Ingeniería Del Software, 5ta Edición - Roger S. PDF

www.FreeLibros.
org
CONSULTOR EDITORIAL
Á R EA D E INFORM ÁTICA Y COM PUTACIÓN
G erardo Quiroz V ieyra

Ingeniero de Comunicacionesy Electrónica
por la ESIME del Instituto Politécnico Nacional
Profesor de la Universidad Autónoma Metropolitana
Unidad Xochimilco
MÉXICO
www.FreeLibros.org
INGENIERIA DEL SOFTWARE
UN ENFOQUE PRÁCTICO
Q uinta edición
Roger S. Pressman
R.S. Pressman & Associates, Inc.
ADAPTACIÓN
Darrel Ince
Open University
TRADUCCIÓN
Rafael Ojeda Martín Isabel Morales Jareño
Virgilio Yagüe Galaup Salvador Sánchez Alonso
D ep a rta m en to de L e n g u a jes y S istem a s Info rm á tico s e Ingeniería d e l S oftw are

F acultad de Inform ática / E scu ela U niversitaria de In fo rm ática
Universidad Pontificia de Salamanca campus Madrid (España)
Jorge A. Torres Jiménez

D ire c to r de la carrera de In geniería de S istem a s C om pu ta cio n a les
Instituto Tecnológico (TEC) de Monterrey campus Querétaro (México)
COLABORACIÓN
Óscar San Juan Martínez Juana González González
Ricardo Lozano Quesada Lorena Esmoris Galán
D ep a rta m en to de L e n g u a jes y S istem a s Info rm á tico s e In geniería d e l Softw are

F acultad de Inform ática / E scu ela U niversitaria de In fo rm ática
REVISIÓN TÉCNICA
Héctor Castán Rodríguez
D ep a rta m en to de L e n g u a jes y S istem a s Info rm á tico s e In geniería d e l Softw are
Facultad de Inform ática / E scu ela U niversitaria d e In fo rm ática
DIRECCIÓN, COORDINACIÓN Y REVISIÓN TÉCNICA

Luis Joyanes Aguilar
D ep a rta m en to de L e n g u a jes y S istem a s In fo rm á tic o s e In geniería d e l Softw are
F acultad de In fo rm ática / E scuela U niversitaria d e In fo rm ática
Me
Grauu
Hit!
www.FreeLibros.org
M A D R ID * BUENOS A IR ES - C A R A C A S * G U A T E M A L A * U S B O A * M E X IC O
NUEVA YORK • P A N A M Á • S A N JU A N • SANTAFÉ DE BOGOTÁ • S A N TIA G O • SAO PAULO
A U C K L A N D * H A M B U R G O * LO N D R E S * M ILÁ N ■ M O N T R E A L * N U E V A D E L H I ■ PARÍS
S A N F R A N C IS C O * S ID N E Y * S IN G A P U R ■ ST. LO U IS • T O K IO • T O R O N T O
IN G E N IE R ÍA D E L SO FTW A R E. U n en foq u e práctico. (5.' edición)
N o está perm itida la reproducción total o parcial de este libro, ni su tratam iento infor
m ático, ni la transm isión de ninguna form a o por cualquier m edio, ya sea electrónico,
m ecánico, por fotocopia, por re gistro u otros m étodos, sin el perm iso p revio y por
escrito de los titulares del C opyright.
D E R E C H O S RESERVADOS © 2002, respecto a la quinta edición en español, por

M cG R A W -H IL L /IN TE R A M ER IC A N A D E ESPA Ñ A , S. A . U.
E dificio Valrealty, 1." planta
B asauri, 17
28023 A ravaca (M adrid)
T raducido de la quinta edición en inglés de

SOFTWARE ENGINEERING.A Practitioner’sApproach. European Adaptation
ISBN : 0-07-709677-0
C o p y rig h t© M M E by The M cG raw -H ill C om panies
ISBN : 84-481-3214-9
D epósito legal: M. 42.852-2001
E ditora: C oncepción Fem ández M adrid

D iseño de cubierta: D esign M aster D im a
www.FreeLibros.org
C om puesto en FER
Im preso en: Im prenta FA RESO. S. A.
IM P R E S O E N ESPA Ñ A - P R IN T E D IN SPAIN
CO N TEN ID O S A P R IM E R A V I S T A
A C E R C A D E L A U T O R , X X III
P R E F A C IO , X X V
P R Ó L O G O A L A C U A R TA E D IC IÓ N E N E SPA Ñ O L , X X IX
P R Ó L O G O A L A Q U IN T A E D IC IÓ N E N E SPA Ñ O L , X X X III
U T IL IZ A C IÓ N D E L L IB R O , X X X V II
PARTE PRIMERA: EL PRODUCTO Y EL PROCESO

CAPÍTU LO 1. E L PRO DUCTO, 3
CAPÍTU LO 2. E L PR O C E S O , 13
PARTE SEGUNDA: GESTIÓN DE PROYECTOS DE SOFTWARE

CAPITU LO 3. C O N C EPTO S SOBRE GESTIÓN DE PR O Y EC TO S, 37
CAPÍTULO 4. P R O C E S O DE SO FTW A REY M ÉTRICAS DE PR O Y EC TO S, 53
C A PITU LO 5. P L A N IF IC A C IÓ N D E P R O Y E C T O S D E SO FTW A RE,77
C A P IT U L O 6. ANÁLISIS Y G E S T IÓ N D E L R IE SG O , 97
C A P IT U L O 7. P L A N IF IC A C IÓ N T E M P O R A L Y S E G U IM IE N T O D E L PR O Y E C T O , 111
C A P IT U L O 8. GARANTIA DE CALIDAD DEL SO FTW A RE(SQ A /G CS), 131
C A P IT U L O 9. G E S T IÓ N D E LA C O N FIG U R A C IÓ N DEL SO FTW A RE(G CSISC M ), 151
PARTE TERCERA: MÉTODOS CONVENCIONALES PARA LA INGENIERÍA DEL SOFTWARE

CAPÍTU LO 10. IN G E N IE R IA DE SISTEM A S, 165
C A P IT U L O 11. C O N C E P T O SY PR IN C IPIO S D EL ANALISIS, 181
CAPÍTU LO 12. M ODELADO DEL ANÁLISIS, 199
CAPÍTU LO 13. C O N C E P T O SY PR IN C IPIO S DE D ISEÑ O , 219
C A P IT U L O 14. D ISEÑ O A R Q U IT E C T Ó N IC O .237
C A P IT U L O 15. D ISEÑ O D E LA IN TERFA Z D E U SUARIO, 259
CAPÍTU LO 16. D ISEÑ O A N IV E L DE C O M PO N EN TE S.273
CAPÍTU LO 17. TÉCN ICAS DE PR U E B A D E L SO FT W A R E ,281
C A P IT U L O 18. ESTRA TEG IA S DE PRU EBA DEL SO FT W A R E,305
CAPÍTU LO 19. M ÉTRICAS TÉCN ICAS D EL SO FT W A R E ,323
PARTE CUARTA: INGENIERIA PEE SOFTWARE ORIENTADA A PRIETOS

CA PITU LO 20. C O N C E P T O SY PR IN C IPIO S ORIEN TA D O S A O BJETO S, 343
CA PITU LO 21. ANÁLISIS O R IE N T A D O A O BJETO S, 361
CA PITU LO 22. D ISEÑ O O R IE N T A D O A O B JE T O S, 379
C A P IT U L O 23. PRUEBAS ORIENTADAS A O B JE T O S, 407
C A P IT U L O 24. M ÉTRICAS TÉCN ICAS PARA SISTEM A S O RIEN TA D O S A O BJETO S, 421
PARTE OTITNTA: TEMAS AVANZADOS EN INGENIERIA DEL SOFTWARE

, C A P IT U L O 25. M ÉTODOS FO R M A LES, 435
CAPÍTU LO 26. IN G E N IE R IA DEL SO FT W A R ED E SALA L IM PIA , 459
CAPÍTU LO 27. IN G E N IE R IA DEL SO FTW A RE BASADA E N C O M PO N EN TES, 473
www.FreeLibros.org
CAPÍTU LO 28. ING EN IERÍA DEL SO FTW A RE D EL C O M E R C IO E LEC TR Ó N IC O
CLIEN TEISERV ID O R, 491
CAPÍTU LO 29. ING EN IERÍA W EB, 521
V
C O N T E N ID O S A P R IM E R A VISTA
CAPÍTULO 30. REINGENIERIA, 541

CAPITULO 31. INGENIERÍA DEL SOFTWARE ASISTIDA POR COMPUTADORA, 559
CAPÍTULO 32. PERSPECTIVAS FUTURAS, 573
APÉNDICE, 581
ÍNDICE, 589
www.FreeLibros.org VI
CONTENIDO
A C E R C A D E L A U T O R , X X III
PR E F A C IO , X X V
P R Ó L O G O A L A CU A RTA E D IC IÓ N E N E SPA Ñ O L , X X IX
P R Ó L O G O A L A Q U IN T A E D IC IÓ N E N E SPA Ñ O L , X X X III
U T IL IZ A C IÓ N D E L L IB R O , X X X V II
PARTE PRIMERA: EL PRODUCTO Y EL PROCESO
CAPÍTULO 1: EL PRODUCTO. 3
1.1. LA EVOLUCIÓN DEL SO FTW A RE 4
1.2. EL SOFTW ARE, 5
1.2.1. CARACTERÍSTICAS DEL SOFTWARE. 5
1.2.2. APLICACIONES DEL SOFTWARE, 6
1.3. SOFTW ARE: ¿UNA CRISIS EN EL H O RIZO NTE?, 8
1.4. M ITOS DEL SOFTW ARE, 8
RESUM EN, 10
REFEREN CIAS, 10
PRO BLEM A S Y PU NTOS A C O N SIDERAR, 11
OTRAS LECTURAS Y FU EN TES DE IN FORM A CIÓN, 11
CAPÍTULO 2: EL PROCESO. 13
2.1. ING EN IERÍA DEL SOFTW ARE: UNA T ECN O LO G ÍA ESTRATIFICAD A, 14
2.1.1. PROCESO. MÉTODOS Y HERRAMIENTAS. 14
2.1.2. UNA VISIÓN GENERAL DE LA INGENIERÍA DEL SOFTWARE. 14
2.2. EL PR O C ESO D EL SOFTW ARE, 16
2.3. M O DELO S DE PR O C ESO D EL SOFTW ARE, 19
2.4. EL M O D ELO LINEAL SECUENCIAL, 20
2.5. E L M O D ELO DE CONSTRUCCIÓN DE P R O T O T IP O S ,21
2.6. E L M O D ELO DRA, 22
2.7. M O DELO S EV O LUTIVOS DE PR O C ESO DEL SOFTW ARE, 23
2.7.1. EL MODELO INCREMENTAL, 23
2.7.2. EL MODELO ESPIRAL. 24
2.7.3. EL MODELO ESPIRAL WINWIN (Victoria & Victoria). 26
2.7.4. EL MODELO DE DESARROLLO CONCURRENTE, 27
2.8. D ESA RRO LLO BASADO EN CO M PO N EN TES, 28
2.9. EL M O D ELO DE MÉTODOS FO RM ALES, 29
2.10. TÉCNICAS DE CUARTA G ENERACIÓ N, 29
2.11. TECN OLOGÍA S DE PRO CESO, 30
2.12. PRO D U CTO Y PRO CESO, 31
RESUM EN , 31
REFEREN CIAS, 32
PRO BLEM A S Y PU NTOS A CO N SIDERAR, 32
OTRAS LECTURA S Y FUENTES DE IN FORM A CIÓN, 33
PARTE SEGUNDA: GESTIÓN DE PROYECTOS DE SOFTWARE
www.FreeLibros.org
CAPÍTULO 3: CONCEPTOS SOBRE GESTIÓN DE PROYECTOS. 37
3.1. EL ESPE C T R O DE LA GESTIÓN , 38
3.1.1. PERSONAL. 38
VII
C O N T E N ID O
3.1.2. PRODUCTO, 38
3.1.3. PROCESO. 38
3.1.4. PROYECTO, 39
3.2. PERSONAL, 39
3.2.1. LOS PARTICIPANTES, 39
3.2.2. LOS JEFES DE EQUIPO. 40
3.2.3. EL EQUIPO DE SOFTWARE,40
3.2.4. ASPECTOS SOBRE LA COORDINACIÓN Y LA COMUNICACIÓN, 43
3.3. PRO DUCTO, 44
3.3.1. ÁMBITO DEL SOFTWARE.44
3.3.2. DESCOMPOSICIÓN DEL PROBLEMA. 45
3.4. PRO CESO, 45
3.4.1. MADURACIÓN DEL PRODUCTO Y DEL PROCESO. 46
3.4.2. DESCOMPOSICIÓN DEL PROCESO. 47
3.5. PRO YECTO , 48
3.6. EL PR IN C IPIO WSHH, 49
3.7. PRÁCTICAS CRÍTICAS, 49
RESUM EN , 50
REFEREN CIAS, 50
OTRAS LECTURAS Y FU EN TES DE INFORM A CIÓN, 51
CAPÍTULO 4- PROCESO DF. SOFTWARE Y MÉTRICAS DF. PROYECTOS. 53

4.1. M EDIDAS, M ÉTRICAS E IN D ICADO RES, 54
4.2. M ÉTRICAS EN EL PR O C ESO Y D O M IN IO S DEL PR O Y EC TO , 55
4.2.1. MÉTRICAS DEL PROCESO Y MEJORAS EN EL PROCESO DEL SOFTWARE. JJ
4.2.2, MÉTRICAS DEL PROYECTO, 58
4.3. M EDICIO NES DEL SOFTW ARE, 58
4.3.1. MÉTRICAS ORIENTADAS AL TAMAÑO, 59
4.3.2. MÉTRICAS ORIENTADAS A LA FUNCIÓN, 61
4.3.3. MÉTRICAS AMPLIADAS DE PUNTO DE FUNCIÓN. 61
4.4. RECO N CILIA CIÓ N DE LOS DIFERENTES ENFO QUES DE M ÉTRICAS, 62
4.5. M ÉTRICAS PARA LA CALIDAD DEL SO FTW A R E,63
4.5.1. VISIÓN GENERAL DE LOS FACTORES QUE AFECTAN A LA CALIDAD. 63
4.5.2. MEDIDA DE LA CALIDAD. 64
4.5.3. EFICACIA DE LA ELIMINACIÓN DE DEFECTOS, 64
4.6. INTEGRACIÓ N DE LAS M ÉTRICAS D EN TRO DEL PR O C E S O DE IN G EN IERÍA
D EL SOFTW ARE, 65
4.6.1. ARGUMENTOS PARA LAS MÉTRICAS DEL SOFTWARE. 65
4.6.2. ESTABLECIMIENTO DE UNA LÍNEA BASE. 66
4.6.3. COLECCIÓN DE MÉTRICAS, CÓMPUTO Y EVALUACIÓN. 66
4.7. E L D ESA RRO LLO DE LA M ÉTRICA Y D E LA O P M (O B JET IV O , PREGUNTA,
M ÉTRICA), 67
4.8. VARIACIÓN DE LA GESTIÓN: C O N TR O L DE PR O C E SO S ESTADÍSTICOS, 69
4.9. M ÉTRICA PARA ORGANIZACIONES PEQUEÑAS, 71
4.10. ESTA BLECIM IEN TO DE UN PRO G RA M A DE M ÉTRICAS DE SOFTW ARE, 72
RESUM EN , 73
REFEREN CIAS, 74
OTRAS LECTURA S Y FUENTES DE IN FORM A CIÓN, 75
www.FreeLibros.org
CAPÍTULO 5: PL ANTFTC ACIÓN DF. PROYECTOS DF. SOFTWARE 77
5.1. OBSERVACIONES SOBRE LA ESTIM ACIÓ N, 78
5.2. O BJETIV O S DE LA PLAN IFICACIÓ N DEL PR O Y EC TO , 79
VIII
CONTENIDO
5.3. A M BITO DEL SO FTW A RE, 79

5.3.1. OBTENCIÓN DE LA INFORMACIÓN NECESARIA PARA EL ÁMBITO, 79
5.3.2. VIABILIDAD, 80
5.3.3. UN EJEMPLO DE ÁMBITO, 80
5.4. RECURSOS, 82
5.4.1. RECURSOS HUMANOS, 82
5.4.2. RECURSOS DE SOFTWAREREUTILIZABLES, 82
5.4.3. RECURSOS DE ENTORNO, 83
5.5. EST IM A C IÓ N DEL PR O Y E C TO DE SOFTW ARE, 84
5.6. TÉCN ICAS DE D ESCO M PO SICIÓ N , 85
5.6.1 TAMAÑO DEL SOFTWARE, 85
5.6.2. ESTIMACIÓN BASADA EN EL PROBLEMA, 86
5.6.3. UN EJEMPLO DE ESTIMACIÓN BASADA EN LDC, 87
5.6.4. UN EJEMPLO DE ESTIMACIÓN BASADA EN PF, 88
5.6.5. ESTIMACIÓN BASADAEN EL PROCESO, 89
5.6.6. UN EJEMPLO DE ESTIMACIÓN BASADA EN EL PROCESO, 89
5.7. M ODELOS E M PÍR IC O S DE ESTIM ACIÓN, 90
5.7.1. LA ESTRUCTURA DELOS MODELOS DE ESTIMACIÓN, 90
5.7.2. EL MODELO COCOMO, 91
5.7.3. LA ECUACIÓN DEL SOFTWARE, 92
5.8. LA DECISIÓ N DE DESARROLLAR-COM PRAR, 92
5.8.1. CREACIÓN DE UN ÁRBOL DE DECISIONES, 93
5.8.2. SUBCONTRATACIÓN (OUTSOURCING), 94
5.9. HERRAM IENTAS AUTOM ÁTICAS DE ESTIM A CIÓ N , 94
RESUM EN, 95
REFERENCIAS, 95
PRO BLEM A S Y PUNTOS A CONSIDERAR, 96
OTRAS LECTURA S Y FU EN TES DE IN FO RM A CIÓ N , 96
CAPÍTULO 6: ANÁLISIS Y GESTIÓN DEL RIESGO. 97

6.1. ESTRATEGIAS DE R IE SG O PROACTIVAS VS. REACTIVAS, 98
6.2. R IE SG O DEL SOFTW ARE, 98
6.3. ID EN TIFICA CIÓ N DEL R IE SG O , 99
6.3.1. EVALUACIÓN GLOBAL DEL RIESGO DEL PROYECTO, 100
6.3.2. COMPONENTES Y CONTROLADORES DEL RIESGO, 101
6.4. PRO Y ECCIÓ N DEL RIESG O , 101
6.4.1. DESARROLLO DE UNA TABLA DE RIESGO, 101
6.4.2. EVALUACIÓN DEL IMPACTO DEL RIESGO, 103
6.4.3. EVALUACIÓN DEL RIESGO, 103
6.5. REFIN A M IEN TO DEL RIESGO, 104
6.6. REDUCCIÓN, SUPERVISIÓN Y G ESTIÓ N DEL R IESG O , 105
6.7. RIESG O S Y PE L IG R O S PARA LA SEGURIDAD, 106
6.8. EL PLAN RSGR, 107
RESUMEN, 107
REFEREN CIAS, 107
PRO BLEM A S Y PUNTOS A CONSIDERAR, 108
OTRAS LECTURAS Y FUENTES DE IN FO RM A CIÓ N , 108
CAPÍTULO 7: PLANIFICACIÓN TEMPORAL Y SEGUIMIENTO DEL PROYECTO. 111
www.FreeLibros.org
7.1. CON CEPTO S BÁSICOS, 112
7.1.1, COMENTARIOS SOBRE «LOS RETRASOS», 112
7.1.2. PRINCIPIO BÁSICOS, 113
IX
CONTE NID O
7.2. LA R ELA CIÓN ENTRE LAS PERSONAS Y E L ESFU ERZO, 114

7.2.1. UN EJEMPLO. 115
7.2.2. UNA RELACIÓN EMPÍRICA, 115
7.2.3. DISTRIBUCIÓN DEL ESFUERZO. 115
7.3. D EFIN ICIÓN DE UN CON JUN TO DE TAREAS PARA EL PRO Y ECTO DE SOFTW ARE, 116
7.3.1. GRADO DE RIGOR. 117
7.3.2. DEFINIR LOS CRITERIOS DE ADAPTACIÓN, 117
7.3.3. CÁLCULO DEL VALOR SELECTOR DEL CONJUNTO DE TAREAS. 117
7.3.4. INTERPRETAREL VALOR SCTY SELECCIONAREL CONJUNTO DE TAREAS. 119
7.4. SELECCIÓ N DE LAS TAREAS DE ING EN IERÍA DEL SO FTW A RE, 119
7.5. REFIN A M IEN TO DE LAS TAREAS PRIN CIPALES, 120
1.6. DEFIN IR UNA RED DE TAREAS, 121
7.7. LA PLA N IFICA CIÓ N TEM PORA L, 122
7.7.1. GRÁFICOS DE TIEMPO. 123
7.7.2. SEGUIMIENTO DE LA PLANIFICACIÓN TEMPORAL. 124
7.8. ANÁLISIS DE VALOR GANADO, 125
7.9. SEGU IM IENTO DEL ERROR, 126
7.10. EL PLAN DEL PRO YECTO , 127
RESUM EN , 127
REFEREN CIAS, 128
CAPÍTULO 8: GARANTÍA DE CALIDAD DEL SOFTWARE (SO A/GCSI, 131

8.1. CON CEPTO S DE CALIDAD, 132
8.1.1. CALIDAD. 132
8.1.2. CONTROLDE CALIDAD. 133
8.1.3. GARANTÍA DE CALIDAD, 133
8.1.4. COSTE DE CALIDAD. 133
8.2. LA TEN D EN CIA DE LA CALIDA D, 134
8.3. GA RA N TIA DE CA LID A D DEL SOFTW ARE, 135
8.3.1. PROBLEMAS DE FONDO. 135
8.3.2. ACTIVIDADES DE SQA, 136
8.4. REVISIO NES DEL SOFTW ARE, 137
8.4.1. IMPACTO DE LOS DEFECTOS DEL SOFTWARE SOBRE EL COSTE. 137
8.4.2. AMPLIFICACIÓN Y ELIMINACIÓN DE DEFECTOS. 138
8.5. REVISIO NES TÉCN ICAS FO RM ALES, 138
8.5.1. LAREUNIÓN DE REVISIÓN, 139
8.5.2. REGISTRO E INFORME DE LA REVISIÓN, 140
8.5.3. DIRECTRICES PARA LA REVISIÓN, 140
8.6. GARANTÍA DE CA LID A D ESTADÍSTICA, 141
8.7. FIA BILID A D DEL SOFTW ARE, 143
8.7.1. MEDIDAS DE FIABILIDAD Y DE DISPONIBILIDAD. 143
8.7.2. SEGURIDAD DEL SOFTWARE. 144
8.8. PRUEBA DE ER R O R E S PARA E L SOFTW ARE, 145
8.9. EL ESTÁNDAR DE C A L ID A D ISO 9001,146
8.10. EL PLAN DE SQA, 147
RESUM EN , 148
R EFEREN CIAS, 148
www.FreeLibros.org
CAPÍTULO 9: GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE(GCS/SCM), 151
9.1. G ESTIÓ N DE LA C O N FIG U RA CIÓ N DEL SOFTW ARE, 152
X
CONTENIDO
9.1.1. LINEAS BASE, 152

9.1.2. ELEMENTOS DE CONFIGURACIÓN DEL SOFTWARE. 153
9.2. EL PR O C ESO DE GCS, 154
9.3. ID EN TIFICA CIÓ N DE O B JE T O S EN LA CON FIGU RACIÓN D EL SOFTW ARE, 154
9.4. C O N TR O L DE V ERSIO N ES, 155
9.5. CO N TRO L DE CAM BIOS, 156
9.6. AUDITORÍA DE LA C ON FIGU RACIÓN , 158
9.7. INFORM ES DE ESTADO, 159
RESUM EN, 159
R EFEREN CIAS, 160
PARTE TERCERA: MÉTODOS CONVENCIONALES PARA LA INGENIERIA DEL SOFTWARE
CAPÍTULO 10: INGENIERÍA DE SISTEMAS. 165

10.1. SISTEM AS BASADOS EN CO M PU TA D O RA , 167
10.2. LA JERA RQ U ÍA DE LA ING EN IERÍA DE SISTEMAS, 167
10.2.1. MODELADO DEL SISTEMA. 167
10.2.2. SIMULACIÓN DEL SISTEMA 168
10.3. IN G EN IERIA DE PR O C ESO DE NEGO CIO: UNA V ISIÓ N GENERAL, 169
10.4. IN G EN IERIA DE PRODUCTO: UNA V ISIÓ N GENERAL, 171
10.5. ING EN IERÍA DE REQUISITO S, 171
10.5.1. IDENTIFICACIÓN DE REQUISITOS, 172
10.5.2. ANÁLISIS Y NEGOCIACIÓN DE REQUISITOS. 173
10.5.3. ESPECIFICACIÓN DE REQUISITOS, 173
10.5.4. MODELADO DEL SISTEMA. 174
10.5.5. VALIDACIÓN DE REQUISITOS, 174
10.5.6. GESTIÓNDE REQUISITOS. 174
10.6. M O D ELA D O DEL SISTEM A, 175
RESUM EN, 178
REFEREN CIAS, 178
PRO BLEM A S Y PUNTOS A CO N SIDERAR, 179
OTRAS LECTURA S Y FU EN TES DE IN FORM A CION, 179
C A PIT U L 011: CONCEPTOSY PRTNCTPTOS DEL ANÁLISIS. 181

11.1. ANÁLISIS DE REQUISITO S, 182
11.2. ID EN TIFICA CIÓ N DE REQUISITO S PARA EL SOFTW ARE, 183
11.2.1. INICIO DEL PROCESO. 183
11.2.2. TÉCNICAS PARA FACILITAR LAS ESPECIFICACIONES DE UNAAPLICAC1ÓN, 184
11.2.3. DESPLIEGUE DE LA FUNCIÓN DE CALIDAD. 186
11.2.4. CASOS DE USO. 186
11.3. PR IN C IPIO S DEL ANÁLISIS, 188
11.3.1. EL DOMINIO DE LA INFORMACIÓN. 189
11.3.2. MODELADO. 190
11.3.3. PARTICIÓN. 190
11.3.4. VISIONES ESENCIALES Y DE IMPLEMENTACIÓN, 191
11.4. CREA CIÓ N DE PRO TO TIPO S DEL SOFTW ARE, 192
www.FreeLibros.org
11.4.1. SELECCIÓN DEL ENFOQUE DE CREACIÓN DE PROTOTIPOS. 192
11.4.2. MÉTODOS Y HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS. 193
11.5. ESPECIFIC A CIÓ N , 193
XI
C O N T E N ID O
11.5.1. PRINCIPIOS DE LA ESPECIFICACIÓN, 194

11.5.2. REPRESENTACIÓN, 194
11.5.3. LAESPECIFICACIÓN DE LOS REQUISITOS DEL SOFTWARE, 194
11.6. REVISIÓN D E LA ESPE C IFIC A C IÓ N , 195
RESUM EN , 196
REFEREN CIAS, 196
O TRAS LECTURA S Y FU EN TES DE INFORM A CIÓN, 197
CA P IT I 11,0 17- M O D E L A D O DF.L A N Á IT S IS . 199

12.1. BREVE HISTO RIA, 200
12.2. LOS ELEM ENTOS DEL M O D ELO DE ANÁLISIS, 200
12.3. M O D ELA D O DE DATOS, 201
12.3.1. OBJETOS DE DATOS. ATRIBUTOS Y RELACIONES. 201
12.3.2. CARDINALIDAD Y MODALIDAD, 203
12.3.3. DIAGRAMAS ENTIDAD-RELACIÓN, 204
12.4. M O D ELA D O FU N CIO N A L Y FLUJO DE IN FORM A CIÓN, 205
12.4.1. DIAGRAMAS DE FLUJO DE DATOS, 206
12.4.2. AMPLIACIONES PARA SISTEMAS DE TIEMPO REAL. 207
12.4.3. AMPLIACIONES DE WARD Y MELLOR. 207
12.4.4. AMPLIACIONES DE HATLEY Y PIRBHAI, 208
12.5. M O D ELA D O D EL C O M PORTAM IEN TO , 209
12.6. M EC A N ISM O S DEL ANÁLISIS ESTRUCTURADO, 210
12.6.1. CREACIÓN DE UN DIAGRAMA ENTIDAD-RELACIÓN, 210
12.6.2. CREACIÓN DE UN MODELO DE FLUJO DE DATOS. 211
12.6.3. CREACIÓN DE UN MODELO DE FLUJO DE CONTROL. 213
12.6.4. LAESPECIFICACIÓN DE CONTROL. 214
12.6.5. LA ESPECIFICACIÓN DEL PROCESO, 214
12.7. E L D ICCIO N A RIO DE DATOS, 215
12.8. O TRO S MÉTODOS CLÁSICOS DE ANÁLISIS, 216
RESUM EN , 216
REFEREN CIAS, 217
OTRAS LECTURA S Y FU EN TES DE IN FORM A CIÓN, 218
C A P ÍT U L O 13: C O N C F .P T O S Y P R T N C T P T O S D F . DTSF.N O. 219

13.1. D ISEN O DEL SO FTW A RE E IN G EN IERIA DEL SOFTW ARE, 220
13.2. EL PR O C ESO DE D IS E NO , 221
13.2.1. DISEÑO Y CALIDAD DEL SOFTWARE. 221
13.2.2. LA EVOLUCIÓN DEL DISEÑO DEL SOFTWARE. 221
13.3. PR IN C IPIO S DEL DISE NO , 222
13.4. CON CEPTO S DEL D ISE NO , 223
13.4.1. ABSTRACCIÓN, 223
13.4.2. REFINAMIENTO, 224
13.4.3. MODULARIDAD, 224
13.4.4. ARQUITECTURA DEL SOFTWARE. 226
13.4.5. JERARQUÍA DE CONTROL. 226
13.4.6. DIVISIÓN ESTRUCTURAL. 227
13.4.7. ESTRUCTURADE DATOS. 228
13.4.8. PROCEDIMIENTO DE SOFTWARE,229
www.FreeLibros.org
13.4.9. OCULTACIÓN DE INFORMACIÓN, 229
13.5. D IS E NO M O DULAR EFECTIVO. 229
XII
C O N T E N ID O
13.5.1. INDEPENDENCIA FUNCIONAL, 229

13.5.2. COHESIÓN, 230
13.5.3. ACOPLAMIENTO. 231
13.6. H EURÍSTICA DE DISEÑO PARA UNA M O D U LA R ID A D EFEC TIV A , 231
13.7. E L M O D ELO DEL DISEÑO, 233
13.8. DOCUM ENTACIÓN D E L D ISE N O , 233
RESUM EN, 234
REFEREN CIAS, 234
OTRAS LECTU RA S Y FU EN TES DE IN FORM A CIÓN, 236
C A P ÍT U L O 14: D T SF N O A R O IU T E C T Ó N IC O .2 3 7
14.1. A R Q U ITECTU RA DEL SOFTW ARE, 238
14.1.1. ¿QUÉ ES ARQUITECTURA?. 23 8
14.1.2. ¿PORQUÉ ES IMPORTANTE LA ARQUITECTURA?. 238
14.2. DISEÑ O DE DATOS, 239
14.2.1 MODELADO DE DATOS. ESTRUCTURAS DE DATOS. BASES DE DATOS Y ALMACÉN DE
DATOS. 239
14.2.2. DISEÑO DE DATOS A NIVEL DE COMPONENTES. 240
14.3. E ST IL O S A RQ U ITECTÓ N ICO S, 241
14.3.1. UNA BREVE TAXONOMÍA DE ESTILOS Y PATRONES. 241
14.3.2. ORGANIZACIÓN Y REFINAMIENTO. 243
14.4. ANÁLISIS D E DISEÑOS A RQ U ITECTÓ N ICO S ALTERNATIVOS, 243
14.4.1. UN MÉTODO DE ANÁLISIS DE COMPROMISO PARA LA ARQUITECTURA. 243
14.4.2. GUÍA CUANTITATIVAPARAEL DISEÑO ARQUITECTÓNICO. 244
14.4.3. COMPLEJIDAD ARQUITECTÓNICA. 245
14.5. CO N V ERSIÓ N DE LOS REQUISITO S EN UNA A R Q U ITECTU RA D EL SO FTW A R E,245
14.5.1. FLUJO DE TRANSFORMACIÓN, 246
14.5.2. FLUJO DE TRANSACCIÓN. 246
14.6. ANÁLISIS DE LAS TRA NSFORM ACIO NES, 247
14.6.1. UN EJEMPLO. 247
14.6.2. PASOS DEL DISENO, 247
14.7. ANÁLISIS DE LAS TRANSACCION ES, 252
14.7.1. UN EJEMPLO. 252
14.7.2. PASOS DEL DISEÑO, 252
14.8. REFIN A M IEN TO DEL DISEÑ O A RQ U ITECTÓ N ICO , 255
RESUM EN , 256
REFEREN CIAS, 256
CAPÍTULO 15: DISE NO DE LA 1NTERFAZ DE USUARIO,259

15.1. LAS REGLAS DE ORO, 260
15.1.1. DAR ELCONTROLALUSUARIO, 260
15.1.2. REDUCIR LA CARGA DE MEMORIA DEL USUARIO. 260
15.1.3. CONSTRUCCIÓN DE UNA INTERFAZ CONSISTENTE. 261
15.2. DISEÑO DE LA INTERFAZ DE U S U A R IO ,262
15.2.1. MODELOS DE DISENODE LAINTERFAZ. 262
15.2.2. EL PROCESO DE DISEÑO DE LA INTERFAZ DE USUARIO. 263
15.3. ANÁLISIS Y M O D ELA D O DE TAREAS, 264
www.FreeLibros.org
15.4. A CTIV ID A D ES DEL D ISEN O DE LA INTERFAZ, 264
15.4.1. DEFINICIÓN DE OBJETOS Y ACCIONES DE LA INTERFAZ. 265
15.4.2. PROBLEMAS DEL DISEÑO, 266
XIII
C O N T E N ID O
15.5. H ERRA M IEN TA S DE IM PLEM ENTACIO N, 268

15.6. EVALUACIÓN DEL D ISE NO , 268
RESUM EN, 270
REFEREN CIAS, 270
OTRAS LECTURAS Y FU EN TES DE INFORM A CIÓN, 271
CAPÍTULO 16: DISEÑO A NIVEL DF, COMPONENTES. 273

16.1. PRO GRAM ACIÓ N ESTRUCTURADA, 274
16.1.1. NOTACIÓN GRÁFICA DEL DISEÑO, 274
16.1.2. NOTACIÓN TABULAR DE DISEÑO, 274
16.1.3. LENGUAJE DE DISENODE PROGRAMAS, 276
16.1.4. UN EJEMPLO DE LDP, 277
16.2. COM PARACIÓN DE N O TA CIO N ES DE DISEÑO, 278
RESUM EN , 279
REFEREN CIAS, 279
CAPÍTULO 17: TÉCNICAS DE PRUEBA DEL SOFTWARE. 281

17.1. FUNDAM ENTOS DE LAS PRU EBA S DEL SOFTW ARE, 282
17.1.1. OBJETIVOS DE LAS PRUEBAS, 282
17.1.2. PRINCIPIOS DE LAS PRUEBAS, 282
17.1.3. FACILIDAD DE PRUEBA, 283
17.2. D ISE NO DE CASOS DE PRU EBA , 285
17.3. PRUEBA DE CAJA BLANCA, 286
17.4. PRUEBA D EL CA M IN O BÁSICO, 286
17.4.1. NOTACIÓN DE GRAFO DE FLUJO, 286
17.4.2. COMPLEJIDAD CICLOMÁTICA, 287
17.4.3. OBTENCIÓN DE CASOS DE PRUEBA, 288
17.4.4. MATRICES DE GRAFOS, 290
17.5. PRU EBA DE LA ESTRU CTU RA DE CON TRO L, 291
17.5.1. PRUEBADE CONDICIÓN, 291
17.5.2. PRUEBADEL FLUJO DE DATOS, 292
17.5.3. PRUEBA DE BUCLES, 293
17.6. PRUEBA DE CAJA N EG RA , 294
17.6.1. MÉTODOS DE PRUEBABASADOS EN GRAFOS, 294
17.6.2. PARTICIÓN EQUIVALENTE, 296
17.6.3. ANÁLISIS DE VALORES LÍMITE, 297
17.6.4. PRUEBADE COMPARACIÓN,297
17.6.5. PRUEBADE LA TABLA ORTOGONAL, 298
17.7. PRUEBA DE ENTORNOS ESPECIALIZADO S, A RQ U ITECTU RA S Y A PLICA CIO N ES, 299
17.7.1. PRUEBADE INTERFACESGRÁFICAS DE USUARIO (IGUs), 299
17.7.2. PRUEBA DE ARQUITECTURA CLIENTE/SERVIDOR, 300
17.7.3. PRUEBA DE LA DOCUMENTACIÓN /F A C ILIDADES DE AYUDA, 300
17.7.4. PRUEBADE SISTEMAS DE TIEMPO-REAL, 300
RESUM EN , 301
REFEREN CIAS, 302
www.FreeLibros.org
XIV
C ONTENIDO
CAPITULO 18: ESTRATEGIAS DE PRUEBA DEL SOFTWARE. 305

18.1. UN ENFOQUE ESTRATÉGICO PARA LAS PRUEBAS DEL SOFTWARE, 306
18.1.1. VERIFICACIÓN Y VALIDACIÓN, 306
18.1.2. ORGANIZACIÓN PARA LAS PRUEBAS DEL SOFTWARE, 307
18.1.3. UNA ESTRATEGIADE PRUEBA DEL SOFTWARE, 307
18.1.4. CRITERIOS PARA COMPLETARLA PRUEBA, 308
18.2. ASPECTOS ESTRATÉGICOS, 309
18.3. PRUEBA DE UNIDAD, 310
18.3.1. CONSIDERACIONES SOBRE LA PRUEBA DE UNIDAD, 310
18.3.2. PROCEDIMIENTOS DE PRUEBA DE UNIDAD, 311
18.4. PRUEBA DE INTEGRACIÓN, 312
18.4.1. INTEGRACIÓN DESCENDENTE, 312
18.4.2. INTEGRACIÓN ASCENDENTE, 313
18.4.3. PRUEBADE REGRESIÓN, 314
18.4.4. PRUEBADE HUMO, 314
18.4.5. COMENTARIOS SOBRE LA PRUEBA DE INTEGRACIÓN, 315
18.5. PRUEBA DE VALIDACIÓN, 316
18.5.1. CRITERIOS DE LA PRUEBA DE VALIDACIÓN, 316
18.5.2. REVISIÓN DE LA CONFIGURACIÓN, 316
18.5.3. PRUEBAS ALFAY BETA, 316
18.6. PRUEBA DEL SISTEMA, 317
18.6.1. PRUEBADE RECUPERACIÓN, 317
18.6.2. PRUEBADE SEGURIDAD, 317
18.6.3. PRUEBA DE RESISTENCIA (STRESS), 318
18.6.4. PRUEBA DE RENDIMIENTO, 318
18.7. EL ARTE DE LA DEPURACIÓN, 318
18.7.1. ELPROCESO DE DEPURACIÓN, 319
18.7.2. CONSIDERACIONES PSICOLÓGICAS, 319
18.7.3. ENFOQUES DE LA DEPURACIÓN, 320
RESUMEN, 321
REFERENCIAS, 321
PROBLEMAS Y PUNTOS A CONSIDERAR, 322
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 322
CAPÍTULO 19: MÉTRICAS TÉCNICAS DEL SOFTWARE. 323

19.1. CALIDAD DEL SOFTWARE, 324
19.1.1. FACTORES DE CALIDAD DE McALL, 324
19.1.2. FURPS, 325
19.1.3. FACTORES DE CALIDAD IS 0 9 1 2 6 ,326
19.1.4. LA TRANSICIÓN A UNA VISIÓN CUANTITATIVA, 326
19.2. UNA ESTRUCTURA PARA LAS MÉTRICAS TÉCNICAS DEL SOFTWARE, 327
19.2.1. EL RETO DELAS MÉTRICAS TÉCNICAS, 327
19.2.2. PRINCIPIOS DE MEDICIÓN, 328
19.2.3. CARACTERÍSTICAS FUNDAMENTALES DE LAS MÉTRICAS DEL SOFTWARE, 328
19.3. MÉTRICAS DEL MODELO DE ANÁLISIS, 329
19.3.1. MÉTRICAS BASADAS EN LAFUNCIÓN, 329
19.3.2. LA MÉTRICA BANG, 330
19.3.3. MÉTRICAS DE LA CALIDAD DE LA ESPECIFICACIÓN, 331
19.4. MÉTRICAS DEL MODELO DE DISEÑO, 332
19.4.1. MÉTRICAS DEL DISEÑO ARQUITECTÓNICO, 332
www.FreeLibros.org
19.4.2. MÉTRICAS DE DISEÑO A NIVEL DE COMPONENTES, 333
19.4.3. MÉTRICAS DE DISEÑO DE INTERFAZ, 335
19.5. MÉTRICAS DEL CÓDIGO FUENTE, 336
XV
C O N T E N ID O
19.6. M ÉTRICAS PARA PRUEBAS, 337

19.7. M ÉTRICAS DEL M A NTEN IM IENTO , 338
RESUM EN, 338
REFEREN CIAS, 338
PR O B LE M A SY PU NTOS A CO N SIDERAR, 339
PARTE CUARTA: INGENIERÍA DFT, SOFTWARE, ORIFATAílA A OBJETOS
CAPITULO 20: CONCEPTOSY PRINCIPIOS ORIENTADOS A PRIETOS. 343

20.1. EL PARADIGM A O RIEN TA D O A O BJETOS, 344
20.2. CO N CEPTO S DE ORIENTACIÓN A O B JET O S, 345
20.2.1. CLASES Y OBJETOS. 346
20.2.2. ATRIBUTOS, 347
20.2.3. OPERACIONES. MÉTODOS Y SERVICIOS. 347
20.2.4. MENSAJES. 347
20.2.5. ENCAPSUL AMIENTO, HERENCIA Y POLIMORFISMO. 348
20.3. ID EN TIFICA CIÓ N DE L O S E LEM EN TO S DE UN M O D E LO DE O B JET O S, 350
20.3.1. IDENTIFICACIÓN DE CLASES Y OBJETOS. 350
20.3.2. ESPECIFICACIÓN DE ATRIBUTOS. 353
20.3.3. DEFINICIÓN DE OPERACIONES.353
20.3.4. FIN DE LA DEFINICIÓN DEL OBJETO, 354
20.4. G ESTIÓ N DE PRO YECTO S DE SO FTW A RE O RIEN TA D O A OBJETOS, 354
20.4.1. EL MARCO DE PROCESO COMÚN PARA 0 0 .3 5 5
20.4.2. MÉTRICAS Y ESTIMACIÓN EN PROYECTOS ORIENTADOS A OBJETOS. 356
20.4.3. UN ENFOQUE 0 0 PARA ESTIMACIONES Y PLANIFICACIÓN. 357
20.4.4. SEGUIMIENTO DEL PROGRESO EN UN PROYECTO ORIENTADO A OBJETOS. 358
RESUM EN, 358
REFEREN CIAS, 359
CAPITULO 21: ANÁLISIS ORIENTADO A PRIETOS. 361

21.1. ANÁLISIS O RIEN TA D O A OBJETOS, 362
20.1.1. ENFOQUES CONVENCIONALES Y ENFOQUES 0 0 .3 6 2
21.1.2. EL PANORAMA DEL AOO. 362
21.1.3. UN ENFOQUE UNIFICADO PARAEL AOO. 363
21.2. ANÁLISIS DEL D O M INIO , 364
21.2.1. ANÁLISIS DE REUTILIZACIÓN Y DEL DOMINIO. 364
21.2.2. EL PROCESO DE ANÁLISIS DEL DOMINIO. 365
21.3. C O M PO N EN TES G ENÉRICOS DEL M O D E LO DE ANÁLISIS OO, 366
21.4. EL PR O C ESO DE AO O, 367
21.4.1. CASOS DE USO, 367
21.4.2. MODELADO DE CLASES-RESPONSABILIDADES-COLABORACIONES, 368
21.4.3. DEFINICIÓN DE ESTRUCTURAS Y JERARQUÍAS, 371
21.4.4. DEFINICIÓN DE SUBSISTEMAS. 372
21.5. EL M O D ELO O BJETO -RELA CIÓ N , 373
21.6. EL M O D ELO O BJETO -CO M PO RTA M IEN TO , 374
21.6.1. IDENTIFICACIÓN DE SUCESOS CON CASOS DE USO, 374
www.FreeLibros.org
21.6.2. REPRESENTACIONES DE ESTADOS. 375
RESUM EN, 376
REFEREN CIAS, 377
XVI
CONTENIDO
PR O B LE M A S Y PU NTOS A CO N SID ERA R, 377

OTRAS LECTU RA S Y FU EN TES DE IN FO RM A CIÓ N , 378
CAPÍTULO 22: DISEÑO ORIENTADO A OBJETOS.379

22.1. DISE N O PARA SISTEM A S O RIEN TA D O SA O B JE T O S, 380
22.1.1. ENFOQUE CONVENCIONAL VS. 0 0 ,3 8 0
22.1.2. ASPECTOS DEL DISENO, 381
22.1.3. ELPANORAMADE DOO. 382
22.1.4. UN ENFOQUE UNIFICADO PARA EL DOO, 383
22.2. EL PR O C ESO DE D ISEN O DE SISTEM A , 384
22.2.1. PARTICIONAR EL MODELO DE ANÁLISIS, 384
22.2.2. ASIGNACIÓN DE CONCURRENCIA Y SUBSISTEMAS. 385
22.2.3. COMPONENTE DE ADMINISTRACIÓN DE TAREAS, 386
22.2.4. COMPONENTE DE INTERFAZ DE USUARIO. 386
22.2.5. COMPONENTEDE LA ADMINISTRACIÓN DE DATOS. 386
22.2.6. COMPONENTE DE GESTIÓN DE RECURSOS, 387
22.2.7. COMUNICACIONES ENTRE SUBSISTEMAS, 387
22.3. PR O C ESO DE D ISE N O DE O B JE T O S, 388
22.3.1. DESCRIPCIÓN DE OBJETOS, 388
22.3.2. DISENO DE ALGORITMOS Y ESTRUCTURAS DE DATOS, 389
22.4. PATRONES DE DISENO, 390
22.4.1. ¿QUÉ ES UN PATRÓN DE DISEÑO?. 390
22.4.2. OTRO EJEMPLO DE UN PATRÓN. 391
22.4.3. UN EJEMPLO FINAL DE UN PATRÓN, 391
22.4.4. DESCRIPCIÓN DE UN PATRÓN DE DISEÑO. 392
22.4.5. EL FUTURO DE LOS PATRONES. 392
22.5. PRO G RA M A CIÓ N ORIENTADA A O B JET O S, 393
22.5.1. EL MODELO DE CLASES. 393
22.5.2. GENERALIZACIÓN, 394
22.5.3. AGREGACIÓN Y COMPOSICIÓN, 394
23.5.4. ASOCIACIONES. 395
22.5.5. CASOS DE USO. 395
22.5.6. COLABORACIONES. 396
22.5.7. DIAGRAMAS DE ESTADO, 397
22.6. CASO DE ESTUDIO . L IB R O S EN LÍNEA, 398
22.6.1. LIBROS-EN-LÍNEA, 399
22.7. PRO G RA M A CIÓ N ORIENTADA A OBJETO S, 400
RESUM EN , 404
R E FE R EN C IA S, 404
PR O B LE M A S Y PU NTOS A CO N SID ERA R, 405
CAPÍTULO 23: PRUEBAS ORIENTADAS A OBJETOS, 407

23.1. A M PLIA N D O LA V ISIÓ N DE LAS PRUEBAS, 408
23.2. PRUEBAS DE LO S M O D E LO S DE AOO Y DOO, 409
23.2.1. EXACTITUD DE LOS MODELOS DE AOO Y DOO. 409
23.2.2. CONSISTENCIADE LOS MODELOS DE AOO Y DOO. 409
23.3. EST R A T EG IA SD E PRUEBAS O RIEN TA D A SA O B JE T O S, 410
23.3.1. LAS PRUEBAS DE UNIDAD EN EL CONTEXTO DE LA OO, 410
23.3.2. LAS PRUEBAS DE INTEGRACIÓN EN EL CONTEXTO OO, 411
www.FreeLibros.org
23.3.3. PRUEBAS DE VALIDACIÓN EN UN CONTEXTO 0 0,4 1 1
23.4. D ISE N O DE CASOS DE PRUEBA PARA SO FTW A RE 0 0 ,4 1 2
23.4.1. IMPLICACIONES DE LOS CONCEPTOS DE OO AL DISEÑO DE CASOS DE PRUEBA. 412
XVII
C O N T E N ID O
23.4.2. APLICABILIDAD DE LOS MÉTODOS CONVENCIONALES DE DISEÑO DE CASOS DE

PRUEBA, 4 12
23.4.3. PRUEBAS BASADAS EN ERRORES, 412
23.4.4. EL IMPACTO DE LA PROGRAMACIÓN 0 0 EN LAS PRUEBAS. 413
23.4.5. CASOS DE PRUEBA Y JERARQUÍA DE CLASES. 414
23.4.6. DISENO DE PRUEBAS BASADAS EN EL ESCENARIO, 414
23.4.7. LAS ESTRUCTURAS DE PRUEBAS SUPERFICIALES Y PROFUNDAS. 415
23.5. MÉTODOS DE PRUEBA A PLIC A B LE S AL N IV EL DE CLASES, 416
23.5.1. LA VERIFICACIÓN AL AZAR PARA CLASES 0 0 .4 1 6
23.5.2. PRUEBA DE PARTICIÓN AL NIVEL DE CLASES, 416
23.6. DISEÑO DE CASOS DE PRU EBA IN TER C LA SES, 417
23.6.1. PRUEBA DE MÚLTIPLES CLASES. 417
23.6.2. PRUEBA DERIVADA DE LOS MODELOS DE C OMPORT AMIENT 0,418
RESUM EN, 419
R EFER EN C IA S, 419
PR O B LEM A S Y PUNTOS A CONSIDERAR, 419
OTRAS LECTURAS Y FU EN TES DE IN FO RM A CIÓ N , 420
CAPÍTULO 24: MÉTRICAS TÉCNICAS PARA SISTEMAS ORIENTADOS A ORTy.TOS.421

24.1. EL PR O PÓ SITO DE LAS M ÉTRICAS ORIENTADAS A O BJETO S, 422
24.2. C A R A C TE R I STIC AS DISTINTIVAS DE LAS M ÉTRICAS ORIENTADAS A OBJETO S, 422
24.2.1. LOCALIZACIÓN, 422
24.2.2. ENCAPSULACIÓN, 422
24.2.3. OCULTACIÓN DE INFORMACIÓN, 423
24.2.4. HERENCIA. 423
24.2.5. ABSTRACCIÓN. 423
24.3. M ÉTRICAS PARA EL M O D E LO DE DISEÑO 0 0 ,4 2 3
24.4. M ÉTRICAS ORIENTADAS A CLASES, 424
24.4.1. LA SERIE DE MÉTRICAS CK. 425
24.4.2. MÉTRICAS PROPUESTAS POR LORENZ Y KIDD, 426
24.4.3. LA COLECCIÓN DE MÉTRICAS MDOO. 427
24.5. M ÉTRICAS ORIENTADAS A O PER A C IO N ES, 428
24.6. M ÉTRICAS PARA PRUEBAS O RIENTADAS A O BJETO S, 428
24.7. M ÉTRICAS PARA PRO Y ECTO S ORIENTADOS A O BJETO S, 429
RESUM EN, 430
R EFER EN C IA S, 430
PR O B L E M A SY PUNTOS A CO N SID ER A R , 431
OTRAS LECTURAS Y FUENTES DE IN FORM A CIÓN, 431
PARTE QUINTA: TEMAS AVANZADOS EN INGENIERÍA DEL SOFTWARE
CAPÍTULO 25: MÉTODOS FORMALES. 435

25.1. CO N CEPTO S BÁSICOS, 436 .
25.1.1. DEFICIENCIAS DE LOS ENFOQUES MENOS FORMALES. 436
25.1.2. MATEMÁTICAS EN EL DESARROLLO DEL SOFTWARE. 437
25.1.3. CONCEPTOS DE LOS MÉTODOS FORMALES. 438
25.2. PR E L IM IN A R ES M ATEM ÁTICOS, 441
25.2.1. CONJUNTOS Y ESPECIFICACIÓN CONSTRUCTIVA.442
www.FreeLibros.org
25.2.2. OPERADORES DE CONJUNTOS. 442
25.2.3. OPERADORES LÓGICOS, 443
25.2.4. SUCESIONES. 443
XVIII
C O N T E N ID O
25.3. APLICA CIÓN D E LA NOTACIÓN M ATEM ÁTICA PA R A L A E SPECIFIC A CIÓ N

FO RM AL, 444
25.4. LEN GUA JES FO R M A LES DE ESPEC IFIC A C IÓ N , 445
25.5. USO DEL LENGUAJE Z PARA REPRESENTAREN COM PONENTE EJEM PLO DE
SOFTWARE, 446
25.6. MÉTODOS FO RM ALES BASADOS EN OBJETOS, 447
25.7. E SPE C IFIC A C IÓ N A LG EBRAICA , 450
25.8. MÉTODOS FO RM ALES CON CURRENTES, 452
25.9. LO S DIEZ M A N D A M IEN TO S DE LOS M ÉTODOS FO RM ALES, 455
25.10. M ÉTODOS FORM ALES: EL FU TU RO, 456
RESUM EN, 456
REFEREN CIAS, 457
PRO BLEM A S Y PU NTOS A CO N SID ERA R, 457
OTRAS LECTU RA S Y FU EN TE S DE IN FO RM A CIÓ N , 458
CAPITULO 26: TNGF.NTF.RTA DEL SOFTWARE DF, SALA LTMPTA. 4 5 9

26.1. E L ENFO QUE DE SALA LIM PIA, 460
26.1.1. LA ESTRATEGIADE SALA LIMPIA, 460
26.1.2. ¿QUÉ HACE DIFERENTE LA SALA LIMPIA?, 461
26.2. E SPE C IFIC A C IÓ N FU NCION AL, 462
26.2.1. ESPECIFICACIÓN DE CAJA NEGRA, 463
26.2.2. ESPECIFICACIÓN DE CAJA DE ESTADO, 463
26.2.3. ESPECIFICACIÓN DE CAJA LIMPIA, 464
26.3. R E FIN A M IE N TO Y V E RIFICA CIÓ N DEL DISEÑO, 464
26.3.1. REFINAMIENTO Y VERIFICACIÓN DEL DISEÑO, 464
26.3.2. VENTAJAS DE LA VERIFICACIÓN DEL DISEÑO, 466
26.4. PRU EBA DE SALA LIM PIA , 467
26.4.1. PRUEBA ESTADÍSTICA DE CASOS PRÁCTICOS, 467
26.4.2. CERTIFICACIÓN, 468
RESUM EN, 469

REFEREN CIAS, 469
PRO BLEM A S Y PU NTOS A CO N SID ERA R, 470
OTRAS LECTURAS Y FU EN TES DE IN FO RM A CIÓ N , 470
CAPÍTULO 27: INGENIERIA DEL SOFTWARE BASADA EN COMPONENTES, 473

27.1. ING EN IERÍA DE SISTEM A S BASADA EN CO M PO N EN TES, 474
27.2. EL PR O C ESO DE ISBC, 475
27.3. IN G EN IERIA DEL DO M INIO , 476
27.3.1. EL PROCESO DE ANÁLISIS DEL DOMINIO, 476
27.3.2. FUNCIONES DE CARACTERIZACIÓN, 477
27.3.3. MODELADO ESTRUCTURAL Y PUNTOS DE ESTRUCTURA 477
27.4. DESA RRO LLO BASADO EN CO M PO N EN TES, 478
27.4.1. CUALIFICACIÓN, ADAPTACIÓN Y COMPOSICIÓN DE COMPONENTES, 479
27.4.2. INGENIERÍA DE COMPONENTES, 481
27.4.3. ANÁLISIS Y DISEÑO PARA LA REUTILIZACIÓN, 481
27.5. CLA SIFICA CIÓ N Y RECU PERA C IÓ N DE C O M PO N E N T E S,482
27.5.1. DESCRIPCIÓN DE COMPONENTES REUTILIZABLES, 482
27.5.2. EL ENTORNO DE REUTILIZACIÓN, 484
www.FreeLibros.org
27.6. ECO N O M IA DE LA ISBC, 484
27.6.1, IMPACTO EN LA CALIDAD, PRODUCTIVIDAD Y COSTE, 484
27.6.2. ANÁLISIS DE COSTE EMPLEANDO PUNTOS DE ESTRUCTURA, 485
XIX
CONTENIDO
27.6.3.MÉTRICAS DE REUTILIZACIÓN. 486

RESUMEN, 486
REFERENCIAS, 487
PROBLEMAS Y PUNTOS A CONSIDERAR, 488
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 488
C A P IT U L O 28: IN G E N IE R IA P E I S O F T W A R E DF.T. C O M F R C I O F I F C T R Ó M C O
CLMENTE/SEBYTPOR,491
28.1. INTRODUCCIÓN, 492
28.2. SISTEMAS DISTRIBUIDOS, 492
28.2.1. CLIENTES Y SERVIDORES. 492
28.2.2. CATEGORÍAS DE SERVIDORES. 492
28.2.3. SOFIWARE INTERMEDIO (MIDDLEWARE), 494
28.2.4.UN EJEMPLO DE SOFIWARE INTERMEDIO. 495
28.3. ARQUITECTURAS ESTRATIFICADAS, 496
28.4. PROTOCOLOS, 497
28.4.1. EL CONCEPTO, 497
28.4.2.IPEICM P, 498
28.4.3. POP3,498
28.4.4.EL PROTOCOLO H'ITP. 499
28.5. UN SISTEMA DE COMERCIO ELECTRÓNICO, 499
28.5.1.¿QUÉ ES EL COMERCIO ELECTRÓNICO?. 499
28.5.2. UN SISTEMA TÍPICO DE COMERCIO ELECTRÓNICO. 500
28.6. TECNOLOGIAS USADAS PARA EL COMERCIO ELECTRÓNICO, 502
28.6.1. CONEXIONES (SOCKETS), 502
28.6.2. OBJETOS DISTRIBUIDOS. 502
28.6.3. ESPACIOS. 503
28.6.4.CGI. 503
28.6.5.CONTENIDO EJECUTABLE. 503
28.6.6. PAQUETES CLIENTE/SERVIDOR, 504
28.7. EL DISEÑO DE SISTEMAS DISTRIBUIDOS, 504
28.7 .l.CORRESPONDENCIADEL VOLUMEN DE TRANSMISIÓN CON LOS MEDIOS DE TRANS
MISIÓN, 504
29.1.2. MANTENIMIENTO DE LOS DATOS MÁS USADOS EN UN ALMACENAMIENTO
RÁPIDO, 504
28.7.3.MANTENIMIENTO DE LOS DATOS CERCA DE DONDE SE UTILIZAN. 504
28.7.4. UTILIZACIÓN DE LADUPLIC ACIÓN DE DATOS TODO LO POSIBLE. 505
28.7.5.ELIMINAR CUELLOS DE BOTELLA. 505
28.7.6. MINIMIZAR LA NECESIDAD DE UN GRAN CONOCIMIENTO DEL SISTEMA. 505
28.7.7. AGRUPAR DATOS AFINES EN LA MISMA UBICACIÓN. 505
28.7.8. CONSIDERAR LA UTILIZACIÓN DE SERVIDORES DEDICADOS A FUNCIONES
FRECUENTES. 506
28.7.9. CORRESPONDENCIA DE LA TECNOLOGÍA CON LAS EXIGENCIAS DE
RENDIMIENTO. 506
28.7.10.EMPLEO DEL PARALELISMO TODO LO POSIBLE. 506
28.7.11 .UTILIZACIÓN DE LA COMPRESIÓN DE DATOS TODO LO POSIBLE. 506
28.7.12. DISEÑO PARA EL FALLO. 506
28.7.13. MINIMIZAR LA LATENCIA. 506
28.7.14.EPÍLOGO, 506
28.8. INGENIERIA DE SEGURIDAD, 507
28.8.1. ENCRIPTACIÓN, 507
www.FreeLibros.org
28.8.2. FUNCIONES DE COMPENDIO DE MENSAJES. 508
28.8.3. FIRMAS DIGITALES, 508
28.8.4. CERTIFICACIONES DIGITALES. 508
XX
C O N T E N ID O
28.9. COM PON EN TES DE SOFTW ARE PARA SISTEM AS C/S, 509
28.9.1. INTRODUCCIÓN, 509
28.9.2. DISTRIBUCIÓN DE COMPONENTES DE SOFTWARE, 509
28.9.3. LÍNEAS GENERALES PARALA DISTRIBUCIÓN DE COMPONENTES DE
APLICACIONES, 510
28.9.4. ENLAZADO DE COMPONENTES DE SOFTWARE C/S, 511
28.9.5. SOFTWARE INTERMEDIO (MIDDLEWARE) Y ARQUITECTURAS DE AGENTE DE SOLICI
TUD DE OBJETOS. 512
28.10. IN G EN IERÍA DEL SO FTW A RE PARA SISTEM AS C/S, 512
28.11. PRO BLEM A S DE M O D ELA D O DE ANÁLISIS, 512
28.12. DISEÑ O DE SISTEM AS C/S, 513
28.12.1. DISEÑO ARQUITECTÓNICO PARA SISTEMAS CLIENTE/SERVIDOR, 513
28.12.2. ENFOQUES DE DISEÑO CONVENCIONALES PARA SOFTWAREDE APLICACIONES. 514
28.12.3. DISEÑO DE BASES DE DATOS. 514
28.12.4. VISIÓN GENERAL DE UN ENFOQUE DE DISEÑO, 515
28.12.5. ITERACIÓN DEL DISEÑO DE PROCESOS. 516
28.13. PRO BLEM A S DE LAS PRUEBAS, 516
28.13.1. ESTRATEGIAGENERAL DE PRUEBAS C/S, 516
28.13.2. TÁCTICA DE PRUEBAS C/S, 518
RESUM EN, 518
R EFEREN CIAS, 519
CAPITULO 29: INGENIERIA WEB, 521

29.1. LOS ATRIBU TO S DE A PLICA CIO N ES BASADAS EN W EB, 522
29.1.1. ATRIBUTOS DE CALIDAD. 523
29.1.2. LAS TECNOLOGÍAS, 524
29.2. E L PR O C ESO DE IW EB, 525
29.3. UN M A RCO DE TRA BA JO PARA LA IW EB, 525
29.4. FO RM ULACIÓ N Y ANÁLISIS DE SISTE M A S BASADOS EN W EB, 526
29.4.1. FORMULACIÓN. 526
29.4.2. ANÁLISIS, 527
29.5. DISEÑO PARA A PLICA CIO N ES BASADAS EN W EB, 527
29.5.1. DISEÑO ARQUITECTÓNICO, 528
29.5.2. DISEÑO DE NAVEGACIÓN, 530
29.5.3. DISEÑO DE LA INTERFAZ. 531
29.6. PRU EBA S DE LAS A PLICA CIO N ES BASADAS EN W EB, 532
29.7. PRO BLEM A S DE GESTIÓN, 533
29.7.1. EL EQUIPO DE IWEB, 533
29.7.2. GESTIÓN DEL PROYECTO. 534
29.1.3. PROBLEMAS GCS PARA LA IWEB, 536
RESUM EN , 537
R EFEREN CIAS, 538
O TRAS LECTURA S Y FU EN TES DE IN FORM A CIÓN, 539
CAPÍTULO 30 - REINGENIERIA,541
www.FreeLibros.org
30.1. REINGENIERÍA DE PRO CESO S DE N E G O C IO , 542
30.1.1. PROCESOS DE NEGOCIOS. 542
30.1.2. PRINCIPIOS DE REINGENIERÍA DE PROCESOS DE NEGOCIOS. 542
XXI
C O N T E N ID O
30.1.3. UN MODELO DE RPN, 543

30.1.4. ADVERTENCIAS, 544
30.2. REINGENIERÍA DEL SOFTW ARE, 544
30.2.1. MANTENIMIENTO DEL SOFTWARE, 544
30.2.2. UN MODELO DE PROCESOS DE REINGENIERÍA DEL SOFTWARE, 545
30.3. ING EN IERÍA INVERSA, 547
30.3.1. INGENIERÍA INVERSAPARA COMPRENDER EL PROCESAMIENTO,548
30.3.2. INGENIERÍA INVERSAPARA COMPRENDERLOS DATOS, 549
30.3.3. INGENIERÍA INVERSADE INTERFACES DE USUARIO, 550
30.4. REESTRU CTU RACIÓN , 550
30.4.1. REESTRUCTURACIÓN DEL CÓDIGO, 550
30.4.2. REESTRUCTURACIÓN DE LOS DATOS, 551
30.5. IN G EN IERIA D IRECTA (FORW ARD ENGIN EERING), 551
30.5.1. INGENIERÍA DIRECTA PARA ARQUITECTURAS CUENTE/SERVIDOR, 552
30.5.2. INGENIERÍA DIRECTA PARA ARQUITECTURAS ORIENTAD AS A OBJETOS, 553
30.5.3. INGENIERíA DIRECTA PARA INTERFACES DE USUARIO, 553
30.6. LA ECONO M ÍA DE LA R EIN G EN IERÍA , 554
RESUM EN , 555
REFEREN CIAS, 555
CAPÍTULO 31: INflF.NIF.WTA DF.LSOFTWARF, ASISTIDA POR COMPUTADORA. 559

31.1. ¿QUÉ SIG NIFICA CASE?, 560
31.2. CONSTRUCCIÓN DE BLOQU ES BÁSICOS PARA CASE, 560
31.3. UNA TAXONOM ÍA DE H ERRA M IEN TA S CASE, 561
31.4. ENTORNOS CASE IN TEGRAD OS, 565
31.5. LA A RQ U ITECTU RA DE IN TEGRACIÓ N, 566
31.6. EL R E PO SIT O R IO CASE, 567
31.6.1. EL PAPEL DEL REPOSITORIO EN 1-CASE,567
31.6.2. CARACTERÍSTICAS Y CONTENIDOS, 568
RESUM EN, 571
REFEREN CIAS, 571
CAPITULO 32: PERSPECTIVAS FUTURAS. 573

32.1. IM PO RTA N CIA DEL SO FTW A RE S E G U N D A PARTE—, 574
32.2. E L Á M B ITO DEL CAM BIO, 574
32.3. LAS PERSONAS Y LA FO RM A EN Q U E CO N STRU Y EN SISTEM AS, 574
32.4. E L «NUEVO» PR O C E S O DE ING EN IERÍA DEL SOFTW ARE, 575
32.5. NUEVOS M O D O S DE R EPRESEN TA R LA IN FO RM A CIÓ N , 576
32.6. LA TECN O LO G IA C O M O IM PULSOR, 577
32.7. CO M EN TA RIO FINAL, 578
REFEREN CIAS, 578
APÉNDICE, 581
www.FreeLibros.org
ÍNDICE, 589
XXII
A C E R C A DEL A U TO R
OGER S. Pressm an es una autoridad intem acionalm ente reconocida en la m ejora del
R proceso del Software y en las tecnologías de la Ingeniería del Software. Durante tres
décadas, ha trabajado com o ingeniero de Software, gestor, profesor, autor y consultor
centrándose en los tem as de la Ingeniería del Softwate.
Como especialista y gerente industrial, el Dr. Pressm an ha trabajado en el desarrollo de sis
temas CAD/CAM para aplicaciones avanzadas de ingeniería y fabricación. También ha ocu
pado puestos de responsabilidad para program ación científica y de sistemas.
Después de recibir el título de Doctor en Ciencias Físicas en Ingeniería de la Universidad de
Connecticut, el Dr. Pressm an se dedicó a la enseñanza donde llegó a ser Profesor A sociado
(Bullard Associate Professor) de Inform ática en la Universidad de Bridgeport y Director del
Com puter-Aided Design an M anufacturing Center en esta Universidad.
El Dr. Pressman es actualm ente el Presidente de R. S. Pressm an & A ssociates, Inc., una
em presa de asesoría especializada en métodos y formación de Ingeniería del Softwate. Trabaja
com o asesorjefe, y está especializado en la asistencia a compañías para establecer unas prác
ticas eficientes de la Ingeniería del Software. También ha diseñado y desarrollado productos
para la formación en Ingeniería del Softwate de la com pañía y de m ejora del proceso: Essen-
tial Software Engineering, un currículum en vídeo totalmente actualizado que se cuenta entre
los trabajos industriales m ás extensos acerca de este tem a y, Process Advi sor, un sistema pro
gram ado para la m ejora en el proceso de ingeniería del softwate. Am bos productos son utili
zados por cientos de compañías mundiales.
El Dr. Pressm an ha escrito num erosos artículos técnicos, participa regularm ente en revistas
industriales, y ha publicado 6 libros. Además de Ingeniería del Software: Un Enfoque P rá c
tico, ha escrito A M anager ’s Guide to Software Engineering (M cGraw-Hill), un libro que hace
uso de un exclusivo formato de preguntas y respuestas para presentar las líneas generales de
Adm inistración para im plantar y com prender la tecnología: M aking Software Engineering Hap-
p e n (Prentice-Hall), que es el prim er libro que trata los problem as críticos de administración
asociados a la m ejora del proceso del Software y Software Shock (Dorset House), un tratado
centrado en el Softwarey su im pacto en losnegociosy en la sociedad. El Dr. Pressm an es m iem
bro del consejo editorial del ZEEE Software y del C u tte rlT Journal, y durante m uchos años fue
editor de la colum na «M anager» del IE E E Software.
El Dr. Pressman es un conocido orador, impartiendo un gran número de conferencias indus
triales principalmente. Ha presentado tutoriales en la Conferencia Internacional de Ingeniería
del Software y en muchas otras conferencias industriales. Es miem bro de ACM , IEEE y Tau
Beta Pí, Phi Kappa Phi, Eta Kappa N u y Pi Tau Sigma.
www.FreeLibros.org XXIII
www.FreeLibros.org
PREFACIO
U AN DO un software de com putadora se desarrolla con éxito - c u a n d o satisface las
C necesidades de las personas que lo utilizan; cuando funciona impecablemente durante

m ucho tiempo; cuando es fácil de m odificar o incluso es m ás fácil de utilizar— puede
cambiar todas las cosas y de hecho las cam bia para mejor. Ahora bien, cuando un software de
com putadora falla - c u a n d o lo s usuarios no se quedan satisfechos, cuando es propenso a erro
res; cuando es difícil de cambiar e incluso m ás difícil de utilizar— pueden ocurrir y de hecho
ocurren verdaderos desastres. Todos queremos desarrollar un software que haga bien las cosas,
evitando que esas cosas malas m erodeen por las sombras de los esfuerzos fracasados. Para tener
éxito al diseñar y construir un software necesitarem os disciplina. Es decir, necesitarem os un
enfoque de ingeniería.
Durante los 20 años que han transcurrido desde que se escribió la prim era edición de este
libro, la ingeniería del software ha pasado de ser una idea oscura y practicada por un grupo muy
pequeño de fanáticos a ser una disciplina legítim a de ingeniería. Hoy en día, esta disciplina está
reconocida com o un tem a valioso y digno de ser investigado, de recibir un estudio concienzudo
y un debate acalorado. A través de la industria, el título preferido para denom inar al «progra
m ador» ha sido reem plazado por el de «ingeniero de software». Los modelos de proceso de
software, los métodos de ingeniería del software y las herram ientas del software se han adap
tado con éxito en la enorme gam a de aplicaciones de la industria.
Aunque gestores y profesionales reconocen igualmente la necesidad de un enfoque m ás dis
ciplinado de software, continúan debatiendo sobre la m anera en que se va a aplicar esta disci
plina. M uchos individuos y compañías todavía desarrollan software de m anera algo peligrosa,
incluso cuando construyen sistemas para dar servicio a las tecnologías m ás avanzadas de hoy
en día. M uchos profesionales y estudiantes no conocen los métodos nuevos y, com o resultado,
la calidad del software que se produce sufrirá y experim entará malas consecuencias. Además,
se puede decir que seguirá existiendo debate y controversia a cerca de la naturaleza del enfo
que de la ingeniería del software. El estado de la ingeniería es un estudio con contrastes. Las
actitudes han cambiado y se ha progresado, pero todavía queda m ucho por hacer antes de que
la disciplina alcance una m adurez total.
La quinta edición de lalngeniería del Software: UnEnfoque Práctico pretende servir de guía
para conseguir una disciplina de ingeniería madura. Esta edición, al igual que las cuatro ante
riores, pretende servir a estudiantes y profesionales, y mantiene su encanto com o guía para el
profesional de industria y com o una introducción completa al tem a de la ingeniería para alum
nos de diplomatura, o para alumnos en prim er año de segundo ciclo. El form ato y estilo de la
quinta edición ha experim entado cambios significativos, con una presentación m ás agradable
y cóm oda para el lector, y con un contenido de acceso m ás fácil.
La quinta edición se puede considerar m ás que una simple actualización. La revisión de este
libro se ha realizado para adaptarse al enorme crecimiento dentro de este cam po y para enfati
zar las nuevas e importantes prácticas de la ingeniería del software. Además, se ha desarrollado
un sitio Web con todo lo necesario y esencial para com plem entar el contenido del libro. Junto
con la quinta edición de Ingeniería del Software: U nE nfoque P ráctico, la Web proporciona
una gama enorme de recursos de ingeniería del software de la que se beneficiarán instructores,
estudiantes y profesionales de industria.
La estructura de la quinta edición se ha establecido en cinco partes y la intención ha sido la
de realizar una división por temas, y ayudar así a instructores que quizás no tengan tiem po de
abarcar todo el libro en un solo trimestre. La Parte Primera, E l producto y el proceso, es una
introducción al entorno de la ingeniería del software. La intención de esta parte es introducir el
tem a principal y, lo que es m ás importante, presentar los conceptos necesarios para los capítu
los siguientes. La Parte Segunda, Gestión de proyectos de software, presenta los tem as rele
vantes para planificar, gestionar y controlar un proyecto de desarrollo de ingeniería. La Parte
www.FreeLibros.org
Tercera,M étodos convencionales p a ra la ingeniería del software, presenta los métodos clási
cos de análisis, diseño y pruebas considerados com o la escuela «convencional» de la ingenie
ría del software. La Parte Cuarta, Ingeniería del software orientada a objetos, presenta los
XXV
P R E F A C IO
m étodos orientados a objetos a lo largo de todo el proceso de ingeniería del software, entre los
que se incluyen análisis, diseño y pruebas. La Parte Quinta, Temas avanzados en ingeniería del
software, introduce los capítulos especializados en métodos form ales, en ingeniería del soft
ware de sala limpia, ingeniería del software basada en componentes, ingeniería del software
cliente/servidor, ingeniería de Web, reingeniería y herram ientas CASE.
La estructura de la quinta edición en cinco partes permite que el instructor «agrupe» los temas
en función del tiem po disponible y de las necesidades del estudiante. Un trimestre completo se
puede organizar en tom o a una de las cinco partes. Por ejemplo, un «curso de diseño» podría
centrarse solo en la Parte Tercera o Cuarta; un «curso de métodos» podría presentar los capí
tulos seleccionados de las Partes Tercera, Cuarta y Quinta. Un «curso de gestión» haría hinca
pié en las Partes Prim era y Segunda. Con la organización de esta quinta edición, he intentado
proporcionar diferentes opciones para que el instructor pueda utilizarlo en sus clases.
E1 trabajo que se ha desarrollado en las cinco ediciones delngeniería del Software: JJnEnfo-
que Práctico es el proyecto técnico de toda una vida. Los m om entos de interrupción los he dedi
cado a recoger y organizar inform ación de diferentes fuentes técnicas. Por esta razón, dedicaré
mis agradecimientos a m uchos autores de libros, trabajos y artículos, así com o a la nueva gene
ración de colaboradores en m edios electrónicos (grupos de noticias, boletines informativos elec
trónicos y W orld W ide Web), quienes durante 20 años me han ido facilitando otras visiones,
ideas, y comentarios. En cada uno de los capítulos aparecen referencias a todos ellos. Todos
están acreditados en cuanto a su contribución en la rápida evolución de este campo. También
quiero dedicar mis agradecimientos a los revisores de esta quinta edición. Sus com entarios y
críticas son de un valor incalculable. Y por Último dedicar un agradecimiento y reconocimiento
especiales a Bruce M axim de la Universidad de M ichigan — DearBom , quien me ayudó a desa
rrollar el sitio Web que acompaña este libro, y com o persona responsable de una gran parte del
diseño y contenido pedadógico— .
El contenido de la quinta edición de Ingeniería del Software: UnEnfoque Práctico ha tomado
forma gracias a profesionales de industria, profesores de universidad y estudiantes que ya habían
utilizado las ediciones anteriores, y que han dedicado m ucho tiem po en mandarm e sus suge
rencias, críticas e ideas. M uchas gracias tam bién a todos vosotros. Además de mis agradeci
mientos personales a m uchos clientes de industria de todo el mundo, quienes ciertamente me
enseñan m ucho m ás de lo que yo mism o puedo enseñarles.
A m edida que he ido realizando todas las ediciones del libro, tam bién han ido creciendo y
m adurando mis hijos M athew y Michael. S u propia madurez, carácter y éxito en la vida han
sido mi inspiración. N ada me ha llenado con m ás orgullo. Y, finalmente, a Bárbara, mi cariño
y agradecimiento por animarme a elaborar esta quinta edición.
R oger S. Pressmcm
www.FreeLibros.org XXVI
P R E F A C IO
L libro de Roger Pressm an sobre Ingeniería del software es verdaderam ente excelente:
E Siempre he admirado la profundidad del contenido y la habilidad del autor para descri
bir datos difíciles de forma muy clara. De m anera que tuve el honor de que McGraw-
Hill m e pidiera elaborar la A daptación E uropea de esta quinta edición. E sta es la tercera
adaptación, y su contenido es un acopio de la quinta edición americana y el material que yo
m ismo he escrito para ofrecer una dim ensión europea.
Las áreas del libro que contienen ese material extra son las siguientes:
• Existe una gran cantidad de m aterial sobre m étodos form ales de desarrollo del software.
Estas técnicas fueron pioneras en el Reino Unido y Alemania, y han llegado a form ar parte
de los juegos de herram ientas críticos para los ingenieros de software en el desarrollo de sis
tem as altamente integrados y críticos para la seguridad.
. He incluido una sección sobre patrones de diseño. Estos son los que tienen lugar general
mente en m iniarquitecturas que se dan una y otra vez en sistemas orientados a objetos, y que
representan plantillas de diseño que se reutilizarán una y otra vez. He viajado por toda Europa,
y me he encontrado constantemente compañías cuyo trabajo depende realm ente de esta tec
nología.
• He aportado material sobre métricas y en particular la utilización de GQM como m étrica de
método de desarrollo. A m edida que la ingeniería del software se va integrando poco a poco
dentro de una disciplina de ingeniería, esta tecnología se va convirtiendo en uno de sus fun
damentos. La m étrica ha sido uno de los puntos fuertes en Europa de m anera que espero que
toda la dedicación que he puesto en este tem a lo refleje.
« He incluido tam bién material sobre el Lenguaje de M odelado Unificado (UML) el cual refleja
el gran incremento de utilización de este conjunto de notaciones en Europa Occidental. A de
m ás, sospecho que van a ser de hecho las notaciones de desarrollo de software estándar
durante los próxim os tres o cuatro años.
• He dado m ayor énfasis al desarrollo de sistemas distribuidos mediante el lenguaje de p ro
gramación Java para ilustrar la im plicación de algunos de los códigos. Ahora que Internet y
el comercio electrónico están en pleno auge en Europa, las compañías cada vez se vuelcan
más en las técnicas de ingeniería del software al desarrollar aplicaciones distribuidas. Y esto
tam bién queda reflejado en el libro.
• He incluido tam bién material sobre métodos de seguridad e ingeniería. Con la utilización de
Intem et (una red abierta) todos los ingenieros del software tendrán que saber muchas más
técnicas tales como firmas digitales y criptografía.
• Hacia el final del libro he hecho especial hincapié en la utilización de aplicaciones de com er
cio electrónico para m ostrar de esta m anera la tecnología distribuida.
Existen dos partes que hacen referencia al libro: un sitio Web americano muy importante, desa
rrollado por el Dr. Pressman; y un sitio de entrada, cuya dirección se proporciona a lo largo de todo
el libro al final de cada capítulo. Este sitio contiene el material relevante para la edición europea y
los enlaces con el sitio americano. Ambos sitios Web en combinación contienen sub-Webs con recur
sos para Estudiantes, para Profesores y para Profesionales.
En los Recursos para el estudiante se incluye una guía de estudio que resume los puntos clave
del libro, una serie de autopruebas que permiten comprobar la com prensión del m aterial, cientos
de enlaces a los recursos de ingeniería del software,un caso práctico, materiales complementarios
y un tablón de mensajes que permite comunicarse con otros lectores.
En la parte Recursos p a ra el profesor se incluye una guía para el instructor, un conjunto de
presentaciones en PowerPoint basadas en este libro, un conjunto de preguntas que se pueden
utilizar para practicar mediante deberes y exámenes, un conjunto de herram ientas muy peque
ñas (herramientas sencillas de ingeniería del software adecuadas para su utilización en clase),
una herram ienta de Web que permite crear un sitio Web específico para un curso, y un tablón
de mensajes que hace posible la com unicación con otros instructores.
En los Recursos p a ra profesionales se incluye docum entación para los procesos de inge
niería del software, listas de com probación para actividades tales com o revisiones, enlaces a
proveedores de herram ientas profesionales, cientos de enlaces a recursos de ingeniería del soft
ware, inform ación sobre los paquetes de vídeo de Pressman, y com entarios y ensayos indus
triales acerca de varios tem as de la ingeniería del software.
www.FreeLibros.org
Ingeniería del software es un libro excelente, y espero que los aportes que he incluido para
el lector europeo hagan de este libro una lectura obligada.
Darrel Ince
XXVII
www.FreeLibros.org
PRÓLOGO A LA CUARTA EDICIÓN EN ESPAÑOL
EL ESTADO DEL ARTE DE LA ING ENIERÍA DEL SOFTW ARE
La Ingeniería de/1 Softw are1es una disciplina o área de la Inform ática o Ciencias de la C om
putación, que ofrece métodos y técnicas para desarrollar y m antener software de calidad que
resuelven problem as de todo tipo. Hoy día es cada vez m ás frecuente la consideración de la
Zngenierh de/l Software com o una nueva área de la ingeniería, y el ingeniero de/l software
com ienza a ser una profesión im plantada en el m undo laboral internacional, con derechos, debe
res y responsabilidades que cum plir, ju n to a una, ya , reconocida consideración social en el
mundo empresarial y, por suerte, para esas personas con brillante futuro.
La Ingeniería de/l Software trata con áreas muy diversas de la inform ática y de las ciencias
de la computación, tales com o construcción de compiladores, sistemas operativos o desarro
llos en Intranet/Intem et, abordando todas las fases del ciclo de vida del desarrollo de cualquier
tipo de sistem as de inform ación y aplicables a una infinidad de áreas tales com o: negocios,
investigación científica, m edicina, producción, logística, banca, control de tráfico, m eteorolo
gía, el m undo del derecho, la red de redes Intem et, redes Intranet y Extranet, etc.
Definición del térm ino «Ingeniería de/l Software»
El térm ino Zngenierh se define en el D R A E 2 como: «1. C onjunto de conocim ientos y técn i
cas que perm iten aplicar el saber científico a la utilización de la m ateria y de las fuentes de
energía. 2. Profesión y ejercicio del ingeniero» y el térm ino ingeniero se define com o «1. Per
sona que profesa o ejerce la ingeniería». De igual m odo la Real A cadem ia de Ciencias E xac
tas, Físicas y N aturales de E spaña define el térm ino In gen iería com o: «C o n ju n to de
conocim ientos y técnicas cuya aplicación permite la utilización racional de los m ateriales y
de los recursos naturales, m ediante invenciones, construcciones u otras realizaciones prove
chosas para el hom bre»3.
Evidentem ente, si la Ingeniería del Software es una nueva ingeniería, parece lógico que reúna
las propiedades citadas en las definiciones anteriores. Sin embargo, ni el D RAE ni la Real Aca
dem ia Española de Ciencias han incluido todavía el térm ino en sus Últimas ediciones; en con
secuencia vamos a recurrir para su definición más precisa a algunos de los autores más acreditados
que com enzaron en su m om ento a utilizar el térm ino o bien en las definiciones dadas por orga
nism os internacionales profesionales de prestigio tales com o IEEE o ACM. Así, hem os selec
cionado las siguientes definiciones de Zngenierh del Software:
Definición 1
Ingeniería de Software es el estudio de losprincipios y metodologías para desarrollo y m an

tenim iento de sistemas de software [Zelkovitz, 1978]4.
Definición 2
Ingeniería del Software es la aplicación prá ctica del conocim iento científico en el diseño
y construcción de program as de com putadora y la docum entación asociada requerida para
desarrollar, operar (funcionar) y m antenerlos. Se conoce tam bién com o desarrollo de soft
w are o producción de software [Bohem, 19761'.
1 E l Hispanoamérica, el término utilizado normalmente es: Ingeniería de Software.

2 DRAE, Diccionariode la Real Academia Española de la Lengua.
www.FreeLibros.org
3 Vocabulario Científico y Técnico, edición de 1996.
* Z e l k o v i t z , M. V., C h a w , A . C. y G a n n o n ,J . D.: Principies o f Software Engineering and Design. Prentice-Hall.Englewoods
Ciif, 1979. '
5 B o e h m , B . W .: «Software Engineering», / £ £ £ Transactions on Computers, C-25,núm. 12, diciembre, pp. 1226-1241.
XXIX
P R Ó L O G O A LA CUARTA E D IC IÓ N EN ESPAÑ O L
Definición 3
Ingeniería del Software trata del establecimiento de los principios y métodos de la ingenie
ría a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales [Bauer,
197216.
Definición 4
La aplicación de un enfoque sistem ático, disciplinadoy cuantificable al desarrollo, opera

ción (funcionamiento) y mantenim iento del software; es decir, la aplicación de ingeniería al
software. 2. El estudio de enfoques com o en (1) [IEEE, 19931.
Tomando com o base la referencia de estas definiciones seleccionadas, se producen de inm e

diato las preguntas: ¿cuáles son las actividades que se encuadran hoy día en el mundo de la
ingeniería del software? y jc ó m o se enseña la disciplina de ingeniería del software en las uni
versidades, escuelas de ingenieros e institutos tecnológicos?
La respuesta a la prim era pregunta se manifiesta de muy diversas formas, pero creemos que
tal vez las fuentes m ás objetivas sean las conferencias, eventos y acontecimientos internaciona
les más relevantes realizados en estos Ultimos años. Así, de los estudiados, hem os considerado
como congresos significativos, los convocados por SIGSOFT (Special Interest Group on Soft
ware Engineering) de la A C M 8: International Conference on Software Engineering (ICSE, copa-
trocinada con IEEE) celebrada en Boston, M assachussets, USA (17-23 de mayo de 1997) y la
próxim a conferencia anunciada para celebrarse en 1998 en Kyoto, Japón (ICSE, 19-25 de abril
de 1998); 5." Symposium Foundations of Software Engineering, SIGSOFT 97 (Zurich, 22-25
septiembre de 1997)y 6." Symposium SIGSOFT 98 (Orlando, Florida, USA, 3-5 noviem bre de
1998).
En los congresos citados anteriormente y en algunas otras fuentes como revistas de ACM /IEE
y otras de tipo profesional o comercial específicas de ingeniería de software, hem os analizado
sus programas, tutoriales, talleres de trabajo, contenidos, etc., y hem os seleccionado una lista
con los tem as más candentes del actual estado del arte de la ingeniería del Software. Los temas
más sobresalientes son:
• Inspección de software crítico.

• Software de Tecnologías de Procesos de Negocios.
• Arquitecturas de Software Distribuido.
• Introducción a UM L (M etodología de objetos, m étodo unificado de Booch, Rum baugh y
Jacobson).
• Control técnico de proyectos software.
• M arcos de trabajo (frameworks) de empresa orientados a objetos.
• Una introducción a CORBA (Estándar para objetos distribuidos).
• Estrategias de ingeniería inversa para m igración de software.
• Ingeniería de objetos.
• M odelado y análisis de arquitectura de software.
• Objetos distribuidos.
• Sistemas Cliente/Servidor.
• Reingeniería.
. CASE.
• Análisis y Diseño Orientados a Objetos.
Esta cuarta edición ha m ejorado en cantidad y calidad a la tercera edición, pero su actuali
dad en el año 1997, reside en el hecho de que la m ayoría de tem as tratados o que se van a tra
tar en los congresos de la ACM (listados anteriormente), están contemplados y tratados por el
autor en este libro. En cualquier form a, deseamos destacar muy expresamente algunas mejoras
concretas que vienen a llenar una importante laguna que existía en los libros de ingeniería del
www.FreeLibros.org
F. L.: «Software Engineering», Information Processing, 71, North Hoiland PubiishingCo., Amsterdam, 1972
6 B a u e r,
7 IEEE:Standards Collection: Software Engineering, IEEE Standard 6 1 0 .1 2 - 1 9 9 0 , IEEE, 1993.

8 URL de ACM, http://www.acm.org.
XXX
P R Ó L O G O A LA CUART A E D I C I Ó N EN ESPAÑO L
software en inglés y, por supuesto, en español. Así, destacamos el estudio y profundidad que
se hace de temas tan candentes y de actualidad en el m undo de la ingeniería del software tales
como:M étodosformales, reutilización de software, reingeniería.métodos de software Cliente/Ser
vidor, C ASE, análisisldiseñolpruebas y métricas orientados a objetos, etc., ju n to con un epí
logo donde m uestra el estado actual y futuro de la Ingeniería del Software. Con relación a la
tercera edición se aprecia una consolidación de tratamientos y una unificación de bloques de
conocimiento que consiguen mejorar el aprendizaje del lector.
Una de las aportaciones m ás relevantes que aporta esta nueva edición es la excelente biblio
grafía y referencias bibliográficas que se adjuntan en cada capítulo del libro, ju n to a una nove
dad que poco a poco com ienza a incorporarse en las buenas obras científicas y que aquí alcanza
un excelente nivel: direcciones electrónicas (U RLs) de sitios Web de Internet notables, donde
se pueden ampliar conocimientos, fuentes bibliográficas, consultorías, empresas, organismos
internacionales, etc., especializados en Ingeniería de Software.
En lo relativo a la segunda pregunta antes enunciada, su respuesta im plica el uso de libros
de texto y m anuales que ayuden al estudiante a com plem entar las lecciones impartidas por el
profesor, así com o preparar sus trabajos, prácticas, exám enes, etc. Un libro para ser conside
rado de texto o referencia de una determ inada asignatura requiere que su contenido contenga
todos o la m ayoría de los descriptores o tópicos considerados en el program a de la asigna
tura. Veamos por qué esta obra es idónea com o libro de texto para asignaturas del cum'culum
universitario de Ingeniería de/l Software.
EL LIBRO COMO TEXTO DE REFERENCIA UNIVERSITARIA
La importancia fundamental de la disciplina Ingeniería del Software se está manifestando, de modo

destacado,en los currículum de informática y ciencias de la com putaciónde la m ayoría de las uni
versidades de todo el mundo, y seguirá creciendo su im portancia a m edida que nos acerquemos
al tercer milenio.
Debido a estas circunstancias, las organizaciones profesionales, los departam entos educati
vos de los diversos gobiernos y los departam entos universitarios se han preocupado en esta
década y en las anteriores de estandarizar los program as curriculares de las diferentes carreras,
incluyendo materias (asignaturas) troncales y obligatorias, en los planes de estudios de Facul
tades y Escuelas de Ingenieros de todo el mundo.
E1 caso más significativo lo constituyen las organizaciones profesionales internacionales que
se han preocupado tam bién de este proceso. Entre las m ás destacadas sobresalen ACM (Asso-
ciation o f Computing M achinery) e IEEE (Institute for Electrical and Electronics Engineers).
Así, en el año 1991, estas dos organizaciones publicaron conjuntamente unas recom endacio
nes con los requisitos (materias) imprescindibles que, al menos, debían contem plar todos los
planes de estudios de carreras relacionadas con Ciencias de la Computación (Informática). Estas
recom endaciones han sido seguidas por todas las universidades de Estados Unidos y práctica
mente, de una u otra form a, por casi todas las universidades europeas e hispanoam ericanas,
desde el año de su publicación.
Las recom endaciones ACM /IEEE dividen los requisitos del currículum en nueve áreas dife
rentes, con subdivisiones en esas áreas. Para cada subárea se recom ienda un núm ero m ínim o
de unidades de conocimiento (knowledge units) con una indicación de tiem po para cada una de
ellas (períodos de 50 minutos/clase). En estas nueve áreas se incluyen: Algoritmos, A rquitec
tura, Inteligencia Artificial, Bases de Datos, Interfaces Hom bre/M áquina, Computación num é
rica, Sistemas Operativos, Programación, Ingeniería del Software, Lenguajes de Programación
y Temas legales, profesionales y sociales. Los tem as recom endados en el área de Ingeniería de
Software son:
1. Conceptos fundamentales de resolución de problemas.

2. Proceso de desarrollo de software.
3. Especificaciones y requisitos de software.
4. Diseño e im plementación de software.
5. Verificación y validación.
www.FreeLibros.org
9 http:/wwwacm.org ; http:/xavier.xu.edu:8000/—lewan/new cum'culum.html
XXXI
P R Ó L O G O A LA CU ARTA E D I C I Ó N EN ES PAÑ OL
En España, el Consejo de Universidades, organismo encargado de dictar directrices y nor

m as para los planes de estudios de las universidades tiene redactadas las norm ativas que han
de cum plir todas las universidades que deseen im partir las carreras de Ingeniería en Inform á
tica (cinco años académicos, diez semestres), Ingeniería Técnica en Inform ática de Sistemas e
Ingeniería Técnica en Inform ática de Gestión (tres años académicos, seis sem estres) y se publi
can oficialmente en el Boletín O ficial del Estado (BO E). En estas norm ativas de obligado cum
plim iento por todas las universidades, se incluyen las m aterias (asignaturas o conjunto de
asignaturas) troncales que se deben incluir obligatoriam ente en todos los planes de estudios,
además de otras asignaturas con carácter obligatorio y opcional que cada universidad fija en
sus planes de estudios.
Ingeniería del Software es una m ateria troncal incluida en las carreras citadas. 18 créditos
(cada crédito equivale a diez horas de clase) en la ingeniería superior (ingeniero inform útico)
y 12 créditos en la ingeniería técnica de inform ática de gestión (ingeniero técnico informútico).
Esto significa una carga lectiva considerable que todos los estudiantes de carreras de inform á
tica y de com putación han de estudiar, norm alm ente en los cursos 3.” a 5.°
Este libro puede ser utilizado en diferentes tipos de cursos de ingeniería de software tanto a
nivel universitario como a nivel profesional:
1. Cursos introductorios de Ingeniería del Software. Estudiantes de prim er ciclo (tres años)
y segundo ciclo (cinco años), o en carreras de cuatro años (como suele ser el caso de las
universidades hispanoam ericanas y alguna española), sin experiencia previa en Ingenie
ría del Software, pero con formación de dos o tres cursos universitarios (cuatro o cinco
semestres) al menos.
2. Cursos introductorios y de nivel m edio sobre tem as específicos de Ingeniería del Soft
ware tales com o análisis de requisitos y especificaciones, gestión de proyectos de soft
ware, métodos convencionales de Ingeniería del Software, etc.
3. Cursos avanzados en tem as de Ingeniería del Software tales com o: análisis y diseño orien
tados a objetos, métricas, ingeniería inversa, Cliente/Servidor, Reutilización de software,
etcétera.
Este libro explica todos los tem as incluidos en la asignatura o m ateria troncal Ingeniería del
Softw are por el Consejo de Universidades de España, así com o las unidades SE2 a SE5 (la uni
dad SE1 se refiere a conceptos de tipo general que suelen incluirse en otras asignaturas bási
cas) del currículum de la ACM/EEEE de 1991. Por nuestro conocimiento personal (conferencias,
cursillos, estancias...) de m uchas universidades hispanoam ericanas, nos consta que los planes
de estudio de estas universidades incluyen tam bién asignaturas de tipo obligatorio de Ingenie
ría del Software que siguen prácticam ente las recom endaciones de ACM /IEEE y son muy sim i
lares a los program as que se siguen tam bién en España.
APÉNDICE
La obra actual incluye gran cantidad de siglas y acrónimos en inglés, la m ayoría de las cuales,
exceptuándolas ya acreditadas en inglés cóm o BPR..., se han traducido al español. Por su espe
cial im portanciay la gran cantidad de ellas incluidas en el libro, el equipo de traducción decidi
mos recopilar todas las siglas en inglés y sus traducciones al español; a continuación se ha construido
dos tablas ordenadas alfabéticamente en inglés y en español, con el objetivo principal de que el
lector pueda localizar fácilmente cualquiera de las siglas que aparecen en el texto, y en su caso,
la traducción al español. Estas tablas se presentaron a la editora de la obra que tras ver el servicio
que proporcionaba al lector, aceptó incluirlas como Apéndice. De este modo, el lector podrá com
probar en cualquier m om ento entradas de siglas tanto en español como en inglés.
EPÍLOGO
La traducción de esta obra ha sido un esfuerzo com ún que hem os realizado profesores de dife
www.FreeLibros.org
rentes universidades españolas e hispanoam ericanas — profesores de Ingeniería del Software
que hem os utilizado, en la m ayoría de los casos, las ediciones anteriores de esta obra como libro
de referencia en nuestras clases y continuaremos utilizándolo. Por esta circunstancia, hemos
XXXII
P R Ó L O G O A LA CU ART A ED I C I Ó N EN ES PAÑ OL
podido apreciar que esta cuarta edición ha m ejorado de modo muy notable a las ediciones ante
riores y tenem os el convencim iento de que los principios y conceptos considerados en ella,
seguirán teniendo una influencia considerable en num erosos estudiantes de ingeniería, licen
ciatura inform ática o sistemas com putacionales de habla española, com o nos consta que siguen
influyendo en el m undo de habla inglesa. Estamos seguros de que serán m uchos los estudian
tes que seguirán formándose en Ingeniería del Software con este libro com o referencia funda
mental.
Esta cuarta edición llena num erosas lagunas en la literatura de habla española, ya que actua
liza los contenidos tradicionales de la Ingeniería del Software y los extiende a los tem as avan
zados m odernos que ya hem os considerado. El excelente trabajo de Roger S. Pressman permitirá
seguir formando num erosos y buenos profesionales de Ingeniería del Softw are para que esta
industria pueda seguir desarrollándose.
M adrid, septiembre de 1997
Luis Joyanes A guilar

Director del Departam ento de Lenguajes y Sistem as Inform áticos
e Ingeniería del Software
Facultad de Inform ática y Escuela Universitaria de Inform ática
Universidad Pontificia de Salam anca. Campus de M adrid
www.FreeLibros.org XXXIII
P R Ó LO G O A LA Q U IN T A EDICIÓN EN E SP A Ñ O L
L siglo xxi se enfrenta a la creciente im plantación de la sociedad del conocimiento. La

era del conocimiento en que vivimos no sólo está cambiando la sociedad en sí misma,
sino que los nuevos m odelos de negocios requieren la reform ulación de nuevos con
ceptos. Conocim iento, activos intangibles, Web, etc., son algunos de los térm inos m ás utiliza
dos en cualquier ambiente o negociación. Esta era del conocimientorequiere de nuevas tendencias
apoyadas precisam ente en el conocimiento. La ingeniería del software no es una excepción, y
por ello se requiere no sólo una actualización de conceptos, sino tam bién una com prensión y
una formulación del nuevo conocimiento existente en torno a las nuevas innovaciones y teo
rías de dicha disciplina.
En cada edición de su clásica obra, R oger Pressm an nos tiene acostumbrados a la sorpresa
y a la admiración por la clara y excelente exposición de los tem as tratados. Esta vez tampoco
ha sido una excepción, muy al contrario, Pressman da la sensación de haber conseguido «la
cuadratura del círculo» o m ejor aún, ha encontrado la piedra filosofal para form ar y educar a
los actuales y — sobre todo— futuros ingenieros de software del futuro (o a los ingenieros infor
m áticos e ingenieros de sistemas y licenciados en inform ática que se forman en esta disciplina).
En esta quinta edición, Pressm an proporciona al lector una ingente cantidad de conocimiento
relativo a ingeniería del software que facilitará considerablem ente su formación con todo el
rigor profesional y científico que requiere la nueva era del conocimiento que vivirem os en esta
década.
E L N UEV O C O N T E N ID O
Una de las grandes y atractivas novedades de esta quinta edición es su nuevo form ato y estilo.
El SEPA5/2, como se le conoce en la versión en inglés, ha m ejorado el libro y lo ha hecho más
legible y atractivo al lector. M ediante iconos y una lista norm alizada de seis cuestiones clave,
Pressm an va guiando al lector sobre los tem as mas im portantes de cada capítulo a la vez que
su lectura le introduce paulatina e inteligentem ente en las ideas y conceptos más importantes.
Esta quinta edición contiene todos los tem as im portantes de la cuarta edición e introduce una
gran cantidad de tem as relativos a las nuevas tendencias, herram ientas y m etodologías que plan
tea la ingeniería de software actual y futura, así como la naciente nueva ingeniería Web. Un
estudio detenido del contenido nos conduce a los cambios más sobresalientes realizados en esta
quinta edición, que son, entre otros, los siguientes:
• Cinco nuevos capítulos (Capítulo 14, Diseño arquitectónico; Capítulo 15, Diseño de la
interfaz de usuario, proporcionando reglas de diseño, procesos de m odelado de interfaces,
diseño de tareas y métodos de evaluación; Capítulo 16, Diseño a nivel de componentes;
Capítulo 27, exam ina los procesos y la tecnología de la ingeniería de software basada en
componentes, y, Capítulo 29, que presenta los nuevos conceptos de Ingeniería Web (proce
sos WebE, análisis y formulación de aplicaciones Web, es decir arquitectura, navegación y
diseño de interfaces, pruebas y aplicacionesW eb y gestión de proyectos de ingeniería Web).
• Gran cantidad de actualizaciones y revisiones de los 32 capítulos de su contenido total.
Los cambios clave son numerosos, y los m ás sobresalientes son:
— Modelos de procesos evolutivos (WinWin) y de ingeniería basada en componentes.

— Nuevas secciones sobre control estadístico de la calidad.
— Modelo de estim ación de COCOM O 11.
— Técnicas a prueba de errores para gestión de calidad de software (SQA).
— Ingeniería de requisitos.
www.FreeLibros.org
— El lenguaje unificado de modelado, UM L (Unified M odeling Language).
— Nuevas regias y teoría de calidad de software que siguen la norm ativa ISO 9000.
XXXIV
P R Ó L O G O A LA QUINTA E D I C I Ó N EN ES PAÑ OL
NUEVOS RECURSOS DOCENTES Y PROFESIONAUES
Si la edición en papel que tiene el lector en sus manos ya es de por sí excelente, el sitio Web
del libro no le queda a la zaga (www.pressman5.com). Este sitio es una de las mejores herra
m ientas de las que pueden disponer estudiantes, profesores y m aestros, y profesionales del
m undo del software. Destaquem os algunas.
Recursos de estudiantes
• Guía de estudios.
• Autotest.
• Recursos basados en la Web.
• Estudio de casos.
• Vídeos.
• Contenidos suplementarios.
• Foros para intercam bios de mensajes entre lectores.
Recursos de profesores y maestros
• Guía del profesor.

• Transparencias (acetatos) en PowerPoint.
• Bancos de prueba.
• Herram ientas de ingeniería de software.
• Foros de intercam bio de mensajes entre colegas.
Recursos profesionales
• Plantillas de productos de documentos y de trabajos.

• Listas de pruebas de ingeniería de software.
• Herram ientas de ingeniería de software.
• Herram ientas CASE.
• Recursos de ingeniería de software.
• M odelos de procesos adaptables.
• Currículum de vídeos de calidad para la industria.
• Comentarios de la industria.
• Foros profesionales.
EL GLOSARIO DE SIGLAS: UN NUEVO APÉNDICE
U na de las características m ás sobresalientes de esta obra es que recoge con gran profusión la
ingente cantidad de siglas que hoy día se utilizan en la industria del softwarejunto a otras muchas
más acuñadas por el propio autor.
El equipo de profesores que ha traducido y adaptado la versión en inglés de com ún acuerdo
con la editora acordó realizar un apéndice que incluyera todas las siglas incluidas en el libro y
las traducciones correspondientes en español, y viceversa. Este apéndice busca, al igual que ya
se hiciera en la segunda edición en español, facilitar al lector la lectura y seguimiento del m odo
más fácil posible y que le perm ita hacer la correspondencia entre ambos idiomas cuado lo nece
site. Por ello, este apéndice contiene un diccionario inglés-español y otro español-inglés de
siglas. El m étodo que se ha seguido durante la traducción ha sido traducir prácticam ente todas
las siglas, y sólo se han realizado algunas excepciones, com o SQ A (Software Quality Assure-
ment) por su uso frecuente en la jerg a informática, aunque en este caso hem os utilizado ambos
www.FreeLibros.org
térm inos (en inglés, SQA y en español, GCS, Gestión de Calidad del Software). En este caso,
estas siglas en español coinciden con Gestión de Configuración del Software (G CS), por lo que
a veces estas siglas se han traducido por GCVS (Gestión de Configuración de Versiones de Soft
XXXV
P R Ó L O G O A LA QUIN TA E D I C I Ó N EN ESPAÑ OL
ware) para evitar duplicidades. Ésta es una de las razones fundam entales por la que hem os
incluido el glosario de siglas.
EL EQUIPO TRADUCTOR
La edición británica ha sido adaptada por un prestigioso profesor británico, y la edición y la

adaptación españolas han sido realizadas por un num eroso equipo de profesores del Departa-
mentó de Lenguajes y Sistemas Informáticos e ingeniería del Software de la Facultad de in fo r
mática y Escuela Universitaria de Inform ática de la Universidad Pontificia de Salam anca
(España) del campus de M adrid, que ha contado con la inestimable colaboración de profeso
res del prestigioso Instituto Tecnológico (TEC) de M onterrey, de su campus de Querétaro
(México). Una obra de la envergadura de esta quinta edición requería — como ya sucedió tam-
bien en la edición a n te r io r - d e l trabajo y coordinación de num erosas personas. Muchas han
sido las horas dedicadas a la traducción, adaptación y sucesivas revisones de galeradas de las
pruebas de imprenta. Confiamos haber cumplido nuestra obligación con dignidad y profesio-
nalidad.
EL FUTURO ANUNCIADO
Esta quinta edición ha sido actualizada sustancialmente con nuevos m ateriales que reflejan el
estado del arte de la ingeniería del software. El material obsoleto se ha eliminado de esta edi
ción para crear un texto fácil de leer y entender, y totalmente actualizado. Sin embargo, y con
ser importante todo su vasto y excelente contenido, queremos destacar que esta nueva edición
nos brinda y abre el camino al futuro que señala la m oderna ingeniería de software basada en
objetos y componentes, así com o a la ingeniería Web, conservando el rigor y la m adurez de las
teorías ya clásicas de la ingeniería del software.
Sin lugar a dudas, Pressm an ha conseguido una excelente obra, y en una prueba clara de pro-
fesionalidad y excelencia ha logrado superar sus cuatro ediciones anteriores ya de por sí exce
lentes.
M a d rid y Carchelejo (España),verano de 2001
Luis Joyanes A guilar

Director del Departamento de Lenguajes, Sistemas informáticos e Ingeniería de Software
Facultad de Inform ática/Escuela Universitaria de Informática
Universidad Pontificia de Salam anca campus M adrid
www.FreeLibros.org XXXVI
U T ILIZAC IÓ N DEL LIBRO
A quinta edición de Ingeniería del Software: Un Enfoque Práctico se ha vuelto a diseñar para aum entar la
L experiencia del lector y para proporcionar enlaces integrados al sitio Web, http://w w w .p ressm an 5 .co m .
Dentro de este sitio los lectores encontrarán inform ación com plem entaria útil y rica, y una gran cantidad
de recursos para los instructores que hayan optado por este libro de texto en clase.
A lo largo de todo el libro se van encontrando iconos que deberán interpretarse de la siguiente manera:
El icono de punto clave ayudará El icono Referencia web p ro p o r

a e n c o n tra r d e fo rm a rá p id a los c io n a p u n te ro s d ire c to s a sitio s
puntos im portantes. W eb im portantes relacionados con
Utilizado para enfarizarun punto impor la in g en ie ría del softw are.
Para punteros que conducirán
tante en el cuerpo del texto.
directamente a los recursos de la Web.
El icono de consejo p roporciona

^C O N SEJojfy. una guía pragm ática que servirá de El icono de sitio Web in d ica que
ayuda para tom ar la decisión ade se d isp o n e de m ás in fo rm a c ió n
Un consejopráctico de/mundo red apir
c uada o ev itar los problem as típ i sobre el tem a destacado en el sitio
cadea la ingeniería del software. cos al elaborar software. W eb SEPA.
Un tema seleccionado.
El icono de signo de interroga

b..i dónde puedo ción form ula preguntas que se res
encontrarla respues, a?
ponderán en el cuerpo del texto.
E l ico n o d e lista de comproba
ción nos señala las listas de c o m
probación que ayudan a e v alu ar el
0= trab ajo de in g en ie ría del softw are
E= que se e stá llev an d o a cabo y los
pro d u cto s del trabajo.
El icono de referencia cruzada
lista de comprobación
litiM U lU M I nos c o n d u cirá a alg u n a o tra parte
Proporciona una referencia cruzada impor
del texto en donde se podrá encon
tante dentro dd libro
tra r info rm ació n relevante sobre
el tem a en cuestión.
El icono de documento nos seña

la lo s b o c e to s, d e sc rip c io n e s y
e jem p lo s d e docum entos del sitio
www.FreeLibros.org
E l ico n o d e cita p re se n ta c ita s W eb SEPA.
interesantes que tienen gran rele
vancia para los tem as que se estén
Documento
tratando.
XXXVII
www.FreeLibros.org
PARTE
EL P R O D U C T O
Y EL P R O C E S O
N esta parte de Ingeniería del software: un enfoque práctico aprenderá
E sobre el producto que va a ser tratado con ingeniería y el proceso, que

proporciona un marco de trabajo para la tecnología de Ingeniería del
software. En los capítulos siguientes se tratan las preguntas:
• ¿Qué es realmente el software de computadora?
• ¿Por qué se lucha para construir sistemas de alta calidad basados en com
putadoras?
• ¿Cómo se pueden establecer categorías de dominios de aplicaciones para
software de computadoras?
• ¿Qué mitos de software van a existir?
• ¿Qué es un «proceso» de software?
• ¿Existe una forma genérica de evaluar la calidad de un proceso?
• ¿Qué modelos de procesos se pueden aplicar al desarrollo del software?
• ¿En que difieren los modelos de proceso lineales e iterativos?
• ¿Cuáles son sus puntos fuertes y débiles?
• ¿Qué modelos de proceso avanzados se han propuesto para la ingeniería
del software?
Una vez contestadas todas estas preguntas, estará m ás prepar ado para com
prender los aspectos técnicosy de gestión de la disciplina de ingeniería a la que
se dedica el resto del libro.
www.FreeLibros.org 1
www.FreeLibros.org
CAPITULO
EL PRODUCTO
1
AS alarmas com enzaron m ás de una década antes del acontecimiento. Con m enos de
L dos años a la fecha señalada, los m edios de com unicación recogieron la historia. Los
oficiales del gobierno expresaron su preocupación, los directores de la industria y de los
negocios com prom etieron grandes cantidades de dinero, y por Ultimo, las advertencias horri
bles de catástrofe llegaron a la conciencia del público. El software, al igual que el ahora fam oso
error Y2K, podría fallar, y com o resultado, detener el m undo com o nosotros lo conocimos.
Com o vim os durante los últim os m eses del año 1999, sin querer, no puedo dejar de p en
sar en el párrafo profético contenido en la prim era página de la cuarta edición de este libro.
Decía:
E l softw are de com p u tad o ra se ha c o nvertido en el alm a m ater. E s la m áquina que conduce a la tom a
de decisio n es com erciales. Sirve de base para la in v estig a ció n científica m o d ern a y de reso lu ció n de p ro
b lem as de ingeniería. E s el fa cto r clave que d ifere n cia lo s p ro d u cto s y servicios m odernos. E stá inm erso en
sistem as de todo tipo: de transportes, m édicos, d e telecom unicaciones, m ilitares, procesos industriales, entre
tenim ientos, productos de oficin a..., la lista es cási in term inable. El softw are es casi inelu d ib le e n un m u n
do m oderno. A m edida que nos ad en trem o s en el siglo xx i, será el que n o s conduzca a nuevos avances en
to d o , d esde la e d u ca ció n elem ental a la in g en iería genética.
VISTAZO RÁPIDO
¿Qué es? El softw are d e c o m p u tad o ra e s ¿ P a r q u é e s im p o r ta n te ? P o rq u e ¿C uál e s e l prc ducto obtenido?D es-
el producto q u e d is e ñ a n y c onstruyen a f e c t a m uy d e c e r c a a c u a l q u i e r d e el p unto d e v ista d e u n ingeniero d e
los in o en ie ro s d e l softw are. E sto a b a r a s p e c to d e n u e s tr a vid a y e s t á m uy softw are, e l p ro ducto o b te n id o s o n los
c a p ro g ra m a s q u e se e je c u ta n d e n tro e x te n d id o e n n u e s tr o c o m e rc io , c u í- p ro g ra m a s , d o c u m e n to s y lo s d a to s
d e u n a c o m p u ta d o ra d e c u a lq u ie r tu r a y e n n u e s t r a s a c tiv id a d e s c o ti q u e con fig u ran e l so ftw a re d e co m p u
ta m a ñ o y a rq u ite c tu ra , d o c u m e n to s d ia n a s . tad o ra . P ero d e sd e el p u n to d e v is ta d e
qu e com prenden form ularios v irtu a les ¿ C u á le s s o n lo s p a s o s? C o n s tru ir los u su a rio s el producto o b ten id o e s le
e im p re so s y d a to s q u e c o m b in a n so ftw a re d e co m p u tad o ra com o c o n s in fo rm a c ió n r e s u lta n te q u e h a c e de
n ú m ero s y te x to y ta m b ié n in clu y e n truim os c u a lq u ie r otro prod u c to s a tis a lg ú n m o d o e l m u n d o m ejo r a los
re p re s e n ta c io n e s d e info rm ació n d e fa cto rio , a p lic a n d o u n p ro c e so q u e u su a rio s.
a u d io , vídeo e im ág en es. conduce a u n resultado d e a lta c alid ad ¿Cómo p u e d o e s ta r se g u r o d e q u e
¿Quién l o h a c e ? Los in g e n ie ro s d e soft q u e s a tis fa c e la s n e c e s id a d e s d e la lo h e h e c h o e®rr««t*n»©*ii**? Lee
w a re lo c o n stru y e n , y v irtu a lm e n te g e n te q u e u s a r á el producto. D e b es el re sto d e e s te libro, se le c c io n a a q u e
c u a lq u ie r p e rso n a e n el m undo indus- a p lic a r u n e n fo q u e d e in g e n ie ría d e lla s id e a s q u e so n a p lic a b le s a l so ft
tr ia liia d o lo utiliza bien d ire c ta o in d i software. w a re q u e c o n stru y e s y a p líc a la s a tu
rectam ente. trabajo.
Cinco años después de que la cuarta edición de este libro fue escrita, el papel del software
com o «alm a mater» ha llegado a ser m ás obvio.Un director de software de Internet ha produ
cido su propia economía de 500 billones de Euros. En la euforia creada por la prom esa de un
paradigm a económ ico nuevo, los inversores de Wall Street dieron a las pequeñas em presas
«punto-com» estim aciones en billones de dólares antes de que éstas com enzasen a producir un
dólar en ventas. Han surgido nuevas industrias dirigidas por software y las antiguas que no se
han adaptado a esta nueva tendencia están ahora amenazadas de extinción. El gobierno de Esta
dos Unidos ha m antenido un contencioso frente a la m ayor com pañía de la industria del soft
ware, com o lo m antuvo hace poco tiem po cuando se m ovilizó para detener las actividades
m onopolísticas en las industrias del acero y del aceite.
El im pacto del software en nuestra sociedad y en la cultura continúa siendo profundo. Al
m ism o tiem po que crece su im portancia, la com unidad del software trata continuam ente de
desarrollar tecnologías que hagan m ás sencillo, rápido y m enos costosa la construcción de pro
gramas de com putadora de alta calidad.
www.FreeLibros.org
Este libro presenta un m arco de trabajo que puede ser usado por aquellos que construyen
software informático — aquellos que lo deben hacer bien— . La tecnología que com prende un
proceso, un juego de métodos y un conjunto de herram ientas se llam a ingeniería d e l software.
3
I N GE NIE RÍA DEL S O F TW A RE . UN EN F O Q U E P R A C T I C O
U . L A E lQ IIIg l& IL I ÜEUSSJEX W & BS

Hoy en día el software tiene un doble papel. Es un pro
ducto y, al m ism o tiempo, el vehículo para entregarlo. C ^ C /f o ;
Como producto, hace entrega de la potencia inform áti «. introduje en el futuro, más allá de lo que el ojo
ca que incorpora el hardware informático o, más am plia twm no puede ver. Tuve uno visión del mundo
mente, una red de com putadoras que es accesible por r todo lo maravilloso que podría ser.
hardware local. Si reside dentro de un teléfono celular
u opera dentro de una com putadora central, el softwa
re es un transform ador de inform ación, produciendo,
gestionando, adquiriendo, m odificando, m ostrando o las com putadoras y el software nos llevaran a la «dem o
transm itiendo inform ación que puede ser tan sim ple cratización del conocimiento». A Yourdon [YOU92] le
com o un solo bit, o tan complejo com o una presenta preocupaba que las com pañíasen Estados Unidos pudie
ción en multimedia. Como vehículo utilizado para hacer ran perder su com petitividad en em presas relativas al
entrega del producto, el software actúa como la base de software y predijo «el declive y la caída del program a
control de la com putadora (sistem as operativos), la dor am ericano». Hamm er y Champy [HAM93] argu
com unicación de información (redes) y la creación y m entaron que las tecnologías de inform ación iban a
control de otros program as (herram ientas de software desempeñar el papel principal en la «reingeniería de la
y entomos). compañía» .A mediados de los años 90, la persistencia de
las com putadorasy del software .generó una erupción de
libros por «neo-Luddites» (po r cj c m p 1o :R e.v/.sving the Vir
tual Life, editado por James Brook y Ian Boal, y TheFutu-
re Does not Compute de Stephen Talbot). Estos autores
Esoftware es tonto un producto, critican enormemente la computadora, haciendo énfasis
comoel vehículoporosu entrego en preocupaciones legítimas pero ignorando los profun
dos beneficios que se han llevado a cabo [LEV95],
El papel del software informático ha sufrido un cam
bio significativo durante un periodo de tiempo superior Q c f ta :
a 50 años. Enormes mejoras en rendim iento del hard los computadoras hacen las cosos más fáciles,
ware, profundos cambios de arquitecturas informáticas, p to lo mayoría de las cosas que facilitan no
grandes aumentos de m em oria y capacidad de alm ace es preciso hocedos.
nam iento y una gran variedad de opciones de entrada y Aarfy ItM M y
salida han conducido a sistemas más sofisticados y más
complejos basados en computadora. La sofisticación y Al final de los años 90, Yourdon [YOU96] volvió a
la com plejidad pueden producir resultados deslum evaluar las perspectivas del software profesional y sugi
brantes cuando un sistema tiene éxito, pero también pue rió la «resurrección y elevación» del program ador am e
den suponer grandes problemas para aquellos que deben ricano. A m edida que internet creció en im portancia, su
construir sistemas complejos. cambio de pensamiento demostró ser correcto. Al final
Libros populares publicados durante los años 70 y 80 del siglo veinte, el enfoque cambió una vez más. Aquí
proporcionan una visión histórica útil dentro de la per tuvo lugar el im pacto de la «bom ba de relojería» Y2K
cepción cambiante de las com putadoras y del software, (por ejemplo: [YOU98b], [DEJ98], [KAR99]). Aunque
y de su impacto en nuestra cultura. Osbom e [OSB79] m uchos vieron las predicciones de los críticos del Y2K
hablaba de una «nueva revolución industrial». Toffler como reacciones, sus populares lecturas devolvieron la
[TOF80] llamó a la llegada de componentes microelec- difusión del software a sus vidas. Hoy en día, «la com
trónicos la «tercera ola del cambio» en la historia de la putación omnipresente» [NOR98] ha producido una gene
humanidad, y Naisbitt [NAI82] predijo la transformación ración de aplicaciones de inform ación que tienen
de la sociedad industrial a una «sociedad de informa- conexión en banda ancha a la W eb para proporcionar
ción».Feigenbaum y McCorduck [FEI83] sugirieron que «una capa de conexión sobre nuestras casas, oficinas, y
la inform ación y el conocimiento (controladospor com autopistas» [LEV99], El papel del software continúa su
putadora) serían el foco de poder del siglo veintiuno, y expansión.
Stoll [ST089] argumentó que la «com unidad electróni El program ador solitario de antaño ha sido reem pla
ca» creada mediante redes y software es la clave para el zado por un equipo de especialistasdel software,cada uno
intercam bio de conocimiento alrededor del mundo. centradoen una parte de la tecnología requerida para entre
Al comienzo de los años 90, Toffler [TOF90] descri gar una aplicación concreta. Y de este modo, las cuestio
www.FreeLibros.org
bió un «cambio de poder» en el que las viejas estructu nes que se preguntaba el program ador solitario son las
ras de poder (gubernam entales,educativas, industriales, mismas cuestiones que nos preguntam os cuando cons
económicas y m ilitares) se desintegrarían a m edida que truimos sistemas modernos basados en computadoras:
4
C A PIT U L O 1 EL P R O D U C T O Y EL P R O C E S O
• ¿Por qué lleva tanto tiem po term inar los programas?

• ¿Por qué son tan elevados los costes de desarrollo?
• ¿Por qué no podem os encontrar todos los errores
antes de entregar el software a nuestros clientes?
• ¿Por qué nos resulta difícil constatar el progreso con
Estadísticas globales de software forme se desarrolla el software?
E L E EL..SO FTW A RE__________________

En 1970, m enos del uno por ciento de las personas Los costes del software se encuentran en la ingeniería.
podría haber descrito inteligentem ente lo que significa Esto significa que los proyectos de software no se pueden
ba «software de computadora». Hoy, la m ayoría de los gestionar como si fueran proyectos de fabricación.
profesionales y muchas personas en general piensan en
2. E l softw are no se «estropea».
su mayoría que comprenden el software. ¿Pero lo entien
den realmente? La Figura 1.1 describe, para el hardware, la proporción
de fallos como una función del tiempo. Esa relación, deno
m inada frecuentemente «curva de bañera», indica que el
12.1. C a r a c te r í s t i c a s d e l s o ftw a re hardware exhibe relativamente m uchos fallos al princi
Para poder com prender lo que es el softw are (y c o n pio de su vida (estos fallos son atribuibles normalmente
secuentemente la ingeniería del softw are), es im por a defectos del diseño o de la fabricación); una vez corre
tante exam inar las características del softw are que lo gidos los defectos, la tasa de fallos cae hasta un nivel esta
diferencian de otras cosas que los hom bres pueden cionario (bastantebajo, con un poco de optimismo) donde
construir. C uando se construye hardw are, el proceso perm anece durante un cierto periodo de tiem po. Sin
creativo hum ano (análisis, diseño, construcción, prue embargo, conforme pasa el tiempo, el hardware em pie
ba) se traduce finalmente en una form a física. Si cons za a desgastarse y la tasa de fallos se incrementa.
truim os una nu ev a com putadora, n u estro boceto El software no es susceptible a los males del entor
inicial, diagram as form ales de diseño y prototipo de no que hacen que el hardware se estropee. Por tanto, en
prueba, evolucionan hacia un producto físico (chips, teoría, la curva de fallos para el software tendría la for
tarjetas de circuitos im presos, fuentes de potencia, m a que m uestra la Figura 1.2.L os defectos no detecta
etc.). dos haran que falle el program a durante las prim eras
El softw are es un elem e n to del siste m a que es etapas de su vida. Sin embargo, una vez que se corri
lógico, en lugar de físico. Por tanto el softw are tie gen (suponiendo que no se introducen nuevos errores)
ne unas características considerablem ente distintas la curva se aplana, com o se m uestra. L a curva ideali
a las del hardw are: zada es una gran simplificación de los modelos reales
de fallos del softw are (vease m ás inform ación en el
Capítulo 8). Sin embargo la implicación es clara, el soft
ware no se estropea. ¡Pero se deteriora!
C ave
Elsoftware se desarrolla, no sefabrica.
1. El software se desarrolla, E¡software nose estropea, pero se deteriora.

no se fa b r ic a en un sentido clásico.
Aunque existen similitudes entre el desarrollo del soft
ware y la construcción del hardw are, am bas activida
des son fu n d am entalm ente diferentes. En am bas
actividades la buena calidad se adquiere m ediante un
buen diseño, pero la fase de construcción del h ard
ware puede introducir problem as de calidad que no
existen (o son fácilm ente corregibles) en el software.
Ambas actividades dependen de las personas, pero la
relación entre las personas dedicadas y el trabajo rea
lizado es com pletam ente diferente para el softw are
www.FreeLibros.org
(véase el C apítulo 7 ). A m bas actividades requieren
T ie m p o
la construcción de un «producto» pero los enfoques
son diferentes. F IG U R A 1.1. Curva de fallos del hardware.
5
IN GE NI E RÍ A DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
Esto que parece una contradicción, puede com pren A medida que la disciplina del software evoluciona, se
derse mejor considerando «la curva actual» m ostrada en crea un grupo de com ponentesde diseño estándar. Torni
la Figura 1.2. Durante su vida, el software sufre cambios llos estándar y circuitos integradospreparados para la ven
(mantenimiento). Conform e se hacen los cam bios, es ta son solamente los dos mil coinponentes estándar que
bastante probable que se introduzcan nuevos defectos, utilizan ingenieros m ecánicos y eléctricos cuando dise
haciendo que la curva de fallos tenga picos com o se ve ñan nuevos sistemas. Los componentes reutilizables se
en la Figura 1.2. Antes de que la curva pueda volver al han creado para que el ingeniero pueda concentrarse en
estado estacionario original, se solicita otro cam bio, elementos verdaderamente innovadores de un diseño, por
haciendo que de nuevo se cree otro pico. Lentamente, el ejemplo, las partes del diseño que representan algo nue
nivel m ínim o de fallos com ienza a crecer — el software vo. En el m undo del hardware, la reutilización de com
se va deteriorando debido a los cambios— . ponentes es una parte natural del proceso de ingeniería.
Otro aspecto de ese deterioro ilustra la diferencia entre En el mundo del software es algo que sólo ha com enza
el hardware y el software. Cuando un com ponente de do a lograrse en una escala amplia.
hardware se estropea se sustituyepor una pieza de repues El com ponente de softw are d eb ería diseñarse e
to. No hay piezas de repuesto para el software. Cada fallo im plem entarse para que pueda volver a ser reutiliza-
en el software indica un error en el diseño o en el proce do en m uchos program as diferentes. En los años 60,
so mediante el que se tradujo el diseño a código m áqui se construyeron bibliotecas de subrutinas científicas
na ejecutable. Por tanto, el mantenim iento del software reutilizables en una am plia serie de aplicaciones cien
tiene una com plejidad considerablemente m ayor que la tíficas y de ingeniería. Esas bibliotecas de subrutinas
del m antenim iento del hardware. reutilizaban de form a efectiva algoritm os bien d efi
nidos, pero tenían un dom inio de aplicación lim ita
3. Aunque la industria tiende a ensamblar com ponen do. Hoy en día, hem os ex tendido nuestra visión de
tes, la m ayoría del software se construye a medida. reutilización para abarcar no sólo los algorítm os, sino
C onsiderem os la form a en la que se diseña y se cons tam bién estructuras de datos. Los com ponentes re u
truye el hardw are de control para un producto b asa tilizables m odernos encapsulan tanto datos com o pro
do en com putadora. El ingeniero de diseño construye ceso s que se ap lica n a los d ato s, p e rm itie n d o al
un sen cillo esq u em a de la c irc u ite ría dig ital, hace ingeniero del softw are crear nuevas ap licacio n es a
algún análisis fundam ental para asegurar que se co n p a rtir de las p a rte s re u tilizab les. P or ejem p lo , las
sigue la función adecuada y va al arm ario donde se interfaces gráficas de usuario de hoy en día se co n s
encuentran los catálogos de com ponentes digitales. truyen frecuentem ente a partir de com ponentes re u
Después de seleccionar cada com ponente, puede soli tiliza b les que p erm iten la creació n de ventan as
citarse la compra. g rá fic a s, de m enús d e sp le g la b le s y de una am p lia
variedad de m ecanism os de interacción.
Incremento
C VE
La m a y a n del software sigue a c n s tq é rb s s a rrecfcfe.
1.2.2. A p lic a c io n e s d e l s o f tw a r e
El software puede aplicarse en cualquier situación en la
que se haya definido previam ente un conjunto especí
fico de pasos procedim entales (es decir, un algoritmo)
(excepciones notables a esta regla son el software de
los sistemas expertos y de redes neuronales). El conte
nido y el determ inism o de la inform ación son factores
Tiem po importantes a considerar para determ inar la naturaleza
de una aplicación de software. El contenido se refiere
F IG U R A 1 .2 . Curvas de fallos real e idealizada del software al significado y a la form a de la inform ación de entra
da y salida. Por ejem plo, muchas aplicaciones banca-
rias usan unos datos de entrada muy estructurados (una
base de datos) y producen «informes» con determ ina
dos formatos. El software que controla una m áquina
autom ática (por ejem plo: un control numérico) acepta
www.FreeLibros.org
los mébcfcsde rg e n e tb d e software se esfuerzan elementos de datos discretos con una estructura lim ita
para reducirla rra c p L d d e los paos y la Inclinación da y produce órdenes concretas para la máquina en rápi
déla curva (Fig. 1.2). da sucesión.
6
CAPÍTULO 1 EL P R O D U C T O Y EL P R O C E S O
Software de gestión. El proceso de la inform ación

I a revolución del software se fo to en el Capítulo 13. com ercial constituye la m ayor de las áreas de aplica
Lo ¡ngenleríade software basada en componentes ción del software. Los «sistemas» discretos (por ejem
se presento en el Capítulo27. plo: nóminas, cuentas de haberes-débitos, inventarios,
etc.) han evolucionado hacia el software de sistemas de
información de gestión (SIG) que accede a una o m ás
El deterninism o de ¡a información se refiere a la pre-
bases de datos que contienen inform ación com ercial.
decibilidad del orden y del tiem po de llegada de los
Las aplicaciones en esta área reestructuran los datos
datos. Un programa de análisis de ingeniería acepta datos
existentes para facilitar las operaciones com erciales o
que están en un orden predefinido, ejecuta el algorit-
gestionar la tom a de decisiones. Además de las tareas
mo(s) de análisis sin interrupción y produce los datos
convencionales de procesam ientos de datos, las aplica
resultantes en un informe o formato gráfico. Se dice que
ciones de software de gestión tam bién realizan cálculo
tales aplicaciones son determinadas. Un sistema opera
interactivo (por ejemplo: el procesam iento de transac
tivo multiusuario, por otra parte, acepta entradas que
ciones en puntos de ventas).
tienen un contenido variado y que se producen en ins
Softw are de ingeniería y científico. El software
tantes arbitrarios, ejecuta algoritm os que pueden ser
de ingeniería y científico está caracterizado p or los
interrumpidos por condiciones externas y produce una
algoritm os de «m anejo de núm eros». Las aplicacio
salida que depende de una función del entorno y del
nes van desde la astronom ía a la vulcanología, desde
tiempo. Las aplicaciones con estas características se dice
el análisis de la presión de los autom otores a la diná
que son indeterminadas.
m ica orbital de las lanzaderas espaciales y desde la
Algunas veces es difícil establecer categorías gené
biología m olecular a la fabricación autom ática. Sin
ricas para las aplicaciones del software que sean sig
em bargo, las nuevas aplicaciones del área de in g e
nificativas. C onform e aum enta la co m p lejid ad del
niería/ciencia se han alejado de los algoritm os co n
software, es m ás difícil establecer com partim entos
v en cio n ales num éricos. El diseño asistid o p o r
nítidamente separados. Las siguientes áreas del soft
com putadora (del inglés CA D ), la sim ulación de sis
ware indican la am plitud de las aplicaciones p o ten
tem as y otras aplicaciones interactivas, han co m en
ciales:
zado a coger características del softw are de tiem po
Software de sistem as. El software de sistemas es real e incluso del softw are de sistemas.
un conjunto de program as que han sido escritos para Software empotrado. Los productos inteligentes se
servir a otros programas. Algunos program as de siste han convertido en algo com ún en casi todos los m erca
mas (por ejemplo: compiladores, editores y utilidades dos de consumo e industriales. El software empotrado
de gestión de archivos) procesan estructuras de infor reside en m em oria de sólo lectura y se utiliza para con
mación complejas pero determinadas. Otras aplicacio trolar productos y sistemas de los mercados industria
nes de sistemas (por ejemplo: ciertos componentes del les y de consumo. El software empotrado puede ejecutar
sistema operativo, utilidades de manejo de periféricos,
fúncionesm uy limitadas y curiosas (por ejemplo: el con
procesadores de telecomunicaciones)procesan datos en
trol de las teclas de un hom o de m icroondas) o sum i
gran medida indeterminados. En cualquier caso, el área nistrar una función significativa y con capacidad de
del software de sistemas se caracteriza por una fuerte
control (por ejem plo: funciones digitales en un auto
interacción con el hardware de la computadora; una gran móvil, tales com o control de la gasolina, indicadores en
utilización por múltiples usuarios; una operación con
el salpicadero, sistemas de frenado, etc.).
currente que requiere una planificación, una com parti
ción de recursos y una sofisticada gestión de procesos;
unas estructuras de datos complejas y múltiples inter
faces externas.
Software de tiem po real. El software que coor Referencia W eb/ 5
dina/analiza/controla sucesos del m undo real conforme Se puede encontrar una de las mayores bibliotecas
ocurren, se denomina de tiem po real. Entre los elem en de sharewore/freeware en www.shareware.com
tos del software de tiem po real se incluyen: un com po
nente de adquisición de datos que recolecta y da formato
a la información recibida del entorno externo, un com Software de computadoras personales. El mercado
ponente de análisis que transfórm ala inform ación según del software de com putadoras personales ha germinado
lo requiera la aplicación,un componente de control/salida en las pasadas dos décadas. El procesam iento de tex
que responda al entorno externo, y un componente de tos, las hojas de cálculo, los gráficos por computadora,
monitorización que coordina todos los demás com po multimedia, entretenimientos,gestión de bases de datos,
nentes, de forma que pueda mantenerse la repuesta en
www.FreeLibros.org
aplicaciones financieras, de negocios y personales y
tiempo real (típicamente en el rango de un milisegundo redes o acceso a bases de datos extem as son algunas de
a un segundo). los cientos de aplicaciones.
7
IN GE NI E RÍ A DEL S O F TW A RE . UN EN F O Q U E P R Á C T I C O
S o ftw are b asad o en W e b . Las páginas Web busca Software de inteligencia artificial. El software de inte
das por un explorador son software que incorpora ins ligencia artificial (IA) hace uso de algoritmos no numéri
trucciones ejecutables (por ejemplo, CGI, HTML, Perl, cos para resolver problemas complejos para los que no son
o Java), y datos (por ejem plo, hipertexto y una varie adecuados el cálculo o el análisis directo. Los sistemas exper
dad de fonnatos de audio y visuales). En esencia, la red tos, también llamados sistemas basados en el conocimiento,
viene a ser una gran com putadora que proporciona un reconocimiento de patrones (imágenes y voz), redes neu-
recurso software casi ilimitado que puede ser accedido ronales artificiales, prueba de teoremas, y los juegos son
por cualquiera con un m odem . representativos de las aplicaciones de esta categoría.
M uchos observadores de la industria (incluyendo este computadoras, no ha habido ningún «puntocrucial», nin
autor) han caracterizado los problem as asociados con el gún «momento decisivo», solamente un lento cambio evo
desarrollo del software como una «crisis». M ás de unos lutivo, puntualizado por cambios tecnológicos explosivos
cuantos libros (por ejem plo: [GLA97], [F L 0 9 7 ], en las disciplinas relacionadas con el software.
[YOU98a]) han recogido el im pacto de algunos de los C ualquiera que busque la palabra crisis en el d ic
fallos mas importantes que ocurrieron durante la déca cionario encontrará otra definición: «el punto decisivo
da pasada. N o obstante, los mayores éxitos conseguidos en el curso de una enfermedad, cuando se ve m ás claro
por la industria del software han llevado a preguntarse si el paciente vivirá o m orirá». Esta definición puede
si el térm ino (crisis del software) es aún apropiado. darnos una pista sobre la verdadera naturaleza de los
Robert Glass, autor de varios libros sobre fallos del soft problem as que han acosado el desarrollo del software.
ware, representa a aquellos que han sufrido un cambio Lo que realm ente tenem os es una aflicción crónica'.
de pensamiento. Expone [GLA98]: «Puedo ver en mis La palabra aflicción se define como «algo que causa pena
ensayos históricos de fallos y en mis informes de excep o desastre». Pero la clave de nuestro argumento es la defi
ción, fallos importantes en m edio de m uchos éxitos, una nición del adjetivo crónica: «muy duradero o que reapa
copa que está [ahora] prácticam ente llena.» rece con frecuencia continuando indefinidamente». Es
bastante más preciso describir los problem as que hemos
Q p tía: estado aguantando en el negocio del software como una
aflicción crónica, en vez de como una crisis.
-llHJBysifa de los expertos están de acuerdo Sin tener en cuenta com o lo llamemos, el conjunto
'« R ip io manera más probable para que e! mundo de problem as encontrados en el desarrollo del software
se destruya es por occidente. Ahí es donde nosotros de com putadoras no se lim itan al software que «no fun
entremos; somos profesionales de lo informática, ciona correctam ente». Es m ás, el mal abarca los p ro
pwocomos occidentes. blem as asociados a cóm o desarrollar software, cóm o
-fh H L v rlri ímmsitm m antener el volum en cada vez m ayor de software exis
tente y cómo poder esperar m antenemos al corriente de
La palabra crisis se define en el diccionario Webster la dem anda creciente de software.
como «un punto decisivo en el curso de algo, momento, Vivimos con esta aflicción desde este día — de hecho,
etapa o evento decisivo o crucial». Sin embargo, en térm i la industria prospera a pesar de ello— . Y así, las cosas
nos de calidad del softwaretotal y de velocidad con la cual podrán ser m ejores si podem os encontrar y aplicar un
son desarrollados los productos y los sistemas basados en remedio.
1.4 M ITOS DEL SOFTW ARE________

M uchas de las causas de la crisis del software se pue confusión. Los mitos del software tienen varios atribu
den encontrar en una m itología que surge durante los tos que los hacen insidiosos: por ejemplo, aparecieron
prim eros años del desarrollo del software. A diferencia como declaraciones razonables de hechos (algunas veces
de los mitos antiguos, que a m enudo proporcionaban a conteniendo elementos verdaderos), tuvieron un senti
los hom bres lecciones dignas de tener en cuenta, los do intuitivo y frecuentemente fueron prom ulgados por
mitos del software propagaron inform ación errónea y expertos que «estaban al día».
www.FreeLibros.org
1 Esta terminología fue sugerida por el profesor Daniel Tiechrow de la
Universidad de Michigan en una conferencia impartida en Ginebra,
Suiza, Abril, 1989.
8
M itos de gestión. Los gestores con responsabilidad M itos del Cliente. Un cliente que solicita una apli
sobre el software, como los gestores en la m ayoría de cación de software puede ser una persona del despacho
las disciplinas, están norm alm ente bajo la presión de de al lado, un grupo técnico de la sala de abajo, el depar
cumplir los presupuestos,hacer que no se retrase el pro tam ento de ventas o una com pañía exterior que solicita
yecto y m ejorar la calidad. Igual que se agarra al vacío un software bajo contrato. En m uchos casos, el cliente
una persona que se ahoga, un gestor de software se aga cree en los m itos que existen sobre el software, debido a
rra frecuentemente a un m ito del software, aunque tal que los gestores y desarrolladoresdel software hacen muy
creencia sólo dism inuya la presión tem poralm ente. poco para corregir la m ala información. Los mitos con
Mito. Tenemos ya un libro que está lleno de estánda ducen a que el cliente se cree una falsa expectativay, final
res y procedimientos para construir software, ¿no le pro mente, quede insatisfecho con el que desarrolla el software.
porciona ya a mi gente todo lo que necesita saber? M ito. Una declaración general de los objetivos es sufi
Realidad. Está muy bien que el libro exista, pero ciente para com enzar a escribir los program as - p o d e
js e u sa?.¿conocen los trab a jad o res su ex istencia?, mos dar los detalles m ás adelante — .
jrefleja las prácticas m odernas de desarrollo de soft Realidad. U na m ala definición inicial es la principal
ware?, ¿es com pleto?, ¿está diseñado para m ejorar el causa del trabajo baldío en software. Es esencial una des
tiem po de entrega m ientras m antiene un enfoque de cripción formal y detalladadel ámbito de la información,
calidad? En m uchos casos, la respuesta a todas estas funciones, comportamiento, rendimiento, interfaces, liga
preguntas es «no». duras del diseño y criterios de validación. Estas caracte
rísticas pueden determ inarse sólo después de una
exhaustiva com unicación entre el cliente y el analista.
QpHa:
;£n ausencia de estándares significativos,
M ito . Los requisitos del proyecto cam bian co n ti
nuamente, pero los cambios pueden acomodarse fácil
« H nuevo industria como lo del software
mente, ya que el software es flexible.
-jasao depender de los costumbres.
.JtesO* Marco
liB fla iB g B T H S a
M ito. Mi gente dispone de las herram ientas de desa I a gestión y control de cambio está trotada
rrollo de software más avanzadas, después de todo, les con detalle en el CapRub 9
compramos las com putadoras m ás m odernas.
R ealidad. Se necesita m ucho m ás que el últim o
modelo de computadora grande o de PC para hacer desa
rrollo de software de gran calidad. Las herram ientas de
ingeniería del softw are asistida por com putadora
(CASE) son más importantes que el hardware para con
seguir buena calidad y productividad, aunque la m ayo
ría de los desarrolladores del software todavía no las
utilicen eficazm ente.
Mito. Si fallamos en la planificación, podemos añadir
más programadores y adelantar el tiempo perdido (el lla
mado algunas veces «conceptode la horda Mongoliana»). D efin ició n D es arro llo D esp u és
Realidad. El desarrollo de software no es un proce de la en tre g a
so mecánico como la fabricación. En palabras de Bro- F IG U R A 1 .3 . El im pacto del cambio.
oks [BR075]: «...añadir gente a un proyecto de software
retrasado lo retrasa aún más». Al principio, esta declara Realidad. Es verdad que los requisitos del softw a
ción puede parecer un contrasentido. Sin embargo, cuan re cambian, pero el impacto del cam bio varía según el
do se añaden nuevas personas, la necesidad de aprender y m om ento en que se introduzca. La Figura 1.3 ilustra el
comunicarse con el equipo puede y hace que se reduzca la im pacto de los cambios. Si se pone cuidado al dar la
cantidad de tiempo gastado en el desarrollo productivo. definición inicial, los cambios solicitados al principio
Puede añadirse gente, pero sólo de una manera planifica pueden acomodarse fácilmente. El cliente puede revi
da y bien coordinada. sar los requisitos y recom endar las modificaciones con
relativamente poco impacto en el coste. Cuando los cam
bios se solicitan durante el diseño del software, el impac
to en el coste crece rápidamente. Ya se han acordado los
recursos a utilizar y se ha establecido un m arco de tra
www.FreeLibros.org
la red de gestión de proyectos de software bajo del diseño. Los cambios pueden producir trastor
enwww.spmn.com puede ayudarle nos que requieran recursos adicionales e im portantes
a desmitificar estos y otros mitos. modificaciones del diseño; es decir, coste adicional. Los
9
in g e n ie r ía d e l s o f t w a r e . u n e n f o q u e p r á c t ic o
cambios en la función, rendimiento, interfaces u otras M ito. Hasta que no tengo el program a «ejecutándo
características,durante la im plementación (codificación se», realm ente no tengo forma de com probar su calidad.
y prueba) pueden tener un im pacto importante sobre el Realidad. Desde el principio del proyecto se puede
coste. Cuando se solicitan al final de un proyecto, los aplicar uno de los mecanismos más efectivos para garan
cam bios pueden producir un orden de m agnitud m ás tizar la calidad del software: la revisión técnicaform al.
caro que el m ism o cambio pedido al principio. La revisión del software (descrito en el Capítulo 8 ) es
M itos de los desarrolladores. Los mitos en los que un «filtro de calidad» que se ha com probado que es más
aún creen m uchos desarrolladores se han ido fom en efectivo que la prueba, para encontrar ciertas clases de
tando durante 50 años de cultura informática. Durante defectos en el software.
los prim eros días del desarrollo del software, la pro
M ito . Lo único que se entrega al term inar el p ro
gramación se veía com o un arte. Las viejas form as y
yecto es el program a funcionando.
actitudes tardan en morir.
Realidad. Un programa que funciona es sólo una par
M ito. Una vez que escribim os el program a y hace
te de una configuración del software que incluye muchos
mos que funcione, nuestro trabajo ha terminado.
elem entos. La docum entación proporciona el fun d a
Realidad. Alguien dijo una vez: «cuanto más pronto m ento para un buen desarrollo y, lo que es m ás im por
se comience a escribir código, más se tardará en term i tante, proporciona guías para la tarea de mantenimiento
narlo». Los datos industriales [LIE80, JON91, PUT97] del software.
indican que entre el 60 y el 80 por ciento de todo el
esfuerzo dedicado a un program a se realizará después M uchos profesionales del softw are reconocen la
de que se le haya entregado al cliente por prim era vez. falacia de los m itos descritos anteriorm ente. L am en
tablem ente, las actitudes y métodos habituales fom en
tan una pobre gestió n y m alas p rácticas técn icas,
incluso cuando la realidad dicta un m étodo mejor. El
Trabaja muy duro poro entenderlo que tienes que hacer reconocim iento de las realidades del softw are es el
antes de empezar. Noserias copoz de desarrollar codo prim er paso hacia la form ulación de soluciones prác
detalle; por más que sepas, tomo el menor riesgo. ticas para su desarrollo.
E E S U M £ fl___________________________
El softw are se ha convertido en el elem ento clave de ponen una configuración que se crea com o parte del
la evolución de los sistemas y productos informáticos. proceso de la ingeniería del software. El intento de la
En los pasados 5 0 años, el software ha pasado de ser ingeniería del software es proporcionar un m arco de
una resolución de problemas especializada y una herra trabajo para construir software con m ayor calidad.
m ienta de análisis de inform ación, a ser una industria
por sí misma. Pero la tem prana cultura e historia de la
«program ación» ha creado un conjunto de problem as
que persisten todavía hoy. El software se ha converti
do en un factor que lim ita la evolución de los sistemas Cuando te pones o pensar, no encuentras tiempo p a o la
informáticos. El software se com pone de program as, disciplino de lo Ingeniería del software, y te preguntas:
datos y documentos. Cada uno de estos elementos com- «¿ Tendré tiempo para poder hacerlo?»
„ Bl EB £B ¡I ---------------------------------------
[BR075] Brooks, F., TheMvticalMan-Month, Addison-Wes- [GLA97] Glass, R. L., Software Runaways, Prentice Hall,
ley, 1975. ' 1997.
[DEJ98] De Jager, P., et al, Countdown Y2K: Business Sur- [GLA98] Glass, R. L.,«Is there Really a Software Crisis?»,
viva! Planningfor tire Year2000, Wiley, 1998. IEEE Software, vol. 15,n.e 1, Enero 1998, pp. 104-105.
[DEM95] De Marco, T., Why Does Software CostSoM uch?, [HAM93] Hammer, M., y J. Champy,A<?<??7g7?7<?<?77?7g the Cor
DorsetHouse, 1995,p. 9. poration, HarpperCollins Publisher, 1993.
[FEI83] Feigenbaum, E. A., y P. McCorduck, The Fith Gene- [JON91] Jones, C., Applied Software Measurement,McGraw-
ration, Addison-Wesley, 1983. Hill, 1991.
www.FreeLibros.org
[FL097] Flowers, S., Software Failure, Management. Fai- [KAR99] Karlson, E., y J. Kolber, ,4 Basic lntroduction lo
lure-A m aicing Stories and C autionary Tails, Wiley, Y2K: How the Year2000 Computer Crisis Affects Yon?,
1997(7). ' ' Next Era Publications, Inc., 1999.
10
[LEV95] Levy, S., «The Luddites Are Yack»¡Newsweek, 12 de [ST089] Stoll, C., The cuckoo’s Egg, Doubleday, 1989.
Julio de 1995,p. 55. [TOF80] Toffler, A., The Third Wave, Morrow Publishers,
[LEV99] Levy, S., «The New Digital Galaxy», Newsweek, 1980.
31 de Mayo de 1999,p.57. . [TOF90] Toffler, A., Powershift, Bantam Publishers, 1990.
[LIE80] Lientz, B., y E. Swanson, Software Maintenance [YOU92] Yourdon, E., The Decline and Fall ofthe American
Management, Addison Wesley, 1980. Programmer, Yourdon Press, 1992.
[NAI82] Naisbitt, Y,M egatoends, Warner Books, 1982. [YOU96] Yourdon, E., TheRise and Resurrection ofthe Am e
[NOR98] Norman, D., The Invisible Computer,MYT Press, 1998. rican Programmer, Yourdon Press, 1996.
[OSB79] Osborne, A., Running Wild-The N ext Industrial [YOU98a] Yourdon, E., DeathMarch Projects, Prentice-Hall,
Revolution, Osbome/McGraw-Hill, 1979. 1998.
[PUT97] Putnam, L., y W. Myers, Industrial Strength Soft [YOU98b] Yourdon,E., y J. Yourdon, TimeBomb 2000.Pren-
ware, IEEE Computer Society Press, 1997. tice-Hall, 1998.
^M O B I-E M A S Y PU N TO S A C Ó H g l p H
1 .1 . El software es la característica que diferencia a muchos 1 .5 . A medida que el software se difunde más, los riesgos para
productos y sistemas informáticos. Dé ejemplos de dos o tres el público (debido a programas defectuosos) se convierten en una
productos y de, al menos, un sistema en el que el software, no preocupación cada vez más significativa. Desarrolle un escena
el hardware, sea el elemento diferenciador. rio realista del juicio final (distinto a Y2K) en donde el fallo de
computadorapodría hacer un gran daño (económico o humano).
1 .2 . En los años cincuenta y sesenta la programación de com
putadoras era un arte aprendido en un entorno básicamente 1 .6 . Lea detenidamente el grupo de noticias de Internet
experimental. ¿Cómo ha afectado esto a las prácticas de desa comp.risk y prepare un resumen de riesgos para las personas
rrollo del software hoy? con las que se hayan tratado Últimamente. Código alternati
vo: Software Engineering Notes publicado por la ACM.
1 .3 . Muchos autores han tratado el impacto de la «era de la
información».Dé varios ejemplos (positivos y negativos) que 1 .7 . Escriba un papel que resuma las ventajas recientes en
indiquen el impacto del software en nuestra sociedad. Repa una de las áreas de aplicaciones de software principales. Entre
se algunas referencias de la Sección 1.1 previas a 1990e indi las selecciones potenciales se incluyen: aplicaciones avanza
que dónde las predicciones del autor fueron correctas y dónde das basadas en Web, realidad virtual, redes neuronales artifi
no lo fueron. ciales, interfaces humanas avanzadas y agentes inteligentes.
1.4 . Seleccione una aplicación específica e indique: (a) la 1 .8 . Los mitos destacados en la Sección 1.4 se están vinien
categoría de la aplicación de software (Sección 1.2.2) en la do abajo lentamente a medida que pasan los años. Pero otros
que encaje; (b ) el contenido de los datos asociados con la apli se están haciendo un lugar. Intente añadir un mito o dos mitos
cación; (c) la información determinada de la aplicación. «nuevos» a cada categoría.
Literalmente existen miles de libros escritos sobre software do industrializado y casi todas las aplicaciones a la nueva
de computadora. La gran mayoría tratan los lenguajes de pro infraestructura de Internet.
gramación o aplicaciones de software, y sólo unos pocos tra Minasi (The Software Conspiracy: Why Software Com-
tan el software en sí. Pressman y Herron (Software Sock, panies Put Out Faulty Products, How They Can H urt You,
Dorset House, 1991) presentaron una discusión (dirigida a no and What Yon Can Do, McGraw-Hill, 2000) argumentó que
profesionales) acerca del software y del modo en que lo cons el «azote moderno» de los errores del software puede elim i
truyen los profesionales. narse y sugiere formas para hacerlo. DeMarco (Why Does
El libro, éxito de ventas, de Negroponte (BeingDigital, Software CostSoM uch?, Dorset House, 1995) ha producido
Alfred A. Knopf, Inc., 1995) proporciona una visión de las una colección de ensayos divertidos e interesantes sobre el
computadoras y de su impacto global en el siglo xxi. Los software y el proceso a través del cual se desarrolla.
libros de N orm an [NOR98] y Bergm an (Inform ation En Intemet están disponibles una gran variedad de fuen
Appliances & Beyond, Academic Pres/Morgan Kauffman, tes de información relacionadas con temas de gestión y de
2000) sugieren que el impacto extendido del PC declinará software. Se puede encontrar una lista actualizada con refe
al mismo tiempo que las aplicaciones de inform ación y rencias a sitios (páginas) web relevantes en http://www.press-
la difusión de la programación conecten a todos en el mun man5.com.
www.FreeLibros.org
CAPITULO
2 EL PR O C ESO
OW ARD Baetjer, Jr. [B A E98], en un libro fascinante que proporciona un punto de
H vista econom icista del softw are y de la ingeniería del softw are, com enta sobre el
proceso:
C om o el softw are, al igual que el capital, es el co n o cim ien to inco rp o rad o , y puesto que el c o nocim iento
e stá inicialm en te disperso, el desarro llo del softw are im p lícito , latente e inco m p leto e n g ran m edida, es un
proceso social de a p ren d iza je. E l p roceso es un d iálogo e n el que se reúne el co n o cim ien to y se incluye en
el softw are para co n v ertirse e n softw are. E l p roceso pro p o rcio n a una in te rac c ió n e n tre los usuarios y los
d iseñ ad o res, entre los usuarios y las h erram ien tas de d esarro llo , y e n tre los d iseñadores y las h e rra m ie n
tas de desarro llo [tecnología]. Es un p roceso in teractiv o donde la h erram ien ta de desarro llo se usa co m o
m edio de co m u n icació n , con cada ite rac ió n del d iá lo g o se o b tie n e m ayor con o cim ien to de las personas
involucradas.
Realmente, construir software de com putadora es un proceso de aprendizaje iterativo, y el

resultado, algo que Baetjer podría llam ar «capital del software», es el conjunto del software
reunido, denurado v orean izado m ientras se desarrolla el oroceso.
VISTAZO RÁPIDO
¿Qué es? C u a n d o tra b a ja p a ra c o nstruir ¿Por q u é e s im p o rta n te? P o rq u e pro softw are, los pro d u cto s o b te n id o s son
un p ro d u c to o u n s is te m a , e s im p o r p o rcio n a e sta b ilid a d , control y o rg a n i p ro g ram as, d o c u m e n to sy d a to s que se
ta n te s e g u ir u n a s e rie d e p a s o s p r e z a c ió n a u n a a c tiv id a d q u e p u e d e , si p ro d u c e n com o c o n s e c u e n c ia d e la s
d ecibles —un m a p a d e c a rre te ra s q u e no s e con tro la, volverse caótica. a c tiv id a d e s d e i n g e n ie ría d el softw are
le a y u d e a o b ten e r e l re su lta d o opor ¿Cuáles son los p asos? A u n nivel d e ta d e fin id a s por el proceso.
tuno d e c a l i d a d - . El m a p a d e c a r r e lla d o , e l p ro c e so q u e a d o p te m o s ¿Cómo p u e d o e s ta r se g u r o d e q u e
te ra s a s e g u ir e s lla m ad o «proceso del d e p e n d e d e l so ftw a re q u e e s ta m o s lo h e h e c h o c o r r e cta m e n te ? H ay
software.. c o n stru y e n d o . Un p ro c e so p u e d e se r u n a c a n tid a d d e m ec a n ism o s d e eva-
¿Quién lo h a c e ? Los i ngenieros d e soft a p ro p ia d o p a r a c re a r so ftw a re d e un lu a c io n d e l p roceso d e l so ftw a re q u e
w a re y sus g e sto re s a d a p ta n el proce siste m a d e a v ia c ió n , m ie n tra s q u e un p e rm ite n a la s o rg a n iz a c io n e s d e te r
so a sus n e c e s id a d e s y e n to n c e s lo p roceso diferen te por com pleto p u e d e m inar la «m adurez» d e su p roceso del
sig u en . A d em ás la s p e rso n a s q u e h a n se r a d e c u a d o p a r a la c re a c ió n d e un software. Sin em bargo, la c alidad, opor
solicitado el softw are tie n e n u n p a p e l sitio web. tu n id a d y v ia b ilid a d a larg o plazo d el
a d e s e m p e ñ a r e n el p ro c e so d e l soft ¿Cuál es e l p rod ucto ob ten id o? D es producto q ue e s tá construyendo son los
w are. d e el punto d e v ista d e u n ingeniero d e m ejores ind icad o res d e l a eficiencia del
p roceso q u e e stam o s utilizando.
Pero, ¿qué es exactamente el proceso del software desde un punto de vista técnico? Dentro del con
texto de este libro, definimos un proceso de software como un marco de trabajo de las tareas que se
requieren para construir software de alta calidad. ¿Es «proceso» sinónimo de ingeniería del softwa
re? La respuesta es «sí» y «no». Un proceso de software define el enfoque que se toma cuando el soft
ware es tratado por la ingeniería. Pero la ingeniería del software también comprende las tecnologías
que tiene el proceso — métodos técnicos y herramientas automatizadas— .
Aún más importante es que la ingeniería del software la realizan personas creativas, con conoci
miento, que deberían trabajar dentro de un proceso del software definido y avanzado que es apropia
www.FreeLibros.org
do para los productos que construyen y para las demandas de su mercado. La intención de este capítulo
es proporcionar un estudio del estado actual del proceso del software y puntualizar sobre el estudio
detallado de los temas de gestión y técnicos presentados en este libro.
13
IN GE NI ER ÍA DEL SO FTW AR E. UN E N F O Q U E P R AC T I C O
, ____ • . el 0 11 . . . . t e c b . tofiu \
Aunque cientos de autores han desarrollado definicio
nes personales de la ingeniería del software, una defi Harramteaf&g
nición propuesta por Fritz B auer [NAU69] en una
conferencia de gran influencia sobre estos tem as va a
servir como base de estudio:
F IG U R A 2 .1 . C apas de la in g e n ie ría del softw are.
El fundam ento de la ingeniería del softw are e s la

capa de proceso. El proceso de la ingeniería del soft
ware es la unión que mantiene juntas las capas de tec
nología y que permite un desarrollo racional y oportuno
de la ingeniería del software. El proceso define un m ar
[La ingeniería del software] es el establecimiento y uso de prin co de trabajo para un conjunto de Úreas clave de p r o
cipios robustos de la ingeniería a fin de obtener económicamente
ceso (ACPs) [PAU93] que se deben establecer para la
software que sea fiable y que funcione eficientemente sobre máqui
nas reales. entrega efectiva de la tecnología de la ingeniería del
software. Las áreas claves del proceso forman la base
C asi todos los lectores tendrán la ten tac ió n de del control de gestión de proyectos del software y esta
seguir esta definición. N o dice mucho sobre los aspec blecen el contexto en el que se aplican los m étodos téc
tos técnicos de la calidad del softw are; no se enfren nicos, se obtienen productos del trabajo (m odelos,
ta directamente con la necesidad de la satisfacción del documentos, datos, informes, formularios, etc.), se esta
cliente o de la entrega oportuna del producto; omite blecen hitos, se asegura la calidad y el cambio se ges
la m ención de la im portancia de m ediciones y m étri tiona adecuadamente.
cas; tam poco expresa la im portancia de un proceso Los m étodos de la ingeniería del software indican
avanzado. Y sin em bargo, la definición de B auer nos «cómo» construir técnicamente el software. Los m éto
proporciona una línea base. ¿Cuáles son los « p rin ci dos abarcan una gran gam a de tareas que incluyen aná
pios robustos de la ingeniería» aplicables al desarro lisis de requisitos, diseño, construcción de programas,
llo de software de com putadora? ¿Cómo construim os pruebas y mantenimiento. Los m étodos de la ingeniería
el software «económ icam ente»para que sea «fiable»? del software dependen de un conjunto de principios bási
¿Qué se necesita para crear program as de com puta cos que gobiernan cada área de la tecnología e incluyen
dora que funcionen «eficientemente» no en una m áqui actividades de m odelado y otras técnicas descriptivas.
na si no en diferentes «m áquinas reales» ? Éstas son
cuestiones que siguen siendo un reto para los inge
nieros del software.
C LA VE
I a hgenieráde software comprende un proceso,
¿Cómo definimos la
• Ingeniería del software?

mÉOdostéonoosy de gesfón, y henamerfes
Las herramientas de la Ingeniería del software pro

El IEEE [IEE93] ha desarrollado una definiciónm ás porcionan un enfoque automático o semi-automáticopara
completa: el proceso y para los métodos. Cuando se integran herra
Ingeniería del software: (1) La aplicación de un enfoque sis m ientas para que la información creada por una herra
temático, disciplinado y cuantificable hacia el desarrollo, opera m ienta la pueda utilizar otra, se establece un sistem a de
ción y mantenimiento del software; es decir, la aplicación de soporte para el desarrollo del software llamado ingenie
ingenieríaal software. (2) El estudio de enfoques como en (1). ría del software asistida p o r computadora (CASE).
2.1.1. P ro ceso , m é to d o s y h er r a m ie n ta s 2.1.2. U n a v is ió n g e n e r a l d e la in g e n ie r ía d e l

so ftw a re
La Ingeniería del software es un tecnología m ultica-
pa. Como m uestra la Figura 2.1, cualquier enfoque de La ingeniería es el análisis, diseño, construcción, veri
ingeniería (incluida ingeniería del software) debe apo ficación y gestión de entidades técnicas (o sociales).
www.FreeLibros.org
yarse sobre un com prom iso de organización de cali Con independencia de la entidad a la que se va a apli
dad. car ingeniería, se deben cuestionar y responder las
siguientes preguntas:
14
CAPITULO 2 EL P R O C E S O
¿Cuál es el problem a a resolver? Lafa s e de desarrollo se centra en el cómo. Es decir,

durante el desarrollo un ingeniero del software intenta
¿Cuáles son las características de la entidad que se
definir cóm o han de diseñarse las estructuras de datos,
utiliza para resolver el problema?
cóm o ha de im plem entarse la función dentro de una
¿Cómo se realizará la entidad (y la solución)? arquitectura de software, cóm o han de im plementarse
¿Cómo se construirá la entidad? los detalles procedim entales, cóm o han de caracteri
zarse interfaces, cóm o ha de traducirse el diseño en un
¿Qué enfoque se va a utilizar para no contem plar los
lenguaje de program ación (o lenguaje no procedim en-
errores que se com etieron en el diseño y en la cons
tal) y cómo ha de realizarse la prueba. Los métodos apli
trucción de la entidad?
cados durante la fase de desarrollo variarán, aunque las
¿Cómo se apoyará la entidad cuando usuarios soli tres tareas específicas técnicas deberían ocurrir siem
citen correcciones, adaptaciones y mejoras de la enti pre: diseño del software (Capítulos 14, 15y 21), gene
dad? ración de código y prueba del software (Capítulos 16,
17 y 22).
Referencia Q c
üosstolk es un periódico que proporciona consejos y B a ste argumentó que debe haber una explicación
comentarios prócticosde ingeniería del software. Estón ypfHkqdo de la naturaleza, porque Dios nc es
disponibles temas relacionados directamente en: caprichoso ni arbitrario. Esta fe no se ajusta al
www.stc.hill.af.mil
Gran parte de la complejidad que debe dominar es
A lo largo de este libro, nos vam os a ce n trar en
una sola entidad — el softw are de com putadora— .
Para construir la ingeniería del softw are adecuada
mente, se debe definir un proceso de d esarro llo de
software. En esta sección se consideran las caracte L afase de mantenimiento se centra en el cambio que
rísticas genéricas del proceso de softw are. M ás ade va asociado a la corrección de errores, a las adaptacio
lante, en este m ism o cap ítu lo , se trata rán m odelos nes requeridas a m edida que evoluciona el entorno del
específicos de procesos. software y a cambios debidos a las mejoras producidas
El trabajo que se asocia a la ingeniería del software por los requisitos cambiantes del cliente. Durante la fase
se puede dividir en tres fases genéricas, con indepen de m antenim iento se encuentran cuatro tipos de cam
dencia del área de aplicación, tam año o com plejidad del bios:
proyecto. Cada fase se encuentra con una o varias cues Corrección. Incluso llevando a cabo las mejores acti
tiones de las destacadas anteriormente. vidades de garantía de calidad, es muy probable que el
La fase de definición se centra sobre el qué. Es decir, cliente descubra los defectos en el software. El m ante
durante la definición, el que desarrolla el software inten nimiento correctivo cambia el software para corregir los
ta identificar qué inform ación ha de ser procesada, qué defectos.
función y rendim iento se desea, qué com portam iento A daptación. Con el paso del tiem po, es probable
del sistema, qué interfaces van a ser establecidas, qué que cam bie el entorno original (por ejemplo: CPU, el
restricciones de diseño existen, y qué criterios de vali sistem a operativo, las reglas de em presa, las caracte
dación se necesitan para definir un sistema correcto. Por rísticas externas de productos) para el que se desarro
tanto, han de identificarse los requisitos clave del siste lló el software. El m antenimiento adaptativo produce
ma y del software.Aunque los métodos aplicados duran m odificación en el software para acomodarlo a los cam
te la fase de definición variarán dependiendo del bios de su entorno externo.
paradigma de ingeniería del software (o combinación
M ejora. Conform e se utilice el software, el clien
de paradigmas) que se aplique, de alguna m anera ten
te/usuario puede descubrir funciones adicionales que
drán lugar tres tareas principales: ingeniería de sistemas
van a producir beneficios. El m antenimiento perfectivo
o de inform ación (Capítulo 10), planificación del pro
lleva al software m ás allá de sus requisitos funcionales
yecto del software (Capítulos 3, 5 ,6 y 7) y análisis de
originales.
los requisitos (Capítulos 11, 12 y 21).
Prevención. El software de com putadora se dete
riora debido al cambio, y por esto el mantenimiento pre
ventivo tam bién llamado reingeniería del software, se
debe conducir a perm itir que el software sirva para las
CLAVE necesidades de los usuarios finales. En esencia, el m an
www.FreeLibros.org
B software se crea aplicando tres fases distintas que se tenim iento preventivo hace cam bios en program as de
centran en la definición, desarrollo y mantenimiento. com putadora a fin de que se puedan corregir, adaptar y
m ejorar m ás fácilmente.
15
I N GEN IE RÍ A DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
Además de estas actividades de mantenim iento, los

usuarios de software requieren un mantenim iento con
tinuo. Los asistentes técnicos a distancia, teléfonos de
ayuday sitios Web de aplicaciones específicas se imple-
m entan frecuentemente com o parte de la fase de m an
tenim iento. Actividades de protección
Entre las actividades típicas de esta categoría se incluyen:
• Seguimiento y control del proyecto de software
Cuando utilizamos el térm ino«mantenimiento»
• Revisiones técnicas formales
reconocemos que es mucho más que una simple
corrección de errores. • Garantía de calidad del software
• Gestión de configuración del software
Hoy en día, el aum ento de los program as' legales
está forzando a muchas compañías a seguir estrategias « Preparación y producción de documentos
de reingeniería del software (Capítulo 30). En un sen • Gestión de reutilización
tido global, la reingeniería del software se considera a
• M ediciones
m enudo com o una parte de la reingeniería de procesos
comerciales [STA95], • Gestión de riesgos
Las fases y los pasos relacionados descritos en nues Las actividades de protección se aplican a lo largo
tra visión genérica de la ingeniería del software se com de todo el proceso del software y se tratan en las partes
plem entan con un núm ero de actividades protectoras. Segunda y Quinta del libro.
JLU IL.PHQ.C.&S.CLP.EL SQET.W&iRK

Un proceso de software se puede caracterizar como se del proyecto. Finalmente, las actividades de protección
m uestra en la Figura 2.2. Se establece un marco común — tales como garantía de calidad del software,gestión de
del proceso definiendo un pequeño núm ero de activida configuración del software y medición* — abarcan el
des del m arco de trabajo que son aplicables a todos los m odelo de procesos. Las actividades de protección son
proyectos del software, con independenciade su tamaño independientes de cualquier actividad del m arco de tra
o complejidad. Un número de conjuntos de tareas - c a d a bajo y aparecen durante todo el proceso.
uno es una colección de tareas de trabajo de ingeniería En los Últimos años, se ha hecho m ucho énfasis en
del software, hitos de proyectos, productos de trabajo, y la «m adurez del proceso». El Softw ateEngineeringlns-
puntos de garantía de calidad— que permiten que las acti titute (SEI)3 ha desarrollado un m odelo completo que
vidades del m arco de trabajo se adapten a las caracterís se basa en un conjunto de funciones de ingeniería del
ticas del proyecto del software y a los requisitos del equipo software que deberían estar presentes conforme orga
nizaciones alcanzan diferentes niveles de m adurez del
proceso. Para determ inar el estado actual de madurez
del proceso de una organización, el SEI utiliza un cues
Actividades del m arco de trabajo tionario de evaluación y un esquem a de cinco grados.
II Conjuntos de tareas
( m n s e / o^
Seleccione un marco de trabajo del proceso común que se

adecúe al producto, al personal y al proyecto.
El esquema de grados determ ina la conform idad con

un m odelo de capacidad de m adurez [PAU93] que defi
teílwdtws* de Pvetícción
ne las actividades clave que se requieren en los d ife
rentes niveles de m adurez del proceso. El enfoque del
F IG U R A 2 .2 . El proceso del software. SEI proporciona una m edida de la efectividad global de
www.FreeLibros.org
1 El térm ino «program as legales» es un eufem ism o para el software 2 Estos tem as se tratan con m ás detalle en capítulos posteriores.
antiguo, a m enudo diseñado y docum entado pobremente, que es crí 3 El autor se está refiriendo al SEI de la Cannegie Mellon University.
tico para el negocio y debe ser soportado durante algunos años.
16
CAPÍTULO 2 EL P R O C E S O
las prácticas de ingeniería del software de una com pa ción ha sido detallado y se hace cum plir por m edio de
ñía y establece cinco niveles de m adurez del proceso, procedimientos tales como auditorías. Este nivel es aquel
que se definen de la forma siguiente: en el que la m ayoría de los desarrolladores de softwa
Nivel 1: Inicial. El proceso del software se caracte re, pretenden conseguir con estándares com o el ISO
riza según el caso, y ocasionalmente incluso de form a 9001, y existen pocos casos de desarrolladores de soft
caótica. Se definen pocos procesos, y el éxito depende ware que superan este nivel.
del esfuerzo individual. El nivel 4 comprende el concepto de m edición y el
uso de métricas. El capítulo 4 describe este tema con más
Nivel 2: Repetible. Se establecen los procesos de
detalle. Sin em bargo,cabe destacarel conceptode métri
gestión del proyecto para hacer seguimiento del coste,
ca para com prenderla im portancia que tiene que el desa-
de la planificación y de la funcionalidad. Para repetir
rrollador del software alcance el nivel 4 o el nivel 5.
éxitos anteriores en proyectos con aplicaciones sim ila
Una m étrica es una cantidad insignificanteque puede
res se aplica la disciplina necesaria para el proceso.
extraerse de algún docum ento o código dentro de un pro
Nivel 3: Definido. El proceso del software de las yecto de software. Un ejemplo de m étrica es el número
actividades de gestión y de ingeniería se documenta, se de ramas condicionales en una sección de código de un
estandariza y se integra dentro de un proceso de soft programa. Esta m étrica es significativa en el sentido de
ware de toda una organización. Todos los proyectos uti que proporciona alguna indicación del esfuerzo necesa
lizan una versión docum entada y aprobada del proceso rio para probar el código: está directamente relacionado
de la organización para el desarrollo y mantenimiento con el núm ero de caminos de prueba dentro del código.
del software. En este nivel se incluyen todas las carac U na organización del nivel 4 m aneja num erosas
terísticas definidas para el nivel 2. métricas. Estas métricas se utilizan entonces para super
Nivel 4: G estionado. Se recopilan m edidas d eta visar y controlar un proyecto de software, por ejemplo:
lladas del proceso del software y de la calidad del pro
• Una métrica de prueba puede usarse para determ inar
ducto. M ediante la utilización de m edidas detalladas,
cuándo finalizar la prueba de un elem ento del código.
se com prenden y se controlan cuantitativam ente tan
to los productos com o el proceso del software. En este « Una m étrica de legilibilidad puede usarse para ju z
nivel se incluyen todas las características definidas gar la legilibilidad de algún docum ento en lenguaje
para el nivel 3. natural.
Nivel 5: Optimización. M ediante una retroalimen- • Una métrica de com prensión del program a puede uti
tación cuantitativa del proceso, ideasy tecnologías inno lizarse para proporcionar algún umbral num érico que
vadoras se posibilita una m ejora del proceso. En este los program adores no pueden cruzar.
nivel se incluyen todas las características definidas para
Para que estas métricas alcancen este nivel es nece
el nivel 4.
sario que todos los componentes del nivel 3 CM M , en
castellano M CM (M odelo de Capacidad de M adurez),
estén conseguidos, por ejem plo notaciones bien defini
i e f e f g n g i g Mfefe A das para actividades com o la especificación del diseño
de requisitos, por lo que estas métricas pueden ser fácil
BIIS ofrece un amplio conjunto de información
relacionadacon el proceso en www.sei.cmu.edu
m ente extraídas de m odo automático.
El nivel 5 es el nivel m ás alto a alcanzar. Hasta aho
Merece la pena destacar que cada nivel superior es ra, muy pocos desarrolladores de software han alcan
la suma de los niveles anteriores, por ejemplo, un desa- zado esta fase. Representa la analogía del software con
rrolladorde software en el nivel 3 tiene que haber alcan los m ecanism os de control de calidad que existen en
zado el estado nivel 2 para poder disponer de sus otras industrias de m ayor madurez. Por ejemplo el fabri
procesos en el nivel 3. cante de un producto industrial com o un cojinete de
El nivel 1 representa una situación sin ningún esfuer bolas (rodamiento) puede supervisar y controlar la cali
zo en la garantía de calidad y gestión del proyecto, don dad de los rodamientos producidosy puede predecir esta
de cada equipo del proyecto puede desarrollar software calidad basándose en los procesos y máquinas utiliza
de cualquier forma eligiendo los métodos, estándares y dos para desarrollar los rodamientos. Del m ism o m odo
procedim ientos a utilizar que podrán variar desde lo que el desarrollador del sofware en el nivel 5 puede pre
mejor hasta lo peor. decir resultados com o el número de errores latentes en
El nivel 2 representa el hecho de que un desarrollaun producto basado en la m edición tom ada durante la
dor de software ha definido ciertas actividades tales ejecución de un proyecto. Además, dicho desarrollador
como el informe del esfuerzo y del tiem po empleado, y puede cuantificar el efecto que un proceso nuevo o herra
el informe de las tareas realizadas. m ienta de m anufacturación ha tenido en un proyecto
www.FreeLibros.org
El nivel 3 representa el hecho de que un desarrolla- examinando métricas para ese proyecto y com parándo
dcr de software ha definido tanto procesos técnicos como las con proyectos anteriores que no utilizaron ese pro
de gestión, por ejemplo un estándar para la program a ceso o herramienta.
17
i n g e n i e r í a del s o f t w a r e , u n e n f o q u e p r á c t i c o
En este orden debe destacarse que para que un desa-

rrollador de software alcance el nivel 5 tiene que tener
cada proceso definido rigurosam ente y seguirlo al pie
de la letra; esto es una co n secu en cia de estar en el
Referencia
nivel 3. Si el desarrollador del software no tiene defi Una versión tabular del MCM completo del US, Incluyendo
todos ios objetivos, comentarlos, habilidades y
nidos rigurosam ente los procesos pueden ocurrir una
actividades está disponible en
gran cantidad de cam bios en el proceso de desarrollo
sepo.nosc.mil/CMMmatrices.html
y no se podrán utilizar las estadísticas para estas acti
vidades.
Los cinco niveles definidos por el SEI se obtienen m adurez y se distribuyen en niveles diferentes de m adu
como consecuencia de evaluar las respuestas del cues rez del proceso. Las ACPs se deberían lograr en cada
tionario de evaluación basado en el M CM (M odelo de nivel de m adurez de proceso4:
capacidad de madurez). Los resultados del cuestiona N ivel 2 de M adurez del Proceso
rio se refinan en un único grado num érico que propor
• Gestión de configuración del software
ciona una indicación de la m adurez del proceso de una
organización. • Garantía de calidad del software
E1 SEI ha aso c ia d o áreas claves del proceso • Gestión de subcontratación del software
(A C Ps) a cad a uno de los niveles de m adurez. Las • Seguimiento y supervisión del proyecto del software
AC Ps describen esas funciones de la ingeniería del
• Planificación del proyecto del software
softw are (por ejem plo: planificación del proyecto de
so ftw are, g estió n de re q u isito s) que se deben p re • Gestión de requisitos
sentar para satisfacer una buena práctica a un nivel N ivel 3 de M adurez del Proceso
en particular. C ada A CP se describe identificando las
• Revisiones periódicas
características siguientes:
• Coordinación entre grupos
• Ingeniería de productos de software
lodo organización deberlo esforzarse p ro alcanzar

• Gestión de integración del software
lo profundidad del MCM delllS. Sin embargo, • Programa de formación
lo implementación de cualquier aspech del modelo • Definición del proceso de la organización
puede eliminarse en su situación.
• Enfoque del proceso de la organización
• Objetivos— los objetivos globales que debe alcan N ivel 4 de M adurez del Proceso
zar la ACP • Gestión de calidad del software
• Compromisos— requisitos (impuestos en la organi • Gestión cuantitativa del proceso
zación) que se deben cum plir para lograr los objeti
N ivel 5 de M adurez del Proceso
vos y que proporcionan una prueba del intento por
ajustarse a los objetivos. • Gestión de cambios del proceso
• Capacidades — aquellos elementos que deben encon • Gestión de cambios de tecnología
trarse (organizacional y técnicam ente) para permitir • Prevención de defectos
que la organización cum pla los objetivos.
• Actividades — las tareas específicas que se requieren C ada una de las ACPs se definen con un conjunto
para lograr la función ACP. de prácticas clave que contribuyen a cum plir estos obje
tivos. Las prácticas clave son normas, procedim ientos
• M éto d o s p a r a supervisar la implementación — la
y actividades que deben ocurrir antes de que se haya
m anera en que las actividades son supervisadas con
instituido com pletam ente un área clave de proceso. El
forme se aplican.
SEI define a los indicadores clave como «aquellas prác
• M étodos p a ra verificar la implementución — l a forma ticas clave o com ponentes de prácticas clave que ofre
en que se puede verificar la práctica adecuada para cen una visión m ejor para lograr los objetivos de un
la ACP. área clave de proceso». Las cuestiones de valoración
Se definen dieciocho ACPs (descritas m ediante la se diseñan para averiguar la existencia (o falta) de un
estructura destacada anteriorm ente) en el m odelo de indicador clave.
www.FreeLibros.org
4 T éngase en cuenta que las ACPs son acum ulativas. Por ejem plo, el
nivel 3 de m adurez del proceso contiene todas las ACPs del nivel 2
m ás las d estacadas para el nivel 1.
18
2.3 MQDELQ S..EE PROCESO DEL SOFTWARE

Para resolver los problemas reales de una industria, un completo, las etapas descritas anteriormente se aplican
ingeniero del software o un equipo de ingenieros debe recursivam ente a las necesidades del usuario y a la espe
incorporar una estrategia de desarrollo que acompañe cificación técnica del desarrollador del software.
al proceso, métodos y capas de herram ientas descritos
en la Sección 2.1.1 y las fases genéricas discutidas en
la Sección 2.1.2. E sta estrategia a m enudo se llam a
modelo de proceso oparadigm a de ingeniería del soft
CLA V E
ware. Se selecciona un m odelo de proceso para la inge Todas las etapas de un proceso del software - e s t a d o
niería del software según la naturaleza del proyecto y actual, definición del problema, desarrollo técnico e
de la aplicación, los métodos y las herram ientas a utili Integración de la solución— coexisten simultáneamente
en algún nivel de detalle.
zarse, y los controles y entregas que se requieren. En
un docum ento intrigante sobre la naturaleza del proce
so del software, L.B.S. Raccoon [RAC95] utiliza frac- En las secciones siguientes, se tratan diferentes mode
tales como base de estudio de la verdadera naturaleza los de procesos para la ingeniería del software. C ada
del proceso del software. una representa un intento de ordenar una actividad inhe
rentem ente caótica. E s im portante recordar que cada
uno de los modelos se han caracterizado de form a que
ayuden (con esperanza) al control y a la coordinación
de un proyecto de software real. Y a pesar de eso, en el
fondo, todos los m odelos exhiben características del
«M odelo del Caos».
Todo el desarrollo del software se puede caracteri

zar como bucle de resolución de problem as (Fig. 2.3a)
en el que se encuentran cuatro etapas distintas: «status
quo», definición de problem as, desarrollo técnico e inte
gración de soluciones. Status quo «representa el estado
actual de sucesos» [RAC95]; la definición de proble
mas identifica el problem a específico a resolverse; el
desarrollo técnico resuelve el problem a a través de la
aplicación de alguna tecnologíay la integración de solu
ciones ofrece los resultados (por ejemplo: documentos,
programas, datos, nueva función comercial, nuevo pro
ducto) a los que solicitan la solución en prim er lugar. (a)
Las fases y los pasos genéricos de ingeniería del soft
ware definidos en la Sección 2.1.2 se divide fácilm en
te en estas etapas. >
En realidad, es difícil com partim entar actividades de
manera tan nítida com o la Figura 2.3.b da a entender,
porque existen interferencias entre las etapas. Aunque
esta visión sim plificada lleva a una idea muy im por
tante: con independencia del m odelo de proceso que se
seleccione para un proyecto de software, todas las eta
pas - s t a t u s quo, definición de problem as, desarrollo
técnico e integración de so lu c io n e s-c o e x iste n sim ul
táneamente en algún nivel de detalle. Dada la naturale
za recursiva de la Figura 2.3b, las cuatro etapas tratadas
anteriormente se aplican igualmente al análisis de una
aplicación com pleta y a la generación de un pequeño
segmento de código.
Raccoon [RAC95] sugiere un «M odelo del Caos»
www.FreeLibros.org
que describe el «desarrollodel software como una exten F IG U R A 2 .3 . a) Las fases de un bucle de resolución de pro
sión desde el usuario hasta el desarrollador y la tecno blemas [RAC951. b) Fasesdentro de lasfases
logía». Conform e progresa el trabajo hacia un sistema del bucle de resolución de problem as [RAC 95].
19
IN G E N IE R ÍA DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
2.4 E L MODELO LINEAL SEC U EN C I

Llamado algunas veces «ciclo de vida básico» o «mode se pueda evaluar su calidad antes de que com ience la
lo en cascada», el modelo lineal secuencial sugiere un codificación.
enfoque5 sistemático, secuencial, para el desarrollo del Generación de código. El diseño se debe traducir
software que com ienza en un nivel de sistemas y pro en una form a legible por la máquina. El paso de gene
gresa con el análisis, diseño, codificación, pruebas y man ración de código lleva a cabo esta tarea. Si se lleva a
tenim iento. La Figura 2.4 m uestra el m odelo lineal cabo el diseño de una form a detallada, la generación de
secuencial para la ingeniería del software. M odelado código se realiza mecánicamente.
según el ciclo de ingeniería convencional, el m odelo
lineal secuencial comprende las siguientes actividades:
Ingeniería y modelado de Sistemas/Información.
C om o el software siem pre form a parte de un sistema Aunque el modelo lineal es a menudo denominado
m ás grande (o empresa), el trabajo com ienza estable «modelo tradicional», resulto un enfoque razonable
cuando los requisitosse han entendido correctomente.
ciendo requisitos de todos los elementos del sistema y
asignando al software algún subgrupo de estos requisi
tos. Esta visión del sistema es esencial cuando el soft P ruebas. U na vez que se ha generado el código,
ware se debe interconectar con otros elementos como comienzan las pruebas del programa. El proceso de prue
hardware, personas y bases de datos. La ingeniería y el bas se centra en los procesos lógicos internos del soft
análisis de sistem as com prende los requisitos que se w are, asegurando que todas las sentencias se han
recogen en el nivel del sistema con una pequeña parte comprobado, y en los procesos externos funcionales; es
de análisis y de diseño. La ingeniería de información decir, realizar las pruebas para la detección de errores
abarca los requisitos que se recogen en el nivel de y asegurar que la entrada definida produce resultados
em presa estratégico y en el nivel del área de negocio. reales de acuerdo con los resultados requeridos.
M antenimiento. El software indudablemente sufrirá
cambios después de ser entregado al cliente (una excep
ción posible es el software empotrado). Se producirán
' In g e n ie ría d e ' cambios porque se han encontrado errores, porque el soft
s is te m a s /in fo rm a c ió n ware debe adaptarse para acoplarse a los cambios de su
entorno externo (por ejemplo: se requiere un cambio debi
A n á lis is D is e ñ o C ó d ig o P ru e b a do a un sistem a operativo o dispositivo periférico nue
vo), o porque el cliente requiere mejoras funcionales o
de rendimiento. El soporte y m antenim iento del softwa
re vuelve a aplicar cada una de las fases precedentes a un
program a ya existente y no a uno nuevo.
F IG U R A 2 .4 . El m odelo lineal secuencial.
El m odelo lineal secuencial es el paradigma más anti
guo y más extensamente utilizado en la ingeniería del
Análisis de los requisitos del software. El proceso software. Sin embargo, la crítica del paradigm a ha pues
de reunión de requisitos se intensifica y se centra espe to en duda su eficacia [HAN95], Entre los problemas
cialmente en el software. Para com prender la naturaleza que se encuentran algunas veces en el m odelo lineal
del (los) programa(s) a construirse, el ingeniero («ana secuencial se incluyen:
lista») del software debe com prender el dom inio de
información del software (descrito en el Capítulo 11), así ¿Por qué falla algunas veces
como la función requerida, comportamiento,rendimien-
to e interconexión.
Diseño. El diseño del software es realm ente un pro
§ el modelo lineal?
ceso de m uchos pasos que se centra en cuatro atributos 1. Los proyectos reales raras veces siguen el modelo
distintos de program a: estructura de datos, arquitectu secuencial que propone el modelo. Aunque el modelo
ra de software, representaciones de interfaz y detalle lineal puede acoplar interacción, lo hace indirecta
procedim ental (algoritmo). El proceso del diseño tra mente. Como resultado, los cambios pueden causar
duce requisitos en una representación del software donde confusión cuando el equipo del proyecto comienza.
www.FreeLibros.org
5 Aunque el modelo original en cascada propuesto por W inston Royce
[ROY70] hacía provisiones para «bucles de realim entación», la gran
m ayoría de las organizaciones que aplican este m odelo de proceso
lo hacen com o si fuera estrictam ente lineal.
20
2. A menudo es difícil que el cliente exponga explíci C ada uno de estos errores es real. Sin em bargo, el
tamente todos los requisitos. El m odelo lineal secuen- paradigm a del ciclo de vida clásico tiene un lugar defi
cial lo requiere y tiene dificultades a la hora de nido e im portante en el trabajo de la ingeniería del soft
acomodar la incertidumbre natural al com ienzo de ware. Proporciona una plantilla en la que se encuentran
muchos proyectos. métodos para análisis, diseño, codificación, pruebas y
3. El cliente debe tener paciencia. U na versión de tra m antenimiento. El ciclo de vida clásico sigue siendo el
bajo del (los) programa(s) no estará disponible hasta m odelo de proceso más extensamente utilizado por la
que el proyecto esté muy avanzado. Un grave error ingeniería del software. Pese a tener debilidades, es sig
puede ser desastroso si no se detecta hasta que se nificativamente m ejor que un enfoque hecho al azar para
revisa el programa. el desarrollo del software.
*. i :*Q . . ¿ - ¿ .C .Q flS l, ¡QQlORi. l l JX O U P Q JS
Un cliente, a m enudo, define un conjunto de objetivos

generales para el software, pero no identifica los requi
sitos detallados de entrada, proceso o salida. En otros
casos, el responsable del desarrollo del software puede
no estar seguro de la eficacia de un algoritmo, de la capa
cidad de adaptación de un sistema operativo, o de la for
ma en que debería tom arse la interacción hom bre-
máquina. En estas y en otras m uchas situaciones, un
paradigma de construcción de prototipos puede ofre
cer el mejor enfoque.
E1 paradigm a de construcción de prototipos (Fig.
2.5) comienza con la recolección de requisitos. El desa-
rrollador y el cliente encuentran y definen los objeti
vos globales para el software, identifican los requisitos
conocidos y las áreas del esquem a en donde es obli
gatoria m ás definición. Entonces aparece un «diseño
rápido». El diseño rápido se centra en una representa
ción de esos aspectos del software que serán visibles Pero ¿qué hacem os con el prototipo una vez que ha
para el usuario/cliente (por ejemplo: enfoques de entra servidopara el propósito descrito anteriorm ente?Brooks
da y formatos de salida). El diseño rápido lleva a la [BR075] proporciona una respuesta:
construcción de un prototipo. El prototipo lo evalúa el
cliente/usuario y se utiliza para refinar los requisitos En la mayoría de los proyectos, el primer sistema construido
del software a desarrollar. La iteración ocurre cuando apenas se puede utilizar. Puede ser demasiado lento, demasiado
grande o torpe en su uso, o las tres a la vez. N o hay otra alterna
el prototipo se pone a punto para satisfacer las nece
tiva que comenzar de nuevo, aunque nos duela pero es más inte
sidades del cliente, perm itiendo al m ism o tiem po que ligente, y construir una versión rediseñada en la que se resuelvan
el desarrollador com prenda m ejor lo que se necesita estos problemas ... Cuando se utiliza un concepto nuevo de siste
hacer. ma o una tecnología nueva, se tiene que construir un sistema que
no sirva y se tenga que tirar, porque incluso la mejor planificación
no es omnisciente como para que esté perfecta la primera vez. Por
lo tanto la pregunta de la gestión n o es si construir un sistema pilo
to y tirarlo. Tendremos que hacerlo. La Única pregunta es si pla
Cuondo el cliente tiene uno necesidad legítimo, nificar de antemano construir un desechable, o prometer
pero está desorientado sóbrelos detalles, entregárselo a los clientes...
el primer poso es desarrollar un prototipo.
El prototipo puede servir com o «prim er sistema».
El que Brooks recom ienda tirar. Aunque esta puede ser
Lo ideal sería que el prototipo sirviera como un meca una visión idealizada. Es verdad que a los clientes y a
nismo para identificar los requisitos del software. Si se los que desarrollan les gu sta el paradigm a de co n s
construye un prototipo de trabajo, el desarrollador inten trucción de prototipos. A los usuarios les gusta el sis
ta hacer uso de los fragm entos del program a ya exis tem a real y a los que desarrollan les gusta construir algo
www.FreeLibros.org
tentes o aplica herram ientas (por ejem plo: generadores inmediatamente. Sin em bargo, la construcción de pro
de informes, gestores de ventanas, etc.) que permiten totipos tam bién puede ser problem ática por las siguien
generar rápidamente program as de trabajo. tes razones:
21
IN GE NI E RÍ A DEL SOF TW ARE . UN EN F O Q U E P R Á C T I C O
1. El cliente ve lo que parece ser una versión de trabajo para dem ostrar la capacidad. D espués de algún
del software, sin tener conocimiento de que el pro tiempo, el desarrollador debe familiarizarse con estas
totipo tam bién estájunto con «el chicle y el cable de selecciones, y olvidarse de las razones por las que
em balar», sin saber que con la prisa de hacer que son inadecuadas. La selección m enos ideal ahora es
funcione no se ha tenido en cuenta la calidad del soft una parte integral del sistema.
ware global o la facilidad de mantenim iento a largo
plazo. Cuando se informa de que el producto se debe
construir otra vez para que se puedan m antener los
niveles altos de calidad, el cliente no lo entiende y Resisto lopresión de ofrecer un mal prototipo en el
pide que se apliquen «unos pequeños ajustes» para producto final. Como resaltado, hcoüdod se resiente casi
siempre.
que se pueda hacer del prototipo un producto final.
De form a dem asiado frecuente la gestión de desa
rrollo del software es muy lenta. Aunque pueden surgir problem as, la construcción de
2. El desarrollador, a m enudo, hace com prom isos de prototipos puede ser un paradigm a efectivo para la inge
implementación para hacer que el prototipo funcione niería del software. La clave es definirlas reglas del ju e
rápidamente. Se puede utilizar un sistema operativo go al comienzo; es decir, el cliente y el desarrollador se
o lenguaje de programación inadecuado simplemente deben poner de acuerdo en que el prototipo se constru
porque está disponible y porque es conocido; un algo ya para servir com o un m ecanism o de definición de
ritm o eficiente se puede im plementar simplemente requisitos.
El Desarrollo Rápido de Aplicaciones (DRAés un mode Generación de aplicaciones. El DRA asume la uti
lo de proceso del desarrollo del software lineal secuencial lización de técnicas de cuarta generación (Sección 2.10).
que enfatiza un ciclo de desarrollo extremadamente cor En lugar de crear software con lenguajes de program a
to. El modelo DRA es una adaptación a «alta velocidad» ción de tercera generación, el proceso DRA trabaja para
del modelo lineal secuencial en el que se logra el desa volver a utilizar com ponentes de program as ya exis
rrollo rápido utilizando una construcción basada en com tentes (cuando es posible) o a crear componentes reuti-
ponentes. Si se comprenden bien los requisitos y se limita lizables (cuando sea necesario). En todos los casos se
el ámbito del proyecto, el proceso DRA permite al equi utilizan herram ientas para facilitar la construcción del
po de desarrollo crear un «sistema completam ente fun software.
cional» dentro de períodos cortos de tiempo (por ejemplo:
de 60 a 90 días) [MAR91], Cuando se utiliza principal
mente para aplicaciones de sistemas de información, el Equipo ne 3
Equipo ne 2
enfoque DRA comprende las siguientes fases [KER94]:
M odelado
Modelado de Gestión. El flujo de información entre Equipo ns 1 d egestión
las funciones de gestión se m odela de forma que res

ponda a las siguientes preguntas: ¿Qué información con M odelado M odelado
duce el proceso de gestión? ¿Qué información se genera? de gestión de datos
¿Quién la genera? ¿A dónde va la información? ¿Quién EL

zz.
la procesa? El m odelado de gestión se describe con más M odelado
de procesos
detalle en el Capítulo 10. M odelado
de datos
Modelado de datos. El flujo de información defini G eneración
LL
de
do como parte de la fase de m odelado de gestión se refi aplicacionei
na como un conjunto de objetos de datos necesariospara Modelado

de procesos Pruebas
apoyar la em presa. Se definen las características (lla y entrega
m adas atributos) de cada uno de los objetos y las rela
ciones entre estos objetos. El m odelado de datos se trata
Generación
en el Capítulo 12.
Modelado del proceso. Los objetos de datos defi aplicaciones
nidos en la fase de m odelado de datos quedan transfor
mados para lograr el flujo de información necesariopara Pruebas
im plem entar una función de gestión. Las descripciones y entrega
del proceso se crean para añadir, modificar, suprimir, o
www.FreeLibros.org
recuperar un objeto de datos. -6 0 -9 0 d ía s -
' En ingles: RAD (Rapid Application Deveiopm ent) F IG U R A 2 .6 .E I m odelo DRA.
22
P ruebas y e n tre g a. Como el proceso DRA enfati Al igual que todos los modelos de proceso, el enfo
za la reutilización, ya se han com probado m uchos de que DRA tiene inconvenientes [BUT94]:
los componentes de los programas. Esto reduce tiempo • Para proyectos grandes aunque por escalas, el DRA
de pruebas. Sin embargo, se deben probar todos los com requiere recursos hum anos suficientes com o para
ponentes nuevos y se deben ejercitar todas las interfa crear el núm ero correcto de equipos DRA .
ces a fondo. • DRA requiere clientes y desarrolladores com pro
m etidos en las rápidas actividades necesarias para
c a a m m com pletar un sistema en un m arco de tiem po abre
EDRAhoce unfuerte uso de componentes
viado. Si no hay com prom iso por ninguna de las par
tes constituyentes, los proyectos DRA fracasarán.
desarrollo de componentes, véase el Copftulo 27.
• N o todos los tipos de aplicaciones son apropiados
para D R A . S i un sistem a no se puede m odularizar
adecuadamente, la construcción de los componentes
El m odelo de proceso DRA se ilustra en la Figura
necesarios para DRA será problemático. Si. está en
2.6. Obviamente, las limitaciones de tiem po impuestas
juego el alto rendimiento, y se va a conseguir el ren
en un proyecto DRA dem andan «ám bito en escalas»
dimiento convirtiendo interfaces en componentes de
[KER94], Si una aplicación de gestión puede m odular
sistemas, el enfoque DRA puede que no funcione.
se de forma que perm ita com pletarse cada una de las
funciones principales en menos de tres meses (utilizando • DRA no es adecuado cuando los riesgos técnicos son
el enfoque descrito anteriormente), es un candidato del altos. Esto ocurre cuando una nueva aplicación hace
DRA. Cada una de las funciones pueden ser afrontadas uso de tecnologías nuevas, o cuando el softw are
pcr un equipo DRA separado y ser integradas en un solo nuevo requiere un alto grado de interoperatividad
conjunto. con program as de com putadora ya existentes.
Se reconoce que el software, al igual que todos los sis 2.7.1. El m o d e lo in c r e m e n ta l

temas complejos, evoluciona con el tiem po [GIL88], El modelo incrernental com bina elementos del m odelo
Los requisitos de gestión y de productos a m enudo cam lineal secuencial (aplicados repetidam ente) con la filo
bian conforme a que el desarrollo proceda haciendo que sofía interactiva de construcción de prototipos. Com o
el camino que lleva al producto final no sea real; las m uestra la Figura 2.7, el m odelo increm ental aplica
estrictas fechas tope del m ercado hacen que sea im po secuencias lineales de form a escalonada m ientras pro
sible finalizar un producto completo, por lo que se debe gresa el tiem po en el calendario. Cada secuencia lineal
introducir una versión lim itada para cum plir la presión produce un «increm ento» del software [MDE93]. Por
competitiva y de gestión; se comprende perfectamente ejem plo, el software de tratamiento de textos desarro
el conjunto de requisitos de productos centrales o del llado con el paradigm a incremental podría extraer fun
sistema, pero todavía se tienen que definir los detalles ciones de gestión de archivos básicos y de producción
de extensiones del producto o sistema. En estas y en de documentos en el prim er incremento; funciones de
otras situaciones similares, los ingenieros del software edición más sofisticadas y de producción de docum en
necesitan un m odelo de proceso que se ha diseñado tos en el segundo incremento; corrección ortográfica y
explícitamente para acomodarse a un producto que evo gram atical en el tercero; y una función avanzada de
lucione con el tiempo. esquema de página en el cuarto. Se debería tener en cuen
El modelo lineal secuencial (Sección 2.4) se diseña ta que el flujo del proceso de cualquier incremento pue
para el desarrollo en línea recta. En esencia, este enfo de incorporar el paradigma de construcción de prototipos.
que en cascada asum e que se va entregar un sistem a
completo una vez que la secuencia lineal se haya fina
lizado. El m odelo de construcción de prototipos (Sec
ción 2.5) se diseña para ayudar al cliente (o al que CLAVE
desarrolla) a com prender los requisitos. En general, no SmodeloIncremental entrega el softwareen partes
se diseña para entregar un sistema de producción. En pequeñas, pero utlllzables, llamadas ((Incrementos).
ninguno de los paradigm as de ingeniería del software Engeneral, cado Incrementose construye sobre aquél
se tiene en cuenta la naturaleza evolutiva del software. que ya hosido entregado.
Los modelos evolutivos son iterativos. Se caracteri
www.FreeLibros.org
zan por la forma en que perm iten a los ingenieros del Cuando se utiliza un m odelo incremental, el prim er
software desarrollar versiones cada vez m ás completas incremento a m enudo es un producto esencial. Es decir,
del software. se afrontan requisitos básicos, pero muchas funciones
23
IN GE NI E RÍ A DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
suplem entarias(algunas conocidas, otras no) quedan sin El m odelo de proceso increm ental, com o la cons
extraer. El cliente utiliza el producto central (o sufre la trucción de prototipos (Sección 2.5) y otros enfoques
revisión detallada). Como un resultado de utilización y/o evo lu tiv o s, es iterativo por naturaleza. P ero a d ife
de evaluación, se desarrolla un plan para el incremento re n cia de la co n stru cció n de p ro to tip o s, el m odelo
siguiente. El plan afronta la m odificación del producto increm ental se cen tra en la en treg a de un producto
central a fin de cum plir m ejor las necesidades del clien operacional con cada incremento. Los prim eros incre
te y la entrega de funciones, y características adiciona m entos son versio n es «in co m p letas» del p rod u cto
les. Este proceso se repite siguiendo la entrega de cada final, pero proporcionan al usuario la funcionalidad
incremento, hasta que se elabore el producto completo. que p recisa y tam b ién una p latafo rm a para la e v a
luación.
^C O N SE JO ^. El desarrollo increm ental es particularm ente útil
cuando la dotación de personal no está disponible para
Cuando tenga una fecha de entrega imposible
una im plementación com pleta en la fecha límite que se
de cambar, el modela incrementales un buen
haya establecido para el proyecto. Los prim eros incre
paradigma a considerar.
m entos se pueden implementar con m enos personas.
Ingeniería de
increm ento 1
Sistem as/inform ación \
Entrega de¡
Análisis Diseño -j Código Prueba
1.er incremento
increm ento 2 Análisis Diseño Código Prueba Entrega del

2." increm ento
Entrega del
4.° increm ento
Tiem po de calendario
F IG U R A 2 .7 . El m odelo incremental.
2.7.2. El m odelo espiral Planificación

Análisis de riesgos
Comunicación
con el C lient
El m odelo en espiral, propuesto orig in alm en te por
Eje de punto de
Boehm [BOE88], es un m odelo de proceso de soft entrada de proyect
ware evolutivo que conjuga la naturaleza iterativa de
construcción de prototipos con los aspectos controla Ingenieria
dos y sistem áticos del m odelo lineal secuencial. Pro
po rciona el p o ten cial para el d esarro llo ráp id o de Evaluación
del cliente Construcción y adaptación
versiones increm entales del software. En el m odelo
espiral, el software se desarrolla en una serie de ver I I Proyecto de mantenimiento de productos.
siones increm entales. Durante las prim eras iteraccio- c = ] Proyecto de mejora de productos.
i I Proyecto de desarrollo de nuevos productos.
nes, la version increm ental podría ser u n m odelo en IIH H Proyecto de desarrollo de conceptos.
www.FreeLibros.org
papel o un prototipo. D urante las últim as iteraciones,
se producen versiones cada vez más completas del sis
tem a diseñado. FIG U R A 2 .8 . Un m o d elo espiral típico.
24
El modelo en espiral se divide en un núm ero de acti m ás sofisticadas del software. Cada paso por la región
vidades de m arco de trabajo, tam bién llamadas regio de planificación produce ajustes en el plan del proyec
nes de tareas6. Generalmente, existen entre tres y seis to. El coste y la planificación se ajustan con la reali-
regiones de tareas. La Figura 2.8 representa un m odelo m entacion ante la evaluación del cliente. A dem ás, el
en espiral que contiene seis regiones de tareas: gestor del proyecto ajusta el núm ero planificado de ite
• com unicación con el cliente— las tareas requeridas raciones requeridas para com pletar el software.
para establecer com unicación entre el desarrollador
y el cliente.
• p lan ificación— las tareas requeridas para definir
recursos, el tiem po y otra inform ación relacionadas
con el proyecto.
• análisis de riesgos— las tareas requeridas para eva Modelo de proceso adaptable.
luar riesgos técnicos y de gestión.
• ingeniería— l as tareas requeridas para construir una A diferencia del m odelo de proceso clásico que ter
o más representaciones de la aplicación. m ina cuando se entrega el software, el m odelo en espi
• construcción y acción— las tareas requeridas para ral puede adaptarse y aplicarse a lo largo de la vida del
construir, probar, instalar y proporcionar soporte al software de com putadora. U na visión alternativa del
usuario (por ejemplo: docum entación y práctica) m odelo en espiral puede ser considerada exam inando
el eje de pu n to de entrada en el proyecto tam bién refle
• evaluación del cliente— las tareas requeridas para
ja d o en la Figura 2.8. Cada uno de los cubos situados a
obtener la reacción del cliente según la evaluación
lo largo del eje pueden usarse para representar el pun
de las representaciones del software creadas durante
to de arranque para diferentes tipos de proyectos. Un
la etapa de ingeniería e im plem entada durante la
«proyecto de desarrollo de conceptos» com ienza en el
etapa de instalación.
centro de la espiral y continuará (aparecen múltiples ite
raciones a lo largo de la espiral que limita la región som
breada central) hasta que se completa el desarrollo del
concepto. Si el concepto se va a desarrollar dentro de
Las actividades del marco de trabajo se aplican un producto real, el proceso continúa a través del cubo
a cualquier proyecto de software que realice, siguiente (punto de entrada del proyecto de desarrollo
sin tener en cuenta el tamaño ni la complejidad. del producto nuevo) y se inicia un «nuevo proyecto de
desarrollo” . El producto nuevo evolucionará a través de
Cada una de las regiones están compuestas por un con iteraciones alrededor de la espiral siguiendo el camino
junto de tareas del trabajo, llamado conjunto de tareas, que limita la región algo más brillante que el centro.En
que se adaptan a las características del proyecto que va esencia, la espiral, cuando se caracteriza de esta forma,
a emprenderse. Para proyectos pequeños, el núm ero de permanece operativa hasta que el software se retira. Hay
tareas de trabajo y su formalidad es bajo. Para proyectos veces en que el proceso está inactivo, pero siempre que
mayores y más críticos cada región de tareas contiene se inicie un cambio, el proceso arranca en el punto de
tareas de trabajo que se definen para lograr un nivel más entrada adecuado (por ejemplo: m ejora del producto).
alto de formalidad. Engodos los casos, se aplican las acti El m odelo en espiral es un enfoque realista del desa
vidades de protección (por ejemplo: gestión de configu rrollo de sistemas y de software a gran escala. Como el
ración del software y garantía de calidad del software) software evoluciona, a m edida que progresa el proceso
mencionadas en la Sección 2.2. el desarrollador y el cliente com prenden y reaccionan
m ejor ante riesgos en cada uno de los niveles evoluti
¿Qué es un conjunto de
§ tareas?
Cuando empieza este proceso evolutivo, el equipo

vos. El m odelo en espiral utiliza la construcción de pro
totipos como m ecanismo de reducción de riesgos, pero,
lo que es m ás importante, permite a quien lo desarrolla
de ingeniería del software gira alrededor de la espiral aplicar el enfoque de construcciónde prototipos en cual
en la dirección de las agujas del reloj, comenzando por quier etapa de evolución del producto. Mantiene el enfo
el centro. El prim er circuito de la espiral puede produ que sistemático de los pasos sugeridos por el ciclo de
cir el desarrollo de una especificación de productos; los vida clásico, pero lo incorpora al m arco de trabajo ite
pasos siguientes en la espiral se podrían utilizar para rativo que refleja de forma más realista el m undo real.
desarrollar un prototipo y progresivam ente versiones El m odelo en espiral dem anda una consideración direc-
www.FreeLibros.org
6 El modelo en espiral de esta sección e s una variante sobre el modelo
propuesto por Boehm. Para m ás información sobre el modelo en espi
ral original, consulte [BOE88]. Un tratado m ás reciente del modelo
en espiral puede encontrarse en [BOE981.
25
in g en ier ía del s o f t w a r e . un e n f o q u e p r a c t ic o
ta de los riesgos técnicos en todas las etapas del pro El m odelo en espiral W INW IN de Boehm [BOE98]
yecto, y, si se aplica adecuadamente, debe reducir los define un conjuntode actividades de negociación al prin
riesgos antes de que se conviertan en problemáticos. cipio de cada paso alrededor de la espiral. M ás que una
simple actividad de com unicación con el cliente, se defi
c n a a m E sai nen las siguientes actividades:
Modelos evolutivos como el modelo s i espira, son 1. Identificación del sistema o subsistemas clave de los
apropiados, particularmente, paro d desarrollo de «directivos»8.
sistemas orientados o objetos. Para más detalles, véase
la Parte cuarta.
2. Determ inación de las «condiciones de victoria» de
los directivos.
3. Negociación de las condiciones de «victoria» de los
Pero al igual que otros paradigm as, el m odelo en
directivos para reunirlas en un conjunto de condi
espiral no es la panacea. Puede resultar difícil conven
ciones «victoria-victoria» para todos los afectados
cer a grandes clientes (particularmente en situaciones
(incluyendo el equipo del proyecto de software).
bajo contrato) de que el enfoque evolutivo es controla
ble. Requiere una considerable habilidad para la eva
luación del riesgo, y cuenta con esta habilidad para el
éxito. Si un riesgo importante no es descubierto y ges
tionado, indudablem ente surgirán problem as. F inal
m ente, el m odelo no se ha utilizado tanto com o los
paradigm as lineales secuenciales o de construcción de
Habilidadesde negociación
prototipos. Todavía tendrán que pasar muchos años antes
de que se determine con absoluta certeza la eficacia de
Conseguidos completam ente estos pasos iniciales se
este nuevo e importante paradigma.
logra un resultado «victoria-victoria», que será el crite
rio clave para continuar con la definición del sistema y
2.7.3. El m o d e lo e s p ir a l W IN W IN del software. El m odelo en espiral W INW IN se ilustra
(V ictoria& V ictoria) en la Figura 2.9.
El m odelo en espiral tratado en la Seccion 2.7.2 sugie
re una actividad del m arco de trabajo que aborda la 2. Identificar las
condiciones 3a. Reunir las condiciones
com unicación con el cliente. El objetivo de esta activi de victoria de victoria.
dad es m ostrar los requisitos del cliente. En un contex de los directivos. 3b. Establecer los objetivos,
1. Identificar e f restricciones y alternativas
to ideal, el desarrollador simplemente pregunta al cliente siguiente nivel del siguiente nivel.
lo que se necesita y el cliente proporciona detalles sufi para los
directivos. •
cientes para continuar. D esgraciadam ente, esto ra ra i 4 Evaluar las alternativas
’- 'T 'v fifcl producto y del procese
mente ocurre. En realidad el cliente y el desarrollador
J < .y resolución de riesgos.
entran en un proceso de negociación, donde el cliente 7. Revisión
puede ser preguntado para sopesar la funcionalidad,ren- y comentarios.
5. Definir el siguiente nivel
dimiento, y otros productos o características del siste 6. Validar las del producto y del proceso,
m a frente al coste y al tiempo de comercialización. definiciones incluyendo particiones.
del producto
y del proceso.
CLAVE F IG U R A 2 .9 . El m odelo en espiral W IN W IN [BOE98],

la obtenciónde requlsltosdel software requiereuna
negociación. Tiene éxito cuando ambas partes «ganan». Además del énfasis realizado en la negociación ini
cial, el m odelo en espiral W INW IN introduce tres hitos
Las mejores negociaciones se esfuerzan en obtener' en el proceso, llam ados p u n to s de fija ció n [BOE96],
«victoria-victoria». Esto es, el cliente gana obteniendo que ayudan a establecer la com pletitud de un ciclo alre
el producto o sistema que satisface la m ayor parte de dedor de la espiral y proporcionan hitos de decisión
sus necesidades y el desarrollador gana trabajando para antes de continuar el proyecto de software.
conseguir presupuestos y lograr una fecha de entrega En esencia, los puntos de fijación representan tres
realista. visiones diferentes del progreso m ientras que el pro-
www.FreeLibros.org
7 Hay d ocenas de libros escritos sobre habilidades en la negocia 8 Un directivo e s alguien e n la o rg a n iz ac ió n que tiene un in terés
ción [p. ej.,[F IS 9 i], [DON96], [FAR97]].Es u n a de la s c o sa s m as directo, por el negocio, en el sistem a o producto a construir y puede
im portantes que un ingeniero o gestor joven (oviejo) puede a p re n ser prem iado por un resultado con éxito o criticado si el esfuerzo
der. Lea uno. falla.
26
yecto recorre la espiral. El prim er punto de fijación, d e s del usu ario , las d e c isio n e s d e la gestión y los re su lta d o s d e
llamado o b je tiv o s d e l c ic lo de v id a (O C V ), define un las revisiones.
conjunto de objetivos para cada actividad principal El m odelo de proceso concurrente se puede re p re
de ingeniería del software. Como ejem plo, de una par sentar en form a de esquem a com o una serie de acti
te de OCV, un conjunto de objetivos asociados a la vid ad es técn icas im p o rtan tes, tareas y estad o s
definición de los requisitos del producto/sistem a del asociados a ellas. Por ejem plo, la actividad de in g e
nivel más alto. El segundo punto de fijación, llam a n iería d efin id a para el m odelo en esp ira l (S ección
do arquitectura d e l ciclo de vida (ACV), establece los 2.7.2), se lleva a cabo invocando las tareas sig u ien
objetivos que se deben conocer m ientras que se defi tes: m odelado de construcción de prototipos y/o aná
ne la arquitectura del softw are y el sistem a. C om o lisis, especificación de requisitos y diseño'.
ejemplo, de una parte de la ACV, el equipo del pro
La Figura 2.10 proporciona una representación esque
yecto de software debe dem ostrar que ha evaluado la
m ática de una actividad dentro del m odelo de proceso
funcionalidad de los com ponentes del software reuti-
concurrente. La actividad — análisis— se puede encon
lizablesy que ha considerado su im pacto en las d eci
trar en uno de los estados'" destacados anteriormente en
siones de arquitectura. L a ca p a c id a d operativa inicial
cualquier m om ento dado. De forma similar, otras acti
(COI) es el tercer punto de fijación y representa un
vidades (por ejem plo: diseño o com unicación con el
conjunto de objetivos asociados a la preparación del
cliente) se puede representar de una form a análoga.
software para la instalación/distribución, preparación
Todas las actividades existen concurrentem ente, pero
del lugar previam ente a la instalación, y la asistencia
residen en estados diferentes. Por ejemplo, al principio
precisada de todas las partes que utilizará o m anten
del proyecto la actividad de com unicación con el clien
drá el software.
te (no m ostrada en la figura) ha finalizado su primera
iteración y está en el estado de cam bios,en espera. La
2.7.4. El m o d elo d e d esa rr o llo co n cu rr en te
actividad de an á lisis (que estaba en el estado ninguno
Davis y Sitaram [DAV94] han descrito el m odelo de m ientras que se iniciaba la com unicación inicial con el
desarrollo concurrente, llam ado algunas veces inge cliente) ahora hace una transición al estado bajo desa
niería concurrente, de la form a siguiente: rrollo. Sin em bargo, si el cliente indica que se deben
L os gestores de p ro y e c to s q u e sig u e n los p a so s del e sta d o hacer cambios en requisitos, la actividad a n á lisis cam
del pro y ecto en lo q u e se re fie re a las fa s e s im p o rta n te s [del
bia del estado bajo desarrollo al estado cam bios en
ciclo de vida clásico] no tie n e n idea del e stad o d e sus p ro y e c
tos. E stos son ejem p lo s de un intento por seguir los p asos e x tre espera.
m adam ente c o m p le jo s d e a c tiv id a d e s m e d ia n te m o d e lo s El m odelo de proceso concurrente define una serie
dem asiado sim ples. T enga e n c u en ta q u e a u n q u e un p ro y e cto de aco n tecim ien to s que d isp ararán tran sicio n e s de
[grande] esté en la fase de c o d ificació n , hay p ersonal de ese p ro estado a estado para cada una de las actividades de la
yecto im plicado en actividades asociadas generalm ente a m uchas
ingeniería del software. Por ejem plo, durante las p ri
fases de desarro llo sim ultáneam ente. P o r e je m p lo , . .. E l p e rs o
nal está escrib ien d o req u isito s, d ise ñ a n d o , c o d ific a n d o , h a c ie n m eras etapas del diseño, no se contem pla una in co n
do pruebas y p robando la in teg ració n [todo al m ism o tiem po]. sisten cia del m odelo de análisis. E sto g enera la
Los m odelos de p ro ceso s de ing en iería del softw are de H um ph- corrección d el m o d elo de an á lisis de sucesos, que dis
rey y K ellner [H U M 89, K E L 89] h a n m ostrado la c o n c u rre n c ia p arará la activ id ad de a n á lis is del estad o h ech o al
que existe para activ id ad es que o cu rren d u ra n te c u a lq u ie r fase. estado cam bios en espera.
H trabajo m ás reciente d e K e lln e r [K E L 91] utiliza d iag ra m a s
de estado [una n o tac ió n que re p re se n ta los e sta d o s d e un p ro El m odelo de proceso concurrente se utiliza a m enu
ceso] para re p re se n tar la relació n c o n c u rre n te que e x iste en tre do como el paradigma de desarrollo de aplicaciones clien
actividades a sociadas a un aco n tecim ien to esp ecífico (p o r e je m te/servidor11 (Capítulo 28). Un sistema cliente/servidor
plo: un cam bio de req u isito s d u ra n te el ú ltim o d esarro llo ), pero se compone de un conjunto de componentes funciona
falla en capturar la riqueza de la con cu rren cia que existe en todas les. Cuando se aplica a cliente/servidor, el m odelo de pro
las activ id ad es d e d e sa rro llo y d e g e s tió n d el so ftw a re e n un
ceso concurrente define actividades en dos dimensiones
p ro y e cto ... L a m ayoría de lo s m odelos de pro ceso s d e d e s a rro
llo del softw are son d irigidos por el tie m p o : c u an to m ás tard e [SHE94]: una dimensión de sistemas y una dim ensión de
sea, m ás atrás se e n c o n tra rá en el p ro c e so de d e sa rro llo . [Un componentes. Los aspectos del nivel de sistemas se afron
m odelo de p roceso concurrente] está d irig id o por las n e c e s id a tan mediante tres actividades: diseño, ensamblaje y uso.
11 En aplicaciones cliente/servidor, la funcionalidad del softw are se

9 Se debería destacar que el análisis y el diseño son tareas com ple
jas que requieren un estudio sustancial. Las Partes III y IV del libro divide entre d ien te s (norm alm ente PCs) y un servidor (una com pu
www.FreeLibros.org
consideran estos tem as con m ás detalle. tadora m ás potente) que generalm ente m antiene una base de datos
centralizada.
10 U i estado es algún m odo externam ente observable del com por
tamiento.
27
IN GE NI ER ÍA DEL S O F T W A R E . UN E N F O Q U E P R A C T I C O
La dimensión de componentes se afronta con dos activi

dades: diseño y realización. La concurrencia se logra de
dos formas: (1) las actividades de sistemas y de com po
nentes ocurren simultáneamente y pueden modelarse con
el enfoque orientado aobjetosdescritoanteriorm ente;(2)
una aplicación cliente/servidor típica se im plem entacon
muchos componentes, cada uno de los cuales se pueden
diseñar y realizar concurrentemente. En realidad, el mode
lo de proceso concurrente es aplicable a todo tipo de desa Reperesenia un estado de
rrollo de software y proporciona una imagen exacta del una actividad de ingeniería
del software.
estado actual de un proyecto.
FIGURA 2.10. Un elemento del modelo de proceso concurrente.
iü J £ S _
Las tecnologías de objetos (4.a Parte de este libro) pro La actividad de la ingeniería com ienza con la iden
porcionan el m arco de trabajo técnico para un modelo tificación de clases candidatas. Esto se lleva a cabo exa
de proceso basado en componentes para la ingeniería minando los datos que se van a m anejar por parte de la
del software. El paradigm a orientado a objetos enfati aplicación y el algoritmo que se va a aplicar para con
za la creación de clases que encapsulan tanto los datos seguir el tratamiento 2. Los datos y los algoritmos corres
com o los algoritm os que se utilizan para m anejar los pondientes se em paquetan en una clase.
datos. Si se diseñan y se implementan adecuadamente, Las clases creadas en los proyectos de ingeniería del
las clases orientadas a objetos son reutilizables por las software anteriores, se almacenan en una biblioteca de
diferentes aplicaciones y arquitecturasde sistemas basa clases o diccionario de datos (repository) (Capítulo 31).
dos en computadora. Una vez identificadas las clases candidatas, la biblioteca
de clases se exam ina para determ inar si estas clases ya
existen. En caso de que así fuera, se extraen de la biblio
teca y se vuelven a utilizar. Si una clase candidata no resi
de en la biblioteca, se aplican los métodos orientados a
objetos (Capítulos 21-23). Se compone así la primera ite
ración de la aplicación a construirse, mediante las clases
extraídas de la biblioteca y las clases nuevas construidas
para cum plirlas necesidades Unicas de la aplicación. El
flujo del proceso vuelve a la espiral y volverá a introdu
cir por últim o la iteración ensam bladora de com ponen
tes a través de la actividad de ingeniería.
El m odelo de desarrollo basado en componentes con
F IG U R A 2 .1 1 . Desarrollo basado en componentes. duce a la reutilización del software, y la reutilización pro
porciona beneficios a los ingenieros de software. Según
El modelo de desarrollo basado en componentes (Fig. estudios de reutilización, QSM Associates, Inc. informa
2.11) incorpora muchas de las características del m ode que el ensamblaje de componentes lleva a una reducción
lo en espiral. Es evolutivopor naturaleza [NIE92], y exi del 70 por 100 de tiem po de ciclo de desarrollo, un 84
ge un enfoque iterativo para la creación del software. por 100 del coste del proyecto y un índice de producti
Sin embargo, el m odelo de desarrollo basado en com vidad del 26.2, com parado con la norm a de industria del
ponentes configura aplicaciones desde componentes pre 16.9[YOU94], Aunque estos resultados están en función
parados de software (llamados«clases» en la Fig. 2.11). de la robustez de la biblioteca de componentes, no hay
duda de que el ensamblaje de componentes proporciona
c n a a m m a g a
Idtecnoiogío resoltoda para el DBCse trata enlo Parte ventajas significativaspara los ingenieros de software.
cuarta de este libro. El p ro ce so unificado de desarrollo de software
Enel Capitulo27 se presenta unestudiomás detallado [JAC99] representa un núm ero de modelos de desarro
del proceso DBC. llo basados en componentes que han sido propuestos en
www.FreeLibros.org
12 Esta es una descripción simplificada de definición de clase. Para
un estudio m ás detallado, consulte el Capítulo 20.
28
C A PÍT U L O 2 EL P R O C E S O
la industria. Utilizando el Lenguaje de M odelado Uni to de vista del usuario). Entonces acopla la función con
ficado (UML), el proceso unificado define los com po un m arco de trabajo arquitectónico que identifica la for
nentes que se utilizarán para construir el sistem a y las m a que tom ará el software.
interfaces que conectarán los componentes. Utilizando
una combinacion del desarrollo incremental e iterativo, msmxmm
61 los Capítulos21 y 22 se trata UML con más detalle.
el proceso unificado define la función del sistema apli
cando un enfoque basado en escenarios (desde el pun
—.2«.9«...,EL KQDELODILM ÉT-QDQ.SF.QûM AL£¿

El modelo de métodos formales comprende un conjun consiguienteperm iten que el ingeniero del software des
to de actividades que conducen a la especificación m ate cubra y corrija errores que no se pudieron detectar de
mática del software de com putadora. Los m étodos otra manera.
formales permiten que un ingeniero de software espe Aunque todavía no hay un enfoque establecido, los
cifique, desarrolle y verifique un sistema basado en com modelos de métodos formales ofrecen la prom esa de un
putadora aplicando una notación rigurosa y matemática. software libre de defectos. Sin embargo, se ha hablado
Algunas organizaciones de desarrollo del softw are de una gran preocupación sobre su aplicabilidad en un
actualmente aplican una variación de este enfoque, lla entorno de gestión:
mado ingeniería del software de sala limpia [MIL87, 1. El desarrollo de m odelos form ales actualm ente es
DYE92], bastante caro y lleva m ucho tiempo.
2. Se requiere un estudio detallado porque pocos res
los métodosformales se tratan en los Capítulos25 y26. ponsables del desarrollo de software tienen los ante
cedentes necesarios para aplicar métodos formales.
Cuando se utilizan métodos formales (Capítulos 25 3. Es difícil utilizar los modelos com o un mecanismo
y 26) durante el desarrollo, proporcionan un m ecanis de com unicación con clientes que no tienen muchos
mo para eliminar muchos de los problemas que son difí conocim ientos técnicos.
ciles de superar con paradigm as de la ingeniería del N o obstante es posible que el enfoque a través de
software. La ambigüedad, lo incompleto y la inconsis métodos formales tenga m ás partidarios entre los desa-
tencia se descubren y se corrigen m ás fácilmente —no rrolladores del software que deben construir software
mediante un revisión a propósito para el caso, sino de m ucha seguridad (por ejemplo: los desarrolladores
mediante la aplicación del análisis matemático— . Cuan de aviónica y dispositivos médicos), y entre los desa-
do se utilizan métodos formales durante el diseño, sir rrolladores que pasan grandes penurias económicas al
ven como base'para la verificación de program as y por aparecer errores de software.
El término técnicas de cuarta generación (T4G) abarca siguientes herramientas: lenguajes no procedim entales
un amplio espectro de herram ientas de software que tie de consulta a bases de datos, generación de informes,
nen algo en común: todas facilitan al ingeniero del soft m anejo de datos, interacción y definición de pantallas,
ware la especificación de algunas características del generación de códigos, capacidades gráficas de alto nivel
software a alto nivel. Luego, la herramienta genera auto y capacidades de hoja de cálculo, y generación auto
máticamente el código fuente basándose en la especifi m atizada de HTML y lenguajes similares utilizados para
cación del técnico. Cada vez parece m ás evidente que la creación de sitios web usando herram ientas de soft
cuanto mayor sea el nivel en el que se especifique el ware avanzado. Inicialm ente, m uchas de estas herra
software, más rápido se podrá construir el programa. El m ientas estaban disponibles, pero sólo para ámbitos de
paradigma T4G para la ingeniería del software se orien aplicaciónm uy específicos, pero actualmente los entor
ta hacia la posibilidad de especificar el software usan nos T4G se han extendido a todas las categorías de apli
do formas de lenguaje especializado o notaciones caciones del software.
gráficas que describa el problem a que hay que resolver Al igual que otros paradigmas, T4G com ienza con
www.FreeLibros.org
en términos que los entienda el cliente. A ctualm ente, el paso de reunión de requisitos. Idealmente, el cliente
un entorno para el desarrollo de software que soporte describe los requisitos, que son, a continuación, tradu
el paradigma T4G puede incluir todas o algunas de las cidos directamente a un prototipo operativo. Sin embar
29
INGE NIE RÍA DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
go, en la práctica no se puede hacer eso. El cliente pue que facilite la realización del m antenim iento de form a
de que no esté seguro de lo que necesita; puede ser am bi expeditiva.
guo en la especificaciónde hechos que le son conocidos, Al igual que todos los paradigm as del software, el
y puede que no sea capaz o no esté dispuesto a especi m odelo T4G tiene ventajas e inconvenientes.Los defen
ficar la inform ación en la forma en que puede aceptar sores aducen reducciones drásticas en el tiem po de desa
una herram ienta T4G. Por esta razón, el diálogo clien- rrollo del softw are y una m ejora significativa en la
te-desarrollador descrito por los otros paradigmas sigue productividad de la gente que construye el software.
siendo una parte esencial del enfoque T4G. Los detractores aducen que las herram ientas actuales
de T4G no son m ás fáciles de utilizar que los lenguajes
de program ación, que el código fuente producido por
tales herram ientas es «ineficiente» y que el m anteni
Incluso cuando utilice una T4G, tiene que destacar miento de grandes sistemas de software desarrollados
claramente la ingeniería del software haciendo el análisis, mediante T4G es cuestionable.
el diseño y /os pruebas. Hay algún m érito en lo que se refiere a indicaciones
de ambos lados y es posible resum ir el estado actual de
Para aplicaciones pequeñas, se puede ir directam en los enfoques de T4G:
te desde el paso de recolección de requisitos al paso de 1. El uso de T4G es un enfoque viable para muchas de
implementación, usando un lenguaje de cuarta genera las diferentes áreas de aplicación.Junto con las herra
ción no procedim ental (L4G) o un m odelo com prim i mientas de ingeniería de software asistida por com
do de red de iconos gráficos. Sin embargo, es necesario putadora (CASE) y los generadores de código, T4G
un m ayor esfuerzo para desarrollar una estrategia de ofrece una solución fiable a m uchos problem as del
diseño para el sistema, incluso si se utiliza un L4G. El software.
uso de T4G sin diseño (para grandes proyectos) causa 2. Los datos recogidos en com pañías que usan T4G
rá las mismas dificultades (poca calidad, m antenim ien
parecen indicar que el tiem po requerido para produ
to pobre, m ala aceptación por el cliente) que se cir softw are se reduce m ucho para aplicaciones
encuentran cuando se desarrolla software mediante los pequeñas y de tam año medio, y que la cantidad de
enfoques convencionales. análisis y diseño para las aplicaciones pequeñas tam
La im plementación m ediante L4G perm ite, al que bién se reduce.
desarrolla el software, centrarse en la representación de
3. Sin embargo, el uso de T4G para grandes trabajos de
los resultados deseados, que es lo que se traduce auto
desarrollo de software exige el m ismo o m ás tiempo
máticam ente en un código fuente que produce dichos
de análisis, diseño y prueba (actividades de ingenie
resultados. Obviamente, debe existir una estructura de
ría del software), para lograr un ahorro sustancial de
datos con inform ación relevante y a la que el L4G pue
tiem po que puede conseguirse mediante la elim ina
da acceder rápidamente.
ción de la codificación.
Para transform ar una im plem entación T4G en un
producto, el que lo desarrolla debe dirigir una prueba Resum iendo, las técnicas de cuarta generación ya se
com pleta, desarrollar con sentido una docum entación han convertido en una parte importante del desarrollo
y ejecutar el resto de las actividades de integración que de softw are. C uando se com binan con enfoques de
son tam bién requeridas requeridas por otros paradig ensamblaje de componentes (Sección 2.8), el paradig
m as de ingeniería del software. A dem ás, el software m a T4G se puede convertir en el enfoque dom inante
desarrollado con T4G debe ser construido de form a hacia el desarrollo del software.
Los modelos de procesos tratados en las secciones ante ción tratadas en la Sección 2.3. El m odelo, presentado
riores se deben adaptar para utilizarse por el equipo del normalmente como una red, se puede analizar para deter
proyecto del software. Para conseguirlo, se han desarro m inar el flujo de trabajo típico y para exam inar estruc
llado herramientas de tecnología de procesos para ayudar turas alternativas de procesos que pudieran llevar a un
a organizaciones de software a analizar los procesos actua tiem po o coste de desarrollo reducidos.
les, organizar tareas de trabajo, controlar y supervisar el U na vez que se ha creado un proceso aceptable, se
progreso y gestionarla calidad técnica [BAN95], pueden utilizar otras herram ientas de tecnología de pro
Las herram ientas de tecnología de procesos perm i cesos para asignar, supervisar e incluso controlar todas
www.FreeLibros.org
ten que una organización de softw are construya un las tareas de ingeniería del software definidas como par
m odelo autom atizado del m arco de trabajo com ún de te del m odelo de proceso. C ada uno de los miem bros
proceso, conjuntos de tareas y actividades de protec de un equipo de proyecto de softwarepuede utilizar tales
30
herram ientas para desarrollar una lista de control de se puede utilizar para coordinar el uso de otras herra
tareas de trabajo a realizarse, productos de trabajo a pro mientas de ingeniería del software asistida por com pu
ducirse, y actividades de garantía de calidad a condu tadora (Capítulo 3 1) adecuadas para una tarea de trabajo
cirse. La herram ienta de tecnología de proceso tam bién en particular.
2.12 PR ODUCTO Y P R O C E S A ----------
Si el proceso es débil, el producto final va a sufrir indu Toda actividad hum ana puede ser un proceso, pero ca'da uno de
dablemente. A unque una dependencia obsesiva en el nosotros obtiene el sentido de autoestim a ante esas actividades que
pro d u cen una representación o ejem plo que m ás d e una persona
proceso también es peligrosa. En un breve ensayo, Mar- puede utilizar o apreciar, u n a u otra vez, o en algún otro contexto
garet Davis [DAV95] com enta la dualidad producto y n o ten id o en cuenta. E s decir, lo s sentim ientos de satisfacción se
proceso: obtienen por volver a utilizar nuestros productos por nosotros m is
m os o por otros.
Cada diez años o cinco aproxim adam ente,la com unidad del soft
ware vuelve a definir «el problem a» cam biando el foco de los aspec Así pues, m ientras que la asim ilación ráp id a de los objetivos
tos de producto a los aspectos de proceso. P or consiguiente, se han de reutilización en el desarrollo del softw are aum enta p o ten c ial
abarcado lenguajes de program ación estructurados(producto) segui m ente la satisfacció n que lo s de sa rro llad o re s obtienen de su tra
dos por m étodos de análisis estructurados (proceso) seguidos a su bajo, esto in crem en ta la urgencia de ace p ta r la dualidad producto
vez por encapsulaciónde datos (producto) y después por el énfasis y proceso. P e n sa r en un m e c an ism o re u tiliz ab le c o m o el único
actual en el M odelo M adurez de C apacidad de D esarrollo del soft p roducto o el único p roceso, bien oscurece el contexto y la form a
ware del Instituto de ingeniería de softw are (proceso). de u tilizarlo , o bien el hecho de que c ad a u tiliza ció n elab o ra el
p roducto que a su vez se u tilizará c o m o en trad a en a lg u n a otra
Mientras que la tendencia natural de un péndulo es parar en m edio
de dos extrem os, el enfoque de la com unidad del softw are cam bia actividad de d esarro llo del softw are. E le g ir un m étodo sobre otro
reduce enorm em ente las op o rtu n id ad es de reutilización y d e aquí
constantem ente porque se aplica una fuerza nueva cuando falla el
que se pierda la oportu n id ad de a u m e n tar la satisfacción a n te el
último m ovim iento. E stos m ovim ientos son perjudicialespor sí m is
trabajo.
mos y en sí m ism os porque confunden al desarrollador del softw a
re medio cam biando radicalm ente lo que significarealizar el trabajo,
que por sí m ism o lo realiza bien. L os cam bios tam poco resuelven
«el problem a», porque están condenados al fracaso siem pre que el
producto y el proceso se traten com o si form asen una dicotom ía en
lugar de una dualidad. Cualquier actividad se vuelve creativo si el autor se
preocupa de hacerlo bien o de hacerlo mejor.
(S se desarrollo sin pensor y se aplica

descuidadamente, el proceso puede convertirse] en
kr muerte del sentido común.
Las personas obtienen tanta satisfacción ( o m ás) del
M p K. Howard proceso creativo que del producto final. Un artista dis
fruta con las pinceladas de la m ism a form a que disfru
ta del resultado enm arcado. Un escritor disfruta con la
En la com unidad científica hay un precedente que se adelanta a búsqueda de la m etáfora adecuada al igual que con el
las nociones de dualidad cuando contradicciones en observaciones
no se pueden explicar com pletam ente con una teoría com petitiva u
libro final. Un profesional creativo del software debe
otra. La naturaleza dual de la luz, que parece ser una partícula y una ría tam bién obtener tanta satisfacción de la program a
onda al m ism o tiem po, se ha aceptado desde los años veinte cuan ción com o del producto final.
do Louis de B roglie lo propuso. Creo que las observaciones que se El trabajo de los profesionales del software cam bia
hacen sobre los m ecanism os del softw are y su desarrollo dem ues rá en los próxim os años. La dualidad de producto y pro
tran una dualidad fundam ental entre producto y proceso. N unca se
ceso es un elemento importante para m antener ocupada
puede com prender el m ecanism o com pleto, su contexto, uso, signi
ficado y valor si se observa só lo com o u n proceso o sólo com o un
a la gente creativa hasta que se finalice la transición de
producto.. . la program ación a la ingeniería del software.
iH E S U M E N
La ingeniería del software es una disciplina que inte venientes, pero todos tienen una serie de fases gené
www.FreeLibros.org
gra procesos, m étodos y herram ientas para el d esa ricas en común. E n el resto de este libro se consideran
rrollo del software de com putadora. Se han propuesto los principios, conceptos y m étodos que perm iten lle
varios modelos de procesos para la ingeniería del soft var a cabo el proceso que se llam a ingeniería del soft
ware diferentes, cada uno exhibiendo ventajas e incon- ware.
31
I N GEN IE RÍ A DEL S O F TW A R E . UN EN F O Q U E P R Á C T I C O
[BAE98] Baetjer, H., Jr., Software as Capital, IEEE Compu llth ln tl. Conference on Software Engineering, IEEE Com
ter Society Press, 1998,p. 85. puter Society Press, pp. 331-342.
[BAN95] Bandinelli, S. et al, «Modeling and Improving an [IEE93] IEEE Standards Collection: Software Engineering,
Industrial SoftwareProcess», IEEE Trans. Software Engi- IEEE Standard 610.12-1990, IEEE, 1993.
neering, vol. 21, n.- 5, Mayo 1995,pp. 440-454. [JAC99] Jacobson, I., G. B oochy J. Rumbaugh, The Unified
[BRA94] Bradac, M., D. Perry y L. Votta, «Prototyping a Pro Software Developement. Proccess, Addison-Wesley, 1999.
cess Monitoring Experiment”, IEEE Trans. Software Engi-
[KEL89] Kellner, M., Software Process Modeling: Valué and
neering, vol. 20, n.9 10, Octubre 1994, pp. 774-784.
Experience, SEI Technical R eview -1989, SEI, Pittsburgh,
[BOE88] Boehm, B., «A Spiral Model for Software Develo- PA, 1989.
pement and Enhancement", Computer, vol. 21, n.a 5 , Mayo
[KEL91] Kellner, M., «Software Process Modeling Support
1988,pp. 61-72.
for Management Planning and Control», Proc. ls t Intl.
[BOE96] Boehm,B., «Anchoring the SoftwarePocess»,IEEE Conf, On the SoftM’are Process, IEEE Computer Society
Software, vol. 13,n.9 4, Julio 1996,pp.73-82. Press, 1991,pp. 8-28.
[BOE98] Boehm, B., «Using the WINWIN Spiral Model: A [KER94] Kerr, J., y R. HunterJ/iriúe RAD, McGraw-Hill, 1994.
Case Study», Computer, vol. 31, n.9 7, Julio 1998,pp. 33-
44. [MAR91] Martin, J., Rapid Aplication Developement., Pren-
tice-Hall, 1991.
[BR075] Brooks,F., TheMyticalMan-Month, Addison-Wes-
ley, 1975. [MDE93] McDermid, J. y P. Rook, « Software Developement
Process Models», en Software Ingineer's Reference Book,
[BUT94] Butler, J., «Rapid Aplication Developement in CRC Press, 1993,pp. 15/26-15/28.
Action»,A/í»7úg7>7g System Developement., Applied Com
puter Research, vol. 14,n.9 5,M ayo 1995,pp. 6-8. [MIL87] Mills, H.D., M. D yery R. Linger, «Clearoom Soft
ware Engineering», IEEE Software, Septiembre 1987,pp.
[DAV94] Davis, A., y P. Sitaram, «A Concurrent Process 19-25.
Model for Software Developement», Software Enginee-
ringNotes, ACN1 Press, vol. 19,n.9 2, Abril 1994,pp. 38- [NAU69] Naur, P.,y B. Randall (eds.), Software Engineering:
51. A Report. on a Conference sponsored hy the NATO Scien
ce Committee,NATO, 1969.
[DAV95] Davis, M.J., «Process and Product: Dichotomy or
Duality», Software Engineering Notes, ACM Press, vol. [NIE92] Nierstrasz, «Component-Oriented Software Deve
20, n .9 2, Abril 1995,pp. 17-18. lopement», CACM, vol. 35, n.9 9, Septiembre 1992, pp.
160-165.
[DON96] Donaldson,M.C., y M. Dona\dson,Negotiatingfor
Dummies, IDB Books Worldwide, 1996. [PAU93] Paulk, M., et al., «Capability Maturity Model for
Software», Software Engineering Inst.it.ute, Camegie
[DYE92] Dyer, M., The CleanroomApproach to Quality Soft
Mellon University, Pittsburgh, PA, 1993.
ware Developement, Wiley, 1992.
[FAR97] Farber, D.C., Common Sense Negotiation: TheArt [RAC95] Raccoon, L.B.S, «The Chaos Model and the Chaos
Life Cycle», ACM Software Engineering Notes, vol. 20,
o f Winning Gracefuüy, Bay Press, 1997.
n.9 1, Enero 1995,pp. 55-66.
[FIS91] Fisher, R., W. Ury y Bruce Patton, Getting to Yes:
Negot.iat.ing Agreement Wit.hout.Givingln, 2." ed.,Penguin [ROY70] Roy ce, W.W., «Managing the Developement of Large
USA, 1991. Software Systems: ConceptsandTechniques»,P7-oc. WES-
CON, Agosto 1970.
[GIL88] Gilb, T., Principies o f Software Engineering Mana-
gement, Addison-Wesley, 1988. [SHE94] Sheleg, W., «Concurrent Engineering: A New Para-
dign for C/S Developement», Application Developement.
[HAN95] Hanna, M., «Farewell to Waterfalls», Software Trends, vol. l,n .9 6, Junio 1994, pp. 28-33.
Magazine, Mayo 1995,pp.38-46.
[YOU94] Yourdon,E., «SoftvmreReuse», Application D eve
[HUM89] Humphrey, W., y M. Kellner, «Software Process lopement Strategies, vol. VI, n.9 12, Diciembre 1994, pp.
Modeling: Principies of Entity Process Models», Proc. 1-16.
j*RO>BEEMilB Y PU N TO S A CONSIDERAR
2.1. La Figura 2.1 sitúa las tres capas de ingeniería del soft 2.2. ¿Hay algún caso en que no se apliquen fases genéricas
www.FreeLibros.org
ware encima de la capa titulada «enfoque de calidad». Esto del proceso de ingeniería del software? Si es así, descríbalo.
implica un programa de calidad tal como Gestión de Cali 2.3. El Modelo Avanzado de Capacidad del SEI es un docu
dad Total. Investigue y desarrolle un esquema de los prin mento en evolución. Investigue y determ ine si se han aña
cipios clave de un programa de Gestión de Calidad Total. dido algunas ACP nuevas desde la publicación de este libro.
32
2.4. El modelo del caos sugiere que un bucle de resolución de 2.8. Proponga un proyecto específicode software que sea ade
problemas se pueda aplicar en cualquier grado de resolución. cuado para el modelo incremental. Presente un escenario para
Estudie la forma en que se aplicaría el bucle (1) para com aplicar el modelo al software.
prender los requisitos de un producto de tratamiento de texto; 2.9. A medida que vaya hacia afuera por el modelo en espiral,
(2) para desarrollar un componente de corrección ortográfica ¿qué puede decir del software que se está desarrollando o man
y gramática avanzado para el procesador de texto; (3) para teniendo?
generar el código para un módulo de programa que determi
ne el sujeto, predicado y objeto de una oración en inglés. 2.10. Muchas personas creen que la Única forma en la que se
van a lograr mejoras de magnitud en la calidad del software y
2.5. ¿Qué paradigmas de ingeniería del software de los presen en su productividad es a través del desarrollo basado en com
tados en este capítulo piensa que sería el más eficaz? ¿Por qué?
ponentes. Encuentre tres o cuatro artículos recientes sobre el
2.6. Proporcione cinco ejemplos de proyectos de desarrollo asunto y resúmalos para la clase.
del software que sean adecuados para construir prototipos.
2.11. Describa el modelo de desarrollo concurrente con sus
Nombre dos o tres aplicaciones que fueran más difíciles para
propias palabras.
construir prototipos.
2.12. Proporcione tres ejemplos de técnicas de cuarta genera
2.7. El modelo DRA a menudo se une a herramientas CASE.
ción.
Investigue la literatura y proporcione un resumen de una herra
mienta típica CASE que soporte DRA. 2.13. ¿Qué es más importante, el producto o el proceso?
El estado actual del arte en la ingeniería del software se puede controvertidos y amenos sobre el software y el proceso de la
determinar mejor a partir de publicacionesmensuales tales como ingeniería del software. Pressman y Herron (S oftw areSh ock,
IEEE Software, C om puter e IE E E Transactions on Software Dorset House, 1991) consideran el software y su impacto
Engineering. Periódicos sobre la industria tales como A p p lica sobre particulares, empresas y el gobierno.
tion D e\’elopement Trends,C utter IT Journal y Software D eve- El Instituto de ingeniería del software (US localizado en
lopement a menudo contienen artículos sobre temas de ingeniería la Universidad de Carnegie-Mellon) ha sido creado con la
del software. La disciplina se «resume» cada año en el Proce- responsabilidad de promocionar series monográficas sobre
edingofthe International Conference on Software Engineering, la ingeniería del software. Los profesionales académicos,
promocionado por el IEEE y ACM y tratado en profundidad en en la industria y el gobierno están contribuyendo con nue
periódicos como A C M Transactions on Software Engineering vos trabajos importantes. El Consorcio de Productividad del
andM ethodology,ACM Software Engineering N otes y Annals Software dirige una investigación adicional de ingeniería
of Software Engineering. de software.
Se han publicado muchos libros de ingeniería del softwa En la última década se ha publicado una gran variedad de
re en los últimos años. Algunos presentan una visión general estándares y procedimientos de ingeniería del software. El IEEE
del proceso entero mientras que otros se dedican a unos pocos Software E ngineering Standards contiene muchos estándares
temas importantes para la exclusión de otros. Las siguientes diferentes que abarcan casi todos los aspectos importantes de
son tres antologías que abarcan algunos temas importantes la tecnología. Las directrices ISO 9000-3 proporcionan una
de ingeniería del software: guía para las organizaciones de software que requieren un regis
Keyes,J. (ed.). Software Engineering P roductivity H and- tro en el estándar de calidad ISO 9001. Otros estándares de
book, McGraw-Hill, 1993. ' ingeniería del software se pueden obtener desde el MOD, la
McDermid, J. {ed.), Software E n g in eer’s R eferen ce B ook, Autoridad Civil de Aviación y otras agencias del gobierno y
CRC Press, 1993. sin ánimo de lucro. Fairclough (Softw areE ngineering G uides,
Marchiniak, J. J. ( e d ) , E n cyclopedia o f Softw are E n gin e Prentice-Hall, 1996) proporciona una referencia detallada de
ering, Wiley. 1994. los estándares de ingeniería del software producidos por Euro-
Gautier (D istrib u ted E n g in eerin g o f S oftw are, Prentice- pean Space Agency (ESA).
Hall, 1996)proporciona sugerencias y directrices para orga En internet se dispone de una gran variedad de fuentes de
nizaciones que deban desarrollar software en lugares información sobre la ingeniería del software y del proceso de
geográficamentedistantes. software. Se puede encontrar una lista actualizada con refe
En la parte más brillante del libro de Robert Glass (S o ft rencias a sitios (páginas) web que son relevantes para el pro
ware C onflict, Yourdon Press, 1991) se presentan ensayos ceso del software en http://www.pressman5.com.
www.FreeLibros.org
PARTE
I I
GESTION DE PROYECTOS
DE SOFTWARE
N esta parte de Ingeniería del Software: Un erfoque Práctico, estudiamos
E las técnicas de gestión necesarias para planificar-, organizar, supervisar

y controlar proyectos de software. En los capítulos que vienen a conti
nuación, obtendremos respuestas a las siguientes cuestiones:
• ¿Cómo se debe gestionar el personal, el proceso y el problema durante un

proyecto de software?
• ¿Qué son las métricas de software y cómo pueden emplearse para gestio
nar un proyecto de software y el proceso del software?
• ¿Cómo genera un equipo de software estimaciones fiables del esfuerzo,
costes y duración del proyecto?
• ¿Qué técnicas pueden emplearse para evaluar formalmente los riesgos
que pueden tener impacto en el éxito del proyecto?
• ¿Cómo selecciona un gestor de proyectos de software el conjunto de tareas
del proyecto de ingeniería de software? ,
• ¿Cómo se crea la planificación temporal de un proyecto?
• ¿Cómo se define la calidad para que pueda ser controlada?
• ¿Qué es la garantía de calidad del software?
• ¿Por qué son tan importantes las revisiones técnicas formales?
• ¿Cómo se gestionan los cambios durante el desarrollo de software de com
putadora y después de entregarlo al cliente?
Una vez que se haya dado respuesta a estas cuestiones, estará mejor prepa
rado para gestionar proyectos de software de manera que entregue un producto
de alta calidad puntualmente.
www.FreeLibros.org
C A PÍT U L O
3 CONCEPTOS SOBRE GESTION

DE PROYECTOS
N el prefacio de su libro sobre gestión de proyectos de softw are, M eiler Page-Jones
E [PAG85] dice una frase que pueden corroborar m uchos asesores de ingeniería del soft
ware:
H e visitado d ocenas de em p resas, buenas y m alas, y he observ ad o a m uchos ad m in istrad o res de p ro c e
so de d atos, tam bién buenos y m alos. Frecuentem ente, he visto con horror cóm o estos adm inistradores lu ch a
ban inútilm ente c ontra pro y ecto s de p esad illa, sufriendo por fechas lím ite im p o sib les d e cum plir, o que
en treg ab an sistem as que d ecep cio n ab an a sus usu ario s y que d ev o rab an ing en tes cantidades de horas de
m antenim iento.
Lo que describe Page-Jones son síntomas que resultan de una serie de problem as técnicos y
de gestión. Sin embargo, si se hiciera una autopsia de cada proyecto, es muy probable que se
encontrara un denom inador común constante: una débil gestión.
En este capítulo y en los seis que siguen consideraremos los conceptos clave que llevan a
una gestión efectiva de proyectos de software. Este capítulo trata conceptos y principios b ási
cos sobre gestión de proyectos de software. El Capítulo 4 presenta las métricas del proyecto y
del proceso, la base para una tom a de decisiones de gestión efectivas. Las técnicas que se em ple
an para estim ar los costes y requisitos de recursos y poder establecer un plan efectivo del pro
yecto se estudian en el C apítulo 5. Las actividades de gestión que llevan a una correcta
supervisión, reducción y gestión del riesgo se presentan en el Capítulo 6. El Capítulo 7 estudia
las actividades necesarias para definir las tareas de un proyecto y establecer una program ación
del proyecto realista. Finalmente, los Capítulos 8 y 9 consideran técnicas para asegurar la cali
dad a m edida que se dirige un proyecto y el control de los cambios a lo largo de la vida de una
aplicación.
VISTAZO RAPIDO
¿Qué e s? Aunque muchos de nosotros nan la relación entre el negocio y los ciendo puntos de control de calidad y
(en nuestros momentos m ás oscuros) profesionales del software. estableciendo mecanismos p ara con
tom am os la v isió n deDilbert sobre la ¿P er q u é e s im portante? La construc trolar y supervisar el trabajo definido
« g estión», t a i t a u n a actividad muy ción de softw are d e computadora es en la planiíicación.
n e c e s a ria c u a n d o se construyen pro un a em presa compleja, particular ¿C uál e s «1 p rod ucto ob ten id o ? Un
ductos y sistem as basados en compu mente si participa mucha gente, tra plan de proyecto se realiza al com ien
tadoras. La gestión de proyectos bajando durante un periodo de tiempo zo de las actividades de gestión. El
implica ¡a planiíicación, supervisión relativamente largo. Esta es la razón p la n d e fin e e l p ro c e so y l a s t a r e a s á
y co ntrol d e l personal, del proceso y por la cual los proyectos de software realizar el personal que re aliz a rá el tra
d e lo s e v e n to s q u e ocurren mientras necesitan ser gestionados. bajo y los m ecanism os p a ra e v a lu a r lo3
evoluciona el software desde la fase ¿C uáles s e n lo s p a se s? Comprender riesgos, controlar el cambio y evaluar
preliminar a la implementación ope- las cuatro «P’s» —personal, producto, la calidad.
racional. proceso y proyecto—. El personal ¿Cómo p u e d o estar se g u r o d e q ue
¿Q uién lo h a ce? Todos «gestionamos» debe estar organizado para desarro lo he h e c h o correctam ente? N un
de algún modo, pero el ámbito de las llar el trabajo del software con efecti ca e s tá s co m p letam en te seg u ro d e q ue
actividades de gestión varía en función vidad. La comunicación con el cliente el plan de proyecto es correcto h asta
de la persona que las realiza. Un inge debe ocurrir oara aue se comprendan aue no has entregado un producto de
niero de so ftw are g e stio n a sus activi el a lc a n c e d e l p ro d u c to y los re q u is i a lt a c a lid a d d e n tro d e l tie m p o y d el
d a d e s del día a día, planificando,
tos. D e b e s e le c c io n a r s e e l p ro c e so p re su p u esto . S in e m b a rg o , u n g e sto r
supervisando, y controlando las tareas a d e c u a d o p a ra el p e rs o n a l, y e l p ro d e pro y ecto s h a c e lo correcto c u a n d o
técnicas. Los gestores del proyecto p la d ucto. El p ro y e cto d e b e p la n ific a rs e e stim u la a l p e rso n al p a ra tra b a ja r jun
nifican, supervisan y cQn¡rojan el tr a e s tim a n d o e l e sfu e rz o y e l tie m p o tos com o u n eq u ip o efectiv o , c e n tra n
bajo de un equipo de ingenieros de p a r a c u m p lir l a s ta r e a s : d e f in ie n d o d o su a te n c ió n e n la s n e c e s id a d e s d el
www.FreeLibros.org
softw are. Los g esto res expertos coordi
lo s p ro d u c to s d e l tra b a jo , e s t a b l e cliente y e n la c a lid a d d e l producto.
37
IN GE NI ER ÍA DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
L a gestión eficaz de un proyecto de softw are se c e n 3.1.2. P ro d u c to

tra en las cuatro P ’s: perso n a l, p ro d u cto , p ro c e so y Antes de poder planificar un proyecto, se deberían esta
p royecto. El orden no es arbitrario. El gestor que se blecer los objetivos y el ám bito del producto‘, se debe
olvida de que el trabajo de ingeniería del softw are es rían considerar soluciones alternativas e identificar las
un esfuerzo hum ano intenso nunca tendrá éxito en la dificultades técnicas y de gestión. Sin esta información,
gestión de proyectos. Un gestor que no fom enta una es im posible definir unas estim aciones razonables (y
m inuciosa com unicación con el cliente al principio exactas) del coste; una valoración efectiva del riesgo,
de la evolución del proyecto se arriesga a construir una subdivisión realista de las tareas del proyecto o una
una elegante solución para un problem a equivocado. planificación del proyecto asequible que proporcione
El adm inistrador que presta poca atención al p ro c e una indicación fiable del progreso.
so corre el riesgo de arrojar m étodos técnicos y herra
m ientas eficaces al vacío. El gestor que em prende un
proyecto sin un plan sólido arriesga el éxito del p ro
ducto. Enel Capitulo 1se trata una taxonomíade lasóreos
deaplicaciónque producenlos «productos» de software.
3.1.1. P e r s o n a l
La necesidad de contar con personal para el desarrollo
del software altamente preparado y m otivado se viene El desarrolladorde software y el cliente deben reunir
discutiendo desde los años 60 (por ejemplo, [COU80, se para definir los objetivos del producto y su ámbito. En
WIT94, DEM98]). De hecho, el «factor humano» es tan muchos casos, esta actividad empieza como parte del pro
im portante que el Instituto de Ingeniería del Software ceso de ingeniería del sistema o del negocio (Capítulo 10)
ha desarrollado un M odelo de madurez de la capacidad y continúa como el primer paso en el análisis de los requi
de gestión de p erso n a l (M M CGP) «para aum entar la sitos del software (Capítulo 11). Los objetivos identifican
preparación de organizaciones del software para llevar las metas generales del proyecto sin considerar cómo se
a cabo las cada vez m ás complicadas aplicaciones ayu conseguirán (desde el punto de vista del cliente).
dando a atraer, aumentar, m otivar, desplegar y retener El ámbito identifica los datos prim arios, funciones y
el talento necesario para m ejorar su capacidad de desa com portamientos que caracterizan al producto, y, más
rrollo de software» [CUR94]. importante, intenta abordar estas características de una
m anera cuantitativa.
Una vez que se han entendido los objetivos y el ámbi
to del producto, se consideran soluciones alternativas.
3.1.3. P ro c e s o
Un proceso de softw are (C apítulo 2 ) proporciona la
estructura desde la que se puede establecer un detalla
do plan para el desarrollo del softw are. Un pequeño
El m odelo de m adurez de gestión de personal defi núm ero de actividades estructurales se puede aplicar a
ne las siguientes áreas clave prácticas para el personal todos los proyectos de software, sin tener en cuenta su
que desarrolla software: reclutamiento, selección, ges tam año o complejidad. Diferentes conjuntos de tareas
tión de rendimiento, entrenamiento, retribución, desa - t a r e a s , hitos, productos del trabajo y puntos de garan
rrollo de la carrera, diseño de la organización y del tía de c a lid a d -p e rm ite n a las actividades estructura
trabajo y desarrollo cultural y de espíritu de equipo. les adaptarse a las características del proyecto de
El M M CGP es com pañero del m odelo de madurez software y a los requisitos del equipo del proyecto. Final
de la capacidad software (Capítulo 2), que guía a las m ente, las actividades protectoras — tales com o garan
organizacionesen la creación de un proceso de software tía de calidad del software, gestión de la configuración
maduro. M ás adelante en este capítulo se consideran del software y m e d ic ió n -c u b re n el m odelo de proce
aspectos asociados a la gestión de personal y estructu so. Las actividades protectoras son independientes de
ras para proyectos de software. las estructurales y tienen lugar a lo largo del proceso.
1 En este contexto, el term ino «producto» e s usado para abarcar cual

quier software que será construido a petición de otros. Esto incluye
n o sólo productos de softw are, sino tam bién sistem as basados en
www.FreeLibros.org
com putadora, softw are em potrado y softw are de resolución de pro
blem as (por ejem plo, p rogram as para la resolución de problem as
científicos/de ingeniería).
38
CAPÍTULO 3 C O N C E P T O S S OB RE G E S T I Ó N DE P R O Y E C T O S
por 100 experim entaron un desbordam iento en la pla-

nificacióny en el coste [REE99], Aunque la proporción
CLA VE de éxito para los proyectos de software ha m ejorado un
las actividades estructurales se componen de tareas, hitos, poco, nuestra proporción de fracaso de proyecto per
productos de trabajo y puntos de garantía de calidad. manece m ás alto del que debería ser2.
Para evitar el fracaso del proyecto, un gestor de pro
yectos de softw are y los ingenieros de softw are que
3.1.4. P ro y e c to construyeron el producto deben eludir un conjunto de
Dirigimos los proyectos de software planificados y con señales de peligro com unes; com prender los factores
trolados por una razón principal -es la Única m anera del éxito críticos que conducen a la gestión correcta del
conocida de gestionar la com plejidad— . Y todavía proyecto y desarrollar un enfoque de sentido com ún
seguimos esforzándonos. En 1998, los datos de la indus para planificar, supervisar y controlar el proyecto. Cada
tria del software indicaron que el 26 por 100 de pro uno de estos aspectos se trata en la Sección 3.5 y en los
yectos de software fallaron completam ente y que el 46 capítulos siguientes.
En un estudio publicado por el IEEE [CUR88] se les del software, damos este aspecto por descontado. Los
preguntó a los vicepresidentes ingenieros de tres gran gestores argum entan (como el grupo anterior) que el
des compañías tecnológicas sobre el factor m ás im por personal es algo primario, pero los hechos desm ienten
tante que contribuye al éxito de un proyecto de software. a veces sus palabras.
Respondieron de la siguiente manera: En esta sección examinamos los participantes que cola
VP 1: Supongo que si tuviera que elegir lo m ás im portante boran en el proceso del software y la m anera en que se
de n uestro e n torno de trabajo, diría que no son las organizan para realizar una ingeniería del Software eficaz.
herram ientas que em pleam os, es la gente.
V P 2: El ingredientem ás im portante que contribuyóal éxi 3.2.1. L os p a r t i c i p a n t e s
to de este proyecto fue tener gente lista ... pocas cosas
m ás im portan en mi opinión ... L o m ás im portante El proceso del software (y todos los proyectos de soft
que se puede h acer por un proyecto es seleccionar el ware) lo com ponen participantes que pueden clasificarse
personal ... E l éxito de la organización de desarrollo en una de estas cinco categorías:
del softw are está m uy, m uy asociado con la habili
1. Gestores superiores, que definen los aspectos de
dad de reclutar buenos profesionales.
negocios que a m enudo tienen una significativa
VP 3: L a ú n ic a re g la que te n g o e n c u a n to a la g e stió n
influencia en el proyecto.
es a segurarm e de que ten g o buenos pro fesio n ales
— gen terealm en te buena— , de q u e p re p a ro b u e 2. Gestores (técnicos)del proyecto, que deben planifi
n a g e n te y d e que p ro p o rc io n o el e n to rn o e n el car, motivar, organizar y controlar a los profesiona
que lo s b u e n o s p ro fe s io n a le s p u e d a n producir. les que realizan el trabajo de software.
3. Profesionales, que proporcionan las capacidades téc
nicas necesarias para la ingeniería de un producto o
aplicación.
t e compañías que gestionan sensiblemente
4. Clientes, que especifican los requisitos para la inge
•Siistveisián en personal a la larga prosperarán
niería del softw are y otros elem entos que tienen
Sm i (M ia ra y Tht lister
m enor influencia en el resultado.
5. Usuarios finales, que interaccionan con el software
Ciertamente, éste es un testimonio convincente sobre una vez que se ha entregado para la producción.
la importancia del personal en el proceso de ingeniería Para ser eficaz, el equipo del proyecto debe organizarse
del software. Y, sin embargo, todos nosotros, desde los de m anera que maxim ice las habilidades y capacidades
veteranos vicepresidentes al m ás m odesto profesional de cada persona. Y este es el trabajo del jefe del equipo.
2 D adas estas estadísticas,es razonable preguntarse cóm o el impacto

de las com putadorascontinúa creciendo exponencialm ente y la indus
tria del software continúa anunciando el crecimiento de ventas al doble.
Parte de la respuesta, pienso, es que un im portante núm ero de estos
www.FreeLibros.org
proyectos «fallidos» están mal concebidos desde el primer m om ento.
Los clientes pierden el interés rápidam ente (puesto que lo que ellos
pidieron realm ente no era tan im portante com o ellos habían pensado),
y los proyectos son cancelados.
39
IN GE NI E RÍ A DEL SOF TW ARE . UN E N F O Q U E P R A C T I C O
3.2.2. L os je f e s d e e q u ip o Incentivos por logros. Para optim izar la productividad de

un equipo de proyecto, un gestor debe recom pensar la inicia
La gestión de un proyecto es una actividad intensamente tiva y los logros, y dem ostrar a través de sus propias acciones
humana, y por esta razón, los profesionales com peten que no se penalizará si se corren riesgos controlados.
tes del software a m enudo no son buenos jefes de equi Influencia y construcción de espíritu de equipo. U n ges
p o. S im plem ente no tienen la m ezcla adecuada de to r de proyecto eficiente debe ser capaz de «leer» a la gente;
capacidades del personal. Y sin em bargo, com o dice debe ser capaz de entender señales verbales y no verbales y
Edgem on: «Desafortunadam ente y con dem asiada fre reaccionar ante las necesidades de las personas que m andan
cuencia, hay individuos que term inan en la gestión de esas señales. El gestor debe m antener el control en situaciones
de gran estrés.
proyectos y se convierten en gestores de proyecto acci
dentales» [EDG95].
(fftcONSEJC
^ ¿En qué nos fijamos cuando
Un experto de software puede no tener temperamento o
™ seleccionamos a alguien para
deseo de ser ¡efe de equipo. No fuerce al experto poro ser
conducir un proyecto de software?
uno de ellos.
En un excelente libro sobre gestión técnica, Jerry

Weinberg [WEI86] sugiere el modelo de gestión MOI: 3.2.3. El e q u ip o d e s o f tw a r e
M o tiv ac ió n .L a habilidad para m otivar (con un «tira y aflo Existen casi tantas estructuras de organización de perso
ja » ) al personal técnico para que produzca conform e a sus m ejo
nal para el desarrollo de software como organizaciones
res capacidades.
que se dedican a ello. Para bien o para mal, el organi
Organización. L a habilidad para am oldar procesos ex is grama no puede cambiarse fácilmente. Las consecuen
tentes (oi nventar unos nuevos) que perm ita al concepto inicial
transform arse en un producto final.
cias prácticas y políticas de un cambio de organización
no están dentro del alcance de las responsabilidades del
Ideas o innovación.L a habilidad para m otivar al personal
gestor de un proyecto de software. Sin embargo, la orga
para crear y sentirse creativos incluso cuando deban de trab a
ja r dentro de los lím ites establecidos para un producto o apli nización del personal directamente involucrado en un
cación de softw are particular. nuevo proyecto de software está dentro del ámbito del
gestor del proyecto.
Las siguientes opciones pueden aplicarse a los recur
sos hum anos de un proyecto que requiere n personas
equipos sencillos un líder es oquel que sobe o trabajando durante k años:
donde quiete ir, se levanta y va. 1. n individuos son asignados a m diferentes tareas fun
cionales, tiene lugar relativamente poco trabajo con
ju n to ; la coordinación es responsabilidad del gestor
del software que puede que tenga otros seis proyec
Weinberg sugiere que el éxito de los gestores de pro
tos de los que preocuparse.
yecto se basa en aplicar un estilo de gestión en la reso
lución de problemas. Es decir, un gestor de proyectos de
software debería concentrarse en entender el problem a
que hay que resolver, gestionando el flujo de ideas y, al
No todo grupo es un equipo, y no todo equipo
m ism o tiempo, haciendo saber a todos los m iembros del
equipo (mediante palabras y, m ucho m ás im portante,
con hechos) que la calidad es im portante y que no debe
verse comprometida.
Otro punto de vista [EDG95] de las características
2. n individuos son asignados a m diferentes tareas fun
que definen a un gestor de proyectos eficiente resalta
cionales (m<n) de m anera que se establecen «equi
cuatro apartados clave:
p o s i~formales; se puede nombrar un líder al efecto;
Resolución del problema. U n gestor eficiente de un pro la coordinación entre los equipos es responsabilidad
yecto de softw are puede diagnosticar los aspectos técnicos y
de o rganizaciónm ás relevantes, estructurar una solución siste
de un gestor del software.
m áticam ente o m otivar apropiadam ente a otros profesionales 3. n individuos se organizan en t equipos; a cada equipo
para que desarrollen la solución, aplicar las lecciones aprendi se le asignan una o m ás tareas funcionales; cada
das de anteriores proyectos a las nuevas situaciones, m ante equipo tiene una estructura específica que se define
nerse lo suficientem enteflexible para cam biar la g estión si los
para todos los equipos que trabajan en el proyecto;
intentos iniciales de resolver el problem a no dan resultado.
la coordinación es controlada por el equipo y por el
Dotes de gestión. U n buen gestor de proyectos debe tom ar gestor del proyecto de software.
www.FreeLibros.org
las riendas. D ebe tener confianza para asum ir el control cuan
do sea n ecesarioy la garantía para perm itir que los buenos téc Aunque es posible encontrar argumentos en pro y en
nicos sigan sus instintos. contra para cada uno de los enfoques anteriores, existe
40
CAPÍTULO 3 C O N C E P T O S S O B R E G E S T I Ó N DE P R O Y E C T O S
una gran evidencia que indica que una organización de ja r problem as sencillos. Los equipos descentralizados
equipo formal (opción 3) es la m ás productiva. generan m ás y m ejores soluciones que los individua
La «m ejor» estructura de equipo depende del esti les. Por tanto, estos equipos tienen más probabilidades
lo de gestión de una organización, el núm ero de per de éxito en la resolución de problem as complejos. Pues
sonas que com pondrá el e q u ip o , sus niveles de to que el equipo DC es centralizado para la resolución
preparación y la dificultad general del problema. Man- de problem as, tanto el organigrama de equipo DC como
tei [M AN81] sugiere tres org an ig ram as de equipo el de CC pueden aplicarse con éxito para problem as
genéricos: sencillos. La estructura DD es la m ejor para problemas
D e s c e n tr a liz a d o d e m o c r á t i c o (D D ). E ste e q u ip o de difíciles.
in g en iería del softw are no tie n e un j e f e perm anente. M ás Como el rendim iento de un equipo es inversamente
bien, «se n o m bran co o rd in ad o res d e tareas a c o rto p laz o y proporcional a la cantidad de com unicación que se debe
se su s titu y e n p o r o tro s para d ife re n te s tare as» . L as d e c i entablar, los proyectos muy grandes son m ejor dirigi
siones so b re pro b lem as y los e n fo q u es se h a ce n p o r c o n
dos por equipos con estructura CC o DC, donde se pue
senso del grupo. L a co m u n ic ac ió n e n tre los m iem bros del
equipo es horizontal.
den formar fácilmente subgrupos.
El tiem po que los m iem bros del equipo vayan a
«vivir juntos» afecta a la moral del equipo. Se ha des
■ [■ ¿Cómo debería estar
cubierto que los organigramas de equipo tipo DD pro
'S F organizado un equipo
ducen una m oral m ás alta y m ás satisfacción p or el
de softw are?
trabajo y son, por tanto, buenos para equipos que per
m anecerán juntos durante m ucho tiempo.
D e s c e n tra liz a d o c o n tro la d o (D C ). E ste equipo de in g e El organigram a de equipo DD se aplica m ejor a pro
niería del softw are tien e un je fe definido que c o o rd in a tare
blemas con m odularidad relativamente baja, debido a
as específicas y jefe s secundariosque tienen responsabilidades
sobre subtareas. L a reso lu ció n de pro b lem as sig u e siendo
la gran cantidad de com unicación que se necesita. Los
una activ idad del g ru p o , p ero la im p le m e n tac ió n d e so lu organigramas CC o DC funcionan bien cuando es posi
ciones se reparte entre subgrupos por el je fe de equipo. L a ble una m odularidad alta (y la gente puede hacer cada
com unicación e n tre subgrupos e indiv id u o s es horizontal. uno lo suyo).
Tam bién hay com unicación vertical a lo largo de la je ra rq u ía
de control.
C e n tr a liz a d o c o n tr o la d o ( C C ) . E l j e f e d el e q u ip o se
encarga de la resolución de p ro b lem as a alto nivel y la c o o r
dinación interna del equipo. L a c o m u n icació n entre e lje fe y Frecuentementees mejor tenerpocos equipos pequeños,
los m iem bros del equipo es vertical. bien centrados que un gran equipo solamente.
Mantei [MAN81] describe siete factores de un pro

yecto que deberían considerarse cuando se planifica el Los equipos CC y DC producen m enos defectos que
organigrama de equipos de ingeniería del software: los equipos DD, pero estos datos tienen m ucho que ver
• la dificultad del problem a que hay que resolver con las actividades específicas de garantía de calidad
• el tamaño del program a(s) resultante(s) en líneas de que aplica el equipo. Los equipos descentralizados
código o puntos de función (Capítulo 4) requieren generalmente m ás tiem po para com pletar un
proyecto que un organigram a centralizado y al m ism o
• el tiempo que el equipo estarájunto (tiempo de vida
tiem po son mejores cuando se precisa una gran canti
del equipo)
dad de comunicación.
• el grado en que el problem a puede ser m odulari- Constantine [CON93] sugiere cuatro «paradigm as
zado de organización» para equipos de ingeniería del soft
ware:
¿Qué factores 1. Un paradigm a cerrado estructura a un equipo con
• deberíamos considerar
cuando estructuramos
un equipo de software?
una je ra rq u ía tradicional de autoridad (sim ilar al
equipo CC). Estos equipos trabajan bien cuando pro
ducen software similar a otros anteriores, pero pro
bablemente sean m enos innovadores cuando trabajen
dentro de un paradigm a cerrado.
• la calidad requerida y fiabilidad del sistema que se
va a construir 2. E l paradigm a aleatorio estructura al equipo libre
m ente y depende de la iniciativa individual de los
• la rigidez de la fecha de entrega
m iem bros del equipo. Cuando se requiere innova
• el grado de sociabilidad (comunicación) requerido ción o avances tecnológicos, los equipos de para
www.FreeLibros.org
para el proyecto digm a aleatorio son excelentes. Pero estos equipos
Debido a que una estructura centralizada realiza las pueden chocar cuando se requiere un «rendim iento
tareas más rápidamente, es la m ás adecuada para m ane ordenado».
41
IN GENIERÍA DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
3. El paradigm a abierto intenta estructurar a un equipo nen una d e fin ic ió n co m ú n de é x ito o un esp íritu de e q u i
de m anera que consiga algunos de los controles aso po id e n tific a b le . L o que fa lta e s un fe n ó m e n o que d e n o
m in a m o s cuajar.
ciad o s con el paradigm a cerrado, pero tam bién
m ucha de la innovación que tiene lugar cuando se U n e q u ip o c u a ja d o es un g ru p o d e gente tejido tan fu e r
te m e n te que el to d o es m ay o r que la sum a de las p a r te s ...
utiliza el paradigm a aleatorio. El trabajo se desa
rrolla en colaboración, con m ucha com unicación y U na vez que el equipo em pieza a cuajar, la probabilidad
tom a de decisiones consensuadas y con el sello de d e é x ito e m p ie za a subir. E l eq u ip o p u e d e c o n v e rtirs e en
im p arab le, un m onstruo de éxito ... N o necesitan ser d irig i
los equipos de paradigm a abierto. Los organigra
dos de una m anera tradicional y no necesitan que se les m oti
m as de equipo de paradigm a abierto son adecuados ve. E stán en su gran m om ento.
para la resolución de problem as com plejos, pero
pueden no tener un rendim iento tan eficiente com o D eM arco y Lister m antienen que los m iem bros de
otros equipos. equipos cuajados son sig n ificativ am en te m ás p ro
ductivos y están m ás m otivados que la media. C om
p arten una m eta com ún, una cu ltu ra com ún y, en
m uchos casos, un «sentim iento elitista» que les hace
C o g ita :
únicos.
Majar enequipoesdifícil, peronoimposible. Pero no todos los equipos cuajan. De hecho, muchos
PcterOrscker equipos sufren lo que Jackman llama «toxicidadde equi
po» [ J A C 9 8 ] define cinco factores que «fom entan un
entorno de equipo tóxico potencial»:
4 . El paradigm a sincronizado se basa en la comparti-
m entación natural de un problem a y organiza los
m iem bros del equipo para trabajar en partes del pro
blem a con poca com unicación activa entre ellos.
Cogita:
No importa cual sea el problema, siempre
Constantine [ C O N 9 3 ] propone una variación en el é$ ufi problema del equipo.
equipo descentralizado democrático defendiendo a los Jerry Wemberg
equipos con independencia creativa cuyo enfoque de
trabajo podría ser m ejor llam ado «anarquía innova
dora». A unque se haya apelado al enfoque de libre 1. una atm ósfera de trabajo frenética en la que los
espíritu para el desarrollo del softw are, el objetivo m iem bros del equipo gastan energía y se descentran
principal de una organización de Ingeniería del S oft de los objetivos del trabajo a desarrollar;
ware debe ser «convertir el caos en un equipo de alto
2. alta frustración causada por factores tecnológicos,
rendim iento» [ H Y M 9 3 ] . Para conseguir un equipo de
del negocio, o personales que provocan fricción entre
alto rendim iento.
los m iem bros del equipo;
. Los m iem bros del equipo deben confiar unos en
3. «procedim ientos coordinados pobrem ente o frag
otros.
m entados» o una definición pobre o impropiamente
. La distribución de habilidades debe adecuarse al pro elegida del m odelo de procesos que se convierte en
blema. un obstáculo a saltar;
. Para m antener la unión del equipo, los inconformis- 4. definición confusa de los papeles a desempeñar pro
tas tienen que ser excluidos del mismo duciendo una falta de responsabilidad y la acusación
C ualquiera que sea la organización del equipo, el correspondiente, y
objetivo para todos los gestores de proyecto es colabo 5. «continua y repetida exposición al fallo» que con
rar a crear un equipo que presente cohesión. En su libro, duce a una pérdida de confianza y a una caída de la
Peopfeware, DeM arco y Lister [ D E M 9 8 ] estudian este moral.
aspecto:
Jackm an sugiere varios antitóxicos que tratan los
problem as comunes destacados anteriormente.
Para evitar un entorno de trabajo frenético, el
gesto r de pro y ecto s debería estar seguro de que el
H papel del bibliotecario existe sin tener en cuento
equipo tiene acceso a toda la inform ación requerida
lo estructura del equipo. Poro más detalles véase
el Capítulo 9.
para hacer el trabajo y que los objetivos y m etas prin
cipales, una vez definidos, no deberían m odificarse a
m enos que fuese absolutam ente necesario. Adem ás,
las m alas noticias no deberían guardarse en secreto,
T en d e m o s a u sar la p a la b ra e q u ip o d e m a sia d o lib re
www.FreeLibros.org
m ente en el m u n d o de lo s n eg o cio s, d e n o m in a n d o « e q u i
sino entregarse al equipo tan pronto com o fuese po si
po» a cualquier grupo de gente asignado para trab a ja rju n ta . ble (mientras haya tiem po para reaccionar de un m odo
P ero m uchos de e sto s grupos no p a rec en equipos. N o t ie racional y controlado).
42
CAPÍTULO 3 C O N C E P T O S S OBR E G E S T I Ó N DE P R O Y E C T O S
presenta un argumento lógico, de un m odo ordenado.

Otros son intuitivos, pudiendo tom ar una decisión basán
los equipos formados son lo Ideal, pero no es fácil dose en sus «sensaciones».Algunos desarrolladorespre-
conseguirlos. Como mínimo, esté seguro de evitar fieren una planificación detallada com puesta por tareas
un «entorno tóxico». organizadas que les perm ita lograr el cierre para algún
elem ento de un proyecto. Otros prefieren un entorno
Aunque la frustración tiene muchas causas, los desa- m ás espontáneo donde aspectos abiertos son correctos.
rrolladores de software a m enudo la sienten cuando pier Algunos trabajan duro para tener las cosas hechas mucho
den la autoridad para controlar la situación. Un equipo antes de la fecha de un hito, de ese m odo elim inan la
de software puede evitar la frustración si recibe tanta presión cuando se aproximan a las fechas, m ientras que
responsabilidad para la tom a de decisiones com o sea otros están apurados por las prisas para hacer la entre
posible. Cuanto más control se le de al equipo para tomar ga en el Último minuto. Un estudio detallado de la psi
decisiones técnicas y del proceso, m enos frustración cología de estos rasgos y de las form as en las que un
sentiran los m iem bros del equipo. je fe de equipo cualificado puede ayudar a la gente con
Una elección inapropiada del proceso del software rasgos opuestos para trabajarjuntos está fuera del ám bi
(p.ej., tareas innecesarias o pesadas, pobre elección de to de éste libro4. Sin em bargo, es im portante destacar
los productos del trabajo) puede ser evitada de dos for que el reconocimiento de las diferencias hum anas es el
mas: (1) estando seguros de que las características del prim er paso hacia la creación de equipos que cuajan.
software a construir se ajustan al rigor del proceso ele
gido, y (2) permitiendo al equipo seleccionar el proce 3.2.4. A sp e c to s so b re la co o r d in a ció n
so (con el reconocim iento com pleto de que, una vez y la c o m u n ica ció n
elegido, el equipo tiene la responsabilidad de entregar
Hay m uchos m otivos por los que los proyectos de soft
un producto de alta calidad).
ware pueden tener problem as. La escala (tam año) de
El gestor de proyectos de software, trabajando
m uchos esfuerzos de desarrollo es grande, conduciendo
junto con el equipo, debería refinar claramente los roles
a complejidades, confusión y dificultades significativas
y las responsabilidades antes del comienzo del proyec
para coordinar a los m iem bros del equipo. La incerti-
to. El equipo debería establecer su propios m ecanismos
dumbre es corriente, dando como resultado un continuo
para la responsabilidad (las revisiones técnicas form a
flujo de cambios que im pactan al equipo del proyecto.
les3 son una forma para realizar esto) y definir una serie
La interoperatividad se ha convertido en una caracterís
de enfoques correctivos cuando un miem bro del equi
tica clave de m uchos sistemas. El software nuevo debe
po falla en el desarrollo.
comunicarse con el anterior y ajustarse a restricciones
Todo equipo de software experimentapequeños fallos.
predefinidas impuestas por el sistema o el producto.
La clave para elim inar una atmósfera de fallos será esta
blecer técnicas basadas en el equipo para retroalim entar
y solucionar el problema. Además, cualquier fallo de un
miembro del equipo debe ser considerado como un fallo
del equipo. Esto lleva a un acercamiento del equipo a la Hocer o no hacer: no hay alternativa.
acción correctiva, en lugar de culpar y desconfiar, que Yodé (Star Wors)
ocurre con rapidez en equipos tóxicos.
Estas características del software m oderno — esca
•
¿Cómo debemos evitar la, incertidumbre e in te ro p e ra tiv id a d -s on aspectos de
«toxinas» que con frecuencia la vida. Para enfrentarse a ellos eficazmente, un equi
infectan un equipo de software? po de ingeniería del software debe establecer m étodos
efectivos para coordinar a la gente que realiza el tra
Además de las cinco toxinas descritas por Jackman, bajo. Para lograr esto se deben establecer m ecanism os
un equipo de software a m enudo se enfrenta con los ras de com unicación formales e informales entre los m iem
gos hum anos diferentes de su s m iem bros. A lgunos bros del equipo y entre múltiples equipos. La com uni
miembros del equipo son extrovertidos, otros son intro cación formal se lleva a cabo «por escrito, con reuniones
vertidos. Algunas personas recogen inform ación intui organizadas y otros canales de com unicación relativa
tivamente, separando am plios conceptos de hechos m ente no interactivos e im personales» [KRA95], La
dispares. Otros procesan la inform ación linealm ente, com unicación informal es m ás personal. Los m iem bros
reuniendo y organizando detalles m inuciosos de los de un equipo de software com parten ideas de por sí,
datos proporcionados. A lgunos m iem bros del equipo piden ayuda a m edida que surgen los problem as e inter-
toman las decisiones apropiadas solamente cuando se actúan los unos con los otros diariamente.
www.FreeLibros.org
3 Las revisiones técnicas form ales se tra ta n con detalle en el Capi 4 Se puede encontrar una excelente introducción a e sto s tem as rela
tulo 8. cionados con los equipos de proyectos de softw are en [FER98]
43
IN GE NI E RÍ A DEL SOFTW ARE . UN E N F O Q U E P R Á C T I C O
a pro d u cto s de in g en ie ría del softw are. E sto s incluyen re u

n iones de revisión de estado e insp eccio n es de diseño y de
código.
revisiones de diseño# / iiñ to rm e s de seguimiento ¿Cómo coordinar

revisiones de requisitos# S
. ,
reuniones de grupo ¡ r .
de errores
d isp o s ició n o y g «revisiones de estado
correo electrónico
. ,
• inspecciones de código
• las acciones de los miembros
del equipo?
o boletines del proyecto Informal, procedimientos interpersonales.Incluyen reu

niones de grupo para la divulgación de inform ación y resolu
ción de pro b lem as así com o «definición de req u isito s y del
i código fuente
i contenido del diccionario de datos personal de desarrollo».
Comunicación electrónica. C om prende correo electróni
co, boletines de noticias electrónicosy, por extensión, sistem as
i herramientas de control del proyecto
de videoconferencia.
Red interpersonal.D iscusiones inform ales con los m iem
bros del equipo y con personas que no están en el proyecto pero
3 4 5 6 que pueden tener experiencia o una profunda visión que pue
em pleo d e la técnica d e coordinación de ayudar a los m iem bros del equipo.
■ E nfoque im personal, formal P ara v alorar la eficacia de estas técnicas para la c o o r

• P rocedim iento interpersonal, formal
d in a ció n de proyectos, K raul y S treeter estudiaron 65
o P rocedim iento interpersonal, informal
o Com unicación electrónica proyectos de softw are con cientos de personas im plica
a Red interp erso nal das. L a F ig u ra 3.1 (ad ap tad a de [K R A 95]) ex p resa el
v alo r y em pleo de las técnicas de coordinación apunta
das anteriorm ente. E n la figura, el v alor percibido (cla-
F IG U R A 3.1. V alor y e m p le o d e té c n ic a s d e c o o rd in a c ió n sificad o en u n a escala de siete puntos) de varias técnicas
y c o m u n ic a c ió n .
de com unicación y coordinación es contrastado con su
frecuencia de em pleo en un proyecto. Las técnicas situa
K raul y Streeter [K RA 95] ex am inan u n a colección
das p o r encim a de la línea de reg resión fueron «ju zg a
de técnicas de co ordinación de p royectos que se cate-
das co m o rela tiv am e n te valio sas, d ad o la can tid a d de
gorizan de la siguiente m anera:
veces que se em plearon» [K RA 95]. Las técnicas situa
Formal, enfoque impersonal. Incluyen d ocum entos de das por debajo de la línea se consideraron de m enor valor.
ingeniería del softw are y entregas (incluyendo el código fuen
Es interesante resaltar que las redes interpersonales fu e
te), m em orandos técnicos, h itos del pro y ecto , planificacio
nes del p ro g ra m a y h e rra m ie n ta s d e c o n tro l del p ro y e cto ro n catalo g ad as co m o las técn icas de m a y o r v a lo r de
(C apítulo 7), p eticiones de c am bios y docum entación relati coordinación y de com unicación. Es tam bién im portan
va (C apítulo 9 ), inform es de seguim iento de errores e infor te hacer n o tar que los prim eros m ecanism os de garantía
m ación alm acenada (C apítulo 3 1). de calidad del softw are (requisitos y revisiones de dise
Formal, procedimientos interpersonales. Se c en tra en ño) p arecieron ten er m ás v alo r que evaluaciones po ste
las actividades de garantía de calidad (C apítulo 8) ap licada riores de código fuente (inspecciones de código).
3-3 PR O D U C TO _____________________
El gestor de un proyecto de softw are se enfrenta a un dile 3.3.1. Á m b ito d e l so ftw a re
m a al inicio de u n p royecto de ingeniería del softw are. L a prim era actividad de gestión de un proyecto de soft
Se req u ieren estim aciones cuantitativas y un p lan o rg a w are es determ inar el á m b ito del softw are. El ám bito se
nizado, pero no se dispone de inform ación sólida. U n define respondiendo a las siguientes 'cuestiones:
an álisis d etallad o de los re q u isito s del so ftw are p ro
p orcio n aría la inform ación n ecesaria p ara las estim a
ciones, pero el análisis a m enudo lleva sem anas o m eses.
Aún peor, los requisitos p u ed en ser fluidos, cam biando Si no puede delimitar una característica de/software
regularm ente a m ed id a que pro g resa el proyecto. Y, aún que intento construir, considérela característicacomo
un riesgo principal de/proyecto.
así, se n ecesita u n plan «¡ya!».
P o r tan to , d eb em o s ex am in ar el p ro d u cto y el p ro Contexto. ¿C óm o en caja el softw are a construir
www.FreeLibros.org
b lem a a re so lv e r ju s to al in ic io d el p ro y e c to . P o r lo en un siste m a , p ro d u c to o c o n te x to de n e g o c io s
m e n o s se d e b e e s ta b le c e r el á m b ito d el p ro d u c to y m ay o r y qué lim itaciones se im ponen com o resu lta
delim itarlo . do del contexto?
44
CAPÍTULO 3 C O N C E P T O S S OB RE G E S T I Ó N E E P R O Y E C T O S
O bjetivos de inform ación. ¿Qué objetos de datos Las funciones del software, descritas en la exposi
visibles al cliente (Capítulo 11) se obtienen del softwa ción del ám bito, se evalúan y refinan para proporcionar
re? ¿Qué objetos de datos son requeridos de entrada? más detalle antes del comienzo de la estim ación (Capí
F unción y rendim iento. ¿Qué función realiza el tulo 5). Puesto que ambos, el coste y las estim aciones
software para transform ar la inform ación de entra de la planificación temporal, están orientados funcio
da en una salida? ¿Hay características de rendimiento nalmente, un pequeño grado de descomposición suele
especiales que abordar? ser útil.
Por ejem plo, considere un proyecto que construirá
El ámbito de un proyecto de software debe ser uní
un nuevo procesador de textos. Entre las características
voco y entendible a niveles de gestión y técnico. Los
peculiares del producto están: la introducción de infor
enunciados del ám bito del software deben estar deli
m ación a través de la voz así com o del teclado; carac
mitados.
terísticas extrem adam ente sofisticadas de «edición
Es decir, los datos cuantitativos (por ejemplo: núm e
autom ática de copia»; capacidad de diseño de página;
ro de usuarios simultáneos, tam año de la lista de correo,
indexación autom ática y tabla de contenido, y otras. El
máximo tiem po de respuesta permitido) se establecen
gestor del proyecto debe establecer prim ero la exposi
explícitamente; se anotan las limitaciones (por ejemplo:
ción del ám bito que delim ita estas características (así
el coste del producto limita el tam año de la m emoria) y
com o otras funciones m ás norm ales, com o edición,
se describen los factores de reducción de riesgos (por
adm inistración de archivos, generación de docum en
ejemplo: los algoritmos deseados se entienden muy bien
tos). Por ejem plo, ¿requerirá la introducción de infor
si están disponibles en C++).
m ación m ediante voz «entrenam iento» por parte del
usuario? ¿Qué capacidades específicas proporcionará
3.3.2. D e sc o m p o sic ió n d el p ro b le m a la característica de editar copias? ¿Exactam ente cóm o
La descomposición del problema, denominado a veces será de sofisticado la capacidad de diseño de página?
particionado o elaboración delproblema, es una activi
dad que se asienta en el núcleo del análisis de requisitos
im m s m s m
del software (Capítulo 11). Durante la actividad de expo Bi el Capítulo 12 sepresentounatécnica útil paro
sición del ámbito no se intenta descomponer el proble descomponer el problema, lomada «análisis gramatical».
ma totalmente. Más bien, la descomposición se aplica en
dos áreas principales: (1) la funcionalidadque debe entre
garse y (2) el proceso que se em pleará para entregarlo. A m edida que evoluciona la exposición del ámbito,
un prim er nivel de partición ocurre de form a natural. El
equipo del proyecto sabe que el departamento de m ar
keting ha hablado con clientes potenciales y ha averi
guado que las siguientes funciones deberían ser parte
de la edición autom ática de copia: (1) com probación
Para desarrollar un plan de proyecto razonable, tiene ortográfica; (2) com probación gramatical; (3) com pro
que descomponer funcionalmente el problema a resolver
bación de referencias para documentos grandes (p. ej.:
¿se puede encontrar una referencia a una entrada biblio
Los seres hum anos tienden a aplicar la estrategia de gráfica en la lista de entradas de la bibliografía?), y (4)
divide y vencerás cuando se enfrentan a problemas com validación de referencias de sección y capítulo para
plejos. Dicho de manera sencilla, un problem a complejo documentos grandes. Cada una de estas características
se parte en problem as m ás pequeños que resultan más representa una subfunción para im plernentar en soft
manejables. Ésta es la estrategia que se aplica al inicio ware. C ada una puede ser aún m ás refinada si la des
de la planificación del proyecto. com posición hace m ás fácil la planificación.
- i Q & E S .Q
Las fases genéricas que caracterizan el proceso de soft • el m odelo incremental
ware d e fin ic ió n , desarrollo y soporte— son aplicables • el m odelo en espiral
a todo software. El problema es seleccionar el modelo de
■ el m odelo en espiral W INW IN
proceso apropiado para la ingeniería del software que debe
aplicar el equipo del proyecto. En el Capítulo 2 se estudió • el m odelo de desarrollo basado (ensamblaje) en com
una gran gama de paradigmas de ingeniería del software: ponentes
el m odelo de desarrollo concurrente
www.FreeLibros.org
• el modelo secuencia1 lineal
• el modelo de prototipo • el m odelo de métodos form ales
• el modelo DRA el m odelo de técnicas de cuarta generación
45
I N G E N IE RÍ A DEL S O F TW A RE . UN E N F O Q U E P R A C T I C O
• Comunicación con el cliente— tareas requeridas para

establecer la obtención de requisitos eficiente entre
Uno vez eleyido el modelo de proceso, ocompóñelo con el desarrollador y el cliente.
el mínimo conjunto de toreas de trabajo y productos que . P lanificación— tareas requeridas para definir los
desembocaron en un producto de alta calidad - e v í t e l a
recursos, la planificación tem poral del proyecto y
capocidad de destrucción del p r o c e s e .
cualquier inform ación relativa a él.
El gestor del proyecto debe decidir qué m odelo de

proceso es el más adecuado para (1) los clientes que han
solicitado el producto y la gente que realizará el traba Recuerde.... las actividades estructurales se aplican
jo ; (2)l as características del producto en sí, y (3)el entor en todos los proyectos- no hoy excepciones.
no del proyecto en el que trabaja el equipo de software.
Cuando se selecciona un m odelo de proceso, el equipo « Análisis del riesgo— tareas requeridas para valorar
define entonces un plan de proyecto prelim inar basado los riesgos técnicos y de gestión.
en un conjunto de actividades estructurales. U na vez « Ingeniería— tareas requeridas para construir una o
establecido el plan prelim inar, em pieza la descom posi más representaciones de la aplicación.
ción del proceso. Es decir, se debe crear un plan com • Construcción y entrega— tareas requeridas para cons
pleto reflejando las tareas requeridas a las personas para truir, probar, instalar y proporcionar asistencia al usua
cubrir las actividades estructurales. Exploramos estas rio (por ejemplo: docum entación y formación).
actividades brevem ente en las secciones que siguen y
• Evaluación del cliente— tareas requeridas para obte
presentam os una visión más detallada en el Capítulo 7.
ner inform ación de la opinión del cliente basadas en
la evaluación de las representaciones de software
3.4.1. M a d u r a c ió n d e l p r o d u c to y d e l p r o c e s o creadas durante la fase de ingeniería e implementa-
La planificación de un proyecto em pieza con la m adu das durante la fase de instalación.
ración del producto y del proceso. Todas las funciones Los miembros del equipo que trabajan en cada función
que se deben tratar dentro de un proceso de ingeniería aplicarán todas las actividades estructurales. En esencia,
por el equipo de software deben pasar por el conjunto se crea una matriz similar a la que se muestra en la Figu
de actividades estructurales que se han definido para ra 3.2. Cada función principal del problema (la figura con
una organización de software. A sum a que la organiza tiene las funciones para el software procesador de textos
ción ha adoptado el siguiente conjunto de actividades comentado anteriorm ente) se lista en la colum na de la
estructurales (Capítulo 2): izquierda. Las actividades estructurales se listan en la fila
/ .£ X> /
/ / .g'4
¿ ^ / '<?
ACTIVIDADES ESTRUCTURALES / | /
& / £
DE PROCESO C O M U NES / / i? / ^ .
/ $
/ ° 8 / $ / b
/
Tareas de Ingeniería del Softw are
Funciones del producto

Introducción de texto
Edición y form ateo
Edición autom ática de copia
Capacidad de diseño de página
Indexación automática y TOC
Administración de archivos
\
Producción de documentos
www.FreeLibros.org
F IG U R A 3 . 2 . M aduración del problem a y del proceso.
46
CAPITULO 3 C O N C E P T O S S O B R E G E S T I Ó N DE P R O Y E C T O S
de arriba. Las tareas de trabajo de ingeniería del software ECP?», Por ejemplo, un pequeño proyecto, relativamen
(para cada actividad estructural) se introducirían en la fila te simple, requiere las siguientes tareas para la actividad
siguiente5. El trabajo del gestor del proyecto (y de otros de comunicación con el cliente:
miembros del equipo) es estimar los requisitos de recur 1. Desarrollar una lista de aspectos que se han de cla
sos para cada celda de la matriz, poner fechas de inicio y rificar.
finalización para las tareas asociadas con cada celda y los 2. Reunirse con el cliente para resolver los aspectos
productos a fabricar como consecuencia de cada celda. que se han de clarificar.
Estas actividades se consideran en los Capítulos 5 y 7. 3 . D esarrollar conjuntam ente una exposición del
ám bito del proyecto.
4. Revisar el alcance del proyecto con todos los im pli
CLAVE cados.
5. Modificar el alcance del proyecto cuando se requiera.
La descomposicióndel producto y del procesóse produce
simultáneamente con la evolución del plan de proyecto. Estos acontecimientospueden ocurrir en un periodo de
menos de 48 horas. Representan una descomposición del
problem a apropiado para proyectos pequeños relativa
3.4.2.D e sc o m p o sic ió n d e l p roceso
mente sencillos.
Un equipo de software debería tener un grado significa Ahora, considerem os un proyecto más complejo que
tivo de flexibilidad en la elección del paradigma de inge tenga un ámbito más amplio y un mayor impacto com er
niería del software que resulte mejor para el proyecto y cial. Un proyecto como ése podría requerir las siguientes
de las tareas de ingeniería del software que conform an el tareas para la actividad de comunicación con el chente:
modelo de proceso una vez elegido. Un proyecto relati
1. Revisar la petición del chente.
vamente pequeño similar a otros que se hayan hecho ante
riormente se debería realizar con el enfoque secuencia 1 2. Planificar y program ar una reunión formal con el
lineal. Si hay límites de tiem po muy severos y el proble chente.
ma se puede compartim entarm ucho, el m odelo apropia 3 . Realizar una investigación para definir solucionespro-
do es el DRA (en inglés RAD). Si la fecha límite está tan puestasy enfoques existentes.
próxima que no va a ser posible entregar toda la funcio 4. Preparar un «documentode trabajo» y una agenda para
nalidad, una estrategia incremental puede ser lo mejor. la reunión formal.
Similarmente,proyectos con otras características(p. ej.: 5. Realizar la reunión.
requisitos inciertos, nuevas tecnologías, clientes difíci 6. Desarrollar conjuntamente mini-especificaciones que
les, potencialidad de reutilización) llevarán a la selección reflejen la información, función y características de
de otros modelos de proceso6. comportamiento del software.
^ O N S E jd J fy
Aplique siempre la ECP (Estructura Común de Proceso),
sin tener en cuenta el tamaño, criticidad o tipo del
proyecto. Las tareas pueden variar pero la ECP no.
Modelo de proceso adaptable.
Una vez que se ha elegido el m odelo de proceso, la
7. Revisartodas las mini-especificaciones para com pro
estructura común de proceso (ECP) se adapta a él. En todos
bar su corrección, su consistencia,la ausencia de ambi
los casos, el ECP estudiado anteriormente en este capítu
güedades.
lo -com unicación con el cliente, planificación, análisis
de riesgo, ingeniería, construcción, entrega y evaluación 8. Ensamblarlasmini-especificacionesenun documento
del chente— puede adaptarse al paradigma. Funcionará de alcance del proyecto.
para modelos lineales, para modelos iterativos e incre 9. Revisar ese documento general con todo lo que pueda
méntales,para modelos de evolución e .incluso para mode afectar.
los concurrenteso de ensamblaje de componentes.El ECP 10. M odificar el docum ento de alcance del proyecto
es invariable y sirve como base para todo el trabajo de cuando se requiera.
software realizado por una organización. Ambos proyectos realizan la actividad estructural que
Pero las tareas de trabajo reales sí varían, La descom denominamos comunicación con el cliente, pero el equipo
posición del proceso comienza cuando el gestor del pro del prim er proyecto lleva a cabo la m itad de tareas de
yecto pregunta: «¿Cómo vamos a realizar esta actividad ingeniería del software que el segundo.
5 Se hace notar que las tareas se deben adaptar a las necesidades 6 Recuerde que las características del proyecto tienen tam bién una
www.FreeLibros.org
específicasde un proyecto. Las actividades estructurales siempre per fuerte influencia en la estructura del equipo que va a realizar el tra
manecen igual, pero las tareas se seleccionarán b asándose en unos bajo. Vea la Sección 3.2.3.
criteriosde adaptación. Este tem a es discutido m ás adelante en el
Capitulo 7 y en la página Web SEPA 5 /e.
47
3.5 PROYECTO_____________________
P ara g estio n ar un pro y ecto de softw are con éx ito , vaya a estar involucrado en el proyecto. Se refuer
debem os com prender qué puede ir m al (para evitar za construyendo el equipo adecuado (Sección 3.2.3)
esos problem as) y cóm o hacerlo bien. En un excelente y dando al equipo la autonomía, autoridad y tecno
docum ento sobre proyectos de softw are, John Reel logía necesaria para realizar el trabajo.
[REE99] define diez señales que indican que un pro M antenerse. M uchos proyectos no realizan un
yecto de sistem as de inform ación está en peligro: buen comienzo y entonces se desintegran lentamente.
Para m antenerse, el gestor del proyecto debe pro
porcionar incentivos para conseguir una rotación del
personal m ínim a, el equipo debería destacar la cali
U mms 7 de los 10 señóles que indican el fallo de dad en todas las tareas que desarrolle y los gestores
en proyecto de sistemas de información se veteranos deberían hacer todo lo posible por per
ÉáwsÉüsi antes de! desarrollo de un diseño m anecer fuera de la form a de trabajo del equipo7.
flORtesde escribir una linea de código. Seguimiento del Progreso. Para un proyecto de
software, el progreso se sigue mientras se realizan los
productos del trabajo (por ejemplo, especificaciones,
código fuente, conjuntos de casos de prueba) y se
1 . La gente del softw are no com prende las n ecesi
dades de los clientes. aprueban (utilizando revisiones técnicas formales)
como parte de una actividad de garantía de calidad.
2. El ám bito del producto está definido pobrem ente. Además, el proceso del software y las m edidas del
3. Los cam bios están m al realizados. proyecto (capítulo4) pueden ser reunidas y utilizadas
4. La tecnología elegida cambia. para evaluar el progreso frente a promedios desarro
llados por la organización de desarrollo de software.
5. Las necesidades del negocio cam bian [o están mal
Tom ar D ecisiones Inteligentes. En esencia, las
definidas].
decisiones del gestor del proyecto y del equipo de
6. Las fechas de entrega no son realistas. software deberían «seguir siendo sencillas». Siem
7. Los usuarios se resisten. pre que sea po sib le, u tilice softw are del m ism o
8. Se pierden los patrocinadores [o nunca se ob tu com ercial o com ponentes de softw are existentes;
evite p ersonalizar interfaces cuando estén dispo
vieron adecuadam ente].
nibles aproxim aciones estándar; identifique y eli
9. El equipo del proyecto carece del personal con las m ine entonces riesgos obvios; asigne m ás tiempo
habilidades apropiadas. del que pensaba necesitar para tareas arriesgadas
10.Los gestores [y los desarrolladores] evitan buenas o com plejas (necesitará cada minuto).
prácticas y sabias lecciones.
L os profesionales veteranos de la industria hacen
re fere n cia frecu en tem en te a la re g la 9 0 -9 0 cuando
estudian proyectos de software particularm ente d ifí Referencia
ciles: el prim er 90 por 100 de un sistem a absorbe el
Se puede encontrar un gran conjunto de recursos
90 por 100 del tiem po y del esfuerzo asignado. El últi
que pueden ayudar tanto a gestores de proyecto
m o 10 por 100 se lleva el otro 90 por 100 del esfuer
experimentados como a principiantes en:
zo y del tiem po asignado [ZA H 94]. Los factores que
www.pmi.org,www.4pm.com y
conducen a la regla 90-90 están contenidos en las diez
www.projectmanagement.com
señales destacadas en la lista anterior.
¡Suficiente negatividad! ¿Cómo actúa un gestor para
evitar los problem as señalados anteriorm ente? Reel Realizar un Análisis «Postmortem» (despuésde fina
[REE99] sugiere una aproxim ación de sentido común lizar el proyecto}. Establecer un m ecanismo consis
a los proyectos de software dividida en cinco partes: tente para extraer sabias lecciones de cada proyecto.
Empezar con el p ie derecho. Esto se realiza tra Evaluar la planificación real y la prevista, reunir y ana
bajando duro (muy duro) para com prender el pro lizar métricas del proyecto de software y realimentar
blem a a solucionar y estableciendo entonces con datos de los miembros del equipo y de los clien
objetivos y expectativasrealistas para cualquiera que tes, y guardar los datos obtenidos en formato escrito.
www.FreeLibros.org
7 Esta frase implica la reducción al m ínim o de la burocracia, y la eli
m inación tan to de reuniones extrañas com o de la adherencia dog
m ática a las reglas del proceso y del proyecto. El equipo debena estar
capacitado p ara realizar esto.
48
CAPÍTULO 3 C O N C E P T O S SOBRE GESTIÓN EE PR O Y EC T O S
En un excelente docum ento sobre proyectos y proce ponsabilidad de cada m iem bro del equipo de so ft
so del software,Barry Boehm [BOE96] afirma: «... se w are debe estar definida. L a re sp u esta a la p re
necesita un principio de organización que haga una gunta ayuda a cum plir esto.
simplificación con el fin de proporcionar planes [de ¿D ónde están situados organizacionalm ente?
proyectos] sencillos para proyectos pequeños». Boehm N o todos los roles y responsabilidades residen en
sugiere un enfoque que trate los objetivos, hitos y pla el equipo de softw are. El cliente, los usuarios, y
nificación, responsabilidades, enfoque técnico y de otros directivos tam bién tienen responsabilidades.
gestión, y los recursos requeridos del proyecto. Bohem
lo llama el principio «W W W W W H H », después de
una serie de preguntas (7 cuestiones) que conducen a
la definición de las características clave del proyecto
y el plan del proyecto resultante:
i
¿Por qué se desarrolla el sistema? La respuesta a 12
E
esta pregunta permite a todas las partes evaluar la vali
dez de las razones del negocio para el trabajo del soft Plan de Proyecto de Softw are
ware. Dicho de otra forma, ¿justifica el propósito del

negocio el gasto en personal, tiempo, y dinero? ¿Cómo estará realizado el trabajo desde el p u n
¿Qué se realizaráy cuándo? La respuesta a estas to de vista técnico y de gestión? U na vez estab le
preguntas ayuda al equipo a establecer la planifi cido el ám bito del producto, se debe defin ir una
cación del proyecto identificando las tareas clave estrategia técnica y de gestión para el proyecto.
del proyecto y los hitos requeridos por el cliente. ¿Q ué cantidad de cada recurso se necesita? La
respuesta a esta pregunta se deriva de las estim a
cio n es re alizad a s (C apítulo 5) b asadas en re s
A ¿Qué preguntas necesitan
puestas a las preguntas anteriores.
W ser respondidas para
desarrollar un Plan de Proyecto? E1 principio W 5HH de Boehm es aplicable sin tener
en cuenta el tam año o la com plejidad del proyecto de
softw are. Las preguntas señaladas proporcionan un
¿Quién es el responsable de unafunción? A ntes perfil de planificación al gestor del proyecto y al equi
en este capítulo, señalam os que el papel y la res- po de software.
J a r*P R Ü .-C T T Ü IIS C R Í T I C A S , ■
El C oncilio8 A irlie ha d esarro llad o una lista de uno de los riesgos ¿cuál es la oportunidad de que
«prácticas críticas de software para la gestión basada el riesgo se convierta en un problem a y cuál es el
en el rendimiento». Estas prácticas son «utilizadas de im pacto si lo hace?
un modo consistente por, y consideradas críticas por, C oste em pírico y estim ación de la planificación.
organizaciones y proyectos de software de m ucho éxi ¿Cuál es el tam año actual estim ado de la aplicación
to cuyo rendim iento "fin al” es m ás consistente que de software (sin incluir el software del sistema) que
los promedios de la industria» [AIR99]. En un esfuer será entregada en la operación? ¿Cómo se obtuvo?
zo por perm itir a una organización de software d eter
minar si un pro y ecto esp ecífico ha im plem entado
prácticas críticas, el C oncilio A irlie ha desarrollado
un conjunto de preguntas de «Visión Rápida» [AIR99]
para un proyecto’:
Gestión fo rm a l del riesgo. ¿Cuáles son los diez
riesgos principales para este proyecto? Para cada Visión rápida del Proyecto Airlie
www.FreeLibros.org
8 El Concilio Airlie es un equipo de expertos en ingeniería del software 9 Solo se destacan aquí aquellas practicas críticas relacionadas con
promocionadopor el Departamento de Defensa U .S.ayudando en el la «integridad del proyecto)).O tras practicas m ejores se trataran en
desarrollo de directrices para prácticas im portantes en la gestión de capítulos posteriores.
proyectos de software y en la ingeniería del Software.
49
I N GEN IE RÍ A DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
Gestión de proyectos basada en métricas. ¿Dis de el principio del programa y del número de defectos
pone de un programa de métricas para dar una prime que se corrigen y se producen en la actualidad?
ra indicación de los problemas del desarrollo? Si es así, G estión del program a del personal. ¿Cuál es
¿cuál es la volatilidad de los requisitos actualmente? la m edia de rotación de la plantilla en los tres Ulti
Seguim iento del valor ganado. ¿Inform a m en m os m eses por cada uno de los distribuidores/desa-
sualm ente de las m étricas del valor gan ad o ...? Si rro llad o res inv o lu crad o s en el d esarro llo del
es así, ¿están calculadas estas m étricas desde una software para este sistem a?
red de actividades de tareas para el esfuerzo total Si un equipo de proyectos de softw are no puede
a la próxim a entrega? resp o n d er a estas preg u n tas, o las responde in ad e
Seguimientode defectos frente a objetivos de cali cuadam ente, se debe realizar una revisión com pleta
dad. ¿Realiza el seguimientoe informaperiódicamente de las prácticas del proyecto. C ada una de las prácti
del número de defectos encontradosen cada prueba de cas críticas señaladas anteriormente se tratan con deta
inspección [revisión técnica formal] y ejecución des- lle a lo largo de la Parte II de este libro.
JE S U J4 E IL _
L a gestión de proyectos de software es una actividad pletar el trabajo. Finalmente, el proyecto debe organi
protectora dentro de la ingeniería del software. Em pie zarse de una m anera que perm ita al equipo de software
za antes de iniciar cualquier actividad técnica y con tener éxito.
tinúa a lo largo de la definición, del desarrollo y del El elem ento fundam ental en todos los proyectos de
m antenim iento del softw are. software es el personal. Los ingenieros del software
Hay cuatro « P 's » que tienen una influencia sustan pueden organizarse en diferentes organigramas de equi
cial en la gestión de proyectos de software - p e r s o n a l , po que van desde las jerarq u ías de control tradiciona
producto, proceso y proyecto— . El personal debe orga les a los equipos de «paradigm a abierto». Se pueden
nizarse en equipos eficaces, m otivados para hacer un aplicar varias técnicas de coordinación y com unica
software de alta calidad y coordinados para alcanzar una ción para apoyar el trabajo del equipo. En general, las
com unicación efectiva. L os requisitos del producto revisiones form ales y las com unicaciones informales
deben com unicarse desde el cliente al desarrollador, persona a persona son las m ás valiosas para los pro
dividirse (descom ponerse) en las partes que lo consti fesionales.
tuyen y distribuirse para que trabaje el equipo de soft L a actividad de gestión del proyecto com prende
ware. El proceso debe adaptarse al personal y al m edición y m étricas, estim ación, análisis de riesgos,
problema. Se selecciona una estructura com ún de pro p lanificación del program a, seguim iento y control.
ceso, se aplica un paradigm a apropiado de ingeniería C ada uno de estos aspectos se trata en los siguientes
del software y se elige un conjunto de tareas para com capítulos.
[AIR99] Airlie Council, «Performanced Based Management: ware Engineering, vol. 31, n.‘ 11, Noviembre de 1988,
The Program M anager’s Guide Based on the 16-Point pp. 1268-1287.
Plan and Related M etrics», Draft Report, 8 de Marzo,
[CUR94] Curtís, B., et al., People M anagem ent Capahi-
1999.
lity M a turity M odel, Softw are Engineering Institute,
[BAK72] Baker, F.T., «Chief Programmer Team M anage Pittsburgh, PA, 1994.
ment of Production Programming», IBM Systems Jour
nal, vol. 11,n.e 1, 1972, pp. 56-73. ‘ [DEM98] DeM arco, T., y T. Lister, Peopleware, 2: edi-
ción, Dorset House, 1998.
[BOE96] Boehm, B., «Anchoring the Software Process»,
IEEE Software, vol. 13,n.9 4, Julio de 1996,pp. 73-82. [EDG95] Edgemon, J., «Right S tuff How to Recognize
It W hen Selecting a Project M anager», A pplication
[CON93] Constantine, L., «Work Organization: Paradigms
Development. Trends, vol. 2, n.9 5, Mayo de 1995,pp.
for Project Management and Organization», CACM, vol.
37-42. '
3 6 ,n .e 10 ,Octubre de 1993, pp. 34-43.
[COU80] Cougar, J., y R. Zawacky, M anaging and Moti- [FER98] Ferdinandi, P. L., «Facilating Communication»,
www.FreeLibros.org
vating Computer Personnel, Wiley, 1980. IEEE Software, Septiembre de 1998, pp. 92-96.
[CUR88] Curtís, B., et.al, «A Field Study of the Software [JAC98] Jackman, M., «Homeopathic Remedies for Team
Design Process for Large Systems», IEEE Trans. Soft Toxicity», IEEE Software, Julio de 1998, pp. 43-45.
50
CAPÍTULO 3 C O N C E P T O S S O B R E G E S T I Ó N DE P R O Y E C T O S
[KRA95] Kraul, R., y L. Streeter, «Coordination in Software [REE99] Reel, J.S., «Critical Sucoess Factors in Software
Development», CACM, vol. 38, n.Q3, Marzo de 1995, pp. Projects», IEEE Software, Mayo de 1999,pp. 18-23.
69-81. [WEI86] Weinberg, G., On Becoming a Techrtical Leader,
[MAN81] Mantei, M., «The Effect of Programming Team Dorset House, 1986.
StructuresonProgramming Tasks», G4CA/,vol. 24, n." 3, [WIT94] Whitaker, K., Managing Software Maníaos, Wiley,
Maizode 1981, pp. 106-113. 1994. '
[PAG85] Page-Jones, M., Practica1 ProjectM anagem ent, [ZAH94] Zahniser, R., «Timeboxing for Top Team Perfor
Dorset House, 1985,p. VII. mance», SoftVi’are Development, Marzo de 1994,pp. 35-38.
3.1. Basándose en la información contenida en este capítu por el mercado de entretenimiento casero es intensa, hay cier
lo y en su propia experiencia, desarrolle «diez mandamien ta presión para terminar el trabajo rápidamente. ¿Qué estruc
tos» para potenciar a los ingenieros del software. Es decir, tura de equipo elegiría y por qué? ¿Qué modelo(s) de proceso
haga una lista con las diez líneas maestras que lleven al per de software elegiría y por qué?
sonal que construye software a su máximo potencial. 3.8. Se le ha nombrado gestor de proyecto de una gran com
3.2. El Modelo de Madurez de Capacidad de Gestión de Per pañía de productos software. Su trabajo consiste en dirigir la
sonal (MMCGP)del Instituto de Ingeniería del Software hace versión de la siguiente generación de s u famoso procesador
un estudio organizado de las «áreas clave prácticas (ACP)» de textos. Como la competencia es intensa, se han estableci
que cultivan lo s buenos profesionales del software. Su profe do y anunciado fechas límite rígidas. ¿Qué estructura de equi
sor le asignará una ACP para analizar y resumir. po elegiría y por qué? ¿Qué modelo(s) de proceso de software
3.3. Describa tres situaciones de la vida real en las que el
elegiría y por qué?
cliente y el usuario final son el mismo. Describa tres situa 3.9. Se le ha nombrado gestor de proyecto de software de una
ciones en que son diferentes. compañía que trabaja en el mundo de la ingeniería genética.
Su trabajo es dirigir el desarrollo de un nuevo producto de soft
3.41. Las decisiones tomadas por una gestión experimentada
ware que acelere el ritmo de impresión de genes. El trabajo es
pueden tener un impacto significativoen la eficacia de un equi
orientado a I+D, pero la meta es fabricar el producto dentro del
po de ingeniería del software. Proporcione cinco ejemplos para
siguiente año. ¿Qué estructura de equipo elegiría y por qué?
ilustrar que es cierto.
¿Qué modelo(s) de proceso de software elegiría y por qué?
3.5. Repase el libro de Weinberg [WEI86] y escriba un resu 3.10. Como muestra la Figura 3.1, basándose en los resulta
man de dos o tres páginas de los aspectos que deberían tener dos de dicho estudio, los documentos parecen tener más uso
se en cuenta al aplicar el modelo MOI. que valor. ¿Por qué cree que pasó esto y qué se puede hacer
3.6. Se le ha nombrado gestor de proyecto dentro de una para mover el punto documentos por encima de la línea de
organización de sistemas de información. Su trabajo es cons regresión en el gráfico? Es decir, ¿qué se puede hacer para
truir una aplicación que es bastante similar a otras que ha cons mejorar el valor percibido de los documentos?
truido su equipo, aunque ésta es mayor y más compleja. Los 3.11. Se le ha pedido que desarrolle una pequeña aplicación
requisitos han sido detalladamente documentados por el clien que analice todos lo s cursos ofrecidos por la universidad e
te. ¿Qué estructura de equipo elegiría y por qué? ¿Qué mode- informe de las notas medias obtenidas en los cursos (para un
lo(~c)e proceso de software elegiría y por qué? periodo determinado). Escriba una exposición del alcance que
3.7. Se le ha nombrado gestor de proyecto de una pequeña abarca este problema.
compañía de productos software. Su trabajo consiste en cons 3.12. Haga una descomposición funcional de primer nivel
truir un producto innovador que combine hardware de reali de la función diseño de página tratado brevem ente en la
dad virtual con software innovador. Puesto que la competencia Sección 3.3.2.
K M ¿JJL C IE B A ^ lJE ,jgmijEjS-S&.mZJDjlMACÍÓM

Una excelente serie de cuatro volúmenes escrito por Wein proporcionar una nueva visión profunda de los aspectos del
berg (Quality Software Management, Dorset House, 1992, proyecto de software y de su gestión. Purba y Shah (How to
1993,1994,1996)introduce los conceptos básicos sobre sis Manage aSuccessful Software Project, Wiley, 1995)presen-
temas y conceptos de gestión, explica cómo usar medicio tan un número de estudios de casos de proyectos que indican
nes eficazmente y m enciona la «acción congruente», la por qué unos fracasaron y otros fueron un éxito. Bennatan
habilidad de «encajar» las necesidades del gestor, del per (Software Project Management in a Client/Server Environ-
sonal técnico y las del negocio. Proporciona información ment, Wiley, 1995) estudia aspectos específicos de gestión
www.FreeLibros.org
Úñ tanto a los gestores noveles como a los experimentados. asociados con el desarrollo de sistemas cliente/servidor.
Brooks (The M ythical M an-M onth, Aniversary Edition, Sepuede argumentar que el aspecto más importante de la
Addison-Wesley, 1995) ha actualizado su clásico libro para gestión del proyecto de software es la gestión de personal. El
51
IN GE NI E RÍ A DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
libro definitivo sobre este tema lo escribieron DeMarco y Lis- jo más eficazmente. House (T heH um an Side d Project
ter [DEM98], pero se han publicado en los Últimos años los M anagement, Addison-Wesley, 1988)y Crossby (Running
siguientes libros donde se examina su importancia: Things: The art ofM aking Things Happen, McGraw-Hill,
Beaudouin-Lafon, M., Com puter Supported Coopera- 1989)proporcionan directrices prácticas para gestores que
tive Work, W iley-Liss, 1999. deban tratar con problemas humanos y técnicos.
Carm el, E., G lobal Software Teams: C ollaborating Aunque no están relacionados específicam ente con el
Across Borders and Tim eZones, Prentice Hall, 1999. m undo del software, y algunas veces sufren demasiadas
Humphrey, W. S M anaging Technical People: Inno- simplificaciones y amplias generalizaciones, los libros de
vation, Teamwork, and the Software Process, Addison-Wes- gran éxito de Drucker (ManagementChallenges fo r the 21 sí
ley 1997. Century, H arperbusines, 1999), Buckingham y Coffman
Humphrey, W. S., Introduction to the Team o f Software (F irst, B reak A ll the R ules: W hat the W orld’s Greatest
Process, Addison-Wesley, 1999. Managers Do Dijferently, Simón & Schuster, 1999)y Chris-
Jones, P. H Handbook o f Team Design: A Practitio- tensen (TheInnovator's Dilemma, Harvard Business School
ner’s Guide to Team Systems Development, McGraw-Hill, Press, 1997) enfatizan «nuevas reglas» definidas por una
1997. economía que cambia con rapidez. Viejos títulos como The
Karolak, D. S., Global Software Development: M ana One M inute M anager e In Search o f Excellence continúan
ging Virtual Teams and Environm ents, IEEE Com puter proporcionando enfoques valiosos que pueden ayudarle a
Society, 1998. gestionar los temas relacionados con el personal de un modo
Mayer, M., The VirtualEdge: Embracing Technology más eficiente.
forD istrib u ted P ro ject TeamSuccess, Project M anagement En Internet están disponibles una gran variedad de fuen
Institute Publications, 1999. tes de información relacionadas con temas de gestión de pro
Otro excelente libro de Weinberg [WEI86] es lectura yectos de software. Se puede encontrar una lista actualizada
obligada para todo gestor de proyecto y je fe de equipo. Le con referencias a sitios (páginas) web que son relevantes para
dará una visión interna y directrices para realizar su traba los proyectos de software en http://www.pressman5.com.
C A P ÍT U L O
PROCESO DE SOFTWARE
4 Y MÉTRICAS DE PROYECTOS
A medición es fundamental para cualquier disciplina de ingeniería, y la ingeniería del soft
L ware no es una excepción. La medición nos permite tener una visión más profunda propor
cionando un m ecanismo para la evaluación objetiva. Lord Kelvin en una ocasión dijo:
Cuando pueda m edir lo que está diciendo y expresarlo con números, ya conoce algo sobre
ello; cuando no pueda medir, cuando no pueda expresar lo que dice con números, su conoci
miento es precario y deficiente: puede ser el com ienzo del conocimiento, pero en sus pensa
mientos, apenas está avanzando hacia el escenario de la ciencia.
La com unidad de la ingeniería del software ha com enzado finalmente a tom arse en serio las
palabras de Lord Kelvin. Pero no sin frustraciones y sí con gran controversia.
Las métricas del software se refieren a un am plio elenco de m ediciones para el software de
computadora. La m edición se puede aplicar al proceso del software con el intento de m ejorar
lo sobre una base continua. Se puede utilizar en el proyecto del software para ayudar en la esti
m ación, el control de calidad, la evaluación de productividad y el control de proyectos.
Finalmente, el ingeniero de software puede utilizar la medición para ayudar a evaluar la cali
dad de los resultados de trabajos técnicos y para ayudar en la tom a de decisiones táctica a m edi
da que el proyecto evoluciona.
V IS T A Z O R Á P ID O
¿Qué es? El p roceso d el so ftw a re y la s ¿Quién lo h a c e ? L as m étricas d e l soft zan d o m étricas orien tad as a l ta m a ñ o o
m étricas del producto son u n a m edida w a re son a n a liz a d a s y e v a lu a d a s por a la función. El resultado se a n a liz a y
cuantitativa q u e perm ite a l a g e n te del los a d m in istra d o re s d e l softw are. A s e c o m p a ra con p rom edios a n te rio re s
softw are tener u n a visión profunda d e m enudo la s m ed id a s son re u n id a s por d e proyectos sim ila re s realizad o s con
la eficaciadel proceso del softw are y de los in g en iero s d el software. la organización. Se e v a lú a n la s te n
los proyectos q ue d irig e n utilizando el ¿Por q u é e s im portante? Si no m ides, d e n c ia s y se g e n e ra n la s conclusiones.
proceso com o un m arco d e trabajo. Se sólo p o d rá s ju z g a r b a s á n d o te e n u n a ¿Cuál e s e l p rod ucto obtenido?Es un
reúnen los d a to s b á sic o s d e c a lid a d y evaluación subjetiva.M ediante la m edi conjunto d e m étricas d el softw are que
productividad. Estos datos son entonces ción, se p u e d e n se ñ a la r la s ten d en cias p ro p o rcio n a n u n a visión pro fu n d a del
analizados, com parados con prom edios (b u e n a so m alas), realizar m ejores e s ti p roceso y d e la c o m p ren sió n d e l p ro
a n te rio re s, y e v a lu a d o s p a ra d eterm i m aciones, llevar a cab o u n a v e rd a d e ra yecto.
nar la s m ejoras e n la c a lid a d y produc m ejora sobre el tiem po. ¿Cómo p uedo esta r seguro d e q u e lo
tividad. L as m é tric a s son ta m b ié n ¿Cuáles son lo s p asos? C om enzar defi h e h ech o correctam ente? A plican
utilizadas p a ra se ñ a la r á re a s con pro niendo u n conjunto lim itad o d e m ed i do u n p la n d e m ed ició n se n c illo pero
blem as d e m anera q ue se p u e d a n d e sa d a s d e procesos, proyectos y productos c o n siste n te , que n u n c a utilizarem os
rrollar los rem ediosy m ejorar el proceso que se a n fáciles d e recoger. E stas m edi p a ra ev alu ar, p rem iar o c a s tig a r e lre n -
del software. d a s son a m enudo n o rm alizad as u tili dim iento individual.
Dentro del contexto de la gestión de proyectos de software,en primer lugar existe una gran pre
ocupación por las métricas de productividad y de calidad — medidas «de salida» (finalización) del
desarrollo del software, basadas en el esfuerzo y tiempo em pleados, y medidas de la «utilidad» del
producto obtenido— .
Park, Goethert y Florac [PAR96] tratan en su guía de la medición del software las razones por
las que medimos:
Hay cuatro razones para medir los procesos del software, los productos y los recursos:
• caracterizar
www.FreeLibros.org
• evaluar
• predecir
• mejorar
53
I N GE NI E RI A DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
Caracterizamos para comprender mejor los procesos, los productos, los recursos y los entornos y para establecer
las líneas base para las comparaciones con evaluacionesfuturas.
Evaluam ospara determinar el estado con respecto al diseño. Las m edidas utilizadas son los sensores que nos per
miten conocer cuándo nuestros proyectos y nuestros procesos están perdiendo la pista, de modo que podam os poner
los bajo control. También evaluamos para valorar la consecución de los objetivos de calidad y para evaluar el impacto
de la tecnología y las mejoras del proceso en los productos y procesos.
Predecimos para poder planificar. Realizar mediciones para la predicción implica aum entar la com prensión de las
relaciones entre los procesos y los productos y la construcción de modelos de estas relaciones, por lo que los valores
que observamos para algunos atributos pueden ser utilizados para predecir otros. Hacemos esto porque queremos esta
blecer objetivos alcanzablespara el coste, planificación,y calidad - d em anera que se puedan aplicar los recursos apro
piados— . Las medidas de predicción también son la base para la extrapolación de tendencias, con lo que la estimación
para el coste, tiem po y calidad se puede actualizar basándose en la evidencia actual. Las proyecciones y las estima
ciones basadas en datos históricos también nos ayudan a analizar riesgos y a realizar intercambios diseño/coste.
Medimos para mejorar cuando recogemos la información cuantitativa que nos ayuda a identificar obstáculos, pro
blemas de raíz, ineficiencias y otras oportunidades para mejorar la calidad del producto y el rendim iento del proceso.
AJLMEPlEASx MÉIRIC AS, jEJMPi QE DQBEg..

A unque los térm inos m edida, m edición y m étricas se [RAG95]. Un indicador proporciona una visión pro
utilizan a m enudo indistintam ente, es im portante d es funda que perm ite al gestor de proyectos o a los inge
tacar las diferencias sutiles entre ellos. C om o los tér nieros de software ajustar el producto, el proyecto o
m inos «m edida» y «m edición» se pueden u tilizar el proceso para que las cosas salgan mejor.
com o un nom bre o com o un verbo, las definiciones
de estos térm inos se pueden confundir. Dentro del con
texto de la ingeniería del software, una m edida pro
porciona una indicación cuantitativa de la extensión,
cantidad, dim ensiones, capacidad o tam año de algu
nos atributos de un proceso o producto. La m edición
es el acto de determ inar una m edida. El IEEE S ta n
dard G lossaryof Software Engineering Terms [IEEE93]
define métrica como «una m edida cuantitativa del gra
do en que un sistem a, com ponente o proceso posee
un atributo dado». Por ejem plo, cuatro equipos de software están tra
C u ando, sim plem ente, se ha re co p ilad o un solo bajando en un proyecto grande de software. Cada equi
aspecto de los datos (por ejem plo: el núm ero de erro po debe conducir revisiones del diseño, pero puede
res descubiertos en la revisión de un m ódulo), se ha seleccionar el tipo de revisión que realice. Sobre el
establecido una m edida. L a m edición aparece com o exam en de la m étrica, errores encontrados p o r p er
resultado de la recopilación de uno o varios aspectos sona-hora consumidas, el gestor del proyecto notifi
de los datos (por ejem plo: se investiga un núm ero de ca que dos equipos que utilizan m étodos de revisión
re v isio n es de m ódulos para re co p ilar m edidas del m ás form ales presentan un 40 por 100 m ás de erro
número de errores encontrados durante cada revisión). res encontrados p o r perso n a -h o ra consum idas que
U na m étrica del software relata de alguna form a las otros equipos. Suponiendo que todos los parám etros
m edidas individuales sobre algún aspecto (por ejem son iguales, esto proporciona al gestor del proyecto
plo: el núm ero m edio de errores encontrados por revi un indicador en el que los m étodos de revisión más
sión o el núm ero m edio de errores encontrados por form ales pueden p ro p o rcio n ar un ahorro m ayor en
persona y hora en re v isio n es’). inversión de tiem po que otras revisiones con un enfo
Un ingeniero del software recopila m edidas y desa que m enos form al. Esto puede sugerir que todos los
rrolla m étricas para obtener indicadores. Un indica equipos utilicen el enfoque m ás form al. L a m étrica
dor es una m étrica o una com binación de métricas que proporciona al gestor una visión m ás profunda. Y ade
proporcionan una visión profunda del proceso del soft m ás le llevará a una tom a de decisiones m ás funda
ware, del proyecto de softw are o del producto en sí m entada.
www.FreeLibros.org
1 Esto asum e que se recopila otra medida, persona y horas gastadas
en cada revisión.
54
CAPÍTULO 4 P R O C E S O DEL S O F T W A R E Y M É TR IC A S DEL P R O Y E C T O
La medición es algo com ún en el m undo de la ingenie En algunos casos, se pueden utilizar las m ism as
ría. Se mide el consumo de energía, el peso, las dim en m étricas del softw are para determ inar tanto el p ro
siones físicas, la tem peratura, el voltaje, la relación yecto com o los indicadores del proceso. En realidad,
señal-ruido.. . la lista es casi interminable. Por desgra las m edidas que recopila un equipo de proyecto y las
cia, la m edición es m ucho m enos com ún en el mundo convierte en m étricas para utilizarse durante un p ro
de la ingeniería del software. Existen problem as para yecto tam bién pueden transm itirse a los que tienen la
ponerse de acuerdo sobre qué m edir y las m edidas de responsabilidad de m ejorar el proceso del softw are.
evaluación de problem as recopilados. Por esta razón, se utilizan m uchas de las m ismas m étri
cas tanto en el dom inio del proceso com o en el del
proyecto.
Referencia Web
Se puede descargar una guío completo 4.2.1. M étricas del proceso y mejoras
de métricos del software desde: en el proceso del software
www.inv.nasa.gov/SWG/resources/ L a Única form a racional de m ejorar cualquier proceso
NASA-GB-001-94.pdf
es m edir atributos del proceso, desarrollar un ju eg o de
Se deberían recopilar métricas para que los indica métricas significativas según estos atributos y entonces
dores del proceso y del producto puedan ser ciertos. Los utilizar las métricas para proporcionar indicadores que
indicadores de proceso perm iten a una organización de conducirán a una estrategia de mejora. Pero antes de
ingeniería del software tener una visión profunda de la estudiar las m étricas del software y su im pacto en la
eficacia de un proceso ya existente (por ejemplo: el para m ejoras de los procesos del software es importante des
digma, las tareas de ingeniería del software, productos tacar que el proceso es el Unico factor de «los controla
de trabajo e hitos). Tam bién perm iten que los gestores bles al m ejorar la calidad del software y su rendimiento
evalúen lo que funciona y lo que no. Las métricas del com o organización» [PAU94],
proceso se recopilan de todos los proyectos y durante
un largo período de tiempo. Su intento es proporcionar
indicadores que lleven a m ejoras de los procesos de soft
ware a largo plazo. C LA VE
Los indicadores de proyecto perm iten al gestor de La habilidad y le motivación del personal realizando
proyectos del software (1) evaluar el estado del proyecto el trabajo son los factores más Importantes que Influyen
en curso; (2) seguir la pista de los riesgos potenciales: en lo calidad del software.
(3) detectar las áreas de problem as antes de que se co n
viertan en «críticas»; (4) ajustar el flujo y las tareas del
En la F igura 4.1, el proceso se sitúa en el centro de
trabajo, y (5) evaluar la habilidad del equipo del pro
un triángulo que conecta tres factores con una p ro
yecto en controlar la calidad de los productos de traba
funda influencia en la calidad del software y en el ren
jo del software.
d im ie n to com o organización. La d estre za y la
m otivación del personal se m uestran com o el Único
Producto
factor realm ente influyente en calidad y en el rendi
m iento [BOE81]. La com plejidad del producto p u e
de tener un im pacto sustancial sobre la calidad y el
rendim iento del equipo. La tecnología (por ejem plo:
m étodos de la ingeniería del softw are) que utiliza el
proceso tam bién tiene su im pacto. A dem ás, el trián
gulo de proceso existe dentro de un círculo de co n d i
ciones de entornos que incluyen entornos de desarrollo
(por ejem plo: herram ientas C A SE ), condiciones de
gestión (por ejemplo: fechas tope, reglas de em presa)
y características del cliente (por ejem plo: facilidad de
com unicación).
www.FreeLibros.org
m k ¿Como puedo medir
FIG U R A 4 .1 . Determinantes de la calidad del software
* la efectividad de un proceso
y de la efectividad de organización
de software?
(adaptado según [PAU94]).
55
La eficacia de un proceso de software se mide indi

rectamente. Esto es, se extrae un juego de métricas según
los resultados que provienen del proceso. Entre los resul
tados se incluyen m edidas de errores detectados antes las métricas públicas permiten a una organización
de la entrega del software, defectos detectados e infor realizar cambios estratégicos que mejoran el proceso
mados a los usuarios finales,productos de trabajo entre del software y cambios tácticos durante un proyecto
gados (productividad), esfuerzo hum ano y tiem po de software.
consumido, ajuste con la planificación y otras medidas.
Las métricas de proceso tam bién se extraen midiendo
las características de tareas específicas de la ingeniería
Las métricas públicas generalmente asimilan infor
del software. Por ejemplo, se podría m edir el tiem po y
m ación que originalmente era privada de particulares y
el esfuerzo de llevar a cabo las actividades de protec
equipos. Los índices de defectos a nivel de proyecto (no
ción y las actividades genéricas de ingeniería del soft
atribuidos absolutamente a un particular), esfuerzo, tiem
ware del Capítulo 2.
po y datos afines se recopilan y se evalúan en un inten
Grady [GRA92] argum enta que existen unos usos
to de detectar indicadores que puedan m ejorar el
«privados y públicos» para diferentes tipos de datos
rendim iento del proceso organizativo.
de proceso. Com o es natural que los ingenieros del
Las métricas del proceso del software pueden pro
softw are pudieran sentirse sensibles ante la u tiliza
porcionar beneficios significativos a m edida que una
ción de m étricas recopiladas sobre una base particu
organización trabaja por m ejorar su nivel global de
lar, estos datos deberían ser privados para el individuo m adurez del proceso. Sin embargo, al igual que todas las
y serv ir sólo com o un in d icad o r de ese individuo.
métricas, éstas pueden usarse mal, originando más pro
Entre los ejem plos de m étricas p riva d a s se incluyen:
blemas de los que pueden solucionar. Grady [GRA92]
ín d ices de d efecto s (in d iv id u alm en te), índices de
sugiere una «etiqueta de métricas del software» adecua
defectos (por m ódulo), errores encontrados durante el
da para gestores al tiempo que instituyen un program a
desarrollo. de métricas de proceso:
La filosofía de «datos de proceso privados» se ajus
ta bien con el enfoque del proceso p erso n a l del soft • Utilice el sentido com ún y una sensibilidad organi
zativa al interpretar datos de métricas.
ware propuesto por Humphrey [HUM95], Humphrey
describe el enfoque de la m anera siguiente: • Proporcione una retroalim entación regular para par
ticulares y equipos que hayan trabajado en la reco
E l p roceso personal del softw are (P P S ) es un conjunto
pilación de m edidas y métricas.
estructurado de d escripciones de proceso, m ediciones y m éto
dos que pueden ayudar a que los ingenieros m ejoren su rendi • No utilice métricas para evaluar a particulares.
m iento personal. Proporcionan las form as, guiones y estándares • Trabaje con profesionales y equipos para establecer
que les ayudan a estim ar y planificar su trabajo. M uestra cóm o
objetivos claros y métricas que se vayan a utilizar
definir procesos y cóm o m edir su calidad y productividad. Un
principio P PS fundam ental es que todo el m undo es diferente
para alcanzarlos.
y que un m étodo que sea efectivo para un ingeniero puede que • No utilice nunca métricas que amenacen a particu
no sea adecuado para otro. Así pues, el PP S ayuda a que los lares o equipos.
ingenieros m idan y sigan la pista de su trabajo para que pue
• Los datos de métricas que indican un área de proble
dan encontrar los m étodos que sean m ejores para ellos.
mas no se deberían considerar «negativos». Estos datos
son meram ente un indicador de mejora de proceso.
Humphrey reconoce que la mejora del proceso del
software puede y debe em pezar en el nivel individual. • No se obsesione con una sola m étrica y excluya otras
Los datos privados de proceso pueden servir como refe métricas importantes.
rencia im portante para m ejorar el trabajo individual del
ingeniero del software.
¿Qué directrices deben
A lgunas m étricas de proceso son privadas para el
equipo del proyecto de software, pero p ú b lica s para
todos los m iem bros del equipo. Entre los ejemplos se
§ aplicarse cuando recogemos
métricas del software?
incluyen los defectos inform ados de funciones im por

tantes del software (que un grupo de profesionales han A m edida que una organización está más a gusto con
desarrollado), errores encontrados durante revisiones la recopilación y utiliza métricas de proceso, la deriva
técnicas formales, y líneas de código o puntos de fun ción de indicadores sim ples abre el cam ino hacia un
ción por módulo y función2. El equipo revisa estos datos enfoque m ás riguroso llam ado m ejora estadística de
para detectar los indicadores que pueden m ejorar el ren proceso del software (\IK P S). En esencia, MEPS utili
dimiento del equipo. za el análisis de fallos del software para recopilar infor-
www.FreeLibros.org
2 Consulte las Secciones 4.3.1 y 4.3.2 para estudios m ás detallados
sobre L D C (líneasde códigojy m étricas de puntos de función.
56
CAPITULO 4 P R O C E S O DEL SOF TW ARE Y M É T R I C A S DEL P R O Y E C T O
marión de errores y defectos" encontrados al desarro

llar y utilizar una aplicación de sistema o producto. El
análisis de fallos funciona de la m ism a manera: No puedes mejoror tu enfoquepara la Ingeniería
del software a menos que comprendos donde estás
fuerte y donde esés débil. Utilice los técnicasMEPS
poro aumentar esa comprensión.
Referencia W e b l v Siguiendo los pasos 1 y 2 anteriores, se puede desa

MPSEy otra información relacionadacon la calidad rrollar una simple distribución de defectos (Fig. 4.2)
estó disponible en la Sociedad Americana parala Calidad [GRA94], Para el diagrama de tarta señalado en la figu
en www.asq.org ra, se m uestran ocho causas de defectos y sus ongenes
(indicados en sombreado). Grady- sugiere «1 desarrollo
de un diagrama de espina [GRA92] para ayudar a diag
1. Todos los errores y defectos se categorizan por ori
gen (por ejemplo: defectos en la especificación, en nosticar los datos presentados en el diagram a de fre
la lógica, no acorde con los estándares). cuencias. En la Figura 4.3 la espina del diagram a (la línea
central) representa el factor de calidad en consideración
2. Se registra tanto el coste de corregir cada error como (en este caso, los defectos de especificación que cuentan
el del defecto. con el 25 por 100 del total). Cada una de las varillas (líne
3. El número de errores y de defectos de cada catego as diagonales) conectadas a la espina central indican una
ría se cuentan y se ordenan en orden descendente. causa potencial del problem a de calidad (por ejemplo:
4. Se computa el coste global de errores y defectos de requisitos perdidos, especificación ambigua, requisitos
cada categoría. incorrectos y requisitos cambiados). La notación de la
5. Los datos resultantes se analizan para detectar las espina y de las varillas se añade entonces a cada una de
categorías que producen el coste m ás alto para la las varillas principales del diagram apara centrarse sobre
organización. la causa destacada. La expansión se m uestra sólo para la
causa «incorrecta» en la Figura 4.3.
6. Se desarrollan planes para m odificar el proceso con
La colección de métricas del proceso es el conduc
el intento de eliminar (o reducir la frecuencia de apa
tor para la creación del diagram a en espina. Un diagra
riciones de) la clase de errores y defectos que sean
m a en espina completo se puede analizar para extraer
más costosos.
los indicadores que perm itan a una organización de soft
ware m odificar su proceso para reducir la frecuencia de
errores y defectos.
L ó g ic a
20 %
M a n e jo d e d a to s
Interfaz s o ftw a re 10.9%
6 .0%
E s tá n d a re s
In te rfa z 6 .9 %
h a rd w a re
7.7%
C o m p ro b a c ió n
de e rro re s
10.9%
E s p e c ific a c io n e s
2 5 .5 %
In te rfa z d e u s u a rio
11.7%
O r ig e n d e e rr o re s /d e fe c to s
□ E s p e c ific a c ió n /re q u is ito s
□ D is e ñ o
E l C ó d ig o
In c o rre c to C a m b io s
FIGURA 4 .2 . Causas de defectos y su origen para cuatro
proyectos de software [GRA94J. F IG U R A 4 .3 . Un diagrama de espina (Adaptado de [GRA92]).
3 Como se trata en el Capítulo 8 , un e rro re s alguna fisura en un pro

ducto de trabajo de ingeniería del softw are o en la entrega d e sc u
www.FreeLibros.org
bierta por los ingenieros del softw are an te s de que el softw are sea
entregado al usuario final.
Un defecto es una fisura descubierta después de la entrega al usua-
no final.
57
IN G E N IE R ÍA DEL S O F TW A RE . UN EN F OQ U E P R Á C T I C O
4.2.2. M é tric a s d e l p ro y e c to La utilización de métricas para el proyecto tiene dos

Las métricas del proceso de software se utilizan para aspectos fundamentales. En prim er lugar, estas m étri
propósitos estratégicos. Las m edidas del proyecto de cas se utilizan para m inim izar la planificación de desa
software son tácticas. Esto es, las m étricas de proyec rrollo haciendo los ajustes necesarios que eviten retrasos
tos y los indicadores derivados de ellos los utilizan un y reduzcan problem as y riesgos potenciales. En segun
gestor de proyectos y un equipo de software para adap do lugar, las métricas para el proyecto se utilizan para
tar el flujo del trabajo del proyecto y las actividades evaluar la calidad de los productos en el m om ento actual
técnicas. y cuando sea necesario, m odificando el enfoque técni
co que mejore la calidad.
cssmmsm ¿Cómo debemos

las técnicas de estimación de proyectos se estudian
en el capítulo 5. « utilizar las métricas
durante el proyecto?
La prim era aplicación de métricas de proyectos en A m edida que m ejora la calidad, se m inim izan los
la m ayoría de los proyectos de software ocurre duran defectos, y al tiempo que disminuye el número de defec
te la estimación. Las métricas recopiladas de proyectos tos, la cantidad de trabajo que ha de rehacerse también
anteriores se utilizan como una base desde la que se rea se reduce. Esto lleva a una reducción del coste global
lizan las estim aciones del esfuerzo y del tiem po para el del proyecto.
actual trabajo del software. A m edida que avanza un Otro m odelo de métricas del proyecto de software
proyecto, las m edidas del esfuerzo y del tiem po consu [HET93] sugiere que todos los proyectos deberían medir:
m ido se com paran con las estim aciones originales (y la . entradas: la dim ensión de los recursos (p. ej.: perso
planificación de proyectos). El gestor de proyectos uti nas, entorno) que se requieren para realizar el trabajo,
liza estos datos para supervisar y controlar el avance.
« salidas: medidas de las entregas o productos creados
A m edida que com ienza el trabajo técnico, otras
m étricas de proyectos com ienzan a tener significado. durante el proceso de ingeniería del software,
S e m iden los ín d ices de producción rep resen tad o s • resultados: m edidas que indican la efectividad de las
m ediante páginas de documentación, las horas de revi entregas.
sión, los puntos de función y las líneas fuente entre En realidad, este m odelo se puede aplicar tanto al
gadas. A d em ás, se sigue la p ista de los errores proceso com o al proyecto. En el contexto del proyecto,
detectados durante todas las tareas de ingeniería del el m odelo se puede aplicar recursivam ente a m edida
software. Cuando va evolucionando el software d es que aparece cada actividad estructural. Por consiguien
de la especificación al diseño, se recopilan las m étri te las salidas de una actividad se convierten en las entra
cas técn icas (C apítulos 19 al 24) para ev alu ar la das de la siguiente. Las métricas de resultados se pueden
calidad del d iseño y para proporcionar indicadores utilizar para proporcionar una indicación de la utilidad
que influirán en el enfoque tomado para la generación de los productos de trabajo cuando fluyen de una acti
y prueba del código. vidad (o tarea) a la siguiente.
Las m ediciones del m undo físico se pueden categorizar gm ¿Cuál es la diferencia

de dos maneras; medidas directas (por ejemplo: la lon entre medidas directas
gitud de un tomillo) y medidas indirectas (por ejemplo: e indirectas?
la «calidad» de los tom illos producidos, m edidos con
tando los artículos defectuosos). Las métricas del soft
ware se pueden categorizar de form a similar. El coste y el esfuerzo requerido para construir el soft
Entre las m edidas directas del proceso de la inge ware, el núm ero de líneas de código producidas, y otras
niería del software se incluyen el coste y el esfuerzo m edidas directas son relativam ente fáciles de reunir,
aplicados. Entre las m edidas directas del producto se mientras que los convenios específicos para la medición
incluyen las líneas de código (LDC) producidas, velo se establecen más adelante. Sin embargo, la calidad y
cidad de ejecución, tamaño de memoria, y los defectos funcionalidad del software, o su eficiencia o m anteni
informados durante un período de tiempo establecido. m iento son m ás difíciles de evaluar y sólo pueden ser
Entre las medidas indirectas se incluyen la funcionali medidas indirectamente.
www.FreeLibros.org
dad, calidad, com plejidad, eficiencia, fiabilidad, facili El dominio de las métricas del software se dividen
dad de m antenim iento y m uchas otras «capacidades» en métricas de proceso, proyecto y producto. También
tratadas en el Capítulo 19. se acaba de destacar que las métricas de producto que
58
CAPÍTULO 4 P R O C E S O DEL SOF TW ARE Y M É T R I C A S DEL P R O Y E C T O
son privadas para un individuo a m enudo se combinan ¿Qué datos deberíamos

para desarrollar métricas del proyecto que sean públi
cas para un equipo de software. Las métricas del pro
yecto se consolidan para crear métricas de proceso que
§ reunir para derivar métricas
orientadas al tamaño?
sean públicas para toda la organización del software.

Pero jcóm o com bina una organización m étricas que ’ royecto LDC Esfuerzo Coste Pag. Doc. Errores D efectos Personas
provengan de particulares o proyectos? £(000)
^ ^
A lfa 12,100 24 168 365 134 29
Beta 27.200 62 440 1224 321 86
0ONSEJÓ G am m a 20.200 43 314 1050 256 54
Puesto que muchos factores influyen en el trabajo ■

■
del software, no utilice las métricas poro comparar
personas o equipos.
Para ilustrarlo, se va a tener en consideración un

ejemplo sencillo. Personas de dos equipos de proyecto
diferentes registran y categorizan todos los errores que
se encuentran durante el proceso del software. Las m edi F IG U R A 4 .4 . M étricas orientadas al tam año.
das de las personas se com binan entonces para desa
rrollar medidas de equipo. El equipo A encontró 342
Para desarrollar métricas que se puedan com parar
errores durante el proceso del software antes de su rea
entre distintos proyectos, se seleccionan las líneas de
lización. El equipo B encontró184. Considerando que
código com o valor de norm alización. Con lo s ru d i
en el resto los equipos son iguales, ¿qué equipo es más
mentarios datos contenidos en la tabla se pueden desa
efectivo en detectar errores durante el proceso'? Como
rrollar para cada proyecto un conjunto de m étricas
no se conoce el tam año o la com plejidad de los proyec
simples orientadas al tamaño:
tos, no se puede responder a esta pregunta. Sin em bar
go, si se norm alizan las m edidas, es posible crear « errores por KLDC (miles de líneas de código)
métricas de software que perm itan com parar medidas • defectos4 por KLDC
más amplias de otras organizaciones. • E por LDC
• páginas de docum entación por KLDC
4.3.1. M é tric a s O r i e n t a d a s a l T a m a ñ o
Las métricas del software orientadas al tam año provie
nen de la norm alización de las medidas de calidad y/o
productividad considerando el «tamaño» del software
que se haya producido. Si una organización de softwa
re mantiene registros sencillos, se puede crear una tabla Plantilla de colección de métricos
de datos orientados al tamaño, com o la que m uestra la
Figura 4.4. La tabla lista cada proyecto de desarrollo de Además, se pueden calcular otras métricas interesantes:
software de los últim os años y las m edidas correspon • errores por persona-m es
dientes de cada proyecto. Refiriéndonos a la entrada de
• LDC por persona-m es
la tabla (Fig. 4.4) del proyecto alfa: se desarrollaron
• £ por página de documentación
12.1001íneas de código (LDC) con 24 personas-m es y
con un coste de E168.000. Debe tenerse en cuenta que
el esfuerzo y el coste registrados en la tabla incluyen 4.3.2. M é tr ic a s O r i e n ta d a s a l a F u n c ió n
todas las actividades de ingeniería del software (análi Las métricas del software orientadas a la función utili
sis, diseño, codificación y prueba) y no sólo la codifi zan una m edida de la funcionalidad entregada por la
cación. Otra inform ación sobre el proyecto alfa indica aplicación com o un valor de normalización. Ya que la
que se desarrollaron 365 páginas de documentación, se «funcionalidad» no se puede m edir directam ente, se
registraron 134 errores antes de que el software se entre debe derivar indirectam ente m ediante otras m edidas
gara y se encontraron 29 errores después de entregár directas. Las m étricas orientadas a la función fueron
selo al cliente dentro del prim er año de utilización. propuestas por primera vez por Albretch [ALB79], quien
También sabemos que trabajaron tres personas en el sugirió una m edida llam adapunto defunción. Los pun
desarrollo del proyecto alfa. tos de función se derivan con una relación em pírica
www.FreeLibros.org
4 U i defecto ocurre cuando las actividades de garantía de calidad (p.
ej.: revisiones técnicas form ales) fallan para descubrir un error en un
producto de trabajo generado durante el proceso del software.
59
IN G E N I E R Í A DEL S O F TW A RE . UN EN F O Q U E P R Á C T I C O
según las m edidas contables (directas) del dominio de Factor de ponderación

inform ación del software y las evaluaciones de la com Parámetros
de medición Cuenta Simple Medio Complejo
plejidad del software.
N úm ero
de entradas 4 6
de usuario
N úm ero
de salidas 5 7 =
de usuario
□
Se puede obtener información completo sobre los puntos
defunción en: www.ifpug.org N úm ero
de peticiones 4 6
de usuario
□
Los puntos de función se calculan [IFP94] com ple
tando la tab la de la Figura 4.5. Se determ inan cinco Núm ero
de archivos 10 15
características de dominios de inform ación y se pro
porcionan las cuentas en la posición apropiada de la Núm ero
tabla. Los valores de los dominios de inform ación se de interfaces 7 10
externas
definen de la form a siguiente?
Cuenta total
N úm ero de entradas de usuario. Se cuenta cada
entrada de usuario que proporciona diferentes datos
F IG U R A 4.5. Cálculo de puntos de función.
orientados a la aplicación. Las entradas se deberían
diferenciar de las peticiones, las cuales se cuentan de
forma separada. Para calcular puntos de función (P F ), se utiliza la
relación siguiente:
PF = cuenta-total x [0,65 +0,01 x 6 (F ¡)] (4.1)
ve en donde cuenta-total es la suma de todas las entradas
los puntos de función se derivan de medidas PF obtenidas de la figura 4.5.
directasdel dominio de la información. Fy (i = 1 a 14) son «valores de ajuste de la com pleji
dad» según las respuestas a las siguientes preguntas
Número de salidas de usuario. Se cuenta cada salida
[A R T85]:
que proporciona al usuario información orientada a la
aplicación. En este contexto la salida se refiere a infor 1. ¿Requiere el sistem a copias de seguridad y de recu
mes, pantallas, mensajes de error, etc. Los elementos peración fiables?
de datos particulares dentro de un informe no se cuen 2. ¿Se requiere com unicación de datos?
tan de forma separada. 3. ¿Existen funciones de procesam iento distribuido?
Número de peticiones de usuario. Una petición se 4. ¿Es crítico el rendimiento?
define como una entrada interactiva que produce la gene 5. ¿Se ejecutará el sistema en un entorno operativo
ración de alguna respuesta del software inmediata en existente y fuertemente utilizado?
form ade salidainteractiva. Se cuenta cada petición por
6. ¿Requiere el sistema entrada de datos interactiva?
separado.
7. ¿Requiere la entrada de datos interactiva que las
Número de archivos. Se cuenta cada archivo maes
transacciones de entrada se lleven a cabo sobre múl
tro lógico (esto es, un grupo lógico de datos que puede
tiples pantallas u operaciones?
ser una parte de una gran base de datos o un archivo
independiente). 8. ¿Se actualizan los archivos m aestro s de form a
Núm ero de interfaces externas. Se cuentan todas interactiva?
las interfaces legibles por la m áquina (por ejem plo: 9. ¿Son complejas las entradas, las salidas, los archi
archivos de datos de cinta o disco) que se utilizan vos o las peticiones?
para transm itir inform ación a otro sistema. 10. ¿Es complejo el procesam iento interno?
U na vez que se han recopilado los datos anterio 11. ¿Se ha diseñado el código para ser reutilizable?
res, a la cuenta se asocia un v alo r de com plejidad. 12. ¿Están incluidas en el diseño la conversión y la ins
Las organizaciones que utilizan m étodos de puntos talación'?
de función desarrollan crite rio s para d eterm in ar si 13. ¿Se ha diseñado el sistema para soportar m últiples
una en trad a en p a rtic u la r es sim ple, m edia o co m instalaciones en diferentes organizaciones?
pleja. No obstante la determ inación de la com pleji 14. ¿Se ha diseñado la aplicación para facilitar los cam
dad es algo subjetiva. bios y para ser fácilmente utilizada por el usuario?
www.FreeLibros.org
5 En realidad, la definición de los valores del dominio de la informa
ción y la form a en que se cuentan es un poco m ás complejo. El lec
tor interesado debería consultar [1FP94) para obtener más detalles.
60
CAPÍTULO 4 P R O C E S O DEL SO FT W AR E Y M É T R I C A S DEL PRO Y 'E CT O
Cada una de las preguntas anteriores es respondida

usando una escala con rangos desde O (no importante o
aplicable) hasta 5 (absolutamente esencial). Los valo
-M *
Referencia m b l '
res constantes de la ecuación (4.1) y los factores de peso
que se aplican a las cuentas de los dominios de infor Se puede encontrar una lista útil de preguntas realizadas
mación se determ inan empíricamente. con frecuencia sobre los puntos de función (y puntos
Una vez que se han calculado los puntos de función, de función extendidos) en:
http://ourworld.compuserve.com/
se utilizan de form a análoga a las LDC com o form a de
homepuges/softcomp/
normalizar las medidas de productividad, calidad y otros
atributos del software.
B oeing ha desarrollado otra extensión de punto de
función para sistem as en tiem po real y productos de
4.3.3. M étricas a m p lia d a s d e p u n to d e fu n ció n
ingeniería. El enfoque de Boeing integra la dim ensión
La medida de punto de función se diseñó originalm en de datos del software con las dim ensiones fu n cion a
te para aplicarse a aplicaciones de sistem as de infor les y de control para proporcionar una m edida orien
mación de gestión. Para acomodar estas aplicaciones, tada a la función que es adecuada a aplicaciones que
se enfatizó la dim ensión de datos (los valores de dom i enfatizan las capacidades de control y función. Las
nios de inform ación tratados anteriorm ente) para la características de las tres dim ensiones del software se
exclusión de dim ensiones (control) funcionales y de «cuentan, cuantifican y transform an» en una m edida
comportamiento. Por esta razón, la m edida del punto de que proporciona una indicación de la funcionalidad
función era inadecuada para m uchos sistemas de inge entregada por el softw are6, llam ada Punto de Función
niería y sistemas em potrados (que enfatizan función y 3D [WHI95]
control). Para rem ediar esta situación se ha propuesto La dimensión de datos se evalúa exactamente igual
un número de extensiones a la m étrica del punto de fun a como se describe en la Sección 4.3.2. Las cuentas de
ción básica. datos retenidos (la estructura interna de datos de pro
gramas, p. ej.: archivos) y los datos externos (entradas,
salidas, peticiones y referencias externas) se utilizan a
lo largo de las m edidas de la com plejidad para derivar
una cuenta de dim ensión de datos.
I a extensión de los puntos de función se utiliza La dimensión fu n cion al se m ide considerando «el
en la ingeniería, en las aplicaciones de tiempo real núm ero de operaciones internas requeridas para trans
y en las aplicaciones orientadas al control. form ar datos de entrada en datos de salida» [WHI95].
Para propósitos de com putación de los puntos de fun
Una extensión del punto de función es la llam ada ción 3D, se observa una «transform ación» com o una
puntos de características [JON91]; es una am pliación serie de pasos de proceso que quedan limitados por sen
de la medida del punto de función que se puede aplicar tencias sem ánticas. La dimensión de control se mide
a sistemas y aplicaciones de ingeniería del software. La contando el núm ero de transiciones entre estados7.
medida de punto de característica acom oda a aplica Un estado re p resen ta algún m odo de c o m p o rta
ciones en donde la com plejidad del algoritmo es alta. miento externam ente observable, y una transición ocu
Las aplicaciones de software de tiem po real, de control rre com o re su ltad o de algún su ceso que c a m b ia el
de procesos, y empotradas tienden a tener alta com ple m odo de com portam iento del sistem a o del softw are
jidad de algoritmos y por lo tanto son adecuadas para (esto es, cam bia el estado). Por ejem plo, un teléfono
el punto de característica. inalám brico contiene softw are que soporta funciones
Para calcular el punto de característica, los valores de m arcado autom ático. Para introducir el estado de
ds dominio de información se cuentan otra vez y se pesan m arcado autom ático desde un estado en descanso, el
de la forma que se describe en la Sección4.3.2. Además, usuario pulsa una tecla Auto en el teclado num érico.
la métrica del punto de característica cuenta una carac Este suceso hace que una pantalla L C D pida un có d i
terística nueva del software— los algoritmos—. Un algo go que indique la parte que se llama. Con la entrada
ritmo se define como «un problem a de cálculo limitado del código y pulsando la tecla de M arcado (otro suce
que se incluye dentro de un program a de com putadora so), el softw are del teléfo n o in alám b rico hace una
específico» [JON91]. Invertir una matriz, decodificar transición al estado de m arcado. C uando se co m p u
una cadena de bits o m anejar una interrupción son ejem tan puntos de función 3D, no se asigna un v alo r de
plos de algoritmos. com plejidad a las transiciones.
www.FreeLibros.org
6 Debe señalarse que tam bién han sido propuestas otras extensiones 1 En el capítulo 12 se presenta un estudio detallado de la dim ensión
a los puntos de función para aplicarlas en trabajos de softw are de de com portam ientos que incluyen estados y transiciones de estados.
tiempo real (p.ej., [ALA97]). Sin em bargo, ninguno de estos parece
usarse ampliam ente en la industria.
61
I N GE NI E RÍ A DEL SO FTW AR E. UN E N F O Q U E P R A C T I C O
Para calcular puntos de función 3D, se utiliza la rela El punto de función (y sus extensiones), com o la
ción siguiente: m edida LDC, es controvertido. Los partidarios afirman
que PF es independiente del lenguaje de programación,
índice = I + O + O + F + E + T + R (4.2)
lo cual es ideal para aplicaciones que utilizan lenguajes
en donde I, O, Q, F, E, T y R representan valores con convencionales y no procedim entales; esto se basa en
peso de com plejidad en los elem entos tratados ante los datos que probablem ente se conocen al principio de
riormente: entradas, salidas, peticiones, estructuras de la evolución de un proyecto, y así el PF es m ás atracti
datos internas, archivos externos, transform aciones y vo com o enfoque de estimación.
transiciones, respectivamente. Cada valor con peso de
com plejidad se calcula con la relación siguiente:
S e n te n c ia s
valor con peso de com plejidad = ^ N s s e m á n t¡c a s
= ^ W i ^ N ia Wia + N ih W lh (4.3) P as o s d e ^ s . 1 -6 6 -1 0 11 +
p ro c e s o
i
en donde N ü , N ia y N ¡f¡ representan el núm ero de apa 1 -1 0 B ajo . B ajo M edio
riciones del elem ento / (p. ej.: salidas) para cada nivel
1 1 -2 0 B ajo M edio A lto
de com plejidad (bajo, medio, alto), y W¡j , W ia y W ih
son los pesos correspondientes. El cálculo global de los 21 + M e d io A lto A lto
puntos de función 3D se m uestran en la Figura 4.6.
Se debería señalar que los puntos de función, los pun F IG U R A 4 .6 . Cálculo de los índices de los puntos
tos de característica y los puntos de función 3D repre de función 3D.
sentan lo m ism o — «funcionalidad» o «utilidad»
entregada por el software— . En realidad, cada una de Los detractores afirman que el m étodo requiere algún
estas medidas producen el mismo valor si sólo se con «juego de manos» en el que el cálculo se base en datos
sidera la dim ensión de datos de una aplicación. Para sis subjetivos y no objetivos; y afirman que las cuentas del
temas de tiem po real más complejos, la cuenta de puntos dominio de inform ación (y otras dimensiones) pueden
de característica a m enudo se encuentra entre el 20 y el ser difíciles de recopilar después de realizado, y por últi
35 por lOOmás que la cuenta determ inada sólo con los mo que el PF no tiene un significado físico directo — es
puntos de función. simplemente un número— .
4,«4 R E C O N C IL IA C IÓ N D,E L O S ,X ? IF JE JB L £ ..N IE S ^M JL Q Q IlE S ..P t.M É IB Ü 3A S ,,.

La relación entre las líneas de código y los puntos de fun
ción depende del lenguaje de programación que se utili L enguaje de p ro g ram ació n L D C /P F (m edia)
ce para implementarel software, y de la calidad del diseño. Ensam blador 320
Ciertos estudios han intentado relacionar las métricas LDC C 128
y PF. C itandoaA lbrechty Gaffney [ALB83]: COBOL 106
L a tesis de este trabajo es que la cantidad de función pro FORTRAN 106
porcionada por la aplicación (program a) puede ser estim ada Pascal 90
por ladescom posiciónde los principales com ponentes8de datos C++ 64
que usa o proporciona el program a. A dem ás, esta estim ación Ada95 53
de la función debe ser relacionada con el total de L D C a desa Visual Basic 32
rrollar y con el esfuerzo de desarrollo necesario.
Smalltalk 22
La tabla siguiente [JON98] proporciona estim acio Powerbuilder (generador de código) 16
nes informales del número m edio de líneas de código SQL 12
que se requiere para construir un punto de función en
varios lenguajes de programación:
^ C O N S E i d j^
Si conoces el número
•
Utilice el repaso de los datos de un modo juicioso.
de LDC's, ¿es posible estimar Es bastante mejor calcular los PFutilizando los métodos
el numero de puntos de función? utilizadas anteriormente.
8 Es im portante destacar que la «la individualización de co m p o zación de m anten im ien to podría ob serv ar el tam a ñ o de los pro
www.FreeLibros.org
n e n te s im portantes» se puede in te rp re ta r de m u ch a s m a n e ra s. yectos en relación con los pedidos de cam bio de ingeniería (C api
A lgunos ingenieros del softw are que trab a ja n en un e n to rn o de tulo 9). Una o rg a n iz a c ió n de siste m a s de in fo rm a ció n podría
desarrollo orientado a objetos (C uarta Parte) utilizan ciertas c la o bservar el núm ero de p rocesos de negocio a los que im pacta una
se s u objetos com o m étrica dom in an te del tam a ñ o . Una organi- aplicación.
62
CAPÍTULO 4 P R O C E S O DEL S O F T W A R E Y MÉTRICAS DEL P R O Y E C T O
Una revisión de los datos anteriores indica que una com parar la relación LDC/personas-mes (ó PF/perso-
LDC de C ++proporciona aproximadamente 1,6 veces nas-m es) de un grupo con los datos sim ilares de otro
la «funcionalidad» (de m edia) que una LDC de FO R grupo? ¿Deben los gestores evaluar el rendim iento de
TRAN. Además, una LDC de Visual Basic proporcio las personas usando estas métricas? La respuesta a estas
na 3 veces la funcionalidad de una LDC de un lenguaje preguntas es un rotundo «No». La razón para esta res
de programación convencional. En [JON98] sepresen- puesta es que hay m uchos factores que influyen en la
tan datos más precisos sobre las relaciones entre los PF productividad, haciendo que la com paración de « m an
y las LDC, que pueden ser usados para «repasar» pro zanas y naranjas» sea mal interpretada con facilidad.
gramas existentes, determinando sus medidas en PF (por Se han encontrado los puntos de función y las LDC
ejemplo, para calcular el núm ero de puntos de función basadas en métricas para ser predicciones relativam en
cuando se conoce la cantidad de LDC entregada). te exactas del esfuerzo y coste del desarrollo del soft
Las m edidas LDC y PF se utilizan a m enudo para ware. Sin em bargo, para utilizar LDC y PF en las
extraer métricas de productividad. Esta invariabilidad técnicas de estim ación (capítulo 5), debe establecerse
conduce al debate sobre el uso de tales datos. Se debe una línea base de inform ación histórica.
U B U L C 1 ' ' "m •. IS K A B E

El objetivo primordial de la ingeniería del software es pro
ducir un sistema, aplicación o producto de alta calidad. m m m m m
En el capitulo8 se presento un estudio detallada sobre
Para lograr este objetivo, los ingenieros del software deben las actividades de garantía de calidad del software.
aplicar métodos efectivosjunto con herramientas m oder
nas dentro del contexto de un proceso m aduro de desa
rrollo de software. Además, un buen ingeniero del software
(y buenos gestores de la ingeniería del software) deben 4.5.1. V isión g e n e r a l d e lo s fa c to r e s q u e a fe c ta n
medir si la alta calidad se va a llevar a cabo. a la c a lid a d
La calidad de un sistema, aplicación o producto es
Hace 25 años, M cCally Cavano[M CC78] definieron un
tan bueno como los requisitos que describen el proble
juego de factores de calidad como los primeros pasos hacia
ma, el diseño que m odela la solución, el código que con
el desarrollode métricas de la calidad del software. Estos
duce a un program a ejecutable, y las pruebas que
factores evalúan el software desde tres puntos de vista dis
ejercitan el software para detectar errores. Un buen inge
tintos: (1) operación del producto (utilizándolo), (2) revi
niero del software utiliza m ediciones que evalúan la
sión del producto (cam biándolo), y (3) transición del
calidad del análisis y los m odelos de diseño, el código
producto (modificándolo para que funcione en un entor
fuente, y los casos de prueba que se han creado al apli
no diferente,por ejemplo, «portándolo»).Los autores,en
car la ingeniería del software. Para lograr esta evalua
su trabajo, describen la relación entre estos factores de
ción de la calidad en tiem po real, el ingeniero debe
utilizar medidas técnicas (Capítulos 19 y 24) que eva calidad (lo que llam an un «marco de trabajo») y otros
aspectos del proceso de ingeniería del software:
lúan la calidad con objetividad, no con subjetividad.
E n prim er lugar, el m arco de trabajo proporciona un m eca
nism o para que el gestor del proyecto identifique lo que consi
dera im portante. E stas cualidades son atributos del softw are,
adem ás de su corrección y rendim iento funcional, que tiene
Referencia im plicaciones en el ciclo de vida. E n otros factores, com o son
facilidad de m antenim iento y portabilidad, se ha dem ostrado
Se puede encontrar una excelentefuente de información que tienen un im pacto significativoen el coste del ciclo de vida.. .
sobre la calidad del software y ternos relacionados
En segundo lugar, el m arco de trabajo proporciona un m edio
(Incluyendo métricas) en: www.qualityworld.tom
de evaluar cuantitativam ente lo bien que va progresando el d esa
rrollo en relación con los objetivos de calidad establecidos.. .
El gestor de proyectos también debe evaluar la cali E n tercer lugar, el m arco de trabajo proporciona m ás inte
dad objetivamente, y no subjetivamente. A m edida que racción del personal de Q A (garantía de calidad) en el esfuer
el proyecto progresa el gestor del proyecto también debe zo de desarrollo.. .
evaluar la calidad. Las métricas privadas recopiladaspor P or Último,. .. el personal de garantía de calidad puede uti
ingenieros del software particulares se asimilan para pro lizar indicaciones de calidad pobre para ayudar a identificar
porcionar resultados en los proyectos. Aunque se pueden estándares [m ejores] a enfrentar en el futuro.
recopilar muchas m edidas de calidad, el prim er objetivo Un estudio detallado del m arco de trabajo de M cCall
en el proyecto es medir errores y defectos. Las métricas
www.FreeLibros.org
y Cavano, así com o otros factores de calidad, se pre
que provienen de estas m edidas proporcionan una indi sentan en el Capítulo 19. Es interesante destacar que
cación de la efectividad de las actividades de control y casi todos los aspectos del cálculo han sufrido cam bios
déla garantía de calidad en grupos o en particulares. radicales con el paso de los años desde que M cCall y
63
IN GE NIE RIA DEL S O F TW A RE . UN EN F O Q U E P R Á C T I C O
Cavano hicieron su trabajo, con gran influencia,en 1978. a sus usuarios finales— . Cuando la proporción de
Pero los atributos que proporcionan una indicación de desperdicios en el coste global del proyecto (para
la calidad del software siguen siendo los mismos. m uchos proyectos) se representa com o una función
del tiempo, el gestor puede determ inar si la facilidad
total del software producido por una organización de
desarrollo está m ejorando. Se pueden em prender
\iv > acciones a partir de las conclusiones obtenidas de
Sorprendentemente, los factores que definían la calidad esa información.
del software en el año 1970 san los mismos factores Integridad. En esta época de «hackers» y «fire-
que continúan definiendo la calidad del software walls», la integridad del software ha llegado a tener
en la primera década de este siglo. m ucha importancia. Este atributo mide la capacidad
de un sistema para resistir ataques (tanto accidentales
¿Qué significa esto? Si una organización de software
como intencionados) contra su seguridad. El ataque
adopta un ju ego de factores de calidad com o una «lista
se puede realizar en cualquiera de los tres componentes
de comprobación» para evaluar la calidad del softwa
del software: programas, datos y documentos.
re, es probable que el software construido hoy siga exhi
biendo la calidad dentro de las prim eras décadas de este P ara m edir la integridad, se tienen que definir
siglo. Incluso, cuando las arquitecturas de cálculo sufren dos atrib u to s adicionales: am enaza y seguridad.
cambios radicales (como seguramente ocurrirá), el soft Am enaza es la probabilidad (que se puede estim ar
ware que exhibe alta calidad en operación, transición y o deducir de la evidencia em pírica) de que un ata
revisión continuará sirviendo tam bién a sus usuarios. que de un tipo determ inado ocurra en un tiem po
determ inado. La seguridad es la probabilidad (que
se puede estim ar o deducir de la evidencia em p í
4.5.2. M e d id a d e la c a lid a d rica) de que se pueda repeler el ataque de un tipo
Aunque hay m uchas m edidas de la calidad de softwa determ inado. La integridad del sistem a se puede
re, la corrección,facilidad de mantenimiento, integri definir como:
dad, yfa cilid a d de uso proporcionan indicadores Útiles
para el equipo del proyecto. Gilb [GIL88] ha sugerido integridad = X [(1 - amenaza) x (1 - seguridad)]
definiciones y m edidas para cada uno de ellos. donde se suman la am enaza y la seguridad para cada
Corrección. Un program a debe operar correcta tipo de ataque.
mente o proporcionará poco valor a sus usuarios. La
Facilidad de uso. El calificativo«am igable con el
corrección es el grado en el que el software lleva a
usuario» se ha convertido en omnipresente en las dis
cabo su función requerida. La m edida más común de
corrección es defectos p o r K L D C , en donde un cusiones sobre productos de software. Si un programa
no es «amigable con el usuario», frecuentem enteestá
defecto se define como una falta verificada de con
abocado al fracaso, incluso aunque las funciones que
formidad con los requisitos.
realice sean valiosas. La facilidad de uso es un intento
Facilidad de m antenim iento. El mantenimiento de cuantificar «lo amigable que puede ser con el usua
del software cuenta con más esfuerzo que cualquier rio» y se puede m edir en función de cuatro caracte
otra actividad de ingeniería del software. La facili rísticas: (1) habilidad intelectual y/o física requerida
dad de m antenim iento es la facilidad con la que se para aprender el sistema; (2) el tiem po requerido para
puede corregir un program a si se encuentra un error, llegar a ser moderadam enteeficiente en el uso del sis
se puede adaptar si su entorno cambia, o m ejorar si tem a; (3 ) aum ento neto en productividad (sobre el
el cliente desea un cam bio de requisitos. N o hay
enfoque que el sistema reem plaza) m edida cuando
form a de m edir directamente la facilidad de m ante alguien utiliza el sistem am oderadam entey eficiente
nim iento; por consiguiente, se deben utilizar m edi mente; y (4) valoración subjetiva (a veces obtenida
das indirectas. U na simple m étrica orientada al m ediante un cuestionario) de la disposición de los
tiempo es el tiempo medio de cambio (TMC), es decir
usuarios hacia el sistema. En el Capítulo 15 se estu
el tiempo que se tarda en analizarla petición de cam dia más detalladamente este aspecto.
bio, en diseñar una modificación adecuada, en imple-
Los cuatro factores anteriores son sólo un ejemplo
m entar el cam bio, en probarlo y en distribuir el
de todos los que se han propuesto como m edidas de la
cambio a todos los usuarios. Como media, los pro
calidad del software. El Capítulo 19 considera este tema
gram as que se pueden m antener tendrán un TMC
con más detalle.
m ás bajo (para tipos equivalentes de cambios) que
los program as que no son m ás fáciles de mantener.
Hitachi [TAJ81] ha utilizado una m étrica orien 4.5.3. E fica cia d e la E lim in a c ió n d e D e fecto s
www.FreeLibros.org
tada al coste para la capacidad de m antenim iento lla U na m étrica de la calidad que proporciona beneficios
m ada «desperdicios» — el coste en corregir defectos tanto a nivel del proyecto com o del proceso, es la efi
encontrados después de haber distribuidoel software cacia de la eliminación de defectos (E E D ). En esen
64
CAPÍTULO 4 P R O C E S O DEL S OF TW AR E Y M É T R I C A S DEL P R O Y E C T O
cia, EED es una m edida de la habilidad de filtrar las proyecto de software instituya técnicas para encontrar
actividades de la garantía de calidad y de control al todos los errores posibles antes de su entrega.
aplicarse a todas las actividades del m arco de trabajo EED tam bién se puede utilizar dentro del proyecto
del proceso. para evaluar la habilidad de un equipo en encontrar erro
Cuando un proyecto se tom a en consideración glo res antes de que pasen a la siguiente actividad estructu
balmente, EED se define de la forma siguiente: ral o tarea de ingeniería del software. Por ejemplo, la tarea
del análisis de los requisitos produce un m odelo de aná
EED = E / (E + D) (4.4)
lisis que se puede revisar para encontrar y corregir erro
donde E es el núm ero de errores encontrados antes de res. Esos errores que no se encuentren durante la revisión
la entrega del software al usuario final y D es el núm e del m odelo de análisis se pasan a la tarea de diseño (en
ro de defectos encontrados después de la entrega. donde se pueden encontrar o no). Cuando se utilizan en
este contexto, EED se vuelve a definir como:
EED¡ =E¡ /(Ej + E¡ +1) (4.5)
^ ¿Qué es la eficiencia
* de eliminación de defectos? en donde E¡ es el núm ero de errores encontrado duran
te la actividad de ingeniería del software i y E¡ + j es el
núm ero de errores encontrado durante la actividad de
El valor ideal de EED es 1. Esto es, no se han encon ingeniería del software i + 1 que se puede seguir para
trado defectos en el software. De forma realista, D será llegar a errores que no se detectaron en la actividad de
mayor que cero, pero el valor de EED todavía se pue la ingeniería del software i
de aproximar a 1. Cuando E aumenta (para un valor de
D dado), el valor total de EED em pieza a aproximarse
a 1. De hecho, a m edida que E aum enta, es probable
que el valor final de D dism inuya (los errores se filtran Utilice EED como una medido de la eficiencia
antes de que se conviertan en defectos). Si se utilizan de sus primeros actividades de SQA. Si EED es bajo
como una m étrica que proporciona un indicador de la durante el análisis y diseño, emplee olgún tiempo
habilidad de filtrar las actividades de la garantía de la mejorando la forma de conducir los revisiones técnicos
calidad y del control, EED anim a a que el equipo del formales.
I.B INTEGRACIÓN DE LAS METRICAS DENTRO DEL PROCESO DE INGENIERÍA
La mayoría de los desarrolladores de software todavía 4.6.1. A rg u m e n to s p a r a l a s M é tric a s d e l S o ftw a re

no miden, y por desgracia, la m ayoría no desean ni ¿Por qué es tan im portante m edir el proceso de inge
comenzar. Como se ha señalado en este capítulo, el pro niería del software y el producto (software) que produ
blema es cultural. En un intento por recopilar medidas ce? La respuesta es relativamente obvia. Si no se m ide,
en donde no se haya recopilado nada anteriormente, a no hay una form a real de determ inar si se está m ejo
menudo se opone resistencia: «¿Por qué necesitam os rando. Y si no se está mejorando, se está perdido.
hacer esto?», se pregunta un gestor de proyectos ago
biado. «No entiendo por qué», se queja un profesional
saturado de trabajo.
En esta sección, consideraremos algunos argumen
Manejamos cosos «con (os números» en muchos
tos para las métricas del software y presentaremos un
aspectos de nuestras vidas... Estos números nos
enfoque para instituir un program a de métricas dentro
dan una visión y nos oyudan o dirigir nuestros
de una organización de ingeniería del software. Pero
acciones.
antes de empezar, considerem os algunas palabras de
Mkfot! Mak
cordura sugeridas por Grady y Caswell [GRA87]:
Lwry Pv ím h
Algunas de las cosas que d escribim os aquí parecen bastan
te fáciles. R ealm ente, sin em bargo, establecer un program a de La gestión de alto nivel puede establecer objetivos
métricas del softw are con é x ito es un trabajo duro. C uando
significativos de m ejora del proceso de ingeniería del
decimos esto debes esperar al m enos tres años antes de que
estén disponibles las tendencias organizativas, lo que puede software solicitando y evaluando las m edidas de p ro
darte alguna idea del ám bito de tal esfuerzo. ductividad y de calidad. En el Capítulo1 se señaló que
el software es un aspecto de gestión estratégico para
www.FreeLibros.org
La advertencia sugerida por los autores se conside m uchas com pañías. Si el proceso por el que se desa
ra de un gran valor, pero los beneficios de la medición rrolla puede ser mejorado, se producirá un impacto direc
son tan convincentes que obligan a realizar este duro to en lo sustancial. Pero para establecer objetivos de
trabajo. mejora, se debe com prender el estado actual de desa-
65
IN GE NI E RI A DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
rrollo del software. Por lo tanto la m edición se utiliza (3) las medidas deben ser consistentes,por ejemplo, una
para establecer una línea base del proceso desde donde línea de código debe interpretarse consistentem ente en
se pueden evaluar las mejoras. todos los proyectos para los que se han reunido los datos:
Los rigores del trabajo diario de un proyecto del soft (4)l as aplicacionesdeben ser semejantes para trabajar en
ware no dejan m ucho tiem po para pensar en estrategias. la estimación — tiene poco sentido utilizar una línea base
Los gestores de proyecto de software están m ás preo obtenida en un trabajo de sistemas de información batch
cupados por aspectos m undanos (aunque igualm ente para estimar una aplicación em potrada de tiempo real—.
importantes): desarrollo de estim aciones significativas
del proyecto; producción de sistemas de alta calidad y 4.6.3. C o le c c ió n d e m é tric a s ,c ó m p u to y e v a lu a c ió n
terminar el producto a tiempo. M ediante el uso de m edi
El proceso que establece una línea base se m uestra en la
ción para establecer una línea base del proyecto, cada
Figura 4.7. Idealm ente,los datos necesarios para estable
uno de estos asuntos se hace más fácil de manejar. Ya
cer una línea base se han ido recopilando a medida que se
hem os apuntado que la línea base sirve com o base para
ha ido progresando. Por desgracia, este no es el caso. Por
la estimación. Además, la recopilación de métricas de
consiguiente, la recopilación de datos requiere una inves
calidad permite a una organización «sintonizar» su pro
tigación histórica de los proyectos anteriores para recons
ceso de ingeniería del software para elim inar las causas
truir los datos requeridos. Una vez que se han recopilado
«poco vitales» de los defectos que tienen el m ayor
medidas (incuestionablemente el paso más difícil),el cál
im pacto en el desarrollo del software’.
culo de métricas es posible. Dependiendo de la amplitud
Técnicam ente (en el fondo), las m étricas del soft
de las medidas recopiladas, las métricas pueden abarcar
ware, cuando se aplican al producto, proporcionan bene
una gran gama de métricas LDC y PF, así como métricas
ficios inmediatos. Cuando se ha term inado el diseño del
de la calidad y orientadas al proyecto. Finalmente, las
software, la m ayoría de los que desarrollan pueden estar
métricas se deben evaluar y aplicar durante la estimación,
ansiosos por obtener respuestas a preguntas como:
el trabajo técnico, el control de proyectos y la mejora del
. ¿Qué requisitos del usuario son m ás susceptibles al
proceso. La evaluación de métricas se centra en las razo
cambio? nes de los resultados obtenidos, y produce un grupo de
• ¿Qué módulos del sistema son más propensos a error? indicadores que guían el proyecto o el proceso.
• ¿C óm o se debe planificar la prueba para cada
m ódulo?
• ¿Cuántos errores (de tipos concretos) puede esperar
cuando comience la prueba? los datos de las métricas de línea base deberían
Se pueden encontrar respuestas a esas preguntas si recogerse de una gran muestra representativa
se han recopilado métricas y se han usado com o guía de proyectos de software del pasado.
técnica. En posteriores capítulos examinarem os cóm o
se hace esto.
4.6.2. E s ta b le c im ie n to d e u n a L ín e a B a s e
Estableciendouna línea base de métricas se pueden obte
ner beneficios a nivel de proceso, proyecto y producto (téc
nico). Sin embargo la información reunida no necesita ser
fundamentalmente diferente. Las mismas métricas pueden
servir varias veces. Las líneas base de métricas constan de
datos recogidos de proyectos de software desarrollados
anteriormente y pueden ser tan simples como la tabla mos
trada en la figura 4.4 o tan complejas como una gran base
de datos que contenga docenas de medidas de proyectos
y las métricas derivadas de ellos.
Para ser una ayuda efectiva en la mejora del proceso
y/o en la estimación del esfuerzoy del coste, los datos de
línea base deben tener los siguientes atributos: (1) los datos
deben ser razonablemente exactos —se deben evitar «con
jeturas» sobre proyectos pasados— ; (2) los datos deben FIG U R A 4 .7 . P roceso d e recopilación de m étricas
reunirse del mayor número de proyectos que sea posible; del softw are.
www.FreeLibros.org
9 Estas ideas se han form alizado en un enfoque denom inado garan
tía estadística de calidad del software y se estudian en detalle en el
Capítulo 8.
66
CAPÍTULO 4 P R O C E S O DEL S O F T W A R E Y M É T R I C A S DEL P R O Y E C T O
Uno de los problem as al que se han enfrentado los tra Una vez que estas cuestiones se hayan establecido,
bajadores de las métricas durante las dos últim as déca entonces es cuando puede ser desarrollada una m étrica
das es la de desarrollar métricas que fueran útiles para que pueda ayudar a que se cumpla el objetivo planteado
el diseñador de software. Ha sido toda una historia de que naturalmente emergerá a partir de estas cuestiones.
utilización de la m étrica dentro de los entornos indus La importancia de OPM proviene no solam ente del
triales basada en el simple criterio de lo que era facili hecho de que es uno de los prim eros intentos de desa
tar la m edida, m ás que em plear cualquier criterio rrollar un conjunto de m edidas adecuado que pueda ser
relacionado con la utilidad. El panoram a de la Ultima aplicado al software, sino tam bién al hecho de que está
mitad de los años 80 y la prim era m itad de la década de relacionado con el paradigm a de m ejora de procesos
los 90, constató el hecho de que m ientras había sido que ha sido discutido previamente. Basili ha desarro
desarrolladomucho trabajo en la validación de la m étri llado un paradigm a de m ejora de calidad dentro del cual
ca y en el esclarecim iento de los principios teóricos el m étodo OPM puede encaj arse perfectamente. El para
detrás de ella, muy poco había sido hecho para dotar al digma comprende tres etapas:
diseñador de software con herram ientas para la selec • Un proceso de llevar a cabo una auditoría de un pro
ción o construcción de métricas. yecto y su entorno estableciendo metas u objetivos
El objetivo de esta sección es describir OPM, que es de calidad para el proyecto y seleccionando h erra
casi con certeza el método de desarrollo de métrica más mientas adecuadas y m étodos y tecnologías de ges
ampliamente aplicado y mejor conocidoy que ha sidodesa- tión para que dichos objetivos de calidad tengan una
rrollado por Víctor Basili y sus colaboradores de la Uni oportunidad de cumplirse.
versidad de Maryland. Basili y sus colaboradores tenían
> Un proceso de ejecutar un proyecto y chequear los
ya una larga historia de validación de métricas en la déca
datos relacionados con esas metas u objetivos de cali
da de los 80y el méto’do OPM (objetivo, preguntay métri
dad. Este proceso es llevado a cabo en conjunción
ca) surgió de un trabajo que fue desarrollado dentro de un
con otro proceso paralelo de actuación sobre los pro
laboratorio de ingeniería del software esponsorizado por
pios datos cuando se vea que el proyecto corre peli
la Agencia Americana del Espacio, NASA.
gro de no cum plir con los objetivos de calidad.
Basili establecía que para que una organización tuvie
ra un program a de m edida exacto era necesario que • Un proceso para el análisis de los datos del segundo
tuviera constancia de tres componentes: paso, con el fm de poder hacer sugerencias para una
m ayor m ejora. Este proceso im plicaría el analizar
1. Un proceso donde pudieran articularse metas u obje
los problem as ya en la etapa de recolección de datos,
tivos para sus proyectos.
problem as en la im plementación de las directivas de
2. Un proceso donde estas metas pudieran ser traducidas
calidad y problem as en la interpretación de los datos.
a los datos del proyecto que exactamente reflejasen
dichas metas u objetivos en términos de software. Basili [BAS96] ha proporcionado una serie de plan
3. Un proceso que interpretara los datos del proyecto tillas que son útiles para los desarrolládores que deseen
con el fm de entender los objetivos. utilizar el m étodo OPM para desarrollar métricas rea
listas sobre sus proyectos. Los objetivos de OPM pue
Un ejemplo de un objetivo típico que bien podría ser
den articularse por m edio de tres plantillas que cubren
adoptado por una empresa es que la cantidad de trabajo
el propósito, la perspectiva y el entorno.
de revisión sobre un diseño de sistema debido a pro
La plantilla o esquem a de cálculo denom inada de
blemas que fueran descubiertos por los programadores
propósito se utiliza para articular o com parar lo que está
se redujera al 80 por ciento.
siendo analizado y el propósito de dicha parte del pro
A partir de este ejemplo de objetivo emerge un cier
yecto. Por ejem plo, un diseñador puede desear analizar
to número de preguntas típicas cuya contestaciónpodría
la efectividad de las revisiones de diseño con el propó
ser necesaria para clarificar los objetivos y por consi
sito de mejorar la tasa de elim inación de errores de dicho
guiente el desarrollo de una m étrica. Un conjunto de
proceso o el propio diseñador puede desear analizar las
ejemplosde estas preguntas, se exponen a continuación:
norm as utilizadas por su em presa con el objetivo de
• ¿Cómo realizar la cuantificación de los trabajos de reducir la cantidad de mano de obra utilizada durante
revisión? el mantenimiento. Una segunda plantilla está relacio
• ¿Debería ser tenido en cuenta el tam año del producto nada con la perspectiva. Esta plantilla pone su atención
en el cálculo de la dism inución de trabajos de revi en los factores que son importantes dentro del propio
sión o revisiones? proceso o producto que está siendo evaluado. Ejemplos
• Debería ser tenido en cuenta el incremento de mano típicos de esto incluyen los factores de calidad de la
www.FreeLibros.org
de obra de programación requerida para validaciones mantenibilidad, chequeo, uso y otros factores tales como
suplementariasy trabajos de rediseño en comparación el coste y la corrección. Esta plantilla se fundamenta en
con el proceso actual de validar un diseño corriente. la perspectiva del propio proceso al que se dirige.
67
IN GE NI E RI A DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
Hay varios enfoques que pueden hacerse sobre el pro teca de softw are reutilizable. E n este estudio se d a el so ft
ceso de desarrollo de software - e l del cliente y el del w are d e n u e stra á rea d e a p licació n p rincipal; que es la de
control de inventarios.
diseñador son los dos más típicos— y la elección de una
u otra perspectiva tiene un efecto muy grande sobre los Aquí, el propósito es la m ejora de un estándar de pro
análisis que se llevan a cabo. Por ejemplo, si un cierto gramación; la perspectiva es la de la reutilización bajo
proceso como una revisión de requisitos está siendo ana el punto de vista del personal encargado de la adm inis
lizada con respecto al coste, la perspectiva del diseñador, tración de una biblioteca de software reutilizable, y el
es la del que desea reducir el coste del proceso en térm i entorno son todos aquellos proyectos que im pliquen
nos de hacerlo más eficiente en cuanto a la detección de funciones de control de inventarios.
errores; sin embargo, si después examinamos el mismo Otro ejemplo adicional es el siguiente:
propósito pero desde el punto de vista del cliente, con D eseam os exam inar el efecto de utilizar un constructor de
cretamente sobre si su personal puede em plear o no una interfaces g ráficas, sobre la m ejora de las interfaces hom bre-
gran cantidad de tiempo en dichas revisiones, entonces m áquina, que producim os para nuestros sistem as de adm inis
la perspectiva podría involucrar el plantearse un uso más tración. E n particular, deseam os ex am in ar cóm o puede esto
afectar a la facilidad de m anejo de estas interfacespor parte del
eficiente de dicho tiem po empleado en las revisiones.
usuario. U n foco de atención principai es cóm o percibirán los
Ambas perspectivas son válidas -a- veces se solapan y usuarios de estos sistem as que dichas interfaces han cam biado.
a veces son antitéticas— existe, por ejemplo, una nece
sidad natural en el diseñador de m axim izar el beneficio Aquí, el propósito es analizar una herramienta-con
a la vez que el objetivo del cliente es la corrección máxi el objetivo de determ inar una m ejora con respecto a la
m a del producto y la entrega dentro del plazo. Un punto facilidad de uso, bajo el punto de vista del usuario den
im portante a recalcar es que del examen de la perspecti tro del contexto de los sistem as adm inistrativos. Un
va del producto, el desarrolladorestá en una mejor posi ejemplo final es el siguiente:
ción para evaluar un proceso de software y un producto N u e stro o bjetivo es ex am in ar el p roceso de c h eq u e o de
m ódulos de código de form a que podam os utilizar los resulta
de software y también la mejora de los mismos.
dos de las com probaciones con el fin de predecir el núm ero de
Una tercera plantilla implica el entorno. Este es el con defectos de código en com probaciones futuras. L a perspecti
texto dentro del cual el m étodo OPM se aplica e implica va que deseam os tener surge de una preocupación sobre el exce
el examen del personal, la propia empresa y los entornos so de errores que se han com etido y que no han sido detectados
de recursos en los que el análisis se está llevando a cabo. hasta el chequeo del sistem a. D eseam os ver qué factores son
Factores típicos de entorno incluyen, por ejemplo, el tipo im portantes que perm itan que u n program ador tom e decisio
nes sobre si un m ódulo está disponible para ser entregado a los
de sistema informático que está siendo usado, las habili
probadores del sistem a, o por el contrario requiere una com
dades del personal implicado en el proyecto, el m odelo probación adicional. D eseam os concentram osen nuestro m ode
de ciclo de vida adoptado para tal caso, la cantidad de lo de ciclo de vida actual con program adores que utilizan el
recursos adiestrados disponibles y el área de aplicación. lenguaje de program ación FO R TR A N .
Una vez que tanto el propósito como la perspectiva Aquí, el objetivo es la predicción, el análisis de un
y el entorno de un objetivo han sido bien especificados, proceso — el de chequeo de código — la perspectiva es
el proceso de planteamiento de cuestiones y el desarro la de reducción de costes a través d e una reducción del
llo de una m étrica o valoración puede comenzar. Antes núm ero de errores residuales, que se deslizan dentro del
de exam inar este proceso, merece la pena dar algunos propio chequeo del sistema. La perspectiva es desde el
ejemplos de objetivos empleados en los térm inos plan punto de vista del program ador y el entorno el de los
teados. El prim ero se describe a continuación: proyectos convencionales que utilizan el lenguaje de
El o b jetivo es analizar los m edios por los que revisam os program ación FORTRAN.
el có d ig o de p ro g ram ació n con el propósito d e e v a lu a r la La plantilla propósito se utiliza para definir lo que
efectividad en la detección de errores desde el punto de v is
está siendo estudiado: podría ser un proceso, un pro
ta del g e sto r del proyecto de softw are d entro de lo s proyec
tos que sum inistran program as críticos bajo el punto de vista
ducto, un estándar o un procedimiento. La plantilla tam
de la seguridad. bién define lo que se va a hacer, y la razón de hacerlo.
La perspectiva tiene el objetivo de asegurar que los obje
En el ejemplo planteado, el propósito es la evalua tivos no son demasiado ambiciosos: al final del día el
ción, la perspectiva es la elim inación de defectos bajo método OPM requerirá la realización de m edidas y estas
el punto de vista del gestor de proyectos dentro del m edidas y los datos estadísticos asociados serán sólo
entorno de aplicaciones en los que la seguridad es un efectivos cuanto más grande sea el número de factores
aspecto crítico. Otro ejemplo es: dentro de un nivel razonable. La plantilla del entorno
N o so tro s d eseam os ex am in ar la efectiv id ad de las n o r tiene una función similar: reduce el factor de espacio y
m as de program ación que usam os para el lenguaje de pro
perm ite que sean hechas com paraciones estadísticas
gram ación C + +, con el fin de d e te rm in a r si son efectiv os en
efectivas entre procesos y productos.
la producción de softw are, que pueda ser reutilizado dentro
www.FreeLibros.org
de otros proyectos. E n particular, estam os interesados en lo Con el fin de term inar esta sección es provechoso
que se necesita con el fin de organizarefectivam ente un depar analizar el m étodo OPM en acción sobre un pequeño
tam ento nuevo encargado de el m antenim iento de una bib lio ejemplo, con el siguiente objetivo de proceso:
68
CAPÍTULO 4 P R O C E S O DEL S O F T W A R E Y M É TR IC A S DEL P R O Y E C T O
Analícese el proceso de confección de prototipos con el pro una com plejidad ponderada C ¡ . Entonces el tam año de
pósito de evaluar desde el punto de vista del desarrollador, el los requisitos totales será:
número de requisitos que se rechazan por el cliente en una últi
n
ma etapa del proyecto.
Nosotros asumiremos un m odelo desechable de con

fección de prototipos en el que se use una tecnología Supongam os que una cierta proporció n p de estos
como la de un lenguaje típico de cuarta generación para requisitos han sido puestos en cuestión em prendiéndo
desarrollar una versión rápida de un sistem a que, cuan se un chequeo de aceptación por parte del cliente, y que
do el cliente lo ha aceptado, se im plem ente de form a estos requisitos no han sido debidos a cam bios en las
convencional con la elim inación del propio prototipo. propias circunstancias del cliente. Entonces, la m étrica
Esto plantea un cierto núm ero de preguntas que enton n
ces pueden ser procesadas con el fin de evaluar el pro e = p - l R r C¡
ceso de confección de prototipos desechables: i=O
• ¿Qué medida tomaríamos con los requerimientos que representa una cierta m edida de la desviación de los
se hayan cambiado durante la parte convencional del requisitos desde el prototipo a lo largo del chequeo de
proyecto? aceptación.
• ¿Se deben ponderar todos los requisitos de form a Este valor puede entonces ser com parado con los
igualitaria o son algunos m ás complejos que otros? valores base de otros proyectos de confección de pro
• ¿Qué tipos de cambios en los requisitos debemos con totipos que tengan un entorno parecido. Si se ha obser
siderar? Después de todo, algunos de ellos serán debi vado una cierta m ejora, la siguiente etapa es intentar
dos a imperfecciones en el proceso de confección de descubrir cómo se ha logrado esta mejora, por ejemplo,
prototipos m ientras que otros podrían tener que ver en este proyecto el cliente puede haber enviado el m is
con factores extraños que pueden ser debidos a cam mo representante para ayudar en las demostraciones del
bios en las propias circunstancias del cliente. prototipo y por consiguiente ha conseguido una con
Con el f n de aplicar el m étodo OPM , necesitam os sistencia m ayor que faltaba en otros proyectos, o el per
un modelo del proceso que esté llevándose a cabo y un sonal del desarrollo que estaba implicado en el proyecto
modelo de la perspectiva de calidad: el núm ero de cam puede haber estado form ado por analistas en lugar de
bios en los requisitos que son exigidos por el cliente no diseñadores, y así haber constituido una más sólida rela
provienen generalm ente de cambios en sus propias cir ción con el cliente. Si se observaba un incremento en la
cunstancias. m étrica e, entonces un análisis sim ilar debería llevarse
Supongamos que el m odelo para el proceso de con a cabo en térm inos de lo que constituían los factores
fección de prototipos desechables es: desfavorables que afectaban al proyecto.
Lo ya expuesto, entonces, ha sido un resumen esque
1. Especificar los requisitos.
m ático del proceso OPM. Un punto im portante a con
2. Valorar cada requisito en im portancia según térm i siderar es que y a que existe un núm ero casi infinito de
nos del cliente. m étricas que pueden usarse para caracterizar un pro
3. Valorar cada requisito en términos de la com pleji ducto de software y un proceso de software existe una
dad de su descripción. necesidad de determ inar la form a de seleccionarlas, o
4. Planificar una serie de reuniones de revisión en las que dicho de otra form a, cuál de las OPM es el m ejor ejem
se presente a través de un prototipo una cierta selec plo. Una vez que esto ha sido tom ado en consideración
ción de requisitos donde el gestor del proyecto tome en una em presa, esa em presa puede entonces im plicar
una decisión sobre en qué se basa la selección de una se en una actividad continua de m ejora de procesos, que
presentación de, por ejemplo, dos horas de duración. la coloque en un nivel 4 ó 5 de la Escala de M odelos de
Supongamos un m odelo muy simple de perspectiva M adurez de Capacidades y así distinguirla de aquellas
de calidad, dónde cada requisito R t esté asociado con otras que lleguen sólo a niveles 1 ó 2.
Debido a que el proceso de software y el producto que to no será la m ism a que otras métricas similares selec
tal proceso produce son am bos influenciados por cionadas para otro proyecto. En efecto, hay a m enudo
mucho's parám etros (por ejem plo: el nivel de habili variaciones significativas en las métricas elegidas como
dad de los realizadores de dichos procesos, la estruc parte del proceso de software.
tura del equipo de softw are, el con o cim ien to del Puesto que la misma métrica de procesos variará de un
www.FreeLibros.org
cliente, la tecnología que va a ser im plem entada, las proyecto a otro proyecto, ¿cómo podem os decir si unos
herramientas que serán usadas en la actividad de desa valores de métricas m ejoradas (o degradadas) que ocu
rrollo), la m étrica elegida para un proyecto o produc rren como consecuencia de actividades de mejora están
69
I N GE NI E RÍ A DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
de hecho teniendo un impacto cuantitativo real? ¿Cómo 1. Calcular los rangos móviles: el valor absoluto de las
saber si lo que nosotros estamos contemplando es una ten diferencias sucesivas entre cada pareja de puntos de
dencia estadísticam ente válida o si esta «tendencia» es datos... Dibujar estos rangos móviles sobre el gráfico.
simplementeel resultado de un ruido estadístico? ¿Cuán 2. Calcular la m edia de los rangos m óviles... dibujando
do son significativos los cambios (ya sean positivos o ésta («barra Rm») com o la línea central del propio
negativos) de una m étrica de software particular? gráfico.
3. M ultiplicar la m edia por 3.268. D ibujar esta línea
com o el límite de control superior [LCS]. Esta línea
supone tres veces el valor de la desviación estándar
. i mensos paro la gestión
por encim a de la media.
, áJ, «tfjrígbfos, Afe lodo logue lio;,
U sando los datos representados en la figura 4 .8 y los
venación.
distintos pasos sugeridos por Z ultner com o anterior
B M p i i ’v
m ente se ha descrito, desarrollam os un gráfico de co ni
tral Rm que se muestra en la Figura 4.9. El valor (medio)
Se dispone de una técnica gráfica para determ inar si «barra Rm» para los datos de rango m óvil es 1.71. El
los cambios y la variación en los datos de la m étrica son límite de control superior (LCS) es 5.57.
significativos. Esta técnica llam ada gráfico de control
y desarrollada por W alter Shewart en 1920 ", permite
que los individuos o las personas interesadas en la m ejo
ra de procesos de software determ ine si la dispersión Sí m podemos contar señales desde el ruido, como
(variabilidad)y «la localización» (media móvil) o m étri sobremos si los cambios en el proceso son mejoras-
cisio n e .
ca de procesos que es estable (esto es, si el proceso exhi
Richard Zuttner
be cam bios controlados o sim plem ente naturales) o
inestable (esto es, si el proceso exhibe cambios fuera Para determ inar si la dispersión de las m étricas del
de control y las m étricas no pueden usarse para prede proceso es estable puede preguntarse una cuestión muy
cir el rendim iento). Dos tipos diferentes de gráficos de sencilla: ¿Están los valores de rango móvil dentro del
control se usan en la evaluación de los datos m étricos LC S? Para el ejem plo descrito anteriorm ente, la con
[ZUL99]: (1) el gráfico de control de rango móvil (Rm) testación es «sí». Por consiguiente, la dispersión de la
y (2) el gráfico de control individual. m étrica es estable.
Para ilustrar el enfoque que significa un gráfico de El gráfico de control individual se desarrolla de la
control, consideremos una organización de software que m anera siguiente":
registre en la métrica del proceso los errores descubiertos
1. Dibujar los valores de la m étrica individual según se
por hora de revisión, E,. Durante los pasados 15 meses,
describe en la Figura 4.8.
la organización ha registrado el E,. para 20 pequeños
proyectos en el m ism o dom inio de desarrollo de soft 2. Calcular el valor prom edio, A,, para los valores de
ware general. Los valores resultantes para E están repre la métrica.
sentados en la figura 4.8. Si nos referim os a la figura, 3. M ultiplicar la m edia de los valores Rm (la barra Rm)
E, varía desde una tasa baja de 1.2 para el proyecto 3 a por 2.660 y añadir el valor de A, calculado en el paso
una tasa m ás alta de 5.9 para el proyecto 17. En un 2. Esto da lugar a lo que se denom ina límite de p r o
esfuerzo de m ejorar la efectividad de las revisiones, la ceso natural superior (LPNS). Dibujar el LPNS.
organización de software proporcionaba entrenam ien 4. M ultiplicar la m edia de los valores Rm (la barra Rm)
to y asesoram iento a todos los m iem bros del equipo del por 2.660 y restar este valor del A, calculado en el
proyecto, com enzando con el proyecto 11. paso 2. Este cálculo da lugar al lím ite de pro ceso
natural inferior (LPNZ). Dibujar el LPNI. Si el LPNI
es m enor que 0.0, no necesita ser dibujado a m enos
¿Cómo podemos estar que la m étrica que está siendo evaluada tome valo
seguros de que las métricas res que sean m enores que 0.0.
que hemos recopilado son
5 C alcular la desviación estándar según la fórm ula
estadísticamente validas?
(LPNS - A m)/3. D ibujar las líneas de la desviación
estándar una y dos por encim a y por debajo de A,.
R ichard Zultner proporciona una vista general del Si cualquiera de las líneas de desviación estándar es
procedim iento que se requiere para desarrollar un grá m enor de 0.0, no necesita ser dibujada a m enos que
fic o de control de rango móvil (Rm) para determ inar la la m étrica que está siendo evaluada tome valores que
estabilidad del proceso [ZUL99]: sean m enores que 0 .0 .
www.FreeLibros.org
10 D ebería ten e rse en cu en ta que aunque el gráfico de control fue
desarrollado originalm ente para procesos de fabricación e s igual ' 1El estudio que sigue es un resum en de los pasos sugeridos por Zult
m ente aplicable a procesos de softw are. ner [ZUL991- " "
70
CA PÍ T U L O 4 P R O C E S O DEL SO F TW AR E Y M ÉT RI CA S DEL P R O Y E C T O
FIGURA 4.8. Datos de m étricas para descubrir errores F IG U R A 4 .9 . Gráfico de control de rango m óvil (Rm),
por hora de revisión.
Aplicando estos pasos a los datos representados en

la Figura 4.8, se llega a un gráfico de control individual
según se ve en la figura 4.10.
Referencia
Se puede encontrar un Gráfico de Control Común
que cubre el tema en alguna dimensión en: Proyectos
www.sytsma.com/tqmtools/ctlchf principles.html F IG U R A 4 .1 0 . Gráfico de control individual.
Zultner [ZUL99] revisa cuatro criterios, denom i

nados reglas de zona, que pueden usarse para evaluar Puesto que todas estas condiciones fallan para los
si los cambios representados por la m étrica indican valores m ostrados para la figura 4.10, se concluye que
que un proceso está bajo control o fuera de control. los datos de las métricas se derivan de un proceso esta
Si cualquiera de las siguientes condiciones es verda ble y que se pueden deducir legítim am ente a partir de
dera, los datos de la m étrica indican un proceso que los datos recogidos en la m étrica una inform ación que
está fuera de control: constituye una verdadera tendencia. Si nos referim os
a la figura 4.1O, puede verse que la variabilidad de E,
1. Un valor de la m étrica individual aparece fuera del decrece a partir del proyecto 10 (esto es, después de
LPNS. un esfuerzo para m ejorar la efectividad de las revisio
2. Dos de cada tres valores de métricas sucesivas apa nes). Calculando el valor m edio para los 10 prim eros
recen más de dos desviaciones estándar fuera del y los 10 últim os proyectos, puede dem ostrarse que el
valor A,. valor m edio de E r para los p ro y ecto s del 11 al 20,
3. Cuatro de cada cinco valores de métricas sucesivas m uestran un 29 por 100 de m ejora en relación con la
aparecen alejados m ás de una desviación estándar E t de los proyectos 1 al 10. Puesto que el gráfico de
del valor A,. control indica que el proceso es estable, parece que los
4. Ocho valores consecutivos de métrica aparecen todos esfuerzos para m ejorar la efectividad de la revisión
situados a un lado del valor A,. dan sus resultados.
La amplia m ayoría de las organizaciones de desarrollo [KAU99] describe un escenario típico que ocurre cuan
de software tienen m enos de 20 personas dedicadas al do se piensa en program as m étricos para organizacio
software. Es poco razonable, y en la mayoría de los casos nes pequeñas de software:
no es realista, esperar que organizaciones com o éstas Originalmente, los desarrolladoresde software acogían nues
desarrollen program as métricos de software extensos. tras actividadescon un alto grado de escepticism o,pero al final
Sin embargo, si que es razonable sugerir que organiza las aceptaban debido a que nosotros conseguíam os que nues
tras m edidas fueran sim ples de realizar.adaptadas a cada orga
ciones de software de todos los tam años m idan y des
nización y se a seg u rab a que d ichas m edidas pro d u cían una
www.FreeLibros.org
pués utilicen las m étricas resultantes para ayudar a inform ación válida y útil. Al final, los program as proporcio
mejorar sus procesos de software local y la calidad y naban una base para encargarse d e los clientes y para la plani
oportunidad de los productos que realizan. Kautz ficación y desarrollo de su trabajo futuro.
71
IN GE NI ER ÍA DEL S O F TW A RE . UN E N F O Q U E P R A C T I C O
. Defectos descubiertos después de que el cam bio se

haya desviado a la base del cliente, D camb¡0-
Si estás empezando a reunir métricas del software,
recuerda guordorlns.Si te entierros con datas, tu esfuerzo jÉBfc. ¿Cómo puedo derivar
conlos métricos puede fallar. W un conjunto «simple»
de métricas del software?
Lo que Kautz sugiere es una aproxim ación para la
im plementación de cualquier actividad relacionada con
Una vez que estas medidas han sido recogidas para
el proceso del software: que sea simple; adaptada a satis
un cierto número de peticiones de cambio, es posible cal
facer las necesidades locales y que se constate que real
cular el tiem po total transcurrido desde la petición de
mente añada valor. En los párrafos siguientes examinamos
cambio hasta la im plementación de dicho cam bio y el
cómo se relacionan estas líneas generales con las m étri
porcentaje de tiem po consumido por el proceso de colas
cas utilizadas para negocios pequeños.
iniciales, la asignación de cambio y evaluación, y la imple-
«P ara hacerlo fá cil» , es una línea de acción que
mentación del cambio propiamente dicho. De forma simi
funciona razonablem ente bien en m uchas actividades.
lar, el porcentaje de esfuerzo requerido para la evaluación
Pero jc ó m o deducim os un conjunto sencillo de m étri
y la im plem entación puede tam bién ser determinado.
cas de software que proporcionen valor, y cóm o pode
Estas métricas pueden ser evaluadas en el contexto de los
m os e sta r seguros de que estas m étricas sencillas
datos de calidad, Ecqmbjoy Dcumb¡u. Los porcentajes pro
lograran satisfacer las necesidades de una organiza
porcionan un análisis interno para buscar el lugar donde
ción de softw are particular? C om enzam os sin c e n
los procesos de petición de cambio se ralentizan y pue
trarn o s en la m edición, pero sí en los resu ltad o s
den conducir a unos pasos de mejoras de proceso para
finales. El grupo de software es interrogado para que
defina un objetivo sim ple que requiera m ejora. Por reducir tco¡a , Vi ¡ ’feval.’ ^ cambio’ 3^° L'mmbjo- Además,
la eficiencia de elim inación de deíectos (EED) puede ser
ejem p lo , « red u cir el tiem po p ara ev alu ar e im p le
calculada de la siguiente manera:
m entar las peticiones de cambio». U na organización
pequeña puede seleccionar el siguiente conjunto de ^ E D — ^ c a m b io ^ ^ c a m b i o ^ ^ c a m b i e )
m edidas fácilm ente recolectables:
EED puede compararse con el tiem po transcurrido y el
• Tiem po (horas o días) que transcurren desde el
esfuerzo total para determ inar el im pacto de las activi
m om ento que es realizada una petición hasta que se
dades de aseguramiento de la calidad sobre el tiem po y
complete su evaluación, tco¡a.
el esfuerzo requeridos para realizar un cambio.
• Esfuerzo (horas-persona) para desarrollar la evalua- Para grupos pequeños, el coste de incorporar medi
ción, Weva, das y métricas de cálculo oscila entre el 3 y el 8 por 100
• Tiempo (horas o días) transcurridos desde la term i del presupuesto del proyecto durante la fase de apren
nación de la evaluación a la asignación de una orden dizaje y después cae a m enos del 1 por 100 del presu
de cambio al personal, feva|. puesto del proyecto una vez que la ingeniería del
• Esfuerzo (horas-persona) requeridas para realizar el software y la gestión de proyectos se hayan fam iliari
cambio, Wcambi0. zado con el program a de métricas [GRA99], Estos cos
• Tiempo requerido (horas o días) para realizar el cam tes pueden representar una m ejora de las inversiones
b i o , ^cambio' siempre que el análisis derivado a partir de los datos de
• Errores descubiertos durante el trabajo para realizar la m étrica conduzcan a una m ejora de procesos signifi
el cambio, £ cambio. cativa para la organización del software.
4.10 ESTABLECIMIENTO DE UN PROGRAMA DE MÉTRICAS DE SOFTWARE

El Instituto de Ingeniería del Software (IIS) ha desarro 6. Identificar preguntas que puedan cuantificarsey los
llado una guía extensa [PAR96] para establecer un pro indicadores relacionados que se van a usar para
grama de medición de software dirigido hacia objetivos. ayudar a conseguir los objetivos de medición.
La guía sugiere los siguientes pasos para trabajar: 7. Identificar los elementos de datos que se van a reco
1. Identificarlos objetivos del negocio. ger para construir los indicadores que ayuden a res
ponder a las preguntas planteadas.
2. Identificar lo que se desea saber o aprender.
8. Definir las m edidas a usar y hacer que estas defi
3. Identificar los subobjetivos. niciones sean operativas.
4. Identificarlas entidades y atributos relativos a esos
www.FreeLibros.org
9. Identificar las acciones que serán tom adas para
subobjetivos. mejorar las m edidas indicadas.
5. Form alizar los objetivos de la medición. 10. Preparar un plan para im plem entar estas medidas.
72
CAPÍTULO 4 P R O C E S O DEL S O F T W A R E Y M É T R I C A S DEL P R O Y E C T O
nización de software sean anotadas convenientemente.

•V * Ejem plo de tales entidades incluye: recursos de desarro
Referencia W e b l v llo, productos de trabajo, código fuente, casos de prueba,
peticiones de cambio, tareas de ingeniería de software y
Se puede descargaruna guía pora la medición del software planificaciones. Para cada entidad listada, el personal dedi
orientado a objetivos desde: www.sei.tmu.edu
cado al softwaredesarrollauna serie de preguntas que eva
Si se quiere entrar en una discusión más profunda de lúan las características cuantitativas de la entidad (por
los pasos anteriores, lo m ejor es acudir directamente a ejemplo: tamaño, coste, tiem po para desarrollarlo). Las
la guía ya com entada del US (SEI) Instituto de Inge cuestiones derivadas como una consecuencia de la crea
niería del Softwate. Sin embargo, m erece la pena repa ción-de una lista tal de preguntas-entidad, conducen a la
sar brevemente los puntos clave de ésta. derivación de un conjunto de objetivos de segundo nivel
Ya que el software, en prim er lugar, soporta las fun (subobjetivos)que se relacionan directamentecon las enti
ciones del negocio, en segundo lugar, diferencia o clasi dades creadas y las actividades desarrolladas com o una
fica los sistemas o productos basados en computadora, y parte del proceso del software.
en tercer lugar puede actuar como un producto en sí m is C on sid érese el cuarto objetivo apuntado antes:
mo, los objetivos definidos para el propio negocio pue «H acer que el soporte para nuestros productos sea m ás
den casi siempre ser seguidos de arriba abajo hasta los fácil». La siguiente lista de preguntas pueden ser deri
objetivos más específicos a nivel de ingeniería de soft vadas a partir de este objetivo [PAR96]:
ware. Por ejemplo, considéreseuna com pañía que fabri • ¿C ontienen las preguntas de cam bio del cliente la
ca sistemas avanzados para la seguridad del hogar que inform ación que nosotros requerim os para evaluar
tienen un contenido de software sustancial. Trabajando adecuadam ente el cam bio y de esa form a realizarle
como un equipo, los ingenieros de software y los gesto en un tiem po y form as oportunos?
res del negocio, pueden desarrollaruna lista de objetivos • ¿C óm o es de grande el re g istro de peticiones de
del propio negocio convenientem entepriorizados: cam bio?
1. Mejorar la satisfacción de nuestro cliente con nues • ¿Es aceptable nuestro tiempo de respuesta para localizar
tros productos. errores de acuerdo a las necesidades del cliente?
2. Hacer que nuestros productos sean más fáciles de usar. • ¿Se sigue conv en ien tem en te n u estro p ro ceso de
3. Reducir el tiem po que nos lleva sacar un nuevo control de cam bios (Capítulo 9)?
producto al mercado. • ¿Se llevan a cabo los cam bios de alta prioridad de
4. Hacer que el soporte que se dé a nuestros produc m anera oportuna y sincronizada?
tos sea más fácil. B asándose en estas cuestiones, la organización de
5. Mejorar nuestro beneficio global. software puede deducir los objetivos de segundo nivel
(subobjetivos) siguientes: M ejorar el rendim iento del
proceso de gestión del cambio. Las entidades de proceso
CLAVE de softw are y atributos que son relevantes para los
las métricas del software que elijas estarbn tonducldas propósitos u objetivos m ás específicos o de segundo
por el negocio o por los objetivos técnicos que desees nivel son identificados y se definen adem ás las m etas u
cumplir. objetivos de m edida asociados con dichos atributos.
El IIS [PAR96] proporciona una guía detallada para
La organización de software examina cada objetivode los pasos 6 al 10 de este enfoque de m edida o rien ta
negodosy se pregunta: «¿Qué actividades gestionaremos do hacia objetivos. En esencia, se aplica un proceso
(ejecutaremos) y qué queremos mejorar con estas activi- de refinam iento por pasos en el que los objetivos son
dades?»Para responder a estas preguntas el IIS recomienda refinados en preguntas que son a su vez refinadas de
la creación de una «lista de preguntas-entidad», en la que form a m ás detallada en entidades y atributos que por
todas las cosas (entidades) dentro del proceso de softwa Último se analizan en un Último paso de fo rm a m ás
re que sean gestionadas o estén influenciadaspor la orga- m inuciosa a nivel de la m étrica en s í.
La medición perm ite que gestores y desarrolladores to se utilizan para calcular las m étricas del so ftw a
mejoren el proceso del softw are, ayuden en la p la re. E stas m étricas se pueden an alizar para p ro p o r
nificación, seguim iento y control de un proyecto de cionar indicadores que guían acciones de gestión y
www.FreeLibros.org
software, y evalúen la calid ad del pro d u cto (so ft técnicas.
ware) que se produce. Las m edidas de los atributos Las m étricas del proceso perm iten que una o rg a
específicos del proceso, del proyecto y del produc- nización tom e una visión estratégica p ro p o rcio n an
73
IN GE NI ER ÍA DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
do m ayor profundidad de la efectividad de un proce áreas de proceso del software que son la causa de los
so de software. Las m étricas del proyecto son tá c ti defectos del software.
cas. Estas perm iten que un gestor de proyectos adapte Las m étricas tienen significado solo si han sido
el enfoque a flujos de trabajo del proyecto y a pro exam inadas para una v alid ez estadística. El gráfico
yectos técnicos en tiem po real. de control es un m étodo sencillo para realizar esto y
Las métricas orientadas tanto al tam año com o a la al m ism o tiem po exam inar la variación y la localiza
función se utilizan en toda la industria. Las m étricas ción de los resultados de las m étricas.
orientadas al tam año hacen uso de la línea de código La m edición produce cam bios culturales. La reco
com o facto r de norm alización para o tras m ed id as, pilación de datos, el cálculo de métricas y la evaluación
com o persona-m es o defectos. E l punto de función de métricas son los tres pasos que deben implementar-
proviene de las m edidas del dom inio de inform ación se al com enzar un program a de métricas. En general,
y de una evaluación subjetiva de la com plejidad del un enfoque orientado a los objetivos ayuda a una orga
problema. nización a centrarse en las métricas adecuadas para su
Las m étricas de la calid ad del so ftw are, com o negocio. Los ingenieros del software y sus gestores pue
m étricas de productividad, se centran en el proceso, den obtener una visión m ás profunda del trabajo que
en el proyecto y en el producto. D esarrollando y ana realizan y del producto que elaboran creando una línea
lizan d o u na lín ea base de m étricas de ca lid a d , una base de m étricas - u n a base de datos que contenga
organización puede actuar con objeto de corregir esas mediciones del proceso y del p r o d u c to - . "
[ALA97] Alain, A., M. Maya, J. M. Desharnais y S. St. Pie- [IEE93] IEEE Software Engineering Standards, Std. 610.12-
rre, «Adapting Function Points to Real-Time Software», 1990,pp. 47-48.
American Programmer, vol. 10,n.e 11,Noviembre 1997,
[IFP94] Function Point Counting Practices Manual, Release
pp. 32-43.
4.0, IntemationalFunction Point Users Group (IFPUG), 1994.
[ART85] Arthur, L. L,M easuring Programmer Productivity
[JON86] Jones, C., Programming Productivity, McGraw-Hill,
and Software Quality, Wiley-Interscience, 1985.
1986. '
[ALB79] Albrecht, A. ]., «Measuring Application Develop-
[JON91] Jones, C., Applied Software Costs, McGraw-Hill,
ment Productivity», Proc. IBM Application Development.
1991.
Symposium, Monterey, CA, Octubre 1979, pp. 83-92.
[JON98] Jones, C., Estimating Software Costs, McGraw-Hill,
[ALB83] Albretch, A. J., y J. E. Gaffney, «Software Func
1998. ’
tion, Source Lines of Code and Development Effort Pre-
diction: A Software Science Validation», IEEE Trans. [KAU99] Kautz, K., «Making Senseof Measurement for Small
Software Engineering, Noviembre 1983, pp. 639-648. Organizations»,/®??? Software, Marzo 1999,pp. 14-20.
[BOE81] Boehm, B ., Software Engineering Economics, Pren- [MCC78] McCall, J. A., y J. P. Cavano, «AFramework for
tice Hall, 1981. the Measurement of Software Quality», ACM Software
QualityAssurance Workshop,Noviembre 1978.
[GRA87] Grady,R.B., y D.L. Caswell,Software Metrics: Esta-
blishing a Company-Wide Program, Prentice-Hall, 1987. [PAU94] Paulish, D., y A. Carleton, «Case Studies of Soft
ware Process Improvement Measurement», Computer, vol.
[GRA92] Grady, R.G., Practical Software Metrics fo r Pro- 27, n.° 9, Septiembre 1994, pp. 50-57.
je ct. Management and Process Improvement, Prentice-Hall,
1992. [PAR96] Park, R. E., W. B. Goethert y W. A. Florac, Goal
Driven Software Measurement-A Guidebook, CMU/SEI-
[GRA94] Grady, R., «Succesfully Applying Software 96-BH-002, Software Engineering Institute, Carnegie
Metrics», Computer, vol. 27, n.° 9, Septiembre 1994,pp. Mellon University, Agosto 1996.
18-25.
[RAG95] Ragland, B., «Measure. Metnc or Indicator: What'c
[GRA99] Grable,R., et al., «Metrics for SmallProjects: Expe- the Difference?», Crosstalk, vol. 8, n.° 3, Marzo 1995,
riences at SED»,IEEE Software, Marzo 1999,pp. 21-29. pp. 29-30.
[GIL88] Gilb, T., Principies o f Software Project M anage [TAL81] Tjima, D., y T. Matsubara, «The Computer Software
ment, Addison-Wesley, 1998. Industry in Japan», Computei; Mayo 1981,p. 96.
[HET93] Hetzel, W., Making Software Measurement Work, [WHI95] Whitmire, S. A., «An Introduction to 3D Function
QED Publishing Group, 1993. Points», Software Development, Abril 1995,pp. 43-53.
www.FreeLibros.org
[HUM95] Humphrey, W.,,4 D iscipline fo r Software E ngi [ZUL99] Zultner, R. E., «What: Do Our M etrics Mean?»,
neering, Addison-Wesley, 1995. Cutter IT Journal, vol. 12,n.° 4, Abril 1999,pp. 11-19.
74
CAPÍTULO 4 P R O C E S O DEL S O F T W A R E Y MÉ TR IC A S DEL P R O Y E C T O
;%QL. :M.JaJLEII•i.Ifl.SJfr XLQ;:S1BE ...

4.1. Sugiera tres medidas, tres métricas y los indicadores que Número de archivos: 8
se podrían utilizar para evaluar un automóvil. Número de interfaces externos: 2
4.2. Sugiera tres medidas, tres métricas y los indicadores Asuma que todos los valores de ajuste de complejidad están
correspondientes que se podrían utilizar para evaluar el en la media.
departamento de servicios de un concesionario de automó
viles. 4.12. Calcule el valor del punto de función de un sistema empo
trado con las características siguientes:
4.3. Describa, con sus propias palabras, la diferencia entre
métricas del proceso y del proyecto. Estructuras de datos interna: 6
Estructuras de datos externa: 3
4.4. ¿Por qué las métricas del software deberían mantenerse
«privadas»?Proporcione ejemplos de tres métricas que debie Número de entradas de usuario: 12
ran ser privadas. Proporcione ejemplos de tres métricas que Número de salidas de usuario: 6 0
debieran ser públicas. Número de peticiones de usuario: 9
4.5. Obtenga una copia de [HUM95] y escriba un resumen en Número de interfaces externos: 3
una o dos páginas que esquematice el enfoque PSP. Transformaciones: 36
Transiciones: 24
4.6. Grady sugiere una etiqueta para las métricas del soft
ware. ¿Puede añadir más reglas a las señaladas en la Sec Asuma que la complejidad de las cuentas anteriores se divi
ción 4.2.1? de de igual manera entre bajo, medio y alto.
4.7. Intente completar el diagrama en espina de la Figura 4.3. 4.13. El software utilizado para controlar una fotocopiadora
Esto es, siguiendo el enfoque utilizado para especificaciones avanzada requiere 32.000 líneas de C y 4.200 líneas de Small-
«incorrectas»,proporcione información análoga para «perdi talk. Estime el número de puntos de función del software de
do, ambiguo y cambios». la fotocopiadora.
4.8. ¿Qué es una medida indirecta y por qué son comunes tales 4.14. McCall y Cavano (Sección 4.5.1) definen un «marco de
cambios en un trabajo de métricas de software? trabajo» de la calidad del software. Con la utilización de la
información de este libro y de otros se amplían los tres «pun
4.9. El equipo A encontró 342 errores durante el proceso de tos de vista» importantes dentro del conjunto de factores y de
ingenieríadel software antes de entregarlo. El equipo B encon métricas de calidad.
tró 184 errores. ¿Qué medidas adicionales se tendrían que
tomar para que los proyectos A y B determinen qué equipos 4.15. Desarrolle sus propias métricas (noutilice las presenta
elimináronlos errores más eficientemente?¿Qué métricas pro das en este capítulo) de corrección, facilidad de mantenimiento,
pondrían para ayudar a tomar determinaciones? ¿Qué datos integridad y facilidad de uso. Asegúrese de que se pueden tra
históricos podrían ser útiles? ducir en valores cuantitativos.
4.16. ¿Es posible que los desperdicios aumenten mientras que
4.10. Presente un argumento en contra de las líneas de códi
disminuyen defectos/KLDC? Explíquelo.
go como una medida de la productividad del software. ¿Se va
a sostener su propuesta cuando se consideren docenas o cien 4.17. ¿Tiene algún sentido la medida LDC cuando se utiliza
tos de proyectos? el lenguaje de cuarta generación? Explíquelo.
4.11. Calcule el valor del punto de función de un proyecto con 4.18. Una organización de software tiene datos EED para 15
las siguientes características del dominio de información: proyectos durante los 2 últimos años. Los valores recogidos
son: 0.81,0.71, 0.87, 0.54, 0.63, 0.71, 0.90, 0.82, 0.61, 0.84,
Número de entradas de usuario: 32
0.73,0.88, 0.74,0.86, 0.83. Cree Rm y cuadros de control indi
Número de salidas de usuario: 60 viduales para determinar si estos datos se pueden utilizar para
Número de peticiones de usuario: 24 evaluar tendencias.
La mejora del proceso del software (MPS) ha recibido una Garmus, D., y D. Elerron, Measuring the Software Pro
significativa atención durante la pasada década. Puesto que cess: A Practical Guide to Functional Measurements, Pren-
la medición y las métricas del software son claves para con tice-Hall, 1996.
seguir una mejora del proceso del software, muchos libros Kan, S. H.,M etrics andModels in Software Quality Engi
sobre MPS también tratan las métricas. Otras lecturas adi neering, Addison-Wesley, 1995.
cionales que merecen la pena incluyen: Humphrey [HUM95], Yeh (Software Process C ontrol,
Burr, A., y M. Owen,Statistical M ethosfor Software Qua- McGraw-Hill, 1993), Hetzel [HET93] y Grady [GRA92] estu
www.FreeLibros.org
lity, International Thomson Publishing, 1996. dian cómo se pueden utilizar las métricas del software para pro
Florac, W. A., y A. D. Carleton,Measuring the Software porcionar los indicadores necesarios que mejoren el proceso
Process: Statistical Process Control for Software Process del software. Putnam y Myers (Executive Briefing: Controlling
lmprovement, Addison-Wesley, 1999. Software Development, IEEE Computer Society, 1996) y Pul-
75
IN GE NI E RÍ A DEL S OFT W ARE . UN E N F O Q U E PR AC T I C O
f o r d y sus c o le g a s (AQuantitative Approach to Software Mana c a s d e l so ftw a re . Parky o tro s [P A R 9 6 ] h a n d e s a rro lla d o u n a
gement, A d d iso n -W e sle y , 1 9 9 6 )e s tu d ia n la s m é tric a s d e l p r o g u ía d e ta lla d a q u e p ro p o rc io n a p a so a p a so su g e re n c ia s p a ra
c e so y su u s o d e sd e e l p u n to d e v is ta d e la g e stió n . i n s t it u i r u n p r o g r a m a d e la s m é t r i c a s d e l s o f tw a r e p a r a la
W e in b e rg ( Quality Software Management, Volume2: First m e jo ra d e l p ro c e s o d e l so ftw a re .
OrderMeasurement, D o rs e t E louse, 1 9 9 3 )p re s e n ta u n m o d c - L a h o ja in fo rm a tiv a /7 ’Metrics (E d ita d a p o r E lo w a rd R u b in
lo ú til p a ra o b s e rv a r p ro y e c to s d e so ftw a re , a s e g u rá n d o s e e l y p u b lic a d a p o r lo s S e r v ic io s d e In fo rm a c ió n C u tte r) p r e s e n
sig n ific a d o d e la o b s e rv a c ió n y d e te rm in a n d o e l sig n ific a d o ta c o m e n ta r io s Ú tiles so b re e l e s ta d o d e la s m é tric a s d e l s o ft
d e la s d e c is io n e s tá c tic a s y e s tra té g ic a s . G a rm u s y H e r r o n w a re e n la in d u stria . L a s re v is ta s Cutter I T Journal y Software
(Measuring the Software Process, P re n tic e -H a ll, 1996) tra ta Development tie n e n h a b itu a lm e n te a r tíc u lo s y c a r a c t e r í s t i
la s m é tric a s d e l p ro c e s o e n e l a n á lis is d e l p u n to d e fu n c ió n . c a s c o m p le ta s d e d ic a d a s a la s m é t r i c a s d e l s o f tw a re .
E l S o ftw a re P ro d u c tiv ity C o n s o rtiu m ( The Software Measu E n I n te m e t e s tá n d is p o n ib le s u n a g ra n v a rie d a d d e f u e n
rement Guidebook, T h o m s o n C o m p u te r P r e s s , 1 9 9 5 ) p r o - te s d e in f o r m a c ió n r e la c io n a d a s c o n te m a s d e l p ro c e s o d e l
p o rc io n a su g e re n c ia s ú tile s p a ra in stitu ir u n e n fo q u e e fe c tiv o so ftw a re y d e la s m é tric a s d e l so ftw a re . S e p u e d e e n c o n tra r
d e m é tric a s. O m a n y P f le e g e r (Applying Software Metrics, u n a lis ta a c tu a liz a d a c o n r e fe r e n c ia s a s itio s ( p á g in a s ) w e b
I E E E C o m p u te r S o c ie ty P re s s , 1997) h a n e d ita d o u n a e x c e q u e s o n r e le v a n te s p a r a e l p ro c e s o d e l S o ftw a re y p a ra las
le n te a n to lo g ía d e d o c u m e n to s im p o rta n te s so b re la s m é tr i m é tric a s d e l p ro y e c to e n http://www.pressman5.com.
C A PÍT U L O
PLANIFICACIÓN DE PROYECTOS
5 DE SOFTWARE
A gestión de un proyecto de software com ienza con un conjunto de actividades que glo
L balmente se áenom m anplanificación del proyecto. Antes de que el proyecto com ience,
el gestor y el equipo de software deben realizar una estim ación del trabajo a realizar, de
los recursos necesarios y del tiem po que transcurrirá desde el comienzo hasta el final de su re
lización. Siem pre que estim am os, estam os m irando hacia el futuro y aceptam os resignados
cierto grado de incertidumbre.
Aunque la estim ación es m ás un arte que una ciencia, es una actividad im portante que no
debe llevarse a cabo de forma descuidada. Existen técnicas Utiles para la estim ación del esfuer
zo y del tiempo. Las métricas del proyecto y del proceso proporcionan una perspectiva histó
rica y una potente introducción para generar estim aciones cuantitativas. La experiencia anterior
(de todas las personas involucradas) puede ayudar en gran m edida al desarrollo y revisión de
las estimaciones. Y, dado que la estim ación es la base de todas las demás actividades de pla
nificación del proyecto, y que sirve com o guía para una buena ingeniería del software, no es en
absoluto aconsejable embarcarse sin ella.
V IS T A Z O R Á P ID O
¿Qué es? l a planificación d e u n proyec m as y productos b a sa d o s e n c o m p u ta ¿Cuál e s e l p ro d u cto o b te n id o ? Se

to d e so ftw a re re a lm e n te co m p re n d e dora c u e s ta n c o n sid e ra b le m e n te m ás o b tie n e u n a ta b la q u e in d ic a la s ta re
to d as la s a c tiv id a d e s tr a ta d a s e n lo s q u e construir una c a s a g ra n d e , podría a s a de sa rro llar, la s funciones a im ple-
C a p ítu lo s 5 a l 9. S in e m b a rg o , e n el ser razonable d esarrollary e s tim a a n te s m en ta r, y el c o ste , e sfu e rz o y tie m p o
co n tex to d e e ste cap ítu lo , la p lan ifica d e em pezar a construir el software. n e c e sa rio p a ra la re aliz a ció n d e c a d a
ción im plica la estim ació n —su in te n una. T am bién se o b tie n e u n a lis ta d e
¿C uáles son lo s p a so s? La estim ación
to por d e te rm in a r c u á n to d in ero , re c u rso s n e c e s a rio s p a ra el proyecto.
c o m ie n za con u n a d e sc rip c ió n del
esfuerzo, recursos, y tiem p o su p o n d rá ¿Cómo p u e d o e s ta r se g u r o d e q ue
ám b ito d e l producto. H a sta q u e no se
construir un siste m a o producto e sp e lo h e h ech o correctam en te? Esto
«delim ita» el ám b ito no e s posible re a
cífico d e software — . e s difícil, p u e sto q u e re a lm e n te no lo
lizar u n a e s tim a c ió n con sen tid o . El
¿Quién lo h a c e ? Los g e sto re s d el soft p ro b le m a e s e n to n c e s d e sc o m p u e sto s a b rá h a sta q u e el proyecto h a y a fin a
w are — utilizándola inform ación so li e n un conjunto d e pro b lem as d e m enor lizado. Sin e m b a rg o , si tie n e e x p e rie n
c ita d a a los c lie n te s y a los in g e n ie ro s ta m a ñ o y c a d a uno d e é sto s s e estim a c ia y s ig u e u n e n fo q u e sis te m á tic o ,
de so ftw a rey los d a to s d e m étricas d e g u iá n d o s e con d a to s histó rico s y con re a liz a e stim a c io n e s utilizan d o d a to s
softw are obten id o s d e proyectos a n te la experiencia. Es a c o n s e ja b le realizar histó rico s sólidos, c re a p u n to s d e e s ti
riores— . l a s e stim a c io n e s utilizan d o a l m enos m ación m e d ia n te a l m enos d o s m éto
¿Por q u é e s im portante? ¿Podría cons d o s m étodos d iferen tes (com ocom pro- d o s d ife re n te s y d e sc o m p o n e la
truir una c a sa sin sa b e r cuanto e staría bación). La co m p lejid ad y el riesgo del c o m p le jid a d y rie sg o , p u e d e e s ta r
d ispuesto a g a star? . Por su p u e sto q ue p roblem a se considera a n te s d e re a li seg u ro d e h a b e r a c e rta d o plenam ente.
no,y puesto que la m ayoría d é lo s siste z a r u n a estim ació n final.
I N G E N IE RÍ A DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
5.1 O B SER V A C IQ N gé SQ B R E L A ESTIM A C IÓ N

A un destacado ejecutivo se le preguntó una vez por la
característica m ás importante que debe tener un gestor
de proyectos. Respondió: « ...una persona con la habi C LA VE
lidad de saber qué es lo que va a ir mal antes de que ocu
la complejidaddel proyecto, el tamaño del proyectoyel
rra...» . Debemos añadir: « ...y con el coraje para hacer
grado de Incertidumbreestructural afectan a la fiabilidad
estim aciones cuando el futuro no está claro...». de la estimación.
La estimación de recursos, costes y planificación tem
poral de un esfuerzo en el desarrollo de software requie E l grado de incertidumbre estructural tiene también
re experiencia, acceder a una buena inform ación efecto en el riesgo de la estimación. En este contexto,
histórica y el coraje de confiar en predicciones (m edi la estructura se refiere al grado en el que los requisitos
das) cuantitativas cuando todo lo que existe son datos se han definido, la facilidad con la que pueden subdi-
cualitativos. La estim ación conlleva un riesgo inheren vidirse funciones, y la naturaleza jerárquica de la infor
te' y es este riesgo el que lleva a la incertidumbre. m ación que debe procesarse.
La disponibilidad de inform ación histórica tiene una
fuerte influencia en el riesgo de la estimación. Al mirar
Buenos enfoques de estimación y datos históricos atrás, podem os em ular lo que se ha trabajado y mejorar
sólidos ofrecen la mejor esperanza de que la realidad las áreas en donde surgieron problemas. Cuando se dis
puede vencer sobre los demandos imposibles. pone de las métricas completas de software de proyectos
anteriores (Capítulo 4), se pueden hacer estimaciones con
m ayor seguridad; establecer planificaciones para evitar
La complejidad delproyecto tiene un gran efecto en la dificultades anteriores, y así reducir el riesgo global.
incertidumbre, que es inherente en la planificación. Sin
embargo, la complejidad es una medida relativa que se ve
afectada por la familiaridad con esfuerzos anteriores. Se
podría considerar una aplicación sofisticada de comercio : í « f » rarocteriza a una inteligencia formada es
electrónico como «excesivamentecompleja» para un desa p e (ruede descansar satisfecha con el grado
rrollador que haya realizado su prim era aplicación. Sin de precisión que ¡a naturaleza de un asunte permite,
embargo para un equipo de software que desarrolle su y no buscar la exactitud cuando sólo una
enésimo sitio web de comercio electrónico podría consi aproximaáón de lo verdad es posible.
derarse «sumamente fácil» (una de tantas). Se han pro
puesto una seriede medidas cuantitativas de la complejidad
del software (por ejemplo, [ZU597]). Tales m edidas se El riesgo se mide por el grado de incertidumbre en las
aplican en el nivel de diseño y de codificación, y por con estimaciones cuantitativas establecidas por recursos, cos
siguiente son difíciles de utilizar durante la planificación te y planificación temporal. Si no se entiende bien el ámbi
del software (antes de que exista un diseño o un código). to del proyecto o los requisitos del proyecto están sujetos
Sin embargo, al comienzo del proceso de planificación se a cambios, la incertidumbre y el riesgo son peligrosamen
pueden establecer otras valoraciones de complejidad más te altos. El planificador del software debería solicitar defi
subjetivas (por ejemplo, los factores de ajuste de la com niciones completas de rendim iento y de interfaz (dentro
plejidad del punto de función descritos en el Capítulo 4). de una especificación del sistema). El planificador y, lo que
El tamaño delproyecto es otro factor im portante que es m ás importante, el cliente, deben tener presente que
puede afectar a la precisión y a la eficiencia de las esti cualquier cambio en los requisitos del software significa
maciones. A m edida que el tam año aumenta, crece rápi inestabilidad en el coste y en la planificación temporal.
d a m e n te ^ interdependenciaentre varios elementos del Sin embargo, un gestor de proyecto no debería obse
software. El problem a de la descomposición, un enfo sionarse con la estimación. Los enfoques m odernos de
que importante hacia la estimación, se hace más difícil ingeniería del software (por ejemplo, modelos de pro
porque los elementos descompuestos pueden ser toda cesos evolutivos) tom an un punto de vista iterativo del
vía excesivam ente grandes. P arafraseando la ley de desarrollo. En tales enfoques, es posible3 revisar la esti
Murphy: «lo que puede ir m al irá m al», y si hay más m ación (a m edida que se conoce m ás información), y
cosas que puedan fallar, más cosas fallarán. variarla cuando el cliente haga cam bios de requisitos.
1 Eli el Capítulo 6 se presentan técnicas sistem áticas para el análisis 3 Esto no significa que siem pre sea aceptable políticam ente modifi
del riesgo. car las estim aciones iniciales. Una organización de software m adura
www.FreeLibros.org
2 El tam año se incrementa con frecuenciadebidoal c am b io del ámbito» y sus gestores reconocen que el cam bio n o e s libre. Y sin em bargo
que ocurre cuando el cliente modifica los requisitos. El increm ento del m uchos clientes solicitan (incorrectam ente) que una vez realizada la
tam año del proyecto puede tener un impacto geométrico en el coste y estim ación debería m antenerse independientem ente de que las cir
en la planificación del proyecto [MAH96], cunstancias cam bien.
78
CAPÍTULO 5 P L A N I F I C A C I Ó N DE P R O Y E C T O S DE S O F T W A R E
tS',2 OBIETIVCIS PE LA P lA M lE IC A C JáH P E I PB O YEglfi»

El objetivo de la planificación del proyecto de softwa El objetivo de la planificación se logra m ediante un
re es proporcionar un m arco de trabajo que perm ita al proceso de descubrimiento de la inform ación que lleve
gestor hacer estim aciones razonables de recursos, cos a estim aciones razonables. En las secciones siguientes,
te y planificación temporal. Estas estim aciones se hacen se estudian cada una de las actividades asociadas a la
dentro de un m arco de tiem po limitado al comienzo de planificación del proyecto de software.
un proyecto de software, y deberían actualizarse regu
larmente a medida que progresa el proyecto. Además,
las estim aciones deberían definir los escenarios del
Cuanto más sepa, mejor realizaré la estimación.
«mejor caso» y «peor caso» de forma que los resulta
Por consiguiente, actualice sus estimaciones
dos del proyecto puedan limitarse. a medida que progresa el proyecto.
La primera actividad de la planificación del proyecto de tado; ambos están pensando hasta dónde podrían llegar
software es determinar el ámbito del software. Se deben (probablemente los dos tienen aquí diferentes expecta
evaluar la función y el rendim iento que se asignaron al tivas); ambos quieren quitárselo pronto de encima; pero
software durante la ingeniería del sistema de com puta al mismo tiem po quieren que salga bien.
dora (Capítulo 10), para establecer un ám bito de pro
¿Cómo debería empezar la
yecto que no sea am biguo, ni incom prensible para
directivos y técnicos. Se debe delimitar la declaración
del ámbito del software.
§ comunicación entre el
desarrollador y el cliente?
El ámbito del softw are describe el control y los
datos a procesar, la función, el rendim iento, las res Sin embargo, se debe iniciar la comunicación. Gau-
tricciones, las interfaces y la fiabilidad. Se evalúan las se y Weinberg [GAU89] sugieren que el analista comien
funciones descritas en la declaración del ám bito, y en ce haciendo preguntas de contexto libre. Es decir, una
algunos casos se refinan para dar m ás detalles antes serie de preguntas que lleven a un entendim iento bási
del comienzo de la estim ación. Dado que las estim a co del problema, las personas que están interesadas en
ciones del coste y de la planificación tem poral están la solución, la naturaleza de la solución que se desea y
orientadas a la función, m uchas veces es Útil llegar a la efectividad prevista del prim er encuentro.
un cierto grado de descom posición. Las consideracio El prim er conjunto de cuestiones de contexto libre se
nes de rendim iento abarcan los requisitos de tiem po centran en el cliente, en los objetivos globales y en los
de respuesta y de procesam iento. L as restricciones beneficios. Por ejemplo, el analista podría preguntar:
identifican los límites del software originados por el . ¿Quién está detrás de la solicitud de este trabajo?
hardware externo, por la m em oria disponible y por • ¿Quién utilizará la solución?
otros sistemas existentes. . ¿Cuál será el beneficio económico de una buena solu
ción?
5.3.1. O b ten ció n d e la in fo r m a c ió n n e c e s a r ia . ¿Hay otro cam ino para la solución?
para el ám b ito Las preguntas siguientes perm iten que el analista
Al principio de un proyecto de software las cosas siem com prenda m ejor el problem a y que el cliente exprese
pre están un poco borrosas. Se ha definido una necesi sus percepciones sobre una solución:
dad y se han enunciado las metas y objetivos básicos, . ¿C óm o caracterizaría [el cliente] un resultado
pero todavía no se ha establecido la inform ación nece «correcto» que se generaría con una solución satis
saria para definir el ámbito (prerrequisito para la esti factoria?
mación). • ¿Con qué problem a(s) se afrontará esta solución?
La técnica utilizada con más frecuencia para acercar « ¿Puede m ostrarm e (o describirme) el entorno en el
al cliente y al desarrollador, y para hacer que com ien
que se utilizará la solución?
ce el proceso de com unicación es establecer una reu
. ¿Hay aspectos o limitaciones especiales de rendimiento
nión o una entrevista preliminar. L a prim era reunión
entre un ingeniero de software (el analista) y el cliente que afecten a la form a en que se aborde la solución?
www.FreeLibros.org
puede compararse a la prim era cita entre adolescentes. La últim a serie de preguntas se centra en la efecti
Ninguna persona sabe lo que decir o preguntar; ambos vidad de la reunión. Gause y Weinberg las llaman «meta-
están preocupados por si lo que dicen es mal interpre cuestiones» y proponen la lista siguiente (abreviada):
79
« ¿Es usted la persona apropiadapara responder a estas

preguntas?¿Son «oficiales» sus respuestas? C ^ C f ta ;
• ¿Son relevantes mis preguntas para su problema? Hoy 150 km o Chicago, tenemos lleno el tanque
• ¿Estoy realizando muchas preguntas? de gasolina, medio paquete de cigarrillos, está
oscuro y llevamos gafas de sol ¡Vamos!
« ¿Hay alguien más que pueda proporcionar inform a
ffe Ibes Brothers
ción adicional?
. ¿Hay algo m ás que debiera preguntarle?
...no todo lo im aginablees factible,ni siqúiera en el softwa
Estas preguntas (y otras) ayudarán a «rom per el hie re, fugaz com o puede aparecer un forastero. P o r el contrario la
lo» y a iniciar la com unicación esencial para establecer factibilidaddel softw are tiene cuatro dim ensiones sólidas: Tec
nología— ¿Es factible un proyecto técnicam ente? ¿Está dentro
el ámbito del proyecto. Sin embargo, una reunión basa del estado actual de la técnica? Financiación— ¿Es factiblefinan-
da en preguntas y respuestas no es un enfoque que haya cieramente? ¿Puede realizarse a un coste asum ible por la empre
tenido un éxito abrumador. En realidad, la sesión P&R sa de software y por el cliente? Tiempo— ¿Pueden los proyectos
sólo se debería utilizar para el prim er encuentro, reem adelantarse a los de la com petencia? Recursos— ¿La organiza
plazándose posteriorm ente por un tipo de reunión que ción cuenta con los recursos suficientespara tener éxito?
combine elementos de resolución de problem as, nego La respuesta es sencilla para algunos proyectos en ciertas
ciación y especificación. áreas, ya que se ha hecho antes algún proyecto de este tipo. A
las pocas horas, o, a veces, en pocas sem anas de investigación,
Los clientes y los ingenieros de software con fre
se puede estar seguro que se puede hacer de nuevo.
cuencia tienen establecido inconscientemente el pen
sam iento de «nosotros y ellos». En lugar de trabajar Los proyectos de los que no se tiene experienciano son fáci
les. U n equipo puede pasarse varios m eses descubriendo cuá
com o un equipo para identificar y refinar los requisi les son los requisitos principales,y cuáles son aquéllos difíciles
tos, cada uno define su propio «territorio» y se com u de im plem entarpara una nueva aplicación. ¿Podría ocurrir que
nica por m edio de memorandos, documentos form ales alguno de estos requerim ientos presentara algunos riesgos que
de situación, sesiones de preguntas y respuestas e infor hicieran inviable el proyecto? ¿Podrían superarse estos ries
mes. La historia ha dem ostrado que este enfoque es gos? El equipo de factibilidad debe asum ir la arquitectura y el
diseño de los requerim ientos de alto riesgo hasta el punto de
muy pobre. Abundan los malentendidos, se omite infor
poder responder todas estas preguntas. E n algunos casos, cuan
m ación importante y nunca se establece una relación do el equipo proporciona respuestas negativas, esto puede nego
de trabajo con éxito. ciarse con una reducción de los requisitos.
M ientras tanto, los altos ejecutivos están repicando sus dedos
m s m u iM m im
en la m esa. A m enudo, m ueven sus cigarros d e form a elegan
Las técnicas de obtenciónde requisitos se troton te, pero de form a im paciente y rodeados de hum o exclam an
en el Capítulo 11. ¡Ya es suficiente! ¡Hazlo!
M uchos de estos proyectos que se han aprobado de esta for
m a aparecen a los pocos años en la prensa com o proyectos
Con estos problem as en m ente un grupo de investi
defectuosos.
gadores independientesha desarrolladoun enfoque orien
tado al equipo para la recopilación de requisitos que
pueden aplicarse para ayudar a establecer el ámbito de ^CONSEJÓ
un proyecto. Las técnicas denominadas técnicas para faci
El estudio de viabilidad es importante, pero los
litar las especificacionesde la aplicación (TFEA) (faci
necesidades de la gestión son inclusa más importantes.
lítale t! application specification techniques [FAST]),
No es bueno construir un producto o sistema de alta
pertenecen a un enfoque que alienta a la creación de un tecnología que en realidad nadie quiera.
equipo compuesto de clientes y de desarolladores que tra
bajen juntos para identificar el problema, proponer ele Putnam y M yers sugieren, de form a acertada, que el
mentos de solución, negociar diferentes enfoques y estudio del ám bito no es suficiente. U na vez que se ha
especificar un conjunto prelim inar de requisitos. co m p ren d id o el ám bito, tan to el eq u ip o de desarrollo
com o el resto deben trabajar para determ inar si puede
ser construido dentro de las dim ensionesreflejadas ante
5.3.2. V ia b ilid a d riorm ente. E sto es crucial, aunque es una parte del pro
Una vez se ha identificado el ámbito (con la ayuda del ceso de estim ación p asada p o r alto a m enudo.
cliente), es razonable preguntarse: «¿Podemos construir
el software de acuerdo a este ám bito? ¿Es factible el
proyecto?». Con frecuencia, las prisas de los ingenie 5.3.3. Un e jem p lo d e á m b ito
ros de software sobrepasan estas preguntas (o están obli L a com unicación con el clien te lleva a u n a definición
gados a pasarlas por los clientes o gestores impacientes), del control y de los datos procesados, de las funciones
www.FreeLibros.org
solo se tienen en cuenta en un proyecto condenado des que deben ser im p lem en tad as, del ren d im ien to y re s
de el comienzo. Putnam y Myers [PUT97a] tratan este tricciones que delim itan el sistem a, y de la inform ación
aspecto cuando escriben: relacionada. C o m o ejem plo, considerem os el softw are
80
que se debe d esarro llarp ara con tro lar un sistem a de cla • B úsqueda en la base datos.
sificación de cinta tran sp o rtad o ra (SC C T). L a especifi • D eterm inar la posición del com partim ento.
cación del ám bito del SC C T e s la siguiente: • P roducción de la señal de control para el m ecanism o
El sistema de clasificación de cinta transportadora (SC C T )
de m aniobra.
clasifica las cajas que se m ueven por una cinta transportadora.
Cada caja estará identificada por un código de barras que c o n • M antener u n a lista de los destinos de las cajas
tiene un número de pieza y se clasifica en uno de seis com parti En este caso, el rendim iento está determ inado po r la
mentos al final de la cinta. L as cajas pasarán por una estación de
v elocidad de la cinta transportadora. Se tiene que term i
clasificación que consta de un lector de código de barras y un PC.
EL PC de la estación de clasificaciónestá conectado a un m eca nar el procesam iento de cada caja antes de que llegue la
nismo de m aniobra que clasifícalas cajas en los com partim en siguiente caja al lector de código de barras. E l softw are
tos. Las cajas pasan en orden aleato rio y e stán espaciadas del SC C T está lim itado por el hardw are al que tiene que
uniformemente. L a cinta se m ueve a cinco pies por minuto. En acceder— el lector de código de barras, el m ecanism o de
la Figura 5.1 está representadoesquem áticam ente el SCCT.
m aniobra, la com putadora personal (PC)— , la m em oria
El software del SCCT debe recibir inform aciónde entrada de d isp o n ib le y la configuración global de la cin ta tra n s
un lector de código de barras a intervalos de tiem po que se ajus
portadora (cajas uniform em ente espaciadas).
ten a la velocidad de la cinta transportadora.Los datos del códi
go de barras se decodifican al form ato de identificación de caja.
El software llevará a cabo una inspección en la base de datos de ^C O N SE Icljfy.
números de piezas que contiene un m áxim o de 1000 entradas
para determinar la posición del com partim ento adecuada para la Ajuste lo estimación poro reflejar los requisitos
caja que se encuentre actualm enteen el lector (estación de clasi del rendimiento y los restricciones del diseño difíciles,
ficación). La posición correcta del com partim ento se pasará a un Incluso si el ámbito es sencillo.
mecanismo de m aniobra de ordenación que sitúa las cajas en el
lugar adecuado. Se m antendrá una lista con los com partim entos
destino de cada caja para su p osterior recuperacióne inform e. H L a función, el rendim iento y las restricciones se e v a
software del SCCT recibirá tam bién entrada de un tacóm etro de lúan a la vez. U na m ism a función puede p roducir una
pulsos que se utilizará para sincronizar la señal de control del diferencia de un orden de m agnitud en el esfuerzo de
mecanismo de m aniobra. B asándonos en el núm ero de pulsos
desarrollo cuando se considera en un contexto con d ife
que se generen entre la estación de clasificacióny el m ecanism o
rentes lím ites de rendim iento. El esfuerzo y los costes
de maniobra, el software producirá una señal de control para que
la maniobra sitúe adecuadam entela caja. req u erid o s p a ra d esarro lla r el so ftw are S C C T serían
d rásticam en te d iferen tes si la función fu era la m ism a
(por ejem plo: la cinta transportadora siguiese colocan
do cajas en contenedores), pero el rendim iento variará.
Movimiento
de la cinta transportadora r a P or ejem plo, si la velocidad m ed ia de la cin ta tran sp o r
tadora aum entara en un factor de 10 (rendim iento) y las
cajas no estuvieran uniform em ente espaciadas (una re s
tricción), el softw are po d ría ser considerablem ente m ás
HH com plejo - r e q u i r i e n d o ,p o r tanto, un m ay o r esfuerzo
H3 de d e s a r r o llo - . L a fu n ció n , el rendim iento y las re s
tricciones están íntim am ente relacionadas.
1 -0
de control L0 CLAVE
FIGURA 5.1. Un s is te m a d e c la s ific a c ió n d e cin ta Ia consideracióndel ámbito del sofaee debe cortener
tra n s p o rta d o ra . una evaluación de txlas los interfaces externas
El planificador del proyecto exam ina la especificación El softw are interactúa con otros elem entos del sis
del ámbito y extrae todas las funciones im portantes del tem a inform ático. El p lanificador considera la n a tu ra
software. Este proceso, d enom inadodescom posición, se leza y la com plejidad de cada interfaz para determ inar
trató a i el Capítulo 3 y produce com o resultado las fu n cualquier efecto sobre los recursos, los costes y la p la
dones siguientes4: nificación tem poral del desarrollo. El concepto de in ter
fa z a b a rc a lo siguiente: ( 1 ) h a rd w a re (p o r ejem plo:
• Lectura de la entrada del código de barras.
procesador, periféricos) que ejecu ta el softw are y los
• Lectura del tacóm etro de pulsos. dispositivos (por ejem plo: m áquinas, pantallas) que están
• Descodificación de los datos del código de pieza. controlados indirectam ente p o r el softw are; (2) softw a-
www.FreeLibros.org
4 En realidad, la descom posición funcional se hace durante la inge-
niena del sistema (C ap itu ló lo ). El planificador utiliza la inform ación
obtenida a partir de la especificación del sistem a para definir funcio
nes del software.
81
I N G E N IE RÍ A DEL S O F T W A R E . UN E N F O Q U E P R A C T I C O
re ya existente (por ejem plo, rutinas de acceso a una Si se ha desarrollado adecuadamente la especifica
base de datos, componentes de software reutilizables, ción del sistema (véase el Capítulo 10), casi toda la infor
sistemas operativos) que debe ser integrado con el nue m ación requerida para la descripción del ám bito del
vo software; (3) personas que hacen uso del software software estará disponible y docum entada antes de que
por m edio del teclado (terminales) u otros dispositivos comience la planificación del proyecto de software. En
de entrada/salida; (4)procedim ientos que preceden o los casos en los que no haya sido desarrollada la espe
suceden al software en una secuencia de operaciones. cificación, el planificador debe hacer el papel del ana
En cada caso, debe comprenderse claramente la infor lista de sistemas para determ inarlas características y las
m ación que se transfiere a través de la interfaz. restricciones que influirán en las tareas de estimación.
La segunda tarea de la planificación del desarrollo de

software es la estimación de los recursos requeridos para
acom eterel esfuerzo de desarrollode software. La Figu
ra 5.2 ilustra los recursos de desarrollo en forma de pirá
mide. En la base de la pirámide de recursos se encuentra
el entorno de desarrollo — herramientas de hardware y
software— que proporciona la infraestructura de sopor
te al esfuerzo de desarrollo. En un nivel m ás alto se
encuentran los com ponentes de software reutilizables
— los bloques de software que pueden reducir drástica
mente los costes de desarrollo y acelerar la entrega— .
En la parte más alta de la pirámide está el recurso pri
mario — elpersonal— . Cada recurso queda especifica
do m ediante cuatro características: descripción del
recurso, informe de disponibilidad, fecha cronológica
en la que se requiere el recurso, tiem po durante el que 5.4.2. R ecu rso s d e so ftw a r e r e u tiliz a b le s
será aplicado el recurso. Las dos últim as características La ingeniería del softw are basada en com ponentes
pueden verse como una ventana temporal. La disponi (ISBC)5 destaca la reutilización - e s t o es, la creación
bilidad del recurso para una ventana específica tiene que y la reutilización de bloques de construcción de soft
establecerse lo más pronto posible. ware [H 0 0 9 1 ]— . Dichos bloques de construcción, lla
m ados com ponentes, deben establecerse en catálogos
§
¿Cuól es la fuente de
para una consulta más fácil, estandarizarsepara una fácil
información principal para
aplicación y validarse para una fácil integración.
determinar el ámbito?
5.4.1. R ecu rso s h u m a n o s B papel que juegan las personas Implicadas

en el software y las organizaciones del equipo
El encargado de la planificación com ienza elevando el
al que pertenecen se tratan en el Capítulo 3.
ámbito y seleccionando las habilidades que se requieren
para llevar a cabo el desarrollo. Hay que especificartanto
la posición dentro de la organización (por ejemplo: gestor, Bennatan [BEN92] sugiere cuatro categorías de
ingeniero de software experimentado, etc.) como la espe recursos de software que se deberían tener en cuenta a
cialidad (por ejemplo: telecomunicaciones,bases de datos, m edida que se avanza con la planificación:
cliente/servidor). Para proyectos relativamente pequeños C om ponentes ya desarrollados. El software
(una persona-año o menos) una sola persona puede llevar existente se puede adquirir de una tercera parte o
a cabo todos los pasos de ingeniería del software, consul provenir de uno desarrollado internamente para un
tando con especialistas siempre que sea necesario. proyecto anterior. Llam ados com ponentes CCYD
El núm ero de personas requerido para un proyecto (com ponentes com ercialm ente ya desarrollados),
de software sólo puede ser determinado después de hacer estos componentes están listos para utilizarse en el
una estim ación del esfuerzo de desarrollo (por ejemplo, proyecto actual y se han validado totalmente.
personas-mes). Estas técnicas de estim ación del esfuer Com ponentes ya experim entados. Especifica
www.FreeLibros.org
zo se estudiarán después en este m ismo capítulo. ciones, diseños, código o datos de prueba existentes
5 La ingeniería del softw are b asada en com p o n en tes se tra ta con

detalle en el Capítulo 27.
82
desarrolladospara proyectos anterioresque son sim i generalmente se aceptan. El plan del proyecto debe
lares al software que se va a construir para el pro ría reflejar la utilización de estos componentes.
yecto actual. Los miembros del equipo de software 3. Si se dispone de componentes de experiencia parcial
actual ya han tenido la experiencia com pleta en el para el proyecto actual, su uso se debe analizar con
área de la aplicación representada para estos com detalle. S i antes de que se integren adecuadamente
ponentes. Las modificaciones, por tanto, requeridas los com ponentes con otros elem entos del software
para componentes de total experiencia, tendrán un se requiere una gran m odificación, proceda cuida
riesgo relativamente bajo. dosamente - e 1riesgo es alto— . El coste de m odi
ficar los componentes de experiencia parcial algunas
veces puede ser m ayor que el coste de desarrollar
* componentes nuevos.
C LA VE
Para que la reutilización sea eficiente, los componentes De form a irónica, a m enudo se descuida la u tili
de software deben estor catalogados, estondorlzodos y zación de com ponentes de softw are re u tilizab le s
validados. durante la planificación, llegando a convertirse en la
preocupación prim ordial durante la fase de desarro
llo del proceso de software. Es m ucho m ejor especi
C om ponentes con experiencia p arcial. Especi
ficar al p rin cip io las necesid ad es de recursos del
ficaciones, diseños, código o datos de prueba exis
software. De esta form a se puede dirigir la evaluación
tentes desarrollados para proyectos anteriores que
técnica de alternativas y puede tener lugar la adqui
se relacionan con el software que se va a construir
sición oportuna.
para el proyecto actual, pero que requerirán una
modificación sustancial. Los miembros del equipo
5.4.3. R e c u r s o s d e e n to r n o
de software actual han limitado su experiencia sólo
al área de aplicación representada por estos com po El entorno es donde se apoya el proyecto de software,
nentes. Las m odificaciones, por tanto, requeridas llam ado a m enudo entorno de ingeniería del software
para com ponentes de experiencia parcial tendrán (EIS), incorpora hardware y software. El hardware pro
bastante grado de riesgo. porciona una plataform a con las herram ientas (soft
C om ponentes nuevos. Los componentes de soft ware) requeridas para producir los productos que son
ware que el equipo de software debe construir espe el resultado de una buena práctica de la ingeniería del
cíficamente para las necesidades del proyecto softw are7. Com o la m ayoría de las organizaciones de
actual. software tienen m uchos aspectos que requieren acce
so a EIS, un planificador de proyecto debe determ inar
£ ¿Qué aspectos debemos la ventana tem poral requerida para el hardw are y el
* considerar cuando planificamos software, y verificar que estos recursos estarán dispo
la reutilizaciónde componentes de nibles.
software existentes? Cuando se va a desarrollar un sistema basado en com
putadora (que incorpora hardware y software especia
lizado), el equipo de software puede requerir acceso a
Deberían ser consideradas las directrices siguientes
los elementos en desarrollo por otros equipos de inge
por el planificador de software cuando los com ponen
niería. Por ejemplo, el software para un control num é
tes reutilizables se especifiquen com o recurso:
rico (CN) utilizado en una clase de máquina herram ienta
1. Si los com ponentes ya desarrollados cum plen los puede requerir una m áquina herram ienta específica (por
requisitos del proyecto, adquiéralos. El coste de la ejem plo, el CN de un torno) com o parte del paso de
adquisición y de la integración de los componentes prueba de validación; un proyecto de software para el
ya desarrollados serán casi siempre menores que el diseño de páginas avanzado puede necesitar un sistema
coste para desarrollar el software equivalente6. A de de com posición fotográfica o escritura digital en algu
más, el riesgo es relativamente bajo. na fase durante el desarrollo. Cada elem ento de hard
2. Si se dispone de componentes ya experimentados,los ware debe ser especificado por el planificad o r del
riesgos asociados a la modificación y a la integración proyecto de software.
6Cuando los com ponentes de software existentes se utilizan durante ' Otro hardw are ■
—el en t'Arnr' destino— es la coinniitadoTí> sobre la
que se va a ejecutar el softw are al entregarse al usuario final.
www.FreeLibros.org
un proyecto, la reducción del coste global puede ser im portante. En
efecto, los datos de la industria indican que el coste, el tiem po de
adquisición y el núm ero de defectos entregados al cliente se redu
cen.
83
IN GE NI E RÍ A DEL S O F TW A RE . UN E N F O Q U E P R A C T I C O
S.5 E ST ÍM A C 16K S E L PftQ Y E C T O DE SQFTWABJÉ________________________3

A l p rincipio, el coste del softw are constituía un p eq u e (por ejem plo: el clien te, las c o n d icio n es de gestión, el
ño p o rcen taje del co ste to tal de los sistem as b asados EIS [E ntorno de In g e n iería del so ftw a re ], las fechas
en co m p u ta d o ra . U n e rro r c o n sid e ra b le en las e s ti lím ite s) son sim ila re s. P o r d e sg ra c ia , la experiencia
m acio n es del co ste del so ftw a re te n ía relativ am en te an terio r no h a sido siem pre u n bu en indicador de futu
p o c o im pacto. H oy en d ía, el so ftw a re es el e le m e n ro s resultados.
to m ás c a ro de la m a y o ría d e los sistem as in fo rm á ti L as opcio n es re stan te s son m éto d o s v iab le s para la
cos. Para sistem as co m p lejo s, p ersonalizados, un gran estim ac ió n del p ro y e cto de softw are. D esde un pun
e rro r en la estim ació n del co ste p u ed e ser lo que m a r to de v ista id eal, se d eb en a p lic a r c o n ju n tam en te las
que la d ife re n c ia e n tre b en e fic io s y p érd id as. S o b re té c n ic a s in d ic a d a s; u sa n d o c a d a u n a d e e lla s como
p a s a rs e en el c o ste p u e d e se r d e s a s tro s o p a ra el co m p ro b ac ió n de las otras. L as técnicas de descom
desarro llad o r. po sició n u tiliz a n un en fo q u e de « d iv id e y vencerás))
L a estim ación del coste y del esfuerzo del softw are p a ra la estim a ció n del p ro y e cto de softw are. M edian
nunca será una cien cia exacta. Son dem asiadas las varia te la d e sc o m p o sic ió n del p ro y e c to en su s funciones
bles — hum anas, técnicas, de entorno, p o líticas— que p rin c ip ales y en las ta re as de in g en ie ría del software
pued en afectar al coste final del softw are y al esfuerzo co rresp o n d ien tes, la estim ac ió n del coste y del esfuer
aplicado p ara desarrollarlo. Sin em bargo, la estim ación zo pued e realizarse de una fo rm a e sc a lo n a d a idónea.
del p royecto de softw are puede d ejar de ser u n oscuro Se p u e d en u tiliz a r los m odelos em píricos de estima
arte p ara convertirse en una serie de pasos sistem áticos ción co m o c o m p lem en to de las técn icas de descom
que propo rcio n en estim aciones con un grado de riesgo p o s ic ió n , o fre c ie n d o un e n fo q u e de estim ación
aceptable. p o te n c ia lm e n te v a lio s o p o r d e re c h o p ro p io . Cada
m o d elo se b a sa en la e x p erien cia (datos históricos) y
to m a co m o base:
En una era de outsourcing y competencia creciente,

to capacidad para eslimar de un modo más donde d es uno de los valores estim ados (por ejem plo,
exacto se ha convertido en un factor crítico de esfuerzo, coste, duración del proyecto) y los v¡, son deter
supervivencia para muchos grupos Ti. m inados parám etros independientes (por ejem plo, LDC
o PF estim ados).
Las herramientas automáticas de estimación imple-
P ara realizar estim aciones seguras de costes y esfuer m e n tan u n a o v arias técn icas de d esco m p o sic ió n o
zos tenem os varias opciones posibles: m odelos em píricos. C uando se com binan con una inter
faz gráfica de usuario, las herram ientas autom áticas son
1. D ejar la estim ación para m ás adelante (obviam ente,
una opción atractiva para la estim ación. E n sistem as de
¡podem os re a liz a r u n a estim ació n al cien p o r cien
este tipo, se describen las características de la organi
fiable tras h ab er term inado el proyecto!).
zació n de d e sa rro llo (p o r eje m p lo , la ex p erien cia, el
2. B asar las estim aciones en proyectos sim ilares y a ter entorno) y el softw are a desarrollar. D e estos datos se
m inados. obtienen las estim aciones de coste y de esfuerzo.
3. U tilizar «técnicas de descom posición» relativam ente
sencillas p ara g enerar las estim aciones de coste y de
esfuerzo del proyecto.
4. U tilizar uno o m ás m odelos em píricos p ara la esti
m ació n del coste y esfuerzo del softw are.
D esgraciadam ente, la prim era opción, aunque atrac Herramientas CASE.
tiva, no es práctica. L as estim aciones de costes han de

ser p ro porcionadas a priori. Sin em bargo, hay que re co C ada una de las opciones viables para la estim ación
n o c e r que c u a n to m ás tie m p o e sp e re m o s, m á s co sas de costes del softw are, sólo será buena si los datos his
sab rem o s, y cu an to m ás sep am o s, m en o r será la p ro tóricos que se utilizan com o base de la estim ación son
b a b ilid a d de c o m eter serio s erro res en n u e stra s e s ti buenos. Si no existen datos históricos, la estim ación del
m aciones. coste d esc an sará sobre una base m uy inestable. E n el
L a segunda o pción puede funcio n ar razonablem ente C apítulo 4 exam inam os las características de los datos
b ie n , si el p ro y e c to a c tu a l es b a sta n te sim ila r a los de productividad del softw are y cóm o pueden utilizar
www.FreeLibros.org
e sfu erzo s p asad o s y si o tras in flu en cias del p ro y ecto se com o base histórica para la estim ación.
a4
CAPÍTULO 5 P L A N I F I C A C I Ó N DE PR O Y EC T O S DE S O F T W A R E
La estimación de proyectos de software es una form a Tamaño en «lógica difusa». Este enfoque utiliza
eferesolución de problemas y, en la m ayoría de los casos, las técnicas aproximadas de razonam iento que son
el problema a resolver (es decir, desarrollar estim acio la piedra angular de la lógica difusa. Para aplicar este
nes de coste y de esfuerzo para un proyecto de softwa enfoque, el planificador debe identificar el tipo de
re) es demasiado complejo para considerarlo como un aplicación, establecer su m agnitud en u na escala
todo. Por esta razón, descomponemos el problema, vol cuantitativa y refinar la m agnitud dentro del rango
viéndolo a definir como un conjunto de pequeños pro original. Aunque se puede utilizar la experiencia per
blemas (esperando que sean m ás manejables). sonal, el planificador tam bién debería tener acceso
En el Capítulo 3, se estudió el enfoque de descom a una base de datos histórica de proyectos8 para que
posición desde dos puntos de vista diferentes: descom las estim aciones se puedan com parar con la ex p e
posición del problem a y descomposición del proceso. riencia real.
La estimación hace uso de una o ambas formas de par- Tam año en punto de función. El planificador
ticionamiento. Pero antes de hacer una estim ación, el desarrolla estim aciones de características del dom i
planificador del proyecto debe com prender el ám bito nio de inform ación estudiadas en el Capítulo 4.
del software a construir y generar una estim ación de su
«tamaño». ¿Cómo medimos el
w software que estamos
5.6.1. T am año d e l s o ftw a re planeando construir?
La precisión de una estim ación del proyecto de soft-
wate se predice basándose en una serie de cosas: (1) el Tamaño de com ponentes estándar. El software
grado en el que el planificador ha estimado adecuada se compone de un núm ero de «componentes están
mente el tamaño del producto a construir; (2) la habili dar» que son genéricos para un área en particular de
dad para traducir la estim ación del tam año en esfuerzo la aplicación. Por ejemplo, los componentes están
humano, tiempo y dinero (una función de la disponibi dar para un sistema de información son: subsistemas,
lidad de métricas fiables de software de proyectos ante m ódulos, pantallas, informes, program as interacti
riores); (3) el grado en el que el plan del proyecto refleja vos, program as por lotes, archivos, LDC e instruc
las habilidades del equipo de software, y (4)l a estabi ciones para objetos. El planificador de proyectos
lidad de los requisitos del softw are y el entorno que estim a el núm ero de incidencias de cada uno de los
soporta el esfuerzo de la ingeniería del software. componentes estándar, y utiliza datos de proyectos
históricos para determ inar el tam año de entrega por
componente estándar. Para ilustrarlo, considere una
aplicación de sistemas de información. El planifica
CLAVE dor estim a que se generarán 18 informes. Los datos
B «tamaño» del software o tonstrulr puede estimarse históricos indican que por informe se requieren 967
utilizando una medida dlretto, LDC, o uno medido líneas de Cobol [PUT92 J. Esto permite que el plani
indirecto, FF. ficador estime que se requieren 17.000 LDC para el
com ponente de informes. Para otros com ponentes
En esta sección, consideram os el problema del tama- estándar se hacen estim aciones y cálculos similares,
ñodel software. Puesto que una estim ación del proyec y se producen resultados combinados de valores de
to es tan buena com o la estim ación del tam año del tam años (ajustados estadísticamente).
trabajo que va a llevarse a cabo, el tam año representa Tam año del cam bio. Este enfoque se utiliza
el primer reto im portante del planificador de proyectos. cuando un proyecto comprende la utilización de soft
En el contexto de la planificación de proyectos, el tam a w are existente que se debe m odificar de alguna
ño se refiere a una producción cuantificable del proyecto m anera com o parte de un proyecto. El planificador
dfe software. Si se tom a un enfoque directo, el tamaño estim a el núm ero y tipo (por ejemplo: reutilización,
se puede medir en LDC. Si se selecciona un enfoque añadir código, cambiar código, suprimir código) de
indirecto, el tam año se representa como PF. m odificacionesque se deben llevar a cabo. M ediante
Putnam y M yers [PUT92] sugieren cuatro enfoques una «proporción de esfuerzo» [PUT92] para cada tipo
diferentes del problem a del tamaño: de cambio, se puede estim ar el tam año del cambio.
www.FreeLibros.org
8 Consulte la Sección 5.9 que trata brevem ente las herram ientas de
estimación que utilizan una base de datos histórica y otras técnicas
de tam año estudiadas en esta sección.
85
I N GE NI E RÍ A DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
Putnam y Myers sugieren que los resultados de cada do sospechar que se utilice únicam ente una métrica de
uno de los métodos de tam año señalados anteriormente productividad de línea base. En general, el dominio del
se combinan estadísticamente para crear una estimación proyecto debería calcularlas medias de LDC/pm o PF/pm.
de tres puntos o del valor esperado. Esto se lleva a cabo Es decir, los proyectos se deberían agrupar por tamaño
desarrollandovalores de tamaño optimistas (bajos),y más de equipo, área de aplicación, com plejidad y otros para-
probables, y pesimistas (altos), y se com binan utilizando m etros relevantes. Entonces se deberían calcular las
la Ecuación (5.1) que se describe en la sección siguiente. medias del dominio local. Cuando se estima un proyec
to nuevo, prim ero se debería asignar a un dominio, y a
continuación utilizar la m edia del dominio adecuado para
5.6.2. E stim a c ió n b a s a d a e n e l p r o b le m a
la productividad al generar la estimación. Las técnicas
En el Capítulo 4, las líneas de código (LDC) y los pun de estim ación de LDC y PF difieren en el nivel de deta
tos de función (PF) se describieron como m edidas bási lle que se requiere para la descomposición y el objetivo
cas a partir de las que se pueden calcular métricas de de la partición. Cuando se utiliza LDC como variable de
productividad. Los datos de LD C y PF se utilizan de dos estimación, la descom posición”'es absolutamenteesen-
formas durante la estim ación del proyecto de software: cial y con frecuencia se toman para considerables nive
(1) como una variable de estim ación que se utiliza para les de detalle. El enfoque de descomposición siguiente
«dimensionar» cada elem ento del software, y (2) como ha sido adaptado por Phillips [PHI98]11:
métricas de línea base recopiladas de proyectos anterio
res y utilizadas junto con variables de estim ación para
desarrollar proyecciones de coste y de esfuerzo. CLAVE
Las estim aciones de LD C y P F son técnicas de esti
Poro.Estimaciones de LDC, la descomposición
m ación distintas. A pesar de que am bas tienen varias
se centroen las funciones del software.
características en común. El planificador del proyecto
com ienza con un enfoque lim itado para el ámbito del definir el ám bito del producto;
software y desde este estado intenta descom poner el identificar funciones descom poniendo el ámbito;
software en funciones que se pueden estim ar indivi hacer m ientras haya funciones
seleccionar una funciói^
dualmente. Para cada función entonces se estim an las
asignar todas las funciones a la lista de subfunciones;
LDC y el PF (la variable de estimación). De fonna alter
hacer m ientras haya subfunciones
nativa, el planificador puede seleccionar otro compo seleccionar una subfunciónk
nente para dim ensionar clases u objetos, cam bios o si subfunciónk = subfunciónd descrita en una base
procesos de gestión en los que puede tener impacto. de datos histórica
entonces a n o tar datos histó rico s del coste,
¿jjjt ¿Qué tienen en común la esfuerzo, tam año, (L D C o P F ) para
la subfunciónd ;
• estimación orientada a PF
aju star datos histó rico s del coste,
y a LDC? esfuerzo, tam año basados e n cual
quier diferencia:
Las m étricas de productividad de línea base (por use datos del coste, esfuerzo, tama
ejemplo: LDC/pm o PF/pnf') se aplican entonces para ñ o ajustados para o b ten er una esti
la variable de estim ación adecuada y se extrae el coste m ación parcial, E;
o el esfuerzo de la función. Las estim aciones de fun e stim a c ió n p ro y e cto = su m a de
ción se com binan para producir una estim ación global i e p I; '
sino si se puede estim ar coste, estuerzo,
del proyecto entero. tam año (LDC o PF) para subfunciónk
entonces obtener estim ación parcial,
e stim a c ió n p ro y e cto = su m a de
Cuando se comparan métricas de productividadpara
( E, 1; ’
proyectos, esté seguro de establecer una clasificación sino subdividir subfunciónk en sub
de los tipos de proyectos. Esb le permitirá calcular funciones m ás pequeñas;
promedios para dominios específicos y la estimación añadirlas a la lista de subfunciones;
será más exacta. íin si
íin si
Es importante señalar, sin embargo, que hay una sus fin hacer
tancial diversidad en métricas de productividad, hacien fin hacer
q El acrónim o pm hace referencia a perso n as-m es 10 En general se descomponen las funciones del problema. Sin embargo.
se puede utilizar una lista de com ponentesestándar (Sección5.6.1).
www.FreeLibros.org
11 El lenguaje informal de diseño del proceso señalado aquí se expone
para ilustrar el enfoque general para el dim ensionam iento. No tiene
en cuenta ninguna eventualidad lógica.
86
El enfoque de descomposición visto anteriormente asu 5.6.3. U n e je m p lo d e e s t i m a c i ó n b a s a d a e n IJDC

me que todas las funciones pueden descomponerse en sub- Com o ejemplo de técnicas de estim ación de LDC y PF,
funciones que podrán asemejarse a entradas de una base tom em os en consideración un paquete de softw are a
de datos histórica. Si este no es el caso, deberá aplicarse desarrollarse para una aplicación de diseño asistido por
otro enfoque de dimensionamiento. Cuanto más grande com putadora (computer-aided design, CAD) de com
sea el grado de particionamiento, más probable será que ponentes mecánicos. Una revisión de la especificación
pueda desarrollar estimaciones de LDC más exactas. del sistema indica que el software va a ejecutarse en una
Para estim aciones de PF, la descomposición funcio estación de trabajo de ingeniería y que debe interconec-
na de diferente manera. En lugar de centrarse en la fun tarse con varios periféricos de gráficos de computadora
ción, se estim an cada una de las características del entre los que se incluyen un ratón, un digitalizador, una
dominio de inform ación — entradas, salidas, archivos pantalla a color de alta resolucióny una impresora láser.
de datos, peticiones, e interfaces extemas — y los cator Utilizando como guía una especificación de sistema,
ce valores de ajuste de la com plejidad estudiados en el se puede desarrollar una descripción prelim inar del
Capítulo 4 .Las estim aciones resultantes se pueden uti ámbito del software:
lizar para derivar un valor de PF que se pueda unir a
E l softw are de C A D aceptará datos g eo m étrico s de dos y
datos pasados y utilizar para generar una estimación. tres dim ensiones por parte del ingeniero. El ingeniero se inter-
conectará y co n tro lará el sistem a de C A D por m edio de una
interfaz de u suario que va a e x h ib ir las c aracterísticas de un
buen diseño d e interfaz hom bre-m áquina. U na base de datos
CLAVE de C A D con tien e to d o s lo s datos g eo m étrico s y la inform a
Para estimaciones de PF, la descomposición se centra en ción d e soporte. Se desarrollarán m ódulos de análisis de d ise
las característicasdel dominio de información. ño para producir la salida requerida que se va a v isu a liz ar en
varios d ispositivos gráficos. El softw are se diseñará para con
trolar e in te rco n e c ta r d isp o sitiv o s p eriférico s entre lo s que
Con independencia de la variable de estim ación que se incluyen un ratón, un digitalizador, una im p reso ra láser y
se utilice, el planificador del proyecto com ienza por un traz ad o r gráfico (p lo tter).
estimar un rango de valores para cada función o valor La descripción anterior del ám bito es prelim inar
del dominio de información. M ediante los datos histó —no está limitada— . Para proporcionar detalles co n
ricos o (cuando todo lo demás falla) la intuición, el pla cretos y un límite cuantitativo se tendrían que am pliar
nificador estim a un valor de tam año optim ista, más todas las descripciones. Por ejem plo, antes de que la
probable y pesim ista para cada función, o cuenta para estim ació n pueda com enzar, el p lan ifica d o r debe
cada valor del dominio de información. Al especificar determ inar q u é significa «características de un buen
un rango de valores, se proporciona una indicación diseño de interfaz hom bre-m áquina» y cuál será el
implícita del grado de incertidumbre. tam año y la so fisticac ió n de la «base de datos de
CAD».
¿Cómo calcular el valor Para estos propósitos, se asume que ha habido m ás
§ esperado para el tamaño del

softw are?
refinam iento y que se identifican las funciones de soft
ware siguientes:
. interfaz de usuario y facilidades de control (IUFC),
Entonces se calcula un valor de tres puntos o espe
rado. El valor esperado de la variable de estim ación < análisis geométrico de dos dim ensiones (AG2D),
(tamaño), VE, se puede calcular com o una m edia pon • análisis geométrico de tres dim ensiones (AG3D),
derada de las estim aciones optim istas (S t), las más « gestión de base de datos (GBD),
probables (Sm), y las pesim istas (S ). Por ejemplo, • facilidades de presentación gráfica de com putadora
VE = (Sopt,+ 4Sm + SpeJ / 6 (5.1) (FPGC),
da crédito a la estim ación «más probable» y sigue una • control de periféricos (CP),
distribución de probabilidad beta. Se asume que existe • m ódulos de análisis del diseño (MAD).
una probabilidad muy pequeña en donde el resultado
del tamaño real quedará fuera de los valores pesimistas
y optimistas. Muchas oplicaciones modernos residen en uno red o son
Una vez que se ha determ inado el valor esperado de porte de uno arquitectura cliente/servidor. Por
la variable de estimación, se aplican datos históricos de consiguiente, esté seguro que sus estimaciones contienen
productividad de LDC y PF. ¿Son correctas las estim a el esfuerzorequerido pora el desarrollo del software de la
ciones? La única respuesta razonable a esto es: «No «infraestructura».

podemos estar seguros». Cualquier técnica de estim a
www.FreeLibros.org
ción, no importa lo sofisticada que sea, se debe volver Siguiendo la técnica de descomposición de LDC, se
a comprobar con otro enfoque. Incluso entonces, va a desarrolla la tabla de estim ación m ostrada en la Figura
prevalecer el sentido com ún y la experiencia. 5.3. Se desarrollaun rango de estim aciones de LDC para
a7
IN GE NI ER ÍA DEL S O F TW A R E . UN E N F O Q U E P R Á C T I C O
ca d a función. P o r ejem p lo , el ran g o de estim acio n es

de L D C de la fu n c ió n del an álisis g eo m étrico de tres
d im en sio n es es: o p tim ista -4.600 LD C — ; m ás p ro
Referencia W e b Í^
bable — 6.900— , y p e sim ista — 8.600 LD C — . A p li
cando la E cuación (5.1), el v alo r esperado de la función Se puede obtener información sobre las herramientas de
del análisis g eo m étrico es 6 .8 0 0 L D C . E ste núm ero se estimación del coste mediante PF en www.spr.com
introduce en la tabla. D e form a sim ilar se d erivan otras
estim a c io n e s. S u m an d o en v e rtic a l la c o lu m n a e s ti Valor de dominio Opt. Probable Pes. Cuenta Peso Cuenta PF
m ada de L D C , se estab lece u n a estim ació n de 33.200 de información est.
líneas de có d ig o p ara el sistem a de CA D . Númerode entradas 20 24 30 24 4 97
Númerode salidas 12 15 22 16 5 78
Número de peticiones 16 22 28 22 5 88
Número de archivos 4 4 5 4 10 42
^D O N S E ld J fy Número de Interfaces
externas 2 2 3 2 7 15
No sucumba o lo tentación de utilizar este resultado como Cuenta total 320
estimación. Debería obtener otro estimación utilizando
un método diferente. F IG U R A 5 .4 . Estim ación de los valores del dom inio
de información.
U na rev isió n de datos históricos in d ica que la p ro
ductiv id ad m ed ia de la o rganización p ara sistem as de C om o se describ e en el C ap ítu lo 4, se estim a cada
este tipo es de 620 L D C /pm . Según u n a tarifa laboral uno de los factores de ponderación de la com plejidad,
de E8.000 p o r m es, el coste p o r línea de código es apro y se calcula el factor de ajuste de la com plejidad:
xim adam ente de £13,00. Según la estim ación de LD C
y los d ato s de produ ctiv id ad h istó rico s, el coste total Factor Valor
estim ado del proyecto es de £431.000 y el esfuerzo esti C opia de seguridad y recuperación 4
m ado es de 54 p erso n as-m es12. C om unicaciones de datos 2
P roceso distribuido 0
R endim iento crítico 4
E ntorno operativo existente 3
Función LDC estimada
E ntrada de datos en línea (on-line) 4
Interface del usuario y facilidades de control (IUFC) 2.300 T ransacciones de entrada en m últiples
Análisis geométrico de dos dimensiones (AG2D) 5.300 pantallas 5
Análisis geométrico de tres dimensiones (A32D) 6.800
3.350
A rchivos m aestros actualizados en línea
Gestión de base de datos (GBD)
Facilidadesde presentación gráfica (on-line) 3
de computadora (FPGC) 4.950 C om plejidad de valores del dom inio
Control de periféricos (CP) 2.100
de inform ación 5
Módulos de análisis del diseño (MAD) 8.400
C om plejidad del procesam iento interno 5
Líneas de códigos estimadas 33.200 4
C ódigo diseñado para la reutilización
C onversión/instalación en diseño 3
F IG U R A 5 .3 . Tabla de estim ación para el m étodo de LDC. Instalaciones m últiples 5
A plicación diseñada para el cam bio 5
F actor de ajuste de la com plejidad 1,17
5.6.4. U n e jem p lo d e e stim a c ió n b a s a d a e n PF Finalm ente, se obtiene el núm ero estim ad o de PF:
L a descom posición de estim ación b asad a en PF se cen
P F estim ad o = c u e n t a t o t a l X l 0 ' 6 5 + 0 , 0 1 X Z ( L )]
tra en los v alores de dom inio de inform ación, y no en
las funciones del softw are. T eniendo en cuen ta la tabla P F estim ad o — ^ 7 5
de cálculos de p unto de función p resen tad a en la F ig u L a productividad m edia organizacionalpara sistem as

ra 5.4, el p lan ificad o r del p royecto estim a las entradas, de este tipo es de 6,5 PF/pm . Según la tarifa laboral de
salid as, p e tic io n e s, arch iv o s e in terfaces ex tern as del E 8 .0 0 0 p o r m es, el coste p o r PF es aproxim adam ente de
softw are de C A D . P ara los p ropósitos de esta estim a E1.230. Según la estim ación de L D C y los datos de pro
ción, el facto r de pond eració n de la com plejidad se asu ductividad históricos, el coste total estim ado del proyecto
m e com o la m edia. L a Figura 5.4 presenta los resultados es de £461.000, y el esfuerzo estim ado es de 58 perso
de e sta estim ación. nas/m es.
www.FreeLibros.org
12 La estim ación se redondea acercándose lo m ás posible a E l . 000 y
persona-m es.
88
5.6.5. E stim a ció n b a s a d a e n e l p ro ceso ra ten d rem o s do s o tres e stim a c io n e s del co ste y del
esfu erzo que se pueden com parar y evaluar. S i am bos
La técnica m ás com ún p ara estim ar un p royecto es basar
tipos de estim aciones m uestran una concordancia raz o
la estim ación en el proceso que se v a a utilizar. Es decir,
nable, hay u n a b u ena razón para cree r que las estim a
el proceso se descom pone en un conjunto relativam en
ciones son fiables. Si, p o r otro lado, los resu ltad o s de
te pequeño de a c tiv id a d e s o tareas, y en el e sfu e rz o
estas técnicas de descom posición m uestran p o ca c o n
requerido p ara llevar a cabo la estim ació n de cada tarea.
cordancia, se debe realizar m ás investigación y análisis.
Al igual que las técnicas b asadas en p ro b lem as, la
estimación b asad a en el proceso com ien za con un esb o
zo de las funciones del softw are obtenidas a p artir del 5.6.6. U n e jem p lo d e e s tim a c ió n b a s a d a
ámbito del proyecto. P ara cada función se debe llevar e n e l p ro ceso
a cabo una serie de actividades del p roceso de softw a P ara ilustrar el uso de la estim ación b asada en el p ro
re. Las funciones y las actividades del p roceso de soft ceso, de nuevo considerem os el softw are de C A D pre-
ware relacionadas se pueden rep resen tar com o parte de sen tad o en la Sección 5.6.3. L a configuración del sistem a
una tabla sim ilar a la p resen tad a en la F igura 3.2. y todas las funciones del softw are perm anecen iguales
y están indicadas en el ám bito del proyecto.
t s n a m
Emarco de trabajo común del proceso (MCP)
se estudio en el Capítulo 2.
Si e l tiempo lo permite, realice uno m a y a
U na v ez que se m ezclan las fu n cio n es del p ro b le descomposición ol especificar /as tareas; en la Figura 5.5,
ma y las actividades del p ro ceso , el p la n ifica d o r e sti p .% se divide e l análisis en sus tareas principales y se
ma el esfu erzo (p o r eje m p lo : p e rs o n a s -m e s) que se estima coda una p a separado.
requerirá p ara llev ar a cab o cad a u n a de las a c tiv id a

des del p ro ceso de so ftw a re en c a d a fu n c ió n . E sto s En la tab la de estim ación de esfu erzo s y a term in a
datos co n stitu y en la m a triz c e n tra l de la ta b la de la da, que se m u estra en la F ig u ra 5.5 aparecen las e sti
Figura 3.2. L os ín d ices de tra b a jo m e d io s (es decir, m a c io n e s de e sfu e rz o (en p e rso n a s-m e s) p a ra cad a
esfuerzo co ste/unidad) se ap lican en to n ces al e sfu e r actividad de ingeniería del softw are proporcionada para
zo estim ado a cada actividad del proceso. E s m uy p ro cad a fu n c ió n del so ftw a re de C A D (a b re v ia d a para
bable que en ca d a ta re a varíe el ín d ice de trabajo. El m ay o r rapidez). Las actividadesde ingeniería y de cons-
personal v e teran o se in v o lu c ra de lle n o con las p ri trucciónlentrega se subdividen en las tareas prin cip a
meras actividades y g en eralm en te es m u ch o m ás caro les de in g e n ie ría del softw are m ostradas. L as estim a
que el p ersonal ju n io r, q u ien es están re la c io n ad o s con cio n es in ic iales del esfu erzo se p ro p o rcio n an para la
las tareas de d iseñ o p o sterio res, con la g en eració n del com unicación con el cliente,planificación y análisis de
código y con las p ruebas in iciales. riesgos. E stos se señalan en la fila Total en la parte infe
rio r de la tabla. L os totales horizontales y verticales pro
porcionan una indicación del esfu erzo estim ad o que se
Actividad A n á lis is C onstrucción requiere para el análisis, diseño, codificación y pruebas.
QC P lanificación ln g en ieria
e n treg a
EC T o ta le s
W de riesgo Se debería señalar que el 53 p o r 100 de todo el esfuer
Ta r e a - > A ná lis is D is e ñ o C ó d ig o P rueba
zo se aplica en las tareas de ingeniería « frontales» (aná
Función lisis y diseño de los requisitos) indicando la im portancia
y relativa de este trabajo.
IUFC 0 .5 0 2 .5 0 0 .4 0 5.00 n/a 8 .4 0
AG2D 0 .7 5 4 ,0 0 0 .6 0 2 .0 0 n/a 7 .3 5 B asado en una tarifa laboral de £5.000 p o r m es, el
A G 3D 0 .5 0 4.00 1.00 3 .0 0 n/a 8 .5 0 coste total estim ad o del proyecto es de £2 3 0 .0 0 0 y el
FPGC 0 ,5 0 3 .0 0 1,00 1.50 n/a 6 .0 0
GBD 0 .5 0 3 .0 0 0 ,7 5 1.50 n/a 5.75 esfu erzo estim ad o es de 46 personas/m es. A cad a acti
CP 0 .2 5 2 .0 0 0 .5 0 1.50 n/a 4.25 vidad de proceso del softw are o tareas de ingeniería del
M AD 0 .5 0 2 .0 0 0 .5 0 2 .00 n/a 5.00
softw are se le po d ría asociar diferentes índices de tra
bajo y calcularlos p o r separado.
Totales 10.251 0 .2 5 0.25 3 .5 0 120.50 4 .7 5 16.50 4 6 .0 0 El esfu erzo total estim ad o para el softw are de C A D
% Esfuerzo 1% 1% 1% 8% 4 5% 10% 3 6% oscila de un índice bajo de 46 personas-m es (obtenido
C C = C o m u n icació n cliente EC = E va lu a c ió n cliente m ediante un enfo q u e de estim ación basado en el p ro
ceso) a un alto de 58 personas-m es (obtenido m ed ian
FIGURA 5.5. Tabla de estimación basada en el proceso. te un enfoque de estim ación de PF). La estim ación m edia
(u tilizan d o los tres enfo q u es) es de 5 3 perso n as-m es.
Como últim o paso se calculan los costes y el esfuer L a variación m áxim a de la estim ación m ed ia es apro
www.FreeLibros.org
zo de cada función, y la actividad del p roceso de soft xim adam ente del 13 p o r ciento.
ware. Si la estim ación b asad a en el p roceso se realiza ¿Q ué ocurre cu an d o la concordancia entre las esti
independientem entede la estim ación de L D C o PF, aho m aciones es m ala? P ara responder a esta p regunta se ha
89
I N G E N IE RÍ A DEL S O F TW A RE . UN EN F O Q U E P R A C T I C O
de reevaluar la inform ación que se ha utilizado para 1. No se entiende adecuadam ente el ám bito del pro
hacer las estimaciones. yecto o el planificador lo ha mal interpretado.
Muchas divergencias entre estim aciones se deben a
2. Los datos de productividad usados para técnicas de
una de dos causas:
estim ación basados en problem as no son apropiados
para la aplicación, están obsoletos (ya no reflejan con
precisión la organización de la ingeniería del soft
No espere que todos los estimaciones coincidan ware), o se han aplicado erróneamente.
en uno o dos porcentajes. S ilo estimación está
den tro de uno bando del 20 por 100, puede El planificador debe determ inar la causa de la diver
reconciliarse en un único valor. gencia y conciliar las estimaciones.
Un modelo de estimación para el software de com puta señalada en la Ecuación (5.2) la m ayoría de los mode
dora utiliza fórmulas derivadas em píricam entepara pre los de estim ación tienen algún componente de ajuste del
decir el esfuerzo como una función de LDC o PF. Los proyecto que permite ajustar E por otras características
valores para LDC o PF son estimados utilizando el enfo del proyecto (por ejem plo: com plejidad del problema,
que descrito en las Secciones 5.6.2 y 5.6.3. Pero en lugar experiencia del personal, entorno de desarrollo). Entre
de utilizar las tablas descritas en esas secciones, los valo los m uchos m odelos de estim ación orientados a LDC
res resultantes para LDC o PF se unen al modelo de esti propuestos en la bibliografía se encuentran los siguien
mación. Los datos empíricos que soportan la m ayoría tes:
de los modelos de estim ación se obtienen de una m ues E = 5,2 x ( K L D C ) 0'91 M odelo de W alston-Felix
tra lim itada de proyectos. Por esta razón, el m odelo de E = 5 ,5 + 0,73 x
estim ación no es adecuado para todas las clases de soft ( K L D C ) 1 16 M odelo de B ailey-B asili
ware y en todos los entornos de desarrollo. Por consi E = 3,2 x (K L D C )' 05 M odelo sim ple de B oehm
guiente, dos resultados obtenidos de dichos modelos se E = 5,288 x ( K L D C ) 1047 M odelo D oty para K L D C > 9
deben utilizar con prudencia13.
También se han propuesto los modelos orientados a
PF. Entre estos modelos se incluyen:
5.7.1. L a e s tr u c tu r a d e lo s m o d e lo s d e e s tim a c ió n
E = -1 3 ,3 9 + 0 ,0 5 4 5 P F M odelo de A lbretch
y G affney
E = 6 0 ,6 2 x 7,7 2 8 x
CLAVE x 10” P F 7 M odelo de K em erer
E = 5 8 5 ,7 + 15,12 PF M odelo de M atson, B am ett
Unmodelo de estimaciónrefleja locantidadde proyectos
y M ellicham p
a partir de dondese ha obtenido. Por consiguiente,
el modelo es susceptibleal dominio. Un rápido examen de los modelos listados anterior
mente indica que cada uno producirá un resultado dife
Un m odelo com ún de estim ación se extrae utilizando el rente'4 para el m ism o valor de LDC y PF. La implicación
análisis de regresión sobre los datos recopilados de pro es clara. Los modelos de estim ación se deben calibrar
yectos de software anteriores. La estructura global de para necesidades locales.
tales modelos adquiere la forma de [MAT94]:
E =A + B x ( e v f (5.2) ^B O W S R IO ^.
donde A , B y C son constantes obtenidas em píricam en Ninguno de estos modelos debería ser aplicado
te, E es el esfuerzo en personas-mes, y ev es la variable inodecuodomente o su entorno.
de estim ación (de LDC o P F ). Además de la relación
13 En general se debería calibrar un m odelo de estim ación para las 14 Esta referencia se fundam enta en que estos m odelos a m enudo se
condiciones locales. El m odelóse debería ejecutar utilizando los resul derivan de un núm ero relativam ente pequeño de proyectos só lo en
tados de proyectos term inados. Los datos previstos por el m odelo se unos cuantos dom inios de la aplicación.
www.FreeLibros.org
deberían com parar con los resultados reales, y la eficacia del modelo
(para condiciones locales) debería ser evaluada. Si la concordancia
no es buena, los coeficientes del m odelo se deben volver a calcular
utilizando datos locales.
90
CAPÍTULO 5 P L A N I F I C A C I O N DE P R O Y E C T O S DE S OF TW AR E
5.7.2. a m o d e lo C O C O M O un a p a n ta lla o in form e) se clasifica en uno de los tres

Barry Boehm [BOE81], en su libro clásico sobre «eco niveles de com plejidad (esto es, básico, interm edio, o
nomía de la ingeniería del software»,introduce unajerar- avanzado) utilizando los criterios sugeridos p o r B oehm
quía de m odelos de estim ación de softw are con el [BO E96]. En esencia, la com plejidad es una función del
nombie de COCOM O, por C onstructive C ost M odel núm ero y origen de las tablas de datos del cliente y ser
(Modelo Constructivo de Coste). El m odelo COCOM O vid o r necesario para g en erar la p an talla o el inform e y
original se ha convertido en uno de los modelos de esti el núm ero de vistas o secciones presentadas co m o p ar
mación de coste del software m ás utilizados y estudia te de la p antalla o del inform e.
dos en la industria. El m odelo original ha evolucionado
a un modelo de estim ación m ás com pleto llam ado P e so de la Complejidad
Tipo de objeto
COCOMO II [BOE 96, BOE 00], Al igual que su pre Básico Intermedio Avanzado
decesor, COCOM O 11 es en realidad una jerarquía de
Pantalla 1 2 3
modelos de estim ación que tratan las áreas siguientes :
Modelo de composición de aplicación.Utilizado
informe 2 5 a
durante las prim eras etapas de la ingeniería del soft Componente L3G 10
ware, donde el prototipado de las interfaces de usua
rio, la interacción del sistem a y del softw are, la T A B L A 5 .1 . Factores de peso de la com plejidad para tipos
evaluación del rendim iento, y la evaluación de la de objeto [BOE96].
madurez de la tecnología son de suma importancia. U n a vez que se h a d eterm in ad o la com p lejid ad , se
Modelo de fase de diseño previo. Utilizado una valo ra el núm ero de pantallas, inform es, y co m p o n en
vez que se han estabilizado los requisitos y que se tes de acuerdo con la Tabla 5.1. L a cuenta de punto ob je
ha establecido la arquitectura básica del software. to se d e te rm in a m u ltip lic an d o el n ú m ero o rig in a l de
Modelo de fase posterior a la arquitectura.Uti- instancias del objeto p o r el factor de peso de la tab la 5.1
lizado durante la construcción del software. y se sum an para obtener la cuenta total de punto ob je
Al igual que todos los m odelos de estim ación del to. C uando se va a aplicar el desarrollo basado en c o m
software, el m odelo COCOM O II descrito antes nece ponentes o la reutilización de softw are en g eneral, se
sita información del tamaño. Dentro de la'jerarquía del estim a el porcentaje de reutilización (% reutilización) y
modelo hay tres opciones de tam año distintas: puntos se ajusta la cuenta del punto objeto:
objeto, puntos de función, y líneas de código fuente. P O N = (puntos objeto) x [(100 - % reutilización)/100]
El modelo de com posición de aplicación COCOM O donde PO N significa «puntos objeto nuevos».
II utiliza los puntos objeto como se ilustra en los párrafos
siguientes. Debería señalarse que también están disponi
:Qué es un «punto objeto))?
bles otros modelos de estimación más sofisticados (utili
zando PF y KLDC) que forman parte del COCOM O II.
Para obtener una estim ación del esfuerzo b asada en el
valor PO N calculado, se debe calcular la «proporción de
productividad». La Tabla 5.2 presenta la proporción de
Referencia productividad para los diferentes niveles de experiencia
del desarrolladory de m adurez del entorno de desarrollo.
Se puede obtener información detallada sobre el
U na vez determ inada la proporción de productividad, se
COCOMO II, incluyendo software que puede descargar, en
puede obtener una estim ación del esfuerzo del proyecto:
sunset.iisc.edu/COCOMOII/cocomo.html
E sfuerzo estim ad o = PO N / PR O D
Del m ismo modo que los puntos de función (Capí E n m o d e lo s C O C O M O II m á s a v a n z a d o s” , se
tulo 4), el punto objeto es una m edida indirecta de soft requiere u n a variedad de factores de escala, co n d u c to
ware que se calcula utilizando el total de (1) pantallas res de coste y procedim ientos de ajuste. U n estudio co m
(de la interface de usuario), (2) informes, y (3) com po pleto de estos tem as están fuera del ám bito de este libro.
nentes que probablem ente se necesiten para construir E l lector interesado debería consultar [BOEOO] o v isi
la aplicación. C ada instancia de objeto (por ejem plo, tar el sitio w eb C O C O M O II.
www.FreeLibros.org
15 Como se señaló anteriorm ente, estos m odelos hacen uso de las
cuen tas de PF y KLDC para la variable tam año.
91
IN GENIERÍA DEL S O F TW A RE . UN E N F O Q U E P R A C T I C O
sistem as17. El parám etro de productividad se puede ex

M uy traer para las condiciones locales mediante datos histó
M uy
E x p e rie n c ia /c a p a c id a d baja Baja Normal A lta ricos recopilados de esfuerzos de desarrollo pasados.
alta
del d e sa rro lla d o r
M uy M uy
M a d u re z /c a p a c id a d Baja N o rm a l A lta alta
baja
del e n to rn o
Referencia W eb I 1
Se puede obtener información de las herramientas de
PROD 4 7 13 25 50 estimación del coste del software que se han desarrollado
a partir de la ecuación del software en www.qsm.com
T A B L A 5 .2 . P ro p o rc io n e s d e p ro d u c tiv id a d p a ra p u n to s
o b je to [BOE96].
5.7.3. La e c u a c ió n d el so ftw a re Es importante señalar que la ecuación del software

tiene dos parám etros independientes: (1) una estim a
La ecuación del software [PUT92] es un modelo multiva-
ción del tam año (en LDC) y (2) una indicación de la
riable dinámico que asume una distribuciónespecíficadel
duración del proyecto en m eses o años.
esfuerzo a lo largo de la vida de un proyecto de desarrollo
Para sim plificar el proceso de estim ación y utilizar
de software. El modelo se ha obtenido a partir de los datos
una form a m ás com ún para su m odelo de estimación,
de productividad para unos 4.000 proyectos actuales de
Putnam y M yers sugieren un conjunto de ecuaciones
software, un modelo de estimación tiene esta forma:
obtenidas de la ecuación del software. Un tiem po m íni
E = [LDC x B°'333/P ]3 x (1 / 14) (5.3) m o de desarrollo se define como:
donde Ciin = 8,14 (L D C /P )oa} en m eses para t„, > 6 m eses (5.4a)
E = esfuerzo en personas-m es o personas-año, E = 180ÚÍ3 en personas-m es para E > 20 personas-m es (5.4b)
t = duración del proyecto en m eses o años, Tenga en cuenta que t en la ecuación (5.4b) se repre
B = «factor especial de destrezas»16, senta en años.
P = «parámetro de productividad» que refleja: M ediante las ecuaciones (5.4) con P = 12.000 (valor
recom endado para software científico) para el softwa
• M adurez global del proceso y de las prácticas
re de CAD estudiado anteriormente en este capítulo,
de gestión.
• La amplitud hasta donde se utilizan correcta tmin = 8 ’14 (3 3 .2 0 0 / 12.000)0'4’
mente las norm as de la ingeniería del software. tmin = 12-6 m eses

• El nivel de los lenguajes de program ación uti E = 1 8 0 x 0 ,2 8 x ( l ,0 5 ) ?
lizados. El estado del entorno del software. E = 58 personas-m es
• Las habilidades y la experiencia del equipo del
Los resultados de la ecuación del software se corres
software.
ponde favorablem ente con las estim aciones desarrolla
• La com plejidad de la aplicación.
das en la Sección 5.6. Del m ism o m odo que el m odelo
Los valores típicos para el desarrollo del software COCOM O expuesto en la sección anterior, la ecuación
em potrado en tiem po real podrían ser P = 2.000; del software ha evolucionado durante la década pasa
P = lO.OOOpara telecomunicaciones y software de sis da. Se puede encontrar un estudio de la versión exten
temas; y P = 28.000 para aplicaciones comerciales de dida de este enfoque de estim ación en [PUT97],
5.8 LA D E C ISIÓ N DE D E S A R R Q L L A R -C Q M P R A R
En muchas áreas de aplicación del software, a m enu componentes de software «totalmente experimentado»
do es m ás rentable adquirir el software de com putado o «parcialm ente experim entado» (Consulte la Sección
ra que desarrollarlo. Los gestores de ingeniería del 5.4.2), y entonces m odificarse e integrarse para cum
software se enfrentan con una decisión desarrollar o plir las necesidades específicas, o (3) el software pue
comprar que se puede com plicar aún más con las opcio de ser construido de form a personalizada por una
nes de adquisición: (1) el software se puede com prar empresa externa para cum plir las especificaciones del
(con licencia) ya desarrollado; (2) se pueden adquirir comprador.
www.FreeLibros.org
16 B se incrementa lentam ente a medida que crecen «la necesidad de 17 Es im portante destacar que el parám etro de productividad puede
integración, pruebas, garantía de calidad, documentación y habilidad obtenerse em píricam ente de los datos locales de un proyecto,
de gestión» [PUT92], Para program as pequeños (K LD C = 5 a 15).B =
0,16. Para program as mayores de 70 KLDC,B = 0,39.
92
CAPÍTULO 5 P L A N I F I C A C I Ó N DE P R O Y E C T O S DE SOFTW ARE
Los pasos dados en la adquisición del software se En el análisis final, la decisión de desarrollar— com
definen según el sentido crítico del software que se va prar se basa en las condiciones siguientes: (1) ¿La fecha
a comprar y el coste final. En algunos casos (por ejem de entrega del producto de software será anterior que la
plo: software para PC de bajo coste) es m enos caro com del softw are desarrollado internam ente? (2) ¿Será el
prar y experim entar que llevar a cabo una larga coste de adquisición ju n to con el de personalización
evaluación de potenciales paquetes de software. Para m enor que el coste de desarrollo interno del softw are?
productos de software m ás caros, se pueden aplicar las (3) ¿Será el coste del soporte externo (por ejemplo: un
directrices siguientes: contrato de m antenim iento) m enor que el coste del
1. Desarrollo de una especificación para la función y soporte interno? Estas condiciones se aplican a cada una
rendimiento del software deseado. Definición de las de las opciones señaladas anteriormente.
características medibles, siempre que sea posible.
5.8.1. C reació n d e u n árbol d e d ecisio n es
Los pasos descritos anteriormente se pueden especifi
car mediante técnicas estadísticas tales com o el análi
Hoy veces en los que elsoftware proporciono uno sis del árbol de decisión [BOE89]. Por ejem plo, la
solución«perfecto» excepto poro algunos aspectos
Figura 5.6 representa un árbol de decisión para un sis
especlalesde los que puede prescindir. En muchos cosos,
tem a X basado en software. En este caso, la organiza
/ merece lo peno vivir sin éstosI
ción de la ingeniería del software puede (1) construir el
sistema X desde el principio; (2) reutilizar los com po
2. Estimación del coste interno de desarrollo y la fecha nentes existentes de «experiencia parcial» para cons
de entrega. truir el sistem a; (3) com prar un producto de software
3a.Selección de tres o cuatro aplicaciones candidatos disponible y m odificarlo para cum plir las necesidades
que cumplan m ejor las especificaciones. locales; o (4) contratar el desarrollo del software a un
3b.Selección de componentes de software reutilizables vendedor externo.
que ayudarán en la construcción de la aplicación ^ ¿Existe un método sistemático para
requerida. * ordenar las opciones relacionadas con
. 4. Desarrollo de una matriz de comparación que presente la decisión desarrollar-comprar?
la comparación una a una de las funciones clave. Alter
nativamente, realizar el seguimiento de las pruebas de Si se va a construir un sistem a desde el principio,
evaluación para com parar el software candidato. existe una probabilidad del 70 por 100 de que el tra
5. Evaluación de cada paquete de software o com po bajo sea difícil. M ediante las técnicas de estim ación
nente según la calidad de productos anteriores, estudiadas en este capítulo, el planificado r del p ro
soporte del vendedor, dirección del producto, repu yecto estim a que un esfuerzo de desarrollo difícil cos
tación, etc. tará £450.000. Un esfuerzo de desarrollo «sim ple» se
6. Contacto con otros usuarios de dicho software y peti estim a que cueste £380.000. El valor esperado del cos
ción de opiniones. te, calculado a lo largo de la ram a del árbol de deci
sión es:
£380.000
coste esperado = X (probabilidad del cam ino^ X (coste esti
m ado del cam ino) ¡
€450.000
£275.000 donde i es el cam ino del árbol de decisión. P ara el
cam ino construir,
c o ste e sp e ra d o construcción = 0 ,3 0 (£ 3 8 0 K ) + 0 ,7 0 (£ 4 5 0 K )
£310.000
= £429K .........
También se m uestran los otros caminos del árbol de

€490.000
decisión, los costes proyectados para la reutilización,
com pra y contrato, bajo diferentes circunstancias. L os
€2 10.000
costes esperados de estas rutas son:
€400.000 coste esperadoreut¡j¡zación = 0,40 (£275K ) + 0,60 [0,20(£310K )
+ 0,80(£490K )] = £382K
coste e sp e ra d o compra = 0,70(£210K ) + 0,30(£400K ) = £ 2 6 7 K

€350.000
coste esperado,™ = 0,60(£350K ) + 0,40(£500K )] = £ 4 1 0 K
€500.000
www.FreeLibros.org
Según la probabilidad y los costes proyectados que
FIGURA 5 .6 . Árbol de decisión para apoyar la decisión se han señalado en la Figura 5.6, el coste más bajo espe
desarrollar-comprar. rado es la opción «compra».
93
IN GE NIE RI A DEL S O F TW A RE . UN EN F O Q U E P R A C T I C O
con un tercero, quien hace el trabajo a bajo coste ase

gurando una alta calidad. El trabajo de software lleva
do dentro de la com pañía se reduce a una actividad de
Referencia Web
gestión de contratos.
Se puede encontrar un tutorial excelente sobre el análisis
del árbol de decisión en
www.demon.co.uk/mindtool/dectree.html C ita :
modo de reglo, el outsourcing requiere incluso
Sin embargo, es importante señalar que se deben con rtís gestión experto que el desoriollo interno.
siderar m uchos criterios —no sólo el coste — durante SWr Sfe& wieü
el proceso de tom a de decisiones. La disponibilidad, la
experiencia del desarrollador/vendedor/contratante, la La decisión de contratar fuentes externas puede ser
conform idad con los requisitos, la política «local», y la estratégica o táctica. En el nivel estratégico, los gesto
probabilidad de cambios son sólo uno de los pocos cri res tienen en consideración si una parte im portante de
terios que pueden afectar la últim a decisión para cons todo el trabajo del software puede ser contratado a otros.
truir, volver a utilizar o contratar. En el nivel táctico, un jefe de proyecto determina si algu
nas partes o todo el proyecto es aconsejable realizarlo
5.8.2. S u b co n tr a ta ció n (o u tso u r c in g ) mediante subcontratación.
Más pronto o más tarde toda compañía que desarrolla soft Con independencia de la am plitud del enfoque, la
ware de com putadora hace una pregunta fundamental: decisión de elegir outsourcing es a m enudo financiera.
«¿Existe alguna forma por la que podam os conseguir a Un estudio detallado del análisis financiero de la deci
bajo precio el software y los sistemas que necesitamos?» sión del outsourcing está fuera del ám bito de este libro
La respuesta a esta pregunta no es simple, y las discusio y se reserva m ejor para otros (por ejemplo: [MIN95]).
nes sobre esta cuestión dan como respuesta una simple Sin embargo, merece la pena realizar un repaso de los
palabra: subcontratación (outsourcing). pros y los contras de la decisión.
En el lado positivo, los ahorros de coste se pueden
lograr reduciendo el núm ero de personas y las instala
Referencia Web ciones (por ejemplo: computadoras, infraestructura) que
Se puede encontrar información útil (documentos, enlaces) los apoyan. En el lado negativo, una com pañía pierde
acerca del outsourcing en www.outsourcmg.com control sobre el software que necesita. Com o el soft
ware es una tecnología que diferencia sus sistemas, ser
El concepto outsourcing es extremadamente simple. vicios, y productos, una com pañía corre el riesgo de
Las actividades de ingeniería del software se contratan poner su destino en m anos de un tercero.
DE. ESTIMACIÓH_________ —
Las técnicas de descomposición y los modelos em píri (Capítulo 2) y se especifica el conjunto de tareas de
cos de estimación descritos en las secciones anteriores se ingeniería del software.
pueden implementar con software. Las herramientas auto 3. Predicción de los niveles de la plantilla. Se espe
máticas de estim ación perm iten al planificador estimar cifica el núm ero de personas disponibles para reali
costes y esfuerzos, así como llevar a cabo análisis del tipo zar el trabajo. Esto es muy importante, puesto que la
«qué pasa si» con importantes variables del proyecto, relación entre las personas disponibles y el trabajo
tales como la fecha de entrega o la selección de perso (esfuerzo previsto) no es muy lineal.
nal. Aunque existen muchas herramientas automáticas de
4. Predicción del esfuerzo del softw are. Las herra
estimación, todas exhiben las mismas características gene m ientas de estimación utilizan uno o m ás modelos
rales y todas realizan las seis funciones genéricas m os (por ejemplo, Sección 5.7) que relacionan el tamaño
tradas a continuación [JON96]: de las entregas del proyecto con el esfuerzo necesa
1. Dimensionamiento de las entregas del proyecto. rio para producirlas.
Se estim a el «tam año» de uno o m ás productos de 5. Predicción del coste del software. Dado los resul
software. Los productos incluyen la representación tados del paso 4 , los costes pueden calcularse asig
externa del software (por ejemplo, pantallas, infor nando proporciones del trabajo a las actividades del
mes), el software en sí (por ejemplo, KLDC), su fun proyecto señaladas en el paso 2.
cionalidad (por ejem plo, puntos <je función), y la 6. Predicción de la planificación del software. Cuando
www.FreeLibros.org
inform ación descriptiva (por ejemplo, documentos). se conoce el esfuerzo, los niveles de la plantilla y las
2. Selección de las actividades del proyecto. Se selec actividades del proyecto, se puede realizar un borra
ciona el m arco de trabajo del proceso adecuado dor de la planificación asignando el trabajo a través
, *
CAPÍTULO 5 P L A N I F I C A C I Ó N DE P R O Y E C T O S DE S OF TW AR E
de actividades de ingeniería del software basadas en C uando se aplican distintas herram ientas de esti
m odelos recom endados para la distribución del m ación a los m ism os datos del proyecto, se observa
esfuerzo (Capítulo 7). una variación relativam ente grande entre los resu lta
dos estim ados. Pero lo que es m ás im portante, a veces
los valores son bastante diferentes de los valores rea
les. Esto refuerza la idea de que los resultados o b te
nidos por las herram ientas de estim ación se deben usar
sólo com o «punto de p a rtid a » para la o b ten ció n de
estim aciones —no com o única fuente para la estim a
Herramientas Case. ción— .
|JL £ S11M£M — — __________

El planificador del proyecto de software tiene que esti de personas-m es requeridas para cada actividad de inge
mar tres cosas antes de que comience el proyecto: cuán niería del software. Las técnicas empíricas usan expre
to durará, cuánto esfuerzorequerirá y cuánta gente estará siones em píricamente obtenidas para el esfuerzo y para
implicada. A dem ás, el planificador debe predecir los el tiempo, con las que se predicen esas m agnitudes del
recursos (de hardware y de software) que va a requerir, proyecto. Las herram ientas automáticas im plem entan
y el riesgo implicado. un determ inado m odelo empírico.
El enunciado del ámbito ayuda a desarrollar estim a Para obtener estim aciones exactas para un proyecto,
ciones mediante una o varias de las técnicas siguientes: generalmente se utilizan al m enos dos de las tres técni
descomposición, m odelos em píricos y herram ientas cas referidas anteriormente. M ediante la comparación
automáticas. Las técnicas de descomposición requieren y la conciliación de las estim aciones obtenidas con las
un esbozo de las principales funciones del softw are, diferentes técnicas, el planificador puede obtener una
seguido de estim aciones (1) del núm ero de L D C ’s, (2) estim ación m ás exacta. La estimación del proyecto de
de los valores seleccionados dentro del dominio de la software nunca será una ciencia exacta, pero la com bi
información, (3) del núm ero de personas-m es requeri nación de buenos datos históricos y de técnicas siste
das para im plem entar cada función, o (4)del núm ero máticas pueden m ejorar la precisión de la estimación.
LfifF E B E N C I& a_____________________

[BEN92] Bennatan, E. M., Software ProjectManagement: A [MAH96] Mah, M., Quantitive Software Management, Inc.,
Practitioner'sApproach, McGraw-Hill, 1992. prívate communication.
[BOE81] Boehm,B., Software Engineering Economías, Pren- [MAT94] Matson, J ., B . Barrett y J. Mellichamp, «Software
tice-Hall, 1981. Development Cost Estimation Using Function Points»,
[BOE89] Boehm, B., Risk M anagement, IEEE Computer IEEE Trans. Software Engineering, vol. 20, n.e 4, Abril
Society Press, 1989. 1994, pp. 275-287.
[BOE96] Boehm, B., «Anchoring the SoftwareProcess», IEE [MIN95] Minoli, D .,Analizing Outsourcing, McGraw-Hill,
Software, v ol. 13,n.2 4, Julio 1996,pp. 73-82. 1995.
[BOEOO] Boehm, B., et al., Software Cost Estim ation in [PHI98] Phillips, D., The Software Project Manager's Hand-
COCOMO11. Prentice Hall, 2000. book, IEEE Computer Society Press, 1998.
[BR075] Brooks, E , TheM vthical M an-Month, Addison- [PUT92] Putnam, L., y W. Myers, M easuresfor Excellence,
Wesley, 1975. ' Yourdon Press, 1992.
[GAU89] Gause,D. C .,y G. M. Weinberg,Exploring Requi- [PUT97a] Putnam, L., y W. Myers, «How Solved is the Cost
rements: Quality Befare Design, Dorset House, 1989. Estimation Problem», IEEE Software, Noviembre 1997,
[H0091] Hooper,J. W. E .,y R. O. Chester, Software Reuse: pp. 105-107.
Guidelines and Methods, Plenum Press, 1991. [PUT97b] Putnam, L., y W. Myers, Industrial Strength Soft
[JON96] Jones, C., «How Software Estimation Tools Work», ware: Effective Management UsingMeasurement, IEEE
American Programmer, vol. 9, n.a 7, Julio 1996,pp. 19-27. Computer Society Press, 1997.
www.FreeLibros.org Y5
I N GEN IE RÍ A DEL S O F TW A RE . UN E N F O Q U E P R A C T I C O
5.1. Suponga que es el gestor de proyectos de una compañía damente 80 componentes de software. Asuma complejidad
que construye software para productos de consumo. Ha con «media» y maduración desarrollador/entomo media. Utilice
tratado una construcción de software para un sistema de segu el modelo de composición de aplicación con puntos objeto.
ridad del hogar. Escriba una especificación del ámbito que 5.7. Utilice la «ecuación del software» para estimar el soft
describa el software. Asegúrese de que su enunciado del ámbi ware del sistema de seguridaddel hogar. Suponga que las Ecua
to sea limitado. Si no está familiarizado con sistemas de segu ciones (5.4) son aplicables y que P = 8.000.
ridad del hogar, investigue un poco antes de comenzar a
5.8. Compare las estimaciones de esfuerzo obtenidas de los
escribir. Alternativa: sustituya el sistema de seguridad del
Problemas 5.5 y 5.7. Desarrolle una estimación simple para
hogar por otro problema que le sea de interés.
el proyecto mediante una estimación de tres puntos. ¿Cuál es
5.2. La complejidad del proyecto de software se trata breve la desviación estándar?, y ¿cómo afecta a su grado de certeza
mente en la Sección 5.1. Desarrolle una lista de las caracte sobre la estimación?
rísticas de software (por ejemplo: operación concurrente, salida
gráfica, etc.), que afecte a la complejidad de un proyecto. Dé 5.9. Mediante los resultados obtenidos del Problema 5.8, deter
prioridad a la lista. mine si es razonable esperar que el resultado se pueda cons
truir dentro de los seis meses siguientes y cuántas personas se
5.3. El rendimiento es una consideración importante durante
tendrían que utilizar para terminar el trabajo.
la planificación. Discuta si puede interpretar el rendimiento de
otra manera, dependiendo del área de aplicación del software. 5.10. Desarrolle un modelo de hoja de cálculo que implemente
una técnica de estimación o más, descritas en el capítulo. Alter
5.4. Haga una descomposición de las funciones software
nativamente, obtenga uno o más modelos directos para la esti
para el sistema de seguridad del hogar descrita en el Pro
mación desde la web.
blema 5.1. Estime el tamaño de cada función en LDC. Asu
miendo que su organización produce 450LDC/pm con una 5.11. Para un equipo de proyecto: Desarrolle una herramien
tarifa laboral de $7.000 por persona-mes, estime el esfuer ta de software que implemente cada una de las técnicas de esti
zo y el coste requerido para construir el software utilizan mación desarrolladas en este capítulo.
do la técnica de estimación basada en LDC que se describe 5.12. Parece extraño que las estimaciones de costes y plani
en la Sección 5.6.3. ficaciones temporales se desarrollen durante la planificación
5.5. Utilizando las medidas de punto de función de tres dimen del proyecto de software — antes de haber realizado un aná
siones que se describe en el Capítulo 4, calcule el número de PF lisis de requisitos o un diseño detallado — . ¿Por qué cree que
para el software del sistema de seguridad del hogar, y extraiga las se hace así? ¿Existen circunstancias en las que no deba pro-
estimacionesdel esfuerzo y del coste mediante la técnica de esti cederse de esta forma?
mación basada en PF que se describe en la Sección5.6.4. 5.13. Vuelva a calcular los valores esperados señalados en el
5.6. Utilice el modelo COCOMO II para estimar el esfuerzo árbol de decisión de la Figura 5.6 suponiendo que todas las
necesario para construir software para un simple ATM que ramas tienen una probabilidad de 50-50. ¿Por qué cambia esto
produzca 12 pantallas; 10 informes, y que necesite aproxima su decisión final?
La mayoría de los libros de gestión de proyectos de softwa empíricos para la estimación del software. Estos libros propor
re contienen estudios sobre la estimación de proyectos. Jones cionan un análisis detallado de datos que provienen de cientos
(Estimating Software Costs, McGraw Hill, 1998) ha escrito de proyectos de software. Un libro excelente de DeMarco (Con-
el tratado más extenso sobre la estimación de proyectos pu trolling Software Projects, Yourdon Press, 1982) proporciona
blicado hasta la fecha. Su libro contiene modelos y datos apli una profunda y valiosa visión de la gestión, medición y esti
cables a la estimación del software en todo el dominio de la mación de proyectos de software. Sneed (SoftwareEngineering
aplicación. Roetzheim y Beasley (SoftwareProject Cosí and Management, Wiley, 1989) y Macro (Software Engineering :
Schedule Estimating: Best Practices, Prentice-Hall, 1997) Concepts and Management, Prentice — Hall, 1990) estudian la
presentan varios modelos útiles y sugieren las directrices paso estimación del proyecto de software con gran detalle.
a paso para generar las estimaciones mejores posibles. La estimación del coste de líneas de código es el enfoque
Los libros de Phillips [PHI98], Bennatan (OnTitne, Wit- más comúnmente utilizado. Sin embargo, el impacto del para
hin Budget: Software Project M anagem ent Practices and digma orientado a objetos (consulte la Parte Cuarta) puede
Techniques, Wiley, 1995), Whitten (Managing Software Deve- invalidar algunos modelos de estimación. Lorenz y Kidd
lopmentProjects: Form ulafor Success, Wiley, 1995), Well- (Object.— OrientedSoftware Metrics, Prentice— Hall, 1994)
man (Software Costing, Prentice-Hall, 1992), Londeix (Cosí y Cockburn (Surviving Object— Oriented Projects, Addi
Estiniationfor SoftwareDevelopment, Addison-Wesley, 1987) son-Wesley, 1998)estudian la estimación para sistemas orien
contienen información útil sobre la planificación y la esti tados a objetos.
mación de proyectos de software. En Intemet están disponibles una gran variedad de fuen
El tratamiento detallado de la estimación del coste de soft tes de información sobre la planificación y estimación del
www.FreeLibros.org
ware de Putnam y Myers ([PUT92] y [PUT97b]), y el libro de software. Se puede encontrar una lista actualizada con refe
Boehm sobre la economía de la ingeniería del software ([BOE8 1] rencias a sitios (páginas) web que son relevantes para la esti
y COCOMO II [BOE00]) describen los modelos de estimación mación del software en http://w w w .pressm an5.com .
96
CAPÍTULO
K A N Á L IS IS Y GESTIÓN DEL RIESGO
N su libro sobre análisis y gestión del riesgo, R obert C harette [CHA89] p resenta la
E siguiente definición de riesgo:
En prim er lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer están más
allá de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente
con nuestras acciones del pasado. La pregunta es, podem os, por tanto, cam biando nuestras
acciones actuales, crear una oportunidad para una situación diferente y, con suerte, m ejor para
nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo im plica cam bio, que pue
de venir dado por cam bios de opinión, de acciones, de lugares... [En tercer lugar,] el riesgo
im plica elección, y la incertidum bre que entraña la elección. Por tanto, el riesgo, com o la m uer
te y los impuestos, es una de las pocas cosas inevitables en la vida.
Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares
conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa
— ¿qué riesgos podrían hacer que nuestro proyecto fracasara?— . El cambio es nuestra preocu
pación ¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías de desa
rrollo, en las com putadoras a las que va dirigido el proyecto y a todas las entidades relacionadas
con él, al cum plimiento de la planificación tem poral y al éxito en general?. Para terminar, debe
mos enfrentam os a decisiones — ¿qué m étodos y herram ientas deberíamos emplear, cuánta gen
te debería estar im plicada, cuánta importancia hay que darle a la calidad?— .
VISTAZO RÁPIDO
¿Qué e s ? El a n á l i s i s y la g e s tió n d e l ¿ P op q u é e s im p o r ta n te ? Pensem os en b a b ilid a d y d el im pacto. Por últim o, s e

riesg o so n u n a s e r ie d e p a s o s q u e el lem a d e los boys scout: « e starp re p a- d e s a rro lla u n p la n p a r a g e s tio n a r
ay u d an a l e q u ip o d el so ftw a re a com rados» .El softw are e s u n a em presa difí aq u ello s riesgos con gran p robabilidad
p ren d er y a g e s tio n a r la in c e rtid u m cil. M uchas c o sa s p u e d e n ir m al, y e im pacto.
bre. Un p ro y e cto d e s o ftw a re p u e d e francam ente, a m enudo van m a l. Esta es ¿Cuál e s e l p r o d u c t o o b t e n i d o ? Se
e s ta r lle n o d e p ro b le m a s . Un rie s g o la razón p a ra e sta r p re p a ra d o s - c o m re a liz a u n P la n d e R e d u cc ió n , S u p e r
e s un p ro b le m a p o te n c ia l — p u e d e p re n d ie n d o los riesg o s y tom an d o la s v isió n y G e stió n d e l R iesg o (RSG R)o
ocurrir o no— . P ero sin te n e r e n c u e n m edidas proactivas p a ra evitarlo o g e s u n inform e d e riesgos.
ta el re s u lta d o , r e a lm e n te e s u n a tionarlo— e s un elem ento clave d e una ¿Cómo p u e d o e s t a r s e g u r o d e que
b u en a id e a id e n tific a rlo , e v a lu a r su buena gestión d e proyectosde software. lo h e h e c h o c o r r e c ta m e n te ? L o s
p ro b a b ilid a d d e a p a r ic ió n , e s tim a r ¿Cuáles s o n l o s p a s o s ? El re co n o c i riesgos a n alizad o s y g estio n ad o s d e b e
su im p a c to ,y e s ta b le c e r u n p la n d e m iento d e q u e a lg o p u e d e ir m al e s el rían d erivarse del estu d io del p ersonal,
c o n tin g e n c ia por si o c u rre e l p ro b le prim er paso, llam ado identificacióndel d e l producto, d el p roceso y del p royec
ma. riesgo. A con tin u ació n , c a d a riesgo e s to. El R S G R debe ser rev isad o m ientras
¿Quien l o h a c e ? T odos lo s q u e e sté n a n a liz a d o p a ra d e te rm in a r la p ro b a b i el pro y ecto se re a liz a p a r a a s e g u ra r
involucrados e n el p roceso del so ftw a lid a d d e q u e p u e d a o c u rrir y e l d a ñ o q u e loe rie sg o s e s tá n sien d o c o n tro la
re - g e s to re s ,in g e n ie ro s d e so ftw a rey q u e p u e d e c a u s a r si bcurre. U na vez d o s h a s ta la fecha. Los p la n e s d e con
c lie n te s— p a rtic ip a n e n el a n á lis is y e sta b le c id a e s ta inform ación, se p rio - tin g e n c ia p a ra la g e s tió n d e l rie s g o
la g e stió n d el riesgo. rizan los riesg o s, e n función d e la pro d e b e n ser re alistas.
Peter Drucker [DRU75] dijo una vez: «M ientras que es inútil intentar elim inar el riesgo y
cuestionable el poder minimizarlo, es esencial que los riesgos que se tom en sean los riesgos
www.FreeLibros.org
adecuados». Antes de poder identificar los «riesgos adecuados» a tener en cuenta en un p ro
yecto de software, es im portante poder identificar todos los riesgos que sean obvios a jefes de
proyecto y profesionales del software.
97
INGENIERÍA DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
Las estrategias se han denom inado humorísticamente te, en caso de que pudieran convertirse en problemas
«E scuela de gestión del riesgo de Indiana Jones» reales. Pero lo más frecuente es que el equipo de soft
[T H 092], En las películas, Indiana Jones, cuando se ware no haga nada respecto a los riesgos hasta que algo
enfrentaba a una dificultad insuperable, siempre decía, va mal. Después el equipo vuela para corregir el pro
«¡No te preocupes, pensaré en algo!». Nunca se preo blem a rápidam ente. Este es el m étodo denom inado a
cupaba de los problem as hasta que ocurrían, entonces m enudo «de bom beros». Cuando falla, «la gestión de
Indy reaccionaba de alguna m anera heroica. crisis» [CHA92] entra en acción y el proyecto se encuen
tra en peligro real.
U na estrategia considerablem ente m ás inteligente
para el control del riesgo es ser proactivo. L a estrate
S «ted no oteco los riesgos ortivamente, ellos le gia proactiva em pieza m ucho antes de que comiencen
otccfflóo ortivomente o usted. los trabajos técnicos. Se identifican los riesgos poten
ciales, se evalúa su p ro b a b ilid ad y su im pacto y se
establece una prioridad según su im portancia. Des
p ués, el equipo de Softw are estab lece un plan para
Desgraciadam ente, el jefe del proyecto de software controlar el riesgo. El prim er objetivo es evitar el ries
norm alm ente no es Indiana Jones y los m iem bros de su go, pero com o no se pueden evitar todos los riesgos,
equipo no son sus fiables colaboradores. Sin embargo, el equipo trabaja para desarrollar un plan de contin
la mayoría de los equipos de software confían solamente gencia que le perm ita responder de una m anera efi
en las estrategiasde riesgo reactivas. En el m ejor de los caz y controlada. A lo largo de lo que queda de este
casos, la estrategia reactiva supervisa el proyecto en pre cap ítu lo , estudiam os la estra te g ia proactiva para el
visión de posibles riesgos. Los recursos se ponen apar control de riesgos.
Aunque ha habido amplios debates sobre la definición ción y organización), recursos, cliente y requisitos y su
adecuada para riesgo de software, hay acuerdo común impacto en un proyecto de software. En el Capítulo 5, la
en que el riesgo siem pre im plica dos características com plejidad del proyecto, tam año y el grado de incerti-
[HIG95]: dumbre estructural fueron tam bién definidos como fac
* Incertidumbre: el acontecimiento que caracteriza al tores (y estimados) de riesgo del proyecto.
L os riesgos técnicos amenazan la calidad y la plani
riesgo puede o no puede ocurrir; por ejemplo, no hay
ficación tem poral del software que hay que producir. Si
riesgos de un 100 por 100 de probabilidad'.
un riesgo técnico se convierte en realidad, la imple-
• Pérdida: si el riesgo se convierte en una realidad,
m entación puede llegar a ser difícil o im posible. Los
ocurrirán consecuencias no deseadas o pérdidas.
riesgos técnicos identifican problem as potenciales de
Cuando se analizan los riesgos es importante cuan- diseño, implementación, de interfaz, verificación y de
tificar el nivel de incertidumbre y el grado de pérdidas m antenimiento. Además, las ambigüedades de especi
asociado con cada riesgo. Para hacerlo, se consideran ficaciones, incertidumbre técnica, técnicas anticuadas
diferentes categorías de riesgos. y las «tecnologías punta» son tam bién factores de ries
go. Los riesgos técnicos ocurren porque el problem a es
^ ¿Qué tipo de riesgos es problable m ás difícil de resolver de lo que pensábamos.
W que nos encontremos en el Los riesgos del negocio amenazan la viabilidad del
software que se construye? software a construir. Los riesgos del negocio a menudo
ponen en peligro el proyecto o el producto. Los candi
Los riesgos del proyecto amenazan al plan del pro datos para los cinco principales riesgos del negocio son:
yecto; es decir, si los riesgos del proyecto se hacen rea (1) construir un producto o sistem a excelente que no
lidad, es probable que la planificación tem poral del quiere nadie en realidad (riesgo de mercado); (2) cons
proyecto se retrase y que los costes aumenten. Los ries truir un producto que no encaja en la estrategia com er
gos del proyecto identifican los problemas potenciales de cial general de la com pañía (riesgo estratégico); (3)
presupuesto, planificación tem poral, personal (asigna construir un producto que el departamento de ventas no
www.FreeLibros.org
1 Un riesgo del 100 por 100 es una limitación del proyecto de soft
ware.
98
CAPÍTULO 6 A N Á LI S IS Y G E S T I Ó N DEL R I E S G O
sabe cómo vender; (4)perder el apoyo de una gestión Otra categorización general de los riesgos ha sido pro
experta debido a cam bios de enfoque o a cam bios de puesta por Charette [CHA89]. Los riesgos conocidos son
personal (riesgo de dirección); (5) perder presupuesto todos aquellos que se pueden descubrir después de una
o personal asignado (riesgos de presupuesto). E s extre cuidadosa evaluación del plan del proyecto, del entorno
madamente im portante recalcar que no siem pre fun técnico y comercial en el que se desarrolla el proyecto y
ciona una categorización tan sencilla. Algunos riesgos otras fuentes de inform ación fiables (por ejemplo: fechas
son simplemente im posibles de predecir. de entregapoco realistas, falta de especificación de requi
sitos o de ám bito del software, o un entorno pobre de
desarrollo). Los riesgos predecibles se extrapolan de la
experiencia en proyectos anteriores (por ejemplo: cam
.{Hoy en dio,] nadie se permite el lujo de conocer tan bio de personal, m ala com unicación con el cliente, dis
bien una toreo que no contengo ninguna sorpresa, y minución del esfuerzo del personal a medida que atienden
peticiones de mantenimiento). Los riesgos impredecibles
son el com odín de la baraja. Pueden ocurrir, pero son
extrem adam ente difíciles de identificar por adelantado.
SjóLi-DJE N T.í F.IG A Q lO M JiU Jt & ClQ„. ,
La identificación del riesgo es un intento sistem áti . Impacto en el negocio: riesgos asociados con las limi
co para especificar las am enazas al plan del proyecto taciones impuestas por la gestión o por el mercado.
(estimaciones, planificación temporal, carga de recur ■ C aracterísticas del cliente: riesgos asociados con la
sos, etc.). Identificando los riesgos conocidos y prede sofisticación del cliente y la habilidad del desarro
cibles, el gestor del proyecto da un paso adelante para llador para comunicarse con el cliente en los m om en
evitarlos cuando sea posible y controlarlos cuando sea tos oportunos.
necesario. • D efinición del p ro ceso : riesgos asociados con el
grado de definición del proceso del software y su
seguimiento por la organización de desarrollo.
■ Entorno de desarrollo: riesgos asociados con la dis
Aunque los riesgos genéricos son importantes a tener en
ponibilidad y calidad de las herram ientas que se van
cuento, hobitualmente los riesgos específicos del producto
provocan lo mayoría de los dolores de cabeza. Esté
a em plear en la construcción del producto.
convenciio al invertirel tiempoen identificartantos • Tecnología a construir: riesgos asociados con la com
riesgos específicos de/producto como seo posible. plejidad del sistema a construir y la tecnología punta
que contiene el sistema.
Existen dos tipos diferenciados de riesgos para cada • Tamañoy experiencia de la plantilla: riesgos asocia
categoría presentada en la Sección 6.2: riesgos genéri dos con la experiencia técnica y de proyectos de los
cos y riesgos específicos del producto. Los riesgos gené ingenieros del software que van a realizar el trabajo.
ricos son una amenaza potencial para todos los proyectos
de software. Los riesgos específicos de producto sólo
los pueden identificar los que tienen una clara visión de
la tecnología, el personal y el entorno específico del pro
yecto en cuestión. Para identificar los riesgos específi
cos del producto, se examinan el plan del proyecto y la
declaración del ámbito del software y se desarrolla una lista de comprobación de elementos del riesgo.
respuesta a la siguiente pregunta: «¿Qué características
La lista de com probaciónde elementos de riesgo pue
especiales de este producto pueden estar am enazadas
de organizarse de diferentes m aneras. Se pueden res
por nuestro plan del proyecto?»
ponder a cuestiones relevantes de cada uno de los temas
Un m étodo para identificar riesgos es crear una lis
apuntados anteriorm ente para cada proyecto de soft
ta de comprobación de elem entos de riesgo. L a lista
ware. Las respuestas a estas preguntas perm iten al pla
de comprobación se puede utilizar para identificar ries
nificador del proyecto estim ar el im pacto del riesgo. Un
gos y se centra en un subconjunto de riesgos conoci
form ato diferente de lista de com probación de elem en
d o s y predecibles en las sig u ien tes subcategorías
tos de riesgo contiene sim plem ente las características
www.FreeLibros.org
genéricas: relevantes para cada subcategoría genérica. Finalm en
• Tamaño del_producto: riesgos asociados con el tamaño te, se lista un conjunto de «componentes y controlado
general del software a construir o a modificar. res del riesgo» [AFC88] ju n to con sus probabilidades
99
I N GE NI E RÍ A DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
de ap arición. L os co n tro la d o re s d el re n d im ie n to , el tores de proyectos de softw are ex p erto s de diferen tes

soporte, el coste y la planificación tem poral del proyecto partes del m u n d o [K E I98], L as preguntas están o rd e
se estudian com o resp u esta a p reguntas posteriores. n ad as p o r su im p o rtan c ia re la tiv a p a ra el é x ito de un
Se h a p ropuesto un gran num ero de listas de c o m proyecto.
prob ació n p ara el riesgo del p royecto de softw are en los
textos (por ejem plo, [SE I93], [K A R 96]). E stos p ro p o r ¿Corre un riesgo grave el proyecto de
cio n a n u n a v isió n útil de rie sg o s g en érico s p ara p ro
yecto s de softw are y d eberían u tilizarse ca d a v ez que
se realice el análisis y la g estión del riesgo. Sin em b ar
• softw are en el que estamos trabajando?
go, se puede utilizar una lista de preguntas relativam ente 1 .¿ S e h a n e n tre g a d o lo s g e s to re s d el s o ftw a re
pequ eñ a p ara prop o rcio n ar u n a indicación p re lim in a r y c lie n te s fo rm a lm e n te p a ra d a r so p o rte al p ro
de cuando un proyecto es «arriesgado». y e c to ?
2. ¿E stán com pletam ente entusiasm ados los usuarios
finales con el proyecto y con el sistem a/producto a
construir?
del riesgo es gestión de proyectos poro
3. ¿H an com prendido el eq u ip o de ingenieros de soft
w are y los clientes todos los requisitos?
4 . ¿H an estado los clientes involucrados p o r com pleto
en la definición de los requisitos?
6.3.1. E v a lu a c ió n G lo b a l d e l R ie s g o d e l P royecto
5. ¿T ienen los usuarios finales expectativas realistas?
Las siguientes preguntas provienen de los datos del ries
go obtenidos m ediante las encuestas realizad as a g e s 6. ¿Es estable el ám bito del proyecto?
^^CO M PO NENTES
R E N D IM IE N T O SOPORTE C OSTE P L A N IF IC A C IÓ N
TEM PORAL
C A T E G O R ÍA X
Dejar de cumplir los requisitos provocaría Malos resultados en un aumento de costes y retrasos de la
1
el fallo de la misión planificación temporal con gastos que superan las £500.001
Degradación El software no Recortes financieros Fecha

C A T A S T R Ó F IC A
significativa para responde o no significativos, presupuestos de entrega
2 noalcanzar admite soporte excedidos inalcanzable
el rendimiento técnico
Dejar de cumplir los requisitos degradaría Malos resultados en retrasos operativos y/o
1 el rendimiento del sistema hasta donde aumento de coste con un valor esperado
el éxito de la misión es cuestionable de €100.000a f500.000
C R IT IC A
Alguna reducción Pequeños retrasos Algunos recortes de los Posibles retrasos
2 en el rendimiento en modificaciones recursos financieros, posibles en la fecha de entrega
técnico de software excesos del presupuesto
Dejar de cumplir los requisitos provocaría Los costes, impactos y/o retrasosrecuperables
1
la degradación de la misión secundaria de la planificación temporal con un valor estimado
de fl.OOO a flOO.OOO
M A R G IN A L
De mínima a pequeña El soporte Recursos Planificación temporal
2
reducción en el del software financieros suficientes realista, alcanzable
rendimiento técnico responde
Dejar de cumplir los requisitos provocaría Los errores provocan impactos mínimos en el coste y/o
1 inconvenientes o impactos no operativos planificación temporal con un valor esperado de menos
de fl.OOO
D E S P R E C IA B L E
No hay reducción Software fácil Posible superávit Fecha de entrega
2 en el rendimiento de dar soporte de presupuesto fácilmente alcanzable
técnico
www.FreeLibros.org
Nota :(1) Posiblesconsecuenciasde erroreso defectos del software no detectados.
(2) Posibles consecuencias si el resultado deseado no se consigue.
F IG U R A 6 .2 . E v alu ac ió n del impacto [BOE89].
100
7. ¿T iene e l in g en iero de so ftw a re el c o n ju n to a d e ■ riesgo de laplanificación temporal: el grado de incer

cuado de habilidades? tidum bre con que se po d rá m antener la planificación
tem poral y de que el producto se entregue a tiem po.
8. ¿Son estables los requisitos del proyecto?
El im pacto de cada controlador del riesgo en el c o m
9. ¿Tiene ex p e rie n c ia el eq u ip o del p ro y ec to con la
ponente de riesgo se divide en cuatro categorías de im pac
tecn o lo g ía a im plem entar?
to - d e s p r e c i a b l e , m arg in al, crítico y c a t a s tr ó f ic o - .
10. ¿Es adecuado el núm ero de p ersonas del equipo del C om o m uestra la Figura 6.1 [B O E89], se describe una
proyecto p ara realizar el trabajo? caracterizaciónde las consecuenciaspotenciales de erro
11. ¿Están de acuerdo tod o s los clientes/usuarios en la res (filas etiquetadas con 1) o la im posibilidad de con se
im portancia del p royecto y en los requisitos del sis g uir el p ro d u c to desead o (filas e tiq u etad as con 2). L a
tem a/producto a construir? categoría de im pacto es elegida basándose en la caracte
rización que m ejo r encaja con la descripción de la tabla.
R ie s g o s á t e g o r íc ro b a b ilid a c mpacto
«Un radar del riesgo)) es una base de datos de gestión de
riesgoque ayuda a los gestores del proyectoa identificar,
priorizary comunicor los riesgos del proyecto. Se puede La e stim ación d e l ta m a ñ o puedi PS 60% 2
ser s ig n ific a tiv a m e n te b a ja
encontraren www.spmn.com/rsktrkr.html
M a y o r n ú m e ro d e u s u a rio s PS 30% 3
de lo s p re v is to s
M e n o s re u tiliza ció n . PS 70% 2
6.3.2. C o m p o n e n te s y c o n tr o la d o r e s d e l r ie s g o de la p re v is ta
Las Fuerzas A éreas de E stad o s U n id o s [A FC 88] han Los u s u a rio s fin a le s BU 40% 3
se re s is te n al s is te m a
redactado un docum ento que contiene excelentes d irec
La fe c h a d e e n tre g a e s ta rá BU 50% 2
trices p ara identificar riesg o s del softw are y evitarlos. m u y a ju s ta d a
El enfoque de las Fuerzas A éreas requiere que el g e s S e p e rd e rá n los p re s u p u e s to s cu 40% 1
tor del p royecto identifique los co n troladores del ries E l c lie n te c a m b ia rá PS 80% 2
go que afectan a los com ponentes de riesgo del softw are lo s re q u is ito s
— rendim iento, co ste, sop o rte y p la n ific a ció n te m p o La te c n o lo g ía no a lc a n za rá TE 30% 1
ral— En el contexto de este estudio, los com ponentes la s e s p e c ta tiv a s
de riesgo se d efinen de la siguiente m anera: F a lta d e fo rm a c ió n DE 80% 3

en las h e rra m ie n ta s
• riesgo de rendimiento: el grado de incertidum brecon P e rs o n a ls in e x p e rie n c ia ST 30% 2
el que el p roducto encontrará sus requisitos y se ade- H a b rá m u c h o s c a m b io s ST 60% 2
cue p ara su em pleo pretendido; d e p e rs o n a l
■ riesgo de coste: el grado de in certidum bre que m an

tendrá el presupuesto del proyecto; V a lo re s d e im p a c to :
1 - c a ta s tró fic o 2 -c r ít ic o
• riesgo de soporte: el g rad o de in certid u m b re de la 3 - m a r g in a l 4 -d e s p r e c ia b le
facilidad del so ftw are p ara co rreg irse, ad ap tarse y FIGURA 6.2. Ejemplo de una tabla de riesgo antes
ser m ejorado; de la clasificación.
PR O Y EC C IÓ N DEL RIES.G.Q
Laproyeccióndel riesgo, tam b ién d enom inada estima del riesgo e n el proyecto y en el producto, y (4)a pun-
ción del riesgo, intenta m ed ir cada riesgo de dos m an e tar la exactitud general de la proyección del riesgo de
ras — la p ro b a b ilid a d de que el rie sg o sea real y las m anera que n o h ay a confusiones.
consecuencias de los p roblem as asociados con el rie s
go, si ocurriera— . El je fe del proyecto, ju n to con otros
gestores y p ersonal técnico, realiza cu atro actividades 6.4.1. D e s a rro llo d e u n a t a b l a d e r ie s g o
de proyección del riesgo [1 ]: (1) establecer una escala U na tabla de riesgo le proporciona alj efe del proyecto una
que refleje la pro b ab ilid ad p ercib id a del riesgo; (2) defi sencilla técnica para la proyección del riesgo'. E n la Figu
nir las co nsecuencias del riesgo; (3) estim ar el im pacto ra 6.2 se ilustra una tabla de riesgo com o ejem plo.
www.FreeLibros.org
2 La tabla de riesgo debería im plem entarse com o un m odelo de hoja
de cálculo. Esto permite un fácil m anejo y ordenación de las en tra
das.
101
I N GE NI E RI A DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
Un equipo de proyecto empieza por listar todos los Una vez que se han com pletado las cuatro primeras
riesgos (no importa lo remotos que sean) en la primera columnas de la tabla de riesgo, la tabla es ordenada por
columna de la tabla. Se puede hacer con la ayuda de la probabilidad y por impacto. Los riesgos de alta proba
lista de com probación de elementos de riesgo presen bilidad y de alto impacto pasan a lo alto de la tabla, y
tada en la Sección 6.3. Cada riesgo es categorizado en los riesgos de baja probabilidad caen a la parte de aba
la segunda columna (por ejemplo: PS implica un ries jo . Esto consigue una priorización del riesgo de primer
go del tam año del proyecto, BU implica un riesgo de orden.
negocio). La probabilidad de aparición de cada riesgo El je fe del proyecto estudia la tabla ordenada resul
se introduce en la siguiente columna de la tabla. El valor tante y define una línea de corte. L a Einea de corte (dibu-
de la probabilidad de cada riesgo puede estimarse por jad a horizontalm entedesde un punto en la tabla) implica
cada miem bro del equipo individualmente. Se sondea que sólo a los riesgos que quedan por encima de la línea
a los m iem bros del equipo individualmente de un m odo se les prestará atención en adelante. Los riesgos que
rotativo (round-robin) hasta que comience a converger caen por debajo de la línea son reevaluados para con
su evaluación sobre la probabilidad del riesgo. seguir una priorización de segundo orden. Como mues
tra la Figura 6.3, el impacto del riesgo y la probabilidad
tienen diferente influencia en la gestión. Un factor de
riesgo que tenga un gran im pacto pero muy poca pro
babilidad de que ocurra no debería absorber una canti
dad significativade tiem po de gestión. Sin embargo, los
riesgos de gran impacto con una probabilidad moderada
a alta y los riesgos de poco im pacto pero de gran pro
babilidad deberían tenerse en cuenta en los procedi
mientos de análisis de riesgos que se estudian a conti
nuación.
8®
C LA VE
I a tabla de riesgos está ordenada por probabilidad
y por el Impacto para asignar una prioridad a los riesgos.
Todos los riesgos que se encuentran por encima de

la línea de corte deben ser considerados. La columna
etiquetada RSGR* contiene una referencia que apunta
hacia un Plan de reducción, supervisión y gestión del
riesgo, o alternativamente, a un informe del riesgo desa
rrollado para todos los riesgos que se encuentran por
encima de la línea de corte. El plan RSGR y el informe
F IG U R A 6.3. Riesgosy relevancia para la gestión.
del riesgo se estudian en la Sección 6.5.
A continuación se valora el impacto de cada riesgo.

Cada componente de riesgo se valora usando la carac Qcita:
terización presentada en la Figura 6.1, y se determina 8 fracasoenlapreparaciónestápreparando falla
una categoría de impacto. Las categorías para cada uno Bm f ranklm.
de los cuatro com ponentes de riesgo — rendimiento,
soporte, coste y planificación temporal — son prom e La probabilidad de riesgo puede determinarse hacien
diados3 para determinar un valor general de impacto. do estim aciones individuales y desarrollando después
un único valor de consenso. Aunque este enfoque es fac
tible, se han desarrollado técnicas m ás sofisticadas para
^ C Q N S E J o fy
determ inar la probabilidad de riesgo [AFC88]. Los con
Piense seriamente en elsoftwore que está construyendo troladores de riesgo pueden valorarse en una escala de
y pregúntesea si mismo «¿Qué puede ir mal?» Cree su probabilidad cualitativa que tiene los siguientes valo
propio listo y consulte a otros miembros del equipo de res: im posible, improbable, probable y frecuente. D es
software para hacer lo mismo. pués puede asociarse una probabilidad m atem ática con
www.FreeLibros.org
3 Puede usarse una m edia ponderada si un com ponente de riesgo ' En inglés RM M M (Risk Mitigation, Monitoring and M anagem ent).
tiene m ás influencia en el proyecto.
102
CA P Í T U L O 6 A N Á LI S IS Y G E S T I Ó N DEL R I E S G O
cada valor cualitativo (por ejem plo: una probabilidad desarrollo). Puesto que la m edia por componente es
del 0.7 al 1.0 im plica un riesgo muy probable). de 100 LDC y los datos locales indican que el cos
te de la ingeniería del software para cada LDC es de
£14,00; el coste global (impacto) para el desarrollo
6.4.2. E v a lu a c ió n d e l im p a c to d e l r ie sg o
de componentes sería 18 x 100 x 14 = 225.200
Tres factores afectan a las consecuencias probables de
un riesgo si ocurre: su naturaleza, su alcance y cuando E xposición al riesgo : ER = 0,80 x 25.200 -
ocurre. La naturaleza del riesgo indica los problem as 220.200
probables que aparecerán si ocurre. Por ejem plo, una La exposición al riesgo se puede calcular para cada
interfaz externa m al definidapara el hardware del clien riesgo en la tabla de riesgos, una vez que se ha hecho
te (un riesgo técnico) im pedirá un diseño y pruebas tem una estim ación del coste del riesgo. La exposición al
pranas y probablemente lleve a problemas de integración riesgo total para todos los riesgos (sobre la línea de cor
más adelante en el proyecto. El alcance de un riesgo te en la tabla de riesgos) puede proporcionar un signifi
combina la severidad (¿cómo de serio es el problema?) cado para ajustar el coste final estimado para un proyecto.
con su distribución general (¿qué proporción del pro Tam bién puede ser usado para predecir el increm ento
yecto se verá afectado y cuantos clientes se verán per probable de recursos de plantilla necesarios para varios
judicados?). Finalmente, la tem porización de un riesgo puntos durante la planificación del proyecto.
considera cuándo y por cuánto tiem po se dejará sentir La proyección del riesgo y las técnicas de análisis
el impacto. En la m ayoría de los casos, un je fe de pro descritas en las Secciones 6.4.1 y 6.4.2 se aplican rei
yecto prefiere las «malas noticias» cuanto antes, pero teradam ente a medida que progresa el proyecto de soft
en algunos casos, cuanto m ás tarden, mejor. ware. El equipo del proyecto debería volver a la tabla
Volviendo una vez m ás al enfoque del análisis de de riesgos a intervalos regulares, volver a evaluar cada
riesgo propuesto por las Fuerzas Aéreas de Estados Uni riesgo para determ inar qué nuevas circunstancias hayan
dos [AFC88], se recom iendan los siguientes pasos para podido cambiar su im pacto o probabilidad. Com o con
determinar las consecuencias generales de un riesgo: secuencia de esta actividad, puede ser necesario añadir
1. Determinar la probabilidad m edia de que ocurra un nuevos riesgos a la tabla, quitar algunos que ya no sean
valor para cada componente de riesgo. relevantes y cam biar la posición relativa de otros.
2. Empleando la Figura 6.1, determ inar el impacto de
cada com ponente basándose en los criterios m o s ^ C T W S E fO ^
trados. Compare lo ER poro todos los riesgos con el coste estimado
3. Completar la tabla de riesgo y analizar los resulta delproyecto. SI lo ER es superior al 50 por lOOdelcoste
dos como se describe en las secciones precedentes. del proyecto, se deberá evaluar lo viabilidad delproyecta.
¿Cómo evaluamos las
§ consecuencias de un riesgo?
La exposición al riesgo en general, ER, se determ i

6.4.3. E v a lu a c ió n d e l r ie s g o
En este punto del proceso de gestión del riesgo, hemos
establecido un conjunto de tem as de la forma [CHA89]:
na utilizando la siguiente relación [FIAL98] : , h ,x ¡ 1
ER = P x C donde r (. es el riesgo, l¡ es la probabilidad del riesgo y
x¡ es el im pacto del riesgo. Durante la evaluación del
donde P es la probabilidad de que ocurra un riesgo, y
riesgo, se sigue examinando la exactitud de las estim a
C es el coste del proyecto si el riesgo ocurriera.
ciones que fueron hechas durante la proyección del ries
Por ejem plo, supongam os que el equipo del p ro go, se intenta dar prioridades a los riesgos que no se
yecto define un riesgo para el proyecto de la siguien habían cubierto y se em pieza a pensar las m aneras de
te manera: controlar y/o im pedir los riesgos que sea m ás probable
Identificación del riesgo : Solo el 70 por 100 de que aparezcan.
los componentes del software planificados para reu- Para que sea útil la evaluación, se debe definir un nivel
tilizarlos pueden, de hecho, integrarse en la aplica de referencia de riesgo [CHA89], Para la m ayoría de los
ción. La funcionalidad restante ten drá que ser proyectos, los componentes de riesgo estudiados ante
desarrollada de un m odo personalizado. riormente — rendimiento,coste, soporte y planificación
t e m p o r a l - tam bién representan niveles de referencia
Probabilidad del riesgo :80 por 100 (probable). de riesgos. Es decir, hay un nivel para la degradación del
Impacto del riesgo : 60 com ponentesde software rendim iento, exceso de coste, dificultades de soporte o
reutilizables fueron planificados. Si solo el 70 por retrasos de la planificación tem poral (o cualquier com
www.FreeLibros.org
100 pueden usarse, 18 com ponentes tendrán que binación de los cuatro) que provoquen que se term ine el
desarrollarse improvisadamente (además de otro soft proyecto. Si una com binación de riesgos crea problemas
ware personalizado que ha sido planificado para su de m anera que uno o m ás de estos niveles de referencia
103
I N G E N IE RÍ A DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
se excedan, se p arará el trabajo. E n el contexto del aná

lisis de riesgos del softw are, un nivel de referencia de
riesgo tiene un solo punto, denom inado pun to de re fe \ avm
ren cia o pun to de ruptura, en el que la decisión de seguir B nivel de referencia del riesgo establece su tolerancia para
con el proyecto o dejarlo (los p roblem as son dem asiado el sufrimiento. Una vez que la exposición al riesgo supera el
graves) son igualm ente aceptables. L a F igura 6.4 rep re nivel de referencia, el proyecto puede ser terminodo.
senta esta situación gráficam ente.
En realidad, el nivel de referencia puede raram ente
representarse com o u n a línea n ítida en el gráfico. En la
m ayoría de los casos es u n a región en la que hay áreas
de incertidum bre, es decir, intentar p redecir u n a deci
sión de gestión basándose en la com binación de valo
res de re fe re n c ia es a m e n u d o im p o sib le . P o r tanto,
durante la evaluación del riesgo, se realizan los siguien
tes pasos:
1 . D efin ir los n iv eles de re fe re n c ia de rie sg o para el
proyecto;
2. Intentar desarrollar una relación entre cad a (r¡ , l¡, x¡)
y cada uno de los niveles de referencia;
3. P redecir el conjunto de puntos de referencia que defi
nan la región de abandono, lim itado p o r un a curva o
áreas de incertidum bre;
4. Intentar p redecir com o afectarán las com binaciones
com puestas de riesgos a un nivel de referencia.
E xceso en e l c o s te p re v is to E s m ejo r dejar u n estudio m ás detallado para libros

esp ec ia lizad o s en el an álisis de riesgos (por ejem plo:
F IG U R A 6 .4 . Nivel de referencia de riesgo. [C H A 89], [RO W 88]).
6.5..R£nifAMl£ííT.QJÊI.ÜIESGQ__
D urante las p rim eras etapas de la planificación del en el sistem a que se está construyendo, teniendo com o
proyecto, un riesgo puede ser declarado de un m odo muy resultado la necesidad de que el ingeniero tenga que cons
general. C o n el p aso del tiem p o y co n el ap rendizaje tru ir el 30 p o r 100 de los com ponentes restantes.
sobre el p royecto y sobre el riesgo, es p osible refinar el L a condición general que acabam os de destacar pue
riesgo en u n conjunto de riesgos m ás detallados, cada de ser refinada de la siguiente m anera:
uno algo m ás fácil de reducir, supervisar y gestionar. S ubcondición 1: C iertos com ponentes reutiliza-
bles fueron desarrollados p o r terceras personas sin el
¿Cuál es una buena forma conocim iento de los estándares internos de diseño.
W de describir un riesgo?
S ubcondición2: El estándar de diseño para inter
U n a fo rm a de h a c e r e sto es p re se n ta r el rie sg o de faces de com ponentes no h a sido asentado y puede
la fo rm a c o n d íc íó n -tr a n s íc íó n -c o n s e c u e n c ía (C T C ) no ajustarse a ciertos com ponentes reutilizablesexis-
[G L U 94], E s decir, el rie sg o se p resenta de la sig u ie n tentes.
te fo rm a : S ub co n d ició n 3: C iertos com ponentes reutiliza-
D ad a esta < co n d ició n > entonces existe p reocupación bles h a n sido im p le m e n ta d o s en un le n g u a je no
p o r (posiblem ente) < consecuencia>. so portado p o r el en to rn o para el que el sistem a ha
sido construido.
Utilizando el form ato CTC para volver a utilizar el ries
go presentado en la Sección 6.4.2, podem os escribir: Las consecuencias relacionadas con estas subcondi-
Dado que todos los com ponentesreutilizablesdel soft ciones refinadas siguen siendo las m ism as (por ejem plo,
w are deben ajustarse a los estándares específicos del dise el 30 p o r 100 de los com ponentes del softw are deben ser
www.FreeLibros.org
ñ o y que algunos no lo hacen, es entonces preocupante construidos de un m odo personalizado), pero el refin a
que (posiblem ente) solo el 70 p o r 100 de los m ódulos m iento ayuda a aislar los riesgos señalados y puede con
planificados p ara reu tilizar puedan realm ente integrarse ducir a un análisis y respuesta m ás sencilla.
104
CAPÍTULO 6 A N Á LI S IS Y G E S T I Ó N DEL RIES GO
Todas las actividades de análisis de riesgo presentadas y ecto supervisa factores que pueden p roporcionar una
hasta ahora tienen un solo objetivo - a y u d a r al equipo in d ic a c ió n so bre si el rie sg o se e stá h a c ie n d o m á s o
del proyecto a desarrollar una estrategia para tratar los m enos probable. E n el caso de gran m ovilidad del p e r
riesgos—. U na estrategia eficaz debe considerar tres sonal, se pueden supervisar los siguientes factores:
aspectos: • A ctitud general de los m iem bros del eq uipo b asán
• Evitar el riesgo. dose en las presiones del proyecto;
• Supervisar el riesgo, y ■ G rado de com penetración del equipo;
• Gestionar el riesgo y planes de contingencia. • R elaciones in te rp erso n ale s entre los m iem b ro s del
equipo;
. P roblem as potenciales con com pensaciones y b e n e
ficios;
Si ton» tantos precauciones, es paro no dejor
■ D isponibilidad de em pleo dentro y fu era de la c o m
pañía.
Si un equipo de software adopta un enfoque proac

tivo frente al riesgo, evitarlo es siempre la m ejor estra itó fe preparadosparauneventoimprevisto
tegia. Esto se consigue desarrollando un plan de {fuepuedeocurrir ono.
reducción del riesgo. P or ejem plo, asum a que se ha
detectado mucha m ovilidad de la plantilla como un ries
go del proyecto, r¡. Basándose en casos anteriores y en
A dem ás de supervisar los facto res apuntados ante
la intuición de gestión, la probabilidad, de m ucha riorm ente, el je f e del proyecto debería supervisar tam
movilidad se estim a en un 0,70 (70 por 100, bastante
bién la efectividad de los pasos de reducción del riesgo.
alto)y el impacto, x¡, está previsto en el nivel 2. Esto P or ejem plo, u n paso de reducción de riesgo apuntado
es, un gran cambio puede tener un impacto crítico en el anteriorm ente instaba a la definición de «estándares de
coste y planificación tem poral del proyecto. docum entación y m ecanism os para asegurarse de que
Para reducir el riesgo, la gestión del proyecto debe los docum entos se cum plim enten puntualm ente». E ste
desarrollar una estrategia para reducir la m ovilidad.
es un m ecanism o para asegurarse la co n tinuidad,en caso
Entre los pasos que se pueden tomar:
de que u n in d iv id u o crítico ab andone el p royecto. E l
• Reunirse con la plantilla actual y determinar las causas je f e del p ro y e cto d eb e ría c o m p ro b a r los do cu m en to s
de la movilidad (por ejemplo: malas condiciones de tra cuidadosam ente para asegurarse de que son válidos y
bajo, salarios bajos, mercado laboral competitivo). de que cada uno contiene la inform ación necesaria en
• Actuar para reducir esas causas que estén al alcance caso de que un m iem bro nuevo se viera obligado a u n ir
de nuestro control antes de que comience el proyecto. se al eq uipo de softw are a m itad del proyecto.
• Una vez que com ienza el proyecto, asumir que habrá L a g estió n del riesgo y los p la n e s de co ntingencia
movilidad y desarrollar técnicas que aseguren la con asum en que los esfuerzos de reducción han fracasado y
tinuidad cuando se vaya la gente. que el riesgo se ha' convertido en una realidad. C onti
nuando con el ejem plo, el proyecto va m uy retrasado y
• Organizar los equipos del proyecto de m anera que
un núm ero de personas anuncia que se va. Si se h a segui
la inform ación sobre cada actividad de desarrollo
do la estrategia de reducción, tendrem os copias de segu
esté am pliamente dispersa.
ridad disponibles, la inform ación está d o c u m en tad a y
• Definir estándares de docum entación y establecer el conocim iento del proyecto se h a d isp ersad o p o r todo
mecanismos para estar seguro de que los docum en el equipo. A dem ás, el je fe del proyecto puede te m p o
tos se cum plimentan puntualmente. ralm ente vo lv er a reasignar los recursos (y re a ju sta r la
planificación tem poral del proyecto) desde las fu n c io
nes que tienen todo su personal, perm itiendo a los recién
Referencia llegados que deben unirse al equipo que vayan «co gien
d o el ritm o». A los individuos que se van se les p id e que
Se puede obtener uno excelente CPF (cuestiones que
d e je n lo que e sté n h a c ie n d o y d ed iq u en su s ú ltim a s
se preguntan frecuentemente) en
www.sei.cmu.edu/organization/programs/
sem anas a «transferir sus conocim ientos». E sto p o d ría
sepm/risk/risk.faq.html in c lu ir la adquisición de conocim ientos p o r m e d io de
www.FreeLibros.org
vídeos, el desarrollo de «docum entos con com entarios»
A medida que progresa el proyecto, com ienzan las y/o reuniones con otros m iem bros del equipo que p er
actividades de supervisión del riesgo. El je fe del pro m anezcan en el proyecto.
105
5 por 100 y de la duración en un 3 por 100, la gestión

probablem ente lo haga.
Si el rnloi poro un riesgo específico es m ena que el coste
Para un proyecto grande se pueden identificar unos
de lo reducción de/riesgo, notrote de reducir el riesgo 30 ó 40 riesgos. Si se pueden identificar entre tres y
pero continúe supervisándolo. siete pasos de gestión de riesgo para cada uno, ¡la ges
tión del riesgo puede convertirse en un proyecto por
Es im portante advertir que los pasos RSG R provo sí misma! Por este motivo, adaptamos la regla de Pare-
can aum entos del coste del proyecto. Por ejem plo, to 80/20 al riesgo del softw are. La experiencia dice
em plear tiem po en conseguir «un reserva» de cada téc que el 80 por 100 del riesgo total de un proyecto (por
nico crítico cuesta dinero. Parte de la gestión de riesgos ejemplo: el 80 por 100 de la probabilidad de fracaso
es evaluar cuando los beneficios obtenidos por los pasos del proyecto) se debe solam ente al 20 por 100 de los
RSG R superan los costes asociados con su implemen- riesgos identificados. El trabajo realizado durante pro
tación. En esencia, quien planifique el proyecto realiza cesos de análisis de riesgo anteriores ayudará al jefe
el clásico análisis coste/beneficio. Si los procedim ien de proyecto a determ inar q u é riesgos pertenecen a ese
tos para evitar el riesgo de gran m ovilidad aumentan el 20 por 100 (por ejem plo, riesgos que conducen a una
coste y duración del proyecto aproximadamente en un exposición al riesgo alta). Por este m otivo, algunos
15 por 100, pero el factor coste principal es la «copia de los riesgos identificados, valorados y previstos pue
de seguridad», el gestor puede decidir no im plem entar den no pasar por el plan R SG R —no pertenecen al 20
este paso. Por otra parte si los pasos para evitar el ries por 1OO crítico— (los riesgos con la m ayor prioridad
go llevan a una proyección de un aumento de costes del del proyecto).
. B.7 R I E S G O S Y PELIGROS PARA LA SEGURIDAD

El riesgo no se limita al proyecto de software solamente.
Pueden aparecer riesgos después de haber desarrollado Hoja de información d e riesgo
con éxito el software y de haberlo entregado al cliente.
Id. R ie s g o : P 0 2 -4 -3 2 fe c h a : 5 /9 /0 2 P ro b a b ilid a d : 8 0 % Im p a c to : a lto
Estos riesgos están típicamente asociados con las conse
cuencias del fallo del software una vez en el mercado. Descripción :
S ólo el 7 0 p o r 1 0 O d e los c o m p o n e n te s d e l s o ftw a re p la n ific a d o s
En los comienzos de la informática, había un recha p a ra re u tiliza r p u e d e n , d e h e ch o , in te g ra rs e e n la a p lic a c ió n .
zo al uso de las com putadoras (y del software) para el á fu n c io n a lid a d re s ta n te te n d rá q u e d e s a rro lla rs e
control de procesos críticos de seguridad como por ejem de un m o d o p e rs o n a liz a d o .
plo reactores nucleares, control de vuelos de aviones, Ftefinamiento/contexto:

sistemas de armamento y grandes procesos industria S u b c o n d ic ió n 1: C ie rto s c o m p o n e n te s re u tiliza b le s fu e ro n d e s a rro lla d o s
p o r te rc e ra s p e rs o n a s sin el c o n o c im ie n to
les. Aunque la probabilidad de fallo de un sistema de d e los e s ta n d a re s in te rn o s d e d is e ñ o .
alta ingeniería es pequeña, un defecto no detectado en S u b c o n d ic ió n 2: El e s tá n d a r d e d is e ñ o p a ra in te rfa c e s d e c o m p o n e n te s
un sistem a de control y supervisión basados en com n o h a s id o a s e n ta d o y p u e d e n o a ju s ta rs e a c ie rto s
c o m p o n e n te s re u tiliza b le s e x is te n te s .
putadora podría provocar unas pérdidas económ icas
S u b c o n d ic ió n 3: C ie rto s c o m p o n e n te s re u tiliza b le s h a n s id o im p le m e n ta d o s
enormes o, peor, daños físicos significativos o pérdida e n un le n g u a je n o s o p o rta d o p o r el e n to rn o p a ra el q u e
de vidas humanas. Pero el coste y beneficios funciona el s is te m a ha s id o c o n s tru id o .
les del control y supervisión basados en com putadora a Reducción/Supervisión:
m enudo superan al riesgo. Hoy en día, se emplean regu 1. C o n ta c ta r c o n te rc e ra s p e rs o n a s p a ra d e te rm in a r
la c o n fo rm id a d con los e s tá n d a re s d e d is e ñ o .
larmente hardware y software para el control de siste 2. P re s io n a r p a ra c o m p le ta r lo s e s tá n d a re s d e la interfaz;
mas de seguridad crítica. c o n s id e ra r la e s tru c tu ra d e c o m p o n e n te s c u a n d o s e d e c id e
Cuando se em plea software como parte de un siste el p ro to c o lo d e la in te rfa z.
3. C o m p ro b a c ió n p a ra d e te rm in a r los c o m p o n e n te s e n la
ma de control, la complejidadpuede aum entar del orden c a te g o ria d e s u b c o n d ic ió n 3; c o m p ro b a c ió n p a ra d e te rm in a r
de una magnitud o más. Defectos sutiles de diseño indu si se p u e d e a d q u irir el s o p o rte d e l le n g u a je
cidos por error hum ano — algo que puede descubrirse Gestión/Plan de Contingencia/Acción:
y eliminarse con controles convencionales basados en Se c a lc u la q u e la ER es d e £ 2 0 ,2 0 0 . E sta c a n tid a d se c o lo c a d e n tro d e l c o ste
l e c o n tin g e n c ia d e l p ro y e c to . La p la n ific a c ió n d e l p ro y e c to re v is a d o a s u m e
hardware — se convierten en m ucho m ás difíciles de iu e s e te n d rá n q u e c o n s tru ir 18 c o m p o n e n te s a d ic io n a le s ; p o r c o n s ig u ie n te
descubrir cuando se em plea software. se a s ig n a rá e l p e rs o n a l d e a c u e rd o c o n las n e c e s id a d e s .
A cción: L a s fa s e s d e re d u c c ió n s e lle v a rá n a c a b o a p a rtir d e 7 /1 /0 2
Estado actual:
■ f 5/12/02: F a s e s d e re d u c c ió n in iciad as.
SsSMBBBBÜáÉshJ
www.FreeLibros.org
Autor: J o h n G a g n e Asignado: B. L a s te r
Se puedeencontrar unagran base de datos contodos las
entradas del ForoACMsobre riesgosen
catless.nd.ac.uk/Risks/search.html F IG U R A 6 .5 . Hoja de inform ación de riesgo [W IL97]
106
La seguridad del software y el análisis del p elig ro falle el sistem a entero. Si se pueden id en tificar los
son actividades para g arantizar la calidad del so ft p elig ro s al p rin cip io del proceso de in g en iería del
ware (Capítulo 8) que se centra en la identificación software, se pueden especificar características de dise
y evaluación de p elig ro s p o ten cia le s que pueden ño softw are que elim inen o controlen esos peligros
impactar al softw are negativam ente y provocar que potenciales.
ÜilL&JSL PLAM.BjSjGUL
Se puede incluir una estrategia de gestión de riesgo en el que la creación y entrada de información, ordenación
plan del proyecto de software o se podrían organizar los por prioridad, búsquedas y otros análisis pueden ser rea
pasos de gestión del riesgo en un Plan diferente de reduc lizados con facilidad.. El form ato de la H IR se muestra
ción, supervisióny gestión del riesgo (Plan RSGR). Todos en la Figura 6.5.
los documentos del plan RSG R se llevan a cabo com o Una vez que se ha desarrollado el plan RSG R y el
parte del análisis de riesgo y son empleados por el jefe proyecto ha comenzado, em piezan los procedim ientos
del proyecto como parte del Plan del Proyecto general. de reducción y supervisión del riesgo. Com o ya hemos
dicho antes, la reducción del riesgo es una actividad para
evitar problemas. La supervisión del riesgo es una acti
vidad de seguim iento del proyecto con tres objetivos
principales: (1) evaluar cuando un riesgo previsto ocu
rre de hecho; (2) asegurarse de que los procedim ientos
para reducir el riesgo definidos para el riesgo en cues
Plan RSGR tión se están aplicando apropiadamente; y (3) recoger
inform ación que pueda emplearse en el futuro para ana
Algunos equipos de software no desarrollan un docu lizar riesgos. En m uchos casos, los problem as que ocu
mento RSGR formal. M ás bien, cada riesgo se docu rren durante un proyecto pueden afectar a m ás de un
menta utilizando una hoja de inform ación de riesgo riesgo. Otro trabajo de la supervisión de riesgos es inten
(HIR) [WIL97], En la m ayoría de los casos, la HZR se tar determ inar el origen -qué riesgo(s) ocasionaron tal
mantiene utilizando un sistema de base de datos, por lo problem a a lo largo de todo el proyecto - .
Cuando se pone mucho enjuego en un proyecto de soft El análisis de riesgos puede absorber una cantidad
wate el sentido com ún nos aconseja realizar un análisis significativa del esfuerzo de planificación del proyec
cb riesgo. Y sin embargo, la m ayoría de los jefes de pro to. Pero el esfuerzo m erece la pena. Por citar a Sun Tzu,
yecto lo hacen informal y superficialm ente,si es que lo un general chino que vivió hace 2.500 añ o s,« Si cono
hacen El tiempo invertido identificando, analizando y ces al enem igo y te conoces a ti mismo, no tendrás que
gestionando el riesgo m erece la pena por m uchas razo tem er el resultado de cien batallas». Para el je fe de pro
nes: menos trastornos durante el proyecto, una mayor habi yectos de software, el enemigo es el riesgo.
lidad de seguir y controlar el proyecto y la confianza que
da planificar los problemas antes de que ocurran.
[AFC88] Software Risk Ahatement, AFCS/AFLC Pamphlet [DRU75] Drucker, P., M anagement, W. Heinemann, Ltd.,
800-45,U.S. Air Forcé, 30 de Septiembre 1988. 1975.
[BOE89] Boehm, B. W., Software Risk Management, IEEE [GIL88] Gilb, T.,Principies cf Software Engineering Mana
Computes Society Press, 1989. gement, Addison-Wesley, 1988.
[CHA89] Charette, R. N., Software Engineering Risk Analy- [GLU94] Gluch, D.P., «A Construct for Describing Softwa
sis and Management, McGraw-Hill/Intertext, 1989. re Development Risk», C M U /SEI-94-TR -14, Software
www.FreeLibros.org
Engineering Institute, 1994.
[CHA92] Charette,R. N., «BuildingBridgesOverlntelligent
Rivers », American Programmer, vol. 5, n.s 7, Septiem [HAL98] Hall, E. M .,M anaging Risk:Methods fo r Software
bre 1992,pp. 2-9. Systems Development, Addison Wesley, 1998.
107
IN GE NIE RÍA DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
[HIG95] Higuera, R.P, «Team Risk Management», CrossTalk, [ROW88] Rowe, W. D., An Anatomy ofRisk, Robert E. Krie-
US Dept. of Defense, Enero 1995,pp. 2-4. ger Publishing Co., Malabar, FL, 1988.
[KAR96] Karolak, D.W., Software Engineering Risk Mana [SEI93] Taxonomy-BasedRisk Identification, Software Engi
gement, IEEE Computer Society Press, 1996. neering Institute, CMU/SEI-93-TR-6, 1993.
[TH092] Thomsett, R., «The Indiana Jones School of Risk
[KEI98] Keil, M. et al., «A Framework for Identifying Soft
Management», American Programmer, vol. 5, n.° 7, Sep
ware Project Risks», CACM, vol 41, n,el l , Noviembre
tiembre 1992, pp. 10-18.
1998,pp.'76-83.
[WIL97] Williams, R.C., J.A.Walker y A.J. Dorofee, «Put-
[LEV95] Leveson, N. G., Safeware: System Safety and Com ting Risk Management into Practice», IE E E Software,
putes, Adisson-Wesley, 1995. Mayo 1997,pp. 75-81.
6.1. Proporcione cinco ejemplos de otros campos que ilustren 6.8. Desarrolle una estrategia de supervisión del riesgo y sus acti
los problemas asociados con una estrategia reactiva frente al vidades específicaspara tres de los riesgos señalados en la Figu
riesgo. ra 6.2. Asegúrese de identificar los factores que va a supervisar
para determinar si el riesgo se hace más o menos probable.
6.2. Describa la diferencia entre «riesgos conocidos» y «ries
gos predecibles». 6.9. Desarrolle una estrategia de gestión del riesgo y sus acti
vidades específicas para tres de los riesgos señalados en la
6.3. Añada tres cuestiones o temas a cada una de las listas de
Figura 6.2.
comprobación de elementos de riesgo que se presentan en el
sitio web SEPA. 6.10. Trate de refinar tres de los riesgos señalados en la figura
6.2 y realice las hojas de informacióndel riesgo para cada uno.
6.4. Se le ha pedido que construya un software que soporte un
sistema de edición de vídeo de bajo coste. El sistema acepta 6.11. Represente 3 de los riesgos señalados en la figura 6.2 uti
cintas de vídeo como entrada de información, almacena el lizando el formato CTC.
vídeo en disco, y después permite al usuario realizar un amplio
6.12. Vuelva a calcular la exposición al riesgo tratada en la
abanico de opciones de edición al vídeo digitalizado. El resul
Sección 6.4.2 donde el coste/LDC es £16 y la probabilidad es
tado (salida) se envía a una cinta. Realice una pequeña inves
del 60 por 100.
tigación sobre sistemas de este tipo, y después haga una lista
de riesgos tecnológicos a los que se enfrentaría al comenzar 6.13. ¿Se le ocurre alguna situación en la que un riesgo de alta
un proyecto de este tipo. probabilidad y gran impacto no formará parte de su plan
RSGR?
6.5. Usted es el je fe de proyectos de una gran compañía de
software. Se le ha pedido que dirija a un equipo que está 6.14. Respecto a la referencia de riesgo mostrada en la Figu
desarrollando un software de un procesador de textos de ra 6.4, ¿será siempre la curva un arco simétrico como el que
«nueva generación» (ver Sección 3.4.2 para obtener una bre aparece, o habrá situaciones en las que la curva esté más dis
ve descripción). Construya una tabla de riesgo para el pro torsionada? Si es así, sugiera un escenario en el que esto pue
yecto. da ocurrir.
6.6. Describa la diferenciaentre componentes de riesgo y con 6.15. Realice una investigación sobre aspectos de seguridad
troladores de riesgo. del software y escriba una pequeña redacción sobre el tema.
Desarrolle un buscador web para obtener información actual.
6.7. Desarrolle una estrategia de reducción del riesgo y sus
actividades específicas para tres de los riesgos señalados en la 6.16. Describa cinco áreas de aplicación de softwareen las que
Figura 6.2. la seguridad del software y el análisis de riesgo sean vitales.
Las lecturas sobre la gestión del riesgo del software se han Chapman, C.B., y S. Ward. Project Risk Management:
expandido significativamente en los Últimos años. Hall Processes, TechniquesandInsights, Wiley, 1997.
[HAL98] presenta uno de los tratados más completos del tema. Schuyler, J. R., Decisión Analysis in Projects, Project
Karolak [KAR96] ha escrito una guía que introduce un mode Management Institute Publications, 1997.
lo de análisis del riesgo fácil de usar con listas de compro
bación y cuestionarios que merece la pena. Grey ha realizado Wideman,R. M. (editor). Project & Program Risk Mana
una instantánea de la evaluación del riesgo (Practical Risk gement: A Guide to Managing Project Risk and Opportuni-
www.FreeLibros.org
Assessmentfor Project Management, Wiley, 1995). Su trata ties, Project Management Institute Publications, 1998.
do abreviado proporciona una buena introducción al tema. Capers Jones (Assesment and Control d Software Risks,
Otros libros que merecen la pena son: Prentice-Hall, 1994)presenta un detallado estudio sobre ries
108
CAPÍTULO 6 A NÁ LI SI S Y G ES TI Ó N DEL R I E S G O
gos del software que incluye información reunida de cientos Los tratados de Marzo 1995 de American Programmer,
ds proyectos de software. Jones define 60 factores de riesgo Mayo 1997 de IEEE Software, y Junio 1998 Cutter IT Jour
que pueden afectar al resultado de los proyectos de softwa nal están dedicados a la gestión del riesgo.
re Boehm [BOE89] sugiere unos excelentes cuestionarios y El Instituto de Ingeniería del Software ha publicado muchos
formatos de listas de comprobación que pueden resultar de informes y guías detallados sobre el análisis y gestión del ries
valor incalculable a la hora de identificar riesgos. Charrette go. El Air Forcé Systems Command Pamphlet AFSCP 800-45
[CHA89] presenta un detallado tratado de los mecanismos de [AFC88] describe técnicas de identificación y reducción de
análisis de riesgo, recurriendo a la teoría de probabilidades y riesgos. Todos los números de ACM Software Engineering
técnicas estadísticas para analizar riesgos. En un volumen Notes publican una sección titulada «Riesgos para el público»
adjunto, Charette (Application Strategies fo r RiskAnafysis, (editor, P. G. Neumann). Si quiere las últimas y mejores his
McGrawHill, 1990) analiza el riesgo en el contexto tanto del torias de horror de software, éste es el lugar adonde ir.
sistema como de la ingeniería del software y define unas estra En Internet están disponibles una gran variedad de fuen
tegias pragmáticas para la gestión del riesgo. Gilb [GIL88] tes de información relacionadas con temas de análisis y ges
presenta un conjunto de «principios» (que son a menudo diver- tión del riesgo. Se puede encontrar una lista actualizada con
tidosy algunas veces profundos) que pueden servir como una referencias a sitios (páginas) web que son relevantes para el
FU directriz para la gestión del riesgo. riesgo en http://www.pressman5.com.
www.FreeLibros.org
P L A N IF IC A C IÓ N T E M P O R A L
Y S E G U IM IE N T O D EL P R O Y E C T O
finales de los años 60, un joven y brillante ingeniero fue elegido para «escribir» un pro
A gram a de com putadora para una aplicación de fabricación automática. El m otivo para
su selección fue sencillo. Era la única persona de su grupo técnico que había asistido
a un seminario de programación de computadoras. Sabía todo sobre el lenguaje ensam blador y
Fortran, pero nada sobre ingeniería del software y mucho m enos sobre la planificación tem po
ral y seguimiento del proyecto.
Su jefe le dio los manuales adecuados y una descripción verbal de lo que tenía que hacer. Se
le informó de que el proyecto debía term inarse en dos meses.
Leyó los manuales, consideró su enfoque y empezó a escribir código. Después de dos sem a
nas de trabajo, el jefe le llamó a su oficina y le preguntó qué tal iban las cosas.
«Muy bien», dijo el joven ingeniero con entusiasm o juvenil, «es más fácil de lo que p en
saba. He terminado cerca del 75 por 100».
El jefe sonrió. «Es realmente estupendo», dijo, alentando al joven ingeniero a que siguiera
trabajando del mismo modo. Acordaron que se reunirían otra vez en una semana.
U na sem ana más tarde el jefe llamó al ingeniero a su oficina y le preguntó: «¿Por dónde
vamos?»
«Todo va muy bien», dijo el joven, «pero me he encontrado con unos pequeños obstáculos.
Los solucionaré y volveré al ritmo de trabajo pronto.»
«¿Cómo ves las fechas límite de entrega?», preguntó el jefe.
«No hay problema», dijo el ingeniero, «estoy cerca de term inar el 90 por 100».
Si ha estado trabajando en el mundo del software durante algunos años, sabrá el final de la his
toria. No es una sorpresa que el joven ingeniero1se estancara en el 90 por 100 durante el resto del
proyecto y que terminara (con la ayuda de otros) con un mes de retraso.
Esta historia se ha repetido docenas de miles de veces con los desarrolladores de software
durante las últimas tres décadas. La gran pregunta es ¿por qué?
VISTAZO RÁPIDO
¿Qué es? Usted ha seleccionado un mode lizan la información solicitada a los truir. El esfuerzo y la duración se asig
lo de proceso adecuado, ha identificado ingenieros de software. A nivel indivi na a cada tarea y se crea una red de
las tareas de ingeniería del software dual, los mismos ingenieros de soft tareas (también llamada red de activi
que hay que llevar a cabo, ha estimado ware. dades) que permita al equipo de soft
la cantidad de trabajo y el número de ¿P or q u é e s im p ortan te? Para cons ware conseguir la fecha límite de
personas necesario, conoce las fechas truir un sistem a complejo, muchas entrega establecida.
límite de entrega e incluso ha conside tareas de ingeniería del software se ¿C uál e s e l p rod u cto o b ten id o ? Se
rado los riesgos. Ahora es el momento realizan en paralelo y el resultado del obtiene la planificación del proyecto e
de unir todos los puntos. Esto es, tiene trabajo desarrollado durante una tarea información relacionada.
que crear una red de tareas de ingenie puede tener un gran efecto en el tra ¿Cómo p u e d o a s e g u r a r q u e lo h e
ría del software que le permitan conse bajo a realizar en otra tarea. Estas h ech o correcta m en te? Una plani
guir el trabajo realizado a tiempo. Una interdependencias son muy difíciles ficación adecuada requiere que (1)
vez creada la red, tiene que asignar la de comprender sin una planificación. todas las tareas aparezcan en la red;
responsabilidad para cada tarea, ase También es virtualm ente imposible (2) el esfuerzo y el tiempo s e asigne
gúrese de hacerlo y de adaptar la red evaluar el progreso en un proyecto de inteligentemente a cada tarea; (3) las
antes de que los riesgos se conviertan software normal o grande sin una pla relaciones entre tareas estén indica
en realidad. En resumidas cuentas, esto nificación detallada. das correctamente; (4) los recursos sean
es la planificación temporal y el segui ¿C uáles son lo s pasos? Las tareas de asignados al trabajo a realizar, y (5) los
miento del proyecto de software. ingeniería del software dictadas por el hitos se sitúen rigurosamente esp a
¿Quién lo hace? A nivel de proyecto, los modelo de proceso del software son ciados para que se pueda seguir el pro
gestores de proyectos de software, uti refinadas por la funcionalidad a cons greso.
www.FreeLibros.org 1 Si se pregunta si esta historia es autobiográfica, ¡lo es!
111
INGENIERÍA DEL SOFTWARE. UN ENFOQ UE PRÁCTICO
7.1 C O N C E P T O S BÁ SIC OS
Aunque hay muchas razones por las que el software se mentan a m enudo bajo la restricción de una fecha lími
entrega tarde, la mayoría pertenecen a una o más de las te definida. Si las mejores estim aciones indican que la
siguientes causas: fecha límite es poco realista, un gestor de proyecto com
• Una fecha límite de entrega poco realista, estable petente debería «proteger a su equipo de una presión
cida por alguien que no pertenece al grupo de inge [de la planificación temporal] innecesaria...[y] devol
niería del softw are e im puesta a los gestores y ver la presión a quienes la originaron» [PAG85].
profesionales del grupo.
• Cambio de los requisitos del cliente que no se refle
jan en los cambios de la planificación temporal. Adoro las fechas de entrega. Me gusta el sonido
• Una subestimación honesta de la cantidad de esfuerzo peculiar que emiten cuando se aproximan.
y/o el número de recursos que serán necesarios para Douglas Adams
hacer el trabajo.
• Riesgos predecibles y no predecibles que no se con Para ilustrarlo, imagínese que un grupo de desarro
sideraron cuando comenzó el proyecto. llo de software ha sido com isionado para construir un
• Dificultades técnicas que no pudieron ser previstas controlador de tiem po real para un instrumento médico
por adelantado. de diagnóstico que quiere introducirse en el mercado en
• Dificultades humanas que no pudieron ser previstas nueve meses. Después de una cuidadosa estimación y
por adelantado. análisis de riesgos, el gestor del proyecto de software
llega a la conclusión de que el software, tal y como se
• Falta de comunicación entre la plantilla del proyecto
ha pedido, requerirá 14 meses para crearlo con la plan
que causa retrasos.
tilla de la que se dispone. ¿Cómo debe proceder el jefe
• Falta de reconocimiento por parte de la gestión del del proyecto?
proyecto de su retraso y falta de medidas para corre Es poco realista ir a la oficina del cliente (en este
gir el problema. caso el cliente probable es mercadotecnia/ventas) y exi
girle que se cambie la fecha de entrega. Las presiones
externas del m ercado han dictado la fecha y el produc
Los planificaciones temporales irracionales to debe entregarse. También es absurdo rechazar el tra
o excesivas son probablemente la influencia bajo (desde el punto de vista de la carrera profesional).
mas destructiva en el software. Así pues, ¿qué hacer?
Capers Jones
^ ¿Qué deberíamos hacer
Las fechas límite de entrega agresivas (léase «poco • cuando la gestión exige
realistas»), son un hecho consum ado en el m undo del que cumplamos una fecha límite
software. Algunas veces estas fechas límite se piden por de entrega que es imposible?
motivos legítimos desde el punto de vista de la persona Se recomiendan los siguientes pasos en esta situación:
que las establece, pero el sentido común también dice que
1. R ealice una estim ación detallada usando informa
la legitim idad debe ser percibida por las personas que
ción de proyectos anteriores. Determ ine el esfuerzo
hacen el trabajo.
estim ado y la duración del proyecto.
2. Empleando un modelo de proceso incremental (Capí
7.1.1. C om entarios sobre los «retrasos»
tulo 2), establezca una estrategia de desarrollo que
N apoleón dijo una vez: «Un com andante en jefe que proporcione una funcionalidad crítica mínima para
acepta llevar a cabo un plan que considera defectuoso la fecha límite impuesta, pero deje otras funcionali
está com etiendo un error; debe exponer sus razones, dades para más tarde. Documente el plan.
insistir en cam biar el plan y finalm ente presentar su 3. Reúnase con el cliente y (empleando la estimación
dimisión antes de ser el instrumento de la destrucción detallada) explique por qué la fecha límite impuesta
de su ejército.» Duras palabras que muchos gestores de no es realista. Asegúrese de apuntar que todas las esti
proyecto de software deberían considerar. maciones se basan en proyectos del pasado. Asegú
Las actividades de estim ación y análisis de riesgos rese también de indicar la mejora de porcentaje que
estudiadas en los Capítulos 5 y 6, y las técnicas de pla se requerirá para conseguir la fecha límite tal y como
nificación temporal descritas en este capítulo, se imple- está ahora2. El siguiente comentario sería apropiado:
www.FreeLibros.org
2 Si la m ejora de porcentaje es del 10 al 25 por ciento, puede ser posi
ble, de hecho, term inar el trabajo. Pero si se necesita que la mejora
del porcentaje en el rendim iento del equipo sea m ayor del 50 por
ciento. Esta es una previsión no realista.
112
CAPÍTULO 7 P L A N I F I C A C I Ó N T E M P O R A L Y SE G U I M I E N T O DEL P R O D U C T O
«Creo que podemos tener un problema con la fecha camino principal y pueden com pletarse sin preocupar
de entrega del software de controlador XYZ. Les he se del im pacto en la fecha de term inación del proyecto.
entregado a cada uno de ustedes una descomposición Otras tareas se encuentran en el «cam ino crítico»4. Si
abreviada de los ritmos de producción de proyectos estas tareas «críticas» se retrasan, la fecha de term ina
anteriores y una estimación que hemos hecho de varias ción del proyecto entero se pone en peligro.
maneras diferentes. Se fijarán en que he asumido un
20 por 100 de mejora con respecto a los ritmos de pro ^ D O N S E JO ^ .
ducción del pasado, pero todavía obtenemos una fecha
de entrega que está más bien a 14 meses de calenda Las tareas requeridos para lograr el objetivo
de los gestores del proyecto no se deberían realizar
rio que a 9 meses de la presente fecha.»
manualmente. Hay muchas herramientas excelentes
de planificación de proyectos. Utilícelas.
m m m m i
Los modelos de procesos incrementóles se estudian El objetivo del gestor del proyecto es definir todas
en el Capítulo 2.
las tareas del proyecto, construir una red que describa
sus interdependencias, identificar las tareas que son crí
4. Oferte la estrategia de desarrollo incremental como
ticas dentro de la red y después hacerles un seguim ien
alternativa.
to para asegurarse de que el retraso se reconoce «de
«Tenemos pocas opciones y me gustaría que toma inmediato». Para conseguirlo, el gestor debe tener una
ran una decisión basándose en ellas. Primero, pode planificación temporal que se haya definido con un gra
mos aumentar el presupuesto y conseguir recursos do de resolución que le perm ita supervisar el progreso
adicionales de m anera que tengamos la oportunidad y controlar el proyecto.
de tener el trabajo hecho en nueve meses, pero entien L a planificación tem poral de un proyecto de so ft
dan que esto aumenta el riesgo de poca calidad debi ware es una actividad que distribuye el esfuerzo esti
do a lo apretado de las fechas3. m ado a lo largo de la duración prevista del proyecto,
Segundo, podemos quitar un número determ ina asignando el esfuerzo a las tareas específicas de la inge
do de funciones software y capacidades de las que niería del software. Es im portante resaltar, sin em bar
piden. Esto hará la versión prelim inar del producto go, que la planificación tem poral evoluciona con el
algo menos funcional, pero podemos anunciar la fun tiempo. Durante las prim eras etapas de la planificación
cionalidad com pleta para lanzarla a los 14 meses. del proyecto, se desarrolla una planificación temporal
Tercero, podemos contradecir a la realidad y desear macroscópica. Este tipo de planificación temporal iden
poder completarlo en 9 meses. Nos encontrarem os tifica las principales actividades de la ingeniería del soft
con algo que no se pueda entregar a un cliente de ware y las funciones del producto a las que se aplican.
manera alguna. La tercera opción, espero que estén A m edida que el proyecto va progresando, cada entra
de acuerdo, es inaceptable. N uestra experiencia y da en la planificación temporal m acroscópica se refina
nuestras mejores estimaciones dicen que es poco rea en una planificación temporal detallada. Aquí, se iden
lista y una receta para el desastre.» tifican y program an las tareas del software específicas
Habrá gruñidos, pero si se presentan estim aciones (requeridas para realizar una actividad).
sólidas basadas en una buena información histórica, es
probable que se opte por alguna versión negociada de
las opciones 1 ó 2. La fecha límite no realista se desva
necerá. Una planificación temporal demasiado optimista no
produce planes reales más cortos, sino más largos.
Steve McConnell
7.1.2. Principios b á s ic o s
A Fred Brooks, el conocido autor de The M ythical La planificación tem poral para proyectos de desa
Man-Month [B R 095], se le preguntó una vez cóm o se rrollo de software puede verse desde dos perspectivas
retrasan las planificaciones tem porales de los proyec bastante diferentes. En la prim era se ha establecido ya
tos. Su respuesta fue tan simple como profunda: «D ia (irrevocablemente) una fecha final de entrega de un sis
riamente.» tem a basado en computadora. La organización del soft
La realidad de un proyecto técnico (tanto si implica ware está lim itada a distribuir el esfuerzo dentro del
la construcción de una planta hidroeléctrica o desarro marco de tiempo previsto. El segundo punto de vista de
llar un sistema operativo) es que hay que realizar cien la planificación tem poral asum e que se han estudiado
tos de pequeñas tareas antes de p o d er alcan zar el unos límites cronológicos aproximados pero que la fecha
objetivo final. Algunas de estas tareas quedan fuera del final será establecida por la organización de la ingenie
www.FreeLibros.org
3 Puede añadir que agregar m ás personal no reducirá la planificación 4 El cam ino crítico se estudiará con m ás detalle, m ás adelante en este
temporal proporcionalm ente. capítulo.
113
IN G E N IE R ÍA DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
ría del software. El esfuerzo se distribuye para conse a cada tarea se le debe asignar una fecha de inicio y otra
guir el m ejor em pleo de los recursos, y se define una de finalización que son función de las interdependencias
fecha final después de un cuidadoso análisis del soft y de si el trabajo se hará a tiempo total o tiempo parcial.
ware. Desgraciadam ente, la prim era situación es más Validación de esfuerzo. Todos los proyectos tienen
frecuente que la segunda. un número definido de miembros de la plantilla. A medi
Como todas las áreas de la ingeniería del software, da que se hace la asignación de tiem po, el gestor del
la planificación tem poral de proyectos de software se proyecto debe asegurarse de que no se ha asignado un
guía por unos principios básicos: núm ero de personas m ayor que el de la plantilla en ese
Compartimentación. El proyecto debe dividirse en momento. Por ejemplo, considere un proyecto que tie
un número de actividades y tareas manejables. Para lle ne una plantilla asignada de tres miem bros (por ejem
var a cabo está com partim entación, se descom ponen plo, 3 personas-día están disponibles por día de esfuerzo
tanto el producto como el proceso (Capítulo 3). asignado5). Un día cualquiera, se deben realizar siete
Interdependencia. Se deben determ inar las inter tareas concurrentemente. Cada tarea requiere 0,50 per
dependencias de cada actividad o tarea com partim en- sonas-día de esfuerzo. Se ha asignado más esfuerzo del
tada. A lgunas tareas deben ocurrir en una secuencia que pueden realizar las personas disponibles.
determinada; otras pueden darse en paralelo. Algunas Responsabilidades definidas. Cada tarea que se pro
actividades no pueden com enzar hasta que el resultado grame debe asignarse a un miem bro del equipo especí
de otras no esté disponible. Otras actividades pueden fico.
ocurrir independientemente. Resultados definidos. Cada tarea programada debe
ría tener un resultado definido. Para los proyectos de
software, el resultado es norm alm ente un producto (por
ejemplo, el diseño de un módulo) o una parte de un pro
ducto. Los productos se com binan frecuentem ente en
Cuando realice una planificación temporal,
entregas.
compartimenfalice el trabajo, represente interdependencias
Hitos definidos. Todas las tareas o grupos de tareas
de tareas, asigne el esfuerzo y tiempo a cada tarea, defina
responsabilidades para el trabajo a desarrollar,
deberían asociarse con un hito del proyecto. Se consi
y defina los resultados y los hitos.
gue un hito cuando se ha revisado la calidad de uno o
más productos (Capítulo 8) y se han aceptado.
Asignación de tiempo. A cada tarea que se vaya a pro C ada uno de los principios anteriores se aplica a
gramar se le debe asignar cierto número de unidades de m edida que evoluciona la planificación tem poral del
trabajo (por ejemplo, personas-día de esfuerzo). Además, proyecto.
7.2 LA RELACIÓN ENTRE LAS PE RSONAS Y EL ESFUERZO

En un proyecto de desarrollo de software pequeño una gente que les enseña es la misma que estaba trabajando.
sola persona puede analizar los requisitos, realizar el Mientras están enseñando no se trabaja, y el proyecto se
diseño, generar código y realizar las pruebas. A m edi retrasa todavía más.
da que crece el tam año del proyecto más personas se
ven envueltas. (Raramente podemos permitirnos el lujo
de enfocar el esfuerzo de diez personas-año con una per
sona trabajando durante diez años.) Si debe añadir recursos a un proyecto con retraso,
Hay un mito común (estudiado en el Capítulo 1) que asegúrese de que les ha asignado trabajo altamente
todavía creen muchos gestores responsables de esfuer compartimento/izado.
zos de desarrollo del software: «Si se retrasa el progra
ma, siem pre podrem os añadir más program adores y Además del tiem po que se tarda en aprender el sis
recuperar el ritm o más adelante en el proyecto.» D es tema, el involucrar más personas aumenta el número de
graciadamente, añadir gente tarde a un proyecto tiene a vías de com unicación y la com plejidad de la comuni
menudo un efecto negativo, provocando aún más retra cación a lo largo del proyecto. Aunque la comunicación
so. El personal agregado debe aprenderse el sistema y la es absolutam ente esencial para el éxito del desarrollo
www.FreeLibros.org
5 En realidad, se dispone de m enos de tres personas-día debido a reu
niones no m encionadas, enferm edades, vacaciones y o tras razones.
Para nuestro propósito, sin em bargo, asum im os un 100 por 100 de
disponibilidad.
114
CAPÍTULO 7 P L A N I F I C A C I Ó N T E M P O R A L Y S EG U IM IE N TO DEL P R O D U C T O
del software, cada nueva vía de com unicación requie L = P x E 113 t413
re un esfuerzo adicional y, por tanto, un tiem po adi
donde E es el esfuerzo de desarrollo en personas-mes;
cional.
P es un parámetro de productividad que refleja una varie
dad de factores que llevan a un trabajo de ingeniería del
7.2.1. Un ejem plo softw are de alta calidad (los valores típicos de P se
Considere cuatro ingenieros del softw are, cada uno encuentran entre 2.000 y 12.000); y t es la duración del
capaz de producir 5000 LDC/año cuando trabajan en proyecto en meses.
proyectos individuales. Cuando se pone a estos cuatro
ingenieros en un proyecto de equipo, son posibles seis ^ C O N S E JÓ ^ .
vías de comunicación potenciales. Cada vía de com u
Cuando la fecha límite de entrega es cada vez más
nicación requiere un tiempo que podría de otra manera
ajustada, se alcanza un punto en el que el trabajo
emplearse en desarrollar software. Asumiremos que la
no se puede completar según la planificación,
productividad del equipo (medida en LDC) se verá redu
sin tener en cuenta el número de personas
cida en 250 LD C/año por cada vía de com unicación, que lo estén realizando. Afronte la realidad
debido al gasto indirecto asociado con la comunicación. y defino una nueva fecha de entrega.
Por tanto, la productividad del equipo es 20.000 — (250
x 6) = 18.500 LDC/año— un 7,5 por ciento menos de Despejando la ecuación del software anterior, pode
lo que podríamos esperar6. mos llegar a la expresión del esfuerzo de desarrollo E:
El proyecto de un año en el que está trabajando el
equipo anterior se retrasa y a dos m eses de la fecha E = L3 1 (P3 t4) (7.1)
de entrega se agregan dos personas adicionales al equi donde E es el esfuerzo invertido (en personas-año) duran
po. El número de vías de com unicación se dispara a te el ciclo entero de la vida del desarrollo del software y
14. La productividad de la nueva plantilla es la equi del mantenimiento, y t es el tiempo de desarrollo en años.
valente a 840 x 2 = 1.680 LD C para los dos m eses La ecuación de esfuerzo de desarrollo puede relacionar
restantes antes de la entrega. La p roductividad del se con el coste de desarrollo con la inclusión de un fac
equipo es ahora 20.000 + 1.680 - (250 x 14) = 18.180 tor de coste laboral del trabajo ($/personas-año).
LDC/año. Esto lleva a unos interesantes resultados. Considere
un proyecto com plejo de software de tiem po real esti
mado en 33.000 LDC, un esfuerzo de 12 personas-año.
\ Si se han asignado ocho personas al equipo del proyecto,
CLAVE el proyecto puede estar term inado en 1,3 años. Sin
La relación entre el número de personas que trabajan embargo, si extendem os la fecha de finalización a 1,75
en un proyecto de software y la productividad total años, la naturaleza altamente no lineal del modelo des
crito en la Ecuación (7.1) lleva a:
E = L 3 / (P3 r4) - 3 , 8 personas-año
Aunque el ejemplo anterior es una burda sim plifica
ción exagerada de las circunstancias del m undo real, Esto im plica que extendiendo la fecha de finaliza
sirve para ilustrar otro punto clave: la relación entre el ción seis meses, ¡podemos reducir el núm ero de perso
número de personas que trabajan en un proyecto de soft nas desde ocho hasta cuatro! La validez de estos
ware y la productividad global no es lineal. resultados está abierta a debate, pero la implicación es
clara: se pueden obtener beneficios usando menos gen
7.2.2. Una relación em pírica te durante un período de tiem po algo m ayor para reali
zar el mismo trabajo.
Recordando la «ecuación del software» [PUT92] que
se introdujo en el C apítulo 5, podem os dem ostrar la
relación altam ente no lineal entre el tiem po cronoló 7.2.3. D istribución d el esfuerzo
gico para com pletar un proyecto y el esfuerzo hum a Cada una de las técnicas de estimación del proyecto de
no aplicado al proyecto. El número de líneas de código software tratadas en el Capítulo 5 lleva a estimaciones
entregadas (sentencias fuente), L, está relacionado de las unidades de trabajo (por ejemplo, personas-mes)
con el esfuerzo y el tiem po de desarrollo por la ecua requeridas para completar un desarrollo de software. Una
ción: distribución recom endada de esfuerzo en las fases de
6 Es posible presentar un argum ento en contra: la com unicación, si
www.FreeLibros.org
es efectiva, puede aum entar la calidad del trabajo que se está reali
zando, reduciendo, por tanto, la cantidad de repasos y aum entando
la productividad individual de los m iem bros del equipo. ¡Todavía no
hay veredicto final!
115
INGENIERIA DEL SOFTWARE. UN E N FOQ UE PRÁCTICO
definición y desarrollo se conoce normalmente como la den com prender de un 10 a un 25 por 100 del esfuer
regla 40-20-407. El cuarenta por ciento de todo el esfuer zo del proyecto. El esfuerzo invertido en análisis o
zo o más se asigna a las tareas de análisis y diseño. Un creación de prototipos debería crecer proporcio n al
porcentaje similar se aplica a las pruebas. Se puede dedu m ente con el tam año y la com plejidad del proyecto.
cir correctamente que no se insiste mucho en la creación E ntre un 20 y un 25 por 100 del esfuerzo se aplica
de código (un 20 por 100 del esfuerzo). norm alm ente al diseño del softw are. T am bién debe
considerarse el tiem po em pleado en la revisió n del
^ ¿Cuánto esfuerzo debería diseño y la repetición subsiguiente.
* emplearse en cada una de Debido al esfuerzo aplicado al diseño de software, el
las principales tareas de código debería realizarse con relativa poca dificultad. Se
ingeniería del software? puede alcanzar un rango del 15 al 20 por 100 del esfuer
zo global. Las pruebas y las subsiguientes depuraciones
Esta distribución de esfuerzo debería usarse com o de errores pueden dar cuenta de entre un 30 y un 40 por
una directriz solam ente. Las características de cada 100 restante del esfuerzo de desarrollo del software. La
proyecto dictan la distribución del esfuerzo. El esfuer importancia del software dicta a m enudo la cantidad de
zo gastado en la planificación de un proyecto ra ra pruebas que se requieren. Si el software se ve desde el
m ente supera más del 2 ó el 3 por 100, a no ser que punto de vista hum ano (es decir, el fallo del software
el plan com prom eta a una organización a grandes gas puede generar pérdidas de vidas humanas), se pueden
tos por el gran riesgo. El análisis de los requisitos pue considerar incluso porcentajes más altos.
7.3 DEFINICIÓN DE UN CONJUNTO DE TAREAS PARA EL PROYECTO DE SOFTWARE

En el Capítulo 2 se describieron diferentes modelos de ciplina para alcanzar una alta calidad para el software.
proceso. Estos modelos ofrecen paradigmas diferentes Pero, al mismo tiempo, no se debe cargar al equipo del
para el desarrollo del software. Independientem ente de proyecto con trabajo innecesario.
que un equipo de software elija un paradigm a secuen- Los conjuntos de tareas se diseñan para acomodar
cial lineal, uno iterativo, uno evolutivo, uno concurrente diferentes tipos de proyectos y diferentes grados de rigor.
o alguna combinación, el modelo de proceso está lleno Aunque es difícil desarrollar una com pleta taxonomía
de conjuntos de tareas que permiten al equipo del soft sobre los tipos de proyectos de software, la m ayoría de
ware definir, desarrollar y finalmente m antener el soft las organizaciones de software encuentran proyectos de
ware de computadora. los siguientes tipos:
No hay un único conjunto de tareas que sea apropia I. Proyectos de desarrollo del concepto que se ini
do para todos los proyectos. El conjunto de tareas que cian para explorar algún nuevo concepto de negocios o
sería apropiado para un sistema grande y complejo sería aplicación de alguna nueva tecnología.
considerado exagerado para un producto de software
pequeño, relativamente sencillo. Por tanto, un proceso de II. Proyectos de desarrollo de una nueva aplicación
software eficaz debería definir una colección de conjun que se aceptan com o consecuencia del encargo de un
tos de tareas, cada una diseñada para satisfacer las nece cliente específico.
sidades de diferentes tipos de proyectos. III. Proyectos de mejoras de aplicaciones que ocu
rren cuando un software existente sufre grandes modi
ficaciones de su funcionam iento, rendim iento o
interfaces que son observables por el usuario final.
CLAVE
Un «conjunto de toreos» es una colección de entregos,
IV. Proyectos de mantenimiento de aplicaciones que
hitos y tareas de ingeniería del software. corrigen, adaptan o am plían un software existente en
métodos que pueden no ser obvios de form a inmediata
para el usuario final.
Un conjunto de tareas es una colección de tareas de
la ingeniería del software, hitos y entregas que deben V. Proyectos de reingeniería que se lleva a cabo con
realizarse para completar un proyecto particular. El con la intención de reconstruir un sistema existente (here
junto de tareas a elegir debe proporcionar suficiente dis dado) en su totalidad o en parte.
www.FreeLibros.org
7 Hoy en día, se recom ienda norm alm ente aplicar al análisis y a las
tareas de diseño de grandes proyectos de desarrollo de software m ás
del 40 por 100 de todo el esfuerzo del proyecto. De ahí que el nom
bre de «40-20-40» no se aplique en un sentido estricto.
116
Incluso d entro de un tipo de p ro y ecto sim ple, hay

muchos factores que influyen en el conjunto de tareas
a elegir. C uando se tom an en com binación, estos fac Si todo es una emergencia, habrá algo mol en su proceso
tores proporcionan una in d icació n del grado de rig o r del software o en las personas que lo dirigen o en ambos.
con el que debería aplicarse el p roceso del softw are.
El gestor del proyecto debe desarrollar un enfoque
sistemático para seleccionar el grado de rigor apropia
7.3.1. Grado de rigor do para cada proyecto. Para conseguirlo, se definen unos
criterios de adaptación del proyecto y se calcula un valor
selector del conjunto de tareas.
'X
CLAVE 7.3.2. Definir lo s criterios de a d ap tación
El conjunto de tareas crecerá en tamaño y complejidad Los criterios de adaptación se em plean para determ i
ol mismo tiempo que crece el grado de rigor. nar el grado de rigor recom endado con el que el proce
so del softw are debería aplicarse en un proyecto. Se
Incluso para un proyecto de un tipo en particular, el gra definen once criterios de adaptación para proyectos de
do de rigor con el que se aplica el proceso del softw a software [PRE99]:
re puede variar significativam ente. El grado de rigor es
• Tamaño del proyecto.
función de m u ch as c a ra c te rístic a s del p ro y ec to . P o r
ejemplo, los pequeños proyectos no críticos del n e g o • Núm ero potencial de usuarios.
cio pueden ser tratad o s con algo m en o s de rig o r que • Im portancia de la misión.
grandes y com plejas aplicaciones críticas desde el pu n • Antigüedad de la aplicación.
to de vista del negocio. D ebe ad vertirse, no obstante, • Estabilidad de los requisitos.
que todos los proyectos deben ejecutarse de m anera que
• Facilidad de comunicación cliente/desarrollador.
terminen en puntuales entregas de alta calidad. Se p u e
• M adurez de la tecnología aplicable.
den definir cuatro grados de rigor:
• Lim itaciones de rendimiento.
Casual. Se aplican todas las actividades estructura
les del proceso (C apítulo 2), p ero sólo se requiere un • Características em potradas/no empotradas.
conjunto de tareas m ínim o. En general, las tareas p ro • Personal del proyecto.
tectoras se m inim izarán y se reducirán los requisitos de • Factores de reingeniería.
documentación. Son aplicables todavía todos los p rin
cipios básicos de la ingeniería del softw are.
Estructurado. Se aplicará la estructura del proceso
a este proyecto. Se aplicarán las actividades estructura
les y las tareas relativas apropiadas p ara el tipo de p ro
yecto, así com o las actividades p rotectoras necesarias
Modelo de proceso adoptable
para garantizar una alta calidad. Se llevarán a cabo SQ A
(GCS), docum entación y tareas de m edición de m ane A cada uno de los criterios de adaptación se le asig
ra fluida. na un grado que va desde 1 hasta 5, donde 1 represen
Estricto. Se aplicará el proceso com pleto para este ta un proyecto en el que se requiere un pequeño
proyecto con un grado de disciplina tal que garantice una subconjunto de tareas de proceso, y los requisitos gene
alta calidad. Se aplicarán todas las actividades protecto rales m etodológicos y de docum entación son mínimos,
ras y se producirá una robusta docum entación. y 5 representa un proyecto en el que se debería aplicar
un conjunto com pleto de tareas de proceso y en el que
Reacción rápida. Se aplicará la estru ctura del p ro
los requisitos generales m etodológicos y de docum en
ceso a este p ro y ecto , p ero d e b id o a una situ ació n de
tación son sustanciales.
emergencia8, sólo se a p lic a rá n aq u e lla s tarea s e s e n
ciales para m an ten er una alta calid ad . Se re a liz a rá un
7.3.3. C álcu lo d el valor selector d el conjunto
«back-filling» (es decir, d e sa rro lla r un co njunto c o m
pleto de d o c u m e n ta c ió n , re a liz a r re v isio n e s a d ic io de tareas
nales) después de e n tre g a r la a p lic a c ió n /p ro d u cto al Para seleccionar el conjunto apropiado de tareas para
cliente. un proyecto, se deberían seguir los siguientes pasos:
www.FreeLibros.org
8 Las situaciones de em ergencia deberían ser raras (no debería ocu
rrir en más de un 10 por 100 de todo el trabajo realizado dentro del
contexto de la ingeniería del softw are). Una em ergencia no es lo
mismo que un proyecto con apretadas lim itaciones de tiempo.
117
IN G E N IE R Í A DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
1. Revise cada uno de los criterios de adaptación en la.....................................................................

0 •, n 0 ~ , , ■ , O ¿Comoelegimos elconiunto
Sección 7.3.2 y asigne los grados apropiados (1 a 5) 2 j . . .
. . , , . , , . r . • de toreos apropiado para
basándose en las características del proyecto. Estos . . ■»
grados deberían introducirse en la Tabla 7.1. nüeS,r° pr°yet,0?
C rite rio s de A d a p ta c ió n G rad o Peso M u ltip lic a d o r de p u n to de e n tra d a Producto

C o n c u r. N dev. M e jo ra M an t. R ein g
Tamaño del proyecto 1,20 0 1 1 1 1

Número de usuarios ___ 1,10 0 1 1 1 1
Importancia para el negocio ___ 1,10 0 1 1 1 1
Antigüedad ___ 0,90 0 1 1 0 0
Estabilidad de los requisitos 1,20 0 1 1 1 1
Facilidad de Comunicación 0,90 1 1 1 1 1
Madurez de la tecnología 0,90 1 1 0 1
Limitaciones de rendimiento 0,80 0 1 1 0 1
Empotrado/no empotrado 1,20 1 1 1 0 1
Personal del proyecto 1,00 1 1 1 1 1
Interoperabilidad 1,10 0 1 1 1 1
Factores de reingeniería ---- 1,20 0 0 0 0 1
S e le c to r de co n ju n to de ta re a s (SC T)
T A B L A 7 .1 . CÁLCULO DEL SELECTOR DEL C O N JU N TO DE TAREAS. UN EJEMPLO
2. R evise los facto res de po n d eració n asig n ad o s a 0 y 1, e indica la importancia del criterio de adaptación
cada criterio. El valor de un factor de ponderación para el tipo de proyecto. El resultado del producto:
va desde 0.8 a 1.2 y proporciona una indicación de
G rado x factor de ponderación x multiplicador
la relativa im portancia de un criterio de adaptación
de punto de entrada
en particular a los tipos de software desarrollados
dentro del entorno local. Si son necesarias m odifi se coloca en la colum na Producto de la Tabla 7.1
caciones para reflejar m ejor las circunstancias loca para cada criterio de adaptación individual.
les, se deberían hacer. 4. Calcule la media de todas las entradas en la columna
3. Multiplique el grado introducido en la Tabla 7.1 por el Producto y ponga el resultado en el espacio mar
factor de ponderación (peso) y por el multiplicador cado selector del conjunto de tareas (SCT). Este valor
de punto de entrada del tipo de proyecto a realizar. El se usará para ayudarle a seleccionar el conjunto de
multiplicador de punto de entrada toma un valor entre tareas más apropiado para el proyecto.
C rite rio s de A d a p ta c ió n G rado Peso M u ltip lic a d o r de p u n to de e n tra d a Producto
Concur. Ndev. Mejora Mant. Reing.
Tamaño del proyecto 2 1,2 1 2,4

Número de usuarios 3 1,1 1 3,3
Importancia para el negocio 4 1,1 1 4,4
Antigüedad 3 0,9 1 2,7
Estabilidad de los requisitos 2 1,2 i 2,4
Facilidad de Comunicación 2 0,9 1 1,8
Madurez de la tecnología 2 0,9 1 1,8
Limitaciones de rendimiento 3 0,8 1 2,4
Empotrado/no empotrado 3 1,2 1 3,6
Personal del proyecto 2 1,0 1 2,0
Interoperabilidad 4 1,1 1 4,4
Factores de reingeniería 0 1,2 0 0,0
www.FreeLibros.org
S e le c to r de co n ju n to de ta re a s (S C T ) 2 ,8
T A B L A 7 .2 . CÁLCULO DEL SELECTOR DEL C O N JU N TO DE TAREAS. UN EJEMPLO

118
CAPÍTULO 7 P L A N I F I C A C I Ó N TE M P O R A L Y S EG U IM IE N TO DEL P R O D U C T O
7.3.4. Interpretar el valor SCT y seleccio n a r ras tan definidas cuando se seleccionan conjuntos de
el conjunto d e tareas tareas. En el análisis final, el valor del selector del con
junto de tareas, la experiencia acum ulada y el sentido
Una vez que se ha calculado el selector del conjunto de
com ún deben tenerse en cuenta en la elección del con
tareas, se pueden utilizar las siguientes directrices para
junto de tareas para el proyecto.
seleccionar el conjunto de tareas apropiado para un pro
yecto: La Tabla 7.2 ilustra cóm o podría calcularse el SCT
para un hipotético proyecto. El gestor del proyecto selec
Valor del selector ciona los grados m ostrados en la colum na Grado. El
del conjunto de tareas Grado de rigor tipo de proyecto es el desarrollo de una nueva aplica
SCT < 1 ,2 Casual ción. Por tanto, los m ultiplicadores de punto de entra
1.0 < SCT < 3 ,0 Estructurado da se seleccionan de la colum na NDev. La entrada en
SCT > 2,4 Estricto la colum na Producto se calcula empleando
Grado x Peso x M ultiplicador de punto
^ C O N S E IO ^ . de entrada Ndev(NewDeveIop.)
Si el valor del selector del conjunto de tareas es un área
El valor de SCT (calculado corno la m edia de todas
solapada, normalmente es correcto elegir el menor grado de
rigor formal, a no ser que el riesgo del proyecto sea alto.
las entradas de la columna Producto) es 2,8. Usando los
criterios estudiados anteriorm ente, el gestor tiene la
El solapamiento en los valores SCT de un conjunto opción de usar tanto el conjunto de tareas estructurado
de tareas recom endado con otro está hecho a propósi com o el estricto. La decisión se tom a una vez que se
to y pretende ilustrar que no son posibles unas fronte han considerado todos los factores del proyecto.
7.4 SELECCIÓN DE LAS TAREAS DE INGENIERÍA DEL SOFTWARE

Para desarrollar una planificación temporal del proyecto, Los proyectos de desarrollo de concepto se inician
se debe distribuir un conjunto de tareas a lo largo de la cuando se debe explorar el potencial de alguna nueva
duración del proyecto. Como apuntamos en la Sección tecnología. No hay certeza de que la tecnología sea apli
7.3 el conjunto de tareas variará dependiendo del tipo de cable, pero el cliente (por ejemplo, marketing) cree que
proyecto y del grado de rigor. Cada uno de los tipos de existe un beneficio potencial. Los proyectos de desa
proyectos descritos en la Sección 7.3 puede enfocarse rrollo de concepto se enfocan aplicando las siguientes
usando un modelo de proceso lineal secuencial e iterati tareas principales:
vo (por ejemplo, el modelo incremental o de creación de
Ambito del concepto— determ ina el ámbito gene
prototipos) o evolutivo (por ejemplo, el modelo en espi
ral del proyecto.
ral). En algunos casos, un tipo de proyecto fluye suave
mente hacia el siguiente. Por ejemplo, los proyectos de Planificación prelim inar del concepto— estable
desarrollo de concepto que tienen éxito evolucionan a ce la capacidad de la organización para llevar a cabo el
menudo en nuevos proyectos de desarrollo de aplicación. trabajo im plicado por el ámbito del proyecto.
Cuando termina un proyecto de desarrollo de una nueva Valoración del riesgo tecnológico— evalúa el ries
aplicación, empieza a veces un proyecto de mejora de la go asociado con la tecnología a implementar como par
aplicación. Esta progresión es natural y predecible y ocu te del proyecto.
rrirá sea cual sea el modelo de proceso que adopte una Prueba de concepto— dem uestra la viabilidad de
organización. Por consiguiente, las principales tareas de una nueva tecnología en el contexto del software.
ingeniería del software descritas en las secciones siguien Im plem entación del con cepto— im plem enta la
tes son aplicables a todos los flujos del modelo de proce representación del concepto de m anera que pueda revi
so. Como ejemplo, consideremos las tareas principales de sarlo un cliente y se em plea para propósitos de «m ar
ingeniería para los proyectos de desarrollo de concepto. keting» cuando hay que vender un concepto a otros
clientes o departam entos de gestión.
Reacción del cliente ante el concepto— solicita la opi
nión del cliente sobre un nuevo concepto de tecnología y
va encaminada a aplicaciones específicas del cliente.
No deberían producirse sorpresas si echamos un vis
Un modelo de proceso adaptable tazo rápido a estas tareas principales. De hecho el flujo
www.FreeLibros.org
(MPA) completo incluye una de las tareas de ingeniería del software para proyectos
variedad de conjuntos de tareas de desarrollo de concepto (y también para los otros tipos
y está disponible para su uso. de proyectos) es poco más que sentido común.
119
El equipo del softw are debe entender lo que hay elige un m odelo evolutivo, la distribución de tareas de
que hacer (ámbito); el equipo (o el gestor) debe deter la 1.1 a la 1.6 aparecería com o se m uestra en la Figura
m inar si hay alguien disponible para hacerlo (planifi 7.2. Se pueden definir y aplicar de la m ism a m anera las
cación); debe considerar los riesgos asociados con el tareas principales de ingeniería del software para otros
trabajo (valoración del riesgo); probar la tecnología tipos de proyectos.
de alguna m anera (prueba de concepto); e im plem en-
tarlo en form a de prototipo de m anera que el cliente
pueda evaluarlo (im plem entación del concepto y eva
luación del cliente). Finalmente, si el concepto es via
ble, se debe fab ricar una versión de producción
(traducción).
Es importante destacar que las actividades estructu
rales de las tareas de desarrollo de concepto son itera
tivas por naturaleza. Es decir, un proyecto de desarrollo
de concepto cualquiera podría enfocar las tareas ante
riores en varios incrementos planificados, cada uno dise
ñado para producir una entrega que pueda ser evaluada
por el cliente.
Si se elige un modelo de proceso lineal, cada uno de
estos incrementos se define en una secuencia repetitiva
como se ilustra en la Figura 7.1. Durante cada secuen
cia, se aplican actividades protectoras (descritas en el
Capítulo 2); se supervisa la calidad, y al final de cada
secuencia, se produce una entrega. Con cada iteración,
cada entrega debería converger hacia el producto final .F IG U R A 7 .1 . Tareas de desarrollo del concepto
definido para la fase de desarrollo de concepto. Si se en un m odelo secuencial lineal.
7.5 REFINAMIENTO DE LAS TAREAS PRINCIPALES
P la n i f ic a c ió n d e l c o n c e p t o p r e lim i n a r
ral macroscópica para el proyecto. Sin embargo, la pla
V a lo r a c i ó n d e ) r ie s g o t e c n o ló g ic o nificación tem poral m acroscópica debe refinarse para
crear una planificación tem poral d etallad a del pro
yecto. El refinam iento se em pieza tom ando cada tarea
I n g e n ie r í a /
C o n s tr u c ció n
principal y descom poniéndola en un conjunto de sub-
tareas (con productos de trabajo e hitos relacionados).
Com o ejem plo de descom posición de tarea, consi
dere el A m bito del C o n cep to com o un concepto del
proyecto de desarrollo, estudiado en la Sección 7.4.1.
Se puede retinar la tarea empleando un formato de bos
quejo, pero en este libro se em plea un enfoque de len
guaje de diseño de proceso para ilustrar el flujo de la
actividad de ámbito del concepto:
Definición de ta r e a : Tarea 1 .1 Ámbito d el concepto
1 .1 .1 . I d e n ti ñ c a r la n ecesidad, l o s beneñcíos y
c l i e n t e s p o te n c ia le s;
1 .1 .2 . Deñnir el r e s u l t a d o / c o n t r o l deseado y las
E n treg a
entradas que controlan la aplicación;
F IG U R A 7 .2 . Tareas de desarrollo del concepto usando Empezar la tarea 1.1.2
un m odelo evolutivo. 1 . 1 .2 .1 . RTF: Revisar la descripción e s c r ita de
la necesidad 9;
Las tareas principales descritas en la Sección 7.4 pue 1 .1 .2 .2 . Obtener una l i s t a de la s e n t r a d a s /s a li
den em plearse para definir una planificación tem po das v i s i b l e s del c l ie n t e ;
www.FreeLibros.org
9 RTF indica que se debe realizar una revisión técnica formal (Capí
tulo 8).
120
Caso de: procedim ientos Procedimientos = A n á lis i s estructurado

Procedimientos = d e s p lie g u e de la fu nción obtener un diagrama de ñujo de datos a n iv e l
calidad de contexto;
r e u n ir s e con e l c l i e n t e para a i s l a r lo s reñnar el diagrama de ñujo de datos para
p r in c ip a le s r e q u is ito s del concepto; proporcionar más d e t a lle s ;
e n t r e v i s t a r a lo s usuarios únales; e s c r ib i r narrativas de proceso para la s fun
observar el enfoque actual al problema, pro ciones a más bajo n iv e l de refinamiento;
ceso actual; Procedimientos = v is ió n de objeto
r e v is a r r e q u is ito s y quejas a n te rio re s; deñnír operaciones/métodos re le v a n te s para
Procedimientos = a n á l i s i s estructurado cada clase;
hacer una l i s t a de lo s o b je to s de datos fin caso
p rin c ip a le s; 1 . 1 .3 .3 . R e v isa r funcion es/com portam ientos con
definir la s re lacion es en tre lo s objetos; e l c l i e n t e y r e v i s a r según sea n ec esa
r io ;
deñnír lo s a tr i b u to s de lo s objetos;
Fin de tarea Tarea 1.1 .3
Procedimientos = v is ió n del objeto
1 . 1 . 4 . A is la r aquellos elementos de la tecnología a
hacer una l i s t a de la s clases de problemas; implementar en software;
d e s a r r o lla r la je ra rq u ía de c l a s e s y la s 1 . 1 . 5 . I n v e s tig a r la d is p o n ib ilid a d de información
conexiones de clases; sobre el software e x is t e n te ;
definir Jos a tr ib u to s de la s clases; 1 . 1 . 6 . Deñnir v i a b ilid a d técnica;
fin caso 1 .1 .7 . Hacer una estimación rápida del tamaño;
1.1 .2 .3 . RTF: r e v is a r la s entra das/salida s con el 1 .1 .8 . Crear una definición de ámbito;
c l i e n t e y adaptar según se requiera;
Fin de tarea: Tarea 1.1
Fin de tarea Tarea 1 . 1. 2
1.1.3. Definir la funcional i dad/comportamiento para
cada función p rin c ip a l que es desarrollada;
Empezar Tarea 1 . 1. 3
1 . 1 . 3 . 1 . RTF: r e v i s a r l o s o b je to s de datos de
entrada y sa lid a obtenidos en la tarea
1.1 .3 .2 . Obtener un modelo de funciones/compor
tamientos ; El modelo de proceso adaptable
Caso de: procedimientos (MPA) contiene una descripción
Procedimientos = D espliegue de la función del lenguaje de diseño de
calidad procesos completa para todas las
re u n ir s e con el c l i e n t e para r e v i s a r lo s tareas de ingeniería del software.
re q u is ito s del concepto p rin c ip a l;
e n t r e v is ta r a lo s usuarios únales;
observar el enfoque actual del problema, Las tareas y subtareas apuntadas en el refinamiento
proceso actual; del lenguaje de diseño del proceso forman la base para
des a rro lla r un esquema jerárquico de fun- una planificación temporal detallada de las actividades
ci ones/ compprtamien tos; del ámbito del concepto.
7.6 DEFINIR UNA RED DE TAREAS

Las tareas y subtareas individuales tienen interdepen Una red de tareas, también llamada red de activida
dencias basadas en su secuencia. Además, cuando hay des, es una representación gráfica del flujo de tareas de
más de una persona im plicada en un proyecto de inge un proyecto. Se em plea a veces com o el m ecanism o
niería del software, es probable que las actividades de a través del cual se introduce la secuencia de tareas y
desarrollo y tareas se realicen en paralelo. Cuando ocu las dependencias en una herram ienta de program ación
rre esto, las tareas concurrentes deben coordinarse de autom ática de la planificación tem poral de un p ro
manera que estén finalizadas cuando tareas posteriores yecto. En su form a m ás sencilla (la que se em plea en
requieran su(s) resultado(s). una planificación tem poral m acroscópica), la red de
tareas m uestra las tareas principales de ingeniería del
softw are. L a F ig u ra 7.3 m u estra una red de tareas
esquem ática para un proyecto de desarrollo de con
CLAVE cepto.
www.FreeLibros.org
La red de tareas es un mecanismo útil La naturaleza concurrente de las actividades de inge
para representar la dependencia entre tareas niería del software lleva a varios requisitos im portan
y para determinar el camino crítico. tes de la planificación tem poral. Com o las tareas
121
paralelas ocurren asincronamente, el planificador debe 1.3a

determinar las dependencias entre las tareas para garan u Valoración 1.5a
Ámbito del ; Implernentación
del riesgo
tizar un progreso continuo hasta su finalización. A de concepto
tecnológico del concepto
más, el gestor del proyecto debería estar al tanto de las
tareas que pertenecen al camino crítico. Es decir, tare
/ 1.3b
as que deben finalizarse según la planificación tem po 12 Valoración
1.4
1.5a
Prueba del • Implernentación - ►
ral si se quiere que el proyecto en general se term ine a Planificación L * del riesgo
concepto del concepto
a, b. c
del c o n c e p to : tecnológico
tiem po. Estos aspectos se tratan con más detalle más
adelante en este capítulo.
Es im portante resaltar que la red de tareas m os I.6
! 5a
Reacción
trada en la Figura 7.3 es m acroscópica. En una red Implememacion
del cliente
del concepto
de tareas detallada (el precursor de la planificación
tem p o ral d etallad a) cada activ id ad m o strad a en la S e aplican 3 tareas 1.3 . S e aplican 3 tareas 1.5 .
Figura 7.3 se expandiría. Por ejem plo, la Tarea 1.1 se en paralelo a 3 funciones en paralelo a 3 funciones
de concepto diferentes de concepto diferentes
expandiría para m ostrar todas las tareas detalladas en
el refin am ien to de tareas 1.1 m o strad o en la S ec F IG U R A 7 .3 . Una red de tareas para un proyecto
ción 7.5. de desarrollo de concepto.
7.7 LA PLANIFICACIÓ N TEMPORAL

La planificación temporal de un proyecto de software blecer las dim ensiones de tiem po «m ás probables»
no difiere mucho del de cualquier esfuerzo de ingenie para las tareas individuales aplicando m odelos esta
ría multitarea. Por tanto, se pueden aplicar herram ien dísticos, y (3) calcular las lim itaciones de tiempo que
tas de planificación temporal de proyectos y técnicas definen una «ventana» de tiem po de una tarea deter
generales al software con una pequeña modificación en minada.
los proyectos del software. Los cálculos de las lim itaciones de tiem po pueden
ser muy útiles en la planificación temporal de proyec
tos de software. El retraso en el diseño de una función,
por ejemplo, puede retardar el posterior diseño de otras
Para los proyectos más sencillos, lo planificación temporal funciones. Riggs [RIG81] describe importantes limita
debería realizarse con lo ayuda de una herramienta ciones de tiem po que pueden discernirse de una red
de planificación temporal de proyectos.
PERT o CPM: (1) lo antes posible que puede empezar
una tarea cuando las tareas precedentes se completen
La técnica de evaluación y revisión de program a
tam bién lo antes posible; (2) lo más tarde que se puede
(PERT) y el método del camino crítico (CPM) [MOD83]
empezar una tarea antes de que se retrase el tiempo míni
son dos métodos de la planificación temporal de un pro
mo para finalizar el proyecto; (3) la fecha más tempra
yecto que pueden aplicarse al desarrollo de software.
na de finalización — la suma de la fecha más temprana
Ambas técnicas son dirigidas por la información ya desa
de inicio y la duración de la tarea— ; (4) la fecha lími
rrollada en actividades anteriores de la planificación del
te de finalización — la fecha más tardía de inicio suma
proyecto:
da a la duración de la tarea— , y (5) el margen total — la
• Estimaciones de esfuerzo. cantidad de tiem po extra o atrasos permitidos en la pla
• Una descomposición de la función del producto. nificación temporal de las tareas de manera que el cami
• La selección del modelo de proceso adecuado y del no crítico de la red se m antenga conform e a la
conjunto de tareas. planificación tem poral— . Los cálculos de los tiempos
• La descomposición de tareas. límite llevan a la determ inación del cam ino crítico y
proporcionan al gestor un método cuantitativo para eva
Las interdependencias entre las tareas deben defi luar el progreso a m edida que se com pletan las tareas.
nirse em pleando una red de tareas. Las tareas, a veces
denom inadas estructura de descom posición del tra
bajo del proyecto (en inglés, W BS), se definen para el
producto com o un todo o para las funciones indivi
duales.
Tanto PERT com o CPM proporcionan herram ien
www.FreeLibros.org
tas cuantitativas que perm iten al planificador del soft Herramientas CASE
ware : (1) determ inar el camino crítico, la cadena de para la planificación temporal
tareas que determina la duración del proyecto; (2) esta y programación del proyecto.
122
Tanto PERT com o CPM se han im plem entado en Además, se asignan las tareas a individuos específicos.
varias herram ientas autom áticas disponibles virtual
mente para todos los ordenadores personales [THE93],
Tales herramientas son fáciles de usar y hacen asequi
bles los métodos de la planificación temporal descritos
anteriormente a todos los gestores de proyectos de soft CLAVE
ware. Un gráfico de tiempo le permite conocer qué tareas serán
conducidos en un punto determinado en el tiempo.
7.7.1. Gráficos de tiem po
Cuando se crea una planificación tem poral de un p ro
yecto de softw are, el p lan ificad o r em pieza un c o n Com o consecuencia de esta entrada, se genera un
junto de tareas (la estructura de descom posición del gráfico de tiempo, tam bién denom inado Gráfico Gantt.
trabajo). Si se em plean herram ientas autom áticas, la Se puede desarrollar un gráfico de tiem po para todo el
descomposición del trabajo es introducida com o una proyecto. Alternativamente, se pueden desarrollar dife
red de tareas o esquem a de tareas. El esfuerzo, dura rentes gráficos para cada función del proyecto o para
ción y fecha de inicio son las entradas de cada tarea. cada individuo que trabaje en el proyecto.
T areas
1.1.1 Identificar n e c esid a d es y beneficios

R eunirse con los clien tes
Identificar las n e c esid a d es y las lim ita cio n e s
del proyecto
E stablecer la d eclaració n d e p roducto
Hito: declaración de p ro d u cto d efin id a
1.1.2 Definir las sa lid a s/c o n tro l/e n tra d a s d e s e a d a s (SCE)
Alcance de las fu n cio n es del teclad o
Alcance de las fu n cio n es de e n tr a d a d e voz
Alcance de los m odos d e in teracció n
Alcance de do cu m en to de d iag n ó stico s
Alcance o tra s fu nciones W P
Docum ento SCE
RTF: rev isa r el SC E con el clien te
Revisar el SC E seg ú n se re q u ie ra
Hito: SCE definido
1.1.3 Definir la fu n cio n a lid a d /c o m p o rta m ie n to
Definir las fu nciones del teclad o
Definir las fu nciones de e n tr a d a de voz
Describir los m odos d e in teracció n
Describir las com probaciones d e o rto g ra fía /
gram ática
Describir o tra s fu n cio n es W P
RTF: R evisar la definición SC E con el c lien te
Revisar seg ú n se a n e c esa rio
Hito: D efinición de SC E c o m p leta
1.1.4 A islar los ele m e n to s so ftw are
Hito: E lem en to s so ftw are definidos
1.1.5 Investigar la d isp o n ib ilid ad del s o ftw a re e x iste n te
Investigar los c o m p o n en tes de edición d e tex to
Investigar los c o m p o n en tes de la e n tr a d a de voz
Investigar los c o m p o n en tes de la a d m in istra c ió n
de archivos
Investigar los c o m p o n en tes de la com probación
de ortografía y g ra m á tic a
Hito: C om ponentes re u tiliz a b le s id en tificad o s
1.1.6 Definir la v iab ilid a d téc n ic a
E valuar la e n tr a d a de voz
E valuar la com probación d e g ra m á tic a
Hito: V iabilid ad téc n ic a v a lo ra d a
1.1.7 Hacer u n a estim a c ió n r á p id a del ta m a ñ o
1.1.8 C rear u n a definición de ám b ito
Revisar el docu m en to de á m b ito con el clien te
Revisar el docu m en to se g ú n se re q u ie ra
www.FreeLibros.org
Hito: D ocum ento de á m b ito com pleto
FIGURA 7.4. Un ejem plo de gráfico de tiem po.
123
INGENIERÍA DEL SOFTWARE. UN ENFOQ UE PRÁCT ICO
La Figura 7.4 ilustra el formato de un gráfico de tiem progreso hasta la fecha y los problem as que se ave
po. M uestra una parte de la planificación temporal de cinan, o
un proyecto de software que enfatiza la tarea de ám bi • utilizando el análisis del valor ganado (Sección 7.8)
to del concepto (Sección 7.5) para un nuevo producto para evaluar el progreso cuantitativamente.
de software de procesador de textos. Todas las tareas
del proyecto (para ámbito del concepto) se listan en la
columna de la izquierda. Las barras horizontales indi
can la duración de cada tarea. Cuando aparecen m últi Elm ejor ináicoáor del progreso es la finalización
ples barras al mismo tiempo en la planificación temporal, Y la revisión exitosa de un producto de software.
implican concurrencia de tareas. Los rom bos indican
El control lo usa el gestor para administrar los recur
hitos.
sos del proyecto, enfrentarse a los problem as y dirigir
Una vez que se ha introducido la información nece
al personal del proyecto. Si las cosas van bien (es decir,
saria para generar el gráfico de tiem po, la m ayoría de
el proyecto va según la planificación temporal y dentro
las herram ientas de la planificación tem poral de pro
del presupuesto, las revisiones indican que se está
yectos de software producen tablas de proyecto — un
haciendo un progreso real y que se están alcanzando los
listado tab u lar de todas las tareas del proyecto, sus
hitos), el control es liviano. Pero cuando aparecen los
fechas previstas y reales de inicio y finalización, e
problem as, el gestor debe ejercer el control para solu
inform ación varia relativa al tem a— (Fig. 7.5). Em
cionarlos tan pronto com o sea posible. Una vez que el
pleando las tablas junto con los gráficos de tiem po, le
problem a se ha diagnosticado10, se pueden concentrar
perm iten al gestor del proyecto hacer un seguim iento
recursos adicionales en el área del problema: se puede
del progreso.
redistribuir la plantilla, o se puede redefinir la planifi
cación temporal del proyecto.
7.7.2. S e g u im ie n to d e la p la n ific a c ió n tem p oral Cuando se enfrentan a la presión de una fecha de
La planificación tem poral del proyecto le proporcio entrega muy ajustada, los gestores de proyecto utilizan
na al gestor un m apa de carreteras. Si se ha desarro a veces una planificación tem poral de proyecto y una
llado apropiadam ente, define las tareas e hitos que técnica de control denom inada tim e-boxing (tiempo
deben seguirse y controlarse a m edida que progresa el encajonado) [ZAH95], Esta estrategia reconoce que qui
proyecto. El seguim iento se puede hacer de diferentes zás no se pueda entregar el producto com pleto para la
m aneras: fecha límite predefinida. Por tanto, se elige un paradig
• realizando reuniones periódicas del estado del pro m a incremental del software (Capítulo 2) y se crea una
yecto en las que todos los miembros del equipo infor planificación temporal para cada entrega de un incre
man del progreso y de los problemas; mento.
Las tareas asociadas con cada increm ento se enca
• evaluando los resultados de todas las revisiones reali
jonan en el tiempo. Esto significa que la planificación
zadas a lo largo del proceso de ingeniería del software;
temporal para cada tarea se ajusta trabajando hacia atrás
desde la fecha de entrega para cada incremento. Se pone
Q c /f a : una «caja» alrededor de cada tarea. Cuando una tarea
Lo regla básica de los informes de estado del alcanza el límite de su caja de tiempo (más o menos un
software puede resumirse en una frase: «¡ninguna 10 por 100), se term ina el trabajo y se em pieza la
sorpresa!». siguiente tarea.
Capers Jones La prim era reacción frente al enfoque de encajona
miento de tiem po es a m enudo negativa: «Si no se ha
term inado el trabajo, ¿cómo podem os proseguir?» La
• determinando si se han conseguido los hitos forma
respuesta se encuentra en la m anera en que se realiza el
les del proyecto (los rombos mostrados en la Fig. 7.4)
trabajo. Cuando se llega al límite de la caja de tiempo,
en la fecha programada;
es probable que se haya com pletado el 90 por 100 de la
• comparando la fecha real de inicio con las previstas tarea". El restante 10 por 100, aunque importante, pue
para cada tarea del proyecto listada en la tabla del de (1) retrasarse hasta el siguiente increm ento, o (2)
proyecto (Fig. 7.5); completarse más tarde si es necesario. En vez de estar
• reuniéndose informalmente con los profesionales del «estancado» en una tarea, el proyecto progresa hacia la
software para obtener sus valoraciones subjetivas del fecha de entrega.
www.FreeLibros.org
10 Es im portante resaltar que un retraso del program a es un síntom a 11 Un cínico podría recordar el dicho: «El primer 90 por 100 de un sis
de algún problem a oculto. El papel del gestor es diagnosticar cuál es tem a se lleva el 10 por 100 del tiempo. El último 10 por 100 del sistema
el problem a y actuar para corregirlo. se lleva el 90 por 100 del tiempo.»
124
Inicio Inicio Terminación Terminación Personas Esfuerzo

Tareas de trabajo Observaciones
previsto real prevista real asignadas asignado
1.1.1 Id e n tific a r n e c e s id a d e s y b e n e fic io s Es p re v is ib le
R eunirse c o n lo s c lie n te s S e m 1 ,d 1 S e m 1 ,d 1 S e m 1,d2 S e m 1,d2 BLS 2 p-d q u e re q u ie ra
Id e n tific a r las n e c e s id a d e s y lim ita c io n e s S e m 1,d2 S e m 1,d2 S e m 1,d2 S e m 1,d2 JP P 1 p-d m á s e s fu e rz o /
del p ro y e c to tie m p o
E stablecer la d e c la ra c ió n d e l p ro d u c to S e m 1,d3 S em 1,d3 S e m 1,d3 S e m 1,d3 B LS /JPP 1 p-d
H ito: d e c la ra c ió n d e p ro d u c to d e fin id a S e m 1,d3 S e m 1,d3 S e m 1,d3 S e m 1,d3
1.1.2 D e fin ir las s a lid a s /c o n tro l/e n tra d a s
deseadas (SCE)
Á m b ito de las fu n c io n e s d el te c la d o S e m 1,d4 S e m 1,d4 S e m 2,d2 BLS 1,5 p-d
Á m b ito de las fu n c io n e s de e n tra d a de vo z S e m 1,d3 S e m 1,d3 S e m 2,d2 JPP 2 p-d
Á m b ito de lo s m o d o s de in te ra c c ió n S e m 2,d1 S e m 2 ,d 3 M LL 1 p-d
Á m b ito de lo s d ia g n ó s tic o s d e l d o c u m e n to S e m 2,d1 S e m 2 ,d 2 BLS 1,5 p-d
Á m b ito de o tra s fu n c io n e s W P S e m 1,d4 S em 1,d4 S e m 2,d3 JP P 2 p-d
D o cu m e n to SCE S e m 2,d1 S e m 2,d3 M LL 3 p-d
RTF : re v is a r SCE co n el c lie n te S e m 2 ,d 3 S e m 2,d3 Todos 3 p -d
Revisar SCE s e g ú n se re q u ie ra ; S e m 2 ,d 4 S e m 2 ,d 4 Todos 3 p-d
Hito: SCE d e fin id o S e m 2,d5 S e m 2 ,d 5
1.1.3 D e finir ia fu n c io n a lid a d /c o m p o r ta m ie n to
FIG U R A 7.5. Un ejemplo de tabla de proyecto.
, 7.8 ANÁLISIS DE VALOR GANA DO

En la sección 7.7.2, ya discutimos un número de aproxi Para determ inar el valor ganado se desarrollan los
maciones cualitativas al seguimiento del proyecto. Cada siguientes pasos:
una de ellas proporciona al gestor del proyecto una indi 1. El coste presupuestado del trabajo planificado (CPTP)
cación del progreso, pero teniendo en cuenta que esta eva se determina para cada tarea de trabajo que se repre
luación proporcionada de la información es en cierto modo senta en el plan. Durante la actividad de estimación
subjetiva. Ahora bien, ¿es razonable preguntarse si exis (Capítulo 5), el trabajo (en personas-hora, personas-
te una técnica cuantitativa para evaluar el progreso a medi día) de cada tarea de ingeniería del software es con
da que el equipo de software avanza a través de las tareas venientemente planificada. Por consiguiente, CPTPi
de trabajo asignadas en la planificación del proyecto? En es el trabajo que se ha planificado para una cierta tarea
efecto, una técnica para desarrollar análisis cuantitativo i. Para determinar el progreso en un punto dado a lo
del progreso realizado existe. Es denominada análisis de largo de la planificación del proyecto, el valor de CPTP
valor ganado (AVG). es la suma de los valores CPTPi para todas las tareas
del trabajo que deberían haber sido completadas en ese
momento en el plan del proyecto.
¿Cómo se calculo el valor

El valor ganado proporciona una indicación cuantitativa
* ganado para evaluar
del progreso.
el progreso?
Humphrey [HUM95] estudia el valor ganado de la
manera siguiente: 2. Los valores CPTP para todas las tareas del trabajo
se suman para obtener el presupuesto a la term ina
El sistema de valor ganado proporciona una escala de valor
ción que se denom ina PAT. Por consiguiente,
común para cada tarea Lproyecto de software], independiente
mente del tipo de trabajo que esté siendo llevado a cabo. Se PAT = X (C P T P J para todas las tareas k
estiman entonces el total de horas para realizar el proyecto com
pleto y a cada tarea se le da un valor ganado basado en su por 3. A continuación, se calcula el valor para el coste pre
centaje estimado respecto al total. supuestado del trabajo desarrollado (CPTD). El
valor para CPTD es la sum a de los valores CPTP
Dicho de forma más simple, el valor ganado es una
para todas las tareas de trabajo que hayan sido real
medida del progreso. Nos permite evaluar el «porcen
mente terminadas en un punto determinado de la pla
taje de realización» de un proyecto utilizando el análi
nificación del proyecto.
sis cuantitativo más que la opinión particular que de ello
tengamos. En efecto, Flem ing y Kopplem an [FLE98] Wilkens [WIL99J afirma que «la distinción entre el
aducen que el análisis de valor ganado «proporcionan CPTP y el CPTD es que el prim ero representa el pre
www.FreeLibros.org
unas lecturas exactas y fiables del desarrollo desde esta supuesto de las actividades que estaban planificadas para
dos iniciales como cuando tan sólo se haya realizado un ser completadas, y el último representa el presupuesto
15 por ciento del proyecto». de las actividades que realm ente estaban acabadas».
125
INGENIERÍA DEL SOFTWARE. UN ENFOQ UE PRÁCT ICO
Dados los valores para CPTP, PAT, CPTD, pueden ser po de la planificación del proyecto. Es entonces posi
calculados los siguientes indicadores de progreso: ble calcular:
Indice de desarrollo de planificación, IDP = CPTD/CPTP índice de desarrollo del coste, 1DC — CPTP/CRTR
Varianza de la planificación, VP = CPTD - CPTP Varianza del coste, VC = CPTP - CRTR
IDP es una indicación de la eficiencia con que el pro
yecto está utilizando los recursos de la planificación.
Un valor IDP cercano a 1.0 indica una ejecución efi
Referencia W ebl
ciente de la planificación del proyecto. VP es sim ple
Se puede encontrar un gran conjunto de recursos
m ente una indicación absoluta de la varianza de la
para el análisis del valor ganado (bibliografía completa,
planificación prevista.
documentos, enlaces) en www.acq.osd.mil/pm/.
Porcentaje planificado para terminar = CPTD/PAT
Un valor de IDC cercano a 1.0 proporciona una indi
proporciona una indicación del porcentaje de trabajo cación evidente de que el proyecto está dentro del pre
que debería estar terminado en el instante t. supuesto que para él se ha definido. VC es una indicación
absoluta de los ahorros en coste (en relación con los cos
Porcentaje completado = CPTP/PAT
tes planificados) o de las carencias en una etapa parti
proporciona una indicación cuantitativa del «grado de cular del proyecto.
avance en la realización en tanto por ciento» del pro Como ya ocurrió en la aparición del radar, el análi
yecto en un instante determinado de tiem po t. sis del valor ganado aclara las dificultades de planifica
Es tam bién posible calcular el coste real de traba ción antes de que ellas puedan aparecer. Esto permite
jo realizado, CRTR. El valor para CRTR es la suma al gestor del proyecto de software tom ar las acciones
del esfuerzo realm ente desarrollado en tareas de tra correctivas adecuadas antes de que la crisis del proyec
bajo que hayan sido realizadas en un instante de tiem to estalle.
7.9 SEGUIMIENTO DEL ERROR

A través del proceso de software, un equipo que se dedi han encontrado en tareas posteriores) se considera que son
ca al proyecto crea productos de trabajo (por ejemplo, defectos llamados D. La eficiencia de eliminación de
especificaciones de los requisitos o prototipos, docu defectos (Capítulo 4) ha sido definida como:
mentos de diseño, código fuente). Pero este equipo tam
EED = EI(E+D)
bién crea (y corrige afortunadamente) errores asociados
con cada producto de trabajo realizado. Si las medidas EED es una métrica de proceso que proporciona una indi
relacionadas con los errores y las métricas resultantes cación clara de la efectividad de las actividades de garan
son registradas a lo largo de m uchos proyectos de soft tía de calidad, pero EED y el cálculo de errores y defectos
ware, un gestor de proyectos puede utilizar estos datos asociados con ella puede ser también usada para ayudar
como una línea base para com parar esto con los datos al gestor de proyectos a determinar el progreso que se está
de errores recogidos en tiempo real. El seguimiento del realizando a medida que el proyecto de software se mue
error puede utilizarse como una m edida para evaluar el ve a través de las tareas de trabajo planificadas.
estado del proyecto actual. A sum am os que una organización de softw are ha
registrado datos de errores y defectos durante los 24
m eses pasados y ha desarrollado prom edios para las
métricas siguientes:
• Errores por página de especificación de requisitos,
El seguimiento del error nos permite comparar Ereq
el trabajo actual con esfuerzos pasados y proporciona
• Errores por componentes a nivel de diseño, Ediseño
una indicación cuantitativa de la calidad del trabajo
que estemos realizando. • Errores por componente a nivel de código, Ecodigo
• EED-análisis de requisitos
En el Capítulo 4, el concepto de eficiencia de elimi • EED-diseño arquitectónico
nación de defectos ya fue discutido. Para recordarlo bre
• EED-diseño a nivel de componentes
vemente, el equipo de software desarrolla revisiones
• EED-codificación
técnicas formales (y, más tarde, comprobaciones) para
www.FreeLibros.org
encontrar y corregir los errores, E, en productos realiza A m edida que el proyecto progresa a través de cada
dos durante las tareas de ingeniería de software. Cual paso de la ingeniería de softw are, el equipo de soft
quiera de los errores que no se hayan descubierto (pero se w are registra e inform a del núm ero de errores encon
126
trados en los requisitos, diseño y revisiones de códi sión. Si el segundo escenario parece más probable, el
go. El gestor del proyecto calcula los valores actua gestor de proyecto debería adoptar los pasos necesarios
les para Ereq, E diseño y Ecodigo. Estos son después para construir un tiem po12 de diseño adicional dentro
comparados con los prom edios de proyectos anterio del plan con el fin de acom odar los defectos de requisi
res. Si los resultados actuales discrepan en m ás de un tos que probablem ente hayan podido propagarse a tra
20 por 100 de dicho prom edio, ello puede ser causa vés de la actividad propia de diseño.
de preocupación, y debe ser objeto de una investiga La m étrica de seguim iento de errores descrita ante
ción posterior. riorm ente puede ser utilizada tam bién para los recur
sos de com probación y/o revisión de objetivos. Por
ejem plo, si un sistem a se com pone de 120 co m p o
nentes, pero 32 de dichos com ponentes m uestran valo
Cuanto más cuantitativo sea su enfoque para el
res Ediseño que tengan una varianza sustancial a partir
seguimiento y control del proyecto, estará probablemente
del prom edio, el gestor del proyecto puede elegir dedi
más preparado paro prevenir problemas potenciales y
car recursos de revisión de código a los 32 co m p o
responder ante ellos de un modo proactivo. Utilice
nentes y perm itir a otros pasar a su com probación con
métricas de seguimiento y de valor ganado.
una revisión de código. A unque todos los com ponen
tes deberían ser som etidos a una revisión de código en
Por ejemplo, si Ereq =2.1 en el proyecto X, y el pro una supuesta revisión ideal, para los proyectos que se
medio de la organización es 3.6, es posible uno de estos hayan pasado de presupuesto puede ser un m edio efec
dos escenarios: (1) que el equipo de software baya desa tivo realizar una aproxim ación selectiva (revisando
rrollado el trabajo preferente de desarrollar las especi sólo aquellos m ódulos que tengan una calidad dudosa
ficaciones de requisitos o (2) que el equipo haya prestado basándose en el valor Ediseño) con el fin de recupe
una atención secundaria en la aproxim ación a la revi rar el tiem po perdido y/o ahorrar los costes.
7.10 EL PLAN DEL PROYECTO

Cada paso en el proceso de ingeniería del software debe cionado con el proyecto, y (5) describir cómo se garan
ría obtener una entrega que pueda revisarse y que pueda tizará la calidad y se gestionan los cambios.
hacer de fundamento para los siguientes pasos. El Plan
del Proyecto de Software se produce a la culminación de
las tareas de planificación. Proporciona información bási
ca de costes y planificación temporal que será empleada
a lo largo del proceso de software.
El Plan del Proyecto de Software es un documento
relativamente breve dirigido a una audiencia diversa. Plan del Proyecto de Software
Debe (1) comunicar el ámbito y recursos a los gestores Es importante señalar que el Plan del Proyecto del Soft
del software, personal técnico y al cliente; (2) definir ware no es un documento estático. Esto es, el equipo del
los riesgos y sugerir técnicas de aversión al riesgo; (3) proyecto consulta el plan repetidamente — actualizando
definir los costes y planificación temporal para la revi riesgos, estimaciones, planificaciones e información rela
sión de la gestión; (4) proporcionar un enfoque general cionada— a la vez que el proyecto avanza y es más cono
del desarrollo del software para todo el personal rela cido.
„ RESUMEN
La planificación temporal es la culminación de una acti nificación temporal se convierte en un m apa de carre
vidad de planificación, com ponente prim ordial de la teras a seguir por el gestor del proyecto.
dirección de proyectos de software. Cuando se com bi La p la n ific a c ió n tem p o ral em p iez a con la d e s
nan métodos de estim ación y análisis de riesgo, la pla com posición del proceso. Las características del pro-
www.FreeLibros.org
12 En realidad, el tiem po extra será gastado en volver a trabajar en
los defectos de requisitos, pero este trabajo tendrá lugar cuando se
em prenda el trabajo de diseño.
127
INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO
yecto se em plean para adaptar un conjunto de ta re tico del proyecto, un gráfico de tiem po e in fo rm a
as apropiado al trabajo a realizar. U na red de tareas ción diversa del proyecto. El gestor del proyecto pue
m u estra todas las tareas de in g en iería, sus d e p e n de seguir y controlar todos los pasos del proceso de
dencias con otras tareas y sus duraciones previstas. so ftw a re u sando la p la n ific a c ió n tem p o ra l com o
L a red de tareas se usa para calcular el cam ino crí directriz.
REFERENCIAS
[BR095] Brooks, M., The Mythical Man-Month, ed. Aniver [PRE99] Pressman, R. S., Adaptable Process Model, R. S.
sario, Adison-Wesley, 1995. Pressman&Associates, 1999.
[FLE98] Fleming, Q.W., y J.M. Koppelman, «Earned Valué [PUT92) Putman, L., y W. Myers, Measures fo r Excellence,
Project Management», Crosstalk, vol.l 1, n.° 7, Julio 1998, Yourdon Press, 1992.
p. 19.
[RIG8 1] Riggs, J., Production Systems Planning, Analysis
and Control, 3.- ed., Wiley, 1981.
[HUM95 ] Humphrey, W., A Discipline fo r Software Engine
ering, Addison-Wesley, 1995. [THE93] Thé, L., «Project Management Software That’s IS
Friendly», Datamation, Octubre 1993, pp. 55-58.
(MOD83J Moder, J. J., C. R. Philips y E. W. Davis, Pro
ject Management with CPM, PERT and Precedence Dia- [WIL99] Wilkens, T.T., «Earned Valué, Clear and Simple»,
gramming, 3.- ed., VanNostrad Reinhold, 1983. Primavera Systems, Inc, Abril 1999, p. 2.
[PAG85J Page-Jones, M., Practical Project Management, [ZAF195] Zahniser, R., «Time-boxing for Top Team Perfor
Dorset ffouse, 1985, pp. 90-91. mance», Software Development, Marzo 1995, pp. 34-38.
PROBLEMAS Y PUNTOS A CONSIDERAR

7.1. Las fechas límite «irracionales» son un hecho consuma 7.6. La relación entre el personal y el tiempo no es lineal.
do del negocio del software. ¿Cómo procedería si se encuen Usando la ecuación del software de Putman (descrita en la
tra en esta situación? Sección 7.2.2), desarrolle una tabla que relacione el núme
ro de gente con la duración del proyecto para un proyecto
7.2. ¿Cuál es la diferencia entre una planificación temporal de software que requiera 50.000 LDC y 15 personas-año
macroscópica y una detallada? ¿Es posible dirigir un proyec de esfuerzo (el parám etro de productividad es 5.000 y
to si sólo se desarrolla una planificación temporal macroscó B = 0,37). Asuma que el software debe entregarse en 24
pica? ¿Por qué? meses, más/menos 12 meses.
7.3. ¿Hay algún caso en el que un hito de un proyecto no está 7.7. Asuma que ha sido contratado por una universidad para
sujeto a una revisión? Si es así, proporcione uno o más ejem desarrollar un sistema interactivo para apuntarse a cursos
plos. (OLCRS). Primero, actúe como el cliente (¡si usted es un estu
diante, le resultará fácil!) y especifique las características de
7.4. En la Sección 7.2.1, se presenta un ejemplo de «sobre un buen sistema. [Alternativamente, su profesor le propor
carga de comunicaciones» que puede ocurrir cuando mucha cionará un conjunto de requisitos preliminares para el sistema.!
gente trabaja en un proyecto de software. D esarrolle un Usando los métodos de estimación estudiados en el Capítulo
ejemplo que ilustre cómo unos ingenieros expertos, y con 5, desarrolle una estimación de esfuerzo y duración para un
buenas experiencias en ingeniería del software y que utili OLCRS. Sugiera cómo:
zan revisiones técnicas formales, pueden mejorar el ritmo a) definiría las actividades paralelas de trabajo durante el pro
de producción de un equipo (comparado con la suma de los yecto OLCRS;
ritmos individuales de producción). Pista: puede asumir que
las revisiones reducen el retrabajo y que estas repeticiones b) distribuiría el esfuerzo a lo largo del proyecto;
del trabajo suponen de un 20 a un 40 por 100 del tiempo c) establecería hitos para el proyecto.
de una persona.
7.8. Usando la Sección 7.3 como directriz, calcule el SCT
7.5. Aunque agregar gente a un proyecto atrasado lo puede para OLCRS. Asegúrese de mostrar todo su trabajo. Selec
www.FreeLibros.org
retrasar aún más, hay circunstancias en las que no es verdad. cione un tipo de proyecto y cree un conjunto apropiado de
Descríbalas. tareas para el proyecto.
128
CAPÍTULO 7 P L A N I F I C A C I Ó N TE M P O R A L Y S EG U IM IE N TO DEL P R O D U C T O
7.9. Defina una red de tareas para OLCRS o, alternativamente,

tarea esfuerzo planificado esfuerzo real
para otro proyecto de software que le interese. Asegúrese de
mostrar las tareas e hitos y adjuntar las estimaciones de 1 12,0 12,5
esfuerzo y tiempo para cada tarea. Si es posible, utilice una 2 15,0 11,0
herramienta de programación automática para realizar este 3 13,0 17,0
trabajo. 4 8,0 9,5
7.10. Si dispone de una herramienta de programación auto 5 9,5 9,0
mática, determine el camino crítico para la red definida en el 6 18,0 19,0
problema 7.9. 7 10,0 10,0
7.11. Usando una herramienta de programación automática (si 8 4,0 4,5
es posible) o papel y lápiz (si es necesario), desarrolle un grá 9 12,0 10,0
fico de tiempo para el proyecto OLCRS. 10 6,0 6,5
11 5,0 4,0
7.12. Retine la tarea denominada evaluación del riesgo tec
nológico en la sección 7.4 del mismo modo que se refino el 12 14,0 14,5
ámbito del concepto en la Sección 7.5. 13 16,0 -
14 6,0 -
7.13. Suponga que es un gestor de proyectos de software y
15 8,0 -
que se le ha pedido que calcule estadísticas del valor gana
do para un proyecto de software sencillo. El proyecto tiene Calcule IDP, la varianza de la planificación, el porcentaje pla
56 tareas planificadas que se estima que necesiten 582 per nificado para terminación, el.porcentaje completo IDC y la
sonas-día para realizarlas. Al tiempo que ha sido solicitado varianza del coste para el proyecto.
para realizar el análisis del valor ganado, se han completa
do 12 tareas. Sin embargo, la planificación temporal del pro 7 .1 4 . Es posible utilizar EED como una m étrica para el
yecto indica que se deberían haber completado 15 tareas. seguimiento de errores en un proyecto de software. Estu
Están disponibles los siguientes datos de planificación (en die los pros y los contras de utilizar EED para este propó
personas-día): sito.
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN

McConnel (Rapid Development, Microsoft Press, 1996) También se puede obtener información que merece la pena
presenta un estudio excelente acerca de los aspectos que con en los libros de gestión de proyectos de propósito general.
ducen a una planificación de proyectos de software demasia Entre ellos se encuentran:
do optimista y lo que se puede hacer con ella. O’Connell (How
toRun Successful Projects 11.The Silver Bullet, Prentice Hall, Kezner, H., Project Management: A Systems Approach to
1997) presenta un enfoque paso a paso para la gestión de pro Planning, Scheduling, and Controlling, Wiley, 1998.
yectos que pueden ayudarle a desarrollar una planificación Lewis, J. P., Mastering Project Management: Applying
temporal realista para sus proyectos. Advanced Concepts o f Systems Thinking, Control and Eva-
Los aspectos de la planificación temporal están cubier luation, McGraw-Hill, 1988.
tos en la mayoría de los libros sobre gestión de proyectos
de software. M cConnell (Software Project Survival C ui Fleming y Koppelman (Earned Valué Project M anage
de, Microsoft Press, 1998), Hoffman y Beaumont (A ppli ment, Project Management Institute Publications, 1996) tra
cation Developm ent: M anaging a Project 's Life Cycle, tan con mucho detalle el uso de técnicas de valor ganado para
Midrange Computing, 1997), Wysoki y sus colegas (Ejfec- el seguimiento y control de proyectos.
tive Project Management, Wiley, 1995) y W hitten (M ana En Internet están disponibles una gran variedad de fuentes
ging Software Development Projects, 2.- ed., Wiley, 1995)
de información relacionadas con temas de gestión y planifica
consideran el tema en detalle. Boddie (Crunch Mode, Pren
tice-Hall, 1987) han escrito un libro para todos los gesto ción temporal de proyectos. Se puede encontrar una lista actua
res que «tienen 90 días para hacer un proyecto de seis lizada con referencias a sitios (páginas) web que son relevantes
meses». para la planificación en http://www.pressm an5.com .
www.FreeLibros.org
C A PÍT U L O
G A R A N T Í A DE C A LID A D
8 DEL S O FTW A R E (S Q A /G C S )*
L enfoque de ingeniería del softw are descrito en este libro se dirige h acia un solo ob je
E tivo: p ro d ucir softw are de alta calidad. Pero a m uchos lectores les inquietará la pregunta:
«¿Q ué es la calidad del softw are?»
Philip C rosby [C R 079], en su fam oso libro sobre calidad, expone esta situación:
E l problem a de la gestión de la calidad no es lo que la gente no sabe sobre ella. El problem a es lo que
creen que saben...
A este respecto, la calidad tien e m ucho en com ún con el sexo. Todo el m undo lo quiere. (B ajo ciertas
con d icio n es, por supuesto.) T odo el m undo cree que lo conoce. (Incluso aunque no quiera explicarlo.) T odo
el m undo piensa que su ejecu ció n sólo es cu estió n de seguir las inclinaciones naturales. (D espués de todo,
nos las arreg lam o s de alg u n a form a.) Y, por supuesto, la m ay o ría de la gente piensa que los pro b lem as en
estas áreas están producidos por o tra gente. (C om o si só lo ellos se to m a ran el tiem p o para h acer las cosas
bien.)
A lgunos d esarrolladores de softw are continúan creyendo que la calidad del softw are es algo
en lo que em piezan a preocuparse una vez que se ha generado el código. ¡N ada m ás lejos de la
realidad! L a g arantía de calidad del softw are (S Q A , Softw are Q uality A ssurance G C S, G estión
de calidad del softw are) es u n a actividad de protección (C apítulo 2) que se aplica a lo largo de
todo el p roceso del softw are. L a SQA engloba: (1) un enfoque de gestión de calidad; (2) te c
n o lo g ía de ingeniería del softw are efectiva (m étodos y herram ientas); (3 ) revisiones técnicas
form ales que se aplican durante el proceso del softw are; (4) una estrategia de prueba m ulties-
calada; (5 )e l control de la docum entación del softw are y de los cam bios realizados; (6 ) un p ro
cedim iento que asegure un ajuste a los estándares de desarrollo del softw are (cuando sea posible),
y (7) m ecanism os de m edición y de generación de inform es.
E n este capítulo nos centrarem os en los aspectos de gestión y en las actividades específicas
del p roceso que p erm itan a una organización de softw are asegurar que hace «las cosas co rrec
tas en el m om ento ju s to y de la form a correcta».
VISTAZO RÁPIDO
■'•#? No ss suficiente hablar por repetir. Si un equipo de software apli ¿C uál « s e l p roducto ob tenid o? Para
hablar diciendo que la calidad del soít- ca la calidad a todas las actividades definir una estrategia de SQA para el
jj¿j" warees importante, tienes que: (1) defi de la ingeniería del software, reduci equipo de software se ha creado un
nir explícitamente lo que significa rá la cantidad de trabajo repetido que plan de g ara n tía de calidad del soft
«calidad del software»; (2) crear un con deba realizar. Esto supondrá costes ware. Durante el análisis, diseño y
" ¡unto de actividades que ayuden a más bajos y, lo que es más importan codificación, el producto principal de
|i garantizar que todo producto de la snge te, mejorará el tiempo de llegada ai SQA es un breve informe de la revisión
f lr aiería del soítware presenta alta cali mercado. técnica formal. Durante las pruebas, se
la dad: (3) llevar a cabo actividades de realizan los planes y procedimientos
¿C uáles so n lo s p asos? Antes de que
y. garantía de calidad en cada proyecto de de prueba. También se pueden gene
se puedan iniciar las actividades de
software; 4) utilizar métricas para desa rar otros productos de trabajo relacio
garantía de calidad del software, es
le.'. rrollar estrategias que mejoren el pro nados con la mejora del proceso.
importante definir la «calidad del soft
ceso del software y, como consecuencia. ware» a un número diferente de nive ¿Cómo p u e d o a se g u r a r q u e lo h e
Jí :‘ mejoren la calidad del producto final, iw clto correctam ente? Encontrar los
i' ‘ : : les de abstracción. Una vez que
¿Quién lo h a ce? Todo el que esté rela- comprendes lo que es la calidad, un «Tores antes que pasen a ser defectos!.
J~ cionado con el proceso de ingeniería equipe de software debe identificar un Esto es, trabajar para mejorar tu eficien
3 dél software es responsable de la cali- conjunto de actividades de garantía de cia en la eliminación de errores (Capí
'• dad. . calidad del software que eliminarán tulos 4 y 7), reduciendo de este modo la
y 4 P er q u é e s im portante? Lo puedes los errores de los productos realizados cantidad de trabajo repetido que tiene
L hacer correctamente o lo puedes antes de que ocurran. que hacer tu equipo de software.
www.FreeLibros.org
* N. del T.: En español, GCS. Se conservan las siglas SQA en inglés por estar muy extendido su uso para la jerga infor
m ática. A veces se suelen tra d u c ire sta s siglas tam bién por «Aseguramiento de la Calidad del Software».
131
INGE NIE RÍ A DEL S O F TW A RE . UN E N F O Q U E P R A C T I C O
8.1 C O N C E P T O S DE
Se dice que dos copos de nieve no son iguales. Cierta ¿C óm o se aplica esto al softw are? ¿C óm o puede
m ente cuando se observa caer la nieve, es difícil im a una organización de desarrollo de software necesitar
ginar que son totalmente diferentes, por no m encionar controlar la variación? De un proyecto a otro, quere
que cada copo posee una estructura única. Para obser m os reducir la diferencia entre los recursos necesa
var las diferencias entre los copos de nieve, debemos rios p lan ifica d o s p ara term in ar un p royecto y los
exam inar los especím enes muy de cerca, y quizá con recursos reales utilizados, entre los que se incluyen
un cristal de aumento. En efecto, cuanto m ás cerca los personal, equipo y tiem po. En general, nos gustaría
observemos, m ás diferencias podremos detectar. aseguram os de que nuestro program a de pruebas abar
Este fenómeno, variación entre muestras, se aplica ca un porcentaje conocido del softw are de una entre
a todos los productos del hom bre así como a la creación ga a otra. N o sólo querem os re d u cir el núm ero de
natural. Por ejemplo, si dos tarjetas de circuito «idénti defectos que se extraen para ese cam po, sino tam bién
cas» se examinan muy de cerca, podremos observar que nos gustaría asegurarnos de que los errores ocultos
las líneas de cobre sobre las tarjetas difieren ligeramente tam bién se reducen de una entrego a otra. (Es proba
en la geometría, colocación y grosor. Además, la loca ble que n u estro s clien tes se m o lesten si la tercera
lización y el diámetro de los orificios de las tarj etas tam entrega de un producto tiene diez veces m ás defectos
bién varían. que la anterior.) Nos gustaría reducir las diferencias
en velocidad y precisión de nu estras resp u estas de
soporte a los problem as de los clientes. L a lista se
podría am pliar m ás y más.
-Lcrgente olvtdQ cómo de rápido hiciste un trabajo-
:p» s»m p fB recuerda cómo de bien lo hiciste.
8.1.1. C a l i d a d
El American HeritageDictionary, define la calidad como
E l control de variación es el centro del control de «una característica o atributo de algo». Como un atri
calidad. Un fabricante quiere reducir la variación entre buto de un elemento, la calidad se refiere a las caracte
los productos que se fabrican, incluso cuando se reali rísticas mensurables — cosas que se pueden com parar
za algo relativamente sencillo como la duplicación de con estándares conocidos como longitud, color, propie
disquetes. Seguramente, esto puede no ser un problem a dades eléctricas, maleabilidad, etc.— . Sin embargo, el
— la duplicación de disquetes es una operación de fabri software en su gran extensión, como entidad intelectual,
cación trivial y podem os garantizar que se crean dupli es más difícil de caracterizar que los objetos físicos.
cados exactos de software — . N o obstante, sí existen las m edidas de característi
¿Podemos?. Necesitam os asegurar que las pistas se cas de un programa. Entre estas propiedades se inclu
sitúen dentro de una tolerancia específica para que la yen com plejidad ciclom ática, cohesión, núm ero de
gran m ayoría de las disqueteras puedan leer los dis puntos de función, líneas de código y muchas otras estu
diadas en los Capítulos 19y 24. Cuando se examina un
quetes. Además, necesitam os asegurar que el flujo m ag
nético para distinguir un cero de un uno sea suficiente elemento según sus características mensurables, se pue
para que los detecten las cabezas de lectura/escritura. den encontrar dos tipos de calidad: calidad del diseño
Las m áquinas de duplicación de discos aceptan o recha y calidad de concordancia.
zan la tolerancia. Por consiguiente, incluso un proceso
«sim ple»,com o la duplicación, puede encontrarse con
problem as debidos a la variación entre muestras.
fita:
iiwomenos tiempo hacer una cosa bien
-q » ei^fecor por qué se hizo mal.
\ WiKkworth LeajfeNow
CLAVE
Controlar lo variación es la clave de un producto de alta La calidad de diseño se refiere a las características
calidad. En el contexto del software, nos esforzamos que especifican los ingenieros de software para un ele
en controlarla variación en el proceso que aplicamos, mento. El grado de m ateriales, tolerancias y las especi
recursosque consum lm osy los atributos de calidad ficaciones del rendimiento contribuyen a la calidad del
del productoflnal. diseño. Cuando se utilizan m ateriales de alto grado y se
www.FreeLibros.org
1 Esta sección, escrita por Michael Ctovcky, se ha adaptado de <(Fun-
dam entals of ICO 9000», un libro de trabajo desarrollado para Essen-
tial Software Engineering, un vídeo curriculum desarrollado por R.S.
Pressm an& Asociados, Inc. Reim presión autorizada.
132
CAPÍTULO 8 G A R A N T I A DE C A L I D A D DEL S O F T WA R E
especifican tolerancias más estrictas y niveles más altos cificaciones m ensurables en las que se puedan com
de rendimiento, la calidad de diseño de un producto parar los resultados de cada proceso. El bucle de rea
aumenta, si el producto se fabrica de acuerdo con las lim entación es esencial para reducir los defecto s
especificaciones. producidos.
La calidad de concordancia es el grado de cum pli
miento de las especificacionesde diseño durante su rea 8.1.3. G a r a n t í a d e c a li d a d
lización. Una vez m ás, cuanto m ayor sea el grado de
La garantia de calidad consiste en la auditoría y las fun
cumplimento, m ás alto será el nivel de calidad de con
ciones de inform ación de la gestión. El objetivo de la
cordancia.
garantía de calidad es proporcionar la gestión para infor
En el desarrollo del software, la calidad de diseño
m ar de los datos necesarios sobre la calidad del p ro
comprende los requisitos, especificaciones y el diseño
del sistema. La calidad de concordancia es un aspecto ducto, por lo que se va adquiriendo una visión m ás
centrado principalm ente en la im plem entación. Si la profunda y segura de que la calidad del producto está
cumpliendo sus objetivos. Por supuesto, si los datos pro
implementación sigue el diseño, y el sistema resultan
porcionados mediante la garantía de calidad identifican
te cumple los objetivos de requisitos y de rendimiento,
problem as, es responsabilidad de la gestión afrontar los
la calidad de concordancia es alta.
Pero, ¿son la calid ad del diseño y la calid ad de problem as y aplicar los recursos necesarios para resol
concordancia los Unicos aspectos que deben co n si ver aspectos de calidad.
derar los in g en iero s de softw are? R o b ert G lass
[GLA98] establece para ello una relación m ás «intui
tiva»:
satisfacción del usuario = producto satisfactorio+buena cali-
Se puede encontrar una gran variedad de recursos de
dad+ e n treg a d entro de p re su
puesto y del tiem po establecidos calidad del software en
www.qual¡tytree.corn/l¡nks/l¡nks.htm
En la última línea, Glass afirma que la calidad es impor
tante, pero si el usuario no queda satisfecho, ninguna otra
cosarealmente importa. DeMarco [DEM99] refuerza este 8.1.4. C o s te d e c a li d a d
punto de vista cuando afirma: «La calidad del producto El coste de calidad incluye todos los costes acarreados
es una función de cuánto cambia el mundo para mejor.» en la búsqueda de la calidad o en las actividades rela
Esta visión de la calidad establece que si el producto de cionadas en la obtención de la calidad. Se realizan estu
software proporciona un beneficio sustancial a los usua- dios sobre el coste de calidad para proporcionar una línea
nos finales, pueden estar dispuestos para tolerar proble base del coste actual de calidad, para identificar oportu
mas ocasionales del rendim iento o de fiabilidad. nidades de reducir este coste, y para proporcionar una
base norm alizada de comparación. La base de normali
zación siempre tiene un precio. U na vez que se han nor
8.1.2, C o n tro l d e c a li d a d
m alizado los costes de calidad sobre un precio base,
El control de cambios puede equipararse al control de tenem os los datos necesarios para evaluar el lugar en
calidad. Pero, ¿cómo se logra el control de calidad? El donde hay oportunidades de m ejorar nuestros procesos.
control de calidad es una serie de inspecciones, revi Es más, podem os evaluar cóm o afectan los cambios en
siones y pruebas utilizados a lo largo del proceso del térm inos de dinero.
software para asegurar que cada producto cum ple con L o s costes de calidad se pueden div id ir en costes
los requisitos que le han sido asignados. El control de asociados con la prevención, la evaluación y los fallos.
calidad incluye un bucle de realim entación (feedback) Entre los costes de prevención se incluyen:
del proceso que creó el producto. L a com binación de
• planificación de la calidad,
medición y realim entación perm ite afinar el proceso
cuando los productos de trabajo creados fallan al cum • revisiones técnicas formales,
plir sus especificaciones. Este enfoque ve el control de • equipo de pruebas,
calidad como parte del proceso de fabricación. • formación. ,
¿Cuáles son
f l i ¿Qué es el control de calidad
los componentes
del softw are?
del coste de calidad?
Las actividades de control de calidad pueden ser Entre los costes de evaluación se incluyen activida
manuales, com pletam ente autom áticas o una com bi des para tener una visión m ás profunda de-la condición
nación de herram ientas autom áticas e interacción del producto «la prim era vez a través de» cada proce
www.FreeLibros.org
humana. Un concepto clave del control de calidad es so. A continuación se incluyen algunos ejemplos de cos
que se hayan definido todos los productos y las espe tes de evaluación:
133
INGENI ER ÍA DEL S O F T W A R E . UN E N F O Q U E P R A C T I C O
inspección en el proceso y entre procesos, Se han ded icad o 7.053 horas inspeccionando 200.000 lí
neas de código con el resultado de 3.1 12 errores potenciales
calibrado y mantenim iento del equipo,
descubiertos. D ando por sentado un coste de program ador de
pruebas. 4 0 dólares por hora, el coste de elim inar 3.1 12 defectos ha sido
de 282.120 dólares, o aproxim adam ente unos 91 dólares por
defecto.
^C O W S E iO ^.
C om pare estos núm eros con el coste de elim in ació n de
No tengo miedo de incurrir en costes significativos defectos una v e z q u e el p ro ducto se ha enviado al cliente.
de prevención. Esé segura de que su inversión Suponga que no ha habido inspecciones, pero que los progra
le proporcionará un beneficio excelente.
m adores han sido m uy cuidadosos y solam ente se ha escapa
do un defecto por 1.000 líneas de código [significativam ente
m ejor que la m edia en industrial] en el producto enviado. Eso
Los costes de fa llo s son los costes que desapare significaría que se tendrían que corregir todavía 200 defectos
cerían si no surgieran defectos antes del envío de un en la casa del cliente o después de la entrega. A un coste esti
producto a los clientes. Estos costes se pueden sub- m ado de 25.000 dólares por reparaciónde cam po, el coste sena
dividir en costes de fallos internos y costes de fallos de 5 m illones de dólares, o aproxim adam ente 18 veces más
externos. Los internos se producen cuando se detec caro que el coste total del esfuerzo de prevención de defectos.
ta un erro r en el p ro d u cto antes de su envío. Entre
estos se incluyen:
1000- 40-1000
• retrabajo (revisión), veces
• reparación,
• análisis de las m odalidades de fallos. a> 30-70
c 100 veces
Los costes d efa llos externos son los que se asocian 15-40
a veces
a los defectos encontrados una vez enviado el produc
í_
to al cliente. A continuación se incluyen algunos ejem 10
oo veces
plos de costes de fallos externos: <3 10 3 -6
• resolución de quejas, O
> veces
• devolución y sustitución de productos, 1
vez
• soporte de línea de ayuda,
• trabajo de garantía. o
ü
Como es de esperar, los costes relativos para encon
trar y reparar un defecto aumentan dram áticam ente a
Requisitos Diseño Código Prueba Prueba En fase de
m edida que se cambia de prevención a detección y des de de explotación
de el fallo interno al externo. La Figura 8.1, basada en desarrollo sistema
datos recopilados por Boehm [BOE81], ilustra este fenó FIGURA 8.1. Coste relativo de corregir un error.
meno.
Es verdad que IB M produce software utilizado por
^ O N S E J o j^ f
cientos de m iles de clientes y que sus costes por repa
las pruebas son necesarias, pero también ración en casa del cliente o después de la entrega pue
es una forma costosa de encontrar errores. Soste den ser m ás altos que los de organizaciones de software
el tiempo en encontrar errores al comienzo del proceso que construyen sistemas personalizados. Esto, de nin
y podrá reduct significativamente lee costes de pruebas guna m anera, niega los resultados señalados anterior
y depuración. mente. Aunque la organización m edia de software tiene
costes de reparación después de la entrega que son el
Kaplan y sus colegas [KAP95] refuerzan las esta 25 por lOOde los de IBM (¡la m ayoría no tienen ni idea
dísticas de costes anteriores informando con datos anec de cuales son sus costes!), se están im poniendo ahorros
dóticos basados en un trabajo realizado en las en el coste asociados con actividades de garantía y con
instalaciones de desarrollo de IB M en Rochester: trol de calidad.
Hoy en día los responsables expertos de compañías de La tendencia de la calidad comenzó en los años cuarenta
www.FreeLibros.org
todo el m undo industrializado reconocen que la alta cali con el influyente trabajo de W. Edwards Deming
dad del producto se traduce en ahorro de coste y en una [D EM 86], y se hizo la prim era verificación en Japón.
mejora general. Sin embargo, esto no era siempre el caso. Mediante las ideas de Deming como piedra angular, los
134
CAPÍTULO 8 GA R A N T Í A D E C A L I D A D DEL S OF TW AR E
japoneses han desarrollado un enfoque sistemático para M ientras que los dos prim eros pasos se centran en
la eliminación de las causas raíz de defectos en produc el proceso, el paso siguiente llam ado kansei (traducido
tos. A lo largo de los años setenta y ochenta, su trabajo com o «los cinco sentidos») se centra en el usuario del
emigró al mundo occidental y a veces se llam a «gestión producto (en este caso, software). En esencia, exam i
total de calidad (GTC)»2. Aunque la terminología difiere nando la form a en que el usuario aplica el producto,
según los diferentes países y autores, norm alm ente se kunsei conduce a la m ejora en el producto m ism o, y
encuentrauna progresión básica de cuatro pasos que cons potencialm ente al proceso que lo creó.
tituye el fundamento de cualquier programa de GTC. Finalmente, un paso llamado m iryokuteki hinshitsu
amplía la preocupación de la gestión m ás allá del pro
ducto inmediato. Este es un paso orientado a la gestión
que busca la oportunidad en áreas relacionadas que se
C LAVE
pueden identificar observando la utilizació n del p ro
Se puede aplicar GTCal software de computadora. ducto en el mercado. En el m undo del software, mirvo-
El enfoque GTCse centra en la mejora continua
kuteki hinshitsu se podría ver com o un in ten to de
del proceso.
detectar productos nuevos y beneficiosos, o aplicacio
El primer paso se llam a kuizen y se refiere a un sis- nes que sean una extensión de un sistem a ya existente
tana de mejora continua del proceso. El objetivo de kai- basado en computadora.
zen es desarrollar un proceso (en este caso, proceso del
software) que sea visible, repetible y mensurable.
El segundo paso, invocado sólo una vez que se ha
alcanzado kuizen, se llama aturimae hinshitsu. Este paso
examina lo intangible que afecta al proceso y trabaja Se puede encontrar una gran variedadde recursos
para optimizar su im pacto en el proceso. Por ejemplo, paro la mejora continua del procesoyGTCen
el proceso de software se puede ver afectado por la alta deming.eng.clemsom.edu/
rotación de personal que ya en sí m ismo se ve afectado
por reorganizaciones dentro de una com pañía. Puede Para la m ayoría de las com pañías, kuizen debería
ser que una estructura organizativa estable haga mucho ser de preocupación inmediata. Hasta que se haya logra
para mejorar la calidad del software. Atarimae hinshit do un proceso de software avanzado (Capítulo 2), no
su llevaría a la gestión a sugerir cambios en la forma en hay m uchos argum entos para seguir con los pasos
que ocurre la reorganización. siguientes.
1 8 f i TI ñ N T l A J g £ J C L A L I B A I L & £ L S Q £ I M & B ^
Hasta el desarrollador de software m ás agobiado esta- ware. Para los propósitos de este libro, la anterior defini
xá de acuerdo con que el software de alta calidad es una ción sirve para hacer hincapié en tres puntos importantes:
meta importante. Pero, ¿cómo definírnosla calidad? Un 1. Los requisitos del software son la base de las m edi
tom ista dijo una vez: «Cualquier program a hace algo das de la calidad. La falta de concordancia con los
bien, lo que puede pasar es que no sea lo que nosotros requisitos es una falta de calidad.
queremos que haga». 2. Los estándares especificados definen un conjunto de
■ ■ ¿Cómo se define «calidad criterios de desarrollo que guían la form a en que se
w del software))? aplica la ingeniería del software. Si no se siguen esos
criterios, casi siempre habrá falta de calidad.
En los libros se han propuesto muchas definiciones 3. Existe un conjunto de requisitos im plícitos que a
,&calidad del software. Por lo que a nosotros respecta, m enudo no se m encionan (por ejemplo: el deseo por
la calidad del software se define como: facilitar el uso y un buen m antenimiento). Si el soft
Concordancia con los requisitos fun cio n ales y d e rendi- ware se ajusta a sus requisitos explícitos pero falla
mientoexplícitamente establecidos.con los estándaresde desa en alcanzar los requisitos implícitos, la calidad del
rrollo explícitam ente docum entados, y con las características software queda en entredicho.
implícitas que se espera de todo softw are desarrollado profe
sionalmente. 8.3.1. P r o b le m a s d e fo n d o
No hay duda de que la anterior definición puede ser La historia de la garantía de calidad en el desarrollo de
modificada o ampliada. De hecho, no tendría fin una dis software es paralela a la historia de la calidad en la crea
cusión sobre una definición formal de calidad del soft ción de hardware. Durante los primeros años de la infor-
www.FreeLibros.org
2 Consulte [ART92) para un estudio m ás com pleto del GTC y su uso
en un contexto de softw are.y [KAP95] para un estudio sobre el uso
de criterio «Balbridge Award» en el m undo del software.
135
mática (los años cincuenta y sesenta), la calidad era res des de SQAque se enfrentan con la planificación de garan
ponsabilidad únicamente del programador. Durante los tía de calidad, supervisión, mantenimiento de registros,
años setenta se introdujeron estándares de garantía de análisis e informes. Éstas son las actividades que realizan
calidad para el software en los contratos militares para (o facilitan) un grupo independiente de SQA:
desarrollo de software y se han extendido rápidam ente Establecimiento de un p la n de SQA p a ra un proyec
a los desarrollos de softw are en el m undo com ercial to. El plan se desarrolla durante la planificación del pro
[IEE94]. A m pliando la definición presentada anterior yecto y es revisado por todas las partes interesadas. Las
m ente, la garantía de calidad del software (SQA) es un actividades de garantía de calidad realizadas por el equi
«patrón de acciones planificado y sistemático»[SCH97] po de ingeniería del software y el grupo SQA son gober
que se requiere para asegurar la calidad del software. El nadas por el plan. El plan identifica:
ámbito de la responsabilidad de la garantía de calidad se
• evaluaciones a realizar,
puede caracterizarmejor parafraseandoun popular anun
cio de coches: «La calidad es la 1.a tarea.» La im plica • auditorías y revisiones a realizar,
ción para el softw are es que m uchos de los que • estándares que se pueden aplicar al proyecto,
constituyen una organización tienen responsabilidad de • procedim ientos para inform ación y seguimiento de
garantía de calidad del software — ingenieros de soft errores,
ware, jefes de proyectos, clientes, vendedores, y aque
• docum entos producidos por el grupo SQA,
llas personas que trabajan dentro de un grupo de SQA—r
• realim entación de inform ación proporcionada al
equipo de proyecto del software.
¿Cuál es el papel
Referencia Mfefa/ *
de un grnpo de SQA?
Se puede encontrar untutorial profundo y amplios
recursos para la gestión de calidaden
Participación en el desarrollo de la descripción del
www.management.gov
proceso de software delproyecto. El equipo de ingenie
ría del software selecciona un proceso para el trabajo
El grupo de SQA sirve como representación del clien que se va a realizar. El grupo de SQA revisa la descrip
te en casa. Es decir, la gente que lleva a cabo'la SQA ción del proceso para ajustarse a la política de la empre
debe m irar el software desde el punto de vista del clien sa, los estándares internos del software, los estándares
te. ¿Satisface de form a adecuada el software los facto im puestos externam ente (por ejemplo: ISO 9001), y a
res de calidad apuntados en el C apítulo 19? ¿Se ha otras partes del plan de proyecto del software.
realizado el desarrollodel softwarede acuerdo con están R evisión de las actividades de ingeniería del soft
dares preestablecidos? ¿Han desem peñado apropiada ware p a r a verificar su ajuste cdproceso de software
m ente sus papeles las disciplinas técnicas com o parte definido. El grupo de SQA identifica, docum entay sigue
de la actividad de SQA? El grupo de SQA intenta res la pista de las desviaciones desde el proceso y verifica
ponder a estas y otras preguntas para asegurar que se que se han hecho las correcciones.
m antiene la calidad del software. A uditoría de los productos de software designados
p a ra verificar el ajuste con los definidos com oparte del
8.3.2. A c tiv id a d e s d e SQA proceso del software. El grupo de SQA revisa los pro
ductos seleccionados; identifica, docum enta y sigue la
La garantía de calidad del software com prende una gran
pista de las desviaciones; verifica que se han hecho las
variedad de tareas, asociadas con dos constitutivosdife-
correcciones, e inform a periódicam ente de los resulta
rentes — los ingenieros de software que realizan traba
dos de su trabajo al gestor del proyecto.
jo técnico y un grupo de SQA que tiene la responsabilidad
A segurar que las desviaciones del trabajo y los pro
de la Planificación de garantía de calidad, supervisión,
ductos del softw are se docum entan y se m anejan de
m antenim iento de registros, análisis e informes— .
acuerdo con un procedim iento establecido. Las des
Los ingenieros de software afrontan la calidad (y rea
viaciones se pueden encontrar en el plan del proyecto,
lizan garantía de calidad) aplicando m étodos técnicos
en la descripción del proceso, en los estándares aplica
sólidos y m edidas, realizando revisiones técnicas for
bles o en los productos técnicos.
m ales y llevando a cabo pruebas de software bien pla
Registrar lo que no se ajuste a los requisitos e infor
nificadas. Solamente las revisiones son tratadas en este
m ar a sus superiores. Los elem entos que no se ajustan
capítulo. Los temas de tecnología se estudian en las Par
a lo s requisitos están bajo seguim iento hasta que se
tes Tercera a Quinta de este libro.
resuelven.
Las reglas del grupo de SQA tratan de ayudar al equi
www.FreeLibros.org
po de ingeniería del software en la consecución de un pro Además de estas actividades, el grupo de SQA coor
ducto final de alta calidad. El Instituto de Ingeniería del dina el control y la gestión de cambios (Capítulo 9) y ayu
Software [PAU93] recomienda un conjunto de activida da a recopilar y a analizar las métricas del software.
136
CAPÍTULO 8 G A R A N T Í A DE CA L I D AD DEL S O L T WA R E
W ftl£ Y IS IQ M E S .Í2 ;E ü L & Q £ .T W A B E ...

Las revisiones del softw are son un «filtro» para el p ro defecto como una «anom alía del p roducto». L a defini
ceso de ingeniería del softw are. E sto es, las revisiones ció n de «fallo» en el c o n tex to del hard w are se puede
Se aplican en v arios m om entos del desarrollo del soft- encontrar en IE E E Standard 610. 12-1990:
wate y sirven para detectar errores y defectos que pue (a) Un defecto en un dispositivo de hardw are o com ponen
dan así ser eliminados. Las revisiones del softw are sirven te: por ejem plo, un corto circuito o un cable roto.
para «purificar» las actividades de ingeniería del so ft (b) U n paso inco rrecto , p ro c e so o d efin ició n de datos en
wareque suceden com o resultado del análisis, el diseño un program a de com putadora. N ota: E sta defin ició n
y la codificación. F re e d m a n y W einberg [FRE90] argu se usa prin cip alm en te por la discip lin a de to leran cia
mentan de la siguiente form a la necesid ad de re v isio n e s: d e fallos. E n su uso no rm al, lo s té rm in o s « e rro r» y
«fallo» se utilizan para expresar este significado. C o n
El trabajo técnico necesita ser revisado por la m ism a razón sulte tam bién: fallo sensible al d a to : fa llo sensible al
que los lápices necesitan gom as: errar es hum ano. L a segunda p rogram a: fa llo s equivalentes: e n m a sc a ra m ie n to de
razón por la que necesitam os revisiones técnicas es que, aun fallos: fallo interm itente.
que la gente es buena descubriendo algunos de sus propios erro
res, algunas clases de errores se le pasan por alto m ás fácilm ente D entro del contexto del proceso del softw are, los té r
al que los origina que a otras personas. El proceso d e revisión m inos defecto y fallo son sinónim os. A m bos im plican
es, por tanto, la respuesta a la plegaria de R obert Bum s: un problem a de calidad que es descubierto después de
¡Qué gran regalo sería poder vem os com o nos ven los dem ás! entregar el softw are a los usuarios finales (o a otra acti
vidad del proceso del softw are). E n los prim eros c a p í
Una revisión — cualquier revisión— es una form a de a pro
vechar la diversidad de un grupo de personas para: tu lo s, se u tiliz ó el térm in o error p a ra re p re se n ta r un
p ro b lem a de calid ad que es d escu b ierto p o r los in g e
1. señalar la necesidad de m ejoras en el producto de una
sola persona o un equipo: nieros del softw are (u otros) antes de en tre g ar el soft
2. confinnarlas partes de un producto en las que no es nece w are al usuario final (o a otra actividad del proceso del
saria o no es deseable una m ejora: y softw are).
3. conseguir un trabajo técnico de una calidad m ás unifor
me, o al m enos m ás predecible, que la que puede ser con
seguida sin re v isio n e s,co n e l Ande h acer m ás m anejable
el trabajo técnico. P a s o d e d e s a rro llo
D e fe c to s D e te c c ió n
Errores inadvertidos
E rro re s
h! igual que los filtros de aguo, las RTF's tienden o
retardarel «flujo» de las actividadesde ingeniería del
d e paso s
a n te r.o re s < !■ ErroresampPbag&fejt.Ñ^ déla detección E rrores
pasados al
software. Muypocos y el flujo es «suelo». Muchos y el dé arrotas s ig u ie n te paso
flujose reducté o ungoteo. Utilicemétricosporo Errores nuevamerte generados
determinar qué revishnes son efectivasy cuáles no.
Saque los que nosean efectivosfuero del flujo. F I G U R A 8 . 2 . M o d e lo d e a m p l if ic a c ió n d e d e f e c t o s .
Existen m uchos tipos diferentes de revisiones que se

El objetivo prim ario de las revisiones técnicas fo r
pueden llevar adelante com o parte de la ingeniería del
m ales es encontrar errores durante el proceso, de form a
software. Cada una tiene su lugar. U n a reunión in fo r
que se conviertan en defectos después de la en treg a del
mal alrededor de la m áquina de café e s una fo rm a de
softw are. El beneficio obvio de estas revisiones téc n i
revisión, si se d iscuten p ro b lem as técnicos. U na p re
cas form ales e s el descubrim iento de errores al prin ci
sentación form al de un diseño de softw are a una audien
p io p a ra que n o se p ro p ag u en al p a so sig u ie n te del
cia de clientes, e jecu tiv o s y p e rs o n a l té c n ic o es una
proceso del softw are.
fam a de revisión. Sin em bargo, en este libro nos c e n
traremos en la revisión técnicaform al (R T F )—a veces
denominada inspección — . U na rev isió n técnica form al
es el filtro m ás efectivo desde el p unto de vista de garan
tía de calidad. L levada a cab o p o r ingenieros del soft
ware (y otros), la R T F es p ara ellos u n m edio efectivo B o b pli\ci principal de una RTF es e r r a ia r errores
para m ejorar la calidad del softw are. arfes de pasar a otra acfc/tíad de rge nerfe
del software o de entregar al dente.
8.4.1. Im pacto d e lo s d efe cto s d e l so ftw a r e so b re U na serie de estudios (T R W ,N ippon Electric y M itre
el co ste
www.FreeLibros.org
C orp., entre otros) indican que las actividades del dise
El IEEE Standard D ictionary o f E léctrical and E lec ñ o introducen entre el 50 al 65 p o r ciento de todos los
tronics Terms (IE E E S ta n d a rd 1 0 0 -1 9 9 2 ) d efin e un errores (y en últim o lugar, todos los defectos) durante
137
el proceso del software. Sin embargo, se ha dem ostra corrige el 50 por 100 de los errores que le llegan, sin intro
do que las revisiones técnicas formales son efectivas en ducir ningún error nuevo (una suposición muy optimis
un 75 por 100 a la hora de detectar errores [JON86], ta). Antes de que comience la prueba, se han amplificado
Con la detección y la elim inación de un gran porcenta diez errores del diseño prelim inar a 94 errores. Al termi
j e de errores, el proceso de revisión reduce substan nar quedan 12 errores latentes. La Figura 8.4 considera
cialmente el coste de los pasos siguientes en las fases las mismas condiciones, pero llevando a cabo revisiones
de desarrollo y de mantenimiento. del diseño y de la codificación dentro de cada paso del
Para ilustrar el im pacto sobre el coste de la detec desarrollo. En este caso los 10 errores del diseño preli
ción anticipada de errores, considerem os una serie de m inar se amplifican a 24 antes del comienzo de la prue
costes relativos que se basan en datos de coste realmente ba. Sólo quedan 3 errores latentes. Recordando los costes
recogidos en grandes proyectos de software [IBM 81]3. relativos asociados con el descubrimientoy la corrección
Supongamos que un error descubierto durante el dise de errores, se puede establecer el coste total (con y sin
ño cuesta corregirlo 1,O unidad monetaria. De acuerdo revisiones para nuestro ejemplo hipotético). El número
con este coste, el m ism o error descubierto justo antes de errores encontrado durante cada paso m ostrado en las
de que com ienza la prueba costará 6,5 unidades; duran figuras 8.3 y 8.4 se m ultiplica por el coste de elim inar un
te la prueba 15 unidades; y después de la entrega, entre error (1.5 unidades de coste del diseño, 6.5 unidades de
60 y 100 unidades. coste antes de las pruebas, 15 unidades de coste durante
las pruebas, y 67 unidades de coste después de la entre
ga. Utilizando estos datos, se puede ver que el coste total
8.4.2. A m plificación y elim inación de defectos para el desarrollo y el mantenim iento cuando se realizan
Se puede usar un m odelo de amplificación de defectos revisiones es de 783 unidades. Cuando no hay revisio
[IBM81] para ilustrarla generacióny detección de erro nes, el coste total es de 2.177 unidades — casi tres veces
res durante los pasos de diseño preliminar, diseño deta m ás caro— .
llado y codificación del proceso de ingeniería del
software. En la Figura 8.2 se ilustra esquemáticamente
el modelo. Cada cuadro representa un paso en el desa
rrollo del software. Durante cada paso se pueden gene enfermedades, como dicen los médicos, en
' zo m fáciles de curar pero difíciles de
rar errores que se pasan inadvertidos. La revisión puede
pero con el paso del tiempo, cuando no
fallar en descubrir nuevos errores y errores de pasos
SÉ-fc» «conocido y trotado al principio, se vuelven
anteriores, produciendo un m ayor núm ero de errores
'f&feude reconocer pero difíciles de curar.
que pasan inadvertidos. En algunos casos, los errores
SSíste JtaHweli
que pasan inadvertidos desde pasos anteriores se am pli
fican (factor de amplificación, x) con el trabajo actual.
Las subdivisiones de los cuadros representan cada una Para llevar a cabo revisiones, el equipo de desarrollo
de estas característicasy el porcentaje de eficienciapara debe dedicar tiem po y esfuerzo, y la organización de
la detección de errores, una función de la profundidad desarrollo debe gastar dinero. Sin embargo, los resulta
de la revisión. dos del ejem plo anterior no dejan duda de que hemos
La Figura 8.3 ilustra un ejemplo hipotético de la ampli encontrado el síndrome de «pague ahora o pague, des
ficación de defectos en un proceso de desarrollo de soft pués, mucho más». Las revisiones técnicas formales (para
ware en el que no se llevan a cabo revisiones. Com o el diseño y otras actividadestécnicas) producen un bene
m uestra la figura, se asum e que cada paso descubre y ficio en coste demostrable. Deben llevarse a cabo.
_ _____________
Una revisión técnica formal (RTF) es una actividad de desarrollado de form a uniform e y (5) hacer que los
garantía de calidad del software llevada a cabo por los proyectos sean m ás m anejables. A dem ás, la RTF sir
ingenieros del software (y otros). L o s objetivos de la ve com o cam po de entrenamiento, permitiendo que los
RTF son: (1) descubrir errores en la función, la lógi ingenieros m ás jó v en es puedan observar lo s diferen
ca o la im plem entación de cualquier representación tes enfoques de análisis, diseño e im plem entación del
del software; (2) verificar que el software bajo revi software. La RTF tam bién sirve para prom over la segu
sión alcanza sus requisitos; (3) garantizar que el soft ridad y la continuidad, ya que varias personas se fami
w are ha sido rep resen tad o de acuerdo con ciertos liarizarán con partes del software que, de otro modo,
están d ares predefinidos; (4) co n seg u ir un softw are no hubieran visto nunca.
www.FreeLibros.org
3 Aunque estos datos son de hace m ás de 20 años, pueden ser apli
cados en un contexto m oderno.
138
CAPÍTULO 8 G A R A N T Í A DE C A L I D A D DEL S O F T WA R E
La RTF es realm ente una clase de revisión que inclu

ye recorridos, inspecciones, revisiones cíclicas y otro C o g ita :
pequeño grupo de evaluaciones técnicas del software. Uñflrstfnióf» es frecuentemente un evento donde
Cada RTF se lleva a cabo mediante una reunión y sólo se as:ove-díaíi uros minutos y se pierden horas.
tendrá éxito si es bien planificada, controlada y atendi ;'s..AAS8tí(te
da. En las siguientes secciones se presentan directrices
similares a las de las inspecciones [FRE90, GIL93] como Con las anteriores limitaciones, debe resultar obvio
representativas para las revisiones técnicas formales. que cada RTF se cen tra en una parte e s p e c ífic a (y
Diseño prelim inar pequeña) del softw are total. Por ejem plo, en lugar de
D is e ñ o d e ta lla d o „ ,
in ten tar re v isa r un d iseñ o co m p leto , se h acen in s
5 Codificación/ pecciones para cada m ódulo (com ponente) o p eq u e
Prueba de unidad
37 ñ o grupo de m ódulos. Al lim itar el centro de atención
Y
de la RTF, la p ro b a b ilid ad de d e sc u b rir e rro res es
mayor.
94 F'rueba de integración
El centro de atención de la RTF es un producto de
Prueba de validación
Al
Para la integración trabajo (por ejem plo, una porción de una esp ecifica
U Prueba del sistem a ción de requisitos, un diseño detallado del m ódulo,

un listado del código fuente de un m ódulo). El in d i
viduo que ha desarrollado el producto — el p r o d u c
to r— inform a al je fe del proyecto de que el producto
está term inado y que se requiere una revisión. El je fe
E rro res latentes
del proyecto contacta con unje fe de revisión, que eva
FIGURA 8.3. Amplificación de defectos, sin revisiones. lúa la disponibilidad del producto, genera copias del
material del producto y las distribuye a dos o tres revi
Diseño preliminar
sores para que se preparen por adelantado. C ada rev i
0
sor estará entre una y dos horas revisando el producto,
D ise ñ o detallado
E¡|| • 7 0 % 1* Codificación/
Prueba de unidad
tom ando notas y tam bién fam iliarizándose con el tra
bajo. De form a concurrente, tam bién el je fe de re v i
P ili L aiSlíSl 5 0 % .
sión revisa el producto y establece una agenda para
. ."■‘ .'2 5; / \ 10 *3 60%
24
la reunión de revisión que, norm alm ente, queda c o n
• 25
24 Prueba d e integración
vocada para el día siguiente.
Para la integración
Prueba de validación
12
¡P 0 50%
Prueba del sistema
1 _ o
50%
C VE
lililí! Ifi: 1 . 0 . _5 0 % la RTFse centra en una porciónrelativamente pequeña
i;'.'/ de un productodetrabajo.
Errores latentes
FIGURA 8.4. Amplificación de defectos, llevando a cabo La reunión de revisión es llevada a cabo por el jefe
revisiones. de revisión, los revisores y el productor. Uno de los revi
sores tom a el papel de registrador, o sea, de persona que
registra (de form a escrita) todos los sucesos im portan
tes que se produzcan durante la revisión. La RTF
8.5.1. l a r e u n ió n d e re v is ió n
com ienza con una explicación de la agenda y una bre
Independientemente del form ato que se elija para la ve introducción a cargo del productor. Entonces el pro
RTF, cualquier reunión de revisión debe acogerse a las ductor procede con el «recorrido de inspección» del
siguientes restricciones: producto, explicando el material, m ientras que los revi
• deben convocarse para la revisión (norm alm ente) sores exponen sus pegas basándose en su preparación
entre tres y cinco personas; previa. Cuando se descubren problem as o errores váli
• se debe preparar por adelantado, pero sin que requiera dos, el registrador los va anotando.
más de dos horas de trabajo a cada persona; y
• la duración de la reunión de revisión debe ser m enor
de dos horas. Referencia W e b l ^
www.FreeLibros.org
Puede descargarseel NASASATC
Cuando realizamos RTF's,
• ¿cuáles son nuestros

objetivos?
formal Inspection Guideboock de
satc.gsfc.nasa.gov/fi/fipage.html
139
I N G E N IE RI A DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
A l final de la revisión, todos los p articipantes en la 1 Revisar elproducto, no alproductor. U na RTF invo
RTF deben decidir si (1) aceptan el p roducto sin p o ste lu cra g en te y egos. C o n d u cid a ad ecu ad am en te, la
riores m o d ificaciones; (2) rech azan el p roducto debido RTF debe llevar a todos los participantes a un senti
a los serios errores encontrados (una v ez corregidos, ha m iento agradable de estar cu m p lien d o su deber. Si
de hacerse o tra revisión) o (3 ) aceptan el producto p ro se lleva a cabo incorrectam ente, la RTF puede tomar
visionalm ente (se han encontrado errores m enores que el aura de inquisición. Se deben señalar los errores
deben ser corregidos, pero sin necesid ad de o tra p o ste edu cad am en te; el to n o de la re u n ió n debe ser dis
rio r re v isió n ). U n a v ez to m a d a la d ecisió n , to d o s los tendido y constructivo; no debe intentarse dificultar
participantes term in an firm ando, indicando así que han o batallar. El je f e de revisión debe m oderar la reu
participado en la rev isió n y que están de acu erd o con n ió n p a ra garantizar que se m antiene un tono y una
las conclusiones del equipo de rev isió n . actitud adecuados y debe inm ediatam ente cortar cual
quier revisión que haya escapado al control.
8.5.2. R e g is tro e in fo rm e d e l a r e v is ió n
D u ran te la RTF, u n o de los rev iso res (el reg istrad o r)
^ W N S E fO ^
procede a reg istrar todas las peg as que v ay an surgien
do. Al final de la reun ió n de revisión, resum e todas las No señóle bruscamente los errores. Uno forma de ser
p egas y genera u n a lista de sucesos de rev isió n . A d e educada es hacer una pregunto que permita al productor
m ás, p repara un inform e sum ario de la rev isió n técnica descubrir su propia errar.
form al. E l inform e sum ario de rev isió n responde a tres

preg u n tas: 2. Fijar una agenda y mantenerla. U n m al de las reu
niones de todo tipo es la deriva. L a RTF debe seguir
1. ¿Q ué fue revisado?
un p lan de trabajo concreto. El je fe de revisión es el
2. ¿Q uién lo revisó? que carga con la responsabilidad de m antener el plan
3. ¿Q ué se descubrió y cuáles son las conclusiones? de la reunión y n o debe te n e r m ied o de cortar a la
E l inform e sum ario de rev isió n es una p ág in a sim gente cuan d o se em piece a divagar.
ple (con p osibles suplem entos). S e adjunta al registro 3. Lim itar el debate y las impugnaciones. C uando un
histórico del p royecto y puede ser en v iad a al je fe del revisor ponga de m anifiesto una pega, p o drá no haber
p royecto y a otras partes interesadas. unanim idad sobre su im pacto. E n lugar de perder el
tie m p o d eb atien d o la cu estión, d eb e registrarse el
hecho y dejar que la cuestión se lleve a cabo en otro
m om ento.
4. Enunciar áreas de problemas, pero no intentar resol
ver cualquier problem a que se p o n g a de manifiesto.
U na revisión no es una sesión de resolución de pro
blem as. A m en u d o , la resolución de los problem as
puede ser encargada al productor p o r s í solo o con
L a lista de su ceso s de revisión sirve p ara d os p ro la ayuda de otra persona. L a resolución de los pro
pósito s: (1) identificar áreas p roblem áticas dentro del blem as debe ser pospuesta para d espués de la reu
p ro d u cto y (2 ) serv ir co m o lista de co m p ro b a c ió n de nión de revisión.
puntos de acción que guíe al p ro d u cto r p ara h acer las
correcciones. N orm alm ente se adjunta u n a lista de c o n
clusiones al inform e sum ario.
Es im portante establecer un procedim iento de segui is tm o de los compensaciones más bonitas
m iento que asegure que los p untos de la lista de suce if c jt í id a , que ningún hombre puede sinceram ente
sos son corregidos adecuadam ente. A m enos que se haga á M s ayuste o otro sin oyudorse a s mismo
fed|p&rWaté» Eomtsm
así, es posible que las peg as surgidas « caig an en saco
roto». U n enfoque consiste en asignar la resp o n sabili
dad del seguim iento al rev iso r je fe 5. Tomar notas escritas. A veces e s b u ena idea que el
registrador tom e las notas en una pizarra, de forma
8.5.3. D ire c tric e s p a r a l a r e v is ió n que las declaraciones o la asignación de prioridades
Se deb en establecer de antem ano directrices p ara co n pueda ser com probada p o r el resto de lo s revisores,
ducir las revisiones técnicas form ales, distribuyéndolas a m edida que se v a registrando la inform ación.
d esp u és en tre los rev iso res, p ara ser c o n sen su ad as y, 6. Lim itar el número de participantes e insistir en lapre-
fin alm en te, seguidas. A m en u d o , u n a rev isió n in co n paración anticipada. D os personas son m ejores que
www.FreeLibros.org
trolad a puede ser p eo r que no h acer ningún tipo de re v i una, pero catorce no son necesariam ente m ejores que
sión. A co ntinuación se m u estra un conjunto m ínim o de cuatro. Se ha de m antener el núm ero de participantes
directrices p ara las revisiones técnicas form ales: en el m ínim o necesario. A dem ás. todos los miembros
140
CAPÍTULO 8 G A R A N T Í A DE C ALI DAD DEL S O F T WA R E
del equipo de revisión deben prepararse por anticipado. 9. L levar a cabo un buen entrenam iento de todos los
El je fe de rev isió n debe solicitar com entarios (que revisores. P or razones de efectividad, todos los p ar
muestren que cada revisor ha revisado el material). tic ip an te s en la revisión deben recibir algún e n tre
7. D esarrollar una lista de com pro b a ción p a r a cada nam iento form al. El entrenam iento se debe b asar en
producto que haya de ser revisado, U n a lista de co m los aspectos relacionados con el proceso, así com o
probaciones ay uda al je f e de rev isió n a estru c tu ra r las consideraciones de psicología hum ana que a ta
la reunión de R T F y ayuda a cada rev isor a centrarse ñen a la revisión. F reed m an y W einberg [FR E 90]
en los asuntos im portantes. Se deb en desarrollar lis estim an en un m es la curva de aprendizaje para cada
tas de com probaciones p ara los docum entos de aná veinte personas que vayan a p articipar de form a efec
lisis, de diseño, de codificación e incluso de prueba. tiv a en las revisiones.
1 0 .R e p a sa r las revisiones anteriores. L as sesiones de
inform ación pueden ser beneficiosas para descubrir
problem as en el propio proceso de revisión. El p ri
m er producto que se haya revisado puede e sta b le
cer las propias directivas de revisión.
C om o existen m uchas variables (por ejem plo, nú m e
ro de participantes, tipo de productos de trabajo, tie m
8. D isponer recursos y una agenda p a r a las RTF. Para po y duración, enfoque de revisión específico) que tienen
que las revisiones sean efectivas, se d eben planificar im pacto en una revisión satisfactoria, una organización
como una tarea del p ro ceso de in g e n iería del so ft de softw are d eb ería d e te rm in ar qué m éto d o fu nciona
ware. A dem ás se debe trazar u n p lan de actuación m e jo r en un c o n te x to local. P o rte r y sus c o le g a s
para las m o d ific a c io n e s in e v ita b le s q ue aparecen [POR95] proporcionan una guía excelente para este tipo
como resultado de u n a RTF. de experim entos.
BL& fiARAHTÍA DE CALIDAD ESTADÍSTICA.

La g arantía de c a lid a d e s ta d ís tic a r e f le ja u n a te n
dencia, crecien te en to d a la in d u stria , a e sta b le c e r la
calidad más c u a n tita tiv a m e n te . P a ra e l so ftw a re , la m m del código tiene el 80 por 100 de los
garantía de calid a d e s ta d ístic a im p lic a lo s sig u ie n te s U coríjalos!.
pasos: Artbwr
1. Se agrupa y se c la s ific a la in fo rm a c ió n so bre los
defectos del softw are. P ara ilustrar el proceso, supongam os que u n a o rg a
2. Se inten ta e n c o n tra r la c a u sa su b y a c e n te de ca d a nización de desarrollo de softw are recoge inform ación
defecto (por ejem plo, no co ncordancia con la esp e sobre defectos durante un período de un año. A lgunos
cificación, e rro r de d iseñ o , in cu m p lim ien to de los de los defecto s se descubren m ientras se d esarro lla el
estándares, pobre co m unicación con el cliente). softw are. O tro s se encuentran d espués de que el so ft
w are se h ay a distribuido al usuario final. A unque se d e s
■ ■ ¿Qué pasos se requieren cu b ren cien to s de erro res d iferen tes, to d o s se p u ed en
w para desarrollar una SQA encontrar en u n a (o m ás) de las siguientes causas:
estadística?
• E specificación incom pleta o erró n ea (EIE).
• M ala interpretación de la com unicación del cliente
3. Mediante el p rincipio de P areto (el 80 p o r 100 de los
(M CC).
defectos se p u e d e n e n c o n tra r en e l 20 p o r 100 de
• D esviación deliberada de la especificación (DD E).
todas las p osibles causas), se aísla el 20 p o r 100 (los
«pocos vitales»). • Incum plim iento de los estándares de program ación
(IEP).
4. Una vez que se han id entificado los defectos vitales,
• E rror en la representación de los datos (ERD).
se actúa p ara correg ir los problem as que han p ro d u
cido los defectos. • Interfaz de m ódulo inconsistente (IM I).
• E rror en la lógica de d iseño (ELD ).
Este concepto relativam ente sencillo representa un
paso im portantehacia la creación de un p roceso de in g e • P rueba incom pleta o errónea (PIE).
www.FreeLibros.org
niería del softw are ad ap tativ o en el cual se realizan c am • D ocum entación im precisa o incom pleta (DII).
bios para m ejo rar aquellos elem entos del proceso que • E rror en la traducción del d iseño al lenguaje de p ro
introducen errores. gram ación (TLP).
141
I N GE NI E RÍ A DEL S OF TWARE. UN E N F O Q U E P R A C T I C O
. Interfaz hom bre-m áquina ambigua o inconsistente En cada etapa del proceso de ingeniería del softwa
(IHM). re se calcula un índice de fa s e , IF ¡ :
• Varios (VAR).
lFi = W ¡ (S ¡/E l)+ W m (M i¡E i) + W ,( T ¡/E|)
El Índice de errores (IE) se obtiene mediante el cálcu

lo del defecto acumulativo de cada IF/, asignando más
Referencia Mfe fe A peso a los errores encontradosm ás tarde en el proceso de
I a Asociación China de Calidad del Software presenta ingeniería del software, que a los que se encuentran en las
uno de los sitios web más completos para la calidad en primeras etapas:
www.cosq.org
I E = X (í x IF,) / PS
Para aplicarla SQA estadística se construye la Tabla = (IF, + 2IF2 + 3IF3 + ... ilFj) / PS
8.1. La tabla indica que EIE, MCC y ERE) son las cau
sas vitales que contabilizan el 53 por 100 de todos los
errores. Sin em bargo, debe observarse que si sólo se Total G rave M oderado Leve
consideraran errores serios, se seleccionarían las siguien
tes causas vitales: EIE, ERE), TLPy ELD. Una vez deter Error No. % No. % No. % No. %
m inadas las causas vitales, la organización de desarrollo
de software puede com enzar la acción correctiva. Por IEE 205 22% 34 27% 68 18% 103 24%
ejemplo, para corregir la M CC, el equipo de desarrollo
del software podría im plem entar técnicas que facilita MCC 156 17% 12 9% 68 18% 76 17%
ran la especificación de la aplicación (Capítulo 1 ljp ara
m ejorar la calidad de la especificación y la com unica DDE 48 5% 1 1% 24 6% 23 5%
ción con el cliente. Para m ejorar el ERD, el equipo de
desarrollo del software podría adquirir herram ientas IEP 25 3% 0 0% 15 4% 10 2%
CASE para la m odelización de datos y realizar revisio
ERD 130 14% 26 20% 68 18% 36 8%
nes del diseño de datos más rigurosas.
Es im portante destacar que la acción correctiva se
IMI 58 6% 9 7% 18 5% 31 7%
centra principalmente en las causas vitales. Cuando éstas
son corregidas, nuevas candidatas saltan al principio de ELD 45 5% 14 12 3% 19 4%
11%
la lista.
Se han m ostrado las técnicas de garantía de calidad PIE 95 10% 12 9% 35 9% 48 11%
del software estadísticas para proporcionar una mejora
sustancial en la calidad [ART97], En algunos casos, las DII 36 4% 2 2% 20 5% 14 3%
organizaciones de software han conseguido una reduc
ción anual del 50 por 100 de los errores después de la TLP 60 6% 15 12% 19 5% 26 6%
aplicación de estas técnicas.
Junto con la recopilación de información sobre defec IHM 28 3% 3 2% 17 4% 8 2%
tos, los equipos de desarrollo del software pueden cal
cular un índice de errores (IE )para cada etapa principal VAR 56 6% 0 0% 15 4% 41 9%
del proceso de ingeniería del software [IEE94]. D es
pués del análisis, el diseño, la codificación, la prueba y Totales 942 100% 128 100% 379 100% 435 100%
la entrega, se recopilan los siguientes datos:
T A B L A 8.1. Recolección de datos para la SQA estadística
E¡ = número total de defectos descubiertos durante la eta
pa i-ésima del proceso de ingeniería del software;
S¡ = núm ero de defectos graves; Se puede utilizar el índice de errores ju n to con la
M¡ =número de defectos m oderados; información recogida en la Tabla 8.1, para desarrollar
una indicación global de la mejora en la calidad del soft
T¡ = núm ero de defectos leves;
ware.
P S =tam año del producto (LDC, sentencias de diseño, La aplicación de la SQA estadística y el principio de
páginas de docum entación) en la etapa i-ésima. Pareto se pueden resum ir en una sola frase: j Utilizar el
W y, W,„ , Wt = factoresde peso de errores graves, m ode tiempo p a ra centrarse en cosas que realmente intere
rados, y leves, en donde los valores recomendados san, p ero prim ero asegurarse que se entiende qué es lo
son Ws = 10. Wm = 3, Wt = 1. Los factores de peso que realmente interesa!
www.FreeLibros.org
de cada fase deberían agrandarse a m edida que el Un estudio exhaustivo de la SQA estadística se sale
desarrollo evoluciona. Esto favorece a la organi del alcance de este libro. Los lectores interesados debe
zación que encuentra los errores al principio. rían consultar [SCH98], [KAP95] y [KAN95],
142
CAPÍTULO 8 G A R A N T I A DE C A L I D A D DEL S O F T WA R E
No hay duda de que la fia b ilid a d de un p ro g ra m a de

computadora es un elem ento im portante de su calidad
general. Si un pro g ram a falla frecuente y rep etidam en CLAVE
te en su funcionam iento, no im porta si el re sto de los
Los problemas de la fiabilidad del software se deben casi
factores de calidad son aceptables.
siempre a errores en el diseño o en la implernentación.
T o davía se d ebate sobre la re la c ió n e n tre lo s c o n

ceptos clave de la fiabilidad del hardw are y su aplica-
Referenda bilidad al softw are (por ejem plo, [L IT 89], [R O O 90]).
ECentro de Análisis de Fiabilidad proporciona mucha A u n q u e aún falta p o r e stab le ce r un n e x o irre fu ta b le ,
información útil sobre la fiabilidad, mantenibilidad, m erece la p en a considerar unos cu an to s conceptos que
soporte y calidad en rac.iitri.org conciernen a am bos elem entos de los sistem as.
C on sid eran d o un sistem a b asad o en co m p u tad o ra,
La fiabilidad del so ftw a re , a d ife re n c ia d e o tro s u n a sencilla m ed id a de la fiabilidad es el tiem po m edio
fectores de c a lid a d , p u e d e ser m e d id a o e stim a d a entre fa llo s (T M E F ) , donde;
mediante datos h istó ric o s o de desarro llo . L a fia b ili-
Sdad del softw are se d e fin e en té rm in o s e s ta d ístic o s TM EF = TM DF + TM DR
feomo «la pro b ab ilid ad de o p eració n libre de fallo s de
$n programa de c o m p u tad o ra en un e n to rn o determ i- L as siglas T M D F y T M D R corresponden a tiem po
hadoy durante un tie m p o e sp e c ífic o » [M U S 87], P o r m edio de fallo y tiem po m edio de reparación, resp ecti
'Cjemplo, un p ro g ram a X p u e d e te n e r u n a fia b ilid a d vam ente.
estimada de 0,96 d u ran te un in terv alo de p ro c e so de
ocho horas. En otras p alab ras, si se fu era a eje cu ta r el ¿Porqué es TMEF
programa X 100 v e c e s, n e c e s ita n d o o c h o h o ra s de w una métrica más útil
Ámpo de p roceso (tiem p o de ejecu ció n ), lo p robable que errores/LDC?
ísq u e funcione c o rrectam en te (sin fallo s) 96 de cad a
*100 veces. M uchos in v estig ad o res argum entan que el T M D F
r: Siempre que se h abla de fiabilidad del softw are, sur e s, co n m u ch o , una m e d id a m á s Util que lo s d efec-
ge la pregunta fundam ental: ¿Q ué se entiende p o r el té r to s/K L D C o defecto s/P F . S e n c illa m e n te , el u su a rio
mino fallo? En el contexto de cualq u ier d iscusión sobre final se enfrenta a los fallos, no al núm ero total de erro
calidad y fiabilidad del softw are, el fallo es cualquier res. C om o cad a e rro r de un p rogram a no tien e la m is
falta de conco rd an cia co n los requisitos del softw are. m a tasa de fallo , la c u e n ta total de erro res no es una
Incluso en esta definición existen grados. L os fallos p u e b u e n a in d ica ció n de la fia b ilid ad de un sistem a. P or
den ser sim plem ente d esconcertantes o ser cata stró fi ejem plo, considerem os un program a que h a estado fu n
cos. Puede que un fa llo sea c o rre g id o en se g u n d o s cio n an d o du ran te 14 m eses. M uchos de los erro res del
[mientras que otro lleve sem anas o incluso m eses. Para p ro g ra m a p u e d en p asar d e sap e rc ib id o s du ran te d é c a
[complicar m ás las cosas, la correcció n de un fallo puedas antes de que se detecten. El T M E F de esos e rro
llevar a la introducción de otros errores que, fin al re s p u ed e se r d e 50 e in c lu s o d e 100 años. O tro s
mente, lleven a m ás fallos. erro res, aunque no se hay an d escu b ierto aún, p u ed en
te n e r u n a ta sa de fallo de 18 ó 24 m eses. In clu so aun
que se elim in en to d o s los erro res de la p rim e ra c a te
,7.1. Medidas de fiabilidad y de disponibilidad
goría (los que tienen un gran T M E F ), el im pacto sobre
io s primeros trabajos sobre fiabilidad intentaron extra- la fiab ilid a d del softw are será m uy escaso.
j»lar las m atem áticas de la teo ría de fiabilidad del hard A d e m á s de u n a m e d id a de la fia b ilid a d d eb em o s
ware (por ejem plo: [A L V 64]) a la p re d ic c ió n de la obtener una m edida de la disponibilidad. L a disp o n ib i
fiabilidad del softw are. L a m ay o ría de los m odelos de lid a d del softw are es la probabilidad de que un p ro g ra
habilidad relativos al h ard w are v an m ás o rien tad o s a m a fu n c io n e de ac u e rd o co n los re q u isito s en un
ios fallos debidos al desajuste que a los fallos debidos m om ento dado, y se define com o:
♦defectos de diseño. E n el h ardw are, son m ás p ro b a
bles los fallos debidos al desgaste físico (por ejem plo: D isponibilidad = [T M D F /(T M D F + T M D R )] x 100%
el efecto de la tem peratura, de la corrosión y los g o l
ees) que los fallos relativos al diseño. D esgraciadam ente, L a m e d id a de fia b ilid ad T M E F es igu alm en te se n
¡ el software lo que ocurre es lo contrario. D e hecho, sible al T M D F que al T M D R . L a m e d id a de d is p o n i
www.FreeLibros.org
W s los fallos del softw are, se pro d u cen p o r p ro b le b ilid a d es a lg o m á s se n sib le al T M D R , una m e d id a
mas de diseño o de im plernentación; el desajuste (con in d ire c ta de la fa c ilid a d de m a n te n im ie n to del so ft
sulte el C apítulo 1) no en tra en este panoram a. w are.
143
INGENIERIA DEL SOF TW ARE . UN E N F O Q U E P R Á C T I C O
8.7.2. S e g u r id a d d e l s o f tw a r e
L eveson [LEV 86] d iscu te el im p acto del softw are en -M -
sistem as críticos de seguridad, diciendo: Referencia m b J x
A ntes de que se usara softw are en sistem as críticos de segu Se pueden encontrar documentos sobre la seguridad
ridad, norm alm ente éstos se controlaban m ediante dispositi del software (y un glosario detollodo) que merecen
vos electró n ico s y m ecánicos co n v en cio n ales (no progra- la peno en www.rstcorp.com/hotlist/topics-
m ables). L as técnicas de seguridad de sistem as se diseñaban
safety.html
para hacer frente a fallos aleatorios en esos dispositivos [no
program ables]. L os errores hum anos de diseño n o se c o n si
deraban porque se suponía que todos los defectos producidos vedad y su probabilidad de ocurrencia4. Para que sea
por los errores hum anos se podían evitar o elim inar com ple efectivo, se tiene que analizar el software en el contex
tam ente antes de su distribución y funcionam iento. to del sistema completo. Por ejemplo, puede que un sutil
error en la entrada del usuario (las personas son com
ponentes del sistem a) se m agnifique por un fallo del
software que producen los datos de control que actúan
.Nepoedcimogm cualquier condición que podría de forma inadecuada sobre un dispositivo mecánico. Si
íOUüffiî hundimiento de este borco. lo construcción se dan un conjunto de condiciones externas del entor
navd moderna ha ido más allá de eso. no (y sólo si se dan), la situación inadecuada del dis
L f. SskHc, Capitón del Titonic positivo m ecánico producirá un fallo desastroso. Se
pueden usar técnicas de análisis, com o el análisis del
árbol de f a l lo s [V ES81], la lógica de tiempo real
C u an d o se u tiliza e l softw are co m o parte d e l siste
[JAN86] o los modelos de redes de Petri [LEV87], para
m a de co n tro l, la co m p le jid a d puede au m en tar en un
predecir la cadena de sucesos que pueden producir los
ord en de m ag n itu d o m ás. L os defectos sutiles de dise
riesgos y la probabilidad de que se dé cada uno de los
ño, produ cid o s p o r un error h u m ano — algo que se p u e
sucesos que com ponen la cadena.
de d e s c u b rir y e lim in a r en e l c o n tro l c o n v e n c io n a l
Una vez que se han identificado y analizado los ries
basado en el h a r d w a r e - llegan a ser m u ch o m ás d ifí
gos, se pueden especificar los requisitos relacionados
ciles de descu b rir cu an d o se u tiliza el softw are.
con la seguridad para el software. Esto es, la especifi
L a seguridad del software es u n a actividad de garan
tía de calidad del softw are que se cen tra en la identifi
cación puede contener una lista de eventos no desea
bles y las respuestas del sistema a estos eventos. El papel
cació n y e v a lu a c ió n d e lo s rie s g o s p o te n c ia les que
del software en la gestión de eventos no deseados es
pu ed en p ro d u cir un im pacto n egativo en el softw are y
entonces apropiado.
hacer que falle el sistem a com p leto . S i se p u ed en id en
tificar p ronto los riesgos en el proceso de ingeniería del
softw are podrán especificarse las características del dise |S | ¿Cuál es la diferencia
ñ o del softw are que p erm itan elim inar o con trolar los W entre fiabilidad del softw are
riesgos poten ciales. y seguridad del softw are?
C o m o parte de la seg u rid ad del so ftw are, se puede Aunque la fiabilidad y la seguridad del software están
dirig ir un proceso de análisis y m odelado. Inicialm ente, bastante relacionadas, es im portante entender la sutil
se id e n tific a n los rie sg o s y se c la sific a n p o r s u im p o r diferencia que existe entre ellas. La fiabilidad del soft
tan cia y su g rad o de riesg o . P o r ejem p lo , alg unos de ware utiliza el análisis estadístico para determ inar la
los rie sg o s aso ciad o s co n el c o n tro l b asad o en c o m probabilidad de que pueda ocurrir un fallo del softwa
pu tad o ra del sistem a de co n d u c c ió n de un autom óvil re. Sin embargo, la ocurrencia de un fallo no lleva nece
pod rían ser: sariamente a un riesgo o a un accidente. La seguridad
• P ro d u c e u n a ace le rac ió n in c o n tro la d a que no se del software exam ina los m odos según los cuales los
puede detener. fallos producen condiciones que pueden llevar a acci
• N o responde a la presión del pedal del fren o (dete dentes. Es decir, los fallos no se consideran en vacío,
niéndose). sino que se evalúan en el contexto de un completo sis
• N o responde cuando se activa el contacto.
tem a basado en computadora.
Un estudio completo sobre seguridad del software y
• Pierde o g an a velo cid ad lentam ente.
análisis del riesgo va más allá del ámbito de este libro. Ría
C u an d o se h an id entificado esto s riesgos del siste aquellos lectores que estén más interesados, deberían con
m a, se u tilizan técnicas de análisis p ara asignar su gra- sultar el libro de Leveson [LEV95] sobre este tema.
www.FreeLibros.org
4 Este m étodo es anólogo al m étodo de análisis de riesgos descrito
para la gestión del proyecto de softw are en el capítulo 6. l a princi
pal diferencia es el énfasis en aspectos de tecnología frente a temas
relacionados con el proyecto.
144
CAPÍTULO 8 GARA N T I A DE C ALI DAD DEL S O F T WA R E
EBHEJBA DE ERRORES PARA SOFTW ARE

SiWilliam Shakespeare hubiera escrito sobre las con P ara llevar a cabo la entrada adecuada del m enú para cada apli
cación, un «localizador» (una persona que habla en el idiom a
diciones del ingeniero de software moderno, podría per
local y con la term inología de ese lugar) traduce los m enús de
fectamente haber escrito: «Errar es humano, encontrar acuerda con el idiom a en uso. E l problem a es asegurar que (1)
elerrorrápida y correctamente es divino.» En los años cada entrada de m enú (pueden existir cientos de ellas) se ade-
sesenta, un ingeniero industrial japonés, Shigeo Shin- cue a los están d ares apropiados y que no existan conflictos,
go [SHI86], que trabajaba en Toyota, desarrolló una téc independientem ente del lenguaje que se está utilizando.
nica de garantía de calidad que conducía a la prevención E l u so del p o k a -y o k e p ara la p ru e b a de d iv e rso s
y/o a la temprana corrección de errores en el proceso de m en ú s de ap licació n d e sarro lla d o s en d iferen tes le n
fabricación. Denominado p o h i-yo k e (prueba de erro- guajes, tal y com o se ha descrito anteriorm ente, se d is
‘res),el concepto de Shingo hacía uso de dispositivos cute en un artículo de H arry R obinson [R O B 97]:
poku-yoke — m ecanism osque conducen (1) a la pre N osotros prim ero decidim os dividir el problem a de prue
vención de un problem a de calidad potencial antes de bas de m enús en p artes que puedan ser resueltas m ás fá c il
que éste ocurra, o (2 ) a la rápida detección de proble m ente. N uestro prim er avance para la resolucióndel problem a
mas de calidad si se han introducido ya—r N osotros fue el com prender que ex istíandos aspectos separados para los
encontramos dispositivos p oka-yoke en nuestra vida catálogos de m ensaje. H abía por una parte el aspecto de con
tenidos: las traducciones de texto m uy sim plestales com o cam
cotidiana (incluso si nosotros no tenem os conciencia de
biar m eram ente «Cióse» por la palabra «Ferm er». Puesto que
este concepto). Por ejemplo, el interruptor de arranque el equipo que realizaba las com probaciones no h ablaba de for
d e un coche no trabaja si está m etida una m archa en la m a fluida el lenguaje en el que se p retendía trabajar, teníam os
transmisión autom ática (un dispositivo de prevención); que dejar estos aspectos a traductores expertos del lenguaje.
un pitido de aviso del coche sonará si los cinturones de El segundo aspecto de los catálogos del m ensaje era
seguridad no están bien sujetos (un dispositivo de detec la estructura, las reglas sintácticas que debía obedecer
ción defallos). un catálogo de objetivos adecuadam ente construido. A
Un dispositivo de poku-yoke presenta un conjunto diferencia del contenido, en este caso sí que era posible
de características comunes: para el eq u ip o de com probación el v erificar los aspec
• Es simple y barato —si un dispositivo es demasiado tos estructurales de los catálogos.
complicado y caro, no será efectivo en cuanto a C om o un ejem plo de lo que significa estructura, co n
costo—; siderem os las etiquetas y los m nem ónicos de un m enú
• Es parte del proceso - e s t o es, el dispositivo poka- de aplicación. U n m enú está constituido p o r etiquetas
yoke está integrado en una actividad de ingeniería— ; y sus m nem ónicos (abreviaturas)asociados. C ada m enú,
• Está localizado cerca de la tarea del proceso donde independientem ente de su contenido o su localización,
están ocurriendolos errores —por consiguiente pro debe obedecer las siguientes reglas listadas en la G u ía
porciona una realim entación rápida en cuanto a la de E stilo M o tif
corrección de errores se refiere— . • C a d a n em o té cn ic o debe e sta r co n ten id o en su e ti
queta asociada;
• C ada nem otécnico debe ser único dentro del m enú;
• C ada nem otécnico debe ser un carácter Único;
Referencia m k l v
• C ada nem otécnico debe estar en A SC II.
Se puede obtener una colección completa de recursos
de poka-yoke en E stas reglas son invariantes a través de las localiza
www.campbell.berry.edu/faculty/igrout/ ciones, y pueden ser utilizadas para verificar que un m enú
pokayoke.shtml está correctam ente construidoen la localización objetivo.
E xisten varias posibilidades para realizar la prueba
de errores de los m nem ónicos del m enú:
Aunque el poka-yoke fue originariamente desarro- D ispositivo de prevención. N osotros podem os e sc ri
liadopara su uso en «control de calidad cero» [SHI86] b ir un program a para generar los m nem ónicos autom á
para el hardware fabricado, puede ser adaptado para su ticam en te, dada una lista de etiq u etas en cad a m enú.
Úso en ingeniería del software. Para ilustrar esto, con E ste enfoque evitaría errores, pero el problem a es que
sideremos el problem a siguiente [ROB97]: escoger un m nem ónico adecuado es difícil, y el e sfu e r
Una com pañía de productos de softw are vende el softw are zo requerido para escribir el program a no estaría ju s ti
de aplicación en el m ercado internacional. L os m enús desple- ficado con el beneficio obtenido.
gables y todos los códigos asociados proporcionados con cada
D isp o sitivo de p re v e n c ió n . P o d ríam o s e sc rib ir un
aplicación deben reflejar el lenguaje que se em plea en el lugar
donde se usa. P or ejem plo, el elem ento del m enú del lenguaje program a que prevendría al localizador de elegir unos
www.FreeLibros.org
inglés para «Cióse», tiene el m nem ónico«C » asociadocon ello. m nem ónicos que no satisfagan el criterio. E ste enfoque
Cuando la aplicación se vende en un país de habla francesa, el tam bién evitaría errores, pero el beneficio obtenido sería
mismo elem ento del m enú es «Fermer» con el m nem ónico «F». m ínim o: los m nem ónicos incorrectos son lo suficiente
145
IN GE NI E RÍ A DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
mente fáciles de detectar y corregir después de que apa estructurales de los m enús . Un pequeño «script» poka-
rezcan. yoke leería la tabla, recuperaría los m nem ónicos y eti
Dispositivo de detección. Nosotros podríam os pro quetas a partir del catálogo de m ensajes, y compararía
porcionar un program a para verificar que las etiquetas posteriorm ente las cadenas recuperadas con el criterio
del m enú escogidas y los m nem ónicos satisfacen los establecido descrito anteriormente.
criterios anteriores. Nuestros localizadores podrían eje Los «Scripts» poka-yoke eran pequeños (aproximada
cutar los program as sobre los catálogos de mensaje tra mente 100 líneas), fáciles de escribir (algunos de los escri
ducidos antes de enviarnos a nosotros dichos catálogos. tos estaban en cuanto al tiem po por debajo de una hora)
Este enfoque proporcionaría una realim entación rápida y fáciles de ejecutar. Nosotros ejecutábamos nuestros
sobre los errores y será, probablem ente, un paso a dar «scripts» poka-yoke sobre 16 aplicaciones en la ubicación
en el futuro. en inglés por defecto y en 11 ubicaciones extranjeras. Cada
Dispositivo de detección. Nosotros podríam os escri ubicación contenía 100 m enús para un total de 1.200
bir un programa que verificase las etiquetas y mnemóni- menús. Los dispositivos poka-yoke encontraron 311 crro-
cos del menú, y ejecutara el programa sobre catálogos de res en menús y mnemónicos. Pocos de los problemas que
mensajes después de que nos los hayan devuelto los loca nosotros descubrimos eran como muy llamativos, pero en
lizadores. Este enfoque es el cam ino que actualmente total habrían supuesto una gran preocupación en la prue
estamos tomando. No es tan eficiente como alguno de los ba y ejecución de nuestras aplicaciones localizadas.
r iétodos anteriormente m encionados y puede requerir El ejemplo descrito antes representa un dispositivo
que se establezca una com unicación fluida hacia delan poka-yoke que ha sido integrado en la actividad de prue
te y hacia atrás con los localizadores, pero los errores bas de ingeniería del software. La técnica poka-yoke
detectados son incluso fáciles de corregir en este punto. puede aplicarse a los niveles de diseño, codificacióny
Varios textos pequeños de poka-yoke se utilizaron pruebas y proporciona un filtro efectivo de garantía de
como dispositivos poka-yoke para validar los aspectos calidad.
8.9 EL ESTÁNDAR DE CALIDAD ISO 9001 JM

Esta sección contiene varios objetivos, siendo el prin « ISO 9004-2. Quality M anagem ent and Quality Sys
cipal describir el cada vez más importante estándar inter tem Elements — Parí 2— Este docum ento propor
nacional ISO 9001. El estándar, que ha sido adoptado ciona las directrices para el servicio de facilidades
por m ás de 130países para su uso, se está convirtiendo del software com o soporte de usuarios.
en el m edio principal con el que los clientes pueden ju z Los requisitos se agrupan bajo 20 títulos:
gar la competencia de un desarrollador de software. Uno
de los problem as con el estándar ISO 9001 está en que Responsabilidad de la gestión.
no es específico de la industria: está expresado en tér Inspección, m edición y equipo de pruebas.
minos generales, y puede ser interpretado por los desa- Sistema de calidad.
rrolladores de diversos productos com o cojinetes de Inspección y estado de pruebas.
bolas (rodam ientos), secadores de pelo, autom óviles, Revisión de contrato.
equipam ientos deportivos y televisiones, así com o por Acción correctiva.
desarrolladores de software. Se han realizado m uchos Control de diseño.
documentos que relacionan el estándar con la industria Control de producto no aceptado.
del software, pero no entran en una gran cantidad de Control de documento.
detalles. El objetivo de esta sección es describir lo que Tratam iento, alm acenam iento, empaquetam iento y
significa el ISO 9001 en términos de elementos de cali entrega.
dad y técnicas de desarrollo. Compras.
Para la industria del software los estándares rele Producto proporcionado al comprador.
vantes son: Registros de calidad.
« ISO 9001. Quality System s-M odel/or Quality A y y m - Identificación y posibilidad de seguimientodel producto,
Auditorías internas de calidad.
rance in Design, Development, Production, Insta-
Form ación
llation an d Servicing. Este es un estándar que
Control del proceso
describe el sistema de,calidad utilizado para m ante
Servicios.
ner el desarrollo de un producto que implique diseño.
. ISO 9000-3. G uidclincs/of Application o f ISO 9001 Inspección y estado de prueba.
Técnicas estadísticas.
www.FreeLibros.org
to the D evelopm ent, Supply and M aintainance o f
Softw are. Este es un docum ento esp ecífico que M erece la pena ver un pequeño extracto de la ISO
interpreta el ISO 9001 para el desarrollador de soft 9001. Este le dará al lector una idea del nivel con el que
ware. la ISO 9001 trata la garantía de calidad y el proceso de
146
CAPÍTULO 8 G A R A N T I A DE CALI DAD DEL S O F T W A R E
desarrollo. El extracto elegido proviene de la sección ción del párrafo — es pretendido obviam ente p o r los
1. 1 1 : procesos estándar de ingeniería donde equipos tales
4.11. El equipo de Inspección, medición y pruebas. com o indicadores de calibración y potencióm etros son
habituales— .
H suministradordebe controlar, calibrar y mantenerla ins
pección, medir y probar el equipo, ya sea el dueño el suminis Una interpretación del párrafo anteriores que el dis
trador, prestado o proporcionado por el comprador, para tribuidor debe asegurar que cualquiera de las herram ien
demostrarla conformidaddel producto con los requisitos espe tas de software utilizadas para las pruebas tiene, por lo
cificados. El equipo debe utilizarse de un modo que asegure m enos, la m ism a calidad que el software a desarrollar, y
que se conoce la incertidumbre de la medición y que es con que cualquier prueba del equipo produce valores de medi
sistente con la capacidad de medición requerida.
ción, por ejemplo, los monitores del rendimiento, tienen
Lo prim ero a destacar es su generalidad; se puede una precisión aceptable cuando se compara con la preci
aplicar al d esa rro llad o r de cu alq u ier producto. Lo sión especificadapara el rendimiento en la especificación
segundo a considerar es la dificultad en la interpreta de los requisitos.
Elplan de SQA proporciona un m apa para institucio • docum entos de usuario (por ejem plo: archivos de
nalizar la garantía de calidad del software. El plan, desa ayuda).
rrollado por un grupo de SQA, sirve como plantilla para Además, esta sección define el conjunto m ínim o de
actividades de SQA instituidas para cada proyecto de productos de trabajo que se pueden aceptar para lograr
software. alta calidad.
Los estándares, prácticas y convenciones m uestran
todos los estándares/prácticas que se aplican durante el
•i* proceso de software (por ejemplo: estándares de docu

mentos, estándares de codificación y directrices de revi
sión). Además, se listan todos los proyectos, procesos y
(en algunos casos) métricas de producto que se van a reco
a Plan GCS
ger como parte del trabajo de ingeniería del software.
La sección R evisiones y A uditorías del plan identi
El IEEE [IEEE94] ha recom endado un estándar para
fica las revisiones y auditorías que se van a llevar a cabo
los planes de SQA. Las secciones iniciales describen el
por el equipo de ingeniería del software, el grupo de
propósito y el alcance del docum ento e indican aque
SQA y el cliente. Proporciona una visión general del
llas actividades del proceso del software cubiertas por
enfoque de cada revisión y auditoría.
la garantía de calidad. Se listan todos los documentos
señalados en el p la n de SOA y se destacan todos los La sección Prueba hace referencia al Plan y Procedi
estándares aplicables. La sección de G estión del plan miento de Pruebas del Software (Capítulo 18). También
describe la situación de la SQA dentro de la estructura define requisitos de m antenim iento de registros de prue
organizativa; las tareas y las actividades de SQA y su bas. La Información sobre problem as y acción correcti
emplazamiento a lo largo del proceso del software; así va define procedim ientos para informar, hacer segui
ocmo los papeles y responsabilidades organizativas rela miento y resolver errores y defectos, e identifica las res
tivas a la calidad del producto. ponsabilidades organizativas para estas actividades.
La sección de Documentación describe (por referen El resto del p la n de SOA identifica las herram ientas
cia) cada uno de los productos de trabajo producidos como y métodos que soportan actividades y tareas de SQA;
parte del proceso de software. Entre estos se incluyen: hace referencia a los procedim ientos de gestión de con
figuración del software para controlar el cambio; defi
• documentos del proyecto (por ejemplo: plan del pro ne un enfoque de gestión de contratos; establece métodos
yecto), para reunir, salvaguardar y m antener todos los registros;
• modelos (por ejemplo: DERs, jerarquías de clases), identifica la formación que se requiere para cum plir las
• documentos técnicos (por ejemplo: especificaciones, necesidades del plan y define métodos para identificar,
evaluar, supervisar y controlar riesgos.
planes de prueba),
www.FreeLibros.org
^ J lE S U M E H
L a g arantía de calidad del softw are es u n a «actividad m ostrado extrem adam enteefectiva en el descubrimiento
de p ro tecció n » que se aplica a ca d a p aso del pro ceso de errores.
del softw are. L a SQ A com prende p rocedim ientos para P ara llev ar a cabo adecu ad am en te u n a garantía de
la aplicación efectiv a de m étodos y h erram ien tas, revi calidad del softw are, se deben recopilar, evaluar y dis
siones técnicas form ales, técnicas y estrategias de pru e tribuir todos los datos re lac io n ad o s con el proceso de
ba, d isp o sitiv o sp o k u -y o k e , p rocedim ientos de control in g e n iería del softw are. L a S Q A e sta d ístic a ayuda a
de cam bios, p rocedim ientos de g arantía de ajuste a los m ejorar la calidad del producto y la del proceso de soft
estándares y m ecanism os de m ed id a e inform ación. ware. L os m odelos de fiabilidad del softw are amplían
L a SQ A es com p licad a p o r la com pleja n atu raleza de las m edidas, perm itiendo extrapolar los datos recogidos
la calidad del softw are —un atributo de los program as sobre los defectos, a predicciones de tasas de fallo y de
de com pu tad o ra que se define com o « co n cordancia con fiabilidad.
los requisitos definidos explícita e im plícitam ente» — . R esum iendo, recordem os las palabras de D unn y Ull-
C uando se considera de form a m ás general, la calidad del m an [D U N 82]: «L a garantía de calidad del softwarees
softw are eng lo b a m uchos factores de p roceso y de pro— la guía de los preceptos de gestión y de las disciplinas
ducto diferentes con sus m étricas asociadas. de diseñ o de la garantía de calidad para el espacio tec
L as revisiones del softw are son u n a de las activida nológico y la aplicación de la ingeniería del software.))
des m ás im portantes de la SQ A . L as revisiones sirven L a capacidad para garantizar la calidad es la m edida de
co m o filtros durante todas las actividades de ingeniería m adurez de la disciplina de ingeniería. C uando se sigue
del softw are, elim inando defectos m ientras que no son de fo rm a adecuada esa g u ía anteriorm ente menciona
relativam ente costosos de encontrar y corregir. L a re v i da, lo que se obtiene es la m adurez de la ingeniería del
sión técn ica form al es un a rev isió n específica que se ha softw are.
[ALV64] von Alvin, W. H. (ed.), R eliability Engineering, [GLA98] Glass,R., «Defining Quality Intuitively»,/££,£ 'Soft
Prentice-Hall, 1964. w are,M ayo 1998,pp. 103-104 y 107.
[ANS87] ANSI/ASQC A3-1987, Quality Systems Termino- [HOY98] Hoyle, D ,,/so 9000 Quality Systems Development
logy, 1987. Handbook: A Systems EngineeringApproach, Butterworth-
Heinimann, 1998.
[ART92] Arthur, L. J Improving Software Quality: An Insi-
der’s Guide to TOM, Wiley, 1992. [IBM81] «Implementating Software Inspections», notas del
curso, IBM Systems Sciences Institute, IBM Corporation,
[ART97] Arthur, L. J., «Quantum Improvements in Softwa 1981.
re System Quality», CACA1, vol. 40,n.s 6, Junio 1997,pp.
47-52. [IEE90] Software Quality Assurance: Aíodel Procedures, Ins-
titution of Electrical Engineers, 1990.
[BOE81] Boehm, B., Software Engineering Economías, Pren-
[IEE94] Software Engineering Standards, ed. de 1994, IEEE
tice-Hall, 1981.
Computer Society, 1994
[CR075] Crosby, P., Quality is Free, McGraw-Hill, 1975.
[JAN86] Jahanian, E , y A. K. Mok, «Safety Analysis of
[CR079] Crosby, P., Quality is Free, McGraw-Hill, 1979. Timing Properties of Real Time Systems», IEEE Trctns.
Software Engineering, vol. SE-12,n.° 9, Septiembre 1986,
[DEM86] Deming, W. W., O utofthe Crisis, MIT Press, 1986.
pp. 890-904.
[DEM99] DeMarco, T., «Management Can Make Quality [JON86] Jones, T. C., Programming Productivitv, McGraw-
(Im)possible», presentación de Cutter Summit '99, Bos Hill, 1986. '
ton, MA, 26 de Abril 1999.
[KAN95] Kan, S. H., Me tries and Models in Software Qua
[DIJ76] Dijkstra, E.,A Discipline o f Programming, Prentice- lity Engineering, Addison Wesley, 1995.
Hall, 1976.
[KAP95] Kaplan, C., R. Clark y V. Tang, Secrets o f Softwa
[DUN82] Dunn, R., y R. Ullman, QualityAssurance fo r Com re Quality: 40Innovationsfrom IBM , McGraw-Hill, 1995.
puter Software, McGraw-Hill, 1982.
[LEV86] Leveson, N.G., «Software Safety: Why, What, and
[FRE90] Freedman, D. R, y G. M. Weinberg,Handbook oj How», ACM Computing Surveys, vol. 18,n.e 2, Junio 1986,
Walkthroughs, Inspections and TechnicalReviews, 3.- ed., pp. 125-163.
www.FreeLibros.org
Dorset House, 1990.
[LEV87] Leveson,N. G.,y J.L. Stolzy, «Safety Analysis using
[GIL93] Gilb, T., y D. Graham, Software Inspections, Addi- Petri Nets», IEEE Trans. Software Engineering, vol. SE-13,
son-Wesley, 1993. n.° 3, Marzo 1987, pp. 386-397.
148
CAPÍTULO 8 G A R A N T I A DE CA L I D A D DEL S O F T WA R E
(LEV951 Leveson, N.G., Safeware: System Safety and Com- [ROO90] Rook, J., Software Reliahilitv Handhook, Elsevier,
puters, Addison-Wesley, 1995. 1990. '
PLIN79] Linger, R., H. Mills y B. Witt, Structured Program- [SCH98] Schulmeyer, G. C., y J.I. McManus (eds.), H and
ming, Addison-Wesley, 1979. hook o f Software Oualitv Assurance, Prentice-Hall, 3.a ed.,
JUT89] Littlewood,B„ «Forecasting Software Reliability», 1998. ~ '
en Software Reliahility: Modelling and Identification (S. [SCH94] Schmauch, C.E1., ISO 9000 fo r Software Develo-
Bittanti,ed.), Springer-Verlag, 1989, pp. 141-209. per s, ASQC Quality Press, Milwaukee, WI, 1994.
[MAN96] Manns,T. y M. Coleman, Software Quality Assu- [SCH97] Schoonmaker, S.J.,/SO 9000 fo r Engineers and
rance, MacMillan Press, 1996. Designers, McGraw Hill, 1997.
[MUS87] Musa, J. D., A. Iannino y K. Okumoto, Enginee
[SHI86] Shigeo Shingo, Zero Quality Control: Source h is
ring and Managing Software with Reliahilitv Measures,
pe ction and the Poka-Yoke System, Productivity Press,
McGqrw-Hill, 1987. '
1986. ' '
[PAU93] Paulk, M., et al., Capability M aturiry M odel for
[SOM96] Somerville, I., Softw’are Engineering, 5.a ed., Addi-
Software, SoftwareEngineering Institute, Camegie Mellon
son-Wesley, 1996.
’ University, Pittsburgh, PA, 1993.
[F*OR95] Porter, A., H. Siv, C. A. Toman, y L. G. Votta, «An [TIN96] Tingey, M., Comparing ¡SO 9000, Malcolm Bal-
Experiment to Assess the Cost-Benefits of Code Inspec- dridge y al SEJ CMM para Software, Prentice-Hall, 1996.
tions in-Large Scale Software Development», Proc. Third [TR197] Tricker, R., ISO 9 0 0 0 /o r Small Bussinesses, But-
ACM SIGSOFT Symposium on the Foundations o f Soft terworth-Heinemann, 1997.
ware Engineering, Washington DC, Octubre 1996, ACM
Press, pp. 92-103. [VES81] Veseley, W.E., et al., Fault Tree H andhook, U.S
Nuclear Regulatory Commision, NUREG-0492, Enero
[ROB97] Robinson, H., «Using Poka-Yoke Techniques for 1981.
Early Error Detection», Proc. Sixth International Confe-
rence on Software Testing Analysis and Review (STAR’97), [WI494] Wilson, L. A., 8 stp to Succesful ISO 9000, Cam
1997,pp. 119-142. bridge Interactive Publications, 1996.
8.1. Al principio del capítulo se señaló que «el control de varia 8 . 1 0 . Algunas personas piensan que una RTF debe evaluar el
ción está en el centro del control de calidad». Como todos los estilo de programación al igual que la corrección. ¿Es una bue
programas que se crean son diferentes unos de otros, ¿cuáles na idea? ¿Por qué?
son las variaciones que se buscan y cómo se controlan? Revise la Tabla 8.1 y seleccione las cuatro causas vita
8 .1 1 .
8 .2 ¿Es posible evaluar la calidad del software si el d ie n les de errores serios y moderados. Sugiera acciones correc
ta no se pone de acuerdo sobre lo que se supone que ha de toras basándose en la inform ación presentada en otros
hacer? capítulos.
8.3. La calidad y la fiabilidad son conceptos relacionados, Una organización utiliza un proceso de ingeniería del
8 .1 2 .
pero son fundamentalmente diferentes en varias formas. Dis software de cinco pasos en el cual los errores se encuentran
cútalas. de acuerdo a la siguiente distribución de porcentajes:
8.4. ¿Puede un programa ser correcto y aún así no ser fiable?
Explique por qué. P aso P o rc e n ta je d e e r ro r e s e n c o n tra d o s
8.5. ¿Puede un programa ser correcto y aun así no exhibir una 1 20%
traía calidad? Explique por qué. 2 15%
8.6. ¿Por qué a menudo existen fricciones entre un grupo de 3 15 %
ingeniería del software y un grupo independiente de garantía
de calidad del software? ¿Es esto provechoso? 4 40%
8.7. Si se le da la responsabilidad de mejorar la calidad del 5 10%
software en su organización. ¿Qué es lo primero que haría?
¿Qué sería lo siguiente? Mediante la información de la Tabla 8.1 y la distribución de
porcentajes anterior, calcule el índice de defectos global para
8.8. Además de los errores, ¿hay otras características claras dicha organización. Suponga que PS = 100.000.
dd software que impliquen calidad? ¿Cuáles son y cómo se
pueden medir directamente? 8 . 1 3 . Investigue en los libros sobre fiabilidad del software y
escriba un artículo que explique un modelo de fiabilidad del
8.9. Una revisión técnica formal sólo es efectiva si todo el
www.FreeLibros.org
software. Asegúrese de incluir un ejemplo.
mundo se la prepara por adelantado. ¿Cómo descubriría que
uno de los participantes no se la ha preparado? ¿Qué haría si 8 . 1 4 . El concepto de TMEF del software sigue abierto a deba
fuera el jefe de revisión? te. ¿Puede pensar en algunas razones para ello?
149
IN GE NI E RÍ A DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
8.15. Considere dos sistemas de seguridad crítica que estén 8.17. Sugiera unos cuantos dispositivos poka-yoke quepue*
controlados por una computadora. Liste al menos tres peligros dan ser usados para detectar y/o prevenir errores que son
para cada uno de ellos que se puedan relacionar directamen encontrados habitualmente antes de «enviar» un mensaje
te con los fallos del software. por e-mail.
8.16. Utilizando recursos web y de impresión, desarrolle un 8.18. Adquiera una copia de ISO 9001 e ISO 9000-3. Prepa
tutorial de 20 minutos sobrepoka-yoke y expóngaselo a su cla re una presentación que trate tres requisitos ISO 9001 y cómo
se. se aplican en el contexto del software.
Los libros de Moriguchi {Software Excellence: A Total Qua- Sanders, J., Software Quality: A Fratneworkfor Success
lity Management Guíele, Productivity Press, 1997), Horch in Software Development, Addison-Wesley, 1994.
(Practica 1 Guíele to Software Quality Management, Artech Sumner, F. H. Software QualitvAssurance, MacMillan,
Publishing, 1996) son unas excelentes presentaciones a nivel 1993. '
de gestión sobre los beneficios de los programas formales de Wallmuller, E., Software Quality Assurance: A Practical
garantía de calidad para el software de computadora. Los Approach, Prentice-Hall, 1995.
libros de Deming [DEM86] y Crosby [CR079], aunque no
se centran en el software, ambos libros son de lectura obli Weinberg, G. M., Quality Software Management, 4vols.,
Dorset House, 1992, 1993, 1994y 1996.
gada para los gestores senior con responsabilidadesen el desa
rrollo de software. Gluckman y Roome (EvetydayHeroes of Wilson, R. C., Software Rx: Secrets of Engineering Qua-
the Quulity Movement, Dorset House, 1993) humaniza los lity Software, Prentice-Hall, 1997.
aspectos de calidad contando la historia de los participantes Una antología editada por Wheeler, Bryczynsky y Mee-
en el proceso de calidad. Kan (Metrics anel Moeleh in Soft son (Software Inspection: Industry Best Practice, IEEE Com
ware Quality Engineering, Addison-Wesley, 1995) presenta puter Society Press, 1996) presenta información útil sobre
una visión cuantitativa de la calidaddel software. Manns {Soft esta importante actividad de GCS. Friedman y Voas (Software
ware QualityAssurance, Macmillan, 1996) es una excelente Assessment, Wiley, 1995) estudian los soportes y métodos
introducción a la garantía de calidad del software. prácticos para asegurar la fiabilidad y la seguridad de pro
Tingley (ComperinglSO 9000,Malcom Balelrielge, anel gramas de computadora.
the SEICMMfor Software, Prentice-Hall, 1996)proporciona Musa (SoftwareReliability Engineering: More Reliable
una guía útil para las organizacionesque se esfuerzan en mejo Software, Faster Development and Testing, McGraw-Hill,
rar sus procesos de gestión de calidad. Oskarsson {An ISO 1998) ha escrito una guía práctica para aplicar a las técnicas
9000 Approach to Building Quality Software, Prentice-Hall, de fiabilidad del software. Han sido editadas antologías de
1995) estudia cómo se aplica el estándar ISO al software. artículos importantes sobre la fiabilidad del software por Kapur
Durante los últimos años se han escrito docenas de libros y otros (Contrihutions to Hardware and Software Reability
sobre aspectos de garantía de calidad. La lista siguiente es Modelling, World Scientific Publishing Co., 1999), Gritzails
una pequeña muestra de fuentes útiles: (Reliability,Quality anel Safety ofSoftware-lntemive Systems,
Clapp, J. A., et al., Softw’are Quality Control, ErrorAnaly- Kluwer Academic Publishing, 1997), y Lyu (Handbookof
sis anel Testing, Noyes Data Corp.. Park Ridge, NJ,1995. Software Reliahility Engineering, McGraw-Hill, 1996). Sto-
Dunn, R. H., y R.S. Ullman, TQM for Computer Softwa rey (Safety-Critica1 Computer Systems, Addison-Wesley,
re, McGrawHill, 1994. 1996)y Leveson [LEV95] continúan siendo los estudios más
Fenton, N., R. Whitty y Y. Iizuka, Software Quality Assu completos sobre la seguridad del software publicados hasta
rance and Measurement: Worldwide Industrial Applications, la fecha.
Chapman & Hall, 1994. Además de [SHI86], la técnicapoka-yoke para el software
Ferdinand, A. E., Systems, Software, and Quality Enginee- de prueba de errores es estudiada por Shingo (TheShingoPro-
ring, Van Nostrand Reinhold, 1993. ductionManagement System: Improving Product Quality by
Preventing Defects, Productivity Press, 1989) y por Shimbun
Ginac, F. P., Customer Oriente el Software Quality Assu (Poka-Yoke: Improving Product Quulity by Preventing Defects,
rance, Prentice-Hall, 1998.
Productivity Press, 1989).
Ince, D., ISO 9001 anel Software Quality Assurance, En Intemet están disponibles una gran variedad de fuen
McGraw-Hill, 1994. tes de información sobre la garantía de calidad del software,
Ince, D.,Hn ¡ntroduction to Software Quality Assurance fiabilidad del software y otros temas relacionados. Se puede
and Implementation, McGraw-Hill, 1994. encontrar una lista actualizada con referencias a sitios (pági
Jarvis, A., y V. Crandall, Inroads to Software Quality: nas) web que son relevantes para la calidad del software en
«How To» Guíele anel Toolkit, Prentice-Hall, 1997. http://www.pressman5.com.
CAPÍTULO
Q GESTIÓN DE LA CONFIGURACIÓN
DEL SOFTWARE (GCS/SCM)*
UAN DO se construye software de computadora, los cambios son inevitables. Adem ás,
C los cambios aumentan el grado de confusión entre los ingenieros del software que están
trabajando en el proyecto. La confusión surge cuando no se han analizado los cam bios
antes de realizarlos, no se han registrado antes de implementarlos, no se les han com unicado a
aquellas personas que necesitan saberlo o no se han controlado de m anera que m ejoren la cali
dad y reduzcan los errores. Babich [BAB86] se refiere a este asunto cuando dice:
E l arte de coordinar el desarrollo de softw are para m inim izar.. ,1a confusión, se d enom ina g estión de c o n
figuración. L a gestión de configuración es el arte de identificar, organizar y controlar las m odificaciones que
sufre el softw are que con stru y e un equipo de program ación. L a m eta es m axim izar la prod u ctiv id ad m in i
m izando lo s erro res.
La gestión de configuración del software (GCS) es una actividad de autoprotección que se

aplica durante el proceso del software. Como el cambio se puede producir en cualquier m om en
to, las actividades de GCS sirven para (1) identificar el cam bio, (2) controlar el cam bio, (3)
garantizar que el cambio se im plem enta adecuadamente y (4) inform ar del cambio a todos aque
llos que puedan estar interesados.
Es importante distinguir claramente entre el mantenim iento del software y la gestión de con
figuración del software. El mantenim iento es un conjunto de actividades de ingeniería del soft
ware que se producen después de que el softw are se haya entregado al cliente y e sté en
funcionam iento. La gestión de configuración del software es un conjunto de actividades de
seguimiento y control que com ienzan cuando se inicia el proyecto de ingeniería del software y
term ina sólo cuando el software queda fuera de la circulación.
VISTAZO RÁPIDO
¿Qué es? C uando construim ossoftw arede ¿Por q u é e s im p o rta n te? Si no con q u e n ecesitan conocer los c am b io s son
com putadora, surgen cam bios. D ebido trolam os el cam bio, él nos c o n tro lará a in fo rm ad o s, se realizan los inform es.
a esto, necesitam os controlarlos eficaz nosotros. Y e sto n u n c a e s buen o . Es ¿Cuál e s e l p ro d u cto o b te n id o ? El
m ente. La gestió n d e la configuración m uy fá cil p a r a u n flujo d e c a m b io s P la n d e G e stió n d e la C o n fig u ra c ió n
del softw are (GCS) e s u n conjunto de in co n tro lad o s lle v a r a l c a o s a u n pro d e l S o ftw a re d e fin e la e s tr a te g ia d el
actividades d ise ñ a d a s p a ra controlar el yecto d e so ftw a re correcto. P or e s ta proyecto p a ra la GCS. A d em ás, c u a n
cam bio identificando los productos del razón, la G CS e s u n a p a rte e se n cial de do se re a liz a la G CS form al, el proce
trabajo q u e p ro b a b le m e n te c am b ien , u n a b u e n a g e stió n d el proyecto y u n a so d e control d e l c a m b io p ro v o c a
e stab lecien d o re la c io n e s e n tre e llo s, p rá c tic a fo rm al d e la in g e n ie ría del p e tic io n e s d e c a m b io d e l so ftw a re e
definiendom ecanism os p a ra g estionar softw are. inform es d e ó rd e n e s d e c a m b io s d e
distintas versiones d e estos productos, in g en ie ría .
¿ C u á les so n lo s p a so s? P u e sto q u e
controlando los c am b io s realizad o s, y
m uchos pro d u cto s d e tra b a jo s e o b tie ¿Cómo puedo esta r s e g u r o d e q u e lo
auditando e inform andode los cam bios
n e n c u a n d o s e con stru y e el softw are, h e h ech o correctam ente? C u an d o
realizados. c u a lq u ie r p ro ducto d e tra b a jo p u e d e
c a d a uno d e b e e s ta r id en tificad o u n í
¿Quién lo h a c e ? T odos a q u e llo s q u e v ocam ente. U na vez q u e e s to se h a se r e s tim a d o p a r a se r s u p e rv is a d o y
e sté n in v o lu c ra d o s e n el p ro c e so d e lo g ra d o , s e p u e d e n e s ta b le c e r los controlado: c u an d o c u a lq u ie r c am b io
in g en ie ría d e so ftw a re e s tá n re la cio m ec a n ism o s p a r a el control d e l c a m p u e d a se r se g u id o y a n a liz a d o ; c u a n
nados con la GCS h a s ta cierto punto, bio y d e l a s versiones. P a ra g a ra n tiz a r do c u a lq u ie ra q u e necesite sa b e r a lg o
pero la s p osiciones d e m antenim iento q u e s e m a n tie n e la c a lid a d m ie n tra s so b re a lg ú n c am b io h a sid o in fo rm a
e s p e c ia liz a d a s so n c r e a d a s a v eces se re a liz a n los c a m b io s, se a u d ita el do, lo h a b re m o s re a liz a d o c o rre c ta
p a ra la g estió n d el p roceso d e GCS. proceso. y p a r a a s e g u ra r q u e a q u ello s m ente.
www.FreeLibros.org
* En inglés, Software Configuration M anagem ent.
151
I NGENI ERÍ A DEL S OF TWARE . UN E NF OQUE P R Á C T I C O
.DE-LA C O N F IG ü R A C IÓ N DEL SOFTWARE

El resultado del proceso de ingeniería del software es
una inform ación que se puede dividir en tres amplias ff c o N S E J O ^ .
categorías: (1) program as de com putadora (tanto en for la mayoría de los camblasson justificados, ¡to lamente
ma de código fuente como ejecutable), (2) documentos las cambios. Mejor dbho, esté seguro que tiene
que describen los program as de com putadora (tanto téc los mecanismos preparados poro realizarlos.
nicos como de usuario) y (3) datos (contenidos en el pro
grama o externos a él). Los elementos que componen
toda la inform ación producida como parte del proceso 9.1.1. L ín e a s b a s e
de ingeniería del software se denom inan colectivam en Una línea base es un concepto de gestión de configura
te configuración del software. ción del software que nos ayuda a controlar los cam
A m edida que progresa el proceso del software, el bios sin impedir seriamente los cambiosjustificados.La
núm ero de elem entos de configuración del software IEEE (Estándar IEEE 610.12-1990) define una línea
(ECSs) crece rápidamente. Una especificación del sis base como:
tem a produce un plan del proyecto del software y una U na especificación o producto que se ha revisado formal
especificación de requisitos del softw are (así com o m ente y sobre los que se ha llegado a un acuerdo, y que de ahí
otros docum entos relativos al hardw are). A su vez, en adelante sirve com o base para un desarrollo posteriory que
éstos producen otros documentos para crear una je ra r puede cam biarse solam ente a través de procedim ientos for
m ales de control de cam bios.
quía de inform ación. Si sim plem ente cada ECS p ro
dujera otros ECSs, no habría prácticam ente confusión. Una forma de describir la línea base es mediante una
D esgraciadam ente, en el proceso entra e n ju e g o otra analogía:
variable —el cambio— . El cam bio se puede producir C onsidere las puertas de la cocina en un gran restaurante.
en cualquier m om ento y por cualquier razón. De hecho, Para evitar colisiones,una puerta esta m arcada com o SALIDA
la Primera Ley de la Ingeniería de Sistemas [BER80] y la otra com o E N T R A D A . L as puertas tienen topes que hacen
establece: Sin im portar en qué m om ento del ciclo de que sólo se puedan abrir en la dirección apropiada.
vida del sistem a nos encontrem os, el sistem a cam bia Si un cam arero recoge un pedido en la cocina, lo coloca a i
rá y el deseo de cam biarlo persistirá a lo largo de todo una bandej a luego se da cuenta de que ha cogido un plato equi
el ciclo de vida. vocado, puede cam biar el plato correctorápida e informalmente
antes de salir de la cocina.
Qfita: S in e m b a rg o , si a b a n d o n a la c o c in a , le d a ,e l plato al
c lie n te y lu e g o se le in fo rm a de su e rro r, d e b e seguir el
.N o hoy nado perorar ente excepto el cambio siguiente procedim iento: (1) m irar en la o rden de pedido si
Heródfto, 500 AdC. ha habido alg ú n error: (2 ) discu lp arse in sisten tem en te: (3)
vo lv er a la cocina por la puerta de E N T R A D A : (4 ) expli
¿Cuál es el origen de estos cambios? La respuesta a c ar el pro b lem a, etc.
esta pregunta es tan variada como los cambios mismos.
Sin embargo, hay cuatro fuentes fundamentales de cam
bios: CLAVE
• nuevos negocios o condiciones com erciales que dic Un producto de trabajo de la Ingeniería
tan los cambios en los requisitos del producto o en del software se convierte en una línea base,
las norm as comerciales; solamente después de haber sido revisado y aprobado.
• nuevas necesidades del cliente que dem andan la Una línea base es análoga a la cocina de un restau
m odificación de los datos producidos por sistemas rante. A ntes de que un elem ento de configuración de
de información, funcionalidades entregadas por pro software se convierta en una línea base, el cambio se
ductos o servicios entregados por un sistema basado puede llevar a cabo rápida e informalmente. Sin embar
en computadora; go, una vez que se establece una línea base, pasamos,
• reorganización o crecimiento/reducción del negocio de form a figurada, por una puerta de un solo sentido.
que provoca cambios en las prioridades del proyecto Se pueden llevar a cabo los cambios, pero se debe apli
o en la estructura del equipo de ingeniería del software; car un procedim iento form al para evaluar y verificar
cada cambio.
• restricciones presupuestarias o de planificación que En el contexto de la ingeniería del software, defini
provocan una redefinición del sistema o producto. mos una línea base com o un punto de referencia en el
La gestión de configuración del software (GCS) es un desarrollo del software que queda m arcado por el envío
www.FreeLibros.org
conjunto de actividades desarrolladas para gestionarlos de uno o más elementos de configuración del software
cambios a lo largo del ciclo de vida del software de com y la aprobación del ECS obtenido mediante una revi
putadora. sión técnica formal (Capítulo 8). Por ejem plo, los ele
152
CAPÍTULO 9 GE S T I Ó N DE LA C O N F I G U R A C I Ó N DEL S OF T WARE
mentos de una E specificación de D iseñ o se docum en so de ingeniería del software. Llevado al extremo, se pue
tan y se revisan. Se encuentran errores y se corrigen. de considerar un ECS como una sección individual de
Cuando todas las partes de la especificación se han revi una gran especificación o cada caso de prueba de un gran
sado, corregido y aprobado, la E specificación de D ise conjunto de pruebas. De forma más realista, un ECS es
ño se convierte en una línea base. Sólo se pueden realizar un documento, un conjunto completo de casos de prue
cambios futuros en la arquitectura del software (docu ba o un componente de un programa dado (p. ej., una fun
mentado en la E specificación de D iseño) tras haber sido ción de C++ o un paquete de ADA).
evaluados y aprobados. Aunque se pueden definir las En realidad, los ECSs se organizan como objetos de
líneas base con cualquier nivel de detalle, las líneas base configuración que han de ser catalogados en la base de
más comunes son las que se m uestran en la Figura 9.1. datos del proyecto con un nom bre único. Un objeto de
configuración tiene un nombre y unos atributos y está
^CONSEJO «conectado» a otros objetos mediante relaciones. Efe acuer
do con la Figura 9.2, los objetos de configuración,Espe-
quelabasededatosdelproyecta se montiene
Asegúrese
cificación de Diseño, modelo de datos, componente N,
sobteunentomocontrolodo,centralizado. código fuente y Especificaciónde Prueba, están defini
La progresión de acontecim ientosque conducen a un dos por separado. Sin embargo, cada objeto está relacio
línea base está tam bién ilustrada en la Figura 9.1. Las nado con otros com o m uestran las flechas. Una flecha
tareas de la ingeniería del software producen uno o más curvada representa una relación de com posición.E s decir,
ECSs. Una vez que un ECS se ha revisado y aprobado, modelo de datos y componente N son parte del objeto
se coloca en una base de dato s d el p ro y e c to (también Especificación de Diseño. Una flecha recta con dos pun
denominada biblioteca d el p ro yecto o depósito de soft tas representa una interrelación. Si se lleva a cabo un cam
ware). Cuando un miem bro del equipo de ingeniería del bio sobre el objeto código fuente, las interrelaciones
software quiere hacer modificaciones en un ECS de línea perm iten al ingeniero de software determ inar qué otros
base, se copia de la base de datos del proyecto a un área objetos (y ECSs) pueden verse afectados'.
efe trabajo privada del ingeniero. Sin embargo, este ECS
extraído puede m odificarse sólo si se siguen los contro
les GCS (tratados m ás adelante en este capítulo). Las
flechas punteadas de la Figura 9.1 m uestran el camino
de modificación de una línea base ECS.
m o d ific a d a
Elementos de configuración del software.
j B a s e d e d a to s d e l p ro y e c to
r a p ro b a d a M o d e lo d e da to s
T a re a s R e v is io n e s
4 e n g e n ie ría ► té c n ic a s 1
del s o ftw a re f o rm a le s
i
a lm a c e n a d a ttaeltodadaft*'**—
bfeeñoaaidftrttóñfeó -
Diseñe de módulos —
e x tra íd a
c o n tro les. 'i; ■.
GCS ¡L IN E A S B A S E :
[ E s p e c if ic a r o n d e l s is te m a D escripción de la interfaz
R e q u is ito s d e l s o ftw a re Descripción del algoritmo
E s p e c ific a c io n e s d e d is e ñ o ■?0Uv :y • . ..
I C ó d ig o fu e n te
[P la n e s / P r o c e d im ie n to s / Plano*la potaba
¡D a to s d e p ru e b a ProcedimientoMi
( S is t e m a d e fu n c io n a m ie n to l&iapraá&H
UtueB»
FIGURA 9 .1 . ECS de línea base y base de datos del proyecto. ;Códigofwrde.
9.1.2. E lem en to s d e c o n fig u r a c ió n d e l so ftw a re

Ya hemos definido un elemento de configuración del soft
ware como la inform ación creada como parte del proce- F IG U R A 9 .2 . Objetos de configuración.
www.FreeLibros.org
1 Estas relaciones se tratan en la Sección 9.2.1 y la estructura de la
base de datos del proyecto se trata con detalle en el Capítulo 3 1.
153
—9.2 EL PROCESO DE GCS __________

La gestión de configuración del software es un elemento • ¿Cóm o identifica y gestiona una organización las
importante de garantía de calidad del software. Su res diferentes versiones existentes de un program a (y su
ponsabilidad principal es el control de cam bios. Sin docum entación) de forma que se puedan introducir
embargo, la GCS tam bién es responsable de la identi cambios eficientemente?
ficación de ECSs individuales y de las distintas versio
nes del software, de las auditorías de la configuración • ¿Cóm o controla la organización los cambios antes
del software para asegurar que se desarrollan adecua y después de que el softw are sea distribuido al
damente y de la generación de informes sobre todos los cliente?
cambios realizados en la configuración.
• ¿Quién tiene la responsabilidad de aprobar y de asig
nar prioridades a los cambios?
Referencia • ¿Cómo podemos garantizar que los cambios se han

llevado a cabo adecuadamente?
Las páginas amarillasde gestión de configuración
contienenel listado más complejode los recursosde GCS • ¿Qué m ecanism o se usa para avisar a otros de los
en la web. Para más Información, consultar: cambios realizados?
www.cs.colorado.edu/users/andre/
tonfiguration-managementhtml Estas cuestiones nos llevan a la definición de cinco
tareas de GCS: Identificación, control de versiones, con
Cualquier estudio de la GCS plantea una serie de pre trol de cambios, auditorías de configuración y genera
guntas complejas: ción de informes.
9.3 IDENTIFICACIÓN DE OBIETOS EN LA CONFIGURACIÓN DEL SOFTWARE ü

Para con tro lar y gestionar los elem entos de co n figura
ción, se debe identificar cada uno de form a Única y lu e
go organizarlos m ediante un enfoque orientado a objetos. CLAVE
Se pueden identificar dos tipos de objetos [CH089]: obje Las relacionesestablecidosentre los objetosde
tos básicos y objetos com puestos2. U n objeto básico es conflguraclónpermlten al ¡ngenlerodel software
una «unidad de texto» creado p o r un ingeniero de soft evaluar el impactodel cambio.
w are durante el análisis, diseño, codificación o pruebas.
Por ejem plo, un objeto básico podría ser una sección de Los recursos son «entidades que proporciona, proce
una especificación de requisitos, un listado fuente de un sa, referencia o son, de alguna otra forma, requeridas por
m ódulo o un conjunto de casos pru eb a que se usan para el objeto». [C H 089], por ejemplo, los tipos de datos, las
ejercitar el código. U n objeto com puesto es u n a co lec funciones específicase incluso los nombres de las varia
ción de objetos básicos y de otros objetos com puestos. bles pueden ser considerados recursos de objetos. La rea
De acuerdo con la Figura 9.2, la Especificación de Dise lización es una referencia a la «unidad de texto» para un
no es un objeto com puesto. C onceptualm ente, se puede objeto básico y nulo para un objeto compuesto.
ver com o una lista de referencias con nom bre (identifi La identificación del objeto de configuración tam
cadas) que especifican objetos básicos, tales com o m ode bién debe considerar las relaciones existentes entre los
lo de datos y componente N. objetos identificados. Un objeto puede estar identifica
C ada objeto tiene un conjunto de características d is do como < p arte-d e> un objeto compuesto. La relación
tintas que le identifican de form a Única: un nom bre, una < p arte-d e> define una jerarquía de objetos. Por ejem
descripción,una lista de recursos y una «realización». El plo, utilizando esta sencilla notación
nom bre del objeto es una cadena de caracteres que id en
D iag ram a E -R 1.4 < parte-de> m odelo de datos;
tifica al objeto sin am bigüedad. La d escripción del ob je
M odelo de datos < parte-de> especificación de diseño;
to es una lista de elem entos de datos que identifican:
• el tipo de EC S (por ejem plo: docum ento, program a, creamos una jerarquía de ECSs.
N o es realista asumir que la Única relación entre los
datos) que está representado p o r el objeto;
objetos de la jerarquía de objetos se establece median
• un identificad o r del proyecto; te largos caminos del árboljerárquico. En muchos casos,
• la inform ación de la versió n y/o el cam bio; los objetos están interrelacionados entre ram as de la
www.FreeLibros.org
2 Com o m ecanism os para representar una versión com pleta de la
configuración del softw are se ha propuesto el concepto de objeto
agregado [GUS89]
154
CAPÍTULO 9 G E S T I Ó N DE LA C O N F I G U R A C I Ó N DEL S OF TWARE
jerarquía de objetos. P or ejem p lo , el m odelo de datos [GUS891 para c u alq u ier objeto. E l grafo de ev o lu ció n
está interrelacionadocon los diagram as de flujo de datos d escrib e la h isto ria de los cam b io s de un ob jeto y ap a
(suponiendo que se usa el análisis estructurado) y ta m rece ilu strad o en la F ig u ra 9.3. El ob jeto de co n fig u
bién está interrelacionado con un conjunto de casos de ració n 1.O p a sa la re v isió n y se con v ierte en el o b je to
prueba p ara u n a clase p a rtic u la r de eq u iv alen cia. Las 1.1. A lg u n as co rre ccio n es y cam b io s m ín im o s p ro d u
relaciones a trav és de la estructura se pu ed en rep resen c en las v e rsio n e s 1.1.1 y 1.1.2, que v an seg u id as de
tar de la siguiente form a: u na actualización im portante, re su lta n d o el o b jeto 1.2.
M odelo d e d a to s < in te rre la c io n a d o > m o d e lo d e flu jo d e L a ev o lu ció n de o b jeto 1.O sigue h acia 1.3 y 1.4, pero,
datos; al m ism o tie m p o , una g ra n m o d ific a c ió n del o b je to
M odelo de d a to s < in te rre la c io n a d o > c a so d e p ru e b a de la produce un nuevo cam ino de ev o lu ció n , la versión 2.0.
clase m; A estas do s v ersio n es se les sigue d an d o soporte.
Se p u e d e n re a liz a r ca m b io s en c u a lq u ie r v e rsió n ,
r w a jj.n ijju .u .f c aunque no n ec esa riam e n te en todas. ¿C óm o pued e el
tos modelos de datos y losdlagromasde flujo de datos desarrollador establecer las referencias de todos los co m
se tratan en el Capítulo 12. po n en tes, do cu m en to s, casos de p ru e b a de la v ersió n
1.4.? ¿Cóm o puede saber el departam ento com ercial los
En el prim er caso , la interrelación es entre objetos n om bres de los clientes que en la actualidad tienen la
compuestos, m ientras que en el segundo caso, la re la versión 2.1.? ¿C óm o podem os e star seguros de que los
ción es entre un objeto com puesto (m odelo de datos) cam bios en el código fuente de la versión 2.1 han sido
y un objeto básico (caso de prueba de la clase m). reflejados adecuadam ente en la correspondiente d o c u
Las in terrelaciones en tre los o b jeto s de co n fig u ra m entación de diseño? U n elem en to clave para resp o n
ción se pueden rep resen tar con u n lenguaje de interco der a todas estas preguntas e s la identificación.
nexión de módulos ( L I M ) [N A R 87], U n L IM describe
las interdependencias entre los objetos de configuración
y permite construir autom áticam ente cualq uier versión
do un sistema.
El esquem a de identificación de los objetos de so ft
ware debe ten er en c u en ta que los o b je to s e v o lu c io Herramientas CASEGCS
nan a lo largo del p ro ceso de in g e n ie ría del softw are.
Antes de que un o b jeto se co n v ierta en una línea base, Se han desarrollado varias herram ientas autom áticas
puede cam biar v arias v e c e s,.e in c lu so cu an d o y a es para ayu d aren la tarea de identificación(y otras de GCS).
una línea base, los cam b io s se p re se n ta n con bastan te En algunos casos, se diseña la herram ienta para m antener
frecuencia. Se p u e d e c re a r u n grafo de evolución copias com pletas de las versiones m ás recientes.
CQyiTROL DE VERSIQNES
El control de versiones com bina procedim ientos y herra tip o s d e c a m b io s fu n c io n a le s a p lic a d o s al siste m a
mientas para gestionar las v ersiones de los objetos de [L IE 89],
configuración creados durante el p roceso del softw are.
Clemm [CLE89] describe el control de v ersiones en el
contexto de la GCS:
El esquema que Vd. estableció poro los ECS debería

incorporar el número de versión.
La gestión de configuración perm ite a un usuario especifi

car configuraciones alternativas del sistema de softwarem edian-
te la selección de las v ersio n es a d ec u ad a s. E sto se puede
gestionar asociando atributos a cada versión del softw are y per F IG U R A 9 .3 . G ra fo de evolución.
mitiendo luego especificar [y construir] una configuración des
U na representación de las diferentes versiones de un
cribiendo el conjunto de atributos deseado.
sistem a es el grafo de evolución m ostrado en la F igura
Los « atrib u to s» que se m e n c io n a n p u e d en ser tan 9.3. C a d a n o d o del grafo es un ob jeto c o m p u e sto , es
www.FreeLibros.org
sencillos com o u n n ú m ero e sp ecífico de versión aso decir, una versión com pleta del softw are. Cada versión
ciado a cada o b jeto o tan co m p lejo s co m o u n a cad en a del softw are es una colección de ECSs (código fuente,
de variables ló g ic a s (in d ic a d o re s) q u e e sp e c ifiq u e n do cu m en to s, datos) y cad a versión pued e e sta r c o m
IS5
IN GENIERÍA DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
pu esta de diferentes variantes. P ara ilu strar este co ncep o b jeto s del m ism o n iv el de revisión. U n a variante es
to, considerem os u n a versió n de un sencillo p rogram a u n a colección diferente de objetos del m ism o nivel de
que está form ado p o r los com ponentes 1, 2, 3, 4 y 5 3. El re v isió n y, p o r ta n to , c o e x iste en p a ra le lo co n otras
com ponente 4 sólo se usa cuando el softw are se im ple- variantes. U n a n u eva versión se define cu an d o se reali
m enta para m onitores de color. El com ponente 5 se im ple- zan cam bios significativos en uno o m ás objetos.
m en ta cuando se dispone de m o n ito r m onocrom o. Por E n la pasada década se propusieron diferentes enfo
tanto, se pueden definir dos v ariantes de la versión: (1) ques autom atizados para el control de versiones. La prin
com ponentes 1, 2, 3 y 4; (2) com ponentes 1, 2, 3 y 5. cip al diferencia entre los distintos enfoques está en la
Para construir la variante adecuada de una determ ina sofisticación de los atributos que se usan para construir
da versión de un program a, a cada com ponente se le asig versiones y variantes específicas de un sistem a y en la
na una «tupia de atributos» —una lista de características m ecánica del proceso de construcción.
que definen si se ha de utilizar el com ponente cuando se va
v a ria n te s
a construir una determ inada versión del software— . A cada A
variante se le asigna uno o m ás atributos. Por ejem plo, se
podría usar un atributocolor para definir qué com ponentes
se deben incluir para soporte de m onitores en color.
• M i p s : cambo, incluso un cambio para mejor,

acompañado por desventajos y
O tra fo rm a de establecer los conceptos de la relación

entre com ponentes, v ariantes y v ersiones (revisiones)
es representarlas com o \m fondo de objetos [REI89], De •v
acuerdo con la F ig u ra 9.4, la relació n en tre los objetos
de co nfiguración y los com ponentes, las v ariantes y las F IG U R A 9 .4 . R e p re s e n ta c ió n e n fo n d o d e o b je to s
versiones se pu ed en rep resen tar co m o un espacio tridi d e los c o m p o n e n te s , v a ria n te s y v e rs io n e s
m ensional. U n com ponente co n sta de u n a co lección de [REI89], '
.P.E..CAMBIQS
La realidad del control de cam bio en un contexto m oder
no de ingeniería de softw are ha sido bien resum ida por
Jam es B ach [BA C98] :
estó en mantener el orden en
E l control de cam bio es vital. Pero las fuerzas que lo hacen mantener el cambio en medio
necesario tam bién lo hacen m olesto. N o s preocupam os por el
cam bio porque una dim inuta perturbacion en el código puede
Mfrad North WhHrñsad
crear un gran fallo en el producto. Pero tam bien puede reparar
un gran fallo o habilitar excelentescapacidadesnuevas. N os preo
cupam os por el cam bio porque un desarrollador pícaro puede yectos, el control de cam bios com bina los procedim ien
hacer fracasar el proyecto; sin em bargo las brillantes ideas naci tos hum anos y las herram ientas autom áticas para propor
das en la m ente de estos pícaros, y un pesado proceso de con
c io n a r un m ecan ism o para el control del cam bio. El
trol de cam bio pueden disuadirle de hacer un trabajo creativo.
proceso de control de cam bios está ilustrado esquem áti
B ach reconoce que nos enfrentam os a u n a situacion cam ente en la Figura 9.5. Se hace una p etició n de cam
a equilibrar. M ucho control de cam bio y crearem os pro b ió 4 y se e v alú a para ca lcu la r el esfu erzo técnico, los
blem as. Poco, y crearem os o tro s problem as. posibles efectos secundarios, el im pacto global sobre o ta s
En un gran proyecto de ingeniería de softw are, el cam funciones del sistem a y sobre otros objetos de la confi
bio incontrolado lleva rápidam ente al caos. Para estos pro- guración. L os resultados de la evaluación se presentan
3 En este contexto, el térm ino «com ponente» se refiere a todos los 4 A unque m uchas de las peticiones de cam bio se reciben durante la
www.FreeLibros.org
objetos com puestos y objetos básicos di: un ESC de línea base. Por fase de m antenim iento, en este estudio tom am os un punto de vista
ejem plo, un com ponente de «entrada» puede e star constituido por m ás am plio. Una petición de cam bio puede a p are ce r en cualquier
seis com ponentes de softw are distintos, cada uno responsable de m om ento durante el proceso del software.
una subfunción de entrada.
156
CAPÍTULO 9 GE S TI ÓN DE LA C O N F I G U R A C I Ó N DEL S OF T WAR E
a m o un informe de cambios a la autoridad de control de y de auditoría. El objeto a cambiar es «dado de baja» de

cambios (ACC) —una persona o grupo que toma la deci la base de datos del proyecto; se realiza el cambioy se apli
sión final del estadoy la prioridad del cambio— . Para cada can las adecuadas actividades de SQA. Luego, el objeto
cambio aprobado se genera una orden de cambio de inge es «dado de alta» en la base de datos y se usan los meca
niería (OCI). La OCI describe el cambio a realizar, las res nismos de control de versiones apropiados (Sección 9.4)
tricciones que se deben respetar y los criterios de revisión para crear la siguiente versión del software.
Se reconoce la necesidad del cambio

El usuario suscribe la petición de cambio
El desarrollacior la evalúa
Se genera un informe de cambios
La autoridad de control de cambios decide
La petición queda pendiente de actuación Petición d^ cambio denegada
se genera la OCI
Información del usuario
Asignación personalizadas los objetos
de configuración
"Dar de baja" objetos (elementos)de configuración

Realización del cambio
4
Revisión de cambio (auditoría)
Los elementos de configuración qu^ han cambiado son "dados de alta"
Establecimiento de una Nnea base para la prueba
Realización de actividades de garantía de calidad y de prueba
4
"Promoción" de los cambios para ser incluidos en la siguiente versión (revisión)
Reconstrucción de la versión adecuada del software
Revisión (auditoría) de los cambios en todos los elementos de configuración
i
Cambios incluidos en la nueva versión
Distribución d eta nueva versión
FIG U R A 9 .5 . El proceso de control de cambios.
Objeto de configuración
(versión modificada) Objeto de configuración
Desbloqueo (versión de línea base)
Información de
auditoría
Información
ingeniero de pertenencia Base de datos

de software del proyecto
Objeto de configuración Bloqueo Objeto de configuración
(versión extraída)
www.FreeLibros.org
FIG U R A 9 .6 . Control de acceso y de sincronización.
157
IN GE NI E RÍ A DEL S OF TWARE. UN E N F O Q U E P R Á C T I C O
A ntes de que un ECS se co n v ierta en una línea

base, sólo es necesario aplicar un co n tro l de cambios
in fo rm a l. El que haya desarrollado el ECS en cues
/a confusión conduce a los e rrores-algunas de ellas
tión podrá hacer cualquier cam bio ju stificad o por el
muy serias— Los controles de acceso
y de sincronización evitan la confusión. Implemente
proyecto y por los requisitos técnicos (siem pre que
ambos, inclusa si su enfoque tiene que ser simplificado
los cam bios no im pacten en otros requisitos del sis
para adaptarlo a su culturo de desarrolla. tem a m ás am plios que queden fuera del ám bito de tra
bajo del encargado del desarrollo). U na vez que el
L os p ro c e so s de « alta» y «baja» im plem en tan dos objeto ha pasado la revisión técnica form al y ha sido
elem entos im portantes del control de cam bios - - c o n aprobado, se crea la línea base. U na vez que el ECS
trol de acceso y control de sincronización— . El control se convierte en una línea base, aparece el control de
de acceso gob ierna los derechos de los in g en iero s de c a m b io s a n iv e l de p r o y e c to . A hora, para hacer un
softw are a acceder y m odificar objetos de configuración cam bio, el encargado del d esarro llo debe recibir la
concretos. El control de sincronización asegura que los aprobación del gestor del proyecto (si el cam bio es
cam bios en paralelo , realizados p o r p ersonas d iferen « local») o de la ACC si el cam bio im pacta en otros
tes, no se sobreescriben m utuam ente [H A R89], ECSs. En algunos casos, se dispensa de generar for
El flujo de control de acceso y de sincronización están m alm ente las peticiones de cam bio, los inform es de
esquem áticam ente ilustrados en la Figura 9.6. D e acuer cam bio y las OCI. Sin em bargo, hay que hacer una
do con una petición de cam bio aprobada y una O C I, un evaluación de cada cam bio así com o un seguimiento
ingeniero de softw are da de baja a un objeto de configu y revisión de lo s m ismos.
ración. U na función de control de acceso com prueba que Cuando se distribuye el producto de software a los
el ingeniero tiene autoridad p ara d ar de baja el objeto, y clientes, se instituye el control de cam bios fo rm a l. El
el control de sincronización b loquea el objeto en la base procedim iento de control de cambios formal es el que
de datos del proyecto, de fo rm a que no se puedan hacer aparece definido en la Figura 9.5.
m ás actualizaciones hasta que se haya reem plazado con La autoridad de control de cam bios (ACC) desem
la nueva versión. Fíjese que se pueden d ar de baja otras peña un papel activo en el segundo y tercer nivel de
copias, pero no se podrán hacer otras actualizaciones. El control. D ependiendo del tam año y de las caracterís
ingeniero de softw are m odifica una copia del objeto de ticas del proyecto de softw are, la A C C puede estar
línea base, denom inada versión extraída. Tras la SQ A y com puesta por una persona —el gestor del proyec
la prueba apropiada, se da de alta la versión m odificada to — o por varias personas (por ejem plo, represen
del objeto y se desbloquea el nuevo objeto de línea base. tantes del softw are, del hardw are, de la ingeniería de
Puede que algunos lectores em piecen a sentirse in có las bases de datos, del soporte o del departam ento
m odos con el nivel de burocracia que im plica el proceso com ercial, etc.). El papel de la ACC es el de tener una
anterior. E sta sensación es norm al. Sin la protección ade visión general, o sea, evaluar el im pacto del cambio
cuada, el control de cam bios puede ralen tizar el p ro g re fuera del ECS en cuestión. ¿Cóm o im pactará el cam
so y cre a r un p a p eleo innecesario. L a m ay o ría de los bio en el hardw are? ¿C óm o im pactará en el rendi
desarrolladores de softw are que d isponen de m ecan is m iento? ¿Cóm o alterará el cam bio la percepción del
m os de control de cam bios (d esg raciad am en tela m ay o cliente sobre el producto? ¿Cóm o afectará el cambio
ría no tienen ninguno) han creado varios niveles de control a la calidad y a la fiabilidad? La ACC se plantea estas
para evitar los problem as m en cionados anteriorm ente. y otras m uchas cuestiones.
Opte par un poco mós de controlde cambio 0 cambio es inevitable, excepto

del que pensaba necesitar en un principia. Esprobable pora los máquinas de venta.
que mucha puedo ser la cantidad apropiada. Ivmper Sticker
La id en tificació n ,el control de versiones y el control de ha im plem entado correctam ente? L a respuesta es doble:
cam bios ayudan al equipo de d esarrollo de softw are a (1) revisiones técnicas form ales y (2) auditorías de con
m an te n e r un o rden que, de o tro m o d o , lle v a ría a una figuración del softw are.
situación caótica y sin salida. Sin em bargo, incluso los Las revisiones técnicas form ales (presentadas en deta
www.FreeLibros.org
m ecanism os m ás correctos de control de cam bios hacen lle en el C apítulo 8) se centran en la corrección técnica
un seguim iento al cam bio sólo h asta que se h a g enera del elem ento de configuración que h a sido modificado.
do la OCI. ¿C óm o p odem os asegurar que el cam bio se Los revisores evalúan el ECS para determ inar la con-
158
CAPÍTULO 9 G E S T I Ó N DE LA C O N F I G U R A C I Ó N DEL S O F T WA R E
sistenciacon otros ECSs, las om isiones o los posibles 3. ¿Se ha seguido el proceso del software y se han apli
efectos secundarios. Se debe llevar a cabo una revisión cado adecuadamente los estándares de ingeniería del
técnica formal para cualquier cambio que no sea trivial. software?
Una auditoría de configuración del software com 4. ¿Se han «resaltado» los cambios en el ECS? ¿Se han
plementa la revisión técnica formal al com probar carac especificado la fecha del cam bioy el autor? ¿Reflejan
terísticas que generalm ente no tiene en cuenta la los cambios los atributosdel objeto de Configuración?
revisión. La auditoría se plantea y responde las siguien
tes preguntas: 5. ¿Se han seguido procedim ientos de GCS para seña
lar el cam bio, registrarlo y divulgarlo?
¿ Cuáles son las principales
« preguntas que hacemos en

una auditoría de configuración?
6. ¿Se han actualizado adecuadamente todos los ECSs
relacionados?
En algunos casos, las preguntas de auditoría se inclu
1. ¿Se ha hecho el cambio especificado en la OCI? ¿Se yen en la revisión técnica formal. Sin embargo, cuando
han incorporado m odificaciones adicionales? la GCS es una actividad form al, la auditoría de la GCS
2. ¿Se ha llevado a cabo una revisión técnica form al se lleva a cabo independientem ente por el grupo de
para evaluar la corrección técnica? garantía de calidad.
lA .y INFORMES DE ESTADO________
La generación de informes de estado de la configura
ción. (a veces denom inada contabilidad de estado) es
una tarea de GCS que responde a las siguientes pre Desarrolle una «lista que se necesita conocer»
guntas: (l)¿ Q u é pasó? (2) ¿Quién lo hizo? ^ ¿ C u á n para cadaECS y manténgalo actualizada. Cuando
do pasó? (4) ¿Qué m ás se vio afectado? se realice un cambó, asegúrese que se informa
En la Figura 9.5 se ilustra el flujo de inform ación a todos los que estén en la listo.
para la generación de informes de estado de la confi
guración (IEC). Cada vez que se asigna una nueva iden La generación de informes de estado de la configura
tificación a un ECS o una identificación actualizada se ción desempeña un papel vital en el éxito del proyecto de
genera una entrada en el IEC. C ada vez que la ACC desarrollode software. Cuandoaparece involucrada mucha
aprueba un cambio (o sea, se expide una OCI), se gene gente es muy fácil que se dé el síndrome de que «la mano
ra una entrada en el IEC. Cada vez que se lleva a cabo izquierda ignora lo que hace la mano derecha». Puede que
una auditoría de configuración, los resultados aparecen dos programadores intenten modificar el m ismo ECS con
como parte de una tarea de generación de un IEC. La intenciones diferentes y conflictivas. Un equipo de inge
salida del IEC se puede situaren una base de datos inte niería del software puede em plear meses de esfuerzo en
ractiva [TAY85] de forma que los encargados del desa construir un software a partir de unas especificacionesde
rrollo o del mantenim iento del software puedan acceder hardware obsoletas. Puede que la persona que descubra
a la información de cambios por categorías clave. A de los efectos secundarios senos de un cambio propuesto no
más, se genera un IEC regularm ente con intención de esté enterada de que el cambio se está realizando. El IEC
mantener a los gestores y a los profesionales al tanto de ayuda a elim inar esos problem as, m ejorando la com uni
los cambios importantes. cación entre todas las personas involucradas.
m m m m
La gestión de configuración del software es una activi La configuración del software está com puesta por un
dad de protección que se aplica a lo largo de todo el pro conjunto de objetos interrelacionados, tam bién deno
ceso del software. La GCS identifica, controla, audita e m inados elementos de configuración del software, que
informa de las m odificaciones que invariablemente se se producen como resultado de alguna actividad de inge
dan al desarrollar el software una vez que ha sido dis niería del software. Además de los documentos, los pro
tribuido a los clientes. Cualquier inform ación produci gramas y los datos, tam bién se puede poner bajo control
da como parte de la ingeniería del software se convierte de configuración el entorno de desarrollo utilizado para
www.FreeLibros.org
en parte de una configuración del software. La confi crear el software.
guración se organiza de tal form a que sea posible un U na vez que se ha desarrollado y revisado un obje
control organizado de los cambios. to de configuración, se convierte en una línea base. Los
159
IN GENIERÍA DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
cam b io s sobre un objeto de lín ea base c o n d u cen a la d a q u e se re a liz an ca m b io s en los o b je to s de la con

creación de u na nu ev a versió n del objeto. L a evolución figuración. E l p ro ceso de c o n tro l de cam b io s com ien
de un p ro g ram a se puede seguir exam inando el h isto z a c o n u n a p e tic ió n de c a m b io , lle v a a u n a decisión
rial de las revisiones de todos los objetos de su co n fi de p ro se g u ir o n o co n el c a m b io y c u lm in a con una
guración. L o s objetos básicos y los com puestos form an a c tu a liz a c ió n c o n tr o la d a d e l E C S q u e se h a de
un asociación de objetos que refleja las v ariantes y las cam biar.
v ersiones creadas. E l control de v e rsio n e s es un c o n L a au d ito ría de co n fig u ra ció n es u n a actividad de
ju n to de procedim ientos y herram ientas que se usan para SQ A que ayuda a asegurar que se m antiene la calidad
gestio n ar el uso de los objetos. durante la realización de los cam bios. Los inform es de
E l c o n tro l d e c a m b io s es u n a a c tiv id a d p ro c e d i- estad o proporcionan inform ación sobre cada cam bio a
m ental que asegura la c alidad y la co nsistencia a m ed i aquellos que tienen que estar inform ados.
[ADA89] Adams, E., M. Honda y T. Miller, «Object Mana [IEE94] Software Engineering Standards, edición de 1994,
gement in a CASE Environment», Proc. 11 th Intl. C onf IEEE Computer Society, 1994.
Software Engineering, IEEE, Pittsburg, PA, Mayo 1989,
[LIE89] Lie, A. etal., «Change Oriented Versioning in a Soft
pp. 154-163. ' ware Engineeering Database», Proc. 2nd Intl. Workshop
[BAC98] Bach, J., «The Highs and Lows of Change Con on Software Configuration Management, ACM, Prince
trol», Computer, vol. 31, n.e 8, Agosto 1998,pp. 113-115. ton, NJ, Octubre 1989,pp. 56-65
[BER80J Bersoff, E.H., V.D. Hendersony S. G. Siegel,óo//- [NAR87] Narayanaswamy, K., y W. Scacchi, «Maintatning
ware Configuraron Management, Prentice-Hall, 1980. Configurations of Evolving Software Systems», IEEE
[BRY80] Bryan, W., C. Chadboume,y S. Siegel,So/brare Con- Trans. Software Engineering, vol.SE-13, n.° 3, Marzo
figuration Management, IEEE Computer Society Press, 1980. 1987,pp. 324-334.
[CH089] Choi, S. C., y W. Scacchi, «Assuring the Correct- [REI89] Reichenberger, C., «Orthogonal Versión Manage
ness of a Configured Software Descriptíon», Proc. 2nd ment», Proc. 2nd Intl. Workshop on Software Configura
Intl. Workshop on Software Conftguration Management, tion Management, ACM, Princeton, NJ, Octubre 1989,
ACM, Princeton, NJ, Octubre 1989,pp. 66-75. pp. 137-140.
[CLE89] Clemm, G. M., «Replacing Versión Control with [ROC75] Rochkind, M., «The Source Code Control System»,
Job Control», Proc. 2ndlntl. Workshop on Software Con- IEEE Trans. Software Engineering, vol. SE-1, n." 4, Diciem
figuration M anagement, ACM, Princeton, NJ, Octubre bre 1975,pp. 364-370.
1989,pp. 162-169. [TAY85] Taylor,B., «A Database Approach to Configuration
[GUS89] Gustavsson, A., «Maintaining the Evaluation of Management for Large Projects», Proc. Conf. Software
Software Objects in an Integrated Environment», Proc. Maintenance-1985, IEEE, Noviembre 1985,pp. 15-23.
2nd Intl. Workshop on Software Configuration Manage [TIC82] Tichy, W. F., «Design, Implementation and Evalua
ment, ACM, Princeton, NJ, Octubre 1989, pp. 1 14-117. tion of a Revisión Control System», Proc. 6,h Intl. Conf.
[HAR89] Harter, R., «Configuration Management», YWPro- Software Engineering, IEEE, Tokyo, Septiembre 1982,pp.
fessional, vol.3, n.B6, Junio 1989. 58-67.
9 . 1 . ¿Por qué es cierta la primera ley de la ingeniería de sis mo programa? ¿Se manejaría de forma diferente el código
temas? ¿Cómo afecta a nuestra percepción de los paradigmas fuente que la documentación? ¿Cómo se evitaría que dos pro
de la ingeniería del software? gramadores hicieran cambios diferentes sobre el mismo ECS
al mismo tiempo?
9 .2 .Exponga las razones de la existencia de líneas base con
sus propias palabras. 9.5. Investigue un poco sobre bases de datos orientadas a
objetos y escriba un artículo que describa cómo se podrían
9 .3 . Asuma que es el gestor de un pequeño proyecto. ¿Qué
usar en el contexto de la GCS.
líneas base definiría para el proyecto y cómo las controlaría?
9 .6 .Utilice un modelo E-R (Capítulo 12) para describir las
9 .4 .Diseñe un sistema de base de datos que permita a un
interrelaciones entre los ECS (objetos) de la Sección 9.1.2.
ingeniero del software guardar, obtener referencias de forma
www.FreeLibros.org
cruzada, buscar, actualizar, cambiar, etc., todos los elemen 9 . 7 . Investigue sobre herramientas de GCS existentes y des
tos de la configuración del software importantes. ¿Cómo criba cómo implementan el control de versiones, de cambios
160
CAPÍTULO 9 G E S T I Ó N DE LA C O N F I G U R A C I Ó N DEL S O F T WA R E
9.8. Las relaciones «parte-de» e «interrelacionado» repre 9.10. Utilizando la Figura 9.5 como guía, desarrolle un
sentan relaciones sencillas entre los objetos de configuración. esquema de trabajo más detallado aún para el control de cam
Describa cinco relaciones adicionales que pudieran ser Utiles bios. Describa el papel de la ACC y sugiera formatos para la
en el contexto de la base de datos del proyecto. petición de cambio, el informe de cambios e IEC.
9.9. Investigue sobre una herramienta de GCS existente y 9.11. Desarrolle una lista de comprobaciones que se pueda
describa cómo implementa los mecanismos de control de ver utilizar en las auditorías de configuración.
siones. Alternativamente, lea dos o tres de los artículos a los
que se hace referencia en este capítulo e investigue en las 9 .1 2 . ¿Cuál es la diferencia entre una auditoria de GCS y una
estructurasde datos y los mecanismos que se usan para el con revisión técnica formal? ¿Se pueden juntar sus funciones en
trol de versiones. una sola revisión? ¿Cuáles son los pros y los contras?
jfeTB A S LECTURAS Y FUENTES DE INFORMACIÓN

Uro de los pocos libros escritos sobre la GCS en los últimos de las principales actividades de GC). Rawlings (SCM for
años lo realizaronBrown et al. (AntiPatterns and Patterns in NetWork Development Environments, McGraw-Hill, 1994)
Software ConfigurationManagement, Wiley, 1989). es el primer libro de GCS en tratar el asunto con un énfasis
Los autores tratan las cosas que no hay que hacer (anti específico en el desarrollo de software en un entorno de red.
patrones) cuando se implementa un proceso de GCS y enton W hitgift (Methods and Toolsfor Software Configuration
ces consideran sus remedios. Management, Wiley, 199 1) contiene una razonable cobertu
Lyon(Practical CM: Best Configuration Management ra de todos los temas importantes de GCS, pero se distingue
Practicesfor the 21st Century, Raven Publishing, 1999) y por su estudio del diccionario de datos y tratamiento de aspec
Mikkelsen y Pherigo (Practical Software Configuration tos de entornos CASE. Amold y Bohner (Software Change
Management: TheLatenight Developer’sHandhook, Allyn & Impact Analysis, IEEE Computer Society Press, 1996) han
Bacon, 1997) proporcionan tutoriales practicos importantes editado una antología que estudia cómo analizar el impacto
de GCS. Ben-Menachem {Software Configuration Manage del cambio dentro de sistemas complejos basados en soft
ment Guidebook, McGraw-Hill, 1994), Vacca(Implementing ware.
aSuccessful. Configuration. Change. Management. Program, Puesto que la GCS identifica y controla documentos de
I.S. Management Group, 1993), y Ayer y Patrinnostro (Soft ingeniería del software, los libros de Nagle (Handbookfor
ware Configuration Management, McGrawHill, 1992) pre Preparing Engineering Documents: From Concept. to Com-
sentan correctas visiones para aquellos que todavia no se han pletion, IEEE, 1996), Watts (EngineeringDocumentation
introducido en la materia. Berlack (Software Configuration ControlHandbook: ConfigurationManagementfor Industry,
Management, Wiley, 1992, presenta una estudio Útil de con Noyes Publication, 1993). Ayery Patnnnostro (Documenting
ceptos de la GCS, haciendo incapié en la importancia del dic the Software Process, McGraw-Hill, 1992) proporciona un
cionario de datos (repository) y de las herramientas en la complemento con textos mas centrados en la GCS. La edi
gestion del cambio. Babich [BAB86] es un tratado abrevia ción de Marzo de 1999 de Crosstalk contiene vanos artícu
do, aunque eficaz, de temas practicos sobre la gestión de con los Útiles de la GCS.
figuración del software. En Internet están disponibles una gran variedad de fuen
Buckley (Implementing ConfigurationManagernent, IEEE tes de información relacionadas con temas de gestión y de
Computer Society Press, 1993) estudia enfoques de gestión software. Se puede encontrar una lista actualizada con refe
de configuraciónpara todos los elementos de un sistema (hard rencias a sitios (páginas) web que sonrelevantes para el Soft
ware, software y firmware con unos detallados tratamientos ware en http://www.pressman5.com.
www.FreeLibros.org
PARTE
MÉTODOS CONVENCIONALES
PARA LA INGENIERÍA
DEL SOFTWARE
N esta parte de Ingeniería del Software U n EnfoquePrácticoconsidera-
E mos los conceptos técnicos, métodos y mediciones que son aplicables

al análisis, diseño y pruebas del software. En los capítulos siguientes,
aprenderás las respuestas a las siguientes cuestiones:
• ¿Cómo se define el software dentro del contexto de un gran sistema y qué

papel juega la ingeniería de sistemas?
• ¿Cuáles son los principios y conceptos básicos que se aplican al análisis
de requisitos del software?
• ¿Que es el análísis estructurado y cómo sus diferentes modelos te permi
ten entender las funciones, datos y comportamientos?
• ¿Cuáles son los conceptos básicos y los principios que se aplican en la acti
vidad de diseño del software?
• ¿Cómo se realiza el diseño de los modelos de datos; arquitectura, interfa
ces y componentes?
• ¿Cuáles son los conceptos básicos, principios y estrategias que se aplican
a las pruebas del software?
• ;Cómo se utilizan los métodos de prueba de caja negra y caja blanca para
diseñar eficientes casos de prueba?
• ¿Qué métricas técnicas están disponibles para valorar la calidad de los
modelos de análisis y diseño, código fuente y casos de prueba?
Una vez que estas cuestiones sean contestadas, comprenderás cómo cons
truir software utilizando un enfoque disciplinado de ingeniería.
www.FreeLibros.org
CAPÍTULO
10 INGENIERÍA DE SISTEMAS
A C E casi 500 años, M aquiavelo dijo: «... no hay nada m ás difícil de llevar a cabo, m ás
H p eligroso de realizar o de éxito m ás incierto que to m ar el liderazgo en la introducción

de un n uevo orden de cosas». D urante los Últimos 50 años, los sistem as basados en co m
p utad o ra h an introducido u n nuevo orden. A unque la tecnología h a conseguido grandes avan
ces desde que habló M aquiavelo, sus palabras siguen sonando a verdad.
L a ingeniería del softw are aparece com o consecuencia de un proceso denom inado in g en ie
ría de sistem as. E n lugar de centrarse únicam ente e n el softw are, la ingeniería de sistem as se
cen tra en diversos elem entos, analizando, diseñando y organizando esos elem entos e n un sis
tem a que pu ed en ser un producto, un servicio o un a tecnología para la transform ación de in fo r
m ació n o control de inform ación.
El p roceso de ingeniería de sistem as es denom inado ingeniería de p ro ceso s de negocio cuando
el contexto del trabajo de ingeniería se enfoca a u n a em presa. C uando hay que construir un pro
ducto, el p roceso se denom ina in g en iería de producto.
T anto la ingeniería de proceso de negocio com o la de producto intentan poner orden al d esa
rrollo de sistem as basados en com putadoras. A unque cad a u n a se aplica en u n d o m in io de apli
cació n diferente, am bas intentan poner al softw are en su contexto.
VISTAZO RÁPIDO
¿Qué e#? Antes de que el software se pue es el sistema, y los árboles son los ele ¿Cuál es el producto obtenido? Se debe
da construir, el «sistema» en el que mentos tecnológicos (incluido el soft obtener una correcta representación
residirá se debe comprender. Para ware) que son requeridos para realizas del sistema como consecuencia de la
lograrlo, se deben definir los objetivos el sistema. El empeño en construir ele ingeniería de sistemas. Se puede rea
generalesdel sistema;se debe identi mentos tecnológicos, antes de com lizar a través de un prototipo, una
ficar el papel del hardware, sotware, prender el sistema, lleva a cometer especificación o, incluso, un modelo
personas, bases de datos, procedí errores que desagradarán a t e clientes. simbólico, debiendo comunicar la
mientos y otros elementos del sistema; operativa, la funcionalidad y las
¿Cuáles son los pasos? Los objetivos y
y los requerimientos operacionales características de comportamiento del
los requisitos operacionales de mayor
deben ser identificados; analizados, sistema que se va a construir e incor
detalle son identificados gracias a la
especificados,modelizados,validados información facilitada por el cliente. porarlo dentro de la arquitectura del
y gestionados. Estas actividades son sistema,
Los requisitos son analizados para
la base de la ingeniería de sistemas. valorar su claridad, completitud y ¿Cómo puedo estar seguro de que lo he
¿Quién lo hace? Un ingeniero de sistemas consistencia. Una especificación, hecho correctamente? El producto obte
traba,ja para comprenderlos requisitos incorporada a un modelo del sistema, nido a tiavés de la aplicación de la
del sistema en colaboración con el se crea y valida posteriormente por ingeniería de sistemas, debe ser revi
cliente, los futuros usuarios y otras par los clientes y las partes interesadas. sado para determinar su claridad, com-
tes interesadas. Finalmente, los requisitos del siste pletitud y consistencia. Es importante
¿Por qué es impo.jlante?Hay un viejo dicho ma son gestionados para asegurar que los cambiosen los requisitos de un
que dice que «los árboles no dejan ver que los cambios se controlac ade sistema sean gestionados utilizando
el boscrue». En este contexto, el «bosque» cuadamente. métodos sólidos de GCS (Capítulo©.
Es d e cir, ta n to la in g e n ie ría de procesos de n e g o c io ’ com o la de pro ducto trab a jan p a ra a sig n ar un

papel al softw are de c o m p u ta d o ra y p a ra e stab lecer los enlaces que u n en al softw are con otros e le
m entos de u n sistem a basado en c o m p u ta d o ra .
E n este c a p ítu lo , p ro fu n d izam o s en las necesidades de gestión y en las activid ad es específicas del
proceso que p e rm ita n asegurar u n a o rg an izació n d e l softw are que consiga resultados satisfactoriosen
e l tie m p o fija d o y p o r e l m éto d o d e fin id o .
www.FreeLibros.org
1 En realidad, el térm ino ingeniería de sistemas se em plea a m enudo en este contexto. Sin em bargo, en este libro, el
térm ino «ingeniería de sistem as» e s genérico y se usa para abarcar a la ingeniería de proceso de negocio y a la inge
niería de producto.
165
I N GE NIE RÍA DEL S O F T W A R E . UN E N F O Q U E PR AC T I C O
L a p alab ra sistem a es posiblem ente el térm ino m ás u sa ciones específicas, en un conjunto de señales de control
do y abusado del léxico técnico. H ablam os de sistem as que provocan alguna acción físic a específica. T anto la
políticos y de sistem as educativ o s, de sistem as de avia creación de un sistem a de inform ación para asesorar a un
ción y de sistem as de fab ricació n , de sistem as banca- departam ento de m arketing, com o el softw are de control
rio s y de sistem as de lo co m o ció n . L a p a la b ra n o nos p ara el robot, requieren de la ingeniería de sistem as.
dice gran cosa. U sam os el adjetivo p ara describ ir el sis U na característica com plicada de los sistem as basa
tem a y p ara en tender el contexto en q u e se em plea. El dos en com putadora es que los elem entos que com po
diccio n a rio W ebster define sistem a com o: n e n un siste m a p u ed e n tam b ié n re p re se n ta r un
1. un conjunto o disposición de cosas relacionadas de m ane m acroelem ento de un sistem a aún m ás grande. El macro-
ra que form an una unidad o un todo orgánico; 2. un conjunto elem ento es un sistem a basado en com putadora que es
de hechos, principios, reglas, etc., clasificadas y dispuestas de parte de un sistem a m ás grande basado en com putado
m anera ordenada m ostrando un plan lógico de unión de las par ra. P o r ejem plo, considerem os un «sistem a de autom a
tes; 3. un m étodo o plan de clasificacióno disposición; 4 . una
tiz ac ió n de u n a fá b ric a » que es e se n c ia lm e n te una
m anera establecida de hacer algo; m étodo; procedim iento...
je ra rq u ía de sistem as. E n el niv el in fe rio r de la je ra r
S e proporcio n an cin co d e fin icio n es m ás en el dic q u ía tenem os u n a m áquina de control num érico, robots
cionario, pero no se sugiere u n sinónim o preciso. S is y dispositivos de entrada de inform ación. C ad a uno es
tem a es u n a p alab ra especial. un sistem a basado en com putadora p o r derecho propio.
Tom ando prestada la definición del diccionario W ebs L o s elem entos de la m áquina de control num érico inclu
ter, definim os un sistem a basado en com putadora com o: yen hardw are electrónico y electrom ecánico (por ejem
U n conjunto o disposición de elem entos que están organi plo, p rocesador y m em oria, m otores, sensores); software
zados para realizar un objetivo predeñnido procesando infor (para com unicaciones, control de la m áquina e interpo
m ación. lación); personas (el operador de la m áquina); una base
E l o b je tiv o p u e d e ser so p o rta r alg u n a fu n c ió n de de datos (el p rogram a C N alm acenado); docum entación
negocio o desarro llar u n p roducto q u e p u ed a venderse y p ro ced im ien to s. Se po d ría ap licar u n a d escom posi
p ara g enerar beneficios. P ara conseguir el o bjetivo, un ción sim ilar a los d isp o sitiv o s de entrada de in form a
sistem a b asado en com pu tad o ra hace u so de v arios e le c ió n y al ro b o t. T odos so n siste m a s b asad o s en
m entos del sistem a: com putadora.
Software. Programas de com putadora, estructuras de datos
y su docum entación que sirven para hacer efectivo el m étodo
lógico, procedim iento o control requerido.
CLAVE
Hardware. D isp o sitiv o s e lectró n ico s que p ro porcionan
los sistemas complejos son actualmente uno jerarquía
c a p a c id a d d e c á lc u lo , d isp o sitiv o s de in te rc o n e x ió n (p o r
e jem plo, co n m u tad o res de red, d isp o sitiv o s de te le c o m u n i de macro elementos que son sistemas en s' mismos.
c ación) y d isp o sitiv o s electro m ecán ico s (p o r ejem p lo , se n
s o re s, m o to re s, b o m b as) q u e p ro p o rc io n a n una fu n c ió n E n el siguiente nivel de la je ra rq u ía , se d efine una
externa, del m undo real. célula de fabricación. L a célula de fabricación es un sis
Personas. U suarios y operadores del hardw are y software.
tem a basado en com putadora que puede ten er elem en
to s p ro p io s (p o r e je m p lo , c o m p u ta d o ra s, fijacio n es
Documentación. M an u ales, fo rm u lario s y o tra in fo rm a
m ecánicas) y tam bién integra los m acroelem entos que
ción descriptiva que plasm a el em pleo y/o funcionam iento
del sistema. h em os denom inado m áquina de control num érico, robot
y dispositivo de entrada de inform ación.
Procedimientos. Los pasos que definen el em pleo especí
fico de cada elem ento del sistem a o el contexto procedim ental
P ara resum ir, la célula de fabricación y sus macroe-
en que reside el sistema. lem en to s está n c o m p u esto s de elem en to s del sistem a
con las etiquetas genéricas: softw are, hardw are, perso
nas, base de datos, p ro c ed im ien to s y docum entación.
fw H S E ld ^ . En algunos casos, los m acroelem entos pueden compartir
No esté atraído por hablar de un planteamiento un elem ento genérico. P or ejem plo, el ro b o t y la m áqui
«centrada en el software». Comience por considerar n a C N podrían ser m an e jad a s p o r el m ism o operador
todos los elementos de un sistema antes de concentrarse (el elem en to personas). E n otros casos, los elem entos
en el software. genéricos son exclusivos de un sistem a.
El papel del ingeniero de sistem as es definir los ele
Los elem entos se com binan de varias m aneras para m en to s de un sistem a esp ecífico b asad o en com puta
transform ar la información. Por ejem plo, un departam ento dora en el co n tex to de la je ra rq u ía global de sistem as
www.FreeLibros.org
de m arketing tran sfo rm a la inform ación bruta de ventas (m acroelem entos).
en un perfil del típ ico co m prador del producto; un robot En las siguientes secciones, exam inam os las tareas que
transform a un archivo de órdenes, que contiene in struc constituyen la ingeniería de sistem as de com putadoras.
166
CAPÍTULO 10 I NGENI ERI A DE S I STEMAS
í
Dominio
d e n ego cio Vista g lo b al
o d e p ro d u cto
E le m en to
del siste m a
FIGURA 1 0.1. La jerarquía de la ingeniería de sistemas de com putadora.
ElÍ íL2 LA JERARQUIA DE LA IN fi^ tflE R IA DE SISTEMAS

Independientemente del dominio de enfoque, la ingenie definan los procesos que satisfagan las necesidades
ría de sistemas comprende una colección de métodos para de la visión en consideración;
navegar de arriba abajo y de abajo arriba en la jerarquía representen el comportamiento de los procesos y los
ilustrada en la Figura 10.1. El proceso de la ingeniería de supuestos en los que se basa el com portamiento;
sistemas empieza normalmente con una «visión global». definan explícitamente las entradas exógenas3 y endó
Es decir, se examina el dominio entero del negocio o del genas de inform ación al modelo;
producto para asegurarse de que se puede establecer el representen todos las uniones (incluyendo las sali
contexto de negocio o tecnológico apropiado. La visión das) que perm itan al ingeniero entender m ejor la
global se refina para enfocarse totalmente en un dominio visión.
de interés específico. Dentro de un dominio específico, se
analiza la necesidad de elementos del sistema (por ejem
plo, información, software, hardware, personas). Final tita
mente, se inicia el análisis, diseño y construcción del
elemento del sistema deseado. En la parte alta de la jerar VE
quía se establece un contexto muy amplio y en la parte tos buenos s É m e s de hgenetfe comienzan por
baja se llevan a cabo actividades técnicas detalladas,rea clarificar el a r q x r te r r é n b de c o rfe x b — la visión
lizadas por la disciplina de ingeniería correspondiente(por global— y p o g e á s rre rte s e van estrechando hasfe
ejemplo, ingeniería hardware o software) . el nivel de detele necesario.
102.1.M o d ela d o d e l s is te m a Para construir un m odelo del sistem a, el ingeniero

La ingeniería de sistemas de com putadora es un proce debería considerar algunas restricciones:
so de modelado. Tanto si el punto de m ira está en la 1. Supuestos que reducen el núm ero de permutaciones
visión global o en la visión detallada, el ingeniero crea y variaciones posibles, perm itiendo así al m odelo
modelos que [M O T92]: reflejar el problem a de m anera razonable. Por ejem-
2 En algunas situaciones, sin em bargo, los ingenieros del sistem a 3 Las en tra d as exógen as unen un elem ento de una visión dada con
www.FreeLibros.org
deben considerar primero los elem entos individuales del sistema y /o otros elem entos al m ism o o a o tro s niveles; las en tra d as endógenas
los requisitos detallados. Em pleando este enfoque, los subsistem as unen com ponentes individuales de un elem ento en una visión par
se escriben de abajo a arriba considerando primero los com ponen ticular.
tes de detalle del subsistem a.
167
I N GEN IE RÍ A DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
plo, considere un p roducto de rep resen tació n en tres cliente es a m enudo tom ada en cuenta h asta el punto
dim ensiones usado p o r la industria de entretenim iento de realizar su enfoque preferido.
para crear anim aciones realistas. U n dom inio del pro E l m o d e lo de siste m a re su ltan te (desde cualquier
d u cto p erm ite la rep resen tació n de form as hum anas v isió n ) p u ede recla m a r u n a so lu ció n co m p letam en te
en 3D . Las entradas a este dom inio co m prenden la au to m ática, sem iau to m ática o un enfo q u e m anual. De
h ab ilid ad de in tro d u c ir m o v im ien to de u n «actor» h e c h o , es p o sib le a m e n u d o c a rac teriza r m o d elo s de
h um ano vivo, desd e vídeo o creando m odelos gráfi ca d a tip o que sirv en de so lu cio n es altern ativ as para el
cos. E l ingeniero del sistem a hace ciertos supuestos p ro b le m a que te n e m o s e n tre m an o s. E n e s e n c ia , el
sobre el rango de m ovim ien to s h um anos perm itidos ingeniero del sistem a m odifica sim plem ente la influen
(por ejem plo, las p iernas n o p u ed en enrollarse alre c ia re la tiv a de lo s d ife re n te s e le m e n to s del sistem a
ded o r del tro n co ) de m an era que puede lim itarse el (p ersonas, h ard w are, so ftw a re ) para cre ar m o d elo s de
p roceso y el rango de entradas. ca d a tipo.
2. Sim plificaciones q u e p e rm ite n c re a r el m o d e lo a
tiem po. P ara ilustrarlo, considere u n a com pañía de
10.2.2. Sim u lación d el siste m a
p ro d u cto s de o fic in a que v en d e y su m in istra una
am plia v aried ad de fotocopiadoras, faxes y equipos E n los años 60, R.M. G raham [GRA69] hizo un com en
sim ilares. El ingeniero del sistem a e stá m odelando tario crítico sobre la m anera en que se construían los sis
las necesid ad es de la o rganización su m inistradora y tem as basados en com putadora: «C onstruim os sistemas
está trabajando p ara en tender el flujo de in form ación igual que los herm anos W right construían aviones: cons
que en gendra u n a o rden de sum inistro. A unque una truim os todo el sistem a, lo em pujam os barranco abajo,
ord en de sum inistro puede generarse desde m uchos le dejam os que se estrelle y em pezam os de n uevo.» De
orígenes, el ingeniero categoriza solam ente dos fu en h ech o , para al m enos un tip o de sistem a — el sistema
tes: d em an d a in te rn a o p etició n externa. E sto p er reactivo— lo continuam os haciendo hoy en día.
m ite una p artició n sim plificada de entradas necesaria M uchos sistem as basados en com putadora interac-
p ara g enerar u n a ord en de trabajo. cionan con el m u n d o real de form a reactiva. Es decir,
los acontecim ientos del m u n d o real son vigilados por
3. Lim itaciones que ayudan a delim itar el sistem a. Por
el hardw are y el softw are que com ponen el sistem a, y
ejem plo, se está m odelando un sistem a de aviónica
basándose en esos sucesos, el sistem a aplica su control
p ara un avión de p ró x im a generación. C om o el avión
sobre las m áquinas, procesos e incluso las personas que
ten d rá un diseño de dos m otores, tod o s los dom inios
m otivan los acontecim ientos. L os sistem as de tiempo
de supervisión de la prop u lsió n se m o d elarán para
real y sistem as em p o trad o s p ertenecen a m enudo a la
albergar un m áxim o de d os m otores y sus sistem as
categoría de sistem as reactivos.
redundantes asociados.
¿Dónde acaba el modelo ^ C O N S E /O ^ .
• de ingeniería del sistema?

S ilo capacidad de simulación no está disponible
poro un sistema reactivo, el riesgo del proyecto
4. Restricciones que guían la m anera de crear el m odelo se incremento. Considerar poro su utilización un modelo
y el enfoque que se to m a al im plem entar el m odelo. de proceso iterativo que te permito obtener un resultado
P o r ejem p lo , la infraestructura tecn o ló g ica para el en uno primero iteración y utilizar otras iteraciones poro
sistem a de rep resen tació n en tres d im ensiones d es ajustar sus característicos.
crita anteriorm ente es un solo p ro cesad o r basado en

u n Pow er-PC . L a com plejidad de cálculo de los p ro D esgraciadam ente, los desarrolladores de sistemas
blem as deb en restringirse p ara encajar en los lím i reactivos luchan a veces para hacerlos funcionar correc
tes de p roceso im puestos p o r el procesador. tam ente. H asta hace poco, h a sido difícil p redecir el ren
d im ie n to , la e fic a c ia y el c o m p o rta m ie n to de estos
sistem as antes de construirlos. R ealm ente, la construc
\ ción de m uchos sistem as de tiem po real era una aven
CLAVE tura. L as so rpresas (la m a y o ría d e sa g rad a b les) no se
Un ingeniero del sistema considera los siguientes factores descubrían hasta que el sistem a era construido y «arro
cuando desarrolla soluciones alternativas: planteamientos, ja d o colina abajo». Si el sistem a se estrellaba debido a
simplificaciones, limitaciones, restriccionesy preferencias un funcionam iento incorrecto, com portam iento inapro
de los clientes. piado o escaso rendim iento, cogíam os las piezas y empe
zábam os de nuevo.
5. Preferencias q ue in d ic a n la a rq u ite c tu ra p refe rid a M uchos sistem as de la categoría de los reactivos con
www.FreeLibros.org
p ara tod o s los datos, funciones y tecnología. L a solu trolan m áquinas y/o procesos (por ejem plo, aerolíneas
ción p referid a e n tra a v eces en conflicto con otros com erciales o refinerías de p etróleo) que deben operar
fa c to re s re s tric tiv o s. A u n q u e la sa tisfa c c ió n del con extrem a fiabilidad.
168
CAPITULO 10 IN GE NI ER IA DE S I STEMAS
S i e l s is t e m a f a lla , p o d r í a n o c u r r ir p é r d id a s e c o n ó f i c a c i ó n d e l s i s t e m a . E n e l C a p í t u l o 31 s e e s t u d i a n
m ic a s o h u m a n a s s i g n i f i c a t i v a s . P o r e s t e m o t i v o , e l e n f o b r e v e m e n te lo s d e t a lle s t é c n ic o s y t é c n ic a s e s p e c ia
q u e d e s c r ito p o r G r a h a m e s p e n o s o y p e lig r o s o . le s d e m o d e la d o q u e s e e m p le a n p a r a ll e v a r a c a b o
H o y e n d ía s e u t iliz a n h e r r a m ie n ta s s o ftw a r e p a ra e s ta s p ru e b a s .
e l m o d e la d o y s im u la c ió n d e s is t e m a s p a r a a y u d a r a
e lim in a r s o r p r e s a s c u a n d o s e c o n s t r u y e n s is t e m a s
r e a c tiv o s b a s a d o s e n c o m p u t a d o r a . E s ta s h e r r a m ie n
ta s s e a p l i c a n d u r a n t e e l p r o c e s o d e i n g e n i e r í a d e sis
t e m a s , m i e n t r a s s e e s t á n e s p e c i f i c a n d o la s n e c e s i d a d e s
d e l h a rd w a re , s o ftw a r e , b a s e s d e d a to s y d e p e rs o n a s .
L a s h e r r a m ie n ta s d e m o d e la d o y s im u la c ió n c a p a c i Herramientas CASE
tan a l i n g e n i e r o d e s i s t e m a s p a r a p r o b a r u n a e s p e c i Modelado y Simulación
■ B h £ . 2 E N I E . ^ „ D E P l.Q C E S Q
E l o b je t iv o d e la in g e n ie r í a d e p r o c e s o d e n e g o c io ( I P N ) S e d e b e n a n a liz a r y d is e ñ a r tr e s a r q u it e c t u r a s d i f e
es d e f in ir a r q u it e c t u r a s q u e p e r m it a n a la s e m p r e s a s re n te s d e n tr o d e l c o n te x to d e o b je t iv o s y m e ta s d e
e m p le a r l a i n f o r m a c i ó n e f i c a z m e n t e . M i c h a e l G u t t m a n n e g o c io :
[G U T 9 9 ] d e s c r ib e e l d e s a f io c u a n d o d ic e : • a r q u it e c t u r a d e d a to s
El actual e n torno com putacional co n siste e n un po d er de • a r q u it e c t u r a d e a p lic a c io n e s
com putación distrib u id o en to d a la em p resa con m últiples
unidades d iferentes de procesam iento, div id id o y configura • in f r a e s tr u c tu r a d e la t e c n o lo g ía
do por una am plía variedad de tareas, N uevos planteam ien
tos com o la c o m p u tació n c lie n te -se rv id o r, p ro c e sa m ie n to m n sm m m *
distribuido,el trabajo en red (por nom brar algunos de los té r lo s objetos de datos son tratados en detalle
minos m ás so b reu sad o s) p erm iten g e stio n a r las dem andas
en el C a p íJo 12.
aportando m ayor funcionalidad y flexibilidad.
Sin em bargo, el coste de estos cam bios es am p liam ente L a a r q u it e c t u r a d e d a to s p r o p o r c io n a u n a e s tr u c tu
discutido por la organizacionesde TI (Tecnologíasde la Infor
r a p a r a la s n e c e s id a d e s d e i n f o r m a c i ó n d e u n n e g o c io o
m ación) que deb en so p o rtar esta p o líg lo ta configuración.
Hoy, cada organización de TI debe fav o re c er la integración d e u n a f u n c i ó n d e n e g o c i o . L os l a d r i l l o s d e l a a r q u i t e c
de sus sistem as. D ebe d iseñ ar, im p lem en tar y so p o rta r su t u r a s o n lo s o b je t o s d e d a to s q u e e m p le a la e m p r e s a . U n
propia configuración de recursos de c o m p u tació n h etero g é o b je t o d e d a to s c o n tie n e u n c o n ju n t o d e a t r ib u to s q u e
nea, distribuidos lógica y geográficam ente por toda la e m p re d e f in e n a s p e c to s , c u a lid a d e s , c a r a c te r ís tic a s o d e s c r ip
sa, conectándola a través de un esquem a apro p iad o para el
t o r d e lo s d a to s q u e h a n s id o d e s c r ito s . P o r e je m p lo , u n
trabajo en red.
in g e n ie r o d e la in f o r m a c ió n p u e d e d e f in ir e l o b je t o d e
Por otra parte, esta configuración debe ser d ise ñ ad a p ara
d a to s : c lie n te . P a r a d e s c r ib ir m á s e n d e t a lle a l c lie n t e ,
cambios continuos, d esig u alm en te lo c a liz a d o s e n la e m p re
s e d e f in e n lo s s ig u ie n te s a t r ib u t o s :
sa, debido a cam bios en requisitos del n egocio y en las p ro
pias tecnologías. E sto s d iv e rso s e in crem en tales c am b io s O bjeto: Cliente
deben ser coordinados a través del e n torno d istrib u id o , c o n
A tributos:
sistente en hardw are y softw are sum inistrado por decenas,
cuando no cientos, de vendedores. P or supuesto, e speram os nom bre
que estos cam bios los in co rp o rem o s sin ruptura con la o p e nom bre de la com pañía
rativa habitual perm itiendo adem ás a m p liar la operativa.
clasificación d el trabajo y au to rid a d en com pra
C u a n d o h a b l a m o s d e u n a v i s i ó n g e n e r a l d e la s n e c e dirección com ercial e inform ación de contacto
s id a d e s d e t e c n o l o g í a d e i n f o r m a c i ó n d e u n a c o m p a ñ í a , producto(s) de interés
p is te n p e q u e ñ a s in c e r t id u m b r e s q u e s o n p la n te a d a s a
com pra)s) anteriores
la in g e n ie r í a d e s is t e m a s . L a i n g e n i e r í a d e p r o c e s o d e
f e c h a de últim o contacto
g o c io e s u n a c e r c a m i e n t o p a r a c r e a r u n p l a n g e n e
t ! p a ra im p le m e n t a r la a r q u it e c t u r a d e c o m p u t a c ió n
ÍSPE93],
situación d el contacto
U n a v e z d e f in id o e l c o n ju n t o d e d a to s , s e id e n t if ic a n
s u s r e la c io n e s . U n a r e la c ió n in d ic a c o m o lo s o b je t o s
e s tá n c o n e c ta d o s . C o m o e je m p lo , c o n s id e r a r lo s o b je
t o s : cliente y productoA. L o s d o s o b j e t o s p u e d e n c o n e c
www.FreeLibros.org
Tres arqultecturasdlferentes son desorrollodos durante ta r s e p o r la r e la c ió n c o m p r a ; e s d e c ir , u n c lie n te c o m p r a
la PNla arquitectura de datos, la arquitectura e l p r o d u c to A o e l p r o d u c to A e s c o m p r a d o p o r u n c lie n
de aplicación y la Infraestructura tecnológica. te . L o s o b je t o s d e d a to s ( p u e d e n e x is t ir c ie n t o s o m ile s
169
IN GENIERÍA DEL SOFTW ARE . UN E N F O Q U E P R Á C T I C O
para una actividad de negocio im portante) fluyen entre dad de la em presa. La PEI define los objetos de datos
las funciones de negocio, están organizados dentro de visibles a nivel em presa, sus relaciones y cóm o fluyen
una base de datos y se transforman para proveer infor entre los dominios del negocio [M AR90].
mación que sirva a las necesidades del negocio.
La arquitectura de aplicación comprende aquellos ^ C O N S E iO ^ .
elementos de un sistema que transform an objetos den
tro de la arquitectura de datos por algún propósito del
lomoingenierodelsoftware,nodebesprofundizarenPEI
negocio. E n el contexto de este libro, consideram os
nienelAAN. No obstante, sinoestácloroqueestas
norm alm ente que la arquitectura de aplicación es el sis
octividodeshoyansidorealizadas, informea susuperior
queelriesgodelproyectoesmuyalto.
tem a de program as (software) que realiza esta trans
formación. S in embargo, en un contexto m ás amplio, La vista del dominio se trata con una actividad IPN
la arquitectura de aplicación podría incorporar el papel denom inada análisis del área de negocio (AAN). Hares
de las personas (por ejemplo, cliente/servidor) que ha [HAR93] describe AAN de la siguiente manera:
sido diseñado para im plem entar estas tecnologías. El A A N se ocupa de identificar en detalle la inform ación (en
la form a de tipos de entidad [objeto datos]) y los requisitos de
m sm m n m las funciones (en la form a de procesos) de áreas de negocio
B detalle sobre la arquitectura del software seleccionadas [dom inios] identificadas durante el PE I, averi
guando sus interacciones (en form a de matrices). Se ocupa sola
es presentado enel Capítulo 14.
m ente de especificar qué se requiere en un área de negocio.
L a infraestructura tecnológica proporciona el fun A medida que el ingeniero de información comienza el

damento de las arquitecturas de datos y de aplicaciones. AAN, el enfoque se estrecha hacia un dominio del nego
L a infraestructura comprende el hardware y el software cio específico. El AAN ve el área del negocio como una
empleados para dar soporte a las aplicaciones y datos. entidad y aísla las funciones de negocio y procedimientos
Esto incluye computadoras y redes de computadora, enla que perm iten al área del negocio lograr sus objetivos y
ces de telecomunicaciones, tecnologías de alm acena metas. El A A N , al igual que el PEI, define objetos de datos,
m iento y la arquitectura (por ejemplo, cliente/servidor) sus relaciones y cómo fluye la información. Pero a este
diseñada para implementar estas tecnologías. nivel, estas características están delimitadas por el área de
negocio que se está analizando. El resultado de AAN es
aislar las áreas de oportunidad en las que los sistemas de
P la n ific a c ió n información pueden prestar soporte al área de negocio.
e s tra té g ic a
d e la in fo rm a c ió n
(v is ta g lo b a l)
A n á lis is d e l á re a
d e n e g o c io
(vista
IngenieríadeProcesosde Negocio
d e l d o m in io )
U na vez que se ha aislado un sistema de información
para un desarrollo posterior, la IPN hace una transición
a la ingeniería del software. Invocando la fase del dise
D is e ñ o d e l s is te m a ño de sistema de negocio (DSN), se m odelan los requi
d e n e g o c io
(v is ta d e l e le m e n to )
sitos básicos de un sistema de inform ación específico y
In g e n ie ría estos requisitos se traducen en arquitectura de datos,
. del arquitectura de aplicación e infraestructura tecnológica.
s o ftw a re
C o n s tru c ció n El paso final de la IPN (construcción e integración,
e in te g ra c ió n C&I) se centra en los detalles de la implementación. La
(vista d e ta lla d a )
arquitectura e infraestructura se implementan constru
yendo una base de datos apropiaday estructuras internas
F IG U R A 1 0 .2 . La jerarquía de la ingeniería de procesos. de datos, mediante la construcción de aplicaciones que
están constituidas por programas, y seleccionando los
Para m odelar las arquitecturas de sistema descritas elementos apropiados de una infraestructuratecnológica
anteriormente, se define una jerarquía de actividades de para dar soporte al diseño creado durante el DSN. Cada
ingeniería de la información. Como m uestra la Figura uno de estos componentes del sistema debe integrarse
10.2, la visión global se consigue a través de la planifi para formar una aplicación o sistema de información com
cación de la estrategia de información (PEI). La PEI pleto. La actividad de integración también coloca al nue
www.FreeLibros.org
ve todo el negocio como una entidad y aisla los dom i vo sistem a de inform ación en el contexto del área de
nios del negocio (por ejemplo, ingeniería, fabricación, negocio, realizando todo el entrenam iento de usuario y
marketing, finanzas, ventas) importantes para la totali soporte logístico para conseguir una suave transición.
170
C A P I T U L O 10 I NGENI ERI A DE SI STEMAS
^0.4 INGENIERÍA DE PR OD UCTO ; l i l i

La m eta de la in g e n ie ría d e p ro d u c to e s tra d u c ir el
deseo de un c lie n te , de u n c o n ju n to de c a p a c id a d e s
definidas, a un p ro d u c to o p e ra tiv o 4. P a ra c o n se g u ir
esta m eta, la in g e n ie ría de p ro d u c to (co m o la in g e
niería de p ro ceso de n e g o c io ) d eb e c re a r u n a a rq u i
tectura y u n a in fra e s tru c tu ra . L a a rq u ite c tu ra
In g e n ie r ia
com prende cu atro c o m p o n e n te s de sistem a d istin to s:
d e c o m p o n e n te
software, h ard w are, d a to s (b a se s de d a to s) y p e rs o (v ís ta
nas. Se e s ta b le c e u n a in f r a e s tr u c tu r a d e s o p o rte e d e d o m in io )
incluye la te c n o lo g ía re q u e rid a p a ra u n ir lo s c o m p o
nentes y la in fo rm a c ió n (p o r e je m p lo , d o c u m e n to s,
CD-ROM, víd eo ) que se e m p le a p a ra d a r so p o rte a M o d e lo d e A n á lis is
los com ponentes. y D is e ñ o {v is ta
d e l e le m e n t o )
Como se m u e stra en la F ig u ra 10.3, la v isió n g lo
C o m p o n e n te s
bal se co n sig u e a trav és de la ingeniería de requisi In g e n ie r ía
d e p ro g ra m a d e l s o f tw a r e
tos. Los requisitos g en erales del p ro d u c to se o b tien en
C o n s tru c c ió n
del cliente. E sto s re q u isito s co m p ren d en n ec esid ad es
e in te g ra c ió n
de inform ación y c o n tro l, fu n c io n a lid a d del p ro d u c (v is ta d e ta lla d a )
to y co m p o rtam ien to , re n d im ie n to g e n e ra l d el p ro
ducto, d is e ñ o , r e s tr ic c io n e s d e la in te rf a z y o tra s F IG U R A 1 0 .3 . La jerarquía de la ingeniería de productos.
necesidades esp eciales. U n a vez que se c o n o cen estos
requisitos, la m isió n del an álisis del sistem a es a s ig Parte del papel del análisis de sistemas es establecer los
nar funcionalidad y c o m p o rta m ie n to a c a d a u n o de m ecanism os de interfaz que perm itirán que esto suceda.
los cuatro co m p o n en tes m en cio n ad o s an teriorm ente. L a visión de elem en to para la ingeniería de p ro d u c
Una v ez que se h a h e ch o la asig n ació n , co m ien za to es la disciplina de ingeniería aplicada a la asignación
la ingeniería de com ponentes del sistem a. L a in g e de com ponentes. P ara la ingeniería del softw are, esto
niería de c o m p o n e n te s del siste m a e s, d e h e c h o , un significa actividades de modelado del análisis y diseño
conjunto de a ctiv id ad es c o n c u rre n te s q u e se d irig en (cubierto en detalle en posteriores capítulos) y activi
separadam ente a cada u no de los com ponentes del sis dades de construcción e integración que c o m p ren d en
tema: la ingen iería del so ftw are, in g e n ie ría hard w are, generación de código, pruebas y actividades de sopor
ingeniería hum ana e ingeniería de b ases de datos. C ada te. E l m odelado de la fase de análisis asigna requisitos
una de estas d isc ip lin a s de in g e n ie ría to m a u n a v ista a las representaciones de datos, funciones y co m p o rta
de dom inio esp ecífica, pero es im portante resaltar que m iento. E l d ise ñ o con v ierte el m o d e lo de a n álisis en
las disciplinas de in g e n ie ría d e b en e sta b lece r y m a n diseños de datos, arquitectónicos, de interfaz y a nivel
tener una co m unicación a c tiv a en tre ellas. de com ponentes del softw are.
INGENIERÍA DE REQUISITOS
La consecuencia del p roceso de ingeniería de sistem as
es la especificación de un sistem a o producto basado en
computadora que se d escrib e g en éricam en te, e n d ife la porte más dura en la construcción de un sistema
rentes niv eles en la F ig u ra 10.1. P ero el desafío de la s ié íita te es decidir cómo construirlo... Ninguna parte
ingeniería del sistem a (y de los ingenieros del softw a déf hahojo mutila el resultado del sistema si está
re) es im portante: ¿C óm o podem os asegurar que hem os hecho m al. Ninguna parte es más dificultoso para
especificado un sistem a que recoge las necesidades del
cliente y satisface sus e x p e c ta tiv as? N o hay u n a re s
puesta segura a esta difícil p regunta, pero un sólido p ro
ceso de ingen iería de requisitos es la m ejo r solución de L a in g e n ie ría de re q u isito s fa c ilita el m e c a n ism o
que disponem os actualm ente. ap ropiadopara c o m p ren d erlo que quiere el cliente, ana-
"Debemos hacer notar que la term inología (ad ap tad ap o r (MAR90J)
www.FreeLibros.org
utilizada en la Figura 10.2 está asociada con la ingeniería de la infor
mación, la predecesora del m oderno IPN. Sin em bargo, el área cen
tral implicada en cada actividad se ñ a la d a e s dirigida por to d o s
a q u e llo s que consideran el tem a.
171
lizando necesidades, confirmando su viabilidad, nego
•
¿Por qué es tan difícil
ciando una solución razonable, especificando la solu obtener un planteamiento
ción sin am bigüedad, validando la especificación y claro de lo que necesita
gestionando los requisitos para que se transform en en el cliente?
un sistema operacional [THA97]. El proceso de inge
niería de requisitos puede ser descrito en 5 pasos dis « identificar las personas que ayudarán a especificar
tintos [SOM97]: Identificación de Requisitos, Análisis requisitos y contrastar su papel en la organización;
de Requisitos y Negociación, Especificación de Requi « definir el entorno técnico (arquitectura de com puta
sitos, M odelizado del Sistema, Validación de R equisi ción, sistema operativo, necesidades de telecom uni
tos y Gestión de Requisitos. caciones) en el sistem a o producto a desarrollar e
integrar;
10.5.1. Id e n tific a c ió n d e r e q u is ito s « identificar «restricciones de dominio» (característi
En principio, parece bastante sim ple — preguntar al cas específicas del entorno de negocio en el dom i
cliente, a los usuarios y a los que están involucrados en nio de la aplicación) que lim iten la funcionalidad y
los objetivos del sistema o producto y sean expertos, rendimientos del sistema o producto a construir;
investigar cóm o los sistemas o productos se ajustan a • definir uno o m ás métodos de obtención de requisi
las necesidades del negocio, y finalmente, cóm o el sis tos (entrevistas, grupos de trabajo, equipos de dis
tem a o producto va a ser utilizado en el día a día—: Esto cusión);
que parece simple, es muy complicado. « solicitar la participación de m uchas personas para
Christel y Kang [CRI92] identifican una serie de pro que los requisitos se definan desde diferentes puntos
blemas que nos ayudan a com prender por qué la obten de vista, asegurarse de identificar lo fundamental de
ción de requisitos es costosa. cada requisito registrado;
. problem as de alcance. El límite del sistema está mal « identificar requisitos ambiguos como candidatos para
definido o los detalles técnicos innecesarios, que han el prototipado, y
sido aportados por los clientes/usuarios, pueden con • crear escenarios de uso (ver Capítulo 11) para ayu
fundir m ás que clarificarlos objetivos del sistema. dar a los clientes/usuarios a identificar m ejor los
. problem as de comprensión. Los clientes/usuarios no requisitos fundamentales.
están com pletam ente seguros de lo que necesitan,
tienen una pobre com presión de las capacidades y
limitaciones de su entorno de computación, no existe
un total entendim iento del dom inio del problem a, Asegúrate de haber valorado los características generales
antes de especificar el esfuerzo y plazo para obtener
existen dificultades para com unicar las necesidades
los requisitos de detalle.
al ingeniero del sistema, la om isión de información
por considerar que es «obvia», especificación de
El resultado alcanzado como consecuencia de la iden
requisitos que están en conflicto con las necesidades
tificación de requisitos variará dependiendo del tama
de otros clientes/usuarios, o especificar requisitos
ño del sistem a o producto a construir. Para grandes
ambiguos o poco estables.
sistemas, el producto obtenido debe incluir:
• Problem as de volatilidad. Los requisitos cam bian • una relación de necesidades y características;
con el tiempo.
• un informe conciso del alcance del sistema o producto;
. una lista de clientes, usuarios y otros intervinientes
ü & que deben participar en la actividad de obtención de
Referencia W ebl requisitos;
Un informe detallado bajo el titulo ((Necesidades . una descripción del entorno técnico del sistema;
en lo Obtención de Requisitos)) puede ser descargado de « una relación de requisitos (perfectamente agrupados
www.sei.cmu.edu/publications/documents/
por funcionalidad) y las restricciones del dominio
92.reports/92.tr.012.html
aplicables a cada uno;
Para ayudar a solucionar estos problem as, los inge « un conjunto de escenarios que perm iten profundizar
nieros de sistem as deben aproxim arse de una m ane en el uso del sistema o producto bajo diferentes con
ra o rg an izad a a través de reu n io n es p ara d efin ir diciones operativas, y
requisitos. . cualquier prototipo desarrollado para definir mejor
Sommerville y Sawyer [SOM97] sugieren un con los requisitos.
junto de actuacionespara la obtención de requisitos, que
www.FreeLibros.org
están descritos en las tareas siguientes: c s a fflg fflffla
• valorar el im pacto en el negocio y la viabilidad téc los métodos de obtención de requisitos
nica del sistema propuesto; son presentados en el Capítulo 11.
172
CAPÍTULO 10 I NGENI ERI A DE S I STEMAS
Cada uno de los productos obtenidos debe ser revi E l ingeniero del sistem a debe resolver estos c o n flic
sado por las personas que hayan participado en la obten tos a través de un proceso de negociación. L os clientes,
ción de sus requisitos. usuarios y el resto de intervinientes deberán clasificar
sus requisitos y discutir los posibles conflictos según su
10.5.2. A n á lis is y n e g o c ia c ió n d e r e q u is ito s prioridad. Los riesgos aso ciadoscon cada requisito serán
identificadosy analizados (ver C apítulo 6). Se efectúan
Una vez recopilados los requisitos, el producto obteni «estim aciones» del esfu erzo de desarrollo que se u tili
do configura la base del análisis de requisitos. Los requi zan para v alorar el im pacto de cada requisito en e l co s
sitos se agrupan por categorías y se organizan en te del proyecto y en el plazo de entrega. U tilizando un
subconjuntos, se estudia cada requisito en relación con procedim iento iterativo, se irán elim inando requisitos,
el resto, se examinan los requisitos en su consistencia, se irá n co m b in a n d o y/o m o d ific a n d o p a ra c o n se g u ir
completitudy ambigüedad, y se clasifican en base alas satisfacer los objetivos planteados.
necesidades de los clientes/usuarios.
¿Qué cuestiones deben ser 10.5.3. E s p e c ific a c ió n d e r e q u isito s
• preguntadas y contestadas
. durante el análisis de requisitos?
E n el contexto de un sistem a basado en com putadoras
(y softw are), el térm ino especificación significa distin
tas cosas para diferentes personas. U na especificación
Al iniciarse la actividad del análisis de requisitos se puede ser un docum ento escrito, un m odelo gráfico, un
plantean las siguientes cuestiones: m odelo m atem ático form al, una co lec ció n de e sc e n a
• ¿Cada requisito es consistente con los objetivos gene rios de uso, u n prototipo o un a com binación de lo ante
rales del sistema/producto? riorm ente citado.
• ¿Tienen todos los requisitos especificados el nivel A lgunos sugieren que d ebe desarrollarse una «p lan
adecuado de abstracción? Es decir, ¿algunos requi tilla estándar» [SO M 97] y usarse en la especificación
sitos tienen un nivel de detalle técnico inapropiado del sistem a, argum entando que así se conseguirían requi
en esta etapa? sitos que sean p resen tad o s de una fo rm a m ás c o n sis
te n te y m ás c o m p re n sib le . N o o b sta n te , en m u ch a s
• ¿El requisito es necesario o representa una caracte
ocasiones es necesario b u scar la flexibilidad cuando una
rística añadida que puede no ser esencial a la finali
especificación va a ser desarrollada. P ara grandes sis
dad del sistema?
tem as, un docum ento escrito, co m b in ad o con d escrip
• ¿Cada requisito está delimitado y sin ambigüedad? ciones en lenguajes n atu ral y m o d elo s gráficos p u ede
• Cada requisito tiene procedencia. Es decir, ¿existe ser la m ejor alternativa. E n cualquier caso, los e sc e n a
un origen (general o específico) conocido para cada rios a u tilizar pueden ser tan to los requeridos para p ro
requisito? ductos de tam año pequeño o los de sistem as que residan
• ¿Existen requisitos incom patibles con otros requi en entornos técnicos bien conocidos.
sitos?
• ¿Es posible lograr cada requisito en el entorno téc
nico donde se integrará el sistema o producto?
• ¿Se puede probar el requisito una vez implementado?
Técnicasde Negociación
L a Especificacióndel Sistema es el producto final sobre

los requisitos del sistem a obtenido po r el ingeniero. Sir
ve co m o fu n d am e n to para la ingeniería del hardw are,
ingeniería del softw are, la ingeniería de bases de datos y
Análisisde Requisitos la ingeniería hum ana. D escribe la función y característi
Es corriente en clientes y u suarios solicitar m ás de cas de un sistem a de com putación y las restricciones que
lo que puede realizarse, consum iendo recursos de nego gobiernan su desarrollo. L a especificación delim ita cada
cio limitados. También es relativam ente com ún en clien elem ento del sistema. L a Especificación del Sistem a des
tes y usuarios el p ro p o n e r re q u isito s c o n trad ic to rio s, cribe la inform ación (datos y control) que entra y sale del
argumentando que su v ersión es «esencial po r n e ce si sistema.
dades especiales».
www.FreeLibros.org
S/los diferentesclientes/usuarios nopueden facilitar
losrequisitos, el riesgo de errares muy alto. Proceda
conextremaprecaución. Especificacióndel sistema
173
I N G E N IE R ÍA DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
10.5.4. M o d e la d o d e l s is te m a (es un problem a importante), requisitos contradictorios,

Considere por un m om ento que a usted se le ha reque o requisitos im posibles o inalcanzables.
rido para especificar los requisitos para la construcción Aunque la validación de requisitos puede guiarse de
de una cocina. Se conocen las dim ensiones del lugar, la m anera que se descubran errores, es útil chequear cada
localización de las puertas y ventanas y el espacio de requisito con un cuestionario. Las siguientes cuestiones
pared disponible. D ebes especificar todos los armarios representan un pequeño subconjunto de las preguntas
y electrodom ésticos e indicar dónde colocarlos. ¿Será que pueden plantearse:
una especificación válida? • ¿Está el requisito claramente definido? ¿Puede inter
La respuesta es obvia. Para, especificar completamente pretarse mal?
lo que vam os a desarrollar, necesitam os un modelo de • ¿Está identificado el origen del requisito (por ejem
la cocina con toda su información, esto es, un antepro plo: persona, norma, documento)? ¿El planteamiento
yecto o una representación en tres dimensiones que mues final del requisito ha sido contrastado con la fuente
tre las posiciones de los armarios y electrodomésticos, original?
y sus relaciones. Con el modelo será relativamente fácil • ¿El requisito está delim itado en térm inos cuantita
asegurar la eficiencia del trabajo (un requisito de todas tivos?
las cocinas), la estética «visual» de la sala (es un requi
• ¿Qué otros requisitos hacen referencia al requisito
sito personal, aunque muy importante).
estudiado? ¿Están claramente identificadospor medio
Se construyen m odelos del sistem a por la m ism a
de una m atriz de referencias cruzadas o por cualquier
razón que desarrollamos para una cocina un antepro
otro m ecanismo?
yecto o una representación en 3D. Es im portante eva
luar los com ponentes del sistema y sus relaciones entre • ¿El requisito incumple alguna restricción definida?
sí; determ inar cóm o están reflejados los requisitos, y • ¿El requisito es verificable? Si es así, ¿podemos efec
valorar com o se ha concebido la «estética» en el siste tuar pruebas (algunas veces llam adas criterios de
ma. Se pro fu n d iza en el m odelado del sistem a en la validación) para verificar el requisito?
Sección 10.6. • ¿Se puede seguir el requisito en el m odelo del sis
tem a que hemos desarrollado?
10.5.5. V a lid a c ió n d e r e q u is ito s • ¿Se puede localizar el requisito en el conjunto de
El resultado del trabajo realizado es una consecuencia objetivos del sistema/producto?
de la ingeniería de requisitos (especificación del siste • ¿Está el requisito asociado con los rendim ientos del
m a e inform ación relacionada) y es evaluada su calidad sistem a o con su com portam iento y han sido esta
en la fase de validación. La validación de requisitos exa blecidas claramente sus características operaciona-
m ina las especificaciones para asegurar que todos los les? ¿El requisito está im plícitamente definido?
requisitos del sistema han sido establecidos sin ambi
güedad, sin inconsistencias, sin omisiones, que los erro
res detectados hayan sido corregidos, y que el resultado
del trabajo se ajusta a los estándares establecidos para
el proceso, el proyecto y el producto.
-fj re as
Requisitos
^ O N S E J O 4^
Un punto fundamental durante la validación Las preguntas planteadas en la lista de com proba
de los requisitos es lo consistencia. Utilice el modelo ción ayudan a asegurar que el equipo de validación dis
del sistema para asegurar que los requisitos pone de lo necesario para realizar una revisión completa
han sido consistentemente establecidos. de cada requisito.
El primer m ecanismo para la validación de los requi

sitos es la revisión técnica formal (Capítulo 8). El equi 10.5.6. G e s tió n d e r e q u is ito s
po de revisión incluye ingenieros del sistema, clientes, En el capítulo anterior se advertía que los requisitos del
usuarios, y otros intervinientes que examinan la espe sistem a cambian y que el deseo de cambiar los requisi- :
cificación del sistem a5 buscando errores en el conteni tos persiste a lo largo de la vida del sistema. La gestión ,
do o en la interpretación, áreas donde se necesitan de requisitos es un conjunto de actividades que ayudan j
aclaraciones, inform ación incompleta, inconsistencias al equipo de trabajo a identificar, controlar y seguir los j
5 En realidad, m uchas Revisiones Técnicas Form ales son dirigidas a
www.FreeLibros.org
m edida que se desarrolla la especificación del sistema. Es m ejor para
el equipo de revisión exam inar pequeñas partes de la especificación,
de form a que se pueda centrar la atención en un aspecto específico
de los requisitos.
174
CAPÍTULO 10 I NGENI ERÍ A DE S I STEMAS
requisitos y los cambios en cualquier momento. M uchas m ien to . En la F ig u ra 10.4 se m u e stra de fo rm a

de estas actividades son idénticas a las técnicas de ges e s q u e m á tic a este p la n te a m ie n to . C ad a m a triz de
tión de configuración del software que se referencian seguim iento id en tifica los re q u isito s relacio n ad o s
en el Capítulo 9. co n uno o m ás aspectos del siste m a o su en to rn o .
E ntre las po sib les m atrices de seguim ien to citam os
las siguientes:
Referencia Web M atriz de seguimiento de características. M uestra
Un artículo titulado ((Configurando el trabajo de gestión los requisitos identificados en relación a las caracte
de requisitos para ti» contiene una guía pragmático: rísticas definidas por el cliente del sistema/producto.
stsc.hill.af.miL/crosstalk/1999/apr/davis.asp
M atriz de seguimiento de orígenes. Identifica el
origen de cada requisito.
Como en la Gestión de Configuración del Software
(GCS), la gestión de requisitos com ienza con la activi M atriz de seguimiento de dependencias. Indica
dad de identificación. A cada requisito se le asigna un cóm o se relacionan los requisitos entre sí.
Unico identificador, que puede tom ar la forma:
M a triz de Seguim iento de subsistem as. Vincula
< tipo d e r e q u is ito x r e q u is ito n.° > los requisitos a los subsistemas que los manejan.
El tipo de requisito tom a alguno de los siguientes M a triz de seguim iento de interfaces. M uestra
valores: F = requisito funcional, D = requisito de datos, como los requisitos están vinculados a las interfaces
C =requisitode comportamiento, / = requisito de inter externas o internas del sistema.
faz, y S = requisito de salida. De esta forma, un requi
sito identificado com o F09 indica que se trata de un
requisito funcional y que tiene asignado el núm ero 9
dentro de los citados requisitos. Cuando un sistema es grande y complejo, determinar
las «conexiones» entre las requisitos puede ser una tarea
desalentadora. Utilice las tablas de seguimiento
para hacer e I trabajo un poco más fácil.
CLAVE
Muchas actividades de gestión de requisitos En m uchos casos, las m atrices de seguim iento se
son tomadas de la GCS incorporan com o parte de un requisito de base de datos
y se utiliza para buscar rápidam ente los diferentes aspec
Una vez los requisitos han sido id en tificad o s, se tos del sistem a a construir afectados por el cam bio de
desarrollarán un conjunto de m atrices para su segui requisito.
B i t ó , M O D E L A D O D E L . S I S T IL M A
Todos los sistem as basados en com putadora pueden

modelarse como una transform ación de la inform ación
empleando una arquitectura del tipo entrada-proceso-
salida. Hatley y Pirbhai [HAT87] han extendido esta
visión para incluir dos características adicionales del
sistema: tratamiento de la interfaz de usuario y trata
miento del mantenim iento y autocomprobación. A un
que estas características adicionales no están presentes
en todos los sistemas basados en computadora, son muy
comunes y su especificación hace más robusto cualquier
modelo del sistema.
Mediante la representación de entrada, proceso, sali
da, tratamiento de la interfaz de usuario y de autocom-
probación, un ingeniero de sistem as puede crear un
www.FreeLibros.org
modelo de componentesde sistema que establezca el fun
damento para análisis de requisitos posteriores y etapas
d e diseño en cada una de las disciplinas de ingeniería.
175
INGENIERÍA DEL SOF TW ARE . UN E N F O Q U E PR AC T I C O
código de barras equivalente), las cajas se m andarán a los con

tenedores apropiados. Las cajas pasan aleatoriam ente y están
Proceso de interfaz de usuario igualm ente espaciadas. L a línea se m ueve lentam ente.
Proceso Funciones de proceso Proceso

de entrada y control de salida
Mantenimiento
y autocomprobación
F IG U R A 10.5. Plantilla del modelo del sistema [HAT87].
Para desarrollar el modelo de sistema, se em plea un

F IG U R A 1 0 .6 . Diagrama de contexto de Arquitectura
esquema del modelado del sistema [HAT87], El inge
del SCCT (ampliado).
niero de sistem as asigna elem entos a cada una de las
cinco regiones de tratamiento del esquema: (1) interfaz
de usuario, (2) entrada, (^ tra tam ien to y control del sis Para este ejemplo, la versión ampliada utiliza un PC
tema, (4) salida y (5 )m antenim iento y autocomproba- en la estación clasificadora. El PC ejecuta todo el software
ción. En la Figura 10.5 se m uestra el form ato del del SCCT; interacciona con el lector de código de barras
esquema de arquitectura. para leer parte de los núm eros de cada caja; interacciona
con la cinta transportadora vigilando los equipos que con
trolan velocidad en dicha cinta; almacena todos los núme
ros de pieza clasificados; interacciona con el operador
Otros métodos de modelizoción del sistema toman
de la estación clasificadora para producir una variedad
una visión orientada a objetos. El enfoque UML puede
ser aplicada o estos sistemas, plonteóndose
de inform es y diagnósticos; envía señales de control al
en los Capítulos 21 y 22. hardware separador para clasificar las cajas; y se comu
nica con la estructura central de la automatización de la
fábrica. En la Figura 10.6 se m uestra el DCS para SCCT
Como casi todas las técnicas de m odelado usadas en
(ampliado).
la ingeniería del software y de sistemas, el esquem a del
m odelado del sistema permite al analista crear una jerar
quía en detalle. En la parte alta de la jerarquía reside el ^C O N SE JO ^f.
diagrama de contexto del sistema (DCS). El diagram a
El DCS permite una visión «global» del sistema
de contexto «establece el límite de inform ación entre el que debes construir, los detalles que necesites
sistema que se está implementando y el entorno en que no deben especificarse en este nivel. Refina
va a operar» [HAT87]. Es decir, el DCS define todos los jerárquicamente el DCS para elaborar el sistema.
suministradores externos de inform ación que em plea el
sistema, todos los consum idores externos de inform a Cada caja de la Figura 10.6 representa una entidad
ción creados por el sistema y todas las entidades que se externa, es decir, un sum inistrador o consum idor de
comunican a través de la interfaz o realizan m anteni
inform ación del sistema. Por ejemplo, el lector del códi
miento y autocomprobación.
go de barras produce inform ación que es introducidaen
Para ilustrar el empleo del DCS, considere una ver el sistema SCCT. El sím bolo para representar todo el
sión ampliada del sistema de clasificación de cinta trans
sistema (o a niveles m ás bajos, subsistem as principa
p o rta d o ra (S C C T ) estudiado anteriorm ente en el les) es un rectángulo con las esquinas redondeadas. De
C apítulo 5. Al ingeniero del sistema se le presenta la
ahí que SCCT se represente en la región de proceso y
siguiente declaración (algo confusa) de objetivos para control en el centro del DCS. Las flechas etiquetadas
el SCCT:
m ostradas en el DCS representan inform ación (datos y
El sistem a SCC T debe desarrollarse de m anera que las cajas
control) que va desde el entorno exterior al sistema
que se m u ev en a lo largo de la cinta transportadora sean iden
tificadas y ordenadas en uno de los seis contenedores al final
SCCT. La entidad externa lector del código de barras
www.FreeLibros.org
de la cinta. Las cajas pasarán a través de una estación clasifi produce una entrada de inform ación etiquetada como
cadora donde se identificarán. Basándose en un núm ero de iden código de b a r r a s . En esencia, el DCS sitúa a cualquier
tificación im preso en un lateral de la caja (se prop o rcio n a un sistema en el contexto de su entorno exterior.
176
CAPÍTULO 10 I NGENI ERÍ A DE SI STEMAS
Interfaz
Peticiones de op era dor Respuestas, inform es y visu a liza cio n e sd e l SCCT
el operador Subsistem a
de interfaz
con el
operador
Proceso y contro l Petición D atosdi calización te m p o ra l

del SCCT de in fo rm e
Subsistema Subsistem a N úm ero
lector decodificador Subsistem a
de piezas C ontrolador
de código del código de control
de m aniobras de m aniobras
de barras de barras
Datos Posición
del código del contenedoi Ó rdenes de m aniobra
Código de barras t-
de barras
S ubsistem a
de acceso Inform es de SCCT
a la b a s e d o d a t o s S ubsistem a
Clave de configuración
Velocidad de inform es
Subsistema
de la cinta
del sensor
de adquisición C lasificación C ontrolador
de registros de las
de datos
com unicaciones
Estado BCR
con la com putadora
Estado de m aniobra central
Estado del sensoi Ci ihr'it'tpma
Entrada de diagnósticos
efe tacómetro Estado de com unicaciones C onfiguración
cte impulsos de los datos
Estado del lector
del inform e
de código de barras
Interfaz de adquisición
de datos Interfaz de diagnóstico Interfaz de salida
FIGURA 10.7. Diagrama de flujo de arquitectura para el SCCT (am pliado).
ejem plo, hardware, software, personas) tal y com o los

CS22SZBB3SI ha asignado el ingeniero de sistemas.
HDCS es un precursor del diagrama de flujo de c t e , El diagram a inicial de flujo del sistema (DFS) se con
que se e s L d a en el C a p ítb 12. vierte en el nudo superior de unajerarquía de DFS. Cada
rectángulo redondeado del DFS original puede expan
El ingeniero de sistemas refina el diagram a de con dirse en otra plantilla de arquitectura dedicada exclusi
texto de arquitectura estudiando con m ás detalle el rec vamente a ella. Este proceso se ilustra esquemáticamente
tángulo sombreadode la Figura 10.6. Se identifican los en la Figura 10.8. Cada uno de los DFS del sistema pue
subsistemas principales que perm iten funcionar al sis de usarse com o punto de partida de subsiguientes fases
tema clasificador de cinta transportadora dentro del con de ingeniería para el subsistema que se describe.
texto definido por el DCS. En la Figura 10.7 los
subsistemas principales se definen en un diagrama de
flujo del sistema (D F S )que se obtiene del DCS. El flu
jo de información a través de las regiones del DCS se R e f e r e n c ia W ebl
osa para guiar al ingeniero de sistemas en el desarrollo Para corae ferel rré b cb de Hatley-Pirbhai se puede acudir a
de DFS (un «esquema» m ás detallado del SCCT). El www.hasys.com/papers/hp_description.html
diagrama de flujo de la arquitectura m uestra los subsis
temas principales y el flujo de las líneas de inform ación Se pueden especificar (delimitar) los subsistemas y
suportantes (datos y control). Además, el esquema del la inform ación que fluyen entre ellos para los subsi
sistema divide el proceso del subsistema en cada una guientes trabajos de ingeniería. Una descripción narra
www.FreeLibros.org
de las cinco regiones de proceso estudiadas anterior tiva de cada subsistema y una definición de todos los
mente. En este punto, cada uno de los subsistemas pue datos que fluyen entre los subsistemas son elem entos
de contener uno o m ás elem entos del sistem a (por importantes de la Especificación del Sistema.
177
INGENIERÍA DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
Diafragma de flujo de más alto nivel de la arquitectura"^
— □
DFA de A
j L J —f B > FA de B
DFA de C M
t ) X □
1^ * 1 — E 3 )7 O
□ - — 1
1 1 1— u un
12J
F IG U R A 1 0 .8 . C o n stru c c ió n d e u n a je ra rq u ía DFA.
Un sistema de alta tecnología comprende varios com prende una planificación de la estrategia de la infor
ponentes: hardware, software, personas, bases de datos, mación (P E I),un análisis del área de negocio (AAN)y
docum entación y procedimientos. La ingeniería de sis un análisis específico de aplicación que de hecho for
temas ayuda a traducir las necesidades del cliente en un m an parte de la ingeniería del software.
modelo.de sistema que utiliza uno o más de estos com La ingeniería de productos es un enfoque de la inge
ponentes. niería de sistemas que em pieza con el análisis del sis
La ingeniería de sistem as com ienza tom ando una tema. El ingeniero de sistemas identifica las necesidades
«visión global». Se analiza el dom inio de negocio o del cliente, determ ina la viabilidad económica y técni
producto para establecer todos los requisitos básicos. ca, y asigna funciones y rendim ientos al software, hard
El en fo q u e se estrech a en to n ce s a una « v isió n de ware, personas y bases de datos; los componente claves
dom inio», donde cada uno de los elem entos del sis de la ingeniería.
tem a se analiza individualm ente. C ada elem ento es L a ingeniería del sistem a dem anda una intensa
asignado a uno o m ás com ponentes de ingeniería que com unicación entre el cliente y el ingeniero del siste
son estudiados por la disciplina de ingeniería corres ma. Esto se realiza a través de un conjunto de activi
pondiente. dades bajo la denom inación de ingeniería de requisitos
La ingeniería de procesos de negocio es un enfoque -identificación, análisis y negociación, especificación,
de la ingeniería de sistemas que se usa para definir arqui m odelización, validación y gestión-.
tecturas que perm itan a un negocio utlizar la inform a U na vez que los requisitos hayan sido aislados, el
ción eficazm ente. La intención de la ingeniería de m odelado del sistem a puede ser realizado, y las repre
procesos de negocio es crear minuciosas arquitecturas sentaciones de los subsistemas principales pueden ser
de datos, una arquitectura de aplicación y una infraes desarrolladas. La tarea de la ingeniería del sistema fina
tructura tecnológica que satisfaga las necesidades de la liza con la elaboración de una Especificación del Siste
estrategía de negocio y los objetivos de cada área de m a -u n docum ento que sirve de base para las tareas de
negocio. La ingeniería de procesos de negocio com ingeniería que se realizarán posteriorm ente-.
[C R I9 2 ] C h n s te l, M .G ., y K .C . K a n g , « Issu esin R e q u ire m e n ts Inform ation Engineering: Book II -

[M A R 9 0 ] M a r tin , J .,
E lic ita tio n » , S o ftw a re E n g in e e rin g In s titu te , C M U /S E I- Planning and Analysis, P re n tic e H a ll, 1990.
9 2 -T R -1 2 7, S e p te m b e r 1992.
[M O T 9 2 ] M o ta m a rri, S ., « S y s te m s M o d e llin g a n d D escrip-
[G R A 6 9 ] G ra h a m , R .M ., e n Proceedings 1969 NATO Con- tio n » , Software Engineering Notes, v o l. 1 7 ,n .° 2 , A bril
ference o n S o fia r e Engineering, 1969. 1 9 9 2 ,p p . 5 7 -6 3 .
[G U T 9 9 ] G u ttm a n , M ., « A r c h ite c tu r a l R e q u ir e m e n ts f o r a [S O M 9 7 ] S o m e rv ille , I . , y P. S a w y e r ,Requirements Enginee
C h a n g in g B u sin e ss W o rld » , Research Briefsfrom Cutter ring, W ile y , 1997
Consortium (an online Service), J u n e 1, 1999.
[S P E 9 3 ] S p e w a k , S ., EnterpriseArchitecture Planning, Q E D
[H A R 9 3 ] H a res, J,S ., Information Engineeringfor the Advan P u b lis h in g , 1993.
www.FreeLibros.org
ced Practitioner, W ile y , 1 9 9 3 ,pp. 12-13.
[T H A 9 7 ] T h a y e r, R .H ., y M . D o r f m a n , Software Require
[H A T 87] H a tle y ,D .J ., e l .A . P irb h a i, StrategiesforReal-Time ments Engineering, 2 .a e d ., IE E E C o m p u te r S o c iety Press,
System Specification, D o rs e t H o u s e , 1987. 1997. ' '
178
CAPITULO 10 I NGENI ERI A DE S I STEMAS
101. Encuentre tantos sinónimos como pueda de la palabra 10.10.Investigue las técnicas de'contabilidad que se emplean
«sistema». ¡Buena suerte! para un análisis detallado de coste/beneficio de un sistema
que requiera algo de fabricación y m ontaje de hardware.
10.2. Construya una descripción en estructura jerárquica para
Intente escribir un libro de directrices que pueda aplicar un
un sistema, producto o servicio que le sea familiar. El plantea
gestor técnico.
miento abarcará los elementos fundamentalesdel sistema (hard
ware, software, etc.) de una rama concreta de dicha estructura. 10.11. Desarrolle el diagrama de contexto DCS y el resto de
10.3. Seleccione un gran sistema o producto con el que esté diagramas de flujo de un sistema a su elección (o definido por
familiarizado. Defina el conjunto de dominios que describen la su profesor).
visión global de él. Describa el conjunto de elementos que com 10.12. Escriba una descripción de un módulo del sistema que
pongan uno o dos dominios. Para un elemento, identifique los pudiera estar contenido en la especificación de diagrama de
componentes técnicos con los que hay que hacer ingeniería. arquitectura de uno o más de los subsistemas definidos en los
10.4. Seleccione un gran sistema o producto con el que esté DFA desarrollados para el problema 10.11.
familiarizado. Establezca los supuestos, simplificaciones,limi- 10.13. Investigue documentación sobre herramientas CASE
taciones, restricciones y preferencias que deberían haberse y escriba un breve documento describiendo cómo trabajan las
hecho para construir un modelo de sistema eficaz y realizable. herramientas de modelado y simulación. Alternativa: Reúna
10.5. La ingeniería de proceso de negocio requiere definir información de dos o más vendedores de CASE que suminis
idatos, arquitectura.de aplicaciones, además de una infraes tren herramientas de modelado y simulación y valore las simi
tructura tecnológica. Describa cada uno de estos términos litudes y las diferencias.
mediante un ejemplo.
10.14. Basándose en la documentación que le proporcione su
10.6. La planificación de la estrategia de la información empie profesor, desarrolle una pequeña Especificación de Sistema
za por la definición de objetivos. Ponga ejemplos de cado uno para uno de los siguientes sistemas:
de los dominios de negocio.
a. Un sistema de edición de vídeo digital no lineal
,10.7. Un ingeniero de sistemas puede venir de una de tres pro
b. Un escáner digital para ordenador personal
cedencias: el desarrollo de sistemas, el cliente o una tercera
'organización. Discuta los pros y contras de cada procedencia. c. Un sistema de correo electrónico
Descnba a un ingeniero de sistemas «ideal». d. Un sistema para apuntarse a la universidad
10.& Su profesor les repartirá una descripción de alto nivel de e. Un proveedor de acceso a internet
un sistema o producto.
f. Un sistema interactivo de reserva de hoteles
a. Desarrolle un conjunto de cuestiones que debería pre
guntar como ingeniero de sistemas. g. Un sistema de interés local
b. Proponga al menos dos asignaciones diferentes para el Asegúrese de crear los modelos de arquitectura descritos en
sistema basándose en las respuestas de su profesor a la Sección 10.6
sus preguntas. 10.15. ¿Existen características de un sistema que no se pue
c. En clase, compare sus respuestas con las de sus com dan establecer durante las actividades de ingeniería de siste
pañeros. mas? Describa las características, si existen, y explique por
qué se debe retrasar su consideración a fases posteriores de la
¡10.9. Desanolle una lista de comprobación para los atributos ingeniería.
¡«considerar cuando hay que evaluar la «viabilidad» de un sis-
¡jema o producto. Estudie la interacción entre los atributos e 10.16. ¿Existen situaciones en las que se pueda abreviar o eli
¡tatente proporcionar un método para puntuar cada uno de minar completamente la especificación formal del sistema?
¡panera que se obtenga una «puntuación de viabilidad». Explíquelo.
I f e f lS T .K H T U R A S y f u e n t e s d e i n f o r m a c i ó n .
|5elian publicado relativamente pocos libros sobre inge- ring Guidehook, CRC Press, 1996), Wymore (Model-Based
|nería de sistemas en los últimos años. Entre ellos desta Systems Engineering, CRC Press, 1993), Lacy (SystemEngi
camos: neering Management, McGraw-Hill, 1992), Aslakseny Bel-
BlanchardjB.S., System Engineering Management, 2." ed., cher (System s Engineering, Prentice-H all,1992), Athey
PMley, 1997. ' (SystematicSystems Approach, Prentice-Hall, 1982), y Blan-
Rechtin,E., y M.W. Maier, TheA rt o f Systems Architec- chard y Fabrycky (SystemsEngineering andAnalysis, Pren
B/ig, CRC Press, 1996. tice-Hall, 1981) presentan el proceso de la ingeniería del
Weiss, D., et al.,Software Product-LineEngineering, Addi- sistema (con un énfasis diferente de la ingeniería) y ofrecen
www.FreeLibros.org
wn-Wesley, 1999. una valiosa guía.
Libros como los de Armstrong y Sage (Intoduction to Sys- En los Últimos años, los textos de ingeniería de la infor
ttms Engineering, Wiley, 1997), Martin (Systems Enginee mación han sido reemplazados por libros que se centran en
179
la in g e n ie ría d e p ro c e s o d e n e g o c io . S c h e e r (Business Pro ware Requirements Engineering, I E E E C o m p u te r S o c ie ty

cess Engineering: Reference M odelsfor Industrial Enterpri P re s s , 1 9 9 0 )p re s e n ta u n p la n te a m ie n to d e e s tá n d a r e s y d irec
ses, S p rin g e r-V e rla g , 1 9 9 8 ) d e s c rib e m é to d o s d e m o d e la d o tric e s p a r a e l tra b a jo d e a n á lis is .
d e p ro c e s o s d e n e g o c io p a r a e m p re s a s c o n a m p lio s s is te m a s P a r a a q u e llo s le c to re s in v o lu c ra d o s a c tiv a m e n te e n e l tra
d e in fo rm a c ió n . L o z in s k y (Enterprise-Wide Software Solu b a jo d e s is te m a s o in te re s a d o s e n u n tra ta m ie n to m á s sofisti
tions: Integration Strategies andPractices, A d d iso n -W e s le y , c a d o s o b re e l te m a , se p ro p o n e lo s lib ro s d e G e ra ld W ein berg’s
1 9 9 8 )p la n te a e l u s o d e p a q u e te s s o ftw a re c o m o u n a so lu c ió n (Anlntroduction to General System Thinking, W i ley - Inters-
q u e p e rm ita a u n a c o m p a ñ ía m ig r a r d e lo s s is te m a s h e r e d a c ie n c e , 1 9 7 6 , y O n the Design o f Stahle Systems, W ilw y-
d o s a p ro c e s o s d e n e g o c io m o d e rn o s . M a rtin (Information In te rs c ie n c e , 1 9 7 9 ) p e r m ite n u n a e x c e le n te d is c u s ió n sobre
Engineering, 3 v o lú m e n e s , P re n tic e -H a ll, 198 9 , 199 0 , 1 9 91) e l « p e n s a m ie n to g e n e ra l d e s iste m a s» q u e im p líc ita m e n te lle -
p r e s e n ta u n p la n te a m ie n to c o m p r e n s iv o s o b re lo s tó p ic o s d e v a a u n a c e rc a m ie n to g e n e ra l al a n á lis is y d is e ñ o d e sistem as.
la in g e n ie ría d e la in f o rm a c ió n . L ib r o s c o m o lo s d e H a re s L ib ro s m á s r e c ie n te s s o n lo s d e W e in b e r g (General Princi
[H A R 9 3 ], S p e w a k [S P E 9 3 ] y F l y n n y F ra g o s o -D ia z (Infor pies o f Systems Design, Dorset House, 1 9 9 8 , y Rethinking
mation M odeling: A n International Perspective, P r e n tic e - systems Analysis and Design, D o r s e t H o u s e , 1 9 8 8 ) co n tin ú a n
H a ll, 1 9 9 6 ) tr a ta n e s te te m a c o n d e ta lle . e n la tr a d ic ió n d e su m á s a v a n z a d o tra b a jo .
D a v is y Y en (TheInformation system Consultant’s Hand- U n a a m p lia v a ria c ió n d e f u e n te s d e in fo rm a c ió n so b re inge
hook: Systems Analysis and Design, C R C P re s s , 1 9 9 8 )p re - n ie ría d e s is te m a s y e le m e n to s r e la c io n a d o s e s tá n d isp o n ib le s
s e n ta n u n a c o b e r tu r a e n c ic lo p é d ic a d e los r e s u lta d o s d e l e n in te m e t. U n a l is ta a c tu a liz a d a d e r e fe r e n c ia s a p á g in a s web
a n á lis is y d is e ñ o d e s is te m a s e n e l d o m in io d e lo s s ite m a s d e s o b re i n g e n ie ría d e s is te m a s , in g e n ie ría d e la in fo rm a c ió n ,
in fo rm a c ió n . U n v o lu m e n m á s re c ie n te d e los m is m o s a u to in g e n ie ría d e p r o c e s o s d e n e g o c io e in g e n ie ría d e p ro d u c to s
re s (Standards, Guidelines and Examples: System and Soft p u e d e n s e r e n c o n tr a d a s e n http://www.pressman5.com
C A PÍT U L O
CONCEPTOS Y PRINCIPIOS
DEL ANÁLISIS
A ingeniería de requisitos del softw are es u n p ro ceso de descubrim iento, refinam iento,
L m odelado y especificació n . Se refinan en d etalle los req u isito s del sistem a y el papel
asignado al softw are — in icialm enteasignado po r el in g en iero del sistem a— . Se crean
m od elo s de los requisitos de datos, flujo de inform ación y co n tro l, y del c o m p o rtam ien to ope
rativo. Se analizan soluciones alternativas y el m odelo com pleto del análisis es creado. D onald
R e ife r [R E I94] d escrib e el p ro ceso de in g e n iería de req u isito s del softw are e n el siguiente
párrafo:
L a ingeniería de requisitos es el uso sistem ático de procedim ientos, técnicas, lenguajes y herram ientas para
obtener con un coste reducido el análisis, docum entación, evolución continua de las necesidades del usuario
y la especificación del com portam iento externo de un sistem a que satisfaga las necesidades del usuario. T enga
en cuenta que todas las disciplinas de la ingeniería son sem ejantes, la ingeniería de requisitos no se guía por
conductas esporádicas, aleatorias o por m odas pasajeras, si no que se debe b asar en el uso sistem ático de apro—
xim aciones contrastadas.
T anto el desarro llador com o el cliente tienen un papel activo en la ingeniería de requisitos
del softw are —un conjunto de actividades que son denom inadas análisis— . El cliente intenta
rep lan tear un sistem a confuso, a nivel de descripción' de datos, fu n cio n es y com portam iento,
en d etalles concretos. El desarrollador actúa com o un interrogador, co m o consultor, com o p er—
sona que resuelve p roblem as y com o negociador.
VISTAZO RÁPIDO
. ¿Qué es? El p ap el global del softw are e n co m p lejas, u n « a n a lista d e siste m a s» se incorpora a l m odelo d e l softw are y
un gran sistem a e s identificado d u ra n — form ado e n los a sp e c to s d e l negocio e s v a lid a d a ta n to por el ingeniero del
te la in g en ie ría del siste m a (C apítulo d el d om inio d e la a p licació n — p u e d e softw are com opor los clientes/usuarios.
10). De cu alq u ier m an e ra, e s necesario re aliz a r e s t a ta re a . ¿C uál e s e l p rod u cto o b ten id o ? U na
considerar u n a visión lo m ás p rofunda ¿Por q u é e s im p ortan te? Si no a n a li— re p re se n ta c ió n e fe c tiv a d e l so ftw a re
;s, posible del p a p e l d el softw are — para z a s , e s m uy p ro b a b le q u e c o n stru y a s d e b e se r p ro d u c id a com o u n a c o n se —
, com prender los req u isito s específicos u n a so lu c ió n so ftw a re m uy e le g a n te c u en cia del a n á lis is d e requisitos. Tan—
' que d e b e n se r c o n s id e ra d o s e n la q u e re su e lv a in c o rre c ta m e n te e l p ro — to los re q u is ito s d e l s is te m a com o los
)' construcción d e u n so ftw a re d e a lt a blerna. El re su lta d o e stie m p o y d in ero re q u is ito s d e l so ftw a re p u e d e n se r
; calidad — .E ste e s el tra b a jo d el a n á li— perd id o , fru strac ió n p e rso n al y c lie n — re p re se n ta d o s u tilizan d o u n prototipo,
!i sis de requisitos del so ftw are.P ara re a — te s descontentos. u n a e s p e c ific a c ió n o u n m o d elo sim —
i) lizar el tra b a jo a d e c u a d a m e n te , se ¿C uáles son los p asos? Los requisitos bólico.
deben seguir un conjunto d e co n c ep to s ¿Cómo p u e d o esta r se g u r o d e q u e
d e d a to s, fu n cio n es y c om portam iento
y principios fu n d a m e n ta les. son id en tificad o s por la o b ten ció n d e lo h e h e c h o c o r r e c ta m e n te ? El
) ¿Quién lo h a ce? G e n era lm e n te,el inge- in fo rm a ció n f a c ilita d a por el c lien te. re s u lta d o o b te n id o d e l a n á l i s i s d e
• niero d el softw are e s q u ién re a liz a el Los req u isito s son refin ad o s y a n a liz a — re q u is ito s d el softw are d e b e se r revi—
- a n á lisis d e re q u isito s. E n c u a lq u ie r dos p a ra verificar su c la rid a d ,c o m p le - sa d o p a ra co n se g u ir: c la r id a d , com -
- c aso , p a r a a p lic a c io n e s d e n e g o cio titu d y co nsistencia. L a especificación pletitud y consistencia.
fc '
El an álisis y la esp ec ificació n de los req u isito s puede p are c e r u n a ta re a relativam ente sen—
cilla, p ero las ap arien cias engañan. El co n ten id o de co m u n ic ac ió n e s m uy denso. A bundan
las o casio n es p ara las m alas in terp re tacio n es o falta de in form ación. E s m u y p ro b a b le que
hay a am b igüedad. E l d ilem a al que se en fren ta el in g en iero del softw are puede en tenderse
m uy b ien re p itie n d o la fam o sa frase de u n clien te anónim o: «S é que cree que e n ten d ió lo que
www.FreeLibros.org
pien sa que d ije, pero n o estoy seguro de que se d é c u en ta de que lo que escu ch ó n o es lo que
y o quise decir.»
181
I N G E N IE RÍ A DEL S OFT W ARE . UN EN FOQ UE P R Á C T I C O
El análisis de los requisitos es una tarea de ingeniería información se le proporcionará al sistema. Por ejem
del software que cubre el hueco entre la definición del plo, el cliente desea un informe diario que indique qué
software a nivel sistema y el diseño del software (Fig. piezas se han tom ado del inventario y cuántas piezas
11.1). El análisis de requisitos permite al ingeniero de similares quedan. El cliente indica que los encargados
sistemas especificar las característicasoperacionalesdel del inventario registrarán el núm ero de identificación de
software (función, datos y rendim ientos),indica la inter cada pieza cuando salga del inventario.
faz del software con otros elementos del sistema y esta
blece las restricciones que debe cum plir el software.
.- . ' .tic ■- - fe mayor parte

(fe! tiempo de! proyecto— no implementondo
, 0 probando, sino intentando decidir qué construir.
Briol Uwreoce
El análisis de requisitos del software puede dividir

se en cinco áreas de esfuerzo: (1) reconocim iento del
problema, (2) evaluación y síntesis, (3) modelado, (4)
especificación y ( 5 ) revisión. Inicialmente, el analista
estudia la Especificación del Sistema (si existe alguna)
y el Plan del Proyecto de Software. Es importante enten
der el software en el contexto de un sistema y revisar el
F IG U R A 1 1 .1 . Análisis com o puente entre la ingeniería
ámbito del software que se empleó para generar las esti y el diseño de software.
m aciones de la planificación. A continuación, se debe
establecer la com unicación para el análisis de m anera
que nos garantice un correcto reconocim iento del pro
blema. El objetivo del analista es el reconocim iento de
los elem entos básicos del problem a tal y com o los per Cuento con hacer uno parte del diseño durante el análisis
cibe el cliente/usuario. de requisitos y uno porte del análisis de requisitos durante
La evaluación del problema y la síntesis de la solución el diseño.
es la siguiente área principal de esfuerzo en el análisis. El
analista debe definir todos los objetos de datos observa U na vez evaluados los problem as actuales y la infor
bles externamente, evaluar el flujoy contenidode la infor m ación deseada (entradas y salidas), el analista empie
mación, definir y elaborar todas las funciones del software, za a sintetizar una o m ás soluciones. Para empezar, se
entender el comportamiento del software en el contexto definen en detalle los datos, las funciones de tratamiento
de acontecimientos que afectan al sistem a, establecer y el com portam iento del sistema. Una vez que se ha
las características de la interfaz del sistema y descubrir establecido esta información, se consideran las arqui
restricciones adicionales del diseño. Cada una de estas tecturas básicas para la im plem entación. Un enfoque
tareas sirve para describirel problema de manera que se cliente/servidor parecería apropiada, pero ¿está dentro
pueda sintetizar un enfoque o solución global. del ám bito esbozado en el P lan del Software? Parece
P or ejem plo, un m ayorista de recam bios de auto que sería necesario un sistema de gestión de bases de
m óviles necesita un sistema de control de inventario. El datos, pero, ¿estájustificada la necesidad de asociación
analista averigua que los problem as del sistema manual del usuario/cliente? El proceso de evaluación y síntesis
que se emplea actualmente son: (1) incapacidad de obte continúa hasta que am bos, el analista y el cliente, se
ner rápidam ente el estado de un componente; (2) dos o sienten seguros de que se puede especificar adecuada
tres días de m edia para actualizar un archivo a base de mente el software para posteriores fases de desarrollo.
tarjetas; (3) múltiples órdenes repetidas para el mismo A lo largo de la evaluación y síntesis de la solución,
vendedor debido a que no hay m anera de asociar a los el enfoque prim ario del analista está en el «qué» y no
vendedores con los componentes, etc. Una vez que se en el «cómo». ¿Qué datos produce y consume el siste
han identificado los problem as, el analista determina ma, qué funciones debe realizar el sistema, qué interfa
qué inform ación va a producir el nuevo sistema y qué ces se definen y qué restricciones son aplicables?1.
www.FreeLibros.org
'D avis [DAV93] arg u m en ta que los térm inos «que» y «cómo» son
dem asiado vagos Puede leer su libro si desea encontrar un intere
san te debate sobre el tem a '
182
CAPÍTULO 11 C O N C E P T O S Y P R IN C IP IO S DEL A N Á LISIS
Durante la actividad de evaluación y síntesis de la En el Capítulo 2, indicamos que puede no ser posi
solución, el analista crea m odelos del sistem a en un ble una especificación detallada en esta etapa. El clien
esfuerzo de entender mejor el flujo de datos y de control, te puede no estar seguro de lo que quiere. El
el tratamiento funcional y el comportamiento operativo desarrollador puede no estar seguro de que un enfoque
y el contenido de la información. El m odelo sirve como específico consiga apropiadamente el funcionam iento
fundamentopara el diseño del software y como base para y rendim iento adecuados. Por estas y otras m uchas razo
la creación de una especificación del software. nes, se puede llevar a cabo un enfoque alternativo del
análisis de requisitos, denominado creación de p ro to ti
¿Cuál será mi primer p o s oprototipado. El prototipado se com enta m ás tar
• objetivo en esta etapa? de en este capítulo.
IDENTIFICACIÓN DE REQ U ISIT O S PARA EL SOFTWARE

Anles que los requisitos puedan ser analizados, m ode Estas preguntas ayudan a identificar todos los p a r ti
lados o especificados, deben ser recogidos a través de cipantes que tienen un interés en el software a construir.
ün proceso de obtención. Un cliente tiene un problem a Además, las preguntas identifican los beneficios medi-
que pretende sea resuelto con una solución basada en bles en una implementación correcta de posibles alter
Computadora. Un desarrollador responde a la solicitud nativas para un desarrollo norm al del software.
de ayuda del cliente. La com unicación ha empezado. El siguiente conjunto de preguntas perm ite al ana
Pero como ya hemos señalado, el camino de la com uni lista obtener un m ejor entendimiento del problem a y al
cación al entendimiento está a m enudo lleno de baches. cliente com entar sus opiniones sobre la solución:
• ¿Cómo caracterizaría una «buena» salida (resultado)
11.2.1. Inicio d el p r o c e so generada para una buena solución?
Latécnica de obtención de requisitos m ás usada es lle > ¿A qué tipo de problema(s) va dirigida esta solución?
var a cabo una reunión o entrevista preliminar. La pri • ¿Puede m ostrarm e (o describirm e) el entorno en que
mera reunión entre el ingeniero del software (el analista) se utilizará la solución?
y el cliente puede compararse con la prim era cita entre ■ ¿Elay aspectos o restricciones especiales del rendi
dos adolescentes. Nadie sabe qué decir o preguntar; los miento que afecten a la manera de enfocar la solución?
dos están preocupados de que lo que digan sea m alen
tendido; ambos piensan qué pasará (los dos pueden tener
expectativas radicalmentediferentes): los dos están dese
ando que aquello termine, pero, al m ism o tiem po, ambos doras y respuestas claras evitan muchas
desean que la cita sea un éxito.
Q fto á
El últim o conjunto de preguntas se concentra en la
«■ U figce uno pregunto es un tonto por cinco
eficacia de la reunión. Gauge y W einberg [GAU89] las
•■- quién no lo hoce es tonto poro siempre
denom inan «meta-preguntas» y proponen la siguiente
jfof*|tÍ»dÉN
lista (abreviada):
Sin embargo, hay que em pezar la com unicación. • ¿Es usted la persona adecuada para responder a estas
Gauss y W einberg [GAU89] sugieren que el analista preguntas? ¿Sus respuestas son «oficiales»?
empiece preguntando cuestiones de contexto libre. Es • ¿Estoy preguntando demasiado?
flécir, un conjunto de preguntas que llevarán a un enten ■ ¿Hay alguien m ás que pueda proporcionar inform a
dimiento básico del problema, qué solución busca, la
ción adicional?
fiaturaleza de la solución que se desea y la efectividad
■ ¿Hay algo m ás que debería preguntarle?
del primer encuentro. El prim er conjunto de cuestiones
dé contexto libre se enfoca sobre el cliente, los objeti
vos generales y los beneficios esperados. Por ejemplo,
él analista podría preguntar:
Si un sistema o producto va o servir poro muchos usuarios,
¿Quién está detrás de la solicitud de este trabajo? los requisitos deberán ser obtenidos de un grupo
* ¿Quién utilizará la solución? representativo de usuarios. Sisólo unopeisona define
• ¿Cuál será el beneficio económico del éxito de una iodos ios requisitos, el riesgo de aceptación seré olio.
www.FreeLibros.org
solución? Estas preguntas (y otras) ayudarán a «rom per el hie
♦ ¿Hay alguna otra alternativa para la solución que lo» e iniciar la com unicación tan esencial para el éxito
necesita? del análisis. Pero el form ato de reunión tipo «pregunta
183
INGE NIE RÍA DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
y respuesta» no es un enfoque que haya tenido mucho lo suficientemente informal como para animar el libre
éxito. De hecho, esta sesión de preguntas y respuestas flujo de ideas.
debería emplearse solamente en el prim er encuentro y • un «coordinador» (que puede ser un cliente, un desa-
sustituirsedespués por una m odalidad que combine ele rrollador o un tercero) que controle la reunión.
mentos de resolución del problema, negociación y espe • se usa un «mecanismo de definición» (que puede ser
cificación. En la siguiente sección se presenta un enfoque hojas de trabajo, gráficos, carteles o pizarras).
a reuniones de este tipo.
• el objetivo es identificar el problema, proponer ele
mentos de solución, negociar diferentes enfoques y
11.2.2. T é c n ic a s p a r a f a c i l it a r l a s e s p e c if ic a c io especificar un conjunto prelim inar de requisitos de
n e s d e u n a a p lic a c ió n la solución en una atm ósfera que perm ita alcanzar el
Los clientes y los ingenieros del software a m enudo tie objetivo.
nen una mentalidad inconsciente de «nosotros y ellos». ¿Qué diferencias existen
En vez de trabajar como un equipo para identificar y refi-
nar los requisitos, cada uno define por derecho su propio
«territorio»y se comunica a través de una serie de memo
• entre una reunión TFEA
y una reunión ordinaria?
randos, papeles de posiciones formales, documentos y Para com prender m ejor el flujo de acontecimientos
sesiones de preguntas y respuestas. La historia ha demos tal y como ocurren en una reunión TFEA, presentamos
trado que este m étodo no funciona muy bien. Abundan un pequeño escenario que esboza la secuencia de acon
los malentendidos, se omite inform ación importante y tecim ientos que llevan a la reunión, los que ocurren en
nunca se establece una buena relación de trabajo. la reunión y los que la siguen.
C o g ita :
P ^ f e r f in r in Los hechos no dejan de existir por ignorarlos.
AM ous H uxley
Una aproximación a FASI es llamada ((Diseño común de
apllcaclones»(JAD). Un detallado estudio de JAD puede
encontrarse en
En las reuniones iniciales entre el desarrollador y el
www.bee.net/bluebird/jaddoc.htm cliente (Sección 11.2.1) se dan preguntas y respuestas
básicas que ayudan a establecer el ámbito del problema
Con estos problem as en mente es por lo que algunos y la percepción global de una solución. Fuera de estas
investigadores independientes han desarrolladoun enfo reuniones iniciales, el cliente y el desarrollador escri
que orientado al equipo para la reunión de requisitos ben una «solicitud de producto» de una o dos páginas.
que se aplica durante las prim eras fases del análisis y Se selecciona lugar, fecha y hora de reunión TFEA y se
especificación. Denominadas T écn ica s p a r a fa c ilita r elige un coordinador. Se invita a participar a represen
las especificaciones de la aplicación (T F E A ),este enfo tantes de ambas organizaciones; la del cliente y la de
que es partidario de la creación de un equipo conjunto desarrollo. Se distribuye la solicitud de producto a los
de clientes y desarrolladores que trabajan juntos para asistentes antes de la fecha de reunión.
identificar el problema, proponer soluciones, negociar
diferentes enfoques y especificar un conjunto prelim i
nar de requisitos de la solución [ZAH90]. Hoy en día,
las TFEA son empleadas de forma general por los sis Antes de una reunión FAST confecciona una lista de
temas de información, pero la técnica ofrece un poten objetos, servicios, restriccionesy criterios de rendimiento
cial de m ejora en aplicaciones de todo tipo.
Se han propuesto m uchos enfoques diferentes de M ientras se revisa la solicitud días antes de la reu
TFEA2. Cada uno utiliza un escenario ligeramente dife nión, se pide a todos los asistentes que hagan una lista
rente, pero todos aplican alguna variación en las siguien de o b je to s que form en parte del entorno del sistema,
tes directrices básicas: otros objetos que debe producir el sistem a y objetos que
• la reunión se celebra en un lugar neutral y acuden usa el sistema para desarrollar sus funciones. Además,
tanto los clientes como los desarrolladores. se pide a todos los asistentes que hagan otra lista de ser
• se establecen norm as de preparación y de partici vicios (procesos o funciones) que m anipulan o interac-
pación. túan con los objetos. Finalmente, se desarrollan también
• se sugiere una agenda lo suficientem ente form al listas de re stric c io n e s (por ejem plo, costes, tamaño,
como para cubrir todos los puntos importantes, pero peso) y criterios de rendim iento (por ejem plo, veloci-
www.FreeLibros.org
2 Dos de los enfoques m ás populares de TFEA son Desarrollo Con
junto de Aplicaciones (JAD), desarrollado por IBM, y The METHOD,
desarrollado por Perform ance Resources, Inc., Falls Church, VA.
184
dad, precisión). Se inform a a los asistentes que no se producto, pues todo el m undo debería estar de acuer
espera que las listas sean exhaustivas, pero que sí que do en que el desarrollo (o adquisición) del producto
reflejen su punto de vista del sistema. estájustificada. U na vez que se ha conseguido el acuer
Por ejem plo3, imagínese que a un equipo de trabajo do, cada participante presenta sus listas para su estu
TFEA de una com pañía de productos para el consum i dio. Las listas pueden exponerse en las paredes de la
dor se le ha dado la siguiente descripción del producto: habitación usando largas hojas de papel, pinchadas o
N uestras investigaciones indican que el m ercado de siste pegadas, o escritas en una pizarra. Idealm ente debería
mas de seguridad para el hogar está creciendo a un ritm o del poderse m anejar separadam ente cada entrada de las
40 por 100 anual. N os gustaría entrar en este m ercado c o n s listas para poder com binarlas, borrarlas o añadir otras.
truyendo un sistem a de seguridad para el hogar basado en un En esta fase, está estrictam ente prohibido el debate o
m icroprocesador que proteja y/o reconozca varias situaciones
las críticas.
indeseables tales com o irrupciones ilegales, fuego, inundacio
nes y otras. E l producto, provisionalm ente W&maáoHogarSe-
guro, utilizará lo s sensores adecu ad o s para d etectar cada
situación, puede p rogram arsepor el propietario del h ogar y lla
Evita el impulso de cortar la Idea de un cliente
mará autom áticam ente a una agencia d e vigilancia cuando se
detecte alguna de estas situaciones. por ((demasladocostosa» o «poco próctica».
lo ideo es negociar alga que sea aceptable paro todos.
En realidad, se proporcionatía considerablemente más Es decir, debes tener uno mente abierto.
información en esta fase. Pero incluso con inform ación
adicional, habría ambigüedades presentes, existirán om i U na vez que se han presentado las listas individua
siones probablemente y podrían ocurrir errores. Por aho les sobre un tem a, el grupo crea una lista combinada.
ra, la «descripción de producto» anterior bastará. La lista com binada elim ina las entradas redundantes y
El equipo TFEA está compuesto por representantes de añade las ideas nuevas que se les ocurran durante la pre
marketing, ingeniería del software y del hardware, y de la sentación, pero no se elim ina nada más. C uando se han
fabricación también participará un coordinador externo. creado las listas com binadas de todos los tem as, sigue
el estudio - m o d e r a d o p o r el c o o rd in a d o r-. La lista
com binada es ordenada, ampliada o redactada de nue
vo para reflejar apropiadamente el producto o sistema
CLAVE que se va a desarrollar. El objetivo es desarrollar una
los objetos deben ser manipulados por servicios y deben lista de consenso por cada tem a (objetos, servicios, res
«contemplar» las restrlcclonesy rendimientos definidos tricciones y rendimiento). Después estas listas se ponen
por el equipo FAST. aparte para utilizarlas posteriormente.
Todos los componentes del equipo TFEA desarrollan U na vez que se han com pletado las listas de con
las listas descritas anteriormente. Los objetos descritos senso, el equipo se divide en subequipos; cada uno tra
pata HogarSeguro podrían incluir detectores de humo, baja para desarrollar una m ini-especificación de una o
sensores de ventanas y puertas, detectores de m ovim ien m ás entradas de cada lista4. La m ini-especificación es
tos, una alarma, un acontecim iento (se ha activado un una elaboración de la palabra o frase contenida en una
sensor), un panel de control, una pantalla, núm eros lista. P or ejem plo, la m ini-especificación del objeto
de teléfono, una llam ada de teléfono, etc. La lista de panel de control d q HogarSeguro podría ser: montado
servicios podría incluir la instalación de la alarma, vigi en la pared; tam año aproximado 23 13 centímetros;
lancia de los sensores, m arcado de teléfono, program a contiene el teclado estándar de 12 teclas y teclas espe
ción del panel de control y lectura de la pantalla (fíjese ciales; contiene una pantalla LC D de la form a m ostra
que los servicios actúan sobre los objetos). D e igual da en el bosquejo (no presentado aquí); toda la
manera, todos los asistentesTFEA desarrollarán una lis interacción del cliente se hace a través de las teclas usa
ta de restricciones (por ejemplo, el sistem a debe tener das para activar o desactivar el sistema; software para
un coste de fabricación de m enos de £80, debe tener proporcionar una directriz de em pleo, recordatorios,
una «interfaz amigable» con el usuario y debe conectar etc., conectado a todos los sensores.
directamente con una línea telefónica estándar) y de cri Cada subequipo presenta entonces sus mini-especi-
terios de rendim iento (por ejemplo, un acontecimiento ficaciones a todos los asistentes TFEA para estudiarlas.
detectado por un sensor debe reconocerse en un segun Se realizan nuevos añadidos, eliminaciones y se sigue
do; se debería im plem entar un esquem a de prioridad de elaborando. En algunos casos, el desarrollo de algunas
acontecimientos). m ini-especificaciones descubrirá nuevos objetos, ser
Cuando em pieza la reunión TFEA, el prim er tem a vicios, restricciones o requisitos de rendim iento que se
de estudio es la necesidad y ju stific ació n del nuevo añadirán a las listas originales. Durante todos los estu-
www.FreeLibros.org
3Este ejemplo (conextensionesy variacionesjse em pleará para ilus 4 Una alternativa puede ser la creación de casos de uso. Ver Sección
trar métodos im portantes de ingeniería del softw are en m uchos de 1 1.2.4para m ás detalles.
los capítulos siguientes. Com o ejercicio, sería útil que realizara su
propia reunión TFEA y desarrollara un conjunto de listas.
185
IN GE NI E RÍ A DEL S OFT W ARE . UN EN F O Q U E P R A C T I C O
dios, el equipo sacará a relu cir aspectos que no podrán

resolverse durante la reunión. Se h ará u n a lista de estas ^C O N SE JoJ^
ideas p ara tratarlas m ás adelante. Todos queremos implementar muchos requisitos
apasionantes, pero debemos ser cuidadosos. Podemos
concretar «requisitos inútiles», o conducirá requisitos
C jc ifa ;
innovadores que conduceno un producto demasiado
0 com enzó es lo pone más im pórtente del trabajo. futurista.
Fíela
E n realidad, el DFC se extiende a todo el proceso de
U na vez que se han com pletado las m ini-especifica- ingeniería [A K A 90]. Sin em bargo, m uchos conceptos
ciones, cada asistente de la T F E A h ace una lista de crite D FC son aplicables al problem a de la com unicación con
rios de validación del producto/sistem a y presenta su lista el cliente a que se enfrenta un ingeniero del software duran—
al equipo. Se crea así una lista de consenso de criterios de te las prim eras fases del análisis de requisitos. Presenta—
validación. Finalm ente, uno o m ás participantes (o algún m os una visión general sólo de estos conceptos (adaptados
tercero) es asignado p ara escribir el b o rrad o r entero de al softw are de com p u tad o ra)en los párrafos siguientes.
especificación con todo lo expuesto en la reunión TFEA. E n las reuniones con el cliente el despliegue defun—
T F E A no e s la p an acea p ara los p ro b lem as que se ció n se e m p le a para d eterm in ar el v a lo r de cada fun—
en cuentran en las p rim eras reuniones de requisitos, pero c ió n r e q u e rid a p a ra el siste m a . E l d e sp lieg u e de
el enfoque de equipo proporciona las ventajas de m uchos inform ación identifica tan to los o b jeto s de datos como
puntos de vista, estudio y refinam iento instantáneo y un lo s a c o n te c im ie n to s que el siste m a d e b e p rod ucir y
paso adelante h acia el desarrollo de u n a especificación. consum ir. E sto s e stá n u n id o s a las fu n cio n es. Final—
m en te, el despliegue de ta reas ex am in a el com porta—
m ien to del sistem a o pro d u cto den tro del contexto de
11.2.3. D e s p lie g u e d e la fu n ció n d e c a lid a d
su entorno. El a n á lisis de v a lo r es llev ad o a cab o para
El despliegue de la fu n c ió n ca lid a d (D F C )e s u n a té c — d e term in ar la p rio rid ad re la tiv a de req u isito s determi—
n ica de g estión de calidad que traduce las n ecesidades n a d a d u ra n te c a d a uno de los tres d e sp lie g u e s men—
del clien te en re q u isito s técnicos del softw are. O rig i— cio n ad o s anteriorm ente.
nalm ente d esarro llad o en Japón y usado p o r p rim era vez
en K obe Shipyard o f M itsubishi H eavy Industries, Ltd.
A prim eros de los años 70, D FC «se concentra en m axi-
m izar la satisfacción del clien te» [ZU L 92], P ara c o n
seguirlo, D F C hace énfasis en entender lo que resulta
El Instituto DFC es una excelentemente de información:
valioso p ara el cliente y después desp leg ar estos v alo — www.qfdi.org
res a lo largo del p roceso de ingeniería. D F C identifica
tres tipos de requisitos [ZU L92]:
El DFC utiliza observacionesy entrevistascon el clien—
te, em plea encuestasy exam ina datos históricos (por ejem—
plo, inform es de problem as) com o datos de base para la
CLAVE actividad de recogida de requisitos. E stos datos se tradu—
DFC define los requisitos orientados a maximizar cen después en una tabla de requisitos — denominada tabla
lo satisfacción del cliente. de opinión del cliente— que se revisa con el cliente. Enton—
ces se usa una variedad de diagram as, m atrices y méto—
R equisitos norm ales. Se declaran objetivos y m etas para un dos de evaluación para extraer los requisitos esperados e
producto o sistema durante las reunionescon el cliente. Si estos intentar obtener requisitos innovadores [BOS91],
requisitos están presentes, el cliente quedará satisfecho. E jem —
plos de requisitos norm ales podrían ser peticiones de tipos de
presentación gráfica, funciones específicas del sistem a y nive— 11.2.4. C a s o s d e u so
les definidos de rendim iento.
U na vez recopilados los requisitos, bien p o r reunio—
R eq u isito s esperados. E sto s requisitos son im p lícito s al nes inform ales, T FE A o D FC , el ingeniero del software
p ro ducto o sistem a y pueden ser tan fu n d am en tales que el (an alista) p u ede c re a r un co n ju n to de escen ario s que
cliente no los declara explícitam ente. Su ausencia sería m oti— identifiquen u n a línea de utilización para el sistem a que
vo de una insatisfacción significativa. E jem plos de requisi—
va a ser construido. Los escenarios, algunas veces lla—
tos esperados son: facilidad de interacción hom bre-m áquina,
buen funcionam iento y fiabilidad general, y facilidad de in s— m ados casos de uso [JA C 92], facilitan una descripción
talación del software. de cóm o el sistem a se usará.
R eq u isito s innovadores.E stas características van m ás allá
de las expectativas del cliente y suelen ser m uy satisfactorias.
Por ej em plo, se pide un softw are procesador de textos con las
www.FreeLibros.org
características estándar. El producto entregado contiene cier—
\ a VE
tas capacidades de diseño de página que resultan m uy válidas Un caso de uso es un escenario que describe cómo
y que no eran esperadas. el software va a ser usado en uno determinada situación.
186
CAPÍTULO 11 C O N C E P T O S Y P R IN C IP IO S DEL A N Á L IS IS
Para crear un caso de uso, el analista debe primero

identificar los diferentes tipos de personas (o dispositi
vos) que utiliza el sistem a o producto. Estos actores \ ave
actualmente representan papeles que la gente (o dispo tos cosos de usos están definidos desde el punto de vista
sitivos) juegan como impulsores del sistema. Definido de un actor. Un actor es un popel que las personas
(usuarios) o dispositivos juegan cuando ¡nteracclonon
más formalmente, un actor es algo que com unica con
con el software.
el sistema o producto y que es externo al sistema en sí
mismo. En general, un caso de uso es, simplemente, un tex
Es importante indicar que un actor y un usuario no to escrito que describe el papel de un actor que interac
son la misma cosa. Un usuario norm al puede ju g ar un túa con el acontecer del sistema.
número de papeles diferentes cuando utiliza un sistema, Volviendo a los requisitos básicos de HogarSeguro
per lo tanto un actor representa una clase de entidades (Sección 11.2.2), podem os identificar tres actores: el
externas (a veces, pero no siempre personas) que lleva propietario (el usuario), sensores (dispositivos vincula
a cabo un papel. Como ejemplo, considerar un operador dos al sistema), y el subsistema de m onitorizacióny res
de una máquina (un usuario) que interactúa con el orde puesta (la estación central que monitoriza HogarSeguro).
nador central para un elem ento de fabricación que con Para los propósitos de este ejemplo, consideremos úni
tiene un núm ero de robots y m áquinas bajo control camente al actor propietario. El propietario interactúa
numérico. Después de una revisión cuidadosa de los con el producto en un núm ero de diferentes caminos:
requisitos, el software del com putador central requiere . introduce una contraseña para p erm itir cualquier
cuatro modelos diferentes (papeles) de interacción: modo interacción
programación, m odo prueba, m odo m onitorización y
• pregunta acerca del estado de una zona de seguridad
modo investigación. Además, se pueden definir cuatro
actores: programador, probador, supervisor e investiga- . pregunta acerca del estado de un sensor
dcr. En algunos casos, el operador de la máquina puede • presiona el botón de alarma en caso de emergencia
realizar todos los papeles. En otras ocasiones, diferen . activa/desactiva el sistema de seguridad
tes personas pueden jugar el papel de cada actor.
to é m m ittiW e k
Una discusión detallada de los casos de usos, Incluyendo
ejemplos, referencias y plontlllos, se presenta en
membersAoUom/acodéum/|Kfere/OnUseCasesJitiit
= JM
Casos de uso Un caso de uso para el sistema de activac/««persigue:
El propietario observa un prototipo del panel de con
Porque la obtención de requisitos es una actividad
trol de HogarSeguro (Fig. 11.2) para determ inar si
de evolución, no todos los actores se identifican duran
te la primera iteración. Es posible identificar actores ini el sistema está preparado para la entrada. Si el sis
tema no está preparado, el propietario debe física
ciales [JAC93] durante la prim era iteración y actores
secundarios cuando m ás se aprende del sistema. Los mente cerrar ventanas/puertas para que se encienda
el indicador de preparado. (El indicador no prepa
actores iniciales interactúan para conseguir funciones
del sistema y derivar el beneficio deseado del sistema. rado implica que el sensor está abierto, por ejemplo,
que la puerta o ventana está abierta.)
Ellos trabaian directa y frecuentemente con el software.
Los actores secundarios existen para dar soporte al sis
tema que los actores iniciales han dado form a con su HOGARSEGURO orí away stay
trabajo. Q ) © ©
Una vez que se han identificado los actores, se pue max test bvpass
den desarrollar los casos de uso. El caso de uso descri (T ) (D [_6_
be la m anera en que los actores interactúan con el instarrt code chime
sistema. Jacobson [JAC93] sugiere un núm ero de pre
0 0
guntas que deberán responderse por el caso de uso: ready
armed power
• ¿Cuáles son las principales tareas o funciones que
serán realizadas por el actor?
Indicadores O o 0 ®
'— -panic
0
i
en inglés
• ¿Cuál es el sistem a de inform ación que el actor
adquiere, produce o cambia?
FIGURA 11.2. Panel de control de H o g a r S eguro.
www.FreeLibros.org
• ¿Qué actor informará al sistema de los cambios en
el entorno externo? 2. El propietario utiliza el teclado para introducir una
• ¿Qué inform aciónnecesita el actor sobre el sistema? contraseña de cuatro dígitos. La contraseña es com-
187
IN GE NI E RÍ A DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
parada con la contraseñaválida alm acenada en el sis indican que ocurrirá 30 segundos después de pulsar la
tema. Si la contraseña es errónea, el panel de control tecla stay o away. Esta inform ación puede añadirse al
em itirá un sonido y se restaurará para incorporar una caso de uso.
nueva entrada. Los casos de uso describen escenarios que serán per
3. El propietario selecciona y pulsa stay o aw ay (ver cibidos de distinta form a por distintos actores. Wyder
Fig. 11.2) para activar el sistema. Stay activa sola [WYD96] indica que la calidad de la función desplegada
mente sensores perim etrales (cuando detectan m ovi puede ser usada para desarrollar un amplio valor de prio
miento interno se desactivan). Aw ay activa todos los ridades para cada caso de uso. Para acabar, los casos de
sensores. uso son evaluados desde el punto de vista de todos los
actores definidos para el sistema. Se asigna un valor de
4. C uando ocurre una activación, una luz de alarm a prioridad a cada caso de uso (por ejemplo, un valor de 1
puede ser observada por el propietario. a 10)para cada acto?. Se calcula una prioridad, indican
C ada caso de uso facilita un escenario sin am bi do la importancia percibida de cada caso de uso.
güedad en la interacción entre el actor y el software. Cuando un m odelo de proceso iterativo es usado por
Esto puede usarse para especificar requisitos de tiem la ingeniería del software orientado a objetos, las prio
po u otras restricciones del escenario. Por ejem plo, en ridades pueden influir en qué funcionalidad del sistema
el caso de uso referido anteriorm ente, los requisitos será entregada primero.
Durante las dos pasadas décadas, se han desarrollado reducir la complejidad. Son necesarias las visiones esen
un gran núm ero de métodos de modelado. Los inves ciales y de im plementación del software para acomo
tigadores han identificado los problem as del análisis y dar las restricciones lógicas impuestas por los requisitos
sus causas y han desarrollado varias notaciones de del procesam iento y las restricciones físicas impuestas
m odelado y sus correspondientes conjuntos de heurís por otros elementos del sistema.
ticas para solucionarlos. Cada m étodo de análisis tie Además de los principios operativos de análisis men
ne su punto de vista. Sin em bargo, todos los métodos cionados anteriorm ente, Davis [DAV95a] sugiere un
de análisis se relacionan por un conjunto de principios conjunto6 de principios directrices para la «ingeniería
operativos: de requisitos»:
1. Debe representarse y entenderse el dominio de infor . Entender el problem a antes de em pezar a crear el
m ación de un problema. modelo de análisis. Hay tendencia a precipitarse en
2. Deben definirse las funciones que debe realizar el busca de una solución, incluso antes de entender el
software. problema. ¡Esto lleva a m enudo a un elegante soft
ware para el problem a equivocado!
3. Debe representarse el comportamiento del software
(como consecuencia de acontecimientos externos). ■ D esarrollar p ro to tip o s que p erm ita n al usuario
entender cómo será la interacción hombre-máquina.
4 . Deben dividirse los modelos que representan infor
Como el concepto de calidad del software se basa a
m ación, función y com portam iento de m anera que
m enudo en la opinión sobre la «amigabilidad» de la
se descubran los detalles por capas (ojerárquica-
interfaz, el desarrollo de prototipos (y la iteración
mente).
que se produce) es altamente recomendable.
5. El proceso de análisis debería ir desde la inform a
• Registrar el origen y la razón de cada requisito. Este
ción esencial hasta el detalle de la implementación.
e s el p rim er paso para establecer un seguimiento
¿Cuáles son los principios hasta el cliente.
subyacentes que guían el . Usarmúltiplesplanteamientos de requisitos. La cons
trabajo de análisis? trucción de modelos de datos, funcionales y de com
Aplicando estos principios, el analista se aproxima portam iento, le proporcionan al ingeniero del
al problem a sistemáticamente. Se exam ina el dominio software tres puntos de vista diferentes. Esto reduce
de inform ación de m anera que pueda entenderse com la probabilidad de que se olvide algo y aumenta la
pletam ente la función. Se emplean modelos para poder probabilidad de reconocer la falta de consistencia.
com unicar de forma com pacta las características de la . D ar prio rid a d a los requisitos. Las fechas ajustadas
función y su comportamiento. Se aplica la partición para de entrega pueden im pedir la im plem entación de
www.FreeLibros.org
5 Lo ideal e s que la evaluación se a realizada por fu n c io n e s indi 6 Aquí se m enciona sólo un pequeño subconjunto de los principios
viduales de,la organización o negocio re p re se n tad a s por un actor. de ingeniería de requisitos de Davis. Para obtener m ás información,
véase [DAV95a],
188
todos los re q u isito s d e l so ftw a re . Si se a p lic a un u n m odelo de datos. E ste dom inio contiene tres v isio
modelo de proceso increm ental (Capítulo 2), se deben nes diferentes de los datos y del control a m ed id a que
identificar los requisitos que se v an a entregar en la se p rocesa cada uno en u n p rogram a de com putadora:
primera entrega. (1 ) contenido de la inform ación y relaciones, (2) flujo
■ Trabajar-para e lim in a r la a m b ig ü e d a d . C om o la de la in fo rm a ció n y (3) e stru ctu ra de la inform ación.
m ayoría de los requisitos están descritos en u n len P ara en te n d er co m p letam en te el do m in io de la in fo r
guaje n atural, abunda la o portunidad de am bigüeda m ación, debería estudiarse cad a u n a de estas visiones.
des. El em p leo de re v isio n e s té c n ic a s form ales es
una m anera de descu b rir y elim in ar la am bigüedad.
Para comenzar a comprender el dominio de información,

la primera pregunto que debe ser realizada es:
«¿Qué información de salida generoró'el sistema?»
Un computador hará lo que le digas, pero ello puede
se . v jr < de lo que tengas en mente.
El contenido de la inform ación representa los o b je
to s in d iv id u ales de d a to s y de co n tro l que co m p o n en
alguna colección m ay o r de inform ación a la que tra n s
Un ingeniero del softw are que se aprenda estos p rin fo rm a el softw are. P or ejem plo, el o b jeto datos cheque
cipios de m em oria es m uy p robable que desarrolle una es u n a co m p o sició n de v a rio s co m p o n en tes de in fo r
especificación del softw are que p roporcione un e x c e m ación im portantes: el nom bre del beneficiario, la can
lente fundam ento p ara el diseño. tidad n eta a pagar, el im porte bruto, deducciones, etc.
P or tan to , el co n ten id o de cheque es d efin id o p o r los
atributos necesarios para crearlo. D e fo rm a sim ilar, el
11.3.1. El d o m in io d e la in fo rm a c ió n contenido de un o b jeto de control denom inado estado
Todas las aplicaciones so ftw are p u ed en d en o m inarse del sistem a po d ría defin irse m ed ian te u n a cad e n a de
colccúx mrcnlcprocesamiento de datos. E s in teresan bits. C ada bit representa un elem ento diferente de in fo r
te que este térm in o c o n te n g a u n a c la v e para n u estro m ació n que in d ica si un d isp o sitiv o en p articular está
entendim iento de los requisitos del softw are. El so ft en línea o fuera de línea.
ware se construye p ara p ro cesar dato s, p ara tra n sfo r L os ob jeto s de d a to s y de co n tro l p u ed en re la c io
mar datos de u n a fo rm a a otra, es decir, para acep tar narse con otros objetos de datos o de control. P or e je m
una entrad a de in fo rm a c ió n , m a n ip u la rla de alg u n a plo, el objeto de datos cheque tiene una o m ás relaciones
manera y p ro d u c ir u n a sa lid a de in fo rm a c ió n . E sta con los objetos em pleado, banco y otros. D urante el an á
declaración fundam ental de o b jetiv o s es cierta, tanto lisis del dom inio de la inform ación, se deberían definir
si construim os so ftw are p o r lo tes p ara u n sistem a de estas relaciones.
nóminas, com o si co n stru im o s so ftw are ded icad o de E l flu jo de la inform ación representa cóm o cam b ian
tiempo real p ara c o n tro la r el flu jo de co m b u stib le de los datos y el control a m edida que se m u even dentro
un motor de autom óvil. de un sistem a. C om o se m u estra en la F igura 11.3, los
o b je to s de e n tra d a se tran sfo rm an p a ra in te rc a m b ia r
inform ación (datos y/o control), hasta que se tran sfo r
m an en inform ación de salida. A lo largo de este cam i
CLAVE
no de transform ación (o cam inos), se puede introducir
El dominio de información de un problema agrupan
inform ación adicional de un alm acén de datos (por ejem
elementos de datos u objetos que contienen números,
plo, un archivo en disco o m em oria interm edia). Las trans
texto, imágenes audio, video o cualquier combinación
de ellos. form aciones que se aplican a los datos son funciones o
subfuncionesque debe realizar un program a. L os datos y
Es im portante recalcar, sin em bargo, que el softw a control que se m ueven entre dos transform aciones (fun
re también procesa sucesos. U n suceso representa algún ciones) definen la interfaz de cada función.
aspecto de control del sistem a y n o es m ás que un dato L a estru ctu ra de la inform ación representa la o rg a
binario (es encendido o apagado, v erdadero o falso, está nización in te rn a de los elem en to s de datos o de c o n
allí o no). P or ejem plo, un sensor de p resió n detecta la trol. ¿H ay que o rg a n iza r los elem en to s de d a to s o de
presión que excede de un valor seguro y envía una señal c o n tro l c o m o u n a ta b la d e d im e n sió n n o c o m o u n a
de alarma al softw are de vigilancia. L a señal de alarm a e stru c tu ra je rá rq u ic a en árbol? D en tro del co n tex to de
es un suceso que con tro la el co m portam iento del siste la estru ctu ra, ¿qué in fo rm ac ió n e stá re lac io n ad a con
ma. Por tanto, los d ato s (núm eros, caracteres, im á g e otra inform ación? ¿E stá contenida toda la inform ación
nes, sonidos, etc.) y el control (acontecim ientos)residen en una sola estructura o se van a utilizar varias? ¿C óm o
www.FreeLibros.org
dentro del dom inio de la inform ación de un problem a. se relaciona la inform ación de u n a estructura con la de
El prim er principio operativo de análisis requiere el otra? E stas y o tras p reg u n ta s se re sp o n d en m ed ian te
examen del dom inio de la info rm ació n y la creación de u n a v a lo ra c ió n d e la e s tru c tu ra d e la in fo rm a c ió n .
189
I N GE NI E RÍ A DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
D e b e ría r e s a lta s e que la e stru c tu ra de dato s, un c o n n a m anera. U n m odelo de com p o rtam ien to crea una repre
cep to afín que se e stu d ia rá m ás ad elan te en este libro, sentación d e los estad o s del softw are y los sucesos que cau
san que cam bie de estado.
se re fie re al d iseñ o e im plem entación de la estru ctu ra
de la inform ación. Los modelos creados durante el análisis de requisi
tos desempeñan unos papeles muy importantes:
11.3.2. M o d e la d o • El m odelo ayuda al analista a entender la informa
ción, la función y el com portam iento del sistema,
Los m odelos se crean p ara entender m ejor la entidad que
haciendo por tanto más fácil y sistem ática la tarea de
se va a construir. C uando la entidad es algo físico (un ed i
análisis de requisitos.
ficio , un avión, u n a m áq u in a), p odem os c o n stru ir un
m odelo idéntico en form a, pero m ás pequeño. Sin em bar • El m odelo se convierte en el punto de m ira para la
go, cuando la entidad que se v a a construir es softw are, revisión y por tanto la clave para determ inar si se ha
nuestro m odelo debe to m ar una fo rm a diferente. D ebe completado, su consistencia y la precisión de la espe
ser capaz de m o d elar la inform ación que tran sfo rm a el cificación.
softw are, las funciones (y subfunciones) que perm iten • El m odelo se convierte en el fundam ento para el
que ocurran las transform aciones y el com portam iento diseño, proporcionando al diseñador una represen
del sistem a cuando ocurren estas transform aciones. tación esencial del software que pueda trasladarse al
El segundo y tercer principios operativos del análi contexto de la implementación.
sis requieren la construcción de m odelos de función y
% ¿ Cómo usar los modelos
com portam iento.
• creados durante el trabajo
* 1 ¿ Qué tipos de modelos de análisis de requisitos?
* debemos crear durante
Los métodos de análisis estudiados en los Capítulos
el análisis de requisitos?
12y 21 son de hecho métodos de modelado. Aunque el
M o d e lo s f u n c io n a le s . El softw are tran sfo rm a la in fo r m étodo de m odelado em pleado es a m enudo cuestión
m ación y, para hacerlo, debe realizar al m enos tres fu n c io de preferencias personales (o de la organización),la acti
nes genéricas: entrada, procevam iento y salida. C uando se
vidad de m odelado es fundamental para un buen traba
crean m odelos fun cio n ales de una ap licació n , el ingeniero
del softw are se co n cen tra en funciones específicas del pro
jo de análisis.
blem a. El m odelo funcional em p ieza con un sencillo m ode
lo a nivel de con tex to (p o r e jem plo, el nom bre del softw are 11.3.3. P artición
que se va a construir). D espués de una serie de iteraciones,
se c o n sig u en m ás y m ás detalles fu n cio n ales, hasta q u e se
A m enudo los problemas son demasiado grandes o com
consigue representar una m inuciosa definición de toda la fun plejos para entenderlos globalmente. Por este motivo,
cionalidad del sistema. tendem os a hacer una partición (dividir) de estos pro
blemas en partes que puedan entenderse fácilmente y
establecer las interacciones entre las partes de manera
que se pueda conseguir la función global. El cuarto prin
cipio operativo del análisis sugiere que se pueden par
tir los dom inios de la inform ación, funcional y de
comportamiento.
CLAVE
Lo descomposición es un proceso que resulta
de la elaboraciónde datos, funciones o comportamientos.
Puede ser realizada horizontal o verticalmente,
En esencia, la p a rtic ió n descompone un problema en

M o d e lo s d e c o m p o rta m ie n to . L a m ayoría del softw are
sus partes constitutivas. Conceptualmente,establecemos
re sp o n d e a los a c o n te c im ie n to s del m u n d o e x te rio r. E sta
característica estím ulo-respuesta form a la base del m odelo una representación jerárquica de la información o de la
del com portam iento. U n program a de c o m p u tad o ra siem pre función y después partim os el elemento de orden supe
e stá en un estad o , un m odo de com p o rtam ien to observable rior (1) exponiendo m ás detalles cada vez al movernos
exterio rm en te (por ejem p lo , e sp eran d o , calculando, im pri verticalmente en la jerarquía o (2) descomponiendo el
m iendo, haciendo cola) que cam bia sólo cuando ocurre algún problem a si nos m ovem os horizontalm ente en la jerar
suceso. P o r ejem p lo , el softw are perm anecerá en el estado
quía. Para ilustrar estos enfoques de partición, reconsi
www.FreeLibros.org
de esp e ra h asta que (1) un reloj interno le indique que ha
pasado cierto intervalo de tiem po, (2) un suceso externo (por deremos el sistema de seguridad H ogarSeguro descrito
ejem plo, un m ovim iento del ratón) provoca una interrupción, en la Sección 11.2.2. La asignación de software para
o (3) un sistem a externo señala al softw are que actúe de algu- H ogarSeguro (obtenido com o consecuencia de las acti
190
CAPITULO 11 C O N C E P T O S Y P R IN C IP IO S DEL A N Á LISIS
vidades de in g e n ie ría del sistem a y de la s reu n io n es en el C apitulo 12) proporcionará una visión m ás profun
TFEA) puede establecerse en los párrafos siguientes: d a de los requisitos del sistema. A m edida que se parte el
El softw are de H o g a rS eg u ro perm ite al propietario con-
sistem a, se obtienen las interfaces entre las funciones. L os
figurarel sistem a de seguridad cuando se instala, vigila todos datos y elem entos de control que se m ueven a través de
los sensores co n ectad o s al sistem a de seguridad e interactúa u n a interfaz deberían restringirse a las entradas necesa
con el propietario a través de un tec lad o y teclas fu n c io n a rias para realizar la función en cuestión y a las salidas
les del panel de control de H ogarSeguro m ostrado en la F ig u requeridas por otras funciones o elem entos del sistema.
ra 11.2.
Durante la instalación, el panel de control de H ogarSegu Sotfware de Hogarseguro

ro se em plea para «program ar» y configurar el sistem a. A cada
sensor se le asigna un núm ero y un tipo, se program a una c o n
traseña para activar y desactivar el sistem a y se introducen el
(los)núm ero(s) de teléfono que se m arcará(n) cuando un sen Configurar Monitorizar lnteractuar
sor detecte un suceso que haga saltar la alarm a. sistema sensores con el usuario
Cuando un sensor detecta un acontecim iento, el softw are Partición horizontal — — — ►

invoca una alarm a sonora asociada al sistem a. D espués de un
retardo especificado por el p ropietario d u ran tela configuración F IG U R A 1 1 .4 . Partición horizontal de una función
del sistema, el softw are m arca u n núm ero de teléfono de una de HogarSeguro.
empresa de seguridad y proporciona inform ación sobre la d irec
ción, inform ando de la naturaleza del acontecim iento d etecta 11.3.4. V isio n es e s e n c ia le s y d e im p lern en tación 7
do. El número se volverá a m arcar cada 20 segundos hasta que
se obtenga la conexión telefónica. U na visión esencial de los requisitos del softw are presenta
las funciones a conseguir y la inform ación a procesar sin
Toda la interacción con H ogarseguro es m anejada por un
ten er en cuenta los detalles de la im plem entación. Por
subsistema de interacción con el usuario que lee la entrada de
información proporcionada a través del teclado y las teclas fun
ejem plo, la visión esencial de la función de H ogarScgu-
cionales, las pantallas que presentan m ensajes y el estado del ro leer el estado del sensor no tiene n ad a que ver con
sistema en la pantalla LCD . La interacción con el teclado tom a la fo rm a físic a de los datos o el tip o de sensor que se
la siguiente form a... em plea. D e hecho, se po d ría argum entar que leer e sta
do sería un nom bre m ás apropiado para esta función, y a
Los requisitos del softw are de H ogarSeguro pueden
que ig n o ra to talm en te los detalles del m ecan ism o de
analizarse p artiendo los dom inios de inform ación, fu n
entrada. Ig u alm en te, un m odelo de datos esen cial del
cional y de c o m p o rtam ien to del pro d u cto . P ara ilu s
elem en to datos núm ero de teléfono (im plicado en la
trarlo, partirem os el dom inio funcional del problem a.
fu n ció n m a rca r núm ero de te lé fo n o ) puede re p re se n
La Figura 11.4 ilu stra u n a d esco m p o sició n horizontal
tarse en esta fase independientem ente de la estru ctu ra
dd software H ogarSeguro. El problem a se parte m edian
de los datos (si es que hay alguna) usada para im ple-
te la representación de las funciones constitutivas del
m en tar el elem ento datos. E nfocando nu estra atención
sofwareH ogarSeguro, m o viéndose h o rizontalm ente en
en la esencia del problem a en las prim eras fases del aná
lajerarquía funcional. En el p rim er nivel de la jerarq u ía
lisis de requisitos, dejam os abiertas nuestras opciones
aparecen tres funciones principales.
p ara especificar los detalles de im plem entación d u ran
te fases p o sterio re s de e sp e cific ac ió n de re q u isito s y
d iseño del softw are.
0 comprender no puede ser sustituido

so? una 3i - i intensa.
Evita la tentación de trasladarte directamente al punta

de vista de implementación, entendiendoque lo esencia
Las subfunciones asociadas con u n a función principal del problema es obvia. El especificar demasiado rápido
deHogarSeguro pueden ex am inarsem ediante la ex posi la implernentación en detalle reduce tus alternativas
ción vertical detallada en lajerarq u ía, tal y com o se ilus e incremento el riesgo.
tra en la Figura 11.5. M oviéndose hacia abajo a lo largo
de un camino, p o r ejem plo la fun ció n sensores de v ig i L a v isió n de im p lem e n ta ció n de los re q u isito s del
lancia, la partición se hace vertical p ara m ostrar m ayores so ftw a re in tro d u ce la m an ife sta ció n e n el m u n d o real
niveles de detalle funcional. El enfoque de partición que de la s fu n c io n e s d e p ro c e sa m ie n to y la s e stru c tu ra s
hemos aplicado a las funciones de H ogarSeguro puede de la inform ación. E n algunos casos, se d esarro lla una
aplicarse tam bién al dom inio de la inform ación y al de re p re sen ta ció n físic a e n la p rim e ra fase del diseñ o del
comportamiento. D e hecho, la partició n del flujo de la so ftw a re . S in e m b a rg o , la m a y o ría d e lo s siste m a s
información y del com portam iento del sistem a (tratados basados en co m p u ta d o ra se especifican de m an era que
www.FreeLibros.org
7 Mucha gente utiliza térm inos visión «lógica» y «física» para referirse
al m ism o concepto.
191
I N GE NI E RÍ A DEL S O F TW A RE . UN EN F O Q U E P R A C T I C O
se acom ode a ciertos detalles de im plem entación. Un propuesta de todos los elementos del sistema. El mode
dispositivo de entrada de inform ación a H ogarSegu lo esencial (de función o datos) es genérico en el senti
ro podría ser un sensor de perím etro (no un perro guar do de que la realización de la función no se indica
dián, un guardia de seguridad o una trampa). El sensor explícitamente.
detecta una entrada no autorizada al detectar una rup
S o tfw a re de HogarSeguro
tu ra en un circu ito electrónico. Las ca racterísticas
generales del sensor deberían tenerse en cuenta com o
parte de la especificación de los requisitos del soft
ware. El an alista debe reco n o cer las re stric cio n es Configurar Monitorizar Interactuar
im puestas por elem entos predefinidos del sistem a (el sistema sensores con el usuario
sensor) y considerar la visión de im plem entación de
la función y de la inform ación cuando tal visión es
apropiada.
Ya hem os comentado anteriormente que el análisis
de los requisitos del software debería concentrarse en
qué es lo que debe hacer el software, en vez de cóm o
se im plem entará el procesam iento. Sin em bargo, la
visión de im plem entaciónno debería interpretarse nece Leer Identificar Activar/ Activar Marcar
el estado el tipo desactivar la alarma el número
sariam ente com o una representación del cóm o. M ás del sensor de suceso el sensor sonora de teléfono
bien, un m odelo de im plementación representa el m odo
actual de operación, es decir, la asignación existente o FIGURA 11.5. Partición vertical de la función de HogarSeguro.
,U^..GREACl0 .M .i> £ fflQ IQ IIP O S

El análisis hay que hacerlo independientemente del para do prototipo desechable. Este prototipo sirve únicamente
digm a de ingeniería del software que se aplique. Sin como una basta dem ostración de los requisitos. Después
embargo, la forma que toma este análisis varía. En algu se desecha y se hace una ingeniería del software con un
nos casos es posible aplicar los principios operativos paradigm a diferente. Un enfoque abierto, denominado
del análisis y obtener un m odelo de software del que se prototipo evolutivo, emplea el prototipo como primera
pueda desarrollar un diseño. En otras situaciones, se rea parte de una actividad de análisis a la que seguirá el dise
lizan recopilaciones de requisitos (por TFEA, DFC u ño y la construcción. El prototipo del software es la pri
otras técnicas de «tormenta de ideas» [JOR89]), se apli m era evolución del sistema terminado.
can los principios del análisis y se construye un m ode
¿ Qué debemos mirar para
•
lo del software a fabricar denom inado prototipo para
que lo valore el cliente y el desarrollador. Finalmente, determinar si un prototipo
hay circunstancias que requieren la construcción de un es o no una alternativa viable?
prototipo al comienzo del análisis, ya que el m odelo es Antes de poder elegir un enfoque abierto o cerrado,
el único m edio a través del cual se pueden obtener efi es necesario determ inar si se puede crear un prototipo
cazmente los requisitos. El m odelo evoluciona después del sistema a construir. Se pueden definir varios facto
hacia la producción del software. res candidatos a la creación de prototipos [BOA84]: área
de aplicación, complejidad, características del clientey
C del proyecto'.
En general, cualquier aplicación que cree panta
los desorrolloaores pueden construir y probar
t e «psefaraones, pero los usuarios son los que
llas visuales dinám icas, interactúe intensam ente con
en reeüdod aceptan o rechazan ¡a operativa actual. el ser humano, o dem ande algoritmos o procesamiento
>l*RMRlÍMr de com binaciones que deban crearse de m anera pro
gresiva, es un buen candidato para la creación de un
prototipo. Sin em b arg o , estas áreas de aplicación
11.4.1. S e le c c ió n d e l e n fo q u e d e c r e a c ió n d e deben po n d erarse con la co m p lejid ad de la aplica
p ro to tip o s ción. Si una aplicación candidata (una con las carac
El paradigm a de creación de prototipos puede ser cerra terísticas reseñadas an terio rm en te) va a requerir el
do o abierto. El enfoque cerrado se denom ina a m enu d esarro llo de decenas de m iles de líneas de código
www.FreeLibros.org
8 Se puede encontrar otro útil estudio sobre los factores candidatos
de «cuando hacer un prototipo» en (DAV95bl.
192
CAPÍTULO 11 C O N C E P T O S Y P R IN C IP IO S DEL A N Á L IS IS
antes de p o d er re a liz a r c u a lq u ie r fu n c ió n d e m o s tra w are existentes. L a com binación de pro to tip o s con la re u ti
lización de com ponentes de pro g ram a s ó lo fu n c io n a rá si se
ble, es m uy probable q u e se a d e m a s ia d o c o m p le ja
d esarro lla un sistem a bibliotecario de m anera que lo s c o m
para crear un p ro to tip o . Si se p u ed e h a c e r una p a r
p o nentes ex isten tes estén c atalo g ad o s y p u e d a n recogerse.
tición a su c o m p le jid a d , p u ed e se r p o sib le c re a r p r o D e b ería resaltarse que se puede usar un p rodiicto so ftw a re
totipos de p o rc io n e s del so ftw are. e x is te n te c o m o p rototipo de un « n u e v o y m e jo ra d o » p ro
Como el clien te debe in te ra c tu a r co n el p ro to tip o ducto co m petitivo. E n cierta m anera, é sta es una fo rm a de
en fases p o ste rio re s, es e se n c ia l que (1) se d e stin e n reutilización en la creación de prototipos softw are.
recursos del clien te a la ev alu ació n y re fin am ie n to del E sp e cific a cio n es fo rm a le s y e n to rn o s p a r a p ro to tip o s.
prototipo, y (2) el clien te sea capaz de to m a r d e c isio D u ran te las pasadas dos décadas, se han desarrollado varios
nes inm ediatas so b re los re q u is ito s . F in a lm e n te , la len g u ajes fo rm ales de especificación y herram ientas c o m o
naturaleza del p royecto de d e sa rro llo te n d rá una gran sustitutos d e las técnicas de especificación con lenguaje natu
influencia en la capacidad de crear un prototipo. ¿Desea ral. H oy en d ía, lo s d e sarro llad o res de estos lenguajes fo r
m ale s e s tá n d e sa rro lla n d o e n to rn o s in teractiv o s que ( 1 )
y es capaz la g e stió n del p ro y e c to de tra b a ja r co n el
p erm itan a l an alista crea r interactivam ente una especifica
método del p ro to tip o ? ¿,T enem os d isp o n ib le s h e rra ción basada en len g u aje de un sistem a o softw are, (2) invo
mientas para la creación de p ro to tip o s? ¿T ienen e x p e quen herram ientas autom áticas que traducen la especificación
riencia los desarro llad o resco n los m étodos de creación b asad a en el lenguaje en código ejecutable, y (3 ) perm itan
de prototipos? A ndriole [A N D 92] su g iere un c o n ju n al cliente usar el código ejecu tab le del prototipo para refinar
to de seis p reguntas (Fig. 11.6) e in d ic a unos c o n ju n lo s requisitos form ales.
tos básicos de respuestas con su co rresp o n d ien te tipo
de prototipo sugerido. Trabajo
preliminar
Prototipo Prototipo adicional
11.4.2. M étodos y h e r r a m i e n t a s p a r a el d e s a rro llo Pregunta desechable evolutivo requerido
d e p ro to tip o s
¿Se entiende el dominio
Para que la creación del prototipo de softw are sea efec de la aplicación? sí sí No
tivo, debe desarrollarse rápidam ente p ara que el clien ¿Se puede modelar
te pueda valorar los resultados y recom endar los cam bios el problema? sí sí No
oportunos. Para p o d er crear prototipos rápidos, hay d is ¿Está el cliente
ponibles tres clases genéricas de m éto d o s y herram ien suficientemente seguro
tas (por ejem plo, [A N D 92], [TAN89]): de los requisitos
básicos del sistema? Sí/No Sí/No No
Técnicas d e C u a r ta G e n e ra c ió n . L a s técn ica s d e cu a r
¿Están establecidos
t a g en era ció n (T 4 G ) c o m p re n d e n una a m p lia g a m a de
los requisitos
lenguajes de co n su lta e inform es de b ases de d a to s, g e n e y son estables? No sí sí
radores de p rogram as y a p lic a c io n e s y de o tro s le n g u a je s
no procedim entales de m uy alto nivel. C o m o las té c n ic a s ¿Hay requisitos
T4G perm iten al ingeniero del softw are g enerar código e je
ambiguos? sí No sí
cutable ráp id am en te, son id e a le s para la c re a c ió n rápida ¿Hay contradicciones
de prototipos. en los requisitos? sí No sí
C om ponentes d e so ftw a re re u tiliz a b le s. O tro enfoque
para crear prototipos ráp id o s es en sam b lar, m á s q u e co n s F IG U R A 1 1 .6 . Selección del enfoque apropiado de creación
truir, el prototipo m ediante un conjunto de com ponentes soft de prototipo.
No hay duda de que el m odo de especificacióntiene m ucho

que ver con la calidad de la solución. Los ingenieros del
software que se han visto forzados a trabajar con especi
ficaciones incom pletas, in consistentes o engañosas han En muchos casos, no es razonable plantearse
êxperimentado la frustracióny confusión que invariable-
menteprovocan. La calidad, la fecha de entregay el alcan Debemos capturar lo esencia de lo que el cliente solicito.
ce del software son las que sufren las consecuencias.
www.FreeLibros.org
I En algunos casos, se pueden construir rapidam ente prototipos extre
madamente complejos usando técnicas de cuarta generacion o com
ponentes software reutilizables
193
INGE NIE RÍA DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
11.5.1. P r in c ip io s d e la e s p e c ific a c ió n L a inform acióncontenida dentro de la especificación debe—

ría e sta r escalonada. Las representaciones deberían revelar
L a especificación, in dependientem ente del m o d o com o capas de informaciónde manera que el lector se pueda mover
la realicem os, puede verse co m o un p roceso de rep re— en el nivel de detalle requerido. La numeración de párrafos y
sentación. L os requisitos se represen tan de m an era que diagramasdcbería indicar el nivel de detalle que se muestra.A
co m o fin últim o lleven al éx ito de la im plem entación veces, merece la pena presentar la misma información con dife
del softw are. A continuación, se p ro p o n en algunos p rin — rentes niveles de abstracción para ayudar a su comprensión.
cipios de especificación adaptados del trabajo de Bal- L o s d ia g ra m a s y o tra sfo rm a s de notación deberían res
z e ry G oldm an [B A L86]: tringirse en núm ero y se r consistentes en su em pleo. Las nota
ciones confusas o inconsistentes, tanto gráficas como
1. Separar la fu ncionalidad de la im plem entación. simbólicas,degradan la comprensión y fomentan errores.
2. D esarro llar un m odelo del com portam iento deseado
L a s representaciones deben p e rm itir revisiones. Segura
d e un sistem a que com prenda datos y las respuestas mente el contenido de una especificacióncambiará. Idealmente,
fu n c io n a le s de u n siste m a a v a rio s e stím u lo s del debería haber herramientas CASE disponibles para actualizar
entorno. todas las representaciones afectadas por cada cambio.
3. E stab lecer el contexto en que o p era el softw are e sp e— L o s in v estig ad o res h a n llev ad o a cab o num erosos
cificando la m an era en que o tro s co m p o n en tes del estu d io s (por ejem plo, [H O L 95], [C U R 85]) sobre los
sistem a interactúan con él. factores hum anos asociados con la especificación. Pare —
4 . D efinir el entorno en que va a operar el sistem a e indi— ce h ab er pocas dudas de que la sim bología y la distri—
car com o «una colección de agentes altam ente en tre b u c ió n a fe c ta n a la c o m p ren sió n . S in em b a rg o , los
lazados reaccionan a estím ulos del entorno (cam bios ingenieros del softw are parecen ten er preferencias indi—
de objetos) producidos p o r esos agentes» [BAL86], v iduales p o r especificaciones sim b ó licas y diagram as
5. C re a r u n m o d elo in tu itiv o en v ez de u n d ise ñ o o específicos. L a fam iliaridad es a m enudo la raíz de las
m odelo de im plem entación. p referen cias de u n a p erso n a, p ero o tro s facto res más
6. R eco n o cer que «la especificación debe ser tolerante tan g ib les ta les co m o la d isp o sic ió n e sp a c ia l, formas
fácilm ente reconocibles y el grad o de form alidad dic—
a u n p o sib le crecim ien to si n o es c o m p le ta » . U na
e s p e c ific a c ió n es sie m p re un m o d e lo — una a b s— tan norm alm ente la elección individual.
tracció n — de alguna situación real (o p revista) que
n o rm alm en te suele ser com pleja. D e ahí que será 11.5.3. La esp ecifica ció n de le s requisitos del
in c o m p le ta y ex istirá a m uchos niveles de detalle. software
7. E stab lecer el contenido y la estru ctu ra de u n a e sp e — L a especificación de los requisitos del softw are se pro—
cificación de m an era que acepte cam bios. duce en la culm inación de la tarea de análisis. La fun—
E sta lista de principios básicos p ro p o rcio n a la base ción y rendim iento asignados al softw are com o parte de
para rep resen tarlo s requisitos del softw are. Sin e m b a r la ingeniería de sistem as se retinan estableciendo una
go, los princip io s deb en traducirse en realidad. E n la co m p leta descripción de la inform ación, u n a descrip —
siguiente sección exam inam os un conjunto de d irectri— ción detallada de la función y del com portam iento, una
ces p ara la creación de un a especificación de requisitos. indicación de los requisitos del rendim iento y restric —
ciones del diseño, criterios de validación apropiados y
11.5.2. R e p r e se n ta c ió n otros datos pertinentes a los requisitos.
Ya h em o s v isto que los re q u isito s del so ftw a re p u e —

d en esp e c ific arse de v arias m an eras. S in em b argo, si
los requisitos se m u estran en pap el o en un m edio e le c —
tro n ic o de re p re se n ta ció n (¡y d eb ería ser casi siem pre
a sí!), m e re c e la p e n a s e g u ir e ste s e n c illo g ru p o de
directrices: Especificación de Reqais ios Software
L a Introducción a la esp ecificació n d e los requisitos

■ I I ¿Cuáles son las directrices
W básicas fundamentales para
del softw areestablece las m etas y objetivos del software,
representar los requisitos?
describiéndolo en el contexto del sistem a basado en com—
putadora. De hecho, la Introducción puede no ser m ás que
E l f o r m a to de la representación y el contenido deberían el alcancedel so ftw areen el d o cum entode planificación.
e sta r relacionados con el p roblem a. Se puede desarrollar un L a D escrip ció n de la inform ación proporciona una
esbozo general del contenido de la especificación de los req u i detallada descripción del problem a que el softw are va
sitos del softw are. Sin em bargo, las form as de representación
a resolver. Se docum entan el contenido de la informa—
c ontenidas en la especificación es probable que varíen con el
ción y sus rela cio n e s, flujo y estructura. Se describen
www.FreeLibros.org
área de aplicación. P or ejem plo. !a especificación de un siste
m a autom ático de fabricación utilizaría diferente sim bología, las in terfaces h ard w are, softw are y h u m an as para los
diag ram as y lenguaje que la esp ecificaciónde un com pilador e le m e n to s externos del siste m a y p ara las funciones
de u n lenguaje de program ación. internas del softw are.
194
C A P Í T U L O 11 C O N C E P T O S Y P R IN C IP IO S DEL A N Á L IS IS
En la D escripción fu n c io n a l se d escriben todas las da ció n . ¿C óm o re c o n o c e m o s el é x ito d e una im p le -

funciones requeridas p ara so lu cio n ar el problem a. Se m entación? ¿Q ué clases de p ru eb as se deben llev ar a
proporciona una d escripción del p roceso de cad a fu n cabo para v alid ar la fu n ció n , el rendim iento y las r e s
dón; se estableceny ju stific a n las restricciones del dise tricciones? Ign o ram o s esta secció n po rq u e para c o m
ño; se establecen las características del rendim iento; y p le ta rla se n ec esita una p rofunda com prensión de los
se incluyen uno o m ás d iagram as p ara rep resentar grá requisitos del softw are, algo que a m enudo no p o se e
ficamente la estructura global del softw are y las in te m os en esta fase. Sin em bargo, la especificación d e los
racciones én trelas funciones softw are y otros elem entos criterios de validación actúa co m o una revisión im p lí
del sistema. L a secció n de la s e sp e c ific acio n es D e s cita de todos los dem ás requisitos. E s esencial in v e rtir
cripción del com portam iento exam in a la operativa del tiem po y p restar atención a esta sección. Finalm ente, la
software com o consecu en cia de acontecim ientos ex ter especificación incluye una B ibliografía y un A p én d ice.
nos y características de control generadas internam ente. E n m uchos casos la E specificación de requisitos del
softw are puede estar acom pañada de u n prototipo e je
cu tab le (que en algunos casos puede sustituir a la e sp e
c ific a c ió n ), un p ro to tip o en p ap el o un M a n u a l de
Cuando desurdes criterhs de validación, responde
usuario prelim in a r. E l M a n u a l de usuario p re lim in a r
a lo siguiente cuestión: «Cómo reconocer si un sistema
presenta al softw are com o una ca ja negra. E s decir, se
es correcto si no lo muevo de m i mesa ?»
pone gran énfasis en las entradas del usuario y las sali
Probablemente la m ás im portante, e iró n icam en te, das (resultados)obtenidas. El m anual puede servir com o
la sección m ás a m enudo igno rad a de u n a e sp e c ific a una valiosa herram ienta para descubrir problem as en la
ción de requisitos del softw are son los C riterios de va li interfaz hom bre-m áquina.
¡ m
La revisión de la E specificación de requisitos del so ft a veces, norm alm ente, corrientem ente, m u ch o , o p rin
ware (y/o prototipo) es llevada a cabo tanto p o r el d esa c ip a lm e n te ), el re v is o r señ a la rá la se n te n c ia p a ra su
rrollador del so ftw are co m o p o r el c lie n te. C om o la clarificación.
especificación form a el fundam ento p ara el diseño y las U n a v ez que se h a co m p le ta d o la re v isió n , se f ir
subsiguientes actividades de la ingeniería del softw are, m a la esp ecificació n de re q u isito s del so ftw a re p o r el
se debería poner extrem o cuidado al realizar la revisión. clie n te y el d esarro llad o r. L a e sp e c ific a c ió n se c o n
v iene en u n « c o n tra to » p a ra el d e sa rro llo del so ftw a
re. L a s p e tic io n e s de c a m b io s e n lo s re q u is ito s u n a
v e z que se h a fin a liz a d o la e sp e c ific a c ió n n o se e li
m in arán , p ero el c lie n te d eb e sa b e r que c a d a c a m b io
a p o sterio ri sig n ific a u n a a m p lia c ió n d e l ám b ito del
so ftw a re , y p o r ta n to p u e d e n a u m e n ta r lo s c o s te s y
R equisitosS oftw are p ro lo n g a r los p la zo s de la p lan ifica ció n tem p o ral del
Revisión de la Especificación proyecto.
Incluso con los m ejores procedim ientos de revisión,
Inicialm ente la re v isió n se lle v a a c a b o a n iv el siem pre persisten algunos problem as com unes de e sp e
macroscópico. A este niv el, los re v iso re s intentan ase cificación. La especificación es difícil de «probar» de
gurarse de que la e s p e c ific a c ió n se a c o m p le ta , c o n m an era significativa, p o r lo que pueden p asar inadver
sistente y c o rre c ta c u a n d o la in fo rm a c ió n g e n e ra l, tid as c ie rta s in c o n siste n cia s y om isiones. D u ran te la
funcional y de los d o m in io s del c o m p o rtam ien to son revisión, se pueden reco m en d ar cam bios a la especifi
considerados. A sim ism o, u n a exploración com pleta de cació n . P u e d e se r e x tre m a d a m en te d ifíc il v a lo ra r el
cada uno de esto s d o m in io s, la re v isió n p ro fu n d iz a en im pacto global de un cam bio; es decir, ¿cóm o afecta el
el detalle, exam inando n o solo las descripciones super cam bio en una fu nción a los re q u isito s de las dem ás?
ficiales, sino la v ía en la que los re q u isito s son e x p re Los m odernos entornos de ingeniería del softw are (C apí
sados. Por ejem plo, cuando u n a especificación contiene tu lo 3 1) incorporan herram ientas C A S E desarrolladas
un «térm inovago» (por ejem p lo , algo, algunas veces, para ayudar a reso lv er estos problem as.
i
SU
_________________________________________ M
El análisis de requisitos es la p rim era fase técn ica del En m uchos casos, no es posible especificar completa
p roceso de ingeniería del softw are. E n este pun to se refi m ente un problem a en una etapa tan tem prana. La crea
n a la d eclaración general del ám bito del softw are en una ción de p ro to tip o s ofrece un en fo q u e altern ativ o que
e sp e c ific ac ió n co n c re ta que se co n v ierte en el fu n d a produce un m odelo ejecu tab le del softw are en el que
m en to de to d as las activ id ad es sig u ien tes de la in g e se p u e d en re fin a r lo s req uisitos. Se n e ce sita n herra
n iería del softw are. m ientas especiales para p o der realizar adecuadamente
El a n á lisis d eb e e n fo c a rse en los d o m in io s de la la creación de prototipos.
inform ación, funcional y de c o m p o rtam ien to del p ro C om o resultado del análisis, se desarrolla la Especi
blem a. Para entender m ejo r lo que se requiere, se crean fic a c ió n de requisitos d e l software. L a revisión es esen
m odelos, los p roblem as sufren u n a p artició n y se d e sa cial p a ra a se g u ra rse que el c lie n te y el desarrollador
rrollan rep resentaciones que m u estran la esen cia de los tie n e n el m ism o c o n c e p to del sistem a. D esgraciada
re q u isito s y p o sterio rm e n te los d e ta lle s de la im ple- m ente, incluso con los m ejores m étodos, la cuestión es
m entación. que el problem a sigue cam biando.
M EK EREr S I& S
[AKA90] Akao, Y. (de.), Quality Function Deployment :lnte- [HOL95] Holtzblatt, K., y E. Carmel (eds.), «Requirements
grating Customer Requirements in Product Design (tra Gathering: The Human Factor», un resultado especialde
ducido por G. Mazur), Productivity Press, Cambridge MA, CACM, vol. 38, n.° 5, Mayo 1995.
1990
[JAC92] Jacobson, I., Object-Oriented Software Engineering,
[BAL86] Balzer,R., y N. Goodman, «Principies of Good Spe- Addison-Wesley, 1992.
cification and their Implications for Specification Lan-
[JOR89] Jordan, P.W. et al., «Software Storming: Combining
guages», in Software Specification Techniques (Gehani
Rapid Prototyping and Knowledge Engineering», IEEE
and McGetrick, eds.), Addison-Wesley, 1986,pp. 25-39.
Computer, vol. 22,n.° 5, Mayo 1989, pp. 39-50.
[BOA84] Boar, B., Application Prototyping, Wiley-Inters-
cience, 1984. [REI94] Reifer, D.J., «Requirements Engineering», in Ency-
clopedia o f Software Engineering (J.J Marciniak, editor),
[BOS91] Bossert, J.L., Quality Function Deployment: A Prac- Wiley, 1994,pp. 1043-1054.
titioner's Approach, ASQC Press, 1991.
[TAN89] Tanik, M.M., y R.T. Yeh (eds.), «Rapid Prototyping
[CUR85] Curtis, B., Human Factors in Software Develop in Software Development» (resultado especial), ÍEEE
ment, IEEE Computer Society Press, 1985. Computer, vol. 22, n.° 5, Mayo 1989.
[DAV93] Davis, A., SoftM'are requirements: Objetes, Func- [WYD96] Wyder, T., «Capturing Requirements with use-
tions and Stutes, Prentice-Hall, 1993. cases», Software Development, Febrero 1996,pp. 37-40.
[DAV95a] Davis, A., 201 Principies o f Software Develop [ZAH90] Zahniser, R.A., «Building Software in Groups»,
ment, McGraw-Hill, 1995. A m erican Programmer, vol. 3, n.1" 7/8, Julio-Agosto
[DAV95b] Davis, A., «Software Prototyping», in Advances 1990.
in Computers, vol. 40, Academic Press, 1995. [ZUL92] Zultner,R., «Quality Function Deployment for Soft
[GAU89] Gause, D.C., y G. M. Weinberg, Exploring Requi ware: Satisfying Customers», Am erican Programmer,
rements: Quality Befare Design, Dorset House, 1989. Febrero 1992,pp. 28-41.
•0
11.1. El análisis de requisitos del software es indudablemente pueden llevar a cabo las tareas de análisis de manera que se
la fase de comunicación más intensa del proceso de ingenie- minimicen estas repercusiones políticas?
rí a del software. ¿Por qué suele romperse frecuentemente este
enlace de comunicación? 11.3. Estudie su percepción ideal de la formación y currícu
lum de un analista de sistemas.
11.2. Suele haber serias repercusiones políticas cuando
comienza el análisis de requisitos del software (y/o análisis 11.4. A lo largo de todo el capítulo nos referimos al «clien
www.FreeLibros.org
de un sistema). Por ejemplo, lo s trabajadores pueden creer te». Describa el «cliente» desde el punto de vista de los
que la seguridad de su trabajo puede verse amenazada por un desarrolladores de sistemas de información, de los cons
nuevo sistema automático. ¿Qué origina tales problemas? ¿Se tructores de productos basados en com putadora y de los
196
C A P I T U L O 11 C O N C E P T O S Y P R IN C IP IO S DEL A N Á LISIS
constructores de sistemas. ¡Tenga cuidado, el problema pue el contenido y cualquier estructura de la información que le
de ser más complejo de lo que parece! parezca relevante.
11.5. Desarrolle un «kit» de técnicas de especificación de apli 11.9. Llaga una partición del dominio funcional de H ogarSe
cación (TFEA). El kit debería incluir un conjunto de directri guro. Inicialmente haga una partición horizontal; después haga
ces para llevar a cabo una reunión TFEA, materiales para la partición vertical.
facilitar la creación de listas y otros elementos que pudieran 11.10. Construya la representación esencial y de implemen-
ayudaren la definición de requisitos. tación del sistema HogarSeguro.
11.11. Construya un prototipo en papel (o uno real) deHogar-
'11.6. Su profesor dividirá la clase en grupos de cuatro a seis
Seguro. Asegúrese de mostrar la interacción del propietario y
estudiantes. La mitad del grupo hará el papel del departamento
el funcionamiento global del sistema.
íde marketing y la otra mitad el de la ingeniería del software.
1Slírabajo consiste en definir los requisitos del sistema de segu 11.12. Intente identificar componentes software de H ogar-
ridad HogarSeguro descrito en este capítulo. Celebre una reu Seguro que podrían ser «reutilizables» en otros productos o
nión TFEA usando las directrices estudiadas en el capítulo. sistemas. Intente clasificar esos componentes.
11.13. Desarrolle una especificación escrita de HogarSegu-
*11.7. ¿Se puede decir que un Manual preliminar de usuario m usando el esquema propuesto en la página web SEPA. (Nota:
es una forma de prototipo? Razone su respuesta. Su profesor le sugerirá qué secciones com pletar en este
11.8. Analice el dominio de información de HogarSeguro. momento.) Asegúrese de aplicar las cuestiones descritas en la
¡Represente (usando la notación que crea apropiada) el flujo, revisión de la especificación.
Los libros que indicamos sobre la ingeniería de requisitos per (Applying Use-cases: A P ractica 1 G uide, Addison-Wesíey,
miten una buena base para el estudio de los conceptos y prin 1998), y Texel y W illiams (U se-C a se s C o m b in e d W ith
cipios básicos del análisis. Thayer y Dorfman (Software B o o ch /d M T /U M L ,P re n tic e-lla \\, 1997) facilitan una guía
RequirementsEngineering, 2.a ed., IEEE Computer Society detallada y muchos ejemplos Utiles.
Press, 1997)presentan una amplía antología sobre el tema. El análisis del dominio de la información es un principio
Giabam y Graham (Requirem ents E ngineering and R a p id fundamental del análisis de requisitos. Los libros de Matti-
Development, Addison-Wesley, 1989,destaca el desarrollo rápi son (The O bject-O riented E nterprise, McGraw-Hill, 1993),
doy el uso de métodos orientadosa objetos en su planteamiento y Modell (D ataAnalysis, D ata M odelling and Classification,
Sobre la ingeniería de requisitos, mientras MacCauley (Requi- McGraw-Hill, 1992) cubre distintos aspectos de este impor
rements Engineering, Springer Verlag, 1996) presenta un bre tante tema.
ve tratado académico sobre el tema. Un reciente libro de Harrison (Prototyping and Software
En los últimos años, la literatura hacia énfasis en el D evelopm ent, Springer Verlag, 1999) facilita una moderna
modelo de requisitos y en los métodos de especificación, perspectiva sobre el prototipado del software. Dos libros de
pero hoy se hace igual énfasis en los métodos eficientes C onnelly Shafer (Stru ctu red R a p id P rototyping, Prentice-
para la obtención de requisitos del software. Wood y Sil- Hall, 1989) y (Object-O riented R a p id Prototyping, Yourdon
ver (JointApplication D evelopment, segunda edición, Wiley, Press, 1994) muestra como esta importante técnica de análi
1995) han escrito un tratado definitivo para el desarrollo sis puede ser utilizada tanto para entornos convencionales
deaplicacionesenlazadas. Cohén y Cohén (Quality Function como para entornos orientados a objetos.
Deployment, Addison-Wesley, 1995), Terninko ( S te p -B y- Otros libros como los de Pomberger et al. (O bjectO rien-
StepOFD: C ustom er-D riven P roduct D esign, Saint Lucie tation and Prototyping in Software Engineering, Prentice-
Press, 1997), Gause y W einberg [GAU89] y Zahniser Hall, 1996) y Krief et al. (Prototyping W ith O bjects,
ÍZ A H 90] estudia los mecanismos para tener reuniones efec Prentice-Hall, 1996) examina el prototipado desde la pers
tivas, métodos de brainstorm ing y obtención de requisitos pectiva de la orientación a objetos. La IE E E Proceedings o f
cpe pueden usarse para clarificar resultados y una variedad International W orkshop on R apid System Prototyping (publi
de otras necesidades. Los casos de uso configuran una par cado el pasado año) presenta una visión actual en esta área.
te importante del análisis de requisitos orientado a objetos, Una amplía variedad de fuentes de información sobre el
¡}ue pueden usarse de forma independiente de la imple- análisis de requisitos y otros temas relacionados están dispo
toentación tecnológica que se seleccione. Rosenburgy Scott nibles en internet. Una lista actualizada de páginas web que
(Use-CaseDriven Ohject. M odelling w ith I M I.:. 1 P racti- son significativas sobre los conceptos y métodos de análisis
CÚApproach, Addison-W esley, 1999), Schneider et al. se encuentran en http://www.pressman5.com
www.FreeLibros.org
CAPÍTULO
12 MODELADO DEL ANÁLISIS
N un nivel técnico, la ingeniería del software empieza con una serie de tareas de m ode
E lado que llevan a una especificación com pleta de los requisitos y a una representación
del diseño general del software a construir. El modelo de análisis, realm ente un conjunto
de modelos, es la prim era representación técnica de un sistema. Con los años se han propuesto
m uchos métodos para el modelado del análisis. Sin embargo, ahora dos tendencias dom inan el
panoram a del m odelado del análisis. El primero, análisis estructurado, es un m étodo de m ode
lado clásico y se describe en este capítulo. El otro enfoque, análisis orientado a objetos, se estu
dia con detalle en el Capítulo 21. En la Sección 12.8 se presenta una breve visión general de
otros métodos de análisis comúnmente usados.
El análisis estructurado es una actividad de construcción de modelos. M ediante una nota
ción que satisfaga los principios de análisis operacional estudiada en el Capítulo 11, creamos
modelos que representan el contenido y flujo de la inform ación (datos y control); partimos el
sistema funcionalmente, y según los distintos comportamientos establecem os la esencia de lo
que se debe construir. El análisis estructurado no es un método sencillo aplicado siem pre de la
m ism a forma por todos los que lo usan. M ás bien, es una amalgama que ha evolucionado duran
te los últim os 30 años.
En su principal libro sobre este tema, Tom DeMarco [DEM79] describe el análisis estruc
turado de la siguiente forma:
VISTAZO RAPIDO
¿Qué es? La palabra escrita es un vehícu vista. El análisis representa los requi especificación incorporada en el mode
lo maravilloso para la comunicación, sitos en tres «dimensiones», por esa lo es creada y luego validada, tanto por
pero no es necesariamente el mejor razón, se incrementa la probabilidad de el ingenierodel software, como por los
camino para representar los requisitos encontrar errores, descubrir inconsis clientes/usuarios.
del software. El análisis utiliza mía com tencias y detectar omisiones. ¿Cuál es el producto obtenido? Las des
binación de texto y de diagramas, para ¿C son los pasos? Los requisitos de cripciones de los objetos de datos, los
representar los requisitos de datos, fun diagramas entidad-relación, los dia
datos, funciones y comportamientos
ciones y comportamientos, que es rela son modelados utilizando diferentes gramas de flujo de datos, los diagra
tivamente fácil de entender y, más mas de transición de estados, las
importante aún, sencillo para revisar su diagramas, El modelado de datos defi
especificaciones del proceso y las
corrección, completitud y consistencia. ne objetos de datos, atributos y rela
especificaciones de control son crea
ciones. El modelado de funciones
¿Quién lo hace? El ingenierodel software indica como ios datos son transforma da s como resultado de las actividades
(a veces llamado analista) construye el del análisis.
dos dentro del sistema. El modelado
modelo utilizando los requisitos defini del comportamiento representa el ¿Cómo puedo estar seguro de que lo he
dos por el cliente, impacto de los sucesos. Se crean unos hecho correctamente?E1 resultado del
i ¿Por qué es importante? Para validar los modelos preliminares que son anali modelado del análisis debe ser revisa
requisitos del software necesitamos zados y refinados para valorar su cla do para verificar su corrección, comple
f examinarlos desde diferentespuntos de ridad. completitud y consistencia. Una titud y consistencia.
Observando los problemas y fallos reconocidos para la fase de análisis, se puede sugerir que necesita
mos añadir los siguientes objetivos a la fase de análisis.
• Los productos del análisis han de ser de mantenimiento muy fácil. Esto concierne concretamente al
documento final [Especificación de Requisitos del Software],
• Se deben tratar los problemas de gran tamaño mediante algún método efectivo de partición. La espe
cificación mediante novelas victorianas ya no sirve.
• Siempre que sea posible, se deben utilizar gráficos.
• Tenemos que diferenciarlas consideraciones lógicas [esenciales] y las físicas [de implernentación]...
Como mínimo, necesitamos ....
www.FreeLibros.org
■Algo que nos ayude a hacer una partición de los requisitos y a documentar esas divisiones antes de
especificar ...
• Algún método de seguimiento y evaluación de interfaces ...
■Nuevas herramientas para describir la lógica y la táctica, algo mejores que descripciones narrativas ...
199
Es m uy probable que n in g ú n o tro m étodo de ingeniería del softw are h ay a generado tanto interés, h ay a sido pro
bado (y a v eces rechazado y vuelto a probar) p o r tan ta gente, criticado y h ay a provocado tan ta controversia. Pero
el m étodo h a subsistido y h a alcan zad o u n im portante seguim iento d en tro de la com unidad de la ingeniería del
softw are.
A l igual que m uchas de las contribuciones im portan E l té rm in o «análisis e stru c tu ra d o » originalm ente
tes a la ingeniería del softw are, el análisis estructurado a cu ñ ad o p o r D o u g las R oss, fu e p o p u la riz a d o por
no fue introducido en un solo artículo o libro clave que D e M arc o [D E M 79]. E n su lib ro so b re e sta m ateria,
in clu y e ra un tra ta m ie n to co m p leto del tem a. L o s p ri D eM arco p resentó y d en o m in ó los sím bolos gráficos y
m eros trabajos sobre m odelos de análisis aparecieron a los m odelos que los incorporan. E n los años siguientes,
finales de los 60 y principios de los 70, pero la p rim e P ag e-Jo n es [PA G 80], G ane y S arso n [G A N 82] y
ra ap arició n del en fo q u e de an álisis e stru ctu rad o fue m uchos otros propusieron variaciones del enfoque del
com o com plem ento de otro tem a im p o rtan te— el « d ise análisis estructurado. E n todos los casos, el m étodo se
ño estructurado» — . L os investigadores (por ejem plo, centraba en aplicaciones de sistem as de inform ación y
[ST E 74], [Y O U 78], necesitab an u na n o tació n gráfica no proporcionaba una notación adecuada p ara los aspec
p ara rep resen tar los datos y los p rocesos que los tra n s tos de co n tro l y de co m p o rtam ien to de los problem as
form an. E sos p rocesos quedarían finalm ente estableci de ingeniería de tiem po real.
dos en u n a arquitectura de diseño. A m ediados de los 80, las «am pliaciones» para tiem
po real fueron introducidas p o r W ard y M ellor [WAR85]
y, m ás tarde, p o r H atley y P irbhai [HAT87]. C on esas
am pliaciones, se co n sig u ió un m étodo de análisis más
8 p B existan problemas.
robusto que p o día ser aplicado de form a efectiva a pro
•, p s ® » ss esperar que vengan y pensa
blem as de ingeniería. En la actualidad, se está inten
problemas es un problema.
tan d o desarrollar una notación consistente [BRU88] y
fP M N jlite StA&s
se están publicando tratam ientos m odernos que permi
tan acom odar el uso de herram ientas C A SE [YOU89],
12.2. LOS ELEMENTOS DELMQfíEIií!LJRE.AJSÁJLJSISL.—

E l m o d elo de an álisis debe lo g rar tres o b jetiv o s p r i
m arios: (1) d escribir lo que requiere el cliente, (2) esta
b le c e r u n a b a se p a ra la c re a c ió n de u n d is e ñ o d e
so ftw are, y (3) d e fin ir un co n ju n to de re q u isito s que
se pu ed a v alid ar u n a vez que se co n stru y e el so ftw a
re. P ara lo g ra r esto s o b jetiv o s, el m o d elo de análisis
ex traíd o d u ran te el an álisis e stru ctu rad o to m a la fo r
m a ilu stra d a en la F ig u ra 12.1.
E n el cen tro del m o d elo se en c u e n tra el dicciona
rio de datos —un alm acén que co n tien e d efin icio n es
de to d o s los o b jeto s de d ato s c o n su m id o s y p ro d u c i
dos p o r el softw are — . T res d iag ram as d iferen tes r o
dean el núcleo. E l diagrama de entidad-relación (D ER)
rep re se n ta las re la c io n e s entre los o b jeto s de datos. El
D E R es la n otación que se u sa p ara re a liz a r la a c tiv i
d ad de m odelado de datos. L os atributos de c a d a o b je
to de d a to s se ñ a la d o s e n el D E R se p u e d e d e sc rib ir
m ed ian te u n a d escripción de objetos de datos.
El diagram a de flu jo de datos ( DFD) sirv e p a ra
F IG U R fl 12.1. La estructura del m odelo de análisis.
www.FreeLibros.org
d o s p ro p ó sito s: ( 1 ) p ro p o rc io n a r u n a in d ic a c ió n d e
có m o se tra n sfo rm a n los d ato s a m e d id a que se av an su b fu n c io n e s) que tra n sfo rm a n el flu jo de datos. El
z a en el s is te m a , y (2) re p re s e n ta r las fu n c io n e s (y D F D p ro p o rc io n a in fo rm a c ió n a d ic io n a l q u e se usa
200
C A P I T U L O 12 M O D E L A D O DEL ANÁ LIS IS
durante el an álisis del d o m in io de in fo rm a ció n y s ir siciones de estad o a estado. El D T E sirve co m o la base
ve com o b ase p a ra el m o d e la d o de fu n ció n . E n u n a del m odelado de com portam iento. D entro de la especi
especificaciónde proceso ( EP) se en c u e n tra u n a d e s ficación de control ( E C ) se encuentra m ás inform ación
cripción de c a d a fu n c ió n p re s e n ta d a en el DFD. sobre los aspectos de control del softw are.
El diagrama de transición de estados (D TE) indica El m o d elo de an álisis aco m p añ a a cad a d iagram a,
cómo se co m p o rta el sistem a co m o c o n se c u e n c ia de especificación y descripción, y al diccionario señalado
sucesos externos. Para log rar e sto , el D T E representa en la Figura 12.1. U n estudio m ás detallado de estos ele
los diferentes m odos de com portam iento (llam ados esta m entos del m odelo de an álisis se presenta en las sec
dos) del sistem a y la m an era en que se h acen las tra n ciones siguientes.
E1 m odelado de datos responde a u n a serie de p re g u n Objetos: Atributos: Relaciones:

tas específicas im portantes p ara cualq u ier aplicación de
Nombre
procesamiento de datos. ¿Cuáles son los objetos de datos
Dirección
primarios que va a p ro cesar el sistem a? ¿Cuál es la co m
Edad
posición de cada o b jeto de d ato s y qué atributos d e s
Licencia
cribe el objeto? ¿D ónde residen actualm ente los objetos?
de conducir
¿Cuál es la relació n entre los objetos y los procesos que
Número
los transform an?
posee
Fabricante
¿A qué preguntas Modelo
§ da respuesta el modelo
de datos?
Número
— ► de bastidor
Tipo de
carrocería
Para responder estas preguntas, los m étodos de m ode Color
lado de datos h acen uso del d iagram a de en tidad-rela
ción (DER). El D ER, descrito con detalle posteriorm ente FIGURA 12.2. Objetos de datos, atributos y relaciones.
en esta sección, p erm ite que un ingeniero del softw are
identifique objetos de datos y sus relaciones m ediante 12.3.1. O b je to s d e d a to s , a t r ib u to s y r e la c io n e s
una notación gráfica. E n el contexto del análisis estruc El m odelo de datos se com pone de tres piezas de in fo r
turado, el D E R d efin e todos los datos que se introdu m ación interrelacio n ad as: el o b jeto de datos, los atri
cen, se alm acenan, se tran sfo rm an y se pro ducen dentro butos que describen el objeto de datos y la relación que
de una aplicación. conecta objetos de datos entre sí.
O bjetos de datos. U n objeto de datos es una repre
sentación de cualquier com posición de inform ación co m
puesta que deba com prenderel software. Por composición
de inform ación, entendem os to d o aquello que tiene un
! aproximoáón ER está en I
núm ero de propiedades o atributos diferentes. P or tanto,
(fe describir untídades de negocio del mundo real y
el «ancho» (un valor sen cillo jn o sería un objeto de datos
sus relaciones.
M artin JfM eU . -
válid o , p ero las «d im en sio n es» (in co rp o ran d o altura,
ancho y profundidad) se po d ría definir com o objeto.
El diag ram a e n tid a d -re lac ió n se ce n tra solo en los

datos (y p o r consiguiente satisface el p rim er principio CLAVE
operacional de a n á lisis), re p re se n ta n d o una «red de Un objeto de datos es una representación
datos» que existe para un sistem a dado. El D E R es espe de cualquier configuraciónde información
cíficamente Útil p ara aplicaciones en d o n de los datos y que es procesada por el software.
las relaciones que g o biernan los datos son com plejos.
A diferencia del diag ram a de flujo de d atos (estudiado U n o b jeto de d a to s p u ede ser u n a e n tid ad e x tern a
en la Sección 12.4 y usado p a ra re p re se n tar co m o se (por ejem p lo , c u a lq u ier co sa que pro d u ce o consum e
www.FreeLibros.org
transform an los d ato s), el m o d elad o de datos estudia inform ación), una cosa (por ejem plo, un inform e o una
los datos in d ep en d ien tem en te del p ro c e sa m ien to que pantalla), una ocurrencia (por ejem plo, una llam ada tele
los transform a. fónica) o suceso (por ejem plo, una alarm a), un puesto
IN GE NIE RI A DEL SOF TW ARE . UN E N F O Q U E P R A C T I C O
(por ejemplo, un vendedor), una unidad de la organiza com o un identificador -es decir, el atributo identifi-
ción (por ej emplo, departamento de contabilidad), o una cador supone una «clave» cuando queram os encontrar
estructura (por ejemplo, un archivo). Por ejemplo, una una instancia del objeto de dato— . En algunos casos,
persona o un coche (Fig. 12.2) se pueden ver com o un los valores para los identificadores son únicos, aun
objeto de datos en el sentido en que cualquiera se pue que esto no es un requisito. H aciendo referencia al
de definir según un conjunto de atributos. La descrip o bjeto de datos coch e, un id en tificad o r razonable
ción de objeto de datos incorpora el objeto de datos y podría ser el núm ero de bastidor.
todos sus atributos.
los atributos definen un objeto de datos,

Referencia Web describen sus característicos, y en algunas ocasiones,
Información útil sobre el modelo de datos puede establecen referencias o otros objetos.
encontrarse en www.datamodel.org
El conjunto de atributos apropiado para un objeto de
Los objetos de datos se relacionan con otros. Por datos dado se determ ina m ediante el entendimiento del
ejemplo, persona puede p oseer coche, donde la rela contexto del problema. Los atributos para coche des
ción p o see r implica una «conexión» específica entre critos anteriormente podrían servir para una aplicación
persona y coche. Las relaciones siempre se definen por que usara un Departam ento de Vehículos de Motor, pero
el contexto del problema que se está analizando. estos atributos serían menos útiles para una compañía
Un objeto de datos solamente encapsula datos —no de automóviles que necesite fabricar software de con
hay referencia dentro de un objeto de datos a operacio trol. En este últim o caso, los atributos de coche podrían
nes que actúan en el dato'— . Por consiguiente, el obje incluir tam bién núm ero de bastidor, tipo de carrocería,
to de datos se puede representar com o una tabla de la y color, pero m uchos atributos adicionales (Por ejem
plo: código interior, tipo de dirección, selector de equi
forma en que se m uestra en la Figura 12.3. Los enca
bezam ientos de la tabla reflejan atributos del objeto. En pam iento interior, tipo de transm isión) se tendrían que
este caso, se define un coche en térm inos de fabrican añadir para que coche sea un objeto significativo en el
te, modelo, núm ero de bastidor, tipo de carrocería, color contexto del control de fabricación.
y propietario. El cuerpo de la tabla representa ocurren
cias del objeto de datos. Por ejemplo, un Honda CRV
es una ocurrencia del objeto de datos coche.
CLAVE
A trib u to s A ta un o b jeto d e d a to s a otro, las relaciones Indican la mañero en que los objetos
¡d e n tlflc a tlv o s e n e s te caso, el p ro p ie ta rio de datos están «conectados» entre sí.
/ a______ ■ \ X
A trib u to s A trib u to s
Id e n tlflc a d o r d e sc rip tiv o s d e re fe re n c ia Relaciones. Los objetos de datos se conectan entre
sí de muchas form as diferentes. Considere dos objetos
F a b ri N a de T ip o d e de datos, libro y librería. Estos obj etos se pueden repre
c a n te M o d e lo B a stid o r c a rro c e ría C o lo r P ro p ie ta rio sentar mediante la notación simple señalada en la Figu
Lexus LS 40 0 A B 1 2 3 ... S edan B la n c o RSP ra 12.4a. Se establece una conexión entre libro y librería
O c u r r e n c ia H o n d a CRV X456...
Todo- porque los dos objetos se relacionan. Pero, ¿qué son
R o jo CCD
te rre n o relaciones? Para determ inar la respuesta, debemos com
BMW 7 5 0 IL X Z 7 6 5 ... C oupe B la n c o LJL
prender el papel de libro y librería dentro del contexto
F ord T a u ru s Q 1 2 A 4 5 .. S edan A zu l BLF
del software que se va construir. Podem os definir un
F IG U R A 1 2 .3 . Representación tabular del objeto de datos. conjunto de parej as objeto-relación que definen las rela
ciones relevantes. Por ejemplo,
A tributos. Los atributos definen las propiedades • una librería pide libros
de un objeto de datos y tom an una de las tres caracte • una librería m uestra libros
rísticas diferentes. Se pueden usar para ( l ) nom brar
una ocurrencia del objeto de datos, (2) describir la ocu • una librería almacena libros
rrencia, o (3 ) hacer referencias a otra ocurrencia en • una librería vende libros
otra tabla. A dem ás, uno o varios atributos se definen • una librería devuelve libros
www.FreeLibros.org
1 Esta distinción separa el objeto de datos de la ciase u objeto defini
dos como parte del paradigm a orientado a objetos que se estudia en
la Parte Cuarta de este libro.
202
C A P Í T U L O 12 M O D E L A D O DEL ANÁ LIS IS
• U no a uno (1:1)— U na ocurrencia [de un obj eto] «A »

Libro Librería se puede relacionar a una y sólo una ocurrencia del
o b jeto «B », y una ocurrencia de «B» se puede re la
(a) Una conexión básica entre objetos cionar sólo con una ocurrencia de «A».
Pide • U no a m uchos (1 :N)— U na ocurrencia del objeto «A»
se puede relacionar a u n a o m uchas ocurrencias del
objeto «B», pero una de «B» se puede relacionar sólo
a una o cu rren cia de «A ». P o r ejem plo, una m adre
puede ten er m uchos h ijo s, pero un h ijo sólo puede
ten er una m adre.
(b) Relaciones entre objetos • M uchos a m uchos (M:N)— Una ocurrencia del objeto
«A » puede relacionarse con una o m ás ocurrencias
FIGURA 12.4. Relaciones. de «B », m ientras que una de «B» se puede relacio
n ar con una o m ás de «A». P or ejem plo, un tío puede
Las relacionespide, muestra, alm acena y devuelve defi te n e r m u c h o s so b rin o s, m ie n tra s que un so b rin o
ne las conexiones relevantes entre libro y librería. La Figu puede ten er m uchos tíos.
ra 12.4b ilustra estas parejas objeto-relacióngráficam ente. L a cardinalidad define «el núm ero m áxim o de rela
Es im portante destacar que las parejas objeto -rela ciones de objetos que pueden p artic ip a ren una relación»
ción tienen dos direcciones; esto es, se p u eden leer en [TIL93], Sin em b arg o ,n o pro p o rcio n au n a indicación de
cualquier dirección. U n a libreríap id e libros o los libros si un objeto de datos en p articular debe o no participar
sonpedidos p o r u n a librería2. en la relación. Para especificar esta inform ación, el m ode
lo de datos añade m odalidad a la pareja objeto-relación.
12.3.2. C a r d in a lid a d y m o d a lid a d Modalidad. L a m o d a lid a d de u n a relación es cero
Los elementos básicos del m odelado de datos - o b j e t o s si no hay una necesidad explícita de que ocurra una rela
de datos, atributos, y relaciones— proporcionan la base ción, o que sea opcional. L a m odalidad es 1 si una o cu
del entendimiento del dom inio de inform ación de un pro rre n c ia de la re la c ió n es o b lig a to ria . P ara ilu strarlo ,
blema. Sin embargo, tam bién se debe com prenderla infor considerem os el softw are que utiliza una com pañía tele
mación adicional relacionada con estos elem entosbásicos. fónica local para p rocesar peticiones de reparación. Un
Hemos definido un conjunto de objetos y rep resen clien te indica que hay un problem a. Si se diagnostica
tado las parejas o b je to -re la ció n que los lim itan. U na que un problem a es relativam ente sim ple, sólo ocurre
una única acción de reparación. Sin em bargo, si-el pro
simple referencia: el objeto X que se relaciona con el
objeto Y no p ro p o rcio n a inform ación su ficien te para b lem a es com plejo, se pueden req uerir m últiples ac cio
propósitos de ingeniería del softw are. D ebem os c o m n es de rep aración. L a F ig u ra 12.5 ilu stra la relació n ,
prender la can tid a d de o c u rren cias del objeto X que c a rd in a lid a d y m o d a lid a d en tre los o b je to s de dato s
están relacionadas con ocurrencias del objeto Y. Esto
cliente y acción de reparación.
nos conduce al concepto del m odelado de datos llam a
do cardinalidad. Cardinalidad: Cardinalidad:
Cardinalidad. El m odelo de d ato s debe ser capaz Implica que un solo Implica que puede haber
de representar el núm ero de ocurrencias de objetos que cliente espere acción(es) muchas acciones
de reparación de reparación
se dan en una relación. T illm an [TIL93] define la ca r
dinal id a d de u n a p a re ja o b je to -re la ció n de la fo rm a
siguiente: Se proporciona con
La cardinalidad es la especificación del núm ero de
ocurrencias [de un objeto] que se re la c io n a con o c u
rrencias de otro [objeto]. L a cardinalidad norm alm ente
se expresa sim plem ente co m o «uno» o « m uchos». Por
Modalidad: Obligatoria Modalidad: Opcional
ejemplo, un m arido puede ten er solo una esposa (en la Implica que para tener Implica que puede haber
mayoría de las culturas), m ientras que un padre puede acción(es) de reparación, una situación en la que
tener m uchos hijos. Teniendo en consideración todas las debemos tener una acción de reparación
un cliente no sea necesaria
combinaciones de «uno» y « m u ch o s» , dos [objetos] se
pueden relacio n ar com o: F IG U R A 1 2 .5 . Cardinalidad y modalidad.
2Para evitar cualquier ambiguedad, se debe considerar la manera en

que se etiqueta una relación. Por ejemplo, si no se considera el con
www.FreeLibros.org
texto para una relación bidireccional, la Figura 12 4b podría in te r
pretarse erróneamente como libros piden librerías. En tales casos, se
necesita volver a escribir la frase.
203
Undetallado estudio que describelos drogramas entidad

relación puede encontrarse en www.univ-parisl.fr/
CRINFO/dmrg/MEE/misop003/
L a relación entre los objetos de datos coche y fabri

Tipo c a n te se representarían co m o se m u estra en la Figura
N2 de bastidor Modelo Motor Transmisión • • •
de carrocería 12.6. U n fab rican te co n stru y e uno o m uchos coches.
D ado el contexto im plicado p o r el D ER , la especifica
ción del objeto de datos coche (consulte la tabla de obje
F IG U R A 1 2 .6 . Un DER y una tabla de objetos de datos simples to s de d a to s de la F ig u ra 12.6) se ría radicalm ente
(Nota: En este DER la relación «construye» diferente de la prim era especificación (Fig. 12.3)Exa-
se indica mediante un rombo sobre la línea m in a n d o los sím bolos al final de la línea de conexión
de conexión entre los objetos de datos). en tre objetos, se puede v er que la m odalidad de ambas
incidencias es obligatoria (las líneas verticales).
E n la figura, se establece u na relació n de cardinali-
dad de 1 a m uchos. E sto es, se puede p ro p o rcionar un
sólo cliente con cero o m uchas acciones de reparación.
L os sím bolos sobre la co n e x ió n d e relació n que está
m ás cerca de los rectán g u lo s del objeto de datos indica
card in alid ad . L a barra vertical in d ic a 1, y la que está
divid id a en tres indica m uchas. L a m odalidad se indica
por los sím bolos m ás lejanos de los rectángulos de o b je
tos de datos. L a segunda barra vertical a la izquierda
in d ica que debe h ab er un clien te p ara que o cu rra u n a
acció n de rep aració n . E l círcu lo d e la d erech a in d ica
que puede no ex istir acción de rep aració n p ara el tipo
de p ro b lem a inform ado p o r el usuario.
12.3.3. D ia g r a m a s E n tid a d - R e la c ió n
L a pareja objeto-relación (estudiada en la Sección 12.3.1)
es la piedra angular del m odelo de datos. Estas parejas se
pueden rep resen tar gráficam ente m ediante el diagrama
entidad relación (DER). El D E R fue propuesto original
m ente por Peter C hen [CHE77] para el diseño de siste F IG U R A 1 2 .7 . DER ampliado.
m as de bases de datos relaciónales y ha sido am pliado por
otros. Se identifica un conjunto de com ponentes p rim a A m pliando el m odelo, representam os un D ER extre
rios para el DER: objetos de datos, atributos, relaciones m adam ente sim plificado (F igura 12.7) del elementode
y varios indicadores tipo. El propósito prim ario del D ER d istrib u c ió n del n e g o c io de los autom óviles. Se han
es representar objetos de datos y sus relaciones. in tro d u cid o n u ev o s o b jeto s de datos, tra n sp o rtis ta y
d is trib u id o r. A dem ás, las relaciones nuevas —trans
porta, contrata, autoriza y alm acena— indican cómo
Cl a VE los objetos de datos de la figura se asocian entre sí. las
Eobjetivo principal de un DERes representarentidades tablas p ara cada objeto de datos del D ER , se tendría que
(objetos de datas) ysus relacionesentre sí. d e sa rro lla r de a cu erd o c o n las reg las presentadas al
com ienzo del capítulo.
U na notación D E R rudim entaria se h a p resentado en A dem ás de la notación de D E R básica introducida
la Sección 12.3.L os objetos de datos son representados en las Figuras 12.6 y 12.7, el analista puede represen
p o r un rectángulo etiquetado. L as relacio n es se indican tar jerarquías de tipos de objetos de datos. En muchas
m ediante u na lín ea etiquetada conectando objetos. En ocurrencias, un ob jeto de d atos realm ente puede repre
algunas v ariaciones del D E R , la lín ea de co nexión co n sentar una clase o categoría de inform ación. Por ejem
tiene un rom bo que se etiqueta con la relación. Las cone plo, el objeto de d atos coche puede categorizarse como
www.FreeLibros.org
xiones entre objetos de datos y relaciones se establecen d o m é stic o , euro p eo o asiático. L a notación del DER
m ediante una v aried ad de sím bolos especiales que in d i m ostrada en la F igura 12.8 representa esta categoriza-
can cardinalidad y m odalidad (S ección 12.3.2). ción en form a de je rarq u ía.
204
C A P I T U L O 12 M O D E L A D O DEL A N Á LI S IS
^ C Q N S E Jo ffi
Desarrolle el DER de formo Iterativa poro Ir reflanado
los objetos de datas y los relaciones que los conectan.
La notación del D E R tam b ién pro p o rcio na un m e ca

nismo que represen ta la asociabilidad entre objetos. Un
objeto de datos asociativo se represen ta com o se m u es
tra en la F igura 12.9. E n la figura, los objetos de datos
que m odelan lo s su b sistem as in d iv id u ales se aso cian
con el objeto de datos coche.
El m odelado de datos y el d iagram a entidad relación
proporcionan al analista u n a notació n con cisa p ara e x a
minar datos d en tro del co n tex to de u n a aplicación de
procesamiento de datos. E n la m ay o ría de los casos, el
enfoque del m odelado de datos se u tiliza p ara crear una
parte del m odelo de análisis, pero tam b ién se puede u ti
lizar para el d iseñ o de bases de datos y p a ra so p o rtar
cualquier otro m étodo de análisis de requisitos. F IG U R A 1 2 .8 . Jerarquía tipo de objetos de datos.
La información se tran sfo rm a a m edida que fluye por un

sistema basado en com putadora. El sistem a acepta en tra
das en una gran variedad de form as; aplica elem entos de
hardware, softw are y hum anos para transform ar la en tra
da en salida, y produce salida en una gran variedad de
formas. La entrada puede ser una señal de control tran s
mitida por un controlador, una serie de n úm eros escri
tos por un enlace de un a red o un archivo volum inoso
de datos recuperado de un alm acenam iento secundario.
La transform ación puede ser, desde un a sencilla com
paración lógica, h asta u n com plejo algoritm o num érico
o un m ecanism o de reglas de in ferencia de un sistem a
experto. La salid a puede ser el encendido de un diodo
F IG U R A 1 2 .1 0 . M odelo del flujo de inform ación.
de emisión de luz (L E D ) o un inform e de 200 páginas.
Efectivamente, p o dem os crear un modelo de flujo para El análisis estructurado es una técnica del m o d ela
cualquier sistem a de com putadora, in d ep endientem en do del flujo y del contenido de la inform ación. Tal com o
te del tam año y de la com plejidad. m u estra la F igura 12.10, el sistem a basado en co m p u
tad o ra se representa com o una transform ación de in fo r
m ación. S e utiliza un rectángulo p ara representar una
entidad externa, esto es, un elem ento del sistem a (por
ejem plo, un elem ento hardw are, u n a persona, o tro p ro
gram a) u otro sistem a que produce inform ación p a ra ser
transform ada por el softw are, o recibe inform ación p ro
d u c id a p o r el softw are. U n círcu lo (tam b ién llam ado
burbuja) re p resen ta un proceso o transform ación que
es aplicado a los datos (o al control) y los m odifica. U na
flecha representa uno o m ás elem entos de datos (obje
tos de dato). T o d a flecha en un d iag ram a de flujos de
datos debe estar etiquetada. Las líneas en paralelo re p re
sentan un alm acenam iento - i n f o r m a c i ó n alm acenada
www.FreeLibros.org
que es u tilizada p o r el software— . L a sim plicidad de la
n o tación del D FD es una razón p o r la que las técnicas
FIGURA 1 2 .9 . Asociación de objetos de datos. del análisis estructurado son am pliam ente utilizadas.
205
IN GE NI E RI A DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
C o m o ya indicam os anteriorm ente, se puede refinar

^ p o m tu io ffy . cad a una de las burbujas en distintos niveles para mos
El DED ro e s procedimental. Nopermite representar trar un m ay o r detalle. La F igura 12.11 ilustra este con
cepto. El m odelo fundam ental del sistem a F m uestra la
ni bucles. Simplemente muestro el flujo de datos. en trad a p rin cip a l A y la sa lid a fin a l B. R efinam os el
m odelo F en las tra n sfo rm a c io n e s // a j7. O bserve que
Es conveniente h acer n o tar que el diag ram a no p ro se debe m antener la continuidad del flu jo de informa
p o rcio n a n in g u n a indicación explícita de la secuencia ción, es decir, que la entrada y la salida de cada refna-
de procesam iento o de u n a condición lógica. El p ro ce m ie n to d eb e ser la m ism a. E ste c o n c e p to , a veces
dim iento o secuencia puede estar im plícitam ente en el denom inado balanceo, es esencial para el desarrollo de
d ia g ra m a , pues los detalles lógicos son generalm ente m o d e lo s c o n siste n te s. U n m a y o r re fin a m ie n to d e ¡4
retrasados h asta el diseño del softw are. E s im portante m uestra m ás detalle en la form a de las transform acio
no confundir un D FD con el diag ram a de flujo. n e s / / / a f4 5 . D e nu ev o , la en trad a (X, Y ) y la sahda
(Z ) perm anecen inalteradas.
12.4.1. D ia g r a m a s d e flujo d e d a to s
A m ed id a que la inform ación se m ueve a través del soft
w are, es m o d ificad a p o r un a serie de transform aciones.
El diagram a de flu jo de datos (D F D ) qs una técnica que
rep resen ta el flujo de la info rm ació n y las tran sfo rm a
ciones que se aplican a los d ato s al m overse desde la
entrada h asta la salida. E n la F ig u ra 12.10 se m uestra
la fo rm a b ásica de u n d iag ram a de flu jo de datos. El
D F D es tam b ién conocido com o g ra fo de flu jo de datos
o co m o diagram a de burbujas.
CLAVE
El DFDfad/ia un mecanismo paro modelizare I flujo
de Informacióny modellzar las funciones.
S e p u ed e u sar el d ia g ra m a de flu jo de d a to s p a ra
rep resen tar un sistem a o un softw are a cualq u ier nivel F I G U R A 1 2 . 1 1 . R e f i n a m i e n t o d e l flujo d e I n f o r m a c i ó n .
de abstracción. D e hecho, los D FD s p u ed en ser div id i
dos en niveles que represen ten un m ay o r flujo de in fo r L a notación básica que se usa para desarrollar un D FD
m ació n y un m ay o r detalle funcional. P o r consiguiente, no es en sí m ism a suficiente para describir los requisi
el D FD p ro p o rcio n a un m ecanism o p ara el m odelado to s del softw are. P o r ejem p lo , u n a fle ch a de un DFD
funcional, así com o el m odelado del flujo de in form a representa un objeto de datos que entra o sale de un pro
ción. A l h acer esto, se cum ple el segundo p rincipio de ceso. U n alm acén de datos representa alguna colección
análisis operacional (esto es, crear u n m odelo funcio o rganizada de datos. P ero ¿cuál es el contenido de los
n al) estudiado en el C apítulo 11. datos im plicados en las flechas o en el alm acén? Si la
U n D F D de nivel O, tam b ién d en o m in ad o m o delo flecha (o el alm acén) representan una colección de obje
fu n d a m e n ta l d el sistem a o m odelo de co n texto , re p re tos, jc u á le s son? P ara responder a estas preguntas, apli
senta al elem ento de softw are com pleto com o una sola cam os otro com ponente de la notación básica del análisis
b u rb u ja con datos de entrad a y de salida representados estru c tu ra d o — el diccionario de datos— . El formato y
p o r flechas de entrad a y de salida, respectivam ente. A l el uso del diccionario de datos se explica m ás adelante.
dividir el D FD de nivel O p ara m ostrar m ás detalles, apa
recen representados p rocesos (b u rb u jas) y cam inos de ^ O N S E J o j^
flujo de info rm ació n adicionales. P or ejem plo, un D FD
de nivel 1 puede contener cinco o seis b urbujas con fle Si bien lo continuidad del flujo de Información debe
ser mantenido, reconocemosque un ebmento de datos
chas interconectadas. C ad a uno de los p rocesos rep re
representado en un nivel puede ser refinado en sus partes
sen tad o s en el n iv el 1 es u n a su b fu n ció n del sistem a
constituyentesen el siguiente nivel.
general en el m odelo del contexto.
L a notación gráfica debe ser am pliada con texto des
^ 0 ONSEJÓ^ criptivo. Se puede u sar u n a especificación de proceso
www.FreeLibros.org
lo descomposición de un nivel de DFD en su siguiente
(EP) para especificar los detalles de procesam iento que
debería seguir uno oproximociónol ratiol:5, reduciendo
im plica una b u rbuja del D FD . L a especificación de pro
los futuros descomposiciones ceso describe la entrada a la función, el algoritm o que
206
C A P Í T U L O 12 M O D E L A D O DEL A NÁ LI SI S
se aplica para transform ar la entrada y la salida que se vise la v elo cid ad de la tu rb in a , la tem p eratu ra del
produce. Además, el EP indica las restricciones y lim i com bustible y varias sondas de presión, todo ello de
taciones impuestas al proceso (función), las caracterís form a continua. La notación del flujo de datos c o n
ticas de rendim iento que son relevantes al proceso y las vencional no hace distinciones entre datos discretos
restricciones de diseño que puedan tener influencia en y datos continuos en el tiem po. U na am pliación de la
la forma de im plementar el proceso. notación básica del análisis estructurado que se m ues
tra en la Figura 12.12 proporciona un m ecanism o para
12.4.2. Ampliaciones para sistemas de tiempo real representar el flujo de datos continuo en el tiem po.
Para representar el flujo continuo en el tiem po se usa
Muchas aplicaciones de software son dependientes del la flecha de dos cabezas, m ie n tra s que el flu jo de
tiempo y procesan m ás inform ación orientada al con datos discreto se re p resen ta con una flech a de una
trol de datos. Un sistem a de tiem po real debe inter- sola cabeza. En la figura, se m ide continuam ente la
actuar con el m undo real en m arcos tem porales que temperatura supervisada, m ientras que sólo se p ro
vienen dados por el m undo real. El control de naves o porciona un valor para el ajuste de temperatura. El
de procesos de fabricación, los productos de consum o p roceso de la fig u ra p ro d u c e una salid a co n tin u a,
y la instrum entación industrial son algunas de entre valor corregido.
cientos de aplicaciones del software de tiem po real.
Para que resulte adecuado el análisis del software de
tiempo real, se han propuesto varias am pliaciones para
la notación básica del análisis estructurado.
$La v e
Pora odecuor el modelo a un sistema en tiem po real,
la notación del análisis estructurado debe permitir
12.4.3. Ampliaciones de Ward y Mellor procesar eventos y la llegada de continuos datos.
Wardy M ellor [WAR85] am plían la notación básica La distinción entre flujo de datos discreto y c o n
del análisis estru ctu rad o para que se adapte a las tinuo en el tiem po tiene im plicaciones im portantes,
siguientes dem andas im puestas por los sistem as de tanto para el ingeniero de sistem as com o para el d ise
tiempo real: ñador del softw are. D urante la creación del m odelo
• Flujo de inform ación que es recogido o producido del sistem a, podrá aislar los procesos que pueden ser
de forma continua en el tiempo. c rític o s p ara el re n d im ie n to (es m uy usu al que la
• Información de control que pasa por el sistema y el e n tra d a y salid a de d ato s continuos e n el tiem p o
procesamiento de control asociado. dependan del rendim iento). Al crear el m odelo fís i
co o de im plem entación, el diseñador debe esta b le
• Ocurrencias múltiples de la m ism a transform ación
ce r un m eca n ism o para la reco lecc ió n de dato s
que se encuentran a m enudo en situaciones de mul-
continuos en el tiem po. O bviam ente, el sistem a d ig i
titarea.
tal recolecta datos en una form a casi continua u tili
• Estados del sistema y mecanismos que producen tran zan d o técn icas de m u estreo de alta v e lo cid a d . La
sición de estados en el sistema. notación indica dónde se necesita hardw are de c o n
versión analógica a dig ital y qué tran sfo rm acio n es
requerirán, con m ayor probabilidad, un softw are de
E n trad a alto rendim iento.
« c o n tin u a »
T e m p e ra tu ra / S a lid a En los diagram as de flujo de datos c o n v e n cio n a
les no se representa ex p lícitam en te el co n tro l o f l u
j o s de sucesos. De hecho, al analista se le advierte
de que ha de ex c lu ir específicam ente la rep resen ta
ción del flu jo de co n tro l del d iag ra m a de flu jo de
datos. Esta exclusión es dem asiado restrictiv a cu a n
do se trata de aplicaciones de tiem po real y, p o r este
m otivo, se ha d esarro llad o una n o tació n e sp e c ia li
zada para la representación del flujo de sucesos y del
procesam iento de control. S iguiendo con los co n v e
FIGURA 1 2 .1 2 . F lu jo d e d a t o s c o n t i n u o e n e l t i e m p o . nios esta b le c id o s p ara los d iag ra m as de flu jo de
datos, el flujo de datos se representa m ediante fle
En un porcentaje significativo de aplicaciones de chas con traz o co n tin u o . Sin em b arg o , el f l u j o de
tiempo real, el sistem a debe controlar la inform ación control se representa m ediante flechas de trazo d is
continua en el tiempo generada por algún proceso del continuo o som breadas. U n proceso que sólo m an e
www.FreeLibros.org
mundo real. Por ejem plo, puede que se haga n ecesa j a flujos de control denom inado p ro c e so de control,
rio un sistem a de control de pruebas en tiem po real se representa analógicam ente m ediante una burbuja
para m áquinas de turbina de gas, para que se super con trazo discontinuo.
207
IN GE NI E RI A DEL SOF TW ARE . UN EN F O Q U E P R Á C T I C O
P o r ejem p lo , puede que haya que supervisar varios

Movimiento
de alarma buffers de estad o de piezas para que puedan activarse
, Estado de ■A diferentes robots en los m om entos oportunos. Además,
\ cada elemento
puede que cada robot tenga su propio sistem a de control.
Buffer del estado L a notación de W ard y M ellor se usa para representar
de las piezas múltiples ocurrencias equivalentes del m ism o proceso.
12.4.4. A m pliaciones de Hatley y Pirbhai

L as am pliaciones de H atley y P irbhai [HAT87] a la
notación básica del análisis estructurado se centra menos
Órdenes en la creación de sím bolos gráficos adicionales y más en
del operador
Ordenes
la representacióny especificaciónde los aspectos del soft
de posición w are orientados al control. L a flecha de trazo discontinuo
se utiliza para representar el flujo de control o de sucesos.
A diferencia de W ard y M ellor, H atley y Pirbhai sugieren
que se represente por separado la notación de trazo conti
Archivo de Órdenes I nuo de la de trazo discontinuo. A sí, se define un diagra
del robot |
ma de flujo de control (D FC ) .El DFC contiene los mismos
F IG U R A 12 .13. F lujos d e d a to s y d e co n tro l u tiliza n d o procesos que el DFD, pero m uestra el flujo de control en
la n o ta c ió n d e W ard y M ellor [WAR85], lugar de datos. E n lugar de representar directam ente los
procesos de control dentro del m odelo de flujo, se usa una
referencia de notación (una barra sólida) a una especifica
El flujo de control puede ser una entrada directa de
ción de control (E C ) .En esencia, se puede considerar la
un proceso convencional o de un proceso de control. L a
barra com o una «ventana»hacia un «director» (la EC) que
F ig u ra 12.13 ilu stra el flu jo de co n tro l y su p ro c e sa
controla los procesos (las burbujas) representadas en el
m ien to , u tiliz a n d o la n o ta c ió n de W ard y M ellor. L a
D FD , de acuerdo con los sucesos que pasan a través de la
figura ilustra el planteam iento de m ay o r nivel de un flu
ventana. Se usa la EC, que se describe en detalle en la Sec
j o de datos y de control de u n a célula de fabricación. A
ción 12.6.4,para indicar: (1) cóm o se com portael software
m edida que se v an colocando en las fijaciones los co m
cuando se detecta un suceso o una señal de control, y (2)
ponentes a ser ensam blados p o r un robot, se ajusta un
qué procesos se invocan com o consecuencia de la ocu
b it de u n buffer de estado de las piezas (un alm acén
rrencia del suceso. Se usa una especificación de proceso
de control) que indica la p resencia o ausencia de cada
(EP)para describir el procesam iento interno de los proce
com ponente. L a inform ación de sucesos contenida en
sos representados en el diagram a de flujo.
el buffer de estado de las piezas se p a sa co m o una
cadena de bits a un proceso, in terfa z d el m o n ito r de
fija c ió n y operador. El p roceso leerá Órdenes del ope
rador só lo cu an d o la info rm ació n de co n tro l, cadena CLAVE
de bits, in d iq u e que todas las fijaciones co ntienen c o m El DFC muestra como los eventos se mueven
ponentes. Se envía un indicador de suceso, indicador en el sistema. Una EC muestra el comportamiento
de comienzo/parada, a control de activación d el robot, del software como una consecuencia de los eventos
un p roceso de control que p erm ite un p o sterio r p ro ce y a qué procesos les corresponde intervenir
sam ien to de ó rdenes. C o m o co n se c u e n c ia del suceso en Id manipulación de los eventos.
activar proceso se prod u cen otros flujos de datos que
U sando la notación descrita en las Figuras 12.12 y
son enviados a p r o c e sa r órdenes d el robot.
12.13,junto con la inform ación adicional contenida en
EPs y EC s, H atley y P irbhai crean un m odelo de siste
C jc /ta ; m a de tiem po real. P ara representar los datos y los pro
8 wfomo de un sistema en tiempo real a veces cesos que los m anejan se usan los diagram as de flujo de
contiene dispositivos que actúan como los 5 sentidos datos. L os diagram as de flujo de control m uestran cómo
del sistemo. fluyen los sucesos entre los distintos procesos e ilustran
Pwi Wmi y Stepken Melior cóm o los sucesos externos hacen que se activen los pro
cesos. Las interrelaciones entre los m odelos de proce
E n algunas situaciones, en un sistem a de tiem po real so de control se m uestran esquem áticam ente en la Figura
puede h ab er ocurrencias m ú ltiples del m ism o proceso 12.14. El modelo de procesamiento está «conectado»con
de control o de tran sfo rm ació n de datos. Se puede dar el m odelo de control a través de condiciones de datos.
www.FreeLibros.org
este caso en un entorno m ultitarea en el que se activan El m odelo de control está «conectado» con el modelo
las tareas com o resultado de algún p rocesam iento in ter de procesos m ediante la inform ación de activación de
n o o de sucesos externos. procesos contenida en la EC.
208
C A P Í T U L O 12 M O D EL A D O DEL A NÁ LI S IS
P ara determ inar qué es lo que ocurre cu an d o se p ro

duce este suceso, debem os com probar la EC.
Referencia L a e sp e c ific a c ió n d e co n tro l (E C ) c o n tie n e v a ria s
I a especificación del te É rn a en fe rrp o real planteada h e rram ien tas im p o rtan tes del m o delado. P a ra in d icar
por Hatley y Pirbhaies descrita en www.univ-porisl.fr qué p ro ceso s se activ an p o r un su ceso d a d o q u e flu
/CR!NFO/dmrg/ME£98/mísop032/ ye p o r la b a rra v e rtic a l, se u sa u n a tabla de a ctiva
ción de p ro ce so s (d escrita en la S ec ció n 12.6.4). P o r
Una condición de datos se produce cuando los datos eje m p lo , u n a ta b la de ac tiv ació n de p ro c e so s (TA P)
de entrada de un proceso hacen que se produzca una sali p ara la F ig u ra 12.14 p o d ría in d ica r que el suceso p re
da de control. L a Figura 12.14 ilustra esta situación en una sión a lta h a ría que se in v o c a ra u n p ro c e so reducir
parte del m odelo de flujo para un sistem a de supervisión p resió n del tanque (que n o se m u e stra ). A d e m á s de
y control automatizado de válvulas de presión de una refi la TAP, la E C p u ed e c o n te n e r un diagram a de tra n
nería de petróleo. El proceso comprobar y convertirpre- sición de estados ( D T E ) . E l D T E e s un m o d e lo de
sión implementa el algoritm o descrito en el pseudocódigo co m p o rta m ie n to que se b a sa en la d e fin ic ió n d e un
EP que se muestra. C uando la presión absoluta del tanque conjunto de estados del sistem a y se d e sc rib e en la
es mayor que el m áxim o perm itido, se genera un suceso sección sig u ien te.
presión alta. O bserve que cuando se usa la notación de
Hadey y Pirbhai, el flujo de datos de m uestra com o p ar Estado
te de un DFD, m ientras que el flujo de control se encuen de alimentación
tra a parte en un diagram a de flujo de control. del papel
(atascado.. vacío)
Alarma
D ia g ra m a D ia g ra m a
d e flu jo d e d a to s d e flu jo d e c o n tro l
Comienzo/ / Producir \
parada / / Gestión \ »I visualizaciór, 1
/ í de copilado 1 V de usuario M
/
Leer
entrada de
operador
Realizar
diagnóstico
del
problema
Recargar
papel Llena
Fallo
de reproducción
F IG U R A 1 2 .1 5 . DFCde nivel 1 para el software de unafoto-
copiadora.
BftU MQPELADII^£LJS.QMP.0RIÁMI£IÍ1Q.
El modelado del com portam iento e s uno de lo s p rin
¿Cómo modelizar la reacción
cipios fu n d am en tales de to d o s los m é to d o s de a n á li
sis de requisitos. S in em b arg o , sólo alg u n as versio n es
am pliadas d el a n á lis is e s tr u c tu r a d o ([W A R 8 5 ],
• del software ante un evento
externo?
[HAT87J) p ro p o rc io n a n un a n o ta c ió n p a ra este tip o U n estado es un m odo observable de com portam iento.

de m odelado. E l d ia g ra m a d e tra n s ic ió n d e e sta d o s Por ejem plo, estados para un sistem a de supervisión y de
rep resen ta el c o m p o r ta m ie n to 'de u n s is te m a que control para que las válvulas de presión descritas en la Sec
m uestra los e sta d o s y los su c e so s qu e h ace n que el ción 12.4.4. puedan estar en: estado de supervisión, esta
sistem a c a m b ie de e sta d o . A d e m á s , el D T E in d ic a do de alarma, estado de liberación depresión y otros. Cada
www.FreeLibros.org
qué a ccio n es (p o r e je m p lo , a ctiv ació n d e p ro c e so s) uno de estos estados representa un m odo de co m porta
se llevan a c a b o c o m o c o n s e c u e n c ia d e un su c e s o m iento del sistema. Un diagram a de transición de estados
determ inado. indica cóm o se m ueve el sistem a de un estado a otro.
209
INGE NIE RÍA DEL SOF TW ARE . UN E N F O Q U E P R A C T I C O
P ara ilustrar el uso de las am pliaciones de com por z o /p a r a d a p ara a c tiv a r/d e sac tiv a r el p ro c e so de ges
tam iento y de control de H atley y Pirbhai, considerem os tión de copiado. D e fo rm a sim ilar, el suceso ata sc a
el softw are em potrado en una m áquina foto co p iadorade d a (p a rte d e l e s ta d o de a lim e n ta c ió n d e l papel)
oficina. E n la F ig u ra 12.15 se m u estra u n flujo de co n a c tiv a ría rea liza r d ia g n ó stico d el p ro b le m a . Se debe
trol p ara el softw are de fotocopiadora. L as flechas del ría d esta car que to d as las b a rras v ertica le s dentro del
flujo de datos se h an som breado ligeram ente con p ro D F C se refie ren a la m ism a EC. U n flu jo de suceso
pósito s ilustrativos, pero en realid ad se m u estran com o se pued e in tro d u c ir directam en te en el p ro ceso como
parte de un diagram a de flujo de control. m u estra fa llo d e re p ro d u c c ió n . Sin em bargo, este flu
L os flu jo s de co n tro l se m u e stra n de c a d a p ro ceso j o no a c tiv a el p ro c e so , sino que p ro p o rcio n a infor
individual y las b arras v erticales rep resen tan las « v e n m ació n de c o n tro l p a ra el a lg o ritm o de proceso.
ta n a s » EC . P o r e je m p lo , lo s su c e so s e s ta d o d e a li U n d iag ram a de tran sic ió n de estad o s sim plificado
m e n ta c ió n d e l p a p e l y de c o m ie n z o /p a r a d a flu y e n p a ra e l so ftw a re d e fo to c o p ia d o ra d e sc rito anterior
d e n tro de la b a rra de EC. E sto im p lic a que ca d a uno m en te se m u e stra en la F ig u ra 12.16. L os rectángulos
d e e s to s s u c e s o s h a rá q u e se a c tiv e a lg ú n p ro c e so re p re se n ta n e sta d o s del siste m a y las fle c h a s repre
rep re se n ta d o en el D FC . Si se fu e ra n a ex am in ar las sentan transiciones entre estados. C ad a flech a está eti
in te rio rid a d e s del E C , se m o stra ría el su ceso co m ien - q u e ta d a con u n a ex p re sió n en fo rm a de fracción. La
parte superior in d ica el suceso (o sucesos) que hace(n)
que se p ro d u z ca la tran sició n . L a parte in ferio r indica
Llena y comienzo
la acción que se produce co m o con secu en cia del suce
so. A sí, c u a n d o la b a n d e ja d e p a p e l e s tá llen a , y el
b o tó n de co m ie n z o h a sido p u lsa d o , el sistem a pasa
del estad o leyendo órdenes al estado realizando copias.
O bserve que lo s e sta d o s no se co rresp o n d e n necesa
ria m e n te co n los p ro c e so s d e fo rm a b iu n ív o c a . Por
ejem p lo , el esta d o realizando c o p ia s e n g lo b a ría tanto
el p ro c e so g e stió n de co p ia d o c o m o e l p ro ceso pro
ducir visualización de usuario que aparecen en la Figu
ra 12.15.
invocar realizar diagnóstico del problema
No atascado
Diagnosticando 1 C ^ C /fa :
ei problema i
lo ttre c o perdido es un estado de confusión..
Ate orifica misteriosa sobre un DTE
F IG U R A 1 2 .1 6 . Diagramas de transición de estados simplifi FWB¡eirte complejo.
cado para el software de una fotocopiadora.
12.6 MECANISMOS DEL A M Á LlSIS.JSIiiP.C.lPBflD Q

E n la se c c ió n a n te rio r, h e m o s v is to la s n o ta c io n e s lo s co m p leto s y p re ciso s m ed ian te el an álisis estruc
b á s ic a y a m p lia d a d e l a n á lis is e s tru c tu ra d o . P a ra turado. A lo larg o de este estu d io , se usará la notación
p o d e r u tiliz a r la s e fic ie n te m e n te en e l a n á lis is de p re se n ta d a en la S ecc ió n 12.4 y se p resen tarán , con
req u isito s del so ftw are, se h a de c o m b in a r e sa n o ta a lg ú n d e ta lle , o tra s fo rm a s d e n o ta c ió n y a aludidas
c ió n co n un c o n ju n to d e h e u rístic a s q u e p e rm itan al anteriorm ente.
in g e n ie ro d el s o ftw a re d e riv a r u n b u e n m o d e lo de
análisis. P ara ilu stra r el uso de e sas h e u rístic a s, en el 12.6.1. C r e a c i ó n d e u n d ia g ra m a Entidad-Relación
resto de e ste c a p ítu lo u tiliz a re m o s u n a v e rsió n a d a p
El diagram a de entidad-relación perm ite que un ingeniero
tada de las am pliaciones de H atley y P irb h ai [HAT87]
a la n o ta c ió n b á sic a del an álisis e stru c tu ra d o . del softw are especifique los objetos de datos que entran y
salen de un sistem a, los atributos que definen las propie
dades de estos objetos y las relaciones entre los objetos.Al
igual que la m ayoría de los elem entos del m odelo de aná
£1 modelo de análisis permite un exorne,, crítico lisis y las relaciones entre objetos, el D E R se construye de
de los requisitosde/softwore desde tres puntos una form a iterativa. Se tom a el enfoque siguiente:
diferentes de vista. Asegurando lo utilidad de los DERs,
www.FreeLibros.org
DFDs y DTEs cuando construyes el modelo
¿Cuáles son los pasos
E n las seccio n es sig u ien tes, se ex a m in a c a d a uno requeridos para construir
de los pasos que se debe seguir p ara desarro llar m o d e un DER?
210
C A P I T U L O 12 M O D E L A D O DEL ANA LIS IS
1. Durante la reco p ilació n de requisitos, se pide que los ta entre el propietario y panel de control, sistem a de
clientes listen las «cosas» que afronta el proceso de seguridad y servicio de vigilancia. Existe una cone
la aplicación o del negocio. E stas «co sas» e v o lu xión Única entre el sensor y el sistema de seguridad, y
cionan en u n a lista de objetos de datos de entrada y así sucesivamente.
de salida, así com o entidades externas que producen U na vez que se han definido todas las conexiones,
o consum en inform ación. se identifican una o varias parejas objeto-relación para
2. Tomando objetos uno cada vez, el analista y el cliente cada conexión. Por ejem plo, se determ ina la conexión
definen si existe u n a conexión (sin n o m brar en ese entre sensor y sistem a de seguridad para que tenga las
punto) o no en tre el objeto de datos y otros objetos. parejas objeto-relación siguientes:
el sistem a de seguridad supervisa el sensor
3. Siem pre que e x iste u n a c o n e x ió n , el a n a lista y el
el sistem a de seguridad a ctiva ld esa ctiva el sensor
cliente crean u n a o varias parejas de objeto-relación.
el sistem a de seguridad p r u e b a el sensor
4. Para cada p areja objeto -relació n se explóra la card i el sistem a de seguridad p ro g ra m a el sensor
nalidad y la m odalidad. Cada una de las parejas objeto-relación anteriores se
5. Interactivam ente se co n tin ú an los pasos del 2 al 4 analizan para determ inar la cardinalidad y la m odali
hasta que se hayan definido todas las parejas objeto- dad. Por ejem plo, en la pareja objeto-relación el siste
relación. Es norm al descu b rir o m isio n es a m ed id a m a de seguridad supervisa el sensor, la cardinalidad
que el p roceso continúa. O bjetos y relaciones n u e entre sistem a de seguridad y sensor es una a muchos.
vos se añadirán invariablem ente a m edida que crezca La m odalidad es una incidencia de sistem a de seguri
el núm ero de interacciones. dad (obligatoria) y al m enos una incidencia de sensor
6. Se definen los atributos de cada entidad. (obligatorio). M ediante la notación DER introducida en
7. Se form aliza y se revisa el diagram a entidad-relación. la Sección 12.3, la línea de conexión entre sistema de
seguridad y sensor se m odificaría, com o se m uestra en
8. Se repiten los pasos del 1 al 7 h asta que se term ina
la Figura 12.18. Se aplicaría un análisis sim ilar al res
el m odelado de datos.
to de los objetos de datos.
Para ilu strar el uso de estas directrices básicas, u sa
remos el ejem plo del sistem a de seg u rid ad H ogarSe-
Supervisa
giiro tratado en e l C ap ítu lo 11. A c o n tin u a c ió n ,
reproducimos la narrativa de procesam iento para Hogar-
Seguro (Sección 11.3.3), la siguiente lista (parcial) de
«cosas» son im portantes para el problem a:
• propietario
• panel de control
• sensores
• sistema de seguridad
• servicio de vig ilan cia
F IG U R A 1 2 .1 8 . Desarrollo de relaciones y cardinalidad/
modalidad.
Se estudia cada objeto para determ inar sus atributos.

Como se está considerando el software que debe sopor
tar H o g a rS e g u ro , los atributos se deberían centrar en
datos que deban almacenarse para permitir que opere el
sistema. Por ejem plo, el objeto sensor podría tener los
atributos siguientes: tipo de sensor, número de identifi
cación interna, localización de zona, y nivel de alarma.
12.6.2. C r e a c ió n d e u n m o d e lo d e flu jo d e d a t o s
El diagram a de flu jo de datos (1)F D ) permite al inge
niero del software desarrollar los m odelos del ám bito
de inform ación y del ám bito funcional al m ism o tiem
FIGURA 1 2 .1 7 . Establecimiento de conexiones. po. A m edida que se refina el DFD en mayores niveles
de detalle, el analista lleva a cabo implícitam ente una
Tomando estas «cosas» una a una, se exploran las descomposición funcional del sistema. Al m ismo tiem
www.FreeLibros.org
conexiones. Para realizar esto, se dibuja cada objeto y po, el refinam iento del D F D produce un refinam iento
se señalan las líneas que conectan objetos. Por ejemplo, de los datos a m edida que se mueven a través de los pro
la Figura 12.17 m uestra que existe una conexión direc cesos que com ponen la aplicación.
211
in g e n ie r ía del s o f t w a r e , un enfoque pr á c tic o
¿Existe alguna guía útil para

nom bres y los verbos que son sinónimosy no se apoyan
crear DFD's?
directamente en el proceso de modelado)3.
Unas pocas directrices sencillas pueden ayudar de

forma considerable durante la derivación de un diagra
El análisis gramatical no es seguro, pero facilito
m a de flujo de datos; (1) el diagram a de flujo de datos
una excelenteplataforma siestas empezando
de nivel 0 debe reflejar el software/sistem a com o una
a definir objetas de datos y su transformación.
sola burbuja; (2) se deben anotar cuidadosam ente la
entrada y la salida principales; ( 3 ) e 1refinam iento debe
com enzar aislando los procesos, los objetos de datos y E l so ftw a re H o g a rS e g u ro p e r m ite al p ro p ie ta rio de la
v iv ien d a c o n fig u ra r el sistem a d e seguridad al instalarlo;
los almacenes de datos que sean candidatos a ser repre
supervisa to d o s los sensores conectados al sistem a de segu
sentados en el siguiente nivel; (4) todas las flechas y las ridad e in te ra c tú a c o n el pro p ietario a trav é s de un teclado
burbujas deben ser rotuladas con nom bres significati n um érico y unas teclas de fu n ció n que se en cu e n tra n en el
vos; (5) entre sucesivos niveles se debe mantener la con panel de control d e H o g a rS e g u ro que se m uestra en la Figu
tinuidad del flujo de inform ación; (6 ) se deben refinar ra 11.2.
las burbujas de una en una. Hay una tendencia natural D urante la instalación, se usa el panel de control de Hogar-
a com plicar en exceso el diagram a de flujo de datos. S eguro para « p rogram ar» y c o n fig u ra re 1 sistem a. Cadasen-
Esto ocurre cuando el analista intenta reflejar dem asia sor tiene a signado un núm ero y un tipo, existe una contrasella
m aestra para a c tiv a r y d e sa c tiva r el sistem a, y se introdú
dos detalles dem asiado pronto o representa aspectos
cela) un(os ) teléfonols) con los que contactar cuando se pro
procedimentales en detrim entodel flujo de información. duce un suceso detectado por un sensor.
En la Figura 12.19se m uestra el DFD de nivel 0 para
C u a n d o el softw are d etecta un suceso, invoca una alar
Hogar Segur o. Las entidades externas principales (cua ma audible que está incorporada en el sistem a. Tras un retar-
dros) producen inform ación para ser usada por el siste d ü , especificado por el pro p ietario du ran te la configuración
ma y consum en inform ación generada por el sistema. del sistem a, el program a m arca un núm ero de teléfono de un
Las flechas etiquetadas representan objetos de datos u servicio de m o n ito riza ció n .p ro p o rcio n a inform ación sobre
objetos de datos de tipo jerárquico. Por ejemplo, ó rd e la situación e inform a sobre la n aturaleza del suceso detec
tado. C ada 20 segundos se vo lverá a m a r c a r e 1 núm ero de
nes y dato s de u su a rio engloba todas las órdenes de
teléfono hasta que se consiga e sta b lecer la com unicación.
configuración, todas las órdenes de activación/desacti
T oda la interacción con H ogarSeguro está gestionada por
vación, todas las variadas interacciones y todos los datos
un subsistem a d e interacción con el u suario que lee la ínfor-
que se introducen para cualificar o ampliar una orden. m ación intro d u cid a a trav é s del teclad o n um érico y de las
teclas de fu n ció n , m uestra m ensajes de petición en un moni
Monitor tor l.C D y m uestra inform ación sobre el estado del sistema
del panel en el m o n ito r L C D . L a in te ra c c ió n p o r te c la d o tom a la
ie control siguiente f o r m a ...
De acuerdo con el «análisis gram atical», comienza

Alarma a aparecer un patrón. Todos los verbos son procesos
de H ogarSeguro, es decir, deben estar en últim a ins
tancia representados com o burbujas en el consiguien
Línea
te DFD. Todos los nom bres son, o bien entidades
ex tern as (cuadrados), objetos de datos o de control
(flechas) o alm acenes de datos (líneas dobles). Ade
F IG U R A 1 2 .1 9 . DFD de nivel contextual para H o g a rS e g u ro . m ás los nom bres y los verbos están relacionados entre
sí (por ejem plo, cada sensor tiene asignado un núme-
Ahora tenemos que expandir el DFD de nivel 0 o de ro y un tipo). Por tanto, con el análisis gramatical de
nivel a un modelo de nivel 1. Pero, ¿cómo lo hacemos? la narrativa de procesam iento de una burbuja de cual
Una sencilla, pero efectiva, técnica consiste en realizar un quier nivel de D FD , podem os generar m ucha infor
«análisisgramatical»de la narrativa de procesamiento que m ación útil sobre cóm o proceder en el refinamiento
describe la burbuja de nivel contextual. Es decir, aislar del siguiente nivel. U sando esa inform ación, obtene
todos los nom bres (y sentencias nom inales) y todos los m os el D FD de nivel 1 que se m uestra en la Figura
verbos (y sentencias verbales) de la narrativa presentada 12.20. El proceso de nivel contextual de la Figura 12.19
arriba. Para ilustrarlo, reproducimos de nuevo la narrati se ha expandido en siete procesos, derivados de un
va de procesam iento, subrayando las primeras ocurren exam en del análisis gram atical. De form a sim ilar se
cias de los nombres y con las primeras ocurrencias de los ha derivado el flujo de inform ación entre los procesos
verbos en cursiva. (Se debería señalar que se omiten los del nivel 1.
www.FreeLibros.org
3 Se debe tener en cuenta que serán om itidos los nom bres y verbos
que sean sinónim os o no tengan una relación directa con el modelo
de procesos.
212
C A P Í T U L O 12 M O D E L A D O DEL ANÁLISIS
12.6.3. C r e a c ió n d e u n m o d e lo d e flu jo d e c o n tro l

f C o n f ig u r a r \ Para m uchos tipos de aplicaciones de procesam iento de
Ó rd e n e s y d a to s \ M D a to s d e datos, todo lo que se necesita para obtener una represen
del u s u a r i o ^ ^ X » * , * ^ ^ c o n fig u ra c ió n tación significativa de los requisitos del softw are es el
P e tic ió n d e m odelo de flujo de datos. Sin em bargo, com o y a hem os
In te ra c tu a r \ c o n fia u ra c ió n
m encionado anteriorm ente,existe una clase de num ero
sas aplicaciones que están «dirigidas»por sucesos en lugar
p a ra d a de por los datos, que producen inform ación de control m ás
que inform es o visualizaciones, que procesan in form a
ción con fuertes lim itaciones de tiem po y rendim iento.
Tales aplicaciones requieren un m odelado del fu jo de con
trol adem ás del m odelado del flujo de inform ación.
La notación gráfica que se requiere para crear un dia
grama de flujo de control ( DFC) y a ha sido presentada
en la S ección 12.4.4. R eco rd an d o la fo rm a en que se
crea un D FC , lo prim ero es «elim inar» del m odelo de
flujo de datos todas las flechas de flujo de datos. L u e
go, se añaden al diagram a los sucesos y los elem entos
FIGURA 12.20. DFD de nivel 1 para H o g a r S e g u r o . d e c o n tro l (fle c h a s co n lín e a d isc o n tin u a ), así c o m o
« v entanas» (barras verticales) a las especificaciones de
Se debe ten er en cuen ta que en tre los niveles O y 1
control. Pero, ¿cóm o se seleccionan los sucesos?
se ha m anten id o la co n tin u id a d del flu jo de in fo rm a
ción. Se pospone h asta la Sección 12.7 la elaboración
de los contenidos de las en trad as y las salid as de los E s ta d o d e la a c c ió n
d e v is u a liz a c ió r
DFD de niveles O y 1. (te r m in a d a , e n m a rc h a )
Escierto que el proceso narrativopretende onalizor

lo escrito siempre con el mismo nivel de abstracción.
Se pueden refin ar en p o steriores niveles los p ro ce

sos representados en el D F D de nivel 1. P or ejem plo,
se puede refinar el proceso monitorizar sensores al D FD
de nivel 2 que se m u estra en la F ig u ra 12.21. Podem os
observar de nuevo que se m antiene la continuidad del
flujo de inform ación en tre los niveles.
El refinam iento de los D FD s continúa h asta que cada
burbuja rep resen ta un a función sencilla.
InfornruaaDínmdel sensor
T ip o F IG U R A 12 .22. DFD de nivel I para H o g a r S e g u r o .

de a la rm a
Inform ación de config u ra c ió n I \ v is u a liza c ió r
Ya hem os señalado que los sucesos o los elem entos
Id e n t if ic a c ió 'n T ^ ^ ' f G en e ra r de control se im plem entan com o valores lógicos (por
del tip o [ señal ejem plo, verdadero o fa ls o , si o no, 1 ó 0) o com o una
y u b ic a c ió n / \ d e a la rm a
v d e sensor lista discreta de co n d icio n es (vacía, atascada, llena).
D atos D atos P ara seleccionar posibles candidatos a sucesos, se p u e
de c o n figuración C o m p ro b a r , de a larm a den sugerir las siguientes directrices:
con los v alo re s « L istar todos los sensores que son «leídos» p o r el soft
iniciales
N ú m e ro ware.
de teléfo n o
• L istar todas las condiciones de interrupción.
T ip o de id. V \
V de s en s o r • L istar todos los «interruptores» que son accionados
1 I/ ..
M a rc a r
\
\
l censores
• l n ú m e ro I p o r el operador.
• L istar todas las condiciones de datos.
• De acuerdo con el análisis de nom bres y verbos que
www.FreeLibros.org
" Estado del sensor T o n o s d e l n ú m e ro d e te lé fo n o A
se ap lic ó a la n a rra tiv a de p ro c e sa m ie n to , rev isa r
FIGURA 12 .21. DFD de nivel 2 que refina el proceso to d o s los « e le m e n to s de c o n tro l» co m o po sib les
m o n ito r iz a r s e n s o re s . entradas/salidas de ECs.
213
IN GE NI E RÍ A DEL SOF TW ARE . UN E N F O Q U E P R Á C T I C O
• D e sc rib ir el c o m p o rtam ien to del sistem a id e n tifi L a Figura 12.23 refleja un diagram a de transición de
cando sus estados; identificar có m o se alcanza cada estados para el m odelo de flujo de nivel 1 de HogarSegu
estad o y d efinir las transiciones en tre los estados. ro. Las flechas de transición etiquetadas indican cóm o ies-
« C entrarse en las posibles om isiones —un e rro r m uy ponde el sistem a a los sucesos a m edida que pasa por los
co m ú n en la especificación del control (por ejem plo, cuatro estados definidosen este nivel. Estudiando el DTE,
p reguntarse si existe alguna otra form a en la que se un ingeniero del softw are puede determ inar el comporta
puede llegar a un estado o salir de él)— . m iento del sistem a y, lo que es m ás im portante, compro
bar si hay «lagunas» en el com portam iento especificado.
¿Cómo seleccionas eventos U na representación algo diferente del m odo de com
§ potenciales para DFC, DTEy EC?
En la Figura 12.22 se ilustra un D FC de nivel 1 para el

softw are H ogarSeguro. Entre los sucesos y los elem entos
portam iento es la tabla de activación de p ro ceso s (TAP).
L a TAP representa la inform ación contenida en el DTE
dentro del contexto de los procesos, no de los estados.
E s decir, la ta b la in d ic a los p ro c eso s (b u rb u jas) del
m o d e lo de flu jo que serán in v o cad o s c u an d o se pro
de control que aparecen están suceso de sensor (por ejem
plo, un sensor ha detectado una anom alía), indicador de d uzca un suceso. Se puede u sar la TA P com o una guía
parpadeo (una señal para que el m onitor L C D parpadee), para el diseñador que tenga que construir un controla
e interruptor de comienzo/parada (una señal para encen d or que controle los procesos represen tad o sen ese nivel.
der y apagar el sistema). Un suceso fluye a una ventana E n la F igura 12.24 se m u estra u n a TA P para el modelo
EC desde el m undo exterior, ello im plica la activación por de flujo de nivel 1 de H ogarSeguro.
la EC de uno o m ás procesos de los que aparecen en el La EC describeel com portam ientodel sistem a,pero no
DFC. C uando un elem ento de control em ana de un pro nos proporciona información sobre el funcionamientointer-
ceso y fluye a una ventana EC, ello im plica el control y la no de los procesos que son activados com o resultado de ese
activación de algún proceso o de una entidad externa. comportamiento. En la siguiente sección se estudia la nota
ción del m odelado que proporciona esa información.
Interruptorde comienzo/parada
Invocar monitor y control
del sistema Leyendo
12.6.5. l a e s p e c if ic a c ió n d e l p r o c e s o
entrada Se usa la especificación de proceso (EP) para describir
del usuario
todos los procesos del m odelo de flujo que aparecen en
Exceso de tiempo
Suceso de sensor Invocarinteractuar
el nivel final de refinam iento. El contenido de la espe
Invocar monitorizar con el usuario cificación de procesam iento puede incluir una narrati
y controlarel sistema va te x tu al, una d e scrip ció n en lenguaje de diseño de
Monitorización Actuando
pro g ra m a s (L D P ) del algoritm o del proceso, ecuacio
del estado sobre un suceso
del sistema
ilrin ’ Suceso
Invocar
de sensor
visualizar mensaje
de sensor nes m atem áticas, tablas, diagram as o gráficos. Al pro
p o rc io n a r una E P que a co m p añ e cad a b u rb u ja del
y estado
Sucesode sensor
m o d e lo de flu jo , el in g e n ie ro del so ftw are crea u n a
Suceso de sensor «m ini-especificación» que sirve com o prim er paso para
Invocar visualizar
Invocar monitorizary controlarsistema
mensaie v estado la creación de la E specificación de R e q u isito s del Soft
Mostrando ware y constituye una guía para el diseñ o de la compo
realimentación
al usuario Estadode la acción nente de program a que im plem entará el proceso.
Indicadorde parpadeo de visualización
Sucesos de entrada
Suceso de sensor 0 0 0 0 1 0
Indicador de parpadeo 0 0 1 1 0 0
Interruptor de comienzo/parada 0 1 0 0 0 0
Estado de la acción de visualización
Terminada 0 0 0 1 0 0
12.6.4. l a e s p e c if ic a c ió n d e c o n tro l En marcha 0 0 1 0 0 1
Exceso de tiempo 0 0 0 0 0 1
La especificación de control (EC) re p re se n ta el c o m
p o rta m ie n to del sistem a (al n iv el al que se ha h echo Salida
referencia) de dos fo rm as d iferen tes. L a E C contiene Señal de alarma 0 0 0 0 1 0
un d ia g ra m a de tra n sic ió n de esta d o s (D T E ) que es
Activación de procesos
u n a e sp e c ific a c ió n secuencia1 del co m p o rta m ie n to .
Monitorizarycontrolar el sistema 0 1 0 0 1 1
T am b ién p u ed e c o n te n e r una ta b la de a c tiv a c ió n de
Activar/desactivar el sistema 0 1 0 0 0 0
p ro c e so s (T A P ) — una especificación com binatoria del Visualizar mensajes y estado 1 0 1 1 1 1
com portam iento — . E n la Sección 12.4.4. se p resen ta lnteractuar con el usuario 1 0 0 1 0 1
www.FreeLibros.org
ron los a trib u to s in h e re n te s de la EC . A h o ra es el
m om ento de ex am in ar un ejem plo de esta im portante F IG U R A 1 2 .2 4 . Tabla de activación de procesos para
notació n del m odelado del análisis estructurado. HogarSeguro.
214
CA PÍ T U L O 12 M O D E L A D O DEL ANÁLISIS
Para ilu strar el uso de la E P considerem os el p ro ce ta se c u n d a ria d e c o n tra s e ñ a s (e s ta s p u e d e n a s ig n a rs e a

in v ita d o s o tra b a ja d o re s q u e n e c e s ita n e n tr a r e n la c a sa
so que representa la tran sfo rm ació n del m odelo de flu
c u a n d o el p ro p ie ta rio n o e s tá p re s e n te ). Si la c o n tra s e ñ a
jo de H o g a rseg u ro (F ig u ra 12.20). L a E P para e sta
c o in c id e c o n a lg u n a de las de la lis ta , c c o n tr a s e ñ a v a li
función puede to m ar la siguiente form a: d a d a = tru e > es p a sa d a a la fu n c ió n v is u a liz a r m e n s a je s
EP: p ro ceso y e sta d o . Si no e x is te c o in c id e n c ia , < c o n tr a s e ñ a v a lid a
d a = f a l s o se p a sa a la fu n c ió n v is u a liz a r m e n s a je s y
P ro c e sar la c o n tra s e ñ a lle v a a c a b o la v a lid a c ió n de
e sta d o .
.todas las c o n tra s e ñ a s d el siste m a H o g a r S e g u r o . P r o c e
sar la c o n tra se ñ a re cib e una c o n tra s e ñ a de 4 d íg ito s d e s Si en e sta e ta p a se d e se a in c lu ir d e ta lle s a lg o r ít
de la fu n c ió n in te ra c tu a r c o n el u su a rio . L a c o n tra s e ñ a m ico s ad icio n ales, se puede in clu ir c o m o p a rte de la
prim ero se c o m p a ra c o n la c o n tra s e ñ a m a e s tra a lm a c e
E P su rep rese n tació n en lenguaje d e d e s c rip c ió n de
nada e n el siste m a . Si al c o n tr a s ta r c o n la c o n tra s e ñ a
m aestra, < co n tra se ñ a v a lid a d a = tru e > se p a sa a la fu n
p rogram a. Sin em bargo, m uchos p ie n sa n que se d eb e
ción v isu a liz a r m e n s a je s y e sta d o . Si la c o m p a ra c ió n no p o sp o n e r la v e rsió n e n L D P h a sta q u e c o m ie n c e el
es co rrecta, lo s c u a tro d íg ito s se c o m p a ra n c o n u n a lis diseño.
El m o d e l o d e a n á l i s i s a c o m p a ñ a r e p r e s e n t a c i o n e s d e cóm o lo usan (por ejem plo, com o entrada al proceso,

o b je t o s d e d a t o s , f u n c i o n e s y c o n t r o l . E n c a d a r e p r e co m o salida del p ro ceso , co m o alm acén de d a to s,
s e n t a c ió n l o s o b j e t o s d e d a t o s y / o e l e m e n t o s d e c o n t r o l com o entidad externa).
ju e g a n un p a p e l i m p o r t a n t e . P o r c o n s i g u i e n t e , e s n e c e • D escripción del contenido— el contenido rep resen
s a r io p r o p o r c i o n a r u n e n f o q u e o r g a n i z a d o p a r a r e p r e tado m ediante una notación.
s e n ta r la s c a r a c t e r í s t i c a s d e c a d a o b j e t o d e d a t o s y
. Inform ación a d i c io n a l- o tr a inform ación sobre los
e le m e n to d e c o n t r o l. E s t o s e r e a liz a c o n e l d ic c io n a r io
tipos de datos, los valores im plícitos (si se conocen),
de d a to s .
las restricciones o lim itaciones, etc.
S e h a p r o p u e s t o e l d i c c i o n a r i o de d a t o s c o m o g r a
m á t ic a c a s i f o r m a l p a r a d e s c r i b i r e l c o n t e n i d o d e l o s U n a v e z que se in tro d u c e n en el d ic c io n a r io de
o b je t o s d e f i n i d o s d u r a n t e e l a n á l i s i s e s t r u c t u r a d o . E s t a d ato s un n o m b re y sus alias, se d eb e re v isa r la c o n
im p o r t a n t e n o t a c i ó n d e m o d e l a d o h a s i d o d e f i n i d a d e l a siste n cia de las d en o m inaciones. E s decir, si un e q u i
s ig u ie n t e f o r m a [ Y O U 8 9 ] : po de análisis decid e d en o m in a r un elem en to de datos
El diccionario de datos es un listado organizado de todos
rec ié n d e riv a d o c o m o x y z , p ero en e l d ic c io n a rio y a
los elementos de datos que son pertinentes para el sistema, con e x iste o tro lla m a d o x y z , l a h e rra m ie n ta C A S E que
definiciones precisas y rigurosas que permiten que el usuario so p o rta el d ic c io n a rio m u e stra un m e n sa je de a le rta
y el analista del sistema tengan una misma comprensión de las so b re la d u p lic id a d de n o m b res. E sto m e jo ra la c o n
entradas,salidas.de las componentesde los almacenesy [tam s is te n c ia d e l m o d e lo de a n á lis is y a y u d a a re d u c ir
bién] de los cálculos intermedios. erro res.
L a in fo rm ac ió n de « d ó n d e se u sa/có m o se usa» se
^ ¿Cómo representar
re g istra a u to m á tic a m e n te a p a rtir de los m o d e lo s de
* el contenido de los objetos
flujo. C u an d o se c re a u n a e n tra d a del d ic c io n a rio , la
de datos que han sido
h e rra m ie n ta C A S E in sp e c c io n a lo s D F D y los D FC
identificados?
p a ra d e te rm in a r lo s p ro c e s o s q u e u sa n el d a to o la
A c tu a lm e n te , c a s i s ie m p r e s e im p le m e n t a e l d i c in fo rm ac ió n de c o n tro l y c ó m o lo usan. A u n q u e esto
c io n a r io d e d a t o s c o m o p a r t e d e u n a « h e r r a m ie n t a p u eda no p are c e r im p o rtan te, re a lm e n te es u n a de las
CASE d e a n á l i s i s y d i s e ñ o e s tru c tu ra d o s» . A u n q u e m a y o re s v e n ta ja s del d ic c io n a rio . D u ra n te el a n á li
el f o r m a t o d e l d i c c i o n a r i o v a r í a e n t r e l a s d i s t i n t a s sis, hay u n a c o rrie n te c asi c o n tin u a de cam b io s. P a ra
h e r r a m ie n ta s , la m a y o r í a c o n t ie n e la s ig u ie n t e i n f o r p royectos g randes, a m enudo es bastante d ifícil d e te r
m a c ió n : m in a r e l im p a c to de un cam b io . A lg u n as de las p re
g u n ta s que se p la n te a el in g e n ie ro del so ftw a re so n
• nombre— e l n o m b r e p r i n c i p a l d e l e l e m e n t o d e d a t o s
« ¿dónde se usa este elem en to de datos? ¿qué m as hay
o d e c o n t r o l, d e l a lm a c é n d e d a to s , o d e u n a e n tid a d
que c a m b ia r si lo m o d ificam o s? ¿cuál será el im p a c
e x te rn a .
to g e n e ra l del cam b io ?» . Al p o d er tra ta r el d ic c io n a
• a lia s — o t r o s n o m b r e s usados p a ra la p r im e r a rio de datos com o una base de datos, el an alista puede
www.FreeLibros.org
e n tra d a . h a c e r p re g u n ta s b a sa d a s en « d ó n d e se u sa /c ó m o se
• d ó n d e s e usa!cómo se u s a — u n l i s t a d o d e l o s p r o c e usan y o b te n e r re sp u e stas a p eticio n e s sim ila re s a las
so s q u e u s a n e l e le m e n to d e d a to s o d e c o n t r o l y an te rio res.
215
P a r a ilu s t r a r e l u s o d e l d ic c io n a r io d e d a to s , v o lv a
m o s a l D F D d e n i v e l 2 y d e l p r o c e s o m o n i t o r i z a r e l s is
t e m a d e H ogarSeguro, m o s t r a d o e n l a F i g u r a 1 2 .2 1 .
R e f i r i é n d o n o s a l a f i g u r a , e s p e c i f i c a m o s e l e l e m e n t o de
Herramientas CASE d a t o s n ú m e ro d e teléfono. ¿ Q u é e s e x a c t a m e n t e un
Análisis Estructurado n ú m e r o d e t e l é f o n o ? P u e d e s e r u n n ú m e r o l o c a l d e sie
t e d í g i t o s , u n a e x t e n s i ó n d e 4 d í g i t o s , o u n a s e c u e n c ia
L a n o tació n u tilizad a p ara desarro llar u n a descrip d e 2 5 d í g it o s p a r a lla m a d a s d e la r g a d is t a n c ia . E l d ic
ción de contenido se in d ica en la siguiente tabla: c io n a r io d e d a to s n o s p r o p o r c io n a u n a d e f in ic ió n p re
c i s a d e núm ero de teléfono p a r a e l D F D e n c u e s t ió n .
C onstrucción N otación Significado
A d e m á s , i n d i c a d ó n d e y c ó m o s e u s a e s t e e l e m e n t o de
de datos d a t o s y c u a l q u i e r i n f o r m a c i ó n a d i c i o n a l q u e l e s e a r e le
A gregación - está com puesto de v a n t e . L a e n t r a d a d e l d i c c i o n a r i o d e d a t o s c o m i e n z a de
la s ig u ie n te f o r m a :
Secuencia + Y
Selección ti] uno u otro nom bre: núm ero de teléfono
alias: ninguno
R epetición t 1" n repeticiones de
dónde se usa/cóm o se asa: com probar con ajustes inicia
o datos opcionales les (salida)
* * delim itadores m arcar núm ero (entrada)
de com entarios descripción:
núm ero de teléfono = prefijo + núm ero de acceso
L a no tació n p erm ite al ingeniero del softw are rep re prefijo = l * un n úm ero de cuatro dígitos que comience en
sentar una com po sició n de datos en una de las tres alter 0 Ó un núm ero de cinco dígitos que com ience por 0]
nativas fu ndam entales que p u ed en ser construidas núm ero de acceso = *secuencia num érica de cualquiertama-
1. C om o u n a secuencia de elem entos de datos. ño*
2. C o m o u n a selección de en tre un c o n ju n to de e le U n n ú m e r o c o m o e l O 1 3 2 7 5 4 6 3 8 1 q u e d a d e s c r it o
m entos de datos. d e e s ta fo r m a .
3. Com o una agrupación repetitiva de elem entos de datos. P a r a g r a n d e s s is t e m a s b a s a d o s e n c o m p u t a d o r a e l
C ada entrada de elem ento de datos que aparezca com o d ic c io n a r io d e d a to s c re c e r á p id a m e n te e n ta m a ñ o y en
parte de una secuencia, una selección o una repetición c o m p l e j i d a d . D e h e c h o , e s e x t r e m a d a m e n t e d i f í c i l man
puede a su vez ser otro elem ento de datos com puestos t e n e r m a n u a l m e n t e e l d i c c i o n a r i o . P o r e s t a r a z ó n , se
que necesite un m ayor refinam iento en el diccionario. d e b e n u s a r h e r r a m ie n ta s C A S E .
12J3 Q.TEQS MÉ TO D O S C L Á SIC O S D E A N Á U S IS

D urante lo s últim os años se han u tilizado otros m éto • Técnicas de análisis y diseño estructurado (TADE)
dos v aliosos de análisis de requisitos del softw are en la [R O S77, R O S85] "
industria. M ientras que tod o s siguen los principios del son presentadas dentro del sitio w eb SEPA para los lecto
análisis o p eracional tratados en el C apítulo 11, cada uno res interesadosen profundizar en el m odelado del análisis.
introduce una notación y heurística d iferen tesp ara cons
tru ir el m odelo de análisis. U na rev isió n de t r e s im por
tantes m étodos de análisis:
• D esarrollo de sistem as estructurados de datos
(DSED) [W A R 81, O R R 8 1]
• Desarrollo de sistemas Jackson í7FS'./j[JAC83 j DSSD, ISD, y SADT
ja m iM E N .
El análisis estructurado es el m étodo m ás usado para el de todos los objetos de datos que son im portantes para
m odelado de requisitos, u tiliza el m odelo de datos y el el sistem a. L os sistem as de datos y flujo de control son
www.FreeLibros.org
m o d elo de flu jo s p a ra c re a r la base de u n ad e cu a d o la base de representación de la transform ación de datos
m odelo de análisis. U tilizando el diag ram a entidad-rela y control. Al m ism o tiem po, estos m étodos son usados
ción, el ingeniero del softw are crea una representación para crear un m odelo funcional del softw are y proveer
216
C A P Í T U L O 12 M O D E L A D O DEL ANÁLISIS
se de un m ecanismo para dividir funciones. Después, de datos convencionales, pero ahora hay am pliacio
Crea un modelo de comportamiento usando el diagra- nes que perm iten aplicar el m étodo a los sistem as de
ília de transición de estados y un m odelo de contenido tiem po real.
de los datos con un diccionario de datos. Las especifi- El análisis estru ctu rad o está soportado p o r una
cacicnes de los procesos y del control proporcionan una larga lista de h erram ien tas CA SE que ayudan en la
Elaboración adicional de los detalles. c re a c ió n de cada elem e n to del m o d elo y tam b ién
La notación original para el análisis estructurado en el m a n te n im ie n to de la c o n s is te n c ia y de la
fue desarrollada para aplicaciones de procesam iento corrección.
I,... O E M L d A S L ~ _ ■_ ~ .......
(BRU88] Bruyn, W. et al., «ESML: An Extended Systems |ROS77] Ross, D., y K. Schoman, «Structured Analysis for
Modeling Language Based on the Data Flow Diagram», Requirements Definitions», IEEE Trans. Software Engi-
ACM Software Engineeri'ng Notes, vol. 13,n.° 1, Enero neering, vol. 3, n." 1, Enero 1977,pp. 6-15.
’ 1988,pp. 58-67. [ROS84] Ross, D., «Applications and Extensions of SADT»,
[CHE77] Chen, P., The Entity-Relationship Approach toLogi- IEEE Computer, vol. 18,n.° 4, Abril 1984,pp. 25-35.
calDatahase Design, QED Information systems, 1977/ [STE74] Stevens, W.P., G.J. M yers y L.L. Constantine,
[DEM79] DeMarco, T., StructuredAnalysis and System Spe- «Structured Design», IBM Systems Journal, vol. 13,n.°2,
, cificaction, Prentice-Hall, 1979. 1974,pp. 115-139.
[GAN82] Gane, T., y C. Sarson, Structured System s,Analy [TIL93] Tillman, G.A.,H Practical Guide to Logical Data
sis, McDonnell Douglas, 1982. Modeling, McGraw-Hill, 1993.
[HAT87] Elatley, D.J., e I.A. Pirbhai, Strategies fo r Real- [WAR81] Wamier, J.D., Logical Construction o f Programs,
Time System Specification, Dorset House, 1987. Van Nostrand Reinhold, 1981.
[JAC83] Jackson, M.A., System Development, Prentice-Hall, [WAR85] Ward, P.T., y S. J. Mellor, Structured Development
1983. fo r Real-Tune Systems, tres volúmenes, YourdonPress, 1985.
[0RR81] Orr, K.T., StructuredRequirements Definition, Ken [YOU78] Yourdon, E.N., y L.L. Constantine, Structured
Orr & Associates, Inc., Topeka,KS, 1981. Design, Yourdon Press, 1978.
(PAG80] Page-Jones, M., The Practical Guide to Structured [YOU89] Yourdon,E.N., Modern Structured Analysis, Pren-
Systems Design, YourdonPress, 1980. tice Hall, 1990.
L : .. EM • ’ 2RAR
121. Obtenga al menos tres de las diferencias que se men 12.4. Dibuje un modelo de nivel de contexto (DFD de nivel
cionan en la sección 12.1 y escriba un breve artículo que 0) para uno de los cinco sistemas que se listan en el problema
refleje el cambio a lo largo del tiempo de la concepción 12.2. Escriba una descripción de procesamiento a nivel de con
del análisis estructurado. En una sección de conclusiones, texto para el sistema.
Sugiera formas en las que crea que cambiará el método en 12.5. Mediante el DFD de nivel de contexto desarrollado en
el futuro. el problema 12.4, desarrolle diagramas de flujo de datos de
122. Se le pide que constmya uno de los sistemas siguientes: nivel 1y nivel 2. Utilice un «analizador gramatical» en la des
a un sistema de registro en cursos basado en red para su uni cripción de procesamiento a nivel de contexto para que se ini
versidad cie en ese tema. Recuerde especificar todo el flujo de
información etiquetando todas las flechas entre burbujas. Uti
b. un sistema procesamiento de transacciones basado en inter
lice nombres significativos para cada transformación.
net para un almacén de computadoras
c. un sistema simple de facturas para una empresa pequeña 12.6. Desarrolle DFC, EC, E P y un diccionario de datos para
el sistema que seleccionó en el problema 12.2. Intente cons
d. un producto de software que sustituya a rolodex construi truir su modelo tan completo como sea posible.
do en un teléfono inalámbrico
12.7. ¿Significa el concepto de continuidad del flujo de infor
e. un producto de libro de cocina automatizado constmido en
mación que si una flecha de flujo aparece como entrada en el
una cocina eléctrica o en un microondas
nivel 0, entonces en los subsiguientes niveles debe aparecer
Seleccione el sistema que le sea de interés y desarrolle un una flecha de flujo como entrada? Explique su respuesta.
diagtama entidad-relación que describa los objetos de datos,
www.FreeLibros.org
relaciones y atributos. 12.8. Usando las ampliaciones de Ward y Mellor descritas en
las figuras 12.13.¿Cómo encaja la EC que se indica en la figu
122 ¿Qué diferencia hay entre cardinalidad y modalidad? ra 12.13? Ward y Mellor no usan esa notación.
217
INGE NIE RÍA DEL SOF TW ARE . UN E N F O Q U E P R Á C T I C O
12.9. Usando las ampliaciones de Hatley y Pirbhai, rehaga el (determinada a partir de su tamaño). A cada bache se le
modelo de flujo contenido en la Figura 12.13. ¿Cómo encaja asocian datos de petición de obra, incluyendo la ubicación
el modelo de control que se indica en la Figura 12.13? Flatley y el tamaño, la brigada, el equipamiento asignado,lashoras
y Pirbhai no usan esa notación. de reparación, el estado del bache (obra en curso, reparaj
12.10. Describa con sus propias palabras un flujo de sucesos. do, reparación temporal, no reparado), la cantidadde mate-,
rial de relleno usado y el coste de la reparación (calcula&
12.11. Desarrolle un modelo de flujo completo para el soft con las horas dedicadas, el número de trabajadores, el mate
ware de fotocopiadora discutido en la sección 12.5. Puede uti rial y el equipamiento usados). Finalmente, se crea un archi
lizar las ampliaciones de Ward y M ellor o las de Hatley y vo de daños para mantener la información sobre losdañof
Pirbhai. Asegúrese de desarrollar para el sistema un diagrama reportados debidos a la existencia del bache, incluyendo
de transición de estados detallado. el nombre del ciudadano, su dirección, su número de telé
12.12. Complete la descripción de procesamiento para el soft fono, el tipo de daño y el coste de subsanamiento del cafa
ware HogarSeguro que se ha presentado en la Figura 12.20; El sistema SSRB es un sistema interactivo.
describiendo los mecanismo de interacción entre el usuario y Utilice el análisis estructurado para modelar SSRB.
el sistema. ¿Cambiará su información adicional los modelos
de flujo de HogarSeguro que aparecen en este capítulo? Si es 12.14. Se va a desarrollar un sistema de procesamientocb tex
así, ¿cómo? tos basados en computadoraspersonales. Investiguedurantealgu-
nas horas sobre el área de aplicación y lleve a cabo una reunión
12.13. El departamento de obras públicas de un gran ciudad TFEA (Capítulo 1l)con sus compañerosde clase para un mode
ha decidido desarrollar un sistema de seguimiento y repara lo de requisitos del sistema utilizando el análisis estructurado (su
ción de baches (SSRB)basado en página web. Con los siguien profesor le ayudará a coordinarlo). Constmya un modelo de requi
tes requisitos: sitos del sistema mediante el análisis estructurado.
Los ciudadanos pueden conectarse a la página e infor
12.15. Se va a desarrollar el software para un videojuego. Pro
mar sobre la situación y la importancia del bache. Amedi-
ceda como en el problema 12.14.
da que se informa sobre cada bache, se le asigna un número
de identificación y se guarda con la calle en la que se 12.16. Contacte con cuatro o cinco vendedores de herramien
encuentra, su tamaño (en una escala de 1 a 10), su posi tas CASE para análisis estructurado. Revise sus folletosy escri
ción (en el medio, a un lado, etc.), su distrito (determina ba un breve artículo que resuma las características generales
do a partir de la calle) y una prioridad de reparación y las que se distingan a unas herramientas de las otras.
-Q.IfiAS LECTURAS .Y. FUEtU'ES. P £ II?lJFQB>M&.CXOlí..~„-.— — ,'üSI

Existen literalmente docenas de libros publicados sobre el aná Analysis and Design Methodology, Van Nostrand Reínhlod,
lisis estructurado. Todos cubren el tema de forma adecuada, 199Ó)y Hares (SSADMfor the Advanced Pructitioner, WDey,
pero sólo unos pocos constituyen magníficos trabajos. El libro 1990) describe SSADM como una variación del análisis
de DeMarco [DEM79] sigue siendo una buena introducción estructurado que se utiliza enormemente por toda Europa y
de la notación básica. Los libros de Floffer et al. (Modern Sys- Estados Unidos.
t.emsAnalysis and Design, Addison-Wesley, 2.a ed., 1998), Ken- Flynn et al. (Information Modelling: A n InternationalPers-
dall y Kendall (Systems Analysis and Design, 2.a ed., Prentice pective, Prentice Hall, 1996), R eingrubery Gregory (Data
Hall,1998), Davis y Yen (Thelnformation System Consultant’s Modeling Handhook, Wiley, 1995) y Tillman [TIL93] pre
Handhook: Systems Analysis and Design, CRCPress,1998), sentan manuales detallados para crear modelos de datos de
Modell (AProfessional’s Cuide to Systems Analysis, 2." ed., calidad de industria. Kim y Salvatores («Comparing Data
McGraw-Hill, 1996), Robertson and Robertson (Complete Sys Modeling Formalisms», Communications o f the ACM, June
tems Analysis, 2 vols., DorsetHouse, 1994), y Page-Jones (The 1995) han escrito una comparación excelente de métodos de
Practical Cuide to StructuredSystems Design, 2.a ed., Prenti modelado de datos. Un libro interesante de Hay (DataMode-
ce Hall, 1988) son referencias muy valiosas. El libro de Your- ling Patterns, Dorset House, 1995) presenta los «patrones#
don sobre este tema [YOU89] sigue siendo el tratado más comunes de modelos de datos que se encuentran en mucha
extenso publicado hasta la fecha. empresas diferentes. En Kowal (Behaviour Models: Speci-
Para mayor énfasis en la ingeniería, [WAR85] y [HAT87] fying User's Expectations, Prentice-Hall, 1992) se puede
son los libros preferidos. En cualquier caso, Edwards (Real- encontrar un tratamiento detallado del modelado de compor
Time StructuredMethods: SystemsAnalysis, Wiley, 1993) tra tamiento.
ta el análisis de sistemas en tiempo real con gran profundidad, Una amplía variedad de fuentes de información sobre
presentando diagramas de ejemplos Útiles sobre aplicaciones el análisis estructurado están disponibles en internet. Una
reales. lista actualizada de páginas web que son interesantes sobre
Se han desarrollado muchas variaciones sobre el análisis el concepto y m étodos de an álisis se encuentran en
estructuradodurantela última década. Cutts (StructuredSystems h ttp://w w w .pressm an5.com
C A P ÍT U L O
1 Q CONCEPTOS Y PRINCIPIOS
X 0 DE DISEÑO
L o b je tiv o d e lo s d iseñ ad o res es p ro d u c ir u n m o d e lo o re p re s e n ta c ió n de u n a e n tid a d q u e
E se será c o n s tru id a a p o s te rio ri. B e la d y d e s c rib e e l p ro c e s o m e d ia n te e l c u a l se d e s a rro

lla e l m o d e lo d e d is e ñ o [B E L 8 1 ] :
E n cu alq u ier p roceso de diseño ex iste n dos fases im portantes: la diversificación y la convergencia. L a
diversificación es la adquisición de un rep erto rio de alte rn a tiv a s, de un m aterial prim itivo d e diseño: c o m
ponentes, soluciones de com p o n en tes y c o n o cim ien to , todo d entro de catálo g o s, de lib ro s d e tex to y e n la
m ente. D u ran te la c o n v erg en cia, el d ise ñ ad o r elige y com b in a los elem en to s adecu ad o s y e x traídos de este
repertorio para satisfacer los objetivos del diseño, de la m ism a m anera a com o se establece e n el docum ento
de los requisitos, y de la m anera en que se acordó con el cliente. L a segunda fase es la elim inación gradual
de cu alq u ier configuración de com p o n en tes e xcepto de una en particular, y de aquí la creación del producto
final.
L a d iv e rs ific a c ió n y la c o n v e rg e n c ia c o m b in a n in tu ic ió n y ju i c i o e n fu n c ió n de la e x p e rie n
c ia e n c o n s tru ir e n tid a d e s s im ila re s ; u n c o n ju n to d e p rin c ip io s y /o h e u rís tic a q u e p ro p o rc io n a n
la fo r m a d e g u ia r la e v o lu c ió n d e l m o d e lo ; u n c o n ju n to d e c rite rio s q u e p o s ib ilita n la c a lid a d
qu e se v a a ju z g a r , y u n p ro c e s o d e ite ra c ió n q u e p o r Ú ltim o c o n d u c e a u n a re p re s e n ta c ió n fin a l
d e d is e ñ o .
VISTAZO RÁPIDO
¿Qué «*? El diseño es una representación como se aplican en la aplicación qué datos, la arquitectura del sistema, la
significativa de ingeniería de algo que se va a construir. En el nivel dé la inter representación dé la interfaz y los deta
se va a construir. Se puede hacer el faz, es la ergonótnica humana la que lles a nivel de componentes. Durante
seguimiento basándose en los requisi dicta nuestro enfoque de diseño. Y en cada una de las actividades del dise
tos del cliente, y al mismo tiempo la cali el nivel de componentes, un «enfoque ño, se aplican los conceptos y princi
dad se puede evaluar y cotejar con el de programación» conduce a diseños pios básicos que llevan a obtener una
conjunto de criterios predefinidos para de datos y procedimentales eficaces. alte li vad.
obtener un diseño «bueno». En el con ¿P er q u é e s im portante? Si se cons ¿Cuál e s e l p roducto ob ten id o? Por
texto de la ingeniería del software, el truye una casa, ¿se hace sin un plano? último se produce una especificación
diseño se centra en cuatro áreas impor Se correrían riesgos, se cometerían del diseño. La especificación se com
tantes de interés: datos, arquitectura, errores, habría un plano de casa sin pone de ios modelos del diseño que
interfaces y componentes. En estas cua sentido, con ventanas y puertas en describen ios datos, arquitectura, inter
tro áreas se aplican los principios y con - sitios equivocados... un desastre. El faces y componentes. Cada una de
ceptos que se abarcan en este capítulo software de computadora es conside estas partes es lo que forma el produc
¿Quién lo h a c e ? El ingeniero del soft rablemente más complejo que una to obtenido del proceso de diseño.
ware es quien diseña los sistemas casa, de aqui que necesitemos un pla ¿Céuto p u ed o - dar seg u r d e q u e lo
basados en computadora, pero los no —el diseño—. h e h ech o correctam ente? ti» cada
conocimientos que se requieren en ¿ C u á les s e n lo s p a so s? El diseño etapa se revisan los productos del dise
cada nivel de diseño funcionan de dife comienza con el modelo de los requi ño del software en cuanto a claridad,
rentes maneras. En el nivel de datos y sitos. Se trabaja por transformar este corrección, finalización y consistencia,
de arquitectura, el diseño se centra en modelo y obtener cuatro niveles de y se comparan con los requisitos y unos
los patrones de la misma manera a detalles de diseño: la estructura de con otros.
E l d is e ñ o d e l s o ftw a re , a l ig u a l q u e lo s e n fo q u e s d e d is e ñ o d e in g e n ie ría e n o tras d is c ip li

nas, v a c a m b ia n d o c o n tin u a m e n te a m e d id a que se d e s a rro lla n m é to d o s n u e v o s , a n á lis is m e jo
re s y se a m p lia e l c o n o c im ie n to . L a s m e to d o lo g ía s d e d is e ñ o d e l s o ftw a r e c a re c e n d e la
p ro fu n d id a d , fle x ib ilid a d y n a tu ra le z a c u a n tita tiv a q u e se a s o c ia n n o rm a lm e n te a las d is c ip li
nas d e d is e ñ o d e in g e n ie ría m á s clásicas. S in e m b a rg o , sí e x is te n m é to d o s p a ra e l d is e ñ o d e l
s o ftw a re ; ta m b ié n se d is p o n e d e c a lid a d d e d is e ñ o y se p u e d e n a p lic a r n o ta c io n e s d e d is e ñ o .
E n este c a p ítu lo se e x p lo ra rá n lo s c o n ce p to s y p rin c ip io s fu n d a m e n ta le s q u e se p u e d e n a p lic a r
www.FreeLibros.org
a to d o d is e ñ o d e s o ftw a re . E n lo s C a p ítu lo s 1 4 , 1 5 , 1 6 y 2 2 se e x a m in a n d iv e rs o s m é to d o s de
d is e ñ o d e s o ftw a re e n c u a n to a la m a n e ra e n q u e se a p lic a n a l d is e ñ o a rq u ite c tó n ic o , de in te r
fa z y a n iv e l d e c o m p o n e n te s .
219
IN GENIERÍA DEL S O F TW A R E . UN E N F O Q U E P R Á C T I C O
— -3-.1DISEÑQ DEL SOFTWARE 1É IKGEKÍEBfA DEí. SOFTWARE

E l d is e ñ o d e l s o ftw a r e s e e n c u e n tr a e n e l n ú c le o t é c n i
c o d e la in g e n ie r í a d e l s o f t w a r e y s e a p lic a in d e p e n
d ie n te m e n te d e l m o d e lo d e d is e ñ o d e s o ftw a r e q u e se
u t ilic e . U n a v e z q u e s e a n a liz a n y e s p e c if ic a n lo s r e q u i
s ito s d e l s o f t w a r e , e l d is e ñ o d e l s o f t w a r e e s la p r im e r a
d e la s t r e s a c t i v i d a d e s t é c n i c a s - d i s e ñ o , g e n e r a c i ó n d e
c ó d ig o y p r u e b a s — q u e s e r e q u ie r e n p a r a c o n s t r u ir y
v e r if ic a r e l s o ftw a r e . C a d a a c tiv id a d t r a n s f o r m a la i n f o r
m a c ió n d e m a n e r a q u e d é lu g a r p o r ú lt im o a u n s o f t
w a r e d e c o m p u ta d o r a v a lid a d o .
Ss ' í s f tas comunes de la ingeniería

li|É ÍN |S o n las fransieiones desde el análisis
y desde el diseño al código.
C a d a u n o d e lo s e le m e n to s d e l m o d e lo d e a n á li El modelo de diseño
s is ( C a p í t u l o 1 2 ) p r o p o r c i o n a l a i n f o r m a c i ó n n e c e
s a r ia p a r a c r e a r lo s c u a t r o m o d e lo s d e d is e ñ o q u e s e F IG U R A 1 3 .1 . Conversión del m odelo de análisis
r e q u ie r e n p a r a u n a e s p e c if ic a c ió n c o m p le t a d e d is e en un diseño de software.
ñ o . E l f l u jo d e in f o r m a c ió n d u r a n te e l d is e ñ o d e l s o f t
w a r e s e m u e s t r a e n l a F i g u r a 13.1. L o s r e q u i s i t o s d e l E l diseño de la in terfa z d e s c r i b e l a m a n e r a d e
s o f t w a r e , m a n if e s t a d o s p o r lo s m o d e lo s d e d a to s f u n c o m u n i c a r s e e l s o f t w a r e d e n t r o d e s í m i s m o , c o n s is
c io n a le s y d e c o m p o r t a m ie n t o , a lim e n t a n la ta r e a d e l t e m a s q u e i n t e r o p e r a n d e n t r o d e é l y c o n la s p e r s o n a s
d is e ñ o . M e d ia n t e u n o d e lo s m u c h o s m é t o d o s d e d is e q u e l o u t i l i z a n . U n a i n t e r f a z i m p l i c a u n f l u j o d e in f o r
ñ o ( q u e s e a b a r c a r á n e n c a p í t u lo s p o s t e r io r e s ) la ta r e a m a c ió n ( p o r e je m p lo , d a to s y / o c o n t r o l) y u n t ip o e sp e
d e d is e ñ o p r o d u c e u n d is e ñ o d e d a to s , u n d is e ñ o c í f i c o d e c o m p o r t a m ie n t o . P o r t a n t o , lo s d ia g r a m a s
a r q u it e c t ó n ic o , u n d is e ñ o d e in t e r f a z y u n d is e ñ o d e d e f l u j o d e c o n t r o l y d e d a t o s p r o p o r c io n a n g r a n p a r
c o m p o n e n te s . t e d e l a i n f o r m a c i ó n q u e s e r e q u i e r e p a r a e l d i s e ñ o de
E 1 diseño de datos t r a n s f o r m a e l m o d e l o d e l d o m i la in t e r f a z .
n i o d e i n f o r m a c i ó n q u e s e c r e a d u r a n t e e l a n á l i s i s e n la s E l diseno a nivel de componentes t r a n s f o r m a lo s e le
e s tr u c tu r a s d e d a to s q u e s e n e c e s it a r á n p a r a im p le m e n - m e n t o s e s t r u c t u r a l e s d e l a a r q u i t e c t u r a d e l s o f t w a r e en
t a r e l s o f t w a r e . L o s o b j e t o s d e d a t o s y la s r e l a c i o n e s u n a d e s c r ip c ió n p r o c e d im e n t a l d e lo s c o m p o n e n te s d e l
d e f in id a s e n e l d ia g r a m a r e la c ió n e n tid a d y e l c o n t e n i s o f t w a r e . L a in f o r m a c ió n q u e s e o b tie n e d e E P , E C y
d o d e d a to s d e t a lla d o q u e s e r e p r e s e n ta e n e l d ic c io n a d e D T E s ir v e c o m o b a s e p a r a e l d is e ñ o d e lo s c o m p o
r i o d e d a to s p r o p o r c io n a n la b a s e d e la a c t iv id a d d e l n e n te s .
d is e ñ o d e d a to s . E s p o s ib le q u e p a r te d e l d is e ñ o d e d a to s L a im p o r t a n c ia d e l d is e ñ o d e l s o ftw a r e se p u e d e
te n g a lu g a r ju n t o c o n e l d is e ñ o d e la a r q u it e c t u r a d e l d e s c r i b i r c o n u n a s o l a p a l a b r a — calidad — . E l d is e
s o ftw a r e . A m e d id a q u e s e v a n d is e ñ a n d o c a d a u n o d e ñ o e s e l l u g a r e n d o n d e s e f o m e n t a r á l a c a l i d a d e n la
lo s c o m p o n e n te s d e l s o f t w a r e , v a n a p a r e c ie n d o m á s i n g e n i e r í a d e l s o f t w a r e . E l d i s e ñ o p r o p o r c i o n a las
d e ta lle s d e d is e ñ o . r e p r e s e n t a c io n e s d e l s o f t w a r e q u e s e p u e d e n e v a lu a r
E l diseño arquitectónico d e f i n e l a r e l a c i ó n e n t r e e n c u a n t o a c a lid a d . E l d is e ñ o e s la ú n ic a f o r m a de
lo s e le m e n to s e s tr u c tu r a le s ’ p r in c ip a le s d e l s o ftw a r e , c o n v e r t i r e x a c t a m e n t e l o s r e q u i s i t o s d e u n c l i e n t e en
lo s p a tr o n e s d e d is e ñ o q u e s e p u e d e n u t ili z a r p a r a u n p r o d u c t o o s i s t e m a d e s o f t w a r e f i n a l i z a d o . E l d is e
l o g r a r lo s r e q u i s i t o s q u e s e h a n d e f i n i d o p a r a e l s i s ñ o d e l s o f t w a r e s i r v e c o m o f u n d a m e n t o p a r a t o d o s los
t e m a , y la s r e s t r ic c io n e s q u e a f e c t a n a la m a n e r a e n p a s o s s i g u i e n t e s d e l s o p o r t e d e l s o f t w a r e y d e l a in g e
q u e s e p u e d e n a p lic a r lo s p a tr o n e s d e d is e ñ o a r q u i n i e r í a d e l s o f t w a r e . S i n u n d i s e ñ o , c o r r e m o s e l r ie s
te c tó n ic o s [ S H A 9 6 ] . L a r e p r e s e n ta c ió n d e l d is e ñ o g o d e c o n s t r u i r u n s i s t e m a i n e s t a b l e — u n s i s t e m a que
a r q u it e c t ó n ic o — e l m a r c o d e t r a b a jo d e u n s is t e m a f a l l a r á c u a n d o s e l l e v e n a c a b o c a m b i o s ; u n s is te m a
b a s a d o e n c o m p u t a d o r a — p u e d e d e r iv a r s e d e la e s p e q u e p u e d e r e s u l t a r d i f í c i l d e c o m p r o b a r ; y u n s is te m a
www.FreeLibros.org
c if ic a c ió n d e l s is t e m a , d e l m o d e lo d e a n á lis is y d e la c u y a c a lid a d n o p u e d e e v a lu a r s e h a s ta m u y a v a n z a d o
in t e r a c c ió n d e l s u b s is te m a d e f in id o d e n t r o d e l m o d e e l p r o c e s o , s i n t i e m p o s u f i c i e n t e y c o n m u c h o d in e r o
lo d e a n á lis is . g a s ta d o e n é l— .
220
C A P Í T U L O 13 C O N C E P T O S Y P R IN C IP IO S D E D ISE Ñ O
E l d is e ñ o d e l s o f t w a r e e s u n p r o c e s o i t e r a t i v o m e d i a n t e
•
¿Existen directrices
e l c u a l lo s r e q u i s i t o s s e t r a d u c e n e n u n « p l a n o » p a r a c o n s generales que lleven
t r u ir e l s o f t w a r e . I n ic i a lm e n t e , e l p la n o r e p r e s e n t a u n a a un buen diseño?
v is i ó n h o l í s t i c a d e l s o f t w a r e . E s t o e s , e l d i s e ñ o s e r e p r e
s e n ta a u n n i v e l a l t o d e a b s t r a c c i ó n - u n n i v e l q u e p u e d e 3 . U n d is e ñ o d e b e rá c o n te n e r d is tin ta s r e p r e s e n ta c io
ra s tre a rs e d i r e c t a m e n t e h a s t a c o n s e g u i r e l o b j e t i v o d e l s is n e s d e d a to s , a r q u it e c t u r a , in te r f a c e s y c o m p o n e n te s
te m a e s p e c í f i c o y s e g ú n u n o s r e q u i s i t o s m á s d e t a l l a d o s ( m ó d u lo s ) .
de c o m p o r ta m ie n to , fu n c io n a le s y d e d a to s — . A m e d id a 4 . U n d is e ñ o d e b e rá c o n d u c ir a e s tr u c tu r a s d e d a to s a d e
que o c u r r e n la s i t e r a c i o n e s d e l d i s e ñ o , e l r e f i n a m i e n t o c u a d a s p a r a lo s o b je t o s q u e s e v a n a im p le m e n t a r y
s u b s ig u ie n t e c o n d u c e a r e p r e s e n t a c i o n e s d e d i s e ñ o a n i v e q u e p r o c e d a n d e p a tr o n e s d e d a to s r e c o n o c ib le s .
le s d e a b s t r a c c i ó n m u c h o m á s b a j o s . E s t o s n i v e l e s s e
p o d rá n r a s tr e a r a ú n s e g ú n lo s r e q u is it o s , p e r o la c o n e x ió n 5 . U n diseño deberá c o n d u c i r a c o m p o n e n t e s q u e Pre"
senten características funcionales independientes.
es m á s s u t il .
6 . U n d is e ñ o d e b e r á c o n d u c ir a in te r f a c e s q u e r e d u z
c a n l a c o m p l e j i d a d d e la s c o n e x i o n e s e n t r e l o s m ó d u
13.2.1. D ise ñ o y c a li d a d d e l s o f tw a r e lo s y c o n e l e n t o r n o e x te r n o .
A lo la r g o d e t o d o e l p r o c e s o d e l d is e ñ o , la c a lid a d d e
7 . U n d is e ñ o d e b e r á d e r iv a r s e m e d ia n t e u n m é t o d o r e p e
la e v o l u c i ó n d e l d i s e ñ o s e e v a l ú a c o n u n a s e r i e d e r e v i
t i t iv o y c o n t r o la d o p o r la in f o r m a c ió n o b te n id a
s io n e s t é c n i c a s f o r m a l e s o c o n la s r e v i s i o n e s d e d i s e ñ o
d u r a n t e e l a n á lis is d e lo s r e q u is it o s d e l s o f t w a r e
a b o rd a d a s e n e l C a p í t u lo 8 . M c G la u g h lin [ M C G 9 ! ]
E s to s c r it e r io s n o s e c o n s ig u e n p o r c a s u a lid a d . E l p r o
s u g ie r e t r e s c a r a c t e r í s t i c a s q u e s i r v e n c o m o g u í a p a r a
c e s o d e d is e ñ o d e l s o ftw a r e fo m e n ta e l b u e n d is e ñ o a t r a
la e v a l u a c i ó n d e u n b u e n d i s e ñ o :
v é s d e la a p lic a c ió n d e p r in c ip io s d e d is e ñ o fu n d a m e n ta le s ,
• e l d is e ñ o d e b e r á im p le m e n t a r to d o s lo s r e q u is it o s
d e m e t o d o l o g í a s i s t e m á t i c a y d e u n a r e v i s i ó n c u id a d o s a .
e x p líc ito s d e l m o d e lo d e a n á lis is , y d e b e r á n a ju s ta r s e
a to d o s lo s r e q u is it o s im p lí c it o s q u e d e s e a e l c lie n t e ;
• e l d is e ñ o d e b e r á s e r u n a g u ía le g ib le y c o m p r e n s ib le
p a ra a q u e llo s q u e g e n e r a n c ó d i g o y p a r a a q u e llo s q u e ‘tíéfffes formas éconstruir un diseño de software:
c o m p ru e b a n y c o n s e c u e n te m e n te , d a n s o p o rte a l s o ft ' es hacer un diseño tan simple que no
w a re ; :•: oWafnente deficiencias, y la otra es hacer
M tÉ e flo fon complicado que no existan deficiencias
• e l d is e ñ o d e b e r á p r o p o r c io n a r u n a im a g e n c o m p le t a
o t ó : La primera forma es mucho más difícil.
d e l s o ftw a r e , e n fr e n tá n d o s e a lo s d o m in io s d e c o m
p o r ta m ie n to , f u n c io n a le s y d e d a to s d e s d e u n a p e r s -
13.2.2. L a e v o lu c ió n d e l d is e ñ o d e l s o f tw a r e
L a e v o lu c ió n d e l d is e ñ o d e l s o ftw a r e e s u n p r o c e s o c o n
ñtira lograr un buen diseño, hay que pensar t i n u o q u e h a a b a r c a d o la s ú l t i m a s c u a t r o d é c a d a s . E l p r i
•» 4 fíwnera correcta de llevar a cabo la actividad m e r tr a b a jo d e d is e ñ o s e c o n c e n tr a b a e n c r it e r io s p a r a e l
d e s a r r o llo d e p r o g r a m a s m o d u la r e s [ D E N 7 3 ] y m é to d o s
Kvtbarfe® Whifaíiead p a r a r e f i n a r la s e s t r u c t u r a s d e l s o f t w a r e d e m a n e r a d e s
c e n d e n te [ W I R 7 1 ] , L o s a s p e c to s p r o c e d im e n t a le s d e la
C o n e l f in d e e v a lu a r la c a lid a d d e u n a r e p r e s e n ta c ió n
d e f in ic ió n d e d is e ñ o e v o lu c io n a r o n e n u n a f ilo s o f í a d e n o -
de d is e ñ o , d e b e r á n e s t a b le c e r s e l o s c r i t e r i o s t é c n i c o s p a r a
n r in a d a p r o g r a m a c ió n e s tr u c tu r a d a [ D A H 7 1 , M I L 7 2 ] .
u n b u e n d i s e ñ o . M á s a d e la n t e e n e s t e m i s m o C a p í t u l o , s e
U n tr a b a jo p o s te r io r p r o p u s o m d to d o s j a c o n v e r s ió n
a b o r d a r á n m á s d e t a l l a d a m e n t e lo s c r i t e r i o s d e c a l i d a d d e l
d e l f lu jo d e d a to s [S T E 7 4 ] o e s tr u c tu r a d e d a to s [J A C 7 5 ,
d is e ñ o . P o r a h o r a s e p r e s e n t a r á n la s s i g u i e n t e s d i r e c t r i c e s :
W A R 7 4 ] e n u n a d e f in ic ió n d e d is e ñ o . E n f o q u e s d e d is e
1. U n d i s e ñ o d e b e r á p r e s e n t a r u n a e s t r u c t u r a a r q u i t e c t ó ñ o m á s r e c ie n t e s h a c i a l a d e r i v a c i ó n d e d i s e ñ o p r o p o n e n
n ic a q u e ( 1 ) s e h a y a c r e a d o m e d i a n t e p a t r o n e s d e d i s e ñ o u n m é t o d o o r ie n t a d o a o b je t o s . H o y e n d í a , s e h a h e c h o
r e c o n o c i b le s , ( 2 ) q u e e s t é f o r m a d a p o r c o m p o n e n t e s h in c a p ié e n u n d is e ñ o d e s o f t w a r e b a s a d o e n la a r q u it e c
q u e e x h ib a n c a r a c te r ís tic a s d e b u e n d is e ñ o ( a q u e lla s tu r a d e l s o ftw a re [G A M 9 5 , B U S 9 6 , B R 0 9 8 ],
q u e s e a b o r d a r á n m á s a d e la n t e e n e s t e m i s m o c a p í t u l o ) , In d e p e n d ie n te m e n te d e l m o d e lo d e d is e ñ o q u e s e u t i
Y (3 ) q u e s e p u e d a n im p le m e n ta r d e m a n e r a e v o lu tiv a , lic e , u n in g e n ie r o d e l s o ftw a r e d e b e rá a p lic a r u n c o n
fa c ilita n d o a s í la im p le r n e n ta c ió n y la c o m p r o b a c ió n . j u n t o d e p r in c ip io s fu n d a m e n ta le s y c o n c e p to s b á s ic o s
www.FreeLibros.org
2. U n d i s e ñ o d e b e r á s e r m o d u l a r ; e s t o e s , e l s o f t w a r e p a r a e l d is e ñ o a n iv e l d e c o m p o n e n te s ,d e in te r fa z , a r q u i
d e b e rá d i v id ir s e ló g ic a m e n t e e n e le m e n to s q u e r e a te c tó n ic o y d e d a to s . E s to s p r in c ip io s y c o n c e p to s s e
lic e n f u n c io n e s y s u b f u n c io n e s e s p e c í f ic a s . e s t u d ia n e n la s e c c ió n s ig u ie n te .
22 1
I N G E N IE RÍ A DEL SOF TW ARE . UN E N F O Q U E P R Á C T I C O
El diseño de softw are es tanto un proceso com o un E l diseño deberápresentar uniformidade integración.
modelo. El proceso de diseño es una secuencia de pasos Un diseño es uniforme si parece que fue una persona
que hacen posible que el diseñador describa todas los la que lo desarrolló por completo. Las reglas de estilo
aspectos del software que se va construir. Sin embargo, y de form ato deberán definirse para un equipo de
es im portante destacar que el proceso de diseño sim diseño antes de com enzar el trabajo sobre el diseño.
plem ente no es un recetario. Un conocimiento creativo, Un diseño se integra si se tiene cuidado a la hora de
experiencia en el tem a, un sentido de lo que hace que definir interfaces entre los componentes del diseño.
un software sea bueno, y un com prom iso general con E l diseño deberá estructurarse p a ra adm itir cam
la calidad son factores críticos de éxito para un diseño bios. Los conceptos de diseño estudiados en la sec
competente. ción siguiente hacen posible un diseño que logra este
El modelo de diseño es el equivalente a los planes principio.
de un arquitecto para una casa. Comienza representan El diseño deberá estructurar separa degradarsepoco
do la totalidad de todo lo que se va a construir (por ejem a poco, incluso cuando se enfrenta con datos, suce
plo, una representación en tres dim ensiones de la casa) sos o condiciones de operación aberrantes. Un soft
y refina lentamente lo que va a proporcionarla guía para ware bien diseñado no deberá nunca explotar como
construir cada detalle (por ejemplo, el diseño de fonta una «bomba». Deberá diseñarse para adaptarse a cir
nería). De m anera similar, el m odelo de diseño que se
cunstancias inusuales, y si debe term inar de funcio
crea para el softwareproporciona diversas visiones dife
nar, que lo haga de forma suave.
rentes de software de computadora.
Los principios básicos de diseño hacen posible que
el ingeniero del software navegue por el proceso de dise 9*»
ño. Davis [DAV95] sugiere un conjunto' de principios CLAVE
para el diseño del software, los cuales han sido adapta La consistencia del diseño y Id uniformidad es crucial
dos y ampliados en la lista siguiente: cuando se van a construir sistemas grandes. Se deber6
establecer un conjunto de reglas de diseño para el equipo
• En el proceso de diseño no deberá utilizarse «ore
del software antes de comenzar a trabajar.
jeras». Un buen diseñador deberá tener en cuenta
enfoques alternativos, ju zg an d o todos los que se E l diseño no es escribir código y escribir código no
basan en los requisitos del problem a, los recursos es diseñar. Incluso cuando se crean diseños proce-
disponibles para realizar el trabajo y los conceptos dimentales para componentes de programas, el nivel
de diseño presentados en la Sección 13.4. de abstracción del m odelo de diseño es m ayor que
• E l diseño deberá poderse rastrear hasta el modelo el código fuente. Las únicas decisiones de diseño
de análisis. Dado que un solo elem ento del modelo realizadas a nivel de codificación se enfrentan ccn
de diseño suele hacer un seguimiento de los m últi pequeños datos de im plementación que posibilitan
ples requisitos, es necesario tener un m edio de ras codificar el diseño procedimental.
trear cóm o se han satisfecho los requisitos por el E l diseño deberá evaluarse en fu n c ió n de la calidad
modelo de diseño. m ientras se va creando, no después de terminarlo.
• E l diseño no d eberá inventar nada que y a esté Para ayudar al diseñador en la evaluación de la cali
inventado. Los sistem as se construyen utilizando dad se dispone de conceptos de diseño (Sección 13.4)
un conjunto de patrones de diseño, m uchos de los y de m edidas de diseño (Capítulos 19y 24).
cuales probablem ente ya se han encontrado antes. E l diseño deberá revisarse p a ra minimizar los errores
Estos patrones deberán elegirse siem pre com o una conceptuales (semánticos). A veces existe la tenden
alternativa para reinventar. Hay poco tiem po y los cia de centrarse en minucias cuando se revisa el diseño,
recursos son lim itados. El tiem po de diseño se olvidándose del bosque por culpa de los árboles. Un
deberá invertir en la representación verdadera de
equipo de diseñadores deberá asegurarse de haber
ideas nuevas y en la integración de esos patrones afrontado los elementos conceptualesprincipales antes
que ya existen.
de preocuparse por la sintaxis del modelo del diseño.
• E l diseño deberá «minimizar la distancia intelec
tual» [DAV95] entre el software y el problem a como
si de la misma vida real se tratara. Es decir, la estruc C&3H
En et Capitulo 8 se presenta las directrices para llevar
tura del diseño del software (siempre que sea posi
a cabo revisiones de diseño efectivas.
ble) imita la estructura del dominio del problema.
www.FreeLibros.org
1 Aquí solo se destaca un peq u eñ o subconjunto de los principios
de diseño de Davis. Para m as información, véase [DAV95],
222
C A P I T U L O 13 C O N C E P T O S Y P R IN C IP IO S E E D ISE Ñ O
Cuando los princip io s de diseño descritos anterior ejem plo, velocidad, fiabilidad,grado de corrección, usa-
mente se aplican adecuadam ente, el ingeniero del soft bilidad)2. Los.factores de calidad internos tienen im p o r
ware crea un diseño que m u estra los factores de calidad ta n c ia p a ra los in g en iero s del so ftw a re . D esd e u n a
tanto internos com o externos [M EY 88]. L o sfa c to re s de perspectiva técnica conducen a un diseño de calidad alta.
calidad externos son esas propiedades del softw are que P ara lograr los factores de calidad internos, el diseñador
pueden ser observadas fácilm ente p o r los usuarios (por deberá com prender los conceptos de d iseño básicos.
—,1jLA-C QJiC£l?XQ.S..RE L P.IS£Ñü2

Durante las últim as cuatro décadas se h a experim enta m entarse directam ente. W asserm an [W A S83] p ro p o r
do la e v o lu c ió n de un c o n ju n to de c o n c e p to s fu n d a cio n a u n a definición útil:
m entales de d ise ñ o de softw are. A u n q u e el g rad o de L a noción psicológica de « abstracción» perm ite concen
interés en cada concepto h a v ariado con los años, todos trarse en un problem a a algún nivel d e generalización sin tener
han experim entadoel paso del tiem po. C ada uno de ellos en consideración lo s datos irrelevantes de bajo nivel; la u tili
proporcionarán la base de donde el diseñador podrá apli zación de la abstracción tam bién p erm ite trabajar con concep
tos y térm inos que son fam iliares en el entorno del problem a
car los m éto d o s de diseño m ás sofisticados. C ada uno
sin tener que transform arlos en una estructura no fam iliar.. .
ayudará al ingeniero del softw are a resp onder las pre
guntas siguientes: C ad a p a so del p ro c e so del so ftw are es u n re fin a
• ¿Qué criterios se p o d rán u tilizar p ara la partición del m iento en el nivel de abstracción de la solución del soft
softw are en com ponentes individuales? ware. D urante la ingeniería del sistem a, el softw are se
asigna com o un elem ento de un sistem a basado en co m
• ¿Cómo se puede separar la fun ció n y la estructura de
putadora. D urante el análisis de los requisitos del so ft
datos de un a representación conceptual del softw are?
w are, la so lu ció n del so ftw are se e sta b le c e e n e sto s
• ¿Existen criterios u n iform es que d efinen la calidad
térm inos: «aquellos que son fam iliares en el entorno del
técnica de un diseño de softw are? problem a». A m edida que nos adentram os e n el p ro ce
M.A. Jackson una vez dijo: «El com ienzo de la sabi s o de d iseño, se reduce el nivel de abstracción. F inal
duría para un ingeniero del so ftw arees reco n o cerla d ife m ente el nivel de abstracción m ás bajo se alcanza cuando
rencia entre hacer que un program a funcione y conseguir se genera el código fuente.
que lo haga correctam ente».[JA C 875] L o s concep to sd e A m edida que vam os en tran d o en diferentes niveles
diseño de softw are fu ndam entales p ro p o rcionan el m a r de abstracción, trabajam os para crear abstraccionespro-
co de trabajo n e c e sa rio p ara c o n se g u ir q u e lo h ag a .cedim entales y de datos. U na a b stra cció n p ro ced im en -
correctamente». tal es una secuencia nom brada de instrucciones que tiene
una función específica y lim itada. U n ejem p lo de abs
tracción procedim ental sería la palabra «abrir» para una
puerta. « A b rir» im plica u n a secu e n cia larga de pasos
I d abstracción es una de las formas fundamentales procedim entales (por ejem plo, llegar a la p u erta; a lca n
B que tes hombres se enfrentan con la zar y agarrar el pom o de la puerta; g ira r el p om o y tirar
de la puerta; separarse al m o v er la puerta, etc.).
13.4.1. A b stra cció n

Cuando se tiene en consid eració n u n a solución m o d u Como diseñador, trabaje mucho y duro poro derivar
lar a cualq u ier p ro b lem a, se p u ed en e x p o n e r m uchos abstracciones tontoprocedimentales como de datos
niveles de abstracción. En el nivel m ás alto de abstrac que sirvan poto e l problema que tengo en ese momento,
ción, la so lu ció n se p o n e co m o u n a m e d id a e x te n sa pero que tombién se puedon volverá utilizaren otros

situaciones.
em pleando el len g u aje del e n to rn o del problem a. E n
niveles inferiores de abstracción, se to m a u n a orienta
ción más procedim ental. La te rm in o lo g ía o rien ta d a a U n a abstracción de datos es una colección n o m b ra
problemas v a em p arejad a con la term in o logía orien ta d a de datos que describ e un o b jeto de datos (C apítulo
da a la im plem entación en un esfu erzo p o r solucionar 12). E n el c o n te x to de la a b stra c c ió n p ro c e d im e n ta l
el problem a. Finalm ente, en el nivel m ás bajo de abs abrir, podem os definir u n a abstracción de datos llam a
tracción, se e sta b le c e la so lu ció n p a ra p o d e r im ple- d a puerta. A l igual que c u a lq u ier o b jeto de d ato s, la
www.FreeLibros.org
2 S i el C apítulo 19 se presen ta un estu d io m ás d etallado sobre
los factores de calidad.
223
I N G E N IE RÍ A DEL SOF TW ARE . UN EN F O Q U E P R A C T I C O
abstracción de datos para puerta acom pañaría a un c o n (o descripción de inform ación) que se define a un nivel
ju n to de atributos que d escriben esta pu erta (p o r ejem alto de abstracción. E sto es, la sentencia describe la fun
plo, tip o de puerta, d irección de apertura, m ecanism o ción o inform ación conceptualm ente, pero no propor
de apertura, peso, dim ensiones). Se puede seguir d icien ciona inform ación sobre el funcionam iento interno de
do que la ab stracción p rocedim ental abrir hace u so de la inform ación. El refinam iento hace que el diseñador
la inform ación co ntenida en los atributos de la abstrac trabaje sobre la sentencia original, proporcionando cada
ción de datos puerta. vez m ás detalles a m ed id a que van teniendo lugar suce
L a a b stra c c ió n de co n tro l es la te rc e ra fo rm a de sivam ente todos y cada uno de los refinam ientos (ela
ab stracció n que se u tiliza en el d iseñ o del softw are. A l boración).
igual que las abstracciones p rocedim entales y de datos,
este tip o de abstracción im plica un m ecanism o de c o n 13.4.3. M odularidad
trol de p ro g ram a sin especificar los d ato s internos. U n
eje m p lo de a b stracció n de co n tro l es el se m á fo ro de El concepto de m odularidad se h a ido exponiendo des
sin c ro n iz a c ió n [K A I83] que se u tiliz a p a ra co o rd in ar de hace casi cin co d écadas en el softw are de com puta
las activ id ad es en un sistem a op erativ o . E l co n cepto dora. L a a rq u ite ctu ra de co m p u ta d o ra (d escrita en la
de ab stracció n de co n tro l se e stu d ia b rev em en te en el S e cc ió n 13.4.4) e x p re sa la m o d u larid ad ; es decir, el
C ap ítu lo 14. softw are se d ivide en com ponentes nom brados y abor
dados p o r separado, llam ad o s frecu en tem en te módu
los, que se in teg ran para satisface r los requisitos del
13.4.2. R efinam iento problem a.
El refinam iento p a s o a p a s o es una estrateg ia de diseño Se ha afirm ado que «la m odularidad es el Único atri
descendente propuesta originalm ente po r N iklaus W irth buto del softw are que perm ite g estio n a r un program a
[W IR 71]. El d esarrollo de un pro g ram a se realiza re ti intelectualm ente»[M Y E 78], El softw are m onolítico (es
nando sucesivam ente los niveles de detalle procedim en- decir, un program a grande form ado por un Único módu
tales. U na je ra rq u ía se desarro lla descom poniendo una lo) no puede ser entendido fácilm ente p o r el lector. La
sentencia m acroscópica de función (una abstracción p ro cantidad de rutas de control, la am plitud de referencias,
cedim ental) paso a paso hasta alcanzar las sen tenciasdel la can tid ad de v ariab les y la co m p lejid ad global hará
lenguaje de program ación. W irth [W IR71] p roporciona que el entendim iento esté m uy cerca de ser imposible.
una visión general de este concepto: P ara ilustrar este p u n to , tom em os en consideración el
siguiente argum ento basado en observaciones humanas
E n cada paso (del refinam iento), se descom pone una o varias
sobre la resolución de problem as.
instrucciones del program a dado en instrucciones m ás detalla
das. E sta descom posición sucesiva o refinam iento de especifi Pensem os que C(x) es una función que define la com
caciones term ina cuando todas las instrucciones se expresan plejidad percibida de un problem a x, y que E (x) es una
en función de cualquier com putadora subyacente o de cual función que define el esfuerzo (oportuno) que se requie
quier lenguaje de program ación.. .D e la m ism a m anera que se re para resolver un problem a x . Para dos p ro b lem as/^
refinan las tareas, los datos tam bién se tienen que refinar, des
y p 2, si
com poner o estructurar, y es natural refinar el program a y las
especificaciones de los datos en paralelo. C ( p j) > C ( p 2) ( I 3 .ia )
T odos los pasos del refinam iento im plican decisiones de im plica que
diseño. Es im portante q u e ... el program ador conozca los cri
E (p ]) > E ( p 2) (13.1b)
terios subyacentes (para decisiones de diseño) y la existencia
de soluciones alternativas., .
El p roceso de refinam iento de p rogram as propuesto

p o r W irth es análogo al p roceso de refinam iento y de
partició n que se utiliza durante el análisis de requisitos. Para el hombre siempre hoy una solución fácil
L a d ife re n c ia se e n c u e n tra en el n iv el de d e ta lle de pora a tá p e r problemo — clora, plausible
im plem entación que se h ay a tom ado en consideración, ■y «qtSvocoda— .
no en el enfoque. m Hwdrwi
E n general, este resultado es po r intuición obvio. Se

tard a m ás en resolver un problem a difícil.
Existe la tendencia de entrar en detalle inmediatamente, M ediante la experim entación h u m ana en la resolu
saltándose los pasos de refinamiento. Esto conduce o ción de problem as se h a averiguado otra característica
errores y omisiones y hace que el diseño seo más difícil
interesante. E sta es,
de revisar. Realice el refinamiento paso a paso.
C (p j + p 2) > C ( p j) + C (p 2) (13.2)
www.FreeLibros.org
El re fin a m ie n to v erd a d e ram e n te e s un p ro ceso de L a ecuación (13.2) im plica que la com plejidad per
elaboración. Se com ien za con u n a sentencia de función cib id a de un problem a que co m b in a p¡ y p 2 es mayor
224
C A P Í T U L O 13 C O N C E P T O S Y P R IN C IP IO S DE D ISE Ñ O
que la complejidad percibida cuando se considera cada ¿Cómo se puede evaluar un método
problema por separado. Teniendo en cuenta la ecuación
(13.2)y la condición implicada por la ecuación (13.1),
se establece que
E(P¡ + P 2) > E(P¡) + E(p2) ( 13-3)
• de diseño para determinar si va a
conducir a una modularidad efectiva?
C apacidad de d escom p osición m od u lar. Si

un método de diseño proporciona un mecanismo
Esto lleva a una conclusión: «dividey vencerás» — es
sistemático para descomponer el problema en sub-
más fácil resolver un problema complejo cuando se rom
problemas, reducirá la complejidad de todo el pro
pe en piezas manejables — . El resultado expresado en la
blema, consiguiendo de esta manera una solución
ecuación (13.3) tiene implicacionesimportantes en lo que
modular efectiva.
respecta a la modularidad y al software. Es, de hecho, un
argumento para la modularidad. Capacidad de em pleo de com ponentes m odu
lares. Si un método de diseño permite ensamblar los
componentes de diseño (reusables) existentes en un
Ô N SE JO ^. sistema nuevo, producirá una solución modular que
Nomodulante de más. la simplicidadde cadamóduh no inventa nada ya inventado.
se eclipsaráconlacomplejidaddelaintegración. Capacidad de com prensión m odular. Si un
módulo se puede comprender como una unidad autój
Es posible concluir de la ecuación (13.3) que si sub: noma (sin referencias a otros módulos) será más fácil
dividimos el software indefinidamente, el esfuerzo que de construir y de cambiar.
se requiere para desarrollarlo sería mínimo. Desgracia
damente, intervienen otras fuerzas, que hacen que esta
conclusión sea (tristemente) falsa. Como muestra la
Figura 13.2,el esfuerzo (coste) para desarrollar un módu
lo de software individual disminuye a medida que
aumenta el número total de módulos. Dado el mismo
conjunto de requisitos, tener más módulos conduce a un
tamaño menor de módulo. Sin embargo, a medida que
aumenta el número de módulos, también crece el esfuer
zo (coste) asociadocon la integración de módulos. Estas
características conducen también a la curva total del cos
te o esfuerzo que se muestra en la figura. Existe un núme Número de módulos
ro M de módulos que daría com o resultado un coste F IG U R A 13.2. M odularidad y costes de software.
mínimo de desarrollo, aunque no tenemos la sofistica
ción necesaria para predecir M con seguridad. Continuidad modular. Si pequeños cambios en
Las curvas que se muestran en la Figura 13.2 pro los requisitos del sistema provocan cambios en los
porcionan en efecto una guía útil cuando se tiene en módulos individuales, en vez de cambios generali
consideración la modularidad. La modularidad debe zados en el sistema, se minimizará el impacto de los
rá aplicarse, pero teniendo cuidado de estar próximo efectos secundarios de los cambios.
aM. Se deberá evitar modularizar de más o de menos.
Protección modular. Si dentro de un módulo se
Pero, ¿cómo conocemos el entorno de M ? ¿Cuánto se
produce una condición aberrante y sus efectos se
deberá modularizar el software? Para responder a estas
limitan a ese módulo, se minimizará el impacto de
preguntas se deberán comprender los conceptos de
los efectos secundarios inducidos por los errores.
diseño que se estudiarán más adelante dentro de este
capítulo. Finalmente, es importante destacar que un sistema
se puede diseñar modularmente, incluso aunque su
m iim jE S B m implementación deba ser «monolítica». Existen situa
los métodos de diseño se estudian en los Capítulos 14, ciones (por ejemplo, software en tiempo real, software
15,16 y 22. empotrado) en donde no es admisible que los subpro-
gramas introduzcan sobrecargas de memoria y de velo
Cuando se tiene en consideración la modularidad cidad por mínimos que sean (por ejemplo, subrutinas,
surge otra pregunta importante. ¿Cómo se define un procedimientos). En tales situaciones el software podrá
módulo con un tamaño adecuado? La respuesta se y deberá diseñarse con modularidad como filosofía pre
encuentra en los métodos utilizados para definir los dominante. El código se puede desarrollar «en línea».
módulos dentro de un sistema. Meyer [MEY 88] define Aunque el código fuente del programa puede no tener
www.FreeLibros.org
cinco criterios que nos permitirán evaluar un método de un aspecto modular a primera vista, se ha mantenido la
diseño en relación con la habilidad de definir un siste filosofía y el programa proporcionará los beneficios de
ma modular efectivo: un sistema modular.
225
INGENIERÍA DEL S O F TW A R E . UN EN F O Q U E P R Á C T I C O
13.4.4. A rq u itectu ra d e l so ftw a re Familias de sistemas relacionados.El diseño arquitectóni

c o d eb erá dibujarse sobre patro n es rep etib les que se basen
La arquitectura del software alude a la « estructura g lo com únm ente en el diseño de fam ilias de sistem as similares. En
bal del softw are y a las form as en que la estru ctu ra p ro esencia, el diseño deberá tener la h'abilidad de v olver a utilizar
p o rc io n a la in te g rid a d c o n c e p tu a l de u n siste m a » los bloques de construcción arquitectónicos.
[SH A 95a], E n su form a m ás sim p le, la arquitectura es
D a d a la e s p e c ific a c ió n d e e sta s p ro p ie d a d e s, el
la estru ctu ra je rá rq u ic a de los c o m p o n e n te s del p ro
d ise ñ o a rq u ite c tó n ic o se p u ed e re p re se n ta r m edian
g ram a (m ó d u lo s), la m an era en que los co m p o n en tes
te u n o o m á s m o d e lo s d if e r e n te s [G A R 9 5 ], Los
interactúan y la estructura de d ato s que v an a utilizar
m o d elo s e stru c tu ra le s re p re s e n ta n la arqu itectu ra
lo s c o m p o n e n te s. S in e m b a rg o , en u n se n tid o m ás
c o m o u n a c o le c c ió n o rg a n iz a d a de co m p o n en tes de
am plio, los «com ponentes» se pu ed en generalizar para
p rogram a. L o s m odelos del marco de trabajo aumen
represen tar los elem entos p rincipales del sistem a y sus
ta n el n iv e l d e a b stra c c ió n del d ise ñ o en un intento
in teraccio n es3.
de id e n tific a r lo s m a rc o s de tra b a jo (p a tro n e s) repe-
tib les del d ise ñ o a rq u ite c tó n ic o que se encuentran a i
tip o s sim ila re s de a p lic a c io n es. L os m odelos diná—
Referencia W eb l ^ m icos tra ta n lo s a sp e c to s d e c o m p o rta m ie n to de la
a rq u ite c tu ra d el p ro g ra m a , in d ic a n d o c ó m o puede
La STARS Software Architecture T echnology Guide c a m b ia r la e stru c tu ra o la c o n fig u ra c ió n del sistem a
proporciona mbs información y recursos en la dirección
e n fu n c ió n d e lo s a c o n te c im ie n to s e x te rn o s. Los
www-ast.tds-gn.lmco.com/arch/guide.html
m odelos de p ro c e so se c e n tra n en el d ise ñ o del pro
ceso téc n ico de n eg o cio s que tien e que ad ap tar el sis
U n objetivo del diseño del softw are es deriv ar una
tem a. F in a lm e n te lo s m odelos fu n cio n a les se pueden
represen tació n arquitectónica de un sistem a. E sta rep re
u tiliz a r p a ra re p re s e n ta r la je r a r q u ía fu n cio n al de un
sentación sirve co m o m arco de trabajo desde donde se
sistem a.
llevan a cab o actividades de diseño m ás detalladas. U n
conjunto de p atrones arquitectónicos p erm iten que el
ingeniero del softw are reutilice los conceptos a nivel de
diseño. C u VE
Poro representar el diseño arquitectónico se utilizan
cinco tipos diferentes de modelos.
Se h a desarrollado un conjunto de lenguajes de des—

cripción arquitectónica (L D A s) para re p resen ta r los
m odelos destacados anteriorm ente [SFlA 95b]. Aunque
se han propuesto m uchos L D A s diferentes, la mayoría
p ro p o rc io n an m ec an ism o s para d e sc rib ir los com po
nentes del sistem a y la m anera en que se conectan unos
con otros.
Shaw y G arlan [SH A 95a] d escriben un conjunto de
propiedades que deberán especificarse co m o parte de 13.4.5. J erarq u ía d e control
un diseño arquitectónico:
Propiedades estructurales. E ste aspecto de la representa La jerarquía de control, denom inada tam bién estructu
ción del diseño arquitectónico define los com ponentes de un ra de program a, representa la organización de los com
sistem a (por ejem plo, m ódulos, objetos, filtros) y la m anera ponentes de program a (m ódulos) e im plica una jerarquía
en que esos com ponentes se em paquetan e interactúan unos de control. N o representa los aspectos procedim entales
con otros. P or ejem plo, los objetos se em paquetan para encap- del softw are, ni se puede aplicar necesariam ente a todos
sular tanto los datos com o el procesam iento que m anipula los
los estilos arquitectónicos.
datos e interactúan m ediante la invocación de m étodos (C apí
tulo 20).
Propiedadesextra— funcionales.La descripción del diseño
arquitectónico deberá ocuparse de cóm o la arquitectura de d ise
ño consigue los requisitos para el rendim iento, capacidad, fia Bl el Capítulo 14 se presenta un estudio detallado
bilidad, seguridad,capacidad de adaptación y otras características
de estilos y patrones arquitectónicos.
del sistema.
www.FreeLibros.org
3 Por ejem plo, los com p o n en tes a rq u itectó n ico s de un sistem a
cliente/servidor se representan en un nivel de abstracción diferente.
P ara m ás detalles véase el Capítulo 28.
226
C A P Í T U L O 13 C O N C E P T O S Y P R IN C IP IO S DE D ISE Ñ O
Para representar la jerarquía control de aquellos esti La j erarquía de control tam bién representa dos carac
los arquitectónicos que se avienen a la representación se terísticas sutiles diferentes de la arquitectura del soft
utiliza un conjunto de notaciones diferentes. El diagra ware: visibilidad y conectividad. La visibilidad indica
ma más com ún es el de forma de árbol (Fig. 13.3) que el conjunto de componentes de program a que un com
representa el control jerárquico para las arquitecturas de ponente dado puede invocar o utilizar como datos, inclu
llamada y de retom o4. Sin embargo, otras notaciones, so cuando se lleva a cabo indirectamente. Por ejem plo,
tales como los diagram as de W am ier-O rr [ORR77] y un módulo en un sistema orientado a objetos puede acce
Jackson [JAC83] tam bién se pueden utilizar con igual der al amplio abanico de objetos de datos que haya here
efectividad. Con objeto de facilitar estudios posteriores dado, ahora bien solo utiliza una pequeña cantidad de
de estructura, definiremos una serie de m edidas y térm i estos objetos de datos. Todos los objetos son visibles
nos simples. Según la Figura 13.3, laprofundidad y la para el módulo. La conectividad indica el conjunto de
anchura proporcionan una indicación de la cantidad de componentes que un componente dado invoca o utiliza
niveles de control y el ámbito de control global, respec directam ente com o datos. Por ejem plo, un m ódulo que
tivamente. El grado de salida es una m edida del núm e hace directam ente que otro m ódulo em piece la ejecu
ro de módulos que se controlan directam ente con otro ción está conectado a él5.
módulo. El grado de entrada indica la cantidad de m ódu
los que controlan directam ente un módulo dado.
13.4.6. D iv isió n estru ctu ral
Si el estilo arquitectónico de un sistem a esjerárquico,
la estructura del program a se puede dividir tanto h ori
zontal com o verticalmente. En la Figura 13.4.a la par
tición horizontal define ramas separadas de lajerarquía
m odular para cada función principal del programa. Lo
m ódulos de control, representados con un som breado
m ás oscuro se utilizan para coordinar la com unicación
entre ellos y la ejecución de las funciones. El enfoque
m ás simple de la división horizontal define tres parti
ciones - e n tr a d a , transform ación de datos (frecuente
m ente llamado procesam iento) y salida— . La división
horizontal de la arquitectura proporciona diferentes
ventajas:
FIGURA 1 3.3. Term inologías de estructura para un estilo ■ proporciona software m ás fácil de probar
arquitectónico de llam ada y retorno.
. conduce a un software m ás fácil de m antener
La relación de control entre los m ódulos se expresa • propaga m enos efectos secundarios
de la manera siguiente: se dice que un m ódulo que con
trola otro m ódulo es superior a él, e inversamente, se . proporciona software m ás fácil de ampliar
dice que un m ódulo controlado por otro m ódulo es
subordinado del controlador [YOU79]. Por ejemplo, en
¿Cuáles son las ventajas
la Figura 13.3 el m ódulo M es superior a los módulos
a, b y c. El m ódulo h está subordinado al m ódulo e y
por Ultimo está subordinado al m ódulo M. Las relacio
• de la partidón horizontal?
nes en anchura (por ejemplo, entre los m ódulos d y e ) , Com o las funciones principales se desacoplan las
aunque en la práctica se puedan expresar, no tienen que unas de las otras, el cam bio tiende a ser m enos com
definirse con term inología explícita. plejo y las extensiones del sistema (algo muy com ún)
tienden a ser m ás fáciles de llevar a cabo sin efectos
secundarios. En la parte negativa la división horizontal
suele hacer que los datos pasen a través de interfaces de
Si desarrollamos un software orientado o objetos,
no se aplicarán los medidos estructurales destacadas
m ódulos y que puedan com plicar el control global del
aquí. Sin embargo, se aplicarán otros (las que se flujo del program a (si se requiere un m ovimiento rápi
abordan en lo Porte Cuarta). do de una función a otra).
4 Una arquitectura de llamada y de retorno (Capítulo 14)es una estruc 5 En el Capítulo 20, explorarem os el concepto de herencia para el
tura de program a clásica que descom pone la función en una je ra r softw are orientado a objetos. Un com ponente de program a puede
www.FreeLibros.org
quía de control en donde el program a «principal» invoca un núm ero heredar una lógica de control y /o datos de otro com ponente sin refe
de com ponentes de program a que a su vez pueden invocar aún a rencia explícita en el código fuente. Los com p o n en tes de este tipo
otros com ponentes. serán visibles, pero no e stará n c o n ec ta d o s directam en te. Un dia
gram a de estructuras (Capítulo 14) indica la conectividad.
227
INGE NIE RÍ A DEL SO FT W AR E. UN E N F O Q U E P R Á C T I C O
L a división vertical (Fig. 13.4.b), frecuentem ente 11a- L a estructura dicta las alternativas de organización,
m ada facto riza ció n (factoring) sugiere que dentro de la m étodos de acceso, grado de capacidad de asociación
estructura de program a el control (tom a de decisiones)y y p ro cesam ien to de la in form ación. Se han dedicado
el trabajo se distribuyan de m an era descendente. Los lib ro s e n te ro s (p o r e je m p lo , [A H 0 8 3 ], [K RU 84],
módulos del nivel superior deberán llevar a cabo fu n cio [G A N 89]) a estos tem as, y un estudio m ás am plio sobre
nes de control y no realizarán m ucho trabajo de procesa este te m a q u e d a fu e ra del á m b ito d e e ste libro. Sin
miento. L os m ódulos que residen en la parte inferior de em bargo, es im p o rtan te en te n d er la disponibilidad de
la estructura d eberán ser los trab ajad o res, aquellos que m éto d o s clásico s para o rg an iz ar la in fo rm ació n y los
realizan todas las tareas de entrada, proceso y salida. conceptos que subyacen a las jerarq u ías de inform ación.
L a naturaleza del cam bio en las estructuras de progra- La organización y com plejidad de una estructura de
m asjustifica la necesidad de la división vertical. En la Figu datos están lim itados U nicam ente po r la ingenuidad del
ra 13.4b se puede observar que un cam bio en un m ódulo diseñador. Sin em bargo, existe un núm ero lim itado de
de control (parte superior de la estructura) tendrá una pro estructuras de datos clásicas que com ponen los bloques
babilid ad m ay o r de p ro p ag ar efectos secundarios a los de construcción para estructuras m ás sofisticadas.
m ódulos subordinados a él. U n cam bio en el m ódulo de
trabajador, dado su nivel bajo en la estructura, es m enos
probable que propague efectos secundanos.E n general, los
cambios en los program as de com putadora giran alrededor
del programa (es decir, su com portam ientobásico es m enos
probable que cam bie). Por esta razón las estructuras con
división vertical son menos susceptibles a los efectos secun
darios cuando se producen cam bios y p or tanto se podrán U n e lem e n to esca la r es la estru ctu ra de datos más
m antener m ejor - u n factor de calidad clave— . sim ple. C om o su no m b re in d ica, u n elem en to escalar
rep re sen ta un solo elem en to d e in fo rm a ció n que pue
de ser tra tad o p o r un id en tificad o r; es decir, se puede
lo g ra r a c c e so e s p e c ific a n d o un so la d ire c c ió n en
CLAVE m em oria. E l tam añ o y fo rm ato de un elem en to esca
los módulos de «trabajador» tienden a cambiar de forma lar puede v a ria r d en tro de los lím ites que d ic ta el len
más frecuente que los módulos de control. SI se colocan g u a je d e p ro g ra m a c ió n . P o r e je m p lo , u n elem ento
en la parte Inferior de la estructura, se reducen los efectos escalar puede ser: u n a entidad lógica de u n bit de tam a
secundarios (originados por el cambio).
ñ o ; un en tero o nú m ero de co m a flo tan te con un tam a
ño de 8 a 64 bits; u n a c ad en a de caracteres de cientos
13.4.7. E s tr u c tu r a d e d a to s o m iles de bytes.
C uando los elem entos escalares se organizan como
La estructura de datos es u n a represen tació n de la rela
una lista o grupo contiguo, se form a un vector secuen-
ción lógica entre elem entos individ u alesd e datos. C om o
cial. Los vectores son las estructuras de datos m ás comu
la estru ctu ra de la inform ación afectará in v ariab lem en
nes y abren la p u e rta a la in d e x a c ió n v a ria b le de la
te al diseño procedim ental final, la estructura de datos
inform ación.
es tan im portante com o la estru ctu ra de pro g ram a para
C uando el v ector secuencia1 se am plía a dos, tres y
la represen tació n de la arquitectura del softw are.
po r últim o a un nú m ero arb itrario de dim ensiones, se
Función 1 Función crea un espacio n-dim ensioncd. El espacio n-dimensio-
nal m ás com ún es la m atriz bidim ensional. E n muchos
lenguajes de program ación, un esp acio n-dim ensional
se llam a array.
Los elem entos, vectores y espacios pueden estar orga
u& u F u n c ió n 3
(a) D ivisión horizontal
nizados en diversos form atos. U na lista enlazada es una
estructura de datos que o rganiza elem entos escalares no
c o n tig u o s, v ecto res o esp a c io s de m a n e ra (llam ados
nodos) que les p erm ita ser procesados com o una lista.
M ódulos
d e tom a
C ada nodo contiene la organización de datos adecuada
de decisiones (por ejem plo, un vector) o un puntero o m ás que indi
can la dirección de alm acenam iento del siguiente nodo
de la lista. Se pueden añ ad ir nodos en c u alq u ie r p un
to de la lista para adaptar una entrada n u eva en la lista.
M ódulos O tras estructuras de datos incorporan o se constru
www.FreeLibros.org
de «trabajo y en m ed ian te las e stru ctu ras de d ato s fundam entales
(b ) D ivisión V ertical descritas anteriorm ente. Por ejem plo, una estructura de
F IG U R A 1 3 .4 . Partición estructural. d a to s je r á r q u ic a se im p lem en ta m ed ian te listas mul-
228
CA P Í T U L O 13 C O N C E P T O S Y P R IN C IP IO S DE D ISE N O
tienlazadas que co ntienen elem entos escalares, v ecto 13.4.9. O c u lta c ió n d e in fo rm a c ió n

res y p o sib le m e n te e sp a c io s n -d im en sio n ales. U n a El concepto de m odularidad conduce a todos los d ise
estructurajerárquica se en cuentra com únm ente en apli ñ adores de softw are a form ularse una p regunta im por
caciones que req u ieren categorización y capacidad de tante: «¿C óm o se puede descom poner una solución de
asociación. softw are para obtener el m ejo r co n ju n to de m ódulos?»
E l p rin c ip io d e o cu lta ció n d e in fo rm a c ió n [PA R72]
^ m N S K J o f^ . sugiere que los m ó d u lo s se c ara cteriza n p o r las d e c i
siones de d iseño que (cada uno) oculta al otro. E n otras
Invierta por lo menos todo el tiempo que necesite palabras, los m ódulos deberán especificarse y diseñar
diseñando estructuras de datos, el mismo que pretende se de m anera que la inform ación (procedim iento y datos)
invertir diseñando algoritmos poro manipularlos.
que e stá den tro de un m ó d u lo sea inaccesib le a otros
Si es así, se ohorraró mucha tiempo.
m ódulos que no necesiten esa inform ación.
O c u lta c ió n sig n ific a que se p u ede c o n se g u ir una
Es im portante destacar que las estructuras de datos, al m odularidad efectiva definiendo un conjunto de m ó d u
igual que las estructuras de program as, se pueden rep re los in d e p e n d ie n te s que se c o m u n ic a n en tre sí in te r
sentar a diferentes niv eles de abstracción. P or ejem plo, cam biando sólo la inform ación n ecesaria para lograr la
una pila es un m odelo conceptual de u n a estructura de función del softw are. L a abstracción ayuda a definir las
datos que se puede im plem entarcom o un vector o una lis entidades (o inform ación).
ta enlazada. D ependiendo del nivel de detalle del diseño,
los procesos internos de la pila pueden especificarse o no.
13.4.8. P r o c ed im ien to d e s o ftw a r e

La estructura de p ro g ra m a define la je rarq u ía de co n
Procedimiento
trol sin tener en consid eració n la secuencia de proceso
para el módulo
y de decisiones. El p rocedim iento de softw are se centra superior
en el p rocesam iento de cada m ó d u lo individualm ente.
El procedim iento debe p ro p o rcio n ar u n a especificación
precisa de p rocesam iento, incluyendo la secuencia de Procedimiento
sucesos, los p untos de d ecisión exactos, las operaciones para el módulo
repetitivas e incluso la estructura/organización de datos. subordinado
Existe, po r supuesto, una relació n entre la estructura
y el procedimiento. El procesam iento indicado para cada
Procedimiento
módulo debe inclu ir una referen cia a tod os los m ódulos para el último módulo
subordinados al m ó d u lo que se está d escribiendo. Es subordinado
decir, una rep resen tació n p ro ced im en tal del softw are se
distribuye en capas com o m uestra la F igura 13.56. F IG U R A 13.5. El procedimiento se distribuye en capas.
LJJL31 IHSiSMO MODULAR EFECTIV O

Los conceptos fu ndam entales de diseño descritos en la tación de inform ación. E n referencias obligadas sobre
sección anterior sirven p ara incentivar diseños m o d u la el diseño del software, Pam as [PAR72] y W irth [W IR 71]
res. De hecho, la m od u larid ad se h a c o n v ertid o en un alu d en a las té cn ic as de re fin a m ien to que m e jo ra n la
enfoque aceptado en todas las disciplinas de ingeniería. independencia de m ódulos. T rabajos posteriores de Ste-
Un diseño m o d u lar reduce la com plejidad (véase la S ec vens, W yers y Constantine [STE74] consolidaron el co n
ción 13.4.3), facilita los cam bios (un aspecto crítico de cepto.
la capacidad de m an ten im ien to d el softw are),y da com o
resultado una im plem entación m ás fácil al fom entar el
desarrolloparalelo de las diferen tesp artes de un sistema.
Un código e s «determinante» sise describe con
una sola oración — sujeto, verbo y predtada — r
13.5.1. I n d e p e n d e n c ia fu n c io n a l
El concepto de in d ep en d en cia fu n cio n a l es la sum a de L a independencia funcional se consigue desarrollan
la m odularidad y de los conceptos de abstracción y ocul- do m ódulos con una función «determ inante»y una «aver-
www.FreeLibros.org
6 Esto no es verdad para to d as las estructuras arquitectónicas, Por
ejemplo, la estratificaciónjerárquica de procedimientos no se encuen
tra en arquitecturas orientadas a objetos.
229
INGENI ER ÍA DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
sión» a u n a in te ra c c ió n e x c e s iv a c o n o tro s m ódulos. tiene tareas que están relacionadas entre sí p o r el hecho
D icho de o tra m anera, querem os d iseñar el softw are de de que todas deben ser ejecutadas en el m ism o interva
m anera que cada m ódulo trate un a subfunción de req u i lo de tiem po, el m ódulo m u estra cohesión tem poral.
sitos y tenga una interfaz sencilla cuando se observa d es C om o ejem plo de b aja cohesión, tom em os en con
de otras partes de la estru ctu ra del program a. Es ju s to sideración un m ódulo que lleva a cabo un procesamiento
preguntarse p o r qué es im portante la independencia. El de erro res de un paquete de an álisis de ingeniería. El
softw are con una m odularidad efectiva, es decir, m ó d u m ódulo es invocado cu an d o los datos calculados exce
los independientes, es m ás fácil de desarro llar porque la d en los lím ites p reestab lecid o s. Se re aliz an las tareas
función se puede com partim entary las interfaces se sim siguientes: (1) calcula los datos com plem entarios basa
plifican (tengam os en consideración las ram ificaciones dos en los datos calculados originalm ente; (2) produce
cuan d o el d esarrollo se hace en equipo). L os m ódulos un inform e de errores (con contenido gráfico) en la esta
independientes son m ás fáciles de m an ten er (y probar) ción de trabajo del usuario; (3 ) realiza los cálculos de
porque se lim itan los efectos secundarios o riginados por seguim iento que h ay a pedido el usuario; (4 ) actualiza
m odificaciones de diseño/código; p o rq u e se reduce la u n a base de datos, y (5 ) activ a un m enú de selección
p ro p a g a c ió n de e rro re s; y p o rq u e e s p o sib le u tiliz a r para el siguiente procesam iento. A unque las tareas ante
m ódulos usables. E n resu m en , la in d e p e n d e n c ia fu n riores están po co relacionadas, ca d a una es una entidad
cional e s la clave p ara un b u en diseño y el diseño es la fu n c io n a l in d e p e n d ie n te que p o d rá re a liz a rs e m ejor
clave p ara la calidad del softw are. co m o un m ódulo separado. L a com binación de funcio
L a independencia se m ide m ediante dos criterios cu a n es en un solo m ó d u lo p u ede se rv ir sólo p a ra in cre
litativos: la co hesión y el acoplam iento. L a cohesión es m entar la probabilidad de propagación de errores cuando
una m ed id a de la fuerza relativ a funcional de un m ó d u se hace una m odificación a alguna de las tareas proce-
lo. E l a co p la m ien to e s u n a m ed id a de la independencia d im entales anteriorm ente m encionadas.
relativ a en tre los m ódulos.
/ S in \
^ c o p la m ie n to N
13.5.2. C o h e s ió n
L a co hesión e s una ex tensión natural del co n cep to de X
d irec to
'- - I
\
E structura D a to s a | In d ic a d o r
ocultación de inform ación descrito en la Sección 13.4.8. d e d a to s (v a ria b le s ) \ J d e c o n tro l
U n m ódulo cohesivo lleva a cabo una sola tarea dentro
de un procedim iento de softw are, lo cual requiere poca X ) Cp X) 1X1X I
interacció n con los p rocedim ientos que se llevan a cabo
en otras partes de u n program a. D icho de m an era sen
cilla, un m ó d u lo co h esiv o d e b e rá (id ealm en te) h acer
\ XÍpXl / A re a d e d a to s '-, y?
una sola cosa.
F IG U R A 1 3 .6 .Tipos de acoplam iento.

VE
la cohesiónes una indicacióncualitativa del grado L os niveles m oderados d e co h esió n está n relativa
que tiene un módulo para centrarseen una sola cosa. m ente cerca unos de otros en la escala de independen
cia m odular. C uando los elem en to s de procesam iento
L a cohesión se puede representar com o un «espectro».
de un m ódulo están relacionados, y deben ejecutarse en
Siem pre debem os buscar la cohesión m ás alta, aunque la
un o rd e n e sp e c ífic o , ex iste co h esió n p ro c e d im e n ta l.
parte m edia del espectro suele ser aceptable. L a escala de
C uando todos los elem entos de procesam iento se cen
cohesión no es lineal. Es decir, la parte baja de la c o h e
tran en un área de u n a estructura de datos, tenem os pre
sio n e s m ucho «peor» que el ran g o m edio, que es casi tan
sente un a cohesión de com unicación. U na cohesión alta
«bueno» com o la parte alta de la escala. En la práctica, un
se caracterizap o r un m ódulo que realiza una única tarea.
diseñador no tiene que preocuparse de categorizar la cohe
sión en u n m ódulo específico. M ás bien, se d eberá en ten
der el concepto global, y así se deberán evitar los niveles
bajos de cohesión al diseñar los códigos. Si nos concentramos en unosola cosodurante e Idiseño
E n la p arte in fe rio r (y n o d eseab le) del e sp e c tro , a nivel de componentes, hoy que realizarlo con cohesión.
encontrarem os un m ódulo que lleva a cabo un conjunto
de tareas que se relacio n an con otras débilm ente, si es C om o y a se h a m e n c io n a d o a n te rio rm e n te , n o es
que tien en algo que ver. T ales m ódulos se denom inan necesario determ inar el nivel preciso de cohesión. Más
coincid en ta lm en te cohesivos. U n m ó d u lo que re aliza bien, es im portante intentar conseguir u n a cohesión alta
www.FreeLibros.org
tareas relacionadas lógicam ente (por ejem plo, un m ó d u y reconocer cu an d o hay p o ca cohesión para m odificar
lo que produce todas las salidas in d ep endientem entedel el diseño del softw are y conseguir una m ay o r in d epen
tipo) es lógicam ente cohesivo. C uando un m ódulo co n dencia funcional.
230
C A P Í T U L O 13 C O N C E P T O S Y P R IN C IP IO S EE D ISEÑ O
13.5.3. A c o p la m ie n to E n n iv e les m o d erad o s el a c o p la m ie n to se c a ra c te

El acoplam iento es u n a m ed id a de in terconexión entre riz a p o r el paso de co n tro l e n tre m ó d u lo s. E l a c o p la
módulos dentro de u n a estru ctu ra de softw are. E l aco m ien to de co n tro l es m uy co m ú n e n la m a y o ría de los
plamiento depende de la com plejidad de interconexión diseñ o s de softw are y se m u estra e n la F ig u ra 13.6 e n
entre los m ódulos, el pun to donde se realiza una e n tra d o n d e u n « in d ic a d o r d e c o n tro l» (u n a v a ria b le q u e
da o referencia a un m ódulo, y los datos que pasan a tra controla las decisiones en un m ó d u lo superior o su b o r
vés de la interfaz. d in a d o ) se p a sa en tre los m ó d u lo s d y e.
En el diseño del softw are, intentam os conseguir el C u a n d o lo s m ó d u lo s e s tá n a ta d o s a u n e n to rn o
acoplam iento m ás bajo posible. U n a conectividad sen ex tern o al softw are se dan n iv e le s rela tiv am e n te altos
cilla entre los m ódulos da co m o resultado u n softw are de acoplam iento. P o r ejem plo, la E/S ‘acoplaun m ó d u
más fácil de entendery m enos propenso a tener un «efec lo a d isp o sitiv o s, fo rm a to s y p ro to c o lo s de c o m u n i
to ola» [STE75] causado cu an d o ocurren errores en un c a c ió n . E l a c o p la m ie n to e x te rn o e s e s e n c ia l, p e ro
lugar y se pro p ag an p o r el sistem a. d eb e rá lim itarse a un o s p o co s m ó d u lo s e n u n a e s tru c
tu ra. T am b ié n ap a re ce u n a c o p la m ie n to a lto cu an d o
v ario s m ó d u lo s h ac en refe ren cia a u n área g lobal de
d ato s. E l a c o p la m ie n to c o m ú n , tal y c o m o se d e n o
CLAVE m in a e s te c a s o , se m u e s tra e n la F ig u ra 13.8. L o s
Eacoplamiento es una indicación cualitativa m ó d u lo s c, g y k acced en a e le m e n to s d e d a to s e n un
del grado de conexión de un módulo con otros área de d ato s glo b al (p o r e je m p lo , u n a rc h iv o de d is
y con el mundo exterior.
co o u n á re a de m e m o ria to ta lm e n te a c c e sib le ). E l
La F igura 13.6 p ro p o rcio n a ejem plos de diferentes m ó d u lo c in icializ a el e lem en to . M ás tard e el m ó d u
tipos de acoplam iento de m ódulos. L os m ódulos a y d lo g v u e lv e a c a lc u la r el e le m e n to y lo a c tu a liz a .
son subordinados a m ódulos diferentes. N inguno está S u p o n g am o s que se p ro d u ce u n e rro r y que g a ctu a
relacionado y p o r tanto n o ocurre un acoplam ientodirec- liza el elem ento incorrectam ente. M u ch o m ás adelante
to. El m ódulo c es subordinado al m ód u lo a y se acce e n el p r o c e s a m ie n to , e l m ó d u lo k le e el e le m e n to ,
de a él m ediante una lista de argum entos p o r la que pasan in te n ta p ro cesa rlo y fa lla , h a c ie n d o que se in te rru m
los datos. S iem pre que tengam os u n a lista convencio p a el sistem a. E l d iag n ó stico d e p ro b le m a s e n e stru c
nal simple de argum entos (es decir, el p aso de datos; la tu ras c o n aco p lam ien to c o m ú n e s c o sto so e n tiem p o
existencia de corresp o n d en cia uno a u no entre elem en y es difícil. S in em bargo, e sto n o sig n ific a n e c e sa ria
tos), se p resenta u n aco p lam ien to b ajo (llam ad o aco- m en te que el uso de datos g lo b ales se a « m alo » . S ig
plum iento de d a to s) en e sta p arte de la estructura. U na n ific a q u e el d is e ñ a d o r d e l s o ftw a re d e b e rá se r
variación del acoplam iento de dato s, llam ado a co p la co n scien te de las c o n secu en cias p o sib le s del a co p la
miento de m arca (sta m p ), se da cuando una parte de la m ie n to c o m ú n y te n e r esp ecial c u id a d o d e p re v e n ir
estructura de datos (en v ez de argum entos sim ples) se se de ellos.
pasa a través de la interfaz. E sto ocurre entre los m ó d u E l g rad o m ás alto de a co p lam ien to , aco p la m ien to
los b y a. de co n te n id o , se d a c u a n d o u n m ó d u lo h ac e u so de
d ato s o de in fo rm ació n de co n tro l m a n te n id o s dentro
de lo s lím ite s d e o tro m ó d u lo . E n se g u n d o lugar, el
aco p lam ien to de c o n te n id o o c u rre c u an d o s e rea liz an
Slstem asaltam enteflfopW os conducen o depurar b ifu rc ac io n es a m itad de m ódulo. E ste m o d o de a co
verdaderas pesadillas. Evítelos. p la m ien to p u ede y d eb erá evitarse.
13^6. HEURÍSTICA DE D ISEÑO PARA UNA MQDULARIDAD EFECTIVA

Una vez que se ha desarrollado u n a estructura de p ro n a d o se c o n v ie rte en d o s m ó d u lo s o m á s e n la
gram a, se puede c o n se g u ir u n a m o d u la rid ad efectiv a estructura final de program a. Un m ódulo im plosio-
aplicando los conceptos de diseño que se introdujeron nudo es el resultado de com binar el proceso im p li
al principio de este capítulo. L a estru ctu ra de program a cado en dos o m ás m ódulos.
se puede m a n ip u la r de acu erd o co n el siguiente c o n
junto de heurísticas:
I. E va lu a r la «prim era itera ció n » de la estru ctu ra de
p ro g ra m a p a r a reducir a l a co p la m iento y m ejorar te buenos técnicas (de diseño) restringen
la co h esió n . U n a v ez que se h a d e sa rro lla d o la dtó'ss am e detir que un artista puede pintor sin
www.FreeLibros.org
estructura del p rogram a, se p u ed en ex p lo sio n a r o jj| formas,odecirqueunmúsico no
im p lo sio n a r los m ó d u lo s co n v istas a m e jo ra r la Mido sobre teoría musical.
in d ep en d en cia del m ódulo. U n m ó d u lo explosio- r a M Zsfcawtti ei al
231
INGENIERÍA DEL SO FTW A R E . UN E N F O Q U E P R Á C T IC O
U n m ódulo e x p lo sio n ad o se suele d ar cuando m ódulo r, tenem os una violación de la heurística

existe un proceso com ún en dos o m ás m ódulos III, porque el módulo r se encuentra fuera del ámbito
y puede redefinirse com o un m ódulo de cohesión de control del módulo e.
separado. Cuando se espera un acoplam iento alto, IV. E valuar las interfaces de los m ódulos p a ra reducir
algunas veces se pueden im plosionar los m ódu la com plejidad y la redundancia, y m ejorar la con
los para re d u cir el paso de control, h acer re fe sistencia. La com plejidad de la interfaz de un
rencia a los datos globales y a la com plejidad de módulo es la prim era causa de los errores del soft
la interfaz. ware. Las interfaces deberán diseñarse para pasar
inform ación de m anera sencilla y deberán ser con
secuentes con la función de un módulo. La incon
sistencia de interfaces (es decir, datos aparentemente
sin relacionar pasados a través de una lista de argu
m entos u otra técnica) es una indicación de poca
cohesión. El m ódulo en cuestión deberá volverse a
evaluar.
V. D efinir m ódulos cu y a fu n ció n se p u e d a predecir,
p e ro evitar m ódulos que sean dem asiado restric
tivos. Un m ódulo es predecible cuando se puede
tratar com o una caja negra; es decir, los mismos
datos externos se producirán independientemente
de los datos in tern o s de p ro c esam ien to 7. Los
m ódulos que pueden tener «m em oria» interna no
podrán predecirse a m enos que se tenga mucho
cuidado en su empleo.
Un m ódulo que restringe el procesam iento a una
sola subfu n ció n exhibe una gran cohesión y es
E vitar e s tr u c tu r a s p la n a s
bien v isto p o r el diseñador. Sin em bargo, un
m ódulo que restringe arbitrariam ente el tamaño
F IG U R A 1 3 .7 . Estructuras de programa. de una estructura de datos local, las opciones den
tro del flujo de control o los m odos de interfaz
II. In ten ta r m in im izar las estructuras con un alto externa requerirá invariablem ente mantenimiento
para quitar esas restricciones.
g rado de s a lid a ; esforzarse p o r la entrada a
m edida que aum enta la profundidad. La estru c
tura que se m uestra dentro de la nube en la Figura
13.7 no hace un uso eficaz de la factorización.
Todos los m ódulos están «planos», al m ism o nivel Referencia W ebl '
y p o r debajo de un solo m ódulo de control. En
B i la dirección de internet www.dacs.dtic.mil/techs/
general, una distribución m ás razonable de co n design/Design.ToChtml se puede enconhor un informe
trol se m uestra en la estructura de la derecha. La detallado sobre los métodos de diseño de software entre los
estructura tom a una form a oval, indicando la can que se incluyen el estudio de todos los conceptos
tidad de capas de control y m ódulos de alta u tili y principios de diseño que se abortan en este capítulo.
dad a niveles inferiores.
III. M antener el ámbito del efecto de un módulo dentro VI. Intentar conseguir módulos de «entrada controlada)),
del ámbito de control de ese módulo. El ámbito del evitando «conexionespatológicas». Esta heurística
efecto de un módulo e se define como todos lo otros de diseño advierte contra el acoplamiento de conte
m ódulos que se ven afectados por la decisión nido. El software es más fácil de entendery por tanto
tom ada en el m ódulo e. El ám bito de control del más fácil de m antener cuando los m ódulos que se
módulo e se compone de todos los m ódulos subor interaccionan están restringidos y controlados. Las
dinados y superiores al módulo e. En la Figura 13.7, conexiones patológicas hacen referencia a bifurca
si el m ódulo e tom a una decisión que afecta al ciones o referencias en m edio de un módulo.
www.FreeLibros.org
7 Un m ódulo de «caja negra, es una abstracción procedimental.
232
C A P Í T U L O 13 C O N C E P T O S Y P R I N C I P I O S DE DISE ÑO
f e ! » E L M O D E L O B E L P t 8 E » Q ______
Los principios y conceptos de diseño abordados en este nosotros querem os crear un d iseño de softw are que sea
capítulo establecen las bases p ara la creación del m o d e estable. C rea re m o s u n m o d elo de d ise ñ o que se ta m
lo de diseño que com prende rep resentaciones de datos, b alee fácilm en te c o n v ien to s de ca m b io al esta b lec er
arquitectura, in terfaces y com ponentes. A l igual que en u n a base a m p lia e n el diseñ o de datos, m ed ian te u n a
el m odelo de análisis anterior al m odelo, cad a una de reg ió n m e d ia estab le e n el diseñ o a rq u itectó n ico y de
estas rep resentaciones de diseño se en cuentran unidas in te rfa z , y u n a p a rte su p e rio r a p lic a n d o el d ise ñ o a
unas a otras y p o d rá n su frir un seg u im ien to h a sta los n iv el de com ponentes.
requisitos del softw are. L os m étodos que conducen a la creación del m o d e
En la F ig u ra 13.1, el m o d e lo d e d is e ñ o se re p re lo de d iseño se presentan en los C apítulos 14, 15, 16 y
sentó com o u n a p irám id e. E l sim b o lism o de e sta fo r 22 (para sistem as o rien tad o s a objetos). C ad a m éto d o
ma es im p o rta n te . U n a p irá m id e e s u n o b je to perm ite que el diseñador cree u n d iseño estable que se
extrem adam ente estab le con u n a base am p lia y con un ajuste a los co n cep to s fu n d am en tales que co n d u cen a
centro de g ra v e d a d b ajo . A l ig u a l q u e la p irá m id e , un softw are de alta calidad.
La E specificación d e l diseñ o a b o rd a d iferen tes asp e c de d ise ñ o p ro ced im e n tal para c o n v e rtir e s a e s tru c tu
tos del m odelo de d iseñ o y se c o m p le ta a m e d id a que ra en u n a d e scrip ció n estructural.
el diseñador re fin a su p ro p ia re p re se n ta ció n del so ft L a E s p e c ific a c ió n d e l d is e ñ o c o n tie n e u n a r e f e
ware. En p rim e r lu g ar, se d e sc rib e el ám b ito g lo b al ren cia cruzada de requisitos. E l pro p ó sito de e sta re fe
del esfu erzo re a liz a d o en e l d iseñ o . L a m a y o r p arte ren c ia c ru za d a (n o rm alm en te re p re se n ta d a c o m o u n a
de la in fo rm a c ió n q u e se p re s e n ta a q u í se d e riv a de m atriz sim ple) es: (1 ) e sta b le c e r que to d o s los re q u i
la E sp e c ific a c ió n d e l siste m a y del m o d e lo d e a n á sito s se satisfag a n m ed ian te el d ise ñ o del so ftw a re , y
lisis (E sp e c ific a c ió n de lo s r e q u isito s d e l so ftw a re ). ( 2 ) in d ic ar c u a le s so n lo s c o m p o n e n te s c rític o s p ara
A c o n tin u ació n , se e s p e c ific a el d is e ñ o de datos. la im p lem e n tac ió n de req u isito s específicos.
Se d efin en ta m b ié n la s e s tru c tu ra s d e la s b a s e s de E l p rim er paso e n el d e sa rro llo de la d o c u m e n ta
datos, c u a lq u ie r e s tr u c tu r a e x te r n a d e a rc h iv o s , ción de p ru eb as tam bién se encuentra den tro del d o c u
estructuras in te rn a s d e d a to s y u n a re fe re n c ia c r u z a m e n to del diseño. U n a vez que se han e sta b le c id o las
da que co n e c ta o b je to s d e d a to s c o n a rc h iv o s e s p e in terfaces y la e stru c tu ra de p ro g ra m a po d rem o s d esa
cíficos. rro lla r las lín e a s g en erales p a ra co m p ro b ar los m ó d u
El d iseñ o a rq u ite c tó n ic o in d ic a có m o se h a d e ri los in d iv id u a le s y la in te g ra ció n de to d o el paquete.
vado la a rq u ite c tu ra del p ro g ra m a del m o d elo de a n á E n algunos ca so s, e sta secció n se p o d rá b o rra r d e la
lisis. A dem ás, p ara rep resen tar la je ra rq u ía del m ódulo E sp e c ific a c ió n d e l diseño.
se utilizan g ráfico s de estru ctu ras. L as re stric c io n e s de d ise ñ o , ta le s co m o lim ita c io
nes físicas de m e m o ria o la n e ce sid a d de u n a in terfaz
ex te rn a e sp e c ia liz a d a , p o d rán d icta r re q u isito s e sp e
ciales p a ra en sam b la r o e m p aq u etar el softw are. C o n
sid e ra c io n e s e sp e c ia le s o rig in a d a s p o r la n e c e sid a d
de su p e rp o sic ió n de p ro g ra m a s, g estió n de m em o ria
v irtu al, p ro ce sam ie n to de a lta v e lo c id ad u o tro s fa c
Especificacióndel diseño del software to res p o d rá n o rig in ar m o d ific ac io n es e n d ise ñ o d e ri
vadas del flujo o estructura de la inform ación. A dem ás,
Se representa el diseño de interfaces internas y ex ter esta secció n describ e el en fo q u e que se u tiliz a rá p ara
nas de p rogram as y se describe u n diseño detallado de tra n sfe rir so ftw are al clien te.
la interfaz hom bre-m áquina. E n algunos casos, se podrá L a ú ltim a secció n d e la E sp e c ific a c ió n d e l d ise ñ o
representar un prototipo detallado del IG U . c o n tie n e d ato s co m p lem en tario s. T am b ién se p re se n
Los co m p o n en tes — elem en to sd e so ftw are que se tan descripciones de algoritm os, procedim ientos alte r
pueden tratar p o r sep arad o tales co m o subrutinas, fu n n ativos, datos tabulares, extractos de otros docum entos
ciones o p rocedim ientos — se d e sc rib e n in icialm en te y o tro tip o de in fo rm a ció n re le v a n te , to d o s m e d ia n te
con una n arrativ a de procesam ienfo en c u alq u ie r id io n o tas e sp eciales o ap éndices separados. S e rá a c o n se
ma (C astellano, Inglés). L a n arrativ a de p rocesam iento ja b le d esa rro llar un M a n u a l p r e lim in a r de O p e ra c io
www.FreeLibros.org
explica la fu n c ió n p ro c e d im e n ta l de u n c o m p o n e n te n e s /In s ta la c ió n e in c lu irlo c o m o a p é n d ic e p a ra la
(m ódulo). P o sterio rm en te, se u tiliz a u n a h erra m ien ta d o c u m en ta ció n del diseño.
233
I N GE NI E RÍ A DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
I m ü Ü seis
El diseñ o es el n úcleo técnico de la ingeniería del soft visión global de la arquitectura del softw are, m ientras
w are. D urante el diseño se desarrollan, rev isan y do cu que el procedim iento proporciona el detalle necesario
m entan los refinam ientos progresivos de la estructura p a ra la im p le m en tac ió n de los algoritm os. L a oculta
de dato s, arquitectura, in terfaces y d ato s procedim en- ció n de inform ación y la independencia funcional pro
ta les de los c o m p o n e n te s del softw are. E l d ise ñ o da p orcionan la heurística para conseguir una m odularidad
com o resultado representaciones del softw are p ara ev a efectiva.
luar la calidad. C oncluirem osnuestro estudio de los fundam entos del
D urante las cuatro últim as décadas se han propuesto diseño con las palabras de G lendord M yers [MYE78]:
d ife re n te s p rin c ip io s y c o n c e p to s fu n d a m e n ta le s del
Intentamos resolver el problema dándonos prisa en el pro
d iseñ o del softw are. L os p rin c ip io s del d iseñ o sirven ceso de diseño de forma que quede el tiempo suficiente hasta
de gu ía al in g en iero del so ftw are a m edida que avan el final del proyecto como para descubrir los errores que se
za el p ro ceso de diseño. L os co n cep to s de d iseñ o p ro cometieron por correr en el proceso de diseño...
p o rc io n a n los c rite rio s b á sic o s p a ra la c a lid a d del
diseño. L a m oraleja es: ¡No te precipites durante el diseño!
L a m od u larid ad (tanto en el pro g ram a co m o en los M erece la pena esforzarse p o r un buen diseño.
datos) y el concepto de abstracción perm iten que el dise N o hem os term inado nuestro estudio sobre el dise
ñ ado r sim plifique y reutilice los com ponentes del soft ño. E n los capítulos siguientes, se abordan los métodos
ware. El refin am ien to p ro p o rcio n a un m ecanism o para de diseño. E stos m éto d o s co m b in ad o s con lo s funda
representar sucesiv ascap as de datos funcionales. El p ro m entos de este cap ítu lo , fo rm an la base de una visión
gram a y la estructura de datos contribuyen a ten er una com pleta del diseño del softw are.
BEFE&SNCIAS
[AH083] Aho, A.V.J., Hopcroft, y J. Ullmann, Data Struc- [JAC92] Jacobson, I., Object-Oriented Software Engineering,
tures andAlgorithms, Addison-Wesley, 1983. Addison-Wesley, 1992.
[BAS89] Bass,L.,P. Clementsy R. Kazman, Software Archi- [KRU84] Kruse R.L., Data Structures and Program Design,
tecture in Practice, Addison-Wesley, 1998. Prentice-Hall, 1984.
[BEL81] Belady, L., Foreword to Software Design: Methods [MCG91] M cGlaughlin, R., «Some Notes on Program
and Techniques (L.J. Peters, autor), Yourdon Press, 1981. Design», Software Engineering Notes, vol. 16,n.° 4, Octu
bre 1991, pp. 53-54.
[BR098] Brown, W.J. et al., Anti—
Patterns, Wiley, 1998.
[MYE78] Myers, G., CompositeStructuredDesign, VanNos-
[BUS96] Buschmann, F. et al., Pattem -O riented Software
trand, 1978.
Architecture, Wiley, 1996.
[MEY88] Meyer, B., Object-Oriented Software Construction,
[DAV95] Davis, A., 201 Principies o f Software Development,
Prentice-Hall, 1988.
McGraw-Hill, 1995.
[MIL72] Mills, H.D., «Mathematical Foundations for Struc
[DEN73] Dennis, J., «Modularity», in Advanced Course on
tured Programming», TechnicalReportFSC71-6012,IBM
Software Engineering, F.L. Bauer, ed., Springer-Verlag,
Corp., Federal Systems Division, Gaithersburg, Maryland,
Nueva York, 1973, pp. 128-182.
1972.
[GAM95] G am m a,E.,et al,DesignPatterns, Addison-Wes
[NAS73] Nassi, I., y B. Shneiderman, «Flowchart Techni
ley, 1995.
ques for Structured Programming», SIGPLAN Notices,
[GAN89] Gannet, G .,H andbook o f A lgorithm s and Data ACM, Agosto 1973.
Structures, 2.a ed, Addison-Wesley, 1989.
[ORR77] O n, K.T., Structured Systems Development, Your
[GAR95] Garlan, D., y M. Shaw, «An Introduction to Soft don Press, Nueva York, 1977.
ware Architecture», Advances in Software Engineering
[PAR72] Pamas, D.L.,«On Criteria to be used in Decompo-
and Knowledge Engineering, vol. 1, V. Ambriolay G. Tor sing Systems into Modules», CACM, vol. 14,n.° 1, Abril
tora (eds.), World Scientific Publishing Company, 1995. 1972, pp. 221-227.
[JAC75] Jackson, M . A Principies o f ProgramDesign, Aca- [ROS75] Ross, D., J. Goodenough y C. Irvíne, «Software
demic Press, 1975. Engineering: Process, Principies and Goals», IEEE Com
[JAC83] Jackson, M.A., System Development, Prentice-Hall, puter, vol. 8, n.° 5, Mayo 1975.
1983. [SHA95a] Shaw, M., y D. Garlan, «Formulations and For-
www.FreeLibros.org
[KAI83] Kaiser, S.H., The Design o f OperatingSystemsfor Small malisms in Software Architecture», Volunte 1000-Lectu-
Computer Systems, Wiley-Inerscience, 1983, pp. 594 ss. re Notes in Computer Science, Springer Verlag, 1995.
234
C A P Í T U L O 13 C O N C E P T O S Y P R IN C IP IO S DE D IS E Ñ O
[SHA95b] Shaw, M. et al., «Abstractions for Software Archi- [WAR74] Wamier, 1., Lógica! Constructionof Programs, Van
tecture and Toolsto SupporiThem», IEEE Truns. Software No strand-Reinhold, 1974.
Engineering, vol. 21, n.° 4, Abril 1995,pp. 314-335. [WAS83] Wasserman, A., «Information System Design
[SHA96] Shaw, M., y D. Garlan, Software Architecture, Methodology», in Software Design Techniques (P. Free-
Prentice-Hall, 1996. man y A. Wasserman, eds.), 4.a ed., IEEE Com puter
Society Press, 1983,p. 43.
[SOM96] Sommerville, I., Software Engineering, 3.a ed.,
Addison-Wesley, 1989. [WIR71] Wirth, N., «Program Developm ent by Stepwise
Refinement», C4CM, vol. 14,n.°4, 197l,pp.' 221-227.
[STE74] Stevens, W, G. Myers y L. Constantine, «Structu-
rcd Design», IBM Systems Journal, vol. 13,n.° 2, 1974, [YOU79] Yourdon, E., y L. Constantine, StructuredDesign,
pp. 115-139. Prentice-Hall, 1979.
B H B L 4 X Ü .V i l i t f e t iii>
13.1. Cuando se «escribe» un programa, ¿se está diseñan e. cualquier problema que hayan acordado usted y su pro
do software? ¿En qué se diferencia el diseño del software fesor.
de la codificación?
Conforme disminuye el grado de abstracción, su foco de
13.2. Desarrolle tres principios de diseño adicionales que atención puede disminuir de manera que en la última abs
añadir a los destacados en la Sección 13.3. tracción (código fuente) solo se necesite describir una úni
ca tarea.
13.3. Proporcione ejemplos de tres abstracciones de datos
y las abstracciones procedimentales que se pueden utilizar 13.8. Obtenga el trabajo original de Pamas [PAR72] y resu
para manipularlos. ma el ejemplo de software que utiliza el autor para ilustrar
la descom posición en m ódulos de un sistema. ¿Cómo se
13.4. Aplique un «enfoque de refinam iento paso a paso»
utiliza la ocultación de información para conseguir la des
para desarrollar tres niveles diferentes de abstracción pro-
composición?
cedimental para uno o más de los programas que se mues
tran a continuación: 13.9. Estudie la relación entre el concepto de ocultación de
a. Desarrolle un dispositivo para rellenar los cheques que, información como atributo de modularidad eficaz y el con
dada la cantidad numérica en pesetas, imprima la canti cepto de independencia del módulo.
dad en letra tal y como se requiere normalmente. 13.10. Revise algunos de los esfuerzos que haya realiza
b. Resuelva iterativamente las raíces de una ecuación trans do recientem ente en desarrollar un software y realice un
cendental. análisis de los grados de cada m ódulo (con una escala
ascendente del 1 al 7). Obtenga los m ejores y los peores
c. Desarrolle un simple algoritmo de planificación round- ejemplos.
robin para un sistema operativo
13.11. Un grupo de lenguajes de programación de alto nivel
13.5. ¿Es posible que haya algún caso en que la ecuación soporta el procedimiento interno como construcción modu
(13.2) no sea verdad? ¿Cómo podría afectar este caso a la lar. ¿Cómo afecta esta construcción al acoplamiento y a la
modularidad? ocultación de información?
13.6. ¿Cuándo deberá im plem entarse un diseño m odular 13.12. ¿Qué relación tienen los conceptos de acoplamien
ccmo un software m onolítico? ¿Cómo se puede llevar a to y de movilidad del software? Proporcione ejemplos que
cabo? ¿Es el rendim iento la única ju stificación para la apoyen esta relación.
implementación de software monolítico?
13.13. Haga un estudio de la manera en que ayuda la par
13.7. Desarrolle al menos cinco niveles de abstracción para tición estructural para ayudar a mantener el software.
uno de los problemas de software siguientes:
13.14. ¿Cuál es el propósito de desarrollar una estmctura
a. un vídeo-juego de su elección. de programa descompuesta en factores?
b. un software de transformación en tres dimensiones para
13.15. Describa el concepto de ocultación de información
aplicaciones gráficas de computador. con sus propias palabras.
c. un intérprete de lenguajes de programación.
13.16. ¿Por qué es una buena idea m antener el efecto de
d. un controlador de un robot con dos grados de libertad. alcance de un módulo dentro de su alcance de control?
ING EN IE RÍA DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
.QTRASJLECI.UR A S Y FUENTES DE INFO RM ACIÓ N

D o n ald N o rm an ha escrito dos libros f TheDesign ofEvery- D entro de una antología editada por Freem an y Wasser-
day Things, D oubled ay, 1 99 0,y The Psychology d Everyday m an (Software Design Techniques,4r ed., IE E E , 1 9 8 3 )se
Things, H arpercollins, 1988) que se han convertido en c lá encuentra un estudio histórico excelente de trabajos impor
sicos de literatura de diseño y es una lectura «obligada» para tantes sobre diseño del software. Este trabajo de enseñanza
todos los que diseñan cualquier cosa que el ser hum ano va reim p rim e muchos de lo s trabajos clásicos que han formado
utilizar. A dam s (ConceptualBlockbusting, 3." ed. A ddison - la base de las tendencias actuales en el diseño del software.
W esley, 1986) ha escrito un libro que es una lectura esencial Buenos estudios sobre los fundam entos del diseño de soft
para los diseñadores que quieren am p liar su fo rm a de pen w are se pueden encontrar en los libros de M y e rs [MYE78],
sar. Finalm ente un texto clásico de P olya (How to Solve It, Peters (Software Design: Methods and Techniques, Youtdcn
2 . " ed., P rinceton U n iv e rs ity Press, 1 9 8 8 ) proporciona un Press, N u e v a Y o rk , 1981), M a c ro (SoftwareEngineering:
proceso genérico de resolver problem as que puede servir de Concepts and M anagem ent, P re n tic e -H a ll, 1 9 9 0 ) y Som-
ayuda a los diseñadores cuando se enfrentan con problem as m e rv ille (SoftwareEngineering, A d d iso n -W esley, 5.a ed.,
complejos. 1995). '
Siguiendo la m ism a tradición, W in o g rad et al. (Bringing Tratam ientos m atem áticam ente rigurosos del software de
to Software, A d d iso n -W esley, 1996) aborda los diseños del com putadora se pueden encontrar en los libros de Jones ( Soft
softw are que funcionan, los que no funcionan y las razones. ware Development: A Rigourous Approach, Prentice-H all,
U n lib ro fascinante ed itad o por W ix o n y R am sey (Field 198 0), W u lf (FundamentalStructures o f Computer Science,
Methods Casebookfor Software Design, W ile y , 1996) sugie A d d iso n -W esley, 1 98 1) y Brassard y B ratley (Fundamental
re los «métodos de investigación de campos» (m uy sim ilares o f Algorithmics, P re n tic e-H a ll, 1995).
a los que u tiliza n los antropólogos) para entender cóm o rea Todos estos libros ayudan a proporcionarel fundamento teó
liza n los usuarios el trabajo que realizan y entonces diseñar rico necesario para com prender el softw are de computadora.
el softw are que cubra sus necesidades. B e y e r y H o ltz b la tt Kruse (DataStructures and Program Design, Prentice-Hall,
(Contextúa!Design: A Customer-C entreved Approach to Sys 1 9 9 4 )y Tu c ke re t al. (Fundamental o f Computing II: Abstrae-
tems, A cadem ic Press, 1997) ofrecen otra visión del diseño tion, Data Structures, and Large Software Systems, McGraw-
de softw are que integra al cliente/usuario en todos los aspec H ill, 1995)presentan una inform ación valiosa sobre estructuras
tos del proceso de diseño del software. de datos. Las medidas de calidad de diseño presentadas desde
M c C o n n e ll (CodeComplet.e, M icro so ft Press, 1 99 3)p re- una perspectiva técnica y de gestión son abordadas por Card y
senta un estudio excelente de los aspectos prácticos para el Glass (Measuring Design Quality, Prentice-H all, 1990).
diseño de softw are de com putadora de alta calidad. R obert- U n a am plia variedad de fuentes de inform ación sobre el
son (SimpleProgram Design, 3.a ed., B o yd & Fraser Publis- diseño del softw are y otros temas relacionados están dispo
hing) presenta un estudio introductoriode diseño del software nibles en In tem et. U n a lista actualizada de referencias rele
que es ú til para aquellos que em p iezan a estudiar sobre el vantes para los conceptos y m étodos de diseño se puede
tema. encontrar en http://www.pressman5.com
C A P ÍT U L O
D IS E Ñ O A R Q U IT E C T Ó N IC O
L diseño se ha descrito como un proceso multifase en el que se sintetizan representacio
E nes de la estructura de los datos, la estructura del program a, las características de la inter
faz y los detalles procedimentales desde los requisitos de la información. Esta descripción
es ampliada por Freeman [FRE80]:
E l d ise ñ o es una actividad en la que se to m an decisio n es im p o rtan tes, frecu en tem en te d e n a tu ra le z a
estructural. C om parte con la p ro g ram ació n un interés por la a b strac ció n de la re p re se n tac ió n d e la in fo r
m ación y de las secuencias de procesam iento, pero el nivel de d etalle es m uy d iferente en am bos casos. E l
d iseño co n stru y e re p resen tacio n es c oherentes y bien planificadas d e los p ro g ram as, con cen trán d o se en las
interrelaciones de los com p o n en tes de m ayor nivel y en las operacio n es ló g icas im p licad as en los niveles
in fe rio re s...
Como dijimos en el capítulo anterior, el diseño está dirigido por la información. Los m éto
dos de diseño del software se obtienen del estudio de cada uno de los tres dominios del m ode
lo de análisis. El dominio de los datos, el funcional y el de comportamiento sirven de directriz
para la creación del diseño.
En este capítulo se introducen los m étodos requeridos para la creación de «rep resen ta
ciones coherentes y bien planeadas» de los datos y las capas arquitectónicas del m odelo de
diseño. El objetivo es proporcionar un enfoque sistem ático para la o b ten ció n del diseño
arquitectónico — el anteproyecto prelim inar desde el que se construye el software— .
VISTAZO RÁPIDO
4%»é es? El diseño arquitectónico repre sitos derivados durante el análisis de el fin de obtener la estructura que
sente Sa estructura de los datos y los la ingeniería del sistema y de los mejor se ajusta a los requisitos del
componentes del programa que se requisitos del software. cliente y a las normas de calidad. Una
requieren para construir un sistema ¿Por q ué es im portante? En la sección vez que es seleccionada una de las
iwsado en computadora. Constituye Vistazo rápido del capítulo anterior pre alternativas, la arquitectura se elabo
el estilo arquitectónico que tendrá el guntamos: «No serias capaz de inten ra utilizando el método de diseño
sistema, la estructura y las propie tar construir una casa sin un plano, arquitectónico.
dades de los componentes que ese ¿verdad?» Tú tampoco comenzarías el ¿ C u á l e s e l p r o d u c to o b te n id o ?
sistema comprende, y las interrela- esbozo del plano por los bosquejos del Durante el diseño arquitectónico se
cíones que tienen lugar entre todos diseño de tuberías de la casa. Necesi crea un modelo de arquitectura que
los componentes arquitectónicos del tarlas ver la foto completa —la casa en abarca la arquitectura de datos y la
sistema. ai misma— antes de preocuparte por estructura del programa. Además, se
¿Quién lo h a ce? Aunque los ingenie los detalles. Esto es lo que el diseño describen las propiedades de los com
ros del software pueden diseñar tan arquitectónico hace —proporciona la ponentes y sus relaciones (interac
to los datos como la arquitectura, foto completa y asegura que lo estás ciones).
cuando se trata de construir sistemas haciendo bien —. ¿Cómo p u e d o e sta r se g u r o d e q u e
grandes y complejos, el trabajo es, a ¿C uáles <s»a. los p ases? El diseño arqui lo h e h e c h o c o r r e c ta m e n te ? En
menudo, asignado a especialistas. El tectónico comienza con el diseño de cada etapa, los productos resultantes
diseñador de una base de datos o ún datos y después procede a la deriva del diseño del software son revisados
almacén de datos crea la arquitectu ción de una o más representaciones de para clarificar, corregir, completar y
ra de datos para el sistema. El «arqui- la estructura arquitectónica del siste dar consistencia acorde a los requi
iecto del sistema» selecciona un estilo ma. Los estilos arquitectónicos alter sitos establecidos, y entre unos y
arquitectónico apropiado a los requi nativos o patrones son analizados con otros.
in g e n ie ría del so f t w a r e , un e n fo q u e p rá c tic o
Shaw y Garlan [SHA96], en su libro de referencia sobre alternativas arquitectónicasen u n a etapa en la cual hacer
la m ateria, tratan la arquitectura del softw are de la cam bios en el diseño es relativam entefácil, y (3) reducir
siguiente forma: los riesgos asociados a la construcción del software.
Incluso desde que el prim er program a fue dividido en m ódu
los, los sistemas de softw arehan tenido arquitecturas,y los pro-
g ram adoreshan sido responsablesde sus interaccionesa través
de m ódulos y de las propiedades globales de ensam blaje. H is
tóricam ente, las a rq u itectu ras han estado im p lícitas — bien
com o accidentes en la im plem entación, bien com o sistem as
legados del p a s a d o - . L os buenos desarrolladores de softw a
re han adoptado, a m enudo, uno o varios patrones arquitectó
nicos co m o e strateg ias de o rg an izació n del sistem a, pero
utilizaban estos patrones de m odo inform al y no tenían ningún L a definición presentada anteriorm ente enfatiza el,
interés en hacerlos explícitos en el sistem a resultante. papel de los «com ponentes del softw are» en cualquier
Hoy, la arquitectura de software operativa y su repre representación arquitectónica. E n el contexto del dise
sentación y diseño explícitos se han convertido en temas ñ o arquitectónico, un com ponente del softw are puede
dominantes de la ingeniería de software. ser tan sim ple com o un m ódulo de program a, pero tam
b ién puede ser algo tan com plicado co m o incluir bases
de datos y softw are interm edio («middleware») queper-
14.1.1. ¿Q u é e s a rq u itectu ra ?
m iten la configuración de u n a red de clien tes y servi
C uando hablam os de la «arquitectura» de un edificio, dores. Las propiedades de los com ponentes son aquellas
nos vienen a la cabeza diferentes atributos. A nivel más características necesarias para entender cóm o los com
básico, pensam os en la form a global de la estructura p o n en tes in te ra ctú a n con otros co m ponentes. A nivel
física. Pero, en realidad, la arquitectura es m ucho más. arquitectónico, no se especifican las propiedades inter
E s la form a en la que los diferentes com ponentes del nas (p o r ejem plo, detalles de un algoritm o). Las rela
edificio se integran para form ar un todo unido. Es la for ciones entre los com ponentes pueden ser tan sencillas
m a en la que el edificio encaja en su entorno y con los co m o u n a llam a d a de p ro c ed im ien to de un m ódulo a
otros edificios de su vecindad. Es el grado en el que el otro, o tan com plicadas com o el protocolo de acceso a
edificio consigue su propósito fijado y satisface las nece bases de datos.
sidades de sus propietarios. Es el sentido estético de la En este libro, el diseño de la arquitectura de software
estructura— el impacto visual del edificio— y el m odo tien e en c u en ta do s niveles de la p irám id e del diseño
en el que las texturas, los colores y lo s materiales son (Fig. 13.1)— el d iseño de datos y a rq u ite c tó n ic o -. En
combinados para crear la fachada extem a y el «entor este sentido, el diseñ o de datos nos facilita la represen
no vivo» interno. Son los pequeños detalles - e l dise tación de los com ponentes de datos de la arquitectura.
ñ o de las instalaciones eléctricas, del tipo de suelo, de E l diseño arquitectónico se centra en la representación
la colocación de tapices y una lista casi interminable — . de la e stru c tu ra de lo s co m p o n en tes del softw are, sus
Y, finalmente, es arte. propiedades e interacciones.
14.1.2. ¿Por qué e s importante la arquitectura?

Referencia Web! E n su libro dedicado a la arquitectura de software, Bass
Se puede encontrar una lista útil de recursos de y sus colegas [BAS98] identifican tres razones clave por
arquitectura de software en www2.umassd.edu/ las que la arquitectura de softw are es importante:
SECenter/SAResources.html
• las representaciones de la arquitectura de software
Pero, ¿qué pasa con la arquitectura de softw are? Bass facilitan la com unicación entre todas las partes (par
y sus colegas [BA S98] definen este esquivo térm ino de tícip e s) in teresad a s en el d esarro llo de un sistema
la siguiente form a: basado en com putadora;
L a arquitectura de softw are de un sistem a de program a o • la a rq u ite c tu ra d e sta c a d e c isio n e s tem pranas de
com putación es la estructura de las estructuras del sistem a, la diseño que tendrán un profundo im pacto en todo el
cual com prende los com ponentes del softw are, las propieda trabajo de ingeniería del softw are que sigue, y es tan
des de esos com ponentes visibles externam ente, y las relacio im p o rtan te en el éx ito fin a l del sistem a com o una
nes entre ellos.
entidad operacional;
L a arquitecturano es el software operacional. M á s bien, • la arquitectura «constituye un m odelo relativamente
www.FreeLibros.org
es la representación que capacita al ingeniero del softw a pequeño e intelectualm ente com prensible de cómo
re para: (1) analizar la efectividad del diseño p ara la co n está estructurado el sistem a y de cóm o trabajan jun
secución de los requisitos fijados, (2) con sid erar las tos sus com ponentes» [BAS98],
238
CA P Í T U L O 14 DI SE ÑO A R Q U I T E C T Ó N I C O
El m o d elo de d iseño arq u itectó n ico y los p atro n es

arquitectónicoscontenidos dentro son transferibles. Esto
es, los estilos y patrones de arquitectura (S ección 14.3.1)
p ueden ser aplicad o s en el diseñ o de otros sistem as y
El modelo arquitectónico proporciono unovisión «Gestalt»
representados a través de un conjunto de abstracciones
del sistema, permitiendo al Ingeniero del software
examinarlo como untodo. que fa cilitan a los ingenieros del softw are la d esc rip
ción de la arquitectura de un m odo predecible.
! ■ : ; ..................■ - . tos
Al igual que otras actividades de la ingeniería del soft D urante m uchos años, la arquitectura de datos estu
ware, el diseño de d atos (a veces llam ado arquitectura vo lim itada, generalm ente, a las estructuras de datos a
de datos) crea un m odelo de datos y/o inform ación que nivel del p rogram a y a las bases de datos a nivel de apli
se representa con un alto n ivel de abstracción (la visión cación. P ero hoy, las em presas grandes y pequeñas están
de datos del cliente/usuario). E ste m odelo de datos, es in u n d a d a s de d ato s. N o es in u su a l, in c lu so p a ra u n a
entonces refinado en p ro gresivas representaciones esp e m ediana em presa, ten er docenas de bases de datos sir
cificas de la im plem entación, que p u ed en ser procesa viendo diferentes aplicaciones de cientos de gigabytes
das por un sistem a b asado en com putadora. E n m uchas de d ato s. E l d e sa fío de las e m p re sa s h a sido e x tra e r
aplicaciones de softw are, la arquitectura de datos ten inform ación útil de su entorno de datos, particu larm en
drá una gran influencia sobre la arquitectura del soft te cuando la inform ación deseada está funcionalm ente
ware que debe procesarlo. in te rre la cio n ad a (por e je m p lo , in fo rm ac ió n que sólo
La estru ctu ra de d a to s h a sid o sie m p re u n a p arte puede obtenerse si los datos de m arketing específicos
importante del diseño de softw are. A l nivel de los co m se cruzan con los datos de la ingeniería del producto).
ponentes del p rogram a, el d iseñ o de las e stru ctu ras de P ara resolver este d esafío, la com unidad de e m p re
datos y de los algoritm os asociados requeridos para su sas de T I h a d e sa rro lla d o las técn icas de m in e ría de
manipulación, son la p arte esen cial en la cre ac ió n de datos, ta m b ié n lla m a d a s d e sc u b rim ie n to de c o n o c i
aplicaciones de alta calidad. A n ivel de ap licación, la m iento en bases de datos (D C B C ), que navegan a tra
traducción de un m odelo de datos (derivado com o p ar vés de las bases de datos en un inten to p o r e x trae r el
te de la ingeniería de req u isito s) en u n a base de datos nivel de inform ación de negocio apropiado. Sin e m b a r
es el punto clave p ara a lcan zar los o b jetiv o s de n e g o go, la existencia de m últiples bases de datos, sus d ife
cio del sistem a. A n iv el de n e g o c io s, el c o n ju n to de rentes estru ctu ras, el grad o de detalle co n ten id o en las
iftformación a lm a c e n a d a en las d ife re n te s b a se s de bases de datos, y m uchos otros factores hacen d ifícil la
datos y reorganizada en el alm acén de d ato s facilita la m in e ría de d a to s d e n tro de un en to rn o co n b a se s de
tninería de datos o el d esc u b rim ie n to de c o n o cim ie n d ato s e x iste n te s. U n a so lu c ió n a lte rn a tiv a , lla m a d a
to que puede influ ir en el p ropio éx ito del negocio. De alm acén de datos, añade u n a cap a adicional a la a rq u i
cualquier m odo, el diseño de datos ju e g a un papel m uy tectu ra de datos.
importante.
14.2.1. M o d e la d o d e d a t o s , e s t r u c t u r a s d e d a t o s ,
b a se s d e d a to s y a lm a c é n d e d a to s
í
Para obtener Información actualizado sobre tecnologías
Los objetos de d ato s d efin id o s d u ran te el an álisis de
de olmocén de datos visitar:
tequisitos del softw are son m odelad o s u tilizando dia
www.datawarehouse.com
gramas de e n tid a d -re lac ió n y el d iccio n ario de d ato s
(Capítulo 12). L a actividad de diseño de datos traduce
fsos elem entos del m odelo de requisitos en estructuras U n alm a cén de datos es un e n to rn o de d ato s se p a
de datos a nivel de los com ponentes del softw are y, cuan rad o , que no e stá directam en te in teg rad o con las a p li
do es necesario, a arquitectura de base de datos a nivel caciones del día a día, p ero que abarca to d o s los d ato s
de aplicación. utilizad o s p o r una em p resa [M AT96], E n cierto se n ti
do, un alm acén de datos es una gran base de datos in d e
Q c ita : p e n d ie n te , que c o n tie n e a lg u n o s, p e ro n o to d o s lo s
datos alm acen ad o s en las b ases de datos que sirv en al
plfiéofcfcjd de los datos es lo que marca
conjunto de aplicaciones requeridas en un negocio. Sin
www.FreeLibros.org
llif e f e n c io entre un olmocén de datos
em bargo, hay m uchas características diferenciales entre
y ó it t e w e r o de dolos.
un a lm a c é n d e d a to s y u n a b ase d e d a to s típ ic a
fe w ft Rossoberg
[IN M 95]:
239
in g e n ie r ía del s o f t w a r e , un e n fo q u e pr a c tic o
O rie n ta ció n p o r m a te ria . Un almacén de datos y revisarse, las de objetos de datos deberían identifi
está organizado por las m aterias im portantes del carse, se deberían estudiar las organizaciones alter
negocio, más que por los procesos o funciones del nativas de datos y debería evaluarse el im pacto del
negocio. Esto nos lleva a una exclusión de datos que m odelado de datos sobre el diseño del software. P o r
podrían ser necesarios para una función particular ejem plo, la especificación de u n a lista enlazada con
del negocio, pero que generalmente no son necesa m últiples anillos puede satisfacer los requisitos de los
rios para la m inería de datos. datos pero puede llevar a un diseño del softw are poco
Integración. Sin tener en cuenta la fuente de datos, flexible. U n a organización de datos alternativa nos
da consistencia nom brar convenciones, unidades y po d ría llevar a obtener m ejores resultados.
medidas, estructuras de codificación y atributos físi
cos incluso cuando la inconsistencia existe a través de ¿Qué principios son aplicables
las diferentes bases de datos orientadas a aplicaciones. para el diseño de datos?
R estricciones de tiem po. Para un entorno de apli
cación orientado a transacción, los datos son precisos 2. Todas las estructuras de datos y las operaciones a lle
en el momento del acceso y por un periodo de tiempo var a cabo en cada una de ellas deberían estar clara
relativamente pequeño (normalmente de 60 a 90 días) mente identificadas. E l d iseño de u n a estructura de
antes del acceso. Sin embargo, en un almacén de datos, datos eficaz debe tener en cuenta las operaciones que
se accede a los datos en un m om ento específico del se van a llevar a cabo sobre dicha estructura de datos
tiem po (por ejemplo, los clientes con los que se ha (vea [A H 083]). P or ejem plo, im agínese una estruc
contactado el mismo día que el nuevo producto ha sido tura de datos h ech a con un conjunto de elementos de
anunciado en la prensa comercial). El horizonte típico datos diversos. L a estru ctu rad e datos se va a manipu
de tiem po de un almacén de datos es de 5 a 10 años. lar con varias funciones principales del software. Des
No v o latilidad. A diferencia de las típicas bases pués de la evaluación de la operación realizada sobre
de datos de aplicaciones de negocios que atraviesan la estructura de datos, se define un tipo de datos abs
una continua corriente de cambios (insertar, borrar, tracto para usarlo en el diseño del software subsiguiente.
actualizar), en el almacén de datos los datos se car L a especificación de los tipos de datos abstractospuede
gan, pero después de la prim era transferencia, los sim plificar considerablem enteel diseño del software.
datos no cambian. 3. Se debería establecer un diccionario de datos y
usarlo p a ra definir el diseño de los datos y delpro-
grama. El concepto de diccionario de datos se intro
CLAVE d u jo en el C ap ítu lo 12. U n d ic c io n a rio de datos
rep re se n ta ex p lícitam en te las re la cio n e s entre los
Un almacén de datos contiene todos los datos utilizados
en una empresa. Su objetivo es facilitar el acceso
objetos de datos y las restricciones de los elementos
a ((conocimiento)) que de otro modo no se dispondría. de una estructura de datos. L os algoritm os que deben
aprovecharse de estas relaciones específicas pueden
Estas características presentan un cuadro Único de definirse m ás fácilm ente si existe una especificación
desafíos de diseño para el arquitecto de datos. de datos tipo diccionario.
4. Las decisiones de diseño de datos de bajo nivel debe
14.2.2. D ise ñ o d e d a to s a n iv e l d e c o m p o n en te s rían dejarse p a ra elfin a l del proceso de diseño. Se
El diseño de datos a nivel de componentes se centra puede usar un proceso de refinamiento paso a paso para
en la representación de estructuras de datos a las que se el diseño de datos. Es decir, la organización general de
accede directamente a través de uno o m ás com ponen datos puede definirsedurante el análisis de requisitos;
tes del software. W asserman [WASSO] ha propuesto un refinarse durante los trabajos de diseño de datos y espe
conjunto de principios que pueden emplearse para espe cificarse en detalle durante el diseño a nivel de com
cificar y diseñar dicha estructura de datos. En realidad, ponentes. El enfoque descendentedel diseño de cfefca
el diseño de datos empieza durante la creación del m ode proporciona ventajas análogas al enfoque descendente
lo de análisis. Recordando que el análisis de requisitos del diseño de software: se diseñan y evalúan primera
y el diseño a m enudo se so lap an , consideram os el m ente los atributos estructuralesprincipales de manera
siguiente conjunto de principios [WASSO] para la espe que se pueda establecer la arquitectura de los datos.
cificación de datos: 5. L a representación de las estructuras de datos debe
rían conocerla sólo aquellos m ódulos que deban
1. Los principios del análisis sistemático aplicados a la hacer uso directo de los datos contenidos dentro de
fu n ció n y al comportamiento deberían aplicarse tam la estructura. E l c o n c e p to de o c u ltació n de infor
bién a los datos. Invertimos mucho tiempo y esfuerzo m ación y el concepto relacionado de acoplamiento
www.FreeLibros.org
en obtener, revisar y especificar los requisitos fun (C apítulo 13) p ro porciona u n a im portante visión de
cionales y el diseño preliminar. Las representaciones la c a lid a d del d ise ñ o del so ftw a re . E ste principio
de flujo de datos y contenido deberían desarrollarse alude a la im portancia de estos conceptos así como
240
C A P Í T U L O 14 D IS E Ñ O A R Q U I T E C T Ó N I C O
a «la im portancia de separar la v isió n lógica de un 7. Un diseño del softw are y un lenguaje de p ro g ra m a
objeto de datos de su v isió n física» [WASSO]. ción debería soportar la especificación y realización
6. Debería desarrollarse una biblioteca de estructuras de los tipos abstractos de datos. L a im plem entación
de datos útiles y de las operaciones que se les p u e de una estructura de datos sofisticada puede hacerse
den aplicar. L as estructuras de datos y las operacio excesivam ente difícil si no existen los m edios de esp e
nes d eberían c o n sid e ra rse co m o re c u rso s p a ra el cificación directa de la estructura en el lenguaje de pro
diseño del softw are. L as estructuras de datos pueden gram ación escogido para dicha im plem entación.
diseñarse p ara que se p u ed an reutilizar. U n a b ib lio L o s principios descritos anteriorm ente fo rm an una
teca de plantillas de estructuras de datos (tipos abs base para un enfoque de diseño de datos a nivel de co m
tractos de datos) puede red u cir el esfuerzo del diseño ponentes que puede integrarse en las fases de análisis y
y de la especificación de datos. diseño.
■ U fcUTll n a A R Q U IT E C T Ó N IC O S
Cuando un constructor utiliza el térm ino «centre hall colo-

nial~ara describir una casa, la m ayoría de la gente fam i
liarizada con las casas en los Estados U nidos sería capaz
de recrear una im agen general de cóm o sería esa casa y de
cómo sena su diseño de plantas. El constructor h a utiliza 14.3.1. U n a b r e v e ta x o n o m ía d e e s tilo s y p a t r o n e s
do un estilo arquitectónico a m odo de m ecan ism o d es A unque durante los pasados 50 años se han creado cien
criptivo p ara diferen ciar esa casa de otros estilos (por tos de m iles de sistem as basados en com putadora, la gran
ejemplo,A - a m e , raised rcmch. Cape Cod). Pero, lo m ás m ayoría pueden ser clasificados (ver [SHA96], [BAS98],
importante, es que el estilo arquitectónico es tam bién un [BUS98]) dentro de uno de los estilos arquitectónicos:
patrón de construcción. M ás adelante se deberán definir
Arquitecturas centradas de datos. E n el centro de esta
los detalles de la casa, se especificarán sus dim ensiones arquitectura se encuentra un alm acén de datos (por ejem plo,
finales, se le añadirán características personalizadas y se un docum ento o una base de datos) al que otros com ponentes
determinarán los m ateriales de construcción, pero el patrón acceden con frecuencia para actualizar, añadir, borrar o bien
--«centre hall co lo n ia l» - guía al constructor en su tra m odificar lo s datos del alm acén. L a figura 14.1 representa un
bajo. estilo típico basada en los datos. El softw are de cliente accede
a un alm acén centrai. E n algunos casos, el alm acén de datos es
p a siv o . E sto significa que el softw are d e cliente accede a los
datos independientem ente de cualquier cam bio en los datos o
Referencia W e b Í^ de las acciones de o tro softw are de cliente. U na variación en
este acceso transform a el alm acén en una «pizarra» que envía
E proyecto ABLEde lo CMU cuenta con trabajos y notificaciones al softw are de cliente cuando lo s datos de inte
ejemplos muy útiles sobre estilos arquitectónicos: rés del cliente cam bian.
tom.cs.cmu.edu/able/
El software construido para sistem as basados en com

putadoras tam bién cu enta con diversos estilos arquitec
tónicos'. Cada estilo describe una categoría del sistem a
que contiene: (1) un conjunto de com ponentes (por ejem
plo, una base de datos, m ódulos com putacionales) que
realizan una función requerida p o r el sistem a; (2) un co n
junto de conectores que p o sib ilitan la «com u n icación,la
coordinación y la cooperación» entre los com ponentes;
(3) restricciones que d efinen có m o se p u ed en integrar
los com ponentes que form an el sistem a; y (4) m odelos
semánticos que p erm iten al d iseñador entender las p ro
piedades globales de un sistem a p ara analizar las p ro
piedades conocidas de sus partes constituyentes[BA S98].
En la siguiente sección, abordam os los p atrones arqui
tectónicos com únm ente u tilizados p ara el softw are. F IG U R A 1 4 .1 . Arquitectura basad a en lo s datos.
www.FreeLibros.org
' Los términos estilos y patrones se utilizan indistintam ente en este
capítulo.
24 1
I N GEN IE RÍ A DEL SOF TW ARE . UN E N F O Q U E P R Á C T I C O
L as arquitecturas basadas en los datos prom ueven la capa

c id a d d e in te g ra c ió n (in te g ra b ility ) [B A S 9 8 ], P o r c o n si
guien te, los com p o n en tes existentes pueden cam b iarse o los
com ponentes del nuevo cliente pueden añadirse a la a rq u i
tectu ra sin in v o lu crar a o tro s clientes (porque los c o m p o
nentes del cliente operan independientem ente). A dem ás, los
datos pueden ser transferidos entre los clientes utilizando un
m ecanism o de pizarra (p o r ejem p lo , el com ponente de piza
rra sirve para coordinar la transferencia de inform ación entre
clientes). L os com p o n en tes cliente son procesos ejecutados
independientem ente.
(a) Tuberías y filtros
Q pm ; F iltro Filtro Filtro Filtro
PJR tos disciplinas de ingeniería. (b) Secuencial por lotes

||p p yfSsvtó Garlan
F IG U R A 1 4.2. Arquitecturas de flujo de datos.
A rq u itectu ra s de flu jo de d atos. E sta arq u itectu ra se

aplica cuando los datos de e ntrada son tran sfo rm ad o s a tra
tssmmsm
En la Parte 4 se presenta un estudio detallado sobre las
vés de una serie de com p o n en tes c o m p u ta cio n a les o m ani-
p u la tiv o s e n los datos d e salida. U n patrón tu b ería y filtro arquitecturas orientadas a objetos.
(Fig. 1 4 .2 .a )tien e un g ru p o de co m p o n en tes, llam ad o s fil
tro s, c o n e c ta d o s p o r tu b e ría s q u e tra n s m ite n d a to s d e un
A r q u ite c tu r a s o r ie n ta d a s a o b je to s. L o s componen
com ponente al siguiente. C ada filtro trab aja in d ep e n d ien
tes de un siste m a e n c a p su la n los d a to s y las operaciones
te m e n te de aq u ello s com p o n en tes que se en cu en tran en el
que se d e b en re a liz a r para m a n ip u la r los d atos. L a comu
flu jo de e ntrada o de salida; está d ise ñ ad o para re c ib ir la
nicació n y la c o o rd in a c ió n e n tre c o m p o n e n te s se consigue
e n tra d a de datos de una cierta form a y p ro d u c ir una salid a
a trav é s d el paso de m ensajes.
de datos (hacia el siguiente filtro ) de una fo rm a específica.
S in e m b a rg o , el filtro no necesita co n o cer el trab ajo de los A r q u ite c tu r a s e str a tific a d a s. L a e stru c tu ra básica de
filtro s vecinos. una a rq u ite c tu ra e stra tific a d a se re p re se n ta en la Figura
14.3. Se c re a n d ife re n te s c ap a s y cada una realiza opera
Si el flujo de datos degenera en una sim ple línea de tran s c io n e s que p ro g re s iv a m e n te se a p ro x im a n m ás al cuadro
fo rm a d o re s (F ig. 14.2 .b) se le d e n o m in a se c u e n c ia l p o r de in s tru c c io n e s d e la m á q u in a . E n la c a p a externa, los
lotes. E ste patrón aplica una serie de com p o n en tes secuen- c o m p o n e n te s sirv e n a las o p e ra c io n e s d e interfaz de usua
ciales (filtro s) para transform arlos. rio. E n la c a p a in te rn a , los c o m p o n e n te s realizan opera
c io n e s d e in te rfa z d el siste m a . L a s c a p a s interm edias
p ro p o rc io n a n se rv icio s d e u tilid a d y fu n c io n e s del soft
w are de aplicaciones.
O p a :
Uti buea arquitecto es el principal mantenedor
®Í8 vfeBndel usuario de! producto final. Componentes
.IfataMrfe<e$aa \\ \ Capa de la interfaz
del usuario
A rq u itectu ra s de llam ad a y retorno. E ste estilo a rq u i

tectó n ico perm ite al d ise ñ ad o r del softw are (arq u itecto del
sistem a) construir una estructura de program a relativam ente
fácil de m o d ific ar y aju star a escala. E x iste n dos subestilos
[B A S 98] d e n tro de esta categoría:
Capa \
• a rq u ite c tu ra s de p ro g r a m a p rin c ip a llsu h p ro g ra m a : / central Yjj
e sta estru ctu ra clásica de p ro g ram ació n descom pone
las fu n c io n e s en una je ra rq u ía d e c o n tro l d o n d e un
p rogram a « p rin cip al» llam a a un núm ero de c o m p o lC
nentes del pro g ram a, los cu ales, en resp u esta, pueden
tam b ién llam ar a otros com ponentes. L a F ig u ra 13.3
representa una arq u itectu ra de este tipo.
www.FreeLibros.org
• a rq u ite c tu ra s de lla m a d a de p ro c e d im ie n to rem oto:
lo s c o m p o n e n te s d e una a rq u ite c tu ra d e p ro g ra m a
p rincipal/subprogram a, e stán distribuidos e n tre v a ría s
co m p u tad o ras e n una red. F IG U R A 14.3. Arquitectura ectratificada.
242
C A PIT U L O 14 DI SE ÑO A R Q U I T E C T Ó N I C O
Los estilos arquitectónicos citados anteriorm ente son cuál es el papel de los com ponentes dentro de esajerarq u ía de
sólo una pequeña parte de los que dispone el diseñador control? ¿C óm o transfieren el control los com ponentes d e n
tro del sistem a? ¿C óm o se com parte el control entre co m p o
de softw are'. U n a v ez que la in g e n ie ría de req u isito s
nentes? ¿Cuál es la topología de control (por ej em plo, la form a
define las características y las restricciones del sistem a geom étrica3 que adopta el control)?, ¿Está el control sincro
que ha de ser construido, se esco g e el p atrón arquitec nizado o los com ponentes actúan asincrónicam ente?
tónico (estilo) o la co m b in ació n de p a tro n es (estilos)
que m ejor encajan con las características y restriccio ^ ¿Cómo se evalúa un estilo
nes. En m uchos casos, puede ser apropiado m ás de un W arquitectónico que se ha derivado?
patrón y se pod rían d iseñar y evalu ar estilos arquitec
D atos. ¿C óm o se co m u n ican los datos entre co m p o n e n
tónicos alternativos.
tes? ¿El flujo d e d atos es contin u o o son objetos de datos que
pasan de un com ponente a otro, o los d atos e stán disponibles
14.3.2. O rg a n iza ció n y re fin a m ie n to globalm ente para ser com partidos entre los com ponentes del
sistem a? ¿E xisten los com p o n en tes de datos (p o r e je m p lo ,
Puesto que el proceso de diseño d eja a m enudo al in g e una p izarra o alm acén ), y si es así, cuál es su papel? ¿C óm o
niero con un núm ero de alternativas arquitectónicas, es in te ra c tú a n los c o m p o n e n te s fu n c io n a le s c o n los co m p o
importante establecer un conjunto de criterios de d ise n entes de datos? ¿L os com p o n en tes de datos son activ o s o
ño que p u ed an ser u tiliz a d o s p a ra e v a lu a r un d iseñ o p asivos (p o r ejem p lo , los com p o n en tes de datos interactú an
a c tiv a m e n te c o n o tro s c o m p o n e n te s del siste m a )? ¿ C ó m o
arquitectónico derivado. L as sig u ie n te s c u e stio n e s
interactúan los datos y el control d entro del sistem a?
[BAS98] proporcio n an u n a idea del estilo arquitectó
nico que h a sido derivado: E stas preguntas proporcionan al diseñador una ev a
Control. ¿C óm o se gestiona el control dentro de la arqui luación tem prana de la calidad del diseño y sientan las
tectura? ¿Existe unajerarquía de control diferente, y si es así. bases para un análisis m ás detallado de la arquitectura.
Las preguntas citadas en la sección anterior pro p o rcio 2. Elicitación de requisitos. E sta inform ación es req u e
nan una ev aluación p relim in ar del estilo arquitectónico rid a com o parte de los requisitos de ingeniería y se
escogido p ara u n sistem a concreto. Sin em bargo, para utiliza para asegurarse de que todos los clientes, usua
la consecución efectiv a del diseño, se necesita un m éto rios y partícipes im plicados han sido atendidos.
do de ev aluación de la calidad de la arquitectura m ás
completo. E n las sig u ien tes seccio n es, co n sid eram o s
dos enfoques diferentes p ara el análisis de diseños arqui
tectónicos altern ativ o s. E l p rim e r e n fo q u e u tiliz a un Referencia Web
método iterativo p ara evalu ar el diseño de los com pro Se puede encontrar información detallada sobre análisis
misos. El segundo en fo q u e a p lica u n a p se u d o téc n ica de compromiso de software arqultectónlcoen:
cuantitativa para evaluar la calidad del diseño. www.sei.cmu.edu/ o t a / ata_method.html
3. Describir los patroneslestilos arquitectónicosescogi-

dospara derivar los escenarios y requisitos. El(los)
estilo(s) debería describirse utilizando vistas arqui
tectónicas com o:
• vista de m ódulo: para analizar el trabajo asignado
14.4.1. U n m é to d o d e a n á l i s i s d e c o m p r o m iso
p o r com ponente y el grado de ocultación de in fo r
p a ra la a rq u itectu r a m ación que se h a alcanzado
El Instituto de Ingeniería de Software (S E I)h a d e sa • vista de proceso : para an alizar la actuación del
rrollado un M étodo de análisis de compromiso p a ra la sistem a
fl/Y/t«7ec?»ra(MACA)[KAZ98] que estab lece un p ro
• vista de flujo de datos: para analizar el grad o en
ceso de ev aluación iterativ o p ara las arq u itectu ras de
el que la arquitectura cum ple los requisitos fu n
software. L as activ id ad es de an álisis de d iseño m e n
cionales
cionadas abajo se realizan iterativam ente:
1. Recopilación de escenarios. E n el C a p ítu lo 11 se
recogen un grupo de casos de u so p ara representar
mssmssm
En los Capítulos 8 y 19 se estudiante atributos de calidad.
el sistem a desde el punto de v ista del usuario.
www.FreeLibros.org
2Ver [SHA97], [BAS98] y [BUS98] para un estudio detallado de esti 3 Una jerarq u ía es una form a g eo m étrica, pero tam bién podem os
los y patrones arquitectónicos. e n c o n tra r m ecanism os de control se m ejan te s en un sistem a
c lie n te /se rv id o r.
243
I N GEN IE RÍ A DEL SOF TW AR E . UN EN FOQ UE P R Á C T I C O
4. Evaluar los atributos de calidad considerando cada Asada [SHA96] propone varios modelos simples para
atributo d efo rm a aislada. El n ú m ero de atributos ayudar al diseñador a determ inar el grado al cual una
de calid ad esco g id o s p a ra el an álisis d e p e n d e del arquitecturaparticular alcanza los criterios de «bondad»
tie m p o d isp o n ib le p a ra la re v isió n y del g rad o de predefinidos. Estos criterios, a veces llamados dimen
relev an cia de dichos atributos p ara el sistem a actual. siones d e l diseño, a m enudo abarcan los atributos de
Los atributos de calidad para la evaluación del diseño calidad definidos en la sección anterior: fiabilidad, ren
a rq u ite c tó n ic o in c lu y e n : fia b ilid a d , re n d im ie n to , dimiento, seguridad, facilidad de mantenim iento, flexi
seguridad, facilidad de m antenim iento, flexibilidad, bilidad, capacidad de prueba, movilidad, reutilización
capacid ad de prueba, m ovilidad, reu tilizació n e inte- e interoperatibilidad, entre otros.
roperatibilidad. El primer modelo, denominado análisis del espectro,
evalúa un diseño arquitectónicoen un espectro de «bon
5. Identificar la sensibilidad de los atributos de cali dad» desde el mejor diseño posible hasta el peor. Una vez
dad con los diferentes atributos arquitectónicos en que la arquitectura del software ha sido propuesta, se ana
nn estilo arquitectónico específico. E sto se puede liza asignando una «puntuación» a cada una de las
conseguir realizando p equeños cam bios en la arqui dim ensiones del diseño. Estas notas de las dimensiones
tectu ra y d eterm inando cuán sensibles al cam bio son se suman para determ inar la calificación total, S, del
los atributos de calidad, com o el rendim iento. A q u e diseño como un todo. Los casos de notas más bajas4 son
llo s atrib u to s afectad o s sig n ificativ am en te p o r un asignados a un diseño hipotético, y se computa la suma
cam bio en la arquitectura son denom inados puntos de notas de la peor arquitectura, S, La mejor nota.
sensibles. se com puta para un diseño óptim o5. Entonces calcu
6. A nálisis de las arquitecturas candidatas (desarro lamos el índice del espectro, 1 , mediante la ecuación:
lladas en el p a so 3)utilizando el análisis de sensi
l s = [ ( S - S J ( S h - S w) l ) x 1 0 0
bilidad del p a so 5 . El SEI describe este enfoque de
la siguiente form a [K A Z98]: El índice del espectro indica el grado al cual la arqui
Una vez determinados los puntos sensibles de la arquitec tectura propuesta se aproxima al sistema óptimo dentro
tura, encontrar los puntos de compromisoconsiste simplemente del espectro de alternativas razonables para el diseño.
en la identificación de los elementosarquitectónicos en los cua
les varios atributos son sensibles. Por ejemplo, el rendimiento
de una arquitectura cliente/servidor sena muy sensible al núme
ro de servidores (el rendimiento aumenta, dentro de un grado, ün doctor ¡Hiede enterrar sus errores,
aumentando en número de servidores). La disponibilidad de
fsetn d arquitecto sólo puede aconsejar
esa arquitectura también variaría directamente con el número
de servidores. Sin embargo, la seguridad del sistema variaría a s *¡ te te s que planten viñedos.
inversamente al número de servidores (porque el sistema con f r r ¡ tíoyd Wrigbt
tiene más puntos de ataque potenciales). El número de servi
dores, entonces, es un punto de compromiso con respecto a la Si se realizan m odificaciones del diseño propuesto
arquitectura. Este es un elemento, potencialmente uno de
o si se propone un nuevo diseño entero, los índices de
muchos, donde se harán los compromisos arquitectónicos,cons-
ciente o inconscientemente. espectro de ambos deben ser comparados y se compu
tará un índice de mejora, ¡me:
E sto s seis p aso s re p re se n ta n la p rim e ra iteració n
M A C A . Tras los resultados de los pasos 5 y 6 algunas
arquitecturas alternativas se elim in arían , u n a o v arias
Esto proporciona al diseñador una indicación relati
de las arquitecturas restantes serían m o dificadas y p re
va a la m ejora asociada con los cambios arquitectóni
sentadas con m ay o r detalle, y después los pasos M A C A
cos realizados o con la nueva arquitectura propuesta. Si
se aplicarían de nuevo.
Ime es positivo, entonces podemos concluir que el sis
tem a 1 ha sido m ejorado en relación al sistema 2.
14.4.2. G u í a c u a n t i t a t i v a p a r a e l d i s e ñ o a r q u i El análisis de selección del diseño es otro modelo
te c tó n ic o que requiere un cuadro de dim ensiones de diseño para
U no de los m uchos p roblem as con los que se enfrentan ser definido. La arquitectura propuesta es entonces eva
los ingenieros del softw are durante el p roceso de d ise luada para determ inar el núm ero de dim ensiones del
ño es la carencia general de m étodos cuantitativos para diseño que se logran cuando se com para con un siste
la ev aluación de la calidad de los diseños propuestos. m a ideal (el m ejor caso). Por ejem plo, si una arquitec
El enfoque M A C A recogido en la Sección 14.4.1 re p re tura propuesta alcanzara una reutilización de
senta u n enfoque innegablem ente cualitativo y útil para componentes excelente, y esta dim ensión es requerida
el análisis del diseño. para el sistem a ideal, la dim ensión de reutilización ha
www.FreeLibros.org
4 El diseño debe ser todavía aplicable al problem a actual, incluso á 5 El diseño seria Óptimo, pero las restricciones, los costes u otros fac
la solución no es particularm ente buena. tores no perm itirán su construcción.
244
C A P Í T U L O 14 DISEÑO A R Q U I T E C T Ó N I C O
s id o l o g r a d a . S i l a a r q u i t e c t u r a p r o p u e s t a t i e n e p o c a E l E D C e s b a s ta n te f á c il d e im p le m e n t a r c o m o u n
s e g u r id a d , y s e n e c e s i t a u n a g r a n s e g u r i d a d , n o s e h a m o d e lo d e h o ja d e c á lc u lo y p u e d e s e r u t iliz a d o p a r a
a lc a n z a d o l a d i m e n s i ó n d e l d i s e ñ o . a is la r p o r q u é u n c u a d r o d e a lte r n a tiv a s d e d is e ñ o o b t i e
n e u n a s n o ta s m e n o re s q u e o tro .
C a l c u l a m o s e l ín d ice de s e le c c ió n d e l d is e ñ o , d,
com o:
d=(NJNJxlOO 14.4.3. C o m p lejid a d a rq u itectó n ica
d c n d e A , e s e l n ú m e r o d e d im e n s io n e s d e d is e ñ o lo g r a P a r a e v a lu a r la c o m p le jid a d to ta l d e u n a a r q u it e c t u r a
d a s e n la a r q u i t e c t u r a p r o p u e s t a y I V , e s e l n ú m e r o t o t a l d a d a , u n a t é c n ic a ú t i l c o n s is te e n c o n s id e r a r la s r e l a
de d im e n s io n e s e n e l e s p a c io d e d is e ñ o . A m a y o r í n d i c io n e s d e d e p e n d e n c ia e n tr e lo s c o m p o n e n t e s d e la
ce de s e l e c c i ó n d e l d i s e ñ o , m á s c e r c a e s t a m o s d e q u e l a a r q u it e c t u r a . E s ta s r e la c io n e s d e d e p e n d e n c ia s o n c o n
a r q u it e c t u r a p r o p u e s t a a l c a n c e e l s i s t e m a i d e a l . d u c id a s a tr a v é s d e lo s f l u jo s d e in f o r m a c ió n / c o n t r o l
d e n t r o d e l s is t e m a .
E l análisis de contribución « i d e n t i f i c a la s r a z o n e s p o r
Z h a o [ Z H A 9 8 ] p r o p o n e tr e s tip o s d e d e p e n d e n c ia :
las q u e u n g r u p o d e a l t e r n a t i v a s d e d i s e ñ o o b t i e n e u n a s
D ependencias de com partim iento,representan las re la c io
n o ta s m e n o r e s q u e o t r o » . [ S H A 9 6 ] R e t o m a n d o e l e s t u
nes de dependencia entre los consum idores que u tilizan lo s
d io d e l despliegue de la fu n c ió n de calidad (D F C ) v i s m ism os recursos o los productores que producen para íos m is
to e n e l C a p í t u l o 1 1 , e l a n á l i s i s d e v a l o r s e r e a l i z a p a r a m os consum idores. P or ejem plo, tenem os dos com p o n en tes u
d e t e r m in a r l a p r i o r i d a d r e l a t i v a d e l o s r e q u i s i t o s d e t e r y v, si u y v se refieren a los mismos datos globales, entonces
m in a d o s d u r a n t e e l d e s p l i e g u e d e f u n c i o n e s , e l d e s p l i e existe una dependencia de compartim iento entre am bos.
g u e d e i n f o r m a c i ó n y e l d e s p lie g u e d e t a r e a s . S e i d e n t i f i c a D ependencias de flujo, representan las relaciones d e d e p en
un c o n ju n to d e « m e c a n is m o s d e r e a liz a c ió n » ( c a r a c te dencia entre los productores y los consum idores de recursos.
r ís tic a s d e l a a r q u i t e c t u r a ) . S e c r e a u n l i s t a d o c o n t o d o s P o r ejem plo, entre dos com ponentes u y v, si u debe c o m p le
tarse antes de que el control fluya a v (prerrequisito), 0 s¡ u y v
lo s r e q u is it o s d e l c l i e n t e ( d e t e r m i n a d o s a t r a v é s d e l D F C )
se com unican a través de parámetros, entonces existirá una rela
y u n a m a t r iz d e r e f e r e n c ia s c r u z a d a s . L a s c e ld a s d e la
ción de dependencia de flujo entre ambos.
m a t r iz i n d i c a n ( e n u n a e s c a l a d e l 1 a l 1 0 ) l a f u e r z a r e l a
t iv a d e l a r e l a c i ó n e n t r e u n m e c a n i s m o d e r e a l i z a c i ó n y D ependencias restrictivas, representan las restricciones de
un relativo flujo de control entre un cuadro de actividades. Por
un r e q u is it o p a r a c a d a a r q u it e c t u r a p r o p u e s t a . A e s to s e
ejem plo, dos com ponentes u y v, si u y v no se pueden e je c u
le c o n o c e c o m o espacio de diseño cuantificado (E D C ). tar al m ism o tiem po (por exclusión m utua), entonces existirá
una dependencia restrictiva entre u y v.
L a s d e p e n d e n c ia s d e c o m p a r t im ie n t o y d e f l u j o r e c o
g id a s p o r Z h a o s e p a r e c e n d e a lg u n a f o r m a a l c o n c e p
t o d e a c o p la m ie n t o v is t o e n e l C a p í t u lo 1 3 . E n e l
C a p í t u lo 1 9 s e e x p lic a r á n m e d ic io n e s s e n c illa s p a r a la
Hoja de cálculo DFC e v a l u a c i ó n d e la s d e p e n d e n c i a s .
B t.S CQNVE 'S1QN.B£LQ& . EQUISUQS B U S 0 QUIIECIU DELSClO -.-J -

En el C a p í t u l o 1 3 y a d i j i m o s q u e l o s r e q u i s i t o s d e l s o f t - P a ra ilu s t r a r u n e n fo q u e d e c o n v e r s ió n a r q u it e c t ó n i
w a te p u e d e n s e r c o n v e r t i d o s e n v a r i a s r e p r e s e n t a c i o n e s c a , c o n s id e r a r e m o s la a r q u it e c t u r a d e lla m a d a y r e t o m o
del m o d e l o d e d i s e ñ o . L o s e s t i l o s a r q u i t e c t ó n i c o s v i s — u n a e s t r u c t u r a m u y c o m ú n p a r a d i f e r e n t e s t i p o s d e s is
to s e n l a S e c c i ó n 1 4 . 3 . 1 r e p r e s e n t a n a r q u i t e c t u r a s r a d i te m a s 6 — . L a t é c n i c a d e c o n v e r s i ó n q u e s e p r e s e n t a c a p a
c a lm e n t e d i f e r e n t e s , p o r l o c u a l n o d e b e r í a s o r p r e n d e m o s c it a a l d is e ñ a d o r p a r a d e r iv a r a r q u it e c t u r a s d e lla m a d a y
q u e n o e x is ta u n a ú n ic a c o n v e r s ió n q u e lo g r e u n a t r a n r e t o r n o r a z o n a b le m e n te c o m p le ja s e n d ia g r a m a s d e f l u
s ic ió n d e l m o d e l o d e r e q u i s i t o s a l m o d e l o d e d i s e ñ o . D e j o d e d a to s d e n tr o d e l m o d e lo d e r e q u is ito s .
h e c h o , to d a v í a n o e x is te u n a c o n v e r s ió n p a r a a lg u n o s L a t é c n i c a , a v e c e s d e n o m i n a d a diseño estru ctu ra
m o d e lo s a r q u i t e c t ó n i c o s , y e l d i s e ñ a d o r d e b e l o g r a r l a do, t i e n e s u s o r í g e n e s e n a n t i g u o s c o n c e p t o s d e d i s e ñ o
tr a d u c c ió n d e lo s r e q u is it o s d e l d is e ñ o p a r a e s o s e s t ilo s q u e d e fe n d ía n la m o d u la r id a d [ D E N 7 3 ] , e l d is e ñ o d e s
d e u n a f o r m a a d hoc. c e n d e n te [ W I R 7 1 ] y la p r o g r a m a c ió n e s tr u c tu r a d a
6 También es im portante m encionar que las arquitecturas de llam ada
www.FreeLibros.org
y retorno pueden residir dentro de otras arquitecturas m as sofistica
das vistas anteriorm ente en este capitulo. Por ejem p lo ,la arquitec
tura de uno o vanos com ponentesde una arquitectura cliente/servidor
podría ser de llam ada y retorno.
245
I N GEN IE RÍ A DEL S O F TW A RE . UN E N F O Q U E P R A C T I C O
[D A H 7 2 , L IN 7 9 ], S te v e n s, M y e rs y C o n sta n tin e
[STE74] p ro p u siero n el diseño del softw are b asado en c s a « E g g a
el fluyo de datos a trav és de un sistem a. L os prim eros Losdiogramos deflujo de datos se estudian en detalle
trabajos se refinaron y se presentaron en libros de M yers en el Capitulo 12.
[M Y E 78], Y ourdon y C onstantine [Y O U 79],
14.5.2. F lu jo d e t r a n s a c c ió n
¿Cuáles son los pasos
a seguir en la evaluación El m odelo fundam ental de sistem a im plica un flujo de
del DFD en una arquitectura de transform ación; p o r tanto, es posible caracterizar todo
llamada y retorno? el flujo de datos en esta categoría. Sin em bargo, el flu
j o de inform ación está caracterizado a m enudo por un
El diseño estructurado suele caracterizarse com o un único elem ento de datos, denom inado transacción, que
m étodo de diseño orientado al flujo de datos p orque per d esencadena otros flujos de inform ación a lo largo de
m ite u n a cóm o d a tran sició n desde el diagrama de f lu uno de los m uchos cam inos posibles. C uando un D F D
j o de datos ( DFD) a la a rq u ite c tu ra de so ftw are7. La to m a la form a m ostrada en la F igura 14.4, lo que tene
tran sició n desde el flujo de info rm ació n (representado m os es un flu jo de transacción.
co m o un diag ram a de flujo de datos) a u n a estructura
del p ro g ram a se realiza en un p roceso de seis pasos: (1)
se establece el tipo de flujo de inform ación; (2) se in d i
can los lím ites del flujo; (3) se convierte el D F D en la
e stru c tu ra del program a; (4) se d efin e la je ra rq u ía de
c o n tro l; (5 ) se re fin a la e s tru c tu ra re su lta n te usan d o
m edidas y h eur'sticas de diseño, y (6 ) se refina y e la
b o ra la d escripción arquitectónica.
El tipo de flujo de inform ación es lo que d eterm ina
el m étodo de co nversión requerido en el paso 3 . E n las
siguientes secciones exam inam os los d os tipos de flujo.
14.5.1. F lu jo d e tr a n s f o r m a c ió n
R etom ando el m odelo fundam ental de sistem a (nivel O
del d iag ram a de flu jo de d ato s), la in fo rm a c ió n debe
introducirse y obtenerse del softw are en fo rm a de «m u n
do exterior». P or ejem plo, los datos escritos con un tecla
do, los tonos en u n a línea telefónica, y las im ágenes de
vídeo en una aplicación m u ltim ed ia son todas form as de F IG U R A 1 4 .4 . Flujo de transacción.
inform ación del m u n d o exterior. T ales d ato s in tern o s
deb en convertirse a un form ato interno p ara el p ro cesa El flujo de transacción se caracteriza p o r datos que
m iento. La info rm ació n en tra en el sistem a a lo largo de se m ueven a lo largo de un cam ino de entrada que con
cam inos que tran sfo rm an los d ato s ex tern o s a un fo r vierte la inform ación del m u n d o e x terio r en una tran
m ato interno. E stos cam inos se identifican com oflujo de sacción. L a transacción se e v alú a y, basándose en ese
entrada. En el interio r del softw are se produce una tra n valor, se inicia el flujo a lo largo de uno de m uchos cami
sición. L a inform ación entrante se p asa a través de un nos de acción. El centro del flujo de inform ación del
centro de transformación y em pieza a m overse a lo lar que parten m uchos de los cam inos de acción se deno
go de cam in o s que ahora conducen h acia « fu era» del m in a centro de transacción.
softw are. L os datos que se m uev en a lo largo de estos D ebería recalcarse que dentro del D F D de un siste
cam inos se denom inan flujo de salida. El flujo general m a grande, am bos flujos de transacción y de transfor
de datos ocurre de m an era secuencial y sigue un, o unos m ac ió n pueden p resen tarse. P o r ejem plo, en un flujo
pocos, cam in o s8 «directos». C uando un segm ento de un orientado a transacción, el flujo de inform ación a lo lar
diag ram a de flujo de datos p resen ta estas características, go de un cam in o de acción puede ten er características
lo que tenem os presente es un flujo de transformación. de flujo de transform ación.
1 Debe recordarse que tam bién d urante el m odelado de análisis se 8 Un análisis obvio de este tipo de flujo de inform ación lo encontra
utilizan otros elem en to s del m étodo de análisis (por ejem plo; el m os en la Sección 14.3.1 en la arquitectura de flujo de datos. Sin
diccionario de datos, EP, EC). em bargo, hay m uchos casos en los que la arquitectura de flujo de
www.FreeLibros.org
datos no sería la m ejor elección para un sistem a complejo. Los ejem
plos incluyen sistem as que sufrirían cam bios sustanciales en el tiempo,
o sistem as en los cuales el procesam iento asociado con el flujo de
datos no es necesariam ente secuencial.
246
C A P Í T U L O 14 D IS E Ñ O A R Q U I T E C T Ó N I C O
El análisis de las transform aciones es un conjunto de de requisitos del software. Am bos documentos descri
pasos de diseño que permite convertirun DFD, con carac ben el flujo y la estructura de la inform ación en la inter
terísticas de flujo de transform ación, en un estilo arqui faz del software. Las Figuras 14.5 y 14.6 m uestran el
tectónico específico. En esta sección se describe el análisis nivel 0 y 1 del flujo de datos del software Hogarseguro.
de las transformaciones aplicando los pasos de diseño a Paso 2. Revisar y refinar los diagram as de flujo
un sistema de, por ejem plo, una parte del software de de datos del software. La inform ación obtenida de los
Hogarsegnro presentado en capítulos anteriores. modelos de análisis contenidos en la Especificación de
Requisitos del Software se refina para obtener m ayor
14.6.1. Un ejem p lo detalle. Por ejem plo, se exam ina el DFD del nivel 2 de
El sistema de seguridad Hogarsegnro, presentado ante m onitorizar sensores (Fig. 14.7) y se obtiene un d ia
riormente en este libro, es representativo de m uchos grama de flujo de datos de nivel 3 com o se m uestra en
productos y sistemas basados en com putadora actual la Figura 14.8. En el nivel 3, cada transform ación en
mente en uso. El producto vigila el m undo real y reac- el diagram a de flujo de datos presenta una cohesión
dcna ante cambios que encuentra. También interacciona relativam ente alta (Capítulo 13). Es decir, el proceso
con el usuario a través de una serie de entradas por tecla implicado por una transform ación realiza una función
do y visualizaciones alfanuméricas. El nivel 0 del dia única y distinta que puede im plem entarse com o un
grama de flujo de datos de H ogarsegnro, reproducido módulo' en el so \\ware HogarSeguro. Por tanto, el DFD
del Capítulo 12, se m uestra en la Figura 14.5. de la Figura 14.8 contiene suficiente detalle para esta
blecer un diseño «inicial» de la arquitectura del sub
sistema de m onitorizar sensores y continuam os sin más
Monitor
del
refinamiento.
panel
de control
\ de alarmo b
Si e I DFD es refinado más de uno vez, se esforzará por
Alarma 1
derivar burbujas que presentan gran cohesión.
Paso 3. Determ inar si el DFD tiene características

de flujo de transformación o de transacción. En gene
ral, el flujo de inform ación dentro de un sistema puede
FIGURA 14.5. DFD a nivel de contexto para Hogarseguro. representarse siem pre com o una transform ación. Sin
embargo, cuando se encuentra una característica obvia
Durante el análisis de requisitos, se habrán creado de transacción (Fig. 14.4), se recom ienda una estruc
más modelos detallados del flujo para Hogarseguro. tura de diseño diferente. En este paso, el diseñador selec
Además, se crearán las especificaciones de control y ciona la característica general del flujo (de la amplitud
proceso, un diccionario de datos y varios m odelos de del software) basándose en la propia naturaleza del DFD.
comportamiento. Además, se aíslan regiones locales de flujo de transfor
m ación o de transacción. Estos subflujos pueden usarse
para refinar la estructura del program a obtenida por la
14.62.P a s o s d e l d is e ñ o característica general que prevalece. Por ahora, co n
El ejemplo anterior se usará para ilustrar cada paso en centraremos nuestra atención solamente en el flujo de
el análisis de las transformaciones. Los pasos em piezan datos del subsistema de monitorización de sensores m os
con una reevaluación del trabajo hecho durante el aná trado en la Figura 14.7.
lisis de requisitos y después evoluciona hacia el diseño
de la arquitectura del software.
Paso 1. R evisar el m odelo fundam ental del sis- CLAVE
tana. El m odelo fundamental del sistema com prende A menudo se podrán encontrar ambos tipos de flu¡o de
el DFD de nivel 0 y la inform ación que lo soporta. En datos dentro del mismo modelo de análisis, tos flujos se
realidad, el paso de diseño empieza con una evaluación dividen y la estructura del programase deriva utilizando
de la especificación del sistema y de la especificación el análisis adecuado.
www.FreeLibros.org
9 l a utilización del térm ino m ódulo en este capítulo equivale al tér
mino com ponente usado anteriorm ente en el estudio de la arquitec
tura de software.
247
IN GE NI ER ÍA DEL S O F T W A R E . UN EN F O Q U E P R A C T I C O
E valuando el D FD (Fig. 14.8), vem o s que los datos dos lím ites so m b read o s que van de arrib a abajo en el
entran al softw are p o r un cam ino de entrada y salen por dibujo. Se p o d ría arg u m en tar algún cam b io para rea
tres cam inos de salida. N o se distingue n in g ú n centro ju s ta r los lím ites (por ejem plo, se po d ría p roponer un
de tran sacció n (aunque la tran sfo rm ació n establecer las lím ite del flujo de entrada que separe leer sensores, de
condiciones de alarm a p o d ría p ercibirse com o tal). Por a d q u irir inform ación de respuesta). El énfasis en este
tanto, se asum irá u n a característica general de tran sfo r p aso del diseñ o debería ponerse en seleccionar límites
m ació n p ara el flujo de inform ación. razonables, en vez de largas disquisicionessobre la colo
cación de las separaciones.
P a so 5 . R e a liz a r u n a « d esc o m p o sició n d e prim er
n ivel». F a estructura del program a representa una dis
Órdenes y datos tribución descendente del control. L a descom posición
1 del usuaria,-
\ en partes provoca u n a estructura de p rogram a en la que
los m ódulos del nivel superior realizan la to m a de deci
Datos h. siones y los m ódulos del nivel inferior realizan la mayo
, - J e configuración \
/ / V .. Petición ■. ría del trabajo de entrada, cálculos y salida. L os módulos
| Interactuar Vde configuración i . ; >. , rr-i \
[con el usuarioj |informacion de confîguracionj de nivel interm edio realizan algún control y cantidades
Datos I
m oderadas de trabajo.
i — r Arranque/ f \ |y /n s a ie \ * * ••
|Contraseña\ parada ( “ var ¡ , ^ o n frg u ra c o n ,
feâctivaclói\ /
Información
I Procesar \Contraseña válida / Visualizar V is u a liz a Monitor
lia contraseña]................ ' mensajes üel pane?
\ y estado de control
\ V V Datos
\ configuración
información Alarma
del sensor
Monitorizar Tipo de alarma
Estado" l sensores
Id el sensor* Tonos
del número de teléfono
F IG U R A 1 4.6. Nivel 1 del DFD del H o g a rS e g u ro .
P a s o 4. A is la r el c e n tro d e tr a n s f o r m a c ió n e sp ec i
fic a n d o lo s lím ite s d e los flu jo s d e e n tr a d a y s a lid a .
En la sección precedente el flujo de entrada se describió
com o un cam ino en el que la inform ación se convierte
de form ato externo en interno; el flujo de salida convierte F IG U R A 1 4.7. Nivel 2 del DFD que refina el proceso
de form ato interno a externo. L os lím ites del flujo de de m onitorizar sensores
entrad a y el de salida son interpretables. E s decir, los
diseñadores p u ed en elegir p untos ligeram ente d iferen C uando encontram os un flujo de transform ación, un
tes com o lím ites de flujo. De hecho, se p u ed en obtener D FD se organiza en una estructura específica (una arqui
soluciones de diseño alternativas v ariando la posición tectura de llam ada y retorno) que p roporciona control
de los lím ites de flujo. A unque hay que ten er cu idado p ara el procesam iento de inform ación de entrada, trans
cuando se seleccionan los lím ites, u n a variació n de una form ación y de la salida. E sta descom posición en fac
b u rb u ja a lo largo de un cam ino de flujo ten d rá general to res o p rim e r n iv e l del su b siste m a de m onitorizar
m ente p oco im pacto en la estru ctu ra final del program a. sen sores se ilu stra en la F ig u ra 1 4 .9 . U n controlador
p rin c ip al, d en o m in ad o g e s to r d e m o n ito riz a c ió n de
se n so re s, reside en la parte superior de la estructura del
^ C O N S E JO ^ .
p rogram a y sirve para coordinar las siguientes funcio
Cambio lo situación de los fronteras de flujo en un nes de control subordinadas:
esfuerzo por explorar los estructuras de programa • un controlador de procesam iento de la inform ación de
alternativas. No llevo mucho tiempo y puede entrada denom inado controlador de la entrada del sen
proporcionarnos importantes ¡deas.
sor, coordínala recepción de todos los datos de entrada;
• un controlador del flujo de transform ación, denom i
L os lím ites de flujo del ejem plo se ilustran com o cu r nado controladorde las condiciones de alarm a, super
www.FreeLibros.org
vas som breadas que v an v erticales a través del flujo en visa todas las operaciones sobre los datos en su forma
la Figura 14.8. Las transfo rm acio n es(b u rb u jas) que fo r interna (por ejem plo; un m ódulo que invoca varios
m an el centro de tran sfo rm ació n se en cuentran entre los procedim ientos de transform ación de datos);
248
CA PÍ T U L O 14 DI SE ÑO A R Q U I T E C T Ó N I C O
Información de configuración | Información

del sensor
Estado
del sensor
Código de la
condición de la alarma,
identificación del sensor, información
de temporización
Tonos
del número
de telefono
FIGURA 14.8. Nivel 3 del DFDde monitorizar sensores con los límites de flujo.
• un controlador de p rocesam iento de inform ación de

salida, denom inado controlador de la salida de alarma,
coordina la producción de la inform ación de salida.
fío seas dogmático en esta parte. Podría ser necesario

establecer dos o más controladores de procesamiento de
entrado o computación, a couso de lo complejidad del
sistema a construir. Si el sentido común así te lo dicta, hazb.
Aunque la Figura 14.9 im plica una estructura con tres

ianBS,en grandes sistemas la com plejidad del flujo puede
hacer que existan dos o m ás m ódulos de control, uno para
cada una de las funcionesgenéricasdescritas anteriormente.
El número de m ódulos del prim er nivel debería lim itarse
al mínimo que p u ed a realizar las funciones de control
y m antener al m ism o tiem po unas b uenas característi
cas de acoplam iento y cohesión.
Paso 6. R e a liz a r « d e s c o m p o s ic ió n d e s e g u n d o
nivel». La d escom posición de segundo nivel se realiza
mediante la co nversión de las transform aciones in d iv i
www.FreeLibros.org
duales (burbujas) de u n D F D en los m ó d u lo s c o rre s
pondientes dentro de la arquitectura. E m pezando desde F IG U R A 1 4.9. Descomposición de primer nivel
d límite del centro de tran sfo rm ació n y m oviéndonos para la monitorización de sensores.
249
ING EN IE RÍA DEL S O F TW A RE . UN EN F O Q U E P R Á C T I C O
h acia fuera a lo largo de los cam inos de entrada, y luego m iento pueden llevar a cam bios en la estructura, pero
de salida, las transform aciones se co nvierten en niveles puede servir co m o u n a prim era iteración del diseño.
subordinados de la estru ctu ra del softw are. El enfoque
general del segundo nivel de d escom posición del flujo
de datos H ogarSeguro se ilustra en la Figura 14.10.
Mantén bajos los controladores de trabajo en la estructura
A unque la F ig u ra 14.10 ilu stra u n a co rrespondencia
del programa. Así, la arquitectura seré más fácil de modificar.
u n a a u n o e n tre las tra n sfo rm a c io n es d el D F D y los
m ódulos del softw are, ocurren frecuentem ente d iferen
tes conversiones. Se pueden com binar dos o incluso tres L a descom posición de facto res de segundo nivel del
b u rb u jas y re p re se n ta rla s co m o u n so lo m ó d u lo flujo de entrada sigue de igual m anera. L a descompo
(teniendopresente los p roblem as potenciales de la co h e sición en factores se realiza de nuevo m oviéndose hacia
sión), o u n a sola b u rb u ja puede dividirse en dos o m ás fu e ra d e sd e el lím ite del c e n tro de transform ación
m ódulos. L as co nsideraciones p rácticas y las m edidas correspondiente al flujo de entrada. El centro de trans
de la calidad d ictan el resultado de la descom posición form ación del softw are del subsistem a de monitorizar
en facto res de seg u n d o nivel. L a rev isió n y el re fin a sensores se direcciona de m anera algo diferente. Cada
www.FreeLibros.org
F IG U R A 1 4 .1 0 . Descomposición de factores de segundo nivel de m onitorización de sensores.
250
C A P Í T U L O 14 DISEÑO A RQ U ITE C TÓ N IC O
conversión de datos o transform aciones de cálculo de El texto explicativo sirve com o una prim era genera
la porción de transform ación del DFD se convierte en ción de la especificaciónde diseño. Sin embargo, se dan
un módulo subordinado al controlador de transform a más refinamientos y adiciones regularm ente durante este
ción. En la Figura 14.11 se m uestra una estructura de periodo de diseño.
programa com pleta de prim era iteración. Paso 7. Refinar la estructura inicial de la arquitec
Los m ódulos direccionados de la m anera descrita tura usando heurísticas para mejorar la calidad del
anteriormente y m ostrados en la Figura 14.11 repre software. U na primera estructurade arquitectura siempre
sentan un diseño inicial de la estructura del programa. puede refmarse aplicando los conceptos de independen
Aunque los m ódulos se nom bran de m anera que indi cia de m ódulos (Capítulo 13). Los m ódulos se incremen
quen su función, se debería escribir para cada uno un tan o reducen para producir una descomposiciónrazonable,
breve texto que explique su procesam iento (adaptado buena cohesión, acoplamiento m ínim o y lo m ás im por
del EP creado durante la m odelación de análisis). El tante, una estructura que se pueda implementar sin difi
texto describe: cultad, probarse sin confusión y mantenerse sin problemas.
• la inform ación que entra y la que sale fuera del Los refinam ientos se rigen por el análisis y los m éto
módulo (una descripción de la interfaz); dos de evaluación descritos brevem ente en la Sección
• la inform ación que es retenida en el m ódulo, por 14.4, así com o por consideraciones prácticas y por el
sentido común. Hay veces, por ejemplo, que el contro
ejem plo, datos alm acenados en una estructura de
lador del flujo de datos de entrada es totalmente inne
datos local;
cesario, o se requiere cierto procesam iento de entrada
• una descripción procedim ental que indique los prin en un módulo subordinado al controlador de transfor
cipales puntos de decisión y las tareas; m ación, o no se puede evitar un alto acoplam iento
• un pequeño estudio de las restricciones y caracterís debido a datos generales,o no se pueden lograr las carac
ticas especiales (por ejem plo, archivo I/O, caracte terísticas estructurales óptim as (vea la Sección 13.6).
rísticas dependientes del hardw are, requisitos Los requisitos del software ju n to con el buen ju icio son
especiales de tiempo). los árbitros finales.
flimina los módulosde controlredundantes. Es decir, si Céntreseen loindependencia funcional de bs módulos

unmódubde controlno hace otrocoso quecontrolar que derive. Su objetivodebeser unocohesbnalta
otromódub, estofunción de controldebería explotarse y un acoplamiento débil.
a mayor nivel.
Gestor
de !a monitorización
de sensores
www.FreeLibros.org
FIGURA 1 4.11 . Primera iteración de la estructura del program a para m onitorízar sensores.
251
I N GEN IE RI A DEL S OFT W ARE . UN EN F O Q U E P R A C T I C O
Se pueden hacer muchas m odificaciones a la primera En la Figura 14.12 se m uestra la estructura del soft
estructura desarrollada para el subsistema de m onitori ware refinada del subsistema de m onitorizar sensores.
zar sensores de HogarSeguro. Algunas de ellas son: El objetivo de los siete puntos anteriores es desarro
1. El controlador del flujo de entrada se puede elim i llar una representación general del software. Es decir,
nar porque es innecesariocuando sólo hay que mane- una vez que se ha definido la estructura, podem os eva
ja r un solo camino de flujo de entrada. luar y refinar la arquitectura del software viéndola en
2. La subestructura generada del flujo de transform a su conjunto. Las m odificaciones hechas ahora requie
ción puede reducirse en el m ódulo establecer las ren poco trabajo adicional, pero pueden tener un gran
condiciones de alarm a (que incluirá ahora el pro im pacto en la calidad del software.
cesamiento implicado por seleccionar núm ero de El lector debería reflexionar un m om ento y consi
teléfono). El controlador de transform ación no será derar la diferencia entre el enfoque de diseño descri
necesario y la pequeña dism inución en la cohesión to anteriormente y el proceso de «escribir programas)).
es tolerable. Si el código es la única representación del software,
3. Los módulos dar formato de visualización y gene el desarrollador tendrá grandes dificultades en eva
rar la visualización pueden unirse (asumimos que dar luar o refinar a nivel general u holístico y, de hecho,
formato de visualización es bastante simple) en un tendrá dificultad para que «los árboles dejen ver el
nuevo módulo denominado producir visualización. bosque».
TR A N SA C C IO N ES
En m uchas aplicaciones software, un solo elem ento de 14.6. R efinando el flujo, se desarrolla un nivel 2 del
datos inicia uno o varios de los flujos de inform ación diagram a de flujo (también se crearían un diccionario
que llevan a cabo una función derivada por el elemento de datos correspondiente, EC y EP) que se muestra en
de datos iniciador. El elem ento de datos, denom inado la Figura 14.13.
transacción, y sus características de flujo correspon Como se m uestra en la figura, Ordenes y datos del
dientes se trataron en la Sección 14.5.2. En esta sec usuario fluye al sistema y provoca un flujo de infor
ción consideram os los pasos de diseño usados para m ación adicional a lo largo de uno de tres caminos de
tratar el flujo de transacción. acción. Un elemento de datos, tipo de o rd en ,hace que
el flujo de datos se expanda del centro. P or tanto, la
característica general del flujo de datos es de tipo tran
sacción.
Debería recalcarse que el flujo de inform ación a lo
largo de dos de los tres cam inos de acción acomodan
flujos de entrada adicionales (por ejemplo, parámetros
y datos del sistema son entradas en el camino de acción
a «configurar»). Todos los caminos de acción fluyen a
una sola transformación, mostrar mensajes y estado.
Le er I P ro d u c ir ■ G e n e ra r ■ E sta b le c er L
la c o n e x ió n 1 14.7.2. P a s o s d e l d is e ñ o
. s en s o res 1 v is u a liza c ió n 1 s eñ a l d e a la rm a 1
a la re d te le fó n ic a 1 Los pasos del diseño para el análisis de las transaccio
nes son similares y en algunos casos idénticos a los pasos
para el análisis de las transform aciones (Sección 14.6).
G e n e ra rp u ls o s |
La principal diferencia estriba en la conversión del DFD
e n la linea en la estructura del software.
Paso 1. R evisar el m odelo fundam ental del sis
F IG U R A 1 4 .1 2 . Estructura refinada del program a
tema.
para monitorizar sensores. Paso 2. Revisar y refinar los diagram as de flujo de
datos para el software.
14.7.1. Un eje m p lo Paso 3. Determ inar si el DFD tiene características
El análisis de las transacciones se ilustrará conside de flujo de transformación o de transacción.Los pasos
www.FreeLibros.org
rando el subsistema de interacción con el usuario del 1,2 y 3 son idénticos a los correspondientes pasos del
software HogarSeguro. El nivel 1 del flujo de datos de análisis de las transformaciones. El DFD m ostrado en la
este subsistem a se m uestra com o parte de la Figura Figura 14.13tiene la clásicacaracterísticade flujodetran-
252
C A P Í T U L O 14 DISEÑO A RQU ITE CTÓ NICO
Órdenes Datos
y datos Parámetros de configuración
del usuario y datos de sistema o n h r u tr »
Datos form ateados

de configuración
Inform ación de configuración |
Datos
de configuración
Contraseña
Mensaje de
«inténtelo de nuevo»
FIGURA 1 4.13 . Nivel 2 de DFD para el subsistema de interación del usuario con lím ites del flujo.
sacción. S in e m b a rg o , e l flu jo a lo la rg o d e dos d e los se d e s a rro lla d e la m is m a m a n e ra q u e p a ra u n a n á lis is

caminos de a cc ió n que e m a n a n desde la b u rb u ja invocar d e tra n s fo r m a c ió n . E m p e z a n d o p o r e l c e n tro d e tr a n
elprocesamientode laorden p a re c e te n e r c a ra c te rís tic a s s ac ció n , las b u rb u ja s que h a y a lo la rg o d e l c a m in o de
de flu jo de tra n s fo rm a c ió n . P o r ta n to , se d e b e n e s ta b le e n tra d a se c o n v ie rte n e n m ó d u lo s . L a e s tru c tu ra d e la
cer los lím ite s de flu jo p a ra a m b o s tip o s d e flu jo s . ra m a de d is trib u c ió n c o n tie n e u n m ó d u lo d is tr ib u id o r
q u e c o n tro la to d o s lo s m ó d u lo s d e a c c ió n s u b o rd in a
Paso 4. Identificar el centro de transacción y las
dos. C a d a c a m in o d e flu jo d e a c c ió n d e l D F D se c o n
características de flujo a lo largo de cada cam ino de
v ie r te e n u n a e s tr u c tu ra q u e c o rre s p o n d e a sus
acción. L a p o s ic ió n tran s ac ció n se pu e d e d is c e rn ir in m e
c a ra c te rís tic a s e s p e c ífic a s d e flu jo . E s te p ro c e s o se ilu s
diatam ente d e l D F D . E l c e n tro d e tra n s a c c ió n está e n e l
tra e s q u e m á tic a m e n te e n la F ig u ra 1 4 .1 4 .
origen de v a rio s c a m in o s d e a c c ió n q u e flu y e n r a d ia l
mente desde él. P a ra e l flu jo m o s tra d o e n la F ig u ra 1 4.13 ,
la b u rb u ja invocar elprocesamiento de la orden es e l
centro de tra n s a c c ió n . \ a VE
E l c am in o de e n tra d a (p o r e je m p lo e l c a m in o d e flu jo I a descomposición de primer nivel tiene como resultado
a lo largo d e l que se re c ib e u n a tra n s a c c ió n ) y to dos los Id derivación de la paqLfe de control poro el software,
lo descomposición de segundo nivel distribuye los
caminos de a cc ió n d e b en aislarse. L o s lím ite s que d e fin e n
módulos de fiabajp a los corÉdodoes opropiodos.
un c am in o de re c e p c ió n y los c a m in o s de a cc ió n ta m b ié n
se m uestran e n la fig u ra. Se debe e v a lu a r las c a ra c te rís ti C o n s id e ra n d o e l flu jo d e datos d e l su b sis te m a d e inte
cas in d ivid u a les de flu jo de c a d a c a m in o d e acció n. P o r racción del usuario, la d e s c o m p o s ic ió n d e p rim e r n iv e l
ejem plo, e l c a m in o « d e la contraseña» (m o s tra d o in c lu id o d e l p a so 5 se m u e s tra e n la F ig u ra 1 4 .1 5 . L a s b u rb u ja s
en un área so m b re ad a e n la F ig . 1 4 .1 3 ) tie n e c a ra c te rís ti leer órdenesdel usuarioy activarldesactivar el sistema
cas de tra n s fo rm a c ió n . L o s flu jo s de en tra d a , de tra n s fo r se c o n v ie rte n d ire c ta m e n te e n la a rq u ite ctu ra , sin la n ece
mación y de s alid a se in d ic a n co n lím ite s . s id a d d e m ó d u lo s in te rm e d io s d e c o n tro l. E l c e n tro d e
Paso 5. Transformar el DFD en una estructura de tra n s a c c ió n , invocar elprocesamiento de la orden, se
programa adecuada al procesam iento de la tran c o n v ie rte d ire c ta m e n te e n u n m ó d u lo d is trib u id o r co n
www.FreeLibros.org
sacción. E l f lu jo d e tra n s a c c ió n se c o n v ie r te e n u n a e l m is m o n o m b re . Los c o n tro la d o re s d e la c o n fig u r a
arq u ite c tu ra q u e c o n tie n e u n a r a m a d e e n tra d a y u n a c ió n d e l s is te m a y p ro c e s a m ie n to d e la c o n tra s e ñ a se
rama de d is trib u c ió n . L a e s tru c tu ra d e la ra m a d e e n tra d a o b tie n e n c o m o se in d ic a e n la F ig u ra 1 4.16 .
253
IN GE NI E RÍ A DEL S O F T W A R E . UN E N F O Q U E P R A C T I C O
Control
de transacción
Distribuidor
Camino
de recepción
F IG U R A 1 4 .1 4 . Análisis de transacción. F IG U R A 1 4 .1 5 . Descomposición en factores de prim er nivel

del subsistema interacción del usuario.
www.FreeLibros.org
F IG U R A 1 4 .1 6 . Primera iteración de la estructura del program a del su b sic tem a interacción del u su ario.
254
C A P Í T U L O 14 DISEÑO ARQUITECTÓNICO
Paso 6. D e sc o m p o n er y r e f in a r la e s tr u c tu r a de y u n m e n sa je d e a d v e rte n c ia (f lu jo d e sa lid a ) si n o

transacción y la e s tru c tu r a d e to d o s los cam inos de co in c id e con ninguna.
acción. C ad a cam in o de acció n del d iag ram a de flu jo E l c a m in o « c o n fig u ra r» s e d ib u ja sim ilarm en te
de datos tien e sus p ro p ia s c a ra c terístic a s de flu jo de usando el análisis de transform ación. L a arquitectura d e
inform ación. Ya h e m o s d ic h o a n te rio rm e n te que se softw are resultante se m u e stra e n la F igura 14.16.
pueden e n c o n tra r flu jo s de tra n sfo rm a c ió n o de tra n
sacción. L a «subestructura» relacio n ad a con el cam ino P aso 7. R efin ar la p rim e ra a r q u ite c tu ra del p ro
de acción se d e s a rro lla u san d o lo s p a so s e stu d ia d o s g ra m a u san d o h e u rístic a s d e diseño p a r a m e jo ra r la
en esta secció n y en la anterior. c a lid a d del so ftw a re . E ste p a so del an álisis de tra n
sacción es idéntico al c o rresp o n d ien te p aso del análisis
Por e je m p lo , c o n sid e re el flu jo de in fo rm ac ió n del
de transform ación.
p rocesam iento d e c o n tra s e ñ a m o s tra d o (d e n tro del
área som breada) en la F ig u ra 14.13. E l flu jo p re sen ta E n am bos m étodos d e diseñ o se d e b en considerar cu i
las característicasclásicas de transform ación. Se in tro d ad o sam en te c rite rio s ta le s c o m o in d e p en d en c ia del
duce una co n tra se ñ a (flu jo d e en trad a) y se tra n sm ite m ó d u lo , co n v en ie n cia (eficacia de im plem entación y
a un centro de tra n sfo rm a c ió n d o n d e se c o m p a ra con prueba) y facilidad de m an ten im ie n to a m edida que se
las co ntraseñas alm acen ad as. Se p ro d u ce u n a a larm a proponen m odificaciones estructurales.
K 5. R E F I N A M I E N T O D E L D IS E A Q ARQ1
El éxito de la aplicación del análisis de transform ación o m em oria o de tiem po, la delim itación de los valores o
de transacción se co m plem entaañadiendo la d o cum enta cantidades de las estructuras de datos, los casos esp e
ción adicional requerida com o p arte del diseño arquitec ciales no considerados y las características específicas
tónico. D espués de h ab er d esa rro lla d o y refinado la de un m ódulo individual. El p ro p ó sito de una sección
estructura, se deben com pletar las siguientes tareas: restricciones/lim itaciones es re d u c ir el núm ero de erro
« se debe desarrollar una descripción del procesam iento res debidos a características fu n cio n ales asum idas.
para cada m ódulo. U na vez que se h a desarrollado la docum entación de
diseño para todos los m ódulos, se lleva a cabo una revisión
• se aporta u n a d esc rip c ió n de la in te rfaz p a ra ca d a
(vea las directrices de revisión en el C apítulo 8). L a revi
módulo.
sión hace hincapié en el seguim iento de los requisitos del
• se definen las estructuras de datos generales y locales.
soft waie, j calidad ^ ja arquitectura del programa, las d es'
• se anotan to d a s las lim ita c io n e s /re s tric c io n e s del
criDciones de las interfaces, las desciiDciones de las estruc
diseño. turas de datos, los datos prácticos de la im plem entación,la
• se lleva a cabo u n a rev isió n del diseño. capacidad de prueba y la facilidad de mantenimiento.
• se considera un « refinam iento»(si es n ecesario y está
justificado).
%
« ¿Qué pasa una vez que
W la arquitectura ha sido creada?
Documento del diseñode software.
Un tex to ex p lic a tiv o del p ro c e sa m ie n to es (id e al D ebe fom entarse el refinam iento de la arquitectura
mente) u n a d e lim ita d a d esc rip c ió n sin am big ü ed ad es del so ftw are d u ra n te las p rim e ra s e ta p a s d e l d iseño.
del p rocesam iento que ocurre dentro de u n m ódulo. L a C om o y a d ijim o s anterio rm en te en e ste c a p ítu lo , los
narrativa describe el procesam iento, las tareas, las deci- estilos arquitectónicos alternativos deben ser derivados,
sionesy la entrada/salida. L a d escripción de la interfaz refinados y ev alu ad o s para un «m ejor» enfoque. E ste
requiere el d ise ñ o de in te rfa c e s in te rn a s de m ó d u lo , enfoque de optim ización es uno de los verdaderos b en e
interfaces ex tern as del sistem a y la in te rfaz h o m bre- ficios derivados del desarrollo de la representación de
computadora (C apítulo 15).E l diseño de estructuras de la arquitectura del softw are.
datos puede ten er u n p rofundo im pacto en la arquitec Es im portante anotar que la sim plicidad estructural es,
tura y en los detalles p rocedim entales de cada c o m p o a m enudo, reflejo de eleganciay eficiencia. El refinamiento
nente del softw are. T a m b ié n se d o c u m e n ta n las del diseño debería luchar p o r obtener un pequeño núm e
www.FreeLibros.org
restriccio n es/lim itacio n es de ca d a m ó d u lo . A lgunos ro de m ódulos consecuentes a la m odularidad operativa
aspectos típicos que p u e d e n tra ta rse in cluyen: la re s y la estructura de datos m enos com pleja que sirva ade
tricción de tipo o form ato de datos, las lim itaciones de cuadam ente a los requisitos de inform ación.
255
IN GE NIE RÍA DEL SOF TW ARE . UN EN F O Q U E P R Á C T I C O
La arquitecturadel software nos proporciona una visión la eficacia de cada arquitectura propuesta. Esto se con
global del sistema a construir. Describe la estructura y sigue determ inando la sensibilidad de los atributos de
la organización de los componentes del software, sus calidad seleccionados (también llamados dimensiones
propiedades y las conexiones entre ellos. Los com po del diseño) con diferentes m ecanismos de realización
nentes del software incluyen m ódulos de program as y que reflejan las propiedades de la arquitectura.
varias representaciones de datos que son manipulados El m étodo de diseño arquitectónico presentado en
por el programa. Además, el diseño de datos es una par este capítulo utiliza las características del flujo de datos
te integral para la derivación de la arquitectura del soft descritas en el m odelo de análisis que derivan de un esti
ware. La arquitectura m arca decisiones de diseño lo arquitectónico utilizado com únm ente. El diagrama
tempranas y proporciona el m ecanismo para evaluar los de flujo de datos se descompone dentro de la estructu
beneficios de las estructuras de sistema alternativas. ra del sistema a través de dos enfoques de análisis—el
El diseño de datos traduce los objetos de datos defi análisis de las transform aciones y/o el análisis de las
nidos en el m odelo de análisis, en estructuras de datos transacciones — . Se aplica el análisis de las transfor
que residen dentro del software. Los atributos que des m aciones a un flujo de inform ación que presenta dife
cribe el objeto, las relaciones entre los objetos de datos rentes límites entre los datos de entrada y de salida. El
y su uso dentro del program a influyen en la elección de DFD se organiza en una estructura que asigna los con
la estructura de datos. A m ayor nivel de abstracción, el troles de entrada, procesam iento y salida a través de tres
diseño de datos conducirá a lo que se define como una jerarquías separadas de m ódulos de descomposición en
arquitectura para una base de datos o un almacén de datos. factores. El^ análisis de las transform aciones se aplica
El ingeniero del software cuenta con diferentes esti cuando un Único ítem de inform ación bifurca su flujo a
los y patrones arquitectónicos. Cada estilo describe una través de diferentes caminos. El DFD se organiza en
categoría de sistema que abarca un conjunto de com una estructura que asigna el control a una subestructu-
ponentes que realizan una función requerida por el sis ra que adquiere y evalúa la transacción. Otra subes-
tem a, un conjunto de conectores que posibilitan la tructura controla todas las acciones potenciales de
com unicación, la coordinación y cooperación entre los procesam iento basadas en la transacción. Una vez que
componentes, las restricciones que definen cómo se inte la arquitectura ha sido perfilada se elabora y se analiza
gran los componentes para conform ar el sistema, y los contrastándola con los criterios de calidad.
modelos semánticos que facilitan al diseñador el enten El diseño arquitectónico agrupa un grupo inicial d e
dimiento de todas las partes del sistema. actividades de diseño que conducen a un m odelo com
Han sido propuestos uno o varios estilos arquitectó pleto del diseño del software. En los siguientes capítu
nicos por sistema, y el m étodo de análisis de com pro los, se estudiará el diseño de las interfaces y de los
misos para la arquitectura podría utilizarse para evaluar componentes.
ftE E E B E K H j& fik , ; ___ _ ______ - ____ £_____ — J

[AH083] Aho, A.V., J. Hopcroft y J.Ullmann, Data Structu- [KAZ98] Kazman, R. TheArchitectural Tradeoff Analysis
res andAlgorithms, Addison-Wesley, 1983. Method, Software Engineering Institute, CMU/SEI-98-
TR-008. Julio 1998.
[BAS98] Bass, L., P. Clementsy R. Kazman,Software Archi-
tecture in Practice, Addison-Wesley, 1998. [KIM98] Kimball, R., L. Reeves, M. Ross y W. Thomthwai-
[DAH72] Dah, O., E. Dijkstra y C. Hoare, Structured Pro- te, The Data WarehouseLifecycle Toolkit: Expert Methods
gramming, Academic Press, 1972. f o r Designing, Developing, and Deploying, Data Ware-
houses, Willey, 1998.
[DAT95] Date, C J .,A n Introduction to Database Systems,
Sexta Edición, Addison-Wesley, 1995. [LIN79] Linger, R.C., H.D. Mills y B.I. Witt, Structured Pro-
[DEN73] Dennis, J.B., «Modularity», en Advanced Course gramming, Addison-Wesley, 1979.
on Software Engineering, EL. Bauer (ed.), Springer-Ver-
[MAT96] Mattison, R.,D ata Warehousing: Strategies, Tech
lag, Nueva York, 1973,pp. 128-182.
nologies and Techniques, McGraw-Hill, 1996.
[FRE80] Freeman, P., «The Context c£ Design», in Software
Design Techniques (L.P. Freeman y A. Wasserman, eds.), [MOR80] Morris, J., «Programming by Successive Refine-
IEEE Computer Society Press, 3.”ed., 1980,pp. 2-4. ment of Data Abstractions», Software-Practice and Expe-
rience, vol. 10,núm. 4, abril 1980, pp. 249-263.
www.FreeLibros.org
[INM95] Inmon, W.EL, «What is a Data Warehouse?» Prism
Solutions, Inc. 1995, presentada en: [MYE78] Myers, G., Composite Structures Design, Van-
http://w w w .cait.w ustl.edu/cait/papers/prism /voll_nol. No strand, 1978.
256
CAPÍTULO 14 D IS E Ñ O A R Q U I T E C T Ó N I C O
[PET81] Peters, L.J., S oftw are D esig n : M eth ods an dT ech n i- [WAS80] W asserm an, A., «Principies o f S y stem atic Data
ques, Yourdon Press, Nueva York, 1981. D esign and Im plem entation», en S o ftw a re D e s ig n Tech-
[PRE98] Preiss, B.R. D a ta Structures a n d A lg o rith m s: With n iqu es (P. Freem an y A. W asserman, eds.), 3.a ed., IEEE
O h ject-O rien tedD esign P a ttern s in C + + , W iley, 1998. C om puter Society Press, 1980,pp. 287-293.
[SHA96] S haw ,M .,y D. (¡arlan. Sofhvare A rquitecture, Pren- [WIR71] W irth,N ., «Program Development by Stepw ise Refi-
tice Hall, 1996. ' nem ent», CACM , vol. 1 4,n.°4, 1971, pp. 221-227.
[SHA97] Shaw, M., y P. Clem ents, «A Field G uide to Boxo- [YOU79] Yourdon, E., y L. Constantine, Structures D e sig n ,
logy: Preliminary C lassificationof Architectural Styles for Prentice-Hall, 1979.
Software System s», P roc. C O M P S A C , W ashington DC,
Agosto 1997. [ZHA98] Zhao, J., «On Assessing the C om plexity o f S o ft
w are A rchitectures», P ro c. Intl. S o ftw a re A rc h ite c tu re
[STE74] Stevens, W., G. M yers y L. Constantine, «Structu- W orkshop, ACM , Orlando, Florida, 1998, pp. 163-167.
red D esign», IB M S ystem J o u rn a l, vol. 13, n.° 2, 1974,
pp. 115-139.
BEllQBLEMAS. Y.g.U.HXQS.fl C.QNSlDüfiAJL

141. Usando la arquitectura de una casa o un edificio a modo Estudie com o afectará esta opinión a la estructura del soft
(fe metáfora, dibuje com paraciones con la arquitectura del ware que se obtiene cuando un flujo orientado a transacción
software. ¿En qué se parecen la disciplina de la arquitectura es tratado com o de transformación. Utilice un flujo de ejem
clásica y la de la arquitectura del software? ¿En qué se dife plo para ilustrar los puntos importantes.
rencian?
14.12. Si no lo ha hecho, complete el Problema 12.12. U tili
14.2. Escriba un documento de tres a cinco páginas que con ce los métodos de diseño descritos en este capítulo para desa
tenga directrices para la selección de estructuras de datos rrollar una estructura de programa para el SSRB.
basándose en la naturaleza del problem a. Em piece delim i
tando las clásicas estructuras de datos que se encuentran en
14.13. M ediante un diagrama de flujo de datos y una d e s
cripción del procesam iento, describa un sistem a basado en
el software y después describiendo los criterios para la selec
ción de éstos para tipos particulares de problemas. computadora que tenga unas características de flujo de tran s
form ación singulares. Defina los límites del flujo y transfor
14.3. Explique la diferencia entre una base de datos que sir me el DFD en la estructura software usando una técnica de las
ve a una o más aplicaciones de negocios convencionales y un descritas en la Sección 14.6.
almacén de datos.
14.14. M ediante un diagram a de flujo de datos y una d e s
14.4. Escriba un docum ento de tres a cinco página que d e s crip ció n de procesam iento, describa un sistem a b asad o en
criba cómo se utilizan las técnicas de m inería de datos en com putadora que tenga unas características de flujo de tran
un entorno de n egocio y el estado actual de las técnicas sacción claras. D efina los lím ites del flujo y direcciones el
DCBC. D FD en una estructura software utilizando la técnica descri
14.5. Presente dos o tres ejemplos de aplicaciones para cada ta en la Sección 14.7.
estilo arquitectónico citado en la Sección 14.3. E
14.15. Usando los requisitos obtenidos en un estudio hecho
14.G. Algunos de los estilos arquitectónicos citados en la Sec en clase, complete los D FD y el diseño arquitectónico para el
ción 14.3.1. sonjerárquicos por naturaleza y otros no. Haga ejem plo/íogarScgM rapresentadoenlas Secciones 14.6 y 14.7.
una lista de cada tipo. ¿Cómo se im plem entanlos estilos arqui Valore la independencia funcional de todos los módulos. D ocu
tectónicos no jerárquicos? mente su diseño.
14.7. Seleccione una aplicación que le sea familiar. C ontes 14.16. Estudie las ventajas y dificultades relativas de aplicar
te cada una de las preguntas propuestas para el control y los un diseño orientado al flujo de datos en las siguientes áreas:
datosdela Sección 14.3.2. (a) aplicaciones de m icroprocesador em potrado, (b) análisis
14.8. Estudie el M A CA (utilizando el libro de [KAZ98]) y de ingeniería/científico, (c) gráficos por computadora, (d) dise
presente un estudio detallado de los seis pasos presentados ño de sistemas operativos, (e) aplicacionesde negocio, (f) dise
• en la Sección 14.4. E ño de sistem as de gestión de bases de datos, (g) diseño de
software de comunicaciones, (h) diseño de compiladores, (i)
149. Seleccione una aplicación que le sea familiar. U tili aplicaciones de control de proceso y (j) aplicaciones de inte
zando, donde sea requerido, su m ejor intuición, identifique ligencia artificial.
el conjunto de dim ensiones del diseño y después realice el
análisis del espectro y el análisis de la selección del diseño. 14.17. D ado un conjunto de requisitos que le proporcione
su profesor (o un conjunto de requisitos de un problem a en
14.10. Estudie el EDC (utilizando el libro de [SH A 96]) y
el que esté trabajando actualm ente) desarrolle un diseño
desarrolle un espacio de diseño cuantificado para una aplica
arquitectónico com pleto. Lleve a cabo una revisión del dise
www.FreeLibros.org
ción que le sea familiar.
ño (Capítulo 8) para valorar la calidad de su diseño. Este pro
14.11. Algunos diseñadores defienden que todo el flujo de blem a debe asignarse a un eq uipo en vez de a un solo
, datos debe ser tratado com o orientado a transform aciones. individuo.
257
IN GE NI ER IA DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
Durante la Última década han aparecido muchísimos libros Docenas de libros actuales, a menudo abordan el diseño
sobre arquitectura de software. Los libros de Shaw y Gannon de datos y el diseño de estructuras desde un contexto especí
[SHA96], Bass, Clementsy Kazman [BAS98] y Buschmann fico del lenguaje de programación. Algunos ejemplos típicos
y colaboradores[BUS98], proporcionan un tratamiento en los encontramos en:
profundidad sobre la materia. El primer trabajo de Garlan (An Horowitz, E. Y S. Sahni, Fundamentáis <±Data Structures
Introduction to Software Architecture, Software Engineering in Pascal, AI ed., W.H Freeman& Co., 1999.
Institute, CMU/SEI-94-TR-021,1994) proporciona una exce
Kingston, J.H., Algorithms and Data Structures: Design,
lente introducción al tema.
Correctness,Analysis,21 ed., Addison-Wesley, 1997.
Los libros específicos de implementación de arquitectu
ra, sitúan el diseño arquitectónico dentro de un entorno espe Main, M., Data Structures & Otlier Ohjects Using Java,
cífico de desarrollo o tecnología. Mowray (CORBA Design Addison-Wesley, 1998.
Patterns, Wiley, 1997)y Mark y colaboradores(ObjectMana- Preiss, B.R., Data Structures andAlgorithms: With Object-
gement Architecture Guide, Wiley, 1996) proporcionan pará OrientedDesign Patterns in C++, Wiley, 1998.
metros de diseño detallados para el marco de soporte de las Sedgew ick. R., ,4Igorithms inC++: Fundamentáis, Data
aplicaciones distribuidas de CORBA. Shanley (Protected Structures,Sorting, Searching, Addison-Wesley, 1999.
Mode Software Architecture, Addison-Wesley, 1996) pro Standish,T.A., Data Structures in Java, Addison-Wesley,
porciona una guía de diseño arquitectónico para aquellos que 1997.
diseñen sistemas operativos a tiempo real basados en com Standish,T.A., Data Structures, 1Igorithms, and Software
putadora, sistemas operativos multitarea o controladores de Principies in C, Addison-Wesley, 1995.
dispositivos.
Las investigaciones actuales sobre arquitectura de soft En la mayoría de los libros dedicados a la ingeniería de soft
ware están recogidas en el anuario Proceedings ofthe Inter ware se puede encontrar un tratamiento general del diseño del
national Workshopon SoftwareArchitecture, patrocinado por software en discusión con el diseño arquitectónicoy el diseño
la ACM y otras organizaciones de computadoras y en el Pro de datos. Los libros de Pfleeger (SoftwareEngineering:Theory
ceedings of the International Conference on Software Engi- and Practice, Prentice may, 1998) y Sommerville {Software
neering. Engineering, 5." ed., Addison-Wesley, 1995) son representati
El modelado de datos es un prerrequisito para un buen vos de los libros que cubren en detalle el tema del diseño.
diseño de datos. Los libros de Teory (Database Modeling Se puede encontrar un tratamientomás riguroso de la mate
& Design, Academic Press, 1998), Schimdt (DataModeling ria en Feijs (Formalization ofDesign Methods, Prentice may,
f o r Information Professionals, Prentice Hall, 1998), Bobak, 1993), Witt y colaboradores (SoftwareArcliitecture andDesign
(DataModeling and Design f o r Today's Ar chite ctur es, Principies, Thomson Publishing, 1994) y Budgen (Software
Artech House, 1997), Silverston, Graziano e Inmon (The Design, Addison-Wesley, 1994).
Data Model Resource Book, Wiley, 1997), Date [DAT95], Se pueden encontrar representaciones completas de dise
Reingruber y Gregory (The Data Modeling Handbook: A ños orientados a flujos de datos en Myers [MYE78], Yourdcn
Best-Practice Approach to Building Quality Data Models, y Constantine[YOU79], Buhr (SystemDesign withAda,Pren
Wiley, 1994), Hay (DataModel Patterns: Conventions of tice may, 1984), y Page-Jones (ThePractical Guide to Struc
Thought, Dorset House, 1994) contienen una presentación tured Systems Design, segunda edición, Prentice may, 1988).
detallada de la notación de modelado de datos, heurísticas, Estos libros están dedicados solamente al diseño y propor
y enfoques de diseño de bases de datos. En los últimos años cionan unas completas tutorías en el enfoque de flujo de datos.
el diseño de almacenes de datos ha ido cobrando importan En Intemet están disponibles una gran variedad de fuen
cia. Los libros de Humphreys, Hawkins y Dy (DataWare- tes de información sobre diseño de software y temas relacio
housing: Architecture and Implementation, Prentice Hall, nados. Una lista actualizada de referencias web sobre
1999), Kimball [KIM98] e Inmon [INM95] cubren con gran conceptos y métodos de diseño relevantes se puede encon
detalle la materia. trar en: http://www.pressman5.com.
C A PÍT U L O
D IS E Ñ O DE LA IN T E R F A Z
DE U S U A R IO
L plano de una casa (su diseño arquitectónico) no está completo sin la representación de
E puertas, ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no

m encionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios»
del software informático es lo que constituye el diseño de la interfaz de usuario.
El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los
componentes del software; (2) el diseño de las interfaces entre el software y los otros produc
tores y consumidores de inform ación no hum anos (esto es, otras entidades externas) y (3) el
diseño de la interfaz entre el hom bre (esto es, el usuario) y la computadora. En este capítulo
nos centraremos exclusivamente en la tercera categoría de diseño de interfaz — el diseño de la
interfaz de u s u a r io - .
Ben Shneiderman [SHN87] habla sobre esta categoría de diseño en el prólogo de su libro y
afirma lo siguiente:
Para muchos usuarios de sistemas de información computerizados la frustración y la ansiedad forman
parte de su vida diaria. Luchan por aprender el lenguaje de órdenes y los sistemas de selección de menús
que supuestamente les ayudan a realizar su trabajo. Algunas personas se encuentran con casos tan serios
de shocks informáticos, terror en el terminal o neurosis en la red, que evitan utilizar sistemas computeri
zados.
VISTAZO RAPIDO
¿Qué es? El diseño de la interiaz de usua independientemente de la potencia

rio es la categoría de diseño que crea un informática que demuestre o de la fun y Ies í»o|i-sj£síScocIi5s& á» km «Isiais
medio de comunicación entre el hombre cionalidad que ofrezca. Dado que la principales y secundarios del menú. Las
y la máquina. Con un conjunto de prin interfaz es iá que da forma a la percep herramientas se utiliza! . iaqr.
cipios para el diseño de la interfaz, el ción del software por parte del usuario, prototipos ? pbf últim éailém iiiitótéL
diseño identifica los objetos y acciones tiene que estar bien diseñada. modelo de diseñó y m eñm s leíórRAs»
^ de la interfaz y crea entonces uri forma- del resoltado. '-
¿Cuáles son los pasos? El diseño de la
si ! to de pantalla que formará la base del ¿Cuál es el pee dude eMeeMé?. •••.rre-
interfaz de usuario comienza con la
’ prototipo de interiaz de usuario. ación de esees
identificación de los requisitos del usua
¿Quién lo hace? El ingeniero del software rio! de la tarea y del entorno. Una vez , . efoi i .
es quien diseña la interfaz de usuario identificadas las tareas, se crean y se . el desanolloy recî ié - s. -:n toen^voV:
. mediante la aplicación del proceso ite analizan los escenarios del usuario pena prototipos. •.
rativo que se sirve de los principios pre definir el conjunto de objetos y de accio |.Céaae ptm ie mMjt
definidos del diseño. nes de la interfaz. Esto es lo que forma he heche i in i eite—su le t" i. i
¿Por qué es im portante? Si el software la base para la creación del formato de rico» controlo:-, él pss>t;>llpo fiasdiéta»''
es difícil de utilizar, si obliga a cometer la pantalla que representa el diseño grá
errores, o causa frustración para conse fico y la colocación de iconos, la defini trol del texto se utiliza para la siguien
guir los objetivos, no será de agrado, ción del texto descriptivo en pantalla, la te modificación iterativa del prototipo.
Los problem as a los que alude Shneiderman son reales. Es cierto que las interfaces gráficas,
ventanas, iconos y selecciones mediante ratón han elim inado m uchos de los terribles proble
mas con la interfaz. Pero incluso en un «m undo de ventanas» todos encontramos interfaces de
www.FreeLibros.org
usuario difíciles de aprender, difíciles de utilizar, confusas, imperdonables y en m uchos casos
totalmente frustrantes. Sin em bargo, hay quien dedica tiem po y energías construyendo estas
interfaces, y es posible que estos problem as no los crearan a propósito.
259
IN GE NI E RÍ A DEL SOF TW AR E . UN E N F O Q U E P R Á C T I C O
T h e o M a n te l [ M A N 9 7 ] e n su lib ro c re a tres « re g la s d e in te ra c tu a r a tra v é s d e las ó rd e n e s d e l te c la d o , con el

o ro » p a ra e l d is e ñ o d e la in te rfa z : m o v im ie n to d e l ra tó n , c o n u n lá p iz d ig ita liz a d o r, mediante
1. D a r e l c o n tro l a l u s u a rio ó rd en e s p a ra e l re c o n o c im ie n to d e v o z . S in e m b a rg o , no
to d a a c c ió n re s p o n d e a to d o m e c a n is m o d e interacción.
2. R e d u c ir la c a rg a d e m e m o ria d e l u s u a rio
C o n s id e re p o r e je m p lo , la d ific u lta d d e u t iliz a r órdenes
3 . C o n s tru ir u n a in te rfa z co n se cu en te d e l te c la d o ( o e n tra d a d e v o z ) p a ra d ib u ja r u n a form a
E stas re g la s d e o ro fo rm a n e n re a lid a d la base p a ra c o m p le ja .
lo s p rin c ip io s d e l d is e ñ o d e la in te rfa z d e u s u a rio q u e Perm itir que la interacción del usuario se pueda
s e rv irá n d e g u ía p a ra e sta a c tiv id a d d e d is e ñ o d e s o ft interrum pir y deshacer. C u a n d o u n u s u a rio se ve
w a re ta n im p o rta n te . in v o lu c ra d o e n u n a s ec u e n c ia d e a c c io n es , d e b e rá poder
in te rru m p ir la s e c u en c ia p a ra h a c e r c u a lq u ie r o tra cosa
15.1.1. Dar el control al usuario (s in p e rd e r e l tra b a jo que se h u b ie ra h e c h o anteriorm ente).
E l u s u a rio d e b e rá ta m b ié n te n e r la p o s ib ilid a d de
D u ra n te la sesió n de re c o p ila c ió n de lo s re q u is ito s p a ra
« d e s h a c e r» c u a lq u ie r acc ió n .
u n n u e v o s is te m a d e in fo r m a c ió n , u n u s u a rio c la v e fu e
p re g u n ta d o a c e rc a de lo s a trib u to s d e la in te rfa z g r á fi A lig era r la interacción a m edida que avanza el nivel
ca o rie n ta d a a v en tan a s. de conocim iento y p e rm itir p erso n a liza r la interacción.
E l u s u ario re sp o n d ió s o le m n e m e n te , « L o q u e m e gus E l u s u a rio a m e n u d o se e n c u e n tra h a c ie n d o la m ism a
t a r í a r e a lm e n te e s u n s is te m a q u e l e a m i m e n te . Q u e s ec u e n c ia d e in te ra c c io n e s d e m a n e ra re p e tid a . M erece
c o n o z c a lo q u e q u ie ro h a c e r antes d e n e c e s ita rlo y que la p e n a s e ñ a la r u n m e c a n is m o d e « m a c ro s » que
m e fa c ilite h a c e rlo . E s o es to d o . S im p le m e n te e s o .» p o s ib ilite al u s u a rio p e rs o n a liz a r la in te rfa z y así facilitar
M i p rim e ra re a c c ió n fu e m o v e r la c a b e z a y s o n re ír, la in te ra c c ió n .
y h a c e r u n a p a u sa p o r u n o s in s ta n te s . N o h a b ía n a d a
m a lo e n la s o lic itu d d e l u s u a rio . L o que q u e ría e ra que
u n s is te m a re a c c io n a ra a n te sus n e c e s id a d e s y q u e le
Uno ds bs errores más comunes que se comete
a y u d a ra a h a c e r las cosas. Q u e r ía c o n tro la r la c o m p u
Jw M fo « M o m o s diseñar oigo a pruebo de tontos
ta d o ra , y n o d e ja r q u e la c o m p u ta d o ra le c o n tro la ra . esíStíbes&nar ta ingenuidad de bs tontos.
L a m a y o r p a rte d e las re s tric c io n e s y lim ita c io n e s
im p u e s ta s p o r e l d is e ñ a d o r se h a n p e n s a d o p a ra s im
p lific a r e l m o d o d e in te ra c c ió n . P e ro , ¿para qu ien es? E n
m u c h o s casos es p o s ib le q u e e l d is e ñ a d o r in tr o d u z c a O cultar al usuario ocasional los entresijos técnicos.
lim ita c io n e s y re s tric c io n e s p a ra s im p lific a r la im p le - L a in te rfa z d e u s u a rio d e b e rá in tr o d u c ir a l u s u a rio en el
m e n ta c ió n d e la in te rfa z . Y e l re s u lta d o p u e d e ser u n a m u n d o v ir tu a l d e la a p lic a c ió n . E l u s u a rio n o tie n e que
in te rfa z fá c il de c o n s tru ir, p e ro fru s tra n te d e u tiliz a r. c o n o c e r e l s is te m a o p e ra tiv o , las fu n c io n e s de gestión
M a n d e l [ M A N 9 7 ] d e fin e u n a serie d e p rin c ip io s d e d e a rc h iv o s , o c u a lq u ie r o tro s e c re to d e la te cn o lo g ía
d is e ñ o q u e p e rm ite n d a r c o n tro l al u s u a rio : in fo r m á t ic a . E s e n c ia lm e n te , la in t e r f a z n o deberá
Definir los modos de interacción de manera que no r e q u e r ir n u n c a q u e e l u s u a r io in te ra c tú e a u n n ivel
obligue a que el usuario realice acciones innecesarias « in t e r n o » d e la m á q u in a ( p o r e je m p lo , e l u s u a rio no
y no deseadas. U n m o d o d e in te ra c c ió n es e l e s ta d o te n d rá q u e te c le a r n u n c a la s ó rd e n e s d e l sistem a
o p e ra tiv o d e sd e d e n tro d e l s o ftw a re d e a p lic a c ió n ).
a c tu a l de la in te rfa z . P o r e je m p lo , si e n e l p ro c e s a d o r
d e te x to s se s e le c c io n a e l corrector o rtográfico, e l D iseñar la interacción directa con los objetos que
s o ftw a re p a s a a m o d o c o r r e c to r o rto g rá fic o . N o h a y aparecen en la pantalla. E l u s u a rio tie n e u n sentim iento
n in g u n a ra z ó n p o r la q u e o b lig a r a q u e e l u s u a r io d e c o n tro l c u a n d o m a n ip u la los o b je to s necesarios para
p e rm a n e z c a e n este m o d o si e l u s u a rio de se a c o n tin u a r lle v a r a c ab o u n a ta re a de fo r m a s im ila r a lo que ocurriría
e d ita n d o u n a p a rte p e q u e ñ a d e te x to . E l u s u a rio d e b e rá si e l o b je to fu e r a a lg o fís ic o . C o m o e je m p lo de
te n e r la p o s ib ilid a d d e e n tra r y s a lir d e este m o d o sin m a n ip u la c ió n d ire c ta p u e d e ser u n a in te rfa z de aplicación
m u c h o o n in g ú n e s fu e rz o . que p e rm ita al u s u a rio « a la rg a r» u n o b je to (c a m b ia r su
ta m a ñ o ).
¿Cómo se diseñan interfaces
§ que den el control al usuario?
Tener en consideración una interacciónflexible. D a d o

15.1.2. Reducir la carga de memoria del u s u a r io
C u a n to m ás te n g a que re c o rd a r u n u s u ario , m ás propen
sa a e rro re s será su in te ra c c ió n c o n e l sistem a. E s ta es la
www.FreeLibros.org
que d ife re n te s usuarios tie n e n p re fe re n c ia s de in te ra c c ió n ra z ó n p o r la que u n a in te rfa z de u s u ario b ie n diseñada no
diferentes, se deberán p ro p o rc io n ar diferentes selecciones. p o n d rá a p ru e b a la m e m o ria d e l usuario . S ie m p re que sea
P o r e je m p lo , u n s o ftw a re que p u e d a p e rm itir al u s u ario p o s ib le , e l s is te m a d e b e rá « re c o rd a r» la in fo rm a c ió n per-
260
CAPÍTULO 15 D I S E Ñ O DE LA INTERFAZ DE U S U A R I O
tmente y ayudar a que el usuario recuerde m ediante un

escenario de interacción. M andel [M A N 97] define los
principios de diseño que hacen posible que una interfaz «íniraduzca cualquier
reduzca la carga de m em oria del usuario: u ilá g rto s para continuar...».
Reducir la dem anda de m em oria a corto p la zo .
Cuando los u su ario s se v e n in v o lu c ra d o s en ta re a s
complejas, ex ig ir u n a m em o ria a corto plazo puede ser
significativo. L a interfaz se d eberá d iseñar para reducir
los requisitos y recordar acciones y resultados anteriores. d iseño e stá n d a r que se m an tien e en to d a s las p resen
Esto se puede lle v a r a cab o m ed ian te clav es visu ales ta cio n e s de p an tallas; (2) que to d o s lo s m e c a n ism o s
que posibiliten al usuario reco n o cer acciones anteriores de e n tra d a s e lim iten a un co n ju n to lim ita d o y que se
sin tenerlas que recordar. u tilic e n c o n se c u e n te m en te p o r to d a la a p lic a c ió n , y
q u e (3 ) lo s m e c a n is m o s p a ra ir d e ta re a a ta re a se
Establecer valorespor defecto útiles. El conjunto inicial
h a y a n d e fin id o e im p le m e n ta d o c o n se c u e n te m en te .
efe valores p o r defecto tendrá que ser de utilidad para al
M an d el [M A N 97] d efin e u n c o n ju n to d e p rin c ip io s
usuario, pero un usuario tam bién deberá tener la capacidad
de d ise ñ o que a y u d ar a c o n stru ir u n a in te rfa z c o n s e
de especificar sus propias preferencias. Sin em bargo,
cuente:
deberá disponer de una opción de «reinicialización» que
le permita volver a definir los valores p o r defecto. P erm itir que el usu a rio realice una tarea en el
contexto adecuado. M u chas in terfaces im p le m e n ta n
Definir las deficiencias que sean intuitivas. C uando
c a p a s c o m p le ja s d e in te ra c c io n e s c o n d o c e n a s de
para d iseñar u n sistem a se u tiliz a la m n e m ó n ic a (por
im á g en es de p a n ta lla s. E s im p o rta n te p ro p o rc io n a r
ejemplo, alt-P p a ra in v o c a r la fu n c ió n de im p rim ir),
ind icad o res (por e je m p lo , títu lo s de v en tan as, ico n o s
ésta d eberá ir u n id a a u n a a c c ió n q u e se a fá c il de
g ráfico s, co d ific ac io n es en co lo res co n secu en tes) que
recordar (por ejem p lo , la p rim e ra le tra de la ta re a que
p o sib ilite n al u su ario co n o ce r el co n tex to del tra b a jo
se invoca).
que e stá llev an d o a cabo. A d em ás, el u su ario deb erá
se r c a p a z d e d e te rm in a r de d ó n d e p ro c e d e y qué
B ¿Cómo se pueden diseñar a lte rn a tiv a s e x is te n p a ra la tra n s ic ió n a u n a ta re a
w interfaces que reduzcan nueva.
la carga de memoria del usuario?
Elformato visual de la interfaz se deberá basar en una ¿Cómo se pueden construir

metáfora del mundo real. P or ejem plo, en un sistem a de w interfaces consecuentes?
pago de facturas se d e b e rá u tilizar la m etáfora de la
chequeray el registro del cheque p ara conducir al usuario
M antener la consistencia en toda la fa m ilia de
per el proceso del p ago de facturas. E sto hace posible que
aplicaciones. U n conjunto de aplicaciones(o productos)
el usuario com prenda bien las pistas y que no tenga que
deb erá im plem entar las m ism as reglas de d iseño para
memorizar una secuencia secreta de interacciones.
m antener la consistencia en to d a la interacción.
Desglosar la información d efo rm a progresiva. L a Los modelos interactivos anteriores han esperanzado
interfaz deberá organizarse de fo rm ajerárquica. E sto es, al usuario, no realicemos cambios a menos que exista
en cualquier in fo rm ació n sobre u n a ta re a se deb erá alguna razón convincente p a r a hacerlo. U n a vez que
presentar un objeto o algún co m portam iento en prim er una secuencia interactiva se h a co n v ertidoen un estándar
lugar a un nivel alto de abstracción. Y solo después de hecho (por ejem p lo , la utilización de alt-S para grabar
que el usuario in d iq u e su p re fe re n cia realiz an d o la un archivo), el usuario espera u tilizar esta com binación
selección m ediante el ratón se presen tarán m ás detalles. en todas las aplicaciones que se encuentre. U n cam bio
Un ejem plo m uy c o m ú n en m u ch as a p licacio n es de po d ría o rig in a r co n fu sió n (por ejem p lo , la utilización
procesamiento de texto es la función de subrayado dado de alt-S para invocar la función c am b iar de tam año).
que es una función que p ertenece al m enú de estilo de L os principios del diseño de interfaces tratados aquí
texto. Sin em bargono se m uestran todas las posibilidades y en sesiones anteriores proporcionan una guía básica
de subrayado. El usuario es el que debe seleccionar el para la ingeniería del softw are. E n la siguiente sección
subrayado, y así se presen tarán entonces las opciones de exam inarem os el proceso de diseñ o de la interfaz.
esta función (por ejem plo, subrayado sencillo, subrayado
doble, subrayado de guiones).
15.1.3. C o n s tr u c c ió n d e u n a in te rfa z c o n s is t e n t e
www.FreeLibros.org
La interfaz d eberá a d q u irir y p re se n ta r la in fo rm ació n
de form a c o n se c u e n te . E sto im p lic a (1) que to d a la Líneas Generales poro el diseño
información v isu al esté o rg a n iz a d a de a c u e rd o co n el de lo interíoces.
26 1
I N GEN IE RÍ A DEL S O F T W A R E . UN E N F O Q U E P R A C T I C O
El proceso global para el diseño de la interfaz de usua • usuarios esporádicosy con conocimientos:poseen
rio com ienza con la creación de diferentes modelos de un conocim iento sem ántico razonable, pero una
funcionam iento del sistema (la percepción desde fue retención baja de la inform ación necesaria para uti
ra). Es entonces cuando se determ inan las tareas orien lizar la interfaz;
tadas al hom bre y a lajn áq u in a que se requieren para « usuarios frecuentes y con conocimientos: poseen
lograr el funcionam iento del sistema; se tienen en con el conocim iento sintáctico y sem ántico suficiente
sideración los tem as de diseño que se aplican a todos como para llegar al «síndrom edel usuario avanzado)),
los diseños de interfaces; se utilizan herram ientas para esto es, individuos que buscan interrupciones breves
generar prototipos y por últim o para im plem entar el y m odos abreviados de interacción.
m odelo de diseño, y evaluar la calidad del resultado.
15.2.1. M odelos de diseño de la interfaz

j& M U H fó p fru ttzo n los profesionales
Cuando se va a diseñar la interfaz de usuario entran en
■ SlfeftBU do quieren decir «idiota»
ju ego cuatro modelos diferentes. El ingeniero del soft
ware crea un m od elo de d is e ñ o ; cualquier otro ingenie
ro (o el m ism o ingeniero del softw are) establece un
m odelo de u su a rio , el usuario final desarrolla una im a La percepción del sistema (el m odelo de usuario) es
gen mental que se suele llam ar m odelo de usuario o p er- la im agen del sistem a que el usuario final tiene en su
cepción d e l u su a rio , y los que im plementan el sistema mente. Por ejem plo, si se preguntara a un usuario de un
crean una im a g en de sistem a [RUBSS]. D esgraciada procesador de texto en particular que describiera su for
mente, todos y cada uno de los modelos pueden diferir m a de m anejar el program a, la respuesta vendría guia
significativamente. El papel del diseñador de interfaz da por la percepción del sistema. La precisión de la
es reconciliar estas diferencias y derivar una represen descripción dependerá del perfil del usuario (por ejem
tación consecuente de la interfaz. plo, los principiantes harían lo posible por responder
con una respuesta muy elemental) y de la familiaridad
global con el software del dominio de la aplicación. Un
usuario que com prenda por com pleto los procesadores
Referencia MtefeA de texto, aunque puede que haya trabajado solo una vez
Una fuente excelente de directrices de diseño y referencias con ese procesador específico, es posible que propor
se puede encontrar en www.ibm.com /¡bm /easy/ cione de verdad una descripción m ás com pleta de su
funcionam iento que el principiante que haya pasado
Un m odelo de diseño de un sistema completo incor unas cuantas semanas intentando aprender el funciona
pora las representaciones del software en función de los m iento del sistema.
datos, arquitectura, interfaz y procedimiento. La espe La imagen del sistema es una com binación de facha
cificación de los requisitos puede que establezca cier da externa del sistema basado en com putadora (la apa
tas limitaciones que ayudarán a definir al usuario del riencia del sistema) y la inform ación de soporte (libros,
sistema, pero el diseño de la interfaz suele ser un único m anuales, cintas de vídeo, archivos de ayuda) todo lo
tem a secundario de m odelo de interfaz'. cual ayuda a describir la sintaxis y la semántica del sis
El m odelo de usuario representa el perfil de los usua tema. C uando la im agen y la percepción del sistema
rios finales del sistema. Para construir una interfaz de coinciden, los usuarios generalmente se sienten a gus
usuario efectiva, «todo diseño deberá com enzar por to con el software y con su funcionamiento. Para llevar
conocer los usuarios destino, así com o los perfiles de a cabo esta «m ezcla» de modelos, el m odelo de diseño
edad, sexo, habilidades físicas, educación, anteceden deberá desarrollarse con el fin de acoplar la informa
tes culturales o étnicos, motivación, objetivos y perso ción del m odelo de usuario, y la im agen del sistema
nalidad» [SCH87] Además de esto se pueden establecer deberá reflejar de forma precisa la inform ación sintác
las siguientes categorías de usuarios: tica y semántica de la interfaz.
« p r in c ip ia n te s : en general no tienen co n o c im ien to s Los modelos descritos anteriormente en esta sección
sintáctico? ni co n o cim ien to s sem ánticos3 de la uti son «abstracciones de lo que el usuario está haciendo o
lización de la aplicación o del sistema; piensa que está haciendo o de lo que cualquier otra per-
3El conocim iento sem ántico se refiere al sentido subsiguientede apli
www.FreeLibros.org
1Por supuesto esto no e s com o debena ser. Para si stem as interactivos,
el diseño de la interfaz es tan im portante com o el diseño de los datos, cación —una com prensión de la realización de to d as las funciones,
arquitectura o el de com ponentes. del significado de e ntrada y salida, de las m etas y objetivos del sis
2 Eii este contexto el conocim iento sintáctico se refiere a la m ecánica tem a—.
de interacción que se requiere para utilizar la interfaz de fonna eficaz.
262
CAPÍTULO 15 DISEÑO DE LA INTERFAZ DE U S U A R I O
so n a p ie n s a q u e d e b e r ía e s ta r h a c ie n d o c u a n d o u t ili z a S e r e g is t r a n e l n iv e l d e c o n o c im ie n t o , la c o m p r e n s ió n
u n s is t e m a i n t e r a c t i v o » [ M O N 8 4 ] , E s e n c i a l m e n t e , e s t o s d e l n e g o c io y la r e c e p t iv id a d g e n e r a l d e l n u e v o s is t e
m o d e lo s p e r m i t e n q u e e l d i s e ñ a d o r d e l a i n t e r f a z s a t i s m a , y s e d e f in e n d ife r e n te s c a te g o r ía s d e u s u a r io s . E n
fa g a u n e le m e n t o c la v e d e l p r i n c i p i o m á s im p o r t a n t e c a d a c a te g o r ía s e lle v a a c a b o la e lic it a c ió n d e lo s r e q u i
d e l d is e ñ o d e la in t e r f a z d e u s u a r io : « q u ie n c o n o c e a l s ito s . E s e n c ia lm e n t e , e l in g e n ie r o d e l s o f t w a r e in t e n t a
u s u a r io , c o n o c e la s t a r e a s » . c o m p r e n d e r l a p e r c e p c i ó n d e l s i s t e m a ( S e c c i ó n 15 .2.1)
p a r a c a d a c la s e d e u s u a r io .
Cuando Id Imagen del slstem ay lo petcepclbndel sistema ’f r j T ’É * i ¿ ^ íld b e f visto primero

coinciden, el usuario puede utilizar lo apllcaclbn de forma i r i ^ . n r .■ p j l i x ! va a utilizarlo.
efectiva.
15.2.2. El p r o c e so d e d is e ñ o d e la in terfaz U n a v e z d e f in id o s lo s r e q u is it o s g e n e r a le s , s e ll e v a a
c a b o u n a n á l i s i s m á s d e t a l l a d o d e la s t a r e a s . S e i d e n t i f i
d e u su a r io
c a n , d e s c r i b e n y e l a b o r a n la s t a r e a s q u e l l e v a a c a b o e l
E l p r o c e s o d e d is e ñ o d e la s in t e r f a c e s d e u s u a r io e s i t e u s u a r io p a r a c o n s e g u ir lo s o b je t iv o s ( p o r e n c im a d e la c a n
r a t iv o y s e p u e d e r e p r e s e n ta r m e d ia n t e u n m o d e lo e s p i t id a d d e p a s o s it e r a t iv o s a tr a v é s d e la e s p ir a l) . E l a n á li
ral s i m i l a r a l a b o r d a d o e n e l C a p í t u l o 2 . E n l a F i g u r a s is d e t a r e a s s e e s t u d i a d e t a l l a d a m e n t e e n l a S e c c i ó n 1 5 .3 .
1 5 .1 s e p u e d e o b s e r v a r q u e e l p r o c e s o d e d i s e ñ o d e l a E l a n á lis is d e l e n to r n o d e u s u a r io s e c e n tr a e n e l
in te r fa z d e u s u a r io a c o m p a ñ a c u a t r o a c t iv id a d e s d i s t i n e n t o r n o d e l t r a b a jo f í s ic o . E n t r e la s p r e g u n t a s q u e s e
ta s d e m a r c o d e t r a b a j o [ M A N 9 7 ] : f o r m u l a n s e e n c u e n t r a n la s s ig u ie n t e s :
1. A n á l i s i s y m o d e l a d o d e u s u a r i o s , t a r e a s y e n t o r n o s . • ¿ D ó n d e se u b ic a r á fí s ic a m e n t e la in te r fa z ?
2 . D is e ñ o d e la in t e r f a z « ¿ D ó n d e s e s itu a r á e l u s u a r io ? ¿ L le v a r á a c a b o ta r e a s
3. I m p l e m e n t a c i ó n d e l a i n t e r f a z n o r e la c io n a d a s c o n e l in t e r f a z ?
4 . V a lid a c ió n d e la in t e r f a z « ¿ S e a d a p t a b i e n e l h a r d w a r e a la s l i m i t a c i o n e s d e l u z ,
e s p a c io o r u id o ?
E s ta r e c o p ila c ió n d e in fo r m a c ió n q u e fo r m a p a r te d e
la a c t iv id a d d e a n á lis is s e u t i l i z a p a r a c r e a r u n m o d e lo
d e a n á lis is p a r a la in t e r f a z . M e d ia n t e e s ta b a s e d e m o d e
lo s e c o m ie n z a la a c t iv id a d d e d is e ñ o .
£ ¿Cuál es e l objetivo
W del diseño de lo interíoz
de usuario?
E l o b je t iv o d e l d is e ñ o d e la in t e r f a z e s d e f in ir u n c o n
j u n t o d e o b je t o s y a c c io n e s d e in t e r f a z ( y s u s r e p r e s e n
ta c io n e s e n la p a n t a lla ) q u e p o s i b il it e n a l u s u a r io lle v a r
a c a b o t o d a s la s t a r e a s d e f i n i d a s d e f o r m a q u e c u m p l a n
t o d o s lo s o b je t iv o s d e u s a b ilid a d d e f in id o s p o r e l s is t e
m a . E l d is e ñ o d e la in t e r f a z s e a b o r d a m á s d e t a lla d a
m e n te e n la S e c c ió n 1 5 .4
L a a c t iv id a d d e im p le m e n t a c ió n c o m ie n z a n o r m a l
m e n te c o n la c r e a c ió n d e u n p r o t o t ip o q u e p e r m it a e v a
lu a r lo s e s c e n a rio s d e u t iliz a c ió n . A m e d id a q u e a v a n z a
L a e s p ir a l q u e se m u e s tr a e n la F ig u r a 1 5 .1 im p lic a e l p r o c e s o d e d is e ñ o it e r a t iv o , y p a r a c o m p le t a r la c o n s
q u e c a d a u n a d e la s t a r e a s a n t e r i o r e s a p a r e c e r á n m á s d e t r u c c ió n d e la in t e r f a z , s e p u e d e u t ili z a r u n k i t d e h e r r a
una v e z , e n d o n d e a m e d i d a q u e s e a v a n z a p o r l a e s p i m ie n ta s d e u s u a r io ( S e c c ió n 1 5 .5 ).
ral s e r e p r e s e n t a r á l a e l a b o r a c i ó n a d i c i o n a l d e l o s r e q u i L a v a lid a c ió n s e c e n tr a e n : ( 1 ) la h a b ilid a d d e la in t e r
s ito s y e l d i s e ñ o r e s u l t a n t e . E n l a m a y o r í a d e l o s c a s o s , f a z p a r a im p le m e n ta r c o r r e c ta m e n te to d a s la ta re a s d e l
la a c t i v i d a d d e i m p l e m e n t a c i ó n i m p l i c a l a g e n e r a c i ó n u s u a r i o , p a r a a c o p l a r t o d a s la s v a r i a c i o n e s d e t a r e a s , y
de p r o to tip o s — la ú n ic a f o r m a p r á c t ic a p a r a v a lid a r lo p a r a a r c h iv a r t o d o s lo s r e q u is it o s g e n e r a le s d e l u s u a r io ;
www.FreeLibros.org
q u e s e ha d i s e ñ a d o — . (2 ) e l g r a d o d e f a c i l i d a d d e u t i l i z a c i ó n d e l a i n t e r f a z y
L a a c t iv id a d d e a n á lis is in ic ia l s e c o n c e n tr a e n e l p e r d e a p r e n d iz a je , y ( 3 ) la a c e p ta c ió n d e la in t e r f a z p o r p a r
fil d e l o s u s u a r i o s q u e v a n a i n t e r a c t u a r c o n e l s is t e m a . te d e l u s u a r io c o m o u n a h e r r a m ie n ta Ú t il e n s u tr a b a jo .
263
i n g e n i e r í a d e l s o f t w a r e . u n e n f o q u e p r ac t i c o
¿í£i2¡^LjSííjjÉESÍi¿áEÉjtóBÉ$BÉ¡eB^2LÍ^£uIfijÉL¡Ei¡&2u
E n el C apítulo 13 se estudió la elaboración paso a paso de una serie de actividades im portantes: diseño del mobi
(llam ada tam bién refinam iento p aso a p aso y d escom po liario, selección de tejidos y m ateriales, selección de deco
sición funcional) com o m ecanism o p ara refinar las tareas rados en paredes y ventanas, presentación (al cliente),
de procesam iento necesarias p ara que el softw are lleve a costes y com pras. Todas y cada una de estas tareas pue
cabo la función deseada. M ás adelanteen este m ism o libro den elaborarse en otras subtareas. P or ejem plo, el diseño
tendrem os en consideración el análisis orientado a obje del m obiliario puede refinarse en las tareas siguientes: (1)
tos com o enfoque de m odelado p ara los sistem as basados dibujar el plano de la casa con las dim ensionesde las habi
en com putadora. El análisis de tareas p ara el diseño de la taciones; (2) ubicar ventanas y puertas en los lugares ade
interfaz o bien utiliza un enfoque elaborativo o bien orien cuados; (3) utilizar plantillas de m uebles para dibujar en
tado a objetos, pero aplicando este enfoque a las activi el plano un esbozo del m obiliario a escala; ( 3 ) m over el
dades humanas. esbozo del m obiliario para m ejorar su colocación; ( ^ e ti
El análisis de tareas se puede aplicar de dos m aneras. quetar el esbozo del m obiliario; (6) dibujar las dimensio
C om o y a hem os d estacad o an terio rm en te, un sistem a nes para m ostrar la colocación; (7) realizar un dibujo en
interactivo b asado en com pu tad o ra se suele u tilizar para p erspectiva para el cliente. P ara las otras tareas impor
reem p lazar u n a actividad m anual o sem i-m anual. P ara tantes del enfoque se puede utilizar un m étodo similar.
com prender las tareas que se h an de llev ar a cab o para
lo g ra r el objetivo de la actividad, un ingeniero4 deberá
entender las tareas que realizan los h om bres actualm ente CLAVE
(cuando se u tiliza un enfoque m anual) y h acer corres
las tareas humanasse definen y se clasifican como parte
ponder esta tareas con un conjunto de tareas sim ilar (aun
del anólisis de las tareas. Para retinarlas tareas se utiliza
que no necesariam ente idénticas) que se im plem entan en
un procesode elaboración. Deforma alternativa,
el contexto de la interfaz de usuario. Efe form a alternati se Identificany se retinan los objetos y las acciones.
va, el in genieropuede estudiar la especificación ex isten
te p ara la solución b asad a en com pu tad o ra y extraer un L as subtareas (1)-(7) pueden recib ir m ás refinamien
con ju n to d e tareas que se ajusten al m odelo de usuario, al to. L as subtareas (1)-(6) se llevarán a cabo m ediante la
m odelo de diseño y a la percepción del sistema. m anipulación de inform ación y m ediante la realización
Independientem ente del enfoque global utilizado para de acciones dentro de la interfaz de usuario. Por otro lado,
el análisis de tareas, el ingeniero d eberá en prim er lugar la subtarea (7) se podrá llevar a cabo autom áticam enteen
definirlas y clasificarlas. Ya se h a descrito anteriorm ente el softw are y dará com o resultado m uy poca interacción
que el enfoque es una elaboración paso a paso. P or ejem directa con el usuario. El m odelo de diseño de la interfaz
plo, supongam osque una com pañía pequeña quiere cons deberá adaptarse a cada una de estas tareas de form a con
tru ir un sistem a de d iseñ o asistido p o r com putadora secuente con el m odelo del usuario (el perfil de un dise
explícitam en tep ara diseñadores de interiores. A l obser ñ ador «típico» de interio res) y con la percepción del
v ar a un diseñador de interiores en su trabajo, el ingenie sistem a (lo que el diseñador de interiores espera de un sis
ro se da cuenta y notifica que el diseño interior se compone tem a autom atizado).
tM M k t Á .'M r i É m c '
U na v ez finalizado el análisis de tareas, quedan defini 2. H acer corresponder cada objetivo/intención con una
das detalladam ente todas (u objetos y acciones) las que secuencia de acciones específicas
requiere el usuario final y com ienza la actividad del dise 3 _ E specificar la secuencia de acciones de tareas y sub
ño de la interfaz. M ediante el enfoque que se m u estra a tareas, tam bién llam ado escenario del usuario, de la
continuación se p o d rán llevar a cabo los prim eros pasos m an era en que se ejecutarán a nivel de la interfaz.
del diseño de la interfaz [N O R86]: 4. Indicar el estad o del sistem a, esto es, el aspecto que
1. E stablecer los objetivo? e intenciones p ara cada tarea. tien e la in te rfaz cu an d o se está llev an d o a cabo el
escenario del usuario.
■ R ¿Cuáles son los pasos 5. D efinir los m ecanism o de control, esto es, los obje
W que hay que seguir para Nevar tos y acciones disponibles para que el usuario altere
a cabo el diseño d e la iaterfaz? el estad o del sistem a.
www.FreeLibros.org
4 En m uchos casos las actividades descritas en esta sección son lle 5 Entre los objetivos se pueden incluir la consideración de la utilidad de
vadas a cabo por un ingeniero del softw are. Esperem os que el indi las tareas, la efectividad al llevara cabo el objetivo comercial primor
viduo tenga experiencia en ingeniería hum ana y en el diseño de la dial, el grado de rapidez de aprendizaje de las tareas y el grado de satis
interfaz de usuario. facción de los usuarios con la implernentación final de la tarea.
264
CAPÍTULO 15 D IS E ÑO DE LA INTERFAZ DE U S U A R I O
6. M o s tra r la fo rm a e n q u e lo s m e c a n is m o s d e c o n tro l pantalla. A l ig u a l q u e o tras a c tiv id a d e s d e d is e ñ o d e la

afectan al e s ta d o d e l sistem a. in te rfa z , e l fo rm a to d e p a n ta lla es u n p ro c e s o in te ra c tiv o
7. In d ic a r la fo r m a e n que e l u s u a rio in te rp re ta e l estado e n d o n d e se lle v a a c ab o e l d is e ñ o g rá fic o y la c o lo c a c ió n
del sistem a a p a rtir d e la in fo r m a c ió n p ro p o rc io n a d a de los ic o n o s , la d e fin ic ió n d e l te x to d e s c rip tiv o e n p a n
gracias a la in te rfa z . ta lla , la e s p e c ific a c ió n y títu lo s p a ra las v e n ta n a s , y la
d e fin ic ió n de los e le m en to s d e l m e n ú p rin c ip a le s y sec u n
A u n q u e e l d is e ñ a d o r de la in te rfa z se g u ía p o r las
d ario s. S i u n a m e tá fo ra c o n e l m u n d o re a l es a d e c u a d a
reglas de o ro ab o rd a d as e n la S e c c ió n 15.1, d e b e rá c o n
p a ra la a p lic a c ió n , q u e d a e s p e c ific a d a e n ese m o m e n to y
siderar la fo rm a e n q u e se v a a im p le m e n ta r la in te rfa z ,
e l fo rm a to se o rg a n iz a p a ra c o m p le m e n ta r esa m e tá fo ra .
el entorn o (p o r e je m p lo , te c n o lo g ía de p a n ta lla , s is te m a
P a ra m o s tra r la b re v e ilu s tra c ió n d e lo s pasos d e d is e
operativo, h e rra m ie n ta s d e d e s a rro llo ) q u e se v a a u t i-
ñ o d e sc rito s a n te rio rm e n te , to m e m o s e n c o n s id e ra c ió n
liza ry otros e le m e n to s de la a p lic a c ió n que «se e n c u e n
u n e s c e n a rio d e u s u a rio p a ra la v e rs ió n a v a n z a d a d e l
tren p o r d etrás» d e la in te rfa z .
s is te m a //o g c /rS c g ? /ro (d e s c rito e n c a p ítu lo s a n te rio re s ).
E n la v e rs ió n a v a n z a d a , se p u e d e a c c e d e r a H ogarSe
15.4.1. D e fin ic ió n d e o b je to s y a c c io n e s guro m e d ia n te m ó d e m o In te m e t. U n a a p lic a c ió n p a ra
d e l a in te rfa z P C p e rm ite q u e u n p ro p ie ta rio c o m p ru e b e e l e s ta d o d e
la casa d e sd e u n a lo c a liz a c ió n re m o ta , r e in ic ia liz a r la
Un paso im p o rta n te e n e l d is e ñ o d e la in te rfa z es la d e fi
c o n fig u ra c ió n HogarSeguro, a c tiv a r y d e s a c tiv a r e l sis
nición de lo s o b je to s y a c c io n e s q u e se v a n a a p lic a r.
te m a , (e m p le a n d o u n a o p c ió n d e v íd e o c o n u n c o ste
Para lle v a r a c a b o esta d e fin ic ió n , e l e s c e n a rio d e l u s u a
e x tra 6), y s u p e rv is a r v is u a lm e n te las h a b ita c io n e s d e n
rio se a n a liz a s in tá c tic a m e n te d e m a n e ra m u y s im ila r a
tro d e la casa. A c o n tin u a c ió n , se m u e s tra u n e s c e n a rio
como se a n a liz a b a n las n a rra tiv a s d e p ro c e s a m ie n to d e l
p r e lim in a r d e u s u a rio p a ra la in te rfa z :
C apítulo 12. E s to es, se e sc rib e la d e s c rip c ió n d e l e s c e
nario de un u s u a rio . L o s s u stan tiv o s (o b je to s ) y lo s v e r
bos (a cc io n e s) se a ís la n p a ra c re a r u n a lis ta d e o b je to s
la o a m if f iB E E i
f l escena*» descrito aquí es ánrfer a te casos
y de acciones.
de estudio descritos en el Capítulo 11.
En la Sección 12.6.2 se puede encontrar un estudio Escenario. E l pro p ietario de la casa desea a cced er al sis
completa del análisissemántico gramatical. tem a H o g a rS eg u ro instalado en su casa. M ed ian te el siste
m a o perativo de un PC rem oto (por ejem p lo , un portátil que
el pro p ietario se lleve al trab ajo o de v ia je ), el p ropietario
U n a v e z que se h a n d e fin id o y e la b o ra d o ite r a tiv a d eterm in a el estado del sistem a de alarm a, arm a o d esarm a
mente ta n to lo s o b je to s c o m o las a c c io n es , se e s ta b le el sistem a, reconfigura las zonas de seguridad y o b serv a las
cen categorías p o r tip o s . L o s o b je to s se id e n tific a n c o m o diferentes habitaciones de la casa m ediante la p rein stalació n
objetos o rig e n , d e s tin o y d e a p lic a c ió n . U n objeto o ri de una cám ara de vídeo.
gen (p o r e je m p lo , un ic o n o de in fo r m e s ) se a rra s tra y se Para acceder a H ogarSeguro desde una localización rem o
coloca sobre o tro objeto destino (p o r e je m p lo , u n ic o n o ta, el propietario proporciona un identificador y una contrase
de im p re s o ra ). L a im p lic a c ió n de e sta a c c ió n es c re a r ña. C on esto se definen los niveles d e acceso (p o r ejem plo,
todos los usuarios puede que no tengan la capacidad d e recon-
una c o p ia im p re s a d e u n in fo r m e . U n objeto de aplica
figurar el sistem a) y se proporciona seguridad. U na vez vali
ción re p re s e n ta lo s d a to s e s p e c ífic o s d e la a p lic a c ió n dados, el usuario (con los privilegios para el acceso) com prueba
que no se m a n ip u la n d ire c ta m e n te c o m o p a rte d e la in te el estado del sistem a,y cam bia el estado arm ando y desarm ando
racción de la p a n ta lla . P o r e je m p lo , u n a lis ta d e c o rre o H o g a rS eg u ro . E l usuario reconfigura el sistem a visualizando
postal se u t iliz a p a ra a lm a c e n a r lo s n o m b re s q u e se u t i todas las zonas configuradas actualm ente,m odificando las zonas
lizarán p a ra u n c o rre o p o s ta l. E s ta lis ta se p u e d e o rd e cuando se requiera. E l usuario observa el interior de la casa
m ediante cám aras de vídeo estratégicam enteubicadas. E l usua
nar, fu s io n a r o p u rg a r (a c c io n e s basadas e n m e n ú ) p e ro
rio puede utilizar las cám aras para recorrer todo el interior y
no se pu e d e a rra s tra r y c o lo c a r m e d ia n te la in te ra c c ió n
am pliarlopara ofrecer diferentes visiones del interior de la casa.
del usuario.
Tareas del propietario:

¿Qué es el formato
• a c ce d er al sistem a H ogarSeguro;
de pantalla y cómo se aplica?
• in tro d u cir un ID y una contraseña para perm itir un acceso
rem oto;
U n a v e z que e l d ise ñ a d o r q u e d a satisfecho c o n la d e fi
nición de to dos lo s o b je to s y a c c io n es im p o rta n te s (p a ra • com probar el estado del sistem a;
una ite ra c ió n d e d is e ñ o ), se lle v a a c a b o e l fo rm a to de • a c tiv a r o d e sa c tiva r el sistem a H ogarSeguro;
www.FreeLibros.org
6 La opción de vídeo posibilita al usuario c o lo c ar una c ám ara
de vídeo en lugares clave por la casa y exam inar la salida desde una
localizaciónrem ota. ¿E! Gran Herm ano?
265
• visualizar el p la n o de la casa y las localizaciones de los sen s e le c c io n a r u n a v is ió n d e s d e o tr a c á m a ra , e l u su ario

sores; s im p le m e n te a rra s tra y c o lo c a e l ic o n o d e localización
• v isu a liza rzo n a s e n e l plano de la casa; de cám ara d e n tro d e l ic o n o cám ara d e l á n g u lo supe
• cam biar z o n a s e n el plano de la casa; r io r iz q u ie rd o d e la p a n ta lla .
• visualizar las lo ca liz ac io n es de las c á m a ra s de vídeo en el E s ta m u e s tra d e e s b o z o d e fo r m a t o te n d r ía que ir
plano de la casa; c o m p le m e n ta d o m e d ia n te u n a a m p lia c ió n d e to d o s los
• seleccio n a r la c á m a r a de vídeo p ara ten e r visión; e le m e n to s d e l m e n ú d e n tro de la b a rra d e m e n ú , indi
• o b se rv a r la s im á g e n e s de vídeo (c u atro e n c u a d re s p o r c a n d o las a cc io n es d is p o n ib le s p a ra e l (e s ta d o )modode
segundo); supervisión del video. D u ra n te e l d is e ñ o d e la interfaz
• recorrer y a m p lia r las habitaciones c o n la c á m a r a de vídeo. se d e b e ría c re a r u n c o n ju n to c o m p le to d e e sbozos para
to d as y c a d a u n a d e las ta re as d e l p ro p ie ta rio descritas
L o s o b je to s ( n e g r it a ) y la s a c c io n e s (c u r s iv a ) se
e n e l e s c e n a rio d e l u s u a rio .
e x tr a e n d e la lis ta d e ta re a s d e l p r o p ie ta r io d e s c rita s
a n te rio rm e n te . L a m a y o r ía d e lo s o b je to s a n te rio re s son
o b je to s d e a p lic a c io n e s . S in e m b a rg o la lo c a liz a c ió n de 15.4.2. P r o b le m a s d e l d is e ñ o
la c á m a ra d e v íd e o (u n o b je to o rig e n ) se a rra s tra y se A m e d id a q u e la in te rfa z d e u s u a rio v a e v o lu c io n a n d o
c o lo c a sobre la c á m a ra d e v íd e o (u n o b je to d e s tin o ) p a ra casi s ie m p re a flo ra n c u a tro te m a s c o m u n e s d e diseño:
c re a r u n a im a g e n d e v íd e o (u n a v e n ta n a c o n la p re s e n e l tie m p o d e re sp u es ta d e l s is te m a, lo s s e rv ic io s de ayu
ta c ió n d e u n v íd e o ). d a a l u s u a rio , la m a n ip u la c ió n d e in fo r m a c ió n de erro
P a ra la s u p e rv is ió n d e l v íd e o se c re a u n e s b o z o d e l re s y e l e tiq u e ta d o d e ó rd e n e s . D e s g ra c ia d a m e n te ,
fo rm a to d e p a n ta lla (F ig . 1 5 . 2 ) . P a ra in v o c a r la im a g e n m u c h o s d ise ñ a d o re s n o a b o rd a n estos te m a s d e n tro del
d e v íd e o , se s e le c c io n a u n ic o n o d e lo c a liz a c ió n d e pro ceso d e d is e ñ o h asta que es re la tiv a m e n te ta rd e (algu
c á m a r a d e v íd eo C , u b ic a d o e n e l p la n o d e la c a sa que nas v e c es n o se sie n te la a p a ric ió n d e u n e rro r h asta que
se v is u a liz a e n la v e n ta n a d e s u p e rv is ió n . E n este caso, se d is p o n e d e l p ro to tip o o p e ra tiv o ). E l re s u lta d o suele
la lo c a liz a c ió n de u n a c á m a ra e n la s ala d e e sta r (S E ), s er u n a ite ra c ió n in n e c e s a ria , d e m o ra s d e p ro y e c to y
se a rras tra y se c o lo c a sobre e l ic o n o d e v íd e o d e c á m a fru s tra c ió n d e l u s u a rio . E s in fin ita m e n te m e jo r e sta b le
ra e n la p a rte s u p e rio r iz q u ie rd a d e la p a n ta lla . E n to n c e r e l te m a d e d is e ñ o q u e se v a y a a te n e r e n c u en ta al
ces, m e d ia n te la v is u a liz a c ió n d e l re c o r rid o re a liz a d o in ic ia r e l d is e ñ o d e l s o ftw a re , es d e c ir c u a n d o lo s cam
p o r e l v íd e o d e sd e la c á m a ra lo c a liz a d a e n la s a la d e b io s son fá c ile s y lo s costes m á s re d u c id o s .
e sta r (S E ) , a p are ce la v e n ta n a d e im a g e n d e v íd eo . L a s P a ra m u c h a s a p lic a c io n e s in te ra c tiv a s e l tie m p o de
d ia p o s itiv a s d e c o n tro l d e l r e c o r r id o p o r las h a b ita c io re sp u es ta d e l s is te m a es e l p rin c ip a l m o tiv o de queja.
nes y d e las a m p lia c io n e s se u tiliz a n p a ra c o n tro la r la E n g e n e ra l, e l tie m p o d e re sp u es ta d e l s is te m a se m ide
a m p lit u d y la d ir e c c ió n d e la im a g e n d e v íd e o . P a r a desde e l p u n to d e v is ta q u e e l u s u a rio re a liz a la acción
Acceso C onfigurar Estado del sistem a V er S upervisión
Hogar Seguro
Cámara
p im á g e n | d e v i d e o _ .- R j
5P?
www.FreeLibros.org
FIG URA 1 5 .2 . Form ato preliminar de pantalla.
266
CAPÍTULO 15 D IS E Ñ O DE LA INTERFAZ DE U S U A R I O
cb control (por ejem plo, p u lsar la tecla intro o pu lsar el • ¿Se n e ce sita rá d isp o n er de to d as las fu n cio n es del
botón del ratón) h asta que el softw are responde con la sistem a en cualquier m om ento durante la interacción
salida o acción deseada. del sistem a? O pciones: ayuda solo para un subcon-
El tiem po de resp u esta del sistem a tiene dos carac ju n to de todas las funciones y acciones; ayuda para
terísticas im portantes: la d uración y la variabilidad. Si todas las funciones.
la duración de la re sp u e sta del sistem a es d em asiado • ¿De qué fo rm a solicitará ayuda el usuario? O p c io
larga, es inevitable o btener co m o resultado la fru stra nes: un m enú de ayuda; una tecla de fu n ció n e sp e
ción y el estrés del usuario. Sin em bargo, si la interfaz cial; una orden de A Y U D A .
va m arcando el ritm o del u su a rio u n a d u rac ió n breve
• ¿Cóm o se representará la ayuda? O pciones: una v e n
del tiem po de resp u esta puede ser tam b ién perjudicial.
tana separada; una referencia a un docum ento im preso
Un tiem po de resp u esta rápido puede obligar a que el
(no es lo ideal); una sugerencia de una o dos líneas
usuario se precipite y com eta errores.
que surge en una localización fija en la pantalla.
• ¿C óm o regresará el usuario a la interacción norm al?
^ O N S E J o j^ jf Opciones: un botón de reto m o visualizado en la p a n
talla; una tecla de función o una secuencia de control.
Si no se puede evitar unorespuesto variable, asegúrese
de proporcionar alguno indicación visual del progreso • ¿Cóm o se estructurará la inform ación sobre la panta
para que el usuario sepa lo queestó ocurriendo. lla? Opciones: una estructura«plana» donde el acceso
a la inform ación se realiza m ediante una contraseña;
La variabilidad se refiere a la d esviación del tiem po u n ajerarq u ía estratificada de inform ación que va pro
cb respuesta prom edio, y en m uchos aspectos es la carac p o rcio n a n d o m ás datos a m edida que el u su a rio va
terística m á s im portante del tiem po de respuesta. U na entrando por la estru ctu rad a utilización de hipertexto.
variabilidad b aja posib ilita al usuario establecer un rit
C uando ha salido algo m al, los m ensajes de e rro r y
mo de interacción, aunque el tiem po de respuesta sea
las sugerencias son « m alas noticias» para los usuarios
relativam ente largo. P or ejem plo, es p referible obtener
de sistem as interactivos. E n el p eo r de los casos, estos
una segundarespuesta de u n a ord en a una respuesta que
m ensajes im parten inform ación sin u tilizar o engañosa
varíe de 0,1 a 2,5 segundos. E l usuario siem pre estará
y sirven solo para increm entar la frustración del u su a
desconcertado y preguntándose si ha ocurrido algo «d ife
rio. E xisten m uy pocos usuarios que puedan decir que
rente» detrás de la escena.
no se han encontrado con un erro r del tipo:
Casi todos lo s usuarios de un sistem a interactivo basa
do encom putadorarequierenayuda,ahoray siem pre.Los FALLO GRAVE DEL S IS T E M A - - 14 A
dos tipos de funciones de ayuda m ás com unes son: inte
E n algún lu g a r d eb e e x istir una ex p lica ció n del erro r
gradas y com plem entarias(añadibles). [RUB88], Se dise
14A , o sino ¿por qué habrá incluido el diseñador esta
ña u na/u n ció n de a yu d a in teg ra d a d en tro del m ism o
identificación? A pesar de esto, el m ensaje de error no
software desde el principio. Suele ser sensible al contex
proporciona una indicación verdadera de lo que va m al
to, lo que posibilita al usuario seleccionar entre los tem as
o d e donde m irar p ara o b ten er m ás in form ación. U n
que sean relevantes para las acciones que esté llevando a
m en saje d e e rro r co m o el que se ha presentado a n te
cabo en ese m om ento. O bviam enteesto reduce el tiem po
riorm ente no hace nada p o r a liv ia rla ansiedad del usu a
que requiere para o btener ayuda, e increm enta su «fam i
rio o p o r ayudar a solucionar el problem a.
liaridad» con la interfaz. Una fu n ció n de ayuda com ple
E n general, todos los m ensajes de error o sugeren
mentaria se añade al softw are u n a v ez co n stru id o el
cias de un sistem a interactivo deberán ten er las carac
sistema. En m uchos aspectos es m uy sim ilar a un m anual
terísticas siguientes:
de usuario en línea con una capacid ad lim itada de co n
sulta. Es posible que el usuario tenga que buscar en una • El m ensaj e deberá describir el problem a en una j erga
lista de m iles de tem as para encontrar la guía adecuada, que el usuario pueda entender.
entrando norm alm ente en las ayudas incorrectas y reci • E l m ensaje deberá proporcionar consejos c o n stru c
biendo m ucha inform ación irrelevante. N o hay ninguna tivos para recuperarse de un error.
duda de que es preferible el enfoque de funciones de ayu - E l m en saje deb erá in d ica r c u a lq u ier co n secu en cia
da integradas al enfoque de funciones com plem entarias. negativa del error (por ejem plo, los archivos de datos
posiblem ente deteriorados) para que el usuario pueda
•
¿Cuáles son los temas de diseño com probar y g arantizar que no hay ninguno (y co rre
que deberán tenerse en cuenta girlos si existen).
en la construcción de las funciones
de ayuda?
www.FreeLibros.org
Cuando se va a con sid erar u n servicio de ayuda hay
Duplique el esfuerzo y f e palabras al solucionar errores
una serie de tem as de d ise ñ o q u e d eb erán a b o rd a rse
cuandopiense que necesito uno función de ayudo y,
[RUBSS]: de esto forma, es probable que consigo un buen resultado.
267
I N GE NI E RÍ A DEL S O F TW A RE . UN E N F O Q U E P R A C T I C O
■ El m ensaje d eb erá ir seguido p o r u n a clave audible softw are del sistem a, y se utilizaban norm alm ente para
o visual. E sto es, p ara a c o m p añ ar la v isu a liz ac ió n aplicaciones de to d o tipo. A ctualm ente, la utilización
del m ensaje se p o d ría g enerar un p itido, o aparecer de in terfaces o rien tad as a v en tan a s en donde solo se
m o m en tán eam en te u n a luz d estellean te o v isu a li señala y se selecciona, h a reducido el hecho de depen
zarse en un colo r que se pued a reco n o cer fácilm ente der de órdenes tecleadas, aunque m uchos usuarios avan
com o el « co lo r del error». za d o s sig u e n p re firie n d o el m o d o de interacción
« El m ensaje no d eberá tener «sentencias». E sto es, las orientado a órdenes. C u an d o se proporcionan Órdenes
palabras del m ensaje nunca deberán culpar al usuario. escritas com o m odo de interacción surge una serie de
tem as de diseño:
D ado que a nadie le g u sta realm ente tener m alas noti
« ¿Se corresponden todas las opciones del m enú con
cias, a m uy p ocos u suarios les gustará ten er un m ensaje
su órdenes?
de e rro r in dependientem ente del diseño. N o ob stante,
« ¿Q ué form as adquirirán las órdenes? O pciones: una
u n a filosofía eficaz de m ensajes de e rro r puede ayudar
m u ch o a la h o ra de m e jo ra r la calid a d de u n sistem a secuencia de control (p o r ejem p lo , alt-P ); teclas de
interactivo y red u cirá significativam ente la frustración función; u n a p alab ra tecleada.
del usuario cu an d o aparecen problem as. . ¿Será difícil aprender y recordar las órdenes? ¿Qué
A n teriorm ente las órdenes escritas o tecleadas eran se puede hacer si se olvida u n a orden?
el m o d o de interacción m ás co m ú n en tre el usuario y el . ¿Podrá personalizar o abreviar el usuario las órdenes?
15 .5 HERRAMIENTAS DE IMPLEMENTACIÓ N
U n a v ez c re a d o el m o d elo de d ise ñ o , se im p lem en ta • proporcionar una respuesta (por ejem plo,un eco auto
co m o un prototipo’, que los usuarios h an ex am inado m ático de la entrada)
(aq u e llo s que adaptan el m odelo del u su a rio d escrito • p ro p o rc io n ar ayu d a e in d icacio n es de solicitud de
anteriorm ente), y que se h a b asado en los com entarios entrada de órdenes;
de los usuarios.
• m a n ip u la r v en tan a s y cam pos, d esp lazarse por las
P ara acoplar este enfoque de diseño iterativo se ha
ventanas;
desarrollado u n a clase extensa de herram ientas diseño
de interfaz y de g eneración de prototipos. E stas herra • establecer conexiones entre el softw are de la aplica
m ientas así llam ad as,/u eg o de herram ientas de la inter ción y la interfaz;
f a z de usuario o sistem as de desarrollo de la interfaz de • aislar la aplicación de las funciones de gestión de la
usuario ( S D I U ) ,proporcio n an com ponentes u objetos interfaz;
que facilitan la creación de ventanas, ruenús, interacción • perm itir que el usuario personalice la interfaz.
de dispositivos, m ensajes de error, Órdenes y m uchos
otros elem entos de un entorno interactivo.
M ediante los com ponentes de softw are p reestab le
cidos que se p u ed en u tilizar p ara crear u n a interfaz de
usu ario , un S D IU p ro p o rc io n a rá los m ecan ism o s
[M Y E89] para:
• g e stio n a r los d isp o sitiv o s de salid a (tales co m o el
Diseño de la Interfaz de usuario
rató n o el teclado);
• v alid ar la entrad a del usuario; E stas funciones se pueden im plem entar m ediante un
• m an ip u lar los errores y v isu alizar m ensajes de error; enfoque gráfico o basado en lenguajes.
U na vez que se h a creado un prototipo de interfaz de usua táneas hasta un estudio form alm ente diseñado que utili
rio, deberá sufrir una evaluación para determ inar si cu m zará m étodos estadísticos para la evaluación de cuestio
ple las n ecesidades del usuario. L a ev aluación podrá narios cum plim entadospor un grupo de usuarios finales.
abarcar un espectro de form alidad: desde «pruebas» infor El ciclo de evaluación de la interfaz adquiere forma
m ales en donde el usuario proporciona respuestas espon en la Figura 15.3. U na vez finalizado el m odelo de dise
www.FreeLibros.org
1 Debe destacarse que en algunos casos (por ejemplo, los indicadores
del panel de los aviones), el primer paso debena ser simular la inter
faz en un dispositivo en vez de utilizar el hardw are del indicador.
268
C A PÍT U L O 15 D I S E Ñ O DE LA INTERFAZ DE U S U A RI O
ño, se crea un prototipo de p rim er nivel. E ste prototipo 1 . L a d u rac ió n y la co m p lejid a d de la esp e cific ació n
es evaluado p o r el usuario, que es quien proporcionará que se h ay a escrito del sistem a y de su interfaz p ro
al diseñador los co m entarios directos sobre la eficacia porcionan u n a indicación de la cantidad de aprendi
de la interfaz. A dem ás, si se u tilizan técnicas form ales zaje que requieren los usuarios del sistem a.
de evaluación (por ejem plo, cuestio n ario s,hojas de ev a 2. La cantidad de tareas especificadasy la cantidad m edia
luación), es posible que el d iseñador extraiga inform a de acciones p o r tarea proporcionan una indicacióndel
ción de estos datos (por ejem plo, el 80 p o r 100 de los tiem po y de la eficacia global del sistema.
usuarios no m ostró afinidad con el m ecanism o para gra
3. L a cantidad de acciones, tareas y estados de sistem as
bar archivos de datos). L as m odificaciones que se re a
indicados con el m odelo de diseño indican la carga de
licen sobre el diseño se basarán en la entrad a del usuario
m em oria que tienen los usuarios del sistema.
y entonces se creará el p rototipo de segundo nivel. El
ciclo de ev aluación continúa h asta que y a no sean n ec e 4. El estilo de la interfaz, las funciones de ayu d a y el
sarias m ás m odificaciones del diseño de la interfaz. protocolo de solución de erro res proporcionan una
indicación general de la com plejidad de la interfaz
y el grado de aceptación p o r parte del usuario.
U n a vez construido el prim er prototipo, el diseñador
puede recopilar u n a diversidad de datos cualitativos y
& escribir delante que pueda
cualificativos que ayudarán a ev a lu ar la interfaz. P ara
y in 'a p #9fft¡2 en donde la mente
recopilar los datos cualitativos, se pueden distribuircues-
■ H H p j , : -. r can el universo y los
tionarios a los usuarios del prototipo. Las preguntas p u e
o fados.
d en ser (1) del tip o de re sp u e sta si/no; (2) re sp u e sta
num érica; (3 ) respuesta con escala de valoración (sub
je tiv a ), o (4) re sp u e sta p o r p o rc en taje s (subjetiva). A
El enfoque de g e n e ra c ió n de p ro to tip o s es efic az , continuación se m uestran unos ejem plos:
ahora bien ¿es posible evaluar la calidad de la interfaz 1. ¿E ran c la ro s lo s ic o n o s? E n c aso n e g a tiv o , ¿Q ué
de usuario antes de construir un p rototipo? Si los p ro iconos no eran claros?
blemas se p u ed en descu b rir y solucionar rápidam ente,
2. ¿Eran fáciles de recordar y de invocar las acciones?
el núm ero de b ucles en el ciclo de ev aluación se re d u
cirá y el tiem po de desarrollo se acortará. Si se h a crea 3. ¿C uántas acciones diferentes ha utilizado?
do un m odelo de d ise ñ o de la in te rfa z , d u ra n te las 4 . ¿R esultaron fáciles de ap renderlas operaciones bási
primeras re v isio n e s del d iseñ o se p o d rá n ap licar una cas del sistem a? (v a lo rac ió n d e l a 5)
serie de criterios [M O R 81] de evaluación: 5. E n com paración con otras interfaces que haya u tili
zado, ¿C óm o evaluaría ésta?
entre el 1 % m ejores, 10% m ejores, 25% m ejores, 50%
Diseño m ejores, 5 0 % inferiores.
preliminar
Interfaz de usuario.
Si se desea obtener datos cuantitativos, se puede lle

var a cabo una form a de análisis para el estudio del tiempo.
Los usuarios son observados durante la interacción;y para
tener una guía durante la m odificación de la interacción
se recopilan y utilizan datos tales como: grupo de tareas
finalizadas co rrectam en te p o r e n cim a del p erío d o de
tiem po estándar; frecuencia de acciones; secu en cia de
acciones; tiem po transcurrido «m irando» la pantalla;
núm ero y tipo de errores, y tiem po de solución de erro
res; tiem po necesario para utilizar la ayuda; y cantidad de
referencias de ayuda p o r período de tiem po estándar.
www.FreeLibros.org
U n estudio com pleto de los m étodos de ev aluación de
está finalizada
la interfaz de usuario queda fuera del ám bito de este libro.
FIGURA 1 5 .3 . El ciclo de evaluación de diseño de la interfaz. Para m ás inform ación, véase [LEA88] y [M AN97],
269
I N GEN IE RÍ A DEL SOF TW ARE . UN E N F O Q U E P R A C T I C O
S B H H I
¡ n u m
Se p u e d e a rg u m e n ta rq u e la in te rfa z de u s u a rio es e l e le U n a v e z q u e se h a n d e fin id o las ta re as , lo s escena

m e n to m ás im p o rta n te d e u n s is te m a o p ro d u c to b a s a rio s d e l u s u a rio se c re a n y a n a liz a n p a ra d e fin ir un con
d o e n c o m p u ta d o ra . S i la in te rfa z tie n e u n d is e ñ o p o b re , ju n t o de o b je to s y a c c io n es d e la in te rfa z . E s to es lo que
la c a p a c id a d q u e tie n e e l u s u a rio d e a p ro v e c h a rs e d e la p ro p o rc io n a la base p a ra la c re a c ió n d e l fo rm a to de la
p o te n c ia d e p ro c e s o d e u n a a p lic a c ió n se p u e d e d ific u l p a n ta lla , e l c u a l re p re s e n ta e l d is e ñ o g rá fic o y la colo
tar g ra v e m e n te . E n e fec to , u n a in te rfa z d é b il p u e d e lle v a r c a c ió n d e ic o n o s , la d e fin ic ió n d e u n te x to descriptivo
a l fra c a s o d e u n a a p lic a c ió n c o n u n a im p le m e n ta c ió n e n p a n ta lla , la e s p e c ific a c ió n y titu la c ió ri de ventanasy
s ó lid a y u n b u e n d iseñ o . la e s p e c ific a c ió n d e lo s e le m e n to s im p o rta n te s y secun
E x is te n tres p rin c ip io s im p o rta n te s q u e d irig e n e l d ise d a rio s d e l m e n ú . C u a n d o se v a a re fin a r u n m o d e lo de
ñ o de in te rfa c es de u s u ario eficaces: (1) p o n e r e l c o n tro l d is e ñ o p a ra e l s is te m a se tie n e n e n c o n s id e ra c ió n temas
e n m a n o s d e l u s u ario ; (2 ) re d u c ir la c arg a d e la m e m o ria d e d is e ñ o ta le s c o m o tie m p o de re sp u es ta , estructura de
d e l u s u ario ; ( 3 ) c o n s tru ir u n a in te rfa z consecuente. P a ra Ó rden es y a c c io n es , m a n ip u la c ió n d e e rro re s y funcio
lo g ra r que u n a in te rfa z se a te n g a a estos p rin c ip io s , se nes d e a y u d a . P a ra c o n s tru ir u n p ro to tip o que e l usua
d e b e rá d e s a rro lla ra n pro ceso de d is e ñ o o rg a n iz a d o . r io p u e d a e v a lu a r se u tiliz a n d iv e rs a s h e rra m ie n ta s de
E l d is e ñ o d e l a in t e r f a z d e u s u a rio c o m ie n z a c o n im p le m e n ta c ió n .
la id e n tific a c ió n d e lo s re q u is ito s d e l u s u a rio , d e las L a in te rfa z d e u s u a rio es la v e n ta n a d e l softw are. En
ta re a s y d e l e n to rn o . E l a n á lis is d e ta re a s es u n a a c ti m u c h o s casos, la in te rfa z m o d e la la p e rc e p c ió n que tie
v id a d d e d is e ñ o q u e d e fin e la s ta re a s y a c c io n e s d e l ne u n u s u a rio d e la c a lid a d d e l sistem a. S i la ventana se
u s u a rio e m p le a n d o u n e n fo q u e e la b o r a tiv o u o r ie n ta d ifu m in a , se o n d u la o se q u ie b ra , e l u s u a rio puede recha
d o a o b je to s . z a r u n s is te m a p o te n te b a sa d o e n c o m p u ta d o ra .
[DUM88] Dumas, J . S Designing User Interfaces f o r Soft puter Systems», Intl. Journal o f Man-Machine Studies,
ware, Prentice-Hall, 1988. vol. 15,pp. 3-50.
[LEA88] Lea, M., «Evaluating User Interfaces Designs», User [MYE89] Myers, B.A., «User Interface Tools: Introduction
Interface D esig n fo r Computer Systems, Halstead Press and Survey», IEEE Software, Lnero 1989, pp. 15-23.
(Wiley), 1988.
[NOR86] Norman, D.A., «Cognitive Engineering», UserCen-
[MAN97] Mandel, T„ The Elements o f User Interface Design, tered Systems Design, Lawrence Earlbaum Associates,
Wiley, 1997. Nueva Jersey, 1984.
[MON84] Monk, A. (ed), Fundamentáis o f Human-Compu- [RUB88] Rubin, T„ User Interface D esignfor CornputerSys-
ter Interaction, Academic Press, 1984. tems, Haldstead Press (Wiley), 1988.
[MOR81] Moran, T.P., «The CommandLanguage Grammar: [SHN87] Shneiderman, B., Designing the User Interface,
ARepresentationforthe User Interface o f InteractiveCom- Addison-Wesley, 1987.
NMM
• . •..i ..í a I li
15.1. Describa la peor interfaz con la que haya trabajado algu a. un sistema de autoedición
na vez y critíquela en relación con los conceptos que se han b, un sistema de diseño asistido por computadora
presentado en este capítulo. Describa la mejor interfaz con la
c. un sistema de diseño de interiores
que haya trabajado alguna vez y critíquela en relación con los
conceptos presentados en este capítulo. d,un sistema de matriculación automatizado para la uni
versidad
15.2. Desarrolle dos principios de diseño más que «den el
e. un sistema de gestión de biblioteca
control al usuario».
f. un sistema de votación basada en Internet para las elec
15.3. Desarrolle dos principios de diseño más que «reduzcan ciones públicas
la carga de memoria del usuario».
un sistema bancario en casa
15.4. Desarrolle dos principios de diseño más que «ayuden h. una aplicación interactiva asignada por su instructor
www.FreeLibros.org
a construir una interfaz consecuente».
Desarrolle un modelo de diseño, un modelo de usuario, una
15.5. Considere una de las aplicaciones interactivas siguien imagen de sistema y una percepción de sistema para cual
tes (o una aplicación asignada por su profesor): quiera de los sistemas anteriores.
270
C A P I T U L O 15 DISEÑO DE LA INTERFAZ DE U S U A R I O
156. Realice un análisis detallado de tareas para cualquiera el análisis de tareas que haya llevado a cabo desde el Proble
ds los sistemas que se relacionan en el Problema 15.5. Utili ma 15.6 al 15.8.
ce un enfoque elaborativo u orientado a objetos.
15.11. Proporcione unos cuantos ejemplos que muestren la
15.7. Como continuación al Problema 15.6, defina objetos y razón de que la variabilidad del tiempo de respuesta pueda
acciones para la aplicación que acaba de seleccionar. Identi considerarse un tema a tener en cuenta.
fique todos los tipos de objetos.
15.12. Desarrolleun enfoque que integre automáticamente los
15.8. Desarrolle un conjunto de formatos de pantalla con una mensajes de error y una función de ayuda al usuario. Esto es,
definición de los elementos del menú principales y secunda que el sistema reconozca automáticamente el tipo de error y
rios para el sistema que haya elegido en el Problema 15.5. proporcione una ventana de ayuda con sugerencias para corre
15.9. Desarrolle un conjunto de formatos de pantalla con una girlo. Realice un diseño de software razonablemente comple
definición de los elementos principales y secundarios del menú to que tenga en consideración estructuras de datos y algoritmos.
para el sistema estándar HogarSeguro de la Sección 15.4.1. 15.13. Desarrolle un cuestionariode evaluación de la interfaz
Puede optar por un enfoque diferente al mostrado en la Figu que contenga20 preguntas genéricas que se puedan aplicar a la
ra 15.2 sobre un formato de pantalla. mayoría de las interfaces. Haga que 10 compañeros de clase
15.10. Describa el enfoque utilizado en las funciones de ayu rellenen el cuestionario del sistemade interfaz que vayan a uti
da del usuario que haya utilizado para el modelo de diseño en lizar todos. Resuma los resultados e informe de ellos a la clase.
jñ&xsQxmiiñJLzm mz&júJLi H t v * ‘
Aunque el libro de Donald Norman no trata específicamente usuario ha sido editado por Carroll (Scenario-BasedDesign:
interfaces hombre-máquina, mucho de lo que su libro (The Envisioning Work and Technology in System Development,
Design o f Everyday Things, Reissue edition, Currency/Dou- Wiley, 1995). Horrocks (Constructing the User Interface with
bleday, 1990) tiene que decir sobre la psicología de un dise Statecharts, Addison-Wesley, 1998)ha desarrollado un méto
ño eficaz se aplicará a la interfaz de usuario. Es una lectura do formal para el diseño de interfaces de usuario que se basa
recomendada para todos los que sean serios a la hora de cons en el modelado del comportamiento basado en el estado.
truirun diseño de interfaz de alta calidad. La actividad de evaluación se centra en la usabilidad. Los
Durante la década pasada se han escrito docenas de libros libros de Rubin (HandbookofUsability Testing:How to Plan,
acerca del diseño de interfaces. Sin embargo, los libros de Design, and ConductEffective Tests, Wiley, 1994)y Nielson
Mandel [MAN97] y Shneiderman (Designing the User Inter- (Usability Inspection Methods, Wiley, 1994) aborda el tema
face: Strategiesfor Effective Human-Computer Interaction, de forma considerable y detallada.
3.a ed., Addison-Wesley, 1990) continúan proporcionando el La computadora Apple de Macintosh popularizó las inter
estudio más extenso acerca de la materia. Donnelly (In Your faces de usuario con diseños sólidos y fáciles de utilizar. El
Face: The Best o f Interactive Design, Rockport Publications, personal de Apple (MacintoshHuman Interface Guidelines,
1998), Fowler, Stanwicky Smith (GUI Design Handbook, Addison-Wesley, 1993)estudia la apariencia y utilización del
McGraw-Hill, 1998), Weinschenk, Jamar, y Yeo (GUIDesign ahora famoso Macintosh (y tan imitado). Uno de los prime
Essentials, Wiley, 1997), Galitz (TheEssential Guide to User ros libros que se han escrito acerca de la interfaz de Micro
Interface Design: An Introduction to GUI Design Principies soft Windows fue elaborado por el personal de Microsoft (The
and Techniques, Wiley, 1996), Mullet y Sano (Designing Windows G uidelinesfor Software Design: A n Application
VisualInterfuces: Communication Oriented Techniques,Pren- Design Guide, Microsoft Press. 1995).
ticeHall, 1995), y Cooper (A boutFace: The Essentials of En un libro de Murphy (FrontPanel: Designing Software
User Interface Design, IDG Books, 1995) han escrito estu f o r Embedded User Interfaces, R&D Books, 1998), el cual
dios que proporcionan las líneas generales y principios de puede resultar de gran interés para los diseñadores del pro
diseño adicionales así como las sugerencias para la elicita- ducto, se proporciona una guía detallada para el diseño de
ción de requisitos, modelado, implementación y comproba interfaces de sistemas empotrados y aborda los peligros inhe
ción del diseño. rentes en controles, en manipulación de maquinaria pesada e
El análisis y modelado de tareas s o n las actividades fun interfaces para sistemas médicos y de transporte. El diseño
damentales del diseño de la interfaz. Hackos y Redish (User de la interfaz para productos empotrados también se estudia
and TaskA nalysisfor Interface Design, Wiley, 1998) han en el libro de Garrett (AdvancedInstrumentation and Com
escrito un libro especializado en estos temas y proporcionan puter HO Design: Real-Time System Computer Interface Engi
un método detallado para abordar el análisis de tareas. Wood neering, IEEE, 1994).
(Userlnterface Design: Bridging the Gapfrom User Requi Una amplia variedad de fuentes de información sobre el
rements to Design, CRC Press, 1997) tiene en consideración diseño de la interfaz de usuario y de temas relacionados están
la actividad de análisis para interfaces y la transición hacia disponibles en Internet. Una lista actualizada de referencias
las tareas de diseño. Uno de los primeros libros que presen relevantes para la interfaz de usuario se puede encontrar en
tan el tema de los escenarios en el diseño de la interfaz de http://w ww.pressm an5.com
www.FreeLibros.org
C A P IT U L O
16 D IS E Ñ O A N IV E L DE C O M P O N E N T E S
L diseño a nivel de com ponentes, llam ado tam bién diseño pro ced im en ta l, tiene lugar d e s
E pués de h ab er establecido los diseños de datos, de interfaces y de arquitectura. El obje

tivo es convertir el m odelo de diseño en un softw are operacional. N o obstante, el nivel
de ab stracción del m odelo de diseño existente es relativam ente alto y el nivel de abstracción del
p ro g ram a operacional es bajo. E sta conversión puede ser un desafío, abriendo las puertas a la
introducción de errores sutiles que sean difíciles de detectar y corregir en etapas posteriores del
p roceso del softw are. E dsgar D ijkstra, uno de los principales valedores para la com prensión del
diseño, escribe lo siguiente [D IJ72]:
E l softw are p arece ser d iferente de m uchos otros pro d u cto s, donde co m o n orm a una calidad superior
im p lica un precio m ás elevado. A q u e llo s que q uieran realm en te un softw are fiable d escu b rirán q u e para
em p ezar deben en co n trar un m edio de ev itar la m ay o ría d e los errores y, co m o resu ltad o , el p roceso d e pro
g ram ació n será m enos costoso.. ..y los pro g ram ad o res que sean eficaces no d eb erán m alg a star su tiem po
d e purando los pro g ram as — no d eb erán co m eter errores desde el principio— .
A unque estas p alabras y a se escribieron hace m uchos años, h o y en d ía siguen siendo v e r

dad. C uando el m odelo de d iseño se convierte en código fuente, deberán' seguirse u n a serie de
principios que no solo lleven a cabo la conversión, sino que «no introduzcan errores desde el
principio».
VISTAZO RÁPIDO
¿Q u é es? E ste d ise ñ o c o n s is te e n c o n p o n e n te s re p re s e n ta e l so ftw a re q u e n otaciones gráficas, ta b u la re s y b a s a -

; vertir el d ise ñ o d e d a to s , in te rfa c e s y p e rm ite r e v is a r lo s d a to s d e l d is e ñ o d a s e n texto.
a rq u ite c tu ra e n u n softw are o p e rac io p a r a su c o rrecció n y c o n siste n c ia con ¿Cuál e s e l p ro d u c to o b te n id o ? El
nal. P a ra p o d e rlo lle v a r a c a b o , el la s re p re s e n ta c io n e s d e d ise ñ o a n te d ise ñ o p ro ced im en tal d e c a d a com po
d ise ñ o se d e b e r á r e p r e s e n ta r a u n riores (e sto e s , los d ise ñ o d e d a to s , d e n e n te re p re se n ta d o e n form a d e n o ta
nivel d e a b s tra c c ió n c e rc a n o a u n in terfaces y d e a rquitectura). C on e ste ción g ráfica, ta b u la r o b a s a d a e n texto
c ó d ig o . El d is e ñ o a n iv el d e co m p o d is e ñ o se p ro p o rc io n a u n m e d io d e e s el prim er producto d e trab ajo duran-*
n e n te s e s ta b le c e los d a to s algorítm i- e v a l u a r e l fu n c io n a m ie n to d e l a s te el d ise ñ o a nivel d e c om ponentes.
eos q u e s e re q u ie re n p a r a m a n ip u la r . e s tr u c tu r a s d e d a to s , in te r f a c e s y
¿Cómo p u e d o e s ta r se g u r e d e q u e
la s e s tru c tu ra s d e d a to s , e fe c tu a r la a lg o ritm o s.
lo h e h e c h o c o r r e c ta m e n te ?
c o m u n icació n e n tre los c o m p o n e n tes
¿C uáles so n lo s p a so s? L as re p re s e n M ed ian te u n a rev isió n e stru c tu ra d a y
del softw are por m edio d e la s in te rfa
ta c io n e s d e lo s d is e ñ o s d e d a to s. u n a inspección. El e x a m e n d e l d ise ñ o
ces. e im p le m e n ta r lo s a lg o ritm o s
a r q u ite c tu r a e in te rfa c e s fo rm a n la s e re a liz a p a r a d e te rm in a r si la s
a sig n a d o s a c a d a com ponente
b a s e d e l d ise ñ o a nivel d e c o m p o n e n e stru ctu ras d e l os datos, la s secuencias
¿Quién ]o h a c e ? Un ingeniero del soft tes. L a n a rra tiv a d e l p ro c e so d e c a d a d e l p roceso y la s cond icio n es ló g ic a s
w are. com ponente s e c onvierte e n u n m ode son co rrectas, y p a ra ver sip ro d u c irá n
¿Por q u é e s im p o r ta n te ? S e tie n e lo d e d ise ñ o p ro c e d im e n ta l e m p le a n la tra n s fo rm a c ió n d e d a to s y control
que ten e r la c a p a c id a d d e d e te rm in a r d o u n c o n ju n to d e c o n stru c c io n e s d e a d e c u a d o s q u e se a s ig n ó a l co m p o
si el p ro g ra m a f u n c io n a rá a n te s d e p ro g ra m a c ió n e s tr u c tu r a d a . P a ra n e n te d u ra n te lo s p rim eros p a so s d el
construirlo. El d ise ñ o a nivel d e com re p re se n ta r e s te d ise ñ o se u tilizan la s diseño.
M ediante la u tilización de un lenguaje de program ación es posible representar el diseñ o a

nivel de com ponentes. E n esencia, el program a se crea em pleando com o guía el m odelo de dise
ño. U n enfoque alternativo es representar el d iseño procedim ental m ediante la utilización de
alguna rep resen tación interm edia (por ejem plo, gráfica, tabular o b asad a en texto) que se p u e
da tran sfo rm ar fácilm ente en có digo fuente. Independientem ente del m ecanism o que se utilice
p ara rep resen tar el diseñ o a nivel de co m p o n en tes, la definición de las estru ctu ras de datos,
www.FreeLibros.org
interfaces y algoritm os deberán ajustarse a la diversidad de líneas generales del d iseño p ro ce
dim ental establecidas com o ayuda para evitar errores durante la evolución del m ism o diseño.
E n este capítulo, exam inarem os estas líneas generales de diseño.
273
IN GE NI E RÍ A DEL SOF TW AR E . UN E N F O Q U E P R A C T I C O
ÍStACIÓM aSÉtgCTBRÁD»
Los fundam entos del diseño a nivel de com ponentes na que los psicólogos denom inan fra g m e n ta c ió n (tro
proceden de la década de los años sesenta, y tom aron ceado o chunking). Para entender este proceso, consi
cuerpo con el trabajo de Edsgar Dijkstra y sus colabo deremos la m anera de leer esta página. Las letras no se
radores [BOH66, DIJ65, DIJ76], A finales de los sesen leen individualmente: m ás bien, se reconocen formasú
ta, D ijkstra y otros propusieron la utilización de un trozos de letras que forman palabras o frases. Las cons-;
conjunto de construcciones lógicas restringidas de las tracciones estructuradas son fragm entos lógicos que:
que poder formar cualquier programa. perm iten al lector reconocer elementos procedimenta*»'
les de un módulo en lugar de leer el diseño o el código;
línea a línea. La com prensión mejora cuando se encuen-t
tran patrones fácilmente reconocibles.
16.1.1. Notación gráfica del diseño

«Una imagen vale más que mil palabras», pero es impor
tante saber qué imagen y qué 1.000 palabras. Es incues
Las construcciones son secuenciales, condicionales tionable que herramientas gráficas, tales como diagramas
y repetitivas. La construcción secu en cia l implementa de flujo o diagram as de cajas, proporcionan formas grá
los pasos del proceso esenciales para la especificación ficas excelentes que representan datos procedimentales
de cualquier algoritmo. La condicional proporciona las fácilmente.
funciones para procesos seleccionados a partir de ima
condición lógica y la repetitiva proporciona los bucles.
Las tres construcciones son fundamentales para la p r o CLAVE
gra m a ció n estru ctu ra d a — una técnica im portante de la p rog ra maci ón estructu rado proporciona
diseño a nivel de componentes— . los modeloslógicos y útiles para el diseñador.
Las constraccionesestracturadassepropusieron para
restringir el diseño procedim ental del softw are a un El diagrama de flujo es una imagen bastante senci
núm ero reducido de operaciones predecibles. La m étri lla. M ediante la utilización de una caja se indica un paso
ca de la com plejidad (Capítulo 19) indica que la utili del proceso. Un rombo representa una condición lógi
zación de construcciones estructuradas reduce la ca y las flechas indican el flujo de control. La Figura
com plejidad del program a y, por tanto, mejora la capa 16.1 ilustra tres constraccionesestracúiradas. La secuen
cidad de comprender, com probar y mantener. La utili cia se representa com o dos cajas de procesamiento
zación de un número limitado de construcciones lógicas conectadas por una línea (flecha) de control. La condi
también contribuye a un proceso de com prensiónhum a- ción. llamada tam bién si-entonces-si no, se representa
Siguiente
tarea
Primera
tarea T Parte
Parte si-no Si-entonces
Secuencia Si entonces si-no Condición

(if-then-else)
Condición
del caso
Tarea
Parte de bucle
caso
Condición Tarea
Mientras- He b u c le ,
de bucle
hacer 0 u c e R e p e tir - h a s t a
( d o - w h il e ) ( r e p e a t - u n t il)
Condición
www.FreeLibros.org
Según-sea (seleción) Repetición de bucle
FIGURA 16.1. C o n s tru c c io n e s e n d ia g ra m a d e flujo. FIGURA 16.2. C o n stru c c io n e s a n id a d a s .
274
C A PÍT U L O 16 D ISEÑ O A NIVEL D E C O M P O N E N T E S
m ediante e l s ím b o lo d e l r o m b o d e d e c is ió n q u e , si es C h a p ín [ C F IA 7 4 ] , lo s d ia g ra m a s (ta m b ié n d e n o m in a
cierto, p ro v o c a e l p ro c e s a m ie n to d e la p a rte entonces, dos diagramas Nassi-Schneiderman, diagramas N -S o
y, si es fa ls o , in v o c a e l p ro c e s a m ie n to d e la p a rte si-no. diagramas Chapin) tie n e n las c a ra c te rís tic a s s ig u ie n
La re p etició n se re p re s e n ta m e d ia n te dos fo rm a s lig e tes: ( 1 ) d o m in io fu n c io n a l (es d e c ir, e l a lc a n c e d e u n a
ramente d ife re n te s . E l mientras-hacer p ru e b a u n a c o n re p e tic ió n o d e u n s i-e n to n c e s -s i-n o ) b ie n d e fin id o y
dición y e je c u ta u n a ta re a d e b u c le r e p e tid a m e n te c la ra m e n te v is ib le c o m o re p re s e n ta c ió n g rá fic a ; ( 2 ) la
siempre que la c o n d ic ió n siga s ie n d o v e rd a d . U n repe- tra n s fe re n c ia a rb itra ria de c o n tro l es im p o s ib le ; ( 3 ) e l
tir-hasta p rim e ro e je c u ta la ta re a de b u c le , después p ru e a lc an ce d e los datos lo ca les y /o g en erales se p u e d e d e te r
ba la c o n d ic ió n y re p ite la ta re a h asta q u e la c o n d ic ió n m in a r fá c ilm e n te y (4)l a re c u rs iv id a d es fá c il d e re p re
falla. L a c o n s tru c c ió n d e s e le c c ió n ( según_sea ) q u e se sentar.
muestra en la fig u ra re a lm e n te es u n a e x te n s ió n d e si-
entonces-si_no. U n p a rá m e tro se p ru e b a p o r d e cis io n es Primera tarea
sucesivas hasta q u e o c u rre u n a c o n d ic ió n v e rd a d e ra y
se e je c u ta d c a m in o d e p ro c e s a m ie n to aso ciad o .
Las c o n s tru c c io n e s e s tru c tu ra d a s p u e d e n a n id a rs e
Siguiente tarea
unas en otras c o m o m u e s tra la F ig u ra 16.2. E n esta F ig u Parte Parte
ra, un re p e tir-h a s ta fo rm a la p a rte th e n d e u n s i-e n to n - si_no entonces
c e s -s i-n o (m o s tra d a d é n tro d e la lín e a d is c o n tin u a
Siguiente tarea + 1
exterior). O tro if-th e n -e ls e fo rm a la p a rte s i-n o d e la p r i
m a n c o n d ic ió n . F in a lm e n te l a c o n d ic ió n p ro p ia m e n te
dicha se c o n v ie rte e n u n s eg u n d o b lo q u e e n u n a sec u en Secuencia Si-entonces-si-no
cia. A n id a n d o c o n s tru c c io n e s d e e sta m a n e ra , se p u e d e
desarrollar u n e s q u e m a ló g ic o c o m p le jo . Se d e b e ría des Condición de bucle
tacar que c u a lq u ie ra d e lo s b lo q u e s d e la F ig u r a 1 6 .2 Parte
podría h a ce r re fe re n c ia a o tro m ó d u lo , lo g ra n d o p o r ta n repetir hasta
( r e p e a t u n til)
to la e stratifica ció n p ro c e d im e n ta l que c o n lle v a la estruc
Parte
tura del p ro g ra m a . hacer m ientras
(d o w h ile )
ffc o N S E J O ^ . a
las construcciones de programación estructurado Condición de bucle
deberán facilitarla comprensióndeldiseño. Es correcto
soltarlos, si utlllzarlossln «saltarlas» da como resultado
Repetición
uno complejidad Innecesaria
E n g e n e ra l, la u tiliz a c ió n d o g m á tic a d e c o n s tru c c io XCóndición según=sea ( c a s e ) / '

nes estructuradas e x c lu s iv a m e n te p u e d e in tr o d u c ir d e
Valor Valor
fic ie n c ia c u a n d o se re q u ie re s a lir d e u n c o n ju n to d e
bucles anid ados o c o n d ic io n e s an id ad a s. L o que es m ás
im p o rta n te , u n a c o m p lic a c ió n a d ic io n a l d e to d a s las Parte Parte
pruebas ló g ic a s a lo la rg o d e l c a m in o d e s alid a p u e d e caso caso
oscurecer e l flu jo d e c o n tro l d e l s o ftw a re , a u m e n ta r la
posibilidad de e rro r y te n e r u n im p a c to n e g a tiv o e n su
lectura y m a n te n im ie n to . ¿ Q u é p o d e m o s h acer?
Selección
’E l d is e ñ a d o r d is p o n e d e dos o p c io n es : (1 ) la re p re
sentación p ro c e d im e n ta l se re d is e ñ a d e m a n e ra q u e la FIGURA 16.3. Construcciones de diagramas de capas.
«rama de escape» n o sea n e c e s a ria e n u n a p o s ic ió n a n i
dada en e l f lu jo d e c o n tr o l; o ( 2 ) la s c o n s tru c c io n e s L a re p re s e n ta c ió n g rá fic a d e c o n s tru c c io n e s e s tru c
estructuradas se s alte n d e u n a m a n e ra c o n tro la d a ; esto tu ra d a s m e d ia n te d ia g ra m a s d e c a ja s se ilu s t r a e n la
es, se d is e ñ a u n a ra m a re s trin g id a fu e ra d e l flu jo a n id a F ig u ra 1 6 .3 . E l e le m e n to fu n d a m e n ta l d e l d ia g ra m a es
do. L a o p c ió n 1 es o b v ia m e n te e l e n fo q u e id e a l, p e ro la la c aja. P a ra re p re s e n ta r u n a s ec u en c ia, se c o n e c ta n dos
opción 2 se p u e d e im p la n ta r s in ro m p e r e l e s p íritu d e la c a ja s seguidas. P a ra re p re s e n ta r u n s i-e n to n c e s -s i-n o ,
p ro g ra m a c ió n e s tru c tu ra d a [ K N U 7 5 ] , la c o n d ic ió n v a s eg u id a d e u n a c aja p a rte s i-e n to n c e s y
O tra h e rra m ie n ta de d is e ñ o g rá fic o , e l diagrama de u n a p a rte s i n o . L a re p e tic ió n se d ib u ja c o n u n lím it e
cajas, s u rg ió d e l d e se o de d e s a rro lla r u n a re p re s e n ta q u e e n c ie rra e l p ro c e s o (p a rte h a c e r-m ie n tra s o p a rte
www.FreeLibros.org
ción de d is e ñ o p ro c e d im e n ta l q u e n o p e rm itie ra la v io re p e tir-h a s ta ) q u e se v a a re p e tir. F in a lm e n te , la s e le c
lación de las c o n s tru c c io n e s e stru ctu ra d as . D e s a rro lla d a c ió n se re p re se n ta m e d ia n te la fo rm a g rá fic a m o s tra d a
p c r N a s s iy S c h n e id e r m a n [ N A S 7 3 ] y a m p lia d a p o r e n la p a rte in fe r io r d e la fig u ra .
275
En la Figura 16.4 se ilustra la organización de la tabla

de decisión y se divide en cuatro secciones. El cuadrante
Tontolos diagramas de flujo como los diagramas superior izquierdo contiene una lista de todas las con
de cojos yo no se utilizan tonto como antes. En general, diciones. El cuadrante inferior contiene una lista de todas
se deberían utilizar puro documentar o evaluar el diseño las acciones posibles basándose en combinacionesde
en casos específicos, m paro representar todo un sistema. las condiciones. Los cuadrantes de la derecha forman
una m atriz que indica las combinaciones de las condi
A l ig u a l q u e lo s d ia g ra m a s d e flu jo , u n d ia g ra m a d e
ciones y las correspondientes acciones que se han de
c a ja s e stá e s tra tific a d o e n m ú ltip le s p á g in a s a m e d id a
producir para cada com binación específica. Por tanto,
q u e se re fin a n lo s e le m e n to s d e p ro c e s a m ie n to de u n
cada colum na de la m atriz puede interpretarsecomo una
m ó d u lo . U n a « lla m a d a » a u n m ó d u lo s u b o rd in a d o se
regla de procesamiento.
p u e d e re p re s e n ta r m e d ia n te u n a c a ja c o n e l n o m b re d e l
Para desarrollar una tabla de decisión se aplican los
m ó d u lo e n c e rra d o e n u n ó v a lo .
siguientes pasos:
1. Hacer una lista de todas las acciones que pueden aso
16.1.2. Notación tabular de diseño
ciarse con un procesam iento específico (o módulo).
E n m u c h a s a p lic a c io n e s d e s o ftw a re , p u e d e ser n e ce sa
2. Hacer una lista de todas las condiciones (o decisio
rio u n m ó d u lo q u e e v a lú e u n a c o m b in a c ió n c o m p le ja
nes) durante la ejecución del procesamiento.
d e c o n d ic io n e s y que s e le c c io n e las a cc io n es basadas
e n esas c o n d ic io n e s . L a s ta b la s d e d e c is ió n p ro p o rc io 3. A sociar conjuntos específicos de condiciones con
n a n u n a n o ta c ió n q u e c o n v ie rte a c c io n es y c o n d ic io n e s acciones específicas, elim inando combinaciones
(d e s c rita s e n la n a rra c ió n d e l p ro c e s a m ie n to )e n u n a fo r imposibles de condiciones; alternativamente, desa
m a ta b u la r. E s d if íc il q u e la ta b la se p u e d a in te rp re ta r rrollar cualquier perm utación posible de combina
m a l, e in c lu s o es p o s ib le u t iliz a r la c o m o e n tra d a le g i ciones.
b le p o r la m á q u in a p a ra u n a lg o ritm o d irig id o p o r u n a 4. Definir reglas indicando qué acción o acciones ocu
ta b la . E n u n e s tu d io c o m p le to d e e sta h e rra m ie n ta d e rren para un conjunto de condiciones.
d is e ñ o , N e d C h a p ín a firm a [ H U R 8 3 ] :
Reglas ¿Cómo se puede construir
Condiciones
c o n d ic ió n n.° 1 V
1 2 3 4
y y
n
• una tabla de decisiones?
Para ilustrar el empleo de una tabla de decisión tome

c o n d ic ió n n.° 2 y y mos en consideración el siguiente extracto de una des
c o n d ic ió n n.° 3
y y cripción procedim ental para un sistema de facturación
de un servicio público:
Si la cu en ta del cliente se factura utilizando un método de
tarifas fijo, se establece un cargo m ensual m ínim o para con
sum os m enores de lOOkWh (kilovatios/hora). E n los demás
Acciones casos, la facturación por com putadora aplica la tarifa A. Sin
em bargo, si la cuenta se factura em pleando un m étodo de fac
ac ció n n.° 1 V yy turación variable, se aplicará la tarifa A para consum os por
acció n n.° 2 y V debajo de lOOkWh, con un consum o adicional facturado de
acció n n.° 3 y acuerdo con la tarifa B.
acció n n.° 4 yyy La Figura 16.5 ilustra una representación de tabla de

decisión de la descripción anterior. Todas y cada una de
acció n n.° 5 Vy y las cinco reglas indican una condición de las cinco via
bles (esto es, en el contexto de este procedim iento una
F IG U R A 16.4. Nom enclatura de la tabla de decisión. «V » (verdadera) no tiene sentido ni en la cuenta de tad-
fa fija ni en la variable, por tanto esta condición se omi
A lgunas herram ientas de softw are antiguas se com binan te). C om o regla general, la tabla de decisión puede
bien con otras herram ientasnuevas y técnicas de ingenieríadel utilizarse eficazm ente para com plem entar otras nota
software. L as tablas de decisión son un ejem plo excelente. F ue ciones de diseño procedimental.
ron las q ue p recedieron a la ingeniería del softw are hace casi
una década, pero encajaron tan bien con la ingeniería del soft
w are que podrían haberse diseñado con tal propósito. 16.1.3. Lenguaje de diseño de programas
El lenguaje de diseño de program as (L D P ), también
denominado lenguaje estructurado opseudocódigo, es
www.FreeLibros.org
Utilice uno tabla de decisión cuando dentro «un lenguaje rudim entario en el sentido de que utiliza
de un componente se combine un conjunto el vocabulario de un lenguaje (por ejem plo, el Inglés),
'¿xvfeAhesAw>Usa» es,m\ewga»i^, tstesRr
276
CAPÍTULO 16 D IS E Ñ O A NIVEL DE C O M P O N E N T E S
turado de program ación )> fC A I7 5 ]. E n este capítulo se H ay que d e sta c a r que L D P se p u ede a m p lia r de
utiliza L D P co m o referen cia genérica de un lenguaje de m anera que incluya palabras clave para procesos m ul-
diseño. titarea y/o concurrentes, m anipulación de in terru p cio
A prim era v ista L D P se parece a un lenguaje de p ro n e s, sin c ro n iz a c ió n en tre p ro c e so s y m u c h a s o tras
gramación m oderno. L a diferencia entre éste y un v er características. L os diseños de aplicaciones para los que
dadero lenguaje de program ació n rad ica en el em pleo se utiliza L D P deberán dictar la fo rm a final que tendrá
de texto d esc rip tiv o (p o r e je m p lo , In g lé s) in se rta d o el lenguaje de diseño.
directamente dentro de las sentencias de LDP. D ado que
se utiliza tex to d escrip tiv o in sertad o d irectam en te en 16.1.4. U n e je m p lo d e LDP
una estructura sin táctica,este lenguaje no se puede co m
P ara ilustrar el em pleo de L D P presentam os un e je m
pilar (alm enos p o r ahora). Sin em bargo, las herram ientas
plo de diseño procedim ental para el softw are del siste
LDP que e x iste n actu alm en te co n v ie rte n L D P en un
m a de seguridad H ogarSeguro com entado en capítulos
«esquem a» de len g u aje de p ro g ram ació n , y/o re p re
anteriores. El sistem a H ogarSeguro en cuestión vigila
sentación gráfica (por ejem plo, un d iagram a de flujo de
las alarm as de detección de fuego, hum o, ladrones, agua
diseño). E stas herram ientas tam b ién prod ucen m apas
y tem peratura (por ejem p lo , la ruptura del sistem a de
anidados, un índice de o peración de d iseñ o, tablas d e
calefacción durante la ausencia del propietario en invier
referencias cruzadas, y m ás d iversidad de inform ación.
no); hace saltar el sonido de la alarm a, y llam a al ser
v icio de v ig ila n cia g e n e ra n d o un m e n sa je d e voz
Reglas
-----------------------------------------
sintetizada. E n el L D P que se m uestra a continuación,
Condiciones 1 2 3 4 5 1 se ilu stran algunas de las c o n stru ccio n es im p o rtan tes
Cuenta de tarifa fija F señaladas en secciones anteriores.
V V F F
Hay que recordar que L D P no es un lenguaje de p ro
Cuenta de tarifa variable F F V V F
gram ación. El diseñador hace una adaptación cuando
Consumo < lOOkWh V F V F lo requiere y sin preocuparse de errores de sintaxis. Sin
Consumos 100kWh F V F V em bargo, se deb erá re v isa r el d iseño del softw are de
v ig ilan cia (¿se o b serv a algún p ro b lem a?) y re finarlo
antes de escribirse. El L D P siguiente define una e la b o
Acciones ració n de diseño procedim ental para el com ponente de
m onitor de seguridad.
Cargo mensual mínimo V
Facturación tarifa A V V PROCEDURE s e g u r id a d .m o n ito r ;
INTERFACE RETURNS s i s t e m a . e s ta d o ;
,Facturacióntarifa B V TEPE s e ñ a l I S STRUCTURE DEFINED
Otro tratamiento V nom bre I S STR1NG LENGTH VAR;
d i r e c c i ó n I S HEX d i s p o s i t i v o l o c a l i z a c i ó n ;
l í m i t e . v a l o r I S s u p e r i o r l í m i t e SCALAR;
m e n s a je I S STRING LENGTH VAR;
FIGURA 16.5. Tabla de decisión resultante. END s e ñ a l TEPE;
TEPE s i s t e m a . e s t a d o I S B IT (4 );
Un lenguaje de diseño de prog ram as puede ser una TEPE a la rm a , t i p o DEFINED;
simple transp o sició n de un lenguaje tal com o A da o C. hum o.alarm a I S INSTANCE OF s e ñ a l ;
A lternativam ente, p u ed e ser un p ro d u c to c o m p rad o fu e g o , alarm a I S INSTANCE OF s e ñ a l ;
específicamente p ara el diseño procedim ental. agua, alarm a I S INSTANCE OF s e ñ a l ;
tem p. alarm a I S INSTANCE OF s e ñ a l;
la d r ó n , alarm a I S INSTANCE OF s e ñ a l ;
TEPE t e l é f o n o . n ú m e ro I S a re c ó d ig o t 1 -d íg ito
Sería una buena idea utilizar un lenguaje
n ú m e ro ;
de programación cama base para el LDP.
Esb hará posible generar un esquema de código
(mezclado can texto) a medida que se lleva
a cabo el diseño a nivel de componentes.
i n i c i a l i z a r to d o s s i s t e m a s p u e r t o s y r e i n i c i a l i z a r
Una sintaxis b ásica L D P deberá inclu ir construccio to d o h a rd w a re ;
nes para la definición de subprogram as, d escripción de CASE OF c o n tr o l .p a n e l . i n t e r r u p t o r e s (c p s) -
la interfaz, d eclaración de datos, técnicas p ara la estru c WHEN c p s = " t e s t ' SELECT
turación de bloques, co nstrucciones de condición, co n s CALL alarm a PROCEDURE W1TH " a c ti v a d o " p a r a c o
www.FreeLibros.org
p r o b a c ió n , tie m p o en se g u n d o s;
trucciones re p e titiv a s y c o n stru c c io n e s de E /S. El
formato y la sem ántica de estas co nstrucciones L D P se ItHEN c p s = "a la rm a -d e sa c tiv a d a "S E L E C T
presentan en la sección siguiente. CALL alarm a PROCEDURE WITH " d e s a c ti v a d a " ;
277
in g e n ie ría d e l s o f tw a r e , un en fo q u e p ra c tic o
WHEN c p s = "nuevo, l í m i t e , tem p " SELECT PARBEGIN

CALL t e c la d o , e n tr a d a PROCEDURE; CALL ala rm a PROCEDURE WITH " a c tiv a d a " ,alafa
WHEN c p s = " la d r ó n a la r m a , d e s a c ti v a d a " SELECT ma. tie m p o en se g u n d o s ;
d e s a c t i v a r s e ñ a l [ la d r ó n . a la rm a ]; CALL t e l é f o n o PROCEDURE WITH m e n sa je [alar'
ma. t i p o ] , t e l é f o n o núm ero;
ENDPAR
ELSE b i f u r c a c i ó n
DEFAULT n in g u n o ; ENDIF
ENDCASE ENDFOR
REPEAT UNTIL a c t i v a r . i n t e r r u p t o r e s d e s a c ti v a d o ENDREP
r e i n i c i a l i z a r to d o s s e ñ a l .v a l o r e s e i n t e r r u p t o r e s ; END s e g u r id a d .m o n ito r
DO FOR a l a r m a . t i p o = hum o, f u e g o , a g u a , tem p , H a y que destacar que e l d ise ñ a d o r d e l procedimiento
la d r ó n ;
d e l m o n ito r de s e g u rid a d h a u tiliz a d o u n a construcción
READ d ir e c c ió n [ a la r m a , t ip o ] s e ñ a l .v a l o r ;
IF s e ñ a l . v a l o r > l í m i t e [alarm a, t ip o ]
nueva PARBEGZN... ENDPAR la c u a l especifica un blo
que p a ra le lo . Todas las tareas e sp e cific ad a sd en tro del blo
THEN t e l é fo n o .m e n s a j e = m e n s a je [ a la r m a . t i p o ] ;
e s t a b l e c e r a la rm a , t im b r e e n " a c ti v a d a " p a r a
que PARBEGZN se e je c u ta n e n p a ra le lo . E n este caso,no
se to m a n e n c o n sid e ra ció n lo s detalles d e implementación.
E n la s e c c ió n a n te rio r se h a n p re s e n ta d o v a ria s té c n ic a s c o n la q u e u n d is e ñ o se p u e d e e d it a r a y u d a rá a sim

d ife re n te s p a ra re p re s e n ta r u n d is e ñ o p ro c e d im e n ta l. Se p l i f i c a r to d a s y c a d a u n a d e las ta re a s d e la ingenie
p u e d e e s ta b le c e r u n a c o m p a ra c ió n te n ie n d o la p re m is a r ía d e l s o ftw a re .
d e q u e c u a lq u ie r n o ta c ió n p a ra e l d is e ñ o p ro c e d im e n -
L egibilidad para la com putadora. U n a notación
t a l , si se u t iliz a c o r r e c ta m e n te , p u e d e s er u n a a y u d a
q u e se p u e d e in tr o d u c ir d ire c ta m e n te e n u n sistem a de
in c a lc u la b le p a ra e l p ro c e s o d e d is e ñ o ; p o r e l c o n tra rio ,
d e s a rro llo b a sa d o e n c o m p u ta d o ra o fre c e ventajas sig
au n c o n la m e jo r n o ta c ió n , si ésta se a p lic a m a l, d is m i
n ific a tiv a s .
n u y e su e n te n d im ie n to . T e n ie n d o e n c u e n ta lo a n te rio r,
es m o m e n to d e e x a m in a r lo s c rite r io s q u e se p u e d e n C apacidad de m antenim iento. E l m an ten im ien to
a p lic a r p a ra c o m p a ra r las n o ta c io n e s d e d iseñ o . d e l s o ftw a re es la fase m á s costosa d e l c ic lo de v id a del
L a n o ta c ió n d e d is e ñ o d e b e rá lle v a m o s a u n a re p re s o ftw a re . E l m a n te n im ie n to d e la c o n fig u ra c ió n del soft
s e n ta c ió n p ro c e d im e n ta l fá c il d e e n te n d e r y d e re v is a r. w a re casi s ie m p re lle v a al m a n te n im ie n to de la repre
A d e m á s , la n o ta c ió n d e b e r á m e jo r a r la h a b ilid a d d e s e n ta c ió n d e l d is e ñ o p ro c e d im e n ta l.
« c o d ific a r e n » p a ra q u e e l c ó d ig o se c o n v ie rta de h e c h o C um plim iento de las estructuras. Y a se han des
e n u n s u b p ro d u c to n a tu ra l d e d is e ñ o . F in a lm e n t e , la c rito las v e n ta ja s d e u n e n fo q u e d e d is e ñ o que utiliza
re p re s e n ta c ió n d e d is e ñ o d e b e rá ser fá c il d e m a n te n e r c o n ce p to s d e p ro g ra m a c ió n e s tru c tu ra d a . U n a notación
p a ra q u e e l d is e ñ o sea s ie m p re u n a re p re s e n ta c ió n d e d is e ñ o que h a ce c u m p lir s o lo la u tiliz a c ió n de cons
c o rre c ta d e l p ro g ra m a . tru c c io n e s e s tru c tu ra d a s c o n d u c e a la p rá c tic a de un
b u e n d iseñ o .
« ¿Cuáles son los criterios que
w se utilizan para evaluar Proceso autom ático. U n d is e ñ o p ro c e d im e n ta l con
notaciones de diseño? tie n e la in fo r m a c ió n q u e se p u e d e p ro c e s a r p a ra que el
d is e ñ a d o r p u e d a o b s e rv a r o tra v e z y m e jo r a r la correc
D e n tro d e l c o n te x to d e las c a ra c te rís tic a s g e n e ra le s c ió n y c a lid a d d e u n d ise ñ o . D ic h a o b s e rv a c ió n puede
q u e se d e s c rib ie ro n a n te rio rm e n te se h a n e s ta b le c id o m e jo ra rs e c o n in fo rm e s q u e p ro v e n g a n d e h e rram ien
lo s s ig u ie n te s a trib u to s d e n o ta c io n e s d e d is e ñ o : tas d e d is e ñ o d e s o ftw a re .
M odularidad. U n a n o ta c ió n de d is e ñ o d e b e rá s o p o r R epresentación de datos. L a h a b ilid a d d e repre
ta r e l d e s a rro llo d e l s o ftw a re m o d u la r y p ro p o rc io n a r s en tar d a to s lo c a le s y g lo b a le s es u n e le m e n to esencial
u n m e d io p a ra la e s p e c ific a c ió n d e la in te rfa z . d e l d is e ñ o d e ta lla d o . U n a n o ta c ió n d e d is e ñ o id e a l sería
Sim plicidad general. U n a n o ta c ió n d e d is e ñ o d e b e la re p re s e n ta c ió n d ire c ta d e lo s datos.
rá ser re la tiv a m e n te s im p le d e a p re n d e r, re la tiv a m e n te
Verificación de la lógica. L a v e r ific a c ió n autom áti
fá c il de u t iliz a r y e n g e n e ra l fá c il d e lee r.
c a d e la ló g ic a d e l diseñ o es e l o b je tiv o p rim o rd ia l duran
www.FreeLibros.org
F acilid ad de ed ició n . E s p o s ib le q u e e l d is e ñ o te las p ru e b a s d e l s o ftw a re . U n a n o ta c ió n q u e m e jo ra la
p ro c e d im e n ta l r e q u ie r a a lg u n a m o d ific a c ió n a m e d i h a b ilid a d d e v e r ific a r la ló g ic a m e jo r a e n o rm e m e n te lo
d a q u e e l p ro c e s o d e s o ftw a r e a v a n z a . L a f a c ilid a d a c e p ta b le de las pru eb as.
270
CAPITULO 16 D I S E Ñ O A NIVEL DE C O M P O N E N T E S
Habilidad de «codificaren». La tarea de ingenie ten, y el potencial de «generar códigos automáticos» es

ría del software que va a continuación del diseño a nivel bueno.
efe componentes es la generación de códigos. Una nota Sin embargo, no se puede decir que la notación
ción que puede convertirse fácilmente en código fuen de diseños sea necesariamente inferior a LDP o que
te reduce esfuerzos y errores. «sea buena» en atributos específicos. M uchos d ise
Lina pregunta que surge naturalmente de cualquier ñadores prefieren la naturaleza pictórica de los dia
estudio de notaciones de diseño es: «¿Cuál es realmen gramas de flujo y de los diagramas de bloques dado
te la mejor notación según los atributos que se han esta que proporcionan alguna perspectiva sobre el flujo
blecido anteriormente?» La respuesta sería totalmente de control. El contenido tabular preciso de las tablas
subjetiva y abierta a debate. Sin embargo, parece ser de d ecisión es una herramienta excelen te para las
que el lenguaje de diseño de programas ofrece la mejor aplicaciones controladas por tablas. Y muchas otras
combinación de características. LDP puede insertarse representaciones de diseño (por ejem plo, véase
directamente en listados de fuentes, en mejoras de docu [PE T 81], [SO M 96]), que no se presentan en este
mentación y al hacer que el mantenimiento del diseño libro, ofrecen sus propias ventajas. En el análisis
sea menos difícil. La edición se puede llevar a cabo final, la selección de una herramienta de diseño pue
mediante cualquier editor de texto o sistema de proce de depender más de factores humanos [CUR85] que
samiento de texto; los procesadores automáticosya exis de atributos técnicos.
El proceso de diseño acompaña a una secuencia de acti las notaciones de diseño que representa los detalles a
vidades que reducen lentamente el nivel de abstracción nivel de componentes o bien en formatos gráficos, tabu
con el que se representa el software. El diseño a nivel lares o basados en texto.
de componentes representa el software a un nivel de La programación estructurada e s una filosofía de
abstracción muy cercano al código fuente. diseño procedimental que restringe el número y tipo de
A un nivel de componentes, el ingeniero del software construcciones lógicas que se utilizan para representar
debe representar estructuras de datos, interfaces y algo el dato algorítmico. El objetivo de la programación
ritm os con suficiente detalle como para servir de guía estructurada es ayudar a que el diseñador defina algo
en la generación de códigos fuente de lenguajes de pro ritmos menos complejos y por tanto más fáciles de leer,
gramación. Para conseguirlo, el ingeniero utiliza una de comprobar y mantener.
[BOH66] Bohm, C., y G. Jacopini,«Flow Diagramas, Turing [DIJ76] Dijkstra, E., «Structure Programming», Software
Machines andLanguageswith only twoFormation Rules», Engineering, Concepts and Techniques (J. Buxton et al.,
CACMvol. 9, n.a 5, Mayo 1966,pp. 366-371. eds.), Van Nostrand-Reinhold, 1976.
[CAI75] Carne, S„ y K. Gordon, «PDL -A Tool for Soft [HUR83] Hurley, R.B., Decisión Tables in Software Engi
ware Design», in Proc. National Computer Conference, neering, Van Nostrand Reinhold, 1983.
AFIPS Press, 1975,pp. 271-276.
[LIN79] Linger, R.C, H. D. Mills y B.I. W itt, Estructured
[CHA74] Chapín,N., «A N ew Form atforFlow charts», Soft Programming, Addison-Wesley, 1979
ware—Practice and Experience, vol. 4, n.2 4, 1974, pp.
341-357. [NAS73] Nassi, I., y B. Shneiderman, «Flowchart Techni
ques for Structured Programming», SIG PLAN Notices,
[DU65] Dijkstra,E., «Programming Consideredas a Human
ACM, Agosto 1973.
Activity», in Proc. 1 9 6 5 IFIP Congress, North Holland
Publishing Co., 1965. [PET81] Peters, L.J., Software Design: Methods and Tech
niques, Yourdon Press, Nueva York, 1981.
[DU72] Dijkstra,E„ «TheHumbleProgrammer», 1972ACM
Turing Áward Lecture, CACM, vol. 15. n.2 10, Octubre [SOM96] Som m erville, I. Software Engineering, 5.- ed..
1972,pp. 859-866. Addison-Wesley, 1996.
I N GE NI E RÍ A DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
9jdü1Z.H
16.1. S e le c c io n e u n a p a rte p e q u e ñ a d e u n p r o g ra m a q u e y a s u p o n g a q u e to d o s lo s p ro c e s o s so b re lo s im p u e s to s son lle

e x is ta (a p ro x im a d a m e n te d e 5 0 -7 5 lín e a s d e c ó d ig o ). A ís le las v a d o s a c a b o p o r o tro s m ó d u lo s.
c o n s tru c c io n e s d e p ro g ra m a c ió n e s tru c tu ra d a d ib u ja n d o c a ja s
16.6. D e s a rro lle u n d is e ñ o p ro c e d im e n ta l p a ra u n program a
a lre d e d o r d e e lla s e n e l c ó d ig o fu e n te . ¿ E x iste n c o n s tru c c io
q u e a c e p te u n te x to a r b itra ria m e n te la rg o c o m o e n tra d a y ela
n e s d e n tro d e l p a sa je d e l p ro g ra m a q u e v io le n la filo s o fía d e
b o re u n a lis ta d e p a la b ra s y d e su fre c u e n c ia d e a p a ric ió n como
p ro g ra m a c ió n e stru c tu ra d a ? Si fu e ra a sí, v u e lv a a d is e ñ a r e l
salid a.
c ó d ig o p a ra a d a p ta rlo a la s c o n s tru c c io n e s d e p ro g ra m a c ió n
e stru c tu ra d a . Si n o fu e ra a sí, ¿ Q u é se p u e d e d e s ta c a r e n las 16.7. D e s a rro lle u n d ise ñ o p ro c e d im e n ta l d e u n p ro g ram a que
c a ja s q u e a c a b a d e d ib u ja r? in te g re n u m é ric a m e n te u n a f u n c ió n / e n lo s lím ite s d e a hacia b.
16.2. T o d o s lo s le n g u a je s d e p ro g r a m a c ió n m o d e rn o s im p le - 16.8. D e s a rro lle u n d is e ñ o p ro c e d im e n ta l p a ra u n a m áquina

m e n ta n la s c o n s tru c c io n e s d e p ro g ra m a c ió n e stru c tu ra d a . Pro T u r in g g e n e r a liz a d a q u e a c e p te u n c o n ju n to d e c u ád ru p les
p o rc io n e e je m p lo s d e tre s le n g u a je s d e p ro g ra m a c ió n . c o m o e n tra d a d e p ro g ra m a y e la b o re u n a sa lid a se g ú n espe
c ific a c ió n .
16.3. ¿Por q u é e s im p o rta n te la « f ra g m e n ta c ió n » d u ra n te el
p ro c e s o d e re v is ió n d e d is e ñ o a n iv e l d e c o m p o n e n te s? 16.9. D e s a rro lle u n d is e ñ o p ro c e d im e n ta l p a r a u n program a
q u e s o lu c io n e e l p ro b le m a d e la s T o rre s d e H a n o i. M uchos
Los p r o b le m a s 1 6 .4 -1 6 .1 2 se p u e d e n r e p re s e n ta r e n u n a ( o
lib ro s d e in te lig e n c ia a rtific ia l e s tu d ia n e s te p ro b le m a deta
m á s ) n o ta c io n e s d e d is e ñ o p r o c e d im e n ta le s p r e s e n ta d a s e n
lla d a m e n te .
e ste c a p ítu lo . S u p ro fe s o r p u e d e a s ig n a r n o ta c io n e s d e d is e ñ o
e s p e c ífic a s a p ro b le m a s c o n c re to s. 16.10. D e s a rro lle u n d is e ñ o p ro c e d im e n ta l p a ra to d a s las par
te s o la s p a rte s fu n d a m e n ta le s d e u n a n a liz a d o r sin tác tic o p aia
16.4. D e s a r r o lle u n d is e ñ o p r o c e d im e n ta l p a r a lo s c o m p o
u n c o m p ila d o r. C o n s u lte u n o o m á s lib ro s s o b re d ise ñ o de
n e n te s q u e im p le m e n ta n la s o rd e n a c io n e s sig u ie n te s: S h e ll-
c o m p ila d o re s.
M e tz n e r; heapsort (o rd e n a c ió n d e l m o n tíc u lo ) . S i n o e s tá
fa m ilia riz a d o c o n e sta s o rd e n a c io n e s , c o n s u lte c u a lq u ie r lib ro 16.11. D e s a rro lle u n d is e ñ o p ro c e d im e n ta l p a ra e l algoritm o
so b re e s tru c tu ra s d e d a to s. d e e n c rip ta c ió n /d e s c rip ta c ió n q u e h a y a se le c c io n a d o .
16.5. D e s a rro lle u n d ise ñ o p ro c e d im e n ta l p a ra u n a in te rfa z d e 16.12. E s c rib a u n a rg u m e n to d e u n a o d o s p á g in a s p a ra la nota

u s u a rio in te ra c tiv a q u e so lic ite in fo rm a c ió n b á sic a a c e rc a d e c ió n d e d ise ñ o p ro c e d im e n ta l q u e p re fie ra. A s e g ú re se de que su
lo s im p u e s to s so b re la re n ta . D e riv e su s p ro p io s re q u is ito s y a rg u m e n to a b a rc a los c rite rio s p re s e n ta d o s e n la S e c ció n 16.2.
E l tra b a jo d e L in g e r, M ills y W itt (Structured Programming- e l d is e ñ o p r o c e d im e n ta l e n u n c o n te x to d e le n g u a je de pro

Theory and Practice, A d d is o n -W e s le y , 1 9 7 9 ) s ig u e sie n d o e l g r a m a c ió n :
e s tu d io d e fin itiv o s o b re e s ta m a te ria . E l te x to c o n tie n e u n A d a m s o n , T .A ., K .C . M a n s f ie ld y J.L . A n to n a k o s , Stnic-
b u e n L D P a sí c o m o e s tu d io s d e ta lla d o s d e ra m ific a c io n e s d e tured Basic Applied to Technology, P re n tic e H a ll, 2000.
la p ro g r a m a c ió n e stru c tu ra d a . E n tre o tr o s lib ro s q u e se c e n A n to n a k o s , J.L., y K . M a n s fie ld , Application Program
tra n e n te m a s d e d is e ñ o p ro c e d im e n ta l se in c lu y e n lo s lib ro s ming in Structured C, P re n tic e H a ll, 1996.
d e R o b e rts o n (SimpleProgram Design, B o y d & F ra s e r P u b lis- F o ro u z a n , B .A ., y R. G ilb e rg , Computer Science: A Stnic-
h in g , 1 9 9 4 ), B e n tle y (ProgrammingPearls, A d d is o n -W e s tured Programming Approach Using C+ + , B ro o k s/C o le
le y , 1 9 8 6 , y More Programming Pearls, A d d is o n - W e s le y , P u b lis h in g , 1999.
1 9 8 8 )y D a h l, D ijk stra y E loare (StnicturedProgatmning, Acá.- O ’B rie n , S .K ., y S. N a m e ro ff, TurboPascal 7: The Com
d e m ic P re s s , 1972). plete Reference, O s b o m e M c G r a w -H ill, 1993.
Solo e x is te u n n ú m e r o r e la tiv a m e n te p e q u e ñ o d e lib r o s W e lb u m , T., y W. P ric e , Structured Cobol: Fundamentals
a c tu a le s d e d ic a d o ú n ic a m e n te a l d i s e ñ o a n iv e l d e c o m and Style, 4.- e d ., M itc h e ll P u b lis h e rs , 1995.
p o n e n te s . E n g e n e r a l, lo s l i b r o s d e l e n g u a j e s d e p r o g r a U n a g r a n v a rie d a d d e fu e n te s d e in fo rm a c ió n so b re dise
m a c ió n a b o r d a n e l d is e ñ o p r o c e d im e n ta l c o n a lg ú n d e ta lle , ñ o d e s o f tw a r e y te m a s r e la c i o n a d o s e s t á n d is p o n ib le s en
p e r o s ie m p r e e n e l c o n te x to d e l le n g u a je q u e se h a i n t r o In te m e t. U n a lis ta a c tu a liz a d a d e re f e r e n c ia s a sitio s (luga
d u c id o e n e s te lib ro . L o s s i g u ie n te s lib r o s s o n r e p r e s e n t a re s) w e b q u e so n re le v a n te s p a ra c o n c e p to s y m é to d o s d e dise
tiv o s d e l o s c ie n to s d e tít u l o s q u e t ie n e n e n c o n s i d e r a c i ó n ñ o se p u e d e n e n c o n tr a r e n http://www.pressman5.com.
C A PÍT U L O
T É C N IC A S DE PR U EB A
D EL S O FTW A R E
k “ TUNCA se dará suficiente im portancia a las pruebas del software y sus implicaciones en
\ I la calidad del software. Citando a Deutsch [DEU79]:
El desarro llo de sistem as de softw are im plica una serie de activ id ad es d e p ro d u cció n en las que las p o si
bilidades de que ap arezca el fallo hum ano son enorm es. L o s errores pued en em p ezar a darse d e sd e el p ri
m er m om ento del proceso, en el que los objetivos....pueden estar especificados de form a errónea o im perfecta,
a sí co m o [en] po sterio res pasos de diseño y d e sa rro llo ..D e b id o a la im p o sib ilid ad h um ana de trab a ja r y
c o m u n icarse de form a perfecta, el desarro llo de softw are h a de ir a com pañado de una actividad que g a ran
tice la calidad.
Las pruebas del software son un elemento crítico para la garantía de calidad del software y
representa una revisión final de las especificaciones, del diseño y de la codificación.
La creciente percepción del software com o un elemento del sistema y la im portancia de los
«costes» asociados a un fallo del propio sistema, están m otivando la creación de pruebas m inu
ciosas y bien planificadas. N o es raro que una organización de desarrollo de software emplee
entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas. En casos extre
mos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo,
control de reactores nucleares) puede costar ¡de tres a cinco veces m ás que el resto de los pasos
de la ingeniería del software juntos!
VISTAZO RÁPIDO
¿ Q u é e s ? U n a vez g e n e r a d o e 1 có d ig o b a s. S in e m b a rg o , c o n fo n n e p ro g re s a b lan c a» . Los req u isito s d e l softw are se

‘ fu e n te , e l so ftw a re d e b e s e r p ro b a d o e l p ro c eso d e p ru e b a , los e sp e c ia lista s com prueban u t i 1 i i o téc n ic a sd e dise
p a ra d e sc u b rir (y corregir) e l m áxim o e n p ru e b a s se v a n in co rp o ra n d o . ño d e c aso s d e p ru e b a d e «caja negra»,
d e errores p o sib le s a n te s d e su e ntre- En a m b o s casos, se in te n ta e n c o n tra re l
¿Por q u é e s im portante? Las rev isio m ayor núm ero d e errores con la m enor
i . g a a l cliente. N ueslro objetivo e s d ise nes y o tra s activ id ad esS Q A d escubren
ñ a r u n a se rie d e c aso s d e p ru e b a q u e ca n tid a d d e esfuerzo y tiem po.
e rro re s, p e ro no so n su fic ie n tes. C a d a
te n g a n u n a a lt a p r o b a b ilid a d d e vez que el p ro g ram a s e e je c u ta ,e l clien ¿ C u á l e s e l p r o d u c t o o b t e n i d o ? Se
en co n trar e rro re s — ero ¿cóm o c o n se te lo e s tá probando. Por lo ta n to , d e b e d e fin e y d o c u m e n ta u n c o n ju n to d e
guirlo?— A quí e s donde a p lic am o s la s m o s h a c e r un in te n to e s p e c ia l por c a s o s d e p ru e b a , d ise ñ a d o s p a r a com
técnicas d e p ru e b a s d e l softw are. E stas e n c o n tra r y c o rre g ir to d o s los e rro re s p ro b a r la lógica in te rn a y los re q u isito s
téc n ica s fa c ilita n u n a g u ía siste m á ti a n te s d e e n tre g a r el p ro g ra m a a l c lie n externos. Se d e te rm in a n los re su lta d o s
c a p a r a d is e ñ a r p ru e b a s que: (1) com te. Con el objetivode en co n trare l m ayor e sp e ra d o s y s e g u a rd a n los re su lta d o s
p ru e b e n la lógica in te rn a d e los n ú m ero posible d e e rro re s ,la s p ru e b a s re a lm e n te obtenidos.
co m ponentes softw are, y (2) verifiquen d e b e n c onducirse siste m á tic am e n te . y
¿Cómo puedo M iar seguro d e g :* lo
los d o m in io s d e e n tr a d a y s a l id a d e l los c a sos d e p ru e b a d e b e n d is e ñ a rs e h e h ech o co rrec tam e n te? C u a n
: ■ p ro g ram a p a r a d e sc u b rir erro re s e n la u tilizan d o té c n ic a s defin id as. d o com ienzas la p ru e b a ,d e b e s c a m b ia r
fu n c io n a lid a d , e l c o m p o rta m ie n to y
¿Cuáles son los pesos? El softw are d ebe tu p u n to d e v ista, in te n ta «romper» con
rendim iento firm eza e l so ftw a re. D ise ñ a c a s o s d e
p ro b a rse d e sd e d o s p e rsp e c tiv a s dife- '
¿Quién lo h a ce? D u ra n te la s p rim e ras ren tes: (1) la lógica in te rn a d e l p ro g ra p r u e b a d e u n a fo rm a d is c ip lin a d a y
e ta p a s d e la p ru e b a, e s el ingeniero del m a se com prueba u t i l i i d o técn icas de re v is a q u e d ic h o s c a s o s d e p ru e b a
softw are q u ie n re a liz a to d a s la s p ru e d ise ñ o d e c a s o s d e p ru e b a d e «caja a b a rc a n todo lo d esa rro llad o .
www.FreeLibros.org
En este capítulo, verem os los fundamentos de las pruebas del software y las técnicas de dise
ñ o de casos de prueba.
281
IN GE NI E RÍ A DEL S O F TW A RE . UN EN FOQ UE P R A C T I C O
Las p ruebas presen tan una interesante anom alía para el 2. U n bu en caso de prueba es aquel que tiene una alta
ingeniero del softw are. D urante las fases anteriores de probabilidad de m ostrar un error no descubierto hasta
definición y de desarrollo, el ingeniero intenta construir entonces.
el softw are partiendo de un concepto abstracto y llegan 3. U na prueba tiene éxito si descubre un error no detec
do a una im plem entacióntangible. A continuación, llegan tado hasta entonces.
las pruebas. El in g e n ie ro c rea u n a serie de casos de prue
ba que intentan «dem oler» el softw are construido. De ¿Cuál es nuestro primer
hecho, las pruebas son uno de los p asos de la ingeniería
del softw are que se puede v er (por lo m enos, psicológi
cam ente) com o destructivo en lugar de constructivo.
• objetivo cuando probamos
el softw are?
Los objetivos anteriores suponen un cam bio dramá

tico de p u n to de vista. Nos qu itan la idea que, normal
m e n te , te n e m o s de que una p ru e b a tie n e éxito si no
descu b re errores.
N uestro objetivo es diseñar pruebas que sistemática
m ente saquen a la luz diferentes clases de errores, hacién
dolo con la m en o r cantidad de tiem po y de esfuerzo.
Si la prueba se lleva a cabo con éxito (de acuerdo ccn
Los ingenieros del softw are son, p o r n aturaleza, p e r
el objetivo anteriorm ente establecido),descubrirá errores
sonas constructivas. L as p ruebas req u ieren que se d es
en el softw are. C om o ventaja secu n d aria, la pmeba
ca rte n id eas p re c o n c e b id as sobre la « co rrecció n » del
dem uestra hasta qué punto las fondones del software pare
softw are que se acaba de desarro llar y se supere cu al
cen funcionarde acuerdo con las especificacionesy pare
q u ier co n flicto de in tereses que a p arezcan cu ando se
cen alcanzarse los requisitos de rendim iento. Además, los
descubran errores. B eizer [BEI90] d escrib e e ficien te
datos que se van recogiendo a m edida que se lleva a cabo
m ente esta situación cuando plantea:
la prueba proporcionan una buena indicación de la fiabi
E xiste un m ito que dice que si fuéram os realm ente buenos
lidad del softw are y, de algunam anera, indican la calidad
program ando, no habría errores que buscar. Si tan sólo fuéra
m os realm ente capaces de co n cen trarn o s, si todo el m undo del softw are com o un todo. Pero, la prueba no puede ase
em pleara técnicas de codificación estructuradas, el diseño des g urar la ausencia de defectos; sólo puede dem ostrar que
cendente, las tablas de decisión, si losprogramas seescribieran existen defectos en el software.
en u n lenguaj e apropiado, si tuviéram os siempre la solución m ás
adecuada, entonces no habría errores. A sí es el mito. Según el
mito, existen errores porque som os m alos en lo que hacem os,
y si som os m alos en lo que hacem os, deberíam os sentirnos cul
pables por ello. P or tanto, las pruebas, con el diseño de casos
de prueba, son un reconocim iento de nuestros fallos, lo que
im plica una buena dosis de culpabilidad. Y lo tediosas que son
las pruebas so n u n ju sto castigoa nuestroserrores. ¿Castigados
por qué? ¿Por ser hum anos? ¿Culpables por qué? ¿Por no con
seguir una perfección inhum ana? ¿Por no poder distinguirentre
lo que o tro p rogram ador piensa y lo que dice? ¿Por no tener
telepatía? ¿Por no resolver los problem as de co m u n icació n 17.1.2. P rincipios d e la s pruebas
hum ana que han estado presentes...durante cuarenta siglos?
A n tes de la ap licació n de m é to d o s p a ra el diseño de
¿D eben infundir culpabilidad las pruebas? ¿Son real c aso s de p ru e b a e fe c tiv o s, un in g en iero del software
m ente destructivas? L a resp u esta a estas preguntas es: deb erá e n te n d e r lo s p rin c ip io s b ásico s que guían las
¡No! Sin em bargo, los objetivos de las p ruebas son algo pruebas del softw are. D avis [DAV95] sugiere un con
diferentes de lo que p odríam os esperar. ju n to ' de principios de prueba que se han adaptado para
usarlos en este libro:
17.1.1. O bjetivos d e la s pruebas • A todas las pru ebas se les debería p o d e r hacer un
E n un ex celen te lib ro sobre las p ru eb as del softw are, seguimiento hasta los requisitos del cliente. Como
G len M yers [M YE79] establece varias norm as que pue h em os visto, el objetivo de las pruebas del software
den servir acertadam entecom o o b jetiv o sd e las pruebas: es descubrir errores. Se entiende que los defectosirás
1. La prueba es el proceso de ejecución de un program a graves (desde el punto de vista del chente) son aque
con la intención de descu b rir un error. llos que im piden al program a cum plir sus requisitos.
www.FreeLibros.org
1 Aquí se presenta sólo un pequeño subconjunto de los principios de
ingeniería de pruebas de Davis. Para obtener m ás inform ación, vea
[DAV96],
282
CAPITULO 17 T É C N I C A S DE P RU E BA DEL S O F T W A R E
• Las p ru e b a s d eberían p la n ific a rse m u ch o a n tes de La facilidadde prueba del software es simplemente la
que empiecen. L a planificación de las p ruebas (C apí facilidad con la que se puede probar un programa de com
tulo 18) p u ed en em p ezar tan pronto co m o esté co m putadora. Como la prueba es tan profundam ente difícil,
pleto el m odelo de requisitos. L a definición detallada merece la pena saber qué se puede hacer para hacerlo más
de los caso s de p ru e b a p u ed e e m p e z a r ta n p ro n to sencillo. A veces los program adores están dispuestos a
com o el m o d elo de d iseñ o se h a co n so lidado. P o r hacer cosas que faciliten el proceso de prueba y una lista
tanto, se pu ed en p lan ificar y d iseñ ar to d as las p ru e de comprobación de posibles puntos de diseño, caracte
bas antes de g en erar n in g ú n código. rísticas, etc., puede ser útil a la hora de negociar con ellos.
• E l p rin cip io de P areto es aplicable a la p r u e b a del
software. D icho de m an era sencilla, el principio de
Pareto im plica que al 80 p o r 100 de tod os los e rro
Referencia
res d escu b ierto s d u ra n te las p ru e b a s se les puede
hacer un seguim iento h asta u n 20 p o r 100 de todos Un útil documento titulado ((Perfeccionandola facilidad
los m ódulos del p ro g ram a. E l p ro b le m a , p o r déla prueba del software» puede encontrarseen:
supuesto, es aislar estos m ódulos sospechosos y p ro www.it!abs.coni/itewsletters/testnet/docs/testg|iKty.ht¡n.
barlos concienzudam ente.
• Las p ru e b a s deberían em p eza r p o r «lo p e q u e ñ o » y
Existen, de hecho, métricas que podrían usarse para
m edir la facilidad de prueba en la m ayoría de sus aspec
progresar hacia «lo gra n d e ». L as p rim eras pruebas
tos. A veces, la facilidad de prueba se usa para indicar
planeadas y ejecutadas se centran generalm ente en
lo adecuadamente que un conjunto particular de prue
m ódulos in dividuales del program a. A m ed id a que
bas va a cubrir un producto. También es em pleada por
avanzan las pruebas, d esplazan su pun to de m ira en
los militares para indicar lo fácil que se puede com pro
un intento de encontrar errores en grupos integrados
bar y reparar una herram ienta en plenas maniobras. Esos
de m ódulos y finalm ente en el sistem a entero (C apí
dos significados no son lo m ismo que «facilidadde prue
tulo 18).
ba del software». La siguiente lista de com probación
• No son p o s ib le s las p ru e b a s exhaustivas. E l núm ero proporciona un conjunto de características que llevan a
de p erm utaciones de cam inos p ara in clu so un p ro un software fácil de probar.
gram a de tam añ o m o d erad o es ex cep cio n alm en te
grande (v ea la S e c c ió n 17.2 p a ra u n e stu d io m ás O p e ra tiv id a d . «C uanto m ejor funcione, m ás efi
avanzado). P o r este m o tiv o , es im p o sib le ejecu tar cientemente se puede probar.»
todas las com binaciones de cam inos durante las p ru e • El sistem a tiene pocos errores (los errores añaden
bas. Es posible, sin em bargo, cu b rir adecuadam ente sobrecarga de análisis y de generación de informes
la lógica del p ro g ra m a y aseg u rarse de que se han al proceso de prueba).
aplicado todas las co ndiciones en el d iseñ o a nivel « Ningún error bloquea la ejecución de las pruebas
de com ponente.
• El producto evoluciona en fases funcionales (per
• Para ser m ás eficaces, las p ru e b a s deberían ser rea-
m ite sim ultanear el desarrollo y las pruebas).
lizadaspor un ecpiipo independiente. P o r «m as efi
caces» querem os referirnos a p ruebas con la m ás alta O b serv ab ilid a d . «Lo que ves es lo que pruebas.»
probabilidad de encontrar errores (el objetivo prin ci • Se genera una salida distinta para cada entrada.
pal de las pruebas). P o r las razones que se ex pusie
• Los estados y variables del sistema están visibles o
ron an terio rm en teen este capítulo, y que se estudian
con m ás detalle en el C apítulo 18, el ingeniero del
se pueden consultar durante la ejecución.
software que creó el sistem a no es el m ás adecuado « Los estados y variables anteriores del sistema están
para llevar a cabo las p ruebas p ara el softw are. visibles o se pueden consultar (por ejem plo, reg is
tros de transacción).
17.1.3. F a cilid a d d e p ru eb a • Todos los factores que afectan a los resultados están
En circunstancias id eales, u n in g en iero d el so ftw are visibles.
diseña un p ro g ram a de com putadora, un sistem a o un « Un resultado incorrecto se identifica fácilmente.
producto con la « facilidad de p ru eb a» en m ente. Esto « Los errores internos se detectan automáticamente a
permite a los encargados de las p ruebas d iseñar casos través de m ecanismos de auto-comprobación.
de prueba m ás fácilm ente. Pero, ¿qué es la «facilidad
• Se inform a automáticamente de los errores internos.
de prueba» Jam es B ach 2 describe la facilidad de p ru e
ba de la siguiente m anera: . El código fuente es accesible.
www.FreeLibros.org
2 Los siguientes párrafos son copyright de Jam es Bach, 1994,y se han
adaptado de una página de lntem et que apareció inicialm ente en el
grupo de noticias comp.software-eng. Este material se ha usado con
penniso.
283
• L a docum entación técnica está bien organizada.

• L a docum entación técnica e s específica y detallada.
• L a docum entación técn ica es exacta.
«Lq facilidad de pruebo» ocurre como el resultadode
un buen diseño. El diseño de datos, de lo arquitectura, L os atributos sugeridos po r B ach los puede emplear
de los ¡nterfacesy de los componentes de detalle pueden el ingeniero del softw are para desarrollar una configu
facilitarla prueba o hacerlo más difícil. ració n del softw are (por ejem plo, p ro g ram as, datos y
docum entos) que pued a probarse.
C o n tro lab ilid ad. « C u an to m ejo r p odam os contro
lar el softw are, m ás se puede autom atizar y optim izar.» ¿Cuóles s o n las c a r a c te rís tic a s
de una « b u e n a » prueba?
« T odos los re su lta d o s p o sib le s se p u e d e n g en erar a
trav és de alguna com binación de entrada. ¿Y qué pasa con las pruebas propias? K aner, Falky
« Todo el código es ejecutable a través de alguna co m N g uyen [KAN93J sugieren los siguientes atributos de
b in ació n de entrada. un a «buena» prueba:
. El ingeniero de pruebas puede con tro lar directam ente 1. U n a b u e n a p ru e b a tie n e u n a a lta p ro b a b ilid ad de
los estados y las variables del hardw are y del software. encontrar un error. P ara alcanzar este objetivo, el res
p o n sab le de la p ru e b a debe en te n d er el softw are e
. L os fo rm ato s de las en trad as y los re su lta d o s son
in te n ta r d e sa rro lla r u n a im a g e n m e n ta l de cómo
consistentes y estructurados.
po d ría fallar el softw are.
. L as p ruebas p u ed en especificarse, autom atizarse y
2. U na buen a p rueba no debe ser redundante. El tiempo
reproducirse convenientem ente. y los recursos para laá pruebas son lim itados. No hay
C a p a c id a d de descom posición. « C o n tro la n d o el m otivo para realizar una p ru eb a que tiene el mismo
ám bito de las pruebas, p odem os aislar m ás rápidam ente propósito que otra. Todas las pruebas d eb en an tener
los p roblem as y llev ar a cabo m ejores p ruebas de re g re un propósito diferente (incluso si es sutilm ente dife
sión.» rente). P o r e je m p lo , un m ó d u lo del softw are de
. E l sistem a so ftw a re e s tá c o n stru id o co n m ó d u lo s H ogarSeguro (estudiado en anteriores capítulosjestá
independientes. diseñado para reconocer u n a contraseña de usuario
• L o s m ó d u lo s del so ftw are se p u e d e n p ro b a r in d e para activar o desactivar el sistem a. E n un esfuerzo
p endientem ente p o r descubrir un error en la entrada de la contraseña,
el responsable de la p rueba diseña una serie de prue
S im plicidad. «C uanto m enos h ay a que probar, m ás
bas que introducen una secuencia de contraseñas. Se
rápidam ente p odrem os probarlo.»
introducen contraseñas válidas y no válidas (secuen
• S im plicidad funcional (por ejem plo, el conjunto de cias de cu atro núm eros) en pruebas separadas. Sin
características es el m ínim o n ecesario p ara cum plir em bargo, cad a contraseña válida/no válida debería
los requisitos). analizar un m odo diferente de fallo. P or ejem plo, la
« Sim plicidad estructural (por ejem plo, la arquitectura contraseña no válid a 1234 no d eb e ría ser aceptada
es m odularizada para lim itar la propagación de fallos). por un sistem a program ado para reconocer 8080como
• S im plicidad del código (por ejem plo, se adopta un la contraseña correcta. Si 1234 es aceptada, tenemos
estándar de código p ara facilitar la inspección y el presente un error. O tra prueba, digam os 1235,tendría
m antenim iento). el m ism o propósito que 1234 y es, p o r tanto, redun
E stab ilid ad . « C uanto m enos cam bios, m en os in te dante. Sin em bargo, la entrada no válida 8081 u 8180
tiene una sutil diferencia, intentando dem ostrar que
rrupciones a las pruebas.»
existe un error para las contraseñas «parecidas»perc>
• L os cam bios del softw are son infrecuentes.
no idénticas a la contraseña correcta.
« L os cam bios del softw are están controlados.
3. U na buena prueba debería ser «la m ejo r de la cose
« L os cam bios del softw are no in validan las pruebas cha» [K A N 93], E n un grupo de pruebas que tienen
existentes. propósito sim ilar, las lim itaciones de tiem po y recur
« El softw are se recu p era b ien de los fallos. sos pueden abogar p o r la ejecución de sólo un sub-
F acilid ad de com prensión. « C uanta m ás in form a conjunto de estas pruebas. En tales casos, se debena
ción tengam os, m ás inteligentes serán las pruebas.» em p lear la p rueba que ten g a la m ás alta probabili
• El diseño se h a entendido perfectam ente. dad de descubrir una clase entera de errores.
4. U na buen a p rueba no debería ser ni dem asiado sen
• L as d ependencias en tre los com ponentes internos,
cilla ni dem asiad o com pleja. A u nque es posible a
externos y com partidos se han entendido perfectamente.
veces com binar una serie de pruebas en un caso de
www.FreeLibros.org
« Se h an com unicado los cam b ias del diseño.
prueba, los posibles efectos secundarios de este enfo
• L a d o c u m e n ta c ió n té c n ic a es in s ta n tá n e a m e n te que p u ed e n e n m a sc a ra r erro re s. E n g eneral, cada
accesible. p ru eb a debería realizarse separadam ente.
284
CAPITULO 17 T É C N I C A S DE P R U E B A D EL S O F T W A R E
I D IS E ftO d e c a s o s d e p r u e b a
El diseño de p ruebas p ara el softw are o p ara otros pro condiciones y/o bucles. Se puede exam inar el «estado del
ductos de ingeniería puede requerir tanto esfuerzo com o program a» en varios puntos para determ inar si el estado
el propio diseño inicial del pro d u cto . S in em bargo, los real coincide con el esperado o m encionado.
ingenieros del so ftw are,p o r razones que y a hem os trata
do, a m enudo tratan las pruebas com o algo sin im portan
cia, desarrollando casos de p ru eb a que « p arezcan
adecuados», pero que tien en p o ca g arantía de ser co m
CLAVE
pletos. R ecordando el objetivo de las pruebas, debem os I a s pruebas de caja blanca son diseñadas después
diseñar p ruebas que ten g an la m a y o r pro babilidad de de que exista un diseño de componente (o código fuente).
El detalle de lo lógica del programa debe estar disponible.
encontrar el m ayor núm ero de errores con la m ínim a can
tidad de esfuerzo y tiem po posible.
A prim era vista parecería que una prueba de caja blan
ca m uy profunda nos llevaría a tener «program as cien por
Qc/ta: cien correctos».T odo lo que tenem os que h acer es definir
baste uno sola regla pora el diseño de casos todos los cam inos lógicos, desarrollar casos de p rueba que
,de pruebo: cubrir todos les posibilidades, sin hacer los ejerciteny evaluar los resultados, es decir, generar casos
demasiados casos de pruebo. de prueba que ejerciten exhaustivamente la lógica del pro
TmmwoYamaura grama. D esgraciadam ente, la prueba exhaustiva presenta
ciertos problem as logísticos. Incluso para pequeños p ro
gram as, el núm ero de cam inos lógicos posibles puede ser
Cualquier producto de ingeniería (y de m uchos otros enorm e. Por ejem plo, considere un program a de 100 líne
campos) puede probarse de una de estas dos formas: (1) as de código en lenguaje C. D espués de la declaración de
conociendo la función específica p ara la que fue diseña algunos datos básicos, el program a contiene dos bucles
do el pro d u cto , se p u ed en llev ar a cab o pruebas que que se ejecutan de 1 a 20 veces cada uno, dependiendo de
demuestren que cada función es com pletam ente operati las condiciones especificadas en la entrada. D en tro del
va y, al m ism o, tiem po buscando errores en cada función; bucle interior, se necesitan cuatro construccionesif-then-
(2) conociendo el funcio n am ien to d el producto, se pue else. ¡Existen aproximadamente 1014 cam inosposibles que
den desarrollar pruebas que aseguren que «todas las pie se pueden ejecutar en este programa!
zas encajan», o sea, que la o peración in terna se ajusta a
las especificaciones y que todos los com ponentes in ter
nos se han com probado de fo rm a adecuada. E l prim er
enfoque de prueba se denom ina prueba de caja negra y el
segundo, prueba de caja blanca. No es posible una prueba exhaustiva sobre todos
los caminos del programa, porque el número de caminos
es simplemente demasiado grande.
c )£ c
Referencia Web
’e b f , Para poner de m anifiesto el significado de este núm e
ro, supongam os que hem os desarrollado un procesador
Lo página de técnicas de prueba es una excelente fuente
de información sobre los métodos de prueba: de pruebas m ágico («m ágico» porque no existe tal pro
www.testworks.com/News/TTN-Online/ cesador) para hacer una prueba exhaustiva. El procesador
puede desarrollarun caso de prueba, ejecu tarlo y evaluar
Cuando se consid era el softw are de com putadora, la los resultados en un m ilisegundo. Trabajando las 24 horas
prueba de caja negra se refiere a las p ruebas que se lle del día, 365 días al año, el procesadortrabajaría durante
van a cabo sobre la interfaz del software. O sea, los casos 3 1 7 0 años para p robar el program a. E sto irrem ediable
de prueba preten d en d e m o stra r que las fu n cio n es del m ente causaría estragos en la m ayoría de los planes de
software son operativas, que la entrad a se acepta de fo r desarrollo. L a p rueba exhaustiva es im posible para los
ma adecuada y que se produce un resultado co rrecto, grandes sistem as software.
así como que la integridad de la in fo rm a ció n ex tern a La prueba de caja blanca, sin embargo, no se debe dese
(por ejemplo, archivos de datos) se m antiene. U na p ru e char com o im practicable. Se pueden elegir y ejercitar una
ba de caja n eg ra exam in a algunos aspectos del m odelo serie de cam inos lógicos im portantes.
fundamental del sistem a sin te n e r m u ch o en cuenta la Se pueden co m p ro b ar las estru ctu ras de datos m ás
estructura ló g ica interna del softw are. im portantes para verificar su validez. Se pueden co m b i
La p ru eb a de caja blanca del softw are se b asa en el nar los atributos de la p rueba de caja blanca así com o los
www.FreeLibros.org
minucioso exam en de los detalles procedim entales. Se de caja negra, para llegar a un m étodo que valide la inter
comprueban los cam inos lógicos del software proponiendo faz del softw are y asegure selectivam ente que el funcio
casos de p ru eb a que ejerciten conjuntos específicos de nam iento interno del softw are es correcto.
285
IN GE NI ER ÍA DEL SOF TW AR E . UN E N F O Q U E P R Á C T I C O
L a p ru eb a de caja blanca, d enom inada a veces prueba cedim iento habitual tiende a hacerse m ás comprensi
de caja de cristal es un m étodo de d iseñ o de casos de ble (y bien exam inado), m ientras que el procesamiento
prueba que usa la estructura de control del diseño pro de «casos especiales» tiende a caer en el caos.
cedim ental para o btener los casos de prueba. M ediante • A m enudo creem os que un cam ino lógico tiene pocas
los m étodos de p ru eb a de caja blanca, el ingeniero del p o sib ilid a d e s d e e je c u ta rse c u a n d o , d e hecho, se
softw are puede o btener casos de p ru eb a que (1) garan puede ejecutar de fo rm a norm al. El flujo lógico de
ticen que se ejercita por lo m enos una vez todos los cam i un program a a veces no es n ad a intuitivo, lo que sig
nos independientes de cada m ódulo; (2) ejerciten todas n ifica que nuestras suposiciones intuitivas sobre el
las decisiones lógicas en sus vertientes v erd ad era y fal flujo de control y los datos nos pueden llevar a tener
sa; (3 ) ejecuten tod o s los bucles en sus lím ites y con sus e rro re s d e d ise ñ o que sólo se d e sc u b re n cuando
lím ites operacionales; y (4)ejerciten las estructuras inter com ienza la p ru eb a del cam ino.
nas de datos p ara asegurar su validez. • L os errores tipográficos son aleatorios. Cuando se
E n e ste m o m e n to , se p u ed e p la n te a r u n p re g u n ta traduce un p rogram a a có d ig o fu ente en un lenguaje
razonable: ¿P or qué em plear tiem po y energía p reo cu de program ación, es m u y probable que se den algu
p án d o se de (y p ro b a n d o ) las m in u c io sid a d e s ló gicas nos errores de escritura. M uchos serán descubiertos
cu a n d o p o d ría m o s e m p le a r m e jo r el e sfu e rz o ase g u p o r los m eca n ism o s de co m p ro b ac ió n de sintaxis,
rando que se h an alcanzado los requisitos del p ro g ra p e ro o tro s p e rm a n e c e rá n sin d e te c ta r h asta que
m a? O, d ich o de o tra fo rm a, ¿p o r qué no em p leam o s com ience la prueba. E s igual de probable que haya
todas n uestras energías en la pru eb a de caja negra? La un erro r tipográfico en un oscuro cam ino lógico que
resp u e sta se en c u e n tra en la n a tu ra le z a m ism a de los en un cam in o principal.
defectos del softw are (por ejem plo, [JO N 81]):
• Los errores lógicos y las su posicionesincorrectas son
inversam ente proporcionales a la probabilidad de que Q p a :
se ejecute un cam ino del program a. L os errores tie n w de en los esquinas
den a introducirse en nuestro trabajo cuando diseña ^ É i ^ l m e n los límites.
m os e im p lem en tam o s fu n cio n es, c o n d icio n es o ím p i* *
controles que se encuentran fuera de lo normal. El pro-
17.4 PRUEBA DEL CAMINO BÁ SICP.
L aprueba del camino básico es una técnica de prueba I7 .4 .L N o t a c i ó n d e g r a f o d e f l u j o

de caja b lanca propuesta inicialm ente p o r Tom M cC a- A n tes de c o n sid e ra r el m é to d o del c a m in o básico se
be [M C C 76], El m étodo del cam ino b ásico p erm ite al debe introducir u n a sencilla notación para la represen
diseñador de casos de p ru eb a o btener un a m ed id a de la tación del flujo de co n tro l, d en o m in ad a grafo de flujo
com plejidad ló g ica de un diseño p rocedim ental y usar {o grafo del program a) . El grafo de flujo representa el
esa m ed id a co m o g uía para la d efinición de un conjun flujo de control lógico m ediante la notación ilustrada en
to básico d e cam inos de ejecución. L os casos de p ru e la F igura 17.1. C ada construcción estructurada (Capí
ba obtenidos del conjunto básico g arantizan que durante tu lo 16) tien e su co rresp o n d ien te sím bolo en el grafo
la p ru eb a se ejecuta p o r lo m en o s u n a vez cada senten del flujo.
cia del program a.
Construcciones estructurales en forma de grafo de flujo:
Según-sea
(Case)
Dibujo un f o f o de flujo cuando lo lógica de lo estructura
de control de un módulo seo complejo. El grofo de flujo te
permite trazar más fácilmente los cominos del progromo.
Donde cada círculo representa una o más sentencias, sin bifurcaciones, P ara ilustrar el uso de un grafo de flujo, considere
en LDP o código fuente m os la representación del d iseño procedim ental en la
FIG U R A 1 7 .1 . N otación de grafo de flujo. Figura 17.2a. E n ella, se usa un diagram a de flujo para
www.FreeLibros.org
3 Realmente, el método del camino básico se puede llevar a cabo sin
usar grafos de flujo. Sin embargo, sirve como herramienta Útil para
ilustrar el método.
286
CAPITULO 17 T É C N I C A S DE PRUEBA DEL S OF TW AR E
representar la estructura de control del program a. E n la C uando en un d iseño procedim ental se en cu en tran
Figura 17,2b se m u e stra el g rafo de flu jo co rre sp o n condiciones com puestas, la generación del grafo de flu-
diente al diagram a de flujo (suponiendo que no hay co n j o se hace un poco m ás com plicada. U na condición co m
diciones co m p u estas en lo s ro m b o s de d e c isió n del p u esta se da c u a n d o aparecen u n o o m á s o p e ra d o re s
diagrama de flujo). (OR, A N D , N A N D , Ñ O R lógicos) en una sentenciacon-
En la F igura 17,2b, cad a círcu lo , d en o m in ad o nodo dicional. E n la Figura 17.3 el segm ento en L D P se tra
del grafo de flujo, represen ta u n a o m ás sentencias produce en el grafo de flujo anexo. Se crea un n o d o aparte
cedimentales. U n solo n o d o puede corresponder a una p o r cada una de las condiciones a y b de la sentencia SI
secuencia de cuadros de p roceso y a un ro m bo de d eci a O b. C ada n o d o que contiene una condición se d e n o
sión. Las flechas del grafo de flu jo , denom inadas a ris m ina nodo p re d ic a d o y está caracterizado po rq u e dos o
tas o e n la c e s, re p re se n ta n flu jo de c o n tro l y son m ás aristas em ergen de él.
análogas a las flechas del d iag ram a de flujo. U na aris
ta debe term in ar en un n o d o , in clu so au nque el nodo
Nodo
no represente n in g u n a sen ten cia p ro c e d im en ta l (p o r predicado
ejem plo, v éase el sím b o lo p a ra la c o n stru c c ió n
S i-en to n ces-si-n o ). L as áreas delim itadas p o r aristas
y nodos se d enom inan regiones. C u an d o c o n ta b iliz a IF a OR b
mos las regiones incluim os el área e x te rio r del grafo, Then Drocedimiento x
contando com o otra reg ió n m ás4. Else procedim iento y
ENDIF
F IG U R A 1 7 .3 . Lógica com puesta.
17.4.2. C o m p l e j i d a d c i c l o m á t i c a
La com plejidad ciclom ática es una m étrica del so ftw a
re que proporciona una m edición cuantitativa de la co m
p le jid a d ló g ica de un p rogram a. C uando se u sa en el
co n tex to del m éto d o de p ru e b a del cam ino b ásico , el
v alor calcu lad o co m o com plejidad ciclom ática define
el núm ero de cam inos independientes del conjunto b á si
co de un program a y nos da un lím ite superior para el
núm ero de pruebas que se deben realizar para asegurar
que se ejecuta cada sentencia al m enos una vez.
a) Diagrama de flujo
U n ca m in o in dependiente es c u alq u ier cam in o del
program a que introduce, p o r lo m enos, un nuevo co n
ju n to de sentencias de proceso o una nueva condición.
E n térm inos del grafo de flujo, un cam ino independiente
está constituido p o r lo m enos p o r una arista que no haya
sido recorrida anteriorm ente a la definición del cam ino.
P or ejem plo, para el grafo de flujo de la Figura 17.2b,
un conjunto de cam inos independientes sería:
cam in o 1: 1-11
cam in o 2: 1-2-3-4-5-10-1-11
cam in o 3: 1-2-3-6-8-9-10-1-11
cam ino 4: 1-2-3-6-7-9-10-1-11
Fíjese que cada nuevo cam ino introduce una nueva

arista. El cam ino
1-2-3-4-5-10-1-2-3-6-8-9-10-1-11
no se considera un cam ino independiente,ya que es sim
plem ente una com binación de cam in o s y a esp e c ific a
FIG U R A 17.2 . dos y no recorre ninguna nueva arista.
www.FreeLibros.org
4 En la Sección 17.6.1 viene un estudio m as detallado de los gratos
y su empleo en las pruebas.
287
I N GEN IE RÍ A DEL S O F TW A RE . UN EN F O Q U E PR AC T I C O
P o r tan to , la co m p le jid a d ciclo m á tic a del grafo de

ONSEIÓ ^ flujo de la F igura 17.2b es 4.
Lo complejidad cidomática es una métrica útil para Es m ás, el v alor de V(G) nos da un lím ite superior
predect las módulos que san más propensas a error. para el núm ero de cam inos independientes que compo
Puede ser usada tonto para planificar pruebas cam a nen el co n ju n to básico y, co n secu en tem en te, un valor
para diseñar casas de prueba. lím ite superior para el núm ero de pruebas que se deben
diseñar y ejecutar para garantizar que se cubren todas
L os cam inos 1,2, 3 y 4 definidos anteriorm ente co m las sentencias del program a.
ponen un con ju n to básico p ara el grafo de flu jo de la
Figura 17.2b. Es decir, si se pueden d iseñar p ruebas que 17.4.3. O b te n c ió n d e c a s o s d e p r u e b a
fuercen la ejecución de esos cam inos (un conjunto bási
El m étodo de p ru eb a de cam ino básico se puede apli
co), se garan tizará que se h ab rá ejecutado al m en os una
car a un diseño procedim ental detallado o a un código
vez cada sentencia del p ro g ram a y que ca d a condición
fuente. E n e sta sección, p rese n tarem o s la p ru eb a del
se hab rá ejecutado en sus vertientes v erd ad era y falsa.
cam in o básico co m o u n a serie de pasos. U sarem os el
S e d eb e h a c e r h in c a p ié en que el co n ju n to b ásico
procedim iento m edia, representado en L D P en la Figu
no es Unico. D e h ech o , de un m ism o d iseñ o p ro ced i-
ra 17.4, com o ejem plo para ilustrar todos los pasos del
m e n ta l se p u e d e n o b te n e r v a rio s c o n ju n to s b á sic o s
m étodo de diseño de casos de prueba. Se puede ver que
diferen tes.
m edia, aunque con un algoritm o extrem adam ente sim
ple, contiene condiciones com puestas y bucles.
| ¿Cómo se cálculo
f - la complejidad titlom átita?
¿C óm o sabem os cuántos cam inos hem os de buscar?

Q c ita:
Errar es humono, encontrar unfallo, divino.
El cálculo de la com plejidad ciclo m ática nos da la re s
StoÉwt t e »
puesta. L a com plejidad ciclo m ática e stá b asad a en la
teoría de grafos y nos da una m étrica del softw are extre
m adam ente Útil. L a com plejidad se puede calcu lar de
tres form as: 1. U sando el diseño o el código como base, dibujamos
el co rresp o n d ien teg rafo de flujo. C ream os un grafo
1. El n ú m ero de regiones del g rafo de flu jo co incide
usando los sím bolos y las norm as de construcción pre
con la com plejidad ciclom ática.
sentadas en la Sección 16.4.1. R efiriéndonos al LDP
2. L a co m p lejid ad ciclo m ática, V(G), de un g rafo de de m edia de la F igura 17.4, se crea un grafo de flujo
flujo G se define com o. num erando las sentencias de L D P que aparecerán en
V (G ) = A - N + 2 los correspondientes nodos del grafo de fu jo . El corres
pondiente grafo de flujo aparece en la Figura 17.5.
A
donde es el núm ero de aristas del grafo de flujo y
N es el núm ero de nod o s del m ism o.
PROCEDURE media;
3. L a co m p le jid a d ciclo m ática, V(G), de u n g rafo de * E s te p r o c e d im ie n to c a lc u la la m e d ia d e 1 0 0 o m e n o s
núm eros que se encuentren entre unos lim ites;
flujo G tam b ién se define com o ta m b ié n calcula el to ta l de entradas y el total
de núm eros válidos.
V (G ) = P + 1
donde P es el núm ero de n odos p redicado co n ten i INFERFACE RETURNS m edia, to ta l. entrada, total. válido;
INTERFACE ACEPTS valor, m ínim o, m áxim o;
dos en el grafo de flujo G.
T Y P E v a lo r [1:100] IS S C A L A R A R R A Y ;
T Y P E m e d ia , to ta l, e n tra d a , to ta l, v á lid o ;
M ín im o , m á x im o , s u m a IS S C A L A R :
% /P E i IS IN T E G E R ;
2
C A VE - to ta l, e n tr a d a = to ta !, v á lid o = 0;
j s u m a =0;
I a complejidadciclomática dátente el número |_ D O W HILE V A L O R [ i] < > - 9 9 9 a n d to t a l e n tr a d a < 1 0 0 3
4 ► Incrementar t o t a l e n tr a d a e n 1;
de casos de prueba que deben epcutese para garantizar IF v a lo r [ i] > = m ín im o A N D v a lo r [ i] < = m axtm o 6
que Ocfes las sentencias de un componerte 5 r T H E N in c r e m e n ta r to ta l.v á lid o en 1;
s u m a = s u m a + v a i o r [i] ;
han sido p o te te al menos una vez. L E L S E ig norar
Te n d if
8
[jncrementar i en 1 ;
R efiriéndonos de nuevo al grafo de flujo de la F ig u Í ENODO
ra 17.2b, la com plejidad ciclom ática se puede calcular If t o t a l v a lid o > 0 10
TF IE N m e d ia = s u m a /to ta l v a lid o ,
m ediante cualq u iera de los anteriores algoritm os: 1 2 — -► E L S E m e d ia = - 9 9 9 ,
www.FreeLibros.org
B e n d if
1. el grafo de flujo tiene cuatro regiones END media
2. V (G ) = 1 1 aristas - 9 nod o s + 2 = 4 F IG U R A 1 7.4. LDP para diseño de pruebas con nodos
3. V (G ) = 3 nod o s p redicado + 1 = 4. no identificados.
288
CAPÍTULO 17 T É C N I C A S DE PRUE BA DEL S O F T W A R E
2 Determ inam os la com plejidad ciclom ática del m alm ente m erece la p en a id en tificar los n o d o s p re
grafo de flujo resultante. La co m p lejidad ciclom á d ic ad o p a ra que sea m ás fácil ob ten er lo s caso s de
tica, V(G), se d eterm in a aplicando uno de los algo prueba. E n este caso , los n o dos 2, 3, 5, 6 y 10 son
ritmos d escritos en la S ección 17.5.2.. Se debe ten er n o d o s predicado.
en cuen ta que se p u ede d eterm in ar V(G) sin d e sa 4. Preparamos los casos de prueba que forzarán la
rrollar el grafo de flujo, co ntando to d as las sen ten ejecución de cada cam ino del conjunto básico.
cias co n d icio n ales del L D P (para el p rocedim iento D ebem os escoger lo s datos de form a que las co n d i
media las co n d icio n es co m p u estas cu entan com o 2) ciones de los no d o s p redicado estén adecuadam ente
y añadiendo 1. establecidas, con el fin de co m probar cad a cam ino.
En la F ig u ra 17.5, Los casos de prueba que satisfacen el conjunto básico
V (G ) = 6 reg io n es p reviam ente descrito son:
V (G ) = 1 7 aristas - 13 n o d o s +2 = 6
Caso de prueba del camino 1:
V (G ) = 5 nodos p red icad o + 1 = 6
v a lo r (k) = entrada válida, donde k < i definida a con
tinuación
v a lo r (íj = - 9 9 9 , donde 2 <= i <= 100
resultados esperados: m e d ia co rre c ta sobre lo s k
v alores y to tales adecuados.
N ota: el cam ino 1 no se puede p ro b ar p o r sí solo;
debe ser p robado com o parte de las pruebas de los
cam inos 4, 5 y 6.
los ingenieros del software subestiman bastante

el número de pruebas necesarias para verificar
Manya Oald y Osarles Unwin

v a lo r (1) = - 9 9 9
resultados esperados: m e d ia = - 9 9 9 ; o tro s to tale s
con sus v alores iniciales
intento de p ro cesar 101 o m ás valores
FIGURA 17.5. Grafo de flujo del procedimiento media. los prim eros 100 valores deb en ser válidos
resultados esperados: igual que en el caso
3. Determinamos un conjunto básico de cam inos de prueba 1
linealmente independientes. El v a lo r de V (G ) nos
da el núm ero de cam inos linealm ente in d ep en d ien
tes de la estru ctu ra de control del p rogram a. E n el v alo r (i) = entrada válid a donde i < 100
caso del p ro ced im ien to m edia, hay que especificar v alo r ( k) < m ínim o, para k < i
seis cam inos: resultados esperados: m e d ia co rre c ta sobre lo s k
cam in o 1: 1-2-10-11-13 v alores y to tales adecuados
cam ino 2: 1-2-10-12-13 Caso de prueba del cam ino 5:

v alo r (i) = entrada válid a donde i < 100
cam in o 3: 1-2-3-10-11-13
v alo r (k) > m áxim o, para k <= i
cam in o 4: 1-2-3-4-5-8-9-2-...
resultados esperados: m e d ia c o rre c ta sobre lo s n
cam in o 5 : 1-2-3-4-5-6-8-9-2-... valores y to tales adecuados
cam in o 6: 1-2-3 -4 -5 -6 -7 -8 -9 -2-... Caso de prueba del camino 6:
www.FreeLibros.org
L os p u n to s su sp e n s iv o s (...) que sig u en a los v a lo r (i) = entrada válid a donde i < 100
cam inos 4, 5 y 6 in d ican que cu alq u ier cam in o del resultados esperados: m e d ia co rre c ta so b re lo s n
resto de la estru ctu ra de con tro l es aceptable. N o r valores y to tales adecuados
289
INGE NIE RÍA DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
E je c u ta m o s c a d a c a so de p ru e b a y c o m p a ra m o s • los recu rso s req u erid o s du ran te el recorrido de un

los re su lta d o s o b te n id o s co n los e sp e ra d o s. U n a vez enlace.
term in ad o s to d o s los c a so s de p ru eb a, el resp o n sab le P ara ilu stra rlo , u sarem o s la fo rm a m ás sim ple d e
de la p ru e b a p o d rá e s ta r se g u ro de q u e to d a s las s e n peso, que indica la existencia de conexiones ( O ó 1).La
ten cias del p ro g ra m a se h a n e je c u ta d o p o r lo m enos m atriz de grafo de la F igura 17.6 se rehace tal y como
u n a vez. se m u estra en la F igura 17.7. Se h a reem plazado cada
E s im p o rta n te d a rse c u e n ta d e q u e a lg u n o s c a m i letra p o r un 1, indicando la existencia de una conexión
n o s in d e p e n d ie n te s (p o r e je m p lo , e l c a m in o 1 de (se h a n e x c lu id o los c ero s p o r cla rid a d ). C uando se
n u e stro e je m p lo ) n o se p u e d e n p ro b a r d e fo rm a a is representa de esta form a, la m atriz se denom ina m otriz
lad a . E s d e c ir, la c o m b in a c ió n d e d a to s re q u e rid a de conexiones. .
p a ra re c o rre r el c a m in o n o se p u e d e c o n s e g u ir co n
el flu jo n o rm a l del p ro g ra m a . E n ta le s c a s o s , e sto s
c a m in o s se h a n d e p ro b a r c o m o p a rte de o tra p ru e
b a de cam in o .
17.4.4. M a tric e s d e g r a f o s
E l p ro c e d im ie n to p a ra o b te n e r e l g ra fo d e flu jo , e
in c lu so la d e te rm in a c ió n de u n c o n ju n to de c a m in o s
básico s, es su scep tib le de ser m ecan izad o . P ara d e s a
rrollar u n a h erram ien ta softw are que ayude en la pru e
b a d e l c a m in o b á s ic o , p u e d e se r b a s ta n te Útil u n a
e stru c tu ra de d a to s d e n o m in a d a m a triz de grafo.
U n a m a triz de g ra fo es u n a m a triz c u a d ra d a cu y o
ta m a ñ o (es decir, el n ú m e ro de fila s y de c o lu m n as)
Grafo de flujo Matriz del grafo
es ig u al al n ú m ero de n o d o s d el g ra fo de flujo. C ada
fila y c a d a c o lu m n a c o rre sp o n d e a u n n o d o e s p e c ífi F IG U R A 1 7.6. M atriz del grafo.
co y las entradas de la m atriz co rresponden a las co n e
x io n e s (aristas) e n tre los n odos. E n la F ig u ra 17.6 se
m u e stra u n se n c illo eje m p lo de u n g ra fo de flu jo con E n la F ig u ra 17.7, c a d a fila c o n d o s o m ás entra
su c o rre sp o n d ie n te m a triz de g ra fo [B E I90], d a s r e p r e s e n ta u n n o d o p re d ic a d o . P o r ta n to , los
c á lc u lo s a ritm é tic o s que se m u e stra n a la derecha de
E n la figura, c a d a n o d o d el grafo d e flu jo e s tá id en la m atriz de c o n e x io n e s n o s d an o tro n u ev o método
tific a d o p o r u n n ú m e ro , m ien tras que c a d a a rista lo
está p o r su letra. Se sitú a un a e n tra d a en la m atriz p o r de d eterm in ac ió n de la co m p le jid ad ciclom ática (Sec
c a d a c o n e x ió n e n tre d o s n odos. P o r e je m p lo , el nodo c ió n 17.4.2).
B eizer [BEI90] proporciona un tratam iento profun
3 e stá c o n e c ta d o co n el n o d o 4 p o r la a rista b.
do de otros algoritm os m atem áticos que se pueden apli
ca r a las m atrices de grafos. M ediante estas técnicas, el
| i | ¿Qué es una matriz análisis requerido para el d iseño de casos de prueba se
w de grafos y cómo aplicarla puede autom atizar parcial o totalm ente.
en la prueba?
Conectado
H asta aquí, la m atriz de grafo no es n ad a m ás que una
'representación tab u lar del grafo de flujo. Sin em bargo,
añadien d o u np e s o de enlace a cada entrad a de la m atriz, 1 1 1-1=0
la m atriz de grafo se puede convertiren una potente herra
2
m ien ta p ara la ev aluación de la estru ctu ra de control del
prog ram a durante la prueba. El peso de enlace nos da 3 1 i ¡¡ 2 - 1 = 1
inform ación adicional sobre el flujo de control. En su for
m a m ás Sencilla,el peso de enlace es 1 (existe u n a co n e 4 iilllj 1 1; 2 - 1 = 1
xión) ó O (no existe conexión). A los pesos de enlace se
les puede asignar otras p ropiedades m ás interesantes: 5 IIÉlll ¡Sil 2-1 =1
..... 3+1=*
« la probabilidad de que un enlace (arista) sea ejecutado; Matriz de grafo
. el tiem po de p rocesam iento asociado al recorrido de
www.FreeLibros.org
un enlace; Complejidad
. la m e m o ria re q u e rid a d u ra n te el re c o rrid o de un ciclomática
enlace; y FIG URA 1 7 .7 . Matriz de co n ex io n es.
290
f c u u P R U E B A D E L A E S T R U C T U R A D E C O M T R O L : ___
La técnica de pru eb a del cam in o b ásico descrita en la El m étodo de lap ru e b a de condiciones se centra en la
Sección 17.4 es una de las m uchas técnicas para la p ru e prueba de cada una de las,condiciones del program a. Las
ba de la estru ctu ra de control. A u n q u e la p ru e b a del estrategias de p ru eb a de condiciones (tratadas posterior
cam ino b á sic o es sencilla y altam en te efectiv a, no es m ente en este capítulo) tienen, gen eralm en te,d o s v en ta
suficiente p o r sí sola. E n e s ta secció n se tra tan otras ja s. L a prim era, que la c o b e rtu ra de la p ru e b a de u n a
variantes de la p ru e b a de e stru c tu ra de control. E stas condición es sencilla. L a segunda, que la cobertura de la
variantes am plían la cobertura de la p ru eb a y m ejoran p ru eb a de las condiciones de un p rogram a da una o rien
la calidad de la p ru eb a de c a ja blanca. tación para generar pruebas adicionalesdel program a.
El propósito de la p ru eb a de condiciones es detectar,
no sólo los errores en las condiciones de un program a,
17.5.1. P r u e b a d e c o n d ic ió n ’
sino tam bién otros errores en dicho program a. Si un co n
ju n to de p ru e b a s de un p ro g ra m a P es e fe c tiv o p a ra
d e te ctar erro res en las c o n d icio n es que se e n cu en tran
en P, es probable que el conjunto de pruebas tam bién sea
los erroresson muchomós comunes en el entorno efectiv o para d e tecta r otros erro res en el p ro g ram a P.
de los condicioneslógicas que en los sentencias de A d em ás, si u n a e strateg ia de p ru e b a es e fec tiv a para
proceso secuencial. d etectar errores en una condición, entonces es probable
que d ich a estrategia tam bién sea efectiva para detectar
errores en el program a.
La p r u e b a de c o n d ic ió n e s u n m é to d o de d ise ñ o de Se han propuesto u n a serie de estrategias de prueba
casos de p ru e b a que e je rc ita las c o n d icio n es ló gicas de condiciones. L a p ru e b a de ram ificaciones es, posi
contenidas en el m ó d u lo de un p ro g ram a. U n a co n d i blem en te, la estrategia de prueba de condiciones m ás
ción sim ple es u n a v a ria b le ló g ic a o u n a e x p re sió n sencilla. P ara una condición com puesta C, es necesario
relacional, p o sib le m e n te p re c e d id a c o n un o p e ra d o r ejecutar al m enos una vez las ram as verdadera y falsa
NOT (« i» ). U na expresión relacional to m a la siguien de C y cada condición sim ple de C [M Y E79].
te form a
E , < operador-relacional> E 2
donde E, y E, son e x p resio n es aritm éticas y <opera-

dor-relaciona¡> puede ser alguno de los siguientes: «<», Coda que decides efectuarunapruebade condición,
«<=», «=», «?i» («=» desigualdad), «>», o «>=». U na deberásevaluarcadacondiciónenun intento
por descubrirerrores. ¡Este es unescondrijoideal
condición com puesta e stá form ada p o r dos o m ás con
parabs errores!
diciones sim ples, operadores lógicos y paréntesis. Supo
nemos que los o p erad o res ló g ico s p e rm itid o s en una
condición com puesta in cluyen O R («I»), A N D («& ») y L a p ru e b a del dom inio [W H I80] requiere la realiza
NOT («“'»). A u n a condición sin e x p resio n es relacio- ción de tres o cu atro pruebas para una expresión rela
nales se la den o m in a E xpresión lógica. cional. P ara una expresión relacional de la form a
Por tanto, los tipos posibles de com ponentes en una E, < operador-relaciona¡> E,
condición p u ed en ser: un o p erad o r lógico, una variable
lógica, un p a r de paréntesis lógicos (que rodean a una se requieren tres pruebas, para com probar que el v alor
condición sim ple o com puesta), un o p erador relacional de E, es m ayor, igual o m en o r que el v alo r de E,, re s
o una expresión aritm ética. pectivam ente [H O W 82], Si el < operador-relacional>
Si una co n d ició n es in co rrecta, e n to n c e s es in c o es incorrecto y E, y E 2 son correctos, entonces estas tres
rrecto al m enos un co m p o n en te de la condición. A sí, pruebas garantizan la detección de un e rro r del o p e ra
los tipos de erro res de u n a co n d ició n p u ed en ser los d o r relacional. P ara detectar errores en E , y E 2, la p ru e
siguientes: b a que h ag a el v alo r de E, m ay o r o m en o r que el de E,
• error en o perador lógico (existencia de operadores debe h acer que la diferencia entre estos d o s valores sea
lógicos incorrectos/desaparecidos/sobrantes) lo m ás pequeña posible.
Para una expresión lógica con n variables, habrá que
• error en variable lógica
realizar las 2” pruebas posibles ( n > 0). E sta estrategia
• error en paréntesis lógico puede d etectar errores de un operador, de una variable
• error en o perador relacional y de un paréntesis lógico, pero sólo es p ráctica cuando
• error en expresión aritm ética. el v alo r de n es pequeño.
www.FreeLibros.org
5Las secciones 17.5.1. y 17.5.2. se han adaptado de [TAI89] con per
miso del profesor K.C. Tai.
291
I N GE NI E RI A DEL S O F T W A R E . UN EN F O Q U E P R A C T I C O
Tam bién se pueden o btener p ruebas sensibles a error cio n al, podem os construir un conjunto de restricciones
p a ra e x p re sio n e s ló g icas [F O S 84, T A I87]. P ara una p ara C2 m ediante la m odificación del conjunto de res
expresión ló g ica sin g u lar (una ex p re sió n lógica en la tricciones {(v, v), (f, v), (v, f ) } definido para C,. Obsér
cual cada variable lógica sólo aparece u n a vez) con n vese que «v» para (E, = E 4) im plica «=» y que «f» para
variables lógicas (n > 0), p odem os g enerar fácilm ente (£,. = E 4) im plica «< »o «>». A l reem plazar (v, v) y (f,
un conjunto de pruebas con m en o s de 2" pruebas, de tal v) p o r (v, =) y (f, =), respectivam ente y reemplazando
form a que ese grupo de p ruebas garantice la detección (v, f) p o r (v, <) y (v,>), el conjunto de restricciones resul
de m ú ltiples erro res de operadores ló g ico s y tam bién tante para C, es {(v, =), (f, =), (v, <), (v, >)} .La cobertura
sea efectivo p ara detectar otros errores. del conjunto de restricciones anterior garantizará la detec
T ai [T A I89] su g ie re u n a e s tra te g ia de p ru e b a de ción de errores del operador relacional o lógico en C2.
c o n d ic io n e s q u e se b asa en las té c n ic a s d e sta c a d a s C om o tercer ejem plo, considerem os una condición
an terio rm en te. L a técn ica, d en o m in ad a B R O (p ru e de la form a
ba d el opera d o r re la c io n a /y de ra m ific a c ió n ) , g a ra n
C ,: (E, > E 2) & ( 13 = E4)
tiza la d etección de errores de operadores relaciónales
y de ra m ific a cio n e s en u n a co n d ició n d a d a , en la que donde E ,, E 2, E, y E, son ex p resio n es aritm éticas. Una
to d as las v ariab les ló g icas y o p erad o res relació n ales restric c ió n de c o n d ic ió n p ara C, es de la fo rm a (D¡,
d e la c o n d ic ió n a p a re c e n só lo u n a v e z y n o tie n e n D 2), donde to d o s los I), y D, son >, = o <. Puesto que
v ariab les en com ún. Cj es igual que C, e x c e p to en que la p rim era condi
La estrategia B R O utiliza restricciones de condición ció n sim ple de C, es una ex p resió n rela cio n a l, pode
para una condición C. U na restricción de co n d ició npara m o s c o n stru ir un c o n ju n to d e re stric c io n e s para C¡
C co n n c o n d icio n es sim p le s se d e fin e co m o (D ,, m ed ian te la m o d ific ac ió n del co n ju n to de restriccio
D 2,...,D n), donde D¡ (0 < i < n) es un sím bolo que e sp e nes para C„ obten ien d o
cifica una restricció n sobre el re su lta d o de la i-ésim a
{(>, =), (=, =), (<, =), o , » , ( > . <)}
condición sim ple de la condición C. U na restricción de
condición D para una condición C se cubre o se trata en La cobertura de este conjunto de restricciones garan
una ejecución de C, si durante esta ejecución de C, el tiza rá la d etecció n de erro res de o p e ra d o r relacional
resultado de cada condición sim ple de C satisface la re s en C,.
tricció n correspondiente de D.
P ara una variable lógica B , especificam os una re s 17.5.2. P rueba del flu jo de datos
tricció n sobre el resultado de B, que consiste en que B
El m étodo d e p r u e b a de flu jo de datos selecciona cami
tiene que ser verdadero (v) o falso (f). De form a sim i
nos de prueba de un program a de acuerdo con la ubi
lar, p ara una expresión relacional, se u tilizan los sím
cación de las definiciones y los usos de las variables del
bo lo s >, = y < p ara e sp e c ific ar re stric c io n e s sobre el
program a. Se han estudiado y com parado varias estra
resultado de la expresión.
teg ia s de p ru e b a de flu jo de d ato s (p o r ejem plo,
C om o ejem plo, considerem os la condición
[FR A 88], [N TA 88], [FRA 93]).
C,: Bi & B2 Para ilustrar el enfoque de prueba de flujo de datos,
supongam os que a cada sentencia de un program a se le
donde B , y B, son v ariables lógicas. L a restricción de
asigna un núm ero único de sentencia y que las funcio
condición p ara C¡ es de la form a (D¡, D 2), donde D , y
nes no m odifican sus parám etros o las variables globa
D, son «v» o «f». El v alo r (v, f) es una restricción de
les. Para una sentenciacon S com o núm ero de sentencia,
condición p ara C, y se cubre m ediante la prueba que
hace que el v alo r de B, sea v erdadero y el v alo r de B, DEF(S) = (X I la sentencia S contiene una definición
sea falso. L a estrategia de prueba B R O requiere que el deX }
co n ju n to de re s tric c io n e s {(v, v), (f, v ), (v, f )} sea U SO (S) = {X I la sentencia S contiene un uso deX}
cubierto m ediante las ejecuciones de C,. Si C, es in co
rrecta p o r uno o m ás errores de o perador lógico, p o r lo Si la sentencia S es una sentencia i f o de bucle, su con
m enos un p ar del conjunto de restricciones forzará el ju n to D E F estará vacío y su conjunto U SE estará basa
fallo de C,. do en la condición de la sentenciad. La definición de una
C om o segundo ejem p lo , c o n sid erem o s una c o n d i v aria b le!' en una sentenciad se dice que está viva en una
ción de la form a sentencia S 1 si existe un cam ino de la sentenciad a la sen
tencia S 1 que no contenga otra definición de X.
Ce. B i & ( % = E 4)
donde ffl es una expresión lógica y E, y E, son expre
siones aritm éticas. U n a restricció n de co n d ició n p ara C,
es de la form a ( D,, D2),
donde D,
es «v» o «f» y D, es
www.FreeLibros.org
Es para realista asumir que la prueba del flujo de datas
>, = o <. Puesto que C 2 es igual que C h excepto en que
puede ser usada ampliamente cuando probamos grandes
la segunda condición sim ple de C2 es una expresión rela-
sistemas. En cualquier rasa, puede ser utilizada en oreas
* En ingles, Branch arid Relational Operator del software que sean sospechosos.
292
CAPÍTULO 17 TÉCNIC AS DE PRUEBA DEL S O F T W A R E
U na cadena de definición-uso (o c a d e n a D U ) de una otras cadenas D U se pueden cubrir h acien d o q u e esos

v a ria b le !' tiene la fo rm a [ X , S , S ’], d o n de S y S ’ son cinco cam inos contengan iteraciones del bucle.
números de s e n te n c ia ,!' está en D EF(S) y en U SO (5” ) D ado que las sentencias de un p rogram a e stá n re la
y la definición de X en la sentencia S está viv a en la sen cionadas entre sí de acuerdo con las d efin icio n es d e las
tencia S’. variables, el enfoque de prueba de flujo de datos es efec
U na sencilla estrateg ia de p ru eb a de flujo de datos tivo para la protección contra errores. Sin e m b arg o , los
se basa en req u erir que se cu b ra al m en o s una vez cada problem as de m edida de la cobertura de la p ru e b a y de
cadena DU. E sta estrateg ia se conoce co m o estrategia selección de cam inos de prueba para la p ru e b a d e flujo
de prueba DU. Se ha d em ostrado que la p ru eb a D U no de datos son m ás difíciles que los correspondientes p ro
garantiza que se cubran todas las ram ificaciones de un blem as para la p ru eb a de condiciones.
programa. Sin em b arg o , solam ente no se garantiza el ■
cubrim iento de u n a ram ificació n en situ acio n es raras

17.5.3. P ru eb a d e b u c le s
como las co nstrucciones if-then-else en las que la p a r
te then no tiene ninguna definición de variable y no ex is L os bucles son la pied ra angular de la in m e n sa m a y o
te la parte else. E n esta situación, la p ru eb a D U no cubre ría de los algoritm os im plem entados en softw are. Y sin
necesariam ente la ram a else de la sentencia $superior. em b arg o , les p restam o s norm alm ente p o c a a te n c ió n
Las estrategias de p ru eb a de flujo de datos son Úti cu an d o llevam os a cabo las pruebas del softw are.
les para seleccio n ar cam inos de p ru eb a de un program a
que contenga sentencias if o de bucles anidados. Para i^CONSEJO
ilustrar esto, considerem os la aplicación de la prueba
DU p ara se le c c io n a r cam in o s de p ru eb a para el L D P las estructuras de bucles complejos esotro lugar
propenso o errores, f t r tonto, es muy vallosoreollzai
que sigue:
diseños de pruebas que ejerciten completamente
p ro c x los estructuras bucle
do w h ile C1 L a p rueba de bucles es una técnica de p rueba d e caja

if C2 b lanca que se centra exclusivam ente en la validez d e las
then construcciones de bucles. Se pueden definir cu atro c la
ifC 4 ses diferentes de bucles [BEI90]: bucles simples, bucles
t h e n B4;
concatenados, bucles anidados y bucles no estructura
dos (Fig. 17.8).
else B5;
endi f; B u c le s s im p le s . A los bucles sim ples se les debe apli
else c a r el siguiente co n ju n to de p ru eb as, d o n d e n e s el
i f C3 núm ero m áxim o de pasos perm itidos p o r el bucle:
then b 2 ; 1. p asar p o r alto totalm ente el bucle
else B3 ; 2. p a sar una sola vez p o r el bucle
endi f; 3. p asar dos veces p o r el bucle
endi f; 4 . hacer m pasos p o r el bucle con m < n
enddo; 5. hacer n - 1, n y n+l pasos p o r el bucle
B6;
end p r o c ;
Para aplicar la estrateg ia de p ru eb a D U p ara seleccio

nar caminos de pru eb a del diag ram a de flujo de control,
necesitamos co n o cer las d efiniciones y los usos de las
variables de cada condición o cada bloque del LDP. A su
mimos que la variable X es defin id a en la Últim a sen
tencia de los b loques B 1, B 2, B3, B 4 y B5, y que se usa
en la prim era sentencia de los b loques B 2, B 3, B4, B5
y B 6. La estrateg ia de p ru eb a D U requiere una e je c u
ción del cam ino m ás corto de cada B¡, 0 < i < 5, a cada
Bj, 1< j < 6. (Tal pru eb a tam b ién cubre cualquier uso de simples anidados
la variable!' en las co ndiciones C 1, C 2 , C 3 y C4). A u n Bucles
que hay veinticinco cadenas D U de la variable X, sólo concatenados
www.FreeLibros.org
necesitamos cinco cam inos p ara cubrir la cadena DU. Bucles no
La razón es que se necesitan cinco cam inos para cubrir estructurados
la cadena D U de X desde B¡, 0 < i < 5, h asta B 6, y las F IG U R A 1 7.8. Clases de bucles.
293
Bucles anidados. Si extendiéram os el enfoque de prue B ucles concatenados. L os bucles concatenados se

ba de los bucles sim ples a los bucles anidados, el núm ero pueden p ro b ar m ediante el enfoque anteriorm ente defi
de posibles pruebas aum entaría geom étricam ente a m edi n id o para los bucles sim ples, m ien tras cad a uno de los
d a que aum enta el nivel de anidam iento. E sto llevaría a b u c le s sea in d e p e n d ie n te del resto . S in em bargo, si
un núm ero im practicablede pruebas. Beizer [BEI90] sugie hay d o s b u cles c o n c a te n ad o s y se usa el controlador
re un enfoque que ayuda a reducir el núm ero de pruebas: del bu cle 1 co m o v a lo r in icial del bu cle 2, entonces
1. C om enzar p o r el bucle m ás interior. E stablecer o co n los b u c les n o son ind ep en d ien tes. C u an d o los bucles
figurar los dem ás b ucles co n sus v alores m ínim os. no son in d ep en d ien tes, se rec o m ien d a u sa r el enfoque
ap lic a d o p a ra los b u cle s anidados.
2. L lev ar a cab o las p ruebas de b ucles sim ples p ara el
bucle m ás interior, m ientras se m antienen los parám e
tros de iteración (por ejem plo, con tad o r del bucle) de
los b ucles externos en sus v alores m ínim os. A ñadir
otras pruebas p ara valores fuera de rango o excluidos. No debes probar los bucles no estructurados, Rediséñalos.
3. P ro g resar h acia fu era, llevando a cab o p ruebas para
el siguientebucle, pero m anteniendo tod o s los bucles B ucles no estru ctu rad os. S iem p re que sea posi
externos en sus v alores m ínim os y los d em ás bucles ble, esta c lase de b u cles se d e b e n re d iseñ a r para que
anidados en sus v alores «típicos». se a ju s te n a las c o n s tru c c io n e s d e program ación
4. Continuar hasta que se hayan probado todos los bucles. e stru c tu ra d a (C a p ítu lo 1 6 ).
L a s p r u e b a s de caja negra, tam b ién d enom inada p r u e • ¿Es el sistem a particularm ente sensible a ciertos valo
ba de com portam iento, se centran en los requisitos fu n res de entrada?
cio n ales del softw are. O sea, la p ru e b a de c a ja n e g ra • ¿D e qué form a están aislados los lím ites de una clase
perm ite al ingeniero del softw are o b ten er conjuntos de de datos?
co n d icio n es de e n tra d a que e je rc ite n co m p letam en te
• ¿Q ué v o lú m e n es y niveles de datos to lerará el sis
to do s los re q u isito s fu n c io n a le s de un p ro g ram a. L a
tem a?
p rueb a de caja n eg ra no es una alternativa a las técn i
cas de p ru eb a de caja blanca. M ás b ien se trata de un . ¿Q ué efectos sobre la operación del sistem a tendrán
enfoque co m plem entario que intenta descu b rir d iferen com binaciones específicas de datos?
tes tipos de errores que los m étodos de c a ja blanca. M e d ia n te las técn icas d e p ru e b a d e c a ja neg ra se
L a p ru eb a de caja neg ra intenta en co n trar errores de o b tiene un c o n ju n to d e c aso s de p ru e b a que satisfa
las sig u ien tes categ o rías: (1 ) fu n cio n es in co rrectas o c e n lo s sig u ie n te s c rite rio s [M Y E 7 9 ]: (1 ) casos de
ausentes, (2) errores de interfaz, (3) errores en estruc p ru e b a que red u cen , en un c o eficien te que es mayor
turas de datos o en accesos a b ases de d ato s externas, que uno, el n ú m e ro d e c a so s de p ru e b a adicionales
(4 )errores de rendim iento y (5 ) erro res de in icializa- que se d eb en d ise ñ a r p a ra a lc a n z a r una p ru e b a razo
ción y de term inación. n able y ( 2 ) c a so s de p ru e b a que nos d icen algo sobre
A diferen cia de la pru eb a de caja blanca, que se lle la p rese n c ia o au sen cia de clases de erro res en lugar
v a a cabo p reviam ente en el p roceso de prueba, la p ru e de errores asociados solam ente con la p ru eb a que esta
b a de c a ja n e g ra tien d e a a p lic a rse d u ra n te fases m os realizando.
p osteriores de la p ru eb a (véase el C apítulo 18). Ya que
la p ru e b a de c a ja n e g ra ig n o ra in ten cio n ad am en te la
17.6.1. M é to d o s d e p r u e b a b a s a d o s e n g ra fo s
estru ctu ra de control, cen tra su atención en el cam po de
la inform ación. L as p ruebas se diseñan p ara resp onder El prim er paso en la p rueba de caja n eg ra es entender
a las siguientes preguntas: los objetos6 que se m odelan en el softw are y las rela
ciones que conectan a estos objetos. U n a vez que se ha
• ¿C óm o se p ru eb a la validez funcional?
llevado a cabo esto, el siguiente paso es definir una serie
. ¿Cóm o se prueba el rendim iento y el com portam iento de pruebas que verifiquen que «todos los objetos tienen
del sistem a? entre ellos las relaciones esperadas» [BEI95], Dicho de
. ¿Q u é clases de e n tra d a c o m p o n d rán u n o s b u enos o tra m anera, la p ru eb a del softw are em pieza creando un
casos de prueba? grafo de objetos im portantes y sus relaciones, y después
www.FreeLibros.org
°En este contexto, el térm ino «objeto» com prende los objetos de datos
que se estudiaron en los Capítulos 11 y 12 así com o objetos de pro
gram a tales com o m ódulos o colecciones de sentencias del lenguaje
de program ación.
294
CAPÍTULO 17 T É C N I C A S DE PRUEB A DEL SO F T W A R E
diseñando u n a serie de p ruebas que cubran el grafo de C o m o se m u e stra e n la fig u ra , u n a se le c c ió n del

m anera que se ejerciten todos los objetos y sus relacio m enú en archivo nuevo genera una ventana del docu
nes para descu b rir los errores. mento. El peso del n o d o de ventana del documento
proporciona una lista de los atributos de la ventana que
%
se esp e ra n cu an d o se gen era u n a ventana. E l p e so del
en lace in d ica que la v en tan a se tien e que g e n e ra r en
iV E m e n o s de 1.0 segundos. U n e n la ce no d irig id o e s ta
Un grafo representa Id relación entre objeto dato y objeto blece una relación sim étrica entre selección en el menú
programa, permitiéndonos derivar casos de prueba
de archivo nuevo y texto del documento, y los e n la
que buscan errores asociados con estas relaciones.
ces p aralelo s in d ic an las relac io n es en tre la ventana
del documento y el texto del documento. E n re a li
d ad , se d eb ería g en erar un grafo b asta n te m ás d e ta lla
Y Enlace dirlaldo Q b je to \ do c o m o p re c u rso r al d ise ñ o d e c aso s de p ru e b a. El
1 (peso de enlace)
ingeniero del softw are obtiene en to n ces caso s de p ru e
Enlace Peso de! nodo
ba a tra v e sa n d o el g ra fo y cu b rie n d o ca d a u n a d e las
no dirigido relaciones m ostradas. E stos casos de p rueba están d ise
Enlaces paralelos *v a 'o r®
. Obieto _ ñados para intentar encontrar erro res en alguna de las
relaciones.
a) Notación de grafo B eizer [BEI95] describ e un núm ero de m éto d o s de
prueba de com portam iento que pueden hacer uso de los
/V e n t a n a \
Nuevo \ La selección del m enú genera f de 1 grafos:
archivo J (tiem po de generación < 1.0 seg.) ^documental
M o d e la d o d e l f l u j o de tra n sa cció n . L o s n o d o s
Perm ite
la edición d e , A trib uto s: rep re sen tan los p aso s de alguna tran sa cc ió n (p o r
Se representa com o ejem plo, los pasos necesarios para una reserva en una
' C ontiene Dimensiones de Inicio
configuración
o preferencias línea aérea usando un servicio en línea), y los en la
predeterminadas ces representan las conexiones lógicas entre los pasos
Color de fondo: blanco
b) Un sencillo ejemplo Color cbl texto:
(por ejem plo, vuelo.inform ación.entrada es seguida
color o preferencias de validación!disponibilidad.procesam iento). El d ia
predeterminadas gram a de flujo de datos (C apítulo 12) puede usarse
R G U R A 1 7 .9 . para ayudar en la creación de grafos de este tipo.
Para llevar a cabo estos p aso s, el ingeniero del soft M odelado de estadofinito. Los nodos representan
ware empieza creando un grafo —una colección de nodos d iferen tes estad o s del softw are o b serv ab les p o r el
qte representan objetos; enlaces que representan las rela usuario (por ejem plo, cada una de las «pantallas» que
ciones entre los objetos;pesos de nodos que describen las aparecen cuando un telefonista coge una petición por
propiedades de un nodo (por ejem plo, un valor específi teléfono), y los enlaces representan las transiciones
co de datos o com portam iento de estado) y p e so s de enla que o cu rren p a ra m o v erse de estad o a estad o (por
ces que describen alguna característica de un enlace— !. e je m p lo ,p e tic ió n -in fo rm a ció n se verifica durante
En la F igura 17.9a se m u e stra u n a re p re se n tació n inventario-disponibilidad-búsqueda y es seguido por
simbólica de un grafo . L os n odos se representan com o cliente-factura-inform ación-entrada). E l diagram a
círculos conectados p o r enlaces que tom an diferentes fo r e sta d o -tra n sició n (C ap ítu lo 1 2 ) puede u sarse para
mas. Un enlace dirigido (representado p o r u n a flecha) ayudar en la creación de grafos de este tipo.
indica que una relación se m ueve sólo en una dirección. M o d e la d o d e l flu jo de d a to s. L o s n o d o s so n
Uv i enlace bidireccional, tam b ién denom inado enlace o b jeto s de d a to s y lo s e n la c e s son las tra n sfo rm a
simétrico, im plica que la relación se aplica en am bos sen c io n e s q u e o c u rre n p a ra c o n v e rtir u n o b je to de
tidos. Los enlaces paralelos se usan cuando se establecen d atos en otro. P or ejem plo, el n o d o F IC A .im p u e s -
diferentes relaciones entre los n odos del grafo. t o ,r e te n id o (F IR ) se c a lc u la d e b r u to s .s u e ld o s
Como ejem plo sencillo, considerem os una parte de (B S) u sa n d o la rela c ió n F IR = 0 ,6 2 X BS.
un grafo de una aplicación de un p ro cesador de texto M o d ela d o de planificación. L os nodos son o b je
(Fig. 17.9b) donde: to s de p ro g ram a y los e n la c e s so n las c o n e x io n e s
objeto n.s 1 = selección en el menú de archivo nuevo secuenciales entre esos objetos. L o s pesos de e n la
objeto n.® 2 = ventana del documento ce se usan para especificar los tiem pos de ejecución
objetan.® 3 = texto del documento requeridos al ejecutarse el program a.
www.FreeLibros.org
^Si losconceptos anteriores suenan vagam ente familiares, recordemos gram a) caracterizados com o representaciones de diseño procedimen-
que los grafos se usaron tam bién en la Sección 17.4.1 para crear un tal o com o código fuente y los enlaces dirigidos indicaban el flujo de
grafo del programa para el método de la prueba del camino básico. Los control entre estos objetos del program a. Aquí se extiende el uso de los
nodos del grafo del programa contenían instrucciones (objetos de pro grafos para incluir la prueba de caja negra.
295
IN GE NI ER ÍA DEL SOF TW AR E . UN EN FOQ UE P R Á C T I C O
U n estudio detallado de cada u no de esto s m étodos de no se puede usar U N D O )d eb ería n apuntarse. Final
de p ru eb a basados en grafos está m ás allá del alcance m ente, todos los nodos del grafo deberían tener una rela
de este libro. El le c to r in te re sa d o d e b e ría c o n su lta r ción que los lleve de vuelta a ellos m ism os; en esencia,
[BEI95] p ara v er un estudio detallado. M erece la pena, un bucle de «no acción» o «acció n n u la» . Estas relacio
sin e m b a rg o , p ro p o rc io n a r un re s u m e n g e n é ric o del nes reflexivas deberían probarse tam bién.
enfoque de p ruebas b asadas en grafos. C uando em pieza el diseño de casos de prueba, el pri
m er objetivo es conseguir la cobertura de nodo. Esto sig
¿Cuáles son las artividodes nifica que las pruebas deberían diseñarse para demostrar
U generales requeridas que ningún nodo se h a om itido inadvertidam entey que
durante la prueba basada los pesos de nodos (atributos de objetos) son correctos.
en un grafo? A continuación, se trata la cobertura de enlaces. Todas
las relaciones se prueban basándose en sus propiedades.
Las p ruebas b asadas en grafos em piezan con la defi P o r e je m p lo , u n a re la c ió n sim étrica se p rueba para
nició n de todos los nod o s y pesos de nodos. O sea, se dem ostrar que es, de hecho, bidireccional. U na relación
identifican los objetos y los atributos. El m odelo de datos transitiva se p ru eb a para dem ostrar que existe transiti-
(C apítulo 12) puede usarse com o pun to de partida, pero vidad. U n a relación reflexiva se p rueba para asegurarse
es im portante ten er en cuen ta que m uchos nod o s p u e de que hay un bucle nulo presente. C uando se han espe
den ser objetos de p ro g ram a (no representados ex plíci cificado los pesos de enlace, se diseñan las pruebas para
tam ente en el m odelo de datos). P ara prop o rcio n ar una dem ostrar que estos pesos son válidos. Finalm ente, se
indicación de los p untos de inicio y final del grafo, es invocan las pruebas de bucles (S ección 17.5.3).
útil d efinir unos nod o s de entrada y salida.
U n a vez que se h an id entificado los nodos, se d eb e 17.6.2. P artición e q u iv a le n te
rían e sta b le c e r los en laces y los p eso s de enlaces. En
Lap a rtició n equivalente es un m étodo de prueba de caja
general, conviene n o m b rar los enlaces, aunque los en la
n eg ra que d ivide el cam po de entrada de un programa
ces que represen tan el flujo de control en tre los objetos
en clases de datos de los que se pueden derivar casos
de p ro g ram a no es n ecesario nom brarlos.
de prueba. U n caso de p rueba ideal descubre de forma
E n m uchos casos, el m odelo de g rafo puede tener
in m ed ia ta u n a clase de erro res (por ejem p lo , proceso
bucles (por ejem plo, un cam ino a través del grafo en el
incorrecto de todos los datos de carácter) que, de otro
que se encuentran uno o m ás nodos m ás de una vez). La
m odo, requerirían la ejecución de m uchos casos antes
prueb a de bucle (S ección 17,5.3) se puede aplicar tam
de detectar el e rro r genérico. L a partición equivalente
bién a nivel de com portam iento (de caja negra). El grafo
se dirige a la definición de casos de p ru eb a que descu
ayudará a identificar aquellos bucles que hay que probar.
bran clases de errores, reduciendo así el núm ero total
C ada relació n es estudiada separadam ente, de m an e
de casos de p rueba que hay que desarrollar.
ra que se p u ed an o btener casos de prueba. L a transiti-
v id a d de re la c io n e s se c u e n c ia le s es e s tu d ia d a p ara
determ in ar cóm o se p ro p ag a el im pacto de las relacio
nes a través de objetos definidos en el grafo. L a transi-
las clases de entrada san conocidas relativamente
tividad puede ilustrarse considerando tres objetos X ,Y
temprano en el procesa de software. Por esto razón,
y Z. C onsiderem os las siguientes relaciones:
comenzamos pensando en la partición equivalente
X es necesaria p a r a calcular Y una vez el diseña ha sido creada.
Y es necesaria p a r a calcular Z
El diseño de casos de p rueba para la partición equi
P or tanto, se h a establecido u n a relació n transitiva
valente se b asa en una evaluación de las clases de equi
entre X y Z:
v a le n c ia para u n a co n d ició n de entrada. M ediante
X es n ecesaria p a r a calcular Z conceptos introducidos en la sección anterior, si un con
B asán d o se en e s ta re la c ió n tra n sitiv a , las p ru eb as ju n to de objetos puede unirse p o r m edio de relaciones
para encontrar errores en el cálculo de Z deb en co n si sim étricas, transitivas y reflexivas, entonces existe una
derar u n a v aried ad de v alores p ara X e Y. clase de equivalencia [BEI95]. U na clase de equiva/en-
L a sim etría de u n a relación (enlace de grafo) es tam cia representa un conjunto de estados válidos o no váli
bién un a im portante directriz p ara d iseñar casos de prue do s para co n d icio n es de entrada. T íp ic am e n te, una
ba. Si un enlace es bidireccional (sim étrico),es im portante condición de entrada es un valor num érico específico,un
p ro b a r esta característica. L a c a ra c terístic a U N D O rango de valores, un conjunto de valores relacionados o
[BEI95] (deshacer) en m uchas aplicaciones para o rd e una condición lógica. Las clases de equivalencia se pue
nadores personales im plem enta una lim itada simetría. Es den definir de acuerdo con las siguientes directrices:
www.FreeLibros.org
decir, U N D O perm ite desh acer u n a acción después de 1. Si u n a c o n d ic ió n de e n tra d a e sp ec ifica un rango,
haberse com pletado. E sto debería probarse m in u cio sa se d efine u n a clase de eq u iv a len c ia v álid a y dos no
m ente y todas las excepciones (por ejem plo,lugares d o n válidas.
296
CAPÍTULO 17 TÉ CN IC A S DE PRUEBA DEL S O F T W A R E
2. Si una condición de entrada requiere un v alor e sp e prueba. E l an álisis de valores lím ite n o s lle v a a u n a
cífico, se define u n a clase de equivalencia válida y e le c c ió n d e c aso s de prueba que e je rc ite n los v a lo re s
dos no válidas. lím ite.
3. Si una condición de entrada especifica un m iem bro
de un conjunto, se define u n a clase de equivalencia
válida y una no válida. CLAVE
4. Si una condición de entrada es ló g ica, se define una AVL amplía la partlclónequlvalente para fijarse sobre
clase de equivalencia v álid a y u n a no válida. datos en el «límite» de una clase de equivalencia.
Como ejem plo, considerem os los datos co n tenidosen

una aplicación de autom atización bancaria. El usuario El análisis de valores lím ite es una té cn ic a d e d ise
puede «llam ar» al banco usando su ord en ador personal, ño de casos de prueba que com plem enta a la p a rtic ió n
dar su contraseña de seis dígitos y continuar con una serie equivalente. En lugar de seleccionar c u a lq u ier elem en
de órdenes tecleadas que desencadenarán varias funcio to de una clase de equivalencia, el AVL llev a a la e le c
nes bancarias. El softw are p ro porcionado p o r la aplica ción de casos de prueba en los «extrem os» d e la clase.
ción bancaria acepta datos de la siguiente forma: E n lugar de centrarse solam ente en las c o n d icio n es de
Código de área: en blanco o un núm ero de tres dígitos entrada, el AVL obtiene casos de p ru eb a ta m b ién para
el cam po de salida [M YE79].
Prefijo: núm ero de tres dígitos que no com ience por
Oo 1
¿ Cómo se crean casos
Sufijo: núm ero de cuatro dígitos
Contraseña: v alo r alfanum érico de seis dígitos
Órdenes: «com probar», « d ep o sitar» , « p ag a r factu
• de prueba para el AVL?
L as d irectrices de A VL son sim ila re s e n m u ch o s

ra», etc. aspectos a las que proporciona la partición equivalente:
Las condicionesde entrada asociadas con cada elemento 1. Si una condición de entrada especifica un rango d eli
de la aplicación bancaria se pueden especificar como: m itado p o r los valores a y b, se d eb en diseñar casos
de prueba para los valores a y ó, y para los valo res
Código de área: condición de entrada,lógica— el códi
ju s to p o r deb ajo y ju s to p o r e n c im a de a y b, re s
go de área puede estar o no presente
pectivam ente.
condición de entrada, rango— valo
res definidos en tre 2 00 y 999, con 2. Si una condición de entrada especifica un núm ero de
excepciones específicas v alo res, se d e b en d e sarro lla r caso s d e p ru eb a que
ejerciten los valores m áxim o y m ínim o. T am bién se
Prefijo: condición de entrada, rango — valor
deben probar los valores ju s to p o r encim a y ju s to por
e s p e c if ic a d o 200 sin dígitos 0
debajo del m áxim o y del m ínim o.
Sufijo: condición de entrada, v alo r — lo n
3. A p lic a r las d ire c tric e s 1 y 2 a las c o n d ic io n e s de
gitu d de cuatro dígitos salida. P or ejem plo, supongam os que se requiere una
Contraseña: c o n d ic ió n d e e n tra d a , ló g ic a — tabla de «tem peratura / presión» co m o salida de un
la p a la b ra c la v e p u ed e e sta r o no program a de análisis de ingeniería. Se d eb en d ise
presente; ñar casos de prueba que creen un inform e de salida
condición de entrada, v alo r — cade que produzca el m áxim o (y el m ínim o) n ú m ero p er
na de seis caracteres m itido de entradas en la tabla.
' Orden: co n d ició n de e n tra d a , c o n ju n to — 4. Si las e stru c tu ra s d e d a to s in te rn a s tie n e n lím ite s
c o n te n id a en las ó rd en es listad as preestablecidos (por ejem plo, una m atriz que tenga
anteriorm ente un lím ite definido de 100 entradas), hay que asegu
A plicando las directrices p ara la o btención de clases rarse de d iseñ a r un c aso de p ru e b a que e je rc ite la
de equivalencia, se p u ed en desarro llar y ejecutar casos estructura de datos en sus lím ites.
de prueba p ara cad a elem en to de d ato s del cam po de L a m ayoría de los ingenieros del softw are llevan a
entrada. Los casos de pru eb a se seleccionan de form a cab o de fo rm a in tu itiv a alg u n a fo rm a de AVL. A p li
que se ejercite el m ay o r n ú m ero de atrib u to s de cada cando las directrices que se acaban de exponer, la prueba
clase de equivalencia a la vez. de lím ites será m ás co m p leta y, p o r tan to , ten d rá una
m ay o r probabilidad de detectar errores.
17.6.3. A nálisis d e v alores lím ite
Por razones que no e stá n del to d o c la ra s, los erro re s 17.6.4. P rueba d e com paración
www.FreeLibros.org
tienden a darse m ás en los lím ites del cam po de e n tra H ay situaciones (por ejem p lo , aviónica de aeronaves,
da que en el « c e n tro » . P o r ello , se ha d e sa rro lla d o el co n tro l de planta nu clear) en las que la fiab ilid a d del
análisis de v a lo re s lím ite s (A V L ) c o m o té c n ic a de softw are es algo absolutam ente crítico. E n ese tipo de
297
in g e n ie r ía del s o f t w a r e . un en fo q u e p r á c tic o
aplicaciones, a menudo se utiliza hardware y software bas exhaustivas. El método de prueba de la tabla orto
redundante para minimizar la posibilidad de error. Cuan gonal es particularmente útil al encontrar errores aso
do se desarrolla software redundante, varios equipos de ciados con fallos localizados — una categoría de error
ingeniería del software separados desarrollan versiones asociada con defectos de la lógica dentro de un com
independientes de una aplicación, usando las mismas ponente software— .
especificaciones. En esas situaciones, se deben probar Para ilustrar la diferencia entre la prueba de la tabla
todas las versiones con los mismos datos de prueba, para ortogonal y una aproximación más convencional «un
asegurar que todas proporcionan una salida idéntica. elemento de entrada distinto cada vez», considerar un
Luego, se ejecutan todas las versiones en paralelo y se sistema que tiene tres elementos de entrada, X , Y y Z.
hace una comparación en tiempo real de lo s resultados, Cada uno de estos elementos de entrada tiene tres valo
para garantizar la consistencia. res diferentes. Hay 33 = 27 posibles casos de prueba.
Con las lecciones aprendidas de los sistemas redun Phadke [PHA97] sugiere una visión geométrica de los
dantes, los investigadores (por ejemplo, [BRI87]) han posibles casos de prueba asociados con X , Y y Z,
sugerido que, para las aplicaciones críticas, se deben según se ilustra en la Figura 17.10. Observando la
desarrollar versiones de software independientes, inclu figura, cada elemento de entrada en un momento dado
so aunque só lo se vaya a distribuir una de las versiones puede m odificarse secuencialm ente en cada eje de
en el sistema final basado en computadora. Esas ver entrada.
siones independientes son la base de una técnica de prue
ba de caja negra denominada p rueba de comparación
o pru eb a mano a mano [KNI89].
Cuando se han producido múltiples implementacio-
nes de la misma especificación, a cada versión del soft
ware se le proporciona como entrada los casos de prueba
diseñados mediante alguna otra técnica de caja negra
(por ejemplo, la partición equivalente). Si las salidas
producidas por las distintas versiones son idénticas, se
asume que todas las implementaciones son correctas.
Si la salida es diferente, se investigan todas las aplica Un e le m e n to d e e n tra d a T ab la o rto g o n a l L9
ciones para determinar el defecto responsable de la dife a la vez
rencia en una o más versiones. En la mayoría de los F IG U R A 17.10. Una vista geométrica de los casos.
casos, la comparación de las salidas se puede llevar a
cabo mediante una herramienta automática.
Esto da com o resultado un alcance relativamente
limitado al dominio de entrada (representado en la figu
17.6.5. P r u e b a d e l a t a b l a o rto g o n a l
ra por el cubo de la izquierda).
Hay muchas aplicaciones en que el dominio de entrada Cuando se realiza la prueba de la tabla ortogonal,
es relativamente limitado. Es decir, el número de pará se crea una tabla ortogonal L 9 de casos de prueba. La
metros de entrada es pequeño y los valores de cada uno tabla ortogonal L9 tiene una «propiedad de equilibrio))
de los parámetros está claramente delimitado. Cuando [PHA97], Es decir, los casos de prueba (representados
estos números son muy pequeños (por ejemplo, 3 pará por puntos negros en la figura) están «uniformemen
metros de entrada tomando 3 valores diferentes), es posi te dispersos en el dominio de prueba», según se ilus
ble considerar cada permutación de entrada y comprobar tra en el cubo de la derecha de la Figura 17.10. El
exhaustivamente el proceso del dominio de entrada. En alcance de la prueba por todo el dominio de entrada
cualquier caso, cuando el número de valores de entra es más completo.
da crece y el número de valores diferentes para cada Para ilustrar el uso de la tabla ortogonal L9, consi
elemento de dato se incrementa, la prueba exhaustiva derar la función enviar para una aplicación de un fax.
se hace impracticable o imposible. Cuatro parámetros, P l, P2, P3 y P4 se pasan a la fun
ción enviar. Cada uno tiene tres valores diferentes. Por
ejemplo, Pl toma los valores:
CLAVE P l = 1, enviar ahora
I a prueba de le tabla ortogonal permite diseñar casos P2 = 2, enviar dentro de una hora
de prueba que facilitan una cobertura máximo de prueba P3 = 3, enviar después de media noche
con un número razonable de casos de prueba. P2, P3, y P4 podrán tomar también los valores 1, 2y 3,
representando otras funciones enviar.
www.FreeLibros.org
La p ru eb a de la tabla ortogonal puede aplicarse a Si se elige la estrategia de prueba «un elemento de
problemas en que el dominio de entrada es relativamente entrada distinto cada vez», se especifica la siguiente
pequeño pero demasiado grande para posibilitar prue secuencia de pruebas (P1,P2,P3,P4): (1,1,1,1), (2,1,1,1),
290
C A P Í T U L O 17 T É C N I C A S DE P RU EB A DEL S O F T W A R E
(3.1.1.1), (1,2,1,1), (1,3,1,1), (1,1,2,1), (1,1,3,1), L a p ru eb a de la tab la o rtogonal nos perm ite propor
(1.1.1.2), y (1,1,1,3). Phadke [PHA97] v aloraestos casos c io n a r u n a b u en a c o b e rtu ra de p ru e b a c o n b a sta n te s
de prueba de la siguiente m anera: m enos casos de p ru eb a que en la estrategia exhaustiva.
C ada uno de estos casos de prueba son Útiles, Únicam ente U n a tab la ortogonal L 9 para la función de envío del fax
cuando estos p arám etros de prueba no se influyen m utuam en se describe en la Figura 17.11.
te. Pueden detectar fallos lógicos cuando el v alor de un pará P h ad k e [P H A 97] v a lo ra el re su lta d o d e las p ru e
metro produce un mal funcionam iento del software. E stos fallos
b a s u tiliz a n d o la ta b la o rto g o n a l d e la s ig u ie n te
pueden llam arse fallos de m odalidad simple. E l m étodo no pue
de detectar fallos lógicos que causen un m al funcionam iento
m an era:
cuando dos o m ás parám etros sim ultáneam ente tom an deter Detecta y aísla todos los fallos de modalidad sim
minados valores; es decir, no se pueden detectar interacciones. ple. U n f a llo d e m o d a lid a d sim p le e s u n p ro b le m a q u e
Así, esta habilidad para detectar fallos es lim itada. afecta a un s o lo parám etro. P o r e je m p lo , si to d o s lo s caso s
Dados un núm ero relativam ente pequeño de parám e d e p ru e b a del fa c to r P 1 = 1 c au sa n una c o n d ic ió n d e e rro r,
tros de entrada y valores diferentes, es posible realizar una n os e n c o n tra m o s c o n el fa llo d e m o d a lid a d sim ple. E n los
e je m p lo s d e p ru e b a 1, 2 y 3 [Fig. 17.111 se e n c o n tra rá n
prueba exhaustiva. E l n ú m ero de p ruebas requeridas es
e rro re s . A n a liz a n d o la in fo rm a c ió n e n q u e la s p ru e b a s
3-81 — grande pero manejable— . Todos los fallos aso m u estran erro res, se puede id en tific ar que valo res del p a rá
ciados con la perm utación de los datos serán encontrados, m etro c au sa n el error. E n e ste e je m p lo , a n o ta m o s q u e las
pero el esfuerzo requerido es relativam ente alto. p ru e b a s 1, 2 y 3 c au sa n un e rro r, lo q u e p e rm ite a is la r [el
p ro c e so ló g ic o a so c ia d o c o n « e n v ia r ah o ra» (P1 = 1)] la
fuente del error. E l aislam ien to del fallo es im p o rtan te para
so lu c io n a r el error.
P1 P2 P3 P4 '
Detecta todos los fallos de modalidad doble. S i e x is
1 1 1 1 te un pro b lem a d o n d e e stán afectados d o s p a rá m e tro s que
1 2 2 2 in te rv ie n e n c o n ju n ta m e n te , se lla m a fa llo d e m o d alid ad
doble. E n e fe c to , un fallo de m odalidad doble es una in d i
1 3 3 3 c ació n de in co m p atib ilid ad o de im p o sib ilid ad de in te ra c
2 1 2 3 c ió n e n tre dos parám etros.
2 2 3 1
Fallos multimodales. L as tab las orto g o n ales [del tipo
2 3 1 2 indicado] pueden asegurar la detección Ú nicam ente de fallos
3 1 3 2 de m odalidad sim ple o doble. S in em bargo, m uchos fa llo s
e n m o d a lid a d m últip le p u e d e n ser d e te c ta d o s a tra v é s de
3 2 1 3 e sta s pruebas.
3 3 2 1
Se p u ede e n c o n tra r u n e stu d io d e ta lla d o so b re la
FIGURA 17.11. Unatabla ortogonal L9. prueba de tabla ortogonal en [P H A 89].
A medida que el softw are de com p u tad o ra se h a hecho en m en o s c o sto sa en tie m p o y m ás exacta. A l m ism o
más com plejo, h a crecido tam b ién la necesidad de en fo tie m p o , la c o m p le jid a d d e las IG U s h a a u m e n ta d o ,
ques de p ruebas especializados. L os m étodos de prue o rig in an d o m á s d ific u ltad en el d iseño y e je c u c ió n de
ba de c a ja b la n c a y de c a ja n e g ra tra ta d o s en las los c a so s de prueba.
Secciones 17.5 y 17.6 son aplicables a todos los e n to r
nos, arquitecturas y aplicaciones pero a v eces se nece
sitan unas directrices y enfoques Únicos p ara las pruebas.
En esta sección se estudian directrices de p ru eb a para
entornos, arq u itectu ras y a p licacio n es esp ecializad as
que pueden encontrarse los ingenieros del softw are.
D ado que las IG U s m o d ern as tie n e n la m ism a ap a
rie n c ia y filo s o fía , se p u e d e n o b te n e r u n a se rie de
17.7.1. P r u e b a d e i n t e r f a c e s g r á f i c a s d e u s u a r i o
p ru eb as estándar. L o s g rafo s de m o d elad o de estad o
(IG U s)
finito (S ección 16.6.1) pueden ser utilizados para re a
Las interfaces g rá fic a s de u su a rio (IG U s) p resen tan liz a r p ru eb as que v ay an dirig id as sobre d ato s e s p e c í
interesantes d esafío s p ara los in g en iero s del so ftw a fico s y p ro g ram as o b jeto que sean re le v an te s p a ra las
www.FreeLibros.org
re. D ebido a los co m p o n en tes re u tiliz a b le s p ro v isto s IG U s.
como p arte de los en to rn o s de d e sa rro llo de las G U I, C onsiderando el gran núm ero de perm utaciones aso
la creación de la in te rfa z d e u su a rio se h a co n v ertid o ciad as con las o p e racio n es IG U , sería n ec esario p a ra
299
pro b ar el u tilizar herram ientas autom áticas. U n a am plía claridad editorial. La segunda fase, la p r u e b a en vivo,
lista de herram ientas de p ru eb a de IG U h an aparecido utiliza la docum entación unto al uso del programa real.
en el m ercado en los Últimos años. P ara p ro fu n d izar en Es sorprendente, pero la prueba en vivo de la docu
el tem a, v er el C apítulo 31. m entación se puede enfocar usando técnicas análogas
a m uchos de los métodos de prueba de caja negra estu
diados en la Sección 17.6. Se pueden em plear pruebas
basadas en grafos para describir el em pleo del progra
ma; se pueden em plear el análisis de la partición equi
valente o de los valores límites para definir varias clases
de entradas e interacciones asociadas.
Prueba IGU.
17.7.4. P r u e b a d e s is te m a s d e tiem p o -rea l

17.7.2. P r u e b a d e a rq u itectu ra c lie n te /se r v id o r
La naturaleza asíncrona y dependiente del tiempo de
La arquitectura cliente/servidor (C/S) representa un desa muchas aplicaciones de tiem po real, añade un nuevo y
fío significativo p ara los responsables de la p ruebas del potencialm ente difícil elemento a la complejidad de las
software. La naturaleza distribuida de los entornos clien pruebas - e l tiempo—. El responsable del diseño de casos
te/servidor, los aspectos de rendim iento asociados con de prueba no sólo tiene que considerar los casos de prue
el proceso de tran saccio n es, la p resen cia potencial de ba de caja blanca y de caja negra, sino también el trata
diferentes plataform as h ardw are, las com plejidades de m iento de sucesos (por ejem plo, procesam iento de
las co m u n icacio n esd e red, la necesid ad de servir a m ú l interrupciones),la temporización de los datos y el para
tiples clientes desde u n a base de datos cen tralizada (o lelismo de las tareas (procesos) que manejan los datos. Eh
en algunos casos, distrib u id a) y los requisitos de coor m uchas situaciones, los datos de prueba proporcionados
dinación im puestos al servidor se com binan todos para al sistema de tiempo real cuando se encuentra en un deter
h acer las p ruebas de la arquitectura C/S y el softw are minado estado darán un proceso correcto, mientras que al
residente en ellas, co nsiderablem ente m ás difíciles que proporcionárselos en otro estado llevarán a un error.
la p ru eb a de aplicaciones individuales. D e hecho, e stu
dios recientes sobre la ind u stria indican un significati
vo aum ento en el tiem po invertido y los costes de las
pruebas cuando se desarro llan entornos C/S.
Sistemas de tiempo real.

Lo ingenierío del software diente/servidor se presento
en el Capítulo 28.
Por ejemplo, un software de tiem po real que controla
una m oderna fotocopiadora puede aceptar interrupcio
nes del operador (por ejemplo, el operador de la máqui
17.7.3. P ru eb a d e la d o cu m en ta ció n y fa c ilid a d e s na pulsa teclas de control tales com o «inicialización» u
de ayuda «oscurecim iento») sin error cuando la m áquina se
E l térm ino ap ru eb as del so ftw are» hace im ag in arn o s encuentra en el estado de hacer fotocopias (estado de
gran cantidad de caso s de p ru eb a p reparados p ara e je «copia»). Esas m ism as interrupciones del operador,
cutar p rogram as de com pu tad o ra y los datos qu e m ane cuando se producen estando la m áquina en estado de
ja n . R eco rd an d o la definición de so ftw are p re sen ta d a «atasco», pueden producir un código de diagnóstico que
en el p rim er c ap ítu lo de este lib ro , es im p o rtan te d a r indique la situación del atasco (un error).
se c u e n ta de q u e la p ru eb a debe ex ten d erse al terc er Además, la estrecha relación que existe entre el soft
elem en to de la c o n fig u ra c ió n del so ftw are — la do cu ware de tiem po real y su entorno de hardware también
m e n ta c ió n - . puede introducir problem as en la prueba. Las pruebas
L os errores en la d o cum entación p u ed en ser tan des del software deben considerar el im pacto de los fallos
tructivos p ara la aceptación del program a, com o los erro del hardware sobre el proceso del software. Puede ser
res en los d ato s o en el có d ig o fuente. N a d a e s m ás muy difícil simular de forma realista esos fallos.
frustrante que seguir fielm ente el m anual de usuario y Todavía han de evolucionar mucho los métodos gene
o btener resultados o com p o rtam ien to sq u e no coinciden rales de diseño de casos de prueba para sistemas de tiem
con los anticipados p o r el docum ento. P or esta razón, la po real. Sin embargo, se puede proponer una estrategia
prueba de la docum entación debería ser una parte im por en cuatro pasos:
tante de cualq u ier plan de p ruebas del softw are. Prueba de tareas. El prim er paso de la prueba de
www.FreeLibros.org
L a p ru eb a de la d ocum entación se puede en focar en sistemas de tiem po real consiste en probar cada tarea
d o s fases. L a p rim e ra fase, la revisió n e in sp ecció n independientemente. Es decir, se diseñan pruebas de
(C apítulo 8), exam ina el d ocum ento para com p ro bar la caja blanca y de caja negra y se ejecutan para cada
300
CAPÍTULO 17 T É C N I C A S DE PRUEB A DEL S O F T W A R E
tarea. Durante estas pruebas, cada tarea se ejecuta inde Prueba intertareas. U na vez que se han aislado
pendientemente. L a prueba de la tarea h a de descubrir los erro res en las tareas in d iv id u ales y en el c o m
errores en la lógica y en el funcionam iento, pero no p o rta m ie n to del sistem a, la p ru e b a se dirige h a cia
los errores de tem porización o de com portam iento. los errores relativos al tiem po. Se prueban las tare
as asíncronas que se sabe que co m u n ican con otras,
co n d iferen tes tasa s de d ato s y ca rg a s d e p ro c e so
. . . . • 'T T V p ara determ inar si se producen erro res de sin cro n is
m o entre las tareas. A dem ás, se prueban las tareas
BForum de Discusión de la Prueba del Software presenta temas que se c o m u n ic a n m e d ia n te co la s de m e n sa je s o
de ¡nterésa los profesionales que efectúanla pruebo: alm acenes de datos, para detectar errores en el ta m a
www.ondaweb.coni /HyperNews/get.cgi/forums/sti.html ño de esas áreas de alm acenam iento de datos.
Prueba de comportamiento. U tilizando m odelos Prueba del sistema. El software y el hardware están
del sistema creados con herram ientas C A SE, es posi integrados, por lo que se lleva a cabo una serie de prue
ble sim ular el com portam iento del sistem a en tiem po bas com pletas del sistem a (C apítulo 18) para intentar
real y exam inar su com portam iento com o consecuen descubrir errores en la interfaz softw are/hardw are.
cia de sucesos externos. Estas actividades de análisis L a m ayoría de los sistem as de tiem po real procesan
pueden servir com o base del diseño de casos de prue interrupciones. P or tanto, es esencial la prueba del m ane-
ba que se llevan a cabo cuando se ha construido el soft j o de estos sucesos lógicos. U sando el diagram a estado-
ware de tiem po real. U tilizando una técnica parecida tran sició n y la especificaciónde control (C apítulo 12), el
a la partición equivalente (Sección 17.6.1), se pueden responsable de la p rueba desarrolla una lista de todas las
categorizar los sucesos (por ejem plo, interrupciones, posibles interrupciones y del proceso que ocurre com o
señales de control, datos) p ara la prueba. Por ejem plo, consecuenciade la interrupción. Se diseñan después prue
los sucesos p ara la fotocopiadora p u eden ser in te bas para valorar las siguientes característicasdel sistema:
rrupciones del usuario (por ejem plo, reinicialización
• ¿Se han asignado y gestionado apropiadam ente las
del contador), interrupcionesm ecánicas (por ejem plo,
prioridades de interrupción?
atasco del papel), interrupciones del sistema (por ejem
plo, bajo nivel de tinta) y m odos de fallo (por ejem • ¿Se g estio n a co rrectam en te el p ro ce sam ie n to para
plo, rodillo excesivam ente caliente). Se p rueba cada todas las interrupciones?
uno de esos sucesos individualm ente y se exam ina el • ¿Se ajusta a los requisitos el rendim iento (por eje m
com portam iento del sistem a ejecutable para detectar plo, tiem po de proceso) de todos los procedim ientos
errores que se produzcan com o co n secuenciadel pro de gestión de interrupciones?
ceso asociado a esos sucesos. Se puede com parar el
• ¿C rea problem as de funcionam iento o rendim iento
com portam iento del m odelo del sistem a (desarrolla
la llegada de un gran volum en de interrupciones en
do durante el análisis) con el softw are ejecutablepara
m om entos críticos?
ver si existe concordancia. U n a vez que se h a proba
do cada clase de sucesos, al sistem a se le presentan A dem ás, se deberían p robar las áreas de datos g lo
sucesos en un orden aleatorioy con una ffecuenciaale- bales que se usan para transferir inform ación com o p ar
atoria. Se exam in a el co m portam iento del softw are te del p ro c e so de u n a in te rru p c ió n p a ra v a lo ra r el
para detectar errores de com portam iento. potencial de generación de efectos colaterales.
El principal objetivo del diseño de casos de p ru eb a es p endientes que aseguren la total cobertura. L a prueba
obtener un co n ju n to de p ru eb as que ten g an la m a y o r de condiciones y del flujo de datos ejercita m ás aún la
probabilidad de d escu b rirlo s defectos del software. Para lógica del p rogram a y la p ru eb a de los bucles com ple
llevar a cabo este objetivo, se usan d os categorías d ife m en ta a otras técnicas de caja blanca, proporcionando
rentes de técnicas de diseño de casos de prueba: p ru e un procedim iento para ejercitar bucles de distintos g ra
ba de caja b lan ca y p ru eb a de c a ja negra. dos de com plejidad.
Las pruebas de caja b lan ca se centran en la e stru c H eztel [H ET84] describ e la p ru eb a de caja b lan ca
tura de control del program a. Se obtienen casos de prue co m o « p ru eb a a p eq u e ñ a esc ala» . E sto se d eb e a que
ba que aseguren que durante la p ru eb a se han ejecutado, las p ru eb as de c a ja b la n c a que h em o s c o n sid erad o en
por lo m enos u n a vez, todas las sentencias del p ro g ra este c a p ítu lo son típ ic a m e n te a p lic a d a s a p e q u e ñ o s
ma y que se ejercitan todas las condiciones lógicas. La c o m p o n e n te s de p ro g ram as (po e je m p lo ; m ó d u lo s o
www.FreeLibros.org
prueba del cam ino básico, u n a técn ica de caja blanca, p eq u eñ o s g rupos de m ódulos). P or o tro lado, la p ru e
hace uso de grafos de p ro g ram a (o m atrices de grafos) b a de c aja n e g ra am p lía el enfo q u e y se pued e d e n o
para obtener el conjunto de p ruebas linealm ente inde- m in a r «pru eb a a gran escala».
30 1
ING EN IE RÍA DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
Las pruebas de caja negra son diseñadas para validar Los m étodos de prueba especializados comprenden una
los requisitos funcionales sin fijarse en el funcionam ien am plia gam a de capacidades del softw are y áreas de apli
to interno de un program a. Las técnicas de prueba de caja cación. Las interfaces gráficas de usuario, las arquitectu
neg ra se centran en el ám bito de inform ación de un pro ras cliente/servidor, la docum entación y facilidadesde
gram a, de form a que se proporcione una cobertura co m ayuda, y los sistem as de tiem po real requieren directrices
pleta de prueba. Los m étodos de prueba basados en grafos y técnicas especializadas para la prueba del software.
exploran las relaciones entre los objetos del program a y A m enudo, los desarrolladores de softw are experi
su com portam iento. L a p artició n equivalente divide el m entados dicen que «la prueba nunca term ina, simple
cam po de entrada en clases de datos que tienden a ejerci m ente se transfiere de usted (el ingeniero del software)
tar determ inadas funciones del softw are. El análisis de al cliente: C ada vez que el clien te usa el program a, lle
valores límite prueba la habilidad del program a para m ane- va a cabo una prueba.» A plicando el diseño de casos de
ja r datos que se encuentran en los lím ites aceptables. La prueba, el ingeniero del softw are puede conseguir una
prueba de la tabla ortogonal sum inistra un m étodo siste prueba m ás com pleta y descubrir y corregir así el mayor
m ático y eficiente p ara p ro b ar sistem as con un núm ero n ú m ero de erro res antes de que co m ien cen las «prue
reducido de parám etros de entrada. bas del cliente».
[BE190] B eizer,B ., Software T estin g T e clm iq u e s,% ed., Van [JON81] Jones, T.C., Program m ing Productivity: Issuesfor
N ostrand Reinhold, 1990. the 8 0 ’s, IEEE Com puter Society Press, 1981.
[BE195] Beizer, B., Black-Box Testing, Wiley, 1995. [KAN93] K aner,C ., J. F a lk y H.Q. N guyen, TestingCompu-
[BRI87] Brilliant, S.S., J.C. K night, y N.G. Levenson, «The ter Software, 2.a ed., Van N ostrand Reinhold, 1993.
Consistent C om parisonP roblem in N-Versión Software», [KNI89] Knight, J., y P. Am m ann, «Testing Software Using
A C M Software Engineering N otes, vol. 12,n.° 1, enero M últiple V ersions», Softw are P roductivity Consortium,
1987,pp. 29-34. Report n.° 89029N, Reston, VA, Junio 1989.
[DAV95] D avis, A., 201 Principies o f Software Development, [MCC76] M cCabe, T., «A Software Com plexity Measure»,
M cGraw -H ill, 1995. IE E E Trans. Software Engineering, vol. 2, Diciembre 1976,
[DEU79] D eutsch, M., «Verification and Validation», Soft pp. 308-320.
ware Engineering, R. Jensen y C.Tonies (eds.), Prentice- [MYE79] Myers, G., T heA rt o f Software Testing,Wiley, 1979.
Hall, 1979,pp. 329-408. [NTA88] Ntafos, S.C., «Acomparison of Some StmcturalTes-
[FOS84] Foster, K .A ., «S ensitive Test D ata fo r B oolean tingStrategiess./E LA Trans. Software Engineering, vol. 14,
E xpressions»,H CA / Software Engineering Notes, vol. 9, n.° 6, Jum o 1988,pp. 868-874.
n.° 2, Abril 1984,pp. 120-125. [PHA89] Phadke, M .S., Q uality Engineering U sing Robust
[FRA88] Frankl,P.G .,y E.J. W eyuker,«An A pplicableFam ily Design, Prentice Hall, 1989.
of Data Flow Testing Criteria», IE E E Trans. Software Engi [PHA97] Phadke, M.S., «Planning Efficient Software Tests»,
neering, vol. 14,n.° 10, O ctubre 1988,pp. 1483-1498. Crosstalk, vol. 10,n.° 10, Octubre 1997,pp. 278-283.
[FRA93] Frankl, P .G , y S. Weiss, «A n Experim ental Com- [TAI87] Tai, K.C., y H.K. Su, «Test G eneration for Boolean
parison of the Effectiveness of Branch Testing and Data Expresions», Proc. CO M PSAC’87, Octubre 1987,pp. 278-
Flow » ,IE E E Trans. Software Engineering, vol. 19,n.° 8, 283.
Agosto 1993,pp. 770-787. [TAI89] Tai, K.C., «W hat to D o B eyond Branch Testing»,
[HET84] H etzel, W., The Com plete G uide to Softw are Tes A C M Softw are E ngineering N o tes, vol. 14,n.° 2, Abril
ting, QED Information Sciences, Inc., Wellesley, M A, 1984. 1989,pp. 58-61.
[HOW82] H ow den, W.E., «Weak M utation Testing and the [WHI80] W hite, L.J., y E.I. Cohén, «A D om ain Strategiefor
Com pletenessof Test Cases», IE E E Trans. Software E ngi Program Testing», IE E E Trans. Software Engineering, vol
neering, vol. SE-8, n.° 4, ju lio 1982,pp. 371-379. SE-6, n.° 5, M ayo 1980,pp. 247-257.
TI
17.1. M yers [MYE79] usa el siguiente program a com o auto- 17.2. Diseñe e implemente el programa especificado en el Pro
com probación de su capacidad para especificar una prueba blem a 17.1 (con tratam iento de errores cuando sea necesario).
adecuada: un program a lee tres valores enteros. Los tres valo O btenga un grafo de fluj o para el program a y aplique la prue
res se interpretan com o representación de la longitud de los ba del cam ino básico para desarrollar casos de prueba que
tres lados de un triángulo. El program a im prim e un m ensaje garanticen la com probación de todas las sentencias del pro
www.FreeLibros.org
indicando si el triángulo es escaleno, isósceles o equilátero. grama. E jecute los casos y m uestre sus resultados.
D esarrolle un conjunto de casos de prueba que considere que 17.3. ¿Se le ocurren algunos objetivos de prueba adicionales
probará de form a adecuada este programa. que no se hayan m encionado en la Sección 17.1.1?
302
17A A p liq u e la té c n ic a d e p ru e b a d e l c a m in o b á s ic o a c u a l m ie n tra s q u e la p r u e b a d e c a ja b la n c a p u d ie r a d e s c u b rir e r ro

quiera d e lo s p ro g ra m a s q u e h a y a im p le m e n ta d o e n lo s P r o res. In d iq u e p o r lo m e n o s tr e s e je m p lo s e n lo s q u e la p r u e b a
blem as 17.4 a 17.11. d e c a ja b la n c a p u e d a d a r la im p re s ió n d e q u e « to d o e s tá b ie n » ,
17.5. E sp e c ifiq u e , d is e ñ e e im p le m e n te u n a h e rra m ie n ta d e m ie n tra s q u e la p r u e b a d e c a ja n e g ra p u d ie r a d e s c u b rir e rro re s.
software q u e c a lc u le la c o m p le jid a d c ic lo m á tic a p a r a e l l e n 1 7 .1 2 . ¿ P o d ría u n a p ru e b a e x h a u s tiv a (in c lu s o si fu e ra p o s i
guaje de p ro g ra m a c ió n q u e q u ie ra . U tilic e la m a triz d e g ra fo s b le p a r a p e q u e ñ o s p ro g ra m a s ) g a r a n tiz a r q u e u n p r o g r a m a e s
como e stru c tu ra d e d a to s o p e ra tiv a e n e l d ise ñ o . al 100 p o r 100 c o rre c to ?
17£ l L ea a B e iz e r [B E I90] y d e te rm in e c ó m o p u e d e a m p lia r el 1 7 .1 3 . U s a n d o e l m é to d o d e la p a rtic ió n e q u iv a le n te , o b te n g a
programa desarrollado e n el P ro b lem a 17.5 para q u e incluy a varios u n c o n ju n to d e c a s o s d e p ru e b a p a ra e l s is te m a HogarSeguro
pesos de e n la c e .A m p líe la h e rra m ie n ta p a ra q u e p ro c e s e la s p ro d e s c rito a n te rio rm e n te e n e l lib ro .
babilidades d e e je cu c ió n o lo s tie m p o s d e p ro c e so d e en laces. 17.1 4 . M e d ia n te e l a n á lis is d e v a lo re s lím ite , o b te n g a u n c o n
17.7. U se e l e n fo q u e d e p r u e b a d e c o n d ic io n e s d e s c rito e n la ju n to d e c a s o s d e p r u e b a p a r a e l s is te m a S S R B d e s c rito e n el
Sección 17.5.1 p a r a d is e ñ a r u n c o n ju n to d e c a s o s d e p ru e b a P r o b le m a 12.13.
para el p ro g ra m a c re a d o
e n e l P r o b le m a 17.2. 17.15. In v e s tig u e u n p o c o y e s c rib a u n b r e v e d o c u m e n to so b re
178. M e d ian te e l e n fo q u e d e p ru e b a d e flu jo d e d a to s d e s c ri el m e c a n is m o d e g e n e ra c ió n d e ta b la s o rto g o n a le s p a ra la p r u e
to en la S e c c ió n 1 7 .5 .2 , c re e u n a lis ta d e c a d e n a s d e d e f in i b a d e d a to s.
ción-uso p a ra e l p ro g ra m a c re a d o e n e l P ro b le m a 17.2. 17.1 6 . S e le c c io n e u n a I G U e s p e c ífic a p a r a u n p r o g ra m a c o n
17.9. D ise ñ e u n a h e r ra m ie n ta a u to m á tic a q u e r e c o n o z c a lo s e l q u e e s té f a m ilia riz a d o y d is e ñ e u n a s e rie d e p r u e b a s p a ra
bucles y lo s c la s ifiq u e c o m o in d ic a la S e c c ió n 17.5.3. e je r c ita r la IG U .
17.10. A m p líe la h e rra m ie n ta d e sc rita e n e l P ro b le m a 1 7 .9 p a ra 1 7 .1 7 . In v e s tig u e e n u n s is te m a C lie n te /S e r v id o r q u e le se a
que genere c a s o s d e p ru e b a p a ra c a d a c a te g o ría d e b u c le , c u a n fa m ilia r. D e s a rr o lle u n c o n ju n to d e e s c e n a r io s d e u s u a rio y
do los e n cu e n tre . S e rá n e c e s a rio lle v a r a c a b o e s ta f u n c ió n d e g e n e re u n p e rfil o p e ra c io n a l p a r a e l siste m a .
forma in te ra c tiv a c o n e l e n c a rg a d o d e la p ru e b a . 1 7 .1 8 . P ru e b e u n m a n u a l d e u s u a rio (o u n a fa c ilid a d d e a y u
17.11. D é p o r lo m e n o s tr e s e je m p lo s e n lo s q u e la p ru e b a d e d a ) d e u n a a p lic a c ió n q u e u tilic e fre c u e n te m e n te . E n c u e n tre
caja n egra p u e d a d a r la im p re s ió n d e q u e « to d o e s tá b ie n » , al m e n o s u n e rro r e n la d o c u m e n ta c ió n .
WBéhias lec t u r a s y fu e n t e s de in f o r m a c ió n
La in g e n ie ría d e l s o ftw a re p re s e n ta ta n to d e s a fío s té c n ic o s to s e sp e c ia le s q u e d e b e n c o n sid e ra rse c u a n d o se p ru e b a n g ra n

como de gestión. L o s lib ro s d e B la c k (,Managing the TestingPro- d e s siste m a s d e p ro g ra m a c ió n .
cess, M icrosoft P re ss, 1999), D u s tin , R a s h k a y P a u l (Testpro- L a p r u e b a d e l s o ftw a re e s u n r e c u rs o e n c o n tin u a a c tiv i
cess Improvement: Step-By-Step Guide to Structured Testing, d a d . E s p o r e s ta ra z ó n p o r lo q u e m u c h a s o r g a n iz a c io n e s a u to -
Addison-W esley, 1999), P e n y (Surviving the TopTenChallen- m a tiz a n p a rte d e lo s p ro c e s o s d e p ru e b a . Los lib ro s d e D u s tin ,
ges of Software TestingA People-Oriented Approach, D o rs e t R a s h k a y P o s to n (AutomatedSoftware Testing: Introduction,
House, 1997),y K i t y F in z i (SofbvareTestingin the Real World: Management, and Performance, A d d is o n - W e s le y , 1 9 9 9 ) y
Improving the Process, A d d iso n -W esley , 1995) o rie n ta n so b re P o s to n ( Automating Specification-Based Software Testing,
las necesidades d e g e stió n y d e p ro c e so s . IE E E C o m p u te r S o c ie ty , 1 9 9 6 ) h a b la n s o b re h e r ra m ie n ta s ,
P ara a q u e llo s le c to re s q u e d e se e n ‘ in fo rm a c ió n a d ic io n a l e s tra te g ia s y m é to d o s p a r a a u to m a tiz a r la p ru e b a . U n a e x c e
sobre la te c n o lo g ía d e p r u e b a d e l s o ftw a r e , e x is te n v a r io s le n te fu e n te d e in fo rm a c ió n s o b re h e r ra m ie n ta s a u to m a tiz a
libros e x ce le n tes. K a n e r, N g u y e n y F a lk (Testing Computer d a s d e p r u e b a l a e n c o n t r a m o s e n Testing Tools Reference
Software,W ile y ,1999), E lu tc h e s o n ( S o fi a re TestingMethods Guide (S o ftw a re Q u a lity E n g in e e rin g , In c ., J a c k s o n v ille , F L ,
andMetrics: TheM ost Important Test, M c G ra w -H ill, 19 9 7 ), a c tu a liz a d a a n u a lm e n te ) . E s te d ir e c to r io c o n tie n e d e s c r i p
Marick (The Craft o f Software Testing: Subsystem Testing c io n e s d e c ie n to s d e h e rra m ie n ta s d e p r u e b a , c la s ific a d a s p o r
Including Object-Based and Object-Oriented Testing, P r e n tip o d e p ru e b a , p la ta fo rm a h a rd w a r e y s o p o rte s o ftw a re .
tice-Hall, 1995), J o rg e n s e n (Software Testing:A Craftman’s A lg u n o s lib ro s tr a ta n lo s m é to d o s y e s tr a te g ia s d e p ru e b a
Approach, C R C P r e s s , 1 9 9 5 ) p r e s e n ta n e s tu d io s s o b re lo s e n á re a s d e a p lic a c ió n e sp e c ia liz a d a .G a rd in e r(7 e s//> 7 g 5 'a /e fy -
m étodos y e s tra te g ia s d e p ru e b a . Related Software: A Practical Handbook, S p r in g e r V e rla g ,
M yers [M Y E 79] p e rm a n e c e c o m o u n te x to c lá sic o , c u b rie n 19 9 9 ) h a e d ita d o u n lib ro q u e tr a ta la p r u e b a e n s is te m a s d e
do con c o n sid e ra b le d e ta lle la s té c n ic a s d e c a ja n e g ra . B e iz e r s e g u r id a d c rític a . M o s le y (Client/Server Software Testing on
[BEI90] d a u n a a m p lia c o b e rtu ra d e la s té c n ic a s d e caj a b la n c a , the Desk Top and the Web, P re n tic e H a ll, 1 9 9 9 ) tr a ta la p r u e
introduciendo c ie rto n iv e l d e rig o r m a te m á tic o q u e a m e n u d o se b a p a r a c li e n te s , s e r v id o r e s y c o m p o n e n t e s e n r e d . R u b in
echa en falta e n o tro s tra ta d o s so b re la p ru e b a. S u ú ltim o lib ro (H andbookof Usability Testing, W ile y , 1 9 9 4 ) h a e s c r ito u n a
[BEI95] p re sen ta u n tra ta d o c o n c is o d e m é to d o s im p o rta n te s. g u ía ú til p a ra lo q u e n e c e s ita n m a n e ja r in te r fa c e s h u m a n a s.
Peny (EjfectiveMethodsfo r Software TestingfN'ú&y-QED, 1995),
U n a a m p lia v a rie d a d d e fu e n te s d e in fo rm a c ió n sobre
y F re e m a n y Voas ( Sofi areAssesment: Reliability, Sfety, Tes-
p ru e b a s d e l s o ftw a re y e le m e n to s re la c io n a d o s e s tá n
tability, Wiley, 19 9 5 )p resen ta n b u e n a s in tro d u c cio n e s a las estra
tegias y tác tic as d e la s p ru e b a s. M o s le y (TheHandbook ofM IS d is p o n ib le s e n in te rn e t. U n a lis ta a c tu a liz a d a d e r e f e
www.FreeLibros.org
Application Software Testing,P rentice-H all, 1 9 9 3 )e stu d ia asp e c re n c ia s a p á g in a s w e b que son re le v a n te s sobre lo s c o n
tos de las p ruebas p a ra g ra n d es siste m a s d e in fo rm ació n , y M a rk s c e p to s d e p ru e b a , m é to d o s y e s tra te g ia s se p u e d e n
CTesting VeryBig Systems, M cG raw -H ill, 1 9 9 2 )e stu d ia lo s asp e c e n c o n tra r e n h t t p : //w w w .p r e s s m a n 5 .c o m .
www.FreeLibros.org
C A P ÍT U L O
1 Q E S T R A T E G IA S DE PR U E B A
X O DE S O FTW A R E
N A estrateg ia de p ru eb a del softw are integra las técnicas de diseño de casos de prueba
U en u n a serie de pasos bien planificados que dan com o resultado una correcta co n struc
ción del softw are. L a estrategia p roporciona un m ap a que describ e los pasos que hay
que llev ar a cabo co m o parte de la p rueba, cuán d o se deben p lanificar y realizar esos paso s, y
cuánto esfu erzo , tiem po y recursos se van a requerir. P o r tan to , cualquier estrategia de prueba
debe inco rp o rar la planificación de la prueba, el diseño de casos de p rueba, la ejecución de las
p ruebas y la agrupación y evaluación de lo s datos resultantes.
U n a estrateg ia de p rueba del softw are debe ser suficientem ente flexible para prom over la
creatividad y la adaptabilidad necesarias para adecuar la p rueba a todos lo s grandes sistem as
basados en softw are. A l m ism o tiem po, la estrategia debe ser suficientem ente ríg id a para p ro
m o v er un seguim iento razonable de la planificación y la gestión a m ed id a que progresa el p ro
yecto. S hoom an [S H 0 8 3 ] trata estas cuestiones:
E n m uchos aspectos, la p ru eb a es un p roceso individualista, y el núm ero de tipos diferentes de pruebas
varía tan to com o los diferen tes enfo q u es de desarrollo. D urante m uchos años, nuestra Unica d efensa contra
los errores de program ación era un cuid ad o so diseño y la propia inteligencia del program ador. A hora nos
enco n tram o s en una era en la que las técnicas m odernas de diseño [y las revisiones técn icas form ales] nos
ayudan a re d u cir el núm ero de errores iniciales que se encuentran en el código de form a inherente. D e fo r
m a sim ilar, los d iferen tes m étodos de prueba e stán em pezando a agruparse en v arias filosofías y enfoques
diferentes.
VISTAZO RÁPIDO
¿Qué es? El d ise ñ o efectivo d e c a s o s d e v e ch a y e l esfuerzo e s consum ido inne E s ta s p ru e b a s e s t á n d is e ñ a d a s p a r a

' p ru e b a (C a p ítu lo 17) e s im p o rta n te , cesariam e n te y, e n e l p e o r d e los casos, d e sc u b rir e rro re s e n los requisitos.
■ pero ta m b ié n lo e s la e s tra te g ia p a ra los e rro re s in ad v e rtid o s q u e d a rá n sin
¿C uál e s e l p ro d u cto o b te n id o ? El
su u tilización. ¿Se d e b e rá d e sa rro lla r d e te c ta r. Por ta n to , p a re c e ra z o n a b le
e q u ip o d e tr a b a jo q u e d e s a rro lla el
” un p la n fo rm a l p a r a e s t a s p ru e b a s ? . e sta b le c e r u n a e s tra te g ia siste m á tic a
so ftw are d o c u m e n ta la especifícacióa
¿Se d e b e rá p ro b a r e l p r o g ra m a in te p a r a p ro b a r el softw are.
d e la p ru e b a b a s á n d o s e e n l a d e fin í
gram ente o e je cu ta r p ru e b a s solam en- ¿C u á les s e n le s p a se s? La p ru e b a ción d e l p la n q u e e sta b le c e la e s tra te
le sobre u n a p a rte p e q u e ñ a d e l m ismo? co m ien za por d o pequeño» y p ro g resa g ia g e n e ra l y d e l p ro c e d im ie n to q u e
¿Se d e b erá n ejecutar p ru e b a s d e regre- h a c ia «lo grande». Por e s ta razón, d e b e
e sp e c ífic a m e n te d e sc rib e lo s p a s o s a;
; sión c u a n d o se a ñ a d a n n u e v o s com m os c o m e n z a r l a s p r im e ra s p ru e b a s
se g u ir y la s p ru e b a s a re a liz a r
p o n e n te s a l s is te m a ? ¿ C u á n d o se so b re e l co m p o n en te e le m e n ta l y a p li
d e b e rá in v o lu c ra r a l c lie n te ? E sta s y c a r so b re é l p ru e b a s d e c a ja b la n c a y ¿Cómo p u e d o esta r se g u r o d e q u e
otras m u c h a s c u e s tio n e s s e rá n c o n te s d e c a ja n e g ra p a r a d e s c u b rir e rro re s lo h e h e c h o c o r r e c ta m e n te ? L a
ta d a s c u an d o d e sa rro lle s u n a e s tra te • e n la ló g ica y e n la fu n c io n a lid a d d e l re v is ió n d e l a e sp e c ific a c ió n d e la
: g ia d e p ru e b a d e l softw are. p ro g ram a. D e sp u é s d e q u e los com po p ru e b a e s p re v ia a la re aliz a ció n d e la
¿Quién lo h a ce? El jefe d e l proyecto, los n e n te s e le m e n ta le s h a y a n sid o a p ro p ru e b a . S e d e b e v a lo ra r l a c o m p le ti-
in g e n ie ro s d e l so ftw a re y los esp ecia- bados, p ro c e d e re m o s a su in te g rac ió n . tu d d e los c a s o s d e p ru e b a y d e l a s
I lista s e n pru eb as. L as p ru e b a s se e fe c tu a rá n c o n fo n n ee l ta r e a s d e la p ru e b a. Un p la n y u n p ro
¿ P o r q u é e s i m p o r t a n t e ? E n e l p ro softw are s e v a y a construyendo c e d im ie n to d e p ru e b a e fec tiv o p e rm i
t ir á u n a c o n stru c c ió n o r d e n a d a ¿ e i
yecto, la p ru e b a a v e c e s re q u ie re m á s F in a lm e n te , u n a s e rie d e p r u e b a s d e
so ftw are y e l d e sc u b rim ie n to d e e rro
esfuerzo q u e c u a lq u ie r o tra a c tiv id a d a lto n iv e l s e r á n e je c u ta d a s u n a v ez el
re s e n c a d a e ta p a d e l p ro c eso d e co n s
d e la in g e n ie n a d e l software. S is e e fe c p ro g ra m a e s t é to ta lm e n te p re p a ra d o
túa sin u n p lan , e l tiem p o s e d e sa p ro p a r a su o p e rativ id a d . trucción.
E stas « filosofías y enfoques» constituyen lo que nosotros llam arem os estrategia. E n el C apí
tulo 17 se p resentó la tecnología de p ru eb a del softw are'. E n este capítulo centrarem os nuestra
www.FreeLibros.org
atención en las estrategias de p rueba del softw are.
1 Las pruebas de sistem as orientados a objetos se estudian en el Capítulo 23.
305
IN GE NI ER ÍA DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
. ■■■ :m q ú _______- ¿ g i c q i ú i . : - . . h u e s a s ............. _ l. ■. ■

L a s p ru e b a s son u n c o n ju n to d e a c tiv id a d e s q u e se p u e ta a lo s re q u is ito s d e l c lie n te . B o h e m [ B O E 8 1 ] lo d e fi
d e n p la n ific a r p o r a d e la n ta d o y lle v a r a c a b o s is te m á ti ne de o tra fo rm a :
c a m e n te . P o r esta ra z ó n , se d e b e d e fin ir e n e l p ro ce so J e n fca ció n :« ¿ E sta m o s construyendo el producto correc
d e la in g e n ie ría d e l s o ftw a re u n a plantilla p a ra las p ru e tam ente?»
bas d e l s o ftw a re : u n c o n ju n to d e pasos e n lo s que p o d a Validación .«¿Estamos construyendoel producto correcto? »
m o s s itu a r lo s m é to d o s e s p e c ífic o s d e d is e ñ o d e casos
d e p ru e b a . L a d e fin ic ió n d e V & V c o m p re n d e m u c h a s d e las acti
S e h a n p ro p u e s to v a ria s e s tra te g ia s d e p ru e b a d e l v id a d e s a las q u e nos h e m o s re fe rid o c o m o g a ra n tía de
s o ftw a re e n distin to s lib ro s . T o d a s p ro p o rc io n a n al in g e c a lid a d d e l s o ftw a re ( S Q A * ) .
n ie ro d e l s o ftw a re u n a p la n tilla p a ra la p ru e b a y to das L a v e r ific a c ió n y la v a lid a c ió n a b a rc a n u n a a m p lia
tie n e n las s ig u ie n te s c a ra c te rís tic a s g e n erales : lis ta d e a c tiv id a d e s S Q A q u e in c lu y e : re v is io n e s té c
n ic a s fo r m a le s , a u d ito ría s d e c a lid a d y d e c o n fig u r a
• L a s p ru e b a s c o m ie n z a n a n iv e l d e m ó d u lo ’ y tra b a
c ió n , m o n it o r iz a c ió n d e r e n d im ie n t o s , s im u la c ió n ,
j a n « h a c ia fu e ra » , h a c ia la in te g ra c ió n de to d o e l sis
e s tu d io s d e f a c t i b i li d a d , r e v is ió n d e l a d o c u m e n ta
te m a b a sa d o e n c o m p u ta d o ra .
c ió n , r e v is ió n d e la b a s e d e d a to s , a n á lis is a lg o r ítm i
• S e g ú n e l m o m e n to , son a p ro p ia d a s d ife re n te s té c n i c o , p ru e b a s d e d e s a r r o llo , p ru e b a s d e v a lid a c ió n y
c as d e p ru e b a . p ru e b a s d e in s ta la c ió n [ W A L 8 9 ] . A p e s a r d e q u e las
• L a p ru e b a la lle v a a c a b o e l re s p o n s a b le d e l d e s a a c tiv id a d e s d e p r u e b a tie n e n u n p a p e l m u y im p o r
r r o llo d e l s o ftw a r e y (p a r a g ra n d e s p ro y e c to s ) u n ta n te e n V & V , m u c h a s o tra s a c tiv id a d e s son ta m b ié n
g ru p o in d e p e n d ie n te d e pru eb as. n e c e s a ria s .
• L a p ru e b a y la d e p u ra c ió n son a c tiv id a d e s d ife re n
tes, p e ro la d e p u ra c ió n se d e b e in c lu ir e n c u a lq u ie r m m a m m i*
e s tra te g ia de p ru e b a . la s uctívidades SQA son estudiadas en detalle en el
Capítulo 8.
U n a e s tra te g ia d e p ru e b a d e l s o ftw a re d e b e in c lu ir
p ru e b a s d e b a jo n iv e l q u e v e r ifiq u e n q u e to d o s lo s
p e q u e ñ o s s e g m e n to s d e c ó d ig o fu e n te se h a n im p le - L a s p ru e b a s c o n s titu y e n e l ú ltim o b a s tió n desde el
m e n ta d o c o rre c ta m e n te , a sí c o m o p ru e b a s de a lto n iv e l q u e se p u e d e e v a lu a r la c a lid a d y , d e fo rm a m á s p ra g
q u e v a lid e n las p rin c ip a le s fu n c io n e s d e l s is te m a fre n te m á tic a , d e s c u b rir lo s e rro res. P e ro las p ru e b a s n o deben
a lo s re q u is ito s d e l c lie n te . U n a e s tra te g ia d e b e p ro p o r ser v is ta s c o m o u n a re d d e s e g u rid a d . C o m o se suele
c io n a r u n a g u ía a l p ro fe s io n a l y p ro p o rc io n a r u n c o n d e c ir: « N o se p u e d e p ro b a r la c a lid a d . S i n o e s tá a h í
ju n t o d e h ito s p a ra e l j e f e d e p ro y e c to . D e b id o a que los antes d e c o m e n z a r la p ru e b a , n o e sta rá c u a n d o se te r
pasos d e la e s tra te g ia d e p ru e b a se d a n a la v e z c u a n d o m in e .» L a c a lid a d se in c o rp o ra e n e l s o ftw a re d u ra n te
a u m e n ta la p re s ió n d e lo s p la z o s fija d o s , se d e b e p o d e r e l p ro c e s o d e in g e n ie ría d e l s o ftw a re . L a a p lic a c ió n ade
m e d ir e l p ro g re s o y lo s p ro b le m a s d e b e n a p a re c e r l o c u a d a d e lo s m é to d o s y d e las h e rra m ie n ta s , las r e v i
antes p o s ib le . sion es té c n ic a s fo rm a le s e fe c tiv a s y u n a s ó lid a g estió n
y m e d ic ió n , c o n d u c e n a la c a lid a d , q u e se c o n fir m a
d u ra n te las pru eb as.
Referencia Web
Información útil sobre las estrotegiosde pruebo del software
es suministrado en el informe sobre lo Pruebo del Software
en:www.ondaweb.com/stí/newshr.htm
18.1.1. V e r i f i c a c i ó n y v a l i d a c i ó n
L a p ru e b a d e l s o ftw a re es u n e le m e n to d e u n te m a m ás
a m p lio q u e , a m e n u d o , es c o n o c id o c o m o v e rific a c ió n M i l l e r [ M Í L 7 7 ] re la c io n a la p ru e b a d e l s o ftw a re con
y v a lid a c ió n ( V & V ) . L a verificación se re fie re al c o n la g a ra n tía d e c a lid a d a l e s ta b le c e r q u e « la m o tiv a c ió n
ju n to d e a c tiv id a d e s que aseguran que e l s oftw are im p le - su b ya ce n te d e la p ru e b a d e p ro g ra m a s es c o n firm a r la
m e n ta c o rre c ta m e n te u n a fu n c ió n e s p e c ífic a . L a c a lid a d d e l s o ftw a re c o n m é to d o s q u e se p u e d e n a p li
validación se re fie r e a u n c o n ju n to d ife re n te de a c tiv i c a r de fo r m a e c o n ó m ic a y e fe c tiv a , ta n to a g ra n d e s c o m o
d ades q u e a s e g u ra n q u e e l s o ftw a re c o n s tru id o se a ju s a p e q u e ñ o s sistem as».
www.FreeLibros.org
2 Para los sistem as o rientadosa objetos,laspruebas empiezan a nivel * Por lo habitual de su utilización m antenem os el term ino ingles SQA
de clase o de objeto. Vea m ás d e tallesen el Capítulo23. (Softw areQ uality A ssurance).
306
CAPITULO 18 ES TR AT EG IA S DE PRUEB A DEL S O F T W A R E
18.1.2. Organización para las pruebas del software h e ch o de p erm itir al c o n stru c to r que p ru eb e lo que ha
Bl cualquier proyecto de softw are ex iste un conflicto construido. U n a p ru e b a in d ep en d ien te elim in a el c o n
de intereses inherente que aparece cu an d o com ienzan flicto de intereses que, de otro m odo, estaría p re se n
las pruebas. Se pide a la gente que ha construido el soft te. D espués de to d o , al personal del e q u ip o que form a
ware que lo pruebe. E sto parece to talm ente inofensivo: el grupo in d ep en d ien te se le p ag a para que encuentre
después de todo, ¿quién puede con o cer m ejo r un p ro errores.
grama que los que lo h an d esarro llad o ? D esgraciada Sin em bargo, el responsable del desarrollado del soft
mente, esos m ism o s p ro g ram ad o res tie n e n un g ran w are no entrega sim plem ente el program a al G IP y se
interés en dem ostrar que el pro g ram a está libre de e rro desentiende. El responsable del d esa rro llad o y el G IP
res, que funciona de acuerdo con las especificaciones trabajan estrecham ente a lo largo del proyecto de soft
del cliente y que estará listo de acuerdo con los plazos w are para asegurar que se realizan pruebas exhaustivas.
y el presupuesto. C ada u n o de esto s intereses se c o n M ientras se realiza la prueba, el desarrollador debe estar
vierte en inconveniente a la ho ra de encontrar errores a disponible para co rre g ir los errores que se van d e sc u
lo largo del p roceso de prueba. briendo.
Desde un punto de v ista psicológico, el análisis y el
diseño del softw are (junto con la codificación) son tareas
constructivas. El ingeniero del softw are crea un p ro g ra
Sino existe un GIPen tu organización,
ma de com putadora, su d o cu m entacióny sus estructuras
tendrás que asumir su punto de vista.
de datos asociadas. A l igual que cualq u ier constructor, el Cuando pruebes, intenta destrozare! software.
ingeniero del softw are está orgulloso del edificio que aca
ba de construir y se en fren ta a c u alq u iera que intente
sacarle defectos. El G IP es parte del equipo del proyecto de d esarro
Cuando com ienza la prueba, aparece una sutil, aun llo de softw are en el sentido de que se ve im p licad o
que firme intención de «rom per» lo que el ingeniero del durante el proceso de especificación y sigue im plicado
software ha construido. D esde el punto de vista del co n s (planificación y especificación de los procedim ientos
tructor, la prueba se puede considerar (psicológicam ente) de prueba) a lo largo de un gran proyecto. Sin em bar
destructiva. Por tanto, el con stru cto r anda con cuidado, go, en m uchos casos, el G IP inform a a la organización
diseñandoy ejecutando p ruebas que d em uestren que el de g aran tía de calid ad del softw are, c o n sig u ien d o de
programa funciona, en lug ar de detectar errores. D e s este m odo un grado de independencia que no sería p o si
graciadamente, los errores seguirán estando. Y si el in g e ble si fuera una parte de la organización de desarrollo
niero del softw are no los encuentra, ¡el cliente si lo hará! del softw are.
A m enudo, existen ciertos m alentendidos que se pue
dan deducir eq uivocadam ente de la anterior discusión: 18.1.3. U na estra teg ia de prueba del softw are
(1) el responsable del desarrollo no debería entrar en el El proceso de ingeniería del softw are se puede ver com o
proceso de prueba; (2) el softw are debe ser «p u esto a una espiral, com o se ilustra en la F igura 18.1. Inicial
salvo» de extraños que p u ed an p robarlo de form a d es m ente, la ingeniería de sistem as define el papel del soft
piadada; (3) los encargados de la prueba sólo aparecen w are y conduce al análisis de los requisitos del softw are,
en el proyecto cuando com ien zan las etapas de prueba. donde se establece el dom inio de inform ación, la fu n
Todas estas frases son incorrectas. ción, el com portam iento, el rendim iento, las restriccio
El responsable del desarrollo del softw are siem pre nes y los c rite rio s de v a lid a c ió n del so ftw a re . A l
es responsable de p ro b a r las u n id a d e s in d iv id u a le s m ovem os hacia el interior de la espiral, llegam os al d ise
(módulos)del p rogram a, asegurándose de que cada una ño y, p o r últim o, a la codificación. Para desarrollar soft
lleva a cab o la fu n c ió n p a ra la q u e fu e d ise ñ ad a . E n w are de com putadora, dam os vueltas en espiral a través
muchos caso s, ta m b ié n se e n carg ará de la p ru e b a de de una serie de flujos o líneas que dism inuyen el nivel
integración, el paso de las p ruebas que lleva a la co n s de abstracción en cada vuelta,
trucción (y prueba) de la estru ctu ra total del sistem a.
Sólo una vez que la arquitectura del softw are esté c o m ¿Qué es la estrategia global
pleta entra e n ju e g o un grupo independiente de prueba.
• para la prueba del softw are?
Tam bién se puede ver la estrategia para la prueba del

CLAVE softw are en el contexto de la espiral (Fig. 18. l).L a p ru e
ba de u n id ad com ienza en el vértice de la espiral y se
Un grupo ¡ndependientede prueba no tiene el ((conflicto
centra en cada unidad del softw are, tal com o está im ple-
de intereses) que tienen los desarrolladores del software.
m entada en código fuente. L a prueba avanza, al m o v er
www.FreeLibros.org
nos hacia fuera de la espiral, hasta llegar a la p ru e b a de
El pap el del g ru p o in d ep en d ien te de p ru e b a (G IP) in teg ració n , donde el foco de atención es el diseño y la
es elim inar los in h eren tes p ro b lem as aso ciad o s con el construcción de la arquitectura del softw are. D ando otra
307
I N GE NI E RÍ A DEL SOF TW ARE . UN E N F O Q U E P R Á C T I C O
v u e lta p o r la e s p ira l h a c ia fu e ra , e n c o n tra m o s la prue e l m á s a m p lio c o n te x to d e la in g e n ie ría d e sistem as d e

ba de validación, d o n d e se v a lid a n lo s re q u is ito s e sta c o m p u ta d o ra .
b le c id o s c o m o p a rte d e l a n á lis is d e re q u is ito s d e l E l s o ftw a re , u n a v e z v a lid a d o , se d e b e c o m b in a r con
s o ftw a r e , c o m p a rá n d o lo s c o n e l s is te m a q u e h a s id o otros e le m en to s d e l sistem a (p o r e je m p lo , h a rd w are , gen
c o n s tru id o . F in a lm e n te , lle g a m o s a la prueba del siste te , bases d e d a to s ). L a prueba del sistema v e rific a que
ma, e n la q u e se p ru e b a n c o m o u n to d o e l s o ftw a re y c a d a e le m e n to e n c a ja d e fo rm a a d e c u a d a y q ue se alcan
o tro s e le m e n to s d e l s is te m a . P a r a p ro b a r s o ftw a re de z a la fu n c io n a lid a d y e l re n d im ie n to d e l sistem a total.
c o m p u ta d o ra nos m o v e m o s h a c ia fu e ra p o r u n a e s p ira l
q u e , a c a d a v u e lta , a u m e n ta e l a lc an ce d e la p ru e b a .
Prueba del sistema
Prueba de validación, \ n , , ...
_ , , . , Prueba de unidad
Prueba de integración \ \ \ /
v \ \ l
\ \. '1§¡
• ¡Íl¡¡ H ÍÍIÍÉ Ík IS P ^
P S Jr y /
y i
/ ...... '! - ^ rrÛÓdioo de la prueban

j ——“T 'Diseño
Requisitos ‘Ingeniería del sistema F IG U R A 1 8 .2 . E tapas en la prueba del softw are.
F IG U R A 1 8 .1 . Estrategia de prueba.
18.1.4. C riterios p a ra co m p le ta r la p ru eb a
Si consideramos el proceso desde el punto de vista pro- C a d a v e z q u e se tra ta n las p ru e b a s d e l s o ftw a re surge
ced im en tal,la prueba, en el contexto de la ingeniería del u n a p re g u n ta c lá s ic a : ¿ C u a n d o h e m o s te rm in a d o las
softw are, realm ente es u n a serie de cuatro pasos que se pru eb a s? , ¿ c ó m o sab em o s q u e h e m o s p ro b a d o lo sufi
llevan a cabo secuencialm ente. E sos pasos se m uestran c ie n te ? D e s g ra c ia d a m e n te , n o h a y u n a re sp u es ta defi
en la Figura 18.2. Inicialmente, la prueba se centra en cada n it iv a a e s ta p re g u n ta , p e ro h a y a lg u n a s respuestas
m ódulo individualm ente, asegurando que funcionan ade p rá c tic a s y n u e v o s in te n to s d e base e m p íric a .
cuadam ente com o una unidad. De ahí el nom bre de p r u e
ba de unidad. L a prueba de unidad hace un uso intensivo J jjjl ¿Cuándo debemos probar?
de las técnicas de prueba de caja blanca, ejercitando cam i
nos específicos de la estructura de control del m ódulo para
asegurar un alcance com pleto y una detección m áxim a de U n a re sp u es ta a la p re g u n ta a n te rio r es: « L a prueba
errores. A continuación, se deben ensam blar o integrar los n u n c a te rm in a , y a que e l re s p o n s a b le d e l d e s a rro llo del
m ódulos para form ar el paquete de softw are com pleto. La s o ftw a re c a rg a o p a sa e l p ro b le m a al c lie n te .» C ad a vez
p ru e b a de integración se dirige a todos los aspectos aso q u e e l c lie n te /u s u a rio e je c u ta u n p ro g ra m a d e com pu
ciados con el doble problem a de verificación y de cons ta d o ra , d ic h o p ro g ra m a se e stá p ro b a n d o c o n un nuevo
trucción del programa. Durante la integración, las técnicas c o n ju n to d e d a to s . E s te im p o rta n te h e c h o s u b raya la
que m ás prevalecen son las de diseño de casos de prueba im p o rta n c ia d e o tras a c tiv id a d e s d e g a ra n tía de calidad
de caja negra, aunque se p u ed en llev ar a cabo algunas de l s o ftw a re. O tra respu esta (a lg o c ín ic a , p e ro sin embar
pruebas de caja blanca con el fin de asegurar que se cubren g o c ie rta ) es: « S e te rm in a la p ru e b a c u a n d o se agota el
los principales cam inos de control. Después de que el soft tie m p o o e l d in e ro d is p o n ib le p a ra ta l e fe c to .»
ware se ha integrado (construido), se dirigen un conjun A u n q u e a lg u n o s p ro fe s io n a le s se s irv a n d e estas res
to de p r u e b a s de a lto nivel. Se d eben co m probar los p u e s ta s c o m o a rg u m e n to , u n in g e n ie r o d e l softw are
criterios de validación (establecidos durante el análisis de n e c e s ita u n c rite r io m á s rig u ro s o p a ra d e te rm in a r cuan
requisitos). La p ru eb a de validación proporciona una segu d o se h a re a liz a d o la p ru e b a s u fic ie n te . M u s a y Acker-
ridad final de que el softw are satisface todos los requisi m a n [ M U S 8 9 ] s u g ie re n u n a re s p u e s ta b a s a d a en un
tos funcionales, de com portam iento y de rendim iento. c rite r io e sta d ístico : « N o , n o p o d e m o s te n e r la absoluta
D urante la validación se usan exclusivam ente técnicas de c e rte z a d e q u e e l s o ftw a re n u n c a fa lla rá , p e ro en base a
prueba de caja negra. un m o d e lo e s ta d ís tic o d e c o rte te ó ric o y v a lid a d o expe
rim e n ta lm e n te , h e m o s re a liz a d o las p ru e b a s suficientes
l a m a g a a p a ra d e c ir, c o n u n 9 5 p o r 100 de c e rte z a , q u e la proba
Los técnicas de pruebo de cojo blanca y cojo negra b ilid a d d e fu n c io n a m ie n to lib re d e fa llo de 1.0 00 horas
se estudian en el Capítulo 17. de C P U , e n u n e n to rn o d e fin id o d e fo rm a pro babilísti-
www.FreeLibros.org
c a , es a l m e n o s 0 ,9 9 5 .»
El últim o paso de p ru eb a de alto n ivel queda fuera M e d ia n te e l m o d e la d o e s ta d ís tic o y la te o ría de fiabi
de los lím ites de la ingeniería del softw are, entrando en lid a d del so ftw are, se p u ed en d esarro llar m o d e lo s de fallos
308
CAPÍTULO 18 ES TR AT EG IA S DE PR UE BA DEL SOFTW ARE
del software (descubiertos durante las pruebas) como una ro de puntos de datos, el modelo se puede usar para pre
función del tiem po de ejecución. Una versión del m ode decir el tiem po de prueba total requerido para alcanzar
lo de fallos, denominado m odelo logarítm ico de P oisson una intensidad de fallos aceptablemente baja.
de tiempo de ejecución, tom a la siguiente forma:
t I I
f(t) = (Hp) In [(lf)pt + 1)] (1 8 .1 ) ■ Datos recogidos durante la prueba |
donde
f(t) número acumulado de fallos que se espera que
se produzcan una vez que se ha probado el soft
ware durante una cierta cantidad de tiem po de
ejecución t,
l0 la intensidad de fallos inicial del software (fallos
por unidad de tiempo) al principio de la prueba
p la reducción exponencial de intensidad de fallo
a medida que se encuentran los errores y se van
haciendo las correcciones. F IG U R A 18 .3. Intensidad de fallos en función del tiem po
La intensidad de fallos instantánea,/(t)se puede obte de ejecución.
ner mediante la derivada de f( t) :
M ediante la agrupación de métricas durante la prue
l (t )=l 0 / ( l 0 pt + 1) (1 8 .2 ) ba del software y haciendo uso de los modelos de fia
Mediante la relación de la ecuación (18.2), los que bilidad del software existentes, es posible desarrollar
realizan las pruebas pueden predecir la dism inución de directrices im portantes para responder a la pregunta:
errores a medida que estas avanzan. La intensidad de error ¿cuándo term inam os la prueba? No hay duda que toda
real se puede trazarjunto a la curva predecida (Fig. 18.3). vía queda m ucho trabajo por hacer antes de que se pue
Si los datos reales recopilados durante la prueba y el dan establecer reglas cuantitativas para la prueba, pero
modelo logarítmico de Poisson de tiem po de ejecución los enfoques em píricosque existen actualmente son con
están razonablemente cerca unos de otros, sobre un núme siderablemente mejores que la pura intuición.
Más adelante, en este capítulo, exploram os una estrate o frecuencia de ocurrencia, y horas de trabajo por
gia sistemática para la prueba del software. Pero inclu prueba de regresión deberían establecerse dentro de
so la mejor estrategia fracasará si no se tratan una serie la planificación de la prueba [GIL95],
de aspectos invalidantes. Tom Gilb [GIL95] plantea que C om prender qué usuarios van a m anejar el so ft
se deben abordar los siguientes puntos si se desea imple- w are y desarrollar un p e r fil p a r a cada categoría de
mentar con éxito una estrategia de prueba del software: usuario. U sar casos que describan el escenario de
¿Qué debemos hacer para interacción para cada clase de usuario pudiendo redu
§ definir una estrategia de

prueba correcta?
Especificar los requisitos del p ro d u cto de m anera

cu a n tifica b le m u ch o a n te s de que c o m ien cen las
cir el esfuerzo general de prueba concentrando la
prueba en el empleo real del producto.
¿JDJJJ.UIJJJIU.I.l.fc
los casos de usa describen un escenario para usar
pruebas. Aunque el objetivo principal de la prueba el software y se estudianen el CapíLb 11.
es encontrar errores, una buena estrategia de prueba
también evalúa otras características de la calidad,
tales com o la portabilidad, facilidad de m an ten i D esarrollar un p la n de p r u e b a que haga h in ca
miento y facilidad de uso (Capítulo 19). Todo esto p i é en la «prueba de ciclo rápido». Gilb [GIL95]
debería especificarse de manera que sea medible para recom ienda que un equipo de ingeniería del software
que los resultados de la prueba no sean ambiguos.
«aprenda a probar en ciclos rápidos (2 por 100 del
E stablecer los objetivos de la p r u e b a de m anera esfuerzo del proyecto) de increm entos de funciona
explícita. Se deberían establecer en térm inos medi- lidad y/o m ejora de la calidad Utiles para el cliente,
bles los objetivos específicos de la prueba. Por ejem y que se puedan probar sobre el terreno». La reali
www.FreeLibros.org
plo, la efectividad de la prueba, la cobertura de la mentación generada por estas pruebas de ciclo rápido
prueba, tiempo m edio de fallo, el coste para encon puede usarse para controlar los niveles de calidad y
trar y arreglar errores, densidad de fallos remanente las correspondientes estrategias de prueba.
309
ING EN IE RÍA DEL S O F TW A RE . UN EN F O Q U E P R A C T I C O
n ic a s fo rm a le s ( C a p ít u lo 8 ) p u e d e n s er ta n efecti
vas c o m o las p ru e b a s e n e l d e s c u b rim ie n to de erro
ds los requisitos percibidos por e! usuorio res. P o r e ste m o tiv o , la s re v is io n e s p u e d e n reducir
$ 4 es semejante a la inspección de una construcción la c a n tid a d d e e s fu e rz o d e p ru e b a n e c e s a ria para
jssBodo en el trabajo realizado por un decorador p ro d u c ir s o ftw a r e d e a lta c a lid a d .
'&feí9 ol p í o en cimientos, vigas y fontanería. Llevar a cabo revisiones técnicasformalespara
evaluar la estrategia de p ru eb a y los propios casos
de prueba. L a s re v is io n e s té c n ic a s fo rm a le s pueden
C onstruir un software «robusto» diseñado p a ra d e s c u b rir in c o n s is te n c ia s , o m is io n e s y errores cla
probarse a sí mismo. E l s o ftw a re d e b e ría d iseñ arse ros e n e l e n fo q u e d e la p ru e b a . E s to a h o rra tiempo
de m a n e ra que use técn icas d e d e p u ra c ió n a n tie rro re s y ta m b ié n m e jo r a la c a lid a d d e l p ro d u c to .
(S e c c ió n 1 8 .3 .1 ). E s d e c ir, e l s o ftw a re d e b e r ía ser
D esarrollar un enfoque de m ejora continua al
c a p a z de d ia g n o s tic a r c ie rta s clases d e e rro re s. A d e
proceso de prueba. D ebería medirse la estrategia
m á s , e l d is e ñ o d e b e ría in c lu ir p ru e b a s a u to m a tiz a d a s
de p ru eb a . L a s m é tr ic a s a g ru p a d a s d u ra n te la
y pru ebas de re g re s ió n .
p ru e b a d e b e ría n usarse c o m o p a rte d e un enfoque
U sar revisiones técnicas fo r m a le s efectivas e s ta d ís tic o d e c o n tr o l d e l p ro c e s o p a ra la prueba
com ofiltro antes de la prueba. L a s re v is io n e s té c d e l s o ftw a re .
L a p ru e b a de u n id a d c e n tra e l p ro c e s o de v e r ific a c ió n
e n la m e n o r u n id a d d e l d is e ñ o d e l s o ftw a re : e l c o m p o
n e n te s o ftw a re o m ó d u lo .
Interiaz
E stru c tu ra s d e d a to s lo c a le s
18.3.1. C o n s id e r a c io n e s s o b r e l a p r u e b a d e u n i d a d
L a s p ru e b a s q u e se d a n c o m o p a rte d e la p ru e b a d e u n i C o n d icio n e s lím ite
da d están e sq u e m ática m en te ilu strad as e n la F ig u ra 18.4. C a m in o s in d e p e n d ie n te s

S e p ru e b a la in te rfa z d e l m ó d u lo p a ra a s e g u ra r q u e la C a m in o s d e m a n e jo d e e rro re s
in fo r m a c ió n flu y e d e fo r m a a d e c u a d a h a c ia y desde la
u n id a d de p ro g ra m a q u e e stá s ie n d o p ro b a d a . Se e x a
m in a n las e stru ctu ra s d e datos lo c a le s p a ra a s e g u ra r que
lo s d a to s q u e se m a n tie n e n te m p o ra lm e n te c o n s e rv a n
su in te g rid a d d u ra n te to d o s lo s pasos d e e je c u c ió n d e l
a lg o ritm o . Se p ru e b a n las c o n d ic io n e s lím it e p a ra ase
g u ra r que e l m ó d u lo fu n c io n a c o rre c ta m e n te e n los l ím i
tes e s ta b le c id o s c o m o re s tric c io n e s d e p ro c e s a m ie n to .
Se e je rc ita n to d o s lo s c a m in o s in d e p e n d ie n te s (c a m i
nos b ásicos) de la e s tru c tu ra de c o n tro l c o n e l fin de ase
g u ra r que to d as las s en ten c ias d e l m ó d u lo se e je c u ta n
p o r lo m e n o s u n a v e z . Y , fin a lm e n te , se p ru e b a n to d o s
F IG U R A 1 8.4. Prueba de unidad.
los c a m in o s d e m a n e jo d e errores.
D u ra n te la p ru e b a d e u n id a d , la c o m p ro b a c ió n selec
tiv a de lo s c a m in o s d e e je c u c ió n es u n a ta re a esencial.
Se d e b e n d is e ñ a r casos d e p ru e b a p a ra d e te c ta r errores
d eb id o s a c álcu lo s inco rrecto s,co m paracion esin correctas
o flu jo s d e c o n tro l in a p ro p ia d o s . L a s p ru e b a s d e l cam i
Prueba de Unidad. n o b á s ic o y d e b u c le s son té c n ic a s m u y e fe c tiv a s para
A n te s d e in ic ia r c u a lq u ie r o tra p ru e b a es p re c is o p r o d e s c u b rir u n a g ra n c a n tid a d de e rro re s e n lo s cam inos.
b a r e l f lu jo d e d a to s d e la in te rfa z d e l m ó d u lo . S i los
¿Qué errores son los mós comunes
datos n o e n tra n c o rre c ta m e n te , to d as las d e m ás p ru eb a s
n o tie n e n s en tid o . A d e m á s d e las estru ctu ra s d e da to s
§ durante la prueba de unidad?
www.FreeLibros.org
lo c a le s , d u ra n te la p ru e b a de u n id a d se d e b e c o m p ro b a r
(e n la m e d id a de lo p o s ib le ) e l im p a c to d e lo s datos g l o E n tre los e rro re s m ás c o m u n e s e n lo s c á lc u lo s están:
b a le s sobre e l m ó d u lo . (1 ) p re c e d e n c ia a ritm é tic a in c o rre c ta o m a l interpretada;
310
C A P I T U L O 18 ESTRATEGIAS DE PRUE BA DEL S O F T W A R E
(2) operaciones de m o d o m ezcladas; (3) inicializaciones m áxim o o m ínim o perm itidos. L os casos de p rueba que
incorrectas; (4) falta de precisión; (5) incorrecta rep re ejerciten las estructuras de datos, el flujo de co n tro l y
sentación sim bólica de una expresión. L as com paracio los valores de los datos p o r debajo y p o r e n c im a d e los
nes y el flujo de control están fu ertem ente em parejadas m áxim os y los m ínim os son m uy apropiados para d e s
(por ejem plo, el flujo de control cam bia frecuentem ente cubrir estos errores.
tras una com paración). L os casos de p ru eb a deben d es
cubrir errores com o: (1) c o m p aracio n es ente tip o s de
datos distintos; (2) operadores lógicos o de precedencia Interfaz
incorrectos; (3) igualdad esperad a cuando los errores de
Estructuras de datos locales
precisión la h acen p oco probable; (4)variables o co m
paraciones incorrectas; (5 ) term in ació n de bucles in a Condiciones límite
propiada o in ex isten te; (6) fa llo d e salid a c u an d o se Caminos independientes
encuentra u n a iteración divergente, y (7 ) v ariab les de
Caminos de manejo de errores
bucles m odificadas de form a inapropiada.
Un buen diseñ o ex ig e que las co n d icio n es de e rro r
sean p revistas de an tem an o y que se d isp o n g a n unos
caminos de m an ejo de erro res que re d irija n o te rm i
nen de u n a fo rm a lim p ia el p ro ceso c u a n d o se dé un
error. Y ourdon [Y O U 75] lla m a a e ste e n fo q u e anti-
purgado. D e sg ra c ia d a m e n te , e x iste u n a te n d e n c ia a
incorporar la m a n ip u la c ió n de erro res en el softw are
y así no probarlo nunca. C om o ejem p lo , sirve u n a h is
toria real: RESULTADOS
Mediante un contrato se desarrolló un importante sistema
F IG U R A 1 8.5. Entorno para la prueba de unidad.
de diseño interactivo.En un módulo de proceso de transaccio
nes, un bromista puso el siguientemensaje de manipulación de
error que aparecía tras una serie de pruebas condicionales que
invocaban varias ramificaciones del flujo de control: ¡ERROR! 18.3.2. Procedim ientos de Prueba de Unidad
NO HAY FORMA DE QUE VD. LLEGUE HASTA AQUÍ. D ebido a que un com ponente no es un p rogram a in d e
¡Este «mensaje de error» fue descubiertoporun cliente duran pendiente, se debe desarrollar para cada p rueba de un i
te la fase de puesta a punto!
dad un softw are que controley/o resguarde. E n la Figura
18.5 se ilustra el entorno para la p ru eb a de unidad. En
la m ayoría de las aplicaciones, un controlador no es m ás
Asegura que tu diseño de pruebes ejecuta todos los caminos
que un «program a principal» que acepta los datos del
pura encontrar errores. Si no lo haces, el camino puede fallar
caso de prueba, p asa estos datos al m ódulo (a ser p ro
al ser invocado, provocando una situación Incierta. bado) e im prim e los resu ltad o s im portantes. L os re s
g u a rd o s sirv en p a ra re e m p la z a r m ó d u lo s que e stá n
sub o rd in ad o s (llam ados por) el co m p o n en te que hay
Entre los errores p otenciales que se deb en co m pro que probar. U n resguardo o un «subprogram a sim ula
bar cuando se evalú a la m anip u lació n de errores están: do» usa la interfaz del m ódulo subordinado,lleva a cabo
1. D escripción ininteligible del error. u n a m ínim a m anipulación de datos, im prim e u n a v e ri
2. El e rro r se ñ a la d o n o se c o rre sp o n d e co n e l e rro r ficac ió n de e n tra d a y d e v u e lv e co n tro l al m ó d u lo de
encontrado. p rueba que lo invocó.
3. La condición de error hace que in tervenga el sistem a
antes que el m ecan ism o de m anejo de errores. ^C O N S E J O ^p .
4. El p ro c e sa m ie n to de la c o n d ic ió n e x c e p c io n al es Hay ocasiones en que no dispones de los recursos para hacer
incorrecto. una prueba unitaria completa. & esta situación, selecchna
5. La d escripción del e rro r no p ro p o rcio n a suficiente b s módulos críticos y aquellos con alto complejidad
inform ación p a ra a y u d a r en la lo c a liz a ció n d e la clclomática y realiza sobre ellos la prueba unitaria.
causa del error.
La prueba de lím ites es la últim a (y probablem ente, L o s controladores y los resguardos son u n a so b re
la más im portante) tarea del paso de la p ru eb a de u n i carga de trabajo. Es decir, am bos son softw are que debe
dad. El softw are falla frecuentem ente en sus condicio desarrollarse (norm alm ente no se aplica un diseñ o fo r
nes lím ite. E s decir, co n fre c u e n cia aparece un e rro r m al) p ero que no se e n tre g a con el p ro d u cto de so ft
www.FreeLibros.org
cuando se p ro cesa el elem ento n -ésim o de un array n- w are final. S i lo s c o n tro la d o re s y re sg u a rd o s son
dim ensional,cuando se hace la i-ésim a rep etición de un sencillos, el trabajo adicional es relativam ente p e q u e
bucle de i p aso s o c u a n d o se e n c u e n tra n los valo res ño. D esgraciadam ente, m uchos com ponentes no p u e
311
den ten er una adecuada pru eb a unitaria con un « se n ci La prueba de u n idad se sim plifica cu an d o se diseña
llo» softw are adicional. E n tales caso s, la pru eb a co m un m ódulo con un alto g rado de cohesión. Cuando un
pleta se pospone hasta que se lleg u e al paso de prueba m ódulo sólo realiza una función, se reduce el número
de integración (donde tam b ién se u san controladores o de casos de prueba y los errores se pueden predecir y
resguardos). descubrir m ás fácilm ente.
U n neófito del m undo del softw are podría, u n a vez que se puedan pro b ar com pletam ente las interfacesy se pue
se les ha hech o la prueba de u n id ad a todos los m ó d u de a p lic a r un e n fo q u e de p ru eb a siste m á tic a . En las
lo s, c u e s tio n a r de fo rm a a p a re n te m e n te le g ítim a lo siguientes secciones se tratan varias estrategias de inte
siguiente: «Si todos fu ncionan b ien p o r separado, ¿por gración increm ental diferentes.
qué dudar de que funcio n en tod o s ju n to s?» P or supues
to, el p roblem a es «ponerlos ju n to s» (interacción). Los 18.4.1. Integración descendente
datos se pu ed en p erd er en una interfaz; un m ódulo pue
L a p r u e b a de integración descendente es un plantea
de ten er un efecto adverso e in advertido sobre otro; las
m iento increm ental a la construcción de la estructura de
subfunciones, cu an d o se co m b in an , pu ed en no pro d u
program as. Se integran los m ódulos m oviéndose hacia
cir la función principal deseada; la im precisión ac ep
abajo p o r la je ra rq u ía de co n tro l, c o m en zan d o por el
ta d a in d iv id u a lm e n te p u ed e c re c e r h a sta n iv e le s
m ódulo de control principal (program a principal). Los
inaceptables; y las estructuras de d ato s g lo b ales p u e
m ó d u lo s su b o rd in a d o s (su b o rd in a d o s de cualquier
den p re se n ta r p ro b lem as. D e sg raciad am en te, la lista
m odo) al m ódulo de control principal se van incorpo
sigue y sigue.
rando en la estructura, bien de form a primero-en-pro-
La pru eb a de integración es una técnica sistem ática
fu n d id a d , o bien de fo rm aprim ero-en-cm chura.
para construir la estructura del pro g ram a m ientras que,
al m ism o tiem po, se llevan a cab o p ruebas p ara d etec
tar errores asociados con la interacción. El objetivo es
cog er los m ódulos probados m ediante la pru eb a de un i Cuando desarrollas una planificación detallada del
dad y construir una estructura de pro g ram a que esté de proyecto debes considerar la manera en que la
acuerdo con lo que dicta el diseño. integración se va a realizar, de formo que los
componentes estén disponibles cuando se necesiten.
ONSEJÓ^
Efectuar una integración big bag es una estrategia vaga C om o se m uestra en la Figura 18.6, la integraciónpri-
que está condenada al fracaso, la prueba de integración m ero-en-profundidad integra todos los m ódulos de un
deberó ser conducida incrementalmente. cam ino de control principal de la estructura. La selección
del cam ino principal es, de alguna m anera, arbitraria y
dependerá de las características específicas de la aplica
A m enudo hay una ten d en cia a inten tar un a integra
ción. P or ejem plo, si se elige el cam ino de la izquierda,
ción no increm ental; es decir, a construir el p rogram a
se integrarán prim ero los m ódulos M 1, M 2 y M 5. A con
m ediante un enfoque de «big bang». Se com binan todos
tinuación, se integrará M8 o M 6 (si es necesario para un
los m ódulos p o r anticipado. Se pru eb a todo el p ro g ra
fu n cionam ientoadecuadode M2). A cto seguido se cons
m a en c o n ju n to . ¡N o rm alm en te se lleg a al caos! Se
truyen los cam inos de control central y derecho. La inte
encuentran un gran conjunto de errores. L a corrección
gración prim ero-en-anchura incorpora todos los módulos
se hace difícil, p uesto que es com plicado aislar las cau
directam ente subordinadosa cada nivel, m oviéndose por
sas al tener delante el pro g ram a entero en toda su ex ten
la estructura de form a horizontal. Según la figura, los pri
sión. U na vez que se corrigen esos errores aparecen otros
m eros m ódulos que se integran son M 2, M 3 y M4. A con
nuevos y el p roceso continúa en lo que parece ser un
tinuación, sigue el siguiente nivel de control, M 5, M6, etc.
ciclo sin fin.
L a integración increm ental es la antítesis del e n fo
§
¿ Cuáles son los pasos para una
que del «big bang». El pro g ram a se construye y se prue integración top-down?
ba en p equeños segm entos en los que los erro res son
El proceso de integración se realiza en una serie de
m ás fáciles de aislar y de corregir, es m ás p robable que
cinco pasos:
www.FreeLibros.org
3 Las estrategias de integración para sistemas orientados a objetos
se tratan en el Capitulo 23.
312
C A P I T U L O 18 ES TR AT EG IA S DE P RU EB A DEL S O F T W A R E
1. Se usa el módulo de control principal como contro lo g í s t ic o s . E l m á s c o m ú n d e e s to s p r o b le m a s s e d a c u a n

lador de la prueba, disponiendo de resguardos para d o s e r e q u ie r e u n p r o c e s o d e lo s n iv e le s m á s b a jo s d e
todos los módulos directamente subordinados al la je r a r q u í a p a r a p o d e r p r o b a r a d e c u a d a m e n te lo s n iv e
módulo de control principal. le s s u p e r i o r e s . A l p r i n c i p i o d e l a p r u e b a d e s c e n d e n t e ,
2. Dependiendodel enfoque de integración elegido (es l o s m ó d u l o s d e b a j o n i v e l s e r e e m p l a z a n p o r resguar
decir, primero-en-profundidado primero-en-anchura) dos; p o r t a n t o , n o p u e d e n f l u i r d a t o s s i g n i f i c a t i v o s h a c i a
sevan sustituyendo uno a uno los resguardos subor a r r ib a p o r la e s tr u c tu r a d e l p r o g r a m a . E l r e s p o n s a b le d e
dinados por los módulos reales. l a p r u e b a t i e n e t r e s o p c i o n e s : ( 1 ) r e t r a s a r m u c h a s d e la s
p r u e b a s h a s ta q u e lo s r e s g u a r d o s s e a n r e e m p la z a d o s p o r
3. Se llevan a cabo pruebas cada vez que se integra un
lo s m ó d u lo s r e a le s ; ( 2 ) d e s a r r o ll a r r e s g u a r d o s q u e r e a
nuevo módulo.
lic e n fu n c io n e s lim it a d a s q u e s im u le n lo s m ó d u lo s r e a
4. Tras terminar cada conjunto de pruebas, se reem l e s ; o (3) i n t e g r a r e l s o f t w a r e d e s d e e l f o n d o d e l a
plaza otro resguardo con el módulo real. je r a r q u í a h a c ia a r r ib a .
5. Se hace la prueba de regresión (Sección 1 8 .4 .3 )
para asegurarse de que no se han introducido erro éjk
¿Qué problemas puedes encontrar
res nuevos. 9 cuando elijas una estrategia
El proceso continúa desde el paso 2 hasta que se haya de integración descendente?
construido la estructura del programa entero.
E l p r im e r e n fo q u e ( r e tr a s a r p r u e b a s h a s ta r e e m p la
z a r lo s r e s g u a r d o s p o r lo s m ó d u lo s r e a le s ) h a c e q u e p e r
d a m o s c ie r t o c o n t r o l s o b r e la c o r r e s p o n d e n c ia d e c ie r ta s
p r u e b a s e s p e c íf ic a s c o n la in c o r p o r a c ió n d e d e t e r m in a
dos m ó d u l o s . E s t o p u e d e d i f i c u l t a r l a d e t e r m i n a c i ó n d e
la s c a u s a s d e l e r r o r y t ie n d e a v i o l a r la n a t u r a le z a a lt a
m e n te r e s tr ic tiv a d e l e n fo q u e d e s c e n d e n te . E l s e g u n d o
e n fo q u e e s fa c tib le p e r o p u e d e lle v a r a u n s ig n if ic a t iv o
in c r e m e n t o d e l e s fu e r z o a m e d id a q u e lo s r e s g u a r d o s se
h a g a n más c o m p l e j o s . E l t e r c e r e n f o q u e , d e n o m i n a d o
p r u e b a a s c e n d e n te , s e e s t u d ia e n la s ig u ie n t e s e c c ió n .
18.4.2. I n te g r a c ió n a s c e n d e n t e
FIG U R A 1 8 .6 . Integración descendente,
L a p r u e b a d e la in te g r a c ió n a s c e n d e n te , c o m o s u n o m
La estrategia de integración descendente verifica los b r e in d ic a , e m p ie z a la c o n s t r u c c ió n y la p r u e b a c o n lo s
puntos de decisión o de control principales al principio m ódulos atóm icos ( e s d e c i r , m ó d u l o s d e l o s n i v e l e s m á s
delprocesodeprueba. En una estructurade programabien b a jo s d e la e s t r u c t u r a d e l p r o g r a m a ) . D a d o q u e lo s
fabricada, la toma de decisiones se da en los niveles supe m ó d u lo s s e in t e g r a n d e a b a jo h a c ia a r r ib a , e l p r o c e s o
riores de lajerarquíay , por tanto, se encuentranantes. Si r e q u e r id o d e lo s m ó d u lo s s u b o r d in a d o s s ie m p r e e s tá
existenproblemas generales de control, es esencial reco d is p o n ib le y s e e lim in a la n e c e s id a d d e r e s g u a r d o s .
nocerlos cuanto antes. Si se seleccionala integraciónpri
mero en profundidad, se puede ir implementando y ¿Cuáles son los pasos para
demostrandolas funciones completas del software. Por una integraciónascendente?
ejemplo, considere una estructuraclásica de transacción
(Capítulo 14) en la que se requiere una compleja serie de S e p u e d e im p le m e n ta r u n a e s tr a t e g ia d e in t e g r a c ió n
entradas interactivas, obtenidas y validadas por medio de a s c e n d e n te m e d ia n t e lo s s ig u ie n t e s p a s o s :
un camino de entrada. Ese camino de entradapuede ser 1 . S e c o m b i n a n l o s m ó d u l o s d e b a j o n i v e l e n g rupos ( a
integradoenformadescendente. Así, se puede demostrar v e c e s d e n o m in a d o s c o n s tr u c c io n e s ) q u e r e a lic e n u n a
todoel proceso de entradas (paraposteriores operaciones s u b f u n c ió n e s p e c íf ic a d e l s o ftw a r e .
dotransacción) antes de que se integren otros elementos 2. S e e s c r i b e u n c o n t r o l a d o r ( u n p r o g r a m a d e c o n t r o l
dola estructura. La demostración anticipada de las posi d e la p r u e b a ) p a r a c o o r d in a r la e n tr a d a y la s a lid a d e
bilidades funcionales es un generador de confianzatanto lo s c a s o s d e p ru e b a .
para el desanollador como para el cliente.
3. S e p r u e b a e l g r u p o .
4. S e e l i m i n a n l o s c o n t r o l a d o r e s y se c o m b i n a n l o s g r u
p o s m o v ié n d o s e h a c ia a r r ib a p o r la e s t r u c t u r a d e l
lo fabricación es ¡m portanteporo ciertos estilos de
arquitectura. Para más detalles ver el Capítulo 14.. p ro g ra m a .
www.FreeLibros.org
L a in t e g r a c ió n s ig u e e l e s q u e m a ilu s t r a d o e n la F i g u
La estrategia descendenteparece relativamente fácil, r a 1 8 . 7 . S e c o m b in a n lo s m ó d u lo s p a r a f o r m a r l o s g r u
pero, en la práctica, pueden surgir algunos problemas p o s 1 ,2 y 3. C a d a u n o d e l o s g r u p o s s e s o m e t e a p r u e b a
313
I N GEN IE RI A DEL S OFT W ARE . UN EN F O Q U E P R A C T I C O
m e d ia n te u n c o n t r o la d o r ( m o s tr a d o c o m o u n b lo q u e o l o s d a t o s q u e l o s o p o r t a n ) . L a p r u e b a d e r e g r e s i ó n es
p u n te a d o ) . L o s m ó d u lo s d e lo s g r u p o s 1 y 2 s o n s u b o r l a a c t i v i d a d q u e a y u d a a a s e g u r a r q u e l o s c a m b i o s ( d e b i
d in a d o s d e M ,. L o s c o n tr o la d o r e s D j y D 2 s e e lim in a n d o s a la s p r u e b a s o p o r o t r o s m o t i v o s ) n o i n t r o d u c e n u n
y lo s g r u p o s in t e r a c c io n a n d ir e c t a m e n t e c o n M ,. D e f o r c o m p o r t a m ie n t o n o d e s e a d o o e r r o r e s a d ic io n a le s .
m a s im ila r , se e lim in a e l c o n tr o la d o r D 3 d e l g r u p o 3
a n te s d e la in t e g r a c ió n c o n e l m ó d u lo M ,. T a n t o M ,
c o m o M , s e in te g r a r á n f in a lm e n t e c o n e l m ó d u lo M c y
a s í s u c e s iv a m e n te . la prueba de regresión es una estrategia importantepara
reducir «efectos colaterales». Se deben ejecutor pruebas
de regresión cada vez que se realice un cambó
importanteen el software (incluyéndola ¡ntegraclónde
CLA VE nuevos módulos).
I a rfe g a d ó n a a a x fite elimina la La prueba de regresión se puede hacer manualmen

neaesdad de resguardoscomplejos. te, volviendo a realizar un subconjunto de todos lo s
casos de prueba o utilizando herram ientas automáticas
A m e d id a q u e la in t e g r a c ió n p r o g r e s a h a c ia a r r ib a , de reproducción de captura. Las herram ientas de repro
d i s m in u y e la n e c e s id a d d e c o n t r o la d o r e s d e p r u e b a d i f e ducción de ca p tu ra perm iten al ingeniero del softwa
r e n te s . D e h e c h o , s i lo s d o s n iv e le s s u p e r io r e s d e la re capturar casos de prueba y los resultados para la
e s tr u c tu r a d e l p r o g r a m a se in te g r a n d e f o r m a d e s c e n subsiguiente reproducción y com paración. El conjun
d e n te , s e p u e d e r e d u c ir s u s t a n c ia lm e n te e l n ú m e r o d e to de pruebas de regresión (el subconjunto de pruebas
c o n tr o la d o r e s y s e s im p lif i c a e n o r m e m e n te la in t e g r a a realizar) contiene tres clases diferentes de casos de
c ió n d e g r u p o s . prueba:
• una m uestra representativa de pruebas que ejercite
18.4.3. P ru eb a d e re g r e sió n todas las funciones del software;
C a d a v e z q u e se a ñ a d e u n n u e v o m ó d u lo c o m o p a r te d e « pruebas adicionales que se centran en las funciones
u n a p r u e b a d e in t e g r a c ió n , e l s o f t w a r e c a m b ia . S e e s ta del software que se van a ver probablem ente afecta
b le c e n n u e v o s c a m in o s d e f lu jo d e d a to s , p u e d e n o c u das por el cambio;
r r i r n u e v a s E /S y se in v o c a u n a n u e v a ló g ic a d e c o n tr o l.
. pruebas que se centran en los componentes del soft
E s to s c a m b io s p u e d e n c a u s a r p r o b le m a s c o n f u n c io n e s
ware que han cambiado.
q u e a n te s tr a b a ja b a n p e r fe c ta m e n te . E n e l c o n te x t o d e
A m edida que progresa la prueba de integración, el
u n a e s tr a te g ia d e p r u e b a d e in t e g r a c ió n , la p r u e b a d e
núm ero de pruebas de regresión puede crecer demasia
r e g r e s ió n e s v o lv e r a e je c u ta r u n s u b c o n ju n to d e p r u e
do. Por tanto, el conjunto de pruebas de regresión debe
b a s q u e se h a n lle v a d o a c a b o a n te r io r m e n te p a r a a s e
ría diseñarse para incluir sólo aquellaspruebas que traten
g u r a r s e d e q u e lo s c a m b io s n o h a n p r o p a g a d o e fe c to s
una o m ás clases de errores en cada una de las f u n c i o
c o la te r a le s n o d e s e a d o s .
nes principales del programa. No es práctico ni eficiente
volver a ejecutar cada prueba de cada función del pro
gram a después de un cambio.
18.4.4. P r u e b a d e h u m o
L a prueba de hum o es un m étodo de prueba de inte
gración que es com únm ente utilizada cuando se ha
desarrollado un producto softw are «empaquetado».
Es diseñado com o un m ecanism o para proyectos crí
ticos por tiem po, perm itiendo que el equipo de soft
w are v alore su p royecto sobre una base sólida. E n
esencia, la prueba de hum o com prende las siguientes
actividades:
1. Los componentes software que han sido traducidos
a código se integran en una «construcción». Una
F IG U R A 18.7. Integración ascendente. construcción incluye ficheros de datos, librerías,
m ódulos reutilizables y componentes de ingeniería
E n u n c o n t e x t o m á s a m p l i o , la s p r u e b a s c o n é x i t o
que se requieren para im plementar una o más fun
( d e c u a lq u ie r t ip o ) d a n c o m o r e s u lta d o e l d e s c u b r im ie n to
ciones del producto.
www.FreeLibros.org
d e e r r o r e s , y lo s e r r o r e s h a y q u e c o r r e g ir lo s . C u a n d o se
c o r r ig e e l s o ftw a r e , s e c a m b ia a lg ú n a s p e c to d e la c o n 2. Se diseña una serie de pruebas para descrubir erro
f ig u r a c ió n d e l s o ftw a r e ( e l p r o g r a m a , s u d o c u m e n ta c ió n res que im piden a la construcción realizar su fun
314
CAPITULO 18 ES TR A TE G IA S DE PRUEBA DEL SOFTW ARE
c ió n a d e c u a d a m e n t e . E l o b je t iv o s e r á d e s c u b r i r e r r o in t e g r a c ió n , e s p r o b a b le q u e lo s e r r o r e s s in d e s c u
re s « b lo q u e a n t e s » q u e te n g a n la m a y o r p r o b a b i l i b r i r d u r a n t e la p r u e b a d e h u m o s e a s o c ie n a « n u e v o s
d a d d e im p e d ir a l p r o y e c to d e s o ftw a r e e l in c r e m e n to s d e s o ftw a r e » - e s t o e s , e l s o ftw a r e q u e
c u m p lim ie n to d e s u p la n if ic a c ió n . s e a c a b a d e a ñ a d ir a la c o n s t r u c c ió n e s u n a p o s ib le
c a u s a d e u n e r r o r q u e s e a c a b a d e d e s c u b r ir — .
3. E s h a b it u a l e n la p r u e b a d e h u m o q u e la c o n s t r u c c ió n
s e in t e g r e c o n o t r a s c o n s t r u c c i o n e s y q u e s e a p l i c a u n a . E l progreso esfá cil de observar. C a d a d í a q u e p a s a ,
p ru e b a d e h u m o a l p r o d u c to c o m p le t o ( e n s u fo r m a s e in t e g r a m á s s o ftw a r e y s e d e m u e s tr a q u e f u n
a c t u a l) . L a i n t e g r a c i ó n p u e d e h a c e r s e b i e n d e f o r m a c io n a . E s to m e jo r a la m o r a l d e l e q u ip o y d a u n a
d e s c e n d e n t e (top-down)o a s c e n d e n t e (bottom-up). in d ic a c ió n a lo s g e s to r e s d e l p r o g r e s o q u e s e e s tá
r e a liz a n d o .
CLAVE 18.4.5. C o m e n t a r i o s s o b r e l a p r u e b a d e i n t e
la prueba de humo se caracteriza por una estrategia de integración g r a c ió n
continua. El software es reconfigurado (con la incorporación de
H a h a b id o m u c h o s e s tu d io s ( p o r e je m p lo , [ B E I 8 4 ] )
nuevos componentes) y utilizado continuamente.
s o b r e la s v e n t a ja s y d e s v e n t a ja s d e la p r u e b a d e in t e
g r a c ió n a s c e n d e n te fr e n te a la d e s c e n d e n te . E n g e n e
La f r e c u e n c i a c o n t i n u a d e la p r u e b a c o m p l e t a d e l r a l , la s v e n t a j a s d e u n a e s t r a t e g i a t i e n d e n a c o n v e r t i r s e
p ro d u c to p u e d e s o r p r e n d e r a a lg u n o s le c to r e s . E n c u a l e n d e s v e n t a j a s p a r a la o t r a e s t r a t e g i a . L a p r i n c i p a l d e s
q u ie r c a s o , la s f r e c u e n t e s p r u e b a s d a n a g e s t o r e s y p r o v e n t a ja d e l e n f o q u e d e s c e n d e n te e s la n e c e s id a d d e
f e s io n a le s u n a v a l o r a c i ó n r e a l i s t a d e l a e v o l u c i ó n d e la s r e s g u a r d o s y la s d i f ic u lt a d e s d e p r u e b a q u e p u e d e n
p m e b a s d e in t e g r a c ió n . M c C o n n e ll [ M C 0 9 6 ] d e s c r ib e e s ta r a s o c ia d o s c o n e llo s . L o s p r o b le m a s a s o c ia d o s
la p r u e b a d e h u m o d e l a s i g u i e n t e f o r m a : c o n lo s r e s g u a r d o s p u e d e n q u e d a r c o m p e n s a d o s p o r
L a prueba d e h um o e je rc ita el sistem a e n te ro d e p rin l a v e n t a ja d e p o d e r p r o b a r d e a n t e m a n o la s p r i n c i p a
cipio a fin. N o h a de se r e x h a u s tiv a , p e ro se rá c a p a z de l e s f u n c i o n e s d e c o n t r o l . L a p r i n c i p a l d e s v e n t a j a d e la
descubrir im portantes p ro b lem as. L a p ru e b a d e h u m o se rá in t e g r a c ió n a s c e n d e n te e s q u e « e l p r o g r a m a c o m o e n t i
suficiente si v e rific a m o s d e fo rm a c o m p le ta la c o n s tru c d a d n o e x is te h a s ta q u e s e h a a ñ a d id o e l ú l t im o m ó d u
ción y podem os asu m ir q u e es suficien tem en te estable para
lo » [ M Y E 7 9 ] , E s te in c o n v e n ie n t e s e r e s u e lv e c o n la
ser probado c o n m ás profundidad.
m a y o r f a c ilid a d d e d is e ñ o d e c a s o s d e p r u e b a y c o n la
L a p r u e b a d e h u m o f a c i l i t a u n a s e r ie d e b e n e f ic io s fa lta d e re s g u a rd o s .
c u a n d o s e a p lic a s o b r e p r o y e c t o s d e in g e n ie r í a d e l s o f t
w a r e c o m p l e j o s y c r í t i c o s p o r su d u r a c i ó n :
¿Qué es un módulo crítico y
• Se minimizan los riesgos de integración. D a d o q u e
la s p r u e b a s d e h u m o s o n r e a l i z a d a s f r e c u e n t e m e n t e ,
in c o m p a t ib ilid a d e s y o t r o s e r r o r e s b lo q u e a n te s s o n
• por qué debemos identificarlo?
L a s e le c c ió n d e u n a e s tr a te g ia d e in t e g r a c ió n
d e s c u b ie r t o s r á p i d a m e n t e , p o r e s o s e r e d u c e l a p o s i d e p e n d e d e la s c a r a c t e r í s t ic a s d e l s o f t w a r e y , a v e c e s ,
b ilid a d d e im p a c t o s im p o r t a n t e s e n la p l a n i f ic a c ió n
d e la p l a n if ic a c ió n d e l p r o y e c to . E n g e n e r a l, e l m e jo r
p o r e r r o r e s s in d e s c u b r ir .
c o m p r o m is o p u e d e s e r u n e n fo q u e c o m b in a d o ( a v e c e s
• Se perfecciona la calidad del producto final. D a d o d e n o m i n a d o p ru eb a sandw ich) q u e u s e la d e s c e n d e n t e
q u e la p r u e b a d e h u m o e s u n m é t o d o o r i e n t a d o a la p a r a lo s n iv e le s s u p e r io r e s d e la e s t r u c t u r a d e l p r o
c o n s tr u c c ió n ( in t e g r a c ió n ) , e s p r o b a b le q u e d e s c u g r a m a , j u n t o c o n la a s c e n d e n te p a r a lo s n iv e le s s u b o r
b r a e r r o r e s f u n c io n a le s , a d e m á s d e d e fe c to s d e d is e ñ o d in a d o s .
a n iv e l d e c o m p o n e n te y d e a r q u it e c t u r a . S i e s to s A m e d id a q u e p r o g r e s a la p r u e b a d e in te g r a c ió n ,
d e fe c to s s e c o r r ig e n r á p id a m e n te , e l r e s u lta d o s e rá e l r e s p o n s a b le d e la s p r u e b a s d e b e i d e n t i f i c a r lo s
un p r o d u c t o d e g r a n c a l i d a d . m ó d u lo s c r í tic o s . U n m ó d u lo c r í t ic o e s a q u e l q u e t ie
n e u n a o m á s d e la s s ig u ie n t e s c a r a c t e r í s t ic a s : ( 1 ) e s tá
d ir ig id o a v a r io s r e q u is ito s d e l s o ftw a r e ; ( 2 ) tie n e u n
m a y o r n iv e l d e c o n t r o l ( e s tá r e la tiv a m e n te a lt o e n la
diorio es el aliciente del proyecto. e s tr u c tu r a d e l p r o g r a m a ) ; ( 3 ) e s c o m p le jo o p r o p e n
S iw hsy oficíente, el proyecto se muere. s o a e r r o r e s (s e p u e d e u s a r la c o m p le jid a d c ic lo m á t i
c a c o m o i n d i c a d o r ) ; o (4 ) t i e n e u n o s r e q u i s i t o s d e
r e n d im ie n t o m u y d e f in id o s . L o s m ó d u lo s c r í t ic o s
d e b e n p r o b a r s e l o a n t e s p o s ib le . A d e m á s , la s p r u e b a s
www.FreeLibros.org
■ Se simplifican el diagnóstico y la corrección de erro d e r e g r e s ió n s e d e b e n c e n t r a r e n e l f u n c io n a m ie n t o d e
res. A l i g u a l q u e t o d o s l o s e n f o q u e s d e p r u e b a d e lo s m ó d u lo s c r í t ic o s .
315
INGENIERÍA DEL S O F TW A RE . UN E N F O Q U E PR AC T I C O
lfl.5 PRUEBA DE VALIDACIÓN_____
T ra s la c u lm in a c ió n d e la p r u e b a d e in te g r a c ió n , e l s o f t 1 8 .5 .2 . Revisión de la configuración
w a r e e s tá c o m p le t a m e n te e n s a m b la d o c o m o u n p a q u e U n e l e m e n t o i m p o r t a n t e d e l p r o c e s o d e v a l i d a c i ó n e s la
te , s e h a n e n c o n tr a d o y c o r r e g id o lo s e r r o r e s d e in t e r f a z r e v i s i ó n d e la c o n f i g u r a c i ó n . L a i n t e n c i ó n d e l a r e v i s i ó n
y p u e d e c o m e n z a r u n a s e r ie f i n a l d e p r u e b a s d e l s o f t e s a s e g u r a r s e d e q u e t o d o s lo s e le m e n t o s d e la c o n f i
w a re : la p r u e b a d e v a lid a c ió n . L a v a lid a c ió n p u e d e d e f i g u r a c ió n d e l s o f t w a r e s e h a n d e s a r r o lla d o a p r o p ia d a
n ir s e d e m u c h a s f o r m a s , p e r o u n a s i m p l e ( a u n q u e v u l g a r ) m e n t e , s e h a n c a t a lo g a d o y e s tá n s u fic ie n te m e n te
d e f in ic ió n e s q u e la v a lid a c ió n s e c o n s ig u e c u a n d o e l d e ta lla d o s p a r a s o p o r t a r la fa s e d e m a n t e n im ie n t o d u ra n
s o f t w a r e f u n c i o n a d e a c u e r d o c o n la s e x p e c t a t i v a s r a z o te e l c ic l o d e v id a d e l s o ftw a r e . L a r e v is ió n d e la c o n fi
n a b le s d e l c lie n t e . E n e s te p u n t o , u n d e s a r r o ll a d o r d e g u r a c i ó n , a v e c e s d e n o m i n a d a auditoría, s e h a e s t u d ia d o
s o ftw a r e e s t r ic t o p o d r í a p r o te s ta r : « ¿ Q u é o q u ié n e s e l c o n m á s d e ta lle e n e l C a p í t u lo 9 .
á r b i t r o d e la s e x p e c t a t i v a s r a z o n a b l e s ? »
18.5.3. Pruebas alfa y beta

E s v ir t u a lm e n t e im p o s ib le q u e u n d e s a r r o lla d o r d e s o ft
CLAVE w a r e p u e d a p r e v e r c ó m o u t i l i z a r á e l u s u a r i o r e a lm e n t e
Como en otras etapas de la prueba, la validación permite e l p r o g r a m a . S e p u e d e n m a l i n t e r p r e t a r la s i n s t r u c c i o
descubrir errores, pero su enfoque está en el nivel de n e s d e u s o , s e p u e d e n u t ili z a r h a b it u a lm e n te e x tra ñ a s
requisitos — sobre cosas que son necesarlaspara el c o m b in a c io n e s d e d a to s , y u n a s a lid a q u e p u e d e p a re
usuario final— . c e r c l a r a p a r a e l r e s p o n s a b l e d e la s p r u e b a s y p u e d e s e r
in in t e li g ib le p a r a e l u s u a r io .
L a s e x p e c t a t iv a s r a z o n a b le s e s tá n d e f in id a s e n la C u a n d o s e c o n s t r u y e s o f t w a r e a m e d id a p a r a u n c lie n
E s p e c ific a c ió n d e R e q u is ito s d e l S o f tw a r e — u n d o c u te , s e lle v a n a c a b o u n a s e r ie d e p r u e b a s d e a c e p ta c ió n
m e n to ( C a p í t u lo 1 2 ) q u e d e s c r ib e to d o s lo s a t r ib u t o s d e l p a r a p e r m i t i r q u e e l c lie n t e v a li d e t o d o s lo s r e q u is ito s .
s o ftw a r e v is ib le s p a r a e l u s u a r io . L a e s p e c if ic a c ió n c o n - L a s r e a liz a e l u s u a r io f i n a l e n lu g a r d e l r e s p o n s a b le d e l
tie n e u n a s e c c ió n d e n o m in a d a — . « C r it e r io s d e v a li d a d e s a r r o llo d e l s is t e m a , u n a p r u e b a d e a c e p t a c ió n p u e d e
c ió n » . L a in f o r m a c ió n c o n t e n id a e n e s a s e c c ió n f o r m a i r d e s d e u n in f o r m a l « p a s o d e p r u e b a » h a s ta la e je c u c ió n
la b a s e d e l e n fo q u e a la p r u e b a d e v a lid a c ió n . s is t e m á t ic a d e u n a s e r ie d e p r u e b a s b ie n p la n if ic a d a s . D e
h e c h o , l a p r u e b a d e a c e p t a c i ó n p u e d e t e n e r l u g a r a lo
la r g o d e s e m a n a s o m e s e s , d e s c u b r ie n d o a s í e r r o r e s a c u
18.5.1. Criterios de la prueba de validación
m u l a d o s q u e p u e d e n i r d e g r a d a n d o e l s is t e m a .
L a v a lid a c ió n d e l s o f t w a r e s e c o n s ig u e m e d ia n t e u n a S i e l s o ftw a r e s e d e s a r r o lla c o m o u n p r o d u c t o q u e
s e r ie d e p r u e b a s d e c a j a n e g r a q u e d e m u e s t r a n l a c o n v a a s e r u s a d o p o r m u c h o s c lie n t e s , n o e s p r á c t ic o r e a
f o r m id a d c o n lo s r e q u is ito s . U n p la n d e p r u e b a t r a z a l i z a r p r u e b a s d e a c e p t a c i ó n f o r m a l e s p a r a c a d a u n o de
la c la s e d e p r u e b a s q u e s e h a n d e l l e v a r a c a b o , y u n e llo s . L a m a y o r í a d e lo s d e s a r r o lla d o r e s d e p r o d u c to s
p r o c e d im ie n to d e p r u e b a d e f in e lo s c a s o s d e p r u e b a d e s o ftw a r e lle v a n a c a b o u n p r o c e s o d e n o m in a d o p r u e
e s p e c íf ic o s e n u n in t e n t o p o r d e s c u b r ir e r r o r e s d e b a a lfa y b e ta p a ra d e s c u b r ir e r r o r e s q u e p a re z c a q u e
a c u e r d o c o n lo s r e q u is ito s . T a n to e l p la n c o m o e l p r o s ó lo e l u s u a r io f i n a l p u e d e d e s c u b r ir .
c e d im ie n t o e s ta r á n d is e ñ a d o s p a r a a s e g u r a r q u e se L a p r u e b a alfa s e l l e v a a c a b o , p o r u n c l i e n t e , e n e l
s a tis fa c e n t o d o s lo s r e q u is it o s f u n c i o n a le s , q u e s e lu g a r d e d e s a r r o llo . S e u s a e l s o ftw a r e d e f o r m a n a tu
a lc a n z a n t o d o s lo s r e q u is it o s d e r e n d im ie n t o , q u e la r a l c o n e l d e s a r r o lla d o r c o m o o b s e r v a d o r d e l u s u a r io y
d o c u m e n ta c ió n e s c o r r e c ta e in t e lig ib le y q u e s e a lc a n r e g is tr a n d o lo s e r r o r e s y lo s p r o b le m a s d e u s o . L a s p r u e
z a n o tr o s r e q u is ito s ( p o r e je m p lo , p o r t a b ilid a d , c o m b a s a lf a s e lle v a n a c a b o e n u n e n to r n o c o n tr o la d o .
p a t ib ilid a d , r e c u p e r a c ió n d e e r r o r e s , f a c il id a d d e L a p ru eb a beta s e l l e v a a c a b o p o r l o s u s u a r i o s f i n a
m a n te n im ie n to ) . le s d e l s o f t w a r e e n l o s l u g a r e s d e t r a b a j o d e l o s c l i e n
U n a v e z q u e se p ro c e d e c o n c a d a c a s o d e p ru e b a d e te s . A d i f e r e n c i a de l a p r u e b a a l f a , e l d e s a r r o l l a d o r no
v a l i d a c i ó n , p u e d e d a r s e u n a d e la s d o s c o n d ic i o n e s e s t á p r e s e n t e n o r m a l m e n t e . A s í , l a p r u e b a b e t a e s una
s i g u i e n t e s : ( 1 ) la s c a r a c t e r í s t i c a s d e f u n c i o n a m i e n t o o a p l i c a c i ó n « e n v i v o » d e l s o f t w a r e e n u n e n t o r n o q u e no
d e r e n d i m i e n t o e s t á n d e a c u e r d o c o n la s e s p e c i f i c a c i o p u e d e s e r c o n t r o la d o p o r e l d e s a r r o lla d o r . E l c lie n te
n e s y s o n a c e p t a b le s ; o ( 2 ) s e d e s c u b r e u n a d e s v ia c ió n r e g is t r a t o d o s lo s p r o b le m a s ( r e a le s o im a g in a r io s ) q u e
d e la s e s p e c i f i c a c i o n e s y s e c r e a u n a l i s t a d e d e f i c i e n e n c u e n t r a d u r a n te la p r u e b a b e ta e in f o r m a a in te r v a lo s
c ia s . L a s d e s v ia c io n e s o e r r o r e s d e s c u b ie r t o s e n e s ta r e g u la r e s a l d e s a r r o lla d o r . C o m o r e s u lt a d o d e lo s p r o
fa s e d e l p r o y e c to r a r a m e n te se p u e d e n c o r r e g ir a n te s b le m a s in f o r m a d o s d u r a n te la p r u e b a b e ta , e l d e s a rro -
www.FreeLibros.org
d e la t e r m in a c ió n p la n ific a d a . A m e n u d o e s n e c e s a rio lla d o r d e l s o ftw a r e lle v a a c a b o m o d ific a c io n e s y a s í
n e g o c i a r c o n e l c l i e n t e u n m é t o d o p a r a r e s o l v e r la s d e f i p r e p a r a u n a v e r s ió n d e l p r o d u c t o d e s o ftw a r e p a r a to d a
c ie n c ia s . la c la s e d e c lie n t e s .
316
C A PIT U L O 18 ES TR AT EG IA S DE PRUEB A DEL S O F T W A R E
Al com ienzo de este libro, p usim os énfasis en el hecho

de que el softw are es sólo un elem ento de un sistem a
mayor b asado en com putadora. Finalm ente, el softw a
figÉBEfiBESBUÉfefe/
re es incorporado a o tro s elem en to s del sistem a (por
Amplia Información sóbrela prueba del software y su
ejemplo, nuevo h ardw are, inform ación) y realizan una
relación con las necesldadesde calidad pueden obtenerse
serie de p ruebas de integración del sistem a y de v ali
en www.stqe.net
dación. E stas p ruebas caen fuera del ám bito del p ro ce
so de ingeniería del softw are y no las realiza únicam ente En otros casos, se debe corregir un fallo del sistem a
el d esarrollador del softw are. Sin em b arg o, los pasos en un d eterm in ad o periodo de tiem po para que no se
dados durante el diseño del softw are y durante la pru e produzca un serio daño económ ico.
ba pueden m ejorar enorm em ente la probabilidad de éx i La p r u e b a de recuperación es una prueba del siste
to en la integración del softw are en el sistem a. m a que fuerza el fallo del softw are de m uchas form as
y verifica que la recuperación se lleva a cabo apropia
CjCita: dam ente. Si la re cu p e ració n es au to m ática (llev ad a a
Semejante a la muerte y a los impuestos, la prueba
cabo p o r el propio sistem a) hay'que evaluar la co rrec
es desagradable e inevitable. ción de la inicialización, de los m ecanism os de recu p e
Ed Ysurdon ración del estado del sistem a, de la recuperación de datos
y del proceso de rearranque. Si la recuperación req u ie
re la intervención hum ana, hay que evaluar los tiem pos
Un problem a típ ico de la pru eb a del sistem a es la m edios de reparación (TM R ) para determ inar si están
((delegaciónde cu lp ab ilid ad » . E sto o cu rre cu an d o se dentro de unos lím ites aceptables.
descubre un e rro r y cad a uno de los cread o res de cada
elemento del sistem a e c h a la cu lp a del p ro b lem a a los
otros. En vez de verse en v u elto en esta ab surda situa 18.6.2. Prueba de seguridad
ción, el ingeniero del so ftw are debe an ticip arse a los C ualquier sistem a basado en com putadora que m aneje
posibles p roblem as de interacción y: (1) d iseñar cam i inform ación sensible o lleve a cabo acciones que pue
nos de m anejo de erro res que p ru e b e n to d a la in fo r dan p erjudicar (o beneficiar) im propiam ente a las p e r
mación p rocedente de otros elem entos del sistem a; (2) sonas es un posible objetivo para entradas im propias o
llevar a cabo una serie de p ruebas que sim ulen la p re ilegales al sistem a. E ste acceso al sistem a incluye un
sencia de datos en m al estad o o de otros p osibles e rro am plio ran g o de actividades: «piratas in form áticos»
res en la in te rfa z d el so ftw a re ; (3 ) re g is tra r los que intentan entrar en los sistem as p o r deporte, em plea
resultados de las p ruebas co m o « ev id en cia» en el caso dos disgustados que intentan p enetrar p o r venganza e
de que se le señale con el dedo; (4) p articip ar en la pla individuos deshonestos que intentan p en etrar para o b te
nificación y el diseño de p ruebas del sistem a para ase ner ganancias personales ilícitas.
gurarse de q u e el so ftw a re se p ru e b a de fo rm a L a p r u e b a de se g u rid a d in ten ta v e rific a r que los
adecuada. m ecanism os de protección incorporados en el sistem a
La prueba del sistem a, realm en te, está c o n stitu id a lo protegerán, de hecho, de accesos im propios. Para citar
por una serie de p ruebas diferentes cuyo p ropósito p ri a B eizer [B EI84]: « P o r supuesto, la seguridad del sis
mordial es ejercitar p rofundam ente el sistem a basado tem a debe ser probada en su invulnerabilidad frente a
en com putadora. A unque cada prueba tiene un p ro p ó un ataq u e fro n ta l, p e ro tam b ién d eb e p ro b a rse en su
sito diferente, todas trab ajan p ara v erificar que se han invulnerabilidad a ataques p o r los flancos o p o r la re ta
integrado adecuadam ente tod o s los elem entos del sis guardia.»
tema y que realizan las fu n cio n es ap ropiadas. En las D urante la prueba de seguridad, el responsable de la
siguientes secciones exam inam os los tipos de pruebas prueba desem peña el papel de un individuo que desea
del sistema [BEI84] v aliosos p ara sistem as basados en entrar en el sistem a. ¡Todo vale! D ebe intentar con se
software. g u ir las clav es de acceso p o r c u a lq u ier m ed io , puede
atacar al sistem a con softw are a m edida, diseñado para
rom per cualquier defensa que se haya construido, debe
18.6.1. Prueba de recuperación b loquear el sistem a, negando así el servicio a otras p er
Muchos sistem as basados en com putadora deben re cu sonas, debe p ro d u cir a p ro p ó sito erro res del sistem a,
perarse de los fallos y continuar el p roceso en un tie m intentando acceder durante la recuperación o debe curio
po p reviam ente esp ecificad o . E n alg u n o s ca so s, un sear en los datos sin protección, intentando encontrar la
www.FreeLibros.org
sistema debe ser to lerante con los fallo s; es decir, los clave de acceso al sistem a, etc.
fallos del p roceso no d eben h acer que cese el fu n c io C on tiem po y recursos suficientes, una buena p ru e
namiento de todo el sistem a. ba de seg u rid ad te rm in ará p o r acceder al sistem a. El
317
INGENIERÍA DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
pap el del d iseñador del sistem a es h acer que el coste de situ acio n es (la m ás c o m ú n se d a con alg o ritm o s mate
la entrad a ilegal sea m ay o r que el v alo r de la in form a m á tic o s), un ra n g o de d ato s m uy p eq u eñ o dentro de
ción obtenida. los lím ites de una entrada válid a para un p rogram a pue
de p ro d u cir un p ro ceso ex ag erad o e in clu so erróneo o
u n a profunda degradación del rendim iento. E sta situa
c ió n es a n á lo g a a u n a sin g u la rid a d e n u n a función
m atem ática. L a p ru e b a de sen sib ilid ad in ten ta descu
b rir c o m b in a c io n e s de d a to s d e n tro de u n a clase d e
e n trad a v álid a que p u ed a p ro d u cir in e stab ilid a d o un
p ro ceso incorrecto.
18.6.4. P r u e b a d e r e n d im ie n to
18.6.3. P r u e b a d e r e s is t e n c i a (S tre s s ) P ara sistem as de tiem p o real y sistem as em potrados,
D urante los pasos de p ru eb a an teriores, las técnicas de es in a c e p ta b le e l so ftw a re q u e p ro p o rc io n a las f u n
caja blanca y de caja negra dab an com o resultado la ev a cio n es re q u e rid a s p ero no se aju sta a los requisitos d e
luación del fu ncionam iento y del rendim iento n orm a ren d im ien to . L a p r u e b a de rendim iento e stá diseñada
les del p ro g ram a. L a s p ru eb as de re s is te n c ia está n p ara p ro b a r el ren d im ien to del softw are en tiem po d e
diseñadas p ara enfren tar a los p rogram as con situacio ejecu ció n d en tro del con tex to de un sistem a integra
nes anorm ales. En esencia, el sujeto que realiza la p ru e do. L a p ru e b a de ren d im ien to se da du ran te todos los
ba de resistencia se pregunta: «¿A qué poten cia puedo pasos del proceso de la prueba. Incluso al nivel de uni
ponerlo a fun cio n ar antes de que falle?» d ad , se debe aseg u rar el ren d im ien to de los módulos
L a p r u e b a de resistencia ejecu ta un sistem a de fo r in d iv id u ales a m ed id a que se lle v an a cab o las prue
m a que d em an d e recu rso s en c a n tid a d , fre c u e n c ia o b as de c a ja blanca. S in em b arg o , h a sta que no están
v o lú m en es anorm ales. P or ejem plo: (1) d ise ñ a r p ru e co m p letam en te integrados todos los elem entos del s is
b a s e s p e c ia le s q ue g e n e re n d ie z in te rru p c io n e s por te m a no se pued e aseg u rar realm en te el rendim iento
segundo, cuando las norm ales son u n a o dos; (2) in cre del sistem a.
m en tar las frecuencias de d ato s de entrada en un orden Las pruebas de rendim iento, a m enudo, van empa
de m a g n itu d co n e l fin de c o m p ro b a r c ó m o re s p o n rejadas con las pruebas de resistencia y, frecuentem en
d en las fu n c io n e s de e n tra d a ; ( 3 ) e je c u ta r c a so s de te, requieren instrum entación tan to de softw are como
p ru e b a q u e re q u ie ra n el m á x im o de m e m o ria o de de hardw are. Es decir, m uchas veces es necesario medir
otro s recu rso s; (4 )d ise ñ a r caso s de p ru e b a que p u e la utilización de recursos (por ejem p lo , ciclos de pro
dan d a r p ro b lem as en u n sistem a o p erativ o v irtu a l o cesador), de un m odo exacto. L a instrum entaciónexter-
(5 ) d ise ñ a r caso s de p ru e b a que p ro d u z c a n ex cesivas n a puede m o n ito rizar los in terv alo s de ejecución, los
b ú sq u e d a s de d a to s r e s id e n te s en d isc o . E s e n c ia l sucesos ocurridos (por ejem plo, interrupciones)y mues
m en te, el re sp o n sa b le de la p ru e b a in te n ta ro m p er el tras de los estados de la m áquina en un funcionam ien
prog ram a. to norm al. Instrum entando un sistem a, el encargadode
U n a variante de la p ru eb a de resisten cia es u n a té c la prueba puede descubrir situaciones que lleven a degra
n ica d e n o m in a d a p ru eb a de sensibilidad. E n algunas daciones y posibles fallo s del sistem a.
1-8.7 EL ARTE DE LA DEPURACIÓEL
L a p ru eb a del softw are es un p roceso que puede p la n i w are. Es decir, la m anifestación externa de un error, y
ficarse y especificarse sistem áticam ente. Se puede lle la causa interna del e rro r pueden no e star relacionados
var a cabo el diseño de casos de prueba, se puede definir de u n a fo rm a obvia. El p ro ceso m en tal, apenas com
una estrategia y se pueden evaluar los resultados en com prendido, que conecta un síntom a con u n a causa es la
paració n con las expectativas prescritas. depuración.
L a d e p u ra c ió n o c u rre co m o c o n s e c u e n c ia de una
p ru eb a efectiva. Es decir, cuando un caso de p ru eba d e s
cubre un error, la depuración es el p roceso que p ro v o
ca la elim inación del error. A unque la depuración puede Referencia
y debe ser un p roceso ordenado, sigue teniendo m ucho BugNet facilita información sobre problemas de seguridad
www.FreeLibros.org
de arte. U n ingeniero del softw are, al evalu ar los re su l y fallos en softwore basado en PC y proporciona una
tados de u n a prueba, se en cuentra frecuentem ente con información útil sobre temas de depuración:
una indicación«sintom ática» de un p roblem a en el soft- www.bugnet.com
318
CAPÍTULO 18 ESTRA TEGIA S DE PRUEBA DEL SOFTW ARE
18.7.1. El P ro c e s o d e d e p u r a c i ó n 7. El síntom a puede aparecer de form a interm itente.

La depuración no es una prueba, pero siempre ocurre Esto es particularm ente com ente en sistemas em po
como consecuencia de la prueba4. Como se m uestra en trados que acoplan el hardw are y el softw are de
la Figura 18.8, el proceso de depuración com ienza con m anera confusa.
la ejecución de un caso de prueba. Se evalúan los resul 8. El síntoma puede ser debido a causas que se distri
tados y aparece una falta de correspondencia entre los buyen por una serie de tareas ejecutándose en dife
esperados y los encontrados realmente. En muchos casos, rentes procesadores [CHE90],
los datos que no concuerdan son un síntoma de una cau Durante la depuración encontramos errores que van
sa subyacente que todavía permanece oculta. El proce desde lo ligeramente inesperado (por ejem plo, un for
so de depuración intenta hacer corresponder el sistema m ato de salida incorrecto) h asta lo catastrófico (por
con una causa, llevando así a la corrección del error. ejem plo, el sistem a falla, produciéndose serios daños
El proceso de depuración siempre tiene uno de los económicos o físicos). A m edida que las consecuencias
dos resultados siguientes: (1) se encuentra la causa, se de un error aumentan, crece la presión por encontrar su
corrige y se elimina; o (2) no se encuentra la causa. En causa. A m enudo la presión fuerza a un ingeniero del
este último caso, la persona que realiza la depuración software a corregir un error introduciendo dos más.
debe sospechar la causa, diseñar un caso de prueba que
ayude a confirmar sus sospechas y el trabajo vuelve hacia
atrás a la corrección del error de una form a iterativa.
¿Por qué es tan difícil la depuración? Todo parece
indicar que la respuesta tiene m ás que ver con la psico
logía hum ana (véase la siguiente sección) que con la
tecnología del software. Sin em bargo, varias caracte
rísticas de los errores nos dan algunas pistas:
Resultados
1. El síntoma y la causa pueden ser geográficam ente
remotos entre sí. Es decir, el síntoma puede apare
cer en una parte del program a, m ientras que la causa Correcciones
está localizada en otra parte muy alejada. Las estruc Id e n tific a d a s
turas de program a fuertemente acopladas (Capítulo
13) resaltan esta situación. F IG U R A 18.8. El proceso de depuración.
2. El síntoma puede desaparecer (tem poralm ente) al

corregir otro error. 18.7.2. C o n s id e r a c io n e s p s ic o ló g ic a s
Desafortunadam ente, todo parece indicar que la habili
3. El síntoma puede realm ente estar producido por algo
dad en la depuración es un rasgo innato del ser hum a
que no es un error (por ejemplo, inexactitud en los
no. A ciertas personas se les da bien y a otras no. Aunque
redondeos).
las m anifestaciones experim entales de la depuración
4. El síntoma puede estar causado por un error humano
están abiertas a muchas interpretaciones, se han detec
que no sea fácilmente detectado. tado grandes variaciones en la destreza para la depura
5. El síntoma puede ser el resultado de problem as de ción de distintos program adores con el m ism o bagaje
temporización en vez de problem as de proceso. de formación y de experiencia.
6. Puede ser difícil reproducir exactamente las condi Hablando de los aspectos hum anos de la depuración,
ciones de entrada (por ejem plo, una aplicación de Shneiderman [SHN80] manifiesta:
tiempo real en la que el orden de la entrada no está
L a depuración es una de las partes m ás frustrantes de la pro
determinado). gram ación. C ontiene elem entos de resolución de problem as o
de rom pecabezas, ju n to con el desagradable reconocim iento de
que se ha com etido un error. L a enorm e ansiedad y la no incli
nación a aceptar la posibilidad de com eter errores hace que la
L jfita tarea sea extrem adam ente difícil. A fortunadam ente, tam bién se
lo variedad que dentro de los programas de computador da un gran alivio y dism inuye la tensión cuando el error es final
debe diagnosticarse [paro depuración] es probablemente mente.. .corregido.
mayor que lo variedad en otros ejemplos de sistemas Aunque puede resultar difícil «aprender» a depurar,
que son regularmente diagnosticados. se pueden proponer varios enfoques del problema. En
Joixi Govld la siguiente sección los examinamos.
www.FreeLibros.org
4 Al decir esta frase, tom am os el punto de vista m ás am plio que se
puede tener de la prueba. N o sólo ha de llevar a cabo la prueba el
equipo de desarrollo a n te s de en treg ar el softw are, sino que el
cliente/usuario prueba el softw are cada vez que lo usa.
319
INGE NIE RÍA DEL SOF TW AR E . UN ENFOQUE P R Á C T I C O
18.7.3. E n fo q u e s d e l a d e p u r a c ió n d a to s r e la c io n a d o s c o n la o c u r r e n c ia d e l e r r o r s e o rg a
Independ ien tem en ted el enfoque que se utilice, la dep u n iz a n p a r a a is la r la s p o s ib le s c a u s a s . S e lle g a a u n a
ració n tiene un objetivo p rim o rd ial: encontrar y co rre « h ip ó t e s is d e c a u s a » y s e u s a n lo s d a to s a n te r io r e s p a ra
gir la cau sa de un e rro r en el softw are. El objetivo se p r o b a r o r e v o c a r la h ip ó t e s is . A lt e r n a t iv a m e n t e , s e d e s a
consigue m ediante una co m binación de una evaluación r r o l l a u n a l i s t a d e t o d a s la s p o s i b l e s c a u s a s y s e ll e v a n
sistem ática, de intuición y de suerte. B radley [B RA 85] a c a b o p ru e b a s p a r a e lim in a r c a d a u n a . S i a lg u n a p ru e
describ e el e n fo q u e de la d ep u ració n de la sig uiente b a in ic ia l in d ic a q u e d e te r m in a d a h ip ó t e s is d e c a u s a e n
form a: p a r t ic u la r p a r e c e p r o m e te d o r a , s e r e f in a n lo s d a to s c o n
e l fin d e i n t e n t a r a i s l a r e l e r r o r .
L a depuración es una aplicación directa del m étodo cientí
C a d a u n o d e lo s e n fo q u e s a n te r io r e s p u e d e c o m p le
fico desarrollado hace 2.500 años. L a base de la depuración es
la localización de la fuente del problem a [la causa] m ediante m e n ta r s e c o n h e r r a m ie n ta s d e d e p u r a c ió n . P o d e m o s u s a r
partición binaria, m anejando hipótesis que predigan nuevos u n a g r a n c a n tid a d d e c o m p ila d o r e s d e d e p u r a c ió n , a y u
valores a exam inar. d a s d in á m ic a s p a r a la d e p u r a c ió n ( « t r a z a d o r e s » ) , g e n e
Tom em os un sencillo ejem plo que no tiene que ver con el r a d o r e s a u t o m á t i c o s d e c a s o s d e p r u e b a , v o l c a d o s de
software: en mi casa no funciona una lám para. Si no funciona m e m o r ia y m a p a s d e r e f e r e n c ia s c ru z a d a s . S in e m b a r
nada en la casa, la causa debe estar en el circuito principal de g o , la s h e r r a m i e n t a s n o s o n u n s u s t i t u t o d e l a e v a l u a
fusibles o fuera de la casa; m iro fuera para ver si hay un apa c ió n c u id a d o s a b a s a d a e n u n c o m p le t o d o c u m e n t o d e l
gón en todo el vecindario. C onecto la sospechosalám para a un
d is e ñ o d e l s o f t w a r e y u n c ó d ig o fu e n t e c la r o .
enchufe que funcione y un aparato que funcione en el circuito
sospechoso. A sí se sigue la secuencia de hipótesis y de pruebas.
En general, existen tres enfoques que se pueden pro

p o n er p ara la depuración [M Y E79]:
1. F uerza bru ta
2 . V uelta atrás
Herramientas CASE
3. E lim inación de causas Pruebo y Depuración.
L a categ o ría de d ep u ració n p o r la fu e rza b ruta es
probablem ente la m ás com ún y m enos eficiente a la hora C u a lq u ie r d is c u s ió n s o b r e lo s e n f o q u e s p a r a la d e p u
de aislar la cau sa del e rro r en el softw are. A plicam os r a c ió n y s u s h e r r a m ie n t a s n o e s ta r í a c o m p le t a s in m e n
los m étodos de depuración p o r fuerza b ru ta cuando todo c io n a r u n p o d e r o s o a lia d o : ¡ o tra s p e r s o n a s ! C u a lq u ie r a
lo dem ás falla. M ediante una filosofía de « d e ja r que la d e n o s o tr o s p o d r á r e c o r d a r h a b e r e s ta d o d a n d o v u e lta s
com pu tad o ra encuentre el e rro r» , se hacen v o lcados de e n la c a b e z a d u r a n t e h o r a s o d í a s a u n e r r o r p e r s i s t e n
m em oria, trazas de ejecución y se cargan m ultitud de te . D e s e s p e r a d o s , le e x p lic a m o s e l p r o b le m a a u n c o le
sentencias M o stra r en el program a. E speram os que en g a c o n e l q u e d a m o s p o r c a s u a lid a d y le m o s t r a m o s e l
algún lugar de la gran cantidad de inform ación genera lis ta d o . In s ta n tá n e a m e n te ( p a r e c e ) , s e d e s c u b re la c a u
da encontrem os alguna p ista que nos lleve a la causa de s a d e l e r r o r . N u e s t r o c o le g a s e a le ja s o n r ie n d o la d in a
un error. A unque la gran cantidad de inform ación p ro m e n te . U n p u n to d e v is t a fr e s c o , n o e m b o ta d o p o r h o ra s
ducid a n os puede llev ar finalm ente al éxito , lo m ás fre d e fr u s t r a c ió n , p u e d e h a c e r m a r a v illa s . U n a m á x im a
cuente es que se desperdicie tiem po y esfuerzo. ¡Primero f i n a l p a r a la d e p u r a c ió n p u e d e s e r : « ¡ C u a n d o t o d o lo
se debe u sar la in teligencia! d e m á s f a lle , p id e a y u d a !»
U n a v e z q u e se h a e n c o n tra d o u n e rro r, h a y q u e c o rre
g ir lo . P e r o c o m o y a h e m o s p o d id o o b s e r v a r , la c o r r e c
fíjate un tiempo limitado, por ejemplo dos horas, c ió n d e u n e r r o r p u e d e in t r o d u c ir o tr o s e r r o r e s y h a c e r
en relación a la cantidad de tiempo que tu inviertes m á s m a l q u e b ie n .
para depurar un problema de tu incumbencia.
Después qué, ¡pide ayuda/ ^ Cuando corrijo un error,
* ¿qué cuestiones debo
L a vuelta atrá s es un en fo q u e m ás norm al para la preguntarme a mi mismo?
depuración, que se puede usar con éxito para pequeños
programas. Partiendo del lugar donde se descubre el sín V a n V l e c k [ V A N 8 9 ] s u g i e r e t r e s p r e g u n t a s s e n c ill a s
tom a, se recorre h acia atrás (m anualm ente) el código q u e d e b e r í a p r e g u n t a r s e t o d o i n g e n i e r o d e l s o f t w a r e a n te s
fu en te h asta que se llega a la posició n de error. D es d e h a c e r la « c o r r e c c ió n » q u e e lim in e la c a u s a d e l e r r o r :
g raciad am en te, a m ed id a que au m en ta el n ú m ero de 1 ¿ S e r e p it e la c a u s a d e l e r r o r e n o t r a p a r t e d e l p r o
lín eas del có d ig o , el n ú m ero de p o sib le s cam in o s de g r a m a ? E n m u c h a s s itu a c io n e s , e l d e f e c t o d e u n p r o
www.FreeLibros.org
vuelta se hace d ifícilm ente m anejable. g r a m a e s tá p r o d u c id o p o r u n p a tr ó n d e ló g ic a e rró n e o
El tercer enfoque p ara la depuración — elim inación q u e s e p u e d e r e p e t ir e n c u a lq u ie r lu g a r . L a c o n s id e
d e c a u s a s - se m anifiesta m ediante inducción o d educ r a c ió n e x p lí c it a d e l p a tr ó n ló g ic o p u e d e te r m in a r e n
ción e introduce el concepto de p artició n binaria. L o s e l d e s c u b rim ie n to d e o tr o s e rro re s .
320
CAPÍTULO 18 ESTRATEGIAS DE PRUEB A DEL S O F T W A R E
2. ¿Cuál es el «siguiente error» que se podrá presentar a 3. ¿ Q u é p o d ría m o s haber hecho p a r a p re v e n ir este
raíz de la corrección que hoy voy a realizar? A ntes de error laprimera vez? E sta pregunta es el prim er paso
hacer la corrección, se debe evaluar el código fuente (o para establecer un m étodo estadístico de garantía de
mejor, el diseño) para determ inarel em parejam ientode calidad del softw are (Capítulo 8 ). Si corregim os tanto
la lógica y las estructuras de datos. Si la corrección se el p ro ceso com o el producto, se elim in a rá el e rro r
realiza en una sección del program a altamente acoplada, del program a actual y se puede elim inar de todos los
se debe tener cuidado al realizar cualquier cambio. futuros program as.
La prueba del softw are contab iliza el m ay o r po rcen ta A d iferencia de la p ru eb a (una actividad sistem ática
je del esfuerzo técnico del p roceso de d esarrollo de soft y planificada), la depuración se puede considerar un arte.
ware. Todavía estam os com enzando a com prender las A p artir de una indicación sintom ática de un problem a,
sutilezas de la planificació n sistem ática de la prueba, de la actividad de la depuración debe rastrear la causa del
su ejecución y de su control. error. D e entre los recursos disponibles durante la dep u
El o b jetiv o de la p ru e b a de so ftw are es d e sc u b rir ración, el m ás valioso puede ser el apoyo de otros in g e
errores. P ara conseguir este objetivo, se p lanifica y se nieros de softw are.
ejecutan u n a serie de pasos; p ruebas de unidad, de in te El requisito de que el softw are sea cada vez de m ayor
gración, de validación y del sistem a. Las pruebas de uni calidad exige un planteam iento m ás sistem ático de la
dad y de in te g ra c ió n se c e n tra n en la v e rific a c ió n prueba. C itando a D unn y U llm an [D U N 82]:
funcional de ca d a m ódulo y en la in corporación de los
L o que se requiere es una estrategia global, que se extienda
módulos en u n a estru ctu ra de program a. L a p rueba de
por el espacio estratégicode la prueba, tan deliberada en su m eto
validación dem uestra el seguim iento de los requisitos dología com o lo fue el desarrollo sistem ático en el que se basa
del softw are y la p ru eb a del sistem a v alid a el softw are ron el análisis, el diseño y la codificación,
una vez que se h a incorporado en un sistem a superior.
C ada paso de p ru eb a se lleva a cab o m ediante una En este capítulo hem os exam inado el espacio estra
serie de técnicas sistem áticas de p ru eb a que ayudan en tégico de la prueba, considerando los pasos que tienen
el diseño de casos de prueba. C on cada paso de prueba la m ay o r probabilidad de conseguir el fin Último de la
se am plía el nivel de ab stracción con el que se co n si prueba: encontrar y subsanar los defectos de una m an e
dera el softw are. ra ordenada y efectiva.
[BEI84] B e iz er, B ., Sojhs’are System Testing and Quality Assu [M IL L 7 7 ] M ille r, E ., « T h e P h ilo s o p h y o f T e s tin g » , Program
rance, V an N o s tr a n d R e in h o ld , 1984. Testing Techniques, IE E E C o m p u te r S o c ie ty P re s s , 1 9 7 7 ,
pp. 1-3. '
[BOE81] B o e h m , B ., Software Engineering Economics, P re n -
tic e -H a ll, 1981, p. 37. [M U S 8 9 ] M u s a , J. D ., y A c k e rm a n , A . F., « Q u a n tify in g S o ft
w a re V a lid a tio n : W h e n to S to p T e s tin g ? » , IEEE Softwa
[BRA85] B ra d le y , J.H ., « T h e sc ie n c e a n d A r t o f D e b u g g in g » , re, M a y o 1 9 8 9 ,p p . 19-27.
C o m p u te rw o rld , 1 9 d e A g o s to d e 1 9 8 5 ,p p . 3 5 -3 8 .
[M Y E 7 9 ] M y e rs , G ., The A rt cf Software Tests, W ile y , 1979.
[CHE90] C h e u n g , W. H ., J. P. B la c k y E. M a n n in g , « A F ra - [S H 0 8 3 ] S h o o m a n , M. L ., Software Engineering, M c g ra w -
m ew o rk fo r D istrib u te d D e b u g g in g » , IEEE Software, E n e H ill, 1983.
ro 1 9 9 0 ,pp. 1 0 6-115.
[S H N 8 0 ] S h n e id e rm a n , B ., SoftW’are Psychology, W in th ro p
[DUN82] D u n n , R ., y R. U llm a n , Quality Assurancefor Com P u b lis h e rs , 1 9 8 0 , p. 28.
puter Software, M c G ra w -H ill, 1 9 8 2 ,p. 158.
[V A N 8 9 ] V an B le c k , T „ « T h re e Q u e s tio n s A b o u t E a c h B u g
[GIL95] G ilb , T., « W h a t W e F a il T o D o In O u r C u rre n t T e s Y ou fin d » ,,4 C A / S o fia r e Engineering Notes, vo l. 1 4 ,n .3
ting C u ltu re » , Testing Techniques Newsletter, (e d ic ió n en- 5 , J u lio 1 9 8 9 ,pp. 6 2 -6 3 .
lín e a , t tn @ s o f t.c o m ), S o f tw a r e R e s e a r c h , I n c , S a n [W A L 8 9 ] W a lla n c e , D . R ., y R. U . F u jii, « S o ftw a re V erifica-
F ra n c is c o , E n e ro 199.5. tio n a n d V a lid a tio n : A n O verV iew » , IEEE Software, M a y o
www.FreeLibros.org
1 9 8 9 ,pp. 10-17. '
[M C 0 9 6 ] M c C o n n e ll, S., « B e s t P ra c tic e s : D a ily B u ild a n d
Sm oke T e s t» , IE E E S o ftw a re , vo l. 13, n .9 4 , Ju lio 1996, [Y O U 7 5 ] Y o u rd o n , E ., Techniques cf Progrum Structure and
p p . 143-144. Design, P r e n tic e - H a ll, 1975.
321
IN G EN IERÍA DEL SO FTW A R E . UN E N F O Q U E P R Á C T IC O
’ PU N TO S fl COMS1DE1
18.1. C on sus propias palabras, describa las diferencias entre tifique el orden de integración. Suponga que todos los módu
verificació n y validación. ¿ U tiliza n las dos los m étodos de los han sido probados en unidad y están disponibles. [Nota:
diseño de casos de prueba y las estrategias de prueba? puede ser necesario com enzar trabajando un poco con el dise
ño inicialm ente.]
18.2. H ag a una lista de algunos problem as que puedan estar
asociados con la creación de un grupo independiente de prue 18.7. ¿Cómo puede afectar la plan ificación del proyecto a la
ba. ¿Están form ados por las m ism as personas el G IP y el gru prueba de integración?
po SQ A ? 18.8. ¿Es posible o incluso deseable la prueba de unidad en
18.3. ¿Es siem pre posible desarrollar una estrategia de prue cualquier circunstancia? Ponga ejem plos que ju stifiquen su
ba de softw are que use la secuencia de pasos de prueba des respuesta.
crita en la Sección 18.1.3? ¿Qué posibles com plicaciones
18.9. ¿Quién debe llevar a cabo la prueba de v a lid a c ió n — el
pueden surgir para sistemas empotrados?
desarrollador del software o el usuario— ? Justifique su respuesta.
18.4. Si sólo pudiera seleccionar tres métodos de diseño de
1 8 .1 0 . D esarrolle una estrategia de prueba com pleta para el
casos de prueba para aplicarlos durante la prueba de unidad,
sistem a HogarSeguro descrito anteriorm ente en este libro.
¿cuáles serian y por qué? D ocum éntela en una Especificación de Prueba.
18.5. Porqué es d ifíc il de realizar la prueba unitaria a un m ódu
1 8.11. Corno proyecto de clase, desarrolle una guía de depu
lo con alto n ive l de integración. ración para su instalación. L a guía debe proporcionar conse
18.6. D esarrolle una estrategia de prueba de integración para jo s orientados al len g u ajey al sistema que se hayan aprendido
cualquiera de los sistemas im plem entados en los problem as con las m alas experiencias. C om ience con un esbozo de los
16.4 a 16.11. D efin a las fases de prueba, indique el orden de temas que se tengan que revisar por la clase y su profesor.
integración, especifique el softw are de prueba adicionaly ju s Publique la guía para otras personas de su entorno.
LAS Y FUENTES DE INFQRMAC
Libros orientados a las estrategias de prueba del softw are son al. (Testing Computer Software, 2 ed., Van N ostrand Rein-
los de B lack ( Managing the TestingProcess, M icro so ft Press, hold, 1993) define los pasos para una estrategia efectiva, pro
1999), D ustin, Rashka and Paul (TestProcess Improvement: p orciona un con ju n to de técnicas y directrices y sugiere
S tep-B y-Step G uide to Structured Testing, A ddison -W esley, procedim ientos para controlar y hacer un seguim iento a los
1999), Perry (Suwiving the Pop Ten Challenges o f Software procesos de prueba. H utcheson (Software Testing Methods
Testing:A People-OrientedApproach, D orset H ouse, 1997), and Metrics, M c G ra w -H ill, 1996) presenta unos métodos y
and K it anáY'mz\(Software Testingin the Real World:Impro- estrategias de prueba pero tam bién proporciona un estudio
ving the Process, A ddison -W esley, 1995). detallado de cóm o se puede usar la m ed ición para conseguir
Kaner, N g u y e n y Falk (TestingComputerSoftwa-re, W iley, una prueba efectiva.
1 99 9), Hutcheson (Software Testing M ethods and Metrics:
U n libro de D unn (Sojhi’are Defect Removal, M cG raw -H ill,
TheM ostImportant Tests, M c G ra w H ill, 1997), M a ric k (The
1 9 8 4 ) contiene unas directrices para la depuración. B eizer
Craft o f Software Testing: Subsystem Testinglncluding Object-
[B E I8 4 ] presenta una interesante «taxonom ía de errores» que
Based and Object-Oriented Testing, Prentice H a ll, 1995), Jor-
puede conducir a unos m étodos efectivos para la planificación
gensen (Software Testing: A Crafts-m an's Approach, C R C
de pruebas. M cConnell (Cocle Complete, M icrosoft Press, 1993)
Press, 1995) presentan estudios sobre los métodos y estrate
gias de prueba. presenta unos pragm áticos consejos sobre las pruebas de uni
A dem ás, antiguos libros de Evans (Productive Software dad y de integración así com o sobre la depuración.
Test Management, W ile y -In te rs c ie n c e , 1 9 8 4 ), H e tze l (The U na am plia variedad de fuentesde inform ación sobre prue
Complete Guide to Software Testing, Q E D Inform ation S cien - bas del softw are y elem entos relacionados están disponibles
ces, 1984), B e iz e r [B E I8 4 ], O u ld y U n w in (Testing in Soft en Internet. U n a lista actualizada de páginas w eb sobre con
ware Development, C am bridgeU niversity Press, 1986), M arks ceptos de prueba, m étodos y estrategias pueden encontrarse
(Testing VeiyBig Systems , M c G ra w -H ill, 1992), y K a n e r et en h ttp ://w w w .p re s s m a n 5 .c o m .
1 Q M É T R IC A S T É C N IC A S
1 O DEL S O FTW A R E
U
N e le m e n to c la v e d e c u a lq u ie r p r o c e s o d e in g e n ie r í a e s la m e d ic ió n . E m p le a m o s m e d i
d a s p a r a e n te n d e r m e jo r lo s a t r ib u to s d e lo s m o d e lo s q u e c re a m o s . P e r o , f u n d a m e n t a l
m e n t e , e m p l e a m o s la s m e d i d a s p a r a v a l o r a r l a c a l i d a d d e l o s p r o d u c t o s d e i n g e n i e r í a o
d e lo s s is t e m a s q u e c o n s t r u im o s .
A d i f e r e n c i a d e o t r a s d is c ip lin a s , la in g e n ie r í a d e l s o ftw a r e n o e s tá b a s a d a e n le y e s c u a n t i
t a t iv a s b á s ic a s d e la F í s ic a . L a s m e d id a s a b s o lu t a s , t a le s c o m o e l v o lt a je , la m a s a , la v e l o c i
d a d o l a t e m p e r a t u r a n o s o n c o m u n e s e n e l m u n d o d e l s o f t w a r e . E n su l u g a r , i n t e n t a m o s o b t e n e r
u n c o n ju n t o d e m e d id a s in d ir e c ta s q u e d a n lu g a r a m é tr ic a s q u e p r o p o r c io n a n u n a in d ic a c ió n
d e la c a li d a d d e a lg ú n t i p o d e r e p r e s e n t a c ió n d e l s o f t w a r e . C o m o la s m e d id a s y m é t r ic a s d e l
s o f t w a r e n o s o n a b s o lu t a s , e s t á n a b ie r t a s a d e b a te . F e n t o n [ F E N 9 1 ] t r a t a e s te a s p e c t o c u a n d o
d ic e :
L a m edición es el p roceso por el que se a sig n an n úm eros o sím bolos a los a tributos d e las entidades en
el m undo real, d e tal m anera que las definan de acuerdo c o n unas reg las claram en te definidas .... E n las c ie n
cias físicas, m ed icin a y, m ás recien tem en te, en las ciencias sociales, som os a hora capaces d e m edir a trib u
tos que p reviam ente pensábam os que no eran m ed ib les... P or supuesto, tales m ediciones no están tan refinadas
co m o las de las ciencias físicas..., pero existen [y se tom an im portantes decisio n es basadas e n ellas]. S e n
tim o s que la o b lig ació n de intentar «m ed ir lo no m edible» para m ejo rar nu e stra c o m p ren sió n d e entidades
particulares es tan p o d ero sa en la in g en ie ría del softw are com o en cu alq u ier disciplina.
P e r o a lg u n o s m ie m b r o s d e la c o m u n id a d d e s o ftw a r e c o n t in ú a n a r g u m e n ta n d o q u e e l s o ftw a r e
n o e s m e d ib le o q u e s e d e b e r ía n p o s p o n e r lo s in te n to s d e m e d ic ió n h a s ta q u e c o m p r e n d a m o s m e jo r
e l s o f t w a r e y lo s a t r ib u to s q u e h a b r í a q u e e m p le a r p a r a d e s c r ib ir lo . E s t o e s u n e r r o r .
VISTAZO RÁPIDO
¿Qué es? Por su naturaleza,la ingenie necesita criterios objetivos para guiarse datos históricos. El resultado del análi
r a es una disciplina cuantitativa.Los en el diseño de datas, de la arquitectu sis es interpretado para profundizar en
ingenieros usan números para ayu ra, de las interfaces y de los componen la calidad del software, y el resultado de
darse en el diseño y cálculo del pro tes. El verificador necesita una referencia la interpretación orienta las modifica
ducto a construir. Hasta hace poco cuantitativa que le ayude en la selección ciones a originarse en los resultados
tiempo. los ingenieros del software dis de ios casos de prueba y de sus objeti obtenidos en el análisis, diseño, codifi
ponían de pocas referencias cuantita vos. Las métricas técnicas facilitan una cación y prueba.
tivas en su trabajo —pero esto está base para que el análisis, diseño, codi ¿Cuál e s e l p rod ucto ob ten id o? Las
cambiando—. Las métricas técnicas ficación y prueba puedan ser conduci métricas del software serán calculadas
ayudan a los ingenieros del software das más objetivamente y valoradas más sobre datos agregados del análisis, de
a profundizar en el diseño y construc cuantitativamente ios modelos de diseño, del código fuen
ción de los productos que desarrollan. ¿Cuáles son los p esos? La primera eta te y de los casos de prueba,
¿Quién lo h ace? Les ingenieros del soft pa en el proceso de medida consiste en ¿Cómo p u e d o ¡‘«te* *«gnro d e q u e
ware usan las métricas técnicas para extraer las medidas y métricas del sof? lo h e Hecho c o r r í st«w;*>nt*'? Hay
ayudarse en el desarrollo de software ware que son apropiadas para la repre que establecer los objetivos y medidas
de mayor calidad. sentación del software que está siendo antes de comenzar la acumulación de
¿Por q ué es importante? Siemprehabrá considerado. A continuación, se requie datos, definiendo sin ambigüedad
elementoscualitativospara la creación ren datos para extraer la formulación de cada métrica técnica. Define pocas
del software. H problema estribaen que métricas agregadas. Una vez calculadas, métricas y utilízalas para profundizar
la valoración cualitativapuede no ser las métricas apropiadas son analizadas en la calidad del resultado obtenido en
suficiente. Un ingeniero del software en base a directrices preestablecidas y la ingeniería del software
A u n q u e la s m é t r i c a s t é c n i c a s p a r a e l s o f t w a r e d e c o m p u t a d o r a n o s o n a b s o l u t a s , n o s p r o
p o r c io n a n u n a m a n e r a s is t e m á tic a d e v a lo r a r la c a lid a d b a s á n d o s e e n u n c o n ju n t o d e « r e g la s
www.FreeLibros.org
c la r a m e n te d e fin id a s » . T a m b ié n le p r o p o r c io n a n a l in g e n ie r o d e l s o f t w a r e u n a v is i ó n in t e r n a e n
e l a c to , e n v e z d e a p o s t e r io r i. E s to p e r m it e a l in g e n ie r o d e s c u b r ir y c o r r e g ir p r o b le m a s p o t e n
c ia le s a n te s d e q u e s e c o n v ie r t a n e n d e fe c to s c a t a s tr ó f ic o s .
323
I N G E N IE RÍ A DEL S O F T W A R E . UN E N F O Q U E P R A C T I C O
En el Capítulo 4 estudiábamos las métricas del software tal y como se aplican a nivel del proceso y del proyecto. En
este capítulo, nuestro punto de atención se desplaza a las medidas que se pueden emplear para valorar la calidad del pro
ducto según se va desarrollando. Estas medidas de atributos internos del producto le proporcionan al desarrollador de soft
ware una indicación en tiempo real de la eficacia del análisis, del diseño y de la estructura del código, la efectividad de los
casos de prueba, y la calidad global del software a construir.
Incluso los desarrolladores del software más hastiados que se pueden m edir directamente (por ejemplo, defec
estarán de acuerdo en que un software de alta calidad es tos por punto de función) y ( 2 ) factores que se pueden
una de las metas más importantes. Pero, ¿cómo definimos m edir sólo indirectam ente (por ejem plo, facilidad de
la calidad? En el Capítulo 8 propusimos diferentes m ane u s o o de m antenimiento). En todos los casos debe apa
ras de interpretar la calidad del software e introdujimos recer la medición. Debemos com parar el software (docu
una definición que hacía hincapié en la concordancia con mentos, programas, datos) con una referencia y llegar
los requisitos funcionales y de rendimiento explícitamen a una conclusión sobre la calidad.
te establecidos, los estándares de desarrollo explícitamente
documentadosy las característicasimplícitas que se espe
ran de todo software desarrollado profesionalmente. CLAVE
Es interesante onotor que los factores de calidad
de McCall son tan válidos hoy como cuando fueron
los primeros propuestos en losaños 70. Aterís,
es razonable Indicar que los factores que afectan
a la calidad del software no cambian.
M cCall y sus colegas [MCC77] propusieron una Útil

N o cabe duda de que la definición anterior podría clasificación de factores que afectan a la calidad del soft
m o d ificase o ampliarse y discutirse eternamente. Para ware. Estos factores de calidad del software, mostrados
los propósitos de este libro, la definición sirve para hacer en la Figura 19.1, se concentran en tres aspectos impor
énfasis en tres puntos importantes: tantes de un producto software: sus características ope
1. Los requisitos del software son la base de las m edi rativas, su capacidad de cam bios y su adaptabilidad a
das de la calidad. La falta de concordancia con los nuevos entornos.
requisitos es una falta de calidad'.
2. Unos estándares específicos definen un conjunto de Facilidad de mantenimiento Portabilidad
criterios de desarrollo que guían la m anera en que se Flexibilidad Reusabilidad
Facilidad de prueba lnteroperatividad
hace la ingeniería del software. Si no se siguen los
criterios, habrá seguramente poca calidad.
R evisión del p ro d u c to d el producto
3 . Existe un conjunto de requisitos im plícitos que a
m enudo no se nom bran (por ejem plo, facilidad de
mantenimiento). Si el software cumple con sus requi
sitos explícitos pero falla en los implícitos, la cali
dad del software no será fiable.
Corrección Fiabilidad Usabilidad Integridad Eficiencia
La calidad del software es una compleja m ezcla de
factores que variarán a través de diferentes aplicacio F IG U R A 1 9 .1 . Factores de calidad de McCall
nes y según los clientes que las pidan. En las siguien
tes secciones, se identifican los factores de la calidad Refiriéndose a los factores anotados en la Figura 19.1,
del software y se describen las actividades hum anas M cCall proporciona las siguientes descripciones:
necesarias para conseguirlos. Corrección. H asta dónde satisface un program a su especi
ficación y logra los objetivos propuestos por el cliente.
Fiabilidad. H asta dónde se puede esperar que un programa
1 9 .1 .1 . F a c t o r e s d e c a l i d a d d e M c C a l l
lleve a cabo su función c o n la exactitud requerida. H ay que
Los factores que afectan a a la calidad del software se hacer notar que se han propuesto otras definiciones de fiabili
pueden categorizar en dos amplios grupos: (1) factores dad más com pletas (vea el C apítulo 8).
1 Es im portante resaltar que la calidad se extiende a los atributos téc

nicos de los m odelos de análisis, de diseño y de codificación. Los
www.FreeLibros.org
m odelos que presentan una alta calidad (en el sentido técnico) darán
lugar a un softw are de una alta calidad desde el pun to de vista del
cliente.
324
C A PIT U L O 19 M ÉTR ICA S T É C N I C A S DEL S O F T W A R E
E fic ie n cia .L a cantidad de recursos inform áticos y de códi C om p lecció n . E l grado con que se h a lo g ra d o la im ple-
go necesarios para que un program a realice su función. m entación total de una función.
Integridad. H asta dónde se puede controlar el acceso al soft C o n cisión.L o com pacto que es el program a en térm inos de
w are o a los datos por personas no autorizadas. líneas de código.
C onsistencia.E l em pleo de un diseño uniform e y de técni
cas de docum entación a lo largo del proyecto de desarrollo del
Q c 'i f a :
software.
I b cotídod de un producto es una fundón E standarizaciónde datos. El em pleo de estructuras y tipos
de ios muchos cambios del mundo por meiorar. de datos estándares a lo largo del program a.
fmDeMerce Tolerancia a l error. El daño causado cuando un program a
encuentra un error.
UsabUidad (facilidad de m anejo). E l esfuerzonecesario para
aprender a operar con el sistem a, preparar los datos de entra E ficiencia de ejecución. E l rendim iento del funcionam ien
da e interpretar las salidas (resultados) de un program a. to de un program a.
C a p a cid a d de e xpansión. El grado con que se pueden
F a cilid a d de m antenim iento. El esfuerzo necesario para
am pliar el diseño arquitectónico, de datos o procedim ental.
localizar y arreglar un error en un program a. (E sta es una defi
nición m uy lim itada). G eneralidad. L a am plitud de aplicación potencial de los
com ponentes del program a.
F lexib ilid a d .E l esfuerzo necesario para m odificar un pro
gram a que ya está en funcionam iento. Indep en d en cia d e l hardware. El grado con que se desaco
pla el softw are del hardw are donde opera.
F acilidad de prueba. El esfuerzo n ecesario para probar un
Instrum entación. E l grado con que el program a vigila su
program a y asegurarse de que realiza correctam ente su fun
propio funcionam iento e identifica los errores que ocurren.
ción.
P ortabilidad. E l esfuerzo necesario para transferir el pro
gram a de un entorno hardw are/softw are a otro entorno dife
rente.
R easabilidad (capacidad de reutilización). H asta dónde se
puede volver a em plear un program a fo p a rte s de un progra
m a) en otras aplicaciones, en relación al em paquetam iento y
alcance de las funciones que realiza el program a. Factoresde Calidad
Interoperatividad. El esfuerzonecesario para acoplarun sis M odularidud. L a independenciafuncional (C apítulo 13) de
tem a con otro. com ponentes de program a.
Es difícil, y en algunos casos im posible, desarrollar O peratividud. L a facilidad de operación de un program a.

m edidas directas de los factores de calidad anteriores. Seguridad. L a disponibilidad de m ecanism os que contro
Por tanto, se d efinen y em plean un conjunto de m étri lan o protegen los program as y los datos.
cas p ara desarro llar expresiones p ara todos los factores, Autodocum entación. El grado en que el código fuente p ro
de acuerdo con la siguiente relació n : porciona d ocum entación significativa.
Sim plicidad. E l grado de facilidad con que se puede enten
F q = C1 X M l + C2 X m 2 +••■■+ Cn X m n
der un program a.
donde F es u n fa c to r de calidad del softw are, c, son
In d e p en d e n cia d e l sistem a software. El grado de indepen
coeficientes de regresión y m, son las m étricas que afec
dencia de program a respecto a las características del lenguaje
tan al facto r de calidad. D esgraciadam ente, m uchas de de program ación no estándar, características del sistem a ope
las m étricas definidas p o r M cC all p u ed en m edirse sola rativo y otras restricciones del entorno.
m ente de m an era subjetiva. L as m étricas pueden ir en Trazabilidad.La capacidad de seguir una representacióndel
form a de lista de c o m p ro b a c ió n q u e se e m p le a para diseño o un com ponente real del program a hasta los requisitos.
«puntuar» atributos específicos del softw are [CAV78], F orm ación. El grado en que ayuda el softw are a m anejar el
El esquem a de p u n tu ació n p ropuesto p o r M cC all es una sistem a a los nuevos usuarios.
escala del O (bajo) al 10 (alto). Se em plean las siguien
tes m étricas en el esq u em a de pun tu ació n: L a relación entre los factores de calidad del softw are
y las m étricas de la lista anterior se m u estra en la Figura
caaagEBEi
las métricasindicadas puedenser valoradas
19.2. D ebería decirse que el peso que se asigna a cada
m étrica depende de lo s productos y negocios locales.
en lasrevisionestécnicasformalesreferenciadas
en el Capítulo8.
19.1.2. FU R PS
F a cilid a d de auditoría. L a facilidad con la que se puede L os factores de calidad descritos p o r M cC all y sus co le
com probar el cum plim einto de los estándares. gas [M CC77] representan sólo una de las m uchas listas
E xactitud. L a exactitud de los cálculos y del control. de com probación sugeridas para la calidad del so ftw a
www.FreeLibros.org
E standarización de com unicaciones. E l grado de em pleo re. H ew lett-P ackard [G RA 87] ha desarrollado un c o n
de estándares de interfaces, protocolos y anchos de banda. ju n to de factores de calidad del softw are al que se le h a
325
dado el acrónimo de FURPS: funcionalidad, facilidad subatributos: facilidad de instalación, facilidad de ajuste, faci
de uso, fiabilidad, rendim ientoy capacidad de soporte. lidad de adaptación al cam bio.
Los factores de calidad FURPS provienen de trabajos
anteriores, definiendo los siguientes atributos para cada
uno de los cinco factores principales:
lÜ lp t id creativorequiere
• La funcionalidad se valora evaluando el conjunto de 3parahacerlo bien, operfecto
características y capacidades del program a, la gene
ralidad de las funciones entregadas y la seguridad
del sistem a global. D e l m is m o m o d o q u e lo s fa c to r e s d e c a lid a d e s tu
• L afacilidad de uso se valora considerando factores d ia d o s e n la s s e c c io n e s 1 9 . 1 . 1 . y 1 9 . 1 . 2 . , lo s f a c t o r e s
humanos (capítulo 15), la estética, la consistencia y I S O 9 1 2 6 n o n e c e s a r ia m e n t e s o n u t iliz a d o s p a r a m e d i
la docum entación general. d a s d ir e c t a s . E n c u a l q u i e r c a s o , f a c i l i t a n u n a v a lio s a
b a s e p a r a m e d id a s in d ir e c t a s y u n a e x c e le n te lis t a p a ra
• La fiabilidad se evalúa midiendo la frecuencia y gra
d e t e r m in a r la c a lid a d d e u n s is t e m a .
vedad de los fallos, la exactitud de las salidas (resul
tados), el tiem po de m edio de fallos (TM D F), la
Capacidad de pruebas
v M é tric a
capacidad de recuperación de un fallo y la capaci
N. d e la calidad
Interoperativllidad
dad de predicción del programa. d e l s o ftw a re
Mantenimiento
• El rendim iento se mide por la velocidad de procesa
Reusabilidad
Portabilidad
Flexibilidad
Fiabialidad
Usabilidad
integridad
Correeión
m iento, el tiem po de respuesta, consum o de recur
Eficiencia
sos, rendim iento efectivo total y eficacia. Factor d e \
c a lid a d \
• La cap acid ad de soporte com bina la capacidad de
ampliar e l program a (extensibilidad), adaptabilidad y Facilidad
servicios (estos tres atributos representan un término de auditoria X X
más común — mantenimiento — ), así como capacidad Exactitud X
Estandarización
de hacer pruebas, compatibilidad, capacidad de con de comunicaciones X
figuración (la capacidad de organizar y controlar ele Compleción X
mentos de la configuración del software [Capítulo9]), Compleiidad X X X
Concisión X X X
la facilidad de instalación de un sistema y la facilidad
Consistencia X X X X
con que se pueden localizar los problemas. Estandarización
Los factores de calidad FURPS y atributos descritos de datos X
Tolerancia a errores X
anteriorm ente pueden usarse para establecer m étricas Eficiencia de ejecución X
de la calidad para todas las actividades del proceso del Capacidad de expansión X
software. Generalidad X X X X
mdependiencia
del hardware X X
19.1.3. Factores de calidad ISO 9126 Instrumentación X X X
Modularidad X X X X X X X
El estándar ISO 9126 ha sido desarrollado en un intento Operatividad X X
de identificarlos atributos clave de calidad para el soft Seguridad X
ware. El estándar identifica seis atributos clave de calidad: Autodocumentación X X X. X X
Simplicidad X X X X
F uncionalidad. El grado en que el softw are satisface las
independencia del sistema X X
necesidades indicadas por los siguientes subatributos: idonei
Trazabilidad X
dad, corrección, interoperatividad, conform idad y seguridad.
Facilidad deformación X
Confiabilidad. C antidad de tiem po que el softw are está dis
ponible para su uso. E stá referido por los siguientes subatri F IG U R A 1 9 .2 . Factores y m étricas de calidad.
butos: m adurez, tolerancia a fallo sy facilidad de recuperación.
Usabilidad. G rado en que el softw are es fácil de usar. Vie 19.1.4. La transición a una visión cuantitativa
ne reflejado por los siguientes subatributos: facilidad de com E n la s s e c c io n e s p r e c e d e n t e s s e e s t u d ia r o n u n c o n ju n
prensión, facilidad de aprendizaje y operatividad. to d e fa c to r e s c u a lit a t iv o s p a r a la « m e d ic ió n » d e la c a li
E ficiencia. G rado en que el softw are hace Óptimo el uso de d a d d e l s o ftw a r e . I n t e n ta m o s d e s a r r o lla r m e d id a s e x a c ta s
los recursos del sistem a.E stá in dicadopor los siguientessuba- d e la c a lid a d d e l s o f t w a r e fr u s tr a d a s a v e c e s p o r la n a tu
tributos: tiem po de uso y recursos utilizados. r a le z a s u b je tiv a d e la a c t iv id a d . C a v a n o y M c C a ll
F acilidadde mantenimiento. La facilidad con que una m odi [ C A V 7 8 ] e s tu d ia n e s ta s itu a c ió n :
ficación puede ser realizada. E stá indicada por los siguientes
L a d eterm in ació n de la calidad es un fa cto r clave en los
subatributos: facilidad de análisis, facilidad de cam bio, estabi
acontecim ientos diarios: concursos de cata de vinos, aconteci
lidad y facilidad de prueba.
m ientos deportivos (por ejem plo, la gim nasia), concursos de
www.FreeLibros.org
Portabilidad. L a facilidad con que el softw are puede ser talento,etc. E n estas situaciones,la calidad seju zg a de la mane
llevado de un entorno a otro. E stá referido por los siguientes ra m ás fundam ental y directa: com paración de objetos unos al
326
CAPÍTULO 19 M ÉT RI CA S T É C N I C A S D EL SOF TW ARE
lado de los otros bajo condiciones idénticas y con conceptos te m anera: «A ño tía s año ingeniam os instrum entos m ás exac
predeterm inados. El vino puede serjuzgado de acuerdo con su to s con los que observar la naturaleza con m ás exactitud. Y
claridad, color, bouquet, sabor, etc. Sin em bargo, este tipo de cuando m iram os las observaciones estam os desconcertados de
ju ic io es m uy subjetivo: para que tenga algo de valor, debe ver que todavía son confusas, y tenem os la sensación de que
hacerse por un experto. son tan inciertas com o siem pre.»
L a subjetividady la especializacióntam bién influyen en la E n las siguientes secciones exam inam os un co n ju n

determ inación de la calidad del softw are. Para resolver este to de m étricas del softw are que pueden aplicarse a la
problem a, se necesita una definición de calidad del softw are valoración cuantitativa de la calidad del softw are. E n
más exacta, así com o una m anera de obtener m edidas cuanti
todos los casos, las m étricas representan m edidas in d i
tativas de la calidad del softw are para hacer un análisis objeti
rectas; es decir, realm en te n u n ca m ed im o s la calid ad
vo.... C om o no e xisteel conocim ientoabsolutom o deberíam os
esperar poder m edir la calidad del softw are exactam ente, ya sino alguna m anifestación de la calidad. E l factor que
que cada m edición es parcialm ente im perfecta. Jacob B ron- lo com plica e s la relación exacta entre la variable que
kowski describióesta paradoja del conocim iento de la siguien se m ide y la calidad del softw are.
I Ü ** - ’ 11 * Ü * '
. ..2.PB..VES*.. ........................... - ..............................í ..i £ c .e h c : . : .............. r i m s
Como dijim os en la introducción de este capítulo, la m edi P ero existe la necesidad de m ed ir y controlar la co m
ción asigna núm eros o sím bolos a atributos de entidades plejidad del softw are. Y si es difícil de obtener un solo
en el m undo real. Para conseguirlo se necesita un m ode v alo r de esta «m étrica de calidad», si debería ser p o si
lo de m edición que com prenda un conjunto consistente ble desarrollar m edidas de diferentes atributos internos
de reglas. A unque la teoría de la m edición (por ejem plo, del program a (por ejem plo, m odularidad efectiva, in d e
[KYB84]) y su aplicación al softw are (por ejem plo, pendencia funcional y otros atributos tratados desde el
[DEM81], [B R I96]) son tem as que están m ás allá del C apítulo 13 al C apítulo 16). E stas m edidas y las m étri
alcance de este libro, m erece la pena estableceruna estruc cas obtenidas de ellas pueden usarse com o indicadores
tura fundam ental y un conjunto de principios básicos para independientes de la calidad de los m odelos de análisis
la medición de m étricas técnicas para el software. y diseño. Pero tam bién surgen problem as aquí. F enton
[FEN94] lo advierte cuando dice:
Q g ita : El peligro de intentar encontrar m edidas que caractericen
tantos atributos diferentes es que, inevitablem ente, las m edi
•i quefasmedidosdetemperatura das tienen que satisfacerobjetivosincom patibles.E sto es con
: ■;¡níúnuníndicedereferenciayevolucionan trario a la teoría de representaciónde la m edición.
| , e-m ;escalos, herramientasytécnicos, A unque la declaración de F enton es correcta, m ucha
v i *ma formaestánmadurandolasmedidas gente argum enta que la m edición técnica llevada a cabo
durante las prim eras fases del proceso de softw are les
proporciona a los desarrolladores de softw are un c o n
sistente y objetivo m ecanism o para v alorar la calidad.
19.2.1. El reto d e la s m é trica s té c n ic a s
C onviene preguntarse, no obstante, qué validez tie
Durante las p asadas tres décadas, m uchos in v estigado nen las m étricas técnicas. E s decir, ¿cóm o están de p ró
res han intentado desarro llar u n a sola m étrica que p ro xim as las m étricas técnicas y la fiabilidad y la calidad a
porcione u n a m edida c o m p leta de la co m p le jid ad del largo plazo de un sistem a basado en com putadora? F en
software. F enton [FE N 94] ca ra c teriz a esta in v e stig a ton [FEN91] trata esta cuestión de la siguiente m anera:
ción com o u n a b ú squeda del « im p o sib le santo grial».
A p e sa r de las intuitivas conexionesentre la estructura inter
Aunque se h an p ropuesto docenas de m edidas de c o m na de los productos softw are (m étricas técnicas) y su produc
plejidad [ZU S90], cada una tiene un punto de vista d ife to externo, y los atributos del proceso, ha habido, de hecho,
rente de lo que es la com plejidad y qué atributos de un m uy pocos intentos científicospara establecer relaciones espe
sistema llevan a la com plejidad. cíficas. H ay varias razones para ello: la que se m enciona m ás
a m enudo es la im posibilidad de llevar a cabo experim entos.
Todos los desafíos m encionados anteriorm ente son
Referencia lüfah m otivo de precaución, pero no es m otivo de d esprecio
de las m étricas técnicas2 . L a m edición es esencial si se
Voluminosa informaciónsobre métricas técnicas han sido desea conseguir calidad.
recopiladas por Horst Zuse: irb.cs.tu-berlin.de/-zuse/
2 Se ha producido una gran cantidad de literatura sobre las m étricas del
software(porejem plo,vea [FEN94], [ROC94], [ZUS97] para obtener unas
extensasbibliografias) y es común la critica de métricas específicas (inclu
yendo algunas de las presentadasen este capítulo)Sin em bargounuchas
www.FreeLibros.org
de las críticas se concentran en aspectos esotéricos y pierden el obje
tivo primario de la m edición en el m undo real: ayudar al ingeniero a
estableceruna m anera sistemática y objetiva de conseguir una visión
interna de su trabajo y mejorar la calidad del producto com o resultado.
327
IN GE NIE RÍ A DEL SOF TW ARE . UN E N F O Q U E PR AC T I C O
19.2.2. P rin c ip io s d e m e d ic ió n • Se deberían aplicar técnicas estadísticas válidas para

A ntes de intro d u cir u n a serie de m étricas técnicas que establecer las relaciones entre los atributos internos
( 1 ) ayuden a la ev aluación de los m odelos de análisis y del producto y las características externas de la cali
diseño, (2) proporcio n en u n a indicación de la co m pleji dad (por ejem p lo , ¿está co rrela cio n a d o el nivel de
dad de los diseños p rocedim entales y del código fuente, com plejidad arquitectónico con el núm ero de defec
y (3) ayuden en el diseño de p ruebas m ás efectivas, es tos descubiertos en la producción?).
im portante entender los principios básicos de la m ed i « Se deberían establecer u n a directrices de interpreta
ción. R oche [ROC94] sugiere un p roceso de m edición ción y recom endaciones para todas las métricas.
que se puede caracterizar p o r cinco actividades: A dem ás de los principios apuntados anteriorm ente,
• fo rm u la c ió n : la obtención de m edidas y m étricas del el éxito de una actividad de m étrica está ligada al sopor
softw are apropiadas para la rep resen tació n del soft te de gestión. Se d e b en co n sid erar los fondos, la for
w are en cuestión. m ación y la prom oción si se quiere establecer y mantener
• colección: el m ecanism o empleado para acum ular datos un p rogram a de m edición técnica.
necesarios p ara obtener las m étricas form uladas.
• análisis: el cálculo de las m étricas y la aplicación de 19.2.3. C a r a c t e r í s t i c a s f u n d a m e n t a l e s d e las
herram ientas m atem áticas. m é tr ic a s d e l s o ftw a re
¿Cuáles son los pasos Se han propuesto cientos de m étricas para el software,
para un proceso pero no todas proporcionan un soporte práctico para el
de medición correcto? d e sa rro llad o r de softw are. A lg u n as d em an d an m edi
ciones que son dem asiado com plejas, otras son tan eso
• interpretación: la ev aluación de los resultados de las téricas que pocos profesionales tienen la esperanza de
m é tric a s en u n esfu erzo p o r co n se g u ir u n a v isió n entenderlas y otras v iolan las nociones básicas intuiti
interna de la calidad de la representación. vas de lo que realm ente es el softw are de alta calidad.
• realim entación (fe e d b a c k ):recom en d acio n es ob te E jiogu [EJI91] define un conjunto de atributos que
n idas de la interpretación de m étricas técnicas tra n s d e b erían ac o m p añ ar a las m étric as efectiv as del soft
m itidas al equipo que construye el softw are. w are. L a m étrica obtenida y las m edidas que conducen
Los principios que se pueden asociar con la form ula a ello deberían ser:
ción de las m étricas técnicas son los siguientes [R O C 94]: • sim p les y fá c ile s de calcular. D e b ería ser relativa
• L os objetivos de la m ed ició n d eberían establecerse m ente fácil aprender a obtener la m étrica y su cál
antes de em p ezar la recogida de datos. culo no debería dem andar un esfu erzo o cantidad de
tiem po inusuales.
« Todas las técnicas sobre m étricas d eberían definirse
sin am bigüedades. ¿Cómo podemos valorar
mm la calidad de una métrica
JF ¿Qué reglas debemos del software propuesta?
I
observar cuando
establecemos medidas técnicas? • em p írica e in tuitivam ente p e rsu a siv a s. L a m étrica
d e b ería sa tisfac er las n o cio n es in tu itiv as del inge
« L as m étricas d eberían obtenerse basándose en una niero sobre el atributo del producto en cuestión (por
teoría válida p ara el dom inio de aplicación (por ejem eje m p lo , u n a m é tric a que m ide la co h esió n de un
plo, las m étricas p ara el diseño han de dibujarse sobre m ódulo debería aum entar su valor a m edida que crece
conceptos y princip io s básicos de diseño y deberían el nivel de cohesión).
inten tar pro p o rcio n ar u n a indicación de la p resencia • consistentes y objetivas. L a m étrica debería siempre
de un atributo que se consid era beneficioso). producir resultados sin am bigüedad. U n tercer equipo
. H ay que h acer las m étricas a m ed id a p ara acom odar d e b e ría ser c ap a z de o b te n e r el m ism o v alor de
m ejor los p roductos y procesos específicos [BAS84], m étrica usando la m ism a inform ación del software.
A unque la form ulación es un p unto de arranque crí • consistentes en el em pleo de unidades y tamaños. El
tico, la recogida y análisis son las actividades que diri cálcu lo m atem ático de la m é tric a d eb e ría em plear
gen el p ro ceso de m edición. R o ch e [R O C 94] sugiere m edidas que no conduzcan a extrañas com binacio
los siguientes principios p ara estas actividades: n es d e unidades. P o r e je m p lo , m u ltip lic an d o el
« Siem pre que sea p o sib le, la reco g id a de d ato s y el núm ero de personas de un equipo p o r las variables
análisis debe autom atizarse. del lenguaje de program ación en el program a resulta
una sospechosam ezcla de unidades que no son intui
$ «MSEKJÍ^ tivam ente persuasivas.
www.FreeLibros.org
Por encima de todo, intento obtener medidos técnicos
• in d ep endientes del lenguaje de p ro g ra m a c ió n . Las
simples. No te obsesiones por lo métrica «perfecta» m étrica s d e b e ría n b a sa rse en el m o d e lo de análi
porque no existe. sis, m o d elo de d ise ñ o o en la p ro p ia e stru c tu ra del
328
CAPÍTULO 19 MÉ TRI CA S T É C N I C A S DEL S O F T W A R E
program a. N o d eb erían d e p e n d e r de los caprichos A u n q u e la m a y o ría d e las m é tric a s d e s o ftw a re

de la sin tax is o sem án tica del len g u aje de p ro g ra satisfacen las ca ra cterística s an te rio res, a lg u n a s d e la
m ación. m é tric a s c o m ú n m e n te e m p le a d a s d e ja n d e c u m p lir
• un eficaz m ecanism o p a r a la realim entación de cali u n a o dos. U n ejem p lo es el p u n to d e fu n c ió n (tra ta
dad. L a m étrica debería proporcionar, al desarrollado en el C ap ítu lo 4 y en este capítulo). Se p u ede a rg u
d o r de so ftw a re , in fo rm a c ió n q u e le llev e a un m e n ta r3 q u e el a trib u to c o n s is te n te y o b je tiv o fa lla
p roducto final de m ay o r calidad. p o rq u e un e q u ip o ajen o in d e p e n d ie n te p u e d e n o ser
c ap az de o b ten e r el m ism o v a lo r del p u n to de fu n ció n
que o tro e q u ip o q u e u se la m is m a in fo rm a c ió n del
softw are. ¿D eb eríam o s e n to n c e s re c h a z a r la m e d id a
Laexperiencia indica que una métrica técnica se usa P F ? L a resp u esta es « ¡p o r su puesto que no!». E l P F
únicamente si es intuitiva y fácil de calcular. Si se requiere p ro p o rc io n a u n a ú til v isió n in te rn a y p o r ta n to p ro
docenas de «contadores» y se han de utilizarcomplejos p o rciona un v alo r cla ro , in clu so si no satisface un atri
cálculos, la métrica no será ampliamente utilizado. b u to p erfectam ente.
-19.3. METRIC. AS DE L M ODELO DE ANÁLISIS

El trabajo técnico en la ingeniería del softw are em pie 1 9 .3 .1 . M é t r i c a s b a s a d a s e n l a f u n c i ó n
za con la creación del m odelo de análisis. E n e sta fase L a m étrica de punto de función (PF) (Capítulo 4) se pue
se obtienen los requisitos y se establece el fundam ento de usar com o m edio para p redecir el tam año de un siste
para el diseño. P or tanto, son deseables las m étricas té c m a que se v a a obtener de un m odelo de análisis. Para
nicas que proporcio n an u n a v isió n in tern a a la calidad ilustrar el em pleo de la m étrica de PF en este contexto,
del m odelo de análisis. consideram os una sencilla representación del m odelo de
análisis m ostrada en la Figura 19.3. En la figura se rep re
g m m sE sssñ senta un diagram a de flujo de datos (C apítulo 12)de una
los modelos de datos, fundones y comportamientos función del sistem a H ogarSeguro4. La función gestiona
son tratados en los Capítulos 11 y 12. la interacción con el usuario, aceptando una contraseña
de usuario para activar/desactivar el sistem ay perm itien
A unque han aparecido en la literatura relativam en do consultas sobre el estado de las zonas de seguridad y
te pocas m étricas de análisis y especificación, es p o si varios sensores de seguridad. La función m uestra una serie
ble adaptar m étricas obtenidas p ara la aplicación de un de m ensajes de petición y envía señales apropiadas de
proyecto (C apítulo 4) p ara em plearlas en este contex control a varios com ponentes del sistem a de seguridad.
to. Estas m étricas ex am inan el m odelo de análisis con
la intención de p red ecir el «tam año» del sistem a re su l
tante. Es p robable que el tam año y la com plejidad del
Para ser útil para el trabajo técnica, las medidas técnicas
diseño estén directam ente relacionadas.
que apoyan la tomo de decisión (ej: errores encontrados
durante la prueba de unidad) deben ser agrupadas
y normalizadas utilizando la métrica PF.
El diagram a de flujo de datos se e v alú a para deter

S e n s o re s
C e n s o r d e P ru e b a ,. m in ar las m edidas clave necesarias para el cálcu lo de
Co n tra s e ñ a
la m étrica de punto de.función (C apítulo 4):
C o n s u lta d e zona F u n c io n es C o n fig u ra c ió n d e zo n a
C o n s u lta d e s e n s o r d e in te ra c c ió n í M e n s a je s
• núm ero de entradas del usuario
U suario s d e l u s u a rio con U s u a rio
In te rru p to r núm ero de salidas del usuario
d e e m e rg e n c ia \HogarSegurqJ te s ta d o d e l s e n s o r
p ^ ^ ^ ^ \\A c t iv a r /D e s a c t iv a r
• núm ero de consultas de usuario
A c tiv a r/ d e s a c tiv a r .
A le d a S u b s is te m a • núm ero de archivos
C o n tra s e ñ a s , s e n s o r e s ... d e a la rm a de
m o n ito riz a c ió n núm ero de interfaces externas
D ô ^ô nfigura ciójê U iste m ^J Tres entradas del usuario: c o n tr a s e ñ a ,in te r r u p to r
d e e m e r g e n c ia y a c tiv a r /d e s a c tiv a r aparecen en la
F IG U R A 1 9 .3 . P arte del m o d e lo de análisis del s o ftw a re de fig u raju n to con dos consultas: c o n s u lta d e z o n a y c o n
HogarSeguro. s u lta d e s e n s o r. Se m u e stra un archivo (a rc h iv o d e
www.FreeLibros.org
3 Fíjese que se puede hacer un contra argumento igualmente vigo- 4 HogarSeguro e s un sistema de seguridad para el hogar que se ha
roso. Tal es la naturaleza de las métricas del software usado como aplicación de ejemplo en capítulos anteriores
329
IN GE NIE RÍA DEL S OFT W ARE . UN EN F O Q U E P R A C T I C O
c o n fig u ra c ió n d el s is te m a ). También están presentes tor del proyecto una importante información de plani
dos salidas de usuarios (m e n s a je s y e s ta d o s d el se n ficación basada en el m odelo de análisis en lugar de en
s o r) y cuatro interfaces externas (s e n s o r d e p r u e b a , estim aciones preliminares.
co n fig u ra c ió n d e zo n a , a c tiv a r/d e s a c tiv a r y a le r ta de C onsiderar que de los proyectos anteriores se han
a la r m a ) . Estos datos, ju n to con la com plejidad apro encontrado una m edia de 3 errores por punto de función
piada, se m uestran en la Figura 19.4. durante las revisiones de análisis y diseño, y 4 errores
Factor d e ponderación
por punto de función durante las pruebas unitaria y de
Parámetro Cuenta Simple Media Compleja
integración. Estos datos pueden ayudar a valorar a los
de medición ingenieros del software la com pletitud de su s revisio
nes y las actividades de prueba.
Número de entradas 0 x 0
del usuario □
0 X 0 19.3.2. l a M é tr ic a b a n g
Número de salidas
del usuario
5
□ Al igual que la m étrica de punto de función, la métrica
consuftas bang puede emplearse para desarrollar una indicación
6 =
□ del tam año del software a im plem entar com o conse
cuencia del m odelo de análisis.
Número de archivos
□ x0 10 15
□ Desarrollada por DeMarco [DEM82], la métrica bang
es «una indicación independiente de la implernentación
Número de interfacesl0 X 0 7 10 = del tamaño del sistema». Para calcular la m étrica bang,
extemas
el desarrollador de software debe evaluar prim ero u n
Cuenta total
conjunto de prim itivas (elementos del m odelo de aná
lisis que no se subdividen m ás en el nivel de análisis).
Las prim itivas [DEM82] se determ inan evaluando el
F IG U R A 19.4. C álculo de p u n to s de fu n c ió n
m odelo de análisis y desarrollando cuentas para los
p a ra una fu n c ió n de H ogar Seguro. siguientes elem entos?
La cuenta total mostrada en la Figura 19.4debe ajus P r im itiv a s fu n c io n a le s (P F u ). Transform aciones (burbu
ja s) que aparecen en el nivel inferior de un diagram a de flujo
tarse usando la ecuación (4.1):
de datos (C apítulo 12).
PF= cuenta-total x (0,65 + 0,01 x X[F7j) E le m e n to s d e d a to s (E D ). L os atributos de un objeto de
Donde cuenta-total es la suma de todas las entradas PF datos, los elem entos de datos son datos no com puestos y apa
obtenidas en la Figura 19.3y F¡ (i=l a 14) son «los valo recen en el diccionario de datos.
res de ajuste de complejidad». Para el propósito de este O b je to s (O B ). O bjetos de datos tal y com o se describen en
ejemplo, asumimos que X[F7] es 46 (un producto m ode el C apítulo 11.
radam ente complejo). Por tanto: R elaciones (R E ). L as conexiones entre objetos de datos tal
PF= 50 x [0,65 + (0,01 x 46)] = 56 y com o se describen en el C apítulo 12.
E sta d o s (ES). E l núm ero de estados observables por el usua-
n o en el diagram a d e transición de estados (C apítulo 12).
T ran sicio n es (T R ). E l núm ero de transicionesde estado en
el diagram a de transición de estados (C apítulo 12).
Referencia Wgfe/
Una introducción útil al PF ha sido elaborada
por Capéis Jones y puede ser localizada en:
www.spr.com/ líbrary/ 0funcmet.htm A n ís s rp reflexionemos sobre uno «nuevo métrico»
¿«temos(îcor... podemos preguntarnos nosotros
jÉSfflOS sobre los puntos básicos, «Qué pretendemos
Basándose en el valor previsto de PF obtenido del jk w is métricas.
m odelo de análisis, el equipo del proyecto puede esti A k t ó NUk y Larry Pvtium
m ar el tam año global de im plementación de las funcio
nes de interacción de HogarSeguro. Asuma que los datos Además de las seis prim itivas apuntadas arriba, se
de los que se disponen indican que un PF supone 60 determ inan las cuentas adicionales para:
líneas de código (se va a usar un lenguaje orientado a P rim itiv a s m o d ific ad a s de fu n c ió n m a n u a l (PM Fu). Fun
objetos) y que en un esfuerzo de un m es-persona se pro ciones que caen fuera del lím ite del sistem a y que deben modi
ducen 12PF. Estos datos históricos proporcionan al ges- ficarse para acom odarse al nuevo sistema.
www.FreeLibros.org
5 El acrónim o apuntado entre paréntesis a continuación de la primi
tiva se em plea para denotar la cuenta de la prim itiva particularipor
ejem plo.PFu indica el núm ero de prim itivas funcionales presente a i
un m odelo de análisis.
330
CAPÍTULO 19 M É TR IC A S T É C N I C A S DEL S O F T W A R E
Elementos de datos de entrada (EDE). Aquellos elem entos

de datos que se introducen en el sistema. Tci IP F u C
Elementos de datos de salida (EDS). A quellos elem entos 2 1 ,0
de datos que se sacan del sistema. 5 ,8
5
Elementos de datos retenidos (EDR). A quellos elem en 10 1 6 ,6
tos de datos que son retenidos (alm acenados) por el sistema. 15 2 9 ,3
Muestras (to k e n s ) de datos (TC¡). L as m uestras de datos 20 4 3 ,2
(elem entos de datos que no se subdividen dentro de una pri
m itiva funcional) que existen en el lím ite de la i-ésim a prim i L a p o n d e r a c ió n v a lo r a d a a p u n ta d a e n e l a lg o r it m o
tiva funcional (evaluada para cada prim itiva). a n t e r i o r s e c a l c u l a d e d i e c i s é i s c la s e s d i f e r e n t e s d e p r i
Conexiones de relación (RE¡). Las relaciones que conec m i t iv a s f u n c io n a le s d e f in id a s p o r D e M a r c o . S e a s ig n a
ta r el i-ésim o objeto en el m odelo de datos con otros objetos. u n a p o n d e r a c ió n q u e v a d e 0 , 6 ( e n c a m in a m ie n to s im
D e M a r c o [ D E M 8 2 ] s u g ie r e q u e la m a y o r í a d e l s o f t p le d e d a to s ) a 2 ,5 ( fu n c io n e s d e g e s tió n d e d a to s ) d e p e n
w a re s e p u e d e a s ig n a r a u n o d e lo s d o s d o m in io s s ig u ie n d ie n d o d e la c la s e d e la p r i m it iv a .
te s , dominio defunción o dominio de datos, d e p e n d i e n d o P a r a a p lic a c io n e s d e d o m in io d e d a to s , s e c a lc u la la
d e la r e la c ió n R E / P F u . L a s a p lic a c io n e s d e d o m in io d e m é t r ic a b a n g m e d ia n te e l s ig u ie n te a lg o r it m o :
f u n c ió n ( e n c o n tr a d a s c o m ú n m e n te e n a p lic a c io n e s d e Asignar a bang el valor in ic ia l = 0 ;
in g e n ie r í a y c ie n t í f ic a s ) h a c e n h in c a p ié e n la t r a n s f o r M ientras queden objetos po r evaluar en el modelo de
m a c ió n d e d a to s y n o p o s e e n g e n e r a lm e n t e e s tr u c tu r a s datos
d e d a to s c o m p le ja s . L a s a p lic a c io n e s d e d o m in io d e Calendar l a cuenta de relaciones' del objeto i
d a to s ( e n c o n t r a d a s c o m ú n m e n t e e n a p lic a c io n e s d e s is Calcular el incremento de OB corregido (IOBC);
te m a s d e in f o r m a c ió n ) t ie n d e n a t e n e r m o d e lo s d e d a to s bang = bang t IOBC;
c o m p le jo s . Fi n Mi entras
RE/PFu < 0,7 im plica una aplicación de dom inio de función E l I O B C c o r r e g id o s e d e te r m in a ta m b ié n d e u n a t a b la

0 ,8 < R E /P F u < l,4 in d ic a u n a aplicación híbrida p u b lic a d a p o r D e M a r c o . A c o n t in u a c ió n se m u e s tr a u n a
v e r s ió n a b r e v ia d a :
RE/PFu > 1 ,5 im plica una aplicación de dom inio de datos
C o m o d ife r e n te s m o d e lo s d e a n á lis is h a r á n u n a p a r R E i IO B C
tic ió n d e l m o d e lo c o n m a y o r o m e n o r g r a d o d e r e f in a
1 1 ,0
m ie n to . D e M a r c o s u g ie r e q u e s e e m p le e u n a c u e n ta
3 4 ,0
m e d i a d e m u e s t r a (token) p o r p r i m i t i v a
6 9 ,0
p a ra c o n t r o la r la u n if o r m id a d d e la p a r t ic ió n a tr a v é s d e U n a v e z q u e s e h a c a lc u la d o la m é t r ic a b a n g , s e p u e
m u c h o s d ife r e n te s m o d e lo s d e n tr o d e l d o m in io d e u n a d e e m p le a r e l h i s t o r ia l a n t e r io r p a r a a s o c ia r la c o n e l
a p lic a c ió n . e s f u e r z o y e l t a m a ñ o . D e M a r c o s u g i e r e q u e la s o r g a n i
P a r a c a l c u l a r l a m é t r i c a bang p a r a a p l i c a c i o n e s d e z a c io n e s s e c o n s t r u y a n s u s p r o p ia s v e r s io n e s d e t a b la s
d o m in io d e f u n c ió n , s e e m p le a e l s ig u ie n te a lg o r it m o : IP F u C e I O B C p a r a c a lib r a r la in f o r m a c ió n d e p r o y e c
Asignar a bang un valor in ic ia l = <¡); to s c o m p le t o s d e s o ftw a r e .
Mientras queden p rim itiv a s funcionales p o r evaluar
Calcular cuenta-token alrededor del lím ite de l a 1 9 3 3 . M é tric a s d e l a c a lid a d d e l a e s p e c ific a c ió n
p r im itiv a i;
D a v is y s u s c o le g a s [ D A V 9 3 ] p r o p o n e n u n a lis t a d e c a r a c
Calendar el incremento PFu corregido (IPFuC) te r ís tic a s q u e p u e d e n e m p le a r s e p a r a v a lo r a r la c a lid a d d e l
Asignar l a p r i m i t i v a a una clase
m o d e lo d e a n á lis is y la c o r r e s p o n d ie n t e e s p e c if ic a c ió n d e
Evaluar l a clase y anotar el peso valorado r e q u is ito s : e s p e c if ic id a d ( a u s e n c ia d e a m b ig ü e d a d ) , c o m -
M ultiplicar IPFuC por el peso valorado
p le c ió n , c o r r e c c ió n , c o m p r e n s ió n ,c a p a c id a d d e v e r if ic a
bang = bang + ponderación IPFuC: c ió n , c o n s is te n c ia in te r n a y e x te r n a , c a p a c id a d d e lo g r o ,
FinMi en tras
c o n c is ió n , t r a z a b ilid a d , c a p a c id a d d e m o d if ic a c ió n , e x a c
L a c u e n t a - t o k e n s e c a lc u la d e te r m in a n d o c u á n to s t i t u d y c a p a c id a d d e r e u t iliz a c ió n . A d e m á s , lo s a u to r e s
s í m b o l o s l é x i c o s (tokens) d i f e r e n t e s s o n « v isib les» a p u n t a n q u e la s e s p e c i f i c a c i o n e s d e a l t a c a l i d a d d e b e n
[D E M 8 2 ] d e n tr o d e la p r im it iv a . E s p o s ib le q u e e l n ú m e e s ta r a lm a c e n a d a s e le c tr ó n ic a m e n t e , s e r e je c u ta b le s o a l
r o d e s í m b o l o s l é x i c o s (tokens) y e l n ú m e r o d e e l e m e n t o s m e n o s in t e r p r e t a b le s , a n o ta d a s p o r im p o r t a n c ia y e s t a b i
d e d a to s s e a d ife r e n te , s i lo s e le m e n to s d e d a to s p u e d e n lid a d r e la tiv a s , c o n s u v e r s ió n c o r r e s p o n d ie n te ,o r g a n iz a -
m o v e rs e d e s d e la e n tr a d a a la s a lid a s in n in g u n a tr a n s d a s , c o n r e f e r e n c ia s c r u z a d a s y e s p e c if ic a d a s a l n i v e l
www.FreeLibros.org
f o r m a c ió n in te r n a . L a I P F u C c o r r e g id a s e d e t e r m in a d e c o r r e c t o d e d e ta lle .
u n a ta b la p u b lic a d a p o r D e M a r c o . A c o n t in u a c ió n , se A u n q u e m u c h a s d e la s c a r a c t e r í s t i c a s a n t e r i o r e s p a r e
p re s e n ta u n a v e r s ió n m u y a b r e v ia d a : c e n s e r d e n a tu r a le z a c u a lit a t iv a , D a v is [ D A V 9 3 ] s u g ie
331
re que to d as p u e d a n re p re se n ta rse u san d o u n a o m ás donde n u¡ es el núm ero de requisitos para los que todos
m étricas6. P or ejem plo, asum im os que hay nr req u isi los revisores tuvieron interpretaciones idénticas. C uan
tos en una especificación, tal com o to m ás cerca de 1 esté el valor de Q, m en o r será la am bi
g üedad de la especificación.
nr = nf + nnf La com pleción de los requisitos funcionales pueden
donde «y es el núm ero de requisitos funcionales y es determ inarse calculando la relación
el núm ero de requisitos no fu n cio n ales (por ejem plo,
rendim iento). Q2= un! ( * /x «s)
donde u, es el núm ero de requisitos únicos de función,
n¡ e s el n ú m e ro de e n tra d a s (e stím u lo s) d e fin id o s o
im p licad o s p o r la e sp e cific ació n y n s es el n ú m ero de
O .A V E
estad o s esp ecificad o s. L a rela ció n Q, m ide el p o rcen
Para medir las característlcasde Id especificación, es taje de fu n cio n es n ec esa rias que se han especificado
necesario conseguir profundizar cuantitativamente en la para un sistem a. Sin em bargo, no tra ta los requisitos
especificidad y en la completitud. no funcionales. P ara in c o rp o ra rlo s a una m étrica glo
bal co m p leta, deb em o s c o n sid erar el g rado de valid a
P ara d eterm inar la especificidad (ausencia de am bi ción de los requisitos.
güed ad ) de los req u isito s. D avis su g iere u n a m étrica Q 3 = nc / ( n c + n J
basada en la consistencia de la interpretación de los revi donde nc es el núm ero de requisitos que se han valida
sores para cada requisito: do com o correctos y n " el núm ero de requisitos que no
Q i = n ui/ n r se han validado todavía.
¡CAS PEI MODELO D£ DISEÑO

Es in co n ceb ib le que el d iseñ o de un n u ev o avión, un E n las siguientes secciones exam inam os algunas de
nuevo chip de com putadora o un nuevo edificio de o fi las m étricas de diseño m ás com unes para el softw are de
cin as se re a liz a ra sin d e fin ir las m ed id as del d ise ñ o , com putadora. A unque ninguna es perfecta, todas pue
sin d e te rm in a r las m étricas p ara v arios asp ecto s de la den proporcionar al diseñador una m ejo r visión interna
calidad del diseño y u sarlas p ara guiar la evolución del y ayudar a que el diseñ o evolucione a un nivel superior
diseño. Y sin em b arg o , el d iseñ o de sistem as c o m p le de calidad.
j o s basados en c o m p u tad o ra a m en u d o co n sig u e p ro
seg u ir sin v irtu alm en te n in g u n a m ed ició n . L a ironía 19.4.1. Métricas del diseño arquitectónico
e s q u e las m é tric a s de d ise ñ o p a ra e l so ftw a re e stá n
L as m étricas de diseñ o de alto nivel se concentran en
d isp o n ib les, pero la gran m ay o ría de los desarro llado-
res de so ftw are co n tin ú an sin sab er que existen. las característicasde la arquitectura del program a (Capí
tulo 14) con especial énfasis en la estructura arquitec
tónica y en la eficiencia de los m ódulos. E stas m étricas
son de caja negra en el sentido que no requieren ningún
k medidaqueesapredable, conocim iento del trabajo interno de un m ódulo en par
yquetíoesapredable, sehaceapredable. ticu lar del sistem a.
G*8te« C ard y G lass [C A R 90] d efin en tre s m edidas de la
c o m p le jid a d d e l d ise ñ o del so ftw are: co m p lejid ad
Las m étricas de diseño para el softw are, com o otras e stru c tu ra l, co m p lejid ad de d a to s y co m p lejid ad del
m étric a s del so ftw a re , no son p erfectas. C o n tin ú a el sistem a.
d e b a te so b re la e fic a c ia y có m o d eb erían aplicarse. La co m p lejid a d estructural, S(i), de un m ódulo i se
M uchos expertos argum entan que se n ecesita m ás e x p e define de la siguiente m anera:
rim en tació n hasta que se p u ed an em plear las m étricas
S d ) = f outd ) (19-1)
de diseño. Y sin em bargo, el diseño sin m ed ició n es una
alternativa inaceptable. d o n d e / di) es la expansión' del m ódulo i.
www.FreeLibros.org
6 Un estudio completo de las métricas de calidad de especificación 7 Como se dijo en el estudio introducido en el Capítulo 13, la expan
está m ás allá del alcance de este capítulo. Vea [DAV93] para m ás sión (fout) indica el número de módulos inmediatamente subordina
detalles. dos al módulo ¡, es decir, el número de módulos que son invocados
directamente por el módulo i.
332
C A P Í T U L O 19 MÉ TR IC A S T É C N I C A S DEL S OF TW AR E
d o n d e n e s e l n ú m e r o d e n o d o s ( m ó d u lo s ) y a e s e l
n ú m e r o d e a r c o s ( lín e a s d e c o n t r o l) . P a r a la a r q u it e c t u
CLAVE r a m o s t r a d a e n la F ig u r a 1 9 .5 ,
Las máfcas pueden profundizar en la estructura,
en los datos, y en lacomplejidad del sistema skxb±>
con el diseño arquitectónico.
L a c o m p le jid a d d e d a to s , D ( i ) , p r o p o r c io n a u n a i n d i
c a c ió n d e la c o m p le jid a d e n la in t e r f a z in t e r n a d e u n
m ó d u lo i y s e d e f in e c o m o :
D (i)= v(i) ¡ \fQJ i ) + 1] (1 9 .2 )
d o n d e v ( i) e s e l n ú m e r o d e v a r ia b le s d e e n tr a d a y s a li
d a q u e e n t r a n y s a le n d e l m ó d u lo í
F in a lm e n t e , la c o m p le jid a d d e l s is te m a , C ( i ) , s e d e f i
n e c o m o l a s u m a d e la s c o m p l e j i d a d e s e s t r u c t u r a l y d e
4 - Anchura -
d a to s , y s e d e f in e c o m o :
F IG U R A 1 9 .5 . Métricas de morfología
C ( i) = S ( i) + D ( i) (1 9 .3 )
A m e d id a q u e c r e c e n lo s v a lo r e s d e c o m p le jid a d , la t a m a ñ o = 17 + 1 8 = 35
c o m p le jid a d a r q u it é c t ó n ic a o g lo b a l d e l s is t e m a t a m p r o f u n d id a d = e l c a m in o m á s la r g o d e s d e e l n o d o
b ié n a u m e n ta . E s to lle v a a u n a m a y o r p r o b a b ilid a d d e r a í z ( p a r te m á s a lt a ) a u n n o d o h o ja . P a r a la
q u e a u m e n te e l e s fu e r z o n e c e s a r io p a r a la in te g r a c ió n a r q u it e c t u r a m o s t r a d a e n la F ig u r a 1 9 .5 , la
y la s p r u e b a s . p r o fu n d id a d = 4 .
¿Hay un camino para a n c h u ra = m á x im o n ú m e r o d e n o d o s d e c u a lq u ie r
§ valorar la Complejidad
de ciertos modelos
arquitectónicos?
n iv e l d e la a r q u it e c t u r a . P a r a la a r q u it e c t u r a m o s t r a
d a e n la F ig u r a 1 9 .5 , la a n c h u r a = 6 .
R e l a c i ó n a r c o - a - n o d o , y = a / n.
q u e m id e la d e n s id a d d e c o n e c t iv id a d d e la a r q u it e c t u
U n a m é tr ic a d e d is e ñ o a r q u it e c t ó n ic o d e a lto n iv e l,
r a y p u e d e p r o p o r c io n a r u n a s e n c illa in d ic a c ió n d e l a c o
p r o p u e s t a p o r H e n r y y K a f u r a [ H E N 8 1 ], t a m b i é n e m p l e a
p la m ie n t o d e la a r q u it e c t u r a . P a r a la a r q u it e c t u r a
la e x p a n s i ó n y l a c o n c e n t r a c i ó n . L o s a u t o r e s d e f i n e n
m o s t r a d a e n la F ig u r a 1 9 .5 , y = 1 8 / 1 7 = 1 , 0 6 .
u n a m é tr ic a d e c o m p le jid a d d e la f o r m a :
M H K = l o n g i t u d ^ : ) x \ J J i ) + f 0J i ) ] 2 (1 9 .4 )
Q c i
d o n d e l a longitud(i) e s e l n ú m e r o d e s e n t e n c i a s e n l e n til medición puede ser visto como un rodeo. Este
g u a je d e p r o g r a m a c i ó n e n e l m ó d u l o i y f in ( i ) e s l a c o n rodeo és necesorio porque los humónos muchos
c e n t r a c ió n d e l m ó d u lo í H e n r y y K a f u r a a m p lí a n la veces no estamos copocitodos paro tomor decisiones
d e f in ic ió n d e c o n c e n t r a c ió n y e x p a n s ió n p r e s e n ta d a s con claridad y objetividad [sin un soporte
e n e s te li b r o p a r a i n c l u i r n o s ó lo e l n ú m e r o d e c o n e
x io n e s d e c o n t r o l d e l m ó d u l o ( lla m a d a s a l m ó d u lo ) ,
s in o t a m b i é n e l n ú m e r o d e e s t r u c t u r a s d e d a t o s d e l q u e
e l m ó d u lo i r e c o g e ( c o n c e n t r a c ió n ) o a c tu a liz a ( e x p a n
19.4.2. M étricas d e d iseñ o a n iv el d e com po
s ió n ) d a t o s . P a r a c a lc u la r e l M H K d u r a n t e e l d i s e ñ o nentes
p u e d e e m p le a r s e e l d is e ñ o p r o c e d im e n t a l p a r a e s t im a r L a s m é tr ic a s d e d is e ñ o a n i v e l d e c o m p o n e n te s s e c o n
e l n ú m e r o d e s e n te n c ia s d e l le n g u a je d e p r o g r a m a c ió n c e n t r a n e n la s c a r a c t e r í s t ic a s in t e r n a s d e lo s c o m p o
d e l m ó d u l o i. C o m o e n l a s m é t r i c a s d e C a r d y G l a s s n e n t e s d e l s o f t w a r e e i n c l u y e n m e d i d a s d e la s « 3 C s »
m e n c io n a d a s a n t e r io r m e n t e , u n a u m e n t o e n la m é t r i — la c o h e s ió n , a c o p la m ie n t o y c o m p le jid a d d e l m ó d u
c a d e H e n r y - K a fu r a c o n d u c e a u n a m a y o r p r o b a b ili lo — i E s t a s t r e s m e d i d a s p u e d e n a y u d a r a l d e s a r r o l l a
d a d d e q u e t a m b ié n a u m e n te e l e s fu e r z o d e in te g r a c ió n d o r d e s o ftw a r e a ju z g a r la c a lid a d d e u n d is e ñ o a n iv e l
y p r u e b a s d e l m ó d u lo . d e lo s c o m p o n e n te s .
F e n to n [F E N 9 1 ] s u g ie r e v a r ia s m é tr ic a s d e m o r f o L a s m é t r ic a s p r e s e n ta d a s e n e s ta s e c c ió n s o n d e c a ja
lo g í a s im p le s ( p o r e j e m p lo , f o r m a ) q u e p e r m it e n c o m b la n c a e n e l s e n tid o d e q u e r e q u ie r e n c o n o c im ie n t o d e l
p a r a r d if e r e n te s a r q u it e c t u r a s d e p r o g r a m a m e d ia n te t r a b a jo in t e r n o d e l m ó d u lo e n c u e s tió n . L a s m é t r ic a s d e
u n c o n ju n t o d e d im e n s io n e s d ir e c ta s . E n la F ig u r a 1 9 .5 , d is e ñ o d e lo s c o m p o n e n te s s e p u e d e n a p lic a r u n a v e z
www.FreeLibros.org
se p u e d e n d e f i n i r la s s i g u i e n t e s m é t r i c a s : q u e s e h a d e s a r r o lla d o u n d is e ñ o p r o c e d im e n t a l. T a m
b ié n se p u e d e n r e tra s a r h a s ta te n e r d is p o n ib le e l c ó d i
tam añ o = n + a 19.5
g o fu e n te .
333
INGE NIERÍA DEL SOF TW ARE . UN EN F O Q U E P R Á C T I C O
porciones de datos de un módulo i). Como la relación de

muestras de superunión con respecto al numero total de
CLAVE muestras en un módulo i aumenta hasta un valor máximo
Es posiblecalcular medidos de la Independencia de 1, la cohesión funcional del módulo también aumenta.
funcional, acoplamiento y cohesión de un componente Métricas de acoplamiento. El acoplam iento de
y usarlos paro valorar la calidady el diseño. m ódulo proporciona una indicación de la «conectivi-
dad» de un módulo con otros m ódulos, datos globales
M é tric a s d e cohesión. B i e m a n y O t t [ B I E 9 4 ] d e f i y el entorno exterior. En el Capítulo 13, el acoplam ien
n e n u n a c o le c c ió n d e m é tr ic a s q u e p r o p o r c io n a n u n a to se estudió en términos cualitativos.
in d ic a c ió n d e la c o h e s ió n ( C a p í t u lo 1 3 ) d e u n m ó d u lo . Dhama [DHA95] ha propuesto una m étrica para el
L a s m é tr ic a s s e d e fin e n c o n c in c o c o n c e p to s y m e d id a s : acoplamiento del módulo que com bina el acoplam ien
P orción de datos. D icho sim plem ente.una porción de datos to de flujo de datos y de control, acoplamiento global y
es una m archa atrás a través de un m ódulo que busca valores acoplamiento de entorno. Las m edidas necesarias para
de datos que afectan a la localización de m ódulo en el que em pe calcular el acoplamiento de módulo se definen en tér
zó la m archa atrás. D ebería resaltarse que se pueden definir tan m inos de cada uno de los tres tipos de acoplamiento
to porciones de program as (que se centran en enunciados y
apuntados anteriormente.
condiciones) com o porciones de datos.
Para el acoplam iento de flu jo de datos y de control:
M uestras (tokens) de datos. L as variables definidas para
d¡ = núm ero de parám etros de datos de entrada
un m ódulo pueden definirse com o m uestras de datos para el
m ódulo. c¡ = núm ero de parám etros de control de entrada
Señales de unión. E l conjunto d e m uestras de datos que se da = núm ero de parám etros de datos de salida
encuentran en una o m ás porciones d e datos. c0 = núm ero de parám etros de control de salida
Señales de superunión. L a m uestras de datos com unes a
todas las porciones de datos de un m ódulo.
P egajosidad. L a pegajosidad relativa de una m uestra de
-M *
unión es directam ente proporcional al núm ero de porciones de
Referencia KteW
datos que liga. Edocumento,«Sistema de métricas del software
B i e m a n y O t t d e s a r r o l l a n m é t r i c a s p a r a cohesiones módulos» podéis bajarlo de
para el acoplamiento de
fu n c io n a le s fu e r te s ( C F F ) , co hesionesfuncionales d éb i www.isse.gmu.edu/faculty/of u t/rs rc h /

abstracts/mj-coupling.html
les ( C F D ) y p e g a jo s id a d ( e l g r a d o r e l a t i v o c o n e l q u e
la s s e ñ a le s d e u n ió n l i g a n ju n t a s p o r c io n e s d e d a to s ) .
Para el acoplam iento global:
E s ta s m é t r ic a s s e p u e d e n in t e r p r e t a r d e la s ig u ie n t e
g d = núm ero de variables globales usadas com o datos
m a n e ra [B IE 9 4 ]:
g c = núm ero de variables globales usadas com o control
Todas estas m étricas de cohesión tienen valores que van de
0 a 1. Tienen un v alor de 0 cuando un procedim iento ti ene m ás
de una salida y no m uestra ningún atributo de cohesión indi Para el acoplam iento de entorno:
cado por una m étrica particular. U n procedim iento sin m ues w = núm ero de m ódulos llam ados (expansión)
tras de superunión,sin m uestras com unes a todas las porciones
r = núm ero de m ódulos que llam an al m ódulo en cuestión
de datos, no tiene una cohesión funcional fuerte (no hay seña
(concentración)
les de datos que contribuyan a todas las salidas). U n procedi
m iento sin m uestras de unión, es decir, sin m uestras com unes Usando estas m edidas, se define un indicador de aco
a m ás de una porción de datos (en procedim ientos con m ás de plam iento de módulo, mc, de la siguiente manera:
una porción de datos),no m uestra una cohesión funcionaldébil
y ninguna adhesividad (no hay señales de datos que contribu m , = k IM
y a n a m ás de una salida). donde k = l es una constante de proporcionalidad'.
L a c o h e s ió n f u n c io n a l f u e r t e y la p e g a jo s id a d se M = d¡ + a x c ¡ + da + b x c a + g d + c x g c + w + r
o b t i e n e n c u a n d o la s m é t r i c a s d e B i e m a n y O t t t o m a n
u n v a lo r m á x im o d e 1. donde a = b = c = 2.
S e d e j a u n e s t u d i o m á s d e t a l l a d o d e la s m é t r i c a s d e C uanto m ayor es el valor de m c, m enor es el aco
B i e m a n y O t t p a r a q u e s e a n r e v is a d a s s u s f u e n t e s [ B I E 9 4 ] . plam iento de módulo. Por ejem plo, si un módulo tiene
S in e m b a r g o , p a r a ilu s t r a r e l c a r á c te r d e e s ta s m é tr ic a s , un solo parám etro de entrada y salida de datos, no acce
c o n s id e r e la m é t r ic a p a r a la c o h e s ió n f u n c i o n a l fu e r te : de a datos globales y es llamado por un solo módulo:
C FF(i) = SU ( SA (ij) / m uestra(i) (19.6) inc = l / ( 1 + 0 + 1 + 0 + - 0 + 0 + 1 + 0 ) = 1 / 3 = 0,33.
d o n d e SU (S A(tj) d e n o t a m u e s t r a d e s u p e r u n i ó n ( e l c o n Deberíamos esperar que un módulo como éste presentara
j u n t o d e s e ñ a le s d e d a t o s q u e s e e n c u e n t r a n e n t o d a s la s un acoplamiento bajo. De ahí que, un valor de mc = 0,33
www.FreeLibros.org
8 El autor [DHA95] advierte que los valores de k y a, b y c (tratados
en la siguiente ecuación)pueden ajustarse a m edida que se van ven-
ficando experim entalm ente.
334
CAPÍTULO 19 MÉ TR IC A S T É C N I C A S DEL S OFT WA RE
implica un acoplamientobajo. Por el contrario, si un m ódu m ó d u lo . C u a n d o la c o m p le jid a d c ic lo m á t ic a d e lo s m ó d u

lo tiene 5 parám etros de salida y 5 parám etros de entrada lo s e x c e d ía n e s e v a lo r , r e s u lta b a e x tr e m a d a m e n te d i f í c il
d e datos, un núm ero igual de parám etros de control, acce- p r o b a r a d e c u a d a m e n te e l m ó d u lo . V e a e n e l C a p ítu lo 1 7
efe a 10 elem entos de datos globales y tiene una concen u n e s tu d io s o b r e la c o m p le jid a d c ic lo m á t ic a c o m o g u ía
tración de 3 y u na expansión de 4, p a r a e l d is e ñ o d e c a s o s d e p r u e b a d e c a ja b la n c a .
mc = 1 /(5 + 2 x 5 + 5 + 2 x 5 + 1 0 + 0 + 3 + 4 ) = 0 ,0 2
el acoplam iento im plicado es grande. 19.4.3. Métricas de diseño de interfaz
Para que aum ente la m étrica de acop lam ientoa m edi A u n q u e e x is te u n a s ig n if ic a t iv a c a n t id a d d e lit e r a t u r a
d a que aum enta el grado de acoplam iento, se puede defi s o b r e e l d is e ñ o d e in te r f a c e s h o m b r e - m á q u in a ( v e a e l
n i r una m étrica de acoplam iento rev isad a com o: C a p í t u l o 1 5 ), s e h a p u b li c a d o r e l a t iv a m e n t e p o c a i n f o r
m a c ió n s o b r e m é t r ic a s q u e p r o p o r c io n e n u n a v is ió n in t e r
n a d e la c a lid a d y f a c ilid a d d e e m p le o d e la in te r fa z .
dende el grado de acoplam ientono aum enta linealm ente
S e a rs [ S E A 9 3 ] s u g ie r e la c o n v e n ie n c ia d e la r e p r e
entre un valor m ínim o en el rango de 0,66 hasta un m áxi
s e n ta c ió n ( C R ) c o m o u n a v a lio s a m é t r ic a d e d is e ñ o p a r a
mo que se aproxim a a 1,O.
in te r f a c e s h o m b r e - m á q u in a . U n a I G U ( I n t e r f a z G r á f i
M étricas de com plejidad. Se p u ed en calcular una
c a d e U s u a r io ) t í p ic a u s a e n tid a d e s d e r e p r e s e n ta c ió n
variedad de m étricas del so ftw are p ara d e te rm in a r la
— ic o n o s g r á f ic o s , t e x t o , m e n ú s , v e n t a n a s y o t r a s — p a r a
complejidad del flujo de control del program a. M uchas
a y u d a r a l u s u a r io a c o m p le t a r ta re a s . P a r a r e a liz a r u n a
de éstas se b asan en u n a re p re se n ta ció n d en o m in ad a
ta r e a d a d a u s a n d o u n a I G U , e l u s u a r io d e b e m o v e r s e d e
g r a f o de flujo. Tal y co m o se d ijo en el C apítulo 17, un
u n a e n t id a d d e r e p r e s e n ta c ió n a o tr a . L a s p o s ic io n e s
g r a f o es u n a rep resen tació n com puesta de n o d o s y en la
a b s o lu t a s y r e la t iv a s d e c a d a e n t id a d d e r e p r e s e n t a c ió n ,
ces (tam bién denom inados aristas). C uando se dirigen
la fr e c u e n c ia c o n q u e s e u t ili z a n y e l « c o s te » d e la t r a n
lo s enlaces (aristas), el grafo de flujo es un grafo diri
s ic ió n d e u n a e n t id a d d e r e p r e s e n t a c ió n a la s ig u ie n te
gido.
c o n t r ib u ir á n a la c o n v e n ie n c ia d e la in te r fa z .
M cCabe [M CC94] identifica un núm ero im portante
de usos p ara las m étricas de com plejidad:
Las m étricas de com plejidad pueden em p learse para pre
decir la info rm ació n c rítica sobre la fiab ilid ad y m an te n i lajbetera — «I Ajuste de todos ¡as partes
miento de sistem as softw are de análisis autom áticos de código q » k its que no se pueda añadir, quitar o cambiar
fuente (o i nform ación de diseño procedim ental). L as m étri akjon? impacto en ¡a armonía del conjunto— .
cas de c o m p le jid a d ta m b ié n re a lim e n ta n la in fo rm a c ió n tekáSMtfH!404 -1472).
durante el pro y ecto de softw are para ay u d ar a c o n tro lar la
[actividad del diseño]. D u ra n te las p ru e b a s y el m a n te n i
P a r a u n a r e p r e s e n ta c ió n e s p e c íf ic a ( p o r e je m p lo , u n
m iento, p ro p o rcio n an una d etallad a info rm ació n sobre los
d is e ñ o d e u n a I G U e s p e c í f ic a ) , s e p u e d e n a s ig n a r c o s
m ódulos softw are para ayudar a resaltar las áreas de inesta
bilidad potencial. te s a c a d a s e c u e n c ia d e a c c io n e s d e a c u e r d o c o n la
s ig u ie n te r e la c ió n :
La m étrica de com plejidad m ás am pliam ente usada
(y debatida) para el softw are es la com plejidad ciclom á C o s te s = X [ fr e c u e n c ia d e t r a n s ic ió n (k) x
tica, originalm ente d esarrollada p o r T hom as M cC abe x c o s te d e tr a n s ic ió n ( k ) ] (1 9 .7 )
[MCC76] y estu d ian d o co n detalle en la Sección 17.4.2. d o n d e k e s la t r a n s ic ió n e s p e c íf ic a d e u n a e n t id a d d e
La m étrica de M cC abe proporciona u n a m edida c u an r e p r e s e n ta c ió n a la s ig u ie n te c u a n d o s e r e a liz a u n a ta r e a
titativa para probar la dificultad y una indicación de la fia e s p e c í f i c a . E s t a s u m a s e d a c o n t o d a s la s t r a n s i c i o n e s
bilidad última. Estudios experim entalesindican una fuerte d e u n a ta r e a e n p a r t ic u la r o c o n ju n t o d e ta re a s r e q u e r i
correlación entre la m étrica de M cC abe y el núm ero de d a s p a r a c o n s e g u ir a lg u n a f u n c ió n d e la a p lic a c ió n . E l
errores que existen en el código fuente, así com o el tiem c o s te p u e d e e s ta r c a r a c te r iz a d o e n té r m in o s d e tie m p o ,
po requerido p ara encontrar y correg ir dichos errores. r e tr a s o d e l p r o c e s o o c u a lq u ie r o t r o v a lo r r a z o n a b le , ta l
c o m o la d is ta n c ia q u e d e b e m o v e r s e e l r a t ó n e n tr e e n t i
d a d e s d e la r e p r e s e n ta c ió n .
L a c o n v e n ie n c ia d e la r e p r e s e n ta c ió n s e d e fin e c o m o :
la complejidodciclomática essolamenteuna más C R = 100 x [( c o s te d e la r e p r e s e n ta c ió n O p tim a C R ) /
de bs machos métricas de complejidad.
/ (c o s te d e la r e p r e s e n ta c ió n p r o p u e s ta ) ] (1 9 .8 )
M c C a b e t a m b ié n d e fie n d e q u e la c o m p le jid a d c ic l o d o n d e C R = 1 0 0 p a r a u n a r e p r e s e n t a c ió n Ó p tim a .

m á t ic a p u e d e e m p l e a r s e p a r a p r o p o r c i o n a r u n a i n d i c a c i ó n P a r a c a lc u la r la r e p r e s e n ta c ió n ó p t im a d e u n a I G U ,
c u a n tita tiv a d e l t a m a ñ o m á x i m o d e l m ó d u lo . R e c o g ie n la s u p e r fic ie d e la in t e r f a z ( e l á re a d e la p a n t a lla ) s e d i v i
www.FreeLibros.org
d o d a to s d e v a r io s p r o y e c t o s d e p r o g r a m a c ió n r e a le s , h a d e e n u n a c u a d r í c u la . C a d a c u a d r o d e la c u a d n c u la r e p r e
a v e r ig u a d o q u e u n a c o m p l e j i d a d c i c l o m á t i c a d e 1 0 p a r e - s e n ta u n a p o s ib le p o s ic ió n d e u n a e n t id a d d e la
ce s e r e l lí m it e p r á c t ic o s u p e r io r p a r a e l ta m a ñ o d e u n r e p r e s e n ta c ió n . P a r a u n a c u a d r í c u la c o n N p o s ib le s p o s i
335
IN GE NI ER ÍA DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
ciones y K diferentes entidades de representación para La CR se em plea para valorar diferentes distribu
colocar, el número posible de distribuciones se repre ciones propuestas de IGU y la sensibilidadde una repre
senta de la siguiente manera [SEA93]: sentación en particular a los cambios en las descripciones
número posible de distribuciones = de tareas (por ejemplo, cambios en la secuencia y/o fre
= [ N ! / ( K k ( N - K ) ] ] x K ! (19.9) cuencia de transiciones). El diseñador de interfacespue-
de emplear el cambio en la conveniencia de la
A medida que crece el número de posiciones de repre representación, A C R , com o guía en la elección de la
sentación, el número de distribuciones posibles se hace mejor representación de IGU para una aplicación en
muy grande. Para encontrar la representación óptima particular.
(menor coste). Sears [SEA93] propone un algoritmo de Es importante apuntar que la selección de un diseño
búsqueda en árbol. de IGU puede guiarse con métricas tales como CR, pero
el árbitro final debería ser la respuesta del usuario basa
da en prototipos de IGU. Nielsen y Levy [NIE94] infor
la s métricas del diseno de interface son volidos, pero man que «existe una gran posibilidad de éxito si se elige
sobre todo, son absolutamentenecesarhs para aseguro/ una interfaz basándose solamente en la opinión del usua
que a los usuarios finales les agrado la intefoce y estén rio. El rendimiento medio de tareas de usuario y su satis
satisfechos con los interacciones requeridas. facción con la IGU están altamente relacionadas.»
La teoría de Halsteadde la ciencia del software [HAL77] H a ls t e a d u s a la s m e d id a s p r i m i t i v a s p a r a d e s a r r o

es «probablemente la mejor conocida y m ás minucio l l a r e x p r e s i o n e s p a r a l a lo n g itu d g l o b a l d e l p r o g r a m a ;
samente estudiada... medidas compuestas de la com volum en m ín im o p o te n c ia l p a r a u n a l g o r i t m o ; e l volu
plejidad (software)» [C U R S O ]. La ciencia del software m en rea l ( n ú m e r o d e b i t s r e q u e r i d o s p a r a e s p e c i f i c a r
propone las primeras «leyes» analíticas para el softwa u n p r o g r a m a ) ; el n iv e l d e l p r o g r a m a ( u n a m e d i d a d e
re de computadora'. l a c o m p l e j i d a d d e l s o f t w a r e ) ; n iv e l del lenguaje ( u n a
c o n s ta n te p a r a u n le n g u a je d a d o ) ; y o t r a s c a r a c te r ís ti
c a s ta le s c o m o e s f u e r z o d e d e s a r r o llo , t ie m p o d e d e s a
Q f i t a :
r r o l lo e in c lu s o e l n ú m e r o e s p e r a d o d e f a llo s e n e l
0 cerebro humano sigue un conjunto rígido s o ftw a re .
ele reglas que conoce [en el desarrollo H a l s t e a d e x p o n e q u e l a l o n g i t u d N s e p u e d e e s t im a r
de algoritmos],
com o:
M m rke Haisfeod
N = n¡ log2 n¡ + n2 l° g 2 n2 (19.10)
La ciencia del software asigna leyes cuantitativas al
desarrollo del software de computadora, usando un con y e l v o lu m e n d e p r o g r a m a se p u e d e d e f in ir c o m o :
junto de medidas primitivas que pueden obtenerse una vez
que se ha generado o estimado el código después de com V = N log2 (n¡ + n2) (19.11)
pletar el diseño. Estas medidas se listan a continuación.
S e d e b e r í a t e n e r e n c u e n t a q u e V v a r i a r á c o n e l le n
n,: el núm ero de operadores diferentes que aparecen en el g u a j e d e p r o g r a m a c i ó n y r e p r e s e n t a e l v o l u m e n d e in f o r
program a
m a c ió n ( e n b it s ) n e c e s a r io s p a r a e s p e c if ic a r un
n2'. el núm ero de operandos diferentes que aparecen en el
p ro g ra m a .
program a
T e ó r ic a m e n t e , d e b e e x is t ir u n v o lu m e n m í n im o p a ra
N ,: el núm ero total de veces que aparece el operador u n a l g o r i t m o . H a l s t e a d d e f i n e u n a r e l a c i ó n d e v o lu m e n
N 2: el núm ero total de veces que aparece el operando
L c o m o la r e la c ió n d e v o lu m e n d e la fo r m a m á s c o m
p a c t a d e u n p r o g r a m a c o n r e s p e c t o a l v o l u m e n r e a l del
p r o g r a m a . P o r t a n t o , L d e b e s e r s i e m p r e m e n o r d e uno.
E n t é r m i n o s d e m e d i d a s p r i m i t i v a s , l a r e l a c i ó n d e v o lu
los operadores incluyen todos las construcciones del flujo de m e n se p u e d e e x p re s a r c o m o
control, condlchnes y operaciones matemáticas, los operandos
agrupan todos las variables y constantesdelprogramo. L = 2/rtj x n2/N 2 (19.12)
9 Se debería resaltar que las «leyes» de Halstead han generado una

sustancial controversia y que no todo el m undo está de acuerdo con
www.FreeLibros.org
que la teoría subyacente sea correcta. Sin em bargo, se han realizado
verificaciones experim entales de las averiguaciones de Halstead para
varios lenguajes de program ación (porejem plo, [FEL89]).
336
CAPÍTULO 19 MÉ TRI CA S T É C N I C A S DEL S O F T W A R E
El trabajo de H alstead se presta a la verificación expe pero puede decirse que se ha llegado a un bu en a c u e r
rim ental y de hech o se ha desarrollado u n a gran labor do entre lo previsto analíticam entey los resultados ex p e
de in v estigación en la ciencia del softw are. U n estudio rim e n ta le s. P ara m ás in fo rm a c ió n , v e a [Z U S 9 0 ],
de este trabajo estaría fu era del alcance de este libro, [FEN91] y [ZUS97],
Aunque se ha escrito m ucho sobre las m étricas del soft de diseño de casos de prueba presentado en el C apítu
ware para p ruebas (por ejem plo, [H E T 93]), la m ayoría lo 17. A dem ás, la com plejidad ciclom ática puede u sa r
de las m étricas p ropuestas se co ncentran en el proceso se para elegir m ódulos com o candidatos para pruebas
de prueba, no en las características técnicas de las pru e m ás p ro fu n d as (C a p ítu lo 18). L os m ó d u lo s c o n gran
bas m ism as. E n general, los responsables de las p ru e com plejidad ciclom áticatienen m ás probabilidad de ten
bas d eben fiarse de las m é tric a s de a n álisis, d iseño y dencia a errores que los m ódulos con m en o r co m pleji
código p ara que les guíen en el d iseñ o y ejecución de dad ciclom ática.
los casos de prueba. Por esta razón, el analista debería invertir un esfuerzo
extra para descubrir errores en el m ódulo antes de in te
grarlo en un sistema. E s esfuerzo de las pruebas tam bién
se puede estim ar usando m étricas obtenidas de m edidas
CLAVE de Halstead (Sección 19.5). U sando la definición del volu
los métricos de lo prueba desembocan en las siguientes m en de un program a, V, y nivel de program a, N P , el
categorias:(l) métricas que ayudan o determinar esfuerzo de la ciencia del softw are, e, puede calcularse
el número de pruebas requeridosen los distintos niveles
como:
dé la prueba; (2)métr¡cas poro cubrirla pruebo
de un componente dado. N P = 1 / [(nj/2) X ( N 2/n2)\ (19.13a)
Las m étricas b asadas en la función (S ección 19.3.1) e = V/NP (19.13b)

pueden em plearse p ara p red ecir el esfu erzo global de El porcentaje del esfu erzo global de pruebas a asig
las pruebas. Se p u e d e n ju n ta r y c o rre la c io n a r v arias n ar a un m ódulo k se puede estim ar usando la siguien
características a nivel de p royecto (por ejem plo, esfuer te relación:
zo y tiem po p a ra las p ru e b a s, e rro re s d e sc u b ie rto s,
p orcentaje de esfuerzo de pruebas (k ) =
número de casos de pru eb a p roducidos) de proyectos
e(Á-)/Xe(z) (19.14)
anteriores con el núm ero de PF producidos p o r un eq u i
po del proyecto. El equipo puede después p redecir los d o n d e e (k ) se c a lc u la p a ra el m ó d u lo k u s a n d o las
valores «esperados» de estas característicasdel proyecto e c u a c io n es (19.13) y la su m a en el d e n o m in a d o r de
actual. la ecu ació n (19.14) es la sum a del esfu erzo de la c ie n
La m étrica bang puede prop o rcio n ar u n a indicación cia del so ftw a re a lo la rg o de to d o s los m ó d u lo s del
del núm ero de casos de pru eb a n ecesarios p ara exam i sistem a.
nar las m edidas prim itivas tratadas en la sección 19.3.2. A m edida que se van haciendo las pruebas, tres m edi
El núm ero de prim itivas funcionales (PFu), elem entos das diferentes proporcionan una indicación de la com -
de datos (D E ), objetos (O B ), relaciones (R E ), estados pleción de las pruebas. U na m edida de la a m p litu d de
(ES) y transicio n es (T R ) p u ed en em plearse para pred e la s p r u e b a s p ro p o rc io n a una in d ic ac ió n de c u an to s
cir el núm ero y tip o s de p ru e b a del so ftw are de caja requisitos (del núm ero total de ellos) se han probado.
negra y de caja blanca. P or ejem plo, el núm ero de pru e E sto proporciona una indicación de la com pleción del
bas asociadas con la interfaz h o m bre-m áquina se p u e p lan de pruebas. La profundidad de las pruebas es una
de estim ar exam inando: (1) el núm ero de transiciones m edida del porcentaje de los cam inos básicos in depen
(TR) contenidas en la rep resen tació n estado-transición d ien tes probados en relación al núm ero total de estos
del IH M y evaluando las p ruebas requeridas para e je cam inos en el program a. Se puede calcular una estim a
cutar cada transición, (2) el núm ero de objetos de datos ción razonablem ente exacta del núm ero de cam inos bási
(OB) que se m ueven a través de la interfaz y (3) el núm e cos sum ando la com plejidad ciclom ática de to d o s los
ro de elem entos de datos que se introducen o salen. m ó d u lo s del p rogram a. F in alm en te, a m e d id a que se
Las m étricas del diseño arquitectónico p roporcionan v an haciendo las pruebas y se recogen los datos de los
información sobre la facilidad o d ificultad asociada con errores, se pueden em plear los perfiles de fa llo s para dar
la prueba de integración (C apítulo 18) y la necesidad prioridad y categorizar los errores descubiertos. La prio
de software especializado de prueba (por ejem plo, m atri ridad indica la severidad del problem a. L as categorías
www.FreeLibros.org
ces y controladores). L a com plejidad ciclom ática (una de los fallos proporcionan una descripción de un error,
métrica de diseño de com ponentes) se encuentra en el de m anera que se puedan llevar a cabo análisis estadís
núcleo de las p ruebas de cam inos básicos, un m étodo ticos de errores.
337
INGE NIERÍA DEL SOF TW ARE . UN EN F O Q U E P R Á C T I C O
Todas las métricas del softwarepresentadas en este capí F a _ núm ero de m ódulos en la versión actual que se han aña
tulo pueden usarse para el desarrollo de nuevo softwa dido
Fd = núm ero de m ó d u lo s d e la versión anterior que se han
re y para el m antenim iento del existente. Sin embargo,
borrado en la versión actual
se han propuesto métricas diseñadas explícitam entepara
El índice de m adurez del software se calcula de l a
actividades de m antenim iento.
siguiente manera:
El estándar E E E 982.1-1988 [EEE94] sugiere un índi
IM S = [ M T - ( F á + F c + Fd) ] I M T (19.15)
ce de madurez del software (IMS) que proporciona una
indicación de la estabilidad de un producto software (basa A m edida que el IMS se aproxima a 1 ,O el producto
da en los cambios que ocurren con cada versión del pro se em pieza a estabilizar. EL IMS puede emplearse tam
ducto). Se determina la siguiente información: bién com o m étrica para la planificación de las activi
dades de m antenim iento del software. El tiem po medio
M t - núm ero de m ódulos en la versión actual para producir una versión de un producto software pue
F c _ núm ero de m ódulos en la versión actual que se han de correlacionarse con el IMS desarrollándose mode
cam biado los empíricos para el mantenimiento.
RESV.- . i
Las m étricas del softw are proporcionan una m anera de diseño de alto nivel consideran los aspectos arqui
cuantitativa de valorar la calidad de los atributos inter tectónicos y estructurales del m odelo de diseño. Las
nos del producto, perm itiendo por tanto al ingeniero m étricas de diseño de nivel de com ponentes propor
valorar la calidad antes de construir el producto. Las cionan una indicación de la calidad del módulo esta
métricas proporcionan la visión interna necesaria para bleciendo m edidas indirectas de la cohesión,
crear modelos efectivos de análisis y diseño, un código acoplamiento y complejidad. Las métricas de diseño de
sólido y pruebas minuciosas. interfaz proporcionan una indicación de la convenien
Para que sea útil en el contexto del m undo real, una cia de la representación de una IGU.
m étrica del software debe ser simple y calculable, per La ciencia del software proporciona un intrigante
suasiva, consistente y objetiva. D ebería ser indepen conjunto de métricas a nivel de código fuente. Usando
diente del lenguaje de program ación y proporcionar el núm ero de operadores y operandos presentes en el
una realim entación eficaz para el desarrollador de soft código, la ciencia del software proporciona una varie
ware. dad de métricas que pueden usarse para valorar la cali
Las métricas del m odelo de análisis se concentran dad del programa.
en la función, los datos y el comportamiento (los tres Se han propuesto pocas m étricas técnicas para un
componentes del m odelo de análisis). El punto de fun empleo directo en las pruebas y mantenim iento del soft
ción y la m étrica bang proporcionan m edidas cuantita ware. Sin em bargo, se pueden em plear m uchas otras
tivas para evaluar el m odelo de análisis. Las métricas métricas técnicas para guiar el proceso de las pruebas
del diseño consideran aspectos de alto nivel, del nivel y com o m ecanismo para valorar la facilidad de mante
de componentes y de diseño de interfaz. Las métricas nim iento de un program a de computadora.
[BAS84] Basili, y V.R D.M. Weiss, «A Methodology for [CAV78] Cavano, J.R, y J.A. McCall, «AFrameworkforthe
CollectingValid Software EngmeeringData»,/£,£ ,£' Trans. Measurement of Software Quality», Proc.ACM Software
Software Engineering, vol. SE-10, 1984,pp. 728-738. Quality Assurance Wokshop, Noviembre 1978,pp. 133
139. '
[BIE94] Bieman, J.M .,y L.M. Ott, «Measuring Functional
Cohesión», IEEE Trans. Software Engineering, vol. 20, [CHA89] Charette, R.N., Software Engineering Risk Analy
n.e 8, Agosto 1994,pp. 308-320. sis and Management,McGraw-Hill/Intertext, 1989.
[BRI96] Briand, L.C., S. Morasca, y V.R. Basili, «Properly-Based [CURSO] Curtís, W., «Management and Experimentation in
Software Engineering Measurement», IEEE Trans. Softwa Software Engineering», Proc. IEEE, vol. 68, n.Q9, Sep
www.FreeLibros.org
re Engineering, vol 22, n.‘J 1,Enero 1996,pp. 68-85. tiembre 1980.
[CAR90] Card, D., y N. R. L. Glass, Measuring Software [DAV93] Davis, A., et al.,«Identifying and Measuring Qua
Design Quality, Prentice-Hall, 1990. lity in a Software Requirements Specification», Proc. l st
338
CAPÍTULO 19 M É T R I C A S T É C N I C A S DEL S OF TW AR E
Intl. Softw are M e tric s Sym posium , IE E E , B altim o re, M D , [IE E 9 4 ] S o ftw a r e E n g in e e r in g S ta n d a r d s , 1994, IE E E , 1994.
M a y 1993, pp. 141-152. [K Y B 8 4 ] K y b u rg ,H .E ., T h e o r y a n d M e a s u re m e n t, Cam bridge
[D E M 8 1 ] D e M illo , R .A . , y R.J. L ip to n , « S o ftw are Project U n iversity Press, 1984.
Forecasting», S o f t w a r e M e t r i c s (Á.J. Perlis, F.G . Sayw ard
[M C C 7 6 ] M c C a b e , T.J., « A Softw are C o m p lexity M easure»,
y M . Shaw, ed.), M I T Press, 1 9 8 1 ,pp. 77-89.
IE E E Trans. Software Engineering, vol. 2, D iciem bre 1976,
[D E M 8 2] D eM a rc o , T., C o n t r o llin g S o ftw a re P r o je c ts , Your- pp. 3 08-320.
don Press, 1982.
[M C C 7 7 ] M c C a ll, J., P. R ichards, y G. W alters, «Factors in
[D H A 95] D ham a, H ., «Q uantitative M o d e ls o f Cohesión and Softw are Q uality », 3 vols., N T IS A D -A 0 4 9 -0 1 4 ,0 1 5 ,0 5 5 ,
Coupling in Softw are», J o u r n a l o f S y s t e m s a n d S o f t w a r e , N o vie m b re 1977.
vol. 2 9, n.° 4, A b ril 1995. '
[M C C 8 9 ] M c C a b e , T .J .,y C .W .B u tle r, «D esign C om plexity
[EJI91] E jio g u ,L ., S o f t w a r e E n g in e e r in g w ith F o r m a l M e t r ic s , M easu rem en t and Testin g », C A C M , vol. 3 2 , n.° 12,
Q E D Publishing, 1991. D ic iem b re 1 9 8 9 ,pp. 1415-1425.
[F E L 89] F e lic an , L ., y G . Z a la te u , « V a lid a tin g Halstead's [M C C 9 4 ] M c C a b e , T.J., y A .H . W atson, «S o ftw are C o m p le
Theory fo r Pascal Programs», IE E E Trans. Softw are E n g i xity», Crosstalk, vol. 7, n.° 1 2 ,D iciem bre 1 99 4,pp. 5-9.
neering, vol. 1 5 ,n.° 2, D ic iem b re 1 9 8 9 ,pp. 1630-1632.
[N IE 9 4 ] N ielsen, J., y J. L evy, «M easuring U sability: P refe-
[F E N 91] Fenton, N ., S o ftw are M e tric s , C hapm an & H a ll, rence vs. Perform ance», C A C M , vol. 37,n.° 4, A b ril 1994,
1991. pp. 76-85.
[FEN 94] Fenton, N ., «So ftw are M easurem ent: A Necessary [R O C 9 4 ] R oche, J .M ., «S o ftw are M e tric s and M easurem ent
S cie n tific B a sis »,/£ ,£ ,£ ' T r a n s . S o f t w a r e E n g i n e e r i n g , vol. Principies», S o f t w a r e E n g i n e e r i n g N o t e s , A C M , vol. 19,
2 0 , n.° 3, M a rz o 1994, pp. 199-206. n.° 1 ,E nero 1 9 9 4 ,pp. 76-8 5 .
[GRA87] Grady, R. B ., y D .L . Caswell, S o f t w a r e M e t r i c s : E s t a - [S E A 93] Sears,A., «LayoutA ppropriaten ess:A M etricforE va-
b l i s h i n g a C o m p a n y - W i d e P r o g r a m , Prentice-H all, 1987. luating U ser Interface W idg et L a y o u t» ,/£ ,£ '£' T r a n s . S o f t
w a r e E n g i n e e r i n g , vol. 19,n.° 7, ju lio 1 99 3,pp. 7 07-719.
[H A 77] H alstead, M ., E le m e n t s o f S o f t w a r e S c ie n c e , N A rth
H olland, 1977. [U S A 8 7 ] M a n a g e m e n t Q u a l i t y I n s i g h t , A FC S P 8 0 0 -1 4 (U.S.
A ir Force), 2o Enero, 1987.
[H EN 81] H enry, S., y D . K a fu ra ,« Softw are S tm ctureM etrics
Based on in fo rm a tio n F lo w » , I E E E T r a n s . S o f t w a r e E n g i [Z U S 90] Zuse, H ., S o f t w a r e C o m p l e x it y : M e a s u re s a n d M e th o d s ,
n e e r i n g , vol. S E -7, n .° 5 , Septiem bre 1 9 8 1 ,pp. 5 10 -5 18 . DeGruyter, N ueva York, 1990.
[H E T 9 3] H etze l, B ., M a k i n g S o ftw a r e M e a s u re m e n t. W o rk , [Z U S 9 7 ] Zuse, H , , A F r a m e w o r k o f S o ftw a re M e a s u re m e n t,
Q E D Publishing, 1993. D eG ruyter, N u ev a Y o rk, 1997.
19.1. L a teoría de la m edición es un tem a avanzado que tie 19.3.2., desarrollecuentasprim itivaspara la m étrica bang. ¿El
ne una gran influencia en las m étricas del software. M e d ia n sistema SSR B es de dom inio de fu nción o de datos?
te [F E N 9 1], [Z U S 9 0 ] y [K Y B 8 4 ] u otras fuentes, escriba una 19.6. C alcule el v alo r de la m étrica bang usando las m edidas
pequeña redacción que recoja los principales principios de la que desarrolló en el P roblem a 19.5.
teoría de la m ed ición. Proyecto in d ivid u a l: Prepare una con
ferencia sobre el tem a y expóngala en clase. 19.7. Cree un m odelo de diseño com pleto para un sistema
propuesto por s u profesor. C alcule la com plejidad estructural
19.2. Los factores de calidad de M c C a ll se desarrollaron y de datos usando las m étricas descritas en la Sección 19.4.1.
durante los años setenta. Casi todos los aspectos de la in fo r C alcule tam bién las m étricas de H e n ry -K a fu ra y de m o rfo lo
mática han cam biado dram áticam ente desde que se desarro gía para el m odelo de diseño.
llaron, y sin embargo, los factores de M c C a ll todavía se aplican
enel software moderno. ¿Puede sacar alguna conclusiónbasa- 19.8. U n sistema de inform ación grande tiene 1.140 m ódu
da en este hecho? los. H ay 96 m ódulos que realizan funciones de control y coor
dinación, y 4 9 0 cuya fu nción depende de un proceso anterior.
19.3. Por qué no se puede desarrollar una única m étrica que E l sistemaprocesa aproxim adam ente220 objetos de datos con
lo abarque todo para la com plejidad o calidad de un progra una m edia de tres atributos por objeto de datos. H ay 140 e le
ma? m entos de la base de datos Unicos y 9 0 segmentos de base de
19.4. R evise el m odelo de análisis que desarrolló com o p ar datos diferentes. 6 0 0 m ódulos tienen un solo punto de entra
te del P roblem a 12.13. M e d ian te las directrices de la Sección da y de salida. C alcule el IC D E del sistema.
19.3.1., desarrolle una estim ación del núm ero de puntos fu n
19.9. Investigueel trabajo de B iem an y Ott [B IE 9 4 ] y desarro
www.FreeLibros.org
ción asociados con SSRB.
lle un ejem plo completo que ilustre el cálculo de su m étrica de
19.5. R evise el m odelo de análisis que desarrolló com o p ar cohesión. Asegúrese de indicar cóm o se determ inan las porcio
te del Problem a 12.13. M e d ian te las directrices de la Sección nes de datos, señales de datos y señales de unión y superuníón.
339
19.10. Seleccione cinco módulos existentes de un progra 19.13. Desarrolle una pequeña herramienta de software que
ma de computadora. Mediante la métrica de Dhama descrita realice un análisis Halstead de un código fuente de un lenguaje
en la Sección 19.4.2., calcule el valor de acoplamiento de de programación a su elección.
cada módulo. 19.14. Haga una investigacióny escriba un documento sobre
la relación entre las métricas de la calidad del software de Hals-
19.11. Desarrolle una herramienta de software que calcule teady la de McCabe (conrespecto a la cuenta de errores). ¿Son
la complejidad ciclomática de un módulo de lenguaje de pro convincentes los datos? Recomiende unas directrices para la
gramación. Elija el lenguaje. aplicación de estas métricas.
19.12. Desarrolle una herramienta de software que calcule 19.15. Investigue documentos recientes en busca de métri
la conveniencia de la representación de una IGU. Esa herra cas específicamente diseñadas para el diseño de casos de prue
mienta debería permitirle asignar el coste de transición entre ba. Exponga los resultados en clase.
las entidades de la representación. (Nota: fíjese en que el tama 19.16. Un sistema heredado tiene 940 módulos. La última
ño potencial del número de las alternativas de representación versión requiere el cambio de 90 de estos módulos. Además,
crece mucho a medida que aumenta el número de posibles se añaden 40 módulos nuevos y se quitaron 12 módulos anti
posiciones de cuadrícula.) guos. Calcule el índice de madurez del software del sistema.
jQTRAS LECIUBAS.XrUENIES PE INFORMACION.

Sorprendentemente hay un gran número de libros dedicados La teoría de la medición del software la presentan Den-
a las métricas del software, aunque la mayoría están enfoca vir, H erm an, y W hitty en una colección de documentos
dos a métricas de proceso y proyecto excluyendo las métri (Proceedings o f the International BCS-FACS Workshop:
cas técnicas. Zuse [ZUS97] ha escrito el más completo tratado Formal A spects o f Measurement, Springer-Verlag, 1992).
de métricas técnicas publicado hasta la fecha. Shepperd (Fo undations o f Software Measurement, Prenti
Los libros de Card y Glass [CAR90J, Zuse [ZUS90], Fen- ce Hall, 1996) también tratan la teoría de la medición en
ton [FEN91], Ejiogu [EJ191], Moeller y Paulish (Métricas del detalle.
Software,Chapman& Hall, 1993)y Hetzel [HET93] sonrefe- Una relación de docenas de usos de las métricas del soft
rencias sobre las métricas técnicas en detalle. Además, mere ware están presentadas en [IEE94], En general, una discu
ce la pena examinar los siguientes libros: sión de cada m étrica ha sido reducida a lo esencial «las
Conte, S.D., H.E. Dunsmore, y V.Y. Shen,Software EngmeeringMetrics primitivas» (medidas) requeridas para calcular las métricas
andModels, Benjamin/Cummings, 1984. y las adecuadas relaciones a efectos de los cálculos. Un apén
Fenton,N.E.,y S.L. Pfleeger,SoftwareMetrics:ARigorous andPrac- dice del libro suministra más información y referencias sobre
tical Approach, 2.a ed.,PWS Publishing Co., 1998. el tema.
Grady, R.B. Practical Software Metiicsfor Project Mangement and Pro- Una amplia variedad de fuentes de información sobre
cess hnprovement,Prentice Hall, 1992. métricas técnicas y elementos relacionados están disponi
Perlis, A., et al., Software Metrics: A n Analysis and Evalua- bles en Intemet. Una lista actualizada de referencias de pági
tion, MIT Press, 1981. nas web sobre m étricas técnicas la puedes encontrar en
Sheppard, M , Software Engineering Metrics, McGraw-Hill, 1992. h ttp ://w w w .p re s s m a n 5 .c o m .
PARTE
IV
INGENIERÍA
DEL SOFTWARE
ORIENTADA A OBJETOS
N esta parte de ingeniería del software: un enfoque práctico considera
E mos los conceptos técnicos, métodos y medidas aplicables al análisis,

diseño y pruebas de software orientado a objetos. En los siguientes capí
tulos responderemos las siguientes preguntas:
• ¿Cuáles son los conceptos y principios básicos aplicables al pensamiento

orientado a objetos?
• ¿En qué se diferencian el enfoque tradicional y el orientado a objetos?
• ¿Cómo deben gestionarse y planificarse los proyectos orientados objetos? „
• ¿Qué es el análisis orientado a objetos y cómo permiten sus distintos mode-r
los comprender las clases, sus relaciones y comportamiento al in$|pi§ib
del software?
• ¿Cuá.es son los elementos de un modelo de diseño orientado a objetos?
• ¿Cuáles son los conceptos y principios básicos aplicables a las pruebas de
software orientado a objetos?
• ¿Cómo cambian las estrategias de prueba y los métodos de diseño de casos
de prueba cuando se considera el software orientado a objetos?
• ¿Qué métricas técnicas están disponibles para evaluar la calidad del soft
ware orientado a objetos?
Una vez contestadas estas preguntas, comprenderá cómo analizar, diseñar,

implementar y probar el software usando el paradigma de orientación a objetos.
www.FreeLibros.org
C A P ÍT U L O
CONCEPTOS Y PRINCIPIOS
ORIENTADOS A OBJETOS
V
I V I M O S e n u n m u n d o d e o b je t o s . E s to s o b je t o s e x is t e n e n la n a tu r a le z a , e n e n t id a d e s
h e c h a s p o r e l h o m b r e , e n lo s n e g o c io s y e n lo s p r o d u c t o s q u e u s a m o s . P u e d e n s e r c la
s if ic a d o s , d e s c r ito s , o r g a n iz a d o s , c o m b in a d o s , m a n ip u la d o s y c r e a d o s . P o r e s to n o e s
s o r p r e n d e n te q u e s e p r o p o n g a u n a v is ió n o r ie n t a d a a o b je t o s p a r a la c r e a c ió n d e s o ftw a r e
c o m p u ta d o r a , u n a a b s tr a c c ió n q u e m o d e la e l m u n d o d e f o r m a t a l q u e n o s a y u d a a e n te n d e r lo
g o b e r n a r lo m e jo r .
L a p r im e r a v e z q u e s e p r o p u s o u n e n fo q u e o r ie n t a d o a o b je t o s p a r a e l d e s a r r o llo d e s o f t w a
r e f u e a f i n a l e s d e l o s a ñ o s s e s e n t a . S i n e m b a r g o , la s t e c n o l o g í a s d e o b j e t o s h a n n e c e s i t a d o c a s i
v e in t e a ñ o s p a r a lle g a r a s e r a m p lia m e n t e u s a d a s . D u r a n t e lo s a ñ o s 9 0 , la in g e n ie r í a d e l s o f t
w a r e o r ie n t a d a a o b je t o s s e c o n v ir t ió e n e l p a r a d ig m a d e e le c c ió n p a r a m u c h o s p r o d u c to r e s d e
s o f t w a r e y p a r a u n c r e c ie n t e n ú m e r o d e s is t e m a s d e in f o r m a c ió n y p r o f e s io n a le s d e la in g e n ie
r í a . A m e d i d a q u e p a s a e l t i e m p o , la s t e c n o l o g í a s d e o b j e t o s e s t á n s u s t i t u y e n d o a l o s e n f o q u e s
c lá s ic o s d e d e s a r r o llo d e s o ftw a r e . U n a p r e g u n t a im p o r t a n t e e s : ¿ P o r q u é ?
L a r e s p u e s ta ( c o m o m u c h a s o tr a s r e s p u e s ta s a in te r r o g a n te s s o b r e in g e n ie r í a d e l s o ftw a r e )
n o e s s e n c illa . A lg u n a s p e r s o n a s a r g u m e n ta r ía n q u e lo s p r o fe s io n a le s d e l s o ftw a r e s e n c illa
m e n te a ñ o r a b a n u n n u e v o e n fo q u e , p e r o e s ta v is ió n e s m u y s im p lis ta . L a s te c n o lo g ía s d e o b je
t o ll e v a n u n n ú m e r o d e b e n e f ic io s in h e r e n t e s q u e p r o p o r c io n a n v e n t a ja s a lo s n iv e le s d e d ir e c c ió n
y té c n ic o .
VI STAZO RÁPI DO
¿ Q u é « s ? Use/ m uchas form as d e enfocar E sta im p o rta n te c a ra c te rís tic a p e rm i d e l p ro b le m a , el d ise ñ o p roporciona
un pro b lem a utilizan d o u n a solución te c o n stru ir c la s e s d e o b je to s e in h e d e ta lle s sobre la arquitectura, lasin ter-
b a sa d a e n e l softw are.U n enfoque muy r e n te m e n te c o n s tru ir b ib lio te c a s d e fa c e s y los c o m p o n e n te s, la im ple-
utilizado e s la visión o rientada a obje objetos y c la s e s reu tilizab les. El p a r a m e n ta c ió n (u tiliz a n d o u n le n g u a je
tos. El dom iniodel problem a secaracte- d ig m a d e o rie n ta c ió n a ob jeto s e s ta n orientado a objetosjtransform a el dise
riza m ediante un conjunto d e objetos con a tra c tiv o p a r a ta n ta s o rg a n iz a c io n e s ñ o e n código, y la s p ru e b a s ch eq u e an
atributosy com portam ientos específicos. d e d e s a rro llo d e so ftw a re d e b id o a ta n to la arq u itectu ra como la s in terfa
Los objetos son m an ip u lad o s m ediante q u e l a re u tiliz a c ió n e s u n a trib u to c es y los com ponentes.
u n a colección d e fu n cio n es (lla m a d a s im p o rta n tís im o e n la in g en ie ría . d e l ¿Cuól e s e l p ro d u cto o b ten id o ? S e
m étodos, o peracio n es o servicios) y se so ftw a re. A d e m á s , lo s c o m p o n e n te s produce un conjunto d e m odelos o rien
com unican entre ellos m ediante u n pro d e so ftw a re d e riv a d o s m e d ia n te el ta d o s a objetos. E stos m odelos de sc ri
tocolo d e m ensajes. Los objetos se c la si p a ra d ig m a d e objetos m u estran c a ra c b e n los req u isito s, el diseñ o , e l código
fican m ediante c la se s y subclases. te rística s (com ola in d ep en d en cia fun y los p ro ceso s d e p ru e b a s p a ra un sis
¿ Q u ié n lo h a c e ? Ia d e fin ic ió n d e objetos c io n a l, la o c u lta c ió n d e in form ación, te m a o producto.
implica 1a descripción de atributos, com etc,) a s o c ia d a s con e l so ftw a re d e a lta
¿Cómo p u e d o e s ta r se g u r o d e que
portam ientos, operaciones y m ensajes. calid ad .
lo h e h e c h o c o r r e c ta m e n te ? E n
E sta a c tiv id a d la re a liz a un ingeniero ¿C uáles son lo s p aso s? L a in g e n ie ría c a d a e ta p a se revisa la c la rid a d d e l os
del software. d el softw are o rie n ta d o a objeto s sig u e productos d e tra b a jo orien tad o s a obje
¿Por q u é e s im p o r ta n te? Un objeto los m ism os p a so s q u e el en fo q u e con to s, su co rrecció n , co m p leció n y c o n
e n c a p s u la ta n to d a to s com o lo s p ro vencional. El a n á lisis identifica ¡a s c la siste n c ia con los re q u is ito s d e l c lie n te
c e so s q u e s e a p li c a n a e s o s d a to s. s e s y objeto s re le v a n te s e n el dom inio y e n tre ellos.
L a s te c n o lo g ía s d e o b je t o s lle v a n a r e u t iliz a r , y la r e u t iliz a c ió n ( d e c o m p o n e n te d e s o f t w a

r e ) lle v a a u n d e s a r r o llo d e s o f t w a r e m á s r á p id o y a p r o g r a m a s d e m e jo r c a lid a d . E l s o f t w a r e
o r ie n t a d o a o b je t o s e s m á s f á c il d e m a n t e n e r d e b id o a q u e s u e s t r u c t u r a e s in h e r e n t e m e n t e p o c o
a c o p la d a . E s t o l l e v a a m e n o r e s e f e c t o s c o la t e r a le s c u a n d o s e d e b e n h a c e r c a m b io s y p r o v o c a
m e n o s f r u s t r a c ió n e n e l in g e n ie r o d e l s o f t w a r e y e n e l c lie n t e . A d e m á s , lo s s is t e m a s o r ie n t a d o s
a o b je t o s s o n m á s f á c ile s d e a d a p t a r y m á s f á c il m e n t e e s c a la b le s ( p o r e je m p lo : p u e d e n c r e a r s e
www.FreeLibros.org
g r a n d e s s is t e m a s e n s a m b la n d o s u b s is t e m a s r e u t iliz a b le s ) .
E n e s te c a p í t u lo p r e s e n ta m o s lo s p r in c ip io s y c o n c e p to s b á s ic o s q u e f o r m a n e l f u n d a m e n to
p a r a la c o m p r e n s ió n d e te c n o lo g í a s d e o b je t o s .
343
INGE NIE RÍA DEL SOFTWARE. UN EN F O Q U E P R Á C T I C O
D u ran te m u ch o s años el térm in o o rien tad o a o bjetos

( 0 0 ) s e usó p ara referirse a un enfoque de desarrollo
de softw are que u sab a uno de los lenguajes orientados CLAVE
a objetos (A da 95, C ++, E iffel, S m alltalk, etc.). H oy en los sistemas0 0 utilizan un modelo de ingeniería
día el p aradigm a O O encierra una com pleta v isión de mediante proceso evolutivo. Más adelante, en este
la in g en iería del softw are. E dw ard B erard hace notar mismo capítulo, nos referiremos a él como el modelo
esto cuando declara [BER93]: recursivo paralelo.
L os beneficios de la tecnología orientada a objetos se for

talecen si se usa antes y durante el proceso de ingeniería del E n el C apítulo 2, exam inam os un núm ero de mode
softw are.E sta tecnología orientada a objetos considerada debe los de procesos diferentes para la ingeniería del softwa
hacer sentir su im pacto en todo el proceso de ingeniería del
re. A unque ninguno de estos m odelos pudo ser adaptado
softw are. U n sim ple uso de program ación orientada a objetos
(P O O ) no brindará los m ejores resultados. L os ingenieros del
para su uso con 0 0 , la m ejo r selección reconoceríaque
softw are y sus directores deben considerar tales elem entos el los sistem as 0 0 tienden a evolucionar con el tiempo.
análisis de requisitos orientado a objetos (A R O O ), el diseño P or esto, un m odelo evolutivo de proceso acoplado con
orientado a objetos (DO O). el análisis del dom inio orientado un enfoque que fom enta el ensam blaje (reutilización)de
a objetos (A D O O ),sistem as de gestión de bases de dalos orien com ponentes es el m ejo r paradigm a para ingeniería del
tadas a objetos (SG B D O O ) y la ingeniena del softw are o rien
softw are OO. En la F igura 20.1 el m odelo de proceso de
tada a objetos asistida por com putadora (ISO OAC).
ensam blaje de com ponentes (C apítulo 2 ) ha sido adap
tado a la ingeniería del softw are OO.
Ge*na:
Conjos objetos es realmente mós fácil construir
modelos [paro sistemas complejos] que dedicarse o
lo programación secuenciol
D avid Tayier Una de las listos más completas de recursos 00
en la web puede consultarse en
El lector fam iliarizado con el enfoque convencional x mini.net/cetus/software.html.
de ingeniería del softw are (p resentada en la tercera p ar
te de este libro) puede reaccio n ar ante e sta declaración El proceso O O se m ueve a través de una espiral evo
con esta pregunta: «¿Cuál es la gran ventaja? U sam os lutiva que com ienza con la com unicación con el u s u a
el análisis, diseño, la p rogram ación, las p ruebas y otras rio. E s aquí donde se define el dom inio del problema y
tecnologías relacionadas cuando real izam os ingeniería se identifican las clases básicas del problem a (tratadas
del software según m étodos clásicos. ¿Por qué debe ser m ás tarde en este capítulo). L a planificación y el análi
la OO diferente?» C iertam ente,¿por qué debe ser la OO sis de riesgos establecen una base para el plan del pro
diferente?E n pocas palabras, ¡no debiera! yecto O O . El trabajo técnico asociado con la ingeniería
del softw are O O sigue el cam ino iterativo m ostrado en
la caja som breada. La ingeniería del softw are 0 0 hace
hincapié en la reutilización. P or lo tanto, las clases se
Id e n tific a r
c la s e s
c a n d id a ta s
Comunicación C o n s tru ir B uscar

con el cliente n -é s lm a c la s e s
ite ra c ió n en
d e l s is te m a b ib lio te c a
A ñ a d ir las E x tra e r
nuevas nuevas
c la s e s a la c la s e s si
b ib lio te c a e x is te n
D e s a rro lla r
1— la s c la se s
si n o e x is te n
A n á lis is 0 0
D is e ñ o 0 0
www.FreeLibros.org
P ro g ra m a c ió n 0 0
P ru e b a s 0 0
FIG U R A 2 0 .1 . El m od elo de p ro ceso OO. FIG U R A 2 0 .2 . Herencia de c la se a o b je to .
344
CA P I T U L O 20 C O N C E P T O S Y P R IN C IP IO S O R IE N T A D O S A O B JE T O S
b u s c a n e n u n a b i b l i o t e c a ( d e c la s e s 0 0 e x i s t e n t e s ) a n t e s L a v is ió n o r ie n t a d a a o b je t o s d e m a n d a u n e n fo q u e
d e c o n s t r u ir s e . C u a n d o u n a c la s e n o p u e d e e n c o n tr a r s e e v o lu t iv o d e la in g e n ie r í a d e l s o ftw a r e . C o m o v e r e m o s
e n la b ib lio t e c a , e l d e s a r r o lla d o r d e s o f t w a r e a p lic a a n á a tr a v é s d e e s te y lo s p r ó x im o s c a p ít u lo s , s e rá e x t r e m a
lis is o r i e n t a d o a o b j e t o s ( A O O ) , d i s e ñ o o r i e n t a d o a o b j e d a m e n t e d i f í c i l d e f i n i r la s c la s e s n e c e s a r i a s p a r a u n g r a n
to s ( D O O ) , p r o g r a m a c ió n o r ie n t a d a a o b je t o s ( P O O ) y s is t e m a o p r o d u c t o e n u n a s o la it e r a c c ió n . A m e d id a q u e
p ru e b a s o r ie n t a d a s a o b je t o s ( P R O O ) p a r a c r e a r la c la e l a n á lis is 0 0 y lo s m o d e lo s d e d is e ñ o e v o lu c io n a n , s e
s e y l o s o b j e t o s d e r i v a d o s d e l a c la s e . L a n u e v a c l a s e s e h a c e p a t e n t e l a n e c e s i d a d d e c la s e s a d i c i o n a l e s . E s p o r
p o n e e n la b ib lio t e c a d e t a l m a n e r a q u e p u e d a s e r r e u - e s ta r a z ó n p o r lo q u e e l p a r a d ig m a a r r ib a d e s c r ito f u n
t iliz a d a e n e l f u t u r o . c io n a m e jo r p a r a la O O .
C u a lq u ie r d is c u s ió n s o b r e in g e n ie r í a d e l s o f t w a r e
o r ie n ta d a a o b je t o s d e b e c o m e n z a r p o r e l t é r m in o
orientado a objetos. ¿ Q u é e s u n p u n t o d e v i s t a o r i e n
ta d o a o b je t o s ? ¿ Q u é h a c e q u e u n m é t o d o s e a c o n s i
d e ra d o c o m o o r ie n t a d o a o b je t o s ? ¿ Q u é e s u n o b je t o ?
D u ra n te a ñ o s h a n e x is tid o m u c h a s o p in io n e s d if e r e n
te s ( p . e j . : [ B E R 9 3 ] , [ T A Y 9 0 ] , [ S T R 8 8 ] , [ B 0 0 8 6 ] )
s o b r e la s r e s p u e s t a s c o r r e c t a s a e s t a s p r e g u n t a s . E n l o s
p á r r a fo s s ig u ie n t e s t r a t a r e m o s d e s in t e t iz a r la s m á s
c o m u n e s d e é s ta s .
La programación orientada a objetos no es tanto

una técnica de codificación de paquetes como
una manera de que los constructores de software
encopsulen funcionalidades para proporcionárselas
a sus clientes.
Brad Cox
F IG U R A 2 0 . 3 . Herencia operaciones de clase a objeto.
»
P a ra e n te n d e r la v is ió n o r ie n t a d a a o b je t o s , c o n s id e
r e m o s u n e j e m p l o d e u n o b j e t o d e l m u n d o r e a l — la c o s a H e m o s in t e n t a d o d e f i n i r u n a c la s e d e s c r i b i e n d o s u s a t r i
s o b re la q u e u s te d e s tá s e n ta d o a h o r a m is m o — , u n a s illa . b u to s , p e r o a lg o f a lt a . T o d o o b je t o e n la c la s e m o b i lia r i o
S illa e s u n m i e m b r o ( e l t é r m i n o in sta n cia t a m b i é n s e p u e d e m a n ip u la r s e d e v a r ia s m a n e r a s . P u e d e c o m p r a r s e
u s a ) d e u n a c la s e m u c h o m á s g r a n d e d e o b je t o s q u e l l a - y v e n d e r s e , m o d ific a r s e f í s ic a m e n te ( p o r e je m p lo , u s te d
m a n e m o s M o b ilia r io . U n c o n ju n t o d e a t r ib u t o s g e n é r i p u e d e e lim in a r u n a p a ta o p in t a r e l o b je t o d e p ú r p u r a ) o
cos p u e d e a s o c i a r s e c o n c a d a o b j e t o , e n l a c l a s e m o v e r s e d e u n l u g a r a o t r o . C a d a u n a d e e s t a s operacio
M o b ilia r io . P o r e j e m p l o , t o d o m u e b l e t i e n e un c o s t o , nes ( o t r o s t é r m i n o s s o n servicios o m étodos) m o d i f i c a r á
d im e n s io n e s , p e s o , lo c a liz a c ió n y c o lo r , e n tr e o t r o s u n o o m á s a t r ib u to s d e l o b je t o . P o r e je m p lo , s i e l a t r ib u t o
m u c h o s p o s ib le s a t r ib u to s . E s to s s o n a p lic a b le s a c u a l lo c a liz a c ió n e s u n d a t o c o m p u e s t o d e f i n i d o c o m o :
q u ie r e l e m e n t o s o b r e e l q u e s e h a b l e , u n a m e s a o s i l l a ,
localización = edificio + piso + habitación
u n s o f á o u n a r m a r i o . C o m o S illa e s u n m i e m b r o d e l a
c la s e M o b i l i a r i o , h e r e d a t o d o s l o s a t r i b u t o s d e f i n i d o s e n t o n c e s u n a o p e r a c i ó n d e n o m i n a d a m over m o d i f i c a r í a
p a r a d i c h a c la s e . E s t e c o n c e p t o s e i l u s t r a e n l a F i g u r a u n o o m á s d e l o s e l e m e n t o s d a t o (e d ific io , p is o o h a b i
2 0 .2 u t iliz a n d o u n a n o t a c ió n c o n o c id a c o m o U M L . E n t a c i ó n ) q u e c o n f o r m a n e l a t r i b u t o lo c a liz a c ió n . P a r a
d ic h a f ig u r a , la c a ja c o n u n a e s q u in a d o b la d a r e p r e s e n h a c e r e s t o , m over d e b e t e n e r « c o n o c i m i e n t o » s o b r e e s t o s
ta un c o m e n t a r i o e n u n l e n g u a j e d e p r o g r a m a c i ó n . e l e m e n t o s . L a o p e r a c i ó n m o ver p u e d e u s a r s e p a r a u n a
U n a v e z d e f in id a la c la s e , lo s a t r ib u t o s p u e d e n r e u - s illa o u n a m e s a , d e b id o a q u e a m b a s s o n in s ta n c ia s d e
t i l i z a r s e a l c r e a r n u e v a s i n s t a n c i a s d e l a c la s e . P o r e j e m l a c l a s e M o b i l i a r i o . T o d a s la s o p e r a c i o n e s v á l i d a s ( p o r
p lo , s u p o n g a m o s q u e d e b e m o s d e f i n i r u n n u e v o o b je t o e j e m p l o , com prar, vender, p e s a r ) d e l a c l a s e M o b i l i a
www.FreeLibros.org
l l a m a d o S ille s a ( u n c r u c e e n t r e u n a s i l l a y u n a m e s a ) r io e s tá n « c o n e c ta d a s » a la d e f in ic i ó n d e l o b je t o c o m o
q u e e s u n m i e m b r o d e l a c l a s e M o b i l i a r i o . L a S ille s a se m u e s tr a e n la F ig u r a 2 0 .3 y s o n h e re d a d a s p o r to d a s
h e re d a t o d o s lo s a t r ib u t o s d e M o b ilia r io . la s i n s t a n c i a s d e e s t a c la s e .
345
g a m m u m m L a s a b s t r a c c io n e s d e d a t o s ( a t r i b u t o s ) q u e d e s c r i
Se puede utilizor lo notación de modelado de datos b e n la c la s e e s tá n e n c e r r a d a s p o r u n a « m u r a lla » de
del Capitulo 12. a b s t r a c c io n e s p r o c e d im e n t a le s ( lla m a d a s o p e r a c io
n e s , m é t o d o s o s e r v i c i o s ) c a p a c e s d e m a n i p u l a r lo s
d a to s d e a lg u n a m a n e r a . L a Ú n ic a f o r m a d e a lc a n z a r
l o s a t r i b u t o s ( y o p e r a r s o b r e e l l o s ) e s i r a t r a v é s de
E l o b j e t o silla ( y t o d o s l o s o b j e t o s e n g e n e r a l ) a l g u n o d e lo s m é t o d o s q u e f o r m a n la m u r a lla . P o r lo
e n c a p s u la d a to s ( lo s v a lo r e s d e lo s a t r ib u t o s q u e d e f i t a n t o , la c la s e e n c a p s u la d a t o s ( d e n t r o d e la m u r a lla )
n e n la s i l l a ) , o p e r a c io n e s ( la s a c c io n e s q u e s e a p lic a n y e l p r o c e s o q u e m a n ip u la lo s d a to s ( lo s m é to d o s qu e
p a r a c a m b ia r lo s a t r ib u t o s d e la s illa ) , o t r o s o b je t o s c o m p o n e n la m u r a lla ) . E s t o p o s i b i l i t a la o c u lta c ió n
( p u e d e n d e f in ir s e o b je t o s c o m p u e s to s [ E V B 8 9 ] ) , c o n s d e i n f o r m a c i ó n y r e d u c e e l i m p a c t o d e e f e c t o s c o la
ta n te s ( p a r a f i j a r v a lo r e s ) y o t r a in f o r m a c ió n r e l a c io t e r a le s a s o c ia d o s a c a m b io s . C o m o e s to s m é to d o s
n a d a . E l e n c a p s u la m ie n to s ig n if ic a q u e to d a e s ta t ie n d e n a m a n i p u l a r u n n ú m e r o l i m i t a d o d e a t r ib u to s ,
in f o r m a c ió n s e e n c u e n t r a e m p a q u e ta d a b a jo u n n o m e s to e s u n a a lt a c o h e s ió n , y c o m o la c o m u n ic a c ió n
b r e y p u e d e r e u t iliz a r s e c o m o u n a e s p e c if ic a c ió n o o c u r r e s ó l o a t r a v é s d e l o s m é t o d o s q u e e n c i e r r a la
c o m p o n e n te d e p ro g ra m a . « m u r a lla » , la c la s e t ie n d e a u n d e s a c o p la m ie n t o c o n
o t r o s e le m e n t o s d e l s is t e m a . T o d a s e s ta s c a r a c te r ís
tic a s d e l d is e ñ o ( C a p í t u lo 1 3 ) c o n d u c e n a s o ftw a re
d e a lta c a lid a d .
la e&fipsukión evita que un progromo seo tan

«tedepemtenfe que el más mínimo cambio
provoque efectos devastadores.
A h o r a q u e h e m o s in t r o d u c id o a lg u n o s c o n c e p to s
b á s ic o s , r e s u lta r á m á s s ig n if ic a t iv a u n a d e f in ic ió n m á s
f o r m a l d e la « o r ie n t a c ió n a o b je t o s » . C o a d y Y o u r d o n
[ C O A 9 1 ] d e f in e n e l t é r m in o d e la s ig u ie n te f o r m a :
o r ie n t a c ió n a o b je t o s =
= o b je t o s + c la s if ic a c ió n + h e r e n c ia + c o m u n ic a c ió n
F IG U R A 20.4. Representación alternativa de una clase
Y a h e m o s in t r o d u c id o tr e s d e e s to s c o n c e p to s . P o s orientada a objetos.
p o n d r e m o s e l t r a ta m ie n to s o b re la c o m u n ic a c ió n p a r a
m á s a d e la n t e .
P u e s t o d e o t r a m a n e r a , u n a c la s e e s u n a d e s c r ip c ió n
g e n e r a liz a d a ( p o r e je m p lo , u n a p l a n t ill a , u n p a tr ó n o
20.2.1. C l a s e s y o b je to s u n p r o t o t i p o ) q u e d e s c r i b e u n a c o l e c c i ó n d e o b je t o s
L o s c o n c e p to s fu n d a m e n ta le s q u e lle v a n a u n d is e ñ o d e s i m i l a r e s . P o r d e f i n i c i ó n , t o d o s l o s o b j e t o s q u e e x is t e n
a l t a c a l i d a d ( C a p í t u l o 13) s o n i g u a l m e n t e a p l i c a b l e s a d e n t r o d e u n a c l a s e h e r e d a n s u s a t r i b u t o s y la s o p e r a
s is t e m a s d e s a r r o lla d o s u s a n d o m é t o d o s c o n v e n c io n a le s c i o n e s d i s p o n i b l e s p a r a l a m a n i p u l a c i ó n d e l o s a t r ib u
y o r ie n t a d o s a o b je t o s . P o r e s ta r a z ó n , u n m o d e lo 0 0 t o s . U n a s u p e r e la s e e s u n a c o l e c c i ó n d e c la s e s y u n a
d e s o f t w a r e d e c o m p u t a d o r a d e b e e x h i b ir a b s tr a c c io n e s s u b c l a s e e s u n a i n s t a n c i a d e u n a c la s e .
d e d a to s y p r o c e d im ie n to s q u e c o n d u c e n a u n a m o d u
la r id a d e f ic a z . U n a c la s e e s u n c o n c e p t o 0 0 q u e e n c a p
s u l a la s a b s t r a c c i o n e s d e d a t o s y p r o c e d i m i e n t o s q u e s e
r e q u ie r e n p a r a d e s c r ib ir e l c o n t e n id o y c o m p o r t a m ie n
t o d e a lg u n a e n t id a d d e l m u n d o r e a l. T a y lo r [ T A Y 9 0 ] Una de los primeros cosas o tener en cuento o la hora
u s a la n o ta c ió n q u e se m u e s tr a a la d e r e c h a d e la F ig u de construir un sistema 0 0 es cómo dosificar los objetos
r a 2 0 . 4 p a r a d e s c r ib i r u n a c la s e ( y o b je t o s d e r iv a d o s d e o manipular en dicho sistema.
u n a c la s e ) .
E s ta s d e f in ic io n e s im p li c a n la e x is t e n c ia d e u n a je r a r -
q u í a d e c la s e s e n l a c u a l l o s a t r i b u t o s y o p e r a c i o n e s d e
CLAVE l a s u p e r c l a s e s o n h e r e d a d o s p o r s u b c la s e s q u e p u e d e n
www.FreeLibros.org
Un objeto encapsula dotas (atributos) y los métodos a ñ a d ir , c a d a u n a d e e lla s , a t r ib u t o s « p r iv a d o s » y m é to
(operaciones, métodos o servicios) que manipulan d o s . U n a j e r a r q u í a d e c la s e s p a r a l a c l a s e M obiliario se
esos datos. ilu s t r a e n la F ig u r a 2 0 .5 .
346
CAPÍTULO 20 C O N C E P T O S Y P R IN C IP IO S O R IE N T A D O S A O B JE T O S
20.2.2. A tributos d estacad o antes, tien e el v alor p o r d efecto 16 válvulas

Ya hem os visto que los atributos están asociados a cla opción deportiva. E sto p u ed e ser ta m b ié n Util p a ra
ses y o b jeto s, y que d escrib en la c la se o el o b jeto de aso ciar una probabilidad con una c a ra cterística p a rti
alguna m anera. U n estu d io de los atributos es p resen c u lar a través de pares {valor, p ro b a b ilid a d ). C o n sid e
tado por de C h a m p e a u x y sus colegas [CH A 93]: re el atributo color para Coche. E n algunas aplicaciones
(por ejem plo, planificación de la producción) puede ser
L as entidades de la vida real están a m enudo descritas con
palabras que indican característicasestables. La m ayoría de los
n ece sario asignar una p ro b a b ilid ad a cad a u n o de los
objetos físicos tienen características tales com o form a, peso, co lo res (blanco y n eg ro son m ás probables co m o c o lo
color y tip o de m aterial. L as personas tienen características res de coches).
com o fecha de nacim iento, padres, nom bre y color de los ojos.
Una característicapuede verse com o una relaciónbinaria entre
una clase y cierto dom inio. 20.2.3. O p eracion es, m étodos y servicios
U n o b je to e n c a p su la d ato s (rep resen tad o s c o m o una
Mobiliario (superclase) colección de atributos) y los algoritm os que procesan
estos datos. E stos algoritm os son llam ados operaciones,
m étodos o servicios' y pueden ser vistos co m o m ó d u
los en un sentido convencional.
CLAVE
Sferrpe que un objeto es estimulado por un mensaje,
inicia algún co m p atern ie rtoejeo te ndo uno operación.
Subclases de la C ada una de las o p eracio n es e n cap su lad as p o r un

superclase mobiliario
o b jeto p ro p o rc io n a una rep resen tació n de uno de los
Instancias de silla
c o m p o rta m ie n to s del ob jeto . P o r e je m p lo , la o p e ra
FIGURA 2 0.5. Una jerarquía de clases. ció n D e te r m in a r e o lo r para el o b jeto Coche extraerá
el c o lo r a lm a c e n ad o en el a trib u to color. L a c o n s e
La «relación» binaria anteriorm ente señalada im p li c u e n c ia de la e x iste n c ia de e sta o p e ra c ió n es que la
ca que un atributo puede to m ar un v alo r definido p o r un clase Coche ha sido diseñ ad a para re c ib ir un e stím u
dom inio en u m erad o . E n la m a y o ría de los caso s, un lo [JA C 9 2 ] (lla m a re m o s al e s tím u lo m e n sa je ) que
dom inio es sim plem ente u n conjunto de v alores esp e requiere el color de una instancia p articular de una cla
cíficos. Por ejem plo, suponga que u n a clase Coche tie se. C ada vez que un objeto recibe un estím ulo, éste in i
ne un atributo color. El dom inio de v alores de color es cia un cierto com portam iento, que puede ser tan sim ple
(blanco, negro, plata, gris, azul, rojo, am arillo,ver c o m o d e te rm in a r e l c o lo r del c o c h e o tan c o m p le jo
de). En situaciones m ás co m p lejas, el d o m in io puede co m o la in icia ció n de una cad en a de estím u lo s que se
ser un conjunto de clases. C ontinuando el ejem plo, la p asan entre una variedad de objetos diferentes. E n este
clase Coche tam b ién tiene un atributo motor que abar ú ltim o caso, con sid ere un eje m p lo en el cu al el e s tí
ca los sig u ien tes v a lo re s de d om inio: { 16 válvulas m ulo in icial rec ib id o p o r el ob jeto n .s 1 da lu g ar a una
opción económica, 16 válvulas opción deportiva, 24 g e n e ra c ió n d e o tro s d o s e stím u lo s q u e se e n v ía n al
válvulas opción deportiva, 32 válvulas opción de o b jeto n .2 2 y al ob jeto n .2 3. L as o p e racio n es en c a p
lu jo ).C a d a u n a de las opciones indicadas tiene un c o n su ladas p o r el se g u n d o y te rc e r o b jeto s actúan sobre
jun to de atributos específicos. el e stím u lo d ev o lv ien d o inform ación necesaria para el
p rim e r ob jeto . E l o b je to n .2 1 u sa e n to n c e s la in fo r
m a c ió n d e v u e lta p a ra sa tisfa c e r el c o m p o rta m ie n to
dem an d ad o p o r el estím u lo inicial.
CLAVE
los valores asignados a los a r tx to s d e un objeto hacen
a ese ser único.
20.2.4. M ensajes
Los m ensajes son el m edio a través del cual interactúan
los objetos. U sando la term inología presentada en la sec
Las c a ra c te rís tic a s (v a lo re s d el d o m in io ) p u e d en ción precedente, un m ensaje estim ula la ocurrencia de
aum entarse asig n an d o un v a lo r p o r d efecto (c ara cte cierto com portam iento en el objeto receptor. El com por
rística) a u n atributo. P o r e je m p lo , el atrib u to m otor tam iento se realiza cuando se ejecuta una operación.
www.FreeLibros.org
1 U sarem os aquí el térm ino operaciones, pero m étodos y servicios
son igualm ente populares.
347
I N GEN IE RÍ A DEL S O F TW A RE . UN EN F O Q U E P R Á C T I C O
E n la F ig u r a 2 0 .6 . s e il u s t r a e s q u e m á tic a m e n t e la E l p a s o d e m e n s a j e s m a n t i e n e c o m u n i c a d o u n s is te m a
in t e r a c c ió n e n tr e o b je t o s . U n a o p e r a c ió n d e n t r o d e u n o r ie n t a d o a o b je t o s . L o s m e n s a je s p r o p o r c io n a n una
o b je t o e m is o r g e n e r a u n m e n s a je d e la f o r m a : v is i ó n in t e r n a d e l c o m p o r t a m ie n t o d e o b je t o s in d iv i
d u a le s , y d e l s is t e m a 0 0 c o m o u n t o d o .
d e s tin o .o p e r a c ió n ( p a r á m e tr o s )
d o n d e d e s tin o d e f in e e l o b je to r e c e p t o r e l c u a l e s e s t i
m u la d o p o r e l m e n s a je , o p e r a c ió n s e r e f ie r e a l m é t o d o
q u e r e c ib e e l m e n s a je y p a r ú m e t r o s p r o p o r c io n a i n f o r
m a c ió n r e q u e r id a p a r a e l é x it o d e la o p e r a c ió n .
F IG U R A 2 0 .6 . Paso de mensaje entre objetos.

20.2.5. E n ca p su la m ien to ,h eren cia y polimorfismo
C o m o u n e j e m p lo d e p a s o d e m e n s a je s d e n t r o d e u n
Aunque la estructura y terminología introducida entre las
s is t e m a 0 0 , c o n s id e r e lo s o b je t o s q u e s e m u e s t r a n e n
Secciones 20.2.1 y 20.2.4 diferencian los sistemas 0 0 a
l a F i g u r a 20.7. L o s c u a t r o o b j e t o s . A , B , C y D s e c o m u
partir de sus componentes convencionales,hay tres carac
n i c a n u n o s c o n o t r o s a t r a v é s d e l p a s o d e m e n s a je s . P o r
terísticas de los sistemas orientados a objetos que los hacen
e je m p lo , s i e l o b je t o B r e q u ie r e e l p r o c e s o a s o c ia d o c o n
Únicos. Como ya hem os observado, las clases y los obje
la o p e r a c ió n o p lO d e l o b je t o D, e l p r im e r o e n v ia r í a a D
tos derivados de ella encapsulan los datos y las operacio
u n m e n s a je d e la f o r m a :
nes que trabajan sobre estos en un único paquete. Esto
D . o p lO ( d a t o s ) proporciona un número importante de beneficios:
jlS , ¿Cuáles son los beneficios

* principales de una arquitectura 0 0 ?
| ^ 9 Í R $ a ¡ r 'i y ¡os m étodos son dos coros
femismam oneda. Los m étodos son
|k < :¿ ^ K s á m « irto s invocados cuando un objeto • Los detalles de im plementación interna de datos y
procedimientos están ocultos al mundo exterior (ocul
tación de la información). Esto reduce la propaga
ción de efectos colaterales cuando ocurren cambios.
C o m o p a r t e d e la e j e c u c ió n d e o p lO , e l o b je t o D p u e • Las estructuras de datos y las operaciones que la s
d e e n v ia r u n m e n s a je a l o b je t o C d e la f o r m a : m anipulan están mezcladas en una entidad sencilla:
la clase. Esto facilita la reutilización de componentes.
C .o p 8 (d a to s )
• Las interfaces entre objetos encapsulados están sim
C e n c u e n tr a o p 8 , la e je c u ta , y e n to n c e s e n v ía u n v a lo r plificadas. Un objeto que envía un mensaje no tiene
d e r e t o m o a p r o p ia d o a D . L a o p e r a c ió n o p lO c o m p le t a que preocuparse de los detalles de las estructuras de
s u e je c u c ió n y e n v ía u n v a lo r d e r e t o m o a B . datos internas en el objeto receptor, l o que simpli
C o x [ C O X 8 6 ] d e s c r ib e e l in t e r c a m b io e n tr e o b je t o s fica la interacción y hace que el acoplamientodel sis
d e la s ig u ie n te m a n e r a : tem a tienda a reducirse.
Se solicita de un o b jeto que e je cu te u n a de sus o p e ra c io La herencia es una de las diferencias clave entre sis
n es e n v ián d o le un m e n sa je que le in fo rm a acerca de lo que
tem as convencionales y sistemas 0 0 . Una s u b c la s e Y
d eb e h a c e r. El [o b jeto ] re c e p to r re sp o n d e al m e n sa je e li
www.FreeLibros.org
g ien d o prim ero la o peración que im p lem en ta el n o m b re del hereda todos los atributos y operaciones asociadas con
m e n s a je , ejecu tan d o d ic h a o p eración y d esp u és devolvien su superclase X . Esto significa que todas las estructu
do el co n tro l al o b jeto q u e orig in a la lla m ad a . ras de datos y algoritm os originalm ente diseñados e
348
im p le m e n t a d o s p a r a X e s tá n in m e d ia t a m e n t e d i s p o n i n u e v a c la s e . C o m o s e ñ a la J a c o b s o n , c u a n d o s e e m p l e a l a
b le s p a r a Y ( n o e s n e c e s a r i o m á s t r a b a j o e x t r a ) . L a r e u a n u la c ió n , « la h e r e n c ia n o e s t r a n s it iv a » [ J A C 9 2 ] ,
tiliz a c ió n s e r e a liz a d ir e c ta m e n te . E n a lg u n o s c a s o s , e s te n ta d o r h e r e d a r a lg u n o s a t r ib u to s
C u a lq u ie r c a m b io e n lo s d a to s u o p e r a c io n e s c o n t e y o p e r a c io n e s d e u n a c la s e y o t r o s d e o t r a c la s e . E s t a a c c i ó n
n id a s d e n t r o d e u n a s u p e r c l a s e e s h e r e d a d o i n m e d i a t a s e ll a m a h e r e n c ia m ú lt ip le y e s c o n t r o v e r t id a . E n g e n e r a l,
m e n te p o r to d a s la s s u b c la s e s q u e s e d e r iv a n d e la l a h e r e n c i a m ú l t i p l e c o m p l i c a l a j e r a r q u í a d e c la s e s y c r e a
s u p e r c la s e 2. D e b i d o a e s t o , l a j e r a r q u í a d e c la s e s s e c o n p r o b le m a s p o te n c ia le s e n e l c o n t r o l d e la c o n f ig u r a c ió n
v ie r t e e n u n m e c a n i s m o a t r a v é s d e l c u a l l o s c a m b i o s ( C a p i t u l o 9 ) . C o m o la s s e c u e n c ia s d e h e r e n c i a m ú l t i p l e s o n
( a a lto s n i v e le s ) p u e d e n p r o p a g a r s e in m e d ia t a m e n t e a m á s d if í c ile s d e s e g u ir ,lo s c a m b io s e n la d e f in ic ió n d e u n a
t r a v é s d e t o d o e l s is t e m a . c la s e q u e r e s i d e e n l a p a r t e s u p e r i o r d e l a j e r a r q u í a p u e d e n
E s im p o r t a n t e d e s ta c a r q u e e n c a d a n iv e l d e la je r a r t e n e r im p a c t o s n o d e s e a d o s o r i g i n a l m e n t e e n la s c la s e s d e f i
q u í a d e c la s e s , p u e d e n a ñ a d i r s e n u e v o s a t r i b u t o s y o p e n id a s e n z o n a s in f e r io r e s d e la a r q u it e c t u r a .
r a c io n e s a a q u e l l o s q u e h a n s i d o h e r e d a d o s d e n i v e l e s
s u p e r io r e s d e l a j e r a r q u í a . D e h e c h o , c a d a v e z q u e s e
d e b e c r e a r u n a n u e v a c la s e , e l in g e n ie r o d e l s o f t w a r e
t ie n e v a r i a s o p c i o n e s :
• L a c la s e p u e d e d is e ñ a r s e y c o n s t r u ir s e d e la n a d a .
E s to e s , n o s e u s a la h e r e n c ia .
+ c h a r5 + c h a r6
• L a j e r a r q u í a d e c la s e s p u e d e s e r r a s t r e a d a p a r a d e t e r
m in a r s i u n a c la s e a s c e n d ie n t e c o n t ie n e la m a y o r í a
d e lo s a t r ib u t o s y o p e r a c io n e s r e q u e r id a s . L a n u e v a
c la s e h e r e d a d e s u c l a s e a s c e n d i e n t e , y p u e d e n a ñ a
d ir s e o t r o s e le m e n to s s i h a c e n fa lta .
+ c h a r7
• L a je r a r q u í a d e c la s e s p u e d e r e e s t r u c t u r a r s e d e t a l
+ c h a r f>
m a n e r a q u e lo s a t r ib u t o s y o p e r a c io n e s r e q u e r id o s
p u e d a n s e r h e r e d a d o s p o r l a n u e v a c la s e .
• L a s c a r a c t e r í s t ic a s d e u n a c la s e e x is t e n t e p u e d e n
4
s o b r e s c r ib i r s e y s e p u e d e n i m p l e m e n t a r v e r s i o n e s p r i
v a d a s d e a t r i b u t o s u o p e r a c i o n e s p a r a l a n u e v a c la s e . X3 X4
c h a r lo c h a r lo
char20 char20
char30 char30
char40 char40
Mientras que un objeto es una entidad que existe c h a r5 () c h a r5 0
¡n el tiempo y en el espacio, uno dase representa c h a r6 0 chár70
j$6|o uno abstracción, «la esencia» del objeto,
F IG U R A 2 0 .8 a . Jerarquía de clases original.
P a ra ilu s t r a r c ó m o la r e e s t r u c t u r a c ió n d e la je r a r q u í a
d e c la s e s p u e d e c o n d u c i r a l a c l a s e d e s e a d a , c o n s i d e r e e l i| | | M » e [polimorfismo] puede ser extraño, pero el
e j e m p lo m o s t r a d o e n l a F i g u r a 2 0 . 8 . L a j e r a r q u í a d e c l a mernnkmn es puro elegancia.
s e s il u s t r a d a s e n l a F i g u r a 2 0 . 8 a n o s p e r m i t e d e r i v a r la s tffHátoyh
c la s e s X3 y X 4 c o n la s c a r a c t e r í s t i c a s 1 , 2 , 3 , 4 , 5 y 6 , y
1, 2 , 3 , 4 , 5 y 7 , r e s p e c tiv a m e n te 3.A h o r a , s u p o n g a q u e
s e d e s e a c r e a r u n a n u e v a c l a s e s o l a m e n t e c o n la s c a r a c E l p o lim o r f is m o e s u n a c a r a c te r ís tic a q u e r e d u c e e n
te r ís tic a s 1 , 2 , 3 , 4 y 8. P a r a d e r iv a r e s ta c la s e , lla m a d a g r a n m e d i d a e l e s f u e r z o n e c e s a r i o p a r a e x t e n d e r u n s is
X2b e n e l e j e m p l o , l a j e r a r q u í a d e b e r e e s t r u c t u r a r s e c o m o te m a O O . P a r a e n te n d e r e l p o lim o r f is m o , c o n s id e r e u n a
se m u e s tr a e n la F ig u r a 2 0 .8 b . E s im p o r t a n t e d a r s e c u e n a p lic a c ió n c o n v e n c io n a l q u e d e b e d ib u ja r c u a tr o tip o s
ta d e q u e l a r e e s t r u c t u r a c i ó n d e l a j e r a r q u í a p u e d e s e r d i f í d i f e r e n t e s d e g r á f i c o s : g r á f i c o s d e l í n e a s , g r á f i c o s d e ta r
c il y , p o r e s ta r a z ó n , s e u s a a v e c e s la a n u la c ió n . ta , h is to g r a m a s y d ia g r a m a s d e K iv ia t . Id e a lm e n te , u n a
E n e s e n c ia , l a a n u l a c i ó n o c u r r e c u a n d o l o s a t r i b u t o s y v e z q u e s e h a n r e c o g id o lo s d a to s n e c e s a r io s p a r a u n t ip o
o p e r a c io n e s s e h e r e d a n d e m a n e r a n o r m a l , p e r o d e s p u é s p a r t ic u la r d e g r á fic o , e l g r á f ic o d e b e d ib u ja r s e é l m is m o .
s o n m o d i f i c a d o s s e g ú n la s n e c e s id a d e s e s p e c í f i c a s d e l a P a ra r e a liz a r e s to e n u n a a p lic a c ió n c o n v e n c io n a l ( y m a n -
www.FreeLibros.org
2 A veces se emplean los términos descendiente y antecesor [JAC92] 3 En este ejemplo llam arem os característica tanto a los atributos como
en lugar de subclase y superclase. a las operaciones.
349
te n e r la c o h e s ió n e n tr e m ó d u lo s ) , s e r ía n e c e s a r io d e s a
r r o l la r m ó d u lo s d e d ib u jo p a r a c a d a t ip o d e g r á fic o . S e g ú n
e s to , d e n tr o d e l d is e ñ o p a r a c a d a t ip o d e g r á fic o , s e d e b e
r á a ñ a d i r u n a l ó g i c a d e c o n t r o l s e m e ja n t e a l a s i g u i e n t e :
case of tipo-grafico:
if tip o -g ra fic o = g ra fic o _ lin e a th e n
D ib u ja r L in e a ( d a to s );
if tip o -g ra fic o = g ra fic o _ ta rta th en
if tip o -g ra fic o = g ra fic o _ h isto g ra m a charlO

char20
th e n D ib u ja rH is to (d a to s ) ; char30
if tip o -g ra fic o = g ra fic o _ k iv ia t th en
end case; X2
A u n q u e e s te d is e ñ o e s r a z o n a b le m e n te e v id e n t e , a ñ a c h a rlo
char20
d i r n u e v o s t ip o s d e g r á fic o s p u e d e s e r c o m p lic a d o , p u e s +char5 char30
h a y q u e c re a r u n n u e v o m ó d u lo d e d ib u jo p a r a c a d a tip o char4Q
d e g r á f ic o y a c tu a liz a r la ló g ic a d e c o n t r o l p a r a c a d a
+char8
g r á fic o .
X2a X2b
P a r a r e s o l v e r e s t e p r o b l e m a , c a d a u n o d e los gráfi-
e o s m e n c io n a d o s a n te r io r m e n te s e c o n v ie r t e e n u n a s u b charlO charlO
char20 char20
c la s e d e u n a c la s e g e n e r a l lla m a d a G r á f ic o . U s a n d o u n char30 char30
c o n c e p t o l l a m a d o s o b r e c a r g a [ T A Y 9 0 ] , c a d a s u b c la s e +ehar6 char40 char40
char50 charSO
d e f in e u n a o p e r a c ió n lla m a d a d ib u ja r . U n o b je t o p u e
d e e n v ia r u n m e n s a je d ib u ja r a c u a lq u ie r a d e lo s o b je x , _____ i +char7 ^
t o s i n s t a n c i a d o s d e c u a l q u i e r a d e la s s u b c la s e s . E l o b j e t o
X3 X4 .
q u e r e c ib e e l m e n s a je in v o c a r á s u p r o p ia o p e r a c ió n d ib u
j a r p a r a c r e a r e l g r á f ic o a p r o p ia d o . P o r e s to , e l d is e ñ o charlO charlO
char20 char20
m o s tr a d o a n te r io r m e n te se r e d u c e a : char30 char30
char40 char40
tipo-grafico dibujar char50 ehar50
charBO ehar70
C u a n d o h a y q u e a ñ a d ir u n n u e v o t ip o d e g r á f ic o a l
s is t e m a , s e c r e a u n a s u b c la s e c o n s u p r o p ia o p e r a c ió n FIGURA20.8b. Jerarquía de clasesreestmcturada.
L o s e le m e n to s d e u n m o d e lo d e o b je t o s - c l a s e s y o b je
t o s , a t r i b u t o s , o p e r a c i o n e s y m e n s a je s — f u e r o n d e f i n i d o s
y e x a m in a d o s e n l a s e c c ió n p r e c e d e n t e . P e r o , ¿ c ó m o p o d e
m o s h a c e r p a r a id e n t if ic a r e s to s e le m e n to s e n u n p r o b le
m a r e a l ? L a s s e c c io n e s q u e s i g u e n p r e s e n t a n u n a s e r i e d e
d ir e c tr ic e s in f o r m a le s q u e n o s a y u d a r á n e n la id e n t if ic a
c ió n d e lo s e le m e n t o s d e u n m o d e lo d e o b je t o s .
P o d e m o s e m p e z a r a i d e n t i f i c a r o b je t o s 4 e x a m in a n d o
2 0 .3 . 1 . I d e n t i f i c a c i ó n d e c l a s e s y o b j e t o s e l p la n t e a m ie n to d e l p r o b le m a o ( u s a n d o la t e r m in o lo
S i u s te d o b s e r v a a s u a lr e d e d o r e n u n a h a b it a c ió n , e x is g í a d e l C a p í t u lo 1 2 ) r e a liz a n d o u n « a n á lis is s in t á c t ic o
te n u n c o n ju n t o d e o b je t o s f í s ic o s q u e p u e d e n s e r f á c i l g r a m a t ic a l» e n la n a r r a t iv a d e l s is t e m a q u e s e v a a c o n s
m e n te id e n t ific a d o s ,c la s ific a d o s y d e f in id o s ( e n té r m in o s t r u ir . Los o b je t o s s e d e te r m in a n s u b r a y a n d o c a d a n o m
d e a t r ib u t o s y o p e r a c io n e s ) . P e r o c u a n d o u s te d « o b s e r v a » b r e o c l á u s u l a n o m i n a l e i n t r o d u c i é n d o l a e n u n a t a b la
e l e s p a c io d e u n p r o b le m a e n u n a a p lic a c ió n d e s o f t w a r e , s im p le . L o s s in ó n im o s d e b e n d e s ta c a r s e . S i s e r e q u ie
lo s o b je t o s p u e d e n s e r m á s d if í c ile s d e id e n t ific a r . r e d e l o b je t o q u e im p le m e n t e u n a s o lu c ió n , e n to n c e s
www.FreeLibros.org
4 E n r e a lid a d , e l A n á lis is OO in t e n t a id e n t if ic a r la s c la s e s a p a r t ir de
las cuales se instancian los objetos. Por tanto, cuando aislam os obje
tos potenciales, tam bién identificam os m iem bros de clases poten
ciales.
350
é s te f o r m a r á p a r t e d e l e s p a c io d e s o lu c ió n ; e n c a s o d e L a c la s ific a c ió n m o s tra d a a n te r io r m e n te e s u n a d e
q u e e l o b je t o s e n e c e s it e s o la m e n te p a r a d e s c r ib i r u n a la s m u c h a s q u e s e h a n p r o p u e s t o e n l a l i t e r a t u r a .
s o lu c ió n , é s te f o r m a p a r t e d e l e s p a c io d e l p r o b le m a . T a m b ié n e s im p o r t a n t e d e s ta c a r .q u é n o s o n lo s o b je
P e ro , ¿ q u é d e b e m o s b u s c a r u n a v e z q u e s e h a n a is la d o to s . E n g e n e r a l, u n o b je t o n u n c a d e b e t e n e r u n « n o m
to d o s lo s n o m b r e s ? b r e p r o c e d i m e n t a l i m p e r a t i v o » [ C A S 8 9 ] . P or e j e m p l o ,
s i lo s d e s a r r o lla d o r e s d e u n s o f t w a r e p a r a u n s is t e m a
g r á fic o m é d ic o d e f in ie r o n u n o b je t o c o n e l n o m b r e
¿Cómo identificar objetos inversión de im agen, e s t a r í a n c o m e t i e n d o u n s u t i l e r r o r .
• cuando estudio cómo

resolver un problema?
L a im a g e n o b te n id a p o r e l s o ftw a r e p u d ie r a s e r, e n e f e c
to , u n o b je t o (e s u n e le m e n to q u e f o r m a p a r te d e l d o m i
n io d e in f o r m a c ió n ) , p e r o la in v e r s ió n d e la im a g e n e s
L o s o b j e t o s s e m a n i f i e s t a n d e a l g u n a d e la s f o r m a s u n a o p e r a c ió n q u e s e a p lic a a d ic h o o b je t o . In v e r s ió n
m o s tra d a s e n la F ig u r a 2 0 .9 . y p u e d e n s e r: d e b e d e f i n i r s e c o m o u n a o p e r a c i ó n d e l o b j e t o im ag en ,
• entidades externas ( p o r e j e m p l o : o t r o s s i s t e m a s , d i s p e r o n o c o m o o b je t o s e p a r a d o q u e s ig n if iq u e ¿ A v e r
p o s itiv o s , p e r s o n a s ) q u e p r o d u c e n o c o n s u m e n i n f o r s ió n d e im a g e n » . C o m o e s ta b le c e C a s h m a n [ C A S 8 9 ] ,
m a c i ó n a u s a r p o r u n s is t e m a s c o m p u t a c io n a l; « . . . e l o b je t iv o d e la o r ie n t a c ió n a o b je t o s e s e n c a p s u la r ,
p e r o m a n t e n ie n d o s e p a r a d o s lo s d a to s y la s o p e r a c io
• cosas ( p o r e j e m p l o : i n f o r m e s , p r e s e n t a c i o n e s , c a r
n e s s o b re e s to s d a to s » .
t a s , s e ñ a le s ) q u e s o n p a r t e d e l d o m i n i o d e i n f o r m a
P a r a ilu s t r a r c ó m o p u e d e n d e f in ir s e lo s o b je t o s d u r a n
c ió n d e l p r o b le m a ;
t e la s p r i m e r a s e t a p a s d e l a n á l i s i s , v o l v a m o s a l e j e m p l o
s o cu rren cia s o su c e so s5 ( p o r e j e m p l o : u n a t r a n s f e d e l s i s t e m a d e s e g u r i d a d H ogarSeguro. E n e l C a p i t u l o
r e n c ia d e p r o p ie d a d o la t e r m in a c ió n d e u n a s e r ie d e 1 2 ,r e a liz a m o s u n « a n á lis is s in t á c t ic o g r a m a tic a l» s o b r e
m o v im ie n to s e n u n r o b o t) q u e o c u r r e n d e n tr o d e l
l a n a r r a t i v a d e p r o c e s a m i e n t o p a r a e l s i s t e m a H o gar-
c o n t e x t o d e u n a o p e r a c ió n d e l s is t e m a ; Seguro. L a n a r r a t i v a d e p r o c e s a m i e n t o s e r e p r o d u c e a
• p a p e le s o roles ( p o r e j e m p l o : d i r e c t o r , i n g e n i e r o , v e n c o n tin u a c ió n :
d e d o r ) d e s e m p e ñ a d o s p o r p e r s o n a s q u e in te r a c tú a n E l softw are H o g a rS eg u ro le perm ite al propietario de la
c o n e l s is t e m a ; casa configurar el sistem a de seguridad una vez que este se
• unidades o rg a n iza cio n a les ( p o r e j e m p l o : d i v i s i ó n , instala, controla to d o s los sensores co n ectad o s al sistem a de
g r u p o , e q u ip o ) q u e s o n r e le v a n te s e n u n a a p lic a c ió n ; seguridad, e interactúa con el propietario a través de un tec la
d o num érico y teclas de fu n ció n c ontenidas e n el panel de
• lugares ( p o r e j e m p l o : p l a n t a d e p r o d u c c i ó n o m u e control de H o g a rS eg u ro m ostrado e n la F igura 11.2
lle d e c a r g a ) q u e e s t a b le c e n e l c o n t e x t o d e l p r o b le m a
D u ran te la in stalació n , el panel de control de H ogarSe-
y la f u n c i ó n g e n e r a l d e l s is t e m a ; giiro se usa para «program ar» y configurar el sistem a. A cada
• estructuras ( p o r e j e m p l o : s e n s o r e s , v e h í c u l o s d e c u a sensor se le asigna un núm ero y tip o , se program a una con
t r o r u e d a s o c o m p u t a d o r a s ) q u e d e f in e n u n a c la s e d e traseña m aestra para activar y desactivar el sistem a, y se intro
ducen núm eros de teléfono a m arcar cuando un sensor detecte
o b j e t o s o , e n c a s o s e x t r e m o s , c la s e s r e l a c i o n a d a s d e
un suceso.
o b je t o s .
C uando se reconoce un suceso de sensor, el softw are invo
c a una alarm a audible a so ciad a al sistem a. D esp u és de un
tiem p o de esp e ra especificado por el propietario d urante las
actividades de configuración del sistem a, el softw are m arca
un núm ero de teléfo n o de un servicio de control, pro p o rcio
n a in fo rm a c ió n a c e rc a d e la lo c a liz a c ió n , e in fo rm a d e la
n atu raleza del suceso detectado. El núm ero será rem arcado
cada 2 0 segundos h asta o b ten er una co n ex ió n telefónica.
T oda la interacción con H ogarSeguro está gestionada por
un subsistem a de interacción con el usuario que tom a la entra
d a a partir del teclad o num érico y teclas de fu n ció n , y m ues
tra m en sajes y el estado del sistem a en la p an talla L C D . L a
interacción con el teclad o to m a la siguiente fo rm a ...
C Í A VE
Hay que utilizar un anolizador sintáctico gramat
para detectar objetos potenciales (nombres) y
F IG U R A 2 0 .9 . Cómo se manifiestan los objetos. operaciones (verbos).
www.FreeLibros.org
5 En este contexto, el term ino suceso denota cualquier ocurrencia.
No necesariam ente implica control, en el sentido del Capítulo 12.
351
INGE NIE RÍA DEL SOFTWARE. UN EN F O Q U E P R Á C T I C O
E xtrayendo los n om bres p odem os p ro p o n er varios 4 . A trib u to s com unes: puede definirse un conjunto de
objetos potenciales: atributos para el objeto potencial, los cuales son apli
cables a todas las ocurrencias del objeto.
Clase / Clasificación 5. O peraciones com unes: puede definirse un conjunto
O b j e t o potencial general de o p eracio n es para el o b jeto p o ten c ial, las cuales
p ro p ie ta rio
son aplicables a todas las ocurrencias del objeto;
ro l o
e n tid a d e x te rn a 6. R eq u isito s e sen cia les: en tid ad es extern as que apa
sensor e n tid a d e x te rn a recen en el esp acio del problem a y producen o co n
su m en in fo rm a ció n esen cial p a ra la p ro d u c ció n de
panel de c o n tro l e n tid a d e x te rn a
cualquier solución para el sistem a, serán casi siem
in sta la c ió n o c u rre n c ia p re d efin id as co m o o b je to s en el m o d elo de re q u i
siste m a cosa sitos.
( a lia s siste m a
de se g u rid ad )
n úm ero, tip o no son o b je to s ,

s in o a tr i b u t o s de
CLAVE
sensor
c o n tra se ñ a Un objeto potencial debe satisfacerlo mayoría de estas
m ae stra cosa característicaspara utilizarlo en el modelo de análisis.
n úm ero
de te lé fo n o cosa
P ara ser c o n sid erad o un o b jeto v álid o a in clu ir en
suceso de sensor
el m odelo de requisitos, un objeto potencial debe satis
o c u rre n c ia
a la rm a a u d ib le fa cer to d as (o casi to d as) las c a ra c te rístic a s an terio
e n tid a d e x te rn a res. L a d e c isió n de in c lu ir o b je to s p o te n c ia le s en el
se rv icio
de c o n tr o l u n id ad o rg a n iz a c io - m o d e lo de a n á lisis es alg o su b je tiv o , y u n a e v a lu a
n a l o e n tid a d c ió n p o s te rio r p u e d e lle g a r a d e s c a rta r un o b je to o
reincluirlo. Sin em bargo, el prim er paso del A O O debe
La lista an terio r se co n tin u a rá h a sta que se h ay an ser la d e fin ició n de o b jeto s, y la co n sig u ien te tom a de
co n sid erad o to d o s los n o m b res de la d e sc rip c ió n del decisiones (incluso subjetivas). T eniendo esto en cu en
proceso. O bserve que hem os llam ado a cada entrada en ta, ap licam os las c arac terístic as selectiv as a la lista de
la lista un o b jeto potencial. D ebem os con sid erar cada o b je to s p o te n c ia le s d e H o g a rS e g u ro (v éa se tab la a
uno de ellos antes de to m ar una d ecisión final. continuación).
Cómo saber si un objeto
•
Clase / Características
potencial es un buen
Objeto potencial aplicables
candidato para utilizarlo
en un sistema 0 0 . p ro p ie ta rio R echazado
( 1 , 2 f a lla n aunque
6 es a p lic a b le )
C oad y Y ourdon [CO A 91] sugieren seis caracterís
sensor A cep tad o ( se a p li can
ticas de selección a usar cada v ez que un analista c o n
to d as)
sidera si incluye o no un objeto p otencial en el m odelo
de análisis: panel de c o n tro l A cep tad o (se a p lic a n
to d as)
7. In fo rm a c ió n retenida: el o b jeto p o te n c ia l será de
u tilid a d d u ra n te el a n á lisis so lam en te si la in fo r in sta la c ió n R echazado
m ació n acerca de él debe recordarse p ara que el sis siste m a (a lia s s i s A cep tad o (se a p lic a n
te m a funcione. tem a d e se g u rid ad ) to d as)
2. S e r v ic io s n e c e s a r io s : el o b je to p o te n c ia l d eb e n úm ero, tip o R echazado ( f a l l a 3)
p o se e r un c o n ju n to de o p e racio n es id en tificab les c o n tra se ñ a m ae stra R echazado ( f a l l a 3)
que p u e d e n c am b iar de alg u n a m a n e ra el v a lo r de
núm ero d e te lé fo n o R echazado ( f a l l a 3)
sus atributos.
3. A trib u to s m últiples: durante el análisis de requisitos, suceso de sensor A cep tad o (se a p lic a n
to d as)
se debe centrar la atención en la info rm ació n p rin ci
pal (un objeto con un solo atributo puede, en efecto, a la rm a a u d ib le A cep tad o (se a p lic a n
www.FreeLibros.org
ser Util d u ra n te el d ise ñ o , p ero seg u ram en te será 2 , 3 , 4 , 5 Y 6)
m ejo r p resen tad o co m o un atrib u to de otro objeto se rv ic io de c o n tro l Rechazado ( f a lla n 1 y
durante la actividad de análisis); 2 aunque 6 se a p lic a )
352
CAPÍTULO 20 C O N C E P T O S Y P R I N C I P I O S O R I E N T A D O S A O BJ E TO S
D ebe tenerse en cu enta que: (1) la lista anterior no información del censor = tipo de sensor
incluye todo, hay que añadir objetos adicionales para com + número de sensor + umbral de alarma
pletar el m odelo; (2) algunos de los objetos potenciales información de respuesta de la alarma =
rechazados serán atributos de los objetos aceptados (por tiempo de retardo + número de teléfono
ejem plo, núm ero y tipo son atributos de s e n so r, y co n + tipo de alarma
traseña m aestra y núm ero de teléfono pueden convertir información de activación/desactivación
se en atributos de sistem a);y (3) diferentes descripciones = contraseña maestra + cantidad de
intentos permitidos + contraseña tempo
del problem a pueden provocar la tom a de diferentes deci
ral
siones de «acep tació n o rechazo» (por ejem plo, si cada
información de identificación = ID del
propietario tiene su propia co ntraseña o fue identificado
sistema + verificación de número de telé-
por im presiones de voz, el objeto P ro p ie ta rio cum pliría Eono + estado del sistema
las características 1 y 2 y habría sido aceptado).
C ad a uno de los elem entos de datos a la d erech a del
20.3.2. E s p e c if ic a c ió n d e a t r i b u t o s signo de igualdad puede vo lv er a definirse en un nivel
elem ental, pero para nuestros propósitos, com prenden
L os atributos d escriben un objeto que h a sido seleccio
una lista razonable de atributos para el ob jeto sistem a
nado para ser incluido en el m odelo de análisis. E n esen (porción som breada de la Fig. 20.10).
cia, son los atributos los que definen al objeto, los que
clarifican lo que se representa el objeto en el contexto del
20.3.3. D e f in ic ió n d e o p e r a c i o n e s
espacio del problem a. P or ejem plo, si tratáram os de co n s
truir un sistem a de estadísticas p ara ju g a d o re s profesio Las operaciones definen el com portam iento de un o b je
nales de béisbol, los atributos del objeto J u g a d o r serían to y cam bian, de alguna m anera, los atributos de dicho
muy diferentes de los atributos del m ism o objeto cuando objeto. M ás concretam ente, una operación cam bia valo
se use dentro del contextode un sistem a de pensiones para res de uno o m ás atributos contenidos en el objeto. Por
ju g a d o re s profesionales. E n el p rim ero, atributos tales lo tanto, una operación debe ten er «conocim iento» de
com o nom bre, posición; p rom edio de bateo, porcentaje la naturaleza de los atributos de los objetos y deben ser
de estancia en el cam po de ju e g o , años ju g a d o s y parti im plem entadas de m anera tal que le p erm ita m anipular
dos ju g a d o s pueden ser relevantes. En el segundo caso, las estructuras de datos derivadas de dichos atributos.
algunos de estos atributos serían relevantes pero otros serí A unque existen m uchos tipos diferentes de o p e ra
an reem plazados (o p otenciados)por atributos com o sala ciones, éstas pueden clasificarse en tres gran d es c a te
rio m edio, crédito total, opciones elegidas p ara el plan de g o rías: (1) o p e ra c io n e s que m a n ip u la n , d e alg u n a
pensión, dirección postal, etc. m anera, datos (p.e.: añadiendo, elim inando, reform a-
Para desarrollar un conjunto significativo de atributos tean d o , seleccio n an d o ); (2) o p eracio n es que realizan
para un objeto, el analista puede estudiar de nuevo la narra algún cálculo; y (3) o p eracio n es que m o n ito riza n un
tiva del p roceso (o d escripción del ám bito del alcance) ob jeto frente a la ocurrencia de un suceso de control.
para el p ro b lem a y seleccionar aquellos elem entos que
razonablem ente «pertenecen» al objeto. A dem ás, para ¿Existe alguna forma
cada objeto debe responderse el siguiente interrogante:
«¿Qué elem entos (com puestosy/o sim ples) definen co m
pletam ente al objeto en el contexto del problem a actual?»
• razonable de categorizar
las operaciones de un objeto?
En una prim era iteración para obtener un conjunto de

operaciones para los objetos del m odelo de análisis, el
analista puede estudiar de nuevo la narrativa del p ro ce
CLAVE so (o descripción del ám bito) del problem a y seleccio
Los atributos se escogen examinando el problema,
nar aquellas operaciones que razonablem ente pertenecen
buscando cosas que definan completamente los objetos al objeto. P ara realizar esto, se estudia de nuevo el aná
y que los hacen únicos. lisis gram atical y se aíslan los verbos. A lgunos de estos
verbos serán operaciones legítim as y pueden co n ectar
P ara ilustrar esto, co n sid erem o s el o b jeto S is te m a se fácilm ente a un objeto específico. P or ejem plo, de la
definido p ara H ogarSeguro. A n teriorm ente y a indica narrativa de proceso de H oga rseg u ro , p resentada ante
m os que el p ro pietario puede con fig u rar el sistem a de riorm ente en este capítulo, vem os que cal sensor se le
seguridadpara reflejar la inform ación acerca de los sen asigna un n ú m ero y un tipo» o que «se p ro g ram a una
sores, sobre la resp u esta de la alarm a, sobre la activa co n traseñ am aestra para activar y desactivar el sistem a».
ción/desactivación, sobre identificación, etc. U sando la E stas dos frases indican varias cosas:
notación de la d escripción del contenido definida para • que u n a operación de asignación es relevante para
www.FreeLibros.org
el diccionario de datos y p resen tad a en el C apítulo 12, el objeto S e n s o r;
p odríam os rep resen tar esto s elem entos de datos c o m • que u n a o p eració n de p ro g ra m a r se le ap licará al
puestos de la siguiente m anera: ob jeto S iste m a ;
353
• que activar y d esactivar son operaciones aplicables 20.3.4. F in d e l a d e f in ic ió n d e l o b je to

al S is te m a (o sea que el e s ta d o d el siste m a puede L a definición de operaciones es el Último paso para
en última instancia definirse usando notación del dic com pletar la especificación del objeto. En la Sección
cionario de datos) com o 20.3.3. las operaciones se eligieron a partir de un exa
estado del sistema = [activado I desacti m en gramatical de la narrativa de proceso del sistema.
vado] Las operaciones adicionales pueden determinarse con
Tras una investigación m ás detallada, es probable siderando la «historia de la vida» [C O A 91] de un obje
que haya que dividir la operación p ro g ra m a r en varias to y lo s m ensajes que se pasan entre objetos definidos
suboperaciones m ás específicas requeridas para co n por el sistema.
figurar el sistem a. Por ejem plo, p r o g r a m a r im plica La historia de la vida genérica de un objeto puede
esp ecificar núm eros de teléfonos, configurar carac definirse reconociendo que dicho objeto debe ser crea
terísticas del sistem a (por ejem plo, crear la tabla de do, modificado, m anipulado o leído de m anera diferen
sen sores, in tro d u cir las carac te rístic as de las ala r te, y posiblem ente borrado. Para el objeto S iste m a , esto
m as), e introducir la(s) contraseña(s), pero por aho puede expandirsepara reflejar actividadesconocidas que
ra, especificarem os p r o g r a m a r com o una operación ocurren durante su vida (en este caso, durante el tiempo
sim ple. que H ogarSeguro se mantiene operativo). Algunas de
las operaciones pueden determinarse a partir de comu
nicaciones sem ejantes entre objetos. Por ejem plo, el
Sistema S u ceso se n so r enviará un mensaje a S iste m a para m os
trar en pantalla la localización y núm ero del suceso; el
ID del sistema P a n e l d e c o n tro l enviará un mensaje de reinicialización
N ú m e r o de teléf o n o de v e r i f i c a c i ó n para actualizar el estado del S is te m a (un atributo); la
Estado del sistema
T a b l a de sensores
A la r m a a u d ib le enviará un m ensaje de consulta, el
T i p o de sensor P a n e l d e c o n tro l enviará un mensaje de m odificación
N ú m e r o d e s ensor para cambiar uno o más atributos sin reconfigurar el obje
Umb r a l de alarma to sistem a por com pleto; el S u c e so s e n s o r enviará un
Contraseña maestra
mensaje para llam ar al núm ero(s) de teléfono(s) conte-
Contraseña temporal
N ú m e r o de intentos nido(s) en el objeto. Podrán considerarse otros m ensa
je s para derivar operaciones correspondientes. La
definición del objeto resultante se m uestra en la Figura
Pro g r a m a r { ) 20.10.
Mostrar ( )
Reiniciar ( )
Se usaría un enfoque sim ilar para cada uno de los
Consultar ( ) objetos definidos para H ogarSeguro. Después de haber
Modificar ( ) definido los atributos y operaciones para todos los obje
L lamar { ) tos especificados hasta este punto, se crearían los ini
cios del m odelo AOO. En el Capítulo 21 se presenta un
F IG U R A 2 0 .1 0 . El objeto sistema con operaciones estudio m ás detallado del m odelo de análisis creado
asociadas. com o parte del A O O .
É f li^ C B W rta tt DE PR O Y E C T O S P E SOFTW ARE ORIENTADO A OB1ETOS
Como examinamos en la Parte Prim era y Segunda de 6. Seguimiento, m onitorización y control del progreso.
este libro, la m oderna gestión de proyectos de softwa
re puede subdividirse en las siguientes actividades:
1 . E stablecim iento de un m arco de proceso com ún
las proyectas 0 0 requieren mucha más gestión
para el proyecto.
de lo planificación y seguimientoque los proyectas
2. U so del m arco y de m étricashistóricas para desa de software convencional. Nosuponga que la 00
rrollar estim aciones de esfuerzo y tiem po. le releva de esto actividad.
3 . Especificación de productos de trabajo e hitos que

perm itirán m edir el progreso. El director técnico que se enfrenta con un proyecto
de software orientado a objetos aplica estas seis activi
4 . Definición de puntos de comprobación para la gestión dades. Pero debido a la naturaleza única del software
www.FreeLibros.org
de riesgos, aseguramiento de la calidad y control. orientado a objetos, cada una de estas actividades de
5. G estión de los cam bios que ocu rren in v a ria b le gestión tiene un m atiz levemente diferente y debe ser
m ente al progresar el proyecto. enfocado usando un m odelo propio.
354
C A P Í T U L O 20 C O N C E P T O S Y P R I N C I P I O S OR IE N TA DO S A O B J E T O S
E n la s s e c c i o n e s q u e s i g u e n , e x p l o r a m o s e l á r e a d e . E n s a m b la r u n n u e v o p r o t o t ip o u s a n d o o b je t o s d e la
g e s t ió n d e p r o y e c t o s o r ie n t a d o s a o b je t o s . L os p r i n c i b ib lio t e c a y lo s o b je t o s q u e s e c r e a r o n n u e v o s .
p io s d e g e s tió n fu n d a m e n ta le s s e r á n lo s m is m o s , p e r o • R e a liz a r p r u e b a s p a r a d e s c u b r ir e r r o r e s e n e l p r o t o -
para que u n p ro y e c to 0 0 sea d irig id o co rrectam en te . tip o .
h a y q u e a d a p ta r la té c n ic a .
• O b te n e r r e a lim e n ta c ió n d e l c lie n t e s o b r e e l p r o t o
tip o .
E s te e n fo q u e c o n tin ú a h a s ta q u e e l p r o to tip o e v o lu
Referencia W&bA c io n a h a c ia u n a a p lic a c ió n e n p r o d u c c ió n .
Encontraráun tutorial muy completo sobre gestión
de proyectos 0 0 y un buen conjunto de enlaces en: ¿Cómo aplicar un modelo
mm¡.net/cetus/oo_pro¡ect_mngt.html.
• recursivo/paralelo en la
ingeniería del software 0 0 ?
20.4.1. El marco d e proceso común para O O

E l m o d e lo r e c u r s iv o /p a r a le lo e s m u y s im ila r a l m o d e
U n m a r c o d e p r o c e s o c o m ú n ( M P C ) d e f in e u n e n fo q u e
lo d e p r o c e s o O O p r e s e n ta d o a n te r io r m e n te e n e s te c a p í
o r g a n iz a tiv o p a r a e l d e s a r r o llo y m a n t e n im ie n t o d e s o f t
t u lo . E l p r o g r e s o s e p r o d u c e it e r a t iv a m e n t e . L o q u e h a c e
w a r e . E l M PC i d e n t i f i c a e l p a r a d i g m a d e i n g e n i e r í a d e l
d ife r e n te a l m o d e lo r e c u r s iv o /p a r a le lo e s e l r e c o n o c i
s o ftw a r e a p lic a d o p a r a c o n s t r u ir y m a n te n e r e l s o f t w a
m ie n t o d e q u e (1 ) e l m o d e lo d e a n á lis is y d is e ñ o p a r a
r e , a s í c o m o la s t a r e a s , h i t o s y e n t r e g a s r e q u e r i d o s . E s t a
s is t e m a s O O n o p u e d e r e a liz a r s e a u n n i v e l u n if o r m e
b le c e e l g r a d o d e r ig o r c o n e l c u a l s e e n f o c a r á n lo s
d e a b s tr a c c ió n , y ( 2 ) e l a n á lis is y d is e ñ o p u e d e n a p li
d ife r e n te s t ip o s d e p r o y e c to s . E l M P C s ie m p r e e s a d a p
c a r s e a c o m p o n e n te s in d e p e n d ie n te s d e l s is t e m a d e
t a b l e , d e t a l m a n e r a q u e s i e m p r e c u m p l a c o n la s n e c e
m a n e r a c o n c u r r e n te . B e r a r d [ B E R 9 3 ] d e s c r ib e e l m o d e
s id a d e s i n d i v i d u a l e s d e l e q u i p o d e l p r o y e c t o . É s t a e s s u
lo d e la s ig u ie n te m a n e r a :
c a r a c te r ís tic a m á s im p o r t a n t e .
• D e s c o m p o n e r s is t e m á tic a m e n te e l p r o b le m a e n c o m
p o n e n te s a lta m e n t e in d e p e n d ie n te s .
• A p l ic a r d e n u e v o e l p r o c e s o d e d e s c o m p o s ic ió n a
tm w m m m
El marco de procesa común define las octividodes c a d a u n a d e la s c o m p o n e n t e s i n d e p e n d i e n t e s p a r a , a
básicos de Ingeniería delsoftware. Se describe s u v e z , d e s c o m p o n e r la s ( la p a r te r e c u r s iv a ) .
en el C apítuloí. • C o n d u c ir e s te p r o c e s o d e r e a p lic a r la d e s c o m p o s i
c ió n d e f o r m a c o n c u r r e n te s o b r e to d o s lo s c o m p o
n e n te s ( la p a r te p a r a le la ) .
Ed B erard [BER93] y G rady B ooch [ B 0 0 9 1 ] , entre • C o n t in u a r e s te p r o c e s o h a s ta c u m p lir lo s c r it e r io s d e
otros, sugieren el u so de un «m odelo recu rsivo/parale fin a liz a c ió n .
lo» para el desarrollo de softw are orientado a objetos.
En esencia, el m odelo recursivo/paralelo funciona de la E s im p o r ta n te o b s e r v a r q u e e l p r o c e s o d e d e s c o m
s ig u ie n t e m a n e r a : p o s ic ió n m o s tr a d o a n te r io r m e n te e s d is c o n t in u o s i e l
. R e a l i z a r l o s a n á l i s i s s u f i c i e n t e s p a r a a i s l a r la s c la s e s a n a lis ta /d is e ñ a d o r r e c o n o c e q u e e l c o m p o n e n te o s u b -
d e l p r o b l e m a y la s c o n e x i o n e s m á s i m p o r t a n t e s . c o m p o n e n te r e q u e r id o e s tá d is p o n ib le e n u n a b ib lio t e
c a d e r e u tiliz a c ió n .
• R e a l i z a r u n p e q u e ñ o d i s e ñ o p a r a d e t e r m i n a r s i la s
P a ra c o n t r o la r e l m a r c o d e p r o c e s o r e c u r s iv o /p a r a
c la s e s y c o n e x i o n e s p u e d e n s e r i m p l e m e n t a d a s d e
le lo , e l d ir e c t o r d e l p r o y e c to tie n e q u e r e c o n o c e r q u e e l
m a n e r a p r á c tic a .
p r o g r e s o e s tá p la n if ic a d o y m e d id o d e m a n e r a in c r e -
• E x t r a e r o b je t o s r e u t iliz a b le s d e u n a b ib lio t e c a p a r a
m e n t a l . E s t o e s , la s t a r e a s y l a p l a n i f i c a c i ó n d e l p r o y e c t o
c o n s tr u ir u n p r o to tip o p r e v io . e s tá n u n id a s a c a d a u n a d e la s « c o m p o n e n t e s a lt a m e n
• C o n d u c ir a lg u n a s p r u e b a s p a r a d e s c u b r ir e r r o r e s e n te in d e p e n d ie n te s » , y e l p r o g r e s o s e m id e p a r a c a d a u n a
e l p r o to tip o . d e e s ta s c o m p o n e n te s in d iv id u a lm e n t e .
• O b te n e r r e a lim e n ta c ió n d e l c lie n t e s o b r e e l p r o t o
tip o .
. M o d if ic a r e l m o d e lo d e a n á lis is b a s á n d o s e e n lo q u e
se h a a p r e n d id o d e l p r o t o t ip o , d e la r e a liz a c ió n d e l
d is e ñ o y d e la r e a lim e n t a c ió n o b te n id a d e l c lie n te . En muchos aspectos, lo arquitectura de un sistema 0 0
www.FreeLibros.org
• R e f in a r e l d is e ñ o p a r a a c o m o d a r s u s c a m b io s . hoce que el comenzar o trabajar en paralelo sea
más fácil. Sin embargo, también es cierto que codo
• C o n s t r u ir o b je t o s e s p e c ia le s ( n o d is p o n ib le s e n la
toreo paralela se define de formo que pueda calcularse
b ib lio t e c a ) . el progreso.
JZ 7
INGE NIE RÍA DEL SOF TW ARE . UN E N F O Q U E P R Á C T I C O
Primeras iteraciones
en análisis/diseño
p ro to tip o
Evaluación | Siguiente
incremento
Evaluación l 'U-ésimo
dei cliente Bincremento
F IG U R A 2 0 .1 1 . Secuencia típica de un proceso para un proyecto OO.
C ada iteración del proceso recursivo/paralelo requie que el objetivo principal es la reutilización. Las estim a
re planificación, ingeniería (análisis, diseño, extracción ciones a partir de PF pueden usarse de m anera efectiva,
de clases, p rototipado y p ru eb as) y actividades de ev a pues los elem entos del dom inio de inform ación requeri
luación (Fig. 20.11). D urante la planificación, las activi dos se pueden determ inar a partir del planteam iento del
dades asociadas con cada u n a de las com ponentes problem a. El análisis de PF puede aportar valores para
independientes del program a son incluidas en la planifi estim acionesen proyectos 0 0 ,p e r o la m edida de PF no
cación. [Nota: Con cada iteración se ajusta la agenda para provee una granularidad suficiente para ajustes de plani
acom odar los cam bios asociados con la iteración prece ficación y esfuerzo a realizar, los cuales se requieren cuan
dente]. D urante las prim eras etapas del proceso de inge do iteram os a través del paradigm a recursivo/paralelo.
niería, el análisis y el diseño se realizan iterativam ente. L orenz y K idd [LO R94] sugieren el siguiente con
La intención es identificar todos los elem entos im portan ju n to de m étricas para proyectos6:
tes del análisis OO y de los m odelos de diseño. Al co n ti
N úm ero de guiones de escenario. U n guión de
n u ar el trabajo de ingeniería, se pro d u cen versiones
esc en a rio (co m o los casos de uso d iscu tid o s en el
increm entales del software. D urante la evaluación se rea
C apítulo 11) es una secuencia detallada de pasos que
lizan, p ara cada increm ento, revisiones, evaluaciones del
describen la interacción entre el usuario y la aplica
cliente y pruebas, las cuales producen una realim entación
ción. C ada guión se organiza en tripletes de la forma:
que afecta a la siguiente actividad de planificación y al
subsiguiente increm ento. {in iciad o r, acción, p a rtic ip a n te ]
donde iniciador es el ob jeto que solicita algún ser
20.4.2. Métricas y estim ación en proyectos vicio (que inicia un m ensaje); acción es el resultado
orientados a objetos de la solicitud; y p a rtic ip a n te es el objeto servidor
Las técnicas de estim ación en proyectos de softw are con que cum ple la petición (solicitud). El núm ero de guio
vencionales requieren estim aciones de líneas de código nes de actu ació n e stá directam en te re la c io n a d a al
(LD C ) o puntos de función (PF) com o controlador prin tam año de la aplicación y al núm ero de casos de prue
cipal de estim ación. Las estim aciones realizadas a partir b a que se deben desarrollar para ejercitar el sistem a
una vez construido.
www.FreeLibros.org
de LD C tienen p oco sentido en proyectos OO debido a
6 Las técnicas de medida de sistemas OO se discuten con detalle en

el capítulo 24.
356
CAPÍTULO 20 C O N C E P T O S Y P R IN C IP IO S O R IE N T A D O S A O B JE TO S
rrollar estim aciones razonables es esencial el d esarro

llo de m últiples puntos de datos. E sto significa que las
Estos métricos pueden utilizarse poro complementar los
estim aciones deben derivarse usando diferentes té c n i
métricos FP. Proporcionan uno formo de «medir» un cas. Las estim aciones respecto al esfuerzo y la duración
proyecto 00. u sadas en el desarrollo de softw are convencional (C apí
tulo 5 ) son aplicables al m undo de la 0 0 , p e r o la base
Número de clases clave. Las clases clave son las de datos h istó rica para proyectos O O es re la tiv a m e n
«com ponentes altam ente independientes» [LOR94] te pequeña en m uchas organizaciones. D eb id o a esto,
definidas inicialm ente en el AOO. D ebido a que estas vale la pena sustituir la estim ación de costes para soft
clases son c e n tra le s al d o m in io del p ro b le m a , el w are convencional p o r un enfoque diseñ ad o explícita
m en te p ara so ftw a re O O . L o re n z y K id d [L O R 94]
núm ero de dichas clases es una indicación del esfuer
zo necesario p ara desarro llar el softw are y de la can sugieren el siguiente enfoque:
tidad potencial de reu tilizació n a aplicar durante el 1. D e sa rro llo de e stim a c io n e s u sa n d o la d e sc o m p o
d esarrollo del sistem a. sició n de esfu erzo s, an álisis de P F y c u a lq u ier o tro
Número de clases de soporte. Las clases de sopor m éto d o ap licable a ap licacio n es co nvencionales.
te son necesarias para im plem entar el sistem a, pero no 2. D esarro llar gu io n es de e sc e n a rio y d ete rm in a r una
están directam ente relacionadas con el dom inio del cuenta, usando A O O (C ap ítu lo 21). R ec o n o ce r que
problem a. C om o ejem plos podem os tom ar las clases el n ú m ero de gu io n es de escen ario s p u ede cam b iar
de Interfaz G ráfica de U suario, el acceso a bases de co n el p ro g reso del proyecto.
datos y su m anipulacióny las clases de com unicación.
A dem ás las clases de soporte se definen iterativam en
te a lo largo del proceso recursivo/paralelo. is m m s m s m
En el Capitulo 5 se consideran diferentes técnicos
El n ú m ero de clases de sop o rte e s un in d icad o r
de estimación de proyectos software
del e sfu e rz o n e c e sa rio re q u e rid o p a ra d e sa rro lla r
el so ftw are y de la can tid a d p o te n c ia l de re u tiliz a
ción a a p licar d u ran te el d esarro llo del sistem a.
3 . D e te rm in a r la c a n tid a d de c la se s c la v e u sa n d o
e s« s m m AOO.
Bi el Capitulo 24 se presentan detalladamente
4. C la sific a r el tip o de in terfa z p a ra la ap licació n y
las métricas 00.
d e s a rro lla r un m u ltip lic a d o r p a ra la s c la se s de
soporte:
Número promedio de clases de soporte por cla
se clave. E n general las clases clave son conocidas Tipo de Interfaz Multiplicador
en las p rim e ra s etap as del p ro y ecto . L as clases de Interfaz no gráfica
sop o rte se d efin en a lo la rg o de éste. Si, d a d o un
tSJ
(No IGU)
O
dom inio de problem a, se conociera la cantidad p ro
Interfaz de usuario
m ed io de clases de soporte p o r clase clave, la esti basada en texto 2,25
m ació n (b asad a en la can tid a d to tal de c la se s) se
sim plificaríam ucho. Interfaz Gráfica de Usario
(IGU) 2, 5
Lorenz y K idd sugieren que las aplicaciones con
IGU poseen entre dos y tres veces m ás clases de sopor Interfaz Gráfica de Usuario
te que clases clave. L as aplicaciones sin IG U poseen (IGU) compleja 3, 0
a lo sum o dos veces m ás de soporte que clave.
Número de subsistemas.Un subsistema es una agre M ultiplicar el núm ero de clases clave (paso 3) p o r
gación de clases que dan soporte a una íúnción visible el m u ltip lic a d o r an terio r para o b ten er una e s tim a
al usuario final del sistema. U na vez que se identifican c ió n del n ú m ero de c la se s de soporte.
los subsistemas, resulta m ás fácil realizar una planifica 5. M u ltip lic a r la c a n tid a d to tal d e c la se s (c la v e +
ción razonable en la cual el trabajo en los subsistem as soporte) p o r el núm ero m edio de unidades de trabajo
está repartida entre los m iem bros del proyecto. p o r clase. L o ren zy K idd sugieren entre 15y 2 0 d ía s-
-persona p o r clase.
20.4.3. U n e n fo q u e O O p a ra e s tim a c io n e s 6. C om probar la estim ación respecto a clases m ultip li

y p la n ifica ció n can d o el n ú m ero p ro m ed io de u n id ad es de trab ajo
www.FreeLibros.org
p o r guión de acción.
La estim ación en p royectos de softw are es m ás un arte
que u n a cie n c ia . Sin e m b a rg o , e sto en m o d o alg u n o L a planificación de proyectos o rien tad o s a objetos
excluye el u so de u n en fo q u e sistem ático. P ara d e sa es com plicada p o r la naturaleza iterativa del m arco de
357
in g en ier ía del s o f t w a r e , un en fo q u e pr á c tic o
tr a b a jo d e l p ro c e s o . L o r e n z y K id d s u g ie r e n u n c o n ju n t o « S e h a c r e a d o y r e v is a d o u n m o d e lo d e c o m p o r ta
d e m é tr ic a s q u e p u e d e n a y u d a r d u r a n te e s ta p l a n i f ic a m ie n to ( C a p ítu lo 2 1 ) .
c ió n d e l p r o y e c to : • S e h a n m a r c a d o c la s e s r e u t i l i z a b l e s .
N ú m e ro de ite ra c io n e s p rin c ip a le s . R e c o r
d a n d o e l m o d e lo e n e s p ir a l ( C a p í tu lo 2 ) , u n a it e H ito técnico: diseño OO term inado
r a c ió n p r in c ip a l c o r r e s p o n d e rá a u n r e c o r r id o d e • S e h a d e f in id o y r e v is a d o e l c o n ju n t o d e s u b s is te m a s
3 6 0 g r a d o s d e la e s p ir a l. E l m o d e lo d e p r o c e s o ( C a p ítu lo 2 2 ).
r e c u r s iv o /p a r a le lo e n g e n d r a r á u n n ú m e r o d e m in i—
• L a s c la s e s s e h a n a s i g n a d o a s u b s i s t e m a s y h a n s i d o
e s p ir a le s ( it e r a c io n e s lo c a liz a d a s ) q u e s u c e d e n
r e v is a d a s .
d u r a n te e l p r o g r e s o d e la it e r a c ió n p r in c ip a l. L o r e n z
y K i d d s u g ie r e n q u e la s it e r a c io n e s d e e n tr e 2 .5 y • S e h a e s t a b le c id o y r e v is a d o la a s ig n a c ió n d e ta re a s .
4 m e s e s d e d u r a c ió n s o n m á s f á c ile s d e s e g u ir y • S e h a n id e n t if ic a d o r e s p o n s a b ilid a d e s y c o la b o r a
g e s tio n a r . c io n e s ( C a p í t u lo 2 2 ) .
N ú m e r o d e c o n tr a to s c o m p le to s . U n c o n t r a t o • S e h a n d i s e ñ a d o y r e v i s a d o l o s a t r i b u t o s y o p e r a c io n e s .
e s « u n g r u p o d e r e s p o n s a b ilid a d e s p ú b lic a s r e la
• S e h a c r e a d o y r e v is a d o e l m o d e lo d e p a s o d e m e n
c io n a d a s q u e lo s s u b s is te m a s y la s c la s e s p r o p o r
s a je s .
c io n a n a s u s c lie n te s » [ L O R 9 4 ] , U n c o n t r a t o e s u n
h i t o e x c e le n t e , y d e b e r í a a s o c ia r s e a l m e n o s u n c o n
H ito técnico:program ación OO term inada
tr a to a c a d a it e r a c ió n d e l p r o y e c to . U n je f e d e p r o
y e c t o p u e d e u s a r c o n tr a to s c o m p le t o s c o m o u n • C a d a n u e v a c la s e h a s id o im p le m e n t a d a e n c ó d ig o a
b u e n in d ic a d o r d e l p r o g r e s o e n u n p r o y e c to O O . p a r t ir d e l m o d e lo d e d is e ñ o .
. L a s c la s e s e x t r a í d a s ( d e u n a b i b l i o t e c a d e r e u t i l i z a
c ió n ) s e h a n in te g r a d o .
20.4.4. S e g u im ie n t o d e l p r o g r e s o e n u n p r o
• S e h a c o n s t r u id o u n p r o t o t ip o o in c r e m e n to .
y e c to o r ie n ta d o a o b jeto s
A u n q u e e l m o d e lo d e p r o c e s o r e c u r s iv o /p a r a le lo e s e l H ito técn ico:pru eba OO
m e jo r m a r c o d e tr a b a jo p a ra u n p r o y e c to 0 0 , e l p a r a
• H a n s id o r e v is a d a s la c o r r e c c ió n y c o m p le c ió n d e l
le lis m o d e ta r e a s d i f ic u lt a e l s e g u im ie n t o d e l p r o y e c
a n á lis is 0 0 y d e l m o d e lo d e d is e ñ o .
to . E l je f e d e l p r o y e c to p u e d e te n e r d ific u lt a d e s
e s t a b le c ie n d o h it o s s ig n if ic a t i v o s e n u n p r o y e c t o O O . S e h a d e s a r r o lla d o y r e v is a d o u n a r e d d e c la s e s —
d e b id o a q u e s ie m p r e h a y u n c ie r t o n ú m e r o d e c o s a s r e s p o n s a b ilid a d e s - c o la b o r a c io n e s ( C a p ítu lo 2 3 ).
o c u r r ie n d o a la v e z . E n g e n e r a l, lo s s ig u ie n te s h it o s • S e h a n d is e ñ a d o c a s o s d e p r u e b a y e je c u ta d o p r u e
p r in c ip a le s p u e d e n c o n s id e r a r s e « c o m p le t a d o s » a l b a s a l n i v e l d e c la s e s p a r a c a d a c l a s e ( C a p í t u l o 2 3 ) .
c u m p lir s e lo s c r it e r io s m o s t r a d o s :
• S e h a n d is e ñ a d o c a s o s d e p r u e b a y c o m p le t a d o p r u e
b a s d e a g r u p a m i e n t o s ( C a p í t u l o 2 3 ) y la s c la s e s s e
H ito técnico: análisis OO term inado h a n in te g r a d o .
• T o d a s la s c la s e s , y l a j e r a r q u í a d e c la s e s , e s t á n d e f i • S e h a n t e r m i n a d o la s p r u e b a s d e l s is t e m a .
n id a s y r e v is a d a s .
R e c o r d a n d o e l m o d e lo d e p r o c e s o r e c u r s iv o /p a r a le
• S e h a n d e f in id o y r e v is a d o lo s a t r ib u t o s d e c la s e y
lo e x a m in a d o a n te r io r m e n te e n e s te c a p í t u lo , e s im p o r
la s o p e r a c i o n e s a s o c ia d a s a u n a c la s e .
ta n te d e s ta c a r q u e c a d a u n o d e e s to s h ito s p u e d e s e r
• S e h a n e s t a b le c id o y r e v is a d o la s r e l a c io n e s e n t r e r e v is a d o n u e v a m e n te a l e n tr e g a r d ife r e n te s in c r e m e n
c la s e s ( C a p í t u l o 2 1 ) . t o s a l u s u a r io .
L a s t e c n o lo g ía s d e o b je t o s r e f le ja n u n a v is i ó n n a t u s e n ta d o s c o m o o b je t o s . Es im p o r t a n t e d e s ta c a r q u e
r a l d e l m u n d o . L o s o b je t o s s e c la s if i c a n e n c la s e s y lo s o b je t o s ( y la s c la s e s d e la s q u e s e d e r iv a n ) e n c a p -
la s c la s e s s e o r g a n i z a n e n je r a r q u í a s . C a d a c la s e c o n s u la n d a to s y p r o c e s o s . L a s o p e r a c io n e s d e p r o c e s a
tie n e u n c o n ju n t o d e a t r ib u t o s q u e la d e s c r ib e n y u n m i e n t o s o n p a r t e d e l o b j e t o y s e i n i c i a n a l p a s a r l e un
c o n ju n t o d e o p e r a c io n e s q u e d e f in e su c o m p o r t a m e n s a je a l o b je t o . U n a d e f i n i c i ó n d e c la s e , u n a v e z
m ie n t o . L o s o b je t o s m o d e la n c a s i t o d o s lo s a s p e c to s d e f in id a , c o n s t it u y e la b a s e p a r a la r e u t iliz a c ió n e n
www.FreeLibros.org
id e n t if ic a b le s d e l d o m i n io d e l p r o b le m a : e n tid a d e s lo s n iv e le s d e m o d e la d o , d is e ñ o e im p le m e n t a c ió n .
e x t e r n a s , c o s a s , o c u r r e n c ia s , r o le s , u n id a d e s o r g a n i- L o s o b je t o s n u e v o s p u e d e n s e r in s t a c ia d o s a p a r t ir
z a c io n a le s , lu g a r e s y e s t r u c t u r a s p u e d e n s e r r e p r e d e u n a c la s e .
358
CAPÍTULO 20 C O N C E P T O S Y P R I N C I P I O S O R I E N T A D O S A O BIE TO S
T re s c o n c e p to s im p o r t a n t e s d ife r e n c ia n e l e n fo q u e O O d e l í n e a s d e c ó d i g o n e c e s a r i a s p a r a i m p l e m e n t a r u n s is
d e la in g e n ie r í a d e l s o ftw a r e c o n v e n c io n a l. E l e n c a p s u - te m a y f a c il it a lo s c a m b io s e n c a s o d e q u e s e p r o d u z c a n .
l a m i e n t o e m p a q u e t a d a t o s y la s o p e r a c i o n e s q u e m a n e Los p r o d u c t o s y s i s t e m a s o r i e n t a d o s a o b j e t o s s e p r o
ja n e s o s d a to s . L a h e r e n c ia p e r m it e q u e lo s a t r ib u to s y d u c e n u s a n d o u n m o d e lo e v o lu t iv o , a v e c e s lla m a d o
o p e r a c io n e s d e u n a c la s e p u e d a n s e r h e r e d a d o s p o r to d a s r e c u r s iv o /p a r a le lo . E l s o ftw a r e o r ie n t a d o a o b je t o s e v o
la s c la s e s y o b je t o s q u e s e in s t a n c ia n d e e lla . E l p o l i lu c io n a it e r a tiv a m e n te y d e b e d ir ig ir s e te n ie n d o e n c u e n
m o r f is m o p e r m it e q u e u n a c a n t id a d d e o p e r a c io n e s d i f e ta q u e e l p r o d u c t o f i n a l se d e s a r r o lla r á a p a r t ir d e u n a
re n te s p o s e a n e l m is m o n o m b r e , r e d u c ie n d o la c a n tid a d s e r ie d e in c r e m e n t o s .
[B E R 93 ] B erard, E .V ., Essays on Object— Oriented Softwa [C O X 8 6 ] C ox, B .J., Object-Oriented Programming, A d d i

re Engineering, A ddison— W esley, 1993. son-W esley, 1986.
[B 0 0 8 6 ] B ooch, G ., «Object-OrientedDevelopment», IEEE [E V B 8 9 ] Object-OrientedRequirem ents Analysis (course

Trans. Software Engineering, Vol. S E - 12, Febrero 1986, notebo ok), E V B S oftw are E n g in eerin g , Inc., F red erick,
pp. 211 y ss. M D , 1989.
[ B 0 0 9 1 ] B ooch , G ., Object-O riented Design, B e n ja m in - [JA C 92] Jacobson, I., Object-Oriented Software Engineering,
C um m ings, 1991. A d d iso n -W esley, 1992.
[B U D 9 6 ] B udd, T ../1 /f introduction to Object-Oriented Pro [L O R 9 4 ] Lorenz, M ., y K id d , J., Object-Oriented Software

gramming, 2 .a ed., A ddison -W esley, 1996. M etrics, P re n tic e-H a ll, 1994.
[C A S 89] C as h m an ,M ., «O bject-O riented D o m ain Analysis», [S T R 8 8 ] S troustrup, B ., « W h a t is O b je c t-O rie n te d P ro

ACM Software Engineering Notes, vol. 14,n.° 6, Octubre gram m ing?», IEEE Software, vol. 5, n.° 3, M a y o 1988,
1989, pp 67. pp. 10-2 0 .
[C H A 93] Champeaux, D . de D . Lea, y P. Faure, Object-Orien [T A Y 9 0 ] Taylor, D .A ., Object-Oriented Technology:A Mana-

ted System Development, A ddison -W esley, 1993. ger's G uide, A ddison -W esley, 1990.
[C O A 9 1] Coad, P„ y Yourdon, E ., Object-Oriented Analysis,

2." ed., P re n tic e-H a ll, 1991.
20.1. L a ingeniería del softw areorientada a objetos está reem 2 0 .6 . C onsidere la típ ic a in te rfa z g ráfica de usuario (IG U ).
plazando rápidam ente a los enfoques de desarrollo de soft D e fin a un c o n ju n to de clases y subclases para las e n ti
ware tradicionales. C om o todas las tecnologías, la orientación dades de la in te rfa z q u e ap arecen g e n e ra lm e n te en una
a objetos tam bién tiene sus fallo s. U tiliza n d o Internet y otras IG U . A s e g ú re s e de d e fin ir lo s a trib u to s y o p e ra c io n e s
fuentes de b ib lio g ra fía m ás tradicionales, escriba un breve apropiadas.
artículo que resuma lo que les críticos dicen sobre la O O y
por qué creen que hay que tener cuidado al aplicar el para 2 0 .7 . D e ta lle los objetos que aparecerían en un sistem a de
digm a de objetos. reserva de aulas de lec tu ra en una universidad o c o le g io .
¿C uáles serían sus atributos?
20.2. E n este capítulo no hemos considerado el caso en el que
un nuevo objeto necesita un atributo u operación que no está 2 0 .8 . L e ha sido asignada la tarea de in g e n ie ría de un n u e
contenido en la clase de la que hereda el resto de atributos y vo p ro g ram a de p ro cesam iento de textos. Se ha id e n tifi
operaciones. ¿Cómo cree que se m anejaría esta situación? cado una clase lla m a d a d o cu m en to . D e fin a los atributos
y operaciones relevantes de dicha clase.
20.3. D e ta lle los objetos que p a rtic ip aría n en un sistem a
de reservas de vuelos. ¿Cuáles serían sus atributos? 2 0 .9 . In v e s tig u e dos leng uajes de pro gram ación O O d ife
20.4. U tilizando sus propias palabras y algunos ejem plos defina rentes y m uestre la im p lem e n ta ció n de l o s m ensajes en la
los términos clase, encapsulamiento, herencia y polimorfismo. sintaxis de cada uno de e llo s . Ponga e je m p lo s .
www.FreeLibros.org
20.5. R evise los objetos definidos en el sistem a H ogarSe 20.10. Ponga un e je m p lo concreto de reestructuración de
guro. ¿Cree que hay otros objetos que deban ser d e fin id o s je ra rq u ía de clases tal y com o aparece en la discusión de
como p rin c ip io del m odelado? la F ig u ra 2 0 .8 .
359
20.11. Ponga un e je m p lo de herencia m ú ltip le . Investigue la Sección 2 0 .3 .1 para determ in ar qué clases deberían estar
algunos artícu lo s sobre e l te m a y e x tra ig a los pros y los en e l m o d e lo de a n álisis .
contras.
20.13. D es crib a con sus propias palabras p o r qué el m ode
20.12. E scriba un enunciado para un sistem a que le p ro lo re cu rsivo /p ara lelo es apropiado en los sistem as O O .
p orcione su pro fesor. U tilic e e l a n a liza d o r sintáctico gra
m a tic a l p a ra id e n tific a r clases c an d id a ta s, a trib u to s y 20.14. Ponga tres o cuatro e je m p lo s de clases c la ve y de
operaciones. A p liq u e el c rite rio de selección discutido en soporte que se describiero n én la Sección 2 0 .4 .2 .
n » » A « t g C í ttl>Afi Y f BENTES DE IN FO R M A C IÓ N
L a explosión de interés por las tecnologías O O ha dado com o L a naturaleza Única del p arad ig m a O O supone especia
resultado la publicación de literalm ente cientos de libros duran les retos a los gestores de pro yecto. L o s lib ro s de C ock-
te los Ú ltim os 15 años. E l tratam iento abreviado de T a y lo r B u rn (Surviving Object-Oriented P rojects: A M anager’s
[T A Y 9 0] sigue siendo la m ejor introducción al tema. Adem ás, Guide, A d d iso n -W esley, 1 9 9 8 ), B o o ch (Object Solutions:
los libros de A m bler (The ObjectPrimer: The applicationDeve- M anaging the Object Oriented Project, A ddison -W esley,
lopper’s Guideto Object-Orientation,S I G S B o o k s , 1998), Gos- 1 9 9 5 ), G o ld b erg y R u b ín (Succeding With Objects: Deci
sain y Graham (ObjectModeling and Design Strategies, S IG S sión Frameworks f o r Project Management, A d d iso n -W es
Books, 1998), B ahar (Object TechnologyMade Simple, Sim ple ley, 1 9 9 5 ) y M e y e r (Object-Success: A M an a g er’s Guide
Software Publishing, 1 99 6)y Singer (Object Technology Stra to Object Orientation, P re n tic e -H a ll, 1 9 9 5 ) consideran las
tegies and 7«crics,Cam bndgeUniversityPress, 1 9 9 6 )son tam estrategias de p la n ific a c ió n , seguim iento y control de pro
bién valiosas introducciones a los conceptos y métodos O O . yectos O O .
Z a m ir (Handbookof Object Technology, C R C Press, 1998) E a rle s y S im m s (B uilding B usiness O bjects, W ile y ,
ha editado un volum inoso tratado que cubre todos los aspec 1 9 9 8 ), C a rm ic h a e l (D evelopingB usiness O bjects, S IG S
tos de las tecnologías de objetos. Fayad y L aitn en (Trunsition B ooks, 1 9 9 8 ), F in g a r (T heB lueprintfor Business Objects,
to Object-Oriented Software Development, W ile y , 1998) u ti C am bridge U n iversity Press, 1996) y T a y lo r (Business Engi-
liz a casos de estudio para iden tificar los retos técnicos, c u l neerin with O bject Technology, W ile y , 1 9 9 5 ) enfocan la
turales y de gestión a superar cuando una organización hace tecn ología de objetos tal y com o se aplica en contextos de
una transición a la tecnología de objetos. G ardner et al. (Cog- negocios. Sus lib ro s m uestran m étodos p ara expresar los
nitive Patterns: Problems-Solving F ram ew orksfor Object conceptos y requisitos de negocio directam ente com o obje
Technology, C am bride U n iversity Press, 1 99 8)p ro p o rcio n a r tos y aplicaciones orientadas a objetos.
al lector una introducción básica sobre conceptos de resolu E n In te rn e t hay gran v a rie d a d de fu entes de in fo rm a
ción de problemas y la tecnología asociada a los patrones cog- ción sobre tecnologías de objetos y otros tem as relaciona
nitivos y al m odelado cognitivo tal y com o se aplican en los dos. E n http://www.pressman5.com e ncon trará una lista
sistemas orientados a objetos. de referencias w eb actu alizada sobre tem as O O .
C A P ÍT U L O
21 ANALISIS ORIENTADO A OBJETOS
U A N D O s e t ie n e q u e c o n s t r u i r u n n u e v o p r o d u c t o o s is t e m a , ¿ c ó m o l o c a r a c t e r iz a m o s d e
C f o r m a t a l q u e s e a t r a t a d o p o r la in g e n ie r í a d e l s o f t w a r e o r ie n t a d o a o b je t o s ? ¿ H a y p r e g u n
t a s e s p e c i a l e s q u e q u e r a m o s h a c e r a l c l i e n t e ? ¿ C u á le s s o n l o s o b j e t o s r e l e v a n t e s ? ¿ C ó m o
s e r e l a c io n a n e n t r e s í? ¿ C ó m o s e c o m p o r t a n lo s o b je t o s e n e l c o n t e x t o d e l s is t e m a ? ¿ C ó m o e s p e
c if ic a m o s o m o d e la m o s u n p r o b le m a d e f o r m a t a l q u e p o d a m o s c r e a r u n d is e ñ o e f ic a z ?
A c a d a u n a d e e s ta s in te r r o g a n t e s s e r e s p o n d e d e n t r o d e l c o n t e x t o d e l a n á lis is o r ie n t a d o a
o b j e t o s (A O O ), p r i m e r a a c t i v i d a d t é c n i c a q u e s e d e s a r r o l l a c o m o p a r t e d e l a i n g e n i e r í a d e l s o f t
w a r e 0 0 . E n lu g a r d e e x a m in a r u n p r o b le m a u t iliz a n d o e l m o d e lo d e in f o r m a c ió n c lá s ic o d e
f l u j o d e d a to s , e l A O O in t r o d u c e v a r io s c o n c e p to s n u e v o s . C o a d y Y o u r d o n [ C O A 9 1 ] c o n s id e
r a n el t e m a c u a n d o e s c r i b e n :
E1 A O O (A nálisis O rien tad o a O b jeto s) se basa en con cep to s que ya aprendim os en la guardería: o b je
tos y atributos, clases y m iem bros, to d o s y partes. E l porqué n o s ha llevado tan to tiem p o a p lic ar estos c o n
ceptos al análisis y especificación de sistem as es algo que nadie sabe a cie n cia cierta...
E l A O O s e b a s a e n u n c o n ju n t o d e p r in c ip io s b á s ic o s q u e s e in t r o d u je r o n e n e l C a p ítu lo 11 .
P a r a c o n s t r u ir u n m o d e lo d e a n á lis is s e a p lic a n c in c o p r in c ip io s b á s ic o s : ( 1 ) s e m o d e la e l d o m i
n i o d e la in f o r m a c ió n ; ( 2 ) s e d e s c r ib e la f u n c ió n ; ( 3 ) s e r e p r e s e n ta e l c o m p o r t a m ie n t o d e l m o d e
lo ; ( 4 ) lo s m o d e lo s d e d a t o s , f u n c i o n a l y d e c o m p o r t a m ie n t o s e d i v i d e n p a r a m o s t r a r m á s d e t a lle s ;
y ( 5 ) lo s m o d e lo s in ic ia l e s r e p r e s e n t a n la e s e n c ia d e l p r o b le m a m ie n t r a s q u e lo s U lt im o s a p o r -
t a n 'd e t a lle s d e la im p le m e n t a c ió n . E s t o s p r i n c ip i o s f o r m a n la b a s e p a r a e l e n f o q u e d e l A O O
p r e s e n ta d o e n e s e c a p ít u lo .
VISTAZO RÁPIDO
¿ Q u é es? Antes d e q u e pueda construir un ¿P or qué es im portante? No se puede tra sla d a la in ío rm aáó c d e l o ta m M d e
sistem a orien tad o a objetos, tien e q u e construir softw are (o rien tad o s objetos o uso.a u n a representación d e laBciaMB-y
definir la s clases (obletos) q ue represen de otro tipo) h a sta que se tien e un cono sus colaboraciones con la s otras ciases.
ta n el problem a a resolver, la form a e n cim iento ra zo n a b le d el siste m a o pro Las características estáticas y dinám icas
que la s c la s e s s e relacio n an e interac- ducto. El AOO nos proporciona u n a forma d e la s c la se s se m odelan entonces utili
tú a n u n a s con otras, el funcionam iento concreta d e re p re se n tar e l conocim iento zando u n lenguaje d e m odelado unifica
interno (atrib u to sy operaciones) d e l os d e los requiáitos y u n a form a d e probca do o cualquier otro métcxlo.
objetos y los m ecanism os d e com unica dicho conocim ientoenfaentándolo con la ¿ C u á l e s e l p r o d u c t o p b t e n i d o ? Se
ción (m ensajes)que los perm iten trab a - percepción q u e el cliente tiene del siste c re a u n m odelo d e a n á lis is o rie n ta d o
jarjuntos. Todas e s t a s cosas se cum plen m a a cxnstm ir. . a objetos. Dicho m odelo se com pone d e
en el a n á lisis orientado a objetos. ¿ C u á l e s m t e s p a s a * ? El AOO com ien u n a re p re se n ta c ió n g ráfica, o b a s a d a
¿ Q u ié n lo h u s e ? La definición d e un mode za con u n a descripción d e c aso s d e uso, e n el len g u a je, q u e d efine los a trib u to s
lo d e a n á lis is llev a im plícita u n a d e s q u e e s u n a descripción d e e sc e n a rio s d é l a c la se , 1a s re la c io n e s y co m porta
cripción d e la s c aracterísticas d e la s sobre cómo interactúan los actores (gen m ie n to s y l a s c o m u n ic a c io n e s e n tre
c la se s q u e d escriban u n sistem a o pro te, m áquinas u otros sistem as) con el s is c la s e s , a s í com o u n a r e p re s e n ta c ió n
ducto. L a a ctividad la r e a l i i u n in g e te m a a construir. El m odelo d e c la s e s - d e l com p o rtam ien to d e la c la s e e n e l
niero del software. re s p o n sa b ilid a d -c o la b o ra c ió n (CRC) tiem po.
E l p r o p ó s i t o d e l A O O e s d e f i n i r t o d a s la s c la s e s q u e s o n r e l e v a n t e s a l p r o b l e m a q u e s e v a a
r e s o l v e r , la s o p e r a c i o n e s y a t r i b u t o s a s o c i a d o s , la s r e l a c i o n e s y c o m p o r t a m i e n t o s a s o c ia d a s c o n
e l l a s . P a r a c u m p l i r l o s e d e b e n e j e c u t a r la s s i g u i e n t e s t a r e a s :
1. L o s r e q u is it o s b á s ic o s d e l u s u a r io d e b e n c o m u n ic a r s e e n tr e e l c lie n t e y e l in g e n ie r o d e l
s o ftw a re .
2 . I d e n t i f i c a r la s c la s e s ( e s d e c i r , d e f i n i r a t r i b u t o s y m é t o d o s ) .
3 . S e d e b e e s p e c i f i c a r u n a j e r a r q u í a d e c la s e s .
www.FreeLibros.org
4 . R e p r e s e n t a n la s r e l a c i o n e s o b j e t o a o b j e t o ( c o n e x i o n e s d e o b j e t o s ) .
5 . M o d e la r e l c o m p o r t a m ie n t o d e l o b je t o .
6 . R e p e t i r i t e r a t i v a m e n t e la s t a r e a s d e l a 1 a l a 5 h a s t a c o m p l e t a r e l m o d e l o .
36Z
INGE NIE RI A DEL SO FTW A RE. UN E N F O Q U E P R Á C T IC O
Es im portante observar que no existe un acuerdo universal sobre los «conceptos» que sirven de base para el A O O ,
pero un lim itado núm ero de ideas clave se repten a m enudo, y son éstas las que co n siderarem osen este capítulo.
o r ie n t a d o a o r e e t o s ______________________________ '
El ob jetiv o del análisis orientado a objetos es d esarro El método de Booch. El m étodo de B ooch [B 0 0 9 4 ]
llar u n a serie de m odelos que d escriban el softw are de abarca un «m icroproceso de desarrollo» y un «m acro-
com putadora al trab ajar p ara satisfacer un conjunto de proceso de desarrollo». El nivel m icro define un conjunto
requisitos definidos p o r el cliente. E l A O O , co m o los de tareas de análisis que se reaplican en cada etapa en el
m étodos de análisis convencional descritos en el C apí m acro proceso. P or esto se m antienen un enfoque ev o
tulo 12, fo rm a n u n m odelo de análisis m ultiparte para lutivo. El m icro proceso de desarrollo identifica clases y
sa tisfa c e r este o bjetivo. El m o d elo de an álisis ilustra objetos y la sem ántica de dichas clases y objetos, define
inform ación, fu ncionam iento y com portam iento dentro las relaciones entre clases y objetosy realiza una serie de
del c o n te x to d e los elem en to s del m o d elo de o bjetos refin am ien to sp ara elaborar el m odelo del análisis.
descrito en el C apítulo 20.
21.1.1. E nfoques co n v en cio n a les y en foq u es OO

•L . w ti del trabajo con objetos
¿Es el análisis orientado a objetos realm ente diferente del mación como
enfoque del análisis estructurado p resentado en el C apí ^fepséfflocSSn.
tulo 12? A unque el debate continúa, F ic h m a n y Kem e-
rer [FIC92] resp o n den a la pregunta directam ente:
C oncluim os que el enfoque del análisis orientado a obje El método de Rumbaugh. R um baugh [RU M 91] y
tos... representa un cam bio radical sobre las m etodologías orien
sus co leg as d e sarro llaro n la T écnica de M o d e la d o de
tadas a procesos, tales com o el an álisisestructurado.pero sólo
un cam bio increm ental respecto a las m etodologías orientadas O bjetos (O M T ) para el an álisis, d iseño del sistem a y
a datos, tales com o la ingeniería de la inform ación. L as m eto diseño a nivel de objetos. L a actividad de análisis crea
dologías orientadas a procesos desvían la atención de las prio tres m odelos: el m odelo de objetos (una representación
ridades inherentesa los objetos durante el proceso de m odelado de o b jeto s, clases, je ra rq u ía s y relac io n es), el m odelo
y conducen a un m odelo del dom inio del problem a ortogonal dinám ico (una representación del com portam iento del
con los tres principios esenciales de la orientación a objetos:
sistem a y los objetos) y el m odelo funcional (una repre
encapsulam iento, clasificaciónde objetos y herencia.
sentación a alto nivel del flujo de inform ación a través
D icho sim plem ente,el análisis estructuradotom a una del sistem a sim ilar al DFD).
v isió n d iferen te de los requisitos del m o d elo entrada- El método de Jacobson. T am bién llam ad o O O SE
proceso-salida. Los datos se co nsideran separadam ente (en español Ingeniería del Softw are O rientada a O bje
de los procesos que los transform an. El co m p o rtam ien tos), el m étodo de Jacobson [JAC92] es una versión sim
to del sistem a, aunque im portante, tiende a d esem peñar plificada de O bjectory, un m étodo patentado, tam bién
un pap el secundario en el análisis estructurado. El aná desarrollado p o r Jacobson. Este m étodo se diferencia de
lisis estructurado hace u n fuerte uso de la d esco m posi los otros p o r la im portancia que da al caso de uso - u n a
ción funcional (p artición del d iagram a de flujo de datos, d escripción o escen ario que describ e có m o el usuario
C apítulo 12). interactúa con el producto o sistem a— .
El método de Coad y Yourdon. El m étodo de Coad
21.1.2. El panoram a del AOO y Y ourdon [C O A 91] se considera, con frecuencia, como
L a po p u larid ad de las tecnologías de objetos ha g en e uno de los m éto d o s del A O O m ás sen cillos de apren
rado docenas de m étodos de A O O desde finales de los der. La notación del m odelado es relativam ente simple
80 y d u ran te los 90'. C ada uno de ello s in tro d u ce un y las reglas para desarrollar el m odelo de análisis son
p ro ceso p a ra el an álisis de un p roducto o sistem a, un evidentes. A continuación sigue una descripción re su
conjunto de m odelos que ev oluciona fuera del proceso, m ida del proceso de A O O de C oad y Yourdon:
y una n o tació n que posib ilita al ingeniero del softw are • Identificar objetos,usando el criterio de «qué buscar».
crear cada m odelo de una m anera consistente. E ntre los . D efin ir una estru ctu ra de g e n e ra liz ac ió n -e sp e c ifi
m ás am pliam ente utilizados se encuentran': cación.
1La discusión detallada de estos m étodos y su s diferencias esta fuera 2 En general, los m étodos de AOO se identifican usando el (o los)
del alcance en este libro. A dem ás, la industria se m ueve hacia una nombre(s) del desarrollador del m étodo, incluso si al m étodo se le
www.FreeLibros.org
form a de m odelado unificada en un único m étodo, lo que hace que ha dado un nom bre o acrónim o único
las discusiones sobre los antiguos m étodos sólo ten g a n sentido a
e fectos históricos. El lector interesad o puede co n su ltar a Berard
[BER92] y G raham [GRA94J para una com paración m ás detallada.
362
CAPÍTULO 21 A NÁ LISIS O R IE N TA D O A O B JE T O S
• D efin ir u n a estru ctu ra de todo-parte. 21.1.3. U n e n f o q u e u n if ic a d o p a r a e l A O O

• Iden tificar tem as (representaciones de com ponentes A l fin a l d e la p a s a d a d é c a d a , G ra d y B o o c h , J a m e s R u m
de subsistem as). b a u g h e I v a r J a c o b s o n e m p e z a r o n a c o la b o r a r p a r a c o m
• D efin ir atributos. b i n a r y r e c o p i l a r la s m e j o r e s c a r a c t e r í s t i c a s d e c a d a u n o
• D efin ir servicios. d e s u s m é t o d o s d e d is e ñ o y a n á lis is o r ie n t a d o a o b je t o s
e n u n m é to d o u n if ic a d o . E l r e s u lta d o , d e n o m in a d o L e n
El m é to d o d e W irfs -B ro c k . E l m é to d o de W irfs- g u a je d e M o d e la d o U n if ic a d o ( U M L ) , s e h a c o n v e r t i d o
B rock [W IR90] n o hace u n a distinción clara entre las e n e l m é to d o m á s u t iliz a d o p o r la in d u s tr ia 3 .
tareas de análisis y diseño. E n su lugar, propone un p ro
ceso continuo que com ien za co n la v alo ración de una
e sp e c ific ac ió n del clien te y te rm in a co n el diseño. A O S fr o
co ntinuación se esbozan b revem ente las tareas relacio I fg ic u é ) algunos de tos notaciones
nadas con el análisis de W irfs-B rock: oteando así un único punto de referencia
• E v alu ar la especificación del cliente. . conceptos importantes.
• U sar un análisis g ram atical p ara e x tra e r clases can-
didatas de la especificación.
• A grupar las clases en un intento de d eterm inar super- U M L p e r m it e a u n in g e n ie r o d e l s o ftw a r e e x p r e s a r
clases. u n m o d e lo d e a n á lis is u t iliz a n d o u n a n o t a c ió n d e m o d e
• D efinir responsabilidades p ara ca d a clase. la d o c o n u n a s r e g la s s in tá c tic a s , s e m á n tic a s y p r á c tic a s .
• A sig n ar responsabilidades a ca d a clase. E r ik s s o n y P e n k e r [ E R I 9 8 ] d e f in e n d ic h a s r e g la s d e la
• Iden tificar relaciones en tre clases. s ig u ie n te fo r m a : ,
• D efinir colaboraciones entre clases basándose en sus L a sintaxis nos dice có m o m o strar y co m b in ar los sím
responsabilidades. bolos. L a sintaxis es com parable a las palabras en el lenguaje
natural: es im p o rtan te saber cóm o se escriben y cóm o com
• C onstruir rep resentacionesjerárquicas de clases para b in a rla s c o rre c ta m e n te p a ra fo rm a r una frase. L as re g ia s
m o strar relaciones de herencia. sem ánticas nos dicen lo que significa cada sím bolo y cóm o
• C onstruir un grafo de colab o racio n esp ara el sistema. interpretarlo, tanto cuando aparece solo com o cuando lo hace
en com binación con otros. E s com p arab le al significado de
A unque la term inologíay etapas del proceso para cada las palabras en el lenguaje natural.
uno de estos m étodos de A O O difieren, los procesos gene
L as reglas prácticas definen el significado de los sím bolos
rales de AO O son en realidad m uy sim ilares. Para reali a trav é s de los cuales se o btiene el m odelo y se hace c o m
zar un análisis o rien tad o a objetos, u n ingeniero del prensible para otras personas. E sto correspondería, en lengua
software debería ejecu tar las siguientes etapas genéricas: je n atural, a las reg ias de c o n stru cció n d e frases claras y
1. O btener los requisitos del cliente p ara el sistem a. fácilm ente com prensibles.
2. Iden tificar escenarios o casos de uso. E n U M L , u n s is t e m a v ie n e r e p r e s e n t a d o p o r c in c o

3. Seleccionar clases y o b jeto s u sando los re q u isito s v is t a s d if e r e n t e s q u e l o d e s c r ib e n d e s d e d if e r e n t e s p e r s
básicos co m o guías. p e c tiv a s . C a d a v is t a s e r e p r e s e n ta m e d ia n te u n c o n ju n
4. Identificar atributos y o peraciones p ara cada objeto t o d e d i a g r a m a s . E n U M L e s t á n p r e s e n t e s la s s i g u i e n t e s
del sistem a. v is t a s [ A L H 9 8 ] :
5. D efin ir estru c tu ra s y je ra rq u ía s que o rg an icen las V is ta d e l u s u a r io . R e p r e s e n t a e l s is t e m a ( p r o d u c t o )
clases. d e s d e la p e r s p e c t iv a d e lo s u s u a r io s ( lla m a d o s a c to r e s
6. C onstruir un m odelo objeto-relación. e n U M L ) . E l c a s o d e u s o e s e l e n fo q u e e le g id o p a ra
7. C onstruir un m odelo objeto-com portam iento. m o d e la r e s ta v is t a . E s ta im p o r t a n t e r e p r e s e n ta c ió n d e l
a n á lis is , q u e d e s c r ib e u n e s c e n a r io d e u s o d e s d e la p e r s
8. R evisar el m odelo de análisis O O con relación a los
p e c t iv a d e l u s u a r io f in a l, s e d e s c r ib ió e n e l c a p í t u lo l l 4.
casos de uso/escenarios.
V i s t a e s t r u c t u r a l : lo s d a t o s y l a f u n c i o n a l i d a d s e
Estas etapas genéricas se tratan en m ay o r detalle en
m u e s t r a n d e s d e d e n t r o d e l s is t e m a , e s d e c ir , m o d e la la
las Secciones 21.3 y 21.4.
e s t r u c t u r a e s tá t ic a ( c la s e s , o b je t o s y r e la c io n e s ) .
\) V E Conv en todos los enfoques de análisis, b obtención

Durante el AOO se aplico un conjunto genérico de pasos, de requisitos es lo clave. Asegúrese de que obtiene
Independientemente del método de análisis elegido. b vista correcta del usuario. El resto saldrá solo.
www.FreeLibros.org
3 Booch, R um baugh y Ja co b so n han publicado una trilogía fu n d a 4 Si aún no lo ha hecho, lea por favor la discusión sobre los casos de
mental de libros sobre UML. El lector interesad o puede co n su ltar uso de la Sección 11.2.4.
[B0099], [RUM99] y [JAC99].
363
INGENIERÍA DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
V is t a d e l c o m p o r t a m i e n t o : e s t a p a r t e d e l m o d e l o d e l V i s t a d e i m p l e m e n t a c i ó n ', l o s a s p e c t o s e s t r u c t u r a l e s
a n á lis is r e p r e s e n ta lo s a s p e c to s d in á m ic o s o d e c o m y d e c o m p o r ta m ie n to se r e p r e s e n ta n a q u í ta l y c o m o v a n
p o r t a m i e n t o d e l s i s t e m a . T a m b i é n m u e s t r a la s i n t e r a c a s e r im p le m e n t a d o s .
c io n e s o c o la b o r a c io n e s e n tr e lo s d iv e r s o s e le m e n to s
V is t a d e l e n t o r n o : a s p e c t o s e s t r u c t u r a le s y d e c o m
e s t r u c t u r a l e s d e s c r i t o s e n la s v i s t a s a n t e r i o r e s .
p o r t a m ie n t o e n e l q u e e l s is t e m a a im p le m e n t a r s e r e p r e
s e n ta .
E n g e n e r a l, e l m o d e lo d e a n á lis is d e U M L s e c e n tr a
Referencia Web e n la s v i s t a s d e l u s u a r i o y e s t r u c t u r a l . E l m o d e l o d e d i s e
Bimini.net/cetus/oo_uml.html hay un amplio ñ o d e U M L ( tr a ta d o e n e l C a p ítu lo 2 2 ) se d ir ig e m á s a
tutorial y una lista de recursos UML que Incluye la s v i s t a s d e l c o m p o r t a m i e n t o y d e l e n t o r n o . E n e l C a p í
herramientas, artículos y ejemplos. t u lo 22 d e s c r ib ir e m o s U M L c o n m á s d e ta lle .
lo
E l a n á lis is e n s is t e m a s o r ie n t a d o s a o b je t o s p u e d e o c u la n e c e s id a d d e 1 0 0 c la s e s . S e le a s ig n a a d o s e q u ip o s
r r i r a m u c h o s n iv e le s d if e r e n t e s d e a b s tr a c c ió n . A n i v e l la ta r e a d e c o n s t r u ir la a p lic a c ió n . C a d a u n o d e b e d is e
d e n e g o c i o s o e m p r e s a s , la s t é c n i c a s a s o c ia d a s c o n e l ñ a r y c o n s tr u ir u n p r o d u c to f in a l y , a s u v e z , e s tá c o m
A O O p u e d e n a c o p la r s e c o n u n e n f o q u e d e in g e n ie r í a p u e s to d e p e rs o n a s c o n e l m is m o n iv e l d e h a b ilid a d y
d e la in f o r m a c ió n ( C a p í t u lo 1 0 ) e n u n e s fu e r z o p o r d e f i e x p e r ie n c ia .
n i r c la s e s , o b je t o s , r e la c io n e s y c o m p o r t a m ie n t o s q u e
m o d e le n e l n e g o c io p o r c o m p le t o . A n i v e l d e á re a s d e
n e g o c io s , p u e d e d e f in ir s e u n m o d e lo d e o b je t o s q u e d e s ^P O N SE JO ^.
c r ib a e l tr a b a jo d e u n á re a e s p e c íf ic a d e n e g o c io s ( o u n a
c a t e g o r í a d e p r o d u c t o s o s i s t e m a s ) . A n i v e l d e la s a p l i Otros beneficios derivados déla reutilización son
c a c io n e s , e l m o d e lo d e o b je t o s s e c e n tr a e n lo s r e q u is i
del software serán más consistentes, tendiendo
to s e s p e c íf ic o s d e l c lie n t e , p u e s é s to s a f e c t a n a la
o facilitar el mantenimiento del producto. Asegúresede
a p lic a c ió n q u e se v a a c o n s tr u ir .
establecer un conjunto de reglas de reutilización
poro conseguir dichos objetivos.
CLAVE
E l e q u ip o A n o tie n e a c c e s o a u n a b ib lio t e c a d e c la
£I objetivodel análisis del dominio es definir el conjunto
s e s , p o r l o q u e d e b e d e s a r r o l l a r la s 1 0 0 c la s e s d e s d e
de clases (objetos) que se encuentran en el dominio de
e l p r i n c i p i o . E l e q u i p o B u s a u n a b i b l i o t e c a d e c la s e s
la aplicación. Dichas clases podrán re u É im e muchas veces.
r o b u s t a y e n c u e n t r a q u e y a e x i s t e n 5 5 c la s e s . S e g u r o
que:
E l A O O , e n s u n iv e l d e a b s tr a c c ió n m á s a lt o ( e l n iv e l
1 . E l e q u ip o B f in a liz a r á e l p r o y e c t o m u c h o a n te s q u e
d e e m p r e s a ) , e s tá m á s a llá d e l a lc a n c e d e e s te lib r o . L o s
elA.
le c t o r e s in t e r e s a d o s d e b e r í a n v e r a [ E E L 9 8 ] , [ C A R 9 8 ] ,
[ F I N 9 6 ] , [ M A T 9 4 ] , [ S U L 9 4 ] y [ T A Y 9 5 ] , lo s c u a le s 2 . E l c o s te d e l p r o d u c to d e l e q u ip o B s e rá s ig n if ic a t i
h a c e n u n a n á lis is m á s d e ta lla d o . A n iv e l d e a b s tr a c c ió n v a m e n te m á s b a jo q u e e l c o s te d e l p r o d u c to d e l
m á s b a jo , e l A O O c a e d e n t r o d e l a lc a n c e g e n e r a l d e la e q u ip o A .
in g e n ie r í a d e l s o ftw a r e o r ie n t a d o a o b je t o s y e s e l c e n 3. L a v e r s i ó n q u e s e d i s t r i b u y a d e l p r o d u c t o p r o d u c i d o
t r o d e a t e n c i ó n d e l r e s t o d e la s s e c c i o n e s d e e s t e c a p í p o r e l e q u ip o B te n d r á m e n o s d e fe c to s q u e la d e l p r o
t u lo . E n e s ta s e c c ió n n o s c e n tr a r e m o s e n e l A O O q u e d u c t o d e l e q u ip o A .
s e r e a liz a a u n n iv e l m e d io d e a b s tr a c c ió n . E s ta a c t iv i
A u n q u e e l m a r g e n p o r e l c u a l e l tr a b a jo d e l e q u ip o
d a d , lla m a d a a n á lis is d e l d o m in io , t ie n e lu g a r c u a n d o
B e x c e d e r á a l d e l A e s tá a b ie r t o a d e b a te , p o c o s a r g u
u n a o r g a n iz a c ió n d e s e a c r e a r u n a b i b li o t e c a d e c la s e s
m e n ta r á n q u e la r e u s a b ilid a d a p o r ta u n a v e n t a ja s u b s
r e u t iliz a b le s ( c o m p o n e n te s ) a m p lia m e n t e a p lic a b le s a
t a n c ia l a l e q u ip o B .
u n a c a t e g o r ía c o m p le t a d e a p lic a c io n e s .
¿ P e r o d e d ó n d e v i n o l a « b i b l i o t e c a d e c la s e s r o b u s
t a » ? ¿ Y c ó m o s e d e t e r m i n ó q u e la s e n t r a d a s d e l a b i b l i o
21.2.1. A n á l i s i s d e r e u t i l i z a c i ó n y d e l d o m in io t e c a e r a n a p r o p ia d a s p a r a s u u s o e n n u e v a s a p lic a c io n e s ?
www.FreeLibros.org
L a s t e c n o lo g ía s d e o b je t o s e s tá n in f lu e n c ia d a s p o r la P a r a r e s p o n d e r e s ta s p r e g u n ta s , la o r g a n iz a c ió n q u e c re ó
r e u t iliz a c ió n . C o n s id e r e u n e je m p lo s im p le . E l a n á li y m a n t u v o d ic h a b ib lio t e c a t u v o q u e a p lic a r e l a n á lis is
s is d e l o s r e q u i s i t o s p a r a n u e v a s a p l i c a c i o n e s i n d i c a n d e l d o m in io .
364
CAPÍTULO 21 A N Á LI S IS O R I E N T A D O A O B J E T O S
21.2.2. El p r o c e s o d e a n á l i s i s d e l d o m in io
F ir e s m it h [ F I R 9 3 ] d e s c r ib e e l a n á lis is d e l d o m i n io d e l
s o ftw a r e d e la s ig u ie n te m a n e r a : j¡ É o? s p quera hacer una inversión
El análisis del dominio del software es la identificación, " M ilu t e a t e c ió n de software, necesita
análisis y especificación de requisitos comunes de un domi i componentes a considerar
nio de aplicación específico, normalmente para su reutili
# e f rfasarraite de un modelo de ese tipo.
zación en múltiples proyectos dentro del mismo dominio
de aplicación ... (el análisis orientado a objetos del domi ü ft?
nio es la identificación, análisis y especificación de capa
cidades comunes y reutilizables dentro de un dominio de
aplicación específico, en términos de objetos, clases, sub- L a F i g u r a 2 1 . 1 [ A R A 8 9 ] i l u s t r a la s e n t r a d a s y s a l i
montajes y marcos de trabajo comunes... d a s c la v e p a r a e l p r o c e s o d e a n á lis is d e l d o m in io . S e e x a
E 1 « d o m in io d e a p lic a c io n e s e s p e c íf ic o » p u e d e m i n a n la s f u e n t e s d e l d o m i n i o d e c o n o c i m i e n t o e n u n
v a r ia r d e s d e a v ió n ic a h a s ta b a n c a , d e s d e ju e g o s d e in t e n t o d e id e n t if ic a r o b je t o s q u e s e p u e d a n r e u t il iz a r a
v íd e o m u lt im e d ia h a s ta a p lic a c io n e s d e n tr o d e u n e s c á l o la r g o d e t o d o e l d o m in io . E n e s e n c ia e l a n á lis is d e l
n e r CAT. E l o b j e t i v o d e l a n á l i s i s d e l d o m i n i o e s c l a d o m in io e s m u y s im ila r a la in g e n ie r í a d e l c o n o c im ie n
r o : e n c o n t r a r o c r e a r a q u e lla s c la s e s a m p lia m e n t e to . E l in g e n ie r o d e l c o n o c im ie n t o in v e s t ig a u n á re a d e
a p lic a d a s , d e t a l m a n e r a q u e s e a n r e u t il iz a b le s . in t e r é s e s p e c í f i c a , i n t e n t a n d o e x t r a e r h e c h o s c l a v e s q u e
s e p u e d a n u s a r p a r a la c o n s t r u c c ió n d e u n s is t e m a e x p e r
t o o u n a r e d n e u r o n a 1 a r t if ic ia l. D u r a n t e e l a n á lis is d e l
á.iiiJjjjJiJjjiu.M.fc d o m i n i o o c u r r e l a e x t r a c c i ó n d e o b j e t o s ( y c la s e s ) .
La reutilización es lo piedra angular de la ingeniería D efinir el dom inio a investigar. P a r a l l e v a r a c a b o
del software basada en componentes, tema que se e s ta ta r e a , e l a n a lis ta d e b e p r im e r o a is la r e l á re a d e n e g o
c io , t i p o d e s is t e m a o c a t e g o r í a d e l p r o d u c t o d e in t e r é s .
A c o n t in u a c ió n , s e d e b e n e x t r a e r lo s « e le m e n to s » ta n t o
0 0 c o m o n o 0 0 . L o s e le m e n to s 0 0 in c lu y e n e s p e c if i
U s a n d o la t e r m in o lo g í a in t r o d u c id a a l in ic io d e l c a c i o n e s , d i s e ñ o s y c ó d i g o p a r a c la s e s d e a p l i c a c i o n e s
lib r o , e l a n á lis is d e l d o m in io p u e d e v e r s e c o m o la a c t i 0 0 y a e x i s t e n t e s ; c l a s e s d e s o p o r t e ( p . e . : c la s e s d e l n t e r -
v id a d d e c o b e r tu r a p a r a e l p r o c e s o d e l s o ftw a r e . C o n f a z G r á f i c a d e U s u a r io o c la s e s d e a c c e s o a b a s e s d e
e s to q u e r e m o s d e c ir q u e e l a n á lis is d e l d o m in io e s u n a d a to s ) ; b ib lio t e c a s d e c o m p o n e n te s c o m e r c ia le s y a d e s a
a c tiv id a d e n c u r s o d e la in g e n ie r í a d e l s o ftw a r e n o r r o lla d a s (C Y D ) r e le v a n te s a l d o m i n io y c a s o s d e p r u e b a .
lig a d a a n in g ú n p r o y e c to d e s o ftw a r e . E n c ie r ta f o r L o s e le m e n to s n o 0 0 a b a r c a n p o lític a s , p r o c e d im ie n
m a , e l p a p e l d e u n a n á lis is d e l d o m in io e s s im ila r a l to s , p la n e s , e s tá n d a r e s y g u ía s ; p a r te s d e a p lic a c io n e s n o
d e u n m a e s tro to r n e r o d e n tr o d e u n e n to r n o d e fa b r i 0 0 ( in c lu y e n d o e s p e c if ic a c ió n , d is e ñ o e in f o r m a c ió n d e
c a c ió n fu e r te . E l tr a b a jo d e l m a e s tr o to r n e r o e s d is e p r u e b a ) , m é tr ic a s y C Y D d e l s o ftw a r e n o O O .
ñ a r y c o n s tr u ir h e r r a m ie n ta s q u e p u e d e n u s a rs e p o r C lasificar los elem entos extraídos del dom inio. L o s
v a r ia s p e r s o n a s q u e t r a b a ja n e n a p lic a c io n e s s i m i l a e l e m e n t o s s e o r g a n i z a n e n c a t e g o r í a s y s e e s t a b l e c e n la s
r e s , p e r o n o n e c e s a r ia m e n t e id é n t ic a s . E l p a p e l d e l c a r a c t e r í s t ic a s g e n e r a le s q u e d e f in e n la c a te g o r ía . S e
a n a lis ta d e l d o m in io e s d is e ñ a r y c o n s t r u ir c o m p o p r o p o n e u n e s q u e m a d e c la s if ic a c ió n p a r a la s c a t e g o
n e n te s r e u t iliz a b le s q u e p u e d a n s e r u t iliz a d o s p o r d if e r ía s y s e d e f in e n c o n v e n c io n e s p a r a la n o m e n c la t u r a d e
r e n te s p e r s o n a s q u e tr a b a ja n e n a p lic a c io n e s s im ila r e s c a d a e le m e n to . S e e s t a b le c e n je r a r q u í a s d e c la s if ic a c ió n
p e r o n o n e c e s a r ia m e n te ig u a le s . e n c a s o d e s e r a p r o p ia d o .
Literatura técnica
Taxonom ía de clases
Aplicaciones existentes \ ►
\ Estándar de reusabilidad M odelo
Recursos del cliente Análisis 1 ► del
del dominio 1 Modelos funcionales
Consejo de experto análisis
m Lenguajes del dom inio del
Requisitos actuales/futuros W * dom inio
www.FreeLibros.org
FIGURA 2 1 .1 . Entrada y salida para an álisis del d om in io.
365
caaamgga
Una estrategia completa del modele del anáfisis debe
A d e m á s , u n a v e z q u e s e h a n d e f in id o lo s o b je t o s , e l
a n a lis ta d e b e e s tim a r q u é p o r c e n ta je d e u n a a p lic a c ió n
t í p ic a p u d ie r a c o n s tr u ir s e u s a n d o lo s o b je t o s r e u tiliz a b le s .
considerar tanto la arquitectura como ios componentes.
En el Capítulo 14 hay una confíela discusión sobre D e s a r r o lla r u n m o d e lo d e a n á lis is p a r a los o b je
to s. E l m o d e l o d e a n á l i s i s s e r v i r á c o m o b a s e p a r a e l
d is e ñ o y c o n s t r u c c ió n d e lo s o b je t o s d e l d o m in io .
R e c o le c ta r u n a m u e s tr a r e p r e s e n ta tiv a d e a p lic a A d ic io n a lm e n t e a e s ta s e ta p a s , e l a n a lis ta d e l d o m i

c io n e s e n el d o m in io . P a r a r e a l i z a r e s t a t a r e a , e l a n a n i o t a m b ié n d e b e c r e a r u n c o n ju n t o d e lí n e a s m a e s tr a s
lis t a d e b e a s e g u r a r q u e la a p lic a c ió n e n c u e s tió n tie n e p a r a la r e u t iliz a c ió n , y d e s a r r o lla r u n e je m p lo q u e ilu s
e l e m e n t o s q u e c a e n d e n t r o d e la s c a t e g o r í a s y a d e f i n i tr e c ó m o lo s o b je t o s d e l d o m in io p u d ie r a n u s a rs e p a r a
d a s . B e r a r d [ B E R 9 3 ] o b s e r v a q u e d u r a n t e la s p r i m e r a s c r e a r u n a a p lic a c ió n n u e v a .
e t a p a s d e u s o d e la s t e c n o l o g í a s d e o b j e t o s , u n a o r g a E l a n á lis is d e l d o m in io e s la p r im e r a a c t iv id a d t é c
n iz a c ió n d e l s o ftw a r e te n d r á m u y p o c a s , s i h a y a lg u n a , n i c a e n u n a a m p l i a d i s c i p l i n a q u e a l g u n o s l l a m a n in g e
a p lic a c io n e s O O . D e b id o a e s to , e l a n a lis ta d e d o m in io n ie ría d el d o m in io . C u a n d o u n n e g o c i o , s i s t e m a o
d e b e « id e n t if ic a r lo s o b je t o s c o n c e p tu a le s ( o p u e s to s a p r o d u c to d e l d o m in io e s d e f in id o c o m o e s tr a té g ic o a
lo s f í s ic o s ) e n c a d a a p lic a c ió n [n o 0 0 ] » . la r g o p la z o , p u e d e d e s a r r o lla r s e u n e s f u e r z o c o n t in u a
d o p a r a c r e a r u n a b ib lio t e c a r e u t iliz a b le r o b u s t a . E l o b je
A n a liz a r c a d a a p lic a c ió n d e n tr o d e la m u e s tr a . E l
t iv o e s s e r c a p a z d e c r e a r s o ftw a r e d e n tr o d e l d o m in io
a n a l i s t a d e b e s e g u i r la s e t a p a s s i g u i e n t e s [ B E R 9 3 ] :
c o n u n a lt o p o r c e n ta je d e c o m p o n e n te s r e u t iliz a b le s .
• I d e n t if ic a r o b je t o s c a n d id a to s r e u t iliz a b le s . A r g u m e n t o s a f a v o r d e u n e s f u e r z o d e d ic a d o a la in g e
• I n d i c a r la s r a z o n e s q u e h a c e n q u e e l o b j e t o h a y a s i d o n ie r í a d e l d o m in io s o n : b a jo c o s te , m a y o r c a lid a d y
id e n t if ic a d o c o m o r e u t iliz a b le . m e n o r tie m p o d e c o m e r c ia liz a c ió n .
• D e f i n i r a d a p t a c io n e s a l o b je t o q u e t a m b i é n p u e d e n
s e r r e u tiliz a b le s .
• E s t im a r e l p o r c e n ta je d e a p lic a c io n e s e n e l d o m in io R e fe re n d a jj
q u e p u e d e n r e u t il iz a r e l o b je t o .
Biwww.sei.cmu.edu/str/descriptions/deda.html
• I d e n t if ic a r lo s o b je t o s p o r n o m b r e y u s a r té c n ic a s d e hoy un tutorial sobre análisis del dominio que merece la peno.
g e s tió n d e c o n f ig u r a c ió n p a r a c o n tr o la r lo s ( C a p í tu lo 9 ).
21.3 .CQMPQNENTES GENjÉRÍCQS DEL MQDEI.Ó BE fiÑ Á tlSIS 6 0 i .
E l p r o c e s o d e a n á lis is o r ie n t a d o a o b je t o s s e a d a p ta a c o m p o n e n te s d e r e p r e s e n ta c ió n g e n é r ic o s q u e a p a re
c o n c e p to s y p r in c ip io s b á s ic o s d e a n á lis is d is c u t id o s e n c e n e n t o d o s l o s m o d e l o s d e a n á l i s i s O O 5 . L o s co m p o
e l C a p ítu lo 1 1 . A u n q u e la t e r m in o lo g í a , n o ta c ió n y a c t i n e n te s e stá tic o s s o n e s t r u c t u r a l e s p o r n a t u r a l e z a , e
v id a d e s d if ie r e n r e s p e c to d e lo s u s a d o s e n m é to d o s c o n in d ic a n c a r a c te r ís tic a s q u e s e m a n t ie n e n d u r a n t e to d a
v e n c io n a le s , e l A O O ( e n s u n ú c le o ) r e s u e lv e lo s m is m o s l a v i d a o p e r a t i v a d e u n a a p l i c a c i ó n . L o s com ponentes
o b je t iv o s s u b y a c e n te s . R u m b a u g h [ R U M 9 1 ] e x a m in a dinám icos s e c e n t r a n e n e l c o n t r o l , y s o n s e n s i b l e s a l
e s to c u a n d o a s e g u ra q u e : tie m p o y a l t r a ta m ie n to d e s u c e s o s . E s to s ú lt im o s d e f i
n e n c ó m o in te r a c tú a u n o b je t o c o n o t r o s a lo la r g o d e l
E l análisis... se ocupa de proyectar un m odelo preciso, c o n
ciso, com prensible y correcto del m undo real. ..E l propósito tie m p o . P u e d e n id e n t if ic a r s e lo s s ig u ie n te s c o m p o n e n
de análisis Orientado a objetos es m odelar el m undo real de for te s [ M O N 9 2 ] :
m a tal que sea com prensible. P ara esto se deben exam inar los
requisitos, analizar las im plicaciones que se deriven de ellos y
V istaestática de clases sem ánticas. U n a t a x o n o m í a d e
reafirm arlos de m anera rigurosa. Se deben abstraer prim ero las c la s e s t í p i c a s s e m o s t r ó e n e l C a p í t u l o 2 0 . S e i m p o n e n lo s
características del m undo real y de ja r los pequeños detalles r e q u i s i t o s y s e e x t r a e n ( y r e p r e s e n t a n ) la s c la s e s c o m o
para m ás tarde. p a r t e d e l m o d e l o d e a n á l i s i s . E s t a s c la s e s p e r s i s t e n a t r a
P a r a d e s a r r o lla r u n « m o d e lo p r e c is o , c o n c is o , c o m v é s d e t o d o e l p e r í o d o d e v id a d e la a p lic a c ió n y s e d e r i
v a n b a s á n d o s e e n l a s e m á n t i c a d e l o s r e q u i s i t o s d e l c lie n t e .
p r e n s ib le y c o r r e c to d e l m u n d o r e a l» , u n in g e n ie r o d e l
s o ftw a r e d e b e s e le c c io n a r u n a n o t a c ió n q u e s e s o p o r
te a u n c o n ju n t o d e c o m p o n e n te s g e n é r ic o s d e A O O . n ¿Cuáles son los componentes
M o n a r c h i y P u h r [ M O N 9 2 ] d e fin e n u n c o n ju n t o d e clave de un modelo de AOO?
www.FreeLibros.org
5 Los autores [MON92] aportan tam bién un análisis de veintitrés méto
dos de AOO e indican cóm o representan éstos dichas com ponentes.
366
C A PIT U L O 21 A N Á L IS IS OR IE N TA DO A O B J E T O S
portam ientos que se adaptan al escenarioutilizado (casos

de uso) del sistem a. E sto s com portam ientos se im ple-
m e n tan a trav és de la d efin ició n de una secu en cia de
Les componentes estáticos no cambian mientras operaciones que los ejecutan.
la aplicación se está ejecutando, las componentes
V ista d in á m ic a de la c o m u n ic a c ió n . L o s o b je to s
dinámicos están ¡nfluencladospor el tiempo y los sucesos.
deben com unicarse unos con otros y hacerlo basándose
en una serie de m ensajes que provoquen transiciones de
Vista está tica de los atributos. T oda clase debe d e s un estad o a otro del sistem a.
cribirse explícitam ente. L os atributos asociados con la Vista dinám ica del control y m anejo del tiempo. D ebe
clase aportan u n a d escripción de la clase, así com o una describirse la naturaleza y duración de los sucesos que
indicación inicial de las o peraciones relevantes a esta provocan transiciones de estados.
clase.
D e C h a m p ea u x y sus colegas [CH A 93] definen una
Vista está tica de las rela cio n es. L os o b jeto s están v ista ligeram ente diferente de las representaciones del
«conectados» unos a otros de varias form as. El m odelo A O O . L a s c o m p o n e n te s e stá tic a s y d in á m ic a s se
de análisis debe rep resen tar las relaciones de m anera tal id e n tific a n p a ra el o b je to in te rn a m e n te y p a ra la s
que p u ed an identificarse las o peraciones (que afecten a rep re sen tacio n e s entre objetos. U n a v ista d in ám ica e
estas c o n ex io n es) y que p u ed a d esarro llarse u n bu en interna del objeto puede caracterizarse com o la h istoria
diseño de in tercam bio de m ensajes. de vid a d el objeto, esto es, los estad o s que alcan za el
Vista está tica de los com portam ientos. L as relacio o b jeto a lo largo del tiem po, al realizarse una serie de
nes indicadas anteriorm ente definen un conjunto de co m operaciones sobre sus atributos.
21.4 EL PR O C E SO DE R O O
El proceso de A O O n o com ienza con un a preocupación ■ p ro p o rc io n a r u n a b a se p a ra la v a lid a c ió n d e la s

por los objetos. M ás b ien com ienza con u n a co m pren pruebas.
sión de la m an era en la que se u sará el sistem a: p o r las
D urante el A O O los casos de uso sirven com o base
personas, si el sistem a es de interacción con el hom bre;
para los prim eros elem entos del m odelo de análisis.
por otras m áq u in as, si el sistem a está e n v u elto en un
U tilizando U M L se puede crear una representación
control de procesos; o p o r otros program as; si el siste
visual de los casos de uso llam ada diagram a de casos
ma co o rd in ay controla otras aplicaciones. U na vez que
de uso. C om o otros elem entos del análisis, los casos de
se ha definido el escenario, com ienza el m odelado del
u so pueden rep re se n tarse a d iferen tes niveles de abs
software.
tracción. L os diagram as de casos de uso contienen casos
Las secciones que siguen d efinen una serie de téc n i
de uso y actores, siendo estos últim os las entidades que
cas que pu ed en usarse p ara reco p ilar requisitos básicos
interactúan con el sistem a. P ueden ser hum anos u otras
del usuario y después definen un m odelo de análisis para
m áquinas o sistem as que tengan definidas interfaces con
un sistem a orientado a objetos.
nuestro sistem a.
21.4.1. Casos de uso

Como exam inam os en el C apítulo 11, los casos de uso
m odelan el sistem a desde el p unto de v ista del usuario. Referencia
Creados durante la obtención de requisitos, los casos de En www.umv-paris 1.fr/CR IN F0/dm rg/M EE/m isop0l 4
uso deben cu m p lir los siguientes objetivos: existe un tutorial que aborda en profundidad los casos de uso.
> definir los requisitos funcionalesy operativos del sis
tem a (producto), diseñando un escenario de uso acor El sistem a de seguridad H ogarSeguro , discutido en
dado p o r el usu ario final, y el equipo de desarrollo; capítulos anteriores, puede usarse para ilustrar cóm o p u e
p ro p o rcio n ar u n a d escripción clara y sin am bigüe den desarrollarse casos de uso. R ecordando los req u isi
dades de có m o el usu ario final in teractúa con el sis to s b ásico s de H o g a rS e g u ro , p o d em o s d e fin ir tres
tem a y viceversa, y actores: el propietario (el usuario), los sensores (dis
positivos adjuntos al sistem a) y el subsistem a de moni-
torización y respuesta (la estac ió n c e n tra l que
ts m E S B m i m onitoriza H o g a rS e g u ro ). Para los propósitos de este
www.FreeLibros.org
los casos de usa son una excelente herramlentade
ejem plo, considerarem os solam ente el actor propietario.
licitoción de requisitos, independientemente del método de
análisis utilizado. Véase el copítulo 11 para más detalle.
La F ig u ra 2 1.2.a m uestra u n d iag ram a de caso s de
uso de alto nivel para el propietario. E n d icha figura
367
I N GE NI E RÍ A DEL S O F TW A R E . UN EN F O Q U E P R Á C T I C O
s e id e n t if ic a n d o s c a s o s d e u s o y s e r e p r e s e n ta n c o n e lip f a c e r e s t a s s e is c a r a c t e r í s t i c a s p a r a p o d e r s e r c o n s i d e
ses. C a d a c a s o d e u s o d e a l t o n i v e l p u e d e d e t a l l a r s e r a d o c o m o p o s ib le m ie m b r o d e l m o d e lo :
m e d ia n te d ia g r a m a s d e c a s o s d e u s o d e n iv e l in f e r io r .
P o r e je m p lo , la F ig u r a 2 1 .2 . b r e p r e s e n ta u n d ia g r a m a 1. retener inform ación: e l o b j e t o p o t e n c i a l s e r á ú t i l
d e c a s o s d e u s o p a r a l a f u n c i ó n interactúa. S e c r e a u n d u r a n te e l a n á lis is s i la in f o r m a c ió n s o b r e e l m is m o
c o n ju n t o c o m p le t o d e d ia g r a m a s d e c a s o s d e u s o p a r a d e b e g u a r d a r s e p a r a q u e e l s is t e m a f u n c io n e
to d o s lo s a c to r e s . P e r o p a r a u n a d e t a lla d a d is c u s ió n s o b r e 2 . Servicios necesarios: e l p o t e n c i a l o b j e t o d e b e t e n e r
lo s c a s o s d e u s o u s a n d o U M L e s m e jo r c o n s u lt a r la u n c o n ju n t o d e o p e r a c io n e s id e n t if ic a b le s q u e p e r
b i b l i o g r a f í a s o b r e e l t e m a (p.e. [ E R I 9 7 ] o [ A L H 9 8 ] ) . m it a n c a m b ia r lo s v a lo r e s d e s u s a t r ib u to s .
3. M últiples atributos: d u r a n t e e l a n á l i s i s d e r e q u i s i t o s
21.4.2. M o d e l a d o d e c la se s-r e sp o n sa b ilid a d e s- n o s c e n tra m o s m á s e n la in f o r m a c ió n m á s im p o r
c o la b o r a c io n e s ta n te . U n o b je t o c o n u n s o lo a t r ib u t o p u e d e , e n e fe c to ,
s e r Ú til d u r a n te e l d is e ñ o , p e r o p r o b a b le m e n te s e rá
U n a v e z q u e s e han d e s a r r o l l a d o lo s e s c e n a r i o s d e u s o
u n a t r ib u t o d e o t r o o b je t o d u r a n t e e l a n á lis is d e a c t i
b á s i c o s p a r a e l s i s t e m a , e s e l m o m e n t o d e i d e n t i f i c a r la s
v id a d e s .
c la s e s c a n d i d a t a s e i n d i c a r s u s r e s p o n s a b i l i d a d e s y c o l a
b o r a c i o n e s . E l m o d e l a d o d e clases-responsabilidades- 4. Atributos comunes: e l c o n j u n t o d e a t r i b u t o s d e f i n i d o
p a r a l a c l a s e d e b e s e r a p l i c a b l e a t o d a s la s o c u r r e n
colaboraciones ( C R C ) [ W 1 R 9 0 ] a p o r t a u n m e d i o s e n c i l l o
d e i d e n t i f i c a r y o r g a n i z a r la s c la s e s q u e r e s u l t e n r e l e v a n t e s c ia s d e l o b je t o .
a l s is t e m a o r e q u is it o s d e l p r o d u c t o . A m b l e r [ A M B 9 5 ]
d e s c r ib e e l m o d e la d o C R C d e la s ig u ie n t e m a n e r a :
HogarSeguro
U n m odelo CRC es realm ente una colección de tarjetas
índice estándar que representan clases. L as tarjetas están divi
didas en tres secciones. A lo largo de la cabecera de la tarjeta
usted escribe el nom bre de la clase. E n el cuerpo se listan las
responsabilidades de la clase a la izquierda y a la derecha los
colaboradores.
Referencia W e b ^ "
Enwww.univ-paris1.fr/CRINFO/iimrg/MEE97/inisop013 (a)
puede consultor uno discusión detalloda de lo técnico de los fórjelas CRC.
E n r e a lid a d , e l m o d e lo C R C p u e d e h a c e r u s o d e t a r
j e t a s í n d i c e v i r t u a l e s o r e a le s . E l c a s o e s d e s a r r o l l a r u n a
r e p r e s e n t a c i ó n o r g a n i z a d a d e la s c la s e s . L a s responsa
bilidades s o n l o s a t r i b u t o s y o p e r a c i o n e s r e l e v a n t e s p a r a
l a c la s e . P u e s t o d e f o r m a s i m p l e , u n a r e s p o n s a b i l i d a d
e s « c u a lq u ie r c o s a q u e c o n o c e o h a c e la c la s e »
[ A M B 9 5 ] . L o s colaboradores s o n a q u e l l a s c la s e s n e c e
s a r ia s p a r a p r o v e e r a u n a c l a s e c o n l a i n f o r m a c i ó n n e c e
s a r ia p a r a c o m p le t a r u n a r e s p o n s a b ilid a d . E n g e n e r a l,
u n a c o la b o r a c ió n im p lic a u n a s o lic it u d d e in f o r m a c ió n
o u n a s o lic it u d d e a lg u n a a c c ió n .
C lases
L a s p a u t a s b á s i c a s p a r a i d e n t i f i c a r c la s e s y o b j e t o s s e
p r e s e n ta r o n e n e l C a p í t u lo 2 0 . R e s u m ie n d o , lo s o b je t o s
s e m a n if ie s t a n e n u n a v a r ie d a d d e f o r m a s ( S e c c ió n
2 0 .3 . 1 ) : e n tid a d e s e x te r n a s , c o s a s , o c u r r e n c ia s o s u c e
s o s , r o le s , u n id a d e s o r g a n iz a t iv a s , lu g a r e s , o e s t r u c t u
ra s . U n a té c n ic a p a r a id e n t ific a r lo s e n e l c o n te x to d e u n
p r o b le m a d e l s o f t w a r e e s r e a liz a r u n a n á lis is g r a m a t i
c a l c o n l a n a r r a t i v a d e p r o c e s a m i e n t o p a r a e l s is t e m a . ib)
www.FreeLibros.org
T o d o s lo s n o m b r e s s e t r a n s f o r m a n e n o b je t o s p o t e n c ia
le s . S i n e m b a r g o , n o t o d o o b j e t o p o t e n c i a l p o d r á F IG U R A 2 1 .2 . a ) D iagram a de casos de uso de alto nivel.
in c lu ir s e e n e l m o d e lo . U n o b je t o p o t e n c ia l d e b e s a tis b) D iagram a de casos de uso detallado.
368
CAPÍTULO 21 ANÁLISIS O R I E N T A D O A O B J E T O S
R e sp o n sa b ilid a d e s
¿Cómo determinar si merece la
• pena incluir un objeto potencial

en una tarjeta índice CRC?
5. O peraciones com unes: el objeto p otencial debe defi

L as p a u tas básicas para identificar re sp o n sa b ilid a d e s
(atrib u to s y operaciones) tam bién fu e ro n p re se n ta d a s
en el C apítulo 20. Para resumir, los atrib u to s re p re se n
tan características estables de una clase, e sto e s, in fo r
n ir un conjunto de o peraciones ap licab les, al igual m ación sobre la clase que debe retenerse p a ra llev ar a
que antes, a todos los objetos de la clase. c ab o lo s o b jetiv o s del softw are e s p e c ific a d o s p o r el
6. R equisitos esenciales: las entidades externas que apa cliente. L o s atributos pueden a m en u d o e x tra e rs e del
recen en el espacio del p ro b lem a y pro ducen in fo r p lan tea m ien to de alcance o discern irse a p a rtir d e la
m ación esencial p ara la o peración de u n a solución co m p ren sió n de la naturaleza de la clase. L a s o p e ra
p ara el sistem a casi siem pre se d efinen com o ob je ciones pueden extraerse desarrollando u n a n á lisis g ra
tos en el m odelo de requisitos. m atical sobre la narrativa de procesam iento del sistem a.
L os verbos se transform an en candidatos a operaciones.
U na clase potencial debe satisfacer las seis caracte
C ada operación elegida para una clase e x h ib e u n c o m
rísticas de selección anteriores si v a a ser incluida en el
portam iento de la clase.
m odelo CRC.
Firesm ith [FIR93] extiende las características de c la
sificación su g irie n d o , a d em ás de la s e x iste n te s, las
siguientes:
C lases dispositivo. M odelan entidades externas tales las responsabilidades de una clase incluyen tanto a los
como sensores, m otores y teclados. atributos como a las operaciones.
C la se s p ro p ie d a d . R ep re se n ta n alg u n a p ro p ie d ad
im portante del entorno del pro b lem a (por ejem plo: e sta
W irfs-B rock y sus colegas [W IR90] su g ieren c in c o
blecim iento de créditos dentro del contexto de una apli
pautas para especificarresponsabilidades para las clases:
cación de p réstam os hipotecarios).
1. L a in te lig en c ia del sistem a debe d istr ib u ir s e de
C lases in teracció n . M odelan in teracciones que o c u
rren entre otros objetos (por ejem plo: u n a adquisición o m anera igualitaria. Toda aplicación encierra un cierto
grado de inteligencia,por ejem plo, lo que sa b e e l sis
una licencia).
tem a y lo que puede hacer. E sta in te lig e n c ia puede
d istrib u irse ente las clases de v arias m a n e ras. L as
,¿Hay alguna manera de clasificar
clases «tontas» (aquellas con pocas re sp o n sa b ilid a
las clases? ¿Qué características
des) pueden m odelarse de m anera que actúen c o m o
nos ayudan a hacerlo?
sirvientes de unas pocas clases «listas» (aq u ellas con
m u ch as responsabilidades). A u n q u e e s te e n fo q u e
A d icionalm ente, los objetos y clases p u eden clarifi
hace que el flujo de control dentro de u n siste m a sea
carse p o r un conjunto de características:
claro, posee algunas desventajas: (1) C o n cen tra to d a
T angibilidad. ¿R ep resen ta la clase algo tan g ib le o la in teligenciaen pocas clases, haciendo los cam bios
palpable (por ejem p lo , un tec la d o o sen sor), o rep re m ás difíciles; (2) Tiende a necesitar m á s clases y por
senta inform ación m ás abstracta (por ejem plo: una salida lo tanto el esfuerzo de desarrollo aum enta.
prevista)?
In clu sivid a d . ¿E s la c la se a tó m ic a (es decir, no responsabilidades
incluye otras clases) o es agregada (incluye al m enos a una clase?
u n objeto anidado)?
Secuencia. ¿Es la clase concurrente (es decir posee P o r e sta razón, la inteligencia d e l sis te m a d eb e
su p ropio hilo de control) o secu en cia l (es controlada distribuirse de m anera igualitaria entre la s cla se s de
por recursos externos)? una aplicación. Com o cada ob jeto c o n o c e y a c tú a
P ersistencia. L a clase es tem poral (se crea durante sobre algunos pocos elem entos (g en eralm en te bien
a ejecución del p ro g ram a y es elim in ad a una vez que d efin id o s y claros), la cohesión d e l sis te m a s e ve
éste term ina), o p erm a n en te (es alm acenada en una base increm entada. Adicionalm ente, los e fe c to s co la te ra
de datos)? les provocados por cam bios tienden a am o rtiguarse
Integridad. ¿Es la clase corrom pióle (es decir, no pro d ebido a que la inteligencia del siste m a se h a d e s
tege sus recursos de influencias externas) o es segura (la com puesto entre muchos objetos.
clase refuerza los controles de accesos a-sus recursos)?
U sando estas categorías de clases, p u eden am pliar
www.FreeLibros.org
se las «tarjetas índice» creadas com o p arte del m odelo Si una clase tiene ana listo excesivamente larga de
CRC p ara incluir el tipo de la clase y sus característi responsobilidodes, tal vez deberla considerarsesu división
cas (Fig. 21.3). en varias clases menores.
369
I N GEN IE RI A DEL S O F TW A R E . UN EN F O Q U E P R Á C T I C O
P ara d eterm inar si la inteligencia del sistem a está sab ilid ad no d eb e com p artirse, de m an era general,
d istrib u id a eq u itativ am en te, las resp o n sa b ilid a d es e n tre v a ria s clases. Si la in fo rm a c ió n e stá d istri
d e fin id a s en ca d a ta rje ta ín d ic e d el m o d e lo C R C bu id a, el softw are se to rn a m ás d ifícil de m antener
d eb en ser ev alu ad as p ara d e te rm in a r si ca d a clase y probar.
p o see u n a lista de re sp o n sa b ilid a d e s e x tra o rd in a 5. Compartir responsabilidades entre clases relacio
riam en te grande. E sto in d ic a un a co n c e n tra ció n de nadas cuando sea apropiado. E xisten m uchos casos
inteligencia. A dem ás, las responsabilidades de cada en los cuales u n a gran variedad de objetos exhibe el
clase d e b en m o stra r el m ism o niv el de abstracción. m ism o com portam iento al m ism o tiem po. Com o un
P o r e je m p lo , e n tre la lista de o p e ra c io n e s de una ejem p lo , considere un videojuego que debe mostrar
clase ag reg ad a lla m a d a C om probación de cuenta los sig u ien tes objetos: ju gador, cuerpo-del-juga-
ex iste n dos resp o n sab ilid ad es: saldo-de-la-cuenta dor, brazos-del-jugador,cabeza-del-jugador. Cada
y verificar-talones-cobrados. L a prim era operación uno de estos atributos tiene sus propios atributos (p.e.:
(re s p o n s a b ilid a d ) im p lic a u n c o m p le jo p ro c e d i p o sició n , orientación, color, velo cid a d ), y todos
m iento m atem ático y lógico. L a segunda es un a sim deben actualizarse y visualizarse al m o v er el usua
ple a ctiv id ad p ara e m p le a d o s. D eb id o a que estas rio el jo y stic k . L as re sp o n sab ilid ad es actualizar y
d o s a c tiv id a d e s n o e s tá n al m ism o n iv e l d e a b s visualizar d eben, p o r lo tan to , co m p artirse por los
tracció n , verificar-talones-cobrados debe situarse objetos señalados. El ju gad or sabe cuán d o algo ha
d e n tro de las re sp o n sa b ilid a d e s de la c la se C om cam biado y se requiere actualizar; colabora con los
probación de entradas, la cu al está co n te n id a en o tro s o b je to s p a ra a lc a n z a r u n a n u ev a posición u
la clase agregada C om probación de cuenta. o rie n ta c ió n , p e ro c a d a o b je to c o n tro la su propia
visualización.
Nombre de la clase:
Colaboradores
Tipo de la clase: (dispositivo, propiedad, rol, evento,...)
Características de la clase: (tangible, atómica, concurrente,...) L as clases c u m p le n c o n sus re sp o n sab ilid ad es de u n a
Responsabilidades: Colaboradores: , d e las d o s sig u ie n te s m an eras: (1) u n a c la se puede
u sar sus p ro p ias o p e racio n es p a ra m an ip u la r sus pro
p io s atributos, c u m p lie n d o p o r lo tan to con una res
p o n s a b ilid a d p a rtic u la r, o (2) p u e d e c o la b o ra r con
o tra s clases.
W irfs-B rock [W IR90] y sus colegas definen las cola
boraciones de la siguiente form a:
L as colaboraciones representan solicitudes de un cliente a
un serv id o r en el cu m p lim ien to de una responsabilidad del
F IG U R A 2 1 .3 . Un modelo CRC de tarjeta índice. cliente. U na colaboración es la realización de un contrato entre
el cliente y el servidor... D ecim os que un objeto colabora con
otro, si para ejecutar una responsabilidad necesita enviar cual
2. Cada responsabilidaddebe establecerse lo más gene quier m ensaje al otro objeto. U na colaboración sim ple fluye en
ral posible. E sta directriz im plica que las resp o n sa una dirección, representando una solicitud del cliente al servi
b ilid ad es g en erales (ta n to los atrib u to s c o m o las dor. D esde el punto de vista del cliente, cada una de sus cola
boraciones está asociada con una responsabilidad particular
operaciones) d eben residir en la parte alta de la je ra r- im plem entada por el servidor.
quía de clases (puesto que son genéricas, se aplica
rán a to d a s las su b c la se s). A d ic io n a lm e n te , debe
usarse el polim orfism o (C apítulo 20) p ara d efinir las
operaciones que generalm ente se aplica a la super-
clase, pero que se im plem en tan de m an era diferente
CLAVE
en cada u n a de las subclases. Un objeto servidor colabora con un objetos cliente
en un esfuerzo por llevar o cabo una determinada
3. La información y el comportamiento asociado a ella,
responsabilidad. la colaboración implica el paso de mensajes.
debe encontrarse dentro de la m ism a clase. E sto
im p lem en ta el p rin c ip io O O de e n c a p su la m ie n to
(C apítulo 20 ). L os datos y p rocesos que m anipulan Las colaboraciones identifican relaciones entre cla
esto s d ato s d e b en em p aq u etarse co m o u n a unidad ses. C uando todo un conjunto de clases colabora para
cohesionada. satisfacer algún requisito, es posible organizarlas en un
4. La información sobre un elemento debe estar loca subsistem a (un elem ento del diseño).
lizada dentro de una clase, no distribuida a través L as c o lab o racio n es se id en tifican determ inando si
www.FreeLibros.org
de varias clases. U n a clase sim ple debe asu m ir la u n a clase puede satisfacer cada responsabilidad. Si no
resp o n sab ilid ad de alm acenam iento y m anipulación puede, entonces necesita interactuar con otra clase. De
de un tip o e sp ecífico de in fo rm ació n . E sta re sp o n aquí surge'lo que hem os llam ado u n a colaboración.
370
CAPÍTULO 21 A NÁ LI SI S O R IE N TA D O A O B JE T O S
Como un ejemplo, considere la aplicación H ogar-

¿Qué enfoque efectivo
Seg a ro 6. Como una parte del procedimiento de activa
existe para revisar un
ción (vea el caso de uso para activación en la sección
modelo CRC?
11.2.4), el objeto p a n e l d e c o n t r o l debe determinar si
existen sensores abiertos. Se define una responsabili
dad llamada d e te r m in a r-e sta d o -d e l-se n so r.S \hay sen 1. A todos los participantes de la revisión (del modelo
sores abiertos, el p a n e l d e c o n t r o l debe poner el atributo CRC) se les da un subconjunto de las tarjetas índice
estado al valor «no preparado». La informacióndel sen del modelo CRC. Las tarjetas que colaboran deben
sor puede obtenerse del objeto s e n s o r . Por lo tanto, Ig estar separadas (esto es, ningún revisor debe poseer
responsabilidad d e te r m in a r - e s ta d o - d e l- s e n s o r puede dos tarjetas que colaboren).
ejecutarse solamente si el p a n e l d e c o n t r o l trabaja en 2. Todos los escenarios (y sus correspondientes diagra
colaboración con el s e n s o r . mas de casos de uso) deben organizarse en categorías.
Para ayudar en la identificaciónde colaboradores, el 3. El director de la revisión lee el caso de uso con aten
analista puede examinar tres relaciones genéricas dife ción. Cuando el director llega a un objeto identifi
rentes entre clases [W IR90] : (1) la relación es-parte-de, cado, se traspasa la señal a la persona que posee la
(2) la relación tiene-conocim iento-sobre, y (3 ) la rela clase tarjeta índice correspondiente. Por ejemplo, el
ción depende-de. A través de la creación de un diagra caso de uso mencionado en la Sección 20.4.1 con
ma de relación entre clases (Sección 2 1.4.4), el analista tiene la siguiente narración:
desarrolla las conexionesnecesarias para identificarestas E l propietario de la casa o b serv a el panel de control de
relaciones. Cada una de las tres relaciones genéricas se Hogarseguropara determ inar si el sistem a está listo para entra
considerabrevemente en los párrafos siguientes. da de datos. Si el sistem a/w está fe to , el propietario debe cerrar,
Todas las clases que forman parte de una clase agre físicam ente, las ventanas y puertas para que aparezca el indi
cador de «listo». [Un in d ic a d o rn o listo im plica que un sensor
gada están conectadas a ésta a través de una relación es está abierto, esto es que una puerta o ventana está abierta.]
parte-de. Considere las clases definidas para eljuego de
vídeo mencionado anteriormente, la clase c u e r p o - d e l - Cuando el director de la revisión llega al «panel de
j u g a d o r es-parte-de, al igual que c u e r p o - d e l - j u g a d o r , control» en la narrativa del caso de uso, se pasa la
b r a z o s - d e l- ju g a d o r y c a b e z a - d e l- ju g a d o r . señal a la persona que posee la tarjeta panel de con
Cuando una clase debe obtener información sobre trol. La frase « im plica que un sensor está abierto»
otra, se establece la relación tiene-conocim iento-sobre. requiere que la tarjeta índice contenga una respon
La responsabilidad d e te rm in a r-e sta d o -d e l-se n so re s un sabilidad que validará esta implicación (la respon
ejemplo de la relación tie n e-co n o cim ien to -so b re. La sabilidad determinar-estado-del-sensor realiza esta
relación depende-de implica que dos clases poseen una acción). Al lado de la responsabilidad en la tarjeta
dependencia no realizable a través de tie n e -c o n o c i índice está el colaborador sensor. La señal se pasa
miento-sobre o es-parte-de. Por ejemplo, la c a b e z a - d e l - entonces al objeto sensor.
j u g a d o r debe estar siempre conectada al c u e r p o - 4. Cuando se pasa la señal, se le pide al que posee la
d e l - j u g a d o r (a menos que el videojuego en particular tarjeta de la clase que describa las responsabilidades
seamuy violento), aunque cada objeto puede existir sin mencionadas en la tarjeta. El grupo determina si una
conocimientodirecto sobre el otro. Un atributodel obje ( o más) de las responsabilidades satisface el requi
to c a b e z a - d e l - j u g a d o r llamadop o s ic ió n -c e n tr a l se sito del caso de uso.
obtiene de lap o sic ió n -c e n tra l del objeto c u e r p o - d e l - 5 . Si las responsabilidades y colaboraciones mencio
j u g a d o r . Esta información se obtiene a través de un ter nadas en las tarjetas índice no pueden acomodarse
cer objeto, jugador, el cual la obtiene del al caso de uso, se hacen modificaciones a las tarje
c u e r p o - d e l - j u g a d o r . Por lo tanto, la c a b e z a - d e l - j u g a - tas. Esto puede incluir la definición de nuevas cla
d o r depende-de c u e r p o - d e l - j u g a d o r . ses (y sus correspondientes tarjetas índice CRC) o la
En todos los casos, el nombre de la clase colaborado especificación de responsabilidades y colaboracio
ra seregistra en la tarjeta índice del modelo CRC al lado nes nuevas o revisadas en tarjetas existentes.
de la responsabilidad que ha generado dicha colabora Este m odns operandi continúa hasta terminar el caso
ción. Por lo tanto, la tarjeta índice contiene una lista de de uso. Cuando terminan todos los casos de uso, conti
responsabilidadesy de colaboraciones correspondientes núa el análisis OO.
que posibilitan se realicen las responsabilidades su rea
lización (Fig. 21.3).
Cuando se ha desarrolladoun modelo CRC por com 21.4.3. D e fin ició n d e estr u c tu r a s y je r a r q u ía s
pleto, los representantes del cliente y de las organiza Una vez que se han identificadolas clases y objetos usan
ciones de ingeniería del software pueden recorrer el do el modelo CRC, el analista comienza a centrarse en
modelo haciendo uso del siguiente enfoque. la estructura del modelo de clases y lasjerarquías resul
www.FreeLibros.org
6 Vea una explicación de las clases deH ogarseguroen la Sección
2 0 .3 .
37 1
IN GE NI E RÍ A DEL S OFT W ARE . UN EN F O Q U E P R Á C T I C O
tantes que surgen al em erg er clases y subclases. U sa n m en ta un o o m ás co n tra to s [W IR 90] con sus colabo
do la n o tació n U M L p odem os c re a r gran v ariedad de rad o re s externos. U n c o n tra to es una lista esp ecífica
diagram as. D ebe crearse u n a estructura de generaliza- de so licitu d es que los co lab o rad o res p u e d en hacer a
ción-especialización p ara las clases identificadas. u n subsistem a'.
P ara ilustrarlo co n sid ere el o b jeto sensor d efin id o
para H ogarSeguro y m ostrado en la Figura 21.4. Aquí,
la generalización, sensor, se refin a en u n co n ju n to de Sensor
especializaciones: sensor de entrada, sensor de hum o
y sensor de m ovim iento. L os atributos y operaciones A trib u to s O p e ra c io n e s
identificados en el sensor son h eredados p o r las e sp e
cializaciones de la clase. H em os cread o u n a je ra rq u ía
de clases sim ple.
E n o tro s c a so s, un o b je to re p re s e n ta d o se g ú n el
m odelo inicial puede estar com puesto realm ente de un Sensor Sensor S ensor
núm ero de partes las cuales p u ed en definirse a su vez de entrada de hum o d e m o v im ie n to
com o objetos. E sto s objetos agregados p u ed en re p re
se n ta rse co m o u n a e stru c tu ra co m p o n en te-a g reg a d o
[ER I97] y se d efinen usando la n o tació n representada F IG U R A 2 1 .4 .a Diagram a de clases que ¡lustra la relación
en la F ig u ra 21.5. E l ro m b o im p lica u n a re la c ió n de de generalización-especialización.
ensam b laje. D ebe n o tarse que las lín eas de co n ex ió n
pued en aum entarse con sím bolos adicionales (no m o s
trados) para rep resen tar cardinalidad, que se adaptan de
la n o tació n del m odelo entidad-relación descrito en el
C apítulo 12.
L as rep resentaciones estructurales p ro v een al an a
lista de los m edios p ara p articio n ar el m odelo CRC y
p ara rep resen tar esta p artició n gráficam ente. L a ex pan
sión de cad a clase ap o rta los d etalles n e c e sa rio s para
rev isió n y p ara el subsiguiente diseño.
21.4.4. D efin ición d e su b sistem a s

U n m odelo de análisis para una aplicación com pleja pue
de tener cientos de clases y docenas de estructuras. Por
F IG U R A 2 1 .5 .a Diagrama de clases que ¡lustra la relación
esta razón, es n ecesario definir una rep resen tación co n de agregación.
cisa que sea un resum en de los m odelos CR C y estruc
tural descritos anteriorm ente.
L os su b siste m a s p u ed en re p re se n ta rs e den tro del
co n tex to del m o d e lo C R C c re a n d o una tarje ta índice
del subsistem a. L a tarjeta índice del su b sistem a indi
CLAVE ca el n o m b re del sub sistem a, los co n trato s que debe
cu m p lir y las clases u otros sub sistem as que soportan
Un S L te fe r r a (paquetede UML) incluye una jerarquía
el contrato.
de clases más detefeda.
L o s p a q u e te s so n id é n tic o s a lo s su b siste m a s en
in te n c ió n y c o n te n id o , p ero se re p re se n ta n gráfica
L os su b co n ju n to s de clases que co lab o ran entre sí m ente en U M L. P o r ejem plo, sup o n g a que el panel de
p a ra lle v a r a c ab o un c o n ju n to de resp o n sa b ilid ad e s c o n tro l d e H o g a r S e g u r o e s c o n sid e ra b le m e n te más
co h esio n ad as, se les llam a n o rm alm en te su b sistem a s co m p lejo que el rep re sen ta d o p o r la F ig u ra 21.5, con
o p a q u e te s (en te rm in o lo g ía U M L ). L os su b sistem as ten ien d o m ú ltip les m o n ito res, una so fisticad a d istri
o p a q u e te s son a b stra c c io n e s q u e a p o rta n u n a r e fe b u c ió n de teclas y o tras características. E ste pudiera
ren c ia o p u n te ro a los d etalles en el m o d elo de an á li m o d elarse co m o una e stru c tu ra to d o -p arte s m ostrada
sis. S i se o b se rv a d e sd e el e x te rio r, u n s u b s is te m a en la F ig u ra 21.6. Si el m o d e lo de req u isito s co n tu
puede tra ta rse co m o u n a caja n e g ra que c o n tie n e un v iera docen as de e sta s e stru c tu ra s (H o g a rS eg u rú no
co n ju n to de re s p o n s a b ilid a d e s y q u e p o see sus p r o la s te n d rá ), se ría d ifíc il a b s o rb e r la re p re se n tació n
pios co lab o rad o res (extern o s). U n su b sistem a im ple- co m p le ta de u n a vez. D e fin ie n d o u n a refe ren cia de
www.FreeLibros.org
7 Recuerde que las clases interactúan usando una filosofía cliente/ser
vidor. En este caso el subsistem a es el servidory los colaboradores
externos los clientes.
372
CAPÍTULO 21 AN Á LIS IS O RI EN TA D O A O B J E T O S
temas, como se muestra en la figura, pudiera referen- sensor (Figs. 21.5 y 21.6); para el sistem a, suceso sen
ciarse toda la estructura a través de un simple icono sor y alarm a audible se crearán también estructuras si
(la carpeta de ficheros). Las referencias de paquetes estos objetos necesitan objetos ensamblados.
se crean generalmente para cualquier estructura que Las flechas discontinuas mostradas en la parte supe
posea múltiples objetos. rior de la Figura 21.7 representan relaciones de depen
Al nivel más abstracto, el modelo de AOO conten dencia entre los paquetes que se muestran. Sensor
drá solamente referencias de paquetes tales como las depende del estado del paquete suceso sensor. Las fle
que se ilustran al inicio de la Figura 21.7. Cada una de chas continuas representan composición. En el ejem
las referencias se expandirá a una estructura. Se ilus plo, el paquete sistem a está compuesto por los paquetes
tran las estructuras para los objetos panel de control y panel de control, sensor y alarm a audible.
El enfoque del modelado CRC usada en secciones ante

riores ha establecido los primeros elementos de las rela
ciones de clases y objetos. El primer paso en el
establecimientode las relaciones es comprender las res
ponsabilidadesde cada clase. La tarjeta índice del mode
lo CRC contiene una lista de responsabilidades. El
siguiente paso es definir aquellas clases colaboradoras
que ayudan en la realización de cada responsabilidad.
Esto establece la «conexión» entre las clases.
Entre dos clases cualesquiera que estén conectadas
existe una r e l a c i ó n * . Debido a esto los colaboradores
siempreestánrelacionados de algunamanera. El tipo de
relación más común es la binaria (existe una relación
entre dos clases). Cuando se analiza dentro del contexto
de un sistema 00,una relación binariaposee una direc
ciónespecífica’ que se define apartir de qué clase desem F IG U R A 2 1 .6 . Referencia a paquete (subsistem a).
peña el papel del cliente y cuál actúa como servidor.
Rumbaughy sus colegas [RUM91] sugieren que las
relaciones pueden derivarse a partir del examen de los
verbos o frases verbales en el establecimientodel alcan El modelo objeto-relación (como el modelo entidad-
ce o casos de uso para el sistema. Usando un análisis relación) puede obtenerse en tres pasos o etapas:
gramatical, el analista aísla verbos que indican locali 1 U s a n d o la s t a r je t a s í n d ic e C R C ,p u e d e d ib u ja r s e u n a
zaciones físicas o emplazamientos ( c e r c a d e , p a r t e d e , La Figura 21.8 repre
r e d d e o b je t o s c o la b o r a d o r e s .
c o n t e n i d o e n ) , comunicaciones ( t r a n s m i t e a , o b t e n i d o senta las conexiones de clase para los objetos de
d e ) , propiedad ( i n c o r p o r a d o p o r , s e c o m p o n e d e ) y cum H o g a r S e g u r o . Primero se dibujan los objetos conec
plimiento de una condición ( d i r i g e , c o o r d i n a , c o n t r o tados por líneas sin etiquetas (no se muestran en la
l a ) . Estos aportan una indicación de la relación. figura) que indican la existencia de alguna relación
La notación del lenguaje unificado de modeladopara entre los objetos conectados. Una alternativa es mos
el modelo objeto-relaciónutiliza una simbología adap trar los nombres de los roles de cada clase en la rela
tada de las técnicas del modelo entidad-relaciónexami- ción en lugar del nombre de la relación. Esto se
nadas en el Capítulo 12. En esencia, los objetos se describe en el Capítulo 22.
conectancon otros objetosutilizandorelaciones con nom 2. R e v is a n d o e l m o d e lo C R C d e t a r je t a s í n d ic e s , s e e v a
bres. Se especifica la cardinalidad de la conexión (ver lú a n r e s p o n s a b ilid a d e s y c o la b o r a d o r e s y c a d a lí n e a
capítulo 12) y se establece toda una red de relaciones. Para evi
d e c o n e x ió n s in e t iq u e t a r r e c ib e u n n o m b r e .
tar ambigüedades, una punta de flecha indica la
«dirección» de la relación (Fig. 21.8).
i ¿Cómo se obtiene un modelo 3. U n a v e z q u e s e h a n e s t a b le c id o y n o m b r a d o la s r e l a
objeto-relación? c io n e s , s e e v a lú a c a d a e x tr e m o p a r a d e t e r m in a r la c a r -
www.FreeLibros.org
8 Otros térm inos para relación son asociación [RUM91] y conexión 9 Es im portante notar que esta e s una salida de la n atu ra le z a bidi-
[COA91]. " reccional de las relaciones usadas en el m odelado de d a to s (C apí
tulo 12).
373
d in a lid a d ( F ig . 2 1 .8 ) . E x is t e n c u a t r o o p c io n e s : O a 1, Un panel de control controla uno o más sensores

1 a 1 , O a m u c h o s , ó 1 a m u c h o s . P o r e j e m p l o , e l s is y cada sensor es controlado por un panel de control
te m a H o g a r S e g u ro c o n tie n e u n ú n ic o p a n e l d e c o n tr o l
( la c a r d in a lid a d 1 lo in d ic a ) . A l m e n o s u n s e n s o r d e b e
e s ta r p r e s e n te p a r a q u e e l p a n e l d e c o n t r o l lo a c tiv e .
S in e m b a r g o , v a r io s s e n s o re s p u e d e n e s ta r p r e s e n te s
( l a r e l a c i ó n 1 .. l o i n d i c a ) . U n s e n s o r p u e d e r e c o n o c e r
1 o m á s s u c e s o s d e s e n s o r (p .e .: s e d e te c ta h u m o u o c u
r r e u n a c a íd a , p u e s e l s í m b o lo 1 ..* lo in d ic a ) .
Un sistema está formado por cero Ó más alarmas audibles I

“ una alarma audible está asociada con un único sistema *
J
F IG U R A 2 1 .8 . Relaciones entre objetos.
L o s p a s o s a n t e r io r m e n t e m o s t r a d o s c o n t in ú a n h a s ta
q u e s e p r o d u z c a u n m o d e lo o b je t o - r e la c ió n c o m p le t o .
E n e l d e s a r r o llo d e u n m o d e lo o b je t o - r e la c ió n , e l a n a
lis t a a ñ a d e a ú n a lg u n a o t r a d im e n s ió n a l m o d e lo d e a n á
l i s i s g e n e r a l . N o s o l a m e n t e s e i d e n t i f i c a n la s r e l a c i o n e s
e n t r e o b j e t o s , s i n o q u e s e d e f i n e n t o d a s la s v í a s i m p o r
t a n te s d e m e n s a je s ( C a p í t u l o 2 0 ) . E n n u e s t r a d e s c r ip
c i ó n d e l a F i g u r a 2 1 . 7 , h i c i m o s r e f e r e n c i a a la s f l e c h a s
q u e c o n e c ta n s ím b o lo s d e p a q u e te s . T a m b ié n s o n v ía s
d e m e n s a je s . C a d a f l e c h a i m p l i c a e l i n t e r c a m b i o d e m e n
F IG U R A 2 1 .7 . Modelo de análisis con referencias a paquetes. s a je s e n t r e s u b s i s t e m a s e n e l m o d e l o .
E l m o d e lo C R C y e l d e o b je t o - r e la c ió n r e p r e s e n t a n e le 5. R e v is a r e l m o d e lo o b je t o - c o m p o r t a m ie n t o p a r a v e r i
m e n to s e s tá t ic o s d e l m o d e lo d e a n á lis is O O . A h o r a e s e l f i c a r e x a c t it u d y c o n s is te n c ia .
m o m e n to p a r a h a c e r u n a t r a n s ic ió n a l c o m p o r ta m ie n to
C a d a u n o d e e s t o s p a s o s s e d i s c u t e e n la s s e c c io n e s
d i n á m ic o d e l s is t e m a o p r o d u c t o O O . P a r a e je c u t a r e s te
s ig u ie n te s .
p a s o d e b e m o s r e p r e s e n ta r e l c o m p o r t a m ie n t o d e l s is t e
m a c o m o u n a f u n c ió n d e s u c e s o s e s p e c íf ic o s y tie m p o .
21.6.1. Id e n tific a c ió n d e s u c e s o s con c a s o s d e uso
•
¿Cuáles son los posos C o m o v im o s e n la S e c c ió n 2 1 .4 .1 , e l c a s o d e u s o
o seguir poro construir un r e p r e s e n t a u n a s e c u e n c ia d e a c t iv id a d e s q u e in c lu y e n
modelo objetos-tomportomiento? a a c to r e s y a l s is t e m a . E n g e n e r a l, u n s u c e s o o c u r r e
c a d a v e z q u e u n s is t e m a O O y u n a c t o r ( r e c u e r d e q u e
E l m o d e lo o b je to - c o m p o r ta m ie n to in d ic a c ó m o r e s u n a c to r p u e d e s e r u n a p e rs o n a , u n d is p o s itiv o o in c lu
p o n d e r á u n s is t e m a O O a s u c e s o s e x t e r n o s o e s t í m u lo s . s o u n s is t e m a e x t e r n o ) in t e r c a m b ia n in fo r m a c ió n .
P a r a c r e a r e l m o d e lo , e l a n a lis t a d e b e e je c u t a r lo s R e c o r d a n d o la e x p lic a c ió n d a d a e n e l C a p ítu lo 1 2 , es
s ig u ie n te s p a s o s : im p o r t a n t e r e c o r d a r q u e u n s u c e s o e s B o o le a n o . E s to
1. E v a lu a r to d o s lo s c a s o s d e u s o ( S e c c ió n 2 1 .4 . 1 ) p a r a e s , u n s u c e s o n o e s la in f o r m a c ió n q u e s e in t e r c a m
c o m p r e n d e r t o t a lm e n t e la s e c u e n c ia d e in t e r a c c ió n b ia , e s e l h e c h o d e q u e la in f o r m a c ió n h a s id o in t e r
d e n t r o d e l s is t e m a . c a m b ia d a .
2 . I d e n t if ic a r s u c e s o s q u e d i r ig e n la s e c u e n c ia d e in t e r U n c a s o d e u s o s e e x a m in a p o r p u n to s d e in te r c a m
a c c ió n y c o m p r e n d e r c ó m o e s to s s u c e s o s s e r e la c io n a n b io d e in f o r m a c ió n . P a r a ilu s t r a r lo , r e c o n s id e r e e l c a s o
c o n o b je t o s e s p e c íf ic o s . d e u s o d e s c r ito e n la S e c c ió n 1 1 .2 .4 :
3 . C re a r u n a tra z a d e s u c e s o s [R U M 9 1 ] p a ra c a d a c a s o 1. El propietario observa el panel de control áe,HozarSeí>um
www.FreeLibros.org
(Figura 11.2) para determ inar si el sistem a está listo para
de uso.
recibir datos. Si el sistem a no está listo , el propietario debe
4 . C o n s t r u ir u n d ia g r a m a d e t r a n s ic ió n d e e s ta d o s p a r a cerrar físicam ente ventanas y puertas de tal m anera que el
e l s is t e m a . indicador de disponibilidad esté p resente. [Un indicador de
374
CAPÍTULO 21 ANÁLI SI S O R I E N T A D O A O BJ E TO S
no preparado im plica que el sensor está abierto, p o r ejem a g r e g a d o jugador ( e n l a a p l i c a c i ó n d e l v i d e o j u e g o e x a

plo, que una puerta o ventana está abierta.] m i n a d o a n t e r i o r m e n t e ) i n c l u i r á posición y orientación
2. F.l nronietario usa el teclado p ara teclear una contraseña de a c t u a l d e l jugador ( a t r i b u t o s d e l o b j e t o ) a s í c o m o o t r a s
cuatro d íg ito s. L a contraseña se com para con la contraseña c a r a c te r ís tic a s d e ju g a d o r q u e s o n r e le v a n te s a l j u e g o
válida alm acenada en el sistem a. Si la contraseña es in co
( p . e . : u n a t r i b u t o q u e i n d i q u e permanecen deseos mági
rrecta, el panel de control avisará una vez y se restaurará
por sí m ism o para recibir datos adicionales. Si la contrase cos). E l estado activo d e u n o b j e t o i n d i c a d e s t a d o a c t u a l
ña e s correcta, el panel de control esp e ra por las acciones c u a n d o é s te e n tr a e n u n a tr a n s f o r m a c ió n c o n t in u a o p r o
siguientes. c e s o . E l o b j e t o jugador p o s e e r á l o s s i g u i e n t e s e s t a d o s
3. F.l propietario selecciona v teclea perm anecer o continuar a c t i v o s : en movimiento, en descanso, lesionado, en recu
paraactiv arel sistem a.F em ia n ecer activa solamente los sen peración, atrapado, perdido e n t r e o t r o s . P a r a f o r z a r l a
sores del perím etro ílos sensores internos detectores de m ovi t r a n s i c i ó n d e u n o b j e t o d e u n e s t a d o a c t i v o a o t r o debe
m iento e stán desactivados). C o n tin u a r a ctiv a to d o s los o c u r r i r u n s u c e s o ( a v e c e s , l l a m a d o disparador). U n c o m
sensores.
p o n e n te d e u n m o d e lo o b je t o - c o m p o r ta m ie n to e s u n a
4. C uando ocurre la activación, el propietario puede observar r e p r e s e n ta c ió n s im p le d e lo s e s ta d o s a c t iv o s d e c a d a o b je
una luz roia de alarm a.
t o y lo s s u c e s o s ( d is p a r a d o r e s ) q u e p r o d u c e n lo s c a m b io s
Las partes de texto subrayadas anteriormenteindican e n tr e e s to s e s ta d o s a c tiv o s . L a F ig u r a 2 1 .9 il u s t r a u n a
sucesos. Deberá identificarseun actorpara cada suceso: r e p r e s e n ta c ió n s im p le d e lo s e s ta d o s a c tiv o s p a r a e l o b je
lainformación que se intercambiadebe anotarse. y debe t o panel de control e n e l s i s t e m a HogarSeguro.
rán indicarse otras condiciones o restricciones.
Como ejemplo de un suceso típico, considere la fra
se subrayada del caso de uso propietario usa el teclado
para teclear una contraseña de cuatro dígitos. En el con Cuando se empiezon o identificar estados, lo atención
texto del modelo de análisis OO el actor propietario se centro en los modos de Comportamiento observables
transmite un suceso al objeto panel de control. desde el exterior. Más tarde, se pueden refinar estos
El suceso puede llamarse contraseña introducida. estados en comportamientos no evidentes cuando
La información transferida son los cuatro dígitos que se observo el sistema desde el exterior.
forman la contraseña, pero ésta no es una parte esencial
del modelo de comportamiento. Es importantenotar que C a d a f le c h a e n la F ig u r a 2 1 .9 r e p r e s e n ta u n a t r a n s i
algunos sucesos tienen un impacto explícito en el flujo c ió n d e u n e s ta d o a c tiv o d e l o b je t o a o tr o . L a s e t iq u e
de control del caso de uso, mientras que otros no impac ta s m o s tra d a s e n c a d a fle c h a r e p r e s e n ta n lo s s u c e s o s
tan directamente en este flujo de control. Por ejemplo. q u e d is p a r a n la tr a n s ic ió n . A u n q u e e l m o d e lo d e e s ta
el suceso contraseña introducida no cambia explícita d o a c t iv o a p o r ta u n a v is ió n in t e r n a m u y ú t i l d e la « h is
mente el flujo de control del caso de uso, pero los resul t o r ia d e v id a » d e u n o b je t o , e s p o s ib le e s p e c if ic a r
tados del suceso comparar contraseña (derivada de la in f o r m a c ió n a d ic io n a l p a r a a p o r ta r m á s p r o f u n d id a d e n
interacción contraseña se compara con la contraseña la c o m p r e n s ió n d e l c o m p o r t a m ie n t o d e u n o b je t o . A d i
válida almacenada en el sistema) tendrá un impacto c io n a lm e n t e a e s p e c if ic a r e l s u c e s o q u e p r o v o c a la o c u
explícito en la información y flujo de control del soft r r e n c ia d e la t r a n s ic ió n , e l a n á lis is p u e d e t a m b ié n
ware H ogarSeguro. e s p e c if ic a r u n a g u a r d a y u n a a c c ió n [ C H A R 9 3 ] , U n a
Una vez que todos los sucesos han sido identifica guarda e s u n a c o n d i c i ó n B o o l e a n a , q u e d e b e s a t i s f a
dos, se asocian a los objetos incluidos. Los actores (enti c e rs e p a r a p o s ib ilit a r la o c u r r e n c ia d e u n a tr a n s ic ió n .
dades externas) y objetos pueden responsabilizarse de P o r e je m p lo , la c o n d ic ió n d e g u a r d a p a r a la t r a n s ic ió n
la generación de sucesos (p.e.: propietario genera el d e s d e e l e s ta d o « e n d e s c a n s o » a l d e « c o m p a r a n d o » e n
suceso contraseña introducida) o reconociendo suce la F ig u r a 2 0 .9 p u e d e d e te r m in a r s e a t r a v é s d e l e x a m e n
sos que han ocurrido en otraparte (p.e.: el panel de con d e l caso de uso:
trol reconoce el resultado binario del suceso comparar if (entrada de contraseña = 4 dígitos)
contraseña). then ejecutar transición al estado comparando;
E n g e n e r a l, la g u a r d a d e u n a t r a n s ic ió n d e p e n d e
21.6.2. R e p r e s e n ta c io n e s d e e s ta d o s
u s u a lm e n te d e l v a lo r d e u n o o m á s a t r ib u t o s d e u n o b je
En el contexto de sistemas OO deben considerarse dos to . E n o t r a s p a la b r a s , la c o n d ic ió n d e g u a r d a d e p e n d e
caracterizaciones de estados: (1) el estado de cada obje d e l e s ta d o p a s iv o d e l o b je t o .
to cuando el sistema ejecuta su función, y (2) el estado U n a acción o c u r r e c o n c u r r e n t e m e n t e c o n l a t r a n s i c i ó n
del sistema observado desde el exterior cuando éste eje o c o m o u n a c o n s e c u e n c ia d e e lla y g e n e r a lm e n t e im p li c a
cuta su función. u n a o m á s o p e r a c io n e s ( r e s p o n s a b ilid a d e s ) d e l o b je t o . P o r
E1 estadode un objeto adquiere en ambos casos carac e j e m p l o , l a a c c i ó n c o n e c t a d a c o n e l s u c e s o contraseña
terísticas pasivas y activas [CHAR93], Un estado pasi
www.FreeLibros.org
introducida ( F i g . 2 1 . 9 ) e s u n a o p e r a c i ó n q u e a c c e d e a u n
vo es simplementeel estado actual de todos los atributos o b je t o c o n tr a s e ñ a y r e a liz a u n a c o m p a r a c ió n d í g it o a d í g i
de un objeto. Por ejemplo, el estado pasivo del objeto t o p a r a v a lid a r la c o n tr a s e ñ a in tr o d u c id a .
375
L a Figura 21.1O ilustra una traza parcial de sucesos para

Comparar contraseña (volverV
1 [contraseña incorrecta] j a entrar J el sistem a H ogarSeguro. C ada una de las flechas repre
senta un suceso (derivado de un caso de uso) e indica cómo
el suceso sintoniza su com portam iento entre los objetos
| Se introduce / . ¡contraseña incorrecta] de HogarSeguro. El prim er suceso, sistem a listo, se deri
í[ r e ^p o s o "
| la contraseña \ Comparando
va del entorno exterior y sintoniza el com portam iento al
C om parar contraseña
propietario. El propietarioteclea una contraseña. El suce
[contraseña correcta]
X so inicia aviso y aviso sonoro indican cóm o se canaliza el
Activación
com portam iento s i la contraseña no es válida. U na con
correcta
traseña válida provoca un retomo al propietario. Los suce
F IG U R A 2 1 .9 . Representación de la transición de estados. sos restantes y sus trazas siguen el com portam iento como
cuando se activa o desactiva el sistema.
El segundo tipo de representación de com portam iento U M L u tiliza diagram as de estad o , de secuencia, de
para el A O O co nsidera u n a rep resen tació n de estados colaboración y de actividades para representar el com
para el p roducto general o sistem a. E sta representación portam iento dinám ico de lo s objetos y las clases iden
abarca un m odelo sim ple de traza de sucesos [R U M 9 1] tificadas co m o parte del m odelo del análisis.
que in d ica cóm o los sucesos causan las transiciones de
objeto a objeto y un diag ram a de tran sició n de estados QPropietan^
que ilustra el com portam iento de cada objeto durante el
procesam iento. S is te m a Introducir
lis to - | contraseña
U na v ez que h an sido identificados los sucesos para Iniciar sonido
un c a so de u so , el a n a lista c re a u n a re p re s e n ta c ió n Y
acerca de có m o los su ceso s p ro v o c a n el flu jo desd e
un o b je to a otro. E sta re p re se n ta ció n , lla m a d a traza I<i |^ .|gP]reo np/da rae sdoa tpara .. I
t iv a c io r T |
Sonido
de su ceso s o de sucesos, es u n a v e rsió n a b rev iad a del i Seleccionar

I perm anecer/salir I Activar/desactivar
caso de uso que re p re se n ta o b jeto s c la v e y los su c e
sensores
sos que prov o can el co m portam iento de p asar de ob je Sen sores
to a objeto. activados/desactivados
Petición de luz roja
Luz roja encendida

CLAVE Preparado para
nueva acción
Una transición de un estado a otro requiere un suceso que
la produzca. los sucesos son booleanos por naturaleza ya
menudo ocurren cuando un objeto se comunica con otro. F IG U R A 2 1 .1 0 . Traza de sucesos parcial para el sistema
H o g a rs e g u ro .
J E S 1 Z M £ Í I __________________________________________________________________________________
______________________________________________ s
L os m étodos de A O O p erm iten a un ingeniero del soft los re q u isito s esp e cific ad o s p o r el clien te tal y como
w are m o d elar un p ro b lem a representando las caracte éstos afectan a la aplicación a construir.
rísticas tanto dinám icas com o estáticas de las clases y El proceso de A O O co m ien za con la definición de
sus relaciones com o com ponentesprincipales del m o d e casos de uso (escen ario s que d escrib en cóm o se v a a
lado. C om o los m étodos precedentes, el lenguaje u n ifi u tilizar el sistem a). L a técnica de m odelado de clases-
cado de m odelado U M L construye un m odelo de análisis responsabilidades-colaboraciones (C R C ) se aplica para
con las siguientes características: (1) rep resen tación de d o c u m e n ta r las clases y sus atributos y operaciones.
las clases y jerarq u ías de clases, (2) creación de m o d e T am bién p ro p o rc io n a u n a vista inicial de las colabora
los o b jeto-relación, y (3 ) o btención de m odelos objeto- ciones que ocurren entre los objetos. El siguiente paso
com portam iento. en el A O O es la clasificación de objetos y la creación
El análisis de sistem as orientados a objetos se re ali de u n a je ra rq u ía de clases. L o s sistem as (paquetes) se
za a m uchos niveles diferentes de abstracción. E n l o s pueden u tiliz a r para en ca p su lar o b jeto s relacionados.
niveles de em presa o de negocio las técnicas asociadas E l m o d e lo o b je to -re la c ió n p ro p o rc io n a inform ación
con e l an álisis se p u ed en co n ju g a r con el en fo q u e de sobre las c o n ex io n es entre las clases, m ientras que el
www.FreeLibros.org
in g e n ie ría del p ro ceso de negocio. A estas técn icas a m odelo objeto-com portam iento rep re se n ta el compor
m enudo se las llam a de análisis del dom inio. E n el nivel tam iento de l o s o b jeto s individualm ente y el global de
de im plem en tació n el m odelo de objetos se cen tra en todo el sistem a.
376
CAPÍTULO 21 A N Á LI S IS O RI EN TA D O A O B JE T O S
[ALH98] Alhir, S.S., UML m a Nutshell, O ’Reilly & Asso [FIC92] Fichman, R.G., y Kemerer, C.F., O bject-O riented
ciates, Inc. 1998. a nd C onventional A n a ly sis and D esign M ethodologies,
[AMB95] Ambler, S., «Using Use-Cases», Software Deve Computer, vol. 25, n.° ÍO,Octubre 1992,pp. 22-39.
lopment, Julio 1995,pp. 53-61 [FTN96] Fingar, P., The B lu ep rin tfo rB u sin ess O bjects, Cam
[ARA89] Arango, G., y Prieto-Diaz, R., «Domain Analysis: bridge University Press, 1996.
Concepts and Research Directions», D om ain A nalysis: [FIR93] Firesm ith, D.G., Object. O riented R eq u erim en ts
A cquisition o f R eusable Inform ation f o r Software Cons- A nalysis and L ogical D esign, Wiley, 1993.
truction (G. Arango y Prieto-Diaz, eds.), IEEE Computer
Society Press, 1989. [JAC92] Jacobson, I., Object-Oriented Software Engineering,
Addison-Wesley, 1992.
[BER93] Berard, E.V., Essays on O bject-O riented Software
Engineering, Addison-Wesley, 1993. [JAC99] Jacobson, I., Booch, G., y Rumbaugh, J., U nified
Software D evelopm ent Process, Addison-Wesley, 1999.
[BEN99] Beneth, S., S. McRobb y R. Farmer, O bject-O rien
ted System A nalysis and D esign Usign UNL, McGraw- [MAT94] M attison, R., The O b ject-O rien ted E nterprise,
Hill, 1999. McGraw Hill, 1994.
[B0094] Booch, G., O bject-O riented A nalysis and D esign, [MON92] Monarchi, D.E., y Puhr, G.I., «A Research Typo-
2 r ed., Benjamín Cummings, 1994. logy for Object-Oriented Analysis and Design», CACM,
vol. 35, n.° 9, Septiembre 1992,pp. 35-47.
[B0099] Booch, G., Jacobson, I.,y Rumbaugh, J., The Unified
Modeling Language User Guide, Addison-Wesley, 1999. [RUM91] Rumbaugh, J., et al., O bject O rientedM odelling
[CAR98] Carmichael,A., Developing Business Objects, SIGS and D esign, Prentice-Hall, 1991.
Books, 1998. [RUM99] Rumbaugh, J., Jacobson, I.,y Booch, G., The U ni
[CHA93] de Champeaux, D., D. Lea, y P. Faure, O bject- fie d M o d ellin g Language R eference M a n u a l, Addison-
O riented System D evelopm ent, Addison-Wesley, 1993. Wesley, 1999.
[C0A91] Coad, P., y E. Yourdon, O bject-O riented A nalysis, [SUL94] Sullo, G.C., O bject Engineering, Wiley, 1994.
2.a ed., PrenticeHall, 1991 [TAY95] Taylor, D.A., B usiness E ngineering w ith O b ject
[EEL98] Eeles, P,. y Simms, O., B uilding B usiness Objects, Technology, Wiley, 1995.
Wiley, 1998.
[WIR90] Wirfs-Brock,R., Wilkerson,B., y Weiner, L., Desig-
[ERI98] Eriksson, H.E., y Penker,M., UMLToolkit, Wiley, 1998. ning O bject O riented Software, Prentice-Hall, 1990.
S m O B L E M A S Y P ÜNT QS A CONS I DE RAR
21.1. Hágase con uno o más libros sobre UML y compárelo 21.5. Escriba un caso de uso para el sistema HogarSeguro. Los
con el análisis estructurado (Capítulo 12) utilizando las dimen casos de uso deben tratar el escenario requerido para establecer
siones de modelado propuestas por Fichman y Kemerer una zona de seguridad. Una zona de seguridadlleva asociado un
[FIC92] en la Sección 21.1.1. conjuntode sensores que pueden ser accedidos, activados y desac
tivados no individualmente sino en conjunto. Debe ser posible
21.2. Desarrolle una clase-presentación sobre un diagrama
definir hasta diez zonas de seguridad. Sea creativo, pero intente
estático o dinámico de UML. Presente el diagrama en el con mantenerse dentro de lo definido para el panel de control del sis
texto de un ejemplo sencillo, pero intente mostrar el suficien tema tal y como fue definido previamente en este libro.
te nivel de detalle como para demostrar los aspectos más
importantes del tipo de diagrama elegido. 21.6. Desarrolle un conjunto de casos de uso para el sistema
SSRB del Problema 12'. 13.
21.3. Conduzcaun análisis del dominio para una de las siguien
tes áreas: Tendrá que hacer varias suposiciones sobre la form a de
interacción del usuario con el sistema.
a) Un sistema para almacenarlos expedientes de los alumnos
de una universidad. 21.7. Desarrolle un conjunto de casos de uso para alguna de
las siguientes aplicaciones:
b) Una aplicación de comercio electrónico (p.e. ropa, libros,
a) Software para un asistente personal electrónico de propó
equipos electrónicos, etc.)
sito general.
c) Un servicio al cliente para un banco.
b) Software para un videojuego de su elección.
d) El desarrollo de un videojuego. c) Software para el sistema de climatización de un auto
www.FreeLibros.org
e) Un área de aplicación propuesta por su instructor. móvil.
21.4. Describa con sus propias palabras la diferencia entre las d) Software para un sistema de navegación de un automóvil.
vistas estática y dinámica de un sistema. e) Un sistema propuesto por su instructor.
377
I N GEN IE RI A DEL S O F TW A RE . UN EN F O Q U E P R Á C T I C O
Lleve a cabo una pequeña investigación (unas pocas horas) en 21.13. Desarrolle un modelo objeto-comportamiento para el
el dominio de la aplicación y conduzca una reunión TFEA producto o sistema elegido en el problema 21.7. Asegúrese de
(Capítulo 11) con sus compañerospara desarrollar unos requi listar todos los sucesos,proporcionar la traza de sucesos, desa
sitos básicos (su instructor le ayudará a coordinarlo). rrollar un diagrama de flujo de sucesos y definir diagramas de
21.8. Desarrolle un conjunto completo de tarjetas CRC del estado para cada clase.
producto o sistema elegido en el problema anterior.
21.14. Describa con sus propias palabras la forma de deter
21.9. Dirija una revisión de las tarjetas CRC con sus colegas.
minar los colaboradores de una clase.
¿Cuántas clases, responsabilidades y colaboraciones adicio
nales ha añadido a consecuencia de la reunión? 21.15. ¿Qué estrategia propondría para definir subsistemasen
21.10. Desarrolle una jerarquía de clases para el producto o colecciones de clases?
sistema elegido en el Problema 21.7.
21.16. ¿Qué papel desempeña la cardinalidad en el desarrollo
21.11. Desarrolle un conjunto de subsistemas (paquetes) para
de un modelo objeto-relación?
el producto o sistema elegido en el Problema 21.7.
21.12. Desarrolle un modelo objeto-relaciónpara el producto 21.17. ¿Cuál es la diferencia entre los estados pasivo y activo
o sistema elegido en el Problema 21.7. de un objeto?
O T R A S . liE d ltR A S ..X .J E IU E H ÍT E S P E lM .f i

Los casos de uso forman la base del análisis orientado a obje Douglas, B., Real-Time UML:Developing Efficient Objects
tos, sin importar el método de AOO elegido. Los libros de fo r Embedded Systems, Addison-Wesley, 1999.
Rosemberg y Scott (Use case driven Object modelling with Fow ler,M .,y Kendall Scott, UMLDistilled, 2.a ed., Addison-
UML: apracticalapproach, Addison-Wesley, 1999), Schnei- Wesley, 2000.
der, Vinters y Jacobson (Applying Use Cases: A Practical Gui-
de, Addison-Wesley, 1999), y Texel y Williams (Use Cases Larman, C., Applying UML andPatterns: an Introductionto
CotnbinedWithBooch/OMT/UML: Process and Products, Pren- Object Oriented Analysis, Prentice-Hall, 1997.
tice-Hall, 1997) proporciona una guía para la creación y uso Odell, J.J., y Fowler, M., Advanced Object Oriented Analy
de esta importante herramienta de obtención de requisitos y sis and Design Using UML, SIGS Books, 1998.
mecanismo de representación. Ostereich,B., Developing Software with UML: ObjectOrien-
Casi todos los libros publicados recientemente sobre aná tedAnalysis and Design inPractice, Addison-Wesley, 1999.
lisis y diseño orientado a objetos ponderan UML. Todos los
Page-Jones, M., Fundamentáis of Object-Oriented Design in
que están considerando en serio aplicar UML en su trabajo,
UML, Addison-Wesley, 1999.
deberían comprar [B 0 0 9 9 ], [JAC99] y [RUM99]. Además
Stevens, P., y Pooley, R., Software Engineering with
de estos, los siguientes libros también son representativos de
Objects and Components, Addison-Wesley, 1999.
las docenas de ellos escritos sobre la tecnología de UML:
En Internet hay gran cantidad de fuentes de información sobre
Douglas,B., y Booch, G.,DoingHard Time:DevelopingReal- análisis orientado a objetos y temas relacionados. Una lista actua
Time Systems with UML, Objects, Frameworks and Pat- lizada sobre las referencias web relevantes de cara a l análisis
terns, Addison-Wesley, 1999. orientado a objetos la encontrará en http://www.pressman5.com
C A P ÍT U L O
22 DISEÑO ORIENTADO A OBJETOS
L d iseñ o o rien tad o a o b jeto s transform a el m odelo de an álisis cread o usando análisis
E orientado a objetos (C apítulo 21), en un m odelo de diseño que sirve com o antep ro y ecto
para la construcción de softw are. El trabajo de diseñador de softw are puede ser in tim i
dante. G am m a y sus colegas [G A M 95] proveen un panoram a razonablem ente ex acto del D O O
cuando d eclaran que:
El diseño de softw are orientado a objeto s es difícil, y el diseño de softw are reusable orientado a o b je
tos es aun m ás difícil. Se deb en identificar lo s ob jeto s p ertin en tes, clasificarlos d entro de las clases en la
granularidad correcta, definir interfaces de clases y je ra rq u ía s de h erencia y establecer relaciones clave entre
ellos. El diseño debe ser específico al problem a que se tien e entre m anos, pero suficientem ente general para
adaptarse a problem as y req u erim ien to s futuros. A d e m ás se d eberá e v ita r el rediseño, o por lo m enos m in i
m izarlo. L o s d iseñ ad o res e x p erim en tad o s en O O dicen que un diseño reu sab le y flexible es difícil, si no
im posible de o b ten er « b ien » , la prim era vez. A ntes de que un diseño sea term in ad o , usu alm en te tratan de
reutilizarlo varias veces, m odificándolo cada vez.
A diferencia de los m étodos de diseño de softw are convencionales, el D O O proporciona un

diseño que alcanza diferentes niveles de m odularidad. L a m ayoría de los com ponentes de un sis
tem a, están organizados en subsistem as, un «m ódulo» a nivel del sistem a. Los datos y las o p e
raciones que m anipulan los datos se encapsulan en objetos —una form a m o d u lar que es el bloque
de constru cció n de un sistem a O O — . A dem ás, el D O O debe describir la organización específi
c a de los datos de los atributos y el detalle procedural de cada operación. Estos representan datos
y piezas algorítm icas de un sistem a OO y son los que contribuyen a la m odularidad global.
VISTAZO RÁPIDO
¿Qué es? El diseño d e softw are Orientado el principio, pero m uchas o tra s pueden nentes: la in terfazd eu su ario , la g e stió n
a objetos req u iere la definición d e una ser re u tiliz ad a s, si s e reconocen los de datos y los m ecanism os d e adminis
arq u itec tu ra d e softw are m u lticap a, la patro n es d e diseño apropiados. El DOO tración d e tareas. Ei diseño d e obj etos se
esp ecificaciónde su b sistem as que re a establece un anteproyecto d e d iseñ o ,q u e cen tra e n los d e ta lle s internos d e c a d a
lizan fu n cio n es n e c e s a ria s y proveen perm ite a l ingeniero d e softw are definir c lase, definición d e atributos. operacio
soporte de infraestructura, u n a d escrip la arquitectura OO, e n form a que maxi- n e s y d e ta lle s d e l os m en sq es.
ción d e objetos (clases),que so n lo sb lo - mice la reutilización; d e e s ta m anera, se ¿Cuál es e l p r o d u c to «Munido? El mode
qu es d e construccióndel sistem a, y una m ejora la velocidad del desarro llo y la lo d c diseño OO a b a rc a arquitectura de
descripciónde los m ecanism osdecom u- c a lid a d del producto term inado. softw are, descripción d e la interfaz d e
nicación, que perm iten que los datos Bu- ¿C uáles s o n los p a s o s ? E l DOO se divide usu ario , com p o n en tes d e g e stió n d e
ya n e n tre la s c a p a s, s u b s is te m a s y e n dos g ra n d e s actividades: diseño del datos. m ecanism osde ad m in istració n de
objetos. El Diseño O rien tad o a O bjetos siste m a y d ise ñ o d e objetos. El diseño de tareas y descripciones detalladas d e cada
(DOO), cum ple todos estos requisitos. sistem a c rea l a arquitectura del produc una d e la s clases u sa d a s e n el sistema.
¿ Q u ié n l o h a c e ? El D O O lo realiza un to definiendo una serie d e «capas», que ¿ C ó m o p u e d o «wtar se g u ro d e q u e lo
ingeniero d e software. cum plen funcionesespecíficas d e lsiste - h e h e c h o c o r r e c t a m e n t e ? En c a d a
¿Por q u é e s i m p o r t a n t e ? Un sistem a m a e identifica 1a s clases, q u e son encap- e ta p a , lo s e le m e n to s d e l m o d e lo d e
orientado a objetosutiliza la s definicio su la d a s p o r los su b siste m asq u ere sid en d ise ñ o o rientado a objetos son re v isa
nes d e la s cla se s d eriv ad as del m odelo en c a d a capa. dos por clarid ad , corrección, integridad
d e an álisis. A lg u n a s d e e s ta s defm icio- A dem ás, el diseño d e sistem as incor y c o n siste n c ia c o n los r e q u is ito s del
nes ten d rá n q u e ser co n stru id as desd e pora la e sp e cific a ció n d e tre s com po cliente y e n tre ellos.
L a n atu raleza Única del diseño orientado a objetos, reside en su capacidad para construir cua
tro c o n cep to s im p o rtan tes de d iseño de softw are: ab stracció n , o cu ltam ien to (o cu ltació n ) de
inform ación, in dependencia funcional y m odularidad (C apítulo 13). Todos los m étodos de dise
ño p ro cu ran softw are que exhiba estas características fundam entales, pero sólo el D O O provee
un m ecanism o que perm ite al diseñador alcanzar las cuatro, sin com plejidad ni com prom iso.
www.FreeLibros.org
El diseño orientado a objetos, la program ación orientada a objetos, y las pruebas orientadas
a objetos son actividades de construcción para sistem as O O . E n este capítulo se considera el
p rim er paso en la construcción.
379
I N GE NIE RÍA DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
E n el C apítulo 13 se introdujo el concepto de u na pirá form a los cim ientos sobre los que la pirám ide se sostie
m ide de diseño p ara el softw are convencional. C uatro ne. La capa fundamental se centra en el diseño de los obje
capas de diseño - - d a to s , arquitectura, interfaz y nivel tos del dom inio (11am adospatronesde diseño). Los objetos
de c o m p o n e n t e s - fuero n definidas y discutidas. P ara del d o m iniojuegan un papel clave, en la construcción de
sistem as orientados a objetos, podem os tam b ién definir la infraestructura del sistem a O O aportando soporte para
un a p irám id e, p ero las cap as son un p o co diferentes. las actividades de interfaz hom bre/m áquina, administra
Refiriéndose a la Figura 22.1, las cuatro capas de la pirá ción (gestión) de tareas y gestión (administración) de datos.
m ide de diseño O O son: L os objetos del dom inio se pueden usar, adem ás, para
La capa subsistem a. C ontiene u n a representación d esarro llarel diseño de la aplicación en s í mism a.
de cada uno de los subsistem as, p ara p erm itir al soft
w are conseguir sus requisitos definidos p o r el cliente e 22.1.1. E n fo q u e c o n v e n c io n a l v s. O O
im p lem en tar la infraestructura q u e soporte los req u eri
Los enfoques convencionalespara el diseño de software
m ientos del cliente.
aplican distintas notaciones y conjunto de heurísticas,
para trazar el m odelo de análisis en un m odelo de dise
Q c /to : ño. R ecordando la Figura 13.1, cada elem ento del mode
En el diseño, configuramos el sistema lo convencional de análisis se corresponde con uno o
f encontramos su forma... m ás capas del m odelo de diseño. A l igual que el dise
hrtr Jwobson, Grsdy Boodi y James Rumbough. ño convencional de softw are, el D O O aplica el diseño
de datos cuando los atributos son representados, el di
La capa de clases y objetos. C ontiene la je rarq u ía señ o de in te rfa z cu an d o s e d e sa rro lla un m o d elo d e
de clases, q u e p erm iten al sistem a ser cread o usando m ensajería, y diseño a nivel de com ponentes (procedi-
generalizaciones y cada v ez esp ecializacionesm ás acer m ental), para operaciones de diseño. Es im portante notar
tadas. E sta capa tam b ién contiene representaciones. que la arquitectura de un diseño OO tiene m ás que ver
La capa de mensajes. C ontiene detalles de diseño, con la colaboración entre objetos que con el control de
que p erm ite a cada objeto com unicarse con sus colabo flujo entre com ponentes del sistem a.
radores. E sta capa establece interfaces externas e in ter A pesar de que existen sim ilitudes entre los diseños
nas p ara el sistem a. convencionales y 0 0 , se h a optado p o r renom brar las
La capa de responsabilidades. C ontiene estructu capas de la pirám ide de diseño, para reflejar con mayor
ras de datos y diseños algorítm icos, p ara tod o s los atri precisión la naturaleza de un diseño O O . L a Figura 22.2
buto s y operaciones de cada objeto. ilustra la relación entre el m odelo de análisis 0 0 (Capí
tulo 21) y el m odelo de diseño que se derivará de ahí'.
Diséfto de clases y objetos
Bisafto íNusaujssjstemas
F IG U R A 2 2.1. La pirámide del Diseño OO.
Ei m o d elo d e diseño
L a pirám ide de diseño se centia exclusivam ente en el
diseño de un p roducto o sistem a específico. O bserve, sin F IG U R A 2 2.2. Transform ación de un m odelo de análisisOO
em bargo, que existe otra capa de diseño, y que esta capa a un m odelo de diseño OO.
www.FreeLibros.org
1 Es im p o rtan te h acer n o tar que la derivación n o e s siempre
evidente. Para profundizar véase [DAV95],
380
CAPÍTULO 22 DISEÑO ORIE NT ADO A O B JE T O S
E l d is e ñ o d e s u b s is te m a s s e d e r iv a c o n s id e r a n d o lo s • c o n tin u id a d : la h a b ilid a d p a r a h a c e r p e q u e ñ o s c a m
r e q u e r im ie n to s g lo b a le s d e l c lie n t e ( r e p r e s e n ta d o s p o r b io s e n u n p r o g r a m a y q u e s e r e v e le n h a c ie n d o lo s
lo s c a s o s d e u s o ) y l o s s u c e s o s y e s t a d o s q u e s o n e x t e r c a m b io s p e r tin e n t e s e n u n o o m u y p o c o s m ó d u lo s .
n a m e n te o b s e r v a b le s ( e l m o d e lo d e c o m p o r t a m ie n t o d e • p r o t e c c ió n : u n a c a r a c t e r í s t ic a a r q u it e c t ó n ic a , q u e
o b j e t o s ) . E l d i s e ñ o d e c la s e s y o b j e t o s e s t r a z a d o d e l a r e d u c e la p r o p a g a c ió n d e e f e c t o s c o la te r a le s , s i o c u
d e s c r ip c ió n d e a t r ib u t o s , o p e r a c io n e s y c o la b o r a c io n e s r r e u n e r r o r e n u n m ó d u lo d a d o .
c o n t e n id a s e n e l m o d e lo C R C . E l d is e ñ o d e m e n s a je s e s
m a n e ja d o p o r e l m o d e lo o b je t o - r e la c ió n , y e l d is e ñ o d e
r e s p o n s a b ilid a d e s e s d e r iv a d o d e l u s o d e a t r ib u t o s , o p e
r a c io n e s y c o la b o r a c io n e s d e s c r it o e n e l m o d e lo C R C . Referencia W e b ^
F ic h m a n y K e m e r e r [ F I C 9 2 ] s u g ie r e n d ie z c o m p o Una referencia que responde a la pregunta ¿qué hace
n e n te s d e d is e ñ o m o d e la d o , q u e p u e d e n u s a r s e p a r a c o m que un diseño orientado o objetos sea bueno?, puede
p a r a r v a r io s m é to d o s c o n v e n c io n a le s y o r ie n t a d o s a encontrarse en: www.kinetico.com/ootips/ood-
o b je t o s : principles.html
1. r e p r e s e n ta c ió n d e la je r a r q u í a d e m ó d u lo s .
2 . e s p e c i f i c a c i ó n d e la s d e f i n i c i o n e s d e d a t o s . D e e s to s c r it e r io s , M e y e r [ M E Y 9 0 ] , s u g ie r e c in c o
p r in c ip io s b á s ic o s d e d is e ñ o , q u e p u e d e n s e r d e d u c id o s
3 . e s p e c i f i c a c i ó n d e l a l ó g i c a procedimental.
p a r a a r q u it e c t u r a s m o d u la r e s : ( 1 ) u n id a d e s lin g ü í s t ic a s
4 . in d ic a c ió n d e s e c u e n c ia s d e p r o c e s o f i n a l - a - f i n a l
m o d u la r e s , ( 2 ) p o c a s in te r fa c e s , ( 3 ) p e q u e ñ a s in t e r f a
(end-to-end)
c e s ( a c o p la m ie n t o d é b il) , ( 4 ) in te r fa c e s e x p lí c it a s y ( 5 )
5. r e p r e s e n t a c i ó n d e e s t a d o s y t r a n s i c i o n e s d e l o s o c u lt a c ió n d e in f o r m a c ió n .
o b je t o s .
6 . d e f i n i c i ó n d e c la s e s y j e r a r q u í a s . ¿Qué principios básicos
7 . a s i g n a c i ó n d e o p e r a c i o n e s a la s c la s e s .
8 . d e f in ic i ó n d e t a lla d a d e o p e r a c io n e s .
9 . e s p e c i f i c a c i ó n d e c o n e x i o n e s d e m e n s a je s .
§ nos guian en el diseño
de arquitecturas modulares?
1 0 . id e n t if ic a c ió n d e s e r v ic io s e x c lu s iv o s . L o s m ó d u lo s s e d e f in e n c o m o u n id a d e s lin g ü í s t ic a s
m o d u la r e s , c u a n d o « c o r r e s p o n d e n a u n id a d e s s in t á c t i
c a s e n e l le n g u a je u s a d o » [ M E Y 9 0 ] , E s d e c ir , e l le n
¿Qué criterio se puede usar
§ para comparar los métodos

convencionalesy los métodos
de DOO?
g u a je d e p r o g r a m a c ió n q u e s e u s a r á d e b e s e r c a p a z d e
d e f in ir d ir e c ta m e n te la m o d u la r id a d . P o r e je m p lo , s i e l
d is e ñ a d o r c r e a u n a s u b r u t in a , c u a lq u ie r a d e lo s le n g u a
j e s d e p r o g r a m a c ió n a n t ig u o s ( F O R T R A N , C , P a s c a l) ,
Y a q u e e x is te n m u c h o s e n fo q u e s d e d is e ñ o c o n v e n d e b e p o d e r im p le m e n ta r lo s c o m o u n a u n id a d s in t á c t i
c i o n a le s y o r i e n t a d o s a o b j e t o s , e s d i f í c i l d e s a r r o l l a r u n a c a . P e r o s i u n p a q u e te q u e c o n tie n e e s tr u c tu r a s d e d a to s
c o m p a r a c ió n g e n e r a liz a d a e n tr e lo s d o s m é to d o s . S in y p r o c e d im ie n t o s , y lo s id e n t if ic a c o m o u n a s o la u n i
e m b a r g o , s e p u e d e a s e g u r a r q u e la s c o m p o n e n t e s d e d a d d e f i n i d a , e n u n l e n g u a j e c o m o A d a (u o t r o l e n g u a
m o d e la d o 5 a l 1 0 n o e s tá n s o p o r ta d a s u s a n d o d is e ñ o j e o r ie n t a d o a o b je t o s ) , s e rá n e c e s a r io r e p r e s e n ta r
e s t r u c t u r a d o ( C a p í t u lo 1 4 ) o s u s d e r iv a d o s . d ir e c ta m e n te e s te t ip o d e c o m p o n e n te e n la s in t a x is d e l
le n g u a je .
22.1.2. A s p e c to s d e l d is e ñ o P a r a lo g r a r e l b a jo a c o p la m ie n t o ( u n c o n c e p t o d e
d is e ñ o in t r o d u c id o e n e l C a p ítu lo 1 3 ), e l n ú m e r o d e
B e r tra n d M e y e r [ M E Y 9 0 ] s u g ie r e c in c o c r it e r io s p a r a
in te r fa c e s e n tr e m ó d u lo s d e b e m in im iz a r s e ( « p o c a s
ju z g a r la c a p a c id a d d e m é t o d o s d e d is e ñ o p a r a c o n s e
in te r fa c e s » ) , y la c a n tid a d d e in f o r m a c ió n q u e s e m u e
g u ir m o d u la r id a d , y lo s r e la c io n a a l d is e ñ o o r ie n t a d o a
v e a tr a v é s d e la in t e r f a z t a m b ié n d e b e s e r m in im iz a d a
o b je t o s :
( « p e q u e ñ a s in t e r f a c e s » ) . S ie m p r e q u e lo s c o m p o n e n te s
» descomponibilidad: l a f a c i l i d a d c o n q u e u n m é t o d o s e c o m u n ic a n , d e b e n h a c e r lo d e m a n e r a o b v ia y d ir e c
d e d is e ñ o a y u d a a l d is e ñ a d o r a d e s c o m p o n e r u n p r o ta ( « in te r fa c e s e x p líc ita s » ) . P o r e je m p lo , s i e l c o m p o
b le m a g r a n d e e n p r o b le m a s m á s p e q u e ñ o s , h a c ié n n e n te X y e l c o m p o n e n te Y s e c o m u n ic a n m e d ia n te e l
d o lo s m á s f á c il d e r e s o lv e r . á re a d e d a to s g lo b a l (a lo q u e s e lla m a a c o p la m ie n to
• com ponibilidad e l g r a d o c o n e l q u e u n m é t o d o d e c o m ú n e n e l C a p ítu lo 1 3 ), v io la n e l p r in c ip io d e in te r
d is e ñ o a s e g u r a q u e lo s c o m p o n e n te s d e l p r o g r a m a fa c e s e x p líc ita s p o r q u e la c o m u n ic a c ió n e n tr e c o m p o
( m ó d u lo s ) , u n a v e z d is e ñ a d o s y c o n s tr u id o s , p u e d e n n e n te s n o e s o b v ia a u n o b s e r v a d o r e x te r n o . F in a lm e n te ,
s e r r e u t i l i z a d o s p a r a c r e a r o t r o s s is t e m a s . s e lo g r a e l p r i n c ip i o d e o c u lta m ie n to d e in f o r m a c ió n ,
www.FreeLibros.org
• comprensibilidad l a f a c i l i d a d c o n l a q u e e l c o m p o c u a n d o to d a in fo r m a c ió n a c e rc a d e u n c o m p o n e n te se
n e n te d e u n p r o g r a m a p u e d e s e r e n te n d id o , s in h a c e r o c u lta a l a c c e s o e x te r n o , a m e n o s q u e e s a in fo r m a c ió n
r e f e r e n c ia a o t r a in f o r m a c ió n o m ó d u lo s . s e a e s p e c íf ic a m e n te d e f in id a c o m o p ú b lic a .
38 1
I N GEN IE RI A DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
L os criterios y principios de diseño p resentados en to s en fatiza el esq u em a d etallad o de un ob jeto in d iv i

esta sección p u ed en ser aplicados a cualq u ier m étodo dual. Se se le c c io n a n las o p e ra c io n e s del m o d e lo de
de diseño (así co m o al diseño estructurado). C om o se an álisis, y los alg o ritm o s se d efin en para cad a opera
verá, el m étodo de diseño orientado a objetos logra cada ción. Se rep resen ta n las e stru ctu ras de datos apropia
uno de los criterios m ás eficientem ente que otros en fo das p a ra atributos y algoritm os. L as clases y atributos
ques, y resu lta en arquitectu rasm o d u lares, que cum plen de clase son diseñ ad o s de m a n era que se optim ice el
efectivam ente cada u no de los criterios. acceso a los datos, y se m ejo re la efic ien c ia com puta-
cional. Se crea un m o d elo de m en sajería, p a ra im ple
m en ta r re la cio n e s de o b jeto s (asociaciones).
22.1.3. £1 Panorama de DOO
C om o se v io en el C ap itu lo 21, u n a gran v ariedad de E l método de Jacobson. E l d is e ñ o p a ra ISO O
m étodos de análisis y diseño orientados a objetos fue (In g en iería del softw are o rien tad a a ob jeto s) [JAC92]
es u n a v e rsió n sim p lific a d a del m é to d o p ro p ie ta rio
propuesta y utilizada durante los ochenta y los n o v en
O b je c to ry , ta m b ié n d e s a rro lla d o p o r Ja c o b so n . El
ta. E stos m étodos establecieron los fundam entos para
la n o tació n m od ern a de D O O , h eurísticas de d iseño y m o d e lo d e d ise ñ o e n fa tiz a la p la n ific a c ió n p a ra el
m o d e lo d e a n á lis is IS O O . E n p rin c ip io , el m o d elo
m odelos. A continuación, h arem os u n a b reve revisión
id e a liz a d o d e a n á lis is se a d a p ta p a ra a c o p la rs e al
global de los prim eros m étodos de D OO:
am b ie n te del m u n d o real. D e sp u é s lo s o b je to s de
E l método de Booch. C om o se v io en el C apítulo d ise ñ o p rim a rio s, lla m a d o s bloques so n c re a d o s y
21, el m étodo B o o ch [B 0 0 9 4 ] abarca un «proceso de
catalogados com o bloques de interfaz, bloques de enti
m icro desarrollo» y un «proceso de m acro desarrollo». d a d e s y b lo q u e s de co n tro l. L a c o m u n ic a c ió n entre
En el contexto del diseño, el m acro d esarrollo engloba b lo q u es du ran te la ejecu ció n se d efine y los bloques
una actividad de planificación arquitectónica, que agrupa se o rg an izan en subsistem as.
objetos sim ilares en particiones arquitectónicas separa
das, capas de objetos p o r nivel de abstracción, id enti E l método de Coad y Yourdon. É ste m étodo para
D O O [COA91 ], se desarrolló estudiando «cóm o es que
fica situaciones relevantes, crea un prototipo de diseño
los d iseñ ad o res orientados a objetos efectivos» hacen
y valid a el prototipo aplicándolo a situaciones de uso.
su trabajo. La aproxim ación de d iseño dirige no sólo la
El m icro d esarrollo define un conjunto de «reg las» que
aplicación, sino tam bién la infraestructura de la aplica
regu lan el uso de o p eraciones y atributos y las políticas
ción, y se enfoca en la representación de cuatro com
del d o m in io e s p e c ífic o p a ra la a d m in istra c ió n de la
p o n e n te s m a y o re s de sistem as: la co m p o n en te de
m em o ria, m an ejo de erro res y o tras fu n cio n es; d e sa
d o m in io del pro b lem a, la co m p o n en te de interacción
rro lla s itu a c io n e s que d e s c rib e n la se m á n tic a de las
hum ana, la com ponente de adm inistración de tareas y
reglas y políticas; crea un prototipo p ara cada política;
la de adm inistración de datos.
instrum enta y refina el prototipo; y revisa cada política
para así «tran sm itir su visión arquitectónica» [B 0 0 9 4 ], E l método de Wirfs-Brock. W irfs-B rock, Wilker-
son y W einer [W IR 90] d efin en un co n ju n to de tareas
QgH a: técnicas, en la cual el análisis conduce sin duda al diseño.
Los p ro to co lo s3 para cada clase se construyen refinando
líe existe rozón por lo que la transición de la fase de contratos entre objetos. C ada operación (responsabili
jq p s & o s o lo de diseño no debería ser más fácil en dad) y protocolo (diseño de interfaz) se diseña hasta un
ja Ingeniería de software que en cualquier otra nivel de detalle que guiará la im plem entación. Se desa
dfcdpSna de ingeniería. El diseño es difícil. rrollan las especificaciones para cada clase (definirres-
fcStelifflidi. p o n sa b ilid ad e s p riv a d as y d etalles de operaciones) y
cad a subsistem a (identificar las clases encapsuladasy
E l método de Rumbaugh. La técnica de m odelado
la interacción entre subsistem as).
de objetos (T M O ) [R U M 91] e n g lo b a una actividad de
diseño que alienta al diseño a ser conducido a dos d ife
ren tes niveles de ab stracció n . El d iseñ o de sistem a se
cen tra en el esquem a de los com ponentes que se n e ce
Aunque no es tan robusto como UML, el método Wirfs-
sitan p ara c o n stru ir un sistem a o p ro d u cto com pleto.
Brock tiene uno elegancia sencilla, que lo convierte
El m o d e lo de a n á lisis se d iv id e en su b siste m a s, los en un enfoque alternativo e interesante al DOO.
cu ales se asig n an a p ro c e sa d o re s y tareas. Se define
una e strateg ia p ara im p le m e n ta r la ad m in istra c ió n de A p esar de que la te rm in o lo g ía y etapas de proceso
dato s, y se id e n tific a n los recu rso s y m ec a n ism o s de p ara cad a uno de e sto s m éto d o s de D O O difieren, los
co n tro l requeridos p ara accesarlos. El d iseñ o de o b je p ro c e so s d e D O O g lo b a l so n b a sta n te consistentes.
www.FreeLibros.org
2 Un bloque e s la abstracción de diseño, que permite la representa- 3 Un protocolo e s una descripción formal de los m ensajes, a los que
ción de un objeto agregado. la clase responde.
382
CAPÍTULO 22 D IS E Ñ O OR IE N TA DO A O B J E T O S
P ara lle v a r a cab o un d iseñ o o rien tad o a o b je to s, un E s ta s p r o p o r c io n a r o n u n a v i s i ó n in t e r n a a l u s o d e la s

ingeniero de softw are debe e je c u ta r las siguientes e ta s itu a c io n e s p a r a e l s is t e m a ( f a c il it a n d o g u ía s p a r a e l
pas g enerales: m o d e la d o d e c o m p o r t a m ie n t o ) , y e s ta b le c ie r o n f u n d a
1. D escrib ir cada subsistem a y asignar a procesadores m e n to s p a r a la im p le m e n t a c ió n y v is t a s d e l m o d e lo
y tareas. a m b ie n t a l, id e n t if ic a n d o y d e s c r ib ie n d o e le m e n to s
e s t r u c t u r a l e s e s t á t i c o s d e l. s i s t e m a .
2. E leg ir u n a estrateg ia p ara im p lem en tar la adm inis
U M L s e o r g a n iz a e n d o s a c t iv id a d e s m a y o r e s :
tración de datos, soporte de interfaz y adm inistración
d is e ñ o d e l s is t e m a y d is e ñ o d e o b je t o s . E l p r i n c ip a l
de tareas.
o b je t iv o d e U M L , d is e ñ o d e s is t e m a , e s r e p r e s e n t a r
3. D iseñ ar un m ecan ism o de co n tro l, p ara el sistem a la a r q u it e c t u r a d e s o ftw a r e . B e n n e tt, M c R o b b y F a r -
apropiado. m e r [ B E N 9 9 ] , e x p o n e n e s te a s p e c to d e la s ig u ie n te
4 . D iseñ ar objetos c rean d o una rep resen tación proce- m a n e ra :
dural para cada o p eració n , y estructuras de datos para E n térm in o s de desarro llo o rie n ta d o a o b jeto s, la a rq u i
los atributos de clase. te c tu ra c o n ce p tu a l e s tá re la c io n a d a c o n la e stru c tu ra del
5. D iseñar m ensajes, usando la colab o raciónentre o b je m o d elo e stá tic o d e c la se y las c o n e x io n e s e n tre las c o m
po nentes d el m o d elo . El m o d elo a rq u ite c tu ra d e sc rib e la
tos y relaciones.
m anera co m o el sistem a se d iv id e en su b siste m a s o m ó d u
6. C rear el m odelo de m ensajería. los, y co m o se co m u n ican e x p o rta n d o e im p o rta n d o datos.
7. R ev isar el m odelo de d iseñ o y re n o v a rlo ca d a vez L a a rq u ite c tu ra d e c ó d ig o , d e fin e c o m o es q u e el c ó d ig o
del pro g ram a se e n cu e n tra org an izad o en a rc h iv o s y d ire c
que se requiera.
to rio s y a g rupado e n librerías. L a a rq u itec tu ra de ejecu ció n
se c en tra en los asp ecto s din ám ico s del siste m a y la c o m u
n ica ció n e n tre c o m p o n e n te s, m ie n tra s las ta re a s y o p e ra
CLAVE ciones se ejecutan.
Un conjunto de etapas genéricas se aplica durante L a d e f in ic i ó n d e « s u b s is t e m a s » , n o m b r a d a p o r B e n

el D00, sin importar el método de diseño que se escoja. n e t t e t a l . , e s u n a p r e o c u p a c i ó n p r i n c i p a l d u r a n t e e l dise
ño d e s i s t e m a d e U M L .
Es im portante h acer n o ta r q u e las etapas de diseño
discutidas en e sta sección son iterativas. E so significa
que deb en ser ejecutadas in crem entalm ente, ju n to con
las actividades de A O O , h asta que se p ro duzca el d ise CLAVE
ño com pleto. E¡ diseño de sistema se centra en arquitectura
de software y definición de subsistemas.
B diseño de objetos describe objetos, hasta
22.1.4. U n e n f o q u e u n i f i c a d o p a r a e l D O O un nivel en el cual puedan ser implementados,
En el C ap ítu lo 21, se m en cio n ó co m o G rady B o o ch , en un lenguaje de programación.
Jam es R u m b a u g h e Iv a r J a c o b s o n , c o m b in a ro n las
m ejores cualidades de sus m éto d o s p ersonales de aná E l d is e ñ o d e o b je t o s s e c e n t r a e n l a d e s c r ip c ió n d e
lisis y d iseñ o o rien tad o a o b je to s, e n un m éto d o u n i o b je t o s y s u s in te r a c c io n e s c o n lo s o t r o s . U n a e s p e c if i
ficado. El resultado, llam ado el L e n g u a j e d e M o d e l a d o c a c i ó n d e t a l l a d a d e la s e s t r u c t u r a s d e d a t o s d e l o s a t r i
U n i f i c a d o , se h a v u e lto a m p lia m e n te u sa d o e n la b u t o s y d i s e ñ o p r o c e d u r a l d e t o d a s la s o p e r a c i o n e s , s e
indu stria4. c r e a d u r a n t e e l d is e ñ o d e o b je t o s . L a v i s ib ilid a d 5 p a r a
to d o s lo s a t r ib u t o s d e c la s e s e d e f in e , y la s in t e r f a c e s
e n tr e o b je t o s s e e la b o r a n p a r a d e f in ir lo s d e ta lle s d e u n
m o d e lo c o m p le t o d e m e n s a je s .
Referencia E l d is e ñ o d e s is t e m a s y o b je t o s e n U M L s e e x t ie n
Untutorial y listado extenso de recursos de UML incluyendo d e p a r a c o n s id e r a r e l d is e ñ o d e in t e r f a c e s , a d m in is
herramientas, referenciasy ejemplos, t r a c ió n d e d a to s c o n e l s is t e m a q u e s e v a a c o n s t r u ir
se pueden encontrar en: m¡n¡.net/(etus/oo_uml.html y a d m i n is t r a c ió n d e ta r e a s p a r a lo s s u b s is te m a s q u e
s e h a n e s p e c if ic a d o . L a in t e r f a z d e u s u a r io e n U M L
D u r a n t e e l m o d e lo d e a n á lis is ( C a p í t u lo 2 1 ) , s e r e p r e u t iliz a lo s m is m o s c o n c e p to s y p r in c ip io s e x a m in a
s e n t a n la s v i s t a s d e l m o d e l o d e u s u a r i o y e s t r u c t u r a l . d o s e n e l C a p ítu lo 1 5 . L a v is ió n d e l m o d e lo d e u s u a -
www.FreeLibros.org
4 Booch, R um baugh y Jacobson han escrito tres libros muy im por 5 Visibilidad indica si el atributo es público (disponible a través de
tan te s sobre UML. El lector interesad o debe co n su lta r [B 0099], todas las instancias de la clase),privado (disponible sólo para la clase
[RUM99] y LÍAC99] que lo especifica) o protegido (un atributo que puede ser usado por
la clase que lo especifica y por sus subclases).
383
rio maneja el proceso del diseño de la interfaz de

usuario, proporcionando una situación que se elabo
ra iterativamente, para volverse un conjunto de cla
ses de interfaz6. La administración de datos establece
un conjunto de clases y colaboraciones, que permi
ten al sistema (producto) manejar datos persistentes
(por ejemplo, archivos y bases de datos). El diseño
de la administración de tareas establece la infraes
tructura que organiza subsistemas en tareas, y admi
nistra la concurrencia de tareas. El flujo de procesos
para el diseño se ilustra en la Figura 22.3’.
A lo largo del proceso de diseño UML, la visión del
modelo de usuario y de estructura se elabora dentro del
diseño de la representación delimitada anteriormente.
Esta actividad de elaboración se analiza en las seccio
nes siguientes. F IG U R A 2 2 . 3 . Flujo de Proceso para DOO.
El diseño de sistema desarrolla el detalle arquitectóni particiona el modelo de análisis, para definir colecciones
co requerido para construir un sistema o producto. El congruentes de clases,relaciones y comportamiento. Estos
proceso de diseño del sistema abarca las siguientes acti elementos de diseño se definen como subsistema.
vidades:
• Partición del modelo de análisis en subsistemas. (c O N S E Ifl^
• Identificar la concurrencia dictada por el problema. las conceptos de cohesión y acoplamiento (Capítulo 131
• Asignar subsistemas a procesadores y tareas. pueden aplicarse o nivel de subsistemas. Esfuércese
• Desarrollar un diseño para la interfaz de usuario. par alcanzar uno buena Independencia funcional,
cuando diseñe subsistemas
• Elegir una estrategia básica para implementar la
administración (gestión) de datos. En general, todos los elementos de un subsistema
• Identificar recursos globales y los mecanismos de comparten alguna propiedad en común. Y se integran
control requeridos para su acceso. para completar la misma función; deben residir dentro
del mismo producto de hardware, o deben administrar
¿Cuáles son las etapas la misma clase de recursos. Los subsistemas se caracte-
« del proceso de diseño

de sistemas?
rizanpor susresponsabilidades; eso significa que un sub
sistemapuede identificarsepor los servicios que provee
[RUM91 ]. Cuando se usa en el contexto de un diseño de
sistema 00, un servicio es una colección de operacio
• Diseñar un mecanismo de control apropiado para el
sistema, incluyendo administración de tareas. nes que llevan a cabo una función específica (por ejem
• Considerar cómo deben manejarse las condiciones plo, administrar archivos de procesador de textos,
de frontera. producir un ren derin g tridimensional, traducir una señal
de vídeo analógica en una imagen digital comprimida).
• Revisar y considerar trade-offs.
En las secciones siguientes, el diseño de actividades , ¿Qué criterios nos guían
relacionadas con cada una de estas etapas se conside
ran con mayor detalle. t en el diseño de subsistemas?
Cuando se definen (y diseñan) los subsistemas, se

deben seguir los siguientes criterios de diseño:
22.2.1. P articionar e l m o d e lo d e a n á lis is • El subsistema debe tener una interfaz bien definida,
Uno de los principios fundamentales del análisis (Capí a través de la cual se reduzcan todas las comunica
tulo 11 jes hacer particiones. En el diseñode sistemasOO ciones con el resto del sistema.
www.FreeLibros.org
6 Hoy en día la m ayoría de las clases de interfaz son parte de una 7 Recuerde que el AOO e s una actividad iterativa. Es totalm ente posi
librería de c o m p o n e n tes de softw are reutilizables. Esto facilita el ble que el m odelo de análisis sea revisado com o consecuencia del
diseño e im plem entación de IGUs (Interfaz gráfica de u su a rio ). trabajo de diseño.
384
CAPÍTULO 22 D IS E Ñ O O R I E N T A D O A O BJ E TO S
• C o n l a e x c e p c i ó n d e u n p e q u e ñ o n ú m e r o d e « c la s e s 6 . D e f i n i r e l m o d e lo d e m e n s a je r ía p a r a la c o m u n ic a
d e c o m u n ic a c ió n » , la s c la s e s in c l u id a s d e n t r o d e l c ió n e n tr e c a p a s .
s u b s i s t e m a d e b e n c o l a b o r a r s ó l o c o n o t r a s c la s e s d e n 7. R e v i s a r e l d i s e ñ o d e c a p a s , p a r a a s e g u r a r q u e e l a c o
t r o d e l s u b s is te m a . p la m ie n to e n tr e c a p a s s e m in im iz a ( u n p r o t o c o lo
• E l n ú m e r o d e s u b s is t e m a s d e b e s e r b a jo . c lie n t e / s e r v id o r p u e d e a y u d a r a r e a liz a r e s ta ta r e a )
• U n s u b s is te m a p u e d e s e r p a r t ic io n a d o in te r n a m e n te ,
8. I t e r a r p a r a r e f in a r e l d is e ñ o d e c a p a s .
p a r a a y u d a r a r e d u c ir la c o m p le jid a d .
C u a n d o d o s s u b s is t e m a s s e c o m u n ic a n e n t r e s í, p u e
d e n e s t a b l e c e r u n enla ce c lien telservid o r o u n e n l a c e 22.2.2. A sig n a c ió n d e c o n c u rre n c ia y s u b s is te m a s
piinto-a-punto (peer-to-peer) [ R U M 9 1 ] . E n u n e n l a c e E l a s p e c to d in á m ic o d e l m o d e lo o b je t o - c o m p o r t a m ie n
c lie n t e / s e r v id o r , c a d a u n o d e lo s s u b s is t e m a s a s u m e u n o t o p r o v e e u n a i n d i c a c i ó n d e c o n c u r r e n c i a e n t r e c la s e s ( o
d e lo s p a p e le s im p lic a d o s , e l d e e l c lie n t e o e l d e l s e r s u b s i s t e m a s ) . S i la s c la s e s ( o s u b s i s t e m a s ) n o s e a c t i v a n
v id o r . E l s e r v ic io f l u y e d e l s e r v id o r a l c lie n t e e n u n a al m i s m o t i e m p o , n o h a y n e c e s id a d p a r a e l p r o c e s a m i e n t o
s o la d i r e c c i ó n . E n u n e n l a c e p u n t o - a - p u n t o , l o s s e r v i c o n c u r r e n t e . E s t o s i g n i f i c a q u e la s c la s e s ( o s u b s i s t e m a s )
c io s p u e d e n f l u i r e n c u a lq u ie r d ir e c c ió n . p u e d e n s e r im p le m e n ta d a s e n e l m is m o p r o c e s a d o r d e
C u a n d o u n s is t e m a e s p a r t ic io n a d o e n s u b s is te m a s , h a r d w a r e . P o r o t r o la d o , s i la s c la s e s ( o s u b s is t e m a s )
se lle v a a c a b o o t r a a c t iv id a d d e d is e ñ o , lla m a d a e s tr a d e b e n a c tu a r e n s u c e s o s a s in c r ó n ic a m e n te y a l m is m o
t if ic a c ió n p o r c a p a s . C a d a c a p a [ B U S 9 6 ] d e u n s is t e m a t ie m p o , s e v e r á n c o m o c o n c u r r e n te s . C u a n d o lo s s u b
0 0 . c o n t ie n e u n o o m á s s u b s is te m a s y r e p r e s e n t a u n s is t e m a s s o n c o n c u r r e n t e s , e x is t e n d o s o p c io n e s d e a l o
n iv e l d if e r e n t e d e a b s tr a c c ió n d e la f u n c io n a lid a d r e q u e - ja m ie n t o : ( 1 ) a lo ja r c a d a s u b s is te m a e n p r o c e s a d o r e s
r id a p a r a c o m p le t a r la s f u n c io n e s d e l s is t e m a . E n la in d e p e n d ie n t e s ó ( 2 ) a l o ja r lo s s u b s is t e m a s e n e l m is m o
m a y o r ía d e lo s c a s o s , lo s n iv e le s d e a b s tr a c c ió n s e d e t e r p r o c e s a d o r y p r o p o r c io n a r s o p o r te d e c o n c u r r e n c ia , s o b r e
m in a n p o r e l g r a d o e n q u e e l p r o c e s a m ie n t o a s o c ia d o la s c a r a c t e r í s t ic a s d e l s is t e m a o p e r a t iv o .
c o n e l s u b s is te m a e s v is i b le a l u s u a r io f in a l.
P o r e je m p lo , u n a a r q u it e c t u r a d e c u a tr o c a p a s d e b e ^C O N S E JO ^.
in c lu ir : ( 1 ) u n a c a p a d e p r e s e n t a c ió n ( e l s u b s is te m a a s o
c ia d o c o n l a in t e r f a z d e u s u a r io ) , ( 2 ) u n a c a p a d e a p l i En la mayoría ríe los casas, unaimplementoción
demultiproceso incrementóla compkjidady el riesgo
c a c i ó n ( e l s u b s is t e m a q u e l l e v a a c a b o p r o c e s o s a s o c ia d o s
técnica. Siempre que sea posible, escojo lo orquitecturo
c o n l a a p l i c a c i ó n ) , (3) u n a c a p a d e f o r m a t o d e d a t o s ( l o s
de procesada más simple que pueda realizar el trobojo.
s u b s is t e m a s q u e p r e p a r a n l o s d a t o s p a r a s e r p r o c e s a d o s ) ,
y ( 4 ) u n a c a p a d e b a s e d e d a to s ( e l s u b s is t e m a a s o c ia d o L a s t a r e a s c o n c u r r e n t e s s e d e f i n e n [R U M 9 1 ] e x a
c o n la a d m in is t r a c ió n d e d a to s ) . C a d a c a p a s e e n c u e n m in a n d o e l d ia g r a m a d e e s ta d o p a r a c a d a o b je t o . S i e l
tr a m á s p r o f u n d a m e n t e d e n t r o d e l s is t e m a , r e p r e s e n t a n f l u jo d e s u c e s o s y tr a n s ic io n e s in d ic a q u e s o lo u n o b je
d o u n p r o c e s a m ie n to m á s e s p e c íf ic o a l a m b ie n te . t o e s tá a c tiv o e n e l t ie m p o , u n h ilo d e c o n t r o l s e h a e s ta
b le c id o . E l h i lo d e c o n t r o l c o n tin ú a , a u n c u a n d o u n
¿Cómo se crea un diseño
§ por capas?
B u s c h m a n n y s u s c o le g a s [ B U S 9 6 ] s u g ie r e n e l
s ig u ie n t e e n f o q u e d e d i s e ñ o p a r a e s t r a t i f i c a c i ó n p o r c a p a s :
o b je t o e n v í a u n m e n s a je a o t r o o b je t o , m ie n t r a s q u e e l
p r im e r o b je t o e s p e r a p o r la r e s p u e s ta . S in e m b a r g o , s i
e l p r im e r o b je t o c o n tin ú a p r o c e s a n d o d e s p u é s d e e n v ia r
u n m e n s a je , e l h i l o d e c o n t r o l s e d iv id e .
1. E s t a b l e c e r l o s c r i t e r i o s d e e s t r a t i f i c a c i ó n p o r c a p a s . L a s ta r e a s e n u n s is t e m a 0 0 s e d is e ñ a n g e n e r a n d o
E s to s ig n if ic a d e c i d ir c ó m o s e a g r u p a r á n lo s s u b s is h ilo s d e c o n t r o l a is la d o s . P o r e je m p lo , m ie n tr a s q u e e l
te m a s e n u n a a r q u it e c t u r a d e c a p a s . s is t e m a d e s e g u r id a d H o g a r S e g u r o m o n i t o r iz a s u s s e n
2. D e t e r m in a r e l n ú m e r o d e c a p a s . M u c h a s d e e lla s s o res , p u e d e t a m b i é n m a r c a r a l a e s t a c i ó n c e n t r a l d e
c o m p lic a n in n e c e s a r ia m e n te ; m u y p o c a s d e b ilit a n la m o n it o r iz a c ió n p a r a v e r if i c a r la c o n e x ió n . Y a q u e lo s
in d e p e n d e n c ia f u n c io n a l. o b je t o s in v o lu c r a d o s e n a m b o s c o m p o r t a m ie n t o s e s tá n
3. N o m b r a r la s c a p a s y a s i g n a r s u b s i s t e m a s ( c o n s u s a c tiv o s a l m is m o t ie m p o , c a d a u n o r e p r e s e n ta u n h i lo
c la s e s e n c a p s u l a d a s ) a u n a c a p a . A s e g u r a r s e d e q u e d e c o n t r o l y c a d a u n o p u e d e s e r d e f in id o c o m o u n a ta re a
la c o m u n ic a c ió n e n t r e s u b s is t e m a s ( c la s e s ) e n u n a d is tin ta . S i la m o n ito r iz a c ió n y m a r c a d o o c u r r ie r a n
c a p a 8, y o t r o s s u b s i s t e m a s ( c l a s e s ) e n o t r a c a p a , s e c u e n c ia lm e n te , p o d r í a im p le m e n t a r s e u n a s o la ta r e a .
s ig u e n la f i lo s o f í a d e d is e ñ o d e la a r q u it e c t u r a . P a r a d e t e r m i n a r c u á l d e la s o p c i o n e s d e a s i g n a c i ó n
4 . D is e ñ a r in te r fa c e s p a r a c a d a c a p a . d e p r o c e s a d o r e s e s a p r o p ia d a , e l d is e ñ a d o r d e b e c o n s i
5. R e f i n a r l o s s u b s i s t e m a s , p a r a e s t a b l e c e r l a e s t r u c t u r a d e r a r lo s r e q u is it o s d e d e s e m p e ñ o , c o s to s y e l e n c a b e
d e c la s e s p a r a c a d a c a p a . z a d o im p u e s t o p o r la c o m u n ic a c ió n e n tr e p r o c e s a d o r e s .
www.FreeLibros.org
8 Eli una arquitectura cetrada, los m en sajes p ro c ed e n te s de una
capa se deberían h a b er en v iad o a la capa a d y ac en te inferior. En
una a rq u ite c tu ra abierta, los m e n s a je s d eb en e n v ia rse a c u a l
quiera de las c a p a s inferiores.
385
ING EN IE RÍA DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
22.2.3. C o m p o n e n t e d e a d m i n i s t r a c i ó n d e t a r e a s interfazpor sí misma representa un subsistemade impor

C o a d y Y o u r d o n [ C O A 9 1 ] s u g ie r e n la e s tr a te g ia s ig u ie n tancia críticapara la mayoría de las aplicacionesmoder
te , p a r a e l d is e ñ o d e o b je t o s q u e m a n ip u la n ta r e a s c o n nas. El modelo de análisis OO (Capítulo 21), contiene
c u rre n te s : los escenarios de uso (llamados c a s o s de u so ), y una
« s e d e t e r m i n a n la s c a r a c t e r í s t i c a s d e l a t a r e a .
descripción de los roles que-juegan los usuarios (lla
mados a c to re s) cuando interactúan con el sistema. Este
« s e d e fin e u n c o o r d in a d o r d e ta r e a y o b je t o s a s o c ia
modelo sirve como entrada al proceso de diseño de inter
dos.
faz de usuario.
• s e in t e g r a e l c o o r d in a d o r y o tr a s ta re a s .
L a s c a r a c te r ís tic a s d e la ta r e a s e d e t e r m in a n , c o m
p r e n d ie n d o c ó m o e s q u e s e in ic ia la ta r e a . L a s ta re a s
Ia mayoríade las clases necesariasparacrear
c o n t r o la d a s p o r s u c e s o s y m a n e ja d a s p o r r e l o j s o n
unainterfaz modernayaexisteny están disponibles
la s m á s c o m u n e s . A m b a s s e a c t iv a n p o r u n a i n t e
parael diseñador. Bdiseñode interfaz obedece
r r u p c ió n , p e r o la p r im e r a r e c ib e u n a in t e r r u p c ió n d e
al enfoque definidaenel Capítulo15.
a lg u n a fu e n t e e x te r n a ( p o r e je m p lo , o t r o p r o c e s a d o r ,
u n S e n s o r ) , m ie n tr a s q u e la ú lt im a e s c o n t r o la d a p o r
e l r e lo j. Una vez que el actor y su situación de uso se defi
nen se identifica unajerarquía de comando. La jerar
quía de órdenes define la mayoría de las categorías del
menú de sistema (la barra de menú o la paleta de herra
$$cspl¡M y el conocimiento centrado... mientas), y todas las subfunciones, que estarán dispo
.tsajtísuyen ol ocio de creación. nibles en el contexto de una categoría importante de
menú de sistema (las ventanas de menú). La jerarquía
de órdenes se refina repetidamente, hasta que cada caso
A d e m á s d e la m a n e r a e n q u e u n a ta r e a e s in ic ia de uso pueda ser implementado navegando por lajerar
d a , ta m b ié n s e d e b e n d e t e r m in a r la p r io r id a d y c r i- quía de funciones.
t ic id a d d e la ta r e a . L a s ta r e a s d e a lta p r io r id a d d e b e n Debido a que existe una amplia variedad de entor
t e n e r a c c e s o in m e d ia t o a lo s r e c u r s o s d e l s is t e m a . nos de desarrollo de interfaces de usuario, el diseño de
L a s ta re a s d e a lta c r it ic id a d d e b e n c o n tin u a r o p e los elementos de una IGU (Interfaz Gráfica de Usuario)
r a n d o a u n c u a n d o la d is p o n ib ilid a d d e u n r e c u r s o e s no es necesario. Ya existen clases reutilizables (con atri
r e d u c id a o e l s is t e m a o p e r a t iv o s e e n c u e n t r a e n e s ta butos y operaciones apropiadas) para ventanas, iconos,
d o d e g ra d a d o . operaciones de ratón y una amplia gama de otro tipo de
U n a v e z q u e la s c a r a c t e r í s t ic a s d e la ta r e a s e h a n funciones de interacción. La persona que implementa
d e t e r m in a d o , s e d e f in e n lo s a t r ib u t o s y o p e r a c io n e s estas clases (el desarrollador), sólo necesita instan ciar
d e l o b je t o r e q u e r id o , p a r a a lc a n z a r c o o r d in a c ió n y objetos, con las características apropiadas para el domi
c o m u n ic a c ió n c o n o tr a s ta re a s . L a p la n t illa b á s ic a d e nio del problema.
u n a ta r e a ( p a r a u n o b je t o ta r e a ) , to m a la f o r m a d e
[C O A 9 1 ]:
Nombre de l a ta rea - e l nombre d e l o b je to 22.2.5. C o m p o n e n te d e l a a d m i n i s t r a c i ó n
D e sc rip c ió n - un r e l a t o que d e s c r ib e e l p r o p ó s ito d e d a to s
d e l o b je t o .
P rio rid a d - p r io r id a d de l a tarea (por ejem plo, a l t a ,
La administración o gestión de datos engloba dos áre
media, b a j a ) . as distintas de interés: (1) la administración (gestión)
S e r v i c i o s - l i s t a de o p e r a c io n e s que so n r e s p o n s a de datos críticos para la propia aplicación, y (2 ) la crea
b i l i d a d d e l o b je to . ción de infraestructura para el almacenamiento y recu
C oordinados p o r - l a manera como se invoca e l com peración de los objetos. En general, la administración
p o rta m ie n to d e l o b je t o . de datos se diseña en forma de capas. La idea es aislar
Comunicados v ía - d a to s de en trada y s a lid a r e l e los requisitos de bajo nivel que manipulan las estructu
va n tes a l a ta rea . ras de dafos, de los requisitos de alto nivel para mane
L a d e s c r ip c ió n d e e s ta p la n t illa p u e d e s e r tr a d u c id a jar los atributos del sistema.
e n e l m o d e lo d e d is e ñ o e s tá n d a r ( in c o r p o r a n d o la r e p r e En el contexto del sistema, un sistema de manipula
s e n ta c ió n d e a t r ib u t o s y o p e r a c io n e s ) , p a r a lo s o b je t o s ción de bases de datos, normalmente se usa como alma
ta re a . cén de datos común para todos los subsistemas. Los
objetos requeridos para manipular la base de datos son
miembros de clases reutilizables que se identifican
www.FreeLibros.org
22.2.4. C o m p o n e n t e d e in t e r f a z d e u s u a r i o mediante el análisis del dominio (Capítulo 21), o que
A u n q u e la c o m p o n e n te d e in t e r f a z d e u s u a r io s e im p le - se proporcionan directamente por el fabricante de la
m e n ta d e n tr o d e l c o n t e x t o d e l d o m in io d e l p r o b le m a , la base de datos. Una discusión detallada del diseño de
386
CAPÍTULO 22 DI SE ÑO ORIE NT ADO A O BI ETO S
bases de datos p ara sistem as O O está fuera del ám bito debe diseñar un m ecanism o de control para ello. R um -
de este libro'. b a u g h y sus colegas [RUM 91] sugieren que cad a rec u r
El d iseñ o de la co m p o n en te de ad m in istrac ió n de so deba ser poseído po r un «objeto guardián». E l objeto
datos incluye el diseño de los atributos y operaciones guardián es el portero del recurso, controlando el acce
requeridas p ara ad m inistrar objetos. L os atributos sig so y m oderando peticiones contradictorias para é l.
nificativos se añaden a cad a o b jeto en el d o m in io del
problem a, y p ro p o rcio n an inform ación que responde a 22.2.7. Com unicaciones entre subsistem as
la preg u n ta «¿C óm o m e alm aceno?». C o a d y Y ourdon
U na vez que cad a subsistem a h a sido especificado, es
[CO A 91] aco n sejan la cre a c ió n de u n a c lase objeto-
necesario definir las colaboraciones que e x iste n entre
servidor, « con los servicios de (a) in d icar al objeto que
subsistem as. E l m odelo que se usa para la colaboración
se alm acene a sí m ism o, y (b) recu p erar objetos alm a
objeto-objeto puede ser extendido en conjunto para los
cenados p ara su uso p o r otros com ponentes de diseño».
subsistem as. L a Figura 2 2.4 ilustra un m odelo de c o la
C om o un ejem plo de la gestión de los datos para el
boración. C om o se vio anteriorm ente e n este cap ítu lo ,
objeto Sensor, ex am in ad o co m o p arte del sistem a de
la com unicación puede ocurrir estableciendo un enlace
SQgaridadHogarSeguro, el diseño puede especificar un
cliente/servidor o punto-a-punto.R efiriéndose a la F ig u
archivo llam ado «Sensor». C ada registro debería co rres
ra, se debe e sp e cific ar la in terac ció n que e x iste en tre
ponder a una instancia denom inada Sensor, y habría de
subsistem as. R ecuérdese que un contrato proporciona
contener los valores de cada atributo de Sensor para una
la indicación de los m odos com o un subsistem a puede
instancia dada. Las operaciones dentro de la clase objeto-
interactuar con otro.
servidor d e b e ría n p e rm itir a u n o b jeto e sp e c ífic o ser
alm acenado y recuperado, cuando sea requerido p o r el
¿Qué etapas de diseño
sistem a. P ara o b jeto s m ás co m p lejo s, sería n ecesario
especificar una base de datos relacional, o una base de
datos orientada a objetos para eje c u ta rla m ism a función. • se requieren para especificar
un «contrato» de un subsistema?
Las siguientes etapas de diseño pueden aplicarsepara

especificar un contrato para un subsistem a [W IR 90]:
1. L ista r ca d a p etició n que p u e d e ser rea liza d a p o r los
co laboradores del subsistem a. O rg an izar las p e ti
ciones p o r subsistem a y definirlas dentro de uno o
m ás contratos apropiados. A segurarse de anotar co n
tratos que se h ereden de superclases.
2 P ara cada contrato. anotar las operaciones (la sh ere
dadas y las p r iv a d a s .) que se requieren p a r a im ple-
m entar las responsabilidades que im plica el contrato.
A segurarse de asociar las operaciones con las clases
específicas, que residen en el subsistem a.
3 C onsiderar un contrato a la vez. crear una tabla con
la fo r m a de la .F igura 22.5. P a ra cada contrato, la
tabla debe incluir las siguientes colum nas:
FIG URA 22 .4. Modelo de colaboración entre subsistemas. Tipo: el tipo de contrato (por ejem plo, cliente/
servidor o punto-a-punto).
22.2.6. Componente de gestión de recursos

Están d isponibles u n a v aried ad de recursos diferentes
para un sistem a o p roducto 0 0 ; y , m uch as veces, los
subsistem as com piten p o r estos recursos al m ism o tiem
po. Los recursos globales del sistem a p u eden ser en ti
dades ex tern as (p o r e je m p lo , u n a u n id ad de d isco ,
procesador o línea de co m unicaciones) o abstracciones
(por ejem plo, u n a base de datos, u n objeto). Sin im por
tar la n aturaleza del re c u rso , el ingeniero de softw are FIG URA 2 2 .5 . Tabla de c o la b o ra c io n e s del su b sistem a.
www.FreeLibros.org
9 Los lectores in te resad o s deben c o n su lta r [BR091], [TAY92] y
[RA094]
387
IN GE NI ER ÍA DEL S O F TW A RE . UN EN F O Q U E P R AC T I C O
C olabor ador es . l o s n o m b r e s d e l o s s u b s i s t e g r a f o d e c o la b o r a c ió n e s s im ila r , e n f o r m a , a l d ia

m a s q u e s o n p a rte d e l c o n tra to . g r a m a d e f l u jo d e s u c e s o s e x a m in a d o e n e l C a p í
Clase: l o s n o m b r e s d e la s c la s e s ( c o n t e n i d a s e n t u l o 2 1 . C a d a s u b s is te m a s e r e p r e s e n ta , j u n t o c o n
e l s u b s is te m a ) , q u e p r o p o r c io n a n s e r v ic io s d e n o s u s in t e r a c c io n e s c o n o t r o s s u b s is te m a s . L o s c o n
ta d o s p o r e l c o n tr a to . t r a t o s q u e se i n v o c a n d u r a n t e i n t e r a c c i ó n , s e d e t a
l l a n c o m o s e m u e s t r a e n la F ig u r a . L o s d e t a lle s
Operaciones: n o m b r e s d e la s o p e r a c i o n e s ( d e n
t r o d e la c la s e ) , q u e im p le m e n t a n lo s s e r v ic io s . d e la in t e r a c c ió n se d e t e r m in a n o b s e r v a n d o e l c o n
t r a t o e n la t a b la d e c o la b o r a c ió n d e l s u b s is te m a
Formato del mensaje: e l f o r m a t o d e l m e n s a j e
( F ig . 2 2 .5 ) .
r e q u e r id o p a r a im p le m e n t a r la in t e r a c c ió n e n tr e
c o la b o r a d o r e s .
E s b o c e u n a d e s c r ip c ió n a p r o p ia d a d e l m e n s a je ,
p a r a c a d a i n t e r a c c i ó n e n t r e l o s s u b s is t e m a s .
4. Si los m odos de interacción entre los subsistem as Coda c o r t a b entre sLbssfema se m a n fe s b por uno o
son com plejos, debe crear un diagram a su b sis mós mensajes que se tansporfen entre los c b p b s dentro
tem a-colaboración como el de la F igura 22.6. E l de los sLbssfemos
22.3 PBOC£S jQ.,D£ PISENQ PE QBIETQS

R e to m a n d o la m e tá f o r a q u e s e in t r o d u jo a l in ic io d e l o b j e t o , y d e t a l l e s d e p r o c e d i m i e n t o s , q u e d e s c r i b e n la s
l i b r o , e l d i s e ñ o d e s is t e m a s O O s e p u e d e v i s u a l i z a r c o m o o p e r a c io n e s .
e l p la n o d e l s u e lo d e u n a c a s a . E l p la n o d e l s u e lo e s p e
c if ic a e l p r o p ó s it o d e c a d a h a b it a c ió n y s u s c a r a c te r ís ^C O W S E IO ^L
t i c a s a r q u i t e c t ó n i c a s , q u e c o n e c t a n la s h a b i t a c i o n e s u n a s
c o n o tr a s y c o n e l a m b ie n te e x t e r io r . A h o r a e s e l m o m e n Asegúrese de que lo arquitectura se ha definido
antes de comenzar e I diseño de objetos. No deje
to d e p r o p o r c io n a r lo s d e ta lle s q u e s e r e q u ie r e n , p a r a
que lo arquitecturapredomine.
c o n s t r u ir c a d a h a b it a c ió n . E n e l c o n t e x t o d e l D O O , e l
d i s e ñ o d e o b j e t o s s e c e n t r a e n la s « h a b i t a c i o n e s » . L a d e s c r ip c ió n d e l p r o t o c o lo n o es na da m ás que un
B e n n e t y s u s c o le g a s [ B E N 9 9 ] e x a m in a n e l d is e ñ o c o n ju n t o d e m e n s a je s y u n c o m e n t a r io c o r r e s p o n d ie n
d e o b je t o s d e la s ig u ie n te m a n e r a : te p a r a c a d a m e n s a je . P o r e je m p lo , u n a p o r c ió n d e l p r o
El diseño de objetos tiene que ver con el diseño detallado t o c o lo d e d e s c r ip c ió n p a r a e l o b je t o s e n s o r d e
de los objetos y sus interacciones. Se com pleta d en tro de la m o v im ie n t o ( d e s c r ito a n t e r io r m e n te ), p o d r ía s e r:
arquitecturaglobal, definida durante el diseño del sistem a y de
MENSAJE (sensor, movimi ento) -> le e r : DEVUELVE sen-
acuerdo con las reglas y protocolos de diseño aceptados. El
so r.ID , se n so r.e sta d o ;
diseño del objeto está relacionado en p articular con la especi
ficación de los tipos de atributos, cóm o fun cio n an las o pera E s to d e s c r ib e e l m e n s a je r e q u e r id o p a r a le e r e l S e n
ciones y cóm o los objetos se enlazan con otros objetos.
s o r. Ig u a lm e n te ,
E s e n e s ta fa s e c u a n d o lo s p r in c ip io s y c o n c e p to s MENSAJE (sensorm ovim iento) — > a s ig n a : ENVIA sen-
b á s ic o s a s o c ia d o s c o n e l d is e ñ o a n i v e l d e c o m p o n e n so r.ID , se n so r.e sta d o ;
t e s ( C a p í t u l o 1 6 ) e n t r a n e n j u e g o . S e d e f i n e n la s e s t r u c
tu r a s d e d a to s lo c a le s ( p a r a a t r ib u t o s ) , y s e d is e ñ a n lo s A s ig n a ( e s ta b le c e ) o in ic ia l iz a e l e s ta d o d e l S e n s o r.
a lg o r it m o s ( p a r a o p e r a c io n e s ) .
S u b s is te m a S u b s is te m a
p a ra el p a n e l sensor
22.3.1. D escrip ción d e objetos d e c o n tro l S o lic itu d d e a s ig n a c ió n
d e e s ta d o p a ra la z o n a
U n a d e s c r ip c ió n d e l d is e ñ o d e u n o b je t o ( in s ta n c ia d e
S o lic itu d de d e e s ta d o d e p ru e b a
c la s e o s u b c la s e ) p u e d e t o m a r u n a o d o s f o r m a s
e s p e c ific a c ió n
[ G O L 8 3 ] : ( 1 ) Una descripción de protocolo q u e e s t a d e l tip o de
b le c e la in t e r f a z d e u n o b je t o , d e f in ie n d o c a d a m e n s a je chequeo S o lic itu d d e n o tific a c ió n
p e rió d ic o p e rió d ic a d e l c h e q u e o
q u e e l o b j e t o p u e d e r e c i b i r y la s o p e r a c i o n e s q u e e l o b j e d e a c tu a liza c ió n d e la
d e e s ta d o
t o l l e v a a c a b o c u a n d o r e c i b e u n m e n s a j e , o ( 2 ) Una des d e la a la rm a c o n fig u ra c ió n d e a la rm a
cripción de im plem entación q u e m u e s t r a d e t a l l e s d e d e l s is te m a
im p le m e n t a c ió n p a r a c a d a o p e r a c ió n im p lic a d a p o r u n
m e n s a je p a s a d o a u n o b je t o . L o s d e t a lle s d e im p le -
www.FreeLibros.org
m e n t a c ió n in c lu y e n in f o r m a c ió n a c e r c a d e la p a r te p r i
v a d a d e l o b je t o ; e s to s ig n if ic a , d e ta lle s in t e r n o s a c e r c a F IG U R A 2 2 .6 . Gráfico a b re v ia d o del subsistem a colaborado
d e la e s t r u c t u r a d e d a to s , q u e d e s c r ib e n lo s a t r ib u t o s d e l de H o g a rS e g u ro .
388
CAPÍTULO 22 DISEÑO ORIENTADO A OBJETOS
P ara un sistem a grande con m uchos m ensajes, g en e u s a m

ralm ente es p osible crear categorías de m ensajes. P or Aparentemente, cada concepto que se presentó
ejem plo, categorías de m ensajes p ara el objeto Sistem a en el Capítulo 13 es también oplicoble aquí.
d e H ogarSeguro d eberían incluir m ensajes de co nfigu Asegúrese de estar familiorizado con los temas
ración del sistem a, m ensajes de m onito rización (su p er presentados en el Capítulo 13.
v isión), m ensajes de sucesos, etc.
U n a descripción de la im plem entación de un objeto, Se c rea un algoritm o para im plem entar la especifi
p ro p o rcio n a los d etalles in tern o s (« o c u lto s» ), q u e se cació n para cad a operación. E n m u ch as ocasio n es, el
req u ieren para la im plem entación, pero n o son n ece sa alg o ritm o es una sim ple secu en ciaco m p u tacio n alo pro-
rios p ara ser invocados. E sto significa que el diseñador cedural, que puede ser im plem entada co m o un m ódulo
del objeto debe p ro p o rcio n ar u n a d escripción de im ple- de softw are autocontenido. Sin em bargo, si la especifi
m entación, y debe p o r tanto crear los d etalles internos c a c ió n de la o p e ra c ió n es co m p le ja , será n e c e sa rio
del objeto. Sin em bargo, otro d iseñador o desarrollador m o dularizar la operación. L as técnicas convencionales
que utilice el objeto u otras instancias del objeto, req u ie de diseño de com ponentes se pueden usar para resolver
re solo la descripción del protocolo, pero no la descrip esta tarea.
ción de la im plem entación. L as estructuras de datos se diseñan al m ism o tie m
U na descripción de la im plem entación se com pone de po que los algoritm os. Ya que las operaciones m an ip u
la siguiente inform ación: (1) una especificación del n o m lan los atributos de una clase, el diseño de estructuras
bre del objeto y referen cia a la clase; (2) una especifica de datos, que reflejan m e jo r los atrib u to s, tendrán un
ción de las estructuras de datos p rivadas, con indicación fuerte sentido en el diseño algorítm ico de las operacio
de los datos y sus respectivos tipos; (3 ) una descripción nes correspondientes.
de procedim ientos de cada operación o , alternativam en
te, indicadores a dichas d escripciones de p ro cedim ien M ¿Existe alguna manera
tos. La d escripción de im plem entación debe co n ten er w de clasificar las operaciones
inform ación suficiente,para el m anejo adecuado de todos (métodos)?
los m ensajes descritos en la descripción de protocolo.
A unque existen m uchos tipos diferentes de o p e ra
ciones, norm alm ente se pueden dividir en tres grandes
CLAVE categorías: (1) operaciones que m anipulan los datos de
alg u n a m a n e ra (p o r ejem p lo , ag regando, elim in an d o ,
Para alcanzar los beneficios del ocuitamlento
reform ateando, seleccionando),(2) operaciones que eje
de Información (Capítulo 13), cualquiera que Intente
cutan cálculos, y (3) operaciones que m onitorizan (super
usar un objeto solo necesítalo descripción
del protocolo. La descripción de la Implementación visan) al objeto para la ocurrencia de un suceso controlado.
contiene detalles, que deberían «ocultarse» P o r ejem p lo , la d e scrip ció n del p ro ceso H ogarSe-
de aquellos que no tienen necesidad de conocer. guro contiene los fragm entos de la oración: «al sensor
se asigna un núm ero y tipo» y «una contraseña (pass-
Cox [COX85] caracterízala diferencia entre la in fo r word) m aestra program ada para habilitar y deshabilitar
m ación c o n te n id a en la d escripción de p ro to c o lo y la el sistem a». E stas dos frases indican varias cosas:
contenida en la d escripción de im plem entación, en té r . Q ue u n a operación de asignación es im portante para
m inos de «usuarios» y «proveedores» de servicios. U n el objeto Sensor.
«usuario» del servicio pro v isto p o r un objeto debe ser ■ Q ue u n a operación p ro g ra m a r se aplicará al objeto
fam iliar con el p rotocolo de invocación del servicio; eso
Sistem a.
significa especificar lo que se desea. El p roveedor del
servicio (el pro p io objeto), debe ocuparse del m odo en • Q ue las operaciones h a b ilita r y desh a b ilita r se apli
que el servicio se sum inistrará al usuario; esorsignifica can a S istem a (finalm ente se debe definir el estado
con detalles de im plem entación. de sistem a usando la no tació n adecuada en u n d ic
cionario de datos) com o:
es ta d o d el s is te m a = [ h a b ilita d o I
22.3.2. D iseñ o d e algoritm os y estructuras d e s h a b ilita d o ]
d e datos
Una variedad de representacionescontenidas en el m o d e
lo de análisis y el diseño de sistem a, p ro v een una esp e
cificación p ara to d as las o peraciones y atributos. L os Una operación se define en gran parte de la misma
algoritm os y estructuras de datos se diseñan utilizando manera en que se refina una función en el diseño
un enfoque, que difiere un p oco de los enfoques del dise convencional. Escriba uno descripción del proceso,
www.FreeLibros.org
ño de datos y del diseño a n iv el de com ponentes e x a haga un análisis gramatical y aísle nuevas operaciones
m inadas p ara la ingeniería del softw are convencional. a un nivel de abstracción más bajo.
389
IN GE NI E RI A DEL S O F TW A RE . UN E N F O Q U E P R A C T I C O
L a o p e r a c i ó n program ar s e a s i g n a d u r a n t e e l A O O , c i o n e s : instalar,definir, construir y cargar. C a d a u n a d e

p e r o e s p e c íf ic a m e n t e d u r a n t e e l d is e ñ o d e l o b je t o s e r e f i- e s ta s n u e v a s o p e r a c io n e s s e v u e lv e p a r te d e l o b je t o S is
n a r á u n n ú m e r o d e o p e r a c io n e s m á s e s p e c íf ic a s , q u e s e t e m a , q u e t i e n e c o n o c i m i e n t o d e la s e s t r u c t u r a s d e d a t o s
r e q u ie r e n p a r a c o n f i g u r a r e l s is t e m a . P o r e je m p lo , d e s in te r n a s , q u e im p le m e n t a n lo s a t r ib u t o s d e lo s o b je t o s ,
p u é s d e d is c u s io n e s c o n e l in g e n ie r o d e l p r o d u c t o , e l a n a y q u e s e in v o c a e n v ia n d o m e n s a je s c o n e l f o r m a t o :
lis t a , y p o s ib le m e n te c o n e l d e p a r t a m e n to d e m a r k e t in g
M E N S A JE (sistem a ) — > i n s t a l a r : ENVÍA t e l é f o n o . n ú m e r o ;
( m e r c a d o t e c n ia ) , e l d is e ñ a d o r d e b e e la b o r a r la d e s c r ip
c ió n d e l p r o c e s o o r ig in a l, y e s c r i b ir l o s ig u ie n te p a r a p r o - q u e i m p l i c a q u e se p r o p o r c io n a a l s is t e m a u n n ú m e r o
gram ar ( s u b r a y a n o p e r a c i o n e s p o t e n c i a l e s — v e r b o s — ■): d e t e l é f o n o d e e m e r g e n c i a , y u n m e n s a j e instalar se
P rogram ar habilita al u suario de H ogarSeguro para confi

envía al s is t e m a .
gurar el sistem a u n a vez que h a sido instalado. El u suario pue L os v e r b o s d e n o t a n a c c i o n e s u o c u r r e n c i a s . E n e l
de (1) in stalar n ú m ero s de teléfonos; (2) definir tiem p o s de c o n t e x t o d e la f o r m a liz a c ió n d e l d is e ñ o d e l o b je t o , se
dem ora p ara alarmas; (3) construir u n a tab la de sensores que c o n s id e r a n n o s ó lo v e r b o s , s in o fr a s e s v e r b a le s d e s -
contenga cada ID de sensor, su tipo y asignación; y (4) cargar c r ip t iv a s y p r e d ic a d o s ( p o r e je m p lo , « e s ig u a l a » ) , c o m o
una contraseña (passw ord) m aestra.
o p e r a c io n e s p o te n c ia le s . E l a n á lis is g r a m a t ic a l s e a p li
P o r c o n s ig u ie n te , e l d is e ñ a d o r h a r e f in a d o la o p e r a c a r e c u r s iv a m e n t e , h a s ta q u e c a d a o p e r a c ió n h a s id o
c i ó n s i m p l e programar, y s e r e e m p l a z a c o n la s o p e r a r e f i n a d a a su n i v e l m á s d e t a l l a d o .
L o s m e jo r e s d is e ñ a d o r e s e n c u a lq u ie r c a m p o t ie n e n lo s a r c h iv o s d e l u s u a r io , y p r o p o r c io n a fa c ilid a d e s
u n a h a b ilid a d e x tr a ñ a p a r a r e c o n o c e r p a tr o n e s q u e p a r a c r e a r , r e n o m b r a r y e l i m i n a r t a l e s a r c b ó ^<¡.
c a r a c t e r iz a n u n p r o b le m a y lo s p a tr o n e s c o r r e s p o n S o lo e x is t ir á u n a in s t a n c ia d e e s e a d m in is tr a r
d ie n t e s , q u e p u e d e n c o m b in a r s e p a r a c r e a r u n a s o lu a r c h iv o s .
c ió n . G a m m a y s u s c o le g a s [ G A M 9 5 ] e x a m in a n e s to • E n u n s is t e m a d e c o n t r o l d e t r á f ic o a é r e o , s o lo e x is
c u a n d o a f ir m a n q u e : t i r á u n a in s ta n c ia d e l c o n t r o la d o r , q u e m a n tie n e r e g is
S e e n co n trará n patrones rep etid o s de clases y o b jeto s de t r o s d e lo s p la n e s d e v u e lo y s u s p o s ic io n e s .
com unicación,en m uchos sistem as orientados a objetos. Estos • E n u n a a p lic a c ió n b a n c a r ia , s o lo e x is t ir á u n c o n t r o
patrones resuelven problem as específicosde diseñ o ,y vuelven
la d o r , q u e m a n t ie n e e l r e g is t r o d e lo s c a je r o s a u to
al diseño o rien tad o a objetos m á s flexible, eleg an te y ex tre
m adam ente reutilizable.A yudan a los diseñadores a reutilizar m á tic o s u t iliz a d o s p o r e l b a n c o .
diseños exitosos b asando nu ev o s d iseños en experiencia pre
via. U n diseñador bastante fam iliarizado con ese tipo de patro | | | | ¿Qué es un patrón de diseño
nes puede aplicarlos inm ediatam ente a problem as d e diseño, W y por qué se necesitan esos
sin tener que redescubrirlos. patrones?
g s b s s s x b e r L a F i g u r a 2 2 . 7 m u e s t r a l a e s t r u c t u r a g e n e r a l d e e s te
Los potrones existen o nivel tonto de orquitecturo p a t r ó n , la p a la b r a « s ta t ic » d e s c r ib e u n a v a r ia b le u t i
como de componentes. Pora mayor información,
l i z a d a p a r a t o d a la c la s e . E n e s ta F i g u r a s o lo s e m u e s
t r a n d o s o p e r a c i o n e s e n l a c l a s e Singleton, p e r o s e
p u e d e n m o s t r a r a lg u n a s m á s d e p e n d ie n d o d e l c o n
D u r a n te e l p r o c e s o d e D O O , u n in g e n ie r o d e l s o f t t e x t o . A c o n t in u a c ió n s e m u e s t r a u n e s q u e le to e n J a v a
w a r e d e b e 'o b s e r v a r c a d a o p o r t u n i d a d e n la q u e p u e d a n p a ra e l p a tró n :
r e u t il iz a r p a tr o n e s d e d is e ñ o e x is te n te s (c u a n d o c u m
p tib lic c la s s S in g le to n {
p l e n la s n e c e s i d a d e s d e l d i s e ñ o ) , e n v e z d e c re a r o tro s
p r í v a t e s t a t i c O b je to S ím p le in s ta n c ia ü n ic a = n u il;
nuevos.
p tib lic s t a t i c O b je to S ím p le I n s ta n c ia ü n ic a ( )
{
22.4.1. ¿Q ué e s un patrón d e diseño? if ( i n s t a n c i a ü n i c a == n u i l )
A n t e s d e e x a m in a r lo s p a tr o n e s c o n d e ta lle v a le la p e n a i n s t a n c i a ü n i c a = new O b je to S ím p le ( ) ;
o b s e r v a r u n e je m p lo s e n c illo d e u n p a tr ó n , q u e s e p r e r e tu r n in s ta n c ia ü n ic a ;
s e n ta u n a y o t r a v e z . M u c h a s a p lic a c io n e s tie n e n e l
}
r e q u is it o d e q u e s o lo u n a in s t a n c ia d e u n s o lo o b je t o
//C ó d ig o p a ra c o n s tr u c to r e s , se rá p r iv a d o .
d e b e s e r in s t a n c ia d a . A lg u n o s e je m p lo s d e a p lic a c io n e s
/ / C ó d i g o p a r a m é to d o s q u e im p le m e n te n l a e s c r i t u
www.FreeLibros.org
y o b je t o s d e in s ta n c ia s s im p le s s o n :
ra de
. E n u n s is t e m a o p e r a t iv o h a b r á s o lo u n o b je t o a d m i
/ / o p e r a c i o n e s d e n t r o de S i n g l e t o n , que p u e d e n
n is tr a d o r d e a r c h iv o s , q u e m a n tie n e e l r e g is tr o d e in c lu ir
390
CAPÍTULO 22 DI SEÑ O O RI EN TA D O A O BJ E TO S
El rol de Memento es el de vigilar el estado o alma

/ / C ó d i g o p a r a m é t o d o s que i m p l e m e n t e n o p e r a c i o n e s cenamiento de recuperación del estado de un sistema,
de r e t o r n o cuando se requiera. La Figura 22.8 muestra el dia
//e n el o b jeto S in g le to n , debe i n c l u i r o p e r a c ió n l grama de clase para el patrón. Existen tres elementos
/ / o p e r a d ón2 de este patrón. El primero es ClaseCreadora, el cual
} es una clase que describe objetos cuyo estado debe
ser almacenado. Existen dos métodos asociados con
esta cíasq: fija rV a lo rM e m e n to y c o n s tr u ir M e m e n to .
El primero inicializa su estado, toma un argumento el
cual es un objeto definido por la clase Memento y
reestablece su estado con el uso del argumento. El
segundo crea un objeto de la clase ClaseMemento la
cual contiene su estado actual. En efecto, fija r M e -
m e n to actúa como un recurso de restauración, mien
tras que co n stru irM em e n to lo hace como un recurso
de almacenamiento.
F IG U R A 2 2 .7 . La estructu ra g e n e ra l del patrón S in g le t o n .

Clase Creadora
El patrón S in g le to n se implementa por medio de

una variable de instancia estática, descrita por el atri Estado Creador
buto de clase ObjetoSimple. La cual es inicializada
con null para la instanciación.
El acceso al objeto Singleton se realiza mediante FijarValorM em entoO
ConstruirM em entoO
el método in sta n c ia lrn ic a . Este comprueba primero
si ObjetoSimple es igual a n u ll. En caso afirmativo,
significa entonces que no se ha creado un objeto de
tipo Singleton, y que el método llamará a un cons
tructor privado adecuado para establecer al objeto Sin- Clase M em ento!)
gleton; en el código anterior esto se realiza cuando el
EstadoMementoO
argumentodel constructor es cero. El constructor uti
lizado se declarará como privado, ya que no se desea ObtenerEstadoMementoO
que ningún usuario pueda crear objetos de tipo Sin FijarEstadoMementoO
gleton, excepto si es por medio de in sta n c ia lrn ic a , la
cual se ejecutará, de una vez y por todas, en el momen
F IG U R A 2 2 .8 . El patrón Memento.
to de la creación. La clase también contendrá méto
d os, que ejecutarán operaciones en un objeto de tipo
Singleton. La clase ClaseMemento define objetos que man
De este modo, si el patrón Singleton se utilizara en tendrán el estado de un objeto de la clase ClaseCrea
u n sistema de control de tráfico aéreo, y solo se nece dora. Contiene dos métodos o b te n e rE sta d o M e m e n to
sitara un controlador de aeronaves, entonces el nom y fija rE sta d o M e m e n to . La primera devuelve el esta
bre de la clase anterior debena ser Controlador Aéreo, do que se almacena, mientras que la segunda fija el
y debería tener métodos tales como o b te n erC o n tro - estado a un valor pasado como argumento. El tercer
ladorAéreo, que devuelve la Unica instancia de un con elemento del patrón Memento es la clase cliente Care-
trolador de tráfico aéreo. taker, ésta no se muestra en la Figura 22.8. Repre
senta una clase que implementa objetos que contienen
un objeto de la clase ClaseMemento. Tiene un con
22.4.2. O t r o e j e m p l o d e u n p a t r ó n junto muy limitado de funciones ya que todo lo que
Se ha visto ya un ejemplo de un patrón: S in g leto n . El realiza es almacenar un Memento, no altera ni exa
objetivo de esta sección es describir un patrón más mina los contenidos de un memento.
complicado, conocido como M e m e n to .
\c u VE 2 2 .4 .3 . U n e j e m p l o f i n a l d e u n p a t r ó n
Frecuentemente, existe la necesidad de desarrollar
un código que lleve a cabo el procesamiento de
www.FreeLibros.org
El patrón de M em en to se usa datos accedidos secuencialmente. Este acceso
para la recuperación de sistemas. secuencia1 tendrá usualmente la misma forma, y por
391
esto es ad e c u a d o p a ra u n patró n . E l o b je tiv o d e e sta c ia d o s co n las c la se s F iltro F u e n te C o n c re to , que

s e c c ió n e s d e s c r ib i r ta l p a tr ó n ; e llo e s d e b id o a r e a liz a rá n a lg ú n tip o d e p ro c e s a m ie n to c o n los
G ra n d [G R A 9 9 ]. A lg u n o s e je m p lo s d e p r o c e s a datos.
m ie n to s e c u e n c ia l son:
» U n pro g ram a de inform es debe p ro cesar un archivo 22.4.4. D escrip ción de un patrón de d iseñ o.
de datos de em pleados, leyendo cada registro y d ese
L a s d isc ip lin a s m a d u ra s de in g e n ie ría h a c e n un v a s
ch an d o todos aq u ello s registros de em p lead o s que
to u so de p a tro n e s de diseñ o . L a in g e n ie ría del soft
gan en p o r encim a de una cierta cantidad.
w are so lo se e n c u e n tra en su in fa n c ia , c o n el uso de
• U n program a editor puede ser consultado p o r su usua p a tro n es. D e c u a lq u ie r m a n e ra , se está p ro ced ien d o
rio, p ara listar las líneas de texto de u n archivo que rá p id a m e n te h a c ia el c o m ie n z o d e u n a ta x o n o m ía.
co incidan con un cierto patrón. E n g e n e ra l, la d e sc rip c ió n d e u n p a tró n c o m o parte
• U n p ro g ram a de an álisis de la W eb d eb e le e r el d e una ta x o n o m ía d e b e p ro p o rc io n a r [G A M 95]:
código fuente de un docum ento H T M L , p ara descu
« N o m b re del patrón. P o r eje m p lo F iltro.
brir cuantas referencias a otros sitios contiene el docu
m ento. • In ten c ió n del patrón. P o r e je m p lo , un p atró n debe
te n e r la in te n c ió n d e f a c ilita r el m a n te n im ie n to ,
pues puede acom odar un núm ero de diferentes tipos
«*fy v¿Qué hace el Filtro? de objeto.
• L o s p ro b le m a s de d ise ñ o q u e m o tiv a n el patrón.
Por ejem p lo , un patrón debe desarrollarse, para que
E stas son fo rm a s d ife re n te s de p ro c e sa m ie n to ; de
un n ú m ero de tra n sfo rm ac io n es d iferen tes de datos
c u a lq u ie r m an era, está n u n id o s p o r el h e c h o d e que
p u e d a n ser a p lic a d a s a u n o b je to , m u c h a s de las
el p ro c e sa m ie n to de d a to s es de m a n e ra sec u e n cial.
cu ales son d esco n o cid as, cu an d o el p a tró n es d esa
E ste p ro c e sa m ie n to d eb e h a c e rse c o n b a se en p a la
rro llad o o riginalm ente.
bra p o r p a la b ra , o co n b ase en re g is tro p o r re g istro ;
a p e sa r de ello , ta m b ié n se a p lic a al p ro c e sa m ie n to
secu en cial, y de a q u í que sea u n a b u en a o p o rtu n id a d ¿Cómo se describe un patrón
de c a p tu ra rs e en u n p a tró n . E ste p a tró n , c o n o c id o de diseño?
co m o F iltro , se m u e stra en la F ig u ra 22.9. C o n sta de
v arias clases: • L a so lu ció n que resu elv e esto s problem as.
• FiltroFuente. E s ta e s la c la s e q u e a c tú a c o m o • L a s cla se s que se re q u ie re n p a ra im p le m e n ta r la
su p erclase p a ra o tra s clases c o n c re ta s, que im ple- solución. P o r e je m p lo , las c u a tro c la se s descritas
m e n ta n el p ro c e sa m ie n to re q u e rid o . L a c lase no en la F ig u ra 22.9.
lle v a a c a b o la re c u p e ra c ió n de lo s d a to s q u e se • L as re sp o n sa b ilid a d e s y c o la b o ra c io n e s entre las
p ro cesarán , pero d eleg a eso al o b jeto F u en te, cuya clases de solución. P or ejem p lo , una clase debe ser
c la se será d e sc rita en la te rc e ra v iñ e ta sig u ien te. resp o n sa b le de la co n stru c ció n de un o bjeto, cuyo
El o b je to F u e n te se p asa p o r m e d io d el co n stu c - c o m p o rtam ien to v a ría al tiem p o de ejecución.
to r a la clase. L a clase contiene un m étodo llam ado
• L in c a m ie n to s que c o n d u z c a n a u n a im p lem en ta-
obtenerDatos, q u e re c u p e ra los d a to s que se p ro
cesarán . c ió n e fe ctiv a . G e n e ra lm e n te, e x istirá un núm ero
de fo rm as d iferen tes de p ro g ram ar un p atró n ; por
• F iltr o F u e n te C o n c r e to .E s ta es u n a subclase de la ejem p lo , el p ro ce sam ie n to de e rro re s debe ser tra
clase FiltroFuente. R edefine el m étodo o b ten erD a ta d o de d iferen tes fo rm as.
tos, p ara realizar algunas o p eraciones extras en los
• E jem p lo s de có d ig o fuente.
d ato s que h an sido leídos, p o r ejem p lo si el patrón
se utiliza p ara con tar las cadenas de caracteres que • R eferen cias a o tro s p atro n es de d iseñ o , o patrones
co inciden con cierto patrón, el código p ara realizar que p u e d a n u sarse en co n ju n to con el p atró n des
e ste re cu en to se c o lo c a aquí. N o rm a lm e n te este crito.
m étodo utiliza el m étodo correspondiente o btener
D atos, dentro de la super-clase. 22.4.5. El futuro d e lo s patrones
• Fuente. E sta clase se asocia con los objetos, que lle E n la a c tu a lid a d , se h a d e sa rro lla d o y c a ta lo g a d o un
van a cab o el p roceso de recu p erar los datos que se n ú m ero relativ am e n te p eq u eñ o de p atrones. D e cu al
procesarán. E sto se logra p o r m ed io de un m étodo q u ie r m a n e ra , lo s ú ltim o s c in c o añ o s h a n sido te sti
llam ado obtenerD atos, g o s d e u n a tre m e n d a e x p lo s ió n , e n té rm in o s de
www.FreeLibros.org
• FuenteConcreta E s ta c la s e e s u n a s u b c la se de in te ré s in d u stria l. L o s p a tro n e s, ju n to co n los co m
F u en te e im p le m e n ta el m éto d o o b te n e rD a to s. Su p o n e n te s, o fre c e n la e sp e ra n z a de que la in g en iería
fu n c ió n e s p ro p o rc io n a r d a to s a los o b je to s a so de so ftw a re , e v e n tu a lm e n te , se p a re z c a a o tra s dis-
392
CAPITULO 22 DI SE NO O R IE N TA D O A O B JE T O S
ciplinas de in g en iería, co n clases v o lv ién d o se el an á FiltroFuente

logo e n so ftw a re de c o m p o n e n te s e le c tró n ic o s, y los
«abstracto» ObtenerDatosOl Las clases FiltroFuente
p a tro n e s v o lv ié n d o s e e l a n á lo g o e n s o ftw a re de
y FiltroFuenteConcreto
p e q u e ñ o s c irc u ito s h e c h o s d e c o m p o n e n te s. A n te s CnritetUirán ntrns línátndÓS
de que e s to su c e d a , e x is te aú n u n a in g e n te c a n tid a d FiltroFuenteConcreto pero no se muestran
de tra b a jo qu e lle v a r a c a b o al id e n tific a r p a tro n e s y
ObtenerDatosO
c a ta lo g a rlo s ; ta m b ié n , se p ro d u c irá e s ta s itu a c ió n ,
cuando e l n ú m e ro d e p a tro n e s e x iste n te s se v u e lv a
tan g ra n d e , q u e se n e c e s ite u n a fo rm a d e in d ex ad o
Fuente
a u to m ática o se m ia u to m á tic a .
CLAVE
En la actualidad existe un buen grupo de patrones;
sn embargo, en los próximos años debería haber
una verdadera expansión en su uso. F IG U R A 2 2 .9 . El patrón Filtro.
El objetivo de esta sección es describir, con un grado de

mayor detalle, el conjunto de notacio n es que com ponen
el lenguaje U M L. A n teriorm ente, en el C apítulo 21, se
describen su origen y com ponentesprincipales; de hecho,
muchos de los diagram as p resentados en el C apítulo 21
y en este capítulo h an sido expresados en U M L. Se ha
tomado la decisión de utilizar esta notación, porque se ha
vuelto predom inante m uy rápidam ente en aquellas co m
pañías que u tilizan ideas de ingeniería p ara desarrollar
software orientado a objetos. El p rim er com ponente que
se intenta describ ir es el m odelo de clases.
CLAVE
UML se está convirtiendo en un estándar de facto No se muestran
todos los atributos
para el análisis y diseño orientado a objetos.
y operaciones
22.5.1. El m o d elo d e c la s e s
Un m odelo de clases es un a descripción de las clases en F IG U R A 2 2 .1 0 . Un ejem plo de una clase descrita en UM L.
un sistem a y sus relaciones. N o describe el com porta
m iento dinám ico del sistem a, p o r ejem plo el com por T am b ié n e n la F ig u ra 2 2 .1 0 se m u e s tra u n a v e r
tam iento de objetos individuales. El p rim er elem en to sió n g rá fic a de los c o m e n ta rio s u tiliz a d o s e n el le n
de un diag ram a de clases es u n a d escripción de clases g u a je d e p ro g ra m a c ió n . E l c u a d ro , c o n u n a e s q u in a
individuales. L a F ig u ra 22.10 m u estra com o se d escri su p e rio r d e re c h a d o b la d a , lla m a la a te n c ió n d e l le c
be una clase. L a clase describe al cliente de un banco. to r a a lg ú n asp ec to d e u n d ia g ram a. E n e l c a s o d e la
E sta figura es m uy sim ple, y a que solo contiene una F ig u r a 2 2 .1 0 , se lla m a la a te n c ió n d e l le c to r , al
clase. C onsta del nom bre de lá clase (C lie n te ),e l n o m h e c h o de que m u c h o s d e lo s a trib u to s y o p e ra c io n e s
bre de algunos de sus atributos, p o r ejem plo el atribu a so c ia d o s c o n la c la se C lie n te n o se m u e s tra n ; p o r
to d i r e c c i ó n , que contiene la d irección del cliente, y la e je m p lo , la c o le c c ió n de c u e n ta s que p o se e el c lie n
lista de o p eracio n es; p o r ejem p lo , la o p e ra ció n obte- te n o se m u e stra n e n la se c c ió n d e a tr ib u to s d e la
nerNombre recupera el nom bre de un cliente. C ada cu a clase .
dro que rep resen ta u n a clase contiene, p o r consiguiente, L a F ig u ra 22.10 es m uy sim ple, e n la p rá c tic a los
una sección que contiene el nom bre de la clase, una sec d ia g ra m a s de cla se s e n U M L m o s tra rá n la re la c ió n
www.FreeLibros.org
ción que en um era los atributos de los objetos definidos entre clases. Existe un gran n ú m ero d e tip o s d ife re n
por la clase, y u n a sección que describe las operaciones tes de rela cio n e s, que pueden se r expresadas. L a p ri
asociadas con tales objetos. m era co sa que tratem os será la gen eralizació n .
393
I N G E N I E R Í A DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
22.5.2. G en era liza c ió n 22.5.3. A g r e g a c ió n y c o m p o sició n

E sta re la c ió n es la que se m antiene en tre u n a clase X y L a sección anterior d escrib ió u n a relación, que puede
otra clase Y, cu an d o la clase Y es el ejem plo m ás esp e ser representada en un diagram a de clases U M L : gene
cífico de la clase X. P o r ejem plo, una relació n de g en e ralización; las otras relaciones im portantes son la agre
raliz a c ió n e x iste e n tre u n a clase C uenta, la cual g a ció n y la co m posición. E x isten do s rela cio n e s que
rep re se n ta u n a cu enta b an caria g en eral, y u n a c u en ta establecen que u n a clase genera objetos, que son parte
corriente, que es un ejem plo específico de u n a cuenta. de un ob jeto d efin id o p o r o tra clase. P o r ejem p lo , un
L a Figura 22.11 m uestra com o se representaría esta rela sistem a para un fabricante tendrá la necesidad de m an
ción en un diag ram a de clases U M L. te n e r los d ato s a c e rc a de los e le m e n to s que se están
fab rican d o , y de aq u ello s que se están h aciendo. Por
ejem plo, un ordenador se fabricaría a partir de una exten
sa serie de com ponentes incluyendo su arm azón, un dis
No se muestran
co d u ro , un co n ju n to de ta rjeta s de m em o ria, etc. El
y operaciones ordenador se co n stru y e, a p a rtir de u n a serie de com
ponentes y en un sistem a orientado a objetos utilizado
para dar soporte al proceso de fabricación, existirá una
relación de agregación entre la clase utilizada para des
CuentaCorriente Depósito cribir el producto fabricado y cada uno de sus com po
nentes. L a Figura 22.12 m u estra com o se representa esta
relación, en un diagram a de clases U M L.
A quí u n a clase C u en ta tiene u n a relació n de g enera

§ ¿Qué es agregación?
lización con las clases m ás específicas, com o son Cuen-

taCorriente y Depósito. E sta relació n se represen ta por A q u í la lín e a con un ro m b o h u eco en un extrem o
indica que la clase describe objetos que agregan otros
m edio de u n a flecha, que apunta de la clase m ás e sp e
cífica h acia la clase m ás general. U n a v ez m ás, o b ser objetos, la clase con el rom bo unido a ella describe obje
to s, que contiene objetos definidos p o r la otra clase. En
ve qu e, p ara p ro p ó sito s ilu strativ o s, n o se m u e stra
U M L las relaciones norm alm ente se mezclan. Por ejem
ning u n a o peración o atributo.
plo, la F igura 22.12 habrá un núm ero de com ponentes,
que posean una relación de generalización con la clase
Producto Manufacturado
C om ponente.
77
Cliente
ColecciónCuentas
F IG U R A 22.12. Agregación en UML.
ProductoManufacturado F IG U R A 22.14. Un diagrama UML de clases mostrando

composición.
77
E sto se m u estra en la F igura 22.13, donde C om po
nente se asocia con un núm ero de clases m ás específi
Com ponente É ca s, que d e sc rib e n lo s c o m p o n e n te s co n los que un
producto fabricado puede ser ensam blado.
¿Qué es composición?
Com ponenteA C om ponentes Com ponenteC
Existe u n a fo rm a especial de agregación, conocida
www.FreeLibros.org
co m o co m p o sició n . É sta se u sa c u a n d o se tien e una
F IG U R A 2 2 .1 3 . Un diagram a UM L de clases mostrando situ ació n en la que un o b jeto c o n tie n e un n ú m ero de
generalización y agregación. otros objetos, y cuando el objeto contenedor se elim i
394
CAPITULO 22 DISENO ORIENTADO A OBJETOS
n a t o d a s la s i n s t a n c i a s d e l o s o b j e t o s q u e e s t á n c o n t e m o d e la lí n e a d e t e r m in a q u e u n a d m in is t r a d o r d ir ig e a
n id o s d e s a p a r e c e n . P o r e je m p lo , u n a c la s e C lie n t e q u e u n c o n ju n t o d e e m p le a d o s .
r e p r e s e n ta c lie n te s e n u n b a n c o te n d r á u n a r e la c ió n d e L a a s o c ia c ió n e n t r e c la s e s p u e d e n o m b r a r s e p a r a
c o m p o s ic i ó n c o n la s c u e n ta s q u e e l c lie n t e p o s e e ; p o r d o c u m e n ta r e x p lí c it a m e n t e la r e la c ió n . P o r e je m p lo , la
q u e s i e l c lie n te s e e lim in a , p o r e je m p lo , s e m u e v e a o t r o F ig u r a 2 2 .1 7 d o c u m e n ta e l h e c h o d e q u e u n a d m in is
b a n c o , to d a s s u s c u e n ta s s o n e lim in a d a s ; e s ta f o r m a d e t r a d o r d ir ig e a u n g r u p o ( c o le c c ió n ) d e e m p le a d o s .
r e la c ió n s e in d ic a d e m a n e r a m u y s im i la r a la a g r e g a
c ió n , p e r o e n e s ta o c a s ió n e l r o m b o e s tá r e lle n o e n lu g a r Administrador
d e h u e c o . E s to s e m u e s tr a e n la F ig u r a 2 2 .1 4 .
2 2 .5 .4 . A s o c i a c i o n e s
L a a g r e g a c ió n y la c o m p o s ic ió n s o n e je m p lo s e s p e c í f i
c o s d e u n a r e l a c i ó n e n t r e d o s c la s e s . U n a r e l a c i ó n o c u
r r e e n t r e d o s c la s e s c u a n d o e x i s t e a l g u n a c o n e x i ó n e n t r e Em pleado
e lla s , e n U M L e s to s e c o n o c e c o m o a s o c ia c ió n . A l g u
n o s e je m p lo s d e e s to s e d e s c r ib e n a c o n t in u a c ió n :
. Administrador se r e l a c i o n a c o n l a c la s e
U n a c la s e F I G U R A 2 2 .1 6 . Multiplicidad en un diagram a de clases
Empleado e n v i r t u d d e q u e u n a d m i n i s t r a d o r d i r i g e en UML.
a u n n ú m e r o d e e m p le a d o s .
U n a a lt e r n a t iv a p a r a d o c u m e n t a r la a s o c ia c ió n e s
> U n a c la s e Vuelo s e a s o c ia c o n la c la s e Avión e n v ir
d o c u m e n t a r lo s p a p e le s ( r o le s ) q u e c a d a c la s e ju e g a e n
tu d d e q u e u n a v ió n e m p r e n d e u n v u e lo p a r tic u la r .
u n a a s o c ia c ió n . U n e je m p lo d e e s ta s it u a c ió n s e m u e s
• U n a c la s e Computadora s e r e l a c i o n a c o n u n a c la s e
t r a e n l a F i g u r a 2 2 . 1 8 . A q u í , l a c l a s e Universidad j u e
Mensaje e n v ir t u d d e l h e c h o d e q u e u n a c o le c c ió n
g a e l r o l d e h o s p e d a r u n a s e r i e d e e s t u d i a n t e s q u e , a su
d e m e n s a je s e s tá e s p e r a n d o e l p r o c e s o d e u n a c o m
v e z , ju e g a n e l r o l d e s e r e s tu d ia n te s m ie m b r o s d e la u n i
p u ta d o ra .
v e r s i d a d . N o r m a l m e n t e , c u a n d o s e d o c u m e n t a n la s a s o
. InformeBancario s e r e l a c i o n a c o n l a c la s e
U n a c la s e c ia c io n e s , s e e lig e e l t i p o d e d o c u m e n t a c ió n q u e s e
Transacción e n v i r t u d d e q u e e l i n f o r m e c o n t i e n e u t iliz a r á : s i la d o c u m e n ta c ió n d e a s o c ia c ió n o la d o c u
d e ta lle s d e c a d a tr a n s a c c ió n . m e n t a c i ó n d e r o l e s d e c la s e s q u e p a r t i c i p a n e n l a a s o
D e e s ta s r e la c io n e s , s ó lo la ú l t im a e s d e a g r e g a c ió n . c ia c ió n . E l r e a liz a r a m b o s , a u n q u e p e r fe c ta m e n te v á lid o ,
T o d a s la s o t r a s s o n a s o c i a c i o n e s c l a r a s . T a l e s a s o c i a s e c o n s id e r a c o m o u n e x c e s o .
c io n e s s e e s c r i b e n e n U M L c o m o u n a l í n e a r e c t a . P o r
e je m p lo , la F ig u r a 2 2 .1 5 m u e s tr a la p r im e r a a s o c ia c ió n A d m in istra d o r |
d e la s a n t e r i o r e s .
1....................... I
L a s a s o c i a c i o n e s e n t r e c la s e s s e d o c u m e n t a n e n t é r 1
m in o s d e la m u lt i p li c id a d d e la a s o c ia c ió n y d e l n o m Administra
b re d e la a s o c ia c ió n . A c o n t in u a c ió n s e o b s e r v a r á la
1..*
m u lt ip lic id a d , e x a m in a n d o e l e je m p lo d e la F ig u r a
2 2 .1 5 . E n e s te e je m p lo u n s im p le a d m in is t r a d o r d ir ig e Empleado
a u n o o m á s e m p le a d o s , y u n s o lo e m p le a d o s e rá d i r i-
g id o p o r u n s o lo a d m in is tr a d o r . E s ta a s o c ia c ió n s e m u e s
tr a e n la F ig u r a 2 2 .1 6 . F IG U R A 2 2 .1 7 . Docum entando una Asociación.
22.5.5. C a s o s d e u s o
A n t e r io r m e n t e , e n e l C a p í t u lo 2 1 , s e e x a m in a r o n lo s
c a s o s d e u so . E n U M L , u n c a s o d e u so s e d o c u m e n t a
d e m a n e r a m u y s im p le , e n té r m in o s d e a c to r e s y d e u n
c a s o d e u s o . U n a c to r e s c u a lq u ie r a g e n te q u e in te r a c -
t ú a c o n e l s is t e m a q u e s e c o n s t r u y e , p o r e je m p lo e l p i l o
to d e u n a v ió n , u n p r e s ta ta r io d e lib r o s d e u n a lib r e r í a
o e l j e f e d e lo s e m p le a d o s e n u n a c o m p a ñ í a . U n c a s o d e
F IG U R A 2 2 .1 5 . Un ejem plo de una relación simple en UML. u s o d o c u m e n ta a lg u n a a c c ió n q u e e l a c to r e je c u ta ; p o r
e je m p lo , e l p r é s ta m o d e u n li b r o , e l c a m b io d e d ir e c
c ió n d e u n a v ió n o la a d ic ió n d e u n m ie m b r o a u n e q u i
www.FreeLibros.org
A q u í e l 1 q u e s e e n c u e n t r a a l f i n a l d e la lí n e a d e a s o p o d e p r o g r a m a c ió n . U n c a s o d e u s o s im p le s e m u e s tr a
c ia c ió n in d ic a q u e u n e m p le a d o s o lo e s d i r ig i d o p o r u n e n la F ig u r a 2 2 .1 9 . S e m u e s tr a e l u s u a r io d e u n a b i b l i o
a d m in is t r a d o r ; y e l 1 .. q u e s e e n c u e n t r a e n e l o t r o e x t r e te c a q u e p id e p r e s ta d o u n lib r o .
395
INGENIERÍA DEL SO F TW A RE . UN EN F O Q U E P R A C T I C O
Universidad L a existencia de un gran núm ero de casos de uso sig

n ifica que h ab rá algunos casos de u so que serán u tili
zad o s p o r otros casos de u so. C uando e sto sucede, el
Hospedar diagram a de casos de uso U M L va a incluir una etiqueta
conocida com o un estereotipo « u s e s » , sobre la fle
Estudiante M iem bro
ch a que conduce al caso de u so. S e m u estra un ejem plo
en la F igura 22.21, la cual m u estra algunos casos de uso,
Estudiante involucrados con un sistem a para la adm inistración de
productos en un alm acén (W arehouse). P or ejem plo, el
adm inistrador del alm acén puede h acer una petición a
nivel de existencias de un producto en particular. Al lle
F IG U R A 2 2 .1 8 . Docum entando roles.
v ar a cabo estas funciones, el adm inistrador del alm a
cén genera un núm ero de casos de uso, cad a uno de los
El actor en este caso es el p restatario, que utiliza la cuales hacen uso de otro caso de uso, que valid a el nom
biblioteca, y el círculo ovalado m u estra el caso de u s o bre del producto al que se hace referencia en el caso de
con el m ism o nom bre debajo. L os casos de u so re p re uso para revisar; por ejem plo, que el adm inistradorhaya
sentan una v isión, a un alto n ivel funcional, de un sis escrito un nom bre de producto válido.
te m a en U M L . E n g e n e ra l, un sistem a g ra n d e debe A quí, el hecho de que un caso de uso se em plee por
contener centenares, si no m illares de casos de u so . U n otros casos, se indica p o r m edio de una flecha con pun
fragm ento de un grupo de casos de uso relacionados con ta hueca.
el m ism o actor se m u estra en la F ig u ra 2 2 . 2 0 .
Prestatario Pedir prestado un libro Validar

producto
| Habrá más casos
F IG U R A 2 2 .1 9 . Un caso de uso sencillo. de uso asociados
con un administrador
I del almacén
M u estra algunas de las acciones que un adm inistra Consultar detalles
de orden
dor de p royecto debe llev ar a cab o , cu an d o in teractúa
con un sistem a de ad m inistración de proyectos.
F IG U R A 2 2 .2 1 . Un ejem plo de casos de uso utilizando otro
caso de uso.
22.5.6. C o la b o ra cio n es
D u ran te la ejecu ció n de u n sistem a o rien tad o a obje
Administrador Emitir inform e de estado tos, los objetos interactuarán con cada uno de los otros.
Por ejem p lo , en un sistem a b an cario , un ob jeto C uen
ta p u ed e e n v ia r un m e n sa je a un o b je to transacción
para crear una transacción que ha ocurrido en una cuen
ta, p o r ejem plo una cuenta de cargo. E ste tipo de infor
m ac ió n es im p o rtan te para el d iseñ a d o r de un sistem a
Seleccionar plantilla
orien tad o a o b jeto s, du ran te el p ro ceso de la identifi
ca c ió n y v a lid a c ió n d e clases. P o r esta ra z ó n , UML
tiene dos notaciones eq u iv alen tes para definir las inte
racciones. E n este libro no s c en trarem o s sólo en uno:
el d iag ram a de secu en cias; el o tro d iag ram a se cono
Term inar proyecto
ce co m o d iag ram a de co lab o ració n , y es equivalente
al d iag ram a de secuencia; de h ech o , son tan sim ilares
Iniciar Proyecto que las h e rram ie n tas C A S E pueden norm alm ente cre
www.FreeLibros.org
ar un diag ram a, a p a rtir de una in sta n cia o de la otra.
L a F ig u ra 2 2 . 2 2 m u estra un ejem p lo sim ple de un dia
FIG URA 2 2 .2 0 . Un con ju n to d e c a s o s d e uso. g ram a de secuencias.
396
CAPÍTULO 22 D I S E Ñ O O RI EN TA DO A O B J E T O S
E n e s te d ia g ra m a e x is te n tre s o b je to s, lo s c u ale s A q u í un actor, representado p o r un ob jeto anónim o

se in v o lu c ra n e n u n a in te ra c c ió n . E l p rim e ro es el definido p o r la clase In fo rm e B a la n c e , en v ía un m e n
objeto a d m in istra d o r d e sc rito p o r la c la se E m p le a saje al objeto cuenta, que consulta la cuenta.
d o . E sto e n v ía u n m e n sa je a c tu a liz a r ln fo r m e a un E ste objeto com prueba si es una cuenta válida, y lu e
objeto lla m a d o in fo rm eV en ta s, el cu al e n v ía u n m e n go envía un m ensaje generar!nform eB alance a un ob je
saje c r e a r T r a n s a c c ió n a u n o b je to tr a n s a c c ió n - to inform eB alance, que contiene los datos req u erid o s
Ventas. p o r el cliente del banco.
22.5.7. D i a g r a m a s d e e s t a d o
O tro co m p o n en te im p o rtan te de U M L es el diag ram a
de estado. Este m uestra los diferentes estados en que un
v ie jo C lie n te : a c t u a li z a r ln f o r m e ; objeto se encuentra, y có m o se dan las transiciones de
C lie n te B a n c o
cada estad o a otros estados. Tal diagram a contiene los
siguientes com ponentes:
c r e a r T r a n s a c c ió n |
• E stados: se m uestran dentro de cuadros, con esq u i
¡ c a m b ia r D e t a lle s < Ti
nas redondeadas.
u
• Transiciones entre estados m ediante flechas.
¿Qué es un diagrama
F IG U R A 22.22. Un diagrama de secuencia sencillo.
de estados?
E n e l d ia g ra m a de s e c u e n c ia e x is te n tre s o b je to s
Sucesos que provocan las transiciones entre estados.
in v o lu crad o s, u n o de e llo s (a dm inistrador)Ú Q nQ su
clase e s p e c ífic a ( E m p le a d o ) , los o tro s no. L o s c o n M a rc a de inicio, que m uestra el estado inicial, en el
ten id o s e n lo s c u a d ro s d e u n d ia g ra m a d e s e c u e n que un ob jeto se encuentra cu an d o se crea.
cia p u e d e n c o n te n e r so lo e l n o m b re d e l o b je to , el M a rc a de p a r a d a (fin), que indica que un objeto ha
n o m b re d e u n o b je to ju n t o c o n su c la s e se p a ra d o alcanzado el final de su existencia (vida).
p o r d o s p u n to s , o so lo el n o m b re d e u n a c la se p r e
cedida de d o s p u n to s ; e n e s te ú ltim o c a s o , el o b je
to es a n ó n im o .
La F igura 22.22 tam b ién m u e stra el rol de un actor
d entro de u n a co lab o ració n : aq u í el acto r C lien teB a n
co y V ie jo C lie n te , interactúa co n el ad m in istrad o r del
objeto E m p le a d o , e n v ian d o u n m en saje cam biarD e-
talles.
La F igura 22.23 m uestra otro ejem plo de u n diag ra
ma de secuencias.
cuenta Je
¡a la n c e
j
:C lie n te B a n c o
r c o n s u lt a C u e n t a
u F IG U R A 2 2 .2 4 . Ejemplo de un diagrama de estados.

c o m p ro b ar
u C u e n t a V á lid a
U n ejem plo de diagram a de estados se m uestra en la
F igura 22.24.
A quí se m uestra el ciclo de vida de una c u en ta ban-
g e n e r a r ln f o r m e B a la n c e caria. C uando la cuenta se crea, se visualiza co m o una
V cuenta vacía. H asta que una transacción se lleve a cabo
(los fondos depositados o retirados de la cuenta se visua
lizan com o una cuenta activa). El diagram a de estado
www.FreeLibros.org
tam bién m uestra que, cu an d o una cuenta se cierra, se
FIG U R A 2 2 .2 3 . O tro e je m p lo d e d ia g ra m a d e s e c u e n c ia . destruye.
397
I NGE NIERIA DEL S O F T W A R E . UN E N F O Q U E P R A C T I C O
WBE&MmbÉ' E N LÍ NEA
El objetivo de esta sección es mostrar el uso de diagra 6 . E l s i t i o w e b d e b e r á in t e r a c t u a r c o n u n s is t e m a d e
mas UML, descrito en la Sección 22.25, aplicado a un c o n t r o l d e in v e n t a r io , q u e t a m b ié n r e q u ie r e d e s a r r o
sistema real. Este sistema es un sistema de comercio llo . E s te s is t e m a d e c o n t r o l d e in v e n t a r io s d e b e m a n e
electrónico (e-commerce). j a r e l p r o c e s o d e r e c e p c ió n d e lib r o s d e lo s in v e n t a r io s
d e la s e d i t o r i a l e s , r e t i r o d e l i b r o s c u a n d o s e o r d e n a n
p o r p a r te d e u n c lie n t e , y r e o r d e n a c ió n d e e x is te n c ia
22.6.1. L ib ros-en -lín ea d e u n lib r o , c u a n d o s e e n c u e n tr a p o r v a c ia r s e , p a r a
Libros-en-línea es una compañía creada reciente e n c a r a r u n p r o b le m a d e s u m in is t r o s , e n u n tie m p o
mente, que es subsidiaria de otra gran compañía mul d e s ie t e d í a s .
tinacional de comercio, conocida como Pollday 7 . E l c o n t r o l d e in v e n ta r io s p o r p a r te d e l a d m in is tr a d o r
Publishing. Los directores de Pollday Publishing se s e r á f i j a d o e n u n t i e m p o d e s ie t e s e m a n a s . É l o e l l a
decidieron a llevar a cabo un gran crecimiento en ven t e n d r á n l a r e s p o n s a b i l i d a d d e m a n t e n e r la s v e n t a s , y
tas por internet entre sus clientes, y decidieron pre l a d i s p o n i b i l i d a d d e e x i s t e n c i a s y , c u a n d o la s e x i s
parar a Libros-en-Línea para ello. El concepto que t e n c i a s d e u n l i b r o s e e n c u e n t r e n b a j a s , h a c e r un
Pollday tiene es el de un sitio Web de comercio elec n u e v o p e d id o . P a r a r e a liz a r e s to , e s te s is t e m a d e c o n
trónico, que tenga catálogos detallados de cada libro t r o l d e in v e n t a r io s d e b e p r o p o r c io n a r in f o r m e s d e
que manejan, junto con recursos con los que el usua v e n ta s y e x is te n c ia s d e in v e n t a r io c o n r e g u la r id a d .
rio del sitio Web puede ordenar libros, utilizando una 8. U n A d m in is t r a d o r d e M a r k e t t in g in te r v e n d r á c a d a
forma incluida en una página Web. A continuación, o c h o s e m a n a s . E l J e fe d e M a r k e ttin g te n d r á la fu n
se muestran algunos extractos, tomados del conjun c ió n d e d e t e r m in a r lo s p r e c io s a lo s q u e lo s lib r o s
to de requisitos iniciales, detallados por el equipo téc s e r á n v e n d id o s . S e d a r á la s it u a c ió n d e q u e u n lib r o
nico de Libros-en-línea: p u e d e te n e r u n n ú m e r o d ife r e n te d e p r e c io s d u ra n te
1 . Libros-en-línea desea desarrollar la capacidad de s u t ie m p o d e v id a ; p o r e je m p lo , se d e b e d e c id ir s i se
ventas en línea por medio de la Web. EL sitio web o f r e c e c o n u n m a y o r d e s c u e n t o d u r a n t e la s p r i m e r a s
que implementa esta capacidad debe permitir al s e m a n a s , y lu e g o a ju s ta r e l p r e c io a lo s p r e c io s r e c o
cliente examinar los detalles del libro, ordenarlo y m e n d a d o s p o r la s e d i t o r i a l e s .
registrar su dirección de correo electrónicopara reci L a com pañía que desarrolló el softw are para Libros-
bir ofertas especiales con detalles, publicaciones nue en-línea, prim ero identificó un núm ero de clases candi-
vas y revisiones. d a ta s , q u e a c o n t in u a c ió n s e d e ta lla n :
2. Cuando un cliente accede al sitio Web, cada uno de • R eg istro C lien te . D e t a l l e s d e a l g u i e n q u e c o m p r a
los recursos antes descritos se despliegan. lib r o s , o q u e s e r e g is tr ó p a r a r e c ib ir c o r r e o s e le c tr ó
3. Si el cliente registra su dirección de correo electró n ic o s c o n in f o r m a c ió n .
nico, se le preguntarán su informaciónpersonal. Esto • Libro. E l a r t í c u l o p r i n c i p a l , q u é L i b r o s - e n - l í n e a
incluye su nombre, una dirección de correo electró vende.
nico, una dirección postal. Un miembro del equipo • Orden. U n a o r d e n q u e u n c l i e n t e r e a l i z a , p a r a u n o
conocido como el administrador de contratos será el o m á s lib r o s . E s ta o r d e n d e b e s e r p a r a u n a s im p le
responsable de enviar información de oferta, etc., a c o p ia d e u n lib r o , o p a r a c o p ia s d e u n n ú m e r o d e
los clientes. l i b r o s o i n c l u s o m ú l t i p l e s c o p i a s d e m u c h o s li b r o s .
4. El cliente podrá comprar libros del catálogo en U n a o r d e n c o n t e n d r á u n n ú m e r o d e lí n e a s d e o r d e n
línea, examinando las páginas con detalles de los (v é a s e a c o n t in u a c ió n ) , y u n a e s p e c if ic a c ió n d e e n v ío .
libros y seleccionando el libro, que comprará • L ín ea D eO rd en . E s t a e s u n a s i m p l e l í n e a d e o r d e n .
mediante algún mecanismo como el de presionar P o r e je m p lo la o r d e n d e la c o p ia d e u n lib r o . U n a
un botón. El sistema deberá mantener un carrito de o r d e n c o n s is t ir á e n u n a o m á s lí n e a s d e o r d e n . U n a
compras virtual, en el que los detalles de cada libro lí n e a d e o r d e n c o n t e n d r á in f o r m a c ió n a c e r c a d e
se almacenan. Conforme el carrito se va llenando q u é li b r o s e o r d e n a y la c a n t id a d o r d e n a d a ( u s u a l
de libros, se muestra al cliente el precio acumulado m e n te 1 ).
de todas sus compras. • C arrito. E s u n c o n t e n e d o r q u e e x i s t e d u r a n t e l a
5. Cuando el clienteha terminado de comprar en el sitio e x p lo r a c ió n d e l s it io W e b , p o r p a r te d e u n c lie n te q u e
Web, se le pedirá información acerca de qué forma r e a liz a u n a o r d e n . L o s c o n te n id o s d e l c a r r it o s e rá n
de envío se utilizará. Por omisión se mostrará la lí n e a s d e o r d e n . C u a n d o u n c lie n t e c o m p le t e u n a
opción de envío por correo estándar, y un servicio o r d e n , la s l í n e a s d e o r d e n d e l c a r r i t o y l a i n f o r m a
www.FreeLibros.org
de envío expreso garantizado para entregar dentro c ió n d e e n v í o p r o p o r c io n a d a p o r e l u s u a r io s e r á n a n e
de 24 horas. x a d a s a u n a o rd e n .
398
CAPÍTULO 22 D IS E ÑO O RI EN TA D O A O B JE T O S
OrdenEspera. Esta es una parte de la orden, la cual Estas fueron, entonces, las clases identificadasprinci
no puede cumplirse por las existencias del almacén. palmente. También se identificaronun número de actores:
Si el cliente está conforme, esperando por un libro . Cliente. Este es el actor principal: la persona que
que no está en existencia, entonces se realiza una lleva a cabo las acciones, que resultan en los mayo
orden de espera. Esta orden de espera se satisface, res cambios de estado del sistema.
cuando las existencias del libro se restauran por . Administrador de marketting. Es un actor importante
Libros-en-línea. que ajusta muchos de los parámetros del sistema,
Almacén. Esta es una colección de libros que se tales como el precio de los libros.
encuentran en existencia. Una orden de libro o de • Adm inistrador del control de inventarios. Alguien
colección de libros se manda al almacén y de ahí que controla los inventarios en un almacén y toma
se retiran los libros de sus cajas del almacén, se decisiones acerca de las órdenes.
empaquetan y se despachan al cliente. En ese Existen un gran número de casos de uso asociados
momento, se ajustan los detalles de las existen con estas acciones, muchas de ellas asociados con el
cias. actor cliente, se muestran en la Figura 22.25.
RegistroExistencias. Estos son los datos que des La selecciónde casos de uso asociadosconel Cliente,y
criben los detalles de las existencias de un libro; las mostradasenla Figura 22.25 incluyencasosdeusopara:
por ejemplo, cuántos hay en existencia, el nivel « Registro. Aquí el cliente proporciona su nombre y
actual cuando se ha hecho una requisición a las edi su clave. Una vez registrada, pueden examinar el
toriales, y la localización de los libros dentro del catálogo de libros.
almacén. . Ordenar. Aquí el cliente ordena una o más copias de
NotaEmpaque. Esta es una nota enviada con una un libro.
colección de libros al cliente. La nota de empaque . Realizar. El cliente completa la ordeny ordena al sis
contiene información acerca de cuántos libros se tema iniciar el proceso en que la orden se despacha.
enviarony la tarifa de envío aplicada. Tambiénpuede ■ Buscar un libro. El cliente busca, en el catálogo en
contener detalles de algunos libros, que no pudieron línea, un libro específico.
ser enviados porque no se encontraban en las exis . Eliminar tarjeta de crédito. Aquí el clientepuede eli
tencias.
minar una o más de las tarjetas de crédito registra
TarjetaCrédito. Un cliente pagará por sus libros das y asociadas con él.
mediante una tarjeta de crédito. El sistema permite ■ Registrar tarjeta de crédito. Aquí el cliente registra
a l cliente pre-registrar su o sus tarjetas, para que
no tenga que reescribirlas cada vez que haga una una o más de sus tarjetas de crédito al sistema.
orden. Una porción de uno de estos diagramas de clase para
el sistema, se muestra en la Figura 22.26. Un número
de roles asociados con el diagrama se ha omitido; regu
larmente se incluyen. Algunas de las relaciones entre
clase, también se omitieron.
El diagrama muestra muchas de estas clases antes
descritas. Las únicas clases que se omitieron son:
OrdenSatisfecha y OrdenEspera. Estas dos clases son
especializaciones de la clase Orden, que representauna
orden de libros para un cliente.
Borrar tarjeta
de crédito
Registrar
www.FreeLibros.org
tarjeta de crédito
F IG U R A 2 2 .2 6 . Una sección de un diagram a de clases
FIGURA 2 2 .2 5 . Algunos casos de u so para el actor Cliente. para el caso de estudio.
399
IN G E N IE R ÍA DEL S O F T W A R E . UN E N F O Q U E PR AC T I C O
C uando se hace un pedido, algunos de los artículos entre tarjetas de crédito y órdenes, en virtud de que una
pedidos p u d iero n no haberse servido, porque los libros ta rje ta de créd ito p a rtic u la r se u tiliz a p a ra p ag ar una
no estaban en existencia. C uando esto ocurre, la orden orden. D e cualquier m anera, se m u estra suficiente deta
se d iv id e en dos: to d o s los lib ro s que p u ed en p ro p o r lle para proporcionar u n a indicación de qué tan com
cionarse en un o b jeto O rdenS atisfecha, y aquellos que plicado se ve un diagram a de clases U M L.
no pudieron encontrarse, se registran en un objeto Orden- U n ejem plo de diagram a de secuencias asociado con
Espera. Las relaciones en el diag ram a de clases se d eta el caso en estudio se m u estra en la F igura 2 2 .27.
llan a continuación. A quí e l c lie n te o rd e n a un libro. E sto resu lta en el
• U n alm acén se asocia con u n núm ero de registros de registro de existencias para el libro consultado,y se ajus
existencias, los cuales detallan los libros alm acena ta si el libro está en existencia. Si el libro está en exis
dos en el alm acén. U n sim ple alm acén se asocia con tencia, un objeto de tipo línea de orden se crea, el cual
uno o m ás registros de existencia. se anexa a una orden, la cual se construye conform e el
clien te n avega p o r el sitio w eb de Libros-en-línea. E l
• U n registro de existencia se asocia con un solo libro,
diagram a final (Fig. 22.28) m uestra un diagram a de esta
y un libro se asocia con un solo registro de existencia.
do para el objeto Orden.
• U n a o rden puede consistir en u n n ú m ero de líneas U n cliente prim ero realiza la orden, y el estado del
de orden, y u n a línea de o rden será asociada con una o b jeto O rden se vuelve orden parcial; entonces se da al
so la orden. cliente la opción de añadir m ás libros o de elim inar libros
• U n cliente reg istrará su núm ero de tarjeta de crédito de su orden. E n cualquier m om ento de la construcción
al sistem a, un núm ero de tarjeta de crédito se asocia de la orden, el cliente puede cancelar la orden, esto con
co n u n solo cliente. duce a la term inación. C uando el cliente indica que se
h a llegado al fin de la orden, entonces la orden se vuel
• U n cliente se asocia con un núm ero de órdenes satis
ve u n a orden de libros com pleta. E n este punto, el clien
fe c h a s, las cu ales se re a liz a n sobre u n p e río d o de
te tiene dos opciones: cancelar al orden o especificarel
tiem po. C ada o rden satisfecha se asocia con un solo
tipo de envío que se u sará para la orden. Si se seleccio
cliente.
n a el tipo de envío, en to n ces la orden se convierte en
• U n clien te se a so cia con un núm ero de órdenes en u n a orden com pleta. E n e sta etapa, el cliente tiene otras
espera, que actualm ente no p u ed en ser satisfechas. dos opciones: confirm ar la orden, en este caso la orden
C ada ord en en esp e ra se asocia con un solo cliente. se envía para ser procesada, o cancelar la orden. Ambas
L a F ig u ra 22.26 m u e stra solo alg u n as de las rela- opciones conducen al punto de salida del diagram a de
c ie n e s involucradas, p o r ejem p lo , ex iste u n a relación estados.
—¡ajLEBQGBAMAClPH ..OaiEltIACfl. A.OBIE TOS

L a e ta p a fin a l de d e sa rro llo , d e n tro d el c ic lo de v id a U n ejem plo del código esqueleto de una clase se m ues
o rie n ta d a a o b je to s , es la p ro g ra m a c ió n . N o e s la tra a continuación.
in ten ció n de e ste lib ro lle g a r a m á s d e ta lle a c e rc a de cla ss C lie n te {
e s te p ro c e s o ; la p r o g ra m a c ió n e s a n a liz a d a c o m o p r iv a te S tr in g NomhreCli en te;
im p o rtan te p e ro co m o activ id ad s u b s id ia ria al a n á li p r iv a te S tr in g D ireccionC li en te;
sis y d iseñ o ; p e ro se p ro p o rc io n a u n a p e q u e ñ a in tro / / se definen más a tr ib u to s aquí
d u c c ió n en e l le n g u a je d e p ro g ra m a c ió n J a v a . L a p u b lic S tr in g obtenerN om breCliente{ )
se c c ió n o tra s le c tu r a s y f u e n t e s de in fo rm a c ió n al í
fin al del cap ítu lo d e ta lla u n g ran n ú m e ro de b u enos //c ó d ig o para obtenerNombreCliente
lib ro s so b re el tem a. }
El proceso de program ació n involucra la conversión p u b lic vo id m odiñcarD ireccionC liente( S trin g
de un diseño orientado a objetos en un código de p ro dirección)
gram a. E fectivam ente, esto significa que las clases defi í
//c ó d ig o para m odiñcarD ireccionC liente
n id as en el d iseñ o d e b en ser c o n v ertid as en c la ses
expresadas en un lenguaje de prog ram ació n orientado }
a objetos com o Java, C + + o Sm allTalk. E sta sección se
//c ó d ig o p a r a la s operaciones r e s ta n te s
concentra en Java, que se e stá v o lviendo rápidam ente
}
el lenguaje de program ació n de facto, p ara d esarrollar
los m odernos sistem as distribuidos. L a prim era línea de código define que el nom bre de
www.FreeLibros.org
U n a clase en Jav a se introduce p o r m ed io de la p a la la clase será C liente. In m ed iatam en te a continuación,
bra clave class, dentro del código p ara la clase; el p ro las d escrip cio n es de atributos de clase. E n el código
gram ador define los atributos y operaciones para la clase. anterior, solo se m uestran dos atributos: el nom bre del
400
CA P Í T U L O 22 D I S E Ñ O O R IE N TA DO A OB JE TO S
cliente y su dirección; ambos se expresan como cade La palabra clave String especificaque esta operación
nas de caracteres. Normalmente, enun sistemareal exis devolverá una cadena, y la palabra clavepu blic descri
ten muchos más atributos asociados con la clase. La be el hecho de que cualquier código de cualquier otra
descripción del atributo incluye su tipo (S trin g ) y s u clase puede hacer u so de esta operación: p u b lic e s el
visibilidad. En el ejemplo anterior, a los dos atributos opuestode la palabra claveprivate, detalladaen el párra
mostrados se les asigna la visibilidad de privados. Esto fo anterior.
significa que pueden ser accedidos por cualquier códi El código para esta operación se encierra con llaves
go dentro de la clase pero no por alguno fuera de ella; ({() de operación.
por ejemplo, el código que pertenece a otra clase. Esto La operación modificarDirecciónCliente difiere en
significa que las variables de instancia se encapsulan dos cosas de la operación obtenerNombreCliente. En
dentro de la clase. Existen otros modificadores de visi primer lugar, le antecede la palabra void; esto indica que
bilidad en Java: Se encontrará con otro después, cuan no hay resultado que regresar de la operación: la ope
do se describan las operaciones de una clase. ración solo lleva a cabo acciones que modifican los atri
butos de la clase. En segundo, la operación asociada con
el argumento dirección, que es una cadena que repre
^ istroStock) ( eS I r) :Orden
J senta la nueva dirección de un cliente, que reemplaza
rá a la anterior.
Cliente
Esto, entonces, es la forma básica de una clase en
"‘i OrdenLibro Java; es muy similar en muchas formas a la estructura
de clases expresadapara los lenguajes orientados a obje
tos, con excepción de SmallTalk. A continuación, se
muestra el código completo de una clase muy simple.
La clase representa un contador, que es un dispositivo
que sirve pararegistrar el número de veces que una pági
na web ha sido accedida por visitantes de un sitio Web.
c la s s Contador {
p r ív a te i n t veces;
p u b lic Contador ( i n t v a lo r ln ic io )
{
FIG U R A 2 2 .2 7 . Un diagrama de secuencia para el caso de veces = v a lo rln ic io ;
estudio.
}
p u b lic vo id ajustaContador ( in t v a lo r )
También se han mostrado dos operaciones dentro de {
la clase Cliente. La primera es la operación obtener- veces = va lo r;
NombreCHente, que devuelve el nombre del cliente des }
critopor la clase. p u b lic i n t obtenerC uenta( )
í
re tu r n veces;
}
p u b lic vo id incrementaCuenta ( )
Orden(libro) vecese t ;
}
}
La clase denominada Contador tiene un atributo
veces, que registra el número de veces consultado por
usuarios. La siguiente operación tiene el mismo nom
bre de la clase, y se conoce como constructor. Este es
Seleccionar
Transporte
un fragmento de código ejecutable, que se ejecuta cuan
tancelarOrden \ ( t i p o transporte) do el objeto se crea, recibe un argumento entero que es
el valor inicial del contador. Cuando el usuario de la
Orden Completa clase desea crear un objeto contador, el código es el
siguiente:
Contador cont = new Contador ( 0 ) ;
www.FreeLibros.org
Cancelarorden La palabra clave new llama al constructorpara crear
un objeto contador que tiene un solo atributo veces ini-
FIG U R A 2 2 .2 8 . Un diagrama de estados. cializado a cero.
401
I N GEN IE RÍ A DEL S O F TW A RE . UN EN F O Q U E P R A C T I C O
La operación obtenerCuenta regresa el valor actual del R ecuérdese que, en la herencia, las operaciones en
contador, la operación ajustaC ontador ajusta el atributo la superclase (en nuestro clase C ontador) se heredan por
veces a un valor dado p o r su argum ento, y la operación la su p e rc la se (en n u e stro c a so T ie m p o C o n ta d o r), a
incrementaCuenta in c re m e n ta d atributo veces en uno (la m enos que se sobrecarguen.
operación ++ es la operación de increm ento en uno). La prim era operación ajustaContador, sobrecarga al
La sintaxis de Java p ara env iar m ensajes al objeto es m étodo correspondiente en la superclase. Prim ero ini-
la siguiente: cializa el atributo veces dentro de la superclase, hacien
Objeto.nombreOperación ( argumentos ) do una llam ada a su constructor (la palabra clave súper
se utiliza para ello), y luego se construye un nuevo obje
P or ejem p lo p ara in c re m e n ta r u n o b jeto C o ntador
to Tim e. Este objeto se define en cualquier otro lugar, y
cont el código sería: no se debe m ostrar el código. La operación ajustaC on
c o n t. increm entaCuenta< ); tador tam bién sobrecarga la operación correspondiente
La clase anterior es m uy sim ple; de cualq u ier m odo, dentro de C ontador. El código dentro de la clase prim e
sirve p ara ilu strar las características estructurales p rin ro inicializael atributo de la superclase, para que sea igual
cipales de cóm o se define una clase. E xisten otras co m a valor. Luego envía un m ensaje setNow al atributo hora
plicaciones, com o el hecho de que pueden definirse varios A cceso, para ajustar su v alo r a la hora actual, el código
niveles de visibilidad; de cualq u ier m o d o , esto queda para la operación setN ow form a parte de la clase Time y
fuera del alcance de un libro de ingeniería del softw are. no se m uestra. El m étodo obtenH ora es sim ple: todo lo
E xisten dos m aneras de com binar clases: la prim era que hace es regresar el v alor de horaAcceso. La opera
es la herencia y la segunda es la agregación. Los lenguajes ción increm entaC uenta sobrecarga la operación corres
de program ación o rientada a objetos co ntienen recursos pondiente en la clase C ontador. Prim ero increm enta el
que perm iten a am bas ser im plem entadasfácilm ente. valor de veces, llam ando a la operación incrementaCuenta
E n Java, la palabra clave extends se utiliza p ara d eri dentro de la superclase, luego ajústale v alor de horaAc
var una clase de una y a existente p o r m ed io de la h eren ceso, enviando un m ensaje setN ow al objeto. El método
cia. P or ejem plo, asúm ase que se n ecesita derivar una obtenC uenta, heredado de la c la s e C o n tad o r,n o necesi
clase nueva, que se parece m u ch o a la clase C ontador, ta ser sobrecargada, y a que todo lo que hace es regresar
pero que adem ás registra la h o ra a la que la cuenta se el v alor del atributo veces, dentro de la superclase.
increm entó. El esqueleto de la nuev a clase, que hereda Esto es, com o un lenguaje de program ación orienta
la clase C ontador, se m uestra a continuación: do a objetos im p lem entala herencia. La implem entación
c la s s TiempoContador ex ten d s Contador{ de la agregación es m ás sim ple: todo lo que involucra
/ / Algunos a tr ib u to s nuevos es la inclusión de las partes agregadas com o atributos de
/ / Algunas operaciones nu eva s. clase. P o r e je m p lo , la c lase sig uiente C om putadora,
} representa a una com putadora; form a parte de un siste
m a para p lanificar la fabricación de com putadoras. Una
La palabra clave extends especifica el h echo de que
com putadora es agregada desde un m onitor, un teclado,
la clase T iem poC ontador se h ereda de la clase C onta
una unidad de proceso y así sucesivam ente. Esto se mues
dor. El código p ara la clase se m uestra a continuación:
tra en la clase com o una serie de atributos.
c la ss TiempoContador ex ten d s Contadorf
c la s s Computer {
Time horaAcceso;
p r iv a te M onitor mon;
p u b lic TiempoContador( i n t v a lo r ln ic io )
p r ív a te KeyBoard kb;
{ p r iv a te P rocessor proc;
superf v a lo r ln ic io ) ; / / demás a tr ib u to s
horaAcceso = new Tíme horaAcceso( ) ; //d e fin ic ió n de la s operaciones asociadas con
l la computadora.
p u b lic void ajustaC ontador( in t v a lo r ) )
{
C o m o un eje m p lo fin a l de c ó d ig o en Jav a , se ha
super .ajustaC ontador ( in t v a l o r ) ;
horaAcceso.setNow) ); re p ro d u c id o m u c h o del c ó d ig o p a ra un c lie n te , del
} pequeño caso de estudio m ostrado en la Sección 22.6.
p u b lic Tíme obtenHora ( ) U n cliente es alguien que com prará libros usando inter
{ net. El código para m uchos de los m étodos se encuen
retu rn horaAcceso; tra a continuación:
} c la s s C lie n te
p u b lic void increm entaCuenta( ) {
{ Ctring nombre, d irecció n , típoTarj etaCredi to ,
super .incrementaCuenta í ) ; c la v e , infoSeguridad;
www.FreeLibros.org
horaAcceso. setNow( ) ; H istorialCom pras He;
} OrdenesActuales ordenesA;
} P refere n cia s p r e f ;
402
CAPÍTULO 22 D I S E Ñ O ORIE NT ADO A O B JE T O S
P ublic o b te n P re fC lie n te { ) í
( r e tu r n Hc;
re tu rn p r e f; }
} p u b lic vo íd inicO rdenesAf )
p u b lic C tring obtenerNombre( ) {
{ / / u t i l i z a e l método se tC lea r de Ordenes-
re tu rn nombre; A c tu a le s para
} / / i n i c i a l i z a r la s ordenes a c tu a le s
p u b lic C tring obtenD ireccion( ) o rd en esA .setC lea r( );
{
re tu rn d ire c c ió n ; p u b lic vo íd agregaOrdenf Orden ord J
} {
p u b lic C tring obtenTipoTajetaC redito ( ) / / U t i l i z a e l método addCurrentOrders de
{ O rdenesActuales
r e tu m tipoT arjetaC redi to; ordenesA.addCurrentOrders ( ord );
} }
p u b lic C tring obtenC lave( ) p u b lic vo íd borraOrden ( Orden ord )
t {
re tu rn clave; / / U t i l i z a e l método removeCurrentOrder de
1 O rdenesActuales
p u b lic C tring o b te n ln fo S e g u n d a d ( ) OrdenesA.removeCurrentOrder( ord );
i }
r e tu m ínfoSeguridad; p u b lic i n t numOrdenesActuales( )
} {
p u b lic vo íd ponNombre( C tring nom ) / / U t i l i z a e l método no de la c la se Orde-
{ nesA ctuales
nombre = nom; r e tu m OrdenesA,no( );
}
p u b lic vo íd ponDireccion { C tring d ir ) p u b lic O rdenesActuales obtenOrdenesActuales ( )
i {
d ire c c ió n = d ir ; r e tu m OrdenesA;
}
p u b lic void ponTipoTarjetaC reditol C trin g t t c )
(
tipoTarjetaC redi to = t te ; Muchos de los métodos sonmuy simples: todo lo que
} hacen es o ajustar u obtener los valores de los atributos
p u b lic ponClavef C tring c l v )
que se encuentranen la clase Cliente. Estos atributos son:
i
cla ve = c lv ; • nom bre. Nombre del cliente.
1 • d irecció n . Dirección del cliente.
p u b lic voíd ponlnfoSeguridadf C tring is g ) ■ tip o T a rjeta C réd ito . Una cadena que describe el tipo
t de tarjeta de crédito usada por el cliente.
ÍnfoSeguridad = is g ; . clave. La cadena usada por el cliente, para acceder
)
p u b lic voíd ponP referencias ( C tring p r f )
al sitio de venta de libros.
{
. ín foS egu ridad. Esta es una cadena que se utiliza por
pref = p r f; el cliente, para identificarsecon el equipo de servicio
1 del sitio, en caso de que se olvide su clave. Por ejem
p u b lic voíd iniciaH istC om pras( ) plo, puede contenerel lugar de nacimiento del cliente.
t . Hc. Es el historial de los libros que el cliente ha com
/ / i n í c i a l i z a e l h is t o r i a l de compras con prado.
e l m é t o d o setC lear
. o rd en esA . Contiene los detalles de cada orden, que
} se lleva a cabo en ese momento; por ejemplo, una
p u b lic voíd agregaTransCompra (TransCompra t e ) orden que no puede ser satisfecha completamente.
{ • p r e f. Contiene una lista de preferencias de compra
/ / u t i l i z a e l método add definido en H isto - para el cliente. Por ejemplo, el hecho de que el cliente
rialCompras para normalmente compra novelas de terror.
//a g r e g a r un lib r o a la tran sa cció n de
compras al o b je to
Existe un grupo de métodos, que pueden llamar a
//C lle n t e métodos definidos en otras clases; por ejemplo, el méto
www.FreeLibros.org
H e.add( te ); do b o rra O rd e n , que elimina una orden de los detalles
de cliente, y utiliza el método re m o ve C u rren tO rd e r de
p u b lic HistCompras obtenHistCompras{ ) la clase O rdenesActuales.
403
i n g e n i e r í a d e l s o f t w a r e . u n e n f o q u e p r ac t i c o
El diseño orientado a objetos traduce el modelo de Durante el diseño del sistema, la arquitecturadel sis
AOO del mundo real, a un modelo de implementación tema orientado a objetos se desarrolla.Además del desa
específica, que puede realizarse en software. El pro rrollo de sistemas, de sus interaccionesy de su colocación
ceso de DOO puede describirse como una pirámide dentrode las capas arquitectónicas,el diseño de sistemas
compuesta por cuatro capas. La capa fundamental se considera la componente de interacción con el usuario,
centra en el diseño de subsistemas, que implementan una componente de administraciónde tareas y una com
funciones principales de sistema. La capa de clases ponente de manejo de datos. Estas componentesde sub
especifica la arquitectura de objetos global, y lajerar sistemas proporcionan la infraestructura de diseño, que
quía de clases requerida para implementar un sistema. permite a la aplicaciónoperar efectivamente. El proceso
La capa de mensajes indica cómo debe ser realizada de diseño de objetos se centraen la descripciónde estruc
la colaboración entre objetos, y la capa de responsa turas de datos, que usan los atributos de clase, los algo
bilidades identifica las operaciones y atributos que ritmos que usan las operaciones y los mensajes que
caracterizan cada clase. • permiten colaboraciones entre objetos relacionados.
Al igual que el AOO, existen diferentes métodos de Los patrones de diseño permiten al diseñador crear
D O O . UML es un intento de proporcionar una aproxi la arquitectura de diseño integrando componentes reu-
mación simple al D O O , que se aplica en los dominios sables. La programaciónOO extiendeel modelo de dise
de aplicaciones. UML y otros métodos, aproximan el ño a un dominio de ejecución. Un lenguaje de
proceso de diseño mediante dos niveles de abstracción programación OO se usa para traducir las clases, atri
—diseño de subsistemas (arquitectura) y diseño de obje butos, operaciones y mensajes, de manera que puedan
tos individuales-. ejecutarse por la máquina.
.....
[BEN99] Bennett, S., S. M cRobb y R. Farmer, O bject [GAM95] Gamma, E., et al., D esign Patterns, Addison-
O riented Svstem A nalvsis and D esign Using UML, Wesley, 1995.
M cG raw H Íll, 1999. '
[GOL83] Goldberg, A., y D. Robson, Smalltalk-80: The
[BIH92] Bihari, T., y P. Gopinath, «Object-Oriented Real- Languuge and Its Im plem entation, Addison-Wesley,
Time Systems: Concepts and Examples», Computer, vol. 1983.
25, n.3 12,Diciembre 1992,pp. 25-32.
[JAC92] Jacobson, I., Object-Oriented Software Enginee-
[B 0094] Booch, G., Object-Oriented Analysis and Design, ring, Addison-Wesley, 1992.
2.- ed., Benjamín Cummings, 1994. [JAC99] Jacobson, I., G. Booch y J. Rumbaugh, Unified
[B 0 0 9 9 ] Booch, G., 1. Jacobsony J. Rumbaugh, The Uni- Software Development Process, Addison-Wesley, 1999.
fied M o d ellin g Language User Guide, Addison-Wesley, [MEY90] Meyer, B., Object-Oriented Software Construc-
1999. tion, 2.- ed., Prentice-Hall, 1988.
[B R 091] Brow n, A.W., O bject-O riented D atabases, [PRE95] Pree, W., D esign Patterns f o r Object-Oriented
McGraw-Hill, 1991. Software Development, Addison-Wesley, 1995.
[BUS96] Buschmann, F., et al.,.4 System ofPatterns: Pat- [RUM91] Rumbaugh, J., et al., Object-Oriented Modelling
tern Oriented System Architecture, Wiley, 1996. and Design, Prentice-Hall, 1991.
[COA91] Coad, P., y E. Yourdon, Object-Oriented Design, [RUM99] Rumbaugh, J., I. Jacobsony G. Booch, The Uni-
Prentice-Hall, 1991. fi e d M odelling Language Reference M anual, Addison-
Wesley, 1999.
[COX85] Cox, B., «Software Ies and Objective-C», Unix-
World, primavera de 1985. [R A 094] Rao. B.A., O bject-O riented Databases: Tech
nology, A p p lica tio n s and P roducts, McGraw-Hill,
[DAV95] Davis, A., «O bject-O riented Requirem ents to 1994.’
Object-Oriented Design: An Easy Transition?», J.Sys
tems Software, vol. 30, 1995, pp. 151-159. [TAY92] Taylor, D.A., Object-Oriented Information Sys
tem, Wiley, 1992.
[DOU99] Douglass, B., Real-TimeUML: Developing Effi-
cient Object.sfor Embedded Systems, Addison-Wesley, [WIR90] Wirfs-Brock, R., B. Wilkerson y L.Weiner, Desig-
ning Object-Oriented Software, Prentice-Hall, 1990.
www.FreeLibros.org
1999. '
404
CAPÍTULO 22 DISENO O R I E N T A D O A O B J E T O S
21.1. La pirámide de diseño para el DOO difiere, de alguna 2 1.12 . A p liq u e e l e n fo q u e d e l D O O e x a m in a d o a n te r io r m e n

manera, de la descrita para el diseño del software conven te e n e s te c a p ítu lo , p a ra d is e c c io n a r e l d i s e ñ o d e l s is te m a
cional (Capítulo 13). Vea las diferencias y semejanzas de H o g a rS e g u ro . D e fin a to d o s los su b s is te m a s re le v a n te s, y d e s a
ellas dos. rro lle e l d is e ñ o d e o b je to s p a ra la s c la se s im p o rta n te s .
21.2. ¿Cómo difieren el DOO y el estructurado? ¿Qué aspec 2 1 .1 3 . A p liq u e e l e n fo q u e d e l D O O e x a m in a d o e n e s te c a p í
tos de estos dos métodos de diseño son los mismos? tu lo a l s is te m a S S R B d e sc rito e n e l p r o b le m a 12.13.
21.3. Revise los cinco criterios para la modularidad eficaz exa 2 1 .1 4 . D e s c r ib a un ju e g o d e v íd e o y a p liq u e e l e n f o q u e d e l
minados en la Sección 22.1.2. Usando el enfoque de diseño D O O e x a m in a d o e n e ste c a p ítu lo , p a ra r e p re s e n ta r su d ise ñ o .
descrito posteriormente en el capítulo, demuestre cómo se
logran estos cinco criterios. 2 1 .1 5 . U s te d e s re s p o n sa b le d e l d e s a rro llo d e u n s is te m a d e
c o rre o e le c tr ó n ic o a im p le m e n ta rse so b re u n a r e d d e P C . El
21.4. Seleccione uno de los métodos de DOO presentados en s is te m a d e e -m a il p e rm itirá a lo s u s u a rio s e s c rib ir c a r ta s d iri
la Sección 22.1.3, y prepare un tutorial de una hora para su g id a s a o tro u su a rio o a u n a lis ta d e d ire c c io n e s e s p e c íf ic a .
clase. Asegúrese de mostrar todas las convenciones gráficas L a s c a rta s p u e d e n se r e n v ia d a s , c o p ia d a s , a lm a c e n a d a s , e tc.
de modelado que sugiere el autor. El s is te m a d e c o rre o e le c tró n ic o h a rá uso d e la s c a p a c id a d e s
21.5. Seleccione un método de DOO no presentado en la Sec d e p r o c e s a m ie n to d e te x to e x is te n te s p a ra e s c rib ir la s c a rta s .
ción 22.1.3, (por ejemplo, HOOD), y prepare un tutorial de U s a n d o e s ta d e s c rip c ió n c o m o p u n to d e p a r tid a , d e r iv e u n
una hora para su clase. Asegúrese de mostrar todas las con c o n ju n to d e re q u is ito s, y a p liq u e la s té c n ic a s d e D O O , p a r a
venciones gráficas de modelado que sugiere el autor. c r e a r u n d is e ñ o d e a lto n iv e l, p a ra e l siste m a d e c o r re o e l e c
tró n ic o .
21.6. Analice cómo los casos de uso pueden servir como una
fuente importante de información para el diseño. 2 1.16 . U n a n a c ió n u b ic a d a e n u n a p e q u e ñ a isla h a d e c id id o
c o n s tru ir u n siste m a d e c o n tro l d e tráfico a é re o (C T A ) p a ra s u
21.7. Investigue un entorno de desarrollo IGU, y muestre cómo
ú n ic o a ero p u e rto . E l siste m a se e sp e c ific a c o m o sigue:
el componente de interacción hombre-máquina se implemen
to en el mundo real. ¿Qué patrones de diseño se ofreceny cómo T o d o s lo s a v io n e s que a te rriz a n en el a e ro p u e rto d e b e n
se usan? te n e r u n tra n s m is o r q u e tra n s m ita e l tip o de a v ió n y lo s
d a to s d el v u e lo e n u n p a q u ete, c o n fo rm ato de a lta d e n s i
21.8. La gestión de tareas en sistemas OO puede ser muy com d a d , a la e s ta c ió n de C T A de tie rra. L a e stac ió n d e CTA de
pleja. Realice alguna investigación sobre métodos de D O O , tie rra p u e d e in te rro g a r a u n a v ió n , p a ra so lic ita r in fo rm a
para sistemas en tiempo real (por ejemplo, [BIH92] o c ió n e sp e c ífic a y a lm a ce n arla en una base de d ato s d e a v io
[DOU99]) y determine cómo la gestión de tareas se realiza nes. Se c re a un m o n ito r de g rá fic o s p o r o rd e n ad o r, a p a rtir
dentro de este contexto. de la in fo rm a c ió n a lm a c e n a d a , y se la m u e stra a u n c o n
21.9. Examine cómo el componente de manejo de datos se tro la d o r d e tráfico . E l m o n ito r se a c tu a liz a c a d a 10 se g u n
dos. T o d a la in fo rm a c ió n e s a n a liz a d a , p a ra d e te rm in a r si
implementaen un entorno de desarrollo OO típico.
e x is te n « situ a c io n e s p e lig ro sa s» . E l c o n tro la d o r de trá fic o
21.10. Escriba un artículo de dos o tres página sobre bases de a é re o p u e d e in te rro g a r la b a se de d a to s, p a ra b u scar in fo r
datos orientadas a objetos, y analice cómo pueden usarse, para m a c ió n e sp e c ífic a a c e rc a de c u a lq u ie r a v ió n que se m u e s
desarrollar el componente de gestión de datos. tre e n p a n ta lla .
21.11. ¿Cómo reconoce un diseñador las tareas que deben ser U s a n d o e l D O O , c re e u n d is e ñ o p a ra e l siste m a d e C T A .
recurrentes? N o in te n te im p le m e n ta rlo .
Además de las muchas referencias de este capítulo, los libros dos en la sección o t r a s l e c t u r a s yf u e n t e s d e i n f o r m a c i ó n del
de Gossainy Graham ( O b j e c t m o d e l l i n g a n d D e s i g n S t r a t e - Capítulo 21 también se centran en el diseño con un nivel de
g ie s , SIGS Books, 1998), Meyer (Object-Oriented Design detalle considerable.
Through Heuristics, Addison-Wesley, 1996), y Walden, Jean- El uso de patrones de diseño para el desarrollo de soft
Maic Nerson ( S e a m l e s s O b j e c t - O r i e n t e d S o f t w a r e A r c h i t e c - ware orientado a objetos tiene importantes implicaciones
t u r e : A n a l i s i s a n d D e s i g n o f R e l i a b l e S y s t e m s , Prentice-Hall, para la ingeniería del software basada en componentes, la
1995)cubren con bastante detalle el DOO. Fowler (R e f a c i ó - reutilización en general y la calidad global de los sistemas
r i n g : i m p r o v i n g t h e D e s i g n o f E x i s t i n g C o d e , Addison-Wes resultantes. Además de [BUS96] y [GAM95], muchos libros
ley, 1999) dirige el uso de técnicas orientadas a objetos para recientes dedican sus páginas al mismo tema, como los
rediseñar y reconstruir programas antiguos con el fin de mejo siguientes:
rar su calidad de diseño. Ambler, S.W., P r o c e s s P a t t e r n s : B u i l d i n g L a r g e - S c a l e
Muchos libros de diseño orientado a objetos publicados S y s t e m s U s i n g O b j e c t T e c h n o l o g y , Cambridge University
www.FreeLibros.org
recientemente enfatizan UML. El lector seriamente interesa Press, 1999.
do en aplicar UML a su trabajo debe adquirir [B 0 0 9 9 ], Coplien, J.O., D.C. Schmidt, P a t t e r n L a n g u a g e s o f P r o -
[RUM99] y [JAC99], Además, muchos de los libros referi- g r a m D e s i g n , Addison-Wesley, 1995.
405
I N GE NI E RI A DEL SOFTWARE. UN EN F O Q U E P R A C T I C O
F o w ler, M ., A n a l y s i s P a t t e m s : R e u s a b l e O b j e c t M o d e l s , E iffe l: Thom as, P., y R . W eedon, O b j e c t - O r i e n t e d P r o

A d d iso n -W esley, 1996. g r a m m in g in E if f e l, A d d iso n -W esley, 1997.
G rand, M ., P a t t e m s i n J a v a , vol. 1, John W ile y , 1998. Jezequel, J .M ., O h j e c t - O r i e n t e d S o f t w a r e E n g i n e e r i n g
Langr, J . , E s s e n t i a l Java S t y l e : P a t t e m s f o r I m p l e m e n t a - W i t h E i f f e l , A d d iso n -W esley, 1996.
t i o n , P re n tic e-H a ll, 1999. Java: Coad, P., M . M a y fie ld y J. K e m , J a v a D e s i g n : B u i l -
L a rm an , C . , A p p l y i n g U n í a n d P a t t e m s : A n I n t r o d u c t i o n d i n g B e t t e r A p p s a n d A p p l e t s , 2 .a ed., P re n tic e-H a ll, 1998.
t o O b j e c t - O r i e n t e d A n a l y s i s a n d D e s i g n , P re n tic e-H a ll, 1997. L e w is, J., y W. Loftus, J a v a S o f t w a r e S o l u t i o n s : F o u n d a -
M a rtin , R .C ., et a l . , P a t t e m L a n g u a g e s o j P r o g r a m D e s i g n t i o n s o f P r o g r a m , A ddison -W esley, 1997.
3 , A d d iso n -W esley, 1997. Sm alltalk: Sharp, A ., S m a l l t a l k b y E x a m p l e : T h e D e v e l o -
R ising, L ., y J. C oplien (eds.), T h e P a t t e m s H a n d b o o k : p e r ' s (J u id - C , M c G ra w -H ill, 1997.
T e c h n i q u e s , S t r a t e g i e s , a n d A p p l i c a t i o n s , S IG S B o o k s , 1998. LaL o n d e, W .R ., y J.R. P ugh, P r o g r a m m i n g i n S m a l l t a l k ,
Pree, W ., D e s i g n P a t t e r n s f o r O b j e c t - O r i e n t e d S o f t w a r e P re n tic e-H a ll, 1995.
D e v e l o p m e n t , A ddison -W esley, 1995. L o s libros que cubren temas de D O O , m ediante el u so de
Preiss, B ., D a t a S t r u c t u r e s a n d A l g o r i t h m s w i t h O b j e c t - dos o m ás lenguajes de program ación, proporcionan una idea
O r i e n t e d D e s i g n P a t t e r n s i n J a v a , John W ile y, 1999. y com paración de las capacidades de los lenguajes. Algunos
Vlissides, J., P attem H atching: D e s i g n P a t t e r n s A p p l i e d , títulos son:
Addison-W esley, 1998. D ra k e , C ., O b j e c t - O r i e n t e d P r o g r a m m i n g W i t h C + + a n d
V lissides, J .M ., J.O . C o p lie n y N . K e rth , P a t t e m L a n S m a l l t a l k , Prentice H a ll, 1998.
g a a g e s o f P r o g r a m D e s i g n 2 , A ddison-W esley, 1996. Joyner, I., O b j e c t s U n e n c a p s u l a t e d : J a v a , E iffe l a n d C + + ,
C ientos de libros de pro gram ación orientada a objetos P rentice H a ll, 1999.
(P O O ) han sido publicados. U n a m uestra de libros específi Zeigler, B.P., O b j e c t s a n d S y s t e m s : P r i n c i p l e d D e s i g n W it h
cos en lenguajes de P O O : I m p l e m e n t a t i o n s i n C + + a n d J a v a , Springer Verlag, 1997.
C + + : C ohoon, J.P., C + + P r o g r a m D e s i g n : A n I n t r o d u c - U n a am plia variedad de fuentes de inform ación sobre dise
t i o n t o P r o g r a m m i n g a n d O b j e c t - O r i e n t e d D e s ig n ,M c G ra w - ño orientado a objetos, así com o temas relacionados, están
H ill, 1998. disponibles en internet. U n a lista actualizada de referencias
B arclay, K . , y J. Savage, O b j e c t - O r i e n t e d D e s i g n W i t h a sitios (páginas) w eb, que pueden ser relevantes al DOO,
C + + , P re n tic e-H a ll, 1997. pueden encontrarse en h ttp ://w w w .p re s s m a n 5 .c o m
C A PÍT U L O
Q PR U E B A S O R IE N T A D A S
¿k O A O BJETO S
L o bjetivo de las pruebas, expresado de form a sencilla, es en co n trar el m a y o r núm ero
E posible de errores con una cantidad razonable de esfuerzo, ap licado so b re u n lapso de

tiem po realista. A p esar de que este objetivo fundam ental perm anece in a lterad o para el
softw are orientado a objetos, la naturaleza de los program as 0 0 cam b ia n la s estrateg ias y las
tácticas de prueba.
P uede argum entarse que, conform e el A O O y el DOO m aduran, una m ay o r reu tiliz a c ió n de
patrones de diseño m itigarán la necesidad de pruebas intensivas en los sistem as 0 0 . L a verdad
es ju s to lo contrario. B inder [BIN 94b] lo analiza, cuando afirma que:
C ada reutilización es un nuevo con tex to de uso y es prudente repetir las pruebas. P a re c e pro b ab le que
se necesitarán m enos p ruebas para o b ten er una alta fiabilidad en sistem as orien tad o s a objetos.
L a pru eb a de los sistem as 0 0 presentan un nuevo conjunto de re to s al in g en iero del soft

w are. L a definición de pruebas debe ser am pliada para incluir técnicas que d escu b ran errores
(revisiones técnicas form ales), aplicadas para los m odelos de A O O y D O O . L a in teg rid ad , com -
p leció n y co nsistencia de las representaciones 0 0 deben ser evaluadas co n fo rm e se c o n stru
yen. L as p ruebas de un id ad pierden m ucho de su significado, y las estrate g ias d e integración
cam bian de m odo significativo. E n resum en, las estrategias y tácticas de p ru e b a d eb en to m a r
se en cuenta p ara las características propias del softw are 0 0 .
VISTAZO RÁPIDO
¿Q ué e s ? La a rq u ite c tu ra d e so ftw a re la frustración a s o c ia d a c o n un produc- basado en usos y p r u e b a s d e a g ru p a -
o rie n ta d o a o b je to s se m a n ifie s ta en t o d e b a j a c alid ad . G o n e l propósito de miento, junto con los enfoques basados
una serie d e su b siste m a s o rg an izad o s en co n trar el m ayor n ú m ero posible de en fallos, se aplican para probar
por c a p a s , q u e e n c a p su la n c la s e s q u e errores, la s p ru e b a s d e b e n conducirse ?. exhaustivamente l a s c la s e s c o la b o ra
c o la b o ran e n tre sí. C a d a uno d e e sto s sistem áticam ente, y los casosdeprue doras. Por úllimo, lo s c a s o s d e uso
elem en to s d el siste m a (su b s is te m a s y ba deb en ser d e sig n a d o s mediante téc (desarrollados com o p a rte d e l m odelo
cla se sj.re a liz a n funciones que a y u d an n ica s d isc ip lin a d a s. de análisis OC) se u s a n p a r a d e sc u b rir
a alcan zar requerim ientos del sistem a.
¿C uáles so n lo s p a ro s? l as pruebas errores en el sc ftw a re a nivel d e v a li
Es necesario pro b ar un siste m a OO, en dación.
0 0 son e stra té g ic a m e n te similares a
una v a rie d a d d e niv eles d iferen tes, en ¿C nál e s e l ¡p re d se to o b te n id o ? Se
la s p ru e b a s d e sistem asconvencíonct-
un esfuerzo p a ra d e sc u b rir errores, que diseñan y documer t a n u n c o njunto d e
les. p ero tá c tic a m e n te d ife re n te s. Ya
d e b en ocurrir c u an d o la s c la s e s c o la casos de prueba, diseñados para pro
q u e los m odelos d e a n á lis is y diseño
b o ra n con o tra s e n tre sí, y los s u b s is bar clases, sus c o la b o ra c io n e s y cam-
0 0 son sim ila re s e n e stru c tu ra y con
tem a s se co m u n ican por m edio d é l a s portamien os; s e d e fin e n los re su lta d o s
ten id o a 1p ro g ram a 0 0 ,1 a s «pruebas»
c a p a s a rquitectónicas. esperados y s e r e g is tra n los r e s u lta
c o m ie n z a n c o n la re v is ió n de estos
¿Q uién lo h a c e ? L as p ru e b a s o rie n ta m odelos. U na vez q u e s e h a generado dos reales
d a s a objeto s se re a liz a n por in g e n ie el c ó d ig o ,la s p ru e b a s 0 0 comienzan ¿Cómo peed o esta r seg u re d e q u e lo
ro s d e so ftw a re y e s p e c ia lis ta s e n «en lo pequeño, con la s p ru e b a s d® h e lt@«li« co rred ó m en te? C u a n d o
pru eb as. c la se s. E x iste n p r u e b a s d is e ñ a d a s comienzan l a s p r u e b a s , s e c a m b ia su
¿P er q u é es im portante? S e d e b e e je p a ra probar la s o p e ra c io n e s d e la s c la punto de v is ta . ¡In te n ta «romper» si
c u ta r el program a a n te s d e q u e lle g u e s e s y e x a m in a r si los e rro re s e x iste n software! Diseñar los casos de prueba
al c lie n te ,c o n la in ten ció n e sp e c ífic a c u a n d o u n a c la s e c o la b o ra con otras. de una form a d isc ip lin a d a y re vi sar los
www.FreeLibros.org
d e d e sc u b rir to d o s los e rro re s, d e A sí com o la s c la s e s se in te g ra n p a ra casos de p ru e b a q u e s e c re a n con m eti
m a n e ra que el c lie n te no experim ente form ar un su b siste m a b a sa d o e n hilos. c ulosidad.
407
L a c o n s tru c c ió n d el s o ftw a re o rie n ta d o a o b je to s 3. El com portam iento del sistem a o sus clases pueden
co m ien za co n la cre a c ió n de los m o d elo s de análisis caracterizarse inadecuadam ente, para alojar el atri
y d iseñ o (C ap ítu lo s 21 y 22). D eb id o a la n a tu ra lez a buto irrelevante.
evolu tiv a del p arad ig m a de ingen iería de softw are 0 0 ,
estos m odelos co m ienzan com o rep resen tacio n es, rela Si el error no se descubre durante el análisis y se pro
tiv am en te in fo rm a le s, de los re q u isito s del siste m a, y p ag a m ás allá, los siguientes problem as pueden ocurrir
ev o lu c io n a n en m o d elo s d e ta lla d o s de c la s e s , co n e (y tendrán que evitarse con una n u eva revisión) duran
x io n es y re la c io n e s de c la se s, el d iseñ o del sistem a y te el diseño:
el d is e ñ o d e o b je to s (in c o rp o ra n d o u n m o d e lo de 1. L a localización im propia de la clase a un subsistem a
co n e c tiv id a d de o b jeto s p o r m ed io de m e n sa je s). E n y/o ta re as p u ede o c u rrir du ran te el diseñ o del sis
cada etap a, los m odelos p u ed en pro b arse, en un in ten tema.
to de d e sc u b rir e rro re s, antes de su p ro p a g a c ió n a la
sigu ien te ite ra c ió n . 2. El trabajo del diseño innecesario tendrá que ser recu
perado, para crear el diseño procedim ental, para las
operaciones que afecten al atributo innecesario.
3. El m odelo de m ensajes (m ensajería) será incorrecto

Debido a su rapacidad para detectar y corregir (debido a que deben diseñarse m ensajes para las ope
, defectos en productos de trabajo anteriores, raciones innecesarias).
las revisiones técnicas son por lo menos
tan importantes, en el control de los costes ’ Si el error perm anece sin detectarse durante el diseño
y la planificación, como las pruebas. y p a sa a la a c tiv id a d de c o d ific a c ió n , se g astará un
Steve McConne'l
esfuerzo considerable para generar el código que imple-
m enta un atributo innecesario, dos operaciones innece
P u ed e arg u m en tarse q u e la re v isió n de los m o d e sarias, m en sajes que c o n tro lan co m u n icacio n es entre
los de an álisis y d ise ñ o O O son e sp ecialm en te ú tiles, objetos, y m uchos otros aspectos relacionados. Adem ás,
y a que las m ism as e stru ctu ras se m á n tic a s (p o r e je m la p ru eb a de la clase absorberá m ás tiem po del necesa
p lo , c la se s, atrib u to s, o p e ra c io n e s, m en sajes), a p a re rio. U na vez que se encuentra el problem a en su totali
cen en los n iv e le s de a n á lisis, d ise ñ o y c o d ific a c ió n . dad, debe llevarse a cabo la m odificación del sistema,
P o r co n sig u ien te, un p ro b le m a en la d e fin ic ió n de los teniendo siem pre presentes l o s posibles efectos colate
a trib u to s de las c la s e s q u e se d e sc u b re n d u ra n te el rales producidos p o r el cam bio.
an álisis e v ita rá e fe c to s laterales q u e p u e d e n o c u rrir
si e l p ro b le m a n o se d e s c u b rie ra h a s ta el d ise ñ o o
im p le m e n ta c ió n (o in c lu so la sig u ie n te ite ra c ió n del
an á lisis).
P or ejem plo, considérese una clase en la que el núm e Existe unviejo dichoquedice«cortarporlosano».
ro de atributos se definen durante la p rim era iteración Sipierde tiemporevisandolos modelos deAOO
del A O O . U n atributo externo (extraño), se agrega a la y DOO, después loganará.
clase (debido al m alentendido del dom inio de pro b le
m a). Se especifican dos operaciones p ara m an ip ular el
atributo. Se realiza una revisión y un experto en el d o m i D urante las etapas finales de su desarrollo, los mode
nio señala el error. E lim in an d o el atrib u to irrelevante los de A O O y de D O O proporcionan inform ación subs
en esta etapa, los problem as y esfuerzos innecesarios se tancial acerca de la e stru ctu ra y c o m p o rtam ien to del
evitan durante el análisis: sistema. Por esta razón, estos m odelos deben estar some
tidos a una revisión rigurosa, antes de la generación de
1. Pueden haberse generado subclases especiales para código.
adoptar (alojar) el atributo innecesario o ex cepcio T odos los m o d elo s o rien tad o s a o b jeto s deben ser
nes a él. El trabajo involucrado en la creación de sub p robados (en este contexto, el térm ino «prueba» se uti
clases no necesarias se h a evitado. liza para incorporar revisiones técnicas form ales), para
2 . U n a m ala interpretación de la d efinición de la clase aseg u rar la e x a c titu d , c o m p le c ió n y consistencia
puede con d u cir a relaciones de clases incorrectas o [M G R 94], dentro del contexto de la sintaxis, sem ánti
irrelevantes. ca y pragm ática del m odelo [LIN 94].
CAPÍTULO 23 PRUE BAS OR IE N TA DA S A O BI ET O S
Los modelos de análisis y diseño no pueden probarse en gráfica de las conexiones entre clases. Toda esta infor
el sentidoconvencional,ya queno puedenejecutarse. S i n mación se puede obtener del modelo de AOO (Capítu
embargo, se pueden utilizar las revisiones técnicas for lo 21).
males (Capítulo 8) para examinar la exactitud y consis
tencia de ambos modelos de análisis y diseño.
232.1. Exactitud de los m od elos de AOO y DOO

La notacióny sintaxis que se utilizapara representar los
modelos de análisis y diseño se corresponderá con el Modelos de AOO
método específico de análisis y diseño, elegido para el
proyecto. Por consiguiente, la exactitud sintáctica se Para evaluar el modelo de clases, se recomiendan los
juzga en el uso apropiado de la simbología; cada mode siguientes pasos [MGR94]:
lo se revisa para asegurarse de que se han mantenido
1. Revisar el modelo C RC y el modelo objeto-relación.
las convenciones propias del modelado.
Durante el análisis y diseño, la exactitud semántica -Realizar un control cruzado, para asegurarse de que
debejuzgarse basada en la conformidaddel modelo con todas las colaboraciones implicadas en el modelo de
el dominio del problema en el mundo real. Si el mode AOO hayan sido representadas adecuadamente.
lo refleja con exactitud el mundo real (al nivel de deta
¿Qué pasos deben seguirse
lle apropiado a la etapa de desarrollo en la que se revisa
el modelo), entonces es semánticamente correcto. Para
determinar si el modelo enrealidadrefleja el mundoreal,
debepresentarse a expertos en el dominio del problema,
• para revisar el modelo
de clases?
2. Inspeccionar la descripción de cada tarjeta CRC,

quienes examinarán las definiciones de las clases y sus p a ra determinar si alguna responsabilidad delegada
jerarquías, para detectaromisiones o ambigüedades.Las esparte de la definición del colaborador. Por ejem
relaciones entre clases (conexiones de instancia) se eva plo, considérese una clase definida para un sistema
lúanpara determinar si reflejan con exactitud conexio de control de punto de venta, llamada venta a cré
nes del mundo real'. dito. Esta clase tiene una tarjeta CRC, que se ilustra
en la Figura 23.1.
2 3 2 2 .C o n siste n c ia d e lo s m o d e lo s d e AOO Para esta colección de clases y colaboraciones, se
y DOO pregunta si algunaresponsabilidad (por ejemplo, leer
La consistencia de los modelos de AOO y DOO debe la tarjeta de crédito) se cumple si se delega al cola
juzgarse «considerando las relaciones entre entidades borador nombrado (Tarjeta de crédito). Esto signi
dentrodel modelo. Un modelo inconsistentetiene repre fica que la clase Tarjeta de crédito posee una
sentaciones en una parte, que no se reflejan correcta operación para ser leída. En este caso, la respuesta
mente en otras partes del modelo» [MGR94], es «Sí». El objeto-relación se recorre,, para asegu
Para evaluar la consistencia, se debe examinar cada rarse de que todas las conexiones son válidas.
clasey sus conexiones a otras clases. Un modelo clase-
responsabilidad-colaboración (CRC), y un diagrama tmmmsm
objeto-relaciónpueden utilizarse para facilitar esta acti Sugerenclasadlclonalespara conducir una revisión
del modelo CRC se presentan en el Capítulo 21.
vidad. Como se comentó en el Capítulo 21, el modelo
CRC se compone de una tarjeta índice CRC. Cada tar
jeta CRC muestra el nombre de la clase, sus responsa 3. Invertir la conexiónpara asegurarse de que cada cola
bilidades (operaciones)y sus colaboradores (otras clases borador que solicita un servicio recibe las peticiones
a las que se envían mensajes y de las cuales depende de una fuente razonable. Por ejemplo, si la clase Tar
para el cumplimiento de sus responsabilidades). Las j e t a de crédito recibe una petición de cantidad de
colaboraciones implican una serie de relaciones (por compra de la clase Venta a crédito, existirá un pro
ejemplo, conexiones), entre clases del sistema O O . El blema. Tarjeta de crédito no reconoce la cantidad de
modelo objeto-relaciónproporciona una representación compra.
www.FreeLibros.org
1 Les casos de uso poseen un valor incalculable, en el seguim iento
de los m odelos de análisis y diseño, frente a los escenarios del m undo
real para el sistem a OO.
409
INGENIERÍA DEL S O F T W A R E . UN EN F O Q U E P R A C T I C O
U n a v e z q u e se c re a e l m o d e lo d e D O O ( C a p í tu lo 2 2 ),
Nombre de la clase: venta a crédito d e b e n l l e v a r s e a c a b o t a m b i é n la s r e v i s i o n e s d e l d i s e ñ o
Tipo de la clase: evento de transacción d e l s i s t e m a y d e l d i s e ñ o d e o b j e t o s . E l d i s e ñ o d e l s is t e
Características de la clase: intangible, atómica, secuencia!, m a d e s c r ib e e l p r o d u c t o a r q u it e c t ó n ic o g lo b a l, lo s s u b
permanente, protegida s is t e m a s q u e c o m p o n e n e l p r o d u c t o , la m a n e r a e n q u e
Responsabilidades: Colaboradores: lo s s u b s is t e m a s s e a s ig n a n a lo s p r o c e s a d o r e s , la a s ig
n a c i ó n d e c la s e s a s u b s i s t e m a s y e l d i s e ñ o d e l a i n t e r f a z
Leer tarjeta de crédito Tarjeta de crédito .
d e u s u a r io . E l d is e ñ o d e o b je t o s p r e s e n ta lo s d e ta lle s d e
Obtener autorización A utorización de crédito
c a d a c l a s e , y la s a c t i v i d a d e s d e m e n s a j e r í a n e c e s a r i a s
Enviar por correo p a r a i m p l e m e n t a r la s c o l a b o r a c i o n e s e n t r e c la s e s .
Etiqueta de producto
cantidad de compra
Vendedor
A rchivo a u d ito r
G enerar factura Factura
Modelos de DOO
F IG U R A 2 3 .1 . Un ejem plo de tarjeta índice CRC usada para E l d is e ñ o d e s is t e m a s e r e v is a e x a m in a n d o e l m o d e
revisión. lo o b je t o - c o m p o r ta m ie n to d e s a r r o lla d o d u r a n te e l A O O ,
y la c o r r e s p o n d e n c ia n e c e s a ria d e l c o m p o r ta m ie n to d e l
4. U t iliz a n d o la s c o n e x io n e s in v e r t id a s , y a e x a m in a
s is t e m a , f r e n t e a lo s s u b s is t e m a s d is e ñ a d o s p a r a lo g r a r
d a s e n e lp a s o 3 , d e t e r m in a r s i o t r a s c la s e s s e r e q u ie
e s te c o m p o r ta m ie n to .
re n y s i la s r e s p o n s a b ilid a d e s s e h a n r e p a r tid o
L a c o n c u r r e n c ia y a s ig n a c ió n d e ta re a s t a m b ié n se
a d e c u a d a m e n te e n tr e la s c la s e s .
r e v i s a n d e n t r o d e l c o n t e x t o d e l c o m p o r t a m i e n t o d e l s is
te m a . L o s e s ta d o s d e c o m p o r t a m ie n t o d e l s is t e m a s e e v a
5 . D e te r m in e s i la s r e s p o n s a b ilid a d e s m u y s o l ic it a
lú a n p a r a d e t e r m in a r c u á le s e x is te n c o n c u r r e n te m e n te .
d a s , d e b e n c o m b in a r s e e n u n a s o la r e s p o n s a b ili
L o s e s c e n a rio s o s itu a c io n e s d e lo s c a s o s d e u s o s e u t i
d a d . P o r e j e m p lo , le e r t a r je t a d e c r é d it o y o b te n e r
l i z a n p a r a v a l i d a r e l d is e ñ o d e la in t e r f a z d e u s u a r io .
a u t o r iz a c ió n o c u r r e n e n c a d a s itu a c ió n . P o r c o n s i
E l m o d e la d o d e o b je t o s d e b e p r o b a r s e fr e n t e a la re d
g u ie n te , se p u e d e n c o m b in a r e n la r e s p o n s a b ilid a d
o b je t o - r e la c ió n , p a r a a s e g u ra rs e d e q u e to d o s lo s o b je
v a lid a r p e t ic ió n d e c r é d ito , q u e in c o r p o r a o b te n e r
to s d e d is e ñ o c o n t ie n e n lo s a t r ib u t o s y o p e r a c io n e s n e c e
e l n ú m e r o d e t a r je t a d e c r é d it o , y c o n s e g u ir la a u to
s a r ia s y p a r a im p le m e n t a r la s c o la b o r a c io n e s q u e s e
r iz a c ió n .
d e f in ie r o n p a r a c a d a t a r je t a C R C . A d e m á s , la e s p e c if i
6 . S e a p lic a n it e r a t iv a m e n t e lo s p a s o s 1 a 5 p a r a c a d a c a c i ó n d e t a l l a d a d e l a s o p e r a c i o n e s ( p o r e j e m p l o , lo s
c la s e , y d u ra n te c a d a e v o lu c ió n d e l m o d e lo de a l g o r i t m o s q u e i m p l e m e n t a n a la s o p e r a c i o n e s ) , s e r e v i
AOO. s a n u s a n d o té c n ic a s d e in s p e c c ió n c o n v e n c io n a le s .
23.3 ESTRATEGIAS D E PRUEBAS ORIENTADAS A OBIETQS
L a e s tr a te g ia c lá s ic a p a r a la p r u e b a d e s o ftw a r e d e o r d e ú l t im o , e l s is t e m a s e c o m p r u e b a c o m o u n t o d o p a r a a s e
n a d o r , c o m ie n z a c o n « p r o b a r lo p e q u e ñ o » y fu n c io n a g u r a r s e d e q u e s e d e s c u b r e n los e r r o r e s e n r e q u i s i t o s .
h a c ia f u e r a h a c ie n d o « p r o b a r lo g r a n d e » . S ig u ie n d o la
je r g a d e la p r u e b a d e s o ftw a r e ( C a p í t u lo 1 8 ), s e c o m ie n Q c ifo ;
z a c o n la s p r u e b a s d e u n i d a d , d e s p u é s s e p r o g r e s a h a c i a
j o p » probodor no es el que encuentra
la s p r u e b a s d e i n t e g r a c i ó n y s e c u l m i n a c o n la s p r u e b a s
» yoi cte tos errores...; el mejor
d e v a li d a c ió n d e l s is t e m a . E n a p lic a c io n e s c o n v e n c io
í g r a * repara lo mayorío de ellos,
n a l e s , la s p r u e b a s d e u n i d a d s e c e n t r a n e n la s u n i d a d e s
isa» »t «L
d e p r o g r a m a c o m p ila b le s m á s p e q u e ñ a s — e l s u b p r o -
g r a m a ( p o r e je m p lo , m ó d u lo , s u b r u tin a , p r o c e d im ie n t o ,
23.3.1. L as p r u e b a s d e u n id a d e n e l co n tex to
c o m p o n e n t e ) - . U n a v e z q u e c a d a u n a d e e s ta s u n id a
d e s h a n s id o p r o b a d a s in d iv id u a lm e n t e , s e in t e g r a n e n
d e la O O
u n a e s tr u c tu r a d e p r o g r a m a , m ie n tr a s q u e se e je c u ta n C u a n d o s e c o n s id e r a e l s o ftw a r e o r ie n t a d o a o b je t o s , e l
www.FreeLibros.org
u n a s e r ie d e p r u e b a s d e r e g r e s ió n p a r a d e s c u b r ir e r r o r e s , c o n c e p to d e u n id a d c a m b ia . L a e n c a p s u la c ió n c o n d u c e
d e b i d o s a la s i n t e r f a c e s e n t r e l o s m ó d u l o s y l o s e f e c t o s a la d e f i n ic i ó n d e c la s e s y o b je t o s . E s t o s ig n if ic a q u e
c o la te r a le s p r o d u c id o s p o r a ñ a d ir n u e v a s u n id a d e s . P o r c a d a c l a s e y c a d a i n s t a n c i a d e u n a c l a s e ( o b j e t o ) , e n v u e l
410
CAPÍTULO 23 PRUEBAS OR IE N TA DA S A OB JE TO S
ven atrib u to s (d ato s) y o p eracio n es (tam b ién co n o c i ro, las pru ebas basadas en hilos, integran el co n junto
dos co m o m éto d o s o serv icio s), que m an ipulan estos de clases requeridas, para responder u n a entrada o suce
datos. E n v ez de p ro b ar un m ód u lo in d iv id u al, la u n i so al sistem a. C ada hilo se integra y p rueba in dividual
dad m á s p e q u e ñ a c o m p ro b a b le es la c lase u o b je to m ente. Las pruebas de regresión se aplican para asegurar
encapsulado. Ya que una clase puede contener un n ú m e que n o o cu rran e fe c to s laterales. L a se g u n d a ap ro x i
ro de o peraciones d iferen tes, y u n a o peración p a rtic u m ac ió n de in te g ra c ió n , la p ru eb a basada en el u s o ,
lar d eb e e x istir c o m o p a rte de u n n ú m e ro de c lase s com ienza la construcción del sistem a p ro b a n d o aque
diferentes, el significado de la u n id ad de p rueba c a m llas clases (llam adas clases independientes), que u tili
bia drásticam ente. zan m uy pocas (o ninguna) clases servidoras. D espués
N o se puede p ro b ar m ás de u n a o peración a la vez de que las clases independientes se prueban, esta secuen
(la visión co nvencional de la unidad de prueba), pero s í c ia de pruebas p o r capas de clases dependientes co n ti
com o parte de u n a clase. P ara ilustrar esto, co nsidére n ú a h a sta que se co n stru y e el siste m a co m p le to . A
se una je ra rq u ía .d e clases, en la cual la o peración X se diferencia de la integración convencional, el uso de dri-
define p ara la superclase y se h ered a p o r algunas su b vers y stubs com o operaciones de reem plazo, debe ev i
clases. C a d a su b clase u tiliza la o p eració n X , p ero se tarse siem pre que sea posible.
aplica en el contexto de l o s atributos y o p eraciones p ri
vadas que han sido definidas p ara la subclase. Ya que el
contexto en el que la o p e ra c ió n X se u tiliz a v a ría de
m anera sutil, es n ecesario p ara p ro b ar la operación X c VE
en el contexto de estas subclases. E sto significa que p ro la estrategia de integración de pruebas 0 0 se centra
bar la operación X en vacío (la aproxim ación de la prue en grupos de clases que colaboran o se comunican
ba de unidades tradicionales) es inefectiva en el contexto de la misma manera.
orientado a objetos.
La pru eba de agrupamiento [M G R 94] es una fase
en las pruebas de integración de softw are O O . A q u í, un
ag ru p am ien to de clases co lab o rad o ras (determ in ad as
CLAVE p o r la revisión de los m odelos C R C y objeto-relación),
I a prueba de softwareOO es equivalente al módulo se p rueba diseñando los casos de prueba, que intentan
de pruebas unitariaspara el software convencional. rev elar errores en las colaboraciones.
No es recomendable comprobar operacionespor separado.
2 3 .3 .3 . Pruebas de validación en un contexto OO
La prueba de clases para el softw are OO es el eq u iv a
A l n iv e l de siste m a o d e v a lid a c ió n , lo s d e ta lle s de
lente de las pruebas de unidad p ara el softw are conven
cional* A diferencia de las pruebas de unidad del softw are c o n ex io n es de clases d esap arecen . A s í c o m o la v a li
d ació n co n v en cio n al, la v a lid a ció n del so ftw are O O
convencional que tienden a centrarse en el detalle algo-
se ce n tra en las accio n es v isib les al u su a rio y salidas
ntm ico de un m ódulo y de los datos que fluyen a través
reconocibles desde el sistem a. P a ra ay u d ar en la c o n s
de la interfaz del m ódulo, la prueba de clases para el soft
tru cción de las pruebas de validación, el p ro bador debe
ware OO se conduce m ediante las operaciones encapsu-
u tilizar los casos de u so (C ap ítu lo 20), que son parte
ladas por la clase y el com portam iento de la clase.
del m odelo de análisis. L os casos de uso p ro p o rc io n an
un escen ario , que tien e u n a g ran sim ilitu d de errores
23.3.2. Las pruebas de integración con l o s revelados en los req u isito s de in te ra cció n del
en el contexto OO usuario.
Ya que el so ftw a re o rie n ta d o a o b je to s n o tie n e una
estru ctu ra de co n tro l je rá rq u ic o , las e stra te g ia s c o n o m in a g a s a
v encionales de integración descendente (top-dow n) y Aparentemente, todos los métodos de pruebas
ascendente (bottom -up) tien en m uy p oco significado. de caja negmdiscutidos en eI Capítulo 17
En sum a, la integración de o p eraciones u n a p o r una en son aplicables a la 00 .
una clase (la aproxim ación de la integración increm en-
tal convencional), a m enudo es im posible p o r la «inte L os m étodos de prueba convencionales de caja negra
racció n d ire c ta e in d ire c ta de los c o m p o n e n te s que p ueden usarse para realizar pruebas de validación. A d e
co n fo rm an la clase» [BER93], m ás, los casos de p rueba deben derivarse del m o d elo de
E xisten dos estra te g ia s diferentes p ara las pruebas com portam iento del objeto y del diagram a de flu jo de
de integración de los sistem as O O [BIN 94a]. El p rim e sucesos, creado com o parte del A O O .
www.FreeLibros.org
2 Los m étodos de diseño para pruebas de caso, para las clases 0 0 ,
se discuten de las Secciones 23.4 a 23.6.
411
IN GENIERÍA DEL SOF TW AR E . UN E N F O Q U E P R A C T I C O
23.4 D ISE Ñ O DE C A S O S DE PRUEBA PARA SOFTWARE. OQ

Los m étodos de d iseñ o de caso s de p ru e b a p ara so ft
ware orientado a objetos continúan evolucionando. Sin
em bargo, u n a aproxim ación global al diseño de casos Referencia WebJ
de prueba O O ha sido d efinida p o r B em ard [BER93]:
Una colección excelente de publicaciones, fuentes
1. C ad a caso de pru eb a debe ser id entificado se p a ra y bibliografías de pruebas 0 0 puede encontrarse
dam en te, y ex p lícitam en te aso ciad o con la clase a en www.rbsc.com
probar.
2. D ebe declararse el p ropósito de la prueba. La herencia tam bién conduce a retos adicionalespara
3. D ebe desarrollarse una lista de pasos a seguir, com o el diseñador de casos de prueba. Ya se ha dicho que cada
co nsecuencia de la prueba, pero adem ás debe c o n nuevo contexto de uso requiere repetir la prueba, aún y
ten er [BER93]: cu a n d o se h ay a lo g ra d o la re u tiliz a c ió n . A d em ás, la
a. d e fin ic ió n de u n a lista de e sta d o s, esp ecífico s h eren cia m últiple' co m p lica m u ch o m ás las pruebas,
p ara el objeto a probar. increm entando el núm ero de contextos para los que se
req u iere la p ru e b a [B IN 94a], Si las subclases instan-
b. una lista de m ensajes y operaciones, que se ejer
ciadas de una superclase se utilizan dentro del m ism o
citarán com o co nsecuencia de las pruebas.
do m in io de problem a, es probable que el conjunto de
c. una lista de excepciones, que pueden ocurrir co n casos de prueba derivados de la superclase puedan usar
form e el objeto se com prueba. se para la prueba de las subclases. De cualquier m ane
d. u n a lista de co ndiciones externas (por ejem plo, ra, si la subclase se utiliza en un contexto enteram ente
los cam bios en el am biente externo al softw are, diferente, los casos prueba de la superclase serán esca
que debe existir p ara con d u cir apropiadam ente sam ente aplicables, y tendrá que diseñar un nuevo con
las pruebas). ju n to de pruebas.
e. in fo rm a c ió n ad icio n al, que a y u d a rá a la c o m
p ren sió n e im plem entación de la prueba. 23.4.2. A p licabilid ad d e los m étodos convencio
A diferencia del diseño de pruebas convencional, que n a le s d e d iseñ o d e c a so s d e prueba
se conduce m ediante una visión entrada-proceso-salida Los m étodos de «caja blanca» descrito sen el Capítulo 17
de softw are, o el detalle algorítm ico de los m ódulos indi pueden aplicarse a las operaciones definidas para una cla
viduales, la prueba o rientada a objetos se enfoca en las se. Técnicas com o el cam ino básico, pruebas de bucle o
secuencias de o p e racio n es de d iseñ o ap ro p iad as para técnicas de flujo de datos pueden ayudar a asegurar que
pro b ar los estados de una clase. se ha probado cada sentencia de la operación. De cual
quier m odo, la estructuraconcisa de m uchas operaciones
23.4.1. Im p licaciones d e los conceptos d e OO de clase provoca que algunos defiendan que el esfúerzo
a l d iseñ o d e c a so s d e prueba aplicado a la prueba de « cajablanca» debe ser redirigido
adecuadam ente a las pruebas, a un nivel de clase.
C om o y a se ha visto, la clase es el objetivo del diseño
Los m étodos de prueba de «cajan eg ra» son tan apro
de caso s p rueba. D eb id o a que los atrib u to s y o p e ra
piados para los sistem as 0 0 ,c o m o lo son para los siste
ciones se en cap su lan , las o peraciones de prueba fuera
m as desarrollados utilizando los m étodos convencionales
de la clase son generalm ente im productivas. A p esar de
de ingeniería de softw are. C om o se dijo al principio del
que la e n c a p su la c ió n es u n co n cep to de d iseñ o e se n
capítulo, los casos de uso pueden proporcionar datos Uti
cial p ara la O O , puede c re a r un o b stácu lo cu a n d o se
les en el diseño de pruebas de «caja neg ra» , y pruebas
hacen las pruebas. C om o m enciona B inder [B IN 94a],
basadas en estados [A M B95],
«la prueba requiere inform es del estado abstracto y co n
creto del objeto». L a encapsulación puede dificultar un
23.4.3. P ruebas b a sa d a s en errores4
poco la obtención de esta inform ación. A m en o s que se
proporcio n en o peraciones incorporadas p ara c o n o cer El objetivo de las pruebas basadas en errores dentro de
los v alores p ara los atributos de la clase, u n a im ag en un sistem a 0 0 , e s diseñar pruebas que tengan una alta
in sta n tá n e a del estad o del o b jeto puede ser d ifícil de probabilidad de revelar fallos. Ya que el producto o sis
adquirir. tem a debe adaptarse a los requerim ientos del chente, la
www.FreeLibros.org
3 C o n c e p to d e D O O q u e d e b e u s a rs e c o n e x tr e m a p re c a u c ió n . 4 L a s S e c c io n e s 2 3 . 4 . 3 a 23.4.6 h a n s id o a d a p t a d a s d e u n a r t íc u lo '
d e B r i a n M a r i c k , d i v u l g a d o e n e l g r u p o d e n o t i c i a s d e in t e r n e t
comp.testing. E s ta a d a p t a c ió n s e h a in c l u id o c o n e l p e r m is o d e l a u to r.
P a r a a d e n t r a r s e m á s e n la d is c u s ió n d e e s te t e m a , v é a s e |M A R 9 4 ] ,
412
CAPITULO 23 PRUE BAS O R I E N T A D A S A O B J E T O S
planificación preliminar requerida para llevar a cabo la perciben como «improbables», entonces esta aproxi
prueba basada en fallos comienza con el modelo de aná mación no es en realidad mejor que la técnica de prue
lisis. El probador busca fallos posibles (por ejemplo, los bas aleatorias. De cualquier manera, si los modelos de
aspectos de implementación del sistema que pueden análisis y diseño pueden proporcionar la visión de lo
manifestarse en defectos). Para determinar si existen que parece andar mal, entonces las pruebas basadas en
estos fallos, los casos de prueba se diseñan para probar errores pueden encontrar un número significativo de
el diseño o código. errores con esfuerzos relativamente pequeños.
Las pruebas de integración buscan fallos probables
en operaciones o mensajes de conexión. Tres tipos de
fallos se encuentran en este contexto: resultados ines
CLAVE perados, uso incorrectode operaciones/mensajes, invo
la estrategia consiste en hacer hipótesis de una serie caciones incorrectas. Para determinar fallos probables
de posiblesfallos, y luego conducirlas pruebas cuando las funciones (operaciones) se invocan, se debe
para comprobarlas hipótesis. examinar el comportamiento de la operación.
C o n s id é r e s e u n e je m p lo s im p le 5. L o s in g e n ie r o s d e áÜii ,
■ m ¿ Q u e tip o d e fa llo s
s o f t w a r e g e n e r a l m e n t e c o m e t e n e r r o r e s e n lo s l í m i t e s lü ! , „ ,
W s e e n c u e n tra n e n lla m a d a s
d e l p r o b le m a . P o r e je m p lo , c u a n d o s e p r u e b a u n a o p e
o o p e ra c io n e s y c o n e x io n e s
r a c i ó n SQRT q u e g e n e r a e r r o r e s p a r a n ú m e r o s n e g a t i d e m e n s a je s ?
v o s , s e s a b e p r o b a r los l í m i t e s : u n n ú m e r o n e g a t i v o
c e rc a n o a l c e r o y e l c e r o m is m o . E l « c e r o m is m o » c o m Las pruebas de integración se aplican tanto a atribu
p r u e b a s i e l p r o g r a m a d o r h a c o m e tid o u n e r r o r c o m o : tos como a operaciones. Los «comportamientos» de un
I f ( x > 0 ) calcular_la_raíz_cuadrada ( ); objeto se definen por los valores que se asignan a sus
E n lu g a r d e lo c o r r e c to
atributos. Las pruebas debenverificar los atributos para
determinar si se obtienen valores apropiados para los
( x >= 0 ) ca lcu la r-la -ra íz-c u a d ra d a ( );
If
distintos tipos de comportamientos de los objetos.
C o m o o t r o e je m p lo , c o n s id é r e s e l a e x p r e s ió n b o o le a n a E s importante hacer notar que las pruebas de inte
s ig u ie n te : gración intentanencontrar los errores en el objeto clien
If (a && !b I ! c ) te, no en el servidor. Dicho en términos comunes, el
enfoque de las pruebas de integración es determinar si
el error existe en el código de invocación, no en el códi
^C O N S E J O go invocado. La invocación a operaciones se utiliza como
una pista, una forma de encontrar los requerimientos de
Ya que la prueba basada en fallos se da en un nivel
la prueba que validen el código de invocación.
detallada, se reservo mejor para las operaciones
y clases que son críticas a sospechosas.
23.4.4. El impacto de la programación OO en las
L a s p r u e b a s d e m u lt ic o n d ic ió n y té c n ic a s r e la c io n a pruebas
d a s e x a m i n a n la s f a l t a s p o s i b l e s c o n t o d a s e g u r i d a d e n Hay distintas maneras en que la programación orienta
e s ta e x p r e s ió n , c o m o , p o r e je m p lo , da a objetos puede tener un impacto en las pruebas.
&& debería de ser II Dependiendo del enfoque de la P O O .
! se ignoró donde se necesitaba
. Algunos tipos de fallos se vuelven menos probables
(no vale la pena probar).
Y debería haber un paréntesis alrededor de !b lie
> Algunos tipos de fallos se vuelven más probables
P a ra c a d a e r r o r p r o b a b le , s e d is e ñ a n c a s o s d e p r u e (vale la pena probar).
b a , q u e fo r z a r á n a la c o n d ic ió n in c o r r e c t a a fa lla r . E n la . Aparecen algunos tipos nuevos de fallos.
e x p r e s ió n a n t e r io r , ( a = 0 , b = 0 , c = 0 ) f o r z a r á n a q u e la
e x p r e s i ó n s e evalúe f a l s a . S i e l & & h u b i e r a s i d o II, e l
c ó d ig o h u b ie r a d a d o e l r e s u lta d o in c o r r e c t o y e l c o n t r o l
h a b r ía s e g u id o la r a m a e r r ó n e a . Si usted deseo y espera que un programo funcione,
D e s d e lu e g o q u e la e f e c t iv id a d d e e s ta s té c n ic a s seré más probable que vea un programa
d e p e n d e d e c ó m o lo s p r o b a d o r e s p e r c ib e n e l « f a ll o p r o funcionando — extrañará fallos— .
b a b le » . S i lo s f a l l o s v e r d a d e r o s e n u n s is t e m a 0 0 s e
www.FreeLibros.org
5 El código presentado en ésta y en las siguientes secciones utiliza la
sintaxis de C++. Para m ayor inform ación, véase cualquier buen libro
de C++.
413
IN GE NI E RI A DEL SOF TW ARE . UN E N F O Q U E P R Á C T I C O
Cuando se invoca una operaciónes difícil decir exac bada, porque representa un nuevo diseño y nuevo
tamente qué código se ejecuta. Esto es, la operación código. Pero, ¿la d e r i v a d a : . h e r e d a d a ( ) debe Ser
debe pertenecer a una de muchas clases. Incluso, pue recomprobada?
de ser difícil determinar el tipo exacto o clase de un Si la d e r i v a d a : h e r e d a d a ( ) invoca a redefini-
parámetro. Cuando el código lo acceda puede obtener da y el comportamiento de redefinida cambia, d e r i
se un valor inesperado. La diferencia puede entenderse v a d a : - . h e r e d a d a ( ) podría manejar erróneamente
considerando la llamada a una función convencional: el nuevo comportamiento. De este modo, se necesi
tan nuevas pruebas aunque el diseño y el código no
hayan cambiado. Es importante hacer notar, sin
Para el softwareconvencional,el probador debe con embargo, que s o l o un subconjunto de todas las prue
siderar todos los comportamientos atribuidos afu n c y bas para d e r i v á d a -. - . h e r e d a d a ( ) deben rehacerse.
nada más. En un contexto 00,el probador debe consi Si parte del diseño y codificación para heredada no
derar los comportamientos de base::func( ) , de deriva- depende de redefinida (por ejemplo, no la llama ni
da::func( ) y así sucesivamente. Cada vez que fu n c se llama ningún código que indirectamente la llame),
invoca, el probador debe considerar la unión de todos ese código no necesita ser recomprobado en la clase
los comportamientos distintos. Esto es más fácil si se derivada.
siguen prácticas de diseño OO adecuadas, y se limitan B a se :r e d e ñ n id a ( ) y d e r iv a d a ::r e d e ñ n íd a ( )
las diferencias entre superclases y subclases (en el len son dos operaciones diferentes con especificaciones e
guaje de C++, estas se llaman clases base y clases deri implementaciones diferentes. Cada una debería tener
vadas). un conjunto de requisitos de prueba, derivadas de la
La aproximación a las pruebas para clases derivadas especificación e implementación. Aquellos requisitos
y base es esencialmente la misma. La diferencia es de prueban errores probables: fallos de integración, fallos
contabilidad. de condición, fallos de límitesy así sucesivamente.Pero
Probar las operaciones de clases es análogo a probar las operaciones es probable que sean similares por lo
código que toma un parámetro de la función y luego la que el conjunto de requisitos de pruebas se solapan.
invoca. La herencia es una manera conveniente de pro Cuanto mejor sea el diseño 0 0 , el solapamiento será
ducir operaciones polimórficas. En la llamada, lo que mayor. Es necesario desarrollar las nuevas pruebas, solo
importa no es la herencia, sino el polimorfismo. La para aquellos requisitos de d e r i v a d a : - .r e d e f i n i d a ( )
herenciahace que la búsqueda de los requisitos de prue que no fueron satisfechas por pruebas d e b a s e : - .r e d e
ba sea más directa. ñ n id a ( ) .
En virtud de la construcción y arquitectura de soft Para concluir, las pruebas de b a s e : -.re d e f i n i d a ( )
ware, ¿existen algunos tipos de fallos más probables se aplican a los objetos de la clase derivada. Las entra
para un sistema 00,y otros menos probables? la res das de las pruebas deben ser apropiadas para las clases
puesta es «sí». Por ejemplo, a causa de que las ope base y derivada, pero l o s resultados esperados pueden
raciones OO son generalmente más pequeñas, se diferir en la clase derivada.
tiende a gastar más tiempo en la integración ya que
existen más oportunidades de errores de integración.
A sí que los errores de integración se vuelven más pro
23.4.6. D is e ñ o d e p r u e b a s b a s a d a s
bables.
e n e l e s c e n a r io
Las pruebas basadas en los errores no localizan dos
23.4.5. C a s o s d e p ru eb a y je ra rq u ía d e c la s e s tipos de errores: (1) especificaciones incorrectas y (2)
Como se explicó previamente en este capítulo, la heren interacción entre subsistemas. Cuando ocurren errores
cia no obvia la necesidad de probar todas las clases asociados con especificaciones erróneas, el producto
derivadas. De hecho, puede complicar el proceso de no realiza lo que el cliente desea. Puede que haga cosas
prueba. incorrectas, o puede omitir funcionalidad importante.
Pero en cualquier circunstancia, la calidad (cumpli
miento de requisitos) se sacrifica. L o s errores asocia
CLA VE dos con la interacción de subsistemas ocurren cuando
el comportamiento de un subsistema crea circunstan
Aunque se haya comprobado bastante una clase base,
cias, (por ejemplo, sucesos, flujo de datos) que causan
tendrá que comprobarlas clases derivadas de ella.
que el otro subsistema falle.
Las pruebas basadas en el escenario se concentran
Considérese la situación siguiente. Una clase base en lo que el usuario hace, no en lo que el producto
contiene operaciones heredadas y redefinidas. Una hace. Esto significa capturar las tareas (por medio de
www.FreeLibros.org
clase derivada redefine operaciones redefinidas para los casos de u s o ) que el usuario tiene que hacer,
funcionar en un contexto local. Existe la pequeña duda después aplicarlas a ellas y a s u s variantes como
de que la d e r i v a d a : : r e d e ñ n i d a ( ) debe ser compro pruebas.
414
CAPÍTULO 23 PRUEB AS OR IE N TA DA S A O BJ E TO S
cionar «imprimir» en el menú y presionando el botón

«imprimir» en la caja de diálogo, se conseguirá que la
VE última página corregida se imprima de nuevo. Así que,
la prueba basada en el escenario descubrirá errores de acuerdo con el editor, el escenario correcto debería
que ocurren cuando cualquier actor interoctúa ser como el siguiente:
con el software 00. C a so d e u so : Im prim ir u n a nueva copia.
1. A brir el docum ento.
Los escenarios revelan errores de interacción. Pero
2. Seleccionar « im prim ir» en el m enú.
para llevar a cabo esto, los casos de prueba deben ser
más complejos y realistas que las pruebas basadas en 3. C om probar si se im prim e un rango de páginas; si es así, p re
sionar para « im prim ir» el docum ento entero.
los errores. Las pruebas basadas en el escenario tienden
avalidar subsistemas en una prueba sencilla (los usua 4. P resionar en el b otón de im presión.
rios no se limitan al uso de un subsistema a la vez). 5. C errar el docum ento.
A manera de ejemplo, considérese el diseño de prue Pero este escenario indica una especificación poten
bas basadas en el escenario, para un editor de texto. Uti cial de error. El editor no hace lo que el usuario razo
lícense l o s siguientes casos: nablemente espera. Los clientes generalmente pasarán
C aso d e uso: Prepara la versión final. por alto la opción de rango de páginas del paso 3 en el
A spectos d e fondo: N o es inusual im prim ir el borrador «final», ejemplo anterior. Se incomodarán cuando enciendan la
leerlo y descubrir algunos errores incóm odos que no eran tan impresora y encuentren una página cuando ellos que
obvios en la im agen de la pantalla. E ste caso de uso describe rían 100. Los clientes fastidiados significan errores de
la secuencia de pasos q ue ocurren cuando esto pasa.
especificación.
1. Im prim ir el d o cum ento entero. Un diseñadorde casos deprueba debe olvidar la depen
2. R ondar dentro del docum ento, cam biar algunas páginas. dencia en un diseño de pruebas, pero es probable que el
3. Al m o m en to en que c ada página se cam bia, se im prim e. problema aparezcadurante las pruebas. El probador ten
4. A lgunas veces se im prim e u n a serie de páginas.
dría entonces que lidiar con la respuesta probable, «¿Esa
es la forma como se supone que debe funcionar?».
Este escenario describe dos elementos: una prueba
y unas necesidades específicas del usuario. Las necesi
23.4.7. L as e s t r u c tu r a s d e p r u e b a s s u p e r f ic ia le s
dades del usuario son obvias: (1) un método para impri
mir una sola página y (2) un método para imprimir un y p ro fu n d a s
rango de páginas. Hasta donde va la prueba, existe la La estructura superficial se refiere a la estructura visi
necesidad de editar después de imprimir (así como lo ble al exterior de un programa OO. Esto es, la estruc
contrario). El probador espera descubrir que la función tura que es inmediatamente obvia al usuario final. En
de impresióncausa errores en la funciónde edición; esto vez de llevar a cabo funciones, los usuarios de muchos
es, que las dos funciones de software sean totalmente sistemas OO deben de proveerse de objetos para mani
independientes. pular de alguna forma. Pero sin importar la interfaz, las
C aso d e u so : Im presión de u n a nueva copia. pruebas aún se basan en las tareas de los usuarios. Cap
A s p e c to s d e fo n d o : S e p id e u n a co p ia re cien te. D ebe se r
turar estas tareas involucra comprensión, observación,
im presa:
y conversar con usuarios representativos (y tantos usua
rios no representativos como valga la pena considerar).
1. A brir el docum ento
Debe haber alguna diferencia en detalle con seguri
2. Im prim irlo. dad. Por ejemplo, en un sistema convencional con una
3 . C errar el docum ento. interfaz orientada a comandos, el usuario debe usar la
lista de comandos como una lista de control de pruebas.
Si no existen escenarios de prueba para ejercitar un
^ fo N s e jd jfy
comando, las pruebas probablemente pasaron por alto
Aunque lo pruebo basado en el escenario tiene su mérito, algunas tareas del usuario (o la interfazcontiene coman
encontrará uno recompensomayor revisondo los casos de dos inútiles). En una interfaz basada en objetos, el veri
uso cuando se desarrollan durante el AOO. ficador debe usar la lista de todos los objetos, como una
lista de control de pruebas.
Una vez más, la aproximaciónde las pruebas es rela
tivamente obvia. Excepto que el documento no apare
ció fuera de ningún lugar. Fue creado en una tarea
anterior. ¿La tarea anterior afecta a esta? CAVE
En los editores modernos, los documentos registran
www.FreeLibros.org
I o estructura de pruebas se da en dos niveles:
como fueron impresos por última vez. Por omisión, se (1) pruebas que validan la estructura visible
imprimende la misma forma la siguiente vez. Después por el usuario final, (2) pruebas diseñadas
del escenariop r e p a r a r ¡a versión fin a l, con solo selec para validar la estructura Interna del programa.
415
L a s m e jo re s p ru eb as se d an c u a n d o el d ise ñ a d o r L os m odelos de an álisis y diseñ o se utilizan com o

observa al sistem a de u n a m a n e ra n u e v a o p o co c o n una base para la v erificación de la estructura profunda.
vencional. P or ejem p lo , si el sistem a o p roducto tiene P or ejem plo, el diagram a objeto-relación o el diagram a
una in te rfa z b a sa d a en co m an d o s, p ru eb as m ás co m de colaboración de subsistem as describ e colaboracio
pletas se darán si el diseñador de casos supone que las nes entre objetos y subsistem as, que no pueden ser visi
operaciones son independientes de los objetos. H acer b les externam ente.
preguntas com o «¿Q uerrá el usuario usar esta operación El diseño de casos de p rueba entonces se pregunta:
— que se aplica sólo al objeto sc a n n e r — m ientras tra «¿Se ha capturado (com o una prueba) alguna tarea que
b aja con la im presora?». C u alq u iera q u e sea el estilo de p ruebe la colaboración anotada en el diagram a objeto
la interfaz, el diseño de casos de p ru eb a q u e ejercita la relación, o en el diagram a de colaboración de subsiste
estru ctu ra superficial debe u sar am bos objetos y opera m as? Si no es así, ¿por qué no?»
cio n es, co m o p istas q u e c o n d u zcan a las tareas d e sa El diseño de representaciones de jerarq u ías de clases
percibidas. p roporciona una visión de la estructura de herencia. La
L a estru ctu ra p ro fu n d a se refiere a l o s detalles té c estru ctu rajerárq u ica se u tiliza en la verificación basada
nicos de un p ro g ram a OO. E sto es, la estru ctu ra que se en errores. C onsidérese la situación en la cual una ope
com prende exam inando el diseño y/o el código. La veri ración llam ada llamar a ( ) tiene un solo argum ento, y
fica c ió n de la e stru c tu ra p ro fu n d a e stá d ise ñ a d a p ara ese argum ento es una referencia a la clase base. ¿Qué
ejercitar dependencias, com p o rtam ien to s y m ecanism os o c u rrirá cu an d o llam ar_a( ) pase a la clase derivada?
de com unicación, que han sido establecidos co m o p ar ¿Cuáles serán las diferencias en com portam iento que pue
te del diseño del objeto y del sistem a (C apítulo 22) de dan afectar a tal función? Las respuestas a estas pregun
softw are OO. tas pueden conducir al diseño de pruebas especializadas.
23.5 DE P tU E B A A P L I C A / l ES NIVEL DE 'CLASES

En el C apítulo 17 se m encionó que la p ru eb a de soft E sto representa la secuencia de v erificación mínima
w are com ien za «en lo pequeño» y lentam ente p rogresa para u n a cuenta. D e cualquier m odo, pueden existir una
hacia la pru eb a «a grande». L a prueba «en pequeño», am plia variedad de com binaciones de operacionesposi-
se enfoca en u n a sola clase y los m étodos encapsulados bles, dentro de esta secuencia:
p o r ella. L a verificació n y partició n al azar son m éto A b r i r - c o n fig u ra r - d e p o s i t a r - [ d e p o s i t a r i r e t i
dos que p u ed en usarse p ara ejercitar a u n a clase d u ran r a r I c o n s u l t a r s a ld o I re sum en I L i m i t e C r é d i t o ]n -
te la pru eb a O O [K IR94]. r e t i r a r - c e rra r
Pueden generarse una variedad de secuencias de ope
raciones diferentes al azar. P or ejem plo,
23.5.1. l a v e rific a c ió n a l a z a r p a r a c l a s e s O O
P ru e b a r 1 : a b ril - c o n fig u ra r■- d e p o s i t a r - c o n s u lta r
A m an era de ilustraciones sencillas de esto s m étodos, saldü - re su m en - r e t i r a r - c e r r a r .
considérese u n a aplicación b an caria en la cual u n a c la Prueba r : a b r i r - c o n iig u r a r - d e p o s i t a r - r e t i r a r -
se cu e n ta co n tien e las sig u ien tes o p eracio n es: abrir, d e p o s i t a r - c o n s u i t a r s a l d o - L ím iteC ré-
d ito - r e tir a r - cerrar.
configurar, depositar, retirar, consultur saldo, resumen,
Lim itecredito y cerrar [K IR94]. C ada una de estas ope E stas y otras pruebas de orden aleatorio se realizan
raciones debe aplicarse a cu e n ta , pero algunas lim ita para pro b ar diferentes registros de operaciones de ins
ciones (por ejem plo, la cuen ta debe ser abierta antes de tancias de clases.
que otras o p eraciones puedan aplicársele, y cerrada d es
pués de que todas las o peraciones h ay an sido c o m p le 23.5.2. P r u e b a d e p a r t i c i ó n a l n iv e l d e c la s e s
tad as) están im plícitas en la n atu raleza del probletna. La prueba departición reduce el núm ero de casos de prue
A ún co n estas lim itaciones, existen m uchas c o m b in a b a requeridos para validar laclase, de la m ism a forma que
ciones de operaciones. El registro de o p eraciones m ín i la partición equivalente (Capítulo 17) para software con
m a de una in sta n c ia de cu e n ta in clu y e las sig uientes vencional. Las entradas y salidas se clasifican, y los casos
operaciones : de p ru eb a se diseñan, para validar cada categoría. Pero
A b r ir - coniigurar - d e p o s ita r - r e t i r a r - c e rra r. ¿cóm o se derivan las categorías de partición?
ü ¿Qué opciones de pruebas

Ô N SE JO ^. * están disponibles a nivel
www.FreeLibros.org
El número de combinaciones posibles poro uno prueba de clases?
aleatoria puede crecer mucha. Una estiotegio similar
L a p a rtic ió n basada en estados clasifica las opera
puede usarse poro mejorar lo eficiencia de los pruebas. cio n es de clase b a sa d a en su h a b ilid a d de cam biar el
416
CAPÍTULO 23 PRUEB AS O R I E N T A D A S A O B J E T O S
estado de la clase. U na vez m ás, co nsiderando la clase L a partición basada en atributos clasifica las o p e ra
cuenta, o p eraciones de estad o in cluyen a depositar y ciones de clase basada en los atributos que ellas usan.
retirar, y co nsiderando que las o p eraciones de no -esta Para la clase cuenta, los atributos saldo y Lím iteCré-
do in cluyen a co n su lta r saldo, re su m e n y L ím iteC rédi- dito pueden usarse para definir particiones. L as o p e ra
to, las pruebas se diseñan de m anera que las operaciones ciones se dividen en tres particiones: (1) O p eraciones
que cam bian el estad o , y aquellas que n o lo cam bian, que utilizan LimiteCrédito, (2) operaciones que m o d i
se ejerciten separadam ente. Entonces: fican L ím itecrédito, y (3) operaciones que n o utilizan
o m odifican L ím itecrédito. Las secuencias d e p ru eb a
P ru e b a p x : a b r ir - configurar - d e p o s ita r - d e p o sita r se diseñan p o r cada partición.
- r e t i r a r - r e t i r a r - cerra r.
P r u e b a p , : a b r ir - configurar - d e p o s ita r - resumen -
L a partición basada en categorías clasifica las op era
L ím ite c ré d ito - r e t i r a r - ce rra r. ciones de la clase basadas en la función genérica que cada
una lleva a cabo. Por ejem plo, las operaciones en la cla
La pru eb a p¡ cam bia el estado, m ientras que la p ru e se cuenta pueden clasificarse en operaciones de iniciali-
ba p2 ejercita las o p eraciones que no cam bian el estado zación (abrir, configurar), operacionescom putacionales
(excepto p o r las necesarias de la secuencia m ínim a de (depositar, retirar), consultas (saldo, resumen, Límite-
prueba). Crédito) y operaciones de term inación (cerrar).
El diseño de casos de prueba se v uelve m ás com plica ve rifC u en ta - ve rifN IP - [ [ v e r ifP ó liz a
do cuando la integración del sistem a OO com ienza. Es reg R etira r] I reqD epositar I reqlnfoCuenta ]r‘
en esta etapa en que la v erificació n de colaboraciones
entre clases com ienza. P ara ilu strar «la g eneración de Tarjetalnsertada
Verifica rCuenta
C ontraseña
casos de pru eb a in te rc la se s» [KIR94], se exp an d e el D epósito
VerificarPIN
VerificarP olííica
ejemplo de la ap licació n b an caria in troducida en la S ec R etirar
ReqRetirar
ción 23.5, p ara inclu ir las clases y colaboraciones de la EstadoCuenta
Req Depósito ValidarPIN
ATM te rm in a r
Figura 23.2. L a d ire c c ió n de las flech as en la F ig u ra IníoCuenta ValidarC uenta
Interfaz \ a t m | Banco
indica que se invo can co m o co nsecuencia de colabora A brirC uenta
de. usuafio i VerificarÉstíido
ciones im plícitas a los m ensajes. D epósitolnicial
EstadoD epósito TarjetaA utorizo
TarjetaA utorizo
Así com o la v erificació n de clases in d iv id u ales, la Im prim irE stadoC uenta
Desautorizar
TipoC uenta
LeerlnfoTarjeta Balance
v erificació n de c o lab o racio n es de clases p u ede c o m Cerra rCuenta d
O btenerC antidadE fectivo ncuiai
pletarse ap lican d o m éto d o s de p artició n y al azar, así Depósito
como pruebas basadas en el escenario y pruebas de co m Cerrai
portam iento. V alid a ción
\ Cajero C u e n ta
de in fo rm a ció n
23.6.1.P ru eb a d e m ú ltip le s c la s e s
F IG U R A 23.2. Grafo de colaboraciones de clase
Kirani y Tsai [KIR94] sugieren la secuencia siguiente para una aplicación bancaria [KIR94],
de pasos, p ara g enerar casos de pru eb a aleatorios para
múltiples clases:
U n caso de p ru e b a a le a to rio p ara la c la se banco
1. Para cada clase cliente, utilice la lista de operacio
podría ser:
nes de clase, p ara g enerar una serie de secuencias de
Prueba r 3 = verifC uenta - verifN IP - reqD epositai
pruebas al azar. L as o p eraciones en viarán m ensajes
a las otras clases servidoras. C on la finalidad de c o n sid e ra r a los co lab o rad o res
2. Para cada m ensaje que se genere, determ ine la clase involucrados en esta prueba, los m ensajes asociados con
co laboradora y la o peración co rre sp o n d ien te en el cada una de las operaciones m encionadas en el caso de
objeto servidor. prueba r3 deben ser tom ados en cuenta. Banco debe co la
3. Para cada o peración en el objeto servidor (invocada b o rar con infoValidación para e je cu tar verifC uenta y
por m ensajes enviados p o r el objeto cliente), d eter verifNIP. Banco debe colaborar con cuenta para ejecu
m ine los m ensajes que transm ite. tar reqD epositar. De aquí que un nuevo caso de prueba,
que ejercite estas colaboraciones, es:
4. Para cada uno de los m ensajes, determ ine el siguiente
nivel de o peraciones que son invocadas, e incorpore Prueba r 4 = verifC uentaBanco [validCuepta, níoValidación
éstas a la secuencia de pruebas.
- reqD epositar - [DepositarCuúnlJ
www.FreeLibros.org
Para ilu strar [KIR94], considérese una secuencia de
o peraciones p a ra la c la se banco re la tiv a a una clase L a aproxim ación para la prueba de partición de m ú l
A ™ (F igura 23.2): tiples clases es sim ilar a la aproxim ación usada para la
417
prueba de partición de clases individuales. La m anera P ru e ba s 1: a b r i r - p r e p a r a r c u e n t a - d e p o s i t a r (in i

c i a l ) - r e t i r o ( f in a l ) - c e r r a r
como una sola clase se particiona se discutió en la Sec
ción 23.4.5. De cualquier modo, la secuencia de prue Nótese que esta secuencia es idéntica a la secuencia
bas se extiende para incluir aquellas operaciones que se m ínim a de pruebas, discutida en la Sección 23.5.1. Si
invocan por l o s m ensajes a clases colaboradoras. Una se agregan secuenciasde prueba adicionales a la secuen
aproxim ación alternativa basa las pruebas por partición cia mínima:
en las interfaces de una clase en particular. H aciendo
P rue ba s 2 : a b r i r - p r e p a r a r c u e n t a - d e p o s ita r (i n i
referencia a la Figura 23.2, la clase banco recibe m en c i a l ) - s a l d o - c r é d i t o - r e t i r o (final) -
sajes de las clases ATM y Cajero. Los métodos inclui cerrar.
dos en banco pueden probarse particionándolos en
P rue b a s¡ : p r e p a r a r c u e n t a - d e p o s i t a r ( i n i c i a l ) -
aquellos que sirven a ATM y aquellos que sirven a Caje r e t i r o - infoCuenta - r e t i r o ( f i n a l ) c e r r a r .
ro. La partición basada en estados (Sección 23.4.9), pue
de usarse para refinar aún más las particiones. Se pueden derivar aún más casos de prueba, para ase
gurarse de que todos los com portamientos para la cla
se han sido adecuadamente ejercitados. En situaciones
23.6.2. P ru eb a d e r iv a d a d e lo s m o d e lo s
en las que el com portam iento de la clases, resulte en
d e c o m p o r ta m ien to una colaboración con una o más clase se utilizan m úl
En el Capítulo 21 se discutióel uso del diagrama de tran tiples DTEs para registrar el flujo de comportamientos
sición de estados, como el modelo que representa el com del sistema.
portam iento dinámico de una clase. El DTE (Diagrama E1 m odelo de estado puede ser recorrido « p r i m e r o a
de transición de estados) para una clase puede usarse lo a n c h o » [M GR94], En este co n tex to ,p rim ero a lo
para ayudar a derivar una secuencia de pruebas, que ejer ancho im plica que un caso de prueba valida una sola
citarán el comportamiento dinámico de la clase (y aque transición y después, cuando se va a verificar una nue
llas clases que colaboran con ella). La Figura 23.3 va transición, se utilizan sólo las transiciones previa
[KIR94] ilustra una DTE para la clase cuenta explica m ente verificadas.
da con anterioridad6. Con referencia a la Figura, las tran Considérese el objeto tarjeta-de-créd ito de la Sec
siciones iniciales se mueven por los estados cuenta vacía ción 23.2.2. El estado inicial de ta rjeta -d e-créd ito
y configura cuenta. Un retiro final y cierre causan que es in d efin id o (es decir, no se ha proporcionado u n
la clase cuenta haga transiciones a los estados nohace- núm ero de tarjeta de crédito). Una vez leída la tarjeta
trabajo de cuenta y cuenta muerta, respectivamente. de crédito durante una venta, el objeto asum e u n esta
do definido; esto significa que los atributos número
tarjeta y fecha expiración, se definen ju n to con id e n -
itai
C uenta P rep arar tificadores específicos del banco. La tarjeta de crédi
vacía
í a h cuenta
A brir Preparar to se envía, cuando se envía la au to rizació n , y es
cuenta aprobada cuando la autorización se recibe. La transi
D epósito (inicial)
ción de ta r je ta -d e -c r é d ito de un estado a otro puede
.D e p ó s ito probarse generando casos de prueba, que hagan que la
Trabajo transición ocurra. Un enfoque « p r i m e r o a lo a n c h o »
con la en este tipo de pruebas, puede no validar el envío antes
Balance cuenta
R etirar
C rédito __
infoC uenta
O de que se ejercite indefinida y definida. Si lo hiciera,
haría uso de transiciones que no han sido verificadas
Retirar todo (fin al) con anterioridad, y violaría el criterio «prim ero a lo
ancho».
E lim inar 1 C uenta
C uenta J no operativa
Cerrar
F IG U R A 2 3 .3 . D iagram a de tran sició n de estados r

para la clase cuenta [KIR94]. Referencia W e b l v
Las pruebas a diseñarse deben alcanzar una cober Uno extensa colección de ((consejos sobre
pruebas 0 0 » (incluyendo muchos referencias
tura de todos los estados [KIR94], Eso significa que las
útiles) puede encontrarse en:
secuencias de operaciones deben causar que la clase
w ww .kinetka.com /ootips/
cuenta haga transiciones por todos los estados:
www.FreeLibros.org
6 La simbologia UML se utiliza para el DTE que se ilustra en la Figura
23.3. Difiere ligeram ente de la simbología usada para los DTEs en la
parte tres de este libro.
418
CAPITULO 23 PRUEBAS ORIENTADAS A OBJETOS
El objetivo global de la v erificació n orien tada a objetos citen. El esta d o de la c la se re p re se n ta d a p o r lo s v a lo

- e n c o n t r a r el m áx im o nú m ero de errores con un m ín i re s d e su s a trib u to s se e x a m in a , p a ra d e te rm in a r si
m o de esfuerzo— , es idéntico al objetivo de prueba del p ersisten erro res.
softw are convencional. P ero la estrateg ia y tácticas para L a prueba de integración puede llevarse a cabo utili
la pru eb a O O difieren de m odo significativo. La visión zando una estrategia b asada en hilos o b asada en el uso.
de v e rific a ció n se am p lía, p a ra in c lu ir la re v isió n de L a estrategia b asada en hilos integra el conjunto de cla
am bos m od elo s de diseño y de análisis. ses, que colaboran para responder a una entrada o suce
E n resum en, el enfoque de p ru eb a se aleja del co m so. Las pruebas basadas en el uso construyen el sistem a
ponente procedim ental (el m ódulo) hacia la clase. Ya que en capas, com enzando con aquellas clases que no usan
los m odelos de análisis y diseño OO y el código fuente clases servidoras. Los m étodos de diseño de integración
resultante se acoplan sem ánticam ente, la prueba (a m ane de casos de p rueba pueden usar pruebas al azar y p o r p ar
ra de revisiones técnicas form ales) com ienza en estas acti tición. E n sum a, las pruebas basadas en el escenario y las
vidades de ingeniería. P or esta razón, la rev isión de los pruebas derivadasde los m odelos de com portam iento pue
métodos CR C, objeto-relación y objeto-com portam iento, den usarse para verificar una clase y sus colaboraciones.
pueden verse com o una prim era etapa de prueba. U n a secuencia de pruebas reg istra el flujo de operacio
U na v ez que la P O O h a sid o c o n c lu id a , las p ru e nes, a través de las colaboraciones de clases.
bas de u n id a d se a p lic a n a c a d a c la se . E l d ise ñ o de L a prueba de validación de sistem as O O está o rien
p ruebas p a ra u n a c la se u tiliz a u n a v a rie d a d d e m é to tad a a c a ja n e g ra y p u ede co m p letarse ap lican d o los
d o s : p ru eb as b asad as e n e rro re s, la s p ru e b a s al azar m ism os m étodos de p rueba de caja de n eg ra discutidos
y las p ru eb as p o r p artició n . C a d a u n o de esto s m é to p ara el softw are convencional. S in em bargo, las p ru e
dos e je rc ita la s o p e racio n es e n c a p su la d a s p o r la c la bas basadas en el escen ario dom inan la validación de
se. L a s s e c u e n c ia s d e p ru e b a s se d is e ñ a n p a ra sistem as 0 0 ,h a c ie n d o que el caso de uso sea el co n
asegurarse de que las o p e racio n es re le v a n te s se e je r ductor prim ario para las pruebas de validación.
JL £ £ £ E £ £ £ IA ¿ .
[AMB95] Ambler, S., «Using Use Cases», Software D eve [KIR94] Kirani, S., y W.T. Tsai, «Specification and Verifica-
lopment, Julio de 1995,pp. 53-61. tion of Object-Oriented Programs», Technical Report TR
[BER93] Berard, E.V., Essays on Ohject-Oriented Software 94-96, Computer Science Department, University of Min
Engineering, vol. 1,Addison-Wesley, 1993. nesota. Diciembre de 1994.
[BIN94a] Binder, R.V., «Testing Object-Oriented Systems:
[LIN94] Lindland, O.I., et al., «Understanding Quality in Con
A Status Report», American Programmer, vol. 7, n.° 4,
ceptual Modeling», IEEE Software, vol. 11, n.° 4, Julio de
Abril de 1994, pp. 23-28.
1994,pp. 42-49.
[BIN94b] Binder,R.V., «Object-Oriented Software Testing»,
C4CM,vol. 37, n.° 9, Septiembre de 1994, p. 29. [MAR94] Marick, B., The Craft o f Software Testing, Prenti-
[CHA93] DeChampeaux, D., D. Leay P. Faure, Object-Orien ce Hall. 1994.
ted System Development, Addison-Wesley, 1993.
[FIC92] Fichman, R., y C. Kemerer, «Object-Oriented and [MGR94] McGregor, J.D., y T.D. Korson, «Integrated Object-
conceptual Design Methodologíes», Computer, vol. 25, Oriented Testing and Development Processes», CACM,
n.° 10, Octubre de 1992, pp. 22-39. vol. 37, n." 9, Septiembre de 1994,pp. 59-77.
2 3 .1 . Describa con sus propias palabras por qué la clase es 2 3 .4 . Derive un conjunto de tarjetas índice CRC para Hogar-
la más pequeña unidad razonable para las pruebas dentro de Seguroy ejecute los pasos señalados en la Sección 23.2.2 para
un sistema OO. determinar si existen inconsistencias.
2 3 .2 . ¿Por qué debemos probar de nuevo las subclases ins- 2 3 .5 . ¿Cuál es la diferencia entre las estrategiasb a s a d a s en hilos
tanciadas de una clase existente si ésta y a ha sido probada por y aquellas estrategiasbasadas en uso para las pruebas de inte
completo? ¿Podemos usar los casos de prueba diseñados para gración? ¿Cómo cabe la pmeba de agrupación en ellas?
www.FreeLibros.org
dicha clase? 2 3 . 6 . Aplique la prueba aleatoria y la de partición a tres cla
2 3 .3 . ¿Por qué debe comenzar la «prueba» con las activida ses definidas en el diseño del sistema HogarSeguro produci
des de AOO y DOO? do por usted en el Problema 22.12.
419
Produzca casos de prueba que indiquen las secuencias de ope 23.10. Obtenga pruebas usando los métodos señalados en los
raciones que se invocarán. Problemas 23.6 y 23.7 para el sistema de e-mail considerado
23.7. Aplique la prueba de múltiples clases y las pruebas deri en el Problema 22.15.
vadas del modelo de comportamiento al diseño de HogarSe-
guro. 23.11. Obtenga pruebas usando los métodos señalados en los
Problemas 23.6 y 23.7 para el sistema ATC considerado en el
23.8. Obtenga pruebas usando los métodos señalados en los Problema 22.16.
Problemas 23.6 y 23.7 para el sistema S S R B descrito en el
Problema 22.13. 23.12. Obtenga cuatro pruebas adicionales usando cada
23.9. Obtenga pruebas usando los métodos señalados en los uno de los métodos señalados en los Problemas 23.6 y 23.7
Problemas 23.6 y 23.7 para el juego de vídeo considerado en para la aplicación bancaria presentada en las Secciones 23.5
el Problema 22.14. y 23.6.
La literatura para la prueba OO es relativamente escasa, aun Jorgenesen (Software Testing: A Cruftsman ’sApprouch,
que se ha expandido algo en años recientes. Binder (Testing CRC Press, 1995) y M cGregor y Sykes fObject-Oriented
Object-Oriented Systems: Models, Patterns, and Tools, Addi- Software Development, Van Nostrand Reinhold, 1992) pre
son-Wesley, 2000) ha escrito el tratamiento más extenso del senta capítulos dedicados al tema. Beizer (Black-BoxTes-
tema publicado hasta la fecha. Siegel y Muller (ObjectOrien- ting, Wiley, 1995) analiza una variedad de m étodos de
ted Software Testing:A HierarchicalApproach, Wiley, 1996) diseño de casos prueba los cuales son apropiados en un con
propusieron una estrategia práctica de prueba para sistemas texto O O .
OO. Marick (The Craft. o f Software Testing: Subsystem Tes Binder (Testing Object-Oriented Systems, Addison-Wes
ting Including Ohject-Based and Object-Oriented Testing, ley, 1996) y Marick [M A R 9 4 ] presenta tratamientos detalla
Prentice Hall, 1995) cubre la prueba tanto para software con dos de prueba O O . En resumen, muchas de las fuentes
vencional como para O O . anotadas para e l Capítulo 17 son en general aplicables a la
Antologías de publicaciones sobre pmeba OO han sido edi prueba O O .
tadas por Kung et al. (TestingObject-Oriented Software, IEEE Una amplia variedad de fuentes de información de prue
Computer Society, 1998)y Braude (OhjectOrientedAnalysis, ba orientada a objetos y temas relacionados se encuentran dis
Design and Testing: Selected Readings, IEEE Computer ponibles en intemet. Una lista reciente a sitios (páginas) web
Society, 1998). Estos tutoriales de IEEE proporcionan una inte que son relevantes a la prueba OO puede encontrarse en
resante perspectiva histórica en el desarrollo de prueba O O . h t t p ://w w w .p r e s s m a n 5 .c o m
C A P ÍT U L O
^ m M É T R IC A S T É C N IC A S PARA S IS T E M A S
A ¿X O R IE N T A D O S A O B JE T O S
N secciones anteriores de este libro, se mencionó que las métricas y mediciones son com
E ponentes clave para cualquier disciplina de ingeniería —y la ingeniería de software orien

tada a objetos no es una excepción—. Desgraciadamente, el uso de métricas para sistemas
OO ha progresado mucho más despacio que'el uso de otros métodos OO. Ed Berard [BER95]
mencionó la ironía de las mediciones, cuando declaraba que:
La gente involucrada en el software parece tener una relación amor-odio con las métricas. Bor una par
te, menosprecian y desconfían de cualquier cosa que parezca o suene a medición. Son rápidos, bastante rápi
dos para señalar las «imperfecciones», en los argumentos de cualquiera que hable acerca de las mediciones
a los productos de software, procesos de software, y (especialmente) personas involucradas en software.
P o r otra parte, esta misma gente parece no tener problemas al identificar q u é lenguaje de programación es
el mejor, las estupideces que los administradores hacen para «arruinar» proyectos, y la metodología de tra
bajo en qué situaciones.
La «relación amor-odio» que Berard declara es real. Más aun, como los sistemas OO se
encuentran cada vez más implantados, es esencial que los ingenieros en software posean medi
ciones cuantitativas, para la evaluación de calidad de diseños, a niveles arquitectónicos y de
componentes.
Estas mediciones permiten al ingeniero evaluar el software al inicio del proceso, haciendo
cambios que reducirán la complejidad y mejorarán la viabilidad, a largo plazo, del producto
final.
VISTAZO RÁPIDO
¿Qué es? Construir software OO ha sido la arquitectura 0 0 ,la s clases y sub riores. Los resultados del análisis son
una actividad de ingeniería, que confía sistemas que conforman la arquitectu interpretados para obtener una visión
más en el juicio, folklore y referencias ra, las operaciones y atributos que inherente a la calidad del software, y
cualitativas, que en la evaluación cuan constituyen una clase. El comprobador los resultados de la interpretación con
titativa. Las métricas OO se han intro necesita lasreferencias cuantitativas, ducen a la modificación de resultados
ducido para ayudar a un ingeniero del que le ayudarán en la selección de de trabajo deducidos del análisis, dise
software a usar el análisis cuantitativo, casos de prueba y sus objetivos. Las ño, codificación o prueba.
para evaluar la calidad en el diseño métricas técnicas proporcionan una ¿Cuál e s e l p rod u cto o b ten id o ? Las
antes de que un sistema se construya. base desde la cual el análisis, el dise métricas de software que se calculan
El enfoque de métricas OO está en la ño y la verificación pueden conducirse mediantelosdatos recolectados délos
clase —la piedra fundamental de la de manera más objetiva, y ser evalua modelos de análisis y diseño, código
arquitectura 0 0 —, dos más cuantitativamente. fuente y casos de prueba.
¿Quién lo h a c e ? Les ingenieros del soft ¿C uáles son lo s p asos? El primer paso ¿Cómo p u e d o e s ta r se g u r o d e q u e
ware se ayudan de las métricas para en el proceso de medición es deducir lo h e h ech o correctam ente? Debe
construir software de mayor calidad. lasmediciones de software y métricas establecer los objetivos de las medi
¿P or q u é e s im p ortan te? Como se que pudieran ser apropiadas para la ciones antes de que la recolección de
expuso en el vistazo rápido del Capí representación del software en consi datos comience, definiendo cada métri
tulo 19, la evaluación cualitativa de deración. Después, se recolectan los ca OO de manera concreta. Definir
software debe complementarse con el datos requeridos para aplicar las métri solamente algunas métricas y después
análisis cuantitativo. Un ingeniero del cas formuladas. Una vez computados, utilizarlas, para obtener una vista inhe
software necesita un criterio objetivo se analizan basándose en orientacio rente a la calidad de un producto de
para ayudarse a conducir el diseño de nes preestablecidas y en datos ante ingeniería de software.
24.1 EL PR O PÓ SIT O DE LAS MÉTRICAS. O RIENTADAS A, QBIET.QS.

Los objetivos p rim arios p ara las m étricas o rientadas a C ada uno de estos objetivos es im portante, pero para
objetos n o son d iferen tes de aq u ello s de las m étricas el in g en iero de softw are la calidad del p ro d u cto debe
desarrolladas para el softw are convencional: ser lo m ás im portante. Pero ¿cóm o m ed ir la calidad de
un sistem a O O ? ¿Qué característicasdel m odelo de dise
« p ara en tender m ejo r la calidad del producto. ño pueden y deben evaluarse para determ inar si el sis
« p ara evalu ar la efectividad del proceso. tem a será fácil de im plem entar, fácil de verificar, simple
de m o d ifica r y, lo m ás im p o rtan te, aceptable para los
. p ara m ejorar la calidad del trabajo llevado a cabo al u suarios finales? E stas preguntas serán contestadas en
nivel del proyecto. la parte restante del capítulo.
Las m étricas p ara cualq u ier p roducto de ingeniería son Ya que el softw are convencional enfatiza la fúnción
reguladas p o r las c a ra c terístic a s ú nicas del p roducto. co m o un m ecan ism o de lo calizació n , las m étricas de
Por ejem plo, sería inútil o sin sentido con tar las m illas softw are se han enfo cad o a la estructura interna o ju n
por galón de consum o p ara u n autom óvil eléctrico. La ciones de com plejidad (por ejem plo, longitud del m ódu
m étrica es firm e p ara los autom óviles convencionales lo, cohesión o com plejidad ciclom ática), o a la m anera
(es decir, im pulsados p o r sistem as de com bustión in ter com o las funciones se conectan entre sí (acoplam iento
na a gasolina) pero no se aplica cuando el m odo de p ro de m ódulos).
pulsión cam bia radicalm ente. E l softw are o rien tad o a
objetos e s fu n d am en talm en te d ife re n te del so ftw are
desarrollado con el uso de m étodos convencionales. Por
tm sm
Métricostécnicas pam software convencional
esta razón, las m étricas para sistem as O O d eben ser afi se describen en el Capitulo 19.
nadas a las c a ra c terístic a s que distinguen al softw are

OO del softw are convencional. P uesto que la clase es la u n idad básica de un siste
B erard [B E R 95] d e fin e c in c o c a ra c te rís tic a s que m a 0 0 , 1 a localización se basa en los objetos. P o r esta
reg u la n las m é tric a s e s p e c ia liz a d a s: L o c a liz a ció n , razón, las m étricas deben aplicarse a la clase (objeto),
encapsulación, ocultam iento de inform ación, h erencia com o a una entidad com pleta. E n sum a, la relación entre
y técnicas de abstracción de objetos. C ada una de estas operaciones (funciones) y clases no es necesariam ente
características se discute b revem ente en las secciones uno a uno. Por lo tanto, las m étricas que reflej an la m ane
siguientes'. ra en la que las clases colaboran deben ser capaces de
acom odarse a relaciones uno a m uchos y m uchos a uno.
24.2.2. E n cap su lación

Referencia Web
B erard [B E R 95] d efin e la e n c a p su la c ió n com o el
Una extensión de búsqueda para métricas 0 0 la puedes obtener
en: www.objenv.com /cetus / oo_metrics.html «em paquetam iento ( o ligam ento) de una colección de
e le m e n to s. E jem p lo s d e b ajo niv el de encapsulación
[para softw are convencional] incluyen registros y m atri
24.2.1. L ocalización ces, [ y ] su b p ro g ram as (por ejem plo, procedim ientos,
La localización es u n a característica del softw are que funciones, subrutinas y p árrafo s), son m ecanism os de
indica la m anera en que la inform ación se concentra en nivel m edio para la encapsulación.»
un program a. P or ejem plo, los m étodos conv en ciona
les para la d esco m p o sició n fu n cio n al organizan la infor
m ación en to m o a las fu n cio n es que son típ icam en te
tg a a a B B a
los conceptos ba stes de diseño se describen
im p lem en tad as co m o m ó d u lo s p ro ced im en tales. L os en d Capitulo 13. Su aplicación al software 0 0

se discute en el Capitulo 20.
m étodos m anejados p o r datos lo calizan la in form ación
en to m o a estructuras de datos específicas. E n el c o n
texto O O , la inform ación se concentra p o r la en capsu P ara los sistem as 0 0 , 1 a encapsulación engloba las
lación de datos y procesos dentro de los lím ites de una responsabilidades de una clase, incluyendo sus atribu
clase u objeto. tos ( y otras clases para objetos agregados) y operacio
www.FreeLibros.org
1 Este estudio ha sido adaptado de [BER95]
422
CAPÍTULO 24 MÉ TR IC A S T É C N I C A S P ARA SI ST EM AS O R IE N TA DO S A OBJE TO S
n e s , y lo s e s ta d o s d e la c la s e , d e f in id o s p o r v a lo r e s d e u n a je r a r q u í a d e c la s e s . E n g e n e r a l, e l s o f t w a r e c o n
a t r ib u t o s e s p e c íf ic o s . v e n c io n a l n o c u m p le e s ta c a r a c te r ís tic a .
L a e n c a p s u l a c i ó n i n f l u y e e n la s m é t r i c a s , c a m b i a n Y a q u e la h e r e n c ia e s u n a c a r a c te r ís t ic a v it a l e n
d o e l e n f o q u e d e la s m e d i c i o n e s d e u n m ó d u l o s i m p l e , m u c h o s s is t e m a s O O , m u c h o s m é t o d o s O O s e c e n t r a n
a u n p a q u e te d e d a to s ( a t r ib u to s ) y m ó d u lo s d e p r o c e e n e lla . L o s e je m p lo s ( d is c u t id o s m á s a d e la n te e n e s te
s o ( o p e r a c io n e s ) . c a p í t u lo ) in c l u y e n m ú lt ip le s h ijo s ( in s ta n c ia s in m e d ia
E n s u m a , la e n c a p s u la c ió n e le v a la m e d ic ió n a u n ta s d e u n a c la s e ) , m ú lt ip le s p a d r e s ( g e n e r a liz a c io n e s
n iv e l d e a b s tr a c c ió n m á s a lto . in m e d ia t a s ) , y je r a r q u í a s d e c la s e a u n n i v e l d e a n id a -
P o r e je m p lo , m á s a d e la n te e n e s te c a p í t u lo s e i n t r o m i e n t o ( p r o f u n d id a d d e u n a c la s e e n la j e r a r q u í a d e
d u c i r á n la s m é t r i c a s a s o c ia d a s c o n e l n ú m e r o d e o p e r a - h e r e n c ia ) .
c i o n e s p o r c la s e . C o n t r a s t a e s t e n i v e l d e a b s t r a c c i ó n c o n
la s m é t r i c a s q u e s e c e n t r a n e n c o n t a r c o n d i c i o n e s b o o -
24.2.5. A b s t r a c c i ó n
le a n a s ( c o m p l e j i d a d c i c l o m á t i c a ) o e n c o n t a r l í n e a s d e
L a a b s tr a c c ió n e s u n m e c a n is m o q u e p e r m it e a l d is e
c ó d ig o .
ñ a d o r c o n c e n t r a r s e e n lo s d e t a lle s e s e n c ia le s d e u n c o m
p o n e n te d e p r o g r a m a ( y a s e a n d a to s o p ro c e s o s ),
24.2.3. O c u l t a c i ó n d e i n f o r m a c ió n p r e s ta n d o p o c a a t e n c ió n a lo s d e t a lle s d e b a jo n iv e l.
L a o c u lt a c ió n d e in f o r m a c ió n s u p r im e ( u o c u lt a ) lo s C o m o B e r a r d d e c la r a : « la a b s tr a c c ió n e s u n c o n c e p to
d e t a lle s o p e r a c io n a le s d e u n c o m p o n e n t e d e p r o g r a m a . r e la t iv o . A m e d id a q u e s e m u e v e a n iv e le s m á s a lto s d e
S o lo s e p r o p o r c io n a la in f o r m a c ió n n e c e s a r ia p a r a a c c e a b s tr a c c ió n , s e ig n o r a n m á s y m á s d e ta lle s , e s d e c ir , s e
d e r a l c o m p o n e n te a a q u e llo s o t r o s c o m p o n e n te s q u e tie n e u n a v is ió n m á s g e n e ra l d e u n c o n c e p to o e le m e n
d e s e e n a c c e d e r. to . A m e d id a q u e s e m u e v e a n iv e le s d e a b s tr a c c ió n m á s
U n s is t e m a O O b ie n d is e ñ a d o d e b e im p le m e n t a r b a jo s , s e in t r o d u c e n m á s d e ta lle s , e s d e c ir , s e tie n e u n a
o c u l t a c i ó n d e i n f o r m a c i ó n . P o r e s t a r a z ó n , la s m é t r i c a s v is ió n m á s e s p e c íf ic a d e u n c o n c e p to o e le m e n to .»
q u e p r o p o r c io n a n u n a in d ic a c ió n d e l g r a d o d e o c u lt a Y a q u e u n a c la s e e s u n a a b s t r a c c ió n , q u e p u e d e v is u a
c ió n lo g r a d o s u m in is t r a n u n 'in d ic io d e la c a lid a d d e l liz a r s e a d if e r e n t e s n iv e le s d e d e t a lle d e d if e r e n t e s d e
d is e ñ o O O . m a n e r a s ( p o r e je m p lo , c o m o u n a lis t a d e o p e r a c io n e s ,
c o m o u n a s e c u e n c ia d e e s ta d o s , c o m o u n a s e r ie d e c o la
b o r a c i o n e s ) , la s m é t r i c a s O O r e p r e s e n t a n a b s t r a c c i o n e s
24.2.4. H e r e n c i a e n t é r m in o s d e m e d ic io n e s d e u n a c la s e ( p o r e je m p lo ,
L a h e r e n c i a e s u n m e c a n i s m o q u e h a b i l i t a la s r e s p o n n ú m e r o d e in s t a n c ia s p o r c la s e p o r a p lic a c ió n , n ú m e r o
s a b ilid a d e s d e u n o b je t o , p a r a p r o p a g a r s e a o t r o s o b je o c la s e s p a r a m e t r i z a d a s p o r a p l i c a c i ó n , y p r o p o r c i ó n d e
to s . L a h e r e n c ia o c u r r e a tr a v é s d e to d o s lo s n iv e le s d e c la s e s p a r a m e t r i z a d a s c o n c la s e s n o p a r a m e t r i z a d a s ) .
24.3 M ÉTRICAS PAftA EL M ODELO DE D IS E fiQ O O -
M u c h o a c e r c a d e l d is e ñ o o r ie n t a d o a o b je t o s e s s u b d a d . L a p o b l a c i ó n s e m i d e h a c i e n d o u n r e c u e n t o d e la s
je t iv o — u n d is e ñ a d o r e x p e r im e n ta d o « s a b e » c o m o e n t i d a d e s 0 0 , c o m o la s c la s e s u o p e r a c i o n e s . L a s m e d i
c a r a c t e r iz a r a u n s is t e m a 0 0 , p a r a q u e im p le m e n t e d a s d e v o lu m e n s o n id é n t ic a s a la s d e p o b la c ió n , p e r o
e f e c t i v a m e n t e l o s r e q u e r i m i e n t o s d e l c lie n t e — . P e r o , s e r e a liz a n d in á m ic a m e n te - e n u n in s ta n te d e tie m p o
c u a n d o u n m o d e lo d e d is e ñ o 0 0 c re c e e n ta m a ñ o y d a d o - . L a lo n g itu d e s la m e d id a d e u n a c a d e n a d e e le
c o m p le jid a d , u n a v is i ó n m á s o b je t iv a d e la s c a r a c t e m e n to s d e d is e ñ o in te r c o n e c t a d o s ( p o r e je m p lo , la p r o
r ís tic a s d e l d is e ñ o p u e d e b e n e f ic ia r a l d is e ñ a d o r e x p e f u n d id a d d e u n á r b o l d e h e r e n c ia e s u n a m e d id a d e
r im e n t a d o ( q u e a d q u ie r e v is t a a d ic io n a l) , y a l n o v a t o lo n g it u d ) . L a s m é tr ic a s d e f u n c io n a lid a d p r o p o r c io n a n
( q u e o b tie n e in d ic a d o r e s d e c a lid a d q u e d e o t r a m a n e u n a in d ic a c ió n in d ir e c ta d e l v a lo r e n tr e g a d o a l c lie n te
r a n o e s ta r ía n d is p o n ib le s ) . p o r u n a a p lic a c ió n O O .
C o m p le jid a d . A s í c o m o e l ta m a ñ o , e x is te n d if e r e n
¿Qué características pueden
§
te s e n fo q u e s d e la c o m p le jid a d d e l s o ftw a r e [ Z U S 9 7 ] ,
medirse cuando se evalúa W h i t m i r e la d e fin e e n té r m in o s d e c a r a c te r ís tic a s e s tr u c -
un diseño OO? t u r a le s , e x a m in a n d o c ó m o s e in t e r r e la c io n a n la s c la s e s
C o m o p a r t e d e u n t r a t a m i e n t o d e t a l l a d o d e la s m é t r i d e u n d is e ñ o 0 0 c o n o tra s .
c a s d e s o f t w a r e p a r a s is t e m a s 0 0 , W h i t m i r e [ W H I 9 7 ] A c o p la m ie n t o . L a s c o n e x io n e s f ís ic a s e n tr e lo s e le
d e s c r ib e n u e v e c a r a c te r ís tic a s d is t in t a s y m e d ib le s d e m e n to s d e l d is e ñ o 0 0 ( p o r e je m p lo , e l n ú m e r o d e c o la
www.FreeLibros.org
u n d is e ñ o 0 0 : b o r a c io n e s e n t r e c la s e s o e l n ú m e r o d e m e n s a je s
T a m a ñ o . E l ta m a ñ o s e d e f in e e n té r m in o s d e c u a t r o in t e r c a m b ia d o s e n tr e o b je t o s ) , r e p r e s e n ta n e l a c o p la
e n fo q u e s : p o b la c ió n , v o lu m e n , lo n g it u d y f u n c io n a li m ie n t o d e n t r o d e u n s is t e m a O O .
423
INGENIERÍA DEL SO FTW AR E. UN E N F O Q U E P R Á C T I C O
Suficiencia. Whitmire define la suficiencia como «el

grado en que una abstracciónposee los rasgos mínimos
necesarios, o el grado en que una componente de diseño Referencia
posee características en su abstracción, desde el punto Uninforme técnico de la NASA, queaborda métricasde
de vista de la aplicación actual». Dicho de otro modo, calidadpara sistemas 00, puede descargarsedel
sehace la pregunta: «¿qué propiedades tiene que poseer satc.gsfc.nasa.gov/support/index.html
esta abstracción (clase) para que sea Util?» [WHI97].
En esencia, un componente de diseño (por ejemplo, una
O rig in alid ad . Una característica similar a la simpli
clase) es suficiente si refleja completamente todas las
propiedades del objeto dominio de la aplicación que se cidad, la originalidad (aplicadatanto a operaciones como
modela; esto es l o que significa que la abstracción a clases) es el grado en que una operación es atómica;
(clase), posea los rasgos imprescindibles. esto significa que la operación no puede ser construida
fuera de una secuencia de otras operaciones contenidas
dentro de una clase. Una clase que exhibe un alto grado
de originalidadencapsula solamente las operacionespri-
p e nuchas de las decisiones para las cueles mitivas.
le tS É Ío que contor coa el folklore y mitos pueden S im ilitud. Esta métrica indica el grado en que dos o
«serse atora datos cuantitativos. más clases son similares en términos de estructura, com
portamiento, función o propósito.
V o latilid a d . Como se mencionó anteriormente en
Integridad. La Única diferenciaentre integridady sufi este libro, pueden ocurrir cambios en el diseño cuando
ciencia es «el conjunto de características, contra las que se modifiquen los requisitos, o cuando ocurran modifi
se comparan la abstracción o componente de diseño caciones en otras partes de la aplicación, resultando una
[ W H I 9 7 ] » . La suficiencia compara la abstracción, desde adaptación obligatoria del componente de diseño en
el punto de vista de la aplicación en cuestión. La integri cuestión. La volatilidad de un componente de diseño
dad considera muchos puntos de vista, preguntándose: OO mide la probabilidad de que un cambio ocurra.
«¿Qué propiedades se requieren para representar com La descripción de métricas de Whitmire para estas
pletamente el objeto dominio del problema?» Ya que los características de diseño se encuentra fuera del ámbito
criterios de integridad consideran diferentes puntos de de este libro.'Los lectores interesados deben consultar
vista, hay una implicación indirecta, acerca del grado en [WHI97], para más detalles.
que la abstraccióno componentede diseñopuede serreu- En realidad, las métricas técnicas para sistemas
tilizada. OO pueden aplicarse no sólo al modelo de diseño,
C ohesión.A sí como sucorrespondienteen el software sino también al modelo de análisis. En las secciones
convencional, un componente OO debe diseñarse de siguientes, se exploran las métricas que proporcio
manera que posea todas las operacionestrabajando con nan un indicador de calidad, al nivel de las clases OO
juntamente para alcanzarun propósitoÚnicoy bien defi y al nivel de operación. En suma, las métricas apli
nido. La cohesión deuna clase se determina examinando cables al manejo de proyectos y pruebas también se
el grado en que «el conjunto de propiedades que posee comentarán.
sea parte del diseño o dominio del problema» [WHI97]. La clase es la unidad fundamental de un sistema O O .
Por esta razón, las medidas y métricas para una clase Así mismo, la clase «padre» es de las que heredan las
individual, lajerarquía de clases y las colaboraciones subclases (algunas veces llamadas hijas), sus atributos
de clases poseen un valor incalculable, para el ingenie y operaciones. La clase, normalmente, colabora con
ro del software que ha de evaluar la calidad del diseño. otras clases. Cada una de estas características pueden
En capítulos anteriores se estudió que la clase encap- usarse como base de la medición2,
sula operaciones (procesamiento) y atributos (datos).
2 N ótese que la validez de algunas m étricas, discutidas en este capí

tulo, actualm ente se d eb ate en la literatura técnica. Aquellos que
abanderan la teoría de m edición requieren de un grado de form a
www.FreeLibros.org
lismo que algunas de las m étricas OO no proporcionan. De cualquier
m anera, es razonable declarar que todas las m étricas proporcionan
una visión útil para el ingeniero de software.
424
CAPÍTULO 24 MÉTRIC AS T É C N I C A S PARA SI STE MAS OR IE N TA DO S A O B J E T O S
24.4.1. La s e r ie d e m é trica s C K ejem plo, le falta un m étodo correspondiente de sí), entonces

pasará su m ensaje a sus clases padres.
Uno de los conjuntos de métricas OO más ampliamen
E n el otro extrem o, el recuento podría incluir a todos aque
te referenciados, ha sido el propuesto por Chidamber y llos m étodos definidos en la clase en cuestión, ju n to con los
Kemcrer [CHI94]. Normalmente conocidas como la m étodos heredados. E ste enfoque enfatiza la im portancia del
se rie d e m é tr ic a s C K , los autores han propuesto seis espacio de estados, en lugar del increm ento de la clase, para la
métricas basadas en clases para sistemas OO3. com prensión de la clase.
M étodos ponderados por clase (M PC). Asumen Entre estos extrem os, existe cierto núm ero de posibilidades
que n métodos de complejidad c¡, c2, ... cn se definen diferentes. P or ejem plo, una podría restringir el recuento a la
para la clase C. La métrica de complejidad específica clase en cuestión y lo s m iem bros heredados directam ente de
sus padres. E ste enfoque se basa en el a rgum ento de que la
que se eligió (por ejemplo, complejidad ciclomática) especialización de clases padres es lo m ás directam ente rele
debenormalizarse de manera que la complejidad nomi vante en el com portam iento de las clases descendientes.
nal para un método toma un valor de 1 0 .
A sí com o la m ayoría de las convenciones de recuento
M P C = le en m étricas de softw are,cualquiera de los enfoques re su
para cada i = 1 hasta n. m id o s c o n a n te rio rid a d es a c e p ta b le, sie m p re que el
El número de métodos y su complejidad son indicado enfo q u e de recuento sea aplicado co n sisten te m en te al
res razonables de la cantidad de esfuerzo requerido para m om ento de reco lectar m étricas.
implementar y verificar una clase. En suma, cuanto Á rbol de profundidad de h erencia (A P H ). E sta
mayor sea el número de métodos, más complejo es el m étrica se define com o «la m áxim a longitud del nodo
árbol de herencia (todas las subclases heredan métodos a la raíz del árbol» [C H I94], C on referencia a la Figura
de sus padres). Finalmente, a medida que crece el 24.1, el v alo r del A P H para la je ra rq u ía de clases m o s
número de métodos para una clase dada, más probable trad a es de 4.
es que se vuelvan más y más específicos de la aplica A m edida que el A P H crece, es posible que clases de
ción, así que se limita el potencial de reutilización. Por m ás bajos niveles heredarán m uchos m étodos. E sto co n
todas estas razones, el MPC debe mantenerse tan bajo lleva dificultades potenciales, cu an d o se intenta p red e
como sea razonable. cir el co m p o rtam ien to de u n a clase. U n a je ra rq u ía de
clases profunda (el A P H es largo) tam bién con d u ce a
una com plejidad de diseño m ayor. P or el lado positivo,
lo s valores A PH grandes im plican un gran núm ero de
m étodos que se reutilizarán.
El número de métodos y su complejidad está N úm ero de descendientes (ND D). L as su b cla ses
directamente relacionado con el esfuerzo requerido
in m ed iatam en te su b o rd in ad as a una clase e n la je r a r
para comprobar una clase.
qu ía de clases se d en o m in an sus descen d ien tes. C on
referencia a la F igura 24.1, la clase C 2 tiene tres d e s
Aunque podría parecer relativamente claro llevar la cendientes — subclases C 2 1, C 22 y C23— .
cuenta del número de métodos en una clase, el pro
A m edida que el núm ero de descendientes crece, la
blema es más complejo de lo que parece, Churcher
reutilización se increm enta, pero adem ás es cierto que
y Shepperd [CHU95] discuten este aspecto cuando
cu an d o el N D D crece, la abstracción rep resentada por
escriben:
la clase predecesora puede diluirse. E sto significa que
Para contar m étodos, se debe contestar la pregunta funda
existe una posibilidad de que algunos descendientes no
mental: «¿pertenece un m étodo únicam ente a la clase que lo
define, o pertenece a cada clase que la h ereda directa o indi- sean m iem bros, realm ente apropiados, de l a clase pre-
rectam ente?».L as preguntas com o esta pueden p arecer trivia decesora. A m ed id a que el N D D crece, la cantidad de
les, ya que el sistem a de ejecución las resolverá finalm ente.D e pruebas (requeridas para ejercitar cada descendiente en
cualquier m anera, las im plicaciones para la s m étricas deben su contexto operativo) se increm entará tam bién.
ser significativas.
U na posibilidad es restringir el contador de la clase actual
ignorando los m iem bros heredados. L a m otivación para esto
^ C O N S E id f^
podría ser que los m iem bros h eredados ya han sido contados I a herencia es una habilidad extremadamentepoderasa,
en las clases donde fueron definidos, así que el increm ento de
que puede meterlo en problemas, si no se usa ron
la clase es la m ejor m edida de su funcionalidad, lo que refleja
cuidada. Utilice el APH y otros métricos relacionadas
su razón para existir. P ara entender lo que la clase lleva a cabo,
para darse una lectura de la complejidad de la jerarquía
la fuente de inform ación m ás im portante son sus propias ope
raciones. Si una clase n o puede responder a un m ensaje (por de clases.
www.FreeLibros.org
3 Chidamber, Darcy y K em erer usan el térm ino m étodos en vez de
operaciones. Su utilización del térm ino es reflejada en esta sección.
425
I N GEN IE RÍ A DEL S O F T W A R E . UN EN F O Q U E P R A C T I C O
s e c u e n c ia d e c o m p r o b a c i ó n ( C a p í t u lo 2 3 ) s e in c r e m e n t a
ta m b ié n . A s í m is m o , se d ic e q u e , a s í c o m o la R P C
a u m e n t a , l a c o m p l e j i d a d d e l d i s e ñ o g l o b a l d e l a c la s e
s e in c r e m e n ta .
Carencia de cohesión en los métodos (CCM ). C a d a
m é t o d o d e n t r o d e u n a c la s e , C , a c c e d e a u n o o m á s a t r i
b u t o s ( t a m b ié n lla m a d o s v a r ia b le s d e in s t a n c ia ) C C M
e s e l n ú m e r o d e m é t o d o s q u e a c c e d e a u n o o m á s d e lo s
m is m o s a t r ib u t o s 4. S i n o e x is te n m é to d o s q u e a c c e d a n
a l o s m i s m o s a t r i b u t o s , e n t o n c e s C C M = O.
P a ra ilu s tr a r e l c a s o e n e l q u e C C M e s d ife r e n te d e 0 ,
c o n s id é r e s e u n a c la s e c o n 6 m é t o d o s . C u a t r o d e l o s m é t o
d o s t ie n e n u n o o m á s a t r ib u to s e n c o m ú n (e s d e c ir , a c c e
d e n a a t r ib u to s c o m u n e s ) . D e e s ta m a n e r a , C C M = 4 .
S i C C M e s a l t o , lo s m é t o d o s d e b e n a c o p la r s e a o t r o ,
p o r m e d io d e lo s a t r ib u to s . E s to in c r e m e n t a la c o m p le
j i d a d d e l d i s e ñ o d e c la s e s . E n g e n e r a l , l o s v a l o r e s a l t o s
p a r a C C M im p li c a n q u e la c la s e d e b e d is e ñ a r s e m e jo r
d e s c o m p o n i e n d o e n d o s o m á s c la s e s d i s t i n t a s . A u n q u e
e x is ta n c a s o s e n lo s q u e u n v a lo r a lt o p a r a C C M e s ju s -
t if ic a b le , e s d e s e a b le m a n t e n e r la c o h e s ió n a lta , e s d e c ir ,
m a n t e n e r C C M b a jo .
F IG U R A 2 4 .1 . U na jerarq uía de clases.
A coplam iento entre clases objeto (A C O ). E l

tusponderaciones orientadas o objetos,
son «aporteintegral de la tecnología de objetos
m o d e lo C R C ( C a p í t u lo 2 1 ) d e b e u t iliz a r s e p a r a d e te r
y de ta t o n o práctica de b ingeniería de software
m i n a r e l v a l o r d e A C O . E n e s e n c ia , A C O e s e l n ú m e r o
(Mi i Hembraon-Setlen
d e c o la b o r a c io n e s lis ta d a s p a r a u n a c la s e , e n la t a r je t a
í n d ic e C R C .
A m e d id a q u e A C O s e in c r e m e n ta , e s m á s p r o b a b le 24.4.2. M é trica s p r o p u e sta s por Lorenz y Kidd
q u e e l g r a d o d e r e u t iliz a c ió n d e u n a c la s e d e c r e z c a . V a l o E n s u l i b r o s o b r e m é t r i c a s OO, L o r e n z y K i d d [ L O R 9 4 ]
r e s a lt o s d e A C O a d e m á s c o m p lic a n la s m o d i f ic a c i o n e s s e p a r a n la s m é t r i c a s b a s a d a s e n c la s e s e n c u a t r o a m p l i a s
y la s p r u e b a s , q u e s e p r o d u c e n c u a n d o s e r e a l i z a n m o d i c a te g o r ía s : t a m a ñ o , h e r e n c ia , v a lo r e s in t e r n o s y v a lo r e s
f ic a c io n e s . E n g e n e r a l, lo s v a lo r e s d e A C O p a r a c a d a e x t e r n o s . L a s m é t r i c a s o r i e n t a d a s a l t a m a ñ o p a r a la s c l a
c la s e d e b e n m a n t e n e r s e t a n b a jo s c o m o s e a r a z o n a b le . s e s O O s e c e n tr a n e n e l r e c u e n t o d e a t r ib u to s y o p e r a c io
E s to e s c o n s is te n te c o n la r e g la g e n e r a l p a r a r e d u c ir e l n e s p a r a c a d a c la s e i n d i v i d u a l , y l o s v a l o r e s p r o m e d i o p a r a
a c o p la m ie n to , p a r a e l s o ftw a r e c o n v e n c io n a l. e l s i s t e m a O O c o m o u n t o d o . L a s m é t r i c a s b a s a d a s e n la
h e r e n c i a s e c e n t r a n e n l a f o r m a e n q u e la s o p e r a c i o n e s s e
^ C Q N S E J o f^ i r e u t i l i z a n e n l a j e r a r q u í a d e c la s e s . L a s m é t r i c a s p a r a v a l o
r e s in t e r n o s d e c la s e e x a m i n a n l a c o h e s i ó n ( S e c c i ó n 2 4 . 4 . 1 )
los conceptosáe acoplamiento y coheslónse oplicon tonto
y l o s a s p e c t o s o r i e n t a d o s a l c ó d i g o ; la s m é t r i c a s o r i e n t a
al software convenaonalcomo al 00. Mantenga
d a s a v a lo r e s e x te m o s , e x a m in a n e l a c o p la m ie n to y la r e u
el acoplamiento de clases bajo y la cohesioné operación alto.
t iliz a c ió n . A c o n t in u a c ió n , u n a m u e s tr a d e m é tr ic a s
p r o p u e s ta s p o r L o r e n z y K i d d 5:
R espuesta para una clase (RPC). E l c o n j u n t o d e
r e s p u e s t a d e u n a c la s e e s « u n a s e r ie d e m é t o d o s q u e Tamano de clase (TC). E l t a m a ñ o g e n e r a l d e u n a c la s e
p u e d e n p o te n c ia lm e n t e s e r e je c u ta d o s , e n r e s p u e s ta a p u e d e m e d i r s e d e t e r m i n a n d o la s s i g u i e n t e s m e d i d a s :
u n m e n s a je r e c ib id o p o r u n o b je t o , e n la c la s e » [ C H I 9 4 ] , « e l t o t a l d e o p e r a c io n e s ( o p e r a c io n e s t a n t o h e r e d a d a s
R P C s e d e f in e c o m o e l n ú m e ro d e m é to d o s e n e l c o n c o m o p r iv a d a s d e l a in s t a n c ia ) , q u e s e e n c a p s u la n
ju n t o d e re s p u e s ta . d e n t r o d e l a c la s e .
A m e d id a q u e la R P C a u m e n ta , e l e s fu e r z o r e q u e r id o . e l n ú m e r o d e a t r ib u to s ( a t r ib u to s ta n to h e re d a d o s c o m o
p a r a la c o m p r o b a c ió n t a m b ié n s e in c r e m e n ta , y a q u e la p r i v a d o s d e l a i n s t a n c i a ) , e n c a p s u l a d o s p o r l a c la s e .
www.FreeLibros.org
4 l a definición formal e s un poco m ás compleja. Véase [CHI94] para 5 Para un tratam iento m ás com pleto, véase [LOR94]
m ás detalle.
426
CAPÍTULO 24 M É TR IC A S T É C N I C A S P ARA SI ST EM AS O R IE N TA DO S A O B J E T O S
donde n ivel corresponde al nivel en la je ra rq u ía de c la

ses en que reside la clase, y M t0[a¡ es el nú m ero total de
Durante la revisión del modelo cíe AOO, las tarjetas CPC m étodos de la clase. C uanto m ás elev ad o sea el v alo r
proporcionan una indicación razonable de las valores de IE, m ás probable será que lajerarq u ía de clases tenga
esperados paro JC. SI encuentra uno clase con demasiada clases que n o se aju sten a la ab stracció n de la su p e r
responsobilidodduranteAOO, considere elporticionarlo. clase.
La m étrica M PC p ropuesta p o r C hidam ber y K em e 24.4.3. La colección d e m étricas MDOO

rer (Sección 24.4.1) es tam b ién una m étrica ponderada H arriso n , C o u n seil y N ith i [H A R 98] p ro p u siero n un
del tam añ o de clase. conjunto de m étricas para el d iseño orien tad o a objetos
C om o se in d icó co n an terio rid ad , v a lo res grandes (M D O O ), que proporcionan indicadores c u an titativ o s
para TC ind ican que la clase debe te n e r b a sta n te re s para el d iseño de c a ra cterístic as O O . A con tin u ació n ,
ponsabilidad. E sto red u cirá la reu tilizació n de la clase una m uestra de m étricas M D O O :
y com plicará la im plem entacióny las pruebas. E n g en e
ral, op eracionesy atributos h eredados o públicos deben Q c ita :
ser ponderados con m ayor im portancia, cuando se d eter Twore 00 pora evaluar su calidad,
mina el tam año de clase. [LO R 94] O peraciones y a tri - -‘.s fctfe ffip o rio n tí ■'to vez, conforme
butos privados, p erm iten la especialización y son m ás a ' ; - 0 continúa incrementóndose
propios del diseño.
Tam bién se p u e d e n c a lc u la r los p ro m ed io s para el M Bv t íh tí ai.
núm ero de a trib u to s y o p e ra c io n e s de clase. C u an to
menor sea el v alo r p rom edio p ara el tam año, será m ás
posible que las clases dentro del sistem a p u edan reuti- Factor de herencia de métodos (FH M ). E l grado
lizarse. en que la arquitectura de clases de un sistem a O O hace
u so de la h e ren c ia tan to p ara m é to d o s (o p e ra c io n es)
Número de operaciones redefinidas para una sub
com o atributos, se define com o:
clase (ÑOR). E xisten casos en que u n a subclase reem
plaza una o peración hered ad a de su superclase p o r una F H M = Z Mj f C j ) / X M J C¡)
versión especializada p ara su pro p io uso. A esto se le donde el sum atorio v a desde i= l hasta TC. TC se d efi
llama redejinición. L os v alores grandes p ara el Ñ O R , ne com o el núm ero total de clases en la arquitectura, C¡
generalm ente ind ican un p roblem a de diseño. Tal com o es una clase den tro de la arquitectura, y
indican L orenz y Kidd:
D ado que una subclase debe ser la especialización de sus
superclases, deben, sobre todo, extender los servicios (opera donde
ciones) de las superclases. E sto debe resultar en nuevos nom M J C¡) = al núm ero de m étodos que pueden ser in v o
bres de m étodos únicos.
cados en relación con C¡
Si el Ñ O R es grande, el d iseñador ha violado la abs MJC¡) = al núm ero de m étodos declarados en la clase
tracción rep resen tad a p o r la superclase. E sto provoca
una débil je ra rq u ía de c la se s y un so ftw a re O O , que
M ¿(C ■) = al núm ero de m étodos heredados (y no rede-
puede ser difícil de p ro b ar y m odificar.
finidos) en C-
Número de operaciones añadidas por una su b
El v alo r de FH M (el factor de herencia de atributo,
clase (NOA). L as subclases se especializan añadiendo
F H A , se defin e de m anera an áloga), p ro p o rcio n a una
operaciones y a trib u to s p riv a d o s . A m e d id a q u e el
referencia sobre im pacto de la herencia en softw are OO.
valor N O A se in c re m e n ta , la su b c la se se a leja d e la
abstracción re p re se n ta d a p o r la superclase. E n g e n e Factor de acoplam iento (FA). C on anterioridad, en
ral, a m e d id a que la p ro fu n d id a d de la je r a r q u ía de este capítulo se indicó que el acoplam iento es un in d i
clases in cre m e n ta (A P H se v u e lv e g ra n d e ), el v a lo r cador de las conexiones entre los elem entos del diseño
para N O A a n iv e le s m ás b ajo s e n la je ra rq u ía d eb ería O O . L a colección de m étricas M D O O define el facto r
disminuir. de acoplam iento de la siguiente m anera:
índice de especialización (IES). El índice de e sp e FA = [ME¡ e s-c lie n te (C¡, C .)] / (TC 2 - T C )
1 J 1 J
cialización prop o rcio n a una indicación aproxim ada del donde los sum atorios van desde i = 1 hasta TC y desde
grado de especialización, p ara cada una de las subcla j = 1 hasta TC. L a función
ses en un sistem a OO. La especialización se puede alcan
www.FreeLibros.org
zar añadiendo o elim inando operaciones, pero tam bién E s cliente = 1, si existe una relación entre la clase
redefiniendo. cliente, C c y la clase servidora C v y C c ^ Cs.
IE = [Ñ O R x n ivel ] / M tota¡ E s - d ie n te = 0, en cualquier otro caso.
427
I N GEN IE RÍ A DEL S O F T W A R E . UN EN F O Q U E P R A C T I C O
A p e s a r d e que m u c h o s fa c to re s a fe c ta n la c o m p le ji FP =Z jM JC j) / X¡ [M n(C¡) x D C (C¡)]

dad, c o m p re n s ió n y m a n te n im ie n to d e l s o ftw a re , es ra z o d o n d e lo s s u m a to rio s v a n desde i = 1 h a sta T C y
n a b le c o n c lu ir q u e c o n fo rm e e l v a lo r d e l FA c re c e , la
c o m p le jid a d d e l s o ftw a re O O ta m b ié n c rec e, y la c o m M J C ,) = M n(C¡) + M JC j)
p re n s ió n , e l m a n te n im ie n to y e l p o te n c ia l d e r e u tiliz a
c ió n , p u e d e n re s e n tirs e c o m o re s u lta d o . Y
F a c t o r d e p o lim o r f is m o ( F P ) .H a r r is o n , C o u n s e lly
MJCj) =a l n ú m e ro d e m é to d o s n u e vo s.
N it h i [ H A R 9 8 ] d e fin e n F P c o m o « e l n ú m e ro de m é to M J C¡) =a l n ú m e ro d e m é to d o s re d e fin id o s .
dos q u e re d e fin e n m é to d o s h e re d a d o s , d iv id id a p o r el DC(C¡) =a l n ú m e ro d e d e s c en d ie n te s (e l n ú m e ro de
m á x im o n ú m e ro d e p o s ib le s s itu a c io n e s p o lim ó rfic a s clases d e s c en d ie n te s d e u n a c lase b a se ).
d is tin ta s ...; de esta m a n e ra , e l F P es u n a m e d id a in d i H a r r is o n , C o u n s e ll y N it h i [ H A R 9 8 ] p re s e n ta n un
re c ta d e la c a n tid a d r e la tiv a de lig a d u ra d in á m ic a e n u n a n á lis is d e ta lla d o d e F H M , F A y F P e n c o n ju n to con
sis te m a » . L a c o le c c ió n de m é tric a s M D O O d e fin e e l F P o tras m é tric a s , y e x a m in a n su v a lid e z d e u so, en la e v a
de la s ig u ie n te m a n e ra : lu a c ió n de la c a lid a d d e l d iseñ o .
Y a q u e la c la s e es la u n id a d d o m in a n te e n lo s s is te e n v ia d o s p o r u n a sola o p e ra c ió n se in c re m e n ta n , es má$
m a s 0 0 , se h a n p ro p u e s to m e n o s m é tric a s p a ra o p e p ro b a b le que las re sp o n sa b ilid a d e s n o h a y a n sid o correc
ra c io n e s q u e las re la c io n a d a s c o n las clases. C h u rc h e r ta m e n te a sig n ad as d e n tro d e la clase.
y S h e p p e r d [C F 1 U 9 5 ] d is c u te n lo a n te r io r c u a n d o
iiü m jiü iim i-iii
d e c la ra n q u e :
Las métricas pueden aplicarse a nivel de componentes,
Resultados de estudios recientes indican que los métodos
pero también pueden aplicarse a operaciones. Véase el
tienden a ser pequeños, tanto en términos de número de sen
tencias como en complejidad lógica [WIL93], sugiriendo que
Capítulo 19 para más detalles.
la estructura de conectividddde un sistema debe ser mas impor
tante que el contenido de los módulos individuales.
D e c u a lq u ie r m o d o , e x is te n a lg u n as id e a s que p u e C o m p l e j i d a d d e o p e r a c ió n ( C O ) . L a c o m p le jid a d
d e n lle g a r a a p re c ia rs e , e x a m in a n d o las c a ra c te rís tic a s de u n a o p e ra c ió n p u e d e ser c a lc u la d a usand o c u alq u iera
p ro m e d io p a ra lo s m é to d o s (o p e ra c io n e s ). A c o n tin u a de las m é tric a s d e c o m p le jid a d (C a p ítu lo 1 9 ) p ro p u es
c ió n se re s u m e n tres s im p le s m é tric a s , p ro p u es ta s p o r tas p a ra e l s o ftw a re c o n v e n c io n a l [ Z U S 9 0 ] , Y a que las
L o r e n z y K id d [ L O R 9 4 ] : o p e ra c io n e s d e b e n lim ita rs e a u n a re s p o n s a b ilid a d espe
c ífic a , e l d is e ñ a d o r d e b e ría e s fo rz a rs e p o r m a n te n e r la
T a m a ñ o m e d io d e o p e r a c ió n (T O medj0). A u n q u e
C O ta n b a ja c o m o sea p o s ib le .
las lín e a s de c ó d ig o p o d ría n ser usadas c o m o u n in d i
c ad o r p a ra e l ta m a ñ o d e o p e ra c ió n , la m e d id a L D C ad o N ú m e r o d e p a r á m e t r o s d e m e d ia p o r o p e ra c ió n
le c e de to d o s los p ro b le m a s d is c u tid o s e n e l C a p ítu lo 4. ( N P med ia )' T a n la rg o c o m o sea e l n ú m e ro d e p arám e
P o r esta ra z ó n , e l n ú m e ro d e m e n s a je s e n v ia d o s p o r la tro s de o p e ra c ió n , m á s c o m p le ja s erá la c o la b o ra c ió n
o p e ra c ió n p ro p o rc io n a u n a a lte rn a tiv a p a ra e l ta m a ñ o e n tre o b je to s . E n g e n e ra l, N P media d e b e m a n te n e rs e tan
de o p e ra c ió n . A m e d id a q u e e l n ú m e r o d e m e n s a je s b a ja c o m o sea p o s ib le .
L a s m é tric a s d e d is e ñ o an o tad as e n las S e c c io n es 2 4 .4 o rg a n iz a n e n c a te g o ría s , q u e re fle ja n c a ra c te rís tic a s de

y 2 4 .5 p ro p o rc io n a n u n a in d ic a c ió n d e la c a lid a d de d is e ñ o im p o rta n te s .
dise ñ o . T a m b ié n p ro v e e n u n a in d ic a c ió n g e n e ra l d e la
Encapsulación
c a n tid a d d e e s fu e rz o d e p ru e b a s re q u e rid o p a ra p ro b a r
u n s is te m a O O . C a r e n c ia d e c o h e s ió n e n m é to d o s ( C C M ) 6. Cuanto
B in d e r [ B I N 9 4 ] s u g ie re q u e u n a a m p lia g a m a d e m á s a lto sea e l v a lo r C C M s erá n e c e s a rio p ro b a r más
m é tric a s de d is e ñ o tie n e n u n a in flu e n c ia d ire c ta e n la estados p a ra a s e g u ra r que lo s m é to d o s n o g e n eran efec
www.FreeLibros.org
« c o m p ro b a b ilid a d » d e u n s is te m a 0 0 . L a s m é tric a s se tos c o la te ra le s .
; Véase la Sección 24.4.1 para una descripción de CCM
428
C A P I T U L O 24 M ÉT R IC A S TÉ C N IC A S PARA SISTEMAS O R I E N T A D O S A O B I E T O S
Porcentaje público y protegido (PPP). L o s a t r i

b u to s p ú b lic o s q u e s e h e r e d a n d e o t r a s c la s e s s o n v i s i
b le s p a r a e s a s c la s e s . L o s a t r ib u t o s p r o t e g id o s s o n La comprobación 0 0 puede ser un poco compleja,
u n a e s p e c ia liz a c ió n y s o n p r i v a d o s a s u b c la s e s e s p e las métricas pueden ayudarle a la asignación de recursos
c ífic a s . E s t a m é t r ic a in d ic a e l p o r c e n t a je d e a t r ib u de pruebas a hihs, escenarios y grupas de clases,
to s d e u n a c la s e q u e s o n p ú b lic o s . V a lo r e s a lt o s p a r a que son «sujetos» basados en características ponderadas.
P P P in c r e m e n ta n la p r o b a b ilid a d d e e f e c to s c o la t e Utilícelos.
r a le s e n t r e c la s e s . L a s p r u e b a s d e b e n d is e ñ a r s e p a r a
a s e g u r a r q u e e s e t i p o d e e f e c t o s c o la te r a le s s e a n d e s Número de Padres Directos (NPD). C u a n d o e s u t i
c u b ie r to s . liz a d o e n e l c o n te x t o 0 0 , e l N P D e s u n a in d ic a c ió n d e
Acceso público a datos miembros (APD). E s t a h e r e n c ia m ú lt ip le . N P D > 1 in d ic a q u e la c la s e h e r e d a
m é t r ic a in d i c a e l n ú m e r o d e c la s e s ( o m é t o d o s ) q u e s u s a t r ib u t o s y o p e r a c io n e s d e m á s d e u n a c la s e r a í z . S e
p u e d e n a c c e d e r a lo s a t r ib u t o s d e o t r a s c la s e s , u n a d e b e e v it a r q u e N P D > 1 ta n to c o m o s e a p o s ib le .
v io la c ió n d e e n c a p s u la c ió n . V a lo r e s a lt o s p a r a A P D Número de descendientes" (NDD) y árbol de pro
p r o d u c e n p o te n c ia lm e n t e e fe c to s c o la te r a le s e n tr e fundidad de herencia (APH)7. T a l c o m o s e e x p l i c ó e n
c la s e s . L a s p r u e b a s d e b e n d i s e ñ a r s e p a r a e s t a r s e g u e l C a p í t u lo 2 3 , lo s m é to d o s d e la s u p e r c la s e t e n d r á n q u e
ro s d e q u e e s e t ip o d e e f e c to s c o la te r a le s s e rá n d e s s e r p r o b a d o s n u e v a m e n t e p a r a c a d a s u b c la s e .
c u b ie r to s .
A d e m á s d e la s m é t r i c a s a n t e r i o r e s , B i n d e r [ B I N 9 4 ]
t a m b ié n d e f in e m é tr ic a s p a r a la c o m p le jid a d y p o l i m o r
Herencia f i s m o d e la s c la s e s . L a s m é t r i c a s d e f i n i d a s p a r a l a c o m
Número de clases raíz (NCR). E s t a m é t r i c a e s u n p l e ji d a d d e c la s e , i n c l u y e n t r e s m é t r ic a s C K ( S e c c ió n
r e c u e n t o d e la s d i s t i n t a s j e r a r q u í a s d e c la s e s , q u e s e d e s 2 4 . 4 . 1 ) : M é t o d o s p o n d e r a d o s p o r c la s e ( M P C ) , e l a c o
c r i b e n e n e l m o d e l o d e d i s e ñ o . S e d e b e n d e s a r r o l l a r la s p l a m i e n t o e n t r e c la s e s d e o b j e t o s ( A C O ) y l a r e s p u e s t a
c o le c c io n e s d e p r u e b a s p a r a c a d a c la s e r a í z , y l a j e r a r p a r a u n a c la s e ( R P C ) . E n r e s u m e n , t a m b ié n s e d e f in e n
q u í a d e c la s e s c o r r e s p o n d i e n t e . A m e d i d a q u e e l N C R la s m é t r i c a s a s o c ia d a s c o n e l r e c u e n t o d e m é t o d o s . L a s
se in c r e m e n t a , e l e s f u e r z o d e c o m p r o b a c i ó n t a m b i é n s e m é t r i c a s a s o c ia d a s c o n e l p o l i m o r f i s m o s e e s p e c i f i c a n e n
in c r e m e n ta . d e ta lle . L o m e jo r e s d e ja r s u d e s c r ip c ió n a B in d e r .
C o m o s e p r e s e n tó e n la P a r te D o s d e e s te li b r o , e l t r a m a c ió n d e l ta m a ñ o d e im p le m e n t a c ió n d e l s o ftw a r e . E l
b a jo d e l j e f e d e p r o y e c t o e s p l a n e a r , c o o r d i n a r , r e g i s t r a r ta m a ñ o e s d ir e c ta m e n te p r o p o r c io n a l a l e s f u e r z o y la
y c o n tr o la r u n p r o y e c to d e s o ftw a r e . E n e l C a p ítu lo 2 0 d u r a c ió n . L a s s ig u ie n t e s m é t r ic a s [ L O R 9 4 ] p u e d e n p r o
se p r e s e n t a r o n a lg u n o s d e lo s a s p e c to s e s p e c ia le s a s o p o r c io n a r u n a v is ió n s o b re e l ta m a ñ o d e l s o ftw a r e :
c ia d o s c o n l a g e s t i ó n d e p r o y e c t o p a r a p r o y e c t o s O O .
P e r o ¿ q u é h a y a c e r c a d e la s m é t r i c a s '? ¿ E x i s t e n m é t r i c a a fflS E B g a
c a s O O e s p e c ia liz a d a s q u e p u e d a n s e r u t iliz a d a s p o r e l I a oplicabilidod de un modelo de procesos evolutivos,
je f e d e p r o y e c t o p a r a p r o p o r c io n a r u n a v is ió n in te r n a llamado el modelo recursivo/porolelo, se discute en el
a d ic io n a l s o b r e e l p r o g r e s o d e s u p r o y e c t o ? 8. L a r e s Capítulo 20.
p u e s ta , d e s d e lu e g o e s « s í» .
L a p r im e r a a c tiv id a d e je c u ta d a p o r e l je f e d e p r o
Número de escenario (NE). E l n ú m e r o d e e s c e n a
y e c t o e s p l a n i f i c a r , y u n a d e la s p r i m e r a s t a r e a s d e p l a
r io s o c a s o s u s o ( C a p ítu lo s 11 y 2 1 ) e s d ir e c ta m e n te
n if ic a c ió n e s la e s t im a c ió n . R e to m a n d o e l m o d e lo
p r o p o r c i o n a l a l n ú m e r o d e c la s e s r e q u e r i d a s p a r a c u b r i r
e v o lu tiv o d e p r o c e s o s , la p l a n i f ic a c ió n s e v u e lv e a r e v i
lo s r e q u is it o s , e l n ú m e r o d e e s ta d o s p a r a c a d a c la s e , e l
s a r d e s p u é s d e c a d a it e r a c ió n d e l s o ft w a r e . D e e s te
n ú m e r o d e m é to d o s , a t r ib u to s y c o la b o r a c io n e s . E l N E
m o d o , la p l a n i f ic a c ió n ( y s u s e s t im a c io n e s d e p r o y e c
e s u n im p o r t a n t e in d ic a d o r d e l ta m a ñ o d e u n p r o g r a m a .
to) e s r e v i s a d a n u e v a m e n t e d e s p u é s d e c a d a i t e r a c i ó n
de A O O , D O O e in c lu s o P O O . Número de clases clave (NCC). U n a c l a s e c l a v e s e
U n o d e lo s a s p e c to s c la v e , a l q u e d e b e h a c e r f r e n t e c e n tr a d ir e c ta m e n te e n e l d o m in io d e l n e g o c io p a r a e l
un je f e d e p r o y e c to d u r a n te la p la n if ic a c ió n , e s u n a e s ti p r o b le m a , y te n d r á u n a m e n o r p r o b a b ilid a d d e s e r im p le -
www.FreeLibros.org
7Véase la Sección 24.4.1 para una descripción de NCC y APM 8 Una descripción interesante de la colección de m étricas CK (Sec
ción 24.4.1) para el uso en la adm inistración de la to m a de decisio
nes puede encontrarse en [CH198],
429
m en tad a p o r m ed io de la re u tiliz a c ió n 9. P or esta razón, Las m étricas N E , N C C y N S U B pueden re c o le c ta r

valores altos p ara N C C indican gran trabajo de d e sa se sobre proyectos OO pasados, y están relacionados con
rrollo substancial. Lorenz y K idd [LO R 94 ] sugieren que el esfuerzo invertido en el proyecto com o un todo, y en
entre el 20 y el 4 0 p o r 100 de todas las clases en un sis actividades de procesos individuales (por ejem plo, AOO,
tem a O O típ ico corresponde a las clases clave. El resto D O O , PO O y pruebas O O ) E sto s datos pueden tam bién
es in fra e stru c tu ra de soporte (G U I, co m u n icacio n es, utilizarse ju n to con m étricas de d iseño discutidas con
bases de dato s, etc.). anterioridad en este capítulo, para calcular «m étricas de
productividad», tales com o el núm ero de clases prome
N ú m e ro de su b sistem as (N SU B). El núm ero de sub dio p o r desarrollador o prom edio de m étodos p o r p e r
sistem as pro p o rcio n a una visión sobre la asignación de sona/m es. C olectivam ente, estas m étricas pueden usarse
recu rso s, la p lanificación (con énfasis particu lar en el para estim ar el esfuerzo, duración, personal y otra infor
desarrollo paralelo) y el esfuerzo de integración global. m ación de proyecto para el proyecto actual.
MSHMM___________________
El software orientado a objetos es fundam entalm entedife- L as m é tric a s o rie n ta d a s a o p e ra c io n e s se centran
rente al softw are desarrolladocon el uso de m étodos co n en el tam añ o y co m p le jid ad de las o p eracio n es in d i
vencionales. Es p o r esto que las m étricas para sistem as viduales. S in e m b a rg o , es im p o rtan te h ac er n o tar que
O O se enfocan en la ponderación que puede aplicarse a la p rim e ra p ara las m é trica s de d ise ñ o O O es a nivel
las clases y a las características del diseño — lo c a liz a de clases.
ció n , encapsulación, ocultam ientode inform ación, heren Se ha propuesto una am plia variedad de m étricas OO
cia y técnicas de abstracción de objetos— , que definen para evaluar la com probabilidad de un sistem a OO. Estas
a la clase com o única. m étricas se centran en la encapsulación, herencia, com
L a co lección de m étricas C K define seis m étricas de plejidad de las clases y polim orfism o. M uchas de estas
softw are o rientadas a la clase que se centran en la cla m étricas han sido adaptadas de la colección CK y de las
se y en la je ra rq u ía de clases. L a co lección de m étricas m étricas propuestas por L orenz y K idd. O tras han sido
tam b ién inco rp o ra m étricas p ara evalu ar las co labora propuestas p o r Binder.
ciones en tre clases y la cohesión de m étodos que re si L as c arac terística s p o n d erab les del m odelo de aná
den d en tro de la clase. A l n ivel o rien tad o a clases, la lisis y d iseño p u ed en a y u d ar al je fe de proyecto de un
colección CK puede co m plem entarse con las m étricas sistem a O O en la p lan ifica ció n y reg istro de las acti
propuestas p o r L orenz y K idd y la co lección de m é tri v idades. El n ú m ero de e scen ario s (casos de uso), cla
cas M D O O . E stas incluyen p o n deraciones de «tam año» ses c lav e y su b siste m a s p ro p o rc io n a n in fo rm ació n
de clase, y otras m étricas que p roporcionan u n a visión acerca del nivel de esfuerzo requerido para implem entar
acerca del grado de especialización de las subclases. el sistem a.
[B E R 9 5 ] B erard, E ., M e t r i c s f o r O b j e c t - O r i e n t e d S o f t w a r e [H A R 9 8 ] H arrison, R ., S.J. C ounseil y R .V . N ith i, « A n E v a -

E n g i n e e r i n g , publicado en internet en c o m p .s o ftw a re - lu atio n o f the M O O D Set o f O b je c t-O rie n te d Softw are
eng, 28 de enero de 199.5. M etrics», I E E E T r a n s . S o f t w a r e E n g i n e e r i n g , vol. 24,n.° 6,
Junio de 1998,pp. 4 91 -4 96 .
fC H I9 41 C hidam ber, S.R., y C.F. K em erer, « A M e tric s S ui
te fo r O b je c t-O rie n te d D e s ig n » , I E E E T r a n s . S o f t w a r e
[L O R 9 4 ] Lorenz, M ., y J. K id d , O b je c t- O r ie n t e d S o ftw a re
E n g i n e e r i n g , vol. 20, n.° 6, Junio de 1994, pp. 4 7 6 -4 9 3 .
M e t r i c , P re n tic e-H a ll, 1994.
[C H I9 8 ] C hidam ber, S.R ., D .R y C .F. K em erer, « M an a g e
m ent U se o f M e tric s fo r O b je ct-O rien ted S oftw are: A n [W H I9 7 ] W h itm ire , S., O b je c t - O r ie n t e d D e s ig n M e a s u re -
E xp lo rato ry A n alysis», I E E E T r a n s . S o f t w a r e E n g i n e e m e n t e , W ile y , 1997.
r i n g , vol. 24, n.° 8, Agosto de 1 9 9 8 ,pp. 6 2 9 -6 3 9 .

[Z U S 9 0 ] Z u s e, H ., S o f t w a r e C o m p l e x i t y : M e a s u re s a n d
[C H U 9 5 ] C h u rc h e r,N .I., y M .J . Shepperd, «Towards a C o n M e t h o d s , D eG ruyter, N u ev a Y o rk, 199Ó.
ceptual Fra m ew o rk fo r O b ject-O riented M etrics», ,4 C M
S o f t w a r e E n g i n e e r i n g N o t e s , vol. 2 0 , n.° 2, A b ril de 199.5,
[Z U S 9 7 ] Zuse, H ., A f r a m e w o r k o f S o f t w a r e M e s u re m e n t,
pp. 69-76. D eG ruyter, N u ev a Y o rk, 1997.
www.FreeLibros.org
9 Esto sólo es verdad h asta que una robusta librería de com ponentes
reutilizables se desarrolla para un dom inio particular.
430
CAPÍTULO 24 M É T R I C A S T É C N I C A S P A R A S I S T E M A S O R I E N T A D O S A O BJETOS
PROBLEMAS Y P P K T O S A CO NSIDERAR
24.1. R e v is e la s m é tr ic a s p re s e n ta d a s e n e s te c a p ítu lo y e n el
N ú m e ro NGE NCC NSUB E s fu e rzo
C a p ítu lo 19. ¿ C ó m o p o d ía c a r a c te r iz a r la s d if e re n c ia s s e m á n
de p ro vecto (d ía s)
ticas y s in tá c tic a s e n tr e la s m é tric a s p a ra s o f tw a r e c o n v e n
cio n al y O O ? 1 34 60 3 900
24.2. ¿ C ó m o e s q u e la lo c a liz a c ió n a fe c ta la s m é tric a s d e s a 2 55 75 6 1.575
rro lla d a s p a r a s o ftw a re c o n v e n c io n a l y O O ?
3 122 260 8 4.420
24.3. ¿Por q u é n o se h a c e m á s é n fa s is e n la s m é tric a s OO q u e
ab o rd an la s c a r a c te rís tic a s e s p e c íf ic a s d e la s o p e ra c io n e s r e s i 4 45 66 2 990
d e n te s d e n tro d e u n a c la s e ?
5 80 124 6 2.480
24.4. R e v is e la s m é tr ic a s d e s c rita s e n e s te c a p ítu lo y s u g ie ra
a lg u n as q u e a b o rd e n d ire c ta o in d ire c ta m e n te e l o c u lta m ie n -
to d e in fo rm a c ió n . S e d is p o n e d e u n n u e v o p r o y e c to q u e s e e n c u e n tr a
24.5. R e v is e la s m é tr ic a s d e s c rita s e n e s te c a p ítu lo y s u g ie ra e n la s p r im e r a s fa s e s d e A O O . S e e s t im a q u e p a r a e s te
alg u n as q u e a b o rd e n d ire c ta o in d ire c ta m e n te la a b s tra c c ió n . p r o y e c t o s e d e s a r r o lla r á n 9 5 c a s o s p r á c tic o s . E s tim a r :
24.6. U n a c la s e x p o s e e 12 o p e ra c io n e s . S e h a c a lc u la d o la a . e l n ú m e r o t o t a l d e c la s e s q u e s e r á n n e c e s a r ia s p a r a
c o m p le jid a d c ic lo m á tic a p a r a to d a s la s o p e r a c io n e s d e l s is te im p le m e n t a r e l s is t e m a ;
m a OO y e l v a lo r p ro m e d io d e la c o m p le jid a d d e l m ó d u lo e s b. l a c a n t i d a d t o t a l d e e s f u e r z o q u e s e r á n e c e s a r i a p a r a
4. P a ra la c la s e x la c o m p le jid a d d e la s o p e ra c io n e s d e la 1 a im p le m e n t a r e l s is t e m a .
la 1 2 e s 5 ,4 ,3 ,6 ,8 ,2 ,2 ,5 ,5 ,4 ,4 r e s p e c tiv a m e n te . C a lc u la rM P C .
2 4 .1 2 . Su profesor le proporciona una lista de métricas OO
24.7. C o n r e s p e c to a la s F ig u r a s 2 0 .8 a y b , c a lc u le e l v a lo r procedente de este capítulo. Calcule los valores de estas métri
A P H p a r a c a d a u n o d e lo s á rb o le s d e h e re n c ia . ¿ C u á l e s e l cas para uno o más de los problemas que se indican a conti
v a lo r d e NDD p a ra la c la s e x2 d e a m b o s á rb o le s? nuación:
24.8. A c u d a a [C H I94] y p re s e n te u n a d e sc rip c ió n d e u n a p á g i a . e l m o d e lo d e d is e ñ o p a r a e l d is e ñ o H o g a r S e g u r o .
na re fe re n te a la d e f in ic ió n fo rm a l d e la m é tr ic a C C M .
b . e l m o d e lo d e d is e ñ o p a r a e l s is t e m a S S R B d e s c r it o
24.9. E n la F ig u r a 2 0 .8 b , ¿ c u á l e s e l v a lo r d e N O A p a r a la s
e n e l p r o b le m a 1 2 .1 3 .
cla se s x3 y x4?
c. e l m o d e l o d e d i s e ñ o p a r a e l j u e g o d e v í d e o c o n s i d e
24.10. C o n r e s p e c to a la F ig u ra 2 0 .8 b su p o n g a q u e la s c u a
r a d o e n e l p r o b le m a 2 2 .1 4 .
tro o p e ra c io n e s h a n s id o in v a lid a d a s e n e l á rb o l d e h e re n c ia
(jerarquía d e c la s e s ),¿ c u á l e s e l v a lo r d e IE p a ra e s a je ra rq u ía ? d . e l m o d e lo d e d is e ñ o p a r a e l c o r r e o e le c t r ó n ic o c o n
s id e r a d o e n e l p r o b le m a 2 2 .1 5 .
24.11. U n e q u ip o d e s o ftw a re h a f in a liz a d o c in c o p r o y e c
tos h a sta la fe ch a . L o s d a to s sig u ie n te s h a n sid o re c o g id o s p a ra e . e l m o d e lo d e d is e ñ o p a r a e l p r o b le m a C T A c o n s id e
to d o s lo s ta m a ñ o s d e lo s p r o y e c to s : r a d o e n e l p r o b le m a 2 2 .1 6 .
Una variedad de libros de AOO, DOO y Comprobación OO (O bject-O rien tedM etrics: M e asures o f C om plexity, Prentice-
(véase O tras lecturas yfu e n te s d e inform ación en los Capítu Hall, 1996) ofrecen los únicos libros dedicados a métricas
los 20, 21 y 22) que hacen referencia de paso a las métricas O O . Otros libros dedicados a las métricas de software con
OO, pero hay pocos que abordan el tema con detalle. Los libros vencional (véase o tra s lectu ras y fu e n te s d e inform ación en
escritos por Jacobson (O hject-O rientedSoftw are Engineering, los Capítulos 4 y 19) contienen discusiones lim itadas de
Addison-Wesley, 1994) y Graham (O h je c to -O rie n te d M et- métricas O O .
hods, Addison-Wesley, segunda edición, 1993).Proporcionan Una amplia variedad de fuentes de información para métri
un tratamiento más extenso que la mayoría. cas orientadas a objetos y temas relacionados se encuentra
Whitmire [WHI97] presenta el tratamiento matemática y disponible en intemet. Una lista reciente de referencias a sitios
extensamentemás sofisticado de las métricas OO publicadas (páginas) web relevantes a las métricas OO pueden encon
a la fecha. Lorenz y Kidd [LOR94] y Hendersen-Sellers trarse en h ttp ://w w w . m h h e .p re s s m a n 5 .c o m
www.FreeLibros.org 43 1
www.FreeLibros.org
PARTE
V
TEM AS AVANZADOS
EN INGENIERÍA
DEL SOFTWARE
n esta parte de Ingeniería del Software: Un enfoque práctico se han tenido
E en consideración varios temas avanzados de la ingeniería del software

que ayudarán a ampliar su entendimiento sobre la ingeniería del soft
ware. En los capítulos siguientes se abarcan las cuestiones siguientes:
• ¿Qué notaciones y preliminares m atemáticos («métodos form ales»)se

requieren para especificar formalmente el software?
• ¿Cuáles son las actividades técnicas clave que se llevan a cabo durante el
proceso de ingeniería del software de la sala limpia?
• ¿Cómo se utiliza la ingeniería del software basada en componentes para
crear sistemas a partir de componentes reutilizables?
• ¿Cuál es el impacto de la arquitectura cliente/servidor sobre la forma en
que se diseña el software de comercio electrónico?
• ¿Se pueden aplicar los principios y conceptos de la ingeniería del software
en productos y aplicaciones basadas en Web?
• ¿Cuáles son las actividades técnicas clave que se requieren para la inge
niería del software?
• ¿Cuáles son las opciones arquitectónicas para establecer un entorno de
herramientas CASE?
• ¿Cuál es el futuro de la ingeniería del software?
Una vez que se hayan contestado estas preguntas, se comprenderán los temas
que pueden tener un impacto profundo en la ingeniería del software la próxima
década.
www.FreeLibros.org
C A P ÍT U L O
M É TO D O S FO R M A LES
O S m é to d o s d e la in g e n ie ría d e l s o ftw a re se p u e d e n d e s g lo s a r sobre u n e sp e ctro de « fo r
L m a lid a d » , q u e v a u n id o lig e ra m e n te a l g ra d o d e r ig o r m a te m á tic o q u e se a p lic a d u ra n te

lo s m é to d o s d e l a n á lis is y d ise ñ o . P o r esta ra z ó n , estos m é to d o s , d e sc rito s a n te rio rm e n te
d e n tro d e este lib r o , se c o lo c a ría n e n e l e x tr e m o d e l e s p e c tro q u e c o rre s p o n d e a lo in fo r m a l.
P a ra c re a r m o d e lo s d e a n á lis is y d is e ñ o , se u t iliz a u n a c o m b in a c ió n de d ia g ra m a s , te x to , ta b la s
y n o ta c io n e s s e n c illa s , a p lic a n d o s in e m b a rg o p o c o r ig o r m a te m á tic o .
A c o n tin u a c ió n se c o n s id e ra e l e x tr e m o o p u e s to d e l e sp e ctro de fo rm a lid a d . A q u í se d e s c ri
be u n a e s p e c ific a c ió n y u n d is e ñ o u tiliz a n d o u n a s in ta x is y u n a s e m á n tic a fo r m a l q u e e s p e c ifi
c a n e l fu n c io n a m ie n to y c o m p o rta m ie n to d e l sistem a. L a e s p e c ific a c ió n fo r m a l tie n e u n a fo r m a
m a te m á tic a (p o r e je m p lo , se p u e d e u t iliz a r e l c á lc u lo d e p re d ic a d o s c o m o base p a ra u n le n g u a je
fo r m a l d e e s p e c ific a c ió n ).
E n u n a in tro d u c c ió n sobre m é to d o s fo rm a le s , A n th o n y H a l l [ H A L 9 0 ] a firm a lo s ig u ie n te :
L o s m étodos fo rm ales son objeto de controversia. Q uienes lo s propugnan afirm an que pueden revolu
c io n ar el desarro llo [del softw are]. Sus detracto res p ien san que resultan im p o sib lem en te d ifíciles. M ientras
ta n to , para la m ay o ría de la gente los m étodos fo rm ales so n tan poco fam iliares que resulta difícil ju z g a r
estos puntos de vista contrapuestos.
E n este c a p ítu lo se e x p lo ra n lo s m é to d o s fo rm a le s y se e x a m in a su p o s ib le im p a c to s o b re la
in g e n ie ría d e l s o ftw a re e n lo s años v e n id e ro s .
VI STAZO RÁPI DO
¿Q u é es? Estos métodos permiten al inge pueden perder vidas o incluso tener lee o escribe datos en un estado. Una
niero del software crear una especifi graves consecuencias económicas. En operación se asocia a dos condicio
cación sinambigüedades que seamás dichas situaciones es esencial descu nes: una precondición y una postcon
completa y constante que las que se brir los errores antes de poner en ope dición. La notación y la heurística
utilizan en los métodos convenciona ración la computadora. Los métodos asociados con los conjuntos y especi
les u orientados a objetos. La teoría de formales reducen drásticamente los ficaciones constructivas —operadores
conjuntos y las notaciones lógicas se errores de especificación, y conse de conjuntos, operadores lógicos y
utilizan para crear una sentencia cla cuentemente son la base del software sucesiones— forman la base de los
ra de hechos (o de requisitos). Esta que tiene pocos errores una vez que el métodos formales.
especificación matemática entonces se cliente comienza a utilizarlo.
puede analizar para comprobar que ¿C uál e s e l p r o d u c to o b te n id o ?
¿C uáles son lo s p a so s? El primer paso Cuando se aplican métodos formales
sea correcta y constante. Como esta en la aplicación de los métodos for s e produce una especificación repre
especificación se crea utilizando nota males es definir el invariante de
ciones matemáticas. inherentemente sentada en un lenguaje formal como Z
datos, el estado y las operaciones o VDM.
es menos ambigua que los nodos infor para el funcionamiento deun sistema.
males de presentación. El invariante de datos es una condi ¿Cómo p u e d o e s ta r se g u r o d e q u e
¿Quién lo h a ce? Un ingeniero del soft ción que se verifica mediante la eje lo h e h ech o co rred a m en te? Debi
ware especializado crea una especifi cución de una función que contiene un do a que los métodos formales utilizan
cación formal. conjunto de datos. Los datos almace la matemática discreta como meca
¿Por q u é e s im portante? En sistemas nados forman el estado en donde una nismo de especificación, para demos
críticos para la misión y para la segu función puede acceder y alterar; y las trar que una especificación es correcta,
www.FreeLibros.org
ridad, un fallo puede pagarse muy operaciones son las acciones que tie se pueden aplicar pruebas lógicas a
caro. Cuando la computadora falla se nen lugar en un sistema a medida que cada función del sistema.
435
I N GE NI E RÍ A DEL SOF TW ARE . UN E N F O Q U E P R Á C T I C O
25.1 C O N C E P T O S B Á SIC O S
L a E ncyclopedia o f Software E ngineering [ M A R 9 4 ] r o s d e l s o ftw a r e , h a y o t r o s ( h a y q u ie n d ir í a q u e la m a y o
d e fin e lo s m é to d o s f o r m a le s d e la s ig u ie n t e f o r m a : r í a ) q u e n o c o n s id e r a n e s p e c ia lm e n t e a g r a d a b le e l p u n
L os m étodos form ales que se utilizan para desarrollar sis to d e v is t a m a te m á tic o d e l d e s a r r o llo d e l s o ftw a r e . P a ra
tem as de com putadoras son técnicas de base m atem ática para e n te n d e r p o r q u é u n e n fo q u e f o r m a l tie n e u n c ie r t o in te
describir las propiedades del sistem a. E stos m étodos form ales r é s , e s p r e c i s o c o n s i d e r a r e n p r i m e r l u g a r la s d e f i c i e n
proporcionan m arcos de referencia en el seno de los cuales las c i a s a s o c ia d a s a l o s e n f o q u e s m e n o s f o r m a l e s .
personas pueden especificar, desarrollar y verificar los siste
m as de m anera sistem ática, en lugar de hacerlo ad hoc.
Se dice que un m étodo es form al si posee una base m ate
25.1.1. Deficiencias de los enfoques menos
m ática estable, que norm alm ente vendrá dada por un lengua formales
je form al de especificación. E sta base proporciona una form a
L o s m é t o d o s d e s c r i t o s p a r a e l a n á l i s i s y d i s e ñ o e n la s
de definir de m anera precisa nociones tales com o la consis
P a r te s T e r c e r a y C u a r t a d e e s te li b r o h a c e n u n a m p lio
tencia y com pletitud, y, lo que es aun m ás relevante, la especi
ficación, la im plem entación y la corrección. u s o d e l le n g u a je n a tu r a l y d e to d a u n a g a m a d e n o ta
c io n e s g r á fic a s . A u n c u a n d o la a p lic a c ió n c u id a d o s a d e
ío s m é to d o s d e a n á lis is y d is e ñ o ju n t o c o n u n a r e v is ió n
Q e /fa : d e ta lla d a p u e d e c ie r ta m e n te lle v a r a u n s o ftw a r e d e e le
los métodos formales tienen un potencial tremendo v a d a c a lid a d , la to r p e z a e n la a p lic a c ió n d e e s to s m é to
pora mejorar la claridad y la precisión de las d o s p u e d e c r e a r t o d a u n a g a m a d e p r o b le m a s . L a
- f < de los requisitos y a la hora de e s p e c if ic a c ió n d e u n s is t e m a p u e d e c o n te n e r c o n t r a d ic
encontrar tanto errores im portantes como sutiles. c io n e s , a m b ig ü e d a d e s , v a g u e d a d e s , s e n te n c ia s in c o m
Steve Easterbiook et al. p le ta s y n iv e le s m e z c la d o s d e a b s tr a c c ió n .
L a s p r o p ie d a d e s d e s e a d a s d e u n a e s p e c if ic a c ió n f o r
fjc O M S E jd j^
m a l - c a r e n c i a d e a m b ig ü e d a d , c o n s is te n c ia y c o m - Aunque un buen índice de documentono puede elimina!
p l e t i t u d - s o n lo s o b je t iv o s d e t o d o s lo s m é t o d o s d e las Contradbciones, puede ayudara descubrirlas.
e s p e c if ic a c ió n . S in e m b a r g o , la u t iliz a c ió n d e m é to d o s Poro las especificaciones y otros documentoshay
fo r m a le s d a lu g a r a u n a p r o b a b ilid a d m u c h o m a y o r d e que invertir tiempo en crear un índice completo.
a l c a n z a r e s t o s o b j e t i v o s id e a l e s . L a s i n t a x i s f o r m a l d e
u n le n g u a je d e e s p e c if ic a c ió n ( S e c c ió n 2 5 . 4 ) h a c e p o s i L a s contradicciones s o n c o n j u n t o s d e s e n t e n c i a s q u e
b le in t e r p r e t a r lo s r e q u is it o s o e l d is e ñ o d e u n a f o r m a d if ie r e n e n tr e s í . P o r e je m p lo , u n a p a r te d e la e s p e c if i
ú n ic a , e lim in a n d o e s a a m b ig ü e d a d q u e s u e le p r o d u c ir c a c ió n d e u n s is t e m a p u e d e a f ir m a r q u e e l s is t e m a d e b e
s e c u a n d o e s c u a lq u ie r le c t o r q u ie n in t e r p r e t a u n le n d e m o n i t o r i z a r t o d a s la s t e m p e r a t u r a s d e u n r e a c t o r quí
g u a je n a t u r a l ( p o r e je m p lo , e l e s p a ñ o l) , o u n a n o t a c ió n m ic o m ie n t r a s q u e o t r a p a r te , q u e q u iz á s h a y a e s c r ito
g r á f i c a . L a s c a p a c id a d e s d e s c r i p t i v a s d e l a t e o r í a d e c o n o t r o m i e m b r o d e l p e r s o n a l , p u e d e a f i r m a r q u e s o la m e n t e
ju n t o s y d e la n o ta c ió n g r á f ic a ( S e c c ió n 2 5 .2 ) h a c e n s e r á p r e c is o m o n i t o r iz a r la s t e m p e r a t u r a s q u e p e r te
p o s ib le u n e n u n c ia d o c la r o d e lo s h e c h o s ( lo s r e q u is i n e z c a n a u n d e t e r m i n a d o i n t e r v a l o . N o r m a l m e n t e , la s
to s ) . P a r a q u e lo s h e c h o s s e a n c o n s is te n te s p u e s to s d e c o n t r a d ic c io n e s q u e s e p r o d u c e n e n la m is m a p á g in a d e
m a n if ie s t o e n u n lu g a r d e u n a e s p e c if ic a c ió n , n o d e b e la e s p e c if ic a c ió n d e l s is t e m a s e p u e d e n d e t e c t a r c o n f a c i
r á n v e r s e c o n t r a d ic h o s a l e s ta b le c e r s e e n o t r o lu g a r d e l i d a d . S i n e m b a r g o , e s f r e c u e n t e q u e la s c o n t r a d i c c i o
la m is m a . L a c o n s is te n c ia se a s e g u r a m e d ia n te u n a n e s e s t é n s e p a r a d a s p o r u n e l e v a d o n ú m e r o d e p á g in a s .
d e m o s t r a c ió n m a t e m á t ic a d e q u e lo s h e c h o s in ic ia le s se L a s am bigüedades s o n s e n t e n c i a s q u e s e p u e d e n
p u e d e n h a c e r c o r r e s p o n d e r f o r m a lm e n t e ( m e d ia n te in te r p r e ta r d e m u c h a s m a n e ra s . P o r e je m p lo , e l e n u n
r e g la s d e in f e r e n c ia ) c o n s e n te n c ia s p o s te r io r e s e x is c ia d o s ig u ie n te e s a m b ig u o :
te n te s d e n tr o d e la e s p e c if ic a c ió n . El o p erad o r de identidad c o n sta del nom bre y la contra
L a completitud e s d i f í c i l d e l o g r a r , a u n c u a n d o s e u t i seña del o p e rad o r; la co n traseñ a c o n sta de seis dígitos; debe
de ser visualizada en la pantalla de seguridad, y se deposi
lic e n m é to d o s fo r m a le s . C u a n d o se e s tá c re a n d o la e s p e
tará en el arch iv o de re gistro cuando el o p erad o r se conecte
c if ic a c ió n s e p u e d e n d e ja r s in d e f in ir a lg u n o s a s p e c to s con el sistem a.
d e l s is t e m a ; q u iz á s o t r a s c a r a c t e r í s t ic a s s e o m it a n a p r o
E n e s te e x tr a c to , ¿ L a p a la b r a « d e b e » a lu d e a la c o n
p ó s it o p a r a o f r e c e r a lo s d is e ñ a d o r e s u n a c ie r t a lib e r t a d
tr a s e ñ a o a la id e n t id a d d e l o p e r a d o r ?
a la h o r a d e s e le c c io n a r u n e n fo q u e d e im p le m e n t a c ió n ;
a d e m á s e s im p o s ib le c o n s id e r a r to d o s lo s e s c e n a r io s
o p e r a c io n a le s e n u n s is t e m a g r a n d e y c o m p le jo . P o r ú l t i
www.FreeLibros.org
m o , la s c o s a s p u e d e n o m i t i r s e s i m p l e m e n t e p o r e r r o r . Com eter errores es hum ano, y volver a com eterlos
A u n q u e e l f o r m a l i s m o p r o p o r c i o n a d o p o r la s m a t e
m á tic a s t ie n e u n c ie r t o a t r a c t iv o p a r a a lg u n o s in g e n ie AMcoltn Fertaí
436
CAPÍTULO 25 M ÉTODOS FORM ALES
La va g u ed a d suele producirse p orque la especifica 25.1.2. M atem áticas en el desarrollo del software
ción del sistem a e s u n d o c u m e n to m u y v o lu m in o so . Las m atem áticas poseen m uchas propiedades útiles para
A lcanzar un elevado nivel de p recisió n de form a co n quienes desarrollan grandes sistem as. U n a de las p ro
sistente es una tarea casi im posible. P uede dar lugar a piedades m ás útiles es que pueden d esc rib ir de form a
sentencias tales com o «la interfaz con el sistem aem plea- su cin tay exacta una situación física, un objeto o el re su l
da po r los operadores del rad ar debe ser am istosa para tado de una acción. L a situación ideal sería que un in g e
con el usuario», o «la interfaz virtu al se basará en sim niero del softw are estuviera en la m ism a situación que
ples conceptos globales que sean sencillos de entender u n m atem ático dedicado a la m atem ática aplicada. Se
y utilizar, y, adem ás, en escaso núm ero». U na revisión debería presentar una especificación m atem ática de un
poco d etallada de estas afirm aciones p o d ría no detectar sistem a, y elaborar la solución en base a una arquitec
la carencia de inform ación útil subyacente. tura de softw are que im plem ente la especificación2.
La inco m p lecció n 1 es p o siblem ente uno de los p ro O tra de las ventajas de la utilización de las m atem á
blemas que se producen m ás frecuentem ente en las esp e ticas en el proceso del softw are es que proporcionan una
cificaciones de sistem as. P o r ejem p lo , con sid érese el transición suave entre las actividades de ingeniería del
siguiente req u isito funcional: softw are. E n m atem áticas no solo se pueden ex p re sar
El sistema debe de mantener el nivel horario del depósito a especificaciones funcionales sino tam bién diseños de sis
partir de los sensores de profundidad situados en el depósito. tem a, y, desde luego, el código del program a es una n o ta
Estos valores deben de ser almacenados para los Ultimos seis
ción m atem ática, aunque ciertam ente sea algo verbosa.
meses.
L a propiedad fundam ental de las m atem áticas es que
Esto describe la parte principal del alm acenam iento adm ite la abstracción y es un m ed io ex celen te para el
del sistema. Supongam os que una de las órdenes del sis m odelado. D ado que es u n m e d io e x a cto , hay p o c as
tema es: probabilidades de am b igüedad, y las especificaciones
La función de la orden PROMEDIOtiene que visualizaren se p u e d en v e rific a r m atem áticam en te p a ra d e sc u b rir
un PC el nivel medio de agua para un sensor concreto entre dos
contradicciones e incom pletitud;y, p o r últim o, la v ag u e
fechas dadas.
dad desap arece com pletam ente. A dem ás, las m a te m á
S uponiendo que n o se o fre c ie se m á s in fo rm ació n tic a s se p u e d e n u tiliz a r p a ra re p re s e n ta r n iv e le s de
acerca de esta orden, los d etalles de la orden e starían ab stracció n en la e sp ecific ació n de sistem a de form a
gravem ente incom pletos. P or ejem p lo , la descripción organizada.
de la orden n o incluye lo que sucedería si un usuario de L as m atem áticas constituyen una herram ienta ideal
sistema especificase una fecha que distase m ás de seis p a ra el m o delado. H acen p o sib le e x h ib ir el esquem a
meses de la fecha actual. fundam ental de la especificación y ayudan al analista y
L a m ezcla de los n iv e le s de abstra cció n se produce especificador del sistem a a v erificar una especificación
cuando sen ten cias ab stractas se en tre m e zcla n a lea to para su funcionalidad, sin problem as tales com o el tie m
riam ente con sentencias que se en cuentran en un nivel po de respuesta, las directrices de d iseño, las directri
muy inferior. P or ejem plo, sentencias tales com o: ces de im plem entación y las restricciones del proyecto
El objetivodel sistemaes hacer un seguimientode stockde que siem pre estorban. Tam bién ayuda al diseñador, por
un almacén que la especificación de diseño del sistem a m uestra las
pueden v erse m ezcladas con la siguiente: propiedades del m odelo, y ofrece tan sólo los detalles
Cuando el encargado de la carga escribe la orden retirar suficientes para h acer posible llevar a cabo la tarea que
será preciso comunicar el número de pedido, la identidad del tengam os entre m anos.
artículo a retirar y la cantidad retirada. El sistema responderá P or últim o, las m atem áticas proporcionan un e le v a
con una confirmación de que la extracciones admisible. do nivel de verificación cuando son usadas com o m edio
Aun cuando dichas sentencias son im portantes en la de desarrollo del softw are. C uando es preciso d em os
especificación de un sistem a, quienes h acen la esp eci trar que un diseño se ajusta a una especificación y que
ficación suelen arreglárselas para m ezclarlas de tal m odo algunos có d ig o s de program a son el reflejo exacto de
que resulta m uy difícil v er toda la arquitectura fu n cio un d iseño, es posible u tilizar una dem ostración m a te
nal global del sistem a. m ática. A ctualm ente es la práctica preferida po rq u e no
Todos estos problem a son m ás frecuentes que lo que hay que hacer un gran esfu erzo para la validación in i
uno d esearía creer. Y cada uno de ello s representa una cial, y porque gran parte de la com probación del siste
deficiencia p otencial en los m étodos convencionales y m a de so ftw are tie n e lu g a r d u ra n te la p ru e b a de
orientados a objetos de especificación. aceptación y del sistem a.
1Esta muy extentida la traducción del término incontpleteness por 2 Una palabra de precaución es apropiada en este punto. Las espe
incompletitud, pero este término en español no está aceptado por la
www.FreeLibros.org
cificaciones matemáticas de sistemas que se presentan en este capí
RAE. (N. del Trad.) tulo no son tan sucintas como una expresión matemática simple.Los
sistemas de software son notoriamente complejos,y no sería realista
esperar que pudieran especificarse en la misma línea que las mate
máticas.
JÍ9 7
IN GE NIE RÍA DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
25.1.3. C o n ce p to s d e lo s m éto d o s fo rm a les 1 . Wiisors

E l o b je tiv o d e esta s ec ció n es p re s e n ta r los co n cep to s 2. Símpson
fu n d a m e n ta le s im p lic a d o s e n la e s p e c ific a c ió n m a te
m á tic a de s is te m a de s o ftw a re , sin a b ru m a r a l le c to r c o n 3. i m i l i
u n e x c e s iv o n iv e l d e d e ta lle m a te m á tic o . P a r a lo g ra r 4 . Fernández
esto , se u tiliz a r á n unos p o c o s e je m p lo s s e n c illo s :
5.
Maxlds = 10
Ejem plo 1. Una tabla de símbolos. P a ra m a n te n e r
6.
u n a ta b la d e s ím b o lo s se u t iliz a u n p ro g ra m a . E s ta ta b la
se u t iliz a fre c u e n te m e n te e n m u c h o s tip o s d is tin to s de 7.
a p lic a c io n e s . C o n s ta de u n a c o le c c ió n de e le m e n to s sin
d u p lic a c ió n . E n la F ig u ra 25.1 se m u e s tra u n e je m p lo
9.
de ta b la típ ic a de s ím b o lo s e n d o n d e se re p re s e n ta u n a
ta b la q u e u t iliz a u n s is te m a o p e ra tiv o p a ra q u e c o n tie io.
n e a lm a c e n a d o s lo s n o m b re s de los u s u ario s de un sis
te m a . O tro s e je m p lo s de ta b la s in c lu iría n p o r e je m p lo F IG U R A 2 5 .1. Una tabla de sím bolos que se em plea
la c o le c c ió n de n o m b re s d e l p e rs o n a l e n u n s is te m a de para un sistem a operativo.
n ó m in a , la c o le c c ió n de n o m b re s de c o m p u ta d o ra s en
un s is te m a de c o m u n ic a c io n e s de re d y la c o le c c ió n de O tro c o n c e p to im p o rta n te es e l de estado. E n e l c o n
d e stin o s de u n s is te m a q u e e la b o ra h o ra rio s de trenes. te x to d e m é to d o s fo rm a le s 3, un esta d o es e l d a to a lm a
S u p o n g a que la ta b la p re s e n ta d a e n este e je m p lo n o c en a d o a l c u a l a cced e e l s is te m a y q u e es a lte ra d o por
co n s ta de m á s de M axlds m ie m b ro s d e p e rs o n a l. E s ta éste. E n e l e je m p lo d e l p ro g ra m a d e la ta b la de s ím b o
a firm a c ió n , que im p o n e u n a re s tric c ió n sobre la ta b la , es lo s , e l e s ta d o es la ta b la de s ím b o lo s .
u n c o m p o n e n te de u n a c o n d ic ió n c o n o c id a c o m o inva E l c o n c e p to fin a l es e l de operación. S e tra ta de una
riante de datos — u n a id e a im p o rta n te a la c u a l v o lv e a c c ió n q u e tie n e lu g a r e n u n s is te m a y q u e le e o e s c ri
re m o s en re p e tid a s o casio n es a lo la rg o d e l c a p ítu lo — . b e datos e n u n estado. S i e l p ro g ra m a d e ta b la de s ín -
b o lo s se o c u p a de a ñ a d ir y e lim in a r n o m b re s de personal
de la ta b la de s ím b o lo s , e n to n c e s e sta rá a so c iad o a dos
o p e ra c io n e s : u n a o p e ra c ió n p a ra a ñ a d ir un n o m b re espe
CLAVE c ific a d o e n la ta b la de s ím b o lo s , y o tra o p e ra c ió n para
Un invariante de datos es un conjunto de condicionesque e lim in a r u n n o m b re e x is te n te de la ta b la . S i e l p ro g ra
sonverdaderas durante la ejecucióndel sistema que m a p ro p o rc io n a la c a p a c id a d d e c o m p ro b a r si existe o
contiene una colecciónde datos. n o un n o m b re c o n c re to e n la ta b la , q u ie re d e c ir que será
n e c e s a ria u n a o p e ra c ió n q u e p ro p o rc io n e a lg u n a in d i
U n invariante de datos es u n a c o n d ic ió n v e rd a d e ra c a c ió n de la e x is te n c ia d e l n o m b re e n la ta b la .
a lo la rg o de la e je c u c ió n d e l s is te m a q u e c o n tie n e u n a
c o le c c ió n de datos. E l in v a ria n te de dato s, q u e es v á l i
d o p a ra la ta b la d e s ím b o lo s d e s c rita a n te r io r m e n te ,
po see dos c o m p o n e n te s : ( 1 ) que la ta b la n o c o n te n d rá C LA VE
m ás de M axlds n o m b re s y (2)que n o e x is tirá n n o m b re s
la «precondición» define las circunstanciasen las que una
d u p lic a d o s e n la ta b la. E n e l caso d e l p ro g ra m a de tablas
operación en particular es vóllda. la «postcondición» define
de s ím b o lo s d e s c rito a n te rio rm e n te , esto s ig n ific a q u e ,
que ocurrecuando una operación ha finalizado su acción.
in d e p e n d ie n te m e n te d e l m o m e n to e n que se e x a m in e la
ta b la de s ím b o lo s d u ran te la e je c u c ió n d e l s is te m a, s ie m
p re c o n te n d rá un m á x im o d e M axlds id e n tific a d o re s de U n a o p e ra c ió n está a so c iad a a d o s c o n d ic io n e s : las
p e rs o n a l y n o c o n te n d rá d u p lic a d o s . p re c o n d ic io n e s y las p o s tc o n d ic io n e s . U n a precondi
ción d e fin e las c irc u n s ta n c ia s e n q u e u n a o p e ra c ió n a i
p a rtic u la r es v á lid a . P o r e je m p lo , la p re c o n d ic ió n para
u n a o p e ra c ió n q u e a ñ a d a u n n o m b re a la ta b la de sím
CLAVE b o lo s de id e n tific a d o re s de p e rs o n a l es v á lid a sólo si el
Enlos métodos formales, un«estado» es un conjunto n o m b r e q u e h a y q u e a ñ a d ir n o e s tá a lm a c e n a d o en la
de datos almacenadosa los que el sistema accede ta b la y e x is te n m e n o s de M axlds id e n tific a d o re s de p er
y modifica. Una«operación» es una acciónque lee s o n a l e n la ta b la . L a postcondición d e u n a o p e ra c ió n
oescribe datos en unestado. d e fin e lo q u e o c u rre c u a n d o la o p e ra c ió n h a fin a liz a d o
www.FreeLibros.org
3 Recuérdese que el térm ino e stad o se ha utilizado tam bién en los
Capítulos 12 y 2 1 com o una representación del com portam iento de
un sistem a o de objetos.
438
CAPÍTULO 25 MÉTODOS FORMALES
su acción. E sto se d efin e m ed ian te su efecto sobre el Bloques sin usar

estado. En el ejem plo de la operación que añade un iden-
tificador a la tabla de sím bolos de identificadoresde per
sonal, la postco n d ició n especificaría m atem áticam ente
que la tabla h ab rá sido increm entada con el identifica-
dor nuevo.
Ejemplo 2. Un gestor de bloques. U n a de las p a r
tes m ás im portantes de los sistem as operativos es el sub
sistema que m antiene archivos que h ay an sido creados
por usuarios. U n a parte del su bsistem a de archivos es
el gestor de bloques. Los archivos del alm acén de archi
vos están form ados p o r b loques de espacio que se alm a
cenan en alg ú n d isp o s itiv o de a lm a c e n a m ie n to de
archivos. D urante el fu n cio n am ien to d e la com putadora,
Cola de bloques que contiene bloques de archivos borrados
los arch iv o s v an sie n d o c re a d o s y b o rra d o s, lo cual
requiere la adquisición y liberació n de bloques de alm a F IG U R A 2 5 .2 . Un gestor de bloques.
cenam iento. P ara abordar este bloque, el su bsistem a de
archivo m a n te n d rá u n a re se rv a de b lo q u e s lib re s y • En la colección de bloques usados no existirán n ú m e
seguirá tam bién la p ista de aquellos bloques que se estén ros de bloques duplicados.
utilizando en ese m om ento. C uando se liberen bloques
E ntre las operaciones asociadas a este subsistem a se
procedentes de un archivo b o rrado lo no rm al será aña
encuentran las siguientes:
dirlos a una co la de b loques que están a la espera de ser
añadidos al d epósito de b loques que n o se utilizan. En • U n a operación que añade una colección de bloques
la Figura 25.2 se m u estra un cierto nú m ero de com po usados al final de la cola.
nentes: la reserv a de b loques n o utilizados, los bloques • U na operación que elim ina una colección de bloques
que en la actualidad form an parte de los archivos adm i usados de la parte anterior de la cola y los coloca en
nistrados p o r el sistem a o p erativ o y aq u ello s blo q u es la colección de bloques sin usar.
que estén esperando p ara ser añadidos a la reserv a de • U na operación que com prueba si la cola de bloques
espacio. L os b loques que está n a la esp e ra se m an tie e stá o no vacía.
nen en u n a co la y cada elem ento de la co la contiene un L a precondición de la prim era operación es que los
conjunto de b lo q u e s p ro c e d e n te s de alg ún arch iv o bloques que se vayan a añadir deben de enco n trarseen la
borrado. colección de bloques usados. L a postcondición e s que
la colección de bloques debe de añadirse al final de la cola.
L a precondición de la segunda operación e s que la
lo técnico de Tormentode ideas (Bralnstormlng)
cola debe de ten er al m enos un elem ento. L a p o stco n
puede funcionar bien cuando se necesita desarrollar dición es que los bloques deben de añadirse a la c o le c
un invariante de datos poro uno función ción de bloques sin usar.
rozonoblementecomplejo. L a operación f in a l- c o m p r o b a r si la cola de bloques
p roporcionados está o no vacía— no posee p recondi-
ción. E sto significa que la operación siem pre está d efi
Para este su b sistem a,el estado es la colección de blo nida, independientem ente del v alor que tenga el estado.
ques libres, la co lección de b loques usad o s y la cola de S i la cola está vacía, la postcondición m an d a un valor
bloques devueltos. El invariante de datos, expresado en verdadero, y fa ls o si no lo está.
lenguaje n atural, es:
• No h abrá ningún bloque que esté a la vez usado y sin Ejemplo 3. Un concentrador de impresión. E n los
usar. sistem as operativos m ultitarea, existe un cierto núm ero
de tareas que hacen solicitudes para im prim ir archivos.
• Todos los conjuntos de b loques alm acenados en la
C on frecuencia, no se dispone de un núm ero suficiente
cola serán subconjuntos de la co lección de bloques
de dispositivos de im presión para satisfacer sim ultáne
utilizados en ese m om ento.
am ente todas las solicitudes de im presión en curso. Toda
• No existirán elem entos de la co la que co ntengan los so licitu d de im p resió n que n o se p u ed a sa tisfac er de
m ism os n úm eros de bloque. form a inm ediata se u b icará en una cola a la espera de
• La co lección de b loques usad o s y b loques sin usar su im presión. L a parte del sistem a operativo que abarca
será la co lección total de b loques de que consten los la adm inistración de estas colas se conoce con el n o m
www.FreeLibros.org
archivos. bre de concentrador de im presión.
• En la c o le c c ió n de b lo q u e s sin u sa r n o ex istirán E n e ste e je m p lo se supone que el sistem a o p e ra ti
núm eros de b loques duplicados. vo no puede em p lea r m ás de D isp M a x d isp o sitiv o s de
439
INGENIERIA DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
s a lid a y q u e c a d a u n o t ie n e a s o c ia d a u n a c o la . T a m T o d o a r c h iv o tie n e a s o c ia d o u n ta m a ñ o .
b ié n s e s u p o n d r á q u e c a d a u n o d e lo s d i s p o s i t iv o s T o d a c o la a s o c ia d a a u n d is p o s i t iv o d e s a lid a c o n
e s tá a s o c ia d o a u n c ie r t o l í m i t e d e lí n e a s p o r a r c h i te n d r á a r c h iv o s q u e te n g a n u n ta m a ñ o m e n o r q u e e l
v o q u e se p u e d e n im p r im ir . P o r e je m p lo , u n d is p o l í m i t e s u p e r io r d e e s te d i s p o s i t iv o d e s a lid a .
s it iv o d e s a lid a q u e t e n g a u n l í m i t e d e 1 . 0 0 0 lí n e a s N o e x is t ir á n m á s d e D is p M a x d is p o s it iv o s d e s a lid a
d e im p r e s ió n e s ta r á a s o c ia d o a u n a c o la q u e c o n t e n
q u e s e a n a d m in is tr a d o s p o r e s te c o n c e n tr a d o r .
g a ta n s o lo a q u e llo s a r c h iv o s q u e n o p o s e a n m á s d e
1 .0 0 0 lí n e a s d e t e x t o . L o s c o n c e n t r a d o r e s d e im p r e
s ió n s u e le n im p o n e r e s t a l i m i t a c i ó n p a r a e v i t a r la s
8»
g r a n d e s ta re a s d e im p r e s ió n , q u e p o d r ía n o c u p a r u n o s C LA VE
d is p o s it iv o s d e im p r e s ió n le n to s d u r a n t e p e r ío d o s d e los estados y las operaciones en muchos aspectos
t i e m p o s u m a m e n t e l a r g o s . E n l a F i g u r a 25.3 s e m u e s son análogos a lo definición de clases en los sistemas
tr a u n a r e p r e s e n t a c ió n e s q u e m á tic a d e u n c o n c e n orientados a objetos. los estados representan el dominio
tr a d o r d e im p r e s ió n . de los datos (atributos) y los operaciones
son los procesos (métodos) que manipulan los datos.
S e g ú n se m u e s tr a e n la fig u r a , e l e s ta d o d e l c o n c e n
t r a d o r c o n s t a d e c u a t r o c o m p o n e n t e s : la s c o l a s d e a r c h i
E l c o n c e n t r a d o r p u e d e t e n e r a s o c ia d o u n c ie r t o n ú m e
v o s q u e e s p e r a n p a r a s e r im p r e s o s , e n d o n d e c a d a c o la
e s tá a s o c ia d a a u n d i s p o s i t iv o d e s a lid a e n p a r t ic u la r ; la r o d e o p e r a c io n e s . P o r e je m p lo :
c o le c c ió n d e d is p o s it iv o s c o n tr o la d o s p o r e l c o n c e n tr a • U n a o p e r a c ió n q u e a ñ a d a u n d i s p o s i t i v o d e s a lid a
d o r ; la r e la c ió n e n tr e d is p o s it iv o s d e s a lid a y e l ta m a ñ o n u e v o a l c o n c e n t r a d o r , j u n t o c o n su l í m i t e d e i m p r e
m á x im o d e a r c h iv o q u e p u e d e im p r im ir c a d a u n o d e s ió n a s o c ia d o .
e llo s , y, p o r ú l t im o , la r e la c ió n e n tr e lo s a r c h iv o s q u e « U n a o p e r a c ió n q u e e lim in a u n a r c h iv o d e la c o la a s o
e s p e r a n p a r a s e r im p r e s o s y s u t a m a ñ o e n lí n e a s . P o r
c ia d a a u n d e t e r m in a d o d i s p o s i t iv o d e s a lid a .
e je m p lo , e n la F ig u r a 2 5 .3 se m u e s tr a e l d is p o s it iv o d e
• U n a o p e r a c ió n q u e a ñ a d a u n a r c h iv o a la c o la a s o
s a li d a L P 1 , q u e c o n u n l í m i t e d e i m p r e s i ó n d e 7 5 0 lí n e a s ,
c ia d a a u n d is p o s it iv o d e s a lid a e n p a r t ic u la r .
t i e n e d o s a r c h i v o s fim p y p e rs o n a s a l a e s p e r a d e i m p r i
m ir s e , y c o n u n t a m a ñ o d e 6 5 0 lí n e a s y 7 0 0 lí n e a s r e s . U n a o p e r a c i ó n q u e a l t e r e e l l í m i t e s u p e r i o r d e lí n e a s
p e c tiv a m e n te . d e im p r e s ió n p a r a u n d is p o s it iv o d e s a lid a e n p a r
tic u la r .
« U n a o p e r a c i ó n q u e t r a s l a d e u n a r c h i v o d e u n a c o la
Dispositivos de salida Colas
a s o c ia d a a u n d i s p o s i t iv o d e s a lid a a o t r a c o la a s o
LP1 f im p p e rs o n a s | c ia d a a u n s e g u n d o d i s p o s i t iv o d e s a lid a .
LP 2 d a to s n u e v o s C a d a u n a d e e s ta s o p e r a c io n e s s e c o r r e s p o n d e c o n
u n a f u n c ió n d e l c o n c e n tr a d o r . P o r e je m p lo , la p r im e r a
LAS1
o p e r a c i ó n s e c o r r e s p o n d e r í a c o n l a n o t i f i c a c i ó n a l con
LAS2 e x re s c e n tr a d o r d e u n n u e v o d is p o s itiv o c o n e c ta d o a l o rd e
n a d o r q u e c o n t i e n e e l s i s t e m a o p e r a t i v o q u e a su v e z
límites Dimensiones a d m in is tr a a l c o n c e n tr a d o r .
r T a l c o m o s u c e d í a a n t e s , c a d a o p e r a c i ó n e s t á a s o c ia
LP1 - * ■ 7 5 0 d a to s n u e v o s — ► 4 5 0 d a a u n a p r e c o n d ic ió n y a u n a p o s t c o n d ic ió n . P o r e je m
LP2 -* ■ 500 f im p - * - 6 5 0 p lo , la p r e c o n d ic ió n p a r a la p r im e r a o p e r a c ió n e s q u e e l
LAS1 - ^ 3 0 0 e x re s — ► 50 n o m b r e d e l d i s p o s i t iv o d e s a lid a y a n o e x is t e y q u e e x is
LAS2 200 p e rs o n a s — * - 7 0 0 ta n e n e s e m o m e n t o m e n o s d e D is p M a x d is p o s itiv o s d e
s a l i d a a e f e c t o s d e l c o n c e n t r a d o r . L a p o s t c o n d i c i ó n es
q u e e l n o m b r e d e l d i s p o s i t i v o n u e v o s e a ñ a d e a l a c o le c
F IG U R A 2 5 .3 . Un concentrador de impresión. c ió n d e n o m b r e s d e d is p o s it iv o s y a e x is te n te s , fo r m á n
d o s e u n a n u e v a e n t r a d a p a r a e l d i s p o s i t i v o s i n q u e e s ta
E l e s ta d o d e l c o n c e n tr a d o r s e re p r e s e n ta m e d ia n te e n t r a d a t e n g a a s o c ia d o s a r c h iv o s e n s u c o la , y e l d is
lo s c u a t r o c o m p o n e n te s : c o la s , d is p o s it iv o s d e s a lid a , p o s i t i v o s e a s o c i a a su l í m i t e d e i m p r e s i ó n .
lí m it e s y d im e n s io n e s . E l in v a r ia n te d e d a to s tie n e c in L a p r e c o n d i c ió n d e la s e g u n d a o p e r a c ió n ( la e lim in a
c o c o m p o n e n te s : c i ó n d e u n a r c h i v o d e u n a c o l a a s o c i a d a a u n d e t e r m in a
d o d i s p o s i t i v o d e s a li d a ) e s q u e e l d i s p o s i t i v o s e a c o n o c id o
. C a d a d i s p o s i t iv o d e s a lid a e s tá a s o c ia d o a u n lí m it e p a r a e l c o n c e n t r a d o r y q u e e x i s t a a l m e n o s u n a e n tr a d a
s u p e r io r d e lí n e a s d e im p r e s ió n . e n la c o la a s o c ia d a a l d i s p o s i t iv o . L a p o s t c o n d ic ió n es
www.FreeLibros.org
. T o d o d i s p o s i t iv o d e s a lid a e s tá a s o c ia d o a u n a c o la q u e l a c a b e z a d e l a c o l a a s o c i a d a a l d i s p o s i t i v o d e s a lid a
d e a r c h iv o s e s p e r a n d o im p r e s ió n , q u e p o s ib le m e n te s e a e lim in a d a y se b o r r e s u e n tr a d a e n la p a rte d e l c o n
n o e s tá v a c ía . c e n t r a d o r q u e s i g a l a p i s t a d e l o s t a m a ñ o s d e a r c h iv o s .
440
CAPÍTULO 25 M ÉTODOS FORMALES
La precondición de la quinta operación descrita ante . El tam año del archivo es m enor o igual que el límite
riormente (el traslado de un archivo de una cola aso de impresión asociado al segundodispositivode salida.
ciada a u n dispositivo de salida a la cola asociada a un
La postcondición es que el archivo será elim inado
segundo dispositivo de salida) es:
de una cola y añadido a otra cola.
• El prim er dispositivo de salida es conocido para el En cada uno de los ejemplos indicados en esta sec
concentrador. ción, se han presentado los conceptos clave de la espe
• El segundo dispositivo de salida es conocido para el cificación formal. Se ha hecho esto sin hacer hincapié
concentrador. en las m atem áticas necesarias para hacer formal la espe
• La cola asociada al prim er dispositivo contiene el cificación. Consideraremos estas m atem áticas en la sec
archivo que hay que trasladar. ción siguiente.
-J&JL PJBLEUMUMRES. mTEM ÁII.C. Q.S.

Para aplicar de forma eficiente los métodos form ales, Las especificaciones constructivas de conjuntos resul
el ingeniero del software debe de tener un conocim ien tan preferibles a la s especificaciones enum eradas, por
to razonable de la notación m atem ática asociada a los que hacen posible definir de forma sucinta los conjuntos
conjuntos y a las sucesiones, y a la notación lógica que form ados por m uchos m iem bros. Tam bién se define
se emplea en el cálculo de predicados. El objetivo de explícitam ente la regla que se utiliza para construir el
esta sección es proporcionar una breve introducción al conjunto.
tema. Para una descripción m ás detallada del tem a se C onsidere el siguiente ejem plo de especificación
recomienda exam inar los libros especializados en esta constructiva:
materia: por ejemplo, [WIL87], [GRI93] y [ROS95],
Esta especificación posee tres componentes: una sig

25.2.1. Conjuntos y especificación constructiva natura, « LJ , un predicado n < 3 ; y un término, n. La
Un conjunto es una colección de objetos o elementos que signatura especifica el intervalo de valores que se con
se utiliza como la piedra angular de los m étodos form a siderará cuando se forme el conjunto, el predicado (una
les. Los elementos de un conjunto son únicos (es decir, expresión Booleana) define la form a en que se debe de
no se permiten los duplicados). Forman un grupo peque construir el conjunto y, por último, el término ofrece la
ño de elementos dentro de llaves, separando mediante form a general del elem ento del conjunto. En el ejem
comas sus elementos. Por ejemplo, el conjunto plo anterior, f^| denota el conjunto de los núm eros natu
{C++, Pascal, Ada, Cobol, Java] rales; por tanto, es preciso considerar los núm eros
naturales, el predicado indica que solamente tienen que
contiene los nom bres de cinco lenguajes de program a incluir los núm eros naturales menores que 3, y el tér
ción. m ino especifica que todos los elem entos del conjunto
El orden en que aparecen los elementos dentro de un será de la form a n. Por tanto, la especificación anterior
conjunto no es relevante. El núm ero de elementos del define un conjunto:
conjunto se conoce con el nom bre de cardinalidad. El
operador # proporciona la cardinalidad de un conjunto. ( 0, 1, 2 )
Por ejemplo, la expresión Cuando la form a de los elem entos del conjunto es
# ( A , B , C , D } =4 evidente, se puede om itir el térm ino. Por ejem plo, el
conjunto anterior se podría especificar en la forma:
indica que se ha aplicado el operador de cardinalidad al
conjunto mostrado, con un resultado que indica el núm e
ro de elementos que había en el conjunto.
Los conjuntos que se han descrito anteriorm ente
4 ¿Qué es una especificación poseían todos ellos elementos que tienen objetos indi
• constructiva de conjuntos? viduales. Tam bién se pueden construir conjuntos for
m ados a partir de elementos que sean pares, ternas, etc.
Por ejemplo, la especificación de conjunto
Hay dos m aneras de definir un conjunto. En prim er
lugar, se puede definir por enum eración de sus elem en
tos (esta es la forma en que se han definido los conjun define el conjunto de parejas de números naturales con
tos indicados anteriorm ente). El segundo m étodo la form a (x, y2) y en los cuales la suma de x e y es 10.
consiste en crear una especificación constructiva de con
www.FreeLibros.org
Se trata del conjunto
juntos. La forma general de los núm eros de un conjun
to se especifican empleando una expresión Booleana.
441
E videntem ente, una especificación co nstructiva de El operador c es sim ilar a c . Sin em bargo, si sus
conjuntos tal co m o la que se requiere p ara representar operandos son iguales posee el v alor verdadero. C on
alg u n o s co m p o n en tes del so ftw are de co m p u tad o ras siguientem ente, el v alor del predicado
puede ser co nsiderablem ente m ás com plicada que los
{HD 1, LP4, R C 5 } c {HD 1, RC2, HD3, L P 1, LP4, LP 6 }
indicados anteriorm ente. Sin em bargo, la m ism a form a
y la estructura b ásica seguirán siendo las m ism as. es fa ls o , y el predicado
{ H D 1 .L P 4 , RC5} c { H D 1 .L P 4 , R C 5 }
25.2.2. Operadores de conjuntos
es verdadero.
Para rep resen tar las operaciones conjuntos y las opera U n conjunto especial es el conjunto vacío O .E n m ate
ciones lógicas se utiliza el m ism o co n ju n to esp eciali m áticas norm ales este operador se corresponde con el
zado de sím bolos. El ingeniero del softw are que pretenda cero. El conjunto vacío tiene la propiedad de que es un
ap licar los m éto d o s fo rm ales d eb e de e n te n d e r esto s subconjunto de todos los conjuntos restantes. D os iden
sím bolos. tidades útiles relacionadas con el conjunto vacío son
0 u A = A y 0 n A = 0
tfc O N S u d j^
para todo conjunto A, en donde u es el o p e ra d o r unión,
Cuando se desarrollan especificaciones formales
tam bién conocido com o «taza» (dado su form a); y n es
es indispensable el conocimientodel conjunto
el o p e ra d o r in te rse c c ió n , c o n o c id o ta m b ién com o
de operaciones. Sise pretende aplicar métodos formales
«gorra».
lo mejor es dedicar tiempo poro familiarizarnos
con los conjuntos de operaciones.
El operador unión adm ite dos conjuntos y form a uno
con todos los elem entos del conjunto después de elim i
nar los duplicados. A sí pues, el resultado de la expresión
El operador e se utiliza p ara indicar la p ertenencia {A rc h iv o l,A rc h iv o 2 , Im puesto, C om pilador} u
de un conjunto. P or ejem plo la expresión {N uevolm puesto, D 2, D 3, A rchivo2}
X E X
es el conjunto
tiene el v alo r verdadero s ix es m iem bro del conjunto X {A rc h iv o l, A rchivo2, Im puesto, C om pilador,
y el valo r fa lso en caso contrario. P or ejem plo, el p re N u ev olm puesto, D 2, D 3 }
dicado
El operador de intersección adm ite dos conjuntos y
12 e ( 6 , 1, 12, 2 2 } form a un conjunto que consta de los elem entos com u
tiene el v alo r verdadero p o r cuanto 12 es un m iem bro nes a los dos anteriores. P or tanto, la expresión
del conjunto. { 1 2 ,4 ,9 9 , 1} n { 1, 13, 12,771
El c o n tra rio del o p e ra d o r e e s el o p e ra d o r £ . La
expresión da lugar a un conjunto { 12, 1).
x g X
posee el valor v erdadero si x no es m iem bro de conjunto

los estructuras motemóticas están entre los mejores
X y falso en caso contrario. P or ejem plo, el predicado
descubrimientos realizados por la mente humana.
13<2 { 13, 1, 124,221 Dougkis Bofstadter
posee el valor fa lso .
L os operadores c y c tien en conjuntos co m o ope- El operador diferencia de conjuntos \ com o el m is
randos. El predicado m o nom bre indica, form a un co n ju n to elim inando los
elem entos del segundo operando de entre los elem en
A c B tos del prim er operando. C onsiguientem ente el valor de
la expresión
tiene el v alo r v erdadero si los m iem b ro s del conjunto
A están dentro del conjunto B , y tiene el v alo r fa ls o en {N uevo, V iejo ,A rch iv o lm p u esto ,
caso contrario. De esta form a el predicado P aram S istem a ]\{ V iejo, P aram S istem a ¡
{1 ,2 } c { 4 ,3 , 1,2} da lugar al conjunto {N uevo,A rchivolm puesto ¡.

El v alor de la expresión
posee el v alo r verdadero. Sin em bargo, el predicado
{a, b, c, d} n {x, y }
{H D 1, LP4, R C 5 } c {H D 1, RC2, HD3, L P 1, LP4, LP 6 }
será el conjunto vacío O .E l operador siem pre propor
www.FreeLibros.org
posee el v a lo rfa ls o p o rq u e el elem en to RCS no está ciona un conjunto; sin em bargo, en este caso no exis
den tro del conjunto que se encuentra a la derecha del ten elem entos com unes entre sus operandos, de manera
operador. que el conjunto resultante carecerá de elem entos.
442
CAPITULO 25 MÉTODOS FORMALES
El operador final es el producto cruzadox,

co n o ci 25.2.4. S u c e s io n e s
do algunas veces tam b ién co m o producto cartesiano, U n a sucesión es una estructura m atem ática que m o d e
el cual posee dos operandos que son conjuntos de pa re la el hecho consistente en que sus elem entos e s t á n o rd e
jas. El resultado es un conjunto de parejas en donde cada nados. U na sucesión 5 es un conjunto de parejas cuyos
una se com pone de un elem ento tom ado del prim er o p e 1
elem entos oscilan entre y el elem ento de m ay o r n ú m e
rando, com binado a su v ez co n un elem ento del segun ro. P or ejem plo,
do operando. L a siguiente expresión es un ejem plo del
producto cruzado
{(1, Jones), (2, W ilson), (3, Shapiro), (4 ,E stévez)}
{1,2} x {4,5,6} es u n a sucesión. L os o b jeto s que fo rm a n los p rim ero s

elem en to s de las parejas se co n o cen co m o dominio de
El resultado de e sta expresión es u n a su c e sió n , y la c o le c c ió n d e se g u n d o s e le m e n to s
{(1,4), (1,5), (1,6), (2,4), (2,5), (2,6) ¡

com o intervalo de la su c e sió n . E n e s te lib r o , la s
secu en cias se in d ic ará n em p lean d o co rch etes a n g u la
re s. P o r e je m p lo , la s u c e s ió n a n te rio r se e s c rib iría
Hay que ten er en cuen ta que todos los elem entos del
en to n ces com o
primer operando se com binan con tod o s los elem entos
del segundo. (Jones, W ilson, Shapiro, Estévez)
U n concepto im portante en los m éto d o s form ales es A diferencia de los conjuntos, en una sucesión se p er
el operador conjuntopotencia.Se trata de la colección m ite la duplicidad, aunque su orden es m uy im portan
de subconjuntos de ese conjunto. El sím bolo que se u ti te. P o r tanto
liza p ara este o perador de conjunto en este capítulo es
P . Este es un o perador unario que cu an d o se aplica a (Jones, W ilson, Shapiro) Z (Jones, Shapiro, W ilson )
un conjunto devuelve el conjunto de subconjuntos del U n a su cesió n v acía se re p re se n ta m ed ian te la fo r
operando. P o r ejem plo, m a ()•
E n las especificaciones form ales se u tiliza un cierto
núm ero de operadores de sucesión. L a concatenación,
A , es un operador binario que form a una sucesión que
ya que todos los conjuntos son subconjuntos de { 1,2,3}. se construye añadiendo el segundo operando al final de
su prim er operando. P or ejem plo,
25.2.3. O p e r a d o r e s ló g ic o s
(2,3 , 3 4 , i ) A ( 7 2 , 3 3 , 3 4 , 200)
Otro co m p o n en te im p o rtan te de los m é to d o s fo rm a d a com o resultado la sucesión (2, 3, 34, 1, 12, 33, 34,
les es la ló g ic a : el á lg e b ra de las e x p re sio n e s v e rd a 200).
deras y falsas. C u a lq u ie r in g e n ie ro d e l so ftw a re O tr o s o p erad o res que p u ed en a p lic a rse a la s su c e
en tenderá e l s ig n ific a d o d e lo s o p e ra d o re s ló g ic o s sio n es so n cabeza, colafrente y último. El o p e ra d o r
com unes. S in e m b a rg o , lo s o p e ra d o re s ló g ic o s que cabeza e x tra e el p rim e r e le m e n to de u n a su c e sió n ; el
están a so c ia d o s a lo s le n g u a je s d e p ro g ra m a c ió n o p e ra d o rcola p ro p o rc io n a lo s ú ltim o s n- 1 e le m e n
com unes se esc rib e n u tiliz a n d o los sím b o los d isp o n i to s fin a le s de u n a su c e sió n de lo n g itu d n; p o r Ú ltim o
bles en el teclad o . L os o p erad o res m atem ático s e q u i el o p e ra d o r Último e x tra e el e le m e n to fin a l d e u n a
valentes son los siguientes: su c e sió n ; y el o p e ra d o r frente p ro p o rc io n a lo s ú lti
A
Y
m os n- 1 elem en to s en una su cesió n de longitud n. P or
eje m p lo ,
V O
—i cabeza(2, 3, 34, 1 ,9 9 , 101) = 2
no
cola{2 , 3 , 3 4 , 1 , 9 9 , 1 0 1 )= { 3 ,3 4 ,1 ,9 9 , 101)
=> im plica ú ltim o(2 , 3, 34, 1, 99, 10 1 )= 101
fr e n te (2 ,3 ,3 4 , 1, =
101) <2, 3, 34, 1, 99)
La cuantificación universal es u n a m an era de co n
feccionar u n a afirm ación acerca de los elem en to s del D ado que una sucesión es un conjunto de parejas, se
conjunto que resu lta ser v erd ad era p ara tod o s los m iem pueden aplicar todos los operadores de co n ju n to s d es
bros de ese conjunto. L a cuantificación u niversal u tili critos en la S ección 25.2.2. C uando en un estad o se u ti
za el sím bolo V. V eam os un ejem plo de la utilización liz a u n a su c e sió n , se d e b e ría d e sig n a r u tiliz a n d o la
de este sím bolo p alab ra clave seq . P or ejem plo,
ListaArchivos: seqA R C H IV O S
NingúnUsuario: {(J
www.FreeLibros.org
en donde se lee que to d a p areja de v alores del conjunto
i
de los n úm eros n aturales, si es m ay o r que entonces j, d e sc rib e n un e stad o con do s com ponentes: u n a suce
i2es m ay o r que f. sión de archivos y un núm ero natural.
443
INGE NIE RÍA DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
25.3 APLICACION DE LA NOTACION MATEMATICA

PA R A LA E S P E C IF IC A C IÓ N iL I :fi' i II 111i II
Para ilustrar la utilización de la notación matemática en

la especificación formal de un componente de softwa
re, estudiaremos de nuevo el ejemplo del G estor de B lo Referencia m k
ques de la Sección 25.1.3. Para recapitular, veremos que
se utiliza un componente importante del sistema ope Para encontrar más información sobre métodosformales visite lo página
archive.comlab.ox.ac.uk/formal-methods.html
rativo de una computadora que mantiene archivos cre
ados por usuarios. El gestor de bloques mantiene una Los componentes matemáticos del invariante de datos
reserva de bloques sin utilizar y también sigue la pista se corresponden con los cuatro componentes del len
de aquellos bloques que se estén utilizando en ese guaje natural marcados que se han descrito anterior
momento. Cuando los bloques proceden de un archivo mente. En la primera línea del invariante de datos se
borrado, lo normal es añadirlos a una cola de bloques establece que no habrá bloques comunes en la colec
en espera a ser añadidos a la reserva de bloques no uti ción de bloques usados y en la colección de bloques
lizados. En la Figura 25.24 se muestra un esquema en libres. En la segunda línea se establece que la colección
donde se representa este funcionamiento. de bloques usados y de bloques libres será siempre igual
a la colección completa de bloques del sistema. La ter
¿(ómo se pueden representar
§ los estados y los invariontes

de datos utilizando los operadores
lógicos y de conjuntos presentados
cera línea indica que el elemento i-ésim o de la cola de
bloques será siempre un subconjuntode los bloques usa
dos. La última línea afirma que si dos elementos de la
cola de bloques no son iguales, entonces no existirán
anteriormente?
componentes comunes en estos dos elementos. Los dos
últimos componentes en lenguaje natural del invarian
Existe un supuesto conjunto B L O Q U E S, que se com te de datos se implementan com o consecuencia del
pone de un conjunto formado por todos los números de hecho consistente en que usados y libres son conjuntos,
bloque, y un conjunto TodosLosB loques, que es un con y por tanto no contendrán duplicados.
junto de bloques entre 1 y B lo q u esM a x. Su estado se La primera operación que se va a definir es la que
modelará mediante dos conjuntos y una sucesión. L o s elimina un elemento de la parte anterior de la cola de
dos conjuntos son usados y lib re s. Ambos contienen bloques. La precondición es que debe de existir al menos
bloques, es decir, el conjunto usados contiene los que un elemento en la cola:
se están utilizando actualmente en los archivos, y el con
junto libres contiene los que están disponibles para los #C olaB loques > 0,
archivos nuevos. La sucesión contendrá los conjuntos La postcondición es que es preciso eliminar la cabe
de bloques listos para ser liberados procedentes de archi za de la cola y es preciso ubicarla en la colección de
vos que se han borrado. bloques libres, y es preciso ajustar la cola para mostrar
El estado se puede describir de la siguiente forma esa eliminación:
usados, libres: P B L O Q U E S u s a d o s ’ = usados \cabeza C olaB loques a
C olaB loques: seq P B L O Q U E S lib re s' = libres u cabeza C olaB loques a
C o la B lo q u es’ = cola C olaB loques
Esta descripción de estado se asemeja a la declara
ción de variables de un programa. Afirma que usados y Una convención que se utiliza en muchos méto
libres serán los conjuntos de bloques y que C o la B lo dos formales es que el valor de una variable después
ques será una sucesión, cada uno de cuyos elementos de una cierta operación lleva el signo prima. Por tan
será un conjunto de bloques. El invariante de datos se to, el primer componente de la expresión anterior afir
escribirá de la siguiente manera ma que el nuevo conjunto de bloques usados
( u s a d o s ’) se rá igual al conjunto bloques usados ante
usados n libres = 0 a rior menos los bloques que hayan sido eliminados.
usados u libres = TodosB loques a El segundo componente afirma que el nuevo conjunto
V i: dom C olaB loques • C ola B lo q u es i c usados a de bloques libres ( l i b r e s ’) será el conjunto viejo de
V i j : dom C ola B lo q u es . i => C ola B lo q u es i n bloques libres después de añadir la cabeza de la cola
C olaB loques] = 0 de bloques. El tercer componente afirma que la cola
www.FreeLibros.org
4 Si no recuerda lo que ocurrió en la colección del gestor de bloques
consulte la Sección 25.1.3 para revisar el invariante de datos, las pre
condiciones de las operaciones y las postcondiciones asociadas al
gestor.
444
CAPÍTULO 25 M ÉTODOS FORM ALES
n u e v a d e b lo q u e s s e rá ig u a l a la c o la d e l v ie jo v a lo r L a p o s t c o n d ic ió n e s q u e e l c o n ju n t o d e b lo q u e s s e
d e la c o la d e b lo q u e s , e s d e c ir , a to d o s lo s e le m e n to s a ñ a d e a l f in a l d e la c o la d e b lo q u e s y e l c o n ju n t o d e b lo
d e la c o la s a lv o e l p r im e r o . U n a s e g u n d a o p e r a c ió n q u e s lib r e s y u s a d o s p e r m a n e c e in v a r ia b le :
es la q u e s e e n c a r g a d e a ñ a d ir u n a c o la d e b lo q u e s ColaBloques’=ColaBloqu.es A (ABlocks)A
BloquesA a la c o la d e b lo q u e s . L a p r e c o n d ic ió n e s usados’= usados A
que BloquesA s e a e n e s e m o m e n to u n c o n ju n to d e libres’= libres
b lo q u e s u s a d o s :
N o c a b e d u d a d e q u e la e s p e c if ic a c ió n m a t e m á t ic a
BloquesA c usados d e la c o la d e b lo q u e s e s c o n s id e r a b le m e n t e m á s r ig u
r o s a q u e u n a n a r r a c ió n e n le n g u a je n a t u r a l o u n m o d e
¿Cómo se pueden representar
« las pretonditiones y las

posttonditiones?
lo g r á f ic o . E s te r ig o r a d ic io n a l r e q u ie r e u n c ie r t o
e s fu e r z o , p e r o lo s b e n e f ic io s g a n a d o s a p a r t ir d e u n a
m e jo r a d e la c o n s is te n c ia y d e la c o m p le t it u d p u e d a n
ju s t if ic a r s e p a r a m u c h o s t ip o s d e a p lic a c io n e s .
25.4 LENGUAIES FQ IIMALES DE ESPEC1E1C "CIÓ N
U n le n g u a je d e e s p e c if ic a c ió n f o r m a l s u e le e s ta r c o m p o s ib le e s p e c if ic a r e l c o m p o r t a m ie n t o d e l s is t e m a . P o r
p u e s to d e tr e s c o m p o n e n te s p r im a r io s : ( 1 ) u n a s in t a e je m p lo , s e p u e d e d e s a r r o lla r u n a s in t a x is y u n a s e m á n
x is q u e d e f in e la n o t a c ió n e s p e c í f ic a c o n la c u a l s e t i c a p a r a e s p e c i f i c a r l o s e s t a d o s y la s t r a n s i c i o n e s e n t r e
re p re s e n ta la e s p e c if ic a c ió n ; ( 2 ) u n a s e m á n tic a q u e e s t a d o s , l o s s u c e s o s y s u s e f e c t o s e n la s t r a n s i c i o n e s d e
a y u d a a d e f in ir u n « u n iv e r s o d e o b je t o s » [ W I N 9 0 ] q u e e s ta d o s , o la s in c r o n iz a c ió n y la t e m p o r iz a c ió n .
se u t iliz a r á p a r a d e s c r ib ir e l s is t e m a ; y ( 3 ) u n c o n ju n E s p o s ib le u t i l i z a r d is t in t a s a b s tr a c c io n e s s e m á n t i
to d e r e l a c i o n e s q u e d e f i n e n la s r e g l a s q u e i n d i c a n c u á c a s p a r a d e s c r ib ir u n m is m o s is t e m a d e d if e r e n t e s
le s s o n l o s o b j e t o s q u e s a t i s f a c e n c o r r e c t a m e n t e l a m a n e r a s . E s o s e h a h e c h o d e m a n e r a f o r m a l e n lo s
e s p e c if ic a c ió n . C a p í t u lo s 1 2 y 2 1 . E l f l u jo d e d a to s y e l p r o c e s a m ie n
El dominio sintáctico d e u n le n g u a je d e e s p e c if ic a t o c o r r e s p o n d ie n te s e d e s c r ib í a u t iliz a n d o e l d ia g r a m a
c ió n f o r m a l s u e le e s t a r b a s a d o e n u n a s in t a x is d e r iv a d a d e f l u j o d e d a to s , y s e r e p r e s e n ta b a e l c o m p o r ta m ie n
d e u n a n o ta c ió n e s tá n d a r d e la te o r ía d e c o n ju n t o s y d e l t o d e l s is t e m a m e d ia n t e u n d ia g r a m a d e t r a n s ic ió n e n tr e
c á l c u l o d e p r e d i c a d o s . P o r e j e m p l o , la s v a r i a b l e s t a l e s e s ta d o s . S e e m p le a b a u n a n o t a c ió n a n á lo g a p a r a d e s
com o x,y, z y d e s c r ib e n u n c o n ju n t o d e o b je t o s q u e e s tá n c r i b i r lo s s is t e m a s o r ie n t a d o s a o b je t o s . E s p o s ib le u t i
r e la c io n a d o s a u n p r o b le m a ( a lg u n a s a v e c e s s e d e n o liz a r u n a n o ta c ió n d e m o d e la d o d if e r e n t e p a r a
m in a n e l dominio del discurso) y se u t iliz a n ju n t o c o n r e p r e s e n t a r e l m is m o s is t e m a . L a s e m á n t ic a d e c a d a
lo s o p e r a d o r e s d e s c r i t o s e n l a S e c c i ó n 2 5 . 2 . A u n q u e l a r e p r e s e n ta c ió n p r o p o r c io n a u n a v is ió n c o m p le m e n t a
s in ta x is s u e le s e r s im b ó li c a , t a m b i é n s e p u e d e n u t i l i z a r r i a d e l s is t e m a . P a r a il u s t r a r e s te e n f o q u e c u a n d o s e
ic o n o s ( s í m b o l o s g r á f i c o s c o m o c u a d r o s , f l e c h a s y c í r u t ilic e n lo s m é to d o s f o r m a le s , s u p ó n g a s e q u e s e u t i l i
c u l o s ) s i no s o n a m b i g u o s . z a u n le n g u a je d e e s p e c if ic a c ió n f o r m a l p a r a d e s c r ib ir
El dominiosemántico d e u n le n g u a je d e e s p e c if ic a e l c o n ju n t o d e s u c e s o s q u e d a n lu g a r a q u e s e p r o d u z
c ió n in d ic a la f o r m a e n q u e e s e le n g u a je r e p r e s e n ta lo s c a u n c ie r t o e s t a d o d e n t r o d e u n s is t e m a . O t r a r e la c ió n
r e q u is it o s d e l s i s t e m a . P o r e j e m p l o , u n l e n g u a j e d e p r o f o r m a l r e p r e s e n ta to d a s a q u e lla s f u n c io n e s q u e s e p r o
g r a m a c ió n p o s e e u n c o n ju n t o d e s e m á n tic a s f o r m a le s d u c e n d e n tr o d e u n c ie r t o e s ta d o . L a in te r s e c c ió n d e
q u e h a c e p o s ib le q u e e l d e s a r r o lla d o r d e s o ftw a r e e s p e e s ta s d o s r e la c io n e s p r o p o r c io n a u n a in d ic a c ió n d e lo s
c ifiq u e a lg o r it m o s q u e t r a n s f o r m a n u n a e n tr a d a e n u n a s u c e s o s q u e d a rá n lu g a r q u e se p r o d u z c a n fu n c io n e s
s a lid a . U n a g r a m á t i c a f o r m a l ( t a l c o m o B N F ) s e p u e d e e s p e c íf ic a s .
u t iliz a r p a r a d e s c r ib ir la s in t a x is d e l le n g u a je d e p r o E n la a c tu a lid a d s e u t ili z a to d a u n a g a m a d e le n g u a
g r a m a c ió n . S in e m b a r g o , u n le n g u a je d e p r o g r a m a c ió n je s fo r m a le s d e e s p e c if ic a c ió n : C S P [ H I N 9 5 , H O R 8 5 ] ,
n o e s u n b u e n le n g u a je d e e s p e c if ic a c ió n , p o r q u e s o la L A R C H [G U T 9 3 ], V D M [J O N 9 1 ] y Z [S P I8 8 , S P I9 2 ]
m e n te p u e d e r e p r e s e n ta r f u n c io n e s c o m p u ta b le s . U n s o n le n g u a je s f o r m a le s d e e s p e c if ic a c ió n r e p r e s e n t a t i
le n g u a je d e e s p e c if ic a c ió n d e b e r á p o s e e r u n d o m i n io v o s q u e m u e s t r a n la s c a r a c t e r í s t i c a s i n d i c a d a s a n t e r i o r
s e m á n tic o m á s a m p lio ; e s to e s , e l d o m in io s e m á n tic o m e n te . E n e s te c a p í t u lo , s e u t iliz a e l le n g u a je d e
de un l e n g u a j e d e e s p e c i f i c a c i ó n d e b e d e s e r c a p a z d e e s p e c if ic a c ió n Z a e fe c to s d e ilu s tr a c ió n . Z e s tá a c o m
e x p r e s a r id e a s t a le s c o m o « P a r a t o d o x d e u n c o n ju n t o p a ñ a d o d e u n a h e r r a m ie n ta a u to m a tiz a d a q u e a lm a c e
www.FreeLibros.org
in f in it oA, e x is te u n y d e u n c o n ju n to in f in it o B ta l q u e n a a x io m a s , r e g la s d e in f e r e n c ia y te o r e m a s o r ie n t a d o s
la p r o p i e d a d / * e s v á l i d a p a r axe y» [W IN 9 0 ], O tr o s le n a la a p lic a c ió n q u e d a n lu g a r a p r u e b a s d e c o r r e c c ió n
g u a je s d e e s p e c i f i c a c i ó n a p l i c a n u n a s e m á n t i c a q u e h a c e m a te m á tic a s d e la e s p e c if ic a c ió n .
445
25,5 U S O $>%t ÍXjNG VAfé Z PARA REPRESENTAR V]K C O M PO N EN TE

E íE M P io tH E s o f t w a r e : r :
L a s e s p e c if ic a c io n e s e n Z s e e s tr u c tu r a n c o m o u n c o n E n e s ta s e c c ió n , s e u t i l i z a e l le n g u a je d e e s p e c if ic a
j u n t o d e e s q u e m a s — s o n e s tr u c tu r a s p a r e c id a s a c u a d r o s c ió n Z p a r a m o d e la r e l e je m p lo d e l g e s to r d e b lo q u e s
q u e p r e s e n ta n v a r ia b le s y q u e e s p e c if ic a n la r e la c ió n e x is q u e s e p r e s e n t a b a e n l a S e c c i ó n 2 5 . 1 .3 y s e t r a t a b a p o s
t e n t e e n t r e la s v a r i a b l e s — . U n e s q u e m a e s , e n e s e n c i a , t e r io r m e n t e e n la S e c c ió n 2 5 .3 . E n la T a b la 2 5 .1 s e p r e
u n a e s p e c if ic a c ió n f o r m a l a n á lo g a a la s u b r u t in a o e l p r o s e n t a u n r e s u m e n d e l a n o t a c i ó n d e l l e n g u a j e z . El
c e d im ie n t o d e u n le n g u a je d e p r o g r a m a c ió n . D e l m is m o s ig u ie n t e e je m p lo d e e s q u e m a d e s c r ib e e l e s ta d o d e l
m o d o q u e l o s p r o c e d i m i e n t o s y la s s u b r u t i n a s s e u t i l i z a n g e s to r d e b lo q u e s y d e l in v a r ia n te d e d a to s :
p a r a e s t r u c t u r a r u n s is t e m a , l o s e s q u e m a s s e u t i l i z a n p a r a
e s tr u c tu r a r u n a e s p e c if ic a c ió n f o r m a l.
La notación Z está basada en la teoría de conjuntos con tipos y en la lógica de primer orden. Z proporcio
na una estructura denom inada esqu em a, para describir el estado y las operaciones de una especificación.
Los esq u em as agrupan las declaraciones de variables con una lista de predicados que limitan los posibles
valores de las variables. En Z el esquem a X se define en la forma
------------------------------ X --------------------------------------------
declaraciones
predicados
Las funciones constantes globales se definen en la forma

declaraciones
predecibles
La declaración proporciona el tipo de la función o constante, mientras que el predicado proporciona su
valor. En esta tabla solam ente se presenta un conjunto abreviado de sím b olos de Z.
C o n ju n to s :
S : NN X S se declara com o un conjunto de X .
X G S x es miembro de S.
xg S x no e s miembro de S
Se T S e s un subconjunto de T: Todo miembro de S e s tá tam bién en T.
Su T La unión de S y T\ Contiene tod os los m iem bros de S o T o ambos.
S n T La inserción de S y T: Contiene tod os lo s m iem brostanto de S c o m o de T.
S\ T La diferencia de S y T: Contienetodos los miembros de S sa lv o losq u e están también en T.
O Conjunto vacío: No contiene miembros.
{x} Conjunto unitario: Solam ente contiene a x.
NN El conjunto de lo s núm eros naturales O, 1 , 2 ....
s: f x S e declara S com o un conjunto finito de X .
m ax(S) El máximo del conjunto no vacío de núm eros S.
F u n c io n e s :
f:X>^> Y S e declara com o una inyección parcial de X e Y.
dom f El dom inio de f. D ícese del conjunto de valores de x para los cuales está definido flx).
ran f El rango de ñ El conjunto de valores que tom a flx) cuando x recorre el dom inio de f.
f ® {x ■
—^ y} Una función que coincide con f salvo que x se hace corresponder con y.
{x}< f Una función igual que f, salvo que x s e ha elim inado de su dominio.
L ó g ic a :
P AQ P yQ : Es verdadero si tanto P com o Q son verdaderos.
P => Q P implica Q: Es verdadero tanto si Q es verdadero com o si P e s falso.
www.FreeLibros.org
es' =es Ningún com ponente del esquem a S cambia en una operación.
TABLA 25.1. R esu m en de la notación Z.
446
CAPITULO 25 MÉTODOS FORMALES
------------------- G estionar B loques ----------------------- -------------------- E lim in a r B lo q u es ----------
usados, libres: P B L O Q U E S A G esto rB lo q u es

C o laB loques: seq P B L O Q U E S
# C olaB loques > 0,
usados n libres = O a usados ’ = u s a d o s \ cabeza C olaB loques a
usados n libres = TodosB loques lib re s' = libres u cabeza C olaB loques a
V /.d o m C ola B lo q u es . C ola B lo q u es i c; usados a C o la B lo q u e s' = cola C olaB loques
V i , j : dom C ola B lo q u es • i <=#
C olaB loques i n C ola B lo q u es j = 0 L a inclusión de A G esto rB lo q u e s d a com o resultado
todas las variables que com ponen el estad o disponible
en el esquem a E lim inarB loques, y asegura que el in v a
riante de datos se m antendrá antes y d esp u és de que se
ejecute la operación.
-M -
La segunda operación, que añade una colección de
Referencia Web i
b loques al final d e la cola, se representa de la m an era
Información detallada sobre el lenguaje Z en donde
siguiente:
se Incluye FAQ se puede encontrar en
archive.comlab. ox.ac.uk/z.html --------------------— A ñ a d ir B lo q u es ---------------------------
A G esto rB lo q u es
El esquem a se co m p o n e de d os partes. L a prim era
B loques A ? :B L O Q U E S
está p o r en cim a de la línea cen tral re p re sen ta n d o las
variables del estado, m ientras que la que se encuentra B lo q u es A l c usados
por debajo de la línea central describe un invariante de C o la B lo q u es' = C olaB loques (B lo quesA ?)
los datos. C uando el esquem a que representa el in v a
usados ’ = usados A
riante y el estad o se utiliza en otro esquem a, va p rece
dido por el sím bolo A Por tanto, si se utiliza el esquem a libres ’ = libres
anterior en uno que describa, p o r ejem plo, una o p era
ción, se rep resen taría m ediante A G estorBloques. C om o P o r convención en Z , toda variable que se lea y que
la afirm ación anterior establece, los esquem as se p u e no form e parte del estado irá term inada m ediante un sig
den u tilizar p ara d e s c rib ir o p e ra c io n e s. El e je m p lo n o de in terro g ació n . C o n sig u ien tem en te, B lo quesA ?,
siguiente describe la o peración que elim ina un elem en que actúa com o parám etro de entrada, acaba con un sig
to de una cola de bloques: n o de interrogación.
1.25.6 MÉTODOS.E.QBMAIES BASADQ&.EK-.QBIEIQ&-

E1 in terés c re c ie n te e n la te c n o lo g ía de o b je to s ha Cola[T]
supuesto que los que tra b a ja n en el área de los m é to
dos form ales h a y a n c o m e n z a d o a d e fin ir n o tacio n es numObjetosM ax :
m atem áticas que re fle ja n las c o n stru c c io n e s a so cia numObjetosM ax 1 1 0 0
das a la o rien ta c ió n a o b jeto s, llam ad as c la se s, h e re n cola: seqT____________
cia e in sta n c ia c ió n . Se h a n p ro p u e s to d ife re n te s #cola N um O bjetosM ax
variantes de las n o ta c io n e s e x iste n te s, p rin c ip a lm e n INIT
te las que se b asan en Z y el p ro p ó sito de esta se c cola = Q
ción es e x a m in a r O b je c t Z q u e d e s a rro lla ro n e n el
Añadir
Centro de V erificació n de S oftw are de la U n iv ersid ad
A(numObjetosMax)
de Q ueensland— . elemento? : T
O bject Z es m uy sim ilar a Z en detalle. Sin e m b a r #cola < numObjetosM ax
go, difiere en lo que se refiere a la estructuración de los cola’ = cola < elemento? >
esquemas y a la inclusión de las funciones de herencia
Extraer
e instanciación.
A(numObjetosMax)
A co ntinuación se m uestra un ejem plo de especifi
www.FreeLibros.org
elemento! : T
cación en O bject Z. A quí se representa la especificación cola ^ < >
de una clase que describe una cola g enérica que puede elemento! = cabeza cola
tener objetos de cualq u ier tipo. cola’ = cola cola
447
INGE NIE RI A DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
S e h a d e fin id o u n a c la s e q u e tie n e u n a v a r ia b le d e
in s ta n c ia c o la , es d e c ir, u n a s e c u e n c ia q u e tie n e o b je
to s d e l tip o T, d o n d e T p u e d e ser d e c u a lq u ie r tip o ; alta, baja '.ColaProc
p o r e je m p lo , p u e d e ser u n e n te ro , u n a fa c tu ra , u n g r u alta A baja
p o d e e le m e n to s d e c o n f ig u r a c ió n o b lo q u e s d e -------------------------------- IN IT
m e m o ria . D e b a jo d e la d e fin ic ió n d e c o la se le e n unos
alta .IN IT a b a ja .IN IT
e s q u e m a s q u e d e fin e n la clase. L a p rim e ra d e fin e u n a
c o n s ta n te q u e te n d r á u n v a lo r n o m a y o r d e 1 0 0 . E l
s ig u ie n te e s p e c ific a la lo n g itu d m á x im a d e l a c o la y
lo s d o s e s q u e m a s s ig u ie n te s A ñ a d ir y E x tra e r d e f i
n e n lo s p ro c e s o s d e a ñ a d ir y e x tr a e r u n e le m e n to de
total! : 1^1_____________
la c o la .
L a p re c o n d ic ió n d e A ñ a d ir e s p e c ific a q u e c u a n d o se total! =: llalla + ftbaja
añ ad e a la c o la u n o b je to elem ento? n o d e b e te n e r u n a
lo n g itu d m a y o r a la p e rm itid a ; y la p o s tc o n d ic ió n e s p e
c ific a lo que o c u rre c u a n d o se h a fin a liz a d o la a d ic ió n L a p rim e ra lín e a d e fin e e l e s q u e m a . L a seg u n d a y
de e le m e n to s . L a p re c o n d ic ió n d e la o p e ra c ió n E xtraer te rc e ra d e fin e n e l e s ta d o y e l in v a ria n te d e l estado. E n
e s p e c ific a que p a ra q u e esta o p e ra c ió n se h a g a c o n é x i este caso e l e s ta d o se c o m p o n e d e dos c o la s de p ro ce
to la c o la n o d e b e e sta r v a c ía , y la p o s tc o n d ic ió n d ebe so b ie n d ife re n c ia d a s : alta y baja.
d e fin ir la e x tra c c ió n de la c a b e z a d e la c o la y su c o lo A la d e fin ic ió n d e l e s ta d o le s ig u e la d e fin ic ió n de
c a c ió n e n la v a ria b le elem ento! c u a tro o p e ra c io n e s . IN IT se d e fin e c o m o la a p lic a c ió n
E s to es, p o r ta n to , la e s p e c ific a c ió n b á s ic a d e la c la de la o p e ra c ió n h e re d a d a IN IT e n las c o la s alta y baja ;
se de u n o b je to e n O b je c t Z . S i q u is ié ra m o s u t iliz a r un a ñ a d ir A lta se d e fin e c o m o la a p lic a c ió n d e la o p e ra
o b je to d e fin id o p o r d ic h a c la se , s e ría re la tiv a m e n te s im c ió n h e re d a d a añadir e n e l c o m p o n e n te d e l estad o alta;
p le de hacer. P o r e je m p lo , s u p o n g a m o s q ue se está d e fi a ñ a d irB a ja se d e fin e c o m o la a p lic a c ió n d e la o p e ra
n ie n d o p a rte de u n s is te m a o p e ra tiv o q u e m a n ip u la b a c ió n h e re d a d a a ñadir so b re e l c o m p o n e n te d e estado
p ro ceso s que re p re s e n ta n los p ro g ra m a s e n e je c u c ió n y b a ja ty , fin a lm e n te , la o p e ra c ió n totalP rocesos se d e fi
que to m a m o s la d e c is ió n d e que los p ro ceso s te n ía n que n e c o m o la s u m a d e ta m a ñ o s de las c o la s in d iv id u a le s
e sta r e n dos c o la s , u n a c o n lo s p ro ceso s d e a lta p r io r i alta y baja.
d a d y la o tra c o n a q u e llo s d e b a ja p rio rid a d , y d o n d e la C o n s e c u e n te m e n te , esto es u n e je m p lo d e in stan cia-
p r io r id a d la u tilic e e l p la n ific a d o r d e l s is te m a o p e ra ti c ió n e n a c c ió n , d o n d e los o b jeto s d e fin id o s p o r un esque
v o c o n e l p ro p ó s ito d e d e c id ir c u a l es e l s ig u ie n te p r o m a O b je c t Z se u tiliz a n e n o tro e s q u e m a . C o n esto se
ceso a e je c u ta r. L a p r im e r a s e n te n c ia d e O b je c t Z p u e d e d e fin ir la h e re n c ia .
n e ce sa ria in s ta n c ia rá la c lase d e c o la g e n e ra l e n u n a que P a ra p o d e r lle v a r a c a b o la d e fin ic ió n d e h e re n c ia ,
c o n te n g a pro cesos. e x a m in e m o s o tro e je m p lo , e l d e u n a ta b la d e sím bo los.
C olaP roc = = C ola[ P R O C E SO S ] E stas ta b la s se u tiliz a n c o n s ta n te m e n te e n a p lic ac io n es
[procQ / co la ,p ro c ? I e lem en to ? p ro c! / elem ento!] q u e c o n tie n e n lo s n o m b re s d e e m p le a d o s e n sistem as
d e p e rs o n a l, n o m b re s d e im p re s o ra s e n sistem as opera
S e p u e d e d e c ir que to d o lo que h a ce e s re e m p la z a r tiv o s , n o m b re s d e c a rre te ra s e n sistem as d e n a ve g ac ió n
e l tip o T p o r P R O C E S O S e n la d e fin ic ió n d e la c la se , la p a ra v e h íc u lo s , y otros. P a ra d e s c rib ir la h e re n c ia , p ri
c o la g e n e ra l cola p o r la c o la d e lo s p ro ceso s procQ y m e ro d e fin ire m o s u n a ta b la g e n é ric a de s ím b o lo s , a con
los p a rá m e tro s g e n e ra le s d e e n tra d a y s a lid a elem ento? tin u a c ió n la u tiliz a re m o s y m o s tra re m o s c ó m o se puede
y elem ento!, p o r a q u e llo s p a rá m e tro s d e p ro c e s o p ro c? , h e re d a r d e l e s q u e m a Z q u e la d e fin e . E n p rim e r lugar
y p ro c!. E l s ím b o lo / re p re s e n ta u n a fo r m a d e s u s titu se d e b e n d e s c rib ir in fo r m a lm e n te las o p e ra c io n e s y el
c ió n d e te x to . e stad o n e ce sa rio s.
E l s ig u ie n te p a so , c o m o se m u e s tra a c o n tin u a c ió n ,
E l e s ta d o e sta rá c o m p u e s to de un c o n ju n to d e l tipo
es d e fin ir u n a c lase que d e s c rib e las dos colas. E s ta c la
T. S u p o n e m o s q u e n o h a b rá m ás d e 100 o b je to s y d e fi
se u t iliz a las o p e ra c io n e s d e fin id a s e n la c la s e Cola.
n ire m o s u n a s erie d e o p e ra c io n e s q u e a c tu a rá n sobre el
S u p o n g a m o s q u e las s ig u ie n te s o p e ra c io n e s son n e c e
estado:
sarias:
• IN IT que in ic ia liz a la ta b la d e s ím b o lo s p a ra que esté
• a ñadir A lta , añ ad e u n p ro c e s o a la c o la d e lo s p ro c e
v a c ía .
sos d e a lta p rio rid a d .
• añadirB aja, añ ad e u n p ro c e s o a la c o la d e lo s p r o • añadir que a ñ a d e u n o b je to a la ta b la d e sím bolos.
cesos de b a ja p rio rid a d . • extraer q u e e x tra e u n o b je to d e la ta b la de sím bolos.
www.FreeLibros.org
• IN IT in ic ia liz a las c o la s d e a lta y b a ja p rio rid a d . • núm ero q u e re to rn a c o n e l n ú m e ro d e o b je to s de la
• totalP rocesos d e v u e lv e e l n ú m e ro to ta l de pro cesos ta b la d e s ím b o lo s . A c o n tin u a c ió n se m u e s tra esta
q u e está n e n las colas. d e fin ic ió n .
448
CAPÍTULO 25 MÉTODOS FORM ALES
-------------- T a b la S ím b o lo [T ] A h o r a s u p o n g a m o s q u e s e n e c e s it a u t ili z a r la h e r e n
c ia . P a r a m o s t r a r e s te c a s o , s u p o n g a m o s u n a o p e r a c ió n
n u m O b je to s M a x : ÑJ___________ e n c o n tr a r q u e d e v u e l v e u n v a l o r e n c o n tr a d o s i s e e n c u e n
M a x E le m < 1 0 0 tr a u n o b je t o e n la ta b la d e s ím b o lo s , y u n v a lo r no en con
ta b la : T _______________________ tr a d o s i n o e s t á e n l a t a b l a . V a m o s a s u p o n e r t a m b i é n u n a
# ta b la < M a x E le m a p lic a c ió n e n la q u e c u a n d o s e e je c u ta la o p e r a c ió n en con
tr a r s e s u e l e u t i l i z a r e l m i s m o o b j e t o q u e e s t á e n l a t a b l a .
--------------------------------- IN IT -------
A s e g u r a r e m o s q u e , c u a n d o s e a p lic a a n te s e s ta o p e r a
t a b l a = ) ) ___________________________ c ió n , a n te s d e e m p e z a r s e c o m p r o b a r á q u e é s te e s e l o b je
----------------------------------------- A ñ a d ir — t o , lo q u e p o d r í a s u p o n e r u n a b ú s q u e d a p r o lo n g a d a e n la
A ( ta b la ) ta b la . A n t e s d e d e f in ir e s te e s q u e m a s e d e b e d e u t ili z a r
o b ie t o ? : T e l e s q u e m a o r ig in a l d e ta b la d e s ím b o lo s p a r a i n c l u i r e s ta
in f o r m a c ió n . E n p r i m e r lu g a r n e c e s it a m o s u n m ie m b r o
# ta b la < M a x E le m
d i f e r e n c i a d o d e l a t a b l a q u e s e c o n o c e c o m o F re c E le m .
t a b l a ' = t a b l a u { o b j e t o ? }_______
E s te e s e l e le m e n to q u e s e u t ili z a c o n m á s fr e c u e n c ia . L a
----------------------------------------- E x t r a e r — d e f in ic ió n d e la ta b la n u e v a e s :
A ( ta b la )
o b je t o ? : T T a b la D if[T ] -------------------
o b ie t o ? e t a b la T a b la S ím b o lo s /T ] -------------------------------------------------
ta b la ' = ta b l a \ ( o b je to ? ] F r e c E le m : T
------------------------------- n ú m e r o — --------------------------- E n c o n t r a r -------------------------------

A( F r e c E le m )
E /ta b la ) a S e r E n c o n tr a d o ? : T
num Tablalnl : M e s ta d o ! : [e n c o n tr a d o ,n o e n c o n tr a d o } .__________
num Tabla!n\ = # ta b la a S e r E n c o n tr a d o ? = F r e c E le m v a S e r E n c o n tr a d o ?
H ta b la = >
E s ta s s o n o p e r a c io n e s m u y s im p le s q u e c o n lle v a n e s ta d o ! = e n c o n tr a d o a F r e c E le m ' = a S e r E n c o n
o p e r a c io n e s e s t á n d a r d e c o n j u n t o s c o m o u , y q u e tr a d o ?
s ig u e n e l f o r m a t o m o s t r a d o e n e l e j e m p l o d e c o l a s . L a a S e r E n c o n tr a d o ? A F r e c E le m a a S e r E n c o n tr a d o ?
o p e r a c i ó n a ñ a d ir s e d e f i n i r á s o l o s i l a t a b l a t i e n e e s p a <£. ta b la =>
c io p a r a e l o b je t o q u e s e v a a a ñ a d ir , y la o p e r a c ió n
e s ta d o ! = n o E n c o n tr a d o
e x tr a e r s o l o s e d e f i n e s i e l o b j e t o q u e s e v a a e x t r a e r
e s tá d e n t r o d e la t a b la d e s í m b o lo s . L a o p e r a c ió n núm e
A q u í t o d a s l a s o p e r a c i o n e s d e f i n i d a s p a r a T a b la -
ro n o a f e c t a a l e s t a d o , y d e a q u í q u e i n c l u y a e l e l e
S ím b o lo s s e h e r e d a n s i n c a m b i o s c o m o e s t á l a v a r i a b l e
m e n t o E (ta b la ). d e i n s t a n c i a ta b la . L a n u e v a o p e r a c i ó n e n c o n tr a r u t i l i
S i q u e r e m o s in s t a n c ia r la t a b la c o m o u n a t a b la d e
z a u n a v a r i a b l e F r e c E le m q u e f o r m a p a r t e d e l n u e v o
n o m b re s d e e m p le a d o s d e l t ip o E M P LE A D O , se r e q u ie
e s q u e m a T a b la D if d e O b j e c t Z .
re to d o lo s ig u ie n te :
E s ta o p e r a c ió n c o m p r u e b a s i e l p a r á m e tr o d e e n tr a d a
T a b E m p le a d o = = T a b la S im b o lo s [E M P L E A D O ] d e e n c o n tr a r e s e l m i s m o q u e e l e l e m e n t o f r e c u e n t e q u e
[e m p /ta b la ,e m p ? /o b je to ? ,e m p llo b je lo ’\ s e e s t á r e c u p e r a n d o v a r i a s v e c e s o e s t á d e n t r o d e l a t a b la .
Si e s a s í, e n t o n c e s e l e s t a d o c o r r e c t o e n c o n t r a d o s e d e v u e l
d o n d e la ta b la s e c o n v ie r t e e n u n a ta b la c o n o b je t o s
v e y e l e le m e n t o f r e c u e n t e s e a c tu a liz a . S i e l e le m e n t o n o
EM PLE A D O y d o n d e lo s p a r á m e tr o s d e e n tr a d a d e f i
e s e l e le m e n to fr e c u e n te y n o e s tá d e n tr o d e la ta b la e n to n
n id o s d e f o r m a g e n é r ic a h a n s id o s u s t it u id o s p o r p a r á
c e s s e d e v u e l v e e l e s t a d o n o E n c o n tra d o .
m e tr o s e s p e c í f ic o s em p? y em p!
E s te e s q u e m a se p u e d e u t iliz a r e n to n c e s d e n tr o d e
A c o n t in u a c ió n s e m u e s tr a e l e s q u e m a O b je c t Z q u e
u n a a p lic a c ió n d e e m p le a d o s e s p e c if ic a n d o :
d e s c r ib e l a n u e v a t a b l a d e e m p l e a d o s m e d i a n t e l a i n s -
ta n c ia c ió n ; s im p le m e n t e in v o lu c r a la r e d e f í n ic ió n d e lo s T a b E m p le a d o F r e c = = T a b la D if[E M P L E A D O ]
o p e ra d o re s q u e s e a c a b a n d e d e fin ir . [ e m p s /ta b la ,e m p ? /o b je to ? ,e m p lE m p f r e c /O b je to fr e c ]
------------------- ta b la E m p --------------------- Y
-------------------- Em pleadoFrec ------------------------
e : T a b E n w le a d o s
A ñ a d irE m p = e .a ñ a d ir e : T a b E m p le a d o F r e c
A ñ a d ir E m p F r e c i e .A Ñ A D lR
E x tra e rE m p = e. e x tr a e r
www.FreeLibros.org
E x tr a e r E m p F r e c i e.E X T R A E R
In itE m p = e.IN IT In itE m p F r e c i e .IN IT
N ú m ero E m p = e .n ú m e r o N ú m e r o E m p F r e c = e .N U M E R O
449
INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO
E s to e s u n a in t r o d u c c ió n c o r ta p a r a m o s t r a r la m a n e c i ó n a n t e r i o r , p a r a i m p l e m e n t a r la s f u n c i o n e s p a r a l a in s -
r a d e e m p e z a r a u t i l i z a r la s n o t a c i o n e s f o r m a l e s p a r a l a t a n c ia c ió n y la h e r e n c ia . E l t r a b a jo e n e s ta á r e a e s tá t o d a
e s p e c i f i c a c i ó n d e s is t e m a s o r i e n t a d o s a o b j e t o s . L a m a y o r v í a a n iv e l d e in v e s t ig a c ió n c o n p o c a s a p lic a c io n e s . S in
p a r te d e l tr a b a jo q u e s e h a lle v a d o a c a b o d e n tr o d e e s ta e m b a r g o , d u r a n t e e l p e r í o d o d e v i d a d e e s t a e d i c i ó n la s
á re a h a e m p le a d o la n o c ió n Z y se h a in te n ta d o c o n s t r u ir n o ta c io n e s fo r m a le s o r ie n t a d a s a o b je t o d e b e r í a n e x p e
b a s a d o e n la s i d e a s d e e s t a d o , p r e c o n d i c i ó n , p o s t c o n d i r im e n t a r e l m is m o n i v e l d e p e n e tr a c ió n in d u s t r ia l q u e
c ió n e in v a r ia n t e d e d a to s , q u e s e h a d e s c r ito e n la s e c n o t a c i o n e s e s t á n d a r t a l e s c o m o la s n o t a c i o n e s Z .
U n a d e la s c a r a c t e r í s t i c a s p r i n c i p a l e s d e la s d o s t é c n i N o m b r e : c o la P a r c ia l
c a s d e e s p e c if ic a c ió n d e s c r ita s a n te r io r m e n t e , Z y Z + + , C la s e s : c o l a ( Z )
e s e l h e c h o d e q u e e s tá n b a s a d a s e n la n o c ió n d e e s ta O p e ra d o re s :
d o : u n a c o le c c ió n d e d a to s q u e s e v e n a fe c ta d o s p o r o p e c o la V a c í a : — » c o la ( Z )
r a c io n e s d e f in id a s p o r e x p r e s io n e s e s c r ita s e n e l c á lc u lo a ñ a d ir E le m e n to : Z x c o la ( Z ) —» c o la ( Z )
d e l p r e d ic a d o . e x t r a e r E le m e n to : Z x c o la ( Z ) - » c o la ( Z )
U n a t é c n ic a a lte r n a tiv a se c o n o c e c o m o e s p e c if ic a p r im e r a : c o la ( Z ) — > Z
c ió n a lg e b r a ic a . Y c o n s is te e n e s c r i b ir s e n te n c ia s m a t e c o la ( Z ) —» Z
ú ltim a :
m á t ic a s q u e n a r r a n e l e f e c t o d e la s o p e r a c io n e s
e s tá V a c ía ? : c o la ( Z ) —> B o o le a n a
a d m is ib le s e n a lg u n o s d a to s . E s ta t é c n ic a tie n e la v e n
t a ja p r i n c ip a l d e a p o y a r e l r a z o n a m ie n t o d e m a n e r a L a p r im e r a lí n e a e s la q u e d a e l n o m b r e a l t i p o d e
m u c h o m á s f á c il q u e lo s m é to d o s b a s a d o s e n e l e s ta d o . c o la . L a s e g u n d a lí n e a a f ir m a q u e la c o la m a n e ja r á c u a l
E l p r im e r p a s o a l e s c r ib ir u n a e s p e c if ic a c ió n a lg e q u ie r t ip o d e e n tr a d a Z ; p o r e je m p lo , Z p o d r ía s e r m e n
b r a ic a e s d e t e r m in a r la s o p e r a c io n e s n e c e s a r ia s . P o r s a je s , p r o c e s o s , e m p l e a d o s e s p e r a n d o e n t r a r a u n e d i f i c i o
e je m p lo , p o d r í a d a r s e e l c a s o d e q u e u n s u b s is te m a q u e o a e r o n a v e s e s p e r a n d o p a r a a t e r r iz a r e n u n s is t e m a d e
im p le m e n t e u n a c o la d e m e n s a je s e n u n s is t e m a d e c o n tr o l d e l tr á fic o a é re o .
c o m u n i c a c i ó n n e c e s i t e o p e r a c i o n e s q u e e x t r a i g a n un E l r e s t o d e l a e s p e c i f i c a c i ó n d e s c r i b e la s s i g n a t u r a s
o b je t o d e l c o m ie n z o d e la c o la , q u e d e v u e lv a n e l n ú m e d e la s o p e r a c i o n e s : c u á l e s s o n l o s n o m b r e s y e l t i p o d e
r o d e o b je t o s d e u n a c o la y q u e c o m p r u e b e n s i la c o la e l e m e n t o q u e p r o c e s a n . L a d e f i n i c i ó n d e colaVacía a f i r
e s tá v a c í a . m a q u e n o t o m a a r g u m e n t o s , y q u e d a u n a c o la q u e e s tá
U n a v e z q u e s e h a n d e s a r r o lla d o e s ta s o p e r a c io n e s , v a c í a ; l a d e f i n i c i ó n d e añadirE lem ento a f i r m a q u e t o m a
s e p u e d e e s p e c if ic a r la r e l a c ió n q u e e x is t e e n t r e e lla s . u n o b je t o d e l t ip o Z y u n a c o la c o n lo s o b je t o s d e l t ip o
P o r e je m p lo , e l e s p e c if ic a d o r p o d r ía d e s c r ib ir e l h e c h o Z y e n to n c e s d a u n a c o la d e o b je t o s d e l t ip o Z , y a s í
d e q u e c u a n d o se a ñ a d e u n e le m e n to a la c o la e l n ú m e s u c e s iv a m e n te .
r o d e e le m e n to d e e s a c o la a u m e n ta e n u n e le m e n to . E s to e s s o lo la m it a d d e la e s p e c if ic a c ió n — e l r e s to
P a r a m o s t r a r u n a im p r e s ió n d e l a s p e c to d e u n a e s p e c i d e s c r i b e l a s e m á n t i c a d e c a d a o p e r a c i ó n e n f u n c i ó n d e la
f ic a c ió n a lg e b r a ic a r e p r o d u c ir e m o s d o s e s p e c if ic a c io r e la c ió n c o n o tr a s o p e r a c io n e s - . A c o n tin u a c ió n , se
n e s . L a p r im e r a e s p a r a u n a c o la , y la s e g u n d a p a r a u n a m u e s t r a n a lg u n o s e je m p lo s d e e s te t i p o d e e s p e c if ic a c ió n .
t a b la d e s í m b o lo s . A s u m im o s q u e la s o p e r a c io n e s L a p r i m e r a a f i r m a q u e estáVacíal s e r á v e r d a d e r a p a r a
s ig u ie n te s s o n n e c e s a r ia s p a r a la c o la : u n a c o l a v a c í a y f a l s a s i e x i s t e a l m e n o s u n o b j e t o e n la
• C olaVacía. D e v u e l v e u n v a l o r B o o l e a n o v e r d a d e r o c o la ; c a d a u n a d e e s ta s p r o p ie d a d e s s e e x p r e s a n e n u n a
s i la c o la a la q u e se a p lic a e s tá v a c í a y fa ls o s i n o lo s o la lí n e a
e s tá . e s tá V a c í a ? ( c o la V a c ía ) = v e rd a d e ra
• añadirO bjeto. A ñ a d e u n o b j e t o a l f i n a l d e l a c o l a . e s t á V a c í a ? ( a ñ a d ir O b je to ( z ,q ) ) = fa ls a
• extraerO bjeto. E x t r a e u n o b j e t o d e l f i n a l d e l a c o l a . L a d e f i n i c i ó n d e l a o p e r a c i ó n p r im e r a e s
• p rim ero . D e v u e l v e e l p r i m e r e l e m e n t o d e u n a c o l a , p r im e r a ( a ñ a d ir E le m e n to ( z ,q ) ) = z
y e s ta n o s e v e a f e c t a d a p o r e s ta o p e r a c ió n . l a c u a l e s t a b l e c e q u e p rim e ro v o l v e r á c o n e l p r i m e r e l e
• Último. D e v u e l v e e l ú l t i m o e l e m e n t o d e u n a c o l a , y m e n t o d e la c o la .
e s ta n o s e v e a fe c t a d a p o r e s ta o p e r a c ió n . C o n e s to s e p u e d e v e r e l e s t ilo d e e s p e c if ic a c ió n .
P a ra c o n c lu ir o fr e c e r e m o s u n a e s p e c if ic a c ió n c o m
• estáVacía? D e v u e l v e u n v a l o r B o o l e a n o v e r d a d e r o
p le t a d e u n a t a b la d e s ím b o lo s . E s ta e s u n a e s tr u c tu
www.FreeLibros.org
s i la c o la e s tá v a c í a ,' y f a ls o s i n o lo e s tá .
r a d e d a t o s q u e c o n t i e n e u n a c o l e c c i ó n d e o b j e t o s s in
A c o n t i n u a c i ó n s e m u e s t r a n la s p r i m e r a s l í n e a s d e l a d u p lic a d o s . E s ta s ta b la s s e e n c u e n t r a n p r á c tic a m e n te
e s p e c if ic a c i ó n y la s o p e r a c io n e s d e e s ta c o la : e n t o d o s lo s s is t e m a s d e c o m p u t a d o r a s : s e u t iliz a n
450
CAPITULO 25 MÉTODOS FORM ALES
para alm acenar nom bres en sistem as de em pleados, La definición del operador añadirElemento es
identificadores de aeronaves en sistem as de control añadirElem ento(s2, añadirElem ento(s l,s)) =
del tráfico aéreo, program as en sistem as operativos y si s 1 = s2 entonces añadirElemento(s2,s)
otros. o si no añadirElem ento(sl,añadirElem ento(s2,s))
• tablaVacía. Construye una tabla de símbolos vacía.
Esto establece que si se realizan dos sumas en la tabla
• añadirElemento. Añade un sím bolo a una tabla de de símbolos y se intenta añadir el m ismo elem ento dos
símbolos que ya exista. veces, solo será equivalente a la suma de uno de los dos
• extraerElemento. Extrae un símbolo de una tabla de elementos. Sin embargo, si los elementos difieren, enton
símbolos que ya exista. ces el efecto será el de añadirlos en un orden diferente.
• estáenTabla? Será verdadero si un símbolo está en La definición de extraerElemento es
una tabla y falso si no está. extraerElem ento(s l.tablaVacía) = tablavacía
• unir. Une el contenido de dos tablas de símbolos. extraerElemento (si, añadirElemento (s2,s)) =
• común. Toma dos tablas de símbolos y retorna con si s 1 = s2 entonces extraerElemento (s l,s)
los elementos comunes de cada tabla. o si no añadirElemento (s2,extraerElemento (sl,s))
• esParteDe. Retorna verdadero si una tabla de sím Esta definición establece que si se intenta extraer un
bolos está en otra tabla de símbolos. elem ento de una tabla vacía se elaborará la construc
ción de tabla vacía, y que cuando se extrae un elem en
• eslgual. Retorna verdadero si una tabla de símbolos to s i de una tabla que contiene un objeto s2, entonces
es igual a otra tabla de símbolos.
si s 1 y s2 son idénticos el efecto es el de extraer el obje
• estáVacía. Retorna verdadero si la tabla de símbolos to s i , y si no son iguales el efecto es el de dejar s2 y
está vacía. extraer el objeto s l .
A continuación se m uestra la definición de las firmas La definición de estáenTabla! es
de los operadores estáenTabla?(sl, tablavacía) = falso
estáenTabla(sl, añadirElem ento(s2,s)) =
T a b la d e n o m b r e s
si sl = s2 entonces es verdadero o si no está
Clases: tablaSímbolos(Z)con = en Tabla? (s l,s)
Operadores: En esta definición se establece que un elem ento no
tablavacía: — tablaSímbolos(Z) puede ser m iem bro de una tabla de sím bolos vacía y
añadirElemento: Z x tablaSímbolos (Z) —> . que el resultado de aplicar estaenTablal y sl auna tabla
tablaSímbolos (Z) que esté formada de sl y s2 devolverá un valor verda
dero si sl es igual a s2\ si no son iguales hay que apli
extraerElemento: Z x tablaSímbolos (Z) —» car estáenTabla? a s i .
tablaSímbolos (Z) A continuación se m uestra la definición de unir:
estáenTabla?: Z x tablaSímbolos (Z) —» unir(s, tablavacía) = s
Booleano unir(s, añadirElem ento(sl,t)) =
unir: tablaSímbolos (Z) x añadirElem ento(sl ,unir (s,t))
tablaSímbolos (Z) —>
Aquí se establece que uniendo una tabla vacía y una
tablaSímbolos (Z) tabla s da com o resultado la construcción de una tabla
común: tablaSímbolos (Z) x vacía s, y que el efecto de unir dos tablas en donde una
tablaSímbolos (Z) —> de ellas tenga el sím bolo s l es equivalente a añadir sl
tablaSímbolos Z) al resultado de unir dos tablas.
esParteDe?: tablaSímbolos (Z) x A continuación se m uestra la definición de común:
tablaSímbolos (Z) —» Booleano común(s, tablavacía) = tablavacía
com ún(s,añadirElem ento(sl,t)) = si estáenT abla?(sl,s)
tablaSímbolos (Z) x
entonces añadirElem ento(sl,
tablaSímbolos (Z) —» Booleano
común(s,t))
estáVacía?: tablaSímbolos (Z) -» Booleano o sino común(s,t)
Esta definición establece que la tabla com puesta ele
Todas las definiciones se pueden entender al margen los elem entos com unes de la tabla vacía y cualquier
de la línea siguiente otra tabla es siem pre la tabla vacía. La segunda línea
afirm a que, si se unen dos tablas, entonces, si hay un
Clases: tablaSímbolos (Z) con =
www.FreeLibros.org
elem ento com ún s l , este se añade al conjunto com ún,
la cual establece que los objetos del tipo Z se asociarán o de lo contrario se form a el conjunto com ún de dos
con un operador de igualdad. conjuntos. .
45 1
INGE NIE RÍA DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
L a definición de e sP a rte D e l es la siguiente: esParteD e?: Z x tablaS ím bolos (Z) x

esParteD e?(tabla Vacía,s) = verdadero tablaS ím bolos (Z) —> B ooleana
esParteD e?(añadirE lem ento(s l,s)) = eslgual?: Z x tablaS ím bolos (Z) x
si estáenTabla? (s l,t) entonces esParteD e?(s,t) tablaS ím bolos (Z) —> B ooleana
o si no es falso
estáV acía?: tablaS ím bolos (Z) —>B ooleana
E sta d e fin ic ió n estab lece que la ta b la de sím bolos
añadirE lem ento(s2,añadirE lem ento(s l,s)) =
vacía siem pre es parte de cualq u ier tabla de sím bolos.
si s i = s2 entonces añadirE lem ento(s2,s)
L a segunda línea establece que si la tabla t contiene un
o si no a ñ a d irE lem en to (sl, añadirE lem ento(s2,s))
elem ento en s entonces se aplica e sP a rte d e l p ara ver si
s es u n a subtabla de t. extraerE lem ento(s 1, ta b lav a cía) = ta b lav acía
A co ntinuación se p resenta la definición de e s lg u a ll: extraerE lem ento(s 1, añadirE lem ento(s2,s)) =
si s i = s 2 entonces extraerE Iem en to (sl,s)
eslg u al?(s,t) = esP arteD e?(s,t) a esP artede?(t,s)
o si no añadirE lem entos(s2,extraerE lem ento(s l,s))
E sta d efinición establece que las tablas de sím bolos estáen T ab la?(sl, tab la v ac ía) = falso
son iguales si están d en tro u n a de otra. L a definición estáen T ab la?(sl, añadirE lem ento(s 2 ,s)) =
final de estáV acíal es así de sencilla: si s 1 = s 2 entonces verdadero
está V acía?(tabla Vacía) = verdadero o s in o e stáen T ab la?(sl,s)
estáV acía(añadirE lem ento(s l,t)) = falso
unir(s, ta b lav a cía) = s
A quí se establece sim plem ente que la tabla v acía está unir(s, añadirE lem ento(s l,s)) =
vacía y que una tabla que co n tien ep o r lo m enos un obje añ ad irE le m en to (sl, unir(s,t))
to no estará vacía. com ún(s, tab la v ac ía) = tab lav acía
Por tanto, la d escripción com pleta de la tabla de sím com ún(s, añadirE lem ento(s l,t)) =
bolo s es la siguiente: si estáenT abla(s 1 ,s)
entonces añadirE lem ento(s 1, com ún(s,t))
T a b la d e n o m b r e s
o sino com ún (s,t)
Clases: tablaSím bolos(Z ) con =
esP arteD e?(tablaV acía,s) = verdadero
O peradores: esP arteD e?(añadirE lem ento(s l,s),t) =
tablavacía: —> tablaS ím bolos(Z ) si estáenT abla?(s l,t) entonces esP arte D e?(s,t)
o si no falso
añadirTabla: Z x tablaS ím bolos (Z) —>
tablaS ím bolos (Z) eslgual?(s,t) = esP arteD e?(s,t) a esParteD e?(t,s)
extraerE lem ento: Z x tablaS ím bolos (Z) —> estáV acía?(tablaV acía) = verdadero
tablaS ím bolos (Z ) estáV acía?(añadirE lem ento(s l,s) = falso
estáenTabla?: Z x tablaSím bolos (Z) —>
B ooleana
Tales especificaciones son bastante difíciles de cons
unir: tablaS ím bolos (Z) x truir, y el problem a principal es qúe no se sabe cuándo
tablaS ím bolos (Z) —> hay que p arar de añadir sentencias que relaten opera
tablaS ím bolos (Z ) ciones y que tienden a ser m ucho m ás prolongadas que
com ún: tablaS ím bolos (Z ) x sus eq u iv alen tes b asad o s en el estad o . Sin em bargo,
tablaS ím bolos (Z) —> m atem áticam ente son m ás puras y m ás fáciles para lle
tablaS ím bolos (Z ) var a cabo el razonam iento.
L as d os seccio n es an terio res h an d escrito Z y la d e ri ta les co m o Z p ara a c o m p a ñ a r la co n cu rren cia, no se

vació n o rien tad a a o b jeto s O b je c tZ . El principal p ro ha h ech o co n m u c h o é x ito y a que n u n ca se d iseñ aro n
b lem a de e sta s e s p e c ific a c io n e s y de las n o ta c io n e s realm en te con esta idea en la cabeza. D onde sí se ha
m a te m á tic a s sim ilares es que no tie n e n las fu n cio n es h ech o co n é x ito h a sido en el d e sa rro llo de n o ta c io
para e sp e c ific ar los sistem as c o n c u rre n tes: aq uellos nes form ales de p ro p ó sito esp ecial para co n cu rren cia,
donde se ejecutan un serie de p rocesos al m ism o tie m y el p ro p ó sito de e sta secció n es d e scrib ir una de las
www.FreeLibros.org
po -y- frecuentem ente con un grado elevado de c o m u m ás conocidas: P S I (P ro c e so s S ecu en ciales in te rc o
n ic a c ió n e n tre e sto s procesos — . A u n q u e se h a n m u n ic a d o s) [C S P (C o m m u n ic a tin g S eq u e n tia l Pro-
rea liz a d o m uchos esfu erzo s p o r m o d ific a r n o tacio n es cesses)].
452
P S I f u e d e s a r r o lla d o e n O x f o r d p o r e l c ie n t í f ic o to r ia m e n t e . E J E C U T A R e s u n p r o c e s o q u e p u e d e e n c a r
in f o r m á t ic o in g lé s T o n y H o a r e . L a id e a p r in c ip a l q u e g a rs e d e c u a lq u ie r s u c e s o e n s u a lfa b e to . A l ig u a l q u e
r e s p a ld a e s ta n o t a c ió n e s q u e s e p u e d e v e r u n s is t e P A R A R e s u n p r o c e s o n o d e s e a d o e in d ic a q u e h a h a b i
m a c o m o u n c o n j u n t o d e p r o c e s o s s e c u e n c ia le s ( p r o d o u n b lo q u e o .
g r a m a s s im p le s n o c o n c u r r e n te s ) q u e s e e je c u ta n y P a r a p o d e r h a c e m o s u n a id e a d e la u t iliz a c ió n d e P S I
se c o m u n ic a n c o n o t r o s p r o c e s o s d e m a n e r a a u tó n o e n la e s p e c if ic a c ió n d e p r o c e s o s e s p e c if ic a r e m o s a lg u
m a . H o a re d is e ñ ó P S I p a r a d e s c r ib ir ta n to e l d e s a n o s s is t e m a s m u y s im p le s . E l p r i m e r o e s u n s is t e m a q u e
r r o l lo d e e s ta s n o ta c io n e s c o m o la c o m u n ic a c ió n q u e se c o m p o n e d e u n p ro c e s o C . U n a v e z q u e s e h a a c ti
tie n e lu g a r e n tr e e lla s . D e la m is m a m a n e r a q u e d e s a v a d o e s te p r o c e s o , la v á lv u la d e u n r e a c to r q u í m ic o s e
r r o l ló e s ta n o t a c ió n , t a m b ié n d e s a r r o lló u n a s e r ie d e c e rra rá y se p a ra rá .
le y e s a lg e b r a ic a s q u e p e r m it e n l l e v a r a c a b o u n r a z o
aC = (c e rra r}
n a m ie n to : p o r e je m p lo , s u s le y e s p e r m it e n a l d is e
C = (c e r r a r —> P A R A R )
ñ a d o r d e m o s tr a r q u e e l p r o c e s o P ,n o s e b lo q u e a r á
e s p e r a n d o la a c c ió n d e o t r o p r o c e s o P , q u e e s tá a s u L a p r im e r a lí n e a d e f in e e l a lfa b e to d e l p r o c e s o c o m o
v e z e s p e r a n d o a q u e e l p r o c e s o P , lle v e a c a b o a lg u u n p ro c e s o q u e s e c o m p o n e d e u n s u c e s o , y la s e g u n d a
n a o t r a a c c ió n . lí n e a e s ta b le c e q u e e l p r o c e s o C s e e n c a r g a r á d e c e r r a r
L a n o t a c ió n P S I e s m u y s im p le e n c o m p a r a c ió n c o n y e n to n c e s p a ra r.
u n a n o ta c ió n Z u O b je c t Z ; d e p e n d e d e l c o n c e p to d e u n E s ta e s u n a e s p e c if ic a c ió n m u y s im p le y a lg o ir r e a l.
s u c e s o . U n s u c e s o e s a lg o q u e s e p u e d e o b s e rv a r, e s a tó D e f in a m o s a h o r a o t r o p r o c e s o C , q u e a b r ir á la v á lv u la ,
m ic o e in s t a n t á n e o , lo q u e s ig n if ic a q u e u n s u c e s o , p o r la c e r r a r á y q u e c o m e n z a r á o t r a v e z a c o m p o r ta r s e e n t o n
e je m p lo , n o s e p u e d e in t e r r u m p ir , s in o q u e s e c o m p le c e s c o m o C ,.
ta r á , in d e p e n d ie n t e m e n t e d e l o q u e e s té o c u r r ie n d o e n aC , = { a b r ir , c e r r a r }
u n s is t e m a . L a c o l e c c i ó n d e s u c e s o s a s o c ia d o s c o n a l g ú n
C ,= ( a b r i r - ) c e r r a r —> C ,)
p r o c e s o P s e c o n o c e c o m o e l a lfa b e to d e P y s e e s c r ib e
c o m o o (P . E je m p lo s t í p ic o s d e s u c e s o s s o n e l e n c e n d i U n a d e f in ic ió n a lt e r n a t iv a d o n d e s e d e fin a n d o s p r o
d o d e la v á lv u la d e u n c o n tr o la d o r in d u s tr ia l, la a c tu a c e s o s s e ría
liz a c ió n d e u n a v a r ia b le g lo b a l d e u n p r o g r a m a o la aC , = { a b r ir }
t r a n s f e r e n c ia d e d a to s a o t r a c o m p u ta d o r a . L o s p r o c e C, = • ( a b r ir á C J
sos s e d e f i n e n r e c u r s i v a m e n t e e n f u n c i ó n d e l o s s u c e
s o s . P o r e je m p lo Y
(esP) aC 2= (c e rra r)
C, = (c e rr a r —> C ,)
d e s c r ib e e l h e c h o d e q u e u n p r o c e s o e s tá in v o lu c r a d o
e n e l s u c e s o e d e n tr o d e a P y e n to n c e s se c o m p o r ta A q u í , e l p r im e r p r o c e s o C j tie n e e l a lfa b e to { a b r i r ) ,
c o m o P . E n P S I s e p u e d e n a n id a r d e f in ic io n e s d e p r o s e e n c a r g a d e u n s o lo s u c e s o q u e a p a r e c e d e n t r o d e l a lf a
c e s o s : p o r e je m p lo , P s e p u e d e d e f in ir e n f u n c ió n d e b e t o y q u e s e c o m p o r t a e n t o n c e s c o m o e l p r o c e s o C ,.
o tro p ro c e s o P , c o m o E 1 C , t a m b ié n p o s e e u n a lfa b e to d e u n s o lo s u c e s o , s e
e n c a r g a d e e s te s u c e s o y s e c o m p o r t a e n to n c e s c o m o
( e - > (e a - > /> ,) )
C , . U n o b s e r v a d o r a je n o a l t e m a q u e v e a e l s is t e m a
e n d o n d e o c u r r e e l s u c e s o e, y e l p r o c e s o s e c o m p o r ta e x p r e s a d o d e e s ta f o r m a v e r í a la s ig u ie n te s u c e s ió n d e
c o m o e l p ro c e s o P ,. sucesos:
L a fu n c io n e s q u e s e a c a b a n d e d e s c r ib ir n o s o n m u y
a b r i r , c e r r a r , a b r i r , c e r r a r . . ..
ú t ile s , y a q u e n o p r o p o r c i o n a n n i n g u n a o p c i ó n , p o r e j e m
p lo , p a ra e l h e c h o d e q u e u n p ro c e s o se p u e d a e n c a rg a r E s ta s u c e s ió n s e c o n o c e c o m o r a s tr e o d e l p r o c e s o .
d e d o s s u c e s o s . E l o p e r a d o r d e o p c i ó n | p e r m i t e q u e la s A c o n tin u a c ió n , s e m u e s tr a o t r o e je m p lo d e e s p e c if ic a
e s p e c if ic a c io n e s P S I in c lu y a n e l e le m e n to d e d e t e r m i- c ió n P S I. E s ta re p r e s e n ta u n r o b o t q u e s e p u e d e e n c a r
n is m o . P o r e je m p lo , la s ig u ie n te e s p e c if ic a c ió n d e fin e g a r d e d o s s u c e s o s q u e se c o rre s p o n d e n c o n u n re tro c e s o
un p r o c e s o P q u e p e r m i t e u n a o p c i ó n . o u n a v a n c e e n l a lí n e a . S e p u e d e e s t a b l e c e r l a d e f i n i
c ió n d e l c a m in o i n f i n i t o d e u n r o b o t s in p u n to s f in a le s
P = ( e , — ) P { I e , — » P 2)
e n e l r e c o r r id o d e la s ig u ie n te m a n e r a
A q u í e l p r o c e s o P s e d e f in e c o m o u n p r o c e s o c a p a z
a R O B O T = {a v a n c e ,re tr o c e s o }
d e e n c a r g a r s e d e d o s s u c e s o s e , o e,. S i s e d a e l p r i m e
R O B O T = (a v a n c e -) R O B O T ] re tro c e s o s R O B O T )
r o , e l p ro c e s o se c o m p o r ta r á c o m o P ,, y s i a p a re c e e l
s e g u n d o , s e c o m p o r t a r á c o m o P ,. A q u í e l ro b o t se p u e d e e n c a rg a r d e a v a n z a r o re tro
E n P S I e x is t e u n a s e r ie d e p r o c e s o s e s tá n d a r . P A R A R c e d e r y c o m p o r ta r s e c o m o u n r o b o t , p u d ie n d o a v a n z a r
e s e l p r o c e s o q u e in d ic a q u e e l s is t e m a h a t e r m in a d o d e y r e t r o c e d e r , y a s í s u c e s iv a m e n te . S u p o n g a m o s o t r a v e z
www.FreeLibros.org
m a n e r a a n o r m a l, e n u n e s ta d o n o d e s e a d o c o m o e s e l q u e la e s p e c if ic a c ió n e s r e a l in t r o d u c ie n d o a lg u n a s o tr a s
b lo q u e o . S A L T A R e s u n p r o c e s o q u e t e r m in a s a tis fa c fu n c io n e s P S I. L a c o m p lic a c ió n e s q u e la p is ta s o b r e la
453
ING EN IE RÍA DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
q u e v ia j a e l r o b o t s e c o m p o n e d e c ie n to s d e m o v im ie n t o s n o r m a s o b r e la c o m u n ic a c ió n y la s in c r o n iz a c ió n e s q u e
c o n a v a n c e s y r e tro c e s o s q u e d e n o ta n e s te m o v im ie n c u a n d o d o s p r o c e s o s s e e s tá n e je c u ta n d o e n p a r a le lo , d o n
t o . S u p o n g a m o s t a m b i é n q u e e n e s t a p i s t a e l r o b o t a r ra n d e tie n e n a lg u n o s s u c e s o s e n c o m ú n , d e b e n d e e je c u ta r
c a d e la p o s ic ió n 1 . A c o n tin u a c ió n se m u e s tr a la e s e s u c e s o s im u lt á n e a m e n t e . T o m e m o s c o m o e j e m p lo u n
d e f in ic ió n d e e s te R O B O T ,: s i s t e m a b a s t a n t e s i m p l e y r e a l q u e e n c i e n d e y a p a g a la s
lu c e s y q u e s e b a s a e n u n e je m p lo s im ila r a l d e [ H I N 9 5 ] .
aR O BO Tc { a v a n c e ,re tro c e s o }
L a s d e f in ic io n e s d e lo s d o s p r o c e s o s d e e s te s is t e m a s o n :
ROBOT R,
R, (avance —» R .) oL U Z , = { e n c e n d id a ,a p a g a d a ]
R, (avance —>R ¡+¡ I retroceso —> R , ,) LU Z, = ( e n c e n d id a — > e n c e n d id a — » P A R A R
(¿ < 100 a i > 1) I a p a g a d a —> a p a g a d a —> P A R A R )
R„ (re tro c e so —» R J a L U Z 2 = { e n c e n d id a , a p a g a d a )
LU Z, = ( e n c e n d i d a —> a p a g a d a -+ L U Z ,)
A q u í el r o b o t r e p r e s e n t a u n p r o c e s o c o n l o s m i s m o s
d o s s u c e s o s d e l a lf a b e t o c o m o e l r o b o t a n t e r io r . S in A m b o s p r o c e s o s tie n e n e l m is m o a lfa b e to . E l p r im e r
e m b a r g o , l a e s p e c i f i c a c i ó n d e su i m p l i c a c i ó n e n e s t o s p r o c e s o L U Z , , o b ie n e n c ie n d e la lu z y la v u e lv e a e n c e n
s u c e s o s e s m á s c o m p le ja . L a s e g u n d a lí n e a e s ta b le c e q u e d e r d e n u e v o ( h a y q u e r e c o r d a r q u e e s p o s ib le q u e o tr o s
e l r o b o t a r r a n c a r á e n u n a p o s ic ió n in ic ia l y se c o m p o r p r o c e s o s h a y a n a p a g a d o e l s is t e m a e n tr e m e d ia s , y se
ta r á d e la m is m a m a n e r a q u e c o n e l p r o c e s o R , e l c u a l h a a v e r ia d o (P A R A R e s u n e s ta d o n o d e s e a d o ), o b ie n
r e p r e s e n t a su p o s i c i ó n e n e l p r i m e r r e c u a d r o . L a t e r c e la a p a g a u n a v e z , y u n a v e z m á s . E l p r o c e s o LUZ,
r a lí n e a e s ta b le c e q u e e l p r o c e s o R , s o lo s e p u e d e e n c a r e n c ie n d e la lu z y la a p a g a , y a c o n t in u a c ió n e m p ie z a a
g a r d e l s u c e s o d e a v a n c e y a q u e se e n c u e n tra e n e l p u n to c o m p o r t a r s e d e n u e v o c o m o LUZ,. L o s d o s p r o c e s o s e n
f i n a l . L a c u a r t a lí n e a d e f in e la s e r ie d e p r o c e s o s d e s d e p a r a le lo se d e n o ta n m e d ia n te :
R, a / ? „ . A q u í s e d e f i n e e l h e c h o d e q u e e n c u a l q u i e r p u n - L U Z , II L U Z ,
t o e l r o b o t s e p u e d e a v a n z a r o r e t r o c e d e r . L a lí n e a f i n a l
¿ C u á l e s e l e fe c to d e e je c u ta r e s to s p r o c e s o s e n p a ra
e s p e c if ic a lo q u e s u c e d e c u a n d o e l r o b o t h a a lc a n z a d o
le lo ? E n u n a in tr o d u c c ió n c o m o e s e s ta n o se p u e d e
e l f i n a l d e l r e c o r r i d o : s o lo p u e d e r e t r o c e d e r .
e n t r a r e n m u c h o d e ta lle . S in e m b a r g o , s e p u e d e d a r u n a
E s ta e s la m a n e r a e n q u e f u n c io n a n lo s p r o c e s o s e n
id e a d e l r a z o n a m ie n t o q u e s e p u e d e a p lic a r a d ic h a
P SI. En s i s t e m a s r e a l e s e x i s t i r á u n a s e r i e d e p r o c e s o s
e x p r e s ió n . S e r e c o r d a r á q u e c u a n d o s e in t r o d u jo P S I se
e je c u tá n d o s e c o n c u r r e n te m e n te y c o m u n ic á n d o s e c o n
a f ir m ó q u e n o s o lo c o n s is te e n u n a n o t a c ió n p a r a e s p e
o tr o s , c o m o s e m u e s tr a a c o n tin u a c ió n m e d ia n te a lg u
c if ic a r lo s p r o c e s o s c o n c u r r e n te s , s in o q u e ta m b ié n c o n
n o s e je m p lo s :
t ie n e u n a s e r ie d e n o r m a s q u e p e r m it e n r a z o n a r a c e r c a
• E n u n s is t e m a c lie n t e / s e r v id o r , u n s o lo s e r v id o r e n d e la s e x p r e s i o n e s d e p r o c e s o s c o m p l e j o s y , p o r e j e m
e je c u c ió n c o m o p r o c e s o e s ta r á e n c o m u n ic a c ió n c o n p lo , d e te r m in a r s i c u a lq u ie r s u c e s o n e fa s to c o m o u n b lo
v a r io s c lie n te s q u e ig u a lm e n te s e e je c u ta r á n c o m o q u e o a p a r e c e r á d e n t r o d e l s is t e m a e s p e c if ic a d o e n P S I.
p ro c e s o s . P a ra p o d e r v e r lo q u e o c u r r e m e r e c e la p e n a a p lic a r a lg u
• E n s is t e m a s d e t i e m p o r e a l, q u e c o n t r o la n u n r e a c n a s d e la s n o r m a s q u e d e s a r r o l l ó H o a r e p a r a P S I . R e c o r
t o r q u í m ic o , e x is t ir á n p r o c e s o s d e s u p e r v is ió n d e la d e m o s q u e s e in t e n t a a v e r ig u a r c u á l e s e l p r o c e s o q u e
te m p e r a tu r a d e lo s r e a c to r e s q u e s e c o m u n ic a r á n c o n s e h a d e f i n i d o m e d i a n t e l a e j e c u c i ó n e n p a r a l e l o d e lo s
l o s p r o c e s o s q u e a b r e n y c i e r r a n la s v á l v u l a s d e e s t o s p r o c e s o s L U Z , y LUZ,. E s t a e x p r e s i ó n e s e q u i v a l e n t e a:
re a c to re s .
L U Z t ( e n c e n d id o — > e n c e n d id o - + P A R A R
• E n u n s i s t e m a d e c o n t r o l d e t r á f i c o a é r e o , l a fu n c io = I a p a g a d o — » a p a g a d o —> P A R A R )
n a lid a d d e l r a d a r se p o d r ía im p le m e n t a r c o m o p r o
LU Z, = ( e n c e n d id o - ^ a p a g a d o —> L U Z , )
c e s o s q u e se c o m u n ic a n c o n p r o c e s o s q u e lle v a n a
c a b o la s t a r e a s d e v i s u a l i z a r e n p a n t a l l a la s p o s i c i o U n a d e la s n o r m a s d e H o a r e e s t a b l e c e q u e
n e s d e la s a e r o n a v e s .
( e - > P ) \ \ ( e —> Q ) = e —> ( P W Q )
D e a q u í q u e e x is t a la n e c e s id a d d e r e p r e s e n t a r e n P S I .E s to n o s p e r m it e a m p lia r la e x p r e s ió n q u e in v o lu c r a
la e je c u c ió n e n p a r a le lo d e lo s p r o c e s o s . T a m b ié n e x is a L U Z , y L U Z , con
te la n e c e s id a d d e a lg ú n m e d io c o n e l q u e s e p r o d u z c a
( e n c e n d i d o — > ( ( e n c e n d i d o - ^ P A R A R ) II ( a p a g a d o — >
la c o m u n ic a c ió n y la s in c r o n iz a c ió n e n tr e e s to s p r o c e
L U Z 2) ) )
sos. E l o p e r a d o r q u e e s p e c i f i c a l a e j e c u c i ó n e n p a r a l e
l o e n P S I e s II. P o r t a n t o , e l p r o c e s o P q u e r e p r e s e n t a l a E s ta e x p r e s ió n s e p u e d e s im p lif ic a r a u n m á s u t i l i
e j e c u c i ó n e n p a r a l e l o d e l o s p r o c e s o s d e P , y P, s e d e f i z a n d o o t r a d e la s n o r m a s d e H o a r e a l a e x p r e s i ó n
ne com o
( e n c e n d id o - + P A R A R )
P =P, \ \ P,
lo c u a l s ig n if ic a q u e la e je c u c ió n e n p a r a le lo d e lo s d o s
www.FreeLibros.org
L a s in c r o n iz a c ió n e n t r e lo s p r o c e s o s s e lo g r a m e d ia n p r o c e s o s e s e q u iv a le n t e a u n a lu z q u e s e e n c ie n d e y
te p r o c e s o s c o n a lg ú n s o la p a m ie n t o e n s u s a lfa b e to s . L a e n to n c e s se p a ra e n u n e s ta d o d e b lo q u e o n o d e s e a d o .
454
H asta ahora, se h an visto procesos que cooperan con ne el proceso PROD,, el cual equipara este p ro ceso con
la sincronización m ediante el hech o de que tienen alfa A , sin entradas esperando. La segunda lín e a estab lece
betos sim ilares o que se solapan. E n los sistem as reales que cu an d o el proceso recibe un v alo r d e e n tra d a x se
tam bién e x istirá la n e c e sid a d de que los p ro c eso s se com porta com o el proceso con u n v alor x alm acenado.
com uniquen con datos. PS I es un m étodo uniform e para L a tercera línea establece que cu an d o u n p ro c e so con
la co m unicación de datos: se trata sim plem ente com o un v alor alm acenado recibe un v alor y entonces se c o m
un suceso en donde el suceso nom C anal.val indica que po rta co m o un proceso con dos valores alm acenados.
ha ocurrido un suceso que se corresponde con la co m u L a últim a línea establece que un proceso co n d o s v alo
nicación del v alo r va l a través de un canal nom C anal. res alm acenados em itirá el producto de esto s v alo res,
PSI contiene u n dispositivo notacional sim ilar al de Z alm ac en ará el últim o v alor y en to n ces se c o m p o rta rá
para distin g u ir en tre la entrad a y la salida; para distin com o A con ese valo r alm acenado, de m a n e ra que, p o r
guir la prim era se introduce el signo de interrogación, ejem p lo , si aparece otro v alor se m u ltip lica rá p o r ese
m ientras que para distin g u ir la segunda se utiliza el sig v a lo r y se e m itirá p o r el canal de salida. A s í p u es, la
no de exclam ación. especificación anterior se co m p o rta co m o u n p ro c e so
A c o n tin u ació n , se m u e stra un ejem p lo b asa d o en en donde se recib e u n a su cesió n d e e n te ro s y lle v a a
[HIN95], en donde se representa la especificación de un cabo la m ultiplicación de los valores.
proceso que to m a d os enteros y form a el producto. S e puede decir entonces que e sta es u n a definición
breve de PSI —al igual que todos los m étodos fo rm ales
PRO/), = A ()
incluye tam bién una notación m atem ática y las n orm as
= ( e n ? x ^ > A ,„)
para el ra z o n a m ie n to -. A unque en las descripciones de
A ( l) = (en) y A*,>) Z y O bject Z no se han exam inado las norm as y se h a
A*.y) = (fu e r a ! { x A ,„)
co n cen trad o en el fo rm alism o to d a v ía co n tie n en fu n
A p rim era v ista esto parece m uy com plicado, por eso ciones sustanciales para razo n ar sobre las propiedades
m erece la pena describirlo línea a línea. L a p rim era defi de un sistem a.
25.9 LOS DIEZ MANDAMIENTOS DE LOS M ÉTQ DQ S FORMALES
La decisión de h acer uso de los m étodos form ales en el seguridad serán nuestras prim eras opciones, e irán
m undo real n o debe de adoptarse a la ligera. B ow en y seguidos p o r aquellos co m p o n en tes cuyo fallo no
H inchley [B O W 95] h an a c u ñ a d o « lo s d ie z m a n d a se p u eda adm itir (por razones de negocios).
mientos de los m étodos form ales» ,co m o guía para aque III. Estim arás los costes. L os m étodos form ales tienen
llos que estén a pun to de em barcarse en este im portante unos costes de arranque considerables. El e n tre n a
enfoque de la ingeniería del softw are5. m iento del personal, la adquisición de herram ien
ta s de ap o y o y la u tiliz a c ió n de a se so re s b a jo
contrato dan lugar a unos costes elevados en la p ri
m era ocasión. E stos costes deben tenerse en cuenta
l a decisión de utilizar métodos formales no debería
cu an d o se esté considerando el beneficio obtenido
tomarse a lo ligera. Siga estos mandamientos»
frente a esa inversión asociada a los m étodos fo r
y asegúrese de que todo el mundo haya recibida
lo formación adecuada.
m ales.
IV. Poseerás un experto en m étodos form ales a tu
I. Seleccionarás la notación adecuada. C on objeto disposición. El entrenam iento de expertos y la ase
de seleccionar eficientem ente dentro de la am plia soría continua son esenciales para el éx ito cuando
gam a de lenguajes de especificación fo rm al e x is se utilizan los m étodos form ales p o r prim era vez.
tente, el ingeniero del softw are d eb erá considerar V. No abandonarás tus m étodos form ales de desa
el v o c a b u la rio del len g u aje, el tip o de aplicació n rrollo. E s posible, y en m uchos casos resu lta d esea
que h ay a que especificar y el grado de utilización ble, integrar los m étodos form ales con los m étodos
del lenguaje. convencionales y/o con m étodos orientados a obje
II. Formalizarás, pero no de más. E n general, resulta tos (C apítulos 12 y 21). C ada uno de estos m étodos
necesario aplicar los m étodos form ales a todos los posee sus ventajas y sus inconvenientes. U na co m
asp ecto s de los sistem as de c ie rta en v e rg a d u ra. b in ac ió n de am bos, ap licad a de fo rm a adecuada,
A q u ello s c o m p o n e n te s que sean c rític o s p a ra la puede p roducir excelentes resultados6.
www.FreeLibros.org
5 Esta descripción e s una versión sumamente abreviada de [BOW95] 6 La ingeniería del software de la sala limpia (Capítulo26) e s un ejem
plo integrado que hace uso de los m étodos form ales y de una nota
ción m ás convencional para el desarrollo..
455
u n a g a r a n t ía d e c o r r e c c ió n . E s p o s ib le (o c o m o
a lg u n o s p r o b a b le m e n te d ir í a n ) q u e e l s is t e m a fin a l,
Referencia J É W a u n c u a n d o s e h a y a d e s a r r o lla d o e m p le a n d o m é to
d o s f o r m a le s , s ig a c o n t e n ie n d o p e q u e ñ a s o m is io
Información útil sobre los métodos formales se puede
n e s , e r r o r e s d e m e n o r im p o r t a n c ia y o t r o s a t r ib u to s
obtener en: www.cIcam/users/mghlOOl
q u e n o s a tis fa g a n n u e s tr a s e x p e c ta tiv a s .
VI. D ocum entarás suficientem ente. L o s m é t o d o s IX . Comprobarás, com probarás y volverás a com
f o r m a le s p r o p o r c io n a n u n m é t o d o c o n c is o , s in probar. L a i m p o r t a n c i a d e l a c o m p r o b a c i ó n d e l
a m b ig ü e d a d e s y c o n s is te n te p a r a d o c u m e n t a r lo s s o f t w a r e s e h a d e s c r it o e n lo s C a p í t u lo s 1 7 , 1 8
r e q u i s i t o s d e l s is t e m a . S i n e m b a r g o , s e r e c o m i e n d a y 2 3 . L o s m é to d o s f o r m a le s n o a b s u e lv e n a l in g e
q u e s e a d ju n te u n c o m e n t a r io e n le n g u a je n a t u r a l n ie r o d e l s o f t w a r e d e la n e c e s id a d d e ll e v a r a
a la e s p e c if ic a c ió n f o r m a l, p a r a q u e s ir v a c o m o c a b o u n a s c o m p r o b a c io n e s e x h a u s t iv a s y b ie n
m e c a n is m o p a r a r e f o r z a r la c o m p r e n s ió n d e l s is p la n e a d a s .
te m a p o r p a r te d e lo s le c to r e s . X. Reutilizarás cuanto puedas. A l a l a r g a , l a ú n i c a
VII. No com prom eterás los estándares de calidad. f o r m a r a c io n a l d e r e d u c ir lo s c o s te s d e l s o ftw a r e
« L o s m é to d o s fo r m a le s n o tie n e n n a d a d e m á g ic o » y d e in c r e m e n ta r la c a lid a d d e l s o ftw a r e p a s a p o r
[ B O W 9 4 ] , y , p o r e s t a r a z ó n , la s d e m á s a c t i v i d a la r e u t iliz a c ió n ( C a p í tu lo 2 7 ). L o s m é to d o s f o r
d e s d e SQA ( C a p í t u l o 8) d e b e n d e s e g u i r a p l i m a l e s n o m o d i f i c a n e s t a r e a l i d a d . D e h e c h o , qui
c á n d o s e c u a n d o s e d e s a r r o l l e n s is t e m a s . z á s s u c e d a q u e l o s m é t o d o s f o r m a l e s s e a n un
VIII. No serás dogm ático. E l i n g e n i e r o d e s o f t w a r e e n fo q u e a d e c u a d o c u a n d o e s p r e c is o c re a r c o m
d e b e r e c o n o c e r q u e lo s m é to d o s fo r m a le s n o s o n p o n e n te s p a r a b ib lio te c a s r e u tiliz a b le s .
_¿5U0 M ÉTQPG & FORM ALES: EL FUTURO
A u n c u a n d o la s t é c n i c a s d e e s p e c i f i c a c i ó n f o r m a l , c o n P e r o s ig u e n e x is t ie n d o p r o b le m a s . L a e s p e c if ic a c ió n
fu n d a m e n to m a te m á tic o , to d a v ía n o se u t iliz a n c o n f o r m a l s e c e n t r a f u n d a m e n t a l m e n t e e n la s f u n c i o n e s y
d e m a s ia d a f r e c u e n c ia e n la in d u s t r ia ) é s t a s o f r e c e n c ie r lo s d a to s . L a t e m p o r iz a c ió n , e l c o n t r o l y lo s a s p e c to s d e
t a m e n t e u n a s v e n t a j a s s u b s t a n c i a l e s c o n r e s p e c t o a la s c o m p o r ta m ie n to d e l p r o b le m a s o n m á s d if í c ile s d e re p re
té c n ic a s m e n o s f o r m a le s . L is k o v y B e r s in s [ L I S 8 6 ] s e n ta r. A d e m á s , e x is t e n c ie r ta s p a r te s d e l p r o b le m a ( p o r
r e s u m e n e s to e n la m a n e r a s ig u ie n te : e j e m p l o , la s i n t e r f a c e s h o m b r e - m á q u i n a ) q u e s e e s p e c i
f i c a n m e j o r e m p l e a n d o t é c n i c a s g r á f i c a s . P o r ú l t i m o , la
Las especificaciones formales se pueden estudiar mate
máticamente, mientras que las especificaciones informales e s p e c if ic a c ió n m e d ia n te m é to d o s fo r m a le s e s m á s d if í
no pueden estudiarse de esta manera. Por ejemplo, se puede c i l d e a p r e n d e r q u e o t r o s m é to d o s d e a n á lis is q u e s e p r e
demostrar que un programa correcto satisface sus especifi s e n ta n e n e s te li b r o y r e p r e s e n ta « u n c h o q u e c u lt u r a l) )
caciones, o bien se puede demostrar que dos conjuntos alter s ig n if ic a t iv o p a r a a lg u n o s e s p e c ia lis ta s d e l s o ftw a r e . P o r
nativos de especificacionesson equivalentes.. . Ciertas formas e s t a r a z ó n , e s p r o b a b l e q u e la s t é c n i c a s d e e s p e c i f i c a
de falta de completitud o de inconsistencia se pueden detec
c ió n fo r m a le s m a te m á tic a s p a s e n a s e r e l fu n d a m e n to d e
tar de forma automática.
u n a f u t u r a g e n e r a c ió n d e h e r r a m ie n ta s C A S E . C u a n d o
A d e m á s , la e s p e c if ic a c ió n f o r m a l e lim in a la a m b i e s t o s u c e d a , e s p o s i b l e q u e la s e s p e c i f i c a c i o n e s b a s a d a s
g ü e d a d , y p r o p u g n a u n m a y o r r i g o r e n la s p r i m e r a s f a s e s e n m a te m á tic a s s e a n a d o p ta d a s p o r u n s e g m e n to m á s
d e l p r o c e s o d e in g e n ie r í a d e l s o ftw a r e . a m p l i o d e l a c o m u n i d a d d e l a i n g e n i e r í a d e l s o f t w a r e 7.
L o s m é to d o s fo r m a le s o fr e c e n u n fu n d a m e n to p a r a e n to r c r ip t iv a s d e la te o r ía d e c o n ju n t o s y d e la n o ta c ió n ló g i
n o s d e e s p e c if ic a c ió n q u e d a n lu g a r a m o d e lo s d e a n á li c a c a p a c it a n a l in g e n ie r o d e l s o ftw a r e p a r a c r e a r u n e n u n
s is m á s c o m p l e t o s , c o n s is t e n t e s y c a r e n t e s d e a m b i g ü e d a d , c ia d o c la r o d e lo s h e c h o s ( r e q u is it o s ) .
q u e a q u e llo s q u e s e p r o d u c e n e m p le a n d o m é to d o s c o n L o s c o n c e p to s s u b y a c e n te s q u e g o b ie r n a n lo s m é to
v e n c io n a le s u o r ie n t a d o s a o b je t o s . L a s c a p a c id a d e s d e s - d o s f o r m a le s s o n : ( 1 ) lo s in v a r ia n t e s d e d a to s - c o n -
www.FreeLibros.org
7 Es importante tener en cuenta que hay otras personas que no están
de acuerdo. Véase [YOU94],
456
C A P Í T U L O 25 MÉTODOS FORMALES
diciones que son ciertas a lo larg o de la e je cu c ió n del Z , al igual que todos los lenguajes de especificación
sistem a que co n tien e u n a c o le c c ió n de datos— ; ( 2 ) el fo rm a l, posee tan to un d o m in io se m á n tic o c o m o un
estado — los d a to s a lm a c e n a d o s a los q ue acced e el dom inio sintáctico. El dom inio sintáctico utiliza una sim -
sistem a y que son alterados p o r él—¿ (3) la operación bología que sigue estrecham ente a la notación de c o n
— una acción que tien e lu g a r en u n sistem a y que lee ju n to s y al cálculo de predicados. El dom inio sem ántico
o escribe d ato s en un estado— . U n a o p e ra ció n q u eda capacita al lenguaje para ex p resar requisitos de form a
asociada con dos condiciones: u n a preco n dición y una concisa. La estructura Z contiene esquem as, estructuras
postcondición. en form a de cu adro que p re se n ta n las v aria b les y que
La m atem ática d isc re ta — la n o tació n y práctica aso especifican las relaciones entre estas variables.
ciada a los conjuntos y a la especificación constructiva, L a decisión de u tilizar m étodos form ales debe c o n
a los operadores de conjuntos, a los operadores lógicos siderar los costes de arranque, así com o los cam bios pu n
y a las su cesiones— constituyen la base de los m étodos tuales asociados a una tecnología radicalm ente distinta.
formales. E stas m atem áticas están im p lem entadas en el E n la m ayoría de los casos, los m étodos form ales o fre
contexto de un lenguaje de e sp e c ific ac ió n fo rm al, tal cen los m ayores beneficios para los sistem as de seguri
como Z. dad y para los sistem as críticos para los negocios.
J l £ ] '.EREN £LI& SL
[BOW95] Bowan, J.P., y M.G. Hinchley, «Ten Command- tions Techniques; eds.: N. G ehaniyA T. McKittríck, Addi
ments of Fermal Methods, Computer», vol. 28, n.a 4, Abril son-Wesley, 1986, p. 3.
1995. [MAR94] Marcianiak, J.J. (ed.), Encyclopedia o f Software
[GRI93] Gries, D., y F.B, Schneider,H Lógica!Approach to Engineering, Wiley, 1994.
DiscreteMath, Springer-Verlag, 1993. [ROS95] Rosen, K.H., Discrete Mathernatics and Its Appli
[GUT93] Guttag, J.V., y J.J. Homing, Larch:Languages and cations, 3.a ed., McGraw-Hill, 1995.
Toolsfor Formal Specifications, Springer-Verlag, 1993. [SPI88] Spievy, J.M., UnderstandingZ:A Specification Lan-
guage and Its Formal Semantics, Cambridge University
[HAL90] Hall, A., «Seven Myths of Formal Methods», IEEE
Press, 1988.
Software, Septiembre 1990.
[SPI92] Spievy, J.M., The ZNot.at.ion: A Reference Manual,
[HOR85] Hoare, C.A.R., Communicating Sequential Pro- Prentice-Hall, 1992.
cesses, Prentice-Hall International, 1985.
[WIL87] Witala, S.A., Discrete Mathernatics: A Unified
[HIN95] Hinchley, M.G., y S.A. Jarvis, C on curren t Systems: Approach, McGraw-Hill, 1987.
FonnalDevelopment in CSP, McGraw-Hill, 1995.
[WIN90] Wing, J.M., «A Specifrer’s Introduction to Formal
[JON91] Jones, C.B., Systematic Development JJsing VDM, M ethods», IEEE Computer, vol. 23, n .fi 9, Septiembre
2.a ed., Prentice-Hall, 1991. 1990, pp. 8-24.
[LIS86] Liskov, B.H., y V. Berzins, «An Appraisal of Pro- [YOU94] Yourdon, E., «Formal Methods», Guerrilla Pro-
gram Specifications», publicado en Software Specifica grammer, Cutter Information Corp., Octubre 1994.
PROBLEMAS Y PUNTO S A C Q N 5 I II E B A R
25.1. Revisar los tipos de deficiencias asociados a los enfo a. el invariante de datos
ques menos formales de la ingeniería del software en la Sec
b. el estado
ción 25.1.1. Proporcione tres ejemplos de cada uno de ellos,
procedentes de su propia experiencia. c. las operaciones probables
25.2. Los beneficios de las matemáticas como mecanismo de 25.4. Se le ha asignado un equipo de software que está desa
especificación se han descrito con cierta extensión en este capí rrollando software, denomina do DuplicadosMemoria, y que
tulo. ¿Existe algún aspecto negativo? proporciona una mayor cantidad de memoria aparente para
25.3. Se le ha asignado un equipo de software que va a desa un PC, en comparación con la memoria física. Esto se logra
rrollar software para un fax módem. Su trabajo consiste en identificando, recogiendo y reasignando bloques de memo
desarrollar el «listín telefónico» de la aplicación. La función ria que hayan sido asignados a aplicaciones existentes pero
del listín telefónico admite hasta MaxNombre nombres de no estén siendo utilizados. Los bloques no utilizados se rea
www.FreeLibros.org
direcciones que serán almacenados junto con los nombres de signan a aplicaciones que requieran memoria adicional. Efec
la compañía, números de fax y otras informaciones relacio tuando las suposiciones oportunas, y empleando el lenguaje
nadas. Empleando el lenguaje natural, defina: natural, defina:
INGE NIERÍA DEL S O F TW A RE . UN EN F O Q U E P R A C T I C O
a. e l in v a ria n te d e d a to s 25.8. D e s a rro lla r u n a e s p e c ific a c ió n c o n s tru c tiv a d e c o n ju n

to s c o rre sp o n d ie n te a l c o n ju n to d e p a re ja s e n la s c u a le s el p ri
b. e l e sta d o
m e r e le m e n to d e c a d a p a r e ja e s la s u m a d e d o s n ú m e ro s
c. las o p e r a c io n e s p ro b a b le s n a tu ra le s n o n u lo s, y e l s e g u n d o e le m e n to e s la d ife re n c ia d e
e so s d o s n ú m e ro s. A m b o s n ú m e ro s d e b e n d e e s ta r e n tre 100
25.5. D e s a rro lla r u n a e s p e c ific a c ió n c o n stru c tiv a p a ra u n c o n y 2 0 0 in clu siv e .
j u n to q u e c o n te n g a tu p la s d e n ú m e ro s n a tu ra le s d e la fo rm a
( x ,y , z-’) ta le s q u e la su m a d e x e y e s ig u a l a 25.9. D e s a rro lla r u n a d e s c rip c ió n m a te m á tic a d e l e s ta d o y del
in v a ria n te d e d a to s p a ra e l P ro b le m a 25.3. R e fin a r e s ta d e s
25.6. E l in sta la d o r d e u n a a p lic a c ió n b a sa d a e n P C d e te r m i c rip c ió n e n e l le n g u a je d e e s p e c ific a c ió n Z.
n a si e s tá p re se n te o n o u n c o n ju n to d e re c u rso s d e h a rd w a re
y so ftw a re a d e c u a d o s. C o m p ru e b a la c o n fig u ra c ió n d e h a r d 25.10. D e s a r ro lla r u n a d e s c rip c ió n m a te m á tic a d e l e s ta d o y
w a re p a ra d e te rm in a r si e s tá n p r e s e n te s o n o d ife re n te s d is d e l in v a ria n te d e d a to s p a ra e l P ro b le m a 25.4. R e fin a r e sta d e s
p o s itiv o s (d e e n tre m u c h o s d isp o sitiv o s p o s ib le s ) y d e te rm in a c rip c ió n e n e l le n g u a je d e e s p e c ific a c ió n Z .
si y a e s tá n in sta la d a s la s v e rsio n e s e sp e c ífic a s d e so ftw a re d e l
25.11. U tiliz a n d o la n o ta c ió n Z p re s e n ta d a e n la T a b la 2 5 .1 ,
siste m a y d e c o n tro la d o re s. ¿Qué c o n ju n to d e o p e ra d o r e s se
s e le c c io n a r a lg u n a p a rte del* siste m a d e s e g u rid a d HogarSe-
u tiliz a ría p a ra lo g ra r e s to ? P ro p o rc io n a r u n e je m p lo e n e ste
guro d e s c rito a n te rio r m e n te e n e s te lib ro , e in te n ta r e sp e c ifi
c o n te x to .
c a rlo e m p le a n d o Z.
25.7. In te n te d e sa rro lla r u n a e x p re s ió n e m p le a n d o la ló g ic a y 25.12. E m p le a n d o u n a o m á s d e la s f u e n te s d e in f o r m a c ió n
u n c o n ju n to d e o p e ra d o re s p a ra la sig u ie n te se n ten c ia : « P a ra
in d ic a d a s e n la s r e f e r e n c ia s d e e s te c a p ítu lo o e n la se c c ió n
to d o x e y, si x e s p a d re d e y e y e s p a d re d e z, e n to n c e s x e s
d e Otras Lecturas y Fuentes de Información, d e s a rro lla r una
a b u e lo d e z. T o d a s la s p e rso n a s tie n e n u n p a d re .» P ista : u tili
p r e s e n ta c ió n d e m e d ia h o ra a c e r c a d e la s in ta x is y se m á n
c e la s fu n c io n e s P(.x, y ) y G(x, z ) p a ra re p re s e n ta r la s fu n c io
tic a b á s ic a d e u n le n g u a je d e e s p e c if ic a c ió n f o r m a l y d is
n e s p a d re y a b u e lo , re sp e c tiv a m e n te .
tin to d e Z .
O T R A SL E C T U R A S Y FUENTES DE INFO RM ACIÓ N
A d e m á s d e lo s lib ro s u tiliz a d o s c o m o re fe re n c ia e n e s te c a p í Ja c k y , J., T h e W ay o f Z: Practical Programming WithFor-

tu lo , se h a p u b lic a d o u n n ú m e r o b a s ta n te g ra n d e d e lib r o s malM ethods, C a m b rid g e U n iv e r s ity P re s s , 1997.
a c e rc a d e te m a s r e la c io n a d o s c o n los m é to d o s fo rm a le s a lo L a ñ o , J ., y H a u g h to n (e d s.), Object-Oriented Specifica
la rg o d e lo s ú ltim o s añ o s. Se p re s e n ta a c o n tin u a c ió n u n l is tion Case Studies, P r e n tic e - H a ll, 1993.
ta d o d e lo s e je m p lo s m á s sig n ific a tiv o s: R a n n , D ., J. T u m e r y J. W h itw o rth , Z:A Beginner's Guide,
C h a p m a n & H a ll, 1994.
B o w a n , J., Formal Specification and Documentado» using
R a tc liff , B.,Introducing Specification Using Z: A Practi
Z: A Case study Approach, In te r n a tio n a l T h o m s o n C o m p u
te r P re s s , 1996.
cal Case Study Approach, M c G ra w -H ill, 1994.
D. S h e p p a rd , An Introduction to Formal Specification with
C a se y , C.,A Programming Approach to FormalMethods,
Z and VDM, M c G ra w - H ill, 1995.
M c G ra w -H ill, 2 0 0 0 .
C o o p e r,D ., y R. B a rd en , Z in Practice, P re n tic e -H a ll, 1995. L o s e je m p lo s d e s e p tie m b r e d e 1 9 9 0 d e IEEE Transac-
C ra ig e n , D., S. G e rh a rt y T. Raltson, Industrial Applica tions on Software Engineering, IEEE Software e IEEE Com-
tion ofFonna! Methods to Model, Design, Diagnose and Ana - puter e s ta b a n d e d ic a d o s to d o s e llo s a lo s m é to d o s fo rm ales.
lize Computer Systems, N o y e s D a ta C o rp ., P a rk R id g e , N J , S ig u e n sie n d o u n a fu e n te e x c e le n te d e in f o rm a c ió n Útil.
1995. ' ' S c h u m a n h a e d ita d o u n lib ro q u e d e s c rib e lo s m é to d o s
D ille r, A ., Z .: A n Introduction to Formal Methods, 2 .a ed., f o r m a l e s y la s t e c n o lo g ía s o r ie n ta d a s a o b j e t o s (Formal
W iley , 1994. Object-Oriented Development, S p rin g e r-V e rla g , 19 9 6 ). El
H a rry , A ., Formal Methods Fací File: VDMv Z, W ile y , lib ro o fre c e lín e a s g e n e ra le s a c e rc a d e la u tiliz a c ió n se le c ti
1997 ' ' ' v a d e m é to d o s f o r m a le s y a c e r c a d e la fo rm a e n q u e e sto s
H in c h le y , M .,y J. B o w a n , Applications o f Formal Methods, m é to d o s se p u e d e n u tiliz a r e n c o n ju n c ió n c o n e n fo q u e s OO.
P re n tic e -H a ll, 1995. E n I n te rn e t se e n c u e n tr a u n a g r a n c a n tid a d d e in fo rm a
H in c h le y , M . , y J. B o w a n , Industrial Strength Formal c ió n a c e rc a d e lo s m é to d o s f o r m a le s y d e o tr o s te m a s re la
Methods, A c a d e m ic P re s s , 1997. c io n a d o s. E n http://www.pressman5,com se p u e d e en co n trar
H u s s m a n n , H ., Formal F oundationsfor Software Engi u n a lista d e re fe re n c ia s a c tu a liz a d a re le v a n te p a ra lo s m é to
neering Methods, S p rin g e r-V e rla g , 1997. d o s fo rm a le s .
C A P ÍT U L O
a p IN G E N IE R ÍA DEL S O F TW A R E
A Y \ DE S A LA L IM P IA
A u t iliz a c ió n in te g r a d a d e l m o d e la d o d e in g e n ie r í a d e l s o ftw a r e c o n v e n c io n a l, m é to d o s
L fo r m a le s , v e r if i c a c ió n d e p r o g r a m a s ( d e m o s tr a c io n e s d e c o r r e c c ió n ) y e s ta d ís tic a S Q A
s e h a n c o m b in a d o e n u n a té c n ic a q u e p u e d e d a r lu g a r a u n s o ftw a r e d e c a lid a d e x t r e
m a d a m e n t e a lta . L a in g e n ie r í a d e l s o ftw a r e d e s a la lim p ia e s u n e n f o q u e q u e h a c e h in c a p ié e n
la n e c e s id a d d e i n c l u i r la c o r r e c c ió n e n e l s o f t w a r e a m e d id a q u e é s te s e d e s a r r o lla . E n lu g a r
d e l c i c l o c l á s i c o d e a n á l i s i s , d i s e ñ o , p r u e b a s y d e p u r a c i ó n , e l e n f o q u e d e s a l a l i m p i a s u g i e r e un
p u n to d e v is t a d is t in t o [ L I N 9 4 ] :
L a filosofía que subyace tras la ingeniería del softw are de sala lim pia co n siste en e v ita r la dep en d en cia
de costosos procesos de elim inación de d efecto s, m ediante la escritura de increm entos de código desde un
prim er m om ento, y m ediante la verificación de su corrección antes de las pruebas. Su m odelo de proceso
incluye la certificación estadística de calidad de los increm entos de código, a m edida que estos se van a ñ a
d iendo cn el siste m a .
E n m u c h o s a s p e c t o s , e l e n f o q u e d e s a la l i m p i a e l e v a l a i n g e n i e r í a d e l s o f t w a r e a o t r o n i v e l .
A l ig u a l q u e la s t é c n ic a s d e m é t o d o s f o r m a le s q u e s e p r e s e n ta b a n e n e l C a p í t u l o 2 5 , e l p r o
c e s o d e s a la l i m p i a h a c e h in c a p ié e n e l r i g o r e n la e s p e c if ic a c ió n y e n e l d is e ñ o , y e n la v e r i
f ic a c ió n f o r m a l d e c a d a u n o d e lo s e le m e n to s d e l m o d e lo d e d is e ñ o r e s u lta n t e m e d ia n t e e l
u s o d e p r u e b a s d e c o r r e c c ió n b a s a d a s e n fu n d a m e n to s m a te m á tic o s . A l e x te n d e r e l e n fo q u e
a d o p t a d o e n lo s m é t o d o s f o r m a l e s , e l e n f o q u e d e s a la l i m p i a h a c e h in c a p i é t a m b i é n e n t é c
n i c a s d e c o n t r o l e s t a d í s t i c o d e c a l i d a d , i n c l u y e n d o la s c o m p r o b a c i o n e s b a s a d a s e n e l u s o a n t i
c ip a d o d e l s o f t w a r e p o r p a r t e d e lo s c lie n t e s .
ViSTAZO RÁPIDO
¿Qué e s ? ¿C uántas v eces se h a oído decir (fallos inform áticos)que se com eten e n se a n a liz a n p a r a p e rm itir el c álcu lo
«Hazlocorrectam ente a la primera.? Esa el diseño y construcción d el softw are? m atem ático d e l a fiabilidad proyectada
es la filosofía prim ordial d e la ingenie Esto e s lo que prom ete la in g e n ie ría del e n el com ponente d e softw are.
ría del softw are de s a la lim pia, un pro softw are de s a la lim pia. ¿Cuál e s e l p ro d u cto o b te n id o ? El
ceso q u e d a im portancia a la verificación d e sa rro llo d e e sp e cific a cio n es d e c a ja
¿Cuáles son los pasos? Los m odelos de
matemática d e la corrección antes de que n eg ra, d e c a ja d e e sta d o y d e c a ja lim
a n á lis is y diseño se c re a n utilizando la
com ience la construcción d e u n progra p ia. Y, a d e m á s, el reg istro d e l os re su l
re p re s e n ta c ió n d e e s tru c tu ra d e caja.
m a y d e q u e la certificación de la fiabili ta d o s d e l a s p ru e b a s fo rm a le s d e
U na «caja» e n c a p s u la el s is te m a (o
dad d el softw are forme p a rte de la corrección y la s p ru e b a s e s ta d ís tic a s
a lg ú n a sp e c to d el siste m a ) a un nivel
actividad de pruebas. H aciendo hinca d e utilización.
específico d e ab stracció n . La verifica
pié en u n a filosofía m ás profunda, se tra
ción d e la corrección se a p lic a u n a vez ¿Cómo p u ed o e s ta r se g u r o d e q u e
taría d e aq u e lla que tiene índices d efallo
q u e se h a c o m p le ta d o el d ise ñ o d e l a lo h e h e c h o c o r r e c ta m e n te ? La
extrem adam ente bajos y q u e e s difícil o
e stru c tu ra d e c a ja Y la p ru e b a e sta d ís p ru e b a form al d e corrección se a p lic a
im posible de lograr utilizando m étodos
tic a d e la utilización com ienza u n a vez a la e sp e c ific a c ió n d e e s tr u c tu r a d e
m enos form ales.
q u e s e h a v e rifica d o la corrección en c ajas. L as p ru e b a s e s ta d ís tic a s d e u ti
¿Quién lo h a ce? Un in g en iero d el soft c a d a e stru c tu ra d e caja. El softw are se lización ejercitan los e scen ario s d e u ti
ware formado p a ra e sta especialización. p ru e b a definiendo un conjunto d e e s c e liz a ció n p a r a a s e g u ra r q u e no se
¿Por q ué e s im portan te? Los erro res narios, d e te rm in a n d o la p ro b a b ilid a d re v elen y se p u e d a n c o rre g ir los e rro
c o n lle v an d o b le trab ajo . T rab a ja r el d e utilización d e c a d a uno y definiendo re s e n la funcionalidad del usuario. Los
doble lleva m ás tiem po y e s m ás caro. ento n ces la s p ru e b a s a le a to ria s q u e se d a to s d e p ru e b a se u tiliz a n p a r a p ro
¿No sería m aravilloso poder reducir d ra a ju s ta n a la s p ro b ab ilid ad es. Por ú lti porcionar u n a señ al d e la fiabilidad del
m á tic a m e n te la c a n tid a d d e erro res mo, los registros d e errores re su lta n tes softw are.
C u a n d o e l s o f t w a r e f a lla e n e l m u n d o r e a l, s u e le n a b u n d a r lo s p e lig r o s a la r g o p la z o a s í c o m o
los p e l i g r o s i n m e d i a t o s . L o s p e l i g r o s p u e d e n e s t a r r e l a c i o n a d o s c o n l a s e g u r i d a d h u m a n a , c o n
www.FreeLibros.org
p é r d id a s e c o n ó m ic a s o c o n e l f u n c io n a m ie n t o e f e c t iv o d e u n a in f r a e s t r u c t u r a s o c ia l y d e n e g o
c i o s . L a i n g e n i e r í a d e l s o f t w a r e d e s a la l i m p i a e s u n m o d e l o d e p r o c e s o q u e e l i m i n a l o s d e f e c
to s a n te s d e q u e p u e d a n d a r lu g a r a r ie s g o s g r a v e s .
459
INGE NIERÍA DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
26.1 EL ENFOQUE DE SALA LIMPIA

La filosofía de la «sala lim pian en las técnicas de fabri 26.1.1. l a estrategia de sa la lim pia
cación de h ardw are es en realid ad algo b astante senci El enfoque de sala lim pia hace u s o de una versión espe
llo: se trata de una form a rentable y eficiente, en térm inos cializada del m odelo increm ental de softw are (C apítu
de tiem po, de establecer un enfoque de fabricación que lo 2). Se desarrolla un «cauce de increm entos de software»
im pid a la introducción de defectos de producción. E n [LIN94] por parte de equipos de ingeniería del software
lu g ar de fabricar un p roducto y dedicarse después a eli p equeños e independientes. A m edida que se va certifi
m in ar defectos, el en fo q u e de sala lim pia d em an d a la cando cad a in crem en to , se integ ra en el todo. C onsi
discip lin a n ecesaria p ara elim inar errores en las e sp e guientem ente, la funcionalidad del sistem a va creciendo
cificaciones y en el diseño, fabricando entonces el p ro con el tiem po.
ducto de fo rm a «lim p ia» .
^ ¿Cuáles son las tareas
• principales que se realizan
en la ingeniería del software
■ienijda de sala limpia logra control de calidad
de sala limpia?
estadístico sobre el desarrollo del software
separando estrictamente el proceso del diseño
La sucesión de tareas de sala lim pia para cada incre
del proceso de comprobación en un cauce
m ento se ilustra en la Figura 26.1. L os requisitos glo
de desarrollo incremental de software.
b ales del siste m a o p ro d u c to se v an desarro llan d o
em p lean d o los m étodos de ingeniería de sistem as des
crito s en el C ap ítu lo 10. U n a vez que se h a asignado
La filosofía de sala lim p ia fue p ro p u esta p o r p rim e una funcionalidad al elem ento de softw are del sistem a,
ra vez para la ingeniería del softw are po r parte de M ills el tubo de la sala lim pia com ienza sus increm entos. Se
y sus colegas [W IL87] durante los años 80. A un c u an producen las tareas siguientes:
do las p rim eras experiencias acerca de este enfoque dis
Planificación de incrementos. Se desarrolla un plan
ciplinado p ara los trab ajo s relacionados con el softw are
de proyecto que adopta la estrategia increm ental. Se van
m ostraba prom esas significativas [H A U 94], no ha alcan
estab le cie n d o las fu n cio n alid ad es de c a d a uno de los
zado una am plia utilización. H enderson [HEN95] sugie
increm entos, su tam año estim ad o y un p lan de desarro
re tres p osibles razo n es:
llo de sala lim pia. Es preciso tener especial cuidado para
1. L a creencia en que la m eto d o lo g ía de sala lim pia es asegurar que los increm entos certificados se vayan inte
excesivam ente teórica, excesivam ente m atem ática y grando de form a tem poralm ente oportuna.
excesivam ente rad ical p ara u tilizarla en el d esarro
Recolección de requisitos. M ediante el uso de téc
llo de softw are real.
nicas sim ilares a las presentadas en el C apítulo 1 L se
2. N o p ro p u g n a u n a co m probación unitaria p o r parte desarrolla una descripción m ás detallada de requisitos
de los desarrolladores, sino que la sustituye p o r una del nivel del usuario (para cad a increm ento).
v erificació n de la correcció n y p o r un control e sta
Especificación de la estructura de cajas. Se utiliza un
d ístic o de la c a lid a d - e s t o s c o n cep to s que re p re
m étodo de especificación que hace uso de estructuras de
sentan una desv iació n fundam ental co n respecto a la
caja [FIEV93] para d escrib irla especificaciónfuncional.
fo rm a en que se desarro lla la m ay o r parte del so ft
w are en la actualidad— . incremento n2 1
3. L a m a d u rez de la in d u stria de d e sa rro llo del so ft EES DF GCl
O
<
li£ j
RR CEU c
w are. El uso de p ro ceso s de sa la lim p ia re q u ie re
.. ..... ... £P _ .................... ¡
u n a ap licació n rig u ro sa de p ro c e so s d efin id o s en incremento n2 2
to d as las fases del ciclo de vida. D ado que la m ayor EES DF VC IC J
GCi CEU C
p arte de la in d u stria fu n c io n a to d a v ía en el n iv el RR
1 . , PP ....
ad hoc (según se h a definido p o r parte del Softw are
incremento ns 3
E n g in e e rin g In stitu te C ap ab ility M atu rity M odel), EES DF VC¡
la in d u s tria n o h a e s ta d o p re p a ra d a p a ra a p lic a r RR
GCÍ IC| C E U c
estas técnicas. 1 pP í
IS - In g e n ie ría de s is te m a s GC - G e n e ra c ió n de c ó d ig o
A u n cu an d o e x iste n cierto s in d ic io s de v e rd ad en RR - R e c o le cció n de re q u is ito s IC - In sp e cció n de c ó d ig o
to d a s las in d icacio n es e x p resad as an terio rm en te, l o s E E C - E sp ecificación de e s tru c tu ra CEU - C o m p ro b a c ió n estadística
posib les beneficios de la ingeniería del softw are de sala d e ca ja s de u tiliz a c ió n
DF - D is e ñ o fo rm a l C - C e rtific a c ió n
lim p ia co m pensan m ás que sobradam ente la inversión
www.FreeLibros.org
VC -V e rific a c ió n de c o rre c c ió n PP - P la n ific a c ió n d e prueba
re q u e rid a p a ra su p e ra r la re siste n c ia c u ltu ra l que se
encu en tra en el n ú cleo de estas objeciones. FIG URA 2 6 .1 . El m o d e lo de p r o c e s o de sala limpia.
460
C A P I T U L O 26 IN GE NI ER IA DEL SOFTWARE: DE S A L A LIMPIA
A justado a los principios de análisis o p eracional d e s

critos en el C apítulo 11, la estructura de caja «aísla y
separa la definición creativa del com portam iento, de los la sala limpia da importancia a las pruebas que ejercitan
datos, y de los p ro cedim ientos p ara cada nivel de refi k manera en que se utilizo realmente el software,
nam iento». los casos de utilización proporcionan una fuente
excelente para el proceso de planificación estadística
de comprobación.
Referencia Web / C o m p ro b a c ió n estad ística de u tiliz a c ió n . R e c o r

Uno fuente excelente de información y de recursos dando que es im posible una com probación ex h au stiv a
poro la ingeniería del software de sala limpio del softw are de co m p u tad o ra (C ap ítu lo 17), siem p re
se puede entontror en www.tleansoft.com resu lta necesario diseñar un conjunto finito de caso s de
prueba. Las técnicas estadísticas de utilización [P 0 0 8 8 ]
D iseño fo rm a l. M e d i a n t e e l u s o d e l e n f o q u e d e e je c u ta n una c o le c c ió n de p ru eb as d e riv a d a s d e una
estructura de caj as, el diseño de sala lim pia es una ex ten m uestra estadística (la distribución de p robabilidad indi
s ió n n a t u r a l y s in d is c o n t in u id a d e s d e la e s p e c if ic a c ió n . cad a anteriorm ente) de todas las posibles ejecu cio n es
A u n c u a n d o e s p o s ib le e fe c t u a r u n a d is t in c ió n c la r a e n tr e del program a p o r parte de todos los usuarios de una cier
estas dos actividades, las especificaciones (que se d en o ta p o blación ob jetiv o (S ección 26.4).
minan «cajas negras») se refinan iterativam ente (den C ertificación. U n a v ez que se h a finalizado la v e ri
tr o d e c a d a in c r e m e n t o ) p a r a tr a n s f o r m a r s e e n d is e ñ o s ficación, la inspección y la com probación de utilización
a n á l o g o s a l a a r q u i t e c t u r a y a los p r o c e d i m i e n t o s ( q u e (y después de corregir todos los errores) se certifica el
se denom inan «cajas de estado» y «cajas trasparentes», increm ento com o preparado para su integración.
respectivam ente).
A l ig u a l que o tro s m o d e lo s d e p ro c e s o d el s o f t
Verificación de co rrecció n . E l e q u i p o d e s a l a l i m w are d escrito s en o tra s p a rte s de e ste lib ro , el p r o c e
p ia lle v a a c a b o u n a s e r ie d e r ig u r o s a s a c t iv id a d e s d e so de sa la lim p ia h a c e e s p e c ia l h in c a p ié en la
v e r if ic a c ió n d e c o r r e c c ió n a p lic a d a s p r im e r o a l d is e ñ o n e ce sid a d de c o n d u c ir u n o s m o d e lo s de an á lisis y de
y d e s p u é s a l c ó d ig o . L a v e r if ic a c ió n ( S e c c io n e s 2 6 .3 y d ise ñ o de m uy alta c alid a d . S eg ú n se v e rá p o s te rio r
2 6 .4 ) c o m ie n z a c o n la e s t r u c t u r a d e c a ja s d e l m á s a lt o m ente en este c a p ítu lo , la n o ta c ió n de e stru c tu ra de
nivel (la e sp e c ific ac ió n ) y av an za h a c ia el detalle de ca jas no es m ás que o tra fo rm a p a ra que el in g e n ie
d is e ñ o y e l c ó d ig o . E l p r i m e r n i v e l d e v e r if i c a c ió n d e ro del softw are p u e d a re p re s e n ta r l o s re q u isito s y el
c o r r e c c ió n s e lle v a a c a b o a p lic a n d o u n c o n ju n t o d e diseñ o . L a d istin c ió n re al del e n fo q u e de sa la lim p ia
c u e s tio n e s de co rrecció n » [L IN 88 ], Si este co njunto co n siste en que se a p lic a la v e rific a c ió n fo rm al a los
de p r e g u n t a s n o d e m u e s t r a q u e l a e s p e c i f i c a c i ó n e s m o d elo s de ingeniería.
c o r r e c ta , se u t iliz a n m é to d o s m á s fo r m a le s ( m a te m á ti
c o s ) d e v e r ific a c ió n .
26.1.2.¿Qué h ace diferente la s a la lim p ia?
D yer [D Y E92] alude a las d iferen cias d el enfoque de
Lo calidad no es una acción. Es un hábito.
sala lim pia cuando define el p ro ce so :
L a sala lim p ia rep re se n ta el prim er intento p ráctico de
poner el proceso de desarrollo del softw are bajo un control
G en eración de código, inspección y verificación. estadístico de calidad con una e strategia b ien definida para
la m ejora continua del proceso. P a ra a lc an z a r e sta m eta , sc
L a s e s p e c if ic a c io n e s d e e s t r u c t u r a d e c a ja , q u e s e r e p r e
definió un ciclo único de vida de sala lim p ia, que hacía h in
s e n ta n m e d ia n t e u n le n g u a je e s p e c ia liz a d o , s e t r a d u c e n capié en una ingeniería del softw are b asa d a en las m atem á
al l e n g u a j e d e p r o g r a m a c i ó n a d e c u a d o . S e u t i l i z a n e n t o n tic a s para o b ten er diseñ o s de so ftw a re c o rre c to s y q u e se
ces técnicas estándar de recorrido o de inspección (C apí basaba en softw are basado en e sta d ístic a para la c e rtific a
tulo 8) para asegurar el cum plim iento sem ántico de las ción de fiabilidad de ese softw are.
estructuras de código y de cajas, y la corrección sintác
L a ingeniería del softw are de sala lim pia ditiere de
tic a d e c ó d ig o . A c o n t in u a c ió n , s e e f e c t ú a u n a v e r if i c a
los puntos de vista convencionales y o rien tad o s a o b je
c ió n d e c o r r e c c ió n p a r a e l c ó d i g o f u e n t e .
tos que se representan en la Partes T ercera y C uarta de
Planificación de la c o m p ro b a ció n estad ística. L a este libro porque:
u t iliz a c ió n e s tim a d a d e l s o f t w a r e s e a n a liz a , s e p l a n i
1. H ace uso explícito del control estadístico de calidad.
fic a y se d is e ñ a u n c o n ju n t o d e c a s o s d e p r u e b a q u e
e je r c ite n la « d is t r ib u c i ó n d e p r o b a b ilid a d » d e e s a u t i 2. Verifica la especificación del diseño e m p lean d o una
liz a c ió n ( S e c c ió n 2 6 . 4 ) . S e g ú n s e m u e s t r a e n la F ig u dem ostración de corrección basada en las m atem áticas.
www.FreeLibros.org
ra 2 6 . 1 , e s t a a c t i v i d a d d e s a l a l i m p i a s e r e a l i z a e n 3. H ace m ucho uso de la com probación e sta d ística de
p a r a le lo c o n l a e s p e c i f i c a c i ó n , l a v e r i f i c a c i ó n y l a g e n e utilización para descubrir errores de esp ecial in c i
r a c ió n d e c ó d ig o . dencia.
461
IN GENIERÍA DEL S O F TW A R E . UN E N F O Q U E P R Á C T I C O
cubrir los erro res) y dep u rad o d esp u és (para e lim in ar

los errores). C uando se publica finalm ente el softw are,
la u tiliz a c ió n p rá c tic a d e sc u b re aun m ás d e fe c to s, y
Las característicasmás importantes que distinguen com ienza otro ciclo de com probación y depuración. Este
la sala limpia son la comprobación de corrección trabajo re p etid o asociado a las actividades m en cio n a
y la comprobación estadística de utilización. das resulta costoso y lleva m ucho tiem po. Y lo que es
peor, puede ser degenerativo; la corrección de errores
E videntem ente, el enfoque de sala lim pia aplica la puede (inadvertidam ente) dar lu g ar a la introducción de
m ayor parte, si es que no todos, de los principios b á si otros errores.
cos de ingeniería del softw are y de los conceptos que
se han p resentado a lo largo de este libro. Son esen cia C ^ } C ita :
les unos buenos p rocedim ientos de análisis y diseño si
Existe alguno cosa divertida en la vida y asta
es que se d esea p ro d u cir una elev ad a calidad. P ero la
es que si no oceptas nada excepto lo mejor,
ingeniería de sala lim p ia d iv erg e de las p rá c tic as de
sueles conseguirlo.
softw are c o n v e n c io n a le s al q u ita r im p o rta n c ia (hay
W. Somerset Maugham
quien diría elim inar) al pap el de las p ruebas de u nidad
y a la depuración y al red u cir dram áticam ente (o elim i
nar) la cantidad de co m probaciones que son realizadas E n la ingeniería del softw are de sala lim pia, la co m
por quien d esarrolla el softw are'. p ro b ac ió n u n itaria y la d e p u rac ió n se ven sustituidas
En el d esarrollo co nvencional del softw are, los e rro p o r una v erificación de corrección y p o r pruebas b a sa
res se aceptan com o cosas que pasan. D ado que se c o n das en la estadística. E stas actividades ju n to con el m an
sidera que los errores son inevitables, cada m ódulo del tenim iento de registros para una continua m ejora, hacen
programa debe ser com probado unitariam ente (para des que el enfoque de sala lim pia sea único.
2,6.2 E S P E C I F I C A C I Ó N F U N C I O N A L
Independientem entedel m étodo de análisis selecciona C aja negra. E sta caja esp e cific a el co m p o rta m ien
do, los principios de operació n p resentados en el C apí to del sistem a, o de p arte de un sistem a. El sistem a (o
tulo 11 siem pre serán aplicables. Se m o d elan los datos, parte de él) responde a estím u lo s específicos (sucesos)
las funciones y el com portam iento. L os m od elo s re su l m e d ia n te la a p lic a c ió n d e un c o n ju n to de re g la s de
tantes deben de ser d escom puestos (refinados) para p ro tran sic ió n que hacen c o rresp o n d er el estím u lo con la
porcionar un grado de detalle cada v ez m ás elevado. El respuesta.
objetivo global consiste en pasar de una esp ecificación C aja de estado. E sta c aja e n c a p su la los d ato s de
que captura la esencia de un problem a, a una esp ecifi estad o s y de se rv ic io s (operacio n es) de fo rm a a n á lo
cación que pro p o rcio n a una cantidad de detalle sustan ga a lo s o b jeto s. E n e sta v ista de e sp e c ific a c ió n , se
cial para su im plem entación.
representan las en trad as de la caja de estad o s (los estí
La ingeniería del softw are de sala lim pia satisface m u lo s) y sus sa lid a s (las resp u estas). L a c aja de e sta
los principios de análisis o p eracio n alp o r cuanto em plea dos tam b ié n rep resen ta la « h isto ria de estím u lo s» de
un m étodo denom inado especificación de e stn ic tu n i de la c aja n e g ra , es decir, lo s d a to s e n c a p su la d o s en la
caja. U n a «caja» encapsula el sistem a (o algún aspec caja de estado que deben ser m antenidos entre las tran
to del sistem a) co n un cierto grado de detalle. M edian sicio n es im p licad as
te un p ro ceso de re fin a m ie n to p ro g re siv o , se van
refinando las cajas para fo rm ar u n a je ra rq u ía en la cual Caja lim pia. Las fu n cio n es de tra n sic ió n que están
cada caja tiene transparencia referencia!. E sto es, «el im p licad as en la c aja de e sta d o se d efin en en la caja
contenido de inform ación de cada especificación de caj a lim p ia. D ich o literalm e n te, la c a ja lim p ia co n tien e el
basta p ara d efin ir su refinam iento, sin d epender de la diseño procedim ental correspondiente a la caja de esta
im plem en tació n de n inguna otra caja» [L IN 94], E sto dos.
capacita al analista p ara desglosar jerárq u icam en te el
sistem a, pasando de la representación esencial situada ¿ Cómo se lleva o cabo
en la parte superior, h asta los detalles específicos de la * el refinamiento como parte
im plem en tació n situados en la parte inferior. Se u tili de lo especificación de estructura
zan tres tipos de cajas: de caja negra?
www.FreeLibros.org
1 Las pruebas s e realizan, pero las efectúa un equipo independiente
de pruebas
462
C A P Í T U L O 26 I N G E N I E R Í A D E L SO F T W A R E D E S A L A L I M P I A
L a F ig u r a 2 6 .2 ilu s tra e l e n fo q u e d e re fin a m ie n to 26.2.1. E s p e c if ic a c ió n d e c a ja n e g r a

m ed ia n te e l uso de u n a e s p e c ific a c ió n d e e s tru c tu ra de U n a e s p e c ific a c ió n d e c a ja n e g ra d e s c rib e u n a a b s tra c
cajas. U n a c a ja n e g ra ( C N , ) d e fin e las re sp u es ta s de c ió n , e s tím u lo s y respu estas e m p le a n d o la n o ta c ió n que
todo un c o n ju n to c o m p le to d e e s tím u lo s . C N , se p u e se m u e s tra e n la F ig u ra 2 6 .3 . [ M I L 8 8 ] , L a fu n c ió n se f
de re fin a r e n u n c o n ju n to de c a ja s n e g ra s , d e sd e C N , , a p lic a a u n a s e c u e n c ia , S1* , d e e n tra d a s (e s t ím u lo s ) y
hasta C N , ,,,c a d a u n a d e las c u a le s a b o rd a u n a c ie r ta e sta fu n c ió n los tr a n s fo r m a e n u n a s a lid a (re s p u e s ta ),
clase d e c o m p o r ta m ie n to . E l r e f in a m ie n to p ro s ig u e R. P a ra c o m p o n e n te s s e n c illo s d e s o ftw a r e ,/, p u e d e ser
hasta que se id e n tifiq u e u n a c la s e c o h e s iv a d e c o m u n a fu n c ió n m a te m á tic a , p e ro e n g e n e r a l, / se d e sc rib e
p o rta m ie n to (p o r e je m p lo , C N , , , ) . A c o n tin u a c ió n , se e m p le a n d o e l le n g u a je n a tu ra l (o
b ie n u n le n g u a je de
d e fin e u n a c a ja d e e s ta d o ( C E , , , ) p a ra la c a ja n e g ra e s p e c ific a c ió n fo rm a l).
(CN,, E n e ste c as o , C E , , , c o n tie n e to d o s lo s d a to s M u c h o s d e lo s c o n ce p to s in tro d u c id o s p a ra sistem as
y s e rv ic io s n e ce sa rio s p a ra im p le m e n ta r e l c o m p o rta o rie n ta d o s a o b je to s son a p lic a b le s ta m b ié n p a ra la c a ja
m ie n to d e f in id o p o r C N , ! P o r ú lt im o , se r e fin a n e g ra . L a s a b strac cio n es d e datos y las o p e ra c io n e s que
CE, p a ra fo r m a r u n c o n ju n to d e c a ja s tra n s p a re n m a n ip u la n estas a b strac cio n es , se v e n e n ca p su la d a s p o r
tes ( C T , | | nj y se e s p e c ific a n lo s d e ta lle s de d is e ñ o de la c a ja n e g ra . A l ig u a l q u e u n a je r a r q u ía d e c la s e s , la
p ro c e d im ie n to s . e s p e c ific a c ió n d e c a ja n e g ra p u e d e m o s tra r las j e r a r
A m e d id a q u e se v a r e a liz a n d o c a d a u n o d e e sto s q u ía s de u tiliz a c ió n en q u e las c a ja s d e n iv e l in fe r io r
pasos de r e fin a m ie n to , se p ro d u c e ta m b ié n u n a v e r if i h e re d a n las p ro p ie d a d e s de las c ajas d e n iv e l s u p e rio r
cación d e la c o rre c c ió n . S e v e r ific a n las e s p e c ific a d e n tro d e la e s tru c tu ra d e á rb o l.
ciones de la s c a ja s de e s ta d o p a ra a s e g u ra r q u e to das
y cada u n a d e e lla s se a ju s ta n a l c o m p o rta m ie n to d e fi
nido p o r la e s p e c ific a c ió n d e la c a ja n e g ra p re d e c e s o - tm B S E E S S S k
los conceptos orientados a objetos se describen
ra. D e m a n e ra s im ila r, se v e r ific a n las e s p e c ific a c io n e s
en el Capítuio 20.
de las cajas tra n s p a re n te s c o n re s p e c to a la c a ja de e sta
dos p re d e ce so ra.
26.2.2. E s p e c if ic a c ió n d e c a ja d e e s t a d o
asfcfe L a c a ja d e estad o es « u n a g e n e ra liz a c ió n s e n c illa de u n a
m á q u in a de e stad o » L M IL 8 8 ], R e c o rd a n d o la d e s c rip c ió n
C LAVE d e l m o d e la d o de c o m p o rta m ie n to y d e los d ia g ra m a s de
El refinamiento de Id estructura de cajas y la verificación tra n s ic ió n de estados que se o fre c e en el C a p ítu lo 1 2, un
de corrección ocurren simultáneamente. estad o es a lg ú n m o d o o b s e rv a b le d e c o m p o rta m ie n to d el
sistem a. A m e d id a que se p ro d u c e e l p ro c e s a m ie n to , el
s is te m a v a re s p o n d ie n d o a sucesos (e s tím u lo s ) e fe c tu a n
Es p re cis o te n e r e n c u e n ta que los m é to d o s d e e sp e
d o u n a tra n s ic ió n que p a rte d e l estado y lle g a a a lg ú n n u e
c ificació n b asados e n m éto d o s fo rm a le s (C a p ítu lo 2 5 )
v o estado. A m e d id a que se e fe c tú a la tra n s ic ió n , puede
se pueden u t iliz a r e n lu g a r d e l e n fo q u e d e e s p e c ific a -
p ro d u c irs e u n a a cc ió n . L a c a ja de estad o u tiliz a u n a abs
c ió n d e e s tru c tu ra d e cajas. E l ú n ic o re q u is ito q u e sees tra c c ió n d e datos p a ra d e te rm in a r la tra n s ic ió n al estado
puede v e rific a r fo rm a lm e n te c a d a u n o d e los n iv e le s de
s ig u ie n te (re s p u e s ta ) que se p ro d u c irá c o m o c o n s e c u e n
especificación.
c ia d e la tra n s ic ió n .
www.FreeLibros.org
FIGURA 2 6 . 2 . R efinam iento de la estructura de cajas. F IG U R A 2 6 . 4 .Una esp ecificación de caja de esta d o [MIL88]
463
Según se m uestra en la Figura 26.4, la caja de estado tituida por las estructuras de program ación estructura
contiene una caja negra. El estím ulo, S, que se introduce da que im plem enta g.
en la caja negra, procede de alguna fuente extem a y de un
conjunto de estados internos del sistem a, T. M ills p ro tm m m m k
porciona una descripción m atem ática de la fu n ció n ,/, de El diseño de pocedmErtosy la programación
la caja negra contenida en el seno de la caja de estado: estudiada se descrbenen el Capitulo 16.
C o m o e je m p lo , c o n sid é re se la c a ja lim p ia que se

donde g es una subfunción que e stá asociada a un esta m uestra en la Figura 26.5. L a caja negra g, que se mues
do específico t. C u an d o se co nsideran en su conjunto, tra en F igura 26.4 se ve su stituida por una sucesión de
las parejas de estados y subfunciones (t, g) definen la estructuras que co n tien en una e stru ctu ra condicional.
función de caja n e g ra /. Estas, a su vez, se pueden refinar para fo n n a r cajas trans
p arentes del in terio r a m ed id a que vaya avanzando el
26.2.3. E s p e c if ic a c ió n d e c a ja li m p i a procedim iento de refinam iento progresivo.
L a especificación de caja lim pia está íntim am ente rela Es im portante tener en cuenta que la especificación
cio n ad a con el diseño de p rocedim ientos y con la p ro de procedim ientos descrita en la je rarq u ía de caja lim
gram ación estructurada. E n esen cia, la subfunción g, p ia se puede d e m o stra r a efecto s de co rrecció n . Este
que se en cuentra dentro de la caja de estado, se ve su s tem a se consid erará en la sección siguiente.
2 6 .3 RE FI NA M IE N T O Y V E R I F I C A C I O N DEL D IS E Ñ O
E l enfoque de diseño que se utiliza en la in g en iería del pero ¿qué pasa con el diseño de datos'? En este aspec
softw are de sala lim p ia hace m u ch o uso de la filosofía to, entra e n ju e g o mi cierto n ú m ero de conceptos fun
de la program ació n estructurada. Pero, en este caso, la d a m e n ta le s d e d ise ñ o (C a p ítu lo 13). L os datos del
p ro g ram ació n estru ctu rad a se a p lica de fo rm a m ucho program a se encapsulan com o un conjunto de abstrac
m ás rigurosa. ciones a las cu ales prestan serv icio las subfuncionec.
L os co n c e p to s de e n c a p su la m ie n to de d a to s, oculta-
m iento de inform ación y los tipos de datos se utilizan
entonces para crear el diseño de datos.
Referencia Web
E l programa DoD STARTS ha desarrollado varias glbs
y doarrertosde sala limpio: ftp.cdrom.com/
p u b /ad a /d o c s/tle an rm
26.3.1. R e fin a m ie n to y v e rific a c ió n d e l d is e ñ o

C ada esp ecificación de caja lim pia representa el diseño
de un procedim iento (subfunción) necesario para efec
tuar una transición de caja de estado. M ediante la caja
F IG U R A 2 6 .5 . U n a e s p e c ific a c ió n de ca ja tr a n s p a r e n te . lim p ia , se u tiliz a n las estru c tu ra s de program ación
estructurada y de refinam iento progresivo según se ilus
tra en la F ig u ra 26.6. U na fu n ción de program a, / se
L a funciones básicas de p rocesam iento (que se des
refina para dar lugar a una sucesión de subfunciones f
crib ían durante los refinam ientos anterio res de la espe
y h. E stas a su vez se refinan para fo rm ar estructuras
cificación) se refinan ahora utilizando una «expansión
condicionales (si-entonces-sino y hacer-m ientras). Un
progresiva de funciones m atem áticas en estru cturas de
refinam iento posterior ilustra la elaboración lógica con
conectiv id ad lógica [por ejem plo, si-e n to n c e s-sin o ] y
tinuada.
subfunciones, donde la expansión [se] efectúa hasta que
todas las funciones identificadas pudieran ser enuncia
das d irectam ente en el lenguaje de p ro g ram ación utili ^ ¿ Qué condiciones
www.FreeLibros.org
zado para la im plem entación» [D Y E92], * se aplican para probar
El enfoque de la p ro g ram ació n estru ctu rad a se pue que las construcciones
de u tilizar de fo rm a e fic ie n te p ara refin ar la fu n ció n , estructuradas son correctas?
464
C A P I T U L O 26 I N G E N I E R Í A D E L S O F T W A R E DE S A L A L I M P I A
C a d a v e z q u e se r e fin a u n a c a ja l i m p ia h a s ta e l
s ig u ie n te n iv e l d e d e ta lle , se a p lic a n las c o n d ic io n e s de
c o rre c c ió n in d ic a d a s a n te rio rm e n te .
E s im p o rta n te te n e r e n c u en ta que la u tiliz a c ió n de
e s tru c tu ra s d e p ro g ra m a c ió n e s tru c tu ra d a re s trin g e e l
n ú m e ro d e c o m p ro b a c io n e s d e c o rre c c ió n q u e es p re
c is o e fe c tu a r. S e v e rific a una sola c o n d ic ió n e n busca
de sucesiones; se v e r ific a n dos c o n d ic io n e s p a ra lo s si-
e n to n c e s -s in o ; y se v e r ific a n tres c o n d ic io n e s p a ra los
b u c le s .
C o n o b je to d e ilu s tra r a lg u n a v e r ific a c ió n d e c o rre c
c ió n p a ra un d is e ñ o d e p ro c e d im ie n to s , se u tiliz a un sen
c illo e je m p lo p re s e n ta d o p o r p rim e ra v e z p o r p a rte de
L in g e r y sus c o la b o ra d o re s [ L Y N 7 9 ] , N u e s tro o b je tiv o
es d is e ñ a r y v e r ific a r u n p e q u e ñ o p ro g ra m a q u e c a lc u
le la p a rte e n te ra , y, d e una r a íz c u a d ra d a de u n e n te ro
dado, x. E l d is e ñ o d e p r o c e d im ie n to s se re p re s e n ta
e m p le a n d o e l d ia g ra m a d e flu jo de la F ig u r a 2 6 .7 .
F IG U R A 2 6 . 6 . Refinam iento progresivo.

Raíz cuadrada
E n c ad a n iv e l de r e fin a m ie n to , e l e q u ip o de sala lim

pia2 lle v a a c a b o u n a v e r ific a c ió n fo rm a l d e c o rre c c ió n .
Para lo g ra r esto , se a so c ia u n c o n ju n to d e condiciones
de corrección g e n é ric a s a las estru ctu ra s d e p ro g ra m a
ción e s tru c tu ra d a . S i se e x p a n d e u n a f u n c ió n /p a r a d a r
una s u c e s ió n g y h.e n to n c es la c o n d ic ió n de c o rre c c ió n
para todas las e n tra d a s d e / e s :
• ¿Es cierto q u e g seguido p o r li d a lu g a r a / ?
Si se re fin a u n a fu n c ió n p p a ra lle g a r a u n a e s tru c
tu ra c o n d ic io n a l (si-entonces-sino),l a c o n d ic ió n de
c o rre c c ió n p a ra to d a e n tra d a de p es:
• ¿Siem pre que sea cierta la condición (c) es cierto
q ue (¡r r e a liz a p y siem p re q u e (c) sea fa lsa , es
cierto que y re a liz a p ?
S i se re fin a una fu n c ió n m e n fo rm a d e b u c le , las
c o n d ic io n e s d e c o rre c c ió n p a ra to d as la s e n tra d a s F IG U R A 26.7. Cálculo de la parte entera de una raíz
de ii son: cuadrada [LIN79].
• ¿E stá g a ra n tiz a d a la finalización?
• ¿Siem pre q u e (c) sea v e rd a d e ra es cierto q u e n P a ra v e r ific a r la c o rre c c ió n d e este d is e ñ o , es p r e c i
seguido p o r m re a liz a m, s ie m p re q u e (c) sea so d e fin ir las c o n d ic io n e s d e e n tra d a y d e s a lid a q u e se
falso, sigue realizándose m si se obvia el b u cle? in d ic a n en la F ig u ra 2 6 .8 . L a c o n d ic ió n d e e n tra d a in d i
x
ca que d e b e ser m a y o r o ig u a l a O. L a c o n d ic ió n d e
s a lid a re q u ie re q u e a p e rm a n e z c a in ta c ta y que ad o p te
un v a lo r d e n tro d e l in te rv a lo m o s tra d o en la fig u ra . P a ra
d e m o s tra r que el d is e ñ o es c o rre c to , es n e c e s a rio d e m o s
Sinos limitamos o construcciones estructuradas cuando tra r que las c o n d ic io n e s comienza bucle, cont, si sali
, y
se creo un diseño de procedimientos, lo pruebo da m o s tra d a s e n la F ig u r a 2 6 . 8 son c ie rta s e n to d o s los
de h corrección es sencillo. Sise violan los construcciones, casos. E n a lg u n as o c as io n es se d e n o m in a n subdemos-
los pruebas de corrección son difíciles o imposibles. traciones.
www.FreeLibros.org
2 Dado que todo el equipo está implicado en el proceso de verifica
ción, es m enos probable que se produzca un error al efectuar la veri
ficación en sí.
465
INGENIERIA DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
Raíz ción que utilice x. Por tanto, queda intacto. Dado que
la com probación de co n d ic io n es ( y + 1)2 < v tiene
que fallar para alcanzar la condición s o l i d o , se sigue
que (y + 1)2 < x. A dem ás, la condición b u c l e debe
se g u ir sien d o v e rd a d e ra (esto e s, y 2 < v). C o n si
guien tem en te, que ( y + 1 )2 > ,v e y 2 < ,v se pueden
com binar para satisfacer la condición de s a l i d a .
A dem ás, es preciso ase g u ra r que finalice el bucle.
U n exam en de la condición del bucle indica que dado
que y se va increm entando y que v > 0 , el bucle fínal-
m ente debe term inar.
i salida: x intacto, e y2 < x < (y + 1)2 L os cin c o p aso s in d icad o s an terio rm e n te son una
dem ostración de la corrección del diseño del algoritmo
F IG U R A 2 6 . 8 . D e m o s tr a c ió n d e la c o r r e c c ió n d e l d is e ñ o indicado en la F igura 26.7. A h o ra estam os seguros de
[L IN 7 9 ], que el diseñ o calcu lará, realm en te, la parte entera de
una raíz cuadrada.
1. L a c o n d ic ió n co m ien zo ex ig e que f.v > 0 e y = 0], Es posible utilizar un enfoque m atem áticam ente más
B asándose en los requisitos del problem a, se supone riguroso de la V erificación del diseño. S in em bargo, un
q u e la c o n d ic ió n de e n tra d a es correcta'. C o n s i debate sobre este tem a iría m á s allá del alcance de este
guientem ente, se satisface la prim era parte de la co n libro. Los lectores interesados pueden consultar [LIN79],
dición c o m i e n z o , x > 0. En el d iag ram a de flujo, la
sen ten cia que p reced e in m ed iatam en te a la c o n d i 26.3.2. V e n ta ja s d e l a v e r i f i c a c i ó n d e l d is e ñ o 4
ción c o m i e n z o h ace que y = 0. C o nsiguientem ente,
la segunda parte de la condición c o m i e n z o tam bién L a verificación de corrección rig urosa de cada uno de
se satisface. De aq u í que com ienzo sea verdadero. los re fin am ien to s del diseñ o de c aja lim p ia posee un
cierto n úm ero de v en ta jas ev id en tes. L in g e r [LIN94]
2. La condición b u c l e se puede encontrar de dos m an e
las describe de la siguiente m anera:
ras: ( 1) d irectam ente saliendo de c o m i e n z o (en este
. Se red u c e la v e rific a c ió n a un p r o c e s o fin ito . La
caso, la condición del bucle se satisface directamente)
o bien ( 2 ) a través del control de flujo que p asa por fo rm a anidada y secuencial, en que se organizan las
la c o n d ic ió n c o n t . D ad o que la c o n d ic ió n c o n t es estructuras de control en una caja lim pia, define de
idéntica a la condición b u c l e , b u c l e es verdadera inde m an e ra natural una .jerarquía que rev ela las condi
pendien tem en te de la ram a de flujo que lleve a ella. cio n e s de c o rrec ció n que es p rec iso verificar. Un
ax io m a de su stitu c ió n [LIN 79J nos perm ite reem
p lazar las funciones objetivo p o r sus refinam ientos
% de estructura de control dentro de lajerarquía de sub-
CLA VE d em o stra cio n e s. P o r e je m p lo , la subdem ostracióii
Poro dem o strar la corrección de un diseño, p rim ero para la función final f l de la Figura 26.9 requiere que
se d eben identificar todos las co n d icio n e s y dem ostrar
la com probación de las operaciones g l y g 2 con la
qu e to do u no de e llo s tom o un valo r Booleono.
función final f 2 pro d u zca sobre los datos el mismo
Esto e s lo q u e se llam a subdem ostroción.
efecto f l . O b sérvese que f2 reem plaza a todos los
detalles de su refin am ie n to den tro de la dem ostra
3. Se llega a la condición c o n t únicam ente después de
ción. E sta su stitu c ió n lo c aliz a el arg u m en to de
hab er increm entado en 1 el v alo r de y . A d em ás, la
dem ostración en la estructura de control que se está
ruta de flujo de control que lleva a c o n t solam ente se
estudiando. D e hecho, perm ite al ingeniero del soft
puede invocar si la condición si tam b ién es v e rd a
w are realizar dem ostraciones en cualquier orden.
dera. C onsiguientem ente si M + 1 )2 < .v. se sigue que
y 2 < -v. La condición c o n t se satisface. ^ ¿ Qué es lo que se gana
4 . L a condición s i se com prueba en la lógica co n d icio * realizando las demostraciones
nal que se m uestra. C onsiguientem ente, la condición de corrección?
s i debe de ser v erd ad era cu an d o el flujo de control
pase p o r la v ía m ostrada. . E s im p o s ib le a s o c ia r u n a im p o r ta n c ia e x c e s iv a al
5. La condición salido exige, en prim er lugar, que v no e fe c to p o s it iv o q u e p o s e e s o b re la c a lid a d lo re d u c
haya cam biado. U n exam en del diseño indica que v c i ó n d e l a v e r i f i c a c i ó n a u n p r o c e s o f i n i t o . Aun
no aparece e n ningún lugar a la izq u ierd a de un ope cu an d o to d o s, sa lv o los p ro g ra m a s m ás triviales,

rador de asignación. N o hay n in g u n a llam ada a fu n - m uestran un conjunto, que en esencia es infinito, de
www.FreeLibros.org
’ U n v a lo r n e g a t iv o p a r a u n a r a ia c u a d r a d a c a re c e d e s ig n if ic a d o e n 4 E s ta s e c c ió n y la s F ig u r a s 2 6 7 h a s t a la 2 6 9 s e h a n a d a p ta d o de
e s te c o n t e x t o . IU 6 I9 4 ] S e u t iliz a n c o n p e r m is o d e l a u t o r
466
C A P Í T U L O 26 I N G E N I E R I A DEL S O F T W A R E D E S A L A L I M P I A
rutas de ejecución, se pueden verificar en un núm ero de acu erd o en que cada c o n d ició n es co rrec ta, por
finito de pasos. tanto, mi e rro r solam ente es posible si todos y cada
mío de los m iem bros del eq uipo verifican in co rrec
tam ente una condición. El requisito de acuerdo uná
CLAVE n im e b asad a en las v e rific a cio n e s in d iv id u ale s de
resultados da lugar a u n softw are que posee pocos o
A un cu an do en un p royrom o h ay uno contidod
extrem o d o m ente grand e d e fo rm a s de ejecución,
ningún defecto antes de su prim era ejecución.
lo s p o so s poro d e m o strar qu e u n proyrom o • T odo sistem a de so ftw are, in d e p e n
E s e s c c d a b le .
es correcto son m uy pocos. d ie n te m e n te de su ta m a ñ o , p o see unos p ro c e d i
m ie n to s de ca ja tran sp aren te del m ás a lto n iv el
[f 1] f 1 = [D O g 1; g 2; [ f 2] E N D I? form ados por estructuras de secuencia, alternancias
DO e iteraciones. C ada uno de estos invoca típicam ente
gi
g2 a un gran subsistem a que posee m iles de líneas de
[f2 ] f 2 = [W H IL E p1 D O [ f 3] E N D I ? có d ig o — cada uno de estos sub sistem as posee su
W H IL E p ropio nivel superior de funciones y procedim ientos
pl
DO [ f 3] f 3 = [D O g 3 ; [f4 ]; g 8 E N D I ? finales — . Por tanto, las condiciones de corrección
g3 para estas estructuras de control de alto nivel se veri
[f4 ] f4 = [IF p 2 ; T H E N [ f 5] ELS E [ f 6] E N D I ?
fican de la m ism a fo rm a en que se procede con las
IF
P2 estructuras de bajo nivel. Las verificaciones de alto
T H E N [f 5] f 5 = [D O g 4 ; g 5 E N D I ? nivel pueden requerir, y m erecerá la pena, mía m ayor
g4 cantidad de tiem po, pero no se necesita m ás teoría.
g5
ELSE [ f 6 ] f 6 = [D O g 6 ; g 7 E N D I ? • P r o d u c e u n c ó d ig o m e jo r q u e la c o m p r o b a c ió n u n i
g6 t a r i a . La c o m p ro b a c ió n u n itaria so la m e n te c o m
g?
EN D p ru e b a los e fe c to s de e je c u ta r v ía s de p ru e b a s
98 seleccionadas entre m uchas vías posibles. Al basar
EN D la verificación en la teoría de funciones, el enfoque
END
de sala lim pia puede v erificar todos y cada uno de
F IG U R A 2 6 .9 .Diseño con subdemostraciones [LIN94]. los p o sib les e fe c to s so b re los d a to s, p o rq u e aun
cuando mi program a pueda tener m últiples vías de
• P e r m it e q u e lo s e q u ip o s d e s a la l im p i a v e r ifiq u e n ejecución, solam ente posee mía función. La v erifi
L os diseños
to d a s la s lín e a s d e d is e ñ o y d e c ó d ig o . cación es, adem ás, m ás eficiente que la com proba
pueden efectu ar la verificación m ediante mi análisis c ió n u n itaria. La m a y o r de las c o n d ic io n e s de
y debate en grupo de las bases del teorem a de correc verificación se pueden verificar en unos pocos m inu
ción y pueden p ro d u cir p ruebas escritas cuando se tos, pero las com probaciones unitarias requieren una
necesite mía co n fia n z a ad icio n al en algún sistem a cantidad notable de tiem po para prepararlas, ejecu
crítico para vidas o m isiones. tarlas y com probarlas.
• D a l u g a r a u n n iv e l d e d efecto s p r ó x i m o a c e r o . E s im portante ten er en cuenta que la verificación de
Durante una revisión en equipo, se verifica por tu r diseño debe de aplicarse en últim a instancia al código
nos la corrección de todas y cada mía de las e stru c fuente en sí. En este contexto, suele denom inarse v e r -
turas de control. Cada m iem bro del equipo debe estar f ic a c ió n d e c o r r e c c ió n .
26. 4 P R U E B A DE S A L A L I M P I A
La táctica y estrategia de la prueba de sala limpia es algo El com portam iento visible para el usuario de ese p ro
fundam entalm ente distinto de los enfoques conv en cio gram a está co n tro lad o por las en trad as y sucesos que
nales de com probación. Los m étodos c o n v en cio n ales suelen ser producidos por el usuario. Pero en casos co m
derivan de casos de p ru eb a p ara d e sc u b rir e rro res de plejos, el espectro posible de entradas y sucesos (esto
diseño y de co d ificació n . E l o b je tiv o de los caso s de es, lo s c aso s p ráctic o s) p u ed e n ser e x tre m a d a m e n te
prueba de sala lim pia es v alid ar los req u isitos del so ft variables. ¿C uál es el su b co n ju n to de casos prácticos
ware m ediante la dem ostración de que mía m uestra esta que verifica adecuadam ente el com portam iento del pro
dística de casos prácticos (Capítulo 11) se han ejecutado gram a? Esta es la prim era cuestión que aborda la prue
con éxito. ba estadística de casos prácticos.
L a p ru eb a esta d ístic a de caso s « eq u iv ale a p ro b ar
el so ftw a re en la fo rm a en que los u su a rio s tie n e n
www.FreeLibros.org
26.4.1. Prueba e sta d ístic a d e c a so s prácticos intención de utilizarlo» [L1N94J. Para lo g rar esto, los
El usuario de un p ro g ram a de co m p u tad o ra n o suele e q u i p o s d e p r u e b a d e s a l a l i m p i a (tam bién llam ados
necesitar com prender los detalles técn ico s del diseño. e q u i p o s d e c e r t i f i c a c i ó n ) deben d e te rm in a r la d is tri
I NGE NIERÍA DEL S O F TW A RE . UN EN FOQ UE P R Á C T I C O
b u c ió n d e p r o b a b ilid a d d e u t iliz a c ió n c o r r e s p o n d ie n el intervalo de distribución que se m uestra en la tabla

te a l s o ftw a r e . L a e s p e c if ic a c ió n ( c a ja n e g r a ) d e c a d a anterior:
in c r e m e n t o d e l s o f t w a r e s e a n a liz a p a r a d e f in ir u n c o n
H D -P -H D -H D -H D -F Z
ju n t o d e e s tím u lo s ( e n tr a d a s o s u c e s o s ) q u e p u e d e n P -H D -H D -H D -C -H D -H D
d a r lu g a r a q u e e l s o ftw a r e m o d if iq u e s u c o m p o r ta
H D -H D -F Z -P -P -H D
m ie n t o . B a s á n d o s e e n e n tr e v is ta s c o n p o s ib le s u s u a
r io s , e n la c r e a c ió n d e e s c e n a r io s d e u t ili z a c ió n y e n El equipo de prueba ejecuta los casos prácticos indi
u n a c o m p r e n s ió n g e n e r a l d e l d o m in io d e la a p lic a cados anteriormente (y otros más) y verifica el compor
c ió n , s e a s ig n a u n a p r o b a b ilid a d d e u t ili z a c ió n a c a d a tam iento del software frente a la especificación del
u n o d e lo s e s t í m u lo s . sistema. La temporización de las pruebas se registra, de
L o s c a s o s p r á c tic o s s e g e n e r a n p a r a c a d a u n o d e lo s m odo que sea posible determ inar los intervalos tempo
e s tím u lo s ' d e a c u e r d o c o n la d is t r i b u c ió n d e p r o b a b ili rales. M ediante el uso de intervalos temporales, el equi
d a d d e u t ili z a c ió n . C o m o e je m p lo , c o n s id é r e s e e l s is t e po de certificación puede calcular el tiempo-mínimo-entre
m a d e s e g u r id a d H o g a r S e g u r o d e s c r it o a n t e r io r m e n t e fallos. Si se lleva a cabo una larga sucesión de pruebas
e n e s te lib r o . S e e s tá u t iliz a n d o la in g e n ie r í a d e l s o f t sin fallo, el TM EF es bajo, y se puede suponer que la fia
w a r e d e s a la l i m p i a p a r a d e s a r r o l l a r u n i n c r e m e n t o d e l bilidad del software es elevada.
s o f t w a r e q u e g e s tio n e la in t e r a c c ió n d e l u s u a r io c o n e l
t e c la d o d e l s is t e m a d e s e g u r id a d . P a r a e s te in c r e m e n t o 2 6 .4 .2 . C e r t i f i c a c i ó n
s e p u e d e n id e n t if ic a r c in c o e s tím u lo s . E l a n á lis is in d i
Las técnicas de verificación y prueba descritas ante
c a e l p o r c e n ta je d e p r o b a b ilid a d d e c a d a e s t í m u lo . P a r a
riorm ente en este capítulo dan lugar a com ponente5
h a c e r q u e s e a m á s s e n c illa la s e le c c ió n d e c a s o s d e p r u e
de software (y a increm entos com pletos) que se pue
b a , e s ta s p r o b a b i l i d a d e s s e h a c e n c o r r e s p o n d e r c o n i n t e r
den certificar. En el contexto del enfoque de la inge
v a lo s n u m e r a d o s e n tr e 1 y 9 9 [ L I N 9 4 ] , lo q u e s e m u e s t r a
n iería del softw are de sala lim pia, la c e r t i f i c a c i ó n
e n la ta b la s ig u ie n t e :
im plica que la fiabilidad (m edida por el tiem po míni
m o de fallo, TM D F) podrá ser especificada para cada
E stím ulos P ro b ab ilid ad In terv alo com ponente.
del p ro g ra m a El posible impacto de los componentes de software
certificables va más allá de mi sencillo proyecto de sala
h a b ilita r / limpia. Los com ponentes de s o ftw a re re u tiliz a b le s se
d e s h a b ilit a r ( H D ) 50% 1 -4 9 pueden almacenar ju n to con sus escenarios de utiliza
f ija r z o n a (F Z ) 15% 5 0 -6 3 ción, con los estím ulo\ del program a y con las corres
c o n s u lt a ( C ) 15% 6 4 -7 8 pondientes distribuciones de probabilidad. Cada uno de
los componentes dispondrá de una fiabilidad certifica
p ru e b a (P ) 15% 7 9 -9 4
da dentro del escenario de utilización y dentro del régi
alarm a (A) 5% 9 5 -9 9 m en de com probación d e s c rito . Esta inform ación es
sumamente valiosa p ara otras personas que tengan inten
P a ra g e n e ra r u n a s u c e s ió n d e c a s o s d e p r u e b a d e ción de utilizar estos componentes.
u t iliz a c ió n q u e s e a ju s te a la d is t r ib u c ió n d e p r o b a b i E1 enfoque de la certificación im plica cinco pasos
lid a d e s d e u t il i z a c i ó n , s e g e n e r a u n a s e r ie d e n ú m e [W OH 94J:
r o s a le a t o r io s e n tr e 1 y 9 9 . E l n ú m e r o a le a t o r io 1. Es preciso crear escenarios de utilización.
c o r r e s p o n d e a l in t e r v a lo d e d is t r ib u c ió n d e p r o b a b i
2. Se especifica un perfil de utilización.
lid a d a n te r io r m e n te d e s ta c a d o . C o n s ig u ie n te m e n te , la
3. Se generan casos de prueba a partir del perfil.
s u c e s ió n d e c a s o s p r á c tic o s s e d e f in e a le a t o r ia m e n te
p e r o s e c o r r e s p o n d e c o n la p r o b a b ilid a d c o r r e s p o n 4. Se ejecutan pruebas y los datos de los fallos se
d ie n t e d e a p a r ic ió n d e e s e e s tím u lo . P o r e je m p lo , registran y se analizan.
s u p o n g a q u e s e g e n e r a n la s s i g u i e n t e s s u c e s i o n e s d e 5. Se calcula y se certifica la fiabilidad.
n ú m e r o s a le a t o r io s
^ ¿ Cómo se certifica un
• componente de software?
3 8 -2 1 -5 2 -8 4 -8 6 -4
Los pasos 1 a 4 se han descrito en secciones ante
S e d e r iv a n lo s s ig u ie n t e s c a s o s p r á c t ic o s m e d ia n riores. En esta sección, nos concentram os en la certifi
te la s e le c c ió n d e lo s e s t í m u lo s a d e c u a d o s b a s a d o s e n cación de fiabilidad.
www.FreeLibros.org
5 Se utilizan herram ientas autom atizadas con este fin Para m as infor
m a c io n , v e a s e [D Y E 9 2 |
468
C A PI T U L O 26 INGENIERIA DEL S O F T W A R E D E S A L A LIMPIA
La certificación para la ingeniería del software de sala M odelo de Certificación. Se estima y certifica la fia
limpia requiere la creación de tres modelos [P 0 0 3 4 ]: bilidad global del sistema.
M odelo de m uestreo. La com probación de softw a Al final de la prueba estadística de utilizació n , el
re ejecuta m casos de prueba aleatorios, y queda certi equipo de certificación posee la inform ación necesaria
ficada si n o se produce ningún fallo o si se produce un para proporcionar un software que tenga un T M E F cer
número de fallos inferior al especificado. El valor de m tificado que se habrá calculado em pleando todos estos
se deriva m atemáticamente para asegurar que se alcan modelos.
ce la fiabilidad necesaria. Una descripción detallada del cálculo de los m ode
Modelo de com ponentes. Es preciso certificar un sis los de muestreo, de componentes y de certificación va
tema compuesto por n componentes. El modelo de com más allá del alcance de este libro. El lector interesado
ponentes capacita al analista para detenninar la probabilidad encontrará detalles adicionales en [M US87], [CUR86J
de que falle el componente í antes de finalizar el programa. y [P 0 0 9 3 ],
RESUMEN
La ingeniería del software de sala lim pia es un enfoque definen condiciones de salida para cada una de las sub
formal para el desarrollo del software, que puede dar funciones y se aplica un conjunto de subpruebas. Si se
lugar a u n software que posea una calidad notablem en satisfacen todas y cada una de las condiciones de sali
te alta. Emplea la especificación de estructura de cajas da, entonces el diseño debe ser correcto.
( o métodos form ales) para el m odelado d e análisis y U na vez finalizada la verificación de co rrecció n ,
diseño, y hace hincapié en la verificación de la correc com ienza la prueba estadística de utilización. A d ife
ción, m ás que en las pruebas, com o mecanismo funda rencia de la comprobación condicional, la ingeniería del
mental para hallar y elim inar errores. Se aplica una software de sala limpia no hace hincapié en la prueba
prueba estadística de utilización para desarrollar la infor unitaria o de integración. En su lugar, el softw are se
mación de tasa de fallos necesaria para certificar la fia com prueba m ediante la definición de un conjunto de
bilidad del software proporcionado. escenarios, mediante la determinación de las probabi
El enfoque de sala limpia comienza por unos modelos lidades de utilización de cada uno de esos escenarios y
de análisis y diseño que hacen uso de una representación mediante la aplicación posterior de pruebas aleatorias
de estructura de cajas. Una «caja» encapsula el sistema (o que satisfagan estas probabilidades. Los registros de
algún aspecto del sistema) en un determ inado nivel de error resultantes se combinan con modelos de muestreo,
abstracción. Se utilizan cajas negras para representar el de componentes y de certificación para hacer posible el
comportamiento observable externamente de ese sistema. cálculo matemático de la fiabilidad estimada de ese com
Las cajas de estado encapsulan los datos y operaciones de ponente de software.
ese estado. Se utiliza una caja limpia para modelar el dise La filosofía de sala limpia es un enfoque riguroso de
ñ o de procedimientos que está implicado por los datos y la ingeniería del software. Se trata de un modelo de pro
operaciones de la caja de estados. ceso del software que hace hincapié en la verificación
Se aplica la verificación de corrección una vez que m atem ática de la corrección y en la certificación de la
está completo el diseño de estructura de cajas. El dise fiabilidad del software. El resultado final son unas tasas
ño de procedimientos para un componente de software de fallo extremadamente bajas, que sería difícil o im po
se desglosará en una serie de subfunciones. Para dem os sible de conseguir empleando unos métodos menos for
trar la corrección de cada una de estas subfunciones, se males.
R E FER ENC IA S
[CUR86] Currit, P.A., M. Dyer y H.D. Mills, «Certifying the [HEN95] Elenderson, J., «Why isn’t cleanrooin the Univer
Reliability of Software»,IEÉE Trcms. Software Enginee- sal Software Development Methodology?». Crosstalk, vol.
ríng, vol. SE-12,n." l,E n ero d e 1994. 8 , n.- 5, Mayo de 1995,pp. 11-14.
[DYE92] Dyer, M., The Cleanroom Appwach to Quality Soft [HEV93] Elevner,A.R., y H.D. Mills,«Box Structure Methods
ware Development, Wiley, 1992. for System Development with Objects», IBM Systems Jour
nal, vol. 3 l,n." 2, Febrero de 1993,pp. 232-251.
[HAU94] Elausler, P.A., R. Linger y C. Trammeb «Adopting
www.FreeLibros.org
Cleanroom Software Engineering with a phased Appro- [LIN79] Linger, R. M., H. D. Mills y B.l. Witt, Structured
ach»,/ÜA/ Systems Journal, vol. 33, n." 1, Enero de 1994, Programming: Theory and Practice, Addison-Wesley,
pp. 89-109.' 1979.
469
IN GENIERÍA D E L S O F T W A R E . U N E N F O Q U E P R Á C T I C O
[LIN88] Linger, R. M., y H. D. Mills, «A Case Study in Cle- [MUS87] Musa, J.D., A . Iannino y K. Okumoto, E n g in e e r in g
anroom Software Engineering: The IBM COBOL Struc- u n d M a n a g i n g S o ftw a r e w ith R e l i a b il i tv M e a s u r e s ,
turing Facility», P ro c . C O M P S A C ' 88 , Chicago, Octubre McGraw-Hill, 1987. '
de 1988. [POO 88] Poore, J. H., y H.D. M ills, «Bringing Software
[LIN94] Linger, R., «Cleanroom Process Model»,/??.??.?? S o ft Under Statistical Quality Control», Q u a lity P r o g r e s s ,
w a re , v o l. 11, n.a 2, Marzo de 1994,pp. 50-58. Noviembre de 1988, pp. 52-55.
IMIL87] Mills, H.D.,M. D yery R. Linger, «Cleanroom Soft [P0093J Poore, J. H., H.D. Mills y D. Mutchler, «Planning
ware Engineering», I E E E S o ftw a r e , vol. 4, n.° 5, Sep and Certifying Software System Reliability», I E E E S o ft
tiembre de 1987,pp. 19-24. w a re , vol. 10,n.Q 1, Enero de 1993,pp. 88-99.
[MIL 88] Mills, H.D., «Stepwise Refinement and Verification [WOH94] Wohlin, C., y P. Runeson, «Certification of Soft
in Box StructuredSystems», C o m p u te r , vol. 21, n.- 6 , Junio ware Components», I E E E T ra n s, S o ftw a r e E n g in e e r in g ,
de 1988, pp. 23-35. vol. 20, n.y 6, Junio de 1994,pp. 494-499.
PROBLEMAS Y PUNTOS A CONSIDERAR

26.1. Si tuviera que seleccionar un aspecto de la ingeniería del Descomponer el diseño en subfunciones y definir un conjun
software de sala limpia que la hiciera radicalmente distinta de to de condiciones que hagan posible demostrar que este algo
los enfoques convencionales u orientados a objetos de la inge ritmo es correcto.
niería del software, ¿cuál sería'?
26.7. Documentar una demostración de verificación de correc
26.2. / Cómo se combinan el modelo de proceso incremental ción para la ordenación por el método de la burbuja descrita
y el trabajo de certificación para construir un software de ele en el Problema 26.6.
vada calidad'! 26.8. Seleccionar un componente de programa que se haya
26.3. Empleando la estructura de especificación de cajas, desa diseñado en otro contexto (o bien asignado por el instruc
rrollar u n análisis de «primer paso» y unos modelos de dise tor) y desarrollar para él una dem ostración completa de
ñ o para el sistema H o g a r S e g u r o . corrección.
26.4. Desarrolle una especificación de estructura de cajas para 26.9. Seleccionar un programa que se utilice regularmente (por
una parte del sistema SSRB presentado en el Problema 12.13. ejemplo, un gestor de correo electrónico, un procesador de
texto, una hoja de cálculo). Crear un conjunto de escenarios
26.5. Desarrolle una especificación de estructura de cajas para
de utilización para ese programa. Definir la probabilidad de
el sistema de correo electrónico en el Problema 21.14.
utilización de cada escenario y desarrollar entonces una tabla
26.6. Se define el algoritmo de ordenación por el método de de estímulos del programa y de distribución de probabilida
las burbujas de la forma siguiente: des parecida a la que se muestra en la Sección 26.4.1.
26.10. Para la tabla de estímulos del programa y de distribu
ción de probabilidades desarrollada en el Problema 26.9, uti
lizar un generador de números aleatorios con objeto de
desarrollar un conjunto de casos de prueba para utilizarlo en
una prueba estadística de utilización.
for j := 2 t o n do
26.11. Con sus propias palabras, describa el objetivo de la cer
tificación en el contexto de la ingeniería del software de sala
limpia.
26.12. Escribir un pequeño'trabajo que describa las matemá
rrh' ticas utilizadas para definir los modelos de certificación des
critos brevemente en la Sección 26.4.2. Utilícense [MUS87],
eni LCUR86] y [POP93] como punto de partida.
OTRAS LECTURAS Y FUENTES DE INFORM ACIÓN

Prowell et al. (C le a n r o o m S o ftw a r e E n g in e e r in g : T e c h n o excelente para aquellas personas que no estén familiarizadas
lo g y and P r o c e s s , A ddison-W esley, 1999) describe con con las prácticas de sala limpia.
profundidad todos los aspectos importantes del enfoque de T h e C le a n r o o m P a n p h le t (Software Technology Support
sala limpia. Estudios Utiles sobre los temas de sala limpia Center, Hill AF Base, UT, abril 1995) contiene reimpresiones
www.FreeLibros.org
han sido editados por Poore y Trammell ( C le a n r o o m S o f t de varios artículos importantes. Linger [L1N94] es una de las
w a r e : A R e a d e r , Blackwell Publishing, 1996). Becker y mejores introducciones a este tema. A s s e t S o u r & e fo t S o ftw a
W hittaker ( C le a n r o o m S o f tw a r e E n g in e e r i n g P r a c ti c e s , re E n g in e e r in g T e c h n o lo g y , ASSET (Departamento de Defen
Idea Group Publishing, 1996) presentan una visión general sa americano) ofrece u n conjunto excelente de seis volúmenes
470
C A P Í T U L O 26 I N GE NIE RÍ A DEL SO F T W A R E DE S A L A LIMPIA
de C leanroom E n gin eerin g H a n dbooks. Se puede contactar Deck, M.D., «Using Box Structures to Link Cleanroom
con ASSET en info@source.asset.com. Lockheed Martin ha and Object-Oriented Software Engineering», Technical R eport
preparado la guía G iiide to the Integration o f O b ject-O rien - 94.01h , Cleanroom Software Engineering Inc., Boulder, CO,
tedM ethods an d C leanroom Software Engineering (1997) que 1994.
contiene un proceso genérico de sala limpia para sistemas ope Dyer, M. «Designing Software for Provable Correctness:
rativos y está disponible en: the direction for quality softwar e»,In form ation a n d S o ftw a
http://www.asset.com/stars/cleanroom/oo/guidhome.htm re Technology, \o \. 30, n.y 6, Julio/Agosto de 1988, pp. 331
340. '’
Linger y Trammell (C le a n ro o m S o ftw a re E n g in eerin g
Referent e M o d el, SEI Technical Report CMU/SEI-96-TR- Pruebas y C ertificación
022, 1996) han definido un conjunto de 14 procesos de sala Dyer, M .,«A n Approach to Software Reliability Measu-
limpia y 20 productos de trabajos que forman la base del SEI rement», Inform ation an d Softw are Technology, vol. 29, n.ü
CMM para la ingeniería del software de sala limpia 8 , Octubre de 1987,pp. 415-420.
(CMU/SEI-96-TR-023). Head, G.E., «Six-Sigma Software Using Cleanroom Soft
Michael Deck, de Cleanroom Software Engineering, Inc., ware Engineering Techniques», H e w le tt-P a c k a rd Jou rn al,
ha preparado una bibliografía sobre temas de sala limpia. Juniode 1994,pp. 40-50.
Entre las referencias se encuentran las siguientes: Oshana, R., «Quality Software via a Cleanroom Metho-
Generales e Introductorias dology», E m h ed d ed S ystem s P ro g ra m m in g , Septiembre de
Deck, M.D., «Cleanroom Software Engineering Myths 1996,pp. 36-52. ’ ' "
andRealities», O u alitv Week 1997, San Francisco, C A, Mayo Whittaker, J.A., y Thomason, M.G., «A Markov Chain
de 1997. ~ ' ' Model for Statistical Software Testing», IEEE Trans. on Soft-
Deck, M.D, y J.A. Whittaker, «Lessons Learned from Fif- wure E n gin eerin g, Octubre de 1994, pp. 8 12-824.
teen Years of Cleanroom Testing», Software Testing, A nalysis,
Estudios de casos e inform es experim entales
andR eview (STAR) '97, San José, CA, 5-9 de Mayo de 1997.
Head, G.E., «Six-Sigma Software Using Cleanrooin Soft
Lokan, C. J., «The Cleanroom for Software Development»,
ware Engineering Techniques», Hewlett-Packard Journal,
The Australian C om pu ter Journal, vol. 25, n.e 4, Noviembre
Juniode 1994,pp. 40-SO.
de 1993.
Hevner, A.R., y H.D. Mills, «Box-structured methods for
Linger, Richard C., «Cleanroom Software Engineering for
systems development with objects», IB M system s Journ al,
Zero-Defect Software», P roc. 15 th In tern a tio n a l Conferen-
vol. 32, nP 2, 1993,pp. 232-251. ’
ce Internationul on Software E ngineering, Mayo de 1993.
Keuffel, W., «Clean YourRoom: Formal Methods forthe Tann, L-G., «OS32 and Cleanroom», P ro c. !st A n im al
European Industrial Symposium on Cleanroom Software Engi
90’s», C om pu ter L anguage, Julio de 1992, pp. 39-46.
n eerin g, Copenhagen, Denmark, 1993, pp. 1-40.
Hevner, A.R, S.A. Becker y L.B. Pedowitz, «Integrated
CASE for Cleanroom Development», IE E E Softw are, M ar Hausler, P.A., «A Recent Cleanroom Success Story: The
zo de 1992, pp. 69-76. Redwing Project», P roc. 17 * A n im al Softw are E ngineering
Cobb, R.H. y H.D. Mills, «Engineering Software under W orkshop, NASA Goddard Space Flight Center, Diciembre
Statistical Quality Control», IE E E S oftw are, Noviembre de de 1992.
1990,pp. 44-45.' Trammel, C.J., Binder L.H. y Snyder, C.E., «The Auto-
mated Production Control Documentation System: A Case
Practicas de Gestión Study in Cleanroom Software Engineering», A C M Trans. on
Becker, S.A.,M.D. Deck y T. Janzon, «Cleanroom and Orga- Softw are E n gin eerin g and M ethoclology, vol. 1, flj-’ 1, Enero
nizational Change », Proc. I4 ,h Pacific Nortlm ’est Software Qua- de 1992,pp. 81-94. ’
lity Conference, Portland, OR, 29-30 de Octubre de 1996.
La verificación de diseños mediante pruebas de correc
Linger, R.C., «Cleanroom Process Model», IE E E Soft ción se encuentra en el centro del enfoque de sala limpia. En
ware, marzo de 1994, pp. 50-58. los libros de Baber (E rro r-F ree S o ftw a re , Wiley, 1991) y
Linger, R.C. y Spangler, R.A., «The IBM Cleanroom Soft Schulmeyer (Zero D e je c t Softw’are, McGraw-Hill, 1990) se
ware Engineering Technology Transfer Program», Sixth SEI estudia la prueba de corrección de forma m u y detallada.
Conference on Software E n gin eerin g E du cation , San Diego,
En Internet se puede encontrar disponible mucha infor
CA, Octubre de 1992.
mación variada sobre la ingeniería del software dc sala lim
Especificación, D iseño y R evisión pia y sobre temas relacionados. Para conseguir una lista
Deck, M.D., «Cleanroom and Object-Oriented Software actualizada de referencias que sea relevante para la ingenie
Engineering: A Unique Synergy», I Y 96Softw are Technology ría del software de sala limpia se puede visitar http://w w w
Conference, SaltLake City, UT, 24 de Abril de 1996. pressm an5.com
www.FreeLibros.org 47 1
www.FreeLibros.org
CAPÍTULO
— IN G E N IE R ÍA DEL S O FTW A R E
/ / B A SA D A EN C O M P O N E N T E S
N e l c o n te x to d e la in g e n ie ría d e l s o ftw a re , la re u tiliz a c ió n se p u e d e c o n s id e ra r u n a id e a
E n u e v a y a n tig u a . L o s p ro g ra m a d o re s h a n re u tiliz a d o id ea s , a b strac cio n es y p ro ceso s d e s

d e e l p rin c ip io d e la e ra de lo s c o m p u ta d o re s , p e ro e l p rim e r e n fo q u e d e re u tiliz a c ió n e ra
m u y c o n c re to . H oy e n d ía , lo s sistem as c o m p le jo s y d e a lta c a lid a d basados e n c o m p u ta d o ra s
d e b e n c o n s tru ir e n p e río d o s d e tie m p o m u y cortos. E s to se m itig a c o n u n e n fo q u e d e r e u tiliz a
c ió n m á s o rg a n iz a d o .
La ingenieríadel software basada en componentes ( IS B C ) es u n p ro c e s o q u e se c e n tra en
e l d is e ñ o y c o n s tru c c ió n d e sistem as basados e n c o m p u ta d o ra que u tiliz a n « c o m p o n e n te s » d e
s o ftw a re re u tiliz a b le s . C le m e n ts [ C L E 9 5 ] d e s c rib e la IS B C d e la m a n e ra s ig u ie n te :
[La ISBC] está cambiando la forma en que se desarrollan los sistemas de software. [La ISBC] repre
senta la filosofía de «comprar.no construir», que expusieronFred Brooks y otros. De la misma manera que
las primeras subrutinas liberaban al programador de tener que pensar en detalles, [ISBC] cambia su objeti
vo y pasa de programar el software a componer sistemas d e software. La implementación ha dado paso a
la integración como núcleo del enfoque. Se puede decir que en su base se encuentra la suposición d e que
en muchos sistemas grandes de software existe una base común suficiente como para justificar los compo
nentes reutilizables para explotar y satisfacer a esa base común.
S in e m b a rg o , surgen m u c h as preguntas. ¿Es p o s ib le c o n s tru ir sistem as c o m p le jo s e n s a m b lá n

d o lo s a p a rtir de un c a tá lo g o de c o m p o n e n te s de s o ftw a re re u tiliza b le s ? ¿Se puede c o n se g u ir d e una
m a n e ra re n ta b le y e n p o c o tie m p o ? ¿Se p u e d e n e stab lecer in c e n tiv o s p a ra a n im a r a que los in g e
nieros del s o ftw a re re u tilic e n y n o re in v e n te n ? ¿Están dispuestos los d ire c tiv o s a c o n tra e r los gastos
VI STAZO RÁPI DO
¿Qué es? Compre un equipo de música diciendo que los sistemas basados en en la arquitectura del sistema; (3)adap-
estéreo y lléveselo a casa. Cada com componentes son más fáciles de ta los componentes si se deben hacer
ponente ha sido diseñado para aco ensamblar y, por tanto, más caros de modificaciones para poderlos integrar
plarse en un estilo arquitectónico construir a partir de piezas separadas. adecuadamente; (4) integra los compo
específico—las conexiones son están Además, la ISBC hace hincapié en la nentes para formar subsistemas y la
dar y puede preestablecerse el protoco utilización de patrones arquitectónicos aplicación completa. Además, loscom-
lo de comunicación—. El ensamblaje es predecibles y en una infraestructura de ponentes personalizados se han dise
fácil porque el sistema no tiene que software estándar, lo que lleva a un ñado para afrontar esos aspectos del
construirse a partir de piezas por sepa resultado de calidad superior. sistema que no pueden implementarse
rado. La ingeniería del software basa utilizando componentes que ya existen.
;Cuáles son los p aso s? La ISBC acom
da en componentes (ISBC) lucha por ¿Cuál e s e l p ro d u c to o b te n id o ? El
paña a dos actividades de ingeniería
conseguir lo mismo. Un conjuntode com producto de la ISBC es el software ope-
paralelas: la ingeniería del dominio y
ponentes de software preconstruidos y racional ensamblado utilizando los
el desarrollo basado en componentes.
estandarizados están disponibles para componentes de software existentes y
La ingeniería del dominio explora un
encajar en un estilo arquitectónicoespe- los que se acaban de desarrollar.
dominio de aplicaciones con la inten
cífico pura algún dominiode aplicación.
ción de encontrar específicamente los ¿Cómo p u e d o e s ta r se g u r o d e q u e
la aplicación se ensambla entonces uti
componentes de datos funcionales y de lo h e h ech o correcta m en te? Utili
lizando estos componentesy no las .pie
comportamiento candidatos para la zando las mismas prácticas SQA que
zas por separado. de un lenguaje de
reutilización. Estos componentes se se aplican en todos los procesos de
programación convencional.
encuentran en bibliotecas de reutiliza ingeniería del software—las revisio
;Q uién lo h a c e ? Los ingenieros del ción. El desarrollo basado en compo nes técnicas formales evalúan los
software. nentes obtiene los requisitos del cliente modelos de análisis y diseño — : las
¿Por q u é e s im p ortan te? La instala y selecciona el estilo arquitectónico revisiones especializadas tienen en
ción del equipo estéreo solo lleva unos adecuado para cumplir los objetivos consideración temas asociados con los
pocos minutos, porque los componen del sistema que se va a construir, y a componentes adquiridos; y la compro
tes están diseñados para integrarse continuación: (1) selecciona posibles bación se aplica para descubrir errores
con facilidad. Aunque el software es componentes para la reutilización; (2) en el software nuevo y en componentes
www.FreeLibros.org
considerablemente más complejo que cualifica los componentes para asegu reutilizables que se hayan integrado en
el sistema estéreo, se puede seguir rarse de que encajan adecuadamente la arquitectura.
473
IN G E N IE R Í A DEL SOFTW ARE . UN EN F O Q U E P R A C T I C O
añadidos y asociados con la c re a c ió n de c o m p o n e n te s de s o ftw a re re u tiliza b le s ? ¿Se p u e d e c re a r u n a b ib lio te c a c o n los

c o m p o n e n te s necesarios para lle v a r a c a b o la re u tiliz a c ió n de m a n e ra accesib le p a ra a q u ello s que la necesitan?
Estas y o tra s p re g u n ta s s ig u e n v iv o s e n la c o m u n id a d d e in v e s tig a d o re s y d e p ro fe s io n a le s d e la in d u s tria que
lu c h a n p o r h a c e r q u e la re u tiliz a c ió n d e c o m p o n e n te s d e s o ftw a re sea e l e n fo q u e m á s c o n v e n c io n a l d e la in g e n ie
r ía d e l s o ftw a re . A lg u n a s de estas p re g u n ta s se e s tu d ia n e n este c a p ítu lo .
S u p e rfic ia lm e n te , la I S B C p a re c e b a stan te s im ila r a la

¿Cuáles son las actividades
in g e n ie ría d e l s o ftw a re o rie n ta d a a o b je to s . E l p ro ce so
c o m ie n z a c u a n d o u n e q u ip o d e s o ftw a re e sta b lec e los
re q u is ito s d e l s is te m a que se v a a c o n s tru ir u tiliz a n d o las
técn icas c o n v e n c io n a le s d e o b ten ció n de re q u isito s (C a p í
• del marco de trabajo ISBC?
Adaptación de componentes. E n e l C a p ítu lo 14 se

s e ñ a ló q u e la a rq u ite c tu ra d e l s o ftw a re re p re s e n ta los
tu lo s 1 0 y 11). Se e s ta b le c e u n d is e ñ o a rq u ite c tó n ic o
p a tro n e s de d is e ñ o que está n c o m p u es to s de c o m p o n e n
(C a p ítu lo 1 4 ), p e ro e n lu g a r de e n tra r in m e d ia ta m e n te en
tes (u n id a d e s de fu n c io n a lid a d ), c o n e x io n e s y c o o rd in a
ta re as de d is e ñ o d e ta lla d a s , e l e q u ip o e x a m in a los r e q u i
c ió n . E s e n c ia lm e n te la a rq u ite ctu ra d e fin e las n o rm a s del
sitos p a ra d e te rm in a r c u á l es e l subsistem a que está d is
diseñ o de todos los co m p o n e n te s, id en tific a n d o los m odos
p u e s to p a ra la composición, y n o p a ra la c o n s tru c c ió n .
d e c o n e x ió n y c o o rd in a c ió n . E n a lg u n o s casos, es p o s i
E s to es, el e q u ip o fo rm u la las sigu ientes p re g u n ta s p a ra
b le q u e lo s c o m p o n e n te s r e u tiliz a b le s a c tu a le s n o se
to d o s y cad a u n o d e los re q u isito s d e l sistem a:
c o rre s p o n d a n c o n las n o rm a s d e l d is e ñ o d e la a rq u ite c
« ¿Es p o s ib le d is p o n e r d e c o m p o n e n te s c o m e rc ia le s tu ra . E stos c o m p o n e n te s d e b e n d e ad ap tarse p a ra c u m
y a d e s a rro lla d o s ( C Y D ) p a ra im p le m e n ta r e l r e q u i p lir las n e c e s id a d e s d e la a rq u ite c tu ra o d e s c a rta rs e y
sito? re e m p la z a rs e p o r o tro s c o m p o n e n te s m ás adecuad os.
• ¿Se d is p o n e d e c o m p o n e n te s re u tiliz a b le s d e s a rro
lla d o s in te rn a m e n te p a ra im p le m e n ta r e l re q u is ito ?
• ¿S on c o m p a tib le s las in te rfa c e s d e lo s c o m p o n e n te s
q u e está n d is p o n ib le s d e n tro d e la a rq u ite c tu ra d e l '• V ; •• . en t» futuro próximo lo m ayoría
software se ensamblarán
s is te m a a c o n stru ir?
,v . ponentes, y no se construirán
E l e q u ip o in te n ta m o d ific a r o e lim in a r a q u ello s re q u i
sito s d e l s is te m a q u e n o se p u e d e n im p le m e n ta r c o n (M i& yStM rtFrest
c o m p o n e n te s C Y D o d e d e s a rro llo p ro p io '. S i lo s r e q u i
sitos n o se p u e d e n n i c a m b ia r n i b o rra r, se a p lic a n m é to Composición de componentes. E l e s tilo a rq u ite c
d o s d e in g e n ie r ía d e l s o ftw a r e c o n v e n c io n a le s u tó n ic o v u e lv e a ju g a r u n p a p e l c la v e e n la fo rm a e n que
o rie n ta d o s a o b je to s p a ra d e s a rro lla r lo s c o m p o n e n te s lo s c o m p o n e n te s d e l s o ftw a re se in te g ra n p a ra fo rm a r
n u e v o s que se d e b e n d is e ñ a r p a ra c u m p lir lo s re q u is i u n s is te m a d e tra b a jo . M e d ia n te la id e n tific a c ió n d e los
tos. P e ro p a ra esos re q u is ito s q u e se a fro n ta n c o n los m e c a n is m o s d e c o n e x ió n y c o o rd in a c ió n (p o r e je m p lo ,
c o m p o n e n te s d is p o n ib le s c o m ie n z a u n c o n ju n to d ife las p ro p ie d a d e s d e e je c u c ió n e n e l d is e ñ o ), la a rq u ite c
re n te d e a c tiv id a d e s d e in g e n ie ría d e l s o ftw a re : tu ra d ic ta la c o m p o s ic ió n d e l p ro d u c to fin a l.
Cualificación de componentes. L o s re q u is ito s d e l Actualización de componentes. C u a n d o se im p le -
s is te m a y la a rq u ite c tu ra d e fin e n lo s c o m p o n e n te s que m e n ta n sistem as c o n c o m p o n e n te s C Y D , la a c tu a liz a
se v a n a necesitar. L o s c o m p o n e n te s re u tiliz a b le s (ta n c ió n se c o m p lic a p o r la im p o s ic ió n de u n a te rc e ra parte
to si son C Y D c o m o de d e s a rro llo p ro p io ) se id e n tific a n (es d e c ir, es p o s ib le q u e la e m p re s a q u e d e s a rro lló el
n o rm a lm e n te m e d ia n te las c a ra c te rís tic a s d e sus in te r c o m p o n e n te re u tiliz a b le n o te n g a e l c o n tro l d e la e m p re
faces. E s d e c ir, se d e s c rib e n « lo s s e rv ic io s que se p r o sa d e in g e n ie ría d e l s o ftw a re ).
p o r c io n a n y e l m e d io p o r e l q u e lo s c o n s u m id o re s T o d a s y c a d a u n a d e las a c tiv id a d e s IS B C se e s tu
a c c e d e n a estos s e rv ic io s » [ B R 0 9 6 ] c o m o p a rte d e la d ia n m á s p ro fu n d a m e n te e n la S e c c ió n 2 7 .4 .
in te rfa z d e l c o m p o n e n te . P e ro la in te rfa z n o p ro p o rc io E n la p rim e ra p a rte d e esta s e c c ió n e l té rm in o « c o m
na u n a im a g e n c o m p le ta d e l a c o p le d e l c o m p o n e n te en p o n e n te » se h a u tiliz a n d o e n re p e tid a s o cas io n es , a pesar
la a rq u ite c tu ra y e n lo s re q u is ito s . E l in g e n ie ro d e l s o ft de q u e es d if íc il de e fe c tu a r u n a d e s c rip c ió n d e fin itiv a
w a re d e b e d e u tiliz a r u n p ro c e s o de d e s c u b rim ie n to y de d e l té rm in o . B r o w n y W a lln a u [ B R 0 9 6 ] s u g ie re n las
a n á lis is p a ra c u a lific a r e l a ju s te d e c a d a c o m p o n e n te . s ig u ie n te s p o s ib ilid a d e s :
1 La implicación es que la organización ajusta sus requisitos com er
www.FreeLibros.org
ciales o del producto de m anera que se puede lograr la im plem enta-
ción b asada en com p o n en tes sin la necesidad de una ingeniería
personalizada. Este enfoque reduce el coste del sistem a y mejora el
tiempo de com ercialización, pero no siempre es posible.
474
CAPITULO 27 I N GE NIE RÍ A DEL SOFTWARE B A SA D A EN C O M P O N E N T E S
• c o m p o n e n te - u n a p a r t e r e e m p l a z a b l e , c a s i i n d e p e n c io n a lid a d s in o ta m b ié n e l r e n d im ie n to , la f i a b i lid a d y
d ie n t e y n o t r iv ia l d e u n s is t e m a q u e c u m p le u n a f u n o t r o s f a c t o r e s d e c a lid a d ( C a p í t u lo 1 9 ) e n c a ja n c o n lo s
c ió n c la r a e n e l c o n t e x t o d e u n a a r q u it e c t u r a b ie n r e q u is it o s d e l s is t e m a /p r o d u c to q u e s e v a a c o n s t r u ir ;
d e f in id a ;
• com ponente d el softw are en e je c u c ió n - u n p a q u e t e G s sm s E E zm
d in á m ic o d e u n ió n d e u n o o m á s p r o g r a m a s g e s tio b certificación de componentesse puede realizar
con losmétodos de salo limpia. Para obtener
n a d o s c o m o u n a u n id a d , a lo s q u e s e a c c e d e a tr a v é s
más información consulteelCopftulo 26.
d e in te r fa c e s d o c u m e n ta d a s q u e s e p u e d e n d e s c u b r ir
e n la e je c u c ió n ;
• com ponentes a d a p ta d o s- a d a p t a d o s p a r a m o d i f i c a r
• com ponente de s o ftw a r e - u n a u n i d a d d e c o m p o s i ( t a m b ié n lla m a d o s « e n m a s c a r a d o s » o « e n v o lt o r io s » )
c ió n q u e s o lo d e p e n d e d e l c o n t e x t o c o n tr a c tu a l d e
[ B R 0 9 6 ] la s c a r a c t e r í s t i c a s n o d e s e a d a s .
f o r m a e s p e c íf ic a y e x p lí c it a ; . com ponentes en sa m b la d o s- i n t e g r a d o s e n u n e s t i l o
• com ponente de n e g o c io - l a i m p l e m e n t a c i ó n d e s o f t a r q u it e c t ó n ic o e in t e r c o n e c t a d o s c o n u n a in f r a e s
w a re d e u n c o n c e p to c o m e r c ia l « a u tó n o m o » o d e u n t r u c t u r a d e c o m p o n e n te s a d e c u a d a q u e p e r m it e c o o r
p r o c e s o c o m e r c ia l; d in a r y g e s tio n a r lo s c o m p o n e n te s d e f o r m a e f ic a z ;
A d e m á s d e la s d e s c r i p c i o n e s a n t e r i o r e s , l o s c o m p o • c o m p o n en te s a c tu a liza d o s- e l s o f t w a r e a c t u a l s e
n e n te s d e l s o f t w a r e t a m b i é n s e p u e d e n c a r a c t e r i z a r p o r e l r e e m p la z a a m e d id a q u e s e d is p o n e d e n u e v a s v e r
u s o e n e l p r o c e s o I S B C . A d e m á s d e lo s c o m p o n e n t e s C Y D , s io n e s d e c o m p o n e n t e s ;
e l p r o c e s o I S B C p r o d u c e lo s s ig u ie n t e s c o m p o n e n t e s : D a d o q u e la IS B C e s u n a d is c ip lin a e n e v o lu c ió n , n o
• com ponentes c u a lific a d o s- e v a l u a d o s p o r l o s i n g e e s p r o b a b le q u e e n e l f u t u r o s u r ja u n a d e f in ic ió n u n i f i
n ie r o s d e s o f t w a r e p a r a a s e g u r a r q u e n o s ó lo la f u n cada.
,»2lZt.2L E3* JE B LQ G I O D E 1 BiGL

E n e l C a p ítu lo 2 , se u t ili z ó u n « m o d e lo d e d e s a r r o llo E l m o d e lo d e p r o c e s o p a r a la in g e n ie r í a d e l s o f t w a
b a s a d o e n c o m p o n e n te s » ( F ig . 2 .1 2 ) p a r a ilu s t r a r la f o r r e b a s a d a e n c o m p o n e n t e s h a c e h in c a p ié e n la s p is t a s
m a e n q u e s e in t e g r a u n a b ib lio t e c a d e « c o m p o n e n te s p a r a l e l a s e n la s q u e a p a r e c e c o n c u r r e n t e m e n t e l a i n g e
c a n d id a t o s » r e u t i l i z a b l e s e n u n m o d e l o t í p i c o d e p r o n ie r ía d e l d o m in io ( S e c c ió n 2 7 .3 ) c o n e l d e s a r r o llo b a s a
c e s o e v o lu tiv o . S in e m b a r g o , e l p r o c e s o I S B C se d e b e d o e n c o m p o n e n t e s . L a ingeniería del dom inio r e a l i z a
c a r a c te r iz a r d e f o r m a q u e n o s ó lo id e n t if iq u e lo s c o m e l t r a b a jo q u e s e r e q u ie r e p a r a e s ta b le c e r e l c o n ju n t o d e
p o n e n te s c a n d i d a t o s s i n o q u e t a m b i é n c u a l i f i q u e l a i n t e r c o m p o n e n te s d e s o ftw a r e q u e e l in g e n ie r o d e l s o f t w a
fa z d e c a d a c o m p o n e n te , q u e a d a p te lo s c o m p o n e n te s r e p u e d e r e u tiliz a r . E s to s c o m p o n e n te s e n to n c e s se tr a n s
p a r a e x t r a e r la s f a l t a s d e c o i n c i d e n c i a s a r q u i t e c t ó n i c a s , f ie r e n a tr a v é s d e u n « lí m it e » q u e s e p a ra la in g e n ie r í a
q u e e n s a m b le lo s c o m p o n e n te s e n u n e s t ilo a r q u it e c t ó d e l d o m in io d e l d e s a r r o llo b a s a d o e n c o m p o n e n te s .
n ic o s e le c c io n a d o y q u e a c t u a lic e lo s c o m p o n e n t e s a
m e d id a q u e c a m b i a n l o s r e q u i s i t o s d e l s i s t e m a [ B R 0 9 6 ] ,
Referencia Web
La página de tecnología de componentes proporciono
Información útil sobre ISBC:
www.odateom.com/c o p /
L a F ig u r a 2 7 .1 ilu s t r a u n m o d e lo d e p r o c e s o t í p ic o q u e
a c o p la l a I S B C e x p l í c i t a m e n t e [ C H R 9 5 ] . L a i n g e n i e r í a d e l
d o m in io c re a u n m o d e lo d e d o m in io d e a p lic a c ió n q u e se
u t i l i z a c o m o b a s e p a r a a n a l i z a r los r e q u i s i t o s d e l u s u a r i o
e n e l f l u j o d e la in g e n ie r í a d e l s o ftw a r e . U n a a r q u it e c t u r a
d e s o f t w a r e g e n é r i c a (y l o s p u n t o s d e e s t r u c t u r a c o r r e s
p o n d ie n t e s , v é a s e la S e c c ió n 2 7 . 3 . 3 ) p r o p o r c io n a la e n t r a
d a p a r a e l d is e ñ o d e la a p lic a c ió n . F in a lm e n te , d e s p u é s d e
q u e s e h a n c o m p r a d o lo s c o m p o n e n t e s r e u t i l i z a b l e s , s e h a n
s e l e c c i o n a d o a p a r t i r d e la s b i b l i o t e c a s e x i s t e n t e s o s e h a n
www.FreeLibros.org
c o n s t r u id o ( c o m o p a r t e d e la in g e n ie r í a d e l d o m in io ) , lo s
in g e n ie r o s d e l s o f tw a r e d is p o n d r á n d e e llo s d u r a n t e la a c t i
FIGURA 27.1. Un m o d elo de p roceso de sop orte a la ISBC. v id a d d e d e s a r r o llo b a s a d a e n c o m p o n e n te s .
475
in g e n ie ría d e l s o ftw a re . un enfoque p ra c tic o
El objetivo de la ingeniería del dominio es identificar, 1 . Seleccionar funciones y objetos específicos.

construir, catalogar y diseminar un conjunto de com po 2. Abstraer funciones y objetos.
nentes de software que tienen aplicación en el software 3 . Definir una taxonomía.
actual y futuro dentro de un dominio de aplicación en
4. Identificar las características comunes.
particular. El objetivo general consiste en establecermeca-
nism os que capaciten a los ingenieros del software para 5. Identificar las relaciones específicas.
com partir estos componentes — para reutilizarlos— a lo 6 . Abstraer las relaciones.
largo de su trabajo en sistemas nuevos o actuales. 7. Derivar un m odelo funcional.
8 . Definir un lenguaje del dominio.
¿Cómo se pueden identificar

inios está a punto de encontrar
’0 $ ¡ ' fst dsfetnos paro identificar
; ■ ■Lii : • se pueden aplicar a muchos
.’» ? '■%tpam identificar las familias
• . y clasificarlos componentes
reutilizables?
, :: , : •' r que estón ubicadas de forma El lenguaje del dominio hace posible la especifica
¡¡¡8# asquea provecho de esos componentes. ción y construcción posterior de aplicaciones dentro del
há&tbmmH dominio.
Aun cuando los pasos indicados anteriormente pro
La ingeniería del dominio incluye tres actividades porcionan un modelo Útil para el análisis del dominio, no
principales: análisis, construcción y diseminación. En proporcionan ninguna guía para decidir cuáles son los com
el Capítulo 2 1 se presentó una revisión general del aná ponentes de software que son candidatos para la reutiliza
lisis del dom inio. Sin embargo, este tem a se vuelve a ción. Hutchinson y Hindley [HUT88] sugieren el siguiente
tratar en las secciones siguientes. La construcción y la conjunto de cuestiones pragmáticas como guía para iden
disem inación del dominio se describirán m ás adelante tificar los componentes del software reutilizables:
en otras secciones dentro de este m ismo capítulo. ■ ¿Es la funcionalidad del com ponente un requisito
Se podría argumentar que «la reutilización desapa para futuras im plementaciones ?
recerá, no m ediante la elim inación, sino m ediante la
• ¿Hasta qué punto es corriente la función del com
integración» en el entram ado de prácticas de la inge
ponente dentro del dominio?
niería del software [TRA95], Como la reutilización cada
vez recibe más importancia, todavía hay quien cree que • ¿Existe una duplicación de la función del compo
en la próxim a década la ingeniería del dominio tendrá nente dentro del dominio?
tanta im portancia como la ingeniería del software. • ¿Depende ese componente del hardware?
• ¿Permanece intacto el hardware entre implementa
27.3.1. El p ro ce so d e a n á lis is d el d o m in io ciones?
En el Capítulo 21 se describía el enfoque general del ¿Cuáles son
análisis del dominio en el contexto de la ingeniería del ♦ los componentes
software orientado a objetos. Las pasos del proceso se identificados durante el análisis
definían de la siguiente manera: del dominio que serán candidatos
1. Definir el dominio que hay que investigar. de la reutilización?
2. Categorizar los elementos extraídos del dominio.
• ¿Es posible trasladar las partes específicas del hard
3. R ecoger una m uestra representativa de las aplica
ware a otro componente?
ciones del dominio.
• ¿Está el diseño suficientemente optimizado para la
4. Analizar cada aplicación de la muestra.
siguiente implementación?
5. Desarrollar un m odelo de análisis para los objetos.
• ¿Es posible param etrizar un componente no reutili-
Es im portante tener en cuenta que el análisis del zable para que pase a ser reutilizable?
dominio se puede aplicar a cualquier paradigm a de la
• ¿Es reutilizable ese componente en m uchas imple-
ingeniería del software, siendo posible aplicarlo tanto
m entaciones con cambios solo m enores?
para el desarrollo convencional com o para el desarro
• ¿Es viable la reutilización mediante modificaciones?
llo orientado a objetos.
Prieto-Diaz[PRI87] am p liad segundo paso del aná • ¿Se puede descomponer un componente no reutili
www.FreeLibros.org
lisis del dominio indicado anteriormente y sugiere un zable para producir componentes reutilizables?
enfoque de ocho pasos para la identificación y clasifi • ¿Hasta qué punto es válida la descomposición del
cación de componentes reutilizables: componente para su reutilización?
476
CAPÍTULO 27 I N GE NIE RI A DEL SOF TW ARE B A S A D A EN C O M P O N E N T E S
U na d escripción en p ro fu n d id ad de los m étodos de 4. claram ente relevante, y si el softw are nuevo no posee
análisis del dom inio va m ás allá del alcance de este libro. esta c arac terístic a, la reu tiliz a c ió n será in eficien te
Para m ás info rm ació n acerca del análisis del dom inio, pero quizás siga siendo posible
véase [PRI93]. 5. es claram en te relevante, y si el so ftw are nuevo no
posee esta característica, la reutilización será inefi
27.3.2. F u n cion es de caracterización ciente y la reutilización sin esta característica no es
Aveces resulta difícil determ inar si un com ponente poten recom endable.
cialmente reutilizable es realm ente aplicable en una situa C uando se va a construir un softw are nu ev o , w , den
ción determ inada. Para llevar a cabo esta determ inación, tro del d o m in io de la ap licación, se d e riv a p a ra él un
es n ecesario d efinir un conjunto de características del conjunto de característicasdel dom inio. A continuación,
dominio que sean co m p artid asp o r todo el softw are en el se efectúa una com paración entre D p¡ y D w¡, para d eter
seno del dom inio. U na característica del dom inio define m inar si el com ponentep se puede reutilizar eficazm ente
algún atributo genérico de todos los productos que ex is en la aplicación w .
ten dentro del dom inio. P or ejem plo, entre las caracte
rísticas genéricas se podría incluir: la im portancia de la
seguridad y fiabilidad, el lenguaje de p rogram ación, la
concurrencia de p ro c e s a m ie n to ^ m uchas más. Referencia W ebl
Un conjunto de características de dom inio de un co m Para encontrar referenciasvaliosas sobre
ponente reutilizable se puede rep resen tar com o {D¡} \ en una tecnología de objetos de dlreccionamlento
donde cada elem ento D p¡ del conjunto representa una de informes, arquitecturas y análisis de dominios,
característica específica de dom inio. El v alor asignado se puede visitar lo dirección de Internet:
a D ■representa una escala ordinal com o una indicación www.sei.cmu.edu/mbse/ wisr_report.html
de la relevancia de esa característicapara el com ponente
p. Una escala típ ica [B A S94] p o d ría ser: L a Tabla 27.1 [BA S94] enum era las características
1. no es relevante para que la reutilización sea o no ade típicas del dom inio que pueden ten er im pacto en la reu
cuada. tilización del softw are. E stas características del d o m i
2. relevante sólo en circunstancias p oco com unes. nio deben de tenerse en cuenta con o b jeto de reutilizar
un com ponente de form a eficiente.
3. relevante: el co m p o n en te se p u ed e m o d ific ar para
A un cuando el softw are que se vaya a construir ex is
poder u tilizarlo, a p esar de las diferencias.
ta claram ente en el seno de un dom inio de aplicación,
los co m p o n en tes re u tiliz ab le s situados d e n tro de ese
P ro d u c to P ro c e s o P e rs o n a l dom inio deberán ser analizados con objeto de d eterm i
nar su aplicabilidad. E n algunos casos (esperem os que
Estabilidad M odelo M otivación
sea un núm ero lim itado), la «reinvención de la rueda»
de requisitos de proceso
puede seguir siendo la opción m ás rentable.
Software A juste Educación
concurrente del proceso
Restricciones Entorno Experiencia/ 27.3.3. Modelado estructural y puntos d e estructura
de memoria del proyecto form ación C uando se aplica el análisis del dom inio, el analista bu s
Tamaño R estricciones • dom inio ca tram as repetidas en las aplicaciones que residen d e n
de aplicaciones de planificación de aplicación tro del dom inio. El m odelado estructural es un enfoque
Complejidad R estricciones • proceso de ingeniería basado en tram as que opera efectuando la
de interfaz de presupuesto suposición consistente en que todo dom inio de aplicación
de usuario posee tram as repetidas (de función, de datos y de co m
portam iento) que tienen un potencial de reutilización.
Lenguaje(s) Productividad • plataform a
P ollak y R issm an [PO L94] d escrib en los m o delos
de programación
estructurales de la siguiente m anera:
Seguridad • lenguaje
Los modelos estructurales constan de un pequeño número
y fiabilidad
de elementos estructurales que manifiestan unas tramas de
Requisitos Productividad interacción claras. Las arquitecturas de sistemas que utilizan
de la duración global del equipo modelos estructurales se caracterizan por múltiples ensambla
de desarrollo jes formados por estos elementos del modelo. De esta mane
ra, las interacciones complejas entre sistemas que tienen muchas
Calidad del producto unidades arquitectónicas, surgen de tramas sencillas de inte
Fiabilidad racción que existen en el conjunto pequeño de elementos.
www.FreeLibros.org
del producto Todo d o m in io de ap licació n se puede c arac teriza r
TABLA 27.1. Características del dominio que afectan por un m odelo estructural (por ejem plo, la aviónica d ifie
al software [BAS94]. re m ucho en los aspectos específicos, pero todo el so ft
477
I N G E N I E R Í A DEL S OFT W ARE . UN EN FOQUE P R Á C T I C O
w a r e m o d e r n o d e e s te d o m in io tie n e e l m is m o m o d e lo • un mecanismode establecimientode límites q u e p e r

e s tr u c tu r a l) . P o r ta n to , e l m o d e lo e s tr u c tu r a l e s u n e s t i m it e a l u s u a r io e s ta b le c e r lí m it e s s o b r e lo s p a r á m e
lo a r q u it e c t ó n ic o ( C a p í t u lo 1 4 ) q u e p u e d e y d e b e r e u t i- tr o s q u e h a y q u e m e d ir ;
liz a r s e e n a p lic a c io n e s p e r te n e c ie n te s a l d o m in io . • un mecanismodegestión d e s e n s o r e s q u e s e c o m u n ic a
M c M a h o n [ M C M 9 5 ] d e s c r ib e u n punto de estruc c o n to d o s lo s s e n s o re s e m p le a d o s e n la m o n it o r iz a c ió n ;
tura c o m o u n a « e s tr u c tu r a b ie n d ife r e n c ia d a d e n tr o d e
• un mecanismo de respuesta q u e r e a c c io n a fr e n te a
u n m o d e lo e s tr u c tu r a l» . L o s p u n to s d e e s tr u c tu r a tie n e n
la s e n tr a d a s p r o p o r c io n a d a s p o r e l s is t e m a d e g e s
tr e s c a r a c t e r í s t ic a s b ie n c la r a s :
tió n d e s e n s o re s ;
1. U n p u n t o d e e s tr u c tu r a e s u n a a b s tr a c c ió n q u e d e b e • un mecanismo de control q u e c a p a c it a a l u s u a r io
d e t e n e r u n n ú m e r o l i m i t a d o d e in s t a n c i a s . A l r e p l a n p a r a c o n t r o la r la f o r m a e n q u e s e e f e c t ú a la m o n i-
te a r e s ta c a r a c te r ís tic a e n la je r g a o r ie n t a d a a o b je to r iz a c ió n .
t o s ( C a p í t u l o 2 0 ) , e l t a m a ñ o d e l a j e r a r q u í a d e c la s e s
d e b e s e r p e q u e ñ o . A d e m á s , la a b s tr a c c ió n d e b e r e p e
t ir s e a lo la r g o d e la s a p lic a c io n e s d e l d o m in io . E n
c a s o c o n tr a r io , e l e s fu e r z o r e q u e r id o p a r a v e r if ic a r , C LA VE
d o c u m e n ta r y d is e m in a r e s e p u n to d e e s tr u c tu r a n o Un punto de estructura se puede ver como un patrón
p u e d e ju s t if ic a r s e e n té r m in o s d e c o s te . de diseño que aparece repetidas veces en aplicaciones
dentro de un dominio específico.
¿Qué es un «punto
de estructura)) y cuáles C a d a u n o d e e s to s p u n to s d e e s tr u c t u r a e s tá in t e g r a
son sus características? d o e n u n a a r q u it e c t u r a d e d o m in io .
E s p o s ib le d e f in ir lo s p u n to s d e e s t r u c t u r a g e n é r ic o s
2 . L a r e g la s q u e r ig e n la u t i l i z a c i ó n d e l p u n t o d e e s t r u c q u e t r a s c ie n d e n a u n n ú m e r o d e d o m in io s d e a p lic a c io
tu r a d e b e n e n te n d e r s e fá c ilm e n t e . A d e m á s , la in t e r n e s d ife r e n te s [S T A 9 4 ]:
fa z c o n e l p u n to d e e s tr u c tu r a d e b e s e r r e la tiv a m e n te A plicaciones cliente. La IG U , que incluye todos los mentís,
s e n c illa . paneles y capacidades de entrada y edición de órdenes.
3 . E l p u n to d e e s tr u c tu r a d e b e im p le m e n t a r e l o c u lta - B ases de datos. E l depósito de todos los objetos relevantes
m ie n t o d e in f o r m a c ió n a is la n d o to d a la c o m p le jid a d para el dominio de la aplicación
d e n tr o d e l p u n t o d e e s tr u c tu r a e n s í. E s to r e d u c e la M otores de cálculo. Los modelos numéricos y no numéri
c o m p le jid a d p e r c ib id a d e l s is t e m a e n s u c o n ju n t o . cos que manipulan datos.
C o m o e je m p lo d e p u n to s d e e s tr u c tu r a c o m o tr a m a s F unción de reproducción de informes. La función que pro
a r q u it e c t ó n ic a s p a r a u n s is t e m a , c o n s id é r e s e e l d o m i duce salidas de todo tipo.
n i o d e l s o f t w a r e d e s is t e m a s d e a la r m a . E l d o m i n io d e l E ditor de aplicaciones. Mecanismo adecuado para perso
s is t e m a p u e d e a b a r c a r s is t e m a s t a n s im p le s c o m o nalizar la aplicación ajustándola a las necesidades de usuarios
HogarSeguro ( d e s c r ito s e n c a p ít u lo s a n te r io r e s ) o ta n específicos.
c o m p le jo s c o m o e l s is t e m a d e a la r m a d e u n p r o c e s o L o s p u n to s d e e s tr u c tu r a s e h a n s u g e r id o c o m o a lte r
in d u s t r ia l. S in e m b a r g o , s e e n c u e n t r a n u n c o n ju n t o d e n a t i v a a la s l í n e a s d e c ó d i g o y a l o s p u n t o s d e f u n c i ó n
tr a m a s e s tr u c tu r a le s p r e d e c ib le s : p a r a la e s t im a c ió n d e l c o s te d e l s o f t w a r e ( [ M C M 9 5 ] ,
« una interfaz q u e c a p a c it a a l u s u a r io p a r a in t e r a c t u a r E n la S e c c ió n 2 7 .6 . 2 s e p r e s e n ta u n a d e s c r ip c ió n b r e v e
c o n e l s is t e m a ; d e l c o s te u t iliz a n d o p u n to s d e e s tr u c tu r a .
17A PESABBQLLQ BASA£>.Q.£ÍLC..QMP.QMENTES

E l d e s a r r o llo b a s a d o e n c o m p o n e n te s e s u n a a c tiv id a d U n a v e z q u e s e h a e s ta b le c id o la a r q u it e c t u r a , s e d e b e
d e la I S B C q u e tie n e lu g a r e n p a r a le lo a la in g e n ie r í a p o p u la r iz a r m e d ia n t e lo s c o m p o n e n t e s q u e ( 1 ) e s tá n d is
d e l d o m in io . L a u t iliz a c ió n d e m é to d o s d e d is e ñ o a r q u i p o n ib le s e n b ib lio te c a s d e r e u t iliz a c ió n , y / o ( 2 ) se h a n
t e c t ó n ic o y d e a n á lis is s e h a d e s c r ito a n te r io r m e n te e n d i s e ñ a d o p a r a s a t i s f a c e r la s n e c e s i d a d e s d e l c l i e n t e . D e
o t r a s e c c ió n d e e s te t e x t o , e n d o n d e e l e q u ip o d e l s o f t a q u í q u e e l f lu jo d e u n a ta r e a d e d e s a r r o llo b a s a d a e n
w a r e r e f in a e l e s t ilo a r q u it e c t ó n ic o a d e c u a d o p a r a e l c o m p o n e n t e s t e n g a d o s c a m i n o s p o s i b l e s ( F i g . 2 7 .1 ) .
m o d e lo d e a n á lis is d e la a p lic a c ió n q u e s e v a a c o n s C u a n d o lo s c o m p o n e n te s r e u t iliz a b le s e s tá n d is p o n ib le s
t r u i r 2. p a r a u n a in t e g r a c ió n f u t u r a e n la a r q u it e c t u r a , d e b e n
www.FreeLibros.org
2Se debería destacar que el estilo arquitectónico suele estar influen
ciado por el modelo de estructura genérico creado en la ingeniería
del dominio (véase Figura 27.1)
478
CAPÍTULO 27 INGE NIE RÍ A DEL SO FT W AR E B A SA D A EN C O M P O N E N T E S
estar cualificados y adaptados. Cuando se requieren co m C a d a u n o d e lo s f a c t o r e s a n te r io r e s es r e la t iv a m e n

p o nentes n u ev o s, d eb en diseñarse. L os com p o n en tes te f á c il d e v a lo r a r c u a n d o s e p r o p o n e n lo s c o m p o n e n
resultantes entonces se «com ponen» (se integran) en una te s r e u t iliz a b le s q u e s e h a n d e s a r r o lla d o d e n t r o d e la
plantilla de arq uitectura y se co m prueban a conciencia. m is m a a p lic a c ió n . S i s e h a n a p lic a d o p r á c tic a s d e in g e
n ie r í a d e l s o ftw a r e d e b u e n a c a lid a d d u r a n te e l d e s a
r r o l l o , s e p u e d e n d i s e ñ a r r e s p u e s t a s p a r a la s p r e g u n t a s
27.4.1. C u a lific a c ió n , a d a p ta c i ó n y c o m p o s ic ió n
r e la c io n a d a s c o n la lis t a a n te r io r . S in e m b a r g o , e s m u c h o
d e c o m p o n e n te s
m á s d i f í c il d e te r m in a r e l f u n c io n a m ie n t o in t e r n o d e c o m
Como se acaba de ver, la ingeniería del dom inio propor p o n e n te s C Y D o d e te r c e r a s p a r te s , p o r q u e la Ú n ic a
ciona la biblioteca de com ponentes reutilizables necesa in f o r m a c ió n d is p o n ib le e s p o s ib le q u e s e a la m is m a
rios para la ingeniería del software basada en componentes. in t e r f a z d e e s p e c if ic a c io n e s .
Algunos de estos com ponentes reutilizab les se d esarro
A d a p ta c ió n d e c o m p o n e n te s
llan dentro de ella m ism a, otros se pueden extraer de las
aplicaciones actuales y aun otros se p u ed en adquirir de L o id e a l s e r ía q u e la in g e n ie r í a d e l d o m in io c re a r a u n a
terceras partes. b ib lio t e c a d e c o m p o n e n te s q u e p u d ie r a n in te g r a r s e f á c i l
D esgraciadam ente,la existencia de com ponentes reu- m e n te e n u n a a r q u it e c t u r a d e a p lic a c io n e s . L a im p li c a
tilizables no g arantiza que estos com ponentes puedan c ió n d e u n a « in t e g r a c ió n f á c il» e s q u e : ( 1 ) s e h a y a n
integrarse fácilm ente, o de form a eficaz, en la arquitec im p le m e n t a d o lo s m é to d o s c o n s e c u e n te s d e la g e s tió n d e
tura elegida p ara una aplicación nueva. E sta es la razón r e c u r s o s p a r a to d o s lo s c o m p o n e n te s d e la b ib lio t e c a ; ( 2 )
por la que se aplica una sucesión de actividades de d esa q u e e x is t a n a c t iv id a d e s c o m u n e s , ta le s c o m o la g e s t ió n
rrollo b asada en com ponentes cu an d o se h a propuesto d e d a t o s p a r a t o d o s l o s c o m p o n e n t e s , y (3 ) q u e s e h a y a n
que se utilice un com ponente. im p le m e n t a d o in te r fa c e s d e n tr o d e la a r q u it e c t u r a y c o n
e l e n to r n o e x te r n o d e m a n e r a c o n s e c u e n te .
C ualificación d e c o m p o n e n te s
La cualificaciónde componentes asegura que un c o m
ponente candidato llev ará a cab o la función necesaria,
encajará adem ás « ad ecu ad am en te» en el estilo arq u i
tectónico esp ecificad o p a ra el sistem a y ex h ib irá las Us iBtepdof8s de componentes necesitan
características de calidad (por ejem plo, rendim iento, fia fc u b d r la fundón y la forma de los componentes
bilidad, u sabilidad) necesarias p ara la aplicación.
tfah Brown y Kart WaSnoa
La d escripción de la interfaz p ro p o rciona in form a
ción útil sobre la o peración y u tilizació n de los com po
nentes del so ftw are, p ero no p ro p o rc io n a to d a la E n r e a lid a d , in c lu s o d e s p u é s d e h a b e r c u a lif ic a d o
información necesaria p ara determ inar si un com ponente u n c o m p o n e n te p a r a s u u t iliz a c ió n d e n tr o d e u n a a r q u i
propuesto puede de hech o volver a reutilizarse de m ane te c tu r a d e a p lic a c ió n , e s p o s ib le e x h ib ir c o n f lic t o s e n
ra eficaz en u n a aplicación nueva. A c o n tin u ació n , se u n a o m á s d e la s á r e a s a n t e r io r e s . P a r a m i t i g a r e s to s
muestran algunos factores de los m uchos a tener en cuen c o n f lic t o s s e s u e le u t i l i z a r u n a t é c n ic a d e a d a p ta c ió n
ta durante la cualificación de los com ponentes [B R 096]: lla m a d a « e n c u b r im ie n to d e c o m p o n e n te s » [B R 0 9 6 ].
• la interfaz de program ació n de aplicaciones (A PI); C u a n d o u n e q u ip o d e s o ftw a r e tie n e t o t a l a c c e s o a l d is e
ñ o in t e r n o y a l c ó d ig o d e u n c o m p o n e n t e ( n o s u e le s e r
• las herram ientas de desarrollo e integración necesa
e l c a s o d e lo s c o m p o n e n te s C Y D ) s e a p lic a e l e n c u
rias p ara el com ponente;
b r im ie n t o d e c a ja b la n c a . A l ig u a l q u e s u h o m ó lo g o e n
• requisitos de ejecución, entre los que se incluyen la la s p r u e b a s d e l s o f t w a r e ( C a p í t u l o 1 7 ) , e lencubrimiento
utilización de recursos (por ejem plo, m em oria o alm a- de caja blanca e x a m in a lo s d e ta lle s d e l p r o c e s a m ie n
cen am ien to ),tiem p o o v elo cid ad y p rotocolo de red; t o in t e r n o d e l c o m p o n e n t e y r e a liz a la s m o d if ic a c io n e s
¿Cuáles son los factores

a n i v e l d e c ó d ig o p a r a e l im i n a r lo s c o n f lic t o s . E l encu
brimiento de caja gris
§ a tener en cuenta durante
la cualificación de componentes?
• requisitos de servicio, donde se incluyen las i n t e r f a

s e a p lic a c u a n d o la b ib lio t e c a
d e c o m p o n e n te s p r o p o r c io n a u n le n g u a je d e e x t e n s ió n
d e c o m p o n e n te s , o A P I , q u e h a c e p o s ib le e lim in a r o
e n m a s c a r a r lo s c o n f lic t o s . E l encubrimiento de caja
ces del sistem a operativo y el soporte p o r parte de negra r e q u ie r e la in t r o d u c c ió n d e u n p r e p r o c e s a m ie n -
otros com ponentes; t o o p o s t p r o c e s a m ie n t o e n la in t e r f a z d e c o m p o n e n te s
p a r a e lim in a r o e n m a s c a r a r c o n f lic t o s . E l e q u ip o d e
• funciones de seguridad, co m o controles de acceso y
s o ftw a r e d e b e d e te r m in a r s i se j u s t i f ic a e l e s fu e r z o
protocolo de autenticación;
r e q u e r id o p a r a e n v o lv e r a d e c u a d a m e n te u n c o m p o n e n te
www.FreeLibros.org
• supuestos de diseños em bebidos, incluyendo la u ti o s i p o r e l c o n t r a r io se d e b e r í a d is e ñ a r u n c o m p o n e n te
lización de algoritm os n um éricos y no num éricos; p e r s o n a liz a d o ( d is e ñ a d o p a r a e l im i n a r lo s c o n f lic t o s
• m anip u lació n de excepciones. q u e se e n c u e n tre n ).
479
INGE NIE RÍA DEL SOFTW ARE . UN EN F O Q U E P R A C T I C O
Com posición de com ponentes OMG/CORBA, El Grupo de gestión de objetos (Object

Management Group) ha publicado una arquitectura común de
L a ta re a d e composición de componentes ha en sam distribución de objetos{ OMG/CORBA). Los distribuidoresde
b la d o c o m p o n e n te s c u a lific a d o s , a d a p ta d o s y d is e ñ a objetos (ORB) proporcionan toda una gama de servicios que
d o s p a ra p o p u la r iz a r la a rq u ite c tu ra e s ta b le c id a para, hacen posible que los componentes reutilizables (objetos) se
u n a a p lic a c ió n . P a ra p o d e r lle v a r lo a c a b o , d e b e e s ta comuniquen con otros componentes, independientemente de
b le c e rs e u n a in fr a e s tru c tu ra d o n d e los c o m p o n e n te s su ubicación dentro del sistema. Cuando se construyen com
ponentes empleando el estándarOMG/CORBA, la integración
e s té n u n id o s a u n s is te m a o p e ra c io n a l. L a in fra e s tru c
de esos componentes(sin modificación) dentro del sistema que
tu ra (n o rm a lm e n te u n a b ib lio te c a d e c o m p o n e n te s e sp e da garantizada si se crea una interfaz mediante un lenguaje de
c ia liz a d o s ) p ro p o rc io n a u n m o d e lo p a ra la c o o rd in a c ió n definición de interfaces (LDI) para cada componente.
de c o m p o n e n te s y s e rv ic io s e s p e c ífic o s que h a ce n p o s i
b le c o o rd in a r u n o s c o m p o n e n te s c o n o tro s , y lle v a r a
c a b o las ta re as c o m u n es .
E n tre los m u c h o s m ec a n is m o s p a ra c re a r u n a in fra e s Referencia W ebl
tr u c tu ra e fic a z , e x is te u n c o n ju n to d e c u a tro « in g r e
La información más actualizada sobre CORBA se puede
d ie n te s a rq u ite c tó n ic o s » [ A D L 9 5 ] q u e se d e b e r ía
obtener en www.omg.org
p re s e n ta r p a ra lo g ra r la c o m p o s ic ió n d e c o m p o n e n te s:
Modelo de intercambio de datos. Se trata de mecanismos Utilizando una metáfora cliente/servidor, los objetos situa
que capacitan a los usuarios y a las aplicaciones para interac- dos dentro de la aplicación cliente solicitan uno o más ser
tuar y transferir datos (por ej emplo, arrastrar y soltar, cortar y vicios del servidor de ORB. Las solicitudes se hacen a través
pegar), y que deberían estar definidos para todos los compo del LDI, o bien dinámicamente en el momento de la ejecu
nentes reutilizables. Los mecanismos de intercambio de datos ción. Un repositorio de interfaces contiene toda la informa
no solamente permiten la transferencia de datos entre hombre ción necesaria acerca de las solicitudes de servicio y de los
y programa, y entre componentes, sino que también hacen posi formatos de respuesta. CORBA se estudia con más detalle
ble la transferencia entre los recursos del sistema (por ejem en el Capítulo 28.
plo, arrastrar un archivo al icono de una impresora para COM de Microsoft. Microsoft ha desarrollado un mode
imprimirlo). lo de objetos para componentes (COM) que proporciona una
Automatización. Para facilitar la interacción entre com especificación para utilizar los componentes elaborados por
ponentes reutilizables se deberían de implementar herramien diferentes fabricantes dentro de una aplicación única bajo el
tas, macros y guiones. sistema operativo Windows. COM abarca dos elementos: las
interfaces COM (irnplementadas como objetos COM) y un
¿Cuáles son los ingredientes conjunto de mecanismos para registrar y pasar mensajes entre
• necesarios para lograr

la composición de componentes?
interfaces COM. Desde el punto de vista de la aplicación, «el
foco no está en cómo [seimplementan los objetos COM], sino
en el hecho de que el objeto tiene una interfaz que se registra
con el sistema, y que utiliza el sistema de componentes para
Almacenamiento estructurado. Los datos heterogéneos comunicarse con otros objetos COM» [HAR98],
(por ejemplo, los datos gráficos, de voz, texto, vídeo y datos
numéricos) dentro de un «documentocompuesto»,deben estar
organizados para poder acceder a ellos como si de una sola
estructura de datos se tratase, en lugar de comportarse como si Referencia
fueran toda una colección de archivos por separado. «Los datos
estructurados mantienen un índice descriptivo de estructuras La información más actualizada sobre GCM se puede
de anidamiento, que las aplicaciones pueden recorrer libre obtener en www.microsoft.com/COM
mente para localizar,crear o editar el contenido de datos indi
viduales según lo indique el usuario final» [ADL95], Componentes JavaBean de SUN. El sistema de compo
Modelo de objetos subyacente.El modelo de objetos ase nentes JavaBean es una infraestructura ISBC portátil e inde
gura que los componentes desarrollados en distintos lenguajes pendiente de la plataforma que utiliza el lenguaje de
de programación que residan en distintas plataformas pueden programación Java. El sistema JavaBean amplía el applet4 de
ser interoperables. Esto es, los objetos deben ser capaces de Java para acoplar los componentes de software más sofistica
comunicarse en una red. Para lograr esto, el modelo de obje dos necesarios para el desarrollo basado en componentes.
tos define un estándar para la interoperabilidad de los compo
nentes.
D a d o que e l im p a c to fu tu ro d e la re u tiliz a c ió n y de
la IS B C e n la in d u s tria d e l s o ftw a re es e n o rm e , u n a g ra n Referencia W ebl
c a n tid a d d e em p res as im p o rta n te s y c o n so rcio s in d u s Para obtener recursos excelentes de estimación
tria le s 3 h a n p ro p u e s to e stándares p a ra e l s o ftw a re p o r visite la Red de Gestores de Proyectos en
c o m p o n e n te s: ¡ava.sun.com/beans
www.FreeLibros.org
3 En [O R F 9 6 ] y [Y O U 9 8 ] se presenta un estudio excelente sobre los 4 En este contexto, un applet se puede considerar un componente
estándares de « o b je to s d is t r ib u id o s » . simple.
480
CAPÍTULO 27 INGE NIE RIA DEL S O F T W A R E BA SA D A EN C O M P O N E N T E S
El sistema de componentes JavaBean acompaña un con « c o rre s p o n d e n c ia d e e s p e c ific a c io n e s » .B e llin z o n i y sus

junto de herramientas llamadas Kit de DesarrolloBean (BDK), c o la b o ra d o re s [ B E L 9 5 ] d e s c rib e n u n e n fo q u e p a ra lo s
que permite a los desarrolladores: ( 1) analizar el funcionamiento sistem as o rie n ta d o s a o b je to s :
de los Beans (componentes); (2) personalizar su comporta
miento y aspecto; (3) establecer mecanismos de coordinación L os com ponentes se definen y se alm acenan com o clases
y comunicación; (4) desarrollar Beans personalizados para su de especificación,diseñoe implementación con diferentesnive
utilización en una aplicación específica;y (5) probar y evaluar les de abstracción (cada clase es una descripción ya realizada
el comportamiento de un Bean. de un producto procedente de aplicacionesanteriores). El cono
cim iento de especificación - c o n o c im ie n to de desarrollo—
¿Cuál de estos e stándares d o m in a rá la in d u s tria ? P o r se alm acena en la form a de clases que sugieren la reutilización,
el m o m e n to , n o h a y u n a respu esta fá c il. A u n q u e m u c h o s y que contienen indicaciones para recuperar com ponentes reu-
d e s a rro lla d o re s h a n e s ta b le c id o n o rm a s e n base a u n o tilizables basándose en su descripción y tam bién para com po
de estos e stá n d a re s, es p ro b a b le q u e g ra n d e s e m p resas nerlos y ajustarlos una vez recuperados.
de s o ftw a re te n g a n la p o s ib ilid a d d e e le g ir e n tre tres
estándares, d e p e n d ie n d o d e las c a te g o ría s y p la ta fo rm a s
de a p lic a c ió n que h a y a n s e le c c io n a d o .
Aunque la empresa no haga ingenierío de dominios,
hay que ir realizándola a medida que avanza el trabajo.
27.4.2. I n g e n i e r í a d e c o m p o n e n t e s
Cuando construyo el modelo de anéllslspregúntese:
C o m o se h a s eñ a lad o a n te rio rm e n te e n este c a p ítu lo , e l
proceso d e I S B C fo m e n ta la u tiliz a c ió n d e lo s c o m p o en otros aplicaciones de este tipo ? » Sí la respuesto
nentes de s o ftw a re e xisten tes . S in e m b a rg o , h a y o c a es afirmativo, puede que el componente ya existo.
sion es e n q u e se d e b e n d is e ñ a r lo s c o m p o n e n te s . E s
decir, los c o m p o n e n te s d e s o ftw a re n u e v o s d e b e n d e sa L a s h e r r a m ie n ta s a u to m a tiz a d a s se u t iliz a n p a r a
rro llarse e in teg rarse c o n los c o m p o n e n te s C Y D y a e x is e x p lo r a r e l re p o s ito rio e n u n in te n to d e h a c e r c o in c i
tentes y l o s d e d e s a r r o llo p ro p io . D a d o q u e esto s d ir e l re q u is ito in d ic a d o e n la e s p e c ific a c ió n a c tu a l c o n
c o m p o n e n te s n u e v o s v a n a fo r m a r p a rte de la b ib lio te lo s d e s c rito s p a ra u n o s c o m p o n e n te s r e u tiliz a b le s y a
ca de d e s a rro llo p ro p io d e c o m p o n e n te s re u tiliz a b le s , e x is te n te s (c la s e s ). L a s fu n c io n e s d e c a ra c te riz a c ió n
de b ería n d ise ñ a rse p a ra su re u tiliz a c ió n . (S e c c ió n 2 7 .3 .2 ) y la s p a la b ra s re s e rv a d a s se e m p le a n
N o h a y n a d a d e m á g ic o e n la c re a c ió n d e c o m p o c o m o a y u d a p a ra h a lla r c o m p o n e n te s p o te n c ia lm e n te
nentes de s o ftw a re que se p u e d e n re u tiliz a r. C o n c e p to s re u tiliz a b le s .
de diseñ o ta les c o m o a b s tra c c ió n , o c u lta m ie n to , in d e S i la c o rre s p o n d e n c ia d e e s p e c ific a c io n e s p ro d u c e
pendencia fu n c io n a l, re fin a m ie n to y p ro g ra m a c ió n estruc c o m p o n e n te s q u e se a ju s ta n a la s n e c e s id a d e s d e la
turada, ju n t o c o n lo s m é to d o s o rie n ta d o s a o b je to s , a p lic a c ió n e n c u e s tió n , e l d is e ñ a d o r p u e d e e x t r a e r
pruebas, S Q A y m é to d o s de v e rific a c ió n d e c o rre c c ió n , e sto s c o m p o n e n te s d e u n a b ib lio te c a de r e u tiliz a c ió n
todos e llo s c o n trib u y e n a la c re a c ió n d e c o m p o n e n te s de (r e p o s ito r io ) y u t iliz a r lo s p a ra d is e ñ a r e l n u e v o s is te
s oftw are que son re u tiliz a b le s '. E n e sta s e c c ió n n o se m a . S i n o es p o s ib le h a lla r c o m p o n e n te s d e d is e ñ o , e l
revisarán estos te m a s , sin o q u e , p o r e l c o n tra rio , se te n in g e n ie ro d e l s o ftw a re e n to n c e s d e b e a p lic a r m é to d o s
drán en c o n s id e ra c ió n lo s te m a s e s p e c ífic o s d e la reuti d e d is e ñ o c o n v e n c io n a le s u 0 0 p a ra c re a rlo s . E s e n
lización p a ra p rá ctica s sólidas de in g e n ie ría d e l so ftw a re. este m o m e n to - c u a n d o e l d is e ñ a d o r c o m ie n z a a c re a r
u n n u e v o c o m p o n e n te — e n e l q u e d e b e d e c o n s id e
ra rs e el diseñopara la reutilización (D P R ).
27.4.3. A n á l is is y d i s e ñ o p a r a l a r e u t i l i z a c i ó n
L o s c o m p o n e n te s d e d is e ñ o y a n á lis is se h a n tra ta d o
d e ta lla d a m e n te e n las P arte s T e rc e ra y C u a r ta d e este
libro. L o s m o d e lo s de d a to s , fu n c io n a l y d e c o m p o rta Aunque existen asuntos especiales a tener en cuenta
m ien to (re p re s e n ta d o s m e d ia n te u n a g a m a d e n o ta c io cuando el objetivo es la reutlllzaclón, hay que centrarse
nes d is tin ta s ) se p u e d e n c re a r c o n o b je to de d e s c rib ir lo en las principios básicos de un buen diseño. Si se siguen

estos principias, las probabilidadesde reutilización
que debe r e a liz a r u n a d e te rm in a d a a p lic a c ió n . A c o n ti
n u a ció n , se u tiliz a n u nas e s p e c ific a c io n e s p o r e s c rito
para d e s c rib ir estos m o d e lo s , y o b te n e r c o m o re s u lta d o
fin a l u n a d e s c rip c ió n c o m p le ta d e lo s re q u is ito s . T a l c o m o se h a in d ic a d o a n te r io r m e n te , e l D P R
L o id e a l s e ría a n a liz a r e l m o d e lo d e a n á lis is p a ra re q u ie re que e l in g e n ie ro d e l s o ftw a re a p liq u e unos s ó li
d e te rm in a r a q u e llo s e le m e n to s d e l m o d e lo que in d ic a n dos c o n ce p to s y p rin c ip io s d e d is e ñ o d e l s o ftw a re (C a p í
unos c o m p o n e n te s re u tiliz a b le s y a e xisten tes . E l p r o tu lo 1 3 ). P e r o la s c a ra c te rís tic a s d e l d o m in io d e la
blem a consiste en e x tra e r in fo rm a c ió n a p a rtir d e l m o d e a p lic a c ió n ta m b ié n tie n e n q u e te n e rse e n cu en ta. B in
lo de re q u is ito s , d e f o r m a q u e p u e d a lle v a r a u n a d e r [B 1 N 9 3 ] su g iere u n c ie rto n ú m e ro d e asuntos6 fu n
www.FreeLibros.org
5Para aprender más sobre estos temas, véase desde el Capítulo 13 6 En general las preparaciones indicadas para el diseño destinado a
hasta el 16, y desde el 20 al 22. la reutilización deberían de llevarse a cabo com o parte de la inge
niería del dom inio (Sección 27.3).
INGENIERÍA DEL SO FT W A RE. UN E N F O Q U E PRÁCTICO
dam entales que deb en considerarse com o base del d ise U na vez que se han estab lecid o los datos estándar,
ño para la reutilización: las interfaces y las plantillas de program a, el diseñador
D a to s estándar. Es preciso investigarel dom inio de la apli posee un m arco de referencia en el cual puede crear el
cación, y es preciso iden tificarlas estructuras de datos están diseño. L os com ponentes nuevos que se ajustan a este
dar globales (por ejem plo, las estructuras de archivos o toda m arco de referencia tendrán una m ay o r probabilidad de
una base de datos com pleta). E ntonces se pueden caracterizar ser posteriorm ente reutilizables.
todos los com ponentes de diseño para uso de estas estructuras
A l igual que el d iseño, la co n stru cc ió n de c o m p o
de datos estándar.
nentes reutilizables se basa en m étodos de la ingeniería
P rotocolos de interfaz estándar. D eberían establecerse tres
del softw are que y a se han descrito en otras partes de
niveles de protocolo de interfaz: la naturaleza de las interfaces
intram odulares, el diseño de interfaces técnicas externas (no
este libro. La construcción se puede efectuar em plean
hum anas) y la interfaz hom bre-m áquina. do lenguajes convencionales de program ación, de te r
P lantillas de program a. E l m odelo de estructura (Sección
ce ra g e n e ra c ió n , le n g u a je s de c u a rta g en e ra ció n y
27.3.3) puede servir com o plantilla para el diseño arquitectó generadores de código, técnicas de program ación visual
nico de un nuevo program a. o herram ientas m ás avanzadas.
C o nsid ere u n a g ran b ib lio te c a u n iv ersitaria. P ara su El co n cep to de un c o m p o n e n te de softw are es una
u tiliz a c ió n tie n e d isp o n ib le s d e c e n a s de m illa res de «descripción de lo que hace el com ponente» [W HI95].
lib ro s , p e rió d ic o s y o tra s f u e n te s de in fo rm a c ió n . L a in te rfaz con el c o m p o n e n te se describ e c o m p le ta
A h o ra b ie n , p a ra a cced er a e sto s recu rso s es p re c iso m en te y su sem án tica — representada d en tro del co n
d esa rro lla r alg ú n sistem a de clasificació n . P ara re c o texto de pre y postcondiciones — se identifica tam bién.
rre r e ste gran v o lu m e n de in fo rm a c ió n , los b ib lio te El c o n c e p to d eb e c o m u n ic a r la in ten ció n del com po
cario s h an d e fin id o u n e sq u e m a d e c la sific a ció n que nente.
in clu y e un c ó d ig o d e c la s ific a c ió n de la b ib lio te c a ,
p alab ras re serv ad as, n o m b res de au to r y o tras e n tr a
das de índice. T odas e lla s c a p a c ita n al u s u a rio para
en co n tra r el re c u rso n e c e sa rio de fo rm a rá p id a y sen C LA VE
cilla. Poro describir un componente reutilizable, se tendrá
que describir su concepto, contenido y contexto.
.f ia :
i mejor después de conocer oigo, El contenido de un com ponente describe la form a en
sáer dónde se encuentra. que se construye el concepto. E n esencia, el contenido
S». *1Minos es una inform ación que queda oculta a los ojos del usua
rio h a b itu a l y que so lam ente n ec esita co n o ce r quien
intentará m odificar ese com ponente.
C onsidere ahora un gran depósito de com ponentes.
El contexto sitúa el com ponente de softw are reutili
R esiden en él decenas de m illares de com ponentes de
zable en el seno de su dom inio de aplicabilidad, esto es,
softw are reutilizables. ¿C óm o puede h allar el in g enie
m ed ian te la e sp ec ificac ió n de c a ra cterística s co ncep
ro del softw are el com ponente que necesita? P ara re s
tuales, operacionales y de im plem entación, el contexto
ponder a esta p regunta, surge otra preg u n ta m ás. ¿Cóm o
capacita al ingeniero del softw are para h allar el com
se describen los com ponentes de softw are en térm inos
p o n en te adecuado para sa tisfa ce r los req u isito s de la
de no am biguos y fácilm ente clasificables? Se trata de
aplicación.
cuestiones difíciles y tod av ía no se ha desarrollado una
respuesta definitiva. E n esta sección, se exploran las ten
dencias actuales que capacitarán a los futuros in g enie
ros del so ftw a re p a ra n a v e g a r p o r las b ib lio tecas
Referencia Wfejfei
reutilizables.
Uno detallado guía de reutlllzaclón de componentes
se puede descargar de la dirección
27.5 .1. D e s c r ip c ió n d e c o m p o n e n t e s r e u t i l i z a b l e s webl .ssg.gunter.af.mil/
U n com ponente de softw are reutilizable se puede d es sep/SEPver40/Main.html#GD
www.FreeLibros.org
cribir de m uchas m aneras, pero la descripción ideal abar
ca lo que T racz [T R A 90] ha lla m a d o el M o d e lo 3 C P ara que resulte útil en un sentido práctico, el con
- c o n c e p t o , contenido y c o n t e x t o - . cepto, el contenido y el contexto tienen que traducirse
482
CAPÍTULO 27 IN G EN IER IA DEL S O F T W A R E B A S A D A EN C O M P O N E N T E S
en un e sq u e m a de e s p e c ific a c ió n c o n c re to . Se h a n e s c ri
to v a ria s d o c en as d e a rtíc u lo s y tra b a jo s ace rca d e los
esquem as d e c la s ific a c ió n p a ra c o m p o n e n te s d e s o ft
ware reutilizables (por ejem plo, [W H I95] contiene una
extensa b ib lio g r a fía ). L os m é to d o s p ro p u es to s se p u e
den d e s c o m p o n e r e n tres zo n a s fu n d a m e n ta le s : m é to
dos de las c ie n c ia s d e la d o c u m e n ta c ió n y d e Términos Términos 1
■ Palabra |
b ib lio te c o n o m ía , m é to d o s de in te lig e n c ia a rtific ia l y sis Clasificado 1 reservada 9 extraídos no extraídcsl
tem as d e h ip e rte x to . L a g ra n m a y o r ía d e lo s tra b a jo s del texto del texto I
re a liz a d o s h asta e l m o m e n to s u g ie re la u tiliz a c ió n de
m étodos p ro p io s de b ib lio te c o n o m ía p a ra la c la s ific a Descriptores | Con sintaxis
yEnumeraciónjl
ción de c o m p o n e n te s .
Encabezados i Sin sintaxis (
L a F ig u ra 27.2 p re s e n ta u n a ta x o n o m ía d e lo s m é to HFaceta
del tema |
vocabula
dos de in d e x a c ió n e n b ib lio te c o n o m ía . L o s
rios controlados de indexación lim itan los térm inos y Diccionario
P
sintaxis que se p u e d e n u t iliz a r p a ra c la s ific a r lo s o b je
tos (c o m p o n en tes ). L o s vocabularios de indexación no F IG U R A 27.2'. Una taxonom ía de métodos de indexación
controlados n o im p o n e n re s tric c io n e s sobre la n a tu ra le [FRA94],
za de la d e s c rip c ió n . L a g ra n m a y o ría d e los e sq u em as
de c la s ific a c ió n p a ra lo s c o m p o n e n te s d e s o ftw a re se Clasificación por facetas. Se analiza una cierta área del
dom inio y se identifica un conjunto de características descrip
encuentran d e n tro de las tres c a te g o ría s s ig u ie n te s :
tivas básicas. E stas características, que se denom inan facetas,
Clasificación enumerada. Los componentes se describen reciben entonces diferentesprioridades según su im portanciay
mediante la definición de una estructurajerárquica en la cual se relacionan con un com ponente. L a faceta puede describir la
se definen clases y diferentes niveles de subclases de compo función que lleva a cabo el com ponente, los datos que se m ani
nentes de software. Los componentes en sí se enumeran en el pulan, el contexto en que se aplican o cualquier otra caracterís
nivel más bajo de cualquierruta de lajerarquía enumerada. Por tica. El conjunto de facetas que describen los com ponentes se
ejemplo, una jerarquía enumerada para operaciones con v e n denom ina descriptor de facetas. G eneralm ente, la descripción
ta n a s podríaser por facetas se lim ita a un m áxim o de siete u ocho facetas.
o p e r a c io n e s v en ta n a
v is u a l iz a c ió n ¿Cuáles son las opciones
a b r ir
b a sa d o s en menú
v e n ta n a A b ie r ta
b a sa d o s en s i s t e m a s
v e n ta n a S is tema
• disponibles para clasificar
componentes?
C om o ilustración sencilla del uso de facetas en la clasifica

ción de com ponentes, considérese un esquem a [LIA93] que
cerra r hace uso del siguiente descriptor de facetas:
a t r a v é s de p u n t e r o (función, tipo de objeto, tipo de siste m a )
C ada una de las facetas del descriptor de facetas adopta uno

cam bio de tamaño
o m ás valores que en general serán palabras reservadas d e s
a t r a v é s de ó rd e n e s criptivas. P o r ejem plo, si función es una faceta de un com po
e s ta b le c e r T a m V e n ta n a , r e d im e n s io n a d o E s - nente, entonces entre los valores típicos que se asignan a esta
ta n d a r , c o n tr a e r V e n ta n a faceta podríam os contar:
p o r a r r a s tr e fu n c ió n = (copiar, desde) o bien (copiar, reem plazar,
a r r a s tr a r V e n ta n a , e s tir a r V e n ta n a todo)
r e o r d e n a c ió n de p l a n o s
L a utilización de m últiples valores de faceta hace posible
que la función prim itiva copiar se refine m ás exactam ente.
d e s p la z a m ie n to
L as palabras reservadas (valores) se asignan al conjunto de
facetas de cada com ponente de una cierta biblioteca de reutili
zación. C uandoun ingenierodel software desea ocultar la biblio
tec a en bu sca de posibles com p o n en tes para un diseño, se
La estructurajerárquica de un esquem a de clasificación enu especifica una lista de valores y se consulta la biblioteca en bus
m erado hace que sea sencillo com prenderlo y utilizarlo. Sin ca de posibles candidatos. P ara incorporar una función de dic
em bargo.antes de poder construir una jerarquía, es preciso lle cionario se pueden em plear herram ientas autom atizadas. Esto
v a ra cabo una ingenieríadel dom inio para que esté disponible hace posible que la búsqueda no sólo abarque las palabras reser
una cantidad suficiente de conocim ientos acerca de las entra vadas especificadaspor el ingeniero del softw are, sino tam bién
das correctas de esa jerarquía. otros sinónim os técnicos de esas m ism as palabras reservadas.
www.FreeLibros.org
1 Solamente se indica un pequeño subconjunto de todas las opera
ciones posibles.
483
I NGE NIERÍA DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
Un esquema de clasificación por facetas proporcionaal inge to s ) que p e rm ite a la a p lic a c ió n c lie n te re c u p e ra r
niero del dominio una mayor flexibilidad al especificar des lo s c o m p o n e n te s y s e rv ic io s d el s e rv id o r d e la
criptores complejos de los componentes [FRA94], Dado que
b iblioteca.
es posible añadir nuevos valores de facetas con facilidad, el
esquema de clasificación por facetas es más fácil de extender • unas herram ientas C A S E que prestan su apoyo a la
y de adaptar que el enfoque de enumeración. integración de com ponentes reutilizados en un nuevo
Clasificaciónde atributos y valores. Para todos los com d iseño o im plem entación.
ponentes de una cierta zona del dominio se define un conjun
to de atributos. A continuación, se asignan valores a estos C a d a u n a de e sta s fu n c io n e s in te ra ctú a co n una
atributos de forma muy parecida a una clasificación por face b iblioteca de reutilización o b ien se encuentra incorpo
tas. De hecho, la clasificación de atributos y valores es pareci rad a a e sta últim a.
da a la clasificaciónpor facetas con las excepcionessiguientes: L a b iblioteca de reutilización es un elem ento de un
(1) no hay límite para el número de atributos que se pueden repositorio C A S E m ás ex ten so (C apítulo 3 1) y pro p o r
utilizar; (2) no se asignan prioridades a los atributos;y (3) no
c io n a las p o sib ilid a d es a d e c u a d as p a ra el alm ac en a
se utiliza la función diccionario.
m iento de una am plia gam a de elem entos reutilizables
B asándose en un estudio em pírico de cada u n a de las (por ejem plo, especificación, diseño, casos de prueba,
técnicas anteriores de clasificación, Frakes y Pole [FRA94] guías para el usuario). L a b iblioteca abarca una base de
indican que no existe una técnica que sea claram ente «la datos y las herram ientas necesarias para consultar esa
mejor» y que «ningúnm étodo es m ás que m oderadam ente b ase de d ato s y re c u p e ra r de e lla com ponentes. Un
adecuado en lo tocante a efectividad de búsq u ed a.. e sq u e m a de c la sific a c ió n de c o m p o n e n te s (Sección
Parece entonces que es p reciso realizar un trabajo m ás 27.5.1) servirá com o base para consultas efectuadas a
extenso en el desarrollo de unos esquem as de clasifica la biblioteca.
ción efectivos p ara las bibliotecas de reutilización. L as consultas suelen caracterizarse m ediante el uso
del elem ento de contexto del M odelo 3C que se descri
2 7 .5 .2 . E l e n t o r n o d e r e u t i l i z a c i ó n b ía anteriorm ente. Si una consulta inicial d a lugar a una
L a reutilizació n de com ponentes de softw are debe de lista volum inosa de candidatos a com ponentes, enton
estar apoyada p o r un entorno que abarque los elem en ces se refin a la consulta para lim itar esa lista. A conti
tos siguientes: n u ació n , se ex trae n las in fo rm acio n es de concepto y
• una base de datos de com ponentes capaz de alm ace co n ten id o (d espués de h a b e r h a lla d o los candidatos a
com ponentes) para ayudar al desarrollador a que selec
nar com ponentesde softw are, así com o la inform ación
cione el com ponente adecuado.
de clasificación necesaria p ara recuperarlos.
U n a descripción detallada de la estructura de biblio
« un s is te m a d e g e s tió n d e b ib lio te c a s q u e p r o
tecas de reutilización y de las herram ientas que las ges
p o r c io n a a c c e s o a la b a s e d e d a to s .
tio n an v a m ás allá de los lím ites de este libro. El lector
• un s is te m a d e re c u p e ra c ió n d e c o m p o n e n te s de interesado debería consultar [H 0 0 9 1 ] y [LIN95] para
s o ftw a re (p o r e je m p lo , u n d is tr ib u id o r de o b je - m ás inform ación.
27.6 ECONOM IA DE LA ISBC----------

L a eco n o m ía de la in g e n ie ría del so ftw are b a sa d a en les indican que es posible obtener notables beneficios
co m p o n en tes tie n e un a tra c tiv o e v id e n te . E n te o ría , de negocios m ediante una reutilización agresiva del soft
debería pro p o rcio n ar a las em presas de softw are unas w are. Se m ejora tanto la calidad del producto, com o la
v entajas n otables en lo tocante a la calidad y a los tie m productividad del desarrollador y los costes en general.
pos de realización. É stas, a su vez, d eberían traducirse
en ahorros de costes. ¿E xisten datos reales que p resten
apoyo a n u estra intuición?
P ara re sp o n d e r a e sta p reg u n ta p rim ero e s p reciso ¡SBC no es un «rompe crismas» económico
si los componentes disponibles son /as correctos
com prender lo que se puede reu tilizar en un co ntexto
para el trabajo. S ilo reutilizaciónexige
de ingeniería del softw are, y cuáles son los costes aso
personalizoción, hoy que proceder con precaución.
ciados a la reutilización. C om o consecuencia, será posi
ble desarro llar un análisis de costes y de beneficios para C a l i d a d . E n un e n to rn o ideal, un com ponente del
la reutilización. softw are que se desarrolle para su reutilización estará
verificado en lo tocante a su corrección (véase el Capí
2 7 .6 .1 . I m p a c t o e n l a c a l i d a d , p r o d u c t i v i d a d y c o s te tulo 26) y no contendrá defectos. E n realidad, la verifi
www.FreeLibros.org
A lo larg o de los Ú ltim os añ o s, e x iste n n o tab les e v i cación form al no se lleva a cabo de form a rutinaria, y
dencias proced en tes de casos p rácticos en la in dustria los defectos pueden aparecer y aparecen. Sin embargo,
(por ejem plo, [HEN95], [M CM 95] y [LIM 94]), las cu a con ca d a reutilización, los defectos se van hallando y
484
CAPÍTULO 27 I N GE NIE RÍ A DEL S OF TWARE B A S A D A EN C O M P O N E N T E S
e lim in a n d o , y c o m o r e s u lta d o la c a lid a d d e l c o m p o n e n te mm ¿Cuáles son los tostes

m e jo r a . C o n e l t ie m p o , e l c o m p o n e n te lle g a a e s ta r v i r W asociados a la reutilizatión
tu a lm e n t e li b r e d e d e fe c to s . del software?
E n u n e s tu d io r e a liz a d o e n H e w le t- P a c k a r d , L im
[ L I M 9 4 ] in f o r m a q u e la ta s a d e d e fe c to s p a r a e l c ó d ig o • I n c r e m e n t o d e la d o c u m e n ta c ió n p a r a f a c il it a r la r e u
r e u tiliz a d o e s d e 0 ,9 d e fe c to s p o r K L D C , m ie n tr a s q u e t iliz a c ió n ;
la ta s a p a r a e l s o f t w a r e r e c ié n d e s a r r o lla d o e s d e 4 ,1 • M a n t e n im ie n t o y m e jo r a d e c o m p o n e n te s d e la r e u
d e fe c to s p o r K L D C . P a r a q u e u n a a p lic a c ió n e s té c o m t iliz a c ió n ;
p u e s t a p o r u n 6 8 p o r 100 d e c ó d i g o r e u t i l i z a d o , l a t a s a • L ic e n c ia s p a r a c o m p o n e n te s a d q u ir id o s e x te r n a m e n te ;
d e d e fe c to s s e rá d e 2 ,0 d e fe c to s — u n a m e jo r a d e l 5 1 p o r
• C r e a c ió n o a d q u is ic ió n y f u n c io n a m ie n t o d e u n d e p ó
1 0 0 p a r a la ta s a e s p e r a d a s i la a p lic a c ió n h u b ie r a s id o
s ito p a r a la r e u t iliz a c ió n ;
d e s a r r o lla d a s in r e u t iliz a c ió n — . H e n r y y F a lle r [ H E N 9 5 ]
• F o r m a c ió n d e l p e r s o n a l e n e l d is e ñ o y c o n s tr u c c ió n
in fo r m a n d e u n a m e jo r a d e c a lid a d d e l 3 5 p o r 1 0 0 .A u n
p a r a la r e u tiliz a c ió n .
c u a n d o e x is t e n r e c o r te s a n e c d ó t ic o s q u e a b a r c a n u n
e s p e c tr o r a z o n a b le m e n t e a m p l io e n p o r c e n t a je s d e m e jo A u n c u a n d o lo s c o s te s a s o c ia d o s a l a n á lis is d e l d o m i
r a d e la c a lid a d , e s ju s t o q u e la r e u t iliz a c ió n p r o p o r c io n io ( S e c c ió n 2 7 . 4 ) y e l f u n c io n a m ie n t o d e u n r e p o s it o
n e u n b e n e f ic io n o d e s p r e c ia b le e n f u n c ió n d e la c a lid a d r i o p a r a la r e u t iliz a c ió n p u e d e n r e s u lt a r n o t a b le s , m u c h o s
y f ia b ilid a d d e l s o ftw a r e p r o p o r c io n a d o . d e lo s c o s te s re s ta n te s in d ic a d o s a n te r io r m e n te s e e n f r e n
t a n c o n t e m a s q u e f o r m a n p a r t e d e la s b u e n a s p r á c t i c a s
d e la in g e n ie r í a d e l s o ftw a r e , t a n to s i s e c o n s id e r a p r i o
r it a r ia la r e u t iliz a c ió n c o m o s i n o .
C LA VE 2 7 .6 .2 . A n á l i s i s d e c o s t e e m p l e a n d o p u n t o s
Aunque los datos empíricosvaríen, la evidencia d e e s tru c tu ra

industrial indica que la reutilización proporciona E n la S e c c ió n 2 7 . 3 . 3 se d e f in í a u n p u n t o d e e s tr u c tu r a
un beneficio sustancial en coste. c o m o u n a tr a m a a r q u it e c t ó n ic a q u e a p a re c e r e p e tid a
m e n te e n e l s e n o d e u n d e te r m in a d o d o m in io d e a p li
c a c io n e s . E l d is e ñ a d o r d e l s o ftw a r e ( o e l in g e n ie r o d e l
P r o d u c t iv id a d . C u a n d o s e a p lic a n c o m p o n e n te s r e u -
s is t e m a ) p u e d e d e s a r r o lla r u n a a r q u it e c t u r a p a r a u n a
tiliz a b le s a lo la r g o d e l p r o c e s o d e l s o ftw a r e , s e in v ie r t e
n u e v a a p lic a c ió n , s is t e m a o p r o d u c t o m e d ia n t e la d e f i
m e n o s t ie m p o c r e a n d o lo s p la n e s , m o d e lo s , d o c u m e n to s ,
n ic ió n d e u n a a r q u it e c t u r a d e l d o m in io y p o b lá n d o la
c ó d ig o y d a to s n e c e s a r io s p a r a c r e a r u n s is t e m a f ia b le .
e n to n c e s c o n p u n to s d e e s tr u c tu r a . E s to s p u n to s d e
S e s ig u e p r o p o r c io n a n d o u n m i s m o n i v e l d e f u n c i o n a li
e s tr u c tu r a s o n , o b ie n c o m p o n e n te s r e u t iliz a b le s , o b ie n
d a d a l c lie n t e c o n m e n o s e s fu e r z o . C o n s ig u ie n te m e n te ,
p a q u e te s d e c o m p o n e n te s r e u tiliz a b le s .
m e jo r a la p r o d u c t iv id a d . A u n c u a n d o lo s in f o r m e s a c e r
A u n c u a n d o lo s p u n to s d e e s tr u c tu r a s e a n r e u t iliz a -
c a d e la s m e j o r a s d e p r o d u c t i v i d a d s o n s u m a m e n t e d i f í
b le s , s u a d a p ta c ió n , in t e g r a c ió n y c o s te s d e m a n t e n i
c ile s d e i n t e r p r e t a r 8, p a r e c e q u e u n a r e u t i l i z a c i ó n d e e n t r e
m i e n t o n o s e r á n d e s p r e c ia b le s . A n t e s d e s e g u ir a d e la n te
e l 3 0 y e l 5 0 p o r 1 0 0 p u e d e d a r lu g a r a m e jo r a s d e p r o
c o n la r e u t iliz a c ió n , e l g e s to r d e l p r o y e c to d e b e e n te n
d u c tiv id a d q u e se e n c u e n tr e n e n tr e e l in te r v a lo q u e m e d ia
d e r lo s c o s t e s a s o c ia d o s a l u s o d e p u n t o s e s t r u c t u r a .
e n tre e l 2 5 y e l 4 0 p o r 1 0 0 .
D a d o q u e t o d o s lo s p u n to s d e e s t r u c t u r a ( y to d o s lo s
Coste. E l a h o r r o n e t o d e c o s t e s p a r a l a r e u t i l i z a c i ó n
c o m p o n e n te s r e u t iliz a b le s e n g e n e r a l) p o s e e n u n a h is
se e s tim a p r o y e c ta n d o e l c o s te d e l p r o y e c t o s i s e h u b ie
t o r ia p a s a d a , e s p o s ib le r e c o g e r d a to s d e c o s te s p a r a c a d a
ra d e s a r r o lla d o é s te d e s d e c e r o , C , y r e s ta n d o d e s p u é s
u n o d e e llo s . E n u n a s it u a c ió n id e a l, lo s c o s te s d e a d a p
la s u m a d e l o s c o s t e s a s o c i a d o s p a r a l a r e u t i l i z a c i ó n , C r ,
t a c i ó n , i n t e g r a c i ó n y m a n t e n i m i e n t o a s o c ia d o s a l o s c o m
y e l c o s te r e a l d e l s o ftw a r e c u a n d o e s te f in a lm e n t e se
p o n e n te s d e u n a b ib lio te c a d e r e u t iliz a c ió n se m a n tie n e n
im p la n t a , C ¡.
p a r a c a d a c a s o d e u t iliz a c ió n . E n to n c e s e s p o s ib le a n a
C s e p u e d e d e t e r m i n a r a p l i c a n d o u n a o m á s d e la s
liz a r e s to s d a to s p a r a d e s a r r o lla r u n a e s tim a c ió n d e c o s
té c n ic a s d e e s t im a c ió n d e s c r ita s e n e l C a p í t u lo 5 . L o s
te s p a r a e l p r ó x im o c a s o e n q u e s e u t ilic e n .
c o s te s a s o c ia d o s a la r e u t i l i z a c i ó n , C r , in c l u y e n
C o m o e je m p lo , c o n s id é r e s e u n a n u e v a a p lic a c ió n ,
[C H R 9 5 ]:
X , q u e r e q u ie r e u n 6 0 p o r 1 0 0 d e c ó d ig o n u e v o , y la r e u -
• M o d e la d o y a n á lis is d e l d o m in io ;
t i li z a c i ó n d e t r e s p u n t o s d e e s t r u c t u r a , P E , , P E , y P E ,.
• D e s a r r o llo d e la a r q u it e c t u r a d e l d o m in io ; C a d a 'u n o d e e s to s c o m p o n e n t e s r e u t il iz a b le s h a s id o
www.FreeLibros.org
8 Existen m uchas circunstancias a te n u an te s (por ejem plo, área de
aplicación, complejidad del problema, estructura y tam año del equipo,
duración del proyecto, tecnología aplicada) que puede te n e r su
impacto sobre la productividad del equipo de un proyecto.
485
INGE NIE RÍ A DEL S O F TW A RE . UN E N F O Q U E P R Á C T I C O
utilizado en un cierto núm ero de aplicaciones adicio lización en un sistem a basado en com putadoras. Los
nales, y los costes m edios de adaptación, integración y beneficios asociados a la reutilización dentro de un sis
mantenim iento están disponibles. tem a S se pueden expresar com o el siguiente cociente
Rb ($)= I f 's in reutilización' ^ con le u tiliz a á á n ] / ^ s in reutilización ( 2 7 .1 )
■IB ¿Existe un cálculo rápido
W que permita estimar donde
el beneficio de la reutilización C • reutilización es coste de desarrollar S sin reutilización,
y sin
de componentes en términos
de coste? C reutilización es coste de d esa rro llará con reutilización
De lo que se deduce que R b(S) se puede expresar
Para estim ar el esfuerzo requerido para proporcionar com o un valor no dim ensional que se encuentra en el
la aplicación,X, es preciso efectuar el siguiente cálculo: intervalo
esfuerzo global = Enuevo + E¡gua, + Eada¡mián + E¡n(egración 0 < R h( S ) < \ (27.2)
donde D evanbuy sus colaboradores [DEV95] sugieren que

EnUevo = es el esfuerzo que el ingeniero requiere para cons (1) R, se verá afectado por el diseño del sistema; (2)
tru ir los nuevos com ponentes de softw are (que se determ ina dado que R, se ve afectado por el diseño, es im portan
rá em pleando las técnicas descritas en el C apítulo 5); te hacer que R , forme parte de la estim ación de alter
Ejguai = es e l esfuerzo requerido para cualificar P E ,, PE , y
nativas de diseño; y (3) los beneficios asociados a la
PE ,; ‘' reutilización estarán íntim am ente relacionados con los
beneficios en términos de costes de cada uno de los com
âdaptación = es el esfuerzo requerido para adaptar P E ,, PE,
Y PE 3;
ponentes reutilizables individuales.
Se define una m edida general de reutilización en los
întegración = es el esfuerzo requerido para integrar P E ,, PE,
sistemas orientados a objetos, denom inada apro'ech a
y PE,;
miento de reutilización [BAN94] en la siguiente forma:
El esfuerzo necesario para cualificar, adaptar e inte âprovechado" ^^‘freutilizados^^'fconstruidos (27.3)
grar PE,, PE, y PE, se determ ina calculando la m edia
de datos históricos recogidos para la cualificación, adap donde
O B /reuti|izados es el núm ero de objeto s reu tilizad o s en el
tación e integración de los com ponentes reutilizables
sistem a;
en otras aplicaciones.
(^^construidos es el núm ero de objetos construidos para el
sistem a.
27.6.3. Métricas de reutilización
Se ha desarrollado toda una gam a de métricas de soft De lo que se deduce que a m ed id a que aum enta
ware en un intento de m edir los beneficios de la reuti â provechado’ tam bién aum enta R,.
RESUMEN
La ingeniería del software basada en componentes rrollo basado en componentes cualifica, adapta e inte
proporciona unos beneficios inherentes en lo tocante a gra estos componentes para su reutilización en un siste
calidad del software, productividad del desarrollador y m a nuevo. Además, el desarrollo basado en componentes
coste general del sistema. Sin embargo, es preciso ven diseña componentes nuevos que se basan en los requi
cer muchas dificultades antes de que el m odelo de pro sitos personalizados de un sistema nuevo.
ceso ISB C se utilice ampliamente en la industria. Las técnicas de análisis y diseño de componentes
Además de l o s com ponentes del software, un inge reutilizables se basan en los m ismos principios y con
niero del softw are puede adquirir toda una gam a de ceptos que forman parte de las buenas prácticas de inge
elem entos reutilizables. E ntre estos se cuentan las niería del softw are. Los com ponentes reutilizables
representaciones técnicas del software (por ejem plo, deberían de diseñarse en el seno de un entorno que esta
especificación, m odelos de arq u itectu ra, diseños y blezca unas estructuras de datos estándar, unos proto
códigos), docum entos, datos de prueba e incluso tare colos de interfaz y unas arquitecturas de program a para
as relacionadas con los procesos (por ejem plo, técni todos los dominios de aplicación.
cas de inspección). La ingeniería del software basada en componentes
El proceso ISB C acompaña a dos subprocesos con hace uso de un m odelo de intercam bio de datos; herra
currentes - in g e n ie r ía d e l dominio y desarrollo basado m ientas, alm acenam iento estructurado y un m odelo
en componentes— . El objetivo de la ingeniería del domi objeto subyacente para construir aplicaciones. El mode
www.FreeLibros.org
nio es identificar, construir, catalogar y disem inar un lo de objetos suele ajustarse a uno o m ás estándares de
conjunto de componentes de software en un determ i com ponentes (por ejem plo, OM G/CORBA) que defi
nado dom inio de aplicación. A continuación, el desa nen la form a en que una aplicación puede acceder a los
486
CAPÍTULO 27 I NGENI ERÍ A DEL S OF TWARE BA S A D A EN C O M P O N E N T E S
objetos reutilizables. Los esquem as de clasificación La econom ía de reutilización del softw are se abar
capacitan al desarrollador para hallar y recuperar com ca con una Unica pregunta: ¿Es ren tab le co n stru ir
ponentes reutilizables y se ajustan a un modelo que iden m enos y reu tilizar m ás? En general, la respuesta es
tifica conceptos, contenidos y contextos. La clasificación «sí», pero un planificador de proyectos de softw are
enumerada, la clasificación de facetas, y la clasifica debe considerar los costes no triviales asociados a la
ción de valores de atributos son representativas de adaptación e integración de los com ponentes reu tili
muchos esquem as de clasificación de com ponentes. zables.
[A D L 9 5 ] A d le r, R .M ., «Engineering Standards fo r C om po- [H U T 8 8 ] Flutchinson, J.W ., y P.G. Flindley, « A P re lim in a ry

nent Softw are», C o m p u t e r , vol. 2 8, n.° 3, M a rz o de 1995, Study o f Large Scale Softw are Reuse», S o f t w a r e E n g i n e e
pp. 68-77. r i n g J o u r n a l , vol. 3, n.° 5 , 1 9 9 8 ,pp. 2 08 -2 12 .
[BAS94] B as ili, V.R ., L .C . B ria n d y W .M . Thom as, «D om ain [L IM 9 4 ] L im , W .C ., «Effects o f Reuse on Q u ality, Producti-
Analysis fo r the Reuse o f Softw are D evelopm ent E xp e- vity, and Economics», I E E E S o f t w a r e , Septiem brede 1994,
riences», P r o c . O f t h e 1 9 !l> A n n u a l S o f t w a r e E n g i n e e r i n g pp. 2 3-3 0 .
W o r k s h o p , N A S A /G S F C , Greenbelt, M D , D ic iem b re de [L IA 9 3 ] L ia o , H . , y F . W ang, « S o ftw are R euse Based on a
1994. Large O b ject-O riented Library», A C A / S o f t w a r e E n g i n e e
[B EL95] B e llin zo n a ,R ., M .G . G u g in iy B. P em ici, «Reusing r i n g N o t e s , vol. 18,n.° 1, Enero de 1993, pp. 74-8 0 .
Specifications in O O A pplications», I E E E S o f t w a r e , M a r [L IN 9 5 ] L in th ic u m , D .S ., «Com ponent D evelopm ent (asp e-
zo de 1 9 9 5 ,pp. 65-75. cial featu re)», A p p l i c a t i o n D e v e l o p m e n t T r e n d s , Junio de
[B IN 93] B in der, R ., «D esign fo r Reuse is fo r R e a l» , A m e r i 1995, pp. 57-78.
c a n P r o g r c n n m e r , vol. 6, n.° 8, Agosto de 1 9 9 3 ,p p . 3 3- [M C M 9 5 ] M c M ah o n , P.E., «Pattem -Based Architecture: B rid-
37. ging Softw are R euse and Cost M anag em ent», C r o s s t a l k ,
[B R 0 9 6 ] B ro w n , A .W ., y K .C . W a lln a u , « E n g in ee rin g o f vol. 8, n.° 3, M a rz o de 1995, pp. 10-16.
C om ponent B ased System s», C o m p o n e n t - B a s e d S o f t [O R F 9 6 ] O rfa li, R ., D . Flarkey y J. Edw ards, T h e E s s e n t i a l
w a r e E n g i n e e r i n g , T E F E C o m p u ter Society Press, 1996, D i s t r i b u t e d O b j e c t s S u r v i v a l G u i d e , W ile y , 1996.
pp. 7-15.
[P R I8 7 ] P rie to -D ía z , R ., « D o m a in A n a ly s is fo r R eu sab i-
[C H R 95] Christensen, S.R ., «So ftw are Reuse Iniciatives at lity » , P r o c . C O M P S A C '8 7 , T o k y o , O ctu b re de 1 987,
Lockheed», C r o s s t a l k , v ol. 8, n.° 5 , M a y o de 1 99 5,pp. 26- pp. 2 3 -2 9 .
31.
[P R I9 3 ] P rieto -D íaz, R ., «Issues andE xp eriencesin Softw are
[C LE95] Clem ens, P C ., «From Subroutines to Subsystems: Reuse», A m e r i c a n P r o g r a m m e r , vol. 6, n.° 8, Agosto de
Com ponent-Based S o ftw are D e v e lo p m e n t» , A m e r i c a n 1 9 9 3 ,pp. 10-18.
P r o g r a m m e r , y ol. 8, n.° 1 1 ,N o vie m b re de 1995.
[P O L 9 4 ] P ollak, W ., y M . Rissm an, «Structural M o d e ls and
[D E V 95 ] D evanbu, P. et al., «A n a lytic al and E m p irica l E va- Pattem ed A rchitectures», C o m p u t e r , vol. 2 7 ,n .° 8, A g o s
lu a tio n o f S o ftw are R euse M e tric s » , T e c h n i c a l R e p o r t , to de 1 99 4,p p . 67-68.
Com puter Science D epartm ent, U niversity o f M a ryla n d , [S T A 9 4] Staringer, W ., «Constructing A pplications fro m Reu-
Agosto de 1995. s a b l e C o m p o n z n X s » , I E E E S o f t w a r e , S ep tiem brede 1994,
[FR A 94] Frakes, W .B ., y T.P. Pole, « A n E m p irica l Study o f pp. 6 1-6 8 .
Representation M ethods fo rR e u s a b le Softw are C o m p o - [T R A 9 0 ] Tracz, W ., «W h e re Does Reuse Start?», P r o c . R e a -
nents » , I E E E T r a n s . S o f t w a r e E n g i n e e r i n g , vol. 2 0, n.° 8, l i t i e s c f R e u s e W o r k s h o p , Syracuse U niversity C A S E C e n -
Agosto de 1 9 9 4 ,pp. 6 17 -6 30 . ter, E nero de 1990.
[H A R 98] Elarm on, P., «N avig atin g the D istribu ted C om po- [T R A 9 5 ] Tracz, W ., « Third International C onference on S oft
nents Landscape», C u t t e r I T J o u r n a l , vol. l l , n . ° 2 , ware Reuse-Sum m ary», A C A / S o f t w a r e E n g i n e e r i n g N o t . e s ,
D iciem bre de 1 9 9 8 ,pp. 4-11. vol. 2 0, n.° 2, A b ril de 1995, pp. 2 1-2 2 .
[H E N 9 5 ] Elenry, E ., y B . F a lle r, « L a rg e S cale In d u s tria l [W H I9 5 ] W h ittle , B ., «M odels and Languages fo r C o m p o
Reuse to Reduce Cost and C ycle T im e » , I E E E S o f t w a r e , nent D escription and Reuse», A C M S o f t w a r e E n g i n e e r i n g
Septiembre de 1995, pp. 4 7-5 3 . N o t e s , vol. 2 0, n.° 2, A b ril de 1995,pp. 76-89.
[H 0 0 9 1 ] Flooper, J .W .,y R .O . C Y ie s t e x , S o f t w a r e R e u s e : G u i- [Y O U 9 8 ] Y o u rdon,E . (ed.), «Distributed Objects», C u tte r I T

d e l i n e s a n d M e t h o d s , P lenum Press, 1991. J o u r n a l , vol. l l , n . e 1 2 ,D ic iem b re de 1998.
INGENIERIA DEL S O F TW A R E . UN EN F O Q U E P R A C T I C O
PRO -LEM, •- i < * TOS A CONSIDERAR

27.1. U no de los obstáculos principales de la reutilización con 27.7. Desarrolle un m odelo estructural sencillo para un d o m i
siste en hacer que los desarrolladores de softwareconsideren la nio de aplicación que le asigne su instructor, o bien uno con el
reutilización de componentes y a existentes,en lugar de volver cual esté fam iliarizado.
a inventar otros nuevos. (¡Después de todo, es divertido cons
truir cosas!) Sugiera tres o cuatro form as distintas en que una 27.8. ¿Qué es un punto de estructura?
organización de softw are pueda proporcionar incentivos para 27.9. Obtenga inform ación de los estándares más recientes de
que los ingenieros de softw are u tilicen la reutilización. ¿Qué C O R B A , C O M o de JavaBeans y prepare un trabajo de 3 a 5
tecnologías deberían de estar implantadas para apoy árese esfuer páginas que trate los puntos m ás destacables. Obtenga in fo r
zo de reutilización? m ación de una herram ienta de distribución de solicitudes de
27.2. A unque los componentes de softw are son los «elem en objetos e ilustre en que esa herram ienta se ajusta al estándar.
tos» reutilizables más obvios, se pueden reutilizar muchas otras
27.10. Desarrolle una clasificaciónenum erada para un dom inio
entidades producidas com o parte de la ingeniería del softw are.
de aplicación que le asigne su instructor o para uno con el cual
Tenga en consideración los planes de proyecto y las estim acio
esté fam iliarizado.
nes de costes. ¿Cómo se pueden reutilizar y cuál es el benefi
cio de hacerlo? 27.11. Desarrolle un esquema de clasificación por facetas para
27.3. L leve a cabo una pequeña investigación acerca de la inge un dom inio de aplicación que le asigne su instructor o bien para
niería de dom inios, y detalle algo más el m odelo de procesos uno con el cual esté fam iliarizado.
esbozadoen la Figura 27.1. Identifique las tareas necesarias para 27.12. Investigue en la literatura para conseguirdatos recientes
el análisis de dom inios y para el desarrollo de arquitecturas de de calidad y productividad que apoyen la utilización. Presente
software. esos datos al resto de la clase.
27.4. ¿En qué sentido son iguales las funcionesde caracteriza
27.13. Se estim a que un sistema orientado a objetos requiere
ción para los dom inios de aplicaciones y los esquemas de cla-
3 20 objetos para su finalización.Adem ás, se estima que es posi
sificaciónde componentes? ¿En qué sentido son distintas?
ble adquirir 190 objetos procedentes de un depósito y a exis
27.5. Desarrolle un conjunto de característicasdel dom iniopara tente. ¿Cuál es el aprovecham iento de reutilización? Suponga
sistemas de inform ación que sean relevantes para el procesa que los objetos nuevos cuestan2 60.000 pts., y que se necesitan
m iento de datos de alumnos de una Universidad. 1 56.000 pts. para adaptar un objeto y 1 04.000 pts. para inte
27.6. Desarrolle un conjunto de características del dom inio que grarlo. ¿Cuál es el coste estim ado del sistema? ¿Cuál es el valor
sean relevantes para el software de publicación y autoedición. de Rb?
OTRAS LECTURAS Y FUENTES DE IN FO R M A C IÓ N

Durante los últim os años se han publicado libros sobre el de métodos cuantitativos para valorarlos beneficios de la reu
desarrollo basado en com ponentes y la reutilización de c o m tilización del software.
ponentes. A lie n , Frost y Yourdon (Component-Based Develop- Durante los Últimos años se han publicado docenas de libros
mentfor Enterprise Systems: Applying the Select Perspective, que describen los m ism os estándares basados en componentes
Cam bridge U niversity Press, 1998) abarca todo el proceso de de la industria, pero tam bién tienen en consideración muchos
IS B C mediante el uso de U M L (Capítulos 21 y 2 2 ) basándose tópicos im portantesde la IS B C . A continuación se muestra un
en el enfoque del modelado. Los libros de L im (Managing Soft muestreo del estudio de los tres estándares:
ware Reuse: A Comprehensive Guide to Strategically Reengi-
neering the Organization f o r Reusable Components,
CORBA
Prentice-Flall, 1998), Coulange (Software Reuse, S prigerV er- D o ss , G .M ., CO RBA N etw orking Java, W o rd w a re
lag, 1998), R e ife r (Practica¡Software Reuse, W ile y , 1997), P ublish ing , 1999.
Jacobson, Griss y Jonsson (SoftwareReuse: Architecture Pro Floque, R ., C O R B A for R eal Prograrnmers, A ca d em ic
cess and Organizationfor Business Success, A ddison-W esley, Press/M organ K aufm ann, 1999.
1997) afronta m uchos temas de IS B C . F o w le r (Analysis Pat- S iegel, J., CORBA 3 Fundamentáis and Programming,
tems: Reusable Object M oféis, A ddison-W esley, 1996)consi- W ile y , 1999.
dera la aplicación de patrones arquitectónicos dentro del proceso S lam a ,D ., J. G arb isy P. Russell,£>7/<?7y>77.s<? CORBA, Pren-
de IS B C y proporciona muchos ejem plos Utiles. Tracz (Con- tic e -H a ll, 1999. '
fessions o f a Used Program Salesman: Institutionalizing Soft COM
ware Reuse, Addison-W esley, 1995)presenta un estudio algunas
B o x, D .K ., T. E w a ld y C. Sells, Effective Ways to Impro-
veces desenfadado y muy útil de los temas asociados con la cre
ación de una cultura de reutilización. ve YourCOM and M TS-Based Applications, Addison-'Wes-
ley, 1999.
Leach (Software Reuse: Methods, M odels and Costs,
K irtlan d , M ., Designing Component-Based Applications,
M c G ra w -H ill, 1997) proporciona un análisis detallado de los
www.FreeLibros.org
M ic ro s o ft Press, 1999.
estudiosde costes asociados con la IS B C y con la reutilización.
Poulin (Measuring Software Reuse: Principies, Practices, and M uchas com pañías aplican una com binación de estándares
Economic Models, Addison-W esley, 1996) sugiere un número de componentes. Los libros de Geraghty et al. (COM-CORBA
488
CAPÍTULO 27 INGENIERIA DEL S OF T WARE B A S A D A EN C O M P O N E N T E S
Interoperubility, Prentice-Hall, 1999), Pritchard (COM and Valesky, T . C Enterprise JavaBeans: Developing Com-
CORBA Side by Side: Architectures, Strutegies, und Imple - ponent-BasedDistributedApplicutions, Addison-Wesley, 1999.
mentaiions, Addsion-Wesley, 1999)y Rosen etal. (Integrating Vogel,A., y M. Rangarao, Programming with Enterprise
CORBA und COMApplicutions, Wiley, 1999) tienen en consi JavaBeans, JTS und OTS, Wiley, 1999.
deración los temas asociados con la utilización de CORBA y En Intemet está disponible una gran variedad de fuentes
COM como base para el desarrollobasado en componentes. de información sobre la ingeniería del software basada en
JavaBeans componentes. Una lista actualizada de referencias en la red
Asbury, S., y S.R. Weiner ,Developing Javu Enterprise que son relevantes para la ISBC se puede encontrar en la direc
Applications, Wiley, 1999. ción http://www.pressman5.com
www.FreeLibros.org
c a p it u l o |NGEN|ER ÍA De l SOFTWARE
O O DEL COMERCIO ELECTRÓNICO
¿ O CLIENTE / SERVIDOR
fí n a le s d e s ig lo , e l d e s a r r o llo d e u n a n u e v a g e n e r a c ió n d e m á q u in a s h e r r a m ie n ta s c a p a
A c e s d e s o p o r t a r fu e r te s t o le r a n c ia s d ie r o n p o d e r a lo s in g e n ie r o s q u e d is e ñ a b a n u n p r o
c e s o n u e v o d e f a b r ic a c ió n lla m a d o p r o d u c c ió n e n m a s a . A n t e s d e la lle g a d a d e e s ta
t e c n o lo g í a a v a n z a d a d e m á q u in a s h e r r a m ie n ta s , n o s e p o d í a n s o p o r t a r fu e r te s t o le r a n c ia s . P e r o
c o n e s ta t e c n o lo g í a s e p o d í a n c o n s t r u ir p ie z a s in t e r c a m b ia b le s y f á c ilm e n t e e n s a m b la b le s —
la p ie d r a a n g u la r d e la p r o d u c c ió n e n m a s a — .
C u a n d o s e v a a d e s a r r o lla r u n s is t e m a b a s a d o e n c o m p u t a d o r a , u n in g e n ie r o d e s o f t w a r e s e
v e r e s t r i n g i d o p o r la s l i m i t a c i o n e s d e la s t e c n o l o g í a s e x i s t e n t e s y p o t e n c i a d o c u a n d o l a s t e c
n o l o g í a s n u e v a s p r o p o r c i o n a n c a p a c i d a d e s q u e n o e s t a b a n d i s p o n i b l e s p a r a la s g e n e r a c i o n e s
a n t e r i o r e s d e i n g e n i e r o s . L a e v o l u c i ó n d e la s a r q u i t e c t u r a s d i s t r i b u i d a s d e c o m p u t a d o r a h a c a p a
c it a d o a lo s in g e n ie r o s d e s is t e m a s y d e l s o f t w a r e p a r a d e s a r r o lla r n u e v o s e n f o q u e s s o b r e c ó m o
se e s tr u c tu r a e l tr a b a jo y c ó m o se p r o c e s a la in fo r m a c ió n d e n tr o d e u n a e m p re s a .
L a s n u e v a s e s t r u c t u r a s d e la s o r g a n i z a c i o n e s y l o s n u e v o s e n f o q u e s d e p r o c e s o d e i n f o r m a c i ó n
( p o r e j e m p l o : t e c n o l o g í a s i n t r a n e t e I n t e r n e t , s i s t e m a s d e a p o y o a la s d e c i s i o n e s , s o f t w a r e d e g r u
p o , e i m á g e n e s ) r e p r e s e n t a n u n a s a l i d a r a d i c a l d e la s p r i m e r a s t e c n o l o g í a s b a s a d a s e n m i n i c o m
p u ta d o r a s o e n m a in fr a m e s . L a s n u e v a s a r q u it e c t u r a s d e c o m p u t a d o r a h a n p r o p o r c io n a d o la te c n o lo g í a
q u e h a h e c h o p o s i b l e q u e la s e m p r e s a s v u e l v a n a d i s e ñ a r s u s p r o c e s o s d e n e g o c i o ( C a p í t u l o 3 0 ) .
E n e s te c a p í t u lo , e x a m in a r e m o s u n a a r q u it e c t u r a d o m in a n te p a r a e l p r o c e s o d e in f o r m a c ió n
— lo s s is t e m a s c lie n t e ! s e m id o r ( C / S ) d e n t r o d e l c o n t e x t o d e lo s s is t e m a s d e c o m e r c io e l e c t r ó
n ic o — . L o s s is t e m a s c lie n t e / s e r v id o r h a n e v o l u c io n a d o j u n t o c o n lo s a v a n c e s d e la i n f o r m á t i
c a p e r s o n a l , e n l a i n g e n i e r í a d e l s o f t w a r e b a s a d a e n c o m p o n e n t e s , c o n la s n u e v a s t e c n o l o g í a s
d e a lm a c e n a m ie n to , c o m u n ic a c ió n m e jo r a d a a tr a v é s d e r e d e s , y t e c n o lo g í a d e b a s e s d e d a to s
m e j o r a d a s . E l o b j e t i v o d e e s t e c a p í t u l o ' e s p r e s e n t a r u n a v i s i ó n g l o b a l y b r e v e d e l o s s is t e m a s
c lie n t e / s e r v id o r c o n u n é n fa s is e s p e c ia l e n lo s te m a s d e la in g e n ie r í a d e l s o f t w a r e q u e d e b e n d e
a f r o n t a r s e c u a n d o s e a n a liz a n , d is e ñ a n , p r u e b a n y s e d a s o p o r t e a d ic h o s s is t e m a s C /S .
VISTAZO RAPIDO
¿Qué as? Las arquitecturas cliente/servi dominante. Puesto que los avances tec- lidad del cliente y del servidordentro del
dor (CVS) dominan el horizontede los sis nológicos(por ej emplo,desarrollo basa contexto de losestándares de integración
temas basados en computadora. Todo do en componentes,agentesde solicitud de componentes y d e 1a arquitectura C/S.
existe: desde redes de cajeros automá de objetos, Java) cambian la forma de ¿Cuál es el p ro d u c to o b te n id o ? Un
ticos hasta Internet. y esto es debido a construir los sistemas C/S, en su cons sistema C/S de alta calidad es el pro
que el software que reside en una com trucción se debe deaplicar un proceso ducto de la ingeniería del software C/S,
putadora - e lcliente— solicita servi de ingeniería del software sólido. También se producen otros productos
cios y/o datosde otra computadora -el ¿Cuáles son los pasos? Los pasos que de trabajo de software (tratados ante
servidor—. La ingeniería del software se siguen en la ingeniería de los siste riormente en este mismo libro).
cliente/servidor combina principios con mas C/S son similares a los que seapli- ¿Cómo puedo e s ta r segure d e que lo
vencionales, conceptos y métodos tra can durante la ingeniería del software h e h e c h o c o rre c ta m e n te ? Utili
tados anteriormente en este libro, con basada en componentes y OO. El mode zando las mismas prácticas SQA que se
elementos de la ingeniería del softwa lo de proceso es evolutivo, comenzan aplican en todos los procesos de inge
re basada en componentes y orientada do por la obtención de los requisitos. niería del software—las revisiones téc
a objetos para crear sistemas C/S, La funcionalidad se asigna a los subsis nicas formales evalúan los modelos de
¿Quién lo h a c e ? Los ingenieros de soft temas decomponentesque se van aasig- análisis y diseño-;las revisiones espe
ware llevan a cabo el análisis, diseño, n a despuésobienalclienteoal servidor cializadas consideran los temas aso
implementación y prueba de estos sis de la arquitectura C/S. El diseño se cen ciados a la integración decomponentes
temas. tra en l a integración de los componentes y al software intermedio (middlewaie),
¿P o rq u é as im portante? El impacto de existentes y en la creación de compo y las pruebas se aplican para desvelar
los sistemas C/S en los negocios, el nentes nuevos. la implementacióny las errores al nivel de componentes, sub-
comercio. el gobierno y la ciencia es pruebas luchan por ejercitarla funciona sistema,cliente y servidor.
www.FreeLibros.org
1Parte de este capítulo se ha adaptado a partir del material de cursos desarrollado por John Porter para el Client/Server Curri
culum ofrecido en la Facultad de Ingeniería BE1 de la Universidad de Fairfield. Se ha obtenido permiso para su utilización.
49 1
INGENIERÍA DEL S O F T W A R E . UN E N F O Q U E P R Á C T I C O
ÍZ
Los últimos diez años han sido testigos de avances m asi datos que contienen las com putadoras que com ponen el
vos en las áreas de computación. La prim era es que el sistema. En lugar de tener que reproducir los datos en
hardware se ha ido abaratando cada vez más, y a su vez todas las com putadoras se pueden distribuir por un
se ha ido haciendo m ás potente: las com putadoras de pequeño número de computadoras. Un sistema distribuido
sobremesa hoy en día tienen la potencia que poseían los tam bién proporciona acceso a servicios especializados
mainframes hace algunos años. La segunda área es la de que quizás no se requieran muy frecuentemente,y que se
las comunicaciones; avances tales como los sistemas de puedan centralizaren una com putadora del sistema.
comunicación vía satélite y los sistemas de teléfonos digi
tales significa que ahora es posible conectar económ ica C ^ C /fa ;
mente y eficientemente con otros sistemas informáticos f ! modelo de computación C/S representa
separados físicamente. Esto ha llevado al conceptode un 4 *i ejempb específico de proceso cooperativo
sistema de com putación distribuido. Dicho sistema con «fe ' nde la relación entre clientes
siste en un núm ero de com putadoras que están conecta e los componentes
das y que llevan a cabo diferentes funciones. Existen líWÓ M hardware como del software.
muchas razones por las que tales sistemas se han hecho ÍIk I w sm
populares:
Tolerancia a fallos. Un sistema distribuido se puede
Rendimiento. El rendim iento de m uchos tipos de diseñar de forma que tolere los fallos tanto del hardware
sistemas distribuidos se puede increm entar añadiendo como del software. Por ejemplo, se pueden utilizar varias
simplemente m ás computadoras. Norm alm ente esta es com putadoras que lleven a cabo la m ism a tarea en un
una opción m ás sencilla y m ás barata que m ejorar un sistem a distribuido. Si una de las com putadoras fu n
procesador en un mainframe. Los sistem as típicos en cionaba m al, entonces una de sus herm anas puede
donde se puede lograr este increm entoen el rendimiento hacerse cargo de su trabajo. Una base de datos de una
son aquellos en donde las com putadoras distribuidas com putadora se puede reproducir en otras com putado
llevan a cabo m ucho proceso, y en donde la relación tra ras de forma que si la com putadora original tiene un mal
bajo de comunicaciones y proceso es bajo. funcionam iento, los usuarios que solicitan la base de
Compartición de recursos. Un sistema distribuido datos son capaces de acceder a las bases de datos repro
permite a sus usuarios acceder a grandes cantidades de ducidas.
28.2 s i s t e m a s nmmmmíms____
282.1. C lientes y servidores poca potencia para comunicarse con el central. Los dos
El propósito de esta sección es introducir tanto la idea problem as m ás serios son la dificultad de m ejorar y de
de cliente com o la de servidor. Estos son los bloques copiar con interfaces IGU modernas. A m edida que las
básicos de construcción de un sistema distribuido y, de aplicaciones van siendo más grandes, la carga de una main
esta m anera, cuando se describa el diseño y el desarro frame común llega al punto en que también necesita mejo
llo de dichos sistemas, será necesario tener conocimiento rar y normalmente con hardware de procesamientonuevo,
de sus funciones y de su capacidad. memoria o alm acenam ientode archivos. Mejorar dichas
Un servidor es una com putadora que lleva a cabo com putadoras es más fácil que antes; sin embargo, pue
un servicio que norm alm ente requiere m ucha poten de resultar un proceso moderadamente difícil y caro -es
cia de procesam iento. Un cliente es una com putadora ciertamente más caroy más difícil que añadirun servidor
que solicita los servicios que proporciona uno o m ás nuevo basado en PC a un conjunto de computadorascon-
servidores y que tam bién lleva a cabo algún tipo de figuradas como clientes y servidores— . El segundo pro
procesam iento por sí mismo. Esta form a de organiza blem a es hacerse con interfaces IGU modernas. Para
ción de com putadoras es totalmente diferente a los dos ordenar a una computadora que visualice incluso una pan
modelos que dom inaron los años ochenta y principios talla relativamente prim itiva relacionada, digamos, con
de los noventa. unos cuantos botones y una barra de desplazamiento de
El primer modelo se conoce como procesamiento cen la misma, conlleva tanto tráfico en las líneas de comuni
tral (host). En este modelo de organización todo el pro cación que un sistema podría colapsarse fácilmente con
cesamiento que se necesitaba para una organización se los datos que se utilizan para configurar y m anterer una
www.FreeLibros.org
llevaba a cabo por una com putadora grande — normal serie de interfaces basadas en IGUs.
mente una m ainfram e— m ientras que los usuarios El segundo modelo de com putación es en donde hay
emplean sencillas terminales inform áticaso PCs de muy un grupo de com putadoras actuando com o servidores,
492
CAPÍTULO 28 I NGENI ERÍ A DEL S OF TWARE DEL C O M E R C I O E L E C T R Ó N I C O C L I E NT E/ S ERVI DOR
pero poseen poco procesam iento que llevar a cabo. N or bre de cuenta, nom bre del titular de la cuenta, saldo
malmente estos term inales poco inteligentes actuarían actual de la cuenta y límite de descubierto de la cuenta.
como servidores de archivos o servidores de impresión U na de las característicasde las bases de datos que inva
para un número de PCs potentes o minicomputadoras lidan la utilización de los servidores de archivos e s que
que llevarían a cabo el procesam iento y estarían conec los archivos que se crean son enorm es y ralentizan el
tados a una red de área local. Las com putadoras clien tráfico si se transfirieran en bloque al cliente. A fortu
te solicitarían servicios a gran escala, como es obtener nadamente, para la gran m ayoría de aplicaciones no se
un archivo, llevando a cabo entonces el procesam iento requiere dicha transferencia; por ejem plo en una apli
de dicho archivo. De nuevo, esto conduce a problemas cación bancaria las consultas típicas que se realizarían
con el tráfico en donde, por ejemplo, la transm isión de en una base de datos bancaria serían las siguientes:
archivos grandes a un núm ero de clientes que requie . Encontrar las cuentas de los clientes que tienen un
ren simultáneamente estos archivos hace que el tiempo descubierto m ayor de 2.000 pts.
de respuesta de la red vaya tan lento com o una tortuga.
. E ncontrar el saldo de todas las cuentas del titular
¿Qué es la informática John Smith.
diente/servidor? • Encontrar todas las órdenes regulares del cliente Jean
La computacióncliente/servidor es un intento de equi Smith.
librar el proceso de una red hasta que se com parta la • Encontrar el total de las transacciones que se reali
potencia de procesam iento entre com putadoras que lle zaron ayer en la sucursal de M anchester Picadilly.
van a cabo servicios especializados tales como acceder Actualm ente una base de datos bancaria típica ten
a bases de datos (servidores),y aquellos que llevan a cabo drá m illones de registros, sin em bargo, las consultas
tareas tales como la visualización IGU que es más ade anteriores conllevarían transferir datos a un cliente que
cuado para el punto final dentro de la red. Por ejemplo, sería solamente una fracción muy pequeña del tamaño.
permite que las com putadoras se ajusten a tareas espe En un entorno de bases de datos cliente/servidor los
cializadas tales como el procesam ientode bases de datos clientes envían las consultas a la base de datos, n or
en donde se utilizan hardware y software de propósito m alm ente utilizando alguna IGU. Estas consultas se
especial para proporcionar un procesam iento rápido de envían al servidor en un lenguaje llam ado SQL (Len
la base de datos com parado con el hardw are que se guaje de Consultas Estructurado). El servidor de bases
encuentra en las mainfTames que tienen que enfrentarse de datos lee el código SQL, lo interpreta y, a continua
con una gran gam a de aplicaciones. ción, lo visualiza en algún objeto HCI tal como una caja
de texto. El punto clave aquí es que el servidor de bases
de datos lleva a cabo todo el procesam iento, donde el
28.2.2. C a te g o r ía s d e s e r v id o r e s
cliente lleva a cabo los procesos de extraer una consul
Y a se ha desarrollado una gran variedad de servidores. ta de algún objeto de entrada, tal como un campo de tex
La siguiente lista ampliada se ha extraído de [ORF99]: to, enviar la consulta y visualizar la respuesta del
Servidores de archivos. Un servidor de archivos pro servidor de la base de datos en algún objeto de salida,
porciona archivos para clientes. Estos servidores se utili tal com o un cuadro de desplazamiento.
zan todavía en algunas aplicaciones donde los clientes S erv id o re s de so ftw a re de g ru p o . Softw are de
requieren un procesamiento com plicado fuera del rango grupo es el térm ino que se utiliza para describir el soft
normal de procesamientoque se puede encontrar en bases ware que organiza el trabajo de un grupo de trabajado
de datos comerciales. Por ejemplo, una aplicación que res. Un sistem a de softw are de grupo norm alm ente
requiera el almacenamiento y acceso a dibujos técnicos, ofrece las siguientes funciones:
digamos que para una empresa de fabricación, utilizaría
u n servidor de archivos para almacenar y proporcionar
• Gestionar la agenda de los individuos de un equipo
los dibujos a los clientes. Tales clientes, por ejemplo, serían de trabajo.
utilizados por ingenieros quienes llevarían a cabo opera • G estionar las reuniones para un equipo, por ejem
ciones con dibujos, operaciones que serían demasiado plo, asegurar que todos los m iem bros de un equipo
caras de soportar, utilizando una com putadora central que tienen que asistir a una reunión estén libres
potente. Si los archivos solicitados no fueran demasiado cuando se vaya a celebrar.
grandes y no estuvieran compartidos por un número tan • Gestionar el flujo de trabajo, donde las tareas se dis
grande de usuarios, un servidor de archivos sería una forma tribuyen a los m iem bros del equipo y el sistema de
excelente de almacenar y procesar archivos. software de grupo proporciona inform ación sobre la
S erv id o res de bases de d ato s. Los servidores de finalización de la tarea y envía un recordatorio al per
bases de datos son com putadoras que almacenan gran sonal que lleva a cabo las tareas.
www.FreeLibros.org
des colecciones de datos estructurados. Por ejemplo, un • Gestionar el correo electrónico, por ejemplo, organi
banco utilizaría un servidor de bases de datos para alm a zar el envío de un correo específico a los miem bros
cenar registros de clientes que contienen datos del nom de un equipo una vez term inada una tarea específica.
493
Un servidor de software de grupo guarda los datos inform ar a las com putadoras cliente que ya ha finali
que dan soporte a estas tareas, por ejemplo, almacena zado una petición de im presión en particular.
las listas de correos electrónicos y permite que los usua Servidores de aplicaciones. Un servidor de aplica
rios del sistem a de software de grupo se comuniquen ciones se dedica a una aplicación única. Tales servidores
con él, notificándoles, por ejemplo, que se terminado suelen escribirse utilizando un lenguaje tal como Java o
una tarea o proporcionándoles una fecha de reunión en C++. Un ejemplo típico del servidor que se utiliza en el
la que ciertos empleados puedan acudir. dibujo de un fabricante de aviones que gestionaba las ver
siones diferentes de dibujos producidos por el personal
| | | | ¿Qué es un servidor Web? técnico iría dirigido a algún proceso de fabricación.
Hf
28.2.3. Software intermedio (middleware)
Servidores Web. Los documentos Web se alm ace Hasta el m om ento probablem ente ya tenga la impresión
nan com o páginas en una com putadora conocida como de que la com unicación entre cliente y servidor es direc
servidor Web. Cuando se utiliza un navegador (brow- ta. Desgraciadamente, esto no es verdad: normalmente
ser) para ver las páginas Web normalmente pincha sobre existe por lo m enos una capa de software entre ellos.
<i enlace en un docum ento Web existente. Esto dará Esta capa se llam a software interm edio (middleware).
como resultado un mensaje que se enviará al servidor Como ejemplo de software interm edio considerem os la
Web que contiene la página. Este servidor responderá Figura 28.1. É sta m uestra la com unicación entre un
entonces enviando una página a su computadora, donde cliente ejecutando un navegador com o Internet Explo
el navegador pueda visualizarlo. De esta m anera los ser rer y un servidor Web.
vidores Web actúan com o una form a de servidor de
archivos, administrando archivos relativamente peque
ños a usuarios, quienes entonces utilizan un navegador El software
intermedio
para exam inar estas páginas. Para comunicarse con un determina
navegador Web, un cliente que utiliza un navegador está El navegador dónde está
solicita la página
haciendo uso a su vez de un protocolo conocido com o una página Web y la solicita
HTTP. al servidor
Servidores de correo. Un servidor de correo ges
Navegador
tiona el envío y recepción de correo de un grupo de usua
rios. Para este servicio norm alm ente se utiliza un PC de
rango medio. Existen varios protocolos para el correo
La página Web La página
electrónico. Un servidor de correo estará especializado es devuelta es enviada
en utilizar solo uno de ellos. al navegador al software
intermedio
Servidores de objetos. Uno de los desarrollos más por el servidc
excitantes en la inform ática distribuida durante los últi
mos cinco años ha sido el avance realizado, tanto por FIGURA 28.1. Software intermedio y servidor Web.
parte de los desarrolladores, como por parte de los inves
tigadores, para proporcionar objetos distribuidos. Estos A quí el software interm edio que se encuentra entre
son objetos que se pueden alm acenar en una com puta el servidor Web y el cliente que ejecuta el navegador
dora, norm alm ente un servidor, con clientes capaces de W eb intercepta las peticiones que proceden del nave
activar la funcionalidad del objeto enviando m ensajes gador. S i se hace una petición para una página Web
al objeto, los cuales se corresponden con métodos defi entonces determ ina la localización del docum ento
nidos por la clase de objeto. Esta tecnología liberará Web y envía una petición para esa página. El servidor
finalmente a los program adores de la program ación de responde a la petición y devuelve la página al software
bajo nivel basada en protocolos requerida para acceder intermedio, quien la dirige al navegador que la visuali
a otras com putadoras de una red. En efecto, esto per zará en la pantalla del m onitor que utiliza el cliente.
mite que el program ador trate a los objetos a 'distancia Existen dos categorías de software intermedio: el soft
como si estuvieran en su computadora local. Un servi w are interm edio general y el software interm edio de
dor que contiene objetos que pueden accederse a dis servicios. El prim ero es el que está asociado a los ser
tancia se conoce com o servidor de objetos. vicios generales que requieren todos los clientes y ser
vidores. El software típico que se utiliza com o tal es:
Servidores de impresión. L o s servidores de im pre
sión dan servicio a las solicitudes de un cliente remoto. • El software para llevar a cabo comunicaciones utili
Estos servidorestienden abasarse enPC s bastantebara- zando el protocolo TCP/IP y otros protocolos de red.
www.FreeLibros.org
tos, y llevan a cabo las funciones limitadas de poner en . El software del sistema operativo que, por ejemplo,
cola de espera las peticiones de impresión, ordenar a la mantiene un alm acenam iento distribuido de archi
im presora que lleve a cabo el proceso de im presión e vos. Este es una colección de archivos que se espar-
494
CAPÍTULO 28 I NGENI ERÍ A DEL S OF TWARE DEL C O M E R C I O E L E C T R Ó N I C O CLI E NT E/ S ERVI DOR
cen por un sistema distribuido. El propósito de esta • Un softw are interm edio asociado a productos de
parte del sistema operativo es asegurar que los usua seguridad específicos. Un buen ejem plo es el soft
rios pueden acceder a estos archivos, de forma que ware interm edio asociado a lo que se conoce com o
no necesiten conocer la localización de los archivos. conexiones (sockets) seguras. Estas son conexiones
que se pueden utilizar para enviar datos seguros en
una red de tal form a que hace imposible que intru
sos escuchen a escondidas los datos. Este tecnología
VE se describe en la Sección 28.8.
B software intermedio es el centro de un sistema
diente/servidor.
28.2.4. U n e je m p lo d e s o f tw a r e in te r m e d io
El software de autentificación, el cual com prueba El software intermedio orientado a mensajes es el soft
que un usuario que desee utilizar un sistema distri ware intermedio que administra el flujo de mensajes hacia
buido pueda en efecto hacerlo. y desde un cliente. Esta sección estudia detalladamente
El software interm edioorientado a mensajes que ges este software con el fin de proporcionar un ejemplo de
tiona el envío de mensajes desde clientes'a servido un tipo específico de software intermedio. Para referirse
res y viceversa. al software interm edio orientado a mensajes a m enudo
se utiliza la sigla MOM. Es el que gestiona de forma efi
Clientes caz las colas que contienen mensajes que proceden y que
Clientes
instalaciones se envían desde servidores. La Figura 28.2 m uestra un
Cola de de servidor número de configuraciones. La Figura 28.2 (a) m uestra
Cola de
entrada Servidor entrada un número de clientes que acceden a dos colas, una cola
dh de entrada a la que envían los mensajes y una cola de sali
da desde la que tom an los mensajes y un único servidor
que lee y escribe los mensajes. Un mensaje de entrada
d
típico podría ser el que ordena al servidor que encuentre
Cola de
salida algunos datos en una base de datos y un mensaje de sali
da podría ser los datos que se han extraído de la base de
datos. La Figura 28.2 (b) m uestra múltiples clientes y un
(b)
número de instanciaciones del programa servidor que tra
FIG U R A 2 8 .2 . Configuraciones Mom . bajan concurrentemente en las mismas colas.
Hay que establecer una serie de puntualizaciones a
El software interm edio de servicios es el software cerca de un software M OM :
asociado a un servicio en particular. Entre los ejemplos • No se necesita establecer una conexión especializada
típicos de este tipo de software se incluyen: m ientras que el cliente y el servidor interactúan.
• Un software que permite a bases de datos diferentes . El m odelo de interacción entre clientes y servidores
conectarse a una red clienteiservidor.Probablemente es, en efecto, muy simple: los clientes y servidores
el m ejor ejem plo de este tipo de softw are sea la interactúan m ediante colas. Todo lo que necesita
O DBC (C onectividad abierta de bases de datos) hacer el program ador del cliente y del servidor es
(Open Database Connectivity)) producida por M icro enviar un mensaje a la cola. El software M OM a nivel
soft. Esta permite que existan felizmente en una red de program ador es muy simple.
la vasta m ayoría de sistemas de gestión de bases de . U tilizando el softw are M OM la com unicación es
datos. asíncrona, hasta el punto en que la m itad de la pareja
• Un software específico de objetos distribuidos tal cliente/servidor puede que no esté com unicándose
como el que está asociado a CORBA. CORBA es con la otra parte. Por ejem plo, el cliente puede que
una tecnología de objetos distribuida que permite a no esté ejecutándose: puede detenerse para su m an
objetos escritos en una gran variedad de lenguajes tenim iento y que el servidor siga m andando m ensa
que coexistan felizmente en una red de tal form a que je s a colas MOM. Puede que el cliente haya cerrado
cualquier objeto pueda enviar mensajes a otro objeto. con algunos mensajes a la espera de que l o s procese
El software interm edio de CORBA tiene que ver con el servidor. El servidor puede colocar estos m ensa
funciones tales como configurar objetos distribuidos, je s en la cola de m anera que la próxim a vez que el
com unicación y seguridad entre objetos. cliente se conecte pueda leer los mensajes. Este esce
• Un software interm edio de Web asociado al proto nario es el ideal para la inform ática móvil.
colo HTTP.
www.FreeLibros.org
• Un software interm edio de software de grupo que
adm inistra los archivos que describen a los equipos CLAVE
de trabajo y sus interacciones. Cuando se utiliza el software comunicacion es asincrona.
495
E l p r o p ó s it o d e e s ta s e c c ió n e s e x p lo r a r la id e a d e u n a . ¿ E s r e la t iv a m e n t e e s tá t ic a la b a s e d e d a to s e n lo q u e
a r q u it e c t u r a e s tr a t ific a d a p a r a u n a a p lic a c ió n c lie n te / s e r s e r e f ie r e a p r e d e c ir u n c r e c im ie n t o p e q u e ñ o d e
v i d o r y s e l i m i t a a d e s c r i b i r la s a r q u i t e c t u r a s p o p u l a r e s ta m a ñ o y e s tru c tu ra ?
d e d o s y d e tr e s c a p a s . U n a a r q u it e c t u r a d e d o s c a p a s d e • ¿ E s e s tá t ic a la b a s e d e l u s u a r io ?
u n a a p lic a c ió n c lie n t e / s e r v id o r c o n s is te e n u n a c a p a d e • ¿ E x is t e n r e q u is it o s f i jo s o n o h a y m u c h a s p o s i b i l i
ló g ic a y p r e s e n ta c ió n , y o t r a c a p a d e b a s e s d e d a to s . L a
d a d e s d e c a m b io d u r a n t e la v id a d e l s is t e m a ?
p r im e r a tie n e q u e v e r c o n p r e s e n ta r a l u s u a r io c o n ju n t o s
• ¿ N e c e s ita r á e l s is t e m a u n m a n t e n im ie n t o m í n im o ?
d e o b je t o s v is u a le s y lle v a r a c a b o e l p r o c e s a m ie n t o q u e
r e q u ie r e n lo s d a to s p r o d u c id o s p o r e l u s u a r io y lo s d e v u e l A u n q u e a lg u n a s d e e s ta s c u e s t io n e s v a n e n la z a d a s
to s p o r e l s e r v id o r . P o r e je m p lo , e s ta c a p a c o n te n d r ía e l ( l o s c a m b i o s e n l o s r e q u i s i t o s d a n l u g a r a la s t a r e a s d e
c ó d i g o q u e m o n i t o r i z a la s a c c i o n e s d e p u l s a r b o t o n e s , e l m a n te n im ie n to ) , se tr a ta d e u n c a n tid a d b ie n a m p lia d e
e n v ío d e d a to s a l s e r v id o r , y c u a lq u ie r c á lc u lo lo c a l n e c e p r e g u n ta s q u e d e b e r ía n d e te n e r s e e n c u e n ta a n te s d e
s a r io p a r a la a p lic a c ió n . E s to s d a to s s e p u e d e n a lm a c e a d o p ta r u n a a r q u it e c t u r a d e d o s c a p a s .
n a r e n u n a b a s e d e d a to s c o n v e n c io n a l, e n u n a r c h iv o
s im p le o p u e d e n s e r in c lu s o lo s d a to s q u e e s tá n e n la
m e m o r ia . E s ta c a p a r e s id e e n e l s e r v id o r .
N o r m a l m e n t e la s a r q u i t e c t u r a s d e d o s c a p a s s e u t i
CLAVE
liz a n c u a n d o s e r e q u ie r e m u c h o p r o c e s a m ie n t o d e d a to s . Cuandounaaplicaciónimplicaunprocesamiento
L a a r q u it e c t u r a d e l s e r v id o r W e b d e n a v e g a d o r es u n considerableel enfoquededoscopascadavez
b u e n e je m p lo d e u n a a r q u it e c t u r a d e d o s c a p a s . E l n a v e esmásdifícildeimplementor.
g a d o r d e l c lie n t e r e s id e e n la c a p a d e ló g ic a y p r e s e n
t a c i ó n m i e n t r a s q u e l o s d a t o s d e l s e r v i d o r W e b — la s C u a n d o u n a a p lic a c ió n im p lic a u n p r o c e s a m ie n to c o n
p á g i n a s W e b — r e s i d e n e n la s c a p a d e l a b a s e d e d a t o s . s id e r a b le , e n to n c e s c o m ie n z a n a s u r g ir p r o b le m a s c o n
O t r o e je m p lo d e a p lic a c ió n e n d o n d e se e m p le a r ía n o r la a r q u it e c t u r a d e d o s c a p a s , p a r t ic u la r m e n t e a q u e lla s
m a lm e n t e u n a a r q u it e c t u r a d e d o s c a p a s e s u n a a p lic a a p lic a c io n e s q u e e x p e r im e n ta n c a m b io s d e f u n c io n a li
c ió n s im p le d e e n t r a d a d e d a t o s , d o n d e la s f u n c io n e s d a d a m e d id a q u e s e v a n u t iliz a n d o . T a m b ié n , u n a a r q u i
p r in c ip a le s q u e e je r c it a n lo s u s u a r io s e s in t r o d u c i r lo s te c tu r a d e d o s c a p a s , d o n d e n o h a y m u c h a s p a rte s d e
d a to s d e fo r m a s m u y d iv e r s a s e n u n a b a s e d e d a to s c ó d ig o d e p r o c e s a m ie n t o u n id a s a a c c io n e s ta le s c o m o
r e m o ta ; p o r e je m p lo , u n a a p lic a c ió n d e e n tr a d a d e d a to s p u ls a c ió n d e b o to n e s o in t r o d u c c ió n d e t e x t o e n u n c a m
d e u n s i s t e m a b a n c a r i o , d o n d e la s c u e n t a s d e u s u a r i o s p o d e t e x t o , e s tá a lta m e n t e o r ie n t a d a a s u c e s o s e s p e c íf i
n u e v o s s e te c le a n e n u n a b a s e d e d a to s c e n tr a l d e c u e n c o s y n o a lo s d a to s s u b y a c e n te s d e u n a a p lic a c ió n , y d e
ta s . E l c lie n t e d e e s ta a p lic a c ió n r e s id ir á e n la c a p a l ó g i a q u í q u e la r e u t iliz a c ió n s e a a lg o c o m p lic a d o .
c a y d e p r e s e n ta c ió n m ie n tr a s q u e la b a s e d e d a to s d e
Capa Capa del servidor Capa de bases
c u e n ta s r e s id ir í a e n la c a p a d e b a s e d e d a to s . de presentación de la aplicación de datos
L a s d o s a p lic a c io n e s d e s c r ita s a n t e r io r m e n t e m u e s
t r a n l a c a r a c t e r í s t i c a p r i n c i p a l q u e d i s t i n g u e a la s a p l i
c a c io n e s d e c a p a s d e o tr a s a p lic a c io n e s q u e e m p le a n
m á s c a p a s p o r e l h e c h o d e q u e la c a n tid a d d e p r o c e s a
m ie n t o n e c e s a r io e s m u y p e q u e ñ a . P o r e je m p lo , e n la
a p lic a c ió n d e v a lid a c ió n d e d a to s , e l Ú n ic o p r o c e s a
m ie n t o r e q u e r id o d e l la d o d e l c lie n t e s e r ía la v a lid a c ió n
d e d a to s q u e s e lle v a r í a a c a b o s in r e c u r r ir a la b a s e d e
d a t o s d e la s c u e n t a s . U n e j e m p l o s e r í a c o m p r o b a r q u e
e l n o m b r e d e u n c lie n te n o c o n tie n e n in g ú n d í g it o . E l
r e s to d e la v a lid a c ió n s e h a r ía e n la c a p a d e la b a s e d e Nianta
d a to s y c o n lle v a r ía c o m p r o b a r la b a s e d e d a to s p a r a a s e
g u r a r q u e n o s e a ñ a d ie r o n r e g is t r o s d u p lic a d o s d e c lie n
te s a la b a s e d e d a to s . R e e c e [R E E 9 7 ] h a d o c u m e n ta d o F IG U R A 2 8 .3 . Una arquitectura de tres capas.
lo s c r it e r io s q u e s e d e b e r í a n u t i l i z a r c u a n d o c o n s id e r a
m o s a d o p ta r u n a a r q u it e c t u r a c lie n te s e r v id o r d e d o s L a F ig u r a 2 8 .3 m u e s tr a u n a a r q u it e c t u r a d e tr e s c a p a s .
c a p a s . E s to s s o n lo s c r it e r io s : S e c o m p o n e d e u n a c a p a d e p r e s e n ta c ió n , u n a c a p a d e
p r o c e s a m ie n to ( o c a p a d e s e r v id o r d e s o lic it u d e s ) y u n a
www.FreeLibros.org
. ¿ U t iliz a la a p lic a c ió n u n a ú n ic a b a s e d e d a to s ?
c a p a d e b a s e d e d a to s . L a c a p a d e p r e s e n ta c ió n e s la re s
. ¿ S e lo c a liz a e l p r o c e s a d o r d e b a s e d e d a to s e n u n a p o n s a b l e d e l a p r e s e n t a c i ó n v i s u a l d e l a a p l i c a c i ó n , la
s o la C P U ? c a p a d e l a b a s e d e d a t o s c o n t i e n e l o s d a t o s d e l a a p li-
496
CAPÍTULO 28 IN GE NIE RI A DEL S OF TWARE DEL C O M E R C I O E L E C T R O N I C O CL IE N T E /S E R V I D O R
cacióny la capa de procesam iento es la responsable del tra el servidor de los clientes. La localización de esta
procesamiento que tiene lugar en la aplicación. Por ejem capa no le resta valor a las ventajas que proporciona una
plo, en una aplicación bancaria el código de la capa de arquitectura de tres capas:
presentación se relacionaría simplemente con la m oni • En prim er lugar, la arquitectura de tres capas permite
torización de sucesos y con el envío de datos a la capa aislar a la tecnología que implementa la base de datos,
de procesamiento. Esta capa interm edia contendría los de forma que sea fácil cambiar esta tecnología. Por
objetos que se correspondencon las entidades de la apli ejem plo, una aplicación podría utilizar en prim er
cación; por ejem plo,en una aplicación bancaria los obje lugar la tecnología relacional para la capa de base de
tos típicos serían los bancos, el cliente, las cuentas y las datos; si una base de datos basada en objetos fu n
transacciones. ciona tan eficientem ente com o la tecnología rela
La capa final sería la capa de la base de datos. Ésta cional que se pudiera entonces integrar fácilm ente,
estaría com puesta de los archivos que contienen los todo lo que se necesitaría cam biar serían los m éto
datos de la aplicación. La capa interm edia es la que dos para comunicarse con la base de datos.
conlleva capacidad de m antenim iento y de reutiliza • U tiliza m ucho código lejos del cliente. Los clien
ción. Contendrá objetos definidos por clases reutili tes que contienen m ucho código se conocen com o
zables que se pueden utilizar una y otra vez en otras clientes pesados (gruesos). En un entorno en donde
aplicaciones. Estos objetos se suelen llam ar objetos de se suele n ec esitar algún cam bio, esto s clien tes
negocios y son los que contienen la gam a norm al de p esados pu ed en co n v ertirse en una p esa d illa de
constructores, métodos para establecer y obtener varia m antenim iento. C ada vez que se requiere un cam
bles, m étodos que llevan a cabo cálculos y m étodos, bio la organización tiene que asegurarse de que se
norm alm ente privados, en com unicación con la capa ha descargado el código correcto a cada cliente.
de la base de datos. La capa de presentación enviará Con una capa interm edia una gran parte del código
mensajes a los objetos de esta capa intermedia, la cual de una aplicación cliente/servidor reside en un lugar
o bien responderá entonces directam ente o m antendrá (o en un núm ero reducido pequeño de lugares si se
un diálogo con la capa de la base de datos, la cual pro u tilizan servidores de copias de seguridad) y los
porcionará los datos que se m andarían com o respues cam bios de m antenim iento ocurren de form a cen
ta a la capa de presentación. tralizada.
El lugar donde va a residir la capa interm edia depen
• La idea de las tres capas encaja con las prácticas
de de la decisión sobre el diseño. Podría residir en el
orientadas a objetos de hoy en día: todo el procesa
servidor, que contiene la capa de base de datos; por otro
m iento tiene lugar por medio de los mensajes que se
lado, podría residir en un servidor separado. Éa deci
envían a los objetos y no m ediante trozos de código
sión sobre dónde colocar esta capa dependerá de las
asociados a cada objeto en la capa de presentación
decisiones sobre diseño que se apliquen, dependiendo
que se está ejecutando.
de factores tales como la cantidad de carga que tiene un
servidor en particular y la distancia a la que se encuen
CLAVE
Tipo Código S u m a de | Existe una diferenciaenire el software intermedio
(8 bits) (8 bits) verificación |
(middleware) y la capa del servidor de la aplicación.
P arám etros
I Lo que m erece la pena destacar, llegado este pun
to, es que existe una diferencia entre la capa in ter
Datos
1 m edia del serv id o r de la aplicació n y el softw are
intermedio (middleware). M ientras que el prim ero des
cribe el software de la aplicación que m edia entre el
cliente y el servidor, el segundo se reserva para el soft
FIGURA 28.4. El fo r m a to del p r o t o c o l o IC M P . ware de sistemas.
fcl8.4 PR OT O CO LO S____________________________________________________________
En este capítulo hasta ahora se ha utilizado el térm i 28.4.1. El c o n c e p to
www.FreeLibros.org
no protocolo sin proporcionar realm ente m ucho deta Con objeto de describir lo que es exactamente un pro
lle. El propósito de esta sección es proporcionar este tocolo, utilizaré un pequeño ejemplo: el de un cliente
detalle. que proporciona servicios bancarios para casa, permi-
497
tiendo, por ejemplo, que un cliente consulte una cuen 28.4.2. IP e IC M P

ta cuyos datos residen en el servidor. Supongamos que IP, el protocolo que ejecutaInternet es un protocolomuy
el cliente se comunica con el servidor que utiliza una complicado, y una descripción completa estaría fuera
serie de mensajes que distinguen las funciones requeri del ámbito de este libro, ya que la descripción de este
das por el cliente, y que también se comunica con otros protocolo necesitaría un libro entero que le hicierajus
datos requeridos por el servidor. ticia. Debido a esto me centraré en una parte pequeña
Por ejemplo, el cliente puede ejercer la función de del protocolo, aunque importante, conocida como ICMP
consultar un saldo de cuenta tecleando un número de (In te rn e tC o n tro lM e ssa g e P ro to c o l). Protocolo de men
cuenta en un cuadro de texto y pulsando el botón del sajes de control de Internet que se utiliza para monito-
ratón el cual enviará el mensaje al servidor. Este men rizar los errores y problemas de la red que utiliza IP. En
saje podría ser de la forma la Figura 28.4 se muestra el formato de los mensajes
CS*<Número de cuenta, que forman parte del protocolo.
El campo Tipo especifica el tipo de error que ha ocu
donde C S (Consulta del Saldo) especifica que el usua rrido. Por ejemplo, este campo indicaría que el desti
rio ha consultado una cuenta para obtener el saldo con no de un mensaje era inalcanzable. El campo Código
el número de cuenta que identifica la cuenta. El servi contiene la información secundaria que se utiliza para
dor entonces recibirá este mensaje y devolverá el sal proporcionar una interpretación más detallada del cam
do; el mensaje que el servidor envía podría tener el po Tipo. El campo de Sum a d e ve rific a ció n es utiliza
formato do por el software para comprobar que la transmisión
S * < C a n t i d a d d e l S a ld o >
del mensaje ICMP se ha llevado a cabo correctamen
te. Los dos campos restantes contienen los datos que
El cliente interpretara este mensaje y visualizara el permitirán al software de comprobación localizar el
saldo en algún elemento de salida. problema originado.
Si el cliente quisiera consultar los números de cuen ICPM es utilizado por IP para llevar a cabo el pro
tas de todas las cuentas con las que él o ella está aso cesamiento básico de errores y también para incremen
ciado, el mensaje entonces podría ser de la forma tar la eficacia de la red. Por ejemplo, se podría utilizar
CC* para llevar a cabo el cambio de dirección del mensaje
si una computadora, que se encontrara en el camino ini
donde C C (Consulta de Cuenta) solicita las cuentas, y cial del mensaje, descubriera una ruta mejor.
en cuya función ya no se requieren más datos. El ser
vidor podría responder con un mensaje que comenza
ra con (Información de Cuenta) y que estuviera 28.4.3. PO P3
formado por números terminados con asteriscos. Por POP3 ( Post Office Protocol version 3) (Protocolo de
ejemplo, Oficina de Correos versión 3 ) se utiliza para el envío y
la recepción de correo electrónico. Es un protocolo sen
IC*2238997*88765 " 882234 cillo y es ampliamente utilizado. En esta sección reali
los mensajes que he descrito forman un protocolo sen zaré un estudio de algunas de s u s características.
cillo que comunicafuncionalidady datos entre dos enti
dades (un cliente y un servidor) en la red.
O ¿Qué es un protocolo? P0P3 es un protocolo robusto y muy sencillo.
5
Utilícelo todo lo posible más que otros protocolos
U n punto importante acerca de los protocolos es que Existen varios protocolos de correo, entre los que se
siempre que se utiliza un mecanismo para la comuni incluyen SMTP, IMAP y diferentes versiones de POP.
cación en una red existe un protocolo. Por ejemplo, los Probablemente el más complicado de estos sea IMAP,
objetos distribuidos son objetos que se encuentran en el cual incluye funciones secundarias y un conjunto de
localizaciones remotas en una red, y es mediante la uti mensajes más rico que POP.
lización de un protocolo la manera en que se envían los El propósito de POP es posibilitar a los usuarios
mensajes, aunque la programación de estos objetos esté acceder al correo remoto y consta de una serie de
a un nivel superior por debajo de la programación y comandos que permiten a los programas de usuario
oculta al programador. interactuar con un servidor de correo POP. El están
El protocolo que he descrito se asemeja a unjugue dar POP3 describe un grupo de mensajes posibles que
te y también a un protocolo de aplicaciones. Merece pueden enviarse al servidor de correo POP3 y el for
mato de los mensajes es devuelto por el servidor. L a
www.FreeLibros.org
la pena entrar en el estudio de algunos protocolos más
reales que estén asociados a los servicios de nivel de Tabla 28.1 muestra un subconjunto pequeño del pro
sistema. tocolo POP3.
498
CAPÍTULO 28 I NGENI ERÍ A DEL S O F T WA R E DEL C O M E R C I O E L E C T R Ó N I C O CLI E NT E/ S ER V ID OR
p r o t o c o lo H T T P y s e rá n in te r p r e ta d o s p o r e l s e r v id o r
M ensaje S ig n ifica d o
q u e lle v a r á a c a b o o p e r a c io n e s ta le s c o m o d e v o lv e r u n a
USER I n f o r m a a l s e r v id o r s o b re u n u s u a p á g in a W e b o p r o c e s a r a lg ú n f o r m u la r io q u e e s té in s e r
r i o e n p a r t ic u la r q u e e s tá in t e n t a n t a d o d e n t r o d e u n a p á g in a .
d o e n v ia r u n c o r r e o A c o n tin u a c ió n , se m u e s tr a u n e je m p lo q u e ilu s t r a lo
PASS P r o p o r c io n a u n a c o n tr a s e ñ a p a r a d e s c r ito a n te r io r m e n te
u n u s u a r io e n p a r t ic u la r
GET/index.html HTTP/ 1.1
STAT P r e g u n ta cd s e r v id o r c u á n to s m e n
s a je s h a y e s p e r a n d o p a r a s e r le íd o s E s te e s e l m e n s a je q u e e n v í a u n n a v e g a d o r c u a n d o
D ELE B o r r a u n m e n s a je q u ie r e v is u a liz a r u n a p á g in a e n p a r t ic u la r . E s te m e n s a
RETR R e c u p e r a u n m e n s a je j e se p u e d e h a b e r g e n e ra d o d e d ife r e n te s m a n e ra s . P o r
e je m p lo , e l u s u a r io p u e d e h a b e r p in c h a d o c o n e l r a t ó n
T A B L A 2 8 .1 . U n s u b c o n ju n to d e l P O P 3 e n u n d e t e r m i n a d o e n l a c e e n un d o c u m e n t o W e b q u e
s e ñ a la a la p á g i n a s o l i c i t a d a . L a l í n e a a n t e r i o r c o n t i e n e
la p a la b r a r e s e r v a d a G E T , la c u a l e s p e c if ic a b a q u e s e
ib a a d e v o lv e r u n a r c h iv o , y e s p e c if ic a b a t a m b ié n e l
28.4.4. El p ro to c o lo HTTP n o m b r e d e l a r c h iv o q u e s ig u e a l c a r á c t e r '/ ' ( in d e x . h t m l)
E s te e s u n o d e lo s p r o t o c o lo s m á s im p o r t a n t e s q u e s e y la v e r s ió n d e l p r o t o c o lo q u e u t ili z a e l n a v e g a d o r q u e
u t iliz a n d e n tr o d e I n t e r n e t ; e s e l p r o t o c o lo q u e r ig e v a a e n v i a r e l m e n s a je .
la c o m u n i c a c i ó n e n t r e u n c l i e n t e q u e u t i l i z a u n n a v e E l s e r v id o r ta m b ié n u t iliz a r á e l p r o to c o lo H T T P p a ra
g a d o r W e b ta l c o m o In te r n e t E x p lo r e r y u n s e r v id o r e n v i a r m e n s a je s d e v u e lt a a l c lie n t e . P o r e j e m p lo , e l
W eb. m e n s a je
L a fu n c ió n p r in c ip a l d e u n s e r v id o r W e b e s p o n e r a
HTTP/1.1 200 OK
d is p o s ic ió n d e c lie n t e s p á g in a s W e b . E s to s c lie n t e s u t i
li z a r á n u n n a v e g a d o r q u e le s c o n e c t a r á a l p u e r t o 8 0 e n s ig n if ic a q u e e l s e r v id o r , q u e e s tá u t iliz a n d o H T T P v e r
e l s e r v id o r W e b ; e s te e s e l p u e r to e s tá n d a r q u e s e u t i l i s i ó n 1 .1 , h a p r o c e s a d o c o n é x i t o l a p e t i c i ó n i n i c i a d a p o r
z a p a r a ta le s s e r v id o r e s . E l n a v e g a d o r q u e e s tá u t i l i e l c l i e n t e . E l c ó d i g o 200 e n e s t e c a s o e s u n e j e m p l o d e l
z a n d o e l c lie n t e . e n v ia r á m e n s a je s d e f in id o s p o r e l c ó d ig o d e e s ta d o q u e in d ic a é x ito .
28.5.1. ¿ Q u é e s e l c o m e r c io e le c tró n ic o ? e s e a r t íc u lo . N o r m a lm e n t e la c o m p a ñ í a d e s u b a s ta s
e s p e c if ic a r ía u n p e r ío d o d e o f e r t a p a r a a s í d a r la p o r
P a ra ilu s t r a r la a p a r ie n c ia d e u n s is t e m a d i s t r i b u i d o e x a
fin a liz a d a .
m in a r e m o s u n e j e m p lo t o m a d o d e u n á r e a d e a p lic a c ió n
• S is te m a s q u e p r o p o r c io n a n a lg ú n s e r v ic io b a s a d o e n
c o n o c id a c o m o c o m e r c i o e l e c t r ó n i c o . E n u n s e n t i d o
a m p l io , e l t é r m i n o « c o m e r c i o e l e c t r ó n i c o » ( E c o m m e r - r e d p a r a u s u a r io s . P r o b a b le m e n t e lo s m á s c o n o c id o s
c e ) se p u e d e d e f in ir c o m o la a p lic a c ió n d e la te c n o lo g í a s o n lo s q u e o f r e c e n c u e n ta s d e c o r r e o g r a tis , d o n d e
d e s is t e m a s d i s t r i b u i d o s q u e a p o y a la s o p e r a c i o n e s c o m e r - lo s in g r e s o s d e d i c h a e m p r e s a p r o b a b le m e n t e p r o
c ia le s . A c o n t i n u a c i ó n , s e d e t a l l a n a l g u n o s d e d i c h o s s i s c e d a n d e l a p u b l i c i d a d e n la s p á g i n a s W e b q u e s e u t i
te m a s : l i z a n p a r a e s e s i t i o W e b . E s t a s so n c o m p a ñ í a s q u e
m e d ia n t e u n h o n o r a r io m o n i t o r iz a n s u s it io W e b y le
• S is t e m a s p a r a v e n d e r a l g u n o s a r t í c u l o s o s e r v i c i o s
e n v í a n u n m e n s a je , n o r m a lm e n t e p o r c o r r e o e le c
u t iliz a n d o I n t e r n e t , d o n d e lo s c lie n t e s in t e r a c t ú a n
tr ó n ic o o m e d ia n te u n b u s c a d o r s i h a n d e te c ta d o u n
c o n e l s is t e m a q u e u t i l i z a n a v e g a d o r e s . E n t r e lo s
p r o b le m a , c o m o e l m a l f u n c io n a m ie n t o d e l s e r v id o r
s is t e m a s t í p ic o s d e c o m e r c i o e l e c t r ó n i c o d e e s t a
q u e se u t iliz a p a ra e l s itio W e b .
c a te g o r ía se in c lu y e n lo s q u e v e n d e n li b r o s , r o p a
y C D s. • S is te m a s q u e p r o p o r c io n a n s e r v ic io s d e a s e s o r a -
m i e n t o . Los s i s t e m a s t í p i c o s d e e s t e t i p o s o n l o s q u e
^ ¿Qué es el comercio p r o c e s a n u n a d e s c r ip c ió n d e a r t íc u lo s , c o m o u n C D ,
• electrónico? p a r a lo s q u e e s t a b le c e r á n e l m e jo r p r e c io , d e s p u é s
d e h a b e r e x p l o r a d o u n n ú m e r o d e s is t e m a s d e v e n t a
• S is t e m a s p a r a s i m u l a r a l g u n a a c t i v i d a d c o m e r c i a l e n
e n la r e d .
tie m p o r e a l u t iliz a n d o t e c n o lo g í a d e r e d . U n b u e n
e je m p lo d e e s te t i p o d e s is t e m a s e s u n a s u b a s ta e n la « S is te m a s in t e r n o s q u e e l c lie n t e n o v e , p e r o q u e d a n
www.FreeLibros.org
r e d .U n s is t e m a d e s u b a s ta t í p i c o s o l i c i t a r í a a r t í c u s o p o r te a m á s a c tiv id a d e s c o m e r c ia le s c o n v e n c io n a
lo s a l o s u s u a r i o s d e I n t e r n e t , u b i c a r í a l o s d a t o s e n le s . P o r e j e m p l o , u n s i s t e m a q u e a p o y a e l s u m i n i s t r o
u n a p á g in a W e b y e n t o n c e s c o m e n z a r í a l a o f e r t a p a r a d e m e r c a n c ía s a u n c o m e r c ia n t e m in o r is t a d e la c a lle .
499
« Sistemas de publicidad. M uchos de los ingresos del realiza el pedido de un libro, a continuación se le
comercio electrónico proceden de la publicidad en solicitan los datos de la tarjeta de crédito. Algunos
línea. M uchas páginas Web asociadas a las aplica sistem as de pedidos suelen quedarse con los datos
ciones de com ercio electrónico contendrán peque de las tarjetas de form a permanente de m anera que
ños espacios publicitarios conocidos com o b a n n e r s . no se requiere que el cliente proporcione los datos
Estos anuncios se pueden «pinchar», conduciendo cada vez que haga un pedido.
así al usuario del navegador a un sitio Web el cual • Estos ser
L a p r o v i s ió n d e s e r v ic io s d e s e g u im ie n to .
norm alm ente vende algún producto o servicio. Los vicios posibilitarán al cliente seguir con el proceso
sistemas de publicidad son una form a particular de de una com pra utilizando su navegador. Las páginas
sistemas de comercio electrónico que llevan a cabo W eb personalizadas para el cliente describirán el
funciones tales com o vender un b a n n e r (espacio desarrollo de un pedido: si ya se ha enviado, si está
publicitario), m onitorizando el éxito de estos anun esperando porque el libro no está en stock, y cuál es
cios y la adm inistración del pago de los honorarios la fecha en la que se espera enviar el pedido.
de publicidad.
• Un servicio ofrecido
E l p r o c e s a m ie n t o d e r e v is io n e s .
E stas form an un conjunto típico de aplicaciones por los sitios de ventas de libros más sofisticados y
que están bajo el «banner» del com ercio electrónico. es el que proporciona el medio por el que los clien
En la parte restante de esta sección observarem os una tes pueden escribir revisiones de los libros a com
aplicación típica de com ercio electrónico que adm i prar. Estas revisiones se pueden com unicar al
nistra la venta de un artículo. Esto es lo que piensa vendedor o bien por correo electrónico o por una
cu a lq u ie r p e rso n a de una a p lic a c ió n de co m ercio página Web especializada.
electrónico, aunque espero que después de leer este
• Un ser
L a p r o v is ió n d e u n s e r v ic io d e c o n fe r e n c ia .
preám bulo este sistem a se considerará sólo com o un
vicio de conferencia capacita a un grupo de clientes
tipo de sistema.
para interactuar entre ellos enviando mensajes a una
conferencia, entendiendo por conferencia algo dedi
cado a un tem a específico tal como, por ejemplo, la
CLAVE últim a novela de Robert Goddard o el estado de la
El comercio electrónico no es solamente ficción crim inal. Tales servicios no proporcionan
un comercio minorista de red. ingresos directamente a un vendedor de libros en red.
Sin em bargo, sí pueden proporcionar información
28.5.2. U n s is te m a típ ic o d e c o m e rc io e le c tró n ic o Útil sobre las tendencias en las compras de libros de
las que el personal de ventas de una librería pueden
Con objeto de entender la naturaleza de los sistem as sacar provecho.
cliente/servidor, merece la pena exam inar un ejem plo • L a p r o v is ió n d e n o t i c i a s o b o l e t i n e s p a r a c l ie n t e s .
de una de las áreas del comercio electrónico. Es un sis Un servicio popular que se encuentra en muchos
tem a para adm inistrar las ventas de una gran librería sitios de comercio electrónico dedicados a la venta
que tenga una funcionalidad sim ilar a la que exhiben de un producto es el de proporcionar información
grandes librerías como Blackwells o la filial británica por m edio del correo electrónico. Para el sitio de ven
de Amazon. Las funciones típicas que un sistema como tas de libros que se está describiendo en esta sección
éste proporciona son las siguientes: se incluirían mensajes tal como textos de revisiones,
• Cada libro
L a p r o v is ió n d e s e r v ic io s d e C a t á lo g o . ofertas especiales o m ensajes relacionados con un
que venda una com pañía estará en catálogo y la pedido específico, tal como el hecho de haberse des
página Web proporcionará la descripción de ese libro. pachado.
La inform ación típica que se proporciona sobre un • C o n t r o l y a d m i n i s t r a c i ó n d e l s t o c k . Este es un con
libro es el nombre, autor, editorial y precio. ju n to de funciones que están ocultas para el usuario
• El usuario de
L a p r o v is ió n d e s e r v ic io s d e b ú s q u e d a . del sistema de ventas de libros pero que son vitales
dicho sistema necesitará navegar por el catálogo para para el sistema. Estas funciones se asocian a las acti
decidir si va a com prar un libro. Esta navegación se vidades m undanas, tales com o hacer pedidos de
podría realizar de muchas m aneras diferentes: desde libros, hacer el seguimiento de los stocks y reorde-
navegar secuencialmente desde el prim er libro que nar y proporcionar inform ación de ventas al perso
aparece, hasta navegar utilizando consultas de bús nal responsable de los pedidos.
queda tal com o el título de un libro o su ISBN. • I n f o r m e s f i n a n c i e r o s . Estos son de nuevo un con
• L a p r o v is ió n C uando un
d e s e r v ic io s d e p e d id o s . junto de funciones que están ocultas ante los ojos del
cliente de un sitio de com ercio electrónico quiere usuario del sistema de ventas de libros pero que son
www.FreeLibros.org
com prar un libro, el sistema le proporcionará algún vitales. Proporcionan la inform ación para la gestión
servicio para poderlo hacer y, normalmente, mediante financiera de la com pañía que ejecuta el sistema y
tarjetas de crédito. Generalm ente cuando el cliente proporciona la inform ación de datos tales como la s
500
CAPÍTULO 28 I NGENI ERÍ A DEL S OF TWARE DEL C O M E R C I O E L E C T R Ó N I C O CLI E NT E/ S ERVI DOR
v e n t a s d í a a d í a , a n u a le s y d a to s m á s c o m p le j o s t a le s
c o m o la e f e c t iv id a d d e c ie r ta s e s tr a t e g ia s d e v e n ta s
r e s p e c t o a la s v e n t a s d e l o s l i b r o s q u e e r a n e l t e m a S e r v id o r e s
d e e s ta s e s tr a te g ia s .
□
d e s e g u rid a d
S e p u e d e d e c ir q u e e s ta s s o n u n c o n ju n t o t í p ic o d e
fu n c io n e s m o s tra d a s p o r e l c o m e r c io e le c tr ó n ic o d e d i
c a d o a v e n d e r p ro d u c to s ; e n n u e s tro c a s o e l p r o d u c
to s o n lib r o s , a u n q u e n o h a y n in g u n a r a z ó n p a r a n o
□
h a b e r e le g id o , p o r e j e m p lo , r o p a , C D s , a n t ig ü e d a d e s ,
e t c . , a u n q u e la s f u n c i o n e s d e l s is t e m a v a r ia r í a n u n
p o c o ; p o r e je m p lo , e n u n s it io e s p e c ia liz a d o e n v e n
d e r r o p a n o h a b r í a r a z ó n p o r la q u e im p le m e n t a r la s
□
f u n c io n e s q u e e s tá n c o n e c t a d a s c o n la s r e v is io n e s d e
p ro d u c to s . S e r v id o r
A n t e s d e e s t u d ia r la a r q u it e c t u r a d e d ic h o s is t e m a d e c o n fe r e n c ia
m e r e c e la p e n a h a c e r h in c a p i é e n e l d e s a r r o llo d e t a le s
s is t e m a s . D u r a n t e e l n i v e l d e a n á l i s i s h a y p o c a d i f e r e n
c ia e n tr e e l s is t e m a d e c o m e r c io e le c t r ó n ic o y u n s is t e
m a m á s c o n v e n c io n a l, t a l c o m o e l q u e d e p e n d e d e lo s
o p e r a d o r e s t e le f ó n ic o s p a r a a n o ta r lo s p e d id o s y d o n d e
F IG U R A 2 8 .5 . La arquitectura.
e l c a tá lo g o s e im p r im e y s e e n v í a a lo s c lie n t e s d e la
f o r m a c o n v e n c io n a l. C ie r t a m e n t e e x is t ir á n fu n c io n e s
q u e n o e s ta r á n d e n t r o d e t a le s s is t e m a s c o n v e n c io n a le s , • Un servidor de correo. E s t e s e r v i d o r m a n t e n d r á l i s
c o m o p o r e j e m p l o l o s q u e t i e n e n q u e v e r c o n la s r e v i ta s d e c o r r e o s d e c lie n te s q u e , p o r e je m p lo , h a n i n d i
s io n e s ; s i n e m b a r g o , l a m a y o r p a r t e d e la s f u n c i o n e s s o n c a d o q u e d e s e a n e s ta r p u n tu a lm e n te in f o r m a d o s d e
m u y s im ila r e s , y e s p o s ib le q u e s e lle v e n a c a b o d e f o r la s o f e r t a s e s p e c i a l e s y l o s l i b r o s n u e v o s q u e s e e s t á n
m a d if e r e n t e ; p o r e je m p lo , e l p r o c e s o d e o b t e n e r lo s p u b lic a n d o . E s te s e r v id o r s e c o m u n ic a r á c o n e l s e r
d a t o s d e la s t a r j e t a s d e c r é d i t o s e r í a l l e v a d o a c a b o p o r v id o r W e b p r in c ip a l, y a q u e lo s c lie n t e s p r o p o r c io
u n o p e r a d o r y n o p o r u n a p á g in a W e b . n a r á n s u s d ir e c c io n e s d e c o r r e o y lo s s e r v ic io s q u e
q u i e r e n , i n t e r a c t u a n d o c o n la s p á g i n a s W e b q u e v i s i
ta n . E s t o il u s t r a u n t e m a im p o r t a n t e a c e r c a d e lo s
c lie n t e s y lo s s e r v id o r e s : n o h a y u n a d e s ig n a c ió n
CLAVE fu e r te o r á p id a d e lo q u e e s u n c lie n te o u n s e r v id o r
En el n iv e l de análisis h a y m u y poca d ife re n c ia e n tre los d e u n s is t e m a d e c o m e r c io e le c t r ó n ic o : e s to d e p e n d e
s is te m as d e com ercio electró nico y IOS c onvencio nales. r e a l m e n t e d e l a r e l a c i ó n e n t r e la s e n t i d a d e s i m p l i c a
d a s . P o r e je m p lo , e l s e r v id o r W e b a c tú a c o m o u n s e r
E n la F ig u r a 2 8 .5 s e m u e s tr a la a r q u it e c t u r a té c n ic a v id o r p a r a lo s c lie n t e s q u e e je c u ta n u n n a v e g a d o r ,
d e u n s is t e m a d e li b r o s t í p ic o . L o s c o m p o n e n t e s d e e s te p e r o a c tú a c o m o u n c lie n te c o n e l s e r v id o r d e c o r r e o
s is t e m a s o n : a l c u a l le p r o p o r c io n a d ir e c c io n e s d e c o r r e o p a r a s u s
• Clientes Web. E s t o s e j e c u t a r á n u n n a v e g a d o r q u e lis ta s d e c o r r e o .
in t e r a c t ú a c o n e l s is t e m a y q u e p r i n c ip a lm e n t e ll e v a • Unservidor de conferencia. E s t e e s u n s e r v i d o r q u e
a c a b o fu n c io n e s d e n a v e g a r s o b re c a tá lo g o s y h a c e r a d m i n i s t r a c o n f e r e n c i a s . L e e e n la s c o n t r i b u c i o n e s
p e d id o s . a la c o n f e r e n c ia , v is u a liz a e s ta s c o n t r ib u c io n e s e n
• Un servidor Web. E s t e s e r v i d o r c o n t e n d r á t o d a s la s u n a v e n t a n a a s o c ia d a a u n a c o n f e r e n c ia y b o r r a c u a l
p á g i n a s W e b a la s q u e el c l i e n t e i r á a c c e d i e n d o y s e q u ie r e n t id a d q u e n o e s té a c tu a liz a d a .
c o m u n ic a r á c o n e l r e s t o d e l s is t e m a p a r a p r o p o r c io • Servidores de bases de datos. S o n s e r v i d o r e s q u e
n a r in f o r m a c ió n t a l c o m o la d is p o n ib ilid a d d e u n a d m i n i s t r a n la s b a s e s d e d a t o s a s o c i a d a s a l a a p l i
lib r o . N o r m a lm e n t e e x is t ir á m á s d e u n s e r v id o r W e b c a c ió n d e c o m e r c io . A q u í s e in c lu y e la b a s e d e d a to s
d is p o n ib le p a r a e n fr e n ta r s e c o n u n f a llo d e l h a r d p r in c ip a l d e lib r o s , la c u a l c o n tie n e d a to s d e c a d a
w a re . S i e l s e r v id o r W e b e s ta b a fu n c io n a n d o y se li b r o ; la b a s e d e d a to s d e p e d id o s q u e c o n tie n e d a to s
v i e n e a b a jo , d i c h o s u c e s o s e r í a e x t r e m a d a m e n t e s e n o d e lo s p e d id o s q u e h a n r e a liz a d o lo s c lie n t e s , to d o s
y s e c o r r e s p o n d e r í a c o n la s p u e r t a s d e u n a l i b r e r í a lo s q u e n o s e h a n c u m p lid o t a n t o a n te r io r e s c o m o
c o n v e n c io n a l c e r r a d a a lo s c lie n t e s im p id ie n d o s u a c t u a le s ; la b a s e d e d a to s d e c lie n t e s q u e c o n t ie n e
e n t r a d a . D e b i d o a la s c a ja s r e g i s t r a d o r a s , l o s s i s t e d a to s d e lo s c lie n te s d e lo s v e n d e d o r e s d e lib r o s ; y
www.FreeLibros.org
m a s d e c o r r e o e le c tr ó n ic o q u e tie n d e n a s e r m u y c r í u n a b a s e d e d a to s q u e c o n t ie n e d a to s d e la s v e n t a s
tic o s p a r a u n n e g o c io te n d r á n h a r d w a r e r e p r o d u c id o , d e lib r o s c o n c r e to s ; e s ta b a s e d e d a to s e s p a r tic u
in c lu y e n d o r e p r o d u c c io n e s d e s e r v id o r e s d e W e b . la r m e n t e ú t i l p a r a m u c h o s v e n d e d o r e s d e lib r o s e n
501
INGE NIE RÍA DEL SOF TW ARE . UN EN F O Q U E P R A C T I C O
la red, puesto que les permite publicar las listas de dor Web frontal que se comunica con un sistema ser
los libros m ás vendidos ju n to con las ofertas espe vidor no cliente. Este sistema servidor no cliente es
ciales de esos libros. En m uchos sistemas de com er el que lleva existiendo ya desde hace algún tiempo
cio electrónico estas bases de datos son im ple- y se utilizaba para un procesam iento m ás conven
m entadas en varios servidores de bases de datos cional com o es el de tom ar pedidos por teléfono.
especializados que son duplicados: tales bases de Los servidores de bases de datos se m antendrán
datos son vitales para el funcionam iento de una com actualizados por m edio de un software de sistemas
pañía de comercio electrónico: si el servidor de bases que detecta cuando se va a aplicar una transacción
de datos funcionaba m al y no existen servidores a una base de datos: prim ero aplica la transacción a
duplicados, ocurría algo muy serio, ya que no ten la base de datos que se está utilizando en ese
drían ingresos y los vendedores en red obtendrían m om ento y, a continuación, la aplica a todas las
una reputación muy pobre. Un punto im portante a bases de datos duplicadas.
tener en cuenta sobre esta parte del sistema es que • Un servidor de monitorización. Este es el servidor
no hay razón para que una tecnología anterior, tal que se utiliza para m onitorizar la ejecución del sis
como un mainframe que ejecuta una m onitorización tema. Es utilizado por un adm inistrador del sistema
de transacciones se pueda utilizar para funciones de para com probar el funcionam iento correcto del sis
bases de datos; en realidad m uchos de los sistemas tema y también para ajustar el sistema de manera que
de com ercio electrónico se com ponen de un servi se archive un rendim iento óptimo.
uv OSABAS EfiJLfi .El»

Existen varias tecnologías basadas en red que se utili te de com unicar datos en un sistema distribuido que eje
zan para las aplicacionesde comercio electrónico. Antes cuta el protocolo TCP/IP.
de describirlas m erece la pena decir que muchas tecno
logías antiguas todavía se utilizan para este tipo de apli 28.6.2. O b jeto s d istrib u id o s
cación; el m ejor ejemplo es el uso de la tecnología de
¿Qué es un objeto
§
bases de datos relaciónales para proporcionar alm ace
nes de datos a gran escala. distribuido?
Un objeto distribuido es aquel que reside en una com

putadora, norm alm ente un servidor, en un sistema dis
tribuido. Otras com putadoras del sistema pueden enviar
m ensajes a este objeto com o si residiera en su propia
Muchas tecnologías antiguas todavía se utilizan
para aplicacionesde comercio electrónico.
computadora. El software del sistema se hará cargo de
varias funciones: localizar el objeto, recoger los datos
que se requieren para el mensaje y enviarlos a través
28.6.1. C o n e x io n e s (s o c k e ts ) del medio de com unicación que se utiliza para el siste
ma. Los objetos distribuidos representan un nivel más
Un socket es un tipo de conducto que se utiliza para
alto de abstracción que las conexiones (sockets).apar
conectarse a una com putadora conectada a una red y
te de algún código de inicialización, el program ador no
basada en TCP/IP. El socket se configura de tal m anera
es consciente del hecho de que el objeto reside en otra
que los datos pueden ser bajados desde el cliente y
computadora. Actualm ente existen tres tecnologías de
devueltos al m ismo. Los lenguajes de program ación
objetos distribuidos en pugna:
modernos, com o Java, proporcionan servicios de alta
calidad por m edio de los cuales un socket se puede • RM I. Esta es la tecnología asociada al lenguaje de
conectar mediante «programación» a una com putado program ación de Java. Es un enfoque Java puro en
ra cuya dirección de Internet sea conocida y donde los el que solo los program as escritos en ese lenguaje se
datos se puedan enviar por este conducto. La progra pueden com unicar con un objeto RM I distribuido.
mación necesaria para esto normalmente no es más com Es la tecnología ideal para sistemas cerrados de Java;
plicada que la programación que se requiere para escribir estos sistemas generalmente tendrán pocas conexio
y leer datos de un archivo. Los sockets son una imple- nes o ninguna con otros sistemas.
m entación a bajo nivel de la conectividad; dentro de las • DCOM. Esta es una tecnología desarrollada por la
utilizaciones típicas de un socket están las aplicaciones compañía M icrosoft y permite que program as escri
de conferencia, donde una entrada a una conferencia se tos en lenguajes tales com o Visual Basic y Visual
www.FreeLibros.org
enviaría al servidor de conferencia que utiliza una con J++ (la variedad de Java desarrollada por Microsoft)
figuración de sockets en el servidor. Los sockets son un se comuniquen con los objetos que están en compu
mecanismo de bajo nivel, pero una forma muy eficien tadoras remotas.
502
CAPÍTULO 28 I NGENI ERI A DEL S OF TWARE DEL C O M E R C I O E L E C T R Ó N I C O CLIE NT E/SE RV ID OR
. CORBA. Esta es la tecnología de objetos distribui el formulario, y lleva a cabo la funcionalidad asociada
dos m ás sofisticada. Fue desarrollada por un co n al formulario; por ejemplo, recuperando los datos soli
sorcio de com pañías inform áticas, clientes y citados en el formulario. La program ación CGI se pue
compañías de software. La característica más im por de llevar a cabo en varios lenguajes de programación,
tante del enfoque CORBA es que es m ultilenguaje, aunque el lenguaje seleccionado ha sido Perl, lenguaje
donde los program adores pueden utilizar diferentes de procesam iento de cadenas, existen otros entre los que
lenguajes de program ación para enviar m ensajes a se incluyen, por ejemplo, Java y C++, que contienen los
objetos CORBA: las interfaces CORBA existen para servicios para el procesam iento CGI. Recientemente los
lenguajes tales como Java, FORTRAN, LISP, Ada y que desarrollan Java han proporcionado a los progra
Smalltalk. CORBA está al principio de su desarro m adores el servicio de utilizar Java para este tipo de
llo, sin embargo, amenaza con convertirse en la tec program ación que utiliza la tecnología conocida com o
nología dominante para objetos distribuidos. sewlets. Estos trozos pequeños de código Java son inser
La principal ventaja de los objetos distribuidos sobre tados en un servidor de Web y se ejecutan cuando ocu
la de los sockets es el hecho de que como abarca ente rre un suceso, com o enviar un formulario. Los servlets
ramente el paradigm a de orientación a objetos se pue ofrecen un alto grado de portabilidad sobre otros len
de em plear los mismos métodos de análisis y diseño que guajes de programación.
se utilizan para la tecnología de objetos convencional.
28.6.5. Contenido ejecutable
28.6.3. Espacios Este es el término que se aplica a la inclusión en una pági
Esta es una tecnología que se encuentra en un nivel de na Web de un program a que se ejecuta cuando la página
abstracción incluso más alto que los objetos distribui es recuperada por un navegador. Este program a puede
dos. Fue desarrollada por David Gelemter, un profesor llevar a cabo un núm ero diverso de funciones entre las
de la Universidad de Yale. La tecnología de espacios que se incluyen la animación y la presentación de un for
concibe un sistema distribuido en base a un gran alm a m ulario al usuario para insertar datos. Existen varias tec
cén de datos persistentes donde las com putadoras de un nologías que proporcionan servicios para insertar
sistema distribuido puede leer o escribir. No concibe el contenido ejecutable en una página Web. Aquí se inclu
sistema distribuido com o una serie de program as que yen applets, Active X y Javascript. Un applet es un pro
pasan m ensajes a los dem ás utilizando un mecanismo grama escrito en Java que interactúa con una página Web.
como los sockets, o com o una serie de objetos distri Lo im portante a señalar de esta tecnología es que es por
buidos que se com unican utilizando m étodos. Por el tátil: el código Java se puede m over fácilmente desde un
contrario, la tecnología de espacios conlleva procesos sistema operativo a otro, pero es potencialmente insegu
como escribir, leer o copiar datos a partir de un alm a ro. La razón de por qué los applets son inseguros es que
cén persistente. Un program ador que utiliza esta tecno se pueden utilizar como m edio de transm isión de virus y
logía no se preocupa por detalles com o dónde están otros m ecanismos de acceso a una computadora. Cuan
almacenados los datos, qué proceso va a recoger los do una página de navegador que contiene un applet es
datos y cuándo los va a recoger. descargadapor un navegador, es lo m ismo que cargar un
Esta tecnología se encuentra sólo al principio, aun program a en la com putadora cliente que ejecuta el nave
que las im plementaciones llevan ya disponibles duran gador. Afortunadam ente los diseñadores de Java desa
te algún tiem po para lenguajes com o C y C++; sin rrollaron el lenguaje de tal m anera que es inmensamente
embargo, la im plementación de la tecnología dentro de difícil escribir applets que provoquen violaciones en la
Java como Javaspaces debería asegurar que cada vez se seguridad. Desafortunadam entela solución que se adop
utilizará más para las aplicaciones principales. tó evita acceder a los recursos de una com putadora clien
te o ejecutar otro program a en la computadora. Aunque
se han hecho muchas mejoras en los applets que perm i
28.6.4. CGI
ten un acceso limitado, el m odelo principal del uso de
applets está restringido a este modo de ejecución.
^ ¿Para qué se utiliza CGI? Active X es otra tecnología de contenido ejecutable
que fue desarrollada por M icrosoft. De nuevo se trata
El térm ino CGI (Common Gateway Interface) signifi de un código de program a insertado en una página Web;
ca Interfaz com ún de pasarela. Es la interfaz con el ser la diferencia principal entre esta tecnología y los applets
vidor W eb al cual se puede acceder m ediante los es el hecho de que estos trozos de código se pueden
programas que se ejecutan en el servidor. Gran parte de escribir en diferentes lenguajes com o Visual B asic y
la interactividad asociada a las páginas Web se imple- C++. Esta forma de contenido ejecutable tam bién sufre
menta program ando el acceso a la CGI. Por ejem plo, de posibles problem as de seguridad.
www.FreeLibros.org
cuando el usuario de un navegador accede a una pági Javascript es un lenguaje de program ación interpre
na que contiene un formulario, éste lo rellena y lo envía tado y sencillo que se inserta directamente en una pági
al servidor Web, program a que accede al CGI, procesa na Web. Se diferencia de las soluciones de Active X y
503
applets en que el código fuente de cualquier program a • Paquetes de seguridad. Estos son paquetes que moni-
de guiones de Java se integra en una página Web en vez torizan el tráfico dentro de un sistema distribuido y
de en el código de objetos como ocurre con los applets avisan al adm inistrador de sistemas de la aparición
y Active X. Javascript es un lenguaje sencillo que se de cualquier violación posible en la seguridad. Por
utiliza para una programación relativamente a bajo nivel. ejemplo, el hecho de que alguien intente entrar en un
sistema con una contraseña sin reconocer.
28.6.6. P a q u e te s c lien te /se rv id o r
• M onitores de transacciones. Estos son paquetes de
Este térm ino describe las colecciones de software que
software que administran las transacciones que tie
norm alm ente llevan a cabo algún tipo de procesam ien
nen lugar dentro de un sistem a distribuido y ase
to de sistemas. A continuación, se m uestra un grupo de guran que se devuelvan los datos correctos com o
ejemplos típicos de paquetes de software:
resultado de una transacción y en el orden correcto.
• Paquetes de reproducción de datos. Este tipo de soft M uchas de las funciones de estos m onitores tienen
ware realiza una transacción en la base de datos y la que ver con asegurar que los resultados correctos
aplica a un núm ero de bases de datos reproducidas, se d ev uelvan incluso en el entorno en donde
evitando así acceder a estas bases de datos hasta que podrían aparecer errores de hardw are o de tran s
estén todas en sincronización. misión.
Antes de observar algunos de los principios del diseño rápidos (y caros). El proceso de asignar tales m edios
que se utilizan en el desarrollo de sistemas distribuidos, norm alm ente tiene lugar después de haber tom ado deci
particularm ente de sistemas de com ercio electrónico, siones sobre la potencia de procesam iento de distribu
m erece la pena reiterar lo que se ha señalado anterior ción en un sistema y, algunas veces, conlleva unas ligeras
mente: a nivel de análisis hay poca diferencia entre un iteraciones al final de la fase de diseño.
sistema distribuido y un sistema local, y se basa en que
el m odelo de análisis de un sistema no contendrá nin 28.7.2. M antenimiento de los datos m ás usados
gún dato de diseño com o el hecho de que tres com pu en un alm acenam iento rápido
tadoras, y no una solo, están llevando a cabo algún
Este principio tam bién es obvio. Requiere que el dise
procesamiento. Esto significa que el desarrollador de
ñador exam ine los patrones de datos en un sistema y
un sistema distribuido se enfrentará norm alm ente con
asegure que los datos a los que se accede frecuentemente
un m odelo de objetos o un m odelo funcional sim ilar al
se guarden en algún m edio de almacenamiento rápido.
que se m ostró en las primeras partes de este libro; esta
En m uchos sistem as tales datos pueden constituir no
descripción irá acompañada de algunos de los tipos de
más del 5 por 100 de los datos originales almacenados
com putadoras y de hardware de redes que se van a uti
en el sistema, y de esta m anera permite utilizar con fre
lizar. El proceso de diseño implica transform ar el m ode
cuencia las estrategias que conllevan el alm acenam ien
lo de análisis en algún m odelo físico que se im plementa
to de estos datos dentro de la mem oria principal.
en los elementos de hardware del sistema.
28.7.3. M antenimiento de los datos cerca

de donde s e utilizan
CLAVE Este principio de diseño intenta reducir el tiem po que
Recuerde que durante el análisis existe poca diferencia pasan los datos en medios lentos de transmisión. Muchos
entre una aplicación de comercio electrónico
de estos sistemas son en donde los usuarios acceden con
y una convencional.
frecuencia a un subconjunto de datos. Por ejemplo, u n
sistem a distribuido usado en una aplicación bancaria
Es necesario que el diseñador de sistemas distribui contendría bases de datos con datos de las cuentas de los
dos conozca una serie de principios de diseño. El resto clientes, en donde la m ayor parte de las consultas a la s
de esta sección m uestra un esquema de los mismos. bases de datos de las sucursales las realizarán los clien
tes de esa sucursal; entonces, si los datos de un sistema
bancario se distribuyen a los servidores de las sucursa
28.7.1. C orrespondencia del volum en de trans
les, y los datos asociados a los clientes de esa sucursal
misión con los m edios de transm isión están en esa sucursal, el resto de los datos podrían estar
www.FreeLibros.org
Este es uno de los principios m ás obvios. Esto signifi en otros servidores con otras ubicaciones, y cualquier
ca que para un tráfico denso de datos en un sistema dis consulta que se originara sobre los datos se tendría que
tribuido se deberían utilizar m edios de transm isión com unicar a través de líneas lentas de transmisión.
504
CAPITULO 28 I NGENI ERÍ A DEL S O F T W A R E DEL C O M E R C I O E L E C T R Ó N I C O CLI ENTE/ SERVI DOR
2 8 .7 .4 . U t i l i z a c i ó n d e l a d u p l i c a c i ó n d e d a t o s tenga que utilizar la duplicación de datos, lo que signifi

to d o lo p o s ib le ca es que se necesita un diseñocuidadoso paraminimizar
La duplicación consiste en mantener múltiples copias la cantidadde gastos asociados a él en las transmisiones.
de datos enun sistema al mismo tiempo. Existen muchas Hay que señalar que en los sistemas distribuidosdon-
razones para la duplicación de datos. La primera es que de existe menos relación dinámica entre los datos, se
hay que asegurarla redundancia que permite que un sis pueden emplear estrategias más simples que eliminen
tema distribuido continúe funcionando aun cuando una muchos de los gastos. Por ejemplo, un banco normal
computadoracon datos importantes quede fuera de ser mente lleva a cabo transacciones una vez al día en las
vicio normalmente por un mal funcionamientodel hard bases de datos de los clientes y normalmente después
ware. La otra razón es que proporciona una forma de del cierre del negocio. Esto significa que un sistemaban-
implementarel principio dilucidado en la sección ante cario distribuido puede duplicar datos en sus sucursa
rior: el de asegurar que los datos estén ubicados cerca les y solamente puede volver a copiar los datos
de donde se utilizan. Por ejemplo, una compañía hote cambiadosen las bases de datos una vez al día: no habría
lera con una base central de reservas que hace el segui necesidad de coordinar las bases de datos con frecuen
miento de todas las reservas de las habitaciones para cia durante el día de trabajo.
todos sus hoteles. Es posible que esta compañía tenga Habría que señalar también que esta subsección ha
dos puntos de contacto para clientes que deseen hacer tratado la duplicación de datos en función de mantener
las reservas: los hoteles en sí y una oficina central de los datos cerca de los usuarios para reducir el tiempo de
reservas. Una forma de asegurar el alto rendimiento es transmisión con medios lentos. Hay otras razones para
duplicando los datos asociados a un hotel en particular duplicar los datos, por ejemplo una base de datos que
y guardar los datos en el servidor ubicado en el hotel. se utiliza mucho tendrá colas de transacciones prepara
Esto significa que cualquierreserva realizada por el hotel das y esperandoa ejecutarse. Estas colas se pueden redu
solo necesitará acceder a una base de datos local y no cir disfrutando de bases de datos idénticas mantenidas
requeriráningún tráfico en la línea lenta de transmisión. en otros servidores de bases de datos concurrentes.
Esto suena a un principio muy simple de implementa
ción sencilla. Desafortunadamente, las cosas nunca son 2 8 .7 .5 . E l i m i n a r c u e l l o s d e b o t e l l a
tan simples. En el ejemplo de las reservas de hoteles no En un sistema distribuido un servidor se convierte con
hay necesidad de que las bases de datos asociadas a los frecuencia en un cuello de botella: tiene que manipular
hoteles se comuniquen con la base de datos central. La tanto tráfico que se construyen grandes colas de transac
razón que apoya esto es el hecho de que también habrá ciones esperandoa ejecutarse, con el resultadode que los
clientes que utilicen la oficina central de reservas, así servidores que estánesperando los resultados del proce
como clientes realizando reservas de habitaciones que samiento estarán, en el mejor de los casos, ligeramente
ofrecen los mismos hoteles. A menos que haya coordi cargados y, en el peor, inactivos. La estrategia normal
nación entre la base de datos de la oficina central de para manipular cuellos de botella es compartir la carga
reservas y las bases de datos individuales duplicadas de de procesamientoentre los servidores, normalmente ser
cada hotel, surgirán problemas: por ejemplo, el hecho vidores físicamente cerca del que está sobrecargado.
de decir que hay una habitación libre en un momento
concretoen un hotel a un cliente que utiliza el servicio 2 8 .7 . 6 . M i n i m i z a r l a n e c e s i d a d d e u n g r a n
central de reservas aun cuando esa habitación ya ha sido c o n o c im ie n to d e l s is te m a
reservada por otro cliente que ha llamado directamen
te al hotel. Los sistemasdistribuidos suelennecesitarconocerel esta
do del sistema completo, por ejemplo, podría ser que
necesitaran conocer la cantidad de registros de una base
de datos central. El hecho de necesitar este conocimien
C LA VE to genera más tráfico reduciendo así la eficiencia de un
la duplicación controlada de datos puede tener un efecto sistema, ya que generará tráfico extra a lo largo de las
Importante en el rendimiento de un sistema distribuido. líneas de transmisión. El diseñador de un sistema distri
buido en primer lugar necesita minimizar que el sistema
dependa de datos globales, y entonces asegurar que el
El problema anterior implica que en un sistema don conocimiento necesario se comunique rápidamente a
dehay unarelacióndinámicaentre las bases de datos indi aquellos componentes del sistema que lo requieran.
viduales existe la necesidadentonces de que cada base de
datos mantenga informadas de los cambios a otras bases
de datos, y de que aseguren que los cambios se reflejen 2 8 .7 . 7 . A g r u p a r d a t o s a f i n e s e n l a m i s m a
entodos los datos duplicados. Esto también implica la u b ic a c ió n
www.FreeLibros.org
apariciónde retrasos porque las transacciones permane Los datos que están relacionados deberían de estar den
ceránen cola esperando a que la base de datos se sincro tro del mismo servidor. Por ejemplo, en una aplicación
nice con otras bases de datos. Esto no significa que se de reservas en un sistema de vacaciones, los paquetes
505
individuales de vacaciones deberían de estar cerca de buido y otro componente. El único gasto que se requie
los datos que describen las reservas actuales de ese re para utilizar esta técnica es tiempo del procesador y
paquete. Ubicar por separado los datos en diferentes ser la memoria necesaria para llevar a cabo la compresión
vidores asegura que los medios de baja transmisión y en la computadora del emisor y la descompresión en la
muy cargados se cargarán incluso más. El diseñador de computadora del receptor.
un sistema distribuido debe asegurarse de que los datos
relacionados gracias al hecho de que se suelen recupe- 28.7.12. D iseño para el fallo
rarjuntos tendrán que residir lo más cerca posible, pre
feriblemente en el mismo servidor, o si no, y no de
¿Por qué puede ser
manera tan preferible, en servidores conectados a tra
vés de medios de transmisión rápidos tales como los
medios utilizados en una red de área local. • catastrófico un fallo de
hardware en un sistema de
comercio electrónico?
28.7.8. Considerar la utilización de servidores Un fallo de hardware en la mayoría de los sistemas de

dedicados a funciones frecuentes comercio electrónico es una catástrofe: para los siste
Algunas veces se puede lograr un mayor rendimiento mas de ventas en red esto es equivalente a echar el cie
mediante la utilización de un servidor de empleo espe rre a los clientes. Una parte importante del proceso de
cífico para una función en particular en lugar de, por diseño es analizar los fallos que podrían aparecer en un
ejemplo, un servidor de bases de datos. sistema distribuido y diseñar el sistema con suficiente
redundancia como para que dicho fallo no afecte seria
28.7.9. Correspondenciade la tecnología con las
mente y, en el mejor de los casos, que se pueda redu
cir el tiempo de respuesta de ciertas transacciones. Una
exigen cia s de rendimiento decisión normal que suele tomar el diseñador es dupli
Muchas de las tecnologías que se estudian en este capí car l o s servidores vitales para el funcionamiento de u n
tulo tienen pros y contras, y un factor importante aquí sistema distribuido. Una estrategia en los sistemas de
son las demandas de rendimiento de una tecnología en alta integridad es que un servidor se reproduzca tres
particular. veces y que cada servidor lleve a cabo la misma tarea
Por ejemplo, como medio de comunicación, las en paralelo. Cada servidor produce un resultado a com
conexiones (sockets) normalmente son un medio de parar. Si los tres servidores aceptan el resultado, éste
comunicación mucho más rápido que los objetos dis pasa a cualquier usuario o servidor que lo requiera; si
tribuidos. Cuando el diseñadorelige una tecnología debe uno de los servidores no está de acuerdo, entonces sur
de tener conocimiento de la transmisióny de las cargas ge un problema y el resultado de la mayoría se pasa
de procesamiento que conlleva, y seleccionar una tec informando al administrador de sistemas del posible
nología que minimice estas cargas. problema. La duplicación de servidores como estrate
gia de mitigación de fallos puede utilizarse junto con
28.7.10. Empleo del paralelismo todo lo posible el diseño de un sistema para lograr el paralelismo en
Una de las ventajas principales de la tecnología clien las tareas.
te/servidor es el hecho de que se pueden añadir servi
dores y, hasta cierto punto, elevar el rendimiento del 28.7.13. Minimizar la latencia
sistema. Muchas funciones del comercio electrónico
pueden beneficiarse de la ejecución que están llevando Cuando los datos fluyen de una computadora a otra en
a cabo diferentes servidores enparalelo. Esta no es una un sistema distribuido a menudo tiene que atravesar
decisión sencilla. Mediante el empleo de varios servi otras computadoras. Algunas de estas computadoras
dores, el diseñador está creando la necesidad de que puede que ya tengan unos datos que expidan funciona
estos servidores se comuniquen, por ejemplo, un servi lidad; es posible que otras procesen los datos de algu
dor puede que necesite a otro para completar una tarea na manera. El tiempo que tardan las computadoras es
enparticular antes de finalizar la suyapropia. Esta comu lo que se conoce como latencia. Un buen diseño de sis
nicación puede introducir retrasos y, si el diseñador no tema distribuido es el que minimiza el número de com
tiene cuidado, pueden negar los avances de rendimien putadoras intermediarias.
to que se han logrado utilizando el paralelismo.
28.7.14. Epílogo
28.7.11. U tilización de la com presión de datos Este ha sido un estudio breve aunque necesario, y se
todo lo posible han tratado las diferentes estrategias de diseño que se
www.FreeLibros.org
Se dispone de un grupo de algoritmos que comprimen utilizan en los sistemas distribuidos que implementan
dalos y que reducen el tiempo que tardan los datos en las funciones del comercio electrónico. Un punto impor
transferirse entre un componente de un sistema distri tante a tener en cuenta antes de abandonar esta sección
506
CAPÍTULO 28 ING EN IE RÍ A DEL S O F T WA R E DEL C O M E R C I O E L E C T R Ó N I C O C L IE NT E/ S ER V ID OR
es que una estrategia puede m ilitar contra otra, m ini de datos duplicadas increm enta la latencia de un siste
mizar la latencia y duplicar bases de datos pueden ser m a; com o consecuencia, el diseño de sistem as distri
dos estrategias opuestas: incrementar el número de bases buidos, más que otra cosa, es un arte.
£H,8 INGEK1EBÍA D É H I P A D _ ■ ■■■«- -- ■ --
El incremento m asivo en la utilización pública de sis Estas son entonces algunas de las intrusiones que pue
temas distribuidos ha dado lugar a algunos problemas den tener lugar dentro de un sistema distribuido; estas
graves con la seguridad. Los sistemas distribuidos ante intrusiones cada vez son m ás frecuentes, ya que gran
riores se suelen localizar en un lugar físico utilizando parte de la transm isión en los sistemas de comercio elec
tecnologías tales com o redes de área local. Dichos s is trónico ocurren en una Internet públicam ente accesible
temas estaban físicamente aislados de los usuarios exter que utiliza protocolos públicam ente disponibles.
nos y com o consecuencia la seguridad, aunque es un Una de las tareas m ás importantes del diseñador de
problema, no era un problem a enorme com o lo es aho sistemas distribuidos es diseñar un sistema con el pro
ra para los sistemas de comercio electrónico a los que pósito de m inim izar la posibilidad de éxito de las ins
pueden acceder m iem bros de usuarios que emplean un trucciones de alto riesgo. Para poder llevarlo a cabo se
navegador. necesita utilizar una serie de tecnologías. En la siguien
A continuación, se detallan algunas de las intrusio te sección se hace una relación detallada de estas tec
nes típicas en la seguridad que pueden ocurrir: nologías.
• Un intruso monitoriza el tráfico de una línea de trans
m isión y recoge la inform ación confidencial que 28.8.1. E n crip ta ció n
genera un usuario. Por ejemplo, el intruso podría leer
el núm ero, la fecha de caducidad y el nom bre del ¿Qué es la encriptación y
titular de una tarjeta de crédito. Y, a continuación,
puede utilizar esta inform ación para realizar pedidos
en Internet.
• por qué es útil?
Encriptación es el térm ino que se utiliza para referirse

al proceso de transform ar datos o texto (texto en claro)
• Un intruso podría entrar en un sistema distribuido, para ser ilegible; además, debería resultar virtualmente
acceder a la base de datos y cambiar la inform ación im posible que un intruso pueda descifrarlo. A co n ti
de la misma. Por ejemplo, podría cambiar el balance nuación, se detalla el proceso de utilización de esta tec
de una cuenta en un sistema bancario en la red. nología:
1. La com putadora em isora transform a el texto en
alguna forma ilegible; este proceso se conoce com o
CLAVE encriptación.
Ahora que Internet ya se estó utilizando 2. Los datos encriptados entonces se envían a través de
para muchas mós aplicaciones, la seguridad
líneas de transm isión insegura.
se convierte en un problema Importante.
3. La com putadora receptora procesa el texto encrip-
tado y lo transform a a su form a original. Este p ro
• Un intruso podría leer una transacción que pasa por ceso se conoce com o desencriptación.
alguna línea de transm isión y alterar los datos den
Se utilizan dos formas de encriptación. La primera
tro de ella en beneficio propio. Por ejemplo, podría
es la encriptación simétrica, donde un mensaje se trans
alterar la instrucción de un cliente de un sistema ban
form a en una form a encriptada utilizando una cadena
cario en red para transferir los datos de una cuenta a
conocida com o clave: se aplica alguna transform ación
otra para que la cuenta del intruso sea la que tiene
en el mensaje utilizando la clave. Entonces la clave se
lugar en la transferencia.
com unica al receptor a través de algún m edio seguro y
• Un ex empleado contrariado de una com pañía envía es utilizado por el receptor para llevar a cabo la desen
un program a al sistema distribuido de la compañía criptación.
monopolizando el tiempo del procesador del sistema, La encriptación sim étrica es eficiente pero padece
pasando gradualmente de servidor a servidor hasta un problem a importante: si un intruso descubre la cla
que el sistema queda exhausto y acaba parándose. ve, podría descubrir fácilm ente el m ensaje encripta-
Esta es una form a de ataque conocido com o dene do. La encriptación de clave pública es una solución
gación de ataque al servicio. a este problem a, donde se u tiliza n dos claves de
www.FreeLibros.org
• Un empleado contrariado de una compañía envía un encriptación: una conocida com o clave pública y otra
programa a un sistema distribuido el cual borra los com o clave privada. Un usuario que desea recibir men-
archivos importantes del sistema. sajes encriptados publicará su clave pública. O tros
507
in g en ier ía del s o f t w a r e . un e n fo q u e pra c t ic o
u s u a r io s q u e d e s e e n c o m u n ic a r s e c o n e l u s u a r io u t i e s la q u e s e u t ili z a n o r m a lm e n t e p a r a e s to . C o n s id e
liz a r á n e s ta c la v e p a r a e n c r i p t a r c u a l q u i e r m e n s a je ; r e m o s u n a f o r m a d e lle v a r a c a b o e s te p r o c e s o : d o s
lo s m e n s a je s e n t o n c e s s o n d e s e n c r ip t a d o s m e d ia n t e u s u a r io s d e c o m p u ta d o r a s A y B q u ie r e n c o m u n ic a r
la c la v e p r iv a d a c u a n d o lo s r e c ib e e l u s u a r io o r ig in a l. s e , y A q u ie r e a s e g u r a r s e d e q u e s e e s tá c o m u n ic a n d o
E s ta f o r m a d e e n c r ip ta c ió n tie n e la v e n ta ja p r in c ip a l c o n B . P a r a p o d e r h a c e r e s to , B n e c e s it a t e n e r u n a c la
d e q u e la g e s tió n d e c la v e s e s s e n c illa : la c la v e p r i v e p ú b lic a y u n a p r iv a d a , y te n e r c o n o c im ie n t o d e c u á l
v a d a n u n c a s e e n v í a a n a d ie . U n in t r u s o q u e m o n i t o - e s la c la v e p ú b lic a . A e n v í a u n m e n s a je a B c o n u n t e x
r iz a lo s d a t o s e n c r ip t a d o s q u e v ia j a n p o r a lg ú n m e d io to e n e l q u e A p id e a B u n a e n c r ip t a c ió n u t iliz a n d o su
d e t r a n s m is ió n e s in c a p a z d e d e c o d if ic a r n i n g ú n m e n c la v e p r iv a d a . E s te t e x t o e n to n c e s e s e n c r ip t a d o p o r B
s a je p u e s t o q u e n o t i e n e n a c c e s o p o s i b l e a l a c la v e y d e v u e lt o a A q u ie n l o d e s c if r a u t iliz a n d o la c la v e
p r iv a d a . E l in c o n v e n ie n te p r in c ip a l d e e s ta f o r m a d e p ú b lic a q u e B le h a p r o p o r c io n a d o . S i e l m e n s a je e s e l
e n c r ip t a c ió n e s q u e s e n e c e s it a u n a g r a n c a n t id a d d e m is m o q u e e l q u e s e e n v ió , B e s e n to n c e s q u ie n d ic e
r e c u rs o s p a ra lle v a r a c a b o e l p r o c e s o d e d e s e n c r ip - q u e e s , p e r o , s i n o lo e s , B e n t o n c e s n o h a d e m o s t r a
t a c ió n . D e b id o a e s ta c la v e p ú b lic a , lo s s is t e m a s n o r d o s u id e n t id a d . E s te e s q u e m a c o m p a r t e to d a s la s v e n
m a lm e n t e s e li m it a n a e n v ío s c o r t o s d e t e x t o o a u n t a ja s d e c u a lq u ie r m é t o d o d e c la v e p ú b lic a e n d o n d e
te x t o p e n s a d o p a r a s e r a lta m e n t e s e g u r o . T a m b ié n se la c la v e p r iv a d a e s s e g u r a ; s in e m b a r g o , p u e d e s e r a ta
u t ili z a p a r a la a u t e n t ic a c ió n , la c u a l u t ili z a u n a t é c n i c a d o p o r c u a lq u ie r a q u e d e s e e e s ta b le c e r f a lt a d e c o n
c a c o n o c id a c o m o f ir m a s d ig it a le s , q u e s e d e s c r ib e n fia n z a e n tr e u n e m is o r y u n r e c e p to r . E s to se p u e d e
e n la s e c c ió n s ig u ie n te . h a c e r a lte r a n d o e l m e n s a je e n c r ip t a d o q u e s e h a d e v u e l
L a te c n o lo g ía p r in c ip a l q u e s e u t iliz a e n In te r n e t t o a l e m is o r .
p a r a la e n c r ip t a c ió n s im é t r ic a e s la c a p a d e s o c k e ts
s e g u r o s (SSL ). E s t a e s u n a t e c n o l o g í a q u e s e u t i l i z a
p a r a e n c r i p t a r d a t o s c o n f i d e n c i a le s t a le s c o m o lo s
28.8.4. Certificaciones digitales
n ú m e r o s d e la s t a r j e t a s d e c r é d i t o q u e v i a j a n d e s d e e l
n a v e g a d o r a u n s e r v id o r W e b , o d e s d e u n a a p lic a c ió n U n a c e r tif ic a c ió n d ig it a l e s u n d o c u m e n to e le c tr ó n ic o
a o tra . q u e p r o p o r c io n a a l u s u a r io u n a lt o d e g r a d o d e c o n fia n z a
c o n u n a o r g a n iz a c ió n o p e r s o n a c o n la q u e e s té n tr a
ta n d o . S e p u e d e n u t iliz a r c u a tr o tip o s d e c e r tif ic a c io
nes:
28.8.2. Funciones de compendio de m ensajes
• C e r t if ic a c io n e s d e u n a a u t o r id a d d e c e r t if ic a c ió n .
U n a f u n c i ó n d e c o m p e n d io d e m e n s a je s e s u n a l g o r i t
U n a a u to r id a d d e c e r t if ic a c ió n e s u n a o r g a n iz a c ió n
m o q u e g e n e ra u n n ú m e ro g ra n d e - n o r m a lm e n te e n tr e
q u e p r o p o r c io n a c e r t if ic a d o s d ig it a le s , ta le s c o m o
1 2 8 y 2 5 6 b its d e lo n g itu d — q u e re p r e s e n ta u n c o m
e s t a s d o s o r g a n i z a c i o n e s : Cañada P o s t C o r p o r a t i o n
p e n d io o r e s u m e n d e lo s c a r a c te r e s d e u n m e n s a je . T i e
y lo s s e r v ic io s p o s ta le s d e U S .
n e la p r o p ie d a d d e q u e s i e l m e n s a je c a m b ia y s e v u e lv e
a a p lic a r e l a l g o r i t m o , e l n ú m e r o e n to n c e s c a m b ia . E x is • C e r t if ic a c io n e s d e l s e r v id o r . E s ta s c e r t if ic a c io n e s
t e n m u c h a s u t i l i z a c i o n e s d e la s f u n c i o n e s d e c o m p e n c o n t ie n e n d a to s ta le s c o m o la c la v e p ú b lic a d e l s e r
d i o d e m e n s a je s . U n u s o c o m ú n e s d e t e c t a r lo s c a m b io s v id o r , e l n o m b r e d e la o r g a n iz a c ió n q u e p o s e e e l s e r
e n u n m e n s a je , p o r e je m p lo , e l h e c h o d e q u e u n a t r a n v id o r y la d ir e c c ió n d e l s e r v id o r e n In te r n e t.
s a c c ió n f in a n c ie r a s e h a y a m o d i f ic a d o e n la t r a n s m is ió n • C e r t i f i c a c i o n e s p e r s o n a l e s . E s t a s s o n la s c e r t i f i c a
c o n o b je t o d e f a v o r e c e r a l q u e m o d if ic a . A n t e s d e e n v ia r c i o n e s a s o c ia d a s a u n i n d i v i d u o . C o n t e n d r á n i n f o r
u n m e n s a je s e a p lic a la f u n c ió n d e c o m p e n d io d e m e n m a c ió n f í s ic a ta l c o m o la d ir e c c ió n d e l in d iv id u o
s a je y s e f o r m a u n n ú m e r o g r a n d e . E l m e n s a j e e n t o n j u n t o c o n la in f o r m a c ió n r e la c io n a d a c o n la c o m p u
c e s s e e n v í a c o n e l n ú m e r o a ñ a d id o a l f in a l. L a f u n c ió n ta d o r a c o m o la c la v e p ú b lic a y la d ir e c c ió n d e c o r r e o
d e c o m p e n d io d e m e n s a je s e a p lic a e n e l r e c e p t o r y e l e le c tr ó n ic o d e la p e rs o n a .
n ú m e r o r e s u lta n te se c o m p a r a c o n e l q u e s e e n v ió . S i
• C e r t if ic a c io n e s d e l e d it o r d e s o ftw a r e . E s to s s o n c e r
lo s d o s s o n ig u a le s e l m e n s a je e n to n c e s n o s e h a m o d i
t if ic a d o s q u e p r o p o r c io n a n c o n fia n z a e n q u e e l s o ft
f ic a d o : s i n o s o n ig u a le s e l m e n s a je h a s id o m o d if ic a d o
w a r e h a s id o p r o d u c id o p o r u n a c o m p a ñ í a d e
d u r a n te la t r a n s m is ió n .
s o f t w a r e e s p e c íf ic a .
C o m o e je m p lo p a r a e l f u n c io n a m ie n t o d e e s ta s c e r
t i f i c a c i o n e s t o m e m o s e l d e la s c e r t i f i c a c i o n e s d e l s e r v i
28.8.3. Firmas digitales
d o r . U n s e r v id o r q u e u t ili z a la c a p a d e s o c k e ts s e g u ro s
U n a f ir m a d ig it a l, c o m o s u p r o p io n o m b r e s u g ie r e , e s ( S S L ) d e b e d e te n e r u n c e r tif ic a d o S S L . E s te c e r tif ic a
u n a f o r m a d e q u e e l e m i s o r d e un m e n s a j e s e p u e d a d o c o n t ie n e u n a c la v e p ú b li c a . C u a n d o u n n a v e g a d o r se
www.FreeLibros.org
id e n t if ic a r c o n e l r e c e p to r d e ta l m a n e ra q u e e l r e c e p c o n e c t a c o n e l s e r v id o r s e u t i l i z a e n to n c e s e s ta c la v e
t o r p u e d a c o n f i a r e n q u e e l m e n s a je f u e e n v ia d o r e a l p ú b lic a p a r a c o d if ic a r la in t e r a c c ió n in ic ia l e n tr e e l s e r
m e n te p o r e l e m is o r . L a e n c r ip t a c ió n d e c la v e p ú b li c a v id o r y e l n a v e g a d o r.
508
CAPÍTULO 28 I N GE NI E RÍ A DEL S OF TWARE DEL C O M E R C I O E L E C T R Ó N I C O CLI E NT E/ S ER V ID OR
28.9 COM PONENTES DE.SOFTW ARE PARA SISTEMAS..C/S........ .................— ...
28.9.1. Introducción 28.9.2. Distribución de com ponentes de software

En lugar de visualizar el software como una aplicación Una vez que se han determinado los requisitos básicos
monolítica que deberá de implementarse en una máqui de una aplicacióncliente/servidor, el ingeniero del soft
na, el software que es adecuado para una arquitectura ware debe decidir cómo distribuir los componentes de
posee varios componentes distintos que se pueden aso software descritos en la Sección 28.1.1 entre el cliente
ciar al cliente o al servidor, o se pueden distribuir entre y el servidor. Cuando la mayor parte de la funcionali
ambas máquinas: dad asociada a cada uno de los tres componentes se le
C o m p o n e n te d e in te r a c c ió n c o n e l u s u a r io y p r e
asocia al servidor, se ha creado un diseño de se r v id o r
p e s a d o (grueso). A la inversa, cuando el cliente imple-
s e n t a c i ó n . Este componente implementa todas las fun
ciones que típicamente se asocian a una interfaz gráfica menta la mayor parte de los componentes de interac
de usuario (IGU). ción/presentación con el usuario, de aplicación y de
C o m p o n e n t e d e a p l i c a c i ó n . Este componente imple-
bases de datos, se tiene un diseño de c lie n te p e s a d o
menta los requisitos definidos en el contexto del domi (grueso).
nio en el cual funciona la aplicación. Por ejemplo, una Los clientes pesados suelen encontrarse cuando se
aplicación de negocios podría producir toda una gama implementan arquitecturas de servidor de archivo y de
de informes impresos basados en entradas numéricas, servidor de base de datos. En este caso el servidor pro
cálculos, informaciónde una base de datos y otros aspec porciona apoyo para la gestión de datos, pero todo el
tos. Una aplicación de software de grupo podría pro software de aplicación y de IGU reside en el cliente.
porcionar funciones para hacer posible la comunicación Los servidores pesados son los que suelen diseñarse
mediante boletines de anuncios electrónicos o de correo cuando se implementan sistemas de transacciones y de
electrónico, y en nuestro caso de estudio esto conlleva trabajo en grupo. El servidor proporciona el apoyo de
ría la preparación de informes como los que describen la aplicación necesario para responder a transacciones
las ventas de libros. En ambos casos, el software de la y comunicaciones que provengan de los clientes. El soft
aplicación se puede descomponerde tal modo que algu ware de cliente se centra en la gestión de IGU y de
no de los componentes residan en el cliente y otros resi comunicación.
dan en el servidor.
CLAVE
Referencia W ehl k Un cliente
especificas de
relega la
«pesado» Implementa la mayoría de las aplicaciones
la aplicación en el cliente. Un cliente «ligero»
mayor parte del procesoal servidor.
la PFR del grupo de noticiascomp.dient-server se puede
encontrar en la página
www.faqs.org/faqs/dient-server-faq Se pueden utilizar clientes y servidorespesados para
ilustrar el enfoque general de asignación de compo
nentes de software de cliente/servidor. Sin embargo, un
C o m p o n e n t e d e g e s t i ó n d e b a s e s d e d a t o s . Este
enfoquemás granularpara la asignaciónde componentes
componente lleva a cabo la manipulación y gestión de de software define cinco configuraciones diferentes.
datos por una aplicación. La manipulación y gestión
de datos puede ser tan sencilla como la transferencia de P resen ta ció n distrib u id a . En este e n f o q u e cliente/ser
u n registro, o tan compleja como el procesamiento de vidor rudimentario, la lógicade labase de datos y la lógica
sofisticadas transacciones SQL. de la aplicaciónpermanecen en el servidor, típicamente
Además de estos componentes, existe otro bloque de en una computadora central. El servidor contiene tam
construccióndel software, que suele denominarse soft bién la lógica para preparar información de pantalla,
ware intermedio en todos los sistemas C/S. El softw a empleandoun software tai como CICS. Se utilizaun soft
re i n t e r m e d i o se describió en la Sección 28.2.3. Orfali ware especial basado en PC para transformar la infor
[ORF99] y sus colegas se han referido al software inter mación de pantallabasada en caracteres que se transmite
medio como «el sistema nervioso de un sistema clien desde el servidor en una presentación IGU en un PC.
te/servidor».
¿Cuáles son las opciones de
CLAVE • configuración poro los

componentes de software
diente/servidor?
www.FreeLibros.org
El software Intermedio establécela Infraestructura
que hace posible que los componentes P resen ta ció n rem ota. En esta extensión del enfoque
diente/servidor ¡nteroperen. de presentacióndistribuida, la lógica primaria de la base
509
IN GE NI E RÍ A DEL S O F TW A RE . UN EN F O Q U E P R A C T I C O
d e d a to s y d e la a p lic a c ió n p e r m a n e c e n e n e l s e r v id o r ,
y lo s d a to s e n v ia d o s p o r e l s e r v id o r s e r á n u t iliz a d o s p o r
e l c lie n t e p a r a p r e p a r a r la p r e s e n t a c ió n d e l u s u a r io . I t f f i p á ® ven kt computación
L ó g ica distribuida. S e a s i g n a n a l c l i e n t e t o d a s la s ^/sefWÉf tomo la cuarta generación del
ta r e a s d e p r e s e n ta c ió n d e l u s u a r io y t a m b ié n lo s p r o c e ^^léÍÉlC Éenta informática]
sos a s o c i a d o s a l a i n t r o d u c c i ó n d e d a t o s t a l e s c o m o l a
v a lid a c ió n d e n iv e l d e c a m p o , la f o r m u la c ió n d e c o n
s u l t a s d e s e r v i d o r y la s s o l i c i t u d e s d e i n f o r m a c i o n e s d e
E l r e s t o d e l o s c o m p o n e n t e s d e l a a p l i c a c i ó n s e dis*
a c t u a l i z a c i o n e s d e l s e r v i d o r . S e a s i g n a n a l s e r v i d o r la s
t r i b u y e e n t r e c l i e n t e y s e r v i d o r b a s á n d o s e e n l a d i s t r i
t a r e a s d e g e s t i ó n d e la s b a s e s d e d a t o s , y l o s p r o c e s o s
b u c i ó n q u e o p t i m i c e l a s c o n f i g u r a c i o n e s d e c lie n t e y
p a r a la s c o n s u lt a s d e l c lie n t e , p a r a a c t u a liz a c io n e s d e
s e r v i d o r y d e l a r e d q u e l o s c o n e c t a . P o r e j e m p l o , la
a r c h iv o s d e l s e r v id o r , p a r a c o n tr o l d e v e r s ió n d e c lie n
i m p l e m e n t a c i ó n d e u n a r e l a c i ó n m u t u a m e n t e e x c lu y e n -
te s y p a r a a p lic a c io n e s d e á m b it o g e n e r a l d e la e m p r e s a .
t e i m p l i c a u n a b ú s q u e d a e n l a b a s e d e d a t o s p a r a d e te r
G estión de dato s remota. L a s a p l i c a c i o n e s d e l s e r m i n a r s i e x is t e u n r e g is t r o q u e s a t is f a g a lo s p a rá m e tro s
v id o r c re a n u n a n u e v a fu e n te d e d a to s d a n d o fo r m a t o a d e u n a c i e r t a t r a m a d e b ú s q u e d a . S i n o s e e n c u e n t r a n in
lo s d a to s q u e s e h a n e x t r a í d o d e a lg ú n o t r o lu g a r ( p o r g ú n r e g i s t r o , s e e m p l e a u n a t r a m a d e b ú s q u e d a a lte r n a
e je m p lo , d e u n a fu e n te d e n iv e l c o r p o r a tiv o ) . L a s a p li tiv a . S i la a p lic a c ió n q u e c o n t r o la e s ta tr a m a d e b ú s q u e d a
c a c io n e s a s ig n a d a s a l c lie n t e s e u t i l i z a n p a r a e x p l o t a r e s tá c o n t e n id a e n s u t o t a lid a d e n e l s e r v id o r , s e m in im i
lo s n u e v o s d a to s a lo s q u e s e h a d a d o f o r m a t o m e d ia n te z a e l t r á f ic o d e r e d . L a p r im e r a t r a n s m is ió n d e la re d d e s
e l s e r v i d o r . E n e s t a c a t e g o r í a s e i n c l u y e n l o s s is t e m a s d e e l c lie n t e h a c ia e l s e r v id o r c o n t e n d r í a lo s p a rá m e tro s
d e a p o y o d e d e c is io n e s . t a n t o p a r a l a t r a m a d e b ú s q u e d a p r i m a r i a c o m o p a r a la
B ases de datos distribuidas. L o s d a t o s d e q u e c o n s t a t r a m a d e b ú s q u e d a s e c u n d a r i a . L a l ó g i c a d e a p lic a c ió n
la b a s e d e d a to s s e d is t r ib u y e n e n tr e m ú lt ip le s c lie n te s d e l s e r v id o r d e te r m in a r ía s i s e r e q u ie r e la s e g u n d a bú s
y s e r v id o r e s . C o n s ig u ie n t e m e n t e , e l c lie n t e d e b e d e q u e d a . E l m e n s a je d e r e p u e s ta a l c lie n t e c o n te n d r ía e l
a d m itir c o m p o n e n te s d e s o ftw a r e d e g e s tió n d e d a to s r e g i s t r o h a l l a d o c o m o c o n s e c u e n c i a b i e n d e l a p r im e r a
a s í c o m o c o m p o n e n te s d e a p lic a c ió n y d e I G U . o b i e n d e l a s e g u n d a b ú s q u e d a . E l e n f o q u e a l t e r n a t iv o
D u r a n te lo s Ú lt im o s a ñ o s s e h a d a d o m u c h a im p o r ( e l c l i e n t e i m p l e m e n t a l a l ó g i c a p a r a d e t e r m i n a r s i se
ta n c ia a la t e c n o lo g ía d e c lie n te lig e r o . U n c lie n te lig e r e q u i e r e u n a s e g u n d a b ú s q u e d a ) i m p l i c a r í a u n m e n s a je
r o e s la lla m a d a « c o m p u t a d o r a d e r e d e s » q u e r e le g a to d o p a r a la p r im e r a r e c u p e r a c ió n d e r e g is t r o s , u n a re s p u e s
e l p r o c e s a m ie n to d e la a p lic a c ió n a u n s e r v id o r p e s a d o . t a a t r a v é s d e l a r e d si n o s e h a l l a e l r e g i s t r o , un s e g u n
L o s c lie n te s lig e r o s ( c o m p u ta d o r a s d e r e d ) o f r e c e n u n d o m e n s a je q u e c o n t u v ie r a lo s p a r á m e tr o s d e la s e g u n d a
c o s te p o r u n id a d s u s t a n c ia lm e n te m á s b a jo a u n a p é r b ú s q u e d a , y u n a r e s p u e s t a f i n a l q u e c o n t u v i e r a e l r e g is
d id a d e r e n d im ie n to p e q u e ñ a o n a d a s ig n if ic a t iv a e n t r o r e c u p e r a d o . S i e n l a s e g u n d a b ú s q u e d a s e n e c e s it a e l
c o m p a r a c i ó n c o n la s c o m p u t a d o r a s d e s o b r e m e s a . 5 0 p o r 1 0 0 d e la s v e c e s , l a c o l o c a c i ó n d e l a l ó g i c a e n e l
s e r v i d o r p a r a e v a l u a r l a p r i m e r a b ú s q u e d a e i n i c i a r la
28.9.3. L ín e a s g e n e r a l e s p a r a l a d is tr ib u c ió n d e s e g u n d a s i fu e r a n e c e s a r io r e d u c ir í a e l t r á f ic o d e re d en
un 33 p o r 100.
c o m p o n e n te s d e a p lic a c io n e s
A u n c u a n d o n o e x is t e n r e g la s a b s o lu t a s q u e d e s c r ib a n
la d is t r ib u c ió n d e c o m p o n e n te s d e a p lic a c io n e s e n tr e e l
c l i e n t e y e l s e r v i d o r , s u e l e n s e g u i r s e la s s i g u i e n t e s l í n e
Aunque t e líneas generóles de lo distribución son valiosos,
a s g e n e r a le s :
todos los sistemas deben de tomarse en consideración
El c o m p o n e n te d e p re se n ta c ió n lin te ra c c ió n su ele por sus propios méritos. Poro todos los beneflclosderivados
ub icarse en el cliente. L a d i s p o n i b i l i d a d d e e n t o r n o s de, digamos, un cliente pesado, el diseñador debe de luchar
b a s a d o s e n v e n ta n a s y d e la p o te n c ia d e c ó m p u to n e c e con un conjunto parecido de contruriedodes.
s a r ia p a r a u n a in t e r f a z g r á f ic a d e u s u a r io h a c e q u e e s te
e n fo q u e s e a e f ic ie n t e e n té r m in o s d e c o s te . L a d e c is ió n f in a l a c e rc a d e la d is t r ib u c ió n d e c o m
S i es necesario com partir la base de datos entre m ú l p o n e n t e s d e b e r í a e s t a r b a s a d a n o s o la m e n t e e n la a p li
tiples usuarios conectados a través de la LA N , en to n c a c i ó n i n d iv id u a l , s in o e n la m e z c la d e a p lic a c io n e s q u e
ces la base de dato s suele u b icarse en el servidor. E l e s t é f u n c i o n a n d o e n e l s i s t e m a . P o r e j e m p l o , u n a in s t a
s is t e m a d e g e s t ió n d e la b a s e d e d a to s y la c a p a c id a d d e l a c i ó n p o d r í a c o n t e n e r a l g u n a s a p l i c a c i o n e s q u e r e q u ie
a c c e s o a la b a s e d e d a to s t a m b ié n s e a s ig n a n a l s e r v i r a n u n e x te n s o p r o c e s a m ie n to d e I G U y m u y p o c o
d o r , j u n t o c o n la b a s e d e d a to s fís ic a . p r o c e s a m i e n t o c e n t r a l d e l a b a s e d e d a t o s . E s t o d a r ía
L o s d atos estáticos que se utilicen deberían de a sig l u g a r a l a u t i l i z a c i ó n d e p o t e n t e s e s t a c i o n e s d e t r a b a jo
www.FreeLibros.org
narse a l cliente. E s t o s i t ú a l o s d a t o s m á s p r ó x i m o s a l e n e l l a d o c l i e n t e y a u n s e r v i d o r m u y s e n c i l l o . U n a vez
u s u a r io q u e tie n e n e c e s id a d d e e llo s y m i n im iz a u n t r á im p la n t a d a e s ta c o n f i g u r a c i ó n , o t r a s a p lic a c io n e s f a v o -
f i c o d e r e d in n e c e s a r io y la c a r g a d e l s e r v id o r . r e c e r í a n e l e n f o q u e d e c l i e n t e p r i n c i p a l , p a r a q u e la s
510
CAPÍTULO 28 I NGENI ERI A DEL S O F T W A R E DEL C O M E R C I O E L E C T R Ó N I C O CLI ENTE/ S ERVI DOR
capacidades del servidor no tuvieran necesidad de ver el objeto al cual se había destinado el mensaje, para invo
se aumentadas. car su método, para pasar al objeto los datos adecuados,
Habría que tener en cuenta que a m edida que m adu y para transferir los datos resultantes de vuelta al obje
ra el uso de la arquitectura cliente/servidor, la tenden to que generase el mensaje inicialmente.
cia es a ubicar la lógica de la aplicación volátil en el
servidor. Esto simplifica la im plantación de actualiza
ciones de software cuando se hacen cambios en la lógi \ a v e
ca de la aplicación [PAU95]. Un ORB capacito a un objeto que resida en un cliente
para enviar un mensaje a un método que esté
2 8 .9 .4 . E n l a z a d o d e c o m p o n e n t e s d e s o f t w a r e C / S encapsulodo en otro objeto que resido en un servidor.
Se utiliza toda una gam a de m ecanismos distintos para En el Capítulo 27 se estudiaron los tres estándares
enlazar los distintos com ponentes de la arquitectura m ás utilizados que im plementan una filosofía de redis
cliente/servidor. Estos m ecanismos están incluidos en tribución de objetos: CORBA, CO M y JavaBeans. COR-
la estructura de la red y del sistema operativo, y resul BA se utilizará para ilustrar la utilización del software
tan transparentes para el usuario final situado en el cen interm edio O R B .
tro cliente. Los tipos m ás comunes de mecanismos de
enlazado son:
• Tuberías (pipes):se utilizan mucho en los sistemas
basados en UNIX; las tuberías perm iten la m ensaje Referencía W e b Í^ '
ría entre distintas m áquinas que funcionen con dis La información más actualizada sobre estándares de
tintos sistemas operativos. componentes se puede encontrar en la página
www.omg.com,www.microsoft.com/COM, y
• L l a m a d a s a p r o c e d i m i e n t o s r e m o t o s : perm iten que
java.sun.com/beans
un proceso invoque la ejecución de otro proceso o
módulo que resida en una m áquina distinta. En la Figura 28.6 se m uestra la estructura básica de
una arquitectura CORBA. Cuando se implementaCOR-
¿Cuáles son las opciones BA en un sistema cliente/servidor, los objetos y las cla
§ disponibles para vincular

componentes?
ses de objetos (Capítulo 20) tanto en el cliente como en
el servidor se definen utilizando un lenguaje de d es
cripción de interfaces (LD I2), un lenguaje declarativo
• se utiliza para pasar
I n t e r a c c ió n S Q L c lie n t e ls e r v id o r : que permite que el ingeniero del software defina obje
solicitudes SQL y datos asociados de un componente tos, atributos, métodos y los mensajes que se requieren
(típicamente situado en el cliente) a otro componente para invocarlos. Con objeto de admitir una solicitud para
(típicamenteel SGBD del servidor).Este mecanismo un m étodo residente en el servidor procedente de un
está limitado únicam ente a las aplicaciones SGBDR. objeto residente en el cliente, se crean stubs LDI en el
• C o n e x i o n e s ( s o c k e t s ) , se tratan en la Sección 28.6. cliente y en el servidor. Estos s t u b s proporcionan la pasa
rela a través de la cual se admiten las solicitudesde obje
Además, las im plementaciones orientadas a objetos
tos a través del sistema C/S.
de componentes de software C/S dan lugar a una &-
Dado que las solicitudes de objetos a través de la red
culación» que haga uso de un distribuidor de solicitu
se producen en el m om ento de la ejecución, e s preciso
des de objetos. Este enfoque se describirá en la sección
establecer un m ecanismo para almacenar una descrip
siguiente.
ción del objeto de tal m odo que la inform ación p erti
nente acerca del objeto y de su ubicación esté disponible
2 8 5 5 . S o ftw a r e in te r m e d io (m id d le w a r e ) cuando sea necesario. El repositorio de interfaz hace
y a r q u it e c t u r a s d e a g e n t e d e s o lic itu d precisam ente esto.
d e o b je to s
Los componentes de software C/S descritos en las sec
ciones anteriores están implementadas mediante obje as ib poso positivo, pero no
tos que deben de ser capaces de interactuar entre s í en resolvertes retos más críticos del
e l seno de una sola m áquina (bien sea cliente o servidor)
o a través de la red. Un agente de distribución de obje
tos (ORB) es un componente de softwareintermedio que
capacita a un objeto que resida en un cliente para enviar Cuando una aplicación cliente necesita invocar un
un mensaje a un m étodo que esté encapsulado en otro m étodo contenido en el seno de un objeto residente en
www.FreeLibros.org
objeto que resida en un servidor. En esencia, el ORB alguna otra parte del sistema, CORBA utiliza una invo
intercepta el mensaje y m aneja todas las actividades de
comunicación y de coordinación necesarias para hallar 2 En inglés IDL (Interface Description Language)
511
INGE NIE RÍ A DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
cación dinámica para (1) obtener la inform ación perti dentes del cliente, y lleva a cabo otras muchas tareas
nente acerca del objeto deseado a partir del depósito de de gestión de objetos [ORF99]. En el servidor unos
interfaz; (2) crear una estructura de datos con parám e stubs LDI, similares a los definidos en la máquina Chen
tros que habrá que pasar al objeto; (3) crear una solici te, se em plean com o interfaz con la implementación
tud para el objeto; y (4) invocar la solicitud. A del objeto real que reside en la ubicación del servidor.
continuación, se pasa la solicitud al núcleo ORB — una El desarrollo del software para sistemas C/S moder
parte dependiente de im plementación del sistema ope nos está orientado a objetos. Empleando la arquitectu
rativo en red que gestione las solicitudes — y, a conti ra C O RBA descrita brevem ente en esta sección, los
nuación, se satisface la solicitud. desarrolladores de software pueden crear un entorno a i
La solicitud se pasa a través del núcleo y es proce el cual se pueden reutilizarlos objetos a lo largoy ancho
sada por el servidor. En la ubicación del servidor, un de una red muy amplia. Para m ás inform ación acerca
adaptador de objetos almacena la inform ación de cla de CORBA y de su impacto general sobre la ingeniería
ses y de objetos en un depósito de interfaz residente en del software para sistemas C/S, el lector interesado pue
el servidor, adm ite y gestiona las solicitudes p ro c e de consultar [HOQ99] y [SIE99],
28.10 IN G ENIERÍA DEL SOFTW ARE PARA SISTEM A S C /S
En el C ap ítu lo 2 se p resen tó un cierto núm ero de

m odelos de proceso de software distintos. Aun cuan
do m uchos de ellos se podrían adaptar para su u tili R e p o s ito rio 1 --------- C lie n te
d e in te r fa z 1
zación en el desarrollo de software para sistem as C/S,
hay dos enfo q u es que son los que se utilizan m ás
com únm ente: (1) un paradigm a evolutivo que hace
uso de la ingeniería del softw are basada en sucesos
y/o orientada a objetos; y (2) una ingeniería del soft
ware basada en componentes (Capítulo 27) que se basa
en una biblioteca de com ponentes de software CYD
y de desarrollo propio.
Los sistemas cliente servidor se desarrollan em plean
do las actividades de ingeniería del software clásicas
—el análisis, diseño, construcción y depuración— a
medida que evoluciona el sistema a partir de un con
ju n to de requisitos de negocios generales para llegar a
ser una colección de componentes de software ya vali
dados que han sido implementados en m áquinas clien
te y servidor. F IG U R A 2 8 . 6 . La arquitectura básica CORBA.
2 M L PROBLEMAS DE MODELADO DE ANÁLISIS
La actividad de modelado de requisitos para los sistemas Dado que el m odelado de análisis evita la especi
C/S difiere poco de los métodos de m odelado de análisis ficación de detalles de im plem entación, sólo cuando
que se aplicaban para la arquitectura de computadoras más se haga la tran sició n al diseño se considerarán los
convencionales. Consiguientemente, los principios bási problem as asociados a la asignación de software al
cos de análisis descritos en el Capítulo 11 y los métodos cliente y al servidor3. Sin em bargo, dado que se apli
de modelado de análisis presentados en los Capítulos 12 ca un enfoque evolutivo de la ingeniería del softwa
y 21 son igualmente aplicables al software C/S. Se debe re para los sistem as C /S, las d ec isio n e s de imple-
ría destacar, sin embargo, que dado que muchos sistemas m entación acerca del enfoque C/S global (por ejem
C/S m odernos hacen uso de componentes reutilizables, plo, cliente pesado frente a servidor pesado) se podrán
también se aplican las actividades de cualificación aso hacer durante las prim eras iteraciones de análisis y
ciadas a la ISBC (Capítulo 27). diseño.
www.FreeLibros.org
3 Por ejem plo, una arquitectura C /S conform e a CORBA (Sección
2 8.1,5)tendrá un profundo impacto en la decisiones sobre el diseño
y la implementación.
512
CAPÍTULO 28 I N GE NIE RÍ A DEL S O F T WA R E DEL C O M E R C I O E L E C T R Ó N I C O CLI E NT E/ S ER V ID OR
21,12 DISEÑO DE,SISU

C u a n d o s e e s tá d e s a r r o lla n d o u n s o ftw a r e p a r a s u im p le - r ís tic a s . S in e m b a r g o , t a m b ié n s e p u e d e n a d o p ta r m é t o
m e n ta c ió n e m p le a n d o u n a a r q u it e c t u r a d e c o m p u t a d o d o s c o n v e n c io n a le s ( C a p í tu lo s 1 2 y 1 6 ) .
ra s c o n c r e ta , e l e n f o q u e d e d is e ñ o d e b e d e c o n s id e r a r
e l e n t o r n o e s p e c í f ic o d e c o n s t r u c c ió n . E n e s e n c ia , e l 28.12.1. Diseño arquitectónico para sistemas
d is e ñ o d e b e r í a d e p e r s o n a liz a r s e p a r a a d e c u a r lo a la
cliente/servidor
a r q u it e c t u r a d e l h a r d w a r e .
C u a n d o s e d is e ñ a s o ftw a r e p a r a s u im p le m e n t a c ió n E l d is e ñ o a r q u it e c t ó n i c o d e u n s is t e m a c lie n t e s e r v i d o r
e m p le a n d o u n a a r q u it e c t u r a c lie n t e / s e r v id o r , e l e n fo q u e s e s u e le c a r a c t e r iz a r c o m o u n e s t il o d e c o m u n ic a c ió n
d e d is e ñ o d e b e d e s e r « p e r s o n a liz a d o » p a r a a d e c u a r lo d e p r o c e s o s . B a s s y s u s c o le g a s [ B A S 9 8 ] d e s c r ib e e s ta
a lo s p r o b l e m a s s i g u i e n t e s : a r q u it e c t u r á d e la s ig u ie n te m a n e r a :
El o bjetivo es lograr la calidad de la escalabilidad. U n ser
• E l d is e ñ o d e d a to s ( C a p í t u lo 1 4 ) d o m in a e l p r o c e s o
vid o r e xiste p a ra pro p o rcio n ar datos para uno o m ás clientes,
d e d i s e ñ o . P a r a u t i l i z a r e f e c t i v a m e n t e la s c a p a c i d a
que suelen estíií distribuidos en u n a red. E l cliente origina una
d e s d e u n s is t e m a d e g e s t ió n d e b a s e s d e d a to s r e la - ña m a d a al servidor, el cual trabaja síncronam ente o asincro
c io n a l ( S G B D R ) o u n s is t e m a d e g e s t ió n d e b a s e s d e nam ente, para serv ir a la solicitud del cliente. Si el servidor
d a to s o r ie n t a d o a o b je t o s ( S G B D O O ) e l d is e ñ o d e fun cio n a síncronam ente, d evuelve el control al cliente al m is
m o tiem p o que devuelve los datos. Si el servidor trabaja asin
lo s d a t o s p a s a a s e r t o d a v í a m á s s i g n i f i c a t i v o q u e e n cro n am en te, d evuelve solo los datos al cliente (el que tiene su
la s a p l i c a c i o n e s c o n v e n c i o n a l e s .
propio h ilo de control).
ONSEJÓ^ m sm e m a k .
km cuando el software C/S es diferente, se pueden Biel Capítulo 14 se presenta un estudio detallado de
utilizarmétodos convencionales o de diseño00 conm uy aiquitecturcs.
pocos modificaciones.
D a d o q u e lo s s is t e m a s m o d e r n o s C /S e s tá n b a s a d o s
• C u a n d o s e s e le c c io n a e l p a r a d ig m a c o n t r o la d o p o r
e n c o m p o n e n te s , s e u t ili z a u n a a r q u it e c t u r a d e a g e n te
s u c e s o s , d e b e r ía r e a liz a r s e e l m o d e la d o d e l c o m d e s o lic it u d d e o b je t o s ( O R B ) p a r a im p le m e n t a r e s ta
p o r t a m ie n t o ( u n a a c t iv id a d d e l a n á lis is , C a p í t u lo 1 2 c o m u n ic a c ió n s ín c r o n a y a s ín c r o n a .
y 2 1 ) y s e r á p r e c is o t r a d u c ir lo s a s p e c to s o r ie n t a d o s A u n n iv e l a r q u it e c t ó n ic o , e l le n g u a je d e d e s c r ip
al c o n t r o l i m p l í c i t o s e n e l m o d e l o d e c o m p o r t a m i e n t o c ió n d e la in t e r f a z C O R B A 4 s e u t ili z a p a r a e s p e c if i
a l m o d e lo d e d is e ñ o . c a r lo s d e t a lle s d e la in t e r f a z . L a u t ili z a c ió n d e L D I
. E l c o m p o n e n te d e in t e r a c c ió n /p r e s e n ta c ió n d e l u s u a p e r m it e q u e lo s c o m p o n e n te s d e s o f t w a r e d e la a p l i
r io d e u n s is t e m a C /S im p le m e n t a t o d a s a q u e lla s f u n c a c ió n a c c e d a n a lo s s e r v ic io s O R B ( c o m p o n e n te s )
c io n e s q u e s e a s o c i a n t í p i c a m e n t e c o n u n a i n t e r f a z s in u n c o n o c im ie n t o d e s u f u n c io n a m ie n t o in te r n o .
g r á f ic a d e u s u a r i o ( I G U ) . C o n s i g u i e n t e m e n t e , s e v e r á E l O R B ta m b ié n t ie n e la r e s p o n s a b ilid a d d e c o o r d i
in c r e m e n t a d a l a i m p o r t a n c i a d e l d i s e ñ o d e i n t e r f a n a r la c o m u n ic a c ió n e n tr e lo s c o m p o n e n te s d e l c lie n
c e s ( C a p í tu lo 1 5 ). E l c o m p o n e n te d e in te r a c c ió n /p r e te y d e l s e r v id o r . P a r a lo g r a r e s to , e l d is e ñ a d o r
s e n t a c i ó n d e l u s u a r i o i m p l e m e n t a t o d a s la s f u n c i o n e s e s p e c if ic a u n a d a p ta d o r d e o b je t o s ( ta m b ié n lla m a d o
q u e s e a s o c ia n t í p ic a m e n t e c o n u n a in t e r f a z g r á f ic a e n c u b r id o r ) q u e p r o p o r c io n a lo s s e r v ic io s s ig u ie n te s
d e u s u a r io ( I G U ) . [B A S 9 8 ]:
• S u e le s e l e c c i o n a r s e u n p u n t o d e v i s t a o r i e n t a d o a • S e r e g i s t r a n la s i m p l e m e n t a c i o n e s d e c o m p o n e n t e s
o b je t o s p a r a e l d is e ñ o ( C a p í t u l o 2 2 ) . E n lu g a r d e la ( o b je t o s ) .
e s tr u c tu r a s e c u e n c ia 1 q u e p r o p o r c io n a u n le n g u a je
• S e i n t e r p r e t a n y s e r e c o n c i l i a n t o d a s la s r e f e r e n c i a s
d e p r o c e d im ie n to s se p r o p o r c io n a u n a e s tr u c tu r a d e
d e c o m p o n e n te s ( o b je t o s ) .
o b je t o s m e d ia n t e la v in c u l a c i ó n e n t r e lo s s u c e s o s
in ic ia d o s e n la I G U y u n a f u n c i ó n d e g e s t ió n d e • S e h a c e n c o i n c i d i r la s r e f e r e n c ia s d e c o m p o n e n t e s
s u c e s o s q u e r e s id e e n e l s o f t w a r e b a s a d o e n e l ( o b je t o s ) c o n la im p le m e n t a c ió n d e lo s c o m p o n e n
c lie n t e . te s c o r r e s p o n d ie n te .
Aun c u a n d o p r o s ig u e to d a v ía e l d e b a te a c e rc a d e l
• S e a c tiv a n y d e s a c tiv a n o b je t o s .
m e jo r e n f o q u e d e a n á l i s i s y d i s e ñ o p a r a l o s s i s t e m a s • S e in v o c a n m é to d o s c u a n d o s e tr a n s m ite n m e n s a
C /S , lo s m é t o d o s o r i e n t a d o s a o b j e t o s ( C a p í t u l o s 2 1 y je s .
2 2 ) p a re c e n o f r e c e r la m e jo r c o m b in a c ió n d e c a r a c te • S e im p le m e n t a n s e r v ic io s d e s e g u r id a d .
www.FreeLibros.org
4 S i COM y JavaBeans se utiliza un m étodo análogo.
513
INGENIERIA DEL SOFTWARE. UN EN FOQ UE PRACT ICO
Para achútir los componentes CYD proporcionados por to s d e n e g o c io s s e lle v a a c a b o e m p le a n d o lo s m é t o

proveedores diferentes y componentes de desarrollo pro d o s d e in g e n ie r í a d e la in f o r m a c ió n d e s c r ito s e n e l
pio que pueden haber sido implementadosutilizando dife C a p í t u l o 10. L a n o t a c i ó n d e m o d e l a d o d e l a n á l i s i s
rentes tecnologías, se debe diseñar la arquitectura ORB c o n v e n c io n a l ( C a p í tu lo 1 2 ), ta l c o m o D E R , se p o d rá
para lograr interoperabilidad entres componentes. Para u t ili z a r p a r a d e f i n i r o b je t o s d e n e g o c io s , p e r o e s p r e
poderlo llevar a cabo CORBA utiliza un concepto puente. c is o e s ta b le c e r u n d e p ó s it o d e b a s e d e d a to s p a r a c a p
Supongamos que un cliente se haya implementado tu r a r la in f o r m a c ió n a d ic io n a l q u e n o se p u e d e
utilizando un protocolo ORB X y que el servidor se haya d o c u m e n ta r p o r c o m p le t o e m p le a n d o u n a n o ta c ió n
implementado utilizando el protocolo ORB Y . Ambos g r á fic a ta l c o m o u n D E R .
protocolos son conform e C O R BA , pero debido a las E n e s te d e p ó s it o , s e d e f in e u n o b je t o d e n e g o c io c o m o
diferencias de im plementacióninternas, se deben com u u n a in f o r m a c ió n q u e e s v is ib le p a r a lo s c o m p r a d o r e s y
nicar con un «puente» que proporcione un mecanismo u s u a r io s d e l s is t e m a , p e r o n o p a r a q u ie n e s l o im p le -
para la traducción entre protocolos internos [BAS98], m e n ta n , p o r e je m p lo , u n li b r o e n e l c a s o d e e s tu d io d e
El puente traduce mensajes de m anera que el cliente y v e n ta s d e lib r o s . E s ta in f o r m a c ió n q u e s e im p le m e n t a
el servidor se puedan com unicar suavemente. u t iliz a n d o u n a b a s e d e d a to s r e la c io n a l, s e p u e d e m a n
te n e r e n u n d e p ó s it o d e d is e ñ o . L a s ig u ie n te in f o r m a
c ió n d e d is e ñ o s e r e c o g e p a r a la b a s e d e d a to s
28.12.2. Enfoques de diseño convencionales para
c lie n te / s e r v id o r [ P O R 9 4 ] :
software de aplicaciones
• E n t i d a d e s : s e i d e n t i f i c a n e n e l D E R d e l n u e v o s is
En los sistemas cliente/servidor, los diagramas de flujo
te m a .
(Capítulos 12 y 14) se pueden utilizar para establecer
el ám bito del sistema, para identificar las funciones de • A r c h i v o s : q u e i m p l e m e n t a n la s e n t i d a d e s i d e n t i f i c a
nivel superior y las áreas de datos tem áticas (alm ace das en e l D E R .
nes de datos), y para perm itir la descomposición de fun • R e la c ió n e n tr e c a m p o y a r c h iv o : e s ta b le c e la d is p o
ciones de nivel superior. Apartándose del enfoque DFD s ic ió n d e lo s a r c h iv o s a l id e n t if ic a r lo s c a m p o s q u e
tradicional, sin embargo, la descomposición se detiene e s tá n in c lu id o s e n c a d a a r c h iv o .
en el nivel de un proceso de negocio elemental, en lugar
• C a m p o s : d e f in e lo s c a m p o s d e l d is e ñ o ( e l d ic c io n a
de proseguir hasta el nivel de procesos atómicos.
r io d e d a to s ).
En el contexto C/S, se puede definir un proceso ele
m ental de negocios (PEN) com o un cierto conjunto de • R e la c io n e s e n tr e a r c h iv o s : id e n t i f i c a n lo s a r c h iv o s
tareas que se llevan a cabo sin interrupción por parte r e la c io n a d o s q u e s e p u e d e n u n i r p a r a c r e a r v is t a s

de un usuario en los centros cliente. Estas tareas o bien ló g ic a s o c o n s u lt a s .
se realizan en su totalidad, o bien no se realizan en • V a lid a c ió n d e r e la c io n e s : id e n t i f i c a e l t i p o d e r e la
absoluto. c io n e s e n tr e a r c h iv o s o e n tr e a r c h iv o s y c a m p o s q u e
El diagram a entidad relación adopta tam bién un s e u t ilic e n p a r la v a lid a c ió n .
papel m ás im portante. Sigue utilizándose para d es • T ip o s d e c a m p o : s e u t i l i z a p a r a p e r m i t i r la h e r e n c ia
com poner las áreas de datos tem áticas (de alm acenes d e c a r a c te r ís tic a s d e c a m p o s p r o c e d e n te s d e s u p e re n -
de datos) de los D FD con objeto de estab le cer una la c e s d e l c a m p o ( p o r e je m p lo , fe c h a , t e x t o , n ú m e r o ,
visión de alto nivel de la base de datos que haya que v a lo r , p r e c io ) .
im plem entar em pleando un SGBDR. Su nuevo papel
• T i p o d e d a t o s : la s c a r a c t e r í s t i c a s d e l o s d a t o s c o n t e
consiste en proporcionar la estructura para definir obje
n id o s e n e l c a m p o .
tos de negocios de alto nivel (Sección 28.4.3).
En lugar de servir com o herram ientas para una des • T ip o d e a r c h iv o : s e u t ili z a p a r a id e n t if ic a r c u a lq u ie r a
com posición funcional, el diagram a de estructuras se d e la s u b i c a c i o n e s d e l a r c h i v o .

utiliza ahora com o diagram a de ensam blaje, con obje • F u n c ió n d e l c a m p o : c la v e , c la v e e x t e r n a , a t r ib u to ,
to de m ostrar los com ponentes im plicados en la solu c a m p o v ir t u a l, c a m p o d e r iv a d o , e tc .
ción de algún procedim iento de negocios elem ental. • V a lo r e s p e r m it id o s : id e n t if ic a lo s v a lo r e s p e r m it id o s
Estos com ponentes, que constan de objetos de inter p a r a lo s c a m p o s d e t i p o d e e s ta d o .
faz, objetos de aplicación y objetos de bases de datos,
• R e g la s d e n e g o c io s : r e g la s p a r a e d it a r , c a lc u la r c a m
establecen la form a en la que se van a procesar los
p o s d e r iv a d o s , e tc .
datos.
28.12.3. Diseño de b ases de datos

El diseño de bases de datos se utiliza para definir y te datos en una base de datos
www.FreeLibros.org
después para especificar la estructura de los objetos p ú ; : ¡lar el significado subyacente y la
de negocios que se em plean en el sistem a cliente/ser ¡ É N p f n te datos de forma eficaz y correcta
vidor. El análisis necesario para identificar los obje
514
CAPÍTULO 28 I NGENI ERÍ A DEL S OF TWARE DEL C O M E R C I O E L E C T R Ó N I C O CLI ENTE/ S ERVI DOR
A medida que las arquitecturasC/S se han ido hacien que van más allá del alcance de este libro. El lector inte
do más frecuentes, la tendencia hacia una gestión de resado puede consultar [BR091], [BER92], [VAS93] y
datos distribuida se ha visto acelerada. En los sistemas [ORF99] para una descripción más extensa.
C / S que implementan este enfoque, el componente de
gestiónde datos reside tanto en el cliente como en el ser
vidor. En el contexto del diseño de bases de datos, un
problema fundamental es la distribución de datos. Esto
es, jcómo se distribuyen los datos entre el cliente y el
servidor y cómo se dispersan entre los nudos de la red?
Un sistema de gestión de bases de datos relaciona1
(SGBDR)hace fácil el acceso a datos distribuidosmedian
te el uso del lenguaje de consultaestructurado(SQL). La Objetos
ventaja de SQL en una estructuraC/S es que «no requie de aplicación
re navegar» [BER92], En un SGBDR, los tipos de datos (Componentes) i
seespecificanempleando SQL, pero no se requiere infor
mación de navegación. Por supuesto, la implicación de
esto es que SGBDR debe ser suficientemente sofisticado F IG U R A 28.7. Notación de diagrama de estructura
paramantener la ubicación de todos los datos y tiene que para componentes C/S.
ser capaz de definir la mejor ruta hasta ella. En sistemas
de bases de datos menos sofisticados, una solicitud de 28.12.4. V is ió n g e n e r a l d e u n e n f o q u e d e d i s e ñ o
datos debe indicar a qué hay que acceder y dónde se
encuentra. Si el software de aplicación debe mantener la Porter [POR95] sugiere un conjunto de pasos para dise
información de navegación, entonces la gestión de datos ñar un proceso elemental de negocio que combine ele
se vuelve mucho más complicada por los sistemas C/S. mentos de diseño convencional con elementos de
diseño orientado a objetos. Se supone que se ha desa
¿Qué opciones existen para ' rrollado un modelo de requisitos que defina los obje
• distribuir datos dentro de un

sistema C /S?
Es preciso tener en cuenta que también están dispo

tos de negocio, y que se ha refinado ya antes de
comenzar el diseño de los procesos elementales de
negocio. Entonces, se utilizan los pasos siguientes para
derivar el diseño:
nibles para el diseñador [BER92] otras técnicas para la
distribución y gestión de datos: 1. Para cada proceso elemental de negocio, se identifi
can los archivos creados, actualizados, borrados o
Extracción manual. Se permite al usuario copiar referenciados
manualmente l o s datos adecuados de un servidor a un 2. Se utilizan los archivos identificados en el paso 1
cliente. Este enfoque resulta útil cuando el usuario como base para definir componentes u objetos.
requiere unos datos estáticos y cuando se puede dejar 3 . Para cada componente, se recuperan las reglas de
el control de la estación en manos del usuario. negocio y otra información de objetos de negocio
Instantánea. Esta técnica automatiza la extracción que se haya determinado para el archivo relevante.
manual al especificar una «instantánea»de los datos que 4. Se determinan las reglas que son relevantes para el
deberán de transferirse desde un cliente hasta un servi proceso y se descomponen las reglas hasta llegar al
dor a intervalos predefinidos. Este enfoque es Útil para nivel de métodos.
distribuir unos datos relativamente estáticos que sola
5 . Según sea necesario, se definen los componentes
mente requieran actualizaciones infrecuentes.
adicionales que se requieren para implementar los
Duplicación. Se puede utilizar esta técnica cuando métodos.
es preciso mantener múltiples copias de los datos en dis
tintos lugares (por ejemplo, servidores distintos o clien Porter [POR95] sugiere una notación especializada
tes y servidores). En este caso, el nivel de complejidad de diagramas de estructura (Fig. 28.7) para representar
se incrementa porque la consistencia de los datos, las la estructura de componentes de un proceso elemental
actualizaciones,la seguridad y el procesamiento deben de negocio. Sin embargo, se utiliza una simbología dife
de coordinarse entre los múltiples lugares. rente para que el diagrama se ajuste a la naturaleza orien
Fragmentación. En este enfoque, la base de datos tada a objetos del software C/S. En la figura, se
del sistema se fragmenta entremúltiples máquinas.Aun- encuentran cinco símbolos distintos:
que resulta intrigante en teoría, la fragmentación es Objeto de interfaz. Este tipo de componente, que
excepcionalmente difícil de implementar y hasta el también se denomina componente de interacción/pre
www.FreeLibros.org
momento no es frecuente encontrarla. sentación c o n e l u s u a r i o , se construye típicamente en
El diseño de bases de datos, y más específicamente, un único archivo o bien otros archivos relacionados que
el diseñode bases de datos para sistemas C/S sontemas se hayan unido mediante una consulta. Incluye méto-
515
dos para dar formato a la interfaz IGU y también la Asociación de datos. Cuandoun objeto invoca a otro
lógica de aplicación residente en el cliente, junto con objeto independiente, se pasa un mensaje entre dos obje
los controles de la interfaz. También incluye sentencias tos. El símbolo de asociación de datos se utiliza para
incrustadas de SQL, que especifican el procesamiento denotar este hecho.
de la base de datos efectuado en el archivoprimario con A sociación d e c o n tro l. Cuando un objeto invoca a
respecto al cual se haya construido la interfaz. Si la otro objeto independiente y no se pasan entre los dos
lógica de aplicación asociada normalmente a un objeto objetos, se utiliza un símbolo de asociación de control.
de interfaz se implementa en un servidor, típicamente
mediante el uso de herramientas de software interme
dio, entonces la lógica de aplicación que funcione en el 28.12.5. Ite r a c ió n d e l d is e ñ o d e p ro c e s o s
servidor deberá de identificarsecomo un objeto de apli El repositorio de diseño (Sección 28.4.3), que se utili
cación por separado. za para representar objetos de negocio, se emplea tam
O b je to de base d e d ato s. Este tipo de componentes bién para representar objetos de interfaz, de aplicación
se utiliza para identificar el procesamiento de bases de y de base de datos. Obsérvese que se han identificado
datos tal como la creación o selección de registros que las entidades siguientes:
esté basada en un archivo distinto del archivo primario • Métodos: describen cómo hay que implementar una
en el cual se haya construido el objeto de interfaz. Es regla de negocio.
preciso tener en cuenta que si el archivo primario con « Procesos elementales:definen los procesos elementa
respecto al cual se construyeel objeto de interfaz se pro les de negocio identificadosen el modelo de análisis.
cesa de manera distinta, entonces se puede utilizar un • Enlaceprocesolcomponente: identifica a los com
segundo conjunto de sentencias SQL para recuperar un
archivo en una secuencia alternativa. La técnica de pro ponentes que forman la solución de un proceso ele
cesamiento del segundo archivo debería identificarse mental de negocio.
• Componentes: describe los componentes mostrados
por separado en el diagrama de estructura, en forma de
un objeto de base de datos por separado. en el diagrama de estructura.
« Enlace reglade negocioslcornponente: identifican a
O b je to de aplicación. E s utilizado por un objeto de
interfaz,bien por un objeto de base de datos, y este com los componentes que son significativos para la imple-
ponente será invocadobien por un activadorde una base mentación de una determinada regla de negocio.
de datos, o por una llamada a procedimientos remotos. Si se implementa un repositorio utilizando un
También se puede emplear para identificar la lógica de SGBDR, el diseñador tendrá acceso a una herramienta
negocios que normalmente se asocia al procesamiento de diseño muy Útil que proporciona informes que sir
de interfaz que ha sido trasladado al servidor para su ven de ayuda tanto para la construcción como para el
funcionamiento. futuro mantenimiento del sistema C/S.
28.13 PROBLEMAS DE LAS PRUEBASs
La naturaleza distribuida de los sistemas cliente/ser

vidor planteaun conjunto de problemas específicospara
los probadores de software. Binder [BIN92] sugiere las Referencia W é b f^
siguientes zonas de interés:
Se presentan recursos e información útil
• Consideraciones del IGU de cliente. sobre comprobaciones C /S en la dirección
• Consideraciones del entorno destino y de la diversi www.icon-stl.net/-djmosley /
dad de plataformas.
La estrategia y las tácticas asociadas a la comproba
• Consideraciones de bases de datos distribuidas (inclu
yendo datos duplicados). ción C/S deben diseñarse de tai modo que se Per™ ta
abordar todos v cada uno de los problemas anteriores.
• Consideraciones de procesamiento distribuido(inclu
yendo procesos duplicados). 28.13.1. E s t r a t e g ia g e n e r a l d e p r u e b a s C/S
• Entornos destino que no son robustos. En general, las pruebas de software cliente/servidor se
• Relaciones de rendimiento no lineales. produce en tres niveles diferentes: (1) las aplicaciones
www.FreeLibros.org
5 Esta sección es una versión m uy abreviada y adaptada de un a r
tículo escrito por Daniel Mosley [MOS96] (utilizado con perm iso del
au to r). En [MOS99] se puede e ncontrar una versión actu alizada y
am pliada.
516
CAPÍTULO 28 I N GE NI E R ÍA DEL S OF TWARE DEL C O M E R C I O E L E C T R Ó N I C O C L IE NT E/ S ER V ID OR
de cliente individuales se prueban de modo «desconec c a m a s g a

tado» (el funcionam iento del servidor y de la red sub Los técnicos de elicilación de requisitos y los cosos
yacente no se consideran); (2) las aplicaciones de prácticos de estudio se traten en el Capítulo 11.
software de cliente y del servidor asociado se prueban
al unísono, pero no se ejercitanespecíficam entelas ope
raciones de red; (3) se prueba la arquitectura completa Para desarrollar el perfil operativo, es preciso deri
de C/S, incluyendo el rendim iento y funcionam iento de var un conjunto de escenarios de usuario [BIN95], que
la red. sea similar a los casos prácticos de estudio tratados en
A un cuando se efectúen muchas clases distintas de este libro. Cada escenario abarca quién, dónde, qué y
pruebas en cada uno de los niveles de detalle anterio por qué. Esto es, quién es el usuario, dónde (en la arqui
res, es frecuente encontrar los siguientes enfoques de tectura física) se produce la interacción con el sistem a,
pruebas para aplicaciones C/S: cuál es la transacción, y por qué ha sucedido. Se pue
den derivar los escenarios durante las técnicas de obten
Pruebas defunción de aplicación. Se prueba la fun ción de requisitos o a través de discusiones m enos
cionalidad de las aplicaciones cliente utilizando los formales con los usuarios finales. Sin embargo, el resul
métodos descritos en el Capítulo 17. En esencia, la apli tado debería ser el m ismo. C ada escenario debe p ro
cación se prueba en solitario en un intento de descubrir porcionar una indicación de las funciones del sistem a
errores de su funcionamiento. que se necesitarán para dar servicio a un usuario con
creto; el orden en que serán necesarias esas funciones,
¿Qué tipos de los tiempos y respuestas que se esperan, y la frecuen
• comprobaciones se realizan
para los sistemas C /S?
cia con la que se utilizará cada una de estas funciones.
Entonces se com binan estos datos (para todos los usua
rios) para crear el perfil operativo.
Pruebas de servidor. Se prueban la coordinación y La estrategia para probar arquitecturas C/S es aná
las funciones de gestión de datos del servidor. También loga a la estrategia de pruebas para sistemas basados en
se considera el rendim iento del servidor (tiempo de res software que se describían en el Capítulo 18. La com
puesta y trasvase de datos en general). probación comienza por com probar al por menor. Esto
Pruebas de bases de datos. Se prueba la precisión e es, se com prueba una única aplicación de cliente. La
integridad de los datos almacenados en el servidor. Se integración de los clientes, del servidor y de la red se
examinan las transacciones enviadas por las aplicacio irá probando progresivamente. Finalmente, se prueba
nes cliente para asegurar que los datos se alm acenen, todo el sistema com o entidad operativa. La prueba tra
actualicen y recuperen adecuadam ente. Tam bién se dicional visualiza la integración de m ódulos para sub
prueba el archivado. sistem as/sistem as y su prueba (Capítulo 18) com o un
Pruebas de transacciones. Se crea una serie de prue proceso descendente, ascendente o alguna variación de
bas adecuada para comprobar que todas las clases de tran los dos anteriores. La integración de m ódulos en el desa
sacciones se procesen de acuerdo con los requisitos. Las rrollo C/S puede tener algunos aspectos ascendentes o
transacciones hacen especial hincapié en la corrección descendentes, pero la integración en proyectos C/S tien
de procesamiento y también en los temas de rendimiento de m ás hacia el desarrollo paralelo y hacia la integra
(por ejemplo, tiem po de procesam iento de transacciones ción de m ódulos en todos los niveles de diseño. P or
y comprobación de volúm enes de transacciones). tanto, la prueba de integración en proyectos C/S se efec
Pruebas de comunicaciones a través de la red. Estas túa a veces del mejor m odo posible empleando una apro
xim ación no incremental o del tipo «big bang».
pruebas verifican que la com unicación entre los nudos
de la red se produzca correctamente, y que el paso de
mensaje, las transacciones y el tráfico de red relacio
nado tenga lugar sin errores. También se pueden efec
O K p<
es un área
tuar pruebas de seguridad de la red com o parte de esta pfRíWtos comunes se encuentran
actividad de prueba. tratónoles y los sistemas
llá e n te /s e rY id o r.
■
Para llevar a cabo estos enfoques de pruebas, M usa
[MUS93] recom ienda el desarrollo de perfiles operati
vos derivados de escenarios cliente/servidor. Un perfil
operativo indica la form a en que los distintos tipos de El hecho de que el sistema no se esté construyendo
usuarios interactúancon el sistema C/S. Esto es, los per para utilizar un hardw are y un software especificado
files proporcionan un «patrón de uso» que se puede apli con anterioridad tiene su im pacto sobre la com proba
car cuando se diseñan y ejecutan las pruebas. Por ción del sistema. L a naturaleza m ultiplataform a en red
www.FreeLibros.org
ejemplo, para un determ inado tipo de usuarios, ¿qué de los sistemas C/S requiere que se preste bastante m ás
porcentaje de las transacciones serán consultas? ¿Actua atención a la prueba de configuraciones y a la prueba
lizaciones? ¿Pedidos? de compatibilidades.
517
L a d o c t r in a d e p r u e b a d e c o n f ig u r a c io n e s im p o n e la fo r m a s . A d e m á s , la c o m p r o b a c ió n d e b e e x p lo r a r u n
p r u e b a d e l s is t e m a e n t o d o s lo s e n t o r n o s c o n o c id o s d e e le v a d o n ú m e r o d e r u ta s ló g ic a s , p o r q u e la I G U c re a ,
h a r d w a r e y s o ftw a r e e n lo s c u a le s v a y a a f u n c io n a r . L a m a n ip u la y m o d i f ic a u n a a m p lia g a m a d e o b je t o s g rá
p r u e b a d e c o m p a t ib ilid a d a s e g u ra u n a in t e r f a z f u n c io fic o s . L a c o m p r o b a c ió n se v e c o m p lic a d a a u n m á s p o r
n a lm e n t e c o n s is te n te e n tr e p la t a f o r m a s d e s o f t w a r e y q u e lo s o b je t o s p u e d e n e s ta r p r e s e n te s o a u s e n te s ,
h a r d w a r e . P o r e je m p lo , la in t e r f a z d e v e n ta n a s p u e d e s e r p u e d e n e x is t ir d u r a n te u n c ie r to p e r ío d o d e tie m p o , y
v is u a lm e n te d is t in t a d e p e n d ie n d o d e l e n to r n o d e im p le - p u e d e n a p a r e c e r e n c u a lq u ie r lu g a r d e l e s c r it o r io .
m e n ta c ió n , p e r o lo s m is m o s c o m p o r t a m ie n t o s b á s ic o s E s to s ig n ific a q u e e l e n fo q u e t r a d ic io n a l d e c a p tu
d e l u s u a r io d e b e r í a n d a r lu g a r a lo s m is m o s r e s u lta d o s r a / r e p r o d u c c ió n p a r a c o m p r o b a r in te r fa c e s c o n v e n c io
in d e p e n d ie n te m e n te d e l e s tá n d a r d e in t e r f a z d e c lie n te . n a le s b a s a d a s e n c a r a c te r e s d e b e s e r m o d if ic a d o p a ra
q u e p u e d a m a n e ja r la s c o m p le jid a d e s d e u n e n to r n o
I G U . H a a p a r e c id o u n a v a r ia c ió n f u n c io n a l d e l p a r a
d ig m a d e c a p tu r a /r e p r o d u c c ió n d e n o m in a d o c a p tu ra /
r e p r o d u c c i ó n e s t r u c t u r a d a [ F A R 9 3 ] p a r a e f e c t u a r la
p r u e b a d e la IG U .
L a c a p t u r a / r e p r o d u c c i ó n t r a d i c i o n a l r e g i s t r a la s
EspecificacióndepruebasC/S
e n t r a d a s t a l e s c o m o l a s t e c l a s p u l s a d a s y la s s a l i d a s
t a le s c o m o im á g e n e s d e p a n t a lla q u e s e a lm a c e n a n
28.13.2. T á c tic a d e p r u e b a s C /S p a r a c o m p r o b a c io n e s p o s te r io r e s . L a c a p tu r a /r e p r o
A u n c u a n d o e l s is t e m a C /S n o s e h a y a im p le m e n t a d o d u c c ió n e s tr u c tu r a d a e s tá b a s a d a e n u n a v is ió n in
e m p le a n d o t e c n o lo g í a o r ie n t a d a a o b je t o s , la s t é c n i t e r n a ( ló g ic a ) d e la s a c t iv id a d e s e x te r n a s . L a s
c a s d e p r u e b a s o r ie n t a d a s a o b je t o s ( C a p í t u lo 2 3 ) t ie in t e r a c c io n e s d e l p r o g r a m a d e a p lic a c ió n c o n la IG U
n e n s e n t id o p o r q u e lo s d a to s y p r o c e s o s d u p lic a d o s s e s e r e g is tr a n c o m o s u c e s o s in te r n o s , q u e s e p u e d e n
p u e d e n o r g a n iz a r e n c la s e s d e o b je t o s q u e c o m p a r t a n a lm a c e n a r e n f o r m a d e « g u io n e s » e s c r it o s e n V is u a l
u n m is m o c o n ju n t o d e p r o p ie d a d e s . U n a v e z q u e s e B a s ic d e M i c r o s o f t , e n u n a d e la s v a r ia n t e s d e C , o
h a y a n d e r iv a d o lo s c a s o s p r á c t ic o s p a r a u n a c la s e d e e n e l le n g u a je p a te n ta d o d e l f a b r ic a n t e . L a s h e r r a
o b je t o s ( o s u e q u iv a le n t e e n u n s is t e m a d e s a r r o lla d o m i e n t a s q u e e j e r c i t a n l a s I G U s n o a b a r c a n la s v a l i
c o n v e n c io n a lm e n te ) , e s to s c a s o s d e p r u e b a d e b e r ía n d a c i o n e s d e d a t o s t r a d i c i o n a l e s n i t a m p o c o la s
r e s u l t a r a p lic a b le s e n g e n e r a l a t o d a s la s in s t a n c ia s d e n e c e s id a d e s d e c o m p r o b a c ió n d e r u t a s . L o s m é to d o s
e s a c la s e . d e c o m p r o b a c ió n d e c a ja b la n c a - y c a ja n e g r a d e s c r i
E l p u n t o d e v is t a O O e s e s p e c ia lm e n t e v a lio s o c u a n to s e n e l C a p í t u lo 1 7 s o n a p lic a b le s e n m u c h o s c a s o s ,
d o s e c o n s id e r a la in t e r f a z g r á f ic a d e u s u a r io d e lo s y la s e s t r a t e g ia s o r ie n t a d a s a o b je t o s e s p e c ia le s q u e
s is t e m a s C /S m o d e r n o s . L a I G U e s in h e r e n t e m e n t e s e p r e s e n t a b a n e n e l C a p í t u l o 23 son a d e c u a d a s t a n
o r ie n t a d a a o b je t o s , y s e a p a r t a d e la s in t e r f a c e s t r a d i to p a r a e l s o ftw a r e d e c lie n te c o m o p a r a e l s o ftw a r e
c io n a le s p o r q u e tie n e q u e f u n c io n a r e n m u c h a s p la ta d e s e r v id o r .
A u n c u a n d o lo s s is t e m a s c lie n t e / s e r v id o r p u e d e n a d o p L a s a r q u it e c t u r a s d e a g e n t e d e s o li c it u d d e o b je t o s
t a r u n o o m á s d e lo s m o d e lo s d e p r o c e s o s d e s o ftw a r e s i r v e n d e a p o y o p a r a l o s d i s e ñ o s C / S e n l o s c u a l e s lo s
y m u c h o s d e lo s m é to d o s d e a n á lis is , d is e ñ o y c o m o b je t o s c lie n t e e n v í a n m e n s a je s a lo s o b je t o s s e r v id o r .
p r o b a c i ó n d e s c r i t o s a n t e r i o r m e n t e e n e s t e l i b r o , la s E l e s tá n d a r C O R B A h a c e u s o d e u n le n g u a je d e d e fín i-
c a r a c t e r í s t ic a s d e a r q u it e c t u r a s e s p e c ia le s d e C /S r e q u ie c ió n d e in t e r f a z , y lo s r e p o s it o r io s d e in t e r f a z g e s tio n a n
r e n u n a p e r s o n a liz a c ió n d e l s o ftw a r e d e in g e n ie r í a d e l la s s o l i c i t u d e s d e o b j e t o s i n d e p e n d i e n t e m e n t e d e s u u b i
s o ftw a r e . E n g e n e r a l, e l m o d e lo d e p r o c e s o d e l s o ftw a r e c a c ió n d e n tr o d e la r e d .
q u e s e a p lic a a lo s s is t e m a s C /S t ie n e u n a n a t u r a le z a e v o - E l a n á lis is y e l d is e ñ o d e s is t e m a s c lie n t e / s e r v id o r
lu t iv a , y lo s m é to d o s t é c n ic o s s u e le n te n d e r a e n fo q u e s h a c e n u s o d e d ia g r a m a s d e f l u jo d e d a to s y d e e n ti
o r ie n t a d o s a o b je t o s . E l d e s a r r o lla d o r d e b e d e s c r ib ir a q u e d a d e s y r e la c io n e s , d ia g r a m a s d e e s t r u c t u r a m o d if i
ll o s o b je t o s q u e s e p r o d u z c a n e n la im p le m e n t a c ió n d e lo s c a d o s , y o tr a s n o ta c io n e s q u e s e e n c u e n t r a n e n e l
c o m p o n e n te s d e in te r a c c ió n /r e p r e s e n ta c ió n c o n e l u s u a d e s a r r o llo d e a p lic a c io n e s c o n v e n c io n a le s . E s p r e c i
r io , d e b a s e d e d a to s y d e a p lic a c ió n . L o s o b je t o s d e f i s o m o d i f i c a r la s e s t r a t e g i a s d e c o m p r o b a c i ó n p a r a a d e
n id o s p a r a e s to s c o m p o n e n t e s d e b e r í a n a s ig n a r s e b ie n c u a r la s a la s c o m p r o b a c i o n e s q u e e x a m in a n la
www.FreeLibros.org
a la m á q u in a , o b ie n a la m á q u in a s e r v id o r , y s e p u e c o m u n ic a c ió n a tr a v é s d e la r e d y e l ju e g o e n tre e l
d e n v in c u la r a tr a v é s d e u n d is t r ib u id o r d e s o lic it u d e s s o f t w a r e q u e r e s id e e n e l c lie n t e y a q u e l q u e r e s id e e n
d e o b je t o s . e l s e r v id o r .
518
CAPITULO 28 I NGENI ERI A DEL S O F T WA R E DEL C O M E R C I O E L E C T R Ó N I C O CLI E NT E/ S ERVI DOR
[BAS98] Bass, L., P. Clemens y R. Kazman, Software Archi- [MOS99] Mosley, D., Client Server Software Testing on the
tecture in Practice, Addison-Wesley, 1998. Desk Topam lthe Web, Prentice-I Iall. 1999.
[BER92] Berson, A., ClientlServer Architecture, McGraw- [MUS93] Musa, J., «Operational Profilesin Software Relia-
Hill, 1992. bility Engineering», IEEE Software, Marzo de 1993,pp.
14-32.
[BIN92] Binder, R., «A CASE-based Systems Engineering
[ORF99] Orfali, R., D, Harkey y J. Edwards, Essential
Approachto Client-Server Development», CASE Trends,
ClientlServer Survival Guide, 3.a ed., Wiley, 1999.
1992.
[PAU95] L. G. Paul, «Client/Server Deployment», Compu-
[BIN95] Binder, R., «Scenario-Based Testingfor Client Ser terworld, 18de Diciembre, 1995.
ver systems», Software Development, vol. 3, n.2 8, Agos
to de 1995,pp. 43-49. [POR94] Porter, J., O-DES Design M anual, Fairfield Uni-
versity, 1994.
[BR091] Brown, A.W., Object-Oriented Databases, [POR95] Porter, J., Synon Developer’s Guide, McGraw-Hill,
McGraw-Hill, 1991. 1995. ‘
[FAR93] Farley,K.J., «Software Testing For Windows Deve- [REE97] Reece, G., JBDC and Java, O ’Reilly, 1997.
lopers»,Data BasedAdvisor, Noviembre de 1993,pp. 45 [S1E99] Siegel, J., CORBA 3 Fundamentáis and Program
46, 50-52. ming, Wiley, 1999.
[HOQ99] Hoque, R., CO RBAfor Real Programmers, Aca- [VAS93] Vaskevitch, D., ClientlServer Strategies, IDG
demic Press/Morgan Kaufmann, 1999. Books. 1993.
28.1. Empleando publicaciones comerciales o recursos e Inter Wide Web, y se pueden hacer pedidos a través de correo elec
net de información de fondo, defina un conjunto de criterios trónico, mediante el sitio Web y también por teléfono o fax.
para evaluar herramientas para la ingeniena del software C/S. Se construirá un sistema cliente/servidor para prestar su apo
yo al procesamiento de pedidos en el sitio de la compañía.
28.2. Sugiera cinco aplicacionesen las cuales un servidor pesa
Defina un conjunto de objetos de alto nivel que fueran nece
do parezca una estrategia de diseño adecuada.
sarios para el sistema de procesamiento de pedidos, y organi
28.3. Sugieracinco aplicacionesen las cuales un cliente pesa ce estos objetos en tres categorías de componentes: la
do parezca ser una estrategia de diseño adecuada. presentación con el usuario, la base de datos y la aplicación.
28.4. Efectúe una investigación sobre los Últimos delitos come 2 8.8. Formule reglas de negocio para establecercuándo se pue
tidos en Intemet y describa cómo la tecnología de seguridad de efectuar un envío si el pago se efectúa mediante tarjeta de
apuntada en este capítulo podría haberla evitado. crédito, con respecto al sistema descrito en el Problema 28.7.
28.5. Describa cómo se podría estructurarun sistema de reser Añada reglas adicionales si el pago se efectúamediante cheque.
vas en unas líneas aéreas como un sistema cliente/servidor. 2 8.9. Desarrolle un diagrama de transición de estados (Capí
28.6. Investigue los últimos avances en software para traba tulo 12) que defina los sucesos y estados que resultarían visi
jo en grupo y desarrolle una breve presentación para la clase. bles para un dependiente de entrada de pedidos que trabajase
El profesor puede asignar una función específica a los distin en un PC cliente en la división de ventas por catálogo (P ro
tos participantes. blema 28.7).
28.7. Una compañía va a establecer una nueva división de 2 8 .1 0 . Ofrezca ejemplos de tres o cuatro mensajes que pudie
ventas por catálogo para vender mercancías de uso frecuente ran dar lugar a una solicitud de un método de cliente mante
y en exteriores. El catálogo electrónico se publicará en la World nido en el servidor.
Q IR fiS LECTURAS Y. FPESfES..PE 1H£QRÜ&CIÓS —— .úÉife
Aun cuando los métodos básicos de análisis y diseño para nahan (Developing Client-Server Applications, IDG Books
sistemas cliente/servidor son bastante parecidos a los siste Worldwide, 1999) abarca un amplio abanico de temas C/S.
mas OO convencionales, se requieren técnicas y conoci A un nivel más sofisticado, Orfali y sus colaboradores
mientos especializados. Lowe y Helda han escrito unas [ORF99], y Linthicum (Guide to ClientlServer and Intranet
introducciones valiosas a los conceptos básicos (ClientlSer Development, Wiley, 1997) proporcionan las líneas genera
www.FreeLibros.org
ver Computingfor Dummies, 3.a ed., IDG Books Worldwide, les detalladas para aplicaciones C/S. Berson (ClientlServer
1999), al igual que Zantinge y Adriaans (ManagingClientlSer- Architecture, 2.a ed., McGraw-Hill, 1996)trata temas de arqui
ver, Addison-Wesley, 1997). En un nivel intermedio, McCla- tectura y componentes.
519
En los últimos años las computadorasde redes se han con dimiento del software y los aplican a la arquitectura y al dise
vertido en un tema tecnológicocandente (y una estrategiaarries- ñ o de los sistemas distribuidos. Heinckiens y Loomies (B uil-
gada de negocios). Sinclair y Merkow ( T h in C lie n ts C le a r ly d in g S c a la b le D a ta b a s e A p p li c a ti o n s : O b je c t- O r ie n te d
E x p la in e d , MorganKaufmannPublishers, 1999), Friedrichsy D e s ig n , A r c h ite c tu r e s , a n d I'm p le m e n ta tio n s , Addison-Wes
Jubin (J a v a T h in - C lie n tP r o g r a m m in g fo r a N e tW o r k C o m p u - ley, 1998) dan importancia al diseño de bases de datos en su
tin g E n v ir o n m e n t, Prentice-Hall, 1999), Dewire (T h in C lie n ts , guía para construir aplicaciones cliente/servidor. Ligón
McGraw-Hill, 1998)y Kanter (U n d e rsta n d in g T h in -C lie n tlS e r- ( C l ie n t lS e r v e r C o m r n u n ic u tio n s S e r v ic e s : A G u i d e f o r the
v e r C o rn p u tin g , Microsoft Press, 1998)proporcionan una guía A p p lic a tio n s D e v e lo p e r , McGraw-Hill, 1997) tiene en cuen
valiosa de cómo diseñar, construir, hacer uso y apoyar siste ta una gran variedad de temas de comunicación relacionados
mas cliente ligeros (delgados). entre los que se incluyen TCP/IP, ATM, EDI, CORBA, men
Empezando con el modelado de sucesos de negocios, sajes y encriptación. Schneberger ( C l ie n t lS e r v e r S o ftw a r e
Ruble (P r a c tic a 1 A n a ly s is a n d D e s i g n f o r C lie n tlS e r v e r a n d M a in te n a n c e , McGraw-Hill, 1997) presenta un marco de tra
G U I S y s te m s , 1997)proporciona un estudio en profundidad bajo para controlar los costes de mantenimiento de software
de las técnicas para el análisis y diseño de sistemas C/S. Los C/S y para optimizar el apoyo al usuario.
libros de Goldman, Rawles y Mariga ( C lie n tlS e r v e r I n f o r Literalmente cientos de libros abarcan el desarrollo de sis
m a tio n S y ste m s: A B u s in e s s -O r ie n te d A p p r o u c h , Wiley, 1999), temas C/S específicos del vendedor. La siguiente relación
Shan, Earle y Lenzi (E n te r p r is e C o m p u tin g W ith O b je c ts : representa un pequeño muestreo:
F r o m C lie n tlS e r v e r E n v ir o n m e n ts to th e I n te r n e t, Addison-
Anderson, G.W., Client/Server Database Design With
Wesley, 1997) y Gold-Berstein y Marca ( D e s ig n in g E n te r Sybase: A High-Performance and Fine-Tuning Guide,
p r is e C lie n tlS e r v e r S y s te m s , Prentice-Hall, 1997) tienen en McGraw-Hill, 1997.
consideración los sistemas C/S en un contexto más amplio Barlotta,M. J., Distributed ApplicationDevelopment With
de empresa. Powerbuilder 6, Manning Publications Company, 1998.
Existe un grupo de libros que estudian la seguridad en Bates, R.J., Hands-On Client/Server Intemetworking,
redes; a continuación se proporciona una muestra: McGraw-Hill, 1997. '
Stallings, W., C r y p to lo g y a n d N e tw o r k S e c u r ity , Prenti Mahmoud, Q.H., Distributed Programming with java,
ce-Hall, 1998. Manning Publications Company, 1998.
Gralla, P., T h e C o m p le te I d io ts G u id e to P r o te c tin g Y our- Orfali, R., y Harkey, Client/Server Programming with
s e l f O n lin e , Que, 1999. JavaBeans, Wiley, 1999.
Ghosh, A. K., E -c o r n rn e r c e S e c u r it y : W e a k L in k s , B e s t Sankar, K., Building Internet Client/Server Systems,
D e fe n s e s , John Wiley, 1998. McGraw-Hill, 1999.
Atkins, D. T., Sheldeny T. Petru, I n te r n e t S e c u r ity : P ro - Mosley [MOS99] y Boume (T e s tin g C l ie n t lS e r v e r S y s
fe s s i o n a l R e fe r e n c e , New Riders Publishing, 1997. McGraw-Hill, 1997) han escrito libros de guía detalla
te m s ,
Bemstein, T., A.B. Bhimani, E. Schultzy C. Síegel, I n te r dos para pruebas C/S. Ambos autoresproporcionanun estudio
n e t S e c u r it y f o r B u s in e s s , John Wiley, 1998. en profundidad de las estrategias de comprobación, tácticas
Garfinkel, S .,y G . Spafford, W e b S e c u r ity a n d C o m m e r - y herramientas.
ce, O . Reilly, 1997.
Una gran variedad de fuentes de información sobre inge
niería del software cliente/servidor está disponible en Inter
Tiwana, A., W eb S e c u r ity , Digital Press, 1999.
net. Una lista actualizada de referencias a sitios (páginas) web
Loosely y Douglas ( H ig h - P e r fo r m a n c e C lie n tlS e r v e r , que son relevantes para sistemas C/S se pueden encontraren
Wiley, 1997) explican los principios de la ingeniería de ren http://www.pressman5.com.
C A P ÍT U L O
29 INGENIERÍA WEB
A W o r ld W id e W e b e In t e r n e t h a n in t r o d u c id o a la p o b la c ió n e n g e n e r a l e n e l m u n d o d e
L la in f o r m á t ic a . C o m p r a m o s fo n d o s d e in v e r s ió n c o le c tiv o s y a c c io n e s , d e s c a r g a m o s
m ú s ic a , v e m o s p e lí c u la s , o b te n e m o s a s e s o r a m ie n to m é d ic o , h a c e m o s r e s e r v a s d e h a b i
t a c i o n e s e n h o t e l e s , v e n d e m o s a r t í c u l o s p e r s o n a l e s , p l a n i f i c a m o s v u e l o s e n lí n e a s a é r e a s , c o n
c e m o s g e n te , h a c e m o s g e s tio n e s b a n c a r ia s , r e c ib im o s c u r s o s u n iv e r s it a r io s , h a c e m o s la c o m p r a
-e s d e c i r , e n e l m u n d o v i r t u a l s e p u e d e h a c e r t o d o l o q u e s e n e c e s it e — . S e p u e d e d e c i r q u e
I n t e r n e t y la W e b s o n lo s a v a n c e s m á s im p o r t a n t e s e n la h is t o r ia d e la in f o r m á t ic a . E s ta s t e c
n o lo g ía s in f o r m á t ic a s n o s h a n lle v a d o a to d o s n o s o tr o s a la e r a d e la in f o r m á t ic a ( c o n o t r o s
m i llo n e s d e p e r s o n a s q u ie n e s f in a lm e n t e e n t r a r á n t a m b ié n ) . D u r a n t e lo s p r im e r o s a ñ o s d e l s ig l o
v e in t iu n o e s ta s te c n o lo g í a s h a n lle g a d o c a s i a f o r m a r p a r te d e n u e s tr a v id a d ia r ia .
P a r a to d o s n o s o tr o s q u e r e c o r d a m o s u n m u n d o s in W e b , e l c r e c im ie n t o c a ó t ic o d e la t e c n o -
lo g ia t ie n e s u o r ig e n e n o t r a e r a — lo s p r im e r o s d ía s d e l s o ftw a r e — . E r a n t ie m p o s d e p o c a d i s
c ip lin a , p e r o d e e n o r m e e n t u s ia s m o y c r e a t iv id a d . E r a n t ie m p o s e n q u e lo s p r o g r a m a d o r e s a
m e n u d o e n t r a b a n e n o t r o s s is t e m a s , a lg u n a s v e c e s c o n b u e n a in t e n c ió n y o t r a s c o n m a la in t e n
c ió n . L a a c t it u d q u e p r e v a le c ía p a r e c ía s e r la d e « H a z lo r á p id a m e n te , y e n tr a e n e l c a m p o , q u e
n o s o tr o s l o lim p ia r e m o s ( y m e jo r s e r ía q u e e n te n d ie r a s lo q u e r e a lm e n te q u e r e m o s c o n s t r u ir )
c u a n d o a c tu e m o s » . ¿ L e s u e n a f a m ilia r ?
E n u n a m e s a r e d o n d a v ir t u a l p u b lic a d a e n I E E E S o f tw a r e [P R E 9 8 ] , m a n tu v e e n f ir m e m i
p o s tu r a e n r e la c ió n c o n la in g e n ie r í a d e W e b :
M e parece q u e c u alq u ier p roducto o sistem a im portante es m ereced o r d e recib ir una ingeniería. A ntes
de co m en zar a c o n stru irlas, lo m ejo r es e n ten d er el pro b lem a, d iseñ ar una solución viable, im p lem en tarla
de una m anera só lid a y c o m p ro b a rla e n profundidad. P ro b ab lem en te tam b ién se d eb erían c o n tro la r los
cam bios a m ed id a que el trab a jo vaya a vanzando, y d isp o n er de m ecanism os p ara a seg u rar la calidad del
resultado final. M uchos d e los q u e d esarro llan W ebs n o dicen lo m ism o; e llo s p ien san que su m undo es
realm ente d iferen te, y que sim plem ente no se van a ap lic ar los enfoques d e in g en iería del softw are c o n
vencionales.
V I S T A Z O R Á P I D O
¿Q ué e s? Los s is te m a s y a p lic a c io n e s ñ ía s (por ejem plo, com ercio e le c tró n i b e s. D ado q u e la s W e b A p p s e s tá n e n

(WebApps) b a sa d o s e n W eb hacen posi co), y c a d a vez e s m á s im p o rta n te l a c o n s ta n te e v o lu c ió n , d e b e n d e e s ta -
ble que una población e x ten sa d e u su a n e c e s id a d d e c o n stru ir s is te m a s f ia u i„ — „ e los m ecanism os p a r a el con
rio s fin a le s d is p o n g a n d e u n a g ra n b les, u tilizab les y a d a p ta b le s . E sta e s trol d e c o n fig u ra c io n e s, g a r a n t ía d e
v ariedad d e contenido y funcionalidad, la razó n por la q u e e s n e c e s a rio un c a lid a d y soporte continuado.
La in g en iería W eb no e s un clónicoper- enfoque d isc ip lin a d o p a ra e l d e s a rro ¿ C uál es e l producto obtenido? La
fecto de la ingeniería del softw are, pero llo d e W ebApps. e la b o ra c ió n d e u n a g ra n v a rie d a d d e
to m a p re stad o m uchos d e los concep ¿Cuáles son los paso s a s e g u i r ? Al productos de trab ajo d e in g en iería W eb
tos y principios b á sico s d e la in g en ie ig u al que c u alq u ier d iscip lin a d e in g e (por e je m p lo , m o d elo s d e a n á lis is .
ría del softw are, d a n d o im p o rtan cia a n ie ría , la in g e n ie ría W eb a p lic a. un m odelos d e d iseño, p ro ced im ien to s d e
l a s m ism a s a c tiv id a d e s té c n ic a s y de e n fo q u e g e n é ric o q u e se su a v iz a con p ru e b as). Y com o p ro d u c to fin al la
gestión. E xisten d iferen cias su tile s e n e s tra te g ia s , tá c tic a s y m étodos e s p e W ebA pp operativa.
la form a en q u e s e llev an a cabo e s ta s c ia liz a d o s. El p ro c e so d e in g e n ie ría ¿ Cómo p u e d o e s ta r seguro d e q u e
a ctiv id a d es,p e ro la filosofía prim ordial W eb com ienza con u n a form ulación del lo h e h e c h o correctam ente? A pli
e s idén tica d a d o q u e d icta un enfoque p ro b le m a q u e p a s a a re so lv e rse co n cando la s m ism as prácticas SQA q u e se
d isc ip lin a d o p a ra e l d e sa rro llo d e un la s W ebA pps. Se plan ifica el proyecto a p lic a n e n todos los p rocesos d e in g e
siste m a b a sa d o en com putadora. y s e a n a liz a n lo s re q u is ito s d e la n iería d el so ftw a re —la s revisiones téc
¿Quién lo h a c e ? Los ingenieros W eb y W ebA pp, e n to n c e s s e lle v a a c a b o el n ica s form ales v alo ran los m odelos de
los d e s a rro lla d o re s d e c o n te n id o no d ise ñ o d e in te rfa c e s a rq u ite c tó n ic o y a n á lis is y diseño— ; la s re visiones e sp e
téc n ico s c re a n la s W ebA pps. d e l n a v e g a d o r. El s is te m a se im ple- c ia liz a d a s tie n e n e n c o n sid era ció n la
¿ P o r q u é es im p o rta n te ? A m e d id a m e n ta u tiliz a n d o le n g u a je s y h e rra u s a b ilid a d y la com probación se a p li
www.FreeLibros.org
q u e lasW e b A p p s se in teg ran c a d a vez m ie n tas e sp e c ia liz a d o s a so c ia d o s con c a p a ra d escubrir erro res e n el conteni
m á s e n g ra n d e s y p e q u e ñ a s c o m p a la W eb.y entonces com ienzan la s p ru e do, fu n cio n alid ad y com patibilidad.
521
IN GE NI E RÍ A DEL SOF TW AR E . UN E N F O Q U E P R A C T I C O
Esto nos lleva a formular una pregunta clave: ¿Pue

# den aplicarse principios, conceptos y métodos de inge
•.
niería en el desarrollo de la Web? Creo que m uchos de
:H íffifc d ó n previos al diseño
ellos sí se pueden aplicar, pero su aplicación quizás
f H j f :- v d diseño previo o lo construcción,
requiera un giro algo diferente.
m í í t t í , •ó de todos las transiciones
biotecnología;portento,también
Pero, ¿qué ocurriría si estuviera equivocado?, y ¿si
Y ; Y ?: i transición.
persiste el enfoque actual y específico para ese desa
Uto» Hypfcrey rrollo de la Web? Con la ausencia de un proceso disci
plinado para sistem as basados en Web. cada vez nos
preocupa más la m anera en que nos podem os enfrentar con problem as serios para obtener éxito en el desarrollo,
empleo y «mantenimiento» de estos sistemas. En esencia, a medida que entram os en el nuevo siglo, la infraes
tructura de las aplicaciones que se están creando hoy en día puede llevam os a algo que se podría llam ar «Web
enmarañada». Esta frase connota un cúm ulo de aplicaciones basadas en Web pobremente desarrolladas y con una
probabilidad de fallo bastante alta. Y lo que es peor, a m edida que los sistemas basados en Web se van com pli
cando, un fallo en uno de ellos puede propagar y propagará problem as muy extensos en todos. Cuando ocurra esto,
la confianza en Internet se puede rom per provocando resultados irremediables. Y lo que es aún peor, puede con
ducir a una regulación gubernamental innecesaria y mal concebida, provocando daños irreparables en estas tec
nologías singulares.
Con objeto de evitar una Web enm arañada y lograr un m ayor éxito en el desarrollo y aplicación de sistemas
basados en Web complejos y a gran escala, existe una necesidad apremiante de enfoques de ingeniería W eb disci
plinada y de métodos y herram ientas nuevos para el desarrollo, em pleo y evaluación de sistemas y aplicaciones
basados en Web. Tales enfoques y técnicas deberán tener en cuenta las características especiales en el m edio nue
vo, en los entornas y escenarios operativos, y en la m ultiplicidad de perfiles de usuario im plicando todo ello un
reto adicional para el desarrollo de aplicaciones basadas en Web.
La Ingeniería Web (IWeb) está relacionada con el establecim iento y utilización de principios científicos, de
ingeniería y de gestión, y con enfoques sistemáticos y disciplinados del éxito del desarrollo, em pleo y m anteni
m iento de sistemas y aplicaciones basados en Web de alta calidad [M UR99].
29.1 IQ S ATRIBUTOS DE APIICACIOMES BASABAS EM.WEü

No hay mucho que decir con respecto al hecho de que el mundo). De forma alternativa, una aplicación se pue
los sistemas y las aplicaciones' basados en W eb (nos de ubicar en una Intranet (im plem entando la com uni
referirem os a estas como WebApps) son muy diferentes cación a través de redes de una organización) o una
de las otras categorías de software informático que se Extranet (comunicación entre redes).
tratan en el Capítulo 1. Powell resume las diferencias
básicas cuando afirma que los sistemas basados en Web
«im plican una m ezcla de publicación im presa y desa
CLAVE
rrollo de software,de marketing e inform ática,de com u
las WebApps son ¡ntensivasde red, controladas
nicaciones internas y relaciones externas, y de arte y
por el contenido y en continua evolución. Estos atributos
tecnología» [POW98]. Los atributos siguientes se van
tienen un profundo impacto dentro de laforma
a encontrar en la gran m ayoría de las WebApps2:
en que se lleva a coba la IWeb.
Intensivas de Red. Por su propia naturaleza, una
WebApp es intensiva de red. Reside en una red y debe Controlada p o r el contenido. En muchos casos, la
dar servicio a las necesidades de una comunidad diver función prim aria de una W ebApp es utilizar hiperme-
sa de clientes. Una W ebApp puede residir en Internet dia para presentar al usuario el contenido de textos, grá
(haciendoposible así una comunicación abiertapar todo ficos, sonido y vídeo.
1 En esta categoría se incluyen unos sitios W eb completos, fu n d o 2 En el contexto de este capitulo el term ino «aplicación web» abar
www.FreeLibros.org
nalidad especializada dentro de los sitios W eby aplicaciones de pro cara todo, desde una pagina Web simple que podría a yudara un con
ceso de inform ación que residen en Internet, en una Intranet o en sum idor a calcular el pago de un alquiler de un coche hasta un sitio
una Extranet W eb com pleto que proporcione los servicios com pletos para viales
de negocios y de vacaciones
522
C A P Í T U L O 29 I NGENI ERÍ A WEB
E v o lu c ió n c o n tin u a . A d if e r e n c ia d e l s o f t w a r e d e a p li m e d id a s d e s e g u r id a d e n t o d a la in f r a e s t r u c t u r a q u e a p o
c a c io n e s c o n v e n c io n a l , q u e e v o l u c i o n a c o n u n a s e r ie d e y a u n a W e b A p p y d e n tr o d e la m is m a a p lic a c ió n .
v e r s i o n e s p l a n i f i c a d a s y c r o n o l ó g i c a m e n t e e s p a c ia d a s , E s t é t ic a . U n a p a r t e in n e g a b le d e l a t r a c t iv o d e u n a
la s a p l i c a c i o n e s W e b e s t á n e n c o n s t a n t e e v o l u c i ó n . N o W e b A p p e s s u a p a r ie n c ia e in t e r a c c ió n . C u a n d o s e h a
e s in u s u a l q u e a lg u n a s W e b A p p s ( e s p e c ífic a m e n te , s u
d is e ñ a d o u n a a p lic a c ió n c o n e l f i n d e c o m e r c ia liz a r s e o
c o n t e n id o ) s e a c tu a lic e n c a d a h o r a . v e n d e r p r o d u c t o s o id e a s , la e s t é t ic a p u e d e t e n e r m u c h o
A lg u n o s a r g u m e n ta n q u e la e v o lu c ió n c o n tin u a d e q u e v e r c o n e l é x it o d e l d is e ñ o té c n ic o .
la s W e b A p p s h a c e q u e e l t r a b a j o r e a l i z a d o e n e l l a s s e a
L a s c a r a c t e r í s t ic a s g e n e r a le s d e s ta c a d a s a n t e r i o r
s im ila r a la ja r d in e r í a . L o w e [ L O W 9 9 ] tr a ta e s te te m a
m e n t e s e a p lic a n a to d a s la s W e b A p p s , p e r o c o n u n g r a
c o n e l s ig u ie n te e s c r it o :
d o d ife r e n t e d e in f lu e n c ia . L a s c a te g o r ía s d e a p lic a c io n e s
La in g en ie n a e stá a p u n to de a d o p ta r un en fo q u e c ie n tí q u e s e e n u m e r a n a c o n t i n u a c i ó n s o n la s m á s f r e c u e n t e s
fico y co nsecuente, su a v iza d o p o r u n con tex to específico y e n e l tr a b a jo d e la W e b [ D A R 9 9 ] :
práctico, para el de sa rro llo y el com isio n ad o de sistem as y
aplicaciones. El d esarro llo de los sitios W eb suele e sta r d e s • in f o r m a t iv a : s e p r o p o r c io n a u n c o n t e n id o s o lo d e le c
tinado a crea r una infraestructura (sem b rar el ja rd ín ) y e n to n t u r a c o n n a v e g a c ió n y e n la c e s s im p le s ;
ces « o c u p a rse » de la in fo rm a c ió n q u e crece y b ro ta d e n tro • d e s c a r g a : u n u s u a r io d e s c a r g a la in f o r m a c ió n d e s d e
del jard ín . D espués de u n tiem po, el ja rd ín (es d e cir, el sitio
e l s e r v id o r a p r o p ia d o ;
W eb) c o n tin u a rá e v o lu c io n a n d o , c a m b ia n d o y c re c ie n d o .
U n a b u e n a a rq u itec tu ra inicial d e b e rá p e rm itir q ue este c re
c im iento o curra de form a c o n tro la d a y c o n se c u e n te ...p o d rí W¡k ¿Cómo se pueden
am os h a c e r q u e «tres c irujanos» p o d a ran los « á rb o le s» (es W tategorizar las WebApps?
decir, las secciones del sitio W eb) d e n tro del ja rd ín (el sitio
en sí) a la vez se a seg u ra la in te g rid a d de las referen cias c ru
zadas. P o d ría m o s d isfru tar de «guarderías de jard ín » d o n d e • p e r s o n a liz a b le : e l u s u a r io p e r s o n a liz a e l c o n t e n id o
«se cultiven» las p lan ta sjó v en e s (es decir, las c o n fig u ra cio a s u s n e c e s id a d e s e s p e c í f ic a s ;
nes de d iseño para sitios W eb). A cab em o s c o n e sta analogía, • in te r a c c ió n : la c o m u n ic a c ió n e n tr e u n a c o m u n id a d
n o vaya a ser que v a y am o s d e m a sia d o lejos.
d e u s u a r io s o c u r r e m e d ia n t e u n e s p a c io c h a t ( c h a r la ) ,
U n c u id a d o y u n a a lim e n t a c ió n c o n t in u a p e r m it e q u e t a b lo n e s d e a n u n c io s o m e n s a je r ía in s ta n tá n e a ;
u n s it io W e b c r e z c a ( e n r o b u s te z y e n im p o r t a n c ia ) . P e r o • e n tr a d a d e l u s u a r io : la e n tr a d a b a s a d a e n f o r m u la
a d i f e r e n c i a d e u n j a r d í n , la s a p l i c a c i o n e s W e b d e b e n r io s e s e l m e c a n is m o p r i m a r i o d e la n e c e s id a d d e
d e s e r v i r ( y a d a p t a r s e a ) la s n e c e s i d a d e s d e m á s d e u n c o m u n ic a c ió n ;
ja r d in e r o , L a s s ig u ie n te s c a r a c te r ís tic a s d e W e b A p p s
• o r ie n t a d a a tr a n s a c c io n e s : e l u s u a r io h a c e u n a s o l i
s o n la s q u e c o n d u c e n e l p r o c e s o :
c it u d ( p o r e je m p lo , la r e a liz a c ió n u n p e d id o ) q u e e s
In m e d ia te z . L a s a p lic a c io n e s b a s a d a s e n W e b t ie n e n
c u m p lim e n ta d o p o r la W e b A p p ;
u n a in m e d ia te z [ N O R 9 9 ] q u e n o s e e n c u e n tr a e n o tr o s
• o r ie n t a d o a s e r v ic io s : la a p lic a c ió n p r o p o r c io n a u n
tip o s d e s o ftw a r e . E s d e c ir , e l tie m p o q u e s e ta r d a e n
s e r v ic io a l u s u a r io , p o r e je m p lo , a y u d a a l u s u a r io a
c o m e r c ia liz a r u n s it io W e b c o m p le t o p u e d e s e r c u e s tió n
d e te r m in a r u n p a g o d e h ip o t e c a ;
d e d ía s o s e m a n a s 3. L o s d e s a r r o lla d o r e s d e b e r á n u t i l i
z a r lo s m é t o d o s d e p l a n i f ic a c ió n , a n á lis is , d is e ñ o , im p le - • p o r t a l: la a p lic a c ió n c a n a liz a a l u s u a r io lle v á n d o lo
m e n ta c ió n y c o m p r o b a c ió n q u e se h a y a n a d a p ta d o a a o t r o s c o n te n id o s o s e r v ic io s W e b f u e r a d e l d o m i
p la n if ic a c io n e s a p r e ta d a s e n tie m p o p a r a e l d e s a r r o llo n io d e la a p lic a c ió n d e l p o r ta l;
de W e b A p p s. • a c c e s o a b a s e s d e d a to s : e l u s u a r io c o n s u lt a e n u n a
b a s e d e d a to s g r a n d e y e x tr a e in fo r m a c ió n ;
(w N S E M ^ • a lm a c e n e s d e d a t o s : e l u s u a r io h a c e u n a c o n s u lt a e n
u n a c o le c c ió n d e b a s e s d e d a to s g r a n d e y e x tr a e in f o r
No hay duda de que la Inmediatez o menudo prevalece
m a c ió n .
en el desarrollo de /as WebApps, pero hay que tener
cuidodo, porque el hecho de hocer oigo répldomente L a s c a r a c t e r í s t ic a s y la s c a t e g o r í a s d e s ta c a d a s a n te
no significo tener el privilegio de hacer un trabajo r io r m e n t e e n e s t a s e c c ió n , y la s c a t e g o r í a s d e a p lic a
delngenleríopobre. lo rápido y erróneo raros veces c io n e s r e p r e s e n ta n lo s h e c h o s r e a le s p a r a lo s in g e n ie r o s
tiene un resultado aceptable. d e l a W e b . L a c l a v e e s v i v i r d e n t r o d e la s r e s t r i c c i o n e s
im p u e s t a s p o r la s c a r a c t e r í s t ic a s a n t e r io r e s y a u n a s í
S e g u r i d a d . D a d o q u e la s W e b A p p s e s t á n d i s p o n i b l e s te n e r é x it o e n la e la b o r a c ió n d e la W e b A p p .
a tr a v é s d e l a c c e s o p o r r e d , e s d i f í c il, s i n o im p o s ib le ,
li m it a r la p o b la c ió n d e u s u a r io s f in a le s q u e p u e d e n a c c e
d e r a la a p lic a c ió n . C o n o b je t o d e p r o te g e r e l c o n t e n i 29.1.1. A tr ib u to s d e c a l i d a d
d o c o n fid e n c ia l y d e p r o p o r c io n a r fo r m a s s e g u ra s d e T o d a s la s p e r s o n a s q u e h a y a n n a v e g a d o a l g u n a v e z p o r l a
www.FreeLibros.org
tr a n s m is ió n d e d a to s , d e b e r á n im p le m e n ta r s e fu e r te s W e b o h a y a n u t iliz a d o u n a in t r a n e t d e u n a c o m p a ñ í a p u e -
3 Páginas Web sofisticadas pueden elaborarse en p o cas h o ra s
523
IN GE NIE RÍ A DEL S O F TW A RE . UN E N F O Q U E PR AC T I C O
d e n o p in a r s o b re lo q u e h a c e u n a « b u e n a » W e b A p p . L o s Desarrollo basado en com ponentes

p u n to s d e v is t a in d iv id u a le s v a r ía n e n o r m e m e n te . A lg u L a s t e c n o lo g í a s d e c o m p o n e n t e s e s t u d ia d a s e n lo s C a p í
n o s u s u a r io s d is f r u t a n c o n g r á f ic o s lla m a t iv o s , e n c a m b io t u lo s 2 7 y 2 8 h a n e v o lu c io n a d o e n g r a n p a r te g r a c ia s a l
o t r o s s o lo q u ie r e n u n t e x t o s e n c illo . A lg u n o s e x ig e n in f o r c r e c im ie n t o e x p l o s i v o d e lo s s is t e m a s y a p lic a c io n e s
m a c i ó n c o p i o s a , o t r o s d e s e a n u n a p r e s e n t a c i ó n a b r e v ia d a . b a s a d o s e n W e b . R e t o m a n d o e l e s t u d io d e l c a p í t u lo a n te
E n e fe c to , la p e r c e p c ió n d e « lo b u e n o » p o r p a r te d e l u s u a r io r , lo s in g e n ie r o s W e b d is p o n e n d e tr e s e s tá n d a re s
r i o ( y c o m o c o n s e c u e n c ia , la a c e p t a c ió n o n o a c e p ta c ió n im p o r ta n te s p a ra la in fr a e s tr u c tu r a : C O R BA,
r e s u lta n t e d e la W e b A p p ) p o d r í a s e r m á s im p o r t a n t e q u e C O M / D C O M y J a v a B e a n s . E s to s e s tá n d a re s (a c o m p a
c u a lq u ie r d is c u s ió n té c n ic a s o b r e la c a lid a d d e la W e b A p p . ñ a d o s p o r lo s c o m p o n e n t e s p r e c o n s t m id o s , h e r r a m ie n ta s
P e r o ¿ c ó m o s e p e r c ib e la c a lid a d d e la W e b A p p ? y t é c n i c a s ) p r o p o r c i o n a n u n a i n f r a e s t r u c t u r a q u e p e r m it e
¿ q u é a t r ib u t o s d e b e n d e e x h ib ir s e a n te lo s o jo s d e lo s a lo s q u e d is e ñ a n e m p le a r y p e r s o n a liz a r c o m p o n e n te s d e
u s u a r io s p a r a lo g r a r l o b u e n o y a l m is m o t ie m p o e x h i te r c e r a s p a r te s p e r m it ié n d o le s a s í c o m u n ic a r s e u n o s c o n
b i r la s c a r a c t e r í s t i c a s t é c n i c a s d e c a l i d a d q u e p e r m i t a n o t r o s y c o n s e r v i c i o s a n i v e l d e s is t e m a s .
a u n in g e n ie r o c o r r e g ir , a d a p ta r , m e jo r a r y s o p o r ta r la
a p lic a c ió n a la r g o p la z o ?
Arbol detallado de los requisitos

de calidad pora WebApps
E n r e a l i d a d , t o d a s la s c a r a c t e r í s t i c a s g e n e r a l e s d e l a
c a l i d a d d e l s o f t w a r e e s t u d i a d a s e n l o s C a p í t u l o s 8, 1 9
y 2 4 s e a p l i c a n t a m b i é n a la s W e b A p p s . S i n e m b a r g o , Seguridad
la s c a r a c t e r í s t i c a s m á s r e l e v a n t e s — u s a b i l i d a d , f i a b i l i
S i e n u n a r e d r e s id e u n a W e b A p p , é s ta e s tá a b ie r t a a u n
d a d , e f ic i e n c ia y c a p a c id a d d e m a n t e n im ie n t o - p r o
a c c e s o s in a u to r iz a c ió n . E n a lg u n o s c a s o s , h a s id o e l p e r
p o r c io n a n u n a b a s e Ú t il p a r a e v a lu a r la c a lid a d d e lo s
s o n a l i n t e r n o e l q u e h a i n t e n t a d o a c c e d e r s i n a u t o r i z a c ió n .
s is t e m a s b a s a d o s e n W e b .
E n o t r o s c a s o s , in t r u s o s ( h a c k e r s ) p u e d e n in t e n t a r a c c e
O ls in a y s u s c o la b o r a d o r e s [ O S L 9 9 ] h a n p r e p a r a d o
d e r p o r d e p o r t e , p o r s a c a r p r o v e c h o o c o n in t e n c io n e s m á s
u n « á r b o l d e r e q u is it o s d e c a lid a d » q u e id e n t if ic a u n
m a lic io s a s . M e d ia n t e la in f r a e s t r u c t u r a d e r e d s e p r o p o r
c o n ju n t o d e a t r ib u to s q u e c o n d u c e a W e b A p p s d e a lta
c io n a u n a v a r ie d a d d e m e d id a s d e s e g u r id a d ,ta le s c o m o
c a lid a d . L a F ig u r a 2 9 .1 r e s u m e s u t r a b a jo .
e n c r ip t a c ió n , c o r ta f u e g o s y o tra s . U n e s tu d io a m p lio d e
C a p ac id ad d e c o m p re n s ió n d e l sitio glo b al e s te te m a q u e d a fu e r a d e l á m b it o d e e s te lib r o . P a ra m á s
S ev ic io s d e a y u d a y re a lim e n ta c ió n e n linea i n f o r m a c i ó n , e l l e c t o r in t e r e s a d o p u e d e c o n s u l t a r e n e s ta
U s ab ilid ad
S ervicio s especiales b ib lio g r a fía : [ A T K 9 7 ] , [ K A E 9 9 ] y [B R E 9 9 ],
J C a p ac id ad d e re c u p e rac ió n y d e búsq u e d a Estándares de Internet

1, F u n c io n alid a d ^ S ervicio s d e b ú s q u e d a y n a ve g a c ió n D u r a n t e l a ú l t i m a d é c a d a e l e s t á n d a r d o m i n a n t e e n la
S ervicio s rela c io n a d o s c o n el d o m in io d e a p licación
/ c r e a c ió n d e l c o n t e n id o y la e s tr u c tu r a d e la W e b A p p h a
P roceso c o rre c to d e e nla c e s id o H T M L , u n le n g u a je d e m a r c a s q u e p o s ib ilit a a l d e sa -
- F iabilidad R e cup eración d e e rro res
Validación y rec u p e rac ió n d e la e n trad a d e l u suario r r o l la d o r p r o p o r c io n a r u n a s e r ie d e e t iq u e t a s q u e d e s
\ R e n d im ie n to del tie m p o d e respuesta
c r ib e n u n a g r a n v a r ie d a d d e o b je t o s d e d a to s ( te x to ,
\ Eficiencia Velocidad d e g e n e ra ció n d e p á g in a s g r á f ic o s , a u d io /v íd e o , f o r m u la r io s , e tc .) . S in e m b a rg o ,a
£ V elocidad d e g e n e ra ció n d e gráficos
m e d i d a q u e la s a p l i c a c i o n e s c r e c e n e n t a m a ñ o y c o m
1
F a cilid ad de co rre c ció n p le jid a d , se h a a d o p ta d o u n n u e v o e s tá n d a r — X M L —
C a p ac id ad d e 3I A d a p ta b ilid a d
m a n te n im ie n to 7 L E xte n s ib ilid a d p a r a l a p r ó x i m a g e n e r a c i ó n d e W e b A p p s . XML
( E x t e n s ib le M a r k u p L a n g u a g e ) e l L e n g u a je d e m a rc a s
FIGURA 29.1 . Á rbol de requisitos de calidad (O SL 99). e x te n s ib le e s u n s u b c o n ju n to e s tr ic ta m e n te d e fin id o d e l
m e t a l e n g u a j e S G M L [ B R A 9 7 ] , p e r m i t i e n d o q u e lo s d is e
29.1.2. L as t e c n o lo g ía s ñ a d o r e s d e f i n a n e t i q u e t a s p e r s o n a l i z a d a s e n la s d e s c r ip
E l d is e ñ o y la im p le m e n t a c ió n d e s is t e m a s b a s a d o s e n c io n e s d e u n a p á g in a W e b . M e d ia n t e u n a d e s c r ip c ió n d e l
W e b in c o r p o r a n tr e s te c n o lo g ía s im p o r t a n t e s : e l d e s a r r o m e t a l e n g u a j e X M L , e l s i g n i f i c a d o d e la s e t i q u e t a s p e r
www.FreeLibros.org
l l o b a s a d o e n c o m p o n e n t e s , la s e g u r id a d y lo s e s tá n d a r e s s o n a liz a d a s s e d e f in e e n la in f o r m a c ió n t r a n s m it id a a l
d e In te r n e t. U n in g e n ie r o W e b d e b e r á e s ta r f a m ilia r iz a d o s it io d e l c lie n te . P a r a m á s in f o r m a c ió n s o b r e X M L , e l
c o n la s t r e s p a r a c o n s t r u i r W e b A p p s d e a l t a c a l i d a d . le c t o r in t e r e s a d o d e b e r á c o n s u lt a r [ P A R 9 9 ] y [S T L 9 9 ] ,
524
CAPÍTULO 39 I N G E N I E R Í A WE B
Las características de sistemas y aplicaciones basados suelen ser controladas por el contenido haciendo hin
en Web influyen enormem ente en el proceso de IWeb. capié en la estética, es probable que las actividades de
La inm ediatez y la evolución continúan dictando un desarrollo paralelas se planifiquen dentro del proceso
m odelo de proceso incremental e interactivo (Capítulo IWeb y necesiten un equipo de personas tanto técnicas
2) que elabora versiones de WebApps muy rápidam en com o no (por ejem plo, redactores publicitarios, dise
te. La naturaleza intensiva de red de las aplicaciones en ñadores gráficos).
este dominio sugiere una población de usuarios diver
sa (exigiendo especialm ente la obtención y m odelado
de requisitos), y una arquitectura de aplicación que pue CLAVE
da ser altamente especializada (realizando de esta mane La IWeb demanda un proceso de software
ra exigencias en el diseño). D ado que las W ebApps incremental y evolutivo
A medida que la evolución de las WebApps pasa de uti tos técnicos para la WebApp e identifica los elementos
lizar recursos estáticos de inform ación controlada por del contenido que se van a incorporar. También se defi
el contenido a utilizar entornos de aplicaciones diná nen los requisitos del diseño gráfico (estética).
micos controlados por el usuario, cada vez es más impor La actividad de ingeniería incorpora dos tareas para
tante la necesidad de aplicar una gestión sólida y unos lelas, como se muestra a la derecha en la Figura 29.2. El
principios de ingeniería. Para conseguir esto, es nece diseño del contenido y la producción son tareas lleva
sario desarrollar un marco de trabajo IWeb que acom das a cabo por personas no técnicas del equipo IWeb. El
pañe a un m odelo de proceso eficaz, popularizado por objetivo de estas tareas es diseñar, producir, y/o adqui
las actividades4 del marco de trabajo y por las tareas de rir todo el contenido de texto, gráfico y vídeo que se
ingeniería. En la Figura 29.2 se sugiere un m odelo de vayan a integrar en la WebApp. Al mismo tiempo, se lle
proceso para IWeb. va a cabo un conjunto de tareas de diseño (Sección 29.5)
El proceso IWeb comienza con Yáformulación — acti La generación de páginas es una actividad de cons
vidad que identifica las metas y los objetivos de la WebApp trucción que hace mucho uso de las herramientas auto
y establece el ámbito del primer incremento— . matizadas para la creación de la WebApp. El contenido
definido en la actividad de ingeniería se fusiona con los
diseños arquitectónicos, de navegación y de la interfaz para
elaborar páginas Web ejecutables en HTML, XM L y otros
[ P la n i f ic a c ió n ! lenguajes orientados a procesos (por ejemplo, Java). Duran
te esta actividad también se lleva a cabo la integración con
el software intermedio (Middleware) de componentes (es
decir, CORBA, DCOM o JavaBeans). Las pruebas ejer
citan la navegación, intentan descubrir los errores de las
applets, guiones y formularios, y ayuda a asegurar que la
WebApp funcionará correctamente en diferentes entornos
(por ejemplo, con diferentes navegadores).
F IG U R A 2 9 .2 . El m o d e lo de proceso IW eb. Referencia Web

W3C es un consorcio de industria que proporciona
La planificación estima el coste global del proyecto, occeso a información WWW de interés
evalúa los riesgos asociados con el esfuerzo del desa para los ingenieros de Web, y se puede encontrar
rrollo, y define una planificación del desarrollo bien gra en la dirección ww w.w3.org
nulada para el incremento final de la WebApp, con una
planificación más toscamente granulada para los incre Cada increm ento producido com o parte del proceso
mentos subsiguientes. El análisis establece los requisi IWeb se revisa durante la actividad de evaluación del
www.FreeLibros.org
4 Retom ando el estudio de los m odelos de proceso del Capítulo 2, las
actividades del m arco de trabajo se realizan para todas las WebApps,
m ientras que las tareas se adaptan al tam año y a la complejidad de
la WebApp que se va a desarrollar.
525
c lie n te . E s e n e s te p u n t o e n d o n d e s e s o lic it a n c a m b io s s e i n t e g r a n e n l a s i g u i e n t e r u t a m e d i a n t e e l f l u j o in c r e -
( tie n e n lu g a r a m p lia c io n e s d e l á m b ito ) . E s to s c a m b io s m e n ta l d e l p ro c e s o .
L a f o r m u l a c ió n y e l a n á lis is d e s is t e m a s y a p lic a c io n e s e n zonas geográficas en donde actualm ente no tenem os alma

b a s a d o s e n W e b r e p r e s e n ta n u n a s u c e s ió n d e a c t iv id a cenes de ventas.
d e s d e in g e n ie r í a W e b q u e c o m ie n z a c o n la id e n t if ic a F in a lm e n t e , la c o m p a ñ í a d e f in e la d e m o g r a fí a p a ra
c ió n d e m e ta s g lo b a le s p a r a la W e b A p p , y t e r m in a c o n la W e b A p p : « L o s u s u a r io s p o t e n c ia le s d e H o g a r S e g u -
e l d e s a r r o llo d e u n m o d e lo d e a n á lis is o e s p e c if ic a c ió n r o l n c . c o m s o n p r o p i e t a r i o s d e c a s a s y d e n e g o c io s
d e lo s r e q u is it o s p a r a e l s is t e m a . L a f o r m u l a c ió n p e r p e q u e ñ o s .»
m i t e q u e e l c lie n t e o d is e ñ a d o r e s t a b le z c a u n c o n j u n t o L a s re s p u e s ta s q u e s e h a n e s ta b le c id o a n te r io r m e n
c o m ú n d e m e ta s y o b je t iv o s p a r a la c o n s t r u c c ió n d e la te im p li c a n m e ta s e s p e c íf ic a s p a r a e l s it io W e b H o g a r -
W e b A p p . T a m b ié n id e n t if ic a e l á m b ito d e e s fu e r z o e n S e g u r o I n c .c o m . E n g e n e r a l, s e id e n t if ic a n d o s c a te g o ría s
e l d e s a r r o llo y p r o p o r c io n a u n m e d io p a r a d e te r m in a r [G N A 9 9 ]:
u n r e s u lta d o s a t is fa c to r io . E l a n á lis is e s u n a a c t iv id a d
• M e ta s in f o r m a t iv a s : in d ic a n la in t e n c ió n d e p r o p o r
t é c n ic a q u e id e n t if ic a lo s d a to s y r e q u is it o s fu n c io n a le s
c io n a r e l c o n t e n id o y / o in f o r m a c ió n e s p e c í f ic o s p a ra
y d e c o m p o r ta m ie n to p a r a la W e b A p p . e l u s u a r io f in a l.
29.4.1. F o rm u la c ió n . M e t a s a p lic a b le s : in d ic a n la h a b il id a d d e r e a liz a r

a lg u n a s ta r e a s d e n tr o d e la W e b A p p .
P o w e ll [ P O W 9 8 ] s u g ie r e u n a s e r ie d e p r e g u n t a s q u e
d e b e rá n fo r m u la r s e y r e s p o n d e r s e a l c o m ie n z o d e la e ta
p a d e fo r m u la c ió n :
• ¿ C u á l e s la m o t iv a c ió n p r in c ip a l p a r a la W e b A p p ? CLAVE
. ¿ P o r q u é e s n e c e s a ria la W e b A p p ? PorotodaW ehAppdeberándefinirsemetas
. ¿ Q u ié n v a a u t ili z a r la W e b A p p ? informativosyaplicables.
H I ¿Qué preguntas E n e l c o n te n id o d e la W e b H o g a r S e g u r o In c .c o m ,u n a
W se deberían hacer m e ta in f o r m a t iv a p o d r í a s e r la s ig u ie n te :
para formular el problema?
El sitio proporcionará a los usuarios especificacionesde un
producto detallado, com o descripción técnica, instruccionesde
L a r e s p u e s ta a e s ta s p r e g u n ta s d e b e r á s e r d e lo m ás instalación e inform ación de precios.
s u c in to p o s ib le . P o r e je m p lo , s u p o n g a m o s q u e e l f a b r i
E l e x a m e n d e la s r e s p u e s t a s a n t e r io r e s lle v a r á a
c a n t e d e s is t e m a s d e s e g u r id a d e n e l h o g a r h a d e c id id o
p o d e r s e a p lic a r la a f ir m a c ió n d e m e t a s ig u ie n te :
e s ta b le c e r u n s it io W e b d e c o m e r c io e le c t r ó n ic o p a r a
v e n d e r s u s p r o d u c t o s d ir e c t a m e n t e a lo s c o n s u m id o r e s . H o g arS eg u ro In c.co m c onsultará al cliente só b re la ins
U n a fr a s e q u e d e s c r ib ie r a la m o t iv a c ió n d e la W e b A p p tala ció n (es decir, so b re la c asa, oficina/alm acén minoris
ta ) q u e se v a a p ro te g e r, y d a rá reco m en d acio n es per
p o d r í a s e r la s ig u ie n te :
so nalizadas so b re el p ro ducto y la c o n fig u ració n que se va
H ogarSeguroInc.com 5 perm itirá a los consum idores confi utilizar.
gurar y com prar todos los com ponentes necesarios para insta
lar un sistem a de seguridad en casa o en su com ercio. U n a v e z q u e h a n i d e n t i f i c a d o t o d a s la s m e t a s a p l i
Es im p o r t a n t e d e s ta c a r q u e e n e s ta fr a s e n o s e h a p r o c a b l e s e i n f o r m a t i v a s s e d e s a r r o l l a e l p e r f i l d e l c lie n t e .
p o r c io n a d o n i n g ú n d e ta lle . E l o b je t iv o e s d e lim it a r la E l p e r f i l d e l u s u a r io r e c o g e « la s c a r a c te r ís tic a s r e le
in t e n c ió n g lo b a l d e l s it io W e b . v a n t e s d e lo s u s u a r io s p o t e n c ia le s in c lu y e n d o a n te c e
D e s p u é s d e d is c u t ir c o n o tr o s p r o p ie ta r io s d e H o g a r - d e n te s , c o n o c im ie n t o , p r e fe r e n c ia s e in c lu s o m á s »
S e g u r o I n c ., la s e g u n d a p r e g u n ta se p o d r ía c o n te s ta r d e [ G N A 9 9 ] , E n e l c a s o d e H o g a r S e g u r o In c .c o m , e l p e r
la s ig u ie n te m a n e r a : f i l d e u s u a r i o i d e n t i f i c a r á la s c a r a c t e r í s t i c a s d e un com
p r a d o r t í p i c o d e s is t e m a s d e s e g u r id a d ( e s ta in f o r m a c ió n
H ogarSeguroInc.com nos perm itirá vender directam ente a
s e r í a p r o p o r c i o n a d a p o r e l d e p a r t a m e n t o d e m a r k e t in g
los consum idores, elim inando por tanto los costes de interm e
diarios, y m ejorando de esta m anera los m árgenes de benefi d e H o g a rS e g u ro In c .c o m ).
cios. Tam bién nos perm itirá aum entar las ventas en un 25 por U n a v e z q u e s e h a n d e s a r r o l l a d o la s m e t a s y lo s p e r
100 por encim a de las ventas anuales y nos perm itirá penetrar f ile s d e u s u a r io s , la a c t iv id a d d e f o r m u la c ió n s e c e n tra en
www.FreeLibros.org
5 Hogarseguro ya se ha utilizado anteriorm ente com o ejem plo en el
libro.
526
C A P I T U L O 29 I NGENI ERI A WEB
la afirmación del ámbito para la WebApp (Capítulo 5).

En muchos casos, las metas ya desarrolladas se integran
en la afirmación del ámbito. Además es Util, no obstan é á é m ám alo [WebApps]
I
te, indicar el grado de integración que se espera para la t e * gjmpion mejor
WebApp. Es decir, a m enudo es necesario integrar los ^«ÉpHofnenteydefofmfl
sistemas de inform ación existentes (por ejemplo, la apli ¡(flanes, y no Qtravés de usuarios
cación de base de datos existente) en un planteamiento ' e frRfdeodos. La habilidad
basado en Web. En este punto se tienen en consideración •¿cferttentes dilectamente
también los temas de conectividad. ! v ? >. « a infraestructura
l&hoámiento.
29.4.2. A n á lis is
Los conceptos y principios que se trataron para el aná
lisis de los requisitos del software (Capítulo 11) se apli de procesamiento. Aquí se realiza una descripción deta
can sin revisión en la actividad de análisis de ingeniería llada de todas las funciones y operaciones.
Web. Para crear un m odelo de análisis completo para la
W ebApp se elabora el ámbito definido durante la acti
Análisis de la configuración. Se efectúa una des
cripción detallada del entorno y de la infraestructura en
vidad de formulación. Durante la IWeb se realizan cua
donde reside la WebApp. La W ebApp puede residir en
tro tipos de análisis diferentes:
Internet, en una intranet o en una Extranet. Además, se
Análisis del contenido. Se trata de la identificación deberá identificar la infraestructura (es decir, la infra
del espectro com pleto de contenido que se va a p ro estructura de los componentes y el grado de utilización
porcionar. En el contenido se incluyen datos de texto, de la base de datos para generar el contenido) de la
gráficos, imágenes, vídeo y sonido. Para identificar y W ebApp.
describir cada uno de los objetos de datos que se van a A un cu an d o se reco m ien d a una esp ecificació n
utilizar dentro de la WebApp se puede utilizar el m ode detallada de los requisitos para W ebA pps grandes y
lado de datos (Capítulo 12). com plejas, tales docum entos no son los usuales. Se
Análisis de la interacción. Se trata de la descrip puede decir que la continua evolución de los requisi
ción detallada de la interacción del usuario y la tos de la W ebA pp puede hacer que cualquier do cu
WebApp. Para proporcionar descripciones detalladas m ento se quede obsoleto antes de finalizarse. Aunque
de esta interacción se pueden desarrollar casos prácti se puede decir que esto sucede de verdad, es necesa
cos (Capítulo 11). rio definir un m odelo de análisis que pueda fu n cio
n ar com o fu n d a m e n to de la siguiente activ id ad de
Análisis funcional. Los escenarios de utilización
diseño. Como mínimo, la inform ación recogida duran
(casos de uso) creados com o parte del análisis de inte
te las cuatro tareas de análisis anteriores deberá ser
racción definen las operaciones que se aplicarán en el
rev isad a, m o d ificad a a p etició n , y org an izad a para
contenido de la WebApp e im plicarán otras funciones
form ar un docum ento que pueda pasarse a los d ise
ñadores de W ebA pps
La naturaleza de inmediatez de las aplicaciones basadas en Con objeto de realizar un diseño eficaz basado en
Web unida a la presión de evolucionar continuamente obli W eb, el ingeniero deberá trabajar reutilizando cuatro
ga a que un ingenieroestablezcaun diseño que resuelva el elementos técnicos [NAN98]:
problema comercial inmediato, mientras que al mismo tiem Principios y métodos de diseño.Es im portante des
po obliga a definir'una arquitectura de aplicación que ten tacar que los conceptos y principios del diseño estu
ga la habilidad de evolucionar rápidamente con el tiempo. diados en el Capítulo 13 se aplican a todas las WebApps.
El problema, desde luego, es que resolver (rápidamente) el La m odularidad eficaz (exhibida con una cohesión alta
problema inmediato puede dar como resultado compromi y con un acoplam ientobajo), la elaboración paso a paso,
sos que afectan a la habilidad que tiene la aplicación de evo y cualquier otra heurística de diseño del software con
lucionar con el paso del tiempo. ducirá a sistemas y aplicaciones basados en W eb m ás
fáciles de adaptar, m ejorar, probar y utilizar.
Cuando se crean aplicaciones Web se pueden reutili-
Referencia m b zar los métodos de diseño que se utilizan para los siste
Uno fuente valiosa de líneas generóles prácticos
m as orientados a objetos estudiados anteriormente en
www.FreeLibros.org
poro el diseño de sitios Web se puede encontrar en este libro. La hiperm edia define «objetos» que interac-
w w w .ibiii.com /ibm /easy/design/low er/ túan mediante un protocolo de com unicación algo sim i
f060100.htm l lar a la mensajería. De hecho, la notación de diagramas
527
I N GE NI E RÍ A DEL S O F TW A R E . UN EN F O Q U E P R A C T I C O
p r o p u e s ta p o r U M L ( C a p ítu lo s 2 1 y 2 2 ) p u e d e a d a p ta r Una vez que se ha especificado una plantilla, cualquier par

s e y u t i l i z a r s e d u r a n t e l a s a c t i v i d a d e s d e d i s e ñ o d e la s te de una estructura hipermedia que se acopla a esta plantilla
se podrá generar o actualizar automáticamente llamando sola
W e b A p p s . A d e m á s , s e h a n p r o p u e s t o o t r o s h ip e r m e d io s
mente a la plantilla con datos relevantes [para dar cuerpo al
d e m é to d o s d e d is e ñ o ( p o r e je m p lo , [ I S A 9 5 ] , [ S C H 9 6 ] ) . esquema]. La utilización de plantillas constructivas depende
implícitamentedel contenido separado de los documentoshiper-
media.de la especificación y de su presentación: los datos fuen
te se organizan en la estructura del hipertexto tal y como se
especifica en la plantilla
29.5.1. D is e ñ o a r q u ite c tó n ic o
E l d is e ñ o a r q u it e c t ó n i c o p a r a lo s s is t e m a s y a p lic a c io
n e s b a s a d o s e n W e b s e c e n t r a e n la d e f in ic i ó n d e la
e s t r u c t u r a g l o b a l h i p e r m e d i a p a r a l a W e b A p p , y e n la
a p lic a c ió n d e la s c o n f ig u r a c io n e s d e d is e ñ o y p la n t illa s
c o n s t r u c t i v a s p a r a p o p u l a r i z a r l a e s t r u c t u r a ( y l o g r a r la
r e u t i l i z a c i ó n ) . U n a a c t i v i d a d p a r a l e l a , l l a m a d a d is e ñ o
R eglas de oro. L a s a p l i c a c i o n e s h i p e r m e d i a i n t e d e l c o n t e n id o 6, d e r iv a la e s t r u c t u r a y e l f o r m a t o d e ta
r a c tiv a s ( W e b A p p s ) lle v a n c o n s tr u y é n d o s e y a h a c e u n a lla d o s d e l c o n te n id o d e la in f o r m a c ió n q u e s e p re s e n ta
d é c a d a . D u r a n t e e s e t ie m p o , lo s d is e ñ a d o r e s h a n d e s a r á c o m o p a r te d e la W e b A p p .
r r o lla d o u n c o n ju n t o d e h e u r ís tic a s d e d is e ñ o ( r e g la s d e
o r o ) q u e se p o d r á n v o lv e r a a p lic a r d u r a n te e l d is e ñ o d e 0 9 N S E IO 0 .
a p lic a c io n e s n u e v a s .
la moyorío de las estructuras de las WebApps
Configuraciones de diseño. C o m o s e h a d e s t a c a d o simplemente aparecen. Evite esto trampa. Establezco
a n t e r io r m e n t e e n e s te l i b r o , la s c o n f ig u r a c io n e s d e d is e el diseña estructural de la WebApp explícitamente
ñ o s o n u n e n fo q u e g e n é r ic o p a ra r e s o lv e r p e q u e ñ o s p r o antes de em pezara desarrollar los detalles de la pógino
b le m a s q u e s e p u e d e n a d a p ta r a u n a v a r ie d a d m á s a m p lia y de la navegación.
d e p r o b le m a s e s p e c í f ic o s . E n e l c o n t e x t o d e la s
W e b A p p s , la s c o n f ig u r a c io n e s d e d is e ñ o s e p u e d e n a p l i Estructuras de las W ebApps
c a r n o s o lo a lo s e le m e n to s f u n c io n a le s d e u n a a p lic a L a e s t r u c t u r a a r q u i t e c t ó n i c a g l o b a l v a u n i d a a la s m e t a s
c i ó n , s i n o t a m b i é n a los d o c u m e n t o s , g r á f i c o s y e s t é t i c a e s ta b le c id a s p a r a u n a W e b A p p , a l c o n t e n id o q u e s e v a
g e n e ra l d e u n s itio W e b . a p r e s e n ta r , a lo s u s u a r io s q u e la v is it a r á n y a la f ilo s o
Plantillas. L a s p l a n t i l l a s s e p u e d e n u t i l i z a r p a r a p r o f í a d e n a v e g a c i ó n ( S e c c i ó n 2 9 . 5 . 3 ) e s t a b l e c i d o s . Cuan
p o r c io n a r u n m a r c o d e tr a b a jo e s q u e m á tic o d e c u a lq u ie r d o e l e n c a r g a d o d e la a r q u it e c t u r a v a a r e a liz a r e l d is e ñ o
c o n f ig u r a c ió n d e d is e ñ o o d o c u m e n to a u t ili z a r d e n tr o d e u n a W e b A p p típ ic a p u e d e e le g ir e n tr e c u a tr o fu e n
d e u n a W e b A p p . N a n a r d y K a h n [ N A N 9 8 ] d e s c r ib e n te s d ife r e n te s [P O W 9 8 ] ,
e s te e le m e n t o d e d is e ñ o r e u t iliz a b le d e la s ig u ie n t e
m a n e ra : ¿Cuáles son las opciones
• disponibles para el diseño de

una WebApp?
L a s e s t r u c t u r a s lin e a le s ( F ig . 2 9 . 3 ) a p a r e c e n c u a n
d o e s c o m ú n la s u c e s ió n p r e d e c ib le d e in te r a c c io n e s
t
( c o n a lg u n a v a r ia c ió n o d iv e r s if ic a c ió n ) . U n e je m p lo
c lá s ic o p o d r í a s e r la p r e s e n ta c ió n d e u n m a n u a l d e u s u a
r i o e n la q u e la s p á g in a s d e in f o r m a c ió n s e p r e s e n ta n
c o n g r á f i c o s r e l a c i o n a d o s , v í d e o s c o r t o s o s o n i d o solo
t
d e s p u é s d e h a b e r p r e s e n ta d o u n p r e r r e q u is ito . L a s u c e
s ió n d e p r e s e n ta c ió n d e l c o n t e n id o q u e d a p r e d e f in id a y
s e p u e d e d e c ir q u e , g e n e r a lm e n t e , e s lin e a l. O t r o e je m
Lineal con flujo Lineal p lo p o d r í a s e r la s u c e s ió n d e u n a e n tr a d a d e p e d id o d e
Lineal
opcional con desviaciones
u n p r o d u c to d o n d e s e te n g a q u e e s p e c if ic a r la in f o r m a
F IG U R A 2 9 .3 . Estructuras lineales. c ió n e s p e c í f ic a e n u n o r d e n e s p e c íf ic o . E n ta le s c a s o s ,
www.FreeLibros.org
6 El diseño del contenido es una actividad no técnica que llevan a
cabo redactores publicitarios, artistas, diseñadores gráficos y otros
que generan el contenido de las WebApps. Para más información,
véase ID1N9&1 y 1LYN99L
m
CAPÍTULO 29 I NGENI ERI A WEB
las estructuras que se muestran en la Figura 29.3 son las dél extremo izquierdode lajerarquía puede tener enlaces
adecuadas. A medida que el contenido y el procesa de hipertexto que lleven al contenido que existe enmedio
miento crecen en complicación, el flujo puramente line de la rama derechade la estructura. Sin embargo, debería
al que se muestra a la derecha da como resultado de destacarse que aunque dicha rama permita una nave
estructuras lineales más sofisticadas en las que se pue gación rápida por el contenidode la WebApp, puede ori
de invocar el contenido alternativo, o en donde tiene ginar también confusiónpor parte del usuario.
lugar una desviación para adquirir un contenido com
plementario (la estructura se muestra a la derecha en la
Fig. 29.3).
El acoplamiento es un temo engañoso poro
lo orquitecturo de los WebApps. Por un lodo, facilita
lo navegación. Pero, por otro, también puede hacer
que el usuario «se pierdo». Norehogo conexiones
horizontales dentrode unojerorquío.
F I G U R A 2 9 . 4 . E s t r u c t u r a r e t ic u la r .
Las estru ctu ras reticulares (Fig. 29.4) sonuna opción
arquitectónica que puede aplicarse cuando el contenido
de la WebApp puede ser organizado categóricamenteen
dos dimensiones (omás). Por ejemplo, consideremosuna F I G U R A 2 9 . 5 . E s t r u c t u r a s je r á r q u ic a s .
situaciónen la que un sitio de comercio electrónicoven
de palos de golf. La dimensiónhorizontal de la retícula Una estru ctu ra en r e d o de «web pura» (Fig. 29.6)
representa el tipo de palo en venta (por ejemplo, made se asemeja en muchos aspectos a la arquitectura en evo
ras, hierros, wedges, putters). La dimensiónvertical repre lución para los sistemas orientados a objetos. Los com
senta la ofertaproporcionadapor los fabricantesde palos ponentes arquitectónicos (en este caso las páginas Web)
de golf. De aquí que un usuariopueda navegar por la retí se diseñan de forma que pueden pasar el control
cula horizontalmente para encontrar la columna de los (mediante enlaces de hipertexto) a otros componentes
putters, y recorrer la columna para examinar las ofertas del sistema. Este enfoque permite una flexibilidad de
proporcionadas por los vendedores de putters. Esta arqui navegación considerable, aun cuando puede resultar
tectura WebApp es de utilidad solo cuando se encuentra confuso para el usuario.
un contenido muy regular [POW98].
< Ía v e
Las estructuras reticulares ír a o r a n ben cuando
el conendo puede organizarse caegóricam srte
en dos dimensiones o más.
Las estru ctu ras je rá rq u ica s (Fig. 29.5) son sinduda la

arquitecturaWebAppmás común. A diferenciade la divi
sión dejerarquías de software estudiadas en el Capítulo
14, que fomentan el flujo de control solo a lo largo de las
ramas verticales de lajerarquía, se podrá diseñar una
estructurajerárquica de la WebApp para posibilitar (por F IG U R A 2 9 .6 . E s tru c tu ra e n re d o « w e b p u ra )).
www.FreeLibros.org
medio de la ramificación de hipertexto) el flujo de con
trol en horizontal atravesando las ramas verticales de la Las estructuras arquitectónicas estudiadas en los
estructura. Por tanto, el contenidopresentado en la rama párrafos anteriores sepueden combinarpara formarestruc-
529
IN GE NI ER IA DEL S O F TW A R E . UN E N F O Q U E P R A C T I C O
tu r a s c o m p u e s ta s . L a a r q u it e c t u r a g lo b a l d e u n a W e b A p p • T a m iz : u n a c o n f i g u r a c i ó n q u e v a g u ia n d o a l u s u a r io
p u e d e s e r je r á r q u ic a , p e r o p a r te d e la e s tr u c tu r a p u e d e a t r a v é s d e u n a s e r ie d e o p c io n e s ( d e c is io n e s ) c o n e l
e x h i b ir c a r a c te r ís tic a s lin e a le s , m ie n t r a s q u e o t r a p a r te d e f i n d e lle v a r a l u s u a r io a u n c o n t e n id o e s p e c íf ic o e
la a r q u it e c t u r a p u e d e c o n fe c c io n a r s e e n r e d . L a m e t a d e l in d ic a d o p o r la s u c e s ió n d e o p c io n e s e le g id a s o d e c i
d is e ñ a d o r a r q u it e c t ó n ic o e s h a c e r c o r r e s p o n d e r í a e s tr u c s io n e s to m a d a s .
t u r a d e la W e b A p p c o n e l c o n t e n id o q u e s e v a a p r e s e n • V e c in d a r io : u n a c o n f ig u r a c ió n q u e a b a r c a u n m a r c o
t a r y c o n e l p r o c e s a m ie n to q u e s e v a a lle v a r a c a b o . d e n a v e g a c ió n u n if o r m e p o r to d a s la p á g in a s W e b
Patrones de diseño p a r a p e r m it ir q u e u n u s u a r io te n g a u n a g u ía d e n a v e
C o m o s e h a d e s ta c a d o a n te r io r m e n te e n e s te m is m o g a c ió n c o n s e c u e n te in d e p e n d ie n t e m e n t e d e la lo c a
li b r o , lo s p a tr o n e s d e d is e ñ o s o n u n b u e n m é to d o p a r a liz a c ió n d e la W e b A p p .
r e s o lv e r p e q u e ñ o s p r o b le m a s q u e p u e d e n a d a p ta r s e a L a s c o n fig u ra c io n e s d e d is e ñ o d e h ip e r te x to q u e se
u n a v a r ie d a d m u c h o m á s a m p lia d e p r o b le m a s e s p e c í h a n d e s c r ito a n t e r io r m e n t e s e p u e d e n r e u t iliz a r a m e d i
f i c o s . E n e l c o n t e x t o d e l o s s is t e m a s y a p l i c a c i o n e s b a s a - d a q u e e l c o n te n id o v a a d q u ir ie n d o e l f o r m a t o q u e p e r
d o s e n W e b , lo s p a tr o n e s d e d is e ñ o p u e d e n a p lic a r s e e n m i t ir á la n a v e g a c ió n a tr a v é s d e u n a W e b A p p .
e l n iv e l je r á r q u ic o , n iv e l d e c o m p o n e n te s y n iv e l d e
h ip e r t e x t o ( d e n a v e g a c ió n ) .
29.5.2. D is e ñ o d e n a v e g a c ió n
cam m aga U n a v e z e s ta b le c id a u n a a r q u it e c t u r a d e W e b A p p , u n a
B i los Copítulos 14 y 22 se puede encontrar más v e z id e n t if ic a d o s lo s c o m p o n e n t e s ( p á g in a s , g u io n e s ,
información sobre las configuradonesde diseño. a p p le t s y o t r a s f u n c io n e s d e p r o c e s o ) d e la a r q u it e c t u
r a , e l d i s e ñ a d o r d e b e r á d e f i n i r la s r u t a s d e n a v e g a c i ó n
C u a n d o d e n tr o d e u n a W e b A p p s e r e q u ie r e la f u n q u e p e r m it a n a l u s u a r io a c c e d e r a l c o n t e n id o y a lo s s e r
c io n a lid a d d e l p r o c e s o d e d a to s , p u e d e n a p lic a r s e lo s v ic io s d e la W e b A p p . P a r a q u e e l d is e ñ a d o r p u e d a lle
p a tr o n e s d e d is e ñ o a r q u it e c t ó n ic a s a n iv e l d e c o m p o v a r l o a c a b o , d e b e ( 1 ) i d e n t i f i c a r la s e m á n t ic a d e la
n e n te s p ro p u e s ta s p o r [B U S 9 6 ], [ G A M 9 5 ] y o tro s . L o s n a v e g a c ió n p a r a d if e r e n t e s u s u a r io s d e l s it io ; y ( 2 ) d e f i
p a tr o n e s d e d is e ñ o a n iv e l d e h ip e r t e x t o se c e n tr a n e n n i r la m e c á n ic a ( s in t a x is ) p a r a lo g r a r la n a v e g a c ió n .
e l d i s e ñ o d e la s c a r a c t e r í s t i c a s d e n a v e g a c i ó n q u e p e r G e n e r a lm e n te u n a W e b A p p g r a n d e te n d r á u n a v a r ie
m it e n a l u s u a r io m o v e r s e p o r e l c o n te n id o d e la W e b A p p d a d d e r o l e s d e u s u a r i o s d i f e r e n t e s . P o r e j e m p l o , lo s
f á c ilm e n t e . E n t r e m u c h o s d e lo s p a tr o n e s d e d is e ñ o d e r o le s p o d r í a n s e r e l d e v is it a n t e , c lie n t e r e g is t r a d o o
h ip e r t e x t o p r o p u e s to s e n lite r a t u r a s o b r e e s te te m a se c lie n t e p r i v i l e g i a d o . C a d a u n o d e e s to s r o le s s e p u e d e n
e n c u e n t r a n lo s s ig u ie n te s [B E R 9 8 J : a s o c ia r a d if e r e n t e s n iv e le s d e a c c e s o a l c o n t e n id o y d e
• C ic lo : u n a c o n f ig u r a c ió n q u e d e v u e lv e a l u s u a r io a l s e r v ic io s d ife r e n te s . U n v is ita n te p u e d e t e n e r a c c e s o
n o d o d e c o n te n id o v is it a d o a n te r io r m e n te . s ó lo a u n c o n t e n i d o l i m i t a d o , m i e n t r a s q u e u n c lie n te
r e g is t r a d o p u e d e t e n e r a c c e s o a u n a v a r ie d a d m u c h o
m á s a m p lia d e in f o r m a c ió n y d e s e r v ic io s . L a s e m á n
Q f Í ta l t i c a d e la n a v e g a c ió n d e c a d a u n o d e e s to s r o le s s e ría
Coda una de las configuraciones es una iregla d ife r e n te .
•:■..•! de tres portes, y que expresa E l d i s e ñ a d o r d e W e b A p p s c r e a u n a unidad semánti
w a relación entre un cierto contexto, ca de navegación ( U S N ) p a r a c a d a u n a d e la s m e t a s a s o
ira proferto y una soludón. c i a d a s a c a d a u n o d e l o s r o l e s d e u s u a r i o [ G N A 9 9 ] , Por
C M stepiw r A kxaader e j e m p l o , u n c l i e n t e r e g i s t r a d o p u e d e t e n e r s e is m e t a s
d if e r e n t e s , to d a s e lla s c o n u n a c c e s o a in f o r m a c ió n y
• A n illo d e W e b : u n a c o n f ig u r a c ió n q u e im p le m e n ta s e r v i c i o s d i f e r e n t e s . P a r a c a d a m e t a s e c r e a u n a USN.
u n « g r a n c ic l o q u e e n la z a h ip e r t e x t o s e n te r o s v ia G n a h o y L a r c h e r [ G N A 9 9 ] d e s c r i b e n l a U S N d e la
ja n d o p o r u n te m a » [B E R 9 8 ], s ig u ie n te m a n e r a :
• C o n to r n o : u n p a tr ó n q u e a p a re c e c u a n d o v a r io s c ic lo s
L a e stru ctu ra de una U S N se com pone de un conjunto de
in c id e n e n o tr o , p e r m it ie n d o n a v e g a r p o r r u ta s d e f i subestructuras de navegación que llam am os fo rm a s de n a v e
n id a s p o r lo s c ic lo s . g a c i ó n [W oN ( W a v s o f n a v i g a t i n g ) ] . U na W oN representa
• C o n tr a p u n to : u n p a t r ó n q u e a ñ a d e c o m e n ta r io s d e la m ejor form a de n a v eg ació n o ruta para que usuarios con
h ip e r t e x t o in t e r r u m p ie n d o la n a r r a tiv a d e l c o n te n id o ciertos perfiles lo g ren su m eta o su b m eta deseada. Por tan
to , el con cep to de W oN se asocia al con cep to de Perfil de
p a r a p r o p o r c io n a r m á s in f o r m a c ió n o m á s in d a g a c ió n .
U suario.
• M u n d o d e e s p e jo : e l c o n t e n i d o s e p r e s e n t a u t i l i z a n d o
L a estru ctu ra d e una W oN se com pone de un conjunto de
d ife r e n te s h ilo s n a r r a tiv o s , c a d a u n o c o n u n p u n to d e
n o d o s d e n a v e g a c i ó n (N N ) relev an tes conectados a enlaces
v is t a o p e r s p e c t iv a d ife r e n te . P o r e je m p lo , e l c o n te
de navegación, e n tre los que a lgunas v eces se incluyen las
www.FreeLibros.org
n id o q u e d e s c r ib e u n a c o m p u t a d o r a p e r s o n a l p o d r í a U S N s. Eso sig n ifica que las U S N s pueden agregarse para
p e r m it ir a l u s u a r io s e le c c io n a r u n a n a r r a t iv a « t é c fo rm ar una U S N de nivel superior, o anidarse en cualquier
n ic a » o « n o té c n ic a » q u e d e s c r ib a la m á q u in a . nivel de profundidad.
530
CAPÍTULO 29 I NGENI ERÍ A WEB
d o , la s o f is t ic a c ió n d e la s c a p a c id a d e s , lo s s e r v ic io s d e
p r o c e s a m ie n to y e l b e n e f ic io g lo b a l d e la W e b A p p e n
CLAVE s í , u n a in t e r f a z c o n u n d is e ñ o p o b r e d e c e p c io n a r á a l
Una USN se compone de un conjunto de subestructuras u s u a r io p o t e n c ia l y p o d r á d e h e c h o h a c e r q u e e l u s u a
de navegación llamadas ((formas de navegación)) (WoN). r io s e v a y a a c u a lq u ie r o t r o s it io . D a d o e l g r a n v o lu m e n
Una USN representa una meta de navegaciónespecífica d e W e b A p p s q u e c o m p i t e n v i r t u a l m e n t e e n t o d a s la s
para un tipo específico de usuario. á re a s te m á t ic a s , la in t e r f a z d e b e « a r r a s t r a r » in m e d ia t a
m e n te a l u s u a r io p o te n c ia l. N ie ls e n y W a g n e r [ N I E 9 6 ]
D u r a n t e la s e t a p a s i n i c i a l e s d e l d is e ñ o d e n a v e g a s u g ie r e n u n a s c u a n ta s lí n e a s g e n e r a le s y s e n c illa s e n e l
c ió n , p a r a d e te r m in a r u n a o m á s W o N s p a r a c a d a m e ta r e d is e ñ o d e u n a W e b A p p :
d e u s u a r io , s e e v a lu a r á la e s tr u c tu r a d e la W e b A p p • P r o b a b ilid a d d e q u e lo s e r r o r e s d e l s e r v id o r , in c lu s o
( a r q u it e c t u r a y c o m p o n e n te s ) . C o m o s e h a d e s ta c a d o lo s m á s p e q u e ñ o s , h a g a n q u e e l u s u a r io a b a n d o n e e l
a n te r io r m e n te , u n a W o N id e n t if ic a lo s n o d o s d e n a v e s it io W e b y b u s q u e in f o r m a c ió n y s e r v ic io s e n a lg ú n
g a c ió n ( p o r e je m p lo , p á g in a s W e b ) , y e n to n c e s lo s e n la o t r o s itio .
c e s q u e h a c e n p o s ib le la n a v e g a c ió n e n tr e e llo s . L a W o N
e n to n c e s se o r g a n iz a e n U S N s . ¿Cuáles son algunas
A m e d id a q u e a v a n z a e l d is e ñ o , s e v a id e n t if ic a n d o la
m e c á n ic a d e c a d a e n la c e d e n a v e g a c ió n . E n t r e o t r a s
m u c h a s o p c io n e s s e e n c u e n t r a n lo s e n la c e s b a s a d o s e n
te x to , ic o n o s , b o to n e s , in te r r u p to r e s y m e tá f o r a s g r á fic a s .
• de las líneas generales
básicas para el diseño
de la interfaz de un sitio W eb?
E l d i s e ñ a d o r d e b e r á e l e g i r l o s e n la c e s d e n a v e g a c i ó n a d e
L a v e lo c id a d d e le c t u r a d e l m o n it o r d e u n a c o m p u
c u a d o s p a r a e l c o n te n id o y c o n s e c u e n te s c o n la h e u r ís ti
ta d o r a e s a p r o x im a d a m e n te u n 2 5 p o r 1 0 0 m á s le n to
c a q u e c o n d u c e a l d is e ñ o d e u n a in t e r f a z d e a lta c a lid a d .
q u e le e r u n a c o p ia im p r e s a . P o r ta n to , n o h a y q u e o b l i
A d e m á s d e e l e g i r la m e c á n ic a d e n a v e g a c ió n , e l d is e
g a r a l u s u a r io a le e r c a n tid a d e s v o lu m in o s a s d e te x t o ,
ñ a d o r t a m b i é n d e b e r á e s t a b l e c e r la s c o n v e n c i o n e s y a y u
p a r t ic u la r m e n t e c u a n d o e l t e x t o e x p lic a la o p e r a c ió n
d a s a d e c u a d a s . P o r e je m p lo , lo s ic o n o s y lo s e n la c e s
d e la W e b A p p o a y u d a a n a v e g a r p o r la re d .
g r á fic o s d e b e r á n te n e r u n a s p e c to « c lic k a b le ( c a p a c id a d
d e a c c e d e r s e ) » c o n lo s b o r d e s b is e la d o s , y d a r a s í u n a E v it e lo s s í m b o lo s « b a jo c o n s t r u c c ió n » — le v a n ta n
im a g e n e n tr e s d im e n s io n e s . L a r e a lim e n t a c ió n v is u a l e x p e c t a c ió n y p r o v o c a n u n e n la c e in n e c e s a r io q u e
o d e s o n id o se d e b e rá d is e ñ a r p a r a p r o p o r c io n a r a l u s u a s e g u ra m e n te s e a d e c e p c io n a n t e - .
r io u n a in d ic a c ió n d e q u e se h a e le g id o u n a o p c ió n d e L o s u s u a r io s p r e f ie r e n n o t e n e r q u e r e c o r r e r la p a n
n a v e g a c ió n . P a r a l a n a v e g a c i ó n b a s a d a e n t e x t o , s e d e b e t a lla . D e n t r o d e la s d im e n s io n e s n o r m a le s d e u n a
r á u t ili z a r e l c o lo r q u e in d ic a lo s e n la c e s d e n a v e g a c ió n v e n ta n a d e l n a v e g a d o r se d e b e rá in c lu ir in fo r m a c ió n
y p r o p o r c io n a r u n a in d ic a c ió n d e lo s e n la c e s p o r lo s q u e im p o r t a n t e .
se h a n a v e g a d o . E s ta s s o n s o lo u n a s p o c a s c o n v e n c io
L o s m e n ú s d e n a v e g a c i ó n y la s b a r r a s d e c a b e c e r a s e
n e s d e la s d o c e n a s q u e h a c e n q u e l a n a v e g a c i ó n p o r l a
d e b e rá n d is e ñ a r c o n s e c u e n te m e n te y d e b e r á n e s ta r
r e d s e a a g r a d a b l e . A d e m á s d e la s c o n v e n c i o n e s , e n e s t e
d i s p o n i b l e s e n t o d a s la s p á g i n a s a la s q u e el u s u a r i o
p u n to ta m b ié n s e d e b e r á n d is e ñ a r a y u d a s d e n a v e g a c ió n
t e n g a a c c e s o . E l d i s e ñ o n o d e b e r á d e p e n d e r d e la s f u n
t a le s c o m o m a p a s d e s i t i o s , t a b l a s d e c o n t e n i d o s , m e c a
c io n e s d e l n a v e g a d o r p a r a a y u d a r e n la n a v e g a c ió n .
n is m o s d e b ú s q u e d a y s e r v ic io s d in á m ic o s d e a y u d a
L a e s té t ic a n u n c a d e b e r á s u s t it u ir la f u n c io n a lid a d .
P o r e je m p lo , u n b o t ó n s e n c illo p o d r ía s e r u n a o p c ió n
29.5.3. D is e ñ o d e l a in te rfa z d e n a v e g a c ió n m e jo r q u e u n a im a g e n o ic o n o e s té
L o s c o n c e p to s , p r in c ip io s y m é to d o s d e d is e ñ o s d e in t e r tic a m e n te a g r a d a b le s , p e r o v a g o s c u y a in t e n c ió n n o
fa z q u e se p r e s e n ta ro n e n e l C a p ítu lo 1 5 s o n to d o s a p li e s m u y c la r a .
c a b le s a l d is e ñ o d e in t e r f a c e s d e u s u a r io p a r a W e b A p p s .
S i n e m b a r g o , la s c a r a c t e r í s t i c a s e s p e c i a l e s d e l o s s i s t e
m a s y a p lic a c io n e s W e b r e q u ie r e n o tr a s c o n s id e r a c io
n e s a d ic io n a le s . Referencia
Uno de los mejores grupos de recursosde usabilidod
de la Web ha sido recogido por el Grupo de Usabilidod,
Q cíH a : y se puede encontrar en la dirección
’tiijisU flÉ B tienen poca paciencia con los sitios w w w.usability.com/umijinks.htm
| ' r finen un diseño pobre
m É MMsM y A m ito Wagner L a s o p c io n e s d e n a v e g a c ió n d e b e r á n s e r o b v ia s ,
www.FreeLibros.org
in c lu s o p a r a e l u s u a r io c a s u a l. E l u s u a r io d e b e r á b u s
L a in t e r f a z d e u s u a r io d e u n a W e b A p p e s la « p r im e r a c a r la p a n t a lla p a r a d e t e r m in a r c ó m o e n la z a r c o n o t r o
im p r e s ió n » . In d e p e n d ie n t e m e n t e d e l v a lo r d e l c o n t e n i- c o n t e n id o o s e r v ic io .
531
I N G E N IE RÍ A DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
U na interfaz bien d iseñ ad a m ejora la percepción de las in te rfa c e s W ebA pp de u su a rio está fuera
del contenido o de los servicios del usuario que p ro del ám bito de este libro. L os lecto res interesados
p o rcio n a el sitio Web. N o tiene que ser n e c e sa ria pu ed en c o n su lta r [S A N 96], [F L E 98], [ROS98], o
m ente deslum brante, pero deberá estar siem pre bien [LY N 99] e n tre los c ien to s de o fe rta s que existen
e stru c tu ra d a y erg o n ó m ica. U n e stu d io c o m p le to com o guía.
>ADAS EN WEB
En el Capítulo 17, se destacó que las pruebas son el pro ces de navegación (Sección 29.5.2) son revisados
ceso de ejercitar el software con la intención de encon para asegurar su correspondencia con los especifi
trar (y por últim o corregir) los errores. Esta fdosofía cados en cada USN del rol de usuario.
fúndamentalno se cambiarápara el caso de las WebApps. 3. Se aplican p ru eb a s de unidad a los componentes de
De hecho, dado que los sistemas y aplicaciones basados proceso seleccionados y las p á ginas Web. Cuando
en Web residen en una red e interoperan con muchos sis lo que se tiene en consideración es el tem a de las
temas operativos diferentes, navegadores, plataformas de W ebApps el concepto de unidad cambia. Cada una
hardware, y protocolos de com unicación,la búsqueda de de las páginas Web encapsulará el contenido, los enla
errores representa un reto significativopara los ingenie ces de navegación y los elementos de procesamiento
ros Web. (formularios, guiones, applets). No siempre es posi
¿Qué pasos hay que seguir ble o práctico com probar cada una de las caracterís
• para la comprobación de una

WebApp?
El enfoque de las pruebas de las WebApps adopta los

ticas individualmente. En m uchos casos, la unidad
comprobable m ás pequeña es la página Web. A dife
rencia de la com probación de unidades de software
convencional, que tiende a centrarse en el detalle
algorítmico de un módulo y los datos que fluyen por
principios básicos de todas las pruebas del software (Capí la interfaz del módulo, la com probación por páginas
tulo 17) y aplica estrategias y tácticas que ya han sido se controla mediante el contenido, proceso y enla
recomendadas para los sistemas orientados a objetos (Capí ces encapsulados por la página Web.
tulo 23). Este enfoque se resume en los pasos siguientes:
1. E l modelo de contenido de la WebAppes revisadopara
descubrir errores. Esta actividad de «prueba» se ase tos estrategias de integración se abarcan
m eja en m uchos aspectos a la de un corrector orto en los Capítulos 18y 23.
gráfico de un docum ento escrito. De hecho, un sitio
Web grande tendrá la capacidad de construir un lis
4. Se construye la arquitectura, se realizan las pruebas
tado de los servicios de correctores profesionales para
de integración. La estrategia para la prueba de inte
descubrir errores tipográficos, errores gramaticales,
gración depende de la arquitectura que se haya elegido
errores en la consistencia del contenido, errores en
para la WebApp. Si la WebApp se ha diseñado con una
representaciones gráficas y de referencias cruzadas.
estructuraj erárquica lineal, reticular o sencilla, es posi
ble integrar páginas Web de una manera muy similar
í (fita : a como se integran los m ódulos del software conven
cional. Sin embargo, si se utiliza una jerarquía mez
Lo MMwción es un negocio omargo para los que
clada o una arquitectura de red (Web), la prueba de
■jmpfuefirai e! softwore. Cuando ya se sabe qué integraciones similar al enfoque utilizado para los sis
postas aplicar en una tecnología en particular.
temas OO. La com probación basada en hilos (Capí
>3pecs una nueva (internet y WebApps), y se
tulo 23) se puede utilizar para integrar un conjunto de
vienen (tajo las anteriores.
páginas Web (se puede utilizar una USN para definir
¡locb
el conjunto adecuado) que se requiere para responder
aun suceso de usuario. Cadahilo seintegray sepmeba
2. E l m odelo de diseño p a ra la WebApp es revisado individualmente. La prueba de regresión se aplicapara
p a r a descubrir errores de navegación. Los casos asegurar que no haya efectos secundarios. La com
prácticos derivados com o parte de la actividad de probación de agrupamientos integra un conjunto de
análisis permite que un ingeniero Web ejercite cada páginas colaborativas (determinadas examinando los
escenario de utilización frente al diseño arquitectó casos prácticos y la USN). Los casos de prueba se deri
nico y de navegación. En esencia, estas pruebas no van para descubrir errores en las colaboraciones.
www.FreeLibros.org
ejecutables ayudan a descubrir errores en la nave 5. La WebApp ensam blada se p ru eb a p a ra conseguir
gación (por ejemplo, un caso en donde el usuario no una fu n cio n a lid a d global y un contenido. Al igual
pueda leer un nodo de navegación). Además, los enla que la validación convencional, la validación de los
532
C A P Í T U L O 29 I NGENI ERI A WEB
sistemas y aplicaciones basados en Web se centra en cubrir los errores asociados con todas y cada una de
acciones visibles del usuario y en salidas reconoci las configuraciones posibles.
bles para el usuario que procedan del sistema. Para 7. L a W ebAppse com prueba con unapoblación de usua-
ayudar en la derivación de las pruebas de validación, riosfi nales controlada y m onitorizada. Se selecciona
las pruebas deberán basarse en casos prácticos. El un grupo de usuarios que abarque todos los roles posi
caso práctico proporciona un escenario con una pro bles de usuarios. La WebApp se pone en práctica con
babilidad alta de descubrir errores en los requisitos estos usuarios y se evalúan los resultados de su inte
de interacción del usuario. racción con el sistema para ver los errores de conte
6. L a W ebApp se im plem enta en una va ried a d de con nido y de navegación, los intereses en usabilidad,
fig u ra c io n e s diferentes de entornos y com probar así compatibilidad, fiabilidad y rendimiento de la WebApp.
la co m patibilidad con cada configuración. Se crea Dado que muchas W ebApps están en constante evo
una m atriz de referencias cruzadas que define todos lución, el proceso de com probación es una actividad
los sistem as operativos probables, plataform as de continua, dirigida por un personal de apoyo a la Web
hardware para navegadores7 y protocolos de com u que utiliza pruebas de regresión derivadas de pruebas
nicación. Entonces se llevan a cabo pruebas para des desarrolladas cuando se creó la WebApp.
Dada la inm ediatez de las W ebApps, sería razonable ciplinas. ..» Aun cuando los autores están absolutamente
preguntarse: ¿necesito realm ente invertir tiem po esfor en lo cierto, los «renacentistas» no disponen de muchas
zándome con la W ebApp? ¿no debería dejarse que la provisiones, y dado las exigencias asociadas a los pro
WebApp evolucionara de forma natural, con poca o nin yectos importantes de desarrollo de WebApps, el conjun
guna gestión explícita? M uchos diseñadores de Webs to de conocimientos diversos necesario podrá distribuirse
optarían por gestionar poco o nada, pero eso no hace incluso mejor dentro del equipo de IWeb.
que estén en lo cierto.
La ingeniería W eb es una actividad técnica com
plicada. Hay m uchas personas im plicadas, y a m enu
inundo actual de redes y Webs, se necesita
do trabajando en paralelo. La com binación de tareas
di#» un conocimiento amplio de Internet.
técnicas y no técnicas que deben de tener lugar (a tiem
Scott THy y SMhovg Hoang
po y d en tro del presupuesto) para producir una
WebApp de alta calidad representa un reto para cual
quier grupo dtfíprofesionales. Con el fin de evitar cual Los equipos de IWeb pueden organizarse de forma
quier confusión, frustración y fallo, se deberá poner muy sim ilar a como se organizan los equipos de softwa
en acción una planificación, tener en cuenta los ries re del Capítulo 3 . Sin embargo, pueden existir diferen
g o s , establecer y rastrear una planificación tem poral cias entre los participantes y sus roles. Entre los muchos
y definir los controles. Estas son las actividades clave conocim ientos que deben distribuirse por los miem bros
que constituyen lo que se conoce com o gestión de pro del equipo IWeb se encuentran los siguientes: ingeniería
yectos. del software basada en componentes,realización de redes,
diseño arquitectónicoy de navegación, lenguajesy están
im s m m m
dares de Internet, diseño de interfacespara personas, dise
Losactividadesasociadosconlagestióndeproyectos ño gráfico, disposición del contenido y pruebas de las
desoftwareseestudianenlaPorteSegunda WebApps. Los roles' siguientes deberán ser distribuidos
deestelibro. entre los m iem bros del equipo IWeb:
29.7.1. El e q u ip o d e IWEB ¿Qué papeles juegan

La creación de una buena aplicación Web exige un amplio
abanico de conocimientos. Tilley y Huang [TIL99] se
enfrentan a este tem a cuando afirman: «Hay m uchos
aspectos diferentes en relación con el softwarede aplica
• las personas que forman
parte del equipo de IWeb?
D esarrolladores y proveedores de contenido. Dado
que las W ebApps son controladas inherentemente por
ciones [Web] debido al resurgimiento del renacentista, el contenido, el papel de los m iem bros del equipo IWeb
aquel que se encuentra cómodo trabajando en varias dis se centra en la generación y/o recolección del conteni-
www.FreeLibros.org
7 Los navegadores son excelentes para implementar sus propias Ínter- 8 Estos roles se han adaptado de Harsen y sus colaboradores [HAN99]
prefaciones «estándar» ligeram ente diferentes de HTMLy JavaScript.
Para un estudio de tem as de com patibilidad, véase www.browser-
caps.com.
533
IN GE NIE RÍ A DEL S O F T W A R E . UN EN F O Q U E P R Á C T I C O
do. Retom ando la idea de que el contenido abarca un • el desarrollo e im plem entación de norm as para el
amplio abanico de objetos de datos, los diseñadores y funcionam iento de la W ebApp;
proveedores del contenido pueden proceder de diver • el establecimiento de los procedim ientos de soporte
sos planos de fondo (no de software). Por ejem plo, el y realimentación;
personal de ventas o de m arketing puede proporcionar • los derechos de acceso y seguridad de la implemen
inform ación de productos e imágenes gráficas: los pro tación;
ductores de m edios pueden proporcionar imagen y soni
• la m edición y análisis del tráfico del sitio Web;
do; los diseñadores gráficos pueden proporcionar diseños
para com posiciones gráficas y contenidos estéticos; los • la coordinación de los procedim ientos de control de
redactores publicitarios pueden proporcionar conteni cambios (Sección 29.7.3);
do basado en texto. A dem ás, existe la posibilidad de • la coordinación con especialistas de soporte.
necesitar personal de investigación que encuentre y dé El adm inistrador tam bién puede estar involucrado
form ato al contenido externo y lo ubique y referencie en las actividades técnicas realizadas por los ingenie
dentro de la WebApp. ros de Web y por los especialistas de soporte.
Editores de Web. El contenido tan diverso generado
por los desarrolladores y proveedores de contenido debe 29.7.2. G e s tió n d e l p ro y e c to
rá organizarse e incluirse dentro de la WebApp. Además, En la Parte Segunda de este libro se tuvieron en consi
alguien deberá actuar como conexión entre el personal deración todas y cada una de las actividades global
técnico que diseña la WebApp y l o s diseñadores y pro mente llamadas gestión de proyectos'. Las métricas de
veedores del contenido. Esta función la lleva a cabo el procesos y proyectos, la planificación de proyectos (y
editor de Web, quien deberá entender la tecnología tan estimación), el análisis y gestión de riesgos, la planifi
to del contenido como de la WebApp en donde se inclu cación tem poral y el rastreo, SQA y CGS, se estudia
ye el lenguaje HTM L (o am pliaciones de generaciones ron en detalle. En teoría, la m ayoría de las actividades
posteriores, tal como XML), la funcionalidad de bases de gestión de proyectos, si no todas, estudiadas en capí
de datos y guiones, y la navegación global del sitio Web. tulos anteriores, se aplican a los proyectos de IWeb. Pero
Ingeniero de Web. Un ingeniero Web cada vez se en la práctica, el enfoque de IW eb para la gestión de
proyectos es considerablem ente diferente.
involucra m ás con la gran cantidad de actividades del
desarrollo de una WebApp entre las que se incluyen la En prim er lugar, se subcontrata un porcentaje sus
obtención de requisitos, m odelado de análisis, diseño tan cia l” de W ebA pps a proveedores que (supuesta
arquitectónico, de navegación y de interfaces, imple- m ente) son especialistas en el desarrollo de sistemas y
mentación de la WebApp y pruebas. El ingeniero de Web aplicaciones basados en Web. En tales casos, un nego
también deberá conocer a fondo las tecnologías de com cio (el cliente) solicita un precio fijo para el desarrollo
ponentes, las arquitecturas cliente/servidor, HTML/XML, de una W ebApp a uno o m ás p ro v e e d le s , evalúa los
y las tecnologías de bases de datos; y deberá tener cono precios de los candidatos y selecciona un proveedor para
cimiento del trabajo con conceptos de m ultimedia, pla hacer el trabajo. Pero, ¿qué es lo que busca la organi
taformas de hardw are/softw are, seguridad de redes y zación contratista?, ¿cómo se determ ina la competen
cia de un proveedor de W ebA pps?, ¿cóm o se puede
temas de soporte a los sitios Web.
saber si un precio es razonable?, ¿qué grado de planifi
Especialistas de soporte. Este papel se asigna a la per cación, program ación temporal, y valoración de riesgos
sona (personas) que tiene la responsabilidad de continuar se puede esperar a m edida que una organización (y su
dando soporte a la WebApp. Dado que las WebApps están subconstratista) se va em barcando en un desarrollo
en constante evolución, el especialista de soporte es el res im portante de W ebApps?
ponsable de las correcciones, adaptaciones y mejoras del En segundo lugar, el desarrollo de W ebApps es una
sitio Web, donde se incluyen actualizaciones del conteni área de aplicación relativamente nueva por tanto se pue
do, implementación de productos y formularios nuevos, den utilizar pocos datos para la estim ación. H asta la
y cambios del patrón de navegación. fecha, no se ha publicado virtualm ente ninguna métri
Administrador. Se suele llam ar Web master, y es el ca de IWeb. De hecho, tam poco han surgido muchos
responsable del funcionam iento diario de la W ebApp, estudios sobre lo que esas métricas podrían ser. Por tan
en donde se incluye: to, la estim ación es puramente cualitativa — basada en
www.FreeLibros.org
9 Se recom ienda que lectores no fam iliarizados con los conceptos 10 Aun cuando los datos de industria fiables son difíciles de encon
básicos de gestión de proyectos revisen en este m om ento el Capí trar, es seguro decir que este porcentaje e s considerablem ente mayor
tulo 3. que el que s e encuentra en el trabajo del software convencional.
534
CAPÍTULO 29 I N GE NI E RÍ A WEB
experiencias anteriores con proyectos similares—. Pero una WebApp con éxito. Esta información deberá de
casi todas las WebApps tienen que ser innovadoras documentarseen una especificacióndel producto.
—ofreciendo algo nuevo y diferente a aquellos que la 2. S e d e b e r á d e s a r r o lla r in te r n a m e n te u n d is e ñ o a p r o
utilizan—. De aquí que la estimación experimental, aun d e l a W e b A p p . Obviamente una persona
x im a d o
que sea Útil, está abierta a errores considerables. Por expertaen el desarrollodeWebApps creará un diseño
consiguiente, ¿cómo se derivan estimaciones fiables?, completo, pero puede ahorrar tiempo y dinero iden
¿con qué grado de seguridad pueden cumplirse los pro tificando el aspecto e interacción general de la
gramas temporales definidos? WebApp para el proveedor de subcontratación (esto
En tercer lugar, el análisis de riesgos y la programa siempre puede modificarse durante las etapas preli
ción temporal se predican bajo un entendimiento claro minares del proyecto). El diseñodeberáincluir la indi
del ámbito del proyecto. Y sin embargo, la característi cación del proceso interactivo que se va a llevar a
ca de «evolución continua» tratada en la Sección 29.1 cabo (por ejemplo, formularios, entrada de pedidos).
sugiere que el ámbito de la WebApp sea fluido. ¿Cómo 3 . S e d e b e r á d e s a r r o lla r u n a p la n ific a c ió n t e m p o r a l a p r o
pueden controlar los costes la organización contratista x im a d a d e l p r o y e c t o , in c lu y e n d o n o s o lo la s f e c h a s
y el proveedor subcontratado?, y ¿cómo pueden plani f in a l e s d e e n t r e g a ,s in o ta m b ié n la s fe c h a s h it o ( s ig n i
ficar el momento en que es probable que los requisitos Los hitos deberán adjuntarse a las versiones
f ic a t iv a s ) .
cambien drásticamente a lo largo del proyecto?, ¿cómo de entregaposibles a medida que avanza el proyecto.
se puede controlar el cambio del ámbito?, y lo que es
4 . S e d e b e r á id e n t if i c a r e l g r a d o d e s u p e r v is ió n e in t e
más importante, dado su naturaleza ¿deberán contro
larse los sistemas y aplicaciones basados en Web ? Deberá
r a c c ió n d e l c o n tr a tis ta c o n e l p r o v e e d o r .
Llegado a este punto de gestión de proyectos para incluirse el nombre del contacto del proveedor y la
WebApps, las preguntas que se han formulado por las identificación de la responsabilidad y autoridad del
diferencias destacadas anteriormente no son fáciles de contacto, la definición de los puntos de revisión de
responder. Sin embargo, merece la pena tener en con calidad a medida que el desarrollo va avanzando, y
sideraciónuna serie de líneas generales. la responsabilidad de los proveedores enrelación con
la comunicación entre organizaciones.
Inicio de un proyecto. Aun cuando la subcontrata-
Toda la información desarrollada en los pasos ante
ción sea la estrategia elegida para el desarrollo de riores deberá de organizarse en una s o l i c i t u d d e o p c i o
WebApps, una organización deberá realizar una serie n e s que se transmite a los proveedores candidatos” .
de tareas antes de buscar el proveedor de subcontrata-
ción para hacer el trabajo.
p f e í
B
1. M u c h a s d e la s a c t iv id a d e s d e a n á lis is t r a t a d a s e n la
Se
S e c c ió n 2 9 . 3 s e d e b e r á n r e a li z a r in t e r n a m e n t e . ; -v ■ - g a pagar por cacahuetes,
identifica el público de la WebApp; se confecciona un v- .nono.
listado de aquellos con intereses internos en la nffijSppr I».
WebApp; y se defineny revisan las metas globales de
la WebApp; se especifica tanto la información como Selección entre los proveedores de subcontrata
los servicios que se van a proporcionaren laWebApp; ción candidatos. En los últimos años han surgido miles
se destacan los sitios Web rivales, y se definen las de compañías de «diseño Web» para ayudar a las empre
«medidas» cuantitativas y cualitativas para obtener sas a establecer una presencia y/o implicación Web en
el comercio electrónico. Muchas han llegado a tener
adicciónpor el proceso IWeb, mientras que otras muchas
se asemejan a los intrusos informáticos ( h a c k e r s ) . Con
objeto de seleccionar el desarrollador de Web candida
: -A: ( « m i consejo pora los constructores
to, el contratistadeberá llevar a cabo una diligencia obli
mj¡ÉI0 si? 1, Establecer los requisitos gada: (1) entrevistar a los clientes antiguos para
f . l M : ; - v # fiv ente 2. Conseguir
determinar la profesionalidad del proveedor de Web, la
S ¡ p t f i i# -':.* toles 3. Utilizar proveedores
habilidad de cumplir los compromisosde horarios y cos
:í demostrada. 4. Construir y ampliar
tes, y la habilidad de comunicarseeficazmente; (2) deter
I f p É f a sTpor etapas evolutivas. 5. Tener
minar el nombre del ingenierojefe de Web del proveedor
: j i f Jeredimdoncia sistemática adecuarla
f (y '?. i.-és jara permitir algún grado
de proyectos anterior con éxito (y después cerciorarse
• i cuando aparezcan errores.
de que esta persona se vea obligada mediante contrato
pÉi Sil
a su implicación en el proyecto), y (3) examinar cuida
dosamente las muestras de trabajo del proveedor simi-
www.FreeLibros.org
11 Si el trabajo de desarrollo de la W ebApp e s dirigida por un grupo
interno, nada cam bia. El proyecto se inicia de la m ism a m anera.
535
lares en aspecto e interacción (y en área de negocios) a «temporalmente».Este enfoque hace posible que el equi
la W ebApp que se va a contratar. Antes incluso de que po de la WebApp trabaje sin tener que aceptar una corrien
se vaya a establecer la oferta, una reunión cara a cara te continua de cambios,pero reconociendo la característica
puede proporcionar una buena im presión para que el de evolución continua de la mayoría de las WebApps.
contratista y el proveedor conecten bien. Las líneas generales sugeridas anteriormente no pre
Evaluación de la validez de las ofertas de precios tenden ser un recetario a prueba de tontos para WebApps
y de la fiabilidad de las estim aciones.Dado que exis puntuales y con una producción a un coste bajo. Sin
ten muy pocos datos históricos y el ám bito de las embargo, ayudarán tanto al contratista como al provee
WebApps es notoriam ente fluido, la estim ación es inhe dor a iniciar el trabajo suavem ente con unos conoci
rentem ente arriesgada. Por esta razón algunos provee m ientos mínimos.
dores incorporarán m árgenes sustanciales de seguridad
en las ofertas de precios de un proyecto. Evidentem en 29.7.3. P r o b le m a s G C S p a ra la IWEb
te esto es comprensible y adecuado. L a pregunta no es Durante la últim a década, las W ebApps han evolucio
si tenemos la mejor solución para nuestra inversión, sino nado y han pasado de utilizar dispositivos informales
la serie de preguntas que se m uestran a continuación: para la difusión de inform ación a utilizar sitios sofisti
• ¿Es el coste acordado una buena oferta para propor cados para el com ercio electrónico. A m edida que las
cionar un beneficio directo o indirecto sobre la inver W ebApps van creciendo en im portancia para la super
sión y justificar así el proyecto? vivencia y el crecimiento de los negocios, también cre
• ¿Es el proveedor de la oferta una m uestra clara de la ce el control de la configuración. ¿Por qué? Porque sin
profesionalidad y experiencia requeridos? controles eficaces cualquier cam bio inadecuado en una
W ebApp (recordemos que la inm ediatez y la evolución
Si la respuesta es «sí», el precio ofertado es justo.
continua son los atributos dom inantes de muchas
El grado de gestión del proyecto que se puede espe
WebApps) puede conducir a: (1) una ubicación no auto
rar o realizar. La formalidad asociada con las tareas de
rizada de la inform ación del producto nuevo; (2) u n a
gestión del proyecto (llevadas a cabo tanto por el provee
funcionalidad errónea y pobremente com probada que
dor como por el contratista) es directamente proporcional
frustra a los visitantes del sitio W eb; (3) agujeros de
al tamaño, coste y complejidad de la WebApp. Para pro
seguridad que ponen en peligro a los sistemas internos
yectos complejos y grandes deberá desarrollarse una pla
de las com pañías, y otras consecuencias económ ica
nificación que defina las tareas del trabajo, los puntos de
m ente desagradables e incluso desastrosas.
comprobación, los productos de trabajo de ingeniería, los
puntos de revisión del cliente y los hitos importantes. El
proveedor y el contratista deberán evaluar el riesgo en
conjunto, y desarrollar los planes de mitigar, monitorizar Q c /f a :
y gestionar esos riesgos considerados como importantes.
k forma mós eficaz de enfrentarse
Los mecanismos para la seguridad de calidad y el control
sí cambio es ayudar a crearlo.
de cambios se deberán definir explícitamente al escribir
se. Y tendrán que establecerse métodos de comunicación
entre el contratista y el proveedor. Se pueden aplicar las estrategias generales para la
Evaluación de la planificación temporal del desa gestión de la configuración del software (GCS) descri
rrollo. Dado que las planificacionesde desarrollo de las tas en el Capítulo 9, pero las tácticas y herram ientas
WebApps abarcan un período de tiem po relativamente deberán adaptarse y ajustarse a la naturaleza única de
corto (normalmente menos de un m es o dos), la plani las W ebApps. C uando se desarrollan tácticas para l a
ficación de desarrollo deberá tener un alto grado de gra- gestión de configuración de las WebApps, deberán tener
nularidad. Es decir, las tareas del trabajo y los hitos se en consideración cuatro tem as [DA R99]: el conteni
menores se tendrán que planificar día a día. Esta grado, las personas, la escalabilidad y la política.
nularidad permite que el contratistay el proveedor reco Contenido. Una W ebApp normal contiene una gran
nozcan la reducción del tiem po de planificación antes cantidad de contenido — texto, gráficos, applets, guiones,
de que amenace la fecha de finalización. archivos de sonido y vídeo, elementos activos de pági
Gestión del ám bito. Dado que es muy probable que nas, tablas, corrientes de datos y m uchos más—. El reto
el ámbito cambie a medida que avanza el proyecto de la es organizar este m ar de contenido en un conjunto razo
WebApp, el m odelo de proceso deberá ser incremental nable de objetos de configuración (C apítulo9), y enton
(Capítulo 2). Esto permite que el equipo de desarrollo ces establecer los mecanismos de control de configuración
«congele» el ámbito para poder crear una nueva versión adecuados para estos objetos. Un enfoque será modelar
operativa de la WebApp. El incremento siguiente puede el contenido de la WebApp mediante la utilización de téc
www.FreeLibros.org
afrontar los cambios de ámbito sugeridos por una revi nicas convencionales de m odelado de datos (Capítulo
sión del incrementoprecedente, pero una vez que comien 11), adjuntando un conjunto de propiedades especializa
za el incremento, el ám bito se congela de nuevo das a cada objeto. La naturaleza estática y dinámica de
536
C A P Í T U L O 29 I NGE NI E RI A WEB
cada objeto y la longevidad proyectada (por ejem plo, en las actividades de gestión y control asociadas con la
existencia tem poral y fij a, o un objeto permanente) son IWeb. En algunos casos los diseñadores de W ebApps
ejemplos de las propiedades necesarias para establecer se encuentran fuera de la organización TI, dificultando
un enfoque GCS eficaz. Por ejem plo, si se cambia un posiblem ente la comunicación. Para ayudar a entender
objeto de contenido cada hora, se dice que tiene una lon la política asociada a IW eb, E&fc [DAR99] sugiere las
gevidad temporal. Los m ecanismos de control de este siguientes preguntas: ¿quién asum e la responsabilidad
objeto serán diferentes (menos formales) de los que se de la inform ación en el sitio Web? ¿quién asegura que
aplicaba un componente de formularios (objeto perm a los procesos de control de calidad se han llevado a cabo
nente). antes de publicarla inform ación en el sitio Web? ¿quién
es el responsable de hacer los cambios? ¿quién asume
el coste del cambio? Las respuestas ayudarán a deter
m inar qué personas dentro de la organización deberán
S esencial controlar el cambio dorante los proyectos adoptar un proceso de gestión de configuración para las
IWeb, oon coando puede hacerse de formo exagerada. WebApps.
Empiece por los procedimientosde control de cambh
La gestión de configuración para la IWeb está toda
de relativa informalidad (Capítulo 9). lo meto inicial será
vía en su infancia. Un proceso convencional de GCS
evitar los efectos de trinquete en cambios incontrolados.
puede resultar demasiado pesado y torpe. La gran m ayo
P erso n as. Dado que un porcentaje significativo del ría de las herram ientas GCS no tienen las característi
desarrollo de las WebApps continúarealizándose depen cas que perm iten adaptarse fácilmente a la IWeb. Entre
diendo del caso, cualquier persona que esté implicada los tem as que quedan por tratar se encuentran los
en la WebApp puede (y a m enudo lo hace) crear el con siguientes [DAR99]:
tenido. M uchos creadores de contenido no tienen ante • creación de un proceso de gestión de configuración
cedentes en ingeniería del software y no tienen ningún que sea lo suficientemente hábil como para aceptar la
conocimiento de la necesidad de una gestión de confi inmediatez y la evolución continua de las WebApps;
guración. La aplicación crece y cambia de forma incon
• aplicación de mejores conceptos y herram ientas de
trolada.
gestión de configuración para aquellos que desarro
E scalab ilid ad . Las técnicas y controles aplicados a llan y no están familiarizados con la tecnología;
una W ebApp pequeña no tienen buena escalabilidad. • suministro del soporte a los equipos de desarrollo de
No es muy com ún que una WebApp sencilla crezca sig W ebApps distribuidos;
nificativam ente cuando se im plementan las intercone
• suministro de control en un entorno de cuasipubli-
xiones que existen dentro de los sistem as de
cación, donde el contenido cambia de forma casi con
información, bases de datos, almacenes de datos y pasa
tinua;
relas de portales. A m edida que crece el tam año y la
complejidad, los pequeños cambios pueden tener efec • consecución de la granularidad necesaria para con
tos inalcanzables y no intencionados que pueden ser trolar una gran cantidad de objetos de configuración;
problemáticos. Por tanto, el rigor de los mecanismos de • incorporación de la funcionalidad de gestión de con
control de la configuración deberán ser directam ente figuración en las herram ientas IWeb existentes;
proporcionales a la escalabilidad de la aplicación. • gestión de cam bios en objetos que contienen enla
P olítica. ¿Quién es el propietario de una W ebApp? ces con otros objetos.
Esta pregunta se argum enta en com pañías grandes y Estos y otros temas deberán afrontarse antes de que se
pequeñas, y la respuesta tiene un im pacto significativo disponga una gestión de configuración eficaz para la IWeb.
Se puede argumentar que el im pacto de los sistemas y nadas por el contenido y están en continua evolución. La
aplicacionesbasados en Web es el acontecimiento m ás inmediatez que conduce a su desarrollóla necesidad pri
significativo en la historia de la informática. A medida m ordial de seguridad al funcionar,y la dem anda de esté
que las WebApps crecen en importancia, el enfoque de tica y la entrega del contenido fúncional son otros factores
ingeniería de Web disciplinado ha em pezado a evolu diferenciadores. Durante el desarrollode la WebApp hay
cionar — basado en principios, conceptos, procesos y tres tecnologías que se integran con otras de ingeniería
métodos que se han desarrollado para la ingeniería del del software convencional; desarrollobasado en com po
www.FreeLibros.org
software— . nentes, seguridad y lenguajes de notas estándar.
Las WebApps son diferentes de otras categorías de El proceso de ingeniería de Web com ienza con la for
software informático. Son intensivas de red, están gober mulación —una actividad que identifica las metas y los
537
objetivos de la WebApp—. La planificación estima el probación ejercita la navegación de la WebApp, inten

coste global del proyecto, evalúa los riesgos asociados tando descubrir errores en la función y el contenido, y
con el esfuerzodel desarrolloy define una programación asegurando mientras tanto que la WebApp funcione
temporal del desarrollo. El análisis establece requisitos correctamente en diferentes entornos. La ingeniería de
técnicos e identificalos objetos del contenidoque se incor Web hace uso de un modelo de proceso iterativoe incre-
porarán en la WebApp. La actividadde ingeniería incor mental porque la línea temporal del desarrollo para la
pora dos tareas paralelas: diseño del contenido y diseño WebApp es muy corta. Las actividadesprotectoras apli
técnico. La generación de páginas es una actividad de cadas durante el trabajo de la ingeniería del software
construcción que hace un uso extenso de herramientas —-SQA, GCS, gestiónde proyectos — se aplican atodos
automatizadaspara la creación de WebApps, y la com los proyectos de ingeniería de Web.
[ATK97] Atkins, D., et al., Internet Security: Professional [MUR99] Murugesan, S., WebE Home Page, http://fist-
Reference, New Riders Publishing, 2.a ed., 1997. serv.macarthur.uws.edu.au./sanAVebHome, Julio de 1999.
[BER98] Bemstein, M., «Pattems in Hypertext», Proc. 9,h [NAN98] Nanard, M., y P. Kahn, «Pushing Reuse in Hyper
A C M Conf. Hypertext, ACM Press, 1998, pp. 21-29. media Design: Golden Rules, Design pattems and cons-
tructive Templates», Proc. 9th ACM conf. On Hypertext
[BRA97] Bradley, N., TlteConcise SGML Companion, Addi-
and Hypermedia, ACM Press, 1998, pp. 11 -20.
son-Wesley, 1997.
[NIE96] Nielsen, J., y A. Wagner, «User Interface Design for
[BRE99] Brenton, C., Mastering Network Security, Sybex,
the WWW», Proc. CHI' 96 conference on Human Factors
Inc., 1999. ' '
in Computing systems, ACM, Press, 1996,pp. 330-331.
[BUS96] Buschmann, E et al., Pattern-Oriented Software
[NOR99] Norton, K., «Applying Cross Functional Metho-
Architecture, Wiley, 1996.
dologies to Web Development», Proc. l sl ICSE Works
[DAR99] Dart, S., «Containing the Web Crisis Configura- hop on Web Engineering, ACM, Los Ángeles, Mayo de
tion Management», Proc. l s' ICSE Workshopon Web engi 1995.
neering, ACM, Los Ángeles, Mayo de 199912.
[OSL99] Olsina, L. et al., «Specifying Quality Characteris-
[DIN98] Dinucci, D., M. Giudice y L. Stiles, Elements of tics and Attributes for Web Sites», Proc. l st Workshopon
WebDesign: The Designer’s Guide to a New Médium, 2.a Web Engineering, ACM, Los Ángeles, Mayo de 1995.
ed., Peachpit Press, 1998.
[PAR99] Pardi, W J.,X M L in Action, Microsoft Press, 1999.
[GAM95] Gamma, E. et ai., DesignPatterns, Addison-Wes
[POW98] Powell, T.A., WebSite engineering, Prentice-Hall,
ley, 1998.
1998.
[GNA99] Gnaho, C., y F. Larcher, «A User Centered Me-
[PRE98] Pressman, R.S. (moderador), «Can Intemet-Based
thodology for Complex and Customimizable Web Appli
Applications be Engineered?», IEEE Software, Septiem
cations engineering», Proc. ls t ICSE Workshop on Web
bre de 1998, pp. 104-110.
engineering, ACM, Los Ángeles, Mayo de 1999.
[ROS98] Rosenfeld, L., y P. Morville, Information Architec
[HAN99] Hansen,S., Y. Deshpandey S. Murgusan, «A Skills
turef o r the World Wide fiú/>,0'Reilly & Associates, 1998.
Hierarchy for Web Information system Development»,
Proc. l st ICSE Workshop on Web Engineering, ACM, Los [SAN96] Sano. D., Designing large-Scale Web Sites: A
Ángeles, Mayo de 1999. Visual Design Methodology, Wiley 1996.
[ISA95] Isakowitz, T. et al., «RMM: A M ethodology for [SCH96] Schwabe, D., G. Rossi y S. Barbosa, «Systematíc
Structured Hypermedia Design», CACM, vol. 38, n.Q 8, Hypermedia Application Design with OOHDM», Proc.
Agosto de 1995,pp. 43-44. Hypertext ' 96, pp. 116-128.
[KAE99] Kaeo, M., Designing N etw ork Security, Cisco [SP098] Spool, J.M., et al., Web Site Usability:A Desig
Press, 1999. ner’s Guide, Morgan Kaufmann Publishers, 1998.
[LOW99] Lowe,D.,«WebEngineeringorWebGardening?», [STL99] St. Laurent, S., y E. Cerami, Building X M I Appli
WebNet Journal, vol. l,n .2 2, Enero-Marzo de 1999. cations, McGraw-Hill, 1999.
[LYN99] Lynch, P.J., y S. Elorton, WebStyle Guide: Basic [TIL99] Tilley, S., y S. Huang, «On the emergence of the
Design Principlesfor Creating WebSites, Yale University RenaissanceSoftwareengineer», Proc. l s>ICSE Workshop
Press. 1999. on the WebEngineering, ACM, Los Ángeles, Mayo de 1999.
www.FreeLibros.org
12 Los procedimientos del Primer Taller ICSE sobre Ingeniería del Soft
ware se publican en la red en h ttp ://ñ stserv .m a rca rth u r.
uw s.edu.au/san/icse99-W ebE /IC SE 99-W eb-E -P roc/default.htm
538
CAP ÍTU LO 29 I NGE NI E RI A WEB
2 9 .1 . ¿Existen otros atributos genéricos que diferencien a las 29.10. Realice un análisis del contenido para HogarSegu -
W ebA pps de otras aplicaciones de software? Enum ere 2 Ó 3. roInc.com o para un sitio Web asignado por su profesor.
29.2. ¿Cóm o sejuzga la calidad de un sitio Web? C onfeccio 29.11. Sugiera tres «reglas de oro» que servirán como guía en
ne una lista de 10 atributos de calidad prioritarios que consi el diseño de WebApps.
dere más importantes.
29.12. ¿En qué difiere una configuración de diseño WebApp
29.3. Realice una pequeña investigación y realice un trabajo de una plantilla?
de 2 ó 3 páginas que resuma una de las tres tecnologías que
29.13. Seleccione un sitio Web con el que esté familiarizado
se destacaron en la Sección 29.1.2.
y desarrolle un diseño arquitectónico razonablemente com
29.4. U tilizan d o un sitio W eb real com o ejem plo, ilustre las pleto para el sitio. ¿Qué estmctura arquitectónica seleccionó
diferentes m anifestaciones del «contenido» de la W e b A p p . el diseñador del sitio?
29.5. Responda a las tres preguntas de form ulación para un 29.14. Haga una investigación breve y escriba 2 ó 3 páginas
sitio W eb con el que esté fa m ilia riza d o . D esarrolle una a fir que resuman el trabajo actual en las configuraciones de dise
m ación de ám bito para el sitio W eb. ño de las WebApps.
29.6. D esarrolle un conjunto de p e rfile s para H ogarS egu - 29.15. Desarrolle un diseño arquitectónico para HogarSegu-
roInc.com o un sitio W eb asignado por su profesor. roInc.com o para un sitio Web asignado por su instructor.
29.7. D esarrolle una lista completa de metas inform ativas y 29.16. Utilizando un sitio Web real como ejemplo, desarrolle
aplicables para H ogarSeguroInc.com o un sitio W eb asigna una crítica de su interfaz de usuario y haga una recomenda
do por su profesor. ción que lo mejore.
29.8. Elabore un conjunto de casos de uso para H ogarSegu- 29.17. Describa la manera en que una gestión de proyecto para
roInc.com o un sitio W eb asignado por su profesor. sistemas y aplicaciones basados en Web difieren de la gestión
29.9. ¿En qué difiere el análisis del contenido del análisis fu n de proyecto para el software convencional. ¿En qué se ase
cional y de interacción? meja?
Durante los últimos años se han publicado cientos de libros Menasce y Almeida (Capacity Planningfor Web Perfor
que tratan uno o más temas de ingeniería de Web, aunque mance: Metrics, Models, and Methods, Prentice-Hall, 1998)
relativamente pocos tratan todos los aspectos. Lowe y Hall tratan la valoración cuantitativa del rendimiento de las
(Hypertextand the Web:An Engineering Approach, Wiley, WepApps. Amoroso (IntrusionDetection: AnIntroduction to
1999), y Powell [POW98] abarcan razonablemente estos Internet Surveillance, Correlation, Trace Back, Traps, and
temas. Norris, West y Warson (MediaEngineering: A Quide Response, Intrusión.Net Books, 1999) proporciona una guía
to Developing Information Products, Wiley, 1997), Navarro detallada para los ingenieros de Web que están especializa
y Khan (Effective WebDesign: Master the Essentials, Sybex, dos en temas de seguridad. Umar (AppIication(Re)Enginee-
1998), Fleming y Koman (WebNavigation: Designing the ring: Building Web-Based Applications and Dealing With
User Experience, O ’Reilly & Associates, 1998), y Sano Legacies, Prentice-Hall, 1997)estudiaestrategiaspara latrans-
[SAN96] también abarcan aspectos importantes del proceso formación (reingeniería) de sistemas anteriores en aplicacio
de ingeniería. nes basadas en Web. Mosley (ClientSewer Sofware Testing
Además de [LYN99], [DIN98] y [SP098], los siguientes on the Desk Top and the Web, Prentice-Hall, 1999) ha escri
libros proporcionan una guía útil para los aspectos del dise to uno de los mejores libros que estudian los temas de com
ño de WebApps tanto técnicos como no: probación asociados con WebApps.
Baumgardt, M., Creative WebDesign: Tips and Tricks Haggard (Survival Guide to Web Site Development.,
StepbyStep, Springer Verlag, 1998. Microsoft Press, 1998) y Siegel (Secrets o f Successful Web
Donnelly, D. et al., Cutting Edge Design: TheNext Gene- Sites: Project Management on the World Wide Web, Hay-
ration, Rockport Publishing, 1998. den Books, 1997) proporcionan una guía para el gestor que
Holzschlag, M.E., Web by Design: The Complete Guide, debe de controlar y hacer un seguimiento del desarrollo de
Sybex, 1998. ' WebApps.
Niederst, J., y R. Koman, WebDesign in a Nutshell: A Una amplia variedad de fuentes de información sobre inge
Desktop Quick Reference, O’Reilly & Associates, 1998. niería de Web está disponible en Internet. Una lista amplia y
Weinman, L., y R. Prirouz, Click Here: WebCommuni- actualizada de referencias en sitios (páginas) web se puede
cation Design, New Riders Publishing, 1997. obtener en http:/www.pressman5.com.
www.FreeLibros.org
C A P IT U L O
30 REINGENIERIA
E N u n a r t í c u l o d e g r a n i m p o r t a n c i a e s c r i t o p a r a la H a r v a r d B u s in e s s R e v ie w , M i c h a e l
H a i n m e r [ H A M 9 0 ] s e n t a b a la s b a s e s p a r a u n a r e v o l u c i ó n d e l p e n s a m i e n t o a d m i n i s t r a t i
v o a c e r c a d e lo s p r o c e s o s y c o m p u t a c ió n d e lo s n e g o c io s :
Ha llegado el momento de dejar de pavimentar los senderos para vacas. En lugar de incrustar unos pro
cesos anticuados en silicio y en software, deberíamos eliminarlos y volver a empezar. Tenemos que reha
cer la ingeniería de nuestros negocios: hay que utilizar la potencia de la tecnología de'la información moderna
para rediseñar de forma radical nuestros procesos de negocios, y lograr así unas mejoras drásticas de su ren
dimiento.
Todas las compañías funcionan de acuerdo con una gran cantidad de reglas no escritas... La reingenie
ría intenta apartarse de las viejas reglas acerca de la forma en que se organizan y desarrollan nuestros ne
gocios.
A l i g u a l q u e t o d a s la s r e v o l u c i o n e s , l a l l a m a d a a la s a r m a s d e H a m m e r h a d a d o l u g a r a c a m
b io s t a n to p o s it iv o s c o m o n e g a tiv o s . A lg u n a s c o m p a ñ í a s h a n h e c h o u n e s fu e r z o le g í t i m o e n
r e h a c e r su i n g e n i e r í a , y l o s r e s u l t a d o s h a n m e j o r a d o s u c o m p e t i t i v i d a d . O t r a s s e h a n b a s a d o
ú n i c a m e n t e e n r e d u c i r la s d i m e n s i o n e s y h a c e r s u b c o n t r a t a s ( e n l u g a r d e r e h a c e r s u r e i n g e n i e
r í a ) p a r a m e jo r a r s u s b e n e fic io s . Y c o m o r e s u lta d o s e o b t u v ie r o n o r g a n iz a c io n e s r e d u c id a s c o n
p o c a s p r o b a b ilid a d e s d e c r e c e r e n m i f u t u r o [ D E M 9 5 ] ,
D u r a n t e la p r im e r a d é c a d a d e l s ig lo v e in t iu n o , e l b o m b o p u b li c i t a r io a s o c ia d o a la r e in g e
n ie r ía h a d e c a íd o , p e r o e l p r o c e s o e n s í c o n tin ú a e n c o m p a ñ ía s g r a n d e s y p e q u e ñ a s . L a u n ió n
d e la r e in g e n ie r í a c o n la in g e n ie r í a d e l s o f t w a r e s e e n c u e n t r a e n u n a « r e v i s ió n d e l s is t e m a » .
VISTAZO RAPIDO
¿Qué es? T enga e n c o n sid eració n c u a l ¿Por q u é a s im p o r t a n te ? Vivimos e n un los p ro g ra m a s e x is te n te s q u e e xhiben
quier producto d e tecnología que h a y a m undo e n constantecam bio. Las dem an una m antenibilidad d e m ayor calidad.
adquirido. Lo ve con re g u la rid a d , pero d a s d e funciones d e negocios y d e tec ¿Cuál e s e l p rod ucto o b ten id o ? Son
e s t á en v ejec ien d o . S e rom pe con fre nología de inform ación que la s soportan v a rio s los pro d u cto s q u e se e la b o ra n
c u e n c ia , ta rd a e n re p a ra rs e y y a no e s tá n c am biando a un ritm o que im po (porejem plo,m odelos an álisis, m odelos
representa la ú ltim a tecnología. ¿Q ué ne m ucha presión com petitiva en todas d e d iseñ o , procedim ientos d e pruebas).
se p u e d e h acer? Si el pro d u cto e s d e la s o rg an izacio n es com erciales. Tanto El resultado final e s un proceso d e rein
h ard w are, pro b ab lem en te lo tira rá y se los negocios como el softw areque sopor geniería d e negocios y/o el softw are d e
c o m p rará uno nuevo. Pero si e s un soft ta n (o e s )e l negocio d eb erán diseñarse re in g e n ie ría q u e lo soporta.
w a re p e rso n a liz a d o , no d isp o n d rá la una vez m ás p a ra m antener el ritmo. ¿Cómo puedo e s t a seguro d e q u e lo
opción d e tirarlo. N e c e sita rá re co n s ¿Cuáles son los pasos? La reingenieria h e h ech o correctamente?Utilizan-
truirlo. C reará un producto con una fun d e p ro c e so sd e negocios (RPN) d e fín e la s do la s m ism as prácticas que se a p lic a n
cionalidad nueva, un m ejor rendim iento m etas com erciales, identifica y e v alú a e n todos los procesos d e in g en iería del
y fiab ilid ad , y un m antenim iento m ejo los procesos d e negocios ex isten tes, y s o ftw a re —la s rev isio n es té c n ic a s for
rado. E so e s lo q u e lla m a m o s re in g e crea procesos com ercialesrevisados que m ale s e v a lú a n los m odelos d e a n á lisis
niería. m ejoran la s m etas actuales. El proceso y d e diseños, la s revisiones e sp e cializa
¿Quién lo h a ce? A nivel d e negocio, la d e reingeniería del softw are acom paña d a s tie n e n e n consideración la c a p a c i
re in g e n ie ría e s e je rc id a por e s p e c ia el a n á lisis d e inventarios, la estructura d a d d e a p lic a c ió n co m ercial y la
lis ta s d e n egocio (fre c u e n te m e n te ción de documentoc. la in g en ie ría inver c o m p atib ilid ad , y la c o m p ro b ació n se
e m p re s a s d e c o n s u lto ría ). A n iv el d e s a . la re estru c tu ra ció n d e d a to s y la a p lic a p a ra d esc u b rir los erro res e n el
softw are, la re in g e n ie ría e s e je c u ta d a ingeniería avanzada. El objetivode estas contenido, e n la fun cio n alid ad y e n la
por ingen iero s d el softw are. actividades e s crear v ersionesnuevas de interoperabilidad.
E l s o f t w a r e s u e le s e r l a r e a l i z a c i ó n d e la s r e g la s d e n e g o c i o q u e d e s c r ib e H a m m e r . A m e d i d a q u e
la s r e g la s c a m b i a n , e l s o f t w a r e t a m b i é n t i e n e q u e c a m b ia r . E n l a a c t u a l i d a d , e x i s t e n c o m p a ñ í a s i m p o r
t a n t e s q u e p o s e e n d e c e n a s d e m i l e s d e p r o g r a m a s d e c o m p u t a d o r a q u e p r e s t a n a p o y o a la s « v i e j a s
r e g la s d e l n e g o c i o » . C u a n d o lo s a d m i n i s t r a d o r e s t r a b a j a n p a r a m o d i f i c a r e s ta s r e g la s y l o g r a r a s í m í a
m a y o r e f e c t i v i d a d y c o m p e t i t i v i d a d , e l s o f t w a r e s e g u ir á e l m i s m o r i t m o . E n a l g u n o s c a s o s , e s t o i m p l i
www.FreeLibros.org
c a l a c r e a c i ó n d e s is t e m a s n u e v o s e i m p o r t a n t e s b a s a d o s e n c o m p u t a d o r a '. P e r o e n m u c h o s o t r o s , e s t o
i m p l i c a l a m o d i f i c a c i ó n y / o r e c o n s t r u c c i ó n d e la s a p l i c a c i o n e s e x is t e n t e s .
1Los sistemas y aplicaciones basados en Web estudiados en el Capítulo 29 son ejemplos contemporáneos.
541
I N GEN IE RI A DEL S O F T W A R E . UN E N F O Q U E P R A C T I C O
En este capítulo se examina la reingeniería de forma descendente, comenzando por una visión general de la reingenie
ría de procesos de negocio y pasando entonces a una discusión más detallada de las actividades técnicas que se producen
cuando se efectúa una reingeniería del software.
La R eingeniería de procesos de negocio, R P N (B usi

^CONSEJO
ness Process Reingineering, BPR2) va más allá del ámbi
to de las tecnologías de la inform acióny de la ingeniería Como ingeniero del software, eltrobojo dereingenierio
del software. Entre las muchas definiciones (la m ayo tiene lugar en lo porte Inferior de la jerorqulo.
ría de ellas, algo abstractas) que se han sugerido para la Sin embargo, asegúrese de que alguien hoyo pensado
RPN, se cuenta con una publicada en la revista Fortu seriamente en el nivel anterior. Sl no lo han hecho,
ne [STE93]: «. ..la búsqueda e im plementación de cam su trabajo corre algún riesgo.
bios radicales en el proceso de negocios para lograr un

Cada uno de los sistemas de negocios (también 11a-
avance significativo». Ahora bien ¿cómo se efectúa la
m adosfunción de negocios) están compuestos por uno
búsqueda, y cómo se lleva a cabo la implementación?
o más procesos de negocio, y cada proceso de negocio
O lo que es más importante,¿cómo podem os estar segu
está definido por un conjunto de subprocesos.
ros de que el «cambio radical» que se sugiere va a dar
La RPN se puede aplicar a cualquiernivel de lajerar
lugar realm ente a un «avance significativo» en lugar de
quía, pero a m edida que se amplía el ámbito de la RPN
conducimos a un caos organizativo?
(esto es, a medida que se asciende dentro de lajerarquía)
los riesgos asociados a la RPN crecen de forma dramáti
Q cfto: ca. Por esta razón, la mayor parte de los esfuerzos de la

RPN se centran en procesos o subprocesos individuales.
: e moñona con !o ¡dea de utilizar
£ g |jfK < b ayer es ver la vida paralizada 30.1.2. Principios de reingeniería de procesos
J mmsMI de negocios
En muchos aspectos, la RPN tiene un objetivo y un ámbi
30.1.1. Procesos de negocios to idéntico al proceso de la ingeniería de la información
Un proceso de negocio es «un conjunto de tareas lógi (Capítulo 10). Lo ideal sería que la RPN se produjera de
camente relacionadas que se llevan a cabo para obtener forma descendente, comenzando por la identificación de
un determ inado resultado de negocio» [DAV90]. D en los objetivos principales del negocio, y culminando con
tro del proceso de negocio, se combinan las personas, una especificaciónmucho más detallada de las tareas que
los equipos, los recursos m ateriales y los procedim ien definen un proceso específico de negocios.
tos de negocio con objeto de producir un resultado con Ham m er [HAM90] sugiere una serie de principios
creto. Entre los ejem plos de negocio se incluyen el que nos guiarán por las actividades de la RPN cuando
diseño de un nuevo producto, la adquisición de servi se com ienza en el nivel superior (de negocios):
cios y suministros, la contratación de nuevos em plea O rganización en to m o a los resultados, n o en torno a las
dos o el pago a proveedores. C ada una requiere un tareas. Hay muchas compañías que poseen actividades de nego
cio compartimentadas,de tal modo que no existe una Única
conjunto de tareas y se basa en diversos recursos den
persona (u organización)que tenga la responsabilidad (oel con
tro del negocio. trol) de un cierto resultado de negocio. En tales casos, resulta
Cada proceso de negocio posee un cliente bien defi difícil determinar el estado del trabajo e incluso más difícil
nido —una persona o grupo que recibe el resultado (por depurarlos problemas de proceso cuando esto sucede. La RPN
ejemplo: una idea, un informe, un diseño, un produc deberá diseñar procesos que eviten este problema.
to)— . Además, los procesos de negocio cruzan los lím i H a y que h a c e r que quienes utilicen la salida d el proceso
tes organizativos. Requieren que distintos grupos de la lle v en a cabo e¡proceso. El objetivo de esta recomendación es
organizaciónparticipen en las «tareas lógicamente rela permitir que quienes necesítenlas salidas del negocio contro
len todas las variables que les permitan obtener esa salida de
cionadas» que definen el proceso. forma temporalmente adecuada. Cuanto menor sea el número
En el Capítulo 10 se indicaba que todo sistema es en de personas distintas implicadas en el proceso, más fácil será
realidad una jerarquía de subsistemas. El negocio glo el camino hacia un resultado rápido.
bal se puede segm entar de la siguiente manera:
El negocio
sistemas de negocio
proceso de negocio
Referencia Mfefe
www.FreeLibros.org
subprocesos de negocio Poro encontrar uno extensa información
sobre lo reingenierío de procesosde negocios
' BPR, en castellanoRPN visite la dirección w w w .b rin t.c o m /B P R .h tm
542
CAPITULO 30 R EI N G EN IE RI A
H a y que in co rp o ra r el trabajo de p ro c e sa m ien to de infor Identificación de procesos. E n esta actividad se iden

m ación a l trabajo real que p ro d u c e la inform ación p u ra . A tifican los procesos críticos para alcanzar los ob jetiv o s
medida que la TI se distribuye, es posible localizar la mayor definidos en la definición del negocio, A con tin u ació n ,
parte del procesamiento de información en el seno de la orga
nización que produce los datos. Esto localiza el control, redu
p ueden recib ir prioridades en función de su im portan
ce el tiempo de comunicación y la potencia de computación se cia, necesidad de cam bio, o c u a lq u ier otra fo rm a que
pone en manos de quienes tienen fuertes intereses en la infor resulte adecuada para la actividad de reingeniería.
mación producida.
H a y que m a n ip u la r recursos geográficam ente d ispersos
com o s i estuviesen centralizados. Las comunicaciones basa
das en computadoras se han sofisticado tanto que es posible
situar grupos geográficamentedispersos en una misma «ofici
na virtual», Por ejemplo, en lugar de emplear tres turnos de
ingeniería en una única localización, toda la compañía podrá
tener un turno en Europa, un segundo turno en Norteaménca
y tui tercertumo en Asia. En todos los casos, los ingenierostra-
bajarán durante el día y se comunicarán empleando redes de
un elevado ancho de banda.
íon pronto como vemos lo existencia de oigo

vtqo' en algo nuevo, nos tranquilizamos.
fradriscti WÜtidm NieUsthe
H a y que enlazar las actividadesparalelas en lugar de inte

g ra r sus resultados. Cuando se utilizan diferentes grupos de
empleados para realizar tareas en paralelo, es esencial diseñar
un proceso que exija una continuación en la comunicación y
coordinación. En caso contrario, es seguro que se producirán
problemas de integración. E valuación de procesos. L o s p ro c eso s e x iste n te s
d e b e rá n a n a liz a rse y m e d irse e x h a u stiv a m e n te . L as
H a y que p o n e r el p u n to de decisión en el lu g a r donde se
efectúa el trabajo, e in co rp o ra r el control a l p roceso. Dentro
tareas de procesos se id entificarán;los costes y los tie m
de lajerga del diseño del software, esto sugiere una estructura pos co n su m id o s p o r las tareas de p ro ceso se anotarán
organizativa más uniforme y con menos factorización. cuidadosam ente, y se aislarán los problem as de calidad
H a y que c a p tu ra r los d a to s una sola vez, en el lugar d o n y rendim iento.
de se p rod ucen. Los datos se deberán almacenar en computa Especificación y diseño de procesos. B asándose en la
doras, de tal modo que una vez recopilados no sea necesario inform aciónobtenida durante las tres prim eras actividades
volver a introducirlos nunca.
de la RPN, se prepararán casos prácticos (Capítulo 1 Ijpara
Todos y cada u no de los princip io s anteriores re p re cada uno de los procesos que se tengan que rediseñar. D en
sentan una visión «totalm ente general» de la RPN. U na tro del contexto de la R PN , los casos prácticos identifican
vez informados por estos principios, los planificadores de un escenario que proporciona resultados a un cliente. Con
negocios y los diseñadores de procesos deberán em pezar el uso de casos prácticos com o especificacióndel proceso,
a procesar el nuevo diseño. E n la sección siguiente, se se diseña un nuevo conjunto de tareas (que se ajustan a los
examinará el proceso de R PN m ás detalladam ente. principios indicados en la Sección 30.2.1) para el proceso.
Creación de prototipos. Es preciso construir un pro
30.1.3. Un m o d e lo d e RPN totipo del proceso de negocios rediseñado antes de in te
Al igual que la m ay o ría de las actividades de in genie g rarlo p o r co m p leto en el negocio. E sta activ id ad
ría, la rein g en iería de p rocesos de neg o cio es iterativa. «com prueba»el proceso para que sea posible efectuar refi
Los objetivos de negocio, y los p rocesos que los logran, nam ientos. ■
deberán adaptarse a un entorno de neg o cio cam biante. R efinam ientoe instanciación. B asándose en la re a -
Por esta razón, no existe ni p rincipio n i fin en la R PN lim entación procedente del prototipo, se refin a el p ro
- s e trata de un p roceso evolutivo— . E n la F igura 30.1 ceso de negocio y después se instancia en el seno de un
se representa un m odelo de rein g en iería de procesos de sistem a de negocio.
negocio. E ste m odelo define seis actividades: En algunas ocasiones las actividades de RPN descritas
Definición del negocio. L os objetivos de negocios anteriorm ente se utilizan ju n to con herram ientas de análi
se identifican en un c o n tex to de cu atro c o n tro lad o res sis del flujo de trabajo. El objetivo de estas herram ientas
principales: reducción de costes, reducción de tiem pos, es construir un m odelo del flujo de trabajo existente, en un
www.FreeLibros.org
mejora de ca lid a d y desarrollo y p o te n c ia c ió n del p e r esfuerzo por analizar m ejor los procesos existentes. A de
sonal. L os o b jetiv o s se p u e d e n d e fin ir en el n iv el de m ás, para im plem entar las cuatro prim eras actividades des
negocios o p ara un com ponente específico del negocio. critas en el m odelo de procesos se pueden u tilizar las
543
ING E NI E RI A DEL SO FTW AR E. UN E N F O Q U E P R Á C T I C O
técnicas de m odelado que se asocian norm alm ente a las dos por la evidencia empírica. Para muchas compañías parece
actividades de ingeniería de la inform ación tales com o la que la bala de plata no da en el blanco.
planificació n de estrategias de inform ación y el análi Para otras, sin embargo, el nuevo esfuerzo de la reingenie
sis de áreas de negocios (Capítulo 10). ría ha tenido evidentemente su fruto...
L a RPN puede funcionar, si es aplicada por personas
30.1.4. Advertencias m otivadas y form adas, que reconozcan que el proceso de
E s m uy frecuente que se exagere la im p o rtan cia de un reingeniería es una actividad continua. Si la RPN se lle
nuevo en fo q u e de n e g o cio - e n este caso, la R P N — va a cabo de form a efectiva, los sistem as de información
co m o si fu ese la p an acea, p a ra d esp u és c ritic a rla con se integran m ejo r con los procesos de negocios. Dentro
tanta severidad que pase a ser un desecho. A lo largo de del contexto de una estrategiam ás am plia de negocios se
los U ltim os años, se ha d eb atid o de fo rm a ex ag erad a puede exam inar la reingeniería de aplicacionesm ás anti
acerca de la eficacia de la R PN (por ejem plo: [BLE93] guas, y tam bién se pueden establecer de form a inteligente
y [D IC95]). E n un resu m en excelente del caso a favor las prioridades de reingeniería del softw are.
y en contra de la R PN , W eisz (W E I95) expone su argu A unque la reingeniería de negocio sea una estrate
m ento de la m an era siguiente: gia rechazada p o r una com pañía, la reingeniería del soft
w are es algo que d e b e h ac erse. E x isten decen as de
Resulta tentador atacar a la RPN como si se tratase de otra
m illares de sistem as heredados — aplicaciones crucia
reencarnación de la famosa bala de plata. Desde varios puntos
de vista — pensamiento de sistemas, tratamiento de personal, les para el éxito de negocios grandes y p e q u e ñ o s - que
simple historia— habría que predecir unos índices de fallos se v en a fe cta d o s p o r una e n o rm e n ece sid ad de ser
elevados para el concepto, índices que parecen ser confirma reconstruidos o rehechos en su totalidad.
,.30..2 BEING.EMIEJUA.D EL S.0FXW&BJE

Este escenario resu lta sum am ente conocido: U n a apli debajo de la superficie. A principios de los años 70, el
cación h a dado servicio y h a cubierto las necesidades iceberg de m antenim iento era lo suficientem ente gran
del negocio de una com pañía durante diez o quince años. de com o p ara h undir un portaaviones. En la actualidad
A lo largo de este tiem po, h a sido corregida, adaptada po d ría hundir toda la A rm ada.
y m ejorada m u chas veces. L as personas se d ed icaban a El m antenim iento del softw are existente puede dar
esta tarea con la m ejo r de sus intenciones, pero las prác cuenta de m ás del 6 0 p o r 100 de las inversiones efec
ticas de ing en iería del softw are buenas siem pre se echa tuadas p o r una organización de desarro llo , y ese por
ban a un la d o (p or la u rg e n c ia de o tro s p ro b lem as). centaje sigue ascendiendo a m edida que se produce más
A ho ra la aplicación se h a vuelto inestable. Sigue fu n so ftw a re [H A N 93]. L os lecto res que ten g an m enos
cionando, pero cada vez que in ten ta efectu ar un cam conocim ientos en estos tem as podrían preguntarse por
bio se producen efectos colaterales graves e inesperados. qué se necesita tanto m antenim iento,y por qué se invier
¿Q ué se p uede hacer? te ta n to esfuerzo. O sborne y C hifosky [OSB90] ofre
L a im p o sib ilid ad de m an ten er el softw are no es un cen una respuesta parcial:
problem a nuevo. D e hecho, el gran interés p o r la rein Gran parte del software del que dependemos en la actua
geniería del softw are ha sido g enerado p o r un «iceberg» lidad tiene por término medio entre diez y quince años de
de m antenim iento de softw are que lleva creciendo d es antigüedad. Aun cuando estos programas se crearon emple
de hace m ás de trein ta años. ando las mejores técnicas de diseño y codificación conoci
das en su época (y la mayoría no lo fueron), se crearon
cuando el tamaño de los programas y el espacio de alma
cenamiento eran las preocupaciones principales. A conti
nuación, se trasladaron a las nuevas plataformas, se ajustaron
para adecuarlos a cambios de máquina y de sistemas ope
G s á m tá a W tk J rativos y se mejoraron para satisfacer nuevas necesidades
del usuario; y todo esto se hizo sin tener en cuenta la arqui
SEI ofrece una variedad de recursos
tectura global.
de reingeniería del software en la
dirección: www.sei.cmu.edu/reengineering/
El resultado son unas estructuras muy mal diseñadas, una
mala codificación, una lógica inadecuada, y una escasa docu
mentación de los sistemas de software que ahora nos piden
que mantengamos en marcha ...
30.2.1. Mantenimiento del software
H ace casi trein ta años, el m antenim iento del softw are L a naturaleza ubicua del cam bio subyace en todos
se caracterizaba [CA N 72] p o r ser co m o un «iceberg». los tipos de trabajo del softw are. El cam bio es algo ine
www.FreeLibros.org
Esperábam os que lo que era inm ediatam ente visible fue vitable cuando se construyen sistem as basados en com
ra de v erd ad lo que había, pero sabíam os que un a enor putadoras; p o r tanto debem os desarrollar m ecanism os
m e m a sa de p o sib le s p ro b lem as y c o ste s y a c ía p o r para evaluar, controlar y realizar m odificaciones.
544
CAPÍTULO 30 R EI N G EN IE R IA
• A ntes de derribar y de construir to d a la casa, a seg ú

rese de que la estructura está en m al estado. Si la casa
*;•. f potfad áa mmfenimiento y de comprensión son tiene una buena estructura, quizá sea p o sib le rem o-
® 0t¡^ÉS pactóos: cuanto más difícil sea de aprender delarla sin reconstruirla (con un coste m uy in ferio r
más é M será de mantener. y en m ucho m enos tiem po).
• A n tes de em p ez ar a re co n stru ir, a se g ú re se d e que
en tien d e la fo rm a en que se c o n stru y ó el o rig in a l.
Al leer los párrafos anteriores, un lector podría argu E ch e u n a o je a d a p o r d etrás de las p are d es. C o m
mentar: « .. .pero y o no invierto el 60 p o r 100 de mi tiem prenda el cableado, la fontanería y los detalles in ter
po corrigiendo errores de los program as que desarrollo». nos de la estructura. Aunque vaya a elim inarlos todos,
Por supuesto, el m antenim iento del softw are es algo que la id e a que h a y a adq u irid o de e llo s le se rv irá n de
va m ucho m ás allá de «corregir errores». El mantenim iento m ucho cu an d o em piece a construirla.
se puede d efin ir d escribiendo las cuatro actividades • Si em pieza a reconstruir, utilice tan solo los m ateria
[SWA76] que se em prenden cuando se publica un progra les m ás m odernos y de m ayor duración. Q uizá ahora
m a para su utilización. En el C apítulo 2 se definieron cua le cuesten un poquito m ás, pero le ayudarán a evitar
mantenimiento
tro actividades diferentes de mantenimiento: un m antenim ientocostoso y lento en fecha posterior.
correctivo, mantenimientoadaptativo, mejoras omante • Si h a d ecid id o reconstruir, tenga una actitud d isc i
nimientodeperfeccionamientoy mantenimientopreventi- plinada. U tilice p rá ctica s que den co m o resu ltad o
vo o reingeniería. Tan sólo el 20 p o r 100 de nuestros un a gran calidad — tanto hoy com o en el futuro— .
esfuerzos de mantenimiento se invertirán «corrigiendo erro
res». El 8 0 p o r 100 se dedicará a adaptarlos sistem asexis-
tentes a los cam bios de su entorno externo, a efectuar las
m ejoras solicitadaspor los usuarios y a rehacer la ingenie las pasas para una casa indicados aquí son obvios.
ría de las aplicacionespara su posterior utilización. C uan Asegúrese de que su consideraciónsobre el software
do se considera que el m antenim iento abarca todas estas anticuada aplica pasos que sean ton obvios. Píenselo.
actividades, es fácil v er p o r qué absorbe tanto esfuerzo. Hay mucha dinero en juego.
30.2.2. Un m o d elo d e p ro ce so s d e r e in g e n ie r ía A u n q u e lo s p rin c ip io s a n te rio re s se ce n tran en la

reconstrucción de una casa, son aplicables igualm ente
d e l so ftw a r e
a la reingeniería de sistem as y aplicaciones basados en
La rein g en iería requiere tiem po; conllev a un coste de com putadoras.
d in ero e n o rm e y ab so rb e re c u rso s que de o tro m o d o Para im plem entar estos principios, se aplica un m odelo
p o d rían em plearse en preocupaciones m ás inm ediatas. de proceso de reingeniería del software que define las seis
P or to d as e sta s razo n es, la re in g e n ie ría n o se llev a a actividades m ostradas en la Figura 30.2. En algunas oca
cabo en unos pocos m eses, n i siq u iera en unos pocos siones, estas actividades se producen de form a secuencial
años. L a rein g en iería de sistem as de inform ación es una y lineal, pero esto no siempre es así. Por ejemplo, puede ser
actividad que absorberá recursos de las tecnologías de que la ingeniería inversa (la comprensión del funcionamiento
la inform ación durante m uchos a ñ o s. E sta es la razón interno de un programa) tenga que producirse antes de que
p o r la cu al to d a o rg a n iz a c ió n n e c e sita u na estrateg ia pueda com enzar la reestructuración de documentos.
p rag m ática p ara la rein g en iería del softw are. El paradigm a de la reingeniería m ostrado en la figu
U na estrategia de trabajo tam bién acom paña al m ode ra es un m odelo cíclico. E sto significa que cada una de
lo de procesos de rein g en iería. M ás ad elan te, en esta las actividades presentadas com o parte del paradigm a
m ism a sección, se describ irá este m odelo, pero veam os pueden rep e tirse en o tras ocasiones. P ara u n cic lo en
en p rim er lug ar algunos de los principios básicos. particular, el proceso puede term inar después de c u a l
L a reingeniería es una tarea de reconstrucción, y se quiera de estas actividades.
podrá com prender m ejo r la reingeniería de sistem as de
A nálisis d e in v e n ta rio . Todas las organizaciones de
inform ación si tom am os en consid eració n una activi
softw are deberán disponer de un inventario de todas sus
dad análoga: la reconstru cció n de una casa. C onsidere
aplicaciones. El inventario puede que no sea m ás que una
m os la situación siguiente:
hoja de cálculo con la inform ación que proporciona una
S u p o n g a que h a ad q u irid o u n a casa en o tro lugar.
descripción detallada (por ejem plo: tam año, edad, im por
N unca ha llegado a v er la finca realm ente, pero la co n
tancia para el negocio) de todas las aplicaciones activas.
siguió p o r un precio sorprendentem entereducido, advir
tiéndosele que q u izá fu era p reciso reco n struirla en su
totalidad. ¿C óm o se las arreglaría?
• A ntes de em pezar a construir, sería razonable inspec
www.FreeLibros.org
cionar la casa. Para determ inar si necesita una recons
trucción, usted (o un inspector profesional) creará una
lista de criterios para que la inspección sea sistemática. Análisis de inventario
545
L o s c a n d id a to s a la re in g e n ie ría a p a re c e n c u a n d o se Ingeniería inversa. E l té rm in o «in g en ie ría inversa» tie

o rd e n a e sta in fo r m a c ió n e n fu n c ió n d e su im p o rta n c ia ne sus orígenes en el m u n d o d e l h ard w are. U n a cie rta c o m
p a ra e l n e g o c io , lo n g e v id a d , m a n te n ib ilid a d a c tu a l y p a ñ ía d e se n sa m b la u n p ro d u c to de h a rd w a re c o m p e titiv o
otros c rite rio s lo c a lm e n te im p o rtan tes . E s entonces c u a n en un e s fu e rzo p o r c o m p re n d e r los-«secretos» d e l diseño
d o es p o s ib le a s ig n a r re cu rso s a las a p lic a c io n e s c a n d i- y fa b ric a c ió n d e su c o m p e tid o r. E stos secretos se po d rán
d atas p a ra e l tra b a jo d e re in g e n ie ría . c o m p re n d e r m ás fá c ilm e n te si se o b tu v ie ra n las esp e cifi
E s im p o rta n te d e s ta c a r que e l in v e n ta rio d e b e rá r e v i c ac io n e s de d is e ñ o y fa b ric a c ió n d e l m is m o . P e ro estos
sarse c o n re g u la rid a d . E l estad o de las a p lic a c io n e s (p o r d o c u m en to s son p riv a d o s , y n o están d isp o n ib les p a ra la
e je m p lo , la im p o rta n c ia c o n re s p e c to a l n e g o c io ) p u e c o m p a ñ ía que e fe c tú a la in g e n ie ría in ve rs a. E n ese n cia ,
d e c a m b ia r e n fu n c ió n d e l tie m p o y , c o m o re s u lta d o , u n a ingeniería in versa con é x ito precede de una o m ás espe
c a m b ia rá n ta m b ié n las p rio rid a d e s p a ra la re in g e n ie ría . c ific a c io n e s d e d is e ñ o y fa b ric a c ió n p a ra e l p ro d u c to ,
m e d ia n te e l e x a m e n de e je m p lo s reales de ese p ro d u cto .
L a in g e n ie ría in v e rs a d e l s o ftw a re es a lg o b a stan te
s im ila r. S in e m b a rg o , e n la m a y o r ía d e los casos, e l p ro
g ra m a d e l c u a l h a y q u e h a c e r u n a in g e n ie ría in v e rs a no
es e l d e u n r iv a l, s in o , m á s b ie n , e l p ro p io tra b a jo de la
c o m p a ñ ía (c o n fr e c u e n c ia e fe c tu a d o h ace m u c h o s años).
L o s « s e c re to s » que h a y que c o m p re n d e r re s u lta n in c o m
p re n s ib le s p o rq u e n u n c a se lle g ó a d e s a rro lla r u n a espe
c ific a c ió n . C o n s ig u ie n te m e n te , la in g e n ie ría in v e rs a del
s o ftw a re es e l p ro c e s o d e a n á lis is d e u n p ro g ra m a con
e l fin d e c re a r u n a re p re s e n ta c ió n d e p ro g ra m a c o n un
n iv e l d e a b s tra c c ió n m á s e le v a d o q u e e l c ó d ig o fu e n te .
L a in g e n ie ría in v e rs a es u n p ro c e s o d e re c u p e ra c ió n de
dise ñ o . C o n las h e rra m ie n ta s d e la in g e n ie ría in v e rs a se
F IG U R A 3 0 . 2 . Un m o d e lo de proceso de reingeniería e x tra e rá d e l p ro g ra m a e x is te n te in fo r m a c ió n d e l diseño
de softw are. a rq u ite c tó n ic o y d e p ro c e s o , e in fo r m a c ió n d e los datos.
R eestructuracióndel código. E l tip o m ás c o m ú n de
re in g e n ie ría (e n re a lid a d , la a p lic a c ió n d e l té rm in o re in
R eestructuración de docum entos. U n a d o c u m e n
g e n ie ría s e ría d is c u tib le e n este c as o ) es la re e s tru c tu
ta c ió n escasa es la m a rc a d e m u c h o s sistem as h e re d a
ra c ió n d e l c ó d ig o . A lg u n o s sistem as h e re d a d o s tie n e n
dos. ¿ Q u é se p u e d e h a c e r al respecto?
u n a a rq u ite c tu ra de p ro g ra m a re la tiv a m e n te s ó lid a , pero
O p c ió n n ° 1 : La creación de documentación consume
lo s m ó d u lo s in d iv id u a le s h a n s id o c o d ific a d o s de una
muchísimo tiempo. El sistema funciona, y ya nos apañaremos
fo r m a q u e h a ce d if íc il c o m p re n d e rlo s , c o m p ro b a rlo s y
con lo que tengamos. En algunos casos, éste es el enfoque
correcto. N o es posible volver a crear la documentación para m a n te n e rlo s . E n estos casos, se p u e d e re e s tru c tu ra r el
cientos de programas de computadoras. Si un programa es rela c ó d ig o u b ic a d o d e n tro de lo s m ó d u lo s sospechosos.
tivamente estático está llegando al final de vida útil, y no es P a ra lle v a r a c a b o e sta a c tiv id a d , se a n a liz a e l c ó d i
probable que experimente muchos cambios: ¡dejémoslo así!
g o fu e n te m e d ia n te u n a h e rra m ie n ta de rees tru ctu rac ió n ,
O p c ió n ñ ? 2 : Es preciso actualizar la documentación, pero
se in d ic a n las v io la c io n e s d e las e stru ctu ra s de p ro g ra
se dispone de recursos limitados. Se utilizará un enfoque «del
tipo documentar si se modifica». Quizá no se necesario volver m a c ió n e s tru c tu ra d a , y e n to n c es se re e s tru c tu ra e l c ó d i
a documentar por completo la aplicación. Más bien se docu g o (e s to se p u e d e h a c e r a u to m á tic a m e n te ). E l c ó d ig o
mentarán por completo aquellas partes del sistema que estén re e s tru c tu ra d o re s u lta n te se re v is a y se c o m p ru e b a para
experimentando cambios en ese momento. La colección de a s e g u ra r q u e n o se h a y a n in tr o d u c id o a n o m a lía s . Se
documentos Útil y relevante irá evolucionando con el tiempo. a c tu a liz a la d o c u m e n ta c ió n in te rn a d e l c ó d ig o .
O p c ió n n .2 3 :E1 sistema es fundamental para el negocio, y
es preciso volver a documentarlo por completo. En este caso, R eestructuraciónde datos. U n p ro g ra m a q ue posea
un enfoque inteligenteconsiste en reducir la documentación al u n a e s tru c tu ra d e datos d é b il será d if íc il d e a d ap tar y de
mínimo necesario. m e jo ra r. D e h e c h o , p a ra m u c h a s a p lic a c io n e s , la a rq u i
te c tu ra de d a to s tie n e m á s q u e v e r c o n la v ia b ilid a d a
la rg o p la z o d e l p ro g ra m a q u e e l p ro p io c ó d ig o fu en te.
Cree sólo la documentación que necesite A d ife re n c ia d e la re e s tru c tu ra c ió n d e c ó d ig o , que se
para mejorar su comprensión sobre el software p ro d u c e e n u n n iv e l re la tiv a m e n te b a jo de abstracción ,
No para mamar una pógino más. la e s tru c tu ra c ió n de d a to s es u n a a c tiv id a d d e re in g e
n ie ría a g ra n escala. E n la m a y o ría d e lo s casos, la rees
www.FreeLibros.org
T o d a s y c a d a u n a d e estas o p c io n e s son v ia b le s . L a s tr u c tu ra c ió n d e d a to s c o m ie n z a p o r u n a a c tiv id a d de
o rg a n iz a c io n e s d e l s o ftw a re d e b e rá n s e le c c io n a r a q u e in g e n ie r ía in v e rs a . L a a rq u ite c tu ra d e d a to s a c tu a l se
l l a que re s u lte m á s a d e c u a d a p a ra c a d a caso. a n a liz a m in u c io s a m e n te y se d e fin e n lo s m o d e lo s de
546
CAP IT U LO 30 REINGENIERÍA
datos n ecesarios (C apítulo 12). Se id entifican los o b je do u n « m o to r de rein g en iería» a u to m a tiz a d o . E n el
tos de datos y atributos y, a continuación, se revisan las m o to r se insertaría el program a v iejo , que lo analizaría,
estructuras de datos a efectos de calidad. reestructuraría y después regeneraría la fo rm a de e x h i
b ir los m ejores aspectosde la calidad del softw are. D es
p u és de un espacio de tiem po c o rto , es p ro b a b le que
llegue a aparecer este «m otor», p ero los fa b ric a n te s de
Referencia C A SE han presentado herram ientas que p ro p o rc io n an
Para poder obtener una gran cantidad de recursos un subconjunto lim itado de estas cap acid ad es y que se
parala comunidad de reingeniería visite esto dirección: enfrentan con dom inios de aplicacio n esesp ecífico s (por
vmw.comp.lancs.ac.uk/projects/RenaissanceWeb/ e je m p lo , ap licacio n es que h an sid o im p le m e n ta d a s
em pleando un sistem a de bases de datos específico). L o
C uando la estructura de datos es débil (por ejem plo, que es m ás im portante, estas h erra m ie n tas d e re in g e
actualm ente se im plem en tan archivos planos, cuando niería cada vez son m ás sofisticadas.
un enfoque relaciona 1 sim plificaría m uchísim o el p ro
L a ingeniería directa, que se denom ina ta m b ién ren o
cesam iento), se aplica u n a reingeniería a los datos. vación o reclamación [CHI90], no solam ente recupera la
D ado q u e la a rq u ite c tu ra de d a to s tie n e u n a gran inform ación de diseño de un so ftw arey a existen te, sino
influencia sobre la arquitectura del p rogram a, y tam bién que, además, utiliza esta inform aciónpara alterar o reco n s
so b re los alg o ritm o s que lo p u e b la n , los ca m b io s en tru ir el sistem a existente en un esfuerzo p o r m e jo ra r su
datos d arán lug ar invariablem ente a cam bios o b ien de calidad global. E n la m ayoría de los casos, el softw are
arquitectura o b ien de código. procedente de una reingeniería vuelve a im p lem e n tar la
I n g e n ie r ía d ir e c ta (fo r w a r d e n g in e e r in g ). E n un funcionalidad del sistema existente,y añade adem ás n u e
m undo ideal, las aplicaciones se reco n struyen u tilizan vas funcionesy/o m ejora el rendim iento global.
30.3 INGENIERÍA INVERSA

L a in g e n ie ría in v e rsa in v o ca u n a im ag en de « ran u ra L a com pletitud de un proceso de ingeniería in v ersa
m ágica». Se in serta un listado de código no estructura alude al nivel de detalle que se proporciona en u n d e te r
do ,y n o docum entado p o r la ranura, y p o r el otro lado m inado nivel de abstracción. En la m ayoría de los casos,
sale la d ocum entación com pleta del pro g ram a de c o m la com pletitud decrece a m edida que aum enta el n iv e l
putadora. L am entablem ente, la ran u ra m ágica no ex is de abstracción. P or ejem plo, dado un listado del c ó d i
te. L a ingeniería inversa puede e x tra e r inform ación de go fuente, es relativam ente sencillo d e sa rro lla una rep re
diseño del código fuente, pero el nivel de abstracción, se n ta c ió n d e d ise ñ o de p ro c ed im ien to s co m p leta.
la co m p letitu d d e la docum entación,el grado con el cual T am bién se pueden derivar representaciones sencillas
trab ajan al m ism o tiem po las herram ientas y el analis del flujo de datos, pero es m ucho m ás difícil desarrollar
ta hum ano, y la direccionalidad del p roceso son sum a un conjunto com pleto de diagram as de flujo de datos o
m ente v ariables [CASSS]. un diagram a de transición de estados.
El n ivel de abstracción de un p roceso de ingeniería
inversa y las herram ientas que se utilizan para realizarlo
aluden a la sofisticación de la inform ación de diseño que
CLAVE
se puede extraer del código fuente. El nivel de abstracción
ideal deberá ser lo m ás alto posible. E sto es, el proceso de Se deben ofrontar tres enfoques de ingeniería inversa:
nivel de abstracción, completitud y direccionolidad.
ingeniería inversa deberá ser capaz de derivar sus repre-
sentacionesde diseño de procedim ientos (con un baj o nivel
de abstracción);y la inform ación de las estructuras de datos La com pletitud m ejora en proporción directa a la can
y de program as (un nivel de abstracción ligeram ente m ás tidad de análisis efectuado p o r la persona que está efec
elevado); m odelos de flujo de datos y de control (un nivel tuando la ingeniería inversa. L a interactividud alude al
de abstracción relativam ente alto); y m odelos de entida grado con el cu al el se r h u m an o se « in teg ra » c o n las
des y de relaciones (un elevado nivel de abstracción). A herram ientas auto m atizad as para crear u n p ro ceso de
m edida que crece el nivel de abstracción se proporciona ingeniería inversa efectivo. E n la m ayoría de los casos,
al ingenierodel software información que le permitirá com a m edida que crece el nivel de abstracción, la interacti-
prender m ás fácilm ente estos program as. vidad deb erá in crem en tarse, o sino la co m p le titu d se
verá reducida.
Si la d ireccionalidad del proceso de ingeniería in v er
C B aB B E B g g a
www.FreeLibros.org
sa es m onodireccional, toda la inform ación extraída del
Lo notación indicadoaquí se explica con detalle
código fu en te se proporcionará a la ingeniería del soft
en el Capítulo 12.
w are que podrá en to n ces utilizarla durante la actividad
547
IN GE NI ER ÍA DEL S O F TW A R E . UN E N F O Q U E P R Á C T I C O
d e m a n te n im ie n to . S i la d ire c c io n a b ilid a d es b id ire c - m ie n to q u e se re a liz a , la in te rfa z d e u s u a rio que se a p li

c io n a l, e n to n c e s la in fo r m a c ió n se s u m in is tra rá a u n a c a, y las e stru ctu ra s d e datos d e p ro g ra m a o de base de
h e rra m ie n ta d e re in g e n ie ría q u e in te n ta rá re e s tru c tu ra r datos q u e se u tiliz a .
o re g e n e ra r e l v ie jo p ro g ra m a .
30.3.1. In g e n ie r ía in v e r sa p a ra com p ren d er
I e l p r o c e sa m ie n to
Código fuente sucio
L a p r im e r a a c tiv id a d r e a l d e l a in g e n ie r ía in v e rs a
c o m ie n z a c o n u n in te n to d e c o m p re n d e r y e x tra e r des
p ués a b strac cio n es d e p ro c e d im ie n to s representadas por
e l c ó d ig o fu e n te . P a ra c o m p re n d e r las a b strac cio n es d e
p ro c e d im ie n to s , se a n a liz a e l c ó d ig o e n d is tin to s n iv e
les d e a b stracció n : s is te m a, p ro g ra m a , c o m p o n e n te , con
fig u r a c ió n y s en ten cia.
L a fu n c io n a lid a d g e n e ra l de to d o el sistem a de a p li
c a c io n e s d e b e rá ser a lg o p e rfe c ta m e n te c o m p re n d id o
antes d e que te n g a lu g a r u n tra b a jo de in g e n ie ría inversa
m á s d e ta lla d o . E s to es lo que e s ta b lec e u n c o n te x to para
u n a n á lis is p o s te rio r, y se p ro p o rc io n a n id ea s generales
a ce rca de lo s p ro b le m a s de in te ro p e ra b ilid a d e n tre a p li
c a c io n e s d e n tro d e l sistem a. C a d a u n o d e lo s p rogram as
de que consta e l sistem a de a p lic a c io n e s re p re s e n ta rá u n a
a b s tra c c ió n fu n c io n a l c o n u n e le v a d o n iv e l d e d e ta lle .
T a m b ié n se c re a rá u n d ia g ra m a d e b lo q u e s c o m o re p re
s e n ta c ió n d e la ite ra c ió n e n tre estas a b strac cio n es fun
c io n a le s . C a d a u n o d e lo s c o m p o n e n te s e fe c tú a una
s u b fu n ció n , y re p re se n ta u n a ab stracció n d e fin id a de p ro
c e d im ie n to s . E n c a d a c o m p o n e n te se c re a u n a n a rra tiv a
\ de p rocesam iento. E n algunas s itu ac io n e sy a existen espe
c ific a c io n e s de s is te m a, p ro g ra m a y c o m p o n e n te . C u a n
F IG U R A 3 0 .3 . El proceso de in g e n ie ría inversa.
d o o c u rre ta l c o sa , se re v is a n las e s p e c ific a c io n e s para
p re c ia r si se a ju s ta n al c ó d ig o e x is te n te 4.
E l p ro c e s o de la in g e n ie n a se re p re s e n ta e n la F ig u
ra 3 0 .3 . A n te s de que p u e d a n c o m e n z a r las a c tiv id a d e s
de in g e n ie ría in v e rs a , e l c ó d ig o fu e n te n o e s tru c tu ra d o
(« s u c io » )s e reestructura (S e c c ió n 3 0 .4 . l) p a r a que so la Existe uno gran pasión por lo comprensión,
m e n te contengassomVssxscsúora?, d e p ro g ia m a c ió n estruc así como la pasión que existe por lo músico
tu ra d a 3. E s to h a ce que e l c ó d ig o fu e n te sea m á s fá c il d e Isa posón es bastante común en los niños,
le e r, y es lo que p ro p o rc io n a la base p a ra to d as las a c ti pao entre la mayoría de las personas más
v id a d e s s u b sig u ie n te s de in g e n ie ría in v e rs a . farde o mós temprano desaparece.
A&erí Baste*!
T o d o se c o m p lic a c u a n d o se c o n s id e ra e l c ó d ig o que
Referencia W e b ^ re s id e e n e l in te rio r d e l c o m p o n e n te . E l in g e n ie ro bus
Lo página de Recuperación de diseños y entendimiento c a las secciones de c ó d ig o q u e re p re s e n ta n las c o n fig u
de programasproporcionalos recursos útiles para untrabajo ra c io n e s g e n é ric a s d e p ro c e d im ie n to s . E n casi to dos los
de reingeniería: www.sel.iit.nrt.ca/projects/dr/dr.html c o m p o n e n te s , e x is te u n a s e c c ió n d e c ó d ig o que p re p a
ra lo s datos p a ra su p ro c e s a m ie n to (d e n tro d e l c o m p o
E l n ú c le o de la in g e n ie ría in v e rs a es u n a a c tiv id a d n e n te ), u n a s e c c ió n d ife re n te d e c ó d ig o q u e e fe c tú a el
d e n o m in a d a extracción de abstracciones. E l in g e n ie ro p ro c e s a m ie n to y o tra s e c c ió n d e c ó d ig o que p re p a ra los
tie n e q u e e v a lu a r e l v ie jo p ro g ra m a y a p a rtir d e l c ó d i re s u lta d o s d e l p ro c e s a m ie n to p a ra e x p o rta rlo s d e ese
g o fu e n te (q u e n o suele e sta r d o c u m e n ta d o ) tie n e que c o m p o n e n te . E n e l in te r io r d e c a d a u n a d e estas sec
e x tr a e r u n a e s p e c ific a c ió n s ig n if ic a tiv a d e l p ro c e s a - c io n e s , se e n c u e n tra n c o n fig u r a c io n e s m á s p eq u eñ as.
3 El código se puede reestructurar autom áticam ente em pleando un 4 Con frecuencia, las especificaciones escritas en fases centradas de
www.FreeLibros.org
((m otorde reestructuración), —una herram ienta CASE que reestruc la historia del program a no llegan a actualizarse nunca. A medida
tura el código fuente— . que se hacen cam bios, el código deja de satisfacer esas especifica
ciones.
548
CAPÍTULO 30 REINGENIERIA
P or ejem p lo , suele producirse u n a v erificación de los 3. Para toda variable (dentro de un program a) que rep re
datos y u n a co m probación de los lím ites den tro de la sente una m atriz o archivo, la construcción d e u n lis
sección de código que p rep ara los datos para su p ro c e tado de todas las variables que tengan u n a re la ció n
sam iento. lógica con ella.
P ara los sistem as grandes, la ingeniería inversa sue
le efectuarse m ediante el uso de un enfoque sem iauto-
m atizad o . L a s h e rra m ie n ta s C A S E se u tiliz a n p a ra
«analizar» la sem ántica del código existente. L a salida B i ksptóxim oscñxlos comptomlsosrelofivamente
de este p ro ceso se p asa en to n ces a unas herram ientas significativos en/'asestruáiras efedatos pueden conducii
o tener pioblem s pdenciámentecotostróficos. Fíjese
de reestru ctu ració n y de ingeniería directa que com ple
por ejemplo en el electo del año 2000.
tarán el p roceso de reingeniería.
E stos pasos hacen posible que el in g en iero d el so ft
30.3.2. I n g e n ie r ía in v e r sa p a ra co m p ren d er w are identifique las clases del program a que in te ra ctú -
lo s d a to s an con las estructuras de datos globales.
L a ingeniería in v ersa de datos suele producirse a dife Estructuras de bases de datos. In d e p e n d ie n te m en

rentes niveles de abstracción. E n el nivel de program a, te de su organización lógica y de su estru c tu ra física ,
es frecuente que sea preciso realizar una ingeniería inver las bases de datos perm iten definir objetos d e d ato s, y
sa de las e stru ctu ras de d a to s in tern as del p ro g ram a, apoyan los m étodos de establecer relaciones entre o b je
com o parte del esfu erzo general de la reingeniería. E n tos. P or tanto, la reingeniería de un esquem a d e b ases
el nivel del sistem a, es frecuente que se efectúe una rein de datos para form ar otro exige com prender los o b je to s
g en iería de las estructuras globales de d atos (por ejem y a existentes y sus relaciones.
p lo : arch iv o s, b a se s de d a to s ) p a ra a ju sta rla s a los
p aradigm as nuev o s de gestión de b ases de datos (por | B ¿Cuáles son los pasos que
ejem plo, la tran sferen cia de archivos planos a unos sis w se pueden aplicar para aplicar
tem as de bases de datos relacionales u orientados a obje la ingeniería inversa en una estructura
tos). L a ingeniería in v ersa de las e stru ctu ras de datos de bases de datos existente?
globales actuales establecen el escenario para la in tro
ducció n de u n a n u ev a base de datos que abarque todo P ara definir el m odelo de datos existente co m o p re
el sistem a. cu rso r p a ra u n a re in g e n ie ría que p ro ducirá u n n u e v o
Estructuras de datos internas. L as técnicas de in g e m odelo de base de datos se pueden em plear los pasos
n iería in v ersa para datos de p ro g ram a internos se cen siguientes [PRE94] :
tran en la definición de clases de o b jeto s5. E sto se logra 1. Construcción de un modelo de objetos inicial. L as
exam inando el có d ig o del p ro g ra m a e n un in ten to de claves d efin id as co m o p arte del m odelo se p o d rá n
agrupar v ariables de p ro g ram a que estén relacionadas. co n seg u ir m ediante la revisión de registros de u n a
E n m uchos casos, la o rganización de datos en el seno base de datos de archivos planos o de tablas de un
del código identifica los tipos abstractos de datos. Por esquem a relacional. L o s elem entos de esos registros
ejem plo, las estructuras de registros, los archivos, las o tablas p asarán a ser atributos de u n a clase.
listas y o tras estru c tu ra s de d ato s que su elen p ro p o r 2. Determinaciónde loscandidatosaclaves. Los atribu
cio n ar una indicación inicial de las clases. tos se exam inan para determ inar si se van a utilizar o
P ara la ingeniería inversa de clases, B reuer y L año no para señalar a otro registro o tabla. A quellos que sir
[BRE91] sugieren el enfoque siguiente: van com o punteros pasarán a ser candidatos a claves.
1 Id e n tific a ció n d e los in d icad o res y e stru ctu ras de 3. Refinamiento de las clasesprovisionales. Se d e te r
datos locales dentro del program a que registran infor m in a si ciertas clases sim ilares pueden o n o c o m b i
m ación im portante acerca de las estructuras de datos narse dentro de u n a Única clase.
globales (por ejem plo, archivos o bases de datos). 4. Definición de lasgeneralizaciones. P ara determ inar
2 D efinición de la relació n entre indicadores y estru c si se debe o no construir u n a je ra rq u ía de clases con
turas de datos locales y las estructuras de datos g lo u n a clase de generalización com o precursor de todos
b ales. P o r ejem p lo , se p o d rá activ ar u n in d ica d o r sus descendentes se exam inan las clases que pueden
c u a n d o u n a rc h iv o e s té v a c ío ; u n a e s tru c tu ra de ten er m uchos atributos sim ilares.
d ato s lo cal p o d rá serv ir co m o m e m o ria in term ed ia 5. Descubrimientode lasasociaciones. M ediante el uso
d e lo s cieú ú ltim o s re g is tro s re c o g id o s p a ra u n a de té c n ic a s a n á lo g a s al e n fo q u e de C R C (C a p í
base de d ato s central. tulo 21) se establecen las asociaciones entre clases.
www.FreeLibros.org
5 Para una descripción com pleta de e sto s concep tos o rien tad o s a
objetos, véase la Parte Cuarta de este libro.
549
IN GENIERÍA DEL S OFT W ARE . UN E N F O Q U E P R Á C T I C O
Una vez que se conoce la inform ación definida en los . ¿Cuáles son las acciones básicas que deberá proce
pasos anteriores, se pueden aplicar una serie de trans sar la interfaz, por ejem plo, acciones de teclado y
formaciones [PRE94] para hacer correspondería estruc clics de ratón?
tura de la vieja base de datos con una nueva estructura . ¿Cuál es la descripción com pacta de la respuesta de
de base de datos. comportamiento del sistema a estas acciones?
■ ¿Qué queremos decir con «sustitución», o más exac
30.3.3. I n g e n ie r ía in v e r s a d e in te r f a c e s tamente, qué concepto de equivalencia de interfaces
d e u s u a r io es relevante en este caso?
Las IGUs sofisticadas se van volviendo de rigor para La notación de m odelado de comportamiento (Capí
los productos basados en com putadoras y para los sis tulo 12)puede proporcionar una form a de desarrollar las
tem as de todo tipo. Por tanto el nuevo desarrollo de respuestas de las dos prim eras preguntas indicadas ante
interfaces de usuario ha pasado a ser uno de los tipos riormente. Gran parte de la inform ación necesaria para
m ás com unes de las actividades de reingeniería. A ho crear un modelo de comportamiento se puede obtener
ra bien, antes de que se pueda reconstruir una interfaz mediante la observación de la m anifestación extema de
de usuario, deberá tener lugar una actividad de inge la interfaz existente. Ahora bien, es preciso extraer del
niería inuersa. código la inform ación adicional necesaria para crear el
m odelo de comportamiento.
A ¿Cómo puedo entender Es im portante indicar que una IGU de sustitución
W el funcionamiento de la puede que no refleje la interfaz antigua de form a exac
interfaz de usuario existente? ta (de hecho, puede ser totalm ente diferente). Con fre
cuencia, m erece la pena d esa rro llar m etáforas de
Para com prender totalmente una interfaz de usuario interacción nuevas. Por ejem plo, una solicitud de IU
ya existente (IU), es preciso especificar la estructura y antigua en la que un usuario proporcione un
comportamiento de la interfaz. M erlo y sus colabora superior (del 1 a 10)para encoger o agrandar una ima
dores [M ER93] sugieren tres preguntas básicas a las gen gráfica. Es posible que una IGU diseñada utilice
cuales hay que responder cuando com ienza la ingenie una barra de im ágenes y un ratón para realizar la mis
ría inversa de la IU : m a función.
L a reestructuración del softw are m odifica el código « Reduce la frustración entre ingenieros del software
fuente y/o los datos en un intento de adecuarlo a futu que deban trabajar con el program a, mejorando por
ros cambios. En general, la reestructuración no m odifi tanto la productividad y haciendo m ás sencillo el
ca la arquitectura global del programa. Tiende a centrarse aprendizaje.
en los detalles de diseño de m ódulos individuales y en • Reduce el esfuerzo requerido para llevar a cabo las
estructuras de datos locales definidas dentro de los actividades de mantenimiento.
módulos. Si el esfuerzo de la reestructuración se extien • Hace que el software sea m ás sencillo de comprobar
de m ás allá de los límites de lo s m ódulos y abarca la y de depurar.
arquitectura del software, la reestructuración pasa a ser
La reestructuración se produce cuando la arquitectura
ingeniería directa (Sección 30.5).
básica de la aplicación es sólida, aun cuando sus interio
ridades técnicas necesiten un retoque. Com ienza cuando
H I ¿Qué beneficios se derivan existen partes considerables del software que son Útiles
W de la reestructuración? todavía, y solamente existe un subconjuntode todos los
módulos y datos que requieren una extensa modificación6.
A m old [ARN89] define un cierto número de bene
ficios que se pueden lograr cuando se reestructura el 30.4.1. R e estru ctu r a ció n d e l c ó d ig o
software: La reestructuración del código se lleva a cabo para con
. Program as de m ayor calidad — con m ejor docu seguir un diseño que produzca la m isma función pero con
m entación y m enos com plejidad, y ajustados a las m ayor calidad que el program a original. En general, las
prácticas y estándares de la ingeniería del software técnicas de reestructuracióndel código (por ejemplo, las
moderna— . técnicas de sim plificaciónlógica de Wamier [WAR74])
www.FreeLibros.org
6 En algunas ocasiones,resulta difícil distinguir entre una reestructura
ción extensa y un nuevo desarrollo. Ambos son casos de reingeniería.
550
CAPÍTULO SO REINGENIERÍA
m odelan la lógica del program a em pleando álgebra Boo- sa , lla m a d a a n á l i s i s d e l c ó d i g o f u e n t e . E n p r im e r

lean a, y a co ntinuación aplican u n a serie de reg las de lu g a r se e v a lu a rá n to d a s las se n te n c ia s d e l le n g u a je
tran sfo rm ació n que dan lug ar a u n a ló g ica reestru ctu ra d e p ro g ra m a c ió n c o n d e fin ic io n e s d e d a to s , d e s
da. El o bjetivo es to m ar el código de form a de «plato de c rip c io n e s d e a rc h iv o s, de E /S , y d e s c rip c io n e s d e
espaguetis» y deriv ar un diseño de p rocedim ientos que in te rfa z. E l o b je tiv o e s e x tra e r e le m e n to s y o b je to s
se ajuste a la filosofía de la prog ram ación estructurada d e d a to s, p a ra o b te n e r in fo rm a c ió n a c e rc a d e l flu jo
(C apítulo 16). d e d a to s , a sí c o m o c o m p re n d e r la s e s tr u c tu r a s d e
d ato s y a ex isten tes que se h a y a n im p lem en tad o . E sta
a c tiv id a d a v e c e s se d e n o m in a a n á l i s i s d e d a t o s
^ M U S E IO ^ , [R IC 89].
Aun cuandolareestructurociónpuede aliviar U n a v e z fin a liz a d o el a n á lis is de d a to s , c o m ie n
losproblemas Inmediatas asociadas a la depuración za el r e d i s e ñ o d e d a to s . E n su fo rm a m á s s e n c illa se
y lospequeños cambios, eso no es reingenierío. e m p le a u n p a s o d e e s t a n d a r i z a c i ó n d e r e d i s e ñ o d e
El beneficiarealse logra salocuandose d a t o s q u e c la r if ic a la s d e f in ic io n e s d e d a to s p a r a
reestructuran los datas y laarquitectura. lo g ra r u n a c o n siste n c ia e n tre n o m b re s d e o b je to s de
Se han propuesto tam bién otras técnicas de reestructu d ato s, o en tre fo rm ato s de re g istro s físic o s en el sen o
ración que puedan utilizarse con herram ientas de reinge de la e stru c tu ra de d ato s o fo rm a to d e a rc h iv o s e x is
niería. P or ejem plo, C hoty A cacchi [CHO90] sugieren la ten tes. O tra fo rm a de re d is e ñ o , d e n o m in a d a r a c i o
n a li z a c i ó n d e n o m b r e s d e d a t o s , g a ra n tiz a que to d as
creación de un diagram a de intercam bio de recursos que
diseña cada uno de los m ódulos de program a y los recur la s c o n v e n c io n e s d e d e n o m in a c ió n de d a to s se a ju s
so s (tipos de datos, p rocedim ientos y v ariables) que se te n a lo s e s tá n d a re s lo c a le s , y q u e se e lim in e n la s
intercam bian en este y otros m ódulos. M ediante la c rea irre g u la rid a d e s a m e d id a q u e lo s d a to s flu y e n p o r el
ción de rep resentaciones del flujo de recursos, la arqui sistem a.
tectu ra del p ro g ram a se puede reestru cturar para lograr C uando la reestructuración sobrepasa la estan d ari
el acoplam iento m ínim o entre los m ódulos. zación y la racionalización, se efectúan m odificaciones
físicas en las estructuras de datos y a existentes con o b je
to de h acer que el diseño de datos sea m ás efectivo. Esto
30.4.2. R eestructuración d e los d a to s puede significar una conversión de un form ato de archi
A n tes de q u e p u e d a c o m e n z a r la re e s tru c tu ra c ió n de vo a otro, o, en algunos casos, una conversión de un tipo
dato s, es p re c iso lle v a r a c a b o u n a in g e n ie ría in v e r- de base de datos a otra.
U n program a que posea flujo de control es el equivalente caciones, aplicando un enfoque de ingeniería del soft
gráfico de un plato de espaguetis con « m ódulos»,es decir w are a todos los segm entos revisados.
con 2.000 sentencias de longitud; con p ocas líneas de 4 . L a posibilidad de rediseñar, recodificar y com probar
com entarioútiles en 290.000 sentenciasde código fuente, el program a en su totalidad, utilizando herram ientas
y sin ninguna otra docum entación que se deba modificar CASE (h erram ien tas de re in g e n ie ría ) que servirán
para ajustarle a los requisitos de cam bios del usuario. Se para com prender el d iseño actual.
puede decir que disponem os de las opciones siguientes:
1. L a po sib ilid ad de esforzarse p o r efectuar una m odi N o existe u n a Única opción « c o rre c ta» .L a s circuns
ficación tras otra, luchando co n el d iseño im plícito tancias pueden im poner la prim era opción, aun cuando
y con el código fuente p ara im p lem en tar los cam bios las otras sean las preferidas.
necesarios. E n lu g a r d e e s p e ra r a que se re c ib a u n a so lic itu d
2. L a p o sib ilid ad de inten tar com prender el fu n ciona d e m a n te n im ie n to , la o rg a n iz a c ió n d e d e s a rro llo o
miento interno m ás amplio del programa, en un esfuerzo d e s o p o rte u tiliz a r á lo s r e s u lta d o s d e l a n á lis is de
por hacer que las m odificaciones sean m ás efectivas. in v e n ta rio p a ra se le c c io n a r el p ro g ra m a (1) q u e c o n
tin ú e u tiliz á n d o se d u ra n te u n n ú m e ro d e te rm in a d o
d e a ñ o s, ( 2 ) q u e se e s té u tiliz a n d o c o n é x ito e n la
¿Qué opciones existen
• a c tu a lid a d , y ( 3 ) q u e te n g a p ro b a b ilid a d e s d e su frir

cuando nos enfrentamos
g ra n d e s m o d ific a c io n e s o m e jo ra s en u n fu tu ro p ró
con un programa de diseño
x im o. E n to n c e s , se a p lic a rá n la s o p c io n e s 2 , 3 ó 4
e implementeciónpobres?
an terio re s.
Este enfoque de m antenim iento preventivo fue intro
www.FreeLibros.org
3. L a p o sib ilid ad de rediseñar, reco d ificar y com probar d u cido po r M iller [M IL 8 1] con el nom bre de «reajuste
aquellas partes del softw are que req uieran m odifi- estructurado». D efinía este concepto com o «la aplica
551
ción de las m etodologías de hoy a los sistem as de ayer 30.5.1. In g e n ie r ía d ir ec ta p a ra arquitecturas

para p restar apoyo a los requisitos del m añana». cliente/servidor
A p rim era vista, la sugerencia de v o lv er a d esarro
A lo largo de la últim a década, m uchas aplicaciones de
llar un gran pro g ram a cuando y a existe u n a versió n ope
grandes com putadoras han sufrido un proceso de rein
rativ a p u ed e p a re c e r m á s b ie n ex trav ag an te. Sin
geniería para adaptarlas a arquitecturas cliente/servidor
em bargo, antes de p asar a em itir un ju ic io , co n sid éren
(C/S). E n esencia, los recursos de com putación centra
se los p untos siguientes:
lizad o s (in clu y en d o el softw are) se d istrib u y e n entre
1. El co ste de m a n te n e r u n a lín e a d e c ó d ig o fu e n te m uchas plataform as cliente. A unque se puede diseñar
puede estar entre v einte y cuarenta veces p o r encim a toda una gam a de entornos distribuidos distintos, la apli
del coste del desarrollo inicial de esa línea. cación típica de com putadora central que sufre un pro
2. El rediseño de la arquitectura del softw are (del p ro ceso de rein g e n ie ría p a ra a d o p ta r una arqu itectu ra
g ram a y/o de las e stru ctu ras de d ato s) em p leando cliente/servidor posee las características siguientes:
conceptos de diseño m odernos puede facilitar m ucho • la funcionalidad de la aplicación m igra hacia todas
el m antenim iento futuro. las com putadoras cliente;
3. D ado que y a existe u n prototipo del softw are, la p ro • se im plem entan nuevas interfaces IG U en los cen
du ctividad de desarrollo deberá ser m ucho m ás ele tros clientes;
vad a que la m edia. • las funciones de bases de datos se le asignan al ser
4. E n la actualidad, el usuario ya tiene ex periencia con vidor;
el software. Por tanto, los nuevos requisitos y la direc • la funcionalidad especializada (por ejem plo, los aná
ción del cam bio se po d rán estim arse con m u ch a m ás lisis de com putación intensiva) pueden perm anecer
facilidad. en el centro del servidor; y
5. L as h e rra m ie n tas C A SE p ara la re in g e n ie ría au to • los nuevos requisitos de com unicaciones, seguridad,
m atizarán algunas partes del trabajo. archivado y control deberán establecerse tanto en el
6. C uando finalice el m an ten im ien to p rev en tiv o , se d is centro cliente, com o en el centro servidor.
pondrá de una co nfiguración com pleta del softw are
(docum entos, p rogram as y datos). g g g S H E E H g a
La ingeniería del software diente/servidor
se estudio en el Capítulo 2 8 .
la relngenieríaes muy similaral hecho de lavarse Es im portante ten er en cuenta que la m igración d es
los dientes. Sepuedepensar en mil razanes de co m p u tad o ras cen trales a un p ro ceso C/S requiere
y tardaren lavárselas, dejándoloparomás tarde. tan to una rein g e n ie ría del n e g o cio c o m o u n a rein g e
Pera, al final, estas tácticas deretrasarlos cosos niería del softw are. A dem ás, es preciso establecer una
siempre volverána rondemos. «infraestructura de red de em presa». [JAY94]
C uando una o rganización de desarrollo de softw are

vende el softw are co m o un producto, el m an ten im ien
to preventivo se ve co m o «nuevas versiones» del p ro Si algunos casas, los sistemas C/S o los sistemas 00
gram a. U n g ran d esa rro lla d o r de so ftw are lo cal (por diseñadospora reemplazar unaaplicadón antigua deberán
ejem p lo , u n g ru p o de desarrollo de so ftw are de siste enfocarsecomo unproyectonuevo de desarrollo.
Larelngenleríaentra enjuega solo cuandolos elementos
m as para una com pañía de p roductos de un consum idor
de un sistemaantiguo se von a Integrarcon la nueva
de gran v olum en) puede ten er en tre 500 y 2 .0 0 0 p ro
arquitectura. En algunos casos, quizás es mejor noaceptar
gram as de pro d u cció n dentro de su dom inio de resp o n
la viejay crear unafuncionalidadnueva e idéntico.
sabilidad. Se p o d rá n a sig n a r p rio rid a d e s a esto s
program as según su im portancia, y a co ntinuación se La rein g en iería de a p licacio n es C/S co m ien za con
revisarán esos p rogram as com o los candidatos p ara el un análisis exhaustivo del entorno de negocios que abar
m antenim iento preventivo. ca la com putadora central existente. Se pueden id en ti
E l p ro ceso de in g e n ie ría del so ftw are ap lica p rin ficar tres capas de abstracción- (Fig. 3 0 .4 ).L a base de
cipio s, co n cep to s y m éto d o s de in g e n ie ría del so ftw a datos se encuentra en los cim ientos de la arquitectura
re para v o lv er a c re a r las a p licacio n es ex isten tes. E n cliente/servidor, y gestiona las transacciones y co n su l
la m ay o ría de los casos, la ingeniería directa no se lim i tas que p ro ce d en de las ap licacio n es de servidor. Sin
ta a crear un equivalente m oderno de un pro g ram a ante em bargo, estas transacciones y consultas tienen que ser
rior, sino que m ás bien se integran los nuevos requisitos controladas en el c o n tex to de un conjunto de reglas de
y las n u e v a s te c n o lo g ía s 'en ese esfu erzo de v o lv er a negocio (definidas p o r un proceso de negocio ya ex is
ten te o que ha e x p e rim e n ta d o una rein g en iería). Las
www.FreeLibros.org
ap licar rein g en iería. E l p ro g ram a que se ha v u elto a
d e sa rro lla r a m p lía las c a p a c id a d e s d e la a p lic a c ió n aplicaciones de cliente proporcionan la funcionalidad
anterior. deseada para la com unidad de usuarios.
552
CAPÍTULO 30 REINGENIERÍA
L a s fu n c io n e s d e l s is te m a d e g e s tió n d e bases d e U n e s tu d io c o m p le to so b re e l d is e ñ o y r e in g e n ie r ía
datos y a e x is te n te y la a rq u ite c tu ra d e datos d e la base d e s o ftw a re c lie n te /s e rv id o r es m ás a d e c u a d o p a ra o tro s
d e d a to s e x is te n te d e b e rá n s u fr ir u n p ro c e s o d e in g e lib ro s e s p e c ia liz a d o s e n este m a te ria . E l le c to r in te r e
n ie r ía in v e rs a c o m o p re c e d e n te p a ra e l re d is e ñ o d e la sado d e b e rá c o n s u lta r [ V A S 9 3 ] , [ I N M 9 3 [ y [ B E R 9 2 ] ,
c a p a d e fu n d a m e n to d e la b ase d e d a to s . E n a lg u n o s
casos, se c re a u n n u e v o m o d e lo de datos (C a p ítu lo 1 2).
30.5.2. I n g e n i e r í a d i r e c t a p a r a a r q u i t e c t u r a s
E n to d o s lo s casos, la base d e datos C /S s u fre u n p r o
o r i e n t a d a s a o b je to s
ceso d e re in g e n ie ría p a ra a s e g u ra r q u e la s tra n s a c c io
nes se e je c u ta n c o n s is te n te m e n te ; p a ra a s e g u ra r q u e L a in g e n ie ría d e l s o ftw a re o rie n ta d a a o b je to s se h a tran s
to d as la s a c tu a liz a c io n e s se e fe c tú e n ú n ic a m e n te p o r fo r m a d o e n e l p a ra d ig m a o p c io n a l d e d e s a r r o llo p a ra
u s u a rio s a u to riz a d o s ; p a ra a s e g u ra r q u e se im p o n g a n m u c h a s o rg a n iz a c io n e s d e s o ftw a re . S in e m b a rg o , ¿qué
las re g las d e n e g o c io s fu n d a m e n ta le s (p o r e je m p lo , antes sucede c o n la s a p lic a c io n e s e x is te n te s q u e se d e s a rro
d e b o rra r e l re g is tro de u n p ro v e e d o r, e l s e rv id o r se ase . lla ro n e m p le a n d o m é to d o s c o n v e n c io n a le s ? E n a lg u n o s
g u ra d e q u e n o e x is ta n in g ú n re g is tro p e n d ie n te , c o n casos, la re sp u es ta c o n sis te e n d e ja r estas a p lic a c io n e s
tra to o c o m u n ic a c ió n p a ra ese p ro v e e d o r ); p a ra a se g u ra r ta l y c o m o e ran . P e ro e n o tro s casos, es p re c is o a p lic a r
q ue se p u e d a n a d m itir las c o n su ltas d e fo r m a e fic a z ; y u n a r e in g e n ie r ía a las v ie ja s a p lic a c io n e s p a ra q u e se
p a ra a s e g u ra r que se h a e s ta b le c id o u n a c a p a c id a d c o m p u e d a n in te g ra r fá c ilm e n te e n g ra n d e s sistem as o rie n ta
p le ta d e a rc h iv a d o . dos a o b je to s .
L a re in g e n ie ría d e l s o ftw a re c o n v e n c io n a l p a ra pro
d u c ir u n a im p le m e n ta c ió n o rie n ta d a a o b je to s h a ce uso
Interfaz: IGU de m u c h a s de las m is m a s té c n ic a s d e sc rita s e n la C u a r
ta P a rte d e este lib ro . E n p r im e r lu g a r, se h a ce u n a in g e
n ie r ía in v e rs a d e l s o ftw a re e x is te n te p a ra que sea p o s ib le
Aplicaciones cliente
c re a r lo s m o d e lo s a d ecu ad o s d e d a to s , fu n c io n a l y de
c o m p o rta m ie n to . S i e l s is te m a que se a p lic a a la re in g e
n ie r ía e x tie n d e la fu n c io n a lid a d o c o m p o rta m ie n to d e la
a p lic a c ió n o rig in a l, se c re a n casos p rá c tic o s (C a p ítu lo s
Interfaz: solicitudes de proceso 11 y 2 1 ). L o s m o d e lo s d e datos c rea d o s d u ra n te la in g e
n ie r ía in v e rs a se u tiliz a n en to n c es ju n t o c o n u n m o d e la
d o C R C (C a p ít u lo 2 1 ) p a ra e s ta b le c e r la base p a ra la
d e fin ic ió n d e clases. L a s je ra rq u ía s d e clases, lo s m o d e
lo s d e re la c io n e s e n tre o b je to s , lo s m o d e lo s d e c o m p o r
ta m ie n to d e o b je to s , y lo s s u b s is te m a s se d e fin e n a
c o n tin u a c ió n , y c o m ie n z a e l d is e ñ o o rie n ta d o a o b je to s .
Interfaz: transacciones y consultas A m e d id a que la in g e n ie ría d ire c ta o rie n ta d a a objetos
pasa d e l análisis hasta e l d iseñ o , se p o d rá in v o c a r e l m o d e
Base de datos
lo d e pro ceso d e IS B C (C a p ítu lo 2 7 ). S i la a p lic ac ió n e xis
ten te se e n c u e n tra c o n un d o m in io y a h a sido p o p u la riza d a
p o r m u c h as a p lic a c io n e s o rie n ta d a s a o b je to s , es p ro b a
b le que e x is ta u n a b ib lio te c a ro b u s ta d e c o m p o n e n te s y
F IG U R A 30.4. Proceso de reingeniería de aplicaciones que se p u e d a u tiliz a r d u ran te la in g e n ie ría directa.
de computadores centrales a cliente/servidor.
P ara a q u ellas clases que sea p re cis o c o n s tru irp a rtie n d o
d e c e ro , q u iz á sea p o s ib le r e u tiliz a r a lg o ritm o s y e s tru c
L a c a p a d e re g la s d e n e g o c io s re p re s e n ta e l s o ftw a re tu ras d e datos p ro c e d e n te s d e la a p lic a c ió n c o n v e n c io n a l
re s id e n te ta n to e n e l c lie n te c o m o e n e l s e rv id o r. E s te y a e x is te n te . S i e m b a rg o , es p re c is o v o lv e r a d is e ñ a rlo s
s o ftw a re lle v a a c a b o las ta re as d e c o n tro l y c o o rd in a p a ra a justarse a la a rq u ite c tu ra o rie n ta d a a o b je to s .
c ió n p a ra a s e g u ra r q u e las tra n s a c c io n e s y c o n s u lta s
e n tre la a p lic a c ió n c lie n te y la base d e datos se a ju s te n
30.5.3. I n g e n i e r í a d i r e c t a p a r a in t e r f a c e s
a los p ro ceso s d e n e g o c io s e sta b lec id o s .
L a c ap a d e a p lic a c ió n d e l c lie n te im p le m e n ta las fu n d e u s u a r io
cio n es d e n e g o c io s re q u e rid a s p o r g ru p o s e s p e c ífic o s de C u an d o las a p lic ac io n es m ig ra n desde la co m p u ta d o ra c e n
usuarios fin a les . E n m u c h o s casos, se s eg m e n ta u n a a p li tr a l a la c o m p u ta d o ra d e so b re m es a, lo s u s u a rio s y a n o
c a c ió n d e c o m p u ta d o ra c e n tra l e n u n c ie rto n ú m e ro de están dispuestos a a d m itir unas interfaces d e usuarios a rca
a p lic a c io n e s m ás p e q u e ñ a s , s o m e tid a s a re in g e n ie ría , y nas basadas e n caracteres. D e h e ch o , u n a p a rte s ig n ific a
a d ec u ad as p a ra su fu n c io n a m ie n to d e s o b re m e s a . L a tiv a de todos los esfuerzos in vertid o s en la tran sició n desde
la c o m p u ta c ió n d e c o m p u ta d o ra ce n tra l hasta la a rq u ite c
www.FreeLibros.org
c o m u n ic a c ió n e n tre a p lic a c io n e s de s o b re m es a (c u a n d o
es n e c e s a ria ) s erá c o n tro la d a p o r la c a p a d e re g la s d e tu ra c lie n te /s e rv id o r se p u e d e n re in v e rtir en la re in g e n ie
n egocios. ría d e las in te rfa c es d e u s u ario d e la a p lic a c ió n clie n te .
553
siendo los mismos. L a interfaz rediseñada deberá seguir

§ m ¿Cuáles son los pasos a seguir
perm itiendo que el usuario m uestre el comportamiento
W para una ingeniería de interfaz
de negocios adecuado. P o r ejem plo, cuando se efec
de usuario?
túa una consulta en una base de datos, es posible que,
M erlo y co laboradores [M ER95] sugieren el m odelo para especificar la consulta, la interfaz v ieja necesite
siguiente para la reing en iería de interfaces de usuario: una serie larga de órdenes basadas en textos. L a IGU
1. C om prender la interfaz original y los dato s que se som etida a reingeniería puede h acer que la consulta
trasladan entre ella y el resto de la aplicación. El sea m ás eficiente, reduciéndola a una pequeña secuen
objetivo es com prender la fo rm a en que los dem ás cia de selecciones con el ratón, pero la intención y el
elem entos del p ro g ram a in te ra c tú a n con el código co n ten id o d e la consulta deberán perm anecer intactas.
existente que im plem enta la interfaz. Si se h a de desa 3. Introducir m ejoras que hagan que el m odo de inter
rro lla r u n a n u e v a IG U , en to n ces el flu jo de d ato s acción sea m ás eficiente. L o s fallos ergonóm icos de
en tre la IG U y el resto del p ro g ram a d eberá ser c o n la interfaz existente se estudian y se corrigen en el
secuente con los d ato s que en la actualidad flu y en diseño de la IG U nueva.
entre la interfaz b asad a en caracteres y el program a. 4. C onstruir e integrar la IG U nueva. La existencia de
2. R em o d ela r el com portam iento im plícito en interfaz b ib lio te c a s d e c la se s y d e h e rra m ie n ta s de cuarta
existente p a ra fo r m a r una serie de abstracciones que generación puede reducir el esfuerzo requerido para
tengan sentido en el contexto de una IG U . A unque el construir la IG U de form a significativa. Sin em bargo,
m odelo de interacciónpueda ser radicalm ente distinto, la integración con el softw are de aplicación y a exis
el com portam ientode negocios m o stradopor los usua ten te puede lle v a r m ás tiem po. P a ra aseg u rarse de
rios de la interfaz nueva y vieja (cuando se consideran que la IG U no pro p ag u e u n o s e fe c to s ad v ersos al
en función del escenario de utilización) deberán seguir resto de la aplicación es preciso ten er cuidado.
En un m undo perfecto, todo pro g ram a que no se p u d ie

ra m an ten er se retiraría inm ediatam ente, p ara ser susti
tuido p o r unas aplicaciones de alta calidad, fabricadas ‘ ■ lepogm un poco ahora,
m ediante re in g e n ie ría y d esarro llad as em p lean d o las f mucho más.
prácticas de la ingeniería del so ftw are m odernas. Sin T m S íK itm CMcesioaario de coches
em bargo, vivim os en u n m undo de recursos lim itados. i mus puesta a punto
La rein g en iería consum e recursos que se p u ed en u tili
zar p a ra o tro s p ro p ó sito s de nego cio . C o n s ig u ie n te
m ente, antes de que u n a organización intente efectuar E l co ste aso ciado al m an ten im ien to continuado de
una rein g en iería de la aplicación existente, d eberá lle
una ap licacióncandidata (esto es, si no se realiza la rein
var a cabo un análisis de costes y beneficios. geniería) se puede definir com o:
S need [SN E95] ha p ropuesto u n m odelo de análisis
de costes y b eneficios p ara la reingeniería. Se definen Cnnt 1 + W x L (30.D
nueve parám etros: Los costes asociados con la reingeniería se definen
P j = coste de m antenim iento anual actual p ara una em pleando la relación siguiente:
aplicación; C re¡ng = P 6 ' ^ + P 5 ^ X d - P %) _ ( P ? X P f ] (30.2)
P 2 = coste de o peración anual de u n a aplicación;
E m pleando los costes presentados en la ecuaciones
P, = valor de negocios anual actual de una aplicación; (30.1) y (30.2), los beneficios globales de la reingenie
P, = coste de m antenim iento anual p redicho después ría se pueden calcular en la form a siguiente:
de la reingeniería;
B eneficio y coste = C re¡ng - C mant (30.3)
E 5 = coste de o peraciones anual p redicho después de
la reingeniería; E l a n á lisis de co ste s y b en efic io s p rese n tad o s en
las ecu acio n es anterio res se p u ede llev ar a cabo para
= valo r de negocio actual p redicho después de la
reingeniería; to d a s a q u e lla s a p lic a c io n es de a lta p rio rid a d que se
h a y an id e n tific a d o d u ra n te un a n á lisis de inventario
P, = costes de rein g en iería estim ados;
(S ecció n 3 0.2.2). A q u ellas a p licacio n es que m uestren
P 8 = fecha estim ada de reingeniería; el m ay o r b en eficio en relac ió n co n los co ste s podrán
P, = facto r de riesgo de la reingeniería (P9 = 1,0 es
www.FreeLibros.org
d e stin a rse a la re in g e n ie ría , m ie n tra s que las dem ás
el v alo r nom inal); po d rán ser p ro p u estas h a sta que se d isp o n g a de más
L = v id a esperada d el sistema. recursos.
554
CAP ITU LO 30 R E I N G E N IE R lA
L a in g e n ie r ía se p ro d u c e e n d o s n iv e le s d is tin to s d e d a d — se tra ta d e pro gram as que sean v ia b le s h a sta b ie n

a b s tra c c ió n . E n e l n iv e l d e n e g o c io s , la r e in g e n ie r ía e n tra d o e l s ig lo v e in tiu n o — .
se c o n c e n tra e n e l p ro c e s o d e n e g o c io s c o n la in te n E l a n á lis is d e in ve n tario s p e rm ite q u e u n a o r g a n iz a
c ió n d e e fe c tu a r c a m b io s q u e m e jo r e n la c o m p e t it iv i- c ió n e s tim e todas y cad a u n a d e la s a p lic a c io n e s s is te
d a d e n a lg ú n a sp e c to d e lo s n e g o c io s . E n e l n iv e l d e l m á tic a m e n te , c o n e l f in d e d e te r m in a r c u á le s so n las
s o ftw a re , la r e in g e n ie r ía e x a m in a lo s s is te m a s y a p li c a n d id a ta s p a ra u n a re in g e n ie ría . L a r e e s tr u c tu r a c ió n
c a c io n e s d e in f o r m a c ió n c o n la in t e n c ió n d e r e e s d e d o c u m e n to s c rea un m a rc o d e tr a b a jo d e d o c u m e n
tru c tu ra rlo s o re c o n s tru irlo s d e ta l m o d o q u e m u e s tre n tos n e c e s a rio p a ra e l a p o y o d e u n a c ie r ta a p lic a c ió n a
u n a m a y o r c a lid a d . la rg o p la z o . L a in g e n ie ría in v e rs a es e l p ro c e s o d e a n a
L a re in g e n ie ría de pro ceso s d e n e g o c io ( R P N ) d e fi liz a r u n p ro g ra m a e n un e s fu e rz o p o r e x tr a e r in fo r m a
n e lo s o b je tiv o s d e n e g o c io s , id e n tific a y e v a lú a lo s c ió n a c e rc a d e los datos, d e su a rq u ite c tu ra y d e l d is e ñ o
p ro c e s o s de n e g o c io s y a e x is te n te s (e n e l c o n te x to de d e p ro c e d im ie n to s . P o r Ú ltim o , l a in g e n ie r ía d ir e c t a
lo s o b je tiv o s d e fin id o s ), e s p e c ific a y d is e ñ a lo s p r o re c o n s tru y e e l p ro g ra m a e m p le a n d o p rá c tic a s d e in g e
cesos re v is a d o s , y c o n s tru y e p ro to tip o s , r e fin a e in s n ie r ía m o d e rn a d e l s o ftw a re y la in fo r m a c ió n o b te n id a
ta n c ia esos p ro ceso s e n e l seno d e u n n e g o c io . L a R PN d u ra n te la in g e n ie ría inversa.
tie n e u n o b je tiv o que v a m á s a llá d e l s o ftw a re . S u re s u l L o s costes y b e n e fic io s d e la r e in g e n ie r ía se p u e
ta d o s u ele ser la d e fin ic ió n d e fo rm a s e n q u e la s te c d e n d e te rm in a r d e fo rm a c u a n tita tiv a . El c o s te d e l s ta
n o lo g ía s de la in fo r m a c ió n p u e d a n p re s ta r u n m e jo r tus q u o , esto es, los costes a so ciad o s a l m a n te n im ie n to
a p o y o a lo s n e g o c io s . y so p o rte que c o n lle v a u n a a p lic a c ió n e x is te n te se p u e
L a re in g e n ie ría d e l s o ftw a re a b a rc a u n a s erie d e a c ti d e c o m p a r a r c o n lo s costes e s tim a d o s d e la r e in g e n ie
v id a d e s e n tre las q u e se in c lu y e e l a n á lis is de in v e n ta r í a , y c o n la re d u c c ió n re s u lta n te d e lo s c o s te s d e
r io , la re e s tru c tu ra c ió n d e d o c u m e n to s , la in g e n ie r ía m a n te n im ie n to . E n casi to d o s lo s casos e n q u e u n p r o
in v e rs a , la re e s tru c tu ra c ió n d e p ro g ra m a s y d a to s , y la g ra m a tie n e u n a v id a la rg a y m u e s tra e n l a a c tu a lid a d
in g e n ie ría d ire c ta . E l o b je tiv o de esas a c tiv id a d e s c o n u n m a n te n im ie n to d ific u lto s o , la r e in g e n ie r ía r e p r e
siste e n c re a r v e rs io n e s d e los p ro g ra m a s e x is te n te s que s en ta u n a e s tra te g ia d e n e g o c io s e fic ie n te e n r e la c ió n
m u e s tre n u n a m a y o r c a lid a d , y u n a m e jo r m a n te n ib ili- c o n lo s costes.
|s* , * r, hjjfí. * ' ., | t * ' ' ‘

• ■ ■■■ ' ‘
~R E F f i R f i t f f C I V "• i* i i~ T ;i!,-;, Yi - , ~ i
[ARN89] Amold, R. S., «Software Restructuring», Proc. [DEM95] DeMarco, T., «Lean and Mean», IEEE Software,
IEEE, vol. 77, n.° 4, Abril de 1989,pp. 607-617. Noviembre de 1995,pp. 101-102.
[BER92] Berson, A Client/Server Architecture, McGraw- [DIC95] Dickinson, B., Strategic Business Reengineering,
Hill, 1992. LCI Press, 1995.
[BLE93] Bleakley,F.R., «The Best Plans: Many Companies [HAM90] Flammer, M., «Reengineer Work: D on’t Automa-
Try ManagementFads, Only to See Them Flop», The Wall te, Oblitérate», Harvard Business Review, Julio-Agosto
Street Journal, 6 de Julio de 1993, p. 1. de 1990,pp. 104-112.
[BRE91] Breuer, P.T., y K. Laño, «Creating Specification [HAN93] Flanna, M., «Maintenance Burden Begging for a
From Code: Reverse-Engineering Techniques», Journal Remedy», Datamation, Abril de 1993,pp. 53-63.
o f Software Muintenance: Research and Practice, vol. 3,
Wiley, 1991,pp. 145-162. [INM93] Inmon. W.I I.. Developing Client Server Applica
tions, QED Publishing, 1993.
[CAN72] Canning, R., «The Maintenance “Iceberg”», EDP
A nalyzer,vol. 10,n.° 10, Octubre de 1972. [JAY94] Jaychandra, Y., Re-engineeringtheNetworked Enter
prise », MeGraw-Hi11, 1994.
[CASSS] «Case Tools for Reverse Engineering», CASE Out
look, CASE Consulting Group, Lake Oswego, OR, vol. 2, [MAR94] Markosian, L. et al.,«Using an Enabling Techno
n.° 2, 1988,pp. 1-15. logy to Reengineer Legacy Systems, CA CM, vol. 37,n.° 5,
Mayo de 1994,pp. 58-70.
[CHI90] Chifofsky, E.J., y J.H. Cross, II, «Reverse Enginee
ring and Design Recovery: ATaxonomy», IEEE Software, [MER93] Merlo, E. et al., «Reverse Engineering of User
Enero de 1990,pp. 13-17. Interfaces», Proc. Working Conference on Reverse Engi
neering, IEEE, Baltimore, MD, Mayo de 1993,pp. 171
[DAV90] Davenport, T.Ff, y J.E. Young, «The New Indus
www.FreeLibros.org
178. '
trial Engineering: Information Technology and Business
Process Redesign», Sloan Management Review, Summer [MER95] Merlo, E. et al., «Reengineering User Interfaces»,
1990,pp. 11-27. ' IEEE Software, Enero de 1995,pp. 64-73.
555
[MIL81] Miller, J., T eclm iq u eso fP ro g ra m an d S ystem M ain [STE93] Steward, T.A., «Reengineering: The Elot New Mana-
tenance (G. Parikh, ed.), Winthrop Publishers, 1981. ging Tool», F ortune, 23 de Agosto de 1993, pp. 41-48.
[OSB90] Osbome, W.M., y E.J. Chifofsky, «Fitting Pieces to [SWA76] Swanson, E.B., «The Dimensions of Maintenan
the Maintenance Puzzle», IEEE Softw are, Enero de 1990, ce», P ro c. 2 nd In tl. Conf. S oftw are E n g in eerin g , IEEE,
pp. 10-11. Octubre de 1976,pp. 492-497.
[PRE94] Premerlani, W.J., y M.R. Blaha, «An Approach for [VAS93] Vaskevitch,D., C lientlServer Strategies, IDGBooks,
Reverse Engineering of Relational Databases», C A C M , San Mateo, CA, 1993.
vol. 37, n.° 5, Mayo de 1994,pp. 42-49. [WAR74] Wamier, J.D., L ó g ic a 1 C on stru ction o f Prograrns,
[RIC89] Ricketts, J.A., J.C. DelMonaco y M.W. Weeks, «Data VanNostrand Reinhold, 1974.
Reengineering for Application Systems», Proc. Conf. Soft [WEI95] Weisz, M., «BPR is Like Teenage Sex», A m erican
w are M ain ten an ce-1989, IEEE, 1989, pp. 174-179. P ro g ra rn m er,vo \. 8, n.° 6, Junio de 1995,pp. 9-15.
. IQJ --EMAS Y PU N TO S A CONSIDERAR

30.1. Considere cualquier trabajo que haya desempeñado en 30.5. Sugiera alternativas para el papel y el lápiz o para la
los últimos cinco años. Describa el proceso de negocios en documentación electrónica convencional que puedan servir
que haya desempeñado su función. Utilice el modelo RPN como base para la reestructuración de documentos. [Pista:
descrito en la Sección 30.1.3 para recomendar cambios en el Piense en las nuevas tecnologías descriptivas que se podrían
proceso con la intención de hacerlo más eficiente. utilizar para comunicar el objetivo del software.]
30.2. Realice una investigación acerca de la eficacia de la rein 30.6. Algunas personas creen que las técnicas de inteligencia
geniería de procesos de negocios. Presente argumentos a favor artificial incrementarán el nivel de abstracción de los proce
y en contra de este enfoque. sos de ingeniería inversa. Efectúe una investigación sobre este
tema (esto es, el uso de la IA para ingeniería inversa) y escri
30.3. Su profesor seleccionará uno de los programas que haya
ba un artículo breve que se decante por este tema.
desarrollado alguien de la clase durante el curso. Intercambie
su programa aleatoriamente con cualquier otra persona de la 30.7. ¿Por qué es más difícil lograr la completitud a medida
clase. No le explique ni revise el programa. A continuación, que el nivel de abstracción crece?
implemente una mejora (especificada por el instructor) en el 30.8. ¿Por qué tiene que incrementarse la interactividad si es
programa que haya recibido. preciso incrementarse la completitud?
a. Lleve a cabo todas las tareas de ingeniería del software
incluyendo una breve revisión (pero no con el autor del 30.9. Obtenga literatura de productos correspondientes a tres
programa). herramientas de ingeniería inversa y presente sus caracterís
ticas en clase.
b. Lleve la cuenta cuidadosamentede todos los errores encon
trados durante la comprobación. 30.10. Existe una diferencia sutil entre la reestructuración y
c. Describa su experiencia en clase. la ingeniería directa. ¿En qué consiste?
30.4. Explore la lista de comprobación del análisis de inventa 30.11. Investigue en la literatura para hallar uno o dos artícu
rio presentada en el sitio Web SEPA e intente desarrollaran sis los que describan casos prácticos de reingeniería de grandes
tema de evaluación cuantitativodel software que se pueda aplicar computadoras para producir una arquitectura cliente/servidor.
a los programas existentes en un esfuerzo de seleccionar los pro Presente un resumen.
gramas candidatos para su reingeniería. Su sistema deberá ir 30.12. ¿Cómo se determinarían los valores de P4 a P7 en el
más allá del análisis económico presentado en la Sección 30.6. modelo de costesy beneficios presentado en la Sección30.6?
Al igual que muchos tópicos candentes dentro de la comuni 1997), Hunt (P rocessM apping: H ow to R eengineer YourBusi-
dad de negocios, el bombo publicitario de la reingeniería de ness P rocesses, Wiley 1996), y C arry Johanson (B estPrac-
procesos de negocios ha dado pie a una visión más pragmáti tices in R een gin eerin g: W hat Works an d W h atD oesn 't in the
ca del tema. Elammery Champy (R eengineering the C o rp o R eengineering P rocess, McGraw-Hill, 1995) presentan casos
ration, HarperCollins, 1993) anticiparon gran interés por el prácticos y líneas generales detalladas para RPN.
tema con su best seller. Posteriormente, Elammer (B eyoncl Feldmann (T h e P ra ctica l G uide to Business P rocess Reen
R eengineering: H ow the P rocessed-C en tered O rganization is g in eerin g U sin g ID E F O , Dorset House, 1998) estudia una
C h angingO ur Work and O u rL ives , Elarper-Collins, 1997)refi- notación modelada que ayuda en la RPN. Berztiss ( S o f ia r e
nó su visión centrándose en temas «centrados en procesos». M eth o d s f o r Business R eengineering, Springer, 1996)y Spurr
www.FreeLibros.org
L o s libros de Andersen (B u sin ess P ro ce ss Irnprovernent y colaboradores (S o ftw a re A ssista n c e fo r B usiness R eengi
Toolhox, American Society for Quality, 1999), Elarrington et n eerin g, Wiley, 1994) estudian las herramientas y técnicas
al. (B u sinessP rocess Im provem ent Workhook, McGraw-Hill, que facilitan la RPN.
556
C A P Í T U L O 30 REI NG EN IER ÍA
Relativamente pocos libros se han dedicado a la reingenie mation Architectures: Reengineering Information Systems,
ría del software. Rada (Reengineering Software: How to Reu- Prentice Hall, 1996) estudia el puente que existe entre RPN
se Programming to Build New, State-Of-The-Art Software, y la tecnología de información. Aiken (Data Reverse Engi
Fitzroy Dearbom Publishers, 1999) se centra en la reinge neering, McGraw-Hill, 1996) estudia cómo reclamar, reor
niería a p n nivel técnico. Miller (Re engineering Legacy Soft ganizar y reutilizar los datos de la organización. Arnold
ware Systems, Digital Press, 1998) «proporciona un marco (SoftwareReengineering, IEEE Computer Society Press,
de trabajo para mantener los sistemas de aplicaciones sin 1993) ha publicado una antología excelente de los primeros
cronizados con las estrategias de negocios y con los cambios trabajos sobre las tecnologías de reingeniería del software.
tecnológicos». Umar (Application(Re¡Engineering: Building En Internet se disponen de gran variedad fuentes de infor
Web-BasedApplications and Dealing WithLegacies, Prentice mación sobre la reingeniería de procesos de negocios y la
Hall, 1997) proporciona una guía valiosa para aquellas orga reingeniería del software. Una lista actualizada de referen
nizaciones que quieren transformar los sistemas antiguos en cias a sitios (páginas) web se puede encontrar en la dirección
un entorno basado en Web. Cook (BuildingEnterprise Infor h ttp :/w w w .p re s s m a n 5 .c o m .
www.FreeLibros.org
C A P ÍT U L O
^ A IN G E N IE R ÍA D EL S O F TW A R E
«3 I A S IS T ID A POR C O M P U T A D O R A
O D O e l m u n d o h a o íd o ese p ro v e rb io q u e h a b la d e lo s h ijo s d e l z a p a te ro : e l z a p a te ro
T e stá ta n o c u p a d o h a c ie n d o za p a to s p a ra lo s d e m ás que sus h ijo s n o tie n e n sus p ro p io s

zap a to s. A n te s d e lo s años 9 0 , m u c h o s de lo s in g e n ie ro s de s o ftw a re fu e ro n lo s h ijo s d e l
z a p a te ro . A u n q u e estos p ro fe s io n a le s té c n ic o s c o n s tru y e ro n sistem as c o m p le jo s y p ro d u c to s
que a u to m a tiz a n lo s tra b a jo s de o tro s , n o u tiliz a r o n m u c h a a u to m a tiz a c ió n p a ra e llo s m is m o s .
E n la a c tu a lid a d , lo s in g e n ie ro s de s o ftw a re h a n re c ib id o p o r fin su p r im e r p a r d e z a p a to s
n u e v o s — la in g e n ie ría d e l s o ftw a re a sistid a p o r c o m p u ta d o ra ( C A S E )— . L o s z a p a to s n o v ie
n e n c o n ta n ta v a rie d a d c o m o q u e rría n , a v ec es son u n p o c o d u ro s y e n a lg u n o s cas o s re s u lta n
in c ó m o d o s , n o p ro p o rc io n a n u n a s o fis tic a c ió n s u fic ie n te p a ra lo s que lo s g u s ta n d e v e s tir b ie n ,
y n o s ie m p re c o in c id e n c o n la ro p a q u e u tiliz a n lo s que d e s a rro lla n e l s o ftw a re . A h o r a b ie n ,
s u p o n e n u n a p re n d a a b s o lu ta m e n te e s e n c ia l e n e l g u a rd a rro p a d e l que d e s a rro lla e l s o ftw a re y ,
c o n e l tie m p o , serán m á s c ó m o d o s , se u tiliz a r á n c o n m ás fa c ilid a d y se a d a p ta rá n m e jo r a las
n e ce sid a d es d e c a d a u n o d e lo s d e s a rro lla d o re s .
E n lo s c a p ítu lo s a n te rio re s d e este lib ro se h a in te n ta d o p ro p o rc io n a r u n a e x p lic a c ió n r a z o
n a b le p a ra c o m p re n d e r lo q u e sucede e n tre b a s tid o re s d e n tro de la te c n o lo g ía d e la in g e n ie r ía
d e l s o ftw a re . E n este c a p ítu lo , n u e s tro c e n tro d e in te ré s se d e s p la z a h a c ia las h e rra m ie n ta s y
e n to m o s que a y u d a rá n a a u to m a tiz a r e l p ro c e s o d e l s o ftw a re .
VI STAZO RÁPI DO
¿Qué es? Las herramientas CASE ayu de trabajo o para realizar algún hito tie niero del software en la producción de
dan a los gestores y practicantes de la ne un beneficio sustancial. Pero hay resultados de alta calidad. Además,
ingeniería del software en todas las algo incluso más importante. Las herra disponer de automatización permite
actividades asociadas a tos procesos mientas pueden proporcionar nuevas que el usuario de CASE elabore resul
de software. Automatizan las activida formas de observar la información de la tados adicionales y personalizados
des de gestión de proyecte gestionan ingeniería del software —formas que que no serán fáciles ni prácticos de
todos los productos de los trabajos ela- mejoran la perspicacia del ingeniero producir sin el soporte de las herra
horados a través del proceso, y ayudan que realiza el trabajo—. Esto conduce a mientas.
a los ingenieros en el trabajo de análi tomar mejores decisiones y conseguir ¿Cémo puedo «star sogueo d@ que
sis, diseño y codificación. Las herra una calidad mejor del software. lo b e hache eorroetam snio? Uti
mientas CASE se pueden integrar ¿Cuáles sen los pases? CASE se utili lice las herramientas como comple
dentro de un entorno sofisticado. za junto con el modelo de procesos que mento de las prácticas de ingeniería
¿Quién 1# h«e«? Los gestores de pro se haya elegido. Si se dispone de un del software —no como sustitutivo—
yectos y los ingenieros del software juego completo de herramientas, se uti- Antes de poder utilizar las herramien
¿Por qué es importante? La ingeniería fizará CASE a lo largo de casi todos los tas eficazmente deberán aprenderse
del software es difícil. Las herramientas pasos del proceso de software. los conceptos y métodos de la ingenie
www.FreeLibros.org
que reducen la cantidad de esfuerzo que ¿Cuál es e l producto obtenido? Las ría del software. Solo entonces CASE
se requiere para producir un producto herramientas CASE ayudan al inge proporcionará algún beneficio.
559
I N GE NI E RÍ A DEL SOF TW ARE . UN EN F O Q U E P R Á C T I C O
31.1 ¿QUÉ s r f l w n r : » t. b s f ?______
El m ejo r taller de un artesano — sea m ecánico, carp in El taller de ingeniería del softw are se denom ina un
tero o ingeniero del softw are — tiene tres característi entorno de a p o yo integrado a p r o y e c to s (que se des
cas fundam entales: (1) una colección de h erram ientas cribirá posteriorm ente en este cap ítu lo ), y el conjunto
útiles que le ay u d arán en to d o s los p aso s de la c o n s de herram ientas que llena ese taller se denom ina inge
trucció n de un producto; (2) u n a d isposición o rganiza niería del softw’are asistida p o r com putadora (CASE).
da que p erm itirá h allar rápidam ente las h erram ientas y C A S E p ro p o rc io n a al in g e n ie ro la p o sib ilid ad de
utilizarlas con eficacia; y (3) un artesano cualificado que autom atizar actividadesm anuales y de m ejorar su visión
entien d a la form a de u tilizar las herram ientas de m an e general de la ingeniería. A l igual que las herram ientas
ra eficaz. A h o ra es cu an d o los ingenieros del softw are de ingeniería y de diseño asistidos por com putadoraque
reco n o cen que n ecesitan m ás h erram ientas y m ás v aria utilizan los in g en iero s de otras d iscip lin as, las herra
das ju n to con un taller eficiente y organizado en el que m ien tas C A S E ayudan a g ara n tiza r que la calidad se
pued an ubicarlas. diseñe antes de llegar a construir el producto.
3JLÚLSJQHSXBÍICCION P.E■-fiLQ.QjJ&.S BÁSIG Q S.PABA-CASE.

L a in g e n ie ría del so ftw a re a sistid a p o r c o m p u ta d o ra perm iten a cad a un a de las herram ientas com unicarse
puede ser tan sencilla com o u n a ú n ica herram ienta que en tre s í, p a ra cre ar un a base de d atos del proyecto, y
preste su apoyo p ara u n a ú n ica actividad de ingeniería p ara m o strar el m ism o aspecto al usuario final (el inge
del softw are, o tan com pleja com o todo un e n to rn o que niero del softw are). Los servicios de portabilidad per
abarque « h erram ien tas» , u na base de d ato s, personas, m ite n que las h e rra m ie n ta s C A S E y su m arco de
h ardw are, u n a red , sistem as o p erativ o s, están d ares, y integración m igren entre distintas plataform as del hard
otros m il com ponentes m ás. L os b loques de co nstruc w are y sistem as operativos sin un m antenim iento adap-
ción de C A SE se ilustran en la F ig u ra 31.1. C ada b lo tativo significativo.
que de co nstrucción form a el fundam ento del siguiente,
estando las h erram ientas situadas en la parte superior
del m ontón. Es interesante ten er en cuenta que el fu n
dam ento de los entornos C A S E efectivos tiene re la ti
vam ente poco que v er con las herram ientas de ingeniería
del softw are en sí. M ás bien, los entornos p ara la in g e
n iería del softw are se co nstruyen con éx ito sobre u n a
arquitectura de entornos que abarca un h ardw are y un
softw are de sistem as adecuados. A dem ás, la arquitec
tu ra del entorno d eberá ten er en cu en ta los p atro nes de
trabajo hum ano que se aplicarán durante el proceso de
ing en iería del softw are.
á i ; > s CASE m ás valiosas son aquellas

^ c w i i b B y e n con información en el proceso de F IG U R A 3 1 .1 . Bloques d e construcción CASE.
L os b lo q u e s de c o n stru c c ió n rep resen ta d o s en la

F igura 3 1.1 representan un fundam ento com pleto para
la integración de herram ientas CA SE. Sin em bargo, la
Las arquitecturas del entorno, que constan de una pla m ay o r parte de las herram ientas C A S E que se utilizan
tafo rm a h ardw are y de un soporte de sistem a operativo e n la actu alid ad n o han sid o c o n stru id a s em pleando
(incluyendo softw are de red, gestión de la base de datos todos los bloques de co n stru cc ió n anteriorm ente des
y servicios de g estión de objetos), establece los cim ien critos. D e hecho, algunas herram ientas siguen siendo
tos p ara un entorno CA SE. Pero el entorno C A SE en sí las «soluciones puntuales». E sto es, u n a herram ienta se
requiere otros b loques de construcción. E xiste un co n u tiliza p ara prestar apoyo en u n a actividad de ingenie
ju n to de servicios de p o rta b ilid a d que p ro p o rciona un ría del softw are co n cre ta (por e je m p lo , m odelado de
www.FreeLibros.org
puente entre las herram ien tas C A SE , su m arco de in te análisis), pero esta herram ienta no se com unica direc
g ración y la arquitectura del entorno. E l m arco de in te tam ente con otras, no está u n id a a una base de datos del
gración es un grupo de p rogram as especializados que p ro y e c to , y no fo rm a p a rte de un en to rn o integrado
560
CAPÍTULO 31 in g e n ie r ía del s o f t w a r e a s is t id a p o r c o m p u t a d o r a
C A SE (1-CASE). A unque e sta situación no es la ideal, puente entre herram ientas (por ejem plo,una herram ienta
se puede u tilizar u n a h erram ien ta C A S E b astante e fi de análisis y d iseño que se enlaza con un generador de
ciente, aunque se trate de u n a solicitud puntual. código). M ediante la utilización de este enfoque, la siner
g ia entre herram ientas puede p roducir unos resultados
finales que serían difíciles de crear em pleando c ad a una
H e rra m ie n ta in d iv id u a l
de las h e rra m ie n ta s p o r separado. L a in teg ra c ió n de
(s o lu c ió n p u n tu a l)
fu e n te única se produce cu an d o un único v endedor de
herram ientas C A SE integra una cierta cantidad de h e rra
Fuente única m ientas distintas y las vende en form a de paquete. A u n
In tercam bio de datos que este enfoque es bastante eficiente, la arq u itectu ra
cerrada de la m ayoría de los entornos de fu ente Unica
e v ita a ñ a d ir fá c ilm e n te h e rram ien tas p ro c e d e n te s de
Puentes y asociaciones
entre herram ientas otros fabricantes.
EAIP las herramientas CASEde soluciónpuntualpueden

propordonor un beneficio sustancia/, pero un equipa de
F IG U R A 3 1 .2 . O pciones integradas.
software necesita herramientas que se comuniquen entre
sí. /as herramientas integradas ayudan a que el equipa
L os niveles relativos de integración C A S E se m u es desarrolle, organicey contrólelos productos del trabaja.
tran en la F igura 3 1.2. E n el extrem o inferior del espec Utilícelos.
tro de integración se encuentra la h erram ien ta individual
(solución puntual). C uando las herram ientas individuales E n el ex trem o superior del esp ectro de integración
p ro p o rc io n a n serv icio s p a ra e l in te rc a m b io de d ato s se encuentra el entorno de apoyo integrado a p r o y e c
(com o lo hacen la m ayoría), el nivel de integración m ejo tos integrado (EA IP). Se han creado estándares en cada
ra ligeram ente. E stas herram ientas pro d u cen su salida u no de los bloques de construcción descritos anterior
en un form ato estándar que deberá ser com patible con m ente. L os fabricantes de herram ientas C A S E utilizan
otras herram ientas que sean capaces de leer ese form a lo s están d ares E A IP para c o n stru ir h e rram ien tas que
to. E n algunos casos, los constructores de h erram ientas sean com patibles con el EAIP, y que por tanto sean co m
C A SE com plem entarias tra b a ja n ju n to s p ara form ar un patibles entre s í.
31.3 VNA IMQ.MQÜÍA,I>£.HERRAMIENTAS. CASE

Existe un cierto núm ero de riesgos que son inherentes n istradores o personal técnico, p o r su utilización en los
siem pre que se inten ta efectuar u n a catego rización de distintos pasos del proceso de ingeniería del softw are,
las herram ientas CA SE. E xiste una sutil im plicación que p o r la arquitectura del en to rn o (hardw are y softw are)
consiste en que para crear un entorno C A S E efectivo se que les p resta su apoyo, o incluso p o r su origen o c o s
deberán im plem entar todas las categorías de herramientas te [Q ED 89], La taxonom ía que se presenta a continua
— esto no es ni sencillo, ni cierto— . C uando hay p erso ción u tiliza com o criterio principal la función.
nas que creen que un a h erram ien ta p ertenece a una cate
goría, se puede crear cierta confusión (o contradicción)
al ubicar u n a h erram ien ta específica dentro de otra cate
goría. Es posible que algunos lectores piensen que se ha
om itido una categoría com pleta — elim inando por ta n
to un conjunto de h erram ientas com pleto e incluirlo así
■W -
Herramientas CASE
en el entorno C A SE global— . A dem ás, una categoriza-
ción sencilla tiende a ser p lan a - e s t o e s , no se m uestra H e rra m ie n ta s de in g en iería de procesos de n eg o
la in teracció n jerárq u ica de las herram ientas o las rela cio. A l m o delar los requisitos de inform ación e stra té
ciones que existen entre ellas— . A p esar de estos rie s gica de una organización, las herram ientas de ingeniería
gos, es n ecesario crear una tax o n o m ía de h erram ientas de p ro ce so s de n eg o cio s p ro p o rcio n an un « m etam o -
CA SE — para com prender m ejo r la am plitud de C A SE delo» del cual se derivan sistem as de inform ación e sp e
y p ara apreciar m ejo r en donde se p u ed en aplicar estas cíficos. E n lugar de centrarse en los requisitos de una
www.FreeLibros.org
herram ientas dentro del p roceso del software — . aplicación específica, estas herram ientas C A S E m o d e
L as herram ientas C A S E se p u ed en clasificar p o r su lan la inform ación de negocio cuando ésta se transfiere
fu n ció n , p o r su p a p e l co m o in stru m en to s para a d m i entre distintas entidades org an izativ asen el seno de una
561
in g e n ie r ía del s o f t w a r e , un e n f o q u e p r á c t ic o
com pañía. El o b jetiv o prim o rd ial de las h erram ientas

c s t m
de esta categoría consiste en representar objetos de datos B análisis y gestión de riesgos se hato
de negocio, sus relaciones y la form a en que fluyen estos en el Capitulo 6.
objetos de datos entre distintas zonas de negocio en el
seno de la com pañía.
H erram ientas de gestión de proyectos. La planifi
cación del proyecto y el plan del proyecto deberán ser
lü lá liL L M U W ilJ
lo ingeniería de procesos efe negocios se trato
rastreados y m onitorizados de form a continua. Además,
en el Capítulo 10.
el g esto r deb erá u tilizar las h erram ien tas que recojan
m étricas que en Ultima instancia proporcionen una indi
Modelado de procesos y herramientas de gestión. cación de la calidad del producto del software. Las herra
Si u n a o rganización trab aja p o r m ejo rar un p roceso de m ie n ta s de esta c a te g o ría su elen ser ex ten sio n es de
herram ientas de planificación de proyectos.
negocio (o de softw are) lo p rim ero que debe h acer es
entenderlo. L as herram ientas de m odelado de procesos
(llam adas tam b ién herram ientas de tecnología de p r o fis a a m a g a
A segulm lentoy lo monltorlzaclón se tratan
cesos) se u tilizan p ara rep resen tar los elem entos clave
en el Capitulo 7.
del proceso de m an era que sea posible entenderlo mejor.
E stas herram ientas tam bién pueden prop o rcio n ar v ín cu
los con descripciones de procesos que ayuden a quienes
estén im plicados en el proceso de co m p ren d erlas tareas H erram ientas de segu im ien to de requisitos.
C uando se desarrollan grandes sistem as, las cosas «se
que se requieren para llevar a cabo ese proceso. A dem ás,
derrum ban». E s decir, el sistem a proporcionado suele
las herram ientas de gestión de p rocesos pueden pro p o r
no satisfacer los requisitos especificados p o r el cliente.
cionar vínculos con otras herram ientas que proporcionan
El objetivo de las herram ientas de seguim iento es pro
un apoyo para las actividades de proceso ya definidas.
p o rcionar un enfoque sistem ático para el aislam iento de
los requisitos, com enzando p o r el R FP del cliente o por
la esp ecificació n . L as h e rra m ien tas típicas de segui
los elementos de procesos del software se tratan
m iento de requisitos com binan una evaluación de tex
en el Capítulo 2.
tos p o r interacción hum ana, con un sistem a de gestión
de b ases de datos que alm acen a y cate g o riz a todos y
cada uno de los requisitos del sistem a que se «analizan»
H erram ientas de planificación de proyectos. L as
a p artir de la R FP o especificación original.
herram ientas de esta c ateg o ría se c e n tra n en d os áreas
prim ordiales: estim a c ió n de co stes y de e sfu erzo s del
proyecto de softw are y planificació n de proyectos. Las i¿ u u r a a n B m
h e rra m ie n tas de estim ació n c alcu lan el esfu erzo e sti Los métodos de ingenieno de requlsltosse tratan
m ad o , la d u ra c ió n del p ro y e c to y el n ú m ero de p erso en el Capitulo 10.
nas reco m en d ad o p ara el proyecto. L as h erram ien tas
de planificació n de p royectos h acen posible que el g e s
to r defina todas las tareas del p ro y e c to (la estru ctu ra Herramientas de métricas y de gestión. Las m étri
cas del softw are m ejoran la capacidad del gestor para
de desglose de tareas), que cree u n a red de tareas (nor
controlar y coordinar el proceso de ingeniería del soft
m alm ente em p lean d o u n a en trad a g ráfica), que re p re
sente las in te rd e p e n d e n cia s en tre tareas y que m o d ele w are y la capacidad del ingeniero para m ejorar la cali
d ad del softw are que se produce. L as m étricas o
la can tid a d de p a ra le lis m o que sea p o sib le p a ra ese
herram ientas de m edidas actuales se centran en caracte
proyecto.
rísticas de procesos y productos. Las herram ientas orien
tadas a la gestión se sirven de m étricas específicas del
G s m s m s m k p royecto (por ejem plo, L D C /persona-m es, defectos por
los técnicas de estimación se presentan en el Capitulo 5. punto de función) que proporcionan una indicación glo
los métodos de planificación se tratar en el Capítulo 7.
bal de productividad o de calidad. Las herram ientas con
o rientación técnica determ inan las m étricas técnicas que
H erram ientas de análisis de riesgos. L a identifi proporcionan una m ejo r visión de la calidad del diseño
cació n de p o sib le s rie sg o s y el d esarro llo de u n plan o del código.
para m itigar, m o n ito rizar y gestionar esos riesgos tiene
una im portancia fundam ental en los p royectos grandes. jJ á m m m s m
Las herram ientas de análisis de riesgos h acen posible Los métricas se presentan en los Capítulos 4, 19 y 24.
www.FreeLibros.org
que el g esto r del proyecto construya u n a tabla de rie s
gos pro porcionando una guía d etallada en la id entifica H erram ientas de docum entación. Las herram ien
ción y análisis de riesgos. tas de producción de docum entos y de autoediciónpres-
562
CAPITULO 31 INGENIERÍA DEL S OF TW AR E A SIS TI D A P O R C O M P U T A D O R A
tan su apoyo a casi tod o s los aspectos de la ingeniería

del softw are, y rep resen tan una im portante oportunidad
c m m m m
El r e p o s t e de s o ñ w d r e s e e te i en el Capítulo 9,
de «apro v ech am ien to » p ara todos los que desarrollan
softw are. L a m ay o ría de las organizaciones dedicadas
al d e sa rro llo de so ftw a re in v ie rte n u n a c a n tid a d de Herramientas de gestión de configuración de soft
tiem po considerable en el desarrollo de docum entos, y
ware. L a gestión de configuraciónde softw are (G C S ) se
en m u ch o s c a so s el p ro ceso de d o c u m e n tac ió n en s í encuentra en el núcleo de todos los entornos CASE. Las
herram ientas pueden ofrecer su asistencia en las cin co
resu lta b astante deficiente. Es frecuente que una orga
nizació n de d esarrollo de softw are inv ierta en la docu tareas principales de GCS — identificación, control de ver
m en tació n hasta un 20 o un 30 p o r 1OOyle su esfuerzo siones, control de cam bios, auditoría y c o n ta b ilid ad de
g lo b al de d e sa rro llo de so ftw a re . P o r e sta razó n , las estados— . La base de datos CASE p roporciona el m e ca
nism o de identificartodos los elem entos de configuración
h erram ientas de d ocum entación suponen una oportuni
dad im portante p ara m ejo rar la productividad. y de relacionarlo con otros elem en to s;el proceso de co n
trol de cam bios se puede im plem entar con ayu d a de las
herram ientas especializadas;un acceso sencillo a los e le
e g a m a g m i m entos de configuración individuales facilita el proceso
lo documentación se estudia a lo largo de todo el de auditona; y las herram ientas de com unicación C A SE
libro. En SepaWeb se presentan más datos. pueden m ejorar enorm em ente la Contabilidad de estados
(ofreciendo inform ación acerca de los cam b io s a todos
aquellos que necesiten conocerlos).
H erram ientas de softw are de sistem a. C A S E es
u n a tecn o lo g ía de estacio n es de trab ajo . P or tan to , el o m m jm L L M
entorno C A S E d eberá adaptarse a un softw are de sis Los actividades GCS en donde se incluyen
tem a en red de alta calidad, al correo electrónico, a los lo ¡d en ffa ciá n , control de versiones, control
tablones de anuncios electrónicos y a otras posibilida de cantíos, c a ito ® ,, y contoU dod de estados
se estudion en el Capítulo 9.
des de com unicarse.
G ssm m n m * H erram ientas de análisis y d iseño. L a s h e rra

Consulte IOSCapítulos27,28 y 2 9 poro in estudio m ientas de análisis y diseño hacen p o sib le que el in g e
limitado de estos temas. niero del softw are cree m odelos del sistem a que v a y a a
construir. Los m odelos contienen u n a representación de
los datos, función y co m p o rtam iento(en el nivel de an á
H erram ientas de control de calid ad . L a m ay o r lisis), así com o caracterizaciones del d ise ñ o d e datos,
p arte de las h e rra m ie n ta s C A S E q u e a firm a n te n e r de arquitectura, a nivel de co m p o n en tes e in terfaz'. A l
com o principal interés el control de calidad son en re a efectuar una com probación de consistencia y validez de
lidad herram ientas de m étricas que h acen una a u d ito los m odelos, las herram ientas de an álisis y diseñ o p ro
ría del có d ig o fu en te p ara d e te rm in a r si se aju sta o no porcionan al ingeniero del softw are un cierto g rado de
a cierto s e stán d ares del lenguaje. O tras h e rram ie n tas visión en lo tocante a la representación del an álisis, y
ex tra e n m é tric a s técn icas (C ap ítu lo s 19 y 24) en un le ayudan a elim inar errores antes de que se propaguen
esfuerzo p o r e x tra p o la r la calidad del so ftw are que se al diseño, o lo que es peor, a la pro p ia im plem entación.
está co n stru y en d o .
Ü Ü ILiiU ^lLLI Eonálisís y el diseño se estudien en I ® Partes

GCS se presenta en el Capitulo 8. Tercera y Cuarto de este libro.
Herramientas de gestión de bases de datos. El soft

w are de g e stió n de bases de d ato s sirve co m o fu n d a HerramientasPRO/SIM. Las herramientas PRO/SfM
m en to p ara e s ta b le c e r u n a b ase d e d ato s C A S E (de construcción de prototipos y sim ulación) [NIC90J pro
(repositorio), que tam b ién se den o m in ará base de datos porcionan al ingeniero del softw are la capacidad de pre
del proyecto. D ada la im portancia de los objetos de co n decir el com portam iento de un sistem a en tie m p o real
figuración, las herram ientas de gestión de bases de datos antes de llegar a construirlo. A dem ás, tam bién le capaci
p ara C A SE pu ed en evolu cio n ar a p artir de los sistem as tan para desarrollar sim ulaciones del sistem a de tiem po
de gestión de bases de datos relacionales (SG BD R) para real, lo que perm itirá que el cliente obtenga ideas acerca
transform arse en sistem as de gestión de bases de datos de su funcionam iento, com portam ientoy respuesta antes
orientadas a objetos (SG B D O O ). de la verdadera im plem entación.
www.FreeLibros.org
1 La herramientas de diseño y de análisis orientado a objetos pro
porcionan representaciones análogas.
563
INGE NIE RÍA DEL S O F TW A RE . UN E N F O Q U E P R A C T I C O
La construcción de prototiposy la simulación l-W E B se estudio en el Copilulo 2?

se estudian brevemente en el Capitulo 10.
H erram ientas de integración y p ru eb as. E n el
Herramientas de desarrollo y diseno de interfaz. Las directorio de herram ientas de pruebas de softw are del
herram ientas de desarrollo y diseño de interfaz son en rea Softw are Q uality E ngineering [SQ E 95], se definen las
lidad un conjunto de herram ientas de com ponentes de pro categorías de herram ientas de pruebas siguientes:
gram as (clases) tales com o m enús, botones, estructurasde « adquisición de datos: h e rram ie n tas que adquieren
ventanas, iconos, m ecanism os de desplazam iento de la los datos que se utilizarán durante la prueba;
pantalla, controladores de dispositivos, etc. Sin em bargo, • m edida estática: herram ientas que analizan el código
estos conjuntos de herram ientas se están viendo sustitui fuente sin ejecutar casos de prueba;
dos por herramientas de construcciónde prototiposde inter
faz que p erm iten una rápida creación en pan talla de € m m BBEBSI
La comprobación del software se estudia
interfaces de usuario sofisticadas, que se ajustan al están
en ios Capítulos 1 7 ,1 8 y 23 así como en los
dar de interfaz que se haya adoptado para el softw are.
c m m m E Ek • m e d id a d in á m ica : h e rra m ie n ta s que an alizan el

los elementos del diseño de Interfaz de usuario có d ig o fuente durante la ejecución;
se presentan en el Capítulo 15. « sim ulación: herram ientas que sim ulan las funciones
del hardw are o de otros elem entos externos;
. gestión de p ru e b a s: herram ientas que prestan su asis
H erram ientas de construcción de prototipos. Se tencia en la planificación, desarrollo y control de las
puede u tilizar toda una gam a de herram ientas de co n s pruebas;
trucción de prototipos. Los generadores de p a n ta lla s per . herram ientas d efu n c io n a lid a d cruzada: se trata de
m iten al ingeniero del softw are d efinir rápidam ente la herram ientas que atraviesan los lím ites de las cate
disposición de la p an talla p ara aplicaciones interactivas. gorías anteriores.
O tras herram ientas de prototipos C A SE m ás sofisticadas
D ebería tenerse en cuenta que m uchas de las herra
perm iten la creación de un diseño de datos, acom pañado
m ientas de p ru eb a poseen características que abarcan
p o r d iseñ o s e in fo rm es d e la p an talla. M uchas h erra
dos categorías o m ás de las anteriorm ente m encionadas.
m ientas de análisis y diseño son más extensas y pro p o r
cio n a n o p cio n es de co n stru c c ió n de p ro to tip o s. Las Herramientas de análisis estático. Las herramientas
herram ientas PR O /SIM generan un diseño esquem ático de análisis estático prestan su asistencia al ingeniero del
de código fuente en A da y C para las aplicaciones de inge softw are a efectos de derivar casos prácticos. En la indus
niería (en tiem po real). P or últim o, una gam a am plia de tria se utilizan tres tipos distintos de herram ientas estáti
herram ientas de cuarta generación poseen tam bién carac cas de prueba: herram ientas de prueba basadas en código;
terísticas de co nstrucción de prototipos. lenguajes de prueba esp ec ializad o s y herram ientas de
prueba basadas en requisitos. Las herram ientas de prueba
c a a m iM ia basadas en código adm iten un có d ig o fuente (o LDP)
lo construcciónde prototiposse estudio com o entrada, y llevan a cabo varios análisis de los que
en los Copítulos 2 y 11. se obtiene la generación de casos de prueba. Los lengua
j e s deprueba especializados (por ejem plo,ATLAS) hacen
posible que el ingeniero del softw are escriba especifica
H erram ientas de program ación. L a categoría de ciones de prueba detalladas para describir todos los casos
herram ientas de program ació n ab arca los co m p ilad o de prueba y la logística de su ejecución. Las herram ien
res, editores y depuradores disponibles p ara apoyar a la tas de p ru e b a basadas en requisitos aíslan los requisitos
m ay o ría de lo s lenguajes de program ació n co n vencio del usuario y sugieren los casos de prueba (o clases de
nales. A dem ás, en esta c ateg o ría tam b ién residen los prueba) que ejercitarán esos requisitos.
en to m o s de prog ram ació n orientados a objetos ( 0 0 ) ,
los lenguajes de cu arta generación, los en to m o s de p ro
gram ación g ráfica, los g e n erad o res de a p licacio n es y
Los métodos de comprobación de cap negra
los lenguajes de consulta de bases de datos.
se estudian en el Capítulo 17.
H erram ientas de desarrollo de W ebs. L as activi
dades asociadas a la ingeniería W eb están apoyadas por H erram ientas de análisis d inám ico. L as h e rra
una variedad de herram ientas de desarrollo de WebApps. m ien tas de an álisis d in á m ic o in te ra ctú a n con el pro
www.FreeLibros.org
E n tre estas h e rra m ie n tas se in c lu y e n las q u e p resta n gram a que se esté ejecu tan d o , prueban la cobertura de
ayuda en la g eneración de texto, gráficos, form ularios, rutas, prueban las afirm aciones acerca del valor de varia
guiones, applets y otros elem entos de u n a p ág in a W eb. bles específicas e instrum entan p o r otro lado el flujo de
564
CAPÍTULO 31 I N GE NIE RI A DEL SOF TW ARE ASISTIDA P O R C O M P U T A D O R A
ejecución del program a. Las herram ientas dinám icas

CHS S S S P W T k
pueden ser intrusivas, o no intrusivas. Las herramien Ia pruebaC/S se estudio enel Copflub 28.
tas intrusivas m odifican el software que hay que com
probar mediante la inserción de sondas (instrucciones
adicionales) y que efectúan las actividades m enciona Herramientas de reingeniería. Las herram ientas
das anteriormente. Las herramientas de prueba no intru para el software heredado abarca un conjunto de activi
sivas utilizan un procesador hardware por separado que dades de mantenim iento que actualmente absorben un
funciona en paralelo con el procesador que contiene el porcentaje significativo de todo el esfuerzo relacionado
program a que se está probando. con el software. La categoría de herram ientas de rein
geniería se puede subdividiren las funciones siguientes:
Herramientas de gestión de pruebas. Las h erra
mientas de gestión de pruebas se utilizan para controlar • herramientas de ingeniería inversa p a r a p ro d u cir
y coordinar las pruebas del software por todos y cada uno especificaciones: se tom a el código fu ente com o
de los pasos principales de las pruebas. Las herram ien entrada y se generan modelos gráficos de análisis y
tas de esta categoría gestionan y coordinan las pruebas diseño estructurados,listas de utilización y m ás infor
de regresiones, efectúan comparaciones que determinan mación sobre el diseño;
las diferencias entre la salida real y la esperada y reali
zan pruebas por lotes de program as con interfaces hom iim U U M J L I
bre-m áquina interactivas. Adem ás de las funciones los métodosde reingenierío se estudion
indicadas anteriormente, muchas herram ientas de ges en el Capítulo 30.
tión de pruebas sirven tam bién como controladores de
pruebas genéricos. Un controlador de pruebas lee uno o • herram ientas de reestructuración y análisis de
más casos de prueba de algún archivo de pruebas, aplica código: se analiza la sintaxis del program a, se genera
formato a los datos de prueba para que se ajusten a las una gráfica de control de flujo y se genera automá
necesidades del software que se está probando, e invoca ticam ente un program a estructurado; y
entonces al software que es preciso probar.
• herram ientas de reingeniería p a r a sistem as O n
line: se utilizan para m odificar sistem as de bases
t m f f g B i i
de datos on-line (por ejem plo, para convertir archi
Las estrategiasde prueba se estudion
en el Capítulo 18. vos IDMS o DB2 en un fo rm a to de entidades y
relaciones).
Herramientas de pruebas cliente/servidor. El Muchas de las herram ientas anteriores se ven lim i
entorno C/S exige unas herram ientas de pruebas espe tadas a lenguajes de program ación específicos (aunque
cializadas que ejerciten la interfaz gráfica de usuario abarcan la m ayoría de los lenguajes principales) y
y los requisitos de com unicacionesen red para el cliente requieren un cierto grado de interacción con el inge
y el servidor. niero del software.
Aunque se pueden obtener beneficios individualm en

te de las herram ientas CASE que abarcan actividades ¿Cuáles son los beneficios
de ingeniería del software por separado, la verdadera
potencia de CASE solam ente se puede lograr m edian
te la integración. Entre los beneficios del CASE inte
§ de CASE integradas?
Ahora bien, 1-CASE tam bién expone a desafíos sig

grado (1-CASE) se incluyen: (1) una transferencia nificativos. En cada acción exige unas representaciones
regular de inform ación (m odelos, program as, docu consecuentes de la inform ación de la ing en iería del
m entos, datos) entre una herram ienta y otra, y entre software; unas interfaces estandarizadas entre las herra
un paso de ingeniería y el siguiente; ( 2 ) una reducción m ientas, un m ecanism o hom ogéneo para la co m u n i
del esfuerzo necesario para efectuar actividades glo cación entre el ingeniero del softw are y todas sus
bales tales com o la gestión de configuración de soft herramientas, y un enfoque efectivo que hará posible
ware, el control de calidad y la producción de que 1-CASE se desplace a lo largo de distintas p lata
documentos; (3) un aum ento del control del proyecto formas de hardware y distintos sistemas operativos. Los
que se logra m ediante una m ejor planificación, moni- entomos 1-CASE generaleshan com enzadoa surgirm ás
torización y com unicación; (4) una m ejor coordina lentam ente de lo que inicialm ente se esperaba. Sin
www.FreeLibros.org
ción entre los m iem bros del personal que estén embargo, los entornos integrados sí que existen, y con
trabajando en grandes proyectos de software. el paso de los años se van haciendo más poderosos.
565
• p erm itir un acceso directo y no secuencia1 a cual

quier herram ienta del entorno;
CLAVE
• establecer un apoyo autom atizado para el m odelo de
Ia ¡ntegraciónde las herramientas CASE exige uno base
procesos de softw are que se h ay a seleccionado, inte
de datos que contenga las representacionesconsecuentes
grando herram ientas C A SE y elem entos de configu
de la información de la ingenieríodel softwore.
rac ió n del so ftw are en u n a e stru c tu ra están d ar de
El térm in o integración im plica tan to co m binación desglose de trabajo;
com o cierre. 1-CASE co m bina to d a u n a g am a de h erra • perm itir que los usuarios de ca d a u n a de las herra
m ien tas e info rm ació n d istin to s d e tal m o d o q u e hace m ientas puedan experim entar con el aspecto e inte
p o sib le el cierre de la co m u n ic a c ió n e n tre la s h e rra racción de la interfaz hom bre-m áquina;
m ientas, en tre p ersonas y en tre p rocesos de softw are.
Las herram ientas se integran de tal m an era que la in fo r la z m im i- ii
m ació n de ingen iería del softw are esté disponible para los temos relacionados con los procesosse estudian
todas las herram ientas que se n ecesiten ; la u tilización en los Capítulos2,4 y 7. LosECs se presentan
se integra de tal m o d o que se p ro p o rcio n a un aspecto y en el Capítulo 9.
una interacción co m ú n p ara todas las h erram ientas; y
se integra u n a filosofía de d esarrollo que aplica p rácti • dar soporte a la com unicación entre ingenieros del
cas m odernas y m étodos y a probados. softw are; y
P ara d efin ir la integración en el contexto del p ro ce
so del softw are, es n ecesario establecer un conjunto de • recoger m étricas tanto técnicas com o de gestión que
requisitos p ara 1-C A S E [F O R 89a], U n en to rn o C A SE se puedan u tilizar para m ejorar el proceso y el pro
integrado debería: ducto.
• pro p o rcio n ar un m ecan ism o p ara com partir la in fo r P ara a lcan zar estos objetiv o s, cad a uno de los b lo
m ació n de la ingeniería del softw are en tre todas las q u e s de c o n s tru c c ió n de u n a a rq u ite c tu ra (C A SE
herram ientas dentro del entorno; — Fig. 31.1 —> deb erá en c ajar con los dem ás sin nin
• hacer posible que un cam bio de un elem ento de infor gú n tip o de lim itación. L o s b lo q u es de construcción
m ació n se sig a h asta los dem ás elem entos de in fo r fu n d am en tales - a r q u i t e c t u r a d e l entorno, plataform a
m ació n relacionados; hard w are y siste m a o p e ra tiv o — d eb erán «unirse» a
■ pro p o rcio n ar un control de versiones y u n a gestión través de un co n ju n to de servicios de portabilidad a un
de co n fig u ració n g en eral p ara to d a la inform ación de m a rc o de re fe re n c ia de in te g ra c ió n que a lca n ce los
la ingeniería del softw are; o b jetiv o s ind icad o s anteriorm ente.
J i í I£ fiH A £ IÚ tlL
U n e q u ip o de in g e n ie ría del so ftw a re u tiliz a h e rra ra 3 1 .3 . se m u e stra un m o d e lo se n c illo del m arco de

m ie n ta s C A S E , los m é to d o s c o rre s p o n d ie n te s y un re fe re n c ia que rep re se n ta ú n icam en te los co m ponen
m arco de re fe re n c ia de p ro c e so co n o b je to de crear tes in d ic a d o s anteriorm ente.
un co n ju n to de in fo rm acio n es de in g e n ie ría del so ft
w are. El m arco de re fe re n c ia de in te g ra c ió n fa c ilita
la tran sferen cia de inform ación d esde y h acia ese co n
ju n to d e in fo rm a c io n e s . P a ra lo g ra r e s to , d e b e rá n
ex istir los co m p o n en tes de a rq u ite c tu ra siguientes: la
c re a c ió n de u n a b a se d e d a to s ( p a r a a lm a c e n a r la
info rm ació n ); la co n stru c c ió n de un sistem a de g e s Una lista de todos los elementosde información
tión de o b jeto s (p ara g e stio n a r los c a m b io s e fe c tu a de la Ingeniería del software puede encontrarse
d o s en la in fo rm a c ió n ); la c o n s tru c c ió n d e un boio losECs.
m ecan ism o de co n tro l de h e rra m ie n tas (p ara c o o rd i
nar la u tilizació n de herram ientas C A S E ), y un a in ter L a capa de interfaz del usuario (Figura 3 1 .1 ) incor
faz de u su a rio que p ro p o rc io n e u n a ru ta c o n se c u e n te p o ra un conjunto de herram ientas de interfaz estanda
e n tre la s a c c io n e s e fe c tu a d a s p o r el u s u a rio y la s rizado, con un protocolo de presentación com ún. El kit
h e rra m ie n tas que está n d e n tro del entorno. L a m a y o de herram ientas de interfaz co n tien e softw are para la
www.FreeLibros.org
ría d e los m o d e lo s (p o r e je m p lo , [F O R 9 0 ], [S H A 95] gestión de la interfaz hom bre-m áquina, y una bibliote
del m a rc o de re fe re n c ia de in te g ra c ió n re p re se n ta n a ca de objetos de visualización. A m bos proporcionan un
esto s co m p o n en tes co m o si fu e ra n capas. E n la F ig u m ecanism o consecuente para la com unicación entre la
566
CAPÍTULO 31 IN GENIERIA DEL S OF TW AR E A S I S T I D A P O R C O M P U T A D O R A
interfaz y las h erram ientas C A SE individuales. El p r o m u ltita re a, co o rd in a el flu jo d e in fo rm ació n d esd e el

tocolo de p re se n ta c ió n es el co n ju n to de lín eas g e n e re p o sito rio y el siste m a d e g e s tió n d e o b je to s a la s
rales que p ro p o rc io n a un m ism o a sp e c to a to d a s las herram ientas, realiza las funciones de seguridad y au d i
herram ientas C A SE. L as c o n v en cio n es del d iseño de toría y recoge m étricas acerca de la utilización de h erra
p an talla, n o m b re s y o rg a n iz a c ió n d el m e n ú , ic o n o s, m ientas.
n o m b res de los o b jeto s, u tiliz a c ió n del teclad o y del
ratón, y el m ecanism o p ara acceder a las herram ientas
se d efinen tod o s ellos com o parte del p rotocolo de p re
sentación. Referencia W ebl
los recursos paro la integración de herramientas CASE
Capa de interfaz de usuario y poro los Entornos de Integración de Ingenierío
Kit de herramientas de interfaz
del software se pueden obtener en:
Protocolo de presentación
see.cs.flinders.edv.au/seweb/ti/
Servicios de gestión de herramientas L a capa de g estió n de objetos (C G O ) llev a a cabo
Herramienta
ti n r
Capa de herramientas
las funciones de gestión de configuración que se d e s
cribían en el C apítulo 8. E n esencia, el softw are de esta
|C A S E j
L J l__ H__II__I capa de la arquitectura de m arco de referencia pro p o r
ciona el m ecanism o para la integración de herram ien
Capa de gestión de objetos tas. C ada herram ienta C A SE «se enchufa» en la capa
Servicios de integración
Servicios de gestión de configuración de gestión de objetos. A l funcionar en co n ju n to con el
repositorio C A SE, la C G O proporciona los servicios de
'■¡hA integración —un conjunto de m ódulos estándar que aco
S p ó de-datos plan las herram ientas con el re p o s ito rio —. A dem ás, la
O M L proporciona los servicios de gestión de co n figu
ración haciendo posible la id e n tifica ció n de todos los
F IG U R A 31.3. Modelo de arquitectura para el marco objetos de configuración, llev an d o a cabo el control de
de referencia de integración. v e rsio n e s y p ro p o rc io n an d o ap o y o p a ra el co n tro l de
cam bios, auditorías y contabilidad de estados.
L a capa de h erra m ien ta s in co rp o ra un co n ju n to de L a capa de repositorio com partido es la base de datos
se rv ic io s de g e stió n d e h e rra m ie n ta s c o n las h e rra C A SE y las funciones de control de acceso que hacen
m ientas C A SE en sí. L os servicios de gestión de herra posible que la capa de gestión de objetos interactúe con
m ie n ta s (S G H ) c o n tro la n el c o m p o rta m ie n to de las la base de datos. L a in te g ra c ió n de d a to s se logra
h erram ientas d en tro del entorno. Si d u ran te la e je c u m ediante las capas de gestión de objetos y de rep o sito
ción de u n a o m ás h e rra m ie n tas se em p lea la m ultita- rio com partido que se estudian m ás adelante y con m ás
rea, SGH e fe c tú a la s in c ro n iz a c ió n y c o m u n ic a c ió n profundidad en este m ism o capítulo.
- J L f i - £ L . a E £ í ? S I I O B I Q . . g & S E _________ ____________ mm_____________________________________
El D iccionario Webster define la palabra repositoriocom o del softw are) es interactuar con el repositorio em pleando
.«todo objeto o persona considerado centro de acum ula herram ientas CA SE integradas con él.
ción o almacenam iento». D urante las prim eras fases de la E n este libro, se utiliza un d eterm in ad o n ú m ero de
historia del desarrollo del softw are, el repositorio era en térm inos distintos para hacer alusión al lugar de alm a
realidad una persona -el programador que tenía que recor cenam iento de la inform ación de la ingeniería del soft
dar la ubicación de toda la inform ación relevante para un ware: base de datos C A SE , base de datos del p ro y e c to ,
determ inado proyecto de softw are, que tenía que recordar base de datos de entorno de apoyo integrado a p r o y e c
inform ación que nunca se había escrito y que tenía que to (EA1P), diccionario de requisitos (una base de datos
reconstruirla inform ación que se había perdido— . Triste lim itada) y repositorio, A unque existen sutiles d iferen
m ente, la utilización de una persona com o «centro de acu cias entre algunos de estos térm inos todos ellos hacen
m ulación y alm acenam iento» (aunque corresponda con la referencia al centro de acum ulación y alm acenam iento.
definición del diccionario) no funciona dem asiado bien.
En la actualidad, el repositorio es una «cosa» —una base
31.6.1. El papel del repositorio en 1-CASE
www.FreeLibros.org
de datos que actúa com o centro tanto para la acum ulación
com o para el alm acenam iento de inform ación de ingenie El repositorio de un en to rn o 1-CASE es el conjunto de
ría del software— . El papel de la persona (del ingeniero m ecanism os y de estructuras de datos que consiguen la
567
integración entre datos y herramientas, y entre datos y 31.6.2. C a r a c t e r í s t i c a s y c o n t e n i d o s

datos. Proporciona las funciones obvias de un sistema Las características y contenido del repositorio se entien
de gestión de bases de datos, pero, además, el reposito den especialmente bien examinándolo desde dos pers
rio lleva a cabo o precipita las funciones siguientes pectivas: ¿Q ué es lo que hay que alm acenar en el
[FOR89b]: repositorio, y qué servicios específicos son los que pro
• integridadde datos: incluye funciones para validar porciona el repositorio? En general, los tipos de cosas
las entradas efectuadas en el repositorio, para asegu que habrá que alm acenar en el repositorio incluyen:
rar la consistencia entre objetos relacionados, y para • el problem a que hay que resolver;
efectuar automáticamente m odificaciones «en cas
cada» cuando un cambio efectuado en un objeto exige . inform ación acerca del dominio del problema;
algún cambio en otros objetos relacionados con él; « la solución del sistema a m edida que va surgiendo;
• información compartida:proporciona un mecanismo . las reglas e instrucciones relativas al proceso de soft
para com partir inform ación entre múltiples desarro ware (m etodología) que se está siguiendo;
lladores y entre múltiples herramientas; gestiona y . el plan del proyecto, sus recursos y su historia;
controla el acceso m ultiusuario a los datos, y blo
. inform ación acerca del contexto organizativo.
quea/desbloquea objetos para que los cambios no se
superpongan inadvertidamente; En la Tabla 31.1 se ha incluido una lista detallada de
tipos de representaciones, documentos y otros produc
^ ¿Cuales son las funciones que tos que se almacenan en el repositorio CASE.
* llevan a cabo los servicios que Un repositorio CASE robusto proporciona dos cla
se acoplan con el repositorio CASE? ses distintas de servicios: ( 1 ) los mismos tipos de ser
vicios que puede uno esperar de cualquier sistem a de
• integracióndatos-herranzientas:establece un modelo gestiórfde bases de datos sofisticados; y ( 2 ) servicios
de datos al que pueden acceder todas las herram ien que son específicos del entorno CASE.
tas del entorno 1-CASE; controla el acceso a los M uchos requisitos del repositorio son iguales a los
datos, y lleva a cabo las funciones de gestión de con de las aplicaciones típicas que se construyen tomando
figuración adecuadas; com o base un sistema de gestión de bases de datos de
comercial (SGBD). De hecho, m uchos de los reposito
• integración duros-datos: el sistem a de gestión de
rios CASE actuales hacen uso de un SGBD (normal
bases de datos relaciona los objetos de datos de tal
m ente relaciona 1 u orientado a objetos) com o la
m anera que se puedan alcanzar las dem ás fu n cio
tecnología de gestión de datos básica. Entre las carac
nes;
terísticas de un SGBD que dan soporte a la gestión de
• imposición de la metodología: el m odelo E-R de inform ación de desarrollo del software se incluyen las
datos almacenado en el repositorio puede implicar siguientes:
un paradigm a específico de ingeniería del software;
como m ínimo, las relaciones y los objetos definen Almacenamiento de datos no redundante. Cada
un conjunto de pasos que se llevará a cabo para cons objeto es almacenado sólo una vez, aunque es accesi
truir el contenido del repositorio; ble por todas las herram ientas CASE siempre y cuando
estas lo necesiten.
• estandarizaciónde documentos: la definición de obje
tos de la base de datos da lugar directam ente a un Acceso de alto nivel. Se im plem enta un mecanismo
enfoque estándar para la creación de documentos de com ún de acceso a los datos de tal modo que no sea pre
ingeniería del software. ciso duplicar las funciones de gestión de datos en todas
las herramientas CASE.
Para conseguir estas funciones, se define el reposi
torio en función de un m etam odelo. El metamodelo
¿Cuales son las características
§
determ ina la form a en que se almacena la inform ación
típicas de los SGBD que dan
en el repositorio, la forma en que las herram ientas pue
soporte a CASE ?
den acceder a los datos y estos datos pueden ser visua
lizados por los ingenieros de software, el grado hasta el
cual se puede m antener la seguridad e integridad de los Independencia de datos. Las herram ientas CASE y
datos, y la facilidad con que se puede ampliar el m ode las aplicaciones destino se aíslan del almacenamiento
lo ya existente para adm itir nuevas necesidades físico para que no se vean afectadas cuando la configu
[WEL89], ración del hardware se cambie.
El m etam odelo es la plantilla en la cual se sitúa la Controlde transacciones. El repositorio implementa
información de ingenieríadel software. Una descripción bloqueo de registros, admisiones de dos fases, registros
www.FreeLibros.org
detallada de estos modelos va más allá del alcance de este de transacciones y procedim ientos de recuperación para
libro. Para más información, el lector interesado podría m antener la integridad de los datos cuando existen usua
consultar [WEL89], [SHA95] y [GRI95], rios concurrentes.
568
CAPÍTULO 31 IN GENIERÍA DEL SOF TW ARE A SIS TID A P O R C O M P U T A D O R A
In fo rm a c ió n d e la e m p re sa C o n s tru c c ió n
Estructura organizativa Código fuente; código objeto
Análisis del área de n egocios Instrucciones de construcción del sistem a
Funciones de n egocios Im ágenes binarias
Reglas de n egocios Dependencias de configuración
M odelos de procesos (escenarios) Información de cam bios
Arquitectura de la información V a lid a c ió n y v e rific a c ió n
D is e ñ o de a p lic a c io n e s Plan de comprobación; casos de prueba de los
Reglas de m etodología datos
Representaciones gráficas G uiones de com probación de regresión
Diagramas de sistem a Resultados de com probaciones
Estándares de denom inación Análisis estadísticos
Reglas de integridad referenciales Métricas de calidad de softw are
Estructuras de datos In fo rm a c ió n de g e s tió n del p ro y e c to
Definiciones de proceso Planes de proyecto
Definiciones de clase Estructura de d esg lo se de tareas
Arboles de m enú Estimaciones; planificaciones
Criterios de rendimiento Carga de recursos; informe de problem as
Restricciones tem porales Solicitudes de cambios; informes de estado
Definiciones de pantalla Información de auditoría
Definiciones de informes
Definiciones lógicas D o c u m e n ta c ió n del s is te m a
Lógicas de com portam iento D ocum entos de requisitos
Algoritmos D iseños internos/externos
Reglas de transformación M anuales de usuario
T A B L A 31.1. Contenido de un repositorio CASE [FOR89B]
Seguridad. E l re p o s ito rio p ro p o rc io n a m e c a n is m o s Almacenamiento de estructuras de datos sofistica

p a ra c o n tro la r q u ié n p u e d e v is u a liz a r y m o d ific a r la das. E l re p o s ito rio d e b e a d m itir tip o s d e d a to s c o m p le
in fo r m a c ió n c o n te n id a e n él. jo s ta le s c o m o d ia g ra m a s , d o c u m e n to s y a rc h iv o s , a sí
Consultas informes de datos ad hoc.
e E l re p o s ito c o m o s e n c illo s e le m e n to s de datos. U n re p o s ito rio ta m
r io p e r m ite a c c e d e r d ir e c ta m e n te a s u c o n te n id o b ié n in c lu y e u n m o d e lo d e in fo r m a c ió n (o m e ta m o d e lo )
m e d ia n te u n a in te rfa z d e usuario c ó m o d a ta l c o m o S Q L , q ue d e s c rib e la e s tru c tu ra , re la c io n e s y s e m á n tic a d e los
o m e d ia n te u n « n a v e g a d o r» (browser) o rie n ta d o a f o r d atos a lm a c e n a d o s e n él. E l m e ta m o d e lo d e b e rá p o d e r
m u la rio s , h a c ie n d o p o s ib le u n a n á lis is d e fin id o p o r e l a m p lia rs e p a ra d a r c a b id a a re p re s e n ta c io n e s n u e v a s y
u s u a rio que v a m á s a llá d e lo s in fo rm e s e s tá n d a r p r o a u n a in fo r m a c ió n o rg a n iz a tiv a ú n ic as . E l re p o s ito rio
p o rc io n a d o s p o r e l c o n ju n to d e h e rra m ie n ta s C A S E . n o s o la m e n te a lm a c e n a m o d e lo s y d e s c rip c io n e s de los
s istem as e n d e s a rro llo , s in o q u e lo s m e ta m o d e lo s aso
Apertura. L o s re p o s ito rio s s u ele n p ro p o rc io n a r u n
c ia d o s (e s to es, u n a in fo r m a c ió n a d ic io n a l q u e d e sc rib e
m e c a n is m o d e im p o r ta c ió n /e x p o r ta c ió n s e n c illo q u e
la in fo r m a c ió n d e in g e n ie ría d e l s o ftw a re e n sí, ta l c o m o
h ace p o s ib le las carg as o tra n s fe re n c ia s d e in fo r m a c ió n
e l m o m e n to e n q u e se h a c re a d o u n c o m p o n e n te d e
al p o r m a y o r.
d is e ñ o c o n c re to , su e s ta d o a c tu a l y la lis ta d e c o m p o
Soportemultiusuario. U n re p o s ito rio ro b u s to d e b e rá
n e n te s d e lo s c u ale s d e p e n d e ).
p e r m itir que m ú ltip le s d e s a rro lla d o re s tra b a je n e n u n a
a p lic a c ió n a l m is m o tie m p o . D e b e rá g e s tio n a r e l acceso
§
¿Cuáles son las características
c o n c u rre n te a l a b a s e d e d a to s m e d ia n te m ú lt ip le s especiales mostradas en el
h e rra m ie n ta s y p o r p a rte d e m ú ltip le s u s u a r io s , c o n repositorio CASE?
a rb itra je d e accesos y c o n b lo q u e o s e n e l n iv e l de a rc h i
vos o re g istro s. P a ra lo s e n to rn o s b a s a d o s e n re d e s , e l Imposición de una integridad. E l m o d e lo d e i n f o r
so p o rte m u ltiu s u a rio im p lic a ta m b ié n q u e e l re p o s ito m a c ió n d e l re p o s ito rio c o n tie n e ta m b ié n re g la s , o p o lí
r io se p o d rá c o m u n ic a r m e d ia n te in te r fa z c o n p ro to tic a s , q u e d e s c rib e n re g la s d e n e g o c io s v á lid a s y otras
c o lo s (a g e n te s d e s o lic itu d d e o b je to s ) y s e rv ic io s re s tric c io n e s y re q u is ito s a c e rc a d e la in fo r m a c ió n que
c o m u n e s d e red. se in s e rta e n e l re p o s ito rio (d ire c ta m e n te o a tra v é s de
E l e n to rn o C A S E ta m b ié n e fe c tú a d e m a n d a s espe u n a h e rra m ie n ta C A S E ) . E s p o s ib le e m p le a r u n s e rv i
c ia le s c o n re s p e c to a l re p o s ito rio que v a n m á s a llá d e c io lla m a d o disparador p a ra a c tiv a r las re g la s a s o c ia
www.FreeLibros.org
lo que está d is p o n ib le d ire c ta m e n te e n u n S G B D c o m e r das a u n o b je to s ie m p re que este sea m o d ific a d o , lo c u a l
c ia l. E n tre las c a ra c te rís tic a s e s p e cia le s d e lo s re p o s i hace p o s ib le v e rific a r la v a lid e z de los m o d e lo s de diseño
to rio s C A S E se in c lu y e n las s ig u ie n te s : e n tie m p o re a l.
569
INGE NIE RIA DEL S OFT W ARE . UN EN F O Q U E P R Á C T I C O
El repositorio C A S E d eb erá ser capaz de controlar

una am plia variedad de tipos de objetos entre los que se
Referencia in clu y en te x to , g rá fic o s, m a p a s de b its, docu m en to s
com plejos y objetos Únicos co m o definiciones de pan
Un manual de aprendizaje detallado y una lista de
talla y de inform es, archivos de objetos, datos de com
recursos para repositorios 0 0 (que se pueden utilizar para
probación y resultados. U n repositorio m aduro rastrea
entornos CASE) * pueden encontrar en la dirección
las versiones de objetos con niveles arbitrarios de gra-
mini.net/cetus/oo_db_systems_I .html
nularidad, p o r ejem plo, se puede rastrear ca d a defini
ción de datos o agrupam iento de m ódulos.
Interfaz de herramientas ricas en términos semánti
cos. El m odelo de inform ación del repositorio (el m eta- P ara dar apoyo al desarrollo paralelo, el m ecanism o
m odelo) contiene u n a sem ántica que hace posible que de control de versiones deberá perm itir m últiples deri
to d a u n a gam a de herram ientas interp reten el signifi vados (variantes) a partir de un solo predecesor. A sí pues,
cad o de los d ato s alm acen ad o s en el rep o sito rio . Por un desanollador podrá estar trabajando al m ism o tiempo,
ejem plo, un diag ram a de flujo de datos creado m ediante en dos soluciones posibles para un problem a de diseño
una h erram ien ta C A SE se alm acena en el repositorio en generadas las dos desde el punto de partida.
un fo rm u lario b asado en el m odelo de in fo rm a ció n e Seguimiento de dependenciasy gestión de cambios.
independiente de to d a rep resen tació n in tern a que pueda El repositorio gestiona una am plia variedad de relacio
utilizar la h erram ientas en sí. E ntonces o tra herram ienta n es e n tre lo s e le m e n to s de d a to s a lm a c e n ad o s en él.
C A SE puede interp retar el contenido del repositorio y E ntre estas se cuentan las relaciones entre entidades y
u tilizar la inform ación cuando la necesite p ara su tarea. procesos de la em presa, entre las partes de un diseño de
D e este m odo, la sem ántica alm acenada en un rep o si aplicación, entre com ponentes del diseñ o y la arquitec
torio p erm ite com partir datos entre u n a gran v ariedad tu ra de la inform ación de la em p resa, entre elem entos
de h erram ientas, a diferencia de las conversiones e sp e de diseñ o y p ro d u cto s, etc. A lg u n as de las relaciones
cíficas entre h erram ientas, o entre «puentes». son m eram ente asociaciones, y algunas son d ependen
Gestión deprocesosiproyectos. U n repositorio co n cias o relaciones obligatorias. El m antenim iento de estas
tien e in fo rm a c ió n n o só lo acerca de la ap lic a c ió n de relaciones entre objetos de desarrollo se denom ina admi
softw are en s í, sino tam b ién acerca de las característi nistración de enlaces.
cas de cada p royecto en particular, y del p roceso g en e
ral de la o rganización p ara el d esarro llo del softw are
(fases, tareas y productos). E sto abre p o sibilidades para
la coordinación autom atizada de la actividad de d esa
Lo capacidad del repositorio para hacer seguimiento
rrollo técnico con la actividad de gestión del proyecto.
délas relaciones entre objetos de la configuración
P or ejem plo, la actualización del estado de las tareas de
es una de I b característicosmás importantes. Eimpacto
proyectos se p o d ría efectuar de form a autom ática o bien
del cambio se puede rastrear si se dispone
com o un p roducto derivado de la u tilizació n de h e rra de esto característica.
m ientas CASE. L a actualización de estado resultará m uy
fácil p ara los desarrolladores, sin ten er que abandonar La capacidad'de se g u irla pista de todas estas relacio
el entorno de desarrollo norm al. L a asignación de tareas nes es crucial para la integridad de la inform ación alm a
y consultas tam b ién se puede g estionar p o r correo elec cenada en el repositorio y para la generación de productos
trónico. L o s inform es de p roblem as, las tareas de m an basados en ella, y es una de las contribucionesm ás impor
tenim iento, las autorizaciones de cam bios, y lo s estados tantes que efectúa el concepto de repositorio para la m ejo
de re p a ra ció n se p u e d e n c o o rd in a r y m o n ito riz a r ra del proceso de desarrollo del software. Entre las muchas
m ediante herram ientas que acceden al repositorio. funciones que apoya la gestión de enlaces se cuenta la
Las siguientes características del repositorio son abar capacidad de identificar y estim ar los efectos del cambio.
cadas todas ellas p o r la gestión de configuración del soft A m ed id a que los diseñ o s evolucionan para satisfacer
w are (C apítulo9). Se vuelven a exam inar aquí p ara hacer nuevos requisitos, la capacidad de identificar todos los
hincapié en su interrelación con los entornos 1-CASE. objetos que podrían verse afectados hace posible una esti
Versiones.A m ed id a que avanza un proyecto, se irán m ación m ás p recisa del coste, del tiem po no operativo,
creando m uchas v ersiones de p roductos in d iv iduales. y del grado de dificultad. Tam bién se ayuda a evitar e fec
El repositorio d eberá ser capaz de guard ar todas estas tos colaterales que en caso contrario darían lugar a defec
versiones p ara hacer posible una gestión efectiv a de las tos y a fallos del sistema.
versiones de los p roductos y p ara p erm itir que los desa- L a gestión de enlaces ayuda al m ecanism o de repo
rrolladores vuelv an a las versiones anteriores durante sitorio para asegurar que la inform ación del diseño sea
la co m probación y depuración. c o rre c ta m a n te n ie n d o sin cro n izad as las p artes de un
www.FreeLibros.org
diseño.
m k ¿De qué forma presta ayuda Por ejem plo, si se m odifica un diagram a de flujo de
W el repositorioa la GCS? datos, el repositorio puede detectar s i los diccionarios
570
C A P Í T U L O 31 INGE NIE RI A DEL S O F T W A R E A SIS TID A P O R C O M P U T A D O R A
de datos relacionados, definiciones de p antallas y m ódu de u n a serie de configuraciones que representarán h ito s
los de códigos tam b ién req u ieren m odificación y p u e específicos del proyecto o de versiones de producción.
dan llam ar la atención del desarrollador los com ponentes L a gestión de versiones p roporciona las versiones n e ce
afectados. sarias, y la gestión de enlaces hace seguim iento de las
S eg u im ie n to d e req u isito s. E sta fu n c ió n esp e c ia l interdependencias.
depende de la g estión de enlaces y p ro p o rciona la cap a Seguim ientode auditoría. El seguim iento de auditoría
cid ad de h ac e r s e g u im ie n to de los c o m p o n e n te s de establece inform ación extra acerca de cuándo, por qué, y
d iseñ o y de los p ro d u cto s d eriv ad o s que proceden de p o r quién son efectuados los cam bios. L a inform ación
u n a esp ecificaciónde requisitos específica (seguim iento acerca de las fuentes de las modificaciones se pueden intro
p rog resiv o ).A d em ás, p ro p o rcio n a la capacidad de id en ducir en form a de atributosde objetos específicos del repo
tificar cuáles son los requisitos que generaron cualquier sitorio. Un m ecanism o disparador del repositorio resultará
p roducto derivado (seguim iento regresivo). útil para solicitar al desarrollador o a la herram ienta que
G estión de configuración. U n a función de gestión de esté utilizando que inicie la introducción de inform ación
co nfiguración que trab aja m uy c e rc a de las fun cio n es de auditoría.(tal com o la razón del cam bio) siem pre que
de versiones y gestión de enlaces p ara hacer seguim iento se m odifique un elem ento de diseño.
J L E S n M E J S ________________________________ __
Las herram ientas de ingeniería del softw are asistida por p o r parte de fabricantes que trabajan a la v ez, o b ien se
com pu tad o ra abarcan todas las actividades del proceso puede lograr m ed ian te un softw are d e g estió n que se
del softw are y tam b ién aquellas actividades generales proporcione com o parte del repositorio.
que se aplican a lo largo de todo el proceso. C A SE co m L a integración entre hom bre y com putadora se logra
b in a u n c o n ju n to de b lo q u es de c o n s tru c c ió n que m ediante estándares de interfaz que se están vo lv ien d o
co m ienzan en el nivel del h ardw are y del softw are de ca d a vez m ás com u n es a lo largo y a n ch o d e to d a la
sistem a operativo y finalizan en las herram ientas in d i industria. Para fa c ilita r la in teg ra ció n d e los usuarios
viduales. con las h erram ien tas,d e las herram ientas entre sí, de las
E n este capítulo se h a tenido en co nsideración una herram ientas con los datos y de los datos con otros datos
tax o n o m ía de herram ientas CA SE. L as categorías abar se diseña una arquitectura de integración.
can tanto las actividades de gestión co m o las técnicas, Se h a aludido al repositorio C A S E con el nom bre de
e in cluyen la m ay o r parte de las áreas de aplicación del «bus de softw are». L a inform ación p asa p o r él, y v a cir
softw are. T odas las categorías de herram ientas se han cu lan d o de herram ienta en h e rram ien ta a m e d id a que
considerado « soluciones puntuales». progresa el proceso de softw are. P ero el repositorio es
El e n to rn o 1-CA SE co m b in a m ec a n ism o s de in te m ucho m ás que un «bus». T am bién se trata de un lugar
gración p ara datos, herram ientas e interacción hom brede alm acenam iento que co m b in a sofisticados m ecan is
com putadora. L a integración de datos se puede conseguir m os para integrar herram ientas C A SE m e jo ran d o con-
m ediante el intercam bio directo de inform ación, m edian siguientem enteel proceso m ediante el cual se desarrolla
te estructuras de archivos com unes, m ediante datos co m el softw are. El repositorio es una base de datos relacio-
partidos o interoperabilidad, o a través de la utilización nal u orientada a objetos que es «el centro de acu m u la
de u n repositorio 1-CASE com pleto. L a integración de ción y alm acenam iento»de la inform ación de ingeniería
herram ientas se puede d iseñar de fo rm a p ersonalizada del softw are.
B 2 E t» . . i » . b C l A S ,
[FOR89a] Forte, G., «In Search of the Integrated Environ- [QED89] CASE: The Pot.ent.ial and the JÜtfálls, QED Infor
ment», CASE Outlook, Marzo/Abril de 1989,pp. 5-12. mation Sciences, Inc., Wellsley, MA, 1989,
[FOR89b] Forte, G., «Rally Round the Repository», CASE [SHA95] Sharon, D., y R. Bell, «Tools that Bind: Creating
Outlook, Diciembre de 1989,pp. 5-27. IntegratedEnvironments», IEEE Software, Marzo de 1995,
[FOR90] Forte, G., «Integrated CASE: ADefinition», Proc. pp. 76-85.
3 rdA m m al TEM IW O RKERS Intl. User's Group Confe-
rence, C adre Technologies, Providence, IR, Marzo de 1990. [SQE95] Testing Tools Reference Guide, Software Quality
Engineering, Jacksonville, FL, 1995.
www.FreeLibros.org
[GRI95] Griffen,J., «Repositories: Data Dictionary Descen-
dant Can Extend Legacy Code Investment», Application [WEL89] Welke, R.J. «M eta Systems on M eta Models»,
Development Trends, Abril de 1995, pp. 65-71. CASE Outlook, Diciembre de 1989,pp. 35-45.
571
IN GENIERÍA DEL S O F TW A RE . UN EN F O Q U E P R Á C T I C O
31.1. Haga una lista de todas las herramientas de desarrollo 31.6. ¿Existen situaciones en las cuales las herramientas de
de software que utilice. Organícelas de acuerdo con la taxo com probación dinám icas sean «la Única forma posible»? De
nomía presentada en este capítulo. ser así, ¿cuáles son?
31.2. Empleando las ideas introducidas en los Capítulos 14y 31.7. Describa otras actividades humanas en las cuales la inte
16,¿cómo cree usted que deberían de construirse los servicios gración de un conjunto de herramientas haya proporcionado
de portabilidad? un mayor beneficio que la utilización de cada una de esas herra
mientas de forma individual. N o utilice ejem plos de com pu
31.3. Construye un prototipo en papel para una herramienta
tación.
de gestión de proyectos que abarque las categorías indicadas
en la Sección 31.3. Utilice la Segunda Parte de este libro para 31.8. Describa lo que quiere decir la integración entre herra
obtener información adicional. m ientas y datos con sus propias palabras.
31.4. Lleve a cabo una investigación acerca de los sistema de 31.9. En diferentes lugares de este capítulo se utilizan los tér
gestión de bases de datos orientados a objetos. Estudie por qué minos m etam odelos y metadatos. Describa lo que significan
un SGBDOO sería ideal para herramientas GCS. estos términos em pleando sus propias palabras.
31.5. Recoja la inform ación de productos de al m enos tres 31.10.¿Se le ocurre algún elem ento de configuración adicio
herramientas CASE en una categona especificada por su pro nal que pudiera incluirse entre los elem entos del repositorio
fesor. Desarrolle una matriz que com pare las características. m ostrados en la Tabla 31.1? Haga una lista.
En los años ochenta y principios de los noventa se publica entornos de desarrollo de software. M uller y sus colaborado
ron varios libros sobre CASE en un esfuerzo de sacar provecho res (Com puterAided Software Engineering, Kluwer Academic
del alto grado de interés de la industria en ese momento. Entre Publishers, 1996) han editado una colección de descripciones
las primeras ofertas que todavía disfrutan de valor se encuentran: de investigación CASE a mediados de los noventa. La mejo
res fuentes de información actual sobre herramientas CASE se
Bergin, T. et al., Com puter-Aided Software Engineering:
encuentran en Internet, en publicaciones técnicas periódicas y
Issu es and T ren d sfo r the 1990s a nd B eyond, Idea G roup
en boletines informativos de industria.
Publishing, 1993.
El estándar 1209 IEEE (Evaluation and Selection ofC A SE
Braithwaite, K.S., A pplication D evelopm ent Using CA SE
T ools)presenta un conjunto de líneas generales para evaluar
Tools, Academic Press, 1990.
las herram ientas CASE para los «procesos de gestión de pro
Brown, A. W., D.J. Carney y E.J. M orris, P rincipies o j
yectos, procesos de predesarrollo, procesos de desarrollo, pro
CASE Toollntegration, O xford U niversity Press, 1994.
cesos de postdesarrollo y procesos integrales». Un informe
Clegg, D., y R. Barker, C A SE M ethod Fast-Track: A RAD
detallado de W allnau y F eiler (T o o lln teg ra tio n and Envi-
Approach, Addison Wesley, 1994.
ronm ent A rchitectures, Softw are E ngineering Instituto,
Lew is, T.G., C om puter-Aided Software Engineering, Van
CM U/SEI-9 1 -T R -ll, M ayo de 1991), aunque esté fechado,
Nostrand-Reinhold, 1990.
sigue siendo uno de los m ejores tratam ientos sobre entornos
My lis, R ., Inform ation Engineering; C A SE P ractices and
CASE fácilm ente disponibles.
Techniques, Wiley, 1993.
Una am plia v ariedad de fuentes de inform ación sobre
En la antología de Chifofsky (Com puter-Aided Software CA SE está disponible en Internet. Una amplia lista actuali
Engineering, IEEE Computer Society, 2.a Ed., 1992) se encuen zada de referencias a sitios (páginas) w eb se puede obtener
tra una colección útil de los primeros trabajos sobre CASE y en http :/www.pressman5.com.
CAPÍTULO
32 P E R S P E C T IV A S F U T U R A S
N los 3 1 capítulos anteriores, se h a ido explorando un proceso de ingeniería del softw a
E re. Se h an presentado procedim ientos de gestión y m étodos técnicos, principios básicos

y técnicas especializadas, actividades orientadas a personas y tareas adecuadas para su
autom atización, n o tación de papel y lápiz y herram ientas CASE. Se h a afirm ado que la m ed i
da, la disciplina y un especial interés p o r la calidad darán lugar a un softw are que v a a satisfa
cer las n ecesidades del usuario, a un softw are fiable, a un softw are m antenible y a un softw are
m ejor. Y, sin em bargo, n u nca se h a prom etido que la ingeniería del softw are fu e ra la panacea.
A m ed id a que v am os avanzando h acia el com ienzo de un nuevo siglo, la tecn ología de soft
w are y de sistem as siguen siendo un desafío para todo profesional del softw are y para to d a c o m
p añía que construya sistem as basados en com putadoras. A unque esto se escribió hace m ás de
una década, M ax H opper [H O P90] describe el estad o actual de los acontecim ientos:
D ado que los cam bios de la tec n o lo g ía de la inform ación cada vez se producen m ás ráp id am en te y son
im p lacab les, y d ad o que las con secu en cias de quedarse atrás son irrev e rsib le s, las com pañías tienen que
d om in ar esta tecnología o m orir. H ay que pensar que se trata del m olino de la tecnología. L as com pañías
tendrán que co rre r cada vez m ás d eprisa para estar a la a ltu ra.
Los cam bios de la tecnología de la ingeniería del softw are son, en efecto, «ráp id o s e im pla
cab les» , pero al m ism o tiem po el progreso suele ser bastante lento. Pero una vez que se tom a
la decisión de adaptar un m étodo nuevo (o u n a herram ienta nueva), la decisión de llevar a cabo
la form ación n ecesaria para com prender su aplicación, y la decisión de introducir la tecnología
en la cultura de desarrollo del softw are, y a h a surgido algo nuevo (e incluso m ejor) y co m ien
za de nuevo el proceso.
VI STAZO RÁPI DO
¿Qné es? El futuro n u n c a e s fácil d e p re ¿por q u é la s g ra n d e s e m p re sa s m ulti ¿C uál e s e l p r o d u c to o b te n id o ?

decir: los e n te n d id o s y e x p e rto s d e la nacionales co n tratan a o tra s e m p re sa s U n a v is ió n d e l té rm in o fu tu ro q u e
in d u stria no se resisten. El futuro e s ta a s e s o r a s y a g ra n d e s p e n sa d o re s p a ru p u e d a o no se r corre c ta .
b a p la g a d o d e c a rc a s a s d e tecnologí p re p a ra r los pronósticos?, ¿por q u é un ¿Cómo p u e d o e s ta r se g u r o d e q u e
a s n u e v as y e x c ita n te s que realm ente g ra n p orcentaje d e lectores e s tá n p e n lo h e h e c h o c o r r e c t a m e n t e ?
n u n c a lle g a ro n a se r e so ( a p e s a r del d ie n te s d e lo s horóscopos? Q u e rem o s P re d e c ir e l fu tu ro e s u n a r te , no u n a
bom bo q u e tu v iero n ), y q u e a d q u irie s a b e r lo q u e v a a o c u rrir p a r a e s ta r c ie n c ia . D e hecho, e s b a s ta n te e x tr a
ron form a con tec n o lo g ía s más m oder p re p ara d o s. ñ o c u a n d o s e h a h e c h o u n a p r e d ic
n a s que de a lg u n a m anera m odificaron ¿C uáles son lo s p a so s? No h a y u n a c ió n s e r i a , q u e é s t a s e a a b s o l u
su d irecció n y e x te n sió n . Por lo ta n to fó rm u la p a r a p r e d e c ir e l fu tu ro . Lo ta m e n te v e r d a d e r a o in e q u ív o c a
no preten d em o s p red ecir el futuro sino h e m o s in te n ta d o re c o g ie n d o d a to s y m e n te e r r ó n e a (c o n la e x c e p c ió n ,
qu e e stu d ia re m o s a lg u n o s te m a s que o r g a n iz á n d o lo s c o n el fin d e p ro p o r a f o r t u n a d a m e n te ,d e l a s p re d ic c io
hay que ten e r e n c u e n ta p a ra en ten d er c io n a r u n a in fo rm a c ió n ú til; e x a m i n e s s o b re e l fin d e l m u ndo). S e b u s
los cam bios futuros d e l a in g en ie ría del n a n d o l a s a s o c ia c io n e s s u tile s p a r a c a n te n d e n c i a s y s e i n te n t a e x t r a
softw are y del m ism o software. e x tr a e r el c o n o c im ie n to y, a p a rtir d e p o la rla s a l futuro. S o la m e n te se p u e
¿Quién lo h a ce? Todos. é s te , s u g e r ir p o s i b l e s a p a r i c i o n e s d e e v a l u a r la c o rre c c ió n d e e s t a
¿Por q u é e s importante?¿Por q u é los q u e p re d e c irá n cóm o s e r á to d o e n el e x tra p o la c ió n a m e d id a q u e p a s a el
reyes a n tig u o s c o n tra ta b a n adivinos?, futuro. tiem p o .
E n este capítulo se exam inan las tendencias futuras. N uestro intento no es explorar todas las
áreas de investigación que resulten prom etedoras. T am poco lo es m irar en una «bola de c ris
www.FreeLibros.org
tal» y p ro n o sticar el futuro, m ás bien se intentará explorar el ám bito del cam bio y la form a en
que el cam bio en sí va a afectar al proceso del softw are en los años venideros.
573
IN GE NI E RÍ A DEL S OFT W ARE . UN E N F O Q U E P R A C T I C O
Ü H H U l . ; '. - / . . . . ...i.
L a im po rtan cia del softw are de com pu tad o ra se puede de una corporación. El software es crucial para casi todos los
enunciar de m uchas form as. E n el C apítulo 1, el so ft aspectos del negocio. Pero de muchas maneras, el software es
también una tecnología oculta. Encontramos el software (fre
w are se caracterizaba com o diferenciador. L a función
cuentemente, sin darnos cuenta) cuando nos desplazamos has
prop o rcio n ad a p o r el softw are es lo que diferen cia a los ta nuestro trabajo, cuando efectuamos cualquier compra, cuando
productos, sistem as y servicios, y p ro p o rcio n a u n a v e n nos detenemos en el banco, cuando hacemos una llamada tele
taja com p etitiv a en el m ercado. S in e m b a rg o , el soft fónica, cuando visitamos al médico o cuando realizamoscual-
w are es m ás que u n d iferen ciad o r. L o s p ro g ra m a s, quiera de los cientos de actividades diarias que reflejan la vida
docum entos y d ato s que constituyen el softw are ayu moderna.
dan a g en erar la m ercan cía m ás im portante que pueda El software está en todas partes y, sin embargo, hay muchas
adquirir cualq u ier individuo, negocio o gobierno — la personas en puestos de responsabilidad que tienen poca o nin
guna comprensión de lo que realmente es, como se construye,
inform ación— . P re ssm a n y H errón [PRE91] describen
o de lo que significa para las institucionesque lo controlan (y a
el softw are de la fo rm a siguiente: las que controla). Y, lo que es más importante, tienen muy poca
El software de computadora es una de las pocas tecnologí idea de los peligros y oportunidades que este software ofrece.
as clave que tendrán un impacto significativo en los años 90. L a om nipresencia del softw are nos lleva a u n a con
Se trata de un mecanismo para automatizar negocios, indus clu sió n sencilla: siem pre que u n a te cn o lo g ía tiene un
trias y gobiernos, un medio para transferir nuevas tecnologías,
im pacto am plio —un im pacto que puede salvar vidas o
un método para adquirir experiencia valiosa que otras perso
nas puedan utilizar, un medio para diferenciar los productos de p o n e rla s en p e lig ro , co n stru ir n e g o cio s o destru irlo s,
una compañía de los productos de los de sus competidores, y in form ar a los je fe s de go b iern o o c o n f u n d ir lo s - , es
una ventana que permite examinar el conocimiento colectivo p reciso «m anejarla con cuidado».
. . .. " , J2„ . - uM .L O
L os cam bios en la info rm ática durante los últim os 50 E s posible que la influencia de las ciencias no ex p e
años han sido controlados p o r los avances en las « c ie n rim entales ayude a m o ldear la dirección de la investi
cias experim entales duras» — fisicoquím ica, cien cia de gación inform ática en las ciencias experim entales. Por
m ateriales e ingeniería— . D urante las p róxim as d éca ejem plo, el diseño del las «com putadoras futuras» p u e
das, lo s avances revolucionarios en la info rm ática serán de que sea dirigido m ás p o r un entendim iento de la p si
dirigidos p o r las c ie n c i a s n o experim entales suaves» c o lo g ía del c e re b ro que p o r el e n te n d im ie n to de la
- p s ic o lo g ía h u m a n a , b iología, n eu rofisiología, socio m icroelectrónica convencional.
logía, filosofía y otras— . El período de g estación de las L os cam bios que afectarán a la ingeniería del soft
tecnologías inform áticas que se puede d eriv ar de estas w are du ran te la próxim a d éc ad a se verán influenciados
disciplinas es m u y difícil de predecir. p o r cuatro fuentes sim ultáneas: (1) las personas que re a
lizan el trabajo; (2) el proceso que aplican; (3) la n atu
raleza de la inform ación, y (4) la tecnología inform ática
Q p ík H subyacente. E n las secciones sig u ientes, ca d a uno de
!¡6j8Í»ttóh¡iufo es que cada vez llego un día nuevo. estos com ponentes — personas,proceso, inform ación y
t e c n o l o g í a - se estudiarán detalladam ente.
2 2 .3 y la f o r m a en q o e c o n s t r u y e n sis t e m a s
El softw are necesario p ara los sistem as de alta tecnología w are, es posible que la productividad global del grupo
cada vez son m ás difíciles a m edida que van pasando los sufra. U n m étodo para resolver este problem a es crear
años y el tam año de los program as resultantes increm en un núm ero de equipos de ingeniería del softw are, por
ta de m anera proporcional. El crecim iento rápido del tam a el que se com partim entalicen las personas en grupos de
ño del program a «prom edio»nos presentará unos cuantos tra b a jo in d iv id u a le s. Sin e m b arg o , a m e d id a que el
problem as si no fuera por el sim ple hecho de que: a m edi núm ero de equipos de ingeniería del softw are aum en
da que el program a aum enta, el núm ero de personas que ta, la com unicación entre ellos es tan difícil y larga com o
www.FreeLibros.org
deben trabajar en él tam bién aumenta. la com unicación entre individuos. Es aún peor, la com u
L a exp erien cia in d ica que a m ed id a que aum enta el n ic ació n (e n tre in d iv id u o s o e q u ip o s) — es decir, es
núm ero de personas de un equipo de proyecto de soft dem asiado tiem po el que se pasa transfiriendo poco con
574
CAPÍTULO 32 P E R S P E C T I V A S FU T UR A S
tenido de inform ación, y to d a esta inform ación im p o r (o en continentes diferentes) se « en c u e n tre n » regular
tante suele «perderse entre las grietas»— . m ente. Pero el vídeo tam bién p ro p o rc io n a otra ventaja:
Si la com unidad de ingeniería del softw are va a tra se puede utilizar com o dep ó sito p ara conocim iento sobre
ta r el dilem a de la com unicación de m anera eficaz, el el softw are y para los recién lleg ad o s a un proyecto.
futuro de los ingenieros deberá ex perim entar cam bios L a ev o lu ció n de los a g e n tes in te lig e n te s ta m b ié n
radicales en la fo rm a en q ue los individuos y los equi cam b iará los patrones de tra b ajo de un in g e n ie ro del
pos se co m u n ic a n en tre sí. E l co rreo electró n ico , los softw are am pliando dram áticam ente las h e rram ien tas
tablones de anuncios y los sistem as de v ideoconferen del software. Los agentes in telig entesm ejorarán la h ab i
cia son los lugares com unes com o m ecan ism os de co n e lidad de los ingenieros m ed ian te la c o m p ro b a c ió n de
xión entre m u ch as perso n as de u na red de inform ación. los p ro d u cto s del tra b ajo u tilizan d o el c o n o c im ie n to
L a im portancia de estas herram ientas en el contexto del específico del dom inio, realizando ta rea s ad m in istra ti
trabajo de la ingeniería del softw are n o se puede sobre- vas, llevando a cabo una investigación d irig id a y c o o r
valorar. C on un sistem a de correo electrónico o de tablón dinando la com unicación entre personas.
de an u n cio s e fic a z , el p ro b le m a q u e se en cu e n tra un Finalm ente, la adquisiciónde conocim iento está cam
ingeniero del softw are en la ciudad de N ueva York, se biando profundamente. E n Intem et, un ingeniero del soft
puede reso lv er con la ayuda d e un com pañero en Tokio. w are puede subscribirse a un grupo de noticias centrado
E n realidad, los tablones de anuncios y los grupos de en áreas de tecnología de inm ediata preocupación. U na
n oticias especializados se convierten en los d ep ó sito s p regunta e n v iad a a un g rupo de n o ticias p ro v o c a r e s
de conocim iento q ue perm iten reco g er un conocim ien puestas de otras partes interesadasdesde cualquier lugar
to colectivo de un grupo grande de técn icos p ara resol del globo. L a W orld W ide W eb proporciona a l ingenie
v e r un pro b lem a técnico o un asunto de gestión. r o del softw are la b iblioteca m ás grande del m u n d o de
trabajos e inform es de investigación,m anuales, com en
tarios y referencias de la ingeniería del softw are'.
0 tHoque futuro es el trem endo agobio Si la h istoria pasad a se puede considerar un indicio,
f k r desorientación que inducimos en los individuos es ju s to decir que las m ism as personas no v an a c a m
s o ip é n d o lo s o dem asiados cambios en períodos biar. S in em bargo, las form as en que se co m unican, el
m uy coitos de tiem po. en torno en el que trabajan, la form a en que adq u ieren
el conocim iento, los m étodos y herram ientas que u tili
zan, la d iscip lin a que aplican, y p o r ta n to , la c u ltu ra
El vídeo perso n aliza la com unicación. Y lo m ejor es general del desarrollo del softw are sí c am b iarán sig n i
que hace p osible que com pañeros en lugares diferentes ficativa y profundam ente.
32.4 EL «NUEVO» PR O C ESO DE INGENIERÍA DEL S Q F T W A fife v a ; a ¿
E s razonable caracterizar las dos p rim eras décadas de del m arco de tiem po asignado. L o s m odelo s evolutivos
la práctica de ingeniería del softw are com o la era del hacen h incapié en la necesidad de productos d e trabajo
«pensam ientolineal». Im p u lsad o p o r el m odelo de ciclo increm entales, análisis de riesgos, planificación y revisión
vital clásico, la ingeniería del softw are se h a enfocado de planes, y realim entación que provenga del cliente.
com o una actividad en la cual se podían aplicar una serie
de pasos secuenciales en un esfuerzo p o r resolver p ro
b lem as com plejos. S in em bargo, los enfoques lineales iQ cüio:
del desarrollo del softw are v an en co n tra de la form a en t a e j o i preparación de buen trabajo paro m oñona
que se c o nstruyen realm ente la m ay o ría de los sistem as. es bees? u d í m r trabajo hoy.
E n realidad, los sistem as com plejos ev olucionan de fo r r|lHitiM&ará
m a iterativa, e incluso increm ental. P o r esta razón, un
gran segm ento de la com unidad de la in g eniería del soft ¿Q ué actividades deberán de p oblar el p ro ceso e v o
w are se está desplazando h acia m odelos evolutivos para lu tiv o ? A lo largo d e la d éc ad a pasad a, el M o d e lo de
el desarrollo del softw are. m a d u re z de c a p a c id a d d e sa rro lla d o p o r el S o ftw are
L os m odelos de proceso evolutivos reconocen que la E ngineering Institute (SEI) [PAU93] ha tenido u n im pac
incertidumbre dom ina la m ayoría de los proyectos; que las to apreciable sobre los esfuerzos p o r m ejorar las p rá c
líneas tem porales suelen ser im posibles y cortas; y que la ticas de ingeniería del softw are. El M M C h a dado lugar
iteración proporciona la habilidad de dar una soluciónpar- a m uchos debates (por ejem plo, [B O L91] y [G IL 96]),
cial, aunque un producto com pleto no es posible dentro y sin em bargo p roporciona un a bu en a indicación de los
www.FreeLibros.org
1El sitio W eb SEPA puede proporcionar enlaces electrónicos con las
m aterias m ás im portantes que se p resentan en este libro.
575
atributos que d eben existir cuando se pone en práctica El crecim iento rápido de las aplicaciones basadas en
una b u en a ingeniería del softw are. W eb (W ebA pps) está cam biando tanto en el proceso de
L as tecnologías de objetos, ju n to con la ingeniería del la ingeniería del softw are com o en sus participantes. De
softw are (Capítulo 27) son un brote de la tendencia hacia nuevo, nos encontram os con un paradigm a increm en-
los m odelos de p roceso evolutivos. A m bos ten d rán un tal y evolutivo. Pero en el caso de las W ebApps, la inm e
im pacto profundo sobre la productividad de desarrollo del diatez, seguridad y estética se están convirtiendo en las
softw are y sobre la calidad del producto. L a reutilización p re o cu p a cio n es d om inantes. U n eq uipo de ingeniería
de com ponentes proporciona beneficios inm ediatosy con de W eb m ezcla técnicos con especialistas de contenido
vincentes. Cuando la reutilización se une a las herramientas (por ejem plo, artistas, m úsicos, videógrafos) para co n s
C A SE p ara los prototipos de u n a aplicación, los in cre tru ir una fuente de inform ación para una com unidad de
m entos del program a se pueden construir m ucho m ás rápi usuarios grande e im predecible. El softw are que h a sur
dam ente que m ediante la u tilización de enfoques gido del trabajo de la ingeniería de W eb ya ha dado com o
convencionales. L a construcción de prototipos arrastran resultado un cam bio radical tanto económ ico com o c u l
al cliente al proceso. Por tanto es probable que clientes y tural. A unque los conceptos y principios básicos trata
usuarios se im pliquen m ás en el desarrollo del software. dos en este libro son invariables,el proceso de ingeniería
E sto, a su vez, puede llevar a una satisfacción m ayor del del softw are deberá adaptarse para llegar a acoplarse a
usuario final y a una calidad m ejor del softw are global. la W eb.
A lo largo de las dos ú ltim as décadas, se h a producido

una sutil transición en la term inología que se utiliza para
describ ir el trabajo de desarrollo de softw are realizado
para la com unidad de negocios. H ace trein ta años, el datos: Información:
No hay asociatividad Asociatividad en un
térm ino p ro c e sa m ie n to de datos era la frase operativa
solo contexto
para describ ir la utilización de com putadoras en un co n
texto de negocio. E n la actualidad, el p roceso de datos
h a dado lugar a o tra frase — tecnología de la in fo rm a
ció n — que sig n ific a lo m ism o pero p re se n ta un sutil
cam bio de nuestro centro de atención. L a im portancia
y a no está m eram ente en p ro cesar grandes cantidades
Conocimiento: Sabiduría:
de datos, sino m ás bien en extraer una inform ación sig Asociatividad Creación de principios
nificativ a a p artir de esto s datos. E videntem ente, éste entre contextos generalizados basándose
ha sido siem pre el o b jetiv o , pero el cam b io de la te r múltiples en el conocimiento
procedente de distintas fuentes
m in o lo g ía refleja un cam bio b astante m ás im portante
en la filosofía de la gestión.
C uando en la actualidad se d escriben las aplicacio F IG U R A 3 2 . 1 . Un espectro de «información».
nes de softw are, las p alabras dato s e inform ación apa
recen en num erosas ocasiones. L a palabra conocim iento cuatro puntos de v ista de la «inform ación» se han re p re
se en cu en traen algunas aplicaciones de inteligencia arti sentado esquem áticam ente en la F igura 32.1.
ficial, pero su u tilizació n es relativam ente escasa. Casi H asta la fecha, la gran m ayoría del softw are que se
nadie describe la sabiduría en el contexto de las aplica h a construido h a tenido com o m isión p rocesar datos o
ciones del softw are p ara com putadoras. inform ación. L o s ingenieros de softw are del siglo vein
Los d ato s son inform ación p u ra — una co lección de tiu n o seg u irán esta n d o p reo cu p ad o s p o r sistem as que
hechos que es preciso p ro cesar p ara que sean significa procesen conocim iento". El conocim iento es bidim en-
tivos— . L a inform ación se d eriva asociando los hechos sional. L a in fo rm ac ió n re co g id a acerca de una gam a
en el seno de un contexto dado. El conocim iento aso am plia de tem as relacionados y no relacionados se agru
cia la in fo rm a c ió n o b te n id a en un c o n te x to co n o tra pan para fo rm ar un cu erpo de h ech o s al que se d e n o
inform ación obtenida en un contexto distinto. P or Últi m in a conocim iento. L a clave es nuestra capacidad para
m o, la sabiduría se produce cuando se derivan unos prin asociar in fo rm ació n de una g am a de fu en tes distintas
cipios g eneralizados de co nocim ientos dispares. E stos que puedan no po seer conexiones evidentes entre s í y
www.FreeLibros.org
2 El crecim iento rápido de las tecnologías de m inería de datos (data
mining) y de alm acen es de d a to s (dala warehousing) reflejan este
rápido crecim iento.
576
CA PÍTULO 32 PERSPECTIVAS FUTURAS
co m binarlas de m o d o que nos proporcione algún b en e du ran te la próxim a década, el n ú m ero d e a lu m n o s que
ficio definido. cu rsa rá n estudios prim arios y s e c u n d a rio s , o la p re
sión habida sobre los políticos para re d u c ir los im p u e s
tos y lim itar p o r tanto los aum entos de su eld o p a ra los
Q p » - -
profesores.
6s el podar que nos capacita pora Todos estos elem entos de in fo rm a c ió n se p u e d e n
: v r d c o n o a rn e n to en nuestro propio beneficio com binar para form ular una representación del c o n o c i
cíe ios dem ás, m ie n to - e x is tir á una presión significativa so bre el sis
tlw n ir i, Wotsoii
tem a de educación de los E stados U n id o s a p rin cip io s
del siglo veintiuno y esta presión p ro se g u irá d u ra n te
P ara ilu stra r la p ro g re sió n desd e los d atos al c o n o m ás de una década— . M ediante este conocim iento, p u e
cim iento, co nsiderarem os los datos del censo que in d i de aparecer la oportunidad de un negocio. Q u izá e x is
c a n q u e e l n ú m e ro d e n a c im ie n to s en lo s E stad o s tan oportunidades significativaspara d esarrollar n u evos
U n id o s en 1996 fu e d e 4,9 m illo n e s. E ste n ú m e ro m odelos de aprendizaje que sean m ás efectivas y m enos
re p re se n ta u n v a lo r de datos. A l re la c io n a r este d ato costosas que los enfoques actuales.
co n los n acim ientos de los cu aren ta años an terio res se El futuro del softw are conduce a sistem as que p ro
puede e x tra e r u n elem en to de in fo rm a c ió n útil: aque cesan el conocim iento. Se ha estado p ro cesan d o d ato s
llas p e rso n a s que tu v ie ro n m u ch o s h ijo s en los años durante cincuenta años y extrayendo inform ación du ran
50 y a principios de los 60, está n e fectu an d o un ú lti te casi tres décadas. U no de los desafíos m ás sig n ific a
m o esfu erzo p o r te n e r n iñ o s antes de lle g ar al fin al de tivos a los que se enfrenta la com unidad de la in g en iería
sus años fértiles. E sta in fo rm a c ió n se puede co n ectar del softw are consiste en construir sistem as que d e n el
en to n ces co n o tro s elem en to s de in fo rm ac ió n ap a re n siguiente paso en el espectro: sistem as que ex traig an el
tem ente no relacionados, p o r ejem plo, el núm ero actual conocim iento de los datos y de la inform ación p a ra que
de p ro fe so re s de escu elas p rim a ria s que se retira rá n sea práctica y beneficiosa.
• *- % . y i*
«A-TEQliQLQGÍA COMO IV JIL&QU .
Las personas que co nstruyen y utilizan softw are, el p ro les) p u ed e n dar lu g a r a cam bios radicales e n la c la se
ceso de ingeniería del softw are que se aplica, y la in fo r de softw are que se pued e construir y ta m b ién a c a m
m ació n que se produce se ven afectados todos ellos por bios fu n d am en tales en nuestro enfoque de la in g e n ie
los avances en la tecn o lo g ía del h ardw are y softw are. ría del softw are. D ado que estos enfoques no tra d ic io
H istóricam ente, el h ardw are ha servido com o im pulsor n a le s sig u en esta n d o en el prim er segm en to del c ic lo
de la tecn o lo g ía de la com putación. U na nueva tecn o de quince años, resulta difícil p redecir la form a en que
logía de h ardw are pro p o rcio n a un potencial. E ntonces el m u n d o del so ftw a re se m odificará para a d a p ta rse a
los co n stru c to re s de so ftw are re a c c io n an fre n te a las ellas.
solicitudes de los clientes en un intento de aprovechar L as ten d en c ias fu tu ras de la ingeniería del so ftw a
ese potencial. re se verán im p u lsad as p o r las tecnologías de so ftw a
Las tendencias futuras de la tecnología del hardw are re. La reutilización y la ingeniería del softw are b asad a
tien en p robabilidades de p ro g resar en d os rutas parale en c o m p o n e n te s (te c n o lo g ía s que to d a v ía n o e s tá n
las. E n u n a de las ru tas, las te c n o lo g ía s de h ardw are m a d u ra s) o fre c e n la m e jo r o p o rtu n id a d en c u a n to a
seguirán evolucionando rápidam ente. M ediante la m ayor m ejo ras de gran m a g n itu d en la calid ad de los s is te
capacid ad que p ro p o rc io n a n las te c n o lo g ía s de h a rd m a s y se e n c u e n tra n en el m o m e n to de c o m e rc ia li
w are tradicionales, las dem andas efectuadas a los in g e z a rse . D e h e c h o , a m e d id a que p a sa el tie m p o , el
n ieros de softw are seguirán creciendo. negocio del softw are puede em p e za r a ten er un asp ec
to m uy p arecid o al que tien e el n e g o cio del h a rd w a
re e n la a c tu a lid a d . Q u iz á e x is ta n fa b ric a n te s q u e
la nuevo in d e p e n d e rá electrónica recreo al mundo co n stru y a n d isp o sitiv o s d iferen tes (c o m p o n e n te s de
o im agen y sem ejanza del pueblo global. so ftw are re u tiliz a b le s), o tro s fa b ric a n te s q u e c o n s
Mduhan truyan com ponentes de sistem as (por ejem p lo , un c o n
ju n to de h e rra m ie n ta s p a ra la in te ra c c ió n h o m b re -
P ero los c a m b io s v e rd a d e ro s de la te c n o lo g ía de m áq u in a) e in teg rad o re s de sistem as que p ro p o rc io
h a rd w a re se p u e d e n p ro d u c ir en o tra d ire c c ió n . E l nen so lu cio n es p ara el u su a rio final.
www.FreeLibros.org
d esarro llo de arq u itectu ras de h ard w are no tra d ic io L a in g en iería del so ftw a re va a c a m b ia r — de eso
n ales (por ejem p lo , m áquinas m asiv am en te paralelas, podem os estar seguros— . P ero independientem ente de
p ro c e sa d o re s ó p tic o s y m áq u in as de red es neu ro n a- lo radicales que sean los cam bios, podem os estar segu-
577
ING EN IE RÍA DEL S OFT W ARE . UN EN F O Q U E P R Á C T I C O
ros de que la calidad n u n ca p erd erá su im portancia, y probación co m p eten te siem pre tendrán su lu g a r en el
de que un análisis y diseño efectiv o sju n to con una com - desarrollo de sistem as basados en com putadoras.
Ya han p asado 20 años desde que se escribió la prim e los cuales parecen estar preparados a rep etir lo s errores
ra edición de este libro. Y to d av ía m e acuerdo de c u an del pasado.
do e ra u n jo v e n p ro fe so r se n ta d o en m i m e sa y Para facilitar la transición necesitam os m uchas cosas
escribiendo (a m ano) el m anuscrito de un libro sobre un - u n proceso de softw are adaptable y sensible, m étodos
tem a que no p reo cu p ab a a m uchas p ersonas y que aún m ás eficaces, herram ientas m ás potentes y una acepta
m en o s en tendían realm ente. R ecuerdo la cartas de los ción m ejor de sus partidarios y soporte de los directores,
editores rech azan d o el libro y argum entando (de form a y una dosis no pequeña de educación y « p u b licidad»-.
educada, pero contundente) que n u n ca h ab ría m ercado L a ingeniería del softw are no h a disfrutado de una gran
para un libro sobre « ingeniería del softw are». A fo rtu publicidad, pero a m ed id a que v a pasando el tiem po el
nadam ente, M cG raw -H ill decidió inten tarlo 3, y el re s concepto se vende solo. D e alguna m anera, este libro es
to y a es historia. un «anuncio» para la tecnología.
D urante los Últimos v einte años, este libro h a cam Es posible no estar de acuerdo con todos los e n fo
biado espectacularm ente - e n ám bito, tam año, estilo y ques descritos en este libro. A lgunas de las técnicas y
contenido— . A l igual que la ingeniería del softw are m is opiniones son polém icas; otras deberán ajustarse para
m a, el libro tam bién h a crecido, y p o r suerte tam bién ha trabajar en diferentes entornos de desarrollo de softw a
m adurado durante los Últimos años. re. Sin em bargo, m i sincera esperanza es que In g en ie
H oy en d ía un enfoque de ingeniería en el d esarro ría d el Softw are: Un enfoque p rá c tic o haya d ib ujado
llo del so ftw a re de c o m p u ta d o ra es u n a sa b id u ría los problem as con los que nos enfrentam os; haya dem os
convencional. A unque continúe el debate sobre el «para trado las ventajas de los conceptos de la ingeniería del
d ig m a a d e c u a d o » , el g ra d o de au to m atizació n y los softw are, y h ay a proporcionado un m arco de trabajo de
m étodos m ás efectivos, hoy en d ía los princip io s sub m étodos y herram ientas.
yacen tes de la ingeniería del softw are se aceptan a tra C o m o e m p ie z a un n u e v o m ile n io , el so ftw are se
vés de la industria. E ntonces, ¿por qué solo hace m uy h a c o n v e rtid o e n el p ro d u c to m á s im p o rta n te de la
po co tie m p o q u e e sta m o s sie n d o testig o s de su gran in d u stria y ta m b ién m ás im p o rtan te a n iv el m undial.
adopción? S u im pacto e im portancia han recorrido un larg o cam i
L a respuesta, creo yo , ra d ic a en la d ificultad de la no. Y, sin e m b a rg o , u n a n u e v a g e n e ra c ió n d e desa-
transición de la tecn o lo g ía y el cam bio cultural que la rro lla d o re s de s o ftw a re d e b e rá n e n c o n tra rs e con
acom paña. A unque la m ay o ría de n osotros apreciam os m u ch o s de los m ism o s re to s co n los que se e n fre n ta
la necesid ad de u n a disciplina de ingeniería p ara el soft ro n g en eracio n es anteriores. E sp erem o s que aquellas
w are, lucham os contra la inercia de la p ráctica anterior p erso n as que se en cu e n tre n co n el re to - i n g e n i e r o s
y nos enfrentam os con nuevos dom inios de aplicacio del s o f t w a r e - t e n g a n la sab id u ría de d esarro llar sis
nes (y los que diseñan que son quienes trabajan en ellos) tem as que m e jo re n la co n d ició n hum ana.
[BOL91] Bollinger, T„ y C. M cGowen, «A C ritical Lookat [HOP90] Hopper, M .D., «R attling SABRE, N ew Ways to
Software Capability Evaluations,» IE E E Softw are, Julio C om pete on Inform ation», H a r v a r d B u sin e ss R eview ,
de 1991,pp. 25-41' M ayo-Junio de 1990.
[PAU93J Paulk, M, et al., C a p a b ility M a tu rity M o d el fo r
[GIL96] Gilg, T., «W hat is level $>ixl»JE E E Softw are , E ne
ro de 1996,pp. 97-98 y 103 Software, Software Engineering Institute, Camegie Mellon
U niversity,Pittsburgh, PA, 1993.
www.FreeLibros.org
3 Realm ente los m éritos son de Peter Freem an y Eric M unson, que
fueron quienes convencieron a McGraw-Hill de que valdría la pena
intentarlo.
578
CAPÍTULO 32 PE RS PE C TI V AS FUT URAS
3 2 .1Consiga una copia de las mejores revistas de negocios y 3 2 .4Revise el estudio de lo s modelos de proceso evolutivo
de noticias de esta semana (por ejemplo -.Newsweek, Time, B usi del Capítulo 2. Haga una investigación y recoja artículos
ness Week). Haga una lista de todos los artículos o noticias que recientes sobre este tema. Resuma las ventajas e inconvenientes
se puedan utilizar para ilustrar la importancia del software. de los paradigmas evolutivos basados en las experiencias indi
3 2 .2 Uno de los dominios de aplicaciones de software más cadas en los artículos.
candentes son los sistemas y las aplicaciones basados en Web 3 2 .5 Intente desarrollar un ejemplo que comience con la
(Capítulo 29). Estudie la forma en que las personas, comuni recolección de datos puros y dé lugar a la adquisición de
cación y proceso tienen que evolucionar para adoptar el desa información, después del conocimiento, y finalmente de sabi
rrollo de WebApps de «próxima generación». duría.
3 2 .3Escriba una breve descripción del entorno de desarrollo
ideal de un ingeniero del software hacia el año 2010. Descri 3 2 .6Seleccione una tecnología de actualidad «candente» (no
ba los elementos del entorno (hardware, software y tecnolo necesita ser una tecnología de software) que se esté estudian
gías de comunicación) y su impacto en la calidad y el tiempo do en los medios populares y describa la forma en que el soft
de comercialización. ware posibilita su evolución e impacto.
...QTiL&S .LECXURAS-Y.jEJJJEWX.ES P E . í
Los libros que estudian las tendencias futuras del software tution Press, 1999)han publicado una colección de artículos
y de la computación abarcan una amplia gama de temas téc y ensayos sobre el impacto de la tecnología en las estructu
nicos científicos, económicos, políticos y sociales. Robertson ras sociales, de negocios y económicas. Para aquellos que
(T h eN ew R en a issa n ce: C o m p u ters a n d T h e N e x t L e v e l o f estén interesados en estos temas técnicos, Luryi, Xu y Zas-
C ivilization, Oxford University Press, 1998), argumenta que lavsky (Future Trends in M icro elec tro n ics, Wiley, 1999) han
la revolución informática puede que sea el Único avance más publicado una colección de artículos sobre las direcciones
significativo en la historia de la civilización. Dertrouzos y probables del hardware de computadora. Hayzelden y Big-
Gates (W h a tW ill B e: H o w The N ew W orld o f In form ation ham (S oftw are A g e n ts f o r F uture C om m u n ication S ystem s,
W ilIChange O u rL iv e s, Harperbusiness, 1998)proporcionan Springer Verlag, 1999) han editado una colección que estu
un profundo estudio de algunas de las direcciones que las tec dia las tendencias del desarrollo de los agentes de software
nologías de la información pueden seguir en las primeras inteligentes.
décadas de este siglo. Bamatt (V aluew are: Technology,Huma- K u rzw e il (T h eA g e o f S p iritu a l M achines, W hen C om pu-
nity and Organization, Praeger Publishing, 1999)presenta un ters E xceedH um an Intelligence, Viking/Penguin Books, 1999)
estudio intrigante de la «economía de las ideas» y de la for argumenta que dentro de 20 años la tecnología del hardware
ma en que se creará el valor económico a medida que evolu tendrá la capacidad de modelar completamente el cerebro
ciona el ciber-negocio. El libro de Negroponte (B eing D igital, humano. Borgman (H o ld in g on to R e a lity : The N atu re o f
Alfred A. Knopf, Inc., 1995) fue un best seller a mediados de Inform ation a t the Turn o f the M illenium , University of Chi
los noventa y continúa proporcionando una visión interesan cago Press, 1999) ha escrito una historia de información intri
te de la computación y de su impacto global. gante, haciendo un seguimiento de su papel en la
Kroker y Kroker (.D igitalD eliriu m , New World Perspecti- transformación de la cultura. Devlin (InfoSense: Turning Infor
ves, 1997) han publicado una colección polémica de ensayos, m ation in to K n o w led g e, W.H. Freeman& Co., 1999) trata de
poemas y humor en donde examinan e l impacto de las tecno dar sentido al constante flujo de información que nos bom
logías digitales en las personas y en la sociedad. Brin (TheTrans- bardea día a día. Gleik (F aster: T heA cceleration o fJ u stA b o u t
parent Society: W iü Technology F orcé us To C hoose Betw een E verything, Pantheon Books, 20 0 0 ) estudia el ritmo cada vez
P rivacy and Freedom ?, Perseus Books, 1999) repasa el debate más veloz del cambio tecnológico y de su impacto en todos
continuo asociado a la pérdida inevitable de privacidad perso los aspectos de la vida moderna. Jonscher (T h eE volu tion o f
nal que acompaña al crecimiento de las tecnologías de la infor W iredLife: From theAlphabet. to the Soul-C atcher C hip-H ow
mación. Shenk (D a ta S m o g : Surviving the Inform ation G lut, Inform ation Technologies C hange O u r W orld, Wiley, 2 0 0 0 )
Harpercollins, 1998) estudia lo s problemas asociados con la argumenta que el pensamiento humano y la interacción tras
«sociedad infectada de información» que se está produciendo cienden la importancia de la tecnología.
del volumen de información que producen las tecnologías de Una variedad de fuentes de información sobre las ten
información. dencias futuras en la informática está disponible en Intemet.
Miller, Michalski y Stevens (2 1 st C en tu ry Technologies: Una lista actualizada de referencias en la red se puede encon
P rom ises an d P erils o f a D yn am ic Future, Brookings Insti- traren h t tp : / /w w w .p r e s s m a n 5 .c o m
www.FreeLibros.org
A P É N D IC E
S IG L A S MÁS C O M U N E S EN
IN G E N IE R ÍA D EL S O F TW A R E
Siglas Español / Inglés
Término en Español Término equivalente en Inglés
AAN (Análisis del área del negocio) BAA (Business Area Analysis)
ACC (Autoridad de control de cambio) CCA (Change Control Authority)
ACO (Acoplamientoentre clases de objetos) CBO (Coupling Between Object Classes)
ACPs (Areas clave de proceso) KPAs (Key Process Areas)
ACV (Arquitectura del ciclo de vida) LCA (Life Cycle Architecture)
ADOO (Análisis del dominio orientado a objetos) OODA (Object-Oriented Domain Analysis)
AE (Análisis estructurado) SA (Structured Analysis)
AG2D (Análisis geométrico de dos dimensiones) 2DGA (Two-dimensional Geometric Analysis)
AG3D (Análisis geométrico de tres dimensiones) 3DGA (Three-dimensional Geometric Analysis)
AOO (Análisis orientado a objetos) OOA (Object-Oriented Analysis)
APD (Acceso público a datos miembros) PAD (Public Access to Data members)
APH (Arbol de profundidad de herencia) DIT (Depth of the Inheritance Tree)
API (Interfaz de programación de aplicaciones) API (Application Programming Interface)
AROO (Análisis de los requisitos orientado a objetos) OORA (Object-Oriented Requirements Analysis)
AVG (Análisis de valor ganado) EVA (Eamed Valué Analysis)
AVL (Análisis de valores límites) BVA (Boundary Valué Analysis)
BDK (Kit de desarrollo Bean) BDK (Bean Development Kit)
BRO (Operador relacional y de ramificación) BRO (Branch and Relational operator)
BS (brutos.sueldos) GW (gross .wages)
C (Certificación) C (Certification)
C (Consulta) Q (Query)
C& I (construcción e integración) C& I (Construction and Integration)
C/S (Cliente/servidor) C/S (Client/server)
CAD (Diseño asistido por computadora) CAD (Computer-Aided Design)
Cadena DU (cadena de definición-uso) DU chain (Definition-Use chain)
CASE (Ingeniería del software asistida por computadora) CASE (Computer-Aided Software Engineering)
CC (Centralizado controlado) CC (Controlled Centralised)
CCM (Carencia de cohesión en los métodos) L CO M (Lack of Cohesión in Methods)
CEU (Comprobación estadística de utilización) SUT (Statistical Use Testing)
CFD (Cohesiones funcionales débiles) W FC (WeakFunction Cohesión)
CFF (Cohesiones funcionales fuertes) SFC (Strong Functional Cohesión)
CGI (Interfaz común de pasarela) CG I (Common Gateway Interface)
C G O (Capa de gestión de objetos) OM L (Object Management layer)
CK serie de métricas (Chidamber y Kemerer) CK metrics suite (Chidamber and Kemerer metrics)
CN (Control numérico) NC (Numerical Control)
CO (Complejidad de operación) O C (Operation Complexity)
CO CO M O (Modelo constructivo del coste) C O C O M O (Constructive Cost Model)
CO I (Capacidad operativa inicial) IO C (Initial Operational Capability)
COM (Modelo de objetos para componentes) CO M (Component Object Model)
CORBA (Arquitectura común de distribución de objetos) CORBA (Common Object Request Broker Architecture)
CP (Control de periféricos) PC (Peripheral Control)
C PT P (Coste de presupuestos del trabajo planificado) BCWS (Budgeted Cost of Work Scheduled)
CPTR (Coste de presupuestos del trabajo realizado) BCW P (Budgeted Cost of Work Performed)
CR (Conveniencia de la representación) LA (Layout Appropriateness)
CRC (Clase-responsabilidad-colaboración) CRC (Class-Responsibility-ODllaborator)
CRTR (Coste real de trabajo realizado) ACW P (Actual Cost of Work Performed)
CTA (Control de tráfico aéreo) ATC (Air Trafile Control)
CYD (Comerciales ya desarrolladas) COTS (Commercial Off-The-Shelf)
DBC (Desarrollo basado en componentes) CBD (Component-Based Development)
DC (Descentralizado controlado) CD (Controlled Decentralised)
DCBC (Descubrimiento de conocimiento en bases de datos) KDD (Knowledge Discovery in Databases)
DCS (Diagrama de contexto del sistema) SCD (System Context Diagram)
www.FreeLibros.org
DD (Descentralizado democrático) DD (Democratic Decentralized)
DDE (Desviación deliverada de la especificación) IDS (Intentional Deviation from Specification)
DER (Diagrama de entidad-relación) ERD (Entity Relationship Diagram)
DE (Diseño formal) ED (Formal Design)
581
APÉNDICE
DFC (Desplieguede la función de calidad) QFD (Quality Function Deployment)

DFC (Diagrama de flujo de control) CFD (Control Flow Diagram)
DFD (Diagrama de flujo de datos) DFD (Data Flow Diagram)
DFS (Diagramade flujo del sistema) SFD (SystemFlow Diagram)
DII (Documentaciónimprecisa o incompleta) IID (Inaccurateor Incomplete Documentation)
DOO (Diseño orientado a objetos) OOD (Object-OrientedDesign)
DPR (Diseño para la reutilización) DFR (Design for Reuse)
DRA (Desarrollorápido de aplicaciones) RAD (Rapid Application Development)
DSED (Desarrollode sistemas estructurados de datos) DSSD (Data Structured Systems Development)
DSJ (Desarrollode sistemas Jackson) JSD (Jackson System Development)
DSN (Diseñode sistema de negocio) BSD (Business System Design)
DTE (Diagramade transición de estados) STD (State Transition Diagram)
EA IP (Entorno de apoyo integrado a proyectos) IPSE (Integrated Project Support Environment)
EAT (Estructuras de análisis del trabajo) W BS (W orkBreakdown Structure)
EC (Especificación de control) CSPEC (Control Specification)
ECS (Elementos de configuracióndel software) SCI (Software Confígurationltems)
ED (Elementos de datos) DE (Data Elements)
EDC (Espacio de diseño cuantificado) QDS (Quantity Design Space)
EDE (Elementos de datos de entrada) DEI (Input Data Elements)
EDR (Elementos de datos retenidos) DER (Retained Data Elements)
EDS (Elementos de datos de salida) D E O (Output Input Data Elements)
EEC (Especifícaciónde estructura de cajas) BSS (Box Structure Specification)
EED (Eficacia de eliminación de defectos) DRE (DefectRemoval Efficiency)
EIE (Especificación incompleta o errónea) IES (Incomplete or Erroneous Specification)
EIS (Entorno de ingeniería del software) SEE (Software Engineering Environment)
ELD (Error en la lógica de diseño) EDL (Error in Design Logic)
EP (Especificación de proceso) PSPEC (Process Specification)
ERD (Error en representación de datos) EDR (Error in Data Representation)
ES (Estados) ST (States)
ETRP (Evaluacióny técnica de revisión de programas) PERT (Program Evaluation and ReviewTechnique)
FA (Factorde acoplamiento) CF (Coupling Factor)
FHA (Factorde herencia de atributo) AIF (Attributelnheritance Factor)
FHM (Factorde herencia de métodos) M IF (Method Inheritance Factor)
FIR (FICA.impuesto.retenido) FTW (FlCA.Tax.Withheld)
FP (Factorde polimorfismo) PF (Polymorphism Factor)
FPG C (Facilidadesde presentación gráfica de computadora) CGDF (Computer Graphics Display Facilities)
FURPS (Funcionalidad,facilidad de uso, fiabilidad, FURPS (Functionality,Usability, Reliability,
rendimiento y capacidad de soporte) Performance and Supportability )
FZ (Fijarzona) ZS (Zone Set)
GBD (Gestión de base de datos) DBM (Database Management)
GC (Generaciónde código) CG (Code Generation)
GCS (Garantía de calidad del software) SQA (Software Quality Assurance)
GCS (Gestión de la configuración del software) SCM (Software Configuration Management)
G IP (Grupo independientede prueba) ITG (IndependentTest Group)
OCM /OPM (Objetivo,cuestión (pregunta),métrica) GQM (Goal, Question, Metric)
GTC (Gestión total de calidad) TQM (Total Quality Management)
FID (Habilitar/deshabilitar) AD (Arm-Disarm)(/>. 731)
HIR (Hoj a de información del riesgo) RIS (Risk Information Sheet)
H H p (Protocolo de transferencia de hipertexto) HTTP (HypertextTransferProtocol)
IA (Inteligencia artificial) AI (Artificial Intelligence)
IC (Inspecciónde código) CI (Code Inspection)
1-CASE (CASE integrado) I-CASE (Integrated CASE)
ICED (índice de calidad de la estructura de diseño) DSQI (Design Structure Quality Index)
ICM P (Protocolo de mensajes de control de Internet) IC M P (Internet Control Message Protocol)
IDC (índicede desarrollode coste) C PI (Cost Performance Index)
1DL (Lenguaje de definición de interfaces) IDL (Interface Definition Language)
1DP (índice de desarrollo de planificación) SPI (Schedule Performance Index)
IE (índice de error) E l (Error Index)
IEC (Informes de estado de la configuración) CSR (Configuration Status Reporting)
IE P (Incumplimientode los estádandares de programación) VPS (Violation of Programming Standards)
IES (índice de especialización) SI (Specialisationlndex)
IF (índice de fase) PI (Phase Index)
www.FreeLibros.org
IGU (Interfaz gráfica de usuario) GUI (Graphical User Interface)
IH M (Interfazhombre-máquina) HCI (Human-ComputerInterface)
IM I (Interfaz de módulo inconsistente) ICI (InconsistentComponent Interface)
IM S (índice de madurez del software) SMI (Software Maturity Index)
582
AP ÉN DI C E
IP (Protocolo de Intemet) IP (Internet Protocol)

IPN (Ingeniería de proceso de negocio) BPE (Business Process Engineenng)
IS (Ingeniería de sistemas) SE (System Engineering)
ISBC (Ingeniería del software basada en componentes) CBSE (Component-Based Software Engineering)
ISO O (Ingeniería del software orientada a objetos) OO SE (Object-Oriented Software Engineering)
ISOOAC (Ingeniería del software orientada a objetos asistida OOCASE (Object-Oriented Computer Aided Software
por computadora) Engineering)
IU (Interfaz de usuario) UI (User Interface)
IUSC (Interfaz de usuario y funciones de control) UICE (User Interface and Control Facilities)
IWeb (Ingeniería Web) W ebE (Web-Engineering)
KLDC (mil líneas de código) K LO C (thousands lines of code)
LDAs (Lenguajes de descripción arquitectónica) ADLs (Architectural Description Languages)
LDC (Líneas de código) LOC (Lines of Code)
LDP (Lenguaje de diseño de programas) PDL (Program Design Language)
LIM (Lenguaje de interconexión de módulos) M IL (Module Interconnection Language)
LPNI (Límite de proceso natural inferior) LPNL (Lower Natural Process Limit)
LSPN (Límite superior del proceso natural) UNPL (Upper Natural Process Limit)
MACA (Método de análisis de compromiso para la arquitectura) ATAM (ArchitectureTrade-off Analysis Method)
MAD (Módulos de análisis de diseño) DAM (Design Analysis Modules)
M CC (Mala interpretación de la comunicación del cliente) M CC (Misinterpretation of Customer Communication)
M CC (Método del camino crítico) C PM (Critical Path Method)
M CM (Modelo de capacidad de madurez) CM M (Capability Maturity Model)
M C P (Marco común de proceso) C PF (Common Process Framework)
M DOO (Métricas para el diseño orientado a objetos) M OOD (Metrics for Object-Onented Design)
MEPS (Mejora estadística del proceso de software) SSPI (Statistical Software Process Improvement)
M M CG P (Modelo de madurez de la capacidad de gestión de personíil) PM -CM M (People Management Capability Maturity Model)
M M GR (Mitigación, monitonzación y gestión del riesgo) R M M M (Risk Mitigation, Monitoring and Management)
Modelo M O I (Motivación, organización, ideas o innovación) M O I Model (Motivation, Organisation, Ideas or innovation)
M O M (Software intermedio orientado a mensajes) M O M (Message Oriented Middleware)
M PC (Métodos ponderados por clase) W M C (Weighted Methods per Class)
NCC (Número de clases clave) NKC (N um berof Key Classes)
NCR (Número de clases raíz) NOR (Number o f Root Classes)
NDD (Número de descendientes) NOC (Number o f Children)
NE (Número de escenarios) NSS (Number of Scenario Scripts)
NN (Nodos de navegación) WoN (Ways of Navigating)
NOA (Número de operaciones añadidas por una subclase) NOA (Number o f Operations Added by a subclass)
NOR (Número de operaciones redefinidas para una subclase) NOO (Number of Operations Ovemdden by subclass)
NPD (Número de padres directos) FIN (Fanin)
NPprom (Número de parámetros por operación promedio) NPavg (Average Number of Parameters per operation)
NSUB (Número de subsistemas) NSUB (Number of Subsystems)
OB (Objetos) OB (Objects)
OC I (Orden de cambio de ingeniería) E C O (Engineering Change Order)
OCV (Objetivos del ciclo de vida) L CO (Life Cycle Objectives)
ODBC (Conectividad abierta de bases de datos) ODBC (Open Database Connectivity)
OLCRS (Sistema interactivo para apuntarse a cursos) OLCRS (On-Line Course Registration System)
OM G/CORBA (Grupo de gestión de objetos/Arquitectura común OM G/CORBA (Object ManagementGroup/Common Object
de distribución de objetos) Request Broker Architecture)
OO (Orientado a objetos) OO (Object-Oriented)
ORB (Agente de distríbuición de objetos) ORB (Object Request Broker)
P (Prueba) T (test)
P&R (Pregunta y respuesta) Q&A (Question and Answer)
PAT (Presupuesto a la terminación) BAC (Budget At Completion)
PE I (Planificación de la estrategia de información) ISP (Information Strategy Planning)
PEN (Proceso elemental de negocios) EBP (Elementary Business Process)
P F (Puntos de función) F P (Function Points) y
Pfu (Primitivas funcionales) FuP (Functional Primitives)
PIE (Prueba incompleta o errónea) IET (Incomplete or Erroneous Testing)
PM Fu (Primitivas modificadas de función manual) FuPM (Modified Manual Function Primitives)
PO O (Programación orientada a objetos) O O P (Object-Oriented Programming)
POP3 (Protocolo de oficina de correos versión 3) POP3 (Post Office Protocol versión 3)
PP. (Planificación de prueba) T P (Test Planning)
PPP (Porcentaje público y protegido) PAP (Percent Public and Protected)
www.FreeLibros.org
PRO/SIM (Construcción de prototipos y simulación) PRO /SIM (PROtotyping and SIMulation)
PrO O (Pruebas orientadas a objetos) OOT (Object-Oriented Testing)
PSI (Procesos secuenciales intercomunicados) CSP (Communicating Sequential Processes)
RE (Relaciones) RE (Relatíonships)
583
APÉNDICE
Térm ino en Español Térm ino equivalente en Inglés
Re¡ (Conexiones de relación) Re¡ (Relationship connections)

RFP RFP
Rm (Rangos de movimiento) m R (moving range)
RPC (Respuesta para una clase) R FC (Response for a class)
RPN (Reingeniería de procesos de negocios) BPR (Business Process Reengineering)
RR (Recolección de requisitos) RG (Requirements Gathering)
RTF (Revisión técnica formal) FTR (Formal Technical Review)
SBDOO (Sistemas de bases de datos orientadas a objetos) OODBS (Object-Oriented Database System)
SCCT (Sistema de clasificación de cinta transportadora) CLSS (Conveyor Line Sorting System)
SCE (Salidas/Control/entradas) OCI (Output/Control/Input)
SDIU (Sistemas de desarrollo de la interfaz de usuario) UIDS (User-Interface Development Systems)
SEI (Instituto de ingeniería de software) SEI (Software Engineering Institute)
SGBDOO (Sistemas de gestión de bases de datos orientadas a objetos) OODBMS (Object-Oriented Database Management System)
SGBDR (Sistema de gestión de bases de datos relacional) RDBMS (Relational Database Management System)
SGH (Servicios de gestión de herramientas) TM S (Tools management Services)
SIG (Sistemas de información de gestión) M IS (Management Information System)
SQA (Gestión de calidad de Software) SQA (Software Quality Assurance
SQE (Ingeniería de Calidad del software) SQE (Software Quality Engineenng)
SQL (Lenguaje de consultas estructurado) SQL (Structure Query Language)
SSRB (Sistema de seguimiento y reparación de baches) PH TRS (Pot Hole Tracking and Repair System)
T4G (Técnicas de cuarta generación) 4GT (Fourth Generation Techniques)
TADE (Técnicas de Análisis y diseño estructurado) SADT (Structured Analysis and Design Technique)
TAP (Tabla de activación de procesos) PAT (Process Activation Language)
TC (Tamaño de clase) CS (Class Size)
TC¡ (Muestras (tokens) de datos) TC, (Data tokens)
TFEA (Técnicas para facilitar las especificaciones de la aplicación) FAST (Facilitated Application Specification Techniques)
TI (Tecnologías de la información) IT (Information technologies)
TLP (Error en la traducción del diseño al lenguaje de programación) PLT (error in Programming Language Translation)
TM C (Tiempo medio de cambio) M TTC (Mean-time-to-change)
TM EF (Tiempo medio entre fallos) M TTF (Mean time to failure)
TM EF (Tiempo medio entre fallos) MTBF (Mean time between failure)
TM O (Técnica de modelado de objetos) O M T (Object Modelling Technique)
TM R (Tiempos medios de reparación) M TTR (Mean time to repair)
TOprom (Tamaño medio de operación) OS,,, (Average Operation Size)
T R (Transiciones) TR (Transitions)
UML (Lenguaje de modelado unificado) UML (Unified Modelling Language)
USN (Unidad semántica de navegación) SNU (Semantic Navigation Uniti
V&V (Verificación y validación) V&V (Verification and Validation)
VC (Varianza del Coste) CV (Cost Variance)
VC (Verificación de corrección) CV (Correctness Verification)
VP (Varianza de planificación) SV (Schedule Variance)
WebApps (Aplicaciones basadas en Web) W ebApps (Web-based Applications)
XML (Lenguaje de marcas extensible) XM L (Extensible Mark-up Language)
Siglas Inglés / E spañol
Térm ino en In g lé s Término equivalente en E spañol
2DGA (Two-dimensional Geometnc Analysis) AG2D (Análisis geométrico de dos dimensiones)

3DGA (Three-dimensional Geometric Analysis) AG3D (Análisis geométrico de tres dimensiones)
4GT (Fourth Generation Techniques) T4G (Técnicas de cuarta generación)
ACW P (Actual Cost of Work Performed) CRTR (Coste real de trabajo realizado)
AD (Arm-Disarm) HD (Habilitar/deshabilitar)
ADLs (Architectural Description Languages) LDAs (Lenguajes de descripción arquitectónica)
A l (Artificial Intelligence) IA (Inteligencia artificial)
AIF (Attribute Inbentance Factor) FHA (Factor de herencia de atributo)
API (Application Programming Interface) API (Interfaz de programación de aplicaciones)
ATAM (Architecture Trade-off Analysis Metbod) MACA (Método de análisis de compromiso para la arquitectura)
ATC (Air Traffic Control) CTA (Control de tráfico aéreo)
BAA (Business Area Analysis) AAN (Análisis del área del negocio)
www.FreeLibros.org
BAC (Budget At Completion) PAT (Presupuesto a la terminación)
BCW P (Budgeted CostofW orkPerfonned) C PTD (Coste de presupuestos del trabajo desarrollado)
BCWS (Budgeted Cost of Work Scheduled) C PT P (Coste presupuestado del trabajo planificado)
BDK (Bean Development Kit) BDK (Kit de desarrollo Bean)
584
AP ÉNDICE
Término en Inglés Término equivalente en Español
BPE (Business Process Engineering) IPN (Ingenieríade proceso de negocio)

BPR (Business Process Reengineering) RPN (Reingenieríade procesos de negocios)
BRO (Branch and Relational operator) BRO (Operador relacional y de ramificación)
BSD (Business System Design) DSN (Diseño desistem a de negocio)
BSS (Box Structure Specification) EEC (Especificación de estructura de cajas)
BVA (Boundary Value Analysis) AVL (Análisis de valores límites)
C (Certification) C (Certificación)
C& I (Construction and Integration) C& I (construcción e integración)
C/S (Client/Server) C/S (Cliente/servidor)
CAD (Computer-Aided Design) CAD (Diseño asistido por computadora)
CASE (Computer-Aided Software Engineenng) CASE (Ingenieríadel software asistida por computadora)
CBD (Component-Based Development) DBC (Desarrollobasado en componentes)
CBO (Coupling Between Object Classes) ACO (Acoplamiento entre clases de objetos)
CBSE (Component-Based Software Engineering) ISBC (Ingenieríadel software basada en componentes)
C C (Controlled Centralised) CC (Centralizadocontrolado)
CCA (Change Control Authority) ACC (Autoridad de control de cambios)
CD (Controlled Decentralised) DC (Descentralizadocontrolado)
CE (Coupling Factor) FA (Factor de acoplamiento)
CFD (Control Fiow Diagram) DFC (Diagrama de flujo de control)
CG (Code Generation) GC (Generación de código)
CGD F (Computer Graphics Display Facilities) FPG C (Facilidadesde presentación gráfica de computadora)
CG I (Common Gateway Interface) CG I (Interfaz común de pasarela)
CI (Code Inspection) IC (Inspección de código)
CK metrics suite (Chidamber and Kemerer metrics) CK serie de métricas (Chidamber y Kemerer)
CLSS (Conveyor Line Sorting System) SCCT (Sistema de clasificación de cinta transportadora)
CM M (Capability Maturity Model) M CM (Modelo de capacidad de madurez)
COCO M O (Constructive Cost Model) C O C O M O (Modelo constructivodel coste)
COM (Component Object Model) COM (Modelo de objetos para componentes)
CORBA (Common Object Request Broker Architecture) CORBA (Arquitecturacomún de distribución de objetos)
COTS (Commercial Off-The-Shelf) CYD (Comerciales ya desarrolladas)
CPF (Common Process Framework) M CP (Marco común de proceso)
CPI (Cost Performance Index) IDC (Índice de desarrollo de coste)
CPM (Critica1 Path Method) CPM (Método del camino crítico)
CRC (CLass-Respcnsibility-CCiiaborator) CRC (Clase-responsabilidad-colaboración)
CS (ClassSize) TC (Tamaño de clase)
CSP (Communicating Sequential Processes) PSI (Procesos secuenciales intercomunicados)
CSPEC (Contrpl Specification) EC (Especificación de control)
CSR (Configuration Status Reporting) IEC (Informes de estado de la configuración)
CV (Correctness Verification) VC (Verificación de corrección)
CV (CostVariance) VC (Varianza del Coste)
DAM (Design Analysis Modules) MAD (Módulos de análisis de diseño)
DBM (Database Management) GBD (Gestión de base de datos)
DD (Democratic Decentralized) DD (Descentralizadodemocrático)
DE (Data Elements) ED (Elementos de datos)
DEI (Input Data Elements) EDE (Elementosde datos de entrada)
DEO (Output Data Elements) EDS (Elementos de datos de salida)
DER (Retained Data Elements) EDR (Elementos de datos retenidos)
DFD (DataFlow Diagram) DFD (Diagrama de flujo de datos)
DER (Design For Reuse) DPR (Diseño para la reutilización)
DIT (Depth of the Inheritance Tree) APH (Árbol de profundidad de herencia)
DRE (DefectRemoval Efficiency) EED (Eficacia de la eliminación de defectos)
DSQI (Design Structure Quality Index) ICED (índice de calidad de la estructura de diseño)
DSSD (Data Structured Systems Development) DSED (Desarrollode sistemas estructuradosde datos)
DU chain (Definition-Use chain) Cadena DU (cadena de definición-uso)
EBP (Elernentary Business Process) PEN (Proceso elemental de negocios)
ECO (Engineering Change Order) O CI (Orden de cambio de ingeniería)
EDL (Error in Design Logic) ELD (Error en la lógica de diseño)
EDR (Errorin Data Representation) ERD (Error en la representación de los datos)
E l (Error Index) IE (Índice de error)
ERD (Entity Relationship Diagram) DER (Diagrama de entidad-relación)
EVA (Eamed Value Analysis) AVG (Análisis de valor ganado)
FAST (Facilitated Application SpecificationTechniques) TFEA (Técnicas para facilitar las especificaciones de la aplicación)
www.FreeLibros.org
FD (Formal Design) DF (Diseño formal)
FIN (Fanin) NPD (Número de padres directos)
FP (Function Points) PF (Puntos de función)
FTR (Formal Technical Review) RTF (Revisión técnica formal)
585
APÉNDICE
FTW (FICA.tax.withheld) FIR (FICA.impuesto.retenido)

FuP (Functional Primitives) Pfu (Primitivas funcionales)
FuPM (Modified Manual Function Primitives) PM Fu (Primitivas modificadas de función manual)
FURPS (Functionality, Usabilíty, Reliability, FURPS (Funcionalidad, facilidad de uso, fiabilidad,
Perfonnance and Supportability) rendimiento y capacidad de soporte)
GQM (Goal, Question, Metric) GQ M (Objetivo, cuestión, métrica)
GUI (Graphical User Interface) IG U (Interfaz gráfica de usuario)
GW (gross.wages) BS (brutos.sueldos)
HCI (Human-Computer Interface) IH M (Interfaz hombre-máquina)
HTTP (Hypertext Transfer Protocol) H TTP (Protocolo de transferencia de hipertexto)
1-CASE (Integrated CASE) 1-CASE (CASE integrado)
IC I (Inconsistent Component Interface) IM I (Interfaz de módulo inconsistente)
ICM P (Intemet Control Message Protocol) ICM P (Protocolo de mensajes de control de Internet)
IDL (Interface Deñnition Language) IDL (Lenguaje de definición de interfaces)
IDS (Intentional Deviation from Specification) DDE (Desviación deliverada de la especificación)
IES (Incomplete or Erroneous Specification) E IE (Especificación incompleta o errónea)
IET (Incomplete or Erroneous Testing) PIE (Prueba incompleta o errónea)
IID (Inaccurate or Incomplete Documentation) D II (Documentación imprecisa o incompleta)
IOC (Initial Operational Capability) CO I (Capacidad operativa inicial)
IP (Intemet Protocol) IP (Protocolo de Intemet)
IPSE (Integrated Project SupportEnvironment) EAIP (Entorno de apoyo integrado a proyectos)
ISP (Infonnation Strategy Planning) P E I (Planificación de la estrategia de información)
IT (Infonnation Technologies) T I (Tecnologías de la información)
ITG (Independent Test Group) G IP (Grupo independiente de prueba)
JSD (Jackson System Development) DSJ (Desarrollo de sistemas Jackson)
KDD (Knowledge Discovery in Databases) DCBC (Descubrimiento de conocimiento en bases de datos)
KLOC (thousands Lines of Code) KLDC (miles de líneas de código)
KPAs (Key Process Areas) ACPs (Áreas clave de proceso)
LA (Layout Appropriateness) CR (Conveniencia de la representación)
LCA (Life Cycle Architecture) ACV (Arquitectura del ciclo de vida)
LCO (Life Cycle Objectives) OCV (Objetivos del ciclo de vida)
LCOM (Lack of Cohesión in Methods) CCM (Carencia de cohesión en los métodos)
LOC (Lines of Code) LDC (Líneas de código)
LPNL (Lower Natural Process Limit) LPNI (Límite de proceso natural inferior)
M CC (Misinterpretation of Customer Communication) M CC (Mala interpretación de la comunicación del cliente)
M IF (Method Inhentance Factor) FH M (Factor de herencia de métodos)
M IL (Module Interconnection Language) LIM (Lenguaje de interconexión de módulos)
MIS (Management Information System) SIG (Sistemas de información de gestión)
M IS (Miscellaneous) VAR (Varios)
MOI Model (Motivation, Organisation, Ideas or Innovation) M odelo M OI (Motivación, organización, ideas o innovación)
MOM (Message Oriented Middleware) M O M (Software intermedio orientado a mensajes)
M OOD (Metrics for Object-Onented Design) M DOO (Métricas para el diseño orientado a objetos)
mR (moving Range) R m (Rangos de movimiento)
MTBF (Mean Time Between Failure) TM EF (Tiempo medio entre fallos)
M TTC (Mean-Time-To-Change) T M C (Tiempo medio de cambio)
M TTF (Mean Time To Failure) T M F (Tiempo medio de fallos)
M TTR (Mean Time To Repair) T M R (Tiempos medios de reparación)
NC (Numerical Control) CN (Control numérico)
NKC (Num berOf key classes) NCC (Número de clases clave)
NOA (Number of Operations Added by a subclass) NOA (Número de operaciones añadidas por una subclase)
NOC (Number of Children) NDD (Número de descendientes)
NOO (Number of Operations Overridden by subclass) NOR (Número de operaciones redefinidas para una subclase)
ÑOR (Number ofRoot classes) NCR (Número de clases raíz)
NPavg (Average Number ofParameters per operation) NPprom (Número de parámetros por operación promedio)
NSS (Number of Scenario Scripts) NE (Número de escenarios)
NSUB (Num berof Subsystems) NSUB (Número de susistemas)
OB (Objects) OB (Objetos)
O C (Operation Complexity) C O (Complejidad de operación)
OCI (Output/Control/Tnput) SCE (Salidas/Dontrol/entradas)
ODBC (Open Database Connectivity) ODBC (Conectividad abierta de bases de datos)
O LCRS (On-line Course Registration System) O LCRS (Sitema interactivo para apuntarse a cursos)
OM G/CORBA (Object Management Group/Common Object Request OM G/CORBA (Gmpo de gestión de objetos/Arquitectura común
www.FreeLibros.org
Broker Architecture) de distribución de objetos)
O M L (Object Management Layer) C G O (Capa de gestión de objetos)
OM T (Object Modelling Technique) TM O (Técnica de modelado de objetos)
OO (Object-Oriented) OO (Orientado a objetos)
586
APÉNDICE
OOA (Object-Oriented Analysis) AOO (Análisis orientado a objetos)

OOCASE (Object-Oriented Computer Aided Software Engineering) ISOOAC (Ingeniería del software orientada a objetos asistida
por computadora)
OOD (Object-Oriented Design) DOO (Diseño orientado a objetos)
OODA (Object-Oriented Domain Analysis) ADOO (Análisis del dominio orientado a objetos)
OODBMS (Object-Oriented Database Management System) SGBDOO (Sistemas de gestión de bases de datos orientadas a objetos)
OODBS (Object-Oriented Database Systems) SBDOO (Sistemas de bases de datos orientadas a objetos)
O O P (Object-Oriented Programming) POO (Programación orientada a objetos)
OORA (Object-Oriented Requirements Analysis) AROO (Análisis de los requisitos orientado a objetos)
OOSE (Object-Oriented Software Engineering) ISO O (Ingeniería del software orientada a objetos)
OOT (Object-Oriented testing) PrO O (Pruebas orientadas a objetos)
ORB (Object Request Broker) ORB (Agente de distribuición de objetos)
OSavg (Average Operation Size) TOprom (Tamaño medio de operación)
PAD (Public Access to Data members) APD (Acceso público a datos miembros)
PAP (Percent Public and protected) PPP (Porcentajepúblico y protegido)
PAT (Process Activation Language) TAP (Tabla de activación de procesos)
PC (Peripheral Control) CP (Control de periféricos)
PDL (Program Design Language) LDP (Lenguaje de diseño de programas)
PERT (Program Evaluation and Review Technique) PERT (Técnica de evaluación y revisión de programas)
PF (Polymorphism Factor) FP (Factor de polimorfismo)
PH TRS (Pot Hole Tracking and Repair System) SSRB (Sistema de seguimiento y reparación de baches)
PI (Phase Index) IF (índice de fase)
PLT (error in Programming Language Translation) T L P (Error en la traducción del diseño al lenguaje de programación)
PM -CM M (People Management Capability Maturity Model) M M CG P (Modelo de madurez de la capacidad de gestión de personal)
POP3 (Post Office Protocol versión 3) POP3 (Protocolo de oficina de correos versión)
PRO/SIM (PROtotyping and SIMulation) PRO/SIM (Construcción de prototipos y simulación)
PSPEC (Process SPECification) EP (Especificación de proceso)
Q (query) C (Consulta)
Q&A (Question and Answer) P& R (Pregunta y respuesta)
QDS (Quantity Design Space) EDC (Espacio de diseño cuantificado)
QFD (Quality Function Deployment) DFC (Despliegue de la función de calidad)
RAD (Rapid Application Development) DRA (Desarrollo rápido de aplicaciones)
RDBMS (Relational Database Management System) SGBDR (Sistema de gestión de bases de datos relacional)
RE (Relationships) RE (Relaciones)
Reí (Relationship connections) Rei (Conexiones de relación)
RFC (Response For a Class) RPC (Respuesta para una clase)
RG (Requirements Gathering) RR (Recolección de requisitos)
RIS (Risk Information Sheet) HIR (Hoja de información de riesgos)
RM M M (Risk Mitigation, Monitoring and Management) RSGR (Reducción, supervisión y gestión de riesgos)
SA (Structured Analysis) AE (Análisis estructurado)
SADT (Structured Analysis and Design Technique) TADE (Técnicas de Análisis y diseño estructurado)
SCD (System Context Diagram) DCS (Diagrama de contexto del sistema)
SCI (Software Configuration Items) ECS (Elementos de configuración del software)
SCM (Software Configuration Management) GCS (Gestión de la configuración del Software)
SE (System Engineering) IS (Ingeniería de sistemas)
SEE (Software Engineering Environment) EIS (Entorno de ingeniería del software)
SEI (Software Engineering Institute) SEI (Instituto de ingeniería de software)
SFC (Strong Functional Cohesión) C FF (Cohesiones funcionales fuertes)
SED (System Flow Diagram) DES (Diagrama de flujo del sistema)
SI (Specialisation Index) IES (índice de especialización)
SMI (Software Maturity Index) IM S (índice de madurez del software)
SNU (Semantic Navigation Unit) USN (Unidad semántica de navegación)
SPI (Schedule Perfonnance Index) IDP (Indice de desarrollo de planificación)
SQA (Software Quality Assurance) GCS (Garantía de calidad del software)
SQE (Software Quality Engineering) SQE (Ingeniería de Calidad del software)
SQL (Structure Query Language) SQL (Lenguaje de consultas estructurado)
SSPI (Statistical Software Process Improvement) MEPS (Mejora estadística del proceso de software)
ST (States) ES (Estados)
STD (State Transition Diagram) DTE (Diagrama de transición de estados)
SUT (Statistical Use Testing) CEU (Comprobación estadística de utilización)
SV (Schedule Variance) VP (Varianza de planificación)
T (test) P (Prueba)
www.FreeLibros.org
TCi (Data tokens) TCi (Muestras — tokens— de datos)
TMS (Tools Management Services) SGH (Servicios de gestión de herramientas)
T P (Test Planning) PP (Planificación de prueba)
TQM (Total Quality Management) G TC (Gestión total de calidad)
587
APÉNDICE
T R (Transitions) TR (Transiciones)
UI (User Interface) IU (Interfaz de usuario)
UICE (User Interface and Control Facilities) IUFC (Interfaz de usuario y facilidades de control)
UIDS (User-Interface Development Systems) SDIU (Sistemas de desarrollo de la interfaz de usuario)
UML (Unified Modelling Language) UML (Lenguaje de modelado unificado)
UNPL (UpperNatural Process Limit) LPNS (Límite de proceso natural superior)
V&V (Verification and validation) V&V (Verificación y validación)
VPS (Violation of Programming Standards) IE P (Incumplimientode las estádandaresde programación)
WB S (Work Breakdown Structure) EAT (Estructurasde análisis del trabajo)
W ebApps (Web-basedApplications) Web Apps (Aplicacionesbasadas en Web)
W ebE (Web-Engineenng) IWeb (Ingeniería Web)
W FC (WeakFunction Cohesión) C FD (Cohesiones funcionalesdébiles)
W M C (Weighted methods per class) MPC (Métodos ponderados por clase)
WoN (Ways of navígating) NN (Nodos de navegación)
XM L (Extensible Mark-up Language) X M L (Lenguaje de marcas extensible)
ZS (Zone Set) FZ (Fijar zona)
ÍNDICE
Abstracción. 223-224.423 funcional, 527
Acceso público a datos miembros (APD). 429 para ganar valores, 125-126
Ackerman, A.F.. 308 de interacción, 527
Acoplamiento. 231.424 de inventario, 545-546, 554
entre clases objeto (ACO). 426 (m a p p in g )
común. 231 de las transacciones, 252-255
de contenido. 231 de las transformaciones, 247-252
de control. 231 orientado a objetos (AOO), 352, 376
externo. 231 de componentes genéricos, 366-367
métricas de. 334-335 consistencia, 410-412
Actividades enfoque(s)
de construcción e integración (C&I), 170. 171 00,362
del marco de trabajo. 25, 46 unificado, 363-364
de modelado de diseño. 171 exactitud, 409-410
protectoras. 16.38 métodos de, 362-363
Actores, 187-188, 368 proceso, 367-373
Adaptador de objetos, 513 pruebas, 409-410
Agente de distribución de objetos (ORB). 511 principios del, 188-192
Agregación. 394-395 de los requisitos, 20
Agrupación descripción, 182-183
de datos afines, 505-506 orientado a objetos (AROO), 344
de objetos, 156 para la reutilización, 481-482
Albretch, A J., 62 de selección del diseño, 244-245
Algoritmos. 61 de tareas, 264
diseño de. 389-390 de valores límite (AVL),297
Almacén Aplicaciones basadas en Web ( WebApps)
CASE integrado (1-CASE) atributos de calidad, 523-524
características y contenido, 568-571 características, 523
papel. 567-568 categorías, 523
de datos. 239-240,504 contenido, 536-537
Almacenamiento estructurado, 480 controladas por el contenido, 522
Ambigüedades, 436 diseño, 527-532
Ambito, 536 escalabilidad, 537
del concepto. 119, 120-121 evolución continua, 523
preliminares. 119 intensivas de red, 522
del software. 45 personas, 537
definición, 79 políticas, 537
ejemplo, 80-82 pruebas, 532-533
obtener información, 79-80 tecnologías, 524
vabilidad, 80 Árbol
Arnbler, S., 368 de decisión, 93-94
Análisis, 2 16.563 de profundidad de herencia (APE1), 425,429
del árbol de fallos, 144 Áreas de proceso clave (ACP). 14
del área de negocio (AAN), 170 características, 18
del código fuente, 550-55 1 Amold, R.S., 550
de compromiso para la arquitectura, 243-244 Arquitectura(s), 169-170
de la configuración, 527 de aplicación, 169-170
del contenido, 527 del ciclo de vida (ACV), 27
de contribución, 245 cliente/servidor (C/S), 552-553
de coste. 485-486 de control, 243
de datos. 551 de datos. 169-170.241-242.243
descripción del. 181, 361 descripción, 238
del dominio, 364,476-477 estratificadas, 242,496-497
orientado a objetos (ADOO). 344 importancia de la, 238-239
proceso, 365-366 de integración, 566-567
estructurado, 216-217 de llamada y retorno, 242
descripción, 199-200 orientadas a objetos, 242
www.FreeLibros.org
historia, 200 del software, 226
mecanismos, 210-215 Asignación de componentes
de fallos. 56-57 gestión de datos remota, 5 10
589
ÍN D I C E DE MATERIAS
A s ig n a c ió n d e c o m p o n e n tes (C o n t.) C a p a de
ló g ic a d istrib u id a , 5 1 0 g e stió n de o b jeto s (C G O ), 567
p re se n ta c ió n d istrib u id a, 509 interfaz de u su a rio , 566
rem o ta, 5 0 9 -5 1 0 re p o sito rio c o m p a rtid o , 567
A so cia ció n , 395 C ap ac id a d
de co n tro l, 516 d e d e sc o m p o sic ió n , 284
de datos, 5 1 6 de e x p an sió n , 325
A trib u to s, 202, 233-234 o p e rativ a in ic ial (C O I), 27
e sp e c ific a c ió n de, 353 C ard , D .N ., 332
A u d ito ría de co n fig u ra ció n , 158-159 C a rd in a lid a d , 203
A u to d o c u m e n tac ió n , 325 C a ren c ia d e c o h e s io n e n los m é to d o s (C C M ), 4 2 6 ,4 2 8
A u to m atiza ció n , 480 C A S E in te g rad o (1-C A S E ), 565 -5 6 6
A u to rid a d de co n tro l de c am b io (A C C ), 1 5 7 -1 5 8 ,1 5 9 C a sh m an , M , 351
C aso(s) de
p ru e b a, 4 1 5
B a c h ,J „ 156 d e riv a ció n , 2 8 8 -2 9 0
B alzer, R,, 194 uso, 186-188, 367-368, 374-375, 395-397
B ase de datos, 1 6 6 ,2 3 9 ,5 0 9 C a sw e ll, D .L ., 65
d iseñ o de, 514-5 15 C avano, J.P., 326
estru ctu ra, 549 -5 5 0 C e rtifica ció n , 4 6 1 ,4 6 8 -6 4 9
o b jeto de, 516 C e rtifica d o s d ig ita le s, 508
p ru e b as, 517 C h a m p e au x , D. de, 3 4 7 ,3 6 7
B a sili, V., 67 C ham py, J., 4
B a s s ,L ., 2 3 8 ,5 1 3 C h ap ín , N ., 276
B eizer, B ., 2 8 2 ,2 9 0 C h a re tte ,R .N ., 97
B elady, L .,2 1 9 C hen, R, 204
B e n n e tt,S ., 383 C h id am b e r, S.R ., 427
B e rard , E ., 4 2 1 ,4 2 2 C h ifo v sk y ,E .J., 544
B e rard , E.V., 3 4 4 ,3 5 5 C h ristel, M .G ., 172
B iem a n ,J.M ., 334 C hurcher, N .I., 425
B in d er,R .V „ 4 0 7 ,4 2 8 ,4 2 9 C iclo de v id a clásica. V éase m o d elo secu en cial lineal
B o al, I., 4 C lases, 3 4 6 ,3 6 8 -3 6 9
B o e h m ,B „ 25, 2 6 ,4 9 ,9 1 , 134, 306 clave, 429-430
B o o c k ,G „ 3 5 5 ,3 6 2 ,3 8 2 d ep en d ien te s, 412
B o w a n , J.P., 455 d isp o sitiv o de, 369
B reuer, P.T., 549 id e n tific a c ió n d e , 350-353
B ro o h , J., 4 in te ra c c ió n de, 369
B ro o k s, F., 9, 21, 113 in te rd ep e n d ien te s, 412
B u sc h m an n .F ., 385 p ro p ie d a d de, 369
C la s e s -resp o n sab ilid a d e s-c o la b o rac io n es(C R C ), 368-371
co n sisten c ia, 4 1 0 -4 1 2
estru ctu ras, 371-372
C ad en a d efinición-uso (D U j, 292-293
je ra rq u ía s, 371-372
C alid ad , 63-64, 69, 306, 324
su b sistem as, 372
co m p o n e n tes re u tiliz ab le s, 484 -4 8 5
tarjeta s índice, 368, 369, 3 7 3 ,4 1 1
c o n ce p to s, 132-134
C lasific ac ió n
c o n tro l d e v a ria ció n , 132
d e a trib u to s y v a lo re s, 4 84
de c o n co rd a n cia , 132-133
en u m e rad a , 483
de co ste, 133
p o r facetas, 4 8 3 -4 8 4
de d ise ñ o , 1 3 2 -1 3 3 ,2 2 0 ,2 2 1
C lem e n ts,P .C ., 473
e stán d a res, 146-147
C lem m , G .M ., 155
facto res
C lie n te, 39, 169
e x te rn o s, 223
c o m u n ic a c ió n ,25, 46, 79-80
in tern o s, 2 2 3 '
e v alu ac ió n , 25, 46
IS O , 326
ligero, 5 1 0
de M cC all, 234-235
p esad o , 509
fallo, 134
re a c c ió n an te el c o n ce p to , 119
F U R P S , 325 -3 2 6
C o a d ,P ., 3 4 6 ,3 5 2 ,3 6 2 - 3 6 3 ,3 8 2 ,3 8 6 , 387
m edidas de, 94
C o b e rtu ra
m étrica s, 3 31 -3 3 2
de e n laces, 296
m o v im ien to , 134-135
de nodos, 296
p re v en c ió n , 133
C ó d ig o fu en te, m étrica s, 336 -3 3 7
tran sició n a una v isió n c u an tita tiv a , 3 26-327
C o h e sió n , 2 3 0 ,4 2 4
v a lo ra c ió n , 134
a cc id e n tal, 230
www.FreeLibros.org
v a ria c io n e s e n tre m u estra s, 132
lóg ica, 230
C am b io , 9 -1 0
m étrica s de, 334
ám b ito , 574
tem p o ral, 2 30
590
I n d ic e de m a t e r ia s
C o lab o ra cio n e s, 368, 370-371 C ontradicciones, 436

C olecció n de m étrica s M D O O , 4 2 7 C ontrol
C O M de M ic ro so ft, 480 cam bio(s), 156-158
C o m erc io e le ctró n ico form al, 158
a rq u itec tu ra téc n ica , 501-502 individual, 158
d e sc rip c ió n , 499-500 proceso estadístico, 70-72
fu n c io n e s, 500-501 sincronización, 158
tec n o lo g ía s, 502-508 versiones, 155-156
C o m p le jid a d , 423 C ontrolabilidad, 284
a rq u itec tó n ic a , 245 C ontroladores, riesgo, 101
c ic lo m á tic a, 2 8 7 -2 8 8 ,3 3 7 C o n v ersió n (m apping)
de d atos, 333 arquitectónica, 245-246
m étrica s, 335 de transacciones, 245-246
de o p e rac io n e s, 428 de transform aciones, 247-252
C o m p le titu d , 3 2 5 ,4 2 4 ,4 3 6 C o rrecció n , 6 4 ,3 2 4
C om ponente(s) C o ste, 485
a c tu a liz a c ió n de, 4 7 4 ,4 7 5 de la c alid ad , 133-134
a d a p ta c ió n de, 4 7 4 ,4 7 5 ,4 7 9 e m p írico , 49
de la a d m in istra c ió n d e datos, 386 -3 8 7 de p resupuesto de trabajo
de a d m in istra c ió n d e tare as, 386 planificado (CPTP), 125-126
de a p lic ac ió n , 509, 5 10-511 re a liz a d o (CPTR), 125-126
clasificación y re c u p e ra c ió n de, 482-484 C o u n se ll, S .J.,4 2 8
c o m p o sic ió n d e , 4 7 4 ,4 7 5 ,4 8 0 -4 8 1 C rite rio s de adaptación, 117
c u alific ac ió n d e, 193 C u e llo s de botella, 505
diseñ o de datos, 240-241 C u e stio n e s de contexto libres, 79-80, 183
de d isp o n ib ilid ad in m e d iata, 8 2 ,4 7 4 C u m p lim ie n to de las estructuras, 278
d istrib u c ió n de, 509 -5 2 0
de D O O , 385-387
e stán d ar, 85 D a to s, 576-577
de ex p erien c ia a g ru p a r d ato s afin es, 505-506
c o m p leta, 82-83 D avis, A ., 27, 1 8 8 ,3 3 1 -3 3 2
p arcial, 4 7 4 ,4 7 5 ,4 7 9 D a v is, M., 31
de gestió n de re cu rso s, 387 D ecisió n h a ce r-co m p rar,9 2 -9 3
de in te rfaz de u su a rio , 386 árbol de d e cisio n es, 93-94
JavaB ean de Sun, 480-481 subcontratació n (o w íío w rd n g ), 94
N , 154 D e fec to s,
n u e v o s, 83 am p liac ió n , 138
reutilizables, 193 im p a c to d el c o ste, 137-138
de riesg o , 100-101 D e finición de o b jeto s, 353
C o m p o sició n , 394 -3 9 5 D eM arco, T .,42^ 1 9 9 ,2 0 0 ,3 3 0 ,3 3 1
C o m presión de datos, 506 D ep en d e n c ia s
C om probación de c u en ta, 370 de c o m p a rtim ie n to , 245
C om putadora d e red , 5 10 flujo de, 245
C o m unicación re stric tiv a s, 245
del clie n te , 46 D e p u rac ió n , 3 18
del e q u ip o , 4 3-44 c o n sid era cio n e s p sic o ló g ic as, 3 1 9
de p ro c eso s, 513 -5 1 4 e n fo q u es, 320-321
en tre su b sistem as, 387-388 p ro c eso , 3 1 9
téc n ica s, 183-184 D e sa rro llo
C oncentrador d e im p re sió n , 43 9-441 b a sa d o e n c o m p o n e n tes (D B C ), 28-29, 478-482, 524
C oncepto d e la h orda m o n g o lia n a, 9 de c o n ce p to s, 25
C o n c isió n , 325 rá p id o de a p lic ac io n e s (D R A ), 22-23
C o n d ició n , 2 7 4 ,2 7 5 del so ftw are, m ate m á tic as, 437
co m p u e sta, 291 de W ebs, 564
de datos, 208 D e sc o m p o sició n , 84
C onectividad, 227 de p ro c eso , 47
C o nfiguración del so ftw are, 10 de p ro d u c to , 45
C o njunto d e tareas, 16, 25, 38 téc n ica s, 85-90
c álcu lo d el v a lo r de selecció n , 117-1 18 D escripción(ones)
d e fin ició n , 116-117 de la in fo rm a ció n , 194
C o n siste n cia , 325 fu n c io n a l, 195
C onstantine, L., 41, 42 de o b jeto s, 388 -3 8 9
C o n stru cció n de siste m a s, 574-575 D e sc u b rim ien to de c o n o cim ie n to e n b a se s de datos
C ontabilidad d el estad o , 159 (D C B C ),2 3 9
www.FreeLibros.org
C ontenido D e sp lieg u e de la fu n c ió n de c alid ad (D F C ), 186-188
e je cu ta b le , 503 -5 0 4 D eu tsch , M., 281
de la in fo rm ació n , 189-190 D evanbu, P., 486
591
ÍNDICE DE MATERIAS
D ham a, H., 334 e n fo q u e c o n v en c io n a l VSP. 0 0 ,3 8 0 -3 8 1

D iagram a(s) e x actitu d , 409
de b u rb u ja s ,206 m éto d o s, 382-383
de c o n te x to d el siste m a (D C S ), 176-177 m étrica s, 4 23-424
de flujo de c o n tro l (D F C ), 208 p irám id e, 380
creació n de, 2 1 3 -2 1 4 p ru e b as, 4 09-410
creació n de, 210-21 1 p lan tilla s, 528
e n tid a d -re la c ió n (D E R ), 2 0 0 ,2 0 4 -2 0 5 p rin cip io s, 2 2 2 -2 2 3 ,5 2 8
de espina, 57 de p ro c ed im ie n to s. V éase D ise ñ o a n ivel de c o m p o n e n tes
de estado, 397 p ro c eso , 221
de flujo de p ru e b a b a sa d a e n e sc en a rio , 4 1 5 -4 1 7
de d ato s (D F D ), 200-201, 206-207, 208 re g la s de oro, 528
crea ció n , 211-213 p a ra la reu tilizacíón, 4 8 1 -4 8 2
d el siste m a (D F S ), 177 d el sistem a, p ro c eso , 384-388
de G an tt, 123 de siste m a s de n e g o cio (D S N ), 170
de tran sició n de e stad o s (D T E ), 1 8 3 ,2 0 9 tip o s de, 220
D iccionario de datos, 2 00, 2 0 6 ,2 1 5 -2 1 6 v isió n g en eral, 5 1 5 -5 1 6
D ijk is tra ,E ., 2 7 3 -2 7 4 D isp o n ib ilid a d , 143
D im ensión, 85 D isp o sitiv o s
cam b io , 85 de d e te cc ió n , 145-146
co m p o n e n te e stán d ar, 85 p o k a -y o k e, 145-146
de co n tro l, 61 D iv isió n e stru ctu ral, 2 2 7 -2 2 8
de datos, 61 D o c u m en tac ió n , 1 6 6 ,2 3 3 ,5 6 2 -5 6 3
fu n c io n a l, 61 p ru e b a d e la, 300
lógica difu sa, 85 D o m in io de la in fo rm a ció n , 189-190
punto de fu n c ió n , 85 v a lo re s, 6 0
D iseño, 2 3 4 ,5 6 3 D ruker, P., 97
a n ivel de co m p o n e n tes, 23 D u n n , R., 321
d e sc rip c ió n , 273 D u p lica ció n , 5 1 5
m étrica s, 333-335 de datos, 505
arq u itec tó n ic o , 2 2 0 ,2 5 6 , 528-530 p a q u e te s d e, 504
a n álisis, 243-245
d e sc rip c ió n , 237
guía c u an tita tiv a p ara, 244-245 E c u a c ió n de so ftw are, 92
m é tric a s del, 3 3 2 -3 3 3 ,3 3 7 E ficacia d e e lim in a c ió n de d e fec to s (E E D ), 64-65
refinam iento del, 255 E fic ien c ia , 325
de siste m a s C /S, 513 -5 1 4 de eje cu c ió n , 325
calidad de, 132 E je de p u n to de e n tra d a del p ro y e cto , 25
d e casos d e prueba, 285, 301 E jogu, L ., 328
en tre c lases, 4 1 7 -4 2 0 E le m en to e scalar, 228
c o n v en c io n a l, 414 E n ca p su lam ien to , 3 4 8 ,4 2 2 -4 2 3 ,4 2 8
so ftw a re O O , 4 12-417 E n crip tac ió n , 507-508
c o n ce p to s de, 223-229 E n cu b rim ie n to de caja
consistencia/uniform idad del, 222 gris, 479
de datos, 2 2 0 ,2 3 9 -2 4 0 n e g ra, 479
a n ivel de co m p o n e n te, 240-241 E n tid a d es, 156
d e sc rip c ió n , 2 1 9 ex tern as, 176
e fectiv o , 229-231 E n to rn o
esp e cific a ció n , 154,233 de d e sa rro llo , 82
ev alu ac ió n , 225 de in g e n ie ría d e l so ftw a re (E lS ), 84
para el fallo , 506 p ro to tip o s d el, 193
fo rm al, 461 E q u ip o
h e u rístic as, 23 1-232 c en traliza d o y c o n tro lad o (C C ), 41
de usuario, 270 de d e sc en traliza d o d e m o c rático , (D D ), 4 1 ,4 2
d e sc rip c ió n , 259 d e sc en traliza d o y c o n tro lad o (D C ),4 1 , 42
ev alu ac ió n , 268-269 de in g en ie ría W eb, 533 -5 3 4
m o d elo s, 262-263 ad m in istrad o r, 534
p ro c e so s, 263 d e sa rro lla d o r d el c o n te n id o , 534
re g la s de oro, 260-261 ed ito r, 534
m éto d o s de, 527-528 e sp e c ia lista de soporte, 534
de n a v eg a ció n , 530-531 in g en ie ro , 534
de o b jeto s, p ro c eso , 388-390 p ro v e ed o re s, 534
o rien tad o a o b jeto s (D O O ), 3 4 4 ,4 0 5 de so ftw are
aproxim ación unificada, 383 -3 8 4 coordinación/com unicación, 4 3 -44
www.FreeLibros.org
asp e cto s, 3 81 -3 8 2 organización/estructura, 40-43
co n sisten c ia, 410-411 E rro re s, 311
d e sc rip c ió n , 379 d e te cc ió n de, 2 9 1 -2 9 2
592
I N D I C E DE MAT ERI AS
E rro re s (C o n t.)
d iseñ o de, 389-391
ló g ic a de, 286 in tern as, 549
tipográficos de, 286
je rá rq u ic a s, 529
E sfu e rz o lin e a le s, 528 -5 2 9
d istrib u c ió n , 115-116
e n red , 529
p e rso n as, 114-116
reticulares, 529
E sp a cio s, 503 E v a lu a c ió n y té c n ic a de re v is ió n d e p ro g ra m a s (E T R P ),
de d iseñ o c u a n tific a d o (E D C ), 245 122-123
n -d im e n sio n a l, 228-229 E x ac titu d , 325
E sp e cific a ció n , 193-195 E x p re s ió n ló g ic a (B o o lea n a), 291 -292
a lg e b raic a, 450-452 E x tra c c ió n m anual, 5 15
de c o n tro l (E C ), 2 0 1 ,2 0 8 ,2 1 3 -2 1 4
de datos, 240-241
d iseñ o , 233 F a c ilid a d de
de la e stru ctu ra de cajas, 4 6 0 -4 6 1 ,4 6 2 a u d ito ría, 325
de estado, 4 6 2 ,4 6 3 -4 6 4 co m p re n sió n , 284
n e g ra, 4 6 2 ,4 6 3 p ru e b a, 325
tran sp are n te , 4 6 2 ,4 6 4
a trib u to s, 284
fo rm al, 193 c ara cte rística s, 2 8 3 -2 8 4
len g u a jes de, 445 F a c to r de
n o tac ió n m ate m á tic a, 444-445 a co p lam ien to (FA ), 4 2 7 -4 2 8
fu n c io n a l, 4 6 2 -4 6 4 h e re n c ia d e m é to d o s (FH M ), 427
p rin cip io s, 194 polim orfism o (F P ), 4 28
de p ro c e so (E P ), 2 0 1 ,2 0 6 -2 0 7 ,2 1 4 -2 1 5 F allo(s), 506
re p re se n tac ió n , 194 del año 2 000, 3, 4
de los re q u isito s d el so ftw are, 194-195 d o b les, 299
del sistem a, 1 7 3 ,1 7 7 m ultim odales, 299
Z , 4 4 6 -4 4 7 sim p les, 2 99
E spiral W IN W IN , 2 6-27 F a se de
E sq u em a d el m o d ela d o del sistem a, 1 7 6 ,1 7 8 d e fin ició n , 15
E stabilidad, 284 d e sa rro llo , 15
E stado d el sistem a, 189 soporte, 15
E stándares de Intern et, 524 ad ap tac ió n , 15
E stan d arizació n de co rre c ció n , 15
la co m u n ic ac ió n , 325 m ejora, 15
d atos, 325 p re v en c ió n , 15
rediseño de datos, 551 F e c h a lím ite, 112-113
E stilos arq u itec tó n ic o s, 2 4 1 -2 4 2 F e ig e n b a u m ,E A ., 4
o rg a n iz a c ió n d e , 243 F e n to n ,N ., 3 2 7 ,3 3 3
refinam iento de, 243 F ia b ilid ad , 80, 1 4 3 ,3 2 4 ,3 2 6
taxonom ía de, 241-243 d isp o n ib ilid ad , 143
E stim ación, 78, 84 m ed id a s, 143
a u to m a tiza d a , 84
F iresm ith, D .G ., 369
basada F irm a d ig ita l, 508
p ro b lem as, 86-87 F le m in g , Q.W ., 125
p ro c e so s, 89 F le x ib ilid a d , 325
eje m p lo b a sa d o e n p ro c eso s, 89-90 F lo ra c, W .A ., 53
e m p írica , 84 F lu jo de
L ín e a s de c ó d ig o (L D C ), 85-88 co n tro l, 208
0 0 ,2 9 9 -3 0 0 d atos, 242
P untos de fu n c ió n (P F ), 86-87, 88
a rq u itec tu ras, 242
E strategia de p ru e b a, 321
c o n tin u o e n el tie m p o , 207
a sp e cto s, 3 09 -3 1 0 d iscreto , 207
d ep u ració n , 318-321
grafo de, 206
p ru e b as, 292-293
e n fo q u e, 306-309
in fo rm a ció n , 189-190
in te g rac ió n , 312-315 m o d elo , 2 0 5 -2 0 9
o rg a n iz ac ió n , 307
tran sac ció n , 246
sistem a, 3 17 -3 1 8 tran sfo rm a ció n , 246
un id ad , 3 10 -3 1 2 F o rm a ció n , 325
v a lid a c ió n , 3 1 6 F ra g m en tac ió n , 274, 515
E structura(s) de F re e d m a n ,D .P ., 137
an álisis d el tra b a jo (EA T), 122 F re e m a n ,P ., 237
datos, 2 2 8 -2 2 9 ,2 3 9 F u n c ió n de
je rá rq u ic a s, 2 2 8 -2 2 9
www.FreeLibros.org
ayuda
la in fo rm a ció n , 189-190 c o m p le m e n ta ria, 267
p ro g ram a , 2 2 6 -2 2 7 ,2 2 9
in teg rad a, 267
593
ÍNDICE DE MATERIAS
F unción (C o n t.) individual, 71

prueba, 300 rangos en m ovim iento (R m ), 70
caracterización, 477 de tiem po, 123-124
com pendio de m ensajes, 508 G rafo, 350
FU R PS , 325-326 de ev o lu ció n , 155, 156
G ran co n o cim ien to del sistem a, 505
G rupo indep en d ien te de prueba (G IP ), 307
G affney, J.E., 62 G uiones de escen ario , 429
G a m m a ,E ., 3 7 9 ,3 9 0
G ane, T., 200
G arantía de la calidad del softw are (S Q A ), 148
actividades, 136 Fiabilidad de codificar, 279
antecedentes, 135-136 E la lstea d ,M ., 337
definición, 135 Elam mer, M ., 5, 541, 542
descripción, 131-132 E lardw are, 5, 166
estadística, 141-142 H ares, J.S., 170
plan, 147 E larrison, R., 428
G arlan, D., 2 2 6 ,2 3 8 Elatley, D .J., 208
G ause, D .C ., 79 -8 0 , 183 E lenderson, J., 460
G C I, 785 fíen ry , S., 333
G eneración de H e ren c ia, 3 4 8 -3 4 9 ,4 2 3 ,4 2 9
código, 461 m últiple, 349
una aplicación, 22 H erram ientas, 14
G eneradores de pantallas, 564 capa, 567
G eneralidad, 325 din ám ico , 564
G eneralización, 394 estático , 564
G estión de d esarro llo , 564
de la configuración del softw are (G C S), 159-160 de gestión ,5 6 2
categorías, 152 de p ru e b as, 565
descripción, 151 de im p lem en tació n , 268
elem entos, 78 de pro g ram ació n , 564
identificación de objetos, 154-155 tax o n o m ía, 561-565
IW eb, 536-537 H erró n , R ., 574
líneas base, 152-153 H e tze l, W ., 301
proceso, 154 H inchley, M .G ., 455
de program as relacionada con el personal, 50 H indley, P.G., 476
de proyectos, 5 3 4 -5 3 5 ,5 6 2 H opper, M ., 573
basada en m étricas, 50 H um phrey, W., 56, 125
descripción, 37 H u tc h in so n , J.W., 476
expectación/rendim iento, 536
inicio de un proyecto, 535
personal, 38
proceso, 38 Identificación de
producto, 38 objetos
proyecto, 39 básicos, 154
de riesgos form al, 49 co m p u esta, 154
total de calidad (G T C ), 135 req u isito s, 183-188
atarim ae hinshitsu, 135 inicio del pro ceso , 183-184
kaizen, 135 In certid u m b re e stru ctu ral, 78
m iryokuteki hinshitsu, 135 In c o m p letitu d , 437
G estor(es) In d ep en d en cia
de bloques, 4 3 9 ,4 4 4 -4 4 5 fu n cio n al, 229 -2 3 0
superiores, 39 del h ard w are, 325
(técnico) de proyectos, 39 In d icad o res de pro ceso , 55
G ilb, T., 309 Indice de
G lass, R „ 332 errores (IE ), 142
G naho, C , 530 especialización (IE ), 427
G oethert, W .B., 53 espectro, 244
G ooldm an, N., 194 In fo rm ac ió n , 576-577
G rado de rigor, 1 17 Inform e de
casu al, 117 c am bio, 157
estricto , 117 e stado de configuración, 159
estructurado, 117 Ingeniería, 25, 45-46
reacción ráp id a, 117 del softw are basada en com p o n en tes (ISB C ), 486
www.FreeLibros.org
G rady, R .G ., 56, 57, 65 actividades, 474-475
G ráfico(s) de d escrip ció n , 4 73-474
control, 70 eco n ó m ica de, 484 -4 8 6
594
ÍNDICE DE MATERIAS
In g e n ie ría (C o n t.) ob jeto , 2 6 5 -2 6 6 ,5 1 5 -5 1 6

p ro c e so , 475 re d u c ir la c arg a d e m e m o ria del usu ario , 260-261
de c o m p o n e n tes d el sistem a, 171 de usuario, 550, 552-553
d irecta, 547, 55 1-552 In tern et, 3
a rq u itec tu ra 0 0 , 5 5 3 In tero p e rab ilid a d , 32.5
cliente/servidor, 552-553 Invariante de datos, 438
in te rfac e s de u su a rio , 553-554 ISO
del d o m in io , 362, 366, 476-478 9 0 0 0 -3 , 146
de in fo rm a ció n , 20 9 001, 146-147
in v ersa, 5 4 6 ,5 4 7 -5 4 8 9 0 0 4 -2 , 146
d atos, 549 -5 5 0 9 1 2 6 ,3 2 6
in te rfaz de u su a rio , 550 Ite ra c ió n del d iseñ o de p ro c eso s, 516
p ro c esa m ie n to , 548 -5 4 9
de p ro c e so de n egocio (IPN ), 1 6 9 -1 7 0 ,1 7 8 ,5 6 1 -5 6 2
de p ro d u c to , 171, 178 Ja c k m a n , M ., 42
de re q u isito s, 1 7 1 ,1 7 2 Jack so n , M .A ., 2 2 3 ,2 2 7
a n álisis, 173 Jaco b so n , I., 1 8 7 ,3 6 2 , 382
esp e cific a ció n , 173 Jerarquía(s) de
gestió n , 174-175 clases, 416
id en tific ac ió n , 172 co n tro l, 2 2 6 -2 2 7
m o d ela d o , 174 tip o s de o b jeto s de datos, 204
ne g o ciac io n es, 173 Ju e g o de h e rra m ie n tas de la in te rfaz de u su a rio , 268
v a lid a c ió n , 174
de sala lim p ia, 2 9 ,4 6 9
c ara cte rística s, 461 K a fu ra ,D „ 333
d e fin ició n , 3, 14 K ahn, R , 528
d e sc rip c ió n , 45 9 K a ize n , 135
en fo q u e, 460-462 K ang, K .C ., 172
estrateg ia , 460-461 K a p ln , C., 134
fu tu ro , 573-579 K a u tz, K ., 72
im p o rta n cia, 574 K id d , J., 3 5 6 ,4 2 6 ,4 2 7
p a rad ig m a , 19 K ira n i, S., 418
p ro c e so n u e v o , 575-576 K it de D e sa rro llo B ean (B D K ), 481
p ru e b as, 467-469 K o p p le m a n , J.M ., 125
siste m a s C /S, 512 K ra u l, R., 44
v isió n g e n érica , 14-16
de seg u rid ad , 507
de sistem as, 178 L año, K., 549
d e sc rip c ió n , 165 L arc h er,F ., 530
je ra rq u ía , 167-169 L aten c ia, 506
del so ftw are, 7 L egibilidad p a ra la co m p u ta d o ra , 278
a sistid a p o r c o m p u ta d o ra (C A S E ), 9, 14 L enguaje(s)
b loques de c o n stru c c ió n ,560-561 de d e sc rip c ió n a rquitectónica(L D A s), 226
d e sc rip c ió n , 559 de d iseñ o de p ro g ra m a s (L D P ), 276-277
tax o n o m ía, 561 -565 e je m p lo , 277-278
W eb (IW eb), 537-538 de in te rc o n e x ió n de m ó d u lo s (L IM ), 155
a trib u to s, 522-524 e stru ctu rad o . V éase L e n g u a je de d iseñ o de p ro g ra m a s (L D P )
d e sc rip c ió n , 521 -522 unificado d e m odelado (U M L ), 2 9 ,3 6 3 -3 6 4 ,3 8 3 -3 8 4 ,3 9 3 -3 97
e stim a ció n , 5 3 4 -5 3 5 ,5 3 6 e stu d io de u n caso, 398 -4 0 0
m arco de trab a jo , 525-526 L eveson, N .G ., 144
p ro b le m a s de g estió n , 533-537 L e v y ,J., 336
p ro c eso , 525 L ib ro s e n línea, 398-400
subcontratación(oMíJOMrc-mg), 5 3 4 ,5 3 5 -5 3 6 L id e raz g o
In sp ecció n . Véase R e v isio n e s técnicas fo rm ales (R T F) c ara cte rística s, 40
In sta n tá n ea , 5 1 5 ra sg o s, 40
In stitu to de In g e n ie ría d el S oftw are (SEI), 1 6 ,1 8 ,1 3 6 L ím ite d el p ro c e so n a tu ra l
lib ro de guía, 73 -7 4 in ferio r, 71
In stru m en tac ió n , 325 superior, 71
In teg ra ció n , 564 L ín e a s de c ó d ig o (L D C ), 58, 62-63
In teg rid ad , 64 e je m p lo d e estim a ció n , 87-88
In terfa z e stim a ció n , 86-87
a cc ió n , 2 65-266 L in g e r, R .M ., 4 6 5 ,4 6 6
c o n stru c c ió n c o n sisten te , 261 L íster, T., 42
d a r el co n tro l al u su a rio , 260 L o ca liz ac ió n , 422
d iseñ o , 220, 266-268, 5 3 1 -5 3 2 ,5 6 4
www.FreeLibros.org
L ó g ica e n tie m p o re al, 144
gráfica de usuario (IG U ), p ru e b as, 2 9 9 -3 0 0 L o ren z , M ., 3 5 6 -3 5 7 ,4 2 6 ,4 2 7
h o m b re-m áq u in a , 337 L o w e , D ., 523
595
In d i c e de materias
M A C A , 244 desarro llo , 67, 69-70

M adurez del proceso, 16-18 de diseño 0 0 ,4 2 3 - 4 2 4
definición, 16-17 e stab lecim ien to de p rogram as para, 72-74
gestionada, 17 e tiqueta, 56
inicial, 17 evaluación, 66
optim ización, 17 de integración con objetos, 66
repetible, 17 línea b ase, 66
M andel, T., 260-261 de m an ten im ien to , 338
M antei, M ., 41 del m odelo
M antenibilidad (capacidad de m antenim iento), 6 4 ,2 7 8 ,3 2 5 ,3 2 6 de an álisis, 329-336
M antenim iento, 3 3 8 ,5 4 4 -5 4 5 de diseño, 332-336
M arco de proceso com ún, 16 de organizaciones peq u eñ as, 72
0 0 ,3 5 5 - 3 5 6 orien tad as a
M atem áticas, 4 37, 441 clases, 424-428
aplicación, 444-445 funciones, 59-61
conjuntos, 4 4 1 -4 4 2 objetos
especificación constructiva, 441-442 características, 422-423
sucesiones, 443 descrip ció n , 421
M atrices de g rafo s, 290 propósito, 422
M cC abe, T.J., 335 op eracio n es, 428
M cC all, J.A ., 324-325, 326 tam añ o , 59
M cC orduck, P., 4 privadas, 56
M cG laughlin, R., 221 d e pro ceso , 55-57, 69-70
M cM ahon, P.E., 478 de producto, 58
M edición, 69, 74 de p ro y ecto (s), 58-59
calidad, 63-65 0 0 ,3 5 6 - 3 5 7 ,4 2 8 - 4 3 0
definición, 53, 54 de prueba, 337
descripción, 323-324 públicas, 56
directa, 58 punto de función am p liad o , 61-62
indirecta, 58 reconciliación de diferentes en fo q u es, 62-63
principios, 328 de reutílízacíón, 486
razones, 53 de softw are sencillo, 72
M edida, d escrip ció n , 54 técn icas, 43
M ejora m arco de trabajo, 327-329
estadística del p roceso de softw are (M E P S ), 56-57 reto de, 327
del proceso del softw are, 55-57 de validez e stad ística, 70-72
M ellor, S„ 207 M eyer, B., 225
M ensajes, 347-348 M ilier, E ., 306
de error, 267-268 M ills, H .D ., 460
M erlo, E., 554 M itig a c ió n , m o n itorización y gestión del riesgo (M M G R ), 102,
M étodo(s), 14,347 1 0 5 -1 0 6 ,1 0 7
del cam ino crítico (M C C ), 122-123 M ito s, 8
form ales, 456 de clien tes, 9-10
basados en objetos, 447-450 de desarrolladores, 10
conceptos básicos, 436-441 de gestión, 9
concurrentes, 452-455 M odalidad, 203
descripción, 435 M o d elad o , 190
los diez m andam ientos de, 4 55-456 de análisis, 5 1 2
fu tu ro , 456 actividades del, 171
m odelo, 29 d escrip ció n del, 199
prelim inares m atem áticos, 441-443 elem en to s del, 200-201
ponderados por clase (M P C ), 425 del co m p o rtam ien to , 209-210
M étrica(s), 1 7 ,4 2 6 -4 2 7 de datos, 22, 154, 189
acoplam iento, 334-335 cardinalidad, 203
de argum entos a favor, 65-66 e lem en to s, 201-203
atributos, 328-329 m od alid ad , 203 -2 0 4
bang, 3 3 0 -3 3 1 ,3 3 7 representación gráfica, 204-205
cálculo, 331 e stru ctu ral, 3 6 3 ,4 7 7 -4 7 8
basadas en funciones, 329-330 fun cio n al, 190
cálculo, 66 del negocio, 22
de calidad, 63-65 de procesos, 2 2 ,5 6 2
de especificaciones, 331-332 del sistem a, 167-168, 174, 175-177
de código fu en te, 336-337 lim itaciones, 168
de cohesión, 334 preferencias, 168
de colección, 66
www.FreeLibros.org
restricciones, 168
co m p lejid ad , 335 sim plificaciones, 168
definición, 53, 54 supuestos, 167-168
596
ÍN D I C E DE MAT ERIAS
M odelo(s) d escendientes (N D D ),4 2 5 ,4 2 9

d e análisis, 21 escenarios (N E ),4 2 9
particio n ar e l, 384-385 operaciones
d e caos, 19 a ñadidas p o r una subclase (N O A ), 4 2 7
d e clases, 393-394 red efm id asp ara una subclase (Ñ O R ), 427
de com portam iento, 190 padres directos (N P D ),4 2 9
pruebas, 419 -4 2 0 parám etros p o r o p eración prom edio (N P ), 428
U M L , 363-364 subsistem as (N S U B ), 430
dinám icos, 226
de diseño, 222, 233
de estim ación O bjetivo, pregunta, m étrica (O P M ), 67 -6 9
C O C O M O , 9 1 -9 2 aplicación, 68-69
e m píricos, 90-92 entorno, 68-69
estructura, 90 perspectiva, 68-69
estructurales, 226 propósito, 67
fundam ental del sistem a, 206 O bjetivos
d e im plem entación, 364 del ciclo d e vida (O C V ), 27
de intercam bio d e datos, 480 de las pruebas, 282
de m adurez d e capacidad (M C M ), 16-17 O bjeto
del m arco d e trabajo, 226 de aplicación, 5 1 6
M O I, 40 de d a to s asociativo, 205
de objetos, 480 Z, 447-450
id entificación de elem entos, 350-354 O bjetos, 346
com portam iento, 374-376 d e datos, 201-202
relación, 373-374 distribuidos, 502-503
recursivo paralelo, 344-345 identificación, 350-352
de proceso(s), 19,226 O bservabilidad, 283
de pro totipos, 2 1-22 O cultam iento d e inform ación, 2 2 9 ,4 2 3
D R A , 22-23 O M G /C O R B A , 480
evolutivo, 23-28 O peración dibujo, 3.50
desarrollo concurrente, 27-28 O peraciones, 3 4 7 ,4 3 8
e spiral W IN W IN , 26-27 definición, 353-354
espirales, 24-26 m étricas, 428
increm éntales, 23-24 O peradores m atem áticos
secuencial lineal, 20-21 de conjuntos, 442-443
de red es de P etri, 144 lógicos, 443
catarata. Véase M odelo de proceso secuencial lineal O peratividad, 283, 325
de usuario, 363 O rden de cam bio de in geniería (O C I), 157-158
M odularidad, 2 2 4 -2 2 5 ,2 7 8 , 325 O rientación a objetos ( 0 0 ) 3 5 8 - 3 5 9
M ódulos arquitectura, 553
d e trabajador, 227-228 conceptos de, 345-350
eficaces, 23 1-232 descripción de, 343
M onarchi, D :E ., 366 enfoque p a ra p lanificación, 357-358
M on ito res d e transacciones, 504 estim ación, 356-358
M usa, J.D ., 308 gestió n d e p royectos, 354-358
M y e rs,G ., 234 m étricas d e proyecto, 3 5 6 -3 5 7 ,4 2 9 -4 3 0
M yers, W ., 80 paradigm a, 344-345
seguim iento del progreso, 358
O riginalidad, 424
N aisb itt, J., 4 O sb o m e, A ., 4
N annard, M ., 527 O sb o m e, W .M ., 544
N egociación, 26, 173 O tt, L .M ., 334
N ielsen , J., 336
Nithi, R.V., 428
N ivel de Page-Jones, M ., 3 7 ,2 0 0
clase, prueba, 417-4 18 P aquetes
referen cia del riesgo, 103 clien te/serv id o r (C /S), 504
N o tació n de seguridad, 504
de diseño P arad ig m a/ s)
com paración, 278-279 abiertos, 42
gráfica, 274-276 aleatorios, 41
tabular, 3 9 0 ,5 2 7 -5 2 8 ,5 3 0 cerrados, 41
de grafo de flujo, 2 86-287 de m ejo ra d e calidad, 67
N úm ero de síncronos, 42
clases clave P aralelism o, 506
www.FreeLibros.org
(N C C ), 429-430 P ark, R .E., 53
(N C R ), 429 Partición. 190-191
597
ÍNDICE DE MATERIAS
Partición (C o n t.) e fectiv id ad . 283

basada en atributos, 418 exh au stiv o s. 283
basada en categorías, 4 1 8 de m enor a m ayor. 283
basadas en estad o s, 418 de P a re to , 283
equivalente. 296-297 planificación. 283
pruebas, 417 -4 1 8 Seguim iento hasta los requisitos del cliente, 282
Participantes, 183 W 5H H . 49
Partidario. 39 P R O /S IM , 563
Patrones de diseñ o , 3 9 0 ,5 2 8 ,5 3 0 P roblem as
ciclo, 530 de alcan ce, 172
contorno, 530 de co m p ren sió n . 172
contrapunto, 530 volatilidad, 172
descripción, 390-391 P rocedim iento(s), 166
filtro. 392-393 de softw are, 229
futuro. 393 P ro c e sam ien to
M em ento, 391-392 central (ho st), 492-493
m undo de esp ejo , 530 de datos, 189
S ingleton, 391 P roceso(s), 14, 38
tam iz, 530 au to m ático , 278
vecindario, 530 características, 16
P eligros. 106 d e c o m p ro b ació n de e n tra d a y salida, 158
P ersonal, 38. 166. 5 3 7 ,5 7 4 -5 7 5 de d esarro llo de softw are unificado, 29
equipo de softw are, 40-43 d esco m p o sició n , 47
je fe s de e quipo, 4 0 d escrip ció n , 13
participantes, 39 indicador, 55
P etición de cam bio, 156 integración con m étricas, 65-66
Phadke, M .S., 298, 299 secuenciales intercom unicados (PS I), 452-455
Phillips,D „ 86 de softw are personal, 56
Pirbhai, I.A ., 208 P ro d u c tiv id a d , 485
Planificación. 25 P ro d u c to , 31, 38
de contingencia, 105-106 ám bito, 4 4-45
de la com probación estadística, 461 d esco m p o sició n . 45
de la estrategia de inform ación, (P E I), 170 Program ación
de increm entos. 460 e stru ctu rad a, 274-278
de proyectos, 127 orien tad a a objetos (P O O ). 3 4 4 .4 0 0 -4 0 3
decisión hacer-com prar, 92-94 im p acto en pruebas. 414-415
descom posición, 85-90 P ro g ram as legales, 16
descripción, 77 P rotocolo(s), 497
estim ació n , 84 co n cep to s, 498
herram ientas de estim ación autom atizadas, 94-95 H T T P, 4 99
m odelos de estim ación em píricos, 90-92 ICM P, 498
objetivos, 79 IP, 498
recursos, 82-83 PO P3, 498
N N G R , 107 de presentación, 567
en tiem po Prototipo(s), 21-22. 1 9 2 .5 4 3 ,5 6 4
conceptos básicos, 112-114 desech ab les, 193
desarrollo. 536 entornos, 193
descripción. 111 ev o lu cio n ario , 193
detallada. 1 13 e v o lu tiv o , 193
estim ación. 49 h erram ien tas, 193
herram ientas/técnicas, 122-125 m éto d o s, 193
líneas generales, 114 selección de e nfoque. 158
m acroscópico, 113 P ro y e c ció n del riesg o , 101
OO , 357-358 evaluación del im pacto, 103
relación personal/esfuerzo, 114-116 tabla, 101-103
riesgo, 100 Proyecto) s)
seguim iento, 124 co m p le jid ad , 78
P olim orfism o. 349-350 desarro llo de aplicaciones nuevas, 1 16
P ollak, W .,4 7 7 de desarro llo de co n cep to s, 116, 119
P orcentaje público y protegido (P P P ),4 2 9 ám bito, 119
Portabilidad. 325. 326 evaluación de riesgos de la tecnología, 119
Pow ell. T.A.. 522 im p lem en tació n . 119
P ráctica de so ftw are crítico. 4 9 -50 planificación prelim inar, 119
P ressm an, R., 574 prueba, 119
P rieto-D íaz, R., 476
www.FreeLibros.org
reacción del cliente. 119
P rincipio(s) enfo q u e, 48
de las pruebas, 282-283 indicador, 55
598
ÍNDIC E DE MATERIAS
Proyecto(s) (C o n t.)
de re c u p e rac ió n , 317
m an te n im ien to de a p lic ac io n e s, 116 de re n d im ien to , 318
m ejo ra s de a p lic ac io n e s, 116
d e re siste n c ia (estrés), 318
p lan ifica ció n , 49
de seg u rid ad , 317-318
re in g e n ie n a , 116
d el sistem a, 301, 317
tam a ñ o , 78
d e le g a c ió n de c u lp a b ilid ad , 317
Prueba(s), 5 1 6 ,5 6 4
re c u p e rac ió n , 3 17
a n ivel de clase, 417-418
re n d im ien to , 3 1 8
de a g ru p a m ie n to ,4 1 1
re siste n c ia (estrés), 318
alfa, 3 1 6
seg u rid ad , 317-318
basada(s) en,
e n tie m p o re al, 300-301
esc en a rio s, 415-417
del so ftw are
fa llo s, 4 14-415
d e sc rip c ió n , 2 8 1 -2 8 2
grafo s, 2 9 4 -2 9 6
fu n d a m e n to s, 2 82-284
h ilo s, 4 1 3 ,4 2 0
de la ta b la ortogonal, 298-299
usos, 412
tá c tic a s C /S, 5 1 8
b eta, 293
en tre tare as, 301
de b u c le s, 294
de tran sac cio n e s, 5 1 7
a n id a d o s, 294
de u n id ad , 307-308
c o n ca te n a d o s, 294
c o n sid era cio n e s, 310-311
no e stru ctu rad o s, 294
c o n tex to 0 0 , 4 1 0 - 4 1 1
sim p les, 293
p ro c ed im ie n to s, 311-312
de la caja
de v a lid a c ió n , 3 1 6
b lan c a, 2 8 5 ,2 8 6
alfa y b e ta , 3 1 6
n e g ra, 2 9 4 -2 9 9 ,3 0 2
c o n te x to 0 0 , 4 1 1
de c am in o b a se , 286
criterio s, 3 1 6
de c iclo rá p id o , 309 -3 1 0
rev isió n de co n fig u ra ció n , 3 1 6
de cla se m ú ltip le , 4 18 -4 1 9
P seu d o c ó d ig o . V éase L e n g u a je d e d iseñ o de p ro g ra m a s (L D P )
cliente/servidor, 300 P uhr, G .I., 366
de co m p a rac ió n , 2 9 7 -2 9 8 Puntos
de co m p o rtam ien to , 301
de c ara cte rística s, 61
de c o m u n ic a c ió n d e re d es, 517-51 8
de estru ctu ra, 4 7 7 -4 7 8 ,4 8 5 -4 8 6
de c o n d ic ió n , 2 9 1 -2 9 2
de fijación, 26
criterios p a ra c o m p le ta r, 3 08 -3 0 9
de fu n c ió n (P F ), 6 0 -6 1 , 85
d o c u m e n tac ió n , 300
a m p liad o s, 6 1 -62
del d o m in io , 291
eje m p lo de estim a ció n , 88
y en treg a, 23
estim a ció n , 86-87
e stad ística de caso s p rá ctic o s, 4 6 7 -4 6 8
tres d im e n sio n e s,
de e strateg ia C /S, 516-517
P u tn a m ,L ., 80
e stru ctu ra
de co n tro l, 2 9 1 -2 9 4
p ro fu n d a, 4 17
R a cc o o n , L.B.S., 19
de su p e rfic ie ,4 1 7
R eco lecció n de re q u isito s, 460
fa cilid a d es de ay u d a, 300
R e cu rso s
de fu nción de la a p lic ac ió n , 5 1 7
de e n to rn o , 83
herram ientas C /S, 565
h u m an o s, 82
IG U , 2 9 9 -3 0 0
R e d de tare as, 121-122
im p a c to de la p ro g ra m a c ió n 0 0 , 4 1 5 R ediseño de datos, 551
de in te g rac ió n , 312,413,420
R eel, J.S., 48
a sc en d e n te , 313-314
R e e s tru c tu ra c ió n d e , 550-551
c o n tex to 0 0 , 4 1 3
c ó d ig o , 5 4 6 ,5 5 0 -5 5 1
desc en d e n te , 312-313
datos, 5 4 6 -5 4 7 ,5 5 1
estu d io , 315
d o cu m e n to s, 546
h u m o , 3 1 4 -3 1 5
R e fin a m ie n to ,224, 464-465
re g re sió n , 314
p a so a p a so , 224
de lím ite s, 3 11
R egión(ones) de
de m an o a m an o , 298
d efecto s, 298
m étrica s, 337
tare as, 26
m odelo de
R e g la 90-90, 48
AOO, 409-410 R e g la (C o n t.)
D O O , 409-410
de z o n a, 71
del o p e rad o r relacional y de ram ificació n (B R O ), 292
R eifer., D .J., 181
o rien tad a s a o b jeto s (O O ), 4 0 9 -4 1 9 ,4 2 0
R e in g e n iería
c o ste-b e n efic io , 554
e strateg ia s, 412
d e sc rip c ió n , 541-542
www.FreeLibros.org
m étrica s, 4 28-429
e co n o m ía de la, 554
de ra m ifica cio n es, 291
h e rra m ie n tas, 565
599
ÍNDICE DE MATERIAS
R eingeniería (C ont.) S arson, C ., 200

del proceso de n egocio (R PN ), Saw yer, P , 172
creación de prototipos, 543 Sears, A ., 335
definición del negocio, 543 S eg u im ien to
d escrip ció n , 542 de d efectos, 5 0
especificación y diseño de procesos, 543 de errores, 126-127
evaluación de procesos, 543 para gan ar valores, 50
identificación de p ro ceso s, 543 de requisitos, 562
m o d elo , 543 S eguridad, 1 4 4 ,3 2 5 ,5 2 4
principios, 542-543 de calidad e stad ística , 141 -1 4 2
refinam iento e instanciación, 543 Serie de m étricas C K , 425-430
del softw are, 5 4 4-545, 555 S e rv icio s, 347
m odelo de procesos, 545-547 de gestión de herram ientas (SGH), 567
R elaciones, 2 0 2 -2 0 3 ,2 9 6 Servidor(ores). V éase tam bién S istem as clien te/serv id o r (C/S)
reflexivas, 296 de aplicación, 494
R epetición, 274-275 de archivos, 493
R epresentación de de bases de datos, 4 9 3 ,5 0 1 -5 0 2
d atos, 278 de co n feren cia, 501
estados, 375-376 de co rreo , 4 9 4 ,5 0 1
R equisitos ded icad o s, 506
directrices de representación, 194 de im presión, 494
esperados, 186 de m o n ito rizació n , 502
innovadores, 186 de objeto , 494
norm ales, 186 pesado, 509
R esolución de problem as, de gestión, 4 0 de softw are de grupo, 493-494
R esponsabilidades, 368, 369-370 W eb, 4 9 4 ,5 0 1
R espuesta para una clase (R PC ), 426 Shaw , M ., 2 2 6 ,2 3 8
R eusabilidad (capacidad de reutilización), 82-83, 325 S hepperd, M .J.,4 2 5
R eutilización, 3 6 4 ,4 8 2 -4 8 4 S hingo, S , 145
apro v ech am ien to de, 486 S hneiderm an, B ., 259
de com ponentes, 482 -4 8 4 S hoom an, M.L., 305
e conom ía, 484-485 S im etría, 296
entorno, 484 S im ilitud, 424
m étricas, 486 S im plicidad, 2 84, 325
R evisión(ones) S im ulación del sistem a, 168
de configuración, 3 16 Sistem a(s)
estructurada véase. R evisiones técnicas form ales (RTF) basados en W eb
técnicas form ales (R T F), 10, 137 an álisis, 527
co n stru cció n , 310 form u lació n , 526-527
descripción, 138-139 de bases de datos orien tad o s a objeto s (SBDOO), 344
directrices, 140-141 de clasificación de cinta transportadora (SC C T ), 81, 176-177
inform e, 140 clien te/serv id o r (C /S), 27, 5 18. V éase tam bién servidores
registro, 140 categorías, 493 -4 9 4
reunión, 139 com p o n en tes softw are, 5 0 9 -5 1 2
utilización, 310 d escrip ció n , 4 9 1
R iesgo \
diseñ o , 513-5 16
análisis, 25, 46, 107, 562 en lazad o , 511
características, 98 ingeniería del softw are, 5 12
co m p o n en tes, 100-101 m odelos, 492-493
conocido, 99 p ru eb as, 300, 5 18,5 6 5
controladores, 100-101 co m p lejo s, 166
definición, 97 de desarro llo de la interfaz de usuario (S D IU ), 268
estim ación, 101-104 definición, 166
evaluación, 100-101, 103-104 d istrib u id o s, 492-497
de la tecnología, 119 com p artim en to de recursos, 492
identificación, 99-101 diseño de, 504
negocio, 98-99 ren d im ien to , 492
proyecto, 98 tolerancia a fallos, 492
reactivo frente a proactivo, 98 de tiem p o real, 207
refinam iento, 104 extensiones
seguridad, 106 H atley/P irbhai, 208 -2 0 9
del soporte, 101 W ard/M ellor, 207 -2 0 8
R issm an, M .,4 7 7 pru eb as, 300-301
R obinson, H., 145 S itara n u P ., 27
www.FreeLibros.org
R oche, J.M ., 328 S obrecarga, 350
R oss, D., 200 So ckets (C o n ex io n es), 502
R um b au g h , J., 3 6 2 ,3 6 6 ,3 7 3 ,3 8 2 ,3 8 7 S oftw are, 166
600
ÍNDICE DE MATERIAS
S oftw are (C o n t.) T écnica(s)

a p lic ac ió n , 5 14 de c u arta g en era ció n , 30, 193
a p lic ac io n e s, 6-8 de m o d ela d o d e o b jeto s (T M O ), 382
b a sa d o e n W eb, 8 p a ra fa c ilita r las e sp e c ific a c io n e sd e la a p lic a c ió n (T F E A ),
c alid ad , 221 80, 184 -1 8 6 (1 1 .2 .2 .)
c ara cte rística s, 4-6 T ecnología(s), 506, 577 -5 7 8
c ie n tífico , 8 in frae stru ctu ra , 231
de c o m p u ta d o ra p e rso n al, 8 de o b jeto s, 28
de sa rro llo , 5 d el p r o c e s o ,31, 38
d e sc rip c ió n , 3 T iem po
crisis en, 8 m ed io de fallo (T M D F ), 143
c u rv as de fallo s, 6 de re sp u e sta d el sistem a, 267
de d e te rio ro , 5-6 T illm a n n , G ., 203
ensam blador, 6 Toffler, A ., 4
e v o lu c ió n del d iseñ o , 221 T olerancia al error, 325
h isto ria , 4-6 T oxinas d el e q u ip o , 43
in sertad o , 7 T ran sm isió n , 504
interm edio(m i¿W /evrare), 494-495, 509, 5 11-512 T raz ab ilid a d , 325
e jem p lo , 495 tab la s, 175
de in te lig e n cia a rtificial, 7 Tsai, W .T .,4 1 8
de n e g o cio , 6
de p ru e b a de erro res, 145-146
Q uality E n g in e erin g (S Q E ), 564 U llm a n ,R „ 321
de sistem a, 6, 563 U sabilidad, 6 4 ,3 2 6
e n tie m p o re al, 6 U suario final, 39
Som m erville, L ., 172
S treeter,L ., 44
Subclase, 346 V aguedaz, 437
Subcontratación(oM íio«rci«g), 94, 5 3 4 ,5 3 5 V alidación, 306
Subsistem as, 3 8 7 -3 8 8 ,4 3 0 c riterio s, 195
a p lic a c ió n ,509, 5 10-511 re q u isito s, 174
a sig n ac ió n , 385 V alor de se lec ció n del c o n ju n to de tareas, cálcu lo , 117-1 18
enlazado de so ftw are C /S, 5 11 in te rp reta ció n , 119
gestió n de b ases de datos, 509 Van V leck , T., 320
interacción/presentación de u su a rio , 509 V ariabilidad, 267
Sucesión, 2 7 4 ,2 7 5 V ariantes, 155-155
S uficiencia, 424 V erificación, 3 0 6 ,4 6 4 -4 6 7
Superclase, 346 de c o rre c ció n , 461
de lóg ica, 278
Tabla de V isib ilid a d , 424
activación de p ro c eso s, 209 V isión e sen cial, 191-192
d ecisió n , 276 V ista
sím b o lo s, 438-439 del e n to rn o , 364
Tai, K.C., 292 de im p le m e n tac ió n , 191-192
Talbot, S„ 4 V olatilidad, 424
T am año
clase (T C ), 4 2 6 -4 2 7 W ard, P.T., 207
m edio de o p e ra c ió n (T O medjo), 528 W am ier-O rr, J., 227
T areas W asserm an, A ., 223
de ad ap tac ió n , 25 W qinberg, G .M ., 7 9 , 1 3 7 ,1 8 3
a sig n a c ió n de tie m p o , 114 W einberg, J., 4 0
co m p artim entalización, 114 W h itm ire ,S ., 423
co n cu rre n te s, 385 W ilk e n s,T .T ., 125
de co n stru cc ió n , 25 W irf-B ro c k ,R „ 363, 369, 370, 382
hitos d e fin id o s, 114 W irth, N ., 224
in te rd ep e n d e n cia, 114
p roductos d e fin id o s, 114
p ru e b a, 300-301 Y ourdon, E ., 4, 3 11, 346, 352, 3 6 2 -3 6 3 ,3 8 2 -3 8 6 , 387
re fin a m ie n to , 120-121
re sp o n sa b ilid ad e s d e fin id as, 114
selecció n , 119-120 Z h a o ,J „ 245
v a lid a c ió n de esfu erz o , 114 Z ultner, R., 70
Q uinta edición
enfoque práctico
r S. PRESSMAN
estud ian d o Ingeniería de! S oftw are? ¿Necesita un lib ro de texto?

iería del Software. Un enfoque práctico es el lib ro ideal para ap o ya r sus estudios dada
eriencia con la que cuenta. En esta quinta edición se ha realizado una revisión com pleta
njeto de re fle ja r las prácticas m ás actuales de la ingeniería del so ftw a re . Se ha in clu id o
ial sobre com e rcio electrónico, Java y UM L, y m aterias tales co m o fo rm u la c ió n , análisis
ibas de aplicacion es W eb en un ca p ítu lo nuevo sobre ingenie ría W eb.
adaptación especial realizada por Darrel Ince, este es el libro ideal para estudiantes de
ería del software y de electrónica. También resultará un libro atrayente para profesionales de
ria que buscan tener una buena guía dentro de la ingeniería del software.
terísticas clave:
la s ve rsiones de Java y UML.
m iento más am plio de sistemas distribuidos incluyendo seguridad y com ercio electrónico.
nen de! e n to rn o W eb y sus im p lica cio n e s en la ingeniería de! softw are.
ros estudios de casos y ejem plos para dem o stra r la puesta en práctica de esta teoría.
la nueva página W eb de Pressm an h ttp ://w w w .p re s s m a n 5 .c o m para o b te n e r más
la c ió n acerca de:
s de estudio,
dios de casos.
(pregunta s m ás frecuentes),
untas de opció n m ú ltip le ,
rencias a otras info rm acio ne s.
S.Pressman es una a utoridad de reconocido prestigio internacional en el desarrollo de m ejoras
del proceso del software y en tecnologías de ingeniería del software. Actualmente, es el presidente
ssman & Associates, Inc., una consultoría especializada en prácticas de ingeniería del software.
Ince es profesor de Inform ática en la Open U niversity y a u to r de una am plia bibliografía.
www.FreeLibros.org
9788448132149

Ingeniería Del Software, 5ta Edición - Roger S. PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ingeniería Del Software, 5ta Edición - Roger S. PDF

Caricato da

Copyright:

Formati disponibili

www.FreeLibros.

G erardo Quiroz V ieyra

D ep a rta m en to de L e n g u a jes y S istem a s Info rm á tico s e Ingeniería d e l S oftw are

Jorge A. Torres Jiménez

D ep a rta m en to de L e n g u a jes y S istem a s Info rm á tico s e In geniería d e l Softw are

DIRECCIÓN, COORDINACIÓN Y REVISIÓN TÉCNICA

D E R E C H O S RESERVADOS © 2002, respecto a la quinta edición en español, por

T raducido de la quinta edición en inglés de

C o p y rig h t© M M E by The M cG raw -H ill C om panies

E ditora: C oncepción Fem ández M adrid

PARTE PRIMERA: EL PRODUCTO Y EL PROCESO

PARTE SEGUNDA: GESTIÓN DE PROYECTOS DE SOFTWARE

PARTE TERCERA: MÉTODOS CONVENCIONALES PARA LA INGENIERÍA DEL SOFTWARE

PARTE CUARTA: INGENIERIA PEE SOFTWARE ORIENTADA A PRIETOS

PARTE OTITNTA: TEMAS AVANZADOS EN INGENIERIA DEL SOFTWARE

CAPÍTULO 30. REINGENIERIA, 541

PARTE PRIMERA: EL PRODUCTO Y EL PROCESO

PARTE SEGUNDA: GESTIÓN DE PROYECTOS DE SOFTWARE

CAPÍTULO 4- PROCESO DF. SOFTWARE Y MÉTRICAS DF. PROYECTOS. 53

5.3. A M BITO DEL SO FTW A RE, 79

CAPÍTULO 6: ANÁLISIS Y GESTIÓN DEL RIESGO. 97

CAPÍTULO 7: PLANIFICACIÓN TEMPORAL Y SEGUIMIENTO DEL PROYECTO. 111

7.2. LA R ELA CIÓN ENTRE LAS PERSONAS Y E L ESFU ERZO, 114

CAPÍTULO 8: GARANTÍA DE CALIDAD DEL SOFTWARE (SO A/GCSI, 131

9.1.1. LINEAS BASE, 152

PARTE TERCERA: MÉTODOS CONVENCIONALES PARA LA INGENIERIA DEL SOFTWARE

CAPÍTULO 10: INGENIERÍA DE SISTEMAS. 165

C A PIT U L 011: CONCEPTOSY PRTNCTPTOS DEL ANÁLISIS. 181

11.5.1. PRINCIPIOS DE LA ESPECIFICACIÓN, 194

CA P IT I 11,0 17- M O D E L A D O DF.L A N Á IT S IS . 199

C A P ÍT U L O 13: C O N C F .P T O S Y P R T N C T P T O S D F . DTSF.N O. 219

13.5.1. INDEPENDENCIA FUNCIONAL, 229

CAPÍTULO 15: DISE NO DE LA 1NTERFAZ DE USUARIO,259

15.5. H ERRA M IEN TA S DE IM PLEM ENTACIO N, 268

CAPÍTULO 16: DISEÑO A NIVEL DF, COMPONENTES. 273

CAPÍTULO 17: TÉCNICAS DE PRUEBA DEL SOFTWARE. 281

CAPITULO 18: ESTRATEGIAS DE PRUEBA DEL SOFTWARE. 305

CAPÍTULO 19: MÉTRICAS TÉCNICAS DEL SOFTWARE. 323

19.6. M ÉTRICAS PARA PRUEBAS, 337

PARTE CUARTA: INGENIERÍA DFT, SOFTWARE, ORIFATAílA A OBJETOS

CAPITULO 20: CONCEPTOSY PRINCIPIOS ORIENTADOS A PRIETOS. 343

CAPITULO 21: ANÁLISIS ORIENTADO A PRIETOS. 361

PR O B LE M A S Y PU NTOS A CO N SID ERA R, 377

CAPÍTULO 22: DISEÑO ORIENTADO A OBJETOS.379

CAPÍTULO 23: PRUEBAS ORIENTADAS A OBJETOS, 407

23.4.2. APLICABILIDAD DE LOS MÉTODOS CONVENCIONALES DE DISEÑO DE CASOS DE

CAPÍTULO 24: MÉTRICAS TÉCNICAS PARA SISTEMAS ORIENTADOS A ORTy.TOS.421

PARTE QUINTA: TEMAS AVANZADOS EN INGENIERÍA DEL SOFTWARE

CAPÍTULO 25: MÉTODOS FORMALES. 435

25.3. APLICA CIÓN D E LA NOTACIÓN M ATEM ÁTICA PA R A L A E SPECIFIC A CIÓ N

CAPITULO 26: TNGF.NTF.RTA DEL SOFTWARE DF, SALA LTMPTA. 4 5 9

RESUM EN, 469

CAPÍTULO 27: INGENIERIA DEL SOFTWARE BASADA EN COMPONENTES, 473

27.6.3.MÉTRICAS DE REUTILIZACIÓN. 486

CAPITULO 29: INGENIERIA WEB, 521

30.1.3. UN MODELO DE RPN, 543

CAPÍTULO 31: INflF.NIF.WTA DF.LSOFTWARF, ASISTIDA POR COMPUTADORA. 559

CAPITULO 32: PERSPECTIVAS FUTURAS. 573

U AN DO un software de com putadora se desarrolla con éxito - c u a n d o satisface las

C necesidades de las personas que lo utilizan; cuando funciona impecablemente durante

EL ESTADO DEL ARTE DE LA ING ENIERÍA DEL SOFTW ARE

Definición del térm ino «Ingeniería de/l Software»

Ingeniería de Software es el estudio de losprincipios y metodologías para desarrollo y m an­

Ingeniería de Software es el estudio de losprincipios y metodologías para desarrollo y m an

La aplicación de un enfoque sistem ático, disciplinadoy cuantificable al desarrollo, opera

Tomando com o base la referencia de estas definiciones seleccionadas, se producen de inm e

En España, el Consejo de Universidades, organismo encargado de dictar directrices y nor

El icono de punto clave ayudará El icono Referencia web p ro p o r

El icono de signo de interroga

El icono de documento nos seña

Las herramientas de la Ingeniería del software pro

Todo el desarrollo del software se puede caracteri

. i :Q . . ¿ - ¿ .C .Q flS l, ¡QQlORi. l l JX O U P Q JS

las funciones de gestión se m odela de forma que res

Se reconoce que el software, al igual que todos los sis 2.7.1. El m o d e lo in c r e m e n ta l

La dimensión de componentes se afronta con dos activi