Ingenieria del Software - Roger S. Pressman 6ta edicion2.pdf

Roger S. Pressman

Sexfa edición y

£N © FTWAR C

r

D

r<

«

i

/

Un enfoque práctico

I/

TM

PDF Editor Me Graw

uU

*• 3í£%&*$•>

C O N T E N I D O BREVE

CAPITULO 1

PARTE UNO

PARTE DOS

PASTE TRES

PARTE CUATRO

Software e ingeniería del software

1

El proceso del software 21 CAPÍTULO 2

El proceso: una visión general

22

CAPÍTULO 3

Modelos prescriptivos de proceso

CAPITULO 4

Desarrollo ágil

48

77

Práctica de la ingeniería del software

103

CAPÍTULO 5

La práctica: una visión genérica

CAPÍTULO 6

Ingeniería de sistemas

104

1 33

CAPÍTULO 7

Ingeniería d e requisitos

155

CAPÍTULO 8

Modelado del análisis

191

CAPÍTULO 9

Ingeniería del diseño

245

CAPITULO 10

Diseño arquitectónico

275

CAPÍTULO 11

Diseño al nivel d e componentes

315

CAPÍTULO 12

Diseño de la interfaz de usuario

350

CAPÍTULO 13

Estrategias de prueba del software

CAPÍTULO 14

Técnicas de prueba del software

382

CAPITULO 15

Métricas del producto para el software

418 462

Aplicación de la ingeniería Web 501 CAPÍTULO 16

Ingeniería W e b

CAPÍTULO 17

Formulación y planeación para ingeniería W e b

502

CAPÍTULO 18

Modelado de análisis para aplicaciones W e b

544

CAPITULO 19

Modelado d e diseño para aplicaciones W e b

566

CAPÍTULO 20

Cómo probar aplicaciones W e b

517

604

Gestión de proyectos de software 639

TM

CAPÍTULO 21

Conceptos de gestión d e proyectos

CAPÍTULO 22

Métricas de proceso y proyecto

640

663

PDF Editor CAPITULO 2 3

Estimación para proyectos de software

CAPÍTULO 2 4

Calendarización de proyectos d e software

690

CAPÍTULO 2 5

Gestión del riesgo

CAPITULO 26

Gestión d e la calidad

CAPÍTULO 27

Gestión del cambio

724

747

767

796

vii

viii

CONTENIDO BREVE

PARTE CINCO

Temas avanzados en ingeniería del software 829 CAPÍTULO 2 8

Métodos formales

830

CAPÍTULO 29

Ingeniería del software d e sala limpia

CAPITULO 30

Ingeniería del software basada en componentes

CAPITULO 31

Reingeniería

CAPITULO 32

El camino por recorrer

858 879

902 927

TM

PDF Editor

CONTENIDO

Prefacio

xxviii

Recorrido

xxxi

CAPÍTULO 1

SOFTWARE E INGENIERIA DEL SOFTWARE

1.1

El papel evolutivo del software

1.2

Software

La naturaleza cambiante del software

1.4

Software heredado

8

1 1

1.4.1

Calidad del software heredado

1.4.2

Evolución del software

1.5

Mitos del software

1.6

Cómo inicia todo

1.7

Resumen

12

14 17

18

18

Problemas y puntos a considerar

19

Otras lecturas y fuentes de información PARTE UNO:

2

5

1.3

Referencias

EL PROCESO DEL SOFTWARE CAPITULO 2

20

21

EL PROCESO: UNA VISION GENERAL

22

2.1

Ingeniería del software: una tecnología estratificada

2.2

Marco de trabajo para el proceso

2.3

Integración del modelo de capacidad de madurez (IMCM|

2.4

Patrones del proceso

29

34

2.5

Evaluación del proceso

Modelos de proceso personales y en equipo

36 38

2.6.1

Proceso de software personal (PSP)

2.6.2

Procesos de software en equipo (PSE)

2.7

Tecnología del proceso

2.8

Producto y proceso

2.9

Resumen

39 40

42

43

44

45


46

Otras lecturas y fuentes de información CAPÍTULO 3 3.1

23

24

2.6

Referencias

1

47

TM

MODELOS PRESCRIPTIVOS DE PROCESO

Modelos prescriptivos

48

49

PDF Editor 3.2

El modelo en cascada

3.3

Modelos de proceso incrementóles

50

51

3.3.1

El modelo incremental

52

3.3.2

El modelo DRA 5 3

ix

CONTENIDO 3.4

3.5

3.6

Modelos d e proceso evolutivos

Construcción d e prototipos

3.4.2

El modelo en espiral

3.4.3

El modelo d e desarrollo concurrente

3.4.4

Un comentario final sobre los procesos evolutivos

55

58

Modelos especializados d e proceso

60 61

63

3.5.1

Desarrollo basado en componentes

3.5.2

El modelo d e métodos formales 6 4

3.5.3

63

Desarrollo del software orientado a aspectos

65

El proceso unificado 6 7 3.6.1

Una breve historia

3.6.2

Fases del proceso unificado 6 8

3.6.3 3.7

54

3.4.1

Resumen

67

Productos d e trabajo del proceso unificado 71 72

Referencias 7 3 Problemas y puntos o considerar

74

Otras lecturas y fuentes d e información CAPÍTULO 4

DESARROLLO ÁGIL

4.1

¿Qué es la agilidad?

4.2

¿Qué es un proceso ágil?

4.3

77

79 81

4.2.1

Las políticas del desarrollo ágil

4.2.2

Factores humanos

Modelos ágiles d e proceso 4.3.1

4.4

75

81

82

84

Programación extrema |PE)

84

4.3.2

Desarrollo adaptativo d e software (DAS)

4 . 3 .3

Método d e desarrollo d e sistemas dinámicos (MDSD) 91

4.3.4

Melé

4.3.5

Cristal

89

92 95

4.3.6

Desarrollo conducido por características |DCC|

4.3.7

Modelado ágil |MA)

Resumen

Referencias

95

97

99

100


101

Otras lecturas y fuentes d e información

102

TM PARTE DOS:

PRÁCTICA DE LA INGENIERÍA DEL SOFTWARE CAPÍTULO 5

103

LA PRACTICA: UNA VISIÓN GENÉRICA

104

PDF Editor 5.1

La práctica d e la ingeniería del software 5.1.1

La esencia d e la práctica

5.1.2

Principios esenciales

5.2

Prácticas d e comunicación

109

5.3

Prácticas d e la planeación

11 3

5 .4

Práctica del modelado

116

107

105

106

CONTENIDO

5.5

xi

5.4.1

Principios del modelado del análisis

5.4.2

Principios d e modelado del diseño

Práctica de la construcción

122

5.5.1

Principios y conceptos d e codificación

5.5.2

Principios de las pruebas

5.6

Despliegue

5.7

Resumen

Referencias

128

129

Problemas y puntos o considerar

CAPÍTULO 6

6.2

6.3

130 1 31

INGENIERÍA DE SISTEMAS

Sistemas basados en computadora

La jerarquía d e la ingeniería de sistemas 6.2.1

Modelado del sistema

137

6.2.2

Simulación del sistema

139

1 36

Ingeniería d e procesos d e negocios: una visión general Ingeniería d e producto: una visión general

6.5


140

142

144

6.5.1

Modelado Hatley-Pirbhai

6.5.2

Modelado del sistema con UML

Resumen

151

Referencias

144 147

152


152

Otras lecturas y fuentes de información CAPÍTULO 7

153

INGENIERÍA DE REQUISITOS

7.1

Un puente hacia el diseño y la construcción

7.2

Tareas de la ingeniería d e requisitos

7.3

133

134

6.4

6.6

123

124

126

Otras lecturas y fuentes de información

6.1

117 119

7.2.1

Inicio

7.2.2

Obtención

7.2.3

Elaboración

7.2.4

Negociación

7.2.5

Especificación

7.2.6

Validación

7.2.7

Gestión de requisitos

155 156

157

158 158 159 160 160

161 161

Inicio del proceso de la ingeniería d e requisitos 7.3.1 7.3.2

Identificación d e los interesados

163

TM

164

Reconocimiento d e múltiples puntos de vista

164

PDF Editor 7.4

7.3.3

Trabajo con respecto a la colaboración

7.3.4

Formulación de las primeras preguntas

Obtención de requisitos

164

165

166

7.4.1

Recopilación conjunta d e requisitos

7.4.2

Despliegue d e la función de calidad

7.4.3

Escenarios del usuario

172

167

171

CONTENIDO 7.4.4

Productos de trabajo d e la obtención

7.5

Desarrollo de casos d e uso

7.6

Construcción del modelo de análisis

Elementos del modeb de análisis

7.6.2

Patrones d e análisis

Negociación de requisitos

7.8

Validación de requisitos

7.9

Resumen

Referencias

1 84 186

186 1 88


189

MODELADO DEL ANÁLISIS

Análisis de requisitos 8.1.1

Filosofía y objetivos generales

8.1.2

Reglas prácticas d e análisis

8.1.3

Análisis del dominio

193 194

194

Enfoques de modelado del análisis

196

8.3

Conceptos del modelado d e dalos

197

8.3.1

Objetos d e datos

197

8.3.2

Atributos

8.3.3

Relaciones

8.3.4

Cardinalidad y modalidad

198 199

8 .4

Análisis orientado a objetos

8.5

Modelado basado en escenarios

8.7

X91

192

8.2

8.6

179

I83

187


8.1

179

7.6.1 7.7

173

173

199

201 202

8.5.1

Escritura d e casos d e uso

8.5.2

Desarrollo de un diagrama d e actividad

202

8.5.3

Diagramas de carril

208

209

Modelado orientado al flujo 211 8.6.1

Creación de un modelo de flujo de datos

8.6.2

Creación d e un modelo d e control del flujo 2 1 4

8.6.3

Especificación d e control

8.6.4

Especificación de proceso

Modelado basado en clases

21 1

215 217

219

8.7.1

Identificación d e clases de análisis

219

8.7.2

Especificación de atributos

222

8.7.3

Definición d e operaciones

223

8.7.4

Modelado de Clase-ResponsabilidadColaborador (CRC)

TM 225

PDF Editor 8.8

8.9

8.7.5

Asociaciones y dependencias

8.7.6

Paquetes d e análisis

232

233

Creación d e un modelo d e comportamiento

234

8.8.1

Identificación d e eventos con el caso de uso

8.8.2

Representaciones de estado

Resumen

239

236

235

CONTENIDO Referencias

241

Problemas y punios o considerar

241

Oirás lecturas y fuentes de información CAPÍTULO 9 9.1

INGENIERÍA DEL DISEÑO

Proceso y calidad del diseño

9.3

Conceptos del diseño

9.5

Abstracción

252

Arquitectura

253

9.3.3

Patrones

9.3.4

Modularidad

9.3.5

Ocultación de información

9.3.6

Independencia funcional

9.3.7

Refinamiento

9.3.8

Refabricación

9.3.9

Clases de diseño

254 254

257 258 259

9.4.1

Elementos del diseño de dolos

9.4.2

Elementos del diseño arquitectónico

9.4.3

Elementos de diseño d e interfaz

9.4.4

Elementos d e diseño ol nivel d e componentes

9.4.5

Elementos d e diseño al nivel del despliegue 2 6 7

Diseño d e software basado en patrones

263 264

264

Descripción d e un patrón de diseño

269

9.5.2

Utilización d e potrones en el diseño

270

Resumen

Marcos d e trabajo

266

269

9.5.1

Referencias

270

271

272 273

Otros lecturas y fuentes d e información CAPÍTULO 10

10.2

256 256

262


10.1

249

9.3.2

El modelo d e diseño

247

252

9.3.1

9.5.3 9.6

245

Diseño dentro del contexto d e la ingeniería del software

9.2

9.4

243

273

DISEÑO ARQUITECTÓNICO

Arquitectura del software

275

276

10.1.1

¿Qué es lo arquitectura?

10.1.2

¿Por qué es importante la arquitectura?

Diseño d e datos

276 277

278

TM

10.2.1

Diseño d e datos ol nivel arquitectónico

278

10.2.2

Diseño de datos al nivel de componentes 2 7 9

PDF Editor 10.3

Estilos y patrones arquitectónicos 10.3.1

10.4

280

Una breve taxonomía d e estilos arquitectónicos

10.3.2

Patrones arquitectónicos

10.3.3

Organización y refinamiento

Diseño arquitectónico 10.4.1

284

287

287

Representación del sistemo en el contexto

288

281

riv

CONTENIDO

10.5

10.6

10.4.2

Definición d e arquetipos

10.4.3

Refinamiento d e la arquitectura en componentes

10.4.4

Descripción d e la creación d e instancias del sistema

Evaluación d e diseños arquitectónicos alternos

290 292

294

10.5.1

Un método d e análisis d e compensación para la arquitectura

10.5.2

Complejidad arquitectónica

10.5.3

Lenguajes d e descripción arquitectónica

10.6.1

Flujo d e transformación

10.6.2

Flujo d e transacción

10.6.3

Correlación d e transformaciones

10.6.4

Correlación d e transacciones

Resumen

294

296 296

Correlación del flujo d e datos en una arquitectura del software

10.6.5 10.7

289

297

297

298 299

306

Refinamiento del diseño arquitectónico

310

311

Referencias 3 1 2 Problemas y puntos a considerar

312


11.2

31 3

DISEÑO AL NIVEL DE COMPONENTES

¿Qué es un componente?

316

11.1.1

Concepto orientado a objetos

11.1.2

El concepto convencional

11.1.3

Un concepto relacionado con el proceso

317

318

Diseño de componentes basados en clases 11.2.1

Principios básicos d e diseño

321

322 322

11.2.2

Líneas generales d e diseño al nivel de componentes

11.2.3

Cohesión

11.2.4

Acoplamiento

329

Conducción del diseño al nivel d e componentes

11.4

Lenguaje d e restricción d e objetos

1 1.5

Diseño de componentes convencionales

331

337 340

1 1.5.1

Notación gráfica del diseño

340

11.5.2

Notación tabular del diseño

342

11.5.3

Lenguaje d e diseño de programas

11.5.4

Comparación entre notaciones d e diseño

Resumen

Referencias

325

327

11.3

11.6

315

343 345

TM

346

347


347

PDF Editor Otras lecturas y fuentes d e información CAPÍTULO 12 12.1

348

DISEÑO DE LA INTERFAZ DE USUARIO 3 5 0

Las reglas d e oro

351

12.1.1

Dar el control al usuario

351

12.1.2

Reducir la carga en la memoria del usuario

12.1.3

Lograr que la interfaz sea consistente

354

353

CONTENIDO 12.2

12.3

12.4

xv

Análisis y diseño d e la interfaz d e usuario

Modelos del análisis y diseño de la interfaz

12.2.2

El proceso

359

12.3.1

Análisis del usuario

12.3.2

Análisis y modelado d e tareas

12.3.3

Análisis del contenido d e la pantalla

12.3.4

Análisis del entorno de trabajo

360

Pasos del diseño de la interfaz

361 367

367

368

12.4.1

Aplicación d e los pasos del diseño de lo interfaz

12.4.2

Patrones d e diseño de la interfaz de usuario

12.4.3

Temas d e diseño

Evaluación del diseño

12.6

Resumen

Referencias

372

377

379 380

Otras lecturas'y fuentes de información CAPÍTULO 13

380

ESTRATEGIAS DE PRUEBA DEL SOFTWARE

Un enfoque estratégico para la prueba del software

383

Verificación y validación

384

13.1.2

Organización para las pruebas del software

13.1.3

Estrategia d e prueba para arquitecturas convencionales del software

13.1.4

Estrategia d e prueba del software paro arquitecturas orientadas a objetos

1 3.1.5

Criterios para completar la prueba

385

389

Aspectos estratégicos

13.3

Estrategias d e prueba para el software convencional

390

13.3.1

Prueba d e unidad

13.3.2

Prueba d e integración

391

392 394

Estrategias d e prueba para software orientado a objetos

402

13.4.1

Prueba d e unidad en el contexto orientado a objetos

13.4.2

Prueba de integración en el contexto orientado a objetos

Pruebas d e validación 13.5.1

13.6

382

13.1.1

13.2

13.5

369

371

378


13.4

356

358

Análisis d e la interfaz

12.5

13.1

356

12.2.1

403

404

Criterios d e la prueba de validación

1 3.5.2

Revisión d e la configuración

13.5.3

Pruebas alfa y beta

Prueba del sistema

402

404

405

405

TM

406

13.6.1

Prueba d e recuperación

1 3.6.2

Prueba d e seguridad

407

407

13.6.3

Prueba d e resistencia

408

13.6.4

Prueba de desempeño

PDF Editor 13.7

El arte d e la depuración

408

409

13.7.1

El proceso de depuración

13.7.2

Consideraciones psicológicas

410

411

386 388

xvl

CONTENIDO

13.8

13.7.3

Estrategias d e depuración

13.7.4

Corrección del error

Resumen

Referencias

412

414

415

41 ó


41Ó


417

TÉCNICAS DE PRUEBA DEL SOFTWARE

14.1

Fundamentos d e las pruebas del software 4 1 9

14.2

Pruebas d e caja negra y caja blanca

14.3

Pruebas de caja blanca

14.4

Prueba de la ruta básica

14.5

14.6

14.7

14.8

14.9

422

423 423

14.4.1

Notación d e gráfica d e flujo 4 2 3

14.4.2

Rutos independientes del programa

14.4.3

Derivación d e casos d e prueba

14.4.4

Matrices d e gráficas 4 3 0

Pruebas d e la estructura d e control

430

14.5.1

Prueba d e condición

431

14.5.2

Prueba del flujo d e datos

14.5.3

Prueba de bucles

Pruebo d e caja negra

418

425

427

431

432

41 3

14.6.1

Métodos gráficos d e prueba

14.6.2

Partición equivalente

14.6.3

Análisis d e valores límite

14.6.4

Prueba d e tabla ortogonal

434

436 437 438

Métodos d e pruebas orientadas a objetos

4 41

14.7.1

Implicaciones del concepto orientado a objetos en el diseño de casos de prueba

14.7.2

Aplicabilidad de métodos convencionales d e diseño d e casos d e prueba

14.7.3

Prueba basada en fallas 4 4 3

14.7.4

Casos d e prueba y jerarquía de clase

14.7.5

Prueba basada en escenarios

14.7.6

Estructuras d e superficie y de fondo en pruebas

444

444

Métodos d e pruebo aplicables al nivel d e clase

446

447

14.8.1

Prueba aleatoria para clases orientadas a objetos

14.8.2

Prueba d e partición al nivel d e clase

Diseño de caso de prueba d e interclase

447

448

TM

449

14.9.1

Prueba d e clases múltiples 4 4 9

14.9.2

Pruebas derivadas d e modelos de comportamiento

451

PDF Editor 14.10

14.11

Prueba d e entornos especializados: arquitecturas y aplicaciones

452

14.10.1

Pruebas de interfaces gráficas d e usuario 4 5 2

14.10.2

Prueba de arquitecturas diente/servidor

14.10.3

Prueba d e la documentación y las funciones de ayuda

14.10.4

Prueba d e sistemas d e tiempo real

Patrones de prueba

456

455

452

454

442

442

CONTENIDO 14.12

Resumen

xvll 457


459


15.2

15.3

15.4

460

MÉTRICAS DEL PRODUCTO PARA EL SOFTWARE 4 6 2

Calidad general

463

15.1.1

Factores de calidad d e McCall

15.1.2

Factores de calidad del estándar ISO 9 1 2 6

464

15.1.3

La transición a un concepto cuantitativo

Un marco conceptual para las métricas del producto

465

466 467

15.2.1

Medidas, métricas e indicadores

15.2.2

El reto d e las métricas del producto

467

15.2.3

Principios d e medición

15.2.4

Medición del software orientado a objetivos

15.2.5

Los atributos d e las métricas efectivas del software 4 7 1

15.2.6

Panorama de las métricas del producto 4 7 2

468

469

Métricas para el modelo d e análisis

474

15.3.1

Métricas basadas en la función 4 7 4

15.3.2

Métricas para la calidad de la especificación

Métricas para el modelo d e diseño

470

477

479

15.4.1

Métricas del diseño arquitectónico

15.4.2

Métricas para el diseño orientado a objetos

15.4.3

Métricas orientadas a clases: la colección d e métricas de CK

15.4.4

Métricas orientadas a objetos: la colección de métricas para el diseño orientado a objetos 4 8 6

15.4.5

Métricas orientadas a objetos propuestos por Lorenz y Kidd

15.4.6

Métricas d e diseño al nivel d e componentes

15.4.7

Métricas orientadas a la operación

15.4.8

Métricas de diseño d e la interfaz de usuario 4 9 2

15.5

Métricas para el código fuente 493

15.6

Métricas para pruebas

479 481 483

487

487

491

494

15.6.1

Métricas de Halslead aplicadas a las pruebas

15.6.2

Métricas para pruebas orientadas a objetos

15.7

Métricas para el mantenimiento 4 9 6

15.8

Resumen

494

495

497

Referencias 4 9 7

TM


499


500

PDF Editor PARTE TRES:

APLICACIÓN DE LA INGENIERÍA WEB CAPÍTULO 16

INGENIERÍA WEB

SOI

502

16.1

Atributos d e los sistemas y aplicaciones basados en W e b

16.2

Estratos de la Ingeniería d e WebApp

507

504

xvlll

CONTENIDO

16.3

16.2.1

Proceso

16.2.2

Métodos

507

16.2.3

Herramientas y tecnología

507

El proceso de ingeniería W e b

508

508

16.3.1

Definición del marco d e trabajo 5 0 9

16.3.2

Refinamiento del marco d e trabajo

16.4

Mejores prácticas en ingeniería W e b

16.5

Resumen

512

512

514


515

Otras lecturas y fuentes d e información CAPÍTULO 17 17.1

516

FORMULACIÓN Y PLANEACIÓN PARA INGENIERÍA WEB

Formulación d e sistemas basados en W e b

518

17.1.1

Preguntas d e formulación

519

17.1.2

Recopilación de requisitos para WebApps

17.1.3

El puente hacia el modelado d e análisis

17.2

Planeación de proyectos d e ingeniería W e b

17.3

El equipo d e ingeniería W e b

17.4

17.5

517

520 525

525

526

17.3.1

Los actores

17.3.2

Construcción del equipo

526 528

Conflictos d e gestión d e proyecto para ingeniería W e b

528

17.4.1

Planeación d e WebApp: subcontratación

17.4.2

Planeación d e WebApp: ingeniería W e b en casa

Medición para ingeniería W e b y WebApps

530 533

536

17.5.1

Mediciones para esfuerzo d e ingeniería W e b

17.5.2

Medición del valor d e negocios

537

538

17.6

Las "peores prácticas" para proyectos WebApp

17.7

Resumen

539

540


542


542

MODELADO DE ANÁLISIS PARA APLICACIONES WEB

Requisitos para el análisis de las WebApps

544

545

18.1.1

La jerarquía d e usuario

546

18.1.2

Desarrollo d e casos de uso

18.1.3

Afinación del modelo de caso d e uso

18.2

El modelado d e análisis para WebApps

18.3

El modelo d e contenido

TM

547 549

550

PDF Editor 551

18.3.1

Definición d e objetos d e contenido

18.3.2

Relaciones y jerarquía d e contenido

18.3.3

Clases d e análisis para WebApps

18.4

El modelo de interacción

18.5

El modelo funcional 5 5 7

554

551

552

553

CONTENIDO

xlx

18.6

El modelo d e configuración

18.7

Análisis relación-navegación 18.7.1 18.7.2

18.8

Resumen

559 559

Análisis d e relaciones: preguntas clave Análisis de navegación

560

561

563


564


564

MODELADO DE DISEÑO PARA APLICACIONES WEB

Temas de diseño para ingeniería W e b

Diseño y calidad de una WebApp

19.1.2

Metas de diseño

19.3

Diseño d e la interfaz de la WebApp

19.6

19.7

19.8

567

571

Pirámide del diseño IWeb

19.5

567

19.1.1 19.2

19.4

572 573

19.3.1

Principios y directrices del diseño de la interfaz 5 7 4

19.3.2

Mecanismos d e control d e la interfaz 5 7 9

19.3.3

Flujo de trabajo en el diseño d e la interfaz

Diseño estético

566

580

582

19.4.1

Cuestiones de la plantilla

19.4.2

Cuestiones de diseño gráfico 5 8 3

Diseño del contenido

582

584

19.5.1

Objetos d e contenido

19.5.2

Cuestiones del diseño d e contenido

Diseño arquitectónico

584

19.6.1

Arquitectura d e contenido

586

19.6.2

Arquitectura d e WebApp

588

Diseño d e navegación

585

585

590

19.7.1

Semántica de navegación

19.7.2

Sintaxis d e navegación

Diseño al nivel d e componentes

591

592

593

19.9

Patrones d e diseño hipermedia

19.10

Método d e diseño hipermedia orientado a objetos (MDHOO]

594

19.10.1

Diseño conceptual para el MDHOO

19.10.2

Diseño de navegación mediante el MDHOO

19.10.3

Diseño abstracto d e la interfaz e implementación

19.11

Métricas de diseño para WebApps

19.12

Resumen

595

595 596

598

597

TM

599

Referencias 6 0 0

PDF Editor Problemas y puntos a considerar

602

Otras lectura y fuentes d e información CAPÍTULO 2 0 20.1

603

CÓMO PROBAR APLICACIONES WEB

Prueba de conceptos para WebApps

605

20.1.1

605

Dimensiones d e calidad

604

CONTENIDO 20.1.2

Errores dentro de un ambiente WebApp

20.1.3

Estrategias de pruebas

20.1.4

Planeación d e los pruebas

20.2

El proceso de pruebo: un panorama

20.3

Prueba del contenido

20.4

612

Objetivos de la prueba d e contenido

20.3.2

Prueba d e las bases de datos

Prueba d e la interfaz del usuario

612

613

616

20.4.1

Estrategia d e pruebas d e la interfaz 6 1 6

20.4.2

Prueba d e mecanismos d e la interfaz 6 1 7

20.4.3

Prueba d e la semántica de la interfaz 6 1 9

20.4.4

Prueba d e la facilidad d e uso

20.4.5

Pruebas d e compatibilidad

Prueba al nivel de componentes

20.6

Pruebas d e navegación

620

622

623

625

20.6.1

Prueba d e la sintaxis d e navegación

20.6.2

Prueba d e la semántica de navegación

Prueba de la configuración

Conflictos en el lado del servidor

20.7.2

Conflictos en el lado del cliente

Pruebas de seguridad

20.9

Pruebas del desempeño

625

628 629

630 631

20.9.1

Objetivos d e las pruebas del desempeño

20.9.2

Pruebas d e carga

20.9.3 Resumen

626

628

20.7.1 20.8

20.10

608 609

20.3.1

20.5

20.7

606

607

632

633

Pruebas d e tensión

633

635


637

Otras lecturas y fuentes d e información PARTE CUATRO:

638

GESTIÓN DE PROYECTOS DE SOFTWARE 6 3 9 CAPÍTULO 21 21.1

21.2

CONCEPTOS DE GESTIÓN DE PROYECTOS

El espectro d e la gestión

640

641

21.1.1

El personal

641

21.1.2

El producto

642

21.1.3

El proceso

21.1.4

El proyecto

TM

642 643

Personal

PDF Editor 21.3

21.2.1

Los participantes

21.2.2

Líderes d e equipo

21.2.3

El equipo d e software

21.2.4

Equipos ágiles

21.2.5

Conflictos d e coordinación y comunicación

El producto

651

644

644

645

649

650

CONTENIDO

21.4

xxi

21.3.1

Ámbito del software 6 5 1

21.3.2

Descomposición del problema

652

El proceso 21.4.1

Combinación del producto y el proceso

21.4.2

Descomposición del proceso

21.5

El proyecto

21.6

El principio W 5 HH

21.7

Prácticas críticas 6 5 8

21.8

Resumen

653

654

656 657

659


660


22.2

22.3

22.4

661

MÉTRICAS DE PROCESO Y PROYECTO

Métricas en los dominios del proceso y el proyecto

663

664

22.1.1

Métricas del proceso y mejora del proceso d e software 6 6 4

22.1.2

Métricas del proyecto

667

Medición del software 6 6 8 22.2.1

Métricas orientadas al tamaño

22.2.2

Métricas orientadas a la función 6 7 0

669

22.2.3

Reconciliación d e las métricas LDC y PF 6 7 1

22.2.4

Métricas orientadas a objetos

22.2.5

Métricas orientadas a casos de uso

22.2.6

Métricas d e proyectos d e ingeniería W e b

673 674 674

Métricas para calidad del software 6 7 6 22.3.1

Medición d e la calidad

677

22.3.2

Eficacia en la eliminación d e defectos

678

Integración d e las métricas dentro del proceso de software 6 8 0 22.4.1

Argumentos para las métricas del software 6 8 0

22.4.2

Establecimiento d e una línea base

22.4.3

Recopilación, cálculo y evaluación d e métricas

681 682

22.5

Métricas para organizaciones pequeñas

682

22.6

Establecimiento d e un programa de métricas d e software 6 8 4

22.7

Resumen

686


687

Otras lecturas y fuentes de información CAPÍTULO 2 3

TM

688

ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

23.1

Observaciones acerca d e la estimación

691

23.2

El proceso d e planificación del proceso

692

23.3

Ámbito del software y factibilidad

23.4

Recursos

690

PDF Editor 693

694

23.4.1

Recursos humanos

23.4.2

Recursos d e software reutilizables

695

695

xxii

CONTENIDO 23.4.3

Recursos del entorno 6 9 6

23.5

Estimación de proyectos d e software 6 9 6

23.6

Técnicas de descomposición

23.7

698

23.6.1

Tamaño del software 6 9 8

23.6.2

Estimación basada en el problema

23.6.3

Un ejemplo d e estimación basada en LDC

23.6.4

Un ejemplo d e estimación basada en PF 7 0 2

23.6.5

Estimación basada en el proceso

23.6.6

Un ejemplo de estimación basada en el proceso

23.6.7

Estimación con casos d e uso

23.6.8

Un ejemplo de estimación basada en casos de uso

23.6.9

Reconciliación d e estimaciones

Modelos empíricos d e estimación

709

La estructura d e los modelos d e estimación

23.7.2

El modelo C O C O M O II 7 1 0

23.7.3

La ecuación del software 7 1 2

23.9

Técnicas de estimación especializadas

710

713

714

23.9.1

Estimación para desarrollo ágil

23.9.2

Estimación para proyectos d e ingeniería W e b

23.10.1 23.10.2 Resumen

714 715

217

Creación d e un árbol d e decisión Subcontratación

707

708

23.7.1

La decisión desarrollar-comprar

705

705

Estimoción para proyectos orientados a objetos

23.11

700

704

23.8

23.10

699

717

718

720


721

Otras lecturas y fuentes de información CAPÍTULO 2 4

CALENDARIZACIÓN DE PROYECTOS DE SOFTWARE

24.1

Conceptos básicos

24.2

Calendarización d e proyecto

24.3

722 724

725 727

24.2.1

Principios básicos

728

24.2.2

Relación entre el personal y el esfuerzo 7 2 9

24.2.3

Distribución del esfuerzo 7 3 2

Definición d e un conjunto de tareas para el proyecto d e software 7 3 2

TM

24.3.1

Ejemplo d e conjunto de tareas

24.3.2

Refinamiento d e las tareas principales

24.4

Definición de uno red d e tareas

24.5

Calendarización

733 734

735

PDF Editor 736

24.5.1

Cronogramas

24.5.2

Seguimiento de la calendarización

24.5.3

Seguimiento del progreso en un proyecto O O

24.6

Análisis del valor ganado

24.7

Resumen 7 4 4

738

742

739

741

CONTENIDO

xxlll


744

Otras lecturas y fuentes d e información CAPÍTULO 2 5

746

GESTIÓN DEL RIESGO

747

25.1

Estrategias d e riesgo reactivas y proactivas

25.2

Riesgos del software

25.3

Identificación d e riesgos

25.4

748

749 750

25.3.1

Evaluación del riesgo global del proyecto

25.3.2

Componentes y controladores del riesgo

Proyección del riesgo

752 753

754

25.4.1

Desarrollo de una tabla d e riesgos

755

25.4.2

Evaluación del impacto del riesgo

757

25.5

Refinamiento del riesgo

25.6

Reducción, supervisión y gestión del riesgo

759

25.7

El plan RSGR

25.8

Resumen

759

763

764


765

Otras lecturas y fuentes de información CAPÍTULO 2 6 26.1

26.2

26.3

26.4

765

GESTIÓN DE LA CALIDAD

Conceptos de calidad

768

26.1.1

Calidad

26.1.2

Control d e calidad

26.1.3

Garantía d e la calidad

26.1.4

Costo d e la calidad

769 770 770

770

Garantía de la calidad del software (SQA) 26.2.1

Algunos antecedentes

26.2.2

Actividades d e SQA

Revisiones del software

767

771

772 773

774

26.3.1

Impacto d e los defectos d e software en el costo

26.3.2

Amplificación y eliminación del defecto

775

776

Revisiones técnicas formales 7 7 8 26.4.1

La ¡unta d e revisión

26.4.2

Informe d e la revisión y conservación d e registros

778

26.4.3

Directrices d e la revisión

26.4.4

Revisiones basadas en muestras

779

TM

780 781

26.5

Enfoque formales acerca del SQA

783

26.6

Garantía d e la calidad estadística del software 7 8 3

PDF Editor 26.7

26.6.1

Un ejemplo genérico

26.6.2

Seis sigma para ingeniería del software 7 8 5

Fiabilidad del software 26.7.1

784

786

Medidas d e fiabilidad y disponibilidad

787

xxlv

CONTENIDO 26.7.2

Seguridad del software 7 8 8

26.8

Los estándares de calidad ISO 9 0 0 0

26.9

El plan de SQA

26.10

Resumen

789

79]

792


793


27.2

27.3

27.4

27.5

794

GESTIÓN DEL CAMBIO

796

Gestión de la configuración del software

797

27.1.1

Un escenario d e GCS

27.1.2

Elementos d e un sistema d e gestión d e la configuración

27.1.3

Líneas base

27.1.4

Elementos d e configuración del software 8 0 1

El depósito d e ECS

798

800

803

27.2.1

El papel d e depósito

27.2.2

Características y contenidos generales

27.2.3

Características d e la GCS

El proceso de GCS

799

803 804

805

806

27.3.1

Identificación d e objetos en la configuración del software

27.3.2

Control d e la versión

807

808

27.3.3

Control del cambio

27.3 .4

Auditoría d e la configuración

810

27.3.5

Informe d e estado

813

814

Gestión d e la configuración para ingeniería W e b

815

27.4.1

Problemas en la gestión de la configuración para WebApps

27.4.2

Objetos de configuración WebApp

27.4.3

Gestión del contenido

27.4.4

Gestión del cambio

27.4.5

Control d e la versión

27.4.6

Auditoría y elaboración d e informes

Resumen

Referencias

815

817

817 820 822 823

824

825


826

Otras lecturas y fuentes de información

827

TM PARTE CINCO:

TEMAS AVANZADOS EN INGENIERIA DEL SOFTWARE CAPÍTULO 2 8

MÉTODOS FORMALES

829

830

PDF Editor 28.1

28.2

Conceptos básicos

831

28.1.1

Deficiencias d e los enfoques menos formales

28.1.2

Matemáticas en el desarrollo d e software

28.1.3

Conceptos d e métodos formales

Preliminares matemáticos 28.2.1

833

833

837

Conjuntos y especificación constructiva

832

837

CONTENIDO

xxv

28.2.2

Operaciones d e conjuntos

28.2.3

Operadores lógicos

28.2.4

Sucesiones

838

840

841

28.3

Aplicación d e la notación matemática para la especificación formal

28.4

Lenguajes formales d e especificación

844

28.5

Lenguaje restringido a objetos (OCL)

845

28.6

28.5.1

Un breve panorama de la sintaxis y la semántica del OCL

28.5.2

Ejemplo de uso del OCL

El lenguaje de especificación Z

849

28.6.1

Breve panorama d e la sintaxis y semántica Z

28.6.2

Un ejemplo que utiliza Z

Los diez mandamientos de los métodos formales Métodos formales: el camino por recorrer

28.9

Resumen

854 855


29.3

29.4

29.5

852

853

855


29.2

856

INGENIERÍA DEL SOFTWARE DE SALA LIMPIA

El enfoque de sala limpia

La estrategia de sala limpia

29.1.2

¿Qué hace diferente a la sala limpia?

Especificación funcional

860 862

863

29.2.1

Especificación d e caja negra

29.2.2

Especificación d e caja de estado

29.2.3

Especificación de caja transparente

Diseño d e sala limpia

865 866 • 866

867

29.3.1

Refinamiento y verificación del diseño

867

29.3.2

Ventajas d e la verificación del diseño

871

Pruebas d e sala limpia

872

29.4.1

Pruebas estadísticas de uso

29.4.2

Certificación

Resumen

858

859

29.1.1

Referencias

849

849

28.8

Referencias

845

847

28.7

29.1

842

873

874

875

876


876


877

TM

INGENIERÍA DEL SOFTWARE BASADA EN COMPONENTES

30.1

Ingeniería d e sistemas basada en componentes

30.2

El proceso d e ISBC

30.3

Ingeniería del dominio

880

PDF Editor 30.4

882

883

30.3.1

El proceso d e análisis del dominio

30.3.2

Funciones de caracterización

30.3.3

Modelado estructural y puntos d e estructura

Desarrollo basado en componentes

886

883

884

885

879

xxvl

CONTENIDO 30.4.1

30.5

30.6

30.7

Calificación, adaptación y composición d e componentes

30.4.2

Ingeniería de componentes

30.4.3

Análisis y diseño para la reutilización

Descripción d e los componentes reutilizables

30.5.2

El entorno d e reutilización

Impacto sobre la calidad, la productividad y el costo

30.6.2

Análisis de costo empleando puntos d e estructura

Resumen

898 900

CAPÍTULO 31

902

31.5

896

897

899 901

31.4

894

30.6.1


31.3

892

895


31.2

891

892

30.5.1

Referencias

31.1

890

Clasificación y recuperación d e componentes

Economía d e la ISBC

887

RHNGENIERÍA

Reingeniería d e procesos d e negocio 31.1.1

Procesos de negocios

31.1.2

Un modelo d e RPN

903

904 904

Reingeniería del software 9 0 6 31.2.1

Mantenimiento del software 9 0 7

31.2.2

Un modelo d e procesos d e reingeniería del software 9 0 8

Ingeniería inversa

912

31.3.1

Ingeniería inversa para comprender los datos

31.3.2

Ingeniería inversa para comprender el procesamiento

31.3.3

Ingeniería inversa d e interfaces d e usuario

Reestructuración

914

915

916

31.4.1

Reestructuración del código

31.4.2

Reestructuración d e los datos

Ingeniería directa

91 3

917 917

918

31.5.1

Ingeniería directa para arquitecturas cliente/servidor

31.5.2

Ingeniería directa para arquitecturas orientadas a objetos

31.5.3

Ingeniería directa d e interfaces d e usuario

31.6

La economía d e la reingeniería

31.7

Resumen

920 921

922

923

923


TM

925

Otras lecturas y fuentes d e información 9 2 6

PDF Editor CAPÍTULO 32

EL CAMINO POR RECORRER

927

32.1

La importancia del software. Segunda parte

32.2

El ámbito del cambio

928

32.3

Las personas y la forma en la que construyen sistemas

32.4

El "nuevo" proceso d e ingeniería del software 9 3 1

32.5

Nuevos modos d e representar la información 9 3 3

32.6

La tecnología como impulsor

929

935

930

CONTENIDO

xxvií

32.7

La responsabilidad d e la ingeniería del soflware 9 3 6

32.8

Un comentario final

Referencias

938

939


939

Otras lecturas y fuentes d e información 9 4 0

índice analítico 943 Siglas más comunes en ingeniería del software

953

TM

PDF Editor

C A P Í T U L O

SOFTWARE E INGENIERÍA DEL S O F T W A R E CONCEPTOS CLAVE orocterísticas software

S

éi q&ación

8

mr*B$ d e f a l l a . . . 6 definición ie s o f t w a r e

."¡¡/¿'r. .5

deterioro

..6

evolución

12

historia

3

witos

14

retos

11

software heredado

II

E

s c o m ú n d a r s e cuenta que la invención de una tecnología p u e d e tener efectos profundos e inesperados e n o t r a s tecnologías con las que e n a p a riencia n o tiene ninguna relación, c o m o e n e m p r e s a s comerciales, en pers o n a s y a u n en la cultura en su conjunto. Este f e n ó m e n o a m e n u d o se d e n o m i n a "la ley de las c o n s e c u e n c i a s imprevistas". En la actualidad, el software de computadora es la tecnología individual m á s importante en el ámbito mundial. También es uno de los ejemplos principales de la ley de las consecuencias imprevistas. Nadie en la década de 1950 podría haber predicho que el software se convertiría en una tecnología indispensable en los negocios, la ciencia y la ingeniería; tampoco que el software permitiría la creación de tecnologías nuevas (por ejemplo, la ingeniería genética), la expansión de tecnologías existentes (como las telecomunicaciones), el fin de tecnologías antiguas (com o la industria de la impresión); que el software sería la fuerza conductora detrás de la revolución de las computadoras personales; que los productos e m p a q u e t a d o s de software se podrían comprar en los centros comerciales; que una compañía de software se volvería muy grande y m á s influyente que la mayoría de las compañías de la era industrial; que una gran red construida con software llamada Internet cubriría y cambiaría todo, desde la investigación bibliográfica hasta las compras de los consumidores y los hábitos diarios de los jóvenes (y no tan jóvenes). Nadie podría h a b e r previsto que el s o f t w a r e estaría relacionado con sistemas de todo tipo: de transporte, médicos, de telecomunicaciones, militares, industriales, d e e n t r e t e n i m i e n t o , m á q u i n a s p a r a oficina (la lista p a r e c e n o t e n e r fin).

¿ Q u é e s ? El software de computadora es el producto que los ingenieros de software construyen y después mantienen en el largo plazo. Incluye los programas que se ejecutan dentro de una computadora de cualquier tamaño y arquitectura, el contenido que se presenta conforme los programas se ejecutan y los documentos, tanto físicos como virtuales, que engloban todas las formas de medios electrónicos. ¿ Q u i é n lo h a c e ? Los ingenieros de software lo construyen y lo mantienen, y casi todos en el mundo industrializado lo usan de manera directa o indirecta. ¿Por q u é e s i m p o r t a n t e ? Porque afecta de forma muy cercana todos los aspectos de nuestras vidas y se ha vuelto omnipresente en el comercio, la cultura y las actividades cotidianas.

¿Cuáles s o n los p a s o s ? El software de computadora se construye de la misma forma que cualquier producto de éxito: mediante la aplicación de un proceso que conduzca a un resultado de alta calidad que satisfaga las necesidades de la gente que usará el producto. Se aplica un enfoque de ingeniería del software. ¿Cuál e s el p r o d u c t o o b t e n i d o ? Desde el punto de vista del ingeniero de software, el producto obtenido J o forman los programas,TM el contenido (datos) y los documentos que constituyen el software. Pero desde el enfoque del usuario, el producto obtenido es la información resultante que de alguna manera mejora el mundo del usuario. ¿ C ó m o pirado e s t a r s e g u r o d e q u e lo h e h e c h o c o r r e c t a m e n t e ? Una manera es leer el resto de este texto, seleccionar las ideas aplicables a un software específico y aplicarlas.

PDF Editor

1

CAPÍTULO 1

2

S O F T W A R E E INGENIERÍA DEL S O F T W A R E

Y si se t o m a en cuenta la ley de las c o n s e c u e n c i a s imprevistas, hay m u c h o s efectos que todavía es imposible predecir e n el trabajo diario. Por último, nadie podría h a b e r predicho q u e millones de p r o g r a m a s d e c o m p u tadora tendrían que corregirse, a d a p t a r s e y mejorarse c o n f o r m e p a s a r a el tiempo y que la labor de desarrollar e s t a s actividades de "mantenimiento" absorbería m á s g e n t e y recursos que todo el trabajo aplicado para la creación del s o f t w a r e nuevo. y los descubrimientos tecnológicos son los elementos conductores del cri

A medida que la importancia del s o f t w a r e ha crecido, la c o m u n i d a d del s o f t w a r e ha intentado de m a n e r a continua desarrollar tecnologías que h a g a n m á s fácil, m á s rápida y m e n o s c a r a la construcción y el m a n t e n i m i e n t o de p r o g r a m a s de c o m p u tadora de alta calidad. Algunas de e s t a s tecnologías se limitan al dominio de u n a aplicación específica (por ejemplo, al d i s e ñ o y la implementación de sitios Web); otras se e n f o c a n al dominio de u n a tecnología (como la programación orientada a objetos y la programación orientada a aspectos); y existen o t r a s con b a s e general (por ejemplo, sistemas operativos c o m o LINUX). Sin embargo, a ú n no se desarrolla u n a tecnología de s o f t w a r e que lo h a g a todo, y la probabilidad de que ésta surja e n el futuro e s p e q u e ñ a . Aun así, las p e r s o n a s dejan s u s trabajos, su seguridad y hasta sus vidas e n m a n o s del software de c o m p u t a d o r a s . Más vale que é s t e s e a bueno. Este texto presenta un m a r c o para q u i e n e s construyen s o f t w a r e de c o m p u t a d o r a : las p e r s o n a s que deben hacer b u e n software. El marco, que incluye un proceso, un conjunto de m é t o d o s y u n a serie de h e r r a m i e n t a s se llama ingeniería del software. — r - r ~ - — .J i n g e n i e r í a 05 r . - r - -

—

<• —

(eriales d e la vida humana, para que así la vida sea más fácil, segura y placentera Richard Fairley y M o r * !

En la actualidad, el s o f t w a r e tiene u n p a p e l dual. Es, a la vez, un p r o d u c t o y u n vehículo mediante el cual se entrega un producto. C o m o producto, ofrece la poten-

CLAVE El software es tanto un producto como el vehículo para su entrega.

cia de c ó m p u t o p r e s e n t a d a c o m o h a r d w a r e de u n a c o m p u t a d o r a o, de m a n e r a m á s

TM

amplia, por u n a red de c o m p u t a d o r a s accesible m e d i a n t e h a r d w a r e local. Sin importar el lugar en que resida el software, ya sea e n un celular o dentro de u n a c o m p u tadora central, éste es un transformador de información; realiza la producción, el

PDF Editor

m a n e j o , la adquisición, la modificación, el despliegue o la transmisión de la información que p u e d e ser tan simple c o m o un solo bit o tan compleja c o m o u n a p r e s e n t a ción multimedia. En su papel de vehículo para la entrega de un producto, el software actúa c o m o la b a s e para el control de la c o m p u t a d o r a (sistemas operativos), la comunicación de información (redes), y la creación y el control de otros p r o g r a m a s (utilerías de s o f t w a r e y ambientes).

CAPÍTULO 1

3

SOFTWARE E INGENIERÍA DEL SOFTWARE

El s o f t w a r e entrega el producto m á s importante de nuestro tiempo: información. Transforma los datos p e r s o n a l es (por ejemplo, las transacciones financieras de un individuo) de forma que los d a t o s s e a n m á s útiles en un contexto local; m a n e j a información de negocios para mejorar la c o m p e t i v i d a d ; proporciona u n a vía para las redes d e información alrededor del m u n d o (Internet) y proporciona los medios para adquirir información e n t o d a s sus formas. El papel del s o f t w a r e de c o m p u t a d o r a ha e x p e r i m e n t a d o un c a m b i o significativo en un periodo un poco mayor a 50 años. Las mejorías sustanciales e n el d e s e m p e ñ o del hardware, los c a m b i o s p r o f u n d o s e n las arquitecturas de cómputo, los e n o r m e s i n c r e m e n t o s en las c a p a c i d a d e s de m e m o r i a y a l m a c e n a m i e n t o , y la amplia variedad de opciones de salida y de e n tr a da h a n propiciado el surgimiento de s i s t e m a s m á s elaborados y complejos b a s a d o s en c o m p u t a d o r a s . Los libros populares publicados d u r a n t e las d é c a d a s de 1970 y 1980 ofrecen u n a amplia visión histórica de la cambiante percepción de las computadoras y del software y su impacto en la cultura. Osborne [OSB79] describió u n a "nueva Revolución Industrial". Toffler [TOFSO] llamó al surgimiento de la microelectrónica parte de "la tercera ola del cambio" e n la historia de la humanidad, y Naisbitt [NAI182] predijo la transformación de una sociedad industrial en una "sociedad de la información". Feig e n b a u m y McCorduck [FEI83] sugirieron que la información y el conocimiento (controlados por computadoras) serían el p u n t o de enfoque para el poder en el siglo xxi, y Stoll [STO89] a r g u m e n t ó que la "comunidad electrónica" creada por redes y software era la clave del intercambio de conocimiento alrededor del mundo. Todos estos escri(eoNSUfl^

S se teñe tiempo, team uno o más de este iros clásicos. Hágase atención en ts indicciones errómas que estos experto hicieron en lo oferente o eventos y «nologias. Consérvese la humildad: nadie sabe en realidad el foto) de los sistemas f í e s e construyen.

tores tenían razón. Al c o m i e n z o de la d é c a d a de 1990, Toffler [TOF90] describió un "cambio de poder" e n el q u e t o d a s las viejas estructuras (gubernamentales, educativas, industriales, e c o n ó m i c a s y militares) se desintegrarían a medida que las c o m p u t a d o r a s y el s o f t w a r e condujeran a una "democratización del conocimiento". Yourdon [YOU92] se preocupaba de que las c o m p a ñ í a s e s t a d o u n i d e n s e s pudieran perder su m a r g e n competitivo e n negocios relacionados con el software y predijo "la declinación y caída del programador estadounidense". Hammer y Champy [HAM93] argumentaban que las tecnologías de información representarían un papel primordial e n la "reingeniería de la corporación". A mediados de la década de 1990 la penetración de las comput a d o r a s y del s o f t w a r e provocó el surgimiento de u n a serie de libros de "neoluditas" (como Resisting the Virtual Life, editado por James Brook y Iain Boal, y The Future Does Not Compute, de Stephen Talbot). Estos a u t o r e s s a t a n i z a b a n a la c o m pTM u t a d o r a al e n fatizar inquietudes legítimas, p e r o ignorando los g r a n d e s beneficios que ya se habían obtenido [LEV95],

PDF Editor

" l o s computadoras facilitan la realización de muchas cosas, pero la mayoría de las cosas que fnatrton no necesitan hoftwfy Rooney

4

CAPÍTULO 1


A finales d e la d é c a d a de 1990, Yourdon [YOU96] evaluó de n u e v o a los candidatos a profesionales del s o f t w a r e y sugirió el "surgimiento y resurrección" del program a d o r estadounidense. A medida que Internet cobraba mayor importancia, el giro que había d a d o Yourdon parecía s e r el correcto. Al finalizar el siglo xx, el e n f o q u e c a m b i ó n u e v a m e n t e , esta vez con el impacto del Y2K, "bomba de tiempo" (por e j e m plo [YOU98a], [KAR99]). Aunque las fatales predicciones de aquellos que vislumbrab a n u n a catástrofe respecto al Y2K fueron falsas, sus populares escritos acarrearon la p e r m a n e n c i a del s o f t w a r e en la vida de los s e r e s h u m a n o s . Ya iniciado el n u e v o siglo, Johnson [JOHOl] explicó el poder del "surgimiento" com o u n f e n ó m e n o que explica lo q u e s u c e d e c u a n d o interconexiones p r e s e n t e s en entidades relativamente simples resultan e n un s i s t e m a q u e "se autoorganiza para

(258339

Poto feeruncomwlorio sobre as amplio rengo de tópicos rebcionadoscor el soítwo•6 V»|ese

formar un c o m p o r t a m i e n t o m á s adaptable e inteligente". Yourdon [YOUR02] r e t o m ó los trágicos s u c e s o s ocurridos el 11 de septiembre de 2001 en Nueva York p a r a explicar el impacto continuo del terrorismo global e n la c o m u n i d a d informática. Wolfram [WOL02] presentó un tratado sobre "un n u e v o tipo de ciencia" en d o n d e expone una teoría unificadora basada sobre t o d o en elaboradas simulaciones de software. Daconta y sus colegas [DAC03] explicaron la evolución de la "red semántica", y c ó m o esto cambiará el m o d o en que la gente interactúa a través de las redes globales. 'Me introduje en et futuro, más alia de lo que el ojo humano puede ver. Tuve una visión del mundo y de todo lo viiloso que podría ser."

En la actualidad u n a e n o r m e industria del s o f t w a r e se ha convertido en u n factor d o m i n a n t e en la e c o n o m í a del m u n d o industrializado. El p r o g r a m a d o r solitario de la era inicial ha sido sustituido por equipos d e especialistas en software, en los que c a da u n o se e n f o c a e n u n a parte de la tecnología requerida para desarrollar u n a aplicación compleja. Hasta ahora, las p r e g u n t a s f o r m u l a d a s al p r o g r a m a d o r solitario son las m i s m a s que se hacen c u a n d o se construyen los sistemas b a s a d o s en c o m p u tadoras modernas: 1 • ¿Por qué tarda tanto la obtención del s o f t w a r e terminado? • ¿Por qué s o n tan altos los c o s t o s de desarrollo del software? • ¿Por qué e s imposible e n c o n t r a r t o d o s los errores en el s o f t w a r e a n t e s de e n TM tregarlo a los clientes?

PDF Editor I

En uri excelente libro de ensayos sobre el negocio del software, Tom DeMarco [DEM95] expone la idea contraria. Explica: "En vez de cuestionarse por qué cuesta tanto el software, uno debe preguntarse qué se ha hecho para hacer que hoy el software cueste tan poco. La respuesta a esa pregunta ayudará a continuar con el extraordinario nivel de logros que siempre ha distinguido a la industria del software".

CAPÍTULO 1

5


• ¿Por qué se gastan t a n t o tiempo y e s f u e r z o e n el m a n t e n i m i e n t o de los prog r a m a s existentes? • ¿Por qué e s difícil medir el progreso al desarrollar y darle m a n t e n i m i e n t o al software? Éstas y m u c h a s otras preguntas d e m u e s t r a n la preocupación de la industria por el s o f t w a r e y por la m a n e r a en que éste se desarrolla; u n a preocupación que ha conducido a la adopción de la práctica d e la ingeniería del software.

En 1970, m e n o s del u n o p o r ciento de las p e r s o n a s podrían haber definido lo que significaba "software de computadora". En la actualidad, la mayoría de los profesionales y m u c h o s m i e m b r o s del público creen que e n t i e n d e n el software. Pero, ¿en realidad lo hacen? A ¿Cómo debe VdefMrse el software?

Una definición de s o f t w a r e en un libro de texto p u e d e tener la siguiente forma: el software se forma con 1) las instrucciones se proporcionan

(programas de computadora)

las características, funciones y el grado de desempeño

estructuras de datos que permiten que los programas manipulen ra adecuada; y 3) los documentos

que al ejecutardeseados; 2) las

información

de mane-

que describen la operación y el uso de los programas.

No existe d u d a de que se p u e d e n e n c o n t r a r definiciones m á s completas. Pero se requiere m á s q u e u n a definición formal. Para e n t e n d e r el s o f t w a r e (y la ingeniería del software), es importante e x a m in a r las características que lo h a c e n diferente de otras c o s a s que construye el ser h u m a no. El s o f t w a r e es un e l e m e n t o lógico, en lugar de físico, de un sistema. Por lo tanto, el s o f t w a r e tiene características m u y diferentes a las del hardware: El software se desarrolla, no se manufactura.

1. El software se desarrolla o construye; no se manufactura

en el sentido clásico.

A pesar de que existen similitudes entre el desarrollo del s o f t w a r e y la m a n u factura del hardware, las dos actividades son diferentes en lo f u n d a m e n t a l . En a m b a s , la alta calidad se alcanza por m e d i o del buen diseño, p e r o la fase de manufactura del h a r d w a r e p u e d e incluir problemas de calidad inexistentes (o q u e son fáciles de corregir) e n el software. A m b a s actividades d e p e n d e n de las personas, p e r o la relación entre la g e n t e utilizada y el trabajo realizado es

TM requieren la diferente por completo (véase el capítulo 24). A m b a s actividades

\

construcción de un "producto", p e r o los e n f o q u e s son diferentes. Los costos del software se c o n c e n t r a n e n la ingeniería. Esto significa que los proyectos

PDF Editor CLAVE

B software no se iesgosta, pero se deteriora.

de s o f t w a r e n o se p u e d e n m a n e j a r c o m o si fueran proyectos de m a n u f a c t u r a .

2.

El software no se "desgasta".

En la figura 1.1 se muestra, para el hardware, la tasa de fallas c o m o una f u n -

ción del tiempo. La relación, llamada a m e n u d o "curva de la bañera", indica

Tiempo que el h a r d w a r e tiene un n ú m e r o considerablemente alto de fallas al inicio de su vida (a m e n u d o é s t a s se atribuyen a defectos de diseño o manufactura). Después, los defectos se corrigen y la tasa de fallas baja hasta un nivel estable (se desea que éste sea m u y bajo) por algún periodo. Sin e m b a r g o , conforme ^CONSEJO^

Si se desea reduá el deterioro del software, es necesario realizar un mejor diseño ((opílalos 9-12).

p a s a el tiempo, la t a s a de fallas se eleva de n u e v o c o n f o r m e los c o m p o n e n t e s del h a r d w a r e sufren los efectos acumulativos del polvo, la vibración, el abuso, las t e m p e r a t u r a s e x t r e m a s y m u c h o s otros m a l e s ambientales. Expresado e n forma m á s simple, el h a r d w a r e c o m i e n z a a desgastarse. El s o f t w a r e es i n m u n e a los m a l e s ambientales que desgastan el hardware. Por lo tanto, la curva de la tasa de fallas p a r a el software debería tener la form a de la "curva idealizada" que se muestra e n la figura 1.2. Los defectos sin descubrir causan t a s a s de falla altas en las primeras e t a p a s de vida de un programa. Sin embargo, los errores se corrigen (en el mejor de los c a s o s sin agregar otros errores) y la curva se a p l a n a c o m o se muestra e n la figura 1.2. La curva idealizada e s u n a simplificación burda del modelo de fallas real para

CLAVE Los métodos de la ingeniería del software pretenden reducir lo magnitud de los picos y lo pendiente de lo curva real que se muestra en la figuro 1.2.

el s o f t w a r e (para m á s información v é a s e el capítulo 26). Sin embargo, la implicación e s clara: el s o f t w a r e no s e desgasta, pero sí se deteriora. Esta contradicción a p a r e n t e s e p u e d e explicar de mejor m a nTM e r a si se considera la "curva real" de la figura 1.2. Durante su vida, 2 el software experimenta cambios. Conforme éstos ocurren se presenta la posibilidad de introducir

PDF Editor

errores, lo que o c a s i o n a que la curva de fallas tenga un pico, c o m o se m u e s tra en la figura 1.2. Antes de que la curva p u e d a regresar a su estado original con u n a tasa de fallas estable, se requiere otro cambio, lo que ocasiona que la

2 De hecho, desde el momento en que comienza el desarrollo, y mucho antes de que se entregue la primera versión, el cliente puede solicitar cambios.

CAPÍTULO 1

7


Curvas de tedia p a r a el software.

Corva real

Curva idealizada

Tiempo

curva t e n g a otro pico. De esta m a n e r a , el nivel de fallas m í n i m o se c o m i e n z a a elevar; el s o f t w a r e se deteriora debido a los cambios. Otro aspecto del desgaste ilustra la diferencia e n t r e el h a r d w a r e y el softLn

or arte del

sofíwore
W 3 r e

'

C u a n d o u n

c o r n

P

o n e n t e del

h a r d w a r e se desgasta se sustituye c o n u n

repuesto. Pero e n el s o f t w a r e no existen repuestos. Cualquier falla del s o f t w a r e implica un error e n el diseño o el proceso mediante el cual se p a s ó del diséñ o al código máquina ejecutable. Por lo tanto, el m a n t e n i m i e n t o del s o f t w a r e implica de m a n e r a considerable u n a complejidad mayor que el del h a r d w a r e . 3 . A pesar de que la industria tiene una tendencia hacia la construcción por componentes, la mayoría del software aún se construye a la medida. Considérese la forma en q u e se diseña y construye un h a r d w a r e de control para un producto de cómputo. El ingeniero de diseño dibuja u n e s q u e m a simple del sistema de circuitos digital, realiza algunos análisis f u n d a m e n t a l e s p a ra asegurarse de q u e el diseño realizará las funciones apropiadas y d e s p u é s busca e n los catálogos d e c o m p o n e n t e s digitales cada circuito integrado de acuerdo con un n ú m e r o de parte, una función definida y validada, una interfaz

TM bien definida y u n c o n j u n t o estandarizado de directrices de integración. Una vez seleccionado cada c o m p o n e n t e , puede solicitársele para d e s p u é s e n s a m blarlo. Cuando una disciplina de ingeniería evoluciona se crea u n a colección de

PDF Editor

diseños e s t á n d a r de c o m p o n e n t e s . Los tomillos y los circuitos integrados son

sólo dos ejemplos d e los miles de c o m p o n e n t e s e s tá n d ar que utilizan los ingenieros m e c á n i c o s y eléctricos al diseñar sistemas nuevos. Los c o m p o n e n t e s reutilizables se han c r e a d o para que el ingeniero se pueda concentrar en los

8

CAPITULO 1

S O F T W A R E E I N G E N I E R Í A DEL S O F T W A R E

e l e m e n t o s que e n realidad s o n innovadores e n el diseño; e s decir, e n las partes q u e representan algo nuevo. En el m u n d o del hardware, la reutilización de c o m p o n e n t e s e s u n a p a r t e natural del p r o c e s o de ingeniería. En el á m b i t o del software, dicha actividad a p e n a s se h a c o m e n z a d o a extender. "los ideas son los bloques de construcción de los ideas." ,

H

Jason Zebehazy

Un c o m p o n e n t e de s o f t w a r e se d e b e diseñar e implementar de forma que p u e d a utilizarse en m u c h o s p r o g r a m a s diferentes. Los c o m p o n e n t e s reutilizables m o d e r n o s e n c a p s u l a n t a n t o los d a t o s c o m o el proceso que se aplica a éstos, lo que permite al ingeniero de s o f t w a r e crear aplicaciones n u e v a s a partir de p a r t e s reutilizables. 3 Por ejemplo, las interfaces actuales c o n el usuario se construyen con c o m p o n e n t e s reutilizables que permiten la creación de ventan a s gráficas, m e n ú s desplegables y u n a amplia variedad de m e c a n i s m o s de interacción. Las estructuras de d a t o s y los detalles de p r o c e s a m i e n t o requeridos p a r a construir la interfaz están contenidos e n u n a librería de c o m p o n e n t e s reutilizables para la construcción de la interfaz.

1.3

L a

n a t u r a l e z a

c a m b i a n t e

d e l

s o f t w a r e

En la actualidad existen siete g r a n d e s categorías del s o f t w a r e de c o m p u t a d o r a que p r e s e n t a n retos continuos para los ingenieros de software. Software de sistemas.

El s o f t w a r e d e s i s t e m a s e s u n a colección de p r o g r a m a s

escritos para servir a otros p r o g r a m a s . Algunos p r o g r a m a s de sistemas (como los compiladores, editores y utilerías para la administración de archivos) p r o c e s a n e s tructuras de información complejas p e r o determinadas. 4 Otras aplicaciones de sistem a s (por ejemplo, c o m p o n e n t e s del sistema operativo, controladores, s o f t w a r e de red, p r o c e s a d o r e s p a r a telecomunicaciones) p r o c e s a n d a t o s indeterminados. En cada caso, el área de s o f t w á r e de sistemas se caracteriza por u n a interacción muy intensa con el h a r d w a r e de la c o m p u t a d o r a ; utilización por múltiples usuarios; operación concurrente que requiere la gestión de itinerarios, de compartición de recursos, y de p r o c e s o s sofisticados; estructuras de d a t o s complejas y múltiples interfaces extemas.

TM

Software d e aplicación.

El s o f t w a r e de aplicación consiste en p r o g r a m a s inde-

p e n d i e n t e s que resuelven una necesidad de negocios específica. Las aplicaciones en

PDF Editor 3 4

La ingeniería del software basado en componentes se presenta en el capítulo 30. El software es determinado si el orden y el ritmo de las entradas, el procesamiento y las salidas son predecibles. El software es indeterminado si el orden y el ritmo de las entradas, el procesamiento y las salidas no se pueden predecir.

CAPÍTULO 1


9

esta área procesan datos empresariales o técnicos de forma que facilitan las operaciones de negocios o la toma de decisiones técnicas o de gestión. Además del procesamiento de datos convencional, el software de aplicación se utiliza para controlar las funciones de negocios en tiempo real (por ejemplo, el procesamiento de transacciones en los puntos de venta y el control de procesos de manufactura en tiempo real.) S o f t w a r e científico y d e ingeniería. El software científico y de ingeniería, que se caracterizaba por algoritmos "devoradores de números", abarca desde la astronomía hasta la vulcanología, desde el análisis de la tensión automotriz hasta la dinámica orbital de los transbordadores espaciales, y desde la biología molecular hasta la manufactura automatizada. Sin embargo, las aplicaciones modernas dentro del área científica y de ingeniería s e alejan en la actualidad de los algoritmos numéricos convencionales. El diseño asistido por computadora, la simulación de sistemas y otras aplicaciones interactivas han c o m e n z a d o a tomar características de software en tiempo real e incluso de software de sistemas. Software emportado.

El software emportado reside dentro de la memoria de sólo

lectura del sistema y con él se implementan y controlan características y funciones para el usuario final y el sistema mismo. El software incrustado puede desempeñar funciones limitadas y curiosas (como el control del teclado de un horno de microondas) o proporcionar capacidades de control y funcionamiento significativas (por ejemplo, las funciones digitales de un automóvil, c o m o el control de combustible, el despliegue de datos en el tablero, los sistemas de frenado, etcétera). S o f t w a r e d e línea d e productos. El software de línea de productos, diseñado para proporcionar una capacidad específica y la utilización de muchos clientes diferentes, se puede enfocar en un nicho de mercado limitado (como en los productos para el control de inventarios) o dirigirse hacia los mercados masivos (por ejemplo, aplicaciones de procesadores de palabras, hojas de cálculo, gráficas por computadora, multimedia, entretenimiento, manejo de bases de datos, administración de personal y finanzas en los negocios). Aplicaciones b a s a d a s e n Web. Las "WebApps" engloban un espectro amplio de aplicaciones. En su forma más simple, las WebApps son apenas un poco m á s que un conjunto de archivos de hipertexto ligados que presenta información mediante texto y algunas gráficas. Sin embargo, a medida que el comercio electrónico TM y las aplicaciones B2B adquieren mayor importancia, las WebApps evolucionan hacia ambientes computacionales sofisticados que no sólo proporcionan características, funciones de cómputo y contenidos independientes al usuario final, sino que están integradas con bases de datos corporativas y aplicaciones de negocios.

PDF Editor

S o f t w a r e d e inteligencia artificial. Este software utiliza algoritmos n o numéricos en la resolución de problemas complejos que es imposible abordar por medio de un análisis directo. Las aplicaciones dentro de esta área incluyen la robótica, los sis-

10

CAPÍTULO 1


t e m a s expertos, el reconocimiento de patrones (imagen y voz), las redes n e u r o n a l e s artificiales, la comprobación de t e o r e m a s y los juegos en c o m p u t a d o r a . "No existe una computadora que tenga sentido común." Marvin Minsky Existen millones de ingenieros de software que trabajan duro en una o más de estas categorías. En algunos casos se construyen sistemas nuevos, pero en otros las aplicacion e s existentes se corrigen, adaptan y mejoran. Es común ver a un joven ingeniero de software que trabaja en programas m á s viejos que él mismo. Las generaciones pasadas de creadores de s o f t w a r e han d e j a d o un legado en cada una de las categorías q u e se h a n definido párrafos atrás. Se espera q u e el legado de la generación actual facilite la tarea de los ingenieros de software del futuro. No obstante, e n el horizonte h a n aparecido retos nuevos: Computación ubicua.

El crecimiento rápido de las r e d e s inalámbricas podría

conducir pronto a la verdadera computación distribuida. El reto para los ingenieros de software será desarrollar software de sistema y de aplicación que permita que dispositivos pequeños, c o m p u t a d o r a s p e r s o n a les y sistemas de e m p r e s a se comuniq u e n a través de g r a n d e s redes. Alimentación d e la red.

La World Wide Web se convierte c o n rapidez en un dis-

positivo computacional, así c o m o e n un proveedor de contenido. El reto para los ingenieros de software es crear aplicaciones simples (por ejemplo, planeación de las finanzas

personales) y complejas que beneficien a m e r c a d o s de usuarios finales e s -

pecíficos alrededor del m u n d o . "No siempre es posible predecir, pero siempre es posible prepararse." ,

:

Fuente abierta.

.I...

Anónimo

i;v..;;ivrf;vKMi^W

Existe una tendencia creciente que impulsa la distribución del có-

digo fuente para aplicaciones de sistemas (como sistemas operativos, b a s e s de datos y a m b i e n t e s de desarrollo) de forma que los clientes h a g a n modificaciones locales. El reto para los ingenieros de software es construir u n código f u e n t e que s e a descriptivo en sí mismo, pero, a ú n m á s importante, desarrollar técnicas que permitan tan-

TM

to a los clientes c o m o a los d i s e ñ a d o r e s conocer los cambios realizados y la forma en que se manifiestan dentro del software.

PDF Editor

La " n u e v a e c o n o m í a " . La locura del punto-com que se afianzó en los m e r c a d o s

financieros

hacia finales de la década de 1990 y la subsiguiente ruptura en los pri-

m e r o s a ñ o s del siglo xxi ha llevado a m u c h a gente de negocios a creer que la nueva e c o n o m í a está muerta. La nueva e c o n o m í a está viva y saludable, pero evolucionará con lentitud; la caracterizará la comunicación y la distribución masiva. Andy Lippm a n [L1P02J puntualiza esta situación c u a n d o escribe:

CAPÍTULO 1

SOFTWARE E INGENIERÍA D a SOFTWARE

11

Estamos entrando en una era caracterizada por las comunicaciones entre las máquinas distribuidas y la gente dispersa, en lugar de la que define una conexión entre dos individuos o entre un individuo y una máquina. El antiguo enfoque de la telefonía se refiere a "conexiones con"; la siguiente ola se refiere a "conexiones entre". Por mencionar algunos ejemplos, se tiene Napster, la mensajería instantánea, los sistemas de mensaje cortos y las BlackBerries. El reto para los ingenieros de software e s construir aplicaciones que faciliten la c o m u nicación y la distribución de productos en m a s a mediante productos a p e n a s en formación. Cada u n o de estos "nuevos retos" obedecerá sin duda la ley de las c o n s e c u e n c i a s imprevistas y tendrán efectos (para la gente de negocios, los ingenieros de s o f t w a r e y los usuarios finales) que n o p u e d e n predecirse en la actualidad. Sin embargo, los ingenieros de s o f t w a r e se pueden preparar al iniciar un proceso que tenga la suficiente agilidad y adaptabilidad c o m o para acoplarse a los cambios drásticos en la tecnología y las reglas de negocios que con seguridad se p r e s e n t a r á n en la década siguiente.

t í a ] computadora por sí misma hará una transición histórica de algo que se usa pora tareas analíticas... o algo que puede provocar emociones." David Vaskevitch

M 4

SOFTWARE H S R E P A P P Existen cientos de miles de p r o g r a m a s d e c o m p u t a d o r a y todos pertenecen a u n o de los siete g r a n d e s dominios de aplicación —software d e sistemas, s o f t w a r e de aplica-

¿Qué es el

• software heredado?

c¡ón,

s o f t w a r e científico y de ingeniería, s o f t w a r e empotrado, s o f t w a r e de producto,

WebApps y aplicaciones IA— que se expusieron e n la sección 1.3. Algunos de estos p r o g r a m a s s o n de vanguardia —sólo divulgados entre ciertas personas, industrias y gobiernos—, p e r o otros son m á s viejos, y e n algunos c a s o s mucho m á s viejos. Estos p r o g r a m a s viejos —con frecuencia referidos c o m o software heredado— han sido el foco de atención y preocupación continua d e s d e la d é c a d a de 1960. DayaniFard y sus colegas [DAY99] describen el s o f t w a r e h e r e d a d o de la siguiente forma: Los sistemas de software heredado... fueron desarrollados hace décadas y han sido moTMen los negodificados en forma continua para cumplir los requerimientos de los cambios cios y en las plataformas de cómputo. La proliferación de dichos sistemas ha causado dolores de cabeza a las grandes organizaciones, las cuales los perciben como costosos en su mantenimiento y riesgosos en su evolución.

PDF Editor

Liu y s u s colegas (LIU98) extendieron esta descripción al escribir que " m u c h o s sistem a s h e r e d a d o s persisten c o m o el soporte de las funciones centrales de negocios y

son indispensables para las e m p r e s a s " . Por lo tanto, al s o f t w a r e h e r e d a d o lo caracterizan. su longevidad y el ser crítico p a r a los negocios.

12

CAPÍTULO 1

1.4.1 ¿Qué se de* be hacer si se tiene un software heredado con poca calidad?


Calidad del software h e r e d a d o

Por desgracia, existe una característica adicional que tal vez esté presente en el software heredado: poca calidad.5 Algunas veces, los sistemas heredados tienen diseños imposibles de extender, código complicado, documentación escasa o inexistente, casos de prueba y resultados que nunca fueron archivados, un historial de cambio manejado con pobreza, etcétera; la lista podría seguir hasta tener una longitud considerable. No obstante, estos sistemas son el soporte de "las funciones centrales de negocios y son indispensables para las empresas" [LIU98]. ¿Qué se puede hacer? La única respuesta razonable podría ser no hacer nada, al m e n o s hasta que el sistema heredado experimente algún cambio significativo. Pero si satisface las necesidades de sus usuarios y funciona de manera confiable, el sistema n o está roto y no requiere arreglos. Sin embargo, conforme pasa el tiempo, los sistemas heredados evolucionan por una o más de las razones siguientes: • El software debe adaptarse para satisfacer las necesidades de los nuevos ambientes o las nuevas tecnologías de cómputo.

f ¿Cuáles son • los tipos de cambios que se realizan sobre el software heredado?

• El software debe mejorarse para implementar los nuevos requerimientos de los negocios. • El software debe extenderse para hacerlo operable con sistemas y bases de datos más modernos. • El software debe rediseñarse para hacerlo viable dentro de un ambiente de red. Cuando suceden estas formas de evolución en un software heredado, éste debe someterse a una reingeniería (capítulo 31) de modo que conserve su viabilidad en el

ÔNSEJO^

Cualquier ingeniero de software debe reconoce! que el cambio es natural. No debe intentar combatirlo.

futuro. La meta de la ingeniería de software moderna es "imaginar metodologías que se basen en la noción de la evolución"; esto es, la noción de que "los sistemas de software cambian de manera continua, los nuevos sistemas de software se construyen a partir de los viejos, y... todos deben interactuar y cooperar con los demás" [DAY99].

1.4.2

Evolución del software

El software de computadora evoluciona a través del tiempo, sin importar su dominio de aplicación, t a m a ñ o o complejidad. El cambio (que con frecuencia es llamado mantenimiento del software) conduce este proceso, y se presenta cuando se corrigen

TM

errores, cuando el software se adapta a un nuevo ambiente, cuando el cliente solicita características o funciones nuevas, y cuando la aplicación experimenta una reingeniería para proporcionar beneficios en un contexto moderno. Sam Williams [WIL02] refiere esta situación cuando escribe:

PDF Editor 5

En este caso, la calidad se juzga con base en el pensamiento moderno de la ingeniería del software, que en cierto modo es un criterio injusto, puesto que algunos conceptos y principios modernos de la ingeniería del software aún no habían sido bien entendidos cuando se desarrolló el software heredado.

CAPITULO 1

13


Debido a q u e los p r o g r a m a s a gran escala c o m o Windows y Solaris se expanden bien en el intervalo de 30 a 50 millones d e líneas de código, los administradores d e proyecto exitosos h a n aprendido a dedicar tanto tiempo a combinar los e n r e d o s d e nuestro código her e d a d o c o m o a agregar código nuevo. Para decirlo de m a n e r a m á s simple, en u n a década en la que el d e s e m p e ñ o p r o m e d i o del microchip de PC se incrementó cien veces, la incapacidad de escalar el software incluso a t a s a s lineales ha p a s a d o de un p e q u e ñ o secreto a u n a e n o r m e alteración en toda la industria.

En los últimos 30 años, Manny Lehman [LEH97a] y sus colegas han analizado en forma detallada la industria del software y los sistemas en un esfuerzo dirigido a desarrollar una teoría unificada para la evolución del software. Los detalles de dicho trabajo superan el enfoque del presente texto, 6 pero las leyes subyacentes derivadas de su estudio son dignas de destacarse [LEH97b]: La ley d e l c a m b i o c o n t i n u o ( 1 9 7 4 ) . Los sistemas de tipo electrónico 7 deben adaptarse en forma continua, de lo contrario se volverán menos satisfactorios a través del tiempo. La ley d e la c o m p l e j i d a d c r e c i e n t e ( 1 9 7 4 ) . Cuando un sistema de tipo electrónico está en evolución, su complejidad se incrementa a m e n o s que se realice el trabajo necesario para mantenerla o reducirla. La ley d e la a u t o r r e g u l a c i ó n ( 1 9 7 4 ) . El proceso de evolución de un sistema de tipo electrónico se autorregula con la distribución del producto y las mediciones del proceso cercanas a la normal. La l e y d e la c o n s e r v a c i ó n d e la e s t a b i l i d a d o r g a n i z a c i o n a l ( 1 9 8 0 ) . La tasa de actividad global efectiva promedio en un sistema de tipo electrónico en evolución no varía a lo largo del periodo de vida del producto. La l e y d e la c o n s e r v a c i ó n d e la f a m i l i a r i d a d ( 1 9 8 0 ) . Cuando un sistema de tipo electrónico está en evolución y se quiere tener un desarrollo satisfactorio, todos los involucrados con el sistema, como los desarrolladores, el personal de ventas y los usuarios, deben mantener el dominio sobre su contenido y comportamiento. El crecimiento excesivo disminuye ese dominio. Por tanto, el crecimiento promedio perm a n e c e sin cambio durante la evolución del sistema. La ley d e l c r e c i m i e n t o c o n t i n u o ( 1 9 8 0 ) . El contenido funcional de los sistem a s de tipo electrónico debe incrementarse en forma continua para mantener la satisfacción del usuario a lo largo del periodo de vida del sistema.

TM

La ley d e la c a l i d a d d e c r e c i e n t e ( 1 9 9 6 ) . La calidad de los sistemas de tipo electrónico parecerá declinar a m e n o s que éstos se mantengan y adapten en forma rigurosa de acuerdo con los cambios en su ambiente operacional.

PDF Editor 6 7

Para una clara explicación de la evolución del software, el lector interesado puede revisar [LEH97a], Los sistemas de tipo electrónico son programas de software que han sido implementados en un contexto computacional del mundo real y que, por tanto, evolucionarán a través del tiempo.

CAPÍTULO 1

14


La l e y del s i s t e m a d e r e t r o a l i m e n t a c i ó n ( 1 9 9 6 ) . Los procesos de evolución de los sistemas de tipo electrónico constituyen sistemas d e retroalimentación con niveles, ciclos y agentes múltiples, y deben tratarse de forma que se obtengan mejorías significativas sobre cualquier base razonable. Las leyes que Lehman y sus colegas h a n definido s o n u n a p a r t e inherente de la realidad de un ingeniero de software. En lo sucesivo, en este texto se discutirán modelos para el proceso del software, m é t o d o s d e ingeniería de s o f t w a r e y técnicas de gestión que pretenden m a n t e n e r la calidad del s o f t w a r e mientras éste se e n c u e n t r a e n evolución. 1.5

M I T O S DKL S O F T W A R E Los mitos del software —creencias acerca del s o f t w a r e y de los procesos empleados para construirlo— se pueden rastrear hasta los primeros días de la computación. Los mitos tienen ciertos atributos que los convierten en insidiosos. Por ejemplo, los mitos parecen u n a relación de h e c h o s razonables (algunas veces contienen e l e m e n t o s verdaderos), se observan de m a n e r a intuitiva, y con frecuencia los promulgan practicantes experimentados, q u i e n e s "conocen el terreno".

"En ausencia de normas significativas, una industria nueva como el software suele c epender de los costumbres." Tom D e M a r c o

En la actualidad, la mayoría de los profesionales reconocidos e n la ingeniería del s o f t w a r e identifican los mitos en su real dimensión: actitudes equivocadas que h a n c a u s a d o problemas serios a los administradores y al personal técnico por igual. Sin embargo, las antiguas actitudes y viejos hábitos son difíciles de modificar, por lo que aún subsisten creencias falsas sobre el software. Referencia Web

Lo red de administradores de proyectos de soflwore puede ayudor a leiminar con éstos y otros mitos. Dicho red se puede encontrar en

M i t o s d e l a a d m i n i s t r a c i ó n . Los administradores con responsabilidades sobre el software, al igual que sus p a r e s en la mayoría de las disciplinas, a m e n u d o están bajo presión por m a n t e n e r los presupuestos, evitar q u e los itinerarios se extiendan y mejorar la calidad. De la misma forma que u n a persona a p u n t o de a h o g a r s e se aferra a un tronco, con frecuencia el administrador del software se aferra a un mito si

TM siente que esta creencia reducirá la presión (aun en forma temporal).

www.spmn.coni.

Mito:

Ya se tiene un libro lleno de estándares y procedimientos trucción de software. ¿Esto proporcionará

para la cons

a mi gente todo el conocimien-

PDF Editor to necesario?

R e a l i d a d : Tal vez sea verdad que el libro de e s t á n d a r e s existe, p e r o ¿se usa? ¿Los e n c a r g a d o s de la construcción del software s a b e n de su existencia? ¿El libro refleja la práctica m o d e r n a de la ingeniería del software? ¿Está completo? ¿Es adaptable? ¿Está dirigido al m e j o r a m i e n t o del tiem-

CAPÍTULO 1

SOFTWARE E INGENIERIA DEL SOFTWARE

15

p o de entrega sin dejar de enfocarse en la calidad? En muchos casos la respuesta a todas estas preguntas es no. Mito:

Si se está atrasado en el itinerario es posible contratar más programadores para así terminar a tiempo (algunas veces llamado el concepto de la horda mongola).

Realidad: El desarrollo de software no es un proceso mecánico como la manufactura. En palabras de Brooks [BR075]: "Agregar gente a un proyecto de software atrasado lo atrasa más". De inicio, este enunciado podría parecer contrario a la intuición. Sin embargo, cuando se agregan nuevos integrantes a un equipo la gente que ya estaba trabajando deb e invertir tiempo en la e n s e ñ a n z a a los recién llegados, lo cual reduce el tiempo dedicado al esfuerzo para el desarrollo productivo. Se puede agregar gente, pero sólo de una manera planeada y bien coordinada. Mito:

Si decido subcontratar el proyecto de software a un tercero, puedo relajarme y dejar que esa compañía lo construya.

Realidad: Si una organización n o entiende c ó m o administrar y controlar internamente los proyectos de software, de manera invariable entrará en conflicto al subcontratar este tipo de proyectos. £conscjo£.

i- resano trabajar É w para entender m se debe hacer ane s de comenzar. In xtsunes no es posí xúesarrollar todos o detalles, pero enr; tws se sepa, mexr es el riesgo que se

Mitos del cliente.

El cliente que solicita un software de computadora puede ser la

persona del escritorio de al lado, un grupo técnico en el piso de abajo, el departamento de ventas o de mercadotecnia, o una compañía externa que ha solicitado el software bajo contrato. En muchos casos, el cliente cree en mitos acerca del software porque los profesionales y administradores del software hacen muy poco para corregir la desinformación. Los mitos conducen a expectativas falsas (del cliente) y en definitiva a insatisfacción con el desarrollador. Mito:

Un enunciado general de los objetivos es suficiente para comenzar a escribir programas; los detalles se pueden afinar después.

Realidad: A pesar de que no siempre es factible que el enunciado de los requerimientos sea comprensible y estable, un enunciado ambiguo de los objetivos e s la receta perfecta para el desastre. Los requerimientos precisos (los cuales se derivan usualmente en forma iterativa) se desarrollan sólo mediante la comunicación continua y TM efectiva entre el cliente y el desarrollador.

PDF Editor Mito:

Los requerimientos

del proyecto cambian de manera continua, pero el

cambio puede ajustarse con facilidad porque el software es flexible.

Realidad: Es verdad que los requerimientos del software cambian, pero el impacto del cambio varía de acuerdo con el m o m e n t o en que éste se introduce. Cuando los cambios en los requerimientos s e solicitan en

16

CAPÍTULO 1


e t a p a s t e m p r a n a s (antes de iniciar con el diseño o el código), el impacto en el costo e s relativamente p e q u e ñ o . 8 Sin embargo, conforme pasa el tiempo, el impacto en el costo crece con rapidez —se h a n distribuido los recursos, se h a establecido un m a r c o general para el diseño— y el cambio p u e d e provocar u n a convulsión que requiera recursos adicionales y una modificación significativa en el diseño. Mitos del desarrollado!".

Los mitos que a ú n subsisten entre los d e s a b o l l a d o r e s

del s o f t w a r e han p e r m a n e c i d o a través de 50 a ñ o s de cultura de programación. Durante los primeros a ñ o s del software, la programación era vista c o m o u n a forma de arte; por ello, las viejas formas y actitudes son difíciles de eliminar. Mito:

Una vez que el programa está terminado.

ha sido escrito y puesto a funcionar,

el trabajo

R e a l i d a d : Alguien dijo alguna vez que entre m á s rápido se c o m i e n c e a escribir ^CONSEJO^

código, m á s tiempo pasará para que el p r o g r a m a esté terminado. Los

Siempre que se piense que no hay tiempo paro lo ingeniería del software, se debe considerar si habrá tiempo pora hacerlo todo de nuevo.

datos de la industria indican que entre 60 y 80 por ciento de t o d o el e s f u e r z o aplicado en el software se realizará d e s p u é s de que el sistem a haya sido entregado al cliente por primera vez. Mito:

Mientras el programa no se esté ejecutando, su calidad.

no existe forma de evaluar

R e a l i d a d : Uno de los m e c a n i s m o s m á s efectivos para el a s e g u r a m i e n t o de la calidad del software se puede aplicar desde el inicio de un proyecto: la revisión técnica formal. Las revisiones al software (descritas en el capítulo 26) son un "filtro de calidad" que han probado ser m á s efectivas que las pruebas para encontrar ciertas clases de errores en el software. Mito:

El único producto del trabajo que puede entregarse para tener un proyecto exitoso es el programa en funcionamiento.

R e a l i d a d : Un p r o g r a m a en f u n c i o n a m i e n t o es sólo u n a parte de la configuración del s o f t w a r e que incluye m u c h o s elementos. La documentación proporciona un f u n d a m e n t o para la ingeniería exitosa y, a ú n m á s importante, representa u n a guía para el m a n t e n i m i e n t o del software. Mito:

La ingeniería del software obligará a emprender la creación de una documentación voluminosa lento el proceso.

e innecesaria y de manera invariable tornará más TM

R e a l i d a d : La ingeniería del s o f t w a r e no se refiere a la elaboración de d o c u m e n -

PDF Editor

tos. Está relacionada con la creación de calidad. Una mejor calidad

8

Muchos ingenieros de software han adoptado un enfoque "ágil" que adapta los cambios en forma incremental, con lo que se controla su impacto y costo. Los métodos ágiles se exponen en el capítulo 4.

CAPÍTULO 1


17

conduce a la reducción de los trabajos redundantes. Y una m e n o r cantidad de trabajos redundantes resulta en menores tiempos de entrega. Muchos profesionales de los sistemas reconocen la falacia de los mitos del software. Por el contrario, las actitudes y los métodos habituales conducen a adoptar malas prácticas administrativas y técnicas, a pesar de que la realidad exige un m e jor enfoque. El reconocimiento de las realidades del software es el primer p a s o hacia la formulación de soluciones prácticas para la ingeniería del software.

Cualquier proyecto de software se inicia por alguna necesidad de negocios: la necesidad de corregir un defecto en una aplicación existente; el imperativo de adaptar un sistema heredado a un ambiente de negocios cambiante; el requerimiento de extender las funciones y características de una aplicación existente; o la necesidad de crear un producto, servicio o sistema nuevos. Con frecuencia, en el inicio de un proyecto de ingeniería del software la necesidad de negocios se expresa de manera informal durante una simple conversación. En el recuadro que está abajo se presenta una conversación típica. Con excepción de una referencia pasajera, el software n o se mencionó durante la conversación. Aun así, el software hará la diferencia en el futuro de la línea de productos HogarSeguro. El mercado aceptará el producto sólo si el software incrustado en él satisface de manera apropiada las necesidades del cliente (que aún n o ha sido definido). En los capítulos subsecuentes se dará seguimiento a la ingeniería del softw a r e en HogarSeguro.

HOGARSEGURO 9

Cómo se inicia un proyecto La e s c e n a : Sala de ¡untas en CPI , una compañía (ficticia! que fabrica productos de «erjumo para uso comercial y doméstico.

1

La conversación: Joe: Dime Lee, ¿de qué se trata ese asunto que escuché? ¿Tu equipo está desarrollando un qué? ¿Una caja inalámbrica genérica universal? * -

Los actores: Mal Golden, gerente general, desarrollo de pro3 . r e ; lisa Pérez, gerente de mercadotecnia; tee Warren, gerenLee: Es genial, como del tamaño de una caja de cerillos, se pueTM * de ingeniería; Joe Camalleri, vicepresidente ejecutivo, desarrollo de conectar a sensores de todos los tipos, una cámara digital, CO-e negocios. j SÍ a cualquier cosa. Usando el protocolo 802.1 Ib inalámbrico.

PDF Editor 9

El proyecto HogarSeguro se usará a lo largo de este texto para ilustrar los trabajos internos de un equipo de proyecto, mientras éste construye un producto de software. La compañía, el proyecto y las personas son ficticios, pero las situaciones y los problemas son reales.

18

CAPÍTULO 1


Nos permite tener acceso a lo salida del dispositivo sin usar cables. Pensamos que nos llevará a una nueva generación de productos, , • ' '¡'y' ,, , fli • .

casa, control de aparatos e instrumentos. Tú sabes, apagar el aire acondicionado de tu casa mientras estas manejando, y ese tipo de cosos • f' ^

Joe: ¿Estás de acuerdo, Mal?

Lee (interrumpiendo): Ingeniería hizo un estudio de factibilidad de esta idea, Joe. Se puede realizar a un bajo costo de manufactura. La mayor parte del hardware lo tenemos en existencia. El software es un asunto por resolver, pero nada que no podamos hacer.

Mol; Sí. De hecho, por las ventas tan irregulares que ha habido este año, necesitamos algo nuevo. Lisa y yo hemos estado haciendo una pequeña investigación de mercado, y pensamos que tenemos una línea de productos que podría llegar a ser grande. Joe: ¿Qué tan grande? ¿Como para ser una línea básica? Atol (evitando un compromiso directa): Dile de nuestra idea, Lisa. Lisa: Es toda una nueva generación de lo que llamamos "productos para la administración doméstica". Los llamamos HogarSegtiro. Utilizan la nueva interfase inalámbrica, proporcionan a los usuarios domésticos o dueños de negocios pequeños un sistema que se controla con su PC: seguridad en el hogar, vigilancia de la

1.7

J o e : Interesante. Ahora, pregunté sobre la línea básica. Mal: Las PC han penetrado el 60 por ciento de los hogares en Estados Unidos. Si logramos ponerle el precio adecuado a esta cosa, podría ser una aplicación demoledora. Nadie más tiene nuestra caja inalámbrica; nos pertenece. Tendremos una ventajo dedos años sobre la competencia. ¿Ganancias? Podrían ser entre 30 y 40 millones de dólares en el segundo año. Joe (sonriendo): Vamos a llevar esto al siguiente nivel. Estoy interesado.

RESUMEN El software se ha convertido en el elemento clave de la evolución de los sistemas y productos basados en computadoras, así como en una de las tecnologías más importantes en el ámbito mundial. En los pasados 50 años, el software ha evolucionado desde ser una herramienta para la solución de problemas especializados y el análisis de información, hasta convertirse en una industria por sí mismo. Todavía s e tienen problemas al desarrollar software de alta calidad a tiempo y dentro del presupuesto. El software —programas, datos y documentos— se dirige a un amplio espectro de tecnologías y áreas de aplicación. En la actualidad el software evoluciona de acuerdo con un conjunto de leyes que han permanecido inalteradas a lo largo de 30 años. La intención de la ingeniería del software es proporcionar un marco general para construir software con una calidad mucho mayor.

REFERENCIAS

TM

[BR0751 Brooks, F., The Mythical Man~Month, Addison-Wesley, 1995. |DAC03] Daconta, M„ L. Obrst y K. Smith, The Semantic Web, Wiley, 2003. IDAY99] Dayani-Fard, H. el al., "Legacy Software Systems: Issues, Progress, and Challenges", IBM Technical Report: TR-74. 165-k, abril de 1999, disponible en h t t p : / / w w w . c a s . i b m . c o m / toronto/publications/TR-74.165/k/legacy.html. IDEM951 DeMarco, T„ Why Does Software Cosí So Much?, Dorset House, 1995. |FEI83|Feigenbaum, E. A. y P. McCorduck, The Fifth Generation, Addison-Wesley, 1983. IHAM93] Hammer, M. y J. Champy, Recingineering the Corporation, HarperCollins Publishers, 1993.

PDF Editor

CAPÍTULO 1


19

[JOHO1 ] Johnson, S., Emergence: The Connected Uves ofAnts, Brains, Cities and Software, Scribner, 2 0 0 1 . [KAR99] Karlson, E. y J. Kolber, A Basic Introduction to Y2K. How theyear 2000 Computer Crisis Affects YOU, Next Era Publications, Inc, 1999. [LEH97a] L e h m a n , M y L. Belady, Program Evolution: Processes of Software Change, Academic Press, 1997. [LEH97b] Lehman, M. eí al., "Metrics and Laws of S o f t w a r e Evolution—The Nineties View", en Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997, puede descargarse de h t t p : / / w w w . e c e . u t e x a s . e d u / ~ p e r i y / w o r k / p a p e r s / f e a s t l . p d f . [LEV95] Levy, S., "The Luddites Are Back", en Newsweek, 12 d e julio de 1995, p. 55. [LIP02] Lippman, A., "Round 2.0", en Context Magazine, a g o s t o de 2002, h t t p : / / w w w . c o n t e x t mag.com/. [LIU98] Liu, K. eí al., "Report on t h e First SEBPC Workshop on Legacy Systems", Durham University, f e b r e r o d e 1998, disponible en h t t p : / / w w w . d u r . a c . u k / C S M / S A B A / l e g a c y - w k s p l / report.html. [OSB79) O s b o r n e , A., Running Wild—The Next Industrial Revolution, Osborne/McGraw-Hill, 1979. [NAI821 Naisbitt,)., Megatrends, Warner Books, 1982. [STO891 Stoll, C., The Cuckoo's Egg, Doubleday, 1989. |TOF80|Tof(ler, A., The Third Wave, Morrow Publishers, 1980. [TOF90] Toffler, A. Powershift, Bantam Publishers, 1990. [WIL02] Williams, S., "A Unified Theory of Software Evolution", en salon.com, 2002. h t t p : / / w w w . salón.com/tech/feature/2002/04/08/lehman/index.html. [WOL02] Wolfram, S., A New Kind of Science, Wolfram Media, Inc., 2002. [YOU92] Yourdon, E., The Decline and Fall of the American Programmer, Yourdon Press, 1992. IYOU96] Yourdon, E., The Rise and Resurrection of the American Programmer, Yourdon Press, 1996. |YOU98a] Yourdon, E. y J. Yourdon, Time Bomb 2000, Prentice-Hall, 1998. [YOU98b] Yourdon, E., Death March Projects, Prentice-Hall, 1999. [YQU02] Yourdon, E., Byte Wars, Prentice-Hall, 2002.

1 . 1 . Encontrar al m e n o s cinco e j e m p l o s adicionales d e la m a n e r a en q u e la ley d e las c o n s e cuencias imprevistas se aplica al software d e c o m p u t a d o r a . 1 . 2 . Encontrar a l g u n o s ejemplos (positivos y negativos) q u e indiquen el impacto del s o f t w a r e en la sociedad actual. Revisar u n a d e las referencias anteriores a 1990 en la sección 1.1, e indicar las p r e d i c c i o n e s del a u t o r q u e resultaron correctas, asi c o m o las q u e f u e r o n e r r ó n e a s . 1.3. Desarrollar s u s propias respuestas a las preguntas formuladas en la sección 1.1. Debátanse con los c o m p a ñ e r o s d e clase. 1.4. ¿La definición d e software que se presenta en la sección 1.2 se aplica a los sitios Web? Si la respuesta es afirmativa, indicar la sutil diferencia entre un sitio Web y el software convencional. 1 . 5 . M u c h a s aplicaciones m o d e r n a s c a m b i a n f r e c u e n t e m e n t e (antes d e presentarlas al u s u a TM a l g u n a s formas rio final y d e s p u é s d e q u e se e m p i e z a a utilizar la primera versión). Sugiéranse de construir software para detener el deterioro debido al cambio. 1 . 6 . C o n s i d é r e n s e las s i e t e c a t e g o r í a s p r e s e n t a d a s e n la sección 1.3. ¿Es posible aplicar el m i s m o e n f o q u e d e la ingeniería del s o f t w a r e a c a d a u n a de ellas? Explicar la r e s p u e s t a .

PDF Editor

1 . 7 . Seleccionar a l g u n o d e los n u e v o s r e t o s m e n c i o n a d o s en la sección 1.3 (o algún d e s a f í o aún m á s n u e v o q u e pudiera haber surgido desde la impresión d e e s t e texto) y escribir un d o c u m e n t o de u n a cuartilla q u e describa la tecnología y los retos q u e representa para los ingenieros d e software.

20

CAPITULO 1


1 . 8 . Describir c o n p a l a b r a s p r o p i a s la ley de la conservación (sección 1.4.2). 1.9. Describir con p a l a b r a s propias la ley de la conservación

de la estabilidad de la familiaridad

1 . 1 0 . Describir c o n p a l a b r a s propias la ley de la calidad decreciente

organizacional (sección 1.4.2.).

(sección 1.4.2,).

1 . 1 1 . A medida q u e la p r e s e n c i a del s o f t w a r e s e vuelve m á s generalizada, los riesgos al público (debido a las fallas e n los programas) r e p r e s e n t a n u n a preocupación significativa y creciente. Desarrollar u n e s c e n a r i o c a t a s t r ó f i c o realista en el q u e la falla d e u n p r o g r a m a de c o m p u tadora podría producir u n gran d a ñ o (ya s e a e c o n ó m i c o o h u m a n o ) . 1 . 1 2 . E x a m i n a r c o n a t e n c i ó n al g r u p o d e noticias d e I n t e r n e t c o m p . r i s k y p r e p a r a r u n r e s u m e n d e los riesgos al público q u e s e han discutido r e c i e n t e m e n t e . Fuente alternativa: Software Engineering Note publicada por la ACM.

O T R A S L E C T U R A S Y F U E N T E S DE I N F O R M A C I Ó N 1 0 Existen miles de libros que tratan s o b r e el s o f t w a r e d e c o m p u t a d o r a . La i n m e n s a mayoría discute los l e n g u a j e s de p r o g r a m a c i ó n o las aplicaciones del software, p e r o m u y p o c o s tratan del s o f t w a r e en sí mismo. P r e s s m a n y Herrón (Software Shock, Dorset House, 1991) p r e s e n t a n u n o d e los primeros d e b a t e s (dirigidos al público en general) del s o f t w a r e y d e la forma en que los profesionales lo construyen. El libro m á s vendido de Negroponte (Being Digital, Alfred A. Knopf, Inc., 1995) ofrece u n a visión d e la c o m p u t a c i ó n y su i m p a c t o global e n el siglo xxi. DeMarco [DEM95] ha escrito u n a colección de e n s a y o s divertidos y p r o f u n d o s a c e r c a del s o f t w a r e y del p r o c e s o a través del cual éste s e desarrolla. Los libros de Norman (The Invisible Computer, MIT Press, 1998) y Bergman (Information Appliances and Beyond, Academic P r e s s / M o r g a n Kaufm a n n , 2000) sugieren q u e el impacto extendido d e las PC disminuirá c o n f o r m e los i n s t r u m e n tos de información y la computación omnipresente conecten a todos en el m u n d o industrializado y casi cualquier "aparato" que s e p o s e a esté c o n e c t a d o a u n a n u e v a infraestructura de Internet. Minasi (The Software Conspiracy: Why Software Companies Put Out Faulty Products, How They Can Hurt You, and What You Can Do, McGraw-Hill, 2000) a r g u m e n t a b a q u e la "plaga m o d e r n a " de las i m p u r e z a s del s o f t w a r e s e puede eliminar y sugiere f o r m a s d e lograrlo. C o m p a i n e (Digital Divide: Facing a Crisis or Creating a Myth, MIT Press, 2001) escribe que la "brecha" entre a q u e llos que tienen a c c e s o a los r e c u r s o s de información (como la Web) y los que n o lo tienen s e está reduciendo c o n f o r m e a v a n z a la primera d é c a d a del p r e s e n t e siglo. En Internet existe u n a amplia variedad de f u e n t e s d e información s o b r e tópicos relacionados con el s o f t w a r e y su administración. Asimismo, en n u e s t r o sitio w e b s e p u e d e e n c o n t r a r u n a lista actualizada de r e c u r s o s en la red que son relevantes para el estudio del software: http:/ / w w w . mhhe. c o m / pressman.

TM 10 La sección Otras lecturas yfuentes

de información que se presenta al final de cada capítulo ofrece un

PDF Editor

breve panorama de las fuentes impresas que pueden ayudarle a aumentar su comprensión de los temas principales presentados en este capítulo. Hemos creado un sitio de internet muy extenso para apoyar Ingeniería del sojbvare: un enfoque práctico en http://www.mhhe.com/pressman. Entre los muchos tópicos incluidos se encuentran referencias capítulo por capítulo sobre ingeniería del software existentes en la red que complementan del material presentado en cada capitulo. Con estas referencias se proporciona un enlace con Amazon.com para localizar los libros que se mencionan en cada sección.

P A R T E

Uno EL PROCESO DEL SOFTWARE

E

n esta parte de Ingeniería del software• un enfoque práctico se estudiará el proceso que proporciona un marco de trabajo para la práctica de la ingeniería del software. En los capítulos siguientes se responden estas preguntas: • ¿Qué es un proceso de software? • ¿Cuáles son las actividades del marco general presentes en todos los procesos del software? • ¿Cómo se modelan los procesos y cuáles son los patrones del proceso? • ¿Cuáles son los modelos de proceso prescriptivo y cuáles son sus fortalezas y debilidades? • ¿Cuáles son las características de los modelos incrementales que los hacen idóneos para los proyectos modernos de software? • ¿Qué es el proceso unificado? • ¿Por qué la "agilidad" es un lema en el trabajo de la ingeniería moderna del software? ív TM • ¿Qué es el desarrollo ágil del software y cómo difiere de los modelos de proceso más tradicionales?

PDF Editor

Cuando se respondan estas preguntas se estará mejor preparado para entender el contexto en el cual se aplica la práctica de la ingeniería del software. 21

C A P I T U L O

EL P R O C E S O : U N A V I S I Ó N GENERAL CONCEPTOS CLAVE actividades sombrilla

28

E

|n u n f a s c i n a n t e libro q u e o f r e c e la visión d e u n e c o n o m i s t a sobre el s o ñ w a r e y la ingeniería del s o f t w a r e , H o w a r d Baetjer, Jr. [BAE981 c o m e n t a s o bre el p r o c e s o del s o f t w a r e :

D e b i d o a q u e el s o f t w a r e , c o m o c u a l q u i e r capital, e s c o n o c i m i e n t o m a t e r i a l i z a d o , y

conjunto de t a r e a s

27

d a d o q u e el c o n o c i m i e n t o en u n inicio e s disperso, tácito, l a t e n t e y e n g r a n m e d i d a

evaluación del proceso

36

e s u n diálog o e n el c u a l el c o n o c i m i e n t o q u e el s o f t w a r e d e b e convertir s e c o n j u n t a y

IMCM

29

i n c o m p l e t o , el d e s a r r o l l o del s o f t w a r e e s u n p r o c e s o d e a p r e n d i z a j e social. El p r o c e s o

ISO 9 0 0 1 : 2 0 0 0 . 3 8 marco de trabajo del proceso 24 patrones del procesa

se m a t e r i a l i z a e n e s t e último. El p r o c e s o p r o p o r c i o n a interacción e n t r e l o s u s u a r i o s y las h e r r a m i e n t a s en evolución, y entre los d i s e ñ a d o r e s y sus herramientas [tecnología]. Es u n p r o c e s o iterativo e n el q u e la h e r r a m i e n t a en e v o l u c i ó n sirve c o m o u n m e d i o p a r a la c o m u n i c a c i ó n , en el cual c a d a n u e v a e t a p a del d i á l o g o logra o b t e n e r m á s c o n o c i m i e n t o útil d e l a s p e r s o n a s implicadas.

34

De h e c h o , la c o n s t r u c c i ó n del s o f t w a r e d e c o m p u t a d o r a e s u n p r o c e s o itera

PSE

.40

tivo d e a p r e n d i z a j e , y el resultado, a l g o q u e Baetjer llamaría "el capital del soft

PSP

39

ware", e s u n a materialización del c o n o c i m i e n t o r e c o l e c t a d o , d e p u r a d o y orga

tecnología del proceso

42

n i z a d o c o n f o r m e el p r o c e s o e s t u v o e n ejecución.

¿ Q u é e s ? Cuando se trabaja para construir un producto o sistema es importante seguir una serie de pasos predecibtes: una especie de mapa de carreteras que ayude a crear un resultado de alta calidad y a tiempo. El mapa de carreteras que debe seguirse se llama proceso de software. ¿ Q u i é n l o h a c e ? Los ingenieros d e software y sus jefes adaptan el proceso a sus necesidades y después lo siguen. Además, la gente que ha solicitado el software tiene una función qué desempeñar en el proceso d e definirlo, construirlo y probarlo. sí ¿ P o r q u é e s i m p o r t a n t e ? Porque ofrece esta bilidad, control y organización a una actividad que puede volverse caótica si no se controla. Sin e m b a r g a un enfoque d e ingeniería del software moderno debe ser "ágil". Debe requerir sólo aquellas actividades, controles y documentaciones apropiados para el equipo del proyecto y el producto que ha d e producirse.

¿ C u á l e s s o n los p a s o s ? En detalle, el proceso que se adopte depende del software que se está construyendo. Un proceso puede ser apropiado para crear un software para un sistema de aeronáutica, mientras que un proceso distinto por completo sería el indicado para la creación de un sitio Web.

¿Cuál e s el producto obtenido? Desde el punto de vista del ingeniero d e software, los productos obtenidos son los programas, documentos y datos que se producen como consecuencia d e las actividades y tareas definidas • por el proceso.

¿Cómo p u e d o estar seguro dTM e que lo he h e c h o c o r r e c t a m e n t e ? Existen muchos mecanismos de evaluación del proceso de software que permiten a las organizaciones determinar la "madurez" del proceso de software. No obstante, la calidad, el tiempo requerido, la viabilidad a largo plazo del producto que se construye son los mejores indicadores de la eficacia del proceso que se utiliza. |

PDF Editor 22

CAPÍTULO 2

23

EL PROCESO: U N A VISIÓN GENERAL

Pero, ¿ q u é e s c o n e x a c t i t u d u n p r o c e s o d e s o f t w a r e d e s d e u n p u n t o d e vista t é c nico? D e n t r o del c o n t e x t o d e e s t e libro, u n proceso

de software

se define c o m o un

m a r c o d e t r a b a j o p a r a las t a r e a s q u e s e r e q u i e r e n e n la c o n s t r u c c i ó n de s o f t w a r e de alta calidad. ¿El p r o c e s o e s un s i n ó n i m o d e i n g e n i e r í a del s o f t w a r e ? La r e s p u e s t a e s sí y n o . Un p r o c e s o d e s o f t w a r e d e f i n e el e n f o q u e q u e se a d o p t a m i e n t r a s el s o f t w a re e s t á e n d e s a r r o l l o . P e r o la i n g e n i e r í a del s o f t w a r e t a m b i é n a b a r c a las t e c n o l o g í a s q u e r e q u i e r e el p r o c e s o ( m é t o d o s t é c n i c o s y h e r r a m i e n t a s a u t o m a t i z a d a s ) . A ú n m á s i m p o r t a n t e e s q u e la ingeniería del s o f t w a r e la r e a l i z a n p e r s o n a s creativas y con conocimiento que deben trabajar en un proceso de software m a d u ro q u e s e a a p r o p i a d o p a r a el p r o d u c t o q u e c o n s t r u y e n y p a r a l a s d e m a n d a s de s u s mercados.

2.1

I N G E N I E R Í A DEL S O F T W A R E : U N A T E C N O L O G Í A E S T R A T I F I C A D A A p e s a r de q u e c i e n t o s de a u t o r e s h a n d e f i n i d o e n f o r m a individual la ingeniería software,

del

la defi ni ci ón q u e p r o p u s o Fritz B a u e r [NAU69] e n u n a c o n f e r e n c i a f u n d a -

m e n t a l s o b r e la m a t e r i a a ú n s e p u e d e utilizar c o m o b a s e p a r a el d e b a t e : [La ingeniería del s o f t w a r e es] el e s t a b l e c i m i e n t o y u s o d e principios sólidos d e la ingeniería p a r a o b t e n e r e c o n ó m i c a m e n t e un s o f t w a r e confiable y q u e f u n c i o n e de m o d o eficiente e n m á q u i n a s reales.

Casi cualquier lector s e sentirá t e n t a d o a s u m a r o t r a s ideas a e s t a definición. Dice p o c o s o b r e los a s p e c t o s técnicos de la calidad del s o f t w a r e ; n o s e refiere de m a n e r a directa a la n e c e s i d a d d e satisfacer al cliente o al t i e m p o d e e n t r e g a d e u n p r o d u c t o ; o m i te m e n c i o n a r la i m p o r t a n c i a de la medición y la métrica; n o e s t a b l e c e la i m p o r t a n c i a de un p r o c e s o efectivo. No o b s t a n t e , la definición d e Bauer o f r e c e u n a idea básica. ¿Cuáles s o n "los principios sólidos de la ingeniería" q u e p u e d e n aplicarse en el d e s a rrollo del s o f t w a r e d e c o m p u t a d o r a ? ¿De q u é m a n e r a s e c o n s t r u y e " e c o n ó m i c a m e n t e " u n s o f t w a r e "confiable"? ¿ Q u é se requiere p a r a c r e a r p r o g r a m a s de c o m p u t a d o r a q u e f u n c i o n e n "de m a n e r a eficiente" n o s ó l o e n u n a , s i n o e n varias " m á q u i n a s reales" difer e n t e s ? Estas i n t e r r o g a n t e s c o n t i n ú a n s i e n d o u n reto p a r a los ingenieros d e s o f t w a r e . "Más que una disciplina o un cuerpo de conocimiento, la ingeniería es un verbo, una palabra d e acción, una m a n e r a de abordar un problema." Scott Whítraire

TM El IEEE [IEE93] h a e l a b o r a d o u n a definición m á s c o m p r e n s i b l e al e s t a b l e c e r : A *

¿Cómo se defínela

Ingeniería del software: I) La aplicación de un enfoque sistemático, disciplinado y cuanti-

PDF Editor w software?

ficable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software. 2) El estudio de enfoques como en 1).

Y a u n así, lo q u e e s "sistemático, disciplinado" y "cuantificable" p a r a u n e q u i p o de soft-

w a r e , p u e d e s e r g r a v o s o p a r a otro. Se r e q u i e r e de disciplina, p e r o t a m b i é n d e a d a p tabilidad y agilidad.

PAKTE UNO

24

EL PROCESO DEL SOFTWARE

Estratos d e la ingeniería d e software.

La ingeniería del s o f t w a r e e s u n a t e c n o l o g í a e s t r a t i f i c a d a . C o m o s e m u e s t r a e n la figura 2.1, c u a l q u i e r e n f o q u e d e la i n g e n i e r í a (incluido el de la i n g e n i e r í a del s o f t w a re) d e b e e s t a r s u s t e n t a d o e n u n c o m p r o m i s o c o n la calidad. La Gestión d e la Calidad Total, S i g m a Seis y e n f o q u e s s i m i l a r e s f o m e n t a n u n a c u l t u r a d e m e j o r a c o n t i n u a del p r o c e s o , y e s e s t a c u l t u r a la q u e al final c o n d u c e al d e s a r r o l l o d e e n f o q u e s m u y e f e c tivos p a r a la i n g e n i e r í a del s o f t w a r e . La b a s e q u e s o p o r t a la i n g e n i e r i a del s o f t w a r e

CLAVE La ingeniería del software abarca un proteso, métodos y herramientas.

e s u n enfoque

en la calidad.

La b a s e de la i n g e n i e r í a del s o f t w a r e e s el e s t r a t o del proceso.

El p r o c e s o d e la in-

g e n i e r í a del s o f t w a r e e s el e l e m e n t o q u e m a n t i e n e j u n t o s los e s t r a t o s d e la t e c n o l o gía y q u e p e r m i t e el d e s a r r o l l o r a c i o n a l y a t i e m p o del s o f t w a r e d e c o m p u t a d o r a . El p r o c e s o d e f i n e u n m a r c o d e t r a b a j o [PAU93] q u e d e b e e s t a b l e c e r s e p a r a la e n t r e g a efectiva d e la t e c n o l o g í a d e la i n g e n i e r í a del s o f t w a r e . El p r o c e s o del s o f t w a r e f o r m a la b a s e p a r a el c o n t r o l d e la g e s t i ó n de los p r o y e c t o s d e s o f t w a r e y e s t a b l e c e el c o n t e x t o e n el c u a l s e a p l i c a n los m é t o d o s t é c n i c o s , s e g e n e r a n los p r o d u c t o s del t r a b a jo ( m o d e l o s , d o c u m e n t o s , d a t o s , r e p o r t e s , f o r m a t o s , e t c é t e r a ) , s e e s t a b l e c e n los f u n d a m e n t o s , s e a s e g u r a la c a l i d a d , y el c a m b i o s e m a n e j a d e m a n e r a a p r o p i a d a . Los métodos

d e la ingeniería del s o f t w a r e p r o p o r c i o n a n los " c ó m o " t é c n i c o s p a r a

construir s o f t w a r e . Los m é t o d o s a b a r c a n u n a m p l i o e s p e c t r o de t a r e a s q u e incluyen la c o m u n i c a c i ó n , el análisis d e requisitos, el m o d e l a d o del d i s e ñ o , la c o n s t r u c c i ó n del p r o g r a m a , la realización d e p r u e b a s y el soporte. Los m é t o d o s d e la ingeniería del s o f t -

CrossMesuno

w a r e s e b a s a n e n u n c o n j u n t o d e principios b á s i c o s q u e g o b i e r n a n c a d a á r e a d e la tecnología e incluye a c t i v i d a d e s de m o d e l a d o y o t r a s t é c n i c a s descriptivas. Las herramientas

d e la i n g e n i e r í a del s o f t w a r e p r o p o r c i o n a n el s o p o r t e a u t o m a t i -

z a d o o s e m i a u t o m a t i z a d o p a r a el p r o c e s o y l o s m é t o d o s . C u a n d o l a s h e r r a m i e n t a s s e i n t e g r a n d e f o r m a q u e la i n f o r m a c i ó n q u e c r e e u n a de e l l a s p u e d a u s a r l a o t r a , s e

www.stsc hiH.af.mil.

d i c e q u e s e h a e s t a b l e c i d o u n s i s t e m a p a r a el s o p o r t e d e l d e s a r r o l l o d e l s o f t w a r e , q u e c o n f r e c u e n c i a s e d e n o m i n a i n g e n i e r í a del software

TM

asistida por computadora.

PDF Editor 2.2

MARCO

DE T R A B A J O P A R A EL P R O C E S O

Un marco de trabajo e s t a b l e c e la b a s e p a r a u n p r o c e s o d e s o f t w a r e c o m p l e t o al i d e n tificar u n n ú m e r o p e q u e ñ o d e actividades

del marco de trabajo a p l i c a b l e s a t o d o s l o s

p r o y e c t o s d e s o f t w a r e , sin i m p o r t a r s u t a m a ñ o o c o m p l e j i d a d . A d e m á s , el m a r c o d e : r a b a j o del p r o c e s o a b a r c a u n c o n j u n t o d e actividades ¿e! p r o c e s o del s o f t w a r e .

sombrilla

a p l i c a b l e s a lo l a r g o

CAPÍTULO 2

25


P r o c e s o del s o f t w a r e

Un m a r c o d e trabajo del proceso d e software.

M a r c o d e t r a b a j o del p r o c e s o A c t i v i d a d e s sombrilla Actividad del m a r c o d e t r a b a j o # 1 acción d e la ingeniería d e software # 1 . 1 Conjunto de tareas

t o r e o s del t r a b a j o producios del t r a b a j o punios d e a s e g u r a m i e n t o d e la c a l i d a d f u n d a m e n t o s del p r o y e c t o

acción d e la ingeniería d e software #1 .k Conjunto de tareas

toreas del frabojo p r o d u c t o s del t r a b a j o puntos d e a s e g u r a m i e n t o d e lo c a l i d a d f u n d a m e n t o s del p r o y e c t o

Actividad del m a r c o d e t r a b a j o # n acción de la ingeniería del software #n.l Conjunto d e tareas

t a r e a s del t r a b a j o productos del trabajo puntos d e aseguramiento d e la c a l i d a d fundamentos del proyecto

acción d e lo ingeniería d e software #n.m Conjunto d e tareas

t o r e a s del t r a b o j o p r o d u c t o s del t r a b a j o puntos d e aseguramiento d e lo c a l i d a d f u n d a m e n t o s del p r o y e c t o

C o m o s e m u e s t r a e n la figura 2.2, c a d a actividad d e n t r o del m a r c o c o n t i e n e un c o n j u n t o de acciones

de ingeniería

del software-, es decir, u n a s e r i e dTM e tareas relacio-

n a d a s q u e p r o d u c e u n p r o d u c t o del t r a b a j o e n la ingeniería

del software

(por e j e m p l o ,

el d i s e ñ o e s u n a a c c i ó n d e la ingeniería del s o f t w a r e ) . C a d a a c c i ó n la f o r m a n tareas

PDF Editor

de trabajo i n d i v i d u a l e s q u e c o m p l e t a n a l g u n a p a r t e del t r a b a j o i m p l i c a d o por la a c ción.

"Un proceso define quién está haciendo qué, cuándo y cómo lograr cierta m e t a . " Ivar Jacobson, Grady Booch y J a m e s Rumbaugh

26

PARTE UNO


El s i g u i e n t e marco

de trabajo genérico

del proceso

(utilizado c o m o b a s e p a r a la

d e s c r i p c i ó n d e l o s m o d e l o s d e p r o c e s o e n los c a p í t u l o s s u b s e c u e n t e s ) s e p u e d e aplic a r e n la i n m e n s a m a y o r í a d e los p r o y e c t o s d e s o f t w a r e : 9 ¿Cuáles * son las cinco actividades del marco de t r a b a j o del proceso general?

C o m u n i c a c i ó n . Esta act i vi dad del m a r c o d e t r a b a j o implica u n a i n t e n s a c o l a b o r a c i ó n y c o m u n i c a c i ó n c o n l o s clientes; 1 a d e m á s , a b a r c a la i n v e s t i g a c i ó n de requisitos y otras actividades relacionadas. P l a n e a c i ó n . Esta act i vi dad e s t a b l e c e u n p l a n p a r a el t r a b a j o d e la ingeniería del s o f t w a r e . D e s c r i b e las t a r e a s t é c n i c a s q u e d e b e n r e a l i z a r s e , los r i e s g o s p r o b a b l e s , los r e c u r s o s q u e s e r á n r e q u e r i d o s , l o s p r o d u c t o s del t r a b a j o q u e h a n d e p r o d u c i r s e y un programa de trabajo. M o d e l a d o . Esta act i vi dad a b a r c a la c r e a c i ó n d e m o d e l o s q u e p e r m i t e n al d e s a rrollador y al cl i ente e n t e n d e r m e j o r los r e q u i s i t o s del s o f t w a r e y el d i s e ñ o q u e logrará s a t i s f a c e r l o s . C o n s t r u c c i ó n . Esta act i vi dad c o m b i n a la g e n e r a c i ó n del c ó d i g o (ya s e a m a n u a l o a u t o m a t i z a d o ) y la r e a l i z a c i ó n de p r u e b a s n e c e s a r i a s p a r a d e s c u b r i r e r r o r e s e n el código. D e s p l i e g u e . El s o f t w a r e ( c o m o u n a e n t i d a d c o m p l e t a o u n i n c r e m e n t o c o m p l e t a d o de m a n e r a parcial) s e e n t r e g a al cliente, q u i e n e v a l ú a el p r o d u c t o recibido y p r o p o r c i o n a i n f o r m a c i ó n b a s a d a e n su e v a l u a c i ó n . E s t a s c i n c o a c t i v i d a d e s g e n é r i c a s del m a r c o d e t r a b a j o s o n útiles d u r a n t e el d e s a r r o llo d e p r o g r a m a s p e q u e ñ o s , la c r e a c i ó n d e g r a n d e s a p l i c a c i o n e s e n la red, y e n la ing e n i e r í a d e s i s t e m a s b a s a d o s e n c o m p u t a d o r a s g r a n d e s y c o m p l e j a s . Los d e t a l l e s del p r o c e s o del s o f t w a r e s e r á n m u y d i f e r e n t e s e n c a d a c a s o , p e r o l a s a c t i v i d a d e s d e n t r o del m a r c o p e r m a n e c e r á n iguales. "Eínstein argumentaba que debía existir una explicación simplificada de la naturaleza porque Oíos no es caprichoso ni arbitrario. Tol f e no conforta al ingeniero del software. Mucha de la complejidad que debe maniobrar es de carácter arbitrario." Fred Brooks Si s e u s a u n e j e m p l o d e r i v a d o del m a r c o de t r a b a j o g e n é r i c o del p r o c e s o , la a c t i vidad d e elaboración w a r e : análisis y diseño.

del modelo

la c o m p o n e n d o s a c c i o n e s d e la i n g e n i e r í a del s o f t -

El a n á l i s i s 2 a b a r c a u n c o n j u n t o d e t a r e a s d e tTM r a b a j o (por e j e m -

plo, la i n v e s t i g a c i ó n , e l a b o r a c i ó n , n e g o c i a c i ó n , e s p e c i f i c a c i ó n y v a l i d a c i ó n d e r e q u i sitos) q u e c o n d u c e n a la c r e a c i ó n del m o d e l o de a n á l i s i s (o a la e s p e c i f i c a c i ó n de re-

PDF Editor

1. Un cliente es cualquier persona que tiene un interés en el éxito del resultado del proyecto: gerentes de negocios, usuarios finales, gente de apoyo, etcétera. Rob Thomset bromea diciendo que "un cliente (en inglés stakeholder) es una persona que sostiene una estaca (stakc) grande y afilada... si

no cuidas a tus clientes, ya sabes dónde terminará la estaca". 2. El análisis se explicará con mayor detenimiento en los capítulos 7 y 8.

CAPÍTULO 2 quisitos)

27


El d i s e ñ o a b a r c a t a r e a s d e t r a b a j o ( d i s e ñ o d e d a t o s , d i s e ñ o a r q u i t e c t ó n i -

co, d i s e ñ o d e i n t e r f a z y d i s e ñ o al nivel d e c o m p o n e n t e s ) q u e c r e a n u n m o d e l o d e di-

CLAVE l e n a s proyectos i diferentes s de toreas. E aqñpo de software í « é conjunto de u e c s con base en s j o b l e m a y en las nrectefísticos del

s e ñ o (una e s p e c i f i c a c i ó n d e d i s e ñ o ) . 3 C o m o t a m b i é n s e a p r e c i a e n la figura 2.2, c a d a a c c i ó n d e la ingeniería del s o f t w a re la r e p r e s e n t a u n g r a n n ú m e r o de d i f e r e n t e s conjuntos

de tareas: u n a serie d e ta-

r e a s d e t r a b a j o , p r o d u c t o s r e l a c i o n a d o s , p u n t o s p a r a el a s e g u r a m i e n t o d e la c a l i d a d y f u n d a m e n t o s de p r o y e c t o d e n t r o d e la ingeniería del s o f t w a r e . El c o n j u n t o d e t a r e a s q u e m e j o r se a j u s t e a las n e c e s i d a d e s del p r o y e c t o y a las c a r a c t e r í s t i c a s del e q u i p o e s el q u e s e e s c o g e al final. E s t o implica q u e u n a a c c i ó n d e la ingeniería del s o f t w a r e ( c o m o el d i s e ñ o ) s e p u e d e a d a p t a r a las n e c e s i d a d e s e s p e c í f i c a s del p r o y e c t o d e s o f t w a r e y a las c a r a c t e r í s t i c a s del e q u i p o d e p r o y e c t o . INFORMACIÓN

Conjunto de tareas Un conjunto de tareas define el t r a b a j o real que d e b e realizarse p a r a cumplir los objetivos d e j n a occión d e ingeniería del software. Por ejemplo, la -ecopilación d e requisitos" es una acción importante d e la -geniería del software q u e ocurre durante la actividad d e comunicación. La meta de la reunión d e requisitos es entender qué desean los distintos clientes del software que se va a construir. Para un proyecto pequeño, al parecer simple, el conjunto d e tareas p a r a la recopilación d e requisitos nuede ser como se enumera a continuación: 1. Hacer una lista d e los clientes p a r a el proyecto. 2

Invitar a todos los clientes a una reunión informal.

3. Pedir a c a d a cliente que h a g a una lista d e características y funciones requeridas. 4. Establecer un d e b a t e sobre los requisitos y elaborar una lista final. 5

Priorizar los requisitos.

6. Advertir las á r e a s d e incertidumbre. :ara

un proyecto d e software mayor y más complejo, se -equeriría un conjunto diferente d e tareas. Este p u e d e -ckiir la siguiente lista: 1

Hacer una lista d e los clientes p a r a el proyecto.

2- Entrevistar a c a d a uno d e los clientes, por s e p a r a d o , p a r a determinar d e manera general sus deseos y necesidades.

3. Elaborar una lista preliminar d e las funciones y características b a s a d a s en la información que ofrezcan los clientes. 4. Hacer un programa d e reuniones p a r a recopilar los requisitos. 5. Conducir las reuniones. ó. Producir escenarios informales d e los usuarios como parte d e c a d a reunión. 7. Refinar escenarios d e los usuarios con base en el intercambio de información con los clientes. 8. Elaborar una lista revisada d e los requisitos d e los clientes. 9. Utilizar técnicas d e despliegue d e funciones d e calidad p a r a jerarquizar los requisitos. 10. Empaquetar los requisitos p a r a q u e puedan entregarse de manera incremental. 11. Observar las restricciones q u e serán puestas en el sistema. 12. Debatir métodos p a r a validar el sistema. Ambos conjuntos d e tareas consiguen la recopilación de requisitos, pero son muy diferentes en cuanto a profundidad y formalidad. El equipo d e software elige el conjunto d e tareas q u e permitirá alcanzar la meta d e c a d a

TM

actividad del proceso y acción d e ingeniería del software q u e mantenga la calidad y agilidad.

PDF Editor 3

Cabe aclarar q u e "la elaboración del modelo" debe interpretarse de un m o d o diferente c u a n d o se realiza el mantenimiento de un software existente. En algunos casos ocurre el modelado del diseño y el

análisis, pero en otras situaciones de mantenimiento se le utiliza para ayudar a entender el software heredado, al igual q u e p a r a representar adiciones o modificaciones en éste.

28

PARTE UNO


El m a r c o d e t r a b a j o d e s c r i t o e n la visión g e n e r a l d e la i n g e n i e r í a d e s o f t w a r e lo c o m p l e t a u n a s e r i e d e actividades

\CLAVE Las actividades sombrilla ocurren a lo largo del proceso de s o f t w a r e y se enfocan de m o d o principal en la gestión, el rastreo y el control del proyecto.

sombrilla.

Las a c t i v i d a d e s típicas e n e s t a c a t e g o r í a

incluyen: S e g u i m i e n t o y c o n t r o l d e l p r o y e c t o d e s o f t w a r e : p e r m i t e q u e el e q u i p o de s o f t w a r e e v a l ú e el p r o g r e s o c o m p a r á n d o l o c o n el p l a n del p r o y e c t o y así t o m a r l a s a c c i o n e s n e c e s a r i a s p a r a m a n t e n e r el p r o g r a m a . G e s t i ó n d e l r i e s g o : e v a l ú a los r i e s g o s q u e p u d i e r a n a f e c t a r los r e s u l t a d o s del p r o y e c t o o la calidad del p r o d u c t o . A s e g u r a m i e n t o d e la c a l i d a d d e l s o f t w a r e : d e f i n e y c o n d u c e las a c t i v i d a d e s r e q u e r i d a s p a r a a s e g u r a r la calidad del s o f t w a r e . R e v i s i o n e s t é c n i c a s f o r m a l e s : e v a l ú a los p r o d u c t o s del t r a b a j o d e la i n g e n i e ría del s o f t w a r e e n u n e s f u e r z o e n c a m i n a d o a d e s c u b r i r y e l i m i n a r los e r r o r e s a n t e s

\ CLAVE l a adaptación del proceso de s o f t w a r e e s esencial pora el éxito del proyecto.

d e q u e é s t o s s e p r o p a g u e n h a c i a la s i g u i e n t e a c c i ó n o actividad. M e d i c i ó n : d e f i n e y recolecta m e d i c i o n e s del p r o c e s o , el p r o y e c t o y el p r o d u c t o p a r a a y u d a r al e q u i p o a e n t r e g a r s o f t w a r e q u e s a t i s f a g a l a s n e c e s i d a d e s del cliente; s e p u e d e u s a r e n c o n j u n t o c o n t o d a s l a s o t r a s a c t i v i d a d e s del m a r c o d e t r a b a j o o a c tividades sombrilla. G e s t i ó n d e l a c o n f i g u r a c i ó n d e l s o f t w a r e : m a n e j a los e f e c t o s del c a m b i o a t r a v é s del p r o c e s o del s o f t w a r e . G e s t i ó n d e l a r e u t i l i z a c i ó n : d e f i n e los criterios p a r a la reutilización de p r o d u c t o s del t r a b a j o (se incluyen c o m p o n e n t e s del s o f t w a r e ) y e s t a b l e c e m e c a n i s m o s p a ra la c r e a c i ó n d e c o m p o n e n t e s reutilizables. P r e p a r a c i ó n y p r o d u c c i ó n d e l p r o d u c t o d e t r a b a j o : a b a r c a las a c t i v i d a d e s r e q u e r i d a s p a r a c r e a r p r o d u c t o s del t r a b a j o c o m o m o d e l o s , d o c u m e n t o s , registros, f o r m a t o s y listas. Las a c t i v i d a d e s s o m b r i l l a s e a p l i c a n d u r a n t e el p r o c e s o del s o f t w a r e y s e t r a t a n c o n d e t a l l e e n c a p í t u l o s p o s t e r i o r e s de e s t e texto. T o d o s los m o d e l o s d e p r o c e s o s e c a r a c t e r i z a n d e n t r o del m a r c o del p r o c e s o m o s t r a d o en la figura 2.2. La a p l i c a c i ó n i n t e l i g e n t e d e c u a l q u i e r m o d e l o d e p r o c e s o del s o f t w a r e d e b e r e c o n o c e r q u e la a d a p t a c i ó n (al p r o b l e m a , p r o y e c t o , e q u i p o y a la c u l tura o r g a n i z a c i o n a l ) e s e s e n c i a l p a r a el éxito d e e s t a a c t i v i d a d . P e r o los m o d e l o s d e p r o c e s o difieren de m a n e r a f u n d a m e n t a l e n : •

TM

El flujo global de a c t i v i d a d e s y t a r e a s , y l a s i n t e r d e p e n d e n c i a s e n t r e las a c tividades y las tareas.

PDF Editor •

i ¿De qué manera difieren los modelos del proceso e n t r e s i ?

El g r a d o e n el c u a l las t a r e a s de t r a b a j o e s t á n d e f i n i d a s d e n t r o d e c a d a a c -

tividad del m a r c o d e t r a b a j o .

•

El g r a d o e n el c u a l s e i d e n t i f i c a n y s e solicitan los p r o d u c t o s de t r a b a j o .

•

La f o r m a e n la q u e s e aplican l a s actividades d e a s e g u r a m i e n t o d e la calidad.

•

La m a n e r a e n la q u e s e a p l i c a n l a s a c t i v i d a d e s d e s e g u i m i e n t o y control.

CAPÍTULO 2

29

EL PROCESO. U N A V E I Ó N GENERAL

•

El g r a d o g e n e r a l d e detalle y el rigor c o n el q u e se d e s c r i b e el p r o c e s o .

•

El g r a d o e n el q u e los c l i e n t e s e s t á n c o m p r o m e t i d o s c o n el p r o y e c t o .

•

El g r a d o d e a u t o n o m í a o t o r g a d o al e q u i p o d e p r o y e c t o d e s o f t w a r e .

•

El g r a d o e n el c u a l e s t á n d e f i n i d o s la o r g a n i z a c i ó n y las r e s p o n s a b i l i d a d e s e n el e q u i p o .

"Siento que una rec eto es sólo un lema con el que un cocinero inteligente pue de jugar cada vez de una manera distinta." M a d a m a Benoit Los m o d e l o s d e p r o c e s o q u e e n f a t i z a n la definición, la identificación y la a p l i c a c i ó n d e t a l l a d a d e l a s a c t i v i d a d e s del p r o c e s o h a n s i d o a p l i c a d o s d e n t r o d e la c o m u n i d a d d e la i n g e n i e r í a del s o f t w a r e e n l o s ú l t i m o s 3 0 a ñ o s . La a p l i c a c i ó n d e e s t o s modelos prescríptivos

i n t e n t a m e j o r a r la calidad del s i s t e m a , h a c e r q u e los p r o y e c t o s s e a n m á s

m a n e j a b l e s , q u e las f e c h a s de e n t r e g a y los c o s t o s s e a n m á s p r e d e c i b l e s , y g u i a r a los e q u i p o s de i n g e n i e r o s d e s o f t w a r e m i e n t r a s r e a l i z a n el t r a b a j o q u e r e q u i e r e c o n s truir u n s i s t e m a . Por d e s g r a c i a , h a h a b i d o o c a s i o n e s e n q u e e s t o s o b j e t i v o s n o s e h a n a l c a n z a d o . Si los m o d e l o s p r e s c r i p t i v o s s e a p l i c a n e n f o r m a d o g m á t i c a y sin n i n g u n a a d a p t a c i ó n , é s t o s p u e d e n i n c r e m e n t a r el g r a d o d e b u r o c r a c i a a s o c i a d a c o n la construcción de sistemas b a s a d o s en computadoras, y de m a n e r a inadvertida crear d i f i c u l t a d e s p a r a los d e s a r r o l l a d o r e s y los clientes. En a ñ o s r e c i e n t e s s e h a n p r o p u e s t o m o d e l o s d e p r o c e s o q u e s u b r a y a n la agilidad

r

del p r o y e c t o y s i g u e n un c o n j u n t o d e principios, 4 los c u a l e s c o n d u c e n a u n e n f o q u e caracteriza

m

^ s i n f o r m a l p a r a el p r o c e s o del s o f t w a r e (dicho e n f o q u e n o e s m e n o s efectivo, s e -

oceso

g ú n a r g u m e n t a n q u i e n e s lo p r o p u s i e r o n ) . E s t o s modelos

"?

m a n e j a b i l i d a d y a d a p t a b i l i d a d . S o n a p r o p i a d o s p a r a m u c h o s tipos d e p r o y e c t o s y s o n

ágiles del proceso r e s a l t a n la

útiles de m a n e r a p a r t i c u l a r c u a n d o se d e s a r r o l l a n a p l i c a c i o n e s e n la red. ¿Cuál de l o s e n f o q u e s p a r a el p r o c e s o del s o f t w a r e e s el m e j o r ? Esta p r e g u n t a ha o c a s i o n a d o u n d e b a t e e m o c i o n a l e n t r e los i n g e n i e r o s de s o f t w a r e y s e a b o r d a r á e n el c a p í t u l o 4. Por a h o r a , e s i m p o r t a n t e d a r s e c u e n t a d e q u e e s t o s d o s e n f o q u e s de p r o c e s o t i e n e n u n a m e t a c o m ú n : c r e a r s o f t w a r e d e alta c a l i d a d q u e s a t i s f a g a l a s n e c e s i d a d e s del cliente, p e r o t i e n e n p e r s p e c t i v a s d i f e r e n t e s .

'••lícílKer.í w W c i ' )

l O w i i j

•

WnBBBmSBRtM " ff ' j i l

El I n s t i t u t o d e Ingeniería del S o f t w a r e (SEI, por s u s s i g l a s e n inglés) ha d e s a r r o l l a d o

TM

u n m o d e l o c o m p l e t o de u n a m p l i o p r o c e s o b a s a d o en u n c o n j u n t o de c a p a c i d a d e s de software y de sistemas que deben estar presentes conforme las organizaciones a l c a n z a n d i f e r e n t e s g r a d o s d e c a p a c i d a d y m a d u r e z del p r o c e s o . El SEI s o s t i e n e q u e

PDF Editor

p a r a lograr e s t a s c a p a c i d a d e s u n a o r g a n i z a c i ó n d e b e c r e a r u n m o d e l o d e p r o c e s o (fig u r a 2.2) q u e s e a j u s t e a las d i r e c t r i c e s e s t a b l e c i d a s por la integración capacidad 4

de madurez

(IMCM) [CMM02].

Los modelos ágiles y los principios que los guían se explican en el capítulo 4

del modelo

de

PARTE UNO

30

EL P R O C E S O DEL S O F T W A R E

Perfil d e c a p a cidad del á r e a del proceso de la IMCM [PHI02].

pp

Planeación del proyecto

GR

Gestión d e requisitos

MA

Medición y análisis Gestión d e la configuración

GC ACPP

A s e g u r a m i e n t o d e la calidad d e l p r o d u c t o y el p r o c e s o

1 s -8

I

Z

GR

MA

GC

ACPP

Área del proceso

La IMCM r e p r e s e n t a u n m o d e l o c o m p l e t o d e p r o c e s o e n d o s f o r m a s d i f e r e n t e s : 1) c o m o u n m o d e l o c o n t i n u o y 2 ) c o m o u n m o d e l o d i s c r e t o . El m o d e l o c o n t i n u o IMCM d e s c r i b e u n p r o c e s o e n d o s d i m e n s i o n e s , c o m o s e ilustra e n la figura 2.3. C a d a á r e a Referencia

W e b

Uno "mfoimadón

del p r o c e s o (por e j e m p l o , la p l a n e a c i ó n del p r o y e c t o o la g e s t i ó n d e los requisitos) se e v a l ú a d e m a n e r a f o r m a l c o n t r a las m e t a s y p r á c t i c a s e s p e c í f i c a s y s e clasifica d e a c u e r d o c o n los s i g u i e n t e s n i v e l e s d e c a p a c i d a d :

IMCM p u e d e obleneise en

http://www.seL cmu.ed.ii/anmi/.

N i v e l O: I n c o m p l e t o . El á r e a del p r o c e s o (por e j e m p l o , la g e s t i ó n d e requisitos) a ú n n o s e realiza o t o d a v í a n o a l c a n z a t o d a s las m e t a s y o b j e t i v o s d e f i n i d o s p a r a el nivel 1 d e c a p a c i d a d . N i v e l 1: R e a l i z a d o . T o d a s las m e t a s e s p e c í f i c a s del á r e a del p r o c e s o ( c o m o las d e f i n i ó la IMCM) h a n s i d o s a t i s f e c h a s . Las t a r e a s d e t r a b a j o r e q u e r i d a s p a r a p r o d u cir el p r o d u c t o e s p e c í f i c o h a n s i d o r e a l i z a d a s . N i v e l 2 : A d m i n i s t r a d o . T o d o s los criterios del nivel 1 h a n s i d o s a t i s f e c h o s . Adem á s , t o d o el t r a b a j o a s o c i a d o c o n el á r e a de p r o c e s o s e a j u s t a a u n a política o r g a n i z a c i o n a l definida; t o d a la g e n t e q u e e j e c u t a el t r a b a j o t i e n e a c c e s o a r e c u r s o s a d e c u a d o s p a r a r e a l i z a r su labor; los c l i e n t e s e s t á n i m p l i c a d o s de m a n e r a a c t i v a e n el área de proceso, c u a n d o esto se requiere; todas las tareas de trabajo y productos está n " m o n i t o r e a d o s , c o n t r o l a d o s y r e v i s a d o s ; y s o n e v a l u a d o s e n a p e g o a la d e s c r i p ción del p r o c e s o " [CMM02].

TM

N i v e l 3 : D e f i n i d o . T o d o s los c r i t e r i o s del nivel 2 s e h a n c u m p l i d o . A d e m á s , el p r o c e s o e s t á " a d a p t a d o al c o n j u n t o de p r o c e s o s e s t á n d a r d e la o r g a n i z a c i ó n , de

PDF Editor

a c u e r d o c o n l a s políticas de a d a p t a c i ó n d e e s t a m i s m a , y c o n t r i b u y e a la i n f o r m a c i ó n d e los p r o d u c t o s del t r a b a j o , m e d i c i o n e s y o t r a s m e j o r í a s del p r o c e s o p a r a los activ o s del p r o c e s o o r g a n i z a c i o n a l " [CMM02],

N i v e l 4 : A d m i n i s t r a d o e n f o r m a c u a n t i t a t i v a . T o d o s los criterios del nivel 3

h a n s i d o c u m p l i d o s . A d e m á s , el á r e a del p r o c e s o s e c o n t r o l a y m e j o r a m e d i a n t e m e d i c i o n e s y e v a l u a c i ó n c u a n t i t a t i v a . "Los o b j e t i v o s c u a n t i t a t i v o s p a r a la calidad y el

CAPÍTULO 2

31


d e s e m p e ñ o del p r o c e s o e s t á n e s t a b l e c i d o s y s e utilizan c o m o u n criterio p a r a a d m i n i s t r a r el p r o c e s o " [CMM02], N i v e l 5: M e j o r a d o . T o d o s los criterios del nivel 4 h a n s i d o s a t i s f e c h o s . A d e m á s , el á r e a del p r o c e s o "se a d a p t a y m e j o r a m e d i a n t e el u s o d e m e d i o s c u a n t i t a t i v o s (estadísticos) p a r a c o n o c e r las n e c e s i d a d e s c a m b i a n t e s del cliente y m e j o r a r de m a n e ra c o n t i n u a la eficacia del á r e a del p r o c e s o q u e s e e s t á c o n s i d e r a n d o " [CMM02],

"Gran parte de ia crisis del software es autoinfligida, como cuando CIO dice: "Prefiero que esté mal a que esté tarde. Siempre podemos repararlo después." M a r k Paulk

(CONSEJOâx orgomzotión ¡alo IMCM. Se ¡nbargo, la 3Bc aspecto del -axto puede sei £Gsw en algunas

La IMCM d e f i n e c a d a á r e a del p r o c e s o e n f u n c i ó n de " m e t a s e s p e c í f i c a s " y de las " p r á c t i c a s e s p e c í f i c a s " r e q u e r i d a s p a r a a l c a n z a r d i c h a s m e t a s . Las metas específicas e s t a b l e c e n l a s c a r a c t e r í s t i c a s q u e d e b e n existir p a r a q u e las a c t i v i d a d e s i m p l i c a d a s p o r u n á r e a d e p r o c e s o s e a n e f e c t i v a s . Las prácticas

específicas

convierten una meta

e n u n c o n j u n t o d e a c t i v i d a d e s r e l a c i o n a d a s c o n el p r o c e s o . Por e j e m p l o , la p l a n e a c i ó n d e l p r o y e c t o e s u n a d e las o c h o á r e a s del p r o c e s o d e f i n i d a s p o r la IMCM p a r a la c a t e g o r í a d e " g e s t i ó n del proyecto". 5 Las m e t a s e s p e cíficas (ME) y l a s p r á c t i c a s e s p e c í f i c a s a s o c i a d a s (PE) q u e s e h a n d e f i n i d o p a r a la p l a n e a c i ó n del p r o y e c t o s o n [CMM02]: ME 1 E s t a b l e c e r e s t i m a c i o n e s PE 1.1-1 E s t i m a r el a l c a n c e del p r o y e c t o . PE 1.2-1 E s t a b l e c e r e s t i m a c i o n e s p a r a los a t r i b u t o s del p r o d u c t o y las t a r e a s del t r a b a j o . PE 1.3-1 Definir el ciclo de vida del p r o y e c t o . PE 1.4-1 D e t e r m i n a r e s t i m a c i o n e s de e s f u e r z o y c o s t o . ME 2 D e s a r r o l l a r u n p l a n d e p r o y e c t o PE 2.1-1 E s t a b l e c e r el p r e s u p u e s t o y el p r o g r a m a . PE 2.2-1 Identificar los r i e s g o s del p r o y e c t o . PE 2.3-1 P l a n e a r la g e s t i ó n d e los d a t o s . PE 2.4-1 P l a n e a r los r e c u r s o s del p r o y e c t o . PE 2.5-1 P l a n e a r los c o n o c i m i e n t o s y h a b i l i d a d e s q u e s e r e q u i eTM ren. PE 2.6-1 P l a n e a r la p a r t i c i p a c i ó n del cliente. PE 2.7-1 E s t a b l e c e r el plan de p r o y e c t o .

PDF Editor 5

Otras áreas del proceso definidas como "gestión del proyecto" incluyen: monitoreo y control del proyecto, gestión de acuerdos con proveedores, gestión integrada del proyecto para IPPD, gestión del riesgo, integración del equipo, gestión de integración del proveedor y gestión cuantitativa del proyecto.

32

PARTE UNO


ME 3 C o m p r o m e t e r s e c o n l a p l a n e a c i ó n PE 3.1-1 Revisar los p l a n e s q u e a f e c t a n el p r o y e c t o . PE 3.2-1 Conciliar el t r a b a j o y los n i v e l e s d e r e c u r s o s . PE 3.3-1 C o m p r o m e t e r s e c o n la p l a n e a c i ó n A d e m á s d e las m e t a s y p r á c t i c a s e s p e c í f i c a s , la IMCM t a m b i é n d e f i n e u n a s e r i e d e c i n c o m e t a s g e n é r i c a s y p r á c t i c a s r e l a c i o n a d a s c o n c a d a á r e a del p r o c e s o . C a d a u n a d e las m e t a s g e n é r i c a s c o r r e s p o n d e a u n o d e los c i n c o n i v e l e s d e c a p a c i d a d . Por lo t a n t o , p a r a lograr u n nivel d e c a p a c i d a d p a r t i c u l a r s e d e b e a l c a n z a r la m e t a g e n é r i c a p a r a e s e nivel y l a s p r á c t i c a s g e n é r i c a s q u e c o r r e s p o n d e n a e s a m e t a . P a r a ilustrar lo a n t e r i o r , a c o n t i n u a c i ó n s e e n u m e r a n l a s m e t a s g e n é r i c a s (MG) y l a s p r á c t i c a s g e n é r i c a s (PG) p a r a el á r e a del p r o c e s o d e p l a n e a c i ó n del p r o y e c t o [CMM02J: MG 1 A l c a n z a r l a s m e t a s e s p e c i f i c a s PG 1.1 Realizar p r á c t i c a s b a s e . MG 2 I n s t i t u c i o n a l i z a r u n p r o c e s o d e g e s t i ó n PG 2.1 E s t a b l e c e r u n a política o r g a n i z a c i o n a l . Referencia Web

Una información completo, asi como

PG 2.2 P l a n e a r el p r o c e s o . PG 2.3 P r o p o r c i o n a r r e c u r s o s . PG 2.4 A s i g n a r r e s p o n s a b i l i d a d e s .

obtenerse en www.sei.tnu. edu/tmmi/.

PG 2.5 C a p a c i t a r g e n t e . PG 2.6 M a n e j a r c o n f i g u r a c i o n e s . PG 2.7 Identificar y h a c e r p a r t i c i p a r a c l i e n t e s . PG 2.8 M o n i t o r e a r y c o n t r o l a r el p r o c e s o . PG 2 . 9 E v a l u a r la a d h e r e n c i a de u n m o d o objetivo. PG 2.10 Revisar el e s t a t u s c o n un a l t o g r a d o d e gestión. MG 3 I n s t i t u c i o n a l i z a r u n p r o c e s o d e f i n i d o PG 3.1 E s t a b l e c e r un p r o c e s o definido. PG 3.2 R e c o l e c t a r i n f o r m a c i ó n d e la m e j o r í a . MG 4 I n s t i t u c i o n a l i z a r u n p r o c e s o m a n e j a d o e n f o r m a c u a n t i t a t i v a PG 4.1 E s t a b l e c e r o b j e t i v o s c u a n t i t a t i v o s p a r a el p r o c e s o . PG 4.2 Estabilizar el d e s e m p e ñ o del s u b p r o c e s o . MG 5 I n s t i t u c i o n a l i z a r u n p r o c e s o d e m e j o r a m i e n t o .

TM

PG 5.1 A s e g u r a r la m e j o r a c o n t i n u a del p r o c e s o . PG 5.2 Corregir l a s c a u s a s d e los p r o b l e m a s d e s d e la raíz

PDF Editor

El m o d e l o d i s c r e t o d e la IMCM d e f i n e l a s m i s m a s á r e a s , m e t a s y p r á c t i c a s del p r o -

c e s o q u e el m o d e l o c o n t i n u o . La principal d i f e r e n c i a e s q u e el m o d e l o d i s c r e t o e s t a b l e c e c i n c o n i v e l e s d e m a d u r e z , e n v e z d e c i n c o n i v e l e s d e c a p a c i d a d . Para lograr un nivel de m a d u r e z s e d e b e n c o n s e g u i r m e t a s y p r á c t i c a s e s p e c í f i c a s r e l a c i o n a d a s c o n un c o n j u n t o d e á r e a s del p r o c e s o . La r e l a c i ó n e n t r e los n i v e l e s d e m a d u r e z y las

á r e a s del p r o c e s o s e m u e s t r a n e n la figura 2.4.

CAPITULO 2

33


INFORMACIÓN

La IMCM: ¿se debe o no hacer?

mas grandes y complejos que impliquen docenas o cientos

La IMCM es un modelo total del proceso. Defi-

d e personas por varios meses o años. Es posible que la

ne (en alrededor d e 7 0 0 páginas) las caracte-

cas del proceso que deben existir si una organización establecer un proceso d e software completo. La pre-

que se ha debatido durante una d é c a d a es ¿la IMCM a excesiva? Como la mayor parte d e las cosas en la vida (y an el software) la respuesta no es un simple sí o no. Siempre d e b e adoptarse el espíritu d e la IMCM. Frente 3

esgo d e la simplificación excesiva, se argumenta que el

re-arrollo del software d e b e tomarse con seriedad: d e b e cxanearse; d e b e controlarse d e manera uniforme; d e b e — ;~earse con precisión; d e b e conducirse de manera pro• s o n a l . Debe centrarse en las necesidades d e los clientes o s proyecto, las habilidades d e los ingenieros d e software • la calidad del producto terminado. N a d i e d e b e poner en d u d a estas ¡deas. -os requisitos detallados d e la IMCM deben tomarse en : _enta con seriedad si una organización construye siste-

Áreas del requeridas p e a alcanzar i c nivel d e scxtuiez.

IMCM sea correcta en ciertas situaciones, si la cultura organizacional es flexible frente a modelos d e procesos estándares y se realiza una gestión p a r a lograr que sea un éxito. N o obstante, en otras situaciones 3S posible q u e la IMCM sea demasiado p a r a que una organización la asimile d e manera exitosa. ¿Esto significa q u e la IMCM e s mala o demasiado burocrática o q u e está p a s a d a d e mod a ? No. Tan sólo significa q u e lo correcto p a r a la cultura d e una compañía puede no serlo p a r a otra. La IMCM es un logro significativo p a r a la ingeniería del software. Proporciona una exposición integral de las activid a d e s y acciones q u e deben estar presentes c u a n d o una organización construye un software d e computadora. Aun si una organización d e software elige no a d o p t a r sus detalles, todo equipo de software d e b e retomar su espíritu y aprender d e su exposición del proceso y la práctica d e la ingeniería del software.

Nivel

Enfoque

De optimización

Mejora continua del proteso

Innovación o r g a n i z a c i o n a l y d e s p l i e g u e Análisis c a u s a l y resolución

Gestión cuantitativa

Ejecución del p r o c e s o o r g a n i z a c i o n a l Gestión cuantitativa del p r o y e c t o

Gestionado de m o d o cuantitativo

Definido

Estandarización del proceso

Á r e a s del p r o c e s o

Desarrollo d e requisitos Solución técnica Integración del p r o d u c t o Verificación Validación Enfoque d e l p r o c e s o o r g a n i z a c i o n a l Definición del p r o c e s o o r g a n i z a c i o n a l Capacitación o r g a n i z a c i o n a l Gestión i n t e g r a d a del p r o y e c t o Gestión i n t e g r a d a del p r o v e e d o r Gestión del r i e s g o Análisis y resolución d e la d e c i s i ó n A m b i e n t e o r g a n i z a c i o n a l p a r aTM la i n t e g r a c i ó n Equipo i n t e g r a d o Gestión d e requisitos P l a n e a c i ó n del p r o y e c t o M o n i t o r e o y control del p r o y e c t o Gestión d e a c u e r d o s del p r o v e e d o r Medición y a n á l i s i s A s e g u r a m i e n t o d e la c a l i d a d del producto y del p r o c e s o Gestión d e la c o n f i g u r a c i ó n

PDF Editor Gestionado

Ejecutado

Gestión básica del proyecto

34

PASTE UNO

EL PROCESO D A SOFTWARE

P A T R O N E S DEL P P O C E S O ¿ Q u é es un • patrón del proceso?

El p r o c e s o d e s o f t w a r e p u e d e d e f i n i r s e c o m o u n a c o l e c c i ó n d e p a t r o n e s q u e d e f i n e n un conjunto de actividades, acciones, tareas de trabajo o comportamientos relacion a d o s [AMB98] q u e r e q u i e r e el d e s a r r o l l o d e u n s o f t w a r e d e c o m p u t a d o r a . Dicho e n t é r m i n o s g e n e r a l e s , un patrón de proceso

o f r e c e u n a plantilla: u n m é t o d o c o n s i s t e n -

t e p a r a describir u n a c a r a c t e r í s t i c a i m p o r t a n t e del p r o c e s o de s o f t w a r e . M e d i a n t e la combinación de patrones, un equipo de software puede construir un proceso que satisfaga lo m e j o r p o s i b l e l a s n e c e s i d a d e s de u n p r o y e c t o . "Lo repetición de potrones es muy distinto o la repetición de partes. Además, las portes diferentes serán únicas porque los patrones son únicos." Christopher Alexander Los p a t r o n e s p u e d e n d e f i n i r s e e n c u a l q u i e r g r a d o d e a b s t r a c c i ó n . 6 En a l g u n o s c a s o s s e p u e d e utilizar u n p a t r ó n p a r a describir u n p r o c e s o c o m p l e t o (por e j e m p l o , u n prototipo). En o t r a s s i t u a c i o n e s se utilizan los p a t r o n e s p a r a describir u n a actividad del m a r c o d e t r a b a j o i m p o r t a n t e ( c o m o la p l a n e a c i ó n ) o u n a t a r e a d e n t r o d e u n a a c tividad del m a r c o d e t r a b a j o (por e j e m p l o , la e s t i m a c i ó n d e u n p r o y e c t o ) . A m b l e r [AMB98] p r o p u s o la siguiente plantilla p a r a describir un p a t r ó n d e p r o c e s o : N o m b r e d e l p a t r ó n . Al p a t r ó n s e le a s i g n a u n n o m b r e significativo q u e d e s c r i b a s u

CÚVVE Uno plantillo del potrón ofrece un m e d i o consistente pora describir un potrón.

f u n c i ó n d e n t r o del s o f t w a r e ( c o m o c o m u n i c a c i ó n c o n e l c l i e n t e ) . P r o p ó s i t o . Se d e s c r i b e c o n b r e v e d a d el o b j e t i v o del p a t r ó n . Por e j e m p l o , el objetiv o d e la c o m u n i c a c i ó n c o n e l c l i e n t e e s " e s t a b l e c e r u n a r e l a c i ó n d e c o l a b o r a c i ó n c o n el c l i e n t e e n u n e s f u e r z o e n c a m i n a d o a definir el a l c a n c e del p r o y e c t o , los requisitos del n e g o c i o y o t r a s c o n d i c i o n e s del p r o y e c t o " . El p r o p ó s i t o p u e d e e x p a n d i r s e c o n t e x t o s e x p l i c a t o r i o s a d i c i o n a l e s y d i a g r a m a s a p r o p i a d o s , si s e r e q u i e r e n . T i p o . Se e s p e c i f i c a el t i p o d e p a t r ó n . A m b l e r [AMB98] s u g i e r e t r e s tipos: •

Los patrones

de tarea d e f i n e n u n a a c c i ó n d e la i n g e n i e r í a del s o f t w a r e o

u n a t a r e a d e t r a b a j o q u e e s p a r t e del p r o c e s o y r e l e v a n t e p a r a u n a p r á c t i c a e x i t o s a d e la i n g e n i e r í a del s o f t w a r e (por e j e m p l o , la r e c o p i l a c i ó n d e r e q u i s i t o s e s un patrón de tarea). •

Los patrones

de escenario

d e f i n e n u n a actividad del m a r c oTM de trabajo para

el p r o c e s o . D e b i d o a q u e u n a actividad del m a r c o d e t r a b a j o r e ú n e múltip l e s t a r e a s d e t r a b a j o , u n p a t r ó n de e s c e n a r i o i n c o r p o r a m ú l t i p l e s p a t r o -

PDF Editor

n e s d e t a r e a r e l e v a n t e s p a r a el e s c e n a r i o (actividad del m a r c o de t r a b a j o ) . Un e j e m p l o del p a t r ó n d e e s c e n a r i o e s la c o m u n i c a c i ó n . E s t e p a t r ó n inc o r p o r a r í a el p a t r ó n d e t a r e a r e u n i ó n d e r e q u i s i t o s y o t r o s .

6

Los patrones se aplican a muchas actividades de ingeniería del software. El análisis, el diseño y los patrones de prueba se explican en los capítulos 7, 9, 10,12y 14. Los patrones y "antipatrones" para las actividades de gestión de proyectos se explican en la parte 4 de este libro.

CAPÍTULO 2 •

35

EL PROCESO: UNA VISIÓN GENERAL

Los patrones

de fase d e f i n e n la s e c u e n c i a d e a c t i v i d a d e s del m a r c o d e t r a -

b a j o q u e o c u r r e j u n t o c o n el p r o c e s o , a u n c u a n d o el flujo g e n e r a l d e activ i d a d e s e s iterativo p o r n a t u r a l e z a . Un e j e m p l o d e u n p a t r ó n de f a s e p u e d e ser un m o d e l o e n espiral o d e c o n s t r u c c i ó n d e prototipos.7 C o n t e x t o i n i c i a l . Se d e s c r i b e n l a s c o n d i c i o n e s e n l a s c u a l e s s e aplica el p a t r ó n . A n t e s d e iniciar é s t e s e d e b e c u e s t i o n a r 1) q u é a c t i v i d a d e s o r g a n i z a c i o n a l e s o relativas al e q u i p o h a n o c u r r i d o , 2) c u á l e s el e s t a d o d e e n t r a d a p a r a el p r o c e s o , y 3) q u é i n f o r m a c i ó n de i n g e n i e r í a del s o f t w a r e o i n f o r m a c i ó n del p r o y e c t o y a existe. Por e j e m p l o , el p a t r ó n d e p l a n e a c i ó n (un p a t r ó n discreto) r e q u i e r e q u e 1) l o s clientes y los ingenieros de software hayan establecido una colaboración e n cuanto a c o m u n i c a c i ó n ; 2) s e h a y a c o m p l e t a d o c o n éxito u n g r a n n ú m e r o d e p a t r o n e s d e t a r e a (especificados) p a r a el p a t r ó n d e c o m u n i c a c i ó n c o n e l c l i e n t e ; y 3) s e c o n o z c a n los a l c a n c e s del p r o y e c t o , los r e q u i s i t o s b á s i c o s del n e g o c i o y las restricc i o n e s del p r o y e c t o . P r o b l e m a . Se d e s c r i b e el p r o b l e m a q u e d e b e resolver el p a t r ó n . Por e j e m p l o , el p r o b l e m a q u e d e b e resolver la c o m u n i c a c i ó n c o n e l c l i e n t e p u e d e describirse d e la siguiente m a n e r a : La comunicación inadecuada

porque no se establece

crea un mecanismo

entre el desarrolladory un formato

el cliente muchas

veces es

efectivo para obtener información,

no se

útil para registrarla, y no se realiza una revisión significativa.

S o l u c i ó n . Se d e s c r i b e la i m p l e m e n t a c i ó n del p a t r ó n . En e s t a s e c c i ó n s e d i s c u t e c ó m o el e s t a d o inicial del p r o c e s o (existent e a n t e s d e q u e se h a y a i m p l e m e n t a d o el p a t r ó n ) s e modifica c o m o c o n s e c u e n c i a del inicio del p a t r ó n . T a m b i é n s e d e s c r i b e c ó m o la i n f o r m a c i ó n d e la i n g e n i e r í a del s o f t w a r e o la i n f o r m a c i ó n del p r o y e c t o , d i s p o n i b l e a n t e s d e iniciado el p a t r ó n , s e t r a n s f o r m a c o m o c o n s e c u e n c i a d e la e j e c u c i ó n e x i t o s a del p a t r ó n . C o n t e x t o r e s u l t a n t e . Se d e s c r i b e n las c o n d i c i o n e s q u e h a b r á u n a v e z q u e el p a trón h a y a s i d o i m p l e m e n t a d o c o n éxito. Para c o m p l e t a r el p a t r ó n d e b e n r e a l i z a r s e l a s s i g u i e n t e s p r e g u n t a s : 1) ¿ q u é a c t i v i d a d e s o r g a n i z a c i o n a l e s o r e l a c i o n a d a s c o n el e q u i p o d e b i e r o n h a b e r o c u r r i d o ? , 2) ¿cuál e s el e s t a d o d e salida p a r a el p r o c e so?, y 3) ¿ q u é i n f o r m a c i ó n d e la ingeniería del s o f t w a r e o i n f o r m a c i ó n del p r o y e c t o ha sido desarrollada? P a t r o n e s r e l a c i o n a d o s . S e p r o p o r c i o n a u n a lista de t o d o s los p a t r o n e s d e p r o c e s o d i r e c t a m e n t e r e l a c i o n a d o s c o n é s t e , e n f o r m a j e r á r q u i c a o d e a lTM g u n a otra f o r m a . Por e j e m p l o , el p a t r ó n e s t a c i o n a r i o d e c o m u n i c a c i ó n a b a r c a los p a t r o n e s d e t a r e a reunión del e q u i p o para el proyecto, definición d e una línea de colabora-

PDF Editor

ción, aislamiento d e alcances, reunión d e requisitos, descripción d e restricciones y una creación de un m o d e l o mini-spec.

7

Estos patrones de fase se exponen en el capitulo 3.

36

PARTE UNO


U s o s c o n o c i d o s / E j e m p l o s . Se indican ios e j e m p l o s e s p e c í f i c o s e n l o s c u a l e s el p a t r ó n e s aplicable. Por e j e m p l o , la c o m u n i c a c i ó n e s o b l i g a t o r i a al principio d e c a d a p r o y e c t o d e s o f t w a r e ; s e r e c o m i e n d a p o r m e d i o del p r o c e s o d e s o f t w a r e , y e s obligatoria u n a v e z q u e la actividad de d e s p l i e g u e e s t é r e a l i z a d a . Los p a t r o n e s d e p r o c e s o p r o p o r c i o n a n u n m e c a n i s m o e f e c t i v o p a r a describir

Referencia Web

c u a l q u i e r p r o c e s o d e s o f t w a r e . Los p a t r o n e s p e r m i t e n u n a o r g a n i z a c i ó n de i n g e n i e ría del s o f t w a r e p a r a d e s a r r o l l a r un d e s c r i p c i ó n del p r o c e s o j e r á r q u i c o q u e c o m i e n ce e n un alto g r a d o d e a b s t r a c c i ó n (un p a t r ó n de fase). La descripción s e refina h a s t a www.ombysoft. (om/protess PatternsPoge.html.

u n c o n j u n t o d e p a t r o n e s e s t a c i o n a r i o s q u e d e s c r i b e n a c t i v i d a d e s del m a r c o d e t r a b a j o , y m á s t a r d e s e refina d e un m o d o j e r á r q u i c o e n p a t r o n e s de t a r e a s m á s d e t a llados p a r a c a d a p a t r ó n e s t a c i o n a r i o . D e s p u é s d e q u e s e h a n d e s a r r o l l a d o los p a t r o n e s de p r o c e s o , p u e d e n r e u t i l i z a r s e p a r a la definición de v a r i a n t e s de p r o c e s o ; e s decir, u n e q u i p o d e s o f t w a r e p u e d e definir u n m o d e l o d e p r o c e s o p e r s o n a l i z a d o u s a n d o p a t r o n e s c o m o b l o q u e s de c o n s t r u c c i ó n p a r a el m o d e l o d e p r o c e s o . INFORMACIÓN

Ejemplo de un patrón del proceso El siguiente patrón d e proceso a b r e v i a d o des-

d e software. Los clientes no están seguros d e lo q u e de-

cribe un e n f o q u e aplicable c u a n d o los clientes

sean; es decir, no pueden describir ningún detalle d e

tienen una idea g e n e r a l d e lo q u e d e b e hacerse, pero no están seguros d e los requisitos específicos del software.

los requisitos del software. S o l u c i ó n . Aquí se presenta una descripción del proceso

N o m b r e del patrón. Prototipo. P r o p ó s i t o . El objetivo del patrón es construir un modelo

d e prototipo. Para más detalles, véase el capítulo 3. C o n t e x t o r e s u l t a n t e . Los clientes a p r u e b a n un prototi-

(un prototipo) q u e los clientes evalúen d e m o d o iterativo

p o d e software que identifica requisitos básicos (por

en un esfuerzo e n c a m i n a d o a identificar los requisitos

ejemplo, modelos d e interacción, rasgos computaciona-

del software.

les, funciones d e procesamiento). Después 1) el prototi-

T i p o . Patrón d e fase.

po p u e d e evolucionar recorriendo una serie d e

C o n t e x t o i n i c i a l . Deben cumplirse las siguientes condi-

incrementos p a r a convertirse en el software d e produc-

ciones antes d e iniciar este patrón: 1) los clientes han

ción, o 2) el prototipo se descarta y el software d e pro-

sido identificados; 2) se h a establecido un m o d o de co-

ducción se construye con otros patrones d e proceso.

municación entre los clientes y el e q u i p o d e t r a b a j o ; 3)

P a t r o n e s r e l a c i o n a d o s . Los siguientes p a t r o n e s están

los clientes han identificado el p r o b l e m a q u e ha d e re-

r e l a c i o n a d o s con este p a t r ó n : c o m u n i c a c i ó n c o n

solverse; 4) se ha desarrollado un entendimiento inicial

el cliente; d i s e ñ o iterativo; desarrollo iterativo; e v a l u a c i ó n del cliente; extracción de requisitos.

del alcance del proyecto, los requisitos básicos del negocio y las restricciones del proyecto. P r o b l e m a . Los requisitos son v a g o s o no existen. N o

U s o s c o n o c i d o s / e j e m p l o s . El prototipo se recomien-

obstante, se reconoce con claridad la existencia d e un

TM d a c u a n d o los requisitos son inseguros.

problema, y éste d e b e ir a c o m p a ñ a d o d e una solución

PDF Editor 2.5

E V A L U A C I Ó N PEÍ, P R O C E S O

La e x i s t e n c i a d e un p r o c e s o d e s o f t w a r e n o e s g a r a n t í a d e q u e é s t e s e r á e n t r e g a d o

a t i e m p o , de q u e s a t i s f a r á las n e c e s i d a d e s del cliente, o d e q u e m o s t r a r á las c a r a c terísticas t é c n i c a s q u e c o n d u c i r á n a c a r a c t e r í s t i c a s d e calidad a l a r g o p l a z o (capítulo 26). Los p a t r o n e s d e p r o c e s o d e b e n ir a c o m p a ñ a d o s d e u n a p r á c t i c a sólida de la

CAPÍTULO 2

37


Mejoramiento del proceso de software

Determinación d e la c a p a c i d a d Motiva

i n g e n i e r í a del s o f t w a r e (parte 2 d e e s t e libro). A d e m á s , el p r o c e s o m i s m o d e b e e v a l u a r s e p a r a a s e g u r a r s e de q u e c u m p l a u n a s e r i e d e criterios b á s i c o s del p r o c e s o q u e

CLÁVE i" c evaluación s e

h a n d e m o s t r a d o s e r e s e n c i a l e s p a r a u n a ingeniería d e s o f t w a r e e x i t o s a . 8 La r e l a c i ó n e n t r e el p r o c e s o de s o f t w a r e y los m é t o d o s a p l i c a d o s p a r a la e v a l u a c i ó n y el m e j o -

T & n á e comprender

r a m i e n t o s e m u e s t r a e n la figura 2.5. Se h a n p r o p u e s t o v a r i o s e n f o q u e s p a r a la eva-

3 e s t a d o octuol del

luación del proceso

TXSSO

de software y

de software

e n las d é c a d a s p a s a d a s :

El m é t o d o d e e v a l u a c i ó n d e l a IMCM e s t á n d a r p a r a e l m e j o r a m i e n t o d e l

•¿ n t e n t o m e j o r a r l o .

p r o c e s o ( M E I E M P ) o f r e c e un m o d e l o d e c i n c o p a s o s p a r a la e v a l u a c i ó n del p r o c e s o q u e incluye la iniciación, el d i a g n ó s t i c o , el e s t a b l e c i m i e n t o , la a c c i ó n y el a p r e n -

^ ¿Deque • técnicas •:<»oles se áspone para n d i u r el proceso fc s o f t w a r e ?

d i z a j e . El m é t o d o MElEMP utiliza el SE1 IMCM (sección 2.3) c o m o b a s e p a r a la e v a luación [SEIOO], La a p r e c i a c i ó n b a s a d a e n e l CMM p a r a e l m e j o r a m i e n t o d e l p r o c e s o int e r n o (ABC MPI) o f r e c e u n a t é c n i c a d e d i a g n ó s t i c o p a r a e v a l u a r la m a d u r e z relativa de u n a o r g a n i z a c i ó n d e s o f t w a r e m e d i a n t e la ABC MPI (un p r e c u r s o r de la IMCM, el c u a l s e e x p l i c ó e n la s e c c i ó n 2.3) c o m o b a s e p a r a la e v a l u a c i ó n [DUNOi]. El e s t á n d a r S P I C E ( 1 S O / I E C 1 5 5 0 4 ) d e f i n e u n c o n j u n t o d e r e q u i s i t o s p a r a l a

e v a l u a c i ó n del p r o c e s o de s o f t w a r e ; lo q u e p r e t e n d e e s a y u d a r a las TMo r g a n i z a c i o n e s e n el d e s a r r o l l o de u n a e v a l u a c i ó n objetiva d e la eficacia de c u a l q u i e r p r o c e s o d e s o f t w a r e d e f i n i d o [SPI99].

PDF Editor

El I S O 9 0 0 1 : 2 0 0 0 p a r a s o f t w a r e e s u n e s t á n d a r g e n é r i c o q u e s e a p l i c a a c u a l -

q u i e r o r g a n i z a c i ó n q u e d e s e e m e j o r a r la c a l i d a d g e n e r a l d e l o s p r o d u c t o s , s i s t e m a s

8

La IMCM del SEI [CMM02] describe, en detalle y con amplitud, las características de un proceso de

software y los criterios para un p r o c e s o exitoso.

PARTE UNO

38


o servicios q u e p r o v e e . Por lo t a n t o , el e s t á n d a r s e a p l i c a de m o d o d i r e c t o a c o m p a ñías y organizaciones de software. D e b i d o a q u e el ISO 9 0 0 1 : 2 0 0 0 s e u s a d e m a n e r a a m p l i a e n el á m b i t o i n t e r n a c i o n a l , s e e x a m i n a r á c o n b r e v e d a d en los p á r r a f o s q u e s i g u e n . "Los organizaciones de software han mostrado deficiencias significativas en su habilidad para capitalizar las experiencias g a n a d a s en proyectos completos."

NASA La O r g a n i z a c i ó n I n t e r n a c i o n a l de E s t a n d a r i z a c i ó n (ISO, por s u s siglas e n inglés) h a e s t a b l e c i d o el e s t á n d a r ISO 9 0 0 1 : 2 0 0 0 [ISOOO] p a r a definir los r e q u i s i t o s d e u n s i s t e m a d e g e s t i ó n de calidad (capítulo 26) q u e sirva p a r a e l a b o r a r p r o d u c t o s d e m á s alta calidad y así m e j o r a r la s a t i s f a c c i ó n del cliente. 9 La e s t r a t e g i a f u n d a m e n t a l q u e s u g i e r e el ISO 9 0 0 1 : 2 0 0 0 s e d e s c r i b e d e la s i g u i e n te m a n e r a : El ISO 9 0 0 1 : 2 0 0 0 s u b r a y a la i m p o r t a n c i a q u e tiene p a r a u n a o r g a n i z a c i ó n identificar, imp l e m e n t a r , g e s t i o n a r y m e j o r a r d e m a n e r a c o n t i n u a la e f e c t i v i d a d d e los p r o c e s o s n e c e s a rios p a r a el s i s t e m a d e a d m i n i s t r a c i ó n d e la calidad, y g e s t i o n a r l a s i n t e r a c c i o n e s d e e s t o s p r o c e s o s p a r a c o n s e g u i r los o b j e t i v o s d e la o r g a n i z a c i ó n . . .

Referencia Web

Un excelente resumen del ISO 9 0 0 1 : 2 0 0 0 puede encontrase en http://proxlom. com/iso9 0 0 1 .htm.

El ISO 9 0 0 1 : 2 0 0 0 h a a d o p t a d o u n ciclo d e " p l a n e a r - h a c e r - r e v i s a r - a c t u a r " q u e se aplic a a los e l e m e n t o s d e g e s t i ó n d e c a l i d a d de u n p r o y e c t o d e s o f t w a r e . D e n t r o d e u n c o n t e x t o d e s o f t w a r e , " p l a n e a r " e s t a b l e c e los objetivos, l a s a c t i v i d a d e s y t a r e a s del p r o c e s o n e c e s a r i o s p a r a c o n s e g u i r u n s o f t w a r e d e alta calidad y u n a s a t i s f a c c i ó n del cliente; " h a c e r " i m p l e m e n t a el p r o c e s o d e s o f t w a r e (incluidas las a c t i v i d a d e s del m a r c o d e t r a b a j o y l a s a c t i v i d a d e s sombrilla); "revisar" m o n i t o r e a y m i d e el p r o c e s o p a r a a s e g u r a r s e d e q u e t o d o s los r e q u i s i t o s e s t a b l e c i d o s p a r a la g e s t i ó n de c a l i d a d h a y a n s i d o c u m p l i d o s ; " a c t u a r " inicia l a s a c t i v i d a d e s d e m e j o r a m i e n t o del p r o c e s o d e s o f t w a r e , el c u a l t i e n e u n a c o n t i n u i d a d d e t r a b a j o p a r a m e j o r a r el p r o c e s o . Para u n t r a t a m i e n t o m á s d e t a l l a d o del ISO 9 0 0 1 : 2 0 0 0 l o s l e c t o r e s i n t e r e s a d o s e n el t e m a d e b e n c o n s u l t a r los e s t á n d a r e s ISO o [CIA01], [KET01] o [MONOIJ.

2.6

MODELOS

DE P R O C E S O P E R S O N A L E S Y EN E Q U I P O

El m e j o r p r o c e s o d e s o f t w a r e e s el q u e e s t á c e r c a d e la g e n t e q u e realizará el t r a b a j o .

TM

Si un m o d e l o de p r o c e s o de s o f t w a r e h a s i d o d e s a r r o l l a d o e n u n á m b i t o c o r p o r a t i v o u o r g a n i z a c i o n a l , p u e d e s e r e f e c t i v o s ó l o si e s e n g r a n m e d i d a a d a p t a b l e p a r a s a t i s f a c e r las n e c e s i d a d e s del e q u i p o del p r o y e c t o , q u e e s el q u e e n r e a l i d a d lleva a c a b o

PDF Editor

el t r a b a j o d e ingeniería del s o f t w a r e . En u n e s c e n a r i o ideal, c a d a i n g e n i e r o d e s o f t w a r e c r e a r í a u n p r o c e s o q u e llene lo m e j o r p o s i b l e s u s p r o p i a s n e c e s i d a d e s , y al mis9

El a s e g u r a m i e n t o de la calidad del s o f t w a r e (ACS), u n e l e m e n t o importante de la gestión de calidad,

ha sido definido c o m o una actividad sombrilla que se aplica a través d e todo el m a r c o de trabajo del proceso. Se e x p o n e en detalle en el capitulo 26.

CAPÍTULO 2

39


m o t i e m p o s a t i s f a g a las a m p l i a s n e c e s i d a d e s del e q u i p o y la o r g a n i z a c i ó n . De m o d o al t ernat i vo, el e q u i p o m i s m o c r e a r í a s u p r o p i o p r o c e s o , y al m i s m o t i e m p o cubriría las n e c e s i d a d e s m á s r e d u c i d a s d e los i n d i v i d u o s y las n e c e s i d a d e s a m p l i a s d e la o r g a n i z a c i ó n . W a t t s H u m p h r e y ([HUM97] y [HUMOO]) a r g u m e n t a q u e e s p o s i b l e c r e a r un " p r o c e s o d e s o f t w a r e p e r s o n a l " o u n " p r o c e s o d e s o f t w a r e e n equipo". A m b o s req u i e r e n de u n a r d u o t r a b a j o , c a p a c i t a c i ó n y c o o r d i n a c i ó n , p e r o a m b o s s e p u e d e n conseguir.10 "Unn persona que tiene éxito sólo se ho formado el hábito de hacer las cosos que lo g ente sin éxito no hace." D e x t e r Yager

2.6.1

Proceso d e software personal (PSP)

C a d a d e s a r r o l l a d o r utiliza a l g ú n p r o c e s o p a r a c o n s t r u i r u n s o f t w a r e d e c o m p u t a d o ra. El p r o c e s o p u e d e s e r fortuito o ad hoc, p u e d e c a m b i a r a diario, p u e d e n o s e r eficiente, e f e c t i v o o h a s t a e x i t o s o , p e r o existe u n p r o c e s o . W a t t s H u m p h r e y [HUM97] s u g i e r e q u e p a r a c a m b i a r u n p r o c e s o p e r s o n a l inefectivo, u n individuo d e b e p a s a r p o r c u a t r o f a s e s , e n las c u a l e s se r e q u i e r e c a p a c i t a c i ó n e i n s t r u m e n t a c i ó n c u i d a d o sa. El proceso

de software

personal

(PSP) r e s a l t a la m e d i d a p e r s o n a l del p r o d u c t o d e

t r a b a j o q u e se p r o d u c e y la c a l i d a d r e s u l t a n t e del p r o d u c t o d e t r a b a j o . A d e m á s , el PSP r e s p o n s a b i l i z a al p r o f e s i o n a l e n c a r g a d o d e la p l a n e a c i ó n del p r o y e c t o (por e j e m plo, la e s t i m a c i ó n y la planificación) y le c o n f i e r e el p o d e r d e c o n t r o l a r la c a l i d a d d e t o d o s los p r o d u c t o s d e t r a b a j o del s o f t w a r e q u e s e d e s a r r o l l a n . El m o d e l o PSP d e f i n e c i n c o a c t i v i d a d e s del m a r c o d e t r a b a j o : p l a n e a c i ó n , d i s e ñ o de a l t o nivel, revisión del d i s e ñ o d e a l t o nivel, d e s a r r o l l o y a n á l i s i s de r e s u l t a d o s . A ¿Oté K t i v i V U H M • • r a 4* t r a b a j o * « S z a n duranfcdPSP?

P l a n e a c i ó n . Esta act i vi dad s e l e c c i o n a r e q u i s i t o s y, c o n b a s e e n é s t o s , d e s a r r o l l a el t a m a ñ o y la e s t i m a c i ó n d e los r e c u r s o s . A d e m á s , s e e s t i m a n los d e f e c t o s (el n ú m e r o d e d e f e c t o s p r o y e c t a d o e n el t r a b a j o ) . T o d a s las m e d i c i o n e s s e r e g i s t r a n e n h o j a s d e t r a b a j o o e n plantillas. Al final, s e identifican l a s t a r e a s de d e s a r r o l l o y s e c r e a u n p r o g r a m a del p r o y e c t o . D i s e ñ o d e a l t o n i v e l . S e e l a b o r a n las e s p e c i f i c a c i o n e s e x t e r n a s p a r a q u e c a d a c o m p o n e n t e s e a c o n s t r u i d o y s e c r e a u n d i s e ñ o del c o m p o n e n t e . Se c o n s t r u y e n p r o t o t i p o s c u a n d o existe i n c e r t i d u m b r e . T o d o s los e l e m e n t o s s e registran y r a s t r e a n . R e v i s i ó n d e l d i s e ñ o d e a l t o n i v e l . Los m é t o d o s f o r m a l e s de verificación (capít u l o 26) s e a p l i c a n a e r r o r e s d e s c u b i e r t o s e n el d i s e ñ o . Las m e d i c i o n e s s e m a n t i e n e n p a r a t o d a s l a s t a r e a s i m p o r t a n t e s y los r e s u l t a d o s d e t r a b a j o . Desarrollo.

TM

El d i s e ñ o al nivel de c o m p o n e n t e s e r e f i n a y revisa. Se g e n e r a , re-

PDF Editor

visa, c o m p i l a y p r u e b a el c ó d i g o . Las m e d i c i o n e s s e m a n t i e n e n p a r a t o d a s las t a r e a s i m p o r t a n t e s y los r e s u l t a d o s d e t r a b a j o .

10 Vale la pena mencionar que los proponentes del desarrollo ágil del software (capitulo 4) también argumentan que el proceso debe permanecer cerca del equipo. Ellos proponen un método alternativo para lograrlo.

40

PARTE UNO

a

PROCESO DEL SOFTWARE

A n á l i s i s d e r e s u l t a d o s . M e d i a n t e las m e d i c i o n e s y m e d i d a s r e c o l e c t a d a s (una c a n t i d a d s u s t a n c i a l de d a t o s d e b e a n a l i z a r s e d e m a n e r a estadística) s e d e t e r m i n a la efectividad del p r o c e s o . Las m e d i c i o n e s y m e d i d a s d e b e n o f r e c e r u n a guía p a r a m o dificar el p r o c e s o y así m e j o r a r s u e f e c t i v i d a d . El PSP d e s t a c a la n e c e s i d a d q u e tiene c a d a i n g e n i e r o de s o f t w a r e de identificar los eiTores d e s d e el principio y la i m p o r t a n c i a d e e n t e n d e r los tipos d e e r r o r e s q u e s u e le c o m e t e r . Esto se lleva a c a b o m e d i a n t e u n a a c t i v i d a d d e e v a l u a c i ó n r i g u r o s a aplic a d a e n t o d o s los p r o d u c t o s d e t r a b a j o q u e g e n e r a el i n g e n i e r o d e s o f t w a r e . El PSP r e p r e s e n t a u n e n f o q u e disciplinado, b a s a d o e n m e d i c i o n e s , d e la i n g e n i e -

CLAVE El PSP d e s t o c o lo n e c e s i d a d d e registrar y analizar los tipos de errores que se

ría de s o f t w a r e q u e p u e d e c o n d u c i r a u n c h o q u e d e c u l t u r a s a m u c h o s p r o f e s i o n a les. Sin e m b a r g o , c u a n d o el PSP s e p r e s e n t a d e u n m o d o a d e c u a d o a l o s i n g e n i e r o s de s o f t w a r e [HUM96], la m e j o r í a r e s u l t a n t e e n la p r o d u c t i v i d a d d e la i n g e n i e r í a del s o f t w a r e y la calidad d e é s t e s o n significativas [FER97]. No o b s t a n t e , la industria n o h a a d o p t a d o c o n a m p l i t u d el PSP. Las r a z o n e s , t r i s t e m e n t e , t i e n e n m á s r e l a c i ó n c o n

cometen pora

la n a t u r a l e z a h u m a n a y la inercia o r g a n i z a c i o n a l q u e c o n l a s f u e r z a s y d e b i l i d a d e s

desarrollar e s t r a t e g i a s encaminodos o

del e n f o q u e del PSP. Este ú l t i m o e s un r e t o intelectual y d e m a n d a un g r a d o d e c o m -

eliminarlos.

p r o m i s o (por p a r t e de los p r o f e s i o n a l e s y s u s jefes) q u e n o s i e m p r e e s p o s i b l e o b t e ner. La c a p a c i t a c i ó n e s r e l a t i v a m e n t e larga y s u s c o s t o s s o n a l t o s . En lo cultural, el g r a d o r e q u e r i d o d e medición e s difícil p a r a m u c h a g e n t e involucrada c o n el s o f t w a r e . Una i n t e r r o g a n t e e s si el PSP p u e d e u s a r s e c o m o u n p r o c e s o d e s o f t w a r e e f e c t i v o a un nivel p e r s o n a l . La r e s p u e s t a e s , sin d u d a , sí. Pero a u n si el PSP n o e s a d o p t a d o e n s u totalidad, v a l e la p e n a e s t u d i a r m u c h o s d e los c o n c e p t o s d e m e j o r a del p r o c e so que éste presenta.

2.6.2 Proceso de software en equipo (PSE) tóós información sobre lo construcción de equipos de alto desempeflo empleando el PSE y el PSP puede obtenerse en www.sel.cmu.

D e b i d o a q u e m u c h o s p r o y e c t o s de s o f t w a r e e n el á m b i t o industrial los dirige u n e q u i p o d e p r o f e s i o n a l e s , W a t t s H u m p h r e y e x t e n d i ó l a s lecciones a p r e n d i d a s p a r a la introd u c c i ó n del PSP y p r o p u s o u n proceso de soJ\ware en equipo (PSE). La m e t a del PSE e s construir u n e q u i p o de p r o y e c t o "autodirigido" q u e se o r g a n i c e p a r a p r o d u c i r u n s o f t w a r e d e alta calidad. H u m p h r e y [HUM98] d e f i n e los s i g u i e n t e s o b j e t i v o s del PSE:

eAi/tsp/.

•

Construir equipos autodirigidos que planeen y tengan un seguimiento de su t r a b a j o , e s t a b l e z c a n m e t a s y p o s e a n s u s p r o c e s o s y p l a n e s . Esto s g r u p o s

TM

p u e d e n ser e q u i p o s d e s o f t w a r e p u r o s o e q u i p o s de p r o d u c t o i n t e g r a d o (EP1) d e 3 a 2 0 i n g e n i e r o s .

PDF Editor •

Mostrar a los jefes c ó m o preparar y motivar a sus equipos y c ó m o ayudar-

los a s o s t e n e r u n a l t o d e s e m p e ñ o .

•

A c e l e r a r el m e j o r a m i e n t o del p r o c e s o d e s o f t w a r e al r e a l i z a r , c o n el c o m -

p o r t a m i e n t o n o r m a l y e s p e r a d o , el nivel 5 del MCM.

O f r e c e r u n a g u í a d e m e j o r a m i e n t o a o r g a n i z a c i o n e s d e alta m a d u r e z .

CAPÍTULO 2

ÔMSEJO^^

•

41


Facilitar la e n s e ñ a n z a u n i v e r s i t a r i a d e h a b i l i d a d e s d e e q u i p o industrial de calidad.

Un e q u i p o a u t o d i r i g i d o e n t i e n d e e n f o r m a c o n s i s t e n t e s u s m e t a s y o b j e t i v o s gen e r a l e s . D e f i n e f u n c i o n e s y r e s p o n s a b i l i d a d e s p a r a c a d a u n o d e s u s m i e m b r o s ; registra d a t o s c u a n t i t a t i v o s del p r o y e c t o ( c o m o p r o d u c t i v i d a d y calidad); identifica un p r o c e s o de e q u i p o a p r o p i a d o p a r a el proyecto y u n a estrategia para i m p l e m e n t a r el proc e s o ; d e f i n e e s t á n d a r e s l o c a l e s a p l i c a b l e s al t r a b a j o de ingeniería de s o f t w a r e del e q u i p o , e v a l ú a e n c a d a m o m e n t o riesgos y r e a c c i o n e s ; y registra, g e s t i o n a y r e p o r t a el e s t a t u s del p r o y e c t o . "Encontrar buenos jugadores es fácil. Hacer que jueguen en equipo es otra historia." Casey Stangel

El PSE d e f i n e las s i g u i e n t e s actividades del m a r c o d e trabajo: l a n z a m i e n t o , d i s e ñ o

CLAVE

d e a l t o nivel, i m p l e m e n t a c i ó n , i n t e g r a c i ó n y p r u e b a , y análisis d e resultados. Al igual q u e s u s c o n t r a p a r t e s en el PSP (nótese q u e la t e r m i n o l o g í a e s diferente), e s t a s activid a d e s p e r m i t e n al e q u i p o p l a n e a r , d i s e ñ a r y construir u n s o f t w a r e de u n a m a n e r a disciplinada al m i s m o t i e m p o q u e m i d e n de m o d o c u a n t i t a t i v o el p r o c e s o y el p r o d u c t o . Los análisis d e r e s u l t a d o s m u e s t r a n el e s c e n a r i o p a r a el m e j o r a m i e n t o del p r o c e s o . El PSE utiliza u n a a m p l i a variedad de escritos, f o r m a s y e s t á n d a r e s q u e sirven p a r a guiar a los m i e m b r o s del e q u i p o e n su t r a b a j o . Los escritos d e f i n e n a c t i v i d a d e s e s p e cíficas del p r o c e s o (por e j e m p l o , l a n z a m i e n t o , d i s e ñ o , i m p l e m e n t a c i ó n , i n t e g r a c i ó n y p r u e b a , y a n á l i s i s d e r e s u l t a d o s del proyecto) y o t r a s f u n c i o n e s m á s d e t a l l a d a s del t r a b a j o ( c o m o p l a n e a c i ó n del d e s a r r o l l o , d e s a r r o l l o de requisitos, g e s t i ó n d e la c o n figuración

d e s o f t w a r e y p r u e b a d e u n i d a d ) q u e s o n p a r t e del p r o c e s o del e q u i p o .

Con fines ilustrativos, e s útil t o m a r e n c u e n t a la actividad inicial del p r o c e s o : el lanzamiento

del proyecto.

C a d a p r o y e c t o e s " l a n z a d o " c o n u n a s e c u e n c i a d e t a r e a s (definida c o m o u n escrito) q u e p e r m i t e al e q u i p o e s t a b l e c e r u n a b a s e sólida p a r a iniciar el p r o y e c t o . Se rec o m i e n d a el s i g u i e n t e escrito de lanzamiento •

(sólo de m a n e r a g e n e r a l ) [HUMOOj:

Revisar los o b j e t i v o s del p r o y e c t o c o n la g e s t i ó n y a c o r d a r y d o c u m e n t a r las m e t a s del e q u i p o .

•

E s t a b l e c e r l a s f u n c i o n e s del e q u i p o .

•

Definir el p r o c e s o d e d e s a r r o l l o del e q u i p o .

•

E l a b o r a r u n p l a n de calidad y p l a n t e a r los o b j e t i v o s d e calidad.

•

P r e p a r a r un plan p a r a las n e c e s i d a d e s de s o p o r t e n e c e s a r i a s .

•

Producir u n a estrategia de desarrollo general.

•

E l a b o r a r u n p l a n de d e s a r r o l l o p a r a el p r o y e c t o e n s u t o t a l i d a d .

•

Hacer p l a n e s d e t a l l a d o s p a r a c a d a i n g e n i e r o e n la s i g u i e n t e f a s e .

•

A d a p t a r los p l a n e s i n d i v i d u a l e s a un p l a n de e q u i p o .

TM

PDF Editor

PARTE UNO •


H a c e r u n b a l a n c e d e la c a n t i d a d d e t r a b a j o del e q u i p o p a r a o b t e n e r u n p r o grama mínimo en términos generales.

•

Valorar l o s riesgos del p r o y e c t o y a s i g n a r r e s p o n s a b i l i d a d d e r a s t r e o p a r a c a d a riesgo clave.

Es i m p o r t a n t e s e ñ a l a r q u e la actividad d e l a n z a m i e n t o p u e d e a p l i c a r s e a n t e s d e c a d a act i vi dad del m a r c o d e t r a b a j o del PSE, el c u a l s e explicó p á r r a f o s a t r á s . E s t o s e a j u s t a a la n a t u r a l e z a iterativa d e m u c h o s p r o y e c t o s y p e r m i t e q u e el e q u i p o s e a d a p te a l a s n e c e s i d a d e s c a m b i a n t e s del cliente y a l a s l e c c i o n e s a p r e n d i d a s d e actividad e s previas. El PSE r e c o n o c e q u e l o s m e j o r e s e q u i p o s d e s o f t w a r e s o n a u t o d i r i g i d o s . Los m i e m b r o s del e q u i p o p l a n t e a n los o b j e t i v o s del p r o y e c t o , a d a p t a n el p r o c e s o p a r a cubrir s u s n e c e s i d a d e s , c o n t r o l a n el p r o g r a m a y la m e d i c i ó n y el a n á l i s i s d e las m e d i d a s r e c o l e c t a d a s ; a d e m á s , t r a b a j a n d e m a n e r a c o n t i n u a p a r a m e j o r a r el e n f o q u e del e q u i p o r e s p e c t o d e la i n g e n i e r í a del s o f t w a r e . Al igual q u e el PSP, el PSE e s u n e n f o q u e r i g u r o s o p a r a la i n g e n i e r í a del s o f t w a r e q u e o f r e c e b e n e f i c i o s d i s t i n t o s y c u a n t i f i c a b l e s e n p r o d u c t i v i d a d y calidad. El e q u i p o d e b e c o m p r o m e t e r s e c o n el p r o c e s o y d e b e recibir c a p a c i t a c i ó n p a r a a s e g u r a r s e d e q u e el e n f o q u e s e a p l i q u e de m a n e r a a p r o p i a d a .

Los m o d e l o s g e n é r i c o s de p r o c e s o t r a t a d o s e n las s e c c i o n e s p r e c e d e n t e s d e b e n a d a p t a r s e p a r a q u e los utilice u n e q u i p o d e p r o y e c t o d e s o f t w a r e . Para lograrlo s e h a n d e s a r r o l l a d o herramientas

de tecnología

del proceso

destinadas a ayudar a las or-

ganizaciones de software a analizar sus procesos actuales, organizar sus tareas, c o n t r o l a r y m o n i t o r e a r s u p r o g r e s o , y a d m i n i s t r a r su calidad t é c n i c a [NEG99]. Las h e r r a m i e n t a s d e t e c n o l o g í a del p r o c e s o p e r m i t e n q u e u n a o r g a n i z a c i ó n d e s o f t w a r e c o n s t r u y a u n m o d e l o a u t o m a t i z a d o del m a r c o d e t r a b a j o c o m ú n del p r o c e s o , d e los c o n j u n t o s de t a r e a s y las a c t i v i d a d e s s o m b r i l l a e x p l i c a d a s e n la s e c c i ó n 2.2. El m o d e l o , q u e a m e n u d o s e r e p r e s e n t a c o m o u n a red, e n t o n c e s p u e d e a n a l i z a r s e p a r a d e t e r m i n a r el flujo d e t r a b a j o típico y e x a m i n a r las e s t r u c t u r a s d e p r o c e s o alt e r n a t i v a s q u e p o d r í a n c o n d u c i r a la r e d u c c i ó n del t i e m p o o c o s t o del d e s a r r o l l o . Una v e z c r e a d o u n p r o c e s o a c e p t a b l e e s p o s i b l e utilizar o t r a s h e r r a m i e n t a s de t e c n o l o g í a del p r o c e s o p a r a localizar, m o n i t o r e a r e i n c l u s o c o n t rTM olar todas las tareas d e i n g e n i e r í a del s o f t w a r e d e f i n i d a s c o m o u n a p a r t e del m o d e l o del p r o c e s o . C a d a m i e m b r o del e q u i p o d e s o f t w a r e p u e d e e m p l e a r d i c h a s h e r r a m i e n t a s e n la e l a b o r a -

PDF Editor

ción de u n a lista d e verificación d e l a s t a r e a s d e t r a b a j o q u e se d e b e n d e s a r r o l l a r , los p r o d u c t o s del t r a b a j o q u e e s i m p e r a t i v o p r o d u c i r , y las a c t i v i d a d e s p a r a el a s e g u r a m i e n t o d e la calidad q u e d e b e n r e a l i z a r s e . La h e r r a m i e n t a d e t e c n o l o g í a del p r o c e -

s o t a m b i é n s e p u e d e a p r o v e c h a r p a r a c o o r d i n a r el u s o d e o t r a s h e r r a m i e n t a s d e la ingeniería del s o f t w a r e a s i s t i d a por c o m p u t a d o r a q u e s e a n a p r o p i a d a s p a r a u n a t a r e a d e t r a b a j o particular.

CAPÍTULO 2

43


HERRAMIENTAS DE SOFTWARE

Herramientas de modelado del proceso O b j e t i v o : Si una organización trabaja en el

único (acciones, tareas, productos de trabajo), ofrecen una

-ejoramiento de un proceso de un negocio (o de un softwa-

guía detallada del contenido o la descripción d e c a d a ele-

-5). el primer objetivo es entenderlo. Las herramientas d e -xjdelado del proceso (también llamadas tecnología del

tras se conduce. En algunos casos las herramientas d e

z -oceso o herramientas de gestión del proceso) se utilizan

tecnología del proceso incorporan tareas de gestión del

oaro representar los elementos clave de un proceso p a r a

proyecto estándar, como estimación, itinerario, rastreo y control.

- j e éste pueda entenderse con mayor claridad. Tales herratambién ofrecen vínculos con descripciones del proque ayudan a quienes se interesen en el proceso a las acciones y las tareas d e trabajo necesarias pa-3 desarrollado. Las herramientas d e modelación del proceso proporcionan vínculos con otras herramientas que : -ecen soporte a actividades definidas del proceso. M e c á n i c a : Las herramientas d e esta categoría permiten ; equipo definir los elementos d e un modelo del proceso

mento del proceso, y después gestionan el proceso mien-

Herramientas representativas:" Igrafx Process Tools, distribuidas por Corel Corporation (www.igrafx.com/producís/process), es una serie d e herramientas q u e permiten al equipo organizar, medir y modelar el proceso de software. Objexis Team Portal, desarrollado por Objexis Corporation (www.objexis.com), proporciona la definición y el control completos del flujo d e trabajo del proceso.

4* Si e l p r o c e s o e s d é b i l , s i n d u d a e l p r o d u c t o final s u f r i r á l a s c o n s e c u e n c i a s . A s i m i s m o , u n a c o n f i a n z a e x c e s i v a e n el p r o c e s o e s p e l i g r o s a . En u n b r e v e e n s a y o M a r g a ret D a v i s (DAV95] c o m e n t a s o b r e la d u a l i d a d del p r o d u c t o y el p r o c e s o : A l r e d e d o r d e c a d a d i e z a ñ o s , a v e c e s c a d a cinco, la c o m u n i d a d del s o f t w a r e r e d e f i n e "el p r o b l e m a " c a m b i a n d o su e n f o q u e d e l o s a s p e c t o s del p r o d u c t o a los a s u n t o s del p r o c e s o . E n t o n c e s s e h a n o b t e n i d o l e n g u a j e s d e p r o g r a m a c i ó n e s t r u c t u r a d o s (producto) s e g u i d o s p o r m é t o d o s d e a n á l i s i s e s t r u c t u r a d o (proceso) y e n c a p s u l a c i ó n d e d a t o s (producto), así c o m o el é n f a s i s a c t u a l e n el M o d e l o d e M a d u r e z d e C a p a c i d a d p a r a el D e s a r r o l l o d e Softw a r e del Instituto d e I n g e n i e r í a del S o f t w a r e (proceso) ( s e g u i d o s p o r l o 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 y el d e s a r r o l l o ágil d e s o f t w a r e ] . M i e n t r a s la t e n d e n c i a n a t u r a l d e u n p é n d u l o e s llegar al r e p o s o en el p u n t o m e d i o e n t r e d o s e x t r e m o s , el o b j e t i v o d e la c o m u n i d a d del s o f t w a r e c a m b i a e n f o r m a c o n s t a n t e p o r q u e c a d a v e z q u e u n a o s c i l a c i ó n t e r m i n a se a p l i c a u n a n u e v a f u e r z a . E s t a s o s c i l a c i o n e s s o n n o c i v a s e n sí m i s m a s p o r q u e c o n f u n d e n al p r o f e s i o n a l p r o m e d i o del s o f t w a r e c o n

TM

los c a m b i o s r a d i c a l e s e n el s i g n i f i c a d o d e h a c e r el t r a b a j o o d e j a r q u e é s t e s e d e s a r r o l l e solo. Las o s c i l a c i o n e s t a m p o c o r e s u e l v e n "el p r o b l e m a " , p u e s t o q u e e s t á n d e s t i n a d a s a fa-

PDF Editor

llar m i e n t r a s el p r o d u c t o y el p r o c e s o s e a n t r a t a d o s c o m o si f o r m a r a n u n a d i c o t o m í a e n lugar d e u n a dualidad.

11 Las h e r r a m i e n t a s m e n c i o n a d a s aquí representan una m u e s t r a de esta categoría. En la mayoría d e los c a s o s los n o m b r e s son m a r c a s registradas de sus respectivos desarrolladores.

PARTE UNO

44


Existen p r e c e d e n t e s en la c o m u n i d a d científica hacia las nociones de dualidad, cuando las contradicciones en las observaciones n o se p u e d e n explicar por completo con u n a u otra teoría competidora. La naturaleza dual de la luz, la cual parece ser en forma simult á n e a u n a partícula y una onda, ha sido a c e p t a d a desde la década de 1920, c u a n d o Louis de Broglie la propuso. Creo que las observaciones posibles sobre los artefactos del software y su desarrollo d e m u e s t r a n una dualidad f u n d a m e n t a l entre el producto y el proceso. No se p u e d e llegar a entender el artefacto completo, su contexto, uso, significado y valor si sólo se ve c o m o un proceso o ú n i c a m e n t e c o m o un producto... Todas las actividades h u m a n a s pueden verse c o m o un proceso, pero c a d a ser h u m a n o tiene un sentido de autovaloración de aquellas actividades q u e g e n e r a n u n a representación que p u e d e e m p l e a r o apreciar m á s de u n a p e r s o n a , e m p l e a r u n a y otra vez, o aprovechar en algún otro contexto. Es decir, el ser h u m a n o e n c u e n t r a placer en reutilizar sus productos y en q u e otros los reutilicen. Por lo tanto, mientras la rápida asimilación de reutilizar m e t a s en el desarrollo d e software a u m e n t a de m a n e r a potencial la satisfacción q u e experimentan los profesionales d e su trabajo, también a u m e n t a la urgencia de aceptación de la dualidad del producto y el proceso. Considerar un artefacto reutilizable c o m o sólo un producto o sólo c o m o un proceso oscurece el contexto y las m a n e r a s de utilizarlo, u oscurece el h e c h o de que cada uso resulta en un producto que, a su tiempo, se aprovechará c o m o entrada a alguna otra actividad d e desarrollo de software. Poner un punto de vista sobre el otro reduce en forma sustancial las oportunidades de reutilizar y, por lo tanto, pierde la oportunidad d e increm e n t a r la satisfacción del trabajo. "Sin d u d o , el sistemo ideal, si s e p u d i e r a obtener, seria un código tan flexible y diminuto c o m o poro p r o v e e r por anticipado e n c a d a situación concebible una regla exacta. Pero la vida es d e m a s i a d o compleja p a r a obtener esto idea incluso con t o d o el p o d e r h u m a n o . " Benjamín Cardozo La g e n t e o b t i e n e t a n t a (o m á s ) s a t i s f a c c i ó n d e l p r o c e s o c r e a t i v o q u e del p r o d u c t o final. U n p i n t o r d i s f r u t a l o s t r a z o s d e l p i n c e l t a n t o c o m o el r e s u l t a d o del c u a d r o . U n e s c r i t o r d i s f r u t a la b ú s q u e d a d e u n a m e t á f o r a a p r o p i a d a t a n t o c o m o el l i b r o t e r m i n a d o . Un p r o f e s i o n a l del s o f t w a r e c r e a t i v o d e b e sentir t a n t a s a t i s f a c c i ó n del p r o c e s o c o m o del p r o d u c t o t e r m i n a d o . El t r a b a j o q u e r e a l i z a la g e n t e d e s o f t w a r e c a m b i a r á e n l o s a ñ o s q u e s i g u e n . La d u a l i d a d del p r o d u c t o y el p r o c e s o e s u n e l e m e n t o i m p o r t a n t e p a r a m a n t e n e r a la g e n t e c r e a t i v a c o m p r o m e t i d a m i e n t r a s finaliza la t r a n s i c i ó n d eTM s d e la p r o g r a m a c i ó n h a s t a la i n g e n i e r í a d e l s o f t w a r e .

PDF Editor 2 , 9

RESUMEN

La i n g e n i e r í a d e l s o f t w a r e e s u n a d i s c i p l i n a q u e i n t e g r a al p r o c e s o , l o s m é t o d o s y l a s

h e r r a m i e n t a s p a r a el d e s a r r o l l o d e l s o f t w a r e d e c o m p u t a d o r a . S e h a p r o p u e s t o u n g r a n n ú m e r o d e m o d e l o s d e p r o c e s o p a r a l a i n g e n i e r í a del s o f t w a r e , p e r o t o d o s d e finen

u n c o n j u n t o d e a c t i v i d a d e s del m a r c o d e t r a b a j o , u n a c o l e c c i ó n d e t a r e a s c o n -

CAPÍTULO 2


45

ducidas p a r a realizar c a d a actividad, productos d e trabajo g e n e r a d o s c o m o c o n s e c u e n c i a d e l a s t a r e a s y u n c o n j u n t o d e a c t i v i d a d e s s o m b r i l l a q u e a c o m p a ñ a n el p r o c e s o entero. Los p a t r o n e s d e p r o c e s o p u e d e n a p r o v e c h a r s e p a r a definir las c a r a c t e r í s t i c a s del m i s m o . La i n t e g r a c i ó n del m o d e l o d e c a p a c i d a d d e m a d u r e z (IMCM) e s u n m o d e l o t o t a l del proceso, q u e describe las m e t a s , prácticas y c a p a c i d a d e s específicas c o n q u e deb e c o n t a r u n p r o c e s o d e s o f t w a r e m a d u r o . El SPICE y o t r o s e s t á n d a r e s d e f i n e n l o s r e q u i s i t o s p a r a g u i a r u n a e v a l u a c i ó n d e l p r o c e s o d e s o f t w a r e , y el e s t á n d a r ISO 9 0 0 1 : 2 0 0 0 e x a m i n a la g e s t i ó n d e la c a l i d a d d e n t r o d e u n p r o c e s o . S e h a n p r o p u e s t o l o s m o d e l o s p e r s o n a l y e n e q u i p o p a r a el p r o c e s o d e s o f t w a r e . A m b o s d e s t a c a n la m e d i c i ó n , la p l a n e a c i ó n y la a u t o d i r e c c i ó n c o m o i n g r e d i e n t e s clave para un proceso de software exitoso. L o s p r i n c i p i o s , c o n c e p t o s y m é t o d o s q u e p e r m i t e n r e a l i z a r el p r o c e s o l l a m a d o ingeniería

del software

s e r á n c o n s i d e r a d o s e n el r e s t o d e e s t e libro.

[AMB98] Ambler, S., Process Patterns: Buiiding Large-Scale Systems Using Object Technology, Cambridge University Press/SIGS Books, 1998. [BAE98] Baetjer, Jr., H., Software as Capital, IEEE C o m p u t e r Society Press, 1998, p. 85. [CIA01] Cianfrani, C. et ai, ISO 9001:2000 Explained, American Society of Quality, 2001. [CMM02] Capability, Maturity Model Integration (CMMI), Versión 1.1, Software Engineering Institute, marzo d e 2002, disponible en h t t p : / / w w w . s e i . c m u . e d u / c m m i / . [DAV95] Davis, M„ "Process and Product: Dichotomy or Duality", en Software Engineering Notes, ACM Press, vol. 20, n ú m . 2, abril de 1995, pp. 17-18. [DUN01 IDunaway, D. y S. Masters, CMM-Based Appraisalfor Intemal Process Improvement (CBAIPI Versión 1.2 Method Description, S o f t w a r e Engineering institute, 2001, p u e d e d e s c a r g a r s e de h t t p y / w w w . s e i . c m u . e d u / p u b l i c a t i o n s / d o c u m e n t s / 0 1 .reports/01 tr033.html [ELE98| El E m a m , K., J. Drouin y W. Meló (eds.), SPICE: The Theory and Practice of Software Process Improvement and Capability Determination, IEEE C o m p u t e r Society Press, 1998. [FER97] Ferguson, P. et al., "Results of applying t h e p e r s o n a l s o f t w a r e process", en IEEE Computer, vol. 30, n ú m . 5, m a y o d e 1997, pp. 24-31. [HUM96] Humphrey, W., "Using a Defined a n d M e a s u f e d Personal S o f t w a r e Process", en IEEE Software, vol. 13, núm. 3, mayo-junio d e 1996, pp. 77-88. [HUM971 Humphrey, W„ Introduction to the Personal Software Process, Addison-Wesley, 1997. [HUM98] Humphrey, W., "The Three D i m e n s i o n s of Process I m p r o v e m e n t , Part III: The Team Process", en Crosstalk, abril d e 1998. Disponible en h t t p : / / w w w . s t s c . h i l l . a f . m i l / c r o s s t a l k / 1998/apr/dimensions.asp. [HUM001 Humphrey, W., Introduction to the Team Software Process, Addison-Wesley, 2000. [IEE93] 1EE Standards Collection: Software Engineering, 1EE S t a n d a r d 610.12-1990, IEEE, 1993. [15000] ISO 9001:2000 Document Set, International O r g a n i z a t i o n for S t a n d a r d s , 2000, h t t p : / / TM www.iso.ch/iso/en/iso9000-14000/ iso9000/ 9000isoindex.html. [15001] "Guidance on t h e P r o c e s s A p p r o a c h to Quality M a n a g e m e n t Systems", D o c u m e n t ISO/TC 176/SC2/N544R, International O r g a n i z a t i o n for S t a n d a r d s , m a y o de 2001. [KET01) Ketola, J. y K, Roberts, ISO 9001:2000 in a Nutshell, 2a. ed., Patón Press, 2001. [MONOll Monnich, H., Jr. y H. Monnich, ISO 9001:2000 for Small-and Medium-Sized Businesses, American Society of Quality, 2001. [NAU69] Naur, P. y B. Randall (eds.). Software Engineering: A Report on a Conference Sponsored by the NATO Science Cominee, NATO, 1969. [NEG991 Negele, H., "Modeling of Integrated Product Development proceses", Proc. 9th Annual Symposium ofINCOSE, Reino Unido, 1999.

PDF Editor

PARTE UNO


[PAU93] Paulk, M. eí al., Capabihty Maturity Model/or Software, S o f t w a r e Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1993. [PHI02] Phillips, M„ "CMMI VI.1 TUtorial", abril d e 2002, disponible en h t t p : / / w w w . s e i . c m u . edu/cmmi/. [SEI00] SCAMPl, VI.0 Standard CMMI ® Assessment Method for Process Improvement: Method Description, S o f t w a r e Engineering Institute, Technical Report CMU/SEI-2000-TR-009, disponible en h t t p / / w w w . s e i . c m u . e d u / p u b l i c a t i o n s / d o c u m e n t s / 0 0 . r e p o r t s / 0 0 t r 0 0 9 . h t m l [SPI991 "SPICE: S o f t w a r e Process A s s e s s m e n t , Part 1: Conc e pts and lntroduction", Versión 1.0, ISO/IEC JTCI, 1999.

2.1. En la introducción a e s t e capitulo, Baetjer puntualiza: "El p r o c e s o o f r e c e u n a interacción e n t r e usuarios y diseñadores, entre usuarios y h e r r a m i e n t a s en evolución, e n t r e d i s e ñ a d o r e s y h e r r a m i e n t a s en evolución [tecnologia]". Háganse cinco p r e g u n t a s respecto a a) lo q u e los dis e ñ a d o r e s d e b e n p r e g u n tar a los usuarios; b) los u s u a r i o s d e b e n pre guntar a los d i s e ñ a d o r e s ; c) lo q u e los u s u a r i o s d e b e n p r e g u n t a r s e a sí m i s m o s s o b r e el p r o d u c t o d e s o f t w a r e q u e se construirá; y d) lo q u e los d i s e ñ a d o r e s d e b e n p r e g u n t a r s e a sí m i s m o s s o b r e el p r o d u c t o d e software q u e se construirá y el proceso que se utilizará para hacerlo. 2 . 2 . En la figura 2.1 se colocan los tres estratos de ingeniería del software arriba de un estrato titulado "un enfoque en la calidad". Esto implica un programa de calidad de una organización a m plia como gestión d e la calidad total. Realizar una pequeña investigación y desarrollar una guía de los principios clave d e un programa d e gestión de calidad total. 2 . 3 . ¿Existe la posibilidad d e que las actividades g e n é r i c a s del p r o c e s o d e ingeniería del software n o se apliquen? Si es así, descríbase. 2 . 4 . Las actividades sombrilla ocurren a lo largo d e t o d o el p r o c e s o del s o f t w a r e . ¿Se aplican d e m o d o u n i f o r m e a t r a v é s del p r o c e s o o a l g u n a s e s t á n c o n c e n t r a d a s en u n a o m á s actividad e s del m a r c o d e trabajo? 2 . 5 . Descríbase un m a r c o d e trabajo del p r o c e s o c o n p a l a b r a s propias. C u a n d o se dice q u e las actividades del marco de trabajo son aplicables a todos los proyectos, ¿esto significa que las mism a s t a r e a s d e t r a b a j o se aplican a t o d o s los proyectos, sin importar el t a m a ñ o y complejidad? Expliqúese la respuesta. 2.6. Intente establecer un c o n j u n t o d e tareas p a r a la actividad de comunicación. 2 . 7 . Investigar un poco m á s acerca de la IMCM y discutir las v e n t a j a s y d e s v e n t a j a s d e los modelos de la IMCM continuo y discreto. 2.8. Desplegar la documentación de la IMCM del sitio d e la red del SEI y seleccionar un área del proceso que no sea la planeación del proyecto. Hacer u n a lista d e las m e t a s específicas (ME) y de las prácticas especificas (PE) a s o c i a d a s que se definan m e d i a n t e el área q u e se haya elegido. 2 . 9 . Considerar la actividad d e comunicación d e n t r o del m a r c o d e trabajo. Desarrollar un p a trón completo del p r o c e s o (podría ser un p a t r ó n discreto) a p r o v e c h a n d o TM los principios descritos en la sección 2.4. 2 . 1 0 . ¿Cuál es el propósito d e la evaluación del proceso? ¿Por q u é el SPICE ha sido desarrollado c o m o un e s t á n d a r para la evaluación del proceso?

PDF Editor

2.11. Investigar m á s s o b r e el PSP y p r e p a r a r u n a breve p r e s e n t a c i ó n q u e indique los b e n e f i cios cuantitativos del proceso. 2.12. La utilización d e "escritos" (un m e c a n i s m o requerido en el PSE) n o goza d e gran a c e p t a ción entre la c o m u n i d a d del software. Hacer u n a lista de las ventajas y d e s v e n t a j a s mientras se t o m a n en c u e n t a los escritos y sugerir al m e n o s dos situaciones en q u e serian útiles y o t r a s d o s situaciones en d o n d e n o tendrían t a n t o s beneficios.

47

El estado actual de la ingeniería deL software y el p r o c e s o de software lo determinan bien publicaciones m e n s u a l e s c o m o IEEE Software, Computer, y IEEE Transactions on Software Engineering. Publicaciones periódicas c o m o Application Development Trends y Cutter IT Journal a m e n u d o contienen artículos sobre t e m a s d e ingeniería del software. La disciplina se "resume" c a d a a ñ o en la Proceeding of the International Conference on Software Engineering, patrocinado por el IEEE y ACM, y se discute a profundidad en publicaciones c o m o ACM Transactions on Software Engineering and Methodology, ACM Software Engineering Notes y Annals of Software Engineering. Miles d e p á g i n a s de la red están dedicadas a la ingeniería del software y al proceso d e software. En los a ñ o s recientes se h a n publicado m u c h o s libros referentes al proceso de software y a la ingeniería del software. Algunos p r e s e n t a n un p a n o r a m a del proceso en su totalidad, mientras otras centran su atención en u n o s c u a n t o s t e m a s importantes y excluyen otros. Entre las propuestas m á s populares se encuentran: Abran, A. y ) . Moore, SWEBOK: Guide to the Software Engineering Body of Knowledge, 2002.

IEEE,

Ahern, D, etal., CMMI Distilled, Addison-Wesley, 2001.

Chrisis, B. ef al., CMMI: Cuidelines for Process Integration and Product Improvement, AddisonWesley, 2003. Christensen, M. y R. Thayer, A Projecl Manager's Guide to Software Engineering Best Practices, 1EEE-CS Press (Wiley), 2002. Glass, R., Fact and Fallacies of Software Engineering, Addison-Wesley, 2002. Hunter, R. y R. Thayer (eds.), Software Process Improvement, Persse,)., Implementing

1EEE-CS Press (Wiley), 2001.

the Capability Maturity Model, Wiley, 2001.

Pfleeger, S„ Software Engineering: Theoiy and Practice, 2a. e d „ Prentice-Hall, 2001. Potter, N. y M. Sakry, Making Process Improvement

Work, Addison-Wesley, 2002.

Sommerville, I., Software Engineering, 6a. ed„ Addison-Wesley, 2000 En lo que respecta a lecturas m á s ligeras, un libro d e Robert Glass (Software Conftict, Yourdon Press, 1991) presenta ensayos sorprendentes y controversiales sobre el software y el proceso d e ingeniería del software. Yourdon (Death March Piojects, Prentice-Hall, 1997) e x p o n e lo q u e sale mal c u a n d o fallan g r a n d e s proyectos d e software y c ó m o evitar e s o s errores. G a r m u s (Measuring the Software Process, Prentice-Hall, 1995) y Florac y Carlton (Measuring the Software Process, Addison-Wesley, 1999) explican c ó m o evaluar d e m o d o estadístico la eficacia d e cualquier p r o c e s o d e software. Se ha publicado u n a gran variedad de procedimientos y e s t á n d a r e s d e la ingeniería del software desde la década p a s a d a . El IEEE Software Engineering Standards contiene m u c h o s e s t á n d a r e s diferentes que cubren casi cada u n o de los aspectos importantes de la tecnología. El c o n j u n t o d e d o c u m e n t o s ISO 9001:2000 proporciona u n a guía a las organizaciones d e software q u e d e s e e n mejorar s u s actividades de gestión de calidad. Otros e TM s t á n d a r e s de ingeniería del software se p u e d e n obtener del D e p a r t a m e n t o de Defensa, la FAA y otras agencias g u b e r n a m e n t a l e s y n o lucrativas de Estados Unidos d e America. Fairclough (Software Engineering Guides, Prentice-Hall, 1996) ofrece una referencia detallada de e s t á n d a r e s de ingeniería del software producida por la Agencia Espacial Europea (ESA, por sus siglas en inglés). En Internet está disponible u n a gran variedad d e f u e n t e s de información sobre ingeniería del software y el p r o c e s o d e software. Una lista actualizada de referencias de la World w i d e Web relevantes p a r a el proceso de software p u e d e encontrarse en el sitio: http://www.mhhe.com/pressman.

PDF Editor

C A P Í T U L O

3 CONCEPTOS CLAVE construcción de prototipos . . . . .55 desarrollo concurrente . . . .60 métodos (orinales

.64

modelo DBC . . . .63 modelo DRA . . . .53

M O D E L O S PRESCRIPTIVOS DE P R O C E S O

L

o s m o d e l o s prescriptivos de p r o c e s o s e p r o p u s i e r o n o r i g i n a l m e n t e p a r a ord e n a r el c a o s del d e s a r r o l l o d e s o f t w a r e . La historia ha i n d i c a d o q u e e s t o s m o d e l o s c o n v e n c i o n a l e s h a n traído c o n s i g o cierta c a n t i d a d d e e s t r u c t u r a s útiles p a r a el t r a b a j o e n la ingeniería del s o f t w a r e , y h a n p r o p o r c i o n a d o u n c a m i n o a seguir r a z o n a b l e m e n t e efectivo p a r a los e q u i p o s d e s o f t w a r e . Sin e m b a r g o , el t r a b a j o d e la ingeniería del s o f t w a r e y el p r o d u c t o resultante a ú n p e r m a n e c e n "al b o r d e del c a o s " [NOGOO], En u n d o c u m e n t o intrigante s o b r e la e x t r a ñ a relación e n t r e el o r d e n y el c a o s e n el m u n d o del s o f t w a r e , Nogueira y s u s c o l e g a s e s t a b l e c e n : El b o r d e del c a o s s e d e f i n e c o m o "un e s t a d o n a t u r a l e n t r e el o r d e n y el c a o s , u n a

modelo DSOA . . .65

relación e s t r e c h a e n t r e la e s t r u c t u r a y la s o r p r e s a " [KAU95J. El b o r d e del c a o s se p u e d e

modelo en cascada

visualizar c o m o u n e s t a d o inestable, e s t r u c t u r a d o en f o r m a parcial... e s i n e s t a b l e .50

modelo en espiral

.58

Se t i e n d e a p e n s a r q u e el o r d e n e s el e s t a d o ideal d e la n a t u r a l e z a . Esto p o d r í a ser

modelo incremenlal . . . .52

u n e r r o r . La i n v e s t i g a c i ó n . . . a p o y a la t e o r í a d e q u e la o p e r a c i ó n l e j o s del equilibrio

modelo prescriptivo . .

c i e n t e [ R 0 0 9 6 J . El o r d e n a b s o l u t o s i gni fi ca la a u s e n c i a d e variabilidad, lo c u a l s e r í a

p o r q u e e s a t r a í d o d e m a n e r a c o n s t a n t e hacia el c a o s o h a c i a el o r d e n a b s o l u t o .

g e n e r a c r e a t i v i d a d , p r o c e s o s o r g a n i z a d o s p o r sí m i s m o s y r e t r o a l i m e n t a c i ó n c r e -

.49

u n a v e n t a j a e n a m b i e n t e s i m p r e d e c i b l e s . El c a m b i o o c u r r e c u a n d o e x i s t e a l g u n a e s -

proceso evolutivo

54

p a r a q u e evite el c a m b i o . Por o t r o lado, d e m a s i a d o c a o s p u e d e imposibilitar la c o o r -

proceso unificado

67

t r u c t u r a p a r a q u e p u e d a o r g a n i z a r s e , d i c h a e s t r u c t u r a n o d e b e s e r t a n rigida c o m o d i n a c i ó n y la c o h e r e n c i a . La falta d e e s t r u c t u r a n o s i e m p r e significa d e s o r d e n .

¿ Q u é e s ? Los modelos prescriptivos de proceso definen un conjunto distinto d e actividades, acciones, tareas, fundamentos y productos d e trabajo que se requieren para desarrollar software de alta calidad. Estos modelos de proceso no son perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software. ¿ Q u i é n l o h a c e ? Los ingenieros de software y sus gerentes adaptan un modelo prescriptivo d e proceso a sus necesidades y después lo siguen. Además, la gente que ha solicitado el software tiene un papel por desempeñar conforme se ejecuta el modelo de software. ¿ P o r q u é e s i m p o r t a n t e ? Porque proporciona estabilidad, control y organización a una activi-

dad que si no se controla puede volverse caótica. Algunas veces los modelos de proceso prescriptivo se han referido como "modelos rigurosos de proceso", ya que a menudo incluyen las capacidades sugeridas por la IMCM (capítulo 2). Sin embargo, iodos los modelos de proceso se pueden adaptar para usarlos de forma efectiva y en un proyecto de software específico. ¿ C u á l e s s o n l o s p a s o s ? El TM proceso conduce a un equipo d e software a través de un conjunto de actividades del marco de trabajo que se organizan en un flujo de proceso, el cual puede ser lineal, ¡ncremental o evolutivo. La terminología y los detalles de cada modelo de proceso difieren, pero las actividades genéricas del marco de trabajo permanecen razonablemente consistentes.

PDF Editor 48

CAPÍTULO 3

49


i Cuál e s el producto obtenido? Desde el ounto de vista de un ingeniero d e software, los productos de trabajo son los programas, documentos y datos que se producen como consecuencia de las actividades y tareas q u e define el proceso.

¿Cómo p u e d o estar seguro d e que lo he

d a d de mecanismos p a r a la evaluación del proceso d e software que permite a las organizaciones determinar la "madurez" de sus respectivos procesos. Sin embargo, los mejores indicadores de la eficacia del proceso que se utiliza son la calidad, el tiempo d e entrega y la viabilidad a largo plazo del producto que se construye

h e c h o c o r r e c t a m e n t e ? Existe cierta canti-

Las i m p l i c a c i o n e s f i l o s ó f i c a s d e e s t e a r g u m e n t o s o n s i g n i f i c a t i v a s r e s p e c t o d e la i n g e n i e r í a del s o f t w a r e . Si l o s m o d e l o s p r e s c r i p t i v o s del p r o c e s o 1 b u s c a n e s t r u c t u r a y o r d e n , ¿ é s t o s r e s u l t a n i n a p r o p i a d o s p a r a un m u n d o del s o f t w a r e q u e se b a s a e n el c a m b i o ? A d e m á s , si s e r e c h a z a n los m o d e l o s c o n v e n c i o n a l e s del p r o c e s o (y el o r d e n q u e é s t o s implican) y s e r e e m p l a z a n c o n a l g o m e n o s e s t r u c t u r a d o , ¿ s e imposibilita a l c a n z a r la c o o r d i n a c i ó n y la c o h e r e n c i a e n el t r a b a j o del s o f t w a r e ? No e x i s t e n r e s p u e s t a s fáciles, p e r o e x i s t e n o p c i o n e s d i s p o n i b l e s p a r a los i n g e n i e ros de s o f t w a r e . En e s t e c a p í t u l o s e e x a m i n a r á el e n f o q u e del p r o c e s o prescriptivo, e n el c u a l el o r d e n y la c o n s i s t e n c i a del p r o y e c t o s o n los a s p e c t o s d o m i n a n t e s . En el c a p í t u l o 4 s e e x a m i n a r á el e n f o q u e del p r o c e s o ágil e n el c u a l la o r g a n i z a c i ó n p r o pia, la c o l a b o r a c i ó n , la c o m u n i c a c i ó n y la a d a p t a b i l i d a d d o m i n a n la filosofía del p r o ceso.

3.1

M O D E L O S PRESCPTPTIVOS C u a l q u i e r o r g a n i z a c i ó n d e ingeniería del s o f t w a r e d e b e describir u n c o n j u n t o ú n i c o d e a c t i v i d a d e s d e n t r o del m a r c o de t r a b a j o (capítulo 2) p a r a el (los) p r o c e s o ( s ) de

CLAVE descriptivo n o con «Oreos actos fcto

s o f t w a r e q u e a d o p t e . T a m b i é n d e b e llenar c a d a actividad del m a r c o d e t r a b a j o c o n u n c o n j u n t o d e a c c i o n e s d e ingeniería del s o f t w a r e , y definir c a d a a c c i ó n e n c u a n t o a u n c o n j u n t o d e t a r e a s q u e identifique el t r a b a j o (y los p r o d u c t o s del t r a b a j o ) q u e d e b e n c o m p l e t a r s e p a r a a l c a n z a r las m e t a s de d e s a r r o l l o . D e s p u é s , la o r g a n i z a c i ó n d e b e a d a p t a r el m o d e l o d e p r o c e s o r e s u l t a n t e y a j u s t a r l o a la n a t u r a l e z a específica d e c a d a p r o y e c t o , a l a s p e r s o n a s q u e lo r e a l i z a r á n , y el a m b i e n t e e n el q u e s e e j e c u t a r á el t r a b a j o . Sin i m p o r t a r el m o d e l o del p r o c e s o s e l e c c i o n a d o , los i n g e n i e r o s d e s o f t w a r e h a n e l e g i d o d e m a n e r a tradicional un m a r c o de t r a b a j o g e n é r i c o p a r a el p r o c e s o , el c u a l incluye las s i g u i e n t e s a c t i v i d a d e s d e n t r o del m a r c TM o: comunicación, p l a n e a c i ó n , m o d e l a d o , c o n s t r u c c i ó n y desarrollo.

PDF Editor "Existen muchos formas de ir bocio delante, pero sólo una de permanecer."

Franklin D. Roosewelt

1

Los modelos prescriptivos de proceso a menudo se denominan modelos "convencionales" de proceso

50

ÔNSEJflj^

Aunque un proceso sea prescriptivo, no se debe asumir que éste es estático. Los modelos prescriptivos se deben adaptar o las personas, al problema y al proyecto.

PARTE UNO


En l a s s e c c i o n e s s i g u i e n t e s s e e x a m i n a r á n v a r i o s d e los m o d e l o s p r e s c r i p t i v o s del p r o c e s o d e s o f t w a r e . Se les llama "prescriptivos" p o r q u e p r e s c r i b e n u n c o n j u n t o d e e l e m e n t o s del p r o c e s o : a c t i v i d a d e s del m a r c o d e t r a b a j o , a c c i o n e s d e ingeniería del s o f t w a r e , t a r e a s , p r o d u c t o s del t r a b a j o , a s e g u r a m i e n t o d e la calidad, y m e c a n i s m o s d e c o n t r o l del c a m b i o p a r a c a d a p r o y e c t o . C a d a m o d e l o d e p r o c e s o p r e s c r i b e t a m bién un flujo de trabajo; e s t o es, la f o r m a e n la c u a l los e l e m e n t o s del p r o c e s o s e inter r e l a c i o n a n e n t r e sí. T o d o s los m o d e l o s d e p r o c e s o del s o f t w a r e s e a j u s t a n a l a s a c t i v i d a d e s g e n é r i c a s del m a r c o d e t r a b a j o d e s c r i t a s e n el c a p í t u l o 2, p e r o c a d a u n o aplica u n a i m p o r t a n cia d i f e r e n t e a e s t a s a c t i v i d a d e s y d e f i n e u n flujo d e t r a b a j o q u e i n v o c a c a d a activid a d del m a r c o d e t r a b a j o (así c o m o a c c i o n e s y t a r e a s d e la ingeniería del s o f t w a r e ) de u n a m a n e r a d i f e r e n t e .

Existen o c a s i o n e s e n q u e los requisitos de un p r o b l e m a s e e n t i e n d e n de u n a m a n e r a r a z o n a b l e : c u a n d o el t r a b a j o fluye d e s d e la c o m u n i c a c i ó n a t r a v é s del despliegue d e u n a m a n e r a casi lineal. Esta situación s e e n c u e n t r a a v e c e s c u a n d o e s n e c e s a r i o h a c e r a d a p t a c i o n e s o m e j o r í a s bien definidas a u n s i s t e m a e x i s t e n t e (por ejemplo, u n a a d a p tación a u n s o f t w a r e c o n t a b l e d e b i d o a los c a m b i o s e n las r e g u l a c i o n e s del gobierno). Esto p u e d e ocurrir t a m b i é n e n un n ú m e r o limitado d e p r o y e c t o s d e n u e v o s desarrollos, p e r o s ó l o c u a n d o los r e q u e r i m i e n t o s e s t á n bien definidos y s o n e s t a b l e s e n f o r m a r a z o nable. El modelo en cascada, a l g u n a s v e c e s l l a m a d o el ciclo de vida clásico, s u g i e r e u n e n f o q u e sistemático, s e c u e n c i a l 2 h a c i a el d e s a r r o l l o del s o f t w a r e , q u e se inicia c o n la e s p e cificación de r e q u e r i m i e n t o s del cliente y q u e c o n t i n ú a c o n la p l a n e a c i ó n , el m o d e l a d o , la c o n s t r u c c i ó n y el d e s p l i e g u e para c u l m i n a r e n el s o p o r t e del s o f t w a r e t e r m i n a d o . El m o d e l o e n c a s c a d a e s el p a r a d i g m a m á s a n t i g u o p a r a la ingeniería del s o f t w a re. Sin e m b a r g o , e n las d é c a d a s p a s a d a s , l a s críticas a e s t e m o d e l o d e p r o c e s o h a n

El m o d e l o e n c a s c a d a .

TM

PDF Editor 2

A pesar de q u e el modelo en cascada original, q u e propuso Winston Royce [ROY70], prevé "ciclos

d e retroalimentación", la inmensa mayoría de las organizaciones q u e aplica e s t e m o d e l o de proceso lo trata c o m o si fuera estrictamente lineal.

CAPÍTULO 3

51


o c a s i o n a d o q u e a u n s u s m á s f e r v i e n t e s p r a c t i c a n t e s h a y a n c u e s t i o n a d o s u eficacia [HAN95], Entre l o s p r o b l e m a s q u e a l g u n a s v e c e s s e e n c u e n t r a n al aplicar el m o d e l o ¿ñwqeé

en cascada están: 1.

Miel

Es m u y r a r o q u e los p r o y e c t o s r e a l e s s i g a n el flujo s e c u e n c i a l q u e p r o p o n e el m o d e l o . A p e s a r d e q u e el m o d e l o lineal incluye iteraciones, lo h a c e de m a n e r a indirecta. C o m o r e s u l t a d o , l o s c a m b i o s c o n f u n d e n m i e n t r a s el e q u i p o d e proyecto actúa.

2.

Con f r e c u e n c i a e s difícil p a r a el cliente e s t a b l e c e r t o d o s los requisitos de m a n e r a explícita. El m o d e l o e n c a s c a d a lo r e q u i e r e y s e e n f r e n t a n d i f i c u l t a d e s al inc o r p o r a r la i n c e r t i d u m b r e n a t u r a l p r e s e n t e e n el inicio d e m u c h o s p r o y e c t o s .

3.

El cl i ente d e b e t e n e r p a c i e n c i a . U n a v e r s i ó n q u e f u n c i o n e d e l o s p r o g r a m a s e s t a r á d i s p o n i b l e c u a n d o el p r o y e c t o e s t é m u y a v a n z a d o . Un e r r o r g r a v e s e r á d e s a s t r o s o si n o s e d e t e c t a a n t e s d e la revisión del p r o g r a m a .

En un a n á l i s i s i n t e r e s a n t e d e p r o y e c t o s r e a l e s , B r a d a c [BRA94] c o n c l u y ó q u e la n a t u r a l e z a lineal del m o d e l o e n c a s c a d a c o n d u c e a " e s t a d o s d e b l o q u e o " e n los c u a les a l g u n o s m i e m b r o s del e q u i p o del p r o y e c t o d e b e n e s p e r a r a o t r o s p a r a t e r m i n a r t a r e a s d e p e n d i e n t e s . D e h e c h o , el t i e m p o de e s p e r a p u e d e s u p e r a r el q u e s e aplica e n el t r a b a j o p r o d u c t i v o . El e s t a d o d e b l o q u e o t i e n d e a s e r m á s c o m ú n al principio y al final del p r o c e s o s e c u e n c i a l . En la a c t u a l i d a d , el t r a b a j o del s o f t w a r e e s t á a c e l e r a d o y s u j e t o a u n a c a d e n a infin i t a d e c a m b i o s (de c a r a c t e r í s t i c a s , f u n c i o n e s y c o n t e n i d o d e la i n f o r m a c i ó n ) . Con f r e c u e n c i a , el m o d e l o e n c a s c a d a n o e s a p r o p i a d o p a r a d i c h o t r a b a j o . Sin e m b a r g o , p u e d e servir c o m o u n m o d e l o d e p r o c e s o útil e n s i t u a c i o n e s d o n d e los r e q u e r i m i e n t o s e s t á n fijos y d o n d e el t r a b a j o s e realiza, h a s t a su c o n c l u s i ó n , d e u n a m a n e ra lineal.

3 . 3

msn

M O D E L O S DE P R O C E S O INCREMENTALES

En m u c h a s s i t u a c i o n e s los r e q u i s i t o s iniciales del s o f t w a r e e s t á n bien d e f i n i d o s e n f o r m a r a z o n a b l e , p e r o el e n f o q u e global del e s f u e r z o d e d e s a r r o l l o e x c l u y e u n p r o c e s o p u r a m e n t e lineal. A d e m á s , q u i z á h a y a u n a n e c e s i d a d i m p e r i o s a de p r o p o r c i o n a r de m a n e r a r á p i d a u n c o n j u n t o limitado de f u n c i o n a l i d a d p a r a el u s u a r i o y d e s p u é s r e f i n a r l a y e x p a n d i r l a e n l a s e n t r e g a s p o s t e r i o r e s del s o f t w a r e . En e s t o s c a s o s

TM

s e elige u n m o d e l o d e p r o c e s o d i s e ñ a d o p a r a p r o d u c i r el s o f t w a r e e n f o r m a i n c r e mental.

PDF Editor

"Con demasiada fretuencio, el frobajo en el software sigue lo primero ley del ciclismo: no importa hacia dónde vayas, es montaña arriba y contra el viento." Anónimo

52

PASTE UNO 3.3.1

CLAVE El modelo incrementol entrega uno serie de lanzamientos, llamados mementos, que proporcionan en forma progresiva más funcionalidad para los dientes a medida que se entrega cada uno de los incrementos.


El m o d e l o i n c r e m e n t a l

El modelo

incremental

c o m b i n a e l e m e n t o s del m o d e l o e n c a s c a d a a p l i c a d o e n f o r m a

iterativa. C o m o s e m u e s t r a e n la figura 3.2, el m o d e l o i n c r e m e n t a l aplica s e c u e n c i a s l i n e a l e s d e m a n e r a e s c a l o n a d a c o n f o r m e a v a n z a el t i e m p o e n el c a l e n d a r i o . C a d a s e c u e n c i a lineal p r o d u c e " i n c r e m e n t o s " del s o f t w a r e [MCD93]. Por e j e m p l o , el s o f t w a r e p r o c e s a d o r de t e x t o , d e s a r r o l l a d o c o n el p a r a d i g m a i n c r e m e n t a l e n s u p r i m e r i n c r e m e n t o , p o d r í a r e a l i z a r f u n c i o n e s b á s i c a s d e a d m i n i s t r a c i ó n d e a r c h i v o s , edición y p r o d u c c i ó n d e d o c u m e n t o s ; e n el s e g u n d o i n c r e m e n t o , e d i c i o n e s m á s sofisticadas, y t e n d r í a f u n c i o n e s m á s c o m p l e j a s d e p r o d u c c i ó n d e d o c u m e n t o s ; e n el t e r c e r i n c r e m e n t o , f u n c i o n e s d e c o r r e c c i ó n o r t o g r á f i c a y g r a m a t i c a l ; y e n el c u a r t o , c a p a c i d a d e s a v a n z a d a s d e c o n f i g u r a c i ó n d e p á g i n a . Se d e b e t e n e r e n c u e n t a q u e el flujo del p r o c e s o d e c u a l q u i e r i n c r e m e n t o p u e d e i n c o r p o r a r el p a r a d i g m a d e c o n s t r u c c i ó n de p r o t o t i p o s q u e s e e x p o n e e n la s e c c i ó n 3.4.1. A m e n u d o , al utilizar un m o d e l o i n c r e m e n t a l el p r i m e r i n c r e m e n t o e s u n producto esencial.

E s decir, s e i n c o r p o r a n los r e q u i s i t o s b á s i c o s , p e r o m u c h a s c a r a c t e r í s t i -

c a s s u p l e m e n t a r i a s ( a l g u n a s c o n o c i d a s , o t r a s no) n o se i n c o r p o r a n . El p r o d u c t o e s e n c i a ] q u e d a e n m a n o s del cliente (o s e s o m e t e a u n a e v a l u a c i ó n detallada). C o m o (CONSEJÓ^ Si el cliente demando lo entrega en una fecha imposible de cumplh, sugiérase entregar uno o más incrementos para esa fecho y el resto del software lincrementos adicionales) después.

r e s u l t a d o d e la e v a l u a c i ó n s e d e s a r r o l l a u n p l a n p a r a el i n c r e m e n t o s i g u i e n t e . El p l a n a f r o n t a la m o d i f i c a c i ó n del p r o d u c t o e s e n c i a l c o n el fin d e s a t i s f a c e r de m e j o r m a n e ra l a s n e c e s i d a d e s del cl i ente y la e n t r e g a de c a r a c t e r í s t i c a s y f u n c i o n a l i d a d a d i c i o n a l e s . Este p r o c e s o s e repite d e s p u é s d e la e n t r e g a de c a d a i n c r e m e n t o m i e n t r a s n o s e h a y a e l a b o r a d o el p r o d u c t o c o m p l e t o . El m o d e l o d e p r o c e s o i n c r e m e n t a l , al igual q u e la c o n s t r u c c i ó n d e p r o t o t i p o s y o t r o s e n f o q u e s evolutivos, e s iterativo por n a t u r a l e z a . P e r o a d i f e r e n c i a d e la c o n s t r u c c i ó n d e p r o t o t i p o s , el m o d e l o i n c r e m e n t a l s e e n f o c a e n la e n t r e g a d e u n p r o d u c t o o p e r a c i o n a l c o n c a d a i n c r e m e n t o . Los p r i m e r o s i n c r e m e n t o s s o n v e r s i o n e s

El m o d e l o incremental.

TM

PDF Editor T i e m p o del c a l e n d a r i o d e p r o y e c t o

CAPÍTULO 3

53


" i n c o m p l e t a s " del p r o d u c t o final, p e r o p r o p o r c i o n a n al u s u a r i o la f u n c i o n a l i d a d q u e necesita y u n a plataforma para evaluarlo.3 El d e s a r r o l l o i n c r e m e n t a l e s útil s o b r e t o d o c u a n d o el p e r s o n a l n e c e s a r i o p a r a u n a i m p l e m e n t a c i ó n c o m p l e t a n o e s t á disponible. Los p r i m e r o s i n c r e m e n t o s s e p u e d e n i m p l e m e n t a r c o n m e n o s g e n t e . Si el p r o d u c t o e s e n c i a l e s bien recibido s e a g r e g a (si se requiere) m á s p e r s o n a l p a r a i m p l e m e n t a r el i n c r e m e n t o s i g u i e n t e . A d e m á s , los i n c r e m e n t o s s e p u e d e n p l a n e a r p a r a m a n e j a r los r i e s g o s t é c n i c o s . Por e j e m p l o , un s i s t e m a g r a n d e p o d r í a r e q u e r i r la disponibilidad de u n h a r d w a r e n u e v o q u e e s t á en d e s a r r o l l o y c u y a f e c h a de e n t r e g a e s incierta. Sería p o s i b l e p l a n e a r los p r i m e r o s i n c r e m e n t o s d e f o r m a q u e s e evite el u s o d e e s t e h a r d w a r e , lo q u e permitiría la e n t r e g a d e f u n c i o n a l i d a d parcial a los u s u a r i o s finales sin r e t r a s o s d e s o r d e n a d o s .

3.3.2

El modelo DRA

El desarrollo rápido de aplicaciones

(DRA) e s un m o d e l o de p r o c e s o d e s o f t w a r e i n c r e -

m e n t a l q u e r e s a l t a u n ciclo de d e s a r r o l l o corto. El m o d e l o DRA e s u n a a d a p t a c i ó n a "alta v e l o c i d a d " del m o d e l o e n c a s c a d a e n el q u e s e logra el d e s a r r o l l o r á p i d o m e d i a n t e u n e n f o q u e d e c o n s t r u c c i ó n b a s a d o e n c o m p o n e n t e s . Si s e e n t i e n d e n b i e n los r e q u i s i t o s y s e limita el á m b i t o del proyecto, 4 el p r o c e s o DRA p e r m i t e q u e u n e q u i p o d e d e s a r r o l l o c r e e u n " s i s t e m a c o m p l e t a m e n t e f u n c i o n a l " d e n t r o de u n p e r i o d o m u y c o r t o (por e j e m p l o , d e 6 0 a 9 0 días) [MARSH ]. C o m o o t r o s m o d e l o s d e p r o c e s o , el e n f o q u e DRA c u m p l e c o n las a c t i v i d a d e s g e n é r i c a s del m a r c o d e t r a b a j o q u e ya se h a n p r e s e n t a d o . La comunicación

trabaja

p a r a e n t e n d e r el p r o b l e m a de n e g o c i o s y las c a r a c t e r í s t i c a s d e i n f o r m a c i ó n q u e d e b e incluir el s o f t w a r e . La planeación

e s e s e n c i a l p o r q u e v a r i o s e q u i p o s de s o f t w a r e t r a -

b a j a n e n p a r a l e l o s o b r e d i f e r e n t e s f u n c i o n e s del s i s t e m a . El modelado

incluye t r e s

g r a n d e s f a s e s — m o d e l a d o d e n e g o c i o s , m o d e l a d o de d a t o s y m o d e l a d o del p r o c e s o — y e s t a b l e c e r e p r e s e n t a c i o n e s del d i s e ñ o q u e s i r v e n c o m o b a s e p a r a la actividad de c o n s t r u c c i ó n del m o d e l o DRA. La construcción

r e s a l t a el e m p l e o d e c o m p o n e n t e s

d e s o f t w a r e e x i s t e n t e y la aplicación de la g e n e r a c i ó n a u t o m á t i c a d e código. Por últim o , el despliegue

e s t a b l e c e u n a b a s e p a r a l a s i t e r a c i o n e s s u b s e c u e n t e s , si é s t a s s o n

n e c e s a r i a s [KER94]. El m o d e l o d e p r o c e s o DRA s e ilustra e n la figura 3.3. Es o b v i o q u e las restricciones de t i e m p o i m p u e s t a s s o b r e un p r o y e c t o DRA exigen u n " á m b i t o d e e s c a l a s " [KER94]. Si u n a aplicación de n e g o c i o s se p u e d e m o d u l a r d e f o r m a q u e c a d a g r a n f u n c i ó n p u e d a c o m p l e t a r s e e n m e n o s de t r e s m e s e s ( m e d i a n t e la aplicación TM del e n f o q u e y a

PDF Editor 3 4

Es importante observar que para todos los modelos de proceso ágiles que se tratan en el capítulo 4 también se utiliza una filosofía incremental. Estas condiciones no se pueden garantizar por ningún medio. De hecho, muchos proyectos de software tienen los requisitos muy pobremente definidos al principio. En tales casos los enfoques de construcción de prototipos o evolutivos (sección 3.4) son mejores opciones de proceso. Véase [REI951.

PARTE UNO

54


Equipo #n

El m o d e l o DRA.

modelado del negocio m o d e l a d o d e tos datos m o d e l a d o d e l proceso

Equipo # 2

Comunicación

Modelado modelado del negocio modelado d e los d a t o s m o d e l a d o del proceso

Equipo#!

modelado del negocio modelado de los datos modelado del proceso

reutilización de componentes generación d e código automático

^tuebas^^^

Construcción reutilizactón d e componentes generoción do codigo automático pruebas

Construcción reutilización d e componentes generación automática d e código pruebas

Despliegue integración entrega retroalimentoción

/

6 0 - 9 0 días

descrito), ésta es u n a candidata para el DRA. Cada gran función s e p u e d e abordar m e d i a n t e un equipo de DRA por s e p a r a d o , p a r a d e s p u é s integrarlas y formar un todo. C o m o t o d o s los m o d e l o s de proceso, el e n f o q u e DRA tiene i n c o n v e n i e n t e s í j l ¿Cuáles • son las desventajas del modelo DRA?

[BUT94]: 1) para proyectos g r a n d e s , p e r o escalables, el DRA necesita suficientes r e c u r s o s h u m a n o s p a r a crear el n ú m e r o correcto de e q u i p o s DRA; 2) si los d e s a r r o lladores y clientes n o s e c o m p r o m e t e n con las actividades r á p i d a s n e c e s a r i a s p a r a c o m p l e t a r el s i s t e m a en u n m a r c o de t i e m p o m u y breve, los proyectos d e DRA fallarán; 3) si un s i s t e m a no s e p u e d e m o d u l a r e n f o r m a apropiada, la construcción d e los c o m p o n e n t e s n e c e s a r i o s p a r a el DRA s e r á problemática; 4) si el alto r e n d i m i e n to e s un a s p e c t o importante, y s e a l c a n z a r á al convertir interfases en c o m p o n e n t e s del sistema, el e n f o q u e DRA podría n o funcionar; y 5) el DRA sería i n a p r o p i a d o c u a n d o los riesgos técnicos s o n altos (por ejemplo, c u a n d o u n a aplicación n u e v a aplica m u c h a s n u e v a s tecnologías).

TM

PDF Editor 3.4

M O D E L O S PE PROCESO EVOLUTIVOS

El software, c o m o t o d o s los s i s t e m a s complejos, evoluciona c o n el tiempo [GIL88j.

Los requisitos de los n e g o c i o s y p r o d u c t o s a m e n u d o c a m b i a n c o n f o r m e se realiza el desarrollo; por lo tanto, la ruta lineal que c o n d u c e a un p r o d u c t o final n o s e r á real; las estrictas f e c h a s tope del m e r c a d o imposibilitan la conclusión d e un p r o d u c t o

CAPÍTULO 3

55


c o m p l e t o , p o r lo q u e s e d e b e p r e s e n t a r u n a v e r s i ó n l i m i t a d a p a r a liberar la p r e s i ó n c o m p e t i t i v a y d e n e g o c i o s ; s e t i e n e c l a r o u n c o n j u n t o d e r e q u i s i t o s del p r o d u c t o o

C&VE

s i s t e m a e s e n c i a l , p e r o t o d a v í a s e d e b e n definir los d e t a l l e s d e l a s e x t e n s i o n e s del p r o d u c t o o s i s t e m a s . En é s t a s y o t r a s s i t u a c i o n e s similares, l o s i n g e n i e r o s d e s o f t w a r e n e c e s i t a n un m o d e l o d e p r o c e s o q u e h a y a s i d o d i s e ñ a d o d e m a n e r a explícita p a r a incluir u n p r o d u c t o q u e e v o l u c i o n e c o n el t i e m p o . Los modelos

evolutivos s o n iterativos; los caracteriza la f o r m a e n q u e permiten q u e

los ingenieros d e s o f t w a r e desarrollen versiones c a d a v e z m á s c o m p l e t a s del s o f t w a r e .

3.4.1

Construcción de prototipos

A m e n u d o u n cliente d e f i n e u n c o n j u n t o d e o b j e t i v o s g e n e r a l e s p a r a el s o f t w a r e , p e r o n o identifica los r e q u i s i t o s d e t a l l a d o s d e e n t r a d a , p r o c e s a m i e n t o o s a l i d a . En o t r o s c a s o s , el r e s p o n s a b l e d e l d e s a r r o l l o del s o f t w a r e e s t á i n s e g u r o d e la e f i c a c i a d e u n a l g o r i t m o , d e la a d a p t a b i l i d a d d e u n s i s t e m a o p e r a t i v o o d e la f o r m a q u e d e b e r í a t o m a r la i n t e r a c c i ó n h u m a n o - m á q u i n a . En é s t a s , y e n m u c h a s o t r a s s i t u a c i o n e s , un paradigma

de construcción

de prototipos

p u e d e o f r e c e r el m e j o r e n f o q u e .

A p e s a r d e q u e la c o n s t r u c c i ó n d e p r o t o t i p o s s e p u e d e utilizar c o m o u n m o d e l o de p r o c e s o i n d e p e n d i e n t e , s e e m p l e a m á s c o m ú n m e n t e c o m o u n a t é c n i c a s u s c e p t i j a m é dente m m r e necesidad « m e . aeronosepa wmm e s detalles, amrmtposo wmraéeseun

ble d e i m p l e m e n t a r s e d e n t r o del c o n t e x t o de c u a l q u i e r a d e los m o d e l o s d e p r o c e s o e x p u e s t o s e n e s t e capítulo. Sin i m p o r t a r la f o r m a e n q u e é s t e s e aplique, el p a r a d i g m a de c o n s t r u c c i ó n d e p r o t o t i p o s a y u d a al i n g e n i e r o d e s i s t e m a s y al cliente a e n t e n der d e m e j o r m a n e r a c u á l s e r á el r e s u l t a d o d e la c o n s t r u c c i ó n c u a n d o los r e q u i s i t o s estén satisfechos. El p a r a d i g m a de c o n s t r u c c i ó n d e p r o t o t i p o s (figura 3.4) s e inicia c o n la c o m u n i c a c i ó n . El i n g e n i e r o d e s o f t w a r e y el cliente e n c u e n t r a n y d e f i n e n l o s o b j e t i v o s glo-

ae prototipos.

TM

PDF Editor

56

PARTE UNO


b a l e s p a r a el s o f t w a r e , identifican los r e q u i s i t o s c o n o c i d o s y l a s á r e a s del e s q u e m a e n d o n d e e s n e c e s a r i a m á s d e f i n i c i ó n . E n t o n c e s s e p l a n t e a c o n r a p i d e z u n a iteración de c o n s t r u c c i ó n de p r o t o t i p o s y se p r e s e n t a el m o d e l a d o (en la f o r m a d e u n d i s e ñ o rápido). El d i s e ñ o r á p i d o s e c e n t r a e n u n a r e p r e s e n t a c i ó n d e a q u e l l o s a s p e c t o s del s o f t w a r e q u e s e r á n visibles p a r a el cliente o el u s u a r i o final (por e j e m p l o , la c o n f i g u r a c i ó n de la i n t e r f a z c o n el u s u a r i o y el f o r m a t o d e los d e s p l i e g u e s d e salida). El d i s e ñ o r á p i d o c o n d u c e a la c o n s t r u c c i ó n d e un p r o t o t i p o . D e s p u é s , el p r o t o t i p o lo e v a l ú a el c l i e n t e / u s u a r i o y c o n la r e t r o a l i m e n t a c i ó n s e r e f i n a n los r e q u i s i t o s del s o f t w a r e q u e s e d e s a r r o l l a r á . La i t e r a c i ó n o c u r r e c u a n d o el p r o t o t i p o s e a j u s t a p a r a s a t i s f a c e r las n e c e s i d a d e s del cliente. E s t o p e r m i t e q u e al m i s m o t i e m p o el d e s a r r o llador e n t i e n d a m e j o r lo q u e s e d e b e h a c e r . De m a n e r a ideal, el p r o t o t i p o d e b e r í a servir c o m o u n m e c a n i s m o p a r a i d e n t i f i c a r los r e q u i s i t o s del s o f t w a r e . Si se c o n s t r u y e un p r o t o t i p o de t r a b a j o , el d e s a r r o l l a d o r i n t e n t a e m p l e a r los f r a g m e n t o s del p r o g r a m a y a e x i s t e n t e s o aplica h e r r a m i e n t a s (como generadores de informes, administradores de ventanas, etcétera) que permiten producir p r o g r a m a s de trabajo con rapidez. Pero ¿ q u é d e b e h a c e r s e c o n el p r o t o t i p o u n a v e z c u m p l i d o el p r o p ó s i t o d e s c r i t o ? B r o o k s [BR075] o f r e c e u n a r e s p u e s t a : En la m a y o r í a d e l o s p r o y e c t o s , el p r i m e r s i s t e m a c o n s t r u i d o a p e n a s s e utiliza. Tal v e z s e a d e m a s i a d o lento, m u y g r a n d e o t o r p e e n s u u s o , o r e ú n a l a s tres c a r a c t e r í s t i c a s a la v e z . N o existe otra o p c i ó n q u e c o m e n z a r d e n u e v o , a u n q u e s e a d o l o r o s o , e s lo m e j o r , y c o n s t r u i r u n a r e v i s i ó n r e d i s e ñ a d a e n la q u e s e r e s u e l v a n e s t o s p r o b l e m a s . . . C u a n d o s e aplica u n c o n c e p t o n u e v o d e s i s t e m a o u n a t e c n o l o g í a n u e v a , s e t i e n e q u e c o n s t r u i r u n s i s t e m a inservible y q u e s e a n e c e s a r i o d e s e c h a r , p o r q u e incluso la m e j o r p l a n e a c i ó n n o e s o m n i s c i e n t e c o m o p a r a q u e el s i s t e m a e s t é p e r f e c t o d e s d e la p r i m e r a v e z . Por lo t a n t o , la p r e g u n t a d e la a d m i n i s t r a c i ó n n o e s si d e b e c o n s t r u i r s e u n s i s t e m a piloto y d e s e c h a r l o . Esto t e n d r á q u e h a c e r s e . La ú n i c a p r e g u n t a e s si se p l a n e a la c o n s t r u c c i ó n d e u n d e s e c h a b l e o s e p r o m e t e e n t r e g á r s e l o a los clientes .

El p r o t o t i p o p u e d e servir c o m o " p r i m e r s i s t e m a " , el q u e B r o o k s r e c o m i e n d a d e s e c h a r . P e r o é s t a tal v e z s e a u n a visión i d e a l i z a d a . Es v e r d a d q u e a los c l i e n t e s y los d e s a r r o l l a d o r e s les g u s t a el p a r a d i g m a d e c o n s t r u c c i ó n d e p r o t o t i p o s . A l o s u s u a r i o s les g u s t a el s i s t e m a real y a los d e s a r r o l l a d o r e s les g u s t a c o n s t r u i r a l g o d e i n m e d i a to. Sin e m b a r g o , la c o n s t r u c c i ó n d e p r o t o t i p o s t a m b i é n s e t o r n a p r o b l e m á t i c a p o r las siguientes razones:

TM ^ O N S E J O ^

1.

El cl i ente ve lo q u e p a r e c e u n a v e r s i ó n e n f u n c i o n a m i e n t o del s o f t w a r e , sin s a b e r q u e el p r o t o t i p o e s t á u n i d o "con chicle y c a b l e p a r a e m b a l a j e " , q u e p o r

PDF Editor Resístase o la presión por convertir un prototipo burdo en un producto. Como resultado, casi siempre lo calidad se reduce.

la prisa d e h a c e r l o f u n c i o n a r n o s e h a c o n s i d e r a d o la calidad del s o f t w a r e global o la facilidad d e m a n t e n i m i e n t o a largo p l a z o . C u a n d o s e i n f o r m a q u e el p r o d u c t o d e b e c o n s t r u i r s e o t r a v e z p a r a m a n t e n e r los a l t o s n i v e l e s d e calid a d , el cl i ente n o lo e n t i e n d e y p i d e la aplicación d e " u n o s p e q u e ñ o s a j u s t e s " p a r a q u e s e p u e d a e l a b o r a r un p r o d u c t o final a partir del prototipo. Es m u y frec u e n t e q u e la g e s t i ó n del d e s a r r o l l o d e s o f t w a r e s e a m u y l e n t a .

CAPÍTULO 3 2.


57

A m e n u d o , el d e s a r r o l l a d o r e s t a b l e c e c o m p r o m i s o s d e i m p l e m e n t a c i ó n p a r a lograr q u e el p r o t o t i p o f u n c i o n e c o n r a p i d e z . Tal v e z s e utilice u n s i s t e m a operativo o lenguaje de programación i n a d e c u a d o sólo porque está disponible y es conocido; se p u e d e implementar un algoritmo ineficiente sólo para m o s t r a r c a p a c i d a d . D e s p u é s de u n t i e m p o , el d e s a r r o l l a d o r q u i z á s e f a m i liarice c o n e s t a s s e l e c c i o n e s y olvide las r a z o n e s p o r l a s q u e s o n i n a p r o p i a d a s . La selección m e n o s ideal a h o r a se c o n v i e r t e e n u n a p a r t e integral del s i s t e m a .

A p e s a r d e q u e tal v e z s u r j a n p r o b l e m a s , la c o n s t r u c c i ó n d e p r o t o t i p o s p u e d e s e r u n p a r a d i g m a e f e c t i v o p a r a la i n g e n i e r í a del s o f t w a r e . La clave e s definir las r e g l a s del j u e g o d e s d e el principio; e s decir, el cliente y el d e s a r r o l l a d o r s e d e b e n p o n e r de a c u e r d o e n q u e el p r o t o t i p o se c o n s t r u y a y sirva c o m o un m e c a n i s m o p a r a la definición d e requisitos, e n q u e s e d e s c a r t e , al m e n o s e n p a r t e , y e n q u e d e s p u é s s e d e s a rrolle el s o f t w a r e real c o n u n e n f o q u e h a c i a la calidad. HOGARSEGURO

Selección de un modelo de proceso. Primera parte El e s c e n a r i o : Sala d e reuniones grupo de

ingeniería

del software en

CPI

uno compañía (ficticia) que fabrica producconsumo p a r a uso doméstico y comercial. l e e Warren, gerente d e ingeniería; Doug gerente d e ingeniería del software; Jamie Lazar, del equipo de software; Vinod Raman, miembro >= equipo d e software; y Ed Robbins, miembro del equide software.

¿U,

software... es una buena ¡dea. Necesitamos un proceso aquí. J a m i e ( f r u n c i e n d o e l c e ñ o ) : Mi trabajo es construir programas d e computadora, no a n d a r moviendo papeles. D o u g : Dale una oportunidad antes d e decirme q u e no. Me refiero a esto. [Doug describe el marco d e t r a b a j o del proceso expuesto en el capítulo 2 y los modelos prescriptivos del proceso q u e se han presentado hasta este punto.]

conversación: e : Entonces recapitulemos. He p a s a d o algún tiempo analizando la línea de productos HogarSeguro

na p a s a d a y aprendí mucho acerca d e la ingeniería del

c o m o la

•«nos en el momento. N o hay d u d a , tenemos mucho trabajo que hacer sólo p a r a definir esta cosa, pero me gusq u e comenzaron a pensar acerca de cómo enfocala parte del software d e este proyecto. Parece que en el p a s a d o hemos estado muy aesorganizados en nuestro enfoque hacia el software. Ed: N o lo sé, Doug. Siempre sacamos el producto. D o u g : Es cierto, pero con muchos sacrificios, y este proyecto parece mayor y más complejo q u e cualquier cosa que hayamos hecho antes. - a m i e : N o p a r e c e ser tan duro, pero estoy de a c u e r d o . . .

D o u g : Entonces, me parece q u e un modelo lineal no es p a r a nosotros... supone que tenemos todos los requisitos frente a nosotros y, conociendo este lugar, eso no es probable. V i n o d : Sí, y ese modelo DRA suena muy orientado a la IT... Tal vez sea bueno p a r a construir un sistema d e control d e inventarios o a l g o así, pero no e s correcto p a r a HogarSeguro. D o u g : Estoy d e acuerdo. Ed: Ese enfoque d e construcción d e prototipos me pareTM ce bueno. De cualquier manera se p a r e c e mucho a lo que hacemos aquí.

PDF Editor •xss'ro enfoque ac¡ hoc en los proyectos p a s a d o s no fun-

: o n a r á aquí, en particular si tenemos un tiempo d e éntrel e n u y restringido.

V i n o d : Ése es el problema. Me preocupa que no nos proporcione la suficiente estructura. D o u g : N o hay d e q u é preocuparse. Tenemos muchas

D o u g ( s o n r i e n d o ) : Quiero q u e nuestro enfoque sea

otras opciones, y quiero q u e seleccionen lo mejor p a r a el

. - poco más profesional. Asistí a un curso corto la semo-

equipo y el proyecto.

58

PARTE UNO


3.4.2 El modelo en espiral El modelo

en espiral, q u e B o e h m [BOE88] p r o p u s o o r i g i n a l m e n t e , e s u n m o d e l o de

p r o c e s o d e s o f t w a r e evolutivo q u e c o n j u g a la n a t u r a l e z a iterativa d e la c o n s t r u c c i ó n d e p r o t o t i p o s c o n l o s a s p e c t o s c o n t r o l a d o s y s i s t e m á t i c o s del m o d e l o e n c a s c a d a . P r o p o r c i o n a el m a t e r i a l p a r a el d e s a r r o l l o r á p i d o d e v e r s i o n e s i n c r e m e n t a l e s del s o f t w a r e . B o e h m [BOEOlj d e s c r i b e e s t e m o d e l o de la s i g u i e n t e m a n e r a : El m o d e l o d e d e s a r r o l l o en espiral e s u n g e n e r a d o r del m o d e l o d e p r o c e s o g u i a d o p o r el riesgo q u e s e e m p l e a p a r a c o n d u c i r s i s t e m a s i n t e n s i v o s d e i n g e n i e r í a del s o f t w a r e c o n c u r r e n t e y c o n m ú l t i p l e s u s u a r i o s . Tiene d o s c a r a c t e r í s t i c a s d i s t i n t i v a s p r i n c i p a l e s . U n a d e e l l a s e s u n e n f o q u e cíclico p a r a el c r e c i m i e n t o i n c r e m e n t a l del g r a d o d e d e f i n i c i ó n e i m p l e m e n t a c i ó n d e u n s i s t e m a , m i e n t r a s d i s m i n u y e su g r a d o d e r i e s g o . La o t r a e s u n c o n j u n t o d e p u n t o s d e fijación p a r a a s e g u r a r el c o m p r o m i s o del u s u a r i o c o n s o l u c i o n e s d e s i s t e m a q u e s e a n factibles y m u t u a m e n t e s a t i s f a c t o r i a s .

C u a n d o s e a p l i c a el m o d e l o e n espiral, el s o f t w a r e s e d e s a r r o l l a e n u n a serie de CKJEVVE

e n t r e g a s e v o l u t i v a s . D u r a n t e las p r i m e r a s i t e r a c i o n e s , la e n t r e g a tal v e z s e a un d o c u -

El m o d e l o e n espiral s e puede adoptar y

m e n t o del m o d e l o o u n p r o t o t i p o . D u r a n t e las ú l t i m a s i t e r a c i o n e s se p r o d u c e n ver-

aplicarlo o t r a v é s del ciclo d e vida c o m p l e t o d e u n o aplicación,

s i o n e s c a d a v e z m á s c o m p l e t a s del s i s t e m a d e s a r r o l l a d o . u n p r o c e s o en espiral s e divide e n un c o n j u n t o d e a c t i v i d a d e s del m a r c o d e trab a j o q u e d e f i n e el e q u i p o d e ingeniería del s o f t w a r e . Para p r o p ó s i t o s ilustrativos s e

d e s d e el desarrollo del c o n c e p t o h a s t a el

a p r o v e c h a n las a c t i v i d a d e s g e n é r i c a s del m a r c o d e t r a b a j o e x p u e s t a s p á g i n a s a t r á s . 5

mantenimiento.

e n espiral q u e s e p r e s e n t a e n la figura 3.5. C u a n d o c o m i e n z a e s t e p r o c e s o e v o l u t i v o

C a d a u n a de las a c t i v i d a d e s del m a r c o de t r a b a j o r e p r e s e n t a u n s e g m e n t o d e la ruta el e q u i p o d e s o f t w a r e realiza a c t i v i d a d e s i m p l i c a d a s e n u n circuito a l r e d e d o r d e la

Planeación estimación itinerario análisis de riesgos

Un modelo en espiral

típico.

Modelado análisis diseño

TM

PDF Editor prueba

5

El modelo en espiral expuesto en esta sección e s una variación del modelo q u e propuso Boehm. Para

m á s información sobre el m o d e l o en espiral original, véase [BOE88]. En |BOE98] se p u e d e e n c o n trar una exposición m á s reciente del modelo en espiral d e Boehm.

CAPÍTULO 3


59

espiral que tiene una dirección en el sentido del movimiento de las manecillas del reloj, y que se inicia desde el centro. El riesgo (capítulo 25) es un factor considerado en cada revolución. Los puntos de fijación —una combinación de productos de trabajo y condiciones incluidas a lo largo de la ruta de la espiral— se consideran para cada paso evolutivo. El primer circuito alrededor de la espiral quizá genere el desarrollo de una especificación del producto; los pasos subsecuentes alrededor de la espiral se pueden aprovechar para desarrollar un prototipo y después, en forma progresiva, versiones m á s elaboradas del software. Cada paso a través de la región de planeación resulta en ajustes al plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentación derivada de la relación con el cliente después de la entrega. Además, el administrador del proyecto ajusta el número de iteraciones planeado que se requiere para completar el software. A diferencia de otros modelos de proceso que terminan cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Por lo tanto, el primer circuito alrededor de la espiral podria representar un "proyecto de desarrollo del concepto", el cual se inicia en el centro de la espiral y continúa por múltiples iteraciones 6 hasta que el desarrollo del concepto esté completo. Si el concepto se desarrollará en un producto real, el proceso continúa en la siguiente fase de la espiral y comienza un "proyecto de desarrollo de un producto nuevo". El nuevo producto evolucionará a través de un número de iteraciones alrededor de la espiral. Después, un circuito alrededor de la espiral se podría emplear para representar un "proyecto de mejoramiento del producto". En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativa hasta que el software se retira. En ocasiones el proceso está inactivo, pero siempre que se inicie un cambio el proceso comienza en el punto de entrada aprobado (por ejemplo, mejoramiento del producto). El modelo en espiral es un enfoque realista para el desarrollo de software y de sistemas a gran escala. Como el software evoluciona conforme avanza el proceso, el desarrollador y el cliente entienden y reaccionan de mejor manera ante los riesgos en cada etapa evolutiva. El modelo en espiral emplea la construcción de prototipos como un mecanismo encaminado a reducir riesgos pero, en forma más importante, permite al desarrollador la aplicación del enfoque de la construcción de prototipos en cualquier etapa evolutiva del producto. Mantiene el enfoque sistemático de los pasos que sugiere el ciclo de vida clásico, pero lo incorpora al marco de trabajo iteTM rativo que refleja de forma más verídica el m u n d o real. El modelo en espiral exige una consideración directa de los riesgos técnicos en todas las etapas del proyecto y, si se aplica en forma apropiada, debe reducir los riesgos antes de que se vuelvan problemáticos.

PDF Editor 6

Las flechas que apuntan hacia dentro a lo largo del eje que separa la región de despliegue de la de :omunicación indican una posibilidad de iteración local a lo largo de la misma ruta de la espiral.

60

PARTE UNO


Así c o m o otros paradigmas, el modelo e n espiral no e s una p a n a c e a . Es difícil convencer a los clientes (en particular en situaciones b a j o contrato) de que el enfoque evolutivo es controlable, ya que se requiere una habilidad considerable para evaluar el riesgo y se confia e n dicha habilidad para obtener el éxito. Si un riesgo importante n o se descubre y administra, sin duda surgirán problemas.

3.4.3

El modelo de desarrollo concurrente

El modelo de desarrollo concurrente,

llamado a l g u n a s veces ingeniería concurrente, se

representa e n forma esquemática c o m o u n a serie de actividades del m a r c o de trabajo, acciones y tareas de la ingeniería del s o f t w a r e y sus e s t a d o s asociados. Por ejemplo, la actividad de modelado, definida para el modelo e n espiral, se lleva a c a b o al invocar las acciones siguientes: construcción de prototipos o m o d e l a d o y especificación del análisis y diseño. 7 En la figura 3.6 se proporciona un e s q u e m a de u n a tarea de ingeniería de software (cOHSEJOÂ menudo, el modelo concurrente es más apropiado para proyectos de ingeniería de sistemas (capítulo 6), donde están implicados diferentes equipos de ingeniería.

relacionada con la actividad de m o d e l a d o para el modelo de proceso concurrente. La actividad —modelado— p u e d e estar e n a l g u n o de los estados 8 d e s t a c a d o s m e n cionados a n t e s en cualquier m o m e n t o dado. De forma similar, otras actividades o tareas (por ejemplo, la comunicación y la construcción) se representan de u n a m a n e ra análoga. Todas las actividades existen de forma concurrente, p e r o se e n c u e n t r a n e n diferentes estados. Por ejemplo, al principio del proyecto la actividad de comunicación (no s e muestra e n la figura) ha c o m p l e t a d o su primera iteración y existe en el estado de e n e s p e r a d e c a m b i o s . La actividad de modelado que existió en el estado n i n g u n o mientras se realizaba la comunicación inicial, ahora realiza una transición al e s t a d o e n desarrollo. Sin embargo, si el cliente indica cambios en los requisitos, la actividad de modelado

se m u e v e del e s t a d o e n d e s a r r o l l o al e s t a d o de e n

espera de cambios. El modelo de proceso concurrente define una serie de eventos que dispararán transiciones de e s t a d o a e s t a d o para cada u n a de las actividades, acciones o t a r e a s de la ingeniería del software. Por ejemplo, durante los primeros e s t a d o s del diseño (una acción de la ingeniería del s o f t w a r e que ocurre en el curso de la actividad de modelación) no se detecta una inconsistencia en el m o d e l o del análisis. Esto g e n e ra el evento corrección del análisis del modelo, el cual disparará la creación del a n á lisis d e s d e el e s t a d o r e a l i z a d o hasta el e s t a d o de e n e s p e r a d e c a m b i o s . El m o d e l o de proceso c o n c u r r e n t e se aplica a todos los tipos de desarrollo de soft-

TM

w a r e y proporciona una visión exacta del e s t a d o actual de un proyecto. En lugar de confinar las actividades, acciones y tareas de la ingeniería del s o f t w a r e a una

PDF Editor

secuencia de eventos, define una red de actividades. Cada actividad, acción o tarea e n la red existe de m a n e r a simultánea con o t r a s actividades, acciones o tareas. Los

7

Se debe notar que el análisis y el diseño son acciones complejas que requieren un debate sustancial. La parte 2 de este libro considera estos tópicos en forma detallada.

8

Un estado es alguna forma de comportamiento observable desde el exterior.

CAPÍTULO 3

61

MODELOS PRESCRIPTiVOS DE PROCESO

linguno

Actividad d e m o d e l a d o

R e p r e s e n t a el e s t a d o

Bajo desarrollo

d e u n a a c t i v i d a d o t o r e a d e la ingeniería d e software

en e s p e r a de cambios

En modificación

revisión

e v e n t o s g e n e r a d o s e n u n p u n t o de la red del p r o c e s o disparan transiciones entre los estados.

3.4.4

Un comentario íinal sobre los procesos evolutivos

Ya se ha detectado que al s o f t w a r e de c o m p u t a d o r a s m o d e r n o lo caracteriza el c a m bio continuo, los tiempos de e n t r e g a muy reducidos, y u n a necesidad intensa de satisfacer al cliente/usuario. En m u c h o s casos, el tiempo de llegada al m e r c a d o e s el requisito de gestión m á s importante. Si se pierde una v e n ta na del mercado, el m i s m o proyecto de s o f t w a r e p u e d e perder su significado. 9 "liego basto aquí, y sólo el mañana guía mi camino." D a v e M a t t h e w s Band

TM Los modelos evolutivos de p r o c e s o se concibieron para a b o c a r s e a e s t o s aspectos y, a d e m á s , c o m o m o d e l o s de proceso de clase general. Estos m o d e l o s también

PDF Editor

tienen debilidades, las cuales r e s u m e n Nogueira y s u s colegas [NOGOO]:

9

Sin embargo, es importante notar que llegar en primer lugar a un mercado no garantiza el éxito. De hecho, muchos productos de software muy exitosos han sido los segundos o hasta los terceros en llegar al mercado (al aprender errores de los antecesores).

62

PARTE UNO


A pesar de los incuestionables beneficios de los procesos evolutivos de software, se tienen algunas dificultades con este tipo de procesos. La primera dificultad es q u e la construcción de prototipos |y otros procesos evolutivos m á s elaborados] implican un problema para la planeación del proyecto debido al número incierto de ciclos requeridos para construir el producto. La mayoría d e las técnicas de gestión y estimación de proyectos se b a s a en configuraciones lineales de las actividades, por lo que éstas n o s e ajustan por completo. La s e g u n d a dificultad es que los procesos evolutivos de software n o establecen la velocidad máxima de la evolución. Si las evoluciones s u c e d e n d e m a s i a d o rápido, sin un periodo de relajación, existe la certidumbre d e que el proceso caerá en el caos. Por otro lado, si la velocidad es d e m a s i a d o lenta, se podría afectar la productividad. Una tercera dificultad es que los procesos d e software se deben enfocar en la flexibilidad y extensibilidad en vez d e en la alta calidad. Esta afirmación s u e n a atemorizante. Sin embargo, se debe priorizar la velocidad del desarrollo sobre los cero defectos. Si el desarrollo se extiende p a r a alcanzar u n a alta calidad, se produciría un retraso e n la entrega del producto, la cual se haría c u a n d o el nicho d e oportunidad ya haya desaparecido. Este cambio de paradigma lo impone la competencia en el borde del caos.

En efecto, un proceso de s o f t w a r e que se enfoca en la flexibilidad y la velocidad del desarrollo por encima de la alta calidad s u e n a atemorizante. Aun así, esta idea la ha propuesto cierto n ú m e r o de r e s p e ta d os expertos en la ingeniería del s o f t w a r e (por ejemplo, [YOU95], [BAC97]). El propósito de los modelos evolutivos es desarrollar s o f t w a r e de alta calidad 1 0 de una m a n e r a iterativa o incremental. Sin embargo, e s posible aplicar u n proceso evolutivo para d e s t a c a r la flexibilidad, extensibilidad y velocidad del desarrollo. El reto para los equipos de s o f t w a r e y sus dirigentes es establecer u n b a l a n c e apropiado entre estos parámetros críticos del proyecto y el producto, y el producto y la satisfacción del cliente (el árbitro final de la calidad del software). HOGARSEGURO

Selección de un modelo de proceso. Segunda parte El e s c e n a r i o : Sala de reuniones para el grupo de ingeniería del software en CPI Corporation, una compañía que fabrica productos de consumo para uso doméstico y comercial. Los a c t o r e s : Lee Warren, gerente d e ingeniería; Doug Miller, gerente de ingeniería del software; Ed y Vinod, miembros del equipo de ingeniería del software.

La conversación: (Doug describe las opciones d e procesos evolutivos)

Ed: Ahora veo algo que me gusta. Un enfoque incremental tiene sentido y en realidad me gusta el flujo de ese modelo en espiral. Eso lo hace realista. V i n o d : Estoy de acuerdo. Entregamos un incremento, TM aprendemos d e la retroalimentación del cliente, replaneamos, y después entregamos afro incremento. También se ajusta a la naturaleza del producto. Podemos tener algo en el mercado muy rápido y después agregar funcionalidad con cada versión. Es decir, con cada incremento.

PDF Editor

10 En este contexto, la calidad del software se define con mucha amplitud para abarcar no sólo la satisfacción del cliente, sino también una variedad de criterios técnicos tratados en el capítulo 26.

CAPÍTULO 3


1*1 ir : ñuto, Doug, ¿dijeron que d c o n con cada vuelta alrededor de la o es muy bueno, necesitamos un plan, un efaemos apegamos a él.

• f i

vMonFlOS

63

Ooug; lee, ese es un pensamiento d e la vieja escuela, Como ¿Jijo Ed, debemos mantenerlo realista. Digo que es mejor mover el plan a medida que aprendemos más y conforme solicitan los cambios.

E S P E C I A L I Z A D O S T1B P R O C E S O

Los modelos especializados de proceso adoptan muchas de las características de uno o m á s de los modelos convencionales presentados en las secciones anteriores. Sin embargo, los modelos especializados tienden a aplicarse cuando se ha elegido un enfoque de ingeniería del software definido de una manera muy estrecha."

3.5.1

Desarrollo b a s a d o en componentes

Los nuevos componentes de software comerciales (NCSC), desarrollados por vendedores que los ofrecen como productos, se pueden emplear cuando el software está en proceso de construcción. Estos componentes proporcionan funcionalidad dirigida con interfaces bien definidas que permiten que el componente se integre en el software. El modelo de desarrollo basado en componentes (DBC) (capítulo 30) incorpora muchas de las características del modelo en espiral. Es evolutivo por naturaleza [NIE92] y exige un enfoque iterativo para la creación del software. Sin embargo, el modelo configura aplicaciones a partir de componentes de software empaquetados en forma previa. Las actividades de modelado y construcción comienzan con la identificación de los componentes candidatos. Estos componentes se pueden diseñar como módulos de software convencionales o como clases o paquetes de clases orientados a objetos. 12 Sin importar la tecnología que se aplique en la creación de los componentes, el modelo de desarrollo basado en componentes incorpora los siguientes pasos (implementados mediante un enfoque evolutivo): •

Los productos basados en componentes disponibles se investigan y evalúan para el dominio de aplicación en cuestión.

•

Se consideran los aspectos de integración de componentes.

•

Se diseña una arquitectura de software (capítulo 10) para adaptar los compoTM nentes.

PDF Editor

11 En algunos casos estos modelos especializados de proceso se pueden describir de mejor manera como una colección de técnicas o una metodología para alcanzar una meta especifica del desarrollo del software. Sin embargo, éstas implican un proceso. 12 La tecnología orientada a objetos se trata a lo largo de la parte 2 de este libro. En este contexto, una cíase encapsu/a una sene de datos y ¡os procedimientos que procesan dichos datos. Un paquete de clases es una colección de clases relacionadas que trabajan juntas para alcanzar algún resultado final.

64

PARTE UNO

•


Los c o m p o n e n t e s (capítulo 11) se integran e n la arquitectura.

•

Se realizan p r u e b a s detalladas (capítulo 11) para a s e g u r a r una funcionalidad apropiada. El m o d e l o de desarrollo b a s a d o e n c o m p o n e n t e s c o n d u c e a la reutilización del

software, la cual proporciona beneficios a los ingenieros de software. Con b a s e en estudios de reutilización, QSM Associates, Inc. informa que el e n s a m b l a j e de c o m p o n e n t e s c o n d u c e a u n a reducción de 70 por ciento del ciclo de desarrollo; 84 por ciento del c o s t o del proyecto y un índice de productividad de 26.2, c o m p a r a d o con una n o r m a de la industria de 16.9 [YOU94], A p e s a r de que e s t o s resultados están en función de la robustez de la biblioteca de c o m p o n e n t e s , no hay duda de que el modelo de desarrollo b a s a d o en c o m p o n e n t e s proporciona v e n t a j a s significativas para los ingenieros de software.

3.5.2

El modelo de métodos formales

El m o d e l o de métodos formales

(capítulo 28) c o m p r e n d e un c o n j u n t o de actividades

que c o n d u c e n a la especificación matemática del s o f t w a r e de c o m p u t a d o r a . Los m é t o d o s formales permiten que un ingeniero de s o f t w a r e especifique, desarrolle y verifique un sistema b a s a d o en c o m p u t a d o r a al aplicar u n a notación m a t e m á t i c a rigurosa. Algunas organizaciones de desarrollo del s o f t w a r e aplican en la actualidad una variación de este enfoque, llamado ingeniería del software de sala limpia [M1L87, DYE92], Este m o d e l o se explica e n el capítulo 29. "Es más fácil escribir un progromo incorrecto que entender uno correcto." Alan Perlis Cuando se utilizan m é t o d o s formales durante el desarrollo, é s t o s proporcionan un m e c a n i s m o para eliminar m u c h o s de los p r o b l e m a s difíciles de superar con otros p a r a d i g m a s de la ingeniería del software. La ambigüedad, el e s t a d o incompleto y la inconsistencia se d e s c u b r e n y corrigen con mayor facilidad —no m e d i a n t e u n a revisión ad hoc, sino a través de la aplicación de un análisis matemático—. Cuando los m é t o d o s formales se utilizan d u r a n t e el diseño sirven c o m o b a s e para la verificación de p r o g r a m a s y, por consiguiente, permiten que el ingeniero de s o f t w a r e descubra y corrija errores que de otra m a n e r a podrían n o haberse detectado.

TM de m é t o d o s forA pesar de que a ú n no existe un e n f o q u e establecido, los modelos m a l e s ofrecen la p r o m e s a de un s o f t w a r e libre de defectos. Sin embargo, s e h a m e n cionado u n a gran preocupación acerca de su aplicabilidad e n su e n t o r n o de gestión:

PDF Editor ¿Si los méto* dos formales pueden demostrar la corrección del software, por qué no se utiliza en forma extensa?

•

En la actualidad, el desarrollo de modelos formales es muy caro y c o n s u m e

m u c h o tiempo.

•

Se requiere una capacitación detallada, debido a que p o c o s responsables del

desarrollo de software c u e n t a n con los a n t e c e d e n t e s necesarios para aplicar m é t o d o s formales.

CAPITULO 3

•

MODELOS PEESCRIPnVCS DE PROCESO

65

Es difícil la utilización de e s t o s modelos c o m o un m e c a n i s m o de comunicación con clientes que no tienen m u c h o s conocimientos técnicos.

No obstante, tal vez el enfoque a través de métodos formales haya ganado adeptos entre los desarrolladores de software que deben construir sistemas de alta seguridad (por ejemplo, en los campos de la aeronáutica y de los dispositivos médicos), y entre los desarrolladores que padecen severas penurias económicas cuando aparecen errores en el software.

3.5.3

Desarrollo del software orientado a aspectos

Sin importar el proceso de s o f t w a r e que se elija, los constructores de software c o m plejo implementan de m a n e r a invariable u n conjunto específico de características, funciones y contenido de información. Estas características específicas del software se modelan c o m o c o m p o n e n t e s (por ejemplo, clases orientadas a objetos) y después se construyen dentro del contexto de u n a arquitectura de sistema. Conforme los sistem a s b a s a d o s en c o m p u t a d o r a se vuelven m á s elaborados (y complejos), ciertos "intereses" —propiedades requeridas p a r a el cliente o á r e a s de interés t é c n i c o a b a r c a n toda la arquitectura. Algunos intereses son propiedades de alto nivel de un sistema (por ejemplo, seguridad, falta de tolerancia). Otros intereses afectan las f u n ciones (como la aplicación de reglas de negocios), mientras que otros s o n sistémi eos (como la sincronización de t a r e a s o la gestión de memoria). Cuando los intereses se relacionan con múltiples funciones, características e información del sistema, con frecuencia se d e n o m i n a n intereses generales. Los requerimientos de aspectos definen e s t o s intereses generales que ejercen un impacto a través d e la arquitectura del software. El desarrollo de software orientado a aspectos (DSOA), referido con frecuencia c o m o programación orientada a aspectos (POA), es un p a r a d i g m a de la ingeniería del s o f t w a r e relativamente nuevo que proporciona un proceso y enfoque metodológico para definir, especificar, diseñar y construir aspeetos —"mecanismos m á s allá de subrutinas y legados para localizar la expresión de un interés general" [ELRO1 ]. Grundy [GRU02] explica con mayor profundidad los aspectos en el contexto de lo que él llama ingeniería de componentes orientada a aspectos [ICOA]: La ICOA utiliza un concepto de capas horizontales a través d e c o m p o n e n t e s de s o f t w a r e

CÚXVE

d e s c o m p u e s t o s en forma vertical, llamados "aspectos", para caracterizar propiedades generales d e los componentes, los cuales pueden ser funcionales y no funcionales. Por lo TM general, los aspectos sistémicos incluyen interfases con el usuario, trabajo en colabo-

k s intereses los cuales nidias

ración, distribución, persistencia, gestión de la memoria, p r o c e s a m i e n t o de transiciones,

PDF Editor

seguridad, integridad y otros. Los c o m p o n e n t e s p u e d e n proporcionar o requerir u n o o m á s "detalles d e aspecto" relacionados c o n un a s p e c t o particular, c o m o un m e c a n i s m o d e visión, a c c e s o extensible y tipo de interfase (aspectos d e la interfase con el usuario); generación, transportación y recepción de e v e n t o s (aspectos de distribución); almace-

del

n a m i e n t o / r e c u p e r a c i ó n e indización d e datos (aspectos d e persistencia); autentificación, codificación y derechos d e a c c e s o (aspectos de seguridad); atomicidad d e la transacción,

66

PARTE UNO


control de concurrencia y control del transporte (aspectos d e transacción), y así sucesivam e n t e . Cada detalle d e a s p e c t o tiene u n a serie d e propiedades en relación con características personales y n o funcionales del detalle.

Hasta a h o r a no se ha concretado un proceso orientado a aspectos diferente. Sin embargo, es probable que tal proceso adopte características de los modelos de proceso en espiral y concurrente (secciones 3.4.2 y 3.4.3). La naturaleza evolutiva del modelo e n espiral e s apropiada c u a n d o se identifican y construyen los aspectos. La naturaleza paralela del desarrollo concurrente e s esencial porque los aspectos s e desarrollan de m a n e r a independiente de los c o m p o n e n t e s del software localizados y, a u n así, los aspectos tienen un impacto directo sobre estos componentes. Por lo tanto, resulta esencial implementar u n a comunicación asincrónica entre las activid a d e s del proceso de software aplicadas al desarrollo y la construcción de aspectos y componentes. Si se desea conocer u n a exposición detallada del desarrollo del software orientado a aspectos, se recomienda remitirse a libros dedicados a esta materia. El lector interesado puede consultar [GRA03], [KIS02] o (ELRO1 ].


Gestión del proceso Objetivo: Ayudar en la definición, ejecución y gestión de los modelos prescriptivos del proceso. M e c á n i c a : Las herramientas de gestión del proceso permiten que una organización o equipo de software defina un modelo completo de proceso del software (actividades del marco de trabajo, tareas de aseguramiento de la calidad, puntos de verificación, fundamentos y productos de trabajo). Además, las herramientas proporcionan una guía mientras los ingenieros de software hacen el trabajo técnico y una plantilla para los gerentes, que deben rastrear y controlar el proceso de software. Herramientas representativas13 La GDPA, una serie de herramientas para la definición del proceso de investigación, desarrollada en la

Universidad de Bremen en Alemania (www.lnformatlk.uni-bremen.de/uniform/gdpa/ home.htm),proporciona un amplio espectro d e funciones para el modelado y la gestión del proceso. SpeeDev, desarrollado por Spee Dev Corporation (www.speedev.com), Incluye una serie d e herramientas para la definición del proceso, gestión de los requisitos, resolución de características, planeación del proyecto y seguimiento del mismo. Step Gate Process, desarrollado por Objexis (www.objexis.com), incluye muchas herramientas que ayudan en la automatización del flujo de trabajo. En el sitio de Internet http://205.252.62.38/English/ D-ProcessNotation.htm es posible encontrar una valiosa exposición sobre los métodos y la TM notación que se puede usar para definir y describir un modelo completo del proceso.

PDF Editor

13 Las herramientas mencionadas aquí representan un muestreo de esta categoría. En la mayoría de los casos los nombres son marcas registradas de sus respectivos desarrolladores..

En su libro fundamental sobre el proceso unificado, Ivar Jacobson, Grady Booch y James Rumbaugh [JAC99] exponen la necesidad de un proceso d e software "guiado por los casos de uso, de arquitectura céntrica, iterativo e incremental". Estos autores establecen: En la actualidad la t e n d e n c i a e n el s o f t w a r e s e e n c a m i n a a s i s t e m a s m a y o r e s y c o m p l e jos. Eso s e d e b e en p a r t e al h e c h o d e q u e las c o m p u t a d o r a s s e volvían m á s p o d e r o s a s c a d a a ñ o , lo q u e a l e n t a b a q u e los u s u a r i o s e s p e r a r a n m á s d e ellas. Esta t e n d e n c i a también la impulsó el u s o e x p a n d i d o d e Internet p a r a el i n t e r c a m b i o de t o d o tipo de información. Nuestro a p e t i t o por un s o f t w a r e c a d a vez m á s c o m p l e j o c r e c e e n la medida e n la q u e a p r e n d e m o s c ó m o p u e d e m e j o r a r s e u n p r o d u c t o d e s d e q u e sale u n o h a s t a q u e llega el otro. N e c e s i t a m o s un s o f t w a r e q u e s e a d a p t e m e j o r a n u e s t r a s n e c e s i d a d e s , p e r o que, a su vez, h a g a el s o f t w a r e m á s complejo. En r e s u m e n , q u e r e m o s más.

De alguna manera, el proceso unificado (PU) es un intento encaminado a reunir los mejores rasgos y características de modelos de procesos de software, pero los caracteriza de manera que implementa muchos de los mejores principios del desarrollo ágil de software (capítulo 4). El proceso unificado reconoce la importancia de la comunicación con el cliente y los métodos encaminados a describir el punto de vista del cliente con respecto a un sistema (por ejemplo, el caso de uso' 4 ). El PU enfatiza el importante papel de la arquitectura de software, y "ayuda al arquitecto a enfocarse en las metas correctas, como el entendimiento, el ajuste a los cambios futuros y la reutilización" [JAC99]. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo del software moderno. En esta sección se presenta una visión general de los elementos clave del proces o unificado. En la parte 2 de este texto se analizan los métodos que pueblan el proceso y las técnicas y notaciones complementarias del UML,'° las cuales se requieren al aplicar el proceso unificado en el trabajo real d e la ingeniería del software.

3.6.1 Una breve historia Durante la década de 1980 y al principio de la década siguiente, los métodos y lenguajes de programación orientados a objetos (OO)16 obtuvieron una amplia difusión entre la comunidad de la ingeniería del software. Durante el mismo periodo se pro-

TM 14 Un caso de uso (capítulos 7 y 8) e s un contexto narrativo o plantilla que describe una característica o función del sistema desde el punto de vista del usuario. El caso de uso lo escribe el usuario y sirve

PDF Editor como una base para la creación de un modelo de análisis más completo.

15 El UML (Jnified Modeling Language) se ha convertido en la notación más utilizada para el modelado del análisis y el diseño. Representa una unión entre tres importantes notaciones orientadas a objetos.

16 Si el lector no s e encuentra familiarizado con los métodos orientados a objetos, e n los capítulos 8 y 9 se presenta una breve revisión general de ellos. Para una presentación más detallada véase [REE02] (STIO1 ] o (FOW99].

68

PARTE UNO


puso una amplia variedad de análisis y diseño orientados a objetos (AOO y DOO) y se introdujo un modelo de proceso orientado a objetos de propósito general (similar a los modelos evolutivos presentados en este capítulo). Al igual que la mayoría de los paradigmas "nuevos" para la ingeniería del software, los seguidores de cada uno de los métodos de AOO y DOO argumentaban acerca de cuál d e ellos era el mejor, pero ningún método o lenguaje dominó la escena de la ingeniería del software. Al principio de la década de 1990, James Rumbaugh [RUM91], Grady Booch [B0094] e Ivar Jacobson [JAC92] comenzaron a trabajar en un "método unificado" que combinaría las mejores características de cada uno de sus métodos individuales y adoptaría características adicionales que propusieran otros expertos (por ejemplo, [WIR90]) en el campo OO. El resultado fue el lenguaje de modelado unificado (UML, por s u s siglas en inglés) —que contiene una notación robusta para el modelado y el desarrollo de sistemas OO—. Para 1997, el UML se convirtió en un estándar de la industria para el desarrollo de software orientado a objetos. Al mismo tiempo, Rational Corporation y otras firmas desarrollaron herramientas automáticas para apoyar los métodos del UML. El UML proporciona la tecnología necesaria para apoyar la práctica de la ingeniería del software orientada a objetos, pero no provee el marco de trabajo del proceso que guíe a los equipos en la aplicación de la tecnología. En los años siguientes, Jacobson, Rumbaugh y Booch desarrollaron el proceso unificado, un marco de trabajo para la ingeniería del software orientada a objetos, mediante la utilización del UML. En la actualidad, el proceso unificado y el UML se emplean de forma amplia en proyectos OO de todos los tipos. El modelo iterativo e incremental que propone el PU puede y debe adaptarse para satisfacer necesidades de proyecto específicas. Como consecuencia de la aplicación del UML se puede producir un arreglo de productos de trabajo (por ejemplo, modelos y documentos). Sin embargo, éstos los reducen los ingenieros de software para lograr que el desarrollo sea más ágil y reactivo ante el cambio. Referencia Web

En www. rationol.com/ products/rup/ whitepapers.jsp s pueden encontrar documentos útiles sobre el PIJ.

3.6.2

Fases del proceso uniíicado 17

Se han analizado cinco actividades genéricas del marco de trabajo y se ha explicado que éstas se pueden aplicar para describir cualquier modelo de proceso del software. El proceso unificado no es la excepción. En la figura 3.7 se muestran las "fases" del proceso unificado (PU) y se relacionan con las actividades TM genéricas que se trataron en el capítulo 2. La fase de i n i c i o del PU abarca la comunicación con el cliente y las actividades de planeación. Al colaborar con los clientes y usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el

PDF Editor

17 Algunas veces el proceso unificado se llama proceso unificado racional (PUR) después de que lo respaldara la Rational Corporation, un contribuyente importante en el desarrollo y refinamiento del proceso y un constructor de ambientes completos (herramientas y tecnología).

CAPITULO 3

69

MODELOS PRESCR1PTIVOS DE PROCESO

sistema, y se desarrolla un plan para la naturaleza iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a través de un conjunto preliminar de casos de uso que describen cuáles características y funciones son deseables para cada clase importante de usuarios. En general, un caso de uso describe una secuencia de acciones que desarrolla un actor (por ejemplo, una persona, una máquina, otro sistema) cuando éste interactúa con el software. Los casos de uso ayudan a identificar el ámbito del proyecto y proporcionan una base para la planeación de éste. En este punto, la arquitectura n o es más que un esquema tentativo de los subsistemas más importantes y de las funciones y características que los forman. Después, la arquitectura se refinará y expandirá en un conjunto de modelos que representarán visiones diferentes del sistema. La planeación identifica recursos, evalúa los riesgos importantes, define un itinerario y establece una base para las fases que se aplicarán conforme se desarrolle el incremento del software. La fase de elaboración abarca la comunicación con el cliente y las actividades de modelado del modelo genérico del proceso (figura 3.7). La elaboración refina y expande los casos de uso preliminares que se desarrollaron c o m o una parte de la fase de inicio; además, expande la representación arquitectónica para incluir cinco visiones diferentes del software: el modelo de caso de uso, el modelo de análisis, el modelo de diseño, el modelo de implementación y el modelo de despliegue. En algunos casos, la elaboración crea una "línea de base arquitectónica ejecutable" [ARL02] que representa un sistema ejecutable en su "primer corte". 18 La línea de base arquitectónica demuestra la viabilidad de la arquitectura, pero n o proporciona todas las

TM

PDF Editor \

Producción

18 Es importante destacar que la directriz arquitectónica no es un prototipo que se deseche (sección 3.4.1). En lugar de ello la directriz se aprovecha durante la siguiente fase del PU.

70

PARTE UNO


características y funciones necesarias para utilizar el sistema. Además, el plan se revisa de manera cuidadosa al término de la fase de elaboración para asegurar que el ámbito, los riesgos y los datos entregados aún son razonables. Las modificaciones al plan se deben hacer en este momento. La fase de construcción del PU es idéntica a la actividad de construcción definida para el proceso genérico del software. Si se utiliza el modelo arquitectónico como entrada, la fase de construcción desarrolla o adquiere los componentes del software que harán que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de análisis y diseño iniciados durante la fase de elaboración se completen para reflejar la versión final del incremento del software. Todas las características y funciones necesarias y requeridas del incremento del software (por ejemplo, la entrega) se implementan en código fuente. Conforme los componentes están en proceso de implementación, se diseñan y ejecutan pruebas de unidad para cada uno de ellos. Además, se realizan las actividades de integración (ensamblaje de componentes y pruebas de integración). Los casos de uso se utilizan para derivar un conjunto de pruebas de aceptación que se ejecutan antes del inicio de la siguiente fase del PU. La fase de transición del PU abarca las últimas etapas de la actividad genérica de construcción y la primera parte de la actividad genérica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta, 19 y la retroalimentación del usuario reporta tanto defectos como cambios necesarios. Además, el equipo de software crea la información de soporte necesaria (por ejemplo, manuales del usuario, guías de resolución de problemas, procedimientos de instalación) para el lanzamiento. Al final de la fase de transición, el incremento de software se convierte en un lanzamiento de software utilizable. Referencia Web

En www.

La fase de producción del PU coincide con la actividad de despliegue del proceso genérico. Durante esta fase se monitorea el uso subsiguiente del software, se proP o r c i o n a e l soporte para el ambiente operativo (infraestructura), y se reciben y evalúan los informes de defectos y los requerimientos de cambios.

«

Es probable que mientras se realizan las fases de construcción, transición y producción ya se hayan iniciado los trabajos para el siguiente incremento del software. Esto significa que las cinco fases del PU n o suceden en una secuencia, sino en una concurrencia por etapas. A lo largo de las fases del PU se distribuye un flujo de trabajo TMde ingeniería del software. En el contexto del PU, un flujo de trabajo es análogo a un conjunto de tareas (definido en el capítulo 2). Esto es, un flujo de trabajo identifica las tareas necesarias para completar una acción importante de ingeniería del software y los productos de

PDF Editor

19 En la prueba beta, una acción de prueba controlada (capítulo 13), el software lo utilizan usuarios finales reales, con la intención de descubrir defectos y deficiencias. Se establece un esquema de informe de defectos y deficiencias de manera formal, y el equipo de software evalúa la retroalimentación.

CAPÍTULO 3


71

trabajo que se producen como consecuencia de la realización exitosa de tareas. Se debe destacar que no todas las tareas identificadas para un flujo de trabajo del PU se realizan para cualquier proyecto de software. El equipo debe adaptar el proceso (acciones, tareas, subtareas y productos de trabajo) para satisfacer sus necesidades.

3.6.3

Productos de trabajo del proceso unificado

En la figura 3.8 se ilustran los productos de trabajo clave que se produjeron como consecuencia de las cuatro fases técnicas del PU. Durante la fase de inicio, el propósito es establecer una "visión" general para el proyecto, identificar un conjunto de requisitos de negocios, formar un caso de negocios para el software y definir los riesgos del proyecto y del negocio que pudieran representar un obstáculo para el éxito. Desde el punto de vista del ingeniero de software, el producto de trabajo más importante generado durante la etapa de inicio es el modelo de caso de uso: una colección de casos de uso que describen la forma en que actores externos ("usuarios" humanos y no h u m a n o s del software) interactúan con el sistema y obtienen valor a partir de éste. En esencia, el modelo de casos de uso es una colección de escenarios de uso con plantillas estandarizadas que implican características y funciones del software mediante la descripción de una serie de condiciones previas, un flujo de eventos o un escenario, y un conjunto de condiciones exteriores para la interacción representada. En un inicio, los casos de uso describen requisitos al nivel del dominio de negocios (por ejemplo, el grado de abstracción es alto). Sin embargo, el modelo de casos de uso se refina y elabora conforme cada fase del PU se ejecuta y sirve como una entrada importante para la creación de productos de trabajo subsecuentes. Durante la fase de inicio sólo s e completa entre el 10 y 20 por ciento de los casos de uso. Después de la elaboración, se ha creado entre un 80 y 90 por ciento del modelo. La fase de elaboración produce un conjunto de productos de trabajo que elabora requisitos (incluso requisitos no funcionales 20 ), así c o m o una descripción arquitectónica y un diseño preliminar. Cuando el ingeniero de software inicia con el análisis orientado a objetos, el objetivo primordial es definir un conjunto de clases de análisis que describan en forma adecuada el comportamiento del sistema. El modelo de análisis del PU es un producto de trabajo que se desarrolla como consecuencia de esta actividad. Los paquetes de clases y análisis (colecciones de clases) definidos como una parte del modelo de análisis se refinan después en un modelo de diseño, el cual identifica clases de diseño, subsistemas y las interfases entre los subsistemas. Los modelos de análisis y diseño expanden y refinan una representación TM evolutiva de la arquitectura del software. Además, en la fase de elaboración se revisan los riesgos y el plan de proyecto para asegurar que cada uno de ellos conserve su validez. La fase de construcción produce un modelo de implementación que traduce las

PDF Editor

clases de diseño en componentes de software que se construirán para ejecutar el sis-

20 Requisitos que no se pueden deducir del modelo de caso de uso.

72

PARTE UNO

Principales productos de trabajo producidos para cada fase del PU.

a


F a s e d e inicio D o c u m e n t o d e la visión M o d e l o inicial d e c a s o d e u so G l o s a r i o inicial del p r o y e c t o C a s o inicial d e n e g o c i o Evaluación inicial del riesgo Plan d e p r o y e c t o , fases e iteraciones M o d e l o del n e g o c i o si es n e c e s a r i o U n o o m á s prototipos

Fase de elaboración Modelo d e cosos d e uso Requisitos suplementarios, s e incluyen los n o funcionóles M o d e l o d e análisis Descripción d e la arquitectura del s o f t w a r e Prototipo a r q u i t e c t ó n i c o ejecutable Modelo de diseno preliminar lisia r e v i s a d a d e riesgos Plon d e p r o y e c t o q u e incluye plan d e iteración flujos d e t r a b a j o a d a p t a d o s fundamentos p r o d u c t o s técnicos del t r a b a j o M a n u a l preliminar del usuario

F a s e d e construcción M o d e l o del d i s e ñ o C o m p o n e n t e s del software Incremento i n t e g r a d o del s o f t w a r e Plan y p r o c e d i m i e n t o de pruebas Casos de prueba Documentación del s o p o r t e m a n u a l e s del u s u a r i o m a n u a l e s d e instalación d e s c r i p c i ó n del incremento actual

Fose d e t r a n s i c i ó n Incremento d e s o f t w a r e integrado ;

Retroalimentación g e n e r a l del usuario

t e m a , y u n m o d e l o de despliegue convierte los c o m p o n e n t e s e n el a m b i e n t e físico de computación. Por último, un m o d e l o de prueba describe las p r u e b a s e m p l e a d a s para a s e g u r a r que los c a s o s de uso se reflejen de m a n e r a apropiada en el s o f t w a r e que se h a construido. La fase de transición entrega el in c r e m e n to del s o f t w a r e y evalúa los productos de trabajo elaborados durante la etapa e n que los usuarios finales trabajan con el software. En esta etapa se produce la retroalimentación proveniente de las p r u e b a s beta y los requerimientos cualitativos de cambio. 3.7

RESUMEN Los m o d e l o s prescriptivos del proceso de s o f t w a r e se han aplicado d u r a n t e m u c h o s a ñ o s e n un e s f u e r z o e n c a m i n a d o a o r d e n a r y estructurar el desarrollo del software. Cada u n o de e s t o s m o d e l o s convencionales sugiere un flujo de TM proceso q u e de alguna forma es diferente, p e r o todos realizan el m i s m o c o n j u n t o de actividades genéricas del m a r c o de trabajo: comunicación, planeación, modelado, construcción y despliegue.

PDF Editor

El m o d e l o en c a s c a d a sugiere u n a progresión lineal de actividades del m a r c o de

trabajo que a m e n u d o resulta inconsistente con la realidad m o d e r n a en el m u n d o del s o f t w a r e (por ejemplo, con el c a m b i o continuo, los s i s t e m a s e n evolución, las fechas de entrega restringidas). Sin embargo, e s t e m o d e l o se p u e d e aplicar en situaciones en las cuales los requisitos están bien definidos y son estables.

CAPITULO 3

MODELOS PRESCiaPTIVOS DE PROCESO

73

Los modelos incrementales del proceso de software producen software como una serie de entregas de incrementos. El modelo DRA está diseñado para proyectos grandes que se deben entregar en marcos de tiempo muy reducidos. Los modelos de proceso evolutivos reconocen la naturaleza evolutiva d e la mayoría de los proyectos de ingeniería del software y están diseñados para ajustarse al cambio. Los modelos evolutivos, c o m o el de construcción de prototipos y el modelo en espiral, generan productos de trabajo incrementales (o versiones del software en funcionamiento) con rapidez. Estos modelos se pueden adaptar para aplicarlos a través de todas las actividades de la ingeniería del software: desde el desarrollo de conceptos hasta el mantenimiento del sistema a largo plazo. El modelo basado en componentes destaca la reutilización y ensambladura de componentes. Los modelos de métodos formales conducen a la utilización de un enfoque basado en las matemáticas para el desarrollo y la verificación del software. El modelo orientado a aspectos incluye los intereses generales que cubren la arquitectura total del sistema. El proceso unificado e s un proceso de software "guiado por los casos de uso, de arquitectura céntrica, iterativo e incremental" diseñado como un marco para los métodos y herramientas del UML. El proceso unificado e s un modelo incremental en el que se definen cinco fases: 1) una fase de inicio que abarca la comunicación con el cliente y las actividades de planeación, y destaca el desarrollo y el refinamiento de casos de uso como un modelo primario; 2) una fase de elaboración que abarca la comunicación con el cliente y las actividades de modelado con un enfoque en la creación de modelos de análisis y diseño, con énfasis en las definiciones de clase y representaciones arquitectónicas; 3) una fase de construcción que refina y después traduce el modelo de diseño en componentes de software implementados; 4) una fase de transición que transfiere el software del desarrollador al usuario final para realizar las pruebas beta y obtener la aceptación; y 5) una fase de producción en la cual se realiza el monitoreo continuo y el soporte.

[AMB02] Ambler, S. y L. C o n s t a n t i n e , The Unified Process Inception Phase, CMP Books, 2002. [ARL02] Arlow, J. e I. N e u s t a n d t , UML and the Unified Process, Addison-Wesley, 2002. [BAC97] Bach, )., "Good Enough Quality: Beyond t h e Buzzword", en IEEE Computer, vol.30, n ú m . 8, ag o s t o d e 1997, pp. 96-98. [BOE88] B o e h m , B., "A Spiral Model for S o f t w a r e Development E n h a n c e m e n t " , en Computer, TM vol. 21, n ú m . 5, mayo de 1988, pp. 61-72. [BOE98] Boehm, B., "Using t h e WINWIN Spiral Model: A Case Study", e n Computer, vol.3, núm.7, julio d e 1998, pp. 33-34. [BOEOl] Bohem, B., "The Spiral Model a s a Tool for Evolutionary S o f t w a r e Acquisition", en CrossTalk, m a y o d e 2001, disponible en h t t p : / / w w w . s t s c . h i l l . a f . m i l / c r o s s t a l k / 2 0 0 1 / 0 5 / boehm.html. ( B 0 0 9 4 ) Booch, G., Object-Oriented Analysis and Design, 2a. ed., B e n j a m i n C u m m i n g s , 1994. [BRA94] Bradac, M., D. Peny y L. Votta, "Prototyping a Process Monitoring Experiment", en IEEE TTans Software Engineering, vol. 20, núm. 10, octubre de 1994, pp. 774-784. [BR075J Brooks, F., The Mythical Mar-Month, Addison-Wesley, 1975.

PDF Editor

PARTE UNO

a


IBUT941 Butler,)., "Rapid Application D e v e l o p m e n t in Action", e n Managing System Development, Applied Computer Research, vol. 14, núm.5, m a y o d e 1994, pp. 6-8. [DYE 92] Dyer, M., The Cleanroom Approach to Quality Software Development, Wiley, 1992. [ELR01] Elrad, T., R. Filman y A. B a d e r (eds.), "Aspect-Oriented P r o g r a m m i n g " , e n Comm. ACM, vol. 44, n ú m . 10, o c t u b r e de 2001, edición especial. [FOW99] Fowler, M. y K. Scott, UML Distilled, 2 a . ed., Addison-Wesley, 1999. [GIL88] Gilb, T „ Principies of Software Engineering Management, A d d i s o n - W e s l e y , 1998. [GRA03] G r a d e c k i , J. y N. Lesiecki, Mastering AspectJ: Aspect-Oriented Programming in Java, Wiley, 2003. [GRU02J Grundy, J., "Aspect-Oriented C o m p o n e n t Engineering", 2002, h t t p : / / w w w . e s . auckland. ac.nz/-john-g/aspects.html. [HAN95] H a n n a , M., "Farewell t o Waterfalls", e n Software Magazine, m a y o d e 1995, p p . 3 8 - 4 6. [HES96] H e s s e , W., " T h e o r y a n d P r a c t i c e of the S o f t w a r e Process—A Field S t u d y a n d its Implications for Project M a n a g e m e n t " , Software Process Technology, 5th European Workshop, EWSPT 96, Springer LNCS 1149, 1996, pp. 241 -256. [HESOI] Hesse, w . , " D i n o s a u r M e e t s A r c h a e o p t e r y x ? S e v e n T h e s e s o n R a t i o n a l ' s Unified P r o c e s s (RUP)", e n Proc. 8th Intl. Workshop on Evaluation of Modeling Methods in System Analysis and Design, Ch. Vil Interlaken, 2001. [JAC92] J a c o b s o n , 1., Object-Oriented Software Engineering, Addison-Wesley, 1992. [)AC991 J a c o b s o n , i„ B o o c h , G. y J. R u m b a u g h , The Unified Software Development Process, Addison-Wesley, 1999. [KAU95] K a u f f m a n , S., Al Home in the Universe, Oxford, 1995. [KER94J K e r r J . y R . Hunter, Inside RAD, McGraw-Hill, 1991. [MAR911 M a r t i n , R a p i d Application Development, Prentice-Hall, 1991. [McDE93] M c D e r m i d J. y P. Rook, " S o f t w a r e D e v e l o p m e n t P r o c e s s M o d e l s " , e n Software Engineer's Reference Book, CRC Press, 1993, p p . 1 5 / 2 6 - 1 5 / 2 8 . |M1L87] Mills, H.D., M. Dyer y R. Linger, " C l e a n r o o m S o f t w a r e E n g i n e e r i n g " , e n IEEE Software, s e p t i e m b r e d e 1987, pp. 19-25. [NIE92] Nierstrasz, O., S. G i b b s y D. Tsichritzis, " C o m p o n e n t - O r i e n t e d S o f t w a r e D e v e l o p m e n t " , e n CACM, vol. 35, n ú m . 9, s e p t i e m b r e d e 1992, pp. 160-165. [NOGOO] Nogueira, J., C. J o n e s y Luqi, "Surfing t h e E d g e of C h a o s : Applications t o S o f t w a r e Engineering", C o m m a n d a n d Control Research Technology S y m p o s i u m , Naval Post G r a d ú a t e School, Monterey CA, junio d e 2000, disponible e n http//www.dodccrp.org/2000CCRTS/cd/html/pdf_papers/Track_4/075.pdf. IREE02] Reed, P., Developing Applications with java and UML, A d d i s o n - W e s l e y , 2002. [REI95] Reilly, J. P , "Does RAD U v e Up th t h e Hype", e n IEEE Software, s e p t i e m b r e d e 1995, p p . 24-26. [ R 0 0 9 6 ] Roos, l „ ' T h e Poised O r g a n i z a t i o n : Navigating Effectively on K n o w l e d g e L a n d s c a p e s " , 1996, disponible e n h t t p : / / w w w . i m d . c h / f a c / r o o s / p a p e r _ p o . h t m l . [ROY70] Royce, W.W., " M a n a g i n g t h e D e v e l o p m e n t of Large S o f t w a r e S y s t e m s : C o n c e p t s a n d Techniques" en, Proc. WESCON, a g o s t o d e 1970. [RUM91] R u m b a u g h , J. et al., Object-Oriented Modeling and Design, Prentice-Hall, 1991. [STI01] Stiller, E. y C. LeBlanc, Project-Based Software Engineering: An Object-Oriented Approach, Addison-Wesley, 2001. [WIR90] Wirfs-Brock, R„ B. Wilkerson y L. Weiner, Designing Object-Oriented Software, P r e n t i c e TM Hall, 1990. [YOU94J Yourdon, E„ " S o f t w a r e Reuse", e n Application Development Strategies, vol. 6, n ú m . 12, diciembre d e 1994, pp. 1-16. [YOU95] Yourdon, E., " W h e n G o o o d E n o u g h Is Best", e n IEEE Software, vol. 12, n ú m . 3, m a y o d e 1995, pp. 79-81.

PDF Editor

3 . 1 . Leer [NOGOO] y e s c r i b i r un d o c u m e n t o d e d o s o t r e s p á g i n a s q u e t r a t e s o b r e el i m p a c t o del "caos" e n la ingeniería del s o f t w a r e .

CAPÍTULO 3

MODELOS PRESCRIFITVOS DE PROCESO

75

3 - 2 . Dar tres ejemplos d e proyectos d e s o f t w a r e q u e pudieran adaptarse al m o d e l o en cascada. Ser específico. 3 - 3 . Proporcionar tres e j e m p l o s de proyectos d e s o f t w a r e q u e p u d i e r a n a d a p t a r s e al m o d e l o de construcción de prototipos. Ser específico. 3 . 4 . ¿Cuáles a d a p t a c i o n e s se r e q u i e r e n en el p r o c e s o si el p r o t o t i p o e v o l u c i o n a r á h a c i a un sistema o producto q u e p u e d e entregarse? 3 . 5 . Para lograr un desarrollo rápido el modelo DRA a s u m e la existencia de u n a cosa. ¿Cuál e s y por qué dicha suposición n o siempre es verdadera? 3 . 6 . Proporcionar tres e j e m p l o s de p r o y e c t o s de s o f t w a r e q u e p u d i e r a n a d a p t a r s e al m o d e l o Incremental. Ser específico. 3 . 7 . ¿ Q u é se p u e d e decir a c e r c a del s o f t w a r e q u e e s t á en desarrollo o en m a n t e n i m i e n t o mientras se avanza hacia fuera del flujo d e proceso en espiral? 3 . 8 . ¿Es posible c o m b i n a r m o d e l o s de p r o c e s o ? Si la r e s p u e s t a e s afirmativa, m e n c i ó n e s e u n ejemplo. 3 . 9 . El m o d e l o c o n c u r r e n t e del p r o c e s o define u n c o n j u n t o de "estados". Describir c o n p a l a b r a s p r o p i a s lo q u e r e p r e s e n t a n e s t o s e s t a d o s , y d e s p u é s indicar c ó m o e n t r a n en j u e g o dentro del modelo concurrente del proceso. 3 . 1 0 . ¿Cuáles son las v e n t a j a s y d e s v e n t a j a s d e desarrollar s o f t w a r e para el cual la calidad es "lo s u f i c i e n t e m e n t e buena"? Esto es, ¿qué p a s a c u a n d o se resalta la velocidad del desarrollo sobre la calidad del proyecto? 3 . 1 1 . Proporcionar tres e j e m p l o s d e proyectos d e s o f t w a r e q u e pudieran a d a p t a r s e al modelo b a s a d o en c o m p o n e n t e s . Ser especifico. 3 . 1 2 . Es posible probar que un c o m p o n e n t e de s o f t w a r e o incluso un p r o g r a m a completo está correcto. Entonces, ¿por qué n o todos lo hacen? 3 . 1 3 . Exponer c o n a r g u m e n t o s p r o p i o s el significado d e "intereses generales". I-a iterativa s o b r e el ADP se e x p a n d e c o n rapidez. Investigar y escribir un d o c u m e n t o breve s o b r e la situación actual. 3 . 1 4 . ¿El proceso unificado y el UML son la misma cosa? Explicar la respuesta. 3 . 1 5 . ¿Cuál es la diferencia entre u n a fase del PU y un flujo de trabajo del PU?

Q T R A S L E C T V R A S Y F U E N T E S DE I N F O R M A C I Ó N La mayor parte de los textos sobre ingeniería del software consideran los modelos prescriptivos d e proceso c o n algún detalle. Los libros d e Sommerville (Software Engineering, sexta edición, Addison-Wesley, 2000), Pfleeger (Software Engineering: Theoiy and Practice, PrenticeHall, 2001), y Schach (Object-Oriented and Classical Software Engineering, McGraw-Hill, 2001) consideran los paradigmas convencionales y analizan s u s fortalezas y debilidades. A pesar d e TM s e g u n d a q u e n o se dedica en forma específica al proceso, Brooks (The Mythicai Man-Month, edición, Addison-Wesley, 1995) presenta la experiencia g a n a d a en proyectos antiguos que tienen u n a gran relación con el proceso. Firesmith y Henderson-Sellers (The OPEN Piocess Framework: An Introduction, Addison-Wesley, 2001), presenta u n a plantilla general para crear "procesos de software flexible, pero, a ú n así, indisciplinados" y analiza los atributos y objetivos del proceso. Sharpe y McDermott (Workjlow Modeiing: Too/s for Process Iniprovement and Application Development, Artech House, 2001) presentan herramientas para el modelado de procesos de software y negocios. Jacobson Criss y ¡onsson (Software Reuse, Addison-Wesley, 1997) y McCIure (Software Reuse Techniques, Prentice-Hall, 1997) p r e s e n t a n m u c h a información útil

PDF Editor

PARTE UNO

a


s o b r e el desarrollo b a s a d o en c o m p o n e n t e s . Heineman y Council (Component-Based Software Engineering, Addison-Wesley, 2001) describen el p r o c e s o requerido p a r a implementar sistemas b a s a d o s en c o m p o n e n t e s . Kenett y Baker (Software Process Quality: Management and Control, Marcel Dekker, 1999) consideran la forma en q u e la gestión d e calidad y el diseño d e proceso están c o n e c t a d o s en forma íntima entre si. Ambriola (Software Process Technology, Springer-Verlag, 2001), Derniame y s u s colegas (Software Process: Principies, Methodology, and Technology, Springer-Verlag, 1999) presentan conferencias editadas q u e incluyen m u c h o s aspectos teóricos y de investigación y q u e son relevantes para el p r o c e s o d e software. Jacobson, Booch y Rumbaugh h a n escrito el libro f u n d a m e n t a l sobre el proceso unificado [)AC99]. Sin embargo, los libros de Arlow y Neustadt [ARL02] y una serie de tres v o l ú m e n e s de Ambler y Constantine [AMB02] ofrecen u n a excelente información complementaria. Krutchen (The Rational Unified Process, segunda edición, Addison-Wesley, 2000) ha escrito u n a valiosa introducción al PU. La gestión de un proyecto dentro del contexto del PU está escrita en detalle por Royce (Software Project Management: A Unified Framework, Addison-Wesley, 1998). La descripción definitiva del PU la ha desarrollado la Rational Corporation y está disponible en línea en www.rational.com. En Internet existe u n a amplia variedad d e f u e n t e s d e información sobre la ingeniería y el proceso del software. En el sitio web d e SEPA se p u e d e encontrar una lista actualizada de referencias en la red mundial que son relevantes p a r a el proceso d e software:

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

TM

PDF Editor

C A P I T U L O

DESARROLLO ÁGIL

E

j» B J»

n 2001, Kent Beck y otros 16 notables desarrolladores, escritores y consultores [BEC01] (conocidos c o m o la "Alianza Ágil") firmaron el "Manifiesto para el desarrollo ágil de software", el cual establecía:

H e m o s d e s c u b i e r t o m e j o r e s f o r m a s d e desarrollar s o f t w a r e al construirlo p o r nuestra c u e n t a y a y u d a r a o t r o s a hacerlo, Por m e d i o d e e s t e t r a b a j o h e m o s llegado a valorar:

*5

A los individuos y sus interacciones

s o b r e los p r o c e s o s y las h e r r a m i e n t a s .

. J7

Al software en funcionamiento

..91

A la colaboración

..n

A ia respuesta al cambio s o b r e el s e g u i m i e n t o d e u n plan.

..17

s o b r e la d o c u m e n t a c i ó n e x t e n s a .

del cliente s o b r e la n e g o c i a c i ó n del contrato.

Esto es, a u n q u e los t é r m i n o s a la d e r e c h a tienen valor, n o s o t r o s v a l o r a m o s m á s los a s p e c t o s d e la izquierda.

.M

Un manifiesto se asocia por lo general con un movimiento político e m e r g e n te.- aquel que ataca a la vieja vanguardia y sugiere un cambio revolucionario (en el mejor de los c a s o s para mejorar). De alguna forma, esto es con exactitud de lo que se trata el desarrollo ágil. A pesar de que las ideas subyacentes q u e c o n d u c e n al desarrollo ágil h a n est a d o p r e s e n t e s p o r m u c h o s años, no ha sido s i n o hasta la década p a s a d a que estas ideas h a n cristalizado en un "movimiento". En esencia, los m é t o d o s ágiles 1 se desarrollaron e n u n intento por superar las debilidades advertidas y reales en la ingeniería del s o f t w a r e convencional. El desarrollo ágil proporciona beneficios importantes, p e r o es imposible aplicarlo en todos los proyectos, productos, pers o n a s y situaciones.

41

J7 .84

XI

¿ Q u é e s ? La ingeniería de software ágil combina una filosofía y un conjunto de directrices de desarrollo. La filosofía busca la satisfacción del cliente y la entrega temprana de soft•a-e ¡ncremental; equipos de proyecto pequemos y con alta motivación; métodos informales; . - mínimo de productos de trabajo de la ingeniería del software; y una simplicidad general del desarrollo. Las directrices de desarrollo resalan la entrega sobre el análisis y el diseño (aunque estas actividades no se descartan), y la

comunicación activa y continua entre los desarrolladores y ios clientes. ¿ Q u i é n l o h a c e ? Los ingenieros de software y otros participantes del proyecto {gerentes, clientes y usuarios finales) trabajan juntos en un equipo ágil: un equipo con organización propia y que controla su propio destino. Un equipo ágil fomenta la comunicación y la colaboración entre TM todos los que trabajan en él. ¿Por q u é e s i m p o r t a n t e ? El ambiente moderno de los negocios ocasiona que los sistemas basados en computadoras y los productos de

PDF Editor 1

A los métodos ágiles algunas veces se les llama métodos ligeros o livianos

77

78

PARTE UNO a

PROCESO

Da SOFTWARE

software estén acelerados y en cambio continuo. La ingeniería del software ágil representa una opción razonable a la ingeniería convencional para ciertas clases de software y ciertos tipos de proyectos de software. Ha demostrado su ufilidad al entregar sistemas exitosos con rapidez. ¿Cuáles s o n l o s p a s o s ? El desarrollo ágil podría llamarse con mayor precisión "ingeniería del software ligera". Las actividades básicas del '*f- marco de trabajo -comunicación con el cliente, planeación, modelado, construcción, entrega y ; evolución - se conservan, pero éstas se canfor ;\í man como un conjunto mínimo de tareas que empuja al equipo de proyecto hacia la construcción y la entrega (habrá quienes argumenten que esto se hace a costa del análisis del proble-

ma y del diseño de la solución). ¿Cuál e s el p r o d u c t o o b t e n i d o ? Los clientes e ingenieros de software que han adoptado la filosofía ágil tienen la misma visión: el único producto de trabajo realmente importante es un "incremento de software" en funcionamiento, el cual se entrega al cliente en una fecha prometida. ¿ C ó m o p u e d o e s t a r s e g u r o d e q u e lo h e h e c h o c o r r e c t a m e n t e ? Si el equipo de software está de acuerdo en que el proceso funciona y dicho equipo produce incrementos de software entregables que satisfacen al cliente, entonces el trabajo está bien hecho.

No es la antítesis de la práctica sólida de la ingeniería del s o f t w a r e y es posible aplicarla c o m o u n a filosofía p r e d o m i n a n t e para cualquier trabajo de software. En la e c o n o m í a m o d e r n a , a m e n u d o resulta difícil o imposible predecir c ó m o evolucionarán con el tiempo los sistemas b a s a d o s en c o m p u t a d o r a s (por ejemplo, las aplicaciones Web). Las condiciones del m e r c a d o c a m b ia n con rapidez, las necesidad e s de los usuarios finales evolucionan, y las n u e v a s a m e n a z a s competitivas emergen sin previo aviso. En m u c h a s situaciones ya es imposible definir por completo los requisitos a n t e s de q u e c o m i e n c e el proyecto. Los ingenieros de s o f t w a r e deben ser tan ágiles c o m o para responder a un a m b i e n t e de negocios fluido. ¿Lo anterior significa que el reconocimiento de e s t a s realidades m o d e r n a s ocasiona que se descarten los valiosos principios, conceptos, m é t o d o s y h e r r a m i e n t a s de la ingeniería del software? No, ¡en lo absoluto; Como todas las disciplinas de ingeniería, la ingeniería del s o f t w a r e continúa en evolución. Se p u e d e adaptar con facilidad para enfrentar los retos que implica u n a exigencia de agilidad. "Agilidad: 1 , todo lo demás: 0." Tom DeMarco En un libro que invita a la reflexión y trata sobre el desarrollo TMágil de software, Alistair Cockburn [COC02a] a r g u m e n t a que los modelos prescriptivos de proceso p r e s e n t a d o s en el capítulo 3 tienen u n a falla importante: olvidan las fragilidades de las

PDF Editor personas que construyen

el software de computadora.

Los ingenieros de s o f t w a r e no

son robots. Ellos m u e s t r a n u n a gran variedad en los estilos de trabajo y diferencias significativas en su grado de habilidad, creatividad, orden, consistencia y espontaneidad. Algunos se comunican muy bien en forma escrita, otros no. Cockburn argumenta que los modelos de p r o c e s o pueden "enfrentar las debilidades c o m u n e s de la

gente con disciplina o tolerancia [alguna de las dos]" [CQC02a], y que los modelos

CAPÍTULO 4

DESARROLLO ÁGIL

79

de proceso m á s prescriptivos eligen la disciplina. Él establece: "Como la consistencia en la acción e s u n a debilidad h u m a n a , las metodologías que exigen un alto grado de disciplina son frágiles" [CC)C02a]. Los modelos de p r o c e s o funcionarán si proporcionan un m e c a n i s m o realista que f o m e n t e la disciplina necesaria, o d e b e n estar caracterizados de m a n e r a que m u e s tren "tolerancia" por la g e n t e que realiza el trabajo de la ingeniería del software. De m a n e r a invariable, la g e n t e de software adopta y sostiene m á s fácilmente las prácticas tolerantes, p e r o (como Cockburn lo admite) tal vez sea m e n o s productiva. Com o la mayoría de las c o s a s en la vida, se deben considerar los intercambios.

AA. ¿Qué es la agilidad e n el contexto del trabajo de la ingeniería del software? Ivar Jacobson [JAC02] proporciona una definición útil: Agilidad se ha convertido actualmente en la palabra d e m o d a en c u a n t o se describe un m o d e r n o proceso de software. Cualquiera es ágil. Un equipo ágil es un equipo rápido que responde d e m a n e r a apropiada a los cambios. Éstos son, en gran parte, la materia del desarrollo d e software. Cambios en el software que se va a construir, c a m b i o s entre los m i e m b r o s del equipo, cambios debidos a las n u e v a s tecnologías, cambios d e tod o tipo q u e p u e d e n incidir en el producto q u e se construye o en el proyecto q u e crea el producto. En cualquier actividad d e software se debe incluir un soporte para los c a m bios, esto es algo q u e a d o p t a m o s p o r q u e es el alma y el corazón del software. Un equip o ágil reconoce q u e el s o f t w a r e lo desarrollan individuos q u e trabajan en equipo y q u e las aptitudes de esta gente, y su capacidad p a r a colaborar, son esenciales p a r a el éxito del proyecto.

De a c u e r d o con la visión de Jacobson, la insistencia e n el c a m b i o e s el conductor primordial hacia la agilidad. Los ingenieros de s o f t w a r e deben tener pies veloces si quieren ajustarse a los c a m b i o s rápidos que describe Jacobson. "Ln agilidad es dinámica, ton contenido específico, ajustable al cambio de manera dinámico y orientada ol crecimiento." Steven Goldman el al. Pero la agilidad e s m á s que una respuesta efectiva al cambio. También incluye la

*

[CONSUO.

é e cometer el supone/ que proporciona para soluciones. un y lo disciplina

filosofía del manifiesto e n u n c i a d o al principio de este capítulo. Estimula las estructuras y actitudes de los equipos para que la comunicación (entre losTM m i e m b r o s del equipo, entre los técnicos y la gente de negocios, entre los ingenieros de s o f t w a r e y sus gerentes) sea m á s fácil. Resalta la entrega rápida del s o f t w a r e operativo y le res-

PDF Editor

ta importancia a los productos de trabajo intermedio (lo cual no siempre e s bueno); adopta al cliente c o m o u n a parte del equipo de desarrollo y trabaja para eliminar la actitud del tipo "nosotros y ustedes" que a ú n perjudica a m u c h o s proyectos de software; r e c o n o c e que la planeación tiene sus límites en un m u n d o incierto y que el plan de proyecto d e b e ser flexible.

PARTE UNO


La Alianza Ágil [AGI03J define 12 principios para quienes quieren alcanzar la agilidad: 1. Nuestra mayor prioridad e s satisfacer al cliente mediante la entrega temprana y continua de software valioso. 2 . Bienvenidos los requisitos cambiantes, incluso en fases tardías del desarrollo. La estructura de los procesos ágiles cambia para la ventaja competitiva del cliente. 3 . Entregar con frecuencia software en funcionamiento, desde un par de semanas hasta un par de meses, con una preferencia por la escala de tiempo más corta. 4 . La gente de negocios y los desarrolladores deben trabajar juntos a diario a lo largo del proyecto. 5 . Construir proyectos alrededor de individuos motivados. Darles el ambiente y el soporte que necesitan, y confiar en ellos para obtener el trabajo realizado. 6. El método más eficiente y efectivo de transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara a cara. 7. El software en funcionamiento es la medida primaria de progreso. 8. Los procesos ágiles promueven el desarrollo sustentable. Los patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un paso constante de manera indefinida. 9 . La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 10. La simplicidad —el arte de maximizar la cantidad de trabajo n o realizado— es esencial. 11. Las mejores arquitecturas, los mejores requisitos y los mejores diseños emergen de equipos autoorganizados. 12. A intervalos regulares el equipo refleja la forma en que se puede volver más efectivo; entonces su comportamiento se ajusta y adecúa en concordancia.

TM

La agilidad se p u e d e aplicar en cualquier proceso de software. Sin embargo, para lograrlo es esencial que el proceso sea diseñado en u n a forma que permita al equipo del proyecto adaptar y coordinar las tareas, conducir la planeación en una

PDF Editor

forma que entienda la fluidez de un enfoque de desarrollo ágil, eliminar todo p e ro no los productos de trabajo esenciales y m a n t e n e r l o s controlados, y enfatizar una estrategia de entrega incremental que proporcione software en funcionamiento al cliente tan rápido c o m o sea factible para el tipo de producto y el ambiente operativo.

CAPITULO 4

4.2

81

DESARROLLO ÁGIL

ES tf« PPQCESO AgU-? Cualquier proceso ágil de software s e caracteriza de una m a n e r a que refiere tres suposiciones clave [FOW02) acerca de la mayoría de los proyectos de software: 1. Resulta difícil predecir cuáles requisitos del software persistirán y cuáles c a m biarán. De igual forma, e s difícil presagiar c ó m o cambiarán las prioridades del cliente mientras se ejecuta u n proyecto. 2.

Para m u c h o s tipos de software, el diseño y la construcción están intercalados. Esto es, a m b a s actividades se deben realizar de m a n e r a conjunta, de m o d o que los modelos de diseño s e a n p r o b a d o s conforme se crean. Resulta difícil predecir c u á n t o diseño se necesita a n t e s de que la construcción se utilice para probar el diseño.

3 . El análisis, el diseño y la construcción no s o n predecibles (desde el p u n t o de vista de la planeación), lo que sería deseable. Dados los p u n t o s anteriores, surge u n a pregunta importante: ¿cómo se crea un proceso susceptible de manipular en forma impredecible? La respuesta, c o m o ya se ha puntualizado antes, reside en la adaptabilidad del proceso (a un proyecto y a condiciones técnicas que cambian con rapidez). Por lo tanto, u n p r o c e s o ágil debe ser adaptable. Pero u n a adaptación continua sin un progreso logra muy poco. Por lo tanto, un proceso ágil de software d e b e a d a p t a r s e en forma incremental.

Para llevar a c a b o

u n a adaptación incremental, un equipo ágil requiere de la retroalimentación con el cliente (para que sea factible realizar las a d a p t a c i o n e s apropiadas). Un catalizador efectivo para la retroalimentación del cliente es u n prototipo operacional o u n a porción de u n sistema operacional. Por lo tanto, d e b e instituirse u n a estrategia incremental de desarrollo. Los incrementos

de software (prototipos ejecutables o una porción de

u n sistema operacional) d e b e n entregarse en cortos periodos p a r a que la adaptación m a n t e n g a un b u e n ritmo con el cambio (imprevisibilidad). Este enfoque iterativo le permite al cliente evaluar el incremento del s o f t w a r e de m a n e r a regular, proporcionar la retroalimentación necesaria al equipo de software, e influir sobre las a d a p t a ciones del proceso que se realizan para adecuar la retroalimentación. "No existe un sustituto para la retroalimentación rápida, ni en el proceso de desarrollo ni en el producto TMmismo." Martin Fowler

PDF Editor 4.2.1 Las políticas del desarrollo ágil

Existe un d e b a t e considerable (a veces estridente) sobre los beneficios y la aplicabilidad del desarrollo ágil del s o f t w a r e c o m o alternativa a procesos de ingeniería del software m á s convencionales. Jim Highsmith [HIG02a] (a m a n e r a de broma) analiza los extremos c u a n d o caracteriza el sentimiento del c a m p o proagilidad ("agilitado-

82

PARTE UNO


res"). "Los metodólogos tradicionales son un conjunto de tipos que se arrastran en el lodo y q u e prefieren producir documentación que no fluye, e n vez de u n sistema de trabajo q u e cubra las necesidades del negocio." C o m o contraparte, establece la posición del c a m p o d e la ingeniería del software (de nuevo, e n forma d e broma): "Los metodólogos 'ligeros' y, eh, 'ágiles' son un conjunto de intrusos informáticos que v a n a estar ahí para dar u n a maldita sorpresa c u a n d o intenten elevar sus juguetes al nivel de s o f t w a r e de la empresa". Al igual que todos los a r g u m e n t o s sobre la tecnología del software, e s t e d e b a t e s o b r e la metodología corre el riesgo de d e g e n e r a r en u n a guerra religiosa. Si estalla la guerra, d e s a p a r e c e el p e n s a m i e n t o racional, y las creencias, en vez de los hechos, guían la t o m a de decisiones. Nadie está en contra de la agilidad. La pregunta real es: ¿cuál es la mejor m a n e ra de lograrla? Igual de importante e s la pregunta: ¿ c ó m o s e construye un s o f t w a r e que satisfaga hoy las necesidades de los clientes y m u e s t r e las características de calidad que le permitan extenderse y escalar para cubrir a largo plazo las necesidades del cliente? ^CONSLIO^

No existen r e s p u e s t a s absolutas para ninguna de e s t a s preguntas. Aun dentro de la escuela ágil se han propuesto varios m o d e l o s de proceso (sección 4.3), cada uno

No es necesario elegir entre agilidad e ingeniería del softwore. En lugar de ello, se puede definir un enfoque de ingeniería

con un e n f o q u e sutilmente diferente para el problema de la agilidad. Dentro de cada

de software que sea

g a n a r si se considera lo mejor de a m b a s escuelas, y n a d a que g a n a r si se denigra al-

ágil.

modelo hay un conjunto de "ideas" (que los agilitadores suelen llamar "tareas de trabajo") que representan u n a separación significativa de la ingeniería del s o f t w a r e convencional. Y a u n así, m u c h o s conceptos de agilidad son tan sólo a d a p t a c i o n e s de b u e n o s c o n c e p t o s de la ingeniería del software. C o m o p u n t o final, hay m u c h o que g u n o de los d o s enfoques. El lector interesado p u e d e consultar [HIGO 1 ], [HIG02a] y [DEM02] para un a n i m a do r e s u m e n de los a s p e c t o s técnicos y políticos importantes.

4.2.2

Factores humanos

Los d e f e n s o r e s del desarrollo ágil del s o f t w a r e resaltan la importancia de los "factores de las personas" en un desarrollo ágil exitoso. C o m o establecen Cockburn y Highsmith [COCOl]: "El desarrollo ágil se centra e n los talentos y las habilidades de los individuos, p u e s t o que el p r o c e s o se ajusta a p e r s o n a s y equipos específicos". El p u n t o clave e n esta afirmación e s que el proceso se ajusta a las necesidades de las personas y del equipo, y no al revés. 2

TM

PDF Editor "Aquello apenas suficiente para un equipo es excesivo o insuficiente pora otro."

2

Alistair Cockburn

La mayoría de las organizaciones de software exitosas reconocen esta realidad sin importar el modelo de proceso que elijan.

CAPÍTULO 4

83

DESARROLLO ÁGIL

Si los m i e m b r o s del equipo de software van a m a n e j a r las características del proc e s o que se aplica para construirlo, d e b e existir un gran n ú m e r o de rasgos clave e n tre la gente de un equipo ágil y el equipo mismo.C o m p e t e n c i a . En el contexto de un desarrollo ágil (al igual que e n la ingeniería del software convencional), la "competencia" abarca un talento innato, habilidades específicas relacionadas con el software, y un conocimiento general del proceso que el equipo haya elegido aplicar. La habilidad y el conocimiento del proceso pue* wfti»

den y d e b e n e n s e ñ a r s e a toda la g e n t e q u e f u n g e c o m o m i e m b r o de un equipo ágil. E n f o q u e c o m ú n . Aunque los miembros del equipo ágil d e s e m p e ñ e n tareas diferentes y aporten distintas habilidades al proyecto, todos deben enfocarse en una meta: entregar al cliente un incremento de trabajo de software d e n t r o del tiempo establecido. Alcanzar esta meta requiere que el equipo también se centre en a d a p taciones continuas (pequeñas y grandes) mediante las cuales el p r o c e s o satisfará las necesidades del equipo. C o l a b o r a c i ó n . La ingeniería del software (sin considerar el proceso) incluye evaluar, analizar y usar información que se c o m u n i c a al equipo de software; crear información que ayudará al cliente y a otros a e n t e n d e r el trabajo del equipo; y construir información (software de c o m p u t a d o r a y b a s e s de d a t o s relevantes) que ofrezca un valor comercial para el cliente. Estas t a r e a s se cumplirán si los miemb r o s del equipo colaboran, entre ellos, con el cliente y con sus gerentes. Habilidad para la t o m a d e d e c i s i o n e s . Todo b u e n equipo de s o f t w a r e (incluidos los equipos ágiles) d e b e permitirse la libertad de controlar su propio destino. Esto implica que al equipo se le dé autonomía, e s decir, autoridad para tomar decisiones en c u a n t o a cuestiones técnicas y del proyecto. C a p a c i d a d d e r e s o l u c i ó n d e p r o b l e m a s c o n f u s o s . Los gestores de s o f t w a r e deben reconocer que el equipo ágil enfrentará a m b i g ü e d a d e s y sufrirá golpes de m a n e r a continua debido al cambio. En algunos casos, el equipo d e b e aceptar que el problema que está resolviendo hoy tal vez no sea el problema que debe resolverse m a ñ a n a . Sin embargo, las lecciones aprendidas en cualquier actividad para la resolución de problemas (incluidas aquellas que sirven para solucionar el problema erróneo) pueden beneficiar al equipo en fases posteriores del proyecto.

VE GX

propia r i j a j o que 3 equipo propios y define

C o n f i a n z a y r e s p e t o m u t u o . El equipo ágil se d e b e convertir en loTM que De Marco y Lister [DEM98] llaman un equipo "cuajado" (véase el capítulo 21). Un equipo cuajado muestra la confianza y el respeto necesarios p a r a que "se u n a n con

PDF Editor tanta fuerza, que el todo s e a mayor que la s u m a de las partes" [DEM98],

O r g a n i z a c i ó n p r o p i a . En el contexto del desarrollo ágil, la organización

propia

implica tres factores: 1) el equipo ágil se organiza a sí m i s m o para el trabajo que d e b e hacerse; 2) el equipo organiza el proceso que mejor se ajusta a su a m b i e n t e local; 3) el equipo organiza el p r o g r a m a de trabajo c o n el que se alcance de mejor

PARTE UNO

84


m a n e r a la entrega del i n c r e m e n to del software. La organización propia tiene varios beneficios técnicos, p e r o lo m á s importante es que mejora la colaboración y eleva la moral del equipo. En esencia, el e q u i p o sirve c o m o su propia gestoría. Ken Schw a b e r [SCH02] puntualiza e s t o s a s p e c t o s c u a n d o escribe: "El equipo selecciona la cantidad de trabajo que cree que es c a p a z de hacer d e n t r o de la iteración, y el equipo se c o m p r o m e t e con el trabajo. Nada desalienta m á s a u n equipo que alguien m á s se c o m p r o m e t a por él. Nada motiva m á s a u n equipo que aceptar la responsabilidad de cumplir los c o m p r o m i s o s que él m i s m o hizo".

4.3

M O D E L O S Á G I L E S DE P R O C E S O La historia de la ingeniería del s o f t w a r e está llena de d e c e n a s de descripciones y m e todologías, m é t o d o s de m o d e l a d o y notaciones, h e r r a m i e n t a s y tecnologías obsoletas. Cada e l e m e n t o surgió con notoriedad y d e s p u é s lo eclipsó algo n u e v o y (supuestamente) mejor. Con la introducción de un amplio espectro de modelos ágiles de proceso —cada uno en busca de su aceptación dentro d e la c o m u n i d a d del desarrollo de software— el movimiento ágil está en la m i s m a ruta histórica. 3 "Nuestro profesión vo tros ios metodologías como un adolescente va tras la ropa." Stephen Hawrysh y Jim Ruprecht En las siguientes secciones se p r e s e n t a u n a visión general de cierto n ú m e r o de diferentes modelos ágiles de proceso. Existen m u c h a s similitudes (en filosofía y práctica) entre e s t o s e n f o q u e s . La intención e s subrayar aquellas características de cada m é t o d o q u e lo h a c e n único. Es importante señalar que todos los modelos ágiles se a j u s t a n (en mayor o m e n o r grado) al Manifiesto para el desarrollo de software y a los principios e n u n c i a d o s e n la sección 4.1.

4.3.1 Programación extrema (PE) A p e s a r de q u e los primeros trabajos s o b r e las ideas y los m é t o d o s asociados con la programación Referencia Web

www.extremepra groromiiig.org/ eiKontror uno

extrema (PE) se realizaron a finales de la década de 1980, el trabajo

f u n d a m e n t a l sobre la materia, escrito por Kent Beck [BEC99], se publicó e n 1999. Los libros subsiguientes de Jeffries et al. tJEFOl] sobre los detalles técnicos de la PE, y el trabajo adicional de Beck y Fowler [BECOlb] s o b r e la planeación de la PE expusieron

TM

los detalles del método. La PE utiliza un e n f o q u e orientado a objetos (parte 2 de este libro) c o m o su paradigma de desarrollo preferido. La PE abarca un c o n j u n t o de reglas y prácticas que

PDF Editor

ocurren en el contexto de cuatro actividades del m a r c o de trabajo: planeación, dise3

Esto no es algo malo. Antes de que uno o más modelos o métodos sean aceptados como un estándar de facto, todos deben competir por los corazones y las mentes de los ingenieros de software. Los "ganadores" evolucionan con la mejoría que proporciona la práctica, mientras que los "perdedores" desaparecen o se unen a los modelos "ganadores".

CAPÍTULO 4

85

DESARROLLO ÁGIL

diseño simple carias CRC

ki

soluciones pico prototipos

programación en pareja

Lan

de'

ño, codificación y pruebas. En la figura 4.1 se ilustra el proceso de la PE y se observan algunas de las ideas y tareas clave asociadas con cada actividad del m a r c o de trabajo. En los siguientes párrafos se r e s u m e n las actividades clave de la PE. P l a n e a c i ó n . La actividad de planeación c o m i e n z a creando una serie de historias (también llamadas historias del usuario) que describen las características y la funcioralidad requeridas para el soñware sos de uso descritos

en los capítulos

que se construirá.

Cada historia (similar a los ca-

7 y 8) la escribe el cliente y se coloca en una

carta índice. El cliente le asigna un valor (es decir, una prioridad) a la historia b a s á n d o s e en los valores generales del negocio respecto de la característica o la función. 4 Los m i e m b r o s del equipo de la PE evalúan e n t o n c e s cada historia y le asignan un costo, el cual se mide en s e m a n a s de desarrollo. Si la historia requiere m á s de tres s e m a n a s de desarrollo, se le pide al cliente que la divida en historias m e n o r e s , y se realiza de n u e v o la asignación del valor y el costo. Es importante destacar que las historias n u e v a s pueden escribirse en cualquier m o m e n t o . Los clientes y el equipo de PE trabajan j u n t o s para decidir c ó m o a g r u pTM a r las historias hacia el próximo l a n z a m i e n t o (el siguiente i n c r e m e n t o de software) para que el equipo de la PE las desarrolle. Una vez establecido el compromiso

básico (el

PDF Editor

a c u e r d o de las historias que se incluirán, la fecha de entrega y otras c u e s t i o n e s del proyecto) para u n l a n z a m i e n t o , el equipo de la PE o r d e n a las historias que se d e s a rrollarán de una de las siguientes tres m a n e r a s : 1) t o d a s las historias s e r á n imple-

4

El valor de una historia puede depender también de la presencia de otra historia.

86

PARTE UNO


m e n t a d a s de un m o d o inmediato (dentro de p o c a s s e m a n a s ) ; 2) las historias con valor m á s alto se m o v e r án en el p r o g r a m a y se i m p l e m e n t a r á n al principio; o 3) las historias m á s riesgosas se m o v e r án dentro del p r o g r a m a y se i m p l e m e n t a r á n al principio. Después de que se h a entregado el primer l a n z a m i e n t o del proyecto (también llaEnelslio

m a d o incremento de software), el equipo de la PE calcula la velocidad del proyecto.

c2.com/cgi/wiki?

Dicho de u n m o d o m á s simple, la velocidad del proyecto es el n ú m e r o de historias de

plamiingGame se

los clientes i m p l e m e n t a d o d u r a n t e el primer lanzamiento. Entonces, la velocidad del

puede encontrar un vellosa "juego de ploneadóit" poro la PE.

proyecto p u e d e utilizarse para I) ayudar a estimar fechas de entrega y el programa para l a n z a m i e n t o s subsecuentes, y 2) determinar si se h a h e c h o un compromiso excesivo en algunas de las historias de t o d o el proyecto de desarrollo. Si se presenta un compromiso excesivo, el contenido de los l a n z a m i e n t o s se modifica o se cambian las fechas de las e n t r e g a s finales. Conforme a v a n z a el trabajo de desarrollo, el cliente p u e d e agregar historias, c a m biar el valor de la historia existente, dividir historias o eliminarlas. Entonces el equipo de la PE considera de nuevo los l a n z a m i e n t o s restantes y modifica sus planes de a c u e r d o con ello. "Lo programación extrema es uno disciplina de desarrollo de software que se basa en valores de simplicidad, comunicación, retroalimentación y audacia." Ron Jeffries D i s e ñ o . El diseño de la PE sigue de m a n e r a rigurosa el principio MS (mantenerlo simple). Siempre se prefiere un diseño simple respecto de u n a presentación más compleja. Además, el diseño ofrece u n a guía de implementación para una historia c o m o está escrita, ni m á s ni m e n o s . Se d e s a p r u e b a el diseño de funcionalidad extra (porque el desarrollador s u p o n e que se requerirá m á s tarde). La PE apoya el uso de tarjetas CRC (capitulo 8) como un mecanismo ra p e n s a r en el s o f t w a r e en un contexto

orientado

efectivo pa-

a objetos. Las tarjetas CRC (cola-

borador-responsabilidad-clase) identifican y organizan las clases orientadas al objeto 6 que son relevantes para el in c r e m e n to del software actual. El equipo PE conduce el ejercicio del diseño por medio de un proceso similar al descrito en el capítulo 8 (sección 8.7.4.). Las tarjetas CRC s o n el único producto de trabajo realizado c o m o parte del proceso de la PE.

TMdiseño de la histoSi se encuentra un problema difícil de diseño c o m o parte del ria, la PE recomienda la creación inmediata de un prototipo operacional de e s a porción del diseño. El prototipo del diseño, llamado la solución pico, se implementa y

PDF Editor

evalúa. El propósito es reducir el riesgo c u a n d o comience la verdadera implementa5

Estas directrices de diseño se deberían seguir en todos los métodos de ingeniería del software, aunque a veces las notaciones y terminologías sofisticadas que se utilizan en el diseño pueden emplearse de una manera más simple.

6

En el capitulo 8, y a lo largo de la parte 2 del libro, se estudian las clases orientadas a objetos.

CAPÍTULO 4

87

DESARROLLO ÁGIL

ción y validar las estimaciones originales e n la historia que contiene el problema del diseño. La PE apoya la refabricación, una técnica de construcción que también lo es de diseño. Fowler [FOWOO] describe la refabricación de la siguiente m a n e r a : Refabricación es el proceso d e cambiar un sistema de software d e tal m a n e r a que n o altere el comportamiento externo del código y q u e m e j o r e la estructura interna. Es u n a m a n e r a disciplinada de limpiar el código [y modificar/simplificar el diseño interno], lo que minimiza las oportunidades d e introducir errores. En esencia, al refabricar, se mejora el d i s e ñ o del código d e s p u é s d e q u e se ha escrito.

Debido a que el diseño de la PE virtualmente no utiliza la notación y produce, si a c a so, muy p o c o s productos de trabajo, distintos a las tarjetas de CRC y soluciones pico, el diseño se considera c o m o u n artefacto que p u e d e y d e b e modificarse de m a nera continua a medida que prosigue la construcción. El propósito de refabricar es controlar e s t a s modificaciones al sugerir p e q u e ñ o s c a m b i o s del diseño que "pueden mejorar de m a n e r a radical el diseño" [FOWOO], Sin embargo, d e b e notarse que el esf u e r z o requerido para refabricar p u e d e a u m e n t a r en forma drástica a medida que crece el t a m a ñ o de la aplicación. Una noción central en la PE e s q u e el d i s e ñ o ocurre t a n t o a n t e s c o m o después del c o m i e n z o de la codificación. Refabricar significa que el d i s e ñ o ocurre de m a n e ra c o n t i n u a a medida q u e se construye el sistema. De h e c h o , la actividad de c o n s trucción m i s m a le proporcionará al equipo de PE u n a guía s o b r e c ó m o m e j o r a r el diseño. C o d i f i c a c i ó n . La PE recomienda que d e s p u é s de diseñar las historias y realizar el trabajo de diseño preeliminar el equipo no debe moverse hacia la codificación, sino q u e d e b e desarrollar u n a serie de p r u e b a s de unidad que ejerciten cada una de las historias que vayan a incluirse en el l a n z a m i e n t o actual (incremento de software). 7 Una vez creada la prueba de unidad, el desarrollador e s m á s capaz de centrarse en lo que debe implementarse para p a s a r la prueba de unidad. No se agrega nada extraño (MS). Una vez que el código está completo, la unidad p u e d e probarse de inmediato, y así proporcionar u n a retroalimentación instantánea a los desarrolladores. Un concepto clave durante la actividad de codificación (y u n o de los aspectos de la PE de los que m á s se h a hablado) es la programación

en pareja. La PE recomienda

que dos p e r s o n a s trabajen juntas en u n a estación de trabajo de c o m p u t a d o r a para crear el código de una historia. Esto proporciona un m e c a n i s m o paraTM la resolución de problemas en tiempo real (dos c a b e z a s piensan mejor que una) y el a s e g u r a m i e n to de la calidad e n las m i s m a s condiciones. También alienta que los desarrolladores

PDF Editor

se m a n t e n g a n centrados e n el problema que se tiene a la m a n o . En la práctica, c a da persona tiene un papel sutilmente diferente. Por ejemplo, una persona p u e d e pen-

7

Este enfoque es análogo a conocer las preguntas del examen antes de comenzar a estudiar. Esto facilita mucho más el estudio al enfocar la atención sólo sobre las preguntas que serán formuladas.

PARTE U N O


sar en los detalles de codificación de una porción particular del diseño, mientras que la otra se asegura de que se sigan los estándares de codificación (una parte requerida de la PE) y que el código que se genera "coincida" con el diseño más amplio de la historia. C u a n d o los p r o g r a m a d o r e s completan su trabajo el código que desarrollaron se integra con el trabajo d e otros. En algunos c a s o s e s t o lo lleva a c a b o diariamente el equipo de integración. En otros casos, la pareja de p r o g r a m a d o r e s e s la responsable de la integración. Esta estrategia de "integración continua" ayuda a evitar problemas de compatibilidad e interfaz y proporciona un a m b i e n t e de "prueba de h u m o " (capítulo 13) que ayuda a descubrir los errores d e s d e el principio. P r u e b a s . Ya se ha h e c h o notar que la creación de u n a prueba de unidad 8 a n t e s de c o m e n z a r la codificación es un e l e m e n t o clave para el e n f o q u e de la PE. Las prueb a s de unidad q u e se crean deben implementarse con un m a r c o de trabajo que permita automatizarlas (por lo tanto, p u e d e n ejecutarse de m a n e r a fácil y repetida). Esto apoya una estrategia de regresión de prueba (capítulo 13) c u a n d o el código se m o difica (al cual a m e n u d o se le confiere la filosofía de la PE de refabricar). C u a n d o las unidades individuales de prueba se o r g a n i z a n en un "conjunto universal de p r u e b a s " [WEL99], las p r u e b a s de integración y validación del sistema pueden realizarse a diario. Esto proporciona al equipo de PE una indicación continua del progreso y también p u e d e e n c e n d e r luces de emergencia previas si las c o s a s salen

\

mal. Wells [WEL99] establece: "Arreglar p r o b l e m a s p e q u e ñ o s cada p o c a s h o r a s tom a m e n o s tiempo que arreglar problemas e n o r m e s justo a n t e s de la fecha límite".

CLAVE

las pruebas de aceptación de la PE se derivan de las historias del usuario.

Las pruebas de aceptación de la PE, también llamadas pruebas del cliente, las especifica el cliente y se e n f o c a n en las características generales y la funcionalidad del sistema, e l e m e n t o s visibles y revisables por el cliente. Las p r u e b a s de aceptación se derivan de las historias del usuario que se han i m p l e m e n t a d o c o m o parte de un lanz a m i e n t o de software.

HOGARSEGURO

Tomar en cuenta el desarrollo de software ágil El escenario: Los a c t o r e s : Doug Miller, gerente d e ingeniería d e software; Jamie lazar, miembro del equipo de software; Vinod Raman, miembro del equipo de software.

La conversación:

J a m i e : Doug, ¿tienes un minuto? D o u g : Seguro Jamie, ¿qué pasa? J a m i e : Hemos estado pensando en nuestra TM conversación de ayer acerca del proceso... tú sabes, de cuál sería el proceso que elegiríamos pora este nuevo proyecto de HogarSeguro.

PDF Editor (llaman a la puerta)

8

Doug: ¿Y?

Las pruebas de unidad, que se tratan con detalle en el capítulo 13, s e enfocan sobre un componente

individual del software, al ejercitar la interfaz de los componentes, las estructuras de datos y la fun-

cionalidad en un esfuerzo por descubrir los errores locales en el componente.

CAPÍTULO 4

89

DESARROLLO ÁGIL

- c o b n d o con un amigo de otra ' r e comentó sobre la programación i r - o ^ e í c de proceso ágil, ¿has oído algo i buenas y malas. c; -osotros nos suena muy bien. Te e; software muy rápido, utiliza algo «roción en pareja para hacer i de rci'dad en tiempo real... pienso que es

D o u g : Estoy de acuerdo. Y aun si elegimos como nuestro enfoque un modelo incremental, no existe ninguna razón por la que no podamos incorporar mucho d e lo que la PE tiene que ofrecer. Vinod: Doug, antes dijiste "escuché cosas buenas y malas". ¿Cuáles fueron las "malos* 2 D o u g : Lo que no me gusta es Iq forma en que lá PE menosprecia el análisis y el diseñó... es como decir que la acción real sólo está en ia escritura del código. (los miembros del equipo se miran entre sí y sonríen)

— .c'-cs ideas realmente buenas. Por eí concepto de la programación en i 2e cue todos los participantes del corte del equipo de desarrollo. ¿Eso significa que mercadotecnia l el equipo con nosotros? i): Ellos son participantes, ¿no? Dios!... Van a estar pidiendo cambios -^cesariamente. Mi amigo me dijo que hay ir" los cambios durante el proyecto de ¿ustedes creen que debamos usar PE?

D o u g : Entonces, ¿están de acuerdo con el enfoque de la PE? J a m i e ( h a b l a n d o p o r a m b o s ) : ¡Jefe, lo que nosotros hacemos es escribir código!. D o u g (riendo): Es cierto, pero me gustaría verlos dedicar un poco menos d e tiempo a la codificación y a la recodificación y un poco más de tiempo a analizar lo que se tiene que hacer y a diseñar una solución que funcione. V i n o d : Puede ser que adoptemos ambas formas, agilidad con un poco de disciplina. D o u g : Vinod, creo que podemos hacerlo. De hecho, estoy seguro de ello.

E s d g o que definitivamente deberíamos de

4.3.2 Desarrollo adaptativo d e software (DAS) El desarrollo adaptativo de software (DAS) lo propuso Jim Highsmith [HIGOO] como una técnica para construir software y sistemas complejos. Los apoyos filosóficos del DAS se enfocan en la colaboración h u m a n a y la organización propia del equipo. Highsmith [HIG98] expone lo anterior cuando escribe: La organización propia es una propiedad d e los s i s t e m a s adaptativos complejos, similar a un "ajá" colectivo; es en el m o m e n t o de energía creativa c u a n d o surge la solución a algún

TM

problema persistente. La organización propia emerge c u a n d o los individuos, los a g e n t e s independientes (células en un cuerpo, especies en un ecosistema, desarrolladores en un

PDF Editor

equipo de software) cooperan [colaboran] para crear salidas emergentes. Una salida

e m e r g e n t e es u n a propiedad m á s allá d e la capacidad de cualquier agente individual. Por ejemplo, las n e u r o n a s individuales del cerebro n o p o s e e n conciencia, pero en forma co-

lectiva g e n e r a n la propiedad d e la conciencia. Tendemos a ver este f e n ó m e n o del surgi-

miento colectivo c o m o un accidente, o al m e n o s c o m o independiente y sin reglas. El estudio d e la organización propia demuestra que dicha visión es errónea.

90

PASTE UNO

Desarrollo adaptatívo de software.


planeaáón del ciclo adaptativo enunciado de la misión restricciones del proyecto requisitos básicos plan de lanzamiento en el tiempo

Lanzamiento incremento de software ajuste para ciclos subsecuentes

Referencia Web

www.adaptivesd.
Recopilación de requisitos JAD especificaciones mínimas

componentes implementados/probados grupos de enfoque para retroalimentación revisiones técnicas formales post mortem

Highsmith a r g u m e n t a que un e n f o q u e de desarrollo ágil y adaptativo b a s a d o en la colaboración es "tanto c o m o una f u e n t e de orden en las complejas interacciones e n tre disciplina e ingeniería". Él define un "ciclo de vida" del DAS (figura 4.2), el cual incorpora tres fases: especulación, colaboración y aprendizaje. E s p e c u l a c i ó n . En esta fase se inicia el proyecto y se c o n d u c e el ciclo adaptatívo de planeación.

m k ¿Cuáles son w las características de los ciclos adaptativos del DAS?

Este último utiliza información d e inicio del proyecto —el e n u n c i a d o de

la misión del cliente, restricciones de proyecto (por ejemplo, f e c h a s de entrega o descripciones del cliente) y los requisitos básicos— para definir el conjunto de ciclos de l a n z a m i e n t o (incrementos del software) que s e requerirán para el proyecto. 9 C o l a b o r a c i ó n . La g e n t e motivada trabaja junta de u n a forma q u e multiplica su talento y s u s salidas creativas m á s allá de sus n ú m e r o s absolutos. Este e n f o q u e de co-

ÔNSIJO^ La colaboración efectivo con el cliente ocurrirá sólo si se eliminan todas las actitudes del tipo "yo y ustedes".

laboración es un t e m a recurrente en todos los m é t o d o s ágiles, pero la cooperación n o es fácil. No es sólo comunicación, a u n q u e la comunicación e s parte de ella. No TM es sólo un a s u n t o de trabajo en equipo, a u n q u e un equipo "cuajado" (capítulo 21) es esencial para la presencia de la colaboración real. No es un r e c h a z o al individualis-

PDF Editor

mo, ya que la creatividad individual representa un papel importante en el p e n s a miento de colaboración. Esto es, por encima d e todo, u n a cuestión de confianza. Las p e r s o n a s que trabajan juntas d e b e n confiar entre sí para 1) criticar sin animosidad; 9

Obsérvese que el plan del ciclo adaptativo puede adaptarse, y con probabilidad lo hará, al proyecto cambiante y a las condiciones del negocio.

CAPÍTULO 4

DESARROLLO ÁGIL

91

2) ayudar sin resentimientos; 3) trabajar tan d u r o o m á s duro de lo que ya lo hacen; 4i tener el conjunto de aptitudes para contribuir al trabajo en curso; y 5) comunicar as problemas o preocupaciones e n u n a forma que c o n d u z c a a la acción efectiva.

Me gusta escuchar. He aprendido mucho al escuchar a las personas, l a mayofía de la gente nunca escucha." Ernest Hemingway

Aprendizaje. C o m o m i e m b r o s de un equipo de DAS se c o m i e n z a n a desarrollar los c o m p o n e n t e s integrantes de un ciclo adaptativo, la importancia radica en el a p r e n dizaje y en el progreso a través de un ciclo completo. De hecho, Highsmith [HIGGOO] a r g u m e n t a que los desarrolladores de s o f t w a r e a m e n u d o sobreestiman su c o m prensión (de la tecnología, el p r o c e s o y el proyecto), y que el aprendizaje les podría ayudar a mejorar su g r a d o de entendimiento real. Los equipos del DAS a p r e n d e n de tres m a n e r a s : 1. Grupos e n f o c a d o s . El cliente o los usuarios finales proporcionan retroalimentación sobre los incrementos de software que se entregan. Esto indica en forma directa la satisfacción o la insatisfacción de las necesidades del negocio. 2. R e v i s i o n e s t é c n i c a s f o r m a l e s . Los miembros del equipo del DAS revisan los c o m p o n e n t e s del s o f t w a r e desarrollado mientras mejoran su calidad y su aprendizaje. 3 . Post mortem.

El equipo de DAS se vuelve introspectivo al vigilar su propio

d e s e m p e ñ o y proceso (con el proposito de a p r e n d e r acerca de su e n f o q u e y d e s p u é s mejorarlo). Es importante d e s t a c a r que la filosofía del DAS e s meritoria sin importar el m o d e l o de proceso empleado. El a c e n t o general en la dinámica de la organización propia e n los equipos, la colaboración interpersonal y el aprendizaje individual y por equipo c o n d u c e n grupos de proyectos de s o f t w a r e con u n a mayor posibilidad de éxito.

4.3.3 Método de desarrollo de sistemas dinámicos (MDSD) El método de desarrollo de sistemas dinámicos [STA97] e s un e n f o q u e de desarrollo de software ágil que "proporciona un m a r c o de trabajo para construir y m a n t e n e r sistem a s con restricciones de tiempo muy estrechas mediante el e m p l e o de la construc-

TM ción de prototipos incrementales en un a m b i e n t e de proyecto controlado" [CCS02]. Similar a a l g u n o s aspectos del proceso DRA descrito en el capítulo 3, el MDSD sugiere una filosofía t o m a d a de u n a modificación del principio de Pareto. En este c a -

PDF Editor

so, 80 por ciento de la aplicación se p u e d e entregar en 2096 del tiempo que tomaría entregar 100 por ciento de la aplicación (sistema completo).

Al igual que la PE y el DSA, el MDSD sugiere un proceso iterativo de software. Sin

embargo, el enfoque del MDSD en cada iteración sigue la regla del 80 por ciento. Esto es, sólo se necesita el trabajo suficiente para cada in c r e m e n to y para facilitar el

92

PARTE UNO


movimiento hacia el n u e v o incremento. Los detalles restantes se pueden completar posteriormente c u a n d o se c o n o z c a n m á s los requisitos de negocios o c u a n d o los c a m b i o s hayan sido solicitados o ajustados. En la red mundial hay u n a organización (DSDM Consortium, www.dsdm.org) que de m a n e r a colectiva a s u m e el papel de "conservador" del método. Esta organización ha definido un m o d e l o ágil de proceso, llamado el ciclo de vida del MDSD. Este método define tres ciclos iterativos diferentes, a los cuales preceden dos actividades del ciclo de vida adicionales: Estudio defectibilidad:

establece los requisitos básicos de negocio y las restriccio-

n e s asociadas con la aplicación del m é t o d o y para evaluar si la aplicación es una En w w w . c s 3 ¡ n c . com/DSDM.htm

candidata viable para el proceso del MDSD.

uno MOSB.

mitirán que la aplicación proporcione un valor al negocio; también define la arqui-

Estudio de negocios: establece los requisitos funcionales y de información que pertectura básica de la aplicación. Iteración de modelo funcional

produce una serie d e prototipos incrementales que

d e m u e s t r a n la funcionalidad para el cliente (nota: todos los prototipos del MDSD están d i s e ñ a d o s para evolucionar hacia la aplicación entregable). El propósito durante este ciclo iterativo e s recopilar requisitos adicionales mediante la retroalimentación de lo que obtiene el usuario, mientras é s t e trabaja con el prototipo. Iteración de construcción y diseño: revisa la construcción de prototipos d u r a n t e la iteración del m o d e l o funcional para asegurar q u e cada u n o d e ellos ha sido desarrollado de u n a m a n e r a que le permitirá proporcionar un valor operativo de negocios para los usuarios finales. En a l g u n o s casos, la iteración del m o d e l o funcional y el dis e ñ o y la iteración de construcción s u c e d e n e n forma concurrente. implemeniación:

coloca el in c r e m e n to de software m á s reciente (un prototipo

"operacionalizado") en el a m b i e n t e operativo. Se d e b e d e s t a c a r que 1) el incremento p u e d e n o estar 100 por ciento completo o 2) se pueden requerir c a m b i o s c u a n d o el i n c r e m e n to se coloca en el sitio. En cualquier caso, el trabajo de desarrollo del MDSD continúa al regresar a la actividad de iteración del m o d e l o de función. El MDSD s e p u e d e combinar con la PE para obtener un e n f o q u e c o n j u n t o q u e define un m o d e l o sólido de proceso (el ciclo de vida del MDSD) con los a s p e c t o s prácticos (PE) necesarios para construir i n c r e m e n t o s de software. Además, los conceptos del DAS de colaboración y equipos a u t o o r g a n i z a d o s se p u e dTM e n a d a p t a r a un modelo de proceso combinado.

4.3.4 Melé

PDF Editor

Melé (término derivado de una jugada de rugby 10 ) es un m o d e l o ágil de p r o c e s o que desarrollaron Jefff Sutherland y su e q u i p o a principios de la d é c a d a de 1990. En a ñ o s 10 Un grupo de jugadores se alinea alrededor del balón y los compañeros de equipo trabajan juntos (algunas veces de manera violenta) para desplazar el balón hacia el lado contrario del campo de juego

CAPÍTULO 4

93

DESARROLLO ÁGIL

recientes, S c h w a b e r y Beedle [SCH01] h a n p r e s e n t a d o el desarrollo posterior de los m é t o d o s de melé. Los principios de la melé [ADM96] son consistentes con el manifiesto ágil. • Los equipos de trabajo p e q u e ñ o s están o r g a n i z a d o s para "maximizar la comunicación, minimizar los gastos generales y maximizar el h e c h o de c o m p a r tir conocimiento tácito e informal". • El proceso d e b e a d a p t a r s e a los cambios técnicos y de negocios "para asegurar que se produzca el mejor producto posible". • El proceso produce i n c r e m e n t o s frecuentes de s o f t w a r e "los cuales se p u e d e n inspeccionar, ajustar, probar, d o c u m e n t a r y construir". • El trabajo de desarrollo y la g e n t e que lo realiza están divididos en "particion e s o p a q u e t e s de b a j o acoplamiento". • Conforme se construye el producto se realizan p r u e b a s y documentación constantes. • Los procesos de melé proporcionan la "capacidad de declarar un producto com o 'realizado' siempre que e s t o se requiera (porque la competencia acaba de hacer un lanzamiento, p o r q u e la c o m p a ñ í a necesita el dinero, p o r q u e el usuario/cliente necesita las funciones, p o r q u e ya se está en el m o m e n t o e n que se prometió..." [ADM96]. Con los principios de la m e l é se guían las actividades dentro de un p r o c e s o que incorpora las siguientes actividades del m a r c o de trabajo, requisitos, análisis, diseño, evolución y entrega. En c a d a actividad del m a r c o de trabajo las t a r e a s de trabajo suceden d e n t r o del patrón de proceso (tratado en el párrafo siguiente) llamado sprint. El trabajo realizado d e n t r o de un sprint (el n ú m e r o requerido de sprints variará de a c u e r d o con el t a m a ñ o y la complejidad del producto) se adapta al p r o b l e m a y con frecuencia lo modifica e n tiempo real el equipo de melé. En la figura 4.3 se ilustra el flujo general del proceso de melé.

I

"ios m é t e n o s permiten construir un software más suave."

• »Mifce Beetle et al.

")

La melé subraya el uso de un c o n j u n t o de "patrones de proceso de software"

(NOY02] que ha p r o b a d o su efectividad en proyectos con tiempos de entrega m u y re-

TM

ducidos, requisitos c a m b i a n t e s y condiciones críticas en los negocios. Cada u n o de e s t o s p a t r o n e s de p r o c e s o define un conjunto de actividades de desarrollo:

PDF Editor

Retrasos: son una lista que considera la prioridad de los requisitos o característi-

cas de proyecto que proporcionan un valor comercial para el cliente. En cualquier m o m e n t o se p u e d e n agregar e l e m e n t o s a los retrasos (así se introducen los c a m bios). El gerente de producto evalúa los retrasos y actualiza las prioridades de acuerdo con lo requerido.

PARTE UNO

94


Flujo de proceso de la melé.

Retraso de sprint: Características asignadas al sprint

Elementos de retraso expandidos

Melé: reunión diaria de 15 minutos Los miembros del equipo responden a las preguntas básicas 1) ¿Qué hiciste desde la última reunión? 2) ¿Tienes algún obstáculo? 3) ¿Qué harás antes de la próxima reunión?

La nueva funcionalidad

se demuestra al final del sprint

Retraso del producto: Caracteristicas del producto deseadas por el cliente que han recibido prioridad

Sprint: consisle en unidades de Lrabajo que se requieren para satisfacer un requisito definido en los retrasos en un periodo predefinido (el lapso usual e s de 30 días).

CLAVE La melé incorporo un conjunto de potrones de proceso que resalta las prioridades del proyecto, la división del trabajo, las unidades de trabajo, la comunicación y la retroalimentación frecuente del diente.

En esta etapa, los e l e m e n t o s de los retrasos a los que se dirigen las unidades d e trab a j o del sprint están congelados (es decir, d u r a n t e el sprint no se introducen c a m bios). Por lo tanto, el sprint permite a los m i e m b r o s del equipo trabajar e n un a m biente e n f o c a d o al corto plazo, pero estable. Reuniones de melé: s o n reuniones cortas (por lo general de 15 minutos) y las realiza a diario el equipo de melé. Existen tres p r e g u n t a s que plantean y responden todos los m i e m b r o s del equipo. • ¿Qué hiciste d e s d e la última reunión?

TM

• ¿Cuáles obstáculos encontraste? • ¿Qué e s p e r a s lograr para la siguiente reunión del equipo?

PDF Editor

Un líder de equipo, llamado "maestro de la melé", preside la reunión y evalúa las

r e s p u e s t a s de cada persona. Cada reunión de melé ayuda al equipo a descubrir pro-

b l e m a s potenciales tan pronto c o m o sea posible. Estas reuniones diarias también c o n d u c e n a la "socialización del conocimiento" [BEE99] y, por ende, a promover una estructura de equipo con organización propia.

CAPITULO 4

95

DESARROLLO ÁGIL

Demostración:

se entrega el incremento de s o f t w a r e al cliente de forma que éste

d e m u e s t r e y evalúe la funcionalidad implementada. Es importante señalar que la demostración quizá no contenga toda la funcionalidad planeada, sino aquellas funcion e s susceptibles de entregarse dentro del periodo establecido. Beedle y sus colegas [BEE99] p r e s e n t a n un análisis completo de e s t o s p a t r o n e s y establecen: "La MELÉ s u p o n e la existencia del caos...". El patrón de proceso de la melé permite que u n equipo de desarrollo de s o f t w a r e trabaje de m a n e r a exitosa en un m u n d o d o n d e la eliminación de la incertidumbre es imposible.

4.3.5

Cristal

Alistair Cockburn [COC02a] y Jim Highsmith [HIG02b| crearon la familia cristal de los métodos ágiles11 con el fin de lograr un enfoque de desarrollo de s o f t w a r e que coloca u n premio en la "manejabilidad" d u r a n t e lo que Cockburn caracteriza c o m o "un juego cooperativo de inventiva y comunicación con recursos limitados, con u n a m e ta primaria consistente e n la entrega de software útil y en funcionamiento y una meta secundaria de prepararse para el juego siguiente" [CC)C02b]. Para a l c a n z a r la manejabilidad, Cockburn y Highsmith definieron un conjunto de metodologías, cada u n a de ellas con elementos esenciales c o m u n e s a todas, y funciones, p a t r o n e s de proceso, productos de trabajo y prácticas únicas en cada una de ellas. En realidad, la familia cristal es un conjunto de procesos ágiles, los cuales h a n p r o b a d o su efectividad en diferentes tipos de proyectos. El objetivo es permitir que los equipos ágiles seleccionen el m i e m b r o de la familia cristal m á s apropiado para su proyecto y ambiente.

4.3.6

Desarrollo conducido por características (DCC)

El desarrollo conducido por características

(DCC) lo concibieron originalmente Peter

Coad y sus colegas [COA99] c o m o un m o d e l o de proceso práctico para la ingeniería del s o f t w a r e orientada a objetos. Stephen Palmer y John Felsing [PAL02] han extendido y mejorado el trabajo de Coad, al describir un proceso adaptativo y ágil que puede aplicarse en proyectos de software de t a m a ñ o m o d e r a d o y grande. En el contexto del DCC u n a característica "es una función valuada por el cliente que p u e d e implementarse en dos s e m a n a s o m e n o s " [COA99]. La importancia que se le concede a la definición de características proporciona los siguientes beneficios. • C o m o las características son bloques p e q u e ñ o s de funcionalidad entregable, los usuarios las describen con mayor facilidad, p u e d e n e n t e n d e r cTM ó m o éstas se relacionan con otras con mayor rapidez, y p u e d e n revisarlas de mejor m a nera en b ú s q u e d a de ambigüedades, errores u omisiones.

PDF Editor

• Las características s e pueden organizar en un a g r u p a m i e n t o jerárquico relacionado con el negocio.

11 El nombre "cristaI" se deriva de las características de los cristales geológicos, cada uno con su propio color, forma y dureza.

96

PMCTEISNO O-TOOCÍSOCELSOFWIMÍE. • C o m o una característica e s el incremento de s o f t w a r e entregable, el equipo desarrolla características operativas c a d a dos s e m a n a s . • Debido a que las características son p e q u e ñ a s , sus diseños y representaciones de código son m á s fáciles de inspeccionar de m a n e r a efectiva. • La planeación del proyecto, la elaboración de su p r o g r a m a y su rastreo los guía la jerarquía de la característica, e n lugar de hacerlo un conjunto de tareas de ingeniería del software a d a p t a d o en forma arbitraria. Coad y sus colegas [COA99] sugieren la siguiente plantilla p a r a definir u n a característica: el u n d o n d e u n es "una persona, sitio o cosa (incluyendo papeles, m o m e n t o s en el tiempo o intervalos d e tiempo, o descripciones del tipo de catálogo de entrada)". Los ejemplos de las características para u n a aplicación de comercio electrónico podrían ser: Agregar el producto a un carrito de supermercado. Desplegar las especificaciones Almacenar

la información

técnicas de un producto.

de navegación para un cliente.

Un conjunto de características agrupa características relacionadas en categorías relacionadas con el negocio y se define c o m o [COA99]: <-ar, -er, -ir> un Por ejemplo: hacer ¡a venta del producto e s un conjunto de características que podría abarcar las características relacionadas con anterioridad y otras. El enfoque del DCC define cinco actividades de "colaboración" dentro del m a r c o de trabajo (en el DCC é s t a s se llaman "procesos") c o m o se muestra en la figura 4.4.

Desarrollo conducido por características [COA99] (usado con autorización).

TM

PDF Editor (más forma que contenido)

Una lista de características agrupadas en conjuntos y áreas de contenido

Un plan de desarrollo Propietarios de clase Propietarios del conjunto de características

Un paquete de diseño (secuencias)

Función cliente-valor completada

CAPÍTULO 4

DESARROLLO ÁGIL

97

El DCC concede una mayor importancia a las directrices y técnicas de la gestión del proyecto que muchos otros métodos ágiles. Cuando los proyectos crecen en tam a ñ o y complejidad, con frecuencia la gestión ad hoc del proyecto es inadecuada. Resulta esencial para los desarrolladores, sus gerentes y el cliente entender el estatus del proyecto: cuáles logros se h a n tenido y cuáles programas se han encontrado. Si la presión de la fecha límite es significativa, resulta crítico determinar si los incrementos de software (características) están programados de manera apropiada. Para lograrlo el DCC define seis puntos de fijación durante el diseño y la implementación de una característica: "ensayo del diseño, diseño, inspección del diseño, código, inspección del código, promoción de la construcción" [COA99].

4.3.7

Modelado ágü (MA)

En muchas situaciones los ingenieros de software deben construir sistemas grandes y críticos para los negocios. El ámbito y la complejidad de dichos sistemas se deben modelar de forma que 1) todas las circunscripciones entiendan mejor lo que se debe lograr; 2) el problema se divida de manera efectiva entre la gente que lo debe resolver; y 3) la calidad se evalúe en cada paso conforme el sistema se desarrolla y construye. En los últimos 30 años se ha propuesto una amplia variedad de métodos y notación para el modelado de ingeniería del software en el análisis y diseño (tanto arquitectónico como al nivel de componentes). Estos métodos tienen un mérito significativo, pero se ha comprobado que su aplicación enfrenta dificultades y es desafiante poderlos sostener (sobre muchos proyectos). Parte del problema es el "peso" de estos métodos de modelado. Con esto se hace referencia al volumen de notación requerida, el grado de formalismo sugerido, el t a m a ñ o de los modelos para proyectos grandes, y la dificultad para el mantenimiento del modelo conforme ocurren los cambios. Aun así, el modelado del análisis y el diseño tiene un beneficio sustancial para los proyectos grandes: por ninguna otra razón que hacer que estos proyectos sean manejables en el sentido intelectual. ¿Existe un enfoque ágil para el modelado de la ingeniería del software que pudiera proporcionar una alternativa? En el "Sitio oficial del modelado ágil", Scott Ambler [AMB02] describe el modelado ágil (MA) de la siguiente manera: El m o d e l a d o ágil (MA) es u n a tecnología basada e n la práctica para el m o d e l a d o efectivo d e los s i s t e m a s b a s a d o s en software. Dicho d e u n a forma m á s simple, el m o d e l a d o ágil es una colección d e valores, principios y prácticas p a r a el modelado de software que p u e d e aplicarse en un proyecto de desarrollo d e software de u n a m a n e r a efectiva y TM ligera. Los modelos ágiles son m á s efectivos q u e los tradicionales porque son sólo lo suficientemente b u e n o s , n o tienen que ser perfectos [AMB02]:

PDF Editor

Además de los valores consistentes con el manifiesto ágil, Ambler sugiere valor y humildad. Un equipo ágil debe tener el valor para tomar decisiones que ocasionarán el rechazo y la refabricación de un diseño. Debe tener la humildad de reconocer que quienes manejan la tecnología n o tienen todas las respuestas, y que los expertos en negocios y otros participantes de la empresa son dignos de respeto y consideración.

98

PARTE UNO


A p e s a r de que el MA sugiere un arreglo amplio de principios de modelado "esenciales" y "suplementarios", los responsables de q u e el MA sea único son los siguientes [AMB02J: Modelar con un propósito. Un desarrollador que use el MA debe tener u n a m e t a específica en mente (por ejemplo, comunicar información al cliente o ayudarle a entender mejor algún aspecto del software) a n t e s d e crear el modelo. Una vez identificada la meta para el modelo, el tipo de notación que se usará y el grado de detalle requerido serán m á s obvios. Usar múltiples modelos. Existen m u c h o s modelos y notaciones diferentes con los cuales describir el software. Sólo un p e q u e ñ o s u b c o n j u n t o e s esencial para la m a yoría de los proyectos. El MA sugiere que para proporcionar la visión necesaria cada modelo debe presentar un aspecto diferente del sistema, y sólo aquellos m o d e los que proporcionen un valor para la audiencia a la que están dirigidos deben usarse. Viajar ligero. La realización de trabajo de la ingeniería del software requiere con^CONSUO^^.

servar sólo los modelos que proporcionarán valor a largo plazo y descartar el res-

"Viajar ligero"es un enfoque apiopiado paro lodo el trabajo de ingeniería del software. Construir sólo aquellos modelos que proporcionan valor ¿eni más, ni menos

to. Cada producto d e trabajo q u e s e conserve debe recibir mantenimiento conform e se presentan cambios. Esto representa un trabajo q u e reduce la velocidad del equipo. Ambler [AMB02] observa que "cada vez que se decide conservar un modelo se intercambia la agilidad por la conveniencia de tener la información disponible para el equipo de una forma abstracta (por ende, existe u n a posibilidad de mejorar la comunicación dentro del equipo, así c o m o con los propietarios del proyecto)". El contenido es más importante que la representación.

El modelado debe comuni-

car información a la audiencia a la que está dirigido. Un modelo sintácticamente perfecto q u e comunique sólo un poco del contenido útil n o tiene tanto valor c o m o un modelo c o n una notación defectuosa que, sin embargo, c o m u n i q u e un contenid o valioso para su audiencia. Conocer los modelos y las herramientas

con que se crean. Es necesario entender

las fortalezas y debilidades de cada modelo y las h e r r a m i e n t a s con los q u e se creó. Adaptar en forma local. El enfoque del modelado se debe adaptar a las necesidades del equipo ágil.

TM HERRAMIENTAS DE SOFTWARE

PDF Editor Desarrollo ágil

Objetivo: El objetivo de las herramientas del desarrollo ágil es ayudar en uno o más aspectos del desarrollo ágil con énfasis en la facilitación de la generación rápida de software operativo. Estas

V

herramientas también se pueden utilizar cuando se aplican los modelos prescriptivos de proceso (capítulo 3).

Mecánica: La mecánica de las herramientas varía. En general, los conjuntos de herramientas técnicas incluyen apoyo automatizado para la planeación del proyecto, el desarrollo

/

CAPÍTULO 4

99

DESARROLLO ÁGIL

s 3e viso y \ a recopilación d e requisitos, e\ diseño , a generación de código y la realización de pruebas, os representativas:' 2 a c l o m o el desarrollo ágil es un tópico actual, la

gestión d e un proceso óg'A en v a n a s actividades técnicas dentro del proceso. Ideogramic

UML, desarrollado por Ideogramic

(www.ideogramic.com) e s un conjunto d e herramientas

•*rporia d e los vendedores d e herramientas d e

p a r a el UML creado en forma específica p a r a usarlo

ÍCI—-ore pretenden vender herramientas que apoyen el

dentro d e un proceso ágil.

s-TDGue ágil. Las herramientas q u e se presentan a x r r r i u a r i ó n tienen características que las hacen útiles se - a ñ e r a particular p a r a los proyectos ágiles. -

eme, desarrollado por Microtool i microtool.com), proporciona soporte p a r a la

Together Tool Set, distribuido por Borland (www.borland.com o www.togethersoft.com), proporciona un paquete d e herramientas que apoya muchas actividades técnicas dentro de la PE y otros procesos ágiles.

Una filosofía ágil para la ingeniería del software se relaciona con cuatro aspectos clave: la importancia de la organización propia de los equipos, los cuales controlan el trabajo que realizan; comunicación y colaboración entre los miembros del equipo y entre los profesionales y sus clientes; un reconocimiento de que el cambio representa una oportunidad; y un especial cuidado en la entrega rápida del software que satisfaga al cliente. Los modelos de proceso ágil se diseñaron para cumplir con cada uno de estos aspectos. La programación extrema (PE) e s el proceso ágil que m á s se utiliza. Organizada como cuatro actividades del marco de trabajo —planeación, diseño, codificación y pruebas—, la PE sugiere algunas técnicas innovadoras y poderosas que permiten a un equipo ágil crear frecuentes lanzamientos de software al entregar características y funcionalidad que describe y después prioriza el cliente. El desarrollo de software adaptativo (DSA) destaca la colaboración humana y la organización propia del equipo. Organizado con tres actividades del marco de trabajo —especulación, colaboración y aprendizaje—, el DSA utiliza un proceso iterativo que incorpora la planeación del ciclo adaptativo, métodos de recopilación de requisitos relativamente rigurosos y un ciclo iterativo de desarrollo que incorpora grupos enfocados en el cliente y revisiones técnicas formales como mecanismos de retroalimentación en tiempo real. El método de desarrollo de sistemas dinámicos TM (MDSD) define tres diferentes ciclos iterativos —iteración funcional del modelo, iteración de diseño y construcción e implementación— precedidos por dos actividades del ciclo de vida adicionales: estudio de factibilidad y estudio de negocios. El MDSD abo-

PDF Editor

12 Las h e r r a m i e n t a s m e n c i o n a d a s a q u í s o n s ó l o una m u e s t r a d e esta categoría. En casi todos los c a s o s los n o m b r e s son m a r c a s registradas d e s u s respectivos desarrolladores.

100

PARTE UNO


ga por el uso de programas y sugiere que sólo se requiere el trabajo suficiente para cada incremento de software y así facilitar el movimiento hacia el incremento próximo. La melé subraya el uso de un conjunto de patrones de proceso de software que h a n probado su efectividad en proyectos con límites de tiempo muy ajustados, requisitos cambiantes y que s o n críticos para el negocio. Cada patrón de proceso define un c o n j u n t o de tareas de desarrollo y permite al equipo de melé construir un proceso que se adapte a las necesidades del proyecto. Cristal es una familia de modelos ágiles de proceso que pueden adaptarse a las características específicas de un proyecto. Como otros e n f o q u e s ágiles, cristal adopta una estrategia iterativa, pero se ajusta al rigor del proceso para incluir proyectos de t a m a ñ o s y complejidades diferentes. El desarrollo conducido por características (DCC) e s algo m á s "formal" que otros m é t o d o s ágiles, pero a u n así mantiene la agilidad al enfocar al equipo de proyecto e n el desarrollo de características, funciones q u e evalúa el cliente y que se pueden implementar en dos s e m a n a s o menos. El DCC concede una mayor importancia al proyecto y a su gestión que otros e n f o q u e s ágiles. El modelado ágil (MA) sugiere que el modelado es esencial para todos los sistemas, pero que la complejidad, tipo y tam a ñ o del modelo debe ajustarse al software que será construido. Mediante la proposición de u n a serie de principios de m o d e l a d o esenciales y complementarios, el MA proporciona una guía útil para los profesionales durante las tareas de análisis y diseño.

[ADM961 A d v a n c e d D e v e l o p m e n t M e t h o d s , Inc., "Origins of S e r u m " , 1996, h t t p : / / w w w . c o n t r o I chaos.com/. (AG103] T h e Agile Alliance H o m e P a g e , h t t p : / / w w w . a g i l e a l l i a n c e . o r g / h o m e . [AMB02] A m b l e r , S „ " W h a t is Agile M o d e l i n g (AM)?", 2 0 0 2 , h t t p : / / w w w . a g i l e m o d e l i n g . c o m / index.htm. [BEC991 Beck, K., Extreme Programming Explained: Embrace Change, A d d i s o n - W e s l e y , 1999. IBECOla] Beck, K. etal., "Manifestó for Agile Software Development", h t t p : / / w w w . a g i l e m a n i f e s t o . o r g / . (BECOlb] Beck, K. y M. Fowler, Planning Extreme Programming, Addison-Wesley, 2001. [BEE991 Beedle, M. et al., "SCRUM: An e x t e n s i ó n p a t t e r n l a n g u a g e for h y p e r p r o d u c t i v e s o f t w a r e d e v e l o p m e n t " , i n c l u i d o e n . Pattern Languages ofProgram Design 4, A d d i s o n Wesley, L o n g m a n , R e a d i n g , MA, 1999. O b t e n i d o d e h t t p : / / j e f f s u t h e r l a n d . c o m / s c r u m / s c r u m - p l o p . p d f . [BUSOO] B u s c h m a n n , E etal., Pattern-OrientedSoftwareArchitecture, 2 v o l ú m e n e s , Wiley, 1996, 2000. [COA991 C o a d , P , E. L e f e b v r e y J . D e L u c a , lava Modeling in Color withTM UML, P re nt i c e -H a l l, 1999. [COCO 1 ] C o c k b u r n , A. y j . H i g h s m i t h , "Agile S o f t w a r e D e v e l o p m e n t : T h e P e o p l e F a c t o r " , IEEE Computer, vol 34, n ú m . 11, n o v i e m b r e d e 2 0 0 1 , pp. 131-133. [COC02a] C o c k b u r n , A., Agile Sojbware Development, Addison-Wesley, 2002. [COC02bl C o c k b u r n , A., "What is Agile a n d W h a t D o e s It Imply?", p r e s e n t a d o e n el Agile D e v e l o p m e n t S u m m i t e n W e s t m i n s t e r C o l l e g e e n S a l t L a k e City, m a r z o d e 2 0 0 2 , h t t p : / / c r y s t a l methodologies.org/. [CCS02] CS3 C o n s u l t i n g Services, 2 0 0 2 , h t t p : / w w w . c s 3 i n c . c o m / D S D M . h t m . [DEM981 D e M a r c o , T. y T. Lister, Peopleware, 2 a . e d . , Dorset H o u s e , 1998. [DEM02] D e M a r c o , T. y B. B o e h m , "The Agile M e t h o d s Fray", e n IEEE Computer, vol. 35, n ú m . 6, j u n i o d e 2 0 0 2 , pp. 9 0 - 9 2 .

PDF Editor

CAPÍTULO 4

DESARROLLO ÁGIL

101

[FOWOO] Fowler, M. etal., Refactoring: Improving theDesign o/Existing Code, Addison-Wesley, 2000. [FOWOl] Fowler M. y j . Highsmith, "The Agile Manifestó", Software Development Magazine, agosto de 2001, h t t p : / / w w w . s d m a g a z i n e . c o m / d o c u m e n t s / s = 8 4 4 / s d m 0 1 0 8 a . h t m . [FOW02] Fowler, M., "The New Methodology", j u n i o d e 2002, h t t p : / / w w w . m a r t i n f o w l e r . c o m / articles/newMethodology.html#N8B. [H1G98] Highsmith, J., "Life—The Artificial a n d t h e Real", Software Developmcnt, 1998, e n http://www.adaptivesd.com/articles/order.html. [H1G00] H i g h s m i t h , ) . , Adaptive Software Development: An Evolutionaiy Approach lo Managing Complex Systems, Dorset House Publishing, 1998. [HIG01] Highsmith,). (ed.), "The Great M e t h o d o l o g i e s Debate: Part 1", Cutter IT Journal, vol. 14. n ú m . 12, diciembre d e 2001. [HIG02a] Highsmith, J. (ed.), "The Great Methodologies Debate: Part 2", Cutter IT Journal, vol. 15. n ú m . I, e n e r o d e 2002. [HIG02b] Highsmith, )., Agile Software Development Ecosystems, Addison-Wesley, 2002. [JAC02J J a c o b s o n , I, "A R e s o u n d i n g 'Yes' t o Agile Processes—But Also More", Cutter IT Journal, vol. 15, n ú m . 1, e n e r o de 2002, pp. 18-24. [JEFOI] Jeffries, R, etal., ExtremeProgramming Installed, Addison-Wesley, 2001. [NOY02] Noyes, B., "Rugby, Anyone?", Managing Development (una p u b l i c a c i ó n e n linea d e F a w c e t t e Technical Publications), junio de 2002, h t t p : / / w w w . f a w c e t l e . c o m / r e s o u r c e s / m a nagingdev/methodologies/scrum/. [PAL02] Palmer, S. y j . Felsing, A PracticaI Guide to Feature Driven Development, Prentice-Hall, 2002. [SCH01] S c h w a b e r , K. y M Beedle, Agile Software Development withSCRUM, Prentice-Hall, 2001. [SCH02] S c h w a b e r , K, "Agile P r o c e s s e s a n d Self O r g a n i z a t i o n " , Agile Alliance, 2002, http://www.aanpo.org/articles/index. [STA971 S t a p l e t o n , D S D M — D y n a m i c System Development Method: The Method in Practice, Addison Wesley, 1997. [WEL99I Wells, D., "XP—Unit Tests", 1999, h t t p : / / w w w . e x t r e m e p r o g r a m m i n g . o r g / r u l e s / unittests.html.

4.1. L é a s e de n u e v o el "Manifiesto p a r a el d e s a r r o l l o ágil de s o f t w a r e " al principio de e s t e capítulo. ¿El lector p u e d e p e n s a r e n u n a s i t u a c i ó n e n la q u e u n o o m á s d e los c u a t r o " v a l o r e s " p u e d a m e t e r a u n equipo de s o f t w a r e en problemas? 4.2. Describase agilidad (para proyectos d e software) con p a l a b r a s propias. 4.3. ¿Por q u é u n p r o c e s o iterativo facilita m á s m a n e j a r el c a m b i o ? ¿Todos los p r o c e s o s ágiles t r a t a d o s e n este capítulo s o n iterativos? ¿Es posible concluir un p r o y e c t o e n sólo u n a iteración y a ú n así seguir s i e n d o ágil? Expliqúense las respuestas. 4.4. ¿Podría cada uno de los procesos ágiles describirse recurriendo a las actividades genéricas del m a r c o de trabajo m e n c i o n a d a s e n el capítulo 2? Construyase una tabla q u e coloque las actividades genéricas dentro d e las actividades definidas para cada proceso ágil. 4.5. T r á t e s e d e idear un "principio d e agilidad" adicional q u e p u d i e r a a y u d a r a u n a e q u i p o d e TM ingeniería del s o f t w a r e a volverse a ú n m á s m a n e j a b l e . 4.6. S e l e c c i ó n e s e u n principio d e agilidad d e los e n u n c i a d o s d e la s e c c i ó n 4.1 y t r á t e s e de det e r m i n a r si c a d a u n o de los m o d e l o s de p r o c e s o p r e s e n t a d o s e n este capítulo m u e s t r a n el principio.

PDF Editor

4.7. ¿Por q u é c a m b i a n t a n t o los requisitos? D e s p u é s d e todo, ¿la g e n t e n o s a b e lo q u e quiere? 4.8. C o n s i d é r e n s e los s i e t e r a s g o s e n u n c i a d o s e n la s e c c i ó n 4.2.2. O r d é n e n s e los r a s g o s c o n b a s e e n su p e r c e p c i ó n d e s d e lo q u e e s m á s i m p o r t a n t e h a s t a lo q u e t i e n e m e n o r i m p o r t a n c i a . 4.9. La m a y o r í a de l o s p r o c e s o s ágiles r e c o m i e n d a n la c o m u n i c a c i ó n c a r a a c a r a . Aun e n la actualidad, los m i e m b r o s de u n e q u i p o d e s o f t w a r e y s u s clientes p u e d e n e s t a r g e o g r á f i c a m e n -

102

PARTE UNO


te separados entre sí. ¿Esto implica la necesidad de evitar la separación p e n s a r en formas de contrarrestar este problema?

geográfica?

¿Es posible

4 . 1 0 . Escríbase una historia del usuario para PE que describa los "sitios favoritos" o la característica de "favoritos" disponible en la mayoría de los exploradores Web. 4 . 1 1 . ¿Qué es u n a solución pico en PE? 4 . 1 2 . D e s c r í b a n s e los c o n c e p t o s d e PE refabricación propias.

y programación

en pareja c o n p a l a b r a s

4 . 1 3 . Utilícese la plantilla del patrón d e proceso p r e s e n t a d a en el capitulo 2 y desarróllese un p a t r ó n d e p r o c e s o p a r a cualquiera d e los p a t r o n e s d e melé p r e s e n t a d o s en la sección 4.3.4. 4 . 1 4 . ¿Por qué se dice que cristal es una familia de métodos ágiles? 4 . 1 5 . Utilícese la plantilla d e característica p a r a el DCC descrito en la sección 4.3.6 y defínase un conjunto de características d e un explorador Web. Ahora desarróllese un c o n j u n t o d e características para el conjunto m e n c i o n a d o antes. 4 . 1 6 . Visítese el sitio oficial del m o d e l a d o ágil y h á g a s e u n a lista completa d e t o d o s los principios de MA esenciales y complementarios.

O T R A S L E C T U R A S Y F U E N T E S DE I N F O R M A C I Ó N La filosofía total y los principios s u b y a c e n t e s del desarrollo ágil de software se consideran a profundidad en los libros de Ambler (Agile Modeling, Wiley, 2002), Beck [BEC99], Cockburn [COC02] y Highsmith [HlG02bl. Los libros de Beck 1BEC99], Jef'fries y s u s colegas (Extreme Programming Installed, AddisonWesley, 2000), Succi y Marchesi (Extreme Programming Examined, Addison Wesley, 2001), Newkirk y Martin (Extreme Programming in Practice, Addison Wesley, 2001) y Aver y s u s colegas (.Extreme Programming Applied: Play lo Win, Addison-Wesley, 2001) ofrecen u n a exposición de los pros y contras d e la PE junto con una guía de la mejor forma de aplicarla. McBreen (Questioning Extreme Programming, Addison Wesley, 2003) a s u m e una posición crítica con respecto a la PE, al definir c u á n d o y d ó n d e ésta es apropiada. Por otro lado, McBreen (Pair Programming Iluminated, Addison-Wesley, 2003) presenta u n a consideración profunda d e la programación en pareja. Fowler y sus colegas (Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999) se enfoca en un nivel muy detallado en el importante concepto de la refabricación dentro d e la PE. McBreen (Software Craftsmanship: The New Imperative, Addison-Wesley, 2001) analiza el arle del software y aboga a favor de las alternativas ágiles y la ingeniería d e software tradicional. El DSA lo aborda a profundidad Highsmith [HIG001. Stapetlon realizó un tratamiento valioso del MDSD (DSDM: The Method in Practice, Addison-Wesley, 1997). Palmer y Felsing [PAL02] p r e s e n t a n un tratamiento detallado del DCC. Carmichael y Haywood (Better Software Faster. Prentice-Hall, 2002) presentan otro útil tratamiento del DCC que incluye un recuento paso a pas o por la mecánica del proceso. Schwaber y s u s colegas (Agile Software Development with SCRUM, Prentice-Hall, 2001) p r e s e n t a n un detallado tratamiento d e la melé. Martin (Agile Software Development, Prentice-Hall, 2003) analiza los principios, patrones y prácticas ágiles p o n i e n d o especial cuidado en la PE. Poppendieck y TM Poppendieck (Lean Development; An Agile Toolkit for Software Development Managers, Addison-Wesley, 2003) proporciona las directrices para m a n e j a r y controlar los proyectos ágiles. Highsmith (Agile Software Development Ecosyslems, Addison-Wesley, 2002) presenta u n a valiosa visión de principios, proc e s o s y prácticas ágiles. . En Internet se dispone de una amplia variedad d e fuentes d e información sobre el desarrollo ágil de software. En el sitio w e b de SEPA se p u e d e encontrar u n a lista actualizada de referencias en la red mundial, las cuales son relevantes p a r a el p r o c e s o ágil: http://www.mhhe.com/pressman.

PDF Editor

PARTE

Dos P R Á C T I C A DE LA I N G E N I E R Í A DEL S O F T W A R E

E

n esta parte de Ingeniería del software: un enfoque práctico se apren-

derá acerca de los principios, conceptos y métodos que c o m p r e n d e la práctica de la ingeniería del software. En los capítulos siguientes se

abordarán las siguientes preguntas: •

¿Qué conceptos y principios guían la práctica de la ingeniería del software? •

•

;|wfc^P¡

¿De qué m a n e r a la ingeniería de sistemas conduce a una ingeniería del software efectiva?

•

¿Qué e s la ingeniería de requisitos, y cuáles son los conceptos relacionados que conducen a un buen análisis de requisitos?

•

¿Cómo se crea el modelo de análisis y cuáles son sus elementos?

•

¿Qué es ingeniería de diseño y cuáles son los conceptos relacionados que conducen a u n b u e n diseño?

•

¿Qué conceptos, modelos y métodos se utilizan para crear diseños arquitectónicos, de interfaz y al nivel de componentes?

•

¿Qué estrategias son aplicables a la realización de p r u e b a s de software?

•

TM ¿Qué m é t o d o s se utilizan para diseñar casos de prueba efectivos?

•

¿Qué mediciones y métricas s e usan para establecer la calidad del análi-

PDF Editor sis y los modelos de diseño, código fuente y casos de prueba?

Una vez que estas preguntas hayan sido respondidas, habrá u n a mejor

preparación para la práctica de la ingeniería del software.

103

C A P Í T U L O

5 CONCEPTOS CLAVE principios de: el análisis . . . 1 1 7 el despliegue 1 2 6

LA PRÁCTICA: U N A VISIÓN GENÉRICA

E

n un libro que explora las vidas y los p e n s a m i e n t o s de los ingenieros de software, Ellen Ullman [ULL97] representa un f r a g m e n t o de vida al relatar los p e n s a m i e n t o s de un practicante b a j o presión:

N o t e n g o i d e a d e q u é h o r a e s . No h a y v e n t a n a s en e s t a oficina, ¡tampoco reloj, s ó l o el LHD p a r p a d e a n t e e n rojo d e u n h o r n o d e m i c r o o n d a s , el cual p a r p a d e a 12:00, 12:00,

el diseña . . . 1 1 9

12:00, 12:00. Joel y y o h e m o s e s t a d o p r o g r a m a n d o p o r días. T e n e m o s u n "bicho", el

el m o d e l a d a ágH

n e c i o d e m o n i o d e u n error. Por e s o la p u l s a c i ó n r o j a s i n t i e m p o s e s i e n t e bien, c o m o 121

u n a lectura d e n u e s t r o s c e r e b r o s , los c u a l e s s e h a n s i n c r o n i z a d o d e a l g u n a m a n e r a

la codificación 1 2 3

a la m i s m a v e l o c i d a d del p a r p a d e o . . .

la comunicación

¿ E n q u é e s t a m o s t r a b a j a n d o ? . . . Los d e t a l l e s s e m e e s c a p a n a h o r a . P o d r í a m o s e s t a r

109

la ingeniería del s o f t w a r e 1 0 7 la planeación 1 1 3 las pruebas .124 preguntas WSHH

115

resolución d e problemas

106

a y u d a n d o a g e n t e p o b r e y e n f e r m a o a j u s f a n d o u n a serie d e r u t i n a s d e b a j o nivel p a r a verificar bits en u n p r o t o c o l o d e u n a b a s e d e d a t o s distribuida, n o m e i m p o r t a . M e d e bería i m p o r t a r ; e n o t r a p a r t e d e m í s e r

m á s tarde, quizá c u a n d o s a l g a m o s de este-

c u a r t o llen o d e c o m p u t a d o r a s — m e i m p o r t a r á m u c h o p o r q u é , p a r a q u i é n y c o n q u é p r o p ó s i t o e s t o y e s c r i b i e n d o s o f t w a r e . P e r o a h o r a n o . He p a s a d o a t r a v é s d e u n a m e m b r a n a d o n d e el m u n d o real y s u s u s o s y a n o i m p o r t a n . S o y u n i n g e n i e r o d e s o f t ware...

Sin duda, una imagen oscura d e la práctica de la ingeniería del software, p e r o con la que, d e s p u é s de reflexionar, m u c h o s de los lectores de e s t e libro serán c a p a c e s de identificarse.

¿ Q u é e s ? La práctica es un amplio arreglo de conceptos, principios, métodos y herramientas que deben p considerarse cuando se planea y desarrolla el software. Representa los detalles -las consideraciones técnicas y los cómos- que están bajo la superficie del proceso de software: las cosas que se necesitarán para realmente construir software de computadora de alfa calidad. ¿ Q u i é n lo h a c e ? La práctica de la ingeniería del software la aplican los ingenieros de software y sus gerentes. ¿ P o r q u é e s i m p o r t a n t e ? El proceso del software proporciona a todos los involucrados en la creación de un sistema o producto basado en

computadora un mapa del camino para llegar de manera exitosa a su destino. La práctica proporciona los detalles que se necesitan para transitar a lo largo del camino. Indica dónde están ubicados los puentes, los bloqueos del camino y los obstáculos. Ayuda a entender los conceptos y principios que se deben comprender y seguir para conducir de manera TM segura y rápida. Enseña cómo conducir, dónde reducir y dónde aumentar la velocidad. En el contexto de la ingeniería del software, la práctica es lo que se realiza a diario mientras el software evoluciona desde una idea hasta una realidad, ¿ C u á l e s s o n los p a s o s ? Existen tres elementos de la práctica que se aplican sin importar el modelo de proceso que se escoja. Éstos son los

PDF Editor 104

CAPÍTULO 5

105

LA P R Á C T I C A : U N A VISIÓN G E N É R I C A

^CDKCptos, los principios y los métodos. Un cuarto elemento de la práctica -las herramientasapoya la aplicación de los métodos. e s el p r o d u c t o o b t e n i d o ? La práctica - : .ye ias actividades técnicas que producen - o ; = os productos de trabajo definidos por el cito de proceso del software que se ha elegi-

puedo estar seguro de que lo he k e c h o c o r r e c t a m e n t e ? Primero se

comprender con firmeza los conceptos y principios aplicables al trabajo que se realiza en el momento (por ejemplo, el diseño). Después es preciso asegurarse que se ha seleccionado un método apropiado para el trabajo; se debe tener la certeza que se ha entendido la forma de aplicar el método y el uso de las herramientas automatizadas cuando éstas son apropiadas para la tarea, y se debe ser firme en la necesidad de usar técnicas para asegurar la calidad de los productos de trabajo que se produzcan.

Las p e r s o n a s q u e crean s o f t w a r e de c o m p u t a d o r a practican el arte, la maestría o la disciplina 1 llamada ingeniería del software. Pero, ¿qué es la "práctica" d e la ingeniería del software? En un sentido genérico, la práctica e s u n a colección de conceptos, principios, m é t o d o s y h e r r a m i e n t a s a las q u e un ingeniero de s o f t w a r e recurre a diario. La práctica permite a los g e r e n t e s coordinar proyectos de s o f t w a r e e ingenieros de la especialidad para construir p r o g r a m a s de c o m p u t a d o r a . La práctica multiplica un modelo de proceso de s o f t w a r e con los c ó m o s técnicos y de gestión necesarios para realizar el trabajo. La práctica transforma un e n f o q u e fortuito e n algo m á s organizado, m á s efectivo y con m á s probabilidades de alcanzar el éxito.

5.1

L A P R Á C T I C A P E LA I N G E N I E R Í A P E L S O F T W A R E En el capítulo 2 se introdujo un m o d e l o de proceso de s o f t w a r e genérico c o m p u e s to de una serie de actividades que establecen un m a r c o de trabajo para la práctica de la ingeniería del software. Las actividades genéricas del marco de trabajo —comu nicación, planeación, modelado, construcción y despliegue—y las actividades s o m brilla establecen la arquitectura de u n a esqueleto para el trabajo de ingeniería del software. Todos los modelos de proceso de s o f t w a r e p r e s e n t a d o s e n los capítulos 3 y 4 pueden organizarse en este esqueleto arquitectónico. ¿Pero qué cabida tiene ahí la práctica de la ingeniería del software? En las secciones siguientes se considerarán los conceptos y principios genéricos que se aplican a las actividades del m a r c o de trabajo. 2

TM

PDF Editor 1

2

Algunos escritores utilizan uno de estos términos y excluyen los otros. En realidad, la ingeniería del

software es las tres cosas a la vez. Se exhorta al lector para que revise las secciones relevantes dentro de este capítulo, conforme se discutan los métodos específicos de la ingeniería del software y las actividades sombrilla en los capítulos posteriores del libro

106

PARTE DOS

5.1.1 ÔNSEJO^

Se podría orgumentar que el enfoque de Polya consiste en simple sentido común. Es verdad. Peio es sorprendente la frecuencia con ta que el sentido común no es común en el mundo del software.

PRÁCTICA DE LA INGENIERÍA DEL SOFTWARE

La e s e n c i a d e la práctica

En un libro clásico, How to Solve It, escrito antes de que existieran las computadoras modernas, George Polya [POL45] puntualizó la esencia de la resolución de problemas y, en consecuencia, la esencia de la práctica de la ingeniería del software: 1. Entender el problema (comunicación y análisis). 2 . Planear una solución (modelado y diseño de software). 3. Llevar a cabo el plan (generación de código). 4. Examinar el resultado para probar la precisión (realización de pruebas y aseguramiento de la calidad). En el contexto de la ingeniería del software estos pasos de sentido común conducen a una serie de preguntas esenciales [adaptadas de POL45): Entender el p r o b l e m a . • ¿A quién le interesa la solución del problema? Es decir, ¿quiénes son los clientes? • ¿Cuáles aspectos se desconocen? ¿Qué datos, funciones, características y comportamientos se requieren para resolver de manera apropiada el problema? • ¿El problema puede dividirse en categorías? ¿Es posible representar problemas menores que puedan entenderse con mayor facilidad? • ¿El problema puede representarse de manera gráfica? ¿Se puede crear un modelo de análisis? P l a n e a r la s o l u c i ó n . • ¿Se habían visto problemas similares antes? ¿Existen patrones reconocibles en una solución potencial? ¿Hay un software existente que implemente los datos, las funciones, las características y los comportamientos que se requieren? • ¿Se ha resuelto un problema similar? Si e s así, ¿los elementos de la solución pueden reutilizarse? • ¿Sepueden definirlos subproblemas? Si es así, ¿las soluciones para los subproblemas parecen fáciles? • ¿Se puede representar una solución de modo que conduzca TM a una implementación efectiva? ¿Se puede crear un modelo de diseño? Llevar a c a b o e l plan.

PDF Editor

• ¿La solución marcha conforme al plan? ¿El código fuente se puede seguir conforme al modelo de diseño? • ¿Es probable que cada parte de la solución del componente sea correcta? ¿Se ha revisado el diseño y el código, o mejor aún, se han aplicado al algoritmo pruebas de corrección?

CAPÍTULO 5

107


E x a m i n a r el r e s u l t a d o . • ¿Es posible probar cada parte de la solución del componente?

¿Se ha implemen-

t a d o u n a estrategia de prueba razonable? • ¿La solución produce resultados acordes con los datos, funciones, comportamientos

rasgos y

que se requieren? ¿El s o f t w a r e ha sido validado contra todos

los requisitos de los clientes? "En la solución de codn problema existe un grano de descubrimiento." George Polya

5.1.2

Principios e s e n c i a l e s

El diccionario define la palabra principio c o m o "una ley o supuesto importante que se requiere e n u n sistema de pensamiento". A través de e s t e libro se e x a m i n a n principios en m u c h o s grados diferentes de abstracción. Algunos se e n f o c a n en la ingeniería del software c o m o u n todo, otros consideran u n a actividad genérica y específica del m a r c o de trabajo (por ejemplo, comunicación con el cliente), y otros se c e n tran en acciones d e la ingeniería del s o f t w a r e (como diseño arquitectónico) o t a r e a s técnicas (escribir un escenario de uso). Sin importar qué tan específicos son, los principios ayudan a establecer un conjunto sólido de práctica de ingeniería del software. Por esa razón s o n importantes. David Hooker [H0096] ha propuesto siete principios esenciales, los cuales se e n f o c a n en la práctica de la ingeniería del s o f t w a r e c o m o un todo, que se reproducen enseguida. 3 El p r i m e r p r i n c i p i o : la razón por la que todo existe Un sistema de s o f t w a r e existe por u n a razón: para ofrecer un valor a sus usuarios. i m amenzat un i é software, i esa seguro tun ¡de negocios Í os usuarios i «abren é/.

Todas las decisiones deben t o m a r s e con e s t o en mente. Antes de especificar un requisito de un sistema, a n t e s de señalar u n a pieza de funcionalidad del sistema, a n t e s de determinar las p l a t a f o r m a s del h a r d w a r e o los procesos de desarrollo, u n o d e b e hacerse preguntas c o m o : ¿esto agrega u n valor real al sistema? Si la respuesta es negativa n o s e debe hacer. Todos los d e m á s principios están a p o y a d o s e n éste. El s e g u n d o p r i n c i p i o : MS (mantenerlo

simple)

El diseño de s o f t w a r e n o es un proceso fortuito. Existen m u c h o s factores que deben considerarse en cualquier e s f u e r z o de diseño. Todo el diseño debe ser tan simple como sea posible, pero no más simple. Esto facilita u n sistema de m á s fácil comprensión y TM entendimiento. Esto no quiere decir que las características, h a s t a las internas, deban descartarse en n o m b r e de la simplicidad. Además, los diseños m á s elegantes por lo

PDF Editor

general s o n los m á s simples. Simple t a m p o c o significa "rápido y malo". De hecho, se

3

Reproducido con permiso del autor [H00961. Hooker define patrones para e s t o s principios en:

http://c2.com/cgi/wiki7SevenPrinciplesOfSoftwareDevelopment

108

PARTE DOS


requiere de m u c h a reflexión y trabajo sobre múltiples iteraciones para simplificar. El resultado b u s c a d o es un s o f t w a r e que se m a n t e n g a y sea m e n o s p r o p e n s o al error. 'Existe cierta majestuosidad en la simplicidad, la cual está muy por encima de la curiosidad del ingenio." Alexander Pope ( 1 6 8 8 - 1 7 4 4 ) El t e r c e r p r i n c i p i o : mantener

¡a visión

Una visión clara es esencial para el éxito de un proyecto de software. Sin la visión clara el proyecto podría terminar con "dos [o más] significados" en uno. Sin u n a integridad conceptual u n sistema a m e n a z a con tornarse en una m a s a confusa de diseños incompatibles, unida por u n tipo i n a d e c u a d o de tornillos... Arriesgar la visión arquitectónica de u n sistema de s o f t w a r e debilita y al final r o m p e h a s t a un sistema bien diseñado. Tener a un arquitecto capaz de m a n t e n e r la

\

CLAVE

visión y reforzar lo acordado ayuda al a s e g u r a m i e n t o de que u n proyecto de softw a r e sea exitoso. El c u a r t o p r i n c i p i o : lo que uno produzca,

otros lo consumirán

En muy pocas ocasiones un sistema de s o f t w a r e con fuerza industrial se construye y utiliza de m a n e r a aislada. De alguna u otra forma, alguien m á s utilizará, m a n t e n -

Si el software tiene un valor, acto cambiará a lo largo de su vida útil. Por esa razón, el software debe construirse d e tormo que s e le puedo dor

drá, d o c u m e n t a r á o d e p e n d e r á de su capacidad de e n t e n d e r el sistema. Por lo tanto,

mantenimiento.

Tal vez alguien tenga que depurar el código escrito y eso lo convertirá en un u s u a rio del código. El h e c h o de facilitar el trabajo a otro agrega valor al sistema.

siempre d e b e especificarse, diseñarse e implementarse con la idea de q u e alguien m á s tendrá que e n t e n d e r lo que se realice. La audiencia de cualquier producto de software es potencialmente grande, por lo que se debe especificar t o m a n d o en c u e n ta a los usuarios. Se d e b e diseñar teniendo e n m e n t e a q u i e n e s lo implementen, así c o m o codificar c o n s i d e r a n d o a aquellos que deben m a n t e n e r y extender el sistema.

El q u i n t o p r i n c i p i o : estar abierto

al futuro

Un sistema con u n a larga vida tiene m á s valor. En los ambientes computacionales de la actualidad, e n los que las especificaciones cambian a cada m o m e n t o y las plataformas de h a r d w a r e s o n obsoletas d e s p u é s de algunos meses, la vida del s o f t w a re se mide, de m o d o típico, en m e s e s en lugar de años. No obstante, los verdaderos sistemas de software "con fuerza industrial" deben durar m á s tiempo. Estos sistemas t e n d r á n éxito si están listos para adaptarse a éstos y otros cambios. Los sistemas que logran el éxito son aquellos que h a n sido diseñados de esta m a n eTM r a d e s d e el principio. Nunca se debe diseñar para llegar a una esquina. Uno siempre se debe preguntar: "¿qué tal si?", y prepararse para t o d a s las r e s p u e s t a s posibles, al crear sistemas que

PDF Editor

resuelvan el problema general, no u n problema específico. 4 Es m u y probable que esto c o n d u z c a a la reutilización de un sistema entero.

4

Nota del autor: esta recomendación puede ser peligrosa si se lleva hasta el extremo. El diseño para el "problema general'' algunas veces requiere compromisos de desempeño y puede implicar un mayor esfuerzo para el proyecto.

CAPÍTULO 5

LA P R Á C T I C A U N A VISIÓN GENÉRICA

El s e x t o principio: planear

109

para la reutilización

La reutilización ahorra tiempo y esfuerzo. 5 Al alcanzar un alto grado de reutilización se logra una de las metas m á s difíciles en el desarrollo de un sistema de software. La reutilización de código y diseños ha sido proclamada como un beneficio importante del uso de tecnologías orientadas a objetos. Sin embargo, la recuperación de la inversión n o e s automática. Las posibilidades de reutilización que proporciona la programación orientada a objetos (o convencional) se podrán considerar si se tiene una visión a futuro y una planeación. Existen m u c h a s técnicas para llevar a cabo la reutilización en cada etapa del proceso de desarrollo del sistema; las relativas al diseño detallado y al nivel de código son muy conocidas y están bien documentadas. La nueva bibliografía se está enfocando en la reutilización del diseño en la forma de patrones de software. Sin embargo, esto es sólo una parte de la batalla. La comunicación de oportunidades para la reutilización a otros integrantes de la organización es primordial. ¿Cómo se puede reutilizar algo cuya existencia se ignora? La planeación adelantada para la reutilización reduce el costo e incrementa el valor de los componentes reutilizablesy los sistemas en que dichos componentes se incorporan. El s é p t i m o p r i n c i p i o : pensar Este último principio tal vez sea el que m á s se pasa por alto. Casi siempre, cuando se tiene un pensamiento claro y completo antes de la acción, se producen los mejores resultados. Cuando se reflexiona acerca de algo existe una mayor probabilidad de hacerlo bien. Siempre se obtiene conocimiento de la manera de hacerlo bien de nuevo. Si se piensa en algo y aun así se hace mal, esto se convierte en una experiencia valiosa. Un efecto colateral del pensamiento es aprender a reconucer, cuando alguien n o sabe algo, en qué punto se puede investigar la respuesta. Cuando el pensamiento claro se ha introducido en el sistema es cuando surge su valor real. La aplicación de los primeros seis principios requiere una reflexión intensa, por lo que las recompens a s potenciales son enormes. Si todos los ingenieros de software y todos los equipos de desarrollo tan sólo siguieran los siete principios de Hooker, muchas de las dificultades que se han expe rimentado durante la construcción de sistemas complejos basados en computadora se podrían eliminar.

Antes de que los requisitos del cliente puedan analizarse, modelarse o especificarse, éstos deben recopilarse por medio de u n a actividad de comunicación TM (también llamada obtención de requisitos). Un cliente tiene un problema que se puede ajustar a

PDF Editor

Nota del autor: aunque esto es cierto para quienes reutilizan el software en proyectos futuros, la reutilización puede resultar cara para quienes deben diseñar y construir componentes reutilizables. Algunos estudios indican que el diseño y la construcción de componentes reutilizables pueden costar entre 25 y 200 por ciento más que el software solicitado En algunos casos, la diferencia de costo no se puede justificar.

110

PARTE DOS


u n a solución b a s a d a en c o m p u t a d o r a . Un desarrollador responde a la solicitud c J ayuda del cliente. La comunicación ha c o m e n z a d o . Pero el c a m i n o desde la c o m u l nicación hasta el entendimiento suele estar lleno de baches. La comunicación efectiva (entre pares técnicos, con el cliente u otros participantes del software y con los gerentes de proyecto) está entre las actividades m á s desafiantes! que enfrenta un ingeniero de software. En este contexto se examinan los principio* I conceptos de comunicación de acuerdo con la manera en que se aplican en la c o m a l nicación con el cliente. Sin embargo, m u c h o s de los principios se aplican del m i s j n J m o d o a las formas de comunicación que ocurren dentro de un proyecto de software I P r i n c i p i o # 1 : Escuchar.

Se d e b e centrar la atención en las palabras de q u i e - |

habla, en v e z de formular la respuesta a dichas palabras. Es necesario pedir u r J explicación si algo no está claro, p e r o d e b e n evitarse las interrupciones constantes J ^ÔNSEJO^^-

Nunca se debe ser conflictivo con palabras o actitudes (por ejemplo, dirigir la m i r i - l da a los lados o sacudir la cabeza) c u a n d o u n a persona habla.

Antes de comunicar se debe estar seguro de entender el punto de vista de lo olio paite, saber un poco (le sus necesidades, y entonces opinar.

P r i n c i p i o #2: Prepararse

antes

de comunicar.

Se d e b e invertir algún tiemp J

en e n t e n d e r el problema a n t e s de reunirse con otros. Si es necesario, se p u e d e r e a J lizar una investigación para e n t e n d e r el negocio y dominar la jerga. Si se tiene la re~-l ponsabilidad de conducir la reunión, e s r e c o m e n d a b l e preparar u n a agenda del d J a n t e s de la junta. P r i n c i p i o # 3 : Alguien

debe facilitar

la actividad.

Cualquier reunión de corr.--|

nicación d e b e tener un líder o mediador 1) para m a n t e n e r una conversación dins-i mica y en una dirección productiva; 2) para mediar e n cualquier conflicto que o c a - I rra; 3) para a s e g u r a r que se sigan los otros principios. P r i n c i p i o # 4 : La comunicación

cara a cara es 1o mejor.

Pero, por lo general,

funciona mejor c u a n d o está presente otra representación de la información relevante. Por ejemplo, u n participante podría crear un e s q u e m a o un d o c u m e n t o que sirva c o m o foco de la discusión. "Los preguntas y las respuestas llanas forman el comino más corto hacia la mayoría de las perplejidades." Mork Twaln P r i n c i p i o #5: Tomar

notas

y documentar

las decisiones.

Las c o s a s suelen

caer e n malentendidos. Alguien que participe en la comunicación d e b e servir c o m o "grabadora" y escribir todos los p u n t o s y decisiones importantes. P r i n c i p i o #6: Buscar

la colaboración.

TM La colaboración y el c o n s e n s o se pre-

s e n t a n c u a n d o el conocimiento colectivo de los miembros del equipo se combina

PDF Editor

para describir las funciones o características del producto o sistema. Cada pequeña colaboración sirve para construir confianza entre los miembros del equipo y crear una meta c o m ú n p a r a dicho equipo. P r i n c i p i o # 7 : Conservar

el enfoque,

examinar

un módulo

a la vez. Entre

m á s gente esté implicada e n una comunicación, m á s posibilidades existen de que la

CAPÍTULO 5

111

LA P R Á C T I C A : U N A VISIÓN GENÉRICA

discusión salte de un tópico al siguiente. El mediador debe m a n t e n e r la conversación centrada en un módulo sin dejar un t e m a h a s t a que éste haya sido resuelto (sin embargo, véase el principio #9). INFORMACIÓN

La diferencia entre clientes y usuarios tíñales Los ingenieros d e software se comunican con

proporciona los requisitos básicos del producto; 4)

muchos participantes diferentes, pero los clientes

coordina los recursos económicos p a r a el proyecto. En un

finales tienen el impacto más significativo

negocio d e productos o sistemas, con frecuencia el cliente

el trabajo técnico que sigue. En algunos casos el

es el departamento de mercadotecnia. En un ambiente d e

v el usuario son uno mismo, pero en muchos

TI el cliente p u e d e ser un componente o departamento del

el cliente y el usuario final son personas

negocio.

, que trabajan p a r a diferentes administradores en organizaciones d e negocios.

Un usuario final es la persona o grupo que: 1) en realidad

es la persona o g r u p o que: 1) en un inicio el software q u e se va a construir; 2) define los

usará el software q u e se construye p a r a alcanzar algún propósito d e negocios, y 2) definirá los detalles operativos del software d e forma que el propósito del negocio pueda alcanzarse.

generales d e negocios p a r a el software; 3)

P r i n c i p i o # 8 : Si algo no está claro, se hace un dibujo. La comunicación verbal sólo llega hasta cierto punto. Con frecuencia un e s q u e m a o figura puede proporcionar claridad c u a n d o las palabras fallan al realizar su trabajo. P r i n c i p i o # 9 : a) Una vez que se llega a un acuerdo tinuar;

b) si no se puede

llegar

a un acuerdo,

sobre algo, se debe con-

se debe

continuar;

c) si una

característica o Junción no está clara y no se puede clarificar en el momento, se debe continuar. La comunicación, c o m o cualquier actividad de ingeniería del software, requiere de tiempo. En lugar de que se itere sin fin, los participantes deben reconocer que hay muchos tópicos que requieren análisis (véase el principio #2) y mi pasa si i se p e d e i m arreglo le en

que "continuar" algunas veces e s la mejor forma agilitar la comunicación. P r i n c i p i o # 1 0 : La negociación mejor

cuando

ambas

partes

no es un concurso

ganan.

o un juego.

Funciona

En m u c h a s ocasiones los ingenieros de soft

w a r e y el cliente deben negociar funciones y características, prioridades y fechas de

con el

entrega. Si el equipo ha colaborado de buena forma, todas las partes tienen una meta común. Por lo tanto, la negociación d e m a n d a r á el compromiso de todas las partes.

HOGARSEGURO

A EÜj j

Errores de comunicación El e s c e n a r i o : Lugar d e t r a b a j o

TM La c o n v e r s a c i ó n :

PDF Editor d e ingeniería del software.

a c t o r e s : Jamie Lazar, miembro del equipo d e

Ed: ¿Qué han oído acerca d e este proyecto de HogarSeguro?

Vinod Raman, miembro del equipo d e

V i n o d : La reunión de inicio está p r o g r a m a d a p a r a la

Ed Robbins, miembro del equipo d e software.

próxima semana.

112

PARTE DOS


J a m i e : Yo y a he investigado un poco, pero no m e fue

h a g a m o s algo d e tarea en esta á r e a del producto antes

bien.

d e la reunión de inicio. Doug dijo q u e quería q u e "colaboráramos" con nuestro cliente, así q u e será mejor

Ed: ¿Qué quieres decir? J a m i e : Bueno, le hice una llamada a Usa Pérez, la

q u e a p r e n d a m o s cómo hacerlo. Ed: Probablemente sería mejor q u e fuéramos a su

responsable d e mercadotecnia en este asunto.

oficina. Las llamadas telefónicas n o funcionan p a r a este

V i n o d : ¿Y...? J a m i e : Yo quería que m e dijera algo sobre las características y funciones d e HogarSeguro...

ese tipo d e

cosas. En lugar de eso, comenzó a hacerme preguntas

tipo d e asuntos. J a m i e : Ambos están en lo correcto. Debemos actuar ¡untos o nuestras primeras comunicaciones serán un lío.

sobre seguridad d e sistemas, vigilancia d e sistemas... no

V i n o d : Vi que Doug leía un libro sobre "ingeniería d e

soy una experta.

requisitos". Podría apostar q u e ahí se enlistan algunos

V i n o d : ¿ Q u é te dice eso?

principios p a r a la buena comunicación. Se lo voy a pedir prestado m a ñ a n a .

(Jamie se encoge d e hombros.) V i n o d : Q u e mercadotecnia nos necesitará p a r a q u e

actuemos como consultores y que será mejor que

J a m i e : Buena i d e a . . . después nos puedes enseñar. V i n o d ( s o n r i e n d o ) : Sí, claro.

C O N J U N T O DE TAREAS

Conjunto de tareas genéricas para la comunicación 1. Identificar al cliente primario y otros

•

participantes (sección 7.3.1).

•

2. Reunirse con el cliente primario p a r a

Las necesidades y valores del negocio.

•

Las características y necesidades del usuario final.

•

Las salidas visibles q u e se hayan requerido p a r a

•

Características, funciones y comportamientos

Riesgos d e negocios definidos por el cliente (sección 25.3).

ó.

Desarrollar una breve descripción escrita (por ejemplo, una serie d e listas) d e escenarios,

el usuario. •

Salidas y entradas resultantes.

importantes del software.

las "preguntas libres d e contexto" (sección 7.3.4), las cuales definen: •

%

salidas/entradas, características/funciones y riesgos.

Las restricciones del negocio.

7.

Iterar con el cliente p a r a refinar los escenarios,

8.

Asignar prioridades definidas por el cliente a c a d a

salidas/entradas, características/funciones y riesgos. 3.

Desarrollar un enunciado escrito de una página sobre el ámbito del proyecto, el cual está sujeto a revisión. Revisar el enunciado del ámbito con los interesados en el software y ajusfarlo según lo requerido.

5.

escenario del usuario, característica, función y comportamiento (sección 7.4.2). 9.

actividad d e comunicación con el cliente y otros

TM

Colaborar con el cliente y el usuario final p a r a

participantes, y ajustaría d e la forma que se

definir: •

Revisar toda la información recopilada durante la

requiera.

Escenarios d e uso visibles p a r a el cliente con el

10.

Prepararse p a r a la actividad d e planeación

PDF Editor uso del formato estándar 6 (sección 7.5).

6

(capítulos 2 3 y 24).

Los f o r m a t o s para escenarios de u s o se discuten e n el capítulo 8.

CAPÍTULO 5

5,3

113

LA PRÁCTICA UNA VISIÓN GENÉRICA

P R Á C T I C A S P E LA P L A N E A C I Ó N La actividad d e comunicación ayuda al equipo de s o f t w a r e a definir sus m e t a s y objetivos generales (por supuesto, sujeto al c a m b i o c o n f o r m e pasa el tiempo). Sin e m b a r g o , e n t e n d e r e s t a s m e t a s y objetivos no e s lo m i s m o que definir un plan para llegar a ellos. La actividad de planeación

abarca un c o n j u n t o de prácticas técnicas y

de gestión que permiten al equipo de s o f t w a r e definir un m a p a del c a m i n o mientras se viaja a través de su meta estratégica y objetivos tácticos.

"En la preparación poro la batalla siempre he encontrado que los planes son inútiles, pero que la planeación es indispensable.' D w i g h f D. E i s e n h o w e r

Existen m u c h o s e n f o q u e s diferentes para la planeación. Algunas p e r s o n a s son "minimalistas", y a r g u m e n t a n q u e el c a m b i o con frecuencia obvia la necesidad de u n plan detallado. Otros son tradicionalistas, y dicen que el plan proporciona un m a p a efectivo del camino, y mientras m á s detallado s e a éste, m e n o r probabilidad habrá de que el equipo pierda el rumbo. Además, otros s o n "agüistas" y a r g u m e n t a n que tal vez un "juego de planeación" rápido sea necesario, p e r o que el m a p a del c a m i n o surgirá c u a n d o c o m i e n c e el "trabajo real" sobre el software. ¿Qué hacer? En m u c h o s proyectos la sobreplaneación c o n s u m e tiempo y no produce frutos (demasiadas c o s a s cambian), p e r o la planeación insuficiente es una receta para el caos. C o m o la mayoría de las c o s a s e n la vida, la planeación se d e b e producir c o n moderación, lo suficiente p a r a proporcionar u n a guía útil para el equi po —no más, no m e n o s . Sin importar el rigor con el que se c o n d u z c a la planeación, los siguientes principios son válidos e n todo m o m e n t o . P r i n c i p i o # 1 : Entender los alcances del proyecto. Es imposible utilizar un m a p a de carreteras si no se s a b e el sitio a d o n d e se quiere ir. El h e c h o de e n t e n d e r los a l c a n c e s proporciona al equipo de s o f t w a r e un destino. P r i n c i p i o # 2 : Involucrar oceica '1 v "o/eítos.

al cliente

en la actividad

de planeación.

El cliente

define prioridades y establece las restricciones del proyecto. El ajuste de estas reali d a d e s a m e n u d o requiere que los ingenieros de software negocien las ó r d e n e s de TM entrega, los límites de tiempo y otros a s u n t o s relacionados con el proyecto. P r i n c i p i o # 3 : Reconocer

que la planeación

es iterativa.

El plan de un pro-

PDF Editor

yecto nunca se graba en una piedra. En c u a n t o comience el trabajo es m u y probable q u e las c o s a s cambien. En consecuencia, d e b e a j u s t a r s e el plan para adaptarlo a los cambios. Además, los modelos iterativos e increméntales del proceso dictan la replaneación (después de la entrega de cada incremento de software) basada en la retroalimentación recibida de los usuarios.

114

PARTE DOS


P r i n c i p i o # 4 : Estimar

con base en el conocimiento

disponible.

La finalidad

de la estimación e s proporcionar un indicio del esfuerzo, costo y duración de las tareas, con b a s e en el conocimiento que el equipo tiene del trabajo que s e va a realizar. Si la información es vaga o p o c o confiable, las estimaciones tendrán, de igual forma, poca confiabilidad. P r i n c i p i o # 5 : Considerar

el riesgo

cuando

se define

el plan.

Si el equipo ha

definido riesgos que tienen un alto impacto y u n a alta probabilidad, e s necesario un plan de contingencia. Además, el plan de proyecto (que incluye el calendario) se d e b e ajustar para incluir la posibilidad de que u n o o m á s de e s t o s riesgos se torne un problema real. P r i n c i p i o # 6 : Ser realista.

Las p e r s o n a s n o trabajan el 100 por ciento de cada

día. El ruido siempre entra en cualquier comunicación h u m a n a . Las omisiones y la ambigüedad s o n h e c h o s de la vida. Los cambios ocurrirán. Hasta los m e j o r e s ingenieros de software c o m e t e n errores. Éstas y otras realidades deben considerarse mientras se establece el plan del proyecto. "0 éxito está más en función del sentido común consistente que del genio." An W o n g

\ CLAVE El término granuloridod se refiere ol detalle con el que algunos elementos de lo planeación se representan o dirigen.

Principio #7: Ajustar la granularidad mientras se define el plan. La granularidad s e refiere al grado de detalle que se introduce c o n f o r m e se desarrolla el plan. Una "granularidad fina" e n el plan proporciona detalles significativos de las tareas de trabajo, los cuales se p l a n e a n en incrementos relativamente cortos de tiempo (de forma que el ajuste y el control se d e n con frecuencia). Un plan de "granularidad gruesa" proporciona t a r e a s de trabajo m á s amplias, las cuales se p l a n e a n en period o s m á s largos. Por lo general, la granularidad cambia de fina a gruesa c o n f o r m e el tiempo límite del proyecto está m á s lejos de la fecha actual. En las siguientes s e m a nas o m e s e s el proyecto se p u e d e planear c o n detalle significativo. Las actividades que no se realizarán por m u c h o s m e s e s n o requieren u n a granularidad fina (hay d e m a s i a d a s c o s a s que pueden cambiar). P r i n c i p i o #8: Definir

cómo

se intentará

asegurar

la calidad.

El plan d e b e

identificar la forma en que el equipo de s o f t w a r e pretende asegurar la calidad. Si habrá revisiones técnicas formales, 7 é s t a s se d e b e n calendarizar. En c a s o d e que se utilice programación en pareja (capítulo 4) d u r a n t e la construcciónTMésta d e b e estar definida de m a n e r a explícita e n el plan. P r i n c i p i o # 9 : Describir

cómo

se pretende

incluir

el cambio.

PDF Editor

Incluso a la

mejor planeación p u e d e superarla el cambio incontrolable. El equipo de software debe identificar la forma en que se incluirán los cambios c o n f o r m e se realiza el trab a j o de ingeniería del software. Por ejemplo, ¿el cliente p u e d e solicitar un c a m b i o en 7

Las revisiones técnicas formales se estudian en el capitulo 26.

CAPÍTULO 5


115

cualquier momento? ¿Si se presenta una solicitud de cambio el equipo está obligado a implementarlo de inmediato? ¿Cómo se evalúan el impacto y el costo del cambio? P r i n c i p i o # 1 0 : Adaptar el plan a menudo y hacer los ajustes cuando éstos se requieran. Día tras día los proyectos de software van por detrás del calendario establecido. Por ello, es de mucha ayuda adaptar el progreso a diario. Se deben buscar áreas problemáticas y situaciones en las que el trabajo calendarizado no vaya de acuerdo con el trabajo que se ejecuta en realidad. Cuando s e encuentran desfases, el plan se ajusta en concordancia con ello. En la búsqueda de mayor efectividad, todos los integrantes del equipo de software deben participar en la actividad de planeación. Sólo entonces son miembros del equipo "comprometidos" con el plan. En un excelente documento sobre procesos y proyectos de software, Barry Boehm [BOE96] establece: "Se necesita un principio de organización que se reduzca para proporcionar planes [de proyecto] simples para proyectos simples." Boehm sugiere un enfoque dirigido a los objetivos, fundamentos y calendarios del proyecto, a las responsabilidades, enfoques técnicos y de gestión y a los recursos requeridos. Él lo llamó principio W^HH (why, what, when, who, where, how, how), debido a una serie de preguntas que conducen a una definición de características clave del proyecto y el plan de proyecto resultante: I ¿Oifcs ••I»

i se 'y t se deben

rpn » • prtyetfo

¿ P o r q u é e s t á e n d e s a r r o l l o e s t e s i s t e m a ? Todas las partes deben evaluar la validez de las razones del negocio para el trabajo en el software. Dicho de otra manera, ¿el propósito del negocio justifica el gasto de personal, tiempo y dinero? ¿ Q u é s e h a r á ? Se debe identificar la funcionalidad que se construirá y, por ende, las tareas requeridas para realizar el trabajo. ¿ C u á n d o s e t e r m i n a r á ? E s n e c e s a r i o e s t a b l e c e r u n flujo d e t r a b a j o y u n t i e m p o

límite para las tareas clave del proyecto, asi como identificar los fundamentos requeridos por el cliente. ¿ Q u i é n e s e l r e s p o n s a b l e d e u n a f u n c i ó n ? Se deben definir el papel y la responsabilidad de cada miembro del equipo de software ¿En d ó n d e s e u b i c a n d e n t r o d e la o r g a n i z a c i ó n ? No todos los papeles y responsabilidades residen dentro del mismo equipo de software. El cliente, los usuarios y otros participantes también tienen responsabilidades. TM ¿ C ó m o s e r e a l i z a r á e l t r a b a j o e n l o s s e n t i d o s t é c n i c o y d e g e s t i ó n ? Una vez que se establece el ámbito del producto, es necesario definir una estrategia técnica y de gestión para el proyecto.

PDF Editor

¿Cuánto s e n e c e s i t a d e c a d a recurso? La r e s p u e s t a a e s t a p r e g u n t a s e o b t i e

ne al desarrollar estimaciones (capítulo 23) con base en las respuestas a las preguntas anteriores.

PARTE DOS

116


Las r e s p u e s t a s a las p r e g u n t a s W 5 HH de Boehm son importantes independientem e n t e del t a m a ñ o o la complejidad de u n proyecto de software. Pero, ¿ c ó m o se inicia el proceso de planeación? "Pensamos que los desarroiladores de software están perdiendo uno verdad vital: la nayoria de las organizaciones no saben lo que lacen. Ellas piensan que lo saben, pero no es así"

Tom DeMarco


Conjunto de tazeos genéricas para la planeación 1. Reevaluar el ámbito del proyecto

8

2 . Evaluar los riesgos (sección 2 5 . 4 ) . 3.

Definir t a r e a s d e t r a b a j o p a r a c a d a función y característica (sección 23.6).

Desarrollar o refinar los escenarios del usuario (secciones 7 . 5 y 8.5).

4.

Estimar el esfuerzo p a r a c a d a t a r e a d e t r a b a j o (sección 2 3 . 6 ) .

Extraer funciones y características a partir d e los

Asignar responsabilidad p a r a c a d a tarea d e

escenarios (sección 8.5). 5.

Definir las funciones y características técnicas q u e

ó.

A g r u p a r las funciones y características (escenarios)

t r a b a j o (sección 2 3 . 4 ) .

forman la infraestructura del software.

Definir los productos d e t r a b a j o q u e serán producidos. Identificar los métodos p a r a el aseguramiento d e

d e a c u e r d o con la prioridad del cliente. 7.

la calidad q u e se usarán (capítulo 26).

C r e a r un plan d e proyecto con una g r a n u l a r i d a d g r u e s a (capítulos 2 3 y 24). Definir el número proyectado de incrementos d e software. Establecer un c a l e n d a r i o general del proyecto (capítulo 24). Establecer las fechas d e entrega proyectadas p a r a c a d a incremento.

5.4

Crear un plan con g r a n u l a r i d a d fina p a r a la iteración actual (capítulos 2 3 y 24).

(secciones 7 . 4 y 21.3).

Describir los métodos p a r a el cambio en la gestión (capítulo 27). 9.

Rastrear el progreso d e m a n e r a regular (sección 24.5.2). O b s e r v a r las á r e a s problemáticas (por ejemplo, el d e s f a s e del calendario). Hacer los ajustes q u e se requieran.

P R Á C T I C A DEL M Q P E L A P O Los m o d e l o s se crean p a r a obtener u n mejor e n t e n d i m i e n t o de la entidad real que s e construirá. Cuando la entidad es u n objeto físico (por ejemplo, u n edificio, un avión, una máquina), se p u e d e construir un modelo idéntico en forma y TM t a m a ñ o , p e r o en m e n o r escala. Sin embargo, c u a n d o la entidad es software, el m o d e l o d e b e tomar u n a forma diferente. Debe ser capaz de representar la información que el s o f t w a r e

PDF Editor

transforma, la arquitectura y las funciones que permiten que ocurra la t r a n s f o r m a ción, las características que desean los usuarios, y el c o m p o r t a m i e n t o del sistema conforme se realiza la transformación. Los m o d e l o s deben cumplir e s t o s objetivos en diferentes grados de abstracción (primero al p r e s e n t a r el s o f t w a r e desde el p u n t o de vista del cliente y d e s p u é s al representar el s o f t w a r e en u n nivel m á s técnico).

CAPITULO 5

117

L A P R Á C T I C A : U N A VISIÓN GENÉRICA

En el trabajo de la ingeniería del software se crean dos clases de modelos: modelos de análisis y modelos de diseño. Los modelos de análisis representan los requisiC L Á V E s de 5 repfesenton tos ¡ del diente. Í ¡nodelos de diseño i uno i concreta c c construcción

tos del cliente al presentar el software en tres dominios diferentes: el dominio de la información, el dominio funcional y el dominio del comportamiento. Los modelos de diseño representan características del software que ayudan a los profesionales a construirlo de m a n e r a efectiva: la arquitectura (capítulo 10), la interfaz del usuario (capítulo 12), y el detalle al nivel de c o m p o n e n t e s (capítulo 11). En las secciones siguientes se presentan los principios y conceptos básicos que son relevantes para el modelado del análisis y el diseño. Los métodos técnicos y la notación que permiten que los ingenieros de software creen modelos de análisis y diseño se presentan e n los capítulos posteriores. "El p r i m e r p r o b l e m a del ingeniero en cualquier situación d e diseño e s descubrir cuál e s r e a l m e n t e el p r o b l e m a . "

5.4.1

Principios del m o d e l a d o del análisis

En las p a s a d a s tres décadas s e h a desarrollado un gran n ú m e r o de métodos de m o d e l a d o del análisis. Los investigadores h a n identificado los problemas del análisis y sus causas y han desarrollado una variedad de notaciones de modelado y los conceptos heurísticos correspondientes para manejarlos. Cada m é t o d o de análisis tiene un punto de vista único. Sin embargo, todos los m é t o d o s de análisis están relacionados por medio de u n a serie de principios operativos: P r i n c i p i o SI: El dominio tarse y entenderse.

de información

El dominio de información

de un problema

debe

represen-

lo f o r m a n los datos que fluyen hacia

el sistema (a partir de los usuarios finales, otros sistemas o dispositivos externos), los datos que fluyen desde el sistema (a través de la interfaz del usuario, interfases de red, reportes, gráficas y otros medios) y los almacenamientos de datos que se recopilan y reorganizan los objetos consistentes de información (es decir, los datos que se mantienen e n forma permanente).

K

P r i n c i p i o # 2 : Se deben

definir

las funciones

que ejecuta

el software.

Las

funciones del software proporcionan un beneficio directo a los usuarios Anales y también aporta soporte interno a aquellas características visibles para el usuario.

C L A V E

Algunas funciones transforman los datos que fluyen hacia el sistema. En otros casos,

) del s sé enfoca en t del Cb "iquese

las funciones efectúan algún grado de control sobre el procesamiento interno del TM describir e n software o elementos externos del sistema. Las funciones se pueden m u c h o s grados diferentes de abstracción, q u e van desde un enunciado general del propósito hasta u n a descripción detallada de los elementos del procesamiento q u e d e b e n utilizarse.

PDF Editor Jo ( s e debe

Mr'

¡que

Principio #3: Se debe representar el comportamiento del software (como

una consecuencia

de eventos

externos).

Al comportamiento del software de compu

tadora lo guía s u interacción con el ambiente externo. La entrada que proporcionan

PARTE DOS

PRÁCTICA E S LA INGENIERÍA DEL SOFTWARE

los usuarios finales, los datos de control que aporta un sistema externo o los datos de monitoreo que se recolectan a través de u n a red ocasionan que el software se comporte de u n a m a n e r a especifica. P r i n c i p i o # 4 : Los modelos tamiento

deben

estratificada

partirse

que presentan

de forma

(o jerárquica).

información,

que descubran

función

el detalle

y compor-

de una manera

El modelado del análisis es el primer p a s o en la reso-

lución de problemas en la ingeniería del software. Esto permite al profesional entender mejor el problema y establecer u n a b a s e para la solución (diseño). Los problem a s complejos son difíciles de resolver por completo. Por esta razón, se utiliza una estrategia de "divide y ganarás". Un problema grande y complejo s e divide e n subproblemas hasta que cada subproblema es relativamente fácil de entender. Este concepto se llama partición, y es u n a estrategia clave e n el modelado del análisis. P r i n c i p i o # 5 : La tarea del análisis hacia

el detalle

de implementación.

debe moverse

de la información

esencial

El modelado del análisis c o m i e n z a con la

descripción del problema desde la perspectiva del usuario final. La "esencia" del problema se describe sin ninguna consideración de la forma e n la que se implementará la solución. Por ejemplo, un videojuego requiere que el jugador "instruya" al protagonista e n qué dirección seguir c u a n d o éste se m u e v e dentro de un laberinto peligroso. Esa es la esencia del problema. El detalle de implementación (descrita en forma normal c o m o u n a parte del modelo del diseño) indica c ó m o se implementará la esencia. Respecto del videojuego se podría aplicar la entrada de voz. De m a n e r a alternativa, se podría digitar un c o m a n d o del teclado, o se podría apuntar u n joystick (o u n mouse) en u n a dirección específica.


Conjunto de tareas genéricas para el modelado del análisis 1. Revisar los requisitos del negocio, las

3.

características/necesidades del

Representar todos los objetos importantes d e

usuario, las salidas visibles p a r a el

información.

usuario, las restricciones del negocio, y otros

Definir los atributos p a r a c a d a objeto d e

requisitos técnicos que se h a y a n determinado

información.

durante las actividades d e comunicación con el

Representar las relaciones entre los objetos d e información.

cliente y d e planeación. Expandir y refínar los escenarios del usuario (sección 8.5). Definir a todos los actores. Representar la forma en q u e los actores

M o d e l a r el dominio de la información (sección 8.3).

4.

Modelar el dominio funcional (sección 8.6).

TM

Mostrar la forma en que las funciones modifican los objetos d e datos.

PDF Editor interactúan con el software.

Extraer funciones y características a partir d e los escenarios del usuario.

Revisar los escenarios del usuario p a r a verificar

q u e estén completos y su exactitud (sección 26.4).

Refinar las funciones p a r a proporcionar los detalles d e la elaboración.

Escribir una narración del procesamiento que describa c a d a función y subfunción.

Revisar los modelos funcionales (sección 26.4).

y

CAPÍTULO 5

IR

5.

Modelar el dominio del comportamiento (sección 8.8). ¿

sistema.

sistema a cambiar d e un estado a otro.

Analizar y modelar la inferíase del usuario (capítulo ] 2). Dirigir el análisis de tareas.

Identificar los estados que representan c a d a forma d e comportamiento observable desde el exterior. Presentar el modo en el que un evento lleva al

\

Revisar los modelos d e comportamiento (sección 26.4).

Identificar los eventos externos q u e ocasionan cambios en el comportamiento dentro del

5.4.2

119


Crear 7-

P r o t °Hpos d e la imagen en pantalla,

Revisar todos los modelos en cuanto a que estén completos, su consistencia y las omisiones.

y

Principios d e m o d e l a d o del diseño

El modelo de diseño del s o f t w a r e es el equivalente al plano de una casa para un arquitecto. Comienza con la representación de la totalidad del objeto que será construido (por ejemplo, u n a reproducción tridimensional de la casa) y con lentitud lo refina para proporcionar u n a guía para construir cada detalle (por ejemplo, el diseñ o de la plomería). En forma similar, el modelo del diseño que se crea para el softw a r e proporciona u n a variedad de diferentes vistas del sistema. "Primero ve que el diseño seo sabio y justo: overiguodo esto, persigúelo resueltamente; no por un rechozo dejes ir el propósito que te has resuelto efectuar.* William Shakespeare

No hay p o c o s m é t o d o s para derivar los diferentes e l e m e n t o s de un diseño de software. Algunos m é t o d o s se guían mediante los d a t o s al permitir a la estructura de d a t o s dictar la arquitectura del p r o g r a m a y los c o m p o n e n t e s de procesamiento resultantes. A otros los conduce el patrón a! utilizar información acerca del dominio del problema (el modelo de análisis) para desarrollar estilos arquitectónicos y p a t r o n e s de procesamiento. Incluso otros están orientados a objetos, al usar los objetos del dominio del problema c o m o los c o n d u c t o r e s para la creación de estructuras de d a t o s y los m é t o d o s p a r a manipularlos. Aún así, t o d o s ellos siguen un conjunto de princi píos de diseño que se pueden aplicar sin importar el m é t o d o que se utilice: P r i n c i p i o # 1: £7 diseño

debe ser rastreable

hasta

el modelo

de análisis.

El

modelo de análisis describe el dominio de la información del problema, las funcioTM n e s visibles para el usuario, el c o m p o r t a m i e n t o del sistema y u n conjunto de clases de análisis que e m p a q u e t a los objetos del negocio con los m é t o d o s que les sirven.

PDF Editor

El m o d e l o d e d i s e ñ o t r a d u c e e s t a i n f o r m a c i ó n a u n a a r q u i t e c t u r a : u n c o n j u n t o d e

subsistemas que impiementan las funciones m á s importantes y un conjunto de dise-

ños al nivel de c o m p o n e n t e s que son la realización de las clases de análisis. Excepto el modelo asociado con la infraestructura de software, los e l e m e n t o s del m o d e l o de

diseño deben ser rastreables hasta el modelo de análisis.

120

PARTE DOS


P r i n c i p i o #2: Siempre Eli C S . W W W C .

fld»/~aobyon/ Design/ se pueden entontiar comentoiíos profundos sobie el proceso de diseño. Junto con una exposwéndeto estético del diseño.

se debe considerar

la arquitectura

del sistema

que

se va a construir. La arquitectura del software (capítulo 10) es el esqueleto del sistema que s e va a construir. Éste afecta las interfases, las estructuras de datos, el flujo y el comportamiento del control del programa, la manera en que se pueden realizar las pruebas, la facilidad de mantenimiento del sistema resultante, y mucho más. Por todas estas razones, el diseño debe iniciarse con las consideraciones del diseño arquitectónico. Sólo después de que se ha establecido la arquitectura, es posible considerar los aspectos al nivel de componentes. P r i n c i p i o #3: El diseño de datos es tan importante como el diseño de funciones de procesamiento. El diseño de datos es un elemento esencial del diseño arquitectónico. La manera en que se realizan los objetos de los datos dentro del diseño no puede dejarse a la suerte. Un diseño de datos bien estructurado ayuda a simplificar el flujo del programa, facilita el diseño y la implementación de los componentes del software, y confiere m á s eficiencia al procesamiento en general. P r i n c i p i o #4: Las interfaces

(internas

y externas)

deben

diseñarse

con cui-

dado. La manera en que fluyen los datos entre los componentes de un sistema tiene mucho que ver con la eficiencia del procesamiento, la propagación del error y la simplicidad del diseño. Una interfaz bien diseñada facilita la integración y ayuda a quien realiza la prueba a validar funciones de componentes. P r i n c i p i o #5: El diseño de interfaz del usuario debe ajustarse a las necesidades del usuario final. Sin embargo, en cada caso, debe resaltarse la facilidad del uso. La interfaz del usuario es la manifestación visible del software. Sin importar qué tan sofisticadas sean sus funciones internas, sin importar qué tan comprensibles sean las estructuras de datos, no importa qué tan bien diseñada esté su arquitectura, un diseño de interfaz pobre siempre conduce a la percepción de que el software está "mal" hecho. P r i n c i p i o #6: El diseño al nivel de componentes debe ser independiente del modo funcional. La independencia funcional es una medida del "significado sencillo" de un componente de software. La funcionalidad que entrega un componente debe ser cohesiva; es decir, debe centrarse en una y sólo una función o subfunción. 8 P r i n c i p i o #7: Los componentes deben estar apareados entre sí en forma mínima y vinculados con el ambiente extemo. El apareamiento se consigue de m u c h a s maneras: vía interfaz de componente, por mensajes, a través de datos gloTM bales. A medida que aumenta el nivel de apareamiento, la probabilidad de propagación del error también aumenta y la facilidad de mantenimiento general del software disminuye. Por lo tanto, el apareamiento de componentes debe mantenerse tan bajo como sea posible.

PDF Editor 8

En el capítulo 9 se puede encontrar una exposición adicional acerca de la cohesión.

CAPÍTULO 5

P r i n c i p i o #8: Las representaciones mente

121


comprensibles.

del diseño

(modelos)

deben

ser fácil-

El propósito del diseño es comunicar información a los pro-

fesionales que g e n e r a r á n códigos, a aquellos que probarán el software, y a quienes tal vez m a n t e n g a n el s o f t w a r e en lo futuro. Si el diseño es difícil de entender, no servirá c o m o un medio efectivo de comunicación. P r i n c i p i o # 9 : El diseño ración

el diseñador

debe desarrollarse

debe buscar

la mayor

de manera simplicidad.

iterativa.

En cada ite-

C o m o casi t o d a s las acti-

vidades creativas, el diseño ocurre de m o d o iterativo. Las primeras iteraciones sirven para refinar el diseño y corregir errores, p e r o las iteraciones posteriores deben buscar q u e el d i s e ñ o sea tan simple c o m o sea posible. Cuando se aplican e s t o s principios de m a n e r a apropiada, el ingeniero de s o f t w a re crea u n diseño que muestra los factores internos y externos de calidad. Los factores de calidad externos son aquellas propiedades del s o f t w a r e que los usuarios pueden observar fácilmente (como velocidad, confiabilidad, corrección, facilidad de uso). Los factores de calidad internos son importantes para los ingenieros de software, ya que conducen hacia un diseño de alta calidad d e s d e u n a perspectiva técnica. Lograr factores de calidad internos requiere que el diseñador entienda conceptos básicos de diseño (capítulo 9).

INFORMACIÓN

Modelado ágil En su libro s o b r e m o d e l a d o ágil, Scott Ambler [AMB02] d e f i n e u n a serie d e p r i n c i p i o s ' c u a n d o el análisis y el d i s e ñ o se c o n d u c e n del contexto d e la filosofía del desarrollo ágil d e (capítulo 4):

Principio # 7 : Trotar d e construir m o d e l o s útiles, p e r o olvidarse d e construir m o d e l o s perfectos. Principio # 8: N o volverse d o g m á t i c o a c e r c a d e la sintaxis del modelo. Si éste c o m u n i c a su c o n t e n i d o d e m a n e r a exitosa, la r e p r e s e n t a c i ó n e s s e c u n d a r i a .

• # 1 : La m e t a p r i m a r i a del e q u i p o d e s o f t w a r e e s construir software, no c r e a r m o d e l o s . # 2: V i a j a r ligero; e s decir, n o d e b e n c r e a r s e m á s m o d e l o s d e los n e c e s a r i o s . # 3 : Intentar p r o d u c i r el m o d e l o m á s simple q u e describirá el p r o b l e m a o el s o f t w a r e . ~zo # 4 : Construir m o d e l o s d e f o r m a q u e éstos s e a n a j u s t a b l e s al c a m b i o . # 5 : Ser c a p a z d e e n u n c i a r un p r o p ó s i t o explícito p a r a c a d a m o d e l o q u e se c r e e . # 6 : A d a p t a r los m o d e l o s d e s a r r o l l a d o s al sistema q u e se tiene e n m a n o .

Principio # 9: Si el instinto indica que un modelo no es el correcto aunque éste luzca bien en el papel, probablemente existe una razón para estar preocupados. Principio # 1 0 : O b t e n e r retroalimentación ran p r o n t o c o m o sea posible. Sin i m p o r t a r el m o d e l o d e p r o c e s o q u e se elija o las p r á c t i c a s específicas d e la ingeniería del s o f t w a r e q u e se a p l i q u e n , t o d o s los e q u i p o s d e s o f t w a r e q u i e r e n ser ágiles. Por lo tonto, estos principios se d e b e n a p lTM i c a r sin importar el m o d e l o d e p r o c e s o del s o f t w a r e q u e se h a y a seleccionado.

PDF Editor 9

Los p r i n c i p i o s m e n c i o n a d o s e n e s t a s e c c i ó n se h a n a b r e v i a d o y a d a p t a d o p a r a los p r o p ó s i t o s d e e s t e

libro.

122

PARTE DOS



Conjunto de tareas genéricas para el diseño 1. Utilizar el m o d e l o d e análisis,

Especificar la s e c u e n c i a d e a c c i ó n con b a s e e n los

seleccionar un estilo arquitectónico

e s c e n a r i o s del u s u a r i o .

(patrón) a p r o p i a d o p a r a el s o f t w a r e

C r e a r un m o d e l o d e c o m p o r t a m i e n t o d e la

(capítulo 10). 2.

interfaz.

Dividir el m o d e l o d e análisis e n subsistemas d e

Definir los objetos d e la i n t e r f a z y m e c a n i s m o s d e

d i s e ñ o y u b i c a r éstos d e n t r o d e la arquitectura

control.

(capítulo 10).

Revisar el d i s e ñ o d e la i n t e r f a z y a j u s f a r l o c o m o

Tener la c e r t e z a d e q u e c a d a subsistema e s

sea n e c e s a r i o (sección 2 6 . 4 ) .

c o h e r e n t e e n el sentido funcional.

4.

Diseñar interfases d e subsistema.

Especificar t o d o s los algoritmos e n un g r a d o relativamente b a j o d e a b s t r a c c i ó n .

U b i c a r las clases o f u n c i o n e s d e análisis p a r a c a d a subsistema.

Refinar la interfaz d e c a d a c o m p o n e n t e .

M e d i a n t e la utilización del m o d e l o del d o m i n i o d e la i n f o r m a c i ó n , d i s e ñ a r estructuras d e d a t o s apropiadas.

3. Diseñar la interfaz del usuario (capítulo 12). Revisar los resultados del análisis d e t a r e a s .

5.5

C o n d u c i r el d i s e ñ o al nivel d e c o m p o n e n t e .

Definir les estructuras d e d a t o s e n el nivel d e c o m p o n e n t e (sección 2 6 . 4 ) . Revisar el d i s e ñ o e n el nivel d e c o m p o n e n t e s (sección 2 6 . 4 ) . Desarrollar un m o d e l o d e d e s p l i e g u e (sección 9 . 4 . 5 ) .

P R Á C T I C A DE L A C O N S T R U C C I Ó N La actividad de construcción

abarca u n a serie de t a r e a s de codificación y realización

de p r u e b a s que c o n d u c e n al s o f t w a r e operativo que está listo para entregarlo al cliente o usuario final. En el trabajo de la ingeniería del software moderna la codificación p u e d e ser: 1) la creación directa de código f u e n t e de u n lenguaje de programación; 2) la generación automática de código fuente al utilizar una representación intermedia del diseño del c o m p o n e n t e que será construido; 3) la generación automática de código mediante u n lenguaje de programación de cuarta generación (por ejemplo, Visual C++). "Durante gron parte de mi vida he sido un fisgón del software, asomándome furtivamente en el código sucio de otros personas. Ocasionalmente, encuentro uno joya real, un programa bien estructurado escrito con un estilo consistente, sin enredos, desarrollado de forma que cada componente es simple y organizado, y diseñado para que el producto puedo cambiar con facilidad." TM

David P a m a s

El e n f o q u e inicial de las p r u e b a s está al nivel de componentes, con frecuencia lla-

PDF Editor

m a d a s pruebas de unidad. Los otros niveles de prueba incluyen: 1) pruebas de inte-

gración (realizadas mientras el sistema está e n construcción) 2) pruebas de validación, las cuales evalúan si los requisitos h a n sido satisfechos para el sistema completo (o

para el incremento de software); y 3) pruebas de aceptación, que realiza el cliente en u n e s f u e r z o e n c a m i n a d o a ejercitar las características y funciones.

CAPITULO 5


123

Existe u n a serie de principios y conceptos aplicables a la codificación y las pruebas. Éstos se p r e s e n t a n en las secciones siguientes.

5.5.1

Principios y conceptos d e codificación

Los principios y conceptos que guían la tarea de codificación están alineados de m a n e r a muy c e r c a n a al estilo de la programación, los lenguajes de la programación y los m é t o d o s de programación. Sin embargo, existe un conjunto de principios f u n d a m e n t a l e s que p u e d e n establecerse: jÔMSCJO^.

«toe/ cóeun : elegante «toe/ : equivocado. ario prestar xriculor al mapto le

P r i n c i p i o s d e p r e p a r a c i ó n : Antes de escribir una línea de código se debe estar seguro de: 1. 2. 3. w a r e que se va a construir y el ambiente e n el que é s t e va a operar. 4.

Seleccionar u n a m b i e n t e de programación que proporcione h e r r a m i e n t a s que faciliten el trabajo.

5 . Crear un conjunto de pruebas de unidad que serán aplicadas una vez que se complete el c o m p o n e n t e que se va a codificar. P r i n c i p i o s d e c o d i f i c a c i ó n : Cuando se comience a escribir el código se debe estar seguro de: 1. Restringir los algoritmos al seguir la práctica de la programación estructurada s encootrar

«•te s 4e codificaciófl.

[BOHOO], 2. 3.

Seleccionar las estructuras de datos que satisfarán las necesidades del diseño. Entender la arquitectura del s o f t w a r e y crear interfases que sean consistentes con ella.

4.

Mantener la lógica condicional tan simple c o m o s e a posible.

5 . Crear ciclos anidados e n u n a forma que los haga fáciles de probar. 6.

Seleccionar n o m b r e s de variables significativas y seguir otros e s t á n d a r e s locales de codificación.

7 . Escribir código que tenga d o c u m e n t a c i ó n propia. 8. Crear u n a configuración lineal (por ejemplo, sangrías y líneas en blanco que TM ayuden a la comprensión del código). P r i n c i p i o s d e v a l i d a c i ó n : Después de haber completado ficación, se debe estar seguro de•

los primeros pases de codi-

PDF Editor 1 . Conducir u n ensayo de código c u a n d o sea apropiado

2 . Realizar p r u e b a s de unidad y corregir los errores que se hayan descubierto. 3 . Refabricar el código.

PARTE DOS

124


Los libros sobre codificación y los principios que la guían incluyen trabajos recientes sobre el estilo de programación [KER78], construcción práctica de software IMCC93], perlas de programación [BEN991, el arte de la programación [KNU99], aspectos de la programación pragmática IHUN99], y m u c h o s otros. C O N J U N T O DE TAREAS

Conjunto de tazeos genéricas poza la constzucción Codificar los algoritmos internos y las funciones d e

1. Construir la infraestructura arquitectónica (capítulo 10).

procesamiento relacionadas. Revisar el código conforme éste se escribe (sección

Revisar el diseño arquitectónico.

26.4).

Codificar y probar los componentes que forman la

Buscar la exactitud.

infraestructura arquitectónica.

Asegurarse d e que se han mantenido los

Adquirir patrones arquitectónicos reutilizables.

estándares d e codificación.

Probar la infraestructura p a r a a s e g u r a r la integridad d e la interfaz. 2.

Construir un componente del software (capítulo 11).

Asegurarse de que el código se documenta a sí mismo. 3.

Revisar el diseño al nivel d e componente. Crear una serie d e pruebas d e unidad p a r a el componente (secciones 13.3.1 y 14.7). Codificar las estructuras d e datos y la inferíase del componente.

5.5.2

Realizar pruebas d e unidad al componente. Dirigir todas las pruebas d e unidad. Corregir los errores descubiertos. Aplicar d e nuevo las pruebas d e unidad. Integrar el componente terminado a la infraestructura arquitectónica.

Principios d e las pruebas

En un libro clásico sobre las pruebas realizadas al software, Glen Myers [MYE79] establece u n a serie de reglas que bien p u e d e n servir c o m o objetivos de las pruebas: • Las pruebas consisten en un proceso e n el que se ejecuta u n programa con la intención de encontrar un error que a ú n n o se descubre. ¿Cuáles son

•

los objetivos

de los pruebas al software?

• Un b u e n caso de prueba es aquel en el que hay u n a gran probabilidad de encontrar un error que aún n o se descubre. • Una prueba exitosa es aquella que encuentra un error que a ú n no se descubría. Estos objetivos implican un cambio radical desde el punto de vista de algunos desarrolladores de software. Éstos se o p o n e n a la visión inusual de que la prueba exitoTM sa es aquella e n la que no se e n c u e n t r a n errores. El objetivo aquí es diseñar p r u e b a s que d e m a n e r a sistemática descubran diferentes clases de errores y que lo h a g a n

PDF Editor con un gasto mínimo de tiempo y esfuerzo.

Davis [DAV95] sugiere un conjunto de principios para las pruebas, 1 0 el cual se ha

adaptado para aprovecharlo en este libro:

10 Aquí se presenta sólo un p e q u e ñ o subconjunto de los principios de Davis para las pruebas. Para obtener m á s información véase (DAV95).

CAPÍTULO 5

125

LA PRÁCTICA: UNA VISIÓN GENÉRICA

P r i n c i p i o # 1: Todas las pruebas del clienteEl

deben

ser rastreables

hasta

los requisitos

objetivo de las p r u e b a s realizadas al s o f t w a r e es descubrir errores.

De aqui se d e s p r e n d e que los defectos m á s severos (desde el p u n t o de vista del cliente) son aquellos que hacen fallar el p r o g r a m a al tratar de satisfacer sus requisitos. F C O N S E J O £ .

) amplio .debe •quese 'ai lo grande", •enla del í i se termina cxqueño-,ol teñios . Para las soto es reí

•yprobar

P r i n c i p i o # 2 : Las pruebas el proceso

de prueba.

se deben

planear

mucho

antes

de que comience

La planeación de las pruebas (capítulo 13) p u e d e c o m e n z a r

tan pronto c o m o el m o d e l o de análisis esté completo. La definición detallada de los c a s o s de prueba p u e d e c o m e n z a r en c u a n t o el modelo de diseño haya sido solidificado. Por tanto, todas las pruebas se pueden planear y diseñar a n t e s de que se haya g e n e r a d o cualquier código. P r i n c i p i o # 3 : El principio

de Pareto

es aplicable

para las pruebas

de soft-

ware. Para establecerlo de m a n e r a simple, el principio de Pareto implica que 80 por ciento de los errores descubiertos d u r a n t e las pruebas con probabilidad serán rastreables hasta 20 por ciento de t o d o s los programas. El problema, por supuesto, es aislar estos c o m p o n e n t e s s o s p e c h o s o s y d e s p u é s probarlos. P r i n c i p i o # 4 : Las pruebas hacia

"lo grande".

deben

comenzar

"en lo pequeño"

y progresar

Las primeras p r u e b a s que se p l a n e a n y ejecutan, por lo general,

se e n f o c a n en los c o m p o n e n t e s individuales. Conforme progresan las pruebas, el enfoque cambia en un intento de e n c o n t r a r errores en grupos integrados de c o m p o nentes y, por último, en el sistema completo. P r i n c i p i o # 5 : Las pruebas

exhaustivas

no son posibles.

El n ú m e r o de per-

m u t a c i o n e s e n t r e las rutas, incluso de un programa con un t a m a ñ o moderado, es excepcionalmente grande. Por esta razón es imposible ejecutar cada combinación de rutas para las pruebas. Sin embargo, se p u e d e cubrir de m a n e r a a d e c u a d a la lógica del p r o g r a m a para a s e g u r a r que se hayan ejercitado t o d a s las condiciones al nivel de c o m p o n e n t e s (capítulo 14). C O N J U N T O DE TAREAS

Conjunto de tareas genéricas para las pruebas 1. Diseñar pruebas d e unidad pora c a d a componente del software (sección 13.3.1) Revisar c a d a prueba de unidad p o r a asegurar una cobertura a p r o p i a d a . Dirigir la prueba d e unidad. Corregir los errores descubiertos.

Aplicar d e nuevo las pruebas d e unidad. 2.

Desarrollar una estrategia d e integración (sección 13.3.2). Establecer el orden y la estrategia que se usará p a r a la integración.

TM Definir las "construcciones" y las pruebas requeridas p a r a ejercitarlas

PDF Editor 11 Este principio se refiere a las p r u e b a s funcionales,

e s decir, a las q u e se e n f o c a n en los requisitos.

Las pruebas estructurales (que se e n f o c a n en los detalles arquitectónicos o lógicos) pueden no referirse en forma directa a los requisitos específicos.

GIIIKi

PARTE DOS

126


Dirigir pruebas d e humo a diario.

5.

Dirigir pruebas d e regresión c a d a vez q u e sea

Dirigir las pruebas con mucho orden.

\

Realizar las pruebas d e recuperación (sección 13.6.1).

necesario. Desarrollar una estrategia d e validación (sección

Realizar las pruebas d e seguridad (sección

13.5).

13.6.2).

Establecer los criterios d e validación.

Realizar las pruebas de tensión (sección 13.6.3).

Definir las pruebas requeridas p a r a validar el

Realizar las pruebas de desempeño (sección

software.

13.6.4).

Dirigir las pruebas d e integración y validación. Corregir los errores descubiertos.

6.

Coordinar con el cliente las pruebas d e aceptación (sección 13.5.3).

Aplicar d e nuevo las pruebas c a d a vez que sea

Como se mencionó en el capítulo 2, la actividad de despliegue abarca tres acciones: entrega, soporte y retroalimentación. Como el software moderno es evolutivo por naturaleza, el despliegue no se presenta una sola vez, sino varias veces conforme el software avanza hacia su terminación. Cada ciclo de entrega le proporciona al cliente y a los usuarios finales un incremento de software operativo que provee funciones y características útiles. Cada ciclo de soporte proporciona documentación y asistencia h u m a n a para todas las funciones y características introducidas durante todos los ciclos de despliegue que s e han presentado hasta la fecha. Cada ciclo de retroalimentación ofrece al equipo de software una guía importante que conduce a modificaciones en las funciones, características y el enfoque que se toma para el siguiente incremento. La entrega de un incremento de software representa un fundamento importante para cualquier proyecto de software. Cuando el equipo se prepara para crear un incremento, se debe seguir una serie de principios clave:

(cOMSEJO^.

Se debe tener lo seguridad de que el ¡tente sobe qué esperar antes de que se entregue el memento de software. De otra manera, el dente esperaiá más deloquesel

P r i n c i p i o # I : S e deben administrar las expectativas que el cliente tiene del software. Con demasiada frecuencia, el cliente espera m á s de lo que el equipo ha prometido entregar y de inmediato se presenta un desacuerdo. Esto genera una retroalimentación improductiva que arruina la moral del equipo. En su libro TM sobre la administración de expectativas, Naomi Kartun [KAR94] establece: "El punto inicial para administrar las expectativas es volverse más consciente acerca de lo que se comunica y de la forma en que se hace". Sugiere que un ingeniero de software debe ser cuidadoso de n o enviar al cliente mensajes conflictivos (como prometer más de lo que se puede entregar de manera razonable en el marco de tiempo con el que se

PDF Editor

cuenta, o entregar más de lo que se promete para un incremento de software y después menos de lo prometido para el siguiente).

CAPITULO 5

127


Principio #2: Se debe ensamblar

y probar

un paquete

de entrega

completo.

Se debe ensamblar un CD-ROM u otro medio que contenga todo el software ejecutable, archivos con los datos de soporte, documentos de soporte y otra información relevante para que después lo prueben los usuarios reales. Todos los protocolos de instalación y otras características operativas se deben ejercitar posteriormente en todas las configuraciones de cómputo posibles (por ejemplo, hardware, sistemas operativos, dispositivos periféricos, arreglos de red). P r i n c i p i o # 3 : Se debe establecer

un régimen

de soporte

antes

de entregar

el software. Un usuario final espera responsabilidad e información exacta cuando surja una pregunta o problema. Si el soporte es ad hoc o, aún peor, inexistente, el cliente se siente insatisfecho de inmediato. El soporte debe ser planeado, el material de soporte se debe preparar y se deben establecer mecanismos para mantener un registro apropiado con que el equipo de software pueda realizar una evaluación categórica de los tipos de soporte solicitados. P r i n c i p i o #4: Se debe proporcionar

material

instructivo

apropiado

a los

usuarios finales. El equipo de software entrega más que el software en sí; en caso de ser necesario, se debe desarrollar un entrenamiento apropiado, se deben proporcionar directrices para la resolución de problemas, y se deben publicar descripciones acerca de "cuál es la diferencia con este incremento de software". 12 P r i n c i p i o #5: El software

con errores se debe arreglar primero

y entregar-

se después. Ante la presión del tiempo, algunas organizaciones de software entregan incrementos de baja calidad con una advertencia para el cliente de que los errores "se eliminarán en la próxima versión". Esto es un error. En el negocio del software se dice: "Los clientes olvidarán que se les entregó un producto de alta calidad unos pocos días después, pero nunca olvidarán los problemas que les causó un producto de baja calidad. El software se los recuerda todos los días". El software entregado proporciona un beneficio para el usuario final, pero también provee una retroalimentación útil para el equipo de software. Al utilizar el incremento, los usuarios finales deben ser motivados a comentar sobre las características y funciones, facilidad de uso, confiabilidad y cualesquiera otras características apropiadas. La retroalimentación debe recopilarla y registrarla el equipo de software y aprovecharla para 1) hacer modificaciones inmediatas al incremento entregado (si e s necesario); 2) definir los cambios que serán incorporados en el próximo incremento planeado; 3) realizar las modificaciones necesarias al diseñoTM para ajustarlo a los cambios; y 4) revisar el plan (incluyendo el calendario de entrega) del próximo incremento para reflejar los cambios.

PDF Editor

12 Durante la actividad de comunicación el equipo de software debe determinar los tipos de materiales de ayuda que quieren los usuarios.

128

PARTE DOS

PRÁCTICA DE LA INGENIERIA DEL SOFTWARE


Conjunto de tareas genericas para el despliegue Establecer u n a b a s e d e d a t o s p a r a el r e p o r t e d e

1. C r e a r m e d i o s d e e n t r e g a .

problemas/errores.

E n s a m b l a r y p r o b a r t o d o s los a r c h i v o s ejecutables.

3.

Definir el p r o c e s o d e retroalimentación.

C r e a r y p r o b a r t o d a la d o c u m e n t a c i ó n del usuario.

Definir las f o r m a s d e retroalimentación (en p a p e l o

Implementar las versiones electrónicas (por

electrónica)

e j e m p l o , pdf).

Establecer la b a s e d e d a t o s d e retroalimentación.

Implementar a r c h i v o s d e " a y u d a " con hipertexto.

Definir el p r o c e s o d e e v a l u a c i ó n d e la

Implementar u n a g u í a p a r a la resolución d e

retroalimentación.

problemas. P r o b a r los m e d i o s d e e n t r e g a con un g r u p o p e q u e ñ o d e usuarios representativos.

2. Establecer la persona o grupo encargado del

4.

5.

Establecer m e c a n i s m o s p a r a la localización d e problemas. Establecer m e c a n i s m o s p a r a el r e p o r t e d e problemas.

Dirigir las f u n c i o n e s d e s o p o r t e continuas. P r o p o r c i o n a r asistencia en la instalación y el inicio.

Crear la documentación o las herramientas de soporte por computadora. un sitio w e b , teléfono, c o r r e o electrónico).

Diseminar los m e d i o s d e e n t r e g a a t o d o s los usuarios.

r-opor*fo L u m o n o

Establecer m e c a n i s m o s d e contacto (por e j e m p l o ,

Establecer m e c a n i s m o s d e retroalimentación del usuario.

E n s a m b l a r y p r o b a r t o d o s los a r c h i v o s d e d a t o s .

P r o p o r c i o n a r asistencia continua y d e resolución de problemas. 6.

Recopilar la retroalimentación del u s u a r i o Registrar la retroalimentación. Evaluar la retroalimentación. C o m u n i c a r s e con los u s u a r i o s s o b r e la retroalimentación.

La práctica de la ingeniería del software incluye conceptos, principios, m é t o d o s y h e r r a m i e n t a s que aplican los ingenieros de s o f t w a r e durante el proceso de software. Cada proyecto de ingeniería del software es diferente, a u n así existe un conjunto de principios y t a r e a s aplicables para cada actividad del m a r c o de trabajo del proceso, sin importar el proyecto o producto. TM Si se pretende dirigir u n a b u e n a práctica de la ingeniería del software, e s necesario un conjunto de p u n t o s esenciales técnicos y de gestión. Los p u n t o s técnicos incluyen la necesidad de e n t e n d e r los requisitos y las á r e a s de incertidumbre del pro-

PDF Editor

totipo, así c o m o la necesidad de definir de m a n e r a explícita la arquitectura del softw a r e y el plan de integración de c o m p o n e n t e s . Los p u n t o s esenciales de gestión incluyen la necesidad de definir prioridades y especificar un calendario realista que las refleje, la necesidad de precisar m e d i d a s de control del proyecto a p r o p i a d a s para la calidad y el cambio.

CAPÍTULO 5


129

Los principios de comunicación con el cliente se enfocan en la necesidad de reducir el ruido y mejorar el canal de comunicación conforme progresa la conversación entre el desarrollador y el cliente. Ambas partes deben colaborar para que se establezca la mejor comunicación. Los principios de planeación se enfocan en las directrices encaminadas a construir el mejor mapa para realizar el trabajo que conducirá a terminar un sistema o producto. El plan se puede diseñar sólo para un incremento de software, o se puede definir respecto del proyecto completo. Independientemente de ello, el plan debe indicar qué s e hará, quién lo hará y cuándo se completará el trabajo. El modelado incluye tanto el análisis como el diseño, al describir representaciones del software que se vuelven más detalladas de manera progresiva. La finalidad de los modelos es solidificar la comprensión del trabajo que se realizará y proporcionar una guía técnica para quienes implementarán el software. La construcción incorpora un ciclo de codificación y pruebas en el cual primero se genera el código fuente y después éste se prueba para detectar errores. La integración combina los componentes individuales e involucra una serie de pruebas que se enfocan en los aspectos del funcionamiento general y de las interfases locales. Los principios de codificación definen las acciones genéricas que deben ocurrir antes de que se escriba el código, mientras éste se crea y después de que se haya completado. Aunque existen muchos principios para las pruebas, sólo uno es el dominante: las pruebas se forman con un proceso en el que un programa se ejecuta con el objetivo de encontrar un error. Durante el desarrollo del software evolutivo se presenta el desarrollo para cada incremento de software que s e presenta al cliente. Los principios clave para la entrega consideran administrar las expectativas del cliente y dotar al usuario con infor mación de soporte para el software. El soporte necesita una preparación previa. La retroalimentación permite al cliente sugerir cambios que tienen un valor de negocios y proporcionan al desarrollador una entrada para el próximo ciclo iterativo de la ingeniería del software.

[AMB02] Ambler, S. y R. Jeffrics, Agile Modeling, Wiley, 2002. 1BEN99] Bentley, J„ Programming Pearls, 2a. ed., Addison-Wesley, 1999. IBOE 96] Boehm, B., "Anchoring t h e S o f t w a r e Process", en IEEE Software, vol. 13, n ú m . 4, julio d e 1996, pp. 73-82. [BOHOO] Bohl, M. y M. Rin, Tools for Structured Design: An Introduction lo Programming Logic, TM 5a. ed., Prentice-Hall, 2000. [DAV95] Davis, A., 201 Principies of Software Development, McGraw-Hill, 1995. [FOW991 Fowler, M. et al., Refactoring: Improving the Design ofExisting Code, Addison-Wesley, 1999. [GAR95] Garlan, D. y M. Shaw, "An introduction to S o f t w a r e Architeclure", en ñdvanees in Software Engineering and Knowledge Engineering, vol. 1 (V. Ambriola y G. Tortora, eds.), World Scientific Publishing Company, 1995. [HIG00I Highsmith, ]., Adaptive Software Development: An Evolutionary Approach to Managing Complex Systems, Dorsct House Publishing, 2000.

PDF Editor

PARTE DOS


[H0096] Hooker, D„ "Seven Principies of Software Development", septiembre de 1996, disponible en http://c2.com/cgi/wikiSevenPrinciplesOfSoftwareDevelopment. [HUN95] Hunt, D., A. Bailey y B. Taylor, The Art of Facilitation, P e r s e u s Book Group, 1995. [HUN99] Hunt A., D. T h o m a s y W. C u n n i n g h a m , The Pragmatic Programmer, Addison-Wesley, 1999. DUS99] Justice, T. etal., TheFacilitators Fieldbook, AMACOM, 1999. [KAN931 Kanner, C., J. Falk y H. Q. Nguyen, Testing Computer Software, 2a. ed., Van Nostrand Reinhold, 1993. [KAN96J Kaner, S. et al., The Facilitator's Cuide to Preparatoiy Decisión Making, New Society Publishing, 1996. [KAR94] Karten, N., Managing Expcctations, DorsetHouse, 1994. [KER78] Kernighan, B. y P. Plauger, The Elements of Programming Style, 2a. ed., McGraw-Hill, 1978. [KNU98] Knuth, D„ The Art of Computer Programming, 3 v o l ú m e n e s , Addison-Wesley, 1998. [MCC93] McConnnell, S., Code Complete, Microsoft Press, 1993. (MCC97J McConnell, S„ "Software's Ten Essentials", en IEEE Software, vol. 14, n ú m . 2, m a r z o abril, 1997, pp. 143-144. [MYE78J Myers, G„ Composite Structured Design, Van Nostrand, 1978. [MYE79] Myers, G„ The Art of Software Testing, Wiley, 1979. [PAR72] P a m a s , D.L., "On Criteria to Be Used in D e c o m p o s i n g S y s t e m s into Modules", en CACM, vol. 14, n ú m . 1, abril de 1972, pp. 221-227.

1POL45] Polya, G„ How to Solve II, Princeton University Press, 1945. [ROS75] Ross, D., J. G o o d e n o u g h y C. Irvine, " Softw a r e Engineering: Process, Principies and Goals", en IEEE Computer, vol. 8, n ú m . 5, m a y o de 1975. [SHA95a) Shaw, M. y D. Garlan, "Formulations and Formalisms in Software Architecture", Volume 1000—Lecture Notes in Computer Science, Springer-Verlag, 1995. [SHA95b] Shaw, M. e t al., "Abstractions for Software Architecture and Tools to Support Them", en IEEE Trans. Software Engineering, vol. SE-21, n ú m . 4, abril d e 1995, pp. 314-335. ISTE74] S t e v e n s , W., G. Myers y L. Constantine, "Structured Design", e n IBM Systems Journal, vol. 13, núm. 2, 1974, pp. 115-139. [TAY90] Taylor D. A., Object-Oriented Technology: A Manager's Guide, Addison-Wesley, 1990. [ULL97] Ullman, E., Cióse to the Machine: Technophilia and its Discontents, City Lights Books, 1997. [W1R71] Wirth, N„ "Program Development by Stepwise Refinement", en CACM, vol. 14, n ú m . 4, 1971, pp. 221-227. [ W 0 0 9 5 ] Wood, J. y D. Silver, Joint Application Design, Wiley. 1995. [ZAH90] Zahniser, R. A., "Building Software in Groups", en American Programmer, vol. 3, n ú m s . 7-8, julio-agosto de 1990.

5.1. Inténtese resumir en u n p á r r a f o breve los "siete principios para el desarrollo de software" d e David Hooker (sección 5.1). Trátese d e e x t r a e r la e s e n c i a de su guia e n sólo u n a s c u a n t a s oraciones y sin usar las palabras de Hooker. 5.2. ¿Existen otros p u n t o s técnicos "esenciales" que se p u e d a n r e c o m e n d a r a los ingenieros de TM software? Enunciar cada uno de ellos y explicar por qué se han incluido. 5.3. ¿Existen otros puntos "esenciales" d e gestión que se p u e d a n r e c o m e n d a r a los ingenieros de software? Enunciar cada uno de ellos y explicar por qué se ha incluido.

PDF Editor

5.4. Un principio i m p o r t a n t e de la c o m u n i c a c i ó n e s t a b l e c e " p r e p a r e a n t e s de comunicar". ¿ C ó m o podría esta p r e p a r a c i ó n m a n i f e s t a r s e por si m i s m a en los p r i m e r o s t r a b a j o s q u e se realizan? ¿Cuáles p r o d u c t o s d e trabajo podrían resultar c o m o c o n s e c u e n c i a de la preparación oportuna?

CAPÍTULO 5


131

5.5. H á g a s e u n a i n v e s t i g a c i ó n d e la "facilitación" p a r a la actividad d e c o m u n i c a c i ó n (utilícens e l a s r e f e r e n c i a s q u e s e p r o p o r c i o n a n u o t r a s ) y p r e p á r e s e u n c o n j u n t o d e d i r e c t r i c e s q u e se e n f o q u e n s ó l o e n la facilitación. 5 . 6 . ¿En q u é d i f i e r e n la c o m u n i c a c i ó n ágil y la c o m u n i c a c i ó n d e la i n g e n i e r í a d e s o f t w a r e trad i c i o n a l ? ¿En q u é s o n s i m i l a r e s ? 5.7.

¿Por q u é e s n e c e s a r i o c o n t i n u a r ?

5.8. Realizar u n a i n v e s t i g a c i ó n d e la " n e g o c i a c i ó n " p a r a la a c t i v i d a d d e c o m u n i c a c i ó n y p r e p a rar u n c o n j u n t o d e d i r e c t r i c e s q u e s e e n f o q u e n s ó l o e n la n e g o c i a c i ó n . 5.9.

Describir lo q u e significa granularidad

e n el c o n t e x t o d e u n c a l e n d a r i o d e p r o y e c t o .

5.10. ¿Por q u é s o n i m p o r t a n t e s los m o d e l o s e n el t r a b a j o d e la i n g e n i e r í a d e s o f t w a r e ? ¿ S i e m p r e s o n n e c e s a r i o s ? ¿ S o n c a l i f i c a d o r e s p a r a su r e s p u e s t a a c e r c a d e la n e c e s i d a d ? 5.11.

¿ C u á l e s s o n los t r e s " d o m i n i o s " q u e s e c o n s i d e r a n d u r a n t e el m o d e l a d o del a n á l i s i s ?

5.12. T r a t a r d e a g r e g a r u n principio adicional a l o s e n u n c i a d o s p a r a la c o d i f i c a c i ó n d e la s e c ción 5.6. 5.13.

¿Qué es una prueba exitosa?

5.14. ¿ S e e s t á d e a c u e r d o c o n el s i g u i e n t e e n u n c i a d o ? : " d e b i d o a q u e e n t r e g a m o s m ú l t i p l e s i n c r e m e n t o s al cliente, n o d e b e m o s p r e o c u p a m o s p o r la c a l i d a d e n los p r i m e r o s i n c r e m e n t o s : l o s p r o b l e m a s s e p u e d e n r e s o l v e r e n i t e r a c i o n e s p o s t e r i o r e s . Expliqúese la r e s p u e s t a . 5.15.

¿Por q u é e s i m p o r t a n t e la r e t r o a l i m e n t a c i ó n p a r a el e q u i p o d e s o f t w a r e ?

O T R A S L E C T U R A S Y F U E N T E S DE I N F O R M A C I Ó N La c o m u n i c a c i ó n c o n el cliente e s u n a actividad m u y i m p o r t a n t e e n la i n g e n i e r í a del s o f t w a r e ; n o o b s t a n t e , a l g u n o s p r o f e s i o n a l e s n o d e d i c a n t i e m p o a l e e r a c e r c a d e ella. Los l i b r o s d e P a r d e e (To Satsfy and Delight Your Costumer, Dorset H o u s e , 1996) y Karten [KAR94] p r o p o r c i o n a n u n a g r a n p e r s p e c t i v a d e l o s m é t o d o s p a r a la i n t e r a c c i ó n efectiva c o n el cliente. E n m u c h o s libros s o b r e la g e s t i ó n d e p r o y e c t o s s e c o n s i d e r a n l o s c o n c e p t o s y p r i n c i p i o s d e la c o m u n i c a c i ó n y la p l a n e a c i ó n . Las o f e r t a s ú t i l e s r e l a t i v a s a la g e s t i ó n d e p r o y e c t o s incluyen: H u g h s y Cotterell (Software Project Management, s e g u n d a e d i c i ó n , McGraw-Hill, 1999), Phillips (The Software Project Manager's Handbook, IEEE C o m p u t e r Society P r e s s , 1998), M c C o n n e l l (Software Project

survivai ouide, Microsoft Press, 1998) y Gilb (Principies of software Engineering Management. Addison-Wesley, 1998). Casi c u a l q u i e r libro s o b r e i n g e n i e r í a del s o f t w a r e c o n t i e n e u n a e x p o s i c i ó n útil s o b r e los c o n c e p t o s y p r i n c i p i o s p a r a el a n á l i s i s , el d i s e ñ o y las p r u e b a s . Entre l a s m e j o r e s o f e r t a s e s t á n los libros d e E n d r e s y s u s c o l e g a s (Handbook of Software and Systems Engineering, Addison-Wesley, 2003), S o m m e r v i l l e (Software Engineering, s e x t a edición, Addison-Wesley, 2000), P f l e e g e r (Software Engineering: Theory and Practice, Prentice-Hall. 2001) y S c h a c h (Object-Oriented and Ciassicai Software Engineering, McGraw-Hill, 2001). D a v i s h a r e c o p i l a d o u n a a m p l i a c o l e c c i ó n d e p r i n c i p i o s d e s o f t w a r e en [DAV95], Los c o n c e p t o s y p r i n c i p i o s del m o d e l a d o s e c o n s i d e r a n e n m u c h o s libros d e d i c a d o s al a n á lisis d e r e q u i s i t o s o al d i s e ñ o d e s o f t w a r e . Young (EJfective Requirements Practices, A d d i s o n Wesley, 2001) r e s a l t a u n " e q u i p o c o n j u n t o " d e c l i e n t e s y d e s a r r o l l a d o r e s q u eTM e l a b o r e n los requis i t o s c o l e c t i v a m e n t e . W e i g e r s (Software Requirements, Microsoft Press, 1999) p r e s e n t a m u c h o s r e q u i s i t o s c l a v e d e i n g e n i e r í a y r e q u i s i t o s d e las p r á c t i c a s d e g e s t i ó n . S o m m e r v i l l e y Kotonya (Requirements Engineering: Process and Techniques, Wiley. 1998) a n a l i z a n los c o n c e p t o s y las técn i c a s d e " o b t e n c i ó n " y o t r o s p r i n c i p i o s d e la i n g e n i e r í a d e r e q u i s i t o s . El libro d e N o r m a n (The Design ofEveryday Things. C u r r e n c y / D o u b l e d a y . 1990) e s u n a l e c t u ra o b l i g a d a p a r a c u a l q u i e r i n g e n i e r o d e s o f t w a r e q u e i n t e n t e h a c e r el t r a b a j o d e d i s e ñ o W i n o g r a d y s u s c o l e g a s (Bringing Design to Software, A ddi s on-We s l e y. 1996) h a n e d i t a d o u n a e x c e l e n t e c o l e c c i ó n d e e n s a y o s q u e t r a t a n s o b r e los a s p e c t o s p r á c t i c o s del d i s e ñ o d e s o f t w a r e . C o n s t a n t i n e y L o c k w o o d (Software for Use, Addison-Wesley, 1999) p r e s e n t a n l o s c o n c e p t o s a s o -

PDF Editor

132

PARTE DOS


ciados con el "diseño centrado en el usuario". Tognazzini (Tog on Software Design, AddisonWesley, 1995) presenta u n a valiosa exposición filosófica d e la naturaleza del d i s e ñ o y el impacto de las decisiones sobre la calidad y la capacidad del equipo p a r a producir un software que proporcione un gran valor a su cliente. Hay cientos de libros que tratan sobre u n o o m á s e l e m e n t o s de la actividad d e construcción. Kernighan y Plauger (KER78] escribieron un texto clásico sobre el estilo de programación; McConnell (MCC93] presenta directrices p r a g m á t i c a s para la construcción práctica de software; Bentley ¡BEN99] sugiere u n a amplia variedad de perlas de programación; Knuth [KNU98] ha escrito u n a serie clásica d e tres v o l ú m e n e s s o b r e el arte d e la programación, y Hunt |HUN99| sugiere directrices pragmáticas de programación. La bibliografía s o b r e p r u e b a s ha florecido en la década p a s a d a . Myers [MYE79] s e c o n s e r v a c o m o un clásico. Los libros d e Whitaker (How to Break Software, Addison-Wesley, 2002), Kaner y s u s colegas (Lessons Learned in Software Testing, Wiley, 2001) y Marick (The Craft of Software Testing, Prentice-Hall, 1997) presentan conceptos y principios importantes sobre las pruebas, así c o m o u n a guía pragmática considerable. En Internet existe u n a amplia variedad d e fuentes d e información sobre la práctica d e la ingeniería del software. En el sitio w e b d e SEPA se p u e d e encontrar u n a lista actualizada de referencias en la red mundial, las cuales son relevantes para la práctica d e la ingeniería de software:

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

TM

PDF Editor

C A P Í T U L O

6

INGENIERÍA DE S I S T E M A S CONCEPTOS CLAVE

H

ace casi 500 a ñ o s , Maquiavelo dijo: "No hay n a d a m á s difícil de llevar a cabo, m á s peligroso de realizar o de éxito m á s incierto que e n c a b e z a r la introducción de un n u e v o orden de cosas". Durante los 50 últimos a ñ o s , los s i s t e m a s b a s a d o s e n c o m p u t a d o r a h a n introducido u n n u e v o orden. Aunque la tecnología ha tenido varios a v a n c e s d e s d e la é p o c a d e Maquiavelo, sus palabras a ú n siguen vigentes. La ingeniería del s o f t w a r e ocurre c o m o consecuencia de un p r o c e s o llamado ingeniería de sistemas. En lugar de c o n c e n t r a r s e sólo e n el software, esta disciplina se centra e n una variedad de e l e m e n t o s mientras analiza, diseña y organiza aquellos e l e m e n t o s de u n sistema que pueden ser u n producto, un servicio o u n a tecnología para la transformación o control de información. El proceso de ingeniería de sistemas a s u m e distintas formas, según el dominio de aplicación e n que se utilice. La ingeniería de procesos de negocios se aplica c u a n d o el contexto del trabajo se enfoca en una e m p r e s a . C u a n d o se va a construir u n producto (en e s t e contexto un producto incluye todo, d e s d e un teléf o n o inalámbrico hasta un sistema de control de tráfico aéreo), al proceso se le llama ingeniería de producto. Tanto la ingeniería de p r o c e s o s de negocio c o m o la de producto intentan p o n e r orden en el desarrollo de sistemas b a s a d o s en c o m p u t a d o r a . Aunque cada uno de ellos se utiliza en u n dominio de aplicación diferente, a m b o s b u s c a n p o n e r al s o f t w a r e e n su contexto. Es decir, tanto la ingeniería d e procesos de

¿ Q u é e s ? Antes de que sea posible construir el software, por medio de la ingeniería, se debe entender el "sistema" en que éste reside. Pora lograrlo es necesario determinar el objetivo general del sistema; se debe identificar el papel que tienen el hardware, el software, las personas, las bases de datos, los procedimientos y otros elementos del sistema; y se deben identificar, analizar, especificar, modelar, validar y gestionar los requisitos operacionales. Estas actividades son el fundamento de la ingeniería de sistemas. ¿ Q u i é n lo h a c e ? Un ingeniero de sistemas trabaja para entender los requisitos de un sistema al trabajar con el cliente, usuarios futuros y otros -reresados.

¿Por qué

es

i m p o r t a n t e ? Existe u n a n t i g u o

proverbio que dice: "los árboles no dejan ver el bosque". En este contexto, el "bosque" es el sistema y los árboles son los elementos tecnológicos (incluido el software) que se requieren para realizar el sistema. Si se construyen los elementos tecnológicos de una manera precipitada antes de entender el sistema, sin duda se cometerán errores que decepcionarán al cliente Antes de preocuparse por los árboles se debe TM entender el bosque. ¿ C u á l e s s o n los p a s o s ? 5e identifican los objetivos y requisitos operacionales más detallados al obtener información del cliente; se analizan los requisitos para evaluar su claridad, si está completo y es consistente; se crea una especifi

PDF Editor cación,

q u e p o r lo general

está incorporada

a

133

PARTE DOS

134


un modelo de sistema, que después lo validan los participantes y clientes. Por último, se gestionan los requisitos del sistema para asegurar que los cambios se controlan de manera apropiada. ¿ C u á l e s el p r o d u c t o o b t e n i d o ? Se debe producir una representación efectiva del sistema, como consecuencia de b ingeniería del mismo. Se puede realizar a través de un prototipo, una especificación o incluso un modelo simbólico, pero debe comunicar las características operativas, funcionales y de comportamiento del siste-

ma que se va a construir e incorporarlo dentro de la arquitectura del sistema.

¿Cómo p u e d o estar seguro de que lo he h e c h o c o r r e c t a m e n t e ? Mediante una revisión de todos los productos de trabajo obtenidos, para verificar su claridad, si está completo y es consistente. Es importante mencionar que los cambios en los requisitos de un sistema deben gestionarse con métodos sólidos de GCS (capítulo 27).

negocios c o m o la ingeniería de producto, 1 trabajan p a r a asignar un papel al software de c o m p u t a d o r a y, al m i s m o tiempo, establecer los e n l a c e s que unen al software con otros elementos de un sistema b a s a d o en computadora. Este capítulo se centrará en las n e c e s i d a d e s de gestión y en las actividades específicas del proceso que permitan a la organización de s o f t w a r e asegurarse de hacer las c o s a s correctas en el tiempo correcto y del m o d o correcto.

6.1

S I S T E M A S BASADOS EN C O M P U T A D O R A La palabra sistema tal vez sea el término m á s u s a d o y del que m á s se abusa en el léxico técnico. Se habla de sistemas políticos, sistemas educativos, de sistemas de aviación y sistemas de fabricación, de sistemas bancarios y sistemas de locomoción. La palabra dice muy poco. El adjetivo se utiliza p a r a describir el sistema y así entender el contexto en el que se usa la palabra. El diccionario Webster define sistema de la siguiente m a n e r a : I. Un conjunto o disposición de cosas relacionadas q u e forman u n a unidad o un todo orgánico; 2. Una serie de hechos, principios, reglas, etcétera, clasificado y dispuestos de m a nera o r d e n a d a que m u e s t r a n un plan lógico de la unión de las partes; 3. Un m é t o d o o plan d e clasificación o disposición; 4. Una m a n e r a establecida d e h a c e r algo; método; procedimiento...

En el diccionario a p a r e c e n cinco definiciones más, pero no se sugiere un sinónimo preciso. Sistema

es u n a palabra especial. Al retomar la definición del diccionario TM Webster, un sistema b a s a d o e n c o m p u t a d o r a se define c o m o : Un conjunto o disposición d e e l e m e n t o s q u e están o r g a n i z a d o s para cumplir u n a meta

PDF Editor predefinida al procesar información.

1

En realidad, el término ingeniería de sistemas se emplea con frecuencia en este contexto. Sin embargo, para los propósitos de este libro "ingeniería de sistemas" es genérico y abarca la ingeniería de procesos del negocio y la ingeniería de producto.

CAPITULO 6

135


Es posible que la m e t a s e a apoyar una función de negocio o desarrollar un producto que pueda venderse para generar beneficios. Para cumplir la meta, un sistema b a s a d o en c o m p u t a d o r a emplea u n a variedad de e l e m e n t o s del sistema: S o f t w a r e . Programas de computadora, estructuras de d a t o s y documentación ÔNSEJQÍ^

r a debe coer en lo i de tener una i 'centrodo en el i'.Fara '.deben r todos los i de un i antes de í en el

que sirven para hacer efectivo el método, procedimiento o control lógico que se requiere. H a r d w a r e . Dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión (por ejemplo, c o n m u t a d o r e s de red, dispositivos de telecomunicación) que permiten el flujo de datos, y dispositivos electromecánicos (como sensores, motores, bombas) que proporcionan u n a función externa, del m u n d o real. P e r s o n a s . Usuarios y o p e r a d o r e s del h a r d w a r e y software. B a s e s d e d a t o s . Una extensa y organizada recopilación de información a la cual s e tiene acceso a través de software y que persiste a través del tiempo. D o c u m e n t a c i ó n . Información descriptiva (por ejemplo, modelos, especificaciones, manuales, archivos de ayuda en línea, sitios web) que detalla el uso y operación del sistema. P r o c e d i m i e n t o s . Los p a s o s que definen el uso específico de cada e l e m e n t o del sistema o el contexto de procedimiento e n que reside el sistema. Estos e l e m e n t o s se c o m b i n a n de varias m a n e r a s para transformar la información. Por ejemplo, un d e p a r t a m e n t o de mercadotecnia transforma la información bruta de v e n t a s en un perfil del c o m p r a d o r típico del producto; un robot transforma un archivo d e ó r d e n e s que contiene instrucciones específicas en un conjunto de señales de control que provocan alguna acción física específica. La creación de un sistema de información para asesorar al departamento de mercadotecnia y un software de control para el robot requiere de la ingeniería de sistemas. "Nunca confíes en una computadora que no puedas lanzar por la ventana." Stcve Woiniak

K

CL/AVE complejos •eafcdod una

Una característica complicada de los sistemas b a s a d o s e n computadora e s que tal vez constituyen un m a c r o e l e m e n t o de u n sistema a ú n mayor. El macroelemento es un sistema b a s a d o e n c o m p u t a d o r a que es parte de un sistema mayor b a s a d o t a m bién en computadora. Por ejemplo, un sistema de automatización

de una ftbnca se TM considera u n a jerarquía de sistemas. En el nivel m á s b a j o de la jerarquía se e n c u e n tra u n a máquina de control numérico, robots y dispositivos de e n tr a da de informa

squea i sistemas.

PDF Editor

ción. Cada uno de é s t o s es un sistema b a s a d o e n computadora por d e r e c h o propio. Los elementos de la m á q u i n a de control numérico incluyen h a r d w a r e electrónico y

electromecánico (por ejemplo, procesador y memoria, motores, sensores), s o f t w a r e (para c o m u n i c a c i o n e s y control de la máquina), p e r s o n a s (el operador de la máquina), u n a b a s e de d a t o s (el p r o g r a m a de CN almacenado), documentación y procedí-

136

PARTE DOS


mientos. Podría aplicarse u n a descomposición similar al robot y al dispositivo de e n t r a da de información. Todos son sistemas b a s a d o s e n computadora. En el siguiente nivel de la jerarquía se define u n a célula de fabricación.

Ésta e s ur

sistema b a s a d o en computadora que p u e d e tener e l e m e n t o s propios (por ejemplo, c o m p u t a d o r a s , instalaciones mecánicas), y también integra los m a c r o e l e m e n t o s que se han d e n o m i n a d o máquina de control numérico, robot y dispositivo de entrada de información. En r e s u m e n , la célula de fabricación y sus m a c r o e l e m e n t o s están c o m p u e s t o s de e l e m e n t o s del sistema con las etiquetas genéricas: software, hardware, personas b a s e s de datos, procedimientos y documentación. En algunos c a s o s los macroelem e n t o s p u e d e n compartir un e l e m e n t o genérico. Por ejemplo, el robot y la máquina de CN podría operarlas el m i s m o operador (el e l e m e n t o personas). En otros casos, los e l e m e n t o s genéricos son exclusivos de un sistema. El papel del ingeniero de sistemas es definir los e l e m e n t o s de u n sistema específico b a s a d o en c o m p u t a d o r a e n el contexto de la jerarquía global de sistemas (macroelementos). En las secciones siguientes se e x a m i n a n las t a r e a s que constituyen la ingeniería de sistemas de c o m p u t a d o r a s .

L H J E R A R Q U Í A P E LA I N G E N I E R Í A P E S I S T E M A S Sin importar su dominio de enfoque, la ingeniería de sistemas abarca una serie de m é t o d o s para navegar de arriba hacia a b a j o y de a b a j o hacia arriba en la jerarquía T j s o e r ó de Sistemas X 5 S ) proporciona M á s tuertes útiles en wwwjKose.org.

\ CLÁVE
•nuera progresiva, el

ilustrada e n la figura 6.1. El proceso de la ingeniería de s i s t e m a s por lo general c o m i e n z a con u n a "visión global". Es decir, se examina el dominio entero del negocio o producto para asegurarse de que se p u e d e establecer el contexto tecnológico o de negocios apropiado. La visión global es refinada para e n f o c a r s e totalmente en un dominio específico de interés. Dentro de u n dominio especial se analiza la necesidad de elementos del sistema (por ejemplo, información, software, hardware, personas). Al final se inicia el análisis, diseño y construcción del e l e m e n t o del sistema deseado. En la parte alta de la jerarquía se establece u n contexto muy amplio, y en el de la parte baja se conducen actividades técnicas detalladas, realizadas por la disciplina de ingeniería correspondiente (por ejemplo, ingeniería de hardware o software). 2 Dicho de u n a m a n e r a u n p o c o m á s formal, la visión global (VG) la c o m p o n e un conjunto de dominios (D,) en d o n d e c a d a uno de ellos p u e d e ser un sistema o un sistema de sistemas por derecho propio. TM VG = (D„ D2, D3,.... Dn 1

e v o q u e se delimita

ñosta lo comprensión

Cada dominio lo c o m p o n e n elementos (E;) específicos, los cuales tienen un papel para cumplir el objetivo y las m e t a s del dominio o componente:

PDF Editor

de los detalles técnicos.

2

Sin embargo, en algunas situaciones los ingenieros del sistema deben considerar primero los elementos individuales del sistema. Mediante el uso de este enfoque, los subsistemas se describen de abajo hacia arriba al considerar primero los componentes detallados que forman el subsistema.

CAPITULO 6 A'

-

137


I£;/ £2. £3,

£m)

Por último, cada e l e m e n t o se implementa al especificar los componentes cos que logran la función necesaria para un elemento: E¡ = I C „ C 2 , C A

(Q) técni-

Cjtl

En el contexto de software un c o m p o n e n t e podría ser un p r o g r a m a de c o m p u t a d o ra, un c o m p o n e n t e reutilizable de u n programa, un módulo, u n a clase u objeto o incluso un enunciado en lenguaje de programación. "Siempre diseño los cosos considerándolos en su contexto inmediato superior: uno silla en un cuorto, un cuarto en una casa, uno casa en un vecindario, un vecindario en un plan urbano." Eliel S a a r i n e n

Es importante notar que el ingeniero de sistemas estrecha m á s el e n f o q u e de trabajo conforme a v a n z a hacia a b a j o e n la jerarquía descrita. Sin embargo, la visión global muestra u n a clara definición de la funcionalidad general que le permitirá al ingeniero e n t e n d e r el dominio y el sistema o producto e n el contexto apropiado.

de de

Dominio d e negó, o d e producto

Visión global

Dominio d e interés

Elemento del sistema

Visión del dominio

Visión del e l e m e n t o

r I~t ri r dr í n 111 r ~I L iL LiU I I I I11l ü ~ z~ m i 111111 ~T Tif f rl 1n 11

TM

Visión detallada

PDF Editor 6.2.1


El modelado de sistemas es un e l e m e n t o importante del proceso de ingeniería de sis-

temas. Sin importar que el e n f o q u e esté en la visión global o en la visión detallada, el ingeniero crea modelos que [MOT92]:

138

PARTE DOS

¿Qué se • logro ton el modelo de lo ingeniería de sistemas?


• Definen los procesos que satisfacen las necesidades de la visión que se considera • Representen el comportamiento de los procesos y los supuestos en los que se basa el comportamiento. • Definen de modo explícito las entradas exógenas 3 y endógenas de información al modelo. • Representan todas las uniones (incluidas las salidas) que permiten al ingeniero entender mejor la visión. Al construir un modelo del sistema el ingeniero debe considerar algunas restricciones: 1. Supuestos que reducen el número de permutaciones y variaciones posibles, lo que permite al modelo reflejar el problema de una manera razonable. Por ejemplo, un producto de representación tridimensional que utiliza la industria del entretenimiento para crear animaciones realistas. Un dominio del producto permite la representación de formas h u m a n a s en tres dimensiones. Las entradas a este dominio comprenden la habilidad de adaptar movimiento de un actor h u m a n o vivo, de un video o de la creación de modelos gráficos. El ingeniero de sistemas hace ciertos supuestos sobre el intervalo de movimiento h u m a n o permitido (por ejemplo, las piernas n o pueden enrollarse alrededor del torso) de modo que pueda limitarse el proceso y la gama de entradas. 2. Simplificaciones que permiten la creación del modelo a tiempo. Para ilustrarlo se puede considerar una compañía de productos de oficina que vende y suministra una amplia variedad de fotocopiadoras, escáneres y equipos similares. El ingeniero de sistemas modela las necesidades de la organización suministradora y trabaja para entender el flujo de información que engendra una orden de suministro. Aunque una orden de suministro puede originarse desde muchas fuentes, el ingeniero toma en cuenta sólo dos de ellas: la demanda interna y la petición externa. Esto permite una partición simplificada de entradas que se requiere para generar la orden de suministro.

%

CLAVE

3. Limitaciones que ayudan a delimitar el sistema. Por ejemplo, se modela un sistema de aeronáutica para un avión de próxima generación. Como el avión tiene un diseño de dos motores, el dominio de monitoreo para la propulsión será modelado para acomodar un máximo de dos motores y sus numerosos sistemas asociados.

Un ingeniero d e sistemas considera los siguientes factores al determinar soluciones alternativas: supuestos, simplificaciones, limitaciones, restricciones y preferencias del cliente.

4 . Restricciones que guían la manera de crear el modelo y tomar el enfoque al TM implementarlo. Por ejemplo, la infraestructura tecnológica para el sistema de representación tridimensional descrito antes utiliza procesadores duales basados en G5. La complejidad de cálculo de los problemas debe restringirse para encajar en los límites de proceso que imponen estos procesadores.

PDF Editor 3

Las entradas exógenas unen un elemento de una visión dada con otros elementos en el mismo nivel o en otros niveles; las entradas endógenas unen componentes individuales de un elemento en una visión particular.

CAPÍTULO 6


139

5 . Preferencias q u e indican la arquitectura preferida p a r a t o d o s los d a t o s , funcion e s y tecnología. La solución preferida a v e c e s entra en conflicto c o n otros f a c t o r e s restrictivos. Sin e m b a r g o , la satisfacción del cliente m u c h a s v e c e s s e t o m a e n c u e n t a h a s t a el p u n t o de realizar su e n f o q u e preferido. El m o d e l o d e s i s t e m a resultante (desde cualquier visión) p u e d e reclamar u n a solución a u t o m á t i c a por completo, s e m i a u t o m á t i c a o un e n f o q u e m a n u a l . De hecho, c o n f r e c u e n c i a e s posible caracterizar m o d e l o s d e c a d a tipo q u e sirvan c o m o s o l u c i o n e s alternativas del p r o b l e m a q u e s e tiene entre m a n o s . En e s e n c i a , el ingeniero d e sist e m a s t a n sólo modifica la influencia relativa d e diferentes e l e m e n t o s del s i s t e m a (personas, h a r d w a r e , software) p a r a crear m o d e l o s de c a d a tipo. "Las cosos simples deben set sim )les. Las tosas complejos deben ser posibles." Alan Kay

6.2.2

*

idelo ~é simuloi sistema unentoel 'pmyecto. rio áeutüuar x proceso ' el cual rvn émbolo en ieroaón, y

Simulación d e l s i s t e m a

Muchos s i s t e m a s b a s a d o s en c o m p u t a d o r a interactúan c o n el m u n d o real en forma reactiva. Es decir, los e v e n t o s del m u n d o real los m o n i t o r e a n el h a r d w a r e y el softw a r e q u e c o m p o n e n el s i s t e m a b a s a d o e n c o m p u t a d o r a y, con b a s e e n e s t o s e v e n tos, el s i s t e m a i m p o n e control s o b r e las m á q u i n a s , los p r o c e s o s e incluso s o b r e la g e n t e q u e g e n e r a los eventos. Los s i s t e m a s de t i e m p o real y s i s t e m a s e m p o t r a d o s a m e n u d o p e r t e n e c e n a la categoría d e s i s t e m a s reactivos. Muchos s i s t e m a s d e la categoría d e los reactivos c o n t r o l a n m á q u i n a s o p r o c e s o s (como a e r o l í n e a s c o m e r c i a l e s o refinerías d e petróleo) que d e b e n o p e r a r c o n u n g r a d o m u y alto de confiabilidad. Si el s i s t e m a falla p o d r í a n ocurrir p é r d i d a s c c o n ó m i c a s o h u m a n a s significativas. Por esta r a z ó n , el m o d e l a d o del sistema y las herram i e n t a s d e simulación s e utilizan p a r a a y u d a r a eliminar s o r p r e s a s c u a n d o s e c o n s truyen sistemas reactivos b a s a d o s en computadora. Estas herramientas s e aplican d u r a n t e el proceso de ingeniería de sistemas, c u a n d o s e especifica el papel del hard-

jízor oíros poro afinarware, el software, las b a s e s de d a t o s y las personas. El m o d e l a d o y las herramientas d e simulación permiten al ingeniero d e sistemas probar u n a especificación del sistema.


Herramientas

de simulación

del sistema

O b j e t i v o : Las herramientas d e simulación del sistema proporcionan al ingeniero d e software c capacidad de predecir el comportamiento d e un

TM

funcionamiento, operación y respuesta antes d e la implementación real. M e c á n i c a : Las herramientas d e esta categoría permiten

PDF Editor esterna de tiempo real antes d e q u e éste se construya.

al equipo definir los elementos d e un sistema b a s a d o

Además, estas herramientas permiten al ingeniero d e

en computadoras, y después ejecutar varias

software desarrollar maquetas del sistema en tiempo

simulaciones p a r a entender mejor las características operacionales y el desempeño general del sistema.

-«al, lo que permite al cliente tener una visión del

N

Y

140

r

PARTE D O S


Existen d o s a m p l i a s c a t e g o r í a s d e simulación del

Simics,

d e s a r r o l l a d o p o r Virtutech (www.virtutech.com), e s

sistema: 1) h e r r a m i e n t a s d e propósitos g e n e r a l e s q u e

u n a p l a t a f o r m a d e simulación d e sistema q u e p u e d e

p u e d e n m o d e l a r d e m a n e r a virtual cualquier sistema

m o d e l a r y a n a l i z a r sistemas b a s a d o s e n h a r d w a r e y

b a s a d o en c o m p u t a d o r a s , y 2) h e r r a m i e n t a s d e

software.

propósitos e s p e c i a l e s , q u e e s t á n d i s e ñ a d a s p a r a e m p l e a r l a s en un d o m i n i o d e aplicación específica

SIX, d e s a r r o l l a d o p o r Wolverine S o f t w a r e (www.wolverine.com), p r o p o r c i o n a b l o q u e s d e

(como e n sistemas d e a e r o l í n e a s , sistemas d e

construcción d e p r o p ó s i t o g e n e r a l p a r a m o d e l a r el

m a n u f a c t u r a , sistemas electrónicos).

Herramientas representativas 4 CSIM, d e s a r r o l l a d o p o r Lockheed Martín A d v a n c e d

d e s e m p e ñ o d e u n a a m p l i a v a r i e d a d d e sistemas. En h t t p : / / w w w . i d s i a . c h / ~ a n d r e a / s i m t o o l s . h t m l se p u e d e e n c o n t r a r u n a serie d e vínculos a v a r i a s fuentes d e

Technology Labs [www.all.extemal.lnco.com), e s un

simulación d e sistemas.

simulador d e eventos discretos d e propósitos g e n e r a l e s p a r a sistemas o r i e n t a d o s a d i a g r a m a s d e edificios.

La m e t a d e la ingeniería de procesos

de negocios

(IPN) e s definir a r q u i t e c t u r a s q u e per-

m i t a n q u e u n n e g o c i o utilice i n f o r m a c i ó n de m a n e r a efectiva. C u a n d o l a s n e c e s i d 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 s e o b s e r v a n d e m a n e r a global casi n o h a y d u d a d e q u e s e r e q u i e r a la i n g e n i e r í a de s i s t e m a s . No s ó l o s e r e q u i e r e la e s p e c i f i c a c i ó n d e la a r q u i t e c t u r a d e c ó m p u t o a p r o p i a d a , s i n o t a m b i é n s e d e b e d e s a rrollar la a r q u i t e c t u r a d e s o f t w a r e q u e p u e b l a la c o n f i g u r a c i ó n ú n i c a d e f u e n t e s de c ó m p u t o d e la o r g a n i z a c i ó n . La i n g e n i e r í a d e p r o c e s o s de n e g o c i o s e s u n e n f o q u e q u e c r e a u n plan g e n e r a l p a r a i m p l e m e n t a r la a r q u i t e c t u r a d e c ó m p u t o [SPE93],

•

¿Cuáles son las

Se d e b e n a n a l i z a r y d i s e ñ a r t r e s a r q u i t e c t u r a s d i f e r e n t e s d e n t r o del c o n t e x t o d e o b j e t i v o s y m e t a s de n e g o c i o s .

• r q a r t e r t u r a s que se definen y

• A r q u i t e c t u r a de d a t o s

desarrollan como

• A r q u i t e c t u r a de a p l i c a c i o n e s

p r t e de la IPN?

• I n f r a e s t r u c t u r a d e la t e c n o l o g í a La arquitectura

de datos p r o p o r c i o n a u n m a r c o de t r a b a j o p a r a las n e c e s i d a d e s de

i n f o r m a c i ó n d e u n n e g o c i o o d e u n a f u n c i ó n d e n e g o c i o s . Los ladrillos d e la arquit e c t u r a s o n l o s o b j e t o s de d a t o s q u e utiliza el n e g o c i o . Un o b j e t o de los d a t o s c o n t i e n e u n c o n j u n t o de a t r i b u t o s q u e d e f i n e algún a s p e c t o , c u a l i d a d , c a r a c t e r í s t i c a o d e s c r i p t o r d e los d a t o s q u e s e d e s c r i b e n .

TM

Una v e z d e f i n i d o u n c o n j u n t o d e d a t o s s e identifican s u s r e l a c i o n e s . Una relación

PDF Editor

indica la f o r m a e n q u e l o s o b j e t o s e s t á n c o n e c t a d o s e n t r e sí. C o m o e j e m p l o s e p u e -

4

Las herramientas mostradas aquí son una muestra de esta categoría. En la mayoría de los casos los nombres están registrados por sus respectivos desarrolladores.

CAPÍTULO 6

141


d e n c o n s i d e r a r l o s o b j e t o s c l i e n t e y p r o d u c t o A . Los d o s o b j e t o s p u e d e n c o n e c t a r s e p o r la r e l a c i ó n compra-, e s decir, u n c l i e n t e compra comprado

p r o d u c t o A o p r o d u c t o A es

por u n c l i e n t e . Los o b j e t o s de d a t o s (que p u e d e n existir c i e n t o s o h a s t a

m i l e s p a r a u n a act i vi dad d e n e g o c i o s i m p o r t a n t e ) fluyen e n t r e f u n c i o n e s d e n e g o c i o , e s t á n o r g a n i z a d o s d e n t r o d e u n a b a s e de d a t o s y s e t r a n s f o r m a n p a r a o f r e c e r inform a c i ó n q u e s a t i s f a c e l a s n e c e s i d a d e s del n e g o c i o . ÔNSEJO^ de no debe en PEI ni Sin embargo, i que estos nosehan el ingeniero . oíos que el m/yoyecloes

La arquitectura

de aplicación

abarca aquellos elementos de un sistema que trans-

f o r m a n o b j e t o s d e n t r o d e la a r q u i t e c t u r a d e d a t o s p o r a l g ú n p r o p ó s i t o del n e g o c i o . En el c o n t e x t o d e e s t e libro s e c o n s i d e r a q u e la a r q u i t e c t u r a d e aplicación e s el sist e m a d e p r o g r a m a s (software) q u e r e a l i z a e s t a t r a n s f o r m a c i ó n . Sin e m b a r g o , e n un c o n t e x t o m á s a m p l i o , la a r q u i t e c t u r a d e a p l i c a c i ó n p u e d e i n c o r p o r a r el p a p e l de las p e r s o n a s ( q u i e n e s s o n t r a n s f o r m a d o r e s y u s u a r i o s de i n f o r m a c i ó n ) y p r o c e d i m i e n t o s de negocios que n o han sido automatizados. La infraestructura

tecnológica

p r o p o r c i o n a el f u n d a m e n t o p a r a las e s t r u c t u r a s d e

d a t o s y d e a p l i c a c i ó n . La i n f r a e s t r u c t u r a c o m p r e n d e el h a r d w a r e y el s o f t w a r e c o n q u e s e a p o y a n l a s a p l i c a c i o n e s y los d a t o s . E s t o incluye c o m p u t a d o r a s , s i s t e m a s d e o p e r a c i ó n , r e d e s de c o m p u t a d o r a , e n l a c e s de t e l e c o m u n i c a c i o n e s , tecnologías d e a l m a c e n a m i e n t o y la a r q u i t e c t u r a (por e j e m p l o , cliente, servidor) d i s e ñ a d a p a r a i m p l e mentar estas tecnologías. En la figura 6.2 se d e f i n e e ilustra u n a j e r a r q u í a d e p r o c e s o d e n e g o c i o s p a r a modelar estas arquitecturas de sistema.

jerarquía La e m p r e s a .

«a del de

Planeación estratégica de la información (visión global)

Area de negocio Un á r e a d e neg ocio

Análisis del

área de negocio (visión d e dominio)

1 L Requisito d e p r o c e s o

TM

PDF Editor

Ingeniero de software

Construcción e integración (visión detallada)

11

142

CAPÍTULO

6


La m e t a d e la ingeniería

de producto

e s t r a d u c i r el d e s e o del cliente, d e u n a serie de

c a p a c i d a d e s d e f i n i d a s , a u n p r o d u c t o del t r a b a j o . P a r a c o n s e g u i r e s t a m e t a la ingeniería d e p r o d u c t o — c o m o la i n g e n i e r í a d e p r o c e s o s d e n e g o c i o s — d e b e c r e a r u n a a r q u i t e c t u r a y u n a e s t r u c t u r a . La a r q u i t e c t u r a a b a r c a c u a t r o c o m p o n e n t e s d e sistem a distintos: s o f t w a r e , h a r d w a r e , d a t o s (y b a s e s de datos) y p e r s o n a s . Se e s t a b l e c e u n a i n f r a e s t r u c t u r a de s o p o r t e e incluye la t e c n o l o g í a r e q u e r i d a p a r a u n i r l o s c o m p o n e n t e s y la i n f o r m a c i ó n ( c o m o d o c u m e n t o s , CD-ROM, video) q u e s e e m p l e a para ^CONSEJOÂ menudo se utiliza en este contexto el modelo concurrente del proceso (capítulo 3). Coda disciplina de ingeniería trabaja en paralelo. Se áebe estar seguro de que se promueva la comunicación mientras cada disciplina desempeña su trabajo.

d a r s o p o r t e a los c o m p o n e n t e s . C o m o lo m u e s t r a la figura 6.3, la visión global s e c o n s i g u e m e d i a n t e la i n g e n i e r í a d e r e q u i s i t o s (capítulo 7). Los r e q u i s i t o s g e n e r a l e s del p r o d u c t o s e o b t i e n e n del cliente. E s t o s r e q u i s i t o s c o m p r e n d e n n e c e s i d a d e s de i n f o r m a c i ó n y c o n t r o l , f u n c i o n a l i d a d del p r o d u c t o y c o m p o r t a m i e n t o , d e s e m p e ñ o g e n e r a l del p r o d u c t o , d i s e ñ o , restricc i o n e s de la i n t e r f a z y o t r a s n e c e s i d a d e s e s p e c i a l e s . U n a v e z q u e s e c o n o c e n e s t o s r e q u i s i t o s , el t r a b a j o de la i n g e n i e r í a de r e q u i s i t o s e s a s i g n a r f u n c i ó n y c o m p o r t a m i e n t o a c a d a u n o de los c u a t r o c o m p o n e n t e s a n t e s d e s c r i t o s . U n a v e z h e c h a la a s i g n a c i ó n c o m i e n z a la i n g e n i e r í a d e c o m p o n e n t e s del s i s t e m a . La ingeniería d e c o m p o n e n t e s del s i s t e m a e s e n r e a l i d a d u n c o n j u n t o de a c t i v i d a d e s c o n c u r r e n t e s q u e dirige p o r s e p a r a d o c a d a u n o d e los c o m p o n e n t e s del s i s t e m a i n g e n i e r í a d e s o f t w a r e , i n g e n i e r í a d e h a r d w a r e , ingeniería h u m a n a e i n g e n i e r í a de

La jerarquía de

El producto completo

la ingeniería d e

productos.

Ingeniería de requisitos (visión global)

Capacidades

Hardware

Software

Ingeniería de componente (visión de dominio)

Requisito d e p r o c e s o

Datos

Función

1 11 m i

Comportamiento

ITT

M o d e l a d o de análisis y diseño (visión del elemento)

TM

PDF Editor Componentes d e programa

Construcción e integración (visión detallada)

Ingeniero de software

CAPÍTULO 6

143


b a s e s d e d a t o s . C a d a u n a de e s t a s disciplinas d e i n g e n i e r í a t o m a u n a v i s i ó n d e d o m i n i o específica, p e r o e s i m p o r t a n t e s e ñ a l a r q u e l a s d i s c i p l i n a s d e i n g e n i e r í a d e b e n e s t a b l e c e r y m a n t e n e r u n a c o m u n i c a c i ó n a c t i v a e n t r e ellas. Parte del p a p e l d e la ingeniería de r e q u i s i t o s e s e s t a b l e c e r los m e c a n i s m o s d e i n t e r f a z q u e p e r m i t a n q u e esto suceda. La visión d e e l e m e n t o p a r a la i n g e n i e r í a d e p r o d u c t o e s la disciplina d e i n g e n i e ría a p l i c a d a a u n c o m p o n e n t e a s i g n a d o . P a r a la ingeniería d e s o f t w a r e e s t o significa a c t i v i d a d e s d e m o d e l a d o del a n á l i s i s y d i s e ñ o (cubierto e n detalle e n c a p í t u l o s p o s teriores) y a c t i v i d a d e s de c o n s t r u c c i ó n y d e s p l i e g u e q u e a b a r c a n : g e n e r a c i ó n d e c ó d i g o , p r u e b a s y tareas" de s o p o r t e . Los m o d e l o s de a n á l i s i s de t a r e a s a s i g n a n requisitos a las r e p r e s e n t a c i o n e s d e d a t o s , f u n c i ó n y c o m p o r t a m i e n t o . El d i s e ñ o c o n v i e r te el m o d e l o de a n á l i s i s e n d i s e ñ o s d e d a t o s , a r q u i t e c t ó n i c o s , d e i n t e r f a z y e n el nivel d e c o m p o n e n t e s del s o f t w a r e .

HOGARSEGURO

Ingeniería

de sistema preliminar

El e s c e n a r i o : Lugar d e trabajo : d e ingeniería del software después d e la ¡unía e> inicio d e HogarSeguro s: Jamie Lazar, miembro del equipo d e Vinod Raman, miembro del equipo d e Ed Robbins, miembro del equipo d e software,

rsación: 3 que estuvo muy bien. Sí

pero todo lo que hicimos fue ver el sistema

general; todavía tenemos q u e reunir muchos p a r a hacer el software. Por eso tenemos juntas adicionales s en los próximos cinco días. Por cierto, aue dos de los "dientes" estuvieran aquí en las semanas. Ya sabes, q u e estén con nosotros zoe podamos comunicarnos en realidad y . ¿Y q u é opinaron los demás? Bueno, me miraron como si estuviera loco, pero

Ed: Ya les m a n d e a los d o s una copia por correo electrónico. Revísenla y luego hablamos V i n o d : ¿Qué te p a r e c e después d e la comida? (Jamie y Vinod recibieron el siguiente texto d e Ed.) Notas preeliminares d e la estructura/funcionalidad d e HogarSeguro: • El sistema utilizará una o más PC. varios paneles de control manuales y montables en la p a r e d , varios sensores y varios controladores d e dispositivos/aplicaciones.

• Todos se comunicarán por protocolos inalámbricos (por ejemplo, 802.1 Ib) y serán diseñados p a r a la construcción efe casas nuevas y la aplicación en casas existentes. • Todo el hardware, a excepción d e nuestra nueva cajo inalámbrica, estará fuera del anaquel Funcionalidad básica del software obtenida d e la conversación d e inicio. Funciones d e seguridad d e la casa:

TM

[el gerente d e ingeniería del software] le gustó la - e s ágil- así que está h a b l a n d o con ellos.

• Sensor d e movimiento d e puerta/ventana p a r a monitorear un acceso n o autorizado (robos).

PDF Editor io

estaba tomando notas con mi PDA durante la

v obtuve uno lista d e funciones básicas. Q u é bien, déjame ver.

• Moni toreo d e fuego y humo

• Monitoreo d e nivel d e a g u a en sótano (por ejemplo, inundoción o rompimiento del calentador d e aguo).

144

PARTE DOS


•

Monitoreo d e movimiento en el exterior.

• Disponer un m e n s a j e en la máquina contestadora.

•

C a m b i o d e colocación d e seguridad por Internet.

• Contactar v e n d e d o r e s p a r a suspender e n t r e g a d e periódicos, correo, etcétera.

Funciones d e vigilancia en la c a s a : •

Conectar a u n a o m á s c á m a r a s d e video colocadas f u e r a / d e n t r o d e la c a s a .

Funciones d e la gestión d e comunicación: •

Funciones d e la m á q u i n a contestadora.

•

Controlar p a n o r a m a / z o o m en las c á m a r a s .

•

Definir z o n a s d e monitoreo d e las c á m a r a s .

•

Lista d e llamadas a través d e un identificador.

•

Mostrar tomas d e la c á m a r a e n PC.

•

Hora del m e n s a j e .

•

Tener acceso a las tomas d e la c á m a r a vía Internet.

• Texto del m e n s a j e a través d e un sistema d e

•

G r a b a r digital y selectivamente las tomas d e b cámara.

•

reconocimiento d e voz. •

Mostrar d e nuevo las tomas d e la c á m a r a .

Funciones del c o r r e o electrónico (todas las funciones estándares del c o r r e o electrónico). • Mostrar correo electrónico estándar

Funciones d e la gestión d e la c a s a : •

Controlar a l u m b r a d o .

•

Controlar instrumentos.

• •

• Controlar HVAC. •

Controlar e q u i p o d e a u d i o / v t d e o en la c a s a

•

Habilitar la c a s a dentro d e u n a modalidad "vacaciones/viaje" con un conjunto d e botones: • Disponer a p a r a t o s / a l u m b r a d o / H V A C p a r a que actúen d e m a n e r a a p r o p i a d a

6.5

Lectura d e voz por correo electrónico vía a c c e s o telefónico.

Directorio telefónico personal.

• Vínculo con el PDA. O t r a s funciones: Por definirse. Todas las funciones serán accesibles vía Internet con una contraseña a p r o p i a d a c o m o protección.

M O D E L A D O DEL S I S T E M A Debido a que un sistema p u e d e representarse con diferentes g r a d o s de abstracción (por ejemplo, la visión global, la visión de dominio, la visión de elemento), los modelos de sistema tienden a ser jerárquicos o estratificados por naturaleza. En la parte m á s alta de la jerarquía se p r e s e n t a u n m o d e l o del sistema completo (la visión global) . Los objetos principales de datos, las funciones de p r o c e s a m i e n t o y los comportamientos se representan sin incluir el c o m p o n e n t e del sistema que implementará los e l e m e n t o s del m o d e l o de visión global. A medida que la jerarquía se refina o estratifica se modela el detalle al nivel de c o m p o n e n t e s (en e s t e caso, representaciones de hardware, software, etcétera). Al final, los m o d e l o s de sistemas evolucion a n a modelos de ingeniería (los cuales se refinan después) que son TMespecíficos para la disciplina de ingeniería apropiada.

PDF Editor 6.5.1

M o d e l a d o Hatley-Pirbhcri

Todo sistema b a s a d o en c o m p u t a d o r a p u e d e modelarse c o m o transformación de la información al emplear una plantilla de entrada-proceso-salida. Hatley y Pirbha; [HAT87] han ampliado esta visión p a r a incluir dos características adicionales del sis-

tema: p r o c e s a m i e n t o de la interfaz del usuario y m a n t e n i m i e n t o y p r o c e s a m i e n t o de

CAPITULO 6


145

autocomprobación. Aunque estas características adicionales n o están presentes en t o d o s los s i s t e m a s b a s a d o s e n c o m p u t a d o r a , s o n c o m u n e s y su e s p e c i f i c a c i ó n h a c e que cualquier modelo de sistema sea m á s robusto. Con el u s o d e la r e p r e s e n t a c i ó n d e e n t r a d a , p r o c e s a m i e n t o , salida, p r o c e s a m i e n t o s d e la i n t e r f a z del u s u a r i o y p r o c e s a m i e n t o d e a u t o c o m p r o b a c i ó n , u n i n g e n i e r o d e s i s t e m a s p u e d e c r e a r u n m o d e l o de c o m p o n e n t e s d e s i s t e m a q u e d e j e un f u n d a -

K

m e n t o p a r a e t a p a s p o s t e r i o r e s e n c a d a u n a de l a s disciplinas d e ingeniería. En el d e s a r r o l l o d e u n m o d e l o d e s i s t e m a s e utiliza u n a plantilla m o d e l o del sist e m a [HAT87]. El i n g e n i e r o de s i s t e m a s a s i g n a e l e m e n t o s d e s i s t e m a a c a d a u n a de

CLAVE i -epcesenta lo i.el >ylo ) ton lo r del usuario y •/

l a s c i n c o r e g i o n e s d e p r o c e s a m i e n t o d e n t r o d e la plantilla: 1) i n t e r f a z del u s u a r i o , 2) e n t r a d a , 3) f u n c i o n a m i e n t o y control del s i s t e m a , 4) salida, y 5) m a n t e n i m i e n t o y autocomprobación. Al igual q u e c a s i t o d a s las t é c n i c a s de m o d e l a d o u t i l i z a d a s e n la i n g e n i e r í a d e s i s t e m a s y d e s o f t w a r e , la plantilla m o d e l o del s i s t e m a le p e r m i t e al a n a l i s t a c r e a r u n a j e r a r q u í a e n detalle. En el nivel m á s a l t o d e la j e r a r q u í a e s t á el diagrama del sistema

de contexto

(DCS). El d i a g r a m a d e c o n t e x t o " e s t a b l e c e los limites d e i n f o r m a c i ó n

e n t r e el s i s t e m a q u e i m p l e m e n t a y el a m b i e n t e e n el q u e o p e r a el s i s t e m a " [HAT87]. Es decir, el DCS d e f i n e t o d o s los p r o d u c t o r e s e x t e r n o s de i n f o r m a c i ó n q u e el s i s t e m a utiliza, t o d o s los c o n s u m i d o r e s e x t e m o s de i n f o r m a c i ó n q u e el s i s t e m a crea, y t o d a s l a s e n t i d a d e s q u e se c o m u n i c a n a t r a v é s de la i n t e r f a z o r e a l i z a n m a n t e n i miento y autocomprobación. P a r a ilustrar el u s o del DCS s e c o n s i d e r a r á u n sistema transportadora

de clasificación

de cinta

(SCCT) d e s c r i t o e n la s i g u i e n t e d e c l a r a c i ó n (un t a n t o c o n f u s a ) de

objetivos: El SCCT debe desarrollarse de manera que las cajas que se mueven a lo largo de la cinta transportadora sean identificadas y ordenadas en uno de los seis contenedores al final de la cinta. Las cajas pasarán a través de una estación clasificadora, donde se identificarán. Con base en un número de identificación impreso en un lateral tle la caja y un coillyo de barras, las cajas se mandarán a los contenedores apropiados. Las cajas pasan en un orden aleatorio y están igualmente espaciadas. La linea se mueve con lentitud. Una computadora de escritorio localizada en la estación clasificadora ejecuta todo el software del SCCT, interactúa con el lector de código de barras para leer números de parte en cada caja, interactúa con el equipo de monitoreo de la línea transportadora para obtener la velocidad de la linea transportadora, almacena todos los números de parte clasificados, interactúa con un operador de la estación clasificadora para producir varios TM las cajas, y reportes y diagnósticos, manda señales de control al hardware para clasificar se comunica con un sistema de automatización central de la fábrica.

PDF Editor

El DCS p a r a el SCCT s e m u e s t r a e n la figura 6.4. El d i a g r a m a s e divide e n c i n c o s e g m e n t o s principales. El s e g m e n t o de arriba r e p r e s e n t a el p r o c e s a m i e n t o de la i n t e r f a z del u s u a r i o , y los s e g m e n t o s d e la i z q u i e r d a y d e la d e r e c h a m u e s t r a n el p r o c e s a m i e n t o d e e n t r a d a y d e salida, r e s p e c t i v a m e n t e . El s e g m e n t o c e n t r a l c o n t i e n e f u n -

c i o n e s d e control y p r o c e s o , y el s e g m e n t o d e a b a j o s e e n f o c a e n el m a n t e n i m i e n t o

146

PARTE D O S


Diagrama de contexto del sistema del SCCT.

y la autocomprobación. Cada caja que se muestra en la figura representa una entidad externa-, es decir, u n productor o c o n s u m i d o r de información del sistema. Por ejemplo, el lector de código de barras produce información que e s introducida al sist e m a SCCT. El símbolo para el sistema completo (o, a niveles m á s bajos, subsistemas principales) es u n rectángulo con las esquinas redondeadas. Por lo tanto, el SCCT se representa en la región de p r o c e s a m i e n t o y control al centro del DCS. Las flechas etiq u e t a d a s que se m u e s t r a n en el DCS representan información (datos y control) que va de un a m b i e n t e externo hacia el sistema SCCT. La entidad externa lector de código de barras produce entrada de información etiquetada c o m o código de barras. En esencia, el DSC coloca cualquier sistema en el contexto del a m b i e n t e externo. El ingeniero de sistemas refina el diagrama de contexto de arquitectura al estudiar con m á s detalle el rectángulo s o m b r e a d o de la figura 6.4. Se identifican los subsistemas principales que permiten funcionar al sistema clasificador de cinta transportadora dentro del contexto definido por el DCS. Los subsistemas principales se definen en un diagrama de flujo del sistema (DFS) que se obtiene del DCS. El flujo de información a través de las regiones del DCS se utiliza para guiar TM al ingeniero de sist e m a s e n el desarrollo del DFS, u n e s q u e m a m á s detallado del SCCT. El diagrama de flujo del sistema muestra los s u b s i s t e m a s principales y el flujo d e las líneas d e infor-

PDF Editor

mación importantes (datos y control). Además, la plantilla del sistema divide el proceso del subsistema en cada u n a de las cinco regiones de p r o c e s o p r e v i a m e n t e estudiadas. En este punto, c a d a u n o de los s u b s i s t e m a s p u e d e contener u n o o m á s elem e n t o s del sistema (por ejemplo, hardware, software, personas) tal y c o m o los ha

asignado el ingeniero de sistemas.

CAPÍTULO 6


147

D i a g r a m a d e flujo d e m á s alto nivel d e lo arquitectura

DFS d e A

DFS d e C

El d i a g r a m a d e flujo del s i s t e m a (DFS) inicial s e c o n v i e r t e e n el n o d o s u p e r i o r d e u n a j e r a r q u í a d e DFS. C a d a r e c t á n g u l o r e d o n d e a d o del DFS original p u e d e e x p a n dirse e n o t r a plantilla de a r q u i t e c t u r a d e d i c a d a a ella e n f o r m a e x c l u s i v a . E s t e p r o c e s o s e ilustra d e m a n e r a e s q u e m á t i c a en la figura 6.5. C a d a u n o d e los DFS del sist e m a p u e d e utilizarse c o m o p u n t o de p a r t i d a d e s u b s i g u i e n t e s f a s e s d e ingeniería p a r a el s u b s i s t e m a q u e se d e s c r i b e . En los s u b s i g u i e n t e s t r a b a j o s d e i n g e n i e r í a s e p u e d e n e s p e c i f i c a r (delimitar) l o s s u b s i s t e m a s y la i n f o r m a c i ó n q u e fluyen e n t r e ellos. Un r e l a t o d e s c r i p t i v o d e c a d a s u b s i s t e m a y u n a defi ni ci ón de t o d o s los d a t o s q u e fluyen e n t r e los s u b s i s t e m a s s o n e l e m e n t o s i m p o r t a n t e s d e la e s p e c i f i c a c i ó n del s i s t e m a .

6.5.2

M o d e l a d o d e l s i s t e m a c o n UML

El UML p r o p o r c i o n a u n a c a n t i d a d i m p r e s i o n a n t e de d i a g r a m a s q u e p u e d e n utilizars e p a r a el a n á l i s i s y d i s e ñ o al nivel d e s o f t w a r e y del s i s t e m a . 5 Para el SCCT s e m o d e lan c u a t r o e l e m e n t o s i m p o r t a n t e s del s i s t e m a : 1) el h a r d w a r e q u e pTM e r m i t e el SCCT; 2) el s o f t w a r e q u e i m p l e m e n t a el a c c e s o a la b a s e de d a t o s y la clasificación; 3) el o p e r a d o r q u e a c a t a v a r i a s p e t i c i o n e s del s i s t e m a ; y 4) la b a s e de d a t o s q u e c o n t i e n e

PDF Editor i n f o r m a c i ó n r e l e v a n t e del c ó d i g o d e b a r r a s y el d e s t i n o .

5

En los capítulos del 8 al 11 se presenta una exposición más detallada de los diagramas de UML. Para una exposición completa del UML el lector interesado debe consultar [SCH02], [LAR01] o [BEN99],

148

PARTE D O S


Diagrama de despliegue del hardware d e SCCT.

El h a r d w a r e del SCCT s e p u e d e m o d e l a r e n el nivel del s i s t e m a m e d i a n t e u n diagrama de despliegue

d e UML, c o m o s e ilustra e n la figura 6.6. C a d a c a j a t r i d i m e n s i o -

nal m u e s t r a u n e l e m e n t o del h a r d w a r e q u e e s p a r t e d e la a r q u i t e c t u r a física del sist e m a . En a l g u n o s c a s o s , los e l e m e n t o s del h a r d w a r e t e n d r á n q u e d i s e ñ a r s e y c o n s truirse c o m o p a r t e del p r o y e c t o . Sin e m b a r g o , e n m u c h o s c a s o s los e l e m e n t o s del h a r d w a r e s e p u e d e n adquirir y a c o n s t r u i d o s . El r e t o p a r a el e q u i p o d e i n g e n i e r í a es r e a l i z a r la i n t e r f a z d e los e l e m e n t o s del h a r d w a r e d e m a n e r a a p r o p i a d a . Los e l e m e n t o s del s o f t w a r e p a r a el SCCT s e p u e d e n m o d e l a r e n u n a v a r i e d a d de En wwwjotioiwi. toro/timl/ndex. jsp se puede

f o r m a s m e d i a n t e el u s o d e UML. Los a s p e c t o s d e p r o c e d i m i e n t o del s o f t w a r e del

espeííkocw completa de lo smtWra y semántico del UML

s u c e d e m i e n t r a s el s i s t e m a r e a l i z a s u s f u n c i o n e s . Los r e c t á n g u l o s r e d o n d e a d o s

posteriofes).

q u e s a l e del r o m b o e s t á e t i q u e t a d a ) ; las l í n e a s s ó l i d a s h o r i z o n t a l e s implican la r e a -

SCCT s e p u e d e n r e p r e s e n t a r m e d i a n t e u n diagrama

de actividad

(figura 6.7). Esta

n o t a c i ó n del UML e s similar al d i a g r a m a d e flujo y s e utiliza p a r a r e p r e s e n t a r lo q u e implican u n a f u n c i ó n e s p e c í f i c a del s i s t e m a ; l a s flechas r e p r e s e n t a n el flujo a t r a v é s del s i s t e m a ; el r o m b o d e d e c i s i ó n r e p r e s e n t a u n a d e c i s i ó n r a m i f i c a d a (cada flecha lización de a c t i v i d a d e s e n p a r a l e l o . Otra n o t a c i ó n de UML q u e s e p u e d e u s a r p a r a m o d e l a r s o f t w a r e eTM s el diagrama

de

clase (junto c o n m u c h o s d i a g r a m a s r e l a c i o n a d o s c o n l a s c l a s e s q u e se e x a m i n a n e n a p a r t a d o s p o s t e r i o r e s d e e s t e libro). En el nivel d e la ingeniería del s i s t e m a l a s cla-

PDF Editor

s e s 6 s e e x t r a e n e n u n e n u n c i a d o del p r o b l e m a . P a r a el SCCT l a s c l a s e s c a n d i d a t a s

6

En capítulos anteriores se destacó que una clase representa un conjunto de entidades que forman parte del dominio del sistema. El sistema puede almacenar o transformar estas entidades o pueden servir como un productor o consumidor de la información que el sistema produce.

CAPITULO 6


149

C ó d i g o d e barras inválido

c

)(

O b t e n e r estatus 5 operación

Leer el c ó d i g o ^ ( O b t e n e r el estatus de barras J y del conductor

D

í Producir la \ e n r r a d a del ^Conductor detenido

Conductor «n movimiento

5

p o d r í a n s e r de: c a j a , l í n e a d e c o n d u c c i ó n , l e c t o r d e c ó d i g o d e b a r r a s , c o n t r o l a d o r d e m a n i o b r a s , s o l i c i t u d d e l o p e r a d o r , r e p o r t e , p r o d u c t o y otras. Cada c l a s e e n c a p s u l a u n c o n j u n t o d e a t r i b u t o s q u e r e p r e s e n t a t o d a la i n f o r m a c i ó n n e c e s a ria a c e r c a d e la c l a s e . Una d e s c r i p c i ó n d e c l a s e t a m b i é n c o n t i e n e u n c o n j u n t o d e o p e r a c i o n e s q u e s e a p l i c a n a la c l a s e e n el c o n t e x t o del s i s t e m a SCCT. En la figura 6.8 s e m u e s t r a u n d i a g r a m a d e c l a s e d e UML la c l a s e c a j a .

TM

El o p e r a d o r del SCCT se p u e d e m o d e l a r c o n u n d i a g r a m a de UML de t i p o c a s o s

PDF Editor

d e u s o c o m o s e m u e s t r a en la figura 6.9. El d i a g r a m a de c a s o d e u s o ilustra la f o r m a e n la q u e un a c t o r (en e s t e c a s o el o p e r a d o r q u e s e r e p r e s e n t a c o n u n a figura a d h e rida) i n t e r a c t ú a c o n el s i s t e m a . C a d a ó v a l o e t i q u e t a d o d e n t r o de la c a j a (la cual r e p r e s e n t a la f r o n t e r a del s i s t e m a SCCT) implica un c a s o de u s o — u n e s c e n a r i o e s c r i t o q u e d e s c r i b e u n a i n t e r a c c i ó n c o n el s i s t e m a .

150

Diagrama de clase d e UML para la c l a s e caja.

PAPTE DOS

PRACTICA DE LA INGENIERÍA DEL SOFTWARE

N o m b r e d e la clase

Coja' código de barras velocidad hacia delante ubicación del conductor altura profundidad peso contenido atributos

Atributos

lectura del c ó d i g o de barras!) actualización d e velocidad)) lectura d e velocidad!) actualización d e la ubicación!) lectura d e ubicación!) obtención d e dimensiones!) pobtención del p e s o ( ) verificación d e contenido!)

Operaciones (los paréntesis al final del nombre indican la lista d e atributos q u e requiere la operación)

TM

PDF Editor

CAPÍTULO 6

151



Herramientas

de modelado

de sistemas

O b j e t i v o : Las herramientas d e modelado d e ^

sistemas proporcionan al ingeniero d e software c o p a c i d a d d e modelar todos los elementos d e un

Rational XDE and Rose, desarrollado por Rational Technologies (www.rational.com), proporciona una adaptación b a s a d a en UML d e herramientas d e

j sS>ema b a s a d o en computadoras al usar una notación

desarrollo y modelado p a r a sistemas b a s a d o s en

| específica p a r a la herramienta.

computadoras, la cual se utiliza d e manera amplia.

c ó n i c a : Las mecánicas d e las herramientas varían. ¡

lo general, las herramientas d e esta categoría ayudan

•a

rigeniero d e sistemas a modelar 1) la estructura d e

I «saos los elementos funcionales del sistema; 2) el | comportamiento estático y dinámico del sistema; 3) la • • u f u z máquina-humano.

Herramientas representativas 7 describe, desarrollado por Embarcadero Technologies I -«-«w embarcadero.com), es una adaptación d e I -erramientas d e modelado b a s a d a s en UML que puede

Real-Time Studio, desarrollado por Artisan Software (www.artisansw.com) es una conjunto d e herramientas d e modelado y desarrollo que dan soporte al desarrollo d e sistemas en tiempo real. Telelogic Tau, desarrollado por Telelogic (www.telelogic.com), es un conjunto con herramientas b a s a d a s en UML q u e da soporte al modelado d e diseño y análisis, y tiene vínculos con características d e construcción d e software.

i - p r e s e n t a r sistemas d e software o sistemas completos.

Un s i s l e m a de a l t a t e c n o l o g í a c o m p r e n d e v a r i o s c o m p o n e n t e s : h a r d w a r e , s o f t w a r e , p e r s o n a s , b a s e s d e d a t o s y p r o c e d i m i e n t o s . La i n g e n i e r í a d e s i s t e m a s a y u d a a t r a ducir l a s n e c e s i d a d e s del cl i ente e n u n m o d e l o d e s i s t e m a q u e e m p l e a u n o o m á s d e estos componentes. La i n g e n i e r í a d e s i s t e m a s c o m i e n z a al a d o p t a r u n a "visión global". Se a n a l i z a el d o m i n i o del n e g o c i o o p r o d u c t o p a r a e s t a b l e c e r t o d o s los r e q u i s i t o s b á s i c o s . El e n f o q u e s e r e d u c e e n t o n c e s a u n a "visión d e d o m i n i o " , d o n d e c a d a u n o d e . l o s e l e m e n t o s del s i s t e m a s e a n a l i z a e n f o r m a individual. C a d a e l e m e n t o s e a s i g n a a u n o o m á s c o m p o n e n t e s d e i n g e n i e r í a , los c u a l e s s e e s t u d i a n a p l i c a n d o la disciplina d e i n g e niería c o r r e s p o n d i e n t e . La ingeniería del p r o c e s o d e n e g o c i o s e s u n e n f o q u e de la ingeniería de s i s t e m a s m e d i a n t e el c u a l s e d e f i n e n a r q u i t e c t u r a s q u e p e r m i t a n a u n n e g o c i o utilizar la inform a c i ó n de m a n e r a e f i c a z . El o b j e t i v o d e la i n g e n i e r í a del p r o c e s o d e n e g o c i o s e s c r e a r u n a a r q u i t e c t u r a d e d a t o s , u n a a r q u i t e c t u r a de a p l i c a c i ó n y u n a i n f r a e s t r u c t u ra d e t e c n o l o g í a c o m p r e n s i b l e s q u e s a t i s f a g a n l a s n e c e s i d a d e s d e la e s t r a t e g i a d e n e g o c i o y los o b j e t i v o s y m e t a s d e c a d a á r e a del n e g o c i o .

TM

La ingeniería d e p r o d u c t o s e s u n e n f o q u e de la ingeniería de s i s t e m a s q u e

PDF Editor

c o m i e n z a c o n el a n á l i s i s del s i s t e m a . El i n g e n i e r o de s i s t e m a s identifica las n e c e s i -

7

Las herramientas mostradas aquí son una muestra dentro de esta categoría. En la mayoría de los casos los nombres están registrados por sus respectivos desarrolladores.

152

PARTE D O S


d a d e s del cliente, d e t e r m i n a la factibilidad e c o n ó m i c a y t é c n i c a , y a s i g n a f u n c i o n e s y r e n d i m i e n t o s al s o f t w a r e , el h a r d w a r e , l a s p e r s o n a s y l a s b a s e s de d a t o s ; e s decir a los c o m p o n e n t e s clave d e la i n g e n i e r í a .

[BEN991 Bennett, S., S. McRobb y R. Farmer, Object-Oriented Systems Analysis and Design Usátg UML, McGraw-Hill, 1999. [HAR93] Hares, J. S., Information Engineeringfor Advanced Practitioner, Wiley, 1993, pp. 12-13. [HAT87] Hatley, D.). e I. A. Pirbhai, Strategies for Real-Time System Specification, Dorset House 1987. [LAR01] Larman, C., Applying UML and Pattems: An Introduction to Object-Oriented Analysis and Design and [he Unifed Process, 2a. ed„ Prentice-Hall, mayo de 2001. [MAR901 Martin, J. Information Engineering: Book II—Planning and Analysis, Prentice-Hall, 1990. [MOT92] Motamarri, S., "Systems Modeling and Description", en Software Engineering Notes, ve 17, núm. 2, abril de 1992, pp. 57-63. |SCH02)Schmuller,)., Teach YourselfUML in 24 Hours, 2a. ed., Sams Publishing, 2002. [SPE93] Spewak, S., Enterprise Architecture Planning, QED Publishing, 1993. [THA97] Thayer, R. H. y M. Dorfman, Software Requirements Engineering, 2a. ed., IEEE Computer Society Press, 1997.

6.1. Encontrar tantos sinónimos como se pueda de la palabra "sistema". ¡Buena suerte! 6 . 2 . Construir un "sistema de sistemas" jerárquico para un sistema, producto o servicio con el cual se esté familiarizado. La jerarquía se debe extender hasta los elementos simples del sistema (hardware, software, etcétera) de al menos una rama de cada estructura. 6 . 3 . Seleccionar un sistema o producto grande con el que esté familiarizado. Definir el conjunto de dominios que definan la visión global del sistema o producto. Describir el conjunto de elementos que componen uno o dos de los dominios. Para un elemento, identificar los componentes técnicos que deben desarrollarse. 6.4. Seleccionar algún sistema o producto grande con el cual esté familiarizado. Establecer las suposiciones, simplificaciones, limitaciones, restricciones y preferencias que se deberían hacer para construir un modelo de sistema de modelo eficaz (y realizable). 6.5. La ingenieria de procesos del negocio requiere definir datos, arquitectura de aplicaciones, además de una infraestructura de aplicaciones. Describir cada uno de estos términos mediante un ejemplo. 6.6. Un ingeniero de sistemas puede tener una de tres procedencias: el desarrollo de sistemas, el cliente o una organización externa. Discutir los pros y los contras de cada procedencia Describir un ingeniero de sistemas "ideal".

TM

6.7. El profesor entregará una descripción de alto nivel de un sistema o producto basado en computadoras. a) Desarrollar un conjunto de preguntas que se debería realizar como ingeniero de sistemas. b) Proponer al menos dos ubicaciones diferentes para el sistema con base en las respuestas a sus preguntas. c) En clase, comparar sus ubicaciones con las de sus compañeros.

PDF Editor

6 . 8 . Desarrollar un diagrama de contexto del sistema para el sistema basado en computadoras que se haya elegido (o uno asignado por su profesor).

CAPÍTULO 6


153

6 . 9 Aunque la información hasta este punto está muy entrecortada, trátese de desarrollar un diagrama de desarrollo, un diagrama de actividad, un diagrama de clase y un diagrama de caso de uso con UML para el producto HogarSeguro. 6 . 1 0 . Realizar una investigación bibliográfica y escribir un documento breve que describa cómo funcionan las herramientas de modelado y simulación. Alternativa: recopile bibliografía de dos o más vendedores de herramientas de modelado y simulación y evalúe sus similitudes y diferencias. 6 . 1 1 . ¿Existen características de un sistema que no se puedan establecer durante las actividades de la ingeniería de sistemas? Describir las características, si existen, y explicar por qué su consideración se debe retrasar a fases posteriores del desarrollo. 6 . 1 2 . ¿Existen situaciones en las que la especificación formal del sistema se pueda abreviar o eliminar por completo? Expliqúese la respuesta.

O T R A S L E C T U R A S Y F U E N T E S DE I N F O R M A C I Ó N Los libros de Hatley y sus colegas (Processfor Systems Architecture and Requirements Engineering, Dorset House, 2001), Buede {The Engineering Design of Systems: Models and Methods, Wiley, 1999), Weiss y sus colegas (Software Product-Une Engineering, Addison-Wesley, 1999), Blanchard y Fabrycky (System Engineering and Analysis, 3a. ed., Prentice-Hall, 1998), Armstrong y Sage (Introduction lo Systems Engineering, Wiley, 1997), y Martin (Systems Engineering Guidebook, CRC Press, 1996) presentan el proceso de la ingeniería del sistema (con un énfasis distinto en la ingeniería) y proporcionan una guía muy valiosa. Blanchard (System Engineering Management, segunda edición, Wiley, 1997) y Lacy (System Engineering Management, McGrawHill, 1992) exponen aspectos de gestión de la ingeniería del sistema. Chorafas (Enterprise Architecture and New Generation Systems, St. Lucie Press, 2001) presenta ingeniería de información y arquitecturas de sistema para la "siguiente generación" de soluciones de TI; se incluyen sistemas basados en Internet. Wallnau y sus colegas (Building Systems from Comercial Componennts, Addison-Wesley, 2001) se enfoca en los aspectos de la ingeniería de sistemas basada en componentes para productos y sistemas de información. Lozinsky (Enterprise-Wide Software Solutions: Integration Strategies and Practices, Addison-Wesley, 1998) abarca el uso de paquetes de software como una solución que permite a las compañías pasar de los sistemas heredados a los procesos de negocio modernos. Una exposición muy valiosa del riesgo y la ingeniería del sistema se presenta en el libro de Bradley (Elimination of Risk in Systems, Tharsis Boooks, 2002). Davis (Business Process Modeling with Aris: A PracticaI Ouiúe, Springer-Verlas, 2001). Bustard y sus colegas (System Models for Business Process Improvement, Artech House, 2000), y Scheer (Business Process Engineering: Reference Models for Industrial Enterprises, Springer-Vcrlag, 1998) describen los métodos de modelado del proceso de negocios para sistemas de información y de toda una empresa. Davis y Yen (The Information System Consuitant's Handbook: Systems Analysis and Design, CRC Press, 1998) presentan una cobertura enciclopédica de los aspectos del análisis y diseño de sistemas en el dominio de los sistemas de información. Una ayuda excelente del IEEE por Thayer y Dorfman [THA97J discute la interrelación entre los análisis al nivel de sistema y al nivel de software. Law y sus colegas (Simulation Modeling and Analysis, McGraw-Hill, 1999) TM analizan técnicas de modelado y simulación de sistemas para una amplia variedad de dominios de aplicación. Para los lectores involucrados de manera activa en el trabajo de sistemas o que están interesados en un tratamiento más elaborado del tópico, los libros de Gerald Weinberg (An Introduction to General System Thinking, Wiley, Interscience, 1976, y On the Design of Stable Systems, Wiley-Interscience, 1979) se han convertido en clásicos y ofrecen una excelente exposición sobre el "pensamiento general de sistemas", lo que de manera implícita conduce a un enfoque general del análisis y diseño de sistemas. Otros libros más recientes de Weinberg (General Principies of Systems Design, Dorset House, 1998 y Rethinking Systems Analysis and Design, Dorset House, 1998) continúan la tradición de este primer trabajo.

PDF Editor

PARTE D O S


En Internet existe una amplia variedad d e f u e n t e s d e información sobre la ingeniería de t e m a s y materias relacionadas. En el sitio Web de SEPA, h t t p : / / w w w . m h h e . c o m / p r e s s m a r . se p u e d e encontrar u n a lista actualizada de referencias en la red mundial q u e son relevante para la ingeniería del sistema, la ingeniería de la información, la ingeniería de proceso del negó-] ció y la ingeniería del producto.

TM

PDF Editor

C A P I T U L O

7

INGENIERÍA DE R E Q U I S I T O S CEPTOS VE >...173 ....159

L

a c o m p r e n s i ó n d e los r e q u i s i t o s de u n p r o b l e m a e s t á e n t r e l a s t a r e a s m á s difíciles q u e e n f r e n t a u n i n g e n i e r o d e s o f t w a r e . C u a n d o se p i e n s a por prim e r a v e z a c e r c a de ello, la i n g e n i e r í a d e r e q u i s i t o s n o p a r e c e ta n difícil.

D e s p u é s d e t o d o , ¿el cl i ente n o s a b e lo q u e s e r e q u i e r e ? ¿Los u s u a r i o s finales n o d e b e r í a n e n t e n d e r b i e n las c a r a c t e r í s t i c a s y f u n c i o n e s q u e les p r o p o r c i o n a r á n u n b e n e f i c i o ? Es s o r p r e n d e n t e , p e r o e n m u c h a s o c a s i o n e s la r e s p u e s t a a e s t a s p r e -

.179 .160 .161

.158

g u n t a s es: "no". Y a u n si los c l i e n t e s y u s u a r i o s finales s o n explícitos e n s u s n e c e s i d a d e s , e s t o s r e q u i s i t o s p u e d e n c a m b i a r d u r a n t e el proyecto. La ingeniería d e r e q u i s i t o s e s difícil. En el p r ó l o g o a u n libro d e Ralph Y o u n g [YOUO1 ¡ s o b r e l a s p r á c t i c a s e f e c t i v a s e n l o s requisitos, el a u t o r d e e s t e libro escribió: Es tu peor pesadilla. Un cliente entra en tu oficina, se sienta, te mira directo a los ojos,

.169

y dice: "Yo sé que usted piensa que entiende lo que digo, pero lo que usted no en

.160

tiende es que lo que digo n o es realmente lo que quiero decir". Esto sucede de ma-

.158

nera invariable cuando el proyecto está avanzado, después de que se han realizado los compromisos relativos al tiempo de entrega, las reputaciones están en juego y el

.183

dinero está en serio peligro.

.171

Todos los que hemos trabajado en el negocio de los sistemas y el software por más

.162

de unos cuantos años hemos vivido esta pesadilla, y sólo unos pocos de nosotros he-

.161

mos aprendido a continuar aun con esta circunstancia. Nosotros tenemos dificultades cuando traíamos de obtener requisitos de nuestros clientes. Tenemos problemas al comprender la información que adquirimos. Con frecuencia, registramos los rc-

¿Qué es?

La i n g e n i e r í a d e requisi-

¿Por qué es importante?

El d i s e ñ o y la c o n s -

tos a y u d a a ios i n g e n i e r o s d e s o f t w a -

trucción d e u n e l e g a n t e p r o g r a m a d e c o m p u t a -

re a e n t e n d e r m e j o r el p r o b l e m a e n

d o r a q u e r e s u e l v a el p r o b l e m a i n c o r r e c t o n o

c u y a solución t r a b a j a r á n . Incluye el

s a t i s f a c e l a s n e c e s i d a d e s d e n a d i e . Por lo tanto,

conjunto d e tareas que conducen o

e s m u y i m p o r t a n t e e n t e n d e r lo q u e el cliente

c u á l s e r á el i m p a c t o del s o f t w a r e el n e g o c i o , q u é e s lo q u e el cliente q u i e r e

q u i e r e antes d e c o m e n z a r a diseñar y construir

i n t e r a c t u a r á n los u s u a r i o s f i n a l e s c o n el • e.

un s i s t e m a b a s a d o en c o m p u t a d o r a .

¿Cuáles s o n los p a s o s ?

TM

La i n g e n i e r í a d e requi-

sitos e m p i e z a con la f a s e d e inicio, la c u a l e s

lo h a c e ?

Los i n g e n i e r o s d e s o f t w a r e

u n a t a r e a q u e d e f i n e el á m b i t o y la n a t u r a l e z a

veces r e f e r i d o s c o m o ingenieros de siso analistas e n el m u n d o d e la TI) y o t r o s

t i n ú a c o n la o b t e n c i ó n , q u e e s u n a t a r e a q u e

( g e r e n t e s , clientes y u s u a r i o s finales)

a y u d a a l cliente a d e f i n i r sus n e c e s i d a d e s ; p o s -

PDF Editor en la i n g e n i e r í a d e requisitos.

dei p r o b l e m a q u e d e b e r e s o l v e r s e . D e s p u é s c o n -

t e r i o r m e n t e s i g u e c o n l a e l a b o r a c i ó n , q u e e s la

155

156

PARTE DOS

PRÁCTICA DE LA INGENIERÍA D A SOFTWARE

f a s e d o n d e se r e f i n a n y m o d i f i c a n los r e q u i s i t o s b á s i c o s . C u a n d o el cliente h a d e f i n i d o el p r o b l e -

v a r i o s p r o d u c t o s d e t r a b a j o : e s c e n a r i o s d e uso,

m a se lleva a c a b o ia n e g o c i a c i ó n , d o n d e s e

análisis o a l g u n a especificación.

d e f i n e c u á l e s s o n las p r i o r i d a d e s , c u á l e s a s p e c tos son e s e n c i a l e s y e n q u é m o m e n t o s e r e q u i e ren. Por último, el p r o b l e m a s e e s p e c i f i c a d e a l g u n a m a n e r a , y d e s p u é s es v a l i d a d o y revisa-

listas d e f u n c i o n e s y c a r a c t e r í s t i c a s , m o d e l o s d e

¿Cómo p u e d o e s t a r s e g u r o d e q u e lo he h e c h o c o r r e c t a m e n t e ? El i n g e n i e r o d e soft-

d o p a r a a s e g u r a r q u e la c o n c e p c i ó n d e l p r o b l e m a q u e t i e n e el i n g e n i e r o d e s o f t w a r e c o i n c i d e c o n la p e r c e p c i ó n d e l cliente.

¿Cuál es el p r o d u c t o o b t e n i d o ?

w a r e r e v i s a los p r o d u c t o s d e t r a b a j o d e la i n g e n i e r í a d e r e q u i s i t o s ¡unto c o n el cliente y los usuarios finales p a r a a s e g u r a r s e q u e h a y a e n t e n d i d o lo q u e en r e a l i d a d p r e t e n d í a n d e c i r l e . Es n e c e s a r i o h a c e r u n a a d v e r t e n c i a : a u n d e s -

El o b j e t i v o

p u é s d e q u e t o d a s las p a r t e s e s t á n d e a c u e r d o ,

del p r o c e s o d e la i n g e n i e r í a d e r e q u i s i t o s e s

las c o s a s c a m b i a n , y c o n t i n u a r á n h a c i é n d o l o a

darle a t o d a s las p a r t e s u n a explicación escrita

t r a v é s d e la v i d a del p r o y e c t o .

del p r o b l e m a . Esto p u e d e l o g r a r s e p o r m e d i o d e

quisitos de una manera desorganizada e invertimos muy poco tiempo en verificar lo que registramos. Permitimos que el cambio nos controle en lugar de establecer mecanismos para controlarlo. En resumen, fallamos al establecer un cimiento sólido para el sistema o software. Cada uno de estos problemas representa un reto. Cuando éstos se combinan, la imagen es desalentadora incluso para los gerentes y profesionales del sofware más experimentados. Pero existen soluciones. Sería d e s h o n e s t o d e c i r q u e la i n g e n i e r í a d e r e q u i s i t o s e s la "solución" p a r a l o s r e t o s q u e s e h a n e n u n c i a d o . P e r o p r o p o r c i o n a u n e n f o q u e sólido p a r a a b o r d a r d i c h o s desafios. 7.1

UN

P V E N T E H A C I A EL D I S E Ñ O Y L A C O H S T R V C C I Ó N

Las a c t i v i d a d e s d e d i s e ñ o y c o n s t r u c c i ó n d e s o f t w a r e de c o m p u t a d o r a s o n d e s a f i a n tes, c r e a t i v a s y h a s t a divertidas. D e h e c h o , la c o n s t r u c c i ó n e s tan irresistible q u e m u c h o s d e s a r r o l l a d o r e s de s o f t w a r e q u i e r e n e n t r a r e n ella a n t e s d e c o m p r e n d e r con claridad d e q u é e s lo q u e s e n e c e s i t a . Ellos a r g u m e n t a n q u e l a s c o s a s s e a c l a r a r á n m i e n t r a s c o n s t r u y e n ; q u e l o s i n t e r e s a d o s e n el s o f t w a r e s e r á n c a p a c e s d e e n t e n d e r m e j o r las n e c e s i d a d e s s ó l o d e s p u é s de e x a m i n a r las p r i m e r a s i t e r a c i o n e s del softw a r e ; q u e l a s c o s a s c a m b i a n t a n r á p i d o q u e la i n g e n i e r í a d e r e q u i s i t o s e s u n a pérdid a d e t i e m p o ; q u e la línea de b a s e p r o d u c e u n p r o g r a m a q u e f u n c i o n a y t o d o lo

TM

d e m á s e s s e c u n d a r i o . Lo q u e h a c e s e d u c t o r e s a e s t o s a r g u m e n t o s e s q u e c o n t i e n e n e l e m e n t o s d e v e r d a d . ' P e r o c a d a u n o d e ellos e s i m p e r f e c t o y p u e d e c o n d u c i r a un

PDF Editor p r o y e c t o d e s o f t w a r e fallido.

1

En particular, esto es cierto para los proyectos chicos (menos de un mes) que implican un esfuerzo relativamente pequeño. Conforme el software crece en tamaño y complejidad, estos argumentos comienzan a derrumbarse.

CAPÍTULO 7

157


"La parte más difícil de construir un sistema de software es decidir qué construir. Ninguna parte del trabajo estropea tanto el sistema resultante si se hace mal. Ninguna parte es más difícil de rectificar después." Fred Brooks La i n g e n i e r í a d e requisitos, c o m o t o d a s l a s d e m á s a c t i v i d a d e s de la i n g e n i e r í a del s o f t w a r e , d e b e a d a p t a r s e a l a s n e c e s i d a d e s del p r o c e s o , el p r o y e c t o , el p r o d u c t o y las p e r s o n a s q u e r e a l i z a n el t r a b a j o . D e s d e la p e r s p e c t i v a del p r o c e s o del s o f t w a r e , la i n g e n i e r í a d e r e q u i s i t o s (IR) e s u n a a c c i ó n d e la i n g e n i e r í a del s o f t w a r e q u e c o m i e n z a d u r a n t e la actividad de c o m u n i c a c i ó n y c o n t i n ú a en la actividad de m o d e l a d o . En a l g u n o s c a s o s s e elige u n e n f o q u e a b r e v i a d o . En o t r o s , c a d a u n a d e las t a r e a s d e f i n i d a s p a r a c o m p r e n d e r los r e q u i s i t o s s e d e b e llevar a c a b o de m a n e r a rigurosa. S o b r e todo, el e q u i p o de s o f t w a r e d e b e a d a p t a r s u e n f o q u e a la IR, lo q u e n o signific a a b a n d o n o . Es e s e n c i a l q u e el e q u i p o de s o f t w a r e h a g a u n e s f u e r z o real p o r e n t e n der los r e q u i s i t o s d e u n p r o b l e m a antes d e i n t e n t a r resolverlo. La i n g e n i e r í a d e r e q u i s i t o s t i e n d e u n p u e n t e h a c i a el d i s e ñ o y la c o n s t r u c c i ó n . P e r o ¿ d ó n d e s e origina el p u e n t e ? Se p u e d e a r g u m e n t a r q u e c o m i e n z a al p i e d e los

LVE

p a r t i c i p a n t e s del p r o y e c t o (es decir, g e r e n t e s , clientes, u s u a r i o s finales), d o n d e s e d e f i n e n las n e c e s i d a d e s del negocio, s e d e s c r i b e n los e s c e n a r i o s de los usuarios, se delin e a n las c a r a c t e r í s t i c a s y f u n c i o n e s , y s e identifican las r e s t r i c c i o n e s del p r o y e c t o .

ida para el Sil ella, «esuhOTite ' d e no del

O t r o s q u i z á s u g i e r a n q u e c o m i e n z a c o n la definición m á s a m p l i a del s i s t e m a , e n el q u e el s o f t w a r e e s s ó l o u n c o m p o n e n t e (capítulo 6) del d o m i n i o del s i s t e m a q u e e s a ú n m a y o r . Pero sin i m p o r t a r el p u n t o d e inicio, el t r a b a j o a lo l a r g o del p u e n t e se inicia e n la p a r t e alta del p r o y e c t o , lo q u e p e r m i t e q u e el e q u i p o de s o f t w a r e e x a m l n e el c o n t e x t o del t r a b a j o d e s o f t w a r e q u e s e r á realizado,- l a s n e c e s i d a d e s especific a s q u e el d i s e ñ o y la c o n s t r u c c i ó n d e b e n a b o r d a r ; l a s p r i o r i d a d e s q u e indican el o r d e n e n el q u e se d e b e c o m p l e t a r el t r a b a j o ; y la i n f o r m a c i ó n , l a s f u n c i o n e s y los c o m p o r t a m i e n t o s q u e t e n d r á n u n i m p a c t o p r o f u n d o e n el d i s e ñ o r e s u l t a n t e .

— La i n g e n i e r í a d e r e q u i s i t o s p r o p o r c i o n a el m e c a n i s m o a p r o p i a d o p a r a e n t e n d e r lo q u e el cl i ente quiere, a n a l i z a r l a s n e c e s i d a d e s , e v a l u a r la factibilidad, n e g o c i a r u n a s o l u c i ó n r a z o n a b l e , e s p e c i f i c a r la s o l u c i ó n sin a m b i g ü e d a d e s , validar la e s p e c i f i c a c i ó n , y a d m i n i s t r a r los r e q u i s i t o s c o n f o r m e é s t o s s e t r a n s f o r m a n e n u n s i s t e m a o p e r a c i o n a l [THA97]. El p r o c e s o d e la i n g e n i e r í a d e r e q u i s i t o s s e lleva a c a b o a t r a v é s d e s i e t e d i s t i n t a s f u n c i o n e s : inicio, obtención,

elaboración,

negociación, TMespecificación,

validación y gestión. Resulta i m p o r t a n t e d e s t a c a r q u e a l g u n a s d e e s t a s f u n c i o n e s de la ingeniería de

PDF Editor

r e q u i s i t o s o c u r r e n e n p a r a l e l o y q u e t o d a s d e b e n a d a p t a r s e a las n e c e s i d a d e s del

p r o y e c t o . T o d a s e s t á n dirigidas a definir lo q u e el cliente quiere, y t o d a s s i r v e n p a r a e s t a b l e c e r u n a b a s e sólida r e s p e c t o del d i s e ñ o y la c o n s t r u c c i ó n d e lo q u e o b t e n d r á el cliente.

158

PARTE D O S

7.2.1


Inicio

¿ C ó m o se inicia u n p r o y e c t o d e s o f t w a r e ? ¿Es u n e v e n t o a i s l a d o q u e s e c o n v i e r t e en el c a t a l i z a d o r p a r a u n n u e v o s i s t e m a o p r o d u c t o b a s a d o e n c o m p u t a d o r a ? ¿O la n e c e s i d a d e v o l u c i o n a c o n el t i e m p o ? No e x i s t e n r e s p u e s t a s definitiva s p a r a e s t a s preguntas. "Por lo general,tassemillas de los desastres más importantes en software se siembran en los primeros tres meses desde el comienzo del proyecto.' Capers Jones En a l g u n o s c a s o s , u n a c o n v e r s a c i ó n i n f o r m a l e s t o d o lo q u e s e n e c e s i t a p a r a precipitar u n e s f u e r z o i m p o r t a n t e de ingeniería del s o f t w a r e . Pero e n g e n e r a l , la m a y o r í a d e los p r o y e c t o s c o m i e n z a c u a n d o s e identifica u n a n e c e s i d a d d e n e g o c i o s o s e desc u b r e un n u e v o m e r c a d o o servicio potencial. Los p a r t i c i p a n t e s d e la c o m u n i d a d de n e g o c i o s (es decir, los g e r e n t e s , g e n t e de m e r c a d o t e c n i a , g e r e n t e s d e producto) defin e n u n c a s o d e n e g o c i o s p a r a la idea, t r a t a n d e identificar la a m p l i t u d y p r o f u n d i d a d del m e r c a d o , h a c e n u n análisis preliminar de factibilidad, e identifican u n a descripción f u n c i o n a l del á m b i t o del proyecto. Toda e s t a i n f o r m a c i ó n e s t á s u j e t a a c a m b i o s (una situación probable), p e r o e s suficiente p a r a s u s c i t a r c o n v e r s a c i o n e s c o n la o r g a n i z a ción d e ingeniería del s o f t w a r e . 2 Al inicio3 del p r o y e c t o los i n g e n i e r o s d e s o f t w a r e h a c e n u n a serie d e p r e g u n t a s libres d e c o n t e x t o , las c u a l e s s e e x p o n e n e n la s e c c i ó n 7.3.4. El o b j e t i v o e s e s t a b l e cer u n a c o m p r e n s i ó n b á s i c a del p r o b l e m a , las p e r s o n a s q u e q u i e r e n u n a s o l u c i ó n , la n a t u r a l e z a d e la s o l u c i ó n q u e s e d e s e a , y la e f e c t i v i d a d d e la c o m u n i c a c i ó n prelimin a r e n t r e el cl i ente y el d e s a r r o l l a d o r .

7.2.2

Obtención

En v e r d a d p a r e c e m u y s i m p l e p r e g u n t a r l e al cliente, a l o s u s u a r i o s y o t r o s i n t e r e s a d o s c u á l e s s o n los o b j e t i v o s p a r a el s i s t e m a o p r o d u c t o , q u é e s lo q u e s e d e b e lograr, de q u é f o r m a el p r o d u c t o s a t i s f a c e l a s n e c e s i d a d e s del n e g o c i o y p o r ú l t i m o c ó m o se utilizará el s i s t e m a o p r o d u c t o día a día. P e r o n o e s s i m p l e , e s m u y difícil. Christel y K a n g [CR192] identifican u n a serie de p r o b l e m a s q u e a y u d a n a e n t e n d e r ¿Por qué es difícil comprender con claridad |o que

p o r q u é e s difícil la obtención

d e requisitos:

• P r o b l e m a s d e á m b i t o . El límite del s i s t e m a e s t á m a l d e f i n i d o o los clientes/usuarios especifican detalles técnicos innecesarios que p u e d e n

TM

q w e r e el cliente?

c o n f u n d i r , e n l u g a r d e clarificar, los o b j e t i v o s g e n e r a l e s del s i s t e m a .

PDF Editor

2 Si se va a construir un sistema basado en computadora, las discusiones comienzan con la ingeniería del sistema, una actividad que define la visión global y la visión de dominio para el sistema (capitulo 6). 3

Los lectores del capitulo 3 recordarán que el proceso unificado define una "fase de inicio" más completa, la cual incluye las tareas de inicio, obtención y elaboración tal como se examinan en este capítulo.

CAPITULO 7


159

• P r o b l e m a s d e c o m p r e n s i ó n . Los c l i e n t e s / u s u a r i o s n o e s t á n s e g u r o s por c o m p l e t o de q u é es lo q u e s e necesita, c o m p r e n d e n p o c o a c e r c a d e las c a p a c i d a d e s y limitaciones d e su a m b i e n t e d e c ó m p u t o , n o c o m p r e n d e n del t o do el d o m i n i o del p r o b l e m a , tienen dificultades al c o m u n i c a r n e c e s i d a d e s al ingeniero d e sistemas, o m i t e n información que c o n s i d e r a n "obvia", especifican requisitos q u e c h o c a n c o n las n e c e s i d a d e s d e otros c l i e n t e s / u s u a r i o s , o especifican requisitos a m b i g u o s o inestables. • P r o b l e m a s d e v o l a t i l i d a d . Los p r o b l e m a s c a m b i a n c o n f o r m e t r a n sc u r re el tiempo. Para a y u d a r a s u p e r a r e s t o s p r o b l e m a s , los ingenieros de requisitos d e b e n realizar e n f o r m a o r g a n i z a d a la actividad de recopilación de requisitos.

7.2.3

Elaboración

La i n f o r m a c i ó n c o n s e g u i d a c o n el cliente d u r a n t e el inicio y la o b t e n c i ó n s e e x p a n d e y s e refina d u r a n t e la elaboración.

Esta actividad de la ingeniería de requisitos s e

e n f o c a en el desarrollo d e u n m o d e l o técnico refinado d e las funciones, característic a s y restricciones del s o f t w a r e . La elaboración e s u n a acción del m o d e l a d o del análisis (capítulo 8) y s e c o m p o es

n e d e u n a serie d e t a r e a s d e m o d e l a d o y refinamiento. La elaboración s e c o n d u c e

sedebe

m e d i a n t e la creación y el r e f i n a m i e n t o d e e s c e n a r i o s del u s u a r i o q u e describen la

íadavees

f o r m a en q u e el u s u a r i o final (y o t r o s actores) interactuarán c o n el sistema. Cada e s c e n a r i o del u s u a r i o s e analiza p a r a o b t e n e r clases d e análisis: e n t i d a d e s del d o m i nio d e negocios visibles p a r a el u s u a r i o final. Se definen los atributos d e c a d a clase

mcbose

diseño, wtt d e se

de análisis y se identifican los servicios4 q u e requiere cada clase. Se identifican las r e l a c i o n e s y la colaboración e n t r e las clases y s e p r o d u c e u n a variedad d e d i a g r a m a s d e UML c o m p l e m e n t a r i o s . El resultado final d e la elaboración e s un m o d e l o d e análisis q u e define el d o m i nio d e la información, las f u n c i o n e s y el c o m p o r t a m i e n t o del problema.

INFORMACIÓN

Modelado 1

del análisis

Supóngase por un momento que es necesario

especificar todos los requisitos p a r a la i d e una cocina gourmet. Se conocen las ¡ d e la sala, la ubicación d e las puertas y

aplicaciones (su fabricante, modelo, número y dimensiones). Después se podrían especificar las

TM

contrapartes (laminado, granito, etcétera), uniones d e plomería, pisos y los techos. Esta lista podría constituir una

y el espacio disponible en la p a r e d .

especificación útil, pero no proporciona un modelo de lo

especificar por completo lo que se va a construir

q u e se d e s e a . Para completar el modelo se podría crear

PDF Editor hacer una lista de todos los gabinetes y

una representación tridimensional que muestre la posición

4 También se utilizan los términos operaciones y métodos.

160

PARTE D O S


/T . d e los gabinetes y aplicaciones y los relaciones entre ellos.

una representación tridimensional p a r a el caso d e la

A partir del modelo, sería m á s fácil evaluar la eficiencia

cocina. Es importante evaluar c a d a componente del

del flujo de t r a b a j o (un requisito p a r a t o d a s las cocinas), y

sistema en relación con los otros. Esto permite determinar

la apariencia estética del salón (un requisito personal, p e r o

cómo e n c a j a n los requisitos en esta visión y evaluar la

muy importante.)

"estética" del sistema c o m o h a sido concebido.

Los modelos de análisis se construyen p o r una razón muy p a re c i da a la del desarrollo d e un plano d e t r a b a j o o

7.2.4

Negociación

Dados los recursos limitados del negocio, n o resulta inusual que los clientes y usuarios pidan m á s de lo que se p u e d e lograr. También es relativamente c o m ú n q u e diferentes clientes o usuarios propongan requisitos que entran en conflicto entre sí a ÔNSEJO^ En una negociación e k a i no debe babet ganador ni perdedor. Ambas parles ganan porque se solidifica un 'trato" con el que las dos pueden vivir.

a r g u m e n t a r que su versión e s "esencial p a r a nuestras n e c e s i d a d e s especiales". El ingeniero de requisitos debe conciliar estos conflictos por medio de u n proceso de negociación.

Se pide a los clientes, usuarios y otros interesados que ordenen

sus requisitos y d e s p u é s discutan los conflictos relacionados con la prioridad. Se identifican y analizan los riesgos asociados con cada requisito (para obtener más detalles v é a s e el capítulo 25). Se h a c e n "estimaciones" preliminares del e s f u e r z o requerido p a r a su desarrollo y d e s p u é s s e utilizan para evaluar el impacto de cada requisito en el costo del proyecto y sobre el tiempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan, c o m b i n a n o modifican de forma que c a d a parte alcance cierto grado de satisfacción.

7.2.5

Especificación

En el contexto de los s i s t e m a s b a s a d o s e n c o m p u t a d o r a (y e n software), el término especificación tiene significados diferentes p a r a p e r s o n a s distintas. Una especificación p u e d e ser un d o c u m e n t o escrito, u n conjunto de modelos gráficos, un modelo matemático formal, u n a colección de escenarios de uso, un prototipo o cualquier combinación de éstos.

CLAVE lo formalidad y el formato de una especificación varían con el tamaño y la complejidad del software que se va a construir.

Algunos sugieren que para u n a especificación se d e b e desarrollar y utilizar una "plantilla estándar" [SOM97] a r g u m e n t a n que esto c o n d u c e a que los requisitos sean p r e s e n t a d o s de u n a m a n e r a m á s consistente y por e n d e m á s entendible. Sin embargo, a l g u n a s v e c e s e s necesario ser flexible mientras se desarrolla u n a TM especificación. Respecto de sistemas g r a n d e s el mejor e n f o q u e podría ser un d o c u m e n t o escrito que combinara descripciones e n el lenguaje natural y modelos gráficos. Por otro lado, en

PDF Editor

c u a n t o a productos o sistemas m á s pequeños, podría ser que no se necesite m á s que escenarios de uso, c u a n d o dichos sistemas residan en a m b i e n t e s técnicos q u e se c o m p r e n d a n bien. La especificación es el producto de trabajo final que genera la ingeniería de requi-

sitos. Sirve c o m o base p a r a las actividades de ingeniería de s o f t w a r e subsecuentes.

CAPÍTULO 7


161

D e s c r i b e la f u n c i ó n y el d e s e m p e ñ o d e u n s i s t e m a b a s a d o e n c o m p u t a d o r a y las r e s t r i c c i o n e s q u e regirán s u d e s a r r o l l o . dave c wtdoáón tsb . Se motel xanátsis yquehs se tan esta-

7.2.6

Validación

La c a l i d a d d e los p r o d u c t o s d e t r a b a j o p r o c e d e n t e s d e la ingeniería de r e q u i s i t o s s e e v a l ú a d u r a n t e u n p a s o d e validación. ficación

La v a l i d a c i ó n d e r e q u i s i t o s e x a m i n a la e s p e c i -

p a r a a s e g u r a r q u e t o d o s los r e q u i s i t o s d e s o f t w a r e s e h a n e s t a b l e c i d o d e

m a n e r a precisa; que se han detectado las inconsistencias, omisiones y errores y que é s t o s h a n s i d o c o r r e g i d o s , y q u e los p r o d u c t o s d e t r a b a j o c u m p l e n c o n los e s t á n d a r e s e s t a b l e c i d o s p a r a el p r o c e s o , p r o y e c t o y p r o d u c t o . El m e c a n i s m o p r i m a r i o p a r a la validación d e r e q u i s i t o s e s la r e v i s i ó n t é c n i c a f o r m a l (capítulo 26). El e q u i p o d e revisión q u e valida los r e q u i s i t o s i n c l u y e i n g e n i e r o s d e s o f t w a r e , clientes, u s u a r i o s y o t r o s i n t e r e s a d o s q u e e x a m i n a n la e s p e c i f i c a c i ó n y b u s c a n e r r o r e s e n el c o n t e n i d o o la i n t e r p r e t a c i ó n , á r e a s q u e tal v e z r e q u i e r a n u n a clarificación, i n f o r m a c i ó n f a l t a n t e , i n c o n s i s t e n c i a s (que e s u n p r o b l e m a i m p o r t a n t e c u a n d o s e d e s a r r o l l a n p r o d u c t o s o s i s t e m a s g r a n d e s ) , c o n f l i c t o s e n t r e los requisitos, o r e q u i s i t o s irreales ( i n a l c a n z a b l e s ) .

INFORMACIÓN

Lista de verificación

para la validación

C o n f r e c u e n c i a resulta útil e x a m i n a r c a d a

¿El requisito se p u e d e p r o b a r ? Si e s así, ¿ s e p u e d e n

requisito frente a u n a serie d e p r e g u n t a s en

e s p e c i f i c a r las p r u e b a s ( a l g u n a s veces l l a m a d a s criterios

d e lista d e verificación. Enseguida se p r e s e n t a un s u b c o n j u n t o d e las p r e g u n t a s q u e d e b e n

•

¿Estos p u e d e n m a l i n t e r p r e t a r s e ?

¿El requisito e s r a s t r e a b l e p a r a c u a l q u i e r m o d e l o d e sistema q u e h a y a sido c r e a d o ?

•

¿El requisito e s r a s t r e a b l e p a r a los objetivos g e n e r a l e s del sistema o p r o d u c t o ?

•

¿La especificación está e s t r u c t u r a d a d e u n a f o r m a q u e

e r u n á a d o final d e l requisito h a sido e x a m i n a d o p o r la

c o n d u z c a a su c o m p r e n s i ó n , r e f e r e n c i a y traducción

u e n t e original o c o m p a r á n d o l o c o n ella?

fácil e n p r o d u c t o s d e t r a b a j o m á s técnicos?

; E -equisito está restringido en términos cuantitativos? j C u á l e s otros requisitos e s t á n r e l a c i o n a d o s con éste? j á i ó n registrados d e m a n e r a c l a r a p o r m e d i o d e u n a TTcfriz d e r e f e r e n c i a s c r u z a d a s u o t r o m e c a n i s m o ? •

•

fuente del requisito (por e j e m p l o , u n a p e r s o n a , u n a

-Eojloción o un reglamento) está identificada? ¿El

¡ 3 requisito viola a l g u n a restricción del d o m i n i o del

x

d e validación) p a r a ejercitar el requisito?

j - c s requisitos e s t á n e s t a b l e c i d o s d e m a n e r a c l a r a ? 2

K

de requisitos

• •

¿ S e h a c r e a d o a l g ú n índice p a r a la especificación? ¿Los requisitos a s o c i a d o s con el rendimiento, el d e s e m p e ñ o y las características o p e r o c i o n a l e s se h a n e s t a b l e c i d o d e m a n e r a c l a r a ? ¿ C u á l e s requisitos p a r e c e n ser implícitos?

TM

K

PDF Editor 7.2.7

« i a l e obtener de ü t sobre é

Gestión d e requisitos

En el capítulo 6 s e e s t a b l e c i ó q u e los requisitos p a r a los s i s t e m a s b a s a d o s e n c o m p u t a d o r a s c a m b i a n y q u e el d e s e o d e c a m b i a r l o s p e r s i s t e d u r a n t e la vida del s i s t e m a . La g e s t i ó n de r e q u i s i t o s e s u n c o n j u n t o de a c t i v i d a d e s q u e a y u d a n al e q u i p o d e p r o -

y e c t o a identificar, c o n t r o l a r y r a s t r e a r l o s r e q u i s i t o s y l o s c a m b i o s a e s t o s en c u a l -

162

PARTE D O S


quier m o m e n t o m i e n t r a s s e d e s a r r o l l a el p r o y e c t o . 5 M u c h a s d e e s t a s a c t i v i d a d e s s o a l i d é n t i c a s a l a s a c t i v i d a d e s d e la 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 w a r e (CCS) que I s e t r a t a n e n el c a p í t u l o 27. La g e s t i ó n de r e q u i s i t o s c o m i e n z a c o n la identificación. C a d a r e q u e r i m i e n t o se a s i g n a a u n s o l o i dent i fi cador. U n a v e z i d e n t i f i c a d o s los r e q u i s i t o s s e d e s a r r o l l a n las t a b l a s d e r a s t r e a b i l i d a d . En la figura 7.1 s e m u e s t r a de m a n e r a e s q u e m á t i c a u n a t a b l a d e r a s t r e a b i l i d a d , c a d a u n a de ellas r e l a c i o n a los r e q u i s i t o s c o n u n o o m a s a s p e c t o s del s i s t e m a o d e s u a m b i e n t e . Entre l a s m u c h a s t a b l a s de r a s t r e a b i l i d a d p o s i b l e s e s t á n las s i g u i e n t e s : ^CONSIJO^

T a b l a d e r a s t r e a b i l i d a d d e l a s c a r a c t e r í s t i c a s . M u e s t r a la m a n e r a e n q u e los r e q u i s i t o s s e r e l a c i o n a n c o n l a s c a r a c t e r í s t i c a s del s i s t e m a / p r o d u c t o o b s e r v a b l e s

Cuando un sistema es grande y complejo, la determinación de las conexiones entre los reqtiiíihK puede ser una totea redituable. Se recomiendo el uso de las tablas de rastreabilidad pora facilitar un

p a r a el cliente.

poco el trabajo.

s e r e l a c i o n a n c o n l a s i n t e r f a s e s i n t e r n a s y e x t e m a s del s i s t e m a .

T a b l a d e r a s t r e a b i l i d a d d e l a f u e n t e . Identifica la f u e n t e d e c a d a requisito. T a b l a d e r a s t r e a b i l i d a d d e d e p e n d e n c i a . Indica la f o r m a e n q u e los requisitos e s t á n r e l a c i o n a d o s e n t r e sí. T a b l a d e r a s t r e a b i l i d a d d e l s u b s i s t e m a . E s t a b l e c e c a t e g o r í a s e n t r e los requ: sitos d e a c u e r d o c o n el (los) s u b s i s t e m a (s) q u e g o b i e r n a (n). T a b l a d e r a s t r e a b i l i d a d d e l a i n t e r f a z . M u e s t r a la f o r m a e n q u e los requisitos

En m u c h o s c a s o s , e s t a s t a b l a s d e r a s t r e a b i l i d a d s e m a n t i e n e n c o m o p a r t e de la b a s e d e d a t o s de l o s r e q u i s i t o s d e f o r m a q u e p u e d a b u s c á r s e l e s c o n r a p i d e z para e n t e n d e r c ó m o el c a m b i o e n u n r e q u i s i t o a f e c t a r á d i f e r e n t e s a s p e c t o s del s i s t e m a que se construirá.

Tabla genérica de rastreabilidad.

\

M

Aspe<:to es pecí i c o d el sist e m a

• •, • , .

RequU I S ¡ T O ^ ^ \ ^ A 0 1 ROI

A03 A04 A05

3 SU Q mbie nte 8{J?ÍB5Í

Aíi

R02

•

R03 R04 R05

TM

PDF Editor Rnn

5

v H

La gestión formal de requisitos se inicia sólo para proyectos grandes, los cuales tienen cientos de requisitos identificables. En los proyectos pequeños esta función de la ingeniería de requisitos es bastante menos formal.

CAPÍTULO 7


163


Ingeniería

de requisitos

O b j e t i v o : Las herramientas d e la ingeniería

específico del proyecto que contiene descripciones y

d e requisitos ayudan en la recopilación,

atributos detallados d e los requisitos.

o, gestión y validación d e requisitos. l i c a : La mecánica d e las herramientas varía. Por lo * las herramientas d e la ingeniería d e requisitos i una variedad d e modelos gráficos (por d UML) que muestran los aspectos d e información, niento y comportamiento d e un sistema. Estos l forman la base p a r a todos las otras actividades r s Droceso del software.

titas representativas 6 : Systems Guide, Inc. ha p r e p a r a d o una lista i completa d e herramientas p a r a la i d e requisitos, ésta se p u e d e encontrar en i. systemsguild.com/Guildsite/Robs/retools . 5 modelado d e requisitos se estudia en el capítulo 8. E -etramientas q u e se presentan a continuación se i en la gestión de requisitos. , desarrollado por Cybernetic Intelligence GMBH --«•-«.easy-rm.com), construye un diccionario/glosario

OnVourMark Pro, desarrollado por Omni-Vista (www.omni-vista.com), construye una base d e datos d e los requisitos, establece relaciones entre éstos, y permite a los usuarios analizar la relación entre los requisitos y los calendarios/costos. Rational RequisitePro, desarrollado por Rational Software (www.rational.com), permite a los usuarios desarrollar una b a s e d e datos d e los requisitos, representa las relaciones entre éstos y los organiza, prioriza y rastrea. RTM, desarrollado por Integrated Chipware (www.chipware.com), es una herramienta p a r a la descripción y rastreobilidad d e requisitos q u e también soporta ciertos aspectos del control del cambio y gestión d e las pruebas. Se d e b e hacer notar que muchas tareas d e la gestión d e requisitos se pueden realizar con una simple hoja d e cálculo o un sistema p e q u e ñ o p a r a el manejo d e bases d e datos.

En u n e s c e n a r i o ideal, los c l i e n t e s y los i n g e n i e r o s de s o f t w a r e t r a b a j a n j u n t o s e n el m i s m o e q u i p o . 7 En t a l e s c a s o s , la i n g e n i e r í a d e r e q u i s i t o s se t r a t a s ó l o d e guiar c o n v e r s a c i o n e s significativas c o n c o l e g a s q u e s o n m i e m b r o s bien c o n o c i d o s del e q u i p o . Sin e m b a r g o , e n la r e a l i d a d a m e n u d o e s b a s t a n t e d i f e r e n t e . Los clientes p u e d e n e s t a r e n u n a c i u d a d o p a í s diferente, p u e d e n t e n e r s ó l o u n a idea v a g a de lo q u e se requiere, tal v e z t e n g a n o p i n i o n e s conflictivas a c e r c a del sistem a q u e s e construirá, q u i z á s u c o n o c i m i e n t o t é c n i c o s e a limitado y t e n g a n un t i e m p o limitado p a r a i n t e r a c t u a r c o n el i n g e n i e r o d e requisitos. N i n g u n a de e s t a s s i t u a c i o n e s e s d e s e a b l e , p e r o s o n m u y c o m u n e s , y el e q u i p o de s o f t w a r e c o n f r e c u e n c i a se ve oblig a d o a t r a b a j a r d e n t r o d e las r e s t r i c c i o n e s q u e i m p o n e e s t a situación. E n l a s s e c c i o n e s s i g u i e n t e s s e e x a m i n a n los p a s o s r e q u e r i d o s p a r a iniciar la i n g e niería d e requisitos; e s decir, p a r a c o m e n z a r un p r o y e c t o de f o r m a qTM ue se mantenga e n m o v i m i e n t o h a c i a u n a s o l u c i ó n exitosa.

PDF Editor 6

Las herramientas mencionadas aquí son una muestra dentro de esla categoría. En la mayoría de los casos los nombres están registrados por sus respectivos desarrolladores. 7 Este enfoque se recomienda para todos los proyectos y es una parte integral de la filosofía para el desarrollo ágil de software

164

PARTE D O S

fe?

7.3.1

CLAVE Un interesado es cualquiera que participo en forma directa en el sistema que se va a desarrollar u obtiene beneficios de éste.


Identificación d e los i n t e r e s a d o s

S o m m e r v i l l e y S a w y e r [SOM97] d e f i n e n a los interesados

c o m o "todos aquellos

se b e n e f i c i a n e n u n a f o r m a directa o indirecta del s i s t e m a q u e e s t á e n desarrollo* Ya se h a i d e n t i f i c a d o a los s o s p e c h o s o s u s u a l e s : g e r e n t e s de o p e r a c i o n e s d e nc cios, g e r e n t e s d e p r o d u c t o , g e n t e de m e r c a d o t e c n i a , c l i e n t e s i n t e r n o s y e x t e m o s u s u a r i o s finales, c o n s u l t o r e s , i n g e n i e r o s d e p r o d u c t o , i n g e n i e r o s d e s o f t w a r e , ing n i e r o s d e s o p o r t e y m a n t e n i m i e n t o y o t r o s . C a d a i n t e r e s a d o t i e n e u n a visión d i f r rente del s i s t e m a , o b t i e n e b e n e f i c i o s d i f e r e n t e s c u a n d o é s t e s e desarrolla de m a n " e x i t o s a , y e s t á a b i e r t o a d i f e r e n t e s r i e s g o s si el e s f u e r z o d e d e s a r r o l l o llegara a fallar En el inicio el i n g e n i e r o d e r e q u i s i t o s p u e d e c r e a r u n a lista d e p e r s o n a s q u e c tribuirán d u r a n t e la o b t e n c i ó n d e r e q u i s i t o s (sección 7.4). La lista inicial c r e c e r á c f o r m e s e e s t a b l e z c a c o n t a c t o c o n los i n t e r e s a d o s , ya q u e a c a d a u n o d e e l l o s se p r e g u n t a r á : "¿Con q u i é n m á s p i e n s a q u e d e b e r í a h a b l a r ? "

7.3.2

Reconocimiento d e múltiples p u n t o s d e vista

D e b i d o a q u e e x i s t e n m u c h o s c l i e n t e s d i f e r e n t e s , los r e q u i s i t o s del s i s t e m a s e explor a r á n d e s d e d i v e r s o s p u n t o s de vista. Por e j e m p l o , el g r u p o d e m e r c a d o t e c n i a est¿ i n t e r e s a d o e n f u n c i o n e s y c a r a c t e r í s t i c a s q u e e s t i m u l e n al m e r c a d o p o t e n c i a l , que h a g a n q u e el n u e v o s i s t e m a s e a fácil d e v e n d e r . Los g e r e n t e s d e n e g o c i o s e s t á n inter e s a d o s e n u n g r u p o d e c a r a c t e r í s t i c a s q u e s e p u e d a n c o n s t r u i r sin r e b a s a r u n pres u p u e s t o y q u e e s t é n l i s t a s p a r a llegar a n i c h o s d e m e r c a d o d e f i n i d o s . Los usuario s finales

p u e d e n d e s e a r c a r a c t e r í s t i c a s c o n las q u e e s t é n f a m i l i a r i z a d o s y s e a n fáciles

de a p r e n d e r y utilizar. Los i n g e n i e r o s de s o f t w a r e q u i z á e s t é n i n t e r e s a d o s e n func i o n e s q u e d e n el s o p o r t e d e la i n f r a e s t r u c t u r a y c a r a c t e r í s t i c a s m á s a c c e s i b l e s al m e r c a d o . Los i n g e n i e r o s de s o p o r t e s e p u e d e n e n f o c a r e n la facilidad d e m a n t e n i m i e n t o del s o f t w a r e . "Coloque a tres interesados en uno habitación y pregúnteles qué tipo de sistema quieren. Es probable que obtenga cuatro o más opiniones diferentes" Anónimo C a d a u n o de e s t o s c o m p o n e n t e s (y otros) p r o p o r c i o n a r á n i n f o r m a c i ó n al p r o c e s o de la ingeniería d e requisitos. C o n f o r m e s e r e c o p i l a i n f o r m a c i ó n d e s d e múltiples p u n t o s d e vista, l o s r e q u i s i t o s q u e s u r j a n p u e d e n s e r i n c o n s i s t e n t e s o e n t r a r e n c o n flicto c o n a l g ú n otro. El t r a b a j o del i n g e n i e r o de r e q u i s i t o s e s c TM a t e g o r i z a r toda la i n f o r m a c i ó n d e los i n t e r e s a d o s (incluidos los r e q u i s i t o s i n c o n s i s t e n t e s y conflictivosi e n u n a f o r m a q u e p e r m i t a a q u i e n e s t o m e n la d e c i s i o n e s elegir u n c o n j u n t o d e requi-

PDF Editor s i t o s p a r a el s i s t e m a q u e s e a n c o n s i s t e n t e s d e m a n e r a i n t e r n a .

7.3.3

Trabajo con respecto a la colaboración

En los c a p í t u l o s p r e v i o s s e h a m e n c i o n a d o q u e l o s c l i e n t e s (y o t r o s i n t e r e s a d o s i

d e b e r í a n c o l a b o r a r e n t r e sí (evitando p e l e a s insignificantes) y c o n los p r o f e s i o n a l e s

CAPÍTULO 7

165


de la ingeniería del s o f t w a r e si se d e s e a o b t e n e r u n sistema exitoso. Pero, ¿ c ó m o se logra e s t a colaboración? El t r a b a j o del ingeniero de requisitos e s identificar á r e a s en c o m ú n (es decir, los requisitos e n los que todos los i n t e r e s a d o s están de acuerdo) y á r e a s de conflicto o inconsistencia (esto es, los requisitos solicitados por u n interesado q u e e n t r a n en conflicto con las n e c e s i d a d e s de otro). Ésta es, por supuesto, la última categoría q u e p r e s e n t a un desafio. INFORMACIÓN

Utilización de los 'puntos

de prioridad"

Jna forma d e resolver los conflictos entre requisitos, al mismo tiempo q u e se entiende ««portando relativa d e todos, es la utilización d e : de "votación" b a s a d o en puntos d e prioridad. r * r e s a d o s reciben la misma cantidad de puntos que pueden "gastarse" en cualquier número d e Se presenta una lista d e requisitos y los

(desde su punto d e vista) al asignarle uno o más puntos de prioridad. Los puntos asignados no se pueden reutilizar. Una vez q u e los puntos d e prioridad del interesado se han a g o t a d o , dicha persona no puede realizar ninguna otra acción sobre los requisitos. Los puntos totales que asignen a c a d a requisito todos los interesados indican la importancia general d e c a d a requisito.

-id¡can la importancia relativa d e c a d a uno

La colaboración n o significa, n e c e s a r i a m e n t e , q u e los requisitos se definan por c o n s e n s o . En m u c h o s casos, los i n t e r e s a d o s colaboran al proporcionar su visión de los requisitos, pero un fuerte "campeón de proyecto" (por ejemplo, un gerente de negocios o u n técnico importante) p u e d e t o m a r la decisión final acerca de c u á l e s requisitos se aceptan.

7.3.4

Formulación d e las primeras preguntas

En e s t e capítulo se ha d e s t a c a d o q u e las p r e g u n t a s f o r m u l a d a s al inicio del proyecto d e b e n ser "libres de contexto" [GAU89]. El primer c o n j u n t o de p r e g u n t a s libres de c o n t e x t o se e n f o c a en el cliente y otros interesados, m e t a s g e n e r a l e s y en los Deneficios. Por ejemplo, el ingeniero de requisitos podría preguntar: • ¿Quién e s t á d e t r á s de la solicitud de este trabajo? • ¿Quién usará la solución? • ¿Cuál será el beneficio e c o n ó m i c o de u n a solución exitosa? • ¿Existe otra f u e n t e p a r a la solución requerida? Estas p r e g u n t a s ayudan a identificar a t o d o s los participantes q uTM e tendrían interés en el s o f t w a r e q u e s e r á construido. A d e m á s , estas p r e g u n t a s identifican el b e n e ficio medible de u n a implementación exitosa y las alternativas posibles p a r a perso-

PDF Editor nalizar el desarrollo del software.

"Es mejor saber oigo de bs preguntas que todo de los respuestas."

James Thnrber

166

PARTE D O S


La siguiente serie d e p r e g u n t a s p e r m i t e q u e el e q u i p o d e s o f t w a r e c o m p r e m e j o r el p r o b l e m a y deja q u e el cliente e x p r e s e s u s p e r c e p c i o n e s a c e r c a d e u n a ción: 7 ¿Cuales son • las preguntas que ayudan a omprender en forma preliminar el problema?

• ¿ C ó m o podría c a r a c t e r i z a r s e un b u e n resultado g e n e r a d o por u n a solución exitosa? • ¿Cuáles p r o b l e m a s debería a t a c a r esta solución? • ¿Podría usted describir o m o s t r a r el a m b i e n t e de negocios en el q u e s e utilizará la solución? • ¿Los a s p e c t o s e s p e c i a l e s del d e s e m p e ñ o o las restricciones a f e c t a r á n la fo en que s e b u s q u e la solución? La serie final de p r e g u n t a s s e e n f o c a e n la efectividad d e la actividad de c o m cación en sí m i s m a . Gause y Weinberg [GAU89] las llaman las " m e t a p r e g u n t a s ' p r o p o n e n la siguiente lista abreviada: • ¿Es usted la p e r s o n a a d e c u a d a p a r a c o n t e s t a r esta p r e g u n t a ? ¿Sus r e s p u e s t a s s o n "oficíales"? • ¿Mis p r e g u n t a s s o n r e l e v a n t e s p a r a su p r o b l e m a ? • ¿Estoy h a c i e n d o d e m a s i a d a s p r e g u n t a s ? • ¿Alguien m á s p u e d e p r o p o r c i o n a r información adicional? • ¿Debería p r e g u n t a r l e a l g u n a otra c o s a ? "0 que pregunta es un tonto durante tinto minutos; el que no pregunta es un tonto por siempre." Proverbio chino Estas p r e g u n t a s (y otras) a y u d a r á n a " r o m p e r el hielo" y a iniciar la conversación 1 esencial p a r a la o b t e n c i ó n exitosa. Pero un f o r m a t o d e reunión d e p r e g u n t a y resp u e s t a n o e s un e n f o q u e que haya sido exitoso d e m a n e r a c o n t u n d e n t e . De hecho, I la sesión d e p r e g u n t a s y r e s p u e s t a s s e d e be u s a r sólo p a r a el p r i m e r encuentro, y d e s p u é s s e debe r e e m p l a z a r por un f o r m a t o d e o b t e n c i ó n d e requisitos que combi- ! n e e l e m e n t o s de resolución d e p r o b l e m a s , n e g o c i a c i ó n y especificación. En la sección 7.4 s e p r e s e n t a u n e n f o q u e de e s t e tipo.

7.4

O B T E N C I Ó N DE R E Q U I S I T O S

TM El f o r m a t o d e p r e g u n t a y r e s p u e s t a descrito en la sección 7.3.4 e s útil en la e t a p a inicial, p e r o n o e s un e n f o q u e q u e h a y a s i d o exitoso de m a n e r a decisiva p a r a una

PDF Editor

o b t e n c i ó n d e requisitos m á s detallada; d e hecho, la s e s i ó n d e p r e g u n t a s y respuestas s e deb e usar sólo p a r a el primer e n c u e n t r o y d e s p u é s se d e b e r e e m p l a z a r por un f o r m a t o d e o b t e n c i ó n d e requisitos q u e c o m b i n e e l e m e n t o s d e la resolución, elaboración, n e g o c i a c i ó n y especificación del p r o b l e m a . En la siguiente sección s e pre-

s e n t a u n e n f o q u e d e e s t e tipo.

CAPITULO 7

7.4.1

167


Recopilación c o n j u n t a d e requisitos

C u a n d o s e d e s e a e s t i m u l a r u n e s f u e r z o c o n j u n t o y o r i e n t a d o al e q u i p o d e r e c o p i l a ción de requisitos, u n e q u i p o d e p a r t i c i p a n t e s y d e s a r r o l l a d o r e s t r a b a j a n j u n t o s p a r a identificar el p r o b l e m a , p r o p o n e r e l e m e n t o s d e s o l u c i ó n , n e g o c i a r d i f e r e n t e s e n f o q u e s y e s p e c i f i c a r u n c o n j u n t o p r e l i m i n a r d e r e q u i s i t o s p a r a la s o l u c i ó n [ZAH90]. 8 Se h a n p r o p u e s t o s m u c h o s y d i f e r e n t e s e n f o q u e s p a r a la r e c o p i l a c i ó n c o n j u n t a de requisitos. C a d a u n o utiliza u n e s c e n a r i o m u y diferente, p e r o t o d o s a p l i c a n a l g u n a v a r i a c i ó n de l a s s i g u i e n t e s d i r e c t r i c e s b á s i c a s : • Las r e u n i o n e s l a s dirige a l g u n o de los a s i s t e n t e s , ya s e a u n i n g e n i e r o de

¿Cuóles son las básicas a cabo

s o f t w a r e o u n cliente (junto c o n o t r o s p a r t i c i p a n t e s i n t e r e s a d o s ) . • Se e s t a b l e c e n r e g l a s p a r a la p r e p a r a c i ó n y la p a r t i c i p a c i ó n . • Se s u g i e r e u n a a g e n d a q u e s e a ta n f o r m a l c o m o p a r a cubrir t o d o s l o s p u n t o s i m p o r t a n t e s , p e r o t a n i n f o r m a l c o m o p a r a e s t i m u l a r el flujo d e ideas. • Un m o d e r a d o r ( p u e d e s e r u n cliente, u n d e s a r r o l l a d o r o u n a g e n t e e x t e r n o ) c o n t r o l a la r e u n i ó n . • Se utiliza u n " m e c a n i s m o de d e f i n i c i ó n " ( p u e d e n s e r h o j a s d e t r a b a j o , gráficos, h o j a s a d h e r i b l e s , u n t a b l e r o e l e c t r ó n i c o , u n m e n s a j e r o e l e c t r ó n i c o o un f o r o virtual). • La m e t a e s identificar el p r o b l e m a , p r o p o n e r e l e m e n t o s d e s o l u c i ó n , n e g o c i a r d i f e r e n t e s e n f o q u e s y e s p e c i f i c a r u n c o n j u n t o d e r e q u i s i t o s d e s o l u c i ó n prelim i n a r e s e n u n a a t m ó s f e r a q u e c o n d u z c a al c u m p l i m i e n t o d e la m e t a . Para e n t e n d e r m e j o r el flujo d e los e v e n t o s ( c o n f o r m e é s t o s o c u r r e n ) , s e p r e s e n t a u n e s c e n a r i o b r e v e q u e d e s c r i b e la s e c u e n c i a de e v e n t o s q u e c o n d u c e n a la r e u nión p a r a la r e c o p i l a c i ó n d e r e q u i s i t o s y q u e o c u r r e n d u r a n t e la r e u n i ó n y d e s p u é s de ésta.

"Dedicamos mucho tiempo - l o mayoría del esfuerzo del proyecto- no a la ¡mplementación ni a las pruebas, sino a tratar de decidir qué es lo que se va a construir." Brian Lawrence

D u r a n t e la f a s e d e inicio (sección 7.3), l a s p r e g u n t a s y r e s p u e s t a s b á s i c a s e s t a b l e c e n el á m b i t o del p r o b l e m a y la p e r c e p c i ó n global d e u n a s o l u c i ó nTM . Fuera d e e s t a s r e u n i o n e s iniciales, los p a r t i c i p a n t e s e s c r i b e n u n a "solicitud d e p r o d u c t o " d e u n a o d o s p á g i n a s . Se fijan un lugar, u n a h o r a y u n a f e c h a p a r a la r e u n i ó n y s e s e l e c c i o n a

PDF Editor

u n m o d e r a d o r . Los m i e m b r o s del e q u i p o d e s o f t w a r e y o t r a s o r g a n i z a c i o n e s i n t e r e -

8

A este enfoque se le llama algunas veces técnica de especificación facilitada de la aplicación (FAST, por sus siglas en inglés).

llilIMi

168

PARTE DOS


s a d a s s o n i n v i t a d o s a asistir. La solicitud d e p r o d u c t o s e distribuye a t o d o s los asist e n t e s a n t e s de la f e c h a d e r e u n i ó n . M i e n t r a s revisa la solicitud de p r o d u c t o e n los d í a s p r e v i o s a la r e u n i ó n , s e p i d e a c a d a a s i s t e n t e h a c e r u n a lista d e o b j e t o s q u e s o n p a r t e del a m b i e n t e q u e r o d e a al sist e m a , o t r o s o b j e t o s q u e é s t e p r o d u c i r á , y o b j e t o s q u e utiliza p a r a r e a l i z a r s u s f u n c i o n e s . A d e m á s , s e le p i d e a c a d a a s i s t e n t e q u e e l a b o r e u n a lista d e los servicios ( p r o c e s o s o f u n c i o n e s ) q u e m a n i p u l a n o i n t e r a c t ú a n c o n los o b j e t o s . Por último, requisitos. En

t a m b i é n s e p r e p a r a n listas de las r e s t r i c c i o n e s (por e j e m p l o , c o s t o , t a m a ñ o , r e g l a s

www.rarola.

del n e g o c i o ) y d e los criterios d e r e n d i m i e n t o (por e j e m p l o , v e l o c i d a d , exactitud). Se

com/wp-jadJitm

i n f o r m a a los a s i s t e n t e s q u e n o s e e s p e r a q u e l a s listas s e a n e x h a u s t i v a s , s i n o q u e

bueno descripción de

reflejen la p e r c e p c i ó n q u e c a d a p e r s o n a t i e n e del s i s t e m a . C o m o u n e j e m p l o , 9 c o n s i d é r e s e el f r a g m e n t o d e u n d o c u m e n t o p r e v i o a la reunión, e s c r i t o por u n a p e r s o n a de m e r c a d o t e c n i a i n v o l u c r a d a e n el p r o y e c t o de HogarSeguro.

Esta p e r s o n a escribe la s i g u i e n t e n a r r a c i ó n a c e r c a de la f u n c i ó n de s e g u -

ridad e n el h o g a r q u e s e r á p a r t e d e HogarSeguro. Nuestra investigación indica que el mercado para los sistemas de administración del hogar está creciendo a una tasa de 40 por ciento anual. La primera función de HogarSeguro que saquemos al mercado debería ser ia función de seguridad en el hogar. La mayoría de la gente está familiarizada con los "sistemas de alarma", por lo que dicha función sería fácil de vender. La función de seguridad en el hogar protegería contra o reconocería una variedad de "situaciones" indeseables como una entrada ilegal, fuego, inundaciones, niveles de monóxido de carbono y otras. Utilizará nuestros sensores inalámbricos para detectar cada situación, el usuario podrá programarla y llamará por teléfono automáticamente a una ÔNSEJO^ Si un sistema o producto servirá o muchos usuarios se debe tener lo completa seguridad de que los requisitos se obtienen de una muestra representativo de los usuarios. Si sólo uno de los usuarios define todos los requisitos, el tiesgo de rechazo es alto.

oficina de monitoreo cuando detecte alguna situación. En r e a l i d a d , o t r o s p o d r í a n c o n t r i b u i r a e s t e r e l a t o d u r a n t e la r e u n i ó n p a r a la r e c o pilación d e r e q u i s i t o s , y m u c h a m á s i n f o r m a c i ó n e s t a r í a disponible. P e r o a u n c o n i n f o r m a c i ó n adicional, la a m b i g ü e d a d p o d r í a e s t a r p r e s e n t e , e s p r o b a b l e q u e existieran o m i s i o n e s y p o d r í a n ocurrir e r r o r e s . Por a h o r a , la "descripción f u n c i o n a l " anterior será suficiente. El e q u i p o d e r e c o p i l a c i ó n de r e q u i s i t o s lo c o m p o n e n r e p r e s e n t a n t e s d e los d e p a r t a m e n t o s d e m e r c a d o t e c n i a , de i n g e n i e r í a d e h a r d w a r e y s o f t w a r e y de m a n u f a c t u ra. Se utilizará u n m o d e r a d o r e x t e r n o . C a d a p e r s o n a d e s a r r o l l a l a s listas p r e v i a m e n t e d e s c r i t a s . p a r a HogarSeguro

Los o b j e t o s d e s c r i t o s

p o d r í a n incluir el p a n e l d e control, los d e t e c t o rTM e s d e h u m o , los

s e n s o r e s e n p u e r t a s y v e n t a n a s , l o s d e t e c t o r e s de m o v i m i e n t o , u n a a l a r m a , u n e v e n to ( c u a n d o a l g ú n s e n s o r se active), u n a p a n t a l l a , u n a PC, n ú m e r o s t e l e f ó n i c o s , u n a

PDF Editor

9. El ejemplo de HogarSeguro (con extensiones y variaciones) se utiliza para ilustrar métodos importantes de la ingeniera del software en muchos de los capítulos que siguen. Como ejercicio, seria útil realizar una reunión para la recopilación de requisitos propia y desarrollar una serie de listas para ésta.

CAPÍTULO 7

169


l l a m a d a t e l e f ó n i c a y o t r o s . La lista d e s e r v i c i o s p o d r í a incluir la configuración t e m a , la colocación la programación

d e la a l a r m a , el monitoreo

d e s e n s o r e s , la marcación

del sis-

telefónica,

del p a n e l d e c o n t r o l y la lectura de p a n t a l l a ( o b s é r v e s e q u e los s e r -

vicios a c t ú a n s o b r e los o b j e t o s ) . D e u n a m a n e r a similar, c a d a a s i s t e n t e e l a b o r a r á list a s d e r e s t r i c c i o n e s (por e j e m p l o , el s i s t e m a d e b e r e c o n o c e r c u a n d o los s e n s o r e s n o e s t é n e n f u n c i o n a m i e n t o , d e b e s e r a m i g a b l e p a r a el u s u a r i o , d e b e t e n e r u n a i n t e r f a z d i r e c t a c o n la l í n e a telefónica) y c r i t e r i o s d e r e n d i m i e n t o (por e j e m p l o , el e v e n t o d e un sensor debe ser reconocido en un segundo o menos; se debe implementar un e s q u e m a p a r a la prioridad d e l o s e v e n t o s ) . "los hechos no dejan de existir sólo porque son ignorados." Aldoas Huxley C u a n d o se inicia la r e u n i ó n p a r a la r e c o p i l a c i ó n de d o c u m e n t o s , el p r i m e r t ó p i c o q u e s e t r a t a e s la n e s e s i d a d y la justificación p a r a el n u e v o p r o d u c t o , t o d o s d e b e n e s t a r d e a c u e r d o e n q u e la n e c e s i d a d del p r o d u c t o s e justifica. U n a v e z e s t a b l e c i d o el a c u e r d o , c a d a p a r t i c i p a n t e p r e s e n t a s u s listas p a r a e x a m i n a r l a s . Las listas p u e d e n fijarse e n las p a r e d e s del s a l ó n u s a n d o h o j a s g r a n d e s d e p a p e l , p e g a r s e e n los m u r o s m e d i a n t e h o j a s a d h e s i v a s o e s c r i b i r s e e n u n p i z a r r ó n . De m a n e r a a l t e r n a t i v a , las list a s p u e d e n h a b e r s i d o c o l o c a d a s e n u n boletín e l e c t r ó n i c o , e n u n sitio W e b i n t e r n o , o s i t u a d a s d e n t r o d e u n a m b i e n t e d e f o r o de d i s c u s i ó n (chat room) p a r a r e v i s a r l a s a n t e s d e la r e u n i ó n . En f o r m a ideal, c a d a a s u n t o e n la lista d e b e p e r m i t i r m a n i p u larse p o r s e p a r a d o p a r a q u e l a s listas se p u e d a n c o m b i n a r , los a s u n t o s p u e d a n b o r r a r s e y s e l e s p u e d a n r e a l i z a r a d i c i o n e s . En e s t a e t a p a la crítica y el d e b a t e e s t á n estrictamente prohibidos. D e s p u é s d e q u e las listas i n d i v i d u a l e s s o b r e el á r e a d e u n t ó p i c o s e h a y a n p r e s e n t a d o , el g r u p o c r e a u n a lista c o m b i n a d a . Dicha lista e l i m i n a l o s a s u n t o s r e d u n i reprimir el t á e ignorar la i cíente por NA costoso" 0 i táctica". La naques r uno listo que ¡para i lograr b

ib mente

d a n t e s , i n c o r p o r a i d e a s n u e v a s s u r g i d a s d u r a n t e el d e b a t e , p e r o n o b o r r a n a d a . D e s p u é s d e h a b e r s e c r e a d o las listas c o m b i n a d a s p a r a t o d a s l a s á r e a s d e l o s distint o s t ó p i c o s , el m o d e r a d o r c o o r d i n a el d e b a t e . La lista c o m b i n a d a s e r e d u c e , se i n c r e m e n t a o r e p l a n t e a p a r a r e f l e j a r de m a n e r a a p r o p i a d a el p r o d u c t o / s i s t e m a q u e s e d e s a r r o l l a r á . El o b j e t i v o e s d e s a r r o l l a r u n a lista c o n s e n s a d a e n el á r e a d e c a d a tópico (objetos, servicios, r e s t r i c c i o n e s y r e n d i m i e n t o ) . D e s p u é s d i c h a s listas s e integ r a n p a r a la a c c i ó n p o s t e r i o r . C u a n d o s e c o m p l e t a n las listas c o n s e s a d a s , el e q u i p o s e divide en s u b e q u i p o s m e n o r e s ; c a d a u n o t r a b a j a p a r a d e s a r r o l l a r miniespecificaciones

pTM ara u n o o m á s

a s u n t o s d e c a d a u n a d e l a s listas. 1 0 C a d a m i n i e s p e c i f i c a c i ó n e s u n a e x p l i c a c i ó n c o n cisa d e la p a l a b r a o f r a s e c o n t e n i d a e n la lista. Por e j e m p l o , la m i n i e s p e c i f i c a c i ó n

PDF Editor p a r a el o b j e t o P a n e l d e c o n t r o l d e HogarSeguro

p o d r í a ser:

10 En lugar de crear miniespecificaciones, muchos equipos de software eligen desarrollar escenarios del usuario llamados casos de uso. Éstos se consideran con detalle en la sección 7.5.

r

11

170

PARTE DOS


El Panel de control es una unidad empotrada en la pared con un tamaño aproximado de 9 x 5 pulgadas. El panel de control tiene conexión inalámbrica con los sensores y una PC La interacción con el usuario ocurre por medio de un tablero de 12 teclas. Una pantalla LCD de 2 x 2 pulgadas proporciona la retroalimentación del usuario. El software provee sugerencias e imágenes interactivas y funciones similares. D e s p u é s , c a d a s u b e q u i p o p r e s e n t a s u s m i n i e s p e c i f i c a c i o n e s a t o d o s los a s i s t e n t e s p a r a c o m e n t a r l a s . Se r e a l i z a n l a s a d i c i o n e s , a n u l a c i o n e s y e l a b o r a c i o n e s posten:-! res. En a l g u n o s c a s o s , el d e s a r r o l l o d e las m i n i e s p e c i f i c a c i o n e s d e s c u b r i r á n u e v e * r e q u i s i t o s d e o b j e t o s , servicios, r e s t r i c c i o n e s y r e n d i m i e n t o q u e s e a g r e g a r á n a las listas originales. D u r a n t e los d e b a t e s el e q u i p o e n c o n t r a r á a l g ú n a s u n t o q u e i p u e d a r e s o l v e r s e d u r a n t e la r e u n i ó n . Se m a n t e n d r á u n a lista de a s u n t o s p e n d i e n t e s p a r a q u e d e s p u é s s e p u e d a a c t u a r s o b r e e s t a s ideas. D e s p u é s d e c o m p l e t a r l a s m i n i e s p e c i f i c a c i o n e s , c a d a a s i s t e n t e h a c e u n a lista ó a criterios d e validación p a r a el p r o d u c t o / s i s t e m a y la p r e s e n t a al e q u i p o . E n t o n c e s s a c r e a u n a lista c o n s e n s a d a d e criterios d e v a l i d a c i ó n . Por último, u n o o m á s p a r t i ó ! p a n t e s (o a g e n t e s e x t e m o s ) r e c i b e n el e n c a r g o d e escribir l a s e s p e c i f i c a c i o n e s c o r - i p l e t a s m e d i a n t e el u s o de t o d a s los a s u n t o s t r a t a d o s e n la r e u n i ó n . HOGARSEGURO

Guiar una reunión

para ¡a recopilación

Ei escenario: Una sala de reuniones. Se realiza la primera reunión p a r a la recopilación d e requisitos. Los a c t o r e s : J a m i e Lazar, miembro del e q u i p o d e software; Vinod Raman, miembro del e q u i p o d e software; Ed Robbins, miembro del e q u i p o d e software; Doug Miller, miembro del e q u i p o d e software; tres miembros d e mercadotecnia; un representante d e ingeniería del producto; y un moderador.

La conversación:

.

Moderador ( a p u n t a n d o hacia ei pizarrón b l a n c o ) : Entonces é s a e s la lista actual d e objetos y

de requisitos

J a m i e : Sí, tanto técnicas c o m o legales.

Representante d e producción: ¿Y eso qué significa? J a m i e : D e b e m o s estar seguros d e que alguien externo n o p u e d a entrar e n el sistema, d e s a r m a d o y robar la c a s a o h a c e r a l g o peor. G r a n parte d e la responsabilidad r e c a e e n nosotros.

Doug: Muy cierto. M e r c a d o t e c n i a : Pero a u n así necesitamos la conectívidad p o r Internet... sólo asegúrense de impedir que cualquier intruso entre.

servicios p a r a la función d e seguridad e n el hogar.

Ed: Es más fácil decirlo que hacerlo y...

Persona d e mercadotecnia: Desde nuestra

Moderador (interrumpiendo): No quiero debatir

perspectiva, esta lista a b a r c a t o d a la función.

este asunto a h o r a . Anotemos q u e e s una acción q u e

V i n o d : ¿ N a d i e mencionó q u e los usuarios querían t o d a

d e b e realizarse y continuemos.

la funcionalidad d e H o g a r S e g u r o accesible por Internet?

(Doug, que lleva el registro d e b reunión, h a c e la

Eso incluiría la función d e seguridad en el hogar, ¿no?

anotación correspondiente.)

TM

PDF Editor Persona d e mercadotecnia: Sí, es correcto...

M o d e r a d o r : Siento que a ú n h a y m á s cosas p o r

tendremos q u e a g r e g a r e s a funcionalidad y los objetos

considerar aquí.

apropiados.

Facilitador:

restricciones?

'{

¿Eso también a g r e g a a l g u n a s

(El g r u p o utiliza los siguientes 4 5 minutos en refinar y e x p a n d i r los detalles d e la función d e seguridad en el hogar.)

CAPÍTULO 7

7.4.2


171

Despliegue d e la función d e calidad

El despliegue de la Junción de calidad (QFD. por sus siglas e n inglés) es u n a técnica que traduce las n e c e s i d a d e s del cliente en requisitos técnicos para el software. El QFD "se concentra en a u m e n t a r la satisfacción del cliente desde el proceso de la ingeniería del s o f t w a r e [ZUL92]." Para lograr lo anterior, el QFD resalta una c o m prensión de lo que es valioso para el cliente y d e s p u é s despliega estos valores durante el p r o c e s o de ingeniería. El QFD identifica tres tipos de requisitos [ZUL92]: R e q u i s i t o s n o r m a l e s . Reflejan los objetivos y m e t a s establecidos para un producto o sistema d u r a n t e las reuniones con el cliente. Si estos requisitos están presentes, el cliente estará satisfecho. Algunos ejemplos de requisitos normales podría n ser los tipos de gráficos en pantalla, las funciones específicas del sistema, y los niveles de rendimiento solicitados. Requisitos e s p e r a d o s . Están implícitos en el producto o sistema y pueden parecer tan obvios, aunque son fundamentales, que el cliente no los establece de manera explícita. Su ausencia causaría u n a insatisfacción significativa. Algunos ejemplos de requisitos esperados son la facilidad de la interacción h u m a n o / m á q u i n a , corrección y confiabilidad operacional general y facilidad en la instalación del software. R e q u i s i t o s e s t i m u l a n t e s . Reflejan las características que van m á s allá de las expectativas del cliente y que p r u e b a n ser m u y satisfactorias c u a n d o están presentes. Por ejemplo, u n s o f t w a r e procesador de palabras se solicita con características estándar. El producto e n t r e g a d o contiene varias capacidades de configuración de página que son b a s t a n t e satisfactorias e inesperadas. En la actualidad, el QFD abarca la totalidad del proceso de ingeniería [PAR96]. Sin embargo, muchos conceptos del QFD son aplicables a la actividad de obtención de requisitos. En los párrafos siguientes se presenta una visión general de dichos conceptos (adaptados para el software de computadora).

"A menudo los expectativas fallan, y entre más lo hocen más prometen.* Wilfiam Shakespeare En las reuniones con el cliente, la Junción de despliegue se aplica para determinar el valor de cada función que se requiere para el sistema. El despliegue de la información identifica los d a t o s de los objetos y e v e n t o s que debe consumir yTM producir el sistema. Los datos están ligados a las funciones. Por último, el despliegue de tareas examina el c o m p o r t a m i e n t o del sistema o producto dentro del contexto de su entorno.

PDF Editor

El análisis de valor se realiza para determinar la prioridad relativa de los requisitos

d e t e r m i n a d o s durante cada u n o de los tres despliegues.

El QFD utiliza entrevistas y observación del cliente, s o n d e o s y exploración de los

d a t o s históricos (por ejemplo, los reportes de problemas) c o m o d a t o s crudos para la actividad de recopilación de requisitos. Después, e s t o s d a t o s se traducen en u n a

172

PARTE DOS


tabla d e requisitos — l l a m a d a la tabla de la voz del cliente— q u e s e revisa c o n el cliente Una variedad d e d i a g r a m a s , m a t r i c e s y m é t o d o s d e evaluación s e utilizan p a r a obtener los requisitos e s p e r a d o s y tratar de c o n s e g u i r los requisitos e s t i m u l a n t e s [BOS91].

7.4.3

Escenarios del u s u a r i o

C o n f o r m e se r e c o p i l a n los r e q u i s i t o s s e c o m i e n z a a m a t e r i a l i z a r u n a visión g e n e r a de l a s f u n c i o n e s y c a r a c t e r í s t i c a s del s i s t e m a . Sin e m b a r g o , r e s u l t a difícil continuar c o n a c t i v i d a d e s d e ingeniería del s o f t w a r e m á s t é c n i c a s m i e n t r a s el e q u i p o d e softw a r e n o e n t i e n d a la m a n e r a e n q u e las d i s t i n t a s c l a s e s d e u s u a r i o s f i n a l e s a p l i c a r á n e s t a s f u n c i o n e s y c a r a c t e r í s t i c a s . P a r a lograrlo, los d e s a r r o l l a d o r e s y u s u a r i o s p u e - ¡ d e n c r e a r un c o n j u n t o d e e s c e n a r i o s q u e identifican u n a c a d e n a d e u s o p a r a el sist e m a q u e s e va a c o n s t r u i r . Los e s c e n a r i o s , l l a m a d o s c o n f r e c u e n c i a casos de use (JAC92], p r o p o r c i o n a n u n a d e s c r i p c i ó n d e c ó m o s e u s a r á el s i s t e m a . Los c a s o s de u s o se e x a m i n a n c o n u n m a y o r detalle e n la s e c c i ó n 7.5. HOGARSEGURO

Desarrollo

de un escenario

El e s c e n a r i o : Una sala d e •euniones. Continúa la primera reunión p a r a la

de uso preliminar M o d e r a d o r ( s o n r i e n d o ) : Ésa es la razón por lo q u e lo harías... dime cómo lo harías realmente. P e r s o n a d e m e r c a d o t e c n i a : Humm..., la primera

recopilación d e requisitos. Los a c t o r e s : Jamie Lazar, miembro del equipo d e software; Vinod Román, miembro del equipo d e software; Ed Robbins, miembro del equipo d e software; Doug Miller, miembro del equipo d e software; tres miembros d e mercadotecnia; un representante d e ingeniería del producto; y un moderador.

cosa q u e necesitaría es una PC. Entraría en un sitio web que tendríamos p a r a todos los usuarios d e HogarSeguro. Introduciría mi identificación d e usuario y... V i n o d ( i n t e r r u m p i e n d o ) : La p á g i n a w e b tendría que estar a s e g u r a d a , codificada, p a r a garantizar q u e

La conversación:

estamos seguros y... M o d e r a d o r ( i n t e r r u m p i e n d o ) : Ésa es una buena información, Vinod, pero es técnica. Vamos a enfocarnos

M o d e r a d o r : Hemos estado h a b l a n d o acerca d e la

en la forma en q u e el usuario final usará esta c a p a c i d a d ,

seguridad p a r a el acceso a la funcionalidad d e

¿de acuerdo? V i n o d : N o hay problema.

HogarSeguro,

la cual será accesible por Internet. Me

gustaría tratar algo.

P e r s o n a d e m e r c a d o t e c n i a : Entonces, como estaba

Desarrollemos un escenario d e uso p a r a el acceso a la

diciendo, entraría en ei sitio web e introduciría mi

función d e seguridad en el hogar. J a m i e : ¿Cómo?

" •

M o d e r a d o r : Podemos hacerlo d e un p a r d e formas,

identificación d e usuario y dos niveles de contraseña. J a m i e : ¿Qué p a s a si olvido mi contraseña? M o d e r a d o r ( i n t e r r u m p i e n d o ) : Buen punto, Jamie, pero no vamos a profundizar en eso a h o r a . Haremos

pero por a h o r a me gustaría mantener las cosas realmente informales. Dinos (y a p u n t a a una persona d e

TM una nota del tema y la llamaremos una "excepción*.

mercadotecnia) cómo visualizas el acceso al sistema.

P e r s o n a d e m e r c a d o t e c n i a : Después d e introducir

Estoy seguro q u e existirán otras.

PDF Editor P e r s o n a d e m e r c a d o t e c n i a : Humm..., bueno, es lo

las contraseñas, a p a r e c e r á una pantalla representando

que haría si estuviera fuera d e c a s a y tuviera que d e j a r a

todas las funciones d e SafeHome. Seleccionaría lo

alguien dentro, digamos una persona d e limpieza o un técnico en reparaciones, quien no tendría el código d e

función de seguridad en ei hogar. El sistema podría

seguridad.

preguntándome mi dirección, teléfono o a l g o así.

requerir que yo verificara quién soy, digamos

CAPÍTULO 7


d e s p l e g a r í a u n a imagen del panel d e control del de seguridad, ¡unto con u n a lista d e las funciones p u e d o realizar: activar el sistema, desactivar el desactivar uno o m á s sensores. S u p o n g o q u e i p o d r í a permitirme reconfigurar las z o n a s d e ' y otras cosas c o m o é s a , pero no estoy seguro.

7.4.4

173

(Mientras la p e r s o n a d e mercadotecnia continúa h a b l a n d o , Doug toma las notas correspondientes. Dichas notas forman la b a s e p a r a el primer caso d e uso informal. De m a n e r a alternativa, se le p u d o h a b e r p e d i d o a la p e r s o n a d e mercadotecnia q u e escribiera el escenario, pero esto se h a r í a fuera d e la reunión.)

Productos d e t r a b a j o d e l a o b t e n c i ó n

Los p r o d u c t o s d e t r a b a j o p r o d u c i d o s c o m o c o n s e c u e n c i a de la o b t e n c i ó n de requisit o s v a r i a r á de a c u e r d o c o n el t a m a ñ o del s i s t e m a o p r o d u c t o q u e s e v a y a a c o n s t r u i r . La m a y o r í a d e los s i s t e m a s incluye los s i g u i e n t e s p r o d u c t o s d e t r a b a j o : • Un e n u n c i a d o d e n e c e s i d a d y factibilidad. • Un e n u n c i a d o limitado del á m b i t o del s i s t e m a o p r o d u c t o . • U n a lista de clientes, u s u a r i o s y o t r o s i n t e r e s a d o s q u e p a r t i c i p a r o n e n la o b t e n c i ó n d e requisitos. • U n a d e s c r i p c i ó n del a m b i e n t e t é c n i c o del s i s t e m a . • U n a lista d e r e q u i s i t o s (de m a n e r a p r e f e r e n t e o r g a n i z a d o s p o r f u n c i ó n ) y las restricciones de dominio aplicables a c a d a uno. • Un c o n j u n t o d e e s c e n a r i o s d e u s o q u e p r o p o r c i o n e n u n d i s c e r n i m i e n t o d e la utilización del s i s t e m a o p r o d u c t o e n d i f e r e n t e s c o n d i c i o n e s d e o p e r a c i ó n . • C u a l e s q u i e r a p r o t o t i p o s d e s a r r o l l a d o s p a r a definir d e m e j o r f o r m a los r e q u i sitos. C a d a u n o d e e s t o s p r o d u c t o s d e t r a b a j o los r e v i s a t o d a la g e n t e q u e h a p a r t i c i p a d o e n la o b t e n c i ó n d e requisitos.

7.5

D E S A R R O L L O P E C A S O S DE USO En u n libro q u e a n a l i z a la m a n e r a d e escribir c a s o s de u s o e f i c a c e s , Alistair C o c k b u r n [COCO 1 ] m e n c i o n a q u e "un c a s o d e u s o c a p t u r a u n c o n t r a t o . . . [que] d e s c r i b e el c o m -

kVE "«usóse : d punto B octor. • popel

p o r t a m i e n t o del s i s t e m a e n d i f e r e n t e s c o n d i c i o n e s m i e n t r a s é s t e r e s p o n d e a la p e t i ción d e u n o d e s u s u s u a r i o s " . En e s e n c i a , u n caso de uso c u e n t a u n a historia estiliz a d a d e la m a n e r a e n q u e un u s u a r i o final (el c u a l d e s e m p e ñ a u n o TM de varios p a p e les posibles) i n t e r a c t ú a c o n el s i s t e m a e n u n c o n j u n t o e s p e c í f i c o d e c i r c u n s t a n c i a s . La historia p u e d e s e r u n t e x t o n a r r a t i v o , u n e s q u e m a d e t a r e a s o i n t e r a c c i o n e s , u n a

PDF Editor • los

i cuando cor el

d e s c r i p c i ó n b a s a d a e n u n a plantilla o u n a r e p r e s e n t a c i ó n por m e d i o d e d i a g r a m a s . Sin i m p o r t a r s u f o r m a , u n c a s o de u s o m u e s t r a el s o f t w a r e o s i s t e m a d e s d e el p u n t o de vista del u s u a r i o final.

El p r i m e r p a s o al escribir u n c a s o d e u s o c o n s i s t e e n definir el c o n j u n t o de " a c t o -

r e s " q u e e s t a r á n i n v o l u c r a d o s e n la historia. Los actores s o n las d i f e r e n t e s p e r s o n a s

. Ü1HB

174

PASTE DOS


(o dispositivos) q u e u t i l i z a n el s i s t e m a o p r o d u c t o d e n t r o del c o n t e x t o d e la f u n c i ó r y el c o m p o r t a m i e n t o q u e se describirá. Los a c t o r e s r e p r e s e n t a n l o s p a p e l e s q u e jueg a n las p e r s o n a s (o dispositivos) c o n f o r m e el s i s t e m a o p e r a . D e f i n i d o d e u n a m a n e r a m á s f o r m a l , u n a c t o r e s a l g ú n e l e m e n t o q u e s e c o m u n i c a c o n el s i s t e m a o prod u c t o y q u e e s e x t e r n o al s i s t e m a e n sí m i s m o . C a d a a c t o r t i e n e u n a o m á s m e t a s c u a n d o utiliza el s i s t e m a . Es i m p o r t a n t e s e ñ a l a r q u e u n a c t o r y u n u s u a r i o final n o s o n n e c e s a r i a m e n t e le m i s m o . Un u s u a r i o típico p u e d e d e s e m p e ñ a r v a r i o s p a p e l e s al u s a r u n s i s t e m a m i e n t r a s q u e u n a c t o r r e p r e s e n t a u n a c l a s e de e n t i d a d e x t e r n a (con f r e c u e n c i a , pern o s i e m p r e , u n a p e r s o n a ) q u e d e s e m p e ñ a s ó l o u n p a p e l e n el c o n t e x t o del c a s o de u s o . C o m o u n e j e m p l o , c o n s i d é r e s e al o p e r a d o r d e u n a m á q u i n a (un u s u a r i o ) que i n t e r a c t ú a c o n la c o m p u t a d o r a d e c o n t r o l p a r a u n a célula d e m a n u f a c t u r a q u e cont i e n e v a r i o s r o b o t s y m á q u i n a s d e c o n t r o l n u m é r i c o . D e s p u é s de la revisión cuidad o s a de los requisitos, el s o f t w a r e p a r a la c o m p u t a d o r a d e c o n t r o l r e q u i e r e cuatrc d i f e r e n t e s m o d o s (actores) p a r a su i n t e r a c c i ó n : m o d o d e p r o g r a m a c i ó n , m o d o de p r u e b a , m o d o d e m o n i t o r e o y m o d o d e r e s o l u c i ó n d e p r o b l e m a s . Por lo t a n t o , se p u e d e n definir c u a t r o a c t o r e s : el p r o g r a m a d o r , el q u e r e a l i z a l a s p r u e b a s , el que m o n i t o r e a y el q u e r e s u e l v e los p r o b l e m a s . En a l g u n o s c a s o s el o p e r a d o r de la m á q u i n a p u e d e d e s e m p e ñ a r t o d o s e s t o s p a p e l e s . En o t r a s s i t u a c i o n e s , s o n p e r s o n a s d i f e r e n t e s las q u e p u e d e n d e s e m p e ñ a r el p a p e l de c a d a actor. www.rationd. tom/prodocts/ whitepapers/ 1 0 0 6 2 2 . ¡ s p puede

bojoise un excelente documento sobre los casos de uso.

C o m o la o b t e n c i ó n d e r e q u i s i t o s e s u n a actividad evolutiva, n o t o d o s l o s a c t o r e s s e i d e n t i f i c a n d u r a n t e la p r i m e r a i t e r a c i ó n . D u r a n t e é s t a e s p o s i b l e identificar los a c t o r e s p r i m a r i o s 0AC92], m i e n t r a s q u e l o s a c t o r e s s e c u n d a r i o s s e i d e n t i f i c a n c o n f o r m e s e a p r e n d e m á s a c e r c a del s i s t e m a . Los actores primarios

interactúan para

lograr la f u n c i ó n r e q u e r i d a del s i s t e m a y o b t i e n e n el b e n e f i c i o q u e s e e s p e r a de é s t e Ellos t r a b a j a n d e m a n e r a directa y f r e c u e n t e c o n el s o f t w a r e . Los a c t o r e s s e c u n d a rios d a n s o p o r t e al s i s t e m a d e m a n e r a q u e los a c t o r e s p r i m a r i o s p u e d a n h a c e r su trabajo. Ya i d e n t i f i c a d o s l o s a c t o r e s p u e d e n d e s a r r o l l a r s e los c a s o s d e u s o . J a c o b s o n [JAC92] s u g i e r e v a r i a s p r e g u n t a s 1 1 q u e s e d e b e r í a n c o n t e s t a r m e d i a n t e u n c a s o de

? ¿Qué se ™ necesita saber para d e s a rrollar un caso de uso e f i c a z ?

uso. • ¿Quién(es) e s ( s o n ) el(los) actor(es) primario(s)? • ¿Cuáles s o n l a s m e t a s del a c t o r ? • ¿Cuáles s o n l a s c o n d i c i o n e s p r e v i a s q u e d e b e n existir a n t e s d e TM c o m e n z a r la historia? • ¿ C u á l e s s o n l a s t a r e a s o f u n c i o n e s p r i n c i p a l e s q u e realiza el a c t o r ?

PDF Editor

• ¿ C u á l e s e x c e p c i o n e s p o d r í a n c o n s i d e r a r s e m i e n t r a s s e d e s c r i b e la h i s t o r i a ? • ¿ C u á l e s s o n las v a r i a c i o n e s p o s i b l e s e n la i n t e r a c c i ó n del a c t o r ?

11 Las preguntas de Jacobson se han extendido para proporcionar una visión más completa del contenido del caso de uso.

CAPÍTULO 7


175

• ¿Cuál e s la i n f o r m a c i ó n del s i s t e m a q u e el a c t o r adquirirá, p r o d u c i r á o cambiará? • ¿El a c t o r t e n d r á q u e i n f o r m a r al s i s t e m a a c e r c a de c a m b i o s e n el m e d i o ambiente externo? • ¿Cuál e s la i n f o r m a c i ó n q u e el a c t o r d e s e a del s i s t e m a ? • ¿El a c t o r q u i e r e s e r i n f o r m a d o a c e r c a de c a m b i o s i n e s p e r a d o s ? C o m o s e r e c o r d a r á , l o s r e q u i s i t o s b á s i c o s d e HogarSeguro

d e f i n e n t r e s a c t o r e s : el

p r o p i e t a r i o d e l a c a s a (un usuario), u n a d m i n i s t r a d o r d e l a c o n f i g u r a c i ó n ( p r o b a b l e m e n t e la m i s m a p e r s o n a q u e el p r o p i e t a r i o , p e r o e n u n a f u n c i ó n d i f e r e n te), los s e n s o r e s (dispositivos a g r e g a d o s al s i s t e m a ) , y el s u b s i s t e m a d e m o n i t o r e o (la e s t a c i ó n c e n t r a l q u e m o n i t o r e a la f u n c i ó n d e s e g u r i d a d e n el h o g a r d o n d e e s t á i n s t a l a d o HogarSeguro).

P a r a los p r o p ó s i t o s de e s t e e j e m p l o s ó l o s e c o n s i d e r a

al a c t o r p r o p i e t a r i o . Éste i n t e r a c t ú a c o n la f u n c i ó n d e s e g u r i d a d e n el h o g a r e n difer e n t e s f o r m a s m e d i a n t e el u s o el p a n e l d e c o n t r o l d e la a l a r m a o u n a PC: • I n g r e s a u n a c o n t r a s e ñ a p a r a permitir t o d a s l a s d e m á s i n t e r a c c i o n e s . • I n d a g a a c e r c a del e s t a t u s d e u n a z o n a d e s e g u r i d a d . • I n d a g a a c e r c a del e s t a t u s d e u n s e n s o r . • P r e s i o n a el b o t ó n de p á n i c o e n c a s o d e e m e r g e n c i a . • A c t i v a / d e s a c t i v a el s i s t e m a d e s e g u r i d a d . Si s e c o n s i d e r a la s i t u a c i ó n e n la c u a l el p r o p i e t a r i o utiliza el p a n e l d e control, el c a s o d e u s o b á s i c o p a r a la a c t i v a c i ó n del s i s t e m a s e p r e s e n t a d e la s i g u i e n t e m a n e r a : 1 2

HogarSeguro -•

a p e g a d o salida

salida

n i

Ul

max

en c a s a instante

alarma verificar

desviación

fuego

A

O

o

encendido

prueba desviación

instante c ó d i g o

n o listo

activado

en c a s a

uJ 0 0 CU CD CD

-y.; '

0

0 listo

000 '

p a n ico

'

TM

PDF Editor

12 Nótese que este caso de uso difiere de la situación en la cual se entra en el sistema a través de Internet. En este caso, la interacción se lleva a cabo por medio del panel de control, el acceso es diferente que cuando se utiliza una PC.

176

PARTE D O S


1. El propietario observa el panel de control de HogarSeguro (figura 7.2) para determinar si el sistema está listo para entrar. Si el sistema no está listo se despliega un mensaje de no listo sobre la pantalla LCD, y el propietario debe cerrar en forma física puertas y ventanas para que el mensaje desaparezca. (Un mensaje de no listo implica que un sensor se encuentra abierto; es decir, que una puerta o ventana está abierta.) 2

El propietario utiliza el teclado para introducir una contraseña de cuatro dígitos. La contraseña se compara con la clave almacenada en el sistema. Si la contraseña es incorrecta, el panel de control emitirá un sonido y se reiniciará para recibir otra entrada. Si la contraseña es correcta, el panel de control esperará la siguiente acción.

3.

El propietario selecciona e introduce en casa o salida (véase la figura 7.2) para activar el sistema. En casa activa sólo los sensores del perímetro (los sensores para la detección de movimiento interno se desactivan). Salida activa todos los sensores.

4. Cuando se realiza la activación, el propietario puede observar una luz roja de alarma. El c a s o d e u s o b á s i c o p r e s e n t a u n a historia d e a l t o nivel q u e d e s c r i b e la i n t e r a c c i ó n e n t r e el a c t o r y el s i s t e m a . En m u c h a s o c a s i o n e s , los c a s o s de u s o t i e n e n u n a m a y o r e l a b o r a c i ó n p a r a prop o r c i o n a r m á s d e t a l l e s a c e r c a de la i n t e r a c c i ó n . Por e j e m p l o , C o c k b u r n [COCOi; s u g i e r e la s i g u i e n t e plantilla p a r a las d e s c r i p c i o n e s d e t a l l a d a s d e l o s c a s o s d e u s o Caso de uso:

Inicio de monitoreo

^ O N S E J O ^

Actor primario:

Propietario de la casa.

Con frecuencia, los osos de uso se escriben de manera informal. Sin embaigo, se recomienda el uso de lo plantilla mostrada oqul pora aseguro: que se consideren todos los aspedos clave.

Meta en el contexto:

Establecer el sistema para monitorear los sensores cuando el propietario salga de la casa o permanezca dentro ella.

Condiciones previas:

El sistema ha sido programado para una contraseña y reconocer diferentes sensores.

Activador:

El propietario decide "iniciar" el sistema, es decir, encender las funciones de alarma.

Escenario: 1. Propietario: observa el panel de control. 2. Propietario: introduce la contraseña. 3. Propietario: selecciona "en casa" o "salida". 4. Propietario: observa la luz roja de alarma para indicar que HogarSeguro está en operación. Excepciones:

TM para deter1. El panel de control no está listo: el propietario verifica todos los sensores minar cuáles están abiertos; los cierra. 2. La contraseña es incorrecta (el panel de control emite un sonido): el propietario introduce de nuevo la contraseña correcta.

PDF Editor

3. La contraseña no es reconocida: debe contactarse el subsistema de monitoreo y respuesta para reprogramar la contraseña. 4. Se selecciona en casa: el panel de control emite un sonido doble y se enciende la luz de en casa; se activan los sensores del perímetro.

CAPÍTULO 7

177


5. Se selecciona salida: el panel de control emite un sonido triple y se enciende la luz de salida; se activan todos los sensores. Prioridad:

Esencial, debe implementarse.

Disponible desde:

El primer incremento.

Frecuencia de uso:

Muchas veces al día.

Canal hacia el actor:

A través de la interfaz del panel de control.

Actores secundarios:

Técnicos de soporte, sensores.

Canales hacia los actores secundarios: Técnico de soporte: línea telefónica. Sensores: interfaces alámbricas e inalámbricas. Asuntos pendientes: 1. ¿Debería haber una forma de activar el sistema sin el uso de una contraseña o con una clave abreviada? 2. ¿El panel de control debería desplegar otros mensajes de texto?

\

3. ¿De cuánto tiempo dispone el propietario para introducir la contraseña desde el momento en que presiona la primera tecla?

CLAVE ¡ rteresodos pueden r codo caso de 11 signarle su i relativa.

4. ¿Existe alguna forma de desactivar el sistema antes de que éste se active en realidad? Los c a s o s d e u s o p a r a l a s o t r a s i n t e r a c c i o n e s del p r o p i e t a r i o s e d e s a r r o l l a r í a n de u n a m a n e r a similar. E s i m p o r t a n t e s e ñ a l a r q u e c a d a c a s o d e u s o d e b e r e v i s a r s e c o n c u i d a d o . Si a l g ú n e l e m e n t o d e la i n t e r a c c i ó n e s a m b i g u o , existe la posibilidad d e q u e u n a revisión del c a s o d e u s o d e s c u b r a el p r o b l e m a .

HOGARSEGURO

Desarrollo de un diagrama

de alto nivel para un caso de uso

El e s c e n a r i o : Una sala de

J a m i e : A p e n a s estoy comenzando a a p r e n d e r la

nes. Continúa la reunión p a r a la recopilación d e requisitos.

notación del UML. Entonces, ¿la función d e seguridad en

Los a c t o r e s : Jamie Lazar, miembro del equipo d e

el h o g a r b representa la c a j a g r a n d e con los óvalos en su interior? ¿Y los ó v a b s representan b s casos d e uso

software; Vinod Raman, miembro del equipo d e software;

que escribimos en texto?

zz Robbins, miembro del equipo d e software; Doug

M o d e r a d o r : Sí. Y las figuras p e g a d a s representan actores; es decir, las personas o cosas q u e interactúan

ir, miembro del equipo d e software; tres miembros d e - e - c a d o t e c n i a ; un representante d e ¡ngeniería del rroducto; y un moderador.

y utilicé el cuadro etiquetado p a r a representar un actor

l a conversación:

q u e no e s una persona, en este caso son sensores.

a r a d o r : Hemos invertido bastante tiempo i acerca d e la función d e seguridad en el hogar l HogarSeguro. Durante el descanso dibujé un

con ei sistema según se describe en el caso d e uso... a h ,

D o u g : ¿Eso es legal en el UML?

TM

M o d e r a d o r : Lo legalidad no es el punto. Lo importante es comunicar b información. Yo pienso que el uso de una

PDF Editor i o g r a m a d e caso d e uso para resumir b s escenarios

s que son parte de esta función. Denle un vistazo,

i los asistentes ven la figura 7.3)

figura que parece una persona pero q u e representa un

dispositivo puede confundirnos. Entonces he a d a p t a d o un poco b s cosas. N o creo q u e esto represente un problema.

PARTE D O S

178


V i n o d : De a c u e r d o , e n t o n c e s t e n e m o s narrativos d e

P e r s o n a d e m e r c a d o t e c n i a : Esperen, h e e s t a d o

c a s o s d e uso p a r a c a d a u n o d e los óvalos. ¿ N e c e s i t a m o s

v i e n d o este d i a g r a m a , y d e r e p e n t e m e di c u e n t a q u e

desarrollar narrativas m á s detalladas con base en

hemos olvidado algo.

plantillas? H e leído a c e r c a d e ellas. M o d e r a d o r : Probablemente, pero eso puede esperar hasta q u e h a y a m o s considerado otras funciones de

M o d e r a d o r : ¿De v e r d a d ? ¿ Q u é e s lo q u e o l v i d a m o s ? (La reunión continúa)

HogarSeguro.

Diagrama de

desactiva sistema

caso de uso para la función de seguridad en

Entra en el sistema por . Internet .

lietario j casa

el h o g a r d e HogarSeguro.

Responde c evento d e v alarma^ '

Encuentra una condick V d e error Administrador del sistema

sensores y tas características del sistema


Desarrollo de casos de uso O b j e t i v o : A y u d a e n el desarrollo d e c a s o s d e

•

uso al p r o p o r c i o n a r plantillas q u e sólo requieren el l l e n a d o d e e s p a c i o s e n b l a n c o , p a r a a s í c r e a r c a s o s d e uso e f i c a c e s . La m a y o r í a d e las f u n c i o n a l i d a d e s p a r a los c a s o s d e uso e s t á n incluidas en un conjunto d e f u n c i o n e s m á s a m p l i o p a r a la ingeniería d e requisitos. Herramientas representativas'3 Clear Requirement

Workbench,

d e s a r r o l l a d o p o r LiveSpecs

S o f t w a r e (www.livespecs.com), p r o p o r c i o n a s o p o r t e a u t o m a t i z a d o p a r a la c r e a c i ó n y e v a l u a c i ó n d e c a s o s

La v a s t a m a y o r í a d e las h e r r a m i e n t a s p a r a el m o d e l a d o del análisis, b a s a d a s e n UML, p r o p o r c i o n a n s o p o r t e g r á f i c o y e n texto p a r a el d e s a r r o l l o y m o d e l a d o d e c a s o s d e uso. Objects

by Design,

u n a fuente p a r a h e r r a m i e n t a s d e UML

(www.objectsbydesign.com/tools/umltools_byCompany html) p r o p o r c i o n a vínculos completos p a r a c o n o c e r h e r r a m i e n t a s d e este tipo.

TM

En U s e C a s e s . o r g ( w w w . u s e c a s e s . o r g ) se p u e d e e n c o n t r a r u n a v a r i e d a d d e plantillas p a r a d e s a r r o l l a r c a s o s d e

PDF Editor d e uso, a s í c o m o u n a v a r i e d a d d e o t r a s f u n c i o n e s p a r a

.

u s o , así c o m o u n a b a s e d e d a t o s p a r a soportarlos.

la ingeniería d e requisitos.

13 L a s h e r r a m i e n t a s m e n c i o n a d a s a q u í s o n u n a m u e s t r a d e e s t a c a t e g o r í a . En la m a y o r í a d e los c a s o s los n o m b r e s e s t á n r e g i s t r a d o s p o r s u s r e s p e c t i v o s d e s a r r o l l a d o r e s .

CAPÍTULO 7


IQDELQ

179

DE

ANÁLISIS

El objetivo del m o d e l o d e análisis e s describir los d o m i n i o s r e q u e r i d o s d e información, f u n c i o n a m i e n t o y c o m p o r t a m i e n t o p a r a un sistema b a s a d o en c o m p u t a d o r a s . El m o d e l o c a m b i a en f o r m a dinámic a c o n f o r m e los i n g e n i e r o s d e s o f t w a r e a p r e n d e n m á s a c e r c a del s i s t e m a que se va a construir y los i n t e r e s a d o s e n t i e n d e n m e j o r lo que n e c e s i t a n . Por e s t a r a z ó n el m o d e l o de análisis e s u n a r e p r e s e n t a c i ó n d e los requisitos en un m o m e n t o d e t e r m i n a d o , por lo q u e s e e s p e r a q u e é s t e c a m b i e . Conforme el m o d e l o d e análisis evoluciona, ciertos e l e m e n t o s s e volverán relativam e n t e estables, por lo q u e proporcionarán u n a b a s e sólida para las t a r e a s d e d i s e ñ o q u e siguen. Sin e m b a r g o , otros e l e m e n t o s del modelo p u e d e n ser m á s volátiles, lo q u e indicará que el cliente a ú n n o entiende por completo los requisitos para el sistema. El m o d e l o d e análisis y los m é t o d o s utilizados para construirlo s e describen c o n detalle e n el capítulo 8. En las s e c c i o n e s siguientes s e p r e s e n t a u n a breve visión general.

7.6.1 Elementos del modelo de análisis Existen m u c h a s m a n e r a s de b u s c a r los requisitos p a r a u n sistema b a s a d o en c o m p u t a d o r a . Algunas p e r s o n a s involucradas con el s o f t w a r e dicen q u e lo m e j o r e s selecc i o n a r un m o d o d e r e p r e s e n t a c i ó n (por ejemplo, el c a s o d e uso) y aplicarlo sin t o m a r e n c u e n t a t o d o s los m o d o s r e s t a n t e s . Otros p r o f e s i o n a l e s c r e e n q u e resulta valioso utilizar varios m o d o s d e r e p r e s e n t a c i ó n p a r a m o s t r a r el m o d e l o d e análisis. Las difer e n t e s f o r m a s d e r e p r e s e n t a c i ó n obligan al equipo de s o f t w a r e a c o n s i d e r a r los requisitos d e s d e distintos p u n t o s de vista, u n e n f o q u e que tiene m a y o r e s probabilid a d e s de descubrir omisiones, inconsistencias y a m b i g ü e d a d e s . Los e l e m e n t o s específicos del m o d e l o de análisis los d e t e r m i n a el m é t o d o d e m o d e l a d o q u e s e utilice (capítulo 8). Sin e m b a r g o , existe un c o n j u n t o d e e l e m e n t o s genéricos c o m ú n a la mayoría d e ios m o d e l o s d e análisis: Elementos basados en escenarios. ^CONSEJO^

El s i s t e m a s e describe, d e s d e el p u n t o de

vista del u s u a r i o , por m e d i o de u n e n f o q u e b a s a d o e n escenarios. Por e j e m p l o , los c a s o s de u s o b á s i c o s y s u s c o r r e s p o n d i e n t e s d i a g r a m a s d e c a s o d e u s o (figura 7.3)

.ienpre es una buena

e v o l u c i o n a n p a r a convertirse en c a s o s d e u s o m á s e l a b o r a d o s b a s a d o s e n plantillas.

oec involucrar o los

Los e l e m e n t o s del m o d e l o de análisis b a s a d o s e n e s c e n a r i o s c o n frecuencia s o n los

naesados.

p r i m e r o s que s e desarrollan d u r a n t e la elaboración del modelo. Por tal motivo, sir-

Una de

te mejores formas de facerlo es pedirle a a¡áa uno que elabore

v e n c o m o u n a e n t r a d a p a r a la creación d e o t r o s e l e m e n t o s d e m o d e l a d o . TM Un e n f o q u e a l g o diferente d e n t r o del m o d e l a d o b a s a d o en e s c e n a r i o s m u e s t r a las

osos de uso que xsaibon la formo en

actividades o f u n c i o n e s q u e h a n s i d o definidas c o m o p a r t e de la tarea de o b t e n c i ó n

pe se utilizará el

es, la s e c u e n c i a d e actividades (también se p u e d e n utilizar los t é r m i n o s f u n c i o n e s u

PDF Editor software.

d e requisitos. Estas f u n c i o n e s existen d e n t r o d e un c o n t e x t o d e p r o c e s a m i e n t o . Esto o p e r a c i o n e s ) q u e describe el p r o c e s a m i e n t o d e n t r o d e un c o n t e x t o limitado s e defin e c o m o p a r t e del m o d e l o d e análisis. C o m o la mayoría d e los e l e m e n t o s del m o d e

lo d e análisis (y o t r o s m o d e l o s d e la ingeniería d e software), las actividades (funcio

180

PARTE DOS


nes) s e p u e d e n r e p r e s e n t a r e n m u c h o s g r a d o s d i f e r e n t e s d e a b s t r a c c i ó n . Los m o d e los e n e s t a c a t e g o r í a p u e d e n d e f i n i r s e de m a n e r a iterativa. C a d a iteración p r o p o r c i o n a d e t a l l e s a d i c i o n a l e s del p r o c e s a m i e n t o . C o m o u n e j e m p l o , en la figura 7.4 s e p r e s e n t a u n d i a g r a m a d e actividad e n UML p a r a la o b t e n c i ó n d e requisitos. 1 4 Se m u e s t r a n tres niveles de elaboración.

Diagramas de actividad para la obtención de documentos.

i

¿Priorización formal? No

u|ar di. del caso

( Completar j la plantilla J

Diagrama de c l a s e p a r a el Sensor.

X Definir actores

I

Escribir el escenario

Crear casos d e uso

)

Sensor nombre/id tipo ubicación área característicos

TM

identificar! ] activar!) desactivorj) reconfígurar()

PDF Editor

14 El diagrama de actividad es bastante parecido al diagrama de flujo: un diagrama gráfico para representar las secuencias y lógica del flujo de control (capítulo 11).

CAPÍTULO 7

de aislar es buscar desaip-


181

Elementos basados en clases.

C a d a e s c e n a r i o d e u s o implica u n c o n j u n t o d e

" o b j e t o s " q u e s e m a n i p u l a m i e n t r a s u n a c t o r i n t e r a c t ú a c o n el s i s t e m a . Esto s o b j e t o s s e clasifican e n c l a s e s : u n a c o l e c c i ó n d e c l a s e s c o n a t r i b u t o s s i m i l a r e s y c o m p o r t a m i e n t o s e n c o m ú n . Por e j e m p l o , s e p u e d e u s a r u n d i a g r a m a d e c l a s e p a r a m o s t r a r

éesaitode

u n a c l a s e d e S e n s o r p a r a la f u n c i ó n de s e g u r i d a d d e HogarSeguro

x uso. Al

O b s é r v e s e q u e el d i a g r a m a lista l o s a t r i b u t o s d e los s e n s o r e s (por e j e m p l o , nombre/¡d,

sde

tipo) y l a s o p e r a c i o n e s [por e j e m p l o , identificar(

), habilitar()\

(figura 7.5).

que p u e d e n aplicarse

p a r a m o d i f i c a r d i c h o s a t r i b u t o s . A d e m á s d e los d i a g r a m a s d e c l a s e , o t r o s e l e m e n t o s ¿recapitulo encontrar este tema.

del m o d e l a d o del a n á l i s i s m u e s t r a n la f o r m a e n q u e las c l a s e s c o l a b o r a n c o n u n o y o t r o y las r e l a c i o n e s e i n t e r a c c i o n e s e n t r e l a s c l a s e s . Lo a n t e r i o r s e e x a m i n a c o n m a y o r d e t a l l e e n el c a p í t u l o 8. Elementos de comportamiento.

El c o m p o r t a m i e n t o d e u n s i s t e m a b a s a d o e n

c o m p u t a d o r a p u e d e t e n e r u n p r o f u n d o e f e c t o s o b r e el d i s e ñ o q u e s e elija, a s í c o m o e n el e n f o q u e d e i m p l e m e n t a c i ó n q u e s e a p l i q u e . Por lo t a n t o , el m o d e l o d e a n á l i s i s d e b e p r o p o r c i o n a r e l e m e n t o s d e m o d e l a d o q u e m u e s t r e n el c o m p o r t a m i e n t o . El d i a g r a m a d e e s t a d o (capítulo 8) e s u n m é t o d o p a r a r e p r e s e n t a r el c o m p o r t a m i e n t o de un s i s t e m a al m o s t r a r s u s e s t a d o s y los e v e n t o s q u e o c a s i o n a n q u e d i c h o

CLAVE es uno

s i s t e m a c a m b i e d e e s t a d o . Un e s t a d o e s c u a l q u i e r f o r m a de c o m p o r t a m i e n t o o b s e r v a b l e . A d e m á s , el d i a g r a m a d e e s t a d o indica l a s a c c i o n e s (por e j e m p l o , la a c t i v a c i ó n del p r o c e s o ) q u e s e t o m a n c o m o c o n s e c u e n c i a d e u n e v e n t o particular. P a r a ilustrar un diagrama

de manera los estímulos ocosionon los entre los

d e e s t a d o , c o n s i d é r e s e el e s t a d o d e l e c t u r a d e c o m a n -

d o s de u n a f o t o c o p i a d o r a d e oficina. En la figura 7.6 s e p r e s e n t a el d i a g r a m a de e s t a d o c o r r e s p o n d i e n t e e n UML. Un r e c t á n g u l o r e d o n d e a d o r e p r e s e n t a u n e s t a d o . El r e c t á n g u l o s e divide e n t r e s á r e a s : 1) el n o m b r e del e s t a d o (por e j e m p l o , Lectura d e c o m a n d o s ) , 2) las variables

de estado

q u e i n d i c a n la m a n e r a e n q u e el e s t a d o s e

Lectura de comandos

5 en paiael de

N o m b r e del e s t a d o

Estatus del sistema = "Listo" ^ Mensaje desplegado = "introducir cmd"

"Variables d e e s t a d o

Display status - steady Estatus d e s p l e g a d o - e s t a b l e . Entrada/subsistemas listo Acción: pedir la e n t r a d a del

TM Actividades d e e s t a d o

PDF Editor usuario en el panel

Acción: leer la e n t r a d a del

Acción: interpretar la e n t r a d a

\

del usuario

PARTE DOS


HOGARSEGURO

Modelado preliminar del comportamiento LSJgl

El e s c e n a r i o : Una salo d e

P e r s o n a d e m e r c a d o t e c n i a : Esto parece un p o c o

reuniones. Continúa lo reunión p a r o la recopilación d e requisitos.

técnico, no sé si yo p u e d a a y u d a r en esta parte. M o d e r a d o r : Seguro q u e puedes. ¿Cuál es el

Los a c t o r e s : jamie Lazar, miembro del equipo d e

comportamiento q u e observas desde el punto d e vista de:

software; Vinod Raman, miembro del equipo d e

usuario?

software; £d Robbins, miembro del equipo d e software; Doug Miüer, miembro del equipo d e software; tres miembros d e mercadotecnia; un representante d e ingeniería del producto; y un moderador.

comandos del propietario d e la c a s a. Desplegará su estatus.

La c o n v e r s a c i ó n : M o d e r a d o r : Estamos a punto d e terminar d e hablar acerca d e la funcionalidad d e seguridad en el hogar d e HogarSeguro.

P e r s o n a d e m e r c a d o t e c n i a : Eh. . bueno, el sistema estará monitoreando los sensores, estará leyendo

Pero antes d e hacerlo, me gustaría discutir

M o d e r a d o r : Ves, tú puedes hacerlo. J a m i e : También revisará la PC p a r a determinar si existe alguna entrada desde ahí, por ejemplo: un acceso

el comportamiento d e la función.

b a s a d o en Internet o información d e configuración.

P e r s o n a d e m e r c a d o t e c n i a : Yo no entiendo lo q u e

V i n o d : Sí, d e hecho, la configuración del sistema es un

quieres decir con comportamiento.

estado por derecho propio.

Ed ( r i e n d o ) : Es c u a n d o le d a s al producto un "tiempo

D o u g : Me p a r e c e q u e van muy rápido. Vamos a

fuero" si se comporta mal.

pensarlo un poco más... ¿Existe alguna forma d e hacer

M o d e r a d o r : N o exactamente. Déjenme explicarles. (El

un d i a g r a m a d e esto?

moderador les explica al equipo d e recopilación d e requisitos los conceptos básicos del modelado del

M o d e r a d o r : Sí existe, pero vamos a posponerlo para después d e la reunión.

comportamiento.)

manifiesta a sí m i s m o en el m u n d o exterior, y 3) las actividades de estado que ind;-l c a n la f o r m a en que s e ingresa al e s t a d o (entrada/) y las a c c i o n e s (do:) invocadas! m i e n t r a s s e p e r m a n e c e en el m i s m o . E l e m e n t o s o r i e n t a d o s al

flujo.

C u a n d o la información fluye a través d e un sis-l

t e m a b a s a d o en c o m p u t a d o r a , é s t a s e t r a n s f o r m a . El s i s t e m a a c e p t a la e n t r a d a e a l u n a variedad de f o r m a s , aplica f u n c i o n e s p a r a transformarla y p r o d u c e u n a salicíl t a m b i é n en f o r m a s diferentes. La e n t r a d a p u e d e ser u n a señal d e control q u e traní-l mite un transductor, u n a serie de n ú m e r o s q u e teclea un o p e r a d o r h u m a n o , u - | p a q u e t e d e información transmitido a través d e u n a liga de red, TM o un voluminos-J archivo d e d a t o s o b t e n i d o d e u n a l m a c e n a m i e n t o secundario. La transformacié-.l p u e d e incluir u n a sola c o m p a r a c i ó n lógica, un algoritmo n u m é r i c o c o m p l e j o o un

PDF Editor

e n f o q u e d e interferencia d e reglas p e r t e n e c i e n t e a un s i s t e m a experto. La salical p u e d e e n c e n d e r u n a sola luz de LED o producir un reporte de 200 páginas. En efec-l to, e s posible c r e a r un m o d e l o d e flujo p a r a c u a l q u i e r s i s t e m a b a s a d o en compu-l tadora, sin importar su t a m a ñ o o complejidad. En el capítulo 8 s e p r e s e n t a u n a expc-l sición m á s detallada del m o d e l a d o del flujo.

CAPITULO 7

183


7.6.2 Patrones d e análisis C u a l q u i e r a q u e lleve a c a b o i n g e n i e r í a de r e q u i s i t o s e n m á s de u n o s c u a n t o s p r o y e c t o s de s o f t w a r e c o m i e n z a a d a r s e c u e n t a q u e c i e r t a s c o s a s s u c e d e n d e m a n e r a recurrente en t o d o s los proyectos dentro de un dominio de aplicación específico.15 É sto s p u e d e n d e n o m i n a r s e patrones

de análisis

[FOW97] y r e p r e s e n t a n a l g o (por

e j e m p l o , u n a c l a s e , u n a f u n c i ó n o u n c o m p o r t a m i e n t o ) d e n t r o del d o m i n i o d e aplic a c i ó n q u e p u e d e r e u t i l i z a r s e al m o d e l a r m u c h a s a p l i c a c i o n e s . Geyer-Shultz y H a h s l e r |GEY01] s u g i e r e n d o s b e n e f i c i o s q u e p u e d e n a s o c i a r s e c o n el u s o de p a t r o n e s de análisis: Primero, los patrones de análisis aceleran el desarrollo de modelos de análisis abstractos que capturan los requisitos principales del problema concreto al proporcionar modelos reutilizables del análisis, los cuales incluyen ejemplos, asi como una descripción de las ventajas y limitaciones. Segundo, los patrones de análisis facilitan la transformación del modelo de análisis en un modelo de diseño al sugerir patrones de diseño y soluciones confiables para problemas comunes. Los p a t r o n e s d e a n á l i s i s se i n t e g r a n al m o d e l o r e s p e c t i v o m e d i a n t e u n a r e f e r e n cia al n o m b r e del p a t r ó n . És t o s t a m b i é n s e e n c u e n t r a n a l m a c e n a d o s e n u n d e p ó s i t o p a r a q u e los i n g e n i e r o s de r e q u i s i t o s p u e d a n utilizar los servicios d e b ú s q u e d a y así e n c o n t r a r l o s y reutilizarlos. La i n f o r m a c i ó n a c e r c a d e u n p a t r ó n de a n á l i s i s s e p r e s e n t a e n u n a plantilla e s t á n -

/

d a r q u e t i e n e la s i g u i e n t e forma[GEY01]: 1 6

se puede

Nombre del patrón: un descriptor que captura la esencia del patrón. El descriptor se itfy

utiliza dentro del modelo de análisis cuando se hace alguna referencia al patrón

s recursos i s potrones.

Intención: describe aquello que el patrón pretende lograr o representar o el problema que ataca dentro del contexto de un dominio de aplicación Motivación: un escenario que ilustra la forma en que el patrón se puede utilizar para atacar el problema.

A

¿Existe algu-

Fuerzas y contexto: una descripción de los aspectos externos (fuerzas externas) ca-

i plantilla

paces de afectar la manera en que se utiliza el patrón, asi como de los asuntos externos

i para

que serán resueltos cuando se aplique el patrón. Los aspectos externos pueden incluir

• patro-

cuestiones relacionadas con los negocios, restricciones técnicas externas, y asuntos relacionados con las personas Solución: una descripción de la forma en que se aplica el patrón para resolver el problema, poniendo especial atención en los aspectos estructurales y de comportamiento.

TM Consecuencias: se enfoca en lo que sucede cuando se aplica el patrón y en los cambios que se producen durante su aplicación.

PDF Editor

15 En algunas situaciones las cosas se repiten sin importar el dominio de aplicación. Por ejemplo, las características y funciones de las interfases del usuario son comunes, independientemente del dominio de aplicación que se considere. 16 En la bibliografía se ha propuesto una variedad de plantillas de patrón. Los lectores interesados pue den consultar [FOW97], IBUS96) y (GAM95), entre muchas otras fuentes.

lili

194

PARTE D O S


Diseño: examina la manera en que el patrón de análisis se puede lograr por medio de patrones de diseño conocidos. Usos conocidos: ejemplos de usos en sistemas reales. Patrones relacionados: uno o más patrones de análisis que están relacionados con el patrón en cuestión, porque el patrón de análisis 1) por lo general se utiliza junto con el patrón en estudio, 2) es similar en el sentido estructural a dicho patrón, 3) es una variación del mismo. En el c a p í t u l o 8 s e p r e s e n t a n e j e m p l o s d e p a t r o n e s de análisis, así c o m o o t r o s análisis d e e s t e tópico. INFORMACIÓN

Patrones Los patrones se pueden ver en casi cualquier

perfil cómico, o puede usarse en un papel más malévolo para

actividad d e la vida diaria. Considérense las películas d e acción y aventuras - d e

poner trabas burocráticas o intereses personales en el camino

manera más específica las películas policiacas de acción y

del HéroeyCompañero. dramático.

aventuras con matices d e c o m e d i a - . Se pueden definir patrones p a r a el HéroeyCompañero, CapilánJefedelHéroe,

Para un ejemplo algo más técnico considérese un teléfono celular. Los siguientes patrones son obvios: Llamar,

CriminalconCorazón y muchos más.

BuscorNúmero,

Por ejemplo, el CapitárJefedelHéroe de manera invariable es más viejo, usa corbata (el héroe no), les grita en forma

uno d e estos patrones puede describirse una vez y después

constante al HéroeyCompañero,

Se ha establecido un patrón

VerMensajes entre muchos otros. C a d a

reutilizarse en el software p a r a cualquier teléfono celular.

usualmente es quien da el

En u n c o n t e x t o ideal de la i n g e n i e r í a d e r e q u i s i t o s , l a s t a r e a s d e inicio, o b t e n c i ó n y e l a b o r a c i ó n d e t e r m i n a n l o s r e q u i s i t o s c o n el s u f i c i e n t e d e t a l l e c o m o p a r a e m p r e n der los p a s o s s u b s e c u e n t e s de la i n g e n i e r í a del s o f t w a r e . D e s g r a c i a d a m e n t e , e s t o s u c e d e m u y r a r a v e z . En r e a l i d a d , el cliente y el d e s a r r o l l a d o r e n t r a n e n u n p r o c e s o d e negociación,

e n el c u a l se le d e b e p e d i r al cliente u n b a l a n c e de la f u n c i o n a l i d a d ,

el r e n d i m i e n t o y o t r a s c a r a c t e r í s t i c a s del s i s t e m a o p r o d u c t o f r e n t e al c o s t o y el tiemp o de c o l o c a c i ó n e n el m e r c a d o . El o b j e t i v o d e e s t a n e g o c i a c i ó n e s d e s a r r o l l a r un p l a n d e p r o y e c t o q u e s a t i s f a g a las n e c e s i d a d e s del cliente al m i s m o t i e m p o q u e refleja las r e s t r i c c i o n e s del m u n d o real (por e j e m p l o , t i e m p o , g e n t e , p r e s u p u e s t o ) a las q u e e s t á s o m e t i d o el e q u i p o de s o f t w a r e . "Un ocuerdo es d orte de dividir un postel de tal formo que codo uno piense que se quedó con la rebanada más grande."

TM

Ludwig Erhard

Las m e j o r e s n e g o c i a c i o n e s s o n a q u e l l a s q u e b u s c a n u n r e s u l t a d o del tipo " g a n a r -

PDF Editor

ganar". 1 7 Esto e s , el cl i ente g a n a al o b t e n e r el s i s t e m a o p r o d u c t o q u e s a t i s f a c e la 17 Se han escrito docenas de libros sobre las aptitudes para la negociación (por ejemplo, [LEWOO], [FAR97], (DON96)) Ésta es una de las competencias más importantes que un ingeniero o gerente de software joven (o no tan joveni puede aprender. Se recomienda leer al menos uno de los libros mencionados.

CAPITULO 7


185

mayoría de s u s n e c e s i d a d e s , y el equipo d e s o f t w a r e g a n a al trabajar c o n presup u e s t o s y límites d e tiempo realistas y alcanzables. B o h e m [BOE98] define un c o n j u n t o de actividades d e n e g o c i a c i ó n en el inicio de c a d a iteración del p r o c e s o del s o f t w a r e . En lugar de la actividad sencilla d e comuni c a c i ó n c o n el cliente, s e definen las siguientes actividades: 1. Identificación d e los i n t e r e s a d o s clave en el s i s t e m a o s u b s i s t e m a .

puede

2.

Determinación d e las "condiciones g a n a d o r a s " d e los interesados.

3.

Negociación d e las c o n d i c i o n e s g a n a d o r a s d e los i n t e r e s a d o s p a r a reconciliarlas e n c o n j u n t o d e c o n d i c i o n e s del tipo g a n a r - g a n a r p a r a t o d o s los involucrad o s (incluido el e q u i p o d e software).

La conclusión exitosa d e e s t o s p a s o s iniciales a s e g u r a un resultado del tipo g a n a r g a n a r , el cual s e convierte en el criterio clave p a r a c o n t i n u a r c o n las actividades s u b s e c u e n t e s d e la ingeniería del s o f t w a r e . INFORMACIÓN

El arte de Ja negociación El aprendizaje del arte d e la negociación

hablando. Es necesario escuchar. Es posible q u e se

efectiva es una actividad que sirve a través d e

obtenga un conocimiento que a y u d a r á a negociar de mejor manera la posición propia.

técnica y personal. La consideración d e las : directrices p u e d e resultar muy valiosa: •econocer que no es uno competencia.

4.

Para ser

exitoso, a m b o s lados deben tener el sentimiento d e

posición inflexible.

naber g a n a d o o logrado algo. Las d o s partes •endrán que llegar a un acuerdo. Diseñar una estrategia.

Enfocarse en los intereses de la otra parte. Si se quieren evitar los conflictos no se d e b e tomar una

Decidir que es lo que se

desearía lograr; qué es lo que la otra parte quiere

5.

No dejar que se vuelva personal. Enfocarse en el problema que d e b e ser resuello.

6.

Ser creativo. C u a n d o existen situaciones d e estancamiento no se d e b e tener miedo d e pensar

alcanzar, y q u é es lo que se va a hacer p a r a q u e

fuera d e los cánones.

a m b a s cosas sucedan.

7.

Escuchar de manera activa. No se d e b e pensar en

Estar listo para pactar. Una vez que se ha llegado a un acuerdo, no es necesario esperar: se d e b e pactar dicho convenio y seguir adelanto.

formular una respuesta mientras la otra parte está

HOGARSEGURO

El inicio de una negociación El e s c e n a r i o : Oficina d e Lisa , después d e la primera reunión p a r a la i d e requisitos. - o s a c t o r e s : Doug Miller, gerente d e ingeniería d e

D o u g : En realidad sí. Enviaste algunos buenos

TM elementos a la reunión... contribuyeron bastante. Lisa ( s o n r i e n d o ) : Sí d a r o , ellos me dijeron que llegaron y que no fue una actividad muy tranquila que digamos.

PDF Editor «aftware y Lisa Pérez, gerente d e mercadotecnia. Le c o n v e r s a c i ó n :

D o u g ( r i e n d o ) : Me aseguraré d e quitarme la gorra d e técnico la próxima vez que fe visite... Mira, Lisa, yo creo

L i s a : Bien, escuché q u e en la primera reunión no les fue

que podemos tener un problema en terminar t o d a s fas

o u y bien.

funcionalidades p a r a la función d e seguridad en eí h o g a r

PARTE DOS


p a r o las fechas d e las que está h a b l a n d o tu gerencia. Es

sitio W e b completamente seguro, ya construido y en

muy pront< yo lo sé, pero ya he estado haciendo un

funcionamiento. Para eso se necesita tiempo y gente.

p e q u e ñ o respaldo d e la planeación y...

También tendremos q u e construir funcionalidades

Lisa: Debemos tenerlo paro e s a fecha, Doug. ¿De cuál

adicionales en la primera entrega... no creo que lo

funcionalidad estás hablando?

podamos hacer con los recursos q u e tenemos a hora.

D o u g : Me p a r e c e q u e podemos sacar toda la función

Lisa (frunciendo el ceño): Ya veo, pero debes

d e seguridad en el h o g a r p a r a la fecha límite, pero

encontrar una forma d e hacerlo. Es crucial p a r a las

tendremos q u e retrasar el acceso por Internet hasta la

funciones d e seguridad en el h o g a r y p a r a las otras funciones también... las otras funciones pueden esperar

segunda entrega. l i s a : Doug, el acceso por Internet es lo q u e d a a HogarSeguro

la calidad d e "novedoso". Vamos a

hasta las siguientes entregas,

Lisa y Doug parecen estar en un callejón sin salida, y

construir toda nuestra c a m p a ñ a d e mercadotecnia alrededor d e esto. ¡Debemos tenerlo! D o u g : Entiendo tu situación, d e verdad. El problema es q u e p a r a darte acceso a Internet necesitaremos tener un

7 . 8

VALIDACIÓN

DE

estaré d e acuerdo con

eso. aún así deben negociar una solución a este problema. Er esta situación, ¿pueden "ganar" los dos? En el papel de un mediador, ¿cuál sería una sugerencia a p r o p i a d a ?

REQUISITOS

Al crear c a d a e l e m e n t o del m o d e l o d e análisis, é s t e s e e x a m i n a p a r a c o n o c e r su c ? n l sistencia, s u s o m i s i o n e s y a m b i g ü e d a d e s . A los requisitos q u e r e p r e s e n t a el m o d e J el cliente les da jerarquía y s e a g r u p a n e n p a q u e t e s de requisitos q u e s e i m p l e m e r J tan c o m o i n c r e m e n t o s de s o f t w a r e y s e le e n t r e g a n . Una revisión del m o d e l o de a n a l lisis se e n f o c a en las siguientes p r e g u n t a s : Q

Cuandoi i se

• revisan los requisitos, ¿cuáles preguntas deben hacerse?

¿Cada requisito e s c o n s i s t e n t e c o n el objetivo general del s i s t e m a / p r o d u c t o ' ¿Todos los requisitos h a n sido especificados c o n el g r a d o a p r o p i a d o d e abstracción? Esto es, ¿algunos requisitos p r o p o r c i o n a n un g r a d o d e detalle técnico q u e s e a inapropiado en esta etapa? ¿El requisito e s n e c e s a r i o en realidad o r e p r e s e n t a u n a característica a g r e g a d a irrelevante p a r a el objetivo del s i s t e m a ? ¿Cada requisito está limitado y n o e s a m b i g u o ? ¿Cada requisito tiene u n a atribución? Esto es, ¿existe u n a f u e n t e (por lo general, específica, individual) d e t e r m i n a d a p a r a c a d a requisito? ¿Algunos requisitos e n t r a n en conflicto c o n otros?

TM ¿Cada requisito e s a l c a n z a b l e e n el a m b i e n t e técnico q u e recibirá al sistema i producto?

PDF Editor

¿Cada requisito s e p u e d e p r o b a r u n a v e z q u e é s t e haya s i d o i m p l e m e n t a d o ' ¿El m o d e l o d e requisitos refleja d e m a n e r a a p r o p i a d a la información, la función y el c o m p o r t a m i e n t o del s i s t e m a que s e r á construido?

¿El m o d e l o d e requisitos se h a s o m e t i d o a "partición" p a r a q u e e x p o n g a en f o r m a progresiva i n f o r m a c i ó n m á s detallada a c e r c a del s i s t e m a ?

CAPÍTULO 7

187


• ¿Se h a n u s a d o p a t r o n e s d e requisitos para simplificar el m o d e l o de requisitos? ¿Todos los p a t r o n e s s e h a n validado d e m a n e r a a p r o p i a d a ? ¿Todos los p a t r o n e s s o n c o n s i s t e n t e s c o n los requisitos del cliente? Éstas y o t r a s p r e g u n t a s d e b e n realizarse y c o n t e s t a r s e p a r a a s e g u r a r q u e el m o d e l o d e requisitos e s un reflejo exacto d e las n e c e s i d a d e s del cliente y q u e proporciona u n a b a s e sólida para el diseño.

A n t e s de q u e el d i s e ñ o y la construcción d e un sistema b a s a d o en c o m p u t a d o r a p u e d a n c o m e n z a r , e s n e c e s a r i o e n t e n d e r los requisitos. Esto s e logra r e a l i z a n d o u n a serie d e t a r e a s de ingeniería de requisitos, la cual se lleva a c a b o d u r a n t e las activid a d e s d e c o m u n i c a c i ó n c o n el cliente y m o d e l a d o que h a n sido definidas para el p r o c e s o g e n é r i c o del s o f t w a r e . Los m i e m b r o s del equipo d e s o f t w a r e realizan siete func i o n e s distintas d e n t r o de la ingeniería d e requisitos: inicio, obtención, elaboración, negociación, especificación, validación y gestión. Al inicio del proyecto el desarrollador y el cliente (así c o m o o t r o s interesados) e s t a b l e c e n los requisitos b á s i c o s del p r o b l e m a , definen l a s restricciones predomin a n t e s del proyecto y especifican las características y f u n c i o n e s m á s i m p o r t a n t e s q u e d e b e n estar p r e s e n t e s e n el sistema p a r a q u e éste a l c a n c e s u s objetivos. Esta información e s e x p a n d i d a y refinada d u r a n t e la obtención, u n a actividad para la recopilación d e requisitos q u e e m p l e a r e u n i o n e s que e n c a b e z a un m o d e r a d o r facili tadas, el QFD y el desarrollo d e e s c e n a r i o s d e uso. La elaboración posterior e x p a n d e los requisitos hacia un m o d e l o de análisis; e s decir, u n a colección d e e l e m e n t o s del m o d e l o b a s a d o s en e s c e n a r i o s , en actividades y e n clases, d e c o m p o r t a m i e n t o y o r i e n t a d o s al flujo. En la creación d e e s t o s elem e n t o s s e p u e d e utilizar u n a variedad d e n o t a c i o n e s d e m o d e l a d o . El m o d e l o p u e d e referirse a p a t r o n e s d e análisis, características del d o m i n i o del problema que s o n r e c u r r e n t e s a través d e diferentes aplicaciones. C u a n d o s e identifican los requisitos y se crea el m o d e l o de análisis, el equipo d e s o f t w a r e , el cliente y o t r o s i n t e r e s a d o s en ei proyecto n e g o c i a n la prioridad, disponibilidad y c o s t o relativo d e c a d a requisito. El objetivo de esta n e g o c i a c i ó n es d e s a rrollar un plan d e proyecto realista. A d e m á s , c a d a requisito y el m o d e l o d e análisis c o m o un todo s e validan c o n t r a s t á n d o l o s c o n las n e c e s i d a d e s del cliente para a s e gurar q u e s e construirá el s i s t e m a correcto.

TM

PDF Editor

SÍ;::

[BOE98J Boehm, B. y A. Egyed, "Software Requircments Negotiation: Somc Lcssons Lcarned", en Proc. Intl. Con/. Software Engineeríng. ACM/IEEE, 1998, pp. 503-506. [BOS91]Bossert, J. L., Quality Function Deployment: A Practitioner's Approach, ASQC Press, 1991. [BUS96] Buschmann. F. et al., Pattem-Oriented Software Architecture: A System Paltcrn, Wiley, 1996.

iinirn

188

PAUTE DOS


[COCOl] Cockburn, A., Wríting Effective Use-Cases, Addison-Wesley, 2001. [CRI92] Christel, M. G. y K. C. Kang, "Issues in Requirements Elicitation", en Software Engineering | institute. CMU/SEI-92-TR-12 7, septiembre de 1992. [DON96] Donaldson, M. C. y M. Donaldson, Negotiating for Dummies, IDG Books Worldwide 1996. [FAR97] Farber, D. C., Common Sense Negociation. The Art of Winning Gracefully, Bay Press, 1997 [FOW97] Fowler, M„ Analysis Pallems: Reusable Object Models, Addison-Wesley, 1977. [GAM95] Gamma, E. et al, Design Pattems: Elemente of Reusable Object-Oriented Software Addison-Wesley, 1995. [GAU89] Gause, D. C. y G. M. Weinberg, Exploring Requirements: Quality Befóte Design, Dorsei House, 1989. [GEY01] Geyer-Schultz, A. y M, Hahsler, Software Engineering with Analysis Pattems, Technicaí I Report 01/2001, Instituí für lnformationsverarbeitung und-wirtschaft, Wirschaftsuniversiíá Wien, noviembre de 2001, obtenido de http://wwwai.wu-wien.ac.at/~hahsler/research/virIib_working2001 /virlib/. (JAC92J Jacobson, I., Objetc-Oriented Software Engineering, Addison-Wesley, 1992. |LEW00j Lewicki, R., D. Saunders y J. Minton, Essentials ofNegotiation, McGraw-Hill, 2002. [PAR96] Pardee, W„ To Satisjy and Delight Your Costumer, Dorset House, 1996. ISOM97] Somerville, 1. y P. Sawyer, Requirements Engineering, Wiley, 1997. [THA97] Thayer, R. H. y M Dorftnan, Software Requirements Engineering, 2a. ed., IEEE Computer Society Press, 1997. [YOUOl] Young, R., Effective Requirements Practices, Addison-Wesley, 2001. [ZAH90] Zahniser, R. A., "Buiiding Software in Groups", en American Programmer, vol.3. núms. 78, julio-agosto de 1990. [ZUL92] Zultner, R., "Quality Function Deployment for Software: Satisfying Costumers", e n | American Programmer, febrero de 1992, pp. 28-41.

7.1. ¿Por qué varios desabolladores de software no prestan mucha atención a la ingeniería de ] requisitos? ¿Se llegan a dar circunstancias en las que se puede omitir? 7.2. ¿Qué implica el "análisis de factibilidad" cuando se examina dentro del contexto de la fun- ] ción inicio? 7.3. A usted se le ha dado la responsabilidad de obtener requisitos de un cliente que dice es demasiado ocupado para reunirse con usted. ¿Qué debe hacer? 7.4. Exponer algunos de los problemas que pueden surgir cuando los requisitos deben obte- ] nerse de tres o cuatro clientes diferentes. 7.5. ¿Por qué se dice que el modelo de análisis representa una foto instantánea de un sisten en el tiempo? 7.6. Suponga que ha convencido al cliente (usted es un excelente vendedor) de cada demancá que ha hecho como desarrollador. ¿Eso lo convierte en un negociador experto? ¿Por qué? 7.7. Desarrollar al menos tres "preguntas de contexto libre" adicionales que pueda hacerle i ] TM algún interesado durante la fase de inicio. 7.8. A través de este capítulo se ha hecho referencia al "cliente". Describa al "cliente" para tas 1 desarrolladores de sistemas de información, para constructores de productos basados en compu- I tadora, para constructores de sistemas. Debe tenerse precaución: pueden existir más clientes ( este problema de lo que se imagina.

PDF Editor

7.9. Desarrolle un "paquete" que facilite la recopilación de requisitos. El equipo debe incluir ur I conjunto de directrices para realizar una reunión de recopilación de requisitos y una serie de I materiales que puedan utilizarse para facilitar la creación de listas y otros dispositivos que puedan ayudar en la definición de requisitos.

CAPÍTULO 7


189

7 . 1 0 . El profesor hará grupos de cuatro o cinco estudiantes. La mitad del grupo representará el papel del departamento de mercadotecnia, y la otra mitad, el de ingeniería del software. Lo que se pretenderá es definir los requisitos para la función de seguridad de HogarSeguro, descrita en este capitulo. Realizar una reunión de recopilación de requisitos mientras se utilizan las directrices presentadas en este capitulo. 7 . 1 1 . Desarrolle un caso de uso para una de las siguientes actividades: a) b) c) d) e)

Hacer un retiro en cajero automático. Utilizar su tarjeta de crédito para una comida en un restaurante. Comprar la despensa con una cuenta de cobro en línea. Buscar libros (sobre un tema específico) a través de una librería en línea. Una actividad que defina su instructor.

7 . 1 2 . ¿Qué representan las "excepciones" en los casos de uso? 7 . 1 3 . Explicar con brevedad cada uno de los elementos de un modelo de análisis. Indicar con qué contribuye cada elemento al modelo, cómo es que cada modelo es único y qué información general presenta cada modelo. 7 . 1 4 . Describir con argumentos propios un patrón de análisis. 7.15. Con la plantilla presentada en la sección 7.6.2, sugerir uno o más patrones para una aplicación que aplique el instructor. 7 . 1 6 . ¿Qué significa "ganar-ganar" en el contexto de la negociación durante la actividad de ingeniería de requisitos? 7 . 1 7 . ¿Qué se cree que suceda cuando la validación de requisitos descubre un error? ¿Quién es el indicado para corregir el error?

Debido a que es primordial para la creación exitosa de cualquier sistema complejo basado en computadora, la ingeniería de requisitos se expone en una gran cantidad de libros. Hull y sus colegas (Requirements Engineeríng, Springer-Verlag, 2002), Bray (An Introducción to Requirements Engineeríng, Addison Wesley, 2002), Arlow (Requirements Engineeríng, Addison-Wesíey, 2001), Gilb (Requirements Engineeríng, Addison-Wesley, 2000), G r a h a m {Requircments Engineeríng aricl Rapid Development, Addison-Wesley, 1999) y Sommerville y Kotonya (Requirements Engineeríng• Proceses and Techniques, Wiley. 1998) son sólo algunos libros dedicados a este tema. Dan Bcrry (http://se.uwaterloo.ca/~dbeny/bib.html) ha publicado una amplia variedad de escritos acerca de tópicos relacionados con la ingeniería de requisitos. Lauesen (Software Requirements: Styles and Techniques, Addison-Wesley, 2002) presenta una amplia muestra de notaciones y métodos para el análisis de requisitos. Weigers (Software Requirements, Microsoft Press, 1999) y Leffingwell y sus colegas (Managing Software Requirements: A Unifted Approach, Addison-Wesley, 2000) presentan una colección útil de las mejores prácticas de requisitos y sugieren guias pragmáticas para casi todos los aspectos del proceso de la ingeniería de requisitos. TM Robertson y Robertson (Masteríng the Requirements Process, Addison Wesley, 1999) presentan un estudio de caso muy detallado que ayuda a explicar todos los aspectos del análisis de requisitos y el modelo de análisis de software. Kovitz (Practica! Software Requirements: A Manual of Contení and Style, Manning Publications, 1998) explica paso a paso un enfoque para el análisis de requisitos y una guía de estilo para aquellos que deben desarrollar especificaciones de requisitos. Jackson (Software Requirements Analysis and Speciftcation: A Lexicón of Pracüces, Principies and Prejudices, Addison-Wesley, 1995) presenta una visión sugerente del tema de la A a la Z (de manera literal). Ploesch (Asseraons, Scenaríos and Prototypes, Springer-Verlag, 2003) explica técnicas avanzadas para desanollar requisitos de software.

PDF Editor

190

PARTE DOS


Windle y Abreo (Software Requirements Using the Unifted Process, Prentice-Hall, 2002) exponen la ingeniería de requisitos dentro del contexto del proceso unificado y la notación del UML Alexander y Steven (Writing Better Requirements, Addison-Wesley, 2002) presentan un breve conjunto de directrices para escribir requisitos claros, representarlos como escenarios y revisar el resultado final. El modelado de casos de uso es a menudo el conductor de la creación de todos los demás aspectos del modelo de análisis. Bittner y Spence (Use-Case Modeling, Addison-Wesley, 2002) examinan el tema de manera amplia, así como Cockbum [COCOl), Armour y Miller (Advanced Use-Case Modeling: Software Systems, Addison-Wesley, 2000), Kulak y sus colegas (Use Cases: Requirements in Context, Addison-Wesley, 2000), y Schneider y Winters (Applying Use Cases, Addison-Wesley, 1998). En Internet se puede disponer de una amplia variedad de fuentes de información sobre análisis e ingeniería de requisitos. En el sitio web de SEPA, h t t p : / / w w w . m h h e . c o m / p r e s s m a n , se puede encontrar una lista actualizada de referencias en la red mundial que son relevantes para el análisis y la ingeniería de requisitos.

TM

PDF Editor

CAPITULO

MODELADO DEL A N Á L I S I S

8

E

n el ámbito técnico, la ingeniería d e s o f t w a r e c o m i e n z a con u n a serie de t a r e a s de m o d e l a d o que c o n d u c e n a u n a especificación de requisitos y a u n a representación completa del diseño del software que se construirá. El modelo de análisis, q u e e n realidad e s u n a serie de modelos, es la primera representación técnica de u n sistema.

CEPTOS VE

.194 >...196

En un libro sobre m é t o d o s de m o d e l a d o del análisis, Tom DeMarco [DEM79] describe el proceso de la siguiente m a n e r a :

.219

Al observar los problemas y fallas reconocidas de la fase de análisis es necesario agregarle los siguientes objetivos:

..211

•

Los productos del análisis deben tener una elevada facilidad de mantenimiento. Esto se aplica en particular ai documento final [especificación de requisitos de software].

•

Los problemas de gran tamaño deben tratarse con un método efectivo de partición. La especificación del tipo de las novelas victorianas ya no sirve.

•

Deben utilizarse gráficas cuando sea posible.

....219 . . .202

. . . .225 ....197

• Se debe diferenciar entre consideraciones lógicas [esenciales] y físicas [de implementación]...

....234

Como mínimo se necesita... ....215

•

.211

Algo que ayude a hacer una partición de los requisitos y a documentarla antes de la especificación...

• Algunos medios para el seguimiento y evaluación de las interfases... • Herramientas nuevas para describir la lógica y la táctica, algo mejor que un texto narrativo.

.198 194

Aunque DeMarco escribió acerca de los atributos del m o d e l a d o del análisis h a c e m á s de u n cuarto de siglo, sus contribuciones s e siguen aplicando en la notación y los m é t o d o s m o d e r n o s de m o d e l a d o del análisis.

¿Qué es?

La p a l a b r a e s c r i t a e s u n

q u e e s r e l a t i v a m e n t e f á c i l d e e n t e n d e r y, a u n m á s

v e h í c u l o m a r a v i l l o s o p a r a la c o m u n i -

i m p o r t a n t e , c o n d u c e a u n a r e v i s i ó nTM p a r a l o g r a r la

cación, p e r o n o es, necesariamente,

c o r r e c c i ó n , la i n t e g r i d a d y l a c o n s i s t e n c i a .

la m e j o r

forma

de

r e p r e s e n t a r los

¿ Q u i é n l o h a c e ? Un ingeniero d e software (algu-

PDF Editor r e q u i s i t o s p a r a el s o f t w a r e d e c o m -

p u t a d o r a . El m o d e l a d o d e l a n á l i s i s u t i l i z a u n a combinación d e

formatos

en texto y d i a g r a m a s

n a s v e c e s l l a m a d o a n a l i s t a ) c o n s t r u y e el m o d e l o e m p l e a n d o requisitos o b t e n i d o s del cliente.

¿Por q u é e s i m p o r t a n t e ? Para validar los

p a r a r e p r e s e n t a r los r e q u i s i t o s d e los d a t o s , l a s

requisitos del software es n e c e s a r i o e x a m i n a r l o s

U n c i o n e s y el c o m p o r t a m i e n t o d e u n a m a n e r a

d e s d e a l g u n o s p u n t o s d e v i s t a d i f e r e n t e s . El m o d e -

191

192

PARTE DOS

PRÁCTICA DE LA INGENIERÍA D a SOFTWARE

l a d o del a n á l i s i s r e p r e s e n t a los r e q u i s i t o s e n múl-

d o s . U n a v e z q u e s e h a n c r e a d o los m o d e l o :

tiples " d i m e n s i o n e s " , c o n lo q u e se i n c r e m e n t a la

preliminares, éstos se refinan y a n a l i z a n p a r o

p r o b a b i l i d a d d e e n c o n t r a r errores, d e q u e surjan i n c o n s i s t e n c i a s y d e q u e s e d e s c u b r a n o m i -

e v a l u a r su c a l i d a d , i n t e g r i d a d y c o n s i s t e n c i c D e s p u é s , el m o d e l o d e a n á l i s i s final lo v a l i d a r

siones.

ios i n t e r e s a d o s

¿ C u á l e s s o n l o s p a s o s ? Los requisitos d e infor-

¿Cuál e s el p r o d u c t o o b t e n i d o ? Para el

m a c i ó n , f u n c i o n a l e s y d e c o m p o r t a m i e n t o se

m o d e l o d e análisis es posible elegir una amplio

m o d e l a n m e d i a n t e v a r i o s tipos d e d i a g r a m a s . El

v a r i e d a d d e tipos d e d i a g r a m a s . C a d a u n a d e

m o d e l a d o b a s a d o e n e s c e n a r i o s r e p r e s e n t a el

e s t a s r e p r e s e n t a c i o n e s o f r e c e u n a visión d e u n o

s i s t e m a d e s d e el p u n t o d e vista d e l u s u a r i o . Ei m o d e l a d o orientado al flujo indica c ó m o se

¿ C ó m o p u e d o e s t a r s e g u r o d e q u e lo he

o m á s d e los e l e m e n t o s d e l m o d e l o .

t r a n s f o r m a n los o b j e t o s d e d a t o s a l r e a l i z a r s e

hecho

las f u n c i o n e s d e l p r o c e s a m i e n t o . El m o d e l a d o b a s a d o en clases define objetos, atributos y rela-

t r a b a j o del m o d e l a d o del a n á l i s i s d e b e n revisars e e n lo relativo a su c o r r e c c i ó n , i n t e g r i d a d y

c i o n e s . El m o d e l a d o d e l c o m p o r t a m i e n t o p r e s e n t a los e s t a d o s del s i s t e m a y sus c l a s e s , a s í

c o n s i s t e n c i a . Estos d e b e n r e f l e j a r las n e c e s i d a d e s d e t o d o s los i n t e r e s a d o s y e s t a b l e c e r u n a

c o m o el i m p a c t o d e los e v e n t o s s o b r e sus e s t a -

b a s e d e s d e la c u a l p u e d a c o n d u c i r s e el d i s e ñ o .

8 . 1

ANÁLISIS

DE

c o r r e c t a m e n t e ? Los productos de

REQUISITOS

El análisis de requisitos genera la especificación de características operacionales d J software; indica la interfaz del s o f t w a r e con otros e l e m e n t o s del sistema, y estable-' ce las restricciones que d e b e tener el software. El análisis de requisitos permite que el ingeniero de s o f t w a r e (a veces llamado en e s t e contexto analista o modelador) sd extienda sobre requerimientos básicos establecidos d u r a n t e tareas anteriores a ingeniería de requisitos y construya m o d e l o s que representen escenarios del usua-l rio, actividades funcionales, clases de problemas y s u s relaciones, el comportamiento de las clases y el sistema y, a medida que se transforma, el flujo de datos. El análisis de requisitos le proporciona al diseñador de s o f t w a r e una representación de información, función y c o m p o r t a m i e n t o que p u e d e trasladar a diseños arqui-

CLAVE El modelo de análisis y lo especificación de requisitos proporciona un medio para evaluar la calidad uno vez que el software esté construido.

tectónicos, de interfaz y en el nivel de c o m p o n e n t e s . Por último, el modelo de análisis y la especificación de requisitos ofrecen al desarrollador y al cliente los medios para evaluar la calidad u n a vez construido el software. Por m e d i o del m o d e l a d o del análisis el ingeniero de s o f t w a r e se centra primerc en el qué, no en el cómo. ¿Qué objetos manipula el sistema, qué funciones debe TM d e s e m p e ñ a r el sistema, qué c o m p o r t a m i e n t o s muestra el sistema, qué interfaces se definen y qué restricciones se aplican? 1 En capítulos anteriores se estableció que en esta etapa tal vez n o fuera posible

PDF Editor

realizar una especificación completa de requisitos. Quizá el desarrollador no esté

1

Es necesario m e n c i o n a r que conforme los clientes se vuelven m á s refinados en el sentido tecnoló-

gico existe u n a tendencia hacia la especificación tanto del cómo c o m o del qué. Sin e m b a r g o , el enfoque primario debe p e r m a n e c e r en el qué.

CAPITULO 8

MODELADO DEL ANÁUSIS

193

de

Y de

s e g u r o de qué e n f o q u e específico realizará la función y si se d e s e m p e ñ a r á de m a n e ra apropiada. Estas realidades favorecen u n enfoque iterativo para el análisis y el m o d e l a d o de requisitos. El analista d e b e modelar lo que se c o n o c e y utilizar ese m o d e l o c o m o b a s e para diseñar un incremento de software. 2

8.1.1 Filosofía y objetivos generales El modelo de análisis d e b e cumplir tres objetivos primarios: 1) describir lo que requiere el cliente, 2) establecer u n a b a s e para la creación de un diseño de software, y 3) definir u n conjunto de requisitos que puedan validarse una vez construido el software. El m o d e l o de análisis llena el vacío entre u n a descripción al nivel de sistem a (capítulo 6) —que detalla la funcionalidad general del sistema, la cual se logra al aplicar software, hardware, datos, h u m a n o s — y otros e l e m e n t o s del sistema y del diseño de s o f t w a r e (capítulo 9) —que detallan la arquitectura de aplicación del softw a r e , la interfaz con el usuario y la estructura e n el nivel de componentes—. Esta relación se ilustra e n la figura 8.1. "Los probiemos dignos de otocor demuestran su volor devolviendo el golpe."

Es importante puntualizar que algunos e l e m e n t o s del m o d e l o de análisis están p r e s e n t e s (en u n grado m á s alto de abstracción) en la descripción del sistema, y que e s a s t a r e a s de ingeniería de requisitos e n realidad c o m i e n z a n c o m o parte de la ingeniería de sistemas. Además, todos los e l e m e n t o s del m o d e l o de análisis son identiTM ficables de m a n e r a directa e n las partes del modelo del diseño. No siempre es posible u n a división clara de t a r e a s de análisis y diseño entre e s t a s dos importantes acti-

PDF Editor

vidades del modelado. De m o d o invariable, c o m o parte del análisis se realiza algún diseño y algún análisis se efectúa d u r a n t e el diseño.

2 De manera alternativa, el equipo de software puede elegir la creación de un prototipo (capitulo 3) en un esfuerzo encaminado a entender mejor los requisitos para el sistema.

194

PARTE D O S


8.1.2 Reglas prácticas de análisis Arlow y Neustadt [ARL02] sugieren varias reglas prácticas que deben seguirse para crear el modelo de análisis: • El modelo debe centrarse en los requisitos visibles dentro del problema o dominio de negocio. El grado de abstracción debe ser alto de forma relativa. "No se debe perder tiempo e n detalles" [ARL02] que tratan de explicar c ó m o funcionará el sistema. • Cada elemento del modelo de análisis debe agregarse a un acuerdo general de los requisitos de software y proporcionar ción, función y comportamiento • Debe retrasarse la consideración

una visión interna del dominio de informa-

del sistema. de la infraestructura y otros modelos no funcio-

nales hasta el diseño. Por ejemplo, e s posible que se requiera u n a b a s e de datos, pero las clases n e c e s a r i a s para implementarla, las funciones que se requieren para acceder a ella y el c o m p o r t a m i e n t o que se exhibirá c u a n d o se utilice debe considerarse sólo d e s p u é s de que se haya completado el análisis de dominio del problema. • Se debe minimizar

el acoplamiento

de todo el sistema. Es importante repre-

sentar las relaciones entre clases y funciones. Sin embargo, si el nivel de "interconexión" es e x t r e m a d a m e n t e alto se deben hacer e s f u e r z o s para reducirlo. • Se debe tener la seguridad de que el modelo de análisis proporciona

valor a todos

los interesados. Cada circunscripción tiene su propio u s o del modelo. Por ejemplo, los interesados relacionados con los negocios d e b e n utilizar el m o d e l o para validar los requisitos; los diseñadores, c o m o b a s e para el diseño; la gente de a s e g u r a m i e n t o de la calidad, c o m o ayuda p a r a planear p r u e b a s de aceptación. • El modelo debe mantenerse

tan simple como sea posible. No se deben agregar

d i a g r a m a s adicionales c u a n d o é s t o s no ofrezcan información nueva. No se deben utilizar f o r m a s de notación n u e v a s c u a n d o basta c o n u n a simple lista.

8.1.3 Análisis del dominio En www.iturls.

íom/EBsísh/ Software Engineeríng/ SE modS.asp

Al e x a m i n a r la ingeniería de requisitos (capítulo 7) se estableció queTM los p a t r o n e s de análisis a m e n u d o ocurren de n u e v o en m u c h a s aplicaciones dentro de u n dominio de negocio especifico. Si e s t o s p a t r o n e s se definen y se clasifican por categoría de

PDF Editor pueden encontrarse muthos reíURos útiles pora el onéfisb del dominio.

u n a m a n e r a que permitan al ingeniero o al analista de s o f t w a r e reconocerlos y reutilizarlos, la creación del modelo de análisis se acelera. Un factor de mayor importancia es que la probabilidad de aplicar p a t r o n e s de diseño reutilizables y compon e n t e s ejecutables de s o f t w a r e a u m e n t a en forma sustancial. Esto ofrece tiempo al m e r c a d o y reduce los costos del desarrollo.

CAPITULO 8


195

Entrada y salida para el análisis del dominio. Literatura técnica Taxonomías d e clase

Aplicaciones existentes Sondeos a los clientes Recomendación experta Requisitos actuales/futuros

^

Estándares d e reutilización 1

m

Modelos funcionales Lenguajes d e dominio

Modelo d e análisis del dominio

¿Pero, e n p r i m e r lugar, c ó m o s e r e c o n o c e n los p a t r o n e s d e análisis? ¿ Q u i é n e s los d e f i n e n , los a s i g n a n a u n a c a t e g o r í a y los p r e p a r a n p a r a a p l i c a r l o s en p r o y e c t o s s u b s e c u e n t e s ? Las r e s p u e s t a s a e s t a s p r e g u n t a s r e s i d e n e n el análisis

del dominio.

Firesmith [FIR93] d e s c r i b e el a n á l i s i s del d o m i n i o de la s i g u i e n t e m a n e r a : El análisis del dominio de software es ia identificación, el análisis y la especificación de requisitos comunes de un dominio especifico de aplicación para, de manera típica, reutilizarlo en múltiples proyectos dentro de ese dominio de aplicación... [El análisis del dominio orientado a objetos es] la identificación, el análisis y la especificación de capacidades comunes reutilizables dentro de un dominio específico de aplicación, en términos de objetos, clases, subensamblajes y marcos de trabajo. El " d o m i n i o d e a p l i c a c i ó n e s p e c í f i c o " p u e d e v a r i a r d e s d e a e r o n á u t i c a h a s t a servicios bancarios, desde videojuegos en multimedia hasta software aplicado en instrumental m é d i c o . La m e t a del a n á l i s i s o d e d o m i n i o e s directa: e n c o n t r a r o c r e a r a q u e l l a s clases de análisis o funciones y características c o m u n e s q u e se aplican a m p l i a m e n te p a r a q u e p u e d a n reutilizarse. 3

"El gran arte del aprendizaje es entender poco a poco"

John Locke

En cierta f o r m a , el p a p e l d e u n a n a l i s t a de d o m i n i o e s similar al de u n m a e s t r o f o r j a d o r de h e r r a m i e n t a s e n un a m b i e n t e d e m a n u f a c t u r a p e s a d a . El t r a b a j o d e e s t e último es diseñar y fabricar instrumentos que puedan ser usados por mucha gente • • a e r ó del dominio.

q u e realiza t r a b a j o s similares. El p a p e l del analista de d o m i n i o 4 e s d eTM s c u b r i r y definir

PDF Editor 3

Una visión complementaria del análisis del dominio "involucra el modelado del dominio de forma que los ingenieros de software y otros interesados puedan aprender más de él.. no todas las clases del dominio resultan necesariamente en el desarrollo de clases reutilizables" [LET03|. 4 No debe suponerse que si se cuenta con la colaboración de un analista del dominio, un ingen! .>ro de software no tiene por qué comprender el dominio de aplicación. Todos los miembros de un equipo de software deben tener algún conocimiento del dominio en el cual se colocará el software

196

PARTE DOS


p a t r o n e s de análisis reutilizables, clases d e análisis e i n f o r m a c i ó n relacionada q u e p u e d a u s a r m u c h a g e n t e en aplicaciones parecidas. La figura 8.2 [ARA89] ilustra e n t r a d a s y s a l i d a s clave p a r a el p r o c e s o de análisis d e dominio. Las f u e n t e s d e c o n o c i m i e n t o del d o m i n i o s e e x a m i n a n en un i n t e n t o p e : identificar o b j e t o s q u e p u e d e n ser reutilizados a t r a v é s del dominio.

8 . 2

ENFO&UES

DE M O D E L A D O

PEÍ.

AMAMWK

Una visión del m o d e l a d o del análisis, l l a m a d o análisis estructurado,

•

c o n s i d e r a q u e los

d a t o s y el p r o c e s o q u e t r a n s f o r m a n los d a t o s s o n e n t i d a d e s s e p a r a d a s . Los objetos d e d a t o s s e m o d e l a n e n u n a f o r m a q u e define s u s atributos y relaciones. Los proces o s q u e m a n i p u l a n los o b j e t o s d e los d a t o s s e m o d e l a n d e tal m a n e r a q u e m u e st r an c ó m o t r a n s f o r m a n los datos, m i e n t r a s los o b j e t o s d e d a t o s fluyen p o r el sistema. Un s e g u n d o e n f o q u e del m o d e l a d o del análisis, l l a m a d o análisis orientado a objetos, s e c e n t r a e n la definición de c l a s e s y en la m a n e r a en q u e é s t a s c o l a b o r a n entre ellas p a r a efectuar los requisitos del cliente. El UML y el p r o c e s o unificado (capítulo 3) e s t á n o r i e n t a d o s a objetos en f o r m a p r e d o m i n a n t e .

El [o]nálisis es frustrante, lleno de relociones interpersonales complejos, indefinido y difícil. En pocas palabras, es fascinante. Una vez que estás enganchado, el viejo placer de la construcción de sistemas nunca será suficiente para satisfacerte." Tom DeMarco

A u n q u e el m o d e l o d e análisis p r o p u e s t o en e s t e capítulo c o m b i n a características d e a m b o s e n f o q u e s , e s c o m ú n q u e los e q u i p o s d e s o f t w a r e elijan u n o y excluyan t o d a s las r e p r e s e n t a c i o n e s del otro. El c u e s t i o n a m i e n t o n o e s cuál e s el mejor, s i n o q u é c o m b i n a c i ó n d e r e p r e s e n t a c i o n e s le p r o p o r c i o n a r á a los i n t e r e s a d o s el mejor m o d e l o de requisitos d e software y el p u e n t e m á s efectivo para el diseño d e software. El m o d e l a d o del análisis c o n d u c e a la derivación d e c a d a u n o d e los e l e m e n t o s de m o d e l a d o m o s t r a d o s en la figura 8.3. No o b s t a n t e , el c o n t e n i d o específico d e cada e l e m e n t o (por ejemplo, los d i a g r a m a s c o n q u e s e construyen el e l e m e n t o y el modelo) p u e d e diferir d e p r o y e c t o a proyecto. C o m o ya s e h a p u n t u a l i z a d o m u c h a s veces e n este libro, el equipo d e s o f t w a r e d e b e trabajar p a r a m a n t e n e r l oTM simple. Sólo se d e b e n utilizar aquellos e l e m e n t o s q u e a g r e g u e n valor al m o d e l o .

PDF Editor

"¿Por qué debemos construir modelos? ¿Por qué no construimos el sistema y yo? la respuesta es que podemos construir modelos de tal forma que resaltemos o enfaticemos ciertas características críticas de un sistema, al mismo tiempo que quitamos énfasis a otros aspectos del sistemo." Ed Yourdon

CAPÍTULO 8

M O D E L A D O DEL ANÁLISIS

197

Elementos orientados

=xxlelo

Cosos d e uso. Cosos d e uso. Diogromos d e Diogramas d e

«'fojo

texto diogramas actividad carril

„

Diogramas d e flujo d e datos Diogramas d e flujo d e control Narrativas d e procesamiento

i Modelo d e análisis

Diagramas d e clase Paquetes d e análisis Modelos CRC Diagramas d e colaboración

8 . 3

CONCEPTOS

DEL

MODELADO

Diagramas d e estado Diagramas d e secuencia

DE

DATOS

El m o d e l a d o del análisis a m e n u d o c o m i e n z a con el modelado de datos. El ingeniero o analista de s o f t w a r e define t o d o s los objetos de d a t o s que se p r o c e s a n dentro del M sobre dédalos

sistema y las relaciones entre los objetos de datos, a d e m á s de otra información pertinente para las relaciones.

8.3.1 Objetos de datos Un objeto de datos es u n a representación de casi cualquier información c o m p u e s t a que el s o f t w a r e d e b e entender. Información

compuesta

se refiere a algo que tiene

m u c h a s propiedades o atributos diferentes. Por lo tanto, "anchura" (un valor individual) no sería u n objeto de datos válido, p e r o las d i m e n s i o n e s (la incorporación de altura, a n c h u r a y profundidad) podrían definirse c o m o un objeto. Un objeto de datos p u e d e ser una entidad externa (por ejemplo, cualquier cosa que produzca o c o n s u m a información), una cosa (por ejemplo, un reporte o un despliegue), un suceso (como una llamada telefónica) o un evento (como una alarma), un papel (por ejemplo, un vendedor), u n a unidad organizacional (como un departamento de contaduría), u n lugar (como un almacén), o una estructura (como un archivo). Por ejemplo, una persona o u n auto pueden verse c o m o un objeto de datos en el sentido de que cualquiera de ellos puede definirse en términos de u n conjunto de atributos. La descripción

K

del objeto de datos incorpora el objeto y todos sus atributos. Un objeto de d a t o s encapsula sólo datos: no existe alguna referencia d e n t r o de un

CÚVVE de datos es nsRsenfáción de

objeto de d a t o s a las o p e r a c i o n e s actúen sobre los datos. 5 Por lo tanto, el objeto de d a t o s p u e d e representarse c o m o u n a tabla, tal c o m o se muestra en TM la figura 8.4. Los e n c a b e z a d o s d e la tabla reflejan los atributos del objeto. En este caso, un a u t o se

información

d e f i n e e n t é r m i n o s d e m a r c a , m o d e l o , n ú m e r o d e s e r i e , tipo d e c a r r o c e r í a , color y propieta-

que se

rio. El contenido de la tabla representa ejemplos específicos del objeto de datos. Por

PDF Editor con software.

ejemplo, un Chevy Corvette es una muestra del objeto de datos auto.

5 Esta distinción separa los objetos de datos y las clases u objetos definidos como parte del enfoque orientado a objetos.

198

PARTE DOS


Representación tabular d e objetos d e datos.

Nombres d e atributos

Une los objetos d e d a t o s entre sí, en este c a s o , p r o p i e t a r i o

identificador

Instancia

Atributos descriptivos

Atributos referenciales

Marca

M o d e l o # d e id.

Tipo

Color

Lexus

LS400

Sedan

Blanco

AB123...

Propietario RSP

CCD BMW | Ford

750iL Taurus

XZ765. . . C o u p é Q12A45. .Sedán

Blanco Azul

UL BLF

8.3.2 Atributos

\ CUV V E

características diferentes. Se p u e d e n utilizar para 1) n o m b r a r u n a ocurrencia de:

Los atributos definen a

objeto de datos, 2) describir la ocurrencia o 3) hacer referencia a otra ocurrencia er

un objeto de datos,

otra tabla. Además, se debe definir u n o o m á s atributos c o m o u n identificador; es

describen sus característicos y, en

Los atributos definen las propiedades de un objeto de datos y t o m a n u n a de las tres

decir, el atributo identificador se convierte en u n a "clave" c u a n d o se d e s e a encontrar

algunos casos, hacen

u n a ocurrencia del objeto de datos. En algunos casos, los valores para el (los) ider-

referencia o otro

tificador(es) son únicos, a u n q u e e s t o no es u n requisito. En referencia al objeto de

objeto.

d a t o s a u t o , u n identificador razonable podría ser el n ú m e r o de serie.

Referencia Web "norniolizoción" es importante para todos oqueBos que intentnn reolizai modelado de datos. En www. datamodel.org puede encontrarse uno introducción útil.

El conjunto de atributos apropiado para u n objeto de d a t o s se determina mediarte la comprensión del contexto del problema. Los atributos para a u t o sirven bier para u n a aplicación que utilice el D e p a r t a m e n t o de vehículos de motor, p e r o estes atributos serían inútiles para u n a c o m p a ñ í a automotriz que necesite un s o f t w a r e para el control de fabricación. En este último caso, los atributos para a u t o tal v e r incluirían t a m b i é n número de serie, tipo de carrocería y color, p e r o a d e m á s t e n d r í a n q u t j a d i c i o n a r s e m u c h o s m á s a t r i b u t o s ( c o m o código interior, tipo de tren de manejo, desigrs-

dor de paquete de ajuste, tipo de transmisión) p a r a h a c e r d e a u t o u n o b j e t o significativa

en el contexto de control de fabricación.

INFORMACIÓN

Objetos de datos y clases OO, ¿son lo mismo? V

C u a n d o se d e b a t e a c e r c a d e los objetos d e d a t o s es común que surja una pr egunta : ¿un

objeto d e datos es lo mismo que una clase o r i e n t a d a a objetos? La respuesta es: "no".

también incorpora las operaciones q u e manipulan los

TM

datos implicados p o r dichos atributos. A d e m á s , la definición d e clases implica u n a infraestructura completa que es parte del e n f o q u e de la ingeniería de software

PDF Editor Un objeto de datos define un elemento compuesto d e

orientada a objetos. Las clases se comunican entre sí a

los datos; esto es, incorpora u n a colección d e elementos d e

través d e mensajes; pueden o r g a n i z a r s e en jerarquías;

d a t o s individuales (atributos) y d a un nombre a la

proporcionan características h e r e d a d a s p a r a objetos que

colección d e elementos (el n o m b r e del objeto d e datos).

son una instancia p a r a una clase.

^ U n a clase O O encapsula atributos d e los datos, pero

CAPÍTULO 8


199

o) Una conexión básica entre objetos de datos

b) Relaciones entre objetos de datos

8.3.3 Relaciones Los objetos de d a t o s están c o n e c t a d o s e n t r e sí de m u c h a s m a n e r a s diferentes. Por ejemplo, dos objetos de datos, p e r s o n a y a u t o , pueden representarse con la simple notación ilustrada en la figura 8.5a. Se establece u n a conexión entre p e r s o n a y a u t o porque los objetos se relacionan entre sí. ¿Pero, cuáles son las relaciones? La respuesta se determina e n t e n d i e n d o el papel de las p e r s o n a s (propietarios, en este están á

caso) y de los a u t o s dentro del contexto del s o f t w a r e que se construirá. Se p u e d e definir un conjunto de p a r e j a s objeto/relación que definan las relaciones relevantes. Por ejemplo: • Una persona posee un auto. • Una persona está asegurada para conducir un auto. Las relaciones posee y está asegurada para conducir definen las conexiones relevantes entre p e r s o n a y auto. En la figura 8.5b se ilustran e s t a s p a r e j a s objeto/relación de m a n e r a gráfica. Las flechas de la figura 8.5b ofrecen información importante acerca de la direccionalidad de la relación y a m e n u d o reducen la ambigüedad o las m a l a s interpretaciones.

8.3.4 Cardinalidad y modalidad Los e l e m e n t o s del m o d e l a d o de d a t o s —objetos de datos, atributos y relaciones— ofrecen la b a s e p a r a e n t e n d e r el dominio de información de un problema. Sin embargo, también es necesario c o m p r e n d e r información adicional relacionada con e s t o s e l e m e n t o s básicos. Hasta este p u n t o se ha definido u n conjunto de objetos y se han r e p r e s e n t a d o las parejas objeto/relación que los limitan. Pero u n simple par que TM establece que o b j e t o x se relaciona con o b j e t o Y n o proporciona suficiente información para los propósitos de la ingeniería del software. Se debe e n t e n d e r c u á n t a s ocurrencias del

PDF Editor

o b j e t o x están relacionadas con c u á n t a s ocurrencias del objetoY. Esto c o n d u c e al concepto del m o d e l a d o de d a t o s llamado cardinalidad.

El modelo de d a t o s debe ser capaz de representar el n ú m e r o de ocurrencias de

los objetos en u n a relación dada. Tillmann [T1L93J define la cardinalidad de un par objeto/relación de la siguiente m a n e r a : "Cardinalidad e s la especificación del n ú m e -

I

PARTE D O S

200


Cómo se

ro d e o c u r r e n c i a s d e un [objeto] q u e p u e d e relacionarse con el n ú m e r o d e ocurren-

maneja una

cias d e otro [objeto]". Por ejemplo, un o b j e t o p u e d e relacionarse sólo c o n otro obje-

situación en la

to (una relación 1:1); un objeto p u e d e relacionarse c o n m u c h o s o b j e t o s (una relaci.

que un i datos está rela-

1 :N); un n ú m e r o d e o c u r r e n c i a s d e un objeto p u e d e relacionarse con algún otro]

cionado con la

n ú m e r o d e o c u r r e n c i a s de otro o b j e t o (una relación M:N).6 La cardinalidad tambier !

ocurrencia de

define "el n ú m e r o m á x i m o d e objetos q u e p u e d e participar e n u n a relación" [TIL93] A

muchos otros objetos de datos?

Sin e m b a r g o , no indica si un objeto particular de d a t o s d e be participar o n o en la relación. El m o d e l o d e d a t o s a g r e g a m o d a l i d a d al par o b j e t o / r e l a c i ó n p a r a especif car e s t a información. INFORMACIÓN

Diagramas de entidad-relación La p a r e j a objeto-relación es la piedra angular del modelo d e datos. Estas parejas pueden

representan por medio d e un rectángulo etiquetado. Las relaciones se representan mediante una línea etiquetada

representarse d e manera gráfica mediante el d i a g r a m a de

que conecta objetos. En algunas variaciones del DER la

entidad-relación (DER).' El DER lo propuso originalmente

línea de conexión contiene un rombo q u e está etiquetado

Peter Chen [CHE77] p a r a el diseño d e sistemas de bases relaciónales, y después otros lo han ampliado. Con el DER

con la relación. Las conexiones entre objetos d e datos y relaciones se establecen mediante una variedad d e

se identifica un conjunto d e componentes primarios:

símbolos especiales q u e indican su cardinalidad y

objetos de datos, atributos, relaciones e indicadores d e varios tipos. El propósito primordial del DER e s representar

modalidad.

objetos d e datos y sus relaciones. Ya se ha hecho una introducción d e la notación

r

Para más información sobre el modelado de datos y el d i a g r a m a d e entidad-relación el lector interesado puede consultar [THA00]

rudimentaria p a r a el DER. Los objetos d e datos se

La modalidad

de u n a relación e s de 0 si n o h a y u n a n e c e s i d a d explícita para que

o c u r r a la relación o la relación e s opcional. La m o d a l i d a d e s 1 si u n a ocurrencia de la relación e s obligatoria.

TM

PDF Editor

6 Por ejemplo, un tío puede tener muchos sobrinos y un sobrino puede tener muchos tios. 7 Aunque el DER todavía se usa en algunas aplicaciones para el diseño de bases de datos, en la actualidad la notación en UML es la más utilizada para el diseño de datos.

CAPÍTULO 8

201


in un medio automatizado p a r a crear s d e entidad-relación, diccionarios d e objetos d e y modelos relacionados. ¡ k a : Las herramientas en esta categoría permiten describir objetos d e datos y sus relaciones. En casos utilizan la notación del DER; en otras modelan las relaciones por medio d e otros . A d e m á s permiten la creación d e un modelo d e datos al generar un esquema d e b a s e d e datos

SM80.

itas representativas 8 ERWin, desarrollado por Computes Associates ca.com), ayuda en el diseño de objetos de datos, propias y elementos clave para bases d e datos.

Oracle/Designer, desarrollado por Oracle Systems (www.orade.com), modela procesos d e negocios, entidades d e datos y relaciones que se transforman en diseños a partir d e los cuales se generan aplicaciones completas y bases d e datos. MetoScope, desarrollado por Madrone Systems (www.madronesystems.com), es una herramienta p a r a el modelado d e datos d e b a j o costo q u e d a soporte a la representación gráfica d e datos. ModelSphere,

desarrollado por Magna Solutions GMBH

(www.magnasolutions.com), d a soporte a una variedad d e herramientas d e modelado relaciona!. VisibleAnolysl, desarrollado por Visible Systems (www.visible.com), da soporte a una variedad d e

>, desarrollado por Embarcadero Software

funciones d e modelado del análisis, incluido el

embarcadero.com), brinda soporte al modelado

modelado d e datos.

•relación.

Cualquier estudio sobre el análisis orientado a objetos debería c o m e n z a r definiendo el término orientado a objetos. ¿Qué e s un p u n t o de vista orientado a objetos? ¿Por qué un m é t o d o se considera orientado a objetos? ¿Qué es un objeto? C u a n d o la OO obtuvo u n a amplia variedad de adeptos durante las d é c a d a s de 1980 y 1990, existieron m u c h a s opiniones diferentes (por ejemplo, [BER93|, ¡TAY90], (STR88], [ B 0 0 8 6 | acerca de las r e s p u e s t a s correctas a e s t a s preguntas. En la actualidad h a surgido una visión c o h e r e n t e de la OO. El objetivo del análisis orientado a objetos (AOO) es definir t o d a s las clases (adem á s de las relaciones y el c o m p o r t a m i e n t o asociado con ellas) relevantes para el problema y que deben resolverse. Esto se logra llevando a c a b o a l g u n a s tareas: 1. Deben comunicarse los requisitos básicos del usuario entre el cliente y el ingeniero de software. 2.

Deben identificarse las clases (es decir, se definen los atributos y métodos).

3 . Se define u n a jerarquía de clases. 4.

TM objetos). Deben representarse las relaciones de objeto a objeto (conexiones entre

5. Debe modelarse el c o m p o r t a m i e n t o del objeto. 6. Las t a r e a s 1 a 5 se vuelven a aplicar de m a n e r a iterativa hasta que el m o d e l o

PDF Editor esté completo.

8 Las herramientas mencionadas aquí son una muestra de esta categoría. En la mayoría de los casos los nombres están registrados por sus respectivos desarrolladores.

202

PARTE DOS


En lugar de e x a m i n a r un p r o b l e m a m e d i a n t e un m o d e l o m á s convencional c e l l tipo e n t r a d a - p r o c e s a m i e n t o - s a l i d a (flujo d e información) o un m o d e l o derivado i f o r m a exclusiva d e las e s t r u c t u r a s jerárquicas d e información, el AOO construye i m o d e l o o r i e n t a d o a las c l a s e s q u e se b a s a en la c o m p r e n s i ó n d e los c o n c e p t o s i INFORMACIÓN

Conceptos orientados a objetos Los conceptos orientados a objetos (OO) están bien establecidos en el mundo d e la ingeniería del software. A continuación se presentan las descripciones abreviadas d e conceptos O O q u e se encuentran con frecuencia durante el modelado del análisis. En el capítulo 10 se presentan otros objetos O O q u e están alineados d e manera más cercana al diseño de software. Atributos: una colección d e valores d e los datos que describen una clase.

plano d e trabajo) que describe una colección d e objetos similares. Objetos: instancias d e una clase específica. Los o b j e ^ s heredan los atributos y operaciones d e una clase. Operaciones: también llamadas métodos y servicios proporcionan la representación d e uno d e los comportamientos d e una clase. Subclase: una especialización d e la superclase. Ur-c subclase puede heredar tanto los atributos como las

Clase: encapsula los datos y las abstracciones d e procedimiento requeridos p a r a describir el contenido y el comportamiento d e alguna entidad del mundo real. Dicho d e otra m a n e r a , una clase es una descripción generalizada (por ejemplo, una plantilla, un patrón o un

operaciones d e una superclase. Superclase: también llamada una clase básica, es , generalización d e un conjunto de clases q u e están relacionadas con ella.

A u n q u e el éxito d e un s i s t e m a o p r o d u c t o b a s a d o en c o m p u t a d o r a s e m u c h a s f o r m a s , la satisfacción del u s u a r i o e n c a b e z a la lista. Si los inger s o f t w a r e e n t i e n d e n la m a n e r a en q u e los u s u a r i o s finales (y o t r o s actores) interactuar c o n el s i s t e m a , el e q u i p o d e s o f t w a r e s e r á m á s c a p a z d e caracte f o r m a a p r o p i a d a los requisitos y construir m o d e l o s significativos d e análisis r< ño. Por lo tanto, el m o d e l a d o del análisis con UML c o m i e n z a con la creación d e ¡ narios en la f o r m a d e c a s o s d e uso, d i a g r a m a s d e actividad y d i a g r a m a s d e

8.5.1 Escritura de casos de uso Un c a s o d e u s o c a p t u r a las i n t e r a c c i o n e s q u e o c u r r e n e n t r e los productores ¡ s u m i d o r e s d e información y del s i s t e m a en sí m i s m o . En e s t a sección s e ex TM f o r m a e n q u e s e desarrollan los c a s o s d e u s o c o m o u n a p a r t e d e la a c t i n m o d e l a d o del análisis. 9

PDF Editor

El c o n c e p t o d e un c a s o d e u s o (capítulo 7) e s r e l a t i v a m e n t e fácil d e enter

cribe un e s c e n a r i o d e u s o específico e n u n l e n g u a j e directo d e s d e el punte

9

Los casos de uso son una parte particularmente importante del modelado del análisis terfases con el usuario. El análisis de la interfaz se trata con detalle en el capítulo 12.

CAPÍTULO 8


203

d e u n a c t o r definido. 1 0 Pero c ó m o p u e d e s a b e r s e 1) ¿sobre q u é escribir? 2), ¿ c u á n t o escribir a c e r c a d e ello? 3), ¿qué tan detallada d e b e s e r la descripción?, y 4) ¿ c ó m o o r g a n i z a r la descripción? Estas s o n las p r e g u n t a s q u e d e b e n c o n t e s t a r s e p a r a q u e los c a s o s de u s o t e n g a n u n valor c o m o h e r r a m i e n t a p a r a el m o d e l a d o del análisis. "[Los cosos de uso] son simplemente uno ayudo para definir lo que existe fuera del sistema (actores) y lo que debería realizar el sistema (cosos de uso)." Ivor Jacobson

¿Sobre q u é escribir?

Las p r i m e r a s d o s t a r e a s d e la i n g e n i e r í a d e requisitos 1 1 —ini-

cio y o b t e n c i ó n — p r o p o r c i o n a n la i n f o r m a c i ó n n e c e s a r i a p a r a c o m e n z a r a escribir c a s o s de u s o . Las r e u n i o n e s p a r a la r e c o p i l a c i ó n d e requisitos, d e s p l i e g u e d e la f u n -

situói casos de el

ción d e calidad (QFD) y o t r o s m e c a n i s m o s p a r a la ingeniería d e r e q u i s i t o s s e utilizan p a r a identificar a los i n t e r e s a d o s , definir el á m b i t o del p r o b l e m a , e s p e c i f i c a r las m e t a s o p e r a t i v a s g l o b a l e s , e s q u e m a t i z a r t o d o s los r e q u i s i t o s f u n c i o n a l e s c o n o c i d o s

élainge-

ajusflos.

y describir las c o s a s (objetos) q u e m a n i p u l a r á el s i s t e m a .

esto no deban los i técnicas m el

El d e s a r r o l l o d e u n a s e r i e de c a s o s de u s o s e c o m i e n z a h a c i e n d o u n a lista de las f u n c i o n e s o a c t i v i d a d e s q u e r e a l i z a u n a c t o r e s p e c í f i c o . Éstas p u e d e n o b t e n e r s e d e u n a lista d e f u n c i o n e s r e q u e r i d a s del s i s t e m a por m e d i o d e c o n v e r s a c i o n e s c o n los c l i e n t e s o u s u a r i o s finales, o m e d i a n t e u n a e v a l u a c i ó n d e los d i a g r a m a s de actividad (sección 8.5.2) d e s a r r o l l a d o s c o m o p a r t e del m o d e l a d o del análisis.

Desarrollo de otro escenario de uso preliminar El e s c e n a r i o : Una sala d e la segunda ¡unta p a r a la recopilación

J a m i e : ¿Quién hace el papel del actor en esto? M o d e r a d o r : Creo q u e Meredith (una persona d e mercadotecnia) ha estado t r a b a j a n d o en e s a

s : Jamie Lazar, miembro del equipo d e Ed Robbins, miembro del equipo d e software; f, gerente d e ingeniería del software; tres d e mercadotecnia; un representante d e d e producto; y un moderador. —:¿n: n Es hora d s que comencemos a hablar de la función de vigilancia d e HogarSeguro. a desarrollar un escenario d e usuario p a r a el a la función d e seguridad en el hogar.

funcionalidad. ¿Por q u é no haces tó el papel? M e r e d i t h : ¿Quieres que lo h a g a m o s igual q u e la última vez, no es asi? M o d e r a d o r : Correcto... d e la misma forma. M e r e d i t h : Bueno, es obvio q u e la razón p a r a la vigilancia es permitir que el propietario esté pendiente d e la casa mientras él o ella están fuera, g r a b a r y

TM

reproducir videos q u e se hayan capturado... ese tipo d e

PDF Editor

10 Un actor no es una persona especifica, sino el papel que desempeña una persona (o dispositivo) dentro de un contexto específico. Un actor "llama al sistema para entregar uno de sus servicios" [COCOl], 11 Estas tareas de la ingeniería de requisitos se examinan con detalle en el capítulo 7.

204

PARTE DOS


E d : ¿El video será digital y se almacenará en disco?

movimiento y los acercamientos d e una c á m a r a

M o d e r a d o r : Buerva pregunta, pero por a h o r a

específica. Especifico la c á m a r a seleccionada desde el plano d e la c a s a. Quiero g r a b a r y reproducir la salida

pospongamos los aspectos d e implementación. ¿Meredith?

¡V

M e r e d i t h : De acuerdo, entonces básicamente hay dos partes p a r a la función de vigilancia... la primera configura el sistema, incluyendo el establecimiento de un piano d e la c a s a -necesitamos herramientas q u e ayuden ol propietario a hacerlo- y la segunda parte es la función d e vigilancia real en sí misma. Como el establecimiento

d e las c á m a r a s d e m a n e r a selectiva. Tombión quiero ser c a p a z d e bloquear el acceso o une o más c á m a r a s con una contraseña específica. Y quiero la opción d e ver pequeñas ventanas q u e muestren vistas d e todas las c á m a r a s y después ser c a p a z d e seleccionar la que quiero destacar. J a m i e : Esas se llaman vistas en miniatura.

del plano es parte d e la actividad d e configuración, me

M e r e d i t h : Bien, entonces quiero vistas en miniatura de

enfocaré en la función d e vigilancia.

todas los cámaras. También quiero q u e la interfaz con le

M o d e r a d o r ( s o n r i e n d o ) : Me quitaste las p a l a b r a s

función d e vigilancia tenga la misma apariencia que

d e Id boca.

todas las otras interfases d e HogarSoguro.

•>'

s

'

M e r e d i t h : Mm... Quiero tener acceso a la función d e vigilancia, ya sea o través d e la PC o d e Internet. Siento

Quiero q u e

sea intuitiva; es decir, q u e h ó s e a necesario leer un manual p a r a poder usarla.

/

B U »

q u e el acceso por Internet sería el d e uso más frecuente.

M o d e r a d o r : Buen trabajo, a h o r a entremos en esta

De cualquier manera, quiero ser c a p a z d e desplegar

función con un poco más de detalle. ..

vistas d e las c á m a r a s en una PC y controlar el

¡11®

La función d e vigilancia en el h o g a r d e HogarSeguro

q u e s e e x a m i n a en el r e c u a - 1

dro identifica las siguientes f u n c i o n e s (una lista abreviada) q u e realiza el actor i d e r - l tificado c o m o p r o p i e t a r i o d e l a c a s a : • Tener a c c e s o a la c á m a r a d e vigilancia vía Internet. • Seleccionar la c á m a r a q u e d e s e a ver. • Solicitar vistas en miniatura d e t o d a s las c á m a r a s . • Desplegar vistas d e la c á m a r a en u n a v e n t a n a d e u n a PC. • Controlar la visión p a n o r á m i c a y d e a c e r c a m i e n t o en u n a c á m a r a específica • Registrar en f o r m a selectiva la salida d e c á m a r a . • Repetir la salida de c á m a r a . C o n f o r m e s e realizan las c o n v e r s a c i o n e s posteriores c o n el i n t e r e s a d o (quiesl d e s e m p e ñ a el papel d e un propietario), el e q u i p o d e recopilación d e requisitos desarrolla c a s o s d e u s o p a r a c a d a u n a de las f u n c i o n e s m e n c i o n a d aTM s . En general, 1:s c a s o s d e u s o s e escriben p r i m e r o en un estilo narrativo informal. Si se requiere' mayor formalidad s e rescribe el m i s m o c a s o d e u s o utilizando un f o r m a t o estructu-

PDF Editor

r a d o similar al p r o p u e s t o en el capítulo 7 y reproducido en e s t a sección c o m o i r a recuadro.

Con fines ilustrativos, c o n s i d é r e s e la función " a c c e s o a c á m a r a de vigilancia-des-

pliegue d e vistas de c á m a r a (ACV-DVC)". El i n t e r e s a d o q u e d e s e m p e ñ a el p a p e l e s p r o p i e t a r i o podría escribir el siguiente relato:

CAPÍTULO 8

205


Caso de uso: A c c e s o a cámara de vigilancia-despliegue de vistas de cámara (ACV-DVC) Actor: propietario Si me encuentro en un lugar lejano puedo usar una PC con un software de navegación apropiado para entrar al sitio web de los productos HogarSeguro. Ingreso mi clave de usuario y dos niveles de contraseñas y, después de que estoy validado, tengo acceso a toda la funcionalidad de mi sistema HogarSeguro instalado. Para tener acceso a la vista de una cámara específica selecciono "vigilancia" de los botones desplegados para las funciones más importantes. Después escojo "seleccionar una cámara" y se despliega un plano de planta de la casa. Entonces selecciono la cámara en la que estoy interesado. En forma alterna, puedo ver simultáneamente una lista con vistas en miniatura de todas las cámaras al seleccionar "todas las cámaras" como mi opción de visualización. Una vez que he seleccionado una cámara, selecciono "vista" y una vista de un cuadro por segundo aparece en una ventana, a la cual identifica la cámara clave. Si quiero cambiar de cámara, elijo "seleccionar una cámara" y la ventana de visión original desaparece y se despliega de nuevo el plano de planta de la casa. Una v a r i a c i ó n del c a s o de u s o r e l a t a d o p r e s e n t a la i n t e r a c c i ó n c o m o u n a s e c u e n c i a o r d e n a d a d e l a s a c c i o n e s del u s u a r i o . C a d a a c c i ó n s e r e p r e s e n t a c o m o u n e n u n c i a d o d e c l a r a t i v o . D e s p u é s d e visitar la f u n c i ó n ACV-DVC, s e p u e d e escribir: Caso de uso: A c c e s o a cámara de vigilancia-despliegue de vistas de cámara (ACV-DVC) Actor: propietario 1. El propietario entra en el sitio Web de HogarSeguro. 2. El propietario introduce su clave de usuario. 3. El propietario introduce dos contraseñas (cada una de al menos ocho caracteres). 4. El sistema despliega todos los botones de las funciones más importantes. 5. El propietario selecciona "vigilancia" de los botones de funciones más importantes. 6. El propietario elige "seleccionar una cámara". 7. El sistema despliega el plano de planta de la casa. 8. El propietario selecciona un icono de cámara del plano de planta. 9. El propietario selecciona el botón "vista". 10. El sistema despliega una ventana de visión, identificado por la clave de la cámara. 11. El sistema muestra salida de video dentro de la ventana de visión con una velocidad de un marco por segundo. Es i m p o r t a n t e d e s t a c a r q u e e s t a p r e s e n t a c i ó n s e c u e n c i a l n o c o n s i dTM e r a a l g u n a s inter a c c i o n e s a l t e r n a t i v a s (la n a r r a t i v a t i e n e u n flujo m á s libre y r e p r e s e n t a u n a s c u a n t a s a l t e r n a t i v a s ) . Los c a s o s d e u s o de e s t e t i p o s e r e f i e r e n a l g u n a s v e c e s c o m o esce-

PDF Editor narios primarios

[SCH98].

"Los cosos d e uso pueden usarse en muchos procesos [de software]. Nuestro favorito es un proceso que seo iterativo y conducido por el riesgo." Geri Schneider y Jason Winters

206

PARTE DOS


Por supuesto, para una comprensión completa de la función que se pretende cribir es esencial u n a descripción de las interacciones alternativas. Por lo tanto, p a s o e n el escenario primario se evalúa realizando las siguientes preguntas [SC ¿Cómo se

•

examinan

cursos alternativos de acción mientras se desarrolla un caso de uso?

• ¿El acto p u e d e ejecutar otra acción en este punto? • ¿Es posible que el actor encuentre alguna condición de error en este punte es así, ¿cuál podría ser? • ¿Es posible que el actor e n c u e n t r e algún otro c o m p o r t a m i e n t o provocado algún e v e n t o fuera de su control? Si es así, ¿cuál podría ser? El resultado de las r e s p u e s t a s a e s t a s preguntas es la creación de un conjunte escenarios secundarios que son parte del c a s o de uso original, p e r o que represe c o m p o r t a m i e n t o s alternativos. Por ejemplo, considérense los p a s o s 6 y 7 en el escenario primario presen líneas atrás: 6. El propietario elige "seleccionar una cámara". 7. El sistema despliega el plano de planta de la casa. ¿El actor puede ejecutar otra acción en este punto? La respuesta es: "sí". Con refe cia al relato de flujo libre, el actor p u e d e elegir ver las vistas e n miniatura de t<~ las c á m a r a s de m a n e r a simultánea. Por ende, un escenario secundario podría "Ver las vistas en miniatura de t o d a s las cámaras". ¿Es posible que el actor encuentre alguna condición de error en este punto? C un sistema b a s a d o en c o m p u t a d o r a está en funcionamiento p u e d e ocurrir cualq cantidad de condiciones de error. En este contexto se consideran sólo las condicion e s de error que pueden ocurrir c o m o resultado directo de las acciones descritas e r los p a s o s 6 o 7. De nuevo, la respuesta a la pregunta es: "sí". Puede ser que nunca se haya configurado un p l a n o de planta con iconos de las c á m a r a s . Por lo tanto, 5_ elegir "seleccionar u n a c á m a r a " se produce una condición de error: "no existe un plano de planta configurado para esta casa". 1 2 Esta condición de error se convierte e n un escenario secundario. ¿Es posible que el actor encuentre

algún otro comportamiento

en este punto? De

nuevo, la respuesta a la pregunta es: "si". Cuando se realizan los p a s o s 6 y 7 el sistema p u e d e e n c o n t r a r u n a condición de alarma. Esto podría resultar en que el sistem a desplegara una notificación especial de alarma (tipo, ubicación, acción del sistema) y le proporcione al actor una serie de opciones relacionadas con TM la naturaleza de la alarma. Como este escenario secundario p u e d e ocurrir para casi t o d a s las interacciones, n o se convertirá en u n a parte del c a s o de uso para el ACV-DVC. Er

PDF Editor

12 En este caso, otro actor, el administrador del sistema, tendría que configurar el plano de planta, instalar e inicializar (es decir, asignar una ID a cada equipo) para todas las cámaras, así como realizar pruebas para estar seguro de que cada una de ellas es accesible por medio del sistema y a través del plano de planta.

CAPÍTULO 8


207

vez de eso, se desarrollará un caso de uso por separado —"condición de alarma encontrada"—, el cual estará referenciado a otros casos de uso, según se requiera. En relación con las plantillas formales para los casos de uso que se muestran en el recuadro, los escenarios secundarios se representan como excepciones a la secuencia básica descrita respecto al ACV-DVC.

HOGARSEGURO

Plantilla de caso de uso para 1a vigilancia C a s o d e uso: Acceso o la c á m a r a d e vigilancia-despliegue de vistas d e c á m a r a (ACV-DVC). Propietario en contexto!

!

Ver la salida d e las c á m a r a s colocadas a lo largo d e la casa d e s d e cualquier ubicación remota a través d e I

, previas: El sistema se d e b e configurar por completo; se deben obtener ID y contraseñas a p r o p i a d a s para los usuarios. Ei propietario decide echarle un vitazo a su c a s a mientras se encuentra fuera de ella.

11. El sistema despliega la salida d e video dentro d e ta ventana d e visualización a un cuadro por segundo. Excepciones: 1. La ID o las contraseñas son incorrectos o n o se reconocen; véase el caso d e uso: "validar ID y contraseñas". 2. La función d e vigilancia no está configurada p a r a este sistema, así que el sistema despliega el mensaje de error apropiado; véase el caso d e uso: "configurar la función d e vigilancia". 3. El propietario selecciona "Ver vistas en miniatura p a r a todas las cámaras"; véase el caso d e uso: "Ver vistas en miniatura p a r a todas las cámaros". 4. N o está disponible un plano d e planta o éste n o se ha configurado, asi q u e el sistema despliega el

El propietario entra al sitio web d e Producios HogarSeguro. 2 El propietario introduce su ID d e usuario, i i

El propietario introduce dos contraseñas (cada una

5. Se encuentra una condición d e alarma; véase el caso d e uso: "condición d e alarma encontrada". Prioridad:

Prioridad m o d e r a d a , q u e se

d e al menos ocho caracteres).

implementará después d e las

El sistema despliega todos los botones d e las

funciones básicas.

funciones más importantes.

Disponible en:

El tercer incremento.

El propietario selecciona "vigilancia" de los botones

Frecuencia d e uso:

Poco frecuente.

d e las funciones más importantes. 6

mensaje d e error apropiado; véase ei caso d e uso "configurar plano d e la casa".

Canal hacia el actor: A través d e un browser b a s a d o en

El propietario selecciona "escoger una cámara".

PC y conexión de Internet al sitio

El sistema despliega el plano de la casa.

TM web d e HogarSeguro.

8. El propietario selecciona el icono de una c á m a r a del plano d e planta.

Actores secundarios: Administrador del sistema, cámaras.

PDF Editor ;

El propietario selecciona el botón "vista".

0

El sistema despliega una ventana d e visualización

q u e está identificada con la ID d e la c á m a r a .

Canales hacia los actores secundarios:

1. Administrador del sistema: sistema b a s a d o en PC.

2. Cámaras: conectividad inalámbrica

208

PARTE D O S


Aspectos pendientes:

3. ¿La respuesta del sistema vio Internet será aceptable

1. ¿Cuál es el mecanismo q u e protege contra el uso no

d a d o el a n c h ó d e b a n d a requerido p a r a fas vistas de cámara?

autorizado d e esta c a p a c i d a d por parte d e los empleados d e la c o m p a ñ í a ?

I

4. ¿Se desarrollará una c a p a c i d a d p a r a proporciona'

2. ¿La seguridad es suficiente? El ingreso no autorizado

video a una tasa mayor d e cuadros por segundo

en esta característica representaría una invasión

c u a n d o estén disponibles conexiones con mayor

importante d e la privacidad.

ancho de banda?

9

En m u c h o s c a s o s no es necesario crear u n a representación gráfica de un e s c e r ; ¿Cuándo se han ; temiirado j e estribillos cosos do usó? Para uno exposiítón valiosa de este tópico, véase

rio de uso. Sin embargo, la representación diagramática p u e d e facilitar la compren-

ootips.org/

óvalo. En esta sección sólo se ha e x a m i n a d o en detalle el c a s o de uso para el ACV-

use-tases-done. htmfootips.org/ use-cases-done. html

sión, en particular c u a n d o el escenario e s complejo. C o m o se m e n c i o n ó en el car tulo 7, el UML proporciona u n a capacidad para hacer diagramas d e c a s o s de uso preliminar para el producto HogarSeguro. Cada c a s o de u s o s e representa mediante l - 1 DVC.

8.5.2 Desarrollo de un diagrama de actividad El diagrama de actividad en UML (que se trató en forma breve en los capítulos 6 y 7 complementa el caso de uso al proporcionar una representación gráfica del flujo de inte racción dentro de un escenario específico. De m a n e r a similar al d i a g r a m a de fluj: un diagrama de actividad utiliza rectángulos r e d o n d e a d o s para indicar una funcicespecífica del sistema, flechas para representar el flujo a través del sistema, romb> s de decisión p a r a mostrar una ramificación por decisión (cada flecha que sale de r o m b o se etiqueta), y líneas horizontales sólidas para indicar q u e ocurren actividad e s paralelas.

Diagrama preliminar de caso de uso para el sistema HogarSeguro.

HogarSeguro

TM

PDF Editor

CAPÍTULO 8

209


a de / introducir c o n t r a s e ñ a ^ e ID del usuario J

de a la de

C o n t r a s e ñ a s / I D válidas

e •retas d e

También se pueden seleccionar otras funciones

Contraseñas/1 D no válidos

" Seleccionar u n a \ ( funciónîmportante/ \

Opción p a r a \ reingreso J Restan intentos de entrada

Seleccionar / N o restan intentos d e e n t r a d a

Seleccionar una c á m a r a específica Seleccionar una cámara i en miniatura

Seleccionar un ¡cono

)

la salida d e una c á m a r a en una ventana •

C

Opción p a r a otra vista

Salir d e esta función

) Ver otra c á m a r a

En la figura 8.7 s e m u e s t r a u n d i a g r a m a d e actividad p a r a la f u n c i ó n de ACVDVC. Se d e b e r e s a l t a r q u e el d i a g r a m a d e actividad a g r e g a d e t a l l e s a d i c i o n a l e s q u e

(CLAVE de enUML te acciones que rtrasse función.

n o s e m e n c i o n a n d e m a n e r a directa (pero sí implícita) e n el c a s o d e u s o . Por e j e m plo, u n u s u a r i o p u e d e i n t e n t a r i n g r e s a r la I D u s u a r i o y la c o n t r a s e ñ a s ó l o u n n ú m e r o l i m i t a d o d e v e c e s . E s t o s e r e p r e s e n t a m e d i a n t e un r o m b o d e d e c i s i ó n d e b a j o d e opción para reingreso.

TM

8.5.3 Diagramas de carril

PDF Editor El diagrama

de carril d e UML e s u n a v a r i a c i ó n útil del d i a g r a m a d e actividad, y a q u e

p e r m i t e al m o d e l a d o r la r e p r e s e n t a c i ó n del flujo d e a c t i v i d a d e s d e s c r i t a s p o r el c a s o d e u s o y, al m i s m o t i e m p o , i n d i c a r q u é a c t o r (si h a y m ú l t i p l e s a c t o r e s i n v o l u c r a d o s e n u n a f u n c i ó n específica) o c l a s e d e a n á l i s i s t i e n e la r e s p o n s a b i l i d a d d e la a c c i ó n d e s c r i t a m e d i a n t e u n r e c t á n g u l o d e actividad. Las r e s p o n s a b i l i d a d e s s e r e p r e s e n t a n

PARTE D O S


Diagrama de carril para la función de A c c e s o a la c á m a r a de vigilancia-despliegue de vistas de cámara. Propietario

Cámara

Interfaz

Introducir contraseña e ID del usuario

(

C o n t r a s e ñ a s / I D válidas !ontraseñas/ID no válidas función importante

También se pueden seleccionar otras f Seleccionar vigilancia \ funciones N , J

Vistas en miniatura

ion p a r a reingreso Restan intentos \ d e entrada N o restan intentos d e entrada

Seleccionar una .cámara específica

;
Seleccionar un ¡cono d e c á m a r a

G e n e r a r salida d e video Vista d e salida d e c á m a r a en una ventana etiquetada

"\^

Opción p o r a otra vista

y

Salir d e _ e s t a función

<8>

* 4

C&VE Un diagrama de caniles en UML representa el flujo de los ocácnes y los derisones e indico a x f e s odores realizan r a l o uno de eSos.

Ver otra cámara

c o m o s e g m e n t o s p a r a l e l o s q u e dividen el d i a g r a m a e n f o r m a vertical, c o m o los caniles de una alberca.

TM

Existen tres c l a s e s d e análisis — P r o p i e t a r i o , I n t e r f a z y C á m a r a — c o n r e s p o n s a bilidades d i r e c t a s o indirectas e n el c o n t e x t o del d i a g r a m a de actividad r e p r e s e n t a d o

PDF Editor

e n la figura 8.7. R e s p e c t o d e la figura 8.8, el d i a g r a m a de actividad se r e o r g a n i z a de f o r m a q u e las act i vi dades a s o c i a d a s c o n u n a clase d e análisis particular p e r t e n e z c a n

al carril c o r r e s p o n d i e n t e a dicha clase. Por e j e m p l o , la clase I n t e r f a z r e p r e s e n t a la interfaz c o n el u s u a r i o d e a c u e r d o c o n la visión del propietario. El d i a g r a m a de activi d a d c o n s i d e r a d o s o p c i o n e s q u e s o n r e s p o n s a b i l i d a d d e la interfaz: opción para el rein

CAPÍTULO 8

211


greso y opción para otra vista. Estas o p c i o n e s y las d e c i s i o n e s a s o c i a d a s c o n ellas p e r t e n e c e n al carril d e I n t e r f a z . Sin e m b a r g o , las flechas c o n d u c e n d e s d e e s e carril d e r e g r e s o al carril de p r o p i e t a r i o , d o n d e o c u r r e n las a c c i o n e s del propietario.

¿ J L .

D E L A D Q OBI

AL F L U J O

El m o d e l a d o d e d a t o s o r i e n t a d o al flujo e s u n a d e las n o t a c i o n e s d e a n á l i s i s utilizad a s c o n m a y o r a m p l i t u d e n la a c t u a l i d a d . 1 3 A u n q u e el diagrama

de flujo de datos

(DFD) y los d i a g r a m a s y la i n f o r m a c i ó n r e l a c i o n a d o s n o s o n u n a p a r t e f o r m a l d e UML, p u e d e n utilizarse p a r a c o m p l e m e n t a r los d i a g r a m a s e n UML y p r o p o r c i o n a r un c o n o c i m i e n t o a d i c i o n a l d e los r e q u i s i t o s y el flujo del s i s t e m a . El DFD t i e n e u n a visión del s i s t e m a del tipo e n t r a d a - p r o c e s o - s a l i d a . E s t o e s , l o s o b j e t o s d e d a t o s fluyen h a c i a el interior del s o f t w a r e , s e t r a n s f o r m a n m e d i a n t e e l e m e n t o s d e p r o c e s a m i e n t o , y l o s o b j e t o s d e d a t o s r e s u l t a n t e s fluyen al e x t e r i o r del s o f t w a r e . Los o b j e t o s d e d a t o s s e r e p r e s e n t a n m e d i a n t e f l e c h a s r o t u l a d a s y las t r a n s f o r m a c i o n e s s e r e p r e s e n t a n p o r m e d i o d e círculos ( t a m b i é n l l a m a d a s burbujas).

El

DFD s e p r e s e n t a e n u n a f o r m a j e r á r q u i c a . E s t o e s , el p r i m e r m o d e l o d e flujo d e d a t o s ( a l g u n a s v e c e s l l a m a d o u n DFD de nivel 0 o diagrama

de contexto)

r e p r e s e n t a el sis-

t e m a c o m o un todo. Los d i a g r a m a s de flujo d e d a t o s s u b s e c u e n t e s r e f l n a n el d i a g r a m a d e c o n t e x t o , ya q u e p r o p o r c i o n a n u n a c a n t i d a d c r e c i e n t e de d e t a l l e s c o n c a d a nivel s u b s i g u i e n t e . "Ei propósito d e los diagramas de flujo d e datos es proporcionar un puente semántico entre los usuarios y los desabolladores de sistemas." Kenneth Rozar

8.6.1 Creación d e un modelo de flujo de datos

* xtsonas fie el DFD btiejo yqueno enla mderno. i visión que a forma de •t potenúlU ol nivel Si es de •recomiendo el DFD.

El d i a g r a m a d e f l u j o d e d a t o s p e r m i t e q u e el i n g e n i e r o d e s o f t w a r e d e s a r r o l l e m o d e los del d o m i n i o d e i n f o r m a c i ó n y del d o m i n i o f u n c i o n a l al m i s m o t i e m p o . A m e d i d a q u e el DFD s e r e f i n a h a c i a g r a d o s m a y o r e s d e detalle, el a n a l i s t a d e s e m p e ñ a u n a d e s c o m p o s i c i ó n f u n c i o n a l implícita del s i s t e m a . Al m i s m o t i e m p o , el r e f i n a m i e n t o del DFD r e s u l t a e n u n c o r r e s p o n d i e n t e r e f i n a m i e n t o d e d a t o s m i e n t r a s s e m u e v e h a c i a los p r o c e s o s q u e i n c o r p o r a n la a p l i c a c i ó n U n a s p o c a s d i r e c t r i c e s s i m p l e s p e r m i t e n o b t e n e r u n a a y u d a i n v a l u a b l e d u r a n t e la c r e a c i ó n d e u n d i a g r a m a d e flujo d e d a t o s : 1) el nivel 0 del d i a g r a m a de flujo d e d a t o s

TM

d e b e r e p r e s e n t a r al s o f t w a r e / s i s t e m a c o m o u n a s o l a b u r b u j a ; 2) la e n t r a d a y la salid a p r i m a r i a d e b e n e s t a b l e c e r s e c o n c u i d a d o ; 3) la r e f i n a c i ó n d e b e c o m e n z a r p o r el aislamiento de procesos, objetos de datos y almacenamientos de datos candidatos a

PDF Editor

s e r r e p r e s e n t a d o s e n el s i g u i e n t e nivel; 4) t o d a s l a s flechas y b u r b u j a s s e d e b e n r o t u lar c o n n o m b r e s significativos; 5) s e d e b e m a n t e n e r la c o n t i n u i d a d del flujo de infor-

13 El modelo de flujo de datos es una actividad de modelado esencial en el análisis estructurado.

212

PARTE D O S


DFD al nivel de contexto para la función de seguridad de HogarSeguro.

mación al cambiar de nivel a nivel; 14 y 6) la refinación de las b u r b u j a s d e b e hacerse u n a por una. Existe u n a tendencia natural a complicar de m á s el diagrama de fin;: de datos. Esto ocurre c u a n d o el analista intenta mostrar m u c h o s detalles demasiado pronto o representar aspectos de procedimiento del s o f t w a r e e n lugar de ele m e n t o s del flujo de información. El uso del DFD y de la notación relacionada se ilustra de n u e v o considerando la función de seguridad en el hogar de HogarSeguro.

En la figura 8.9 se muestra un DFC

al nivel de contexto para la función de seguridad. Las entidades externas primarias (cajas) producen información para el uso del sistema y c o n s u m e n información que éste genera. Las flechas rotuladas r e p r e s e n t a n objetos de d a t o s o jerarquías de obje-

\

tos de datos. Por ejemplo, c o m a n d o s y d a t o s del u s u a r i o abarcan todos los c o m a n d o s de configuración, todos los c o m a n d o s de activación/desactivación, todas

CLAVE

las interacciones y todos los d a t o s que se ingresan para calificar o expandir un comando.

la continuidad del flu¡o de información debe mantenerse conforme se refina cada nivel del DFD. Esto significa que lo entrada y salida en un nivel deben ser los mismas que la entrada y salida en un nivel refinado.

El DFD de nivel 0 a h o r a se e x p a n d e a un modelo de flujo de d a t o s de nivel 1. ¿Pero c ó m o se logra esto? Un e n f o q u e simple, pero efectivo, es realizar un "análisis gramatical" [ABB83] sobre la narrativa que describe la burbuja al nivel de contexto. Esto es, se aislan todos los sustantivos y verbos en la narrativa de procesamiento HogarSeguro15

de

obtenida durante la primera reunión para la recopilación de requisi-

tos. Con propósitos ilustrativos, considérese el siguiente texto narrativo de procesam i e n t o con la primera aparición de t o d o s los sustantivos s u b r a y a d o s y la primera aparición de todos los verbos en itálicas. 16

14 Esto es, los objetos de datos que Huyen hacia el sistema o cualquier transformación TM en algún nivel, deben ser los mismos objetos de datos (o sus partes constituyentes) que fluyen hacia la transformación en un nivel más refinado. 15 Una narrativa del procesamiento es similar en estilo al caso de uso, pero algo diferente en propósito. La narrativa del procesamiento proporciona una descripción general de la función que será desarrollada. No es un escenario escrito desde el punto de vista de alguno de los actores. 16 Debe notarse que se omiten los sustantivos o verbos que son sinónimos o que no tienen una ingerencia directa en el proceso de modelación. También se debe notar que, cuando se considere el modelado basado en clases de la sección 8.7, se usará un análisis gramatical similar.

PDF Editor

CAPÍTULO 8

213


La función de seguridad de HogarSeguro permite al propietario configurar el sistema de ses gramatical ide i xw puede run t paso inicial : inste alguna i pora definir E X datos y las sque i ellos.

guridad cuando éste se instala, monitorear todos los sensores que se conectan al sistema de seguridad y que interactúan con el propietario a través de Internet una PC o un panel de control. Durante la instalación, la PC de HogarSeguro se utiliza para programar y configurar el sistema. A cada sensor se le asigna un número y lipa, se programa una contraseña maestra para habilitar o deshabilitar el sistema, y algunos números telefónicos ingresan para marcarse cuando se presenta un evento en los sensores. Cuando se reconoce un evento en los sensores, el software solicita una alarma audible que el propietario especifica durante las actividades de configuración del sistema, el software marca el número telefónico de un servicio de monitoreo. proporciona información acerca de la ubicación, reporta la naturaleza del evento que se ha detectado. El número telefónico se remarca cada 20 segundos hasta que se obtiene una conexión telefónica. El propietario recibe información de seguridad a través de un panel de control, la PC o un buscador que en forma colectiva se denomina una interfaz La interfaz despliega mensajes de opción e información del estatus del sistema en el panel de control, la PC o la ventana del buscador. La interacción del propietario asume la siguiente forma... En r e l a c i ó n c o n el a n á l i s i s g r a m a t i c a l c o m i e n z a a surgir u n p a t r ó n . Los v e r b o s s o n los p r o c e s o s d e HogarSeguro-,

e s t o e s , al final p u e d e n r e p r e s e n t a r s e c o m o b u r b u j a s

e n u n DFD s u b s e c u e n t e . Los s u s t a n t i v o s s o n e n t i d a d e s e x t e r n a s (cajas), o b j e t o s d e d a t o s o d e c o n t r o l (flechas), o a l m a c e n a m i e n t o s d e d a t o s (líneas dobles). D e s p u é s d e b e o b s e r v a r s e q u e los s u s t a n t i v o s y v e r b o s se p u e d a n a s o c i a r d e d i s t i n t a s f o r m a s

t de nivel 1 i Va función i seguridad de

TM

PDF Editor

214

PARTE D O S


DFD d e nivel 2 que refina el proceso de monitoreo d e sensores.

Formato p a r a el despliegue

Generar señal de alarma

Información d e configuración Datos d e configuración

ubicación del sensor Evaluar contra ifiguración

Leer sensores

alarma

'Dalos d e alarma

ID, tipo d e sensor

Estatus el sensor

^CQNSEJoffi

Información del sensor

Número telefónico

Marcar teléfono

Tonos d e números telefónicos

entre sí. Por ejemplo, a cada sensor se le asigna un n ú m e r o y un tipo; por lo tanto, el número y el tipo son atributos del objeto de d a t o s s e n s o r . Entonces, al realizar ur

Se debe tenerla segundad de que loda

análisis gramatical sobre la narrativa de p r o c e s a m i e n t o para u n a burbuja en cual-

lo narrativa de proce-

ceder con la refinación para el siguiente nivel. En la figura 8.10 se presenta un DFD

samiento que se

quier nivel del DFD, se p u e d e generar m u c h a información útil acerca de c ó m o pro-

intento analizar está

de nivel 1 para el cual se h a utilizado esta información. El p r o c e s o al nivel de con-

escrita con el mismo

texto mostrado en la figura 8.9 se ha expandido a seis procesos obtenidos de un exa-

grado de abstracción.

men del análisis gramatical. De m a n e r a similar, el flujo de información entre los procesos en el nivel 1 h a sido obtenido del análisis. Además, se m a n t i e n e la continuidad del flujo de información entre los niveles 0 y 1. Los procesos r e p r e s e n t a d o s en el DFD de nivel 1 se refinan d e s p u é s hacia niveles m á s bajos. Por ejemplo, es posible refinar el proceso monitorear

sensores hacia ur.

DFD de nivel 2 c o m o se muestra en la figura 8.11. De nuevo, d e b e señalarse que se m a n t i e n e la continuidad del flujo de información entre los niveles. La refinación de los DFD continúa hasta que cada burbuja realiza u n a sola función; es decir, hasta que el proceso que representa la burbuja d e s e m p e ñ e u n a función que podría implementarse con facilidad c o m o un c o m p o n e n t e de TM programa. En e capítulo 9 se e x a m i n a un concepto, llamado cohesión, con el cual se evalúa la simplicidad de u n a función dada. Por a h o r a , se busca refinar los DFD hasta que cada burbuja tenga "un solo significado".

PDF Editor 8.6.2 Creación de un modelo de control del flujo

En m u c h o s tipos de aplicaciones el modelo de d a t o s y el diagrama de flujo de datos son todo lo que se necesita para obtener u n a visión significativa de los requisitos de'.

CAPÍTULO 8

215


s o f t w a r e . Sin e m b a r g o , c o m o y a se h a m e n c i o n a d o , existe u n a c l a s e m u y g r a n d e d e a p l i c a c i o n e s q u e e s t á n g u i a d a s p o r e v e n t o s e n l u g a r de d a t o s , q u e p r o d u c e n inform a c i ó n d e control e n l u g a r d e r e p o r t e s o d e s p l i e g u e s , y q u e p r o c e s a n i n f o r m a c i ó n c o n u n e s p e c i a l i n t e r é s p o r el t i e m p o y el r e n d i m i e n t o . D i c h a s a p l i c a c i o n e s r e q u i e r e n aplicar el modelado

de control del flujo, a d e m á s del m o d e l a d o del f l u j o d e d a t o s .

Ya s e h a m e n c i o n a d o q u e un e v e n t o o e l e m e n t o d e c o n t r o l s e i m p l e m e n t a c o m o u n valor b o o l e a n o (por e j e m p l o , v e r d a d e r o o falso, e n c e n d i d o o a p a g a d o , I o 0) o u n a lista d i s c r e t a de c o n d i c i o n e s (vacío, s a t u r a d o , lleno). En la s e l e c c i ó n de los e v e n t o s q u e s o n c a n d i d a t o s p o t e n c i a l e s se s u g i e r e n l a s s i g u i e n t e s directrices: \ ¿C""0

se

• Hacer u n a lista d e t o d o s los s e n s o r e s q u e el s o f t w a r e "lee". • Listar t o d a s las c o n d i c i o n e s d e i n t e r r u p c i ó n . • Listar t o d o s los " i n t e r r u p t o r e s " q u e m a n e j a u n o p e r a d o r . • Listar t o d a s las c o n d i c i o n e s de d a t o s . • D e a c u e r d o c o n el a n á l i s i s d e s u s t a n t i v o s y v e r b o s a p l i c a d o a la n a r r a t i v a de p r o c e s a m i e n t o , revisar t o d o s los " e l e m e n t o s d e c o n t r o l " c o m o p o s i b i l i d a d e s d e e n t r a d a s y s a l i d a s del control d e flujo. • Describir el c o m p o r t a m i e n t o de u n s i s t e m a m e d i a n t e la identificación d e s u s e s t a d o s ; d e t e r m i n a r el g r a d o e n el q u e se a l c a n z a c a d a e s t a d o , y definir las t r a n s i c i o n e s e n t r e los e s t a d o s . • E n f o c a r s e e n p o s i b l e s o m i s i o n e s —un e r r o r m u y c o m ú n al e s p e c i f i c a r el control—; por e j e m p l o , se p u e d e p r e g u n t a r : "¿existe a l g u n a o t r a m a n e r a d e a l c a n z a r e s t e e s t a d o o salir de él?".

8.6.3 Especificación de control La especificación

de control

(EC) r e p r e s e n t a el c o m p o r t a m i e n t o del s i s t e m a (en el

nivel d e s d e el c u a l e s t á referido) d e d o s m a n e r a s d i f e r e n t e s . 1 7 La EC c o n t i e n e u n d i a g r a m a d e e s t a d o q u e e s u n a e s p e c i f i c a c i ó n s e c u e n c i a ! del c o m p o r t a m i e n t o . T a m b i é n p u e d e c o n t e n e r u n a t a b l a d e a c t i v a c i ó n del p r o g r a m a : u n a e s p e c i f i c a c i ó n c o m b i n a toria del c o m p o r t a m i e n t o . En la figura 8.12 s e m u e s t r a un d i a g r a m a d e e s t a d o p r e l i m i n a r 1 8 p a r a el m o d e l o d e control del flujo e n el nivel I p a r a HogarSeguro.

El d i a g r a m a indica c ó m o r e s p o n d e

el s i s t e m a a d i f e r e n t e s e v e n t o s c o n f o r m e é s t e a t r a v i e s a los c u a t r o e s t a d o s d e f i n i d o s e n e s t e nivel. Al r e v i s a r el d i a g r a m a d e e s t a d o , un i n g e n i e r o de TM software puede d e t e r m i n a r el c o m p o r t a m i e n t o del s i s t e m a y, a ú n m á s i m p o r t a n t e , p u e d e e n c o n t r a r si existen " h o y o s " en el c o m p o r t a m i e n t o e s p e c i f i c a d o .

PDF Editor

17 Después, en este mismo capítulo, se presenta notación adicional para el modelado del comportamiento. 18 La notación para el diagrama de estado se muestra aquí de conformidad con la notación del UML. En el análisis estructurado se cuenta con un "diagrama de transición de estado", pero el formato del UML es superior en contenido y representación de información

216

PARTE DOS

P R Á C T I C A DE L A INGENIERÍA DEL S O F T W A R E

Diagrama de estado para la función de seguridad de HogarSeguro.

sensorDisparodo/ reinicioTemporizador

Por ejemplo, el diagrama de e s t a d o (figura 8.12) indica que las transiciones d e s c ; el e s t a d o desocupado

pueden ocurrir si el sistema se reinicia, activa o apaga. Si el sis-

t e m a se activa (es decir, se enciende el sistema de alarma) ocurre u n a transiciór hacia el e s t a d o MonitoreoEstatusSistema,

los m e n s a j e s que se despliegan cambian,

c o m o se muestra, y se solicita el proceso SistemaControfyMonitoreo.

Con el estadc

Monitoreo Stratus Sistema ocurren dos transiciones: 1) al desactivar el sistema se presenta u n a transición de regreso al e s t a d o desocupado;

2) c u a n d o se dispara u n ser -

sor ocurre u n a transición hacia el estado AcciónEnAIarma.

Durante la revisión se

consideran t o d a s las transiciones y el contenido de todos los estados. HOGARSEGURO

Modelado del flujo de datos H e s c e n a r i o : Cubículo de Jamie,

TM La conversación:

PDF Editor ! q u e ha concluido la última reunión p a r a la

(Jamie ha bosquejado los modelos que se muestran en

-ecopiiación d e requisitos.

las figuras 8.9, 8 . 1 0 , 8.11 y 8 . 1 2 y se los muestra a Ed y

Los a c t o r e s : Jamie, Vinod y Ed, miembros del equipo

Vinod).

óe ingeniería de! software d e HogarSeguro.

J a m i e : Tomé un curso de ingeniería del software en la universidad, y ahí aprendi estas cosas. El profesor dijo

CAPITULO 8


estó un poco p a s a d o d e m o d a , pero ¿saben Me a y u d a a clarificar las cosas.

217

Ed: ¿De verdad? J a m i e : Sí, pero primero debemos desarrollar un modelo

Es genial. Pero aquí n o veo ninguna ciase ni ningún

d e análisis completo, y éste n o lo es. V i n o d : Bueno, es un primer paso. Pero vamos a tener

esto e s sólo un modelo d e flujo con algunos d e comportamiento incluidas. ¿Entonces, estos DFD representan una visión E-Piottware, no? ¿E-P-S?

q u e a b o r d a r elementos b a s a d o s en clases y también aspectos del comportamiento, a u n q u e este d i a g r a m a d e estado hace algo d e eso. Ed: Tenemos mucho trabajo por hacer y no mucho tiempo p a r a hacerlo,

Entrada-proceso-salida. En realidad los DFD son ... Si los observas por un momento, la forma en q u e los objetos fluyen a través del y cómo éstos se transforman. como si pudiéramos convertir c a d a burbuja componente ejecutable... al menos en el nivel más del DFD.

(Doug -el gerente d e ingeniería del software- entra en el cubículo.) D o u g : Entonces, ¿los primeros días estarán dedicados al desarrollo del modelo d e análisis, eh?

Jamie (con orgullo): Ya comenzamos. D o u g : Bien, tenemos mucho t r a b a j o por hacer y n o mucho tiempo p a r a hacerlo.

Esa es la mejor parte, sí se puede. De hecho, forma d e traducir los DFD a una arquitectura

(Los tres ingenieros d e software se miran entre sí y sonríen.)

La EC d e s c r i b e e! c o m p o r t a m i e n t o del s i s t e m a , p e r o n o b r i n d a i n f o r m a c i ó n a c e r c a del t r a b a j o interior d e los p r o c e s o s q u e a c t i v a . La n o t a c i ó n d e m o d e l a d o q u e p r o p o r c i o n a e s t a i n f o r m a c i ó n se e s t u d i a e n la s e c c i ó n 8.6.4.

8.6.4 Especificación d e proceso La especificación

de proceso

(EP) s e utiliza p a r a describir t o d o s los p r o c e s o s del

m o d e l o d e flujo q u e a p a r e c e n e n el nivel final d e r e f i n a c i ó n . El c o n t e n i d o d e la e s p e cificación d e p r o c e s o p u e d e incluir texto n a r r a t i v o , u n a d e s c r i p c i ó n e n l e n g u a j e d e d i s e ñ o d e p r o g r a m a s (LDP) 19 del a l g o r i t m o del p r o c e s o , e c u a c i o n e s m a t e m á t i c a s , t a b l a s , d i a g r a m a s o g r á f i c a s . Al p r o p o r c i o n a r u n a EP p a r a a c o m p a ñ a r c a d a b u r b u j a e n el m o d e l o d e flujo, el i n g e n i e r o d e s o f t w a r e c r e a u n a " m i n i e s p e c i f i c a c i ó n " q u e p u e d e servir c o m o guía p a r a el d i s e ñ o del c o m p o n e n t e del s o f t w a r e q u e i m p l e m e n t a r á el p r o c e s o . Para ilustrar el u s o d e la EP, c o n s i d é r e s e la t r a n s f o r m a c i ó n procesamiento traseña r e p r e s e n t a d a e n el m o d e l o d e flujo p a r a HogarSeguro

de con-

(figura TM 8.10). La EP p a r a

e s t a f u n c i ó n p o d r í a t o m a r la f o r m a :

PDF Editor

EP: procesamiento de contraseña (en el panel de control). La transformación procesamiento de contraseña valida la contraseña en el panel de control para la función de se-

19 El lenguaje de diseño de programas (LDP) mezcla la sintaxis del lenguaje de programación con la narrativa en texto para proporcionar detalles del diseño del procedimiento. El LDP se estudia en el capítulo 11.

218

PARTE DOS


g u r i d a d d e HogarSeguro.

El procesamiento

de contraseña

d í g i t o s a partir d e la f u n c i ó n d e interacción

con el usuario.

recibe una contraseña de cuatro La c o n t r a s e ñ a s e c o m p a r a pri-

m e r o c o n la c o n t r a s e ñ a m a e s t r a a l m a c e n a d a e n el s i s t e m a . Si la c o n t r a s e ñ a m a e s t r a c o i n c i d e [ M e n s a j e d e ID v á l i d a = v e r d a d e r o ] s e p a s a a la f u n c i ó n d e mensaje estatus.

y despliegue

del

Si la c o n t r a s e ñ a m a e s t r a n o coincide, s e c o m p a r a n los c u a t r o dígitos c o n u n a ta-

bla d e c o n t r a s e ñ a s s e c u n d a r i a s ( é s t a s s e p u e d e n a s i g n a r a i n v i t a d o s o t r a b a j a d o r e s q u e n e c e s i t a n e n t r a r en la c a s a c u a n d o el p r o p i e t a r i o n o e s t é ) . Si la c o n t r a s e ñ a c o i n c i d e c o n a l g u n a e n t r a d a d e n t r o d e la tabla ( m e n s a j e d e Id válida = v e r d a d e r o ] , s e p a s a a la f u n c i ó n d e mensaje y despliegue

del estatus. Si n o existe a l g u n a c o i n c i d e n c i a [ m e n s a j e d e Id válida

= falso], s e p a s a a la f u n c i ó n d e m e n s a j e y d e s p l i e g u e del e s t a t u s . Si e n e s t a e t a p a s e d e s e a n t e n e r d e t a l l e s a l g o r í t m i c o s a d i c i o n a l e s , s e p o d r í a i n c l u i r t a m b i é n u n a r e p r e s e n t a c i ó n e n l e n g u a j e d e d i s e ñ o d e p r o g r a m a s c o m o p a r t e d e la EP. S i n e m b a r g o , m u c h o s p r o f e s i o n a l e s d e l s o f t w a r e c r e e n q u e l a v e r s i ó n e n L D P s e p u e d e p o s p o n e r h a s t a q u e c o m i e n c e el d i s e ñ o d e c o m p o n e n t e s .

r


Análisis estructurado O b j e t i v o : Las herramientas del análisis

•

Herramientas representativas20

estructurado ayudan a un ingeniero d e software a crear modelos de datos, modelos d e flujo y modelos d e

AxiomSys,

desarrollado por STG, Inc. (www.stgcase.com),

comportamiento d e una manera q u e permita la

proporciona un paquete completo d e herramientas

verificación d e la continuidad y la consistencia, así como

p a r a el análisis d e la estructura que incluye extensiones

su fácil edición y extensión. Los modelos creados utilizando

d e Hartley-Pirbhai p a r a el modelado d e sistemas en tiempo real.

estas herramientas brindan al ingeniero d e software una visión d e la representación del análisis y ayudan o

MacA&D, WinA&D, desarrollados por Excel Software

eliminar errores antes de q u e éstos se propaguen en el diseño o, aun peor, en la misma implementación.

(www.excelsoftware.com), proporcionan un conjunto

M e c á n i c a : Las herramientas d e esta categoría utilizan un

diseño en máquinas Mac y Windows.

"diccionario d e datos" como la base de datos central p a r a la descripción d e todos los objetos d e datos. Una vez q u e las entradas del diccionario están definidas, pueden crearse d i a g r a m a s d e entidad-relación y se pueden desarrollar las jerarquías d e objetos. Las características d e diagramación del flujo d e datos permiten crear fácilmente este modelo gráfico y también proporciona caracteristicas

d e herramientas simples y b a r a t a s p a r a el análisis y el

MetaCASE Workbench, desarrollado por Metacase Consulting (www.metacase.com) es una metaherramienta utilizada p a r a definir un método d e análisis o diseño (incluido en análisis estructurado): sus conceptos, reglas, notaciones y generadores. System Architect, desarrollado por Popkin Software

p a r a la creación d e especificaciones d e control (EC) y

(www.popkin.com), proporciona un amplio rango de

especificaciones d e proceso (EP). Las herramientas d e

herramientas d e análisis y diseño, incluye herramientas

análisis también ayudan al ingeniero d e software en la

p a r a el modelado d e datos y el análisis estructurado.

TM

creación d e modelos d e comportamiento que usan los diagramas d e estado como notación operativa.

PDF Editor

20 Las h e r r a m i e n t a s m e n c i o n a d a s aquí representan una m u e s t r a de esta categoría. En la mayoría de los c a s o s los n o m b r e s están registrados por sus respectivos desarrolladores.

CAPÍTULO 8

•

8-F

219


M O D E L A D O R A S A D O EN CLASES ¿Qué se d e b e hacer para desarrollar los e l e m e n t o s b a s a d o s e n clases de un modelo de análisis: clases y objetos, atributos, operaciones, paquetes, m o d e l o s CRC y diag r a m a s d e colaboración? Las secciones siguientes p r e s e n t a n una serie d e directrices informales q u e ayudarán a identificarlos y representarlos.

8.7.1 Identificación de clases de análisis Al observar el interior de u n a habitación se verá que existe un conjunto de objetos físicos que p u e d e n identificarse, clasificarse y definirse con facilidad (en términos de atributos y operaciones). Pero c u a n d o se "observa" el espacio del problema de una aplicación de software, quizá las clases (y los objetos) s e a n m á s difíciles de c o m prender. "El problema realmente difícil es descubrir cuáles son los objetos correctos [clases] en primer lugar." Cari Argila

Se p u e d e iniciar la identificación de clases al e x a m in a r el e n u n c i a d o del problem a o (de a c u e r d o con la terminología aplicada p r e v i a m e n t e en e s t e capítulo) al realizar un "análisis gramatical" s o b r e las narrativas desarrolladas para el sistema que se va a construir o de los c a s o s de uso. Las clases se determinan al subrayar cada sustantivo e introduciéndolas en u n a simple tabla. Los sinónimos deben anotarse. Si la clase s e requiere p a r a implementar u n a solución, e n t o n c e s e s parte del espacio de solución; por o t r o lado, si una clase sólo se necesita para describir u n a solución e s parte del espacio del problema. ¿Qué se d e b e buscar d e s p u é s de que todos los sustantivos h a n sido aislados? Las clases se manifiestan en u n a de las siguientes formas: | ¿De qué forma s e s t a n a sí i las (lases [ * « t f s i s como ; del i de solui*

• Entidades externas (por ejemplo, otros sistemas, dispositivos, personas) que p r o d u c e n o c o n s u m e n información q u e u s a r á un s i s t e m a b a s a d o en c o m p u tadora. • Cosas (por ejemplo, reportes, despliegues, letras, señales) que son p a r t e del dominio de la información para el problema. • Sucesos o eventos (por ejemplo, u n a transferencia de propiedad o la consecución de u n a serie de movimientos de robot) que ocurren dentro del contexto TM de la operación del sistema. • Papeles (por ejemplo, gerente, ingeniero, personal de ventas) que d e s e m p e ñ a n

PDF Editor p e r s o n a s que interactúan con el sistema.

• Unidades organizacionales para alguna aplicación.

(por ejemplo, división, grupo, equipo) relevantes

• Sitios (por ejemplo, el piso de m a n u f a c t u r a o el puerto de carga) que establecen el contexto del problema y la función global del sistema.

220

PASTE DOS


• Estructuras (por ejemplo, sensores, vehículos de cuatro ruedas o computadoras que definen una clase de objetos o clases d e objetos relacionadas. Esta categorización es una de las m u c h a s que se han propuesto en la bibliografía Por ejemplo, si los desarrolladores del software para un sistema de observado-1 médica definen un objeto con el nombre de Imagenlnvertida o I n v e r s i ó n d e l m a g e n podrían estar cometiendo un error sutil. La I m a g e n obtenida del software podría por supuesto, ser una clase (es una cosa integrante del dominio de la información La inversión de la imagen e s una operación que s e aplica a la clase. Probablemente la inversión<) s e definiría como una operación para la clase Imagen, pero n o s e establecería como una clase diferente para connotar "inversión de imagen". Como establece Cashman [CAS89]: "El objetivo de la orientación hacia los objetos es encapsular, pero aun así mantener separados, los datos y las operaciones sobre los datos' Para ilustrar la forma en que las clases de análisis pueden definirse durante las primeras etapas del modelado, se utiliza de nuevo la función de seguridad ce HogarSeguro. En la sección 8.6.1 se realizó un "análisis gramatical" sobre la narrativa del procesamiento 2 2 para la función de seguridad. Al extraer los sustantivos se puede proponer una serie de clases potenciales:

Clase potencial

Clasificación g e n e r a l

propietario

papel o entidad externa

sensor

entidad externa

panel d e control

entidad externa

instalación

ocurrencia

sistema (alias sistema d e seguridad)

cosa

número, tipo

no objetos, atributos del sensor

contraseña maestra

cosa

número telefónico

cosa

evento del sensor

ocurrencia

alarma audible

entidad externa

servicio d e monitoreo

unidad organizacional o entidad externa

La lista podría extenderse hasta que todos los sustantivos en la narrativa del proceTM la lista ha sido samiento hayan sido considerados. Obsérvese que cada entrada en

PDF Editor

21 Otra categorización importante —la cual define entidad, frontera y clases de controlador— se examina en la sección 8.7.4.

22 Es importante notar q u e esta técnica d e b e usarse también p a r a t o d o s los c a s o s d e u s o desarrollad o s c o m o parte d e la actividad para la recopilación de requisitos (obtención). Esto es, los c a s o s de u s o p u e d e n analizarse gramaticalmente p a r a extraer clases d e análisis potenciales.

CAPÍTULO 8

221


llamada c o m o u n objeto potencial. Cada u n o de ellos d e b e considerarse a fondo a n t e s de t o m a r u n a decisión final. "Las clases luchan, algunas clases triunfan, otras son eliminadas." M a o Zedong Coad y Yourdon [COA91 ] sugieren seis características de selección que se deben u s a r c u a n d o un analista considera cada clase potencial para incluirlas en el modelo de análisis: [ _Como s e ((termina i dase

1. Información referida. La clase potencial será útil d u r a n t e el análisis sólo si la información acerca de ella d e b e recordarse para que el sistema pueda funcionar. 2.

t en una i »

análisis?

Servicios requeridos. La clase potencial d e b e tener un conjunto de o p e r a c i o n e s identificables que p u e d a n cambiar el valor de sus atributos de alguna manera.

3 . Atributos múltiples. Durante el análisis de requisitos el e n f o q u e d e b e estar en la información "importante"; una clase con un solo atributo puede, de hecho, s e r útil durante el diseño, pero p r o b a b l e m e n t e es mejor representarla c o m o un atributo de otra clase durante la actividad de análisis. 4 . Atributos comunes.

Es posible definir u n conjunto de atributos para la clase

potencial, y e s t o s atributos pueden aplicarse en t o d a s las instancias de la clase. 5 . Operaciones comunes.

Es posible definir un conjunto de operaciones para la

clase potencial, y estas operaciones p u e d e n aplicarse e n todas las instancias de la clase. 6.

Requisitos esenciales. Las entidades e x t e r n a s que a p a r e c e n en el espacio del problema, y que producen o c o n s u m e n información esencial para la operación de cualquier solución para el sistema, se definirán casi siempre c o m o clases en el modelo de requisitos.

Considerarla una clase legítima para incluirla e n el modelo de requisitos requiere que una clase potencial satisfaga todas (o casi todas) estas características. La decisión de incluir clases potenciales e n el m o d e l o de análisis es algo subjetiva, y u n a evaluación posterior p u e d e ocasionar que se descarte o reinstale u n a clase. Sin embargo, el primer p a s o del m o d e l a d o b a s a d o en clases e s la definición de clases, y TM se deben tomar decisiones (incluso subjetivas). Con esto en mente, se aplican las características de selección a la lista de clases potenciales de HogarSeguro:

PDF Editor Clase potencial

N ú m e r o d e característica q u e aplica

propietario

rechazada; 1 y 2 fallan aunque aplica 6

sensor

a c e p t a d a : todas aplican

panel d e control


222

PAETE DOS


instalación

rechazada:

sistema (alias función d e seguridad)

a c e p t a d a : todos aplican

número, tipo

rechazada: falla 3, atributos del sensor

contraseña maestra

rechazada: falla 3

número telefónico

r e c h a z a d a : falla 3

evento del sensor


alarma audible

a c e p t a d a : aplican 2, 3, 4 , 5, 6

servicio d e monitoreo

rechazada: I y 2 fallan aunque aplica 6

Se d e b e señalar que 1) la lista anterior n o está completa (se tendrían que agregar s e s adicionales para terminar el modelo); 2) algunas de las clases potenciales i z a d a s se convertirán en atributos para las clases a c e p t a d a s (por ejemplo, número tipo s o n a t r i b u t o s d e s e n s o r , y c o n t r a s e ñ a m a e s t r a y número telefónico s e p u e d e n c o n

tir en atributos de s i s t e m a ) ; 3) la existencia de enunciados diferentes del prob podría o c a s i o n a r decisiones distintas de "aceptación o rechazo" (por ejemplo, si propietario tuviera u n a c o n t r a s e ñ a diferente o si pudiera identificarse por su voz clase P r o p i e t a r i o satisfaría las características 1 y 2 y ésta habría sido aceptada

8.7.2 Especificación de atributos Los atributos describen una clase que ha sido seleccionada para incluirla en modelo de análisis. En esencia, los atributos s o n los que definen la clase, lo cual rifica qué significa la clase en el contexto del espacio del problema.

ClfAVE los atributos son el conjunto de objetos de datos que definen por completo la clase dentro del contexto del problema.

En el desarrollo de u n conjunto de atributos significativo para u n a clase de análisis un ingeniero de s o f t w a r e p u e d e estudiar de n u e v o un c a s o de u s o y selección 3aquellas "cosas" que "pertenecen" de m a n e r a razonable a la clase. Además, se debe contestar la siguiente pregunta para cada clase: ¿Cuáles elementos de d a t o s (com p u e s t o s o elementales) definen esta clase en el contexto del problema? Esto se ilustra c o n s i d e r a n d o la clase s i s t e m a definida para HogarSeguro.

Se h£

m e n c i o n a d o que el propietario p u e d e configurar la función de seguridad para reflejar la información del sensor, información de la respuesta de alarma, información de la activación/desactivación, información de la identificación, y así sucesivamente Estos elementos de d a t o s compuestos se pueden representar de la siguiente manera información de identificación = ID del sistema + verificación del número telefónico + estatus del sistema

TM

información de la respuesta de alarma = tiempo de retraso + número telefónico información de la activación/desactivación = contraseña maestra + número de intentos permi-

PDF Editor sibles + contraseña temporal

Algunos de los d a t o s a la derecha del signo de igual podrían refinarse hasta u n nivel elemental, p e r o para los propósitos de este capítulo constituyen u n a lista razonable de atributos para la clase s i s t e m a (parte s o m b r e a d a de la figura 8.13).

CAPÍTULO 8

223


Los s e n s o r e s s o n parte del sistema global de HogarSeguro, y aun así no están e n listados c o m o e l e m e n t o s de d a t o s o c o m o atributos en la figura 8.13. Ya se ha definido s e n s o r c o m o u n a clase, y varios objetos de s e n s o r se asociarán con la clase s i s t e m a . En general, s e evita la definición de un e l e m e n t o c o m o un atributo si m á s de u n o de los e l e m e n t o s se asociará con la clase.

8.7.3 Definición de operaciones Las o p e r a c i o n e s definen el c o m p o r t a m i e n t o de u n objeto. Aunque existen m u c h o s tipos distintos de operaciones, é s t a s se pueden dividir, por lo general, en tres grand e s categorías: 1) operaciones que manipulan los d a t o s d e alguna m a n e r a (por e j e m plo, al agregar, borrar, reformatear, seleccionar), 2) o p e r a c i o n e s que realizan u n cómputo, 3) operaciones que p r e g u n t a n acerca del e s t a d o de un objeto, y 4) o p e r a ciones que monitorean un objeto para la ocurrencia de un e v e n t o de control. Estas f u n c i o n e s se ejecutan al operar sobre atributos o asociaciones (sección 8.7.5). Por lo tanto, u n a operación d e b e tener "conocimiento" de la naturaleza de los atributos y f a K U J o f .

2 definen los pora uno móísis, el xbe estar en nto é problema tos comporto•squeridos aykrmta-

asociaciones de la clase. C o m o u n a primera iteración e n la obtención de un c o n j u n t o de o p e r a c i o n e s para una clase de análisis, el analista p u e d e estudiar otra vez la narrativa de un procesamiento (o c a s o de uso) y seleccionar aquellas o p e r a c i o n e s que p e r t e n e z c a n de m a n e r a razonable a la clase. Esto s e logra estudiando d e n u e v o el análisis gramatical y aislando los verbos. Algunos de e s t o s verbos serán opciones legítimas y podrán conectarse con facilidad a u n a clase específica. Por ejemplo, en la narrativa del proc e s a m i e n t o p r e s e n t a d a párrafos a t r á s en e s t e capítulo, se observa que "al sensor s e le asigna u n n ú m e r o y u n tipo" o "se p r o g r a m a u n a c o n t r a s e ñ a m a e s tra para habilitar y deshabilitar el sistema". Estas frases indican algunos hechos:

Sistema ID sistema verificaciónNúmeroTelefónico Estafussistema Tiemporetraso Numeróte lefónico Contraseñamaestra Contraseñatemporal Númerodeintentos

TM

PDF Editor programar() desplegar!) reiniciar() buscar() modificar!) llamar()

224

PARTE D O S


• Que una operación de asignar<) es relevante para la clase sensor. • Que una operación de programar,() está encapsulada por la clase sistema • Que habilitar() y deshabilitar() son operaciones que se aplican a la clase sistema En una investigación posterior tal vez la operación programarf) sea dividida en J serie de suboperaciones m á s específicas que se requieren para configurar el siste-J Por ejemplo, programarf) implica la especificación de números telefónicos, la cc"l guración de características del sistema (como al crear la tabla de sensores, al ir r J ducir las características de la alarma) y la introducción de contraseña(s). Sin em:a( go, por ahora programar() se especifica como una sola operación.

Modelos

de clase

El e s c e n a r i o : Cubículo d e Ed, al comenzar el modelado del análisis.

d e estas paredes. ¿Cómo sabe el plano d e planta dónc-e colocar esos objetos? |

Los a c t o r e s : Jamie, Vinod y Ed, miembros del equipo

Ed: N o lo sabe, pero las otras clases sí. Miren los

d e ingeniería del software d e HogarSeguro.

atributos d e a b a j o , digamos, S e g m e n t o s d e P a r e d

La c o n v e r s a c i ó n :

cuales se usan p a r a construir una p a r e d . El segmento de p a r e d tiene u n a s c o o r d e n a d a s d e inicio y final, y la operación d e dibujo(] h a c e el resto.

(Ed ha estado t r a b a j a n d o en la extracción d e clases o partir d e la plantilla d e caso d e uso p a r a el " A c c e s o a

J a m i e ; Y lo mismo p a s a p a r a las puertas y ventanas.

la c á m a r a d e vigilancia-despliegue d e vistas

Parece como si las c á m a r a s tuvieran unos pocos d e

d e c á m a r a " {presentado en un recuadro anterior en este capítulo] y está mostrando a sus colegas las clases

atributos extra.

q u e ha extraído.

Ed: Sí, los necesito p a r a poder d a r la información del

Ed: Entonces, c u a n d o el propietario quiere escoger una

movimiento y el acercamiento.

c á m a r a , él o ella d e b e elegirla d e un plano d e planta. He

V i n o d : Tengo una pregunta. ¿Por qué la c á m a r a tiene

definido una clase llamada P l a n o d e P l a n t a . Aquí está

una ID, pero las otras clases no?

el d i a g r a m a .

'

'f

'

(Todos miran la figura 8.14.)

:

||

Ed: Vamos a necesitar identificar c a d a c á m a r a p a r a 11

,

propósitos del despliegue.

J a m i e : Entonces P l a n o d e P l a n t a es una clase q u e se une a las p a r e d e s q u e están compuestas por segmentos

J a m i e : Tiene sentido p a r a mí, pero tengo algunas otras preguntas, (jamie hace preguntas que resultan en

d e pared, puertas y ventanas, y también las c á m a r a s ; eso es lo q u e significan esas líneas etiquetadas, ¿no?

modificaciones menores.)

Ed: Sí , esas líneas se llaman "asociaciones". Las clases

V i n o d : ¿Tienes tarjetas CRC p a r a c a d a una d e estas clases? Si es así, debemos seguirlas, sóloTM hay que estar

están asociadas entre sí d e acuerdo con las asociaciones a j e les he mostrado, [las asociaciones sé estudian en la

seguros d e q u e no se ha omitido n a d a . Ed: N o estoy seguro d e cómo hacerlas.

PDF Editor sección 8.7.5.]

í

f

¡

,

V i n o d : Entonces el plano d e planta real está hecho d e

V i n o d : N o es difícil, y los resultados son muy buenos.

paredes y contiene cámaras y sensores colocados dentro

Les mostraré.

,

CAPITULO 8

225


PlanodePlanta

a de para ^Planta el en el

tipo nombre Dimensionesexternas determinarTipo() posicionarPlanodePlanta)) escalar) ¡ cambiar color))

Se ubica dentro d e ». Es p a r t e d e

Par «d

Cámara

tipo Dimensionespared

r

ubicación campodeVisión AngulodeTomo Configuración Acercamiento

determinarT P ° 0 calcularDim ensiones()

Segmento d e Pared

Ventana

Ventana

tipo Coordenadasinicio Coordenadasfinal SiguienteSeg mentó Pared

tipo Coordenadasinicio Coordenadasfinal SiguíenteVentana

tipo Coordenadasinicio Coordenadasfinal SiguientePuerta

determmarT¡po() dibujar

determinarTipo{)

determinarTipof) dibujar

dibujar

8.7.4 Modelado de Clase-Responsabilidad-Colaborador (CRC) El modelado de Clase-Responsabilidad-Colaborador

(CRC) [WIR90] proporciona un

medio simple para identificar y organizar las clases relevantes para los requisitos del sistema o producto. Ambler [AMB95] describe el m o d e l a d o CRCTM de la siguiente forma: Un modelo CRC en realidad e s u n a colección de tarjetas índice e s t á n d a r q u e representan

PDF Editor

clases. Las tarjetas se dividen en tres secciones. A lo largo del borde superior d e la tarjeta

s e escribe el n o m b r e d e la clase. En el cuerpo d e la tarjeta se listan las responsabilidades d e la clase a la izquierda y los colaboradores a la derecha.

En realidad, el m o d e l o CRC p u e d e utilizar tarjetas índice reales o virtuales. El objetivo es desarrollar una representación organizada de las clases. Las responsabilidades

226

PARTE D O S


s o n los atributos y las operaciones relevantes para la clase. Dicho de m a n e r a simple, u n a responsabilidad es "cualquier cosa que la clase s a b e o hace" [AMB9F1 Los colaboradores

s o n aquellas clases que se requieren para que u n a clase reciba a

información necesaria para completar u n a responsabilidad. En general, u n a c o l a b c l ración implica ya sea una solicitud de información o la solicitud de alguna acción "Uno de los propósitos de los tarjetas CRC es follor ol inicio, fallar constantemente y (ollar sin que sea caro. Es mucho más barato tirar un bulto de tarjetas que reorganizar una gran cantidad de código fuente." C Horstmunr

En la figura 8.15 se ilustra una tarjeta índice CRC simple para la clase Planodeplanta. La lista de responsabilidades que se muestra en la tarjeta CRC es preliminar y está sujeta a adiciones o modificaciones. Las clases P a r e d y C á m a ra se a n o t a r enseguida de la responsabilidad que requerirá su colaboración. Clases.

Las directrices básicas para identificar clases y objetos ya se h a n prese-

tado en e s t e m i s m o capítulo. La taxonomía d e los tipos de clases q u e s e p r e s e n t ó e r la sección 8.7.1 se p u e d e extender c o n s i d e r a n d o las siguientes categorías: • Clases de entidad, t a m b i én l l a m a d a s clases de modelo o negocios, se extraen En w w w .

de m a n e r a directa del e n u n c i a d o del problema (por ejemplo, P l a n o d e p l a n t a

theumlcoie.com/

y S e n s o r ) . De m a n e r a típica, e s t a s clases representan clases que se almacen a r á n en u n a b a s e de d a t o s y que persisten d u r a n t e la aplicación (a m e n o s q u e se borren de m a n e r a específica).

encontrarse una casos.

• Clases de frontera. Se utilizan para crear la interfaz (por ejemplo, pantallas interactivas o reportes impresos) que el usuario ve y con la cual interactúa c u a n d o se utiliza el software. Las clases de entidad contienen información

Una carta índice del modelo CRC.

i

—

Clase:

-

Descripción

-

PlanodePlanta

— —

Responsabilidad

Colaborador

Define el n o m b r e / t i p o del plano d e planta

TM

M a n e j a la posición del plano d e planta Escala el p l a n o d e planta p a r a su despliegue Escala el p l a n o d e planta p a r a su despliegue

PDF Editor Incorpora p a r e d e s , puertas y v e n t a n a s

Muestra la posición d e las c á m a r a s d e video

Pared Cámara

|

i

CAPÍTULO 8

227


importante p a r a los usuarios, pero no se despliegan a sí mismas. Las clases d e frontera están diseñadas c o n la responsabilidad de m a n e j a r la forma en que los objetos de entidad se p r e s e n t a n a los usuarios. Por ejemplo, una clase de frontera llamada V e n t a n a d e C á m a r a tendría la responsabilidad de desplegar la salida de u n a c á m a r a de vigilancia para el sistema HogarSeguro. Las clases de controlador m a n e j a n u n a "unidad de trabajo" [UML03] d e s d e el inicio hasta el final. Esto es, las clases de controlador se pueden diseñar para m a n e j a r 1) la creación o actualización de los objetos de entidad; 2) la inmediatez de objetos de frontera conforme éstos obtienen información de objetos de entidad; 3) la comunicación compleja entre c o n j u n t o s de objetos; y 4) la validación de d a t o s c o m u n i c a d o s entre los objetos o e n t r e el usuario y la aplicación. En general, las clases de controlador no s e consideran sino hasta que h a c o m e n z a d o el diseño.

"Los objetos pueden clasificar* de manera científica en tres grandes categorías: los que no funcionan, los que se Am " UoawlHflUlKfn y los que se pier Bol!.

Russell Baker

Responsabilidades.

En las secciones 8.7.2 y 8.7.3 se han p r e s e n t a d o las directri-

c e s básicas para identificar responsabilidades (atributos y operaciones). Wirfs-Brock y s u s colegas [WIR90] sugieren cinco directrices para determinar las responsabilidad e s de las clases: 1. La i n t e l i g e n c i a d e l s i s t e m a s e d e b e distribuir e n t r e l a s c l a s e s para

|¿«hs ' ¿rectrices

a b o r d a r d e m e j o r m a n e r a l a s n e c e s i d a d e s del p r o b l e m a Cada aplica-

narse i k asignación dai s IB dases?

ción abarca un cierto g r a d o de inteligencia; esto es, lo que el sistema s a b e y p u e d e hacer. Esta inteligencia p u e d e distribuirse e n t r e las clases de varias m a n e r a s diferentes. Las clases "poco inteligentes" (aquellas que tienen m e n o s responsabilidades) pueden modelarse para actuar al servicio de u n a s c u a n t a s clases "muy inteligentes" (las que tienen m u c h a s responsabilidades). Aunque este e n f o q u e h a c e que el flujo de control en un sistema sea directo, tiene u n a s c u a n t a s desventajas: a) concentra toda la inteligencia en u n a s p o c a s clases, lo que dificulta los cambios, y b) tiende a requerir m á s clases, y por ende, un m e jor e s f u e r z o de desarrollo.

TM entre las Si la inteligencia del sistema se distribuye con mayor amplitud clases de u n a aplicación, cada objeto s a b e y h a c e sólo u n a s c u a n t a s c o s a s (las cuales, por lo general, son bien enfocadas), y la cohesión del sistema mejora.

PDF Editor

Lo anterior a u m e n t a la facilidad de m a n t e n i m i e n t o del s o f t w a r e y reduce el impacto de los efectos colaterales debidos al cambio.

Para determinar si la inteligencia del sistema está bien distribuida las res-

ponsabilidades a n o t a d a s en cada tarjeta índice del m o d e l o CRC deben evaluarse y así c o m p r o b a r si alguna clase tiene u n a lista de responsabilidades

228

PARTE DOS

PRÁCTICA DE LA INGENIERIA D A SOFTWARE

demasiado larga. Esto indica una concentración de inteligencia. 23 Además, las responsabilidades para cada clase deben mostrar el mismo grado de a b s t r a c t i m 2. Cada responsabilidad d e b e e s t a b l e c e r s e tan general c o m o s e a posible. Esta directriz implica que las responsabilidades generales (tanto atributos como operaciones) deben estar en la parte alta de la jerarquía de la clase (debido a que son genéricas son aplicables en todas las subclases). 3. La información y el c o m p o r t a m i e n t o r e l a c i o n a d o c o n ella d e b e n d e n t r o de la m i s m a c l a s e . Con esto se logra el principio OO llamado en sulación. Los datos y los procesos que manipulan los datos deben empaquetarse como una unidad cohesiva. 4. La información relativa a u n a c o s a d e b e localizarse c o n una s o l a c l a s e , n o distribuirse entre m u c h a s de ellas. Una sola clase debe tomar la responsabilidad de almacenar y manipular un tipo específico de información. En general, esta responsabilidad n o se puede compartir entre varias clases. Si la información se distribuye, el software se vuelve más difícil de mantener y más desafiante de probar. 5. Las r e s p o n s a b i l i d a d e s p u e d e n compartirse entre c l a s e s relacionadas c u a n d o e s t o e s apropiado. Existen muchos casos en los que una variedad de objetos relacionados deben mostrar el mismo comportamiento al mismo tiempo. Como un ejemplo, considérese un videojuego que debe desplegar las siguientes clases: Jugador, Cuerpojugador, Brazosjugador, Piernasjugador, Cabezajugador. Cada una d e estas clases tiene sus propios atributos ( p o r e j e m p l o , posición, orientación, color, velocidad) y t o d o s d e b e n a c t u a l i z a r s e y

desplegarse cuando el usuario manipula un jqystick. Por lo tanto, las responsabilidades actualizad) y desplegar,() deben compartirlas cada uno de los objetos mencionados. El Jugador sabe cuando algo ha cambiado y se requiere actualizar(). Colabora con los otros objetos para lograr una nueva posición u orientación, pero cada objeto controla su propio despliegue. Colaboraciones.

Las clases cumplen sus responsabilidades en una de dos formas:

1) una clase puede utilizar sus propias operaciones para manipular sus propios atributos, y con ello cumplir con una responsabilidad particular, o 2) una clase puede colaborar con otras clases. Wirfs-Brock y sus colegas [W1R90] definen las colaboraciones manera:

de la siguiente TM

Las c o l a b o r a c i o n e s r e p r e s e n t a n l a s s o l i c i t u d e s q u e u n cliente h a c e a u n s e r v i d o r c o n el fin

PDF Editor

d e c u m p l i r u n a r e s p o n s a b i l i d a d . Una c o l a b o r a c i ó n e s la m a t e r i a l i z a c i ó n del c o n t r a t o e n tre el cliente y el s e r v i d o r . . . Se d i c e q u e u n o b j e t o c o l a b o r a c o n o t r o o b j e t o si, p a r a c u m -

plir c o n u n a r e s p o n s a b i l i d a d , n e c e s i t a e n v i a r a l g u n o s m e n s a j e s al o t r o o b j e t o . U n a

2 3 En tales c a s o s p u e d e ser necesario dividir las clases en múltiples clases o s u b s i s t e m a s completos para distribuir la inteligencia d e m a n e r a m á s eficaz.

CAPÍTULO 8


229

c o l a b o r a c i ó n sencilla fluye e n una dirección, lo q u e r e p r e s e n t a u n a solicitud del cliente al servidor. Desde el p u n t o d e vista del cliente, c a d a u n a de s u s c o l a b o r a c i o n e s e s t á a s o c i a d a c o n u n a responsabilidad particular q u e h a i m p l e m e n t a d o el servidor.

Las colaboraciones identifican las relaciones entre clases. Cuando un conjunto de clases colabora para lograr algún requisito, éste puede organizarse en un subsistema (un aspecto de diseño). Las colaboraciones se identifican al determinar si una clase puede cumplir cada responsabilidad por sí misma. Si n o e s así, entonces se requiere de la interacción con otra clase y, por ende, una colaboración. Como un ejemplo, considérese la función de seguridad de HogarSeguro. Como parte del procedimiento de activación, el objeto PaneldeControl debe determinar si algún sensor está abierto. Se define una responsabilidad llamada determinar-estatus-sensor(). Si los sensores están abiertos, PaneldeControl debe establecer un atributo de e s t a t u s como "no listo". La información de los sensores se obtiene de cada objeto sensor. Por lo tanto, la responsabilidad determinar-estatus-control() trabaja en colaboración con sensor. Para ayudarse en la identificación de los colaboradores, el analista puede examinar tres relaciones genéricas diferentes entre las clases [WIR90]: 1) la relación esparte-de, 2) la relación tiene-conocimiento-de, y 3) la relación depende de. Cada una de las tres relaciones genéricas se considera con brevedad en los siguientes párrafos. Todas las clases que son parte de una clase agregada se conectan a ésta a través de u n a relación del tipo es-parte-de. Considérense las clases definidas para el videojuego ya mencionado, la clase Cuerpojugador es-parte-de Jugador, al igual que Brazosjugador, Piernasjugador y Cabezajugador En UML estas relaciones se representan como la agregación mostrada en la figura 8.16. Cuando una clase debe obtener información de otra clase se establece la relación tiene-conocimiento-de. La responsabilidad determinar-estatus-sensor() mencionada antes ejemplifica una relación del tipo tiene-conocimiento-de. La relación depende-de implica que dos clases tienen una dependencia que n o se logra mediante las relaciones tiene-conocimiento-de o es-parte-de. Por ejemplo, c a b e z a j u g a d o r siempre debe estar conectada a Cuerpojugador (a m e n o s que el videojuego sea violento en particular). Aun así, cada objeto puede existir sin el conocimiento directo del otro. Un atributo del objeto Cabezajugador llamado p o s i c i ó n central está determinado desde la posición central de Cuerpojugador. TM Esta información se obtiene a través de un tercer objeto, Jugador, quien la adquiere de Cuerpojugador Por ende, Cabezajugador depende-de Cuerpojugador. En todos los casos, el nombre de la clase del colaborador se registra en la tarjeta índice del modelo CRC enseguida de la responsabilidad que ha producido la colabo-

PDF Editor

ración. Por lo tanto, la tarjeta índice contiene una lista de responsabilidades y las colaboraciones correspondientes que permiten que las responsabilidades puedan cumplirse (figura 8.15).

230

PARTE D O S


Una clase agregada compuesta.

Cabezajugadoi

CuerpoJugador

BrazosJugador

PiernasJugador

Cuando s e h a desarrollado un m o d e l o CRC completo, los r e p r e s e n t a n t e s del d i c t e s y la ingeniería del s o f t w a r e pueden revisar el m o d e l o utilizando el siguiente ení> que [AMB95]: 1. Todos los participantes en la revisión (del modelo CRC) reciben un subconjunto de las tarjetas índice del modelo CRC. Las tarjetas que colaboran se deben separar (es decir, ningún revisor d e b e tener d o s que colaboren). 2. Todos los escenarios de c a s o de u s o (y los d i a g r a m a s de c a s o de uso correspondientes) deben o r g a n i z a r s e en categorías. 3 . El líder de la revisión lee el c a s o de uso e n forma deliberada. C u a n d o el líder llega a una clase n o m b r a d a p a s a una señal a la persona que tiene la tarjeta índice de clase correspondiente. Por ejemplo, u n c a s o de u s o para HogarSeguro contiene la siguiente narrativa: El propietario observa el panel d e control d e HogarSeguro p a r a determinar si el sistema está listo para la entrada. Si n o lo está, el propietario podrá cerrar físicamente ventan a s y p u e r tas para q u e s e p r e s e n t e el indicador de listo. [Un indicador d e no-listo implica q u e un sensor está abierto; es decir, q u e esa puerta o ventana está abierta.]

Cuando el líder de la revisión llega a "panel de control", en la narrativa del casc de uso, la señal se p a s a a la persona que p o s e e la carta índice del P a n e l d e control. La frase "implica que un s e n s o r está abierto" requiere TM q u e la tarjeta índice c o n t e n g a u n a responsabilidad que validará esta implicación (lo cual se logra mediante la responsabilidad determinar-estatus-sensor()).

PDF Editor

Enseguida de

la responsabilidad escrita en la tarjeta está el colaborador s e n s o r . Entonces, la señal se p a s a a la clase s e n s o r .

4 . C u a n d o s e p a s a la señal, la persona que p o s e e la tarjeta d e clase d e b e describir las responsabilidades a n o t a d a s en ella. El grupo determina si u n a (o más) de las responsabilidades satisface el requisito del c a s o de uso.

CAPÍTULO 8

231


5. Si las responsabilidades y las colaboraciones anotadas en las tarjetas índice no satisfacen el caso de uso, se hacen las modificaciones necesarias a la tarjeta. Esto puede incluir la definición de clases nuevas (y corresponden a las tarjetas de índice de CRC) o la especificación de responsabilidades o colaboraciones nuevas revisadas sobre las tarjetas existentes. Esta forma de operación continúa hasta que se termina con el caso de uso. Cuando se han revisado todos los casos de uso se continúa con el modelado del análisis.

lelos

CRC

! e s c e n a r i o : Cubículo d e Ed, I análisis.

Con una solo selección, quiero ser c a p a z d e configurar la casa completa p a r a varias situaciones. Una es en casa; la otra, fuera de casa; una tercera, salida por la

s : Vinod y Ed, miembros del equipo d e del software de HogarSeguro

noche, y una cuarta, viaje largo. Todas estas situaciones tendrán configuraciones q u e se aplicarán a todos los dispositivos. En los estados salida por la noche y viaje

i decidido enseñarle a Ed cómo desarrollar

largo el sistema d e b e encender y a p a g a r luces a

s CRC mediante un ejemplo.)

intervalos aleatorios (para a p a r e n t a r que alguien está en casa) y controlar el sistema d e calefacción y aire

: Mientras tú has estado t r a b a j a n d o en lo

acondicionado. Debo ser c a p a z d e invalidar estas

¡ y Jamie ha estado involucrado con la i , y o he estado t r a b a j a n d o en la función d e i del hogar. : ¿Cuál es el estatus d e eso? Mercadotecnia cambia su : vista a c a d a momento. ,, t Aquí está el primer corte del caso d e uso p a r o i a f u n c i ó n . l o hemos refinado un poco, pero i darte una idea genera!. Función d e administración del hogar de

configuraciones a través d e Internet con la protección d e ||

una contraseña a p r o p i a d a . Ed: ¿La gente d e hardware tiene concebidas todas las interfases inalámbricas? V i n o d ( s o n r i e n d o ) : Están t r a b a j a n d o en ellas, digamos q u e no es un gran problema. De cualquier manera, extraje una serie d e clases p a r a la administración del hogar, y podemos utilizar alguna d e ellas c o m o ejemplo. Usemos la clase

InterfazAdministraciónHogar. : Queremos utilizar la interfaz d e i del hogar en una PC o con una conexión t p a r a controlar dispositivos electrónicos que i consoladores d e interfoz inalámbricos. El sistema > permitirme encender y a p a g a r luces específicas, • aplicaciones conectadas a una interfaz D, configurar los sistemas d e calefacción y aire i con las temperaturas q u e yo defina; p a r a i quiero seleccionar los dispositivos de un plano d e i d e la casa. C a d a dispositivo d e b e estar

Ed: De acuerdo.. entonces, las responsabilidades son... los atributos y operaciones p a r a la clase, y las colaboraciones son las clases hacia las que apuntan las responsabilidades. V i n o d : Creo que no entendiste la CRC. Ed: Tal vez un poco, pero continúa.

TMd e clase p a r a V i n o d : Entonces, aquí está mi definición InterfazAdministraciónHogar. Atributos:

PDF Editor híicado sobre el plano d e la planta. Como una i opcional, quiero controlar todos los

sitivos audiovisuales: audio, televisión, DVD,

l y j&adoras digitales, etcétera

Panelopciones: proporciona información en botones q u e

permiten al usuario seleccionar una funcionalidad. Panelsituación: proporciona información en botones que

permiten al usuario seleccionar la situación.

232

PARTE DOS


Pionodeplanta: el mismo q u e el objeto d e vigilancia, pero

seleccionarSituación

P a n e l S i t u a c i ó n (clase)

éste despliega los dispositivos.

entrarPlanodePlanta

P l a n o d e P l a n t a (clase)

(

>

:

.

IconosdeDispositivo: información sobre iconos q u e representan luces, aplicaciones, c á m a r a s , etcétera. PanelesdeDispositivo: simulación d e uria aplicación o panel d e control d e un dispositivo; permite el control. Ed: Entonces c u a n d o se invoca la operación

Operaciones: DespíegarControllj,

entrarplanodePlantall,

selecaonarControl(),

desplegarSihjcK¡ón(), enlrarPlanodePlanlaü,

seleccionarSituación(), seleca'onorlconoDispositivofj,

desplegarPanelDispositivofl

entrar PanelDispositivolj,...

Clase: InterhzAdministraciónHogar

ésta colabora con el objeto

P l a n o d e P l a n t a como el q u e desarrollamos p a r a la vigilancia. Espera, aquí tengo su descripción. (Ven la figura 8.14) V i n o d : Exactamente. Y s¡ quisiéramos revisar todo el modelo de clase, podríamos comenzar con esta carta

Responsabilidad

Colaborador

índice, después ir a la carta índíce del colaborador, y c e

despiegarControl

P a n e l o p e r a c i o n e s (clase)

ahí, a una d e los colaboradores d e los colaboradores, y

seleécionarControl

P a n e l o p e r a c i o n e s (clase)

desplegarSituación

P a n e l S i t u a c i ó n (clase)

así sucesivamente, Ed: Buena forma d e encontrar omisiones o errores.

Vinod: Sí.

8.7.5 Asociaciones y dependencias K

cávE Una asociación define una relación entre clases. La multiplicidad define cuántas de una clase están relacionadas con cuántos de otro clase.

En muchos casos, dos clases de análisis se relacionan entre sí de alguna manera, parecida a la forma en que se relacionan dos objetos de datos (sección 8.3.3). En UML estas relaciones se llaman asociaciones. Véase de nuevo la figura 8.14; la clase PlanodePlanta se define al identificar un conjunto de asociaciones entre PlanodePlanta y otras dos ciases, Cámara y Pared. La clase Pared se asocia con tres clases que permiten que se construya una pared, S e g m e n t o d e P a r e d , Ventana y Puerta. En a l g u n o s casos, u n a asociación se p u e d e definir en forma m á s e x t e n s a al indicar multiplicidad

(el término cardinalidad ya se usó a n t e s en e s t e capítulo). En refe-

rencia a la figura 8.14, un objeto de P a r e d se construye con u n o o más objetos de S e g m e n t o s d e P a r e d . A d e m á s , el o b j e t o P a r e d p u e d e c o n t e n e r 0 o m á s objetos de V e n t a n a y 0 o m á s objetos de Puerta. Estas restricciones de multiplicidad se ilustran e n la figura 8.17, d o n d e "uno o más" se representa m e d i a n t e 1 ..* y "0 o m á s " pom e d i o 0..*. En UML el asterisco indica u n a frontera superior ilimitada en el rango.^ •

¿ Q u é e s un estereotipo?

En m u c h o s casos existe u n a relación cliente-servidor entre d o sTM clases de análisis.

En tales casos, una clase de cliente d e p e n d e de alguna m a n e r a de la clase de servidor y se establece una relación independencia.

Las d e p e n d e n c i a s se definen median-

PDF Editor

te un estereotipo. Un estereotipo es un "mecanismo de extensibilidad" [ARL02] den

24 Otras relaciones de multiplicidad —una a una, una a muchas, m u c h a s a muchas, una a un rango específico con límites inferior y superior, y otras— se pueden indicar c o m o parte d e una asociación

CAPITULO 8


233

tro del UML que permite a un ingeniero de software definir un elemento de modelado especial cuya semántica define el cliente. En UML los estereotipos se representan dentro de comillas angulares (por ejemplo, « e s t e r e o t i p o » ) . Como una ilustración de una dependencia simple dentro del sistema de vigilancia de HogarSeguro, un objeto d e Cámara (en este caso, la clase de servidor) proporciona una imagen d e video o un objeto de VentanadeDespliegue (en este caso, la del cliente). La relación entre estos dos objetos no es una asociación simple, aun así existe una asociación de dependencia. En un caso de uso escrito para la vigilancia (que no se muestra), el modelador aprende que se debe proporcionar una contraseña especial para ver ubicaciones específicas de cámara. Una forma de lograr esto es que Cámara pida una contraseña y después dé permiso a VentanadeDespliegue para TM producir la imagen de video. Esto se puede representar como se muestra en la figura 8.18, donde « a c c e s o » implica que el uso de la salida de la cámara está controlado

PDF Editor mediante una contraseña especial.

8.7.6 Paquetes de análisis

Una parte importante del modelado del análisis e s la categorización. Esto es, los diferentes elementos del modelo de análisis (por ejemplo, casos de uso, clases de

234

PARTE D O S


Paquetes.

. N o m b r e del p a q u e t e MedioAmbii e n t e j +Árbol +Paisa¡e +Camino +Pared +Puente +Edificio +EfectoVisual

RefllasDeUuefloU. +ReglasDeMovim¡enlo +Restricc¡onesEnAcción

+Escera Personaje» | •Jugador •Protagonista •Antagonista +PapeldeSoporte

análisis) se clasifican de una m a n e r a q u e los e m p a q u e t e c o m o u n a agrupación m a d a un paquete de análisis—, a la cual se le asigna un n o m b r e representativo. Para ilustrar la utilización de p a q u e t e s de análisis considérese el videojuego q j d

\ CLAVE Un paquete se utilizo paro ensamblar uno colección de clases relacionadas.

se presentó párrafos atrás. AI desarrollar el m o d e l o de análisis para el videojuego > obtiene un gran n ú m e r o de clases. Algunas se e n f o c a n en el a m b i e n t e del juego;; ejemplo, las e s c e n a s visuales que el usuario ve mientras se desarrolla el jueg: • Clases c o m o Árbol, P a i s a j e , C a m i n o , Pared, P u e n t e , Edificio, EfectoVis' podrían estar dentro de esta categoría. Otras se enfocan en los p e r s o n a j e s dentro ct. 1 juego al describir sus características físicas, acciones y restricciones. Se podrían de:" nir clases c o m o Jugador (la cual se describió con anterioridad), P r o t a g o n i s t a A n t a g o n i s t a y P a p e l e s d e S o p o r t e . Además, otras describen las reglas del jueg : c ó m o navega el jugador a través del ambiente. Aquí son c a n d id a tas clases con-/: R e g l a s D e M o v i m i e n t o y R e s t r i c c i o n e s E n A c c i ó n . Pueden existir m u c h a s o t r i í categorías. Estas clases pueden representarse c o m o los p a q u e t e s de análisis que SÍ muestran en la figura 8.19. El signo de m á s que precede al n o m b r e de la clase de análisis e n cada p a q u e a indica que las clases tienen visibilidad pública y que, por lo tanto, son accesibles desde otros paquetes. Aunque n o se m u e s t r a n e n esta figura, h a y otros símbolos que pueden preceder a un elemento dentro de un paquete. Un signo de m eTM n o s indica que un elemento está oculto de todos los otros paquetes, y un símbolo # indica que un elem e n t o es accesible sólo a las clases c o n te n id a s dentro de un p a q u e t e dado.

PDF Editor 8.8

CREACIÓN PE •

MODELO PE COMPORTAMIENTO

Los diagramas de clase, las tarjetas índice CRC y otros m o d e l o s orientados a las clas e s tratados e n la sección 8.7 r e p r e s e n t a n e l e m e n t o s estáticos del m o d e l o de análi-

CAPÍTULO 8

i se ilo i U softi «temo?

MODELADO DEL ANALISIS

235

sis. Ahora es tiempo de hacer u n a transición al c o m p o r t a m i e n t o dinámico del sistem a o producto. Para lograrlo el c o m p o r t a m i e n t o del sistema d e b e p r e s e n t a r s e c o m o u n a función de los elementos específicos y el tiempo. El modelo de comportamiento indica la forma en que el software responderá a los eventos o estímulos externos. En la creación del modelo el analista debe realizar los siguient e s pasos: 1. Evaluar todos los c a s o s de uso para e n t e n d e r por completo la secuencia de interacción d e n t r o del sistema.

kVE i • J»se E definir lograrlo, (•cose idfinde t e puntos de i*

2.

Identificar los e v e n t o s que c o n d u c e n la secuencia d e interacción y e n t e n d e r la forma e n que e s t o s e v e n t o s se relacionan con las clases específicas.

3 . Crear u n a secuencia para c a d a c a s o de uso. 4 . Construir u n diagrama de e s t a d o para el sistema. 5 . Revisar el m o d e l o de c o m p o r t a m i e n t o para verificar su exactitud y consistencia. Cada uno de e s t o s p a s o s se e x p o n e e n las secciones siguientes.

8.8.1 Identificación de eventos con el caso de uso C o m o se m e n c i o n ó en la sección 8.5, el c a s o de uso representa una secuencia de actividades que implica a los actores y al sistema. En general, siempre que el sistem a y un actor intercambian información ocurre un evento. Si se recuerda la explicación anterior acerca del m o d e l a d o del c o m p o r t a m i e n t o en la sección 8.6.3, será importante puntualizar que el e v e n t o n o e s la información que se ha intercambiado, s i n o el hecho de que la información haya sido intercambiada. Los p u n t o s del intercambio de información s e obtienen e x a m i n a n d o un c a s o de uso. A m a n e r a de ilustración, se reconsiderará el c a s o de uso para una p e q u e ñ a parte de la función de seguridad de HogarSeguro. El propietario utiliza el teclado para introducir una contraseña de cuatro dígitos. La contraseña se compara con la contraseña válida almacenada en el sistema. Si la contraseña es incorrecta, el panel de control emitirá un sonido por una sola vez y se reiniciará para esperar otra entrada. Si la contraseña es correcta, el panel de control esperará la acción posterior. Las p a r t e s s u b r a y a d a s del escenario del c a s o de u s o indican eventos. Se d e b e identificar a un autor para cada evento; la información intercambiada seTM d e b e anotar, y cualquier condición o restricción d e b e registrarse. C o m o ejemplo de un evento típico, considérese la frase subrayada del c a s o de u s o

PDF Editor

"el propietario utiliza el teclado p a r a introducir u n a c o n t r a s e ñ a de cuatro dígitos". En el contexto del modelo de análisis, el objeto, propietario, 2 5 transmite un evento al 25 En este ejemplo se asume que cada usuario (propietario) que interactúa con HogarSeguro tiene una contraseña de identificación y que, por lo tanto, es un objeto legítimo.

236

PARTE D O S


objeto P a n e l d e C o n t r o l . El evento podría llamarse introducción

de contraseña

información transferida son los cuatro dígitos que constituyen la contraseña. ésta no es una parte esencial del modelo de comportamiento. Es importante : que a l g u n o s e v e n t o s tienen u n impacto explícito sobre el flujo de control del i uso, mientras que otros no tienen impacto directo sobre el flujo de control. Por < pío, el evento introducción

de contraseña

no cambia de m a n e r a explícita el fluj: i

control del c a s o de uso, pero los resultados del evento comparación

de cont

(derivado de la interacción "la c o n t r a s e ñ a se compara con la c o n t r a s e ñ a vá a l m a c e n a d a en el sistema") tendrá u n impacto explícito sobre la información flujo de control del software de HogarSeguro. Una vez que se h a n identificado todos los eventos, éstos se ubican con los i tos involucrados. Los objetos pueden ser responsables de generar eventos (por < pío, P r o p i e t a r i o genera el e v e n t o de introducción

de contraseña)

o de recor

eventos que han ocurrido e n cualquier sitio (por ejemplo, P a n e l d e C o n t r o l re ce el resultado binario del evento comparación

de contraseña).

8.8.2 Representaciones de estado En el contexto del modelado del c o m p o r t a m i e n t o se pueden considerar dos dife tes caracterizaciones de los estados: 1) el e s t a d o de cada clase conforme el siste realiza su función, y 2) el e s t a d o del sistema c o m o se observa d e s d e el exterior ( forme el sistema realiza su función. 2 6 <5*

El e s t a d o de una clase implica características tanto pasivas c o m o activas [CHA^ Un estado pasivo es simplemente el estatus actual de todos los atributos de un obje

< & V E El sistemo tiene estados que representon un comportamiento especifico observable desde el exterior; una cióse tiene estados que representan su comportamiento cuando el sistema realiza sus funciones.

Por ejemplo, el e s t a d o pasivo de la clase Jugador (en la aplicación de videoji estudiada con anterioridad) incluiría los atributos de posición y orientación del Jugador ] así c o m o o t r a s características relevantes para el juego (por ejemplo, un atributo i indique la existencia de deseos mágicos). El estado activo de un objeto indica el esta' actual del objeto c u a n d o éste está sujeto a una transformación o a un procesamie to continuos. La clase Jugador podría tener los siguientes e s t a d o s activos: en, miento, en descanso, herido, en curación, atrapado, perdido, etcétera. Debe ocurrir i evento (algunas veces llamado un disparador) para obligar a un objeto a hacer transición de un estado activo a otro. En los párrafos siguientes se explican dos diferentes representaciones del cc portamiento. La primera indica la forma e n que una clase individual cambia sus es do con b a s e e n e v e n t o s externos, y la segunda muestra el c o m p o r t a m i e n t o del so:":TM w a r e c o m o u n a función del tiempo. D i a g r a m a s d e e s t a d o para c l a s e s d e análisis.

Un c o m p o n e n t e de un model

PDF Editor

]

del c o m p o r t a m i e n t o es un diagrama de e s t a d o en UML q u e representa los estad activos para cada clase y los eventos (disparadores) que ocasionan c a m b i o s entre ¡ 26 Los d i a g r a m a s de e s t a d o p r e s e n t a d o s en la sección 8.6.3 m u e s t r a n el e s t a d o del sistema. La expo sición en esta sección se enfocará al e s t a d o d e cada clase d e n t r o del modelo de análisis.

CAPÍTULO 8


237

Temporizador s TiempoCerrado

de estado • clase trol.

e s t o s e s t a d o s activos. En la figura 8.20 s e ilustra un d i a g r a m a de e s t a d o para la clase P a n e l d e C o n t r o l en la función d e seguridad d e HogarSeguro. Cada flecha en la figura 8.20 representa u n a transición d e s d e un e s t a d o activo de u n a clase hasta otro. Las etiquetas m o s t r a d a s para cada flecha representan el evento q u e dispara la transición. Aunque el m o d e l o de e s t a d o activo proporciona un discernimiento activo de la "historia de vida" de u n a clase, es posible especificar información adicional para proporcionar mayor profundidad en la comprensión del c o m portamiento de una clase. A d e m á s de especificar el e v e n t o que ocasiona la transición, el analista p u e d e especificar una guardia y u n a acción [CHA93]. Una guardia es u n a condición b o o l e a n a que d e b e satisfacerse para que ocurra la transición. Por M E de un * estado el ' sin las clases .un f e secuencia

ejemplo, la guardia para la transición desde el e s t a d o de "lectura" al e s t a d o de "comparación" de la figura 8.20 se p u e d e determinar al e x a m in a r el c a s o de uso: si (introducción d e c o n t r a s e ñ a = 4 dígitos), e n t o n c e s c o m p a r a r con c o n t r a s e ñ a a l m a c e n a d a

TM En general, la guardia para una transición por lo regular d e p e n d e del valor de u n o o m á s atributos d e un objeto. En o t r a s palabras, la guardia d e p e n d e del e s t a d o pasivo

PDF Editor del objeto.

-itool c forma en rcsesse * estado o

Una acción sucede de m a n e r a concurrente con la transición del e s t a d o o c o m o

consecuencia de éste, y por lo general implica u n a o m á s operaciones (responsabilidades) del objeto. Por ejemplo, una acción conectada con el evento contraseña intro-

ducida (figura 8.20) e s una operación llamada ValidarContraseña()

q u e da acceso a

238

PARTE D O S


Diagiama de secuencia (parcial) para la función de seguridad de HogarSeguro. ^ropietaiioj

Panel d e control

Sistema listo lis

<2>-

]

Sistema I

i

Sensores

Lectura

Contraseña introducida Solicitud d e búsqueda Resultado Contraseña = correcta

númerDelntenlos > Intentosmóximos

<2>

ú

| I 'j j

Solicitud d e activación

I

Temporizado; > Tiempocerrado

Selección Activación exitosa

1

I

Activación exitosa

un objeto de c o n t r a s e ñ a y realiza u n a comparación dígito por dígito para validar la c o n t r a s e ñ a introducida. Diagramas de secuencia.

El s e g u n d o tipo de representación de comportamien-

to, llamado un diagrama de secuencia en UML, indica c ó m o los eventos causan transiciones de objeto a objeto. Una vez que se h a n identificado los e v e n t o s al examinar u n c a s o de uso, el modelador crea un diagrama de secuencia: u n a representación de c ó m o los eventos c a u s a n un flujo de un evento a otro c o m o u n a función del tiempo. En esencia, el diagrama de secuencia es u n a versión abreviada del c a s o de uso. Representa clases clave y e v e n t o s que causan que el c o m p o r t a m i e n t o fluya de clase a clase. En la figura 8.21 se ilustra un diagrama de secuencia parcial de la función de seguridad de HogarSeguro.

Cada flecha representa un evento (derivado de un caso

de uso) e indica c ó m o el evento canaliza el c o m p o r t a m i e n t o entre los objetos de El tiempo se mide de m a n e r a vertical (hacia abajo),TM y los rectángulos

HogarSeguro.

verticales delgados representan el tiempo invertido en procesar u n a actividad. Los estados se pueden mostrar a lo largo de una línea de tiempo vertical.

PDF Editor

El primer evento, sistema listo, se deriva del ambiente externo y canaliza el c o m -

portamiento a un objeto de propietario. El propietario introduce una c o n t r a s e ñ a . Se pasa un evento de solicitud de búsqueda

al s i s t e m a , el cual busca la c o n t r a s e ñ a en

u n a b a s e de d a t o s simple y regresa un resultado

(encontrado

P a n e l d e C o n t r o l (ahora e n el e s t a d o de comparación).

o no encontrado)

al

Una c o n t r a s e ñ a válida resul-

CAPITULO 8

239


ta en un evento contraseña=correcta para el S i s t e m a , el cual activa los s e n s o r e s con un evento de solicitud de activación. Por último, el control se pasa de regreso al propietario con el evento activación exitosa. Una vez que se ha desarrollado un diagrama de secuencia completo, todos los eventos que ocasionan transiciones entre objetos del sistema se pueden cotejar con un conjunto de eventos de entrada y eventos de salida (de un objeto). Esta información e s útil en la creación de un diseño eficaz para el sistema que será construido. HERRAMIENTAS DE SOFTWARE

Modelado del análisis generalizado en UML O b j e t i v o : Las herramientas p a r a el modelado del análisis proporcionan la capacidad d e modelos b a s a d o s en escenarios, modelos en clases y modelos d e comportamiento mediante ¡UML. 3 Las herramientas en esta categoría soportan -ango d e d i a g r a m a s en UML requeridos p a r a u n modelo d e análisis (estas herramientas soportan el modelado del diseño). Además d e la x diagramas, las herramientas en esta categoría i lo verificación d e la consistencia y la corrección o s d i a g r a m a s en UML; 2) proporcionan vínculos á s e ñ o y la generación d e código; 3) construyen d e datos que ayudan a la administración y d e grandes modelos en UML requeridos p a r a complejos.

ArgoilML, una herramienta d e fuente abierta (argouml.tigris.org). Control Center, desarrollado por TogetherSoft (www.tagethersoft.com). Enterprise Archítect, desarrollado por Sparx Systems (www.sparxsystems.com.au). Object Technology Workbench

(OTW), desarrollado por

OTW Software (www.otwsoftware.com). Power Designer, desarrollado por Sybase (www.sybase.com). Rational Rose, desarrollado por Rational Corporation (www.rational.com). System Archítect, desarrollado por Popkin Software (www.popkin.com).

ÜS r e p r e s e n t a t i v a s 2 7

UML Studio, desarrollado por Pragsoft Corporation (www.pragsoft.com).

herramientas soportan un rango completo

Visio, desarrollado por Microsoft (www.microsoft.com).

en UML requeridos p a r a el modelado del

Visual UML, desarrollado por Visual Object Modelers (www.visualuml.com).

El objetivo del modelado del análisis e s crear una variedad de representaciones que muestran los requisitos del software para la información, la función y el comportaTM(pero potenmiento. Esto se logra aplicando dos diferentes filosofías de modelado cialmente complementarias): el análisis estructurado y el análisis orientado a objetos. El análisis estructurado considera al software c o m o un transformador de infor-

PDF Editor

27 Las h e r r a m i e n t a s m e n c i o n a d a s aquí son una m u e s t r a d e esta categoría. En la mayoría d e los c a s o s los n o m b r e s están registrados por sus respectivos desarrolladores

240

PASTE DOS


mación. Éste ayuda al ingeniero de software a identificar los objetos de datos, relaciones y la manera en la cual estos objetos de datos se transforman mientras yen a través de las funciones de procesamiento del software. El análisis orient objetos examina un dominio de problema definido como un conjunto de casos uso en un esfuerzo por extraer clases que definen el problema. Cada clase tiene conjunto de atributos y operaciones. Las clases están relacionadas entre sí en i variedad de formas diferentes y se moldean mediante la aplicación de diagramas i UML. El modelo d e análisis lo componen cuatro elementos de modelado: me basados en escenarios, modelos de flujo, modelos basados en clases y modelos comportamiento. Los modelos basados en escenarios muestran los requisitos del software desee punto de vista del usuario. El caso de uso —una descripción narrativa o basada una plantilla de una interacción entre un actor y el software— es el elemento mario del modelado. El caso de uso, derivado durante la obtención de r e q u r define los casos clave para una función o interacción específica. El grado de fr lidad y detalle del caso de uso varía, pero el resultado final proporciona la en necesaria a las otras actividades de modelado del análisis. Los escenarios tam pueden describirse por medio de un diagrama de actividad: una representación fica del tipo de un diagrama de flujo que muestra el flujo del procesamiento d e de un escenario específico. Los diagramas de carril ilustran la forma en que el de procesamiento incumbe a varios actores o clases. Los modelos de flujo se enfocan en el flujo de objetos de datos conforme las ciones de procesamiento los transforman. Los modelos de flujo, que se derivan análisis estructurado, utilizan el diagrama de flujo de datos; ésta es una notación modelado que muestra la manera en que una entrada se transforma en una conforme los objetos de datos se mueven a través del sistema. Cada función del ware que transforma datos se describe mediante una especificación del proc* narrativa. Además del flujo de datos, este elemento de modelado también mu el flujo de control (una representación que ilustra la forma en que los eventos tan el comportamiento del sistema). El modelado basado en clases utiliza información derivada de elementos modelado orientado al flujo y basado en escenarios para extraer clases candida" atributos y operaciones de las narrativas basadas en texto. Se establecen los c rios para la definición de una clase. La tarjeta índice clase-responsabilidad-col rador puede usarse en la definición de relaciones entre las clases.TM Además, se p aplicar una variedad de notaciones de modelado en UML para definir jerarqi relaciones, asociaciones, agregaciones y dependencias entre las clases. Los pa tes de análisis se utilizan para categorizar y agrupar clases de manera que sean rrc manejables para los sistemas grandes. Los primeros tres elementos del modelado del análisis proporcionan una visi: estática del software. Los modelos de comportamiento muestran un desemp

PDF Editor

dinámico. El modelo de comportamiento utiliza la entrada de elementos basados

CAPÍTULO 8


241

escenarios, orientados al flujo y basados en clases para representar los estados de las clases de análisis y del sistema como un todo. Esto se logra identificando los estados, definiendo los eventos que ocasionan que una clase (o sistema) tenga una transición de un estado a otro, e identificando las acciones que suceden cuando se realiza la transición. En el modelado del comportamiento se utiliza la notación en UML de los diagramas de estado y los diagramas de secuencia.

[ABB83] Abbott, R., "Program Design by Informal English Descriptions", en CACM, vol. 26, núm. 11, noviembre de 1983, pp. 892-894. [AMB95] Ambler, S„ "Using Use-Cases", en Software Development, julio de 1995, pp. 53-61. [ARA89] Arango, G. y R. Prieto-Diaz, "Domain Analysis: Concepts and Research Directions", en Domairt Analysis: Acquisition of Reusable Information for Software Construction, (Arango, G. y R. Prieto-Diaz, eds.), IEEE Computer Society Press, 1989. [ARL02] Arlow,). e I. Neustadt, UML and the Unified Process, Addison-Wesley, 2002. [BER93] Berard, E. V., Essays on Objetc-Oriented Software Engineering, Addison-Wesley, 1993. [BOO86] Booch, G„ "Object-Oriented Development", en IEE Trans. Software Engineering, vol. SE12, n ú m . 2, febrero de 1986, pp. 21 lff. [BUD96] Budd, T., An Introduction to Objetc-Oriented Programming, 2a. ed., Addison-Wesley, 1996. [CAS89] Cashman, M., "Object-Oriented Domain Analysis", en ACM Software Engineering Notes, vol. 14, núm. 6, octubre de 1989, p. 67. [CHA93] de Champeaux, D., D. Lea y P. Faure, Object-Oriented System Development, AddisonWesley, 1993. [CHE77] Chen, P., The Entity-Relationship Approach to Logical Database Design, QED Information Systems, 1977. [COA91] Coad, P. y E. Yourdon, Object-Oriented Analysis, 2a. ed., Prentice-Hall, 1991. [COCO 1 ] Cockburn, A., Writing Effective Use Cases, Addison-Wesley, 2001. [DAV93] Davis, A„ Software Requirements: Objects, Functions and States, Prentice-Hall, 1993. [DEM79] DeMarco, T., Structured Analysis and System Speciftcation, Prentice-Hall, 1979 [FIR93] Firesmith, D. G., Object-Oriented Requirements Analysis and Logical Design, Wiley, 1993. [LET03] Lethbridge, T., comunicación personal sobre el análisis del dominio, mayo d e 2003. [OMG03] Object M a n a g e m e n t Group, OMG Unified Modeling Language Specification, versión 1.5, m a r z o d e 2003, disponible en h t t p : / / w w w . r a t i o n a l . c o m / u m l / r e s o u r c e s / d o c u m e n t a tion/. [SCH02] Schmuller, J., Teach Yoursel/UML in 24 Hours, 2a. ed., SAMS Publishing 2002. [SCH98J Schneider, G. y J. Winters, Applying Use Cases, Addison-Wesley, 1998. [STR88] Stroustrup, B., "What is Object-Oriented Programming?", en IEEE Software, vol. 5, núm. 3, m a y o de 1988, pp. 10-20. [TAY90] Taylor, D. A., Object-Oriented Technology: A Manager s Guide, Addison-Wesley, 1990. [THA00] Thalheim, B„ Entity Relationship Modeling, Springer-Verlag, 2000. [TIL931 Tillmann, G., A Practical Guide to Logical Data Modeling, McGraw-Hill, 1993. [UML03] The UML Café, "Customers Don't Print Themselves", disponible TMen h t t p : / / w w w t h e u m l c a f e . c o m / a 0 0 7 9 . h t m , mayo d e 2003. (WIR90) Wirfs-Brock, R., B. Wilkerson y L. Weiner, Designing Object-Oriented Software, PrenticeHall, 1990.

PDF Editor

8 . 1 . ¿Es posible c o m e n z a r a codificar inmediatamente d e s p u é s d e haber c r e a d o el modelo d e análisis? Explicar la respuesta y d e s p u é s justificar los p u n t o s en contra.

242

PARTE D O S


8 . 2 . Un análisis práctico e s aquel e n el cual el m o d e l o "debe e n f o c a r s e e n los requisitos que son visibles d e n t r o de los dominios del p r o b l e m a o del negocio". ¿Cuáles tipos d e requisitos nc s o n visibles e n e s t o s dominios? Dar a l g u n o s ejemplos. 8 . 3 . ¿Cuál e s el propósito del análisis del d o m i n i o ? ¿Cómo s e relaciona c o n el c o n c e p t o d e los p a t r o n e s d e requisitos? 8.4. En u n a s c u a n t a s líneas, trátese de describir las diferencias primordiales e n t r e el análisis e s t r u c t u r a d o y el análisis o r i e n t a d o a objetos. 8.5. ¿Es posible desarrollar u n m o d e l o de análisis eficaz sin desarrollar los c u a t r o e l e m e n t o s q u e s e m u e s t r a n e n la figura 8.3? Explicar la r e s p u e s t a . 8 . 6 . S u p ó n g a s e q u e h a n p e d i d o construir u n o d e los siguientes s i s t e m a s . a) b) c) d)

Un registro de c u r s o s b a s a d o e n red p a r a u n a universidad. Un s i s t e m a p r o c e s a d o r de ó r d e n e s b a s a d o e n Internet para u n a tienda d e c o m p u t a d o r a s Un s i s t e m a simple de facturación para u n n e g o c i o p e q u e ñ o . El s o f t w a r e q u e r e e m p l a c e un Rolodex y q u e s e e n c u e n t r e d e n t r o de u n teléfono inalámbrico. e) Un libro d e cocina a u t o m á t i c o q u e e s t é construid o d e n t r o d e u n h o r n o eléctrico o de microondas.

S e l e c c i ó n e s e el s i s t e m a q u e s e c o n s i d e r e i n t e r e s a n t e y d e s c r í b a n s e s u s o b j e t o s d e datos, relac i o n e s y atributos. 8.7. Dibujar u n m o d e l o al nivel d e c o n t e x t o (DFD d e nivel 0) para u n o d e los cinco s i s t e m a s q u e s e listan e n el p r o b l e m a 8.6. Escribir una narrativa del p r o c e s a m i e n t o p a r a el s i s t e m a al nivel d e contexto. 8 . 8 . Utilizar el DFD al nivel de c o n t e x t o desarrollado e n el p r o b l e m a 8.7 p a r a dibujar los diag r a m a s d e (lujo d e los niveles 1 y 2. P a r a c o m e n z a r , utilícese u n "análisis gramatical" e n la narrativa del p r o c e s a m i e n t o al nivel de contexto. Recuérdese especificar t o d o el fluido de inform a c i ó n m i e n t r a s rotula t o d a s las flechas q u e s e e n c u e n t r a n e n t r e las b u r b u j a s . Ú s e n s e n o m b r e s significativos para c a d a t r a n s f o r m a c i ó n . 8.9. Desarróllense especificaciones de control (EC) y especificaciones d e p r o c e s o (EP) p a r a e: s i s t e m a q u e seleccionó e n el p r o b l e m a 8.6. Trátese de q u e el m o d e l o s e a lo m á s c o m p l e t o posible. 8 . 1 0 . El d e p a r t a m e n t o d e o b r a s públicas de u n a ciudad g r a n d e h a decidido desarrollar un sist e m a d e r a s t r e o y r e p a r a c i ó n de b a c h e s b a s a d o e n la Web (SRRB). Se incluye la siguiente descripción: Los c i u d a d a n o s p u e d e n e n t r a r al sitio Web y reportar la ubicación y severidad de los b a c h e s . C u a n d o é s t o s s e reportan e n t r a n a u n "sistema d e r e p a r a c i ó n del d e p a r t a m e n t o de o b r a s públicas", d o n d e se les asigna un n ú m e r o d e identificación, junto con la dirección de la calle, el t a m a ñ o (en u n a escala de 0 a 10), la ubicación (en la orilla d e la calle, e n medio, etcétera), el distrito ( d e t e r m i n a d o p o r la dirección d e la calle), y la urgencia d e la reparación (determinada p o r el t a m a ñ o del bache). Los d a t o s d e la o r d e n d e t r a b a j o e s t á n a s o c i a d o s con c a d a b a c h e e incluyen la ubicación y el t a m a ñ o del b a c h e , n ú m e r o de identificación de la reparación, cantidad de p e r s o n a l n e c e s a r i o , h o r a s a p l i c aTM d a s a la reparación, e s t a d o del b a c h e (trabajo en progreso, r e p a r a d o , r e p a r a d o e n f o r m a temporal, n o r e p a r a do), cantidad d e material de relleno utilizado, y c o s t o de la reparación (cálculo d e las h o r a s aplicadas, n ú m e r o de p e r s o n a s , material y equipo utilizados). Por último, s e crea un archivo d e d a ñ o s para registrar información sobre averías r e p o r t a d a s debido a los b a c h e s , el cual incluye n o m b r e del c i u d a d a n o , dirección, n ú m e r o telefónico, tipo d e d a ñ o , precio del d a ñ o e n dólares. El SRRB e s un s i s t e m a b a s a d o e n la Web; t o d a s las p e t i c i o n e s se h a c e n e n forma interactiva.

PDF Editor

Con b a s e e n u n a notación de análisis e s t r u c t u r a d a , desarrolle un m o d e l o de análisis p a r a el SRRB.

CAPÍTULO 8

8.11.


243

Describir los términos orientados a objetos encapsulaciórt y herencia.

8.12. Escribir un c a s o de uso b a s a d o en u n a plantilla para el sistema d e gestión p a r a el hogar HogarSeguro, descrito d e m a n e r a informal en un recuadro ubicado enseguida de la sección 8.7.4. 8.13. Dibujar un diagrama d e c a s o d e uso en UML para el sistema SRRB p r e s e n t a d o en el problema 8. 10. Tendrán q u e h a c e r s e varios s u p u e s t o s sobre la m a n e r a en que el usuario interactúa con e s t e sistema. 8.14. Desarrollar un modelo de clase para el sistema SRRB p r e s e n t a d o en el problema 8.10. 8.15. Desarrollar un conjunto completo de tarjetas índice del modelo CRC para el sistema SRRB p r e s e n t a d o en el problema 8.10. 8 . 1 6 . Encabezar una revisión de las tarjetas índice de CRC con s u s colegas. ¿Cuántas clases adicionales, responsabilidades y colaboradores fueron a g r e g a d o s c o m o consecuencia de la revisión? 8 . 1 7 . Describir la diferencia entre u n a asociación y u n a d e p e n d e n c i a para u n a clase de análisis. 8.18. ¿Qué e s un paquete d e análisis y c ó m o debe utilizarse? 8.19. ¿De qué m a n e r a difiere un diagrama de estado p a r a clases de análisis d e los d i a g r a m a s d e estado p r e s e n t a d o s para el sistema completo?

•* Se h a n publicado d o c e n a s d e libros sobre análisis estructurado. En la mayoría se trata el t e m a de u n a m a n e r a adecuada, pero sólo en unos c u a n t o s se presenta un trabajo en verdad excelente. DeMarco y Plauger (Structured Analysis and System Specification, Pearson, 1985) es un clásico que sigue siendo u n a b u e n a introducción a la notación básica. Los libros d e Kendal y Kendal (Systems Analysis and Design, 5a. ed., Prentice-Hall, 2002) y Hoffer eí al. (Modern Systems Analysis and Design, Addison-Wesley, 3a. ed., 2001) son referencias valiosas. El libro d e Yourdon (Modern Structured Analysis, Yourdon-Press, 1989) sobre el t e m a se conserva entre las publicaciones m á s completas a la fecha. Alien (Dato Modeling for Everyone, Wrox Press, 2002), Simpson y Witt (Data Modeling Essentials, 2a. ed., Coriolis Group, 2000), Reingruber y Gregory (Data Modeling Handbook, Wiley, 1995) p r e s e n t a n guías detalladas p a r a crear modelos d e datos relacionados con la calidad industrial. Un interesante libro d e Hay (Dato Modeling Patterns, Dorset House, 1995) presenta p a t r o n e s de modelos de d a t o s típicos q u e se encuentran en m u c h o s negocios diferentes. Un tratamiento detallado del modelado del comportamiento puede encontrarse en Kowal (Behavior Models: Speájying User's Expectations, Prentice-Hall, 1992). Los c a s o s d e u s o son la b a s e del análisis orientado a objetos. Los libros de Bittner y Spence (Use Case Modeling, Addison-Wesley, 2002), Cockburn [COCOl], Armour y Miller {Advanced UseCase Modeling: Software Systems, Addison-Wesley, 2000) y Rosemberg y Scot (Use-Case Driven Object Modeling with UML: A Practical Approach, Addison-Wesley, 1999) proporcionan u n a guía valiosa en la creación y uso de este importante m e c a n i s m o d e representación y logro d e requeTM rimientos. Arlow y Neustadt h a n escrito apreciables análisis del UML [ARL02], Schmuller [SCH02], Fowlery Scott (UML Distilled, 2a. ed., Addison-Wesley, 1999), Booch y s u s colegas (The UML User Cuide, Addison-Wesley, 1998) y Rumbaugh y s u s colegas (The Unified Modeling Language Reference Manual, Addison-Wesley, 1998). Los m é t o d o s de análisis y diseño que a p o y a n el proceso unificado los explica Larman (Appfying UML and Pattems: An Introducüon to Object-Oriented Analysis and Design and the Unified process, 2a. ed., Prentice-Hall, 2001), Dennis y s u s colegas (Siystem Analysis and Design: An Object-Oriented Approach with UML, Wiley, 2001), y Rosenberg y Scott (Use-Case Driven Object Modeling with UML, Addison-Wesley, 1999), Balcer y Mellor (Executable UML: A Foundation for

PDF Editor

244

PARTE D O S


Model Driven Architecture, Addison-Wesley, 2002) e x p o n e n la semántica general del UML, los modelos q u e se p u e d e n crear, y u n a forma d e considerar el UML c o m o un lenguaje ejecutable Starr (Executable UML: How to Build Class Models, Prentice-Hall, 2001) ofrece u n a guia útil y s u g e r e n c i a s detalladas para crear clases d e diseño y análisis efectivos. En Internet se dispone d e u n a gran variedad d e f u e n t e s d e información sobre el modelado del análisis. En el sitio SEPA se p u e d e encontrar u n a lista actualizada de referencias d e la red q u e son notables p a r a el m o d e l a d o del análisis: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P Í T U L O

INGENIERÍA DEL D I S E Ñ O ICEPTOS re

....252 tm .. .253 i * ....259 ....259 W ...262 ....256 ...254 it ...256 254 •m.,.258 >...257

9

L

a ingeniería del diseño abarca un c o n j u n t o de principios, c o n c e p t o s y prácticas q u e c o n d u c e n al desarrollo de un sistema o producto de alta calidad. Los principios del diseño (explicados e n el capítulo 5) establecen una filosofía primordial que guían al diseñador e n el trabajo que d e s e m p e ñ a . Es necesario c o m p r e n d e r los conceptos del diseño a n t e s d e que se apliquen las m e c á n i c a s d e la práctica del diseño, y la práctica del d i s e ñ o m i s m o c o n d u c e a la creación de varias representaciones del software, el cual sirve c o m o guía para la actividad de construcción q u e sigue. La ingeniería del diseño n o es una frase c o m ú n dentro del contexto de la ingeniería del software. Sin embargo, debería serlo. El d i s e ñ o es una actividad primordial d e la ingeniería. A principios de la década de 1990, Mitch Kapor, el creador de Lotus 1-2-3, presentó un "manifiesto sobre el diseño de software" e n Dr. Dobbs Journal. Ahí afirma: ¿Qué e s el diseño? Es el lugar en d o n d e u n a persona se p u e d e parar con un pie en dos m u n d o s —el m u n d o d e la tecnología y el de la gente y los propósitos h u m a n o s — e intenta unirlos... El crítico d e arquitectura r o m a n a Vitruvius aportó la noción d e que las construcciones bien diseñadas e r a n aquellas que mostraban firmeza, c o m o d i d a d y placer. Lo mismo d e b e decirse del buen software. Firmeza

el programa no debe tener ningún

error que inhiba su función. Comodidad-, un programa d e b e cumplir c o n los propósit o s para los q u e fue creado. Placer• la experiencia d e usar el programa d e b e ser agra dable. Aquí se p r e s e n t a n los principios d e una teoría d e diseño para software.

¿ Q u é e s ? El diseño es lo que casi cualquier ingeniero quiere hacer. Es el sitio donde manda la creatividad, donde los requisitos del cliente, las necesidades de negocio y las consideraciones técnicas se unen en la formulación de un producto o sistema. El diseño crea una -«presentación o modelo del software, pero a 3¡ferencia del modelo de análisis (que se enfoca en la descripción de los datos, las funciones y el omportamiento requeridos), el modelo de diseo proporciona detalles acerca de las estructu-as de datos, las arquitecturas, las ¡nterfaces y os componentes del software que son necesarios rara implementar el sistema.

¿ Q u i é n l o h a c e ? Los ingenieros de software encabezan cada una de las tareas de diseño. ¿ P o r q u é e s i m p o r t a n t e ? El diseño permite al ingeniero de software modelar el sistema o producto que se va a construir. Este modelo puede evaluarse en relación con su calidad y mejorarse antes de generar código, de realizar pruebas y de que los usuarios finales se vean TM involucrados a gran escala. El diseño es el sitio en el que se establece la calidad del software. ¿ C u á l e s s o n los p a s o s ? El diseño presenta el software de diferentes formas. Primero, debe representarse la arquitectura del sistema o producto. Después, se modelan las ¡nterfaces que conecta" e software con los usuarios finales,

PDF Editor

245

246

PARTE D O S


con otros sistemas y dispositivos y con los propios componentes que lo constituyen. Por último, se diseñan los componentes del software que se utilizarán en la construcción del el sistema. Cada una de estas visiones representa una acción de diseño diferente, pero todas deben ajustarse a un conjunto de conceptos básicos del diseño que determinan todo el trabajo de diseño. ¿ C u á l e s e l p r o d u c t o o b r e n i d o ? Un modelo que abarca representaciones arquitectónicas, de

interfaz, en e! nivel de componentes y de despliegue. >/ ¿ C ó m o p u e d o e s t a r s e g u r o d e q u e lo h e h e c h o c o r r e c t a m e n t e ? El modelo de d i s e ; : lo evalúa e! equipo de software en un esfuer: encaminado a determinar si éste contiene e r —r res, inconsistencias u omisiones; si existen m e res alternativas; y si el modelo puede implem tarse dentro de las restricciones, el itinerario \ i costo que Han sido establecidos. ¿C

La meta de la ingeniería del diseño es producir u n modelo de representador, :M muestre firmeza, comodidad y placer. Para lograrlo, un diseñador d e b e practica- • diversificación y d e s p u é s la convergencia. Belady [BEL81] establece que "la dive J ficación es la adquisición de u n repertorio de alternativas, la materia prima del ¿ . s i ño: c o m p o n e n t e s , soluciones de c o m p o n e n t e s y conocimiento, t o d o contenidc : • catálogos, libros de texto y en la mente". Una vez q u e se ha integrado e s t e conj _ - j a de información, el diseñador d e b e elegir y t o m a r e l e m e n t o s del repertorio que plan los requisitos definidos por la ingeniería de requisitos (capítulo 7) y el m o c e B de análisis (capítulo 8). Cuando e s t o ocurre, se consideran y se r e c h a z a n las a l t e a nativas, y el ingeniero de diseño converge en "una configuración particular de c c o B p o n e n t e s y, por lo tanto, e n la creación del producto final" [BEL81], La diversificación y la convergencia d e m a n d a n intuición y juicio. Estas cualida; J están b a s a d a s en la experiencia de construir entidades similares, un conjunto principios que guían c ó m o evoluciona el modelo, un conjunto de criterios que p e J miten juzgar la calidad, y u n p r o c e s o de iteración que conduce a u n a r e p r e s e n t a r • del diseño final. La ingeniería del diseño para el s o f t w a r e de c o m p u t a d o r a está e n un cambio CCOH tinuo, en la medida en que evolucionan m e j o r e s m é t o d o s , m e j o r e s análisis y - J comprensión m á s amplia. Aun e n la actualidad, la mayoría de las metodologías diseño de s o f t w a r e carecen de profundidad, flexibilidad y naturaleza cuantitatr. a., que por lo general se asocian con disciplinas de diseño de ingeniería más clásica I TM Sin e m b a r g o , existen m é t o d o s para el diseño de software, se dispone de c r i t e - : « para la calidad del diseño, y es posible aplicar notación de diseño. En este capit

PDF Editor

se explorarán los conceptos y principios f u n d a m e n t a l e s aplicables a t o d o el d i s e ñ J de software, los e l e m e n t o s del modelo del diseño y el impacto de los p a t r o n e s s o tJ el proceso de diseño. En los capítulos 10, 11 y 12 se e x a m in a u n a variedad de m é : : dos de diseño de s o f t w a r e mientras se aplican al diseño arquitectónico, de i n t e r a J y e n el nivel de c o m p o n e n t e s .

CAPÍTULO 9

9.1

247


D I S E Ñ O D E N T R O DEL C O N T E X T O DE LA I N G E N I E R Í A DEL SOFTWARE El diseño del s o f t w a r e se encuentra en el núcleo técnico de la respectiva ingeniería y se aplica de m a n e r a independiente al modelo de s o f t w a r e que se utilice. Una vez que se analizan y especifican los requisitos, el diseño del software es la última acción de la ingeniería correspondiente d e n t r o de la actividad del modelado, la cual establece una plataforma para la construcción (generación de código y pruebas).

*

"El milagro m á s común de la in geniería d e software es la transición del análisis al c s e ñ o y del diseño al código." Richard Due

ide

tsiempre rrarwfe-

Cada uno d e los e l e m e n t o s del modelo de análisis (capítulo 8) proporciona la información necesaria para crear los cuatro modelos de diseño que se requieren

ipara tos ¡ del diseño, té que se ha i é fundoixbe laaquitec:9toncesse r otras (¿seño.

para u n a especificación completa de diseño. En la figura 9.1 s e ilustra el flujo de información durante el d i s e ñ o del software. Los requisitos del software que m u e s tran los e l e m e n t o s b a s a d o s en escenarios, b a s a d o s en clases, orientados al flujo y de comportamiento alimentan la tarea de diseño. Mediante la notación de diseño y de los m é t o d o s de diseño que se e x p o n e n en capítulos posteriores, la tarea de diseño prod u c e un diseño de datos-clase, un diseño arquitectónico, un diseño de interfaz y un diseño de c o m p o n e n t e s . El diseño de datos-clase transforma los modelos de análisis y clases (capítulo 8) en las clases de diseño y las estructuras de d a t o s que se requieren para implemen-

Trcmsformaclón del modelo de análisis en un modelo de diseño.

tin ento s b a s a d o s en e s c e n a r i o s ramas iramas ira mas Elementos b a s a d o s en clases >ogramas de clase ; :quetes de análisis vtodelos CRC D agramas de colaboración

D i s e ñ o en el nivel de componentes Diagramas de flujo de dalos Diagramas de flujo de control Narrativas de procesamiento Diseño d e interfaz Modelo de análisis J Elementos d e comportamiento Diagramas de estado Diagramas de secuencia

D i s e ñ o a r q u i t e c t ó n i cTM o

PDF Editor Diseño d e d a t o s / d a s e

Modelo de diseño

248

PARTE D O S


tar el software. Las clases y relaciones que definen las tarjetas índice CRC y el contenido detallado de d a t o s que m u e s t r a n los atributos de clase y otras notaciones proporcionan la b a s e para la actividad de diseño de datos. Una parte del diseño de clas e s p u e d e ocurrir en conjunto con el diseño de la arquitectura del software. El diseño de clase m á s detallado se realiza a medida que se diseña c a d a c o m p o n e n t e del software. El diseño arquitectónico define la relación entre los e l e m e n t o s estructurales más importantes del software, los estilos arquitectónicos y p a t r o n e s de diseño que pueden usarse para satisfacer los requisitos definidos por el sistema, y las restricciones que afectan la m a n e r a en que se pueden implementar los p a t r o n e s arquitectónicos [SHA96]. La representación del diseño arquitectónico —el m a r c o de trabajo de un sistema b a s a d o en computadora— p u e d e derivarse de la especificación del sistema, del m o d e l o de análisis y de la interacción de los s u b s i s t e m a s definidos d e n t r o del m o d e l o de análisis. El diseño de la interfaz describe la forma e n que el s o f t w a r e se c o m u n i c a con los sistemas q u e interactúan con él y con los h u m a n o s que los utilizan. Una interfaz implica un flujo de información (por ejemplo, d a t o s o control) y un tipo de comportamiento especifico. Por lo tanto, los escenarios de uso y los modelos de comportamiento proporcionan m u c h a de la información que se requiere en el diseño de la interfaz. El diseño al nivel de c o m p o n e n t e s transforma los e l e m e n t o s estructurales de la arquitectura del s o f t w a r e e n u n a descripción procedimental de los c o m p o n e n t e s de éste. La información obtenida de los m o d e l o s b a s a d o s e n clases, los modelos de flujo y los m o d e l o s de c o m p o r t a m i e n t o sirven c o m o b a s e para el diseño de c o m p o n e n t e s "Existen dos f o r m a s d e construir un diseño de software. Una forma es hacerlo tan simple que obviamente no hay deficiencias, y lo otra es hacerlo tan complicado q u e no existen deficiencias obvias. El primer método es mucho más difícil." CA.R. Honre

Durante el diseño se t o m a n decisiones que al final incidirán en el éxito de la construcción del software, así c o m o en, con el m i s m o grado de importancia, la facilidad con que el s o f t w a r e p u e d e m a n t e n e r s e . Pero, ¿por qué es tan importante el d i s e ñ o ' La importancia del diseño del s o f t w a r e p u e d e describirse con u n a sola palabra: calidad. El diseño es la etapa e n la que se f o m e n t a r á la calidad en la ingeniería de! TM software. El diseño proporciona las representaciones del s o f t w a r e susceptibles de evaluar respecto de la calidad. El diseño es la única forma en que, de m a n e r a exacta, u n requisito del cliente se p u e d e convertir en un sistema o producto de software

PDF Editor

terminado. El diseño del s o f t w a r e sirve c o m o f u n d a m e n t o para t o d a s las actividades s u b s e c u e n t e s de la ingeniería del s o f t w a r e y del soporte de éste. Sin diseño se corre el riesgo de construir un sistema inestable, el cual fallará c u a n d o se realicen cambios pequeños; que será difícil de probar; cuya calidad no podrá evaluarse sino hasta

CAPÍTULO 9


249

e t a p a s tardías del proceso del software, c u a n d o queda p o c o tiempo y ya se ha g a s t a d o m u c h o dinero e n él. 9.2

P R O C E S O Y C A L I D A D DEL D I S E Ñ O El diseño del s o f t w a r e es u n proceso iterativo mediante el cual los requisitos s e traducen e n u n "plano" para construir el software. Al inicio, el plano representa una visión holística del software. Es decir, el diseño se representa e n un grado alto de abstracción, el cual p u e d e rastrearse de m a n e r a directa h a s t a conseguir el objetivo específico del sistema y requisitos m á s detallados de comportamiento, funcionales y de datos. A medida en q u e o c u r r e n las iteraciones del diseño, un refinamiento s u b siguiente c o n d u c e a representaciones del diseño a grados m u c h o m á s b a j o s de abstracción. Estos grados a ú n se p u e d e n rastrear hasta los requisitos, p e r o la conexión es m á s sutil. A través del p r o c e s o del diseño, la calidad en evolución de é s t e se evalúa con u n a serie de revisiones técnicas formales o con revisiones de diseño explicadas en el capítulo 26. McGlaughlin [MCG91] sugiere tres características que sirven c o m o guía en la evaluación de un buen diseño: • El diseño d e b e implementar todos los requisitos explícitos contenidos en el modelo de análisis, y d e b e a j u s t a r s e a t o d o s los requisitos implícitos que desea el cliente. • El diseño debe ser una guía legible y comprensible para quienes g e n e r a n código y quienes realizan p r u e b a s y, en consecuencia, dan soporte al software. • El d i s e ñ o d e b e proporcionar una imagen completa del software —dando dirección a los dominios de datos, funcionales y de comportamiento— desde u n a perspectiva de implementación. Cada u n a de e s t a s características es e n realidad una m e t a del p r o c e s o de diseño. Pero, ¿ c ó m o se alcanza cada u n a de ellas? "Escribir una brillante pieza de código que funcione es una cosa; diseñar algo q u e pu e d a soportar a largo plazo un negocio es otra muy diferente." C Fergusoit D i r e c t r i c e s d e calidad.

TM Con el fin de evaluar la calidad de u n a representación d e

diseño se deben establecer los criterios técnicos para un b u e n diseño. En secciones posteriores de e s t e capítulo se e x p o n d r á n los conceptos de diseño que también sir-

PDF Editor

ven c o m o criterios de calidad del software. Por a h o r a s e p r e s e n t a n las siguientes directrices:

1. Un diseño d e b e presentar u n a estructura arquitectónica que a) se haya creado mediante p a t r o n e s de diseño reconocibles, b) la integren c o m p o n e n t e s que

250

PARTE DOS


exhiban b u e n a s características de diseño (éstas se explican m á s adelante e r

*® ¿Cuáles son • las características de un buen d i s e ñ o ?

este capítulo), y c) p u e d a implementarse de m a n e r a evolutiva,' para que de esta forma facilite la implementación y las pruebas. 2.

Un diseño d e b e ser modular, e s t o es, el s o f t w a r e deberá dividirse de m a n lógica en e l e m e n t o s o subsistemas.

3 . Un diseño d e b e contener distintas representaciones de los datos, la arquite: tura, las interfaces y los c o m p o n e n t e s . 4.

Un diseño d e b e conducir a estructuras de datos q u e sean a p r o p i a d a s para clases que h a b r á n de implementarse y que p r o c e d a n de p a t r o n e s de datos conocibles.

5 . Un diseño debe conducir a c o m p o n e n t e s que presenten características f> nales independientes. 6. Un diseño d e b e conducir a interfases que reduzcan la complejidad de las cc- ] nexiones entre los c o m p o n e n t e s y el ambiente externo. 7.

Un diseño d e b e o b t e n e r s e por m e d i o de un m é t o d o repetible que se b a s e er información obtenida durante el análisis de requisitos del software.

8.

Un diseño debe representarse por medio de u n a notación que comunique ce m a n e r a eficaz su significado.

Estas directrices de diseño no se logran por casualidad. El p r o c e s o de diseño del w a r e fomenta el buen diseño aplicando principios f u n d a m e n t a l e s d e diseño, metodología sistemática y u n a revisión cuidadosa. INFORMACIÓN

Evaluación de la calidad del diseño: la revisión técnica formal El diseño es importante porque permite que un equipo de software evalúe la calidad 2 del software antes

hacer un resumen d e la técnica en este punto. Una RTF es una reunión que dirigen miembros del equipo d e softwa-e

de ¡mplementarlo; es decir, en un momento en el q u e los

Por lo general participan dos, tres o cuatro personas,

errores, omisiones o inconsistencias son fáciles de corregir

d e p e n d e del ámbito de la información d e diseño que se

y no resultan caras. Pero ¿cómo se evalúa la calidad

revisará. C a d a persona desempeña un papel: el líder de

durante el diseño? El software no se puede comprobar

revisión planea la reunión, establece la a g e n d a y después

porque no existe un software ejecutable al cual aplicarle

realiza la reunión; el relator toma notas p a r a que n a d a se

pruebas. ¿ Q u é d e b e hacerse?

olvide; el productor es la persona cuyo producto d e traba-: (por ejemplo, el diseño de un componente del software) se

Durante el diseño, la calidad se evalúa al realizar una serie d e revisiones técnicas formales (RTF). Las RTF se

revisa. Antes de la reunión, c a d a persona en el equipo de

tratan con detalle en el capítulo 2 6 , 3 pero resulta valioso

revisión recibe una copia del producto TMd e trabajo del

V

PDF Editor 1

Para sistemas m á s p e q u e ñ o s a l g u n a s veces el diseño p u e d e desarrollarse en forma lineal.

2

Los factores de calidad tratados en el capítulo 15 pueden ayudar al equipo de revisión mientras

evalúa la calidad.

3

En e s t e punto se podría considerar la revisión d e la sección 26.4. Las RTF son una parte crítica

proceso de diseño y un m e c a n i s m o importante para lograr la calidad del diseño.

CAPÍTULO 9

251


• se le pide que lo lea en busca d e errores, o ambigüedades. C u a n d o la reunión comienza, ' es detectar todos los problemas del producto : p a r a q u e éstos puedan corregirse antes d e que c -nplementación. La RTF tiene una duración típica

d e entre 9 0 minutos y dos horas. Al concluir la RTF, el equipo d e revisión determina si se requieren acciones

A

posteriores por parte del productor antes d e q u e el producto d e trabajo del diseño pueda aprobarse como parte del modelo d e diseño final.

"Lo calidad no es algo q u e se po iga encima de los sujetos y objetos como a d o r n o e n un árbol d novidod." Roberl Pirsig

Atributos d e calidad.

Hewletl-Packard [GRA87] desarrolló un conjunto de atribu-

tos de calidad; entre ellos están la funcionalidad, la facilidad de uso, la confiabilidad, el d e s e m p e ñ o y la soportabilidad. Estos atributos de calidad representan un objetivo para todo el diseño de software: • La funcionalidad

se estima al evaluar el c o n j u n t o de características y capaci-

d a d e s del programa, la generalidad de las funciones que se entregan y la de

seguridad del sistema en su totalidad.

a

• La facilidad de uso se valora al considerar los factores h u m a n o s (capítulo 12),

é tsena

miago, :que

é son unirse

la estética, consistencia y documentación generales. • La confiabilidad se evalúa al medir la frecuencia y severidad de las fallas, la precisión d e los resultados de salida, la media del m o m e n t o de fallas (MMF), la habilidad para recuperarse de las fallas y la previsibilidad del programa. • El desempeño

se mide con la velocidad de procesamiento, tiempo de

respuesta, c o n s u m o de recursos, rendimiento y eficacia. • La soportabilidad

combina la habilidad de extender el programa (extensibi-

lidad), la adaptabilidad y la serviciabilidad —estos tres atributos representan un concepto m á s común, facilidad de mantenimiento—

a d e m á s , resistencia a

pruebas, compatibilidad, configurabilidad (habilidad para organizar y controlar e l e m e n t o s de la configuración de software) (capítulo 27), la facilidad con que p u e d e instalarse el sistema, y la facilidad con que se pueden localizar los problemas.

TM No todos los atributos de la calidad del s o f t w a r e tienen el m i s m o p e s o c u a n d o s e desarrolla el diseño del software. Tal vez u n a aplicación tenga u n especial interés en

PDF Editor

la seguridad. Es posible que otra d e m a n d e d e s e m p e ñ o con un enfoque particular en la velocidad de procesamiento. Una tercera p u e d e centrarse e n la confiabilidad. Sin importar el peso, es importante puntualizar q u e e s t o s atributos de calidad deben considerarse al c o m i e n z o del diseño, no d e s p u é s de q u e el diseño e s t é completo y haya c o m e n z a d o la construcción.

252

PARTE DOS



Conjunto de tareas genéricas para el diseño 1.

Evaluar y seleccionar patrones d e diseño p a r a urc

Examinar el modelo del dominio d e

clase d e diseño o un subsistema.

la información y diseñar las estructuras d e

Revisar las clases d e diseño y modificarlas según a

datos a p r o p i a d a s p a r a los objetos d e datos y 2.

sus atributos Por medio del modelo d e análisis, seleccionar un

requiera. 5.

dispositivos externos.

estilo arquitectónico (patrón) que sea a p r o p i a d o Dividir el modelo d e análisis en subsistemas d e

Diseñar la interfaz del usuario. Revisar los resultados del análisis d e tareas.

diseño y ubicar estos subsistemas dentro d e la

Especificar la secuencia d e acción con base en

p a r a el software. 3.

ó.

escenarios del usuario.

arquitectura.

Crear un modelo d e comportamiento d e la interior

Asegurarse d e q u e c a d a subsistema e s cohesivo en

Definir los objetos d e la interfaz y mecanismos d e

su funcionamiento.

control.

Diseñar las interfaces del subsistema.

Revisar el diseño d e la interfaz y modificarlo sega-

Ubicar clases o funciones d e análisis p a r a c a d a 4.

Diseñar cualquier interfaz requerida con sistemas :

subsistema. Crear un conjunto d e clases d e diseño o componentes. Traducir c a d a descripción de las clases d e análisis en una clase d e diseño. Verificar c a d a clase d e diseño contra los criterios d e diseño; considerar los aspectos de la herencia. Definir métodos y mensajes asociados con c a d a clase d e diseño.

se requiera. 7.

Conducir el diseño al nivel d e componentes. Especificar todos los algoritmos a un g r a d o de abstracción relativamente b a j o . Refinar la interfaz d e c a d a componente. Definir estructuras d e datos al nivel d e componerles Revisar c a d a componente y corregir todos los < descubiertos. Desarrollar un modelo d e despliegue.

A través d e la historia de la ingeniería del software ha evolucionado un conjunto i conceptos fundamentales de diseño de software. Aunque el grado de interés en i concepto ha variado con los años, han p a s a d o la prueba del tiempo. Cada u n o i ce al ingeniero de software un fundamento sobre el cual pueden aplicarse métc de diseño m á s elaborados. M. A. Jackson DAC75] dijo una vez: "El comienzo de la sabiduría para [un ir niero de software] es reconocer la diferencia entre hacer que un programe funck y conseguir que lo haga del modo correcto". Los conceptos fundamentales del TMlas c o s a s "del i ño de software ofrecen el marco de trabajo necesario para hacer correcto".

PDF Editor 9.3.1 Abstracción

Cuando se considera una solución modular a cualquier problema se pueden expc muchos grados de abstracción. En un alto grado de abstracción una solución se i

blece en términos generales con el lenguaje del entorno del problema. En los gra¿ de menor abstracción se proporciona una descripción m á s detallada de la soluci;*J

CAPÍTULO 9

253


"la abstracción es una de las formas fundamentales en las que el humano se enfrenta a lo complejidad.'' G r a d y Booch

En la medida e n que c a m b i a n los diferentes g r a d o s de abstracción se trabaja para crear abstracciones procedimentales y de datos. Una abstracción procedimental

se

refiere a u n a secuencia de instrucciones que tiene una función específica y limitada. 5pora r ¿Unciones lyde

i sean útiles len i Si pueden i dominio ide L sera aún

El n o m b r e de abstracción procedimental implica e s t a s funciones, p e r o se omiten detalles específicos. Un ejemplo de abstracción procedimental seria la palabra abrir para una puerta. Abrir implica una larga secuencia de p a s o s procedimentales (por ejemplo, c a m i n a r a la puerta, alcanzar la manija, darle vuelta a la manija y e m p u j a r la puerta, hacerse a un lado para abrir p a s o a la puerta que se abre, etc.). 4 Una abstracción de datos es u n a colección n o m b r a d a de datos que describe un objeto de datos. En el contexto de abstracción procedimental, abrirse

p u e d e definir

c o m o u n a abstracción de d a t o s llamada puerta. C o m o cualquier objeto de datos, la abstracción de d a t o s para p u e r t a abarcaría u n a serie de atributos que la describan ( p o r e j e m p l o , puerta, tipo, dirección de apertura, mecanismo de apertura, peso, dimensiones).

Se p u e d e decir que la abstracción procedimental abrir emplearía la información contenida en los atributos de la abstracción de datos puerta.

9.3.2 Arquitectura La arquitectura del software alude a "la estructura general del s o f t w a r e y las f o r m a s e n que la estructura proporciona una integridad conceptual para un sistema" [SHA95a], En su forma m á s simple, la arquitectura es la estructura u organización de los c o m p o n e n t e s del programa (módulos), la m a n e r a en que é s t o s c o m p o n e n t e s interactúan, y la estructura de datos que utilizan los c o m p o n e n t e s . En un sentido m á s amplio, sin embargo, los c o m p o n e n t e s pueden generalizarse para representar e l e m e n t o s importantes del sistema y sus interacciones.

"Una arquitectura de software es el producto del trabajo de desarrollo que ofrece el mayor rendimiento de la inversión con respecto a la calidad, el tiempo y el costo." Len B a s s el al. i_AMpue(k

Una de las m e t a s del diseño de s o f t w a r e es derivar u n a representación arquitecTM tónica de un sistema. Esta representación sirve c o m o el m a r c o de trabajo a partir del cual se c o n d u c e n actividades de diseño m á s detalladas. Un conjunto de patrones

PDF Editor 4

Sin embargo, debe notarse que un conjunto de operaciones puede reemplazarse con otro, siempre que la función implicada por la abstracción de procedimiento sea la misma. Por lo tanto, los pasos requeridos para implementar abrir podrían cambiar en forma sustancial si la puerta fuera automática y estuviera unida a un sensor.

254

PARTE DOS

(CONSEJO^

arquitectónicos permite que un ingeniero de s o f t w a r e reutilice conceptos en el nivea de diseño.

No debe dejarse que la arquitectura sucedo por si sola. Sieso paso, el resto del tiempo de proyecto se invertirá en tratar de obligarla o ajustarse al diseño. Se recomienda diseñar la arquitectura de manera explícita.


El d i s e ñ o arquitectónico p u e d e representarse al u s a r uno o m á s de m u c h o s mode-l los diferentes (GAR95J. Los modelos estructurales

representan la arquitectura cocrcj

u n a colección organizada d e c o m p o n e n t e s del programa. Los modelos del maree ja trabajo incrementan el grado de abstracción del diseño al intentar identificar m a r : J de trabajo repetibles del diseño arquitectónico q u e se e n c u e n t r a n en tipos de aplica-l ciones similares. Los modelos

dinámicos

abordan los a s p e c t o s conductuales de t a

arquitectura del programa, al indicar c ó m o puede cambiar la configuración de la estr_; ] tura o el sistema, c o m o función d e los e v e n t o s externos. Los modelos del proceso s d centran e n el diseño del proceso técnico o de negocios que el sistema d e b e c o r : r - | ner. Por último, los modelos funcionales

pueden utilizarse para representar la jerar-j

quia funcional de un sistema. El diseño arquitectónico se expone en el capítulo 10

9.3.3 Patrones Brad Appleton define un patrón de diseño de la siguiente m a n e r a : "Un patrón es u n semilla de conocimiento, la cual tiene un n o m b r e y transporta la esencia de una s : J ción probada a u n problema recurrente dentro de cierto contexto en medio de inte-I r e s e s en competencia" [APP98]. Dicho d e otro modo, un patrón de diseño d e s c r - n J una estructura de diseño que resuelve un problema de diseño particular dentre j t l un contexto específico y en m e d i o de "fuerzas" q u e pueden tener un impacto en M m a n e r a en que se aplica y utiliza el patrón. potrón describe un problema q u e ocurre u n o y otro vez e n nuestro entorno, y después describe lo esencio de : solución o dicho problema, d e tal forma q u e puedos usar esta solución un millón de veces más, sin nunca hacerlo dos veces d e la misma forma." Christopher Alexandí La finalidad de cada patrón de diseño es proporcionar una descripción que le : Í - J mita al diseñador determinar 1) si el patrón e s aplicable al trabajo actual, 2) si J patrón se p u e d e reutilizar (por ende, ahorrar t i e m p o del diseño), y 3) si el p a t - r ^ l puede servir c o m o guía para desarrollar un patrón similar, p e r o diferente e n c u a . r u l a la funcionalidad o estructura. Los p a t r o n e s de diseño se exponen con mayor d e : ¿ - | lie e n la sección 9.5.

9.3.4 Modularidad

TM Los p a t r o n e s de arquitectura y diseño de s o f t w a r e materializan la modularidad

decir, el software se divide e n c o m p o n e n t e s con n o m b r e s independientes y que es p e - á l

PDF Editor

ble abordar en forma individual. Estos c o m p o n e n t e s llamados módulos

se i n t e g - s J

para satisfacer los requisitos del problema.

Se ha establecido q u e la "modularidad es el atributo particular del s o f t w a r e C-JJ

permite que un p r o g r a m a sea manejable de m a n e r a intelectual" [MYE78]. El softv.3-1 re monolítico (es decir, un p r o g r a m a g r a n d e c o m p u e s t o por un m ó d u l o sencillo} - a l

CAPÍTULO 9

255


puede entenderlo con facilidad un ingeniero de software. El número de rutas de control, la amplitud de las referencias, el n ú m e r o de variables y la complejidad general imposibilitaría comprenderlo. Este punto se ilustra con el siguiente argumento, basado en observaciones de solución de problemas humanos. Considérense dos problemas, p, y p 2 . Si la complejidad observada para p] es mayor que la de p2 se deduce que el esfuerzo requerido para resolver p, es mayor que el esfuerzo necesario para resolverp 2 . Como un caso general, este resultado es obvio en el sentido intuitivo; la resolución de un problema difícil toma más tiempo. También se deduce que la complejidad observada de dos problemas, cuando están combinados, con frecuencia es mayor que la suma de las complejidades observadas cuando cada una de ellas se toma por separado: esto conduce a una estrategia de "divide y vencerás" (es más fácil resolver un problema complejo cuando éste se divide en piezas m á s manejables). Esto tiene implicaciones importantes con respecto a la modularidad y al software. De hecho, es un argumento para la modularidad. Es posible concluir que si el software se subdivide en forma indefinida, el esfuerzo requerido para desarrollarlo se reducirá en forma sensible. Por desgracia, hay otras fuerzas que entran en juego, lo que ocasiona que esta conclusión sea (tristemente) inválida. En relación con la figura 9.2, el esfuerzo (costo) para desarrollar un solo módulo de software decrece conforme se incrementa el número de módulos. Si se tiene el mismo conjunto de requisitos, más módulos significan un t a m a ñ o individual menor. Sin embargo, a medida que crece el número de módulos, el esfuerzo (costo) asociado con la integración de los módulos también crece. Estas características conducen también a la curva total del costo o el esfuerzo que s e muestra en la figura. Existe un número M d e módulos que resultaría en un costo de desarrollo mínimo, a u n q u e hasta el momento no se tiene la sofisticación necesaria para predecir M con seguridad. Las curvas que se muestran en la figura 9.2 proporcionan una guía útil cuando se considera la modularidad. Ésta debe aplicarse, pero se debe tener cuidado de per-

I Costo total del software

I

/ l Costo por integrar

TM

PDF Editor Costo/módulo

N ú m e r o d e módulos

256

PARTE DOS


m a n e c e r eri la vecindad de M. Debe evitarse la modularidad excesiva o insuficiente pero ¿ c ó m o p u e d e conocerse la vecindad de M? ¿Qué tan modular d e b e hacerse e software? Las r e s p u e s t a s a estas preguntas requieren c o m p r e n d e r otros conceptos de diseño que se considerarán después, en este m i s m o capítulo. Un diseño y el p r o g r a m a resultante se modularizan de m a n e r a que el desarrolle se pueda planear con mayor facilidad; se puedan definir y entregar i n c r e m e n t o s de: software; los cambios p u e d a n a j u s t a r s e con mayor facilidad; las pruebas y la elimi nación de errores se pueda conducir con m á s eficiencia, y el m a n t e n i m i e n t o se pueda conducir sin efectos laterales de consideración. 9.3.5

Ocultación de información

El concepto de modularidad c o n d u c e a todos los d i s e ñ a d o r e s de software a formularse u n a pregunta fundamental: ¿ c ó m o p u e d e d e s c o m p o n e r s e una solución de softw a r e para obtener el mejor conjunto de módulos? El principio de ocultación de información [PAR72] sugiere que los módulos "se caracterizan por las decisiones de diseñ o que (cada uno) oculta a los otros". En o t r a s palabras, los m ó d u l o s deben especificarse y diseñarse de m a n e r a que la información (procedimiento y datos) que esta

\CL°AVE Lo finalidod de lo ocultación de información es reservar los detalles de las estructuras de datos y de los procesamientos de procedimiento detrás de una inteifoz del módulo. El conocimiento de los detalles no debe estar al alcance de los usuarios del módulo.

dentro del m ó d u l o s e a inaccesible para otros m ó d u l o s que n o necesiten esa información. La ocultación implica que se p u e d e conseguir una modularidad efectiva al definí: un conjunto de m ó d u l o s independientes que se c o m u n i q u e n e n t r e sí y que interc a m b i e n sólo la información necesaria para lograr la función del software. La abstracción ayuda a definir las entidades de procedimiento (o información) que conform a n el software. La ocultación define y fortalece las restricciones de a c c e s o para lo; detalles de procedimiento dentro de un módulo y para cualquier estructura de datos local que utilice el m ó d u l o [ROS75], El uso de la ocultación de información, c o m o un criterio de diseño p a r a sistemas modulares, proporciona los m a y o r e s beneficios c u a n d o se requieren modificaciones durante la realización de las p r u e b a s y, después, en el curso de m a n t e n i m i e n t o de software. C o m o la mayoría de los datos y procedimientos está oculta de las otras partes del software, existe una probabilidad m e n o r de introducir errores inadvertidos al realizar las modificaciones y propagarlos a otros lugares dentro del software. 9.3.6

Independencia funcional

El concepto de independencia funcional

es la s u m a directa de la modularidad y de los TM conceptos de abstracción y ocultación de información. En referencias obligadas sobre el diseño de software, Wirth |WIR71] y P a m a s [PAR72] aluden a las técnicas de refin a m i e n t o que mejoran la independencia de los módulos. Trabajos posteriores de

PDF Editor Stevens, Myers y Constantine [STE74] consolidaron el concepto.

La independencia funcional se consigue al desarrollar módulos con u n a funciór

"determinante" y u n a "aversión" a la interacción excesiva con otros módulos. Dich: de otra manera, se desea diseñar el software de tal manera que cada módulo aborde u n a subfunción específica de los requisitos y tenga u n a sola interfaz c u a n d o se

CAPÍTULO 9


257

observe d e s d e otras partes de la estructura del programa. Es justo preguntarse por qué e s importante la independencia. El s o f t w a r e con una modularidad efectiva, es decir, con módulos independientes, es m á s fácil de desarrollar porque la función se puede fraccionar y las interfaces se simplifican (considérense las ramificaciones c u a n d o el desarrollo se realiza en equipo). Los módulos independientes son m á s fáciles de m a n t e n e r (y probar) porque se limitan los efectos s e c u n d a r i o s que originan las modificaciones al diseño o ai código, se reduce la propagación de errores, y e s posible emplear módulos reutilizables. En r e s u m e n , la independencia funcional es una clave para el buen diseño, y el diseño es la clave para lograr la calidad del software.

kVE i auno ] del eun ] en

La independencia se evalúa aplicando dos criterios cualitativos: cohesión y a c o plamiento. La cohesión e s u n a medida de la fuerza funcional relativa de un módulo. El acoplamiento

es una medida de la interdependencia relativa entre los módulos.

La cohesión es una extensión natural del concepto de ocultación de información descrito en la sección 9.3.5. Un módulo cohesivo realiza una sola tarea, para lo q u e requiere muy poca interacción con otros c o m p o n e n t e s en otras partes del programa. Dicho de manera sencilla, un módulo cohesivo debe (idealmente) hacer sólo una cosa. El a c o p l a m i e n t o e s u n a medida de la interconexión entre los módulos de una

tVE ) es uno ] del eun i aneciado syal

estructura de software. El acoplamiento d e p e n d e de la complejidad de la interfaz entre los módulos, el p u n t o d o n d e s e realiza una entrada o referencia a un módulo, y los d a t o s que p a s a n a través de la interfaz. En el diseño de s o f t w a r e se intenta conseguir el a c o p l a m i e n t o m á s b a j o posible. Una conectividad sencilla e n t r e los m ó d u los da c o m o resultado un s o f t w a r e m á s fácil de e n t e n d e r y m e n o s p r o p e n s o a experimentar el "efecto ola" [STE74], el cual se presenta c u a n d o surgen problemas en un lugar y d e s p u é s se p r o p a g a n a través del sistema.

9.3.7 Refinamiento El refinamiento

p a s o a p a s o e s u n a estrategia de diseño d e s c e n d e n t e que propuso ini-

cialmente Niklaus Wirth [WIR71]. El desarrollo de un programa se realiza al retinar

* r nndencio a

de m a n e r a sucesiva los niveles de detalle procedimentales. Una jerarquía se desarrolla al d e s c o m p o n e r el enunciado macroscópico de u n a función (una abstracción procedimental) p a s o a p a s o hasta alcanzar las oraciones del lenguaje de programación.

id detalle l ignorar los t conduce I t omisiones t el diseño i más difícil i Se tecorelrefh r xsoa

En realidad, el refinamiento es un proceso de elaboración. Se inicia con el e n u n ciado de u n a función (o una descripción de datos) que se define conTM un alto grado de abstracción. Esto es, el e n u n c i a d o describe los d a t o s o la función de m a n e r a c o n ceptual, pero n o proporciona información acerca de los trabajos internos de la fun-

PDF Editor

ción o de la estructura interna de los datos. El refinamiento h a c e que el diseñador trabaje sobre el e n u n c i a d o original y que proporcione m á s y m á s detalles c o n f o r m e se realiza cada refinamiento sucesivo (elaboración). La abstracción y el refinamiento son c o n c e p t o s complementarios. La abstracción

le permite a un diseñador especificar procedimientos y d a t o s sin considerar detalles

258

PARTE D O S


de grado menor. El refinamiento ayuda al diseñador a revelar los detalles de m e n o r mientras se realiza el diseño. A m b o s conceptos auxilian al diseñador creación de un modelo de diseño completo a medida que evoluciona la activida: diseño. "No follé. Sólo encontré 10 000 formos fallidos de hacer los cosas."

Thomos Referencia Web

En www. refactoring.tom se pueden encentro! excelentes recwsos poro lo l e f o b n t o e f c

9.3.8 Refabricación Una actividad importante de diseño que sugieren m u c h o s m é t o d o s ágiles ( lo 4) es la refabricación, técnica de reorganización que simplifica el diseño (o c_ de un c o m p o n e n t e sin cambiar su función o comportamiento. Fowler [FOW99] ne la refabricación de la siguiente m a n e r a : "La refabricación es el proceso de c . biar un sistema de software de tal forma que no se altere el c o m p o r t a m i e n t o no de su código [diseño] y a ú n así se m e j o r e su estructura interna." Cuando un software se refabrica el diseño existente se examina en busca redundancias, e l e m e n t o s de diseño inútiles, algoritmos innecesarios o insuficic estructuras de datos inapropiadas o construidas de m a n e r a incorrecta, o c u a l c . otra falla de diseño que se pueda corregir para lograr un mejor diseño. Por ejerr r una primera iteración de diseño podría producir un c o m p o n e n t e que muestra pal cohesión (realiza tres funciones que tienen muy p o c a s relaciones entre sí). El ñ a d o r p u e d e decidir que el c o m p o n e n t e d e b e refabricarse en tres c o m p o n e n t e s i tintos, cada uno de ellos con una elevada cohesión. El resultado será un softwr m á s fácil de integrar, probar y m a n t e n e r .

Conceptos

de diseño

El e s c e n a r i o : Cubículo de Vinod,

J a m i e : C u a n d o realizaba mis estudios profesionales o s

comienza el modelado del diseño.

SC nunca entendí realmente por q u é la ocultación de

Los a c t o r e s : Vinod, Jamie y Ed, miembros del equipo

información e r a tan importante como dicen.

d e ingeniería del software d e HogarSeguro.

V i n o d : Porque... e s una técnica p a r a reducir la

También,

Shakiro un nuevo miembro del equipo

propagación del error en un p r o g r a m a . En realidad, i

l a conversación:

la independencia funcional también se logra lo mismo

(Los cuatro miembros del equipo a c a b a n d e regresar d e

S h a k i r a : Yo no tengo un título enTM SC, entonces muchos

un seminario matutino, titulado "Aplicación d e conceptos

d e las cosas que mencionó el instructor son nuevas p c r :

básicos d e diseño", q u e ofreció un profesor local d e

mí. Y yo p u e d o generar un buen código y rápido. No

ciencia computacional.)

veo por qué este asunto es tan importante.

V i n o d : ¿Obtuvieron algo del seminario?

J a m i e : He visto tu trabajo, Shalc, y ¿sabes qué? Tú

PDF Editor i sabía la mayor parte d e las cosas, pero

haces muchas d e estas cosas en forma natural.

3ue no es una mala idea escucharlas d e nuevo.

e s q u e tus diseños y tu código funcionan.

|

CAPÍTULO 9

259


i ( s o n r i e n d o ) : Sueno, yo siempre froto de código, montenerlo enfocado en una cosa, r simples y restringidos las interfases, reutilizar código siempre que puedo... ese tipo de cosas. Moduloridad, independencia funcional, ocultación, ¿ves? : Todavía recuerdo el primer curso de ..ación que tomé... nos enseñaron a refinar el iterativamente. Tú sabes que lo mismo puede aplicarse al El único concepto del que no había escuchado antes "refabricación".

S h a k i r a : Se utiliza en Programación Extrema, creo que eso dijo. Ed: Sí, no es por completo diferente al refinamiento, sólo lo haces después de que el diseño o el código han sido completados. Si me preguntan a mí, es un tipo d e paso hacia la optimización del software. J a m i e : Regresemos al diseño d e HogarSeguro. Creo que deberíamos poner estos conceptos en nuestra lista de revisión mientras desarrollamos el modelo de diseño para HogarSeguro. V i n o d : Estoy d e acuerdo. Pero igual de importante, comprometámonos todos a pensar en ellos conforme desarrollamos el diseño.

9.3.9 Clases de diseño En el capítulo 8 s e mencionó que el modelo de análisis define un conjunto completo de clases de análisis. Cada una de estas clases describe algún elemento del dominio del problema, con enfoque en los aspectos del problema visibles para el usuario o el cliente. El grado de abstracción de una clase de análisis es relativamente alto. Conforme evoluciona el modelo de diseño, el equipo de software debe definir un conjunto de clases de diseño que 1) refine las clases de análisis al proporcionar detalles del diseño que permitirán la implementación de las clases, y 2) produzca un conjunto nuevo de clases de diseño que implementen una infraestructura de software para soportar la solución del negocio. Se sugieren cinco diferentes tipos de clases de diseño, cada uno representa una capa distinta de la arquitectura de diseño [AMB01]: Las clases de interfaz con el usuario definen todas las abstracciones necesarias ¿(teé tipos «cdases « diseñador?

para la interacción humano-computadora (IHC). En muchos casos, la IHC ocurre dentro del contexto de una metáfora (por ejemplo, un libro de verificación, un formato de orden, una máquina de fax) y las clases de diseño para la interfaz pueden ser representaciones visuales de los elementos de la metáfora. Las clases del dominio de negocios a m e n u d o son refinamientosTM de las clases de análisis definidas antes. Las clases identifican los atributos y servicios (métodos) necesarios para implementar algún elemento del dominio de

PDF Editor negocios.

Las clases de proceso implementan abstracciones del negocio en un nivel más bajo, las cuales se requieren para manejar por completo las clases del dominio de negocios.

Las clases persistentes representan almacenamientos de datos (por ejemplo, una base de datos) que persistirán m á s allá de la ejecución del software.

260

PARTE DOS


• Las clases de sistema implementan las funciones de gestión y control de! software que permiten que el sistema opere y se comunique dentro de s;. entorno de computación y con el mundo exterior. A medida que evoluciona el modelo de diseño, el equipo de software debe llar un conjunto completo de atributos y operaciones para cada clase de dis grado de abstracción se reduce conforme cada clase de análisis se transforrv una representación del diseño. Esto es, las clases de análisis representan servicios asociados que se aplican a éstos) usando la jerga del dominio de n Las clases de diseño presentan un mayor detalle técnico, pues son una guía ¡mplementación. Arlow y Neustadt [ARL021 sugieren revisar cada clase de diseño para asegur; la misma esté "bien formada". Ellos definen cuatro características de una diseño bien formada:

¿ Q u é es • u n a clase de diseño "bien formada"?

Completa y suficiente. Una clase de diseño debe ser la encapsulación ta de todos los atributos y métodos que se pueden esperar, en forma razonable base en una interpretación reconocible del nombre de la clase), que existar clase. Por ejemplo, la clase e s c e n a definida para el software de edición de está completa sólo si contiene todos los atributos y métodos que pueden de manera razonable con la creación de una escena de video. La suficiencia ra que la clase de diseño contenga sólo aquellos métodos que sean suficientelograr el objetivo, ni más ni menos. Primitivismo. Los métodos asociados con una clase de diseño deben en en el cumplimiento de un servicio para la clase. Una vez que el servicio h ; implementado con un método, la clase n o debe proporcionar otra forma de mentar la misma cosa. Por ejemplo, la clase videoClip del software de ed video podrían tener atributos punto-inicial y punto-final para indicar los puntos de y fin del clip (nótese que el video bruto cargado en el sistema puede ser más que el clip que se usa). Los métodos cstablecerPuntolnicialf) y establecerPuntoFinJporcionan los únicos medios para configurar los puntos de inicio y fin del clip. C o h e s i ó n alta. Una clase de diseño cohesiva tiene un conjunto de r dades pequeño y enfocado, y aplica atributos y métodos de manera sencii:; implementar dichas responsabilidades. Por ejemplo, la clase VideoClip del re para la edición de video podría contener un conjunto de métodos para TM videoclip. Mientras cada método se enfoque sólo en atributos asociados con e clip se mantendrá la cohesión.

PDF Editor

A c o p l a m i e n t o bajo. Dentro del modelo de diseño es necesario que las

diseño colaboren con alguna otra. Sin embargo, la colaboración se debe en un mínimo aceptable. Si un modelo de diseño tiene un acoplamiento alto las clases d e diseño colaboran con todas las otras clases de diseño), el si; difícil de implementar, probar y mantener a través del tiempo. En general, las :

CAPÍTULO 9

261


de diseño dentro de un subsistema deben tener sólo un conocimiento limitado de las clases en otros subsistemas. Esta restricción, llamada la Ley de Deméter [LIE03], sugiere que un método sólo debe enviar mensajes a métodos de clases vecinas. 5

PlanodePlanta tipo dimensiones exteriores agregarCámara() agregarPared() agregarVentana)) borrarSegmento( | dibujar))

Cámara tipo id Campodevisión Angulodebúsqueda Configuraciónacercamiento

1

Segmento Coordenadainicío Coordenadafin obteneríipoj ] dibujar))

Segmentodepared 1 1

Refinación de una clase El e s c e n a r i o : Cubículo d e Ed, continúa el modelado del diseño. Los a c t o r e s : Vinod y Ed, miembros del equipo de -geniería del software de HogarSeguro. La c o n v e r s a c i ó n : Ed trabaja en la clase P l a n o d e P l a n t a [véase el debate en el recuadro de la sección 8.7.4 y la figura 8.14] y la ha refinado para el modelo de diseño.)

Ventana

1 1

análisis en una clase de diseño Ed: Entonces ¿recuerdas la clase P l a n o d e P l a n t a , no? Se utiliza como una parte de las funciones d e vigilancia v administración del hogar. V i n o d ( a f i r m a n d o c o n la c a b e z a ) : Sí, me parece recordar que la usamos como parte de nuestros análisis de CRC para la administración delTM hogar. Ed: Lo hicimos. De cualquier manera, la estoy refinando para el diseño. Quiero mostrar cómo implementaremos

PDF Editor 5

Una forma menos formal de enunciar la Ley de Deméter es "Cada unidad debe hablar sólo con sus

amigos; no con extraños."

262

PARTE DOS


realmente la clase P l a n o d e P l a n t a . Mi idea es implementarla como un conjunto de listas ligadas [una estructura de datos específica]. Entonces, tuve que refinar la ciase d e análisis P l a n o d e p l a n t a (figura 8.14) y, en realidad, hasta simplificarla. V i n o d : La clase de análisis sólo mostraba cosas en el dominio del problema, bueno, realmente sobre la pantalla de la computadora, que fueran visibles paro el usuario final ¿no? Ed: Sí, pero para la clase de diseño P l a n o d e P l a n t a tengo que agregar algunas cosas que son ¡mplementacián específica. Necesitaba mostrar que P l a n o d e P l a n t a es una agregación de segmentos - y por ende la clase S e g m e n t o - y que la clase S e g m e n t o está compuesta de listas para segmentos de

9.4

pared, ventanas, puertas y cosas así. la clase C á m a r a colabora con P l a n o d e P l a n t a y, obviamente, puede haber muchas cámaras en el plano d e planta. V i n o d : Bueno, veamos una fotografía de esta nueva clase de diseño P l a n o d e P l a n t a . (Ed le muestra el esquema de la figura 9.3.) V i n o d : De acuerdo, veo lo que estás tratando de haceEsto te permite modificar fácilmente el plano de planta porque puedes agregar nuevos elementos o borrar otro? de la lista -la agregación- sin ningún problema. Ed ( a f i r m a n d o c o n la c a b e z a ) : Sí, yo creo que funcionará. V i n o d : Yo también.

EL M Q P S L Q PE P ¡ S S Ñ Q El modelo de diseño p u e d e verse en dos d i m e n s i o n e s diferentes, c o m o se ilustra e-i la figura 9.4. La dimensión del proceso indica la evolución del m o d e l o de diseño c o forme se e j e c u t a n las t a r e a s de diseño c o m o u n a parte del p r o c e s o del software La dimensión de abstracción representa el g r a d o de detalle a medida que cada eleme* to del m o d e l o de análisis se transforma en u n equivalente del diseño y después se refina de u n a m a n e r a iterativa. En la figura, la línea p u n t e a d a indica la frontera entre los modelos de análisis y diseño. En algunos casos se distingue con claridad entre l:s

\ CLAVE El modelo de diseño tiene cuatro elementos importantes: datos, arquitectura, componentes e interfaz.

modelos de análisis y diseño; en otros, el m o d e l o de análisis se c o m b i n a con el dist ñ o y la distinción resulta m e n o s obvia. Los e l e m e n t o s del m o d e l o del diseño utilizan m u c h o s de los d i a g r a m a s e n Uinaplicados e n el m o d e l o de análisis. La diferencia es que estos d i a g r a m a s están r e i n a d o s y elaborados c o m o p a r t e del diseño; se proporciona un mayor detalle para ; implementación específica y se resaltan la estructura y el estilo arquitectónicos, 1: í c o m p o n e n t e s que residen d e n t r o de la arquitectura y las interfaces entre los c o m p : n e n t e s y con el m u n d o exterior. "Los preguntas acerca d e si el diseño es necesario o evitable están bastante f u e r a de lugar: el diseno es inevitable, la alternativa al buen diseño es el mal diseño y no su inexistencia."

TM

Douglas Martin

Sin embargo, es importante m e n c i o n a r que los elementos del m o d e l o anotados ;

PDF Editor

lo largo del eje horizontal n o siempre se desarrollan de u n a m a n e r a secuencial. E~ la mayoría de los casos, el diseño arquitectónico preliminar establece la plataforrr =

y lo siguen el diseño de interfaz y el diseño al nivel de c o m p o n e n t e s , los cuales 3 m e n u d o s e realizan en paralelo. El m o d e l o de despliegue con frecuencia se retrase hasta que el diseño ha sido desarrollado por completo.

CAPÍTULO 9

263

I N G E N I E R Í A DEL D I S E Ñ O

Dimensiones del modelo de diseño.

Alto « o d e l o d e análisis Diagramas d e clase Paquetes de análisis Modelos CRC Diaaramas de colaboración D i a g r a m a s d e flujo de datos D i a g r a m a s d e flujo d e control Narrativas de procesamiento

•O O

C a s o s d e uso - texto Diagramas de caso d e uso Diagramas d e actividad D i a g r a m a s d e carril Diagramas de colaboración Diagramas de estado Diagramas de secuencia

Diagramas de clase Paquetes d e análisis Modelos CRC Diaaramas de colaboración Diagramas de f d e datos D i a a r a m a s d e flujo del control Narrativas de procesamiento Diagramas de estado Diagramas de secuencia

Requisitos: Restricciones Interoperabilidad Objetivos y configuración

e *5

c

R e a l i z a c i o n e s d e clas« de diseño Subsistemas Diagramas de colaboración

E

o

Diseño d e inferíase técnica Diseño d e navegación Diseño de IGU

de diseño Refinamientos

Bojo

c

Diagramas de componente Clases de diseño Diagramas d e actividad Diagramas de secuencia

Refinamientos

Realizaciones d e clases de diseño Subsistemas Diagramas de colaboración

Elementos arquitectónicos

a:

Diagramas de componente Clases de diseño Diagramas d e actividad Diagramas de secuencia

Elementos d e interfaz

E l e m e n t o s a l nivel de componentes

Realizaciones d e clase de diseño Subsistemas Diagramas de colaboración Diagramas de componente Clases de diseño Diagramas d e actividad Diagramas de secuencia

Diagramas de despliegue E l e m e n t o s a l nivel del d e s p l i e g u e

Dimensión del p r o c e s o

9.4.1

Elementos del diseño de datos

Al igual que otras actividades de la ingeniería del software, el diseño de datos (algun a s veces llamado arquitectura de datos) crea u n modelo de datos o información que se representa con un alto grado de abstracción (la visión de los datos del c l i e n t e / u s u a rio). Después, e s t e m o d e l o de datos se refina en representaciones que de m a n e r a

*VE '«ta

el diseño e enfoca en i boses de I de los .el

datos las de datos «quieren para : los * datos

progresiva tienen una implementación específica y que pueden procesarse m e d i a n te el sistema b a s a d o en c o m p u t a d o r a . En m u c h a s aplicaciones de s o f t w a r e la arquitectura de los d a t o s tendrá una profunda influencia sobre la arquitectura del software que los d e b e procesar. La estructura de los d a t o s siempre ha sido u n a parte importante del diseño del software. Al nivel de los c o m p o n e n t e s del sistema, las estructurasTM del d i s e ñ o de d a t o s y los algoritmos con que se manipulan son esenciales para la creación de aplicaciones de alta calidad. Al nivel de aplicación, la traducción de un m o d e l o de datos

PDF Editor

(obtenido c o m o u n a b a s e de la ingeniería de requisitos) a u n a b a s e de d a t o s es esen-

cial para a l c a n z a r los objetivos de negocio de un sistema. Al nivel de negocios, la colección de información a l m a c e n a d a e n b a s e s de d a t o s dispersas y reorganizadas en u n a "conjunción de datos" permite la explotación de d a t o s o el descubrimiento de un conocimiento q u e p u e d e tener un impacto sobre el éxito del m i s m o negocio. En

264

PARTE DOS


cada caso, el diseño de d a t o s juega un papel importante. El diseño de d a t o s se exp: ca con mayor detalle e n el capítulo 10.

\ CLAVE El modelo arquitectónico se derivo del dominio de aplicación, del modelo de análisis y de los estilos y potrones disponibles.

9.4.2

Elementos del diseño arquitectónico

El diseño arquitectónico

para el s o f t w a r e es el equivalente al p l a n o de planta de u r :

casa. Este plano muestra la configuración general de las habitaciones, su tamaf forma y las relaciones entre ellas, y las puertas y v e n t a n a s que permiten el m o v m i e n t o hacia y d e s d e los cuartos. El p l a n o de planta proporciona u n a visión g l o t : de la casa. Los elementos del diseño arquitectónico dan una visión general del so: ware. "Puedes usor un borrador en lo tabla de diseño o un martillo en el sitio de construcción." Frank lloyd Wrigbt El m o d e l o arquitectónico [SHA96] se obtiene a partir de tres fuentes: I) la infc mación acerca del dominio de aplicación para el software que se va a construir los e l e m e n t o s del m o d e l o de análisis específico, tales c o m o diagramas de flujo a: datos o clases de análisis, sus relaciones y colaboraciones para el problema que tiene a la m a n o , y 3) la disponibilidad de patrones (sección 9.5) y estilos arquitect nicos (capítulo 10).

9.4.3 Elementos de diseño d e interfaz El diseño de interfaz para software es el equivalente a u n c o n j u n t o de dibujos deta liados (y especificaciones) para puertas, v e n t a n a s y utilidades externas de u n a casa. Estos dibujos representan el t a m a ñ o y forma de las p u e r t a s y ventanas, la m a n e r a e r que operan, la m a n e r a e n que las conexiones de las utilidades (como agua, e n e r e : eléctrica, gas, teléfono) llegan a la c a s a y se distribuyen entre las habitaciones reprt s e n t a d a s e n el plano de planta. Estos dibujos indican d ó n d e está localizado el t i r bre de la puerta, si hay un intercomunicador que anuncie la presencia de un visítate y c ó m o está instalado el sistema de seguridad. En esencia, los dibujos (y especificaciones) detallados para las puertas, v e n t a n a s y utilidades externas indican confluyen las c o s a s y la información desde y hacia la casa y dentro de las habitaciones que son parte del plano de planta. Los elementos del diseño de interfaz para so:: w a r e m u e s t r a n c ó m o fluye la información hacia o fuera del sistema y c ó m o éste e s : : c o m u n i c a d o entre los c o m p o n e n t e s definidos c o m o parte de la arquitectura. TM "El público está más fomiliarizodo con el diseño molo que con el bueno. En efecto, está condicionado o preferir el mal diseño porque ? con lo que vive. Lo nuevo es omenozonte, lo viejo es seguro."

PDF Editor

Existen tres elementos importantes del diseño de interfaz: 1) la interfaz con e

usuario (IU); 2) interfaces externas a otros sistemas, artefactos, redes u otros pr< ductores o c o n s u m i d o r e s de información; y 3) interfaces internas entre varios con"

CAPÍTULO 9

265


p o n e n t e s de diseño. Estos e l e m e n t o s de diseño de interfaz permiten al s o f t w a r e c o mu n i c a r s e de m a n e r a externa y permiten la comunicación y colaboración interna

KVE s portes paro de diseño . la interfaz i í las con sistemas lio ríos

entre los c o m p o n e n t e s que pueblan la arquitectura del software. El diseño de la IU es una acción primordial de la ingeniería de software, y se c o n sidera con detalle en el capítulo 12. El diseño de u n a IU incorpora e l e m e n t o s estéticos (por ejemplo, distribución, color, gráficas, m e c a n i s m o s de interacción), elementos e r g o n ó m i c o s (por ejemplo, información y ubicación de la distribución, metáforas, navegación de la IU), y e l e m e n t o s técnicos (como p a t r o n e s de la IU, c o m p o n e n t e s reutilizables). En general, la IU es un subsistema único dentro de la arquitectura de aplicación general.

am

dentro

El diseño de las interfases externas requiere información definitiva acerca de la entidad hacia d o n d e se m a n d a o recibe la información. En todos los casos, esta información debe recopilarse durante la ingeniería de requisitos (capítulo 7) y verificarse u n a vez que c o m i e n c e el diseño de la interfaz. 6 El diseño de interfases extern a s d e b e incorporar revisión de errores y (cuando sea necesario) características a p r o p i a d a s de seguridad. El diseño de las interfaces internas está c e r c a n a m e n t e alineado con el diseño al nivel de los c o m p o n e n t e s (capítulo 11). Las realizaciones del diseño de clases de análisis representan todas las o p e r a c i o n e s y e s q u e m a s de m e n s a j e s requeridos para permitir la comunicación y colaboración entre las o p e r a c i o n e s de varias clases. Cada

TeléfonoMóvil PDAInalómbrico

PaneldeControl pantallaLCD indicadoresLED característicasTeclado bocino interfaselnalámbrica leerGolpedeTeclal) decodificarTeclaj) desplegarEstatus() luzLEDs)) enviarMensajeControl(

l Teclado

«Interfaz» Teclado

TM

eerGolpedeTecla( decodificarTecla()

PDF Editor 6

No resulta poco común que las características de la interfaz cambien con el tiempo. Por lo tanto, un diseñador debe asegurar que la especificación para la interfaz se mantenga actualizada.

266

PARTE DOS

En www.oseit.com

sitos y los requerimientos funcionales específicos de la operación que h a sido solici


m e n s a j e d e b e ser diseñado para ajustarse a la transferencia de información de requipuede encontrase inforrootión muy v o t a saine el diseüci detall).

tada. En a l g u n o s casos, u n a interfaz se modela de u n a m a n e r a muy parecida a u r ; clase. El UML define una interfaz de la siguiente m a n e r a [OMGOl]: "Una interfaz es un d e t e r m i n a n t e de las operaciones [públicas] visibles de m a n e r a e x t e m a de una clase, c o m p o n e n t e u otro clasificador (incluidos los subsistemas) sin especificación de estructura interna". Dicho de un m o d o m á s simple, u n a interfaz es un conjunt: de o p e r a c i o n e s que describe parte del c o m p o r t a m i e n t o de u n a clase y proporciona a c c e s o a e s a s operaciones. Por ejemplo, la función d e seguridad de HogarSeguro emplea u n panel de contrc que permite al propietario d e la c a s a controlar ciertos aspectos de la función de seguridad. En u n a versión a v a n z a d a del sistema, las funciones del panel de contr. pueden implementarse vía PDA inalámbrico o teléfono móvil. La clase P a n e l d e C o n t r o l (figura 9.5) proporciona el c o m p o r t a m i e n t o asociad; con un teclado y, por lo tanto, debe implementar operaciones de leerTeclaPresionada y decodificafTecia().

Si e s t a s o p e r a c i o n e s se suministrarán a otra clase (en este casc

a P D A I n a l á m b r i c o y TeléfonoMóvil), resulta inútil definir u n a interfaz c o m o : que se muestra en la figura. La interfaz llamada T e c l a d o se muestra c o m o un estereotipo de « i n t e r f a z » o c o m o u n círculo p e q u e ñ o y etiquetado que se conecta : la clase con u n a línea. La interfaz se define sin atributos y con el conjunto de ope raciones n e c e s a r i a s para lograr el c o m p o r t a m i e n t o de un teclado. "Un error común que cometen las personas cuando tratan de diseñar algo completamente a prueba de tontos es subestimar la ingenuidad de los que son completamente tontos." Douglas Adams

La línea p u n t e a d a con u n triángulo abierto en s u extremo (figura 9.5) indica q u ; la clase P a n e l d e C o n t r o l proporciona o p e r a c i o n e s de T e c l a d o c o m o parte de su comportamiento. En UML e s t o se caracteriza c o m o u n a realización. Esto es, parte de c o m p o r t a m i e n t o de P a n e l d e C o n t r o l se implementará al realizar las operaciones de Teclado. Estas operaciones se proporcionarán a otras clases que entren a la interfaz.

9.4.4 Elementos de diseño al nivel de componentes

TM

El diseño al nivel de c o m p o n e n t e s para el s o f t w a r e equivale a un conjunto de dibu jos detallados (y especificaciones) para c a d a cuarto en u n a casa. Estos dibujos mues-

PDF Editor

tran el a l a m b r a d o y la instalación sanitaria dentro de c a d a cuarto, la ubicación de lo; receptáculos eléctricos e interruptores, llaves, lavabos, tinas, desagües y armarios También describen los pisos que se usarán, los m o l d e s que se aplicarán, y cualquier otro detalle asociado con el cuarto. El diseño al nivel de c o m p o n e n t e s para softwa re describe por completo el detalle interno de cada c o m p o n e n t e del software. Para

CAPÍTULO 9

267


a de ite para -nsor.

lograrlo el diseño al nivel de c o m p o n e n t e s define estructuras de datos para todos los objetos de d a t o s locales, así c o m o detalle algorítmico para t o d o el p r o c e s a m i e n t o que ocurre dentro de un c o m p o n e n t e y una interfaz que permite el a c c e s o a todas las operaciones de los c o m p o n e n t e s (comportamientos). "los df italles no son los detalles. Ellos hacen el diseño." Charles l a m e s

Dentro del contexto de la ingeniería del software orientada a objetos, un c o m p o n e n t e se representa a m a n e r a de diagrama en UML c o m o se muestra en la figura 9.6. En esta figura se representa un c o m p o n e n t e llamado M a n e j o S e n s o r (parte de la función de seguridad de HogarSeguro).

El c o m p o n e n t e está conectado a u n a clase

llamada S e n s o r , la cual está asignada a éste mediante una flecha p u n t e a d a . El c o m p o n e n t e M a n e j o S e n s o r realiza t o d a s las funciones asociadas con los s e n s o r e s de HogarSeguro, entre las que se e n c u e n t r a n su monitoreo y configuración. En el capítulo 11 se presenta u n a explicación m á s a fondo acerca de los d i a g r a m a s de c o m ponente. Los detalles de diseño de un c o m p o n e n t e se pueden modelar a m u c h o s grados distintos de abstracción. En la representación del procesamiento lógico se p u e d e utilizar un diagrama de actividad. El flujo detallado de procedimiento para un c o m p o n e n t e p u e d e representarse, ya sea mediante un pseudocódigo (una representación del tipo de lenguaje de programación que se describe en el capítulo 11), o de algún formato diagramático (por ejemplo, un diagrama de actividad o un diagrama de flujo).

9.4.5 Elementos de diseño al nivel del despliegue Los e l e m e n t o s de d i s e ñ o al nivel del despliegue indican c ó m o se ubicarán la funcionalidad y los s u b s i s t e m a s d e n t r o del e n t o r n o computacional físico que soportará al TM configurados software. Por ejemplo, los e l e m e n t o s del producto HogarSeguro están para operar dentro de tres e n t o r n o s de computación primarios: una PC doméstica, el panel de control d e HogarSeguro y un servidor ubicado en CP1 Corp. (lo que propor-

PDF Editor ciona a c c e s o al sistema a través de Internet).

Durante el diseño se desarrolla un diagrama de despliegue en UML y d e s p u é s se

refina, c o m o se muestra en la figura 9.7. En ésta se m u e s t r a n tres a m b i e n t e s c o m putacionales (en realidad, debería haber más, si se incluyen sensores, c á m a r a s y otros). Se indican los s u b s i s t e m a s (funcionalidad) que se alojan dentro de cada ele-

268

Diagrama de despliegue en UML p a r a HogarSeguro.

PARTE DOS


Panel de control

Servidor de CP1

Seguridad

AccesoPropietario

V

/

Computadora persona| Acceso externo

Seguridad

7

>

Vigilancia

,

4 — ' AdministraciónHogar Comunicación

%. CLAVE Los diagramas de despliegue comienzan en un formato descriptor, donde el entorno de despliegue se describe en términos generales. Después se utilizo un formato de instancia y se describen de manera explícito los

/

m e n t ó de cómputo. Por ejemplo, la c o m p u t a d o r a personal aloja s u b s i s t e m a s que implementan seguridad, vigilancia, administración del hogar y características ce comunicación. Además, se h a diseñado un subsistema de acceso externo para controlar t o d o s los intentos de a c c e s o al sistema HogarSeguro

d e s d e u n a f u e n t e exter-

na. Cada subsistema sería elaborado p a r a indicar los c o m p o n e n t e s que implemento El diagrama mostrado en la figura 9.7 está en forma de descriptor. Esto significa que el diagrama de despliegue muestra el e n t o r n o computacional, pero no indica ce m a n e r a explícita detalles de configuración. Por ejemplo, n o se identifica la "computadora personal". Podría s e r u n a "Wintel" PC o una Macintosh, u n a estación de trabajo Sun o una Linux-box. Estos detalles s e proporcionan c u a n d o el diagrama de despliegue se revisa en forma de instancia durante e t a p a s posteriores del diseño o c u a n d o c o m i e n z a la construcción. Se identifica cada instancia del despliegue (una TM configuración de h a r d w a r e con un n o m b r e específico).

configuración.

PDF Editor

"Deja todo y retírate, tomo una pequeña relajación. Cuando regreses al trabajo, tu juicio será más seguro. Toma algo de distancio porque entonces el trabajo parece más pequeño, una mayor porte del mismo puede ser capturado en uno mirada y lo falta de armonio y propordón se observo con más facilidad." Leonardo DaVinci

CAPÍTULO 9

269


Los m e j o r e s d i s e ñ a d o r e s en cualquier c a m p o de trabajo tienen la misteriosa habilidad de vislumbrar p a t r o n e s que caracterizan un problema y los p a t r o n e s corresp o n d i e n t e s que pueden combinarse para crear u n a solución. A través del p r o c e s o de diseño, un ingeniero de s o f t w a r e debe buscar toda oportunidad para reutilizar patron e s de diseño existentes (cuando cumplen las n e c e s i d a d e s de un diseño) en vez de crear nuevos.

9.5.1 Descripción de un patrón de diseño Las disciplinas m a d u r a s de la ingeniería utilizan miles de p a t r o n e s de diseño. Por ejemplo, un ingeniero m e c á n i c o utiliza un eje de dos p a s o s c o m o un patrón de diseñ o clave. Los atributos (diámetros del eje, d i m e n s i o n e s del orificio de las llaves, etcétera) y las o p e r a c i o n e s (por ejemplo, la rotación del giro y la conexión del giro) son inherentes al patrón. Un ingeniero eléctrico utiliza un circuito integrado (un patrón de d i s e ñ o en e x t r e m o complejo) para resolver un elemento específico de un problem a nuevo. Los p a t r o n e s de diseño pueden describirse e m p l e a n d o la plantilla [MAI03] q u e se muestra e n el recuadro "Plantilla del patrón de diseño". INFORMACIÓN

Plantilla del patrón de diseño Nombre del patrón: describe lo esencia del patrón en un nombre corto, pero expresivo, i: describe el patrón y lo que hace. -conocido-como: lista los sinónimos para el en: proporciona un ejemplo del problema. lidad: anota situaciones específicas de diseño en es aplicable el patrón. : describe las clases que se requieren para *tar el patrón.

Participantes: describe las responsabilidades de las clases que se requieren para implementar el patrón. Colaboraciones: describe cómo colaboran los participantes para llevar a cabo sus responsabilidades. Consecuencias: describe las "fuerzas de diseño" que afectan al patrón y los intercambios potenciales que deben considerarse cuando se implemento el patrón. Patrones relacionados: patrones de diseño relacionados mediante referencias cruzadas.

y

Una descripción del patrón de diseño p u e d e considerar también un c o n j u n t o de f u e r z a s de diseño. Las fuerzas

VE de diseño

de diseño describen requisitos no funcionales (por

ejemplo, facilidad d e mantenimiento, portabilidad) asociados con elTM s o f t w a r e en el q u e se aplicará el patrón. Además, las f u e r z a s definen las limitaciones que restringen la m a n e r a en que se implementará el diseño. En esencia, las fuerzas de diseño

PDF Editor 1 aquellos ¡ lo solución i lo forma se puede el diseño.

describen el a m b i e n t e y las condiciones que d e b e n existir para q u e el patrón del diseño sea aplicable. Las características del patrón (clases, responsabilidades y colaboraciones) indican los atributos ajustables del diseño para permitir q u e el patrón se ajuste a u n a variedad de p r o b l e m a s (GAM95). Estos atributos representan características del diseño que p u e d e n buscarse (por ejemplo, a través de u n a b a s e de datos)

270

PARTE DOS


para que sea factible e n c o n t r a r un patrón apropiado. Por último, la guía asocia i.i con el u s o de u n patrón de diseño indica las ramificaciones de las decisiones 3=11 diseño. "Los potrones están o medio hornear, lo que significo que siempre debes terminarlos y adaptarlos a tu propio entorno." Martín Fowfet

Los n o m b r e s de los p a t r o n e s de diseño deben elegirse con cuidado. Uno de i a problemas técnicos clave e n la reutilización de s o f t w a r e es la falta de habilidad p a a e n c o n t r a r p a t r o n e s reutilizables existentes, a pesar de que existen cientos o miles x patrones. La b ú s q u e d a del patrón "correcto" tiene un apoyo i n m e n s o si se cuerna con u n n o m b r e significativo del patrón.

9.5.2 Utilización d e patrones en el diseño Los p a t r o n e s de diseño pueden usarse durante el diseño del software. Una vez q j se ha desarrollado el modelo de análisis (capítulo 8), el diseñador p u e d e e x a r r . - una representación detallada del problema que d e b e resolver y las restricciones jjc impone el problema. La descripción del p r o b l e m a se examina en varios grados abstracción para determinar si es flexible para uno o m á s de los siguientes tipos de p a s » - j n e s de diseño. ¿Qué tipos • de p a t r o n e s de d i s e ñ o e s t á n disponibles para el ingeniero d e software?

P a t r o n e s a r q u i t e c t ó n i c o s . Estos p a t r o n e s definen la estructura general del ware, indican las relaciones entre los s u b s i s t e m a s y los c o m p o n e n t e s del so y definen las reglas p a r a especificar las relaciones entre los e l e m e n t o s (el paquetes, componentes, subsistemas) de la arquitectura. P a t r o n e s d e d i s e ñ o . Estos p a t r o n e s se aplican a un e l e m e n t o específico diseño c o m o un agregado de c o m p o n e n t e s para resolver algún problema de di: relaciones e n t r e los c o m p o n e n t e s o los m e c a n i s m o s p a r a efectuar la c o m u n i c de c o m p o n e n t e a c o m p o n e n t e . I d i o m a s . A veces llamados patrones de código, estos p a t r o n e s específicos de guaje por lo general implementan u n e l e m e n t o algorítmico o u n componente protocolo de interfaz específico o un m e c a n i s m o de comunicación entre los coirp:nentes.

TM Cada u n o de los tipos de p a t r o n e s difiere e n el grado de abstracción con e. está r e p r e s e n t a d o y con el grado e n el que proporciona u n a guía directa para la a a

PDF Editor

vidad de construcción (en este caso, codificación) del p r o c e s o de s o f t w a r e

9.5.3 Marcos de trabajo

En algunos c a s o s e s necesario proporcionar u n a infraestructura esquelética e s r ^ fica de implementación, llamada marco de trabajo, para el trabajo de diseño. Est: el diseñador p u e d e seleccionar u n a "miniarquitectura

reutilizable que ofrezca el

CAPITULO 9


271

p o r t a m i e n t o y la estructura genérica para u n a familia de abstracciones de software, junto con un contexto... que especifique su colaboración y uso dentro de un domiKVE ! trabajo es > de código

nio dado" [APP98). U n m a r c o de trabajo no e s un patrón arquitectónico, s i n o un esqueleto con una colección de "puntos de conexión" (también llamados g a n c h o s y ranuras) que le p e r -

miten a d a p t a r s e a un dominio de un problema específico. Los p u n t o s de conexión ; t J n c'oses

permiten al diseñador integrar clases o funcionalidad específicas del problema d e n tro del esqueleto. En un contexto orientado al objeto, un m a r c o de trabajo es una colección de clases que cooperan. En esencia, el diseñador de un m a r c o de trabajo a r g u m e n t a r á que u n a miniarquitectura reutilizable se p u e d e aplicar a todo el software que se desarrollará dentro de un dominio limitado de aplicación. Para que sean m á s efectivos, los m a r c o s de trab a j o se aplican sin cambios. Se p u e d e n agregar e l e m e n t o s de diseño adicionales, p e r o sólo a través de los p u n t o s de conexión que permiten que el diseñador desarrolle el esqueleto del m a r c o d e trabajo.

La ingeniería de d i s e ñ o c o m i e n z a c u a n d o la primera iteración de la ingeniería de requisitos llega a su fin. La finalidad del diseño de s o f t w a r e es aplicar un conjunto de principios, c o n c e p t o s y prácticas que c o n d u c e n al desarrollo de un sistema o prod u c t o de alta calidad. La meta del diseño e s crear un modelo de software que implem e n t e todos los requisitos del cliente de m a n e r a correcta y complazca a aquellos que lo usen. Los ingenieros de diseño deben e x a m in a r por medio de m u c h a s alternativas de diseño y converger en la solución que mejor cumpla las n e c e s i d a d e s de los interesados en el proyecto. El proceso de diseño a v a n z a de u n a visión general de software a u n a visión m á s estrecha que define el detalle requerido para implementar un sistema. El proceso c o m i e n z a con un e n f o q u e e n la arquitectura. Se definen los subsistemas; s e establecen m e c a n i s m o s de comunicación entre los subsistemas; se identifican los c o m p o nentes; y se desarrolla u n a descripción detallada de cada c o m p o n e n t e . Además, se diseñan las interfases internas, externas y del usuario. Los c o n c e p t o s de diseño h a n evolucionado e n la primera mitad del siglo de trab a j o de la ingeniería del software. Estos c o n c e p t o s describen atributos del software de c o m p u t a d o r a que deben estar presentes sin importar el proceso de ingeniería del TM s o f t w a r e que se elija, los m é t o d o s de diseño que se apliquen, o los lenguajes de programación que utilicen. El modelo de diseño abarca cuatro e l e m e n t o s diferentes. En la medida en que s e

PDF Editor

desarrolla cada u n o de estos elementos evoluciona una visión m á s completa del diseño. El e l e m e n t o arquitectónico utiliza información derivada del dominio de apli-

cación, el modelo de análisis y catálogos disponibles para p a t r o n e s y estilos que deriven u n a representación estructural completa del software, sus sistemas y c o m -

272

PARTE DOS


ponentes. Los elementos de diseño d e interfaz modelan interfaces internas y exter-í ñas y la interfaz del usuario. Los elementos al nivel de componentes definen caza uno de los módulos (componentes) que pueblan la arquitectura. Por último, los ó t m e n t o s de diseño al nivel de despliegue asignan la arquitectura, sus componentes las interfases a la configuración física que albergará el software. El diseño basado en patrones es una técnica que reutiliza elementos de dis que han probado ser exitosos en el pasado. Cada patrón arquitectónico, patrón diseño o idioma s e cataloga, se documenta por completo y se considera cuidadc mente cuando se evalúa para incluirlo en una aplicación específica. Los marcos trabajo, una extensión de los patrones, ofrecen un esqueleto arquitectónico para diseño de subsistemas completos dentro de un dominio de aplicación específica

[AMB01J Ambler, S.. The Objecl Primer. Cambridge Univ. Press, 2a. ed., 2001. [APP98] Appleton, B„ "Patterns and Software: Essential Concepts and Terminology, p u r x . obtenerse en h t t p : / / w w w . e n t e r a c t . c o m / ~ b r a d a p p / d o c s / p a t t e m s - i n t r o . h t m l . [ARL02] Arlow,). e I. Neusdadt, UML and the Unified Process, Addison-Wesley, 2002. [BEL81] Belady, L., prólogo de Software Design: Methods and Techniques (L. J. Peters, autor),' don Press, 1981. ¡FOWOO] Fowler, M. et ai, Re/acloríng. Improving the Design of Eásting Code, Addison-We 2000.

[GAM951 G a m m a , E. et al., Design Patterns, Addison-Wesley, 1995. [GAR95] Garlan, D. y M. Shaw, "An lntroduction to Software Architecture", en Advances Software Engineering and Knowledge Engineering, vol. I (V. Ambriola y G. Tortora, e d s . ) ' Scientific Publishing Company, 1995. [GRA87] Grady, R. B. y D. L. Casswell, Software Metrics: Establishing a Company-Wide Program. ] Prentice-Hall, 1987. [JAC75] Jackson, M. A., Principies ofProgram Design, Academic Press, 1975. [UE03] Lieberherr, K., "Demeter: Aspect-Oriented Programming", mayo d e 2003, disponible i http://www.ccs.neu.edu/home/lieber/LoD.html. [MA103) Maioriello, J., "What Are Design Patterns and Do 1 Need Them?", developer.com,; disponible e n h t t p : / / w w w . d e v e l o p e r . c o m / d e s i g n / a r t i c l e . p h p / 1 4 7 4 5 6 l . [MCG91 ] McGlaughlin, R., "Some Notes on Program Design". en Software Engineering Notes 16, n ú m . 4, octubre de 1991, pp. 53-54. [MYE78] Myers, G„ Composite Structured Design, Van Nostrand, 1978. [OMGOl] Object M a n a g e m e n t Group, OMG Unified Modeling Language Speciftcaüon, versiór septiembre d e 2001. IPAR721 P a m a s , D. L., "On Criteria to be used in Decomposing Systems into Modules", vol. 14, n ú m . 1, abril de 1972, pp. 221-227. [ROS75] Ross, D., I Goodenough y C. Irvine, "Software Engineering: Process, Principies TM Goals", en IEEE Computer, vol. 8, n ú m . 5, m a y o de 1975. [SCH02] Schmuller,)., Teach YourseifUML, SAMS Publishing, 2002. [SHA96] Shaw, M. y D. Garlan. Software Architecture, Prentice-Hall, 1996. [STA02] "Metaphor", e n The Stanford HCl Leammg Space, 2002, h t t p : / / h c i . S t a n f o r d . e d u / h c f c l concepts/metaphor.html. [STE74] Stevens, W„ G. Myers y L. Constantine, "Structured Design", en IBM Systems )ouma¡ : 13, n ú m . 2, 1974. pp. 115-139. [W1R71] Wirth, N., "Program Development by Stepwise Refinement", e n CACM, vol. 14, n u - 1971, pp. 221-227.

PDF Editor

CAPÍTULO 9


273

PROBLEMAS Y PUNTOS A CONSIDERAR 9 . 1 . ¿Se diseña un software c u a n d o se "escribe" un programa? ¿Qué es lo que hace q u e el diseñ o de software sea diferente a la generación de código? 9 . 2 . Si un diseño d e software n o es un programa (de h e c h o n o lo es), ¿entonces, qué es? 9 . 3 . ¿Cómo se evalúa la calidad d e un diseño d e software? 9 . 4 . Examinar el conjunto d e tareas p r e s e n t a d a s p a r a un diseño. ¿Cuándo se evalúa ia calidad dentro del c o n j u n t o de tareas? ¿Cómo se logra esto? 9 . 5 . Dar ejemplos de tres abstracciones de d a t o s y abstracciones procedimentales que p u e d a n utilizarse p a r a manipularlas. 9 . 6 . Describir c o n a r g u m e n t o s propios la arquitectura de software. 9 . 7 . Sugerir un patrón de diseño relacionado c o n u n a categoria d e c o s a s cotidianas (por ejemplo, productos electrónicos, automóviles, aparatos). Documentar el patrón con ayuda d e la plantilla que se presenta en la sección 9.5. 9 . 8 . ¿Existe algún caso en el que los problemas complejos requieran d e m e n o s e s f u e r z o para resolverse? ¿Cómo afectaría ese caso el a r g u m e n t o para la modularidad? 9 . 9 . se debe implementar un diseño modular c o m o software monolítico? ¿Cómo se p u e d e lograr esto? ¿El d e s e m p e ñ o es la única justificación p a r a la implementación del software m o n o lítico? 9 . 1 0 . Explicar la relación entre el concepto d e ocultación de información c o m o un atributo de modularidad efectiva y el concepto d e independencia del módulo. 9 . 1 1 . ¿Cómo se relacionan los conceptos d e acoplamiento y portabilidad del software? Dar ejemplos que apoyen la explicación. 9 . 1 2 . Aplicar un "enfoque de refinamiento paso a p a s o " para desarrollar tres g r a d o s diferentes d e abstracción procedimental p a r a u n o o m á s de los siguientes programas: a) Desarrollar u n a máquina que expida c h e q u e s que, al dar u n a cantidad numérica en dólares, imprima la cantidad en palabras que por lo general se requiere en un cheque; b) resolver de m a n e r a iterativa la raiz de u n a ecuación trascendental; c) desarrollar u n a tarea simple que planee algoritmos para un sistema operativo. 9 . 1 3 . Realizar u n a p e q u e ñ a investigación sobre programación extrema y escribir un texto breve acerca d e la refabricación para un proceso de desarrollo d e software ágil. 9 . 1 4 . Visitar un depósito d e p a t r o n e s de diseño (en la web) y navegue por unos minutos a trav é s d e los patrones. Elegir u n o y presentarlo a n t e los c o m p a ñ e r o s d e clase.

O T R A S L E C T U R A S Y F U E N T E S DE I N F O R M A C I Ó N Donald Norman ha escrito dos libros (The Design o/Eveiyday Things, Doubleday, 1990, y The Psychology of Everyday Things, HarperCollins, 1988) que se h a n convertidoTM en clásicos en la bibliografía sobre diseño y "debe" leerlos cualquiera que diseñe cualquier cosa q u e usen los h u m a n o s . Adams (Conceptual Blockbusting, 3a. ed., Addison-Wesley, 1986) ha escrito un libro que es u n a lectura esencial para los diseñadores q u e quieran ampliar su m a n e r a d e pensar. Por último, un texto clásico d e Polya (How to Solve It, Princeton University Press, 2a. e d „ 1988) proporciona un proceso d e resolución de p r o b l e m a s genérico que p u e d e ayudar a los diseñadores d e software al e n f r e n t a r s e c o n problemas complejos. Dentro de la m i s m a tradición, Winograd el al. (Bringing Design lo Software, Addison-Wesley, 1996) analiza los diseños de software q u e funcionan, los que n o funcionan y por qué. Un libro fascinante editado por Wixon y Ramsey (Field Methods Casebook for Software Design, Wiley,

PDF Editor

274

PARTE DOS


1996) sugiere m é t o d o s d e investigación d e c a m p o (muy parecidos a los que utilizan los a n " pólogos) para e n t e n d e r c ó m o los usuarios finales hacen el trabajo que hacen, y d e s p u é s ofirec; u n a guía p a r a diseñar el software que satisfaga s u s necesidades. Beyer y Holtzblatt (ContextjDesign: A Customer-Centered Approach to Systems Designs, Academic Press, 1997) ofrecen o c i visión del diseño d e software q u e integra al cliente-usuario en cada a s p e c t o del proceso áe diseño d e software. McConnell (Code Complete, Microsoft Press, 1993) presenta u n a excelente exposición de );s aspectos prácticos de diseñar software p a r a computadora d e alta calidad. Robertson (Siirc Program Design, 3a. ed., Kboyd y Fraser Publishing, 1999) ofrece u n a útil explicación introdu; toria del diseño d e software p a r a quienes c o m i e n z a n su estudio acerca del tema. Fowler y s - s colegas (Refactoríng: Improving the Design ofExisting Code, Addison-Wesley, 1999) exponen t í n i c a s p a r a el m e j o r a m i e n t o incremental d e los diseños d e software. En la década pasada se h a n escrito m u c h o s libros sobre diseños b a s a d o s en patrones p a ~ ingenieros d e software. G a m m a y s u s colegas [GAM95] h a n escrito el libro f u n d a m e n t a l scc"; el tema. Otros libros d e Douglass (Real-Time Design Pattems, Addison-Wesley, 2002), Mets¿:(Design Pattems Applied, Wrox Press, 2002), Marinescu y Román (EJB Design Pattems, Wiir 2001) sitúan p a t r o n e s de d i s e ñ o e n a m b i e n t e s de aplicación y lenguajes específicos. Aderr Í ; los libros clásicos del arquitecto Christopher Alexander (Notes on the Synthesis o/Form, Har. r : University Press, 1964, y A Pattem Language: Towns, Buildings, Construction, Oxford Universr Press, 1977) debe leerlos el diseñador d e software que pretenda c o m p r e n d e r a fondo los parn é s de diseño. En Internet se dispone de u n a amplia variedad de f u e n t e s de información sobre ingenie-.* de diseño. Una lista actualizada d e referencias en la red mundial relevantes p a r a el diseño : software y la ingeniería d e diseño p u e d e encontrarse en el sitio web d e SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

CAPÍTULO

10


E

l d i s e ñ o s e h a d e s c r i t o c o m o u n p r o c e s o d e v a r i o s p a s o s e n el c u a l l a s r e p r e s e n t a c i o n e s d e la e s t r u c t u r a d e l o s d a t o s y el p r o g r a m a , l a s c a r a c t e r í s t i c a s d e la i n f o r m a c i ó n y el d e t a l l e p r o c e d i m e n t a l s e s i n t e t i z a n a p a r t i r d e

l o s r e q u i s i t o s . E s t a d e s c r i p c i ó n la a m p l í a F r e e m a n [FRE80]: [D)iseñó e s u n a actividad relacionada con la t o m a d e decisiones, a m e n u d o d e natu-

.296

raleza estructural. C o m p a r t e con la p r o g r a m a c i ó n una p r e o c u p a c i ó n relacionada con a b s t r a e r la r e p r e s e n t a c i ó n de la información y las s e c u e n c i a s del p r o c e s a m i e n t o , pe-

d e . . .297

ro el g r a d o d e detalles e s m u y diferente e n los e x t r e m o s . El d i s e ñ o construye repres e n t a c i o n e s c o h e r e n t e s y bien p l a n e a d a s de los p r o g r a m a s , q u e s e c o n c e n t r a n e n las

..288 fclo

..287

i » . .276 de .294 de . . 2 8 4 ..279 ée datos 2 7 8

.281 ...302 .296

interrelaciones e n t r e las p a r t e s al nivel m á s e l e v a d o y las o p e r a c i o n e s lógicas e n los niveles inferiores... C o m o s e i n d i c ó e n el c a p i t u l o 9, el d i s e ñ o e s t á o r i e n t a d o a la i n f o r m a c i ó n . L o s m é t o d o s d e d i s e ñ o d e l s o f t w a r e s e d e r i v a n d e la c o n s i d e r a c i ó n d e c a d a u n o d e l o s t r e s d o m i n i o s d e l a n á l i s i s d e l m o d e l o . L o s d o m i n i o s d e la i n f o r m a c i ó n , la f u n c i ó n y el c o m p o r t a m i e n t o s i r v e n c o m o g u í a p a r a el d i s e ñ o d e l s o f t w a r e . En e s t e c a p í t u l o s e p r e s e n t a r á n l o s m é t o d o s r e q u e r i d o s p a r a c r e a r " r e p r e s e n t a c i o n e s c o h e r e n t e s y b i e n p l a n e a d a s " d e l a s c a p a s d e l o s d a t o s y la a r q u i t e c t u r a d e l m o d e l o d e d i s e ñ o . El o b j e t i v o e s p r o p o r c i o n a r u n e n f o q u e s i s t e m á t i c o d e l d i s e ñ o a r q u i t e c t ó n i c o : los p l a n o s p r e l i m i n a r e s q u e se utilizan.

.294

¿ Q u é e s ? Ei diseño arquitectónico r e p r e s e n t o la estructura d e d a t o s y los c o m p o n e n t e s del p r o g r a m a n e c e sarios p a r a construir un sistema c o m p u t a c i o n a l . A s u m e el estilo arquitectónico q u e t o m a r á el sistema, la estructura y las p r o p i e d a d e s d e los c o m p o n e n t e s q u e constituyen e sistema y las interrelaciones entre t o d o s los c o m p o n e n t e s arquitectónicos d e un sistema. i n l o h a c e ? A u n q u e un i n g e n i e r o d e software p u e d e d i s e ñ a r los d a t o s y la a r q u i t e c t u r a , a m e n u d o el t r a b a j o s e a s i g n a a especialistas c u a n d o se construyen sistemas g r a n d e s y comciejos. Un d i s e ñ a d o r d e b a s e d e d a t o s o d e alm a c é n d e d a t o s c r e a la arquitectura d e d a t o s del sistema. El "arquitecto del sistema" selecciona u n estilo a r q u i t e c t ó n i c o a p r o p i a d o p a r a los requisi-

tos d e r i v a d o s d u r a n t e la ingeniería del sistema y el análisis d e los requisitos del software.

¿Por q u é e s i m p o r t a n t e ? Nadie trataría de construir u n a c a s a sin un p l a n o , ¿ v e r d a d ? Tamp o c o e m p e z a r í a a t r a z a r p i a n o s b o s q u e j a n d o la distribución d e la f o n t a n e r í a . N e c e s i t a r í a un p a n o r a m a g e n e r a l (la p r o p i a c a s a ) a n t e s d e preoc u p a r s e p o r los detalles. Eso es lo q u e h a c e el dis e ñ o arquitectónico: p r o p o r c i o n a u n a vista g e n e ral y a s e g u r a q u e s e o b t e n g a lo qTM u e se d e s e a .

¿Cuáles s o n los p a s o s ? El diseño arquitectónic o e m p i e z a con el d i s e ñ o d e los d a t o s y luego p a s a a la derivación d e u n a o m á s r e p r e s e n t a ciones d e la estructura a r q u i t e c t ó n i c a del sistem a . Se a n c l z a r 'os estilos o p a t r o n e s arquitec-

PDF Editor

tónicos a : t e m o s p a r a d e r i v a r la estructura q u e se a m o l d a m e j o r c o s requisitos del cliente. En

275

276

PARTE DOS


c u a n t o se selecciona u n a opción se e l a b o r a la arquitectura e m p l e a n d o un m é t o d o d e d i s e ñ o apropiado.

¿ C ó m o p u e d o e s t a r s e g u r o d e q u e lo he

¿Cual e s el producto o b t e n i d o ? Un modelo q u e a b a r c a la arquitectura d e los d a t o s y la estructura del p r o g r a m a se c r e a d u r a n t e esta etap a del d i s e ñ o . A d e m á s , se d e s c r i b e n las p r o p i e d a d e s d e los componentes y sus relaciones ¡interacciones).

10.1

h e c h o c o r r e c t a m e n t e ? En c a d a e t a p a se revisan los productos resultantes del d i s e ñ o de: software p a r a verificar la claridad, la c o r r e o ción, el g r a d o en q u e se h a n c o m p l e t a d o y s. consistencia c o n los requisitos y entre unos otros.

A R Q U I T E C T U R A DEL S O F T W A R E En su notable libro sobre el tema, Shaw y Garlan [SHA96] analizan la arquitec: del software de la siguiente manera: Desde la primera vez que un programa se dividió en módulos, los sistemas de software h a n tenido arquitecturas, y los p r o g r a m a d o r e s h a n sido responsables d e las interacciones entre los m ó d u l o s y las propiedades globales del ensamblaje. Históricamente, las arqu:tecturas h a n estado implícitas (como accidentes de implementación o s i s t e m a s heredades del pasado). Los b u e n o s desarrolladores de software han adoptado con frecuencia u n o : varios p a t r o n e s arquitectónicos c o m o estrategia p a r a la organización del sistema, pero los emplean d e m a n e r a informal y n o tienen medios para hacerlos explícitos en el sistema resultante.

Hoy, la arquitectura del software efectiva y su representación y diseño explícitos : han vuelto temas dominantes en la ingeniería del software. " l o arquitectura d e un sistema es un morco conceptual completo que describe su f o r m a y estructura (sus componente: y la monero en que se integran)."

Jerrold Grochow

10.1.1 ¿Qué es la arquitectura? Cuando se analiza la arquitectura de un edificio vienen a la mente muchos a tribu: J diferentes. En el aspecto m á s simple s e considera la forma general de la estructura física. Pero, en realidad, la arquitectura e s mucho más, es la manera en que los d - j versos c o m p o n e n t e s de un edificio se integran para formar un todo cohesionado, a TM la manera en que el edificio se amolda a su ambiente y se combina con otros e c í - j cios vecinos. Es el grado en el cual el edificio cumple con el propósito estableció: «

PDF Editor

en que satisface las necesidades de su propietario. Es la percepción estética de la ~ | tructura —el impacto visual del edificio— y la m a n e r a en que las texturas, los coi :-J res y los materiales se combinan para crear la fachada externa y el "entorno vivier-l te" del interior. Son pequeños detalles: el diseño de la iluminación, el tipo de piso, -a colocación de las c o s a s que cuelgan de las paredes, la lista es casi interminable - A nalmente, se trata de un arte.

CAPÍTULO 10


277

¿Pero qué p a s a con la arquitectura del software? Bass, Clement y Kazman [BAS03] definen e s t e término elusivo de la siguiente m a n e r a :

KVE • del »modelar • de un limonera £ » 0 5 Y los

La arquitectura del software d e un p r o g r a m a o sistema d e c ó m p u t o e s la estructura o las estructuras del sistema, que incluyen los c o m p o n e n t e s del software, las propiedades visibles e x t e r n a m e n t e d e e s o s c o m p o n e n t e s y las relaciones entre ellos.

La arquitectura no e s el s o f t w a r e operativo. En cambio, e s u n a representación q u e permite que un ingeniero del software: 1) analice la efectividad del diseño para cumplir con los requisitos establecidos, 2) considere opciones arquitectónicas en u n a

irtresí.

etapa e n que a ú n resulta relativamente fácil hacer c a m b i o s al diseño, y 3) reduzca los riesgos asociados con la construcción del software. "Cósese t u o n t o antes con su arquitectura y después a r r e p i é n t a s e a s u g u s t o . "

es útdes a sde N*l

Esta definición d e s t a ca el papel de los " c o m p o n e n t e s del software" en cualquier representación arquitectónica. En el contexto del diseño arquitectónico, un c o m p o n e n t e de software es algo tan simple c o m o un módulo del p r o g r a m a o una clase orientada a objetos, p e r o también se extiende para incluir b a s e s de d a t o s y middle-

IJ id. */

ware que permita configurar u n a red de clientes y servidores. En e s t e libro, el diseño de la arquitectura del s o f t w a r e considera dos niveles de la pirámide del diseño (figura 9.1): el diseño de datos y el diseño arquitectónico.

En el

contexto del análisis anterior, el diseño de los d a t o s permite representar el compon e n t e de d a t o s de la arquitectura en sistemas convencionales y definiciones de clase (atributos y o p e r a c i o n e s d e encapsulamiento) de los sistemas orientados a objetos. El diseño arquitectónico se concentra en la representación de la estructura de los c o m p o n e n t e s del software, sus propiedades e interacciones.

10.1.2 ¿Por qué es importante la arquitectura? En un libro dedicado a la arquitectura del software, Bass y sus colegas IBAS03] identifican tres r a z o n e s clave por las cuales la arquitectura del s o f t w a r e e s importante:

K

CLAVE ICO i una ] de Gestolt » s S e m o , lo que i al ingeniero de i examinados i un todo.

• Las representaciones de la arquitectura del s o f t w a r e permiten la comunicación entre todas las partes (participantes) interesadas e n el desarrollo de un sistema de cómputo.

TM • La arquitectura d e s t a ca las decisiones iniciales relacionadas con el diseño q u e tendrán un impacto p r o f u n d o en todo el trabajo de la ingeniería del s o f t w a r e

PDF Editor

que le sigue y, lo que también resulta importante, en el éxito final del sistema c o m o entidad operacional.

• La arquitectura "constituye u n m o d e l o relativamente p e q u e ñ o e intelectualm e n t e comprensible de c ó m o está estructurado el sistema y c ó m o trabajan

juntos sus c o m p o n e n t e s " [BAS03].

278

PARTE DOS


El modelo de diseño arquitectónico y los patrones arquitectónicos que contiene >JB transferibles. Es decir, los estilos y patrones arquitectónicos (sección 10.3.1) se api : al diseño de otros sistemas y representan un conjunto de abstracciones que p e n r s r a los ingenieros de software describir la arquitectura de m a n e r a s predecibles. IQ.2

mm

D I S E Ñ O PE PATOS

-

La acción de diseño de datos traduce los objetos de d a t o s definidos c o m o parte ad modelo de análisis (capítulo 8) en estructuras globales al nivel de componentes x software y, c u a n d o es necesario, u n a arquitectura de b a s e de datos al nivel de a : cación. En a l g u n a s situaciones d e b e diseñarse y construirse u n a b a s e de d a t o s esr-r jj cíficamente para un n u e v o sistema. Sin embargo, en otras, se e m p l e a n u n a o b a s e s de d a t o s existentes.

10.2.1 Diseño de datos al nivel arquitectónico Hoy los negocios g r a n d e s y p e q u e ñ o s están i n u n d a d o s d e datos. No resulta pocc ; m ú n que incluso u n negocio de t a m a ñ o m o d e r a d o tenga d o c e n a s de b a s e s de que sirven a m u c h a s aplicaciones que a b a r c a n cientos de gigabytes de datos. E to consiste e n extraer información útil de este e n t o r n o de datos, s o b r e todo la información d e s e a d a tiene funcionalidad c r u z a d a (por ejemplo, información sólo se obtiene si los d a t o s específicos de mercadotecnia e s t á n relacionados de ñera cruzada con los d a t o s de ingeniería del producto).

"ta calidad de los datos marca lo diferencia entre un almocén y un basurero de dotos." Jarrett Rosenbeu

Para resolver este desafio la comunidad de empresas de la tecnología de la info En el siguiente sitio Web se obtiene infonnMión otara de almocén de dalos: www. datawurehouse. com. „

ción (TI) ha desarrollado la técnica de minería de datos, también denominada desc:.: --I miento de conocimiento en bases de datos (DCBD), que recorre bases de datos existe r - e i con el fin de extraer información apropiada e n el ámbito de los negocios. Sin embarp: I la existencia de múltiples b a s e s de datos, sus diferentes estructuras, el grado de d e ^ - | lie que contienen y muchos otros factores hacen que la minería de datos resulte d r ; . [ j dentro de un entorno existente de base de datos. Una solución alterna, denominada .. macen de datos agrega u n a capa adicional a la arquitectura de datos. Un a l m a c é n de d a t o s e s un e n t o r n o de d a t o s independiente que no está diré: J TM m e n t e integrado e n las aplicaciones cotidianas, p e r o que abarca t o d o s los datos x - | lizados en un negocio [MAT96]. En cierto sentido, u n a l m a c é n de d a t o s es una b ¿ ^ | de d a t o s grande e independiente que tiene acceso a los datos a l m a c e n a d o s en

PDF Editor

bases de d a t o s que sirven al conjunto de aplicaciones requeridas en un negocio. Conviene m á s dejar el análisis detallado del diseño de estructuras de datos, b a s e s !

d e d a t o s y a l m a c e n e s de d a t o s a los libros dedicados a estos t e m a s (por ejemp : . l [DATOOO], [PRE98], [KIM98]). El lector interesado d e b e leer la sección Otras / e e f u r J

y fuentes de información

de este capítulo c o m o referencia adicional.

CAPÍTULO 10

279



Minería y almacenamiento de datos Objetivo: Los herramientas de la minería de ayudan en la identificación de relaciones entre que describen un objeto de datos específico o un de objetos de datos. Las herramientas para el -miento de datos ayudan en el diseño de modelos un almacén de datos. ica: Estas herramientas tienen diversas mecánicas. -|, las herramientas de minería aceptan conjuntos de datos como entrada y permiten que el usuario ulte para tratar de comprender mejor las s entre diversos elementos de datos. Las entas d e almacenamiento empleadas en el diseño ionan vínculos con la entidad u otras opciones de ientas representativas' 1

de datos:

Objects, desarrollada por Business Objects, SA -ww.businessobjects.com), es un conjunto de -erramientas de diseño de datos que apoya "la

integración, la consulta, el informe, el análisis y el análisis de datos". SPSS, desarrollado por SPSS, Inc. (www.spss.com), proporciona una amplia variedad de funciones estadísticas que permiten el análisis de conjuntos grandes de datos.

Almacenamiento

de datos:

Industry Warehouse Studio, desarrollada por Sybase (www.sybase.com), proporciona uno infraestructura de almacén de datos empaquetado que "sirve como trampolín" para iniciar el diseño de un almacén de datos. IFW Business Intelligence Suite, desarrollada por Modelware (www.modelwarepl.com), es un conjunto d e modelos, herramientas de software y diseños de base de datos que "proporcionan un camino rápido al almacén de datos y al diseño y la implementación de centros de acopio de datos". Una lista extensa de herramientas y recursos de minería y almacenamiento d e datos se encontrará en el Data Warehousing Information Center (www.dwinfocenter.org).

10.2.2 Diseño de datos al nivel de componentes El diseño de datos al nivel de componentes se concentra en la representación de estructuras de datos a las que se tiene acceso en forma directa mediante uno o m á s componentes de software. Wasserman [WAS80] ha propuesto un conjunto de principios que se emplea para especificar y diseñar estas estructuras de datos. En realidad, el diseño de datos empieza durante la creación del modelo de análisis. Si se recuerda q u e el análisis y el diseño de requisitos suelen superponerse, se considerará el siguiente conjunto de principios (adaptado de [WAS80]) para la especificación de datos: 1. Los principios del análisis sistemático aplicados a la Junción y el comportamiento

¿Caáles prárapios q r f c a b l e s al de d a t o s ?

también deben aplicarse a los datos. También es necesario desarrollar y revisar las representaciones del flujo de datos y el contenido, identificar los objetos

2.

de datos, considerar organizaciones alternas de datos y evaluar el impacto de los datos que modelan el diseño del software. TM Deben identificarse todas las estructuras de datos y las operaciones que se realizarán. El diseño de una estructura de datos eficiente debe tener en cuenta las

PDF Editor

operaciones que s e realizarán en la estructura de datos. Los atributos y opera-

ciones encapsulados dentro de una clase satisfacen este principio.

1

El autor no respalda las herramientas expuestas; sólo representan una muestra de esta categoría. En casi todos los casos los nombres son marcas registradas de sus respectivos desarrolladores.

PARTE DOS

280


3 . Debe establecerse un mecanismo

para la definición del contenido de cada objei

de datos y usarlo para definir los datos y las operaciones que se les aplican. Los diagramas de clase (capítulo 8) definen los elementos de d a t o s (atributos) contenidos dentro de u n a clase y el p r o c e s a m i e n t o (operaciones) que se api ca a e s o s elementos de datos. 4 . Las decisiones del diseño al nivel de datos deben posponerse

hasta una de las i

timas etapas del proceso de diseño. Un proceso de refinación p a s o a p a s o es aplicable al diseño de datos. Es decir, la organización general de los d a t o s p u e d e definirse durante el análisis de los requisitos, refinarse durante el tra b a j o de diseño de datos y especificarse de m a n e r a detallada d u r a n t e el diser al nivel de c o m p o n e n t e s . 5 . La representación

de una estructura de datos sólo debe conocerse para los mó£.<-

los que deben usar directamente

los datos que contiene tal estructura. El concer

to de ocultación de la información y el c o n c e p t o relacionado del a c o p l a m i e r : : (capítulo 9) proporcionan conocimientos importantes sobre la calidad de ur. diseño de software. 6.

Debe desarrollarse una biblioteca de estructuras de datos útiles y también las operaciones que pueden aplicárseles. Esto se logra con u n a biblioteca de clase:

7.

Un diseño de software y un lenguaje de programación

deben dar soporte a la es-

pecificación y la realización de los tipos de datos abstractos. La implementacié" de u n a sofisticada estructura de d a t o s llega a volverse excesivamente difícil s n o existen medios para la especificación directa de la estructura en el lengLi je de programación elegido para la implementación. Estos principios f o r m a n una b a s e p a r a un enfoque de diseño de datos, al nive! c o m p o n e n t e s , que se integre a las actividades de análisis y diseño. 10.3

ESTILOS Y PATRONES ARQUITECTÓNICOS Cuando un constructor e s t a d o u n i d e n s e u s a la frase "colonial con una sala al centr: (centre hall colonial) para describir u n a casa, la mayoría de quienes estén famili¿z a d o s con las c a s a s en Estados Unidos evocará u n a imagen general del aspecto a: la casa y de su p l a n o general. El constructor h a u s a d o u n estilo arquitectónico

core

m e c a n i s m o descriptivo para diferenciar la casa de otros estilos (por ejemplo, mar: TM en A, r a n c h o elevado, Cape Cod). Pero algo m á s importante es que el estilo arquite. tónico también es u n a plantilla p a r a la construcción. Resulta necesario proporcior^r mayores detalles de la casa. Se deben especificar s u s d i m e n s i o n e s finales, agrega-

PDF Editor

características personalizadas, determinar los materiales de construcción, pero t estilo ("colonial con sala al centro") e s el que guía el trabajo del constructor. "En el fondo d e lo mente de todo artista hay un patrón o tipo de arquitectura.*

G . K. C h e s t e r t o r

CAPÍTULO 10


281

El software que se construye para sistemas de cómputo también muestra uno o muchos estilos arquitectónicos. Cada estilo describe una categoría de sistemas que abarca 1) un conjunto de componentes (por ejemplo, una base de datos, módulos computacionales) que realizan una función requerida por el sistema; 2) un conjunto de conectares que permiten la "comunicación, coordinación y cooperación" entre los componentes; 3) restricciones que definen cómo se integran los componentes para formar el sistema, y 4) modelos semánticos que permiten a un diseñador, mediante el análisis de las propiedades conocidas de las partes que lo integran (BAS03), comprender las propiedades generales de un sistema. Un estilo arquitectónico e s una transformación impuesta al diseño de todo un sistema. El objetivo e s establecer una estructura para todos los componentes del sistema. En caso de que una arquitectura existente se vaya a someter a reingenieria (capítulo 31), la imposición de un estilo arquitectónico desembocará en cambios fundamentales en la estructura del software, incluida una reasignación de la funcionalidad de los componentes [BOSOO]. Un patrón arquitectónico, al igual que un estilo, impone una transformación en el diseño de una arquitectura. Sin embargo, un patrón difiere de un estilo en varios elementos fundamentales: 1) el alcance de un patrón es menor, ya que se concentra en un aspecto en lugar de hacerlo en toda la arquitectura; 2) un patrón impone una regla sobre la arquitectura, pues describe la manera en que el software manejará algún aspecto de su funcionalidad al nivel de la infraestructura (por ejemplo, concurrencia) [BOSOO]; 3) los patrones arquitectónicos tienden a abarcar aspectos específicos del comportamiento dentro del contexto de la arquitectura (por ejemplo, cómo maneja una aplicación en tiempo real la sincronización o las interrupciones). Los patrones se usan junto con un estilo arquitectónico para determinar la forma de la estructura general de un sistema. En la siguiente sección se expondrán estilos y patrone s arquitectónicos de uso común en el software.

10.3.1 Una breve taxonomía de estilos arquitectónicos Aunque se han creado millones de sistemas de cómputo en los últimos 50 años, la gran mayoría puede clasificarse (consúltense ISHA96], [BUS96], [BAS03]) en un número relativamente pequeño de estilos arquitectónicos: Arquitectura centrada e n d a t o s . Un almacén de datos (por ejemplo, un archivo o una base de datos) se encuentra en el centro de esta arquitectura; otros componentes tienen acceso a él y cuentan con la opción de actualizar, agregar,TM eliminar o, por otra parte, modificar los datos de ese almacén. En la figura 10.1 s e ilustra un estilo típico centrado en datos. El software cliente tiene acceso a un almacén central. En algunos casos éste es pasivo. Es decir, el software cliente accede a los datos inde-

PDF Editor

pendientemente de cualquier cambio hecho a los datos o a las acciones de otro software cliente. Una variación de este enfoque transforma el depósito en un "pizarrón" que envía notificaciones al software cliente cuando cambian los datos de interés para el cliente.

282

PARTE DOS


Arquitectura centrada en datos.

Una arquitectura centrada e n datos p r o m u e v e la capacidad de integración [BAS:: Esto significa que es posible cambiar c o m p o n e n t e s existentes y agregar n u e v o s < ponentes cliente a la arquitectura sin preocuparse por otros clientes (ya que los i ponentes cliente operan e n forma independiente). Además, es posible pasar datos e - - | tre clientes e m p l e a n d o el m e c a n i s m o del pizarrón (es decir, el c o m p o n e n t e p i z a r : - i | sirve para coordinar la transferencia de información entre clientes). Los c o m p o r es I tes cliente ejecutan los procesos de m a n e r a independiente. Arquitectura d e flujo d e d a t o s . Esta arquitectura se aplica c u a n d o los datos & entrada se habrán de transformar en datos de salida mediante una serie de compor estes para el cálculo o la manipulación. Una estructura de tuberías y filtros (figura 1 : 2 tiene un c o n j u n t o de c o m p o n e n t e s , d e n o m i n a d o s filtros, c o n e c t a d o s por tuberías ojc transmiten d a t o s de un c o m p o n e n t e al siguiente. Cada filtro funciona sin t o m a : t

C F F B I T W Arquitectura de flujo de datos.

Tuberías

TM

PDF Editor Tuberías y filtros

CAPÍTULO 10

283


cuenta si los c o m p o n e n t e s tienen flujo a s c e n d e n t e o descendente; está diseñado para esperar la entrada de d a t o s con cierta forma y producir su salida (al siguiente filtro) de u n a forma especifica. Sin embargo, no es necesario que el filtro c o n o z c a el funcionamiento de los filtros vecinos. "En los disciplinas de lo ingeniería se usan ampliamente potrones y estilos de diseño." M a r y S h o w y David G a r l a n

Si el flujo de d a t o s d e g e n e r a en u n a sola línea de transformaciones se d e n o m i n a procesamiento

por lotes secuencial.

Esta estructura acepta un p r o c e s a m i e n t o por lo-

tes de datos y luego aplica una serie de c o m p o n e n t e s secuenciales (filtros) para transformarlos. Arquitectura d e l l a m a d a y r e t o r n o . Este estilo arquitectónico permite que un dis e ñ a d o r de software (arquitecto del sistema) obtenga u n a estructura de p r o g r a m a que resulta relativamente fácil modificar y cambiar de t a m a ñ o . En esta categoría hay dos subestilos [BAS03]: • Arquitectura de programa principaí/subprograma.

Esta estructura de p r o g r a m a

clásica separa la función en u n a jerarquía de control d o n d e un p r o g r a m a "principal" invoca a varios c o m p o n e n t e s de programa, que a su vez pueden invocar a otros c o m p o n e n t e s . En la figura 10.3 se ilustra una arquitectura de este tipo. • Arquitectura de llamada de procedimiento

remoto. Los c o m p o n e n t e s de una ar-

quitectura de p r o g r a m a principaí/subprograma se distribuyen entre varias c o m p u t a d o r a s de u n a red.

TM

PDF Editor

PARTE DOS


C B E X F Arquitectura estratificada.

Arquitectura o r i e n t a d a a o b j e t o s . Los c o m p o n e n t e s de u n sistema encapsu 3los d a t o s y las o p e r a c i o n e s que d e b e n aplicarse para manipular los datos. La c o r nicación y coordinación entre componentes se consigue mediante el paso de mensa Arquitectura e s t r a t i f i c a d a . En la figura 10.4 se ¡lustra la estructura básica de arquitectura estratificada. Hay varias c a p a s definidas; cada u n a de ellas realiza c o r raciones q u e se a c e r c a n progresivamente al conjunto de instrucciones de la m á o j B na. En la c a p a externa los c o m p o n e n t e s sirven a las operaciones de interfaz de USÜ rio. En la c a p a interna los c o m p o n e n t e s sirven c o m o interfaz c o n el sistema opert tivo. Las c a p a s intermedias proporcionan servicios de utilería y de s o f t w a r e de a r caciones. Estos estilos arquitectónicos sólo s o n u n p e q u e ñ o s u b c o n j u n t o de los que disr >d ne el diseñador de software. 2 Una vez que la ingeniería de requisitos define las z r racterísticas y restricciones del sistema que habrá de construirse, podrán elegírs; d estilo arquitectónico o la combinación de estilos que mejor combinen con las cararterísticas y restricciones. En m u c h o s c a s o s será apropiado m á s de un estilo y p o d r a » diseñarse y evaluarse distintas opciones. Por ejemplo, en m u c h a s aplicaciones 2t b a s e de d a t o s se combina un estilo p o r c a p a s (apropiado p a r a casi todos los s i s u l mas) con u n a arquitectura centrada en datos. TM

10.3.2 Patrones arquitectónicos

PDF Editor

Si el constructor decide construir u n a casa colonial con sala al centro sólo p a a l aplicar u n estilo arquitectónico. Los detalles del estilo (por ejemplo, n ú m e r o de o f l

2

Consúltese [BOSOO], [HOFOO], IBAS03], [SHA97], [BUS96] y [SHA96] para contar con un análiso j (aliado de los estilos y patrones arquitectónicos.

CAPÍTULO 10


285

-ÍOGARSEGURO

Elección de un estilo arquitectónico El e s c e n a r i o : Cubículo de Jamie, J p s continúa el modelado del diseño. actores: Jamie y Ed, integrantes del equipo de ieria del software HogarSeguro. •versación: frunciendo el ceño): Hemos estado modelando la 1 con UML... ya sabes, clases, relaciones y ese tipo Así que supongo que lo adecuado será aplicar la i orientada a objetos.3 _ . p _ j Pero... *k Pero... tengo problemas para visualizar lo que es la * ¥ c t u r a orientada a objetos. Conozco la arquitectuBamada y retorno, una tipo de jerarquía de procer.cional, pero orientada a objetos... no sé, me amorfo. ( s o n r i e n d o ) : Amorfo, ¿eh? lo que quiero decir es que no logro visualizar . sólo el diseño de clases flotando en

el espacio. J a m i e : Bueno, eso no es cierto. Hay jerarquías de clase... piensa en la jerarquía (agregación) que hicimos para el objeto P l a n o C a s a [figura 9.3]. Una arquitectura orientada a objetos es una combinación de esa estructura y las interconexiones (ya sabes, colaboraciones) entre las clases. La mostraremos al describir por completo los atributos y las operaciones, los mensajes que se intercambian y la estructura de las clases. Ed: Voy a dedicar una hora a correlacionar una arquitectura de llamada y retorno, luego regresaré aquí y pensaré en la arquitectura orientada a objetos. J a m i e : Doug no tendrá problema con eso. Él dijo que debemos considerar arquitecturas alternas Por cierto, no hay ninguna razón para no combinar ambas arquitecturas. Ed: Bueno, en eso estoy.

meneas, fachada de la casa, colocación d e puertas y ventanas) variarán considerablemente, pero una vez q u e se ha tomado la decisión de la arquitectura general de la casa, el estilo s e impondrá al diseño. 4 Los patrones arquitectónicos difieren un poco. 5 Por ejemplo, cada casa (y todo estilo arquitectónico para casas) emplea un patrón cocina, el cual define la necesidad de colocar los artículos básicos de cocina, un fregadero, alacenas y, posiblemente,

3

4

Podría argumentarse que la arquitectura de HogarSeguro debe considerarse en un nivel más elevado que la arquitectura indicada. HogarSeguro tiene diversos subsistemas (funcionalidad de monitoreo de la casa, el sitio de monitoreo de la compañía y el subsistema que se ejecuta en la PC del propietario). Dentro de los subsistemas prevalecen los procesos concurrentes (por ejemplo, el monitoreo de sensores) y el manejo de eventos. A este nivel, algunas decisiones arquitectónicas se toman durante la ingeniería del sistema y el producto (capítulo 6), pero el diseño arquitectónico dentro de la TM ingeniería del software muy bien tendría que considerar estos aspectos. Esto indica que tendrá una sala central y un pasillo, que las habitaciones estarán colocadas a la izquierda y la derecha de la sala, que la casa tendrá dos (o más) pisos, que los dormitorios estarán en la planta alta, etc. Estas "reglas" se imponen una vez que se ha tomado la decisión de usar el estilo colonial con sala al centro.

PDF Editor 5

Es importante observar que no hay un acuerdo universal sobre la terminología. Algunas personas (por ejemplo, [BUS96]) usan los términos estilos y patrones como sinónimos, mientras que otros hacen la sutil distinción sugerida en esta sección.

286

PARTE DOS


reglas para ubicar c o s a s relacionadas con el flujo de trabajo e n la habitación. Ade más, el patrón podría especificar la necesidad de cubiertas y acabados, iluminación, interruptores de pared o u n a isla central, pisos, etc. Obviamente, hay m á s de un dis e ñ o de cocina, pero t o d o diseño se concebirá d e n t r o del contexto de la "soluciór' que sugiere el patrón cocina. Como ya se indicó, los patrones arquitectónicos para el s o f t w a r e definen un e r foque específico para el m a n e j o de alguna característica de c o m p o r t a m i e n t o del S Í tema. Bosch [BOSOO] define varios p a t r o n e s arquitectónicos. En los siguientes p á r n fos s e p r e s e n t a n ejemplos representativos.

\ CLAVE Uno arquitectura del software tiene varios patrones arquitectónicos que atienden temas como la concurrencia, la persistencia y lo distribución.

Concurrencia. Muchas aplicaciones deben m a n e j a r varias t a r e a s de m a n e r a tal que simulen paralelismo (es decir, esto ocurre c a d a vez que u n solo procesador m a n e a varias tareas "paralelas" o componentes). Una aplicación tiene varias m a n e r a s 2 m a n e j a r la concurrencia, y c a d a u n a se p r e s e n t a m e d i a n t e u n patrón arquitectóni:» diferente. Por ejemplo, u n e n f o q u e consiste en usar un patrón de m a n e j o de proce s o s del sistema operativo que ofrece características integradas del sistema opera 1 vo que permiten la ejecución concurrente de los c o m p o n e n t e s . El patrón también ir corpora funcionalidad del sistema operativo que m a n e j a la comunicación entre 1 3 procesos, la calendarización y otras funciones requeridas para alcanzar la concurrencia. Otro m é t o d o sería definir un calendarizador de tareas al nivel de a p l i c a d ó c . Un patrón calendarizador de tareas contiene un c o n j u n t o de objetos activos, y c a r a u n o de ellos incluye u n a operación t i c o [BOSOO]. El calendarizador invoca periocc a m e n t e ticf) para cada objeto, que luego realiza las funciones que debe realizar a* tes de regresar el control al calendarizador, m i s m o que invoca de n u e v o la operación tice) para el siguiente objeto concurrente. P e r s i s t e n c i a . Los datos persisten si sobreviven d e s p u é s de la ejecución del p r e n so que los creó. Los datos persistentes se a l m a c e n a n en u n a b a s e de d a t o s o un archivo; en u n m o m e n t o posterior, otros p r o c e s o s tienen la opción de leerlos o m o a ficarlos. En los e n t o r n o s orientados a objetos la idea de u n objeto persistente extiende un poco m á s el concepto de persistencia. Los valores de todos los atributos del objeto, el e s t a d o general de é s t e y otra información complementaria s e a l m a c e r ^ n j para su aplicación y recuperación posterior. En general, se e m p l e a n dos patrones ar quitectónicos p a r a lograr la persistencia: 1) u n patrón d e sistema de administraos de base de datos que aplica las capacidades de a l m a c e n a m i e n t o y recuperación de _~ sistema de administración de b a s e de datos a la arquitectura de la TM aplicación, : 2 un patrón de persistencia al nivel de la aplicación que construye características de pesistencia e n la arquitectura de ésta (por ejemplo, el s o f t w a r e de procesamiento j e

PDF Editor palabras que m a n e j a su propia estructura de documento).

Distribución. El problema de la distribución dirige la m a n e r a en que se común: zar entre sí los sistemas, o los c o m p o n e n t e s de éstos, e n u n e n t o r n o distribuido Es-» problema incluye d o s elementos: 1) la m a n e r a en que las entidades se conectan catre sí, y 2) la naturaleza de la comunicación. El patrón arquitectónico m á s c o m ú r

CAPÍTULO 10

287


tablecido para dirigir el problema de la distribución es el de corredor. Un corredor actúa c o m o "intermediario" entre el componente cliente y un componente servidor. El cliente envía un mensaje al corredor (que contiene toda la información apropiada para que se realice la comunicación), el cual completa la conexión. CORBA (capítulo 30) es un ejemplo de una arquitectura de corredor. Antes de elegir cualquiera de los patrones arquitectónicos indicados en los párrafos anteriores, debe evaluarse si es apropiado para la aplicación y el estilo arquitectónico general, a d e m á s de evaluar su facilidad de mantenimiento, confiabilidad, seguridad y desempeño.

10.3.3 Organización y reíinamiento Debido a que el proceso de diseño suele dejar a un ingeniero d e software con varias opciones arquitectónicas, es importante establecer un conjunto de criterios de diseñ o para evaluar un diseño arquitectónico. Las siguientes preguntas [BAS03] proporcionan una visión específica del estilo arquitectónico que se ha derivado. Control. ¿Cómo se maneja el control dentro de la arquitectura? ¿Existe una jerarquía de control distintiva y, si e s así, cuál es la función de los componentes dentro de esta jerarquía de control? ¿Cómo transfieren los campos el control dentro del sistema? ¿Cómo s e comparte el control entre los componentes? ¿Cuál es la topología del control (es decir, cuál es la forma geométrica que asume el control)? ¿Está sincronizado el control o los componentes operan asincrónicamente? D a t o s . ¿Cómo s e comunican los datos entre los componentes? ¿El flujo de datos e s continuo o los objetos de datos s e pasan esporádicamente al sistema? ¿Cuál es el modo de transferencia de los datos (por ejemplo, los datos se pasan de un componente a otro o están disponibles globalmente para compartirse entre los componentes del sistema)? ¿Existen componentes de datos (por ejemplo, un pizarrón o almacén) y, de ser así, cuál es su papel? ¿Cómo interactúan los componentes funcionales con los de datos? ¿Los componentes de datos son pasivos o activos (es decir, interactúan activamente con otros componentes del sistema)? ¿Cómo interactúan los datos y el control dentro del sistema? Estas preguntas proporcionan al diseñador una evaluación temprana de la calidad del diseño y sientan las bases para un análisis m á s detallado de la arquitectura.

TM Cuando empieza el diseño arquitectónico debe ponerse en contexto el software que se habrá de desarrollar; es decir, el diseño debe definir las entidades externas (otros

PDF Editor

sistemas, otros dispositivos, otras personas) con las que interactúa el software y también la naturaleza de la interacción. Esta información suele adquirirse del modelo de análisis y toda la demás información reunida durante la ingeniería de requisitos. Una vez que se ha modelado el contexto y que se han descrito todas las interfaces exter-

288

PARTE DOS


ñ a s del software, el diseñador especifica la estructura del sistema al definir y refina-*

.

los c o m p o n e n t e s del software que implementan la arquitectura. Este proceso prosu de manera iterativa hasta que se obtiene una estructura arquitectónica completa

"l)n doctor entierro sus errores, pero un arquitecto sólo puede aconsejar o su cliente que plante vides.' Frank Lbyd Wrigh-

10.4.1 Representación del sistema en el contexto

En el capítulo 6 se indica que un ingeniero del sistema d e b e modelar el contexto

\

diagrama de contexto del sistema (figura 6.4) cumple con este requisito al repn

El contexto arquitectónico representa la manera en que el software interactúa con los entidades externas a sus límites.

la m a n e r a en que el software interactuará con las entidades ubicadas m á s allá de

CLAVE

¿Cómo inter• actúan los sistemas entre sí?

tar el flujo de la información d e n t r o y fuera del sistema, la información del u s u a r el p r o c e s a m i e n t o relevante de soporte. Al nivel d e diseño arquitectónico, un arqu • tecto del s o f t w a r e aplica un diseño de contexto arquitectónico (DCA) para moce r r límites. La estructura genérica de los d i a g r a m a s de contexto arquitectónico se tran e n la figura 10.5. Si se t o m a c o m o referencia la figura, los sistemas que interactúan con el de destino (el sistema para el que se está desarrollando un diseño arquitectónico' representan así: • Sistemas superordinados:

los que e m p l e a n el sistema de destino c o m o parte ;

algún e s q u e m a de p r o c e s a m i e n t o de nivel m á s elevado. • Sistemas subordinados:

los que utiliza el sistema de destino y que proporcio-

n a n los d a t o s o el p r o c e s a m i e n t o necesarios para completar la funcionalids; del sistema de destino.

Diagiama de contexto arquitectónico (adaptado d e [BOSOO]).

Sistemas superordinados

1

1

1 Usados

TM

PDF Editor Sistemas subordinados

CAPÍTULO 10

289


• Sistemas al nivel de par: los que interactúan de igual a igual (es decir, la información la producen o c o n s u m e n los pares y el sistema de destino). • Actores: las entidades (personas, dispositivos) que interactúan con el sistema de destino produciendo o consumiendo información necesaria para el procesamiento de requisitos. Cada una de estas entidades externas se comunica con el sistema de destino mediante una interfaz (los pequeños rectángulos sombreados). Para ilustrar la utilización del DCA considérese de nuevo la función de seguridad casera del producto HogarSeguro. El controlador general y el sistema de Internet del producto HogarSeguro son superdordinados a la función de seguridad y se muestran arriba de la función en la figura 10.6. La función de vigilancia e s un sistema par y emplea (es empleado por) la función de seguridad en versiones posteriores del producto. Los páneles d e propietario y control son actores que actúan como productores y consumidores d e la información utilizada, producida (o de a m b o s tipos) por el software d e seguridad. Por último, el software de seguridad emplea los sensores, que s e muestran como subordinados de éste. Como parte del diseño arquitectónico tendrían que especificarse los detalles de cada interfaz mostrada en la figura 10.6. En esta etapa deben identificarse todos los datos que fluyen al interior o el exterior del sistema de destino.

10.4.2 Definición de arquetipos Un arquetipo es una clase o un patrón que representa una abstracción central importantísima en el diseño de una arquitectura para el sistema de destino. En general, se requiere un conjunto relativamente pequeño de arquetipos para diseñar incluso sistemas relativamente complejos. La arquitectura del sistema de destino la integran

Producto HogarSeguro

Sistema b a s a d o en Interne!

1 1

TM Función d e Usa

vigilancia Pares

PDF Editor

1 1

290

PARTE DOS


arquetipos, que representan e l e m e n t o s estables de la arquitectura pero que puededar p a s o a instancias de m u c h a s m a n e r a s diferentes, con b a s e en el comportarmeto del sistema. En m u c h o s casos, los arquetipos se derivan al e x a m in a r las clases de análisis c t finidas c o m o parte del modelo de análisis. Si se continúa el análisis de la función ir seguridad casera de HogarSeguro se definirían los siguientes arquetipos: • N o d o . Representa u n a colección cohesiva de e l e m e n t o s de entrada y salida e n la función de seguridad casera. Por ejemplo, un n o d o estaría integrado pe 1) varios s e n s o r e s y 2) varios indicadores de alarma (salida). • D e t e c t o r . Una abstracción que abarca todo el equipo de s e n s o r e s que alim e n t a información en el sistema de destino. • Indicador. Una abstracción que representa todos los m e c a n i s m o s (por eje~ pío, sirena de alarma, luces p a r p a d e a n t e s , timbre) para indicar que está ocurriendo u n a condición de alarma. • Controlador. Una abstracción que describe el m e c a n i s m o que permite el ar m a d o o d e s a r m a d o de u n nodo. Si los controladores residen e n u n a red tiener la capacidad de c o m u n i c a r s e entre sí. Cada u n o de e s t o s arquetipos se describe con la notación UML, c o m o se muestra ¿a la figura 10.7. Recuérdese que los arquetipos f o r m a n la b a s e de la arquitectura pero son a b s t n c ciones q u e d e b e n refinarse a ú n m á s a medida que a v a n z a el diseño arquitectór :: Por ejemplo, D e t e c t o r podría refinarse en una jerarquía de clase de sensores.

10.4.3 Refinamiento de la arquitectura en componentes A medida que se refina la arquitectura del s o f t w a r e en c o m p o n e n t e s , la estrucr-radel sistema empieza a emerger. Pero ¿cómo se eligen e s t o s c o m p o n e n t e s ? Para

Relaciones UML p a r a los arquetipos d e la función d e seguridad de HogarSeguro (adaptado de [BOSOO]).

Controlador

1

Se comunica con

TM Nodo

PDF Editor 3 1

Detector

Indicador

CAPÍTULO 10

* te de idel i» derivan s: los ¡de la aplicoi rrnxslrudvra Debido o )de ; cliende lo i el tiempo i liante el a pensar en j cuidado.

291


ponder, el diseñador de la arquitectura e m p i e z a con las clases descritas c o m o parte del modelo de análisis. 6 Estas clases de análisis representan entidades d e n t r o del d o minio de la aplicación (negocio) que deben a t e n d e r s e d e n t r o de la arquitectura del software. Por tanto, el dominio de la aplicación e s u n a f u e n t e para la derivación y el refinamiento de los c o m p o n e n t e s . Otra f u e n t e e s el dominio de la infraestructura. La arquitectura debe a d e c u a r s e a m u c h o s c o m p o n e n t e s de infraestructura que habilitan los c o m p o n e n t e s de la aplicación, p e r o que n o tienen conexión de negocios con el dominio de la aplicación. Por ejemplo, los c o m p o n e n t e s de administración de m e moria, de comunicación, de b a s e de d a t o s y de administración de tareas suelen integrarse en la arquitectura del software. La interfaz descrita en el diagrama de contexto de la arquitectura (sección 10.4.1) indica que u n o o m á s c o m p o n e n t e s especializados procesan los d a t o s q u e fluyen por la interfaz. En algunos c a s o s (por ejemplo, u n a interfaz gráfica de usuario) d e b e dis e ñ a r s e u n a arquitectura completa de s u b s i s t e m a s con m u c h o s c o m p o n e n t e s .

"Lo estructura de un sistema de software proporciona la ecología en q u e nace, m a d u r a y m u e r e el código. Un habitat bien diseñado permite el éxito en la evolución de todos los componentes necesarios d e un sistema de software:' R. Pattis

Continuando con la función de seguridad casera de HogarSeguro,

se definirá el

c o n j u n t o de c o m p o n e n t e s de nivel superior q u e atienden la siguiente funcionalidad: • Administración

de comunicación

externa: coordina la comunicación de la fun-

ción de seguridad con entidades externas; por ejemplo, sistemas de Internet, notificación externa de alarma. • Procesamiento

del panel de control: m a n e j a toda la funcionalidad del panel de

control. • Manejo del detector, coordina el a c c e s o a todos los detectores c o n e c t a d o s al sistema. • Procesamiento

de alarma: verifica todas las condiciones de alarma y actúa so-

bre ellas. Cada u n o de e s t o s c o m p o n e n t e s de nivel superior tendría q u e elaborarse iterativam e n t e y luego posicionarse d e n t r o de la arquitectura general de HogarSeguro.

Para

cada uno se definirían clases de diseño (con los atributos y las operaciones apropiadas). Sin embargo, e s importante observar que los detalles de diseño TM de todos los atributos y las o p e r a c i o n e s sólo s e especificarían hasta la realización del diseño en el nivel de c o m p o n e n t e s (capítulo 11).

PDF Editor

En la figura 10.8 se ilustra la estructura arquitectónica general (representada c o m o

un diagrama de c o m p o n e n t e s UML). El componente Manejo de comunicación

6

externa

Si se elige un enfoque convencional (no orientado a objetos». es posible derivar los componentes del modelo de tlujo de datos. En la sección 10.6 se analizara este enfoque

292

PARTE DOS


Estructura general de la arquitectura de HogarSeguro con componentes de nivel

~

„

Procesamiento de panel de control

Selección d e función

Manejo de detector

1 Procesamiento de alarma

adquiere las transacciones provenientes de los c o m p o n e n t e s que procesan la inL-^z gráfica de usuario de HogarSeguro y la interfaz de Internet. El componente director dt - garSeguro maneja esta información y selecciona la función de producto apropiada rs este caso, seguridad). El componente procesamiento

de panel de control interactúa

el propietario para armar o desarmar la función de seguridad. El componente marr.-M de detector agrupa los sensores para detectar una condición de alarma, y el compor ste procesamiento

de alarma produce una salida cuando se detecta la alarma.

10.4.4 Descripción d e la creación de instancias del sistema El diseño arquitectónico que se ha m o d e l a d o hasta este p u n t o a todavía es de u r n vel relativamente alto. Se h a r e p r e s e n t a d o el contexto del sistema; se han def los arquetipos que indican las abstracciones importantes dentro del dominio del ] blema; es evidente la estructura general del sistema; y se h a n identificado los | cipales c o m p o n e n t e s del software. Sin embargo, a ú n se necesita mayor refinar to (recuérdese que todo el diseño e s iterativo). Esto se logra desarrollando u n a instancia de la arquitectura. Es decir, la arqur.r: TM tura se aplica a u n problema específico con el propósito de d e m o s t r a r que la e s t tura y los c o m p o n e n t e s son apropiados.

PDF Editor

En la figura 10.9 se ilustra una instancia de la arquitectura HogarSeguro para el i

t e m a de seguridad. Los c o m p o n e n t e s que muestra la figura 10.8 se retinan a ú n para mostrar detalles adicionales. Por ejemplo, el componente manejo de detector ir ractúa con el componente de infraestructura calendarizador que implementa el as miento "concurrente" de cada objeto sensor del sistema de seguridad. Una elaborac similar se realiza para cada uno de los componentes representados en la figura IO S

CAPITULO 10

293


Instancia de la función de seguridad con elaboración de componentes.

Director HogarSeguro

Manejo d e comunicación externa

Procesamiento d e panel de control

Manejo d e detector

de alarma

y

* Protocolo de | teclado numérico

^ Calendarizador I S

Funciones d e ] despliegue CP Sensor

1

v

Comunicación I \ telefónica I »

j

Alarma


Diseño arquitectónico O b j e t i v o : Las herramientas de diseño arquitectónico modelan la estructura general del i al representar interfases, dependencias, es e interacciones de los componentes. canica: Las herramientas cuentan con mecánicas as. En casi todos los casos, la capacidad del diseño nico es parte d e la funcionalidad de las nientas automatizadas para modelado de análisis y Herramientas representativas7

(www.synthis.com), es una herramienta especializada para el diseño y la construcción de arquitectura específicas de componentes Web. ObjectiF, desarrollada por microTOOL GmbH (www.microtool.coml, es una herramienta de diseño UML que lleva a arquitecturas (por ejemplo, Coldfusion, J2EE, Fusebox) sensibles a la ingeniería de software basada en componentes (capítulo 30). Rational Rose, desarrollada por Rational TM (www.rational.com), es una herramienta de diseño basada en UML que soporta todos los aspectos del diseño arquitectónico.

PDF Editor n, desarrollada por Synthis Corp.

7

Las herramientas expuestas sólo representan una muestra de esta categoría. En casi todos los casos los nombres son marcas registradas por sus respectivos desarrolladores.

2 9 4

P A R T E D O S

10.5


E V A L U A C I Ó N DE DISEÑOS A P A M T E C T Ó N I C O S ALTEEMOS En el mejor de los casos, el diseño produce varias opciones arquitectónicas que evalúan para determinar cuál es la m á s apropiada respecto al problema que h a b n de resolverse. En las siguientes secciones se analizaran diseños arquitectónicos a. temos.

"Tal v e z seo e n el s ó t a n o . D é j a m e ir escoleras arriba y revisar.' M. C. Escher

10.5.1 Un método de análisis de compensación p a r a la arquitectura El Instituto de Ingeniería del Software (SEI, por sus siglas en inglés) ha desarrollad un método de análisis de compensación

para la arquitectura (MACA) [KAZ98] que ¿c

fine un proceso de evaluación iterativo para las arquitecturas del software. Las ; guientes actividades de análisis del diseño se realizan iterativamente: Informoóón o fondo sobre MACA se obtendré en

1. Recopilar escenarios. Se desarrolla u n c o n j u n t o de casos de uso (capítulos 7 •

www.sei.cirai.sdu/ ata/otajnethod. html.

2.

8) para representar el sistema desde el punto de vista del usuario. Deducir requisitos, restricciones y descripción de entornos. Esta información se requiere como parte de la ingeniería de requisitos y se usa para asegurarse ct que se atiendan todas las preocupaciones de los participantes. 3.

Describir los estilos/patrones

arquitectónicos que se han elegido para dirigir los

escenarios y requisitos. 4.

Evaluar los atributos de calidad al considerar cada atributo de manera aislada. Entre los atributos de calidad para la evaluación del diseño arquitectónico se incluyen confiabilidad, desempeño, seguridad, facilidad de mantenimiento, flexibilidad, facilidad de prueba, portabilidad, facilidad de reutilización e intercperabilidad.

5.

Identificar la sensibilidad de los atributos de calidad respecto de varios atributos arquitectónicos para un estilo arquitectónico específico. Esto se logra haciendo p e q u e ñ o s cambios en la arquitectura y determinando la sensibilidad al cambio de un atributo de calidad, c o m o el desempeño. CualquierTM atributo al que afecte significativamente la variación en la arquitectura se considerará u n punto de sensibilidad.

PDF Editor

6. Analizar las arquitecturas alternas (desarrolladas en el paso 3) empleando el anc lisis de sensibilidad aplicado en el paso 5. El SEI describe este enfoque de la siguiente m a n e r a [KAZ98]:

Una v e z d e t e r m i n a d o s los p u n t o s d e s e n s i b i l i d a d a r q u i t e c t ó n i c a s e e n c u e n t r a n l o s p u n t o s

e n q u e se r e q u i e r e c o m p e n s a c i ó n c o n s ó l o identificar l o s e l e m e n t o s a r q u i t e c t ó n i c o s a los

CAPÍTULO 10

295


que son sensibles varios atributos. Por ejemplo, el d e s e m p e ñ o d e una arquitectura cliente-servidor sería muy sensible al n ú m e r o d e servidores (el d e s e m p e ñ o a u m e n t a r á , dentro d e cierto rango, al a u m e n t a r el n ú m e r o de servidores)... Por tanto, el n ú m e r o d e servidores es un punto d e c o m p e n s a c i ó n p a r a esta arquitectura.

Estos seis pasos representan la primera iteración MACA. Con b a s e en los resultados de los pasos 5 y 6 será posible eliminar algunas opciones arquitectónicas, modificar una o m á s de las arquitecturas restantes y representarlas con m á s detalle, y luego aplicar de nueva cuenta los p a s o s de MACA.8

HOGARSEGURO

Evaluación de la arquitectura - j ' G n

El e s c e n a r i o : Oficina de Doug as continúa el modelado del diseño

s : Vinod, Jamíe, Shakira y Ed, integrantes : d e ingeniería del software HogarSeguro. Doug Miller, jefe del grupo de ingeniería del rsación: Sé que están derivando un par d e arquitecturas , para el producto HogarSeguro, y eso es Supongo que mi pregunta es ¿cómo elegiremos la Estoy trabajando en un estilo d e llamada y retorno, y Jamie o yo vamos a derivar una arquitectura : a objetos. Muy bien, ¿y cómo la elegiremos? : Tomé un curso de diseño en mis años de i , y recuerdo que hay varias maneras de : Las hay, pero son un poco académicas. Mira, que podemos hacer nuestra evaluación y elegir la > casos de uso y escenarios. ¿No es lo mismo? : No cuando estás hablando de evaluación r-suitectónica. Ya tenemos un conjunto completo de

casos de uso. Así que apliquemos cada una de las arquitecturas y veamos cómo reacciona el sistema; es decir, cómo funcionan los componentes y los conectares en el contexto del caso de uso. Ed: Es uno buena idea. Eso nos asegura que no dejaremos nada fuera. V i n o d : Cierto, pero también nos indica si el diseño arquitectónico no es directo, si tiene que doblarse como moño para hacer el trabajo, por decirlo así. J a m i e : ¿No es lo mismo un escenario que un caso d e uso? V i n o d : No, en este caso un escenario es algo diferente. D o u g : Estás hablando de un escenario de calidad o uno de cambio, ¿o no? V i n o d : Si. Lo que hacemos es regresar con los participantes y preguntarles cómo cambiará HogarSeguro en los siguientes tres años, por decir algo. Ya sabes, nuevas versiones, características, ese tipo d e cosas. Construimos un conjunto de escenarios d e cambio. También desarrollamos un conjunto d e escenarios de calidad que definen los atributos que nos gustaría ver en la arquitectura del software. J a m i e : Y los aplicamos a las opciones.

TM V i n o d : Exacto. El estilo que maneje mejor los casos de uso y los escenarios es el que escogeremos.

PDF Editor 8

El método de análisis de la arquitectura del software (MAAS) es una alternativa a MACA y vale la pena que los lectores interesados en el análisis arquitectónico lo examinen Un artículo sobre MAAS se descarga de http://www.sei.cmu.edu/publications/artides/saam-metho-propert-sas.htm.

296

PAUTE DOS


10.5.2 Complejidad arquitectónica Una técnica útil para evaluar la complejidad general de una arquitectura determ:-; da consiste en considerar las dependencias entre componentes dentro de la arc_ tectura. Estas dependencias las orienta la información, el flujo de control, o ambas dentro del sistema. Zhao [ZHA98] sugiere tres tipos de dependencias: Dependencias

compartidas q u e representan relaciones de dependencia entre consumido-

res que u s a n el m i s m o recurso o los productores que producen p a r a los m i s m o s consumidores. Por ejemplo, s u p ó n g a n s e dos c o m p o n e n t e s u y v q u e se refieren a los m i s m o : datos globales. Entonces existe u n a relación de dependencia compartida entre u y v . Dependencias

de finjo que representan las relaciones de d e p e n d e n c i a entre productores

c o n s u m i d o r e s de recursos. Por ejemplo, p a r a dos c o m p o n e n t e s u y v, si u debe completarse a n t e s d e que el control p a s e a v (prerrequisito) o si u se comunica con v m e d i a n ! : parámetros, e n t o n c e s existe u n a relación de dependencia de flujo entre u y v . Dependencias

restringidas q u e representan restricciones al flujo relativo de control entre

un c o n j u n t o de actividades. Por ejemplo, si d o s c o m p o n e n t e s u y u n o p u e d e n ejecutarse al mismo tiempo (exclusión mutua), e n t o n c e s existe una relación d e dependencia restringida entre u y v .

Las dependencias compartidas y de flujo que señala Zhao son similares al con de acoplamiento descrito en el capítulo 9. Acoplamiento es un concepto importante de diseño que se aplica al nivel de arquitectura y de componentes. En el capítulo 15 expondrán métricas simples para evaluar el acoplamiento.

10.5.3 Lenguajes de descripción arquitectónica El arquitecto de una casa tiene un conjunto de herramientas estandarizadas y de tación que permite representar el diseño de una manera poco ambigua y fáci. comprender. Aunque el arquitecto del software puede dibujar con notación UML necesitan otras formas de diagramación, y unas cuantas herramientas relación para aplicar un enfoque m á s formal a la especificación de un diseño arquitect El lenguaje de descripción arquitectónica (LDA) proporciona una semántica y sintaxis para describir una arquitectura del software. Hofmann y sus colegas [H sugieren que un LDA debe proporcionar al diseñador la capacidad de separar TMbloques a ponentes arquitectónicos, de integrar componentes individuales en tectónicos mayores y de representar interfaces (mecanismos de conexión) componentes. Una vez que se hayan establecido las técnicas descriptivas, ba en el lenguaje para diseño arquitectónico, es m á s probable que se establezcan métodos de evaluación efectivos para la arquitectura a medida que el diseño evoá-ciona.

PDF Editor k.

I

CAPÍTULO 10

297



Lenguajes de descripción arquitectónica El siguiente resumen de varios LDA importantes lo preparó Rickard Land [LAN02] y se i con el permiso del autor. Debe observarse que > cinco LDA se han desarrollado con fines de ción y no son productos comerciales,

Wrighl (www.cs.cmu.edu/~able/wright/) [ALL97] formaliza los estilos arquitectónicos empleando predicados, lo que permite comprobar la estática para determinar la consistencia y el grado en que se ha completado una arquitectura.

t (poset.stanford.edu/rapide/) [LUC95] construye a sartir de la noción de conjuntos parciales ordenados.

Acmé (www.cs.cmu.edu/~acme/)[GAROO] es un LDA de segunda generación.

i (www.cs.cmu.edu/-UniCon) [SHA96] define arquitecturas de software desde el punto de vista de distracciones útiles para los diseñadores.

UML (www.uml.org/) incluye muchos de los artefactos necesarios para descripciones arquitectónicas; no es tan completo como otros LDA.

«.cs.cmu.edu/~able/aesop/) [GAR94] atiende el problema de reutilización del estilo.

Los estilos analizados en la sección 10.3.1 representan arquitecturas radicalmente diferentes; por tanto, no debe sorprender que n o exista u n a completa correlación (o mapeo) que logre la transición del modelo de análisis a diversos estilos arquitectónicos. En realidad, n o hay correlación práctica para a l g u n o s estilos arquitectónicos. El diseñador d e b e a b o c a r s e a la traducción de requisitos en diseño para e s t o s estilos m e d i a n t e las técnicas a n a l i z a d a s en la sección 10.4. Ilustrar un e n f o q u e de la correlación arquitectónica requiere tener en cuenta una técnica de correlación aplicada a la arquitectura de llamada y retomo (una estructura muy c o m ú n en m u c h o s tipos de sistemas). Esta técnica de correlación permite que un diseñador derive arquitecturas de llamada y retorno r a z o n a b l e m e n t e complejas a partir de d i a g r a m a s de flujo de d a t o s d e n t r o del modelo de análisis. La técnica, a vec e s d e n o m i n a d a diseño estructurado,

se presenta en libros de Myers [MYE78] y Your-

don y Constantin [YOU79]. El diseño estructurado suele caracterizarse c o m o un m é t o d o de diseño orientado a flujo de datos, ya q u e proporciona una conveniente transición de un diagrama de flujo de d a t o s (capítulo 8) a una arquitectura del software. El tipo de flujo de información e s el controlador para el e n f o q u e de correlación o m a p e o . TM

10.6.1 Flujo de transformación

PDF Editor

La información d e b e entrar y salir del software en una forma lógica para "la realidad

externa". Por ejemplo, los d a t o s escritos en u n teclado, los t o n o s d e u n a línea telefónica y las i m á g e n e s de video en u n a aplicación multimedia son medios d e información de la realidad externa. Estos d a t o s externos deben convertirse en una forma interna para el procesamiento. La información ingresa en el sistema por rutas q u e

298

PARTE DOS


transforman los d a t o s externos en una forma interna. Estas rutas se identifican c: m o flujo de entrada. En el núcleo del s o f t w a r e ocurre u n a transición. Los d a t o s e n trantes se p a s a n por u n centro de transformación

y e m p i e z a n a moverse por rutas que

ahora los llevan "fuera" del software. Al desplazamiento de los d a t o s por estas rutas se le d e n o m i n a flujo de salida. El flujo general de d a t o s ocurre de m a n e r a s e c u e n c ü y sigue u n a o u n a s c u a n t a s rutas "en linea recta". 9 C u a n d o un s e g m e n t o de un
10.6.2 Flujo de transacción AI flujo de información suele caracterizarlo un solo e l e m e n t o de datos, llamado t r j r - l sacción, que dispara otro flujo de d a t o s por u n a de m u c h a s rutas. Cuando un diag-i | m a de flujo de datos (DFD) a s u m e la forma mostrada e n la figura 10.10 está preser ca el flujo de transacción. Al flujo de transacción lo caracterizan los d a t o s que s e desplazan por un carrr.;» entrante que convierte la información proveniente del exterior en u n a transacc:

J

Ésta se evalúa y, con b a s e en su valor, se inicia el flujo por una de m u c h a s ruta: d acción. Al e l e m e n t o que concentra y distribuye el flujo de información, del que e~¿ n a n m u c h a s rutas de acción, se le d e n o m i n a centro de transacción. Debe observarse que, dentro del DFD de un sistema grande, tienen que estar :

•

s e n t e s los flujos de transformación y transacción. Por ejemplo, e n u n a t r a n s a c o r a l orientada a flujo, el flujo de información por un c a m i n o de acción p u e d e tener i r 4 racterísticas del flujo de transformación..

Flujo de transacción.

TM

PDF Editor 9

Una correlación obvia para este tipo de flujo de información es la arquitectura de flujo de datos a crita en la sección 10.3.1. Sin embargo, hay muchos casos en que esta arquitectura tal vez no st= • mejor elección para un sistema complejo. Entre los ejemplos se incluyen sistemas que expenTratarán cambios sustanciales con el tiempo o sistemas en los cuales el procesamiento asociadc • el flujo de datos no necesariamente resulta secuencial.

CAPÍTULO 10

10.6.3

299


Correlación d e t r a n s f o r m a c i o n e s

La correlación de transformaciones es un conjunto de pasos d e diseño que permite que un DFD con características de flujo de transformación s e correlacione con un estilo arquitectónico específico. Ilustrar este enfoque requiere considerar de nuevo la función de seguridad HogarSeguro.'0

Un elemento del modelo de análisis e s un con-

junto de diagramas de flujo de datos que describen el flujo de información dentro de la función de seguridad. Con el fin de correlacionar estos diagramas en una arquitectura se llevan a cabo los siguientes pasos de diseño: P a s o 1. Revisar el m o d e l o fundamental del s i s t e m a . El modelo fundamental del sistema o diagrama de contexto describe la función de seguridad c o m o una sola transformación, que representa a los productores y consumidores externos de los datos que fluyen al interior y hacia fuera de la función. En la figura 10.11 se describe un modelo de nivel 0; en la 10.12 se muestra un flujo de datos refinado para la función de seguridad. P a s o 2. Revisar y refinar l o s diagramas d e flujo de d a t o s para el s o f t w a r e . La información obtenida de los modelos de análisis se refina para producir mayor detalle. Por ejemplo, se examina el DFD de nivel 2 para supervisar sensores (figura 10.13) y se deriva un diagrama de flujo de datos de nivel 3, como s e muestra en la figura 10.14. En el nivel 3 cada transformación del DFD muestra una cohesión relativamente alta (capítulo 9). Es decir, el proceso implícito en una transformación realiza una función única y distintiva que puede implementarse como un componente del software HogarSeguro. Por tanto, el DFD de la figura 10.14 contiene suficiente detalle para un "primer corte" en el diseño arquitectónico del subsistema supervisar sensores, y se sigue adelante sin mayor refinamiento.

Comandos y datos • d e usuario

Información d e despliegue

Software HogarSeguro

Tipo de alarma

Despliegue d e panel d e control

Alarma

TM Sensores

Estatus d e sensores

Tonos de número telefónico

PDF Editor

10 Sólo se considera una parte de la función de seguridad de HogarSeguro que usa el panel de control. No se tendrán en cuenta otras características expuestas al principio de este libro y en este capítulo.

300

DFD d e n i v e l 1 para la función d e seguridad de HogarSeguro.

PARTE DOS

Panel d e control


Comandos leusuario y datos

Datos d e configuración con usuario \ Contraseña \

Solicitud d e configuración Inicio detención

Información d e conl

Activar/ desactivar > sistema ¡

' activación \ desactivación

Datos de_ nfiguración

M e n s a j e ID válido Datos de_ / configuración /

Sensores

DFD d e n i v e l 2 q u e refina la transformación moniforear sensores.

icion liegue Información d e sensores Tipo d e alarma

Estatus d e sensores

Alarme

Tonos d e número telefó nico

Formar despliegue Información d e configuración | ID, tipo, "^^^^"^"^"ubicación ^ \ d e sensores configuración

/

cont[a

Información d e sensores

Generar señal d e alarma

Tipo d e alarma

Datos de alarma Número telefónico

Leer sensores Estatus d e sensores

ID, tipo d e sensores

Marcar teléfono Tonos d e número" telefónico

TM

PDF Editor

P a s o 3. D e t e r m i n a r si el D F D t i e n e características d e flujo d e transió

c i ó n o d e t r a n s a c c i ó n . E n g e n e r a l , s i e m p r e e s p o s i b l e r e p r e s e n t a r el f l u j o d e

:«

m a c i ó n d e n t r o d e u n s i s t e m a c o m o u n a t r a n s f o r m a c i ó n . S i n e m b a r g o , c u a n d o s e en-

c u e n t r a u n a c a r a c t e r í s t i c a o b v i a d e t r a n s a c c i ó n (figura 10.10), s e r e c o m i e n d a c o r r e l a c i ó n d e d i s e ñ o d i f e r e n t e . En e s t e p a s o el d i s e ñ a d o r s e l e c c i o n a l a s c a r

CAPÍTULO 10

301

DISEÑO ARQUITECTONICO

DFD de nivel 3 para monitorear sensores con límites de flujo.

Información d e configuración! — ' Datos d e configuración Estatus del sensores i

Información d e sensores

Formar ' ispliegue

Leer sensores

ID, configuración d e sensores

ID, tipo, ubicación con formato

/Adquirí r \ información'

ID, tipo\ ubicaciónX de sensores

lablecer > idiciones alarmai Código de condición d e números a l a r m a , ID d e sensores, información d e c a l e n d a r i o

Generar Tipo señal d e Ide alarma . alarma , Datos d e alarma

numero

Número telefónico

conexión con red niccy Tono listo p a r a número telefónico

Generar

Tonos d e número telefónico

ticas de flujo global (de todo el software) con b a s e en la naturaleza prevaleciente del DFD. Además, se aislan las regiones locales del flujo de transformación o transac-

,VE se encontroiposdeflutienlTO del : orientao s flujos se l c estructura j se deriva c correlación

»

b ubicación : de flu¡o ! explotar altemos de Esto toma tiempo y informa-

ción. Estos subflujos se aprovechan para refinar la arquitectura del programa derivado de u n a característica global descrita antes. Por ahora, la atención se centrará sólo e n el flujo de d a t o s del subsistema monitorear s e n s o r e s descrito en la figura 10.14. Al evaluar el DFD (figura 10.14) se aprecia que los d a t o s entran al software por u n a ruta de e n t r a da y salen por tres rutas de salida. No participa un centro de transacción distintivo (aunque la transformación establece condiciones de alarma que podrían percibirse c o m o tales). Por tanto, se s u p o n d r á u n a característica general de transformación para el flujo d e la información. P a s o 4 . Aislar el c e n t r o d e t r a n s f o r m a c i ó n al e s p e c i f i c a r l í m i t e s d e flujo d e e n t r a d a y salida. En la sección anterior, el flujo de e n tr a da se describió c o m o un

TM interna; el c a m i n o q u e convierte la información con forma externa en información flujo de salida h a c e la conversión inversa. Los límites de los flujos d e e n tr a da y salida están abiertos a la interpretación. Es decir, diferentes diseñadores seleccionarán

PDF Editor

p u n t o s ligeramente diferentes del flujo c o m o posición de los límites. En realidad, las soluciones alternas de diseño s e obtienen al modificar la posición d e los límites de flujo. Aunque d e b e tenerse cuidado al seleccionar los límites, la variación en u n a burbuja a lo largo del c a m i n o de flujo g e n e r a l m e n t e tendrá p o c o impacto e n la estructura final del programa.

•

302

PARTE D O S


Los límites de flujo en este ejemplo se ilustran c o m o curvas s o m b r e a d a s que rren verticalmente por el flujo de la figura 10.14. Las transformaciones (bur que constituyen el centro de transformación caen dentro de los dos límites s o m b r t i dos que corren de arriba a b a j o en la figura. Podría respaldarse el a r g u m e n t o de es posible reajustar u n límite (por ejemplo, podría proponerse un límite de flujo entrada que separe leer sensores y adquirir información de respuesta). En este paso de r. ÔNSUOi^

No se debe odoptor un enfoque dogmático en esto etapa. Jal vez seo necesario establecer dos o más controladorespara procesamiento o cálculo de entrada, con base en lo complejidad del sistema que habrá de construirse. Si el sentido común dicta este enfoque, ¡úsese/

s e ñ o d e b e resaltarse la selección de límites razonables, n o la larga iteración sobri posición de los límites. P a s o 5. Realizar una "factorización d e p r i m e r nivel". La arquitectura del :~ g r a m a que se ha derivado a partir de los resultados de la correlación lleva a una astribución d e s c e n d e n t e del control. La factorización

g e n e r a u n a estructura de pro— r

ma e n que los c o m p o n e n t e s d e s c e n d e n t e s se e n c a r g a n de la toma de decisión— los c o m p o n e n t e s de b a j o nivel realizan m á s trabajo de entrada, cálculo y salida - c o m p o n e n t e s de nivel intermedio se e n c a r g a n de parte del control y realizan d a d e s m o d e r a d a s de trabajo. Al encontrar el flujo de transformación se correlaciona un DFD con u n a e s t r u j a ra específica (una arquitectura de llamada y retorno) que proporciona control para procesamiento de la información de entrada, de transformación y de salida. En U f gura 10.15 se muestra esta factorización de primer nivel p a r a el subsistema supt-msar sensores. Un controlador principal (llamado supervisar director de sensores) resi.^r

Factorización de primer nivel para supervisar sensores.

TM

PDF Editor

CAPÍTULO 10


303

en la parte superior de la estructura del programa y coordina las siguientes funcione s subordinadas de control: • Un controlador de procesamiento de información entrante, llamado controlador de entrada de sensores, coordina la recepción de todos los datos de entrada. • Un controlador de flujo de transformación, llamado controlador de condiciones de alarma, supervisa todas las operaciones de los datos en forma adecuada para el trabajo interno (por ejemplo, un módulo que invoca varios procedimientos de transformación de datos). • Un controlador de procesamiento de información saliente, llamado controlador de salida de alarma, coordina la producción de información de salida. Aunque una estructura de tres picos se desprende de la figura 10.15, flujos complejos en sistemas grandes llegan a pedir dos o más módulos de control para cada una de las funciones genéricas de control descritas. El número de módulos en el primer nivel debe limitarse al mínimo posible para realizar las funciones de control y aun mantener buenas características de independencia funcional. P a s o 6. Realice una "factorización d e s e g u n d o nivel". La factorización de segundo nivel se logra al correlacionar las transformaciones individuales (burbujas) d e una DFD con los módulos apropiados dentro de la arquitectura. Si se empieza en el límite del centro de transformación y se desplaza hacia fuera por rutas de entrada y luego por rutas de salida, las transformaciones se correlacionarán en niveles subordinados de la estructura del software. En la figura 10.16 se muestra el enfoque general de la factorización de segundo nivel. Aunque en la figura 10.16 se ilustra una correlación uno a uno entre transformaciones de DFD y módulos d e software, suelen ocurrir correlaciones diferentes. Es posible combinar dos o hasta tres burbujas y representarlas como un componente, o expandir una sola burbuja en dos o más componentes. Consideraciones prácticas y medidas de la calidad del diseño dictan el resultado de la factorización de segundo nivel. La revisión y el refinamiento producen cambios en la estructura, pero sirven c o m o diseño de "primera iteración" La factorización de segundo nivel para el flujo de entrada se realiza de la misma manera. La factorización se realiza nuevamente al desplazarse hacia fuera, desde el límite del centro de transformación en el lado del flujo de entrada. El centro de transformación del software del subsistema monitorear sensores se correlaciona de maneTM ra un poco diferente. Cada conversión de datos o transformación de datos de la parte de la transformación del DFD se correlaciona con un módulo que está subordina-

PDF Editor

do al controlador de transformación. En la figura 10.17 se muestra una arquitectura de primera iteración completa. Los componentes correlacionados de la manera anterior y mostrados en la figura 10.17 representan un diseño inicial de la arquitectura del software. Aunque el nombre de los componentes indica una función, debe escribirse una breve explica-

304

PARTE D O S


Factorización de segundo nivel para supervisar sensores.

Formar

señal d e .alarma j

conexión con red telefónica

Supervisar director d e sensores

Limite d e f l u j o \ d e transformación Controlador d e entrada d e sensores

Controlador de condiciones de alarma

Controlador d e salida d e alarma

Formar despliegue


conexion con red telefónica

Generar despliegue

Estructura de primera iteración para supervisar sensores. Monitorear director d e sensores

Controlador de entrada d e sensores

Controlador d e salida de alarma

Controlador d e condiciones d e alarma


TM Configurar conexion c o r red telefónico

PDF Editor información d e respuesta

Establecer condiciones de alarma

«leccionar número telefónico

Formar despliegue

Generar despliegue

Generar pulsos 3ara linea

CAPÍTULO 10

305


ción de su p r o c e s a m i e n t o (adaptado de la especificación creada durante el modelado del análisis). ilain
quese Hobjermcoy un bajo.

P a s o 7. Refinar la arquitectura d e p r i m e r a i t e r a c i ó n e m p l e a n d o d i s e ñ o h e u rístico para m e j o r a r la c a l i d a d del s o f t w a r e . Siempre es posible refinar u n a arquitectura de primera iteración si se aplican conceptos de independencia funcional (capítulo 9). Los c o m p o n e n t e s se e x p a n d e n o c o n t r a e n para producir u n a factorización sensible, una b u e n a cohesión, un a c o p l a m i e n t o mínimo y, lo q u e e s m á s importante, una estructura que se implemente sin dificultades, se pruebe sin confusión y se m a n t e n g a sin problemas. Los refinamientos los determinan los m é t o d o s de análisis y evaluación descritos b r e v e m e n t e en la sección 10.5, a d e m á s de las consideraciones prácticas y el sentido c o m ú n . Por ejemplo, hay ocasiones que el controlador del flujo de d a t o s de e n tr a da resulta totalmente innecesario, que se requiere algún p r o c e s a m i e n t o de e n tr a da en un c o m p o n e n t e subordinado al controlador de transformación, que no p u e d e evitarse el acoplamiento elevado debido a los d a t o s globales, o que n o logran alcanzarse las características óptimas de la estructura. Los requisitos del software, junto con el juicio h u m a n o , d e b e n servir p a r a t o m a r la decisión final. El objetivo de los siete p a s o s p r e c e d e n t e s es desarrollar u n a representación arquitectónica del software. Es decir, u n a vez definida la estructura, es posible evaluar y refinar la arquitectura del s o f t w a r e al tener un p a n o r a m a general de él. Las modific a c i o n e s h e c h a s e n e s t e m o m e n t o requieren poca información adicional, p e r o tendrán un fuerte impacto en la calidad del software. El lector d e b e hacer una breve p a u s a y considerar la diferencia entre el enfoque del diseño descrito y el proceso de "escribir programas". Si el código es la única representación del software, el desarrollador tendrá gran dificultad para evaluar o refinar a voluntad, en un nivel global u holístico. En realidad, tendrá dificultad para "ver el b o s q u e entre los árboles".

-ÍOGARSEGURO

Refinamiento de una arquitectura de primera iteración «IBI El e s c e n a r i o : Cubículo de Jamie, s se continúa con el modelado del diseño, a c t o r e s : Jamie y Ed, integrantes del equipo de in-ía del software HogarSeguro.

conversación:

Ed: Mira, aquí está la arquitectura que he obtenido. (Ed muestra a Jamie la figura 10.17, que ella estudia por TM unos momentos.] J a m i e : Está muy bien, pero creo que podemos hacer algunas cosas para simplificarla y mejorarla.

PDF Editor acaba de completar un diseño d e primera iteración subsistema monitorear sensores. Se detiene para pesu opinión a Jamie.)

Ed: ¿Cómo cuáles?

J a m i e : Bueno, ¿por qué usas el componente con trotador de entrada de sensores?

306

PARTE DOS


Ed: Porque necesitas un sensor para b correlación.

Ed: Simplificación, ¿eh?

J a m i e : En realidad no. El controlador no hace mucho, porque estamos manejando un solo camino de flujo para los datos de entrada. Podemos eliminar et controlador sin exponernos a efectos colaterales.

J a m i e : Así es. Y mientras hacemos refinamientos, ser;; buena idea reducir los componentes formar despliegue • generar despliegue. El formato del despliegue del pane de control es simple. Podemos definir un nuevo módulo llamado producir despliegue.

Ed: Puedo vivir con eso. Haré el cambio y... J a m i e ( s o n r i e n d o ) : jEspera! También podemos reducir los componentes establecer condiciones de alarma y seleccionar número telefónico. En realidad el controlador de transformación que muestras no es necesario, y la pequeña reducción de la cohesión resulta tolerable.

Ed ( t r a z a n d o u n b o c e t o ) : ¿De modo que esto es le que crees que podemos hacer? ¡Muestra a Jamie la figura 10.18.) J a m i e : Es un inicio.

Supervisar aireclor d e sensores

Estructura refinada del programa para supervisar sensores.

información de respuesta

Establecer condiciones de alarma

Producir despliegue

10.6.4

Controlador salida de alarma

señal de alarma

Configurar conexion con red telefónica

Correlación d e t r a n s a c c i o n e s

En m u c h a s aplicaciones de software, un solo elemento de d a t o s dispara varios jos de información que afectan u n a función relacionada con el e l e m e n t o de que dispara. El e l e m e n t o de datos, llamado transacción, y sus correspondientes a racterísticas de flujo se analizaron en la sección 10.6.2. En esta sección se c o n s r f j TM rarán los p a s o s de diseño e m p l e a d o s para correlacionar el flujo de transacciór rd u n a arquitectura de software. La correlación de transacciones se ilustrará si se considera el subsistema ús •

PDF Editor teracción con el usuario de la función de seguridad de HogarSeguro.

En la

rJ

10.12 se muestra el flujo de datos de nivel 1 para este subsistema. Al refinar e ~nJ

se deriva un d i a g r a m a de flujo de datos de nivel 2, c o m o se muestra en la : r a 10.19. El objeto de d a t o s c o m a n d o s d e u s u a r i o fluye dentro del sistema y g e n a

un flujo de información adicional por u n a de tres rutas de acción. Un solo eler^Ti

CAPÍTULO 10


307

de datos, tipo de c o m a n d o , hace que el flujo de datos se expanda hacia fuera del concentrador. Por tanto, la característica general del flujo de datos está orientada a la transacción. Debe observarse que el flujo de información a lo largo de dos de las tres rutas de acción acomoda el flujo de entrada adicional (por ejemplo, p a r á m e t r o s y d a t o s del s i s t e m a son entradas del camino de acción "configurar"). Todas las rutas de acción fluyen en una sola transformación, desplegar mensajes y estatus. Los pasos del diseño para la correlación de transacciones son similares y en algunos casos idénticos a los pasos para correlación de transformaciones (sección 10.6.3). Una diferencia importante se encuentra en la correlación del DFD con la estructura del software. P a s o 1. Revisar el m o d e l o fundamental del s i s t e m a . P a s o 2. Revisar y reñnar l o s diagramas de flujo de d a t o s para el software. P a s o 3. Determinar si el DFD tiene características d e flujo d e transformac i ó n o de transacción. Los pasos 1, 2 y 3 son idénticos a los correspondientes en la correlación de transformaciones. El DFD que se muestra en la figura 10.19 tiene una característica de flujo de transformación clásico. Sin embargo, el flujo por las rutas de acción que e m a n a n de la burbuja invocar procesamiento de comandos parece contar con características de flujo de transformación. Por tanto, deben determinarse límites de flujo para a m b o s tipos. P a s o 4. Identificar el centro de transacción y las características de flujo e n cada una de l a s rutas de a c c i ó n . La ubicación del centro de transacción se desprende directamente del DFD. El centro de transacción se encuentra en el origen de varias rutas de acción que fluyen de él de manera radial. En el caso del flujo mostrado en la figura 10.19, la burbuja invocar procesamiento de comandos es el centro de transacción. El camino entrante (es decir, el camino del flujo en que se recibe la transacción) y todas las rutas de acción deben estar aislados. Es necesario evaluar la característica de flujo individual de cada camino de acción. Por ejemplo, el camino "contraseña" (mostrado dentro de un área sombreada en la figura 10.19) tiene características de transformación. El flujo de entrada, de transformación y de salida se indican con límites. TM P a s o 5. Correlacionar el DFD c o n una estructura de programa s e n s i b l e al p r o c e s a m i e n t o d e la transacción. El flujo de transacción s e correlaciona con una arquitectura que contiene una rama entrante y una para despacho. La estructura de la rama entrante se desarrolla de manera muy parecida a la correlación de transformaciones. Si se empieza en el centro de transacción, las burbujas ubicadas a lo largo del camino entrante se correlacionan con módulos. La estructura de la rama para despacho contiene un módulo despachador que controla todos los módulos de ac-

PDF Editor

308

PARTE DOS


DFD de nivel 2 para el subsistema de interacción con el usuario. Datos d e configuración Parámetros y datos sin trabajar del sistema ~

Comandos d e usuario Leer comandos d e usuario

Tipo d e / comandos ( Leer \ V > ^Configurar { datos del sistema

á J : T T L ' a,ch,vo c e Datos d e configuración con formato

Inicio detención Contraseña

Activar/ desactivai sistema

Información d e confii ¡uracion Mensaje d e activación/ desactivación

'

Contraseña

Contraseña no válida

Datos de configuración

Datos d e configuración

Producir mensaje de que no . es válida .

DesplegarX mensajes I — • y estatus ¡ Informador v ^ ^ d e despliegue

Mensaje inténtelo d e nuevo'

ción subordinados. Cada c a m i n o de flujo de acción del DFD se correlaciona cor estructura que c o r r e s p o n de a s u s características de flujo específicas. Este proces: j a ilustra e s q u e m á t i c a m e n t e e n la figura 10.20. Si s e t o m a en cuenta el flujo de d a t o s del s u b s i s t e m a de interacción con el u s . a J rio, la factorización de primer nivel para el p a s o 5 se muestra e n la figura 10.21. _aH b u r b u j a s leer comandos

del usuario y activar/desactivar

sistema se correlacionar. J-j

rectamente con la arquitectura sin necesidad de m ó d u l o s de control inmediat: SI centro de transacción, invocar comando

de procesamiento,

se correlaciona d i r e - r J

m e n t e con el módulo d e s p a c h a d o r del m i s m o nombre. Se crean c o n s o l a d o r e s p a a la configuración del sistema y el procesamiento de la contraseña, c o m o se ilustra a • figura 10.21.

TM P a s o 6 . Factorizar y r e f i n a r la e s t r u c t u r a d e t r a n s a c c i ó n y la d e c a d a cana-j n o d e a c c i ó n . Cada c a m i n o de acción del DFD tiene sus propias características M flujo de información. Ya se ha observado que es posible encontrar los flujos de trans

PDF Editor

mación o transacción. La "subestructura" relacionada con el c a m i n o de accita • desarrolla e m p l e a n d o los p a s o s de diseño analizados en esta sección y en la i - s | rior.

Como ejemplo, considérese el flujo de información de p r o c e s a m i e n t o de la : f l l

t r a s e ñ a que se muestra en la figura 10.19 (dentro del área sombreada). El flujo r

-»

Director de interacción con el usuario

Invocar procesamiento d e comandos

Leer comandos d e usuario

Controlador d e | configuración I d e sistema

Activar/ desactivar sistema

Controlador de procesamiento de contraseña

tra características de transformación clásicas. Se ingresa una contraseña (flujo entrante) y se transmite a un centro de transformación donde se compara contra las TM contraseñas almacenadas. Si no se obtiene una coincidencia, se producen una alarma y un mensaje de precaución (flujo saliente). El camino "configurar" se dibuja de manera similar empleando correlación de transformaciones. En la figura 10.22 s e

PDF Editor muestra la arquitectura del software resultante.

P a s o 7. Refinar la arquitectura d e primera iteración e m p l e a n d o d i s e ñ o heurístico para mejorar la calidad del s o f t w a r e . Este paso para la correlación de transacciones es idéntico al de transformaciones. En a m b o s enfoques de diseño, cri-

310

PARTE D O S

Arquitectura de primera iteración para el subsistema de interacción con el usuario.


leer comandos de usuario

Invocar procesamiento de comandos

Activar/ desactivar sistema

I Controlador I procesamier I de contrasei

Construir archivo de configuración

Comparar contraseña con archivo

Controlador de salida de contraser.;

Producir mensaje de q. no es válicc

terios c o m o independencia del módulo, factibilidad (eficacia de la implementac:; - f \ la prueba) y facilidad de m a n t e n i m i e n t o deben ponderarse c u i d a d o s a m e n t e c u a r a» se p r o p o n g a n modificaciones estructurales.

"Hogalo lo más simple posible, pero no más simple de lo necesorio." Albert Einst; •

10.6.5

Refinamiento del d i s e ñ o a r q u i t e c t ó n i c o

Cualquier análisis del refinamiento del diseño debe prologarse con el siguiente : M mentario: recuerde que u n "diseño óptimo" q u e no funciona tiene un mérito cues: nable. El diseñador de s o f t w a r e d e b e p r e o c u p a r s e por desarrollar u n a represer a ción del s o f t w a r e que cumpla con todos los requisitos funcionales y de desempe-; así c o m o la aceptación del mérito b a s a d o en las medidas y la heurística del dise" x j Debe estimularse el refinamiento de la arquitectura del s o f t w a r e durante las pTM es posible os m e r a s e t a p a s del diseño. Como se analizó al principio de este capítulo, rivar, refinar y evaluar estilos arquitectónicos alternos p a r a determinar cuál es a "mejor" enfoque. Este m é t o d o p a r a afrontar la optimización es u n o de los verde j i -

PDF Editor

ros beneficios que se obtienen de desarrollar u n a representación de la a r q u i t e c t o del software.

Es importante indicar que a m e n u d o la simplicidad estructural refleja e l e g a n c i a

eficiencia. El objetivo del refinamiento del diseño d e b e ser el uso del menor núrr s a de c o m p o n e n t e s que permitan u n a integración efectiva de los m ó d u l o s y de la s |

CAPÍTULO 10


311

tructura de datos m e n o s compleja que sirva adecuadamente para los requisitos de información.

La arquitectura del software proporciona un concepto holístico del sistema que habrá de construirse. Describe la estructura y la organización de los componentes del software, sus propiedades y la conexión entre ellos. Entre los componentes del software se incluyen los módulos del programa y las diversas representaciones de datos que éste manipula. Por tanto, el diseño de datos es una parte integral de la derivación de la arquitectura del software. La arquitectura destaca las decisiones iniciales del diseño y proporciona un mecanismo para considerar los beneficios de estructuras de sistema alternas. El diseño de datos traduce los objetos de datos (definidos en el modelo de análisis) a estructuras de datos que residen dentro del software. Los atributos que describen el objeto, la relación entre los objetos de datos y su utilización dentro del programa influyen en la elección de las estructuras de datos. En un grado m á s elevado de abstracción, el diseño de datos lleva a la definición de una arquitectura para una base de datos o un almacén de datos. El ingeniero del software tiene a su disposición varios estilos y patrones arquitectónicos, Cada estilo describe una categoría del sistema que abarca 1) un conjunto de componentes que realizan una función requerida por un sistema, 2) un conjunto de conectares que permiten la comunicación, coordinación y cooperación entre componentes, 3) restricciones que definen la manera en que se integran los componentes para formar el sistema, y 4) modelos semánticos que permiten a un diseñador comprender las propiedades generales de un sistema. En sentido general, el diseño arquitectónico se realiza aplicando varios pasos. En primer lugar, el sistema debe estar representado en el contexto; es decir, el diseñador debe definir las entidades externas que interactúan con el software y la naturaleza de la interacción. Una vez que se ha especificado el contexto, el diseñador debe identificar un conjunto de abstracciones de nivel superior, llamadas arquetipos, que representan elementos centrales del comportamiento o la función del sistema; después de que se han definido las abstracciones, el diseño empieza a acercarse al dominio de la implementación. Se identifican los componentes y se representan dentro del contexto de una arquitectura que los soporta. Por último, se crean instanTM cias específicas de la arquitectura para "probar" el diseño en un contexto real. Como un simple ejemplo de diseño arquitectónico, el método de correlación o mapeo presentado en este capítulo emplea las características del flujo de datos para de-

PDF Editor

rivar un estilo arquitectónico de uso común. Un diagrama de flujo de datos se correlaciona con una estructura del programa empleando uno o dos enfoques de correlación (correlación de transformación o de transacción). Una vez que se ha derivado una arquitectura, se elabora ésta y luego se compara contra los criterios de calidad.

312

PARTE D O S


[AH083] Aho, A. V., J. Hopcrofl y J. Ullmann. Data Structures and Algorithms, Addison-Wesj; 1983. [ALL97J Alien R., "A Formal Approach lo Software Architecture", tesis de doctorado, Camegie Me University, Número de reporte técnico: CMU-CS-97-144,1997. [BAR001 Barroca. L. y P. Hall (eds.), Software Architecture- Advances and Applications, Sprir.: -. Verlag, 2000. [BAS03] Bass, L., P. C l e m e n t s y R. K a z m a n , Software Architecture in Practice, 2a. ed., Addis-: Wesley, 2003. [BOSOO] Bosch, J., Design & Use o/Software Architectures, Addison-Wesley, 2000. [BUS96] Buschmann, F., Paltern-Oriented Software Architecture, Wiley, 1996. [DAT00] Date, C. J., An Introduction lo Database Systems, 7a. ed., Addison-Wesley, 2000. [DIK00) Dikel, D., D. Kane y J. Wiison, Software Architecture: Organizational Principies and '• lems, Prentice-Hall, 2000. [FRE80] Freeman, P„ ' T h e Context of Design", en Software Design Techniques, 3a. ed. (P. Fre y A. Wasserman, eds.), IEEE Computer Society Press, 1980, pp. 2-4. [GAR94] Garlan D.. R. Alien y J. Ockerbloom, "Exploiting Style in Architectural Design I ments", en Proceedings of SIGSOFT '94 Symposium on the Foundations of Software i ring, 1994. [GAR00] Garlan D.. R. T. Monroe y D. Wile, "Acmé: Architectural Description of Componen: sed Systems", en Foundations of Component-Based Systems, G. T. Leavens y M. Sit, (eds.), Cambridge University Press, 2000. [HOFOO] Hofmeister, C., R. Nord y D. Soni, Applied Software Architecture, Addison-Wesley.; [HOFOl] Hofmann, C. et al., "Approaches to Software Architecture", se descarga de: h t t p : / / c seer.nj.nec.com/84015.html. [KAZ98] K a z m a n , R. el al., The Architectural TTadeoJf Analysis Melhod, S o f t w a r e Engir Institute, CMU/SEI-98-TR-008, julio de 1998. [KIM98] Kimball, R„ L. Reeves, M. Ross y W. T h o m t h w a i t e , The Data Warehouse Lifecycle ' kit: Expert Methods for Designing, Developing, and Deploying Data Warehouses, Wiley [LAN02] Land R., A Brief Survey of Software Architecture, reporte técnico, Departamento de l nieria de Cómputo, Universidad Málardalen, Suecia, febrero de 2002. [LUC95] Luckham D. C. et al., "Specification a n d Analysis of System Architecture Using I en IEEE TYansactions on Software Engineering, ejemplar "Special Issue o n Software , ture", 1995. [MAT96] Mattison, R., Data Warehousing: Strategies, Technologies, and Techniques, McGrav. 1996. ¡MYE78] Myers, G., Composite Slruclured Design, Van Nostrand, 1978. [PRE98] Preiss, B. R., Data Structures and Algorithms: With Object-Oriented Design Pati C++, Wiley, 1998. [SHA96J Shaw, M. y D. Garlan, Software Architecture, Prentice-Hall, 1996. [SHA97] Shaw, M. y P. C l e m e n t s . "A Field Guide to Boxoiogy: Preliminary Classificatior : 1 chitectural Styles for Software Systems", en Proc. COMPSAC, Washington, DC, agosto de : [WAS80] W a s s e r m a n . A., "Principies of Systematic Data Design a n d Implementation". e ware Design Techniques (P. F r e e m a n y A. W a s s e r m a n , eds.), 3a. ed., IEEE Computer ¡ Press, 1980, pp. 287-293. TM [YOU79] Yourdon, E. y L. Constantine, Structured Design, Prentice-Hall, 1979. [ZHA98] Zhao,)., "On Assessing the Complexity of Software Architectures", en Proc. Intl. Arclvtecture Workshop, ACM, Orlando, FL, 1998, pp. 163-167.

PDF Editor

1 0 . 1 . E m p l e a n d o la arquitectura d e u n a c a s a o un edificio c o m o m e t á f o r a , realizar cc ciones c o n la arquitectura del software. ¿En q u é s o n similares las disciplinas d e la ar clásica y la del software? ¿En q u é se diferencian?

CAPÍTULO 10


313

10.2. Escribir un artículo de tres a cinco páginas que presente directrices para seleccionar estructuras de datos basadas en la naturaleza del problema. Empezar delineando las estructuras de datos clásicas encontradas en el trabajo del software y luego describir los criterios para seleccionar, a partir de éstas, tipos particulares de problemas. 10.3. Explicar la diferencia entre una base de datos que sirve a una o más aplicaciones de negocios convencionales y un almacén de datos. 10.4. Presentar dos o tres ejemplos de aplicaciones para cada uno de los estilos arquitectónicos indicados en la sección 10.3.1. 10.5. Algunos de los estilos arquitectónico indicados en la sección 10.3.1 son de naturaleza jerárquica, otros no. Elaborar una lista de cada tipo. ¿Cómo se implementarían los estilos arquitectónicos que no son jerárquicos? 10.6. Los términos estilo arquitectónico, patrón arquitectónico y marco conceptual suelen encontrarse en el análisis sobre la arquitectura del software. Investigar un poco (utilizar la Web) y describir la diferencia entre cada uno de estos términos y sus contrapartes. 10.7. Seleccionar una aplicación con la que se esté familiarizado. Responder cada una de las preguntas planteadas para control y datos en la sección 10.3.3. 10.8. Investigar la MACA (visitar el sitio Web de SEI) y presentar un análisis detallado de los seis pasos presentados en la sección 10.5.1. 10.9. Algunos diseñadores sostienen que todos los flujos de datos deben considerarse orientados a la transformación. Analizar la manera en que esta convención afectará la arquitectura del software que se deriva cuando un flujo orientado a la transacción se trata como transformación. Utilizar un flujo de ejemplo para ilustrar puntos importantes. 10.10. Si no se ha hecho, completar el problema 8.10. Emplear los métodos de diseño descritos en este capítulo para desarrollar una arquitectura del software para el PHTRS. 10.11. Empleando un diagrama de flujo de datos y una descripción del procesamiento, describir un sistema de cómputo que tenga distintas características de flujo de transformación. Definir los límites del flujo y correlacionar el diagrama de flujo de datos con la arquitectura del software empleando la técnica descrita en la sección 10.6.3. 10.12. Empleando un diagrama de flujo de datos y una descripción del procesamiento, describir un sistema de cómputo que tenga distintas características de flujo de transacción. Defina los límites del flujo y correlacione el diagrama de flujo de datos con la arquitectura del software empleando la técnica descrita en la sección 10.6.4.

O T R A S L E C T U R A S Y F U E N T E S DE I N F O R M A C I Ó N La literatura sobre arquitectura de software ha aumentado a lo largo de la década pasada, libros de Fowler (Patterns of Enterprise Application Architecture, Addison-Wesley, 2003), Clementsy sus colegas (Documentig Software Architecture: View and Beyond, Addison-Wesley, 2002), Schmidt y sus colegas (Pattern-Oriented Software Architectures, dos volúmenes, Wiley, 2000), Bosch [B0S00], Dikel y sus colegas [DIKOO], Hofmeister y sus colegas [HOFOO]TM Bass, Clements y Kazman (BAS03], Shaw y Garlan [SHA96] y Buschmann eí al. [BUS96] proporcionan un análisis a fondo del tema. Un trabajo previo de Garlan lAn ¡ntroduction to Software Architecture, Software Engineering Institute, CMU/SEI-94-TR-021,1994) Tiene una excelente introducción. Clementsy Northrop (Software Product Lines: Practices and Pattems, Addison-Wesley, 2001) trata el diseño de arquitecturas que dan soporte a líneas de productos de sofware. Clements y sus colegas (Evaiuating Software Architectures, Addison-Wesley 2002) considera los temas asociados con la evaluación de alternativas de arquitectura y la selección de la mejor arquitectura para un problema de dominio dado.

PDF Editor

PARTE D O S


Libros específicos sobre implementación de arquitectura tratan el diseño arquitectónico detro de un ambiente de desarrollo o tecnología especiales. Wallnau y sus colegas (Building Systers from Commercial Componente, Addison-Wesley, 2001) presentan métodos para construir arc_ tecturas basadas en componentes. Pritchard (COAÍ and CORBA Side-by-Side, Addison-Wesk* 1999), Mowbray (CORBA Design Patterns, Wiley, 1997) y Mark el al. (Objetet Manageme-: Architecture Guide, Wiley, 1996) provee lineaminttos de diseño detallados para la estructura - soporte CORBA, Shanley (Protected Mode Software Architecture, Addison-Wesley 1996) proporc: na asesoria sobre diseño arquitectónico para cualquier sistema operativo basado en tiempo TÍ L. para PC, sistemas operativos multiproposito o drívers. La investigación actual sobre arquitectura de software se documenta anualmente en 1 JÍ Proceedings of the International Workshop en Software Architecture, patrocinados por la ACM r otras organizaciones de computación, y los Proceedings of the International Conference :n Software Engineering Barroca y Hall [BAR00] presentan un útil estudio de investigación recie- : El modelado de datos es un requisito para un buen diseño en esta materia. Los libros JS: Teory (Database Modeling and Design, Academic Press. 1998); Schmidt (Data Modeling -r Information Professionals, Prentice-Hall, 1998); Bobak (Data Modeling and Design for Toas s Architectures, Artech House, 1997); Silverstone, Graziano e Inmon (The Data Model Resc u • Book, Wiley, 1997); Date [DAT00), y Reingruber y Gregoiy (The Data Modeling Handbook: A Bes Practice Approach lo Building Quality Data Models, Wiley, 1994) contiene presentaciones de t a n das sobre notación de modelado de datos, heuristic y aspectos del diseño de bases de dates El diseño de almacenes de datos se ha vuelto más importante en los últimos años. Los libres je Humphreys, Hawkins y Dy (Data Warehousing: Architecture and Implementation, Prentice1999); Kimball el al. [K1M981 e lnmon (1NM95] tratan el tópico con mucho detalle. El estudio general del diseño de software con discución de aspectos de arquitectura y á s í - j ño de datos puede encontrarse en la mayoría de los libros dedicados a la ingeniería de sofr» ®re. Tratamientos más rigurosos del tema se hallan en Feijs (A Formalization of Design Metí - . Prentice-Hall, 1993) Witt etal. (Software Architecture and Design Principies, Thomson Publ 1994) y Budgen (Software Design, Addisson-Wesley, 1994). Presentaciones completas de diseño orientado al flujo de datos pueden encontrarse en [MYE78], Yourdon y Constantine [YOU79], y Page-Jones (The Practica! Cuide to Structured Design, 2a. ed. Prentice Hall, 1998). Estos libros están dedicados sólo al diseño se in extensos análisis del flujo de datos. Una amplia variedad de fuentes de información sobre el diseño arquitectónico están nibles en Internet. Una lista actualizada de referencias en la World Wide Web que son re tes para el diseño arquitectónico puede encontrarse en el sitio Web de SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P Í T U L O

D I S E Ñ O AL NIVEL DE C O M P O N E N T E S ros -329 327 318 317

11

E

l d i s e ñ o al nivel d e c o m p o n e n t e s s e p r e s e n t a d e s p u é s de q u e se ha c o m pletado la primera iteración del diseño arquitectónico. En esta etapa ya se h a n establecido los datos generales y la estructura del programa. El objetivo e s traducir el modelo de d i s e ñ o e n u n s o f t w a r e operacional. Pero el g r a d o de abstracción del modelo de diseño existente es relativamente elevado, y el del programa operacional, bajo. La traducción llega a ser desafiante, abriendo la puerta para el ingreso d e errores sutiles que resultan difíciles de encontrar y corregir e n e t a p a s posteriores del proceso de software. En una f a m o s a conferencia, Edsgar Dijkstra, una d e las p e r s o n a s q u e m á s ha contribuido a nuestra comprensión del diseño de software, afirmó [DIJ72]:

321 325

Al p a r e c e r , la d i f e r e n c i a e n t r e el s o f t w a r e y m u c h o s o t r o s p r o d u c t o s e s q u e en é s t o s , c o m o regla general, m a y o r calidad representa precio m á s elevado. Q u i e n e s d e s e a n

325

s o f t w a r e r e a l m e n t e confiable descubrirán q u e d e b e n e n c o n t r a r un m e d i o para evitar

340

g r a m a c i ó n se volverá m u c h o m á s e c o n ó m i c o . . . los b u e n o s p r o g r a m a d o r e s . . . n o d e -

322

la m a y o r p a r t e d e los e r r o r e s d e s d e e l p r i n c i p i o y, c o m o r e s u l t a d o , el p r o c e s o d e p r o b e n d e s p e r d i c i a r s u t i e m p o d e p u r a n d o : d e b e n e v i t a r l o s e r r o r e s d e s d e el p r i n c i p i o .

331

Aunque e s t a s palabras fueron p r o n u n c i a d a s h a c e m u c h o s a ñ o s , a ú n son vá-

338

lidas. Cuando el modelo de diseño se traduce en código fuente deben seguirse

-343

u n a serie de principios de diseño que n o sólo realicen la traducción, sino que "eviten la introducción de errores d e s d e el principio".

324 -340 322

Es posible representar el diseño al nivel de c o m p o n e n t e s e m p l e a n d o un lenguaje de programación. En esencia, el p r o g r a m a se crea con el modelo de diseñ o arquitectónico c o m o guía. Un e n f o q u e alterno consiste en representar el dis e ñ o al nivel de c o m p o n e n t e s e m p l e a n d o alguna representación intermedia (por ejemplo, gráfica, tabular o basada en texto) que se traduzca fácilmente en código fuente. I n d e p e n d i e n t e m e n te del m e c a n i s m o con que se represente el diseño al nivel de c o m p o n e n t e s , las estructuras de datos, las interfaces y los algoritmos definidos deben a d e c u a r s e a diversas líneas generales de diseño bien definidas, q u e ayuden a evitar errores a medida que evoluciona el diseño procedimental. En este capítulo se e x a m i n a r a n e s a s líneas generales y los m é t o d o s disponibles TM para seguirlas.

PDF Editor ¿ Q u é e s ? Un conjunto completo de componentes de software se define durante el diseño arquitectónico, pero las estructuras de datos

internas y el procesamiento de detalles de c a d a componente no se representan en un g r a d o de abstracción parecido al código El diseño al nivel de componentes define las estructuras de da-

315

316

PARTE DOS


los, los algoritmos, las características d e la interf a z y los m e c a n i s m o s d e c o m u n i c a c i ó n a s i g n a d o s a c a d a c o m p o n e n t e d e software.

m a s o f o r m a s d e texto q u e especifican estructur a s d e d a t o s internas, detalle d e la interfaz local y lógica d e p r o c e s a m i e n t o . La n o t a c i ó n d e diseñ o a b a r c a d i a g r a m a s UML y r e p r e s e n t a c i o n e ; c o m p l e m e n t a r i a s . El d i s e ñ o p r o c e d i m e n t a l se esp e c fica m e d i a n t e un c o n j u n t o d e construcciones d e programación estructurada.

¿ Q u i é n lo h a c e ? Un ingeniero de software realiza el d i s e ñ o al nivel d e c o m p o n e n t e s .

¿Por q u é e s i m p o r t a n t e ? Antes de construir el s o f t w a r e se d e b e tener b c a p a c i d a d d e determin a r si f u n c i o n a r á bien. El d i s e ñ o al nivel d e comp o n e n t e s r e p r e s e n t a el s o f t w a r e d e tal m a n e r a q u e permite revisar si los detalles del d i s e ñ o son correctos y consistentes c o n las r e p r e s e n t a c i o n e s iniciales del d i s e ñ o (es decir, ios d i s e ñ o s d e d a tos, a r q u i t e c t u r a e i n t e r f a z j P r o p o r c i o n a u n a m a n e r a d e e v a l u a r si f u n c i o n a r á n tas estructuras, las interfaces y b s a l g o r i t m o s .

¿Cuál e s el p r o d u c t o o b t e n i d o ? El diseño d; c a d a c o m p o n e n t e , r e p r e s e n t a d o en una noto ción g r á f i c a , t a b u l a r o textual, e s el principo! p r o d u c t o d e t r a b a j o c r e a d o d u r a n t e el d i s e ñ o d nivel d e c o m p o n e n t e s .

¿ C ó m o p u e d o e s t a r s e g u r o d e q u e lo he h e c h o c o r r e c t a m e n t e ? Se realiza un recc rrido o u n a inspección del diseño. Éste se e x a m n a p a r a d e t e r m i n a r si las estructuras d e d a t o : b s interfaces, b s s e c u e n c i a s y c o n d i c i o n e s lógi c a s son c o r r e c t a s y p a r a ver si a r r o j a n b s d a t e : a p r o p i a d o s o la t r a n s f o r m a c i ó n d e control asic n a d a al c o m p o n e n t e d u r a n t e b s p r i m e r a s etc p a s del d i s e ñ o .

¿ C u á l e s s o n los p a s o s ? Las representaciones al nivel d e d i s e ñ o s d e d a t o s , a r q u i t e c t u r a e interf a z r e p r e s e n t a n la b o s e del d i s e ñ o af nivel d e c o m p o n e n t e s La definición d e c l a s e o b n a r r a tiva d e p r o c e s a m i e n t o d e c a d a c o m p o n e n t e s e t r a d u c e e n un d i s e ñ o d e t a l l a d o q u e u s a d i a g r a -

11 .i

¿ftUÉ ES

Hi-

De m a n e r a general, un c o m p o n e n t e es u n bloque de construcción modular para d s o f t w a r e de cómputo. De m a n e r a m á s formal, la especificación unificada de lengua je de m o d e l a d o de OMG [OMGOl] define un c o m p o n e n t e c o m o "una parte m o d u l a : desplegable y reemplazable de un sistema que encapsula implementación y expeor un c o n j u n t o de interfaces". C o m o se analizó en el capítulo 10, los c o m p o n e n t e s pueblan la arquitectura x s o f t w a r e y, por tanto, ayudan a cumplir con los objetivos y requisitos del sistema tu construcción. Debido a que los c o m p o n e n t e s residen e n el interior de la arquitecto ra del software, d e b e n c o m u n i c a r s e y colaborar con otros c o m p o n e n t e s y con e n r d a d e s (como otros sistemas, dispositivos, personas) que existen fuera de los limita del software.

TM

l o s detofles no son sólo detcUes. Integran el diseño."

PDF Editor

Charles Eamts

El verdadero significado del término "componente" variará d e p e n d i e n d o del p je-

to de vista del ingeniero de software que lo usa. En la siguiente sección se revisaratres conceptos importantes de lo que es un c o m p o n e n t e y la m a n e r a en que se s¿ a medida que se realiza el m o d e l a d o del diseño.

CAPÍTULO 11

il. 1.1

kVE i íunto de 10

¡es un i x dases que i entre sí.


317

C o n c e p t o o r i e n t a d o a objetos

En el contexto de la ingeniería del s o f t w a r e orientada a objetos, un c o m p o n e n t e contiene un conjunto de clases que colaboran entre sí.1 Cada clase de un c o m p o n e n t e se ha elaborado completamente para incluir todos los atributos y las operaciones relevantes para su implementación. Como parte de la elaboración del diseño, también deben definirse todas las interfaces (mensajes) que permiten que las clases se comuniquen y colaboren con otras clases de diseño. Para lograrlo, el diseñador empieza con el modelo de análisis y elabora clases de análisis (en el c a s o de c o m p o n e n t e s que se relacionan con el dominio del problema) y clases de infraestructura (en el caso de c o m p o n e n t e s que proporcionan servicios de soporte para el dominio del problema). Este proceso de elaboración del diseño se ilustra imaginando que el s o f t w a r e se construirá para u n a imprenta sofisticada. El objetivo general del software e s recopilar las n e c e s i d a d e s del cliente en el mostrador, cotizar un trabajo de impresión y pasarlo a u n a planta de producción a u t o m a t i z a d a . Durante la ingeniería de los requisitos se deriva u n a clase de análisis d e n o m i n a d a Trabajolmprenta. Los atributos y las o p e r a c i o n e s definidos d u r a n t e el análisis s e observan en la parte superior izquierda de la figura 11.1. Durante el diseño arquitectónico se define Trabajolmp r e n t a c o m o un c o m p o n e n t e de la arquitectura de s o f t w a r e y se representa e m p l e a n d o la notación abreviada de UML que se muestra e n la parte central derecha de la figura. Observe q u e Trabajolmprenta tiene d o s interfaces, caícularTrabajo,

que

proporciona la capacidad de cotizar el trabajo, e iniciarTrabajo, que pasa el trabajo a la planta de producción. Éstas se representan e m p l e a n d o los símbolos q u e se muestran a la izquierda del recuadro del c o m p o n e n t e . El diseño al nivel de c o m p o n e n t e s e m p i e z a en este punto. Deben elaborarse los detalles del c o m p o n e n t e T r a b a j o l m p r e n t a para que proporcionen la información

* tjuelosmo-

r x análisis y

suficiente que guíe la implementación. La clase de análisis original se elabora para dar forma a todos los atributos y las o p e r a c i o n e s requeridos para implementar la clase c o m o el c o m p o n e n t e Trabajolmprenta. T o m a n d o c o m o referencia la parte inferior derecha de la figura 11.1, la clase d e diseño T r a b a j o l m p r e n t a elaborada con-

Micciones

tiene información de atributos m á s detallada, a d e m á s de u n a descripción expandida

. b probable ión de i x análisis ori0 pasos s adiciona1 seguidos sdemoi diseño parla clase : elaborada $ del corn-

de las o p e r a c i o n e s requeridas para implementar el c o m p o n e n t e . Las interfaces caícularTrabajo e iniciaiTrabajo

llevan implícitas la comunicación y colaboración con

otros c o m p o n e n t e s (que no se m u e s t r a n aquí). Por ejemplo, la operación calcularCostoPagina()

(parte de la interfaz caícularTrabajo) colaboraría con un c o m p o n e n t e

TM La operación T a b l a P r e c i o s que contiene la información de precios de los trabajos. verificarPrioridadf)

(parte de la interfaz iniciafTYabajo) colaboraría con el c o m p o n e n -

te ColaTrabajos para determinar los tipos y las prioridades de los trabajos en espe-

PDF Editor ra (o en cola) que se e n c u e n t r a n en producción.

Esta actividad de elaboración se aplica a cada c o m p o n e n t e definido c o m o parte

del diseño arquitectónico. Una vez completado, se elabora a ú n m á s cada atributo, 1

En algunos casos un componente podría contener una sola clase

318

PARTE D O S


operación e interfaz. Deben especificarse las estructuras de d a t o s a p r o p i a d a s p i n cada atributo. Además, t a m b i én se diseña el detalle algorítmico q u e se requiere p: ra implementar la lógica de procesamiento asociada con cada operación. Esta a: vidad de diseño procedimental se analizará m á s adelante, en este m i s m o cap:: Por último, se diseñan los mecanismos necesarios para implementar la interfaz. E" s c a s o del software orientado a objetos, esto abarca la descripción de todos los mera-i jes que se requieren para realizar la comunicación entre objetos dentro del sistema

Elaboración de un componente de diseño. Componente de diseño cokularCostodeTrabajol( J Imprímify posortrobajo( |

cakulorTrabojo

«interfaz» cokularTrobajo

Trabo jolmprento

HpoPopd pwoPopd x

*

I «interfaz» inictarTrabajo

cokxPopel ampliación requisiiosColor corocleristicasProduccion I opcionesDisIribucion opcionesEncuadernado por todaiAl macen refine pñoridod costoTotaíTraboô nomeroOT colculaiCostoPogino() |cokulofCosioPop^|) cokukjrCosloProd() calcula rCosloTra b a ¡oToiol | constru¡rOrdenTrobajo( \ revi$afPrioridad( | pasarTra b a joAPr o d u c c ¡on (

TM

11.1.2

El c o n c e p t o c o n v e n c i o n a l

PDF Editor

En el contexto de la ingeniería del s o f t w a r e convencional, un c o m p o n e n t e es un e £ m e n t ó funcional de un p r o g r a m a que incorpora la lógica del procesamiento, las r J tructuras internas de los d a t o s necesarios para implementar dicha lógica, y ur.a « terfaz que permita la invocación del c o m p o n e n t e y el p a s o de los datos. Un co~r»«l nente convencional, también d e n o m i n a d o módulo, reside d e n t r o de la a r q u i t e r - - ®

C A P Í T U L O 11

319


del s o f t w a r e y representa u n o de tres papeles importantes: I) c o m o componente

de

control que coordina la invocación de todos los d e m á s c o m p o n e n t e s del dominio del problema, 2) c o m o componente

del dominio del problema que implementa una f u n -

ción completa o parcial requerida por el cliente, o 3) c o m o componente de infraestructura responsable de funciones que soportan el procesamiento requerido e n el dominio del problema. C o m o los c o m p o n e n t e s orientados a objetos, los c o m p o n e n t e s del s o f t w a r e c o n vencional se derivan del modelo de análisis. Sin embargo, en este c a s o el e l e m e n t o de d a t o s orientado al flujo del m o d e l o de análisis sirve c o m o b a s e para la derivación. Cada transformación (burbuja) representada e n los niveles inferiores del diagrama de flujo de datos (capítulo 8) se correlaciona directamente (sección 10.6) con una jerarquía de módulos. Los c o m p o n e n t e s de control (módulos) residen cerca d e la parte superior de la jerarquía (arquitectura) y los componentes del dominio del problema tienden a residir hacia la parte inferior de la jerarquía. Para lograr u n a modularidad efectiva, se aplican conceptos de diseño c o m o la independencia funcional (capítulo 9) a medida que se elaboran los c o m p o n e n t e s . "Invariablemente se descubre que un sistemo complejo que funciona ha evolucionado a partir de un sistema simple que también funcionaba. John Goll

Este proceso de elaboración del diseño de c o m p o n e n t e s convencionales se ilustra c o n s i d e r a n d o de nuevo el s o f t w a r e que se habrá de construir para un sofisticado centro de fotocopiado. Un conjunto de d i a g r a m a s de flujo de datos se derivaría durante el m o d e l a d o del análisis. Se supondrá q u e é s t o s se correlacionan (sección

* r se elabora el f coda rrtede t el punto i desplaza al i x estructuras ! específicas y i procedlmen: -nanipular las s de datos. » , no debe tquela i que debe ríos sola i global de 9sema s componentes.

10.6) dentro de la arquitectura que se muestra en la figura 11.2. Cada recuadro representa un c o m p o n e n t e de software. T ó m e s e en cuenta que los recuadros con p a n talla gris tienen una función equivalente a las operaciones definidas en la clase Trab a j o l m p r e n t a analizada en la sección 11.1.1. Sin embargo, e n e s t e c a s o cada operación se representa c o m o un m ó d u l o s e p a r a d o que se invoca c o m o se muestra en la figura. Con o t r o s módulos se controla el p r o c e s a m i e n t o y, por tanto, son compon e n t e s de control. Durante el diseño al nivel de c o m p o n e n t e s , se elabora cada módulo m o s t r a d o en la figura 11.2. La interfaz del módulo se define de m a n e r a explícita. Es decir, se representa cada objeto de d a t o s o de control que fluye por la interfaz. TM El algoritmo q u e permite que el m ó d u l o realice su función está diseñado con el enfoque de refinamiento p a s o a p a s o analizado en el capítulo 9. El c o m p o r t a m i e n t o del módulo sue-

PDF Editor le representarse con un diagrama de estado.

Para ilustrar e s t e proceso considérese el módulo CalcularCostoPagina.

Su objetivo

e s calcular el costo de impresión por página a partir de las especificaciones del cliente. Los datos n e c e s a r i o s para realizar esta función son: número de páginas en el documento, número total de documentos que se producirán, impresión por una o ambas caras, color

320

PARTE D O S


o blanco y negro y tamaño. Estos d a t o s se p a s a n a CalcularCostoPagina

mediante la

terfaz del módulo. Éste usa los d a t o s y determina un costo por página que se ba5¿ en el t a m a ñ o y la complejidad del trabajo (una función de t o d o s los d a t o s pasados a módulo con la interfaz). El costo p o r página es inversamente proporcional al tarr¿ ño del trabajo y directamente proporcional a su complejidad.

Gráfica de estructura de un sistema convencional.

Sistema de ] administración d e trabajo

i Leer datos j de trabajo l o e impresión

Seleccionar la función I d e manejo d e trabajo T

, Desarrollar costo de trabajo

] Calcular costo de página

HCalcular costo de papel

] Calcular costo de prod.

Revisar prioridad

Pasar trabe a producc

En la figura 11.3 se representa el diseño al nivel de c o m p o n e n t e s empleand notación UML modificada. El m ó d u l o CalcularCostoPagina invocar al m ó d u l o obtenerDatosTrabajo,

tiene acceso a l o s d ¿

• -(|

que permite el p a s o de todos los datos - n e -

vantes al c o m p o n e n t e , y u n a interfaz de b a s e de datos, accesarBDCostos, que p e m f l TM te que el módulo tenga a c c e s o a u n a b a s e de datos con t o d o s los costos de :. sión. A medida que prosigue el diseño se elabora el módulo CalcularCostoPagir.. ra proporcionar el detalle del algoritmo y la interfase (figura 11.3). El detalle

PDF Editor

J

goritmo se representa e m p l e a n d o el texto de seudocódigo que se muestra en la M ra con un diagrama de actividad de UML. Las interfaces se representan c o m o u r a a lección de objetos o e l e m e n t o s de datos de e n tr a da y salida. La elaboración

s e ñ o continúa hasta que s e proporcione detalle suficiente para guiar la const> del c o m p o n e n t e .

C A P I T U L O 11

al nivel snentes


obtenerDatosTrabajo o

Calculaza.

321

Componente de diseño

accesarBDCostos Módulo elaborado CostoPagina entra: numeroPagínas entra: numeroDocumentos entra: lados= I, 2 entra: colon* I, 2, 3, 4 entra: tamañoPagina = A, B, C, D sale: costo de página entra: tamañoTrabajo entra: colora 1, 2, 3, 4 entra: tamañoPagina - A, B, C, D sale: CBP sale: SF obtenerDatosTrabajo (numeroPagínas, numeroDocumentos, lados, color, tamañoPagina, costoPagina) accesarBDCostosftamañoTrabajo, color, tamañoPagina, CBP, SF) calcularCostoPagina()

11.1.3

tamaño de trabajo (TT) » numeroPagínas = numeroDocumentos; buscar costo base de página (CBP) -> accesarBDCostos (TT, color); buscar factor d e tamaño (FT) -> accesarBDCostos (TT, color, tamaño) factor d e complejidad d e trabajo (FCT) = I + [(lados-l)*costolado + FT] costoPagina » CBP * FCT

Un c o n c e p t o r e l a c i o n a d o c o n el p r o c e s o

En los c o n c e p t o s orientado a objetos y convencional del diseño al nivel de c o m p o n e n t e s p r e s e n t a d o s e n las secciones anteriores, se s u p o n e que los c o m p o n e n t e s se h a n diseñado d e s d e cero. Es decir, que el diseñador d e b e crear un n u e v o c o m p o n e n te b a s a d o e n especificaciones derivadas del modelo de análisis. Hay, por supuesto, otro e n f o q u e . En la década pasada, la comunidad de la ingeniería del s o f t w a r e ha d e s t a c a d o la necesidad de construir sistemas que usen los c o m p o n e n t e s de s o f t w a r e existentes. En esencia, un catálogo de c o m p o n e n t e s p r o b a d o s al nivel de diseño o de código queda a disposición del ingeniero de software a medida que a v a n z aTM e n el trabajo de diseño. Mientras se desarrolla la arquitectura del software, se eligen del catálogo los c o m p o n e n t e s o patrones de diseño y se usan para poblar la arquitectura. Debido a que

PDF Editor

e s t o s c o m p o n e n t e s se han creado con la reutilización en mente, se e n c u e n t r a a disposición del diseñador una descripción completa de su interfaz, la función o las f u n ciones que realiza y la comunicación y colaboración que requiere. La ingeniería del

software b a s a d a en c o m p o n e n t e s se analizará de m a n e r a muy detallada en el capítulo 30.

322

PARTE D O S



h

Middleware e ingeniería de software basada en componentes Uno de los elementos clave que lleva al éxito o el fracaso de la ingeniería del software basada en componentes es la disponibilidad de middleware. Ésta es una colección de componentes de infraestructura que permiten que los componentes del dominio del problema se comuniquen con otros en una red o dentro de un sistema complejo. Quienes desean usar ingeniería del software basada en componentes a medida que avanza el proceso de software cuentan con tres estándares competidores:

OMG CORBA {http://www.corba.org/). Microsoft COM (http://www.microsoft.com/com/tech/complus.asp! Sun JavaBeans (http://java.sun.com/products/ejb/). Los anteriores sitios Web presentan una amplia variedcx: de tutoriales, manuales, herramientas y recursos generaesobre estos importantes estándares de middleware. En e capítulo 30 se encontrará más información acerca de la ingeniería del software b a s a d a en componentes.

Como ya se ha observado, el diseño al nivel de c o m p o n e n t e s se basa en info~ desarrollada c o m o parte del modelo de análisis (capítulo 8) y representada parte del modelo arquitectónico (capítulo 10). Cuando s e elige un método de niería de software basado en componentes,

el diseño al nivel de éstos se cont-

en la elaboración de las clases de análisis (clases específicas del dominio del | ma), y la definición y la afinación de las clases de infraestructura. La descripciór tallada de los atributos, las operaciones y las interfaces empleados por estas representa el detalle de diseño requerido c o m o precursor de la actividad de a r s - l trucción.

11.2.1

Principios b á s i c o s d e d i s e ñ o

Hay cuatro principios básicos de diseño aplicables al diseño al nivel de c o m p - : - tes y s e han adoptado ampliamente cuando se aplica ingeniería de software o r . e n a j da a objetos. La motivación elemental para la aplicación d e estos principios es diseños que sean m á s sensibles al cambio y reducir la propagación de efectos: darios cuando ocurren cambios. Estos principios pueden usarse para guiar al ñador a medida que desarrolla un componente de software. El principio a b i e r t o - c e r r a d o (PAC). "[El componente

de] un módulo debe TM abierto para extensión, pero cerrado para modificación" [MAROO]. Esta frase pareec contradicción, pero representa una de las características m á s importantes ¿ i

PDF Editor

buen diseño al nivel de componentes. Para expresarlo de manera simple, el dor debe especificar el componente de m a n e r a que permita extenderlo (dentr; dominio funcional que atiende) sin necesidad de modificaciones internas al componente (al nivel de código o lógica). Para ello, el diseñador crea abstrae que sirven c o m o memoria intermedia entre la funcionalidad que tal vez habrá oe tenderse y la propia clase de diseño.

C A P Í T U L O 11

to


«interfaz» Sensor leer() habilitar! ¡ inhabilitar! ¡ probar))

PAC

i

323

Detector

4 V

sensorPuertas/ Ventanas

SensorHumo

DeteclorMovimiento

SensorCalor

Por ejemplo, suponga que la función de seguridad HogarSeguro

SensorC02

usa la clase D e -

t e c t o r que debe revisar el estatus de cada tipo de sensor de seguridad. Es probable que con el tiempo a u m e n t e n el n ú m e r o y los tipos de s e n s o r e s de seguridad. Si la lógica de procesamiento interno está implementada c o m o u n a secuencia de construcciones s i - e n t o n c e s - s L n o (if-then-else), d o n d e cada u n a atiende un tipo de sensor diferente, la adición de un n u e v o tipo de sensor requerirá lógica de p r o c e s a m i e n t o interno adicional (un si-entonces-si_no adicional). Esto es u n a violación del PAC. Una m a n e r a de cumplir c o n el PAC e n el c a s o de la clase D e t e c t o r s e ilustra en la figura 11.4. La interfaz sensor presenta una vista consistente de s e n s o r e s para el c o m p o n e n t e D e t e c t o r . Si se agrega un nuevo tipo de s e n s o r no se requieren c a m bios en la clase D e t e c t o r (componente). Se preserva el PAC. HOGARSEGURO

El PAC en acción Lo e s c e n a : Cubículo de Vinod. s : Vinod y Shakira, integrantes del equipo ingeniería del software HogarSeguro.

conversación: V i n o d : Acabo d e recibir una llamada d e Doug (el ge- del equipo). Dice q u e marketing quiere a g r e g a r un i sensor. = k i r a ( s o n r i e n d o ) : ¡Otra vez! J : Sí... y no vas a creer con lo que han salido aho-

V i n o d : Es p a r a la gente que deja sus mascotas en departamentos o condominios o casas muy cercanas. S perro empieza a ladrar. El vecino se enoja y se queja. Con este sensor, si el perro ladra durante más d e un minuto, por decir algo, el sensor detona una a l a r m a especial que llama al teléfono celular del dueño. S h a k i r a : N o bromees.

TM

V i n o d : Es en serio. Doug quiere saber cuánto tiempo nos tomará agregarlo a la función d e seguridad.

Shakira ( p e n s a n d o por un momento): No mu-

PDF Editor

cho... mira [le muestra a Vinod la figuro 11.4]. Hemos

n k i r a : Sorpréndeme.

aislado las clases d e sensores reales tras la interfaz sen-

V i n o d ( r i e n d o ) : Lo llamaron sensor detector d e ladridos.

sor. Siempre y c u a n d o tengamos especificaciones del

S h a k i r a : ¿Qué significa?

sensor d e perros, se a g r e g a en un tris. Lo único que ten-

324

PARTE D O S


go que hacer es crear un componente apropiado... o sea, uno clase, para él. N o hay ninguna necesidad de cambiar el componente Detector. V i n o d : Entonces le puedo decir a Doug que no hay mucho problema, S h a k i r a : Conociendo a Doug, nos tendrá ocupados y no enviará lo cosa esa contra perros hasta la próxima versión.

V i n o d : No está mal, pero ¿lo podrías implementar a!-: ra mismo si él lo quisiera? S h a k i r a : Sí, la manera en que diseñamos la interfaz - i permite hacerlo sin mucho esfuerzo.

Vinod (pensando por un momento): ¿Alguna has oído hablar del "Principio Abierto-Cerrado"?

Shakira (encogiendo los hombros): Nunca Vinod ( s o n r i e n d o ) : No importa.

Principio d e s u s t i t u c i ó n d e Liskov (PSL). "Debe tenerse la opción de sustituí- i subclases con sus clases principales."

[MAROO] Este principio del diseño, que orig

m e n t e p r o p u s o Barbara Liskov [LIS88], sugiere que un c o m p o n e n t e que use una se principal debe seguir f u n c i o n a n d o a p r o p i a d a m e n t e si, en cambio, se pasa a! i p o n e n t e u n a clase derivada. El PSL exige que cualquier clase derivada de u n a • principal se a p e g u e a cualquier contrato implícito e n t r e la clase principal y los i p o n e n t e s que la usan. En el contexto de esta explicación, un "contrato" es una dición previa que debe ser verdad d e s p u é s de que el c o m p o n e n t e u s a u n a clase | cipal y u n a condición posterior que d e b e ser cierta d e s p u é s de que el componente J una clase principal. Cuando un diseñador crea clases derivadas, también deben tarse a las condiciones previas y posteriores. Principio d e i n v e r s i ó n d e la d e p e n d e n c i a (PID). "Dependa de las abstraed: --r l no de las concreciones."

[MAROO] C o m o h e m o s visto en el análisis del PAC, las a-5-1

tracciones son el lugar d o n d e un diseño se p u e d e extender sin g r a n d e s complica nes. Cuanto m á s dependa un c o m p o n e n t e de otros c o m p o n e n t e s concretos (en - J (CONSEJO^ Si se prescinde del diseño y se pasa directamente al código, sólo recuérdese que éste es la 'concreción" final. Así que se estaró violando el PID.

gar de abstractos, c o m o la interfaz), m á s difícil será extenderlos. Principio d e s e g r e g a c i ó n d e la interfaz (PSI). "Es mejor tener muchas inter:.™ específicas del cliente que una interfaz de propósito general." [MAROO] Hay mucho; lasos en que varios componentes de cliente usan las operaciones proporcionadas por clase de servidor. El PSI sugiere que el diseñador d e b e crear u n a interfaz espec A zada p a r a servir a cada categoría importante del cliente. Sólo las operaciones im: t a n t e s para u n a categoría especial de clientes deben especificarse e n la interfaz o a l ra e s o s clientes. Si varios clientes necesitan las m i s m a s operaciones, deben especificarse en cada u n a de las interfaces especializadas.

TM

Por ejemplo, piense e n la clase P l a n o C a s a que se usa en HogarSeguro para

-i

ciones de seguridad y vigilancia. En el c a s o de las funciones de seguridad, PlanoO- •

PDF Editor

s a sólo se emplea durante las actividades de configuración y utiliza las operaci: - a s colocarDispositivo(), mostrarDispositivo(), agruparDispositivo() y eliminarDisposic * • para colocar, mostrar, agrupar y eliminar sensores del plano. La función de v i g i l a - a B de HogarSeguro

usa las cuatro operaciones indicadas para seguridad, pero sóle t a l

quiere operaciones espaciales para m a n e j a r las cámaras: mostrarPVf) y mostrarle :z-\

CAPÍTULO 11

325


positivo)). Por tanto, el PSI sugiere que los c o m p o n e n t e s de cliente de las dos funcion e s de HogarSeguro tengan interfaces especializadas y definidas para ellas. La interfaz de seguridad sólo abarcaría las operaciones colocarDispositivof), agruparDispositivo()

y eliminarDispositivof).

mostrarDispositivo(),

La interfaz de vigilancia incorporaría las

cuatro operaciones anteriores, a d e m á s de mostrarPV() y mostrar¡DDispositivo(). Aunque los principios de diseño al nivel de c o m p o n e n t e s proporcionan u n a guía útil, los propios c o m p o n e n t e s n o existen e n el vacío. En m u c h o s casos, los compon e n t e s o las clases individuales se organizan en s u b s i s t e m a s o paquetes. Es razonable preguntar, ¿ c ó m o debe presentarse esta actividad de e m p a q u e t a m i e n t o ? Exactamente, ¿ c ó m o deben o r g a n i z a r s e los c o m p o n e n t e s a medida que a v a n z a el diseño? Martin (MAROO] sugiere principios adicionales de e m p a q u e t a m i e n t o que son aplicables al diseño al nivel d e c o m p o n e n t e s .

kVE i * compone reutilizo! más que i iseño técnii requiere óón efeci mecanismos i (capítulo

Principio d e e q u i v a l e n c i a e n t r e reutilización y v e r s i ó n (PER). "La esencia de la reutilización es la misma que de la versión." |MAROO] Cuando las clases o c o m p o n e n tes se diseñan para reutilizarlos, hay un contrato explícito entre el desarrollador de la entidad reutilizable y la persona que la usará. El desarrollador se c o m p r o m e t e a establecer un sistema de control de versiones que dé soporte y m a n t e n g a las version e s anteriores de la entidad mientras los usuarios actualizan lentamente la versión m á s actual. En lugar de atender cada clase individualmente, lo aconsejable sería agrup a r las clases reutilizables e n p a q u e t e s que pueden m a n e j a r s e y controlarse a medida que evolucionan n u e v a s versiones. Principio del c i e r r e c o m ú n (PCC). "Las clases que cambian juntas deben permanecer juntas." [MAROO] Las clases deben e m p a q u e t a r s e de m a n e r a que sean un todo coherente. Es decir, c u a n d o las clases se e m p a q u e t a n c o m o parte de un diseño, deben atender la misma área de funciones o comportamientos. C u a n d o alguna característica de esa área d e b e cambiar, e s probable que s ó l o d e b a n modificarse las clases del paquete. Esto lleva a un control de c a m b i o s y a un m a n e j o de las versiones m á s efectivos. Principio c o m ú n d e la r e u t i l i z a c i ó n (PCR). "Las clases que no se reutilizan juntas no deben agruparse juntas." [MAROO] Cuando u n a o m á s clases cambian en un paquete, también cambia el n ú m e r o de versión del paquete. Todas las d e m á s clases o los d e m á s p a q u e t e s q u e d e p e n d e n de ese p a q u e t e deben actualizarse ahora a la versión m á s reciente del p a q u e t e y probarse para a s e g u r a r que la nueva versión funcion a sin incidentes. Si no h u b o cohesión al agrupar las clases, es posible TM que c a m b i e u n a clase que n o tenga relación con las d e m á s . Esto requerirá un p r o c e s o i n n e c e s a rio de integración y prueba. Por ello, sólo deben incluirse e n un m i s m o p a q u e t e las clases que se reutilizarán juntas.

PDF Editor 11.2.2

Líneas g e n e r a l e s d e diseño a l nivel d e c o m p o n e n t e s

A d e m á s de los principios analizados en la sección 11.2.1, es posible aplicar un con-

junto pragmático de líneas generales de diseño a medida que a v a n z a el d i s e ñ o al ni-

326

PARTE D O S


vel de c o m p o n e n t e s . Estas líneas generales se aplican a c o m p o n e n t e s , s u s i n t e - : e e s y las características de dependencia y herencias que impactan el diseño r e s J l í ¿Qué se

T : debe t o m a r en cuento cuando se n o m b r a n los componentes?

tante. Ambler [AMB02] sugiere las siguientes líneas generales: Componentes.

Deben definirse convenciones de asignación de n o m b r e s para

c o m p o n e n t e s especificados c o m o parte del modelo arquitectónico, y luego refin;--: 1 y elaborarse c o m o parte del diseño al nivel de c o m p o n e n t e s . Los n o m b r e s del délo arquitectónico deben extraerse del dominio del p r o b l e m a y tener algún sigc a d o p a r a los participantes que ven el modelo arquitectónico. Por ejemplo, el bre de clase P l a n o C a s a tiene significado para q u i e n e s lo leen, sin importar sus t e c e d e n t e s técnicos. Por otra parte, los c o m p o n e n t e s de infraestructura o las elaboradas al nivel de c o m p o n e n t e s deben tener u n n o m b r e que refleje el sign do específico de la implementación. Si se habrá de m a n e j a r u n a lista vinculada m o parte d e la implementación de P l a n o C a s a , la operación manejarLista() apropiada, a u n q u e una persona sin conocimientos técnicos podría malinterp: También vale la p e n a usar estereotipos para ayudar a identificar la n a t u r a l e s los c o m p o n e n t e s al nivel de diseño detallado. Por ejemplo, «infraestructura» usarse para identificar u n componente de infraestructura; «basededatos» podría i se para identificar u n a b a s e de datos que sirve a u n a o m á s clases del diseño c ¿ d o el sistema; « t a b l a » se usaría para identificar u n a tabla d e n t r o de una b a s e c e tos. Interfaces.

Las interfaces proporcionan información importante acerca de i

municación y la colaboración (además de ayudar a lograr el PAC). Sin e m b a r g : representación libre de las interfaces tiende a complicar los diagramas del cc nente. Ambler [AMB02] recomienda que 1) c u a n d o los d i a g r a m a s se vuelvar complejos se use la representación de línea y círculo para u n a interfaz, en lugi* .

Cohesión de capa.

Panel de control

Detector

Teléfono

TM Modem

PDF Editor T-com

2

Es improbable que una persona de marcadotecnia o de la organización del cliente (un tipo ¡ tecedentes técnicos) examine el detalle de la información de diseño

CAPITULO 11


327

enfoque más formal del recuadro UML y la flecha con línea de guiones; 2) por razone s de consistencia, las interfaces deben fluir desde la izquierda del recuadro del componente; 3) sólo deben mostrarse las interfaces relevantes del componente en cuestión, aunque estén disponibles otras. Estas recomendaciones pretenden simplificar la naturaleza visual de los diagramas de componentes UML. D e p e n d e n c i a s y herencia.

Para mejorar la legibilidad es buena idea modelar las

dependencias de izquierda a derecha y la herencia de abajo (clases derivadas) hacia arriba (clases principales). Además, las interdependencias entre los componentes deben representarse mediante interfaces, en lugar de hacerlo mediante la representación de una dependencia de componente a componente. Siguiendo la filosofía del PAC, esto ayudará a mejorar las opciones de mantenimiento del sistema.

11.2.3

Cohesión

En el capítulo 9 se describió la cohesión como la "función única" de un componente. En el contexto del diseño al nivel de componentes para sistemas orientados a objetos, la cohesión implica que un componente o una clase sólo encapsula atributos y operaciones relacionadas estrechamente entre sí y con la clase del propio componente. Lethbridge y Laganiére [LET01] definen varios tipos diferentes de cohesión (que aparecen en la lista ordenados según su grado de cohesión): 3 Funcional. Exhibido principalmente para operaciones, este grado de cohesión se presenta cuando un módulo realiza un solo cálculo y luego devuelve un resultado. [CONSEJO.

(tsulta instruci ampiensión de s grados de .esmósimi estar consi » ' concepto is medida que i componení tcrténgase lo r cohesión posi-

D e capa. Exhibido para paquetes, componentes y clases, este tipo de cohesión ocurre cuando una capa superior tiene acceso a los servicios de una inferior, pero ésta no tiene acceso a aquélla. Piénsese, por ejemplo, en la necesidad de que la función de seguridad de HogarSeguro haga una llamada telefónica al exterior si se dispara una alarma. Sería posible definir un conjunto de paquetes en capas como se muestra en la figura 11.5. Los paquetes con pantalla gris contienen componentes de infraestructura. El acceso se tiene del paquete del panel de control hacia abajo. D e c o m u n i c a c i ó n . Todas las operaciones con acceso a los mismos datos se definen dentro de una clase. En general, esa clase sólo se concentra en los datos en cuestión, accesándolos y almacenándolos. Resulta relativamente fácil implementar, probar y mantener las clases y los componentes que muestran cohesión funcional, de capa y de comunicación. El diseñador debe luchar por alcanzar estos grados de cohesión. Sin embargo,TM hay muchos casos en que se encuentran los siguientes niveles inferiores de cohesión: Secuencial. Los componentes o las operaciones están agrupados de manera que el primero permita la entrada al siguiente, y así sucesivamente. El objetivo e s implementar una secuencia de operaciones.

PDF Editor 3

En general, mientras mayor sea el grado de cohesión, más fácil será implementar, probar y mantener el componente.

328

PARTE D O S


P r o c e d i m e n t a l . Las c o m p o n e n t e s o las o p e r a c i o n e s están a g o l p a d o s de m a n ; ra que permiten la invocación de u n o i n m e d i a t a m e n t e después de que s e invoque e anterior, a u n q u e n o se hayan p a s a d o d a t o s entre ellos. T e m p o r a l . Las operaciones que se realizan reflejan un c o m p o r t a m i e n t o o e s U : específico, c o m o una operación que se realiza al principio o t o d a s las operaciones realizadas c u a n d o se detecta u n error. Utilitaria. Se h a n a g r u p a d o c o m p o n e n t e s , clases u operaciones que existen detro de la m i s m a categoría, pero que no tienen otra relación. Por ejemplo, una clase llamada E s t a d í s t i c a muestra cohesión utilitaria si contiene t o d o s los atributos y .= operaciones necesarios para calcular seis medidas estadísticas simples. Estos grados de cohesión son m e n o s deseables y deben evitarse c u a n d o existe» o t r a s opciones de diseño. Sin embargo, es importante t o m a r en cuenta que a veres los t e m a s pragmáticos de diseño e implementación obligan al diseñador a optar por k a . g r a d o s inferiores de cohesión.

HOGARSEGURO

Cohesión en acción 'SUJL'IJBHJ!

El e s c e n a r i o : Cubículo d e jamie.

E d : He diseñado c a d a uno por s e p a r a d o , y son opere

Los p e r s o n a j e s : Jamie y Ed, integrantes del equipo d e

clones muy simples. De m o d o q u e sería buena idea c o _

ingeniería del software q u e t r a b a j a n en la función d e vi-

binar todas las operaciones d e despliegue en una soic

gilancia.

que se llamara desplegarCámaral);

La conversación: Ed: Tengo un diseño preliminar del componente de cámara. J a m i e : ¿Puedo hacerle una rápida revisión? E d : Supongo q u e s í . p e r o en realidad quisiera tu opinión sobre algo. (Jamie le hace un gesto p a r a q u e siga hablando.) Ed: Originalmente definimos cinco operaciones p a r a cámara. Mira... {muestra la lista a Jamie]. determinarTípol

I me dice el tipo d e cómara.

traduárUbicacionf

I m e permite mover la c á m a r a por

et plano d e la caso desplegarlo(j

mostraría el ID, la

visto y el zoom. ¿Qué te parece?

obtiene el ID d e la c á m a r a y lo muestra

¡unto al icono d e ésta

J a m i e ( h a c i e n d o u n a m u e c a ) : N o estoy segura c : q u e sea una buena idea. Ed ( f r u n c i e n d o e l c e ñ o ) : ¿Por qué? Todas estas pe quenas operaciones pueden causar dolores d e cabeza J a m i e : El problema d e combinarlos es que perdemos cohesión. Tú sabes, la operación desplegarCámaral

Ed ( u n p o c o e x a s p e r a d o ) : ¿Y eso qué? Todo este tendrá más d e cien líneas d e código. Creo q u e será fó; implementarlo.

TM

J a m i e : ¿Y q u é p a s a r í a si mercadotecnia decide cambiar la manera en q u e representamos el c a m p o d e vis*r

PDF Editor desplegarVstal) me muestra gráficamente el c a m p o d e vista d e la c á m a r a aesplegarZooml

I me muestra gráficamente la am-

pliación d e la c á m a r a .

I nd

tendría una sola función.

E d : Simplemente me meto en la operación desplegarC:mara() y elaboro el módulo.

J a m i e : ¿Y qué p a s a con los efectos colaterales? Ed: ¿A q u é te refieres?

C A P Í T U L O 11


329

z: Bueno, digamos que haces el cambio pero, sin

Ed: ¿De modo q u e estás en contra d e él?

cuenta, creas un problema con el despliegue del ID.

J a m i e : Tú eres el diseñador... es tu decisión... sólo asegúrate d e comprender las consecuencias d e una b a j a co-

N o sería tan descuidado. : Tal vez no, pero qué pasaría si una persona d e tiene q u e hacer el módulo dentro de dos años, tz no comprenda la operación tan bien como tú y, sabe, podría ser descuidado.

il.2.4

hesión.

Ed (pensándolo por un momento): Tal vez mos ir con diferentes operaciones d e despliegue. J a m i e : Buena decisión.

Acoplamiento

En exposiciones precedentes del análisis y el diseño se observó que la comunicación y la colaboración son elementos esenciales de cualquier sistema orientado a objetos. Sin embargo, hay un lado oscuro en esta importante (y necesaria) característica. A medida que aumenta la cantidad de comunicación y colaboración (es decir, a medida que crece el grado de "conectividad" entre las clases), también aumenta la complejidad del sistema. Y a medida que ésta aumenta, la dificulta de implementar, probar y mantener el software también lo hace. El a c o p l a m i e n t o es una medida cualitativa del grado al que las clases se conectan entre sí. A medida que las clases (y los componentes) se vuelven más interdependientes, el acoplamiento aumenta. Un objetivo importante en el diseño al nivel de componentes consiste en mantener el acoplamiento lo más bajo posible. El acoplamiento de clase se manifiesta de varias maneras. Lethbridge y Laganiére [LET01] definen las siguientes categorías de acoplamiento:

•

E

#

i que se eroh r e iseño de codo de soflatención se al diseño de m c u c s de dalos syalosdiE jücedimentales m imputar las estile datos. Sin D, no deben _ _ _ M la orquitectuI u¡óebe albergar b moonentes o los globales que pueden muchos corn-

A c o p l a m i e n t o del c o n t e n i d o . Ocurre cuando un componente "modifica subrepticiamente datos internos de otro" [LET01]. Esto viola la ocultación de la información, que es un concepto básico del diseño. A c o p l a m i e n t o c o m ú n . Ocurre cuando varios componentes usan una variable global. Aunque esto es necesario en algunas ocasiones (por ejemplo, para establecer valores predeterminados en toda una aplicación), el acoplamiento común puede llevar a la propagación incontrolable de errores y a efectos colaterales imprevisibles cuando se hacen cambios. A c o p l a m i e n t o de control. Se presenta cuando la o p e r a c i ó n A ( ) invoca la o p e r a TM c i ó n B ( ) y pasa una marca de control a 8. La marca de control "dirige" entonces el flujo lógico dentro de 8. El problema con esta forma de acoplamiento e s que un cambio no relacionado en 8 puede causar la necesidad de cambiar el significado de la marca de control que pasa A . Si esto se omite, se presentará un error.

PDF Editor

A c o p l a m i e n t o d e e s t a m p a . Ocurre cuando ClaseB se declara como tipo para

un argumento de una operación de ClaseA Debido a que ClaseB ahora e s parte de la definición de ClaseA, la modificación del sistema se vuelve más compleja.

330

PARTE DOS


A c o p l a m i e n t o d e d a t o s . Ocurre c u a n d o las o p e r a c i o n e s p a s a n c a d e n a s lar£¿.de a r g u m e n t o s de datos. El "ancho de banda" de la comunicación entre clase; « c o m p o n e n t e s crece y la complejidad de la interfaz a u m e n t a . La prueba y el m a r : ; nimiento son m á s difíciles. A c o p l a m i e n t o d e l l a m a d a a rutina. Ocurre c u a n d o u n a operación invoca a otra. Este grado de acoplamiento e s c o m ú n y, a m e n u d o , muy necesario. Sin e m e : go, a u m e n t a la conectividad de u n sistema. A c o p l a m i e n t o d e u s o d e tipo. Ocurre c u a n d o el c o m p o n e n t e A usa un tipc a: datos definido e n el c o m p o n e n t e B (por ejemplo, esto ocurre cada vez que "una cl¿í¿ declara u n a variable de instancia o u n a local c o m o si tuviera otra clase para su tire' [LET01]). Si cambia la definición del tipo, también deben cambiar todos los c o r r : n e n t e s que u s a n la definición. A c o p l a m i e n t o d e i n c l u s i ó n o i m p o r t a c i ó n . Ocurre c u a n d o el componen:-: A importa o incluye un p a q u e t e o el contenido del c o m p o n e n t e B. A c o p l a m i e n t o e x t e r n o . Ocurre c u a n d o un c o m p o n e n t e se comunica o colar-o-j ra con c o m p o n e n t e s de infraestructura (como las funciones del sistema de o p t ' r ción, la capacidad de la b a s e de datos, las funciones de comunicación). Aunque esrsl tipo de acoplamiento e s necesario, d e b e limitarse a un p e q u e ñ o n ú m e r o de c o r ó n e n t e o clases d e n t r o de u n sistema. El s o f t w a r e d e b e c o m u n i c a r s e interna y e x t e r n a m e n t e . Por tanto, el acoplamien:; * fundamental. Sin embargo, el diseñador debe trabajar para reducir el acoplam:e~ai cada vez que s e a posible y c o m p r e n d e r las ramificaciones de un acoplamiento t ev a d o c u a n d o no pueda evitarse.

Acoplamiento en acción El e s c e n a r i o : Cubículo de Shakira. Los a c t o r e s : Vinod y Shakira, integrantes del equipo de ingeniería del software HogarSeguro que trabajan en la función d e seguridad.

La conversación: S h a k i r a : Tuve lo que consideraba una estupenda idea... Luego lo pensé un poco mejor y no me pareció tan buena. Por último, lo rechacé, pero pensé que sería conveniente compartirla contigo.

S h a k i r a ( e x a s p e r a d a ) : No seas sarcóstico, Viro; Tienes que trabajar en tus habilidades interpersonale:V i n o d : ¿Qué me estabas diciendo? S h a k i r a : Bien, de todas maneras, pensaba... ¿Por que no crear una operación en cada objeto sensor denor- re da hacerUamada(} que colaboraría directamente con e: componente L l a m a d a S a l i e n t e , bueno, con una Ínter TM faz al componente L l a m a d a S a l i e n t e .

Vinod ( p e n s a t i v o ) : ¿En lugar de hacer que esa cc ; boración ocurra fuera de un componente como P a n e l C o n t r o l o algo asi?

PDF Editor V i n o d : Seguro, ¿cuál es la idea?

S h a k i r a : Bueno, cada uno d e los sensores reconoce una condición de alarma d e cada tipo, ¿verdad?

Vinod ( s o n r i e n d o ) : Por eso los llamamos sensores, Shakira. Ü ' ' •*

S h a k i r a : Claro... pero luego me dije, eso significa c.-i cada objeto sensor estará conectado al componente Uam a d a S a l i e n t e y que eso significa que está indirect;

CAPÍTULO 11

DISEÑO AL NIVEL DE C O M P O N E N T E

331

c o p i a d o al m u n d o exterior y... bueno, sólo pen-

telefónicos. N o q u e r r á s q u e el sensor a l m a c e n e e s a infor-

e complicaba un p o c o las cosas,

mación p o r q u e si c a m b i a

: Estoy d e acuerdo. En este caso, es mejor idea aue la interfaz del sensor p a s e información a P a >1 y hacer que inicie la l l a m a d a saliente. Adeciferentes sensores podrían dar diferentes números

11.3

S h a k i r a : N o p a r e c e muy a d e c u a d o . V i n o d : El diseño d e la heurística p a r a acoplamiento nos indica que no es correcto. S h a k i r a : De todos modos ..

C O N D U C C I Ó N DEL P I S E Ñ Q AL N I V E L P E C O M P O N E N T E S Al principio de este capítulo se observó que el diseño al nivel de componentes es de naturaleza elaborativa. El diseñador debe transformar la información del análisis y los modelos arquitectónicos en una representación de diseño que proporcione suficiente detalle para guiar la actividad de construcción (codificación y prueba). Los siguientes pasos representan un conjunto de tareas típicas para el diseño al nivel de componentes, c u a n d o se aplica a un sistema orientado a objetos. P a s o 1. Identificar t o d a s l a s c l a s e s d e d i s e ñ o q u e c o r r e s p o n d e n al dominio del problema. Usando los modelos de análisis y arquitectónico, cada clase de análisis y componente arquitectónico está elaborado como se describió en la sección

»

"abajando : que no ' a ob/'e¿meros tres aocentran uto de de dolos y nenio (transfordeínidos ¡delmode-

11.1.1.

P a s o 2. Identificar t o d a s l a s c l a s e s de d i s e ñ o q u e c o r r e s p o n d e n al d o m i nio d e la infraestructura. Estas clases no se describen en el modelo del análisis y a m e n u d o faltan en el modelo arquitectónico, pero deben describirse en este punto. Como ya se ha indicado, entre las clases y los componentes de esta categoría se incluyen componentes de interfaz gráfica d e usuario, del sistema operativo, de administración de objetos y datos, y otros. P a s o 3. Elaborar t o d a s las c l a s e s d e d i s e ñ o q u e n o s e adquieran c o m o c o m p o n e n t e s reutilizables. La elaboración requiere que se describan de manera detallada todas las interfases, los atributos y las operaciones necesarios para implementar la clase. Al realizar esta tarea debe tomarse en cuenta el diseño de la heurística (por ejemplo, la cohesión y el acoplamiento de componentes). P a s o 3a. Especificar l o s d e t a l l e s del m e n s a j e c u a n d o las c l aTM ses o los comp o n e n t e s colaboran. El modelo del análisis emplea el diagrama de colaboración para mostrar la manera en que las clases de análisis colaboran entre sí. A medida que avanza el diseño al nivel de componentes, a veces es útil mostrar los detalles de estas colaboraciones al especificar la estructura de m e n s a j e s que s e pasan entre los objetos de un sistema. Aunque esta actividad de diseño es opcional, puede usarse como precursora de la especificación de interfaces que muestran la manera en que se comunican y colaboran los componentes del sistema.

PDF Editor

332

PARTE D O S

Diagrama de colaboración con envío de mensajes.


TrabajoProducción 1: construirTrabajo (núrneroOT)

2: remitirTrabajo imeroOT)

En la figura 11.6 se ilustra u n diagrama simple de colaboración para el sistema dz impresión analizado antes. Tres objetos, TrabajoProduccion, OrdenTrabajo • ColaTrabajo, colaboran para preparar el envío de u n trabajo de impresión al i - o de producción. Los m e n s a j e s se p a s a n entre objetos c o m o lo ilustran las flechas s la figura. Durante el m o d e l a d o del análisis los m e n s a j e s se especifican comc st muestra en la figura. Sin embargo, a medida que avanza el diseño, cada mensa -- elabora al expandir su sintaxis de la siguiente m a n e r a [BEN02], [condición guardia] expresión de secuencia (valor devueHo): = nombre del mensaje (lisia de argumentos)

d o n d e u n a [condición guardia] está escrita en lenguaje de restricción de objeto (CC_ por sus siglas en inglés) 4 y especifica cualquier conjunto de condiciones que dehrcumplirse a n t e s de enviar el m e n s a j e ; expresión de secuencia es un valor e n t e r o (u ccn indicador de orden, c o m o 3.1.2) que indica el orden secuencial en que se envía JT m e n s a j e ; (valor devuelto) es el n o m b r e de la información que devuelve la operación n vocada por el mensaje; nombre del mensaje identifica la operación que se invoca y '•*ta de argumentos) e s la lista de los atributos que se p a s a n a la operación. P a s o 3 b . Identificar l a s i n t e r f a c e s a p r o p i a d a s para c a d a c o m p o n e n t e .

E- =

contexto del diseño al nivel de componentes, u n a interfaz UML e s un "grupo de cce raciones e x t e r n a m e n t e visibles (es decir, públicas). La interfase no contiene e s t r _ tura interna; no tiene atributos ni asociaciones..." [BEB02], Definida de manera r j s formal, u n a interfaz es el equivalente a u n a clase abstracta q u e proporciona una . nexión controlada e n t r e las clases de diseño. La elaboración de u n a interfaz se i -Sj tra en la figura 11.1. En esencia, las operaciones definidas para laTM clase de diseño están o r d e n a d a s en u n a o m á s clases abstractas. Cada operación dentro de la d¿5e abstracta (la interfaz) d e b e tener cohesión; e s decir, debe mostrar procesamie" a>

PDF Editor que se concentra en u n a función o subfunción limitada.

T o m a n d o c o m o referencia la figura 11.1, podría a r g u m e n t a r s e que la interfaz rj»

ciafTrabajo n o muestra suficiente cohesión. En realidad, realiza tres subfuncione? :

4

El OCL se analiza brevemente en la sección 11.4 y en el capítulo 28.

CAPÍTULO

11

333

D I S E Ñ O A l NIVEL DE C O M P O N E N T E S

Refactorización de definiciones de interfases y clases para ImprimiiTrabajo. calculorTrobajo . . .. - , .

iniciarlrabajo |

I ' ImprimirTroboio

«interfaz» iniciorTrobojo pQsarTraboioAProducción( J

pciónTrabajo

ferentes: construir u n a orden de trabajo, revisar la prioridad del trabajo y p a s a r un trabajo a producción. El d i s e ñ o de la interfaz d e b e refactorizar. Un e n f o q u e seria reexaminar las clases del diseño y definir una nueva clase OrdenTrabajo que s e o c u p a ría de todas las actividades asociadas con la elaboración de una orden de trabajo. La operación construirOrdenTrabajo!)

s e vuelve una parte de esa clase. De igual manera,

se podría definir una clase FilaTrabajo que incorporaría la operación revisarPrioridadl). Una clase TrabajoProduccion abarcaría toda la información asociada con un trabajo de producción que se pasará a la planta de producción. La interfaz iriciarTYabajo tomaría entonces la forma mostrada en la figura 11.7. Ahora esta interfase es cohesiva, y se concentra en una sola función. Las interfaces asociadas con TrabajoProducc i o n , OrdenTrabajo y FilaTrabajo tienen una sola función. P a s o 3 c . Elaborar atributos y definir l o s t i p o s y l a s e s t r u c t u r a s d e d a t o s n e c e s a r i o s para i m p l e m e n t a r l o s . En general, las estructuras y los tipos de d a t o s con que se describen atributos se definen dentro del contexto del lenguaje de programación que habrá de u s a r s e para la implementación. UML define el tipo de d a t o s de un atributo e m p l e a n d o la siguiente sintaxis: nombre : tipo-expresión = valor-inicial {propiedad cadena}

d o n d e nombre es n o m b r e del atributo y tipo-expresión es el tipo de datos; valor-inicial es el valor que toma el atributo c u a n d o se crea u n objeto y propiedad cadena define una propiedad o característica del atributo.

TM Durante la primera iteración de diseño al nivel de c o m p o n e n t e s , los atributos sue-

len describirse por nombre. T o m a n d o c o m o referencia u n a vez m á s la figura 11.1, la

PDF Editor

lista de atributos de T r a b a j o l m p r e n t a sólo incluye los n o m b r e s de los atributos; sin

e m b a r g o , a medida q u e a v a n z a la elaboración del diseño, cada atributo se define e m p l e a n d o el formato de atributos UML indicado. Por ejemplo, Tipo-pesoPapel se define de la siguiente manera:

Tipo-pesopapel: sfring = "A"{contiene 1 de 4 valores: A, B, C o D}

334

PARTE D O S


que define Tipo-pesopapel c o m o una variable de cadena variable inicializada con el . i lor A y que toma u n o de cuatro valores del conjunto |A,B,C,D). Si un atributo aparece varias veces en varias clases de diseño, y tiene una estru: tura relativamente compleja, es mejor crear una clase separada para a c o m o d a : s atributo. P a s o 3 - D . Describir d e m a n e r a detallada el flujo d e p r o c e s a m i e n t o dentr: d e cada o p e r a c i ó n . Esto se logra empleando un seudocódigo basa do en un \t~guaje de programación (sección 11.5.5) o el diagrama de actividad UML. Cada c c a ponente de software se elabora mediante varias interacciones que aplican el e x cepto de refinamiento p a s o a paso (capítulo 9). La primera iteración define cada operación c o m o parte de la clase de diseño, z x cada caso, la operación debe estar caracterizada de manera que asegure una coresión elevada; es decir, la operación debe realizar u n a sola función o sustitución i r finida. La siguiente iteración hace poco m á s que expandir el nombre de la o p e r a o :r Por ejemplo, la operación calcularCostoPapel() observada en la figura 11.1 se expar diría de la siguiente manera: calcularCostoPapel (peso, tamaño, color): numérico

Esto indica que calcularCostoPapel/)

requiere los atributos peso, tamaño y cok*

entrada y devuelve un valor numérico (en realidad un valor en pesos) c o m o sa-ioi

"De hober tenido m á s tiempo, hobria escrito uno cario m á s corta." Blas

(CONSEJO^ La elaboración se usa paso a paso mientras se refino el diseño del componente. Siempre debe preguntarse: "¿Hay una manera de simplificar esto mientras sigue arrojando el mismo resultado?"

Si el algoritmo requerido para implementar calcularCostoPapel()

es simple i •

comprende ampliamente, tal vez sea innecesario elaborar diseño adicional. Ei

rd

niero de software responsable de la codificación proporcionará el detalle n e c e s a B para implementar la operación. Sin embargo, si el algoritmo es m á s comple :

a

creto, se requiere mayor elaboración de diseño en esta etapa. En la figura I i • describe un diagrama de actividad UML para calcularCostoPapel().

Cuando se

plean diagramas de actividad para especificación de diseño al nivel de coi tes, suelen representarse en un nivel de abstracción un poco m á s elevado que a a digo fuente. Más adelante, en este mismo capítulo, se analizará un método el uso de seudocódigo para especificar el diseño.

TM

P a s o 4 . Describir f u e n t e s d e d a t o s p e r s i s t e n t e s ( b a s e s d e d a t o s y ;

1

e identificar las c l a s e s n e c e s a r i a s para manejarlas. Las b a s e s de datos os y o - *- a chivos suelen trascender la descripción del diseño de un componente indiv livjcka_fl

PDF Editor

casi todos los casos estos almacenes de datos persistentes suelen especifica ficanefl cialmente c o m o parte del diseño arquitectónico. Sin embargo, a medida que ai la elaboración del diseño, a veces resulta útil proporcionar detalles adicionales ai estructura y organización de estas fuentes de datos persistentes.

C A P Í T U L O 11

335


P a s o 5. Desarrollar y e l a b o r a r r e p r e s e n t a c i o n e s del c o m p o r t a m i e n t o d e una c l a s e o un c o m p o n e n t e . Los d i a g r a m a s de e s t a d o UML s e usaron c o m o parte del modelo de análisis para representar el c o m p o r t a m i e n t o del sistema que se observa e x t e r n a m e n t e y el c o m p o r t a m i e n t o m á s localizado de clases individuales de análisis. Durante el diseño al nivel de c o m p o n e n t e s , suele ser necesario modelar el c o m p o r t a m i e n t o de una clase de diseño. Al c o m p o r t a m i e n t o dinámico de un objeto (la instanciación de una clase de diseñ o mientras se ejecuta el programa) lo afectan e v e n t o s externos y el e s t a d o actual del objeto (modo o comportamiento). Para c o m p r e n d e r el c o m p o r t a m i e n t o dinámico d e un objeto, el diseñador d e b e e x a m in a r todos los c a s o s de uso relevantes durante el periodo de vida de la clase de diseño. Estos c a s o s de uso proporcionan información que ayuda al diseñador a delinear los eventos que afectan al objeto y a los e s t a d o s en que reside éste mientras pasa el tiempo y ocurren los eventos. La transi-

Diagrama de actividad UML para calcutarCostoPapeH ).

TM

PDF Editor

336

PARTE DOS


ción entre e s t a d o s (impulsados por los eventos) se representan e m p l e a n d o una g a fica de e s t a d o UML [BEN02] c o m o se ilustra e n la figura 11.9. La transición de un e s t a d o (representado por u n rectángulo con esquinas rec n deadas) a otro ocurre c o m o consecuencia de un e v e n t o que t o m a esta forma nombre-evento (lista-parametros) [condicion-guardia] / expresión de acción

d o n d e nombre-evento identifica el evento; lista-parametros incorpora datos a con el evento; condición-guardia está escrita e n lenguaje de restricción de objeto y especifica una condición que debe cumplirse a n t e s de que p u e d a ocurrir el to, y e x p r e s i ó n d e a c c i ó n define u n a acción a n t e s de que ocurra c u a n d o t i c t gar la transición. T o m a n d o c o m o referencia la figura 11.9, cada e s t a d o p u e d e definir acciones irada/ y salida/ que ocurren mientras se p r e s e n t a n las transiciones de entrada > lida. En casi t o d o s los casos, e s t a s acciones corresponden a operaciones rele\ para la clase que se está modelando. El indicador hacer/ proporciona un mecanisrra indicar las actividades que ocurren mientras se e n c u e n t r a e n el estado, y e -.mj cador incluir/ proporciona un m e d i o para elaborar el c o m p o r t a m i e n t o al i n e r v a m á s detalle en la gráfica de estado dentro de la definición de u n estado. Fragmento de diagrama de estado para la clase Trabajolmprenta.

entradaDatosIncompletos

Comportamiento dentro del estado construirDatosTraba¡o

1

construirDatosTrabajo entrar/leerDatosTiabajof) salir/desplegarDatosTraba¡o( | hacer/revisarConsistenciaf) . incluir/entradoDotos ..

entradaDatosCompletada (todos los elementos de datos T cons¡stentes)/desplegarOpc¡onesUsuario T calcula rCostoTrabajo entrar/caícularTrabaío solir/guordar costoTotafTrabajo

costoTrabajoAceptado (el cliente está autorizado) /oblenerFirmaElectronica formarTrabojo entrar/construirTrabajo salir/guardar númeroOT hacer/

TM

fechaEntregaAceptada (el cliente está autorizado)/ estimadoTrabajolmpresion

PDF Editor remitirTraba¡o

entrar/remitirTrabojo salir/iniciarTrabajo hacer/colocar en ColaTrabajo

trabajoRemitido (todas las autorizaciones adquiridas)/ imprimirOrdenTrabajo

.

CAPITULO 11

337


Es importante observar que el modelo de componentes a menudo contiene información que no resulta inmediatamente obvia en otros de componentes de diseño. Por ejemplo, el cuidadoso examen de la gráfica de estado de la figura 11.9 indica que el comportamiento dinámico de la cláusula Trabajolmprenta depende de dos aprobaciones del cliente, derivadas de los datos de costos y la calendarización del trabajo de impresión. Sin aprobaciones (la condición guardia asegura que el cliente tiene autorización para aprobar) n o se remitirá el trabajo de impresión porque no hay manera de alcanzar el estado remitiiTrabajo. P a s o 6. Elaborar diagramas de d e s p l i e g u e para proporcionar d e t a l l e s de la i m p l e m e n t a c i ó n adicional. Los diagramas de despliegue (capítulo 9) se usan com o parte del diseño arquitectónico y s e representan en forma de descriptor. Así, se representan las principales funciones del sistema (a m e n u d o representadas como subsistemas) dentro del contexto del entorno de cómputo que las albergará. Durante el diseño al nivel de componentes pueden elaborarse diagramas de despliegue para representar la ubicación de paquetes clave de componentes. Sin embargo, por lo general los componentes se representan individualmente dentro de un diagrama de componente. La razón de esto e s evitar la complejidad del diagrama. En algunos casos, los diagramas de despliegue s e elaboraron en forma de instancias. Esto significa que el hardware específico y el o los entornos del sistema operativo que se usarán son específicos y que se indica la ubicación de los paquetes de componentes dentro de este entorno. P a s o 7. Factorizar t o d a s l a s r e p r e s e n t a c i o n e s del d i s e ñ o al nivel de c o m p o n e n t e s y s i e m p r e d e b e n c o n s i d e r a r s e alternativas. A lo largo del libro se ha destacado que el diseño es un proceso iterativo. El primer modelo al nivel de componentes que se cree no será tan completo, consistente o exacto c o m o la enésima iteración que aplique al modelo. Es esencial usar la refactorización mientras se realiza el trabajo de diseño. Además, un diseñador no debe tener una visión estrecha. Siempre hay soluciones opcionales para el diseño, y los mejores diseñadores toman en cuenta todas (o casi todas) antes de definir el modelo de diseño final. Desarrollan opciones y examinan cada una de manera cuidadosa, empleando los principios del diseño y los conceptos presentados en los capítulos 5, 9 y 11.

TM La amplia variedad de diagramas disponible c o m o parte de UML proporciona a un

PDF Editor

diseñador un rico conjunto de formas de representación para el modelo de diseño. Sin embargo, las representaciones gráficas no suelen bastar. El diseñador necesita un mecanismo para representar explícita y formalmente la información que restringe algún elemento del modelo de diseño. Es posible, por supuesto, describir restriccione s en un lenguaje natural, pero este método lleva invariablemente a la inconsisten-

338

PARTE DOS


cia y la ambigüedad. Por tanto, lo apropiado p a r e c e un lenguaje m á s formal, que lam e en cuenta la teoría de c o n j u n t o s y los lenguajes formales de especificación (capítulo 28), p e r o que tenga u n a cantidad m e n o r de sintaxis matemática que un le~ guaje de programación. El lenguaje de restricción de objetos (OCL) c o m p l e m e n t a al UML al permitir que ingeniero de s o f t w a r e use gramática y sintaxis formales para construir instrucción;;

\ CLAVE El OCL proporciono gramático y sintaxis formales paro descfibir los elementos de diseño ol nivel de componentes.

sin a m b i g ü e d a d e s relacionadas con varios e l e m e n t o s del modelo de diseño (p ejemplo, clases y objetos, eventos, m e n s a j e s , interfaces). En el OCL las instrucciones se construyen en cuatro partes: 1) un contexto que define la situación limitada que es válida la instrucción; 2) u n a propiedad q u e representan a l g u n a s caracterís: cas del contexto (por ejemplo, si el contexto es u n a clase, u n a propiedad sería atributo); 3) u n a operación (aritmética, orientada a conjuntos) que manipula o cal: ca u n a p r o p i e d a d , y 4) palabras

clave ( c o m o ¡f, then, else, and, or, not, ímplíes) c o n

se especifican expresiones condicionales. C o m o ejemplo simple de una expresión OCL, considérese la condición guardia locada en el e v e n t o costoTrabajoAceptado

que c a u s a u n a transición entre los e s '

c a l c u l a r C o s t o T r a b a j o y formarTrabajo dentro del diagrama de gráfica de para la clase T r a b a j o l m p r e n t a (figura 11.9). En el diagrama, la condición gu se expresa en lenguaje natural y especifica que la autorización s ó l o se presentara el cliente está autorizado p a r a aprobar el costo del trabajo. En el OCL, la expr tomaría la forma: cliente tiene.autoridadAutorización = "si"

d o n d e un atributo booleano, autoridadAutorización, de la clase Cliente (en realidad instancia específica de la clase) d e b e tener el valor si para satisfacer la cond : guardia. Cuando se crea el modelo de diseño suele haber instancias (consulte la sec 11.2.1)

en que deben satisfacerse las condiciones previas y posteriores antes

completar alguna opción especificada en el diseño. El OCL proporciona una mienta poderosa para especificar condiciones previas y posteriores de m a n e r a mal. C o m o ejemplo, piense en u n a extensión al sistema de la imprenta (analiza;: lo largo de este capítulo) e n que el cliente proporciona un límite de costo sup para el trabajo de impresión y u n a fecha de e n t r e g a límite, al m i s m o tiempo que TM especifican otras características del trabajo. Si el costo y la entrega estimada den e s o s límites, el trabajo no se entregará y d e b e notificarse al cliente. En el

PDF Editor

un conjunto de condiciones previas y posteriores se especificaría de la siguiente ñera:

context Trabajolmprenta::validate(limiteSuperiorCosto : Integer, reqEnvioCliente : Integer)

pre: limüeSuperiorCosto > 0

C A P Í T U L O 11


339

and reqEnvioCliente > 0 and tiene.autorizacionTrabajo = " n o " p o s t : if tiene.costoTotalTrabajo < = limiteSuperiorCosto and tiene.fechaEnvio < = reqEnvioCliente then tiene.autorizacionTrabajo = "si" endif E s t a d e c l a r a c i ó n O C L d e f i n e u n a i n v a r i a n t e ( c o n d i c i o n e s q u e d e b e n e x i s t i r a n t e s [pre] y d e s p u é s [post] d e a l g ú n c o m p o r t a m i e n t o ) . Al p r i n c i p i o , ia c o n d i c i ó n p r e v i a e s t a b l e c e q u e el c l i e n t e d e b e e s p e c i f i c a r el c o s t o l í m i t e y la f e c h a d e e n t r e g a , y q u e la a u t o r i z a c i ó n d e b e e s t a r e n " n o " . D e s p u é s d e d e t e r m i n a r l o s c o s t o s y la f e c h a d e e n v í o , s e a p l i c a l a c o n d i c i ó n p o s t e r i o r . T a m b i é n d e b e t o m a r s e e n c u e n t a q u e l a e x p r e s i ó n tiene.autorízacionTrabajo = "si" n o e s t á a s i g n a n d o e l v a l o r "sí"; e n c a m b i o , e s t á d e c l a r a n d o q u e auforizacionTrabajo d e b e t e n e r e l v a l o r " s í " e n e l m o m e n t o e n q u e t e r m i n e l a o p e r a c i ó n . U n a d e s c r i p c i ó n c o m p l e t a del OCL e s t á m á s allá del a l c a n c e d e e s t e libro.5 Los l e c t o r e s i n t e r e s a d o s d e b e n c o n s u l t a r [WAR98] y [OMGOl] p a r a c o n o c e r d e t a l l e s a d i cionales.

H E R R A M I E N T A S DE SOFTWARE

UML/OCL

Herramientas representativas6

O b j e t i v o : Existe una amplia variedad d e he-

ArgoUML, distribuido por Tigress.org (http://argouml.ti-

rramientas UML p a r a a y u d a r al diseñador en

gris.org/), d a soporte a UML y OCL completo, e inclu-

las e t a p a s del diseño. Algunas d e estas herramientas

ye varias herramientas de ayuda p a r a el diseño, que

~cionan soporte al OCL.

van más allá d e la generación d e diagramas UML y expresiones OCL.

á n i c a : Las herramientas d e esta categoría permiten a r señador crear todos los d i a g r a m a s d e UML necesapara construir un modelo d e diseño completo. Lo más

Dresden OCL toolkit, desarrollado por Frank Finger en la Universidad Tecnológica d e Dresden (http://dresden-

ante es que muchas herramientas proporcionan una

ocl-sourceforge.net/), es un juego d e herramientas ba-

s y una semántica sólidas, verificación y manejo d e

s a d a en un compilador OCL q u e a b a r c a varios

d e versión y cambios (capítulo 27). Cuando se proa c a p a c i d a d d e OCL, las herramientas permiten el diseñador cree expresiones OCL y, en algunos caos "compile" p a r a varios tipos d e evaluación y : sis.

módulos q u e analizan, revisan el tipo y normalizan las restricciones OCL. OCL parser, desarrollado por IBM (http://www3.ibm.com/ software/ad/library/standars/OCL-download.html), está escrito en Java y está disponible gratuitamente para la comunidad orientada a objetos con el fin d e que

TM UML. se estimule el uso d e OCL con modeladores

PDF Editor 5

Sin embargo, e n el capítulo 29 se presentara una exposición m á s amplia del OCL (presentada en el

contexto de los m é t o d o s formales).

6

Las h e r r a m i e n t a s m e n c i o n a d a s aquí representan una m u e s t r a de esta categoría. En casi todos los

c a s o s los n o m b r e s d e las m i s m a s son m a r c a s registradas de sus respectivos desarrolladores

340

PARTE DOS PRÁCTICA DE LA INGEMERÍA DEL SOFTWARE

Los f u n d a m e n t o s del diseño al nivel de c o m p o n e n t e s para c o m p o n e n t e s c o n v e n a nales de software 7 se integraron a principios d e la d é c a d a de 1960 y adquirieron s o lidez con el trabajo de Edsgar Dijkstra y sus colegas ([BOH66], [DIJ65], [DIJ76]). A * nales de e s o s años, Dijkstra y otros propusieron el u s o de un c o n j u n t o de constru: ciones lógicas restringidas, a partir de las cuales se pudiera formar cualquier prog-3 ma. Las construcciones d e s t a c a b a n el "mantenimiento del dominio funcional" decir, c a d a construcción tenía u n a estructura lógica predecible, a la que se ingresab a en la parte superior y se a b a n d o n a b a en la inferior, lo q u e permitía al lector s< guir con mayor facilidad el flujo del procedimiento. Las construcciones s o n secuencia, condición y repetición. Secuencia implemer

\

los p a s o s de p r o c e s a m i e n t o esenciales en la especificación de cualquier a l g o n t -

CLAVE

Lo programación estiucturodo es una técnica de diseño que restringe el flujo de la lógica a tres construcciones: secuencia, condición y repetición.

Condición proporciona las funciones para el p r o c e s a m i e n t o seleccionado con basr en algún e v e n t o lógico, y repetición permite los bucles. Estas tres construcciones > f u n d a m e n t a l e s para la programación estructurada, que es u n a importante técnica diseño al nivel de c o m p o n e n t e s . Las construcciones estructuradas se propusieron para restringir el diseño p r c c ^ dimental del software a un n ú m e r o p e q u e ñ o de operaciones. La complejidad de métricas (capítulo 15) indica que el u s o de las construcciones estructuradas la complejidad del p r o g r a m a y, por tanto, mejora las opciones de lectura, pruebe mantenimiento. El u s o de u n n ú m e r o limitado de construcciones lógicas tar contribuye a un proceso de comprensión h u m a n a que los psicólogos llaman mentación.

Para c o m p r e n d e r este proceso, piénsese en la m a n e r a en que está le

d o esta página. No se leen letras individuales s i n o q u e se reconocen patrones o \ p o s de palabras o frases f o r m a d o s por varias letras. Las construcciones estruc das s o n grupos lógicos que le permiten a u n lector reconocer e l e m e n t o s pr m e n t a l e s de un módulo, e n lugar de leer el diseño o código línea por línea. La i prensión se mejora c u a n d o hay p a t r o n e s lógicos fácilmente reconocibles.

11.5.1

Notación gráfica del diseño

Ya se ha analizado el d i a g r a m a de actividad UML en este capítulo y en los capir 7 y 8. El d i a g r a m a de actividad permite a un diseñador representar secuencia, dición y repetición (todos elementos de la programación estructurada) y es el cendiente de u n a representación de diseño gráfico anterior (aún TM u s a d o ampliar te) llamado diagrama de flujo. Un diagrama de flujo, c o m o u n o de actividad, e s muy simple gráficamente

PDF Editor

d i a m a n t e representa u n a condición lógica, y las flechas m u e s t r a n el flujo de cc Un c o m p o n e n t e de s o f t w a r e convencional implementa un e l e m e n t o d e p r o c e s a m i e n t o que < una función o subfunción en el dominio del problema, o alguna capacidad en el dominio de ; i fraestructura. A m e n u d o d e n o m i n a d o s módulos, procedimientos

o subrutinas, los c o m p o n e n t e s c

vencionales n o encapsulan d a t o s de la misma m a n e r a q u e los c o m p o n e n t e s orientados a ob|r

C A P I T U L O 11

341


de Parte si n o (else)

Secuencia

P a r l e e n t o n c e s (then)

si-entonces-si_no (interfaz-then-else)

M i e n t r a s h a c e r (do while)

Selección

Repetir h a s t a ( r e p e a t until)

Repetición

En la figura 11.10 se ilustran tres construcciones estructuradas. La secuencia se representa c o m o d o s cajas de procesamiento conectadas por una línea (flecha) de control. La condición, también llamada si-entonces-si_no,

se describe c o m o un diamante

de decisión que, si es verdadero, causa que ocurra la parte-entonces del procesamiento, y si es falso, invoca la parte si_no. La repetición s e representa e m p l e a n d o dos formas ligeramente diferentes. La parte hacer mientras prueba u n a condición y ejecuta u n a tarea de bucle de m a n e r a repetitiva, siempre y c u a n d o la condición siga siendo verdadera. Una parte repetir hasta ejecuta primero la tarea de bucle, luego prueba u n a condición y repite la tarea hasta que la condición falla. La construcción de selección (o seleccionar-caso) que muestra la figura e s en realidad una extensión de si-entonces-sLno.

Sucesivas decisiones prueban un parámetro hasta q u e ocurre una

condición verdadera y se ejecuta la ruta de procesamiento de la parte de caso. En general, el uso dogmático y exclusivo de las construcciones estructuradas introduce ineficiencia c u a n d o se requiere un escape de u n conjunto de bucles anidaCOMSCJO.

dos o de condiciones anidadas. Lo que es m á s importante, la complicación adicional de todas las pruebas lógicas junto c o n la ruta de escape llega a oscurecer el flujo de control del software, a u m e n t a la posibilidad de error y tiene un impacto TM negativo en la legibilidad y la capacidad de mantenimiento. ¿Qué p o d e m o s hacer? Se le dejan dos opciones al diseñador: 1) se rediseña la representación procedi-

PDF Editor

mental para que la "rama de escape" no sea necesaria en u n a ubicación anidada del flujo de control, o 2) se violan las construcciones estructuradas de u n a m a n e r a controlada; es decir, s e diseña una rama restringida fuera del flujo anidado. La opción 1

e s obviamente el enfoque ideal, pero la 2 puede a c o m o d a r s e sin infringir el espíritu de la programación estructurada.

342

ÔNSEJOÍ^ Debe iisorse una tobla de decisión cuando un conjunto complejo de condiciones y acciones se encuentran dentro de un componente.

PARTE DOS

11.5.2


Notación tabular del diseño

En muchas aplicaciones de software tal vez se requiera un módulo para evaluar combinación compleja de condiciones y seleccionar las acciones apropiadas das en esas condiciones. Las tablas de decisión [HUR83] proporcionan una n" que traduce acciones y condiciones (descritas en una narrativa de procesamien: una forma tabular. Es difícil malinterpretar una tabla, y hasta puede usarse como trada legible para u n a máquina a un algoritmo orientado a tablas. Una tabla de decisión se divide en cuatro cuadrantes. El de la esquina superic quierda contiene una lista de todas las condiciones. El cuadrante de la esquina : izquierda contiene una lista d e todas las acciones posibles, basada en comb : ne s de condiciones. Los cuadrantes de la derecha forman una matriz que combinaciones de condición y las acciones correspondientes que ocurrirán para una binación específica. Por tanto, cada columna de la matriz puede interpretarse una regla de procesamiento. Los siguientes pasos se aplican para desarrollar u-3 bla de decisión. 1. Presentar una lista de todas las acciones que puedan asociarse con un dimiento (o módulo) específico. 2. Presentar una lista de todas las condiciones (o decisiones tomadas) du ejecución d e un procedimiento. 3 . Asociar conjuntos específicos con acciones específicas, eliminando c ciones específicas de condiciones; como opción, desarróllese cada posir s permutación de las condiciones. 4. Definir reglas al indicar cuáles acciones ocurren para un conjunto de ciones. Para ilustrar el uso de una tabla de decisión, piénsese en el siguiente extrac.: caso de uso informal que se ha propuesto para el sistema de la imprenta: Tres tipos d e clientes están definidos: un cliente regular, u n o d e plata y uno de or tipos se asignan s e g ú n la cantidad d e negocios q u e el cliente realiza con la imprerzi un periodo d e 12 meses). Un cliente regular recibe precios de impresión y fechas de ga normales. Un cliente d e plata obtiene un descuento d e 8 por ciento sobre todas : Ü tizaciones y se coloca adelante de los clientes regulares en la cola de impresión. Ur de o r o obtiene u n a reducción del 15 por ciento sobre los precios cotizados y se coloca

TM

lante de los clientes regulares y de plata en la cola de trabajo. Es posible aplicar i c u e n t o especial de x p o r c e n t a j e adicional a los otros d e s c u e n t o s a la c o t i z a : r e cualquier cliente, a discreción de la administración.

PDF Editor

En la figura 11.11 se ilustra una representación de una tabla de decisión nada con el anterior caso de uso informal. Cada una de las seis reglas indica las seis condiciones viables. Como regla general, la tabla de decisión se u ; ; ñera efectiva para complementar otras notaciones de diseño procedimenta.

C A P Í T U L O 11

343


Reglas Condiciones Cliente regular

1

2

3

4

5

6

V ( T ) V (T)

Cliente plata

V (T) V (T)

Cliente oro

V (T) V ( T )

Cliente especial

F

V (T)

F

V (T)

F

V(T)

Acciones Sin descuento

•

Aplicar 8 por ciento d e descuento Aplicar 15 por ciento d e descuento Aplicar x p o r c e n t a j e d e descuento adicional

11.5.3

Lenguaje d e diseño d e programas

El lenguaje de diseño de programas (PDL, por sus siglas en inglés), también denominado lenguaje común estructurado o seudocódigo, es "un lenguaje rudimentario porque utiliza el vocabulario de un idioma (como el inglés) y la sintaxis general de otro (es decir, un lenguaje estructurado de programación)" [CAI75], En este capítulo, PDL se usa como referencia genérica para un lenguaje de diseño. A primera vista, PDL parecería un lenguaje de programación. La diferencia entre PDL y un lenguaje de programación real radica en el uso de texto narrativo (como el inglés) incrustado directamente dentro de las instrucciones en PDL. Dado el uso de texto narrativo incrustado directamente en una estructura sintáctica, n o es posible compilar PDL. Sin embargo, algunas herramientas pueden traducirlo en un "esqueleto" de lenguaje de programación, en una representación gráfica de diseño, o en a m b a s (por ejemplo, un diagrama de flujo). Estas herramientas también producen m a p a s de anidamiento, un índice de operación de diseño, tablas de referencia cruzada y otra información diversa. Un lenguaje de diseño de programas puede ser una simple transposición de un lenguaje como Ada, C o Java. La sintaxis básica de PDL debe incluir construcciones para definición de componentes, descripción de interfaces, declaración de datos, estructuración de bloques y construcciones de condiciones, de repetición y de entra¡dea usar su de ptoyamabase pato osepue. un esque• código : con texto mientras se el diseño.

da/salida. Debe tomarse en cuenta que PDL puede extenderse para TM incluir palabras clave para multitareas, procesamiento concurrente (o a m b a s opciones), manejo de interrupciones, sincronización de interprocesos y muchas otras características. El diseño de la aplicación para la que se está usando PDL debe dictar la forma final del lenguaje de diseño. El formato y la semántica de algunas de estas construcciones de

PDF Editor

PDL se presentan en el ejemplo siguiente.Para ilustrar el uso de PDL, consideramos un diseño procedimental para la función de seguridad HogarSeguro analizada en capítulos anteriores. El sistema supervisa las alarmas para detectar fuego, humo, robo,

344

PARTE DOS


agua y temperatura (por ejemplo, rompimiento del horno cuando el propietario e s u ausente en el invierno), produce un timbre de alarma y llama a un sistema de mor tores, generando un mensaje de voz sintetizado. En el PDL siguiente ilustramos a gunas de las construcciones importantes a n o t a d a s en secciones anteriores. Recuerde que PDL no es un lenguaje de programación. El diseñador puede adar tarlo c o m o se requiera sin preocuparse por errores de sintaxis. Sin embargo, el dise ñ o del software de supervisión tendría que revisarse (¿se observa algún problema' y refinarse antes de que pueda escribirse el código. El siguiente PDL8 proporcior. una elaboración del diseño procedimental para una versión anterior de un c o m p nente de manejo de alarmas. c o m p o n e n t e manejoAlarma El objetivo d e e s t e c o m p o n e n t e e s m a n e j a r los interruptores y las e n t r a d a s del panel 3 control a partir d e los s e n s o r e s por el tipo y a c t u a r en cualquier condición d e alarma a.M sea encontrado. e s t a b l e c e r valores por d e f e c t o para e s t a t u s S i s t e m a (valor devuelto), t o d o s los elemertos de datos inicializar t o d o s los p u e r t o s del s i s t e m a y reiniciar t o d o el hardware revisar interruptoresPanelControl (¡pe) si ipc = "probar" e n t o n c e s invocar alarma fijar en " e n c e n d i d o " si ipc = "alarmaApagado" e n t o n c e s invocar alarma fijar en " a p a g a d o "

valor por d e f e c t o ipc = ninguno restablecer t o d o valoresSeñal e i n t e r r u p t o r e s hacer para t o d o s los s e n s o r e s invocar verificar-Sensor procedimiento regresa valorSeñal si valorSeñal > límite [tipoAlarma] e n t o n c e s t e l e f o n o . m e n s a j e = m e n s a j e [tipoAlarma] fijar timbreAlarma en " e n c e n d i d o " para alarmaTiempoSegundos fijar e s t a t u s s i s t e m a = "condiciónAlarma" parempieza procedimiento alarma con " e n c e n d i d o " , alarmaTiempoSegundos invocar procedimiento t e l é f o n o fijar en tipoAlarma, númeroTeléfono partermina si no omitir

TM

termina si termina h a c e r p a r a

PDF Editor termina manejoAlarma

8

El nivel de detalle que representa el PDL se define localmente. Algunas personas prefieren ur.; cripción orientada al lenguaje más natural, mientras que otras prefieren algo más parecido a digo.

C A P Í T U L O 11


345

Obsérvese que el diseñador del componente de manejo de alarma ha usado las construcciones parempieza—partermina que especifica un bloque paralelo. Todas las tareas especificadas en el bloque parempieza se ejecutan en paralelo. En este caso, no se toman en cuenta los detalles de implementación.


Lenguaje de diseño de programas O b j e t i v o : Aunque la inmensa mayoría d e los

creación de diseños con el uso de una versión definida

ingenieros d e software que usa PDL o seudocó-

de PDL.

oesarrolla una versión q u e se a d a p t a del lenguaje d e ción que tratan d e emplear p a r a la implementoexisten varias herramientas de PDL. i c a : En algunos casos, las herramientas aplican i inversa al código fuente (una triste realidad en : d o n d e algunos programas no tienen absolutalinguna documentación). Otros permiten al diseñar-sor PDL con una a y u d a automatizada.

N

DocGen, distribuido por Software Improvment G r o u p (http://www.software-improvers.com/DocGen.htm), es una herramienta d e ingeniería inversa q u e g e n e r a documentación p a r e c i d a a PDL a partir d e código A d a y C. PowerPDL, desarrollado por Iconix (http://www.iconixsw. com/SpecSheets/PowerPDL.html), le permite a un diseñador crear PDL b a s a d o en diseños y luego traducir el

¡entas rep res ent a t i v a s 9

seudocódigo a formas q u e puedan g e n e r a r otras re-

desarrollado por Caine, Farber y Gordon

presentaciones d e diseño.

p://www.cfg.com/pdl81 /Ipd.html), da soporte a la

11.5.4

Comparación entre notaciones d e diseño

La notación de diseño debe llevar a una representación procedimental fácil de comprender y revisar. Además, la notación debe mejorar la capacidad de "codificar en" para que el código, en realidad, se convierta en un subproducto natural del diseño. Por último, la representación de diseño debe tener la capacidad de darle mantenimiento fácilmente para que el diseño siempre represente el programa de manera correcta. Una pregunta natural que surge en cualquier análisis de la notación de diseño sería: ¿Cuál notación e s realmente mejor, dados los atributos indicados líneas antes? Cualquier respuesta es subjetiva y está abierta al debate. Sin embargo, parece que el lenguaje de diseño de programas ofrece la mejor combinación de características. El PDL puede incrustarse directamente en los listados de código fuente, mejorando la documentación y facilitando m á s el mantenimiento del diseño. La edición se hace en cualquier editor de texto o sistema de procesamiento de palabras, ya existen procesaTM dores automáticos, y la posibilidad de "generación automática de código" es buena. Sin embargo, de esto n o se desprende que cualquier otra notación s e a necesaria-

PDF Editor

m e n t e inferior a PDL, o que "no sea buena" e n atributos específicos. La naturaleza

9

Las h e r r a m i e n t a s expuestas aquí el autor n o las respalda: sólo representan una m u e s t r a d e las he-

rramientas incluidas en esta categoria. En casi todos los casos, los n o m b r e s de las h e r r a m i e n t a s s o n m a r c a s registradas d e sus respectivos desarrolladores

346

PARTE D O S


gráfica de los diagramas de actividad y los de flujo proporciona una perspectiva s bre el flujo de control que muchos diseñadores prefieren. El contenido tabular preso de las tablas de decisión es una herramienta excelente para aplicaciones orierv: das a tablas. Y muchas otras representaciones de diseño (por ejemplo, nidos de r : tri), n o presentados en este libro, ofrecen sus propios beneficios únicos. En el a r ; sis final, la elección de una herramienta de diseño estará relacionada de manera estrecha con factores humanos que con atributos técnicos.

La acción de diseño al nivel de componentes abarca una secuencia de tareas que ducen lentamente el grado de abstracción con que se representa el software E seño al nivel de componentes describe finalmente el software en un grado de tracción cercano al código. Es posible tomar dos enfoques distintos de diseño al nivel de componentes, i: . depende de la naturaleza del software que habrá de desarrollarse. El concepto < tado a objetos se enfoca en la elaboración de clases de diseño que provienen del problema como del dominio de la infraestructura. El concepto c o n v e n c i ó n fina tres tipos principales de componentes o módulos: de control, de domiir : problema y de infraestructura. En ambos casos se aplican principios básicos de seño y conceptos que llevan a software de mayor calidad. Cuando se considera de un punto de vista del proceso, el diseño al nivel de componentes se basa er ponentes de software reutilizables y en patrones de diseño que son elementos ; te de la ingeniería de software basada en componentes. El diseño al nivel de componentes orientado a objetos se basa en clases." principios y conceptos importantes guían al diseñador a medida que se elabora - J clases. Principios como el principio abierto-cerrado y el de inversión de la dep cia, a d e m á s de conceptos como acoplamiento y cohesión, guían al ingeniero dt : ware en la construcción de componentes de software susceptibles de probars--. plementarse y mantenerse. Para realizar diseño al nivel de componentes e~ contexto, las clases se elaboran al especificar detalles de los mensajes, identif terfaces apropiadas, elaborar atributos y definir estructuras de datos para imp tarlos, describir el flujo de procesamiento dentro de cada operación y repres TM la iteraciór comportamiento en un nivel de clase o componente. En todo caso, seño es una actividad esencial. El diseño al nivel de componentes convencional requiere la representación tructuras de datos, interfaces y algoritmos para un módulo de programa con i lie suficiente para servir como guía en la generación de código fuente en leng

PDF Editor

programación. Para lograr esto, el diseñador usa una de varias notaciones ño que representan detalles al nivel de componentes en formatos gráficos, o de texto.

C A P Í T U L O 11


347

La programación estructurada es una filosofía de diseño procedimental que restringe el número y tipo de construcciones lógicas para representar el detalle del algoritmo. El objetivo de la programación estructurada e s ayudar al diseñador a definir algoritmos que sean m e n o s complejos y, por tanto, m á s fáciles de leer, probar y mantener.

[AMB02] Ambler, S., "UML Component Diagramming Guidelines", disponible en h t t p : / / w w w . m o delingstyle.info/, 2002. [BEN02] Bennett, S., S., McRobb y R. Farmer, Object-Oriented Analysis and Design, 2a. ed., McGraw-Hill, 2002. [BOH661 Bohm, C. y G. Jacopini, "Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules", en CACM, vol. 9, n ú m . 5, m a y o de 1966, pp. 366-371. [CAI75] Caine, S. y K. Gordon, "PDL—A Tool for Software Design", en Proc. National Computer Conference, AF1PS Press, 1975, pp. 271-276. [DIJ65J Dijkstra, E„ "Programming Considered a s a Human Activity", en Proc. 1965IFIP Congress, North-Holland Publishing Co., 1965. [D1J72] Dijkstra, E„ "The Humble Programmer", 1972 ACM Turing Award Lecture, CACM, vol. 15, n ú m . 10, octubre de 1972, pp. 859-866. [DIJ76] Dijkstra, E., "Structured Programming", en Software Engineeríng, Concepts and Techniques (J. Buxton et al., e d s ), Van Nostrand-Reinhold, 1976. [HUR83] Hurley, R. B., Decisión Tables in Software Engineeríng, Van Nostrand-Reinhold, 1983. [LET01] Lethbridge, T. y R. Laganiere, Object-Oriented Software Engineeríng: Practical Software Development using UML and Java, McGraw-Hill, 2001. [LIS88] Liskov, B., "Data Abstraction and Hierarchy", en SIGPLAN Notices, vol. 23, n ú m . 5, m a y o d e 1988. [MAR00] Martin, R., "Design Principies and Design Patterns", descargado d e h t t p : / / w w w . o b j e c t mentor.com, 2000. [OMGOl] OMG Unifted Modeling Speciftcation, Object M a n a g e m e n t Group, versión 1.4, septiembre d e 2001. [WAR98] Warmer, J. y A. Klepp, Object Constrainl Language: Precise Modeling with UML, AddisonWesley, 1998,

1 1 . 1 . El t é r m i n o componente suele ser difícil d e definir. Primero proporciónese u n a definición genérica y luego definiciones m á s explícitas p a r a software orientado a objetos y convencional. Por último, elíjanse tres lenguajes d e p r o g r a m a c i ó n con los q u e se esté familiarizado e ilústrese la m a n e r a en que cada u n o define un c o m p o n e n t e . 1 1 . 2 . ¿Por qué son necesarios los c o m p o n e n t e s de control en el software convencional y n o lo son en el orientado a objetos? 11.3. Descríbase el paradigma orientado a objetos mediante argumentos propios. ¿Por qué es impor tante crear abstracciones que sirvan como interfaz entre componentes? TM 1 1 . 4 . Descríbase el DIP m e d i a n t e a r g u m e n t o s propios. ¿Qué pasaría si un d i s e ñ a d o r d e p e n d e excesivamente de las concreciones?

PDF Editor

1 1 . 5 . Selecciónense tres c o m p o n e n t e s q u e se h a y a n desarrollado r e c i e n t e m e n t e y e v a l ú e n s e los tipos de c o h e s i ó n de c a d a uno. Si se tuviera q u e definir el principal beneficio d e u n a c o h e sión elevada, ¿cuál sería? 1 1 . 6 . Selecciónense tres c o m p o n e n t e s q u e se h a y a n desarrollado r e c i e n t e m e n t e y evalúense los tipos d e a c o p l a m i e n t o de c a d a u n o . Si tuviera q u e definir el principal beneficio d e un a c o plamiento elevado, ¿cuál seria?

PARTE D O S


1 1 . 7 . ¿Es r a z o n a b l e decir que los c o m p o n e n t e s del dominio del p r o b l e m a n u n c a d e b e n trar acoplamiento externo? Si se está d e acuerdo, ¿cuáles tipos d e c o m p o n e n t e mostrarían esi tipo de acoplamiento? 11.8. Investigúese y desarróllese u n a lista d e c a t e g o r í a s típicas p a r a los c o m p o n e n t e s d ; fraestructura. 1 1 . 9 . ¿Qué es u n a condición guardia y c u á n d o se usa? 1 1 . 1 0 . ¿Cuál es el papel d e las i n t e r f a c e s en un d i s e ñ o al nivel d e c o m p o n e n t e s basad clases? 1 1 . 1 1 . Los términos atributos públicos y privados suelen usarse en trabajo d e d i s e ñ o al ni\ t a c o m p o n e n t e s . ¿Qué significa c a d a u n o y c u á l e s c o n c e p t o s d e d i s e ñ o tratan d e impc-tr" 1 1 . 1 2 . ¿Qué es u n a fuente de datos persistentes? 1 1 . 1 3 . Desarróllese 1) u n a clase d e d i s e ñ o e l a b o r a d a ; 2) descripciones de interfaz; 3) ur. g r a m a d e actividad p a r a u n a de las o p e r a c i o n e s d e n t r o d e la clase; 4) un d i a g r a m a d e g r i ta de e s t a d o d e t a l l a d o p a r a u n a d e las clases de HogarSeguro q u e s e h a n a n a l i z a d o e n cap - «• anteriores. 1 1 . 1 4 . ¿Es lo m i s m o refinamiento por p a s o s q u e factorización? Si no, ¿cuáles son s u s cias? 1 1 . 1 5 . Investigúese un poco y descríbanse tres o cuatro construcciones OCL u operadores n o se hayan analizado en la sección 11.4. 1 1 . 1 6 . Selecciónese u n a p e q u e ñ a p a r t e d e u n p r o g r a m a e x i s t e n t e (de u n a s 50 a 75 lí;

: programación i construcciones de p r o g r a m a c i ó n estructurada. De lo contrario, ¿qué nota e n los recuadr: está dibujando?

OTRAS

"

J

LECTURAS Y FUENTES DE I N F O R M A C I Ó N

Los principios d e diseño, los conceptos, las líneas generales y las técnicas p a r a clases p o n e n t e s orientados a objetos se revisan en m u c h o s libros sobre ingeniería de software _ lisis y diseño orientados a objetos. Entre las m u c h a s fuentes d e información se e n c - c - a J Bennett y s u s colegas [BEN02], Larman (Applying UML and Patlems, Prentice-Hall, 2001) _ á T ridge y Laganiere [LET01] y Nicola y s u s colegas (Streamlined Object ModeUng. Patterrand Implementation, Prentice-Hall, 2001), Schach (Object-Oriented and Classical so/twa-; - a neering, quinta edición, McGraw-Hill, 2001 ), Dennis y s u s colegas (Systems Analysis src a sign: An Object Oriented Approach with UML, Wiley, 2001), Graham [Object-Oriented fie Principies and Practice, Addison-Wesley, 2000), Richter (Designing Flexible Object-Oner -- ¡ tems with UML, Macmillan, 1999), S t e v e n s y Pooley (Using UML: Software Engineering i jects and Components, edición revisada, Addison-Wesley, 1999) y Riel (Object-Orientei: Heuristics, Addison-Wesley, 1996). El concepto de diseño por contrato es un útil paradigma de diseño. Libros d e Mitche Kim (Design by Contract by Example, Addison-Wesley, 2001) y Jezequel y s u s colegas Pattems and Contracts, Addison-Wesley, 1999) analizan e s t e t e m a en forma detallada '• TM (Design Pattems lava Workbook, Addison-Wesley, 2002) y Shalloway y Trott (Design RjGr— plained: A New Perspective on Object-Oriented Design, Addison-Wesley, 2001) toman e r el impacto d e los p a t r o n e s en el diseño de c o m p o n e n t e s de software. La iteración de d_>íri® esencial p a r a la creación de diseños de alta calidad. Fowler (Refactoring: Improving fe of Existing Code, Addison-Wesley, 1999) proporciona u n a guía útil q u e p u e d e aplicarse : « I da que evoluciona el diseño. El trabajo de ü n g e r , Milis y Witt (Stmctwed Programming—Theory and Practice ' * Wesley, 1979) sigue siendo un tratado definitivo sobre el tema. El texto contiene un a d e m á s d e explicaciones detalladas d e las ramificaciones de la programación e

i

PDF Editor

C A P I T U L O 11

349


Otros libros q u e se concentran en los t e m a s de diseño procedimental para sistemas tradicionales son los de Robertson (Simple Program Design, tercera edición, Course Technology, 2000), Farrell (A Guíele to Programming Logic and Design, Course Technology, 1999), Bentley (Programming Pearls, 2a. edición, Addison-Wesley, ¡999) y Dahl (Structured Programming, Academic Press, 1997). Relativamente, p o c o s libros recientes se h a n dedicado en exclusiva al diseño al nivel d e c o m p o n e n t e s . En general, los libros d e lenguaje d e programación atienden el diseño procedimental con algún detalle, pero siempre en el contexto del lenguaje q u e se introduce en el libro. Hay disponibles cientos de títulos. Una amplia variedad d e fuentes de información sobre d i s e ñ o al nivel de c o m p o n e n t e s se e n c u e n t r a en Internet. Una lista actualizada de referencias en World Wide Web q u e resultan relevantes para el diseño al nivel d e c o m p o n e n t e s se e n c u e n t r a en el sitio Web de SEPA:

http:/ /www.mhhe.com/pressman

TM

PDF Editor

CAPÍTULO D I S E Ñ O DE LA I N T E R F A Z

¿i

1

DE U S U A R I O

1

E

l p l a n o d e u n a c a s a (su d i s e ñ o a r q u i t e c t ó n i c o ) n o e s t a d a c o m p l e t o sin

CONCEPTOS

representación de puertas, v e n t a n a s y c o n e x i o n e s d e agua, electricidad -

CLAVE

l é f o n o (sin m e n c i o n a r la t e l e v i s i ó n p o r c a b l e ) . L a s " p u e r t a s , v e n t a n a s

accesibilidad . . ,.375 anáfisis de la tarea

n e x i o n e s " d e l s o f t w a r e d e c o m p u t a c i ó n i n t e g r a n e l d i s e ñ o d e la i n t e r f a T usuario.

..356

El d i s e ñ o d e l a i n t e r f a z s e c o n c e n t r a e n t r e s á r e a s : 1) e l d i s e ñ o d e í n t e r ;

análisis del (lujo de trabaja .364

e n t r e c o m p o n e n t e s d e s o f t w a r e ; 2) el d i s e ñ o d e i n t e r f a s e s e n t r e el softv. a

elaboración de tarea ..363

o t r o s p r o d u c t o r e s y c o n s u m i d o r e s d e i n f o r m a c i ó n q u e n o s o n h u m a n o s (ef c i r , o t r a s e n t i d a d e s e x t e m a s ) , y 3) e l d i s e ñ o d e l a i n t e r f a z e n t r e u n s e r h u r -

facilidad de uso. 35S funciones de ayuda

l e s d e c i r , el u s u a r i o ) y la c o m p u t a d o r a . E s t e c a p í t u l o s e c o n c e n t r a r á e x c h ¿ m e n t e e n l a t e r c e r a c a t e g o r í a d e diseño

..373

de la in(eifaz:

la del usuario.

En el p r ó l o g o d e s u libro clásico a c e r c a del d i s e ñ o d e i n t e r f a c e s d e u s u

¡nternacionalizac¡ón ..376

Ben S h n e í d e r m a n [SHN90] afirma:

interfaz . . . . ..354

La f r u s t r a c i ó n y a n s i e d a d s o n p a r t e d e la v i d a d i a r i a d e m u c h o s u s u a r i o s d e s i s t e r

análisis de . ..354

d e i n f o r m a c i ó n c o m p u t a r i z a d o s . L u c h a n p o r a p r e n d e r el l e n g u a j e d e c o m a n d o s o i

consistencia ..355

sistemas de selección de m e n ú s que p r e s u n t a m e n t e d e b e n ayudarles a realizar su

evaluación . . . 3 7 7

bajo. Algunas p e r s o n a s se encuentran con c a s o s tan serios de c h o q u e d e c o m p u t a : r a , t e r r o r t e r m i n a l o n e u r o s i s d e r e d , q u e e v i t a n el e m p l e o d e s i s t e m a s d e c ó m p u ' .

modelos . . . . . 3 5 6 pasos de diseño

L o s p r o b l e m a s q u e r e f i e r e S h n e í d e r m a n s o n r e a l e s . E s c i e r t o q u e l a s ¡r.: . .368

e e s gráficas d e usuario, las v e n t a n a s , los iconos y las selecciones h e c h a s ;

patrones . . . ..371

r a t ó n h a n e l i m i n a d o g r a n p a r t e d e l o s m á s t e r r i b l e s p r o b l e m a s r e l a c i o n a d :•=

reglas de oro ..351

las interfases. Pero a u n en u n " m u n d o d e ventanas", t o d o m u n d o ha e n c o r :

¿ Q u é e s ? El d i s e ñ o d e la i n t e r f a z d e

frustra sus e s f u e r z o s p o r a l c a n z a r sus obje-

u s u a r i o c r e a un m e d i o d e c o m u n i c a -

n o le g u s t a r á , sin i m p o r t a r su c a p a c i d a d -

ción efectiva entre un ser h u m a n o y

f u n c i o n e s q u e o f r e z c a . La i n t e r f a z t i e n e q . e i

u n a c o m p u t a d o r a . Siguiendo un con-

c o r r e c t a p o r q u e m o l d e a l a p e r c e p c i ó n dei

junto

de

principios

de

diseño

de

i n t e r f a c e s , el d i s e ñ a d o r i d e n t i f i c a los o b j e t o s y

rio a c e r c a d e l s o f t w a r e . ¿ C u á l e s s o n tes p a s o s ? El d i s e ñ o d e la i n t e r f a z i

las a c c i o n e s d e la interfaz y luego c r e a un for-

usuario empieza

m a t o d e p a n t a l l a q u e f o r m a ta b a s e d e u n p r o -

r e q u i s i t o s d e é s t e , la t a r e o y el a m b i e n t e

totipo d e interfaz d e usuario.

v e z i d e n t i f i c a d a s las t a r e a s del u s u a r i o , s e : -

¿ Q u i é n lo h a c e ? Un ingeniero d e software d i s e ñ a

i

con

la i d e n t i f i c a c i ó n c-: i

TM

y a n a l i z a n ios e s c e n a r i o s d e é s t e p a r a defi-

PDF Editor la i n t e r f a z d e u s u a r i o a i a p l i c a r u n p r o c e s o ite-

c o n j u n t o d e o b j e t o s y a c c i o n e s p a r a la int= - r

rativo b a s a d o e n principios d e d i s e ñ o a m p l i a -

Esto c o n s t i t u y e la b a s e p a r a la c r e a c i ó n c ~ 4

mente aceptados.

m a t o s d e p a n t a l l a q u e r e p r e s e n t a n el d i s e ñ : :

¿ P o r q u é e s i m p o r t a n t e ? Si el u s o d e l s o f t w a r e e s

difícil, si lleva al u s u a r i o a c o m e t e r e r r o r e s o si

f i c o y la u b i c a c i ó n d e l o s i c o n o s ; la d e f i n i c i á r i t e x t o d e s c r i p t i v o e n p a n t a l l a ; la e s p e c i f i c o :

CAPÍTULO 12

DISEÑO DE LA INTERFAZ DE USUARIO

a s i g n a c i ó n d e n o m b r e s a las v e n t a n a s , a d e m á s d e la e s p e c i f i c a c i ó n d e los e l e m e n t o s p r i n c i p a l e s y s e c u n d a r i o s d e los m e n ú s . S e r e c u r r e a h e r r a r entas

para

crear

prototipos

y

finalmente

p a n t a l l a . S e d e s a r r o l l o u n p r o t o t i p o d e la interf a z y se m o d i f i c a d e m a n e r a i n t e r a c t i v a .

¿ C ó m o p u e d o e s t a r s e g u r o d e q u e lo h e h e c h o

i m p l e m e n t a r el m o d e l o d e d i s e ñ o ; p o r último, s e e v a l ú a la c a l i d a d d e l r e s u l t a d o . *Cuál I

351

e s e l p r o d u c t o o b t e n i d o ? S e c r e a n los

e s c e n a r i o s d e l u s u a r i o y se g e n e r a el f o r m a t o d e

c o r r e c t a m e n t e ? El u s u a r i o r e a l i z a u n a " p r u e b a d e m a n e j o " d e l p r o t o t i p o . La i n f o r m a c i ó n q u e p r o p o r c i o n a e s t a p r u e b a se e m p l e a p a r a la s i g u i e n t e m o d i f i c a c i ó n iterativa del p r o t o t i p o .

interfases de usuario difíciles de aprender y usar, confusas, poco intuitivas, imperdonables y, en m u c h o s casos, totalmente frustrantes. Sin embargo, alguien dedicó tiempo y energía a la construcción de tales interfaces, y e s improbable que el constructor haya generado estos problemas a propósito. El diseño de la interfaz de usuario requiere el estudio de las personas y el conocimiento tecnológico adecuado. ¿Quién es el usuario? ¿Cómo aprende a interactuar con un nuevo sistema de cómputo? ¿Cómo interpreta la información que produce el sistema? ¿Qué espera del sistema? Éstas son sólo algunas de las m u c h a s preguntas que deben plantearse y responderse c o m o parte del diseño de la interfaz de usuario. 12.1

LAS

REGLAS

DE O R O

En su libro sobre el diseño de interfaces, Theo Mantel [MAN97] a c u ñ ó tres "reglas de oro" para el diseño de la interfaz: 1. Dar el control al usuario. 2.

Reducir la carga en la memoria del usuario.

3.

Lograr que la interfaz s e a consistente.

Estas reglas de oro forman la base de un conjunto de principios de diseño de interfases de usuario que servirán de guía e n esta importante acción de diseño del software.

12.1.1

Dar el control al usuario

Se le preguntó a un usuario clave, durante la sesión de acopio de requisitos para un nuevo e importante sistema de información, acerca de los atributos de la interfaz gráfica orientada a ventanas. "Lo que en verdad me gustaría", dijo el usuario solemTM nemente, "es un sistema que me lea la mente. Que sepa lo que quiero h a c e r antes de que deba hacerlo y que m e permita hacerlo fácilmente. Eso es todo, y n a d a más".

PDF Editor

Mi primera reacción fue mover la cabeza y sonreír, pero m e detuve por un mo-

mento. No había absolutamente nada de malo en la solicitud del usuario. Quería un sistema que reaccionara a sus necesidades y que le ayudara a hacer las cosas. Quería controlar la computadora; n o que ésta lo controlara.

La mayor parte de las restricciones y limitaciones que impone el diseñador a la

interfaz pretenden simplificar el m o d o de interacción. ¿Para quienes? En m u c h o s ca-

352

PARTE D O S


sos, el diseñador introduce limitaciones y restricciones para simplificar la implerr: tación de la interfaz. Así, tal vez se tenga como resultado una interfaz fácil de cc truir, pero cuyo uso resulta frustrante. Mandel [MAN97] define varios principios de diseño que permiten al usuario i tener el control: Definir l o s m o d o s d e interacción de forma q u e el usuario n o realice a n e s i n n e c e s a r i a s o i n d e s e a b l e s . Un modo de interacción es el estado actúa la interfaz. Por ejemplo, si se elige corrector ortográfico en un menú de un p dor de palabras, el software pasa a un modo corrector ortográfico. No hay nint razón para obligar al usuario a que permanezca en este modo si desea editar e! to. Debe darse al usuario la opción de entrar y salir de él sin esfuerzo. Proporcionar una interacción flexible. Debido a que diferentes usuarios distintas preferencias de interacción, deben ofrecerse las opciones correspon Por ejemplo, tal vez el software le permita al usuario interactuar mediante miento del ratón, un lápiz digitalizador o comandos seleccionados con el ti mediante reconocimiento de voz. Pero no todas las acciones son adecuadas p a n dos los mecanismos de interacción. Por ejemplo, imagine la dificultad de utiliza: m a n d o s seleccionados con el teclado (o entrada de voz) para dibujar una compleja. Incluir las o p c i o n e s de interrumpir y d e s h a c e r la interacción del Aunque se encuentre en medio de una secuencia de acciones, un usuario debe con la opción de interrumpir la secuencia para hacer otra cosa (sin perder el que haya hecho). También debe contar con la opción de "deshacer" cualquier Depurar la interacción a medida que a u m e n t a n l o s g r a d o s d e destreza permitir q u e s e p e r s o n a l i c e la interacción. Con frecuencia, los usuarios nan repitiendo la misma secuencia de interacciones. Vale la pena diseñar un nismo de "macro" que permita a un usuario personalizar la interfaz para fa interacción. Oculte al usuario o c a s i o n a l l o s e l e m e n t o s t é c n i c o s internos. La inten • b e llevar al usuario al mundo virtual de la aplicación; n o es necesario que cc el sistema operativo, las funciones de administración de archivos u otros secre la tecnología de cómputo. En esencia, la interfaz nunca debe requerir que el i TM interactúe en el nivel "interno" del equipo (por ejemplo, nunca debe pedirse usuario escriba comandos del sistema operativo desde el interior del sof

PDF Editor aplicación).

Diseñar interacción directa c o n l o s o b j e t o s que a p a r e c e n e n la pantalla usuario siente que tiene el control cuando manipula los objetos necesarios p a n 1 lizar u n a tarea de manera parecida a como lo haría con un objeto material. Por pío, una interfaz de aplicación que permita al usuario "alargar" un objeto (c su tamaño) es una implementación de manipulación directa.

CAPÍTULO 12

353


"Siempre he deseado que mi computadora sea tan fácil de monejor como mi teléfono. Mi ( Ya no sé cómo usar mi teléfono." Bjarne S t r o n s t r u p (creador d e C++)

12.1.2

Reducir la c a r g a e n la memoria del usuario

Cuantas m á s c o s a s tenga que recordar u n usuario, m á s probabilidades h a b r á de que c o m e t a errores al interactuar con el sistema. Por ello, u n a interfaz d e usuario bien diseñada no d e p e n d e r á de la memoria de éste. Siempre que sea posible, el sistema d e b e "recordar" la información pertinente y ayudar al usuario con un escenario d e interacción que le facilite el uso de la memoria. Mandel [MAN97] define los principios de diseño que logran que u n a interfaz reduzca la carga de memoria que recae en el usuario: Reducir la d e m a n d a d e m e m o r i a a c o r t o p l a z o .

C u a n d o los usuarios partici-

pan en tareas complejas, la d e m a n d a de memoria a corto p l a z o se torna importante. La interfaz se d e b e diseñar para que reduzca la necesidad de recordar acciones y resultados anteriores. Esto se logra al proporcionar pistas visuales que permitan al usuario reconocer acciones anteriores sin tener que recordarlas. Definir v a l o r e s p o r d e f e c t o q u e t e n g a n s i g n i f i c a d o .

El conjunto inicial de va-

lores por defecto d e b e tener un sentido para el usuario promedio, p e r o también c o n tar con la posibilidad de especificar s u s preferencias. Sin e m b a r g o , d e b e disponer de u n a opción "restablecer" que le permita volver a definir los valores por defecto originales. D e f i n i r a c c e s o s d i r e c t o s intuitivos. Cuando se emplea la m n e m o t é c n i c a para aplicar u n a función del sistema (por ejemplo, alt-1 para solicitar la función de imprimir), d e b e estar unida a una acción de m a n e r a tal que resulte fácil de recordar (com o la primera letra de la tarea que se solicita) El f o r m a t o visual d e la interfaz d e b e b a s a r s e e n u n a m e t á f o r a t o m a d a d e la realidad.

Por ejemplo, en un sistema de p a g o de facturas se d e b e utilizar la m e t á -

fora de la chequera y el talonario de c h e q u e s para llevar al usuario a recorrer el proc e s o del p a g o de facturas. Esto permite que el usuario d e p e n d a de pistas visuales que c o m p r e n d e bien, en lugar de m e m o r i z a r u n a misteriosa secuencia de interacciones. D e s g l o s a r la i n f o r m a c i ó n d e m a n e r a p r o g r e s i v a . La interfaz d e b e organizarTM o algún c o m se jerárquicamente. Es decir, la información sobre u n a tarea, un objeto p o r t a m i e n t o d e b e presentarse primero e n un g r a d o alto de abstracción. Después d e q u e el usuario se interese por seleccionar algo con el ratón, deben p r e s e n t a r s e m á s

PDF Editor

detalles. Un ejemplo c o m ú n e n m u c h a s aplicaciones de p r o c e s a m i e n t o de palabras es la función de subrayado. Se trata de u n a entre varias funciones ubicadas e n el m e nú estilo de texto. Sin e m b a r g o , n o a p a r e c e n t o d a s las posibilidades de subrayado. El usuario d e b e seleccionar subrayado para que se presenten a continuación todas las opciones disponibles (como subrayado sencillo, doble, de guiones, etc.).

354

PARTE D O S


HOGARSEGURO

Violación de una "regla de oro" de ¡a interfaz de usuario La e s c e n a : Cubículo d e Vinod, c u a n d o empieza el diseño de la interfaz d e usuario.

V i n o d : Eso no e s lo importante... ¿ q u é tal si lo olvido'

Los a c t o r e s : Vinod y Jamie, integrantes del equipo d e ingeniería d e software d e HogarSeguro

c á m a r a s en operación / el lugar en q u e se encuentran


una lista?

J a m i e : He estado pensando en la interfaz de la función

J a m i e : Muy bien, proporcionemos la lista, la pida o - :

d e vigilancia.

V i n o d : Eso está mejor. Por lo menos no tendrá que

V i n o d ( s o n r i e n d o ) : Pensar es bueno.

recordar cosas q u e podemos ciarle.

J a m i e : Creo q u e podemos simplificar un poco las

J a m i e ( p e n s a n d o p o r u n m o m e n t o ) : Pero o t re

cosas.

gusta el plano, ¿o no?

V i n o d : Lo que significa que..

Vinod: A j á .

J a m i e : Bueno, ¿qué posaría si eliminamos por completo el plono d e la caso? Es ostentoso, pero requiere muchos esfuerzos d e desarrollo. En lugar d e eso, pidamos al

J a m i e : O h , podemos proporcionarle una lista de las V i n o d : Eso es posible, pero ¿por q u é habría d e pedir

J a m i e : ¿Cuál crees que le gustaría c mercadotecnia? V i n o d : Estás bromeando, ¿verdad?

usuario q u e especifique la cámara que desea ver y luego despleguemos el video en una ventana d e video.

J a m i e : No.

V i n o d : ¿Cómo recordará el propietario cuántas

funciones atractivas en los productos... a ellos no les

cámaras están funcionando y d ó n d e se encuentran?

interesa cuál es más fácil d e construir.

J a m i e ( u n p o c o i r r i t a d a ) : Él es el dueño, d e b e

J a m i e ( s u s p i r a n d o ) : Muy bien, tal vez h a r é un

V i n o d : Uh... el q u e tiene el flash... les encantan lo1,

saberlo.

prototipo d e ambos.

V i n o d : ¿Pero qué pasaria si no?

V i n o d : Buena idea.. luego dejaremos q u e el diente

J a m i e : Debe saberlo.

decida.

12.1.3 Logiar q u e la interfaz s e a consistente La i n t e r f a z d e b e a d q u i r i r y p r e s e n t a r l a i n f o r m a c i ó n d e m a n e r a c o n s i s t e n t e . E s t

n

p l i c a q u e 1) t o d a l a i n f o r m a c i ó n v i s u a l e s t é o r g a n i z a d a d e a c u e r d o c o n u n e s t a - . : d e d i s e ñ o q u e s e m a n t e n g a e n t o d a s l a s p r e s e n t a c i o n e s d e p a n t a l l a ; 2) l o s m e c a . ' m o s d e e n t r a d a s e restrinjan a u n c o n j u n t o limitado q u e s e utilice d e m a n e r a cc r a t e n t e e n t o d a l a a p l i c a c i ó n , y 3 ) l o s m e c a n i s m o s p a r a ir d e u n a t a r e a a o t r a s e 1 ; 3 definido e i m p l e m e n t a d o de m a n e r a consistente. M a n d e l [MAN97] d e f i n e un c o r u to de principios de diseño q u e ayudan a construir u n a interfaz consistente:

TM "Las c o s a s q u e t i e n e n a s p e c t o s d i f e r e n t e s d e b e n a c t u a r d e m a n e r a distinta. Las q u e t i e n e n e l m i s m o a s p e c t o , d e b e actuar igual.

PDF Editor

Lorry Mari*

P e r m i t i r q u e e l u s u a r i o i n c l u y a la t a r e a a c t u a l e n u n c o n t e x t o q u e tenga ai

gún significado.

Muchas interfaces implementan capas complejas de intera:zn

n e s c o n d o c e n a s d e i m á g e n e s e n pantalla. Es i m p o r t a n t e p r o p o r c i o n a r indicaársa (por e j e m p l o , títulos d e v e n t a n a , i c o n o s gráficos, c ó d i g o s d e c o l o r c o n s i s t e n t e s a s

CAPITULO 12

355


permitan al usuario conocer el contexto del trabajo que realiza. Además, el usuario debe tener la capacidad de determinar de d ó n d e viene y cuáles son sus opciones para la transición a una nueva tarea. M a n t e n e r la c o n s i s t e n c i a e n t o d a u n a familia d e a p l i c a c i o n e s .

Un c o n j u n t o

de aplicaciones (o productos) debe implementar las mismas reglas de diseño para m a n t e n e r la consistencia en todas las interacciones. Si m o d e l o s i n t e r a c t i v o s a n t e r i o r e s h a n g e n e r a d o e x p e c t a t i v a s e n el usuario, n o h a c e r c a m b i o s a m e n o s q u e h a y a r a z o n e s i n e x c u s a b l e s . Una vez que u n a secuencia interactiva se h a convertido en un estándar de /acto (como el empleo d e alt-G para guardar u n archivo), el usuario espera esto en todas las aplicaciones q u e encuentre. Un cambio (como el uso de alt-G para solicitar la función cambiar de tamaño) crearía confusión. Los principios del diseño de interfases expuestos aquí y en secciones anteriores proporcionan u n a guía para un ingeniero de software. En la siguiente sección se examinará el proceso de diseño de la interfaz. INFORMACIÓN

Facilidad de uso En un brillante ensayo sobre la facilidad d e

La única manera de determinar si existe "facilidad d e uso" dentro d e un sistema en construcción consiste en

uso, Larry Constantine [ C O N 9 5 ] plantea una

realizar una evaluación o una prueba d e uso. Obsérvese a

que tiene una fuerte relación con el tema: "¿Al

los usuarios interactuando con el sistema y respóndanse las siguientes preguntas [CON95]:

de cuentas, qué quieren los usuarios?" Responde así: que los usuarios realmente quieren son buenas ientas. Todos los sistemas d e software, desde los operativos y los lenguajes hasta la entrada de y las aplicaciones d e a p o y o a la toma d e decisiones, solo herramientas. Los usuarios finales esperan d e las ientas q u e construimos p a r a ellos lo mismo que s esperamos d e las herramientas q u e usamos. sistemas fáciles d e a p r e n d e r y q u e les ayuden a

• ¿Es posible usar el sistema sin a y u d a ni enseñanza continua? • ¿Las reglas d e interacción ayudan a un usuario conocedor a t r a b a j a r con eficiencia? • ¿Los mecanismos d e interacción se vuelven más flexibles a medida q u e los usuarios adquieren más conocimientos?

su trabajo. Quieren software que no los detenga, ¡ o confunda, que no les lleve a cometer errores o : 'cuite la terminación del trabajo". Constantine argumenta q u e la facilidad d e uso n o se : d e mecanismos d e interacción estéticos o modernos, inteligencia integrada en la interfaz. En cambio, : c u a n d o la arquitectura d e la interfaz corresponde a -•ecesidades d e las personas q u e la usarán, . n a definición formal d e facilidad d e uso e s elusiva, ue y sus colegas [ D O N 9 9 ] la definen d e la siguiente

• ¿El sistema se ha a d e c u a d o al entorno físico y social en que h a b r á d e usarse? • ¿El usuario está al tanto del estado del sistema? ¿El usuario sabe d ó n d e se encuentra en c a d a momento? • ¿La interfaz está estructurada d e manera lógica y consistente?

TM

• ¿Los mecanismos d e interacción, iconos y procedimientos son consistentes en toda la interfaz?

PDF Editor ~: "Facilidad d e uso es una medida de la manera en

un sistema d e cómputo... facilita el aprendizaje; a quienes aprenden a recordar lo q u e han

ido; reduce la posibilidad d e errores; les permite ser tes y los deja satisfechos con el sistema".

• ¿La interacción anticipa errores y ayuda al usuario a corregirlos?

• ¿La interfaz tolera los errores q u e se cometen? • ¿La interacción es simple?

356

PARTE DOS


Si se responde afirmativamente a c a d a una d e estas

competitiva, mejores reseñas en los medios, mejores

preguntas, es probable que se haya a l c a n z a d o la facilidad

recomendaciones d e boca en b o c a , costos d e soporte

d e uso.

reducidos, mayor productividad del usuario final, menores

Entre los numerosos beneficios mensurables derivados d e un sistema con facilidad de uso se encuentran [DON99]:

costos d e capacitación y documentación, a d e m á s d e menos probabilidades d e que los usuarios insatisfechos

\ m a y o r nivel d e ventas y satisfacción del usuario, ventaja

12.2

entablen demandas.

A N Á L I S I S Y D I S E Ñ O DE L A I N T E R F A Z DE U S U A R I O El proceso general para analizar y diseñar una interfaz de usuario e m p i e z a con : creación de diferentes m o d e l o s de función del sistema (como se percibe d e s d e el e i

Referencia Web

Una excelente fuente

8f> www.useit. com.

tenor). Luego se delinean las tareas orientadas al ser h u m a n o y el equipo que se r ; quieren para lograr el f u n c i o n a m i e n t o del sistema; se t o m a n en cuenta los t e m a s diseño que se aplican a t o d o s los diseños de interfaces; se e m p l e a n herramientas p ra crear prototipos e implantar finalmente el m o d e l o de diseño, y los usuarios fir¿ • les evalúan la calidad del resultado.

12.2.1

Modelos del análisis y diseño d e la interfaz

C u a n d o se analiza y diseña u n a interfaz de usuario entran en juego cuatro modej diferentes. Un ingeniero h u m a n o (o el ingeniero del software) establece un mosdel usuario-, el ingeniero del s o f t w a r e crea un modelo del diseño-, el usuario final y. sarrolla u n a imagen mental que suele d e n o m in a r se modelo mental del usuario o ps cepción del sistema, y quienes implementan el sistema crean un modelo de la in : mentación.

Por desgracia, e s posible que estos m o d e l o s difieran significativame-.

entre sí. El papel del diseñador de la interfaz e s reconciliar e s t a s diferencias y ct-var u n a representación consistente de la interfaz. "Si hay que usar algún 'truco', la interfaz de usuario no es consistente." Douglas Anderso» ^CONSEJO^Hasta un usuario principiante quiere accesos directos; hasta los usuarios esporádicos y con conocimiento suelen necesitai una guía. Hay que darles lo que necesitan.

El m o d e l o del usuario establece el perfil de los usuarios finales del sistema. Paa construir u n a interfaz de usuario efectiva, "todo diseño debe e m p e z a r por la c:n?i prensión de q u i é n e s s o n los usuarios de destino, incluidos sus perfiles de edad < xo, habilidades físicas, educación, a n t e c e d e n t e s culturales o étnicos, m o t i v a c k r ' 3 objetivos y personalidad" [SCH90]. Además, es posible distribuir a los usuarios er _a siguientes categorías:

TM

Principiantes. No tienen conocimientos de la sintaxis' del sistema y cuentan .

PDF Editor

e s c a s o s conocimientos 2 de la s e m á n t i c a de la aplicación o del uso de la computaad ra e n general.

1 En este contexto, conocimiento de sintaxis alude a los mecanismos de interacción requeridos usar la interfaz de manera efectiva. 2 Conocimiento de semántica alude al sentido inherente de la aplicación (una comprensión de la< • dones que se realizan, el significado de entrada y salida, y las metas y los objetivos del sistc--; I

CAPÍTULO 12

357


Usuarios esporádicos y con conocimientos.

Tienen conocimientos razonables de

semántica, p e r o muestran u n a retención relativamente baja de la información sobre sintaxis necesaria para utilizar la interfaz. Usuarios frecuentes y con conocimientos.

Cuentan con conocimientos de sintaxis y

s e m á n t i c a suficientes para llegar al "síndrome del usuario a v a n z a d o " (es decir, individuos que buscan c o m b i n a c i o n e s de teclas y m é t o d o s abreviados para interactuar). Un m o d e l o del diseño de t o d o el sistema incorpora datos, arquitectura, interfaz y representaciones procedimentales del software. La especificación de requisitos establece ciertas restricciones que ayudan a definir el usuario del sistema, p e r o el diseñ o de la interfaz sólo suele ser incidental en relación con el modelo del diseño. 1 El modelo m e n t a l del usuario (percepción del sistema) es la imagen del sistema que los usuarios finales llevan en la mente. Por ejemplo, si se pidiera al usuario de un sistema d e t e r m i n a d o de diseño d e páginas q u e describiera la operación, la percepción del sistema determinaría la respuesta. La precisión de la descripción dependerá del perfil del usuario (por ejemplo, los principiantes darían c u a n d o m u c h o u n a respuesta incompleta) y de la familiaridad general con el s o f t w a r e en el dominio de la aplicación. Un usuario que c o m p r e n d a por completo el diseño de páginas, pero que haya t r a b a j a d o con el sistema una sola vez en realidad podría proporcionar una descripción m á s completa de su f u n c i o n a m i e n t o que el principiante que ha p a s a d o s e m a n a s tratando de a p r e n d e r el sistema. "[P]reste atención a lo que hocen los usuarios, no a lo que dicen." J a k o b Nielsen

El modelo de la implementación combina la manifestación externa del sistema de c ó m p u t o (la apariencia de la interfaz) y toda la información de ayuda (libros, m a n u a les, videocintas, archivos d e ayuda) que describe la sintaxis y s e m á n t i c a del sistema. C u a n d o coinciden el modelo de la implementación y el m o d e l o mental del usuario, los usuarios suelen sentirse a gusto con el s o f t w a r e y lo usan con efectividad. Para lograr esta "combinación" de los modelos, el modelo del diseño debió desarrollarse para incluir la información del modelo del usuario, y el m o d e l o de implementación d e b e reflejar con exactitud la información sintáctica y semántica d e la interfaz. Los m o d e l o s descritos en esta sección son "abstracciones d e lo que el usuario e s tá haciendo o lo q u e piensa q u e está haciendo o lo que alguien m áTM s piensa que debería estar haciendo c u a n d o u s a el sistema interactivo". [MON84]. En esencia, e s t o s modelos permiten que el diseñador de la interfaz satisfaga un e l e m e n t o clave del

PDF Editor

principio m á s importante del diseño de la interfaz de usuario: Conoce al usuario y sus tareas.

3

Así no es como deben ser las cosas. En muchos casos, el diseño de la interfaz es tan importante como el diseño arquitectónico y el nivel de componentes

358

PARTE DOS

12.2.2

PRÁCTICA DE LA INGENIERIA DEL SOFTWARE

El proceso

El proceso de análisis y diseño de las interfaces de usuario e s iterativo y s e repres: ta con un modelo espiral parecido al que se analizó en el capítulo 3. T o m a n d o referencia la figura 12.1, se observará que el p r o c e s o de análisis y diseño de la ir r faz de usuario abarca cuatro actividades distintas de m a r c o de trabajo [MAN97] 1. Análisis y m o d e l a d o de usuarios, tareas y entornos. 2 . Diseño de la interfaz. 3. Construcción (implementación) de la interfaz. 4. Validación de la interfaz. La espiral que se muestra en la figura 12.1 indica que cada una de e s t a s tareas rrirá m á s de u n a vez, y cada p a s a d a p o r la espiral representa la elaboración a d i : ¡irnal de los requisitos y el diseño resultante. En casi todos los casos, la actividac a construcción incluye la creación de prototipos (la única m a n e r a práctica de v á l e lo que se ha diseñado). El análisis de la interfaz se c o n c e n t r a en el perfil de los usuarios que i n t e r a r rán con el sistema. Se registrarán el grado de habilidad, la comprensión del y la disposición general a n t e el n u e v o sistema; y se definirán diferentes cate de usuarios. "Es mejor diseñar b experiencia del usuorio que rectificarla." Jon Una vez definidos los requisitos generales se realiza un análisis m á s detallad: fl las tareas. Se identifican, describen y elaboran las t a r e a s que el usuario realiza :

El proceso de diseño de la interfaz de usuario.

Validación de la interfaz

Análisis del usuario, la tarea y el entorno

TM

PDF Editor

CAPÍTULO 12

359


alcanzar los objetivos del sistema (sobre u n n ú m e r o de p a s a d a s iterativas por la espiral). El análisis de tareas se expone de m a n e r a m á s detallada en la sección 12.3. El análisis del entorno del usuario se concentra en el ambiente físico de trabajo. Entre las preguntas que deben responderse están las siguientes: ¿
• ¿Dónde se localizará físicamente la interfaz?

•etesito I entorno i empiece a r lo interfaz

• ¿El usuario estará sentado, de pie o realizará otras tareas sin relación con la interfaz? • ¿El h a r d w a r e d e la i n t e r f a z t i e n e r e s t r i c c i o n e s d e e s p a c i o o i l u m i n a c i ó n , o l o

o?

a f e c t a el r u i d o ?

• ¿Hay factores h u m a n o s especiales determinados por factores ambientales? La información reunida c o m o parte de la actividad de análisis se utiliza para crear un modelo del análisis para la interfaz. Tomando este modelo c o m o base, se inicia la actividad de diseño. El objetivo del diseño de la interfaz e s definir un conjunto de objetos y acciones (y sus representaciones en pantalla) que permitan que el usuario realice todas las tareas definidas, d e m a n e r a tal que cumplan todos los objetivos de facilidad de uso q u e define el sistema. El diseño de la interfaz se estudia con mayor detalle en la sección 12.4. Por lo general, la actividad de construcción empieza al crear un prototipo que permita evaluar los escenarios de uso. A medida que continúa el proceso de diseño iterativo, pueden usarse herramientas de desarrollo de la interfaz de usuario (consulte el recuadro de la sección 12.4) para completar la construcción de la interfaz. La validación se concentra en 1) la capacidad de la interfaz para implementar correctamente todas las tareas del usuario, a c o m o d a r todas las variaciones de las tareas y cumplir todos los requisitos generales del usuario; 2) la facilidad del uso y el aprendizaje d e la interfaz, y 3) la aceptación por el usuario de que la interfaz e s u n a herramienta útil para su trabajo. Como ya se ha observado, las actividades descritas e n esta sección ocurren de m a n e r a iterativa. Por tanto, es innecesario tratar de especificar cada detalle (para el modelo de análisis o de diseño) en el primer paso. Los siguientes pasos del proceso dan lugar al detalle de la tarea, la información del diseño y las características operativas de la interfaz. 12.3

DE

LA I N T E R F A Z

TM

Un principio clave de todos los modelos de procesos de ingeniería del software re-

PDF Editor za: es mejor comprender 4

el problema antes de tratar de diseñar una solución. En el ca-

Resulta razonable argumentar que esta sección debió colocarse en el capítulo 8, porque allí se estudia el análisis de requisitos. Se ha incluido aquí porque el análisis y el diseño de la interfaz están íntimamente relacionados, y porque el límite entre ambos es muy difuso.

360

PARTE D O S


so del diseño de la interfaz de usuario, c o m p r e n d e r el problema significa comp-;~ der 1) a las p e r s o n a s (los usuarios finales) que interactuarán con el sistema por r e •] dio de la interfaz; 2) las tareas que los usuarios finales deben realizar para hacetrabajo; 3) el contenido que se p r e s e n t a c o m o parte de la interfaz, y 4) el entorne que se realizarán e s t a s tareas. En las secciones siguientes se e x a m i n a r á cada un

.

estos e l e m e n t o s del análisis de la interfaz con el fin de establecer u n a b a s e para el diseño de las tareas que siguen.

12.3.1

Análisis del usuario

Ya se h a indicado que c a d a usuario tiene u n a imagen mental del software (o ] cíón del sistema) que podría ser diferente de la imagen mental de otros. Adema; probable que la imagen mental del usuario sea muy diferente del modelo del > que tiene el ingeniero. El diseñador sólo lograría que coincidan la imagen m e r -_a. el m o d e l o del diseño si trabaja para c o m p r e n d e r a los propios usuarios, ademad¿ C ó m o s é lo • q u e los usuarios quieren d e la i n t e r f a z ?

la m a n e r a en que ellos u s a r á n el sistema. Es posible u s a r información de una ; variedad de f u e n t e s disponible para lograr esto: E n t r e v i s t a s c o n e l u s u a r i o . Es el e n f o q u e m á s directo. Representantes de: ¡ po de software se entrevistan con usuarios finales para c o m p r e n d e r mejor sus i sidades, motivaciones, cultura de trabajo y gran cantidad de t e m a s adicionales to se logra mediante reuniones p e r s o n a les o con g r u p o s de enfoque.

^CONSEJO^ Sobretodo, dediqúese tiempo a hablar con las usuarios redes, pero debe hoceise con cuidoda. Una ophón fuerte no necesariamente signUka que la mayorío de ¡os usuorios esté de ocuerdo.

I n f o r m a c i ó n d e v e n t a s . El personal de ventas se r e ú n e con clientes y i de m a n e r a regular y obtiene información que ayudará al equipo de software a ficar a los usuarios en categorías y a c o m p r e n d e r mejor sus necesidades. I n f o r m a c i ó n d e m e r c a d o t e c n i a . El análisis de mercado es invaluable en la nición de los segmentos del mercado, al tiempo que proporciona u n a comprer la m a n e r a en que cada segmento usaría el software de manera sutilmente dife I n f o r m a c i ó n p r o v e n i e n t e d e s o p o r t e . El personal de soporte habla a con los clientes. Esto los convierte e n la f u e n t e de información m á s probable lo que funciona y lo que no, lo que le gusta a los usuarios y lo que les disgusta características que g e n e r a n d u d a s y las que resultan fáciles de usar. El siguiente grupo de p r e g u n t a s (adaptado de [HAC98] ayudará al diseñado: interfaz a c o m p r e n d e r mejor a los usuarios de un sistema.

%%

TM • ¿Los usuarios s o n profesionales capacitados, técnicos, trabajadores de i u obreros?

PDF Editor CLAVE

¿Cómo aprendemos sobre la demografía y las características de los usuorios finales?

• ¿Qué grado de educación formal tiene el usuario promedio?

• ¿Los usuarios s o n capaces de a p r e n d e r con materiales escritos o expre su d e s e o de recibir capacitación e n el lugar?

• ¿Los usuarios son expertos para tipear o le tienen fobia al teclado? • ¿Cuál e s la edad promedio de la c o m u n i d a d de usuarios?

CAPÍTULO 12


361

• ¿Los usuarios corresponden predominantemente a algún género? • ¿Qué compensación reciben los usuarios por su trabajo? • ¿Los usuarios trabajan en horas normales de oficina, o siguen sus labores hasta que hayan terminado lo que están haciendo? • ¿El software será una parte integral del trabajo de los usuarios, o se empleará ocasionalmente? • ¿Cuál e s el idioma materno de los usuarios? • ¿Cuáles serían las consecuencias si un usuario comete un error mientras usa el sistema? • ¿Los usuarios son expertos en el tema que etiende el sistema? • ¿Los usuarios quieren conocer la tecnología que sustenta la interfaz? Las respuestas a éstas y otras preguntas similares permitirán que el diseñador comprenda quiénes son los usuarios finales, qué los motiva y complace, c ó m o se agruparían en diferentes clases o perfiles de usuarios, cuáles son sus modelos mentales del sistema, y cómo debe caracterizarse la interfaz de usuario para que satisfaga sus necesidades.

12.3.2

Análisis y m o d e l a d o d e tareas

El objetivo del análisis de la tarea es responder las siguientes preguntas: • ¿Qué trabajo hará el usuario en circunstancias específicas? • ¿Cuáles tareas y subtareas se realizarán mientras el usuario trabaja? • ¿Cuáles objetos específicos del dominio del problema manipulará el usuario mientras se realiza el trabajo? • ¿En qué secuencia se presentan tareas del trabajo (el flujo de trabajo)? • ¿Cuál e s la jerarquía de las tareas? Para responder estas preguntas, el ingeniero de software debe basarse en las técnicas de análisis expuestas en los capítulos 7 y 8; pero en este caso las técnicas se aplican a la interfaz del usuario. C a s o s de u s o . En capítulos anteriores se indicó que el caso de uso describe cómo un actor (en el contexto del diseño de la interfaz, un actor siempre e s una persona) interactúa con un sistema. Cuando se usa como parte del análisis de TMtareas, el caso de uso s e desarrolla para que muestre la manera en que el usuario final realiza alguna tarea específica relacionada con el trabajo. Casi siempre, el caso d e uso se escribe de manera informal (un solo párrafo) en primera persona. Por ejemplo, supóngase que una pequeña empresa de software quiere construir un sistema de diseño asistido por computadora explícitamente para diseñadores de interiores. Para comprender mejor cómo hacen su trabajo, se pide a diseñadores de interiores reales que describan funciones específicas del diseño. Cuando se les pregunta: "¿cómo decide

PDF Editor

362

PARTE D O S


el lugar e n q u e c o l o c a r á u n m u e b l e e n u n a habitación?", u n d i s e ñ a d o r d e inter: e s c r i b e el s i g u i e n t e c a s o de u s o informal: Empiezo haciendo un borrador del plano de la habitación, las dimensiones y la posiciode las ventanas y puertas. Me preocupo por la manera en que entra la luz, por la vista OLC se tiene a través de las ventanas (si es hermosa, me gustaría llamar la atención hacia ella por el espacio que las paredes n o tapan, por el flujo del movimiento en la habitación. LUÍ go observo la lista de muebles que mi cliente y yo hemos elegido (mesas, sillas, sillones vitrinas) y la lista de accesorios (lámparas, alfombras, cuadros, esculturas, plantas, peque ñas piezas}, y también observo mis notas sobre la manera en que mi cliente desea que se distribuyan. Luego dibujo cada elemento de mis listas empleando una plantilla que se "ri dibujado a escala con el plano. Etiqueto cada elemento y uso lápiz porque siempre mué vo cosas. Considero varias opciones de ubicación y decido cuál es la que me gusta mas. Luego dibujo una representación (una imagen tridimensional) del cuarto, para dar a ~ cliente una idea del aspecto que tendrá. Este c a s o d e u s o p r o p o r c i o n a u n a d e s c r i p c i ó n e l e m e n t a l de u n a t a r e a d e trabai

| rJ

p o r t a n t e p a r a el s i s t e m a d e d i s e ñ o a s i s t i d o por c o m p u t a d o r a . A partir de él, el n i e r o d e s o f t w a r e e x t r a e r á t a r e a s y o b j e t o s , a d e m á s del flujo g e n e r a l d e la i n t e n J ción. A d e m á s , t a m b i é n e s p o s i b l e c o n c e b i r o t r a s c a r a c t e r í s t i c a s del s i s t e m a I < I a g r a d a r í a n al d i s e ñ a d o r de interiores. Por e j e m p l o , p o d r í a n t o m a r s e fotografías : q d tales del p a n o r a m a d e c a d a v e n t a n a . Así, c u a n d o s e h a g a u n a r e p r e s e n t a c i ó n ;T • i m a g e n d e la h a b i t a c i ó n s e m o s t r a r í a la vista real e n c a d a v e n t a n a .

HOGARSEGURO II i -

Casos de uso para el diseño de interfaces de usuario La e s c e n a : Cubículo d e Vinod, mientras se continúa con el diseño d e le interfaz.

V i n o d : Eso está bien. Es uno d e los principales

Los a c t o r e s : Vinod y Jamie, integrantes del equipo d e ingeniería dei software d e HogarSeguro.

vigilancia. Pero tendremos q u e examinar también el

La conversación: J a m i e : Fui a ver a mi contacto d e mercadotecnia e hice que escribiera un caso d e uso p a r a la interfaz d e vigilancia. V i n o d : ¿Desde el punto d e vista d e quién? J a m i e : Del propietario d e la c a s a , ¿de quién más? V i n o d : También existe el enfoque del administrador. Aunque el propietario desempeñe ese papel, tendrá un

comportamientos d e la interfaz d e la función d e comportamiento del administrador del sistema.

J a m i e (irritada): Tienes razón. (Jamie sale a buscar a la persona d e mercadotecnia Regresa unas horas más tarde.) J a m i e : Tuve suerte. Encontré a nuestro contacto d e mercadotecnia y trabajamos ¡untos el caso del administrador. Básicamente, definiremos

TM

"administración" como una función aplicable a todas funciones d e HogarSeguro.

He aquí lo q u e hicimos.

(Jamie muestra a Vinod el caso d e uso informal.)

PDF Editor punto d e vista diferente. El "administrador" habilita el

sistema, configura las cosas, diseña el plano d e la casa,

coloca las cámaras..

J a m i e : Lo q u e hice fue q u e mercadotecnia representara eí papei cíe j n propietario q u e quiere ver un video.

C a s o d e u s o i n f o r m a l : Quiero la capacidad de configurar o editar el formato del sistema en cualquiemomento. C u a n d o configure el sistema seleccionaré 1c función de administración. Me pregunta si quiero de^- r una nueva configuración. Respondo afirmativamente :

CAPÍTULO 12

DISEÑO DE L A INTERFAZ DE USUARIO

i una pontana d e dibu|0 que m e permite

o eliminar los que ya existen, editar el plano d e la c a s a y

el plano d e !a casa en una cuadrícula. Habrá p a r a paredes, ventanas y puertas que me

los valores d e c á m a r a s y sensores. En todos los casos, espero que el sistema tenga consistencia y m e a y u d e a

•'n el dibujo. Solamente estiro los iconos p a r a que

no cometer errores.

la dimensión correcta. El sistema desplegará las pies o metros (puedo seleccionar el sistema ). Tengo la opción de seleccionar sensores y d e una biblioteca y d e ubicarlas en el plano, poner una leyenda a c a d a una, pero el sistema lo puede hacer automáticamente. Tengo la ' d e definir los parámetros d e sensores y liante menús especiales. Si selecciono editar, mover los sensores o las c á m a r a s , a g r e g a r nuevos

363

V i n o d ( d e s p u é s d e le er el g u i ó n ) : Muy bien. Tai vez haya algunos patrones d e diseño útiles o algunos componentes reutilizables q u e podamos usar en las interfaces gráficas d e usuario tomados d e algún programa de diseño. Te apuesto la comida a que, si los usamos, podemos ¡mplementar parte d e la interfaz del administrador, o casi toda ella. J a m i e : Estoy d e acuerdo, d é j a m e revisarlo.

Elaboración de la tarea. En el capítulo 9, se analizó la elaboración paso a paso (también denominada descomposición funcional o refinamiento paso a paso) como mecanismo para refinar las tareas de procesamiento requeridas para que el software realice alguna función deseada. El análisis de la tarea para el diseño de la interfaz emplea un enfoque elaborativo para apoyar la comprensión de las actividades h u m a n a s a las que debe adecuarse la interfaz de usuario. El análisis de la tarea se aplica de dos maneras. Como ya lo h e m o s indicado, un sistema interactivo, computacional, suele usarse para reemplazar una actividad manual o semiautomática. Con el fin de comprender las tareas indispensables para alcanzar el objetivo de la actividad, un ingeniero h u m a n o 5 debe comprender las tareas

<#

que las personas realizan actualmente (al usar un método manual) y luego relacionarlas con un conjunto similar (pero no necesariamente idéntico) de tareas que se implementan en el contexto de la interfaz de usuario. Como opción, el ingeniero hum a n o puede estudiar una especificación existente para una solución computarizada y derivar un conjunto de tareas de usuario que se adecuarán al modelo de éste, el modelo del diseño y la percepción del sistema.

se ha una torea no que no maneta de y que se •. aplicar e implemente de usuario.

Sin importar el enfoque general para el análisis de la tarea, un ingeniero h u m a n o debe definir y clasificar primero las tareas. Ya se ha indicado que un enfoque es la elaboración paso a paso. Por ejemplo, suponga que una pequeña compañía de software pretende construir un sistema de diseño asistido por computadora explícitamente para diseñadores de interiores. Al observar cómo trabaja uno de ellos, el ingeniero TM nota que el diseño de interiores abarca varias actividades importantes: distribución del mobiliario (tome en cuenta el caso de uso que ya analizamos), selección de telas y materiales, selección de tapices para paredes y cortinas para ventanas, presentación (para el cliente), presupuesto y compras. Cada una de estas importantes tareas pueden desglosarse en subtareas, Por ejemplo, de acuerdo con la información contenida en

PDF Editor 5

En muchos casos, un ingeniero de software realiza las tareas descritas en esta sección. Lo ideal es que esta persona tenga capacitación en ingeniería humana y eri diseño de interfaces de usuario.

364

PAETE DOS


el caso de uso, la distribución del mobiliario se retinaría de las siguientes tareas: 1 ; bujar un plano de la casa tomando c o m o base las dimensiones de la habitación ubicar las ventanas y puertas en los lugares adecuados; 3a) usar las plantilla; muebles para dibujar contomos a escala en el plano; 3b) usar las plantillas de ¡ sorios para dibujarlos a escala en el plano; 4) mover los contornos de los mueble; accesorios para obtener el mejor lugar; 5) rotular todos los contornos de muebles y ¡ cesorios; 6) dibujar las dimensiones para mostrar la ubicación; 7) generar la vista : dimensinal en perspectiva para el cliente. Un enfoque similar se usaría para una de las otras tareas importantes. Es posible retinar aún más de la subtareas I a 7. De la 1 a la 6 s e realizarán al: nipular la información y ejecutar acciones dentro de la interfaz de usuario. Por parte, el software tiene la capacidad de realizar automáticamente la subtarea que representaría poca interacción directa del usuario. 6 El modelo del diseño or ¡ ^CONSEJO^. Aunque lo elaboración del objeto sea útil, no debe usarse como un enfoque independiente. Lo voz del usuario debe tomarse en cuenta durante el análisis de la tarea.

interfaz debe acomodar cada una de esas tareas para que sea consistente con e.: délo del usuario (el perfil de un diseñador de interiores "típico") y la percepciór sistema (lo que el diseñador de interiores espera de un sistema automatizado Elaboración del o b jeto . En lugar de concentrarse en las tareas que un debe realizar, el ingeniero de software examina el caso de uso y otra informador ; tenida del usuario y obtiene los objetos fisicos que usa el diseñador de interiores tos objetos pueden ordenarse en clases. Los atributos de cada clase y una ción de las acciones aplicadas a cada objeto proporcionan al diseñador una hs-u operaciones. Por ejemplo, la plantilla de muebles se traduce en una clase lia M u e b l e c o n a t r i b u t o s q u e p o d r í a n i n c l u i r tamaño, forma, ubicación y o t r a s . El

dor de interiores seleccionaría el objeto de la clase Mueble, lo movería a una | en el plano (otro objeto en el contexto), dibujaría el contorno d e los muebles, e : : tareas seleccionar, mover y dibujar son operaciones. El modelo del análisis de .; i terfaz de usuario no proporcionaría una implementación para cada una de operaciones. Sin embargo, a medida que se elabore el diseño se definirían los ; lies de cada operación. Análisis del flujo de trabajo. Cuando distintos usuarios, cada uno repre do diferentes papeles, utilizan una interfaz de usuario, a veces e s necesario allá del análisis de la tarea y la elaboración de objetos y aplicar el análisis delj trabajo. Esta técnica permite que un ingeniero de software comprenda cómo se i TM liza un proceso de trabajo cuando s e involucran varias personas (y papeles), en una compañía que pretende automatizar el proceso de prescribir y enviar: camentos que se venden con receta. Todo el proceso 7 girará alrededor de un;

PDF Editor

Sin embargo, tal vez éste no sea el caso. Es probable que el diseñador de Interiores quiera i car la perspectiva del dibujo, el tamaño o el uso del color y otra información. El caso de i cionado con las representaciones de dibujos en perspectiva proporcionaría la informacic: necesita atender en esta tarea. Este ejemplo se ha adaptado de (HAC98],

CAPÍTULO 12

365


cación Web disponible para médicos (o sus asistentes), farmacéuticos y pacientes. El flujo de trabajo se representa de manera efectiva con un diagrama de linea de flotación UML (una variante del diagrama de actividad). Sólo se considerará una pequeña parte del proceso de trabajo: la situación que se presenta cuando un paciente pide que se le resurta una receta. En la figura 12.2 se presenta un diagrama de línea de flotación que indica las tareas y decisiones de cada uno de los tres papeles citados. Esta información podría obtenerse mediante entrevistas o casos de estudio escritos por cada actor. Independientemente de esto, el flujo de los eventos (mostrados en la figura) permite que el diseñador de la interfaz reconozca tres características clave: 1. Cada usuario implementa diferentes tareas con la interfaz; por tanto, el concepto de la interfaz diseñada para el paciente será diferente del aplicado a los farmacéuticos o médicos. 2 . El diseño de la interfaz para farmacéuticos y médicos debe tener acceso a la información de fuentes secundarias (como acceso a inventarios de farmacia y a la información acerca de medicamentos alternos por parte del médico), además de desplegar esta información. 3. Es posible elaborar aún m á s muchas actividades indicadas en el diagrama de línea de flotación mediante análisis de la tarea, elaboración de objetos, o ambas opciones (por ejemplo, prescripción de resurtido podría relacionarse con una entrega por correo, o una visita a la farmacia o a un centro especial de distribución de medicamentos). R e p r e s e n t a c i ó n jerárquica. Cuando se analiza una interfaz ocurre un proceso de elaboración. Una vez establecido el flujo de trabajo se define una jerarquía de tarea para cada tipo de usuario. La jerarquía se deriva de una elaboración paso a paso de cada tarea que el usuario haya identificado. Por ejemplo, piénsese en la tarea de usuario solicitar que se resurta una receta. Se desarrolla la siguiente jerarquía de tareas: Solicitar que se resurta una receta • Proporcionar información de identificación • Especificar nombre • Especificar identidad de usuario

TM

- Especificar NIPy contraseña

PDF Editor • Especificar número de receta

• Especificar fecha en que se requiere el resurtido

Completar la tarea solicitar que se resurta una receta requiere definir tres subtareas. Una de ellas, proporcionar información de identificación, incluye tres subtareas adicionales.

366

PARTE DOS


Diagrama de línea de flotación para la función d e resurtido de recetas.

TM

PDF Editor

CAPÍTULO 12

367


"Es mucho mejor adaptar la tecnología al usuario que obligar o éste a adaptarse a la tecnología." Larry Marine

12.3.3

Análisis del contenido d e la pantalla

Las tareas del usuario identificadas en la sección anterior llevan a la presentación de diferentes tipos de contenido. En el caso de aplicaciones modernas, el contenido de la pantalla va de informes b a s a d o s en caracteres (por ejemplo, h o j a s de cálculo), p a n tallas gráficas (por ejemplo, un histograma, un modelo 3-D, la fotografía de u n a persona) o información especializada (como archivos de a u d i o o video). Las técnicas de modelado del análisis estudiadas en el capítulo 8 identifican los objetos de datos de salida que produce u n a aplicación. Estos objetos de datos son: 1) generados por componentes (no relacionados con la interfaz) en otras partes de la aplicación; 2) adquiridas de los datos a l m a c e n a d o s en una base de datos a la que se tiene acceso desde la aplicación, o 3) transmitida de sistemas externos a la aplicación en cuestión. En e s t e p a s o del análisis de la interfaz se consideran el formato y la estética del contenido (tal c o m o se despliega en la interfaz). Entre las preguntas que se habrán de plantear se e n c u e n t r a n las siguientes: • ¿Hay diferentes tipos de d a t o s asignados a ubicaciones consistentes e n la ¿Cómo s e >ylo i del i como i de lo : de a?

pantalla (por ejemplo, las fotos siempre a p a r e c e n en la esquina superior derecha de la pantalla)? • ¿El usuario p u e d e personalizar la distribución del contenido en la pantalla? • ¿Se ha a s i g n a d o una apropiada identificación en pantalla a todo el contenido? • ¿Cómo se s e g m e n t a un informe largo para facilitar su comprensión? • ¿Habrá m e c a n i s m o s disponibles para desplazar directamente al r e s u m e n de información en c o n j u n t o s g r a n d e s de datos? • Se cambiará el t a m a ñ o de la salida gráfica para que quepa dentro de los límites de la pantalla o el monitor que habrá de usarse? • ¿Cómo se usará el color para mejorar la c o m p r e n s i ó n ? • ¿Cómo se presentarán al usuario los m e n s a j e s de error y los avisos de precaución? A medida que se responden e s t a s (y otras) preguntas se establecerán los requisitos para la presentación del contenido.

12.3.4

Análisis del entorno d e trabajo

TM

Hackos y Redish [HAC981 analizan la importancia del análisis del e n t o r n o de trabajo c u a n d o afirman:

PDF Editor

La gente no trabaja aislada; la afectan la actividad que se realiza a su alrededor, las características físicas del lugar de trabajo, el tipo de equipo que emplea y sus relaciones de trabajo con los demás. Si los productos que se diseñan no se amoldan al entorno, es posible que su uso resulte ditícil o frustrante.

368

PARTE DOS


En algunas aplicaciones la interfaz de usuario para un sistema de cómputo se < ca en un "lugar amigable para el usuario" (por ejemplo, iluminación apropiada, I na altura de la pantalla, fácil acceso al teclado), pero en otros (como el piso de i fábrica o la cabina de un avión), la iluminación es deficiente, el ruido es impor un teclado o un ratón no son una opción, la colocación del monitor e s menos i ideal. Al diseñador de la interfaz lo limitarán factores que atentan contra la fácil., de uso. Además de los factores del entorno físico, la cultura del lugar de trabajo tar incide. ¿La interacción del sistema se medirá de alguna manera (por ejemplo, po por transacción o exactitud de ésta)? ¿Dos o más personas tendrán que cc tir información antes de que se proporcione una entrada? ¿Cómo se dará sop los usuarios del sistema? Es necesario responder éstas y muchas otras pregunta; lacionadas antes de iniciar el diseño de la interfaz.

Una vez finalizado el análisis de la interfaz, se han identificado con detalle te tareas (objetos o acciones) que requiere el usuario final, y comenzará la activid diseño de la interfaz. Esta etapa, como todo el diseño de la ingeniería del es un proceso iterativo. Cada paso del diseño de la interfaz se da varias veces ¡ cada uno de ellos se elabora y refina información desarrollada en los pasos < res. Aunque se han propuesto muchos modelos diferentes para el diseño de la i faz de usuario (por ejemplo, [NOR86], [NIEOO]), todos sugieren alguna combii de los siguientes pasos: 1. Con base en la información desarrollada durante el análisis de la infor (sección 12.3), definir los objetos y las acciones de la interfaz (operacic 2 . Definir eventos (acciones del usuario) que cambiarán el estado de la int Modelar este comportamiento. 3. Representar cada estado de la interfaz tal como lo verá el usuario final 4 . Indicar c ó m o interpreta el usuario el estado del sistema a partir de la i proporcionada mediante la interfaz. TM En algunos casos, el diseñador de la interfaz puede empezar con borradores i da estado de la interfaz (es decir, el aspecto de la interfaz en distintas circur

y luego trabajar hacia atrás para definir objetos, acciones y otra información tante para el diseño. Independientemente de la secuencia de las tareas del éste debe 1) seguir siempre las reglas de oro analizadas en la sección 12.1; 2 : lar la manera en que se implementará la interfaz, y 3) tomar en cuenta el (por ejemplo, la tecnología de despliegue, el sistema operativo, las herramii

PDF Editor desarrollo) en que habrá de usarse.

CAPÍTULO 12

369


"Ei diseño interortivo [es] uno mezclo integrada de artes gráficas, tecnología y psicología." Brad Wieners

12.4.1

Aplicación d e los pasos del diseño d e la interíaz

Un p a s o importante e n el diseño de la interfaz es la definición de los objetos que ésta tendrá y las acciones que se les aplicarán. Para realizarlo se analizan los c a s o s de uso de m a n e r a muy parecida a la descrita en el capítulo 8. Es decir, se escribe una descripción de u n c a s o de uso. Luego se aislan los n o m b r e s (objetos) y los verbos (acciones) para crear una lista de objetos y acciones. Una vez definidos los objetos y las acciones, que se han elaborado de m a n e r a iterativa, se organizan por tipo. Se identifican objetos de destino, origen y aplicación. Un objeto de origen (como el icono de un informe) se arrastra y coloca en un objeto de destino (por ejemplo, un icono de impresora). La implicación de esta acción es crear un informe impreso. Un objeto de aplicación representa datos específicos de la aplicación que no se manipulan directamente c o m o parte de la interacción con la pantalla. Por ejemplo, en una lista de correo se a l m a c e n a n n o m b r e s para un envío de correspondencia. La propia lista podría ordenarse, combinarse o purgarse (acciones de menú), p e r o no arrastrarse ni colocarse mediante interacción del usuario. Una vez q u e el diseñador queda satisfecho con un objeto importante y que se han definido las acciones (para u n a iteración de diseño) se realiza el formato de la p a n talla. C o m o o t r a s actividades de diseño de la interfaz, el formato

de la pantalla e s un

proceso interactivo; en él se elabora el diseño gráfico y se colocan los iconos, la definición de texto descriptivo en pantalla, la especificación y la asignación de n o m bres a las ventanas, a d e m á s de la definición de los e l e m e n t o s primarios y secundarios de los menús. Si una metáfora de la realidad es apropiada para la aplicación, se especifica en e s t e m o m e n t o , y el diseño se organiza de m a n e r a tal que satisfaga la metáfora. Un breve ejemplo de los p a s o s del diseño indicados a n t e r i o r m e n t e se obtiene imaginando el contexto e n q u e s e sitúa un usuario del sistema HogarSeguro analizad o en capítulos anteriores. A continuación se presenta un c a s o de estudio preliminar (escrito por el propietario) para la interfaz. C a s o d e u s o preliminar. Quiero tener acceso a mi sistema HogarSeguro desde cualquier lugar remoto vía Internet. Empleando software de navegador que opera en mi notebook (mientras estoy trabajando o viajando) puedo determinar el estado del sistema TM de alarmas, armar o desarmar el sistema, reconfigurar zonas de seguridad y ver diferentes habitaciones de la casa con las cámaras de video preinstaladas.

PDF Editor

Para tener acceso a HogarSeguro desde un lugar remoto proporciono una identificación

y una contraseña. Estos elementos definen los niveles de acceso (por ejemplo, no todos los usuarios pueden reconfigurar el sistema ni proporcionar seguridad). Una vez validado, puedo revisar el estatus del sistema y cambiarlo al armar o desarmar HogarSeguro. Puedo reconfigurar el sistema al desplegar un plano de la casa, ver cada uno de los sensores de

370

PARTE DOS


seguridad, desplegar c a d a z o n a configurada a c t u a l m e n t e y modificar z o n a s d e acuerd con las necesidades. Puedo ver el interior de la c a s a c o n las c á m a r a s de video colocada? d e m a n e r a estratégica. Puedo h a c e r acercamientos y desplazamientos c o n las c á m a r a i p a r a proporcionar diferentes vistas del interior.

Con base en este caso de uso se identifican las tareas del propietario, los objet los elementos siguientes: • tiene acceso al sistema HogarSeguro • ingresa un ID y una c o n t r a s e ñ a para acceso remoto • revisa el e s t a t u s del s i s t e m a • arma o desarma el sistema HogarSeguro • despliega el plano d e la c a s a y las u b i c a c i o n e s d e l o s s e n s o r e s • despliega z o n a s en el plano de la casa • cambia z o n a s en el plano de la casa • despliega u b i c a c i o n e s de l a s c á m a r a s d e v i d e o o el p l a n o de la casa • selecciona visualmente una cámara d e v i d e o • ve i m á g e n e s d e v i d e o • desplaza o acerca las c á m a r a s d e v i d e o Los objetos (en negritas) y las acciones (en cursivas) se extraen de la lista de del propietario. La mayor parte de los objetos indicados son objetos de la ap Sin embargo, ubicación d e las c á m a r a s de v i d e o (un objeto de origen) se tra y coloca en cámara de v i d e o (un objeto de destino) para crear una i video (una ventana que contiene el despliegue de video). Se crea un boceto preliminar del formato de la pantalla para el monitoreo ÔNSEJCÍ^ Aunque las herramientas automatizadas son útiles en el desarrollo de prototipos de formato, en ocasiones todo lo que se necesita es lápiz y papel.

deo (figura 12.3).8 La imagen de video se solicita seleccionando un icono de ción de las cámaras de video, C, localizado en el plano de la casa despleg: ventana de monitoreo. En este caso se arrastra la ubicación de una cámara de en la sala, SA, y se coloca sobre el icono de cámara de video ubicado en la perior izquierda de la pantalla. Aparecerá la ventana de imagen de video, do video de flujo continuo proveniente de la cámara ubicada en la sala (SA troles deslizables de acercamiento y desplazamiento se emplean TM para cr ampliación y la dirección de la imagen del video. Para seleccionar una vista cámara, el usuario simplemente arrastra y coloca un icono de ubicación ck

PDF Editor 8

Considérese que esto difiere de la implementación de estas caracteristicas en capítulos Esto podría considerarse un borrador del primer diseño y representa una opción digna en cuenta

CAPÍTULO 12

371


Acceso Configurar Sistema

Estatus Ver Supervisar

HogarSeguro Cámoro de video.

Primer piso D Detecto: de movimiento frayo mostradoj C Ubicación de cámaro de video Acercar

|[ Zoom

I

mi||[\\JAIejar

Dezplazar

diferente en el icono de la cámara emplazado en la esquina superior izquierda de la pantalla. El boceto del formato que se muestra tendría que complementarse con una expansión de cada elemento de menú dentro de la barra de menús, indicando cuáles acciones están disponibles para el modo de monitoreo de video (estado). Durante la etapa de diseño de la interfaz se crearía un conjunto completo de bocetos para cada tarea de propietario anotada en el escenario del usuario.

12.4.2

Patrones d e diseño d e la interfaz d e usuario

Las interfaces gráficas de usuario sofisticadas se han vuelto tan comunes que ha surgido una amplia variedad de patrones de diseño de interfaces de usuario. Como se observó al principio de este libro, un patrón de diseño e s una abstracción que presTM cribe una solución de diseño a un problema de diseño específico, bien delimitado. Cada uno de los patrones de ejemplo (y todos los patrones de cada categoría) presentados en el recuadro siguiente también tendría un diseño completo al nivel de componentes, incluidos clases, atributos, operaciones e interfaces de diseño.

PDF Editor

Un análisis completo de los patrones de interfaz de usuario está más allá del alcance de este libro. El lector interesado debe consultar IDUY02J, (BOROl], [WEL011 y [TID02] para conocer más información.

372

PARTE D O S


INFORMACIÓN

Patrones de interfaz de usuario En las últimas d é c a d a s se han propuesto cientos d e patrones d e interfaz d e usuario. Tidwell [TID02] y Van Welie [WEL01] proporcionan taxonomías 9

D e s c r i p c i ó n b r e v e : Proporciona una ruta completa de navegación cuando el usuario está trabajando con une jerarquía completa d e páginas o pantallas de despliega

de los patrones d e diseño d e interfaz d e usuario q u e se

Navegación.

han o r g a n i z a d o en 10 categorías. En este recuadro se presentan patrones d e ejemplo d e c a d a una d e estas catego-

nús jerárquicos, p á g i n a s W e b y pantalla de despliegue -

rías. Interfaz d e usuario c o m p l e t a .

Proporciona líneas

Ayuda al usuario en el recorrido de rre

teractivo. P a t r ó n : edición en el lugar D e s c r i p c i ó n b r e v e : Proporciona la capacidad d e e c

generales de diseño p a r a estructura y navegación d e alto

ción simple d e textos p a r a ciertos tipos d e contení de s r

nivel. P a t r ó n : navegación

el lugar en que se despliega. de alto nivel

Búsqueda.

D e s c r i p c i ó n b r e v e : Proporciona un menú d e alto nivel,

Permite búsquedas d e contenido e s p e d í a

mediante la información mantenida en un sitio W e b o zzr-,

a menudo acoplado a un logotipo o una imagen d e

tenida en almacenes persistentes d e datos que están

identificación q u e permite la navegación directa a cual-

sibles p a r a una aplicación interactiva.

quiera de las principales funciones del sistema.

P a t r ó n : búsqueda simple D e s c r i p c i ó n b r e v e : Proporciona la capacidad de

Diseño d e página.

Atiende la organización general

d e las páginas (para sitios Web) o distintos despliegues d e

car, en un sitio W e b o una fuente d e datos persiss

pantalla (para aplicaciones interactivas).

un elemento simple d e datos descrito por una cod

P a t r ó n : pila de carias D e s c r i p c i ó n b r e v e : Proporciona el aspecto d e una pila

alfanumérica. Elementos d e página

Implemento elementos

d e cartas con pestañas; p a r a seleccionarlas se hace dic

eos d e un p á g i n a W e b o pantalla d e despliegue.

en c a d a una d e ellas, q u e representa subfunciones es-

P a t r ó n : asistente

pecíficas o categorías d e contenido.

D e s c r i p c i ó n b r e v e : Lleva al usuario p a s o a paso

Formularios y entrada.

Toma en cuenta diversas

técnicas d e diseño p a r a completar entradas al nivel d e for-

una tarea compleja, proporcionando guías p a r e pletar la tarea mediante una serie d e ventanas

mularios. P a t r ó n : llene los espacios en blanco

Comercio electrónico

D e s c r i p c i ó n b r e v e : Permite el ingreso d e datos alfanu-

nes d e comercio electrónico.

méricos en un "cuadro d e texto". Tablas.

Específicos d e sitios Web

patrones implementan elementos recurrentes de P a t r ó n : carrito de compras

Proporciona guía d e diseño p a r a la creación y

manipulación d e todo tipo d e datos tabulares.

D e s c r i p c i ó n b r e v e : Proporciona una lista d e seleccionados en una compra.

P a t r ó n : lab/a que permite su ordenación

Varios

D e s c r i p c i ó n b r e v e : Despliega una larga lista d e regis-

rías anteriores. En algunos casos, estos patrones

tros q u e se ordenan al seleccionar un mecanismo inte-

del dominio u ocurren p a r a clases específicas de

rruptor p a r a cualquier etiqueta d e la columna. Manipulación directa d e d a t o s .

Atiende la edi-

ción, modificación y transformación d e datos. i P a t r ó n : migas de pan

Patrones q u e no caben fácilmente en las

P a t r ó n : indicador de programa D e s c r i p c i ó n b r e v e : Proporciona una indicados greso cuando se está realizando una operocicr

TM

12.4.3

Temas d e diseño

PDF Editor

A medida que evoluciona el diseño de u n a interfaz casi siempre surgen cuatr: i comunes: tiempo de respuesta del sistema, funciones de ayuda para el nejo de información de error y rotulado de comandos. Por desgracia, m 9

En [T1D02] y [WEL01] se encontrarán descripciones d e p a t r o n e s completos (junto cor.

otros patrones).

CAPITULO 12

373


fiadores no prestan atención a e s t o s t e m a s h a s t a una etapa relativamente tardía del proceso de diseño (en ocasiones el primer atisbo de un problema se presenta hasta que se dispone de un prototipo operacional). Como resultado, a veces se tiene iteración innecesaria, d e m o r a s del proyecto y frustración del cliente. Es m u c h o mejor abordar cada uno c o m o e l e m e n t o de diseño y tomarlo en cuenta al principio del dis e ñ o d e software, c u a n d o los c a m b i o s s o n fáciles y el c o s t o e s bajo. "Un error común que comete lo gente cuando trato de diseñor algo o prueba de tontos es subestimar la ingenuidad de los verdaderamente tontos." D o u g k s Adams

Tiempo de respuesta.

El tiempo de respuesta del sistema es la primera queja so-

bre m u c h a s aplicaciones interactivas. En general, se mide d e s d e el p u n t o en que el usuario realiza alguna acción de control (como oprimir la tecla Return o hacer clic con el ratón) hasta que el s o f t w a r e responde con la salida o la acción deseada. El t i e m p o d e r e s p u e s t a del s i s t e m a t i e n e d o s c a r a c t e r í s t i c a s i m p o r t a n t e s : d u r a c i ó n y variabilidad.

Si la respuesta del sistema s e demora mucho, la frustra-

ción y el estrés del usuario son inevitables. Variabilidad es la desviación del tiempo d e respuesta promedio y, en m u c h o s sentidos, e s la característica m á s importante del tiempo de respuesta. Una baja variabilidad permite q u e el usuario establezca un ritmo de interacción, a u n q u e el tiempo de respuesta sea relativamente largo. Por ejemplo, una respuesta de 1 s e g u n d o a un c o m a n d o a m e n u d o será preferible a u n a respuesta que varía de 0.1 a 2.5 segundos. C u a n d o la variabilidad e s significativa, el usuario siempre se encontrará fuera de balance, siempre se preguntará si ha ocurrido algo "diferente" tras bastidores. Funciones d e ayuda.

Casi todos los usuarios d e un sistema de c ó m p u t o interac-

tivo necesitan ayuda de vez en cuando. En algunos casos, basta con una simple pregunta dirigida a un colega con experiencia. En otros, tal vez la única opción sea una investigación detallada en un conjunto de varios v o l ú m e n e s de " m a n u a l e s de usuario". Sin embargo, e n casi t o d o s los c a s o s el software m o d e r n o proporciona funcion e s de ayuda e n línea que permiten al usuario obtener una respuesta a sus preguntas o resolver un problema sin dejar la interfaz. Deben a t e n d e r s e varios t e m a s de diseño [RUB88] c u a n d o s e t o m a en cuenta una TM opción de ayuda. • ¿La ayuda estará disponible para t o d a s las funciones del sistema y en todo

PDF Editor

m o m e n t o d u r a n t e la interacción con éste? Entre las opciones se incluye ayuda sólo para un s u b c o n j u n t o de t o d a s las funciones y acciones o ayuda para to-

d a s las funciones.

• ¿Cómo necesitará la ayuda el usuario? Entre las opciones se incluyen m e n ú de ayuda, u n a tecla especial de función o un c o m a n d o AYUDA.

374

PARTE D O S


• ¿Cómo se representará la ayuda? Las opciones son una v e n t a n a separada, u n a referencia a un d o c u m e n t o impreso (menos que ideal) o una sugerencia de u n a o dos lineas que aparece en un lugar fijo de la pantalla. • ¿Cómo regresará el usuario a la interacción normal? Entre las opciones se ircluyen un botón de regreso desplegado en la pantalla, u n a tecla de función : u n a secuencia de control. • ¿Cómo se estructurará la información de ayuda? Las opciones son u n a estro; tura "plana" en que se tiene a c c e s o a toda la información con el teclado, u r a jerarquía en c a p a s de información que proporciona detalles crecientes a me dida que el usuario la recorre, o el uso de hipertexto. Manejo de errores.

Los m e n s a j e s de error y los avisos de precaución son

noticias" que se entregan a los usuarios de sistemas interactivos c u a n d o algo sale i En el peor de los casos, los m e n s a j e s de error y los avisos de precaución ofreceformación inútil o que puede malinterpretarse y que sólo sirve para aumentar la tración del usuario. Algunos usuarios de computadora h a n encontrado un error 3r i forma "La aplicación XXX se ha visto forzada a cerrarse porque se ha encontrado un • del tipo 1023". En algún lugar debe existir u n a explicación del error 1023; de lo« rio, ¿por qué habrían asignado los diseñadores ese identificador? Sin e m b a í ; : 4 mensaje de error no proporciona una indicación real de lo que estuvo mal ni de de buscar la información adicional. Un m e n s a j e de error p r e s e n ta do de esta n o h a c e nada por aliviar la ansiedad del usuario ni ayuda a corregir el problema "Lo interfaz con el infierno: 'Poro corregir este error y seguir adelante, escribo cualquier número primo de 1 1 : : los..."

Autor a o M En general, todo m e n s a j e de error o aviso de precaución que produzca un s f l m a interactivo debe tener las siguientes características:

?

Qué

características d e b e t e n e r un "buen" mensaje d e error?

• El m e n s a j e d e b e describir el problema en un lenguaje que el usuario er • El m e n s a j e debe proporcionar consejos constructivos sobre la m a n e r a JT -i cuperarse del error. • El mensaje debe indicar cualquier consecuencia negativa del error (por e - t r J la posibilidad de que se corrompan los archivos de datos) para TMque el USUL-J asegure que no han ocurrido (o para que los corrija si ya ocurrieron). • El m e n s a j e debe a c o m p a ñ a s e de u n a pista visual o auditiva. Es decir c a J

PDF Editor

nerarse un bip junto con el despliegue del mensaje, o éste d e b e p a r p a c e a r l m o m e n t á n e a m e n t e o desplegarse e n un color que se reconozca f á c i l i r = * i c o m o "color de error".

• El m e n s a j e n o d e b e contener juicios. Es decir, la redacción n u n c a debc . H al usuario.

CAPÍTULO 12


375

C o m o a nadie le gustan las m a l a s noticias, a p o c o s usuarios le gustarán los m e n s a jes de error, sin importar lo bien diseñados que estén. Pero un e n f o q u e a d e c u a d o para los m e n s a j e s de error hará m u c h o por mejorar la calidad de un sistema interactivo y reducirá de m a n e r a importante la frustración del usuario c u a n d o ocurran ios problemas. Rotulación de m e n ú s y c o m a n d o s .

El c o m a n d o de texto escrito fue alguna vez

el m o d o m á s c o m ú n de interacción entre los usuarios y el software del sistema y se usaba en aplicaciones de todo tipo. Hoy el uso de interfaces orientadas a ventanas, con opción de señalar y elegir, h a reducido la dependencia de los c o m a n d o s escritos, pero m u c h o s usuarios a v a n z a d o s aún prefieren este tipo de interacción. Varios t e m a s de diseño surgen c u a n d o s e proporcionan c o m a n d o s de texto o etiquetas de m e n ú c o m o m o d o de interacción: • ¿Cada opción de m e n ú tiene un c o m a n d o correspondiente? • ¿Qué forma tendrán los c o m a n d o s ? Entre las opciones se incluyen una secuencia de control (como alt-P), teclas de función o palabras escritas por el usuario. • ¿Qué tan difícil será a p r e n d e r y recordar los c o m a n d o s ? ¿Qué p u e d e hacerse si se olvida un c o m a n d o ? • ¿El usuario tiene la opción de personalizar o abreviar los c o m a n d o s ? • ¿Las etiquetas de los m e n ú s se explican por sí solas d e n t r o del contexto de la interfaz? • ¿Los s u b m e n ú s son consistentes con la función indicada en un e l e m e n t o principal del m e n ú ? C o m o se indicó al principio de e s t e capítulo, es necesario definir c o n v e n c i o n e s para u s a r c o m a n d o s en toda la aplicación. Es c o n f u s o para el usuario y a m e n u d o lo lleva a cometer errores escribir alt-D c u a n d o desea duplicar un objeto gráfico en u n a aplicación y alt-D c u a n d o quiere d e s h a c e r una acción en otra. Es obvio que e s t o propiciará errores. e sitio ranfraró l¡

A c c e s i b i l i d a d d e la a p l i c a c i ó n .

A medida que las aplicaciones de computadora

se vuelven ubicuas, los ingenieros de software deben asegurarse de que el diseño de

des

la interfaz tenga m e c a n i s m o s que permiten u n fácil a c c e s o a quienes tienen necesi-

www.3.

d a d e s especiales. La accesibilidad es un imperativo moral, legal y comercial para los TM usuarios (e ingenieros de software) que tienen problemas físicos. Diversas líneas ge-

/oble/ */

•/ J ¡

nerales de accesibilidad (por ejemplo, [W3C03]), m u c h a s diseñadas para aplicacio-

PDF Editor • o r s software.

n e s Web, pero a m e n u d o aplicables a cualquier software, proporcionan sugerencias detalladas para el diseño de interfaces que a l c a n z a n diferentes grados de accesibili-

dad. Otros (como [APP03], [MIC03]) proporcionan lineas generales específicas para "tecnología asistencial" que atiende las n e c e s i d a d e s de quienes tienen discapacidad e s visuales, auditivas, de movilidad, del habla o de aprendizaje.

376

PASTE DOS


Internacionalización.

Los ingenieros de software y sus administradores subesti

man invariablemente el esfuerzo y las habilidades necesarias para crear interfases de usuario que atiendan las necesidades de usuarios de otras localidades o que ha blan diferentes idiomas. Con demasiada frecuencia, las interfases se diseñan para u n a localidad y u n idioma y luego se espera que funcionen en otros países. El rete para los diseños de interfases es crear software "globalizado"; las interfaces de usua rio deben diseñarse para contener un núcleo genérico de funciones que se entreguer a todos los usuarios. Características adicionales de localidad permiten a la interfa: personalizarse para un m e r c a d o específico. Los ingenieros de software cuentan con varias pautas para la internacionaliza ción (como [IBM03]). Estas p a u t a s atienden amplios problemas de diseño (como la; diferencias e n formato de pantalla en varios mercados) y t e m a s discretos de imple mentación (por ejemplo, diferentes alfabetos pueden crear rotulación y requisitos de espacio especiales). El estándar Unicode [UNI03]) s e ha desarrollado para atender e desalentador desafio de manejar d o c e n a s de idiomas naturales con cientos de cara; teres y símbolos.


Desarrollo de interfases de usuario •

O b j e t i v o . Estas herramientas le permiten a un

Herramientas de representación 1

ingeniero d e software crear una sofisticada interfaz gráfica d e usuario empleando relativamente escaso

Macromedia

Authorware,

desarrollado por Macromedia

desarrollo de software personalizado. Las herramientas pro-

Inc. (www.macromedia.com/software/), se ha diseña-

porcionan acceso a componentes reutilizables y convierte la

d o p a r a la creación d e interfases y entornos de apren-

creación d e una interfaz en una selección entre opciones

dizaje electrónico. Emplea características sofisticadas

predefinidas que se ensamblan mediante la herramienta.

d e construcción.

M e c á n i c a . Las interfases d e usuario modernas están

Motil Common Desklop Environment, desarrollado por The

construidas con un conjunto d e componentes reutilizables

O p e n Group (www.osf.org/tech/desktop/cde/), es

acoplados con algunos componentes personalizados desa-

una interfaz gráfica d e usuario integrada p a r a siste-

rrollados p a r a proporcionar funciones especializadas. Ca-

mas abiertos d e computación d e escritorio. Entrega

si todas las herramientas d e desarrollo d e interfases d e

una interfaz gráfica simple, estándar, p a r a la adminis-

usuario permiten q u e el ingeniero d e software cree una in-

tración d e datos, archivos y aplicaciones.

terfaz empleando opciones d e "arrastrar y colocar"; es decir, el desarrollador selecciona entre opciones predefinidas (por ejemplo, constructores de formularios, mecanismos d e interacción, c a p a c i d a d d e procesamiento d e comandos) y coloca esas opciones en el contenido d e la interfaz q u e habrá d e crearse.

PowerDesigner/PowerBuilder, desarrollado por Sybase (www.sybase/products/internetappdevtools), es un conjunto muy completo d e herramientas CASE, q u e in-

TM

cluyen muchas opciones p a r a el diseño y la construcción d e interfases gráficas d e usuario.

PDF Editor

10 Las herramientas expuestas aquí sólo representan una muestra de esta categoría. En casi todos casos los nombres de las mismas son marcas registradas de sus respectivos desarrolladores.

CAPÍTULO 12

12.5

377


E V A L U A C I Ó N PEÍ, DISEÑO

Una vez que se ha creado un prototipo de interfaz de usuario operacional, d e b e evaluarse y determinar si satisface las necesidades del usuario. La evaluación p u e d e abarcar u n espectro de grados de formalidad que va d e s d e una "prueba de manejo" informal, en la cual un usuario proporciona retroalimentación informal, hasta un estudio d i s e ñ a d o formalmente, el cual emplea m é t o d o s estadísticos para la evaluación de cuestionarios q u e llena u n a población de usuarios finales. El ciclo de evaluación d e la interfaz d e usuario a s u m e la forma m o s t r a d a en la figura 12.4. Después de completado el diseño se crea un prototipo de primer nivel. A continuación, el usuario evalúa e s t e p r o t o t i p o " y h a c e c o m e n t a r i o s directos al diseñador acerca de la eficacia de la interfaz. Además, si se utilizan técnicas formales de evaluación (por ejemplo, cuestionarios, h o j a s de evaluación), e s probable que el dis e ñ a d o r obtenga información de e s t o s d a t o s (por ejemplo, del 80 al 100 p o r ciento de los usuarios rechaza el m e c a n i s m o para guardar archivos de datos). Las modificaciones al diseño se hacen b a s á n d o s e en la información que proporciona el usuario, y así se crea un prototipo de s e g u n d o nivel. El ciclo d e la evaluación continúa hasta que ya s e a n innecesarias m á s modificaciones al diseño de la interfaz.

de

Diseño preliminar

Són

~'erlqz.

Se realizan modificaciones al diseño

Diseño d e interfaz completo

El d i s e ñ a d o r estudia la evaluación

TM

PDF Editor

11 Es importante notar que los expertos en diseños ergonómomico y de interfaz también pueden dirigir revisiones de la interfaz. Dichas funciones se llaman evaluaciones heurísticas o ensayos cognitivos.

378

PARTE DOS


El enfoque de creación de prototipos resulta eficaz, pero ¿es posible evaluar la calidad de una interfaz de usuario antes de construir un prototipo? Si se descubren posibles problemas y se corrigen en las primeras etapas, se reducirá el número de bucles en el ciclo de evaluación y se acortará el tiempo de desarrollo. Si se ha cread: un modelo de diseño de la interfaz, es posible aplicar varios criterios de evaluaciór [MOR81) en las primeras revisiones del diseño: 1. La longitud y complejidad de la especificación escrita del sistema y su interfaz indican la cantidad de aprendizaje necesario para los usuarios del sistema. 2 . El número especificado de tareas del usuario y el promedio de acciones por tarea indican el tiempo de interacción y la eficacia global del sistema. 3. La cantidad de acciones, tareas y estados del sistema que indica el modelo diseño se relaciona con la carga de memoria que recae en los usuarios del sistema. 4.

El estilo de la interfaz, las funciones de ayuda y el protocolo de manejo de errores indican en forma general la complejidad de la interfaz y el grado de aceptación del usuario.

Una vez construido el primer prototipo, el diseñador puede recopilar diversos dat cualitativos y cuantitativos que ayudarán a evaluar la interfaz. Para recopilar los tos cualitativos se pueden distribuir cuestionarios entre los usuarios del prototip: con preguntas que arrojan: 1) respuesta simple si/no, 2) respuesta numérica, 3) reí puesta con escala de valoración (subjetiva), 4) escala de Likert (por ejemplo, corpletamente de acuerdo, un poco de acuerdo), 5) respuesta con porcentajes (subje: va) o 6) respuesta abierta. Si se desean datos cuantitativos, puede aplicarse una forma de análisis de es: dio del tiempo. Se observa a los usuarios durante la interacción y se usan los da::-; (como el número de tareas completadas correctamente en un periodo estándar, fre cuencia y secuencia de acciones, tiempo que pasa "mirando" la pantalla, númer tipo de errores, tiempo de recuperación de errores, tiempo dedicado al uso de la a; da y cantidad de referencias de ayuda por periodo estándar) como guía para la dificación d e la interfaz. Un análisis completo de los métodos de evaluación de la interfaz de usuario : basa el alcance de este libro. Se puede consultar más información en [LEA&íi] [MAN97] y [HAC98J.

TM

PDF Editor

Es posible afirmar que la interfaz de usuario es el elemento m á s importante de sistema o producto de cómputo. Si la interfaz está mal diseñada la capacidad usuario se verá muy reducida para aprovechar las ventajas de una aplicación efecto, una interfaz débil puede llevar al fracaso una aplicación bien diseñada y < una implementación sólida.

CAPÍTULO 12


379

Tres principios importantes guían el diseño de una interfaz de usuario efectiva: 1) dar ei control al usuario, 2) reducir la carga en la memoria del usuario, y 3) lograr que la interfaz sea consistente. Construir una interfaz que cumpla con estos principios requiere desarrollar un proceso de diseño organizado. El diseño de la interfaz de usuario comienza con una serie de tareas de análisis. Entre éstas se encuentra identificación del usuario, tarea y análisis y modificación de la tarea y el entorno. El análisis del usuario define los perfiles de varios usuarios finales y aplica información recopilada de diferentes fuentes de negocios y técnicas. El análisis de tareas define las tareas y acciones del usuario empleando un enfoque elaborativo u orientado a objetos, aplicando casos de uso, elaboración de tareas y objetos, análisis de flujo de trabajo y representaciones jerárquicas de tareas para comprender plenamente la interacción ser humano-computadora. El análisis ambiental identifica las estructuras física y social en que debe operar la interfaz. Una vez identificadas las tareas, se crean y analizan los escenarios para definir un conjunto de objetos y acciones de la interfaz. Esto proporciona la base para la creación del formato de pantalla, que representa el diseño gráfico y la ubicación de los iconos, la definición de un texto descriptivo en pantalla, la especificación de las ventanas y la asignación de títulos a éstas, a d e m á s de la especificación de los elementos primarios y secundarios del menú. Mientras se refina el modelo de diseño, deben tomarse en cuenta temas relacionados con el diseño, c o m o tiempo de respuesta, estructura de comandos y acciones, manejo de errores y funciones de ayuda. El usuario dispone de varias herramientas de implementación para construir un prototipo que él mismo puede evaluar.

IAPP031 Apple Computer, Pcople with Special Needs, 2003, disponible en http://www.apple.com/ disability/. [BAR01] Borchers,)., A Pattern Approach to Interaction Design, Wiley 2001. [CON95] Constantine, L. "What DO Users Want? Engineering Usability in Software", en Windows Tech joumal, diciembre de 1995, disponible en http://www.forUse.com. 1DON99J Donahue, G., S. Weinschenck y J. Nowicki, "Usability is Good Business", Compuware Corp., julio de 1999, disponible en http://www.compuware.com. [DUY021 vanDuyne, D., J. Landay y J. Hong, The design of Sites, Addison-Wesley, 2002. [HAC98] Hackos, J. y J. Redish, User and Task Analysis for Interface Design, Wiley, 1998. [1BM03] IBM, Overview ofSoftware Glohalization, 2003, disponible en http://oss.software.ibm.com /icu/userguide/118n.html. [LEA88] Lea, M., "Evaluating User Interfaces Designs", en User Interface Design for Computer TM Systems, Halstead Press (Wiley), 1988. [MAN97| Mandel, T„ The Elements of User Interface Design, Wiley, 1997. IMIC03] Microsoft Accesability Technology for Eveiyone, 2003, disponible en h t t : / / w w w . m i c r o sofl.com/enable/. [MON84] Monk, A. (ed), Fundamentáis of Human Computer Interaction, Academic Press, 1984. [MOR811 Moran, T. P., "The Command Language Grammar: A Representation for the User Interface of Interactive Computer Systems", en Intl Joumal of Man-Machine Studies, vol. 15, pp. 3-50. [NIEOO] Nielsen, Designing Web Usability, New Riders Publishing, 2000. [NOR86| Norman, D. A., "Cognitive Engineering en User Centered Systems Design, Lawrence Earlbaum Associates, 1986.

PDF Editor

380

PARTE DOS


[RUB88] Rubin, T.. User Interface Design for Computer Systems, Haldstead Press (Wiley), 1988. [SHN90] Shneiderman, B.. Designing the User Interface, Addison-Wesley, 3a. ed., 1990. [TID991 Tidwell,)., "Common Ground A Pattern Language for HC1 Design ", disponible er http://www.mit.edU/@jtidwell/interaction_pattems.html, mayo de 1999. [TID02] T i d w e l l , " I U Patterns and Techniques", disponible en http://time.tripper.com/uip.; terns/index.html, mayo de 2002. [UN103] Unicode Inc., The Unicode Home Page, 2003, disponible en http://www.unicode.org IW3C031 World Wide Web Consortium, Web Contení Accesability Guidelines, 2003, disponible e r http://www.w3.org/TR/2003/Word-WCAG20-20030624/. [WEL01] vanWelle M., 'Interaction Design Patterns", disponible en http://www.welie.com/pi t e m s / , 2001.

1 2 . 1 . Describir la mejor y la peor interfaz con que se haya trabajado alguna vez y critiquer - en relación con los conceptos presentados en este capítulo. 12.2. Desarrollar dos principios de diseño adicionales que "den el control al usuario". 12.3. Desarrollar dos principios de diseño adicionales que "reduzcan la carga en la m e m o r del usuario". 1 2 . 4 . Desarrollar dos principios de diseño adicionales que "logren una interfaz consisten:-. 12.5. Se ha pedido desarrollar un sistema de banco en casa para Web; desarrollar los mode -i del usuario, del diseño y mental y la implementación. 1 2 . 6 . Realizar u n análisis detallado de tareas para el sistema del problema 12.5. Utilizar enfoque elaborativo u orientado a objetos. 1 2 . 7 . Agregar por lo m e n o s cinco preguntas adicionales a la lista desarrollada para el a n á S s a de contenido de la sección 12.3.5. 12.8. Siguiendo con el problema 12.6, definir objetos y acciones de interfaz para la a p l i c a o \ Identificar cada tipo de objetos. 12.9. Desarrollar un conjunto de formatos de pantalla con una definición de elementos prir. pales y secundarios del menú para el sistema del problema 12.5. 12.10. Desarrollar un conjunto de formatos de pantalla con una definición de los elemer principales y secundarios del menú para el sistema HogarSeguro. Es posible aplicar un enfoque (fcerente del que se muestra para el formato de pantalla en la figura 15.3. 1 2 . 1 1 . Describir un enfoque propio de las funciones de ayuda del usuario para el análisis tareas que se hayan realizado como parte del problema 12.5. 12.12. Proporcionar algunos ejemplos que ilustren por qué debe tomarse en cuenta la v a r - a j bilidad del tiempo de respuesta. 12.13. Desarrollar un e n f o q u e que integre a u t o m á t i c a m e n t e los m e n s a j e s de error y i función de ayuda para el usuario. Es decir, que el sistema reconozca automáticamente el l de error y proporcione una ventana de ayuda con sugerencias para corregirlo. Realizar un < ño de software razonablemente completo que tome en cuenta las estructuras de datos y 1 goritmos apropiados.

TM

12.14. Desarrollar un cuestionario de evaluación de interfaces que contenga 20 pregur genéricas aplicables a la mayor parte de las interfaces. Pídase que 10 c o m p a ñ e r o s de cfc completen el cuestionario para un sistema interactivo que todos usen. Resumir los resultadc informar de ellos a su clase.

PDF Editor

Aunque su libro n o se relaciona específicamente con interfaces ser humano-computadora, cho de lo que Donald Norman (The Design o/Eveiyday Things, edición reimpresa, Currency/C

CAPÍTULO 12

381


bleday, 1990) tiene que decir sobre la psicología de un diseño efectivo se aplicará a las interfaces de usuario. Es una lectura recomendada para cualquier persona que tome con seriedad el diseño de interfaces de alia calidad. Las interfaces gráficas del usuario son ubicuas en el mundo moderno de la computación. Ya sea empleada por un cajero automático, un teléfono móvil, una PDA, un sitio Web o una aplicación de negocios, la interfaz de usuario proporciona una ventana al software. Por ello, abundan los libros sobre el diseño de interfaces. Todos los siguientes libros tratan sobre facilidad de uso, conceptos de interfaz de usuario, principios y técnicas de diseño, además de que contienen muchos ejemplos útiles: Galitz (The Essential Guide to User interface Design, Wiley, 2002), Cooper (About Face 2.0: The Essentials of User Interface Design, 1DG Books, 2003), Beyer y Holtzblatt (Contextual Design: A Costumer Centered Approach to Systems Design, Morgan-Kaufmann, 2002), Raskin (The Human Interface, Addison-Wesley, 2000), Constantine y Lockwood (Softwarefor Use, ACM Press, 1999) y Mayhew (The Usability Engineering Ufecyctc, Morgan-Kaufmann, 1999). Johnson (GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers, MorganKaufmann, 2000) proporciona una guía útil para quienes aprenden mejor al examinar contraejemplos. Un libro que se disfruta, de Cooper (The Inmates Are Running the Asylum, Sams Publishing, 1999), analiza por qué los productos de alta tecnología nos atraen y la manera de diseñar unos que no lo hagan. El análisis y modelado de tareas son actividades fundamentales del diseño de interfaces. Hackos y Redish [HAC98] han escrito un libro dedicado a estos temas y proporcionan un método detallado para concentrarse en el análisis de tareas. Wood (User Interface Design: Bridging the Gap from User Requirements to Design, CRC Press, 1997) aborda la actividad de análisis para interfaces y la transición a las tareas de diseño. La actividad de evaluación se concentra en la facilidad de uso. Los libros de Rubin (Handbook of Usability Testing; How to Plan, Design, and Conduct Effective Tests, Wiley, 1994) y Nielsen (Usability Inspection Methods, Wiley, 1994) abordan el tema con gran detalle. En un libro único, que podría parecer muy interesante a los diseñadores de producto, Murphy (Front Panel: Designing Softwarefor Embedded User Interfaces, R&D Books, 1998) ofrece una guía detallada para el diseño de interfaces destinadas a sistemas incrustados y aborda los peligros de seguridad inherentes a los controles, el manejo de maquinaria pesada y las inlerfaces para sistemas médicos o de transporte. El diseño de la interfaz para productos incrustados también se estudia en el libro de Garrett (Advanced Instrumentation and Computer l/O Design: Real-Time System Computer Interface Engineering, IEEE, 1994). En Internet se encuentra una amplia variedad de fuentes de información sobre el diseño de la interfaz de usuario. Una lista actualizada de referencias en la World Wide Web relevantes para el diseño de la interfaz de usuario se encuentra en el sitio Web SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P Í T U L O

L

13

CONCEPTOS CLAVE criterios de finalización . . . . 3 8 9 depuración . . . . 4 0 9 especificación de prueba

.401

estrategia convencional.. .386 estrategia orientada a objetas GIP

..402 .386

E S T R A T E G I A S DE P R U E B A DEL S O F T W A R E

U

n a e s t r a t e g i a d e p r u e b a del s o f t w a r e i n t e g r a los m é t o d o s d e d i s e ñ o c : c a s o de p r u e b a s del s o f t w a r e e n u n a serie bien p l a n e a d a de p a s o s q u e d : s e m b o c a r á e n la e f i c a z c o n s t r u c c i ó n d e s o f t w a r e . La e s t r a t e g i a propc

c i o n a u n m a p a q u e d e s c r i b e l o s p a s o s q u e se d a r á n c o m o p a r t e d e la p r u e t indica c u á n d o s e p l a n e a n y c u á n d o s e d a n e s t o s p a s o s , a d e m á s d e c u á n t o ef u e r z o , t i e m p o y r e c u r s o s c o n s u m i r á n . Por t a n t o , c u a l q u i e r e s t r a t e g i a d e p r u e r d e b e i n c o r p o r a r la p l a n e a c i ó n de p r u e b a s , el d i s e ñ o d e c a s o d e p r u e b a s , l a eje c u c i ó n d e p r u e b a s y la r e c o l e c c i ó n y e v a l u a c i ó n de los d a t o s r e s u l t a n t e s . Una e s t r a t e g i a de p r u e b a del s o f t w a r e d e b e ser lo s u f i c i e n t e m e n t e flexit :• c o m o p a r a p r o m o v e r u n e n f o q u e p e r s o n a l i z a d o . Al m i s m o t i e m p o , d e b e ser a d e c u a d a m e n t e rígido c o m o p a r a p r o m o v e r u n a p l a n e a c i ó n r a z o n a b l e y L-I s e g u i m i e n t o a d m i n i s t r a t i v o del a v a n c e del p r o y e c t o . S h o o m a n [SH083] ana! estos temas:

prueba d e humo

..399

En muchos sentidos, la prueba es un proceso autónomo, y el número de tipos dife-

prueba de integración . . . . 3 9 4

rentes de pruebas varia tanto como los diferentes enfoques de desarrollo. Durante

prueba de regresión . . . . . 3 9 8

cuidadoso y la inteligencia natural del programador. Ahora estamos en la era en que

prueba de unidad . . . . . . 3 9 2

ayudando a reducir el número de errores iniciales inherentes al código. De manera si-

prueba de validación . . . . . 4 0 4

y filosofías distintos.

prueba del sistema . . . . . . 4 0 6 pruebas a l f a /

muchos años, la única defensa contra los errores de programación fueron el diseño las técnicas modernas de diseño (y las revisiones de las técnicas formales] nos estar, milar, diferentes métodos de prueba están empezando a apilarse en varios métodos Es t o s " e n f o q u e s y filosofías" c o n f o r m a n lo q u e s e d e n o m i n a e s t r a t e g i a . En rl c a p í t u l o 14 s e p r e s e n t a r á la t e c n o l o g í a de p r u e b a del s o f t w a r e . Ese c a p í t u l o s: c o n c e n t r a r á e n la e s t r a t e g i a d e la p r u e b a d e l s o f t w a r e .

..405 VyV

..384

¿Qué es?

El software se prueba para descubrir errores cometidos sin darse cuenta al realizar su diseño y construcción. ¿Pero cómo se realizan las pruebas? ¿Debe desarrollarse un plan formal para las pruebas? ¿Debe probarse el programa como un todo o s ó b deben aplicarse pruebas a una parte pequeña? ¿Deben volver a realizarse las pruebas ejecutadas a medida que se agregan nuevos componentes a un sistema de gran tamaño? ¿Cuándo d e b e pedirse la par-

ticipación del cliente? Éstas y muchas otras preguntas se responderán cuando desarrolle una estrategia de prueba del software. TM ¿ Q u i é n lo h a c e ? El ¡efe de proyecto, los ingenieros de software o b s especialistas en pruebe; son quienes desarrollan la estrategia p a r a le prueba del software. ¿ P o r q u é e s i m p o r t a n t e ? Con frecuencia, b prueba requiere una mayor cantidad del esfue zo dedicado al proyecto que cualquier otra act vidad de ingeniería del software. Si se realizc

PDF Editor 3*2

CAPÍTULO 13


n un plan, se desperdicia tiempo, se dedica un esfuerzo innecesario y, aún peor, es posible que no se detecten errores. Por tanto, lo razonable sería establecer una estrategia sistemática p a r a o-obar el software.

"les s o n l o s p a s o s ? La prueba empieza oor lo "pequeño" y avanzo hacia lo "grande". Esto significa que, en las primeras etapas, la : -ueba se concentra en un s o b componente o TT un grupo pequeño de componentes relacio- xlos y se aplica p a r a descubrir errores en la :gica de datos y del procesamiento que se ha encapsulado en el componente. Una vez proba: 3S los componentes, deben integrarse hasta : je todo el sistema se haya construido. En este : jnto se ejecuta una serie de pruebas de alto ni-«I para descubrir errores en la satisfacción de e s requisitos del cliente. A medida que se des-

13.1

383

cubren. los errores deben diagnosticarse y corregirse empleando un proceso llamado depuración.

¿Cuál e s el p r o d u c t o o b t e n i d o ? Una Especificación de la prueba documenta el enfoque que aplicó el equipo de software a la prueba al definir un plan que detalla una estrategia general y un procedimiento que describe los pasos específicos que se darán y las pruebas que h a b r á n de realizarse. ¿ C ó m o p u e d o estar s e g u r o d e q u e lo h e h e c h o c o r r e c t a m e n t e ? Al revisar la Especificación de la prueba antes de realizarla se evalúa s¡ están completos los casos y las tareas de prueba. Un plan y un procedimiento de prueba efectivos llevarán a la construcción ordenada del software y al descubrimiento de errores en c a d a etapa del proceso de construcción.

U N E N F O Q U E E S T R A T É G I C O P A R A LA P R U E B A DEL S Q F T W A P F . La prueba es un conjunto de actividades que se planean con anticipación y se realizan de m a n e r a sistemática. Por tanto, se d e b e definir una plantilla para las pruebas del software (un conjunto de p a s o s e n que se puedan incluir técnicas y m é t o d o s específicos del diseño de c a s o s de prueba). Se han propuesto varias estrategias de prueba del s o f t w a r e en distintos libros; todas proporcionan al desarrollador del software una plantilla para p r u e b a s y t o d a s tienen las siguientes características genéricas: • Para realizar p r u e b a s efectivas un equipo de software d e b e efectuar revi-

sitio «entrarán s para lo i aturare: ".edu/

siones técnicas formales y efectivas (capítulo 26). Esto eliminará m u c h o s errores a n t e s de que e m p i e c e la prueba. • La prueba c o m i e n z a al nivel de c o m p o n e n t e s y trabaja "hacia fuera", hacia la integración de t o d o el sistema de cómputo. • Diferentes técnicas de prueba son a p r o p i a d a s en diferentes m o m e n t o s . TM • La prueba la dirige el desarrollador del s o f t w a r e y (en el c a s o de proyectos grandes) un grupo independiente de pruebas.

PDF Editor

• La prueba y la depuración son actividades diferentes, p e r o la s e g u n d a debe incluirse en cualquier estrategia de prueba.

Una estrategia para la prueba del software d e b e incluir p r u e b a s de bajo nivel (nece-

sarias para confirmar la correcta implementación de un p e q u e ñ o s e g m e n t o de código fuente) y de alto nivel (que validen las principales funciones del sistema a partir

384

PARTE DOS


de los requisitos del cliente). Una estrategia debe servir c o m o guía para el p r o í e s • nal y fijar un conjunto de guías para el jefe de proyecto. Debido a que los pasos | " la estrategia de prueba son simultáneos, c u a n d o e m p i e z a a a u m e n t a r la presicr :< las fechas límite debe tenerse la opción de medir los a v a n c e s y buscar que los : r j b l e m a s a p a r e z c a n lo a n t e s posible.

13.1.1 Verificación y validación La prueba del software es un e l e m e n t o de un tema m á s amplio que suele der n a r s e verificación y validación (VyV). Verificación es el c o n j u n t o de actividades - J J a s e g u r a n que el s o f t w a r e implemente c o r r e c t a m e n t e u n a función e s p e :

ai

Validación es un conjunto diferente de actividades que aseguran que el construido corresponde con los requisitos del cliente. 1 Boehm [BOE81] lo e s t a r - ^ de otra manera: Verificación: "¿Estamos construyendo el producto correctamente?" Validación: "¿Estamos construyendo el producto correcto?" La definición de VyV abarca m u c h a s de las actividades incluidas en el aseg sgura i M to de la calidad del software y se analiza de m a n e r a detallada en el capítulo. tulo 2c La verificación y la validación a b a r c a n u n a amplia lista de actividades de a f o ^CONSEJO^. No se deben tener descuidos ni considerar que las pruebas son una "red de segundad" que atropará lodos los errores que ocurron debido a la aplicación de prácticas débiles de software. No lo son. Debe ponetse especio! cuidado en la calidad y detección de errores en todo el proceso de la ingeniería del software.

ramiento de la calidad del software: revisiones técnicas formales, auditorías de . d dad y de configuración, monitoreo del d e s e m p e ñ o , simulación, factibilidad, r e - . a j de la documentación y la b a s e de datos, análisis de algoritmos, p r u e b a s de lio, de facilidad de uso, calificación y de instalación [WAL89]. Aunque las activkál de prueba tienen un papel d e m a s i a d o importante e n VyV, también se ne m u c h a s otras actividades. "Probar es la parte inevitable de cualquier esfuerzo responsable por desarrollar un sistemo de software." William I Las p r u e b a s s o n el último bastión para la evaluación de la calidad y, de n - . a i M m á s pragmática, el descubrimiento de errores. Pero las p r u e b a s no deben cor rarse c o m o u n a "red de seguridad". Como suele decirse: "No es posible probar la J dad. Si n o está ahí a n t e s de que empiece la prueba, no estará c u á n d o se ter La calidad se incorpora al s o f t w a r e e n todo el p r o c e s o de ingeniería. La aplic TM apropiada de m é t o d o s y herramientas, las revisiones técnicas formales y efe

PDF Editor

Debe indicarse que hay una fuerte divergencia de opinión acerca de los tipos de prueba que c tuyen una "validación". Algunas personas creen que toda prueba es una verificación, y que L= dación se realiza cuando el usuario revisa y aprueba los requisitos, y más delante, cuando el • está en condiciones de operar. Otras personas consideran que la prueba de la unidad y la i ción (secciones 13.3.1 y 13.3.2) constituyen la verificación y que las pruebas de alto nivel (a das más adelante en este capitulo) son la validación.

CAPÍTULO 13

385


junto con una administración y u n a medición sólidas aportan la calidad, que s e c o n firma durante las pruebas. Miller [MIL77] relaciona la prueba del software con el a s e g u r a m i e n t o de la calidad al afirmar: "lo que motiva la prueba de los p r o g r a m a s e s la confirmación de la calidad del s o f t w a r e con m é t o d o s que se p u e d a n aplicar de m a n e r a e c o n ó m i c a y efectiva en sistemas g r a n d e s y pequeños".

13.1.2 Organización p a r a las pruebas del software En cualquier proyecto de s o f t w a r e se p r e s e n t a un conflicto de intereses c u a n d o c o m i e n z a n las pruebas. Ahora se pide a las p e r s o n a s que han construido el software que lo prueben. En sí, e s t o parece inofensivo; d e s p u é s de todo, ¿quién c o n o c e mejor un p r o g r a m a que la persona que lo desarrolló? Por desgracia, a e s o s m i s m o s desarrolladores les interesa m u c h o d e m o s t r a r que el programa está libre de errores, que funciona de a c u e r d o con los requisitos del cliente y que se completará a tiempo y sin rebasar el presupuesto. Cada uno de e s t o s intereses mina las b o n d a d e s de la prueba. " 0 optimismo es el peligro oíupacionol de lo programación; la prueba, el tratamiento." Kent Beck Desde un p u n t o de vista psicológico, el análisis y el diseño del software (junto con la codificación) son t a r e a s constructivas. El ingeniero del s o f t w a r e analiza, modela y luego crea un programa de computadora, junto con su documentación. C o m o cualquier constructor, el ingeniero del s o f t w a r e se sentirá orgulloso del edificio que acaba de construir y mirará con recelo a cualquiera que pretenda echarlo abajo. C u a n d o c o m i e n z a la prueba hay un intento sutil, p e r o definitivo, de "romper" lo que ha construido el ingeniero del software. Al p o n e r s e en los z a p a t o s del constructor la prueba parecerá (psicológicamente) destructiva. De m o d o q u e el constructor actuará con cuidado, d i s e ñ a n d o y ejecutando p r u e b a s que d e m o s t r a r á n el buen funcionamiento del p r o g r a m a e n lugar de descubrir errores. Por desgracia, los errores seguirán presentes. Y si el ingeniero del software n o los encuentra, ¡el cliente sí lo hará! De las consideraciones precedentes suelen inferirse e r r ó n e a m e n t e varias m a l a s interpretaciones: 1) que el responsable del desarrollo n o debería participar en el proc e s o de prueba, 2) q u e el s o f t w a r e d e b e p o n e r s e a salvo de extraños que lo prueben sin misericordia, y 3) que q u i e n e s aplican las p r u e b a s sólo deben participar en el pro-

C&VE ppo te de no tiene el de " que ntan los zrsfiuctores del

yecto c u a n d o vayan a darse los primeros p a s o s de e s a s pruebas. TM Todas e s t a s afirm a c i o n e s son incorrectas. El desarrollador del s o f t w a r e siempre será el responsable de probar las unidades

PDF Editor

individuales (componentes) del programa y a s e g u r a r que cada una realice la función

o muestre el c o m p o r t a m i e n t o para el que se diseñó. En m u c h o s casos, el desarrollador también aplica la prueba de integración (un p a s o que lleva a la construcción,

y la prueba, de toda la arquitectura del software- Sólo d e s p u é s de que la arquitectura del s o f t w a r e esté completa participará u n grupo independiente de prueba.

386

ÔNSEJO^ Si no existe un GIP dentro de una orgonizoción, tendrá que odoptorse su punto de visto propio. Al aplicar lo pruebo se debe trotar de destruir el software.

PARTE DOS


El papel de u n grupo independiente

de prueba (GIP) consiste en eliminar los p ' :

blemas propios de dejar que el constructor pruebe lo que él m i s m o ha constru : La prueba i n d e p e n d i e n t e elimina el conflicto de intereses que, de otra m a n e r a , e>.- J ría presente. Después de todo, al personal del GIP se le p a g a p a r a que e n c u e errores.

-

Sin embargo, el ingeniero del s o f t w a r e n o d e b e simplemente entregar el p r ó j i ma al GIP y alejarse. El desarrollador y el GIP deben trabajar unidos en todo el pr:yecto de software para asegurar la realización de p r u e b a s exhaustivas. Mier

.

é s t a s se realizan, el desarrollador debe estar disponible para corregir los errores r—r se descubran. ' El primer error que comete lo gente es pensor que el equipo de pruebos es responsable de asegurar Brian M a r í a

El GIP es parte del equipo del proyecto de desarrollo del software, ya que par>_ • pa en el análisis y diseño y a d e m á s sigue participando (al planear y especificar : cedimientos de prueba) e n todos los p a s o s de un proyecto grande. Sin e m b a r g :

-j

m u c h o s c a s o s el GIP informa a la organización de a s e g u r a m i e n t o de calidad de! > £•] ware, p o r lo que obtiene un grado de independencia que sería imposible si parte de la organización e n c a r g a d a de la ingeniería del software.

13.1.3. Estrategia de prueba p a r a arquitecturas convencionales del software Seria factible considerar que el proceso de ingeniería del s o f t w a r e es equiparar la espiral que se ilustra en la figura 13. i. Al principio, la ingeniería del sistema ne el papel del software y lleva al análisis de los requisitos de éste, d o n d e se e s a - l blecen el dominio de información, la función, el comportamiento, el desempeñe

,: |

restricciones y los criterios de validación del software. Al d e s p l a z a r s e hacia el r J rior de la espiral se llega al diseño y, por último, a la codificación. El desarroik • s o f t w a r e de c o m p u t a d o r a requiere recorrer la espiral hacia dentro, a lo largo de . n a línea bien definida que disminuye el grado de abstracción tras cada vuelta. ¿Cuál es ID • estrategia general para la prueba del software?

También es posible ver u n a estrategia para la prueba del s o f t w a r e en el c o n t a l de la espiral (figura 13.1). La prueba de unidad c o m i e n z a en el vértice de la esp: se c o n c e n t r a en cada unidad (componente) del software, tal c o m o se implemen:: • el código fuente. La prueba a v a n z a al desplazarse hacia fuera, a lo largo de la e s a l TM y la con i J ral, h a s t a llegar a la prueba de integración, d o n d e s e atiende el diseño ción de la arquitectura del software. Si se recorre otra vuelta hacia fuera en la e s * ral, se encuentra la prueba de validación, d o n d e se validan los requisitos establee. J

PDF Editor

c o m o parte del análisis de requisitos del software, c o m p a r á n d o l o s con el sofhi » que se ha construido. Por último, se llega a la prueba del sistema, d o n d e se p r u e : » c o m o un t o d o el s o f t w a r e y otros e l e m e n t o s del sistema. El s o f t w a r e de c o m p u t a a B ra se prueba recorriendo la espiral hacia fuera, por una línea bien definida, de que en cada vuelta s e e n s a n c h a el alcance de la prueba.

CAPÍTULO 13

387


Si se considera el proceso d e s d e un p u n t o de vista procedimental, en realidad la sitio cxfforcn I i r t e paro rsean

el

prueba d e n t r o del contexto de la ingeniería del software consiste en una serie de cuatro p a s o s q u e se implementan de m a n e r a secuencial. Esos p a s o s se m u e s t r a n en la figura 13.2. Al principio, la prueba se concentra en cada c o m p o n e n t e individual, a s e g u r a n d o que funciona de m a n e r a apropiada c o m o unidad (por ello se le denomina prueba de unidad). La prueba de unidad emplea en forma recurrente las técnicas de prueba que recorren c a m i n o s específicos en u n a estructura de control del componente, lo que asegura una cobertura completa y u n a detección máxima de errores. Enseguida deben e n s a m b l a r s e o integrarse los c o m p o n e n t e s para formar el p a q u e t e de s o f t w a r e completo. La prueba de integración atiende todos los a s p e c t o s asociados con el doble problema de verificación y construcción del programa. Las técnicas de d i s e ñ o de c a s o s de prueba que se concentran en e n t r a d a s y salidas son

rueba del sistema

a de

de unidad Código Diseño Requisitos Ingeniería del sistema

déla del are.

Requisitos

Pruebas de alto nivel

Diseño

TM

PDF Editor Código

"Dirección" de la prueba

388

PARTE DOS


m á s d o m i n a n t e s durante la integración, a u n q u e podrían u s a r s e técnicas que re::-rren r u t a s específicas del p r o g r a m a p a r a a s e g u r a r la cobertura de los principa e s ; c a m i n o s de control. Después de que se h a integrado (construido) el s o f t w a r e se a r : - j ca un c o n j u n t o de p r u e b a s de alto nivel. Se deben evaluar los criterios de valida: od establecidos d u r a n t e el análisis de requisitos. La prueba de validación p r o p o r c un a s e g u r a m i e n t o final de que el s o f t w a r e cumple con t o d o s los requisitos fúrr>:-nales, de c o m p o r t a m i e n t o y d e s e m p e ñ o . El último p a s o de la prueba de alto nivel queda fuera de los límites de la ingentr -I ría del software, p e r o dentro de u n contexto m á s amplio de la ingeniería de los s s J t e m a s de cómputo. El software, u n a vez validado, d e b e combinarse con otros s e m e n t o s del sistema (por ejemplo, hardware, personas, b a s e s de datos). La prueba a d j sistema verifica que t o d o s los e l e m e n t o s e n c a j e n a p r o p i a d a m e n t e y que se log-t • función y el d e s e m p e ñ o generales del sistema.

13.1.4 Estrategia de prueba del software para arquitecturas orientadas a objetos La prueba de sistemas orientados a objetos plantea u n conjunto diferente de d

! •

al ingeniero del software. La definición de prueba d e b e ampliarse para incluir t e r J cas de descubrimiento de errores (por ejemplo, revisiones técnicas formales) que a

\ CLAVE

aplican para analizar y diseñar modelos. El g r a d o al que se han completado y la : y*U

Como los pruebos convencionoles, los orientodos o objetos empiezon por lo "pequeño". Sin emborgo, en casi todos los cosos, el elemento más pequeño probado es una clase o un paquete de doses que colaboran entre sí.

se construyen. La prueba de unidad pierde parte de su significado, y las e s t r a t r r a i

sistencia de las representaciones o r i e n t a d a s a objetos deben evaluarse a medida aufl de integración cambian de m a n e r a importante. En r e s u m e n , las estrategias y laí j c i ticas de prueba (capítulo 14) deben ser responsables de las características únicas J software orientado a objetos. La estrategia general para el s o f t w a r e orientado a objetos tiene u n a filosofía i j a l tica a la que se aplica a las arquitecturas convencionales, p e r o p r e s e n t a diferer : jm en el enfoque. Se e m p i e z a "probando lo pequeño" y se trabaja hacia el exterior b a n d o lo grande". Sin embargo, la atención cambia c u a n d o la prueba es p e q u e r a u n módulo individual (el concepto convencional) a u n a clase que abarca a t r ü x s a operaciones y que, a d e m á s , requiere comunicación y colaboración. A medida r i

HOGARSEGURO Preparación

para

la prueba

la escena: Oficina de Doug Miller, mientras continúa el diseño al nivel de componentes y empieza la construcción de ciertos componentes.

TM La conversación:

PDF Editor Los actores: Doug Miller, jefe de ingeniería del software; Vinod, Jamie, Ed y Shakira, integrantes del equipo de ingeniería del software de HogarSeguro.

Doug: Me parece que no hemos dedicado el tiempo suficiente a hablar de las pruebas. Vinod: Tienes razón, pero todos hemos estado un atareados. Y además hemos pensado en ello..- en realidad, hemos hecho más que pensarlo.

CAPITULO 13


(sonriendo): Lo sé... tenemos exceso de -. pero aún tenemos que pensar en las cosas -tes. " • * Me gusta la idea de diseñar pruebas de antes de empezar a codificar cualquiera de los ntes, de modo que eso es lo que hemos tratado . Tengo un enorme archivo de pruebas que ejecutar una vez que esté completo el código de componentes. "se es el concepto de Programación Extrema (un ágil de desarrollo de software visto en el capítulo jno? Asi es. Aunque no estamos usando, en sí, la ación Extremo, decidimos que sería una buena diseñar pruebas de unidad antes de construir el i (el diseño nos da toda ia información que os). ' Gil

389

Jamie: Yo he estado haciendo lo mismo. Vinod: Y he tomado el papel de integrador, de modo que cada vez que uno de los muchachos me pase un componente, lo integraré y ejecutaré una serie de pruebas de regresión en el programa parcialmente integrado. He estado trabajando para diseñar un conjunto de pruebas apropiado para cada función del sistema. Doug (a Vinod): ¿Con cuánta frecuencia ejecutarás las pruebas? Vinod: Todos los días... hasta que se integre bien el sistema. O sea, hasta que los incrementos de software que planeamos entregar queden integrados. Doug: ¡Muchachos, van adelante de mí! Vinod (sonriendo): La anticipación lo es todo en el negocio del software, jefe.

integran clases dentro de u n a arquitectura orientada a objetos, se ejecuta una serie de p r u e b a s de regresión para descubrir errores debidos a la comunicación y colaboración e n t r e clases (componentes) y a los efectos colaterales q u e origina la adición de n u e v a s clases (componentes). Por último, se prueba el sistema c o m o un todo para asegurarse de que se descubran errores en los requisitos.

13.1.5 Criterios p a r a completar la prueba Cada vez que se analizan las pruebas del s o f t w a r e surge u n a pregunta clásica: ¿cuándo h e m o s terminado las p r u e b a s (cómo s a b e m o s que h e m o s p r o b a d o lo suficiente)? Lo lamentable es que n o hay una respuesta definitiva, sino que hay algunas r e s p u e s t a s p r a g m á t i c a s y algunos intentos iniciales de s e n t a r una guía empírica. Una respuesta a la pregunta es: "nunca se termina de aplicar una prueba; la carga s i mp l e m e n t e se desplaza de usted (el ingeniero del software) a su cliente. Cada vez que el cliente, el usuario, o a m b o s , ejecutan un p r o g r a m a de computadora, éste se está probando. Este hecho incuestionable subraya la importancia de otras actividad e s del a s e g u r a m i e n t o de la calidad del software. Otra respuesta (un poco cínica, pero correcta) es: "la prueba se termina c u a n d o se agota el tiempo o el dinero".

TM Aunque algunos usarán esta respuesta c o m o a r g u m e n t o , un ingeniero del soft-

w a r e necesita criterios m á s rigurosos para determinar que las pruebas han sido sufi-

PDF Editor

cientes. Musa y Ackerman [MUS89j sugieren u n a respuesta b a s a d a en criterios e s t a dísticos: "No, n o p o d e m o s estar c o m p l e t a m e n t e seguros de que el s o f t w a r e nunca fallará, p e r o de a c u e r d o con un modelo estadístico teóricamente sólido y validado en forma experimental, h e m o s realizado las p r u e b a s suficientes c o m o para afirmar, con

u n a confianza del 95%, que las probabilidades de tener mil h o r a s de o p e r a c i o n e s del

390

PARTE DOS


CPU libres de fallas en u n e n t o r n o definido de forma probabilística es p o r lo m e n a d e 0.995." Empleando el m o d e l a d o estadístico y la teoría de la confiabilidad del w a r e , pueden desarrollarse modelos de fallas del s o f t w a r e (descubiertas durante ante m a prueba) c o m o u n a función del tiempo de ejecución (por ejemplo, consú; súteJ [MUS89], [SIN99] O [IEE01]). Al recopilar métricas d u r a n t e la prueba del s o f t w a r e y usar modelos existentes la confiabilidad del software, es posible desarrollar directrices significativas para p o n d e r la pregunta: ¿Cuándo h e m o s terminado la prueba? Lo indiscutible e s que ¿ j a | falta m u c h o trabajo a n t e s de que p u e d a n establecerse reglas cuantitativas p a n 1 prueba, p e r o los enfoques empíricos existentes son considerablemente mejores OH la simple intuición.

13.2

ASPECTOS ESTRATÉGICOS Más adelante, en este mismo capítulo, se explorará u n a estrategia sistemática prueba del software. Pero hasta la mejor estrategia fallara si no atiende una se r e • aspectos predominantes. Tom Gilb [G1L95] argumenta que deben atenderse los sigireB tes temas, si se desea implementar con éxito una estrategia de prueba del software I

9 •

¿C«óles !

directrices

llevan o uno estrategia de prueba del

Especificar los requisitos del producto de manera cuantificable mucho antes ot empiecen las pruebas. Aunque el objetivo primordial de la prueba e s encontrar - - M res, una b u e n a estrategia de prueba también evalúa otras características de la c J dad, c o m o las opciones de llevarla a otra plataforma, a d e m á s de la facilidad de T J

software que

tenimiento y uso (capítulo 15). Esto debe especificarse de m a n e r a tal que p e r ^

tenga éxito?

medirlo p a r a que los resultados de la prueba n o resulten ambiguos. Establecer explícitamente

los objetivos de la prueba. Los objetivos específicos x m

prueba se deben establecer en términos cuantificables. Por ejemplo, dentro de! ~ m de prueba d e b e n establecerse la efectividad y la cobertura de la prueba, el t : s i J medio de falla, el costo de e n c o n t r a r y corregir defectos, la densidad o la f r e o - e i ™ de las fallas restantes, y las h o r a s de trabajo p o r prueba de regresión [GIL95]. Comprender cuáles son los usuarios del software y desarrollar un perfil pare M categoría de usuario. Los c a s o s de uso que describan el escenario de interacció" J cada clase de usuario reducen el e s f u e r z o general de prueba, ya que c o n c e n f a n B prueba en la utilización real del producto.

TM

Desarrollar un plan de prueba que destaque la "prueba de ciclo rápido". Gilb | G £ » recomienda que un equipo de ingeniería del s o f t w a r e "aprenda a probar en z i f l

PDF Editor

rápidos (2% del e s f u e r z o del proyecto) los i n c r e m e n t o s en el m e j o r a m i e n t o de a ifl

cionalidad, la calidad, o a m b a s , de m a n e r a que sean útiles para el cliente y se d a n probar en el campo". La retroalimentación que g e n e r a n e s t a s pruebas de s rápido se utiliza para controlar los grados de calidad y las correspondientes e s c ^ gias de prueba.

CAPÍTULO 13

391


• « • « ¡ a Web

Construir un software •'robusto" diseñado para probarse a sí mismo. El s o f t w a r e debe

b wwite sitio Mi ¿ «onlroró uno

diseñarse de m a n e r a tal q u e use técnicas antierror (sección 13.3.1). Es decir, el soft-

•fefeístode B e pora pruebes: MroJo.com/

——/V/.

w a r e debe tener la capacidad de diagnosticar ciertas clases de errores. Además, el diseño debe incluir pruebas a u t o m a t i z a d a s y de regresión. Usar revisiones técnicas formales y efectivas como filtro previo a la prueba. Las revisiones técnicas formales (capítulo 26) llegan a ser tan efectivas c o m o las p r u e b a s para descubrir errores. Por tanto, las revisiones reducen la cantidad de e s f u e r z o de prueba que se requiere para producir s o f t w a r e de alta calidad. Realizar revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Las revisiones técnicas formales posibilitan descubrir inconsistencias, omisiones y errores evidentes en el e n f o q u e de la prueba. Esto ahorra tiempo y también mejora la calidad del producto. Desarrollar un enfoque de mejora continua para el proceso de prueba. Es necesario medir la estrategia de prueba. Las medidas reunidas d u r a n t e la prueba deben usarse c o m o parte de un e n f o q u e estadístico de control del proceso para la prueba del software.

"Probar únicamente los requisitos del usuario final es como inspeccionar un edificio considerando únicamente el trabajo realizado por el diseñador de interiores, a costa de los cimientos, las vigas y la plomería." Boris Beizer

13.3

E S T R A T E G I A S D E P R U E B A P A R A EL S O F T W A R E C O N V E N C I O N A L En la prueba del s o f t w a r e es posible aplicar m u c h a s estrategias. En un extremo, un equipo de s o f t w a r e podría esperar hasta que el sistema e s t é totalmente construido y luego aplicar p r u e b a s al sistema general e s p e r a n d o e n c o n t r a r errores. Este enfoque, a u n q u e atractivo, s i m p l e m e n t e n o funciona. Arrojará un s o f t w a r e plagado de errores, molesto para el cliente y usuario final. En el otro extremo, un ingeniero de softw a r e podría aplicar p r u e b a s diariamente, sin importar la parte del sistema que se construya. Este enfoque, a u n q u e m e n o s atractivo para muchos, es m u y efectivo. Por desgracia, la mayoría de los desarrolladores de s o f t w a r e d u d a n en TM usarlo. ¿Qué hay que hacer? La estrategia de prueba que elige la mayor parte de los equipos de s o f t w a r e se

PDF Editor

ubica e n t r e estos dos extremos. Toma un e n f o q u e incremental de las pruebas; inicia

con la prueba de unidades individuales del programa, pasa a pruebas diseñadas para facilitar la integración de las unidades, y culmina con pruebas que realizan s o b r e el

sistema construido. En las siguientes secciones se e x p o n e cada una de e s t a s clases de prueba.

392

PARTE DOS

P R Á C T I C A DE L A I N G E N I E R Í A DEL S O F T W A R E

13.3.1 Prueba de unidad La prueba de unidad se concentra en el e s f u e r z o de verificación de la unidad mai p e q u e ñ a del diseño del software: el c o m p o n e n t e o m ó d u l o de software. T o m a n c : c o m o guía la descripción del diseño al nivel de c o m p o n e n t e s , se p r u e b a n importar t e s c a m i n o s de control para descubrir errores dentro de los límites del módulo. El alcance restringido que se ha d e t e r m i n a d o para las p r u e b a s de unidad limita la relativa complejidad de las pruebas y los errores que éstas descubren. Las pruebas de ur dad se concentran e n la lógica del procesamiento interno y en las estructuras de dat dentro de los límites de u n c o m p o n e n t e . Este tipo de prueba se p u e d e aplicar ea paralelo a varios c o m p o n e n t e s .

Consideraciones sobre la prueba de unidad. En la figura 13.3 se ilustran yt m a n e r a esquemática las pruebas que se aplican c o m o parte de la prueba de unidad. _J interfaz del módulo se prueba para asegurar que la información fluye apropiadamer hacia dentro y hacia fuera de la unidad de programa sujeta a prueba. Se examinan i estructuras de datos locales para asegurar que los datos temporales mantienen la ire; gridad durante todos los p a s o s de la ejecución de un algoritmo. Se recorren todos 1 c a m i n o s independientes (caminos de base) e n toda la estructura para a s e g u r a r que todas las instrucciones de u n m ó d u l o se hayan ejecutado por lo m e n o s u n a vez Se p r u e b a n las condiciones límite para asegurar que el módulo opera apropiadamer e n los limites establecidos para restringir el procesamiento. Y, por último, se prueb a n todos los c a m i n o s de m a n e j o de errores. 7

¿Cuáles

•

errores se

encuentran comúnmente

Es necesario probar el flujo de d a t o s en la interfaz del m ó d u l o a n t e s de inic^r cualquier otra prueba. Si los d a t o s n o entran ni salen apropiadamente, todas d e m á s p r u e b a s resultarán inútiles. Además, d u r a n t e la prueba de unidad deben rec >

durante la prueba

rrerse las estructuras de d a t o s locales y evaluarse (si es posible) el impacto loca

de unidad?

sobre los d a t o s globales. Durante la prueba de unidad, una tarea esencial es la prueba selectiva de las rutas ejecución. Se deben diseñar casos de prueba para descubrir errores debidos a cál incorrectos, c o m p a r a c i o n e s e r r ó n e a s o flujos de control inapropiados. Entre los e r

Prueba de unidad.

Interfaz Estructuras d e d a t o s locales Condiciones límite Rulos independientes Rutas d e manejo d e errores

TM

PDF Editor

CAPÍTULO 13

ESTRATEGIAS DE PRUEBA DEL S O m V A E E

393

res m á s comunes en los cálculos se encuentran los siguientes: 1) aplicación incorrecta o mal entendida de la precedencia aritmética, 2) operaciones de modo mezcladas, 3) inicialización incorrecta, 4) falta de precisión, y 5) representación simbólica incorrecta de una expresión. La comparación y el flujo de control están estrechamente acoplados entre sí (es decir, el flujo cambia con frecuencia después de una comparación). Los casos de prueba deben descubrir errores como: 1) comparaciones entre diferentes tipos de datos, 2) operadores lógicos o precedencia de éstos aplicados incorrectamente, 3) expectativa de igualdad cuando los errores de precisión hacen que sea poco probable, 4) comparación incorrecta de variables, 5) terminación inapropiada o inexistente de bucles, 6) falla en la salida cuando se encuentra una iteración divergente, y 7) variables d e bucle modificadas de manera inapropiada. La prueba de limites e s una de las tareas m á s importantes de la prueba d e unidad. Con frecuencia, el software falla en sus límites. Es decir, a menudo los errores ocurren cuando se procesa el enésimo elemento de una matriz de n dimensiones, cuand o se evoca la /-ésima repetición de un bucle con i pasos, cuando se encuentra el valor máximo o mínimo permisible. Es muy probable descubrir errores en los casos d e prueba que se ejercen sobre la estructura de datos, el flujo d e control y los valores de datos ubicados a p e n a s abajo d e los máximos o mínimos, sobre éstos y apenas arriba de ellos. Un buen diseño impone que se prevean las condiciones de error y que se configuren rutas de manejo de errores para modificar la ruta o terminar limpiamente el procesamiento cuando ocurra un error. Yourdon [YOU75] llama a este enfoque antierror. Por desgracia, existe la tendencia a incorporar el manejo de errores en el software y, con ello, a n o probarlo nunca. Una historia real servirá c o m o ejemplo: Un sistema de diseño asistido por computadora se desarrolló bajo contrato . En un módulo de procesamiento de transacciones, un bromista práctico puso el siguiente mensaje de m a n e j o de errores después de una serie de pruebas condicionales que invocaban varias ramas del flujo de control: ¡ERROR! NO HAY FORMA DE QUE PUEDA LLEGAR HASTA AQUl. ¡Este "mensaje de error" lo descubrió un cliente durante la capacitación del usuario!

Entre los posibles errores que deben probarse cuando se evalúe el m a n e j o d e errores se encuentran los siguientes: 1) la descripción del error es ininteligible, 2) el error indicado no corresponde al encontrado, 3) la condición de error causa la intervención del sistema operativo antes de que se dispare el m a n e j o de errores, 4) el proTM cesamiento de la condición de excepción es incorrecto, 5) la descripción del error no proporciona información suficiente para ayudar a localizar la causa del error.

PDF Editor

P r o c e d i m i e n t o s d e prueba d e unidad. La prueba de unidad suele considerarse adyacente al paso de la codificación. El diseño de las pruebas de unidad puede realizarse antes de que empiece la codificación (un enfoque ágil que suele preferirse) o después de que se ha generado el código fuente. Una revisión de la información del

394

PARTE DOS


Entorno de prueba de unidad.

diseño proporciona u n a guía para establecer c a s o s de prueba que probabl descubrirán errores en cada u n a de las categorías analizadas. Cada c a s o de d e b e relacionarse con un conjunto de resultados esperados. Debido a que un c o m p o n e n t e no es un p r o g r a m a independiente, para cada ÔNSEJO^

ba de unidad se debe desarrollar s o f t w a r e controlados

de resguardo, o de

Hoy situaciones en que no se tendrán los recursos para hacer una prueba de unidad muy completa. Entonces deben seleccionarse módulos críticos y los que tengan una elevado complejidad en ciclos, y sólo ésos deben probarse.

las aplicaciones, un controlador no es m á s que un "programa principal" que

tipos. En la figura 13.4 se ilustra el e n t o r n o para la prueba de unidad. En casi los datos del c a s o de prueba, pasa estos d a t o s al c o m p o n e n t e (que habrá de se) e imprime los resultados importantes. Los resguardos

sirven para ree

módulos s u b o r d i n a d o s al c o m p o n e n t e que habrá de probarse (o llamados por Un resguardo o "subprograma simulado" usa la interfaz del m ó d u l o subor realiza una mínima manipulación de datos, proporciona verificación de la en devuelve el control al m ó d u l o de prueba. Controladores y resguardos representan una sobrecarga de trabajo. Es resulta necesario escribir a m b o s tipos de s o f t w a r e (sin q u e suela aplicarse u r ño formal), p e r o n o se entregan con el producto.de s o f t w a r e final. Si se les ne en un nivel simple, la sobrecarga real es relativamente pequeña. Por d n o es posible aplicar a d e c u a d a m e n t e una prueba de unidad a m u c h o s com con u n "simple" s o f t w a r e de sobrecarga. En m u c h o s c a s o s es posible p o ' prueba completa hasta el p a s o de prueba de integración (donde también se controladores o resguardos). TM La prueba de unidad se simplifica c u a n d o se diseña un c o m p o n e n t e c o cohesión elevada. Cuando sólo se atiende u n a función de un componente, el

PDF Editor

ro de c a s o s de prueba se reduce y es m á s fácil predecir y corregir los errores.

13.3.2 Prueba de integración

Un neófito en el m u n d o del software podría plantear u n a pregunta aparent legítima, u n a vez que se haya aplicado u n a prueba de unidad a todos los m "Si todo funciona bien individualmente, ¿por qué dudan que funcione cua

CAPÍTULO 13


395

une?" El problema, por supuesto, consiste en "unir" (crear la interfaz). En una interfaz es posible perder datos, un módulo podría tener un efecto adverso e inadvertido sobre otro, la combinación de subfunciones tal vez no produzca la función principal deseada, la imprecisión aceptable en elementos individuales podría ampliarse hasta grados inaceptables y las estructuras globales de datos podrían presentar problemas. Es triste, pero la lista sigue y sigue.

* nnfoquede ¡'paralo í e s una : perezosa i al fracaso, irealizorla i en incres í probar s se avanza.

La prueba de integración e s una técnica sistemática para construir la arquitectura del software mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la interfaz. El objetivo es tomar c o m p o n e n t e s a los que se aplicó una prueba de unidad y construir una estructura de programa que determine el diseño. A m e n u d o se tiende a intentar una integración que no sea incremental; e s decir, a construir el programa mediante un enfoque de "big bang". Se combinan todos los componentes por anticipado. Se prueba todo el programa como un todo. ¡Y se produce el caos! Se encuentra una gran cantidad de errores. La corrección es difícil, porque resulta complicado aislar las causas debido a la extensión del programa completo. Una vez corregidos esos errores, aparecen otros nuevos y el proceso continúa en un ciclo que parece interminable. La integración incremental es la antítesis del enfoque del "big bang". El programa se construye y prueba en pequeños incrementos, en los cuales resulta m á s fácil aislar y corregir los errores, es m á s probable que se prueben por completo las interfac e s y se vuelve factible la aplicación de un enfoque de prueba sistemática. En los siguientes párrafos se expondrán varias estrategias diferentes de integración incremental.

*

[CONSEJO

s se desarrolla ideun b, tiene que i la i en que i la integración, i redo que los tiles estén s cuando se ixcesite.

Integración d e s c e n d e n t e . La prueba de integración descendente e s un enfoque incremental para la construcción de ia arquitectura del software. Los módulos se integran al descender por la jerarquía de control, e m p e z a n d o con el módulo de control principal (programa principal). Los módulos subordinados al módulo de control principal se incorporan en la estructura de una de dos maneras: primero-en-profundidad o primero-en-anchura. Tomando c o m o referencia la figura 13.5, la integración primero - en profundidad integra todos los módulos de una ruta de control principal d e la estructura del programa. La selección de una ruta principal e s un poco arbitraria y depende de las características específicas de la aplicación. Por ejemplo, si se elige el camino de la TM izquierda, se integrarían primero los módulos M,, y M3. A continuación, se integraría M s o (si e s necesario para el adecuado funcionamiento de M2) M(v Enseguida se construyen las rutas de control central y a la derecha. La integración primero-en anchura incorpora todos los componentes directamente subordinados en cada nivel, desplazándose horizontalmente por la estructura En el caso de la figura, se integra-

PDF Editor

rían primero los componentes M2, M3 y M.,. Y Ies seguirían M5, M6, etc. El proceso de integración se realiza en una serie de cinco pasos:

396

PARTE DOS

PRÁCTICA RA LA INGENIERÍA DEL SOFTWARE

Integración descendente.

M,

I M7

W m ¿Cuáles son

1. El m ó d u l o de control principal se utiliza c o m o controlador de prueba, y se sustituyen los resguardos e n t o d o s los c o m p o n e n t e s directamente subordina

• P los pasos de la integración descendente?

dos al m ó d u l o de control principal. 2.

Dependiendo del e n f o q u e de integración seleccionado (es decir, primero-er profundidad o primero-en-anchura) se van r e e m p l a z a n d o los resguardos s i bordinados, uno por uno, con los c o m p o n e n t e s reales.

3 . Se aplican p r u e b a s c a d a que se integra un n u e v o módulo. 4 . Al completar cada c o n j u n t o de pruebas, se r e e m p l a z a otro resguardo con e m ó d u l o real. 5 . Se aplica la prueba de regresión (que se analiza m á s adelante, en esta misr.2 sección) para asegurarse de que n o se h a n introducido n u e v o s errores. El proceso continúa a partir del p a s o 2 hasta la construcción total de la e s t r u c t u n del programa. La estrategia de integración d e s c e n d e n t e verifica los principales p u n t o s de carne trol o decisión al principio del proceso de prueba. En una estructura de prograna TM bien elaborada, la t o m a de decisiones ocurre e n los niveles superiores de la jerarcua y, por tanto, se e n c u e n t r a n primero. Si existen p r o b l e m a s de control i m p o r t a n : ^ resulta esencial reconocerlos d e s d e el principio. Si se selecciona la integración p~-

PDF Editor

mero-en-profundidad, e s posible implementar y d e m o s t r a r u n a función completa j d

software. Por ejemplo, imagínese una estructura de transacción clásica (capítulo

I

e n que u n a serie compleja de e n t r a d a s interactivas se solicita, adquiere y valida medio de u n a ruta de entrada. Tal vez ese c a m i n o esté integrado en forma desc¿* dente. Todo el p r o c e s a m i e n t o de e n t r a da (para el envío de las siguientes t r a n s a r a *

CAPÍTULO 13

397


nes) podría d e m o s t r a r s e a n t e s de que otros e l e m e n t o s de la estructura se hayan integrado. La demostración t e m p r a n a de la capacidad funcional genera confianza en el desarrollador y e n el cliente. i ¿Cuáles problemas se irán cuani elija la intei descen-

La estrategia d e s c e n d e n t e no parece muy complicada, p e r o en la práctica llegan a surgir problemas de logística. El m á s c o m ú n se presenta c u a n d o se requiere proc e s a m i e n t o en los niveles inferiores de la jerarquía para probar de m a n e r a adecuada los niveles superiores. Al principio de la prueba d e s c e n d e n t e s e reemplazan los módulos de bajo nivel con resguardos; por tanto, no fluirán d a t o s importantes hacia la parte superior de la estructura del programa. Quien aplica la prueba cuenta con tres opciones; 1) retrasar m u c h a s de las p r u e b a s hasta que los resguardos sean r e e m p l a z a d o s con los m ó d u l o s reales, 2) desarrollar r e s g u a r d os que realicen funciones limitadas que simulen los módulos reales, o 3) integrar el s o f t w a r e de la parte inferior de la jerarquía hacia arriba. El primer e n f o q u e (retrasar las p r u e b a s hasta no reemplazar los r e s g u a r d os con los m ó d u l o s reales) h a c e perder cierto control sobre la correspondencia entre pruebas específicas y la incorporación de m ó d u l o s específicos. Con esto se dificulta determinar la causa de los errores y se tiende a violar la naturaleza a l t a m e n t e restringida del e n f o q u e descendente. Es posible trabajar con el s e g u n d o enfoque, p e r o p u e d e llevar a un a u m e n t o importante de la sobrecarga de trabajo, a medida que los r e s g u a r d os se vuelvan m á s y m á s complejos. El tercer enfoque, d e n o m i n a d o prueba ascendente,

se expondrá en la siguiente sección.

Integración ascendente.

La prueba de integración ascendente,

c o m o su n o m b r e lo

indica, e m p i e z a la construcción y la prueba con módulos atómicos (es decir, c o m p o n e n t e s de los niveles m á s b a j o s de la estructura del programa). Debido a que los c o m p o n e n t e s se integran de a b a j o hacia arriba, siempre está disponible el procesamiento requerido para los c o m p o n e n t e s s u b o r d i n a d o s a un d e t e r m i n a d o nivel y se elimina la necesidad de resguardos. Una estrategia de integración ascendente se implem e n t a mediante los siguientes pasos: I ¿Cuáles son los pasos 0 una integra1 ascendente?

1. Se c o m b i n a n los m ó d u l o s d e bajo nivel en grupos (también llamados construcciones) que realicen una subfunción específica del software. 2 . Se escribe un controlador (un p r o g r a m a de control para pruebas) con el fin de coordinar la entrada y la salida de los c a s o s de prueba. 3 . Se prueba el grupo. 4 . Se eliminan los controladores y se c o m b i n a n los g r u p o s a s c eTM n d i e n d o por la estructura del programa.

PDF Editor CI?AVE

i negación ote elimino la )d de ecuardos complejos.

La integración sigue el patrón ilustrado e n la figura 13.6. Los c o m p o n e n t e s se

c o m b i n a n para formar los grupos 1, 2 y 3. Cada u n o de ellos se prueba e m p l e a n d o un controlador (mostrado c o m o un recuadro con guiones). Los c o m p o n e n t e s de los grupos 1 y 2 están subordinados a M„. Los controladores C, y C2 se eliminan y los grupos interaccionan directamente con Ma. De igual m a n e r a , se elimina el controlador

PARTE DOS

398


Integración ascendente.

Grupo 3 Grupo 1

Cj del grupo 3 a n t e s de la integración con el m ó d u l o Mb. Ma y Mh se integrarán fir¿ll m e n t e con el m ó d u l o Mc, y así sucesivamente. A medida que la integración asciende se reduce la necesidad de controladores Jm prueba separados. En realidad, si los dos niveles superiores de la estructura del p T > grama se integran de m a n e r a descendente, se reducirá de m a n e r a importan:; d n ú m e r o de controladores y se simplificará e n o r m e m e n t e la integración de grupos ypNSEJO^ La prueba de regresión es uno estrategia i m p o M e pora reducir"electos colaterales". Deben aplicarse pruebas de regresión codo vez que se boga un cambia importante al software (incluida lo integración de nuevos componentes).

Prueba d e regresión.

Cada vez que se agrega un n u e v o módulo c o m o par.: aa

una prueba de integración, el software cambia. Se establecen n u e v a s rutas de

- cj

de datos, ocurren n u e v a s e n t r a d a s y salidas y se invoca una nueva lógica de cor.r • Estos cambios llegan a causar problemas con funciones que a n t e s funcionaban b « En el contexto de u n a estrategia de prueba de integración, la aplicación de una p.-j? ba de regresión consiste en ejecutar n u e v a m e n t e el m i s m o s u b c o n j u n t o de prueraJ que ya se ha aplicado para asegurarse de que los cambios no h a n propagado e> tos colaterales indeseables. TM En un contexto m á s amplio, si las p r u e b a s (de cualquier tipo) tienen éxit: resultado es el descubrimiento de errores, y é s t o s deben corregirse. Cada vez que software se corrige también cambia algún a s p e c t o de la configuración del sof

PDF Editor

(el programa, su documentación o los datos de soporte). La prueba de regresiór

u n a actividad que ayuda a a s e g u r a r que los cambios (debidos a la prueba u corazones) no introduzcan c o m p o r t a m i e n t o indeseable o errores adicionales. La prueba de regresión se aplica m a n u a l m e n t e , al ejecutar de nueva cuenis

s u b c o n j u n t o de todos los c a s o s de prueba o al e m p l e a r h e r r a m i e n t a s automáticas

CAPÍTULO 13


captura, reproducción, o a m b a s . Las herramientas

399

de captura, reproducción,

o de

a m b o s tipos, permiten al ingeniero del s o f t w a r e capturar c a s o s de prueba y resultad o s para reproducirlos y compararlos después. El conjunto de p r u e b a s de regresión (el s u b c o n j u n t o de p r u e b a s que se aplicarán) contiene tres clases diferentes de c a s o s de prueba: • Una muestra representativa de p r u e b a s que ejercerán todas las funciones del software. • Pruebas adicionales q u e se concentran en las funciones del s o f t w a r e que probablemente el cambio afectaría. • Pruebas q u e se concentran en los c o m p o n e n t e s del software que h a n cambiado. A medida que a v a n z a la prueba de integración, la cantidad de pruebas de regresión llega a volverse muy grande. Por tanto, el c o n j u n t o de p r u e b a s de regresión debe diseñarse para que sólo incluya las que atienden una o m á s clases de errores en cada u n a de las funciones principales del programa. Resulta poco práctico e ineficiente repetir cada prueba para todas las funciones del p r o g r a m a d e s p u é s de que se ha pres e n t a d o un cambio. Prueba de h u m o .

La prueba de humo es un e n f o q u e de prueba de integración q u e

suele utilizarse mientras se desarrollan productos de software. Está d i s e ñ a d o c o m o m e c a n i s m o para m a r c a r el ritmo en proyectos en los cuales el tiempo e s crítico, lo que permite que el equipo de s o f t w a r e evalúe su proyecto con frecuencia. En esencia, el e n f o q u e de la prueba de h u m o abarca las siguientes actividades: 1.

Los c o m p o n e n t e s de s o f t w a r e traducidos a código se integran en u n a "construcción", la cual incluye todos los archivos de datos, las librerías, los m ó d u los reutilizables y los c o m p o n e n t e s de ingeniería q u e se requieren para implementar una o m á s funciones del producto.

2.

CÚVVi i de humo : caracterizarse : uno estrategia

Se diseña una serie de p r u e b a s para exponer errores que impedirán q u e la construcción realice a p r o p i a d a m e n t e su función. El objetivo es descubrir errores "paralizantes" que tengan la mayor probabilidad de retrasar el proyecto de software.

3.

La construcción se integra con otras construcciones, y diariamente TM se aplica una prueba de h u m o a todo el producto (en su forma actual). El e n f o q u e de la

o. Se i el software r nevos

La aplicación diaria de una prueba a todo el producto sorprenderá a a l g u n o s lecto-

I y se aplica • raba de humo i los días.

u n a evaluación realista del a v a n c e de las p r u e b a s de integración. McConnell [ M C 0 9 6 ] describe así la prueba de humo:

integración p u e d e ser d e s c e n d e n t e o ascendente.

PDF Editor

res. Sin embargo, las pruebas frecuentes d a n a los jefes de proyecto y participantes

400

PARTE DOS


La prueba de humo debe ejercitar todo el sistema de principio a fin. No debe ser exhaustiva, pero debe tener la capacidad de exponer problemas importantes. La prueba de hume debe ser tan completa que si la construcción la aprueba, puede suponerse que ésta es suficientemente estable como para probarla de manera más completa. La prueba de h u m o proporciona varios beneficios c u a n d o s e aplica en proyectos ingeniería del s o f t w a r e complejos y que d e p e n d e n en forma crítica del tiempo • Se minimiza

el nesgo en la integración. Debido a que las p r u e b a s de h u m o se

aplican diariamente, desde el principio se descubren las incompatibilidad:-: otros errores paralizantes, por lo que se reduce la probabilidad de que t un fuerte impacto en el calendario c u a n d o se descubran errores. • Se mejora la calidad del producto final. C o m o el enfoque está orientado a la construcción (integración), es probable que la prueba de h u m o descubra errores funcionales, arquitectónicos y al nivel de c o m p o n e n t e s . Si estos errores se corrigen desde el principio, se obtendrá u n a mayor calidad e - ± producto. • Se simplifican el diagnóstico y la corrección de errores. C o m o todos los e de prueba de integración, es probable q u e los errores n o descubiertos e r prueba de h u m o estén asociados con "nuevos i n c r e m e n t o s de software s o f t w a r e que se a c a b a de añadir a la construcción es u n a posible causa i r error recién descubierto). • El progreso es más fácil de evaluar. Cada día que p a s a se integra m á s y se d e m u e s t r a que funciona. Esto mejora la moral del equipo y brinda a ~ jefes de proyecto una b u e n a indicación de que se están logrando avances I "Trole la construcción diaria como si fuero el corazón del proyedo. Si no tiene corazón, el proyedo está m u é - : '

Jim Opciones estratégicas.

Ha habido m u c h a discusión (por ejemplo, (BElé-¡)

las ventajas y desventajas relativas de las pruebas de integración a s c e n d e r :; J J cendente. En general, las ventajas de u n a estrategia tienden a convertirse e r Í-* tajas para la otra. La principal desventaja del enfoque descendente es la neo

Referencia Web

Apuntodotes o comentarios sobre estrategias de pruebo se encontrarán en: www.qalinks.com.

resguardos y las dificultades de las pruebas asociadas. Los problemas re"~ con los resguardos se compensarían con la ventaja de probar lasTM principales ñ. n e s de control e n las primeras etapas. La principal desventaja de la in a s c e n d e n t e es q u e "el programa, c o m o u n a entidad, n o existe hasta que se tal

PDF Editor

dido el último módulo" (MYE79]. Esta desventaja la a t e n ú a la mayor fácil diseñar c a s o s de prueba y la falta de resguardos. La selección de una estrategia de integración d e p e n d e de las caracte software y, e n ocasiones, del calendario del proyecto. En general, la mejor u n e n f o q u e c o m b i n a d o (a veces d e n o m i n a d o prueba sandwich) que usa p

CAPÍTULO 13


401

cendentes para los niveles superiores de la estructura del programa, junto con pruebas ascendentes para los niveles subordinados. ¿Ové es un • ó d u l o critica y por qué identificarse?

A medida que se realiza la prueba de integración, el responsable debe identificar módulos críticos. Un módulo crítico tiene una o m á s de las siguientes características: 1) atiende varios requisitos del software, 2) tiene un alto grado de control (se encuentra en un lugar relativamente alto de la estructura del programa), 3) e s complejo o propenso a errores, o 4) tiene requisitos de desempeño bien definidos. Los módulos críticos deben probarse lo antes posible. Además, las pruebas d e regresión se deben concentrar en el funcionamiento de los módulos críticos. D o c u m e n t a c i ó n de la prueba de integración.

Un plan general para la integra-

ción del software y una descripción de pruebas específicas se documentan en la Especificación déla prueba. Este documento que contiene un plan de prueba, un procedimiento de prueba, es un producto de trabajo del proceso de software y se vuelve parte de la configuración del software. El plan de prueba describe la estrategia general de integración. La prueba se divide en fases y construcciones que atienden características específicas del funcionamiento y el comportamiento del software. Por ejemplo, la prueba de integración para un sistema de diseño asistido por computadora se dividiría en las siguientes fases de prueba: • Interacción del usuario (selección de comandos, creación de dibujos, representación del despliegue, procesamiento de errores y representación). • Manipulación y análisis de datos (creación de símbolos, asignación de dimensiones, rotación, cálculo de propiedades físicas). • Procesamiento y generación de despliegue (despliegues bi y tridimensionales, imágenes y gráficas). • Administración de base de datos (acceso, actualización, integridad, desempeño). Cada una de estas fases y subfases (denotadas entre paréntesis) delinean una amplia categoría funcional dentro del software y suelen relacionarse con un dominio específico dentro de la arquitectura del software. Por tanto, las construcciones del programa (grupos de módulos) se crean para que correspondan con cada fase. Los siguientes criterios y las pruebas correspondientes se aplican para todas las fases de TM prueba. Integridad de la interfaz. Las interfaces internas y externas se prueban a medida que cada módulo (o grupo) se incorpora en la estructura.

PDF Editor Validez funcional. cionales.

Se realizan las pruebas diseñadas para descubrir errores fun-

Contenido déla información. Se aplican las pruebas diseñadas para descubrir errores asociados con estructuras de datos locales o globales.

PARTE DOS

402


Desempeño.

Se realizan las p r u e b a s diseñadas para verificar los límites de desem-

p e ñ o establecidos d u r a n t e el diseño del software. Un calendario para la integración, el desarrollo de software de sobrecarga \ t e m a s relacionados también se analizan c o m o parte del plan de prueba. Se detc n a n las fechas de inicio y término para cada fase y se definen las "ventanas de ponibilidad" para los m ó d u l o s de prueba de unidad. Una breve descripción del w a r e de sobrecarga (resguardos y controladores) se concentra en las caracte~ que requieren e s f u e r z o s especiales. Por último, se describen el e n t o r n o y los sos de la prueba. Configuraciones p o c o c o m u n e s de hardware, simuladores ex y h e r r a m i e n t a s especiales de prueba s o n algunos de los m u c h o s t e m a s que ta podrían analizarse. A continuación se describe el procedimiento detallado de prueba que se r para completar el plan respectivo. También se detalla el orden de integración p r u e b a s correspondientes en cada p a s o de integración. Además, se incluyelista de todos los c a s o s de prueba (anotados para referencia posterior) y los dos esperados. Una historia de resultados, problemas o peculiaridades de las p r u e b a s rea.rí registra en el Informe de prueba que p u e d e adjuntarse a la Especificación de Si s e d e s e a , la información contenida en esta sección será vital d u r a n t e el miento del software. También se p r e s e n t a n referencias y apéndices apropiadc C o m o t o d o s los d e m á s e l e m e n t o s de u n a configuración de software, el de la especificación de prueba p u e d e amoldarse a las n e c e s i d a d e s locales ce organización de ingeniería del software. Sin embargo, es importante observa una estrategia de integración (contenida en el plan de prueba) y los detalles de ba (descritos en el procedimiento de prueba) s o n ingredientes esenciales y aparecer. "El mejor participante de uno pruebo no es el que encuentro más errores... sino el que corrige la mayor conlidod de Cem Kan

13.4

ESTRATEGIAS DE PRUEBA PARA SOFTWARE ORIENTADO A Q E . El objetivo de probar, para definirlo de m a n e r a simple, es encontrar la mayor dad de errores aplicando u n a cantidad manejable de esfuerzo e n un periodo ta. Aunque e s t e objetivo f u n d a m e n t a l sigue sin c a m b i o para el s o f tTM w a r e orie objetos, la naturaleza de este s o f t w a r e cambia la estrategia y la táctica de las bas (capítulo 14).

PDF Editor

13.4.1 Prueba de unidad en el contexto orientado a objetos

Al pensar en el software orientado a objetos cambia el c o n c e p t o de u n i ó s e

encapsulación orienta la definición de clases. Esto significa que cada clase e , cia de una clase (objeto) e m p a q u e t a atributos (datos) y las operaciones (fu que manipulan estos datos. Una clase e n c a p s u l a d a suele ser el eje de las p

CAPÍTULO 13

ESTRATEGIAS DE PRUEBA DEL SOfT.VAKE

403

unidad. Sin embargo, las unidades de prueba m á s p e q u e ñ a s s o n las o p e r a c i o n e s d e n t r o d e la clase. Debido a que u n a clase p u e d e contener varias o p e r a c i o n e s diferentes y a que una operación determinada p u e d e existir c o m o parte de varias clases diferentes, deben cambiar las tácticas aplicadas para la prueba de unidad. No e s posible probar una sola operación de m a n e r a aislada (el c o n c e p t o convencional de prueba de unidad) sino c o m o parte de una clase. Para ilustrarlo, considé-

LAVE ] de dase ¡saftwore a objetos es a la prueba de poro software i No es probar de manera

rese una jerarquía de clase en que se define una operación X para la superclase y que h e r e d a n varias subclases. Cada u n a de é s t a s usa la operación X , p e r o se aplica dentro del contexto de los atributos privados y las operaciones que se han definido para la subclase. Dado que el contexto en que se emplea la operación X varía en f o r m a s sutiles, e s necesario probar la operación en el contexto de cada una de las subclases. Esto significa que si se prueba la operación X de m a n e r a independiente (el enfoq u e de la prueba de unidad convencional) se podrá usar d e m a n e r a deficiente en el contexto orientado a objetos. La prueba de clase para el s o f t w a r e orientado a objetos e s el equivalente a la prueba de unidad para el s o f t w a r e convencional. A diferencia de ésta, que tiende a c o n c e n t r a r s e en el detalle algorítmico de un módulo y e n los d a t o s q u e fluyen p o r la interfaz del módulo, la prueba de clase para el s o f t w a r e orientado a objetos se orienta mediante las o p e r a c i o n e s que encapsula la clase y en el c o m p o r t a m i e n t o de estad o de la clase.

13.4.2 Prueba de integración en el contexto orientado a objetos Debido a que el software orientado a objetos no tiene una estrategia obvia de c o n trol jerárquico, tienen poco significado las estrategias de integración d e s c e n d e n t e y

K

a s c e n d e n t e tradicionales (sección 13.3.2). Además, integrar las o p e r a c i o n e s una por

C L Á V B estrategia para la de integración software orientado n e t o s es la prueba en esos. Los esos son de clases i responden a uno i o un evento. - 2 pruebas basadas seiusose «¡centran en las

n e n t e s que integran la clase" [BER93],

una en u n a clase (el e n f o q u e convencional d e la integración incrementa!) suele resultar imposible debido a las "interacciones directas e indirectas de los compoHay d o s estrategias diferentes para la prueba de integración de los sistemas orient a d o s a objetos [BIN94]. La primera, la prueba basada en subprocesos,

integra el c o n -

junto de clases requerido para responder a u n a e n tr a da o un evento del sistema. Cada subproceso s e integra y prueba individualmente. La prueba de regresión se aplica para asegurar que no se presenten efectos colaterales. El s e g u n d o e n f o q u e de integración, la prueba basada en el uso, e m p i e z a la construcción del sistema con la prueba de e s a s clases (llamadas clases independientes)

que usan muy p o c a s clases de TM servidor (o ninguna). Después de que se p r u e b a n las clases independientes, se prueba la siguiente capa de clases, llamadas clases dependientes,

q u e u s a n las clases

PDF Editor 3Eses q u e n o

-'oboron mucho con unís clases.

independientes. Esta secuencia de c a p a s de prueba de clases dependientes continúa hasta que se construye todo el sistema. El uso d e controladores y r e s g u a r d os también cambia c u a n d o s e aplican pruebas

de integración a los sistemas orientados a objetos. Con los controladores se prueban o p e r a c i o n e s al nivel m á s b a j o y grupos completos de clases. Un controlador también

404

PARTE DOS


se utiliza para reemplazar la interfaz de usuario, de m o d o que p u e d a n aplicarse pruebas de funcionalidad del sistema a n t e s de la implementación de la interfaz. r e s g u a r d os s e usan en situaciones en que la colaboración e n t r e clases es neces p e r o e n las cuales a ú n no se h a n i m p l e m e n t a d o por completo u n a o m á s de las s e s que colaboran. La prueba de grupo e s u n p a s o en la prueba de integración del s o f t w a r e orie do a objetos. Aquí, un grupo de clases que colaboran e n t r e si (determinadas po-1 e x a m e n del CRC y el m o d e l o objeto-relación) s e ejercita al diseñar c a s o s de pr que tratan de descubrir errores en las colaboraciones.

Las pruebas de validación e m p i e z a n tras la culminación de la prueba de integra

\ CLAVE Como todos los demos pasos de pruebo, en lo validación se trata de descubrir errores, pero el punto central está en el nivel de los requisitos (o las cosas que serón inmediatamente evidentes pora el usuario final).

c u a n d o se h a n ejercitado los c o m p o n e n t e s individuales, se ha terminado de er blar el s o f t w a r e c o m o p a q u e t e y se han descubierto y corregido los errores de faz. En el nivel de validación o sistema d e s a p a r e c e la distinción entre software < vencional y orientado a objetos. La prueba se concentra e n las acciones visibles; el usuario y en la salida del sistema que éste p u e d e reconocer. La validación se define de m u c h a s formas, pero u n a definición simple (ai vulgar) es que se alcanza c u a n d o el software funciona de tal m a n e r a que satisface i expectativas razonables del cliente. En este punto, un desarrollador de software t rimentado protestaría: "¿Qué o quién decide lo que es una expectativa r a z o n a b a " Las expectativas razonables se definen en la Especificación de requisitos deí ware (un d o c u m e n t o que describe los atributos del s o f t w a r e visibles para el t La especificación contiene u n a sección d e n o m i n a d a Criterios de validación. La ; mación contenida en e s a sección integra la b a s e del enfoque de la prueba de dación.

13.5.1 Criterios de la prueba de validación La validación del software se logra mediante u n a serie de p r u e b a s que demi q u e se cumple con los requisitos. Un plan de prueba delinea la clase de pruebas i se aplicarán, y un procedimiento de prueba define los c a s o s de prueba espe Tanto el plan c o m o el procedimiento se diseñan para asegurar que se sat todos los requisitos funcionales, que se a l c a n z a n t o d a s las características portamiento, que se cumple con todos los requisitos de d e s e m p e TM ñ o , que la m e n t a c i ó n es correcta y que se cumple también con t o d o s los requisitos de fa de uso y otros requisitos especificados (por ejemplo, portabilidad, compatib

PDF Editor recuperación de errores, facilidad de mantenimiento).

Después de que se h a dirigido cada c a s o de prueba de validación, existirá i

d o s condiciones posibles: 1) la característica de funcionamiento o desempeñe pie con la especificación y se le acepta, o 2) se descubre u n a desviación de cificación y se crea u n a lista de deficiencias. La desviación o el error descubie

CAPITULO 13

ESTRATEGIAS DE PRUEBA DEL SOTTWASE

405

esta etapa de un proyecto rara vez se corrige a n t e s de la fecha de entrega. A m e n u d o es necesario negociar con el cliente un m é t o d o para resolver las deficiencias.

13.5.2 Revisión de la configuración La revisión de la configuración

es un e l e m e n t o importante del proceso de validación;

su objetivo es a s e g u r a r que todos los e l e m e n t o s de la configuración del s o f t w a r e se hayan desarrollado apropiadamente, estén catalogados y tengan el detalle suficiente para reforzar la fase de soporte del ciclo de vida del software. La revisión de la configuración, a veces d e n o m i n a d a auditoria, se analizará con m á s detalle en el capítulo 27.

13.5.3 Pruebas alfa y beta En la práctica e s imposible que un desarrollador de s o f t w a r e prevea c ó m o utilizará el usuario realmente el programa. Es posible que se malinterpreten las instrucciones de uso, que se utilicen con regularidad extrañas c o m b i n a c i o n e s de datos, que una salida en apariencia clara para el responsable de las p r u e b a s sea ininteligible para un usuario en el campo. Al construir s o f t w a r e personalizado para un cliente se aplica una serie de pruebas de aceptación que permiten al cliente validar todos los requisitos. El usuario final conduce, n o los ingenieros del software, las p r u e b a s de aceptación, las cuales v a n d e s d e u n a "prueba de manejo" informal hasta u n a serie de pruebas p l a n e a d a s y ejec u t a d a s de m a n e r a sistemática. En realidad, la prueba de aceptación llega a durar s e m a n a s o m e s e s , por lo que es posible descubrir errores acumulativos q u e degradan el sistema. "Si se recurre a ojos suficientes, todos los errores serón superficiales (por ejemplo, si hay una base lo suficientemente grande de personos que realizan las pruebas beta y de codesarrolladores, casi todos los problemas se caracterizarán rápidamente y la corrección será obvia para alguien)." I . Roymond

Si el s o f t w a r e se desarrolla c o m o un producto que usarán m u c h o s clientes, no e s práctico realizar p r u e b a s de aceptación formales para c a d a uno. La mayoría de los constructores de productos de s o f t w a r e e m p l e a n procesos llamados prueba alfa y prueba beta para descubrir errores que sólo el usuario final podría detectar. Los usuarios finales son quienes aplican la prueba alfa en el lugar TMd e trabajo del desarrollador. El s o f t w a r e se utiliza en un e n t o r n o natural mientras el desarrollador "mira sobre el hombro" d e los usuarios típicos y registra los errores y los problemas

PDF Editor de uso. Las p r u e b a s alfa se realizan en un e n t o r n o controlado.

Las pruebas beta se aplican e n el lugar de trabajo de los usuarios finales. A dife-

rencia de la prueba alfa, por lo general el desarrollador no está. Por tanto, la prueba beta es u n a aplicación "en vivo" del s o f t w a r e en un e n t o r n o q u e no controla el d e s a rrollador. El usuario final registra todos los problemas (reales o imaginarios) que

PARTE DOS

406


e n c u e n t r a d u r a n t e la p r u e b a y los i n f o r m a d e m a n e r a r e g u l a r al d e s a r r o l l a d o r . C C T M r e s u l t a d o d e los p r o b l e m a s i n f o r m a d o s d u r a n t e l a s p r u e b a s b e t a , los i n g e n i e r o s : e | s o f t w a r e lo m o d i f i c a n y l u e g o p r e p a r a n la liberación del p r o d u c t o d e s o f t w a r e F ^ a J t o d a la b a s e de clientes. HOGARSEGURO Preparación

para

validación

Lo e s c e n a : Oficina de Doug Milter, mientras continúa el diseño al nivel de componentes y empieza la construcción de ciertos componentes. Los actores: Doug Miller, jefe de ingeniería de software, Vinod, Jamie, Ed y Shokira, integrantes del equipo de ingeniería del software HogarSeguro. La conversación: Doug: El primer incremento estará listo para validación en... ¿unas tres semanas? Vinod: Es correcto, la integración va bien. Estamos realizando pruebas de humo a diario, encontrando algunos errores, pero nada que no se pueda manejar. Así que hasta ahora todo va bien. Doug: Cuéntame un poco de la validación. Shakira: Bueno, emplearemos todos los casos de uso como base para el diseño de nuestras pruebas. Aún no he empezado, pero estaré desarrollando pruebas para todos los casos de uso de los que soy responsable. Ed: Lo mismo yo. Jamie: Yo también, pero tendremos que actuar juntos para la prueba de aceptación y también para las pruebas alfa y beta, ¿verdad?

13.6

Doug: Sí, en realidad he pensado que podríamos a un contratista que nos ayude con la validación. Teogc dinero en el presupuesto... y nos daría una perspecr • ; fresca. Vinod: Creo que lo tenemos todo bajo control. Doug: Estoy seguro de eso, pero un grupo independiente de prueba nos dará un punto de vista autónomo sobre el software. Jamie: Estamos justos de tiempo aquí, Doug. Yo, e- ; personal, no tengo tiempo para cuidar a nadie que traigas a hacer el trabajo. Doug: Lo sé, lo sé. Pero si un GIP trabaja a partir ir a requisitos y casos de uso, no requerirá mucha ayucc ustedes. Vinod: Todavía pienso que lo tenemos todo bajo cc-—ai Doug: Ya te oí, Vinod, pero me voy a imponer en Planeemos el encuentro con el representante del Gl- i á adelante, esta misma semana. Dejemos que empiece y veamos que nos trae. Vinod: Muy bien, tal vez aligere un poco la carga

P R U E B A DEL S I S T E M A En el inicio d e e s t e libro s e d e s t a c ó el h e c h o d e q u e el s o f t w a r e s ó l o e s u n e l e ® t o de u n s i s t e m a de c ó m p u t o m á s g r a n d e . Al final, el s o f t w a r e s e i n c o r p o r a a ; • e l e m e n t o s del s i s t e m a ( c o m o h a r d w a r e , p e r s o n a s , i n f o r m a c i ó n ) , y s e realiza a serie d e p r u e b a s de i n t e g r a c i ó n del s i s t e m a y d e validación. E s t a s pTM ruebas esta- n allá del a l c a n c e del p r o c e s o del s o f t w a r e y n o l a s r e a l i z a n ú n i c a m e n t e los i r g - a r o s del s o f t w a r e . Sin e m b a r g o , los p a s o s d a d o s d u r a n t e el d i s e ñ o y la p r u e b a d e a

PDF Editor

w a r e m e j o r a r á n e n g r a n m e d i d a la p r o b a b i l i d a d de t e n e r é x i t o e n la i n t e g r a c s o f t w a r e e n el s i s t e m a m a y o r .

"Al igual que lo muerte y los impuestos, las pruebas son desagradables e inevitables."

Ed Y

CAPÍTULO 13


407

Un problema clásico de la prueba del sistema es "señalar con el dedo". Esto ocurre cuando se descubre un error y el desarrollador de cada elemento del sistema culpa a los demás. En lugar de caer en este absurdo, el ingeniero del software debe anticiparse a posibles problemas con la interfaz y 1) diseñar rutas de manejo de errores que prueben toda la información proveniente de otros elementos del sistema, 2) aplicar una serie de pruebas que simulen datos incorrectos u otros posibles errores en la interfaz del software, 3) registrar los resultados de las pruebas como "evidencia" en el caso de que se le culpe, y 4) participar en la planeación y el diseño de pruebas del sistema para asegurar que el software se ha probado adecuadamente. En realidad, la prueba del sistema abarca una serie de pruebas diferentes cuyo propósito principal es ejercitar profundamente el sistema de cómputo. Aunque cada prueba tiene un propósito diferente, todas trabajan para verificar que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas. En las siguientes secciones se examinarán los tipos de pruebas del sistema [BEI84] que valen la pena para sistemas basados en software.

13.6.1 Prueba de recuperación Muchos sistemas de cómputo deben recuperarse de fallas y reanudar el procesamiento en un tiempo determinado. En algunos casos, un sistema debe ser tolerante con las fallas; es decir, las fallas de procesamiento no deben llevar a la caída del sistema, en general. En otros casos, una falla del sistema debe corregirse dentro de un periodo específico o se sufrirá un fuerte d a ñ o económico. La prueba de recuperación es una prueba del sistema que obliga al software a fallar de varias m a n e r a s y a verificar que la recuperación se realice apropiadamente. Si la recuperación es automática (la realiza el propio sistema) debe evaluarse que sean correctos la reinicialización, los mecanismos de respaldo del sistema, la recuperación de datos y el nuevo arranque. Si la recuperación requiere intervención humana, se debe evaluar el tiempo medio de reparación (TMR) para determinar si se encuentra dentro de límites aceptables.

13.6.2 Prueba de seguridad Cualquier sistema de cómputo que maneje información confidencial o que desencadene acciones que dañen (o beneficien) inapropiadamente a los individuos es un blanco para irrupciones impropias o ilegales. La irrupción abarca un amplio rango de actividades: hackers que tratan de entrar en los sistemas por juego, empleados TM disgustados que tratan de irrumpir como forma de venganza, e individuos deshonestos que buscan ganancias personales ilícitas.

PDF Editor

La prueba de seguridad comprueba que los mecanismos de protección integrados en el sistema realmente lo protejan de irrupciones inapropiadas. Para citar a Beizer [BE184J: "Por supuesto que debe probarse la seguridad del sistema para asegurar que e s invulnerable a los ataques frontales, pero también a los perpetrados por los flancos o la retaguardia".

408

PARTE DOS


Durante la prueba de seguridad, quien la aplica d e s e m p e ñ a el papel del indivich. que d e s e a entrar en el sistema. ¡Todo se vale! Debe tratar de obtener contraseña por cualquier medio externo; podría atacar el sistema c o n s o f t w a r e personalizad diseñado para burlar cualquier d e f e n s a que se haya construido; podría saturar el s t tema, n e g a n d o así el servicio a otros; podría producir errores intencionales en el siscr ma para tratar de t e n e r a c c e s o durante la recuperación; podría revisar d a t o s sin protección, con la idea de e n c o n t r a r la clave de acceso al sistema. Si se d a n el tiempo y los recursos suficientes, u n a b u e n a prueba de seguridad minará por irrumpir en el sistema. El papel del diseñador del sistema e s que el cc-s» de la irrupción sea mayor q u e el valor de la información q u e h a b r á de obtenerse

13.6.3 Prueba de resistencia Los p a s o s de prueba analizados antes, e n este m i s m o capítulo, llevan a u n a evai

,

ción completa de las funciones y el d e s e m p e ñ o n o r m a l e s del programa. Las p r u e r - s l de resistencia están diseñadas para confrontar los p r o g r a m a s con situaciones a r .rmales. En esencia, la persona que realiza la prueba de resistencia se pregunta-e "¿Hasta d ó n d e p u e d o llevar esto a n t e s de que falle?" La prueba de resistencia ejecuta un sistema d e tal m a n e r a que requiera una canr-l dad, una frecuencia o un volumen anormal de recursos. Por ejemplo: 1) se d i s e ñ a p r u e b a s especiales que generen diez interrupciones por segundo, c u a n d o la u J promedio es d e u n a o dos-, 2) se a u m e n t a la frecuencia de e n tr a da de d a t o s en JT» magnitud que permita determinar c ó m o r e s p o n d e r á n las funciones de entrada > a t ejecutan c a s o s de prueba que requieran el m á x i m o de memoria u otros recurs -í se d i s e ñ a n c a s o s de prueba que causen problemas de administración de merr 5) se crean c a s o s de prueba que produzcan b ú s q u e d a s excesivas de d a t o s en el e s e * En esencia, la persona que aplica la prueba tratará de sobrecargar el programa. "Si este trotando de encontrar verdaderos errores del sistema y no ha sometido su software a una verdadera prueo: de resistencia, entonces éste es el momento de empezar". Boris B c á r

i

Una variante de la prueba de resistencia es u n a técnica d e n o m i n a d a p r u e r ; • sensibilidad. En a l g u n a s situaciones (la m á s común de ellas ocurre con los m o s matemáticos), un r a n g o muy p e q u e ñ o de datos contendidos dentro de los I B H tes de los d a t o s válidos p a r a un p r o g r a m a p u e d e c a u s a r p r o c e s a m i e n t o extrema® incluso erróneo, o u n a fuerte degradación del d e s e m p e ñ o . Las p r uTM e b a s de s e r = ¿ á H dad tratan de descubrir c o m b i n a c i o n e s de datos dentro de las clases de entrada d a s que c a u s e n inestabilidad o p r o c e s a m i e n t o inapropiado.

PDF Editor 13.6.4 Prueba de desempeño

En sistemas en tiempo real e incrustados es inaceptable el s o f t w a r e que prop i o * n a la función requerida p e r o que no cumple los requisitos de d e s e m p e ñ o . La de d e s e m p e ñ o está d i s e ñ a d a para probar el d e s e m p e ñ o del s o f t w a r e en t i e r r : - g H

CAPÍTULO 13


409

ejecución d e n t r o del contexto de un sistema integrado. La prueba d e d e s e m p e ñ o se aplica e n todos los p a s o s del p r o c e s o de la prueba. Incluso al nivel de la unidad, el d e s e m p e ñ o de un módulo individual debe evaluarse mientras s e realizan las pruebas. Sin embargo, no es sino hasta que se encuentran totalmente integrados todos los elem e n t o s del sistema que es posible asegurar el verdadero d e s e m p e ñ o del sistema. Con frecuencia las pruebas de d e s e m p e ñ o se vinculan con p r u e b a s de resistencia y suelen requerir instrumentación de s o f t w a r e y hardware. Es decir, a m e n u d o resulta necesario medir con exactitud la utilización de recursos (por ejemplo, los ciclos de procesador). Mediante instrumentación externa pueden vigilarse de m a n e r a regular los intervalos de ejecución, los eventos que se registran (como las interrupciones) y los estados de muestra del equipo. Si se instrumenta un sistema, la persona que aplica la prueba descubrirá situaciones que lleven a la degradación y posibles fallas del sistema.


Planeación y administración de pruebas Objetivo: Estas herramientas ayudan al > de software a planear la estrategia de prueba que -ó de elegirse y a manejar el proceso de prueba a i que se aplica. nica: Las herramientas de esta categoría atienden ción y el almacenamiento de la prueba, la listración y el control, el seguimiento de los s, la integración, el rastreo de errores y la ción de informes. Los jefes de proyecto las usan i complementar las herramientas de planeación. ¡ aplican las pruebas usan estas herramientas para r actividades de prueba y controlar el flujo de ación a medida que avanza el proceso de prueba.

Herramientas representativas 2 OTF (Object Testing Frameworkl, desarrollado por MCG Software Inc. (www.mcgsoft.com), proporciona un marco conceptual para la administración de conjuntos de pruebas para objetos Smalltalk. QADireclor, desarrollado por Compuware Corp. (www.compuware.com/qacenter), proporciona un solo punto de control para administrar todas las fases del proceso de prueba. TestWorks, desarrollado por Software Reasearch Inc. (www.soft.com/Products/index, html), contiene un conjunto plenamente integrado de herramientas de prueba, incluidas algunas que sirven para el manejo y la generación de informes de las pruebas.

La prueba del s o f t w a r e e s un p r o c e s o que p u e d e planearse y especificarse sistemáticamente. Se diseña el c a s o de prueba, se define una estrategia y se evalúan los resultados frente a las expectativas prescritas. La depuración ocurre c o m o consecuencia de una prueba realizada TM con éxito. Es decir, c u a n d o un c a s o de prueba descubre un error, la depuración es la acción q u e lo elimina. Aunque la depuración p u e d e y d e b e ser un proceso ordenado, sigue sien-

PDF Editor

d o un arte. Un ingeniero del software, al evaluar los resultados de una prueba, suele

2

Las herramientas expuestas aquí sólo representan una muestra de esta categoría. En casi todos los casos los nombres de las mismas son marcas registradas de sus respectivos desarrolladores.

410

PARTE DOS


enfrentarse con u n a indicación "sintomática" de un problema de software. Es d e n tal vez la manifestación externa del error y su causa interna no tienen una relac: :ir obvia. La depuración e s el proceso m e n t a l que conecta un síntoma con una causa

"En tuonlo empezomos la programación, descubrimos, para nuestro sorpresa, que no será fácil conseguir el p r o g r a r : que tenemos en mente. Es necesario descubrir la depuración. Recuerdo el momento exacto en que m e di cuenta de que iba a gastar gran parte de mi vida, a partir de ese momento, en encontrar los errores de mis propios programas." Maurice Wilkes, descubre la depuración en 1 9 4 ;

13.7.1 El proceso de depuración La depuración n o es una prueba, pero siempre ocurre c o m o consecuencia de

ú

Si se toma c o m o referencia la figura 13.7, el proceso de depuración comienza cor. ejecución de un c a s o de prueba. Se evalúan los resultados y se e n c u e n t r a una

de correspondencia entre el d e s e m p e ñ o e s p e r a d o y el real. En m u c h o s casos

d

datos que no corresponden son síntoma de una c a u s a que aún no aparece. La d e o t - l ración trata de relacionar el síntoma con la causa, lo que c o n d u c e a corregir el e m x l La depuración siempre arroja dos resultados: 1) se encuentra y se corrige la ca-SéJ o 2) no se localiza la causa. En este último caso, la persona encargada de la d ^ - ^ J ción d e b e s o s p e c h a r la causa, diseñar u n o o m á s c a s o s de prueba que ayuden validar e s a sospecha y a v a n z a r hacia la corrección del error de m a n e r a iterativa

El proceso de depuración.

Pruebas de regresión

TM Correcciones^

Causas identificadas

PDF Editor

Al hacer esta afirmación se toma el concepto más amplio posible de la prueba. ¡No sólo el desam llador prueba el software antes de la liberación, sino que el cliente, el usuario, o ambos, pr pruerar | software cada vez que lo usan!

CAPÍTULO 13

ESTRATEGIAS DE PRUEBA D a SOFTWARE

411

¿Por qué e s tan difícil la depuración? Con toda probabilidad, la respuesta se relaciona m á s con la psicología h u m a n a (consulte la siguiente sección) que con la tecnología del software. Sin embargo, ciertas características de los errores ofrecen a l g u n a s pistas: 1. El síntoma y la causa p u e d e n estar s e p a r a d o s geográficamente. Es decir, aquél a p a r e c e e n u n a parte del p r o g r a m a mientras ésta se ubica e n un sitio distante. Los c o m p o n e n t e s con un fuerte acoplamiento (capítulo 11) exacerban esta situación. 2.

Es posible que el síntoma d e s a p a r e z c a (temporalmente) al corregir otro error.

3 . Es probable que el síntoma no lo c a u s e algún error (como en el c a s o de inexactitudes al r e d o n d e a r cifras). 4 . El síntoma podría d e b e r s e a un error h u m a n o difícil de localizar. 5 . El síntoma podría deberse a problemas de tiempo y n o de procesamiento. 6 . Tal vez s e a difícil reproducir con exactitud las condiciones de e n tr a da (por ejemplo, u n a aplicación en tiempo real en que no está definido el orden de entrada). 7 . El síntoma podría presentarse intermitentemente. Esto suele ser c o m ú n e n sistemas e m p o t r a d o s que acoplan el h a r d w a r e y el s o f t w a r e de m a n e r a inextricable. 8.

Probablemente el síntoma se d e b e a c a u s a s distribuidas entre varias tareas que se ejecutan en diferentes p r o c e s a d o r e s [CHE90].

Durante la depuración se e n c u e n t r a n errores que van de m e d i a n a m e n t e molestos (como un formato de salida incorrecto) a catastróficos (por ejemplo, el sistema falla y causa serios d a ñ o s e c o n ó m i c o s o físicos). A medida que a u m e n t a n las c o n s e c u e n cias de un error, también se incrementa la presión para encontrar la c a u s a . A m e n u do, debido a la presión, un desarrollador del s o f t w a r e introduce dos errores m á s al tratar de corregir uno. ' • • •! "Todos soben que depurar es dos veces más difícil que escribir el programo. Por tanto, si aplica toda su inteligencia poro escribirlo, ¿cómo espera siquiera depurarlo?" Brian Kernighan TM

13.7.2 Consideraciones psicológicas

PDF Editor

Por desgracia, hay evidencia de que las destrezas para la depuración s o n innatas e n

el ser h u m a n o . Ciertas p e r s o n a s son b u e n a s p a r a ella; o t r a s no. Aunque la evidencia experimental s o b r e la depuración está abierta a m u c h a s interpretaciones, se han reportado g r a n d e s variaciones en la habilidad para la depuración en p r o g r a m a d o r e s con educación y experiencia similares.

412

PARTE DOS


Al c o m e n t a r los a s p e c t o s h u m a n o s d e la d e p u r a c i ó n , S h n e i d e r m a n [SHN80] i La depuración es u n a de las partes m á s frustrantes d e la programación. Incluye elemetos d e resolución d e p r o b l e m a s o d e r e t o s mentales, junto c o n el molesto reconocimie-: de que se ha cometido un error. La creciente ansiedad y escasa voluntad de aceptar la e .tencia de errores a u m e n t a n la dificultad d e la tarea. Por fortuna, se presenta un gran al vio y la tensión decrece c u a n d o el error finalmente... se corrige. A u n q u e s e a difícil " a p r e n d e r " a d e p u r a r , s e p r o p o n e n v a r i o s e n f o q u e s p a r a e l : b l e m a . S e e x a m i n a r á n e n la s i g u i e n t e s e c c i ó n .

HOGARSEGURO r

Depuración , La e s c e n a : Cubículo de Ed mientras se realizan la codificación y la prueba de unidad. Los a c t o r e s : Ed y Shakira, integrantes del equipo d e ingeniería del software de HogarSeguro. La c o n v e r s a c i ó n :

Ed: Sí, pero... S h a k i r a ( e n t r a n d o e n el cubículo): A ver, ¿cuc = el problema? Ed: Es complicado. Y además he estado revisando es-; durante, ¿cuánto?, cinco horas. No vas a encontrarle

S h a k i r a ( a s o m á n d o s e a ia e n t r a d a d e l cubículo): Hey... ¿dónde estabas a la hora del almuerzo?

S h a k i r a : Perdóname... ¿cuál es el problema?

Ed: Justo aquí... trabajando.

S h a k i r a ( e m p i e z a a p i n t a r s e u n a s o n r i s a en s u rostro): Mira, justo aquí, la variable eslablecerCondicionAlarma. ¿No debería ponerse er "falso" antes de que inicie el bucle?

S h a k i r a : Te ves mal... ¿qué es lo que pasa? Ed ( s u s p i r a n d o c o n f u e r z a ) : He estado trabajando en este error porque lo descubrí a las 9:30 de la mañana, y son las 2:45 y aún no tengo una pista. S h a k i r a : Pensé que estábamos de acuerdo en no dedicar más de una hora a depurar cosas por nuestra cuenta. En ese caso, tendríamos que buscar ayuda, ¿o no?

(Ed le explica el problema a Shakira, que lo mira d u r c r * 30 segundos sin hablar.)

(Ed se queda viendo la pantalla sin creerlo, se indine hacia delante y empieza a golpear su cabeza gentilmente contra el monitor. Shakira, ahora sonrieno: ampliamente, se levanta y sale.)

13.7.3 Estrategias de depuración Sin i m p o r t a r el e n f o q u e q u e s e a d o p t e , la d e p u r a c i ó n t i e n e u n o b j e t i v o p r i m o r á u l e n c o n t r a r y c o r r e g i r la c a u s a d e u n e r r o r d e l s o f t w a r e . El o b j e t i v o s e l o g r a c c n J n a n d o la e v a l u a c i ó n s i s t e m á t i c a , la i n t u i c i ó n y la s u e r t e . B r a d l e y [BRA85] d e s . — n i a s í el e n f o q u e d e la d e p u r a c i ó n :

TM

La depuración e s u n a aplicación simple y directa del método científico desarrollado h a : :

I

2 500 años. La esencia de la depuración consiste en ubicar la f u e n t e del problema

I

PDF Editor

:

causa) mediante partición binaria, m a n e j a n d o hipótesis d e trabajo q u e predigan n u e \ : valores que habrán de examinarse.

T o m e m o s un ejemplo sencillo, sin relación alguna c o n el software: en mi casa n o fur

ciona u n a lámpara. Si n o funciona n a d a e n la casa, la c a u s a debe ser un fusible fundid:

; I

u n a falla en el suministro d e energía eléctrica. Miro alrededor para ver si hay luz en el v;- I

CAPÍTULO 13

ESTRATEGIAS DE PRUEBA DEL SOFTWASE

413

cindario. Conecto la lámpara bajo sospecha en un enchufe que funcione y un aparato en buen estado en el enchufe bajo sospecha Y así se siguen alternando hipótesis y pruebas. En general, se han propuesto tres estrategias de depuración [MYE79I: 1) fuerza bruta, 2) seguimiento hacia atrás y 3) eliminación de la causa. "El primer poso poro corregir un programo es hocer que folie repetidamente (en el ejemplo más simple posible)," T. Duff

• tun rejemplo, .xrael ise :: Iralai de i problema linMuai ? as eso, ¡es jbuscar

Tácticas de depuración.

La categoría de depuración por la fuerza bruta tal vez

s e a el m é t o d o m á s c o m ú n y m e n o s eficiente para aislar la causa de un error del software. Los m é t o d o s de depuración por la fuerza bruta se aplican c u a n d o todo lo d e m á s falla. Al aplicar u n a filosofía de "dejemos que la c o m p u t a d o r a e n c u e n t r e el error", se hacen descargas de memoria, se invocan s e ñ a l e s en tiempo de ejecución y se carga el p r o g r a m a con instrucciones de salida. En algún lugar del p a n t a n o de información que se produce se espera e n c o n t r a r una pista que pueda conducir a la c a u s a de un error. Aunque la gran cantidad de información producida c o n d u z c a finalmente

al éxito, lo m á s frecuente es que haga desperdiciar tiempo y esfuerzo.

El rastreo hacia atrás es un e n f o q u e de depuración muy c o m ú n , que se utiliza con éxito en p e q u e ñ o s programas. E m p e z a n d o en el sitio d o n d e se ha descubierto un síntoma, se recorre hacia a t r á s el código fuente (manualmente) hasta hallar el sitio de la causa. Por desgracia, a medida que a u m e n t a el n ú m e r o de líneas del código, la cantidad de c a m i n o s hacia atrás se vuelve tan grande que resulta inmanejable. El tercer e n f o q u e para la depuración (eliminación de causas) lo determina la inducción o deducción e introduce el concepto d e partición binaria. Los d a t o s relacionados con el error se organizan para aislar las c a u s a s posibles. Se elabora una "hipótesis de la causa" y se aprovechan los d a t o s ya m e n c i o n a d o s para probar o d e s e c h a r la hipótesis. C o m o opción, se elabora una lista de t o d a s las c a u s a s posibles y s e aplican p r u e b a s para eliminar cada una de ellas. Si las p r u e b a s iniciales indican que determinada hipótesis de c a u s a e s prometedora, se refinan los datos para tratar de aislar el error. Depuración automatizada.

Cada uno de los e n f o q u e s de depuración anteriores

c o m p l e m e n t a n las h e r r a m i e n t a s de depuración que proporcionan soporte semiautomatizado al ingeniero de s o f t w a r e mientras se intentan estrategias de depuración. Hailpern y S a n t h a n a m (HAI02j r e s u m e n el e s t a d o de e s t a s h e r r a m i e n t a s c u a n d o indican: "...se han propuesto m u c h o s nuevos e n f o q u e s y se dispone de m u c h o s e n t o r n o s de depuración comerciales. Los e n t o r n o s de desarrollo integrado (EDI) proTM porcionan u n a m a n e r a de capturar algunos de los errores por defecto específicos del lenguaje (por ejemplo, caracteres faltantes de

fin-de-instrucción,

variables indefini-

PDF Editor

das, etc.) sin requerir compilación." Un área que ha a t r a p a d o la imaginación de la industria e s la visualización de las construcciones de programación n e c e s a r i a s c o m o m e d i o de análisis de p r o g r a m a s [BAE971. Se cuenta con una amplia variedad de compiladores de depuración, a y u d a s dinámicas para la depuración ("trazadores"), g e n e r a d o r e s a u t o m á t i c o s de c a s o s de prueba y h e r r a m i e n t a s de correlación de refe-

414

PARTE DOS



Depuración Objetivo: Estas herramientas proporcionan ayuda automatizada a quienes deben depurar problemas de software. El objetivo es proporcionar conocimiento difícil de obtener si se afronta el proceso de depuración manualmente. Mecánica: Casi todas las herramientas de depuración son específicas del lenguaje de programación y del entorno. Herramientas representativas: 4 Jprobe ThreodAnalyzer, desarrollado por Sitraka (www.sitraka.com), ayuda en la evaluación de problemas de subprocesos: bloqueos, detenciones y condiciones de carrera que representan serios peligros para el desempeño en aplicaciones de Java. C++ Test, desarrollado por Parasoft (www.parasoft.com), es una herramienta de prueba de unidad que soporta un amplio rango de pruebas en código C y C++. Las

características de depuración ayudan al diagnós - ';: los errores encontrados. CcdeMedic, desarrollado por NewPlanet Dotware (www.newplanetsoftw3re.com/medic/), proporciona. interfaz gráfica para el depurador UNIX estándar, gdfc ? implemento sus características más importantes. • gdb da soporte a C/C++, Java, PalmOS, varios sistema incrustados, lenguaje ensamblador, FORTRAN yMoauc-1 BugCollector Pro, desarrollado por Nesbitt Software Cora (www.nesbitt.com/), implemento una base de datos multiusuario que ayuda al equipo de software regisfrc errores reportados y otras solicitudes de mantenimienc • administración de flujo de trabajo de depuración. GNATS, una aplicación freeware (www.gnu.org/software/gnats/), es un conjunto x herramientas para registrar informes de error.

r e n d a s c r u z a d a s . Sin e m b a r g o , las 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 la ción c u i d a d o s a b a s a d a e n u n m o d e l o de d i s e ñ o c o m p l e t o y u n c ó d i g o f u e n t e El f a c t o r h u m a n o .

N i n g ú n análisis de los e n f o q u e s y las h e r r a m i e n t a s de

ción e s t a r í a c o m p l e t o sin m e n c i o n a r u n p o d e r o s o aliado: ¡los d e m á s ! Un p vista f r e s c o , d e s p e j a d o d e h o r a s d e f r u s t r a c i ó n , p u e d e h a c e r m a r a v i l l a s . 5 Una m a final p a r a la d e p u r a c i ó n sería: " ¡ C u a n d o t o d o lo d e m á s falle, pida ayuda!"

13.7.4 Corrección del error C u a n d o s e e n c u e n t r a u n e r r o r d e b e corregirse. P e r o c o m o ya s e h a i n d i c a ; : c o r r e g i r u n e r r o r p u e d e n i n t r o d u c i r s e o t r o s y, p o r lo t a n t o , c a u s a r m á s d a ñ : s o l u c i o n a r el p r o b l e m a . Van Vleck [VAN89] s u g i e r e t r e s p r e g u n t a s s i m p l e s q u e ría p l a n t e a r s e t o d o i n g e n i e r o del s o f t w a r e a n t e s de h a c e r la " c o r r e c c i ó n " q u e efe n e la c a u s a del error: ^ •

Cuando corrija un error,

¿qué preguntas debo hacerme?

I . ¿La causa del error se repite en otra parte del programa?

En m u c h a s situac

u n e r r o r se p r o d u c e e n u n p r o g r a m a d e b i d o a u n p a t r ó n e r r ó n e o de lógica p o d r í a r e p e t i r s e e n c u a l q u i e r lugar. La c o n s i d e r a c i ó n explícita del TM p a t r ó n : gico p u e d e llevar al d e s c u b r i m i e n t o d e o t r o s e r r o r e s .

PDF Editor

Las herramientas expuestas aquí representan una muestra de esta categoría. En casi todos ks.sos los nombres de las mismas son marcas registradas de sus respectivos desarrolladores El concepto de programación por pares (recomendada como parte del modelo de proceso cíe gramación extrema analizado en el capítulo 4) proporciona un mecanismo para la depuración • tras se diseña y codifica el software

CAPÍTULO 13


415

2 . ¿Cuál es el "siguiente error" que podría introducirse con la corrección que está a punto de realizarse? Antes de la corrección se debe evaluar el código fuente (o mejor aún, el diseño) para evaluar el acoplamiento entre las estructuras lógicas y de datos. Si la corrección se realiza en una sección del programa con un acoplamiento elevado, debe tenerse mucho cuidado cuando se haga cualquier cambio. 3 . ¿Qué debió hacerse para evitar este error desde el principio? Esta pregunta e s el primer paso hacia el establecimiento de un enfoque estadístico de aseguramiento de la calidad del software (capítulo 26). Si se corrige el proceso junto con el producto, se eliminará el error del programa actual y de todos los programas futuros.

La prueba ocupa el mayor porcentaje del esfuerzo técnico en el proceso del software. Apenas se empiezan a comprender las sutilezas de la planeación, la ejecución y el control sistemáticos de las pruebas. El objetivo de la prueba del software es descubrir errores; se cumple planeando y ejecutando una serie de pasos (pruebas de unidad, integración, validación y sistema). Las pruebas de unidad e integración se concentran en la verificación funcional de cada componente y en la incorporación de componentes en la arquitectura del software. La prueba de validación demuestra el cumplimiento con los requisitos del software, y la prueba del sistema valida el software una vez que se ha incorporado a un sistema mayor. Cada paso de prueba se completa mediante una serie de técnicas sistemáticas de prueba que ayudan a diseñar los casos de prueba. Cada paso de prueba ensancha el grado de abstracción con que se considera el software. A diferencia de la prueba (una actividad sistemática y planeada), la depuración debe considerarse un arte. La actividad de depuración empieza con la indicación sintomática de un problema y debe rastrear la causa del error. Entre los muchos recursos disponibles durante la depuración, el m á s valioso e s el consejo de otros integrantes del equipo de ingeniería del software. La necesidad de crear software de la mayor calidad exige un enfoque de prueba TM más sistemático. Para citar a Dunn y Ullman [DUN82]: Lo indispensable e s una estrategia general que abarque el espacio de prueba estratégico

PDF Editor

con una metodología tan deliberada como lo era el desarrollo sistemático en que se basaban el análisis, el diseño y la codificación.

En este capítulo s e ha examinado el espacio de prueba estratégico, tomando en cuenta los pasos que tienen la mayor probabilidad de conseguir el principal objetivo de la prueba: encontrar y eliminar errores de manera ordenada y efectiva.

416

PARTE DOS

P R Á C n C A DE LA INGENIERÍA DEL SOFTWARE

[BAE971 Baecker, R., C. DiGiano y A. Marcus, "Software Visualization of Debugging Communications of the ACM, vol. 40. núm. 4. abril de 1997 y otros ensayos en la misma t (BE184] Beizer, B„ Software System Testing and Quality Assurance, Van Nostrand-Reinhold [BER93] Berard, E„ Essays on Object-Oriented Software Engineering. vol. 1, Addison-Wesle> J [BIN94] Binder, R., 'Testing Object-Oriented Systems: A Status Report", en American Pro, vol. 7, núm. 4, abril de 1994. ruta crítica, pp. 23-28. [BOE81] Boehm, B., Software Engineering Economics, Prentice-Hall, 1981, p. 37. [BRA85] Bradley, J.H., "The science and Art of Debugging", en Computerworld, 19 de ag 1985, pp. 35-38. [CHE90] Cheung, W. H., J. P. Black y E. Manning, "A Framework for Distributed Debuggir r IEEE Software, enero de 1990, pp 106-115. [DUN82] Dunn, R. y R Ullman, Quality Assurance for Computer Software, McGraw-Hill, 1982.: [GIL951 Gilb, T., "What We Fail To Do In Our Current en Testing Culture", en Testing Newsletter (edición en linea, [email protected]), Software Research, Inc., e n e r o de [HAI02] Hailpem, B. y P. Santhanam, "Software Debugging, Testing and Verification", en H Systems Joumal, vol. 41, núm. 1,2002, disponible en http://www.research.ibm.com, joumal/sj/411/hailpem.html. [IEEO11 Software Reiiabitity Engineering I2th International Symposium, IEEE, 2001. [MC096] McConnell, S., "Best Practices: Daily Build and Smoke Test", en IEEE Software : núm. 4, julio de 1996, pp. 143-144. IMIL77] Miller, E., 'The Philosophy of Testing", en Program Testing Techniques, IEEE Ce Society Press, 1977, pp. 1-3. [MUS891 Musa, J. D. y A. F. Ackerman, "Quantifying Software Validation: When to Stop Te en IEEE Software, mayo de 1989, pp. 19-27. [MYE79] Myers, G., The Art of Software Testing, Wiley, 1979[SH083] Shooman, M. L., Software Engineering, McGraw- Hill, 1983. (SHN80] Shneiderman, B., Software Psychology, Winthrop Publishers. 1980, p. 28. [SIN99] Singpurwalla, N. y S. Wilson, Statistical Methods in Software Engineering: Reliab Risk, Springer-Verlag, 1999. |VAN891 Van Vleck, T„ 'Three Questions About Each Bug You find", en ACM Software l Notes, vol. 14, núm. 5. julio de 1989, pp. 62-63. [WAL89] Wallance, D. R. y R. U. Fujii, "Software Verification and Validation: An Overvie« i IEEE Software, mayo de 1989, pp. 10-17. [YOU 75] Yourdon, E., Techniques of Program Structure and Design, Prentice-Hall, 1975.

1 3 . 1 . Con palabras propias, describase la diferencia entre verificación y validación. ¿L métodos de diseño de casos de prueba y estrategias de prueba? 1 3 . 2 . Elabórese una lista de algunos problemas que pudieran estar asociados con la < de un grupo independiente de prueba. ¿Lo integran las mismas p e r s o n a s que el gn aseguramiento de la calidad del software?

TM

1 3 . 3 . ¿Siempre es posible desarrollar una estrategia para probar s o f t w a r e que secuencia de p a s o s de prueba descrita en la sección 13.1.3? ¿Cuáles son las complicaciones que podrían surgir para sistemas incrustados?

PDF Editor

1 3 . 4 . ¿Por qué es difícil aplicar p r u e b a s de unidad a un módulo altamente acc

1 3 . 5 . El concepto de "antierror" (sección 13.3.1) es una m a n e r a e x t r e m a d a m e n t e efec proporcionar depuración integrada cuando se descubre un error: a) b) c)

Desarrollar un conjunto de directrices antierror. Analizar las ventajas de usar esta técnica. Analizar las desventajas de usar esta técnica.

CAPÍTULO 13

ESTRATEGIAS DE PRUEBA DEL SOFT.VAKE

417

13.6. ¿Cómo afecta la calendarización la prueba de integración? 13.7. ¿La prueba de unidad es posible (o incluso deseable) en todas las circunstancias? Proporcionar ejemplos que justifiquen la respuesta. 1 3 . 8 . ¿Quién debe aplicar la prueba de validación: el desarrollador o el usuario del software? Justifiqúese la respuesta. 13.9. Desarrollar una estrategia de prueba completa para el sistema HogarSeguro analizado en todo el libro. Documéntese en una Especificación de prueba. 1 3 . 1 0 . Como proyecto de clase, desarrollar una Guía de depuración para instalarla. Deben proporcionarse consejos orientados al lenguaje y al sistema ¡qué se hayan aprendido en la escuela de la vida! Empezar con una descripción esquemática de los temas que revisarán los compañeros de clase y el profesor.

Casi todos los libros sobre la prueba del software analizan estrategias junto con métodos para el diseño de casos de prueba. Todos los siguientes libros analizan los principios, los conceptos, las estrategias y los métodos de prueba: Craig y Kaskiel (Systematic Software Testing, Artech House, 2002), Tamres (Introducing Software Testing, Addison-Wesley, 2002), Whittaker (How To Break Software, Addison-Wesley, 2002), Jorgensen (Software Testing: A Craftman's Approach, CRC Press, 2002), Splaine y sus colegas (The Web Testing Handbook, Software Quality Engineering Publishing, 2001), Patton (Software Testing, Sams Publishing, 2000), Kaner y sus colegas (Testing Computer Software, segunda edición, Wiley, 1999), Black (Managing the Testing Process, Microsoft Press, 1999) y Perry (Surviving the Top Ten Challenges of Software Testing: A People-Oriented Approach, Dorset House, 1997) también atienden las estrategias de prueba del software. Para los lectores interesados en métodos de desarrollo ágil de software, Crispin y House {Testing Extreme Programming, Addison-Wesley, 2002) y Beck (Test Driven Development: By Exampie, Addison-Wesley, 2002) presentan estrategias y tácticas de prueba para Programación Extrema. Kamer y sus colegas (Lessons Learned in Software Testing, Wiley, 2001) presentan una colección de más de 300 "lecciones" pragmáticas (directrices) que toda persona dedicada a la prueba de software debe aprender. Watkins (Testing IT: An Off the Shetf Testing Process, Cambridge University Press, 2001) establece un marco conceptual de prueba efectivo para todos los tipos de software desarrollado y adquirido. Lewis (Software Testing and Continuous Quality Improvment, CRC Press, 2000) y Koomen y sus colegas (Test Process Improvment, Addison-Wesley, 1999) analizan estrategias para la mejora continua del proceso de prueba. Sykes y McGregor (Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001), Bashir y Goel (Testing Object-Oriented Software, Springer-Verlag, 2000), Binder, Testing Object Oriented Systems, Addison-Wesley, 1999), Kung y sus colegas (Testing Object Oriented Software, 1EE Computer Society Press, 1998) y Marick (The Craft of Software Testing, Prentice Hall, 1997) presentan estrategias y métodos para prueba de sistemas orientados a objetos. Directrices para la depuración se encuentran en libros de Agans (Debugging: The Nine Indispensable Rules for Finding Even The Most Elusive Hardware and Software Problems, AM ACON, 2002), Tells y Hsieh (The Science of Debugging, The Coreolis Group, 2001), Robbins (Debugging Applications, Microsoft Press, 2000) y Dunn (Software Defect Removal, McGraw-Hill, 1984). Rosenberg (How Debuggers Work, Wiley, 1996) atiende la tecnología de las herramientas de depuTM ración. Younessi (Object-Oriented Defect Management of Software, Prentice-Hall, 2002) presenta técnicas para administrar los defectos que se encuentran en sistemas orientados a objetos. Beizer [BEI84] presenta una interesante "taxonomía de los errores" que puede llevar a métodos efectivos para la planeación de pruebas. Ball (Debugging Embedded Microprocessor Systems, Newnes Publishing, 1998) atiende la naturaleza especial del software incrustado de microprocesador. En Internet se encuentra una amplia variedad de fuentes de información sobre estrategias de prueba del software. Una lista actualizada de referencias en la World Wide Web que resultan relevantes para las estrategias de prueba del software se encuentran en el sitio Web SEPA: http://www.mhhe.com/pressman.

PDF Editor

C A P I T U L O

T É C N I C A S DE P R U E B A DEL S O F T W A R E

CONCEPTOS CLAVE AVI

437

complejidad (¡domática . . . 4 2 6 iadtidod d e prueba

419

gráficas de flujo

.423

partición equivalente . . . 4 3 6 patrones

456

pruebas

L

a s p r u e b a s r e p r e s e n t a n u n i n t e r e s a n t e r e t o p a r a l o s i n g e n i e r o s de se i re, q u i e n e s p o r n a t u r a l e z a s o n p e r s o n a s c o n s t r u c t i v a s . Las p r u e b a s re ;B r e n q u e el d e s a r r o l l a d o r d e s c a r t e n o c i o n e s p r e c o n c e b i d a s d e lo r _ ;

" c o r r e c t o " e n el s o f t w a r e y e n t o n c e s d i s e ñ e difíciles c a s o s d e p r u e b a p a r a perlo". Beizer [BEI90] d e s c r i b e b i e n e s t a s i t u a c i ó n c u a n d o a f i r m a : Es un mito que si realmente fuéramos buenos para programar no tendríamos que purar errores. Si tan sólo pudiéramos concentrarnos, si todos usaran programa: a estructurada, diseño descendente o tablas de decisión, si los programas se escr.r -s ran en SQUISH, si tuviéramos las balas plateadas correctas, entonces no habría e— • res. Ése es el mito. Hay errores, dice el mito, porque somos malos en lo que h a c e - > y si somos malos en eso, debemos sentimos culpables. Por tanto, el diseño de rraaj bas y de casos de prueba es una admisión de la falla, que instila una buena do.- ; _í culpa. Y el tedio de probar sólo es un castigo por nuestros errores. ¿Castigo por ; - •

b a s a d a s en el escenario . . . 4 4 4 b a s a d a s en fallas

443

debudes . . . . 4 3 2

¿Por ser seres humanos? ¿Culpables de qué? ¿De no alcanzar una perfección i n h u r a j na? ¿Por no distinguir entre lo que otro programador piensa y lo que dice? ¿Pe: -1 usar la telepatía? ¿Por n o resolver los problemas de las comunicaciones humanas han estado presentes., durante cuarenta siglos?

i

de caja blanca . 4 2 3

¿Las p r u e b a s d e b e n p r o v o c a r c u l p a ? ¿Las p r u e b a s s o n r e a l m e n t e d e s t r _ : i

de caja negra . 4 3 3

La r e s p u e s t a e s ¡no!

de la estructura de c o n t r o l . . . 4 3 0

s o f t w a r e . Este tipo d e d i s e ñ o s e c o n c e n t r a e n u n c o n j u n t o d e t é c n i c a s

de nivel de dose

En e s t e c a p i t u l o s e a n a l i z a r á n t é c n i c a s p a r a el d i s e ñ o d e c a s o s d e p n . r : ai creación de casos de prueba q u e cumplan con objetivos generales y cor ^

447

t r a t e g i a s de p r u e b a a n a l i z a d a s e n el c a p í t u l o 13.

de r u t a básica . 4 2 3 a objetos . . . 4 4 1

¿ Q u é e s ? Una vez generado e! código fuente, es necesario probar el software p a r a descubrir (y corregir) la mayor cantidad de errores posible antes de entregado al cliente. Su objetivo es diseñar una serie d e casos de prueba que tengan una alta probabilidad de encontrar errores, ¿pero cómo? Aquí es donde entran en escena las técnicas d e prueba del software. Estas técnicas proporcionan directrices sistemáticas p a r a prue-

bas de diseño que 1) comprueben la lógica ' * • na y las interfases de todo componente de ; r - í TM ware y 2) comprueben los dominios de e r r r o x f salida del programa p a r a descubrir errores en m función, comportamiento y desempeño. ¿ Q u i é n l o h a c e ? Durante las etapas inicióle: J proceso, un ingeniero de software realiza : : ias pruebas. Sin embargo, a medida que c a l z a este proceso se irán incorporando espec r I tas en pruebas.

PDF Editor 4IB

CAPÍTULO 14

-_5or q u é es importante?

C o n las revisiones y

c o l a b o r a con otra. A m e d i d a q u e las clases se

erras a c t i v i d a d e s d e a s e g u r a m i e n t o d e la cali-

i n t e g r a n p a r a f o r m a r un s u b s i s t e m a , se a p l i c a la

d a d del s o f t w a r e se p u e d e n y d e b e n d e s c u b r i r

p r u e b a d e u s o , junto c o n los e n f o q u e s b a s a d o s

e r r o r e s , p e r o n o b a s t a c o n ello. El cliente p r u e b a

en f a l l a s , p a r a c o m p r o b a r las c l a s e s q u e c o l a b o -

d p r o g r a m a c a d a v e z q u e lo e j e c u t a . Por t a n t o ,

r a n . Por último, los c a s o s d e u s o a y u d a n a dise-

se tiene q u e e j e c u t a r el p r o g r a m a a n t e s d e q u e

ñ a r p r u e b a s q u e p e r m i t a n d e s c u b r i r e r r o r e s a l nivel d e v a l i d a c i ó n del s o f t w a r e . En t o d o c a s o , el

fiegue a l cliente, y el objetivo e s p e c í f i c o s e r á e n contrar y eliminar t o d o s los e r r o r e s . La localizac ó n d e la m a y o r c a n t i d a d d e e r r o r e s r e q u i e r e a p l i c a r p r u e b a s d e m a n e r a sistemática y d i s e ñ a r casos d e p r u e b a e m p l e a n d o técnicas definidas.

¿Cuáles son los p a s o s ?

En 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 el s o f t w a r e se p r u e b a d e s d e d o s p e r s p e c t i v a s d i f e r e n t e s : 1) la l ó g i c a i n t e r n a d e l

1

419


o b j e t i v o e s e n c o n t r a r el n ú m e r o m á x i m o d e errores con la m í n i m a c a n t i d a d d e e s f u e r z o y t i e m p o .

¿Cuál e s el producto obtenido?

Se diseña y d o c u m e n t a u n c o n j u n t o d e c a s o s d e p r u e b a dis e ñ a d o p a r a c o m p r o b a r la l ó g i c a i n t e r n a , las interfaces, las c o l a b o r a c i o n e s entre c o m p o n e n t e s y los r e q u i s i t o s internos; s e d e f i n e n los r e s u l t a d o s

p r o g r a m a se c o m p r u e b a m e d i a n t e t é c n i c a s d e

e s p e r a d o s y se r e g i s t r a n los r e s u l t a d o s r e a l e s .

diseño d e c a s o s d e p r u e b a d e " c a j a b l a n c a " , 2) los requisitos d e l s o f t w a r e s e c o m p r u e b a n e m -

¿Cómo p u e d o estar seguro d e q u e lo h e h e c h o correctamente? C u a n d o se e m p i e c e

p l e a n d o técnicas d e diseño d e casos d e p r u e b a

l a p r u e b a d e b e c a m b i a r s e d e p u n t o d e vi s t a . ¡El

de "caja negra".

o b j e t i v o e s " r o m p e r " el s o f t w a r e ! D e b e n d i s e -

En el c a s o d e a p l i c a c i o n e s

o r i e n t a d a s a o b j e t o s , la " p r u e b a " e m p i e z a a n t e s

ñ a r s e c a s o s d e p r u e b a e n f o r m a m e t i c u l o s a y re-

d e la e x i s t e n c i a del c ó d i g o f u e n t e , p e r o u n a v e z g e n e r a d o é s t e , se d i s e ñ a r á u n a s e r i e d e p r u e b a s

v i s a r s e q u e los c a s o s d e p r u e b a c r e a d o s a b a r q u e n t o d o lo d i s e ñ a d o . A d e m á s , e s p r e c i s o e v a -

p a r a c o m p r o b a r operaciones con una clase y

luar la c o b e r t u r a d e la p r u e b a y d a r l e segui-

e x a m i n a r si e x i s t e n e r r o r e s m i e n t r a s u n a c l a s e

miento a las actividades d e detección d e errores.

14.1

F U N D A M E N T O S DE I.AS PRUEBAS DEL SOFTWARE En el capítulo 5 se analizaron los objetivos y principios fundamentales de las pruebas. Se recordará que el objetivo de las pruebas es encontrar errores y que una buena prueba es la que tiene una alta probabilidad de encontrar un error. Por tanto, cuando un ingeniero de software diseñe e implemente un sistema o un producto de cómputo, debe tener en mente la facilidad de prueba. Al mismo tiempo, las propias pruebas deben mostrar un conjunto de características para alcanzar el objetivo de encontrar la mayor cantidad de errores con un mínimo de esfuerzo. Todo programo hoce algo bien; pero tal vez sea lo que no queremos que haga."

Anónimo

TM

Facilidad de prueba. James Bach 1 proporciona la siguiente definición: "La facilidad de prueba del software indica simplemente si es fácil o no probar (un programa de computadora)." Las siguientes características propician la creación de software que tenga facilidad de prueba.

PDF Editor 1

Los párrafos siguientes se usan con permiso de J a m e s Ba. n copyright, 1994) y se han a d a p t a d o del

materia! q u e originalmente apareció publicado en el grupo d e noticias comp.software-eng.

420

¿Cuáles • s o n las característkas de la facilidad de prueba?

PARTE D O S


Operatividad. "Cuanto mejor funcione, con mayor eficiencia podrá probarse ¿I un sistema está diseñado e implementado con la calidad en mente, serán relat -• mente escasos los errores que bloquearán la ejecución de las pruebas, lo que p e ~ » tirá el avance de éstas sin correcciones ni reinicios. Observabilidad. "Lo que se ve es lo que se prueba." Las entradas proporcic *aj das como parte de la prueba producen salidas distintas. Los estados y las varia.*'csi del sistema son visibles y pueden consultarse durante la ejecución. La salida ir .»• rrecta se identifica fácilmente. Los errores internos se detectan y reportan en f o r r a automática. El código fuente es accesible. Controlabilidad. "Cuanto mejor se controle el software, mejor se a u t o m a t i z a . ' » y mejorarán las pruebas." El ingeniero de pruebas controla directamente los estad las variables de software y hardware. Las pruebas pueden ser convenientemer .; a pecificadas, automatizadas y reproducidas. Capacidad para d e s c o m p o n e r . Al controlar el alcance de la prueba, se ¿ • rán los problemas m á s rápidamente y se aplicarán las pruebas nuevamente cor -J yor inteligencia. El sistema de software se construye a partir de módulos i n d e r J dientes que también se prueban independientemente. Simplicidad. "Cuanto menos haya que probar, m á s rápido se hará." El p r o g r ^ l debe mostrar simplicidad Juncional (por ejemplo, el conjunto de características es M mínimo necesario para satisfacer los requisitos), simplicidad estructural (la arc_ J tura aparece en módulos para limitar la propagación de fallas) y simplicidad ck : <• go (se adapta un estándar de codificación para facilitar la inspección y el m a n » miento.) Estabilidad. "Cuantos m e n o s cambios haya, menores alteraciones habrá :T I prueba." Los cambios ai software son poco frecuentes, se controlan cuando o c - a J y no invalidan las pruebas existentes. El software se recupera bien de las fallas ] Facilidad de c o m p r e n s i ó n . "Cuanta mayor información se tenga, con ma;. teligencia se aplicará la prueba." Se comprenden bien el diseño de la arquitec~_al las dependencias entre componentes internos, externos y compartidos. Se t i e ' t • ceso instantáneo a la documentación técnica, está bien organizada, es espe. S p detallada y exacta. Los cambios al diseño se comunican a quienes aplican las bas. Un ingeniero usará los atributos que sugiere Bach para desarrollar una configura*® TM de software (es decir, programas, datos y documentos) que sea sensible a la r ~ J f c

PDF Editor

'Los errores son mós comunes en el softwore, tienen más copacidod de expandirse y representan más problemas • en otras tecnologías." David

Características de la prueba. ¿Y qué hay con las propias pruebas? Kaner Nguyen [KAN93] sugieren los siguientes atributos para una buena prueba:

:

M

CAPÍTULO 14

¿0«é es uno *Wno"

1

•

421


buena prueba tiene una elevada probabilidad de encontrar un error. Alcanzar este objetivo requiere que la persona que aplica la prueba comprenda el software y trate de desarrollar una imagen mental de la manera en que puede

Una

fallar. Lo ideal es probar los tipos de fallas. Por ejemplo, un tipo de falla posible en una interfaz gráfica de usuario es la incapacidad de reconocer la posición correcta del ratón; por tanto, se diseñaría un conjunto de pruebas para probarlo tratando de evidenciar un error en el reconocimiento de su posición. 2 . Una buena prueba no es redundante. El tiempo y los recursos destinados a las pruebas son limitados. No hay razón para realizar una prueba que tenga el mismo propósito que otra. Cada prueba debe tener un propósito diferente (aunque las diferencias sean sutiles). 3. Una buena prueba debe ser "la mejor de su clase" [KAN93J. En un grupo de pruebas con un objetivo similar y recursos limitados podría optarse por la ejecución de un solo subconjunto de ellas. En este caso, debe usarse la prueba que tenga la mayor probabilidad de descubrir un tipo completo de errores. 4 . Una buena prueba no debe ser ni muy simple ni demasiado compleja. Aunque a veces es posible combinar una serie de pruebas en un caso de prueba, los posible efectos colaterales asociados con este enfoque podrían enmascarar errores. En general, cada prueba debe ejecutarse por separado.

HOGARSEGURO Diseño

de pruebas

únicas

L a e s c e n a : Cubículo de Vinod. a c t o r e s : Vinod y Ed, integrantes del equipo de ¡ni del software HogarSeguro conversación: : Así que éstos son los casos de prueba que pre> ejecutar con la operación validacionConiraseña. : Sí, cubren muchos d e los posibles tipos de contrase-c que podría ingresar un usuario. V i n o d : Déjame ver señalas que la contraseña correcto será 8080, ¿verdad? I d : Ajó. V i n o d : ¿Y especificas las contraseñas 1234 y 6 7 8 9 pa-a encontrar errores en el reconocimiento de contraseñas no válidas?

V i n o d : Está bien, pero no veo mucho caso en ejecutar los entradas 1234 y 6789. Son redundantes... prueban lo mismo, ¿o no? Ed: Bueno, son valores diferentes. V i n o d : Es cierto, pero si 1234 no descubre un error... en otras palabras... la operación validaáónContraseña detecta que la contraseña no es válida, así que no es probable que 6 7 8 9 nos muestre algo nuevo. Ed: Ya sé lo que quieres decir.

TM

V i n o d : No estoy tratando de ser puntilloso... sólo que tenemos tiempo limitado para las pruebas, de modo que es buena idea ejecutar pruebas que tengan una alta probabilidad de encontrar nuevos errores.

PDF Editor E d : Correcto, y también pruebo contraseñas que son pa-ecidas a la correcta, como 8081 y 8180.

Ed: No hay problema... Pensaré un poco más en esto.

422

PARTE DOS

14.2


PRUEBAS PS CAJA NESRA Y C A J A BLANCA

« •

Hay una de dos maneras de probar cualquier producto construido (y casi cualc- iet cosa): 1) si se conoce la función específica para la que se diseñó el producto, se ar#-| can pruebas, que demuestren que cada función e s plenamente operacional, miertraa se buscan los errores de cada función; 2) si se conoce el funcionamiento interne a a producto, se aplican pruebas para asegurarse de que "todas las piezas encajan -¡ decir, que las operaciones internas se realizan de acuerdo con las especificado-rs± I y que se han probado todos los componentes internos de manera adecuada. Al rc-l mer enfoque de prueba se le denomina prueba de caja negra; al segundo, prueba :e| caja blanca. 2

\CLÁVE

Las pruebas de caja negra son las que se aplican a la interfaz del software prueba de este tipo examina algún aspecto funcional d e un sistema que tiene relación con la estructura lógica interna del software. La prueba de caja blanca . software se basa en un examen cercano al detalle procedimental. Se prueban la; 1 tas lógicas del software y la colaboración entre componentes, al proporcionar de prueba que ejerciten conjuntos específicos de condiciones, bucles o ambos "Sólo hoy una reglo poro diseñar cosos de pruebo: abarcor lodos las funciones, pero no diseñor demasiados caso-.

Los pruebos de cojo blanco sólo pueden

Tsuneo Yamou

diseñarse después del diseño al nivel de componentes (o código fuente), b necesario que los detalles lógicos del programa estén disponibles.

A primera vista, parecería que toda prueba de caja blanca completa llevaría : programa 100 por ciento correcto. Todo lo que se necesita hacer es identificar los caminos lógicos, desarrollar casos de prueba para ejercitarlos y evaluar dos; e s decir, generar casos de prueba para comprobar exhaustivamente la 1c programa. Por desgracia, la prueba exhaustiva presenta ciertos problemas de tica (consúltese el análisis del recuadro). Sin embargo, la prueba de caja blar :ii

*

Prueba exhaustiva • Considérese un programa d e cien líneas en

gico" porque no existe) p a r a aplicar una prueba

lenguaje C. Después d e alguna declaración bá-

va. El procesador desarrolla un caso d e prueba, lo

sica d e datos, el p r o g r a m a contiene dos bucles anidados que se ejecutan d e 1 a 2 0 veces c a d a uno, lo que d e p e n d e

y evalúa los resultados en un milisegundo. Si t r a b a j e horas diarias, 3 6 5 días al año, necesitaría 3 170 <

d e la condición especificada en la entrada. Dentro del bu-

ra probar el programa. Esto causaría,TM indudableme"?

cle interno se requieren cuatro construcciones si-entonces-

desastre en casi todos los calendarios d e desarrollo

si_no l¡f-then-else).

jEl programa tendrá alrededor de 1 0 u

posibles rutas de ejecución!

Por tanto, es razonable asegurar que resulta i" aplicar una prueba exhaustiva en sistemas grandes os

PDF Editor Poner este número en perspectiva requiere suponer que

^se ha desarrollado un procesador d e prueba mágico ("má-

2

Los términos prueba funcional y prueba estructurada suelen u s a r s e en lugar d e prueba de

y de caja blanca, respectivamente.

CAPÍTULO 14

423

TÉCNICAS DE PRUEBA DEL SOFT.VA3E

d e b e d e s e c h a r s e n u n c a c o m o impráctica. Es posible seleccionar y c o m p r o b a r un núm e r o limitado de rutas lógicas importantes; a d e m á s de probar la validez d e las principales estructuras de datos.

14.3

PRUEBAS PE C A J A BLANCA La prueba de caja blanca, en ocasiones llamada prueba de caja de cristal, es un método de diseño que usa la estructura de control descrita c o m o parte del diseño al nivel d e c o m p o n e n t e s para derivar los c a s o s de prueba. Al emplear los m é t o d o s de prueba de caja blanca, el ingeniero del s o f t w a r e podrá derivar c a s o s de prueba que 1) garanticen que t o d o s las rutas independientes dentro del m ó d u l o se h a n ejercitado por lo m e n o s una vez, 2) ejerciten los lados verdadero y falso de t o d a s las decisiones lógicas, 3) ejecuten todos los bucles e n sus límites y dentro de sus límites operacionales, y 4) ejerciten estructuras de d a t o s internos para a s e g u r a r su validez. "Los errores pululan en los rincones y se acumulan en los límites." Boris Beizer

14.4

P R U E B A P E LA RUTA B Á S I C A La prueba de la ruta básica es una técnica de prueba de caja blanca que propuso inicialmente Tom McCabe [MCC76]. El método de la ruta básica permite que el diseñador de c a s o s de prueba obtenga una medida de complejidad lógica de un diseño procedimental y que use esta medida c o m o guía para definir un conjunto básico de rutas de ejecución. Los c a s o s de prueba derivados para ejercitar el conjunto básico deben garantizar que se ejecuta cada instrucción del p r o g r a m a por lo m e n o s u n a vez durante la prueba.

CONSEJO^

14.4.1 Notación de gráfica de flujo Antes de tratar el m é t o d o de la ruta básica, d e b e presentarse u n a notación simple

xbe dibujarse jvJiode cuando la lógico de ~n te seo .El de flujo trozar del programa de más legible.

para la representación del flujo de control, llamado gráfica de flujo [o gráfica del programa).3 La gráfica de flujo describe un flujo de control lógico e m p l e a n d o la notación ilustrada en la figura 14.1. Cada construcción estructurada (capítulo 11) tiene su símbolo correspondiente en la gráfica de flujo. El uso de una gráfica de flujo se ilustra considerando la representación del diseTM ñ o procedimental de la figura 14.2a. Aquí se describe la estructura d e control del prog r a m a m e d i a n t e un diagrama de flujo. En la figura 14.2b se correlaciona (o mapea)

PDF Editor

el diagrama de flujo con su gráfica de flujo correspondiente (suponiendo que no existen condiciones c o m p u e s t a s e n los d i a m a n t e s de decisión del diagrama de flujo). To3

En realidad, el método de la ruta básica se aplica sin el uso de las gráficas de flujo. Sin embargo, sirven como notación útil para comprender el flujo de control e ilustrar el enfoque

424

PARTE D O S


m a n d o c o m o referencia la figura 14.2b, cada círculo, llamado nodo de gráfica de fk. jo, representa una o más instrucciones procedimentales. Una secuencia de recu: dros de proceso y un diamante de decisión se correlaciona con un solo nodo. Las fe chas en la gráfica de flujo, llamadas aristas o enlaces, representan el flujo de cortr: y son análogos a las flechas de los diagramas de flujo. Una arista debe terminar ST un nodo, aunque el nodo n o represente ninguna instrucción procedimental (porl ejemplo, véase el símbolo en la gráfica de flujo para la construcción if-then-else de a figura 14.1). Las áreas que limitan aristas y nodos se denominan regiones. C u a - : • se cuentan las regiones se incluyen las áreas ubicadas fuera de la gráfica. 4

Las construcciones estructuradas en forma de gráfica d e flujo:

Notación d e gráfica de flujo.

Si

Mientras

Hasta

Donde cada circulo representa una o más instrucciónen LDP sin ramificaciones o de código fuente

TM

PDF Editor 4

Un análisis más detallado de las gráflcas y su aplicación se presentará en la sección 14.6.1

C A P Í T U L O 14

425


Cuando se encuentran condiciones compuestas en un diseño procedimental, la generación de una gráfica de flujo se vuelve ligeramente más complicada. Una condición compuesta ocurre cuando hay uno o m á s operadores booleanos (OR, AND, NAND, ÑOR) en una instrucción condicional. Tomando como referencia la figura 14.3, el segmento en LDP se traduce a la gráfica de flujo mostrada. Obsérvese que s e crea un nodo separado para cada una de las condiciones a y b en la instrucción IF a OR b. Cada nodo que contiene una condición es un nodo predicado y se caracteriza porque de él e m a n a n dos o m á s aristas.

14.4.2 Rutas independientes del programa Una ruta independiente e s cualquier ruta del programa que ingresa por lo m e n o s un nuevo conjunto de instrucciones de procesamiento o una nueva condición. Cuando se explica desde el punto d e vista de una gráfica de flujo, una ruta independiente debe recorrer por lo menos una arista que no se haya recorrido antes. Por ejemplo, a continuación se presenta un conjunto de rutas independientes en la gráfica de (lujo de la figura 14.2b: ruta 1: 1-11 ruta 2: 1-2-3-4-5-10-1-11 ruta 3: 1-2-3-6-8-9-10-1-11 ruta 4: 1-2-3-6-7-9-10-1-11 Obsérvese que cada nuevo camino ingresa una nueva arista. El camino 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 n o se considera una ruta independiente porque se trata simplemente de una combinación de rutas ya especificadas y n o recorre ninguna arista nueva. Los caminos 1, 2, 3 y 4 constituyen un conjunto básico para la gráfica de flujo de la figura 14.2b. Es decir, si se diseñan pruebas para forzar la ejecución de esas rutas

esta.

TM

PDF Editor IF a OR b then procedimiento x else procedimiento y ENDIF

426

PARTE DOS

^CONSEJO^lo complejidad ciclomótica es una métrica que resulta útil poro predecir cuáles módulos tienen más probabilidad de contener errores. Se emplea paro lo ploneación de pruebas además del diseño de casos de prueba.


(un conjunto básico), se habrán ejecutado los lados verdadero y falso de cada i r - trucción del programa. Debe observarse que un conjunto básico n o e s único. En rea lidad, es posible derivar varios c o n j u n t o s básicos diferentes de u n diseño proce-mental determinado. ¿Cómo se s a b e c u á n t a s rutas buscar? El cálculo de la complejidad ciclomótica p : ~ porciona la respuesta. La complejidad ciclomática e s una métrica de software quej proporciona u n a medida cuantitativa de la complejidad lógica de un p r o g r a - ¡ Cuando se emplea e n el contexto del m é t o d o de prueba de la ruta básica, el vai i calculado mediante la complejidad ciclomática define el n ú m e r o de rutas inder : - dientes e n el conjunto básico de un programa, y proporciona u n límite superior r ; ra el n ú m e r o de p r u e b a s que deben aplicarse para a s e g u r a r que todas las i n s t r u c o : - ! n e s se hayan ejecutado por lo m e n o s u n a vez. La complejidad ciclomática se b a s a e n la teoría gráfica y se calcula de u n a de r a l maneras:

f

¿Cómo se * calcula la complejidad ciclomótica?

1. El n ú m e r o de regiones corresponde a la complejidad ciclomática. 2.

La complejidad ciclomática, V { G ) , de una gráfica de flujo, G, se define coir V(C) = E - N + 2 d o n d e E es el n ú m e r o de aristas, y N, el n ú m e r o de n o d o s de la gráfica de 3 u | )°-

3.

como

CIJA VE

V(G) = P + 1

Lo complejidad

d o n d e P es el n ú m e r o de n o d o s predicado incluidos en la gráfica de flujo C

ciclomótica proporciono el limite superior del

La complejidad ciclomática, V(G), de u n a gráfica de flujo, G, también se de "'-si

T o m a n d o c o m o referencia u n a vez m á s la gráfica de flujo de la figura \42t

i.

número necesario de casos de prueba para

complejidad ciclomática se calcula e m p l e a n d o cada u n o de los algoritmos qut a

garantizar que cada

a c a b a n de indicar.

instrucción del programo se haya

1. La gráfica de flujo tiene cuatro regiones.

ejecutado por lo menos

2.

V(G) = 11 aristas - 9 n o d o s + 2 = 4

3.

V(G) = 3 n o d o s predicado + 1 = 4

uno vez.

HOGARSEGURO

TM Utilización

de la complejidad

ciclomática

PDF Editor L a e s c e n a : Cubículo d e Shakira.

Los a c t o r e s : Vinod y Shakira, integrantes del equipo de ingeniería del software HogarSeguro

q u e trabaja en

la planeación d e pruebas p a r a la función d e seguridad.


S h a k i r a : Mira.. Sé que debemos aplicar pruebas de unidad a los componentes d e la función d e seguridad pero hay demasiados, y si tomas en cuenta el número operaciones que deben ejercitarse, no sé... tal vez det-e-

CAPÍTULO 14

olvidarnos de la prueba de cajo blanca, integrar to? iiciar la ejecución de las pruebas de caja negra. V i o d : ¿Crees que el tiempo es insuficiente para probar i ion ponentes, ejercitar las operaciones y luego inte-

?

II

427

TÉCNICAS DE PRUEBA D A SOFTWARE

I

i r a : La fecha límite para el primer incremento está cerca de lo que pensábamos.,, sí, claro, estoy preo: ¿Por qué no ejecutamos por lo menos pruebas is a blanca en las operaciones más propensas a « i r a ( e x a s p e r a d a ) : ¿Y exactamente cómo sé son las más propensas a error? V de G. i r a : ¿Qué?

V i n o d : La complejidad ciclomática (V d e G¡. Sólo calcu la V(G) para cada operación dentro de cada componente y verás cuáles tienen los valores más elevados. Esos son los que están más propensos a error. S h a k i r a : ¿Y cómo calculo V de G? V i n o d : Es muy fácil. Aquí tienes un libro que describe cómo hacerlo. S h a k i r a ( h o j e á n d o l o ) : Muy bien, no parece difícil. Lo probaré, las operaciones con la V(G) más elevada serán candidatos para las pruebas de caja blanca. V i n o d : Sólo recuerda que no hay garantías. Un componente con una V(G) baja aún puede estar propenso a

'

III

S h a k i r a : Muy bien. Pero por lo menos esto me ayudará a reducir el número de componentes que necesariamente deben someterse a prueba de caja blanca.

Lo más notable es que el valor de V(G) proporciona el límite superior del n ú m e r o de rutas independientes que forman el conjunto básico; por implicación, ofrece un límite superior del número de pruebas que debe diseñarse y ejecutarse para garantizar la cobertura de todas las instrucciones del programa.

14.4.3 Derivación de casos de prueba El método de prueba de la ruta básica se aplica a un diseño procedimental o al código fuente. En esta sección se presentará la prueba de la ruta básica c o m o una serie de pasos. Se empleará el procedimiento promedio (descrito en PDL en la figura 14.4) c o m o ejemplo para ilustrar cada paso en el método de diseño de casos de prueba. Obsérvese que promedio, aun en el caso de un algoritmo extremadamente simple, contiene condiciones compuestas y bucles. Los siguientes pasos se aplican para derivar el conjunto básico: 1. Utilizando el d i s e ñ o o el c ó d i g o c o m o b a s e s e dibuja la gráfica de fluj o c o r r e s p o n d i e n t e . En la creación de una gráfica de flujo se emplean los símbolos y las reglas de construcción presentadas en la sección 14.4.1. Tom a n d o como referencia el PDL para obtener promedio en la figura TM 14.4, se crea una gráfica de flujo numerando esas instrucciones en PDL, que s e correlacionarán o mapearán en los nodos correspondientes de la gráfica de flujo. En la figura 14.5 se muestra la gráfica de flujo resultante.

PDF Editor

2. D e t e r m í n e s e la complejidad c i c l o m á t i c a de la gráfica d e flujo resultante. La complejidad ciclomática, V(C), se determina al aplicar el algoritmo descrito en la sección 14.4.2. Debe indicarse que podría determinarse V(G) sin desarrollar una gráfica de flujo, si se cuentan todas las instrucciones condicio-

428

PARTE DOS


PROCEDIMIENTO p r o m e d i o :

PDL c o n nodos

*

Identificados.

f >roce * nier,to caled® el promedio d e 100 o menos número® que caen entre valores límite; también calcula la s u m a y el total de n ú m e r o s válidos

E8Íe

INTERFACE RETURN8 promedio, total.entrada, total-valido; INTERFACE ACCEPT8 valor, minkno. máximo: TYPE valor{1:100} 18 8CALAR ARRAY: TYPE prome
I = 1:

total.entrada = total, vafido = 0 : 2 suma = 0 ; """ 4

DO WHILE valor [i] < > - 9 9 9 AND total.entrada < 100 incrementar total.entrada en I;

!< 9

IF valorfí] > = mínimo AND valorflj < = máximo / THEN incrementar total.vafido e n 1: suma = s suma + valorflj

3 6

\ C1 OC

EL8E omitir ENDIF , incrementar i en 1: ENDD0

IF total.valido > 0 10 11 THEN promedio = suma / total.valido; u E18E promedio = - 9 9 9 : ® ENDIF END promedio

nales en el PDL (para el procedimiento promedio, las condiciones c o m p u e - s J cuentan como dos) y se suma 1 al resultado. Tomando c o m o referencia ia í- i gura 14.5, V(G) = 6 regiones V(G) = 17 aristas - 13 nodos + 2 = 6 V(G) = 5 nodos predicado + 1 = 6

"Errar es de humanos, encontrar un error es de dioses.'' Robert D «

3. D e t e r m í n e s e un conjunto b á s i c o de rutas l i n e a l m e n t e i n d e p e n d i e n - . El valor de V(G) indica el número de rutas linealmente independientes de ai 1 estructura de control del programa. En el caso del procedimiento promec a espera especificar seis caminos: TM ruta 1: 1-2-10-11-13 ruta 2: 1-2-10-12-13

PDF Editor ruta 3: 1-2-3-10-11-13

ruta 4: 1-2-3-4-5-8-9-2-...

ruta 5: 1-2-3-4-5-6-8-9-2-...

ruta 6: 1-2-3-4-5-6-7-8-9-2-...

CAPÍTULO 14

429


Los puntos suspensivos (...) que siguen a las rutas 4, 5 y 6 indican que es aceptable cualquier ruta que se recorra en el resto de la estructura de control. A m e n u d o vale la pena identificar nodos predicado como apoyo para derivar los casos de prueba. En este caso, los nodos 2,3, 5, 6 y 10 son nodos predicado. 4. P r e p á r e n s e l o s c a s o s de prueba q u e forzarán la e j e c u c i ó n d e c a d a ruta e n el conjunto b á s i c o . Es necesario seleccionar los datos de manera tal que se establezcan apropiadamente las condiciones de los nodos predicado, a medida que se prueba cada ruta. Cada caso de prueba se ejecuta y compara con los resultados esperados. Una vez completados todos los casos, la persona que aplica la prueba puede estar segura de que todas las instrucciones del programa se han ejecutado por lo m e n o s una vez. Es importante observar que es imposible probar algunas rutas independientes (como la ruta 1 en nuestro ejemplo) por separado. Es decir, en el flujo normal del programa n o puede obtenerse la combinación d e los datos requeridos para recorrer la ruta. En tales casos, estas rutas se ejercitan como parte de otra prueba del camino.

TM

PDF Editor Gráfica de flujo

Matriz de gráfica

PARTE DOS PRÁonCA DE

430

LA INGENIERÍA DEL SOFTWARE

14.4.4 Matrices de gráficas El procedimiento para derivar la gráfica de flujo e incluso determinar un conjunto cc. rutas básicas es sensible a la mecanización. Una estructura de datos d e n o m i n a n matriz de gráfica resulta m u y útil para desarrollar u n a herramienta de s o f t w a r e cv-1 ayude en la prueba de la ruta básica. Una matriz de gráfica es u n a matriz c u a d r a d a cuyo t a m a ñ o (es decir, el núrr e de filas y columnas) es igual al n ú m e r o de n o d o s en la gráfica de flujo. Cada fila r columna corresponde a un n o d o identificado, y las e n t r a d a s de la matriz corresp: * den a las conexiones (una arista) entre nodos. En la figura 14.6 se muestra un e j e - r pío simple de u n a gráfica de flujo y su matriz de gráfica correspondiente [BEI90; T o m a n d o c o m o referencia la figura, cada n o d o e n la gráfica está identificado n ú m e r o s , mientras que c a d a arista se identifica con letras. Una conexión entre n o d o s se indica c r e a n d o u n a e n t r a da de letra e n la matriz. Por ejemplo, el n o d o 3 ^ ¿Qué e s una * matriz de gráfica y cómo se extiende para usarla en la prueba?

conecta al n o d o 4 con la arista b. Hasta este punto, la matriz de gráfica n o es m á s que u n a representación de una gráfica de flujo. Sin embargo, al agregar u n peso de enlace a cada una de entradas, la matriz de gráfica se convierte en una herramienta poderosa para luar la estructura de control del p r o g r a m a durante la prueba. El p e s o de enlace porciona información adicional acerca del flujo de control. En su forma m á s el p e s o de enlace e s 1 (existe u n a conexión) o O (no existe u n a conexión). Perc p e s o s de enlace también se le asignan otras propiedades, m á s interesantes: • La probabilidad de que se ejecute un enlace (arista). • El tiempo de p r o c e s a m i e n t o g a s t a d o durante el recorrido a un enlace. • La memoria requerida durante el recorrido de u n enlace. • Los recursos requeridos d u r a n t e el recorrido de un enlace. Beizer [BEI90] proporciona un tratamiento completo de algoritmos m a t e r adicionales que son aplicables a u n a matriz de gráfica. El empleo de e s t a s té permite automatizar parcial o totalmente el análisis requerido para diseñar cas-:* i prueba. "Un error clósico es prestor más atención a la ejecución de los pruebas que a su diseño."

Brian I

TM 14.5

P R U E B A S DE LA E S T R U C T U R A DE C O N T R O L

PDF Editor i

La técnica de prueba de la ruta básica descrita en la sección 14.4 es u n a de técnicas para la prueba de estructuras de control. Aunque la prueba de la ruta ~ J ca es simple y efectiva, no es suficiente por sí misma. En esta sección se a r brevemente variaciones sobre la prueba de estructuras de control. Éstas e r la cobertura de las p r u e b a s y mejoran la calidad de la prueba de caja blanca

CAPÍTULO 14


431

14.5.1 Prueba de condición

:LAVE s son mucho ; en las s de las > lógicas que : mismo de mes de

La prueba de condición [TAI89] e s un método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en un módulo del programa. Una condición simple es una variable booleana o una expresión relacional, tal vez precedida con un operador NOT (->). Una expresión relacional toma la forma £, E¿ donde E, y E¿ son expresiones aritméticas y es uno de los siguientes: < , < , = , # (desigual), > o a . Una condición compuesta la integran dos o más condiciones simples, operadores booleanos y paréntesis. Se supone que entre los operadores booleanos permitidos en una condición compuesta s e incluyen OR (I), AND (&) y NOT (-•). Una condición sin expresiones relaciónales se considera una expresión booleana. Por tanto, los posibles tipos de elementos en una condición incluyen un operador booleano, una variable booleana, un par de paréntesis (que encierran una condición booleana simple o compuesta), un operador relacional o una expresión aritmética. Si una condición es incorrecta, entonces por lo m e n o s un componente de la condición es incorrecto. Por tanto, entre los tipos de errores en una condición se incluyen los presentes en el operador booleano (operadores booleanos incorrectos/faitantes/adicionales), en la variable booleana, en los paréntesis booleanos, en los operadores relaciónales y en la expresión aritmética. El método de prueba de condición se concentra en la prueba de cada condición del programa para asegurar que n o contiene errores.

14.5.2 Prueba del flujo d e datos El método de prueba del flujo de datos selecciona rutas d e prueba en un programa de acuerdo con las ubicaciones de las definiciones y los usos de las variables en el programa. El enfoque de prueba del flujo de datos se ilustra suponiendo que a cada instrucción de un programa se le asigna un número de instrucción, y que ninguna función modifica sus parámetros o variables globales. En el caso de una instrucción con I como número de instrucción, DEF(I) = {X I instrucción I contiene una definición de X¡ USO(l) = {XI instrucción I contiene un uso de X)

TM Si la instrucción / es una instrucción if (si) o loop (bucle), su conjunto DEF está vacío y su conjunto USO se basa en la condición de la instrucción /. Se dice que la defini-

PDF Editor

ción de la variable X en la instrucción / está viva en la instrucción /' si existe una ruta de la instrucción I a la /' que no contiene otra definición de X. Una cadena definición-uso (DU) de la variable X es de la forma [X, /, /'], donde I e /' son números de instrucción, X está en DEF(I) y USO(I'), y la definición d e X en la instrucción I está viva en la /'.

432

^CONSÍJO^ No es realista asegurar que la prueba del flujo de datos se usarú de manera extenso cuando se prueba un sistemo grande. Sin embargo, puede usarse de una manera orientada a un blonco en óreos de software que están bajo sospecha.

PARTE D O S


Una estrategia simple de prueba de flujo de d a t o s consiste en solicitar que c a a í c a d e n a DU sea cubierta por lo m e n o s u n a vez. Esta estrategia se d e n o m i n a estrBü • gia de prueba DU. Se ha m o s t r a d o que ésta no garantiza la cobertura de todas las •>>] m a s de un programa. Sin embargo, sólo en raras situaciones n o se garantiza que r a m a esté cubierta por u n a prueba DU, c o m o en las construcciones if-then-else s - j entonces-si_no) en que la parte then no tiene definición de alguna variable y la w l te else no existe. En esta situación, la r a m a else de la instrucción if n o está n e c e a - 1 riamente cubierta por la prueba DU. Se han estudiado y c o m p a r a d o varias e s t n c i gias de prueba de flujo de d a t o s (por ejemplo, [FRA88], [NTA88], [FRA93]). A los i J tores interesados se les recomienda que consideren consultar e s a s referencias • bliográflcas.

I

"Los personas que destacan en la aplicación de pruebas son maestras en percibir que 'a ) es gracioso' y actuar ello." Brian

14.5.3 Prueba de bucles Los bucles s o n la piedra de toque p a r a la gran mayoría de los algoritmos imi p k n J tados e n software. Y a u n así, a m e n u d o se les presta poca atención mientras s¿ lizan p r u e b a s de software. La prueba de bucles es u n a técnica de prueba de caja blanca que se c o n c e n t r a ® elusivamente en la validez de la construcción de bucles. Es posible definir c u a t n f l ferentes clases de bucles [BEI90J: bucles simples, c o n c a t e n a d o s , anidados y fracturados (figura 14.7).

Clases de bucles.

TM

PDF Editor Bucles no estructurados

iî

CAPITULO 14

433


Bucles simples.

El siguiente conjunto de p r u e b a s se aplica a bucles simples, don

de n es el n ú m e r o máximo de p a s o s que permite el bucle. 1. Omitir por completo el bucle. 2.

Sólo un p a s o por el bucle.

3.

Dos p a s o s por el bucle.

4 . m p a s o s por el bucle, d o n d e m
Si se f u e s e a extender el e n f o q u e de prueba de los bucles sim-

ples a los anidados, el n ú m e r o de p r u e b a s posibles crecería g e o m é t r i c a m e n t e a medida q u e a u m e n t e el nivel de anidamiento. Esto generaría un n ú m e r o p o c o práctico de pruebas. Beizer [BEI90] sugiere un e n f o q u e que ayudará a reducir el n ú m e r o de pruebas: 1. iniciar e n el bucle m á s interno. Asignar a todos los bucles los valores mínimos. 2.

Aplicar pruebas de bucle simple al m á s interno mientras se m a n t i e n e n los externos en los valores mínimos del p a r á m e t r o de iteración (como el contador de bucles). Agregar otras p r u e b a s para los valores fuera de rango o excluidos.

3 . Trabajar hacia fuera, c o n d u c i e n d o p r u e b a s para el siguiente bucle, p e r o m a n teniendo todos los d e m á s bucles externos en valores mínimos y otros bucles a n i d a d o s en valores "típicos". 4 . Seguir mientras n o s e hayan p r o b a d o todos los bucles. Bucles concatenados.

Los bucles c o n c a t e n a d o s se p r u e b a n e m p l e a n d o el enfo-

que definido para los bucles simples, si cada uno de los bucles es independiente. Sin (pONSEJO^. t oodrá probar r écocia los bucles i volver o

embargo, si dos bucles están c o n c a t e n a d o s y el contador del bucle I se emplea c o m o valor inicial para el bucle 2, e n t o n c e s los bucles n o son independientes. Cuando los bucles no lo son, entonces se recomienda el enfoque aplicado a los bucles anidados. Bucles n o estructurados.

Siempre q u e sea posible, esta clase de bucles d e b e di-

s e ñ a r s e n u e v a m e n t e para reflejar el uso de las construcciones de programación estructurada (capítulo 11). <

Las pruebas

1

de caja negra, también d e n o m i n a d a s , pruebas

!

TM de comportamiento,

se

c o n c e n t r a n en los requisitos funcionales del software. Es decir, permiten al ingenie-

PDF Editor

ro de s o f t w a r e derivar c o n j u n t o s de condiciones de entrada que ejercitarán por c o m -

pleto todos los requisitos funcionales de un programa. La prueba de caja negra no es u n a opción frente a las técnicas de caja blanca. Es, en cambio, un e n f o q u e c o m plementario que tiene probabilidades de descubrir una clase diferente errores de los que se descubrirían con los m é t o d o s de caja blanca.

434

PARTE DOS


Las pruebas de caja negra tratan de encontrar errores en las siguientes cates rías: 1) funciones incorrectas o faltantes, 2) errores de interfaz, 3) errores en estro: turas de datos o en acceso a bases de datos externas, 4) errores de comportamierto o desempeño, y 5) errores de inicialización y término. A diferencia de las pruebas de caja blanca, que se realizan al inicio del procese prueba, las de caja negra tienden a aplicarse durante las últimas etapas de la \ ba (consúltese el capitulo 13). Debido a que éstas desatienden a propósito la estro: tura de control, la atención se concentra en el dominio de la información. Las ¡ bas están diseñadas para responder las siguientes preguntas:

•

?

• ¿Cómo se prueba la validez funcional?

¿Cuáles preguntas

• ¿Cómo se prueban el comportamiento y el desempeño del sistema?

responden las

• ¿Cuáles clases de entrada serán buenos casos de prueba?

p r u e b a s d e caja negra?

• ¿El sistema es particularmente sensible a ciertos valores de entrada? • ¿Cómo se aislan los límites de una clase de datos? • ¿Cuáles tasas de datos y cuál volumen tolera el sistema? • ¿Qué efecto tienen combinaciones específicas de datos sobre la o p e r a d o r sistema? Al aplicar técnicas de caja negra se deriva un conjunto de casos de prueba que tisfacen los siguientes criterios [MYE79]: 1) casos de prueba que reducen, m una cuenta mayor que uno, el número de casos de prueba adicionales que debe- I señarse para alcanzar una prueba razonable, y 2) casos de prueba que indicar sd acerca de la presencia o ausencia de clases de errores, en lugar de un error do sólo con la prueba específica a la mano.

14.6.1 Métodos gráficos de prueba

CLAVE Una gráfica representa las relaciones entre los objetos de datos y los de programa, lo que permite derivar casos de prueba que busquen errores asociados con estos relociones.

El primer paso en la prueba de caja negra es comprender los objetos 5 modelac s el software y la relación entre ellos. Una vez que se ha logrado, el siguiente 3 consiste en definir la serie de pruebas que verifican que "todos los objetos t! relación esperada entre sí" [BEI95J. Explicado de otra manera, la prueba de re empieza al crear una gráfica de objetos importantes y s u s relaciones y luegc a una serie de pruebas que cubran la gráfica de tal manera que se ejercite cada :n to y relación y que se descubran los errores. TMuna gráfica Para dar estos pasos, el ingeniero de software empieza creando colección de nodos que representan objetos, enlaces que representan la reía tre objetos, pesos de nodo que describen las propiedades de un nodo (como ur a de datos o un comportamiento de estado específico) y pesos de enlace que di algunas características de un enlace.

PDF Editor 5

En este caso el término "objetos" se considera en el contexto m á s amplio posible. Abarca obie: - :

tos, componentes (módulos) tradicionales y elementos orientados a objetos del software de có

CAPÍTULO 14

435

TÉCNICAS DE PRUEBA DEL SOFTV/ARI

ación

yw

'(tiempo d e generación < 1.0 seg) Permite la edición d e Es representada como

'

Atributos: Contiene Dimensión inicial: valor o preferencias predeterminados Color de fondo: blanco Color d e texto: color o preferencias

En la figura 14.8a se muestra una representación simbólica de una gráfica. Los nodos se representan como círculos conectados por enlaces que toman un número diferente de formas. Un enlace directo (representado por una flecha) indica que una relación se mueve en una sola dirección. Un enlace bidireccional, también denominado enlace simétrico, indica que la relación se aplica en a m b a s direcciones. Los enlaces paralelos se emplean c u a n d o se establece un n ú m e r o diferente de relaciones entre los nodos de la gráfica. Como ejemplo simple, considérese una parte de la gráfica para una aplicación de procesamiento de palabras (figura 14.8b) donde Objeto ttl = nuevoArchivo (menú selección) Objeto #2 = v e n t a n a D o c u m e n t o Objeto #3 = t e x t o D o c u m e n t o Si se toma como referencia la figura, una selección del menú en nuevoArchivo genera una ventana de documento. El peso del nodo de v e n t a n a D o cTM u m e n t o proporciona una lista de los atributos de la ventana que se esperaban cuando ésta se generó. El peso del enlace indica que la ventana debe generarse en m e n o s de 1.0 segundos. Un enlace indirecto establece una relación simétrica entre la selección del menú nuevoArchivo y t e x t o D o c u m e n t o . y los enlaces paralelos indican las relaciones entre v e n t a n a D o c u m e n t o y t e x t o D o c u m e n t o . En realidad, tendría que generarse una gráfica mucho m á s detallada como precursora del diseño de casos de prueba. El ingeniero de software deriva entonces los casos de prueba al recorrer la

PDF Editor

436

PARTE DOS


gráfica y cubrir cada u n a de las relaciones mostradas. Estos c a s o s de prueba se á s e ñ a r á n en u n intento de e n c o n t r a r errores en cualquiera de las relaciones. Beizer [BEI95] describe varios m é t o d o s de prueba de c o m p o r t a m i e n t o que gráficas: M o d e l a d o del flujo d e t r a n s a c c i ó n . Los n o d o s representan p a s o s de alguna transacción (por ejemplo, los p a s o s requeridos p a r a hacer u n a reservación e n u n a línea e m p l e a n d o un servicio e n línea) y los enlaces representan la conexión lí entre los pasos. El diagrama de flujo de datos (capítulo 8) se utiliza p a r a ayudar la creación de gráficas de este tipo. M o d e l a d o d e e s t a d o finito. Los n o d o s representan los diferentes estados que usuario observa e n el s o f t w a r e (por ejemplo, c a d a u n a de las "pantallas" que ap cen c u a n d o un e m p l e a d o t o m a un pedido por teléfono) y los e n l a c e s representar transiciones que ocurren para ir de un estado a otro. El diagrama de e s t a d o ( lo 8) ayuda a crear gráficas de este tipo. M o d e l a d o d e l flujo d e d a t o s . Los n o d o s s o n objetos de datos, y los enlaces las transformaciones que ocurren para traducir un objeto de d a t o s en otro. Por < pío, el n o d o i m p u e s t o r e t e n i d o por FICA (IRF) se calcula a partir de salario t o (SN) e m p l e a n d o la relación IRF = 0 . 6 2 x SN. M o d e l a d o r e l a c i o n a d o c o n el t i e m p o . Los n o d o s son objetos de programa, y

1

e n l a c e s s o n las conexiones secuenciales entre e s o s objetos. Con los p e s o s de ce se especifican los tiempos de ejecución requeridos mientras el programa se cuta. Un análisis detallado de cada uno de estos m é t o d o s gráficos de prueba se en tra m á s allá del alcance de este libro. El lector interesado debe consultar IBEI95] ra tener u n a cobertura completa.

14.6.2 Partición equivalente La partición equivalente e s u n m é t o d o de prueba de caja negra que divide el nio de e n t r a d a de u n p r o g r a m a en clases de d a t o s a partir de las cuales pueder rivarse c a s o s de prueba. Un c a s o de prueba ideal de m a n e j o simple descubre clase de errores (por ejemplo, p r o c e s a m i e n t o incorrecto de todos los d a t o s de < ^ÔNSEJO^^ Las condiciones de entrado son conocidos en una etapa relativamente temprono del proceso de software. Por esto, debe empezase a pensar en la xrtiaón equivalente

teres) que, de otra manera, requeriría la ejecución de m u c h o s c a s o s a n t e s de que observe el error general. La partición equivalente se e s f u e r z a por definir un c a s : TM prueba que descubra ciertas clases de errores, reduciendo así el n ú m e r o total de s o s de prueba que deben desarrollarse. El diseño de c a s o s de prueba para partición equivalente se b a s a en u n a ev

PDF Editor «entrase

ción de las clases de equivalencia para u n a condición de entrada. Con el uso ce conceptos introducidos e n la sección anterior, si es posible enlazar un conjun:: objetos m e d i a n t e relaciones simétricas, transitivas y reflexivas, e n t o n c e s existe clase de equivalencia [BEI95]. Una clase de equivalencia representa un conjun:: e s t a d o s válidos y n o válidos p a r a las condiciones de entrada. Por lo general

CAPÍTULO 14


437

condición d e e n t r a da es un valor numérico específico, un r a n g o de valores, un conjunto de valores relacionados o u n a condición booleana. Las clases de equivalencia se definen de a c u e r d o con las siguientes directrices: 1. Si u n a condición de entrada especifica un rango, se definen una clase de equivalencia válida y dos no válidas. ¿Cómo se definen las

2.

Si u n a condición de entrada requiere un valor específico, se definen u n a clase de equivalencia válida y dos n o válidas.

; para probas?

3.

Si u n a condición de e n t r a da especifica u n m i e m b r o de un conjunto, se definen una clase de equivalencia válida y otra no válida.

4. Si una condición de e n t r a da e s booleana, s e definen u n a clase de equivalencia válida y otra no válida. Al aplicar .estas directrices para la derivación de clases de equivalencia, se d e s a rrollarán y ejecutarán los c a s o s de prueba para cada objeto de los d a t o s del dominio de entrada. Los c a s o s de prueba s e seleccionan de m o d o que el mayor n ú m e r o de atributos de clase de equivalencia se ejercita una vez.

14.6.3 Análisis de valores límite Es mayor el n ú m e r o de errores q u e s e presenta en los límites del dominio de entrada que en el "centro"; p o r ello se ha desarrollado el análisis de valores límite (AVL) com o técnica de prueba. El AVL lleva a u n a selección de c a s o s q u e prueba los valores límite. El análisis de valores límite es una técnica de diseño de c a s o s de prueba que c o m p l e m e n t a la partición equivalente. En lugar de seleccionar cualquier e l e m e n t o de u n a clase de equivalencia, el AVL lleva a la selección de c a s o s d e prueba en las "aristas" de la clase. En lugar de c o n c e n t r a s e exclusivamente en las condiciones de e n trada, el AVL también deriva c a s o s d e prueba del dominio de salida [MYE79]. Las directrices para el AVL son muy similares a las proporcionadas para la partición equivalente:

\

CLAVE ¿ft extiende I

~trarse en los de las "aristas" E una clase de

«ardentía.

1. Si una condición de e n t r a da especifica un r a n g o limitado por los valores a y b, los c a s o s de prueba deben diseñarse con e s o s valores, a d e m á s de los que se e n c u e n t r a n a p e n a s arriba y a b a j o de ellos. 2 . Si u n a condición de e n t r a da especifica diversos valores, deben desarrollarse c a s o s de prueba que ejerciten los n ú m e r o s m á x i m o y mínimo.TM También se p r u e b a n los valores ubicados a p e n a s arriba y a b a j o de estos m á x i m o s y mínimos.

PDF Editor

3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ejemplo, s u p ó n g a -

¿Cómo puedo crear de prueba

AVI?

se que u n a tabla que c o m p a r a presión y temperatura se requiere c o m o salida de un p r o g r a m a de análisis de ingeniería. Los c a s o s de prueba deben diseñarse para crear un informe de salida que produzca el n ú m e r o m á x i m o (y mínimo) permisible para las e n t r a d a s de la tabla.

438

PARTE D O S


4 . Si la estructura interna de datos del programa tiene límites prescritos (por ejemplo, u n a matriz que tiene un límite definido de cien entradas) debe disc ñarse un caso de prueba para ejercitar los límites de la estructura de datos La mayoría de los ingenieros de software realizan intuitivamente el AVL, hasta c e a to grado. Al aplicar estas directrices, la prueba de límites estará más completa tanto, tendrá una mayor probabilidad de detectar errores. "El cohete Arione 5 estalló al despegar debido a un simple defecto (error) del software que se relacionaba con la eos versión de un valor de punto flotante de 64 bits en un entero de 16 bits. El cohete y sus cuatro satélites carecían os seguro y costaron 500 millones de dólares. Una prueba completa del sistema hubiere encontrado el error, pero f w •*- I fado por razones de presupuesto."

i

Informe n o t i ó c

™

14.6.4 Prueba de tabla ortogonal Hay muchas aplicaciones en las cuales el dominio de entrada es relativamente r * tado. Es decir, el número de parámetros e s pequeño y los valores que cada p a ~ 3 3 * tro puede tomar están claramente limitados. Cuando estos números son muy p e o H ños (por ejemplo, tres parámetros de entrada toman tres valores discretos cada -~ncfl

K% CLAVE La prueba de toblo ortogonal permite diseñar casos de prueba que proporcionan la máxima cobertura de prueba con un número razonable de casos de prueba.

es posible considerar cada permutación de entrada y probar exhaustivamente e n f l cesamiento del dominio de entrada. Sin embargo, a medida que crece el n ú m e i B valores de entrada, junto con el número de valores discretos para cada elemeros I prueba exhaustiva se vuelve poco práctica o imposible. La prueba de tabla ortogonal se aplica en problemas en los cuales el d o m r i : entrada e s relativamente pequeño, pero demasiado grande para una prueba e r » tiva. El método de prueba de tabla ortogonal resulta útil sobre todo para e n c c r ^ M errores asociados con lasfallas de región (una categoría de error asociada cor fectos de la lógica en un componente de software). Ilustrar la diferencia entre la prueba de tabla ortogonal y los enfoques más cionales de "un elemento de entrada a la vez" requiere imaginar un sistema C O H ^ H elementos de entrada, X,YyZ. Cada uno de estos elementos tiene tres valcrts(^B cretos asociados. Hay 3 3 = 27 casos de prueba posibles. Phadke [PHA97] sug>e-^B concepto geométrico, que se ilustra en la figura 14.9, para los posibles c a s ^ ^ H prueba asociados con X, Y y Z. Si toma como referencia la figura, sólo un e!e-nd TM de entrada podría variar a un mismo tiempo en la secuencia que sigue cada a s entrada. Esto da como resultado un cobertura relativamente limitada del domin:: « trada (que representa el cubo de la izquierda de la figura). Cuando se presenta una prueba de tabla ortogonal se crea una tabla ortogxm de casos de prueba, la cual tiene u n a "propiedad de equilibrio" [PHA97]. Es Crr*| casos de prueba (representados con puntos azules en la figura) están "unifor"

PDF Editor

te dispersos por todo el dominio de la prueba", como se ilustra en el cubo de la de la figura 14.9. La cobertura de prueba en el dominio de entrada es más comnH

CAPÍTULO 14

439


de

O

97],

Un e l e m e n t o d e e n t r a d a a la v e z

Tabla o r t o g o n a l L9

Para ilustrar el uso de la tabla ortogonal L9, considérese la función enviar de una aplicación de fax. Se pasan cuatro parámetros, Pl, P2, P3 y P4 a la función enviar. Cada uno toma tres valores discretos. Por ejemplo, Pl toma los valores: Pl = 1, enviarlo ahora Pl = 2, enviarlo en una hora Pl = 3, enviarlo a medianoche P2, P3 y P4 también podrían tomar los valores 1, 2 y 3, representando otras funcione s de enviar. Si se eligiera una estrategia de prueba "un elemento de entrada a la vez", se especificarían las siguientes secuencias de prueba (Pl, P2, P3, P4): (1, 1, 1, 1), (2, 1, 1, 1), (3, I, 1, 1), (1,2, 1, 1), (1, 3, I, 1), (1, 1, 2, 1), (1, 1, 3, 1), (1, 1, 1, 2) y (1, 1, 1, 3). Phadke [PHA97] evalúa estos casos de prueba al afirmar: Estos casos de prueba sólo son útiles c u a n d o se está s e g u r o de q u e los p a r á m e t r o s de prueba n o interactúan. Detectarán fallas de lógica d o n d e un solo valor de p a r á m e t r o hace q u e el software funcione mal. Se trata de fallas de modalidad simple. Este m é t o d o n o detecta fallas de lógica que provoquen un mal f u n c i o n a m i e n t o c u a n d o dos o m á s p a r á m e t r o s toman ciertos valores simultáneamente; es decir, no detecta interacciones. Por tanto, su capacidad p a r a detectar fallas está limitada.

Dado el número relativamente pequeño de parámetros de entrada y valores discretos es posible aplicar una prueba exhaustiva. El número de pruebas requeridas es 34 = 81 (grande, pero manejable). Se encontrarían todas las fallas asociadas TM con permutación de elementos de datos, pero el esfuerzo requerido es relativamente alto. El enfoque de prueba de tabla ortogonal permite proporcionar buena cobertura de prueba con un número considerablemente menor de casos de prueba que la estrategia exhaustiva. En la figura 14.10 se muestra una tabla ortogonal L9 para la función enviar de fax.

PDF Editor

A continuación se presenta la evaluación de Phadke [PHA97] acerca de las pruebas aplicadas con la tabla ortogonal:

440

PARTE DOS


Caso de prueba

Tabla ortogonal L9.

Parámetros de prueba

D e t e c t a y a i s l a t o d a s l a s fallas d e m o d a l i d a d s i m p l e . Una falla de modalidad s r r h pie es un problema consistente con cualquier nivel de cualquier p a r á m e t r o simple. ~ ejemplo, si todos los c a s o s d e prueba del factor Pl = 1 causan u n a condición de error -r trata de u n a falla de modalidad simple. En este ejemplo, las p r u e b a s 1,2 y 3 (figura 14 mostrarán errores. Al analizar la información acerca d e cuáles p r u e b a s muestran err:*i i se identifican cuáles valores de p a r á m e t r o s causan la falla. En este ejemplo, al notar cjí las p r u e b a s 1,2 y 3 causan errores, se aisla [el p r o c e s a m i e n t o lógico asociado con "e lo ahora" (Pl = 1)] c o m o la f u e n t e del error. Este aislamiento d e la falla es importante: ra corregirla. D e t e c t a t o d a s las fallas d e m o d a l i d a d d o b l e . Si existe un problema con c u a n d o se p r e s e n t a n niveles específicos d e dos p a r á m e t r o s al mismo tiempo, se le i mina falla de modalidad doble. Por supuesto, se trata d e u n a indicación d e incomp dad d e un par d e valores o de interacciones d a ñ i n a s entre dos p a r á m e t r o s de prueba Fallas m u l t i m o d a l e s . Las tablas ortogonales (del tipo mostrado) sólo a s e g u r a n 1= tección de fallas d e modalidad simple y doble. Sin embargo, e s t a s p r u e b a s también ( tan m u c h a s fallas multimodales.

Un análisis detallado de las pruebas de tabla ortogonal se encontrará en

H E R R A M I E N T A S DETM SOFTWARE

Diseño de casos de prueba

PDF Editor 1 ^ 1

Objetivo: Ayudar al equipo de software a desarrollar un conjunto completo de casos de prueba de caja blanca y negra. M e c á n i c a : Estas herramientas caen en dos amplias categorías: pruebas estáticas y dinámicas. Se emplean tres ti-

pos diferentes de herramientas de prueba estática er i herramientas de prueba basadas en código, lenguc : prueba especializados y herramientas de prueba i en requisitos. Las herramientas de prueba basadas < digo aceptan código fuente como entrada y realizar i rios análisis que llevan a la generación de casos de

CAPÍTULO 14


. Los lenguajes de prueba especializados (como i permiten que un ingeniero de software escriba esiones detalladas que describen cada caso de y la logística para su ejecución. Las herramientas zrjeba basadas en requisitos aislan requisitos específioel usuario y sugieren casos de prueba (o clases de ) que ejercitarán los requisitos. Las herramientas licas de prueba interactúan con un programa de eje; revisando la cobertura del camino, probando las iones relacionadas con el valor de variables especíe instrumentando de otra manera el flujo de ejecución irograma, mientas representativas6 Test, desarrollada por McCabe & Associates -Avw.mccabe.com), implemento diversas técnicas de enjeba de la ruta derivadas de una evaluación de la complejidad ciclomática y de otras métricas de software.

í®J

*5

441

Panorama, desarrollada por International Software Automation, Inc. (www.softwareautomation.com), abarca un juego completo de herramientas para desarrollar software orientado a objetos, incluidas herramientas que

\

ayudan a diseñar casos d e prueba y planear pruebas.

TestWorks, desarrollada por Software Research Inc. (www. soft.com/Products), es un juego completo de herramientas automatizadas de prueba que ayudan al diseño de casos de prueba para software desarrollado en C/C++ y Java y proporcionan soporte a pruebas de regresión. T-Vec Test Generation System, desarrollado por T-VEC Technologies (www.t-vec.com), es un conjunto de herramientas que da soporte a pruebas de unidad, integración y validación al ayudar en el diseño de casos de prueba empleando información contenida en una especificación de requisitos orientada a objetos. J

vilfA ¡FÍ THbSTO$ I íf í fe

La arquitectura del software orientado a objetos genera una serie de subsistemas separados en capas que encapsulan las clases que colaboran entre sí. Cada uno de estos elementos del sistema (subsistemas y clases) realiza funciones que ayudan a cumplir con los requisitos del sistema. Es necesario probar un sistema orientado a objetos en diferentes niveles para descubrir errores que podrían ocurrir a medida que las clases colaboran entre sí y los subsistemas s e comunican entre las capas de la arquitectura. En el aspecto estratégico, la prueba orientada a objetos es similar a la de los sist e m a s convencionales, pero e s diferente en el aspecto táctico. Debido a que los modelos de análisis y diseño orientados a objetos tienen una estructura y un contenido similares al programa orientado a objetos resultante, la "prueba" podría empezar con la revisión de estos modelos. Una vez que se ha generado el código, la prueba orientada a objetos real empieza por lo "pequeño", con una serie de pruebas diseñadas para ejercitar las operaciones de clase y examinar si existen errores a medida q u e una clase colabora con otra. Cuando las clases se integran para formar un subsistema, se aplica la prueba basada en el uso, junto con los enfoques basados en fallas, TM se emplean para ejercitar plenamente las clases que colaboran entre sí. Por último, los c a s o s de uso para descubrir errores al nivel de validación del software. El diseño convencional de casos de prueba lo determina el concepto entrada-pro-

PDF Editor

ceso-salida del software o el detalle algorítmico de módulos individuales. La prueba

6

Las herramientas expuestas aquí sólo representan una muestra de esta categoría. En casi todos los casos los nombres de las mismas son marcas registradas de sus respectivos desarrolladores.

442

PARTE D O S


orientada a objetos se concentra en el diseño de secuencias apropiadas de o p e r a c m para ejercitar los estados de una clase.

Uno excelente coleccursos sobfe praebos oiientodos o objetos se encontrará en www.rbsi.cam.

14.7.1 Implicaciones del concepto orientado a objetos en el diseño de casos de prueba A medida que la clase evoluciona mediante los modelos de análisis y diseño se VJ±~ ve un destino para el diseño de casos de prueba. Debido a que los atributos y las :curaciones están encapsulados, las operaciones de prueba fuera de la clase sueler s e improductivas. Aunque el encapsulamiento es un concepto de diseño e s e n c : ¿ orientación a objetos, representa un obstáculo menor cuando se prueba, como .: dica Binder [BIN94]: "La prueba debe informar sobre el estado concreto y a b s t r ^ a » de un objeto". Sin embargo, el encapsulamiento llega a dificultar la adquisicicr. m ¡ esta información. A m e n o s que se proporcionen operaciones integradas para tar los valores de los atributos de clase, será difícil obtener una instantánea Ge s i tado de un objeto. La herencia también plantea desafios adicionales para el diseñador de c a s : s prueba. Ya se ha observado que cada nuevo contexto de uso requiere una nueva m | H ba, aunque se haya alcanzado la reutilización. Además, la herencia múltiple' : . K M plica la prueba más allá de aumentar el número de contextos que requierer prueba [B1N94]. Si las subclases que se convierten en instancias a partir de perclase se usan dentro del mismo dominio del problema, es posible usar el c c | ^ | to de casos de prueba derivado de la superclase cuando se prueba la subclase 9 r embargo, si ésta se emplea en un contexto completamente nuevo, los casos de r r o f l ba de la superclase no serán aplicables y será necesario diseñar un nuevo c o - ' - H l de pruebas.

14.7.2 Aplicabilidad d e métodos convencionales de diseño de de prueba

J

Los métodos de prueba de caja blanca descritos en secciones anteriores puedecarse a las operaciones definidas para una clase. Las técnicas de flujo de dat os a l prueba de la ruta básica o de bucle ayudan a asegurar que se han probado t c c a a H instrucciones de una operación. Sin embargo, la estructura concisa de muchas raciones de clase hace que algunos argumenten que el esfuerzo aplicado a ¿ 1 ba de caja blanca podría redirigirse mejor para probar un nivel de clase. Los métodos de prueba de caja negra son tan apropiados para TM los sistema? tados a objetos como los sistemas que se desarrollan con métodos conver de ingeniería de software. Como ya se indicó en este mismo capítulo, los > uso proporcionan información útil para el diseño de pruebas de caja negra y a

PDF Editor das en el estado [AMB95].

7 Uri concepto de orientación a objetos que debe usarse con extremo cuidado.

CAPÍTULO 14

443


14.7.3 Prueba b a s a d a en fallas 8

KVE i para lo loen 3 en crear s sobre un i de follas s y luego ¡deor s oora probar

i ¿Qué tipos 4c fallos se ron e n las ; a operai y en las coe s entre

El objetivo d e la prueba basada en fallas dentro del sistema orientado a objetos e s diseñar pruebas que tengan una alta probabilidad de descubrir posibles fallas. Debido a que el producto o sistema debe cumplir con los requisitos del cliente, la planeación preliminar requerida para realizar la prueba basada en fallas empieza con el modelo del análisis. La persona que aplica la prueba busca fallas posibles (es decir, aspectos de la implementación del sistema que generen defectos). Determinar si existen estas fallas requiere diseñar casos de prueba que revisen el diseño o el código. Por supuesto, la efectividad de estas técnicas depende de la manera en que las personas que aplican las pruebas adviertan una falla posible. Si las fallas reales en un sistema orientado a objetos se consideran poco posibles, entonces este método en realidad no es mejor que cualquier técnica de prueba al azar. Sin embargo, si los modelos de análisis y diseño arrojan luz sobre lo que tal vez esté mal, entonces la prueba basada en fallas encontrará una cantidad importante de errores con gastos relativamente mínimos de esfuerzo. La prueba de integración (cuando se aplica en un contexto orientado a objetos) busca fallas en llamadas a operación o en conexiones entre mensajes. Tres tipos de fallas se encuentran en este contexto: resultado inesperado, operación incorrecta/ mensaje empleado, invocación incorrecta. Para determinar las fallas a medida que se invocan las funciones (operaciones), debe examinarse el comportamiento de la operación. La prueba de integración se aplica a los atributos y a las operaciones. Los "comportamientos" de un objeto los definen los valores que se asignan a sus atributos. La prueba debe ejercitar los atributos para determinar si ocurren valores apropiados para distintos tipos de comportamiento de objeto. Es importante observar que las prueba de integración tratan de encontrar errores en el objeto cliente, n o en el servidor. Explicado en términos convencionales, el eje de la prueba de integración es determinar si existen errores en el código que llama, no en el código llamado. La llamada a la operación se usa c o m o una pista, una manera de encontrar los requisitos de prueba que ejercitan el código que llama.

"Si se quiere y espero que un programo funcione, lo más probable es que se vea un programa funcionando (y que se pasen por alto las follas)."

Cem Kaner et oL

TM

PDF Editor

De la sección 14.7.3 a la 14.7.6 se ha adaptado de un articulo de Brian Marick publicado en el grupo de noticias de Internet componente.testing Esta adaptación se incluye con el permiso del autor. Para conocer mayor información sobre estos temas consúltese (MAR94|. Debe observarse que las técnicas analizadas de las secciones 14.7.3 a 14 7 6 son aplicables al software convencional.

444

PARTE D O S


14.7.4 Casos de prueba y jerarquía de clase

% CLAVE Aunque se hoyo probodo por completo uno dose de bose, oún se tendró que probar todos los clases derivados de ello.

La herencia n o obvia la necesidad de una prueba completa de todas las clases vadas. En realidad, llega a complicar el proceso de prueba. Imagínese la Siguiente tuación. Una clase Base contiene las operaciones heredado() y redeJinido(). Una s e D e r i v a d o define redefinidof) para que sirva en un contexto local. Hay pocas das de que debe probarse Derívado::redefin¡do() porque representa un nuevo d : un nuevo código. Pero ¿debe probarse de nuevo Derivado: :heredado()? Si Derivado: :heredado( ) llama a redefinido( ) y el comportamiento redefinida , cambiado, es posible que Derivado::heredado( ) maneje erróneamente el nuevo portamiento. Por tanto, se necesitan nuevas pruebas a u n q u e n o hayan cambi diseño ni el código. Sin embargo, es importante observar que sólo es posible : zar un subconjunto de todas las pruebas de Derivado: :heredado(). Si parte del i el código de heredado() n o depende de redefinido() (es decir, no lo llama a e. ningún código que lo llame indirectamente), es innecesario probar de nuevo ese digo en la clase derivada. Base.-.-redefinidoU y Derívado::redefinido son operaciones distintas con diferentes cificaciones e implementaciones. Cada una tendría un conjunto de requisitos prueba derivados de la especificación y la implementación. Esos requisitos de ; ba revisan fallas posibles: fallas de integración, de condición, de límites, etc. Sir bargo, es probable que las operaciones sean similares; s u s conjuntos de req de prueba se superpondrán. Mientras mejor sea el diseño orientado a objetos, yor será la superposición. Es necesario derivar nuevas pruebas exclusivamente los requisitos de DeHvado::redefinido( ) que no se satisfagan con las pruebas de ::redefinido( ).

En resumen, las pruebas de Base::redefin¡do() se aplican a objetos de la clase i vado. Las entradas de prueba son apropiadas para las clases de base y derivada; ro los resultados esperados podrían diferir en la clase derivada.

14.7.5 Prueba b a s a d a en escenarios La prueba basada en fallas soslaya dos tipos importantes de errores: 1) es ciones incorrectas y 2) interacciones entre subsistemas. Cuando ocurren errores i ciados con especificaciones incorrectas, el producto n o hace lo que el cliente re. Podría hacer lo incorrecto, u omitir funcionalidad importante. En cualquier

CIJA VE

se merma la calidad (el cumplimiento de los requisitos). Los errores asociadc; TM las interacciones entre subsistemas ocurren cuando el comportamiento de ur sistema crea circunstancias (como eventos o flujo de datos) que causan la ft otro subsistema. La prueba basada en escenarios se concentra en lo que hace el usuario, no e. ducto. Esto significa que se deben capturar las tareas (mediante casos de uso)

PDF Editor La prueba basado en

escenarios descubrirá

errores que ocurren ) cualquier octor i con el

usuario tiene que realizar y luego aplicarlas, junto con sus variantes, como p Los escenarios descubren los errores de interacción. Pero esto se logra si sos de prueba son más complejos y realistas que las pruebas b a s a d a s en falla;

CAPÍTULO 14


445

pruebas b a s a d a s en escenarios tienden a ejercitar varios s u b s i s t e m a s en u n a sola prueba (los usuarios no se limitan al uso de u n subsistema a la vez). C o m o ejemplo, considérese el diseño de p r u e b a s b a s a d a s en escenarios para un editor de texto mediante la revisión de los siguientes c a s o s de uso informales: Caso de uso: Corregir el borrador final. Antecedentes: Es común que se imprima el borrador "final", se lea y se descubran algunos errores molestos y confusos en la imagen en pantalla. Este caso de uso describe la secuencia de eventos que se presenta cuando ocurre esto. 1. Se imprime todo el documento. 2. Se recorre el documento, cambiando ciertas páginas. 3. A medida que se hacen cambios, se imprime página por página. 4. A veces se imprime una serie de páginas.

Este escenario describe dos cosas: u n a prueba y necesidades específicas del usuario. Las necesidades del usuario son obvias: I) un m é t o d o para imprimir páginas individuales, y 2) un m é t o d o para imprimir un r a n g o de páginas. A medida que se aplica la prueba, d e b e probarse la edición d e s p u é s de imprimir (y a la inversa). La persona que aplica la prueba espera descubrir que la función de impresión c a u s a errores en la función de edición; es decir, que las dos funciones del software n o tienen la independencia apropiada. ^CONSEJO^^ ¡la prueba i en escenarios : méritos, se ? mejores s por tiempo a si se revisan 5 de uso cuando i xsarrollan como ¡del modelo de

Caso de uso: Imprimir una nueva copia. Antecedentes: Alguien pide al usuario una nueva copia del documento. Debe imprimirse. 1. Se abre el documento. 2. Se imprime. 3. Se cierra el documento.

Una vez más, el e n f o q u e de la prueba e s relativamente obvio, con la excepción de que e s t e d o c u m e n t o no a p a r e c e de la nada. Se creó en una tarea inicial. ¿Aquella tarea afecta a ésta? En m u c h o s editores m o d e r n o s , los d o c u m e n t o s recuerdan c ó m o se imprimieron por última vez. Como opción predeterminada, se imprimen de la misma m a n e r a la siguiente ocasión. Después del escenario Corregir el borrador final, con sólo seleccioTM n a r "Imprimir" e n el m e n ú y hacer clic en el botón Imprimir del c u a d r o de diálogo se imprimirá de nuevo la última versión corregida. De m o d o que, de a c u e r d o con el edi-

PDF Editor tor, el escenario correcto d e b e tener este aspecto: Caso de uso: Imprimir una nueva copia 1. Se abre el documento.

2. Se selecciona "Imprimir" en el menú.

446

PARTE DOS

P R Á C T C A DE LA INGENIERÍA DEL SOFTWARE

3. Se revisa si está imprimiendo un ra ng o de páginas; si es así, se hace clic para mir todo el documento. 4. Se h a c e clic en el botón Imprimir. 5. Se cierra el documento.

Pero este escenario indica un posible error de especificación. El editor no hace 1 el usuario espera razonablemente que haga. Los clientes con frecuencia o m r revisión indicada en el paso 3. Se sentirán molestos cando vayan a la i m p r encuentren una página cuando querían 100. Los clientes molestos señalarán de especificación. Un diseñador de casos de prueba podría pasar por alto esta dependencia al ñar la prueba, pero es probable que el problema surja durante la prueba. El r sable de ésta tendría entonces que enfrentarse a la probable respuesta: "¡asi pone que debía funcionar!"

14.7.6 Estructuras de superficie y de fondo en pruebas Estructura de superficie e s la estructura observable externamente de un p orientado a objetos. Es decir, la estructura que resulta inmediatamente obvia usuario final. En lugar de realizar funciones, se le dan objetos determinados al rio de muchos sistemas orientados a objetos para que los manipule. Pero ra que sea la interfaz, las pruebas aún se basan en tareas de usuario. La c estas tareas requiere comprensión, observación y comunicación con usuarios sentativos (y con todos los usuarios que n o lo son que valga la pena tomar en Seguramente habrá algunas diferencias en los detalles. Por ejemplo, en lim a convencional con una interfaz orientada a comandos, el usuario podría

CLAVE Lo prueba de estructura de superficie es análogo a lo pruebo de cojo negra. Lo de estructuro de fondo es similor a la de cojo blanco.

dos los comandos como lista de verificación de una prueba. Si n o existen e r de prueba para ejercitar un comando, es probable que la prueba soslaye al reas del usuario (o que la interfaz tenga comandos inútiles). En una interfar tada a objetos el responsable de la prueba podría emplear todos los objetos una lista de verificación de una prueba. Las mejores pruebas se derivan cuando el diseñador observa el sistema manera nueva o poco convencional. Por ejemplo, si el sistema o el product una interfaz basada en comandos, las pruebas m á s completas se derivarán señador del caso de prueba pretende que las operaciones sean independiente; objetos. Deben plantearse preguntas como: "¿El usuario deseará usar esta TM (que sólo se aplica al objeto escáner) mientras trabaja con la impresora? portar cuál sea el estilo de la interfaz, el diseño de casos de prueba que ej estructura de superficie debe usar objetos y operaciones como pistas que c

PDF Editor

a tareas omitidas. La estructura a fondo representa los detalles técnicos internos de un orientado a objetos. Es decir, la estructura que se comprende al examinar ei el código, o ambos. La prueba de estructura de fondo está diseñada para e j e ' pendencias, comportamientos y mecanismos de comunicación que se han

CAPÍTULO 14

447


cido c o m o parte del m o d e l o de diseño (capítulos 9-12) para el s o f t w a r e orientado a objetos. Los modelos de análisis y diseño son la b a s e de la prueba d e estructura de fondo. Por ejemplo, el d i a g r a m a de colaboración UML o el m o d e l o de despliegue describe las colaboraciones e n t r e objetos y s u b s i s t e m a s que tal vez no s e a n visibles externamente. El d i s e ñ a d o r de c a s o s de prueba pregunta entonces: ¿ h e m o s capturado (com o prueba) a l g u n a s t a r e a s que ejercitan la colaboración indicada e n el d i a g r a m a de colaboración? Si n o e s así, ¿por qué? "No se overgilience de los errores ni los convierto en crímenes." Confucio

14.8

M É T O D O S DE P R U E B A A P L I C A B L E S AL N I V E L DE C L A S E En el capítulo 13 se indicó q u e la prueba del s o f t w a r e e m p i e z a por lo "pequeño" y lentamente a v a n z a hacia lo "grande". Se prueba e n el p e q u e ñ o e n t o r n o de una sola clase y los m é t o d o s q u e están e n c a p s u l a d o s e n la clase. La prueba aleatoria y la partición s o n m é t o d o s que se e m p l e a n para ejercitar u n a clase durante una prueba orientada a objetos [KIR94].

CONSEJO^ de posibles en uno zieatorío llega se muy

ln eficiencia meba mejoraría trizara una similor o la de tabla

14.8.1 Prueba aleatoria para clases orientadas a objetos Para ilustrar b r e v e m e n t e e s t o s métodos, imagínese u n a aplicación bancaria en que una clase C u e n t a tiene las siguientes operaciones: abrirf >, configurar(), depositar(), retiran ), saldar(), sumarf),

IimiteCredito() y cerrafí)

[KIR94]. Cada una de estas opera-

ciones se aplica a C u e n t a , pero hay ciertas restricciones (por ejemplo, la cuenta d e b e abrirse a n t e s de aplicar otras operaciones, y d e b e cerrarse después de que se h a n completado todas las operaciones) relacionadas con la naturaleza del problema. Aun con estas restricciones, hay m u c h a s permutas en las operaciones. El historial de comportamiento mínimo de u n a instancia de C u e n t a incluye las siguientes operaciones: abrir • configurar • depositar • retirar • cerrar

Esto representa la secuencia de prueba mínima para C u e n t a . Sin embargo, podría p r e s e n t a r s e una amplia variedad de c o m p o r t a m i e n t o s distintos d e n t r o de esta secuencia. abrir • configurar • depositar • (depositar | retirar | saldar | sumar | limiteCredito]"-retirar "cerrar

TM

Es posible generar al azar varias secuencias diferentes de operaciones. Por ejemplo:

PDF Editor Caso de prueba

r¡: abrir «configurar'depositar* depositar» saldar «sumar «retirar'cerrar

Caso de prueba r 2 : abrir«configurar«depos¡tar«ret¡rar«depositar«saldar*limiteCredito« retirar «cerrar

Éstas y otras p r u e b a s de orden aleatorio se aplican para ejercitar diferentes historiales de instancias de clase.

448

PARTE D O S


HOGARSEGURO Prueba

de clase

l a e s c e n a : Cubículo de Shakira. Los a c t o r e s : Jamie y Shakira, integrantes de! equipo de ingeniería del software HogarSeguro que están trabajando en el diseño d e casos de prueba para lo función de seguridad. La c o n v e r s a c i ó n :

S h a k i r a : Lo sé, lo sé. He aquí otras secuencias que he elaborado. ¿ti (Muestra a Jamie las siguientes secuencias.) # 2 : activar «probar* [leer]" «desactivar # 3 : Peer]" # 4 : activar «desactivar* [probar | leer]

S h a k i r a : He desarrollado algunas pruebas para la clase Detector [figura 11.4], ya sabes, la que permite acceso a todos los objetos d e S e n s o r para la función de seguridad. ¿Estás familiarizada con ella? J a m i e ( s o n r i e n d o ) : Claro, es la que te permite agregar el sensor antiperros". Shakira: Esa misma. De cualquier manera, tiene una interfaz con cuatro operaciones: leerQ, activar!), desactivarI) y probarfj. Antes d e que un sensor tenga la posibilidad de leer, debe activarse. Una vez cctivado, puede leerse y probarse. Es posible desactivarte en cualquier momento, a menos que se haya procesado una condición de alarma. De modo que definí una secuencia simple de prueba que ejercitará su historial de comportamiento. (Muestra a Jamie la siguiente secuencia.) #1: activar'probar-leer-desactivar J a m i e : Eso funcionará, ¡pero tienes que probar más que eso! '"..¡r''

J a m i e : Déjame ver si comprendo tu intención. #1 recorre el historial completo, lo que representa una es pe: e d e uso convencional. #2 repite la operación leer n y ese es un escenario probable. # 3 trata de leer e : antes de que se active... eso debe producir algún • cc mensaje de error, ¿verdad? # 4 activa y desactiva e .-i sor y luego trata de leerte. ¿No es lo mismo que le ba 3? S h a k i r a : En realidad no. En # 4 el sensor se ha do. Lo que realmente pruebo # 4 es si la operador- -: var funciona como debería. Si se presentan ieer¡] o probar() después de desactivar!), debe generarse mensaje de error. Si no lo hace, entonces tenemos . error en la operación desactivar. J a m i e : Estupendo. Sólo recuerda que las cuatro bas tienen que aplicarse a cada tipo de sensor, coda operación puede tener diferencias sutiles, diendo del tipo de sensor. S h a k i r a : No te preocupes. Ése es el plan.

14.8.2 Prueba de partición al nivel de clase La prueba de partición reduce el número de casos de prueba requeridos para si tar la clase de manera muy parecida a la partición equivalente (sección 14.6 j el software convencional. La entrada y la salida se ordenan en categorías y í-e ; ñan casos de prueba para ejercitar cada categoría. ¿Cómo se derivan las c a t r ? de partición? ^ ¿Cuáles '•w opciones de prueba e s t á n disponibles al nivel de c l a s e ?

La partición basada en el estado ordena en categorías las operaciones de TM partir de su capacidad para cambiar el estado de la clase. Si se piensa una vez en la clase Cuenta, las operaciones de estado incluyen depositar() y retiran

PDF Editor tras que las que no son de estado incluyen saldar(), sumar()

1

ni

y limiteCrediu• i

pruebas están diseñadas de m a n e r a q u e ejercitan por separado las o p e r a d o - a cambian de estado y las que no lo hacen. Por tanto, Caso de prueba

p,: abrir «configurar «depositar «depositar «retirar «retirar «cerrar

Caso de prueba P¿ abrir«configurar«depositar«sumar«limiteCredíto«retirar«cerrar

CAPÍTULO 14


449

El caso de prueba p , cambia de estado, mientras que el caso de prueba p2 e j e r c i t a operaciones que n o cambian de estado (aparte de las que se encuentran en la secuencia de prueba mínima). La partición basada en atributos ordena en categorías las operaciones de clase basadas en los atributos que utilizan. En el caso de la clase Cuenta, los atributos saldar y limífeCredifo se emplean para definir particiones. Las operaciones s e dividen en tres particiones: 1) operaciones que usan limiteCredifo, 2) operaciones que modifican limifeCredito, y 3) operaciones que n o usan ni modifican limiteCredito. Entonces se diseñan secuencias de prueba para cada partición. La partición basada en categorías ordena en categorías las operaciones de clase con base en la función genérica que cada una realiza. Por ejemplo, las operaciones de la clase Cuenta se organizan en operaciones de inicialización [abrirf), configurar()], operaciones computacionales \depositar(), retirarf)], consultas Isaldar)), sumar(), UmiteCreditof )\ y de terminación (cerrar(j\

El diseño de casos de prueba se vuelve más complicado cuando empieza la integración del sistema orientado a objetos. En esta etapa debe empezar la prueba de colaboración entre clases. Para ilustrar la "generación de casos de prueba de interclase" [KIR94], se expande el ejemplo del sistema bancario presentado en la sección 14.8 para que incluya las clases y colaboraciones indicadas en la figura 14.11. La dirección de las flechas en la figura indica la dirección de los mensajes. Y las etiquetas individuales indican las operaciones que se invocan como consecuencia de la colaboración indicada por los mensajes. Como en la prueba d e clases individuales, la prueba de colaboración entre clases se lleva a cabo al aplicar métodos aleatorios y de partición, a d e m á s de pruebas bas a d a s en el escenario y de comportamiento.

14.9.1

Prueba d e clases múltiples

Kirani y Tsai [KIR94] sugieren la siguiente secuencia de pasos para generar varios casos de prueba aleatorios de clases múltiples: 1. En cada clase cliente use la lista de operaciones de clase para generar una serie de secuencias de pruebas aleatorias. Las operaciones enviarán mensajes a otras clases del servidor. TM 2 . En cada mensaje generado, determínese la clase colaboradora y la operación correspondiente en el objeto servidor.

PDF Editor

3 . En cada operación del objeto servidor (invocada por los mensajes enviados desde el objeto cliente) determínense los mensajes que transmite. 4. En cada uno de los mensajes, determínese el siguiente nivel de operaciones invocadas e incorpórelos en la secuencia de prueba.

450

Diagrama de colaboración de clases para una aplicación bancaria (adaptado de [KIR94]).

PARTE DOS


Interfaz de usuario de cajero automático

tarjetolnsertada contraseña depositar retirar estatusCuenta terminar

verificarEstatus estatusDeposito despocharEfectivo imprimirEstadoCuenta leerlnfoTarjeta obtenerMontoEfectivo

verificarCuenta verilicarNIP verificarPolitica solicitarRetiro solicitarDeposito infoCuenta labrirCuenta depositolniciaí autorizarTarjeta desautorizar cerrarCuenta

Cajero

limiteCredito tipoCuenta saldar retirar depositar cerrar

Cuenta

ln(o Validación

Como ejemplo [KIR94], considérese una secuencia d e operaciones para la B a n c o relacionada con una clase CajeroAutomatico (figura 14.11): verificarCuenta • verificarNIP» [[verificarPolitica • solict udRet iro] | solicitarDeposito | Cuenta]"

Un caso de prueba aleatoria para la clase B a n c o sería: Caso de prueba r3 = verificarCuenta-verificarNIP* solicitarDeposito Considerar a los colaboradores que participan en la prueba requiere tomar er ta los mensajes asociados con cada una de las operaciones indicadas en el prueba r¡. B a n c o debe colaborar con infoValidacion para ejecutar viriji veríf¡carNIP(). B a n c o debe colaborar con Cuenta para ejecutar solicitarDepos: • tanto, se tiene un nuevo caso de prueba que ejercita estas colaboraciones: Caso de prueba r4 = verificarCuentaBanco[val¡darCuentalnfoValidac¡on] verificarNIPBanco* [validarNIPInfovalidacion] • solicitarDeposito • [depositarcuentaj

El enfoque para la prueba de partición de clases múltiples es similar al empleado para la de clases individuales. Como se analizó en la sección 14.8^ TM mete a partición una sola clase. Sin embargo, se expande la secuencia de para incluir las operaciones invocadas mediante mensajes a las clases que ~ ran. Un enfoque alterno lleva a cabo la partición de las pruebas con base i terfaces de una clase determinada. Si se toma como referencia la figura 14.1: se B a n c o recibe mensajes de las clases CajeroAutomatico y Cajero Por! métodos dentro de B a n c o se prueban al particionarlas entre las que sirven ; roAutomatico y a Cajero. La partición basada en el estado (sección 14.8.2 para refinar aún más las particiones.

PDF Editor

CAPÍTULO 14

451


14.9.2 Pruebas derivadas de modelos de comportamiento En el capítulo 8 s e analizó el uso del diagrama de estado como modelo para representar el comportamiento dinámico de una clase. El diagrama de estado de una clase ayuda a derivar una secuencia de pruebas que revisa el comportamiento dinámico de la clase (y las clases que colaboran con ella). En la figura 14.12 [K1R94] se muestra un diagrama de estado para la clase Cuenta que ya se analizó. Si se observa, las transiciones iniciales recorren los estados vaciar Cuenta y configurar Cuenta. Un retiro final y un cierre de la cuenta causan que la clase Cuenta haga transicione s a los estados cuentalnactiva y cuentaMuerta, respectivamente. Las pruebas que se diseñen deben cubrir todos los estados [KIR94]. Es decir, las secuencias de operación deben lograr que la clase Cuenta haga una transición a todos los estados permisibles: Caso de prueba

S,:

abrir• configurCuenta• depositar(inicial) 'retirar(final) •cerrar

Debe notarse que esta secuencia es idéntica a la secuencia de la prueba mínima tratada en la sección 14.9.1. La secuencia de la prueba adicional se agrega a la sucesión mínima, Caso de prueba

S,:

abrir• configurarCuenta • depositar(in¡cial) ' d e p o s i t a r • saldar • acreditar • retirar(final) • cerrar

Caso de prueba

Sy.

abrir • configurarCuenta • depositar (inicial) • depositar • retirar • infoCuenta • retirar(final) • cerrar

Es posible derivar aún más casos de prueba para asegurar que todos los comportamientos de la clase se hayan ejercitado adecuadamente. En situaciones en que el comportamiento de la clase da como resultado la colaboración con una o más clases, se utilizan varios diagramas de estado para registrar el flujo del comportamiento del sistema.

Diagrama d e estado para ia c l a s e Cuenta adaptado de

configurar j Cuenta depositar (inicial)

nOR94]).

depositar saldar Crédito infoCuenta

trabajando| Cuenta

TM retirar

PDF Editor retirar (final)

r Cuenta

Cerrar

1

inactiva

452

PARTE D O S


El modelo de e s t a d o p u e d e recorrerse de u n a m a n e r a " p r i m e r o - e n - a n c h - i [MGR94]. En este contexto, p r i m e r o - e n - a n c h u r a indica que u n c a s o de prueba ejercita u n a transición. Cuando d e b e probarse u n a n u e v a transición sólo s e u transiciones p r o b a d a s previamente. Imagínese que el objeto TarjetaCredito es parte del sistema bancario. El inicial de TarjetaCredito es indefinido (es decir, no se h a proporcionado un n ro de tarjeta de crédito). Tras leer la tarjeta durante u n a venta, el objeto toma un t a d o definido-, es decir, se definen los atributos numero, tarjeta y fecha vencimiento to con los identificadores específicos del banco. La tarjeta de crédito es r c u a n d o se le envía para autorización, y e s aprobada c u a n d o se recibe la au ción. La transición de TarjetaCredito de un e s t a d o a otro se prueba derivantí J sos de prueba que causen la transición. Un método primero-en-anchura para esr.r de prueba no ejercitaría remitida antes de indefinida o definida. En este caso, usaría siciones que n o se han probado y, por tanto, violaría el criterio primero-en-anch^-i.

Los m é t o d o s de prueba analizados e n secciones anteriores suelen aplicarse d o s los entornos, las arquitecturas y las aplicaciones, pero en o c a s i o n e s se cionan directrices y e n f o q u e s únicos para las pruebas. En esta sección se a' las directrices para prueba de los entornos, las arquitecturas y las aplicaciones cializadas que suelen encontrar los ingenieros de software. ^CONSEJO^. Úsese una estrategia de prueba similar a la aleatoria o de partición (sección 14.8) poro diseñar pruebas de interfoz de usuario.

14.10.1 Pruebas de interfaces gráficas de usuario Las interfaces gráficas de usuario (GUI, por sus siglas en inglés) plantean d t e r e s a n t e s a los ingenieros de software. Debido a los c o m p o n e n t e s reutiliza porcionados c o m o parte de los entornos de desarrollo de la GUI, la creación ce terfaz de usuario c o n s u m e m e n o s tiempo y es m á s precisa (capítulo 12). Pero < m o tiempo ha crecido la complejidad de las GUI, lo que dificulta m á s el di ejecución de c a s o s de prueba. Debido a que m u c h a s GUI m o d e r n a s tienen un a s p e c t o y un m o d o de uso res, es posible derivar una serie de p r u e b a s estándar. Las gráficas de mod estado finito se u s a n para derivar u n a serie de p r u e b a s que ejerciten objetos fieos de d a t o s y p r o g r a m a s que resultan relevantes para la GUI.

TM Debido al gran n ú m e r o de p e r m u t a c i o n e s asociadas con las operaciones

GUI, la prueba d e b e reducirse e m p l e a n d o h e r r a m i e n t a s automatizadas. En

PDF Editor

m o s a ñ o s ha aparecido en el m e r c a d o u n a amplia serie de herramientas de

se encontrorfin información y recursos úlfesp cíenle/servidor: w.csst-

de GUI. Para u n mayor análisis al respecto consulte el capítulo 12.

14.10.2 Prueba d e arquitecturas cliente/servidor

La arquitectura cliente/servidor representa un importante desafio para q•

p r u e b a n el software. La naturaleza distribuida de los e n t o r n o s c l i e n t e / s e n

CAPÍTULO 14

453


aspectos de d e s e m p e ñ o relacionados con el proceso de transacción, la posible presencia de varias plataformas de hardware diferentes, la complejidad de la comunicación en red, la necesidad de servir a varios clientes desde una base de datos centralizada (o, en algunos casos, distribuida) y los requisitos de coordinación impuestos al servidor se combinan para que la prueba de las arquitecturas de software cliente/servidor resulte considerablemente m á s difícil que la prueba de aplicaciones independientes. En realidad, estudios recientes de la industria indican un aumento importante en el tiempo y costo de la prueba cuando se desarrollan entornos cliente/servidor. "En el temo de los pruebas existe una buena dosis de similitud entre los sistemas tradicional y diente/servidor." Kelley B o u m e

En general, la prueba del software cliente/servidor se presenta en tres niveles diferentes: 1) aplicaciones de cliente individuales s e prueban en una modalidad "desconectada"; la operación del servidor y la red n o se toman en cuenta; 2) el software de cliente y las aplicaciones asociadas del servidor se prueban en conjunto, pero las operaciones de red n o se ejercitan de manera explícita; 3) se prueba toda la arquitectura cliente/servidor, incluida la operación y el desempeño de la red. Aunque muchos tipos diferentes de prueba se conducen en cada uno de estos niveles de detalle, los siguientes enfoques d e prueba suelen encontrarse para aplicaciones cliente/servidor: • Pruebas de funcionalidad d e la aplicación. La funcionalidad de las aplicaciones de cliente se prueba empleando los métodos analizados en este capítulo. En esencia, la aplicación se prueba de manera independiente. • Pruebas de servidor. Se prueban las funciones de coordinación y m a n e j o de datos del servidor. También se considera el desempeño del servidor (tiempo de respuesta y procesamiento total de los datos). • Pruebas d e b a s e d e d a t o s . Se prueba la exactitud e integridad d e los datos almacenados en el servidor. Se examinan las transacciones que realizaron las aplicaciones de cliente para asegurar que los datos se almacenan, actualizan y recuperan apropiadamente. También se prueba la función de archivado. • Pruebas d e transacción. Se crea una serie de pruebas para asegurar que cada clase de transacciones se procesa de acuerdo con sus requisitos. Las pruebas s e concentran en determinar si es correcto el procesamiento y en asTM pectos del desempeño (por ejemplo, tiempos de procesamiento de las transacciones y volumen de éstas).

PDF Editor

• Pruebas d e c o m u n i c a c i o n e s de red. Con estas pruebas se verifica que la comunicación entre los nodos de la red ocurre de manera correcta y que el paso de mensajes, las transacciones y el tráfico de la red relacionado se realiza sin errores. También e s posible realizar pruebas de seguridad de la red como parte de estas pruebas.

454

PARTE D O S


Para completar estos enfoques de prueba, Musa [MUS93] recomienda el desarroi de perfiles operaáonales derivados de escenarios de uso de cliente/servidor. 9 Un per • fil operacional indica la manera en que diferentes tipos de usuarios interoperan ccri el sistema cliente/servidor. Es decir, los perfiles proporcionan un "patrón de us aplicable al diseño y ejecución de las pruebas.

14.10.3 Prueba de la documentación y las funciones de ayuda El término prueba del software evoca imágenes de grandes cantidades de casos ix| prueba preparados para ejercitar los programas de cómputo y los datos que manir ían. Si se recuerda la definición de software presentada en el primer capítulo de este libro, e s importante observar que la prueba también debe extenderse al tercer e e mentó de la configuración del software: la documentación. Los errores en la documentación son tan devastadores para la aceptación del p r : grama como los errores en los datos o el código fuente. Nada e s m á s frustrante seguir una guía de usuario o una función de ayuda en línea con toda pulcritud > tener resultados o comportamiento que no coinciden con los descritos en la mentación. Por eso la prueba de la documentación debe ser una parte signifi de cualquier plan de prueba del software. La prueba de la documentación se aborda en dos fases. En la primera, reviste inspección (capítulo 26), se examina la claridad editorial del documento. En la gunda fase, prueba en vivo, se emplea la documentación junto con el programa

Prueba de documentación

M ' I H ' M - I I

V,

• ¿El diseño del documento (formato, tipo de letra, sargrías, imágenes) es apropiado para comprender y a milor rápidamente la información?

• ¿La documentación describe con exactitud la manera en que se realiza cada modalidad de uso?

• ¿Todos los mensajes de error del software que se d e pliegan para el usuario están descritos con más en el documento? ¿Las acciones que deben emse como consecuencia de un mensaje de error i ramente delineadas?

Las siguientes preguntas deben responderse durante la prueba de documentación, de función de ayuda, o ambas:

• ¿Es exacta la descripción de cada secuencia de interacciones? • ¿Los ejemplos son exactos? • ¿La terminología, las descripciones de menú y las respuestas del sistema son consistentes con el programa real? • ¿Es realmente fácil localizar una guía dentro de la documentación? • ¿El uso de la documentación facilita la detección y resolución de errores?

• Si se usan los vínculos de hipertexto, ¿son exactos • completos? • Si se usa el hipertexto, ¿el diseño de la navegado 1- s apropiado para la información requerida? La única manera viable de responder TM a estas pregu^T. hacer que un tercero (por ejemplo, algunos usuarios i donados) pruebe la documentación en el contexto d e , del programa. Se habrán de indicar todas las discr cias y definirse las áreas débiles o ambiguas del to para una posible reescritura.

PDF Editor • ¿El contenido y el índice del documento son exactos y completos?

9

Debe observarse que los perfiles operacionales pueden aplicarse para probar todos los tipos

quitecturas del sistema, no sólo la cliente/servidor.

CAPÍTULO 14


455

14.10.4 Prueba de sistemas de tiempo real La naturaleza asincrónica, dependiente del tiempo, de m u c h a s aplicaciones en tiempo real agrega un elemento nuevo (y difícil en potencia) a la mezcla d e pruebas: el tiempo. El diseñador del caso de prueba n o sólo debe considerar los casos de prueba convencionales, sino también el manejo de eventos (es decir, el procesamiento de interrupciones), la temporización de los datos y el paralelismo entre las tareas (procesos) que manejan los datos. En muchas situaciones, los datos de prueba proporcionados cuando el sistema en tiempo real está en un estado producirán un procesamiento apropiado, mientras que los mismos datos proporcionados cuando el sistema esté en un estado diferente provocarán un error. Por ejemplo, el software en tiempo real que controla una nueva fotocopiadora acepta interrupciones del operador (es decir, el operador del equipo oprime teclas como RE1NICIAR u OSCURECER) sin error c u a n d o el equipo hace copias (en el estado copiar). Si estas mismas interrupciones del operador se ingresan cuando el equipo se encuentra en el estado atasco, se perderá la pantalla de visualización del código de diagnóstico (indicando la ubicación del atasco), lo que representa un error.

¿Cuál e s una estrategia i para la i de un s i s i en t i e m p o

Además, la íntima relación entre el software en tiempo real y su entorno de hardware llegan a causar problemas en la prueba. Las pruebas del software deben considerar el impacto de las fallas del hardware en el procesamiento del software. Resulta extremadamente difícil simular estas fallas de manera realista. Los métodos exhaustivos d e diseño de casos de prueba para sistemas en tiempo real siguen evolucionando. Sin embargo, es posible proponer una estrategia de cuatro pasos: • Prueba d e tareas. El primer paso en la prueba del software en tiempo real consiste en probar cada tarea de manera independiente. Es decir, s e diseñan y ejecutan pruebas convencionales para cada tarea. (Cada tarea se ejecuta de manera independiente durante estas pruebas.) La prueba de tareas descubre errores de lógica y funcionamiento, pero n o de tiempo ni de comportamiento. • Prueba d e c o m p o r t a m i e n t o . Con el empleo de modelos del sistema creados con herramientas automatizadas es posible simular el comportamiento de un sistema en tiempo real y examinarlo como una consecuencia de eventos externos. Estas actividades de análisis sirven como base para el diseño de casos de prueba que se realizan cuando se ha construido el software en tiempo real.

TMen tareas indi• Prueba intertareas. Una vez que s e hayan aislado los errores viduales y en el comportamiento del sistema, la prueba s e desplaza hacia los errores relacionados con el tiempo. Se prueban las tareas asincrónicas de las cuales se sabe que se comunican entre sí, empleando diferentes tasas de da-

PDF Editor

tos y cargas de procesamiento para determinar si ocurrirán errores de sincronización intertareas. Además, se prueban las tareas que se comunican por medio de la cola de mensajes o el almacén de datos para descubrir errores en el t a m a ñ o de estas áreas de almacenamiento de datos.

456

PARTE DOS

P R Á c n c A DE LA INGENIERÍA DEL SOFTWARE

* Prueba del s i s t e m a . El software y el hardware están integrados, de moc que se aplica un rango completo de pruebas del sistema (capítulo 13) para tar de descubrir errores en la interfaz software/hardware. Casi todos los mas en tiempo real procesan interrupciones. Por tanto, resulta esencial la prueba del m a n e j o de estos eventos booleanos. Por medio del diagrama a s estado y la especificación de control (capítulo 8), el responsable de la pi desarrolla una lista de todas las interrupciones posibles y el procesamier ' que ocurre como consecuencia de las interrupciones. Entonces s e diseñapruebas para evaluar las siguientes características del sistema. —¿Se han asignado y manejado apropiadamente las propiedades de in ción? —¿Se ha manejado correctamente el procesamiento de cada interrupci: —¿El desempeño de cada procedimiento de manejo de interrupciones ejemplo, el tiempo de procesamiento) cumple con los requisitos? —¿Un elevado volumen de interrupciones que llega en m o m e n t o s crític:•; problemas en la función o el desempeño? Además, deben probarse áreas de datos globales que se emplean para t información como parte de un procesamiento de interrupciones, con el fin ce luar la posibilidad de generación de efectos colaterales.

14.11

Apuntodores • más de 70 pollones de prueba se encontraún en wwwj-bsc.com.

\ CLAVE l o s p o d o n e s de pruebo ayudan o un equipo de software a comunicarse mejor sobre la prueba y también a comprender mejor te fuerzas que lewn o un e n f o q u e e p e í É c o d e prueba.

P A T R O N E S PE PRUEBA En capítulos anteriores se analizó el uso de patrones como mecanismo para bir los bloques de construcción del software o situaciones de ingeniería del Estos bloques de construcción o situaciones se repiten a medida que se co" diferentes aplicaciones o que se realizan diferentes proyectos. Como sus c* tes en el análisis y el diseño, los patrones de prueba describen bloques de c ción o situaciones frecuentes y que los responsables de probar el software reutilizar al afrontar la prueba de algún sistema nuevo o revisado. Los patrones de prueba n o sólo proporcionan a los ingenieros del software directriz útil cuando empiezan las actividades de prueba, también p r o p o r c i — beneficios adicionales descritos por Marick [MAR02]: TM 1. Proporcionan una terminología a los encargados de la resolución de los problen^s| "Hey, ¿sabes?, debemos usar un Objeto Nulo."

PDF Editor

2. Concentran la atención en las fuerzas que se encuentran detrás del problema. Esc mite a los diseñadores |de casos de prueba] comprender mejor cuándo se aplic¿ solución, y por qué. 3. Estimulan el razonamiento iterativo. Cada solución crea un nuevo contexto para ver nuevos problemas.

CAPÍTULO 14

. efícienencontroiói) .ogts.com/ y

/

/


457

Aunque estos beneficios sean "leves", n o deben perderse de vista. Buena parte de la prueba del software, incluso durante las últimas décadas, ha sido una actividad ad ftoc gj | Q S p a t r o n e s prueba ayudan a un equipo de software a comunicarse de manera más efectiva, a comprender las fuerzas motivadoras que llevan a un enfoque específico de prueba y a considerar el diseño de los casos de prueba como una actividad en evolución, se habrá logrado mucho. Los patrones de prueba se describen de manera muy parecida a los de análisis y diseño (capítulos 7 y 9). Se han propuesto docenas de patrones de prueba (por ejemplo, [B1N99], [MAR02]). Los siguientes tres patrones (presentados en forma resumida), proporcionan ejemplos representativos: Nombre del patrón: t e s t i g o p a r Resumen: Patrón orientado a procesos, t e s t i g o par describe u n a técnica análoga a la programación par (capítulo 4), en la cual d o s responsables d e una p r u e b a s trabajan d e m a n e ra conjunta para d i s e ñ a r y ejecutar u n a serie de p r u e b a s aplicables a actividades d e prueba d e unidad, integración o validación. Nombre del patrón: interfaz d e p r u e b a s e p a r a d a Resumen.

En s i s t e m a s orientados a objetos es necesario probar c a d a clase, incluidas las

"clases internas" (es decir, las clases q u e no exponen ninguna interfaz fuera del compon e n t e que las utiliza). El patrón interfaz d e p r u e b a s e p a r a d a describe la m a n e r a d e crear "una interfaz de prueba q u e permita describir p r u e b a s específicas en clases que sólo son visibles internamente para un c o m p o n e n t e " [LANOI]. Nombre del patrón: p r u e b a d e e s c e n a r i o Resumen: Una vez q u e se ha aplicado u n a prueba de unidad o d e integración es necesario determinar si el software se comportará d e m a n e r a tal q u e satisfaga al usuario. El patrón p r u e b a d e e s c e n a r i o describe u n a técnica p a r a ejercitar el software d e s d e el punto d e vista del usuario. Una falla en este nivel indica q u e el software n o satisface los requisitos d e un usuario visible [KAN01].

Un análisis completo de los patrones de prueba está más allá del alcance de este libro. El lector interesado debe consultar [BIN99] y [MAR02] para conocer mayor in formación sobre este importante tema.

14.12

RESUMEN El objetivo principal del diseño de casos de prueba consiste en derivar un conjunto TM de pruebas que tenga la mayor probabilidad de descubrir errores en el software. Alcanzar este objetivo requiere emplear dos categorías diferentes de técnicas de diseñ o de casos d e prueba (aplicables a sistemas convencionales y orientados a objetos): las pruebas de caja negra y de caja blanca. Las pruebas de caja blanca se concentran en la estructura de control del programa. Los casos de prueba se derivan para asegurar que todas las instrucciones del programa se ejecuten por lo m e n o s una vez durante la prueba, y que todas las condiciones lógicas se ejerciten. La prueba de la ruta básica, una técnica de caja blan-

PDF Editor

458

PARTE D O S


ca, aprovecha las gráficas de! programa (o matrices de gráficas) para derivar un junto de pruebas linealmente independientes que aseguren una cobertura. La ba de condición y de flujo de datos ejercitan aún m á s la lógica del programa prueba de bucle complementa otras técnicas de caja blanca al proporcionar un cedimiento para ejercitar bucles con grados diversos de complejidad. Las pruebas de caja negra están diseñadas para validar requisitos funcionales importar el funcionamiento interno de un programa. Estas técnicas de prueba concentran en el dominio de la información del software, derivando casos de ba mediante partición de los dominios de entrada y salida de un programa en tal que proporcione cobertura completa. La partición equivalente divide el d de entrada en clases de datos que probablemente ejercitarán una función es del software. El análisis de valores límite prueba la capacidad del programa para nejar datos en los límites de aceptabilidad. La prueba de tabla ortogonal prc na un método eficiente y sistemático de probar sistemas con números peque^ parámetros de entrada. Aunque el objetivo general de la prueba orientada a objetos (encontrar el ro máximo de errores con una cantidad mínima de esfuerzo) es idéntico al prueba del software convencional, la táctica para la prueba orientada a objet fieren un poco. El concepto de prueba se ensancha para incluir la revisión délo de análisis y diseño. Además, el eje de la prueba se desplaza del comp procedimental (el módulo) hacia la clase. El diseño de pruebas para u n a clase diversos métodos: prueba basada en fallas, aleatoria y de partición. Cada uno tos métodos ejercita las operaciones encapsuladas por la clase. Las s e c u e prueba están diseñadas para asegurar que se ejerciten operaciones relevar," examina el estado de la clase, representado por los valores de sus atributos, terminar si existen errores. La prueba d e integración se realiza mediante una estrategia basada en el te tipo de prueba construye el sistema en capas, e m p e z a n d o con las clases usan clase de servidor. Los métodos de diseño de casos de prueba de int" también pueden emplear pruebas aleatorias y de partición. Además, se utilizar bas basadas en el escenario y derivadas de modelos de comportamiento para una clase y s u s colaboradores. Una secuencia de prueba da seguimiento al las operaciones entre las colaboraciones de clases. Los métodos de prueba especializados abarcan una amplia serie de opc TM software y áreas de aplicación. La prueba para interfaces gráficas de usuario, quitecturas cliente/servidor, de la documentación y funciones de ayuda y de mas en tiempo real requieren directrices y técnicas especializadas.

PDF Editor

Los desarrolladores de software con experiencia suelen decir: "La prueba termina, sólo se transfiere del ingeniero del software al cliente. Cada vez usa el programa, está realizando una prueba". Al aplicar el diseño de casos i ba, el ingeniero de software logra pruebas más completas y, por tanto, d corrige el mayor número de errores antes de que empiecen las "pruebas del

CAPÍTULO 14

459

T É C N I C A S DE PRUEBA DEL S O F T W A R E

[AMB95] Ambler, S., "Using Use Cases", e n Software Development, julio d e 1995, pp. 53-61. [BE1901 Beizer, B., Software Testing Techniques, s e g u n d a edición, Van Nostrand-Rcinhold, 1990. [BE195] Beizer, B., Black-Box Testing, Wiley, 1995. [B1N94] Binder, R. V., "Testing Object-Oriented Systems: A Status Report", e n American Programmer; vol. 7, n ú m . 4, abril de 1994, pp. 23-28. [B1N99] Binder, R., Testing Object-Oriented Systems: Models, Patterns, and Tools, Addison-Wesley, 1999. [DEU79] Deutsch, M„ "Verification a n d Validation", e n Software Engineering (R. J e n s e n y C. Tonies, e d s ) , Prentice-Hall, 1979, pp. 329-408. [FRA88] Frankl, P. G. y E. J. Weyuker, "An Applicable Family of Data Flow Testing Criteria", e n IEEE Trans. Software Engineering, vol. SE-14, núm.10, octubre d e 1988, pp. 1483-1498. (FRA93] Frankl, P. G. y S. Weiss, "An Experimental C o m p a r i s o n of the Effectiveness of Branch Testing and Data Flow", e n IEEE Trans. Software Engineering, vol. SE-19, núm.8, a g o s t o de 1993, pp.770-787. [KAN93] Kaner, C., J. Falk y H. Q. Nguyen, Testing Computer Software, s e g u n d a edición, Van Nostrand-Reinhold, 1993. [KANOi] Kaner, C„ "Pattern: S c e n a r i o Testing" (borrador), 2001, disponible e n h t t p : / / w w w . t e s ting.com/test-pattems/patterns/pattem-scenario-testing-kaner.html. [K1R94] Kirani, S. y W. T. Tsai, "Specification and Verification of Object-Oriented Programs", Technical Report TR 94-64, C o m p u t e r Science D e p a r t m e n t , University of Minnesota, diciembre d e 1994. [LAN0II Lange, M., "It's Testing Time! Patterns for Testing Software", junio d e 2001, disponible para descarga en http://www.testing.com/test-patterns/patterns/index.html. [L1N94] Lindland, O. I. eí al., "Understanding Quality in Conceptual Modeling", e n IEEE Software, vol. 11, n ú m . 4, julio d e 1994, pp. 42-49. [MAR941 Marick, B., The Craft of Software Testing, Prentice-Hall, 1994. [MAR02] Marick, B., "Software Testing Patterns", 2002, h t t p : / / w w w . t e s t i n g . c o m / t e s t - p a t t e m s / index.html. [MCC76] McCabe, T., "A S o f t w a r e Complexity Measure", e n IEEE Trans. Software Engineering, vol. SE-2, diciembre d e 1976, pp. 308-320. [MGR94] McGregor, J. D. y T. D. Korson, "Integrated Object-Oriented Testing a n d D e v e l o p m e n t Processes", CACM, vol. 37, n ú m . 9, s e p t i e m b r e de 1994, pp. 59-77. [MUS93] M u s a , " O p e r a t i o n a l Profiles in S o f t w a r e Reliability Engineering", e n IEEE Software, m a r z o de 1993, pp. 14-32. [MYE79J Myers, G., The Art of Software Testing, Wiley, 1979[NTA88] Ntafos, S. C., "A C o m p a r i s o n of S o m e Structural Testing Strategies", e n IEEE Trans. Software Engineering, vol. SE-14, núm.6, junio de 1988, pp. 868-874. [PHA89] Phadke, M. S., Quality Engineering Using Robust Design, Prentice-Hall, 1989. [PHA97] Phadke, M. S., "Planning Efficient Software Tests", Crosstalk, vol. 10, n ú m . 10, octubre d e 1997, pp. 11-15. [TA1891 Tai, K. C., "What to Do Beyond Branch T e s t i n g A C M Software Engineering Notes, vol. 14, n ú m . 2, abril d e 1989, pp. 58-61.

TM 1 4 . 1 . Myers [MYE79] aplica el siguiente p r o g r a m a c o m o a u t o e v a l u a c i ó n d e la capacidad p r o pia para especificar p r u e b a s a d e c u a d a s : u n p r o g r a m a lee tres valores enteros. Los tres v a l o r e s s e interpretan c o m o si r e p r e s e n t a r a n las longitudes d e los lados d e un triángulo. El p r o g r a m a imprime un m e n s a j e q u e indica si el triángulo e s e s c a l e n o , isósceles o equilátero. Desarróllese u n c o n j u n t o d e c a s o s d e p r u e b a q u e s e considere q u e p r u e b e n a d e c u a d a m e n t e e s t e p r o g r a m a .

PDF Editor

1 4 . 2 . Diseñar e i m p l e m e n t a r el p r o g r a m a (con m a n e j o de e r r o r e s c u a n d o s e a apropiado) e s p e cificado e n el p r o b l e m a 14.1. Derivar u n a gráfica d e flujo p a r a el p r o g r a m a y aplicar la p r u e b a d e la ruta básica p a r a desarrollar c a s o s de p r u e b a q u e garanticen q u e s e h a n p r o b a d o t o d a s las instrucciones del p r o g r a m a . Ejecutar los c a s o s y m o s t r a r los resultados.

460

PARTE DOS


1 4 . 3 . ¿Al lector le e s posible p e n s a r e n a l g u n a p r u e b a adicional d e características q u e r. a n a l i z a r o n e n la s e c c i ó n 14.7? 1 4 . 4 . Seleccionar u n c o m p o n e n t e de s o f t w a r e q u e el lector h a y a d i s e ñ a d o e i m p l e m e n t a d c c i e n t e m e n t e . Diseñar u n c o n j u n t o de c a s o s d e p r u e b a q u e a s e g u r e n q u e t o d a s las instrucc s e h a y a n e j e c u t a d o con la p r u e b a d e la ruta básica. 1 4 . 5 . Especificar, diseñar e i m p l e m e n t a r u n a h e r r a m i e n t a de s o f t w a r e q u e calcule la c o r dad ciclomática p a r a el l e n g u a j e de p r o g r a m a c i ó n q u e s e elija. Aplicar la matriz d e gráfica m o estructura operativa de d a t o s e n el diseño. 1 4 . 6 . Léase Beizer [BE195] y d e t e r m í n e s e la m a n e r a e n q u e el p r o g r a m a q u e s e desarro, el p r o b l e m a 14.5 p u e d e e x t e n d e r s e p a r a a c o m o d a r varios p e s o s de enlace. Extiéndase la 1 m i e n t a p a r a p r o c e s a r probabilidades de ejecución o t i e m p o s de p r o c e s a m i e n t o de e n l a c e s 1 4 . 7 . Diséñese u n a h e r r a m i e n t a a u t o m a t i z a d a q u e r e c o n o z c a b u c l e s y los o r d e n e e n c a rías, c o m o s e indica e n la sección 14.5.3. 1 4 . 8 . Extiéndase la h e r r a m i e n t a descrita e n el p r o b l e m a 14.7 p a r a g e n e r a r c a s o s d e p r u e r s : ra c a d a categoría de bucle, u n a vez e n c o n t r a d a . Será n e c e s a r i o desarrollar esta función d e i ñ e r a interactiva con el e n c a r g a d o de la p r u e b a . 1 4 . 9 . O f r é z c a n s e por lo m e n o s tres e j e m p l o s e n q u e la p r u e b a d e caja n e g r a daria la in de q u e "todo está bien", m i e n t r a s q u e las p r u e b a s d e c a j a blanca descubrirían u n error p o r lo m e n o s tres e j e m p l o s e n q u e s u c e d a lo contrario: la p r u e b a de c a j a blanca daría la i sión de q u e "todo está bien", m i e n t r a s q u e las p r u e b a s de c a j a n e g r a descubrirían u n errcr 1 4 . 1 0 . ¿La p r u e b a exhaustiva (en c a s o de q u e s e a posible e n p r o g r a m a s muy pequeños] ¡ tiza q u e el p r o g r a m a e s t o t a l m e n t e correcto? 1 4 . 1 1 . En p a l a b r a s propias, descríbase por q u é la clase e s la m e n o r u n i d a d r a z o n a b l e p r u e b a d e n t r o d e u n s i s t e m a o r i e n t a d o a objetos. 1 4 . 1 2 . ¿Por q u é s e tienen q u e volver a p r o b a r s u b c l a s e s q u e c r e a n i n s t a n c i a s a partir c l a s e existente si ésta ya s e h a p r o b a d o p o r c o m p l e t o ? ¿Es posible u s a r los c a s o s d e pn s e ñ a d o s p a r a la clase existente? 1 4 . 1 3 . Apliqúense p r u e b a s aleatorias y d e partición a tres clases definidas e n el d i s e ñ o t e m a HogarSeguro. P r o d ú z c a n s e c a s o s de p r u e b a q u e indiquen las s e c u e n c i a s d e opera se invocarán. 1 4 . 1 4 . Apliqúense p r u e b a s de clase múltiple y p r u é b e n s e derivados del m o d e l o de • m i e n t o para el d i s e ñ o HogarSeguro. 1 4 . 1 5 . Pruébese u n m a n u a l d e u s u a r i o (o u n a íúnción d e ayuda) d e u n a aplicación q u e i c o n frecuencia. E n c u é n t r e s e por lo m e n o s u n error e n la d o c u m e n t a c i ó n .

Entre d o c e n a s de libros q u e p r e s e n t a n m é t o d o s d e d i s e ñ o d e c a s o s de p r u e b a s e Craig y Kaskiel (Systematic Software Testing, Artech House, 2002), T a m r e s TM (Introducing : Testing, Addison-Wesley, 2002), Whittaker (How to Break Software, Addison-Wesley, g e n s e n ( S o f t w a r e Testing: A Craftman's Approach, CRC Press, 2002), Splaine y s u s co Web Testing Handbook, Software Quality Engineering Publishing, 2001), Patton (So/fw S a m s Publishing, 2000), Kaner y s u s colegas (Testing Computer Software, s e g u n d a i ley, 1999). Además, H u t c h e s o n (Software Testing Methods and Metrics: The Most Imp McGraw-Híll, 1997) y Marick (The Craft of Software Testing: Subsyslem Testing Includirj I Based and Object-Oriented Testing. Prentice-Hall, 1995) p r e s e n t a n t r a t a m i e n t o s d e m é trategias d e p r u e b a . Myers [MYE79] sigue s i e n d o u n texto clásico, q u e a n a l i z a las técnicas d e caja negra detalle. Beizer [BE 190] p r o p o r c i o n a u n a amplia cobertura de las técnicas de c a j a bla

PDF Editor

CAPÍTULO 14

461

T É C N I C A S DE PRUEBA DEL S O F T W A R E

d u c e un nivel de rigor m a t e m á t i c o q u e a m e n u d o s e o m i t e e n o t r o s t r a t a m i e n t o s de p r u e b a s . Su último libro [BEI95] p r e s e n t a un t r a t a m i e n t o c o n c i s o d e m é t o d o s importantes. Perry (EJfective Methods for Software Testing, Wiley-QED, 1995) y Friedman y Voas (Software Assessment: Reliabiliy Safety, Testabitity, Wiley, 1995) p r e s e n t a n b u e n a s introducciones a las e s t r a t e g i a s y tácticas d e p r u e b a . Mosley (The Handbook of MIS Application Software Testing, Prentice-Hall, 1993) a n a liza t e m a s d e p r u e b a para s i s t e m a s de información grandes, y Marks (Testing Vety Big Systems, McGraw-Hill, 1992) analiza los a s p e c t o s e s p e c i a l e s q u e deben t o m a r s e e n c u e n t a c u a n d o s e p r u e b a n s i s t e m a s d e p r o g r a m a c i ó n importantes. Sykes y McGregor (Practica! Guide for Testing Object Oriented Software, Addison-Wesley, 2001), Bashir y Goel (Testing Object-Oriented Software, Springer-Verlag. 2000), Binder (Testing Object-Oriented Systems, Addison-Wesley, 1999), Kung y s u s c o l e g a s (Testing Object-Oriented Software, IEEE C o m p u t e r Society Press. 1998), Marick (The Craft ofSofhvare Testing, PrenticeHall, 1997) y Siegel y Muller (Object-Oriented Software Testing: A Hicrarchical Approach, wiley, 1996) p r e s e n t a n e s t r a t e g i a s y m é t o d o s para probar s i s t e m a s o r i e n t a d o s a objetos. La p r u e b a del s o f t w a r e e s u n a actividad q u e o c u p a m u c h o s recursos. Por ello, m u c h a s organ i z a c i o n e s a u t o m a t i z a n p a r t e s del p r o c e s o d e p r u e b a . Libros de Dustin, Rashka y Poston (Automated Software Testing: Introduction, Management, and Performance, Addison-Wesley, 1999), G r a h a m y s u s c o l e g a s (Software Test Automation, Addison-Wesley, 1999), y P o s t o n (Automating Specification-Based Software Testing, IEEE C o m p u t e r Society, 1996) a n a l i z a n h e r r a m i e n t a s , e s t r a tegias y m é t o d o s p a r a p r u e b a s a u t o m a t i z a d a s . Varios libros c o n s i d e r a n los m é t o d o s y las e s t r a t e g i a s de p r u e b a en á r e a s d e aplicación e s pecializadas. Gardiner (Testing Safety-Related Software: A PracticaI Handbook, Springer-Verlag, 1999) ha editado un libro q u e aborda la p r u e b a d e s i s t e m a s de seguridad crítica. Mosley (Client/ Server Software Testing on the Desk Top and the Web, Prentice-Hall, 1999) analiza el p r o c e s o de p r u e b a p a r a clientes, servidores y c o m p o n e n t e s de red. Rubin (Handbook of Usability Testing, Wiley, 1994) h a escrito u n a guía útil para q u i e n e s d e b e n ejercitar i n t e r f a c e s h u m a n a s . Binder IBIN991 describe casi 70 p a t r o n e s de p r u e b a q u e cubren m é t o d o s d e prueba, c l a s e s / grupos, s u b s i s t e m a s , c o m p o n e n t e s reutilizables, m a r c o s c o n c e p t u a l e s y sistemas, a d e m á s d e a u t o m a t i z a c i ó n d e p r u e b a s y p r u e b a d e b a s e de d a t o s especializada. Una lista de e s t o s patrones se encontrará en www.rbsc.com/pages/TestPatternList.htm. Una a m p l i a variedad d e f u e n t e s d e información s o b r e los m é t o d o s d e d i s e ñ o de c a s o s d e p r u e b a está disponible e n Internet. Una lista actualizada d e referencias e n la World Wide Web q u e tienen relevancia p a r a las técnicas d e p r u e b a s e e n c u e n t r a e n el sitio Web SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P I T U L O

15 CONCEPTOS CLAVE calidad

464

factores de McCall

464

indicadores... .467 medición......471 atributos . . . .471 principios medidas

469 467

de código

493

de mantenimiento

496

de modelo de análisis . .474 de modelo de diseño . . .479 orientadas a objetos . . .481 prueba de . . . .494 paradigma OPM

470

M É T R I C A S DEL P R O D U C T O P A R A EL SOFTWARE

L

a medición es u n e l e m e n t o clave en cualquier proceso de ingeniería medidas se e m p l e a n para c o m p r e n d e r mejor los atributos de los mocfc que se crean y evaluar la calidad de los productos de la ingeniería o de sistemas que se construyen. Pero a diferencia de o t r a s disciplinas de la ingería, la del s o f t w a r e n o se basa en las leyes cuantitativas básicas de la física m e d i d a s directas, c o m o el voltaje, la masa, la velocidad o la temperatura r. c o m u n e s e n el m u n d o del software. Debido a q u e las medidas y métricas software suelen ser indirectas están expuestas al debate. Fenton [FEN91] a : este t e m a c u a n d o afirma: La medición e s el p r o c e s o m e d i a n t e el cual s e a s i g n a n n ú m e r o s o s í m b o l o s a los c ^ b u t o s d e e n t i d a d e s reales para definirlas de a c u e r d o con reglas c l a r a m e n t e e s t a b l e : i das... En las ciencias físicas, la m e d i c i n a y, m á s r e c i e n t e m e n t e , las ciencias s o d a es a h o r a p o d e m o s medir atributos q u e s e c o n s i d e r a b a n imposibles d e medir. . Por s p u e s t o , e s t a s m e d i c i o n e s n o tienen el m i s m o r e f i n a m i e n t o q u e casi t o d a s las de ciencias físicas... p e r o existen [y m u c h a s decisiones i m p o r t a n t e s s e t o m a n con en ellas]. S e n t i m o s q u e la obligación d e tratar de "medir lo inmedible" para m e ; ; - £ n u e s t r a c o m p r e n s i ó n d e e n t i d a d e s particulares e s t a n i m p o r t a n t e e n la ingeniería i s o f t w a r e c o m o e n cualquier otra disciplina.

Pero algunos m i e m b r o s de la c o m u n i d a d de software siguen a r g u m e n t a n c i el s o f t w a r e "es inmedible", o que deben posponerse los intentos de medir! I ta que se c o m p r e n d a mejor el propio s o f t w a r e y los atributos que deben ut se para describirlo. Esto es un error.

puntos de función . . . .474

¿ Q u é e s ? Por su naturaleza, la ingeniería es una disciplina cuantitativa. Los ingenieros usan números como apoyo para el diseño y la evaluación del producto que construirán. Hasta hace poco, los ingenieros de software contaban con escasas guías cuantitativas en su trabajo, pero eso está cambiando. Las métricas del producto los ayudan a conocer mejor el diseño y la construcción del software que elaboran. A diferencia de las métricas del proceso y el proyecto que se aplican al proyecto (o ai proceso) co-

mo un todo, las métricas del producto se corar- 4 tran en atributos específicos de los productes ti trabajo de la ingeniería del software y se r e : : : M lan a medida que se realizan las tareas téc- : • (análisis, diseño, codificación y TM prueba). ¿ Q u i é n lo h a c e ? Los ingenieros de software r H las métricas del producto como apoyo : H construir software de mayor calidad. ¿ P o r q u é e s i m p o r t a n t e ? Siempre inte drán elementos cualitativos en la creaciósoftware. El problema es que no basta a:" evaluación cualitativa. Un ingeniero de soi

PDF Editor

CAPÍTULO 15

463

M É T R I C A S DEL P R O D U C T O P A R A EL S O F T W A R E

-ecesita criterios objetivos para orientar el diseio de los datos, la arquitectura, las interfaces y tos componentes. El responsable de la prueba equiere una guía cuantitativa que le ayude a aleccionar los casos de prueba y sus objetivos. -Qs métricas del producto proporcionar, una bae para que el análisis, el diseño, la codificación ' la prueba se realicen con mayor objetividad y se evalúen de manera más cuantitativa. ¿C j ó l e s son los p a s o s ? El primer paso del oroceso de medición consiste en derivar, a par• r del software, las medidas y métricas apropiaaas para la representación del software que se está considerando. A continuación se reúnen los datos para derivar las métricas formuladas. Una 'ez calculadas, se analizan las métricas apropiadas con base en directrices preestablecidas y en datos anteriores. Los resultados del análisis se

interpretan para conocer más acerca dejj la calidad del software; los resultados desembocan en la modificación de los modelos de análisis y diseño, de código fuente o los casos de prueba. En algunos casos, tal vez se llegue a la modificación del propio proceso del software. ¿Cuál e s el p r o d u c t o o b t e n i d o ? Las métricas del producto que se calculan a partir de tos datos recopilados de los modelos de análisis y di seño, de código fuente y casos de prueba. ¿ C ó m o p u e d o e s t a r s e g u r o d e q u e lo h e h e c h o c o r r e c t a m e n t e ? Deben determinarse los objetivos de b medición antes de iniciar lo recopilación de datos, definiendo cada métrica del producto sin ambigüedades. Defínanse unas cuantas métricas y luego utilícense para reconocer la calidad de un producto de trabajo de la ingeniería del software.

Aunque las métricas del producto para el software de computadora no suelen ser absolutas, proporcionan una manera sistemática de evaluar la calidad a partir de un conjunto de reglas definidas con claridad. También proporcionan al ingeniero de software información inmediata y en el sitio; no posterior al hecho. Esto permite al ingeniero descubrir y corregir problemas potenciales antes de que se conviertan en defectos catastróficos. En este capítulo se analizarán las mediciones con que se evalúa la calidad del producto mientras se diseña o construye. Estas medidas de atributos internos del producto proporcionan al ingeniero de software una indicación en tiempo real de la eficacia de los modelos de análisis, diseño y código; también aportan indicativos de la efectividad de los casos de prueba y la calidad general del software que habrá de construirse. 15.1

CALIDAD g e n e r a l

_

_

_

_

_

.

..

.

Hasta los desabolladores de software exhaustos están de acuerdo en que es importante crear software de alta calidad. Pero, ¿cómo se define la calidad? En el sentido TM más amplio, calidad del software es el cumplimiento de los requisitos de funcionalidad y desempeño explícitamente establecidos, de los estándares de desarrollo explícitamen-

PDF Editor

te documentados y de las características implícitas que se esperan de todo software desarrollado profesionalmente. Es indudable que esta definición podría modificarse o extenderse y debatirse interminablemente. En cuanto a los objetivos de este libro, la definición sirve para destacar tres puntos importantes:

464

PARTE DOS


1. Los requisitos del software son la base de las medidas de calidad. La falta J Í I concordancia con estos requisitos e s una falta de calidad.' 2-

Los estándares especificados definen un conjunto de criterios de desarrol ! que guían la ingeniería dei software. Si no se siguen los criterios, el r e s u l t a a r ! será, casi seguramente, la falta de calidad.

3-

A menudo se soslaya un conjunto de requisitos implícitos (por ejemplo, e seo de alcanzar la facilidad de uso). Si el software cumple con s u s requisr ~ I explícitos pero no con los implícitos, la calidad del software estará en duc_. I

La calidad del software es una compleja combinación de factores que variarán í - * J diferentes aplicaciones y los distintos clientes que las solicitan. En las siguientes s a i ciones se identifican los factores que afectan la calidad del software y se d e s c r i o a las actividades h u m a n a s que deben desarrollarse para alcanzarla.

15.1.1 Factores de calidad de McCall Los factores que afectan la calidad del software se dividen en dos grandes grup i l los que se miden directamente (por ejemplo, defectos descubiertos durante la ba), y 2) los que sólo se miden indirectamente (por ejemplo, facilidad de uso > • mantenimiento). En cada caso debe presentarse una medición. Se debe c o m p a r ^ H software (programa, datos, documentos) con algún conjunto de datos y o b t e n s H algún indicio sobre la calidad. McCall, Richards y Walters [MCC77] propusieron una clasificación útil de los fl tores que afectan la calidad del software. Estos factores, que se muestran en la « ra 15.1, se concentran en tres aspectos importantes de un producto de software características operativas, su capacidad para experimentar cambios y su capa para adaptarse a nuevos entornos. Si se toman como referencia los factores indicados en la figura 15.1, McCall • colegas proporcionan las siguientes descripciones:

TM

PDF Editor Corrección

Facilidad de uso

Confiabilidad

1

Eficiencia

Integridad

Es importante indicar que la calidad se extiende a las características técnicas de los modelos

lisis y diseño, así como a la realización del código fuente de éstos. Modelos de alta calida; sentido técnico) darán lugar a software de alta calidad, desde el punto de vista del cliente

CAPÍTULO 15 Corrección.

465


El g r a d o e n q u e el p r o g r a m a c u m p l e c o n s u e s p e c i f i c a c i ó n y s a t i s f a c e l o s o b -

j e t i v o s q u e p r o p u s o el cliente.

KVE

Conflabilidad.

El g r a d o e n q u e s e e s p e r a r í a q u e u n p r o g r a m a d e s e m p e ñ e su f u n c i ó n c o n la

p r e c i s i ó n r e q u e r i d a . [Debe o b s e r v a r s e q u e s e h a n p r o p u e s t o o t r a s d e f i n i c i o n e s d e c o n t i a -

¡ observar i ioctores de i McCall son s hoy como i en lo década Por tanto, es ¡ afirmar que s que : calidad del s no cambian iwnpo.

bilidad m á s c o m p l e t a s ( c o n s ú l t e s e el c a p í t u l o 26)]. Eficiencia. La c a n t i d a d d e c ó d i g o y d e r e c u r s o s d e c ó m p u t o n e c e s a r i o s p a r a q u e u n p r o g r a m a realice s u f u n c i ó n . Integridad.

El g r a d o d e c o n t r o l s o b r e el a c c e s o al s o f t w a r e o los d a t o s por p a r t e d e l a s p e r -

sonas no autorizadas. Facilidad de uso. El e s f u e r z o n e c e s a r i o p a r a a p r e n d e r , o p e r a r y p r e p a r a r los d a t o s d e e n t r a d a d e u n p r o g r a m a e i n t e r p r e t a r la salida. Facilidad de mantenimiento.

El e s f u e r z o n e c e s a r i o p a r a localizar y c o r r e g i r u n e r r o r e n u n

p r o g r a m a . (Una d e f i n i c i ó n m u y limitada.) Flexibilidad.

El e s f u e r z o n e c e s a r i o p a r a m o d i f i c a r u n p r o g r a m a e n o p e r a c i ó n .

Facilidad de prueba.

El e s f u e r z o q u e d e m a n d a p r o b a r u n p r o g r a m a c o n el fin d e a s e g u r a r

q u e r e a l i z a su f u n c i ó n . Portabilidad.

El e s f u e r z o n e c e s a r i o p a r a t r a n s f e r i r el p r o g r a m a d e u n e n t o r n o d e h a r d w a -

re o s o f t w a r e a otro. Facilidad de reutilización.

El g r a d o e n q u e u n p r o g r a m a (o p a r t e s d e él) p u e d e r e u t i l i z a r s e

e n o t r a s a p l i c a c i o n e s (en r e l a c i ó n c o n el e m p a q u e t a m i e n t o y el a l c a n c e d e l a s f u n c i o n e s q u e r e a l i z a el p r o g r a m a ) . Interoperabilidad.

[CONSEJO.

? uno listo r de verificación ) estos 5. Primero i o codo uno t mportoncia ¡pora su Luego i una groduai poro sus s de trabajo i el fin de evaluar t Édad del software f se estú constru-

El e s f u e r z o n e c e s a r i o p a r a a c o p l a r u n s i s t e m a c o n o t r o .

y a calidad de un producto es una función del bien que hace ol mundo." Totn DeMarco

Es difícil, y e n algunos c a s o s imposible, desarrollar medidas directas 7 de e s t o s factores de la calidad. En realidad, m u c h a s de las métricas que definen McCall et al. s ó lo se miden subjetivamente. Es c o m ú n que las métricas adquieran la forma de una lista de comprobación que se emplea para "asignar una graduación" a atributos e s pecíficos del s o f t w a r e [CAV78],

15.1.2 Factores de calidad del estándar ISO 9126 TM El e s t á n d a r ISO 9126 se desarrolló c o m o un intento por identificar los atributos de calidad para el software de computadora. El e s tá n d ar identifica seis atributos clave de la calidad:

PDF Editor 2

Una medida directa indica q u e sólo e s posible contar un valor q u e proporciona una indicación di-

recta del atributo q u e se examina. Por ejemplo, el "tamaño" d e u n programa se m i d e directamente al contar el n ú m e r o d e líneas d e código

466

PARTE DOS

P R Á C T I C A DE LA INGENIERÍA DEL S O F T W A R E

Funcionalidad.

El grado en q u e el s o f t w a r e satisface las necesidades que in

los siguientes subatributos: idoneidad, exactitud, interoperabilidad, cumplimier:

<

seguridad. Contabilidad.

La cantidad de tiempo en que el s o f t w a r e está disponible para

lo según los siguientes subatributos: m a d u r e z , tolerancia a fallas y facilidad de peración. Facilidad de uso. La facilidad con que se u s a el software de a c u e r d o con te guientes subatributos: facilidad de comprensión, facilidad de aprendizaje y o] lidad. Eficiencia. El grado en que el software emplea en forma óptima los recursos ¿ a sistema, c o m o lo indican los siguientes subatributos: c o m p o r t a m i e n t o en el ti c o m p o r t a m i e n t o de los recursos. Facilidad de mantenimiento.

La facilidad con que s e repara el software de a

c o n los siguientes subatributos: facilidad de análisis, facilidad de cambio, esta y facilidad de prueba. Portabilidad. La facilidad con que se lleva el s o f t w a r e de un e n t o r n o a otro los siguientes subatributos: adaptabilidad, facilidad para instalarse, cumpli facilidad para reemplazarse. Al igual que otros factores de calidad del software analizados en el capítulo 9 * sección 15.1.1, los factores ISO 9126 no n e c e s a r i a m e n t e se p r e s t a n a la medicic - d recta. Sin embargo, proporcionan u n a b a s e valiosa para las medidas indirectas \ lista de verificación excelente para evaluar la calidad de un sistema. "Cualquier actividad se vuelve aeotiva cuando la persona que hace las cosos los hoce bien, o mejor." John

15.1.3 La transición a un concepto cuantitativo En las secciones anteriores se analizó un c o n j u n t o de factores cualitativos

I rJ

"medición" de la calidad del software. El esfuerzo por desarrollar medidas p

de la calidad del s o f t w a r e en ocasiones se frustra por la naturaleza subjetiva actividad. Cavano y McCall [CAV78] analizan esta situación:

La d e t e r m i n a c i ó n d e la calidad e s u n factor clave e n t o d a s las actividades diarias TM ( c o n a r - 1 sos de c a t a d e vinos, c o m p e t e n c i a s deportivas [como la gimnasia), c o n c u r s o s de t a l e - : fl etc.). En e s t a s s i t u a c i o n e s la calidad s e juzga d e la m a n e r a m á s b á s i c a y directa: c o r r : r 1

PDF Editor

r a n d o o b j e t o s q u e se e n c u e n t r a n j u n t o s e n c o n d i c i o n e s idénticas y con c o n c e p t o s p r e j t I t e r m i n a d o s . El vino s e juzga d e a c u e r d o con su claridad, color, b o u q u e t , sabor, etc. S e e m b a r g o , e s t e tipo de juicios e s muy subjetivo; p a r a q u e t e n g a algún valor d e b e haceii-: u n experto.

La subjetividad y la especialización t a m b i é n s e aplican p a r a d e t e r m i n a r la calidad J*'

software. Se necesita u n a definición m á s precisa d e la calidad del s o f t w a r e p a r a resc a

CAPÍTULO 15

467


e s t e p r o b l e m a , a d e m á s d e u n m e d i o p a r a derivar m e d i d a s cuantitativas, a partir d e la calidad del s o f t w a r e , para realizar u n análisis objetivo...

En las secciones siguientes se e x a m in a u n conjunto de métricas que se aplican en la evaluación cuantitativa de la calidad del software. En todos los c a s o s las métricas representan m e d i d a s indirectas; es decir, nunca se mide r e a l m e n t e la calidad, sino alguna manifestación de ésta. El factor que complica las c o s a s e s la relación precisa entre la variable que se mide y la calidad del software.

"Así como la medición de la temperatura empieza con un dedo Índice... y da lugar a escalas, herramientas y técnicas sofisticadas, asi sucede también con la madurez en la medición del software." Shan Pfieeger

15.2

U N M A R C O C O N C E P T U A L PARA LAS MÉTRICAS DEL P R O D U C T O C o m o se indicó en la introducción de e s t e capítulo, la medición asigna n ú m e r o s o símbolos a atributos de entidades reales. Esto requiere un modelo de medición que a b a r q u e un c o n j u n t o consistente de reglas. Aunque la teoría de la medición (por ejemplo, [KYB84)) y su aplicación al s o f t w a r e de c o m p u t a d o r a (por ejemplo, [DEM81], [BR196], [ZUS97]) son t e m a s que rebasan el alcance de este libro, vale la pena establecer un marco conceptual y un conjunto de principios básicos para la m e dición de métricas para el producto de software.

15.2.1 Medidas, métricas e indicadores Aunque medida, medición y métrica son términos que suelen utilizarse de m a n e r a intercambiable, e s importante observar las sutiles diferencias e n t r e ellos. En el contexto de la ingeniería del s o f t w a r e u n a medida proporciona u n a indicación cuantitativa de la extensión, la cantidad, la dimensión, la capacidad o el t a m a ñ o de algún atributo de un producto o proceso. Medición es el acto de determinar una medida. El Glosario de estándares del IEEE [IEE93] define métrica c o m o una "medida cuantitativa del grado en que un sistema, c o m p o n e n t e o proceso posee un atributo determinado". Cuando se ha recopilado un solo tipo de datos (por ejemplo, el n ú m e r o de errores descubiertos dentro de un solo c o m p o n e n t e del software) s e ha establecido una m e dida. La medición ocurre c o m o resultado de la recopilación de uno o m á s puntos d e datos (por ejemplo, se investigan varias revisiones de c o m p o n e n t e s yTM pruebas de unidad para reunir medidas del n ú m e r o de errores encontrados en cada uno). Una métrica de software relaciona de alguna manera las medidas individuales (por ejemplo, el

PDF Editor

n ú m e r o promedio de errores e n c o n t r a d o s en cada revisión o prueba de unidad). Un ingeniero de s o f t w a r e recopila medidas y desarrolla métricas para obtener los

indicadores. Un indicador e s u n a métrica o u n a combinación de métricas que pro-

porcionan conocimientos acerca del proceso del software, un proyecto de s o f t w a r e o el propio producto. Un indicador proporciona conocimientos que permiten al jefe

468

PARTE DOS


de proyecto o los ingenieros de s o f t w a r e ajustar el proceso, el proyecto o el proc.c-1 to para que las c o s a s mejoren.

]

"Una tiendo tiene la misma madurez que sus herramientas de medición' Luis P

15.2.2 El reto de las métricas del producto En las últimas tres décadas, m u c h o s investigadores h a n tratado de desarrolla- J sola métrica que proporcione u n a medida completa de la complejidad del s o f h r a B Fenton [FEN94] caracteriza esta investigación c o m o u n a b ú s q u e d a del "santc e n imposible". Aunque se h a n propuesto d o c e n a s de medidas de complejidad [ Z l ' 5 V cada una tiene u n concepto diferente de la complejidad y de los atributos de un m a que llevan a la complejidad. Por analogía, considérese u n a métrica para e v a l u a r ® automóvil atractivo. Algunos observadores destacarían el diseño de la carrocena

T®

tomarían en cuenta características mecánicas y otros m á s podrían considerar e: el desempeño, la economía de combustible o la capacidad de reciclarlo cuandc to s e a inservible. Como cualquiera de estas características estaría en d e s v e n t a n otras, resulta difícil derivar un solo valor de "atractivo". El m i s m o problema con el software de c o m p u t a d o r a . Pero existe la necesidad de medir y controlar la complejidad del software Horst Zuseho recopilado gran cantidod de informoción sobre métricas de producto en irb.cs.tubeHin. de/~iuse/.

afl

difícil derivar un solo valor de esta métrica de calidad, d e b e tenerse la posibi desarrollar medidas de diferentes atributos internos del p r o g r a m a (por ejempk: a l dularidad efectiva, independencia funcional y otros atributos analizados del c a p M B al 12). Estas medidas y las métricas derivadas de ellas se utilizan c o m o indicac dependientes de la calidad de los modelos de análisis y diseño. Pero aquí t a m t gen problemas. Fenton [FEN94] observa esto c u a n d o afirma: "El peligro de t r s i ^ H encontrar medidas que caractericen tantos atributos diferentes es que inevitar te las medidas tienen que satisfacer objetivos que entran e n conflicto entre sí o p o n e a la teoría de que cada medición debe ser representativa." Aunque la ción de Fenton e s correcta, muchas personas argumentan que la medición del realizada durante las primeras e t a p a s del proceso del software proporciona a 1 genieros un m e c a n i s m o consistente y objetivo para evaluar la calidad. Sin embargo, vale la p e n a preguntarse s o b r e la validez de las métricas 3£ ducto. Es decir, ¿qué t a n t o c o n c u e r d a n las métricas del producto, laTM confíat largo plazo y la calidad de un sistema de cómputo? Fenton [FEN91] aborda t s H quietud de la siguiente m a n e r a :

PDF Editor

A p e s a r d e las c o n e x i o n e s intuitivas e n t r e la estructura interna d e los p r o d u c t o s de a

w a r e [métricas del producto] y los atributos d e su p r o d u c t o y su p r o c e s o e x t e r n o s lidad s e h a n r e a l i z a d o m u y p o c o s i n t e n t o s científicos p o r establecer relaciones e s p e c á i ^ B Esto e s así por varias r a z o n e s : la q u e s e cita c o n m á s f r e c u e n c i a e s q u e resulta pocc tico realizar e x p e r i m e n t o s relevantes.

CAPÍTULO 15


469

Cada uno de los "retos" indicados aquí debe t o m a r s e con cautela, pero no hay razón para restarle méritos a las métricas técnicas. 3 La medición es esencial si se desea a lc a n z a r la calidad.

15.2.3 Principios d e medición Antes de introducir una serie de métricas del producto que 1) ayuden a evaluar los modelos de análisis y diseño, 2) ofrezcan una indicación de la complejidad de los diseños procedimentales y el código fuente, y 3) faciliten el diseño de pruebas m á s efectivas, es importante c o m p r e n d e r los principios básicos de la medición. Roche [ROC94] sugiere un proceso de medición al que caracterizan cinco actividades: • Formulación.

i ¿Csóles son ' t e s posos de i de i efettivo?

La derivación de medidas y métricas a p r o p i a d a s para la repre-

sentación del software que se considera. • Recolección. El m e c a n i s m o con que se a c u m u l a n los d a t o s necesarios para derivar las métricas formuladas. • Análisis. El cálculo de las métricas y la aplicación de herramientas matemáticas. • Interpretación.

La evaluación de las métricas en un e s f u e r z o por c o n o c e r m e -

jor la calidad de la representación. • Retroal¡mentación.

Recomendaciones derivadas de la interpretación de las mé-

tricas del producto transmitidas al equipo del software. Las métricas del software sólo serán útiles si están caracterizadas de manera efectiva y se validan para probar su valor. Los siguientes principios [LET03] son representati-

*

vos de m u c h o s otros que podrían proponerse para caracterizar y validar las métricas: • Una métrica debe tener propiedades matemáticas deseables. Es decir, el valor de la métrica debe estar en un rango significativo (por ejemplo, de cero a uno, donde cero realmente significa ausencia, uno indica el valor m á x i m o y 0.5 representa el "punto medio"). Además, una métrica que pretende estar en una escala racional no debe contar con c o m p o n e n t e s que sólo se miden en una escala ordinal. • Cuando una métrica representa una característica de software que aumenta cuando se presentan rasgos positivos o que disminuye al encontrar rasgos indeseables, el valor de la métrica debe aumentar o disminuir en el mismo sentido. • Cada métrica debe validarse empíricamente

en una amplia variedad de contextos

antes de publicarse o aplicarse en la toma de decisiones. Una métrica d e b e m e TM dir el factor de interés, independientemente de otros factores. Debe "crecer" para aplicarse en sistemas g r a n d e s y funcionar e n diversos lenguajes de pro-

PDF Editor gramación y dominios de sistemas.

3

Aunque la crítica de métricas específicas e s común e n la bibliografía, muchas de esas criticas se con-

centran en aspectos esotéricos y pierden de vista el principal objetivo de las métricas en la realidad: ayudar al ingeniero de software a establecer una manera sistemática y objetiva de conocer a fondo su trabajo y, como resultado, mejorar la calidad de! producto

470

PARTE DOS

PRÁCnCA DE LA INGENIERÍA D A S O F T W A R E

Aunque la formulación, caracterización y validación s o n críticas, la recopilación 11 análisis s o n las actividades que dirigen el proceso de medición. Roche [ROC94] giere las siguientes directrices para e s t a s actividades: 1) siempre que sea posible b e n a u t o m a t i z a r s e la recopilación de datos y su análisis; 2) deben aplicarse té estadísticas válidas para establecer relaciones entre los atributos internos de! ducto y las características de calidad e x t e m a s (por ejemplo, si el grado de corrr rjÜfl dad de la arquitectura se correlaciona con el n ú m e r o de defectos informados aplicarla en producción), y 3) para cada métrica deben establecerse directrices \ c o m e n d a c i o n e s para la interpretación.

15.2.4 Medición del software orientado a objetivos Basili y Weiss [BAS84] desarrollaron el paradigma objetivo/pregunta/métrica il sofaie I OPM se encontraré en www.thedacs. ram/GoldProctices/ proctkes/gqma. html.

c o m o u n a técnica para identificar métricas significativas aplicables en cualqu te del proceso del software. El OPM destaca la necesidad de 1) establecer un i vo de medición explícito que sea específico para la actividad del p r o c e s o o las i terísticas del producto que se está evaluando, 2) definir u n c o n j u n t o de pregu deben responderse con el fin de a l c a n z a r el objeto, y 3) identificar métricas I m u l a d a s que ayuden a responder e s a s preguntas. Es posible emplear una plantilla de definición de objetivos [BAS94] para > da objetivo de medición. La plantilla toma esta forma: A n a l i z a r [el n o m b r e d e la actividad o el atributo q u e s e medirá] c o n el p r o p ó s i t o < objetivo g e n e r a l del análisis 4 ] e n r e l a c i ó n c o n (el a s p e c t o d e la actividad o atribuí: ; s e e n considera] d e s d e e l p u n t o d e v i s t a d e [la g e n t e q u e tiene interés e n la i e n el c o n t e x t o d e [el e n t o r n o en q u e tiene lugar la medición].

C o m o ejemplo, considérese u n a plantilla de definición del objetivo para I Seguro: A n a l i z a r la arquitectura del s o f t w a r e HogarSeguro

c o n e l p r o p ó s i t o d e evaluar I: ; :

p o n e n t e s arquitectónicos e n r e l a c i ó n c o n la c a p a c i d a d p a r a lograr q u e Hogar m á s extensible d e s d e el p u n t o d e v i s t a d e los ingenieros de s o f t w a r e q u e re t r a b a j o e n el c o n t e x t o d e la m e j o r a del p r o d u c t o e n los siguientes tres a ñ o s .

Una vez definido explícitamente el objetivo de la medición, se desarroi:31 junto de preguntas. Las r e s p u e s t a s a é s t a s ayudan al equipo de software otros participantes) a determinar si s e h a a l c a n z a d o el objetivo de med TM las preguntas que se r e s p o n d e n están las siguientes: P,:

¿Los c o m p o n e n t e s arquitectónicos están caracterizados de m a r

PDF Editor a p a r e c e n por s e p a r a d o la función y los d a t o s relacionados?

4

Van Solingen y Berghout [SOL99] sugieren que el objetivo es casi siempre "comprender a

mejorar" la actividad del proceso o el atributo del producto.

CAPÍTULO 15

P/.

471

M É T R I C A S D A P R O D U C T O P A R A EL S O F T W A R E

¿La complejidad de c a d a c o m p o n e n t e se e n c u e n t r a dentro de los límites que facilitarán su modificación y extensión?

Cada una de e s t a s p r e g u n t a s d e b e r e s p o n d e r s e de m a n e r a cuantitativa, e m p l e a n do una o m á s m e d i d a s y métricas. Por ejemplo, una métrica que proporciona una indicación de la cohesión (capítulo 9) de un c o m p o n e n t e arquitectónico sería útil para responder P,. La complejidad ciclomática y las métricas a n a l i z a d a s en la sección 15.4.1 o 15.4.2 proporcionarían conocimientos a fondo para P 2 . En realidad, tal vez haya diversos objetivos de medición con p r e g u n t a s y métricas relacionadas. En cualquier caso, las métricas elegidas (o derivadas) deben cumplir con los principios de medición a n a l i z a d o s en la sección 15.2.3 y los atributos de m e dición analizados en la sección 15.2.5. Si se d e s e a obtener mayor información sobre OPM, el lector interesado d e b e consultar [SHE98] o [SOL99].

15.2.5 Los atributos de las métricas efectivas del software Se han propuesto cientos d e métricas para el s o f t w a r e de computadora, p e r o no todas proporcionan soporte práctico para el ingeniero de software. Algunas exigen mediciones d e m a s i a d o complejas; otras son tan esotéricas q u e p o c o s profesionales podrían comprenderlas, y o t r a s m á s violan las nociones intuitivas básicas d e lo que e s el software de alta calidad. Ejiogu [EJ191] define un conjunto de atributos que toda métrica efectiva del softw a r e d e b e abarcar. La métrica derivada y las medidas que llevan a ella deben ser: • Simples y calculables. Debe ser relativamente fácil aprender a derivar la métrica, y su cálculo no debe exigir cantidades anormales de tiempo o esfuerzo. ¿Cómo • debemos riMr la calidad é i mn métrica «r*p«esta del software?

• Empírica e intuitivamente

persuasivas.

La métrica d e b e satisfacer las n o c i o n e s

intuitivas del ingeniero acerca del atributo del producto que se está construyendo. • Consistentes y objetivas. La métrica siempre d e b e arrojar resultados que no permitan ambigüedad alguna. • Consistentes en el uso de unidades y dimensiones.

El cálculo matemático de la

métrica d e b e emplear medidas que no lleven a c o m b i n a c i o n e s e x t r a ñ a s de unidades. ^CONSEJÓ^ j experiencia indico ue sólo se usoiá uno ' « f f i c o del producto si * intuitiva y fácil atufar. Si deben Kcerse docenas de 'cuentas", es improbax que la métrico se xopte ampliamente.

• Independientes

del lenguaje de programación. Las métricas deben b a s a r s e en el TM modelo de análisis o diseño, o e n la estructura del propio programa.

• Mecanismos

efectivos para la retroalimentación

de alta calidad. Es decir, la m é -

trica d e b e llevar a un producto final de la m á s alta calidad.

PDF Editor

Aunque casi todas las métricas de software satisfacen estos atributos, algunas m é -

tricas de uso común n o cumplen con u n a o dos de ellas. Un ejemplo e s el p u n t o de función (el cual se estudia e n la sección 15.3.1), que e s u n a medida de la entrega de "funcionalidad" por parte del software. Se puede a r g u m e n t a r ' que el atributo consis-

472

PARTE DOS


tente y objetiva falla porque tal vez un tercero, que sea independiente, n o logre den. ir el mismo valor del punto de función que un colega que utilice la misma informador i acerca del software. ¿Debemos rechazar entonces la medida de punto de funciónrespuesta es ¡por supuesto que no! El punto de función proporciona conocimier útiles y, por tanto, valores distintos, aunque no satisfaga algún atributo a la perfecc -

15.2.6 Panorama de las métricas del producto Aunque se ha propuesto una amplia variedad de taxonomías métricas, el sígu í ~ B esquema atiende las áreas más importantes de las métricas: Métricas para el m o d e l o de análisis. Estas métricas atienden varios aspectos oH modelo de análisis e incluyen: Funcionalidad entregada: proporciona una medida indirecta de la función que se empaqueta con el software. Tamaño del sistema: mide el t a m a ñ o general del sistema, definido desde el de vista de la información disponible como parte del modelo de análisis. Calidad de la especificación: proporciona una indicación de la especificidac grado en que se ha completado la especificación de los requisitos. Métricas para el m o d e l o d e diseño. Estas métricas cuantifican los atribu: diseño de manera tal que le permiten al ingeniero de software evaluar la cal diseño. La métrica incluye: Métricas arquitectónicas: proporcionan un indicio de la calidad del diseño a tónico. Métricas al nivel de componente:

miden la complejidad de los componer.-^ j

software y otras características que impactan la calidad. Métiicas de diseño de la interfaz-. se concentran principalmente en la facilidad de Métricas especializadas en diseño orientado a objetos: miden características ses, a d e m á s de las correspondientes a comunicación y colaboración. Métricas para el c ó d i g o fuente. Estas métricas miden el código fuente y se para evaluar su complejidad, a d e m á s de la facilidad con que se mantiene y entre otras características:

TM p Métricas de Halstead: controversiales pero fascinantes, estas métricas nan medidas únicas de un programa de cómputo. Métricas de complejidad: miden la complejidad lógica del código fuente se consideran métricas de diseño al nivel de componentes).

PDF Editor

Métricas de longitud: proporcionan un indicio del t a m a ñ o del software.

5

Podría usarse un contraargumento igualmente vigoroso. Ésa es la naturaleza de las

software.

CAPÍTULO 15

M É T R I C A S DEL P R O D U C T O P A R A A S O F T W A R E

473

Métricas para p r u e b a s . Estas métricas ayudan a diseñar casos de prueba efectivos y a evaluar la eficacia de las pruebas: Métricas de cobertura de instrucciones y ramas: lleva al diseño de c a s o s de prueba que proporcionan cobertura del programa. Métricas relacionadas con los defectos: se concentran en encontrar defectos y no en las propias pruebas. Efectividad de la prueba: proporcionan un indicio en tiempo real de la efectividad de las pruebas aplicadas. Métricas en el proceso: métricas relacionadas con el proceso q u e se determinan a medida que se aplican las pruebas. En muchos casos las métricas de un modelo pueden aplicarse en actividades posteriores de la ingeniería del software. Por ejemplo, las métricas de diseño se utilizan para estimar el esfuerzo requerido para generar código fuente. Además, las métricas de diseño se aprovechan para planear pruebas y el diseño de casos de prueba.

HOGARSEGURO

Debate sobre métricas del producto El e s c e n a r i o : Cubículo de Vinod. a c t o r e s : Vinod, Jamie y Ed, integrantes del equipo ngeniería del software de H o g a r S e g u r o , que siguen trabajando con el diseño al nivel dé componentes y de La c o n v e r s a c i ó n : V i n o d : Doug [Doug Miller, jefe de ingeniería del ¡cítware] me dijo que todos deberíamos usar métricas del r'oducto, pero lo hizo de manera vaga. También dijo ; je no presionaría... su uso dependería de nosotros. J a m i e : Eso está bien, porque no tenemos tiempo para empezar a medir cosos. Estamos esforzándonos por cjmplir con el calendario de trabajo. Ed: Estoy d e acuerdo con Jamie. Estamos contra ellas, :quí... no hoy tiempo. V i n o d : Sí, lo sé. pero tal vez por alguna razón sea importante que las usemos. J a m i e : No discuto eso, Vinod. Es cosa de tiempo, - o tengo tanto como para desperdiciarlo

y yo

V i n o d : No, espera... ¿y si nos ahorran tiempo? J a m i e : ¿Cómo? V i n o d : Evitando retrabajar... Si una métrica nos ayuda a evitar un problema importante o incluso uno moderado, y eso nos evita retrabajar una parte del sistema, ahorraremos tiempo, ¿o no? Ed: Es posible, supongo, pero ¿nos garantizas que alguna métrica del producto nos ayudará a encontrar un problema? V i n o d : ¿Y tú me garantizas que no lo hará? J a m i e : Bueno, ¿qué estás proponiendo? V i n o d : Creo que debemos seleccionar unas cuantas métricas de diseño, tal vez orientadas a clases, y aplicarlas como parte de nuestro proceso de revisión para todos los componentes que desarrollemos. TM Ed: No estoy muy familiarizado con las métricas orientadas a objetos.

PDF Editor V i n o d : ¿Y si las mediciones nos ahorraran tiempo?

Ed: Estás equivocado. Requieren tiempo y, como dice jamie,;,

V i n o d : Voy a dedicar un poco de tiempo a revisarlas y a hacer algunas recomendaciones... ¿están de acuerdo? (Ed y Jamie asienten sin mucho entusiasmo.)

474

PARTE DOS

15-3


M É T P I C A S P A R A ET. M O D E L O D E A N Á L I S I S Aunque existen en la bibliografía relativamente p o c a s métricas de análisis y espec ficación, es posible adaptar métricas que se utilizan en la estimación d e p r o y e c t : ; aplicarlas en este contexto. Estas métricas e x a m i n a n el m o d e l o de análisis con la tención de predecir el "tamaño" del sistema resultante. El t a m a ñ o es, e n o c a s (pero n o siempre), un indicador de la complejidad del diseño y casi siempre r~ u n indicador de un mayor esfuerzo de codificación, integración y prueba.

15.3.1 Métricas b a s a d a s en la función La métrica de p u n t o de función (PF), propuesta inicialmente por Albretch [ALB79" m En los siguientes sitios Web se encontraré ¡nforoioción abundcnte y útil acetca lie los puntos de función:

u s a de m a n e r a efectiva c o m o medio para medir la funcionalidad que entrega ur.

www.ffpog. org y www. functionpoints.tom.

nentes, de líneas de código proyectadas, o a m b a s , en el sistema i m p l e m e n t a c : Los puntos de función se derivan e m p l e a n d o u n a relación empírica b a s:aría a;i d

tema. 6 Empleando d a t o s históricos, el PF s e usa para 1) estimar el costo o el •

r|

zo requerido para diseñar, codificar y probar e l software; 2) predecir el n ú mnearo: X-, i] errores que se e n c o n t r a r á n durante la prueba, y 3) pronosticar el n ú m e r o de cc

medidas contables (directas) del dominio de la información del software y las J luaciones de la complejidad de éste. Los valores del dominio de la información se f finen de la siguiente manera: 7 N ú m e r o d e e n t r a d a s e x t e r n a s (EE). Cada entrada extema

se origina

usuario o es transmitida desde otra aplicación y proporciona distintos datos dos a la aplicación o información de control. Las e n t r a d a s suelen emplearse tualizar archivos lógicos internos (AU). Las e n t r a d a s deben distinguirse de ia~ l sultas, que se c u e n t a n por separado. N ú m e r o d e s a l i d a s e x t e r n a s (SE). Cada salida extema se deriva en el de la aplicación y proporciona información al usuario. En este contexto, terna alude a informes, pantallas, m e n s a j e s de error, etc. Los e l e m e n t o s de dividuales d e n t r o de u n informe no se c u e n t a n por separado. N ú m e r o d e c o n s u l t a s e x t e r n a s (CE). Una consulta extema se define : a e n t r a da en línea que lleva a la generación de alguna respuesta inmediata p>:«r j del software, en la forma de salida en linea (a m e n u d o recuperada de u n N ú m e r o d e a r c h i v o s l ó g i c o s i n t e r n o s (ALI). Cada archivo lógico in TM a g r u p a m i e n t o lógico de datos que reside d e n t r o de los límites d e las apli que se m a n t i e n e m e d i a n t e e n t r a d a s externas.

PDF Editor

Desde que Albrecht dio a conocer su trabajo original, se han escrito cientos de libros, tículos sobre PF. En [IEP03] se encontrará una bibliografía muy valiosa.

En realidad, la definición de los valores del dominio de la información y la manera en c j t •

tan son un poco más complejas. El lector interesado deber consultar [IFP01] para c talles.

CAPÍTULO 15

475


Valor del dominio de información Entradas externas (EE) Salidas externas (SE) Consultas externas (CE) Archivos de lógica interna (ALI) Archivos de interfaz externa (AIE)

Factor d e p o n d e r a c i ó n Conteo

Simple

Promedio

a a a a a

Complejo

4

6

5

7

4

6

10

15

7

10

Total de conteos

Número d e archivos de interfaz e x t e r n o s (AIE). Cada archivo de interfaz externo e s un agrupamiento lógico de datos externo a la aplicación pero que proporciona datos que podrían usarse en ésta. p Una vez que se han recolectado los datos, se completa la tabla de la figura 15.2 y se asocia un valor de complejidad con cada conteo. Las organizaciones que usan métodos de punto de función desarrollan criterios para determinar si una entrada determinada es simple, promedio o compleja. No obstante, la determinación de la complejidad e s un poco subjetiva. Para calcular los puntos de función (PF) se usa la siguiente relación: PF = conteo total x [0.65 + 0.01 x I (F¡)]

(15.1)

donde conteo total e s la suma de todas las entradas de PF obtenidas de la figura 15.2. F¡ (j = l a 14) son factores de ajuste de valor basados en las respuestas a las siguientes preguntas [LON02J: 1. ¿El sistema requiere respaldo y recuperación confiables? 2.

¿Se requieren comunicaciones de datos especializadas para transferir información a la aplicación, u obtenerla de ella?

3 . ¿Hay funciones distribuidas de procesamiento? 4 . ¿El desempeño es crítico? 5 . ¿El sistema se ejecutará en un entorno existente que tiene un uso pesado de operaciones? 6. ¿El sistema requiere entrada de datos en linea?

TM

7. ¿La entrada de datos en línea requiere que la transacción de entrada s e construya en varias pantallas u operaciones?

PDF Editor 8. ¿Los ALI se actualizan en línea?

9 . ¿Las entradas, las salidas, los archivos o las consultas son complejos?

10. ¿Es complejo el procesamiento interno? 11. ¿El código diseñado será reutilizable?

476

PARTE DOS


1 2 . ¿Se incluyen la conversión e instalación e n el diseño? 13.

¿Está d i s e ñ a d o el sistema para instalaciones múltiples en diferentes o r g a m o - ] ciones?

1 4 . ¿La aplicación está diseñada para facilitar el cambio y para que el usuario 1: j use fácilmente? Cada una de e s t a s preguntas se responde e m p l e a n d o u n a escala que va de 0 (no portante o aplicable) a 5 (absolutamente esencial). Los valores constantes de ¿ I ecuación (15.1) y los factores de peso que se aplican a los conteos del dominio de la r - l formación se determinan empíricamente. Para ilustrar el empleo de la métrica del PF en este contexto se ideó la r e p r e s e n ^ I Uno en kb.cs. iminragdeburg. de/sw-eng/ us/jova/fp/.

ción simple del modelo de análisis, que se muestra en la figura 15.3. Ahí se r e p r e s * * ! ta u n diagrama de flujo de datos (capítulo 8) dentro del software HogarSeguro. La r j * l ción maneja la interacción con el usuario aceptando u n a contraseña de éste para a:-l tivar o desactivar el sistema, y permite consultas sobre el estado de las z o n a s de se-l guridad y varios sensores de seguridad. La función despliega una serie de mensa es r| envía señales de control apropiadas a varios c o m p o n e n t e s del sistema de segur,cao.1 Se evalúa el diagrama de flujo de d a t o s para determinar un c o n j u n t o de m e d i c a l clave del dominio de información que se requieren para calcular la métrica del p - ^ - l to de función. En la figura se m u e s t r a n tres e n t r a d a s externas ( c o n t r a s e ñ a , b o t a n ; d e p á n i c o y a c t i v a r / d e s a c t i v a r ) junto c o n dos consultas externas (consulta je; z o n a y c o n s u l t a d e s e n s o r ) . Se muestra un ALI (archivo d e c o n f i g u r a c i ó n Asi s i s t e m a ) . También están presentes dos salidas de usuarios ( m e n s a j e s y e s t a o s del s e n s o r ) y cuatro AIE ( s e n s o r d e p r u e b a , c o n f i g u r a c i ó n d e z o n a , activar/-! d e s a c t i v a r y a l e r t a d e alarma). En la figura 15.4 se m u e s t r a n e s t o s datos, ' - ~ J con la complejidad apropiada. El c o n t e o total que se muestra en la figura 15.4 d e b e ajustarse e m p l e a n d o la e c J ción (15.1): PF = c o n t e o total x [0.65 + 0 . 0 1 x £ (F,)]

Modelo de flujo de datos para el software HogarSeguro.

Sensor d e prueba

Sensofes

Contraseña Configuración TM d e zona ' ^ Mensajes Consulto d e sensor /interacción de'\ usuario en Usuario Botón de pánico JÊslatus del sensor Activar/desactivar Activar/desactivar Consulto d e zona Usuario

/

Funclon e

PDF Editor Contraseña, sensores...

Alerta d e alarma

_Doto^lônfiguracióndehsistem^

Subsistema t monitoreo y respuesta

CAPÍTULO 15

477


Valor del dominio de información Entrados externas (EE) Salidas externas (SE) Consultas externas (CE) Archivos de lógica interna (ALI) Archivos de interfaz externa (AIE)

Factor de ponderación Simple Promedio Complejo

Conteo

a a a a a

i i i i i

X

<3)

4

6

= U J

X

(4)

5

7

=

X

(3>

4

6

= [_4J

X

O

10

15

= 1: .7 1

7

10

= [_20J

X

Total de conteos

1

50 1

d o n d e c o n t e o total es la s u m a de t o d a s las e n t r a d a s de PF obtenidas de la figura 15.4, y F¡ (;' = 1 a 14) son factores de ajuste de valor. Para los objetivos de e s t e ejemplo, sup ó n g a s e que I (F¡) e s 46 (un producto m o d e r a d a m e n t e complejo). Por tanto: PF = 50 x [0.65 + (0.01 x 46)1 = 56 Con b a s e en el valor proyectado del PF derivado del modelo de análisis, el equipo del proyecto p u e d e estimar el t a m a ñ o i m p l e m e n t a d o general de la función de interacción del usuario de HogarSeguro.

Supóngase que los d a t o s del p a s a d o indican

que un PF se traduce a 60 líneas d e código (se va a usar un lenguaje orientado a objetos) y q u e se producen 12 PF por cada p e r s o n a - m e s de esfuerzo. Estos d a t o s históricos proporcionan al jefe del proyecto información importante que sirve para la planeación y q u e se b a s a en el m o d e l o de análisis m á s que en estimados preliminares. Supóngase, a d e m á s , que los proyectos anteriores h a n e n c o n t r a d o un promedio de tres errores por punto de función durante las revisiones del análisis y el diseño, y de cuatro errores por p u n t o de función d u r a n t e las pruebas de unidad e integración. Estos d a t o s ayudarán a los ingenieros de s o f t w a r e a evaluar el grado en el que han completado sus actividades de revisión y prueba. Uemura y sus colegas [UEM99] sugieren que los p u n t o s de función también pueden calcularse a partir d e d i a g r a m a s UML de clase y secuencia (capítulos 8 y 10). El lector interesado d e b e consultar [UEM99] para conocer m á s detalles.

"En lugar de sólo musitar nterta de cuál 'nuevo métrico' podrio aplicarse... de lemos plantearnos la pregunta básica: TM '¿qué he remos con las métricos?"' Michaei Mah y larry Putnam

PDF Editor 15.3.2 Métricas p a r a la calidad de la especificación

Davis y s u s colegas [DAV93] proponen u n a lista de características con las cuales

p u e d e evaluarse la calidad del modelo de análisis y la correspondiente especificación

478

PARTE DOS


de requisitos: especificidad (falta de ambigüedad), grado de avance, corrección, faah dad de comprensión,

facilidad de verificación, consistencia

interna y externa, facilkktú

para alcanzar los objetivos, concisión, facilidad para darle seguimiento, facilidad per: modificarse, precisión y facilidad de reutilización. Además, los a u t o r e s [DAV93] obsevan que las especificaciones de alta calidad deben estar a l m a c e n a d a s electrónica mente, ser ejecutables o por lo m e n o s interpretables, estar a n o t a d a s por i m p o r t a n c i relativa, ser estables, tener indicada la versión, estar organizadas, incluir r e f e r e n c i a

\

c r u z a d a s y especificarse con el grado de detalle correcto.

Al medir las características de la especificación es posible obtener un conocimiento cuantitativo de la especificidad y el grado de avance.

cación, de m o d o que

CLAVE

Aunque, al parecer, m u c h a s de e s t a s características tienen u n a naturaleza CL tativa, Davis et al. [DAV93] sugieren que cada una p u e d e representarse emplea u n a o m á s métricas. Por ejemplo, s u p ó n g a s e que hay n r requisitos e n u n a es

n r = r i f + Rnf d o n d e nf e s el n ú m e r o de requisitos funcionales y nnf el de n o funcionales (con-: e desempeño). Para determinar la especificidad (falta de ambigüedad) de los requisitos, Dar.í & al. sugieren u n a métrica b a s a d a e n la consistencia de la interpretación de los rev. res de cada requisito: Qi = nu/nr d o n d e nw e s el n ú m e r o de requisitos que todos los revisores interpretaron de la m a m a n e r a . Cuanto m á s c e r c a n o esté el valor de Q a 1, m e n o r será la ambi de la especificación. El grado de avance de los requisitos funcionales se determina al calcular la -2 ción Q2 = n¡/[n, x ns] donde nu es el número de requisitos de función única; n„ el número de entradas (e los) definidos o implícitos en la especificación, y ns, el número de estados e s p e c i f i c a d ® La relación Q2 mide el porcentaje de funciones necesarias que se han especificac: f f l ra un sistema. Sin embargo, no se atienden requisitos que no son funcionales. P ¿ n l l corporarlos a u n a métrica general del grado de avance, se debe considerar el g r a a r . ^ validación de los requisitos: Qj = nc/[nc

+n j

TM d o n d e n: es el n ú m e r o de requisitos que se han validado c o m o correctos, y r requisitos que a ú n no se validan.

PDF Editor "Mido lo que seo mensurable, y lo que no lo sea, vuélvalo mensurable."

CAPÍTULO 15

M É T R I C A S DEL P R O D U C T O P A R A A S O F T W A R E

15.4

479

EL M Q D E L Q P E P I S E Ñ Q Sería inconcebible que el diseño de un n u e v o avión, un n u e v o chip de c o m p u t a d o r a o u n n u e v o edificio de oficinas se realizara sin definir las medidas del diseño, sin determinar las métricas de diversos aspectos de la calidad del diseño y sin usarlas para guiar la m a n e r a en que evoluciona el diseño. Sin embargo, a m e n u d o el diseño de s i s t e m a s de s o f t w a r e complejos suele a v a n z a r casi sin medición. La ironía es que se dispone de métricas de diseño para el software, pero la gran mayoría de los desarrolladores siguen ignorando su existencia. Las métricas de d i s e ñ o para el s o f t w a r e de computadora, c o m o todas las d e m á s métricas del software, no son perfectas. Sigue abierto el d e b a t e sobre su eficacia y la m a n e r a en que deben aplicarse. Muchos expertos a r g u m e n t a n que se necesita m á s experimentación a n t e s de emplear las mediciones e n el diseño. Sin embargo, un diseño sin medición es inaceptable.

15.4.1 Métricas del diseño arquitectónico Las métricas d e diseño arquitectónico se c o n c e n t r a n en las características d e la arquitectura del p r o g r a m a (capítulo 10), y se d e s t a c a n la estructura arquitectónica y la efectividad de m ó d u l o s o c o m p o n e n t e s dentro de la arquitectura. Estas métricas son de "caja negra", en el sentido de que n o requieren ningún conocimiento del funcion a m i e n t o interno de un c o m p o n e n t e de s o f t w a r e en particular. Card y Glass |CAR90] definen tres medidas de la complejidad del diseño del software: estructural, de datos y del sistema. En el c a s o de las arquitecturas jerárquicas (por ejemplo, las arquitecturas de llam a d a y retorno), la complejidad

estructural de un módulo i se define de la siguiente

manera-. (15.2)

S(i) = / 2 „ u t ( í ) donde/ o u t (/) es la dependencia hacia fuera 8 del m ó d u l o i.

La complejidad de datos proporciona una indicación de la complejidad de la inter-

CÚVVE icos pueden r discernimiento ¡los datos es y la Idel i asociados con lástño nico.

faze interna de un m ó d u l o i y se define como: £>(/) = v(í)/[/oUt(/) + 1]

(15.3)

d o n d e v(/') es el n ú m e r o de variables de e n tr a da y salida que se pasan al módulo i o se reciben de éste. Por último, complejidad

TM del sistema se define c o m o la s u m a de las complejidades

estructural y de datos, especificada como:

PDF Editor C(J) = S(i) 4 D[i)

8

(15.4)

Dependencia hacia Juera se define como el número de módulos inmediatamente subordinados al

módulo i; es decir, el número de módulos invocados directamente por i. Lo contrario, dependencia hacia dentro, seria una variable f,„ que indique el número de módulos que invocan directamente al módulo i.

480

PARTE DOS

P R Á C T I C A DE L A INGENIERÍA D A S O F T W A R E

A medida que aumentan estos valores, la complejidad arquitectónica general del s s j 1 tema también lo hace. Esto lleva a una mayor probabilidad de que a u m e n t e n los fuerzos de integración y prueba. Fenton [FEN91] sugiere varias métricas simples de morfología (es decir, de forr-¿. I que permiten la comparación entre diferentes arquitecturas de programas e m p l e a do un conjunto de dimensiones directas. Si se toma c o m o referencia la a r q u i t e c t o I de llamada y retorno de la figura 15.5, se definirán las siguientes métricas: tamaño = n + a donde n es el número d e nodos y a, el de arcos. En el caso de la arquitectura rr Tetrada en la figura 15.5, tamaño = 17 + 18 = 35 profundidad = 4, el camino m á s largo desde el nodo raíz (superior) a un n e o : hoja. anchura = 6, número máximo de n o d o s en cualquier nivel de la arquitectura relación arco-a-nodo, r = a/n, que mide la densidad de las conexiones y proporciona una simple indicación ót acoplamiento de la arquitectura. En el caso de la arquitectura mostrada en la figura 15.5, r = 18/17 = 1.06. El Comando de Sistemas de la Fuerza Aérea de Estados Unidos [USA87] ha desarrollado varios indicadores de la calidad del software que se basan en las características de diseño que pueden medirse en un programa de computadora. Empleanc: conceptos similares a los propuestos en el IEEE Std. 982.1-1988 [IEE94], la Fuerza Aérea estadounidense emplea información obtenida del diseño de datos y arquitectónico para derivar un índice de calidad de la estructura de diseño (ICED) que va tíe 0 a 1. El cálculo del ICED requiere determinar los siguientes valores [CHA891. S, = el número total de módulos definidos en la arquitectura del programa

M/vJo

Métricas d e morfología.

TM Profundidad

PDF Editor 1h 1

1m 11n miq 11 r 1 Ancho

CAPÍTULO 15

481

M É T R I C A S DHL P R O D U C T O P A R A EL S O F T W A R E

5 2 = el n ú m e r o de m ó d u l o s cuya (unción correcta d e p e n d e de la f u e n t e de e n trada de d a t o s o que p r o d u c e d a t o s que se usarán en otro lugar (en g e n e ral, ios módulos de control, e n t r e otros, no se contarían c o m o parte de S 2 ) 5 3 = el n ú m e r o de módulos cuya función correcta d e p e n d e del p r o c e s a m i e n t o anterior 5 4 = el n ú m e r o de e l e m e n t o s de b a s e de d a t o s (incluye objetos de datos y todos los atributos que definen objetos) 5 5 = el n ú m e r o total de e l e m e n t o s únicos de b a s e de d a t o s 5 6 = el n ú m e r o de s e g m e n t o s de b a s e de d a t o s (registros diferentes u objetos individuales) 5 7 = el n ú m e r o de m ó d u l o s con una sola e n tr a da y salida (con excepción del procesamiento, n o s e considera u n a salida múltiple) Una vez que se han determinado los valores del S, al S 7 para un programa de c o m p u tadora, es posible calcular los siguientes valores intermedios: Estructura del programa: Du d o n d e D¡ se define c o m o sigue: si el diseño arquitectónico s e desarrolló e m p l e a n d o un m é t o d o distinto (por ejemplo, d i s e ñ o orientado al flujo de d a t o s u objetos), e n t o n c e s D, = 1; de lo contrario, D, = 0. Independencia

del módulo. D2 = 1 - (S 2 /S,)

Módulos no dependientes

del procesamiento

anterior: D 3 = 1 - (S 3 /S,)

Tamaño de la base de datos: D4 = 1 - (S 5 /S 4 ) División en compartimientos

de la base de datos: D s = 1 - (S 6 /S 4 )

Característica de entrada/salida

del módulo: D6 = 1 - (S 7 /S,)

Una vez d e t e r m i n a d o s los valores intermedios, se calcula el ICED de la siguiente m a nera: ICED=2iV(D¡

(15.5)

d o n d e i = 1 a 6, w¡ e s el p e s o relativo de la importancia de c a d a u n o de los valores intermedios, y Y w¡ = 1 (si todo D, tiene p e s o s iguales, e n t o n c e s w, = 0.167). Se determina el valor de ICED para los diseños anteriores y se c o m p a r a con un dis e ñ o que está e n desarrollo. Si el ICED e s significativamente m e n o r q u e el promedio, lo indicado es realizar trabajo de diseño y revisión adicionales. De igual m a n e r a , si se van a realizar c a m b i o s importantes en un diseño existente, podrá calcularse el efecto de e s o s c a m b i o s s o b r e el ICED.

TM

"Es posible considerar que la medición es un desvío. Un desvio necesario, porque la mayoría de los seres humanos no son capaces de tomor decisiones claras y objetivos (sin apoyo cuantitativo)." Horst Zuse

PDF Editor 15.4.2 Métricas p a r a el diseño orientado a objetos

Gran parte del d i s e ñ o orientado a objetos e s subjetivo (un diseñador experimentado "sabe" c ó m o caracterizar un s i s t e m a orientado a objetos para que implemente efec-

482

PARTE DOS


tivamente los requisitos del cliente). Pero, a medida q u e a u m e n t a el t a m a ñ o \ complejidad del m o d e l o de diseño orientado a objetos, un concepto m á s objetivo a » las características del diseño beneficiaría al diseñador e x p e r i m e n t a d o (que o b t e n d r á conocimientos adicionales) y al principiante (que obtendría una indicación de la calidad que de otra m a n e r a no estaría disponible). En u n tratamiento detallado de las métricas del software para sistemas orierta • dos a objetos, Whitmire |WHI97] describe nueve características distintivas y mensurables de un diseño orientado a objetos: ¿Cuáles • características pueden medirse cuando se evalúa un diseño orientado a objetos?

T a m a ñ o . El t a m a ñ o se define a partir de cuatro conceptos: población, volurr.elongitud y funcionalidad. Población se mide al t o m a r u n c o n t e o estático de entidad— orientada a objetos c o m o clases u operaciones. Las m e d i d a s de volumen son idér : cas a las de la población, p e r o se recopilan d i n á m i c a m e n t e (en un m o m e n t o deteminado). La longitud es u n a medida de u n a c a d e n a de e l e m e n t o s de diseño Ínter; n e c t a d o s (por ejemplo, la profundidad de un árbol de herencia e s u n a medida de lor-i gitud). Las métricas de funcionalidad

proporcionan u n a indicación indirecta del va. : r

entregado al cliente e n u n a aplicación orientada a objetos. C o m p l e j i d a d . Como el t a m a ñ o , hay m u c h o s conceptos diferentes de la comp ; jidad del s o f t w a r e [ZUS97]. Whitmire considera la complejidad d e s d e el punto de v

;

ta de las características estructurales, al e x a m in a r la m a n e r a e n que se interrelac n a n las clases de un diseño orientado a objetos. A c o p l a m i e n t o . Las conexiones físicas entre los e l e m e n t o s de un diseño orienu do a objetos (por ejemplo, el n ú m e r o de colaboraciones entre clases o el de mensa jes p a s a d o s entre objetos) representan el acoplamiento dentro de un sistema oriert a d o a objetos. S u f i c i e n c i a . Whitmire define suficiencia c o m o "el grado e n que u n a abstracc;: posee las características que se le piden, o el g r a d o e n que u n c o m p o n e n t e de díst ño p o s e e características en s u abstracción, d e s d e el p u n t o de vista de la aplicad:*' actual". Expresado de otra m a n e r a , se pregunta: ¿Cuáles propiedades d e b e tener esta abstracción (clase) p a r a que sea útil? [WH197]. En esencia, un c o m p o n e n t e de c s e ñ o (por ejemplo, u n a clase) es suficiente si refleja p l e n a m e n t e t o d a s las propiec; d e s del objeto de dominio de la aplicación que se está m o d e l a n d o (es decir, que : abstracción, o clase, p o s e e las características que d e b e tener).

TMahora empleando "Muchas de las decisiones para las que tenia que depender del foldore o los mitos puedo tomarlas datos cuantitativos." Stott Whitmire

PDF Editor

G r a d o d e a v a n c e . La única diferencia entre el grado de a v a n c e y la suficienca

e s "el c o n j u n t o de características contra las que c o m p a r a m o s el c o m p o n e n t e de abs tracción o diseño" [WHI97]. La suficiencia c o m p a r a la abstracción d e s d e el punto c : vista de la aplicación actual. El grado de a v a n c e considera varios p u n t o s de vist:

CAPÍTULO 15


483

planteando la pregunta: ¿Cuáles propiedades se requieren para representar plenamente el objeto del dominio del problema? Debido a que los criterios para el grado de avance consideran diferentes puntos de vista, indican indirectamente el grado en que puede reutil izarse el componente de abstracción o diseño. C o h e s i ó n . Como su contraparte en el software convencional, un componente orientado a objetos debe diseñarse de manera que todas las operaciones trabajen en combinación para alcanzar un solo propósito, bien definido. El grado de cohesión de una clase se determina al examinar el grado en que "el conjunto de propiedades que posee e s parte del dominio del problema o el diseño" [WHI97]. Primitivismo. Una característica similar a la simplicidad, el grado de primitivismo (aplicado a operaciones y clases) e s el grado en que una operación es atómica (es decir, la operación n o puede construirse a partir de una secuencia de otras operaciones contenidas dentro de una clase). Una clase que muestra un alto grado de primitivismo sólo encapsula operaciones primitivas. Similitud. Esta medida indica el grado en que dos o más clases son similares en cuanto a su estructura, función, comportamiento o propósito. Volatilidad. Como ya se ha visto en este libro, los cambios de diseño ocurren cuando los requisitos se modifican o cuando las modificaciones se presentan en otra parte de una aplicación, lo que produce una adaptación obligatoria del componente del diseño en cuestión. La volatilidad de un componente de diseño orientado a objetos mide la probabilidad de que ocurra un cambio. En realidad, las métricas del producto para sistemas orientados a objetos no sólo se aplican al modelo de diseño, sino también al de análisis. En las secciones que siguen se explorarán las métricas que proporcionan una indicación d e la calidad al nivel de clase orientada a objetos y al nivel de operación.

15.4.3 Métricas orientadas a clases: la colección de métricas de CK La clase es la unidad fundamental de un sistema orientado a objetos. Por tanto, las medidas y métricas de una clase individual, la jerarquía de clase y las colaboraciones de clase serán invaluables para un ingeniero de software que debe valorar la calidad del diseño. En capítulos anteriores se vio que la clase encapsula operaciones (procesamiento) y atributos (datos). La clase suele ser el "predecesor" de las subclases (a veces denominadas descendientes) que heredan s u s atributos y operaciones. Con frecuencia, la clase colabora con otras clases. Cada una de estas características TM se utiliza como base de la medición. 9 Chidamber y Kemerer [CHI94] propusieron uno de los conjuntos de métricas de software orientado a objetos al que se hace referencia con mayor frecuencia. A me-

PDF Editor 9

Debe observarse que aún se debate en la bibliografía técnica la validez de algunas de las métricas

analizadas en este capitulo. Quienes defienden la teoria de la medición, exigen un grado de formalismo que algunas métricas orientadas a objetos no proporcionan Sin embargo, e s razonable deter minar que las métricas indicadas proporcionan conocimientos útiles para el ingeniero de software.

484

PARTE DOS


n u d o d e n o m i n a d a s colección de métricas de CK, los a u t o r e s p r o p o n e n seis m é t r i c a de diseño b a s a d o e n clases para s i s t e m a s orientados a objetos. 1 0

CLAVE El número de métodos y su complejidad están directo mente correlacionados con el esfuerzo requerido pora probor una clase.

M é t o d o s p o n d e r a d o s p o r c l a s e (MPC).

Suponga que n m é t o d o s de complejidi:

c¡, c¿...,c„ están definidos por la clase C. La métrica de complejidad específica q j t se elija (por ejemplo, la complejidad ciclomática) debe normalizarse con el fin de que ^ complejidad nominal de u n m é t o d o t o m e un valor de 1.0. MPC = I p a r a i = 1 a n. El n ú m e r o de m é t o d o s y su complejidad son indicadores razonabi-de la cantidad de e s f u e r z o requerido para implementar y probar u n a clase. Ademarc u a n t o mayor sea el n ú m e r o de métodos, m á s complejo será el árbol de h e r e n c a (todas las subclases h e r e d a n los m é t o d o s de sus predecesores). Por último, confir-

ÔNSUO^ Lo herencia es uno característica extremadamente poderoso que puede cousar problemas si se empleo sin cuidado. Úsese el APH y otros métricas pora obtener una lectura de lo complejidad de las jerarquías de cióse.

m e crece el n ú m e r o de m é t o d o s de u n a clase determinada, es probable que se v u ; va m á s y m á s específica de la aplicación, lo que limita sus posibilidades de reutiliz»ción. Por t o d a s las r a z o n e s m e n c i o n a d a s , MPC d e b e m a n t e n e r s e lo m á s b a j o que s r i posible. Aunque p a r e z c a relativamente simple desarrollar u n c o n t e o del n ú m e r o de m e a d o s en la clase, e n realidad el p r o b l e m a es m á s complejo de lo que parece. Debe o t sarrollarse un e n f o q u e de c o n t e o consistente p a r a los m é t o d o s [CHU95]. Árbol d e p r o f u n d i d a d d e la h e r e n c i a (APH).

Esta métrica e s "la longitud ma--:

m a desde el n o d o hasta la raíz del árbol" [CHI94], Si toma c o m o referencia la figuré 15.6, el valor de APH para la jerarquía de clase m o s t r a d a es 4. A medida que cre:¿ la APH, es probable que las clases de nivel inferior h e r e d a r á n m u c h o s m é t o d o s Es-

Jerarquía de una clase.

TM

PDF Editor

10 Chidamber y Kemerer usan el término métodos en lugar de operaciones. La forma en que emplear término se refleja en esta sección.

CAPÍTULO 15

485


to se presta a posibles dificultades cuando se trata de predecir el comportamiento de una clase. Una jerarquía de clase profunda (su APH es mayor) también se presta a una mayor complejidad de diseño. Por el lado positivo, valores grandes de APH indican que s e podrían reutilizar muchos métodos. Número d e d e s c e n d i e n t e s (NDD).

Un descendiente es una subclase que se e n -

cuentra inmediatamente subordinada a otra en la jerarquía de clases. Si se toma como referencia la figura 15.6, la clase C 2 tiene tres descendientes (las subclases C 2 | , C22 y C 23 ). A medida que crece el número de descendientes, se incrementa la reutilización, pero podría diluirse la abstracción que representa la clase predecesora si alguno de los descendientes n o e s un miembro apropiado d e la clase predecesora. A medida que aumenta el NDD, también lo hace la cantidad de pruebas (requeridas para ejercitar cada descendiente en su contexto operacional). A c o p l a m i e n t o entre c l a s e s d e o b j e t o s (AECO).

El modelo de conjunto de res-

puesta de una clase (CRC), expuesto en el capítulo 8, se emplea para determinar el valor de AECO. En esencia, AECO es el número de colaboraciones enlistadas, para una clase, en su tarjeta de índice CRC." A medida que AECO aumenta, e s probable que disminuya la facilidad de reutilización de una clase. Valores elevados d e AECO también complican las modificaciones y la prueba que asegura que esas modificaciones s e han hecho. En general, para cada clase deben mantenerse los valores de AECO en el valor más bajo que sea razonable. Esto e s consistente con la directriz general para reducir el acoplamiento en el software convencional.

[CONSEJO,

iceptos de uto y i se aplican al i convencional i orientado o is. Manténgase ¡ el acoplamiento 7fecohesión de s y operaciones.

R e s p u e s t a para una c l a s e (RPC). El conjunto de respuesta para una clase es un "conjunto de métodos que tiene la posibilidad de ejecutarse como respuesta a un mensaje que recibe un objeto de esa clase" [CH194]. La RPC e s el número de métodos en el conjunto de respuesta. A medida que la RPC aumenta, el esfuerzo requerido para probar también lo hace, debido a que crece la secuencia de prueba (capítulo 14). También se desprende que, a medida que la RPC aumenta, se incrementa la complejidad del diseño general de la clase. Falta d e c o h e s i ó n e n m é t o d o s (FCM). Cada método dentro de una ciase, C, tien e acceso a uno o más atributos (también denominados variables de instancia). La FCM es el n ú m e r o de métodos que acceden a uno o más d e los mismos atributos. 12 Si ningún método accede a los mismos atributos, entonces FCM = 0. Para ilustrar el caso donde FCM * 0, imagínese una clase de seis métodos. Cuatro de ellos tienen TM uno o m á s atributos en común (es decir, acceden a atributos comunes). Por tanto, FCM = 4. Si la FCM es alta, los métodos pueden acoplarse entre sí mediante atribu-

PDF Editor

tos. Esto aumenta la complejidad del diseño de clase. Aunque hay casos en que re-

11 Si las tarjetas de Índice CRC se desarrollan manualmente, el grado de avance y la consistencia deben evaluarse antes de determinar el AECO de manera confiable

12 La definición formal e s un poco m á s compleja. Consúltese [CHI94] para conocer m á s detalles.

PARTE DOS


sulta justificable un valor elevado para la FCM. Lo deseable es mantener alta la cohesión; e s decir, conservar baja la FCM.13

Aplicación de métricas de CK El e s c e n a r i o : Cubículo de Vinod. Los a c t o r e s : Vinod, Shakira y Ed, integrantes del equipo del software H o g a r S e g u r o , que siguen trabajando en el diseño al nivel de componentes y de casos de prueba. -SI 'i ^ t a conversación: V i n o d : ¿Tuvieron oportunidad de leer la descripción de lo colección de métricas d e CK que les envié el miércoles y de hacer esas mediciones? Shakira: No fue muy complicado. Regresé a mis diagramas de clase y de secuencia UML, como sugeriste, y obtuve conteos elementales d e APH, FPC y FCM. No pude encontrar el modelo CRC, de modo que no conté AECO. j a m i e ( s o n r i e n d o ) : No pudiste encontrar el modelo CRC porque yo lo tenía. S h a k i r a : Eso es lo que me encanta de este equipo, la gran comunicación. V i n o d : Yo hice mis conteos.,, ¿desarrollaron cifras para las métricas d e CK? ¡|||j (Jamie y Ed asienten.)

Ed: Hay unas cuantas clases donde la RPC es muy elevada, comparada con las asociaciones verdaderas... tal vez debemos echar un vistazo para simplificarlas. J a m i e : Tal vez sí, tal vez no. Todavía estoy preocupada por el tiempo, y no quiero corregir cosas que realmente no están mal. V i n o d : Estoy de acuerdo con eso. Tol vez debemos buscor clases que tengan malos números en al menos do> o más métricas de CK. Digamos que si le pasan dos slrikes, hay que modificarlas. S h a k i r a ( m i r a n d o la lista d e c l a s e s d e Ed c o n a lt a RPC): Mira, ¿ves esta clase? Tiene una FCM alto, además d e una RPC alta. ¿Dos s l r i k e s ? V i n o d : Sí, así lo creo... por lo mismo, será difícil de implementar debido a la complejidad y dificultad de probar. Tal vez valga la pena diseñar dos clases separadas para alcanzar el mismo comportamiento. J a m i e : ¿Crees que la modificación nos ahorrará tiempo? V i n o d : A la larga, sí.

J a m i e : Como tenía las tarjetas CRC, eché un vistazo al AECO y parecía muy uniforme en casi todas las clases. Hubo una excepción, y la anoté.

15.4.4 Métricas orientadas a objetos: la colección de métricas para el diseño orientado a objetos Harrison, Counsell y Nithi [HAR98] proponen un conjunto de métricas para d i s e f : orientado a objetos que proporcionan indicadores cuantitativos para TM las características del diseño orientado a objetos. A continuación se presente una pequeña muestra de estas métricas:

PDF Editor

13 La métrica FCM proporciona conocimientos útiles en algunas situaciones, pero puede malinterprtarse en otras. Por ejemplo, mantener el acoplamiento encapsulado dentro de una clase aumenta s cohesión del sistema como un todo. Por tanto, por lo menos en un sentido importante, un FCM rr¿: elevado en realidad sugiere que una clase puede tener una mayor cohesión, no una menor.

CAPÍTULO 15


M é t o d o d e l f a c t o r d e h e r e n c i a (MFH).

487

El grado en que la arquitectura de clases

de un sistema orientado a objetos u s a la herencia para m é t o d o s (operaciones) y atributos se define c o m o MFH =IM,

(C,)/X Ma{C¡)

d o n d e la sumatoria se presenta d e s d e i = 1 hasta Tc. Tc se define c o m o el n ú m e r o total de clases en la arquitectura; C, es una clase dentro de la arquitectura y M„(C,) = MAC,) + M, (Q donde Ma(C¡) = el n ú m e r o de m é t o d o s que pueden invocarse en asociación con C¡. MafCj) = el n ú m e r o de m é t o d o s declarados en la clase C¡. M(C¡) = el n ú m e r o de m é t o d o s heredados (y no redefinidos) en C,. El valor de MFH (el atributo de factor de herencia, AFH, se define de m a n e r a análoga) es un indicativo del impacto de la herencia en el s o f t w a r e orientado a objetos.

"El análisis del software orientado a objetos para evaluar su calidad se está volviendo cada vez más importante o medido que el paradigma [orientado a objetos] sigue ganando popularidad." ;;•! , Rochel Harrison el al.

F a c t o r d e a c o p l a m i e n t o (FA).

Al principio de este capítulo se indicó que el aco-

plamiento es una indicación de las conexiones entre elementos de un diseño orient a d o a objetos. El conjunto de métricas del diseño orientado a objetos define el acoplamiento de la siguiente m a n e r a : FA = S, I , es_cliente (C„ q)/{Tc2

- Tc )

d o n d e las sumatorias van d e s d e i = 1 hasta Tc y d e s d e j = 1 hasta Tc. La función es_diente

= 1, si y sólo si existe una relación entre la clase cliente, C r , y la clase servidor, Cs, y Cc # Cs = 0, en cualquier otro c a s o

Aunque m u c h o s factores afectan la complejidad, la facilidad de comprensión y el m a n t e n i m i e n t o del software, resulta razonable concluir que, a medida que a u m e n t a TM el valor de FA, también a u m e n t a r á la complejidad del software orientado a objetos y, c o m o consecuencia, es posible que resulten afectadas la facilidad de comprensión y

PDF Editor mantenimiento, junto con la posibilidad de reutilización.

Harrison y sus colegas [HAR98] presentan una análisis detallado de MFH y FA,

junto con otras métricas, y e x a m i n a n su validez para emplearlos en la evaluación de la calidad del diseño.

488

PARTE DOS


15.4.5 Métricas orientadas a objetos propuestas por Lorenz y Kidd En su libro sobre métricas orientadas a objetos, Lorenz y Kidd [LOR94] dividen las métricas basadas en clases en cuatro amplias categorías, cada una con un diseño al nivel de componentes: tamaño, herencia, valores internos y valores externos. Las métricas orientadas al t a m a ñ o aplicadas a una clase de diseño orientado a objetos se concentran en el c o n t e o de atributos y operaciones d e una clase individual, as; c o m o en valores promedio para el sistema orientado a objetos c o m o un todo. Las métricas basadas en la herencia se concentran en la manera en que las operaciones se reutilizan en la jerarquía de clases. Las métricas para los valores internos buscar cohesión y aspectos orientados al código, y las métricas de valores externos exami nan el acoplamiento y la reutilización. A continuación se presenta una muestra de las métricas propuestas por Lorenz y Kidd: (CONSEJO^ Durante lo revisión del modelo de análisis, las tarjetas de Índice CHC proporcionarán uno indicación razonable de los valores esperados para el tamaño de la clase. Sise encuentro una cióse con un número grande de responsabilidades, piénsese en i

T a m a ñ o d e la c l a s e (TC).

El t a m a ñ o general de una clase se determina con las

siguientes medidas: • El número total de operaciones (de instancia heredada y privada) q u e están encapsuladas dentro de la clase. • El número de atributos (de instancia heredada y privada) que están encapsu lados por la clase. La métrica MPC q u e propusieron C h i d a m b e r y Kemerer (sección 15.4.3) tambiees una medida ponderada d e t a m a ñ o de clase. Como ya se indicó, los valores grandes de TC indican que tal vez una clase tenga demasiada responsabilidad. Esto reducirá la posibilidad d e reutilización de la clase y complicará la implementación \ ¿ prueba. En general, debe dársele m á s p e s o a las operaciones y los atributos h e r e d a ! d o s o públicos para determinar el t a m a ñ o de la clase [LOR94]. Las operaciones y ', :< atributos privados permiten la especialización y están m á s focalizados en el diser : También deben calcularse los promedios para el número de atributos y operacior de clase. Cuanto m e n o r e s sean los valores promedio para el TC, m á s probable será que las clases dentro del sistema p u e d a n reutilizarse ampliamente. Número d e o p e r a c i o n e s añadidas por una s u b c l a s e (NOA).

Las subclases

especializan al agregar operaciones y atributos. A medida que el valor de NOA a.*| menta, la subclase se aparta de la abstracción implícita en la superclase. En gene a medida que la profundidad de la jerarquía de clase a u m e n t a (APH TM se vuelve yor), debe caer el valor d e NOA en los niveles inferiores de la jerarquía.

15.4.6 Métricas de diseño al nivel de componentes

PDF Editor

Las métricas de diseño al nivel de c o m p o n e n t e s del software convencional se c

centran en las características internas de un c o m p o n e n t e de software e incluyen didas de cohesión, acoplamiento y complejidad del módulo. Estas medidas ayudaun ingeniero de software a juzgar la calidad de un diseño al nivel de component

CAPITULO 15

489


Las métricas presentadas en esta sección son de "caja de cristal", en el sentido de que requieren conocimiento del funcionamiento interno del módulo que se está considerando. Las métricas d e diseño al nivel de componentes s e aplican una vez que se ha desarrollado el diseño procedimental. Como opción, pueden demorarse hasta que el código fuente esté disponible. Métricas d e c o h e s i ó n . Bieman y Ott 1B1E94] definen una colección de métricas que proporcionan una indicación del grado de cohesión (capítulo 9) de un módulo. Las métricas s e definen a partir de cinco conceptos y medidas: Porción de datos. Definido simplemente, una porción de datos e s un recorrido hacia atrás por un módulo; busca valores de datos que afectan el estado del módulo cuando comienza el recorrido. Debe indicarse que es posible definir las porciones del programa (que se concentran en instrucciones y condiciones) y las porciones de datos. Muestras de datos. Las variables definidas para un módulo se definen como muestras de datos para el módulo. Señales de unión. Este conjunto de muestras de datos cae en una o más porciones de datos. Señales de superunión.

Estas muestras de datos son comunes a todas las porcio-

nes de datos de un módulo. Capacidad de unión. La capacidad de unión relativa de una señal de unión es directamente proporcional al n ú m e r o d e porciones de datos que une. Bieman y Ott desarrollan métricas para cohesión funcional fuerte, cohesión funcional débil y adhesividad (que se relaciona con el grado en que las señales de unión integran las porciones de datos). Estas métricas se interpretan de la siguiente manera [BIE94]: Todas e s t a s m é t r i c a s d e c o h e s i ó n a b a r c a n valores d e 0 a 1. Tienen un valor d e 0 c u a n d o un procedimient o c u e n t a con m á s d e u n a salida y n o m u e s t r a atributo a l g u n o d e c o h e s i ó n indicado p o r una métrica particular. Un p r o c e d i m i e n t o sin s e ñ a l e s d e s u p e r u n i ó n (es decir, sin m u e s t r a s c o m u n e s a t o d a s las p o r c i o n e s d e datos), tiene 0 c o h e s i ó n funcional fuerte (no hay m u e s t r a s de d a t o s q u e contribuyan a t o d a s las salidas). Un p r o c e d i m i e n t o sin s e ñ a l e s de unión (es decir, sin m u e s t r a s c o m u n e s a m á s d e u n a porción d e d a t o s , en proc e d i m i e n t o s c o n m á s d e una p o r c i ó n d e datos) m u e s t r a 0 c o h e s i ó n funcional débil y 0 adhesividad (no h a y m u e s t r a s d e d a t o s q u e contribuyan a m á s de u n a salida).

TM

La cohesión funcional fuerte y la adhesividad se encuentran cuando las métricas de Bieman y Ott toman un valor máximo de 1.

PDF Editor

Métricas de a c o p l a m i e n t o . El acoplamiento del módulo proporciona una indicación de la "conectividad" de un módulo con otros módulos, con datos globales y con el entorno exterior. En el capítulo 9 se analizó el acoplamiento desde el punto de vista cualitativo.

PARTE DOS


Dhama [DHA95] ha propuesto una métrica para el acoplamiento del módulo que abarca el acoplamiento de flujo de datos y de control, el global y el de entorno. Lai medidas necesarias para calcular el acoplamiento del módulo se definen a partir ce | cada uno de los tres tipos de acoplamiento indicados antes. En el caso del acoplamiento de flujo de datos y de control, de = número de parámetros de datos de entrada ce = número de parámetros de control de entrada ds = número de parámetros de datos de salida c s = número d e parámetros de control de salida En el caso del acoplamiento global: gd = número de variables globales usadas como datos gc = número de variables globales usadas como control En el caso del acoplamiento de entorno: w = número de módulos llamados (dependencia hacia fuera) r = número de módulos que llaman al módulo en cuestión (dependencia dentro) Con estas medidas se define un indicador de acoplamiento del módulo, m a , de la guiente manera: m„ = k/M donde k es una constante de proporcionalidad y M = dc + (a x ce) + ds + (¿> x cs) + gd+ (c x gc) + w + r

(15.

Los valores de k, a, b y c deben derivarse empíricamente. A medida que el valor de m a aumenta, disminuye el acoplamiento general del dulo. Para lograr que la métrica de acoplamiento suba a medida que aumenta el do de acoplamiento, se define una métrica de acoplamiento revisada C = 1 - ma donde el grado de acoplamiento aumenta a medida que lo hacen TMlas medidas ecuación (15.6). Métricas d e c o m p l e j i d a d .

Es posible calcular diversas métricas del soft

PDF Editor

para determinar la complejidad del flujo de control del programa. Muchas de se basan en la gráfica de flujo. Como se analizó en el capítulo 14, una gráfica una representación compuesta de nodos y enlaces (también denominados ari Cuando los enlaces (aristas) están dirigidos, la gráfica de flujo es una gráfica gida.

CAPÍTULO 15


491

McCabe y Watson [MCC94] identifican varios usos importantes para las métricas de complejidad: Las m é t r i c a s d e c o m p l e j i d a d s e utilizan p a r a p r e d e c i r la i n f o r m a c i ó n crítica a c e r c a d e la c o n f i a b i l i d a d y la facilidad d e m a n t e n i m i e n t o d e s i s t e m a s d e s o f t w a r e a p a r t i r del a n á l i s i s a u t o m á t i c o del c ó d i g o f u e n t e [o la i n f o r m a c i ó n del d i s e ñ o p r o c c d i m c n t a l ] . Las m é t r i c a s d e c o m p l e j i d a d t a m b i é n o f r e c e n r e t r o a l i m e n t a c i ó n d u r a n t e el p r o y e c t o d e s o f t w a r e p a r a ayud a r a c o n t r o l a r [la a c t i v i d a d del d i s e ñ o ) . D u r a n t e l a s p r u e b a s y el m a n t e n i m i e n t o , o f r e c e n u n a i n f o r m a c i ó n d e t a l l a d a a c e r c a d e los m ó d u l o s d e s o f t w a r e p a r a a y u d a r a d e t e c t a r á r e a s d e posible inestabilidad.

La métrica de complejidad cuyo uso es el m á s extendido (y debatido) para el

:LAVE ,] Csolo íi„ GS „ uno „„„ i de métricas t ::nplejidad.

software de computadora es la complejidad ciclomática, originalmente desarrollada por T h o m a s McCabe [MCC761, [MCC89], y que se analizó con todo detalle en el capítulo 14. Zuse ([ZUS90], [ZUS97]) presenta un análisis enciclopédico de n o menos de 18 categorías diferentes de las métricas de complejidad del software. El autor presenta las definiciones básicas de métricas en cada categoría (por ejemplo, hay distintas variaciones de la métrica de complejidad ciclomática) y luego analiza y critica cada una. El trabajo de Zuse es el más completo publicado a la fecha.

15.4.7 Métricas orientadas a la operación Debido a que la clase e s la unidad dominante en los sistemas orientados a objetos, se han propuesto pocas métricas para operaciones que residen dentro de la clase. Churcher y Shepperd [CHU95] analizan esto cuando afirman: "Los resultados de estudios recientes indican que los métodos tienden a ser pequeños en cuanto al número de instrucciones y a complejidad lógica [W1L93], lo que sugiere que la estructura d e conectividad d e un sistema e s m á s importante que el contenido de los módulos individuales". Sin embargo, se apreciarán mejor las cosas si se examinan las consultas promedio de métodos (operaciones). Tres métricas simples, propuestas por Lorenz y Kidd [LOR94], resultan apropiadas: T a m a ñ o p r o m e d i o d e o p e r a c i ó n (TO prom ). Aunque las líneas de código podrían usarse c o m o indicador del t a m a ñ o de operación, la medida de líneas de código adolece de una serie de problemas analizados en el capítulo 22. Por ello, el n ú m e r o d e m e n s a j e s que envía la operación proporciona una opción al t a m a ñ o de operación. A medida que aumenta el número de mensajes enviados por TM una sola operación, e s probable que las responsabilidades n o se hayan asignado bien dentro de la clase.

PDF Editor

Complejidad d e la o p e r a c i ó n (CO). La complejidad de una operación s e calcula empleando cualquier métrica de complejidad propuesta para el software convencional [ZUS90], Debido a que las operaciones deben limitarse a una responsabilidad específica, el diseñador debe esforzarse por m a n t e n e r la CO lo m á s baja posible.

PARTE DOS


N ú m e r o p r o m e d i o d e p a r á m e t r o s d e la o p e r a c i ó n (NPO p r o m ).

Mientras ma

yor s e a el n ú m e r o de p a r á m e t r o s de la operación, m á s compleja será la colaboracicentre los objetos. En general, el NPO prom debe m a n t e n e r s e lo m á s b a j o posible.

15.4.8 Métricas de diseño d e la interfaz d e usuario Aunque hay obras importantes que tratan el diseño de interfaces ser h u m a n o / m á q u i r j (capítulo 12), se ha publicado relativamente poca información sobre métricas que p r > porcionen conocimientos profundos sobre la calidad y la facilidad de uso de la interfaz. Sears [SEA93] sugiere que lo apropiado delformato (AF) es una métrica de diseño valiosa para interfaces ser h u m a n o / m á q u i n a . Una GUI común aplica entidades de formato (iconos gráficos, texto, menús, ventanas, etc.) para ayudar al usuario a completar t J reas. Para realizar una tarea determinada con una GUI, el usuario debe pasar de uca entidad de presentación a la siguiente. La posición absoluta y relativa de cada entidad de presentación, la frecuencia con que se emplea y el "costo" de la transición de ui entidad de formato a la siguiente contribuirán a determinar lo apropiado de la interis*| "Aprenderá por lo menos un principio del diseño de interfaces de usuario si echa la ropa en una lavadora. Si pone demasiada ropa, nado quedará limpio." Anóniir: Kokol y s u s colegas [KOK95] definen u n a métrica de cohesión para las p a n t a l l a de la interfaz de usuario que mide la conexión relativa e n t r e el contenido de u J Los métricas de diseño de lo interfaz son adecuadas, peco sobie todo lo demás, es necesario osegurarse plenamente de que la Interfaz le gusto a los usuarios finales y de que éstos se sienten cómodos con los interacciones requeridas.

pantalla y el de otra. Si los d a t o s (o el contenido adicional) p r e s e n t a d o s e n una p a a j talla pertenecen a un solo objeto importante de d a t o s (como se definió dentro j a modelo de análisis), la cohesión de la interfaz para esa pantalla será alta. Si se p « sentan m u c h o s tipos diferentes de d a t o s o contenidos y e s o s d a t o s se relacionan a a diferentes objetos de datos, la cohesión de la interfaz d e usuario será baja. Los aw tores proporcionan modelos empíricos para la cohesión [KOK95]. Además, las m e d i d a s directas d e la interacción con la interfaz de usuario se centran e n la medición del tiempo requerido para a lc a n z a r un escenario o una ración específicos, el tiempo requerido para recuperarse de una condición de e r - J los c o n t e o s de o p e r a c i o n e s o t a r e a s específicas requeridas para a lc a n z a r un casc a uso, el n ú m e r o de objetos de d a t o s o contenido p r e s e n t a d o s e n u n a pantalla, la fem sidad y el t a m a ñ o del texto y muchos otros. Sin embargo, estas medidas directas denoi estar o r g a n i z a d a s para crear métricas de interfaz d e usuario q uTM e tengan un sigr a c a d o y que lleven a mejorar la calidad, la facilidad de uso, o a m b o s elementos d¡e a interfaz de usuario.

PDF Editor

Es importante observar que la selección de un diseño de interfaz gráfica de u s J

rio p u e d e determinarse a partir de métricas c o m o AF o la cohesión de pantalla de a interfaz de usuario, pero el árbitro final d e b e ser la entrada del usuario basada J

prototipos de interfaz gráfica de usuario. Nielsen y Levy [NIE94] reportan que "se : n n e u n a probabilidad r a z o n a b l e m e n t e grande de éxito si s e elige entre las i n t e r f a ^

CAPÍTULO 15

493


[diseños] b a s a d a s exclusivamente en las opiniones de los usuarios. El d e s e m p e ñ o promedio de las t a r e a s de los usuarios y su satisfacción subjetiva con u n a interfaz gráfica de usuario tienen u n a elevada correlación".

La teoría de Halstead de la "ciencia del software" [HAL771 propuso las primeras "leyes" analíticas para el s o f t w a r e de computadora. 1 4 Halstead asignó leyes cuantitativ a s al desarrollo de e s t e s o f t w a r e e m p l e a n d o un c o n j u n t o de medidas primitivas que s e derivan d e s p u é s de que se ha g e n e r a d o el código, o se estiman una vez que el dis e ñ o e s t é completo. Las medidas son: n, = el n ú m e r o de o p e r a d o r e s distintos que a p a r e c e n en un programa. n 2 = el n ú m e r o de o p e r a n d o s distintos que a p a r e c e n en un programa. = el n ú m e r o total de veces que a p a r e c e el operador. N 2 = el n ú m e r o total de v e c e s que a p a r e c e el operando. Halstead aplica estas medidas primitivas para desarrollar expresiones relacionadas con la longitud global del programa, el volumen mínimo posible para un algoritmo, el volumen real (número de bits requeridos para especificar un programa), el nivel del : de la interfoz is, pero • -odo lo demás, ) aseguf Unamente de r irteríaz le : 3 los usuarios ¡ Y de que éstos i cómodos s interacciones

programa (una medida de la complejidad del software), el nivel del lenguaje (una constante para un lenguaje determinado) y otras características c o m o esfuerzo de desarrollo, tiempo de desarrollo y hasta el n ú m e r o proyectado de fallas en el software. Halstead d e m u e s t r a q u e la longitud N se p u e d e estimar así: N = n , log 2 n , + n 2 log 2 n 2 y que el volumen de p r o g r a m a s e p u e d e definir c o m o : V = N log 2 (r?i + n 2 ) Se d e b e observar que V variará de acuerdo con el lenguaje de programación y que representa el volumen de información (en bits) necesario para especificar un programa. »rlEl conjunto de 1 regios 1 que sigue el cerebro hume no Lpara el desarrollo de algoritmos] es mas rígido de lo que suele pensarse." Mauríce Halstead En teoría, d e b e existir un volumen mínimo para un algoritmo determinado. HalsTM tead define una relación de volumen, L, c o m o la relación e n t r e el volumen de la forma m á s c o m p a c t a de un p r o g r a m a y el volumen real del programa. En realidad, L siempre d e b e ser m e n o r que 1. Desde el p u n t o de vista de las medidas primitivas, la relación de volumen s e expresa c o m o

PDF Editor

14 Debe observarse que las "leyes" de Halstead han generado gran controversia, y muchos creen que la teoría tiene fallas Sin embargo, se ha realizado la verificación experimental de lenguajes de programación seleccionados (por ejemplo, [FEL8911

494

PARTE DOS

P R Á C T I C A D E LA INGENIERÍA DEL S O F T W A R E

L = 2/n, x n2/N2 El trabajo d e Halstead es sensible a la verificación experimental, y s e ha realizad o una gran cantidad de investigación sobre la ciencia del software. Para obtener m á s información, consúltense [ZUS90], [FEN91] y [ZUS97].

Aunque se ha escrito m u c h o s o b r e las métricas del s o f t w a r e para p r u e b a s (por ejemplo, [HET93]), casi t o d a s las métricas propuestas s e c o n c e n t r a n e n el proceso de prueba, n o en las características técnicas de las propias pruebas. En general, quien e s aplican las p r u e b a s deben d e p e n d e r de las métricas de análisis, diseño y códigc c o m o guía para el diseño y la ejecución de los c a s o s de prueba. Las métricas b a s a d a s en la función (sección 15.3.1) se aplican para predecir el esfuerzo general de la prueba. Es posible recopilar varias características al nivel de. proyecto (como el e s f u e r z o y el tiempo para las pruebas, los errores descubiertos, e. n ú m e r o de c a s o s de prueba producidos) de proyectos anteriores y correlacionarlas con el n ú m e r o d e p u n t o s de función q u e p r o d u c e u n equipo de proyecto. Este equipo tiene la opción posterior de proyectar "valores e s p e r a d o s " de e s t a s características para el proyecto actual.
Las métricas del diseño arquitectónico proporcionan información s o b r e la facilidad o la dificultad asociada con la prueba de integración (capítulo 13) y la n e c e s i d a :

CLAVE Los métricos de pruebo se agrupan en dos amplias categorías: 1) las que tratan de predecli el número probable de pruebas que se requieren a varios niveles de prueba, y 2) las que se concentran en la cobertura de la prueba para un componente determinado.

de contar con s o f t w a r e especializado en p r u e b a s (por ejemplo, r e s g u a r d os y contr; ladores). La complejidad ciclomática (una métrica de diseño al nivel de c o m p o n e r tes) cae en el eje de las p r u e b a s de c a m i n o básico, un m é t o d o de diseño d e c a s o s de prueba p r e s e n t a do e n el capítulo 14. Además, la complejidad ciclomática se emplea para determinar los m ó d u l o s q u e serán candidatos a pruebas de unidad m á s exter sas. Los módulos con elevada complejidad ciclomática son m á s p r o p e n s o s a errcr que los que tienen u n a m e n o r complejidad. Por ello, la p e r s o n a responsable de -a prueba d e b e realizar un e s f u e r z o superior al promedio para descubrir errores en estos m ó d u l o s a n t e s de integrarlos e n un sistema.

15.6.1 Métricas de Halstead aplicadas a las pruebas También es posible estimar el e s f u e r z o que requieren las p r u e b a s mediante métricas derivadas de las m e d i d a s de Halstead (sección 15.5). Si se aplican las definiciones d d i TM e, se calculaba volumen, V, y el nivel de un programa, NP, el e s f u e r z o de Halstead,

así: NP = l/[(7i,/2) x (N2/n2)] e = V/NP

PDF Editor

(15.7a| (15.7bJ

El p o r c e n t a j e del e s f u e r z o general d e prueba q u e se d e b e asignar a un k se estima -] ría con la siguiente relación:

porcentaje de e s f u e r z o de prueba {k) = e ( k ) / ^ e ( i )

(15.8

d o n d e e(k) se calcula p a r a el m ó d u l o k e m p l e a n d o las e c u a c i o n e s (15.7), y donde

CAPÍTULO 15


495

sumatoria en el denominador de la ecuación (15.8) e s la suma del esfuerzo de Halstead en todos los módulos del sistema.

15.6.2 Métricas para pruebas orientadas a objetos Las métricas del diseño orientado a objetos expuestas en la sección 15.4 proporcionan una indicación de la calidad del diseño. También proporcionan una indicación general de la cantidad de esfuerzo necesario en la prueba para ejercitar un sistema orientado a objetos. Binder [B1N94] sugiere una amplia serie de métricas de diseño que tienen una influencia directa sobre la "facilidad d e prueba" de un sistema orientado a objetos. Las métricas toman en cuenta aspectos de encapsulamiento y herencia. A continuación se presenta una muestra:

*

[CONSEJO

i orientada a i a ser 1:37ipiejo. Los s ayudarán a ríos recursos : xuebo a subpro, escenarios y s de closes 'sospes'con base en s znxterísticos . Es recomeni usados.

Falta de cohesión e n m é t o d o s (FCM).' 5 Mientras mayor sea el valor de FCM, deben probarse más estados para asegurar que los métodos no generen efectos colaterales. Porcentaje público y protegido (PYP).

Esta métrica indica el porcentaje de atri-

butos de clase que son públicos o están protegidos. Valores elevados d e PYP a u m e n tan la probabilidad de efectos colaterales entre clases porque los atributos públicos o protegidos conllevan una alta probabilidad de acoplamiento (capítulo 9). 16 Deben diseñarse pruebas para asegurar el descubrimiento de estos efectos colaterales. Integrantes d e a c c e s o público a d a t o s (APD). Esta métrica indica el n ú m e r o de clases (o métodos) al que tienen acceso otros atributos de clase, lo que es una violación del encapsulamiento. Valores elevados de APD conllevan la posibilidad d e efectos colaterales entre clases. Deben diseñarse pruebas para asegurar el descubrimiento d e estos efectos colaterales. N ú m e r o de c l a s e s raíz (NCR). Esta métrica e s un conteo de las distintas jerarquías de clase descritas en el modelo de diseño. Deben desarrollarse conjuntos de prueba para cada clase raíz y para la jerarquía de clases correspondiente. A medida que aumente el NCR, también aumentará el esfuerzo de la prueba. D e p e n d e n c i a hacia dentro (FIN). Cuando se aplica en el contexto orientado a objetos, la dependencia hacia dentro para la jerarquía de herencia e s un indicador de herencia múltiple. FIN > 1 indica que una clase hereda sus atributos y operacione s a partir de una clase raíz. Debe evitarse que FIN > 1 a toda costa. Número de descendientes (NDD) y árbol de profundidad de herencia (APH). 17 TMmétodos de la Como se analizó en el capítulo 14, es necesario volver a probar los superclase de cada subclase.

PDF Editor

15 Consúltese la sección 15.4.3 para conocer una descripción de FCM. 16 Algunas personas promueven diseños en que ninguno de los atributos es público o privado; es decir, PYP = 0. Esto indica que todos los atributos deben accederse en otras clases por medio de métodos.

17 Consúltese la sección 15.4.3 para conocer una descripción de NDD y APH.

496

PARTE DOS


Todas las métricas del software presentadas en este capítulo se aplican también a desarrollo de nuevo software y al mantenimiento del existente. Sin embargo, se har propuesto métricas diseñadas explícitamente para actividades de mantenimiento El IEEE Std. 982.1-1988 [IEE94] sugiere un índice de madurez del software (IMS q u e proporciona una indicación de la estabilidad de un producto de software (basa da en los cambios q u e ocurren con cada versión del producto). Se determina la s¡ guíente información: MT = el número de módulos en la versión actual Fc = el número de módulos cambiados en la versión actual Fa = el número de módulos añadidos a la versión actual Fd = el número de módulos de la versión anterior que se eliminaron en la actúa El índice de madurez del software se calcula de la siguiente manera: IMS = [MT-(Fa + Fc + Fd)]/ Mr A medida que el IMS se acerca a 1.0, el producto empieza a estabilizarse. El IMS tam bién se aplica c o m o métrica para la planeación de actividades de mantenimiento de software. El tiempo medio para producir una versión de un producto de software puede correlacionarse con el IMS, y pueden desarrollarse modelos empíricos para e-, esfuerzo de mantenimiento. HERRAMIENTAS DE SOFTWARE

Métricas del producto O b j e t i v o : Ayudar a los ingenieros de software en el desarrollo de métricas significativas que evalúen los productos del trabajo generados durante el modelado de análisis y diseño, la generación de código fuente y la prueba. M e c á n i c a : Las herramientas de esta categoría abarcan una amplia serie de métricas y se implementan como aplicaciones independientes o (con mayor frecuencia) como funcionalidad que existe dentro de las herramientas para análisis y diseño, codificación o prueba. En la mayor parte de los casos, la herramienta de métrica analiza una representación del software (por ejemplo, un modelo UML o el código fuente) y desarrolla una o más métricas. Herramientas representativas'8 Krakatau Metrics, desarrollada por Power Software (www.powersoftware.com/products), calcula métricas

de complejidad, Halstead y otras relacionadas para C/C++ y Java. Metrics4C, desarrollada por +1 Software Engineering (www.plus-one.com/Metrics4C-fact_sheet.html), calcula varias métricas arquitectónicas, de diseño y orientadas a código, además de otras orientadas a proyecto. Rationol Rose, desarrollada por Rational Corporation (www.rational.com), es un conjunto d e herramientas completas para el modelado UML que incorpora varias características de análisis de métricas. RSM, desarrollada por M-Squared Technologies (msquaredtechnologies.com/m2rsm/index.html), calcula una amplia variedad de métricas orientadas a TM configuración para C, C++ y Java. Understand, desarrollada por Scientific Toolworks, Inc. (www.scitools.com), calcula las métricas orientadas a código para diversos lenguajes de programación.

PDF Editor

18 Las herramientas expuestas representan una muestra de esta categoría. En casi todos los casos los nombres de las mismas son marcas registradas de sus respectivos desarrolladores.

Las métricas del software proporcionan una manera cuantitativa de evaluar la calidad de los atributos internos de un producto, lo que permite que un ingeniero de software evalúe la calidad antes de construirlo. Las métricas proporcionan los conocimientos necesarios para crear modelos efectivos de análisis y diseño, un código sólido y pruebas exhaustivas. Para que resulte útil en la realidad, una métrica del software debe ser simple y cal culable, persuasiva, consistente y objetiva. Debe ser independiente del lenguaje de programación y proporcionar retroalimentación efectiva al ingeniero del software. Las métricas para el modelo de análisis se concentran en la función, los datos y el comportamiento (los tres componentes del modelo de análisis). Las métricas para el diseño consideran los aspectos del diseño de la arquitectura, al nivel de componentes y de la interfaz. Las métricas del diseño de la arquitectura consideran los aspectos estructurales del modelo de diseño. Las métricas de diseño al nivel de componentes indican la calidad del módulo al establecer medidas indirectas para la cohesión, el acoplamiento y la complejidad. Las métricas de diseño de la interfaz d e usuario proporcionan un indicio de la facilidad con que se usa la interfaz gráfica del usuario. Las métricas para los sistemas orientados a objetos se concentran en la medición que puede aplicarse a las características de clase y diseño (localización, encapsulamiento, ocultamiento de información, herencia y técnicas de abstracción de objetos) que convierten a la clase en única. Halstead proporciona un conjunto interesante de métricas al nivel de código fuente. Empleando el n ú m e r o de operadores y operandos presentes en el código, se desarrolla una variedad de métricas para evaluar la calidad del programa. Pocas métricas del producto se han propuesto para emplearlas directamente en las pruebas del software y en el mantenimiento. Sin embargo, muchas otras métricas del producto pueden aplicarse para guiar el proceso de prueba y como mecanismo para evaluar la facilidad de mantenimiento de un programa de cómputo. Una amplia variedad de métricas orientadas a objetos se ha propuesto para evaluar la facilidad de prueba de un sistema orientado a objetos. :#Íl|ÍlÍÍl!|¡Í¡Íí|j [ALB79] Albrecht, A.)., "Measuring Application Development Productivity", e n Proc. IBM Application Development Symposium, Monterey, CA, o c t u b r e de 1979, pp. 83-92.TM [ALB83] Albrecht, A. J. y ) . E. Gaffney, "Software Function, Source Lines of Code a n d Developm e n t Effort Prediction: A Software Science Validation". e n IEEE Trans. Software Engineering, n o v i e m b r e d e 1983, pp. 639-648. [BAS84] Basili, V. R. y D. M. Weiss, "A Methodology for Collecting Valid S o f t w a r e Engineering Data", e n IEEE Trans. Software Engineering, vol. SE-10. 1984, pp. 728-738. [BER95) Berard, E., "Metrics for Object-Oriented S o f t w a r e Engineering", publicación d e Internet e n c o m p . s o f t w a r e - e n g , 2 8 d e enero, 1995 [BIE94] Bieman, J. M. y L. M. Ott, "Measuring Functional Cohesion". en IEEE Trans. Software En gineering, vol. SE-20, n ú m . 8, a g o s t o d e 1994, p p 308-320.

PDF Editor

498

PARTE DOS

P R Á C T I C A DE L A INGENIERÍA D A S O F T W A R E

[BIN94] Binder, R. V., "Object-Oriented S o f t w a r e Testing", e n CACM, vol. 37, n ú m . 9, septiembre d e 1994, p. 29. [BRI96] Briand, L. C„ S. Morasca y V. R. Basili, "Property-Based S o f t w a r e Engineering Measurement", e n IEEE Trans. Software Engineering, vol. SE-22, n ú m . 1, e n e r o de 1996, pp. 68-85. [CAR90] Card, D. N. y R. L. Glass, Measuring Software Design Quality, Prentice-Hall, 1990. [CAV78] C a v a n o , J. P. y J. A. McCall, "A Framework for the M e a s u r e m e n t of S o f t w a r e Quality Proc. ACM Software Quality Assurance Workshop, n o v i e m b r e de 1978, pp. 133-139. [CHA891 Charette, R. N., Software Engineering Risk Analysis and Management, McGraw-Hill/Inte-text, 1989. [CH194] Chidamber, S. R. y C. F. Kemerer, "A Metrics Suite for Object-Oriented Design", e n / Trans. Software Engineering, vol. SE-20, n ú m . 6, junio de 1994, pp. 476-493. [CH198] Chidamber, S. R., D. P. Darcy y C. F. Kemerer, " M a n a g e m e n t Use of Metrics for O b j e c - : Oriented Software: An Exploratory Analysis", e n IEEE Trans. Software Engineering, vol. SE-2- J n ú m . 8, a g o s t o d e 1998, pp. 629-639. [CHU95] Churcher, N. I. y M. J. Shepperd, "Toward a Conceptual F r a m e w o r k for Object-OrieMetrics", e n ACM Software Engineering Notes, vol. 20, n ú m . 2, abril d e 1995, pp. 69-76. [CUR80] Curtís, W., " M a n a g e m e n t a n d Experimentation in S o f t w a r e Engineering", e n Proc. I. vol. 68, n ú m . 9, s e p t i e m b r e de 1980. [DAV93] Davis, A. el al., "Identitying and Measuring Quality in a S o f t w a r e R e q u i r e m e n t s S~ fication", e n Proc. First Intl. Software Metrics Symposium, IEEE, Baltimore, MD, m a y o de 1 pp. 141-152. [DEM8I] DeMillo, R. A. y R. J. Lipton, "Software Project Forecasting", en Software Metrics (A Perlis, F. G. Sayward y M. Shaw, eds.), MIT Press, 1981, pp. 77-89. |DEM82j DeMarco, T., Controlling Software Projects, Yourdon Press, 1982. [DHA95] D h a m a , H„ "Quantitative Models of Cohesion a n d Coupling in Software", e n Journal Systems and Software, vol. 29, n ú m . 4, abril d e 1995. [EJI91] Ejiogu, L., Software Engineering with Foimal Metrics, QED Publishing, 1991. [FEL89J Felican, L. y G. Zalateu, "Validating Halstead's Theory for Pascal Programs", e n f Trans. Software Engineering, vol. SE-15, n ú m . 2, diciembre d e 1989, pp. 1630-1632. [FEN91] Fenton, N., Software Metrics, C h a p m a n a n d Hall, 1991. [FEN94] Fenton, N„ "Software M e a s u r e m e n t : A Necessary Scientific Basis", e n IEEE Trans. ware Engineering, vol. SE-20, n ú m . 3, m a r z o de 1994, pp. 199-206. [GRA87] Grady, R. B. y D. L. Caswell, Software Metrics: Establishing a Company-Wide Prentice-Hall, 1987. [HAL77] Halstead, M., Elements of Software Science, North-Holland, 1977. [HAR98J Harrison, R„ S. J. Counsell y R. V. Nithi, "An Evaluation of the MOOD set of Ob ; ~ Oriented S o f t w a r e Metrics", en IEEE Trans. Software Engineering, vol. SE-24, n ú m . 6, junio 1998, pp. 491-496. [HET93] Hetzel, B., Making Software Measurement Work, QED Publishing, 1993. [IEE93] IEEE Standard Glossaiy of Software Engineering Terminology, IEEE, 1993. [IEE94] Software Engineering Standards, edición 1994, IEEE, 1994. [IFPOl] Function Point Counting Practices Manual, versión 4.1.1, International Function Users Group, 2001, disponible e n h t t p : / / w w w . i f p u g . o r g / p u b l i c a t i o n s / m a n u a l . h t m . [IFP03] Function Point Bibliography/Reference Library, International Function Point U Group, 2003, disponible en h t t p : / / w w w . i f p u g . o r g / a b o u t / b i b l i o g r a p h y . h t m . [KOK95] Kokol, P„ l. R o z m a n y V. Venuti, "User Interface Metrics", ACM SIGPLAN Notices, vol n ú m . 4, abril de 1995, p u e d e d e s c a r g a r s e de: h t t p : / / p o r t a l . a c m . o r g /TM . [KYB84J Kyburg, H. E„ Theoiy and Measurement, Cambridge University Press, 1984. [LET03] Lethbridge, T„ c o m u n i c a c i ó n privada s o b r e m é t r i c a s d e s o f t w a r e , junio d e 2003. ÍLON02] Longstreet, D., " F u n d a m e n t a l of Function Point Analysis", Longstreet Consulting, 2002, disponible e n h t t p : / / w w w . i f p u g . c o m / f p a f u n d . h t m . [LOR94] Lorenz, M. y J. Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994. [MCC76] McCabe, T. J„ "A S o f t w a r e Complexity Measure", e n IEEE Trans. Software Engin vol. SE-2, diciembre de 1976, pp. 308-320. |MCC77) McCall, J., P. Richards y G. Walters, "Factors in S o f t w a r e Quality", tres v o l ú m e n e s , AD-A049-014, 015, 055, n o v i e m b r e de 1977.

PDF Editor

CAPÍTULO 15

MÉTRICAS DEL PRODUCTO P A R A EL SOFTWARE

499

[MCC89I McCabe, T. J. y C. W. Butler, "Design Complexity M e a s u r e m e n t a n d Testing", en CACM, vol. 32, n ú m . 12, diciembre d e 1989, pp. 1415-1425. [MCC94] McCabe, T. J. y A. H. Watson, "Software e n Complexity", e n Crosstalk, vol. 7, n ú m . 12, diciembre d e 1994, pp. 5-9. [NIE94] Nielsen, J. y J. Levy, "Measuring Usability: Preference vs. Performance", e n CACM, vol. 37, n ú m . 4, abril d e 1994, pp. 65-75. [ROC94) Roche, J. M., "Software Metrics a n d M e a s u r e m e n t Principies", e n Software Engineering Notes, ACM, vol. 19, n ú m . 1, e n e r o de 1994, pp. 76-85. [SEA93] Sears, A., "Layout Appropriateness: A Metric for Evaluating User Interface Widget Layout", e n lEEETTans. Software Engineering, vol. SE-19, n ú m . 7, julio d e 1993, pp. 707-719. (SHE98) Sheppard, M„ Goal, Question, Metric, 1998, disponible e n h t t p : / / d e c . b o u r n e m o u t h . a c . u k / ESERG/mshepperd/SEMGQM .html ISOL99] Van Solingen, R. y E. Berghout, The Goal/Questíon/Metric Method, McGraw-Hili, 1999. [UEM99] Uemura, T., S. Kusumot o y K. Inoue, "A Function Point M e a s u r e m e n t Tool for UML Design Specifications", e n Proc. Of Sixth International Symposium on Software Metrics, IEEE, n o v i e m b r e d e 1999, pp. 62-69. [USA87] Management Quality Insight, AFCSP 800-14 (U.S. Air Forcé), 20 d e e n e r o d e 1987. [WHI97] Whitmire, S„ Object Oriented Design Measurement, Wiley, 1997. [WIL93] Wilde, N. y R. Huitt. "Maintaining Object-Oriented Software", e n IEEE Software, e n e r o de 1993, pp. 75-80. [ZUS90] Zuse, H., Sofhvare Complexity: Measures and Methods, DeGruyter, 1990. [ZUS97] Zuse, H., A Framework of Software Measurement, DeGruyter, 1997.

1 5 . 1 . La teoría d e la medición e s un t e m a a v a n z a d o q u e tiene u n a fuerte influencia s o b r e las m é t r i c a s del s o f t w a r e . Utilizando [ZUS97], [FEN91], [KYB84) u o t r a s fuentes, escribir un breve e n s a y o q u e delinee los principales principios d e la teoría d e la medición. Proyecto individual: desarrollar u n a p r e s e n t a c i ó n s o b r e el t e m a y p r e s e n t a r l a a n t e la clase. 1 5 . 2 . Los factores de calidad d e McCall s e desarrollaron d u r a n t e la d é c a d a d e 1970. Casi t o d o s los a s p e c t o s d e la c o m p u t a c i ó n han c a m b i a d o d r á s t i c a m e n t e d e s d e q u e s e desarrollaron; sin e m b a r g o , los factores de McCall siguen a p l i c á n d o s e al s o f t w a r e m o d e r n o . ¿Podría llegarse a alg u n a s c o n c l u s i o n e s a partir d e este h e c h o ? 1 5 . 3 . ¿Por q u é n o s e p u e d e desarrollar u n a sola métrica q u e lo a b a r q u e t o d o para la complejidad o la calidad de un p r o g r a m a ? 1 5 . 4 . Trátese de desarrollar u n a m e d i d a o u n a métrica t o m a d a d e la vida real q u e viole los atrib u t o s de l a s m é t r i c a s efectivas del s o f t w a r e q u e s e definieron e n la sección 15.2.5 1 5 . 5 . Un s i s t e m a tiene 12 e n t r a d a s externas, 24 salidas externas, c a m p o s para 30 c o n s u l t a s externas diferentes, m a n e j a c u a t r o a r c h i v o s lógicos e x t e r n o s y tiene interfaces con seis s i s t e m a s h e r e d a d o s d i f e r e n t e s (6 A1E). Todos e s t o s d a t o s tienen u n a complejidad promedio, y el s i s t e m a general e s r e l a t i v a m e n t e simple. Calcúlese el p u n t o de función p a r a el sistema. 1 5 . 6 . El s o f t w a r e para el Sistema X tiene 24 requisitos f u n c i o n a l e s individuales y 14 n o funcionales. ¿Cuál e s la especificidad de los requisitos? ¿En q u é g r a d o s e h a c o m p l e t a d o ? 1 5 . 7 . Un i m p o r t a n t e sistema de información tiene 1140 m ó d u l o s ; 96 m ó d u l o s realizan f u n c i o n e s d e control y coordinación, y 490 d e p e n d e n de u n p r o c e s a m i e n t o anterior. TM El sistema procesa alrededor d e 2 2 0 o b j e t o s de datos, c a d a u n o c o n u n p r o m e d i o de tres atributos. Hay 140 elem e n t o s ú n i c o s d e la b a s e d e d a t o s y 90 s e g m e n t o s d i f e r e n t e s de é s t a . Por último, 600 m ó d u l o s tienen p u n t o s ú n i c o s d e e n t r a d a y salida. Calcúlese el 1CED del sistema.

PDF Editor

1 5 . 8 . Una clase, X, tiene 12 o p e r a c i o n e s . Se h a c a l c u l a d o la complejidad ciclomática para tod a s las o p e r a c i o n e s del s i s t e m a o r i e n t a d o a objetos, y el valor p r o m e d i o de la complejidad del m ó d u l o e s d e 4. Para la clase X, la complejidad d e la o p e r a c i ó n 1 a la 12 e s 5, 4, 3, 3, 6, 8, 2, 2, 5, 5, 4 y 4, r e s p e c t i v a m e n t e . Calcúlense los m é t o d o s p o n d e r a d o s p o r clase.

Hay u n n ú m e r o s o r p r e n d e n t e m e n t e g r a n d e de libros d e d i c a d o s a las m é t r i c a s del s o f t w a r e , q u e la m a y o r parte d e ellos s e c o n c e n t r a e n las m é t r i c a s del p r o c e s o y el proyecto, p o r lo excluyen las m é t r i c a s del producto. Kan (Metrics and Models in Software Quality Engineering, dison-Wesley, s e g u n d a edición, 2002), Fenton y Plleeger (Software Metrics: A Rigourous and tical Approach, Brooks-Cole Publishing, 1998) y Z u s e ¡ZUS97] h a n escrito t r a t a m i e n t o s c o tos d e las m é t r i c a s del producto. Libros de C a r d y Glass 1CAR90], Z u s e [ZUS90], Fenton (FEN91], Ejiogu (EJI91], M o e l l e r y lish (Software Metrics, C h a p m a n y Hall, 1993) y Hetzel [HET93] a t i e n d e n las m é t r i c a s del pr~ t o c o n algún detalle. O r n a n y Pfleeger (Applyig Software Metrics, IEEE C o m p u t e r Society " 1997) han editado u n a antología d e artículos i m p o r t a n t e s s o b r e las m é t r i c a s del s o f t w a r e m á s , vale la p e n a e x a m i n a r los siguientes libros: Conté, S. D., H. E. D u n s m o r e y V. Y. Shen, Software Engineering Metrics and Models, m i n - C u m m i n g s , 1984. Grady, R. B„ Practica! Software Metrics for Project Management and Process Improvement, tice-Hall, 1992. Sheppard, M„ Software Engineering Metrics, McGraw-Hill, 1992. Denvir, H e r m á n y Whitty p r e s e n t a n la teoría d e la medición del s o f t w a r e e n u n a col" editada d e artículos (Proceedings of the International BCS-FACS Workshop: Formal Aspects of surement, Springer-Verlag, 1992). S h e p p e r d (Foundations of Software Measurement, Prer Hall, 1996) t a m b i é n a t i e n d e con cierto detalle la teoría d e la medición. El e s t a d o actual de !a vestigación s e p r e s e n t a e n los Proceedings of the Symposium on Software Metrics (IEEE, p dos anualmente). Un r e s u m e n muy c o m p l e t o de d o c e n a s de m é t r i c a s de s o f t w a r e útiles s e p r e s e n t a e n [I En general, u n análisis de c a d a métrica s e h a r e d u c i d o a los "primitivos" (las medidas) e s les n e c e s a r i o s para calcular la métrica y las r e l a c i o n e s a p r o p i a d a s para realizar el cálculc a p é n d i c e p r o p o r c i o n a un análisis y m u c h a s referencias. Whitmire [WHI97] p r e s e n t a el t r a t a m i e n t o m á s c o m p l e t o y m a t e m á t i c a m e n t e sofistic las m é t r i c a s o r i e n t a d a s a o b j e t o s q u e s e haya publicado a la fecha. L o r e n z y Kidd [LOR94] y dersen-Sellers (Object-Oriented Metrics: Measures ofComplexity, Prentice-Hall, 1996) o f r c : ú n i c o libro adicional d e d i c a d o a las m é t r i c a s o r i e n t a d a s a objetos. H u t c h e s o n (Software Te Fundamentáis: Methods and Metrics, Wiley, 2003) p r e s e n t a u n a guía útil p a r a la aplicación u s o d e m é t r i c a s p a r a la p r u e b a del s o f t w a r e . Una amplia variedad d e f u e n t e s d e información s o b r e m é t r i c a s del s o f t w a r e s e en disponible e n Internet. Una lista actualizada de referencias e n la World Wide Web relevantes ra las m é t r i c a s del s o f t w a r e s e e n c o n t r a r á e n el sitio Web de SEPA:


TM

PDF Editor

Tres APLICACIÓN DE LA I N G E N I E R Í A W E B

E

n esta parte de Ingeniería del software: un enfoque práctico, se aprenderán los principios, conceptos y métodos con que se crean aplicaciones Web de alta calidad. Las siguientes preguntas se abordan en los capítulos posteriores: • ¿Las aplicaciones Web (WebApps) son diferentes de otros tipos de software? • ¿Qué es la ingeniería Web y qué elementos de la práctica de la ingeniería del software puede adoptar? • ¿Cuáles son los elementos de un proceso de ingeniería Web? • ¿Cómo se formula y planea un proyecto de ingeniería Web? • ¿Cómo se analizan y modelan los requisitos de las WebApps? • ¿Qué conceptos y principios guían la práctica en el diseño de las WebApps? • ¿Cómo se dirigen la arquitectura, la interfase y el diseño de navegación de las WebApps? • ¿Qué técnicas de construcción se pueden aplicar para implementar el modelo del diseño? TM • ¿Qué conceptos, principios y métodos de prueba son aplicables a la ingeniería Web?

PDF Editor

Una vez respondidas estas preguntas se estará mejor preparado para realizar la ingeniería de aplicaciones Web de alta calidad.

501

C A P I T U L O A

INGENIERÍA WEB CONCEPTOS CLAVE

criterios de calidad

513

ingeniería Web herramientas .508

L

a World Wide Web y la Internet que la alimentan son, posiblemente, los de sarrollos m á s importantes en la historia de la computación. Estas tecnolc gías han llevado a todos (con cientos de millones m á s que eventualmem seguirán) a la era d e la informática; además, se han convertido en parte integn de la vida diaria en la primera década del siglo xxi. Para quienes pueden recordar un m u n d o sin la Web, el crecimiento caót:;

métodos

507

de la tecnología tiene su origen en otra era: los primeros días del software. Er

proceso

507

u n a época de poca disciplina pero enorme entusiasmo y creatividad. Eran tierr

marco de trabajo del proceso . . . .509

pos en que los programadores a menudo ingresaban a sistemas en conjunto, a ve

mejores prácticas

pido y entra en el campo; nosotros lo limpiaremos (y mejor entiende qué es i 512

preguntas básicas

SU

WebApps atributos . . . .504 (alegorías . . . 5 0 6

ees para bien, a veces para mal. La actitud prevaleciente parecía ser: "hazlo ra que realmente se necesita construir) conforme avancemos". ¿Suena familiar En una mesa redonda virtual publicada en IEEE Sofhvare [PRE98], mantuv firme mi posición en relación con la ingeniería Web: Me parece que cualquier producto o sistema importante vale la pena una ingeniería Antes de comenzar a construirla es mejor que entienda el problema, diseñe una solución factible, la implemente en una forma sólida y la ponga a prueba ampliamente Tal vez también tenga que controlar los cambios conforme el trabajo avance y disponer de algún mecanismo para asegurar la calidad del resultado final. Muchos desarrolladores de Web no están de acuerdo con esto; ellos piensan que su mundo realmente es diferente y que los enfoques convencionales de ingeniería del software simplemente no se aplican.

¿ Q u é e s ? Los s i s t e m a s y a p l i c a c i o -

c i a s e n la m a n e r a c o m o s e d i r i g e n d i c h a s activi-

nes b a s a d o s e n W e b ( W e b A p p s ) ofrecen un c o m p l e j o a r r e g l o d e con-

d a d e s , p e r o el m é t o d o p r i m o r d i a l d i c t a u n e n f o -

tenido y funcionalidad a u n a amplia p o b l a c i ó n d e u s u a r i o s f i n a l e s . La i n g e n i e r í a W e b ( I W e b ) e s el p r o c e s o con el q u e se c r e a n W e b A p p s d e a l t a c a l i d a d . La ! W e b n o

q u e d i s c i p l i n a d o p a r a el d e s a r r o l l o d e u n sistem a b a s a d o en la c o m p u t a d o r a .

¿ Q u i é n lo h a c e ? Los ingenierosTM Web y los desab o l l a d o r e s d e l c o n t e n i d o q u e n o e s técnico c r e a n las W e b A p p s .

e s un c l o n p e r f e c t o d e la i n g e n i e r í a d e l s o f t w a -

¿ P o r q u é e s i m p o r t a n t e ? Conforme las Web-

re, p e r o t o m a p r e s t a d o s m u c h o s c o n c e p t o s y

A p p s s e i n t e g r a n c a d a v e z m á s en l a s e s t r a t e -

p r i n c i p i o s f u n d a m e n t a l e s d e e l l a . A d e m á s , el

gias de

proceso IWeb a c e n t ú a actividades técnicas y a d m i n i s t r a t i v a s s i m i l a r e s . Existen sutiles d i f e r e n -

e m p r e s a s ( p o r e j e m p l o , e n el c o m e r c i o electróni-

PDF Editor negocios

para

pequeñas y grandes

c o ) , c r e c e e n i m p o r t a n c i a l a n e c e s i d a d d e cons-

C A P Í T U L O 16

503

INGENIERÍA WEB

ruir sistemas confiables, prácticos y a d a p t a b l e s . Por tanto, es n e c e s a r i o un e n f o q u e d i s c i p l i n a d o e n c u a n t o al d e s a r r o l l o d e W e b A p p s .

¿Cuáles s o n los p a s o s ? Al igual que cualquier disciplina d e i n g e n i e r í a , la I W e b a p l i c a un e n f o q u e g e n é r i c o q u e se suaviza m e d i a n t e estrategias, tácticas y m é t o d o s e s p e c i a l i z a d o s . El p r o ceso I W e b c o m i e n z a con u n a formulación del p r o b l e m a q u e se resolverá con la W e b A p p . Se p l a n e a el p r o y e c t o I W e b y s e m o d e l a n los requisitos y el d i s e ñ o d e la W e b A p p El sistema se construye con t e c n o l o g í a s y h e r r a m i e n t a s e s p e c i a l i z a d a s a s o c i a d a s con la W e b . Entonces s e e n t r e g a a los usuarios finales y se e v a l ú a m e d i a n t e criterios t a n t o técnicos c o m o e m p r e s a -

riales D a d o q u e las W e b A p p s e v o l u c i o n a n continuamente, se d e b e n establecer m e c a n i s m o s p a r a el control d e c o n f i g u r a c i o n e s , el a s e g u r a miento d e la c a l i d a d y el s o p o r t e continuo.

¿Cuál e s el p r o d u c t o o b t e n i d o ? Se producen m u c h o s p r o d u c t o s d e t r a b a j o IWeb. El r e s u l t a d o final e s la W e b A p p o p e r a t i v a ,

¿Cómo puedo estar seguro de que lo he hecho correctamente? En o c a s i o n e s e s difícil estar seguro, h a s t a q u e los usuarios finales ejecutan la W e b A p p . Sin e m b a r g o , se aplican práctic a s d e a s e g u r a m i e n t o d e la calidad del software p a r a valorar la calidad d e los modelos IWeb, el contenido y la función globales del sistema, la facilidad d e uso, él d e s e m p e ñ o y la s e g u r i d a d .

Esto conduce a una pregunta clave: ¿se pueden aplicar principios, conceptos y métodos de la ingeniería del software al desarrollo Web? Es posible aprovechar muchos de ellos, pero su aplicación puede requerir un giro un tanto diferente. ¿Pero qué ocurre si persiste un enfoque sin disciplina respecto al desarrollo Web? En ausencia de un proceso disciplinado dirigido a desarrollar sistemas basados en Web, existe una creciente preocupación de que se enfrenten serios problemas en su desarrollo, despliegue y mantenimiento exitosos. En esencia, la infraestructura de aplicación que se está creando en la actualidad puede conducir a una "Web enmarañada" conforme se adentra m á s este nuevo siglo. Esta frase entraña un cúmulo de aplicaciones basadas en Web mal desarrolladas y que tienen muy altas probabilidades de fracaso. Peor aún, conforme los sistemas basados en Web crecen con mayor complejidad, una falla en uno puede propagar y propagará amplios problemas por medio de muchos. Cuando esto ocurra, la confianza en toda la Internet será sacudida. Peor aún, podría conducir a una regulación gubernamental innecesaria y mal concebida, lo que provocará un daño irreparable a estas tecnologías únicas. Para evitar una Web enmarañada y lograr mayor éxito en el desarrollo y la aplicación de sistemas basados en Web complejos y a gran escala, existe una apremiante necesidad de enfoques disciplinados y nuevos métodos y herramientas con que desarrollar, desplegar y evaluar los sistemas y aplicaciones basados TMen Web. Tales enfoques y técnicas deben considerar las características especiales de los nuevos medios, los ambientes y escenarios operativos, y la multiplicidad de perfiles de usuario que colocan desafíos adicionales al desarrollo de aplicaciones basadas en Web.

PDF Editor

La ingeniería Web (IWeb) aplica "sólidos principios científicos, de ingeniería y de administración, y enfoques disciplinados y sistemáticos para el desarrollo, despliegue y mantenimiento exitosos de sistemas y aplicaciones basados en Web de alta calidad" [MUR99J.

504

PARTE TRES

16.1

APLICACIÓN DE LA INGENIERÍA WEB

ATRIBUTOS PE LOS SISTEMAS Y APLICACIONES BASADOS EN W E B En los primeros días de la World Wide Web (área 1990 a 1995) los "sitios Web" consistían en poco más de un conjunto de archivos de hipertexto ligados que presentaban información mediante texto y gráficos limitados. Conforme el tiempo pasó, el HTML a u m e n t ó al desarrollar herramientas (por ejemplo, XML, Java) que permitieron a los ingenieros Web ofrecer capacidades de cálculo junto con información. Nacieron los sistemas y aplicaciones 1 basados en Web (se les referirá de manera colectiva c o m o WebApps). En la actualidad, las WebApps han evolucionado en sofisticadas herramientas de computación que no sólo proporcionan función por sí misma; al usuario final, sino que también se han integrado con bases de datos corporativa; y aplicaciones de negocios. "En el momento en que veamos cierto especie de estabilización, la Web se habrá convertido en algo completamente diferente." Louis Monier Existe poco debate en cuanto a que las WebApps son diferentes a las mucha; otras categorías de software informático analizadas en el capítulo 1. Powell resuma las diferencias principales cuando establece que los sistemas basados en Web "inv lucran una mezcla entre publicación impresa y desarrollo de software, entre marketing e informática, entre comunicaciones internas y relaciones externas, y entre ar-J te y tecnología" [POW98J. En la gran mayoría de las WebApps s e encuentran los seguientes atributos.

^CONSEJO^ Se puede argumenta/ que uno aplicación tradicional dentro de cualquiera de los dominios de software trotados en el capítulo 1 puede mostrar esta lista de atributos. Sin embargo, las WebApps casi siempre lo hacen.

I n t e n s i d a d d e r e d . Una WebApp reside en una red y debe satisfacer las neces-j dades d e una variada comunidad de clientes. Una WebApp puede residir en la Inte-J net (y, en consecuencia, permitir una comunicación mundial abierta). Alternativa] mente, una aplicación puede colocarse en una Intranet (lo que implementa la com nicación en una organización) o en una Extranet (comunicación inter-red). C o n c u r r e n c i a . Un gran número d e usuarios puede tener acceso a la WebApp al mismo tiempo. En muchos casos, los patrones de uso entre los usuarios finales YM riarán enormemente. C a r g a i m p r e d e c i b l e . El n ú m e r o de usuarios de la WebApp puede variar en cr-l denes de magnitud de día con día. El lunes pueden mostrarse 100 usuarios; el mar! TM tes pueden usar el sistema 10 000.

PDF Editor 1

En el contexto de este capítulo, el término "aplicación Web" (WebApp) abarca todo, desde una

pie página Web que puede ayudar al consumidor a calcular el pago de arrendamiento de un ssm móvil, hasta un amplio sitio Web que proporcione servicios de viaje completos para gente I negocios y vacacionistas. Dentro de esta categoría se incluyen los sitios Web completos, la t u r c a nalidad especializada dentro de los sitios Web y las aplicaciones de procesamiento de informar-J que residen en la Internet o en una Intranet o Extranet.

CAPÍTULO 16

INGENIERÍA WEB

505

D e s e m p e ñ o . Si un usuario de WebApp debe esperar demasiado (para ingresar, para procesamiento en el lado del servidor, para formateo y despliegue en el lado del cliente) puede decidir irse a cualquier otra parte. D i s p o n i b i l i d a d . Aunque la expectativa de una disponibilidad del total e s poco razonable, los usuarios de las WebApps populares con frecuencia d e m a n d a n acceso sobre una base de "24/7/365". Los usuarios en Australia o Asia pueden demandar acceso durante momentos cuando las tradicionales aplicaciones de software doméstico en Norteamérica pueden estar fuera de línea por mantenimiento. G o b e r n a d a p o r l o s d a t o s . La función primordial de m u c h a s WebApps es usar hipermedia para presentar contenido de texto, gráficos, audio y video al usuario final. Además, por lo general, las WebApps se utilizan para tener acceso a información que existe en bases de datos que originalmente n o eran parte integral del ambiente basado en Web (por ejemplo, comercio electrónico o aplicaciones financieras). S e n s i b i l i d a d al c o n t e n i d o . La calidad y naturaleza estética del contenido sigue siendo un importante determinante de la calidad de una WebApp. E v o l u c i ó n c o n t i n u a . A diferencia del software de aplicación convencional, que evoluciona a lo largo de una serie de planeadas liberaciones espaciadas cronológicamente, las aplicaciones Web evolucionan de manera continua. No e s raro que algunas WebApps (específicamente, su contenido) se actualicen sobre una agenda minuto a minuto, o que el contenido sea calculado de manera independiente para cada solicitud. Algunos argumentan que la evolución continua de las WebApps hace que el trabajo realizado sobre ellas sea análogo a la jardinería. Lowe [LOW991 comenta esto cuando escribe: La ingeniería trata de a d o p t a r u n e n f o q u e c o n s i s t e n t e y científico, s u a v i z a d o por un c o n texto práctico específico, p a r a el desarrollo y c o m i s i o n a d o d e s i s t e m a s o aplicaciones. Con frecuencia, el desarrollo de sitios W e b s e relaciona m u c h o con la creación de u n a infraestructura (sembrar el jardín) y luego c o n "cultivar" la información q u e crece y r e t o ñ a dentro de este jardín. A lo largo del tiempo, el jardín (es decir, el sitio Web) c o n t i n u a r á e v o l u c i o n a n d o , c a m b i a n d o y creciendo. Una b u e n a arquitectura inicial d e b e permitir q u e e s t e crecimiento ocurra e n u n a f o r m a controlada y c o n s i s t e n t e . . .

El cuidado continuo y la alimentación permiten que un sitio Web crezca (en robustez e importancia). Pero, a diferencia del jardín, las aplicaciones Web deben satisfacer (y adaptarse a) las necesidades de alguien más que el jardinero. TM I n m e d i a t e z . Aunque la inmediatez —la apremiante necesidad de poner software en el mercado rápidamente— es una característica de muchos dominios de aplicación, las WebApps con frecuencia muestran un tiempo para comercializar que puede ser cuestión de unos cuantos días o semanas. 2 Los ingenieros Web deben aplicar

PDF Editor 2

Con las herramientas modernas se pueden producir elaboradas páginas Web en cuestión de unas

cuantas horas.

506

PARTE TRES


métodos de planeación, análisis, diseño, implementación y puesta a prueba que han sido adaptados a los apretados tiempos requeridos para el desarrollo de WebApps S e g u r i d a d . Puesto que las WebApps están disponibles mediante el acceso a la red, e s difícil, si no imposible, limitar la población de usuarios finales que pueden tener acceso a la aplicación. Con la finalidad de proteger el contenido confidencial y ofrecer modos seguros de transmisión de datos, se deben implementar fuertes medidas de seguridad a lo largo de la infraestructura que sustenta una WebApp y dentro de la aplicación misma. E s t é t i c a . Una parte innegable de la apariencia de una WebApp es su presentación y la disposición de sus elementos. Cuando una aplicación se diseña para comercializar o vender productos o ideas, la estética puede tener tanto que ver con el éxí to como el diseño técnico. Estos atributos generales se aplican a todas las WebApps, pero con diferentes gra dos de influencia. ¿Pero qué hay de las WebApps por ellas mismas? ¿Qué problemas abordan? En e trabajo IWeb es usual encontrar las siguientes categorías de aplicaciones [DAR99]. ¿Qué catego• rías de WebApps se encuentran

• Informativo: se proporciona contenido de sólo lectura con navegación y enlaees simples.

en el trabajo

*

Descar§a- u n

•Web?

• Personalizare: pecíficas.

usuario descarga información del servidor apropiado. el usuario personaliza el contenido según sus necesidades es-

• Interacción: la comunicación entre una comunidad de usuarios ocurre por medio de cuartos de charla, tableros de anuncios o mensajería instantánea. • Entrada del usuario: la entrada con base en formularios es el principal mecanismo para las necesidades de comunicación. • Orientada a transacciones: el usuario hace una solicitud (por ejemplo, realiza un pedido) que ejecuta la WebApp. • Orientada a servicios: la aplicación proporciona un servicio al usuario; por ejemplo, lo asesora en la determinación del pago de una hipoteca. • Portal: la aplicación canaliza al usuario hacia otro contenido o servicios Web fuera del dominio del portal de la aplicación. • Acceso a una base de datos: el usuario consulta una gran base de datos y exTM trae información. • Almacén de datos: el usuario consulta una colección de grandes bases de datos y extrae información.

PDF Editor

Los atributos comentados en esta sección, y las categorías de aplicación destacadas líneas arriba, representan importantes hechos de vida para los ingenieros Web La clave es vivir dentro de las restricciones que imponen dichos atributos y aun as: producir una WebApp exitosa.

CAPÍTULO 16

Í6.2

507

INGENIERÍA WEB

E S T R A T O S P E LA I H S E N I E R Í A m

WEBAPP

El desarrollo de sistemas y aplicaciones basados en Web incorpora modelos de proceso especializados, métodos de ingeniería del software adaptados a las características del desarrollo de WebApps y un conjunto de importantes tecnologías habilitadoras. Los procesos, métodos y tecnologías (herramientas) proporcionan un enfoque en estratos de la IWeb que es conceptualmente idéntico a los estratos de la ingeniería del software descritos en la figura 2.1. "La ingeniería Web trata can enfoques disciplinados y sistemáticos para el desarrollo, despliegue y mantenimiento de los sistemas y aplicaciones basados en Web."

»

[CONSEJO.

ebcon i es ágil y ¡esincre' Sin embargo, i que el modelo i k puede elegirse : c mayoría de los s de inge-

16.2.1 Proceso Los modelos de procesos IWeb (que se tratan con detalle en la sección 16.3) adoptan la filosofía del desarrollo ágil (capítulo 4). El desarrollo ágil enfatiza un enfoque de desarrollo riguroso que incorpora rápidos ciclos de desarrollo. Aoyama [AOY98] describe la motivación para el enfoque ágil en la siguiente forma: Internet c a m b i ó la prioridad principal del desarrollo d e s o f t w a r e de qué a cuándo. El reducido tiempo para el m e r c a d o s e h a c o n v e r t i d o e n el límite competitivo por el q u e luchan las c o m p a ñ í a s líderes. En c o n s e c u e n c i a , reducir el ciclo d e desarrollo e s a h o r a una de las m i s i o n e s m á s i m p o r t a n t e s d e la ingeniería del s o f t w a r e .

• m .

Aun cuando rápidos ciclos d e tiempo dominan la reflexión acerca del desarrollo, es importante reconocer que el problema todavía debe analizarse, debe desarrollarse un diseño, la implementación debe proceder en una forma incremental y se debe iniciar un enfoque organizado de prueba. Sin embargo, dichas actividades del marco de trabajo se deben definir dentro de un proceso que 1) adopte el cambio, 2) aliente la creatividad y la independencia del equipo de desarrollo y fortalezca la interacción con los accionistas de la WebApp, 3) construya sistemas que utilicen pequeños equipos de desarrollo, y 4) subraye el desarrollo evolutivo o incremental mediante el uso de cortos ciclos de desarrollo [MCD01],

16.2.2 Métodos El panorama de los métodos de IWeb abarca un conjunto de labores técnicas que permiten al ingeniero Web comprender, caracterizar y luego construir una WebApp de alta calidad. Los métodos de IWeb (que se tratan con detalle en TMlos capítulos 18 al 20) se pueden categorizar de la siguiente manera:

M é t o d o s d e c o m u n i c a c i ó n : definen el enfoque con que se facilita la comunicación entre ingenieros Web y los d e m á s participantes de la WebApp (por ejemplo, usuarios finales, clientes de negocios, expertos en problemas de dominio, diseñadores de contenido, líderes de equipo, gestores d e proyecto). Las técnicas de comunicación

PDF Editor

son particularmente importantes durante la recolección de requisitos y siempre que sea evaluado un incremento en la WebApp

508

PARTE TRES

ÔNSEJO^ Es importante notar que muchos métodos IWeb se han adoptado directamente de sus contrapartes de ingeniería del software. Otros están en sus etapas lormativos. Algunos de estos sobrevivirán; otros serán descartados conforme se sugieran mejores enfogues.


M é t o d o s d e a n á l i s i s d e r e q u i s i t o s : proporcionan u n a b a s e para comprender el contenido que entregará una WebApp, la función que proporcionará al usuario final y los modos de interacción que cada clase de usuario requerirá mientras ocurra la navegación por medio de la WebApp. M é t o d o s d e d i s e ñ o : abarcan una serie de técnicas de diseño que abordan e. contenido, la aplicación y la arquitectura de información, así c o m o el diseño de interfase y la estructura de navegación de la WebApp. M é t o d o s d e p r u e b a : incorporan revisiones técnicas formales —tanto del conté- j nido y el modelo de diseño c o m o de una amplia variedad de técnicas de prueba que abordan conflictos al nivel de componente y arquitectónicos—, pruebas de la navegación, pruebas de facilidad de uso, pruebas de seguridad y pruebas de configuración, j Es importante señalar que, aunque los métodos IWeb adoptan muchos de los mism o s conceptos y principios subyacentes a los métodos de ingeniería del software descritos en la parte 2 de este libro, los mecanismos de análisis, diseño y prueba deben adaptarse para acomodar las características especiales de las WebApps. Además de los métodos técnicos que se han subrayado, es esencial una serie ce actividades sombrilla (con métodos asociados) para la ingeniería Web exitosa. Ésía incluye técnicas de gestión de proyecto (por ejemplo, estimación, calendarizacicr\j análisis de riesgo), técnicas de gestión de configuración de software y de revisión

16.2.3 Herramientas y tecnología Se encuentran excelentes recutsos pora tecnología IWeb en webdeveloper. lom y en www. eborcom.com/ webmaker.

A lo largo de la década pasada ha evolucionado un amplio conjunto de herramientas y tecnología conforme las WebApps se han vuelto m á s complejas y extendidas Dichas tecnologías abarcan un amplio conjunto de descripción de contenido y lenguajes de modelación (por ejemplo, HTML, VRML, XML), lenguajes de programación (por ejemplo, Java), recursos de desarrollo basados en componentes (por ejempl: CORBA, COM, ActiveX, .NET), navegadores, herramientas multimedia, herramientas de autoría de sitio, herramientas de conectividad de b a s e s de datos, herramientas oe seguridad, servidores y utilidades de servidor, y herramientas de administración 11 análisis de sitio. Un tratamiento completo de las herramientas y tecnología para la ingeniería Web s está m á s allá del ámbito de este libro. El lector interesado p u e d e visitar uno o mas de los siguientes sitios Web: Web Developer's Virtual Encyclopedia (www.wdlv.corr. TM WebDeveloper (www.webdeveloper.com), Developer Shed (www.devshed.com), Web-1 knowhow.net

(www.webknowhow.net) o WebReference (www.webreference.com).

PDF Editor 16.3

EL PRQCESQ PE INGENIERÍA W E B

Los atributos de los sistemas y aplicaciones basados en Web tienen una profunda influencia sobre el proceso de IWeb que se elija. En el capítulo 3 se hizo notar que ual ingeniero de software elige un modelo de proceso basado en los atributos del soñ-|

CAPÍTULO 16

INGENIERÍA WEB

509

ware que habrá de desarrollarse. Esta premisa también es cierta para un ingeniero Web. Si la inmediatez y la evolución continua son atributos principales de una WebApp, un equipo de ingeniería Web debe elegir un modelo de proceso ágil (capítulo 4) que produzca liberaciones de WebApp a un ritmo vertiginoso. Por otra parte, si una WebApp será desarrollada durante un largo periodo (por ejemplo, una gran aplicación de comercio electrónico) puede elegirse un modelo de proceso incremental (capítulo 3).

"El desarrollo Web es un adolescente... al igual que lo mayoría de los adolescentes, quiere ser aceptado como un adulto conforme intenta alejarse de sus padres. Si quiere alcanzar todo su potencial, debe tomar unas cuantas lecciones del más experimentado mundo del desarrollo de software." Doug Wnlloce el al.

La intensa naturaleza de las aplicaciones de la red en este dominio sugiere una diversa población de usuarios (que, por lo tanto, realizan demandas especiales acerca de respuesta y modelado de requisitos) y una arquitectura de aplicación que puede ser altamente especializada (que en consecuencia realiza d e m a n d a s acerca del diseño). Puesto que con frecuencia las WebApps son conductoras d e contenido, con énfasis en la estética, es probable que se proyecten actividades de desarrollo paralelas dentro del proceso IWeb e involucren un equipo de personal tanto técnico como lego (por ejemplo, publicistas, diseñadores gráficos).

16.3.1 Definición del marco d e trabajo Cualquiera de los modelos de proceso ágil (por ejemplo, Programación Extrema, Desarrollo de Software Adaptativo, SCRUM) presentados en el capítulo 4 se pueden aplicar de manera exitosa c o m o un proceso IWeb. El marco de trabajo del proceso que se presenta aquí es una amalgama de los principios e ideas tratados en dicho capitulo. La efectividad de cualquier proceso de ingeniería depende de su adaptabilidad. Esto es, la organización del equipo de proyecto, los modos de comunicación entre miembros del equipo, las actividades de ingeniería y las tareas que deben realizarse, la información que se recolecte y cree, y los métodos empleados para producir un producto de alta calidad deben estar adaptados a la gente que realiza el trabajo, el plazo y las restricciones del proyecto, y al problema que se quiere resolver. Antes de TM definir un marco de trabajo de proceso para IWeb se debe reconocer que: V E x proceso f p o n e en •; entrego , cambio y plazos

1. Las WebApps con frecuencia se entregan de manera incremental. Esto es, las actividades del marco de trabajo ocurrirán de manera repetida conforme cada incremento se someta a ingeniería y se entregue.

PDF Editor 2.

Los cambios ocurrirán frecuentemente Estos cambios pueden ocurrir como resultado de la evaluación de un incremento entregado o como consecuencia de cambiar las condiciones de los negocios.

510

P A R T E TRES


3 . Los plazos son cortos. Esto aminora la creación y revisión de voluminosa documentación de ingeniería, p e r o n o excluye la simple realidad de q u e el análisis crítico, el diseño y la prueba deben registrarse en alguna forma. Además, se deben aplicar los principios definidos c o m o parte del "Manifiesto para el desarrollo de s o f t w a r e ágil" (capítulo 4). Sin e m b a r g o , los principios no son los die; m a n d a m i e n t o s . A veces e s razonable adoptar el espíritu de dichos principios sin que sea necesario a t e n e r s e a la letra del manifiesto. Con e s t o s conflictos e n m e n t e s e aborda el proceso de IWeb dentro del proces: genérico de m a r c o de trabajo p r e s e n t a d o en el capítulo 2.

% CLAVE El modelo de proceso genérico (introducido en el capitulo 2) es aplicable a la ingeniería Web.

C o m u n i c a c i ó n c o n e l c l i e n t e . Dentro del proceso IWeb la comunicación con e¿ cliente se caracteriza por medio de dos g r a n d e s tareas: el análisis del negocio y formulación. El análisis del negocio define el contexto empresarial-organizativo ] la WebApp. Además, se identifican los participantes, se predicen los potenci c a m b i o s en el ambiente o los requisitos del negocio, y se define la integración en la WebApp y otras aplicaciones de negocios, b a s e s de d a t o s y funciones. La forrr. ¡ación e s u n a actividad de recopilación de requisitos q u e involucra a t o d o s los p cipantes. El intento e s describir el problema que la WebApp habrá de resolver (j con los requisitos básicos para la WebApp) con el a p r o v e c h a m i e n t o de la mejor formación disponible. Además, se intenta identificar á r e a s de incertidumbre y de ocurrirán c a m b i o s potenciales. P l a n e a c i ó n . Se crea el plan del proyecto para el incremento de la WebApp. plan consiste de u n a definición de tareas y un calendario de plazos respecto al riodo (usualmente medido en s e m a n a s ) proyectado para el desarrollo del incre to de la WebApp. M o d e l a d o . Las labores convencionales de análisis y diseño de ingeniería software se a d a p t a n al desarrollo de la WebApp, se m e z c l a n y luego se funden en actividad de m o d e l a d o IWeb (capítulos 18 y 19). El intento e s desarrollar análisis pidos" y modelos de diseño q u e definan requisitos y al m i s m o tiempo represen u n a WebApp que los satisfará. C o n s t r u c c i ó n . Las h e r r a m i e n t a s y la tecnología IWeb se aplican para construir WebApp que se ha modelado. Una vez que se construye el in c r e m e n to de Web/ se dirige u n a serie d e pruebas rápidas para a s e g u r a r que se descubran los errores el d i s e ñ o (es decir: contenido, arquitectura, interfase, navegación). Pruebas adi TM nales a b o r d a n otras características WebApp. D e s p l i e g u e . La WebApp se configura para su a m b i e n t e operativo, s e entrega

PDF Editor

los usuarios finales y luego c o m i e n z a un periodo de evaluación. La retroalime ción acerca de la evaluación se presenta al equipo d e IWeb y el incremento se difica c o n f o r m e s e requiera.

Estas cinco actividades del m a r c o de trabajo IWeb se aplican e m p l e a n d o un

de proceso incremental, c o m o s e muestra en la figura 16.1.

CAPÍTULO 16

511

INGENIERÍA WEB

Prueba d e a c e p t a c i ó n Uso del consumidor Evaluación del consumidor

Codificación Prueba d e c o m p o n e n t e s

Liberació

Modelo de diseñe Contenido Análisis del n e g o c i o

M o d e l o d e análisis

Formulación Plan d e iteración

Contenido Iteración

Arquitectura Navegación Interfaz

Función Configuración

INFORMACIÓN

Ingeniería Web: preguntas básicas La ingeniería de cualquier producto involucra sutique no advierten inmediatamente quienes carecen de ia sustancial. Las características de las WebApps a los ingenieros Web a responder una diversidad preguntas que deben abordarse durante las primeras es del marco de trabajo. Las preguntas estratégirelacionadas con las necesidades del negocio y los os del producto, se tratan durante la formulación, oreguntas acerca de los requisitos, relacionadas con características y funciones, deben considerarse durante análisis de modelado. Las preguntas específicas de disebase, relacionadas con la arquitectura de la WebApp, características de la interfaz y los conflictos de navega, se consideran conforme evoluciona el modelo de d¡tro. Finalmente, un conjunto de conflictos humanos, r a c i o n a d o s con la forma en la que un usuario realmente r«ractúa con la WebApp, se abordan en forma continua. Susan Weinshenk [WEI02] sugiere un conjunto de preguns que se deben considerar conforme progresan el análisis y el 3 seño. Aquí se anota un pequeño subconjunto (adaptado): ¿Cuán importante es la página de inicio (home page) de un sitio Web? ¿Debe contener información útil o una simple lista de enlaces que conduzcan al usuario a mayores detalles en niveles inferiores?

• ¿Qué opciones de medios audiovisuales tienen más impacto? ¿Los gráficos son más efectivos que el texto? ¿El video (o el audio) es una opción efectiva? ¿Cuándo se deben elegir varias opciones de medios audiovisuales? • ¿Cuánto trabajo se puede esperar que realice un usuario cuando busca información? ¿Cuántos clics desea hacer la gente? • ¿Cuán importantes son los auxiliares de navegación cuando las WebApps son complejas? • ¿Cuán complejas pueden ser las entradas de formulario antes de que se vuelvan irritantes para el usuario? ¿Cómo se pueden expedir las entradas d e formulario? • ¿Cuán importantes son las capacidades de búsqueda? ¿Qué porcentaje de usuarios navega y qué porcentaje usa búsquedas específicas? ¿Cuán importante es estructurar c a d a página en una forma que suponga un enlace desde alguna fuente externa? • ¿La WebApp se diseñará en una forma que sea accesiTM ble a quienes tengan discapacidades físicas o de algún otro tipo?

PDF Editor ¿Cuál es la plantilla de página más efectiva (por ejemplo, menú arriba, a la derecha, a la izquierda) y ésta variará según el tipo de WebApp que se desarrollará?

N o existen respuestas absolutas a preguntas como éstas, e incluso
PARTE TRES

512


16.3.2 Refinamiento del marco de trabajo Ya se ha advertido q u e el modelo del proceso IWeb debe ser adaptable. Esto es, la definición de las tareas d e ingeniería requeridas para retinar cada actividad del marco de trabajo se dejan a discrecional juicio del equipo de ingeniería Web. En algunos casos, una actividad del marco de trabajo se dirige de manera informal; en otros, se definirá una serie de distintas tareas y las dirigirán miembros del equipo. En todo caso, el equipo es responsable de producir un incremento WebApp de alta calidad dentro del periodo acordado. Es importante destacar que las tareas asociadas con las actividades del marco de trabajo IWeb pueden modificarse, eliminarse o extenderse con base en las características del problema, el producto, el proyecto y la gente en el equipo de ingeniería Web "Existen algunos de nosotros que creen que los mejores prácticas para el desarrollo de software son prácticas y merecen ímplementación. Y luego existen algunos de nosotros que creen que las mejores prácticas son interesantes en ciei ta formo académica, mas no lo son para el mundo real, muchas gracias." Warren Keuffel

16.4

M E J O B E S P R Á C T I C A S EN INGENIERÍA W E B ¿Todo desarrollador de WebApp utilizará el m a r c o de trabajo y el conjunto de tareas del proceso IWeb definido en la sección 16.3? Probablemente no. En ocasiones, las equipos de ingeniería Web están sometidos a enorme presión respecto del tiempc rj tratarán de tomar atajos (incluso si éstos son imprudentes e implican más esfuerza de desarrollo, en lugar de menos). Pero se d e b e aplicar un conjunto fundamental i r mejores prácticas —adoptado de las prácticas de ingeniería del software tratadas ¿ lo largo de la Parte 2 de este libro— si se han de construir WebApps con calidad industrial. 1. Tomar tiempo para entender las necesidades del negocio y los objetivos del producto, incluso si los detalles de la WebApp son vagos. Muchos desarrolladores de WebApps creen e r r ó n e a m e n t e que los requisitos vagos (que son bastante I comunes) los liberan de la necesidad de asegurarse d e q u e el sistema que e s - 1 tán a punto de someter a ingeniería tenga un propósito empresarial legítimo El resultado final es (también con frecuencia) un buen trabajo técnico que c o o l duce a la construcción del sistema equivocado por las razones equivocadas

^CONSEJOÂsegúrese de que alguien hoyo enunciado ion claridad los necesidades del negocio pato una WebApp. Si n es así, el proyecto

para el público equivocado. Si los accionistas n o pueden enunciar una neces - 1 TM dad empresarial para la WebApp, debe procederse con extrema precaución. S I los accionistas luchan por identificar un conjunto de objetivos claros para el

PDF Editor élWebestáen

producto (WebApp), no debe procederse mientras ellos n o concluyan.

2 . Describir cómo interactuarán los usuarios con la WebApp aplicando un enfoque I basado en escenarios. Se d e b e convencer a los accionistas para desarrollar c ¿ - | s o s de uso (tratados a lo largo de la Parte 2 d e este libro) para reflejar cómo | los diversos actores interactuarán con la WebApp. Entonces se pueden aprc- I

C A P Í T U L O 16

513

INGENIERÍA WEB

vechar dichos escenarios 1) para la planeación y el rastreo del proyecto, 2) para guiar el análisis y el modelado del diseño, y 3) c o m o una entrada importante para el diseño de pruebas. 3 . Desarrollar un plan del proyecto, incluso si es muy breve. El plan debe basarse en un proceso de marco de trabajo predefinido aceptable para todos los participantes. Puesto que los plazos del proyecto son muy cortos, la dosificación del programa debe ser exacta; es decir, en muchas instancias el proyecto debe planearse y rastrearse diariamente. 4 . Utilizar algún tiempo para modelar lo que se construirá. Por lo general, el análisis total y los modelos d e diseño n o s e desarrollan durante la ingeniería Web. Sin embargo, la clase UMLy los diagramas de secuencia, junto con otra notación UML seleccionada (por ejemplo, diagramas de estado), pueden proporcionar una visión invaluable. 5 . Revisar la consistencia y calidad de los modelos. Las revisiones técnicas formales (capítulo 26) se deben dirigir a lo largo del proyecto IWeb. El tiempo empleado en las revisiones paga importantes dividendos porque usualmente elimina reelaboraciones y resulta en una WebApp q u e exhibe alta calidad, lo que aumenta la satisfacción del cliente. 6.

Utilizar herramientas y tecnología que permitan construir el sistema con tantos componentes

reutilizables como sea posible. Un amplio conjunto d e herramien-

tas WebApp están a disposición virtualmente para cada aspecto de la construcción WebApp. Muchas de dichas herramientas permiten q u e un ingeniero Web construya porciones significativas d e la aplicación empleando componentes reutilizables. 7.

No apoyarse en usuarios anteriores para depurar la WebApp; diséñense pruebas amplias y ejecútense antes de liberar el sistema. Los usuarios de una WebApp con frecuencia le dan una oportunidad. Si falla en su ejecución se mueven a cualquiera otra parte: nunca regresan. Por esta razón, el "pruebe primero, después despliegue" debe ser un sistema primordial, incluso si los plazos s e deben prolongar.

INFORMACIÓN

Criterios de calidad/directrices

para WebApps

La IWeb se esfuerzo en la producción de de alta calidad. Pero, en este contexto, ¿qué es y qué directrices están disponibles para lograrla? i artículo acerca de aseguramiento de la calidad en siWeb, Quibeldey-Cirkel [QUI01 ] sugiere un amplio -to de recursos en línea que abordan estos conflictos:

TM

W3C: guía de estilo para hipertexto en línea www.w3.org/Provider/Style La Guía Sevioid para el diseño Web www.sev.com.au/webzone/design/guide.asp Páginas Web que Apestan www.webpagestfiatsuck.com/index.html

PDF Editor

Y

514

PARTE TEES


Recursos acerca de estilo Web www.westegg.com/unmaintained/bodpoges Herramienta de evaluación Web de Gartner www.gartner.com/ebusiness/website-ings IBM Corp: directrices Web www-3.ibm.com/ibm/easy/eou_ext.nsf/Publish/572 Facilidad de uso en la World Wide Web ijhcs.open.ac.uk Interfaz Salón de la Vergüenza www.iarchitect.com/mshame.htm El arte y el zen de los sitios Web www. tic -systems.com/webtips. shtml Diseño para la Web: estudios empíricos www.microsoft.com/usability/webconf.htm useit.com de Nielsen www.useit.com

Calidad de experiencia www.qualityofexperience.org Creación de sitios Web asesinos www.killersites.com/core.html Todas las cosas en la Web www.pantos.org/atw Nuevo diseño Web de SUN www.sun.com/980113/sunonnet Tognazzini, Bruce: homepage www.asktog.com Webmonkey hotwi red.lycos.com/webmonkey/design/?tw=design Los mejores sitios Web del mundo www.worldbestwebsites.com Yale University: guia de estilo Web de Yale info.med.yale.edu/caim/manual >

Es posible argumentar que el impacto de los sistemas y aplicaciones basados en Wer e s el suceso más significativo en la historia de la computación. Conforme la impo: tancia de las WebApps crece ha c o m e n z a d o a evolucionar un enfoque IWeb discipl nado (adaptado de los principios, conceptos, procesos y métodos de la ingeniería dt software). Las WebApps son diferentes de otras categorías d e software informático; son em. nentemente de red, las gobiernan los datos y se encuentran en evolución continua La inmediatez que dirige su desarrollo, la necesidad apremiante d e seguridad en s_ operación y la demanda de estética, así como la entrega de contenido funcional, s e - i factores diferenciales adicionales. Al igual que otros tipos de software, las WebApp-5 pueden valorarse mediante una diversidad de criterios de calidad que incluyen fac-l lidad de uso, funcionalidad, confiabilidad, eficiencia, capacidad de mantenimient seguridad, disponibilidad, escalabilidad y tiempo para comercialización. La IWeb s e describe en tres estratos; proceso, métodos y herramientas/tecnolc~| gía. El proceso IWeb adopta el enfoque de desarrollo ágil que subraya un punto ce vista de ingeniería "magro", riguroso, que conduce a la entrega incremental del sisTM tema que será construido. El proceso genérico del marco de trabajo —comunicaciór planeación, modelado, construcción y despliegue— es aplicable a la IWeb. Dichas actividades del marco d e trabajo se refinan en un conjunto de tareas IWeb que se adaptan a las necesidades de cada proyecto. A todos los proyectos IWeb s e les apli-l ca un conjunto de actividades sombrilla similar al aplicado durante el trabajo de in-l

PDF Editor geniería del software: SQA, SCM, gestión del proyecto.

CAPÍTULO 16

INGENIERÍA WEB

515

[AOY98] Aoyama, M„ "Web-Based Agile Software Developnient", en IEEE Computer, n o v i e m b r e diciembre, 1998, pp. 56-65. [DAR99] Dart, s „ "Containing the Web Crisis Using Configuration M a n a g e m e n t " , e n Proc, First ICSE Workshop on Web Engineering, ACM, Los Ángeles, m a y o d e 1999. (The Proceedings ofthe First ¡CSE Workshop on Web Engineering s e publican en linea e n h t t p : / / f i s t s e r v . m a c a r t h u r . uws.edu.au/san/icse99-WebE/lCSE99-WebE-Proc/default.htm). [FOWOl] Fowler, M. y J. Highsmith, "The Agile Manifestó", e n Software Development Magazine. a g o s t o d e 2001, h t t p : / / w w w . s d m a g a z i n e . c o m / d o c u m e n t s / s s 8 4 4 / s d m 0 l 0 8 a / 0 l 0 8 a . h t m . [MCD01) McDonald, A. y R. Welland, Agüe Web Engineering (AWE) Process, D e p a r t m e n t of Computer Science, University of Glasgow, Technical Report TR-2001-98, 2001, se p u e d e descargar d e s d e h t t p : / / w w w . d c s . g l a . a c . u k / ~ a n d r e w / T R - 2 0 0 l - 9 8 . p d f . (MUR99] M u r u g e s a n , S., WebE Home Page, h t t p : / / f i s t s e r v . m a c a r t h u r . u w s . e d u . a u / s a n / W e b E H o m e , julio de 1999. INOR99] Norton, K., "Applying Cross Functional Evolutionary Methodologies to Web Development", e n Proc. First ICSE Workshop on Web Engineering, ACM, Los Ángeles, m a y o de 1999. [POW98] Powell, T. A., Web Site Engineering, Prentice-Hall, 1998. [PRE98] Pressman, R. S. (moderador), "Can Internet-Based Applications Be Engineered?", IEEE Software, s e p t i e m b r e de 1998, pp. 104-110. [QUI01] Quibeldey-Cirkel, K., "Checklist for Web Site Quality Assurance", e n Quality Week Europe, 2001, se p u e d e d e s c a r g a r d e s d e w w w . f b i . f h - d a r m s t a d t . d e / ~ q u i b e l d e y / P r o j e k t e / Q W E 2001 /Paper_Quibeldey_Cirkel.pdf. [WEI02] Weinschenk, S., "Psychology a n d the Web: Designing for People", 2002, h t t p : / / w w w .weinschenk.com/learn/facts.asp.

1 6 . 1 ¿Existen o t r o s atributos genéricos q u e diferencien a las WebApps de las aplicaciones de s o f t w a r e m á s convencionales? Inténtese m e n c i o n a r d o s o tres. 1 6 . 2 ¿Cómo juzga el lector la "calidad" de un sitio Web? H á g a s e u n a lista, en o r d e n d e s c e n d e n t e de prioridad, de 10 atributos de calidad q u e c o n s i d e r e n los m á s importantes. 1 6 . 3 Realizar u n p o c o de investigación y escribir u n articulo d e d o s a tres p á g i n a s q u e r e s u m a una d e las t e c n o l o g í a s a n o t a d a s e n la sección 16.2.3. 1 6 . 4 E m p l e a n d o un sitio Web real c o m o ejemplo, ilustrar las diferentes m a n i f e s t a c i o n e s del "contenido" de la WebApp. 1 6 . 5 Revisar los p r o c e s o s de ingeniería del s o f t w a r e descritos en los capítulos 3 y 4. ¿Existe(n) algún(os) otro(s) proceso(s) -distinto(s) al m o d e l o d e p r o c e s o ágil- q u e pueda(n) ser aplicable(s) a la ingeniería Web? Si la r e s p u e s t a e s afirmativa, indicar cuál(es) proceso(s) y p o r qué. 1 6 . 6 Revisar la exposición del "Manifiesto para desarrollo de s o f t w a r e ágil" p r e s e n t a d o en el TM capítulo 4. ¿Cuál d e los 12 principios funcionaría bien para un proyecto de d o s a ñ o s (que involucra a d o c e n a s d e personas) q u e construirá u n g r a n s i s t e m a d e c o m e r c i o electrónico para u n a c o m p a ñ í a a u t o m o t r i z ? ¿Cuál de los 12 principios funcionaría bien p a r a u n proyecto de d o s m e s e s q u e construirá un sitio informativo para una p e q u e ñ a firma de b i e n e s raíces?

PDF Editor

1 6 . 7 Elaborar u n a lista d e "riesgos" q u e serian p r o b a b l e s d u r a n t e el desarrollo d e u n a nueva aplicación d e comercio electrónico q u e s e diseña para v e n d e r t e l é f o n o s celulares y servicios dir e c t a m e n t e p o r m e d i o d e la Web.

P A R T E TRES


En a ñ o s recientes s e h a n publicado c i e n t o s d e libros q u e a n a l i z a n u n o o m á s t e m a s d e ingeniería Web, a u n q u e r e l a t i v a m e n t e p o c o s a b o r d a n todos los a s p e c t o s de la IWeb. Sarukkai (Foundtions o/Web Technology, Kluwar Academic Publishers, 2002) p r e s e n t a una valiosa compiladorde t e c n o l o g í a s q u e s e requieren para la IWeb. M u r u g u s a n y D e s h p a n d e (Wef> Engineering: M; naging Diversity and Complexity of Web Development, Springer-Verlag, 2001) h a n e d i t a d o u n a c: lección d e útiles artículos a c e r c a d e IWeb. Las a c t a s d e c o n f e r e n c i a s i n t e r n a c i o n a l e s acerca a e ingeniería Web y d e ingeniería de s i s t e m a s d e información Web las publica a n u a l m e n t e el IEEE C o m p u t e r Society Press. Flor (Web Business Engineering, Addison-Wesley, 2000) analiza el análisis d e n e g o c i o s y las p r e o c u p a c i o n e s r e l a c i o n a d a s q u e p e r m i t e n al ingeniero Web c o m p r e n d e r mejor las necesidades de los clientes. Bean (Engineering Global E-commerce Sites, Morgan K a u f m a n , 2003) p r e s e n t a c rectrices p a r a el desarrollo de WebApps globales. Lowe y Hall (Hypermedia and the Web: An gineering Approach, Wiley, 1999) y Powell [POW98] o f r e c e n u n a c o b e r t u r a r a z o n a b l e m e n t e c pleta. U m a r (Application Re engineering: Building Web-Based Applications and Dealing with Le Systems, Prentice-Hall, 1997) a b o r d a u n o d e los m á s difíciles conflictos e n la IWeb: la reinge ría d e los s i s t e m a s h e r e d a d o s p a r a h a c e r l o s c o m p a t i b l e s con los s i s t e m a s b a s a d o s e n Web. I Std. 2001-1999 d e f i n e prácticas b á s i c a s d e IWeb. Erí Internet hay disponible una g r a n variedad d e f u e n t e s de información acerca d e ingei ría Web. En el sitio Web d e SEPA s e p u e d e e n c o n t r a r u n a lista actualizada d e referencias e n World Wide Web q u e s o n relevantes para la ingeniería Web:


TM

PDF Editor

C A P I T U L O

17

FORMULACIÓN Y PLANEACIÓN PARA I N G E N I E R Í A W E B

D

urante la tempestuosa década de 1990, el boom de la Internet generó m á s arrogancia q u e cualquier otro evento en la historia de las computadoras Los desarrolladores de WebApps en cientos de jóvenes compañías puntocom argumentaban que había surgido un nuevo paradigma para el desarrollo de software, que las viejas reglas ya no s e aplicarían más, que el tiempo para el merc a d o dominaba todas las d e m á s preocupaciones. Se rieron de la noción de que la formulación y la planeación cuidadosas debían ocurrir antes de que c o m e n z a r a la construcción. ¿Y quién podía rebatirlos? El dinero estaba en todas partes, los jóvenes de 24 a ñ o s se volvieron multimillonarios (al menos en el papel); tal vez las cosas realmente habían cambiado. Y entonces el suelo se vino abajo. Conforme c o m e n z a b a el siglo xxi e m p e z ó a ser dolorosamente evidente que un enfoque de "construyelo y ellos vendrán" simplemente no funcionaba, que la formulación del problema es esencial para garantizar que una WebApp en verdad es necesaria, y que la planeación vale el esfuerzo, aun cuando el calendario de desarrollo sea apretado. Constantine y Lockwood [CONQ2] advierten esta situación cuando escriben:

K28AS

..523 . . .526 ....530 a c o s a ..533 .520 .536 ..539 -.530 ..519 ..525

A p e s a r d e las d e c l a r a c i o n e s r a d i c a l e s d e q u e la Web r e p r e s e n t a u n n u e v o p a r a d i g m a d e f i n i d o p o r r e g i a s n u e v a s , los d e s a b o l l a d o r e s p r o f e s i o n a l e s s e e s t á n d a n d o c u e n t a

..521

d e q u e l a s l e c c i o n e s a c e r c a del d e s a r r o l l o d e s o f t w a r e , a p r e n d i d a s e n l o s d í a s p r e v i o s

530

al Internet, t o d a v í a se a p l i c a n . Las p á g i n a s W e b s o n i n t e r f a c e s d e u s u a r i o , la p r o g r a m a c i ó n HTML e s p r o g r a m a c i ó n , y las a p l i c a c i o n e s d e s p l e g a d a s en el n a v e g a d o r s o n

..524

s i s t e m a s d e s o f t w a r e q u e p u e d e n b e n e f i c i a r s e d e los p r i n c i p i o s b á s i c o s d e la i n g e n i e ría del s o f t w a r e .

Entre los principios fundamentales de la ingeniería de software destaca el de: comprender el problema antes de comenzar a resolverlo, y estar seguro de que la solución concebida es aquella que la gente realmente quiere. Esta e s la base de la formulación, la primera gran actividad en la ingeniería Web. Otro principio fundamental de la ingeniería de software es: planear el trabajo antes de comenzar a realizarlo. Este e s el enfoque que subyace a la planeación de proyectos.

TM realidad

se c o n o z c a

qué

se

necesita

hacer.

a ! . P o r u n a p a r t e , existe u n a t e n d e n -

A m b o s e n f o q u e s s o n i n a p r o p i a d o s y p o r e l lo l a s

cia a

diferir, a e s p e r a r b a s t a q u e

dos primeras actividades del m a r c o d e t r a b a j o

toda t esté c r u z a d o y toda i tenga p u n t o a n t e s d e q u e c o m i e n c e el tra-

d e la i n g e n i e r í a W e b d e s t a c a n la f o r m u l a c i ó n y

PDF Editor la p l a n e o c i ó n

Lo f o r m u l a c i ó n v a l o r a la n e c e s i -

b a j o . Por o t r a p a r t e , h a y u n d e s e o d e s a l t a r y a ,

d a d s u b y a c e n t e d e la W e b A p p , las c a r a c t e r í s t i

d e c o m e n z a r a c o n s t r u i r incluso a n t e s d e q u e e n

c a s y f u n c i o n e s g l o b a l e s q u e d e s e a n los u s u a r i o s

517

518

P A R T E TRES


y el á m b i t o del e s f u e r z o d e desarrollo. La p l a n e a ción a b o r d o los e l e m e n t o s q u e d e b e n definirse p a r a establecer un flujo d e t r a b a j o y un p r o g r a m a , y a r a s t r e a r el t r a b a j o c o n f o r m e a v a n z a el proyecto.

¿ Q u i é n lo h a c e ? Los ingenieros Web, sus admin i s t r a d o r e s y los p a r t i c i p a n t e s sin funciones técnicas; t o d o s p a r t i c i p a n e n la formulación y la planeación.

¿ P o r q u é e s i m p o r t a n t e ? Es difícil viajar a un lugar q u e n u n c a se h a visitado sin d i r e c c i o n e s o un m a p a . Eventualmente s e llega (o tal vez no), p e r o con s e g u r i d a d el v i a j e s e r á frustrante y l a r g o e n f o r m a i n n e c e s a r i a . La f o r m u l a c i ó n y la p l a n e a c i ó n p r o p o r c i o n a n un m a p a p a r a un e q u i p o d e ingeniería W e b .

¿ C u á l e s s o n los p a s o s a s e g u i r ? La formulación c o m i e n z a al e s t a b l e c e r c o m u n i c a c i ó n con et c o n s u m i d o r (accionista) q u e p l a n t e a las r a z o n e s p a r a la W e b A p p : ¿cuál es la n e c e s i d a d del n e g o c i o , c u á l e s usuarios finales son el objetivo, q u é características y funciones se d e s e a n , q u é sistemas y b a s e s d e d a t o s existentes v a n a tener a c c e s o , el c o n c e p t o es r e a l i z a b l e , c ó m o s e medirá el éxito? La p l a n e a c i ó n e s t a b l e c e un p l a n d e

17.1

t r a b a j o , d e s a r r o l l a e s t i m a c i o n e s p a r a v a l o r a r la factibilidad d e las f e c h a s d e e n t r e g a d e s e a d a s , c o n s i d e r a riesgos, d e f i n e un p r o g r a m a y estab l e c e m e c a n i s m o s p a r a r a s t r e o y control,

¿Cuál e s el p r o d u c t o o b t e n i d o ? Puesto que el t r a b a j o d e ingenierí a W e b con f r e c u e n c i a a d o p ta u n a filosofía ágil, los p r o d u c t o s o b t e n i d o s p a r a la formulación y la p l a n e a c i ó n u s u a l m e n t e son p a r c o s , p e r o existen y d e b e n registrarse e n f o r m a escrita. La recopilación d e información d u r a n t e la formulación se registra en un docum e n t o escrito e n el cual s e b a s a n la p l a n e a c i ó n y el m o d e l a d o d e análisis. El p l a n del proyecto e x t i e n d e el p r o g r a m a d e éste y p r e s e n t a cualquier o t r a i n f o r m a c i ó n q u e s e a n e c e s a r i o comunicar a los m i e m b r o s del e q u i p o d e ingeniería W e b y al p e r s o n a l externo.

¿ C ó m o p u e d o e s t a r s e g u r o d e q u e lo h e h e c h o c o r r e c t a m e n t e ? Es necesario desarrollar c o n suficiente detalle p a r a e s t a b l e c e r un m a p a sólido, p e r o n o tanto c o m o p a r a q u e d a r e m p a n t a n a d o . La información d e la formulación y ta p l a n e a c i ó n d e b e revisarse con los clientes p a r a g a r a n t i z a r q u e las inconsistencias y las omisiones se identifiquen e n una e t a p a t e m p r a n a .

F O R M U L A C I Ó N DE S I S T E M A S B A S A D O S EN W E B La formulación de sistemas y aplicaciones basados en Web representa una secuencia de acciones de ingeniería Web que comienza con la identificación de las necesi dades del negocio, se mueve hacia una descripción de los objetivos de la WebApp define grandes características y funciones y realiza la recopilación de requisitos que conducen al desarrollo de un modelo de anáfisis. La formulación permite que los clientes y el equipo de ingeniería Web establezcan un conjunto común de metas \ objetivos para la construcción de la WebApp. También identifica el ámbito de esfuerzo de desarrollo y proporciona un medio para determinar un resultado éxito TM so. El análisis —una actividad técnica que es una continuación de la formulaciónidentifica los requisitos funcionales, de comportamiento y de datos para la WebApp Antes de considerar la formulación con m á s detalle, es razonable pregunta: dónde termina la formulación y dónde comienza el análisis de requisitos. No existí una respuesta sencilla para esta pregunta. La formulación se enfoca sobre el "grar cuadro": en las necesidades y objetivos del negocio y en la información relacionada Sin embargo, virtualmente es imposible mantener este grado de abstracción. Los clientes y los ingenieros Web quieren definir el contenido requerido, discutir la fun

PDF Editor

CAPITULO 17


519

cionalidad específica, enumerar características específicas e identificar la forma en que los usuarios finales interactuarán con la WebApp. ¿Esto e s formulación o recopilación de requisitos? Ambos es la respuesta.

17.1.1 Preguntas de formulación Powell [POW98] sugiere un conjunto de preguntas que deben formularse y responderse al comienzo de la etapa de formulación: • ¿Cuál e s la principal motivación (necesidades del negocio) para la WebApp? • ¿Cuáles son los objetivos que debe satisfacer la WebApp? • ¿Quién usará la WebApp? La respuesta a cada una de estas simples preguntas debe establecerse tan sucintamente como sea posible. Por ejemplo, supóngase que el fabricante de HogarSe§uro[ ha decidido establecer un sitio Web de comercio electrónico para vender sus productos directamente a los consumidores. Un enunciado que describa la motivación para la WebApp puede ser: HogarSegurolnc.com permitirá a los c o n s u m i d o r e s configurar y c o m p r a r t o d o s los c o m p o n e n t e s requeridos para instalar u n sistema d e administración e n su hogar o e m p r e s a .

I (PTONSEJO^ s comienzo la i del , inténtese birlo WebApp ;pretende uren un solo fe. Si no es , no se están ilas s globales del

Es importante advertir que en este enunciado no se proporcionan detalles. El objetivo aquí e s acotar la intención global de la WebApp y colocarla en un contexto empresarial legítimo. Después de platicar con varios clientes se establece una respuesta a la segunda pregunta: HogarSeguroInc.com n o s permitirá v e n d e r d i r e c t a m e n t e a los c o n s u m i d o r e s , lo q u e elim i n a r á los c o s t o s de intermediación y m e j o r a r á los m á r g e n e s d e utilidad. También n o s permitirá a u m e n t a r las v e n t a s e n un p r o y e c t a d o 2 5 p o r ciento s o b r e las v e n t a s a n u a l e s actuales y p e n e t r a r e n r e g i o n e s g e o g r á f i c a s d o n d e e n la actualidad n o t e n e m o s p u n t o s d e venta.

Finalmente, la compañía define la demografía para la WebApp: "Los usuarios proyectados de HogarSeguroInc.com son los propietarios de viviendas y los dueños de pequeños negocios." Las respuestas establecidas líneas arriba implican metas específicas para el sitio Web d e HogarSeguroInc.com. En general, se identifican dos categorías de metas TM [GNA99]: • Metas informativas: indican una intención de proporcionar contenido información específicos al usuario final.

PDF Editor

• Metas aplicables: indican la habilidad para realizar alguna tarea dentro de la WebApp.

1

El producto HogarSeguro ya se usó como ejemplo a lo largo de las partes I y 2 de este libro

PARTE TRES

520


En el contexto de la WebApp HogarSegurolnc.com, una meta informativa puede ser El sitio p r o p o r c i o n a r á a l o s u s u a r i o s e s p e c i f i c a c i o n e s d e p r o d u c t o d e t a l l a d a s , q u e incluirán descripciones técnicas, instrucciones d e instalación e información d e precios.

El examen d e las respuestas a las preguntas planteadas puede conducir al establecimiento de una meta aplicable: H o g a r S e g u r o l n c . c o m c o n s u l t a r á al u s u a r i o a c e r c a d e la i n s t a l a c i ó n (es decir: c a s a , oficina, e s p a c i o d e v e n t a al m e n u d e o ) q u e s e r á p r o t e g i d a y r e a l i z a r á r e c o m e n d a c i o n e s p e r s o n a l i z a d a s a c e r c a del p r o d u c t o y la c o n f i g u r a c i ó n q u e s e utilizará.

Una vez identificadas todas las metas informativas y aplicables, se desarrolla un perfil de usuario. El perfil de usuario captura "características relevantes relacionadas con los usuarios potenciales, que incluye sus antecedentes, escolaridad, preferencias e incluso más" (GNA99]. En el caso de HogarSegurolnc.com, un perfil de usuario identificaría las características de un comprador típico de sistemas de seguridad (esta información la suministraría el departamento de mercadotecnia). ""Si estás hotkeondo [WebApps], probablemente tu enfoque es 'preparen, fuego, apunten'. Si estás comprometido ton hacerlas funcionar, debe ser 'preparen, apunten, fuego'." Autor desconocido

Una vez que se han desarrollado las m e t a s y perfiles de usuario, la actividad de formulación se enfoca sobre una afirmación del ámbito para la WebApp. En muchos casos, las metas ya desarrolladas s e integran en la afirmación del ámbito. Además, es útil, n o obstante, indicar el grado de integración esperado de la WebApp. Esto es con frecuencia es necesario integrar los sistemas de información existentes (por ejemplo, una aplicación existente d e base de datos) con un planteamiento basado en Web. Los temas de conectividad se consideran en esta etapa.

17.1.2 Recopilación de requisitos p a r a WebApps Los métodos para la recopilación de requisitos se trataron en el capítulo 7. Aunque esta actividad puede abreviarse para la ingeniería Web, los objetivos globales de la recopilación de requisitos propuestos para la ingeniería de software permanecen inalterados. Adaptados para las WebApp, dichos objetivos se convierten en: • Identificar requisitos de contenido. • Identificar requisitos funcionales.

TM

• Definir escenarios de interacción para diferentes clases de usuarios.

PDF Editor

Los siguientes pasos de la recopilación de requisitos s e dirigen para lograr estos

t

¿Qué pasos

de recopila-

rió* de requisitos • se apicaa para

I* WebApps?

objetivos: j_

Pedir a

i o s c i i e n t e s que definan las categorías de usuario y describan cada ca-

tegoria. °

2 . Comunicarse con los clientes para definir los requisitos básicos de la WebApp.

C A P Í T U L O 17


521

3. Analizar la información recopilada y utilizar la información para realizar un seguimiento con los clientes. 4. Definir casos de uso (capítulo 8) que describan escenarios de interacción para cada clase de usuario. Definición d e las c a t e g o r í a s d e u s u a r i o . Se puede argumentar que la complejidad de la WebApp es directamente proporcional al número de categorías de usuario para el sistema. La definición de una categoría de usuario requiere formular un conjunto de preguntas fundamentales: • ¿Cuál es el objetivo global del usuario cuando usa la WebApp? Por ejemplo, un usuario del sitio de comercio electrónico de HogarSeguroInc.com puede estar interesado en recopilar información acerca de productos de administración del hogar. Otro usuario tal vez desee comparar precios. Un tercer usuario quiere comprar el producto HogarSeguro. Cada uno representa una clase o categoría diferente de usuario; cada uno tendrá diferentes necesidades y navegará a través de la WebApp de manera diferente. Un cuarto usuario ya posee HogarSeguro y busca soporte técnico o quiere comprar sensores o accesorios adicionales. • ¿Cuáles son los antecedentes y la pericia del usuario en relación con el contenido y la Juncionalidad de la WebApp? Si un usuario tiene un antecedente técnico y una pericia significativa el contenido o la funcionalidad elementales ofrecerán poco beneficio. De manera alternativa, un neófito demanda contenido y funcionalidad elementales y estaría confundido si se perdiese. • ¿Cómo llegará el usuario a la WebApp? ¿El arribo ocurrirá a través de un enlace desde otro sitio Web (probablemente hacia contenido o funcionalidad dentro de la WebApp), o llegará en una forma m á s controlada? • ¿Qué características genéricas de la WebApps le gustan o disgustan al usuario? Diferentes tipos de usuarios pueden tener distintos y predecibles gustos y aversiones. Vale la pena el intento de determinar si los tienen o no. En muchas situaciones la respuesta se puede averiguar preguntándoles cuáles son sus WebApps favorita y menos favorita. Al aprovechar las respuestas a estas preguntas se debe definir el m á s pequeño conjunto razonable de clases de usuario. Conforme se avanza en la recopilación de requisitos, cada diferente clase de usuario debe encuestarse para obtener datos. TM

PDF Editor Recopilación de requisitos para WebApps El e s c e n a r i o : la oficina de Doug

Los a c t o r e s : Doug Miiler, gerente del equipo de ingeniería del software; Vinod Raman, i

522

P A E T E TRES


equipo d e ingeniería del software HogarSeguro; más tarde, tres personas de mercadotecnia.

La conversación: D o u g : La gerencia ha decidido que construyamos un sitio de comercio electrónico para vender HogarSeguro. V i n o d : |Guau, Doug! No tenemos tiempo para hacer eso... estamos empantanados con el trabajo de software de producto. D o u g : l o sé, lo sé... subcontrafaremos el desarrollo con una compañía especializada en la construcción de sitios de comercio electrónico. Ellos nos dirán que lo tendrán listo y corriendo en menos de un mes... muchos componentes reutilizables. V i n o d : Mmmmm. Bien... ¿entonces por qué estoy aquí? D o u g : Para facilitar las cosos: quieren q u e nos encarguemos de ta recopilación de requisitos para el sitio. Quiero que te entrevistes con los diversos clientes pera comprender, aunque sea en forma mínima, los requisitos básicos.

P e r s o n a d e m e r c a d o t e c n i a # 3 : Yo no soy técnico, pero me preocupan tas elementos especializados que necesitamos elaborar además d e tas factores básicos de comercio electrónico. V i n o d ( e n f r e n t a n d o al # 3 ) : ¿Qué quieres decir? P e r s o n a d e m e r c a d o t e c n i a # 3 : La parte difícil será guiar al usuario a través del "proceso de personalización" en una forma simple y completa. El asunto del comercio electrónico real es bastante directo. P e r s o n a d e m e r c a d o t e c n i a # 1 : Tendremos que ofrecer un número 8 0 0 para tas personas que no estén dispuestas a realizar ta personalización por sí mismas. P e r s o n a d e m e r c a d o t e c n i a # 2 : Estoy d e acuerdo V i n o s : Muy bien, tendremos que hablar acerca de cómo les gustaría exactamente hacer ta personalización del producto como una actividad de prevenías, pero dejemos eso por un momento. Tengo otras cuantas preguntas fundamentales.

Vinod (ve a la persona d e mercadotecnia #2):

V i n o d ( e x a s p e r a d o ) : Doug... no me estás escuchando... estamos apretados de tiempo y esto...

Dijiste que querías guiar a tas usuarios a través del proceso. ¿Algún enfoque especial?

D o u g ( i n t e r r u m p e ) : Sólo dale un día de tu tiempo, Vinod. Entrevístate con los tipos de mercadotecnia y hazlos que especifiquen el contenido básico, ta función; tú sabes, el procedimiento usual.

P e r s o n a d e m e r c a d o t e c n i a # 2 : Quisiera ver un proceso paso a paso, con espacios en blanco para responder preguntas de requisitos básicos, menús desplegables, ese tipo de cosas. Cada paso es una ventana, y tas datos de c a d a ventana se validan antes de moverse al paso siguiente.

V i n o d ( r e s i g n a d o ) : Está bien, los llamaré y concertaré algo para mañana, pero no me facilitas la vida. D o u g ( s o n r í e ) : Por eso te llevas tas billetes grandes. V i n o d : Cierto. (Vinod se entrevista con tres personas de mercadotecnia al día siguiente.) V i n o d : Me decían acerca d e tas objetivos y antecedentes de tas usuarios. P e r s o n a d e m e r c a d o t e c n i a # 1 : Como dije, pretendemos que el usuario seo capaz de personalizar todo el sistema HogarSeguro. Tú sabes: escoger sensores, paneles de control, características y Funciones, luego obtener una "cuenta de materiales" generada automáticamente, obtener la cotización y luego comprar el sistema a través del sitio Web.

V i n o d : ¿Has comprobado eso con usuarios representativos? P e r s o n a d e m e r c a d o t e c n i a # 2 : No, pero ta haré V i n o d : Una cosa más. .. ¿cómo encontrará nuestro sitio un usuario? P e r s o n a d e m e r c a d o t e c n i a # 1 : Estamos trabajando en una campaña publicitaria que colocará www.HogarSegurolnc.com en anuncios de revistas, correo dirigido a objetivos, anuncios sensibles a contenido que aparecen en tas motores de búsqueda, y tal vez incluso algunos spots de radio y televisión.

TM

V i n o d : Lo que quiero decir es... tas usuarios siempre entran a través de ta página inicial.

Persona de mercadotecnia #3: Eso es ta que nos

PDF Editor P e r s o n a d e m e r c a d o t e c n i a # 2 : Suponemos que el usuario es propietario d e una casa, no un técnico, así que necesitamos guiarlo a través del proceso paso a paso.

gustaría.

V i n o d : Muy bien, ahora tenemos que ponernos a trabajar. Exploremos tas detalles de cómo quieren personalizar tas sistemas en línea.

C A P Í T U L O 17

523

FORMULACIÓN Y PLANEACIÓN P A R A INGENIERÍA WEB

Comunicación con los clientes y usuarios finales.

La mayoría d e las WebApps

tiene una amplia población de usuarios finales. Aunque la creación de categorías o clases de usuario hace que una evaluación de los requisitos de usuario sea más manejable, no e s recomendable emplear información recopilada sólo de una o dos personas como la base para la formulación o el análisis. Se deben considerar más personas (y más opiniones y puntos de vista). La comunicación se puede lograr aprovechando uno o m á s de los mecanismos siguientes |FUC02a]: i metode i es i emplear

• Grupo muestraI tradicional. Un moderador entrenado se reúne con un pequeño (usualmente m e n o s d e 10 personas) grupo representativo de usuarios finales (o participantes internos que los representan). El propósito es discutir la WebApp que se desarrollará y, fuera d e la discusión, comprender mejor los requisitos del sistema. • Grupo muestraI electrónico. Un debate electrónico moderado dirigido con un grupo de usuarios finales y participantes representativos. El número de participantes puede ser mayor. Puesto que todos los usuarios pueden participar al mismo tiempo, e s posible recopilar más información en un periodo más corto. Dado que todo el debate se basa en texto es automático un registro contemporáneo. • Entrevistas iterativas. Una serie de entrevistas breves, dirigida a usuarios representativos y en la que se solicitan respuestas a preguntas especificas acerca de la WebApp, se dirige a través del sitio Web o mediante correo electrónico. Las respuestas se analizan y aprovechan para afinar la entrevista siguiente. • Entrevistas de exploración. Encuesta basada en Web y ligada a una o más WebApps con usuarios similares a los que usarán la WebApp que se desarrollará. Los usuarios se enlazan a la entrevista y responden una serie de preguntas (usualmente reciben alguna recompensa por participar). • Construcción de escenarios. A usuarios seleccionados se les pide crear casos de uso informales que describan interacciones específicas con la WebApp.

[CONSEJO

i demora/la i de los ; i operaciones 3 mientras Keel ) del análisis, •punto es más ? la recopilai información, i ?valuación.

Análisis d e la i n f o r m a c i ó n r e c o p i l a d a . Conforme se recopila información se categoriza en clase de usuario y tipo de transacción, y luego se valora según su relevancia. El objetivo es desarrollar listas de objetos de contenido, operaciones que se aplican a los objetos de contenido dentro de una transacción de usuario específica, TM funciones (por ejemplo, informativa, computacional, lógica y orientada a la ayuda) que la WebApp proporciona a los usuarios finales, y otros requisitos no funcionales que se advierten durante las actividades de comunicación. Fuccella y Pizzolato [FUC02b] sugieren un método simple (de baja tecnología: low-tech) para comprender c ó m o se deben organizar el contenido y la funcionalidad. Se crea un paquete de "cartas" para los objetos de contenido, las operaciones apli-

PDF Editor

cadas a los objetos de contenido, la funciones WebApp y otros requisitos no funcio-

524

PARTE TRES


nales. Se barajan las cartas y luego s e distribuyen a las personas representativas de cada categoría de usuario. Se pide a los usuarios que ordenan las cartas en grupos que reflejan c ó m o les gustaría que se organizara el contenido y la funcionalidad dentro de la WebApp. Luego se solicita a los usuarios que describan cada agrupamiento y las r a z o n e s por las que son importantes para ellos. Una vez que cada usuar.: realiza este ejercicio, el equipo de ingeniería Web busca agrupamientos comunes entre diferentes clases de usuarios y otros agrupamientos que sean únicos para ur.i clase d e usuario específica. El equipo IWeb desarrolla una lista de etiquetas que se usarán para apuntar la información dentro de cada uno de los agrupamientos derivados con el uso de los paque tes de cartas. Entonces, a los diferentes usuarios representativos se les dan los paquetes de cartas y se les pide ubicar el contenido y la funcionalidad a cada una ¿r las etiquetas. Aquí el próposito e s determinar cuándo las etiquetas (enlaces d e n t r j de la WebApp real) implican de manera adecuada el acceso al contenido y las fun ciones q u e los usuarios esperan encontrar detrás de la etiqueta. Este paso se apli:= de manera iterativa hasta que se alcanza el consenso. "Si IB que estos haciendo no lo puedes describir como un proceso, entonces no sabes lo que estás haciendo," W. L Deming

ÔNSEJO^ En lo Paite 2 de este libio se trataron con detalle los casos de uso. Aunque muchos abogan por el desarrollo de casos de uso muy largos, incluso una nairoción informal proporciona algún beneficio. Convenza a los usuarios paro que escriban cosos de uso.

D e s a r r o l l o d e c a s o s d e u s o . Los casos de uso 2 describen c ó m o interactuará con] la WebApp una categoría de usuario especifica (llamada actor) para lograr ur.a acción específica. La acción p u e d e ser tan simple c o m o adquirir contenido definid: ,¡ o tan compleja c o m o que el usuario realice un análisis detallado de registros selecJ cionados que se mantienen en una b a s e de datos en línea. Los casos de uso d e s c e ben la interacción desde el punto de vista del usuario. Aunque desarrollarlos y analizarlos toma tiempo, los casos de uso 1) ayudan U desarrollador a entender c ó m o perciben los usuarios su interacción con la WebApr J 2) proporcionan el detalle necesario para crear un modelo de análisis efectivo: ;-H ayudan a dividir en compartimientos el trabajo de IWeb; y 4) ofrecen una guía impc - -I tante para quienes deben probar la WebApp. CONJUNTO DE TAREAS

La comunicación

con el cliente (Análisis/Formulación)

1. Identifiqúense

2.

a los clientes del

negocio. ¿Exactamente quién es el "cliente" d e la W e b A p p ? ¿Qué personas d e negocios pueden funcionar como

Formúlese el contexto del negocio. ¿Cómo encaja lo

TM

W e b A p p en una estrategia d e negocios más amplíe' 3.

Defínanse las metas y objetivos clave del negocio

PDF Editor expertos y usuarios finales representativos? ¿Quién participará como miembro activo del equipo?

2

para la WebApp.

¿Cómo se medirá el éxito d e la

W e b A p p , tanto en términos cualitativos como cuantitativos?

En los capítulos 7 y 8 se presentaron con detalle las técnicas p a r a desarrollar los c a s o s de uso

CAPÍTULO 17

Defínanse las metas informativas y aplicables. ¿Qué

6.

d a s e d e contenido se proporcionará a los usuarios anales? ¿Qué funciones/tareas se lograrán cuando se use la WebApp? identifiqúese

el problema.

525


¿Qué problema específico

resuelve la W e b A p p ?

Recopílense requisitos. ¿Qué tareas del usuario se

\

lograrán mediante el uso d e la W e b A p p ? ¿Qué contenido se desarrollará? ¿Qué metáfora d e interacción se usará? ¿Qué funciones computacionales proporcionará la W e b A p p ? ¿Cómo se configurará la W e b A p p p a r a su utilización en red? ¿ Q u é esquema d e navegación se desea?

17.1.3 El puente hacia el modelado d e análisis é proyectos se puede una simple a datos de ' (con la de uno hoja ' en lugar UML Esto ¡todos los del equipo losrequie¡ contenido '• entregado mejor el ñujode que ocurrirá.

Como ya se ha señalado en este capítulo, las actividades que conducen a un equipo de ingeniería Web de la formulación al modelado de análisis representa un continuo. En esencia, el grado de abstracción considerado durante las primeras etapas de la formulación es la estrategia del negocio. Sin embargo, conforme la formulación se lleva a cabo, se analizan los detalles tácticos y se abordan los requisitos específicos de la WebApp. Finalmente, estos requisitos se modelan (con la utilización de casos de uso y notación UML). Los conceptos y principios tratados para el análisis de requisitos de software (capítulos 7 y 8) se aplican sin revisión para la actividad de análisis de ingeniería Web. Durante el análisis se elabora el ámbito definido durante la actividad de formulación para crear un modelo de análisis completo para la WebApp. En la IWeb se realizan cuatro tipos diferentes de análisis: del contenido, de la interacción, de la función y de la configuración. En el capítulo 18 s e exponen las tareas y técnicas de modelado asociadas con cada uno de estos análisis. "Al fracasar para preparar, se prepara para el fracaso." Benjamín Frankfin

17.2

P L A N E A C I Ó N PE PROYECTOS PE INGENIERÍA W E B Dada la inmediatez de las WebApps es razonable preguntar: ¿en realidad se necesita gastar tiempo en la planeación y administración de un esfuerzo WebApp? ¿No sólo se debería dejar evolucionar naturalmente a la WebApp, con poca o ninguna gestión explícita? Más de un desarrollador Web optaría por poca o ninguna gestión, ¡pero eso n o hace que estén en lo correcto! La figura 17.1 presenta un cuadro adaptado de Kulik y Samuelson [KULOO] que indica cómo los "proyectos electrónicos" (e-projects, su término para TM los proyectos WebApp) se comparan con los proyectos de software tradicionales. Al consultar la figura, los proyectos d e software tradicionales y los grandes proyectos electrónicos tienen similitudes sustanciales. Dado que la gestión del proyecto se indica para los proyectos tradicionales, parecería razonable argumentar que también estaría indicada para los grandes proyectos electrónicos. Los pequeños proyectos electrónicos tienen características especiales que los diferencian de los proyectos tradicionales.

PDF Editor

Sin embargo, incluso en el caso de los pequeños proyectos electrónicos, la planea-

PARTE TRES

526


D i f e r e n c i a s e n t r e p r o y e c t o s t r a d i c i o n a l e s y e l e c t r ó n i c o s (e-projects) [ a d a p t a d o d e KULOO] Proyectos tradicionales

Pequeños proyectos electrónicos

Grandes proyectos electrónicos

Recopilación d e requisitos

Riguroso

Limitada

Rigurosa

Especificaciones técnicas

Robustas: modelos, especificaciones

P a n o r a m a descriptivo

Robusta: modelos UMl, especificaciones

Duración del proyecto

M e d i d a en meses o años

M e d i a d a en dias, s e m a n a s o meses

Medida en meses o años

Prueba y aseguramiento de la calidad

E n f o c a d a en lograr blancos d e calidad

E n f o c a d a sobre control d e riesgo

A s e g u r a m i e n t o d e la calidad del software c o m o se d e s c r i b e e n el c a p i t u l o 2 6

Gestión de riesgos

Explícita

Inherente

Explícita

Vida media de los entregables

8 meses o más

De 3 a ó meses o m á s corto

De 6 a 12 m e s e s o más corto

Proceso d e liberación

Riguroso

Expedito

Riguroso

Retroalimentación del cliente después d e la liberación

Requiere estuerzo proactivo

Se obtiene a u t o m á t i c a m e n t e d e la i n t e r a c c i ó n c o n el u s u a r i o

Se obtiene tanto de manera automática como p o r m e d i o d e solicitud de retroalimentación

ción se debe realizar, se deben considerar los riesgos, se debe establecer un prog: ma y se deben definir controles d e m o d o que eviten la confusión, la frustración y fracaso. 1 7 . 3

E l

EQ.UIPQ DE I N G E N I E R Í A

WEB

i

Un equipo de ingeniería Web exitoso mezcla una amplia variedad de talentos c J ! deben trabajar c o m o equipo en un ambiente de proyecto con alta presión. Los p —I zos son cortos, los cambios son inexorables y la tecnología continúa cambiando creación de un equipo que se consolide (véase el capítulo 21) no es asunto sene, a "En el mundo actual, alimentado por la Web y centrado en lo red, uno necesita saber mucho de muchos temos." Scot Tilley y Shihoog Huanj

17.3.1

Los actores

La creación de una aplicación Web exitosa demanda un amplio abanico de hábil: ü l des. Tilley y Huang (TIL99] abordan este tema cuando afirman: "Existen tantos áám rentes aspectos del software de aplicación [a la Web] que se ha dadoTM el (re)surgimier* del renacentista, aquel que se siente cómodo trabajando en varias disciplinas . a Aunque los autores están en lo correcto, los "renacentistas" son r e l a t i v a m e - * pocos, y dadas las demandas asociadas con los grandes proyectos de desarrolle M

PDF Editor

WebApps, el conjunto de diversas habilidades requeridas puede ser mejor d i s t r i t o d o entre un equipo de ingeniería Web. Los equipos de ingeniería Web se pueden organizar, en gran medida, en la m i s r J forma que los equipos de software tradicionales (capítulo 21). Sin embargo, los a n d

CAPÍTULO 17


527

res y sus papeles usualmente son bastante diferentes. Entre las m u c h a s habilidades que se deben distribuir entre los miembros del equipo IWeb se encuentran: ingeniería del software basada en componentes, realización de redes, diseño arquitectónico y de navegación, lenguajes/estándares de Internet, diseño de interfase humana, diseño gráfico, disposición del contenido y pruebas de las WebApps. Los siguientes papeles 3 se deben distribuir entre los miembros del equipo IWeb: iesempe-

D e s a r r o l l a d o r e s / p r o v e e d o r e s d e c o n t e n i d o . Dado que el contenido contro¡a inherentemente las WebApps, una función del equipo IWeb se debe enfocar en la generación o recopilación del contenido. Recuérdese que el contenido abarca un amplio abanico de objetos de datos, por ello los desarrolladores/proveedores de contenido pueden provenir de diversos ámbitos (no de software). E d i t o r e s d e w e b . El variado contenido que generan los respectivos desarrolladores/proveedores se debe organizar para incluirlo en la WebApp. Además, alguien debe actuar como conexión entre el equipo técnico que diseña la WebApp y los desarrolladores/proveedores de contenido sin conocimientos técnicos. Este papel lo satisface el editor de Web, quien debe entender tanto el contenido como la tecnología de la WebApp. I n g e n i e r o W e b . El ingeniero Web se involucra en un amplio rango de actividades durante el desarrollo de una WebApp, que incluyen la obtención de requisitos, el modelado de análisis, el diseño arquitectónico, de navegación y de interfase, la implementación de la WebApp y las pruebas. El ingeniero Web también debe tener una sólida comprensión de las tecnologías de componentes, de las arquitecturas cliente/servidor, de HTML/XML y de tecnologías de bases de datos, y un conocimiento práctico de los conceptos multimedia, de las plataformas hardware/software, de la seguridad de redes y de cuestiones de apoyo a sitios Web. E x p e r t o s e n d o m i n i o s e m p r e s a r i a l e s . Un experto en dominio empresarial debe ser capaz de responder todas las preguntas relacionadas con metas, objetivos y requisitos empresariales relacionados con la WebApp. E s p e c i a l i s t a d e s o p o r t e . Este papel se asigna a la persona (personas) que es (son) responsable(s) del apoyo continuo a la WebApp, Puesto que las WebApps evolucionan continuamente, el especialista de soporte es responsable de las correcciones, adaptaciones y mejoras al sitio, que incluyen actualizaciones de contenido, implementación de nuevos procedimientos y formas, y cambios al patrón de navegación. A d m i n i s t r a d o r . Usualmente llamado "web master", esta persona tiene la resTM ponsabilidad de la operación diaria de la WebApp, lo que incluye: desarrollo e implementación de políticas para la operación de la WebApp, establecimiento de procedimientos de soporte y retroal i mentación, implementación de seguridad y derechos de acceso, medición y análisis de tráfico del sitio Web, coordinación de los procedi-

PDF Editor

mientos de control de cambios (capítulo 27) y coordinación con el especialista de

3

Estos papeles se han adaptado de Hansen y sus colegas |HAN99]

528

P A R T E TRES


soporte. El administrador también puede estar involucrado en las actividades técnic a s que realizan los ingenieros Web y los especialistas de soporte. ÔHSEJO^ Estos características son usuales en los equipos de colaboradores outoorganizodos que barí adoptado un enfoque ágil (capitulo 4). Mientras mejor sea el equipo, mejor será el producto de software que se produzca.

17.3.2 Construcción del equipo En el capítulo 21 se tratarán con cierto detalle los lincamientos para la construcción exitosa d e los equipos d e ingeniería del software. Pero, ¿estos lincamientos se aplican en el apretujado m u n d o d e los proyectos WebApp? La respuesta e s sí. Hace algún tiempo, en su éxito de librería acerca d e la industria de la computación, Tracy Kidder [KIDOO] cuenta la historia del heroico intento de una compañ a de computación por construir una computadora para enfrentar el reto de un nuevo producto que fabricó un competidor más grande. 4 La historia es una metáfora del equip o de trabajo, del liderazgo y del aplastante estrés que todos los tecnólogos encuer tran cuando los proyectos críticos n o avanzan tan suavemente como se planeó. Un resumen del libro de Kidder difícilmente le hace justicia, pero los siguiente; puntos clave [PICO 1 ] tienen particular relevancia cuando una organización c o n s t r j ye un equipo de ingeniería Web: Se d e b e e s t a b l e c e r u n c o n j u n t o d e d i r e c t r i c e s d e e q u i p o . Dichas directr.-] ees abarcan lo que se espera de cada persona, cómo se lidiará con los problema;; qué mecanismos existen para mejorar la efectividad del equipo conforme avanza i proyecto. El l i d e r a z g o f u e r t e e s u n a o b l i g a c i ó n . El líder del equipo debe guiar mee te el ejemplo y el contacto. Debe mostrar un grado de entusiasmo que impulse a otros miembros del equipo "a endosarse" psicológicamente al trabajo que enfrent, El r e s p e t o h a c i a l o s t a l e n t o s i n d i v i d u a l e s e s c r u c i a l . Nadie es bueno todo. Los mejores equipos utilizan las fortalezas individuales. Los mejores líderes: equipo permiten que los individuos tengan libertad para seguir una buena idea. C a d a m i e m b r o d e l e q u i p o s e d e b e c o m p r o m e t e r . El protagonista princ en el libro de Kidder le llama a esto "endoso". Es fácil c o m e n z a r , l o difícil e s m a n t e n e r el Í m p e t u . Los mejores equipos ni dejan que un problema "insuperable" los detenga. Los miembros del equipo de lian una solución "lo suficientemente buena" y proceden, con la esperanza de ímpetu del progreso pueda conducirlos a una solución todavía mejor en el largo pU

TM Una vez realizada la formulación y que se han identificado los requisitos básico; i la WebApp, la empresa debe elegir una de dos opciones de ingeniería Web: 1| WebApp es subcontratada (outsourced): la ingeniería Web la realiza un tercer prc

PDF Editor 4

El libro de Kidder, The Soul of a New Machine, originalmente publicado e n 1981, íes una lectura i

tamente recomendable para cualquiera que intente realizar una carrera en la computación y | quienes ya la tienen!

CAPÍTULO 17

529


dor con experiencia, talento y recursos con los cuales no c u e n t e la e m p r e s a ; o 2) la WebApp la desarrollan en casa ingenieros Web que sean e m p l e a d o s de la empresa. Una tercera opción (hacer algún trabajo de ingeniería Web e n casa y subcontratar otro trabajo) también e s u n a posibilidad. "Como observó Thomns Hobbs en el siglo xvu, lo vido bajo las reglas de las pandillas es solitario, pobre, peligroso, cruel y corta, la vida en un proyecto de software que corre pobremente; es solitario, pobre, peligrosa, cruel y con dificultad alguna vez es lo suficientemente corta." Sfsven McConnell El trabajo q u e d e b e realizarse sigue s i e n d o el m i s m o sin importar si u n a WebApp e s s u b c o n t r a t a d a , desarrollada en casa o distribuida e n t r e u n proveedor externo y el equipo de casa. No obstante, sí cambian los requisitos de comunicación, la distribución de actividades técnicas, el grado de interacción entre clientes y desarrolladores, y una diversidad de otros conflictos crucialmente importantes. La figura 17.2 ilustra, respecto a las WebApps, la diferencia organizacional e n t r e subcontratación y desarrollo en casa. Éste (figura 17.2a) integra directamente todos los miembros del equipo de ingeniería Web (el círculo p u n t e a d o implica integración). La comunicación se establece mediante los c a m i n o s de la organización. En c u a n t o a la subcontratación (figura 17.2b), e s impráctico y desaconsejable q u e cada elem e n t o de casa (por ejemplo, desarrolladores de contenido, accionistas, ingenieros Web internos) tenga comunicación directa con el subcontratista sin que exista algún e l e m e n t o de conexión para coordinar y controlar la comunicación. En las secciones que siguen s e e x a m i n a r á n con m á s detalle las planeaciones para la subcontratación y el desarrollo en c a s a .

as "vas subcontratay desarrollo

Ingenieros

temeros Especialistas d e soporte ^

Especialistas l de soporte^

casa.

I vendedor ¡ D e s a r r o l l a d o r e s ' \ dé contenido /

Desarrolladores. 'Administrador^

contenido.

/Administrador; Subcontratista

Editor Web Gerentes negocios

Gerentes negocios

Clientes

/

Clientes

TM

PDF Editor Mercadotecni

Usuarios finales

ventas

a) D e s a r r o l l o e n c a s a

Usuarios finales

Mercadotecnia ventas

b) D e s a r r o l l o s u b c o n t r a t a d o

530

^ O N S t J O ^

No se supongo que, puesto que se ha subconliatado una WebApp, las responsabilidades son mínimas. De hecho, es probable que se requieran más, no menos, supervisión y gestión.

P A R T E TRES


17.4.1 Planeación de WebApp: subcontratación Un porcentaje sustancial d e las WebApps se subcontrata con proveedores que (supuestamente) se especializan en el desarrollo d e sistemas y aplicaciones basados en Web. 5 En tales casos, un negocio (el cliente) pide un precio fijo para desarrollar la WebApp de uno o m á s proveedores, evalúa los precios competitivos y luego elige un proveedor para efectuar el trabajo. Pero, ¿qué busca la organización contratante? ¿Cómo se determina la competencia de un proveedor de WebApps? ¿Cómo se sabe si una cotización es razonable? ¿Qué grado de planeación, programa d e trabajo y valoración de riesgo se pueden esperar conforme una organización (y su subcontratista) se embarca en un esfuerzo por desarrollar una gran WebApp? "Muchos empresas de Fortune 500 hon descubierto al software como un modelo de servicio [subcontratado] y están contratando modelos similares interna o externamente." Nkk Evans

Estas preguntas no siempre son fáciles de contestar, pero vale la pena considerar algunos lincamientos. Inicio del p r o y e c t o . Si la subcontratación s e elegirá como la estrategia para desarrollar la WebApp, la organización debe realizar una serie de tareas antes de buscar una empresa subcontratista que haga el trabajo: 1. Realizar, internamente, muchas de las labores de análisis tratadas en la sección 17.1.3 (y en el capítulo 18). Se identifica el público para la WebApp; se hace una lista con los accionistas internos interesados en la WebApp; se definen y revisan las metas globales para la WebApp; se especifican la información y servicios que habrá de proporcionar la WebApp; se destacan los sitios Web competidores; y se identifican las "medidas" cualitativas y cuantitativas de una WebApp exitosa. Esta información deberá documentarse en una especifi-

^CONStJO^. Algunos personas argumentan que "el diseño aproximado" es innecesario. Véase como una "primero oferta" que el proveedor subcontrotisto puede modificar y mejorar. Al menos está comunicando sus ideas acerca de a qué se debe parecer el resultado final.

cación de producto que se entregará al subcontratista. 2. Desarrollar internamente un diseño aproximado de la WebApp. Obviamente, un desarrollador Web experto creará un diseño completo, pero e s posible ahorrar tiempo y costo si la visión y el sentido general de la WebApp s e identifican para la empresa subcontratista (esto siempre puede modificarse durante las etapas preliminares del proyecto). El diseño debe incluir una indicación del tipo y volumen de contenido que se presentará en la WebApp y los tipos de TM procesamiento interactivo (por ejemplo, formatos, entrada de pedidos) que se llevarán a cabo. Esta información deberá agregarse a la especificación del producto.

PDF Editor 5

Aunque e s difícil encontrar d a t o s industriales confiables, p u e d e afirmarse q u e e s t e porcentaje e s

considerablemente mayor q u e el q u e s e observa en el trabajo d e s o f t w a r e convencional. En el cap- -I tulo 2 3 se ofrece una exposición adicional acerca d e la subcontratación.

C A P I T U L O 17


531

3. Elaborar un programa aproximado que incluya no sólo las fechas finales de entrega, sino también fechas clave. Las fechas clave se deben adjuntar a las versiones de entrega (incrementos) de la WebApp conforme ésta evolucione. 4. Crear una lista de responsabilidades para la organización interna y el subcontratista. En esencia, esta tarea aborda qué información, contactos y otros recursos se requieren de a m b a s organizaciones. 5. Identificar el grado de supervisión e interacción de la organización contratante con el subcontratista. Esto debe incluir el nombre del contacto del vendedor y la identificación de las responsabilidades y autoridad del contacto, la definición de los puntos de revisión de calidad conforme avance el desarrollo, y las responsabilidades del subcontratista en relación con la comunicación entre las organizaciones. ili r e c deben

Toda la información generada durante estos pasos deberá organizarse en una solicitud de presupuesto que se entrega las empresas candidatas. 6

ido se

varios tas?

S e l e c c i ó n e n t r e l o s s u b c o n t r a t i s t a s c a n d i d a t o s . En los últimos años han surgido miles de compañías de "diseño Web" dedicadas a ayudar a las empresas que desean establecer una presencia Web o aventurarse en el comercio electrónico. Muchas se han vuelto adictas al proceso de IWeb, pero m u c h a s otras son poco más que hackers (intrusos informáticos). Con la finalidad de elegir desarrolladores Web candidatos, el contratante debe realizar algunas diligencias obligadas: 1) entrevistar a los clientes antiguos para determinar el profesionalismo del vendedor Web, así como su habilidad para cumplir con compromisos de plazos y costos, y su destreza para comunicarse efectivamente; 2) determinar el nombre del ingeniero(s) Web jefe de la empresa subcontratista para buscar proyectos anteriores exitosos (y, después, asegurarse de que esta persona tenga la obligación contractual de estar involucrada en su proyecto); y 3) examinar cuidadosamente ejemplos del trabajo del subcontratista que sean similares en apariencia y sentido (y área de negocios) a la WebApp que será contratada. Incluso antes de que se ofrezca una solicitud de presupuesto, u n a entrevista personal puede ofrecer un discernimiento sustancial de la "conexión" entre el contratante y el subcontratista. "Si pagas cacahuates, obtienes monos." George Peppard en el papel del coronel John "Hannibol" Smith en The A-Team TM de tos ochenta) (serie televisiva

Valoración d e la v a l i d e z d e l a s c o t i z a c i o n e s y la c o n f í a b i l i d a d d e l a s e s t i m a c i o n e s . Puesto que existen relativamente pocos datos históricos y que el ámbi-

PDF Editor

to d e las WebApps es fluido en forma notoria, la estimación es inherentemente ries6

Si el trabajo de desarrollo d e la WebApp lo dirigirá un grupo interno, ¡no cambia n a d a ! El proyecto

se inicia de la m i s m a m a n e r a .

532

PARTE TRES


gosa. Por esta razón, algunos proveedores incorporarán márgenes de seguridad sustanciales en cotizaciones para un proyecto. Esto e s comprensible y apropiado. La pregunta no es si se ha obtenido la mejor solución por la inversión. Más bien, las pre guntas deben ser: • ¿La cotización de la WebApp ofrece un rendimiento sobre la inversión, direct :> o indirecto, que justifique el proyecto? • ¿La empresa emisora de la cotización tiene el profesionalismo y la experiencia que se requieren? Si las respuestas a estas preguntas son afirmativas la cotización es justa. C o m p r e n s i ó n del g r a d o d e g e s t i ó n d e l p r o y e c t o q u e p u e d e e s p e r a r o real? z a r . La formalidad asociada con las labores de gestión del proyecto (que realizan d proveedor y la organización contratante) es directamente proporcional al t a m a r : costo y complejidad de la WebApp. Respecto a proyectos complejos y grandes necesario elaborar un programa del proyecto que defina las tareas del trabajo, puntos de comprobación, el aseguramiento de la calidad del software, los produ de trabajo d e ingeniería, los puntos de revisión del cliente y los hitos importantes, proveedor y el contratante tendrán que valorar el riesgo conjuntamente y elat planes para mitigar, monitorear y manejar los riesgos considerados important Los mecanismos para asegurar la calidad y el control de cambios s e deberán def explícitamente por escrito. Se deberán establecer métodos para la comunica" efectiva entre el contratante y el proveedor. E v a l u a c i ó n del p r o g r a m a d e l p r o y e c t o . Dado que los programas de d e s a n de WebApps abarcan un periodo relativamente corto (por lo general m e n o s de o dos meses para que se entregue el incremento), el programa para el desarr debe tener una dosificación muy precisa. Es decir: las tareas de trabajo y los hi m e n o r e s s e deben programar en un cronograma diario. Esta dosificación pre' permite, tanto a la organización contratante como al subcontratista, reconocer hoja suelta de la agenda antes de que amenace la fecha de finalización.

\ CLAVE En lo gestión del ámbito se congelo el trabajo que voyo o realizarse en un incremento. Los cambios se demoran hasta el siguiente

G e s t i ó n del á m b i t o . Como es enormemente probable que el ámbito cambiará c forme avance el proyecto de la WebApp, el modelo de proceso IWeb es adaptable incremental. Esto permite que el equipo de desarrollo del subcontratista "congele" ámbito para un incremento, de modo que se pueda crear una liberación operativa la WebApp. El siguiente incremento puede abordar cambios en el TM ámbito que sugerido una revisión del incremento precedente, pero una vez que comience segundo incremento el ámbito nuevamente se "congela" de manera temporal,

PDF Editor memento d e la

enfoque permite que el equipo d e la WebApp trabaje sin tener que acomodar corriente continua de cambios, pero al mismo tiempo reconoce la evolución co nua característica de la mayoría de las WebApps. Los lineamientos sugeridos líneas atrás no intentan ser un recetario a prueba tontos para la producción a tiempo de WebApps d e bajo costo. Sin embargo, a

CAPÍTULO 17

533


rán t a n t o a la organización contratante c o m o al subcontratista a iniciar el trabajo d e m a n e r a flexible con un mínimo de m a l a s interpretaciones.

Preliminares para la subcontratación 0 e s c e n a r i o : la oficina de Doug Miller. i Doug Miller (gerente del equipo d e del software HogarSeguro)

y Sharon Woods,

e-CommerceSystems, el proveedor p a r a el sitio W e b d e comercio electrónico y gerente del equipo d e ingeniería W e b el trabajo.

S h a r o n : Está t r a b a j a n d o en él mientras platicamos. Dijo q u e tenía que poner un seguro en el lado del producto. S a b e q u e es crucial,.. dijo q u e me lo enviaría por correo electrónico m a ñ a n a en la m a ñ a n a . D o u g : Muy bien... mira, me gustaría estar en el trayecto d e este proyecto. Podemos establecer algunas reglas básicas p a r a supervisar desde nuestra parte. N o

rsación:

quiero entrometerme en tu camino, pero...

Sharon, qué bueno q u e por fin nos encontramos. algo d e trabajo q u e realizar en el mes, más o menos. ( s o n r í e ) : Tenemos, pero parece q u e ustedes se debidamente. Vinod ya nos ha d a d o un d e especificaciones p a r a el sitio y también ho la mayor parte d e los objetos de contenido y d e la funcionalidad del sitio.

involucrados a nuestros clientes. D o u g : Yo t r a b a j a r é como contacto p a r a este proyecto. Toda comunicación vendrá a través mío o d e alguien como Vinod, a quien yo cite. Puesto que estamos en un calendario apretado, m e gustaría establecer una a g e n d a que tenga una dosificación diaria y hablar contigo o enviarte correos electrónicos todos los días acerca d e los

Bien. ¿ Q u é más necesitan? La funcionalidad d e comercio electrónica e s lo q u e me preocupa es la f a c h a d a

S h a r o n : N o hay problema, nos gusta tener

el trabajo

requiere p a r a q u e los usuarios personalicen el antes d e la compra. Vinod te dio el procedimiento básico, ¿no es así? Sí, lo hizo; p e r o quiero validarlo con algunos Bales. También necesitamos contactar a sus d e contenido p a r a obtener descripciones p a r a c a d a sensor, dibujo, lista d e precios, interfase/interconexión, ese tipo d e cosas. ¿Vinod tiene tiempo p a r a hacerles un sloryboard proceso de personalización?

logros, los problemas, etcétera. Sé q u e es mucho, pero creo que eso es lo a d e c u a d o . S h a r o n : Está bien.

Doug (toma algunas hojas de papel de su escritorio y las entrega a Sharon): Escribí una a g e n d a a p r o x i m a d a con fechas límite... ¿qué opinas?

Sharon (luego de estudiar ta agenda): Mmmmm, no estoy segura d e q u e esto funcionará p a r a nosotros. Déjame t r a b a j a r una alternativa y hoy en la tarde te la envío por correo electrónico. D o u g : Claro.

17.4.2 Planeación de WebApp: ingeniería Web en casa TM Conforme las WebApps se vuelven m á s e x t e n s a s y estratégicas para los negocios, m u c h a s c o m p a ñ í a s h a n o p t a d o por controlar el desarrollo en casa. No sorprende que

PDF Editor

la IWeb en casa se gestione de m a n e r a u n p o c o diferente a un e s f u e r z o de subcontratación.

"¿Qué haces cuando necesitas tener listo un sitio Web paro ayet?"

James lewin

534

P A R T E TRES


La gestión de proyectos IWeb pequeños y de t a m a ñ o moderado (es decir: me de 3-5 m e s e s de duración) requiere un enfoque ágil que quite el énfasis en la ges del proyecto pero no elimine la necesidad de planear. Todavía se aplican los pri píos básicos de gestión d e proyectos (capítulo 21), pero el e n f o q u e global es parco y m e n o s formal. Sin embargo, conforme crece el t a m a ñ o del proy WebApp, la gestión del proyecto de ingeniería Web se vuelve m á s y m á s como gestión de proyectos de ingeniería del software (Parte 4 de este libro). Los siguientes se recomiendan para proyectos IWeb pequeños y de t a m a ñ o moderado ^ÓNSIJO^ Es importanle reconoce/que los pasos analizados en esto sección se pueden realizar rápidamente. En ningún coso la planeación IWeb pora proyectos de este tamaño tomo más del 5 por ciento del esfuerzo del proyecto global.

E n t e n d e r el á m b i t o , l a s d i m e n s i o n e s d e c a m b i o y l a s r e s t r i c c i o n e s d e l yecto.

Ningún proyecto, sin importar cuán apretada sea la restricción del tie.

puede co men za r mientras el equipo del proyecto no entienda q u é debe construir recopilación de requisitos y la comunicación con el cliente son precursores esenci») les para la planeación efectiva de la WebApp. Definir u n a estrategia d e p r o y e c t o incremental.

Ya se ha señalado que '

WebApps evolucionan con el tiempo. Si la evolución es descontrolada y caótica probabilidad de un resultado exitoso es pequeña. Sin embargo, si el equipo est ce una estrategia d e proyecto que defina incrementos (liberaciones) de WebApp proporcionen contenido útil y funcionalidad a los usuarios finales, el esfuerzo ingeniería p u e d e enfocarse con mayor facilidad. Realizar análisis d e riesgo.

En el capítulo 25 se presenta una exposición

liada del análisis d e riesgo para proyectos tradicionales de ingeniería del software Todas las labores de gestión de riesgo se realizan para proyectos IWeb, pero su e n í que se abrevia. Los riesgos que entrañan el programa y la tecnología dominan la preocupaa» de la mayoría de los equipos de ingeniería Web. Entre las muchas preguntas reí: nadas con el riesgo que el equipo debe formular y responder están: ¿Los incremer" WebApp planeados pueden entregarse en los plazos definidos? ¿Estos incremer: proporcionarán valor subsecuente para los usuarios finales mientras se realiza ingeniería de incrementos adicionales? ¿Cómo impactan las fechas de entrega solicitudes de cambios? ¿El equipo comprende los métodos, tecnologías y mientas de ingeniería Web requeridos? ¿La tecnología disponible es adecuada para trabajo? ¿Los cambios probables requieren la introducción de nueva tecnología? Desarrollar una estimación rápida.

El eje de la estimación para la mayoría

TM los proyectos de ingeniería Web lo representan los conflictos macroscópicos, OT

que los microscópicos. El equipo IWeb valora si los incrementos WebApp plan pueden desarrollarse con los recursos disponibles de acuerdo con las restriccior

PDF Editor

del programa definido. Esto se logra considerando el contenido y la función de i

7

Aquellos lectores que no estén familiarizados con la terminología y las prácticas básicas de la

tión de riesgos deberán consultar en este momento el capitulo 25.

C A P Í T U L O 17

535


incremento como un todo. Normalmente no se realizan rompimientos "microscópicos", funcionales o de trabajo, del incremento que sean seguidos por el cálculo de estimaciones puntuales de múltiples datos (véase el capítulo 23). Elegir u n c o n j u n t o d e t a r e a s ( d e s c r i p c i ó n d e l p r o c e s o ) . Empleando un marco de trabajo del proceso (capitulo 16) se elige un conjunto de tareas de ingeniería Web que sean adecuadas para las características del problema, el producto, el proyecto y la gente en el equipo de ingeniería Web. Reconózcase la posibilidad de adaptar el conjunto de tareas para que encaje en el desarrollo de cada incremento. E s t a b l e c e r u n p r o g r a m a . El programa de un proyecto IWeb tiene una dosificación relativamente precisa respecto de las tareas que se realizarán en el corto plazo, y luego una mucho más flexible durante periodos posteriores (cuando vayan a entregarse los incrementos adicionales). Esto es, las tareas de ingeniería Web se distribuyen a lo largo de la línea de tiempo del proyecto para el incremento que se desarrollará. La distribución de tareas para subsecuentes incrementos WebApp se demora hasta la entrega del incremento programado. D e f i n i r m e c a n i s m o s d e r a s t r e o del p r o y e c t o .

En un ambiente de desarrollo

ágil, la entrega de un incremento operativo de software con frecuencia e s la medida primaria del progreso. Pero mucho antes de que el software liberable esté disponible, el ingeniero Web enfrentará inevitablemente la pregunta: ¿dónde estamos? En el trabajo convencional de ingeniería del software el progreso se mide determinando qué objetivos se han logrado (por ejemplo, la revisión exitosa de un producto de trabajo). Respecto a proyectos de ingeniería Web pequeños y de t a m a ñ o moderado, los objetivos pueden estar m e n o s definidos, y las actividades formales de aseguramiento de la calidad pueden perder fuerza. En consecuencia, es posible derivar una respuesta si se entrevista al equipo de ingeniería Web para determinar qué actividades del marco de trabajo se han completado. No obstante, este enfoque puede ser poco fiable. Otro enfoque es determinar cuántos casos de uso se han implementado y cuántos (para un incremento dado) permanecen sin implementarse. Esto proporciona una indicación aproximada del grado relativo en que se ha completado el incremento del proyecto.

"El progreso se logro corrigiendo los errores resultantes de lograr el progreso". Claude Gibb

TM E s t a b l e c e r u n e n f o q u e d e g e s t i ó n del c a m b i o . La gestión del cambio se facilita mediante la estrategia de desarrollo incremental que se recomendó para las

PDF Editor

WebApps. Puesto que el tiempo de desarrollo para un incremento es corto, con frecuencia es posible demorar la introducción de un cambio hasta el siguiente incremento, con la consiguiente reducción de los efectos de demora asociados con los cambios que se deben implementar "al vuelo". En el capítulo 27 se presenta la gestión de la configuración y el contenido para las WebApps.

536

PARTE TRES



Gestión d e proyectos IWeb •

O b j e t i v o : Auxiliar al equipo de ingeniería W e b en la planeación, gestión, control y rastreo de proyectos de ingeniería Web. M e c á n i c a : Las herramientas de gestión de proyectos le permiten a un equipo IWeb establecer un conjunto de tareas de trabajo, asignar esfuerzo y especificar responsabilidad a cada tarea, establecer dependencia de tareas, definir un programa y rastrear y controlar las actividades del proyecto. Muchas herramientas en esta categoría están basadas en Web.

Herramientas representativas 8 Business Engine, desarrollado por Business Engine (www.businessengine.com), es una suite de herramientas basada s en W e b que ofrecen facilidades de gestión para proyectos completos de IWeb y proyectos de software convencionales. Ileamwork, desarrollado por iTeamwork.com (www.iteamwork.com), "es una aplicación de equipo de

gestión de proyecto gratuita, en línea y b a s a d a en Web, que puede usar con su navegador web". OurProject, desarrollado por Our Project (www.ourproject.com), es una suite d e herramientas de gestión de proyecto que son aplicables a la IWeb y a los proyectos de software convencionales. Proj-Nel, desarrollado por Ratíonal Concepts, Inc. (www.rationalconcepts.com), "implementa una oficina de proyecto virtual (VPO, virtual project office) para colaboración y comunicación". StartWright (www.startwright.com/projectl .htm) ha desarrollado uno de los recursos más completos de la Web para herramientas e información, tanto para IWeb como para gestión de proyectos de software convencional. Es necesario observar que muchas de las herramientas de gestión de proyecto convencional (Parte 4 de este libro) también se pueden aprovechar de manera efectiva en los proyectos IWeb.

Los ingenieros Web desarrollan sistemas complejos y, al igual que otros tecnología que realizan esta tarea, deben usar mediciones para mejorar el proceso de ingeniería Web y el producto. En el capítulo 15 se analizaron los u s o s estratégicos y tácticos para la medición de software en un contexto de ingeniería del software. Dichos u s e ; también se aplican e n la ingeniería Web. En resumen, la medición de s o f t w a r e ofrece u n a b a s e para mejorar el p r o c e s o de software, lo que a u m e n t a la precisión de las estimaciones del proyecto, incrementa ^CONSEJO^-

el rastreo del proyecto y mejora la calidad del software. La medición de ingeniera

f n general, elnúmeio de medidas IWeb que se debe recopilar, y su complejidad global, debe ser directamente proporcional al tamaño de la WebApp que se construirá.

Web, si se caracteriza de m a n e r a a d e c u a d a , podría lograr todos e s t o s beneficios y también mejorar la facilidad de uso, el d e s e m p e ñ o de la WebApp y la satisfacción de usuario. En el contexto de la ingeniería Web, las mediciones tienen tres m e t a s principales: 1) proporcionar un indicador de la calidad de la WebApp desde elTM p u n t o de vista técnico, 2) proporcionar u n a b a s e para la estimación del esfuerzo, y 3) proporcionar ur.¿ indicación del éxito de la WebApp d e s d e el punto de vista empresarial.

PDF Editor 8

Las herramientas expuestas sólo representan una muestra de esta categoría. En casi todos los ca-

sos los nombres de las mismas son marcas registradas de sus respectivos desarrolladores.

CAPÍTULO 17


537

En esta sección se r e s u m e u n c o n j u n t o de m e d i c i o n e s de e s f u e r z o c o m ú n y c o m plejidad 9 para las WebApps. Este c o n j u n t o p u e d e destinarse al desarrollo d e u n a b a s e de d a t o s histórica para la estimación del esfuerzo. Además, la medición de la complejidad p u e d e conducir a final de c u e n t a s a u n a incapacidad para valorar c u a n titativamente u n o o m á s atributos técnicos de las WebApps discutidos e n el capítulo 16.

17.5.1 Mediciones para esfuerzo d e ingeniería Web Los ingenieros Web dedican e s f u e r z o h u m a n o al realizar una diversidad de tareas de trabajo c o n f o r m e evoluciona u n a WebApp. Mendes y sus colegas |MEN0l] sugieren a l g u n a s posibles medidas de e s f u e r z o para WebApps. Algunas de (o todas) ellas podría registrarlas un equipo de ingeniería Web y luego aprovecharse en una b a s e d e d a t o s histórica con fines de estimación (capítulo 23).

Aplicación de las tareas de autoría y diseño Medida sugerida

Descripción

esfuerzo d e estructuración

tiempo para estructurar la WebApp y / o la arquitectura derivada

esfuerzo d e intervinculación

tiempo para intervincular páginas y así construir la estructura d e las WebApp

planeación d e interfaz

tiempo en que se planea la interfaz de la WebApp

construcción d e interfaz

tiempo en que se implemento la interfaz d e la WebApp

esfuerzo d e prueba de vínculos

tiempo en que se prueban todos los vínculos en la WebApp

esfuerzo d e prueba d e los medios audiovisuales esfuerzo total

tiempo en que se prueban todos los medios audiovisuales en la WebApp esfuerzo d e estructuración + esfuerzo de intervinculación + planeación d e interfase + construcción d e interfase + esfuerzo d e prueba de vínculos + esfuerzo de prueba d e los medios audiovisuales

Esfuerzo de autoría Medida sugerida

Descripción

esfuerzo d e texto

tiempo en que se crea o reutilíza texto en una página

esfuerzo d e vinculación d e página

tiempo en que se crean vínculos en la página

esfuerzo d e estructuración d e página

tiempo en que se estructura la página

TM

PDF Editor esfuerzo d e página total

esfuerzo de texto + esfuerzo d e vinculación de página + esfuerzo d e estructuración de página

9 Es importante notar que las mediciones IWeb todavía están en su infancia.

538

PARTE TRES


Autoría de medios audiovisuales Medida sugerida

Descripción

esfuerzo d e medio audiovisual

tiempo en que se crean o reutílizan archivos d e medios audiovisuote i

esfuerzo d e digitalización d e medios audiovisuales

tiempo en q u e se digitalizan medios audiovisuales

esfuerzo total d e medios audiovisuales

esfuerzo d e medio audiovisual + esfuerzo d e digitalización d e medios audiovisuales

Autoría de programas Medida sugerida

Descripción

esfuerzo d e programación

tiempo en q u e se crean HTML, Java o implementaciones d e leng.'De relacionado

esfuerzo d e reutilización

tiempo p a r a reutilizar/modificar la programación existente

17.5.2 Medición del valor d e negocios Referencia Web

Uno excelente referencia acerco de muchas materias r e t o ñ a d a s

Es interesante advertir que la g e n t e de negocios h a llegado considerablemente a n t e s que la ingeniería Web al desarrollo, la recopilación y el e m p l e o de la medición p¿-T| las WebApps (por ejemplo, [STE02], [NOBOl]). Al e n t e n d e r la demografía de

:d

usuarios finales y sus p a t r o n e s de uso, u n a c o m p a ñ í a u organización p u e d e des«-l rrollar la e n t r a da inmediata para m á s contenido WebApp significativo, ventas •

wnwwjntsriiet.com.

e s f u e r z o s de mercadotecnia m á s efectivos, y mejorar la rentabilidad de los negoc: s i Los m e c a n i s m o s requeridos con q u e s e recopilan d a t o s valiosos para la empresa! usualmente los implementa el equipo de ingenien'a Web, pero evaluarlos y las a c a : - l n e s resultantes las realizan o t r o s participantes. Por ejemplo, s u p ó n g a s e la posi'r J:-l dad de determinar el n ú m e r o de vistas de la página para cada visitante único. C e a b a s e en la medición recopilada, los visitantes que llegan d e s d e el motor de b u s q u e ! da X promedian n u e v e vistas de página, mientras que los visitantes desde el portal™ sólo dos. Estos promedios los p u e d e emplear el d e p a r t a m e n t o de mercadotec- J p a r a ubicar un a n u n c i o publicitario (banner) d o n d e promueva p r e s u p u e s t o s (la p u r f l cidad en el motor de b ú s q u e d a X proporciona mayor exposición, con b a s e en • medición recolectada, que la publicidad en el portal Y ) .

TM HERRAMIENTAS DE SOFTWARE

Mediciones Web

medición W e b captura la información d e uso una vez q i e

PDF Editor O b j e t i v o : Valorar la forma en la que se utiliza

una W e b A p p , las categorías d e usuarios y la facilidad d e uso de la WebApp. M e c á n i c a : La gran mayoría d e las herramientas d e

\

la W e b A p p está en línea. Dichas herramientas proporcionan una amplia variedad d e datos con los c u d » | se valora q u é elementos d e la W e b A p p se utilizan más, cómo se utilizan y quién los utiliza.

CAPÍTULO 17

539


lientas representativas 10

valora el éxito d e las W e b A p p s d e comercio

s, desarrollada por clicktracks.com /.dicktracks.com), es una herramienta de análisis

electrónico.

; archivos de acceso (log) q u e muestra el niento del visitante al sitio W e b directamente

W e b Mefrics Testbed, desarrollada por NIST (zing.ncsl.nist.gov/WebTools/), es una suite d e herramientas b a s a d a s en W e b que valoran la facilidad d e uso d e una WebApp.

• Dogmas d e éste. e, desarrollada por Coremetrics

WebTrends, desarrollada por netlQ (www.NetlQ.com),

w.Coremetrics.com), es representativa d e muchas

recopila un amplio rango d e datos d e uso p a r a

amientas que recopilan datos con los cuales se

W e b A p p s d e t o d o s los tipos.

Una revisión completa de la recopilación y el e m p l e o de las mediciones con valor en los negocios (que incluya el d e b a t e actual acerca de la privacidad personal) está m á s allá del á m b i t o de e s t e libro. El lector interesado deberá e x a m in a r [INA02], [EIS02], [PAT02] O [RIG01],

En ocasiones, la mejor forma de a p r e n d e r c ó m o hacer algo c o r r e c t a m e n t e ¡es examinar c ó m o n o hacerlo! Durante la década p a s a d a , m u c h a s WebApps fracasaron porque 1) un descuido del proyecto y el c a m b i o en los principios de gestión (de cualquier m a n e r a informales) resultó en un equipo de ingeniería Web que "rebotó en las paredes"; 2) un e n f o q u e ad hoc para el desarrollo de la WebApp falló y no produjo un sistema operable; 3) un e n f o q u e d e s d e ñ o s o hacia la recopilación y análisis de requisitos fracasó e n producir un sistema que satisfaciera las necesidades del usuario; 4) un e n f o q u e i n c o m p e t e n t e para el diseño f r a c a s ó al intentar producir un desarrollo de la WebApp que f u e s e utilizable, funcional, extensible (sustentable) y verificable; 5) un e n f o q u e equivocado para las p r u e b a s fracasó para producir un sistema que funcion a s e a n t e s de su introducción. Con e s t a s situaciones en mente, tal vez valga la p e n a considerar un c o n j u n t o d e las "peores prácticas" en la ingeniería Web, a d o p t a d a s de un artículo de Tom Bragg [BRAOO]. Si su proyecto electrónico muestra cualquiera de ellas, e s necesaria una acción correctiva inmediata. P e o r práctica # 1: Se tiene una gran idea, así que se puede comenzar

a construir

la WebApp ahora. No e s necesario p r e o c u p a r s e en considerar si la WebApp está justificada por el negocio, si los usuarios realmente querrán usarla, si se c o m p r e n d e n los requisitos del negocio. El tiempo es corto, tiene que c o m e n z a r s e TM . Realidad: T ó m e n s e u n a s c u a n t a s h o r a s o dias y elabórese u n c a s o d e negocios para la WebApp. Asegúrese de que la idea la apoyan quienes la financiarán y quie-

PDF Editor n e s la usarán.

10 Las herramientas e x p u e s t a s el autor n o las respalda, sólo representan una m u e s t r a d e las herram i e n t a s incluidas en esta categoría. En casi todos los casos, los n o m b r e s d e las h e r r a m i e n t a s son m a r c a s registradas de s u s respectivos desarrolladores

540

P A R T E TRES


P e o r práctica #2: Las cosas cambiarán constantemente, así que no tiene caso tr¿tar de comprender los requisitos de la WebApp. Nunca se escriba algo (pérdida d e tien po). El apoyo debe basarse exclusivamente en la palabra oral. Realidad: Es cierto que los requisitos de la WebApp evolucionan conforme cc tinúan las actividades de ingeniería Web. También es más rápido y simple obter información d e manera verbal. Sin embargo, un enfoque desdeñoso respecto de recopilación y el análisis de requisitos e s un catalizador para m á s cambio (innec sario) todavía. P e o r práctica #3: Los desarrolladores cuya experiencia dominante se relaciona i el desarrollo de software tradicional pueden desarrollar WebApps inmediatamente. No < requiere un nuevo entrenamiento. Después de todo, el software es software, ¿o no? Realidad: Las WebApps son diferentes. Se debe aplicar de manera experta amplio abanico de métodos, tecnologías y herramientas. El entrenamiento y la ex rienda con ellos es esencial." P e o r práctica #4: Burocratizarse. Insista en modelos de proceso pesados, he rios, muchas e innecesarias reuniones "de progreso" y en líderes de proyecto nunca han gestionado un proyecto WebApp. Realidad: Aliente un proceso ágil que resalte la competencia y la creatividad un equipo de ingeniería Web experimentado. Luego salga de su camino y permit trabajar. Si se deben recopilar datos relacionados con el proyecto (por razones le les o el cálculo de la medición), el ingreso/recopilación de datos debe ser tan no i tructivo y simple como sea posible. P e o r práctica #5: ¿Pruebas? ¿Por qué molestarse? Se le dará a unos cuantos i rios finales y se dejará que ellos digan qué funciona y qué no. Realidad: Con el tiempo, los usuarios finales sí realizan "pruebas" exhaustiv pero están tan enojados por la falta de confiabilidad y el pobre desempeño que dejan mucho antes de que los problemas sean corregidos (nunca regresan). En los capítulos que siguen se considerarán los métodos de ingeniería Web ayudarán a evitar estos errores.

La formulación, una actividad de comunicación con el cliente, define el problema resolverá una WebApp. Se identifican las necesidades del negocio, la metas y objett TM del proyecto, las categorías de usuario final, las funciones y características princip y el grado de interoperabilidad con otras aplicaciones. Mientras más información < liada y técnica se adquiera, la formulación se convierte en análisis de requisitos.

PDF Editor

11 Muchos grandes proyectos IWeb requieren integración con aplicaciones y bases de datos cc cionales. En tales casos, los individuos sólo con experiencia convencional pueden y deben ser c volucrados.

C A P Í T U L O 17

FORMULACIÓN Y P L A N E A O Ó N PARA INGENIERÍA WEB

541

El equipo lWeb lo integra un grupo de miembros técnicos y no técnicos organizados en una forma que les brinda considerable autonomía y flexibilidad. Durante la ingeniería Web s e requiere gestión del proyecto, pero las tareas correspondientes están abreviadas y son considerablemente m e n o s formales que las aplicadas en los proyectos convencionales de ingeniería del software. Muchos proyectos WebApp se subcontratan, pero existe una tendencia creciente hacia el desarrollo de WebApps en casa. La gestión del proyecto para cada enfoque difiere tanto en estrategia como en tácticas. Las mediciones de la ingeniería Web están en desarrollo, pero tienen el potencial para ofrecer una indicación de la calidad de la WebApp, proporcionar una base para la estimación del esfuerzo y permitir vislumbrar el éxito de la WebApp desde el punto de vista de los negocios.

[BRAOO] Bragg, T., "Worst Practices for e-Business Projects: We Have Met the Enemy and He Is Us!", Cutter IT Journal, vol. 13, núm. 4, abril de 2000, pp. 35-39. [CON02] Constantine, L. y L. Lockwood, "User-Centered Engineering for Web Applications", en IEEE Software, vol. 19, núm. 2, marzo-abril de 2002, pp. 42-50. [EIS02] Eisenberg, B„ "How to Interpret Web Metrics", en ClickZToday, marzo de 2002, disponible en http://www.clickz.com/sales/traffic/article.php/992351. [FUC02a] F u c c e l l a , J . Pizzolato y J. Franks, "Finding Out What Users Want from your Web Site", IBM developerWorks, 2002, http://www-l06.ibm.com/developerworks/library/moderator-guide/requirements.html. [FUC02b] Fuccella, J. y J. Pizzolato, "Giving People What They Want: How to Involve Users in Site Design", IBM developerWorks, 2002, http://www-106.ibm.com/developerworks/ library/design-by-feedback/expectations. htm 1. [GNA99] Gnado, C. y F. Larcher, "A User-Centered Methodology for Complex and Customizable Web Applications Engineering", en Proc. First ICSE Workshop in Web Engineering, ACM, Los Ángeles, mayo de 1999. [HAN991 Hansen, S„ Y. Deshpande y S. Murugesan, "A Skills Hierarchy for Web Information System Development", en Proc. First ICSE Workshop on Web Engineering, ACM, Los Ángeles, mayo de 1999. [INA02] Inan, H.yM. Kean, Measuring the Success o/Your Web Site, Longman Publishing, 2002. [KIDOO] Kidder, T., The Soul o/a New Machine, Back Bay Books (edición reimpresa), 2000. [KUL001 Kulik, P. y R. Samuelsen, "e-Project Management for a New e-Reality", Project Management Institute, diciembre de 2000, http://www.seeprojects.com/e-Projects/eprojects.html. [LOW98] Lowe, D. y W. Hall (eds.), Hypertextand the Web-An Engineering Approach, Wiley, 1998. [MEN01] Mendes, E., N. Mosley y S. Counsell, "Estimating Design and Authoring Effort", TM en IEEE Multimedia, enero-marzo de 2001, pp. 50-57. [NOBOl] Nobles, R. y K. Grady, Web Site Analysis and Reporting, Premier Press, 2001. [PAT02] Patton, S., "Web Metrics That Matter", en CIO, 15 de noviembre de 2002, disponible en http://www.computerworld.com/developmenttopics/websitemgmt/story/ 0,10801,76002.00.html. [PIC01] Pickering, C., "Building an Effective E-Project Team", en E-Project Management Advisoiy Service, Cutter Consortium, vol. 2, núm. I, 2001, http://www.cutter.com/ consortium. [POW981 Powell, T A., Web Site Engineering. Prentice Hall, 1998.

PDF Editor L

542

P A R T E TRES


[RIG01] Riggins, F. y S. Mitra, "A Framework for Developing E-Business Metrics Through functicnality Interaction", e n e r o d e 2001, s e p u e d e d e s c a r g a r d e http://digitalenterprise org/metrics/metrics.html.

[STE02] Sterne,)., Web Metrics: Proven Methods for Measuring Web Site Success, Wilev 2002. 1TIL99] Tilley, S. y S. H u a n g , "On t h e E m e r g e n c e of t h e R e n a i s s a n c e S o f t w a r e E n g i n e e r

Proc. IstICSE Workshop on Web Engineering, ACM, Los Ángeles, mayo de 1999.

1 7 . 1 . ¿En q u é difiere la formulación de la recopilación d e requisitos? ¿En qué difiere la forrr u - j lación del análisis d e requisitos y del m o d e l a d o de análisis? 1 7 . 2 . En la sección 17.1.1 se encuentran tres preguntas f u n d a m e n t a l e s acerca d e la f o r m a ¿ • I ción. ¿Existen a l g u n a s otras preguntas que se considere posibles de plantear en este p u n t o ' ¿i] es así, ¿cuáles son y por q u é deberían hacerse? 1 7 . 3 . En el contexto d e la recopilación d e requisitos, ¿qué es u n a "categoría de usuario"? ejemplos de tres categorías d e usuario para un vendedor de libros en línea. 1 7 . 4 . Considérese el sitio d e comercio electrónico d e HogarSeguro tratado en e s t e capítu.: ¿Qué m e c a n i s m o de comunicación con el usuario podría usarse para obtener requisitos del S i t e m a y por qué? 1 7 . 5 . Con palabras propias, exponga c ó m o se "analiza" la información recopilada durante comunicación con el cliente y cuál es el resultado d e esta actividad. 1 7 . 6 . ¿Qué beneficios se pueden derivar d e requerir el desarrollo de casos d e uso c o m o para^ d e la actividad d e recopilación d e requisitos? 17.7. Revísese la tabla presentada en la figura 17.1. Agréguense tres hileras más que ulterio distinguirán los proyectos tradicionales de los electrónicos. 1 7 . 8 . Con palabras propias, describa el papel del editor Web. 1 7 . 9 . Revísense las características d e los equipos de desarrollo ágil analizados en el capítulo > ¿Se advierte que una organización en equipo ágil e s apropiada para la IWeb? ¿El lector re algún cambio a la organización para el desarrollo d e la WebApp? 1 7 . 1 0 . Descríbanse cinco riesgos asociados con la subcontratación del desarrollo d e WebApps 1 7 . 1 1 . Descríbanse cinco riesgos asociados con el desarrollo en c a s a de las WebApps. 1 7 . 1 2 . Considérense las mediciones para el e s f u e r z o d e ingeniería Web tratadas en la sec 17.5.1. Inténtese desarrollar cinco o m á s mediciones adicionales para u n a o m á s categorías 1 7 . 1 3 . La facilidad de navegación a través de un sitio Web es un indicador importante de la < de la WebApp. Desarróllense dos o tres mediciones con las cuales pudiera indicarse la facilidad navegación. 1 7 . 1 4 . Aprovechando u n a de las referencias sugeridas e n la sección 17.5.2, c o m e n t e c ó m o TM p u e d e n aprovechar las mediciones c o n valor en los negocios para apoyar la toma de decisi pragmática en éstos.

PDF Editor

Los métodos para la formulación d e WebApps y la recopilación d e requisitos se p u e d e n a d e análisis d e métodos similares para el software d e aplicación convencional. Las otras ras r e c o m e n d a d a s en los capítulos 7 y 8 contienen m u c h a información útil para el ingen Web.

C A P Í T U L O 17

543


Flor (Web Business Engineering, Addison-Wesley, 2000) a b o r d a el análisis de negocios y las p r e o c u p a c i o n e s r e l a c i o n a d a s q u e p e r m i t e n al ingeniero Web c o m p r e n d e r mejor las n e c e s i d a d e s del cliente. La facilidad d e u s o de la WebApp e s un c o n c e p t o q u e s u b y a c e a m u c h a d e la inform a c i ó n definida c o m o parte de la formulación y la recopilación d e requisitos. Krug y Black

(Don't Make me Think: A Common Sense Approach to Web Usabiiity, Que Publishing, 2000) contiene m u c h a s directrices y e j e m p l o s q u e p u e d e n a y u d a r al ingeniero Web a traducir los requisitos del u s u a r i o e n u n a WebApp efectiva. La gestión de p r o y e c t o p a r a los proyectos lWeb parte de m u c h o s d e los m i s m o s principios y c o n c e p t o s aplicables e n proyectos d e s o f t w a r e convencional. Sin e m b a r g o , agilidad e s un l e m a . Wallace (Extreme Programmingfor Web Projects, Addison-Wesley, 2003) describe c ó m o se p u e d e a p r o v e c h a r el desarrollo ágil para la lWeb y c o n t i e n e análisis útiles d e conflictos d e gestión de proyectos. Shelford y Remillard (Real Web Project Management, Addison-Wesley, 2003), O'Connell (How to Run SuccessfuI Projects in Web Time, Arthec House, 2000), Freidlein (Web

Project Management, Morgan Kaufman, 2000) y Gilbert (90 Days to Launch: Internet Projects on Time and on Budget, Wiley, 2000) t r a t a n una amplia variedad d e t e m a s d e gestión d e proyectos

para lWeb. Whitehead (Leading a Software Development Team, Addison-Wesley, 2001) presenta m u c h o s l i n c a m i e n t o s útiles q u e p u e d e n a d a p t a r los e q u i p o s d e ingeniería Web. Las t é c n i c a s para u s a r m e d i c i o n e s Web e n la t o m a de decisiones e m p r e s a r i a l e s s e p r e s e n tan e n libros c o m o los d e S t e r n e [STE02], Inan [1NA02], Nobles [NOBOU y Menasce y Almeida

(Capacity Planning for Web Services: Metrics, Models and Methods, Prentice-Hall, 2001). Las "peores prácticas" son consideradas por Ferry y Ferry (77 Sure-Fire Ways to Kill a Software Project, iUniverse.com, 2000). En Internet está disponible u n a amplia variedad d e f u e n t e s d e información acerca de formulación y planeación p a r a ingeniería Web. Una lista actualizada de referencias en la World Wide Web, r e l e v a n t e p a r a la formulación y la planeación , s e e n c u e n t r a e n el sitio Web d e SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P I T U L O

18 CONCEPTOS CLAVE análisis de navegación

.561

análisis de relación . . . . 5 6 0 árbol d e d a l o s . 5 5 2 ARN

560

casos d e uso . . . 5 4 7 jerarquía

M O D E L A D O DE A N Á L I S I S PARA APLICACIONES W E B

A

primera vista, existe una a p a r e n t e contradicción c u a n d o se considera ri m o d e l a d o de análisis dentro del contexto de la ingeniería Web. Despu:5 de todo, se ha n o t a d o (capítulo 16) que las WebApps tienen una inmediatez y una volatilidad contraria al m o d e l a d o detallado, ya sea en la etapa c e ! análisis o en la del diseño. Y si se realiza algún tipo de modelado, la filosofía á g a (un modelo de proceso a d e c u a d o para m u c h o s proyectos de ingeniería Web) s o l giere que el m o d e l a d o del análisis s e minimice e n favor del m o d e l a d o de disef. ca limitados. Franklin [FRA02] advierte esta situación y escribe: L o s sitios Web, p o r lo g e n e r a l , s o n c o m p l e j o s y e n o r m e m e n t e d i n á m i c o s , Requieren f a s e s d e d e s a r r o l l ó c o r t a s c o n la finalidad d e t e n e r listo el p r o d u c t o y e j e c u t a r l o rápi-

de usuario . . . . 5 4 6

d a m e n t e . C o n f r e c u e n c i a , los d e s a r r o l l a d o r e s v a n directo h a c i a la f a s e d e codificación sin c o m p r e n d e r q u é e s t á n t r a t a n d o d e c o n s t r u i r o c ó m o q u i e r e n construirlo. La cod:

de análisis . . . . 5 4 5 modelo de configuración . . 5 5 9 modelo de contenido . . . 5 5 1 modelo de interacción . . 5 5 4

ficación

r e s p e c t o del s e r v i d o r c o n f r e c u e n c i a s e h a c e ad hoc, l a s tablas d e b a s e s de

d a t o s s e a g r e g a n c o n f o r m e se n e c e s i t a n y la a r q u i t e c t u r a e v o l u c i o n a e n u n a f o r m a a v e c e s n o i n t e n c i o n a l . P e r o a l g u n a i n g e n i e r í a d e s o f t w a r e m o d e l a d a y disciplinada lo g r a r á q u e el p r o c e s o d e d e s a r r o l l o d e s o f t w a r e s e a m u c h o m á s s u a v e y a s e g u r a r á q u e el s i s t e m a W e b s e a m á s s u s t e n t a b l e e n lo f u t u r o .

¿Es posible tenerlo en las dos formas? ¿Se p u e d e hacer "alguna ingeniería software modelada y disciplinada" y todavía así trabajar efectivamente er.

funcional

557

relaciones de contenido

552

m u n d o d o n d e reinan la inmediatez y la volatilidad? La respuesta es un califi do sí.

¿ Q u é e s ? El análisis de una potencial aplicación Web se enfoca en tres preguntas importantes: 1) ¿qué información o contenido se presentará o manipulará?; 2) ¿qué funciones realizará el usuario final?; y 3) ¿qué comportamientos exhibirá la WebApp conforme presente contenido y realice funciones? Las respuestas se representan como parte de un modelo de análisis que abarca una diversidad de representaciones UML. ¿ Q u i é n lo h a c e ? Los ingenieros Web, los desarrolladores de contenido que no son técnicos y los clientes participan en la creación del modelo de análisis.

¿Por q u é e s i m p o r t a n t e ? A lo largo de e r ; libro se ha resaltado la necesidad de compreder el problema antes de comenzar a resolverle El modelado de análisis es importante no porqt e permita que un equipo de ingeniería Web desarrolle un modelo concreto de requisitos WebAp: TM (las cosas cambian muy frecuentemente corr : para que esto sea una expectativa realista), sir: que, más bien, permite que un ingeniero We: defina aspectos fundamentales del problema elementos cuyo cambio no es probable (en ufuturo cercano). El diseño y la construcción se facilitan cuando se comprenden el contenido, : función y el comportamiento fundamentales.

PDF Editor 544

CAPÍTULO 18

M O D E L A D O DE ANÁLISIS P A R A A P L I C A C I O N E S WEB

s s o n los p a s o s ? El modelado de análiie enfoca en los aspectos fundamentales del a: contenido, interacción, función y con¡ón. El análisis de contenido identifica las y colaboraciones de contenido. El análisis ¡a interacción describe los elementos básicos a interacción del usuario, la navegación y los pcrtamientos del sistema que ocurren. El .sis de las funciones define las funciones de WebApp que realizará el usuario y la secuende procesamiento que ocurre como conse-

545

cuencia. El análisis de la configuración identifica el ambiente(s) operativo en ei cual reside la WebApp. ¿Cuál e s el p r o d u c t o o b t e n i d o ? El modelado de análisis lo integran un conjunto de diagramas y textos UML que describen el contenido, la interacción, la función y la configuración. ¿Cómo p u e d o estar seguro d e que lo he h e c h o c o r r e c t a m e n t e ? los productos obtenidos del modelado de análisis se deben revisar para corregirlos, completarlos y darles consistencia.

Un equipo de ingeniería Web d e b e e m p r e n d e r el m o d e l a d o de análisis c u a n d o s e cumplen la mayoría o t o d a s las condiciones siguientes: • La WebApp que se construirá es g r a n d e o compleja. • El n ú m e r o de clientes e s grande. • El n ú m e r o de ingenieros Web y otros colaboradores e s grande. • Las m e t a s y los objetivos (determinados durante la formulación) para la WebbApp afectarán la línea de referencia del negocio. • El éxito de la WebApp tendrá u n a fuerte conexión con el del negocio. Si e s t a s condiciones n o están presentes, lo que le resta importancia al m o d e l a d o de análisis, aprovechar la información obtenida d u r a n t e la formulación y la recopilación de requisitos (capítulo 17) sirve c o m o b a s e p a r a la creación de un m o d e l o de diseño para la WebApp. En tales circunstancias, tal vez se obtenga un m o d e l a d o de análisis limitado, p e r o que terminará incluido en el diseño. 18.1

R E Q U I S I T O S PARA EL A N Á L I S I S DE LAS W E B A P P S El análisis de requisitos para las WebApps abarca tres g r a n d e s tareas: formulación, recopilación de requisitos, 1 y m o d e l a d o de análisis. Durante la formulación s e identifican la motivación (metas) y los objetivos básicos para la WebApp, y también se definen las categorías d e usuarios. Cuando c o m i e n z a la recopilación de requisitos se TM intensifica la comunicación entre el equipo de ingeniería Web y los accionistas (por ejemplo, clientes, usuarios finales). Los requisitos de contenido y funcionales s e e n -

PDF Editor

listan y se desarrollan los e s c e n a r i o s de interacción (casos de uso) escritos d e s d e el p u n t o de vista del usuario final. La intención e s establecer una comprensión básica de por q u é se construirá la WebApp, quién la usará y qué problema) resolverá a sus usuarios. 1

En el capítulo 17 se abordan con detalle la formulación y la recopilación de requisitos.

PARTE TRES


"Los principios d e ingeniería acerca d e planear a n t e s d e diseñar y diseñar antes d e construir h a n resistido c a d a transición tecnológica previa; t a m b i é n sobrevivirán a esta transición." Watts Humphrey

18.1.1 La jerarquía de usuario Las categorías de usuarios finales que interactuarán con la WebApp se identifican c o m o parte de las t a r e a s de formulación y de recopilación de requisitos. En la m a y : - ] ría de los casos, las categorías de usuario son relativamente limitadas y n o neces.-j tan u n a representación UML. Sin embargo, c u a n d o crece el n ú m e r o de categorías ae usuario, a veces es aconsejable desarrollar u n a jerarquía de usuarios, c o m o se muestra en la figura 18.1. La figura muestra a los usuarios del sitio de comercio electrór -I co de HogarSeguroInc.com tratada en los capítulos 16 y 17. ÔNSEJO^. fs bueno idea construir una jerarquía de usuario. Ofrece una visión instantáneo de la población de usuarios y uno morca de verificación que ayudarán o asegurar que se han abordado las necesidades de cada usuario.

Las categorías de usuario (con frecuencia llamados actores) que se muestran e i ] la figura 18.1 indican la funcionalidad que ofrecerá la WebApp; a d e m á s , señalan necesidad de que se desarrollen c a s o s de uso para cada usuario final (actor) anota-] do en la jerarquía. En la misma figura, el u s u a r i o d e H o g a r S e g u r o I n c . c o m en .al parte superior de la jerarquía representa la clase (categoría) de usuario m á s generill y se refina niveles abajo. Un v i s i t a n t e e s un usuario que visita el sitio p e r o n o se re J gistra. Tales usuarios u s u a l m e n t e b u s c a n información general, c o m p a r a n compras n de alguna otra forma están interesados en contenido o funcionalidad "gratuitos" 11J u s u a r i o r e g i s t r a d o dedica tiempo para ofrecer información y se le considera _ J contacto (junto con otros datos demográficos que solicitan las e n t r a d a s de los f e - I mularios). Las subcategorías para los u s u a r i o s r e g i s t r a d o s incluyen:

Jerarquía d e usuarios p a r a HogarSegu-

Usuario de HogarSegurolnc.com

rolnc.com.

O

X Visitante

Usuario registrado

Personal de servicio al cliente

TM

PDF Editor Cliente nuevo

Cliente existente

C A P Í T U L O 18

547

M O D E L A D O DE A N Á L I S E P A R A A P U C A C I O N E S WEB

• Cliente n u e v o : usuario registrado que quiere personalizar y luego comprar componentes de HogarSeguro (y, por tanto, debe interactuar con la WebApp de funcionalidad de comercio electrónico). • Cliente existente: un usuario que ya posee componentes de HogarSeguro y usa la WebApp para 1) comprar componentes adicionales; 2) adquirir información de soporte técnico; o 3) contactar con el soporte al cliente. Los miembros del personal d e servicio al c l i e n t e son usuarios especiales que también pueden interactuar con el contenido y la funcionalidad de HogarSegurolnc.com conforme asisten a los clientes que han establecido contacto con el soporte al cliente de HogarSeguro.

18.1.2 Desarrollo de casos d e uso Franklin [FRA01] se refiere a los casos de uso como "haces de funcionalidad". Esta descripción captura la esencia de esta importante técnica de modelado de análisis. 2 Los casos de uso se desarrollan para cada categoría de usuario descrita en la jerarquía de usuario. En el contexto de la ingeniería Web, el caso de uso en sí mismo es relativamente informal: un párrafo narrativo que describe una interacción específica entre un usuario y la WebApp. 3

1

_L

TM Functonolidod comercio electrónico

PDF Editor 2

Las técnicas para desarrollar casos de uso se analizaron con detalle en capilulos anteriores de este libro (véanse los capítulos 7 y 8).

3

Aunque es posible desarrollar descripciones más formales de casos de uso, la necesidad de agilidad para la lWeb con frecuencia excluye este enfoque

548

P A R T E TRES


La figura 18.2 representa un diagrama UML de caso de uso para la categoría de usuario cliente n u e v o (figura 18.1). Cada óvalo en el diagrama representa un caso d e uso que describe una interacción específica entre el c l i e n t e n u e v o y la WebApp Por ejemplo, la primera interacción se describe con el caso de uso pedir acceso (logir) a HogarSeguroInc.com. No se requeriría m á s de un solo párrafo para describir e~ ta interacción común. La funcionalidad d e las grandes WebApp (y los casos de uso relevantes para ella se anotan adentro de recuadros con líneas punteadas en la figura 18.2. Tales recua dros se conocen como "paquetes" en UML y representan funcionalidad específica. Se advierten dos paquetes: personalización y comercio electrónico. Como ejemplo, considérese el paquete personalización de casos d e uso. Un nuevo cliente debe describir el ambiente doméstico en el cual s e instalará HogarSegur: Para lograrlo, cliente n u e v o inicia los casos de uso describir plano de la casa, seleccionar componentes HogarSeguro y guardar configuración. Considérense los sigui tes casos de uso preliminares escritos desde el punto de vista de un cliente n u e v o Caso de uso: describir plano de la casa ÔNSEJO^ Contorne crece el tamaño de una WebApp, y el modelado de análisis se vuelve más riguroso, los casos de uso preliminares presentados aquí serán expandidos para ajustarse de manera más cercana al formato sugerido en la sección 8.5 del capítulo 8.

La WebApp f o r m u l a r á a l g u n a s p r e g u n t a s g e n e r a l e s acerca del a m b i e n t e e n el cual se plan e a instalar HogarSeguro:

n ú m e r o de h a b i t a c i o n e s y su t a m a ñ o , tipo d e habitación, núme-

ro de pisos, n ú m e r o d e p u e r t a s exteriores y v e n t a n a s . La WebApp permitirá construir u n p l a n o d e la c a s a a p r o x i m a d o al c o n j u n t a r f o r m a s d e l i n e a d a s d e las h a b i t a c i o n e s para cad a piso. El u s u a r i o s e r á c a p a z d e n o m b r a r al p l a n o d e la c a s a y g u a r d a r l o para u n a referencia futura (véase c a s o d e uso: guardar configuración).

Caso de uso: seleccionar componentes HogarSeguro E n t o n c e s la WebApp r e c o m e n d a r á c o m p o n e n t e s d e p r o d u c t o (por ejemplo: p a n e l e s de control, s e n s o r e s , c á m a r a s ) y o t r a s características (por ejemplo, funcionalidad b a s a d a er. PC i m p l e m e n t a d a e n software ) para c a d a habitación y la e n t r a d a exterior. Si el u s u a r i o solicita o p c i o n e s , la WebApp las p r o p o r c i o n a r á si existen. El u s u a r i o o b t e n d r á i n f o r m a d o " descriptiva y d e precios para c a d a c o m p o n e n t e de producto. La WebApp c r e a r á y mostrará u n a factura de materiales c o n f o r m e s e s e l e c c i o n e n varios c o m p o n e n t e s . El u s u a r : t a m b i é n podrá n o m b r a r la factura de m a t e r i a l e s y guardarla para referencia futura (véas
caso de uso: guardar configuración). Caso de uso: guardar configuración

TM

La WebApp permitirá g u a r d a r los d a t o s d e personalización de m o d o q u e el usuario pue-=

PDF Editor

r e g r e s a r d e s p u é s . Podrá g u a r d a r el p l a n o d e la c a s a y la factura de m a t e r i a l e s HogarSeg.

ro q u e eligió para él. Lograr e s t o requiere q u e el usuario p r o p o r c i o n e u n identificador ú" c o para el p l a n o d e la c a s a y la factura d e materiales. También p r o p o r c i o n a r á u - = c o n t r a s e ñ a (password) de c o n f i g u r a c i ó n especial q u e d e b e validarse a n t e s d e q u e p u e c s tener a c c e s o a la i n f o r m a c i ó n g u a r d a d a .

CAPÍTULO 18

549


GARSEGURO

Reflnar casos de uso para WebApps El e s c e n a r i o : Oficina de Doug • Doug Miller (gerente del grupo de ingesoftware HogarSeguro), Sharon Woods, geren: de ingeniería Web del proveedor sta para el sitio Web d e comercio electrónico -uro, y Sam Chen, gerente de la organizasoporte al cliente de HogarSegurolnc.com.

rsación: Sharon, me d a gusto escuchar que las cosas van bien. ¿El modelado d e análisis está casi ( s o n r í e ) : Estamos progresando. El único con> de uso que falta por desarrollar de la jede usuario [figura 18.1 ] es la categoría personal -:o al cliente. ( m i r a n d o a S a m ) : ¿Sam, ahora tú tienes esos de uso?

S h a r o n : Tiene sentido. (Todas las partes leen los casos de uso [a continuación se presenta un ejemplo]): C a s o d e u s o : describir plano de la casa [note que esto difiere del caso de uso del mismo nombre para la cate: g o r í a cliente

nuevo]

S a m : Pediré al cliente [vía telefónica 1 que describo cada habitación de la casa e ingresaré las dimensiones de la habitación y otras características en un gran formulario diseñado específicamente para el personal de soporte al cliente. Una vez que se hayan ingresada los datos de la casa podré guardar los datos con el nombre o número de teléfono del cliente. S h a r o n : Sam, has sido un tanto lacónico en tus descripciones preliminares de caso d e uso. Creo que tendremos que detallarlas un poco. D o u g ( a s i n t i e n d o c o n l a c a b e z a ) : Estoy de acuer-

Los tengo. Se los envié por correo electrónico a . con copia para ti. Aquí está la versión impresa, a Doug y Sharon unas hojas d e papel.) : Como lo vemos, queremos usar el sitio W e b de rSegurolnc.com como una herramienta de soporte los clientes ordenen por teléfono. Nuestros repren d i e n t e s telefónicos completarán todos los formularios -e-iesarios, etc., y procesarán el pedido por el cliente, j : ¿Por qué no sólo remitir al cliente al sitio Web? i (sonríe): Los técnicos piensan que todos se sieni cómodos con la Web. jNo es así! Hay mucha gente a fc que todavía le gusto el teléfono, así que les tenemos que :c- esa opción. Pero no queremos construir un sistema de ^•ocesamiento de solicitudes por separado cuando la majaría de las piezas ya están en el lugar de la Web.

do. S a m ( m a l h u m o r a d o ) : ¿Por qué? S h a r o n : Bueno... mencionas "un gran formulario diseñado específicamente para el personal de soporte al cliente". Vamos a necesitar más detalles. S a m : Lo que quise decir fue que no necesitamos llevar a nuestros representantes por todo el proceso como ustedes lo hacen para un cliente en línea. Un gran formulario resolvería el problema. S h a r o n : Bosquejemos cómo se vería el formulario. Las partes trabajan para proporcionar suficiente detalle que permita al equipo de Sharon emplear en forma efectiva el caso de uso.

TM Aunque es posible ofrecer considerablemente m á s detalle para cada u n o de los c a s o s de uso, la descripción textual informal ofrece una visión útil. Descripciones si-

PDF Editor milares se desarrollarían para c a d a óvalo e n la figura 18.2.

18.1.3 Afinación del modelo de caso de uso

A la par que se crean los d i a g r a m a s de c a s o d e uso para cada categoría de usuario,

se desarrolla u n a vista superior de los requisitos de la WebApp observables de m a -

550

P A R T E TRES


ñera externa. Los casos de uso se organizan en paquetes funcionales, y cada paque te se valora [CONOO] para garantizar que es: se ?• v Cómo a l o r a n los paquetes de casos de uso agrupados p o r la f u n c i ó n usuario?

• Comprensible: todos los clientes entienden el propósito del paquete. • Cohesivo: el paquete aborda funciones relacionadas cercanamente una con otra. • Libremente acoplados: las funciones o clases dentro del paquete colaboran una con otra, pero la colaboración exterior del paquete s e mantiene en un mínimo. • Jerárquicamente superficial: las jerarquías funcionales profundas son difíciles d e navegar y entender para los usuarios; en consecuencia, el número de niveles dentro de una jerarquía de casos de uso debe reducirse siempre que sea posible. Puesto que el análisis de requisitos y el modelado son actividades iterativas, es p r : bable que se sumen nuevos casos de uso a los paquetes que se han definido, que :•& casos de uso existentes sean refinados y que casos de uso específicos puedan reufcw carse en paquetes diferentes.

El modelado de análisis para una WebApp se basa en la información que conti los casos de uso desarrollados para la aplicación. Las descripciones de los casos uso se analizan gramaticalmente para identificar potenciales clases de análisis y i operaciones y atributos asociados con cada clase. Se identifica el contenido que ; sentará la WebApp y se extraen las funciones que se desarrollarán a partir de las i cripciones de caso de uso. Finalmente, los requisitos específicos de la implementa:-^ se deben desarrollar de modo que el ambiente y la infraestructura que apoyan la V. d Apps puedan construirse. Cuatro actividades de análisis, cada una con su aporte a la creación de un m o a lo de análisis completo, son: ¿Qué tipos ' • • de actividad e s de a n á l i s i s o c u r r e n d u r a n t e el m o d e l a d o d e una WebApp?

• Análisis de contenido: identifica todo el espectro del contenido que ofrece-a I WebApp. El contenido incluye texto, gráficas e imágenes, así como datos a ] video y audio.

TM

• Análisis de interacción: describe cómo interactúa el usuario con la WebApo

PDF Editor

• Análisis de funciones: define las operaciones que se aplicarán al contenió: £ la WebApp y describe otras funciones de procesamiento, independientes j a contenido pero necesarias para el usuario final.

• Análisis d e configuración: describe el ambiente y la infraestructura en la - J reside la WebApp.

C A P Í T U L O 18

551


La información recopilada durante las tareas de estos cuatro análisis se debe revisar, modificar c u a n d o se requiera y luego organizarse en un modelo que pueda pasarse a los diseñadores de WebApp. El modelo en si mismo contiene elementos estructurales y dinámicos. Los elementos estructurales identifican las clases de análisis y los objetos de contenido que se requieren para crear una WebApp que satisfaga las necesidades de los clientes. Los elementos dinámicos del modelo de análisis describen c ó m o interactúan los elementos estructurales, entre ellos y con los usuarios finales. "[Los WebApps] exitosas permiten que los dientes satisfagan mejor sus necesidades, m á s rápido o m á s barato por sí mismos, que el trabajar a través del empleado [de una compañía] para los usuarios finales." M a r k McDonald

18.3

EL M O D E L O DE C O N T E N I D O

El modelo de contenido contiene elementos estructurales q u e proporcionan una importante visión de los requisitos de contenido para una WebApp. Dichos elementos estructurales incluyen objetos de contenido (por ejemplo: texto, imágenes gráficas, fotograñas, imágenes de video, audio) que se presentan c o m o parte de la WebApp. Además, el modelo de contenido incluye todas las clases de análisis: entidades visibles para el usuario que se crean o manipulan conforme éste interactúa con la WebApp. Una clase de análisis incluye atributos que la describen, operaciones que afectan el comportamiento requerido de la clase y colaboraciones que permiten la comunicación de la clase con otras clases. Al igual que otros elementos del modelo de análisis, el modelo de contenido se deriva a partir de un e x a m e n cuidadoso de los casos de uso desarrollados para la WebApp. Los c a s o s de uso se analizan gramaticalmente para extraer objetos de contenido y clases de análisis.

18.3.1 Definición de objetos de contenido Las aplicaciones Web presentan información preexistente —llamada contenido—

% CLAVE objeto de contenido cualquier artículo de •formación cohesivo a í se presentará o un .sjorio final. Usual-ente, los objetos de a t e n i d o se extraen é los casos de uso.

a

un usuario final. El tipo y forma del contenido abarca un amplio espectro de elaboración y complejidad. El contenido puede desarrollarse a n t e s de la implementación de la WebApp, mientras ésta se construye o m u c h o d e s p u é s de que la WebApp se encuentra en operación. En cada caso, se incorpora por medio de referencias de naveTM gación e n la estructura global de la WebApp. Un objeto de contenido p u e d e ser una descripción textual de un producto, un artículo que describa un evento noticioso,

PDF Editor

u n a fotografía de acción t o m a d a en un cotejo deportivo, una representación anima da de un logotipo corporativo, un breve video de un discurso o un recubrimiento de audio para u n a colección de diapositivas Powerpoint. Los objetos de contenido se extraen de los casos de uso al examinar la descripción del escenario para referencias directas e indirectas al contenido. Por ejemplo, en el caso d e uso seleccionar componentes

HogarSeguro, se encuentra la oración:

552

P A R T E TRES


Seré capaz de obtener información descriptiva y d e precios para cada componente de producto. Aunque no existe referencia directa al contenido, está implícita. El ingeniero Wer podría reunirse con el autor del caso de uso y comprender en forma más detallada lo que significa "información descriptiva y de precios". En este caso, el autor del caso de uso puede indicar que "información descriptiva" incluye 1) una descripción general del componente en un párrafo; 2) una fotografía del componente; 3) una descripción técnica del componente en varios párrafos; 4) un diagrama esquemático decomponente que muestre cómo encaja en un sistema HogarSeguro típico; y 5) un breve video que muestre cómo instalar el componente en una configuración domés tica típica. Es importante advertir que cada uno de estos objetos d e contenido debe desarrollarse (con frecuencia a través de desabolladores de contenido que no son ingeni; ros Web) o adquirirse para integrarlo en la arquitectura de la WebApp (analizada er el capítulo 19). " l o Web: t a n t o totifenido, t a n p o c o t i e m p o . " Anónimo

18.3.2 Relaciones y jerarquía de contenido

%

CLAVE Un árbol de dotos represento uno jerarquía de objetos d e contenido.

En m u c h a s instancias, una simple lista de objetos de contenido, pareadas con ur a breve descripción de cada objeto, es suficiente para definir los requisitos para el con-j tenido que deben diseñarse e implementarse. Sin embargo, en algunos casos, el modelo de contenido puede contener diagramas de relación de entidades (capítulo 8 v árboles de datos [SR10I] que bosquejan las relaciones entre los objetos de contenic: o la jerarquía de éste que mantiene una WebApp. Considérese el árbol de datos creado para el componente HogarSeguro que muestra en la figura 18.3. El árbol representa una jerarquía de información con que

DescripciónDeMarketing

Arbol de datos para un componente

parteNúmero

HogarSeguro. parteNombre componente

parteTipo

Fotografía DescripciónTécnica

TM

Esquema

PDF Editor descripción

Video

precio

PrecioMayorista PrecioMinorista

C A P Í T U L O 18

M O D E L A D O DE ANÁLISIS P A R A APLICACIONES WEB

553

se describe el c o m p o n e n t e (más adelante se verá que, en realidad, un c o m p o n e n t e HogarSeguro

es una clase de análisis para esta aplicación). Los artículos de datos

simples o c o m p u e s t o s (uno o m á s valores de datos) se representan c o m o rectángulos sin s o m b r e a d o . Los objetos de contenido se representan c o m o rectángulos s o m breados. En la figura, d e s c r i p c i ó n se define por medio de cinco objetos de contenido (los rectángulos sombreados). En algunos casos, u n o o m á s de dichos objetos se retinará m á s todavía c o n f o r m e s e expanda el árbol d e datos.

18.3.3 Clases 4 de análisis p a r a WebApps C o m o ya se ha señalado, las clases de análisis se derivan al e x a m in a r cada c a s o de uso. Por ejemplo, considérese el c a s o de uso preliminar: seleccionar componentes

Ho-

garSeguro que se presentó en la sección 18.1.2. Caso de uso: seleccionar componentes HogarSeguro E n t o n c e s la WebApp r e c o m e n d a r á c o m p o n e n t e s d e p r o d u c t o (por ejemplo: p a n e l e s d e control, s e n s o r e s , c á m a r a s ) y o t r a s c a r a c t e r í s t i c a s (por e j e m p l o , f u n c i o n a l i d a d b a s a d a e n PC i m p l e m e n t a d a e n s o f t w a r e ) p a r a c a d a h a b i t a c i ó n y la e n t r a d a exterior. Si el u s u a r i o s o licita o p c i o n e s , la WebApp las p r o p o r c i o n a r á si e x i s t e n . El u s u a r i o o b t e n d r á i n f o r m a c i ó n descriptiva y d e p r e c i o s p a r a c a d a c o m p o n e n t e d e p r o d u c t o . La WebApp c r e a r á y m o s t r a rá u n a factura d e m a t e r i a l e s c o n f o r m e s e s e l e c c i o n e n varios c o m p o n e n t e s . El u s u a r i o t a m b i é n p o d r á n o m b r a r la factura d e m a t e r i a l e s y guardarla p a r a r e f e r e n c i a futura (véase

caso de uso: guardar configuración). Un rápido análisis gramatical del c a s o de uso identifica dos clases c a n d id a tas (subrayadas): C o m p o n e n t e D e P r o d u c t o y F a c t u r a D e M a t e r i a l e s En la figura 18.4 s e muestra u n a primera descripción de cada clase. La clase C o m p o n e n t e D e P r o d u c t o abarca todos los c o m p o n e n t e s de HogarSeguro que se pueden c o m p r a r para personalizar el producto destinado a u n a instalación particular. Es u n a representación generalizada de S e n s o r , Cámara, P a n e l d e Control y C a r a c t e r í s t i c a d e S o f t w a r e Cada objeto de C o m p o n e n t e D e P r o d u c t o contiene información que corresponde al árbol de datos que se muestra en la figura 18.3 para la clase. Algunos de estos atributos de clase son artículos de d a t o s sencillos o compuestos, y otros son objetos de contenido (véase la figura 18.3). También se m u e s t r a n las o p e r a c i o n e s relevantes para la clase. La clase F a c t u r a D e M a t e r i a l e s abarca una lista de c o m p o n e n t e s q u e c l i e n t e n u e v o h a seleccionado. F a c t u r a D e M a t e r i a l e s es en realidad un a g r e g a d o de ArtículoFdM (muchas instancias de ArtículoFdM c o m p r e n d e n una FTM acturaDeMateriales):

una clase que construye u n a lista c o m p u e s t a de cada c o m p o n e n t e que se

c o m p r a r á y de atributos específicos acerca del componente, c o m o se muestra en la

PDF Editor figura 18.4.

4 En el capítulo 8 se presentaron en forma detallada los mecanismos para identificar y representar las clases de análisis. Si todavía no se ha hecho, el capitulo 8 debe revisarse en este momento.

554

PARTE TRES


Clases d e

Factura DeMateriales

análisis p a r a

ComponentedeProducto

el c a s o d e

parteNúrnero porleNombre parfeTipo descripción precio

uso: seleccionar componentes HogcaSeguro.

crearNuevoArtículoj) abtenerDescripciónQ o b t e n erEspecTócnica ()

identificador precioTotal agregarEn»rada(} b o r r a r E n t r a d a () edítarEnfrada() nombre() guardarj) calcuIarPrecio{)

ArtículoFdM Sensor

Cámara

P o n e l D o C o til-rol

cantidad precio a g r e g a r a Lista 0 borrardeLista(j

Cada caso de uso identificado para HogarSeguroInc.com se analiza gramatical! mente para objetos de análisis. Respecto a cada caso se uso se desarrollan mod de clase similares al descrito en esta sección.

• La gran mayoría de las WebApps permite una "conversación" entre un usuario fina y la funcionalidad, el contenido y el comportamiento de una aplicación. Este motp?! lo de interacción lo componen cuatro elementos: 1) casos de uso, 2) diagramas de s-r-l cuencia, 3) diagramas de estado, 5 y 4) un prototipo de interfaz de usuario. Ade~ de estas representaciones, la interacción también s e representa dentro del conté del modelo de navegación (sección 18.7). ^COKSEJO^. Es posible utilizar las técnicas asociadas con el análisis de toreas (capitulo 12) poto ayudarse a definir los modos de interacción del usuario.

C a s o s d e u s o . Los casos de uso son el elemento dominante del modelo de inieJ racción para las WebApps. No e s raro describir 100 o más casos de uso cuando analizan, diseñan y construyen grandes y complejas WebApps. Sin embargo, un pcc-j centaje relativamente bajo de estos casos de uso describe las principales interaca :-f nes entre las categorías de usuario final (actores) y el sistema. Otros casos de uso r finan las interacciones y proporcionan el detalle de análisis necesario para guiar TM diseño y la construcción. Diagramas de s e c u e n c i a .

Los diagramas de secuencia UML ofrecen una re

PDF Editor

sentación abreviada de la forma en la cual las acciones del usuario (los element: dinámicos de un sistema que definen los casos de uso) colaboran con las clases

5

C a d a u n o d e é s t o s e s u n a i m p o r t a n t e n o t a c i ó n U M L q u e s e d e s c r i b i ó e n el c a p i t u l o 8.

C A P I T U L O 18


555

i de i el c a s o

ates

análisis (los elementos estructurales de un sistema que definen los diagramas de clase). Dado que las clases de análisis se extraen de las descripciones de caso de uso, existe la necesidad de garantizar que hay una forma de realizar un seguimiento entre las clases definidas y los casos de uso que describen la interacción del sistema.

*

[CONSEJO

En capítulos anteriores se apreció que los diagramas de secuencia proporcionan un vínculo entre las acciones descritas en el caso de uso y las clases de análisis (entidades estructurales). Conallen |CONOO] señala esto cuando escribe: "La mezcla de elementos dinámicos y estructurales del modelo [de análisis] es el vínculo clave en la capacidad de seguimiento del modelo y se debe considerar muy seriamente." En la figura 18.5 se muestra un diagrama d e secuencia para el caso de uso seleccionar componentes HogarSeguro. El eje vertical del diagrama muestra las acciones que s e definen dentro del caso de uso. El eje horizontal identifica las clases de análisis que se usan conforme procede el caso de uso. Por ejemplo, un cliente nuevo primero debe describir cada habitación de la casa (el asterisco a continuación de "describir habitación" indica que la acción es iterativa). Para lograr esto, el cliente nuevo responde preguntas acerca del tamaño de la habitación, puertas y ventanas, etcétera. Una vez definida una habitación, se coloca en un plano de la casa. Entonces el cliente nuevo describe la siguiente habitación o procede a la siguiente acción (guardar la configuración del plano de la planta). El movimiento a través yTM hacia abajo del diagrama de secuencia enlaza cada clase de análisis con las acciones del caso de uso. Si en el diagrama s e pierde una acción de caso de uso, el ingeniero Web debe reevaluar la descripción de las clases de análisis para determinar si una o m á s cla-

PDF Editor

ses se han perdido. Es posible crear diagramas de secuencia para cada caso de uso una vez que s e definen las clases de análisis para el caso de uso. Diagramas de e s t a d o . El diagrama de estado UML (capítulo 8) ofrece otra repre-

sentación del comportamiento dinámico de la WebApp conforme sucede una inter-

556

P A R T E TRES


D i a g r a m a de e s t a d o parcial p a r a interacción con cliente nuevo.

Validar m u o r i o

O A

E s t a d o s i s t e m a - " e n t r a d a lisio" S e l e c c i o n a r M u e s t r a m j j - " i n g l e s a r id d e u s u a r i o * *occeso" M u e s t r a msj - " i n g r e s a r c o n t r a s e ñ a " e n f r o d o / o c c e s o solicitado hoce; correr validación d o usuario s a l i d a / e s t a b l e c e r interruptor a c c e s o usuario

C líenlo nuevo

Personalización completa

C

usuario vat.doda

contraseño volidoda

Seleccionar acción usuario

Seleccionar otros (unciones

E s t a d o s i s t e m a » " v í n c u l o lista" Muestro: " e l e c d o n e s de n a v e g a r ió n " entrodo/usuario validodo h a c e : vincular c o m o s e solicita s a l i d a / a c c i ó n usuario seleccionada

Seleccionar funcionalidad comercio electrónico (compra!

Seleccionar funcionalidad personalización Siguiente selección PersoooEzor E s t a d o sistemo - " e n t r a d o lista" M u e s t r a : instrucciones b ó s i c a s

Seleccionar contenido —^descriptivo

Seleccionar contenido I descriptivo

entrada/usuario validado h a c e : proceso selección usuario salida/personalización terminada

Definí, h a b í E s t a d o sistema • " e n t r a d a l i s t a ' M u e s t r a : v e n t a n a def. h a b i t a c i ó n entrada/def. habitación seleccionado hace: corro consulta habitación haco: a l m a c e n a variables habitación salida/habitación completada S e l e c c i o n a r g u a r d a r p l a n o d e la p l a n t a

S e l e c c i o n a r i n g r e s a r h o b i t o c i ó n en p l o n o d e la plonto

Inserción h a b i t a c i ó n c o m p l e t a d a

•

G u a r d a r plano d e lo c o s o E s t a d o s i s t e m a - " e n t r a d o lista" Muestra: indicador almacenamiento e n t r a d a / g u a r d a r hobilación s e l e c c i o n a d a e n p l a n o d e la p l a n t a h o c e , a l m a c e n a p l a n o d o la p l a n t a salido/guardado completado

Construir p l a n o d e b c o s a

^vdescr&m

E s t a d o sistema - " e n t r a d a lista* M u e s t r a : v e n t a n a p l a n o d e la p l a n t a e n t r a d a / p l a n o de lo c a s a s e l e c c i o n a d o h a c e : insertar h a b i t a c i ó n e n lugar h a c o : g u a r d a r v a r i a b l e s p l a n o d e la p l o n t o salido/inserción habitación completada

acción. Al igual que la mayoría de las representaciones de m o d e l a d o utilizadas i ingeniería Web (o en la ingeniería del software), el diagrama de e s t a d o p u e d e sentarse en diferentes g r a d o s de abstracción. La figura 18.6 muestra la vista su~ (mayor grado de abstracción) de un diagrama de e s t a d o parcial para la i n t e r entre un cliente n u e v o y la WebApp de HogarSegurolnc.com. En el diagrama de e s t a d o que se muestra se identifican seis estados obse~ externamente: validar usuario, seleccionar acción del usuario, personalizar,

dejir,ir .-

bitación, construir plano de la casa y guardar plano de la casa. El diagrama de indica las acciones que se requieren para mover al cliente nuevo de u n e s t a d o a • la información que se muestra c o n f o r m e se ingresa un estado, el procesamiento > ocurre dentro de u n e s t a d o y la condición de salida que provoca u n a transición un e s t a d o a otro.

TM Puesto que los c a s o s de uso, los d i a g r a m a s de secuencia y los diagramas de

t a d o m u e s t r a n información relacionada, es razonable preguntar por qué son

PDF Editor

s a n o s los tres. En algunos c a s o s no lo son. Los c a s o s de uso tal vez sean sufic en algunas situaciones. Sin embargo, los c a s o s de uso proporcionan una visiór bien unidimensional de la interacción. Los diagramas de secuencia p r e s e n t a r segunda dimensión que en esencia es m á s de procedimiento (dinámica). Los m a s de e s t a d o proporcionan u n a tercera dimensión que se refiere m á s al co m i e n t o y contiene información acerca de los p a t r o n e s de navegación pote

C A P I T U L O 18


557

que n o proporcionan los casos de uso o el diagrama de secuencia. Cuando se usan las tres dimensiones, las omisiones o inconsistencias que pueden escapar en una dimensión se vuelven obvias cuando se examina una segunda (o tercera) dimensión. Por esta razón, los grandes WebApps complejas pueden beneficiarse de un modelo de interacción que abarque las tres representaciones. Prototipo d e la interfaz de usuario. La plantilla de la interfaz de usuario, el contenido que presenta, los mecanismos de interacción que implementa y la estética global de las conexiones usuario-WebApp, tienen mucho q u e ver con la satisfacción del usuario y la aceptación global de la WebApp. Aunque se puede argumentar que la creación de un prototipo de interfaz de usuario es una actividad de diseño, es una buena idea realizarla durante la creación del modelo de análisis. Mientras más rápido s e pueda revisar la representación física de una interfaz de usuario, mayor será la probabilidad de que los usuarios finales obtengan lo que quieren. En el capítulo 12 se aborda el análisis de la interfaz de usuario y su diseño. Puesto que las herramientas de desarrollo de la WebApp son abundantes, relativamente baratas y funcionalmente poderosas, es mejor crear el prototipo de la interfaz mediante tales herramientas. El prototipo debe implementar los principales vínculos de navegación y representar la plantilla de pantalla global en gran parte como será construida.

El modelo funcional aborda dos elementos de procesamiento de la WebApp y cada uno representa un grado diferente de la abstracción de procedimiento: 1) funcionalidad observable respecto al usuario y que entrega al usuario final la WebApp, y 2) las operaciones dentro de las clases de análisis que implementan comportamientos asociados con la clase. La funcionalidad observable para el usuario comprende cualesquiera funciones de procesamiento que éste inicia directamente. Por ejemplo, un sitio Web financiero puede implementar una variedad de funciones financieras (como una calculadora para fondo de matricula universitaria o una calculadora para fondo de retiro). Dichas funciones en realidad pueden implementarse mediante operaciones dentro de las clases de análisis, pero, desde el punto de vista del usuario final, la función (más precisamente, los datos que proporciona la función) es el resultado visible. TM En un grado inferior de abstracción procedimental, el modelo de análisis describ e el procesamiento que realizarán las operaciones de la clase de análisis. Dichas operaciones manipulan atributos de la clase y están involucradas como clases que colaboran entre sí para lograr algún comportamiento requerido.

PDF Editor

Sin importar el grado de abstracción procedimental, con el diagrama de actividad UML se representan detalles de procesamiento. La figura 18.7 muestra un diagrama de actividad para la operación calcularPreciot < que forma parte de la clase de análi-

558

P A R T E TRES


Diagrama de actividad par a la operac i ó n calculaiPrecio().

N i n g ú n c o m p o n e n t e p e r m a n e c e en listaFdM

(

c o & f o l í n e o <* precio ¥ c a n t i d a d

f w

f V

a

| J

Sumar coiloUnoa \ _ costoTotal 1

» > ° /coatoTotol . \ ' \ cosioTotol - d e s c u e n t o !

( impuesto Jo lot - \ ycosloTotol V tosaimpuGsloJ

í I I

é

ÔNSEJO^ Como alternativa, también es posible escribir uno simple narración del procesamiento o representación en lengua/e de programación de diseño (capitulo 11). Sin embargo, muchas personas prefieren una representación gráfica.

precioTatal coitoTo'o 4 costoEmbarque

sis FacturaDeMateriales 6 Como se anotó en el capítulo 8, el diagrama de activi es similar al diagrama de flujo, el cual ilustra el flujo de procesamiento y las decines lógicas del flujo. Debe notarse que, dentro del flujo procedimental, se i n v dos operaciones adicionales: ca!cCostoEmbarque(), que calcula el costo de embar dependiendo del método que haya elegido el cliente, y determiriarDescuento(), que termina cualquier descuento especial para los componentes HogarSeguro elegi TM para comprar. Los detalles de construcción que indican cómo se solicitan estas raciones y los detalles de la interfaz para cada operación n o se consideran sino

PDF Editor ta que comienza el diseño WebApp. 6

Una revisión de la clase de análisis FacturaDeMateriales puede determinar que, con la Ínter de cohesionar, la operación calcularPreáo() puede colocarse mejor en una clase Facturas. Esta gerencia tiene mérito. Sin embargo, permanece dentro de la clase de análisis FacturaDeMat les para los propósitos de este ejemplo.

CAPÍTULO 18


559

Las WebApps se deben diseñar e implementar de forma que se a c o m o d e n a una diversidad de ambientes, tanto en lado del servidor c o m o en el del cliente. 7 La WebApp puede residir en un servidor que proporcione acceso vía Internet, una Intranet o una Extranet. Se deben especificar el hardware del servidor y el ambiente del sistema operativo. Además, se deben considerar aspectos de interoperabilidad en el lado del servidor. Si la WebApp debe tener acceso a una gran base de datos o interoperar con las aplicaciones corporativas existentes en el lado del servidor, se deben especificar las interfaces apropiadas, los protocolos de comunicación y la información complemen-

* fimporrtodos rrtolilir .rizadas, ¡una ssome3 pora

r:sususuoi no a lo i de un narxnkular.

taria necesaria. El software del lado del cliente proporciona la infraestructura que permite el acceso a la WebApp desde la ubicación del usuario. En general, el software de navegación se utiliza para entregar el contenido y la funcionalidad de la WebApp que se descargan del servidor. Aunque existen estándares, cada navegador tiene sus propias peculiaridades. Por esta razón, la WebApp debe someterse a una amplia prueba en cada configuración de navegador que se especifique c o m o parte del modelo de configuración. En algunos casos, el modelo de configuración n o es m á s que una lista de atributos tanto del lado del servidor como del cliente. Sin embargo, para WebApps m á s elaboradas, varias complejidades de configuración (por ejemplo: distribución de carga entre múltiples servidores, arquitecturas de caché, b a s e s de datos remotas, múltiples servidores que sirven a varios objetos en la misma página Web) pueden impactar el análisis y el diseño. Es factible aprovechar el diagrama de despliegue UML (capítulo 10) en situaciones en las cuales se deban considerar arquitecturas de configuración complejas.

Los elementos del modelo de análisis descritos en las secciones previas identifican los elementos de contenido y funcionalidad, junto con la forma en que se utilizan para implementar la interacción con el usuario. Conforme el análisis evoluciona en diseño, dichos elementos se vuelven parte de la arquitectura de la WebApp. En el contexto de las aplicaciones Web, cada elemento arquitectónico tiene el potencial de vincularse con todos los otros elementos arquitectónicos. Pero, conforme a u m e n t a el número de vínculos, la complejidad de navegación a través de la WebApp también TM crece. Entonces, la pregunta es c ó m o establecer los vínculos apropiados entre los objetos de contenido y las funciones que proporcionan las capacidades que requie-

PDF Editor re el usuario.

El lado del servidor hospeda la WebApp y todas las características de sistema relacionadas que permiten a múltiples usuarios tener acceso a la WebApp vía una red. El lado del cliente proporciona un ambiente de software (por ejemplo, navegadores) que permite a los usuarios finales interactuar con la WebApp en el escritorio del usuario.

560

P A R T E TRES


"[La n a v e g a c i ó n ] no sólo e s la acción d e saltar d e p á g i n a a página, sino la idea d e m o v e r s e a través d e un espacio d e información." A. Reina y J . Torres

El análisis relación-navegación (ARN) proporciona una serie d e pasos de anális.í 1 que luchan por identificar relaciones entre los elementos descubiertos c o m o parte ce I la creación del modelo de análisis.® Yoo y Bieber [YOOOO] describen un ARN del m< do siguiente: El ARN proporciona a los analistas d e s i s t e m a s una técnica sistemática para determinar la estructura de relación d e u n a aplicación, lo que les ayuda a descubrir las relaciones potencialmente útiles en los dominios de la aplicación y que se p u e d e n implementar c o m o vínculos m á s adelante. El ARN también ayuda a determinar las estructuras de navegación apropiadas sobre e s t o s vínculos. El ARN fomenta la comprensión d e los desarrolladores de s i s t e m a s en t o m o a los dominios d e la aplicación al ampliar y profundizar su modele conceptual del dominio. Entonces los desarrolladores p u e d e n mejorar su implementación al incluir vínculos, metainformación y navegación adicionales.

El enfoque ARN se organiza en cinco pasos: • Análisis de los participantes: identifica las diversas categorías de usuario (co i mo se describe en la sección 18.1) y establece u n a apropiada jerarquía de par-I ticipantes. • Análisis de elementos: identifica los objetos de contenido y los elementos f u r - l d ó n a l e s de interés para los usuarios finales (como se describe en las seccio- l ne s 18.3 y 18.5). • Análisis de relaciones: describe las relaciones entre los elementos WebApp. • Análisis de navegación: examina c ó m o los usuarios pueden acceder a elementos individuales o grupos de elementos. • Análisis de evaluación: considera temas pragmáticos (por ejemplo: costo/be I neficio) asociados con la implementación de las relaciones definidas con anterioridad. Los primeros dos pasos en el enfoque ARN se trataron en párrafos anteriores de e - l te capítulo. En las siguientes secciones se consideran métodos para establecer asi relaciones entre los objetos de contenido y las funciones.

18.7.1 Análisis d e relaciones: preguntas clave

TM

Yoo y Bieber [YOOOO] sugieren una lista de preguntas que un ingeniero Web o an=-l

PDF Editor

lista de sistemas deben responder acerca de cada elemento (objeto de contenido •

8

Se debe señalar que el ARN es aplicable a cualquier sistema de información y originalmente se o d sarrolló para los sistemas hipermedia en general. Sin embargo, es posible adaptarlo muy bien ; | l ingeniería Web.

C A P I T U L O 18


561

función) identificado dentro del modelo de análisis. La siguiente lista, adaptada para WebApps, e s representativa [YOOOO]: ¿Cómo s e c l o r a n los del fa a n á f i s i s irender

• ¿El elemento es miembro de una categoría de elementos más amplia? . ¿Qué atributos o parámetros se han identificado para el elemento? • ¿Ya existe información descriptiva acerca del elemento? Si es así, ¿dónde está? • ¿El elemento aparece en diferentes ubicaciones dentro de la WebApp? Si es así, ¿dónde? • ¿El elemento lo componen otros pequeños elementos? Si es así, ¿cuáles son? . ¿El elemento es miembro de una colección de elementos mayor? Si es así, ¿cuál es y cuál es su estructura? • ¿Al elemento lo describe una clase de análisis? • ¿Otros elementos son similares al elemento considerado? Si es así, ¿es posible que pudieran combinarse en un elemento? • ¿El elemento se usa en un ordenamiento específico de otros elementos? ¿Su aparición depende de otros elementos? • ¿Otro elemento siempre sigue a la aparición del elemento considerado? • ¿Qué condiciones previas y posteriores se deben satisfacer para utilizar el elemento? • ¿Categorías de usuario específicas aprovechan al elemento? ¿Las diferentes categorías de usuario emplean de manera diferente al elemento? Si es así, ¿cómo? • ¿El elemento puede estar asociado con una meta u objetivo de formulación específico? ¿Con un requisito WebApp específico? • ¿Este elemento siempre aparece al mismo tiempo que aparecen otros elementos? Si es así, ¿cuáles son los otros elementos? • ¿Este elemento siempre aparece en el mismo lugar (por ejemplo, misma ubicación de la pantalla o página) que otros elementos? Si e s así, ¿cuáles son los otros elementos? Las respuestas a éstas y otras preguntas ayudan al ingeniero Web a posicionar el elemento en cuestión dentro de la WebApp y a establecer relaciones entre elementos. Es posible desarrollar una relación taxonómica y categorizar cada TM relación iden tificada debido a las preguntas anotadas. El lector interesado debe remitirse a [YOOOO] para más detalles.

PDF Editor 18.7.2 Análisis de navegación

Una vez que entre los elementos se han desarrollado relaciones definidas dentro del modelo de análisis, el ingeniero Web debe considerar los requisitos que dictan cómo navegará cada categoría de usuario de un elemento (por ejemplo, objeto de conté-

562

PARTE TRES


nido) a otro. Los mecanismos de navegación se definen como parte del diseño. En esta etapa, los desarrolladores deben considerar requisitos de navegación globales Las siguientes preguntas se deben plantear y responder: ¿Qué pre• guntas se deben plantear para comprender m e ¡ o r los requisitos de navegación?

• ¿Ciertos elementos deben ser más fáciles de alcanzar (es decir, requieren menos pasos de navegación) que otros? ¿Cuál e s la prioridad de presentación? • ¿Ciertos elementos deben resaltarse para forzar a los usuarios a navegar en su dirección? • ¿Cómo s e manejarán los errores de navegación? • ¿La navegación hacia grupos de elementos relacionados debe ser prioritaria sobre la navegación hacia un elemento específico? • ¿La navegación se debe lograr por medio de vínculos, de acceso basado en búsqueda o por otros medios? • ¿Ciertos elementos se deben presentar a los usuarios con base en el contexto de acciones de navegación previas? • ¿El acceso a la navegación debe mantenerse para los usuarios?

ÔNSEJO^ Mientras se onalizan los requisitos de navegación, recuérdese que el usuario siempre debe saber dónde estó y o dónde va. Para lograrlo el usuario necesito un "mapa".

• ¿En cada punto de la interacción del usuario debe estar disponible un mapa o menú de navegación completo (en oposición a un simple vínculo de "retroceso" o puntero dirigido)? • ¿El diseño de la navegación debe nutrirse de los comportamientos de usuario más comúnmente esperados o mediante la importancia percibida d e los elementos WebApp definidos? • ¿Un usuario puede "almacenar" su navegación previa a través de la WebApp para un uso futuro expedito? • ¿Para qué categoría de usuario se debe diseñar una navegación óptima? • ¿Cómo se manejarán los vínculos externos a la WebApp? ¿Superponiendo la ventana de navegador existente? ¿Cómo una nueva ventana de navegador? ¿Cómo un marco separado? Éstas y muchas otras preguntas s e deben plantear y responder como parte del análisis de navegación. El equipo de ingeniería Web y s u s participantes también deben determinar los re quisitos globales para la navegación. Por ejemplo, ¿se proporcionará un "mapa de TM de la WebApp" sitio" para brindar a los usuarios un panorama integral de la estructura ¿El usuario puede realizar un "recorrido" que subraye los elementos más importantes (objetos de contenido y funciones) disponibles? ¿Un usuario tendrá la capacidac de acceder a los objetos de contenido o funciones con base en los atributos definidos de dichos elementos (por ejemplo, un usuario tal vez desee acceder a todas la: fotografías d e u n a construcción específica o a todas las funciones que permitan e! cálculo del peso)?

PDF Editor

CAPÍTULO 18

563


'

:

'

La formulación, la recopilación de requisitos y el modelado de análisis se llevan a cabo c o m o parte del análisis de requisitos para las WebApps. El propósito de dichas actividades es 1) describir la motivación básica (metas) y objetivos para la WebApp; 2) definir las categorías de usuarios; 3) señalar los requisitos de contenido y de función para la WebApp; y 4) establecer una comprensión básica de por qué se construirá la WebApp, quien la usará y qué problema(s) les resolverá a los usuarios. Los casos de uso son los catalizadores para todos los análisis de requisitos y actividades de modelado. Además, pueden organizarse en paquetes funcionales, y cada paquete se valora para garantizar que e s comprensible, cohesivo, libremente acoplado y jerárquicamente superficial. Cuatro actividades de análisis contribuyen a la creación de un modelo d e análisis completo: el análisis de contenido identifica todo el espectro de contenido que proporcionará la WebApp; el análisis de interacción describe la forma en la que el usuario interactúa con la WebApp; el análisis de funciones define las operaciones que se aplicarán al contenido de la WebApp y describe otras funciones de procesamiento independientes del contenido, pero necesarias para el usuario final; y el análisis de la configuración describe el ambiente de la infraestructura en la que reside la WebApp. El modelo de contenido describe el espectro d e los objetos correspondientes que serán incorporados en una WebApp. Dichos objetos de contenido s e deben desarrollar o adquirir para integrarlos en la arquitectura d e la WebApp. Es factible utilizar un árbol de datos para representar la jerarquía de un objeto de contenido. Las clases de análisis (derivadas d e los casos de uso) proporcionan otros medios para representar los objetos clave que manipulará la WebApp. El modelo de interacción se construye con casos de uso, diagramas de secuencia UML y diagramas de estado UML para describir la "conversación" entre el usuario y la WebApp. Además, se construye un prototipo d e la interfaz que auxilie en el desarrollo de la plantilla y los requisitos de navegación. El modelo funcional describe las funciones observables para el usuario y las operaciones de clase que emplean el diagrama de actividad UML. El modelo de configuración describe el ambiente que requerirá la WebApp, tanto en el lado del servidor como en el del cliente del sistema. El análisis de relación-navegación identifica las relaciones entre el contenido y los elementos funcionales, definidos en el modelo de análisis, y establece requisitos paTM ra definir vínculos de navegación apropiados a través del sistema. Una serie de preguntas ayudan a establecer relaciones e identificar características que influirán so-

PDF Editor bre el diseño de navegación.

[CONOO] Conallen,)., Building Web Applications mth UML. Addison-Wesley, 2000. [F..A01] Franklin, S., "Planning Your Web Site with UML", webReview, disponible en h t t p : / / w w w . w e b r e v i e w . c o m / 2 0 0 1 /05_18/deveIopers/indexO I shtml.

564

P A R T E TRES


[SRI01] Sridhar, M. y N. M a n d y a m , "Effective Use of Data Models in Building Web Applications'' 2001, disponible en h t t p : / / w w w 2 0 0 2 . o r g / C D R O M / a l t e r n a t e / 6 9 8 / . [Y00991 Yoo, J. y M. Bieber, "A Systematic Relationship Analysis for Modeling Information Domains", 1999, s e p u e d e d e s c a r g a r d e h t t p : / / c i t e s e e r . n j . n e c . c o m / 3 1 2 0 2 5 . h t m l . [YOOOO] Yoo, J. y M. Bieber, "Toward a Relationship Navigation Analysis", e n Proc. 33rd Hawai Conf. On System Sciences, vol. 6, IEEE, e n e r o d e 2000, s e p u e d e d e s c a r g a r de www.cs.njit.edu/~bieber/pub/hicss00/INWEB02.pdf.

1 8 . 1 Con b a s e e n el g r a n a b a n i c o de r e c u r s o s acerca del desarrollo d e s o f t w a r e ágil disponible e n la Web, investigúese u n p o c o y e s t a b l é z c a s e un r a z o n a m i e n t o en c o n t r a del m o d e l a d o de análisis p a r a las WebApps. ¿Se c o n s i d e r a q u e la a r g u m e n t a c i ó n r e s u l t a n t e s e aplica e n t o d o s los casos? 18.2 Si f u e s e f o r z o s o a llevar a c a b o u n " m o d e l a d o d e análisis ligero" (es decir, m o d e l a d o de análisis minimo), ¿qué r e p r e s e n t a c i o n e s , d i a g r a m a s e información s e definirían d u r a n t e esta actividad d e ingeniería Web? 1 8 . 3 Mediante u n d i a g r a m a similar al m o s t r a d o en la figura 18.1, e s t a b l é z c a s e u n a jerarquía de usuario p a r a (a) u n sitio Web d e servicios financieros o (b) u n sitio Web d e v e n t a d e libros. 1 8 . 4 ¿ Q u é r e p r e s e n t a u n p a q u e t e d e c a s o d e uso? 1 8 . 5 Los c a s o s de u s o o los p a q u e t e s d e c a s o d e u s o s e valoran p a r a g a r a n t i z a r q u e son co.r-

prensibles, cohesivos, libremente acoplados y jerárquicamente superficiales. Describase con palab r a s p r o p i a s q u é significan e s t o s términos. Elíjase u n a WebApp q u e s e visite r e g u l a r m e n t e d e u n a de las siguientes categorías: (a) noticias o deportes, (b) e n t r e t e n i m i e n t o , (c) c o m e r c i o electrónico, (d) juegos, (e) relacionados con c o m p u t a c i ó n , (0 u n a WebApp q u e r e c o m i e n d e n los profesores. Realícense las actividades ir á c a d a s e n los p r o b l e m a s del 18.6 al 18.12: 18.6 Desarróllense u n o o m á s c a s o s d e u s o q u e d e s c r i b a n u n c o m p o r t a m i e n t o de usuario e s pecífico para la WebApp. 1 8 . 7 R e p r e s é n t e s e u n a jerarquía d e c o n t e n i d o parcial y d e f í n a n s e al m e n o s tres c l a s e s d e análisis p a r a la WebApp. 18.8 Desarróllese un d i a g r a m a d e s e c u e n c i a UML y u n d i a g r a m a d e e s t a d o UML q u e d e s c r u n a interacción específica con la WebApp. 1 8 . 9 Considérese la interfaz existente d e la WebApp. H á g a s e un prototipo d e c a m b i o a la i n t f - j faz q u e s e considere susceptible d e mejorar. 1 8 . 1 0 Elíjase u n a función o b s e r v a b l e para el usuario q u e o f r e z c a la WebApp y m o d é l e s e i diante u n d i a g r a m a d e actividad UML. 1 8 . 1 1 Elíjase un objeto d e c o n t e n i d o o función q u e s e a p a r t e d e la arquitectura d e la Web/ y r e s p ó n d a n s e las p r e g u n t a s relación-navegación m e n c i o n a d a s e n la sección TM 18.7.1. 18.12 Considérese la WebApp existente y r e s p ó n d a n s e las p r e g u n t a s relación-navegac m e n c i o n a d a s e n la Sección 18.7.2.

PDF Editor

M u c h o s libros d e d i c a d o s al m o d e l a d o de análisis para s o f t w a r e c o n v e n c i o n a l (con partic é n f a s i s e n los c a s o s d e u s o y la notación UML) c o n t i e n e n m u c h a información útil susceptible : a d a p t a r s e fácilmente a la ingeniería Web. Los c a s o s d e u s o f o r m a n los cimientos del modei;

CAPÍTULO 18

565


d e análisis p a r a l a s WebApps. Los libros d e Kulak y s u s c o l e g a s (Use Cases.- Requírements in Con text, s e g u n d a edición, Addison-Wesley. 2004). BiUner y S p e n c e (Use Case Modeling, AddisonWesley, 2002), Cockburn (Wríting Effective Use Cases, Addison-Wesley, 2001), A r m o u r y Miller

(Advanced Use-Case Modeling: Software Systems, Addison-Wesley, 2000), Rosenberg y Scott (Use Case Driven Object Modeling with UML: A Practical Approcah, Addison-Wesley, 1999) y Schneider, W i n t e r s y Jacobson (Applying use Cases. A practical Guide, Addison-Wesley, 1998) o f r e c e n u n a guia valiosa e n la creación y e m p l e o de este i m p o r t a n t e m e c a n i s m o d e r e p r e s e n t a c i ó n de requisitos. Valiosas d i s c u s i o n e s d e UML h a n escrito Arlow y Neustadt (UML and the Unifled Process, Addison-Wesley, 2002), Schmuller (Teach YourselfUML, S a m s Publishing, 2002), Booch y s u s colegas (The UML User Guide, Addison-Wesley, 1998), y R u m b a u g h y s u s colegas (The Unified Mo-

deling Language Reference Manual, Addison-Wesley, 1998). Los libros d e d i c a d o s al d i s e ñ o d e sitios Web c o n frecuencia c o n t i e n e n u n o o d o s c a p í t u l o s q u e a b o r d a n t e m a s de análisis ( a u n q u e u s u a l m e n t e s o n d i s c u s i o n e s superficiales). Los siguientes libros c o n t i e n e n u n o o m á s a s p e c t o s del análisis d e n t r o del c o n t e x t o de la ingeniería Web: Van Duyne y s u s c o l e g a s (The Design of Sites, Addison-Wesley, 2002), Rosenfeld y Morville (In-

formation Architecturefor the World Wide Web, O'Reilly & Associates, 2002), Wodtke (Information Architecture, New Riders Publishing, 2002), Garret (The Elements of User Experience: User Centered Design for the Web, New Riders Publishing, 2002), Niederst (Web Design in a Nulshell, O'Reilly & Associates, 2001), Lowe y Hall (Hypertext and the Web: An Engineeríng Approach, Wilev 1999), y Powell (Web Site Engineeríng, Prentice-Hall, 1998) o f r e c e n u n a cobertura r a z o n a b l e m e n t e

completa. Norris, West y Watson (Media Engineeríng: A Guide lo Developing Information Products, Wiley, 1997), Navarro y Khan (Effective Web Design: Master the Essentials, Sybex, 1998) y Fleming

y Koman (Web Navigation: Designing the User Experience, O'Reilly & Associates, 1998) proporcionan guía adicional p a r a análisis y diseño. En Internet hay disponible u n a gran variedad de f u e n t e s de información a c e r c a del m o d e l a d o d e análisis para ingeniería Web. Una lista actualizada d e referencias e n la World Wide Web s e e n c u e n t r a b a j o " s o f t w a r e e n g i n e e r í n g r e s o u r c e s " e n el sitio Web de SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P I T U L O

19 CONCEPTOS CLAVE arquitectura de coatenida

.586

arquitectura

MVC atributos de calidad

.569

diseño al nivel d e componentes

. .593

diseño arquitectónico. . 5 8 5 diseño de contenido.. .584 diseño de la interfaz . . 5 7 3 diseño d e navegación

.590

diseño estético . 5 8 2 MDHOO . . . .

,595

métricas....

598

patrones

. . . ..594

M O D E L A D O DE D I S E Ñ O P A R A APLICACIONES W E B

E

n su autorizado libro acerca del diseño Web, Jakob Nielsen [N1E00] afirrr "En esencia, existen d o s e n f o q u e s básicos del diseño: el ideal artístico c expresarse uno m i s m o y el ideal de ingeniería de resolver un problema p ra un cliente". Durante la primera década del desarrollo Web, la idea artística fi el e n f o q u e q u e eligieron m u c h o s desarrolladores. El d i s e ñ o ocurrió en u n a forir ad hoc y usualmente era dirigido c o n f o r m e se g e n e r a b a el HTML. El d i s e ñ o ew lucionó de u n a visión artística que en sí m i s m a evolucionó c o n f o r m e ocurrí >: construcción de la WebApp. Incluso e n la actualidad, los d e f e n s o r e s "radicales" del desarrollo de softwa ágil (capítulo 4) utilizan las aplicaciones Web c o m o cartel de niños para "dise" limitado". Argumentan que la inmediatez y la volatilidad de las WebApps 2: n ú a n el diseño formal, que el d i s e ñ o evoluciona c o n f o r m e se construye (codi ca) una aplicación y que se d e b e gastar relativamente p o c o tiempo e n la ere ción de un modelo de diseño detallado. Este a r g u m e n t o tiene mérito, p e r o SQ para WebApps relativamente simples. Cuando el contenido y la función son co« piejos, c u a n d o el t a m a ñ o de la WebApp abarca cientos de objetos de c o n t e n funciones y clases d e análisis, c u a n d o el éxito de la WebApp tendrá un i m p a : directo sobre el éxito del negocio, el diseño n o p u e d e ni d e b e ser t o m a d o a la gera. Esta realidad c o n d u c e al s e g u n d o e n f o q u e de Nielsen: "el ideal de ingen:e: de resolver un problema para un cliente". La ingeniería Web adopta esta filos fia, y un enfoque m á s riguroso del diseño WebApp permite a los d e s a r r o l l a d a lograrlo.

¿ Q u é e s ? El diseño de WebApps abarca actividades técnicas y otras que no (o son. La visión y el sentido dei contenido se desarrollan como parte del diseño gráfico; la plantilla estética de la interfaz de usuario se crea como parte del diseño de la interfaz; y la estructura técnica de la WebApp se modela como parte del diseño arquitectónico y de navegación. En toda instancia se debe crear un modelo de diseño antes de que comience la construcción, pero un buen ingeniero Web reconoce que el diseño evolucionará mientras más se conozca acerca de los requisitos de los participantes conforme se construya la WebApp.

¿ Q u i é n lo h a c e ? tos ingenieros Web, diseñade res gráficos, desarrolladores de contenido otros participantes colaboran en la creación c un modelo de diseño para la ingeniería Web ¿Por q u é e s i m p o r t a n t e ? El diseño permite un ingeniero Web crear un modelo que pueo valorarse en calidad y mejorarse antes de que < TM generen el contenido y el código, se realice pruebas y se involucren muchos usuarios finóle El diseño es el lugar donde se establece la c a dad de la WebApp. ¿ C u á l e s s o n l o s p a s o s ? El diseño WebAf abarca seis grandes pasos a los cuales alimela información obtenida durante el modelado : análisis.

PDF Editor

CAPÍTULO 19

M O D E L A D O DE DISEÑO P A R A APLICACIONES WEB

i: : seño de contenido utiliza información conte- ; a dentro del modelo de análisis como una pese para establecer el diseño de los objetos de |.: - enido y sus relaciones. El diseño estético I c-ibién llamado diseño gráfico) establece la i- won y el sentimiento que observa el usuario • n i . El diseño arquitectónico se enfoca sobre la ¡es-uctura hipermedia global de todos los obje1: de contenido y funciones. El diseño de la ----faz establece la plantilla global y los mecanismos de interacción que definen la interfaz del . oario. El diseño de navegación define cómo -cvega el usuario final a través de la estructuro - :ermedia, y el diseño de componentes repres a la estructura interna detallada de los elementos funcionales de la WebApp.

19.1

567

¿ C u á l e s el p r o d u c t o o b t e n i d o ? Un modelo de diseño que abarque temas de diseño de contenido, estética, arquitectura, interfaz, navegación y al nivel de componente es el producto de trabajo primario del diseño de ingeniería Web ¿ C ó m o p u e d o e s t a r s e g u r o d e q u e Jo h e h e c h o c o r r e c t a m e n t e ? El equipo de ingeniería Web (y algunos participantes seleccionados) revisa cada elemento del modelo de diseño con la finalidad de descubrir errores, inconsistencias u omisiones. Además, se consideran soluciones alternativas, y también se valora el grado en el que el modelo de diseño actual conducirá a una implementación efectiva.

T E M A S DE D I S E Ñ O P A R A I N G E N I E R Í A W E B C u a n d o se aplica el diseño dentro del contexto de la ingeniería Web, se deben considerar cuestiones t a n t o genéricas c o m o específicas. Desde un p u n t o de vista genérico, el diseño resulta en un modelo que guía la construcción de la WebApp. El modelo de diseño, sin importar su forma, d e b e contener suficiente información para reflejar c ó m o habrán de traducirse los requisitos de los participantes (definidos e n u n m o d e lo de análisis) e n contenido y código ejecutable. Pero el diseño también d e b e ser específico. Debe abordar atributos clave de u n a WebApp en una forma que permita al ingeniero Web construir y ponerla a prueba de m a n e r a efectiva.

19.1.1 Diseño y calidad de u n a WebApp En capítulos anteriores se señaló que el diseño es la actividad de ingeniería que conduce a un producto de gran calidad. Esto conduce a una pregunta recurrente que se presenta en toda las disciplinas de ingeniería: ¿qué es calidad? En esta sección se examinará la respuesta en el contexto de la ingeniería Web. Toda persona q u e haya n a v e g a d o en la Web o u s a d o u n a Intranet corporativa tiene u n a opinión acerca de lo que h a c e u n a "buena" WebApp. Los p u n t o s de vista inTM dividuales varían e n o r m e m e n t e . Algunos usuarios disfrutan los gráficos q u e bailan, otros quieren texto simple. Algunos solicitan información copiosa, otros d e s e a n una

PDF Editor

presentación abreviada. A algunos les gustan las herramientas analíticas sofisticadas o los accesos a las bases de datos, a otros les gustan las cosas simples. De hecho, la percepción del usuario d e lo que es "bueno" (y la resultante aceptación o r e c h a z o de la WebApp c o m o consecuencia) p u e d e ser m á s importante que cualquier discusión técnica de la calidad de la WebApp.

568

PARTE TRES


¿Pero cómo s e aprecia la calidad de la WebApp? ¿Qué atributos debe exhibir para lograr ser buena a los ojos de los usuarios finales y al mismo tiempo mostrar las características técnicas de calidad que permitirán a un ingeniero Web corregir, adaptar, mejorar y apoyar la aplicación a largo plazo? En realidad, todas las características generales de la calidad de software tratadas en los capítulos 9, 15 y 26 se aplican a la WebApps. Sin embargo, las más relevan tes de dichas características —facilidad de uso, funcionalidad, confiabilidad, eficiencia y facilidad de mantenimiento— proporcionan una base útil para valorar la calidac de los sistemas basados en Web. "Si los productos se diseñan pora encajar mejor e n las tendencias naturales del c o m p o r t a m i e n t o h u m o n o , entonces lo g e n t e estará m á s satisfecha, m á s completa y será m á s productiva." Susan Weinschenk

Olsina y s u s colegas [OLS99] han preparado un "árbol de requisitos de calidac que identifica un conjunto de atributos técnicos —facilidad de uso, funcionalidac confiabilidad, eficiencia y facilidad de mantenimiento— que conducen a WebApps c ; gran calidad. 1 La figura 19.1 resume su trabajo. Los criterios anotados en la figura son de particular interés para los ingenieros Web que deben diseñar, construí mantener las WebApps a largo plazo. Offutt [OFF02] extiende los cinco principales atributos de calidad anotados en i figura 19.1 al agregar los atributos siguientes:

Árbol d e requisitos d e c a l i d a d [OLS9" 1

Facilidad de uso

Calidad de la aplicación Web

Comprensibilidad global del sitio Características de retroalimentación en línea y ayuda - Características de la interfaz y estética - Características especiales

Funcionalidad

Capacidades de búsqueda y recuperación Características de navegación y visualización Características de la aplicación relacionadas con el d o r - : I

Confiabilidad

Correcto procesamiento de vínculos Recuperación de errores Validación y recuperación de entrada de usuario Desempeño en tiempo de respuesta Rapidez de generación de página TM Rapidez de generación de gráficos Fácil de corregir Adaptabilidad Extensibilidad

PDF Editor 1

Estos atributos de calidad sori muy similares a los que se presentan en los capítulos 9, 15 y 26 lo tanto, se deduce que las características de calidad son universales para todo el software.

CAPITULO 19

principa-

M O D E L A D O DE DISEÑO P A R A A P L I C A C I O N E S WEB

569

Seguridad. Las WebApps se han convertido en una parte integral de las bases de datos cruciales del gobierno y las empresas. Las aplicaciones de comercio electrónico extraen y luego almacenan información confidencial de los clientes. Por éstas y m u c h a s otras razones, la seguridad de las WebApps es primordial en muchas situaciones. La medida clave de la seguridad es la habilidad de la WebApp y su ambiente de servidor de rechazar el acceso no autorizado e impedir un franco ataque malévolo. Un análisis detallado de la seguridad WebApp está más allá del alcance de este libro. El lector interesado debe consultar [MCC01], [NOR02] o [KAL03]. Disponibilidad. Incluso la mejor WebApp n o satisfará las necesidades de los usuarios si no está disponible. En un sentido técnico, la disponibilidad es la medida del porcentaje del tiempo que una WebApps está disponible para usarla. El usuario final común espera que las WebApps estén disponibles las 24 horas de todos los días del año. Algo menos e s considerado inaceptable. 2 Pero "a tiempo" no es el único indicador de disponibilidad. Offutt [C)FF02j sugiere que "usar características disponibles sólo en un navegador o una plataforma" hace que la WebApp n o esté disponible para quienes tengan una configuración de navegador y plataforma diferente. El usuario invariablemente se irá a otra parte. Escalabilidad.

¿La WebApp y su ambiente de servidor pueden escalarse para ma-

nejar 100, 1 000, 10 000 o 100 000 usuarios? ¿La WebApp y los sistemas con los cuales está conectada manejan variaciones significativas en el volumen o la capacidad de respuesta caerá catastróficamente (o cesará por completo)? No es suficiente construir una WebApp exitosa. Es igualmente importante construir una WebApp que pueda acomodar el peso del éxito (significativamente más usuarios finales) y volvers e todavía m á s exitosa. Tiempo e n el m e r c a d o . Aunque en sentido técnico el tiempo en el mercado n o e s un verdadero atributo de calidad, es una medida de calidad desde un punto de vista de los negocios. La primera WebApp en el mercado usualmente captura un número desproporcionado de usuarios finales. Cientos de miles de páginas Web están disponibles para quienes busquen información en la World Wide Web. Incluso las búsquedas Web mejor dirigidas resultan en una avalancha d e contenido. Con tantas fuentes de información de las cuales elegir, ¿cómo valora el usuario la calidad (por ejemplo, veracidad, precisión, integridad, oportunidad) del contenido que se presenta dentro de una WebApp? Tillman |TIL00] TM sugiere un conjunto de criterios útil para valorar la calidad del contenido:

• ¿El ámbito y la profundidad del contenido se pueden determinar con facilidad para asegurar que satisfacen las necesidades del usuario?

PDF Editor 2

Desde luego, esta expectativa es irreal Las grandes WebApps deben planificar el "periodo de inactividad" para reparaciones y actualizaciones.

570

P A R T E TRES


INFORMACIÓN

Lista de verificación de la calidad del diseño de la WebApp , La siguiente lista de verificación, adaptada de la información presentada en Webreference. com, proporciona un conjunto de preguntas que ayudarán tanto a los ingenieros Web como a los usuarios finales a valorar la calidad global de una WebApp: • ¿El contenido, la función o las opciones de navegación pueden ajustarse a las preferencias del usuario? • ¿El contenido o la funcionalidad se pueden personalizar al ancho de banda en el cual se comunica el usuario? • ¿Las gráficas y los otros medios que no son textuales se han usado de manera apropiada? ¿El tamaño de los archivos gráficos está optimizado para que se desplieguen con eficiencia?

• ¿Las tablas están organizadas y dimensionadas en una forma que las hace comprensibles y que se desplieguen eficientemente? • ¿El HTML está optimizado para eliminar ineficiencias? • ¿El diseño global de la página facilita la lectura y la navegación? • ¿Todos los punteros (vínculos) proporcionan vínculos cor información interesante para los usuarios? • ¿Es probable que la mayoría de los vínculos persistan en la Web? • ¿La WebApp está instrumentada con utilidades d e ges tíón del sitio que incluyan herramientas para rastrear >. uso, prueba de vínculos, búsqueda local y seguridad?

/

7 ¿ Q u é se w debería c o n s i d e r a r cuand o s e v a l o r e el c o n t e n i d o d e calidad?

• ¿Los a n t e c e d e n t e s y la jerarquía de los autores del contenido se pueden identificar fácilmente? • ¿Es posible determinar la precisión del contenido, la última actualización y » que fue actualizado? • ¿El contenido y su ubicación son estables (es decir, p e r m a n e c e r á n e n la UR_ de referencia)? Además de estas preguntas relacionadas con el contenido, se pueden añadir las a guientes: • ¿El contenido e s creíble? • ¿El contenido es único? Esto es, ¿la WebApp proporciona algún beneficio u n co a quienes la usen? • ¿El contenido e s valioso para la comunidad d e usuarios a que se dirige? • ¿El contenido está bien organizado? ¿Está e n un Índice? ¿Es fácilmente ac:ü» sible? La lista de verificación a n o t a d a en esta sección sólo representa u n a pequeña m j d TM tra de los asuntos que deben abordarse conforme evolucione el diseño de u n a WebAjJ Una meta importante de la ingeniería Web es desarrollar sistemas en los que se r r j

PDF Editor

porcionen respuestas afirmativas a todas las p r e g u n t a s relacionadas con la c a l i i J

"Solo porque puedes, no significo que debes."

Jean Kásv

C A P Í T U L O 19


571

19.1.2 Metas de diseño En su columna regular acerca del diseño Web, Jean Kaiser [KAI02] sugiere las siguientes metas de diseño, que son aplicables virtualmente a toda WebApp sin importar el dominio, tamaño o complejidad de la aplicación: Simplicidad.

Aunque pueda parecer pasada de moda, la expresión "todo con mo-

deración" se aplica a las WebApps. Existe una tendencia entre algunos diseñadores a proporcionar al usuario final "demasiado": contenido exhaustivo, efectos visuales extremos, animación entrometida, enormes páginas Web, la lista es larga. Es mejor luchar por la moderación y la simplicidad. Consistencia. Esta meta de diseño se aplica virtualmente a cada elemento del modelo de diseño. El contenido se debe construir de manera consistente (por ejemplo, el formato del texto y los estilos de fuente deben ser los mismos a lo largo de todos los documentos de texto; el arte gráfico debe tener una apariencia consistente, esquema de color y estilo). El diseño gráfico (estética) debe presentar una apariencia consistente en todas las partes de la WebApp. El diseño arquitectónico debe establecer plantillas que conduzcan a una estructura hipermedia consistente. El diseño de interfaz debe definir modos consistentes de interacción, navegación y despliegue de contenido. Los mecanismos de navegación deben usarse de manera consistente a través de todos los elementos de la WebApp. Identidad. La estética, la interfaz y el diseño de navegación de una WebApp deben ser consistentes con el dominio de la aplicación para la cual se va a construir. Un sitio Web para un grupo hip-hop indudablemente tendrá una apariencia y un sentido diferente al de una WebApp diseñada para una compañía de servicios financieros. La arquitectura de WebApp será completamente diferente, las interfases se construirán para acomodar diferentes categorías de usuarios, la navegación estará organizada para lograr diferentes objetivos. Un ingeniero Web (y otros contribuyentes de diseño) deberá trabajar para establecer una identidad para la WebApp por medio del diseño. R o b u s t e z . Con base en la identidad establecida, usualmente una WebApp hace una "promesa" implícita al usuario. El usuario espera contenido y funciones robustas que sean relevantes para s u s necesidades. Si dichos elementos están perdidos o son insuficientes es probable que la WebApp fracase. Navegabilidad. Ya se ha señalado que la navegación debe ser simple y consistenTM Esto es, el te. También debe estar diseñada de modo que sea intuitiva y predecible. usuario debe entender cómo moverse por la WebApp sin tener que buscar vínculos o instrucciones de navegación.

PDF Editor

Apariencia visual. De todas las categorías de software, las aplicaciones Web son incuestionablemente las más visuales, las más dinámicas y sin duda las m á s estéticas. Es indudable que la belleza (apariencia visual) está en el ojo del observador, pero muchas características de diseño (por ejemplo, la apariencia y sentido del contení-

572

P A R T E TRES


do, la plantilla de la interfaz, la coordinación del color, el equilibrio del texto, los gna I fieos y otros medios audiovisuales, los m e c a n i s m o s de navegación) sí contribuyen i I aspecto visual. Compatibilidad.

Una WebApp se utilizará en una diversidad de ambientes (pc*|

ejemplo, diferentes equipos, tipos de conexión a Internet, sistemas operativos, nave-I gadores) y se debe diseñar para q u e s e a compatible con c a d a uno. —

——-

-

-

—

"

~

" P o r a algunos, el d i s e ñ o W e b se e n f o c a en la apariencia y sentido v i s u a l e s . . . pora otros, el diseño Web t r a t a d e la es tructuración d e información y la navegación a t r a v é s del espocio del d o c u m e n t o. Otros incluso p u e d e n considerar q u e el diseño W e b t r a t a acerco d e la tecnología e m p l e a d o p a r a construir aplicaciones W e b interactivas. En realidad, el dise ño incluye todas estos factores y ocaso m á s . " Thomas P o w e l

1 9 . 2

PIRÁMIDE

DEL D I S E Ñ O

IWEB

¿Qué es diseño en el contexto d e la ingeniería Web? Esta pregunta simple e s más J É ficil de responder de lo q u e u n o puede creer. El diseño conduce a un modelo q J contiene la mezcla a d e c u a d a de estética, contenido y tecnología. La mezcla v a r a b a dependiendo de la naturaleza de la WebApp, y, c o m o consecuencia, las a c t i v i d a d de diseño también variarán. La figura 19.2 muestra una pirámide de diseño para la ingeniería Web. Cada r v a de la pirámide representa u n a de las siguientes actividades de diseño.• Diseño de la interfaz: describe la estructura y organización de la interfaz de usuario. Incluye u n a representación de la plantilla de pantalla, u n a definid : r

CLAVE lo IWeb abarca seis diferentes tipos de diseño. Cada uno contribuye o la calidad global de la WebApp.

de los m o d o s de interacción y u n a descripción de los m e c a n i s m o s de navega-) ción. • Diseño estético: también llamado diseño gráfico, describe la "apariencia y sentimiento" de la WebApp. Incluye e s q u e m a s de color, plantilla geométrica | t a m a ñ o de texto, fuente y ubicación, uso de gráficos y decisiones estéticas ¡ n lacionadas. • Diseño de contenido: define la plantilla, la estructura y el bosquejo de todc d contenido que se presenta c o m o parte de la WebApp. Establece las relacio"
PDF Editor

• Diseño de componentes: desarrolla la lógica de procesamiento detallado c j q se requiere para implementar c o m p o n e n t e s funcionales.

En las secciones que siguen se consideran con mayor detalle cada u n a de

actividades de diseño.

CAPÍTULO 19

19.3

573


D I S E Ñ O P E LA INTERFAZ PE LA W E B A P P 3 Toda interfaz del usuario —ya sea diseñada para una WebApp, u n a aplicación de software tradicional, un producto de c o n s u m o o un dispositivo industrial— debe presentar las siguientes características: fácil de usar, fácil de aprender, fácil de navegar, intuitiva, consistente, eficiente, libre de errores y funcional. Debe ofrecer al usuario final una experiencia satisfactoria y gratificante. Los conceptos, principios y métodos de diseño de la interfaz brindan al ingeniero Web las herramientas requeridas para lograr esta lista de atributos. En el capítulo 12 se observó que el diseño de la interfaz comienza no con u n a consideración de la tecnología, sino más bien con un cuidadoso e x a m e n del usuario final. Durante el modelado de análisis para la ingeniería Web (Capítulo 18), se desarrolla u n a jerarquía de usuario. Cada categoría de usuario puede tener necesidades sutilmente diferentes, tal vez quiera interactuar con la WebApp en diferentes formas y quizá requiera funcionalidad y contenido únicos. Esta información se deriva durante el análisis de requisitos, pero se revisa c o m o el primer paso en el diseño de la interfaz.

"Si u n sitio es p e r f e c t a m e n t e utiiizoble p e r o corece d e un estilo d e diseño e l e g a n t e y a d e c u a d o , f r a c a s a r á . "

TMCurt Cloninger Dix [DIX99] a r g u m e n t a que un ingeniero Web debe diseñar u n a interfaz de m o d o

PDF Editor que responda tres preguntas primarias para el usuario final:

3

La mayoría de, si no es que todas, las directrices presentadas en el capitulo 12 se aplican igualmente al diseño de interfases WebApp. Si todavía n o lee ei capitulo 12, hágalo en este momento.

574

(CONSEJO^ Si es probable que los usuarios puedon entrar a su WebApp en varios ubicaciones y niveles en la jerarquía de contenido, asegúrese de diseñar cada página con características de navegación que conduzcan al usuario a los otros puntos de interés.

P A R T E TRES


¿Dónde estoy? La interfaz debe 1) ofrecer una indicación de que se ha tenido acceso a la WebApp 4 y 2) informar al usuario de su ubicación e n la jerarquía de contenido. ¿Qué puedo hacer ahora? La interfaz siempre debe ayudar al usuario a entender sus opciones actuales: qué funciones están disponibles, qué vínculos están vivos, qué contenido es relevante. ¿Dónde he estado, a dónde voy? La interfaz debe facilitar la navegación. En consecuencia, debe proporcionar un "mapa" (implementado en una forma fácil de entender; de dónde ha estado el usuario y qué rutas puede tomar para moverse a cualquie: parte dentro de la WebApp. La interfaz de una WebApp efectiva debe proporcionar respuestas a cada u n a de estas preguntas conforme el usuario final navega a través del contenido y la funcionalidad.

19.3.1 Principios y directrices del diseño de la interfaz Bruce Tognozzi [TOGOl] define un conjunto de características fundamentales deben presentar todas las interfaces y, al hacerlo, establece u n a filosofía que seguir todo diseñador de interfaz de WebApp:

\ CLAVE Uno buena interfaz WebApp es comprensible e indulgente, y ofrece al usuario una sensación de control.

Las interfaces efectivas son visualmente a p a r e n t e s e indulgentes, e implantan en sus usuarios u n a sensación de control. Los usuarios ven rápidamente la envergadura de sus opciones, c o m p r e n d e n c ó m o lograr s u s m e t a s y h a c e n su trabajo. Las interfaces efectivas no preocupan al usuario con los trabajos internos del sistema El trabajo se guarda de m a n e r a cuidadosa y continua, con la opción total de que el usuario d e s h a g a cualquier actividad en cualquier tiempo. Las aplicaciones y servicios efectivos realizan un m á x i m o de trabajo mientras demand a n un mínimo de información a los usuarios.

Con la finalidad de diseñar interfaces que muestren dichas características, T¡. nozzi [TOGOl] identifica u n conjunto de principios de diseño primordiales: 5 Anticipación: una WebApp se debe diseñar de modo que anticipe el siguiente miento del usuario. Por ejemplo, considere u n a WebApp de soporte al cliente rrollada para un fabricante de impresoras para computadora. Un usuario ha solic: un objeto de contenido que presenta información acerca de un controlador de p r e s o r a p a r a un s i s t e m a operativo l a n z a d o r e c i e n t e m e n t e . El TMd i s e ñ a d o r tie WebApp debe anticipar que el usuario p u e d a solicitar u n a descarga del contro

PDF Editor

Todas las personas han marcado alguna página de un sitio Web, sólo para volver a visitarla maí de y no tener que dar indicaciones del sitio Web o del contexto de la página (asi como para moverse hacia otra ubicación dentro del sitio). Los principios originales de Tognozzi se han adaptado y extendido con el fin de aprovech este libro. Véase ¡TOGOl] para mayores detalles acerca de estos principios.

CAPÍTULO 19

MODELADO d e d e e ñ o p a e a a p l i c a c i o n e s w e b

575

y debe proporcionar facilidades de navegación que permitan hacerlo sin solicitarle al usuario una búsqueda de esta capacidad. V E de una estar di-

Comunicación: la interfaz debe comunicar el estado de cualquier actividad que haya iniciado el usuario. La comunicación puede ser obvia (por ejemplo, un mensaje de texto) o sutil (por ejemplo, una hoja de papel que se mueva a través de una impresora para indicar que la impresión está en camino). La interfaz también debe comunicar el estado del usuario (por ejemplo, la identificación del usuario) y la ubicación dentro de la jerarquía de contenido de la WebApp. Consistencia: el uso de los controles de navegación, menús, iconos y estética (por ejemplo, color, forma, plantilla) deben ser consistentes a través de toda la WebApp. Por ejemplo, si el texto subrayado de azul implica un vínculo de navegación, el contenido nunca debe incorporar texto subrayado en azul que n o implique un vínculo. Toda característica de la interfaz debe responder en una forma que sea consistente con las expectativas del usuario. 6 Autonomía controlada: la interfaz debe facilitarle al usuario el movimiento a través de toda la WebApp, pero lo debe hacer en una forma que refuerce las convenciones de navegación establecidas para la aplicación. Por ejemplo, la navegación hacia porciones seguras de la WebApp se deben controlar con la identificación del usuario y su contraseña, y no debe existir mecanismo de navegación que permita al usuario dar la vuelta a dichos controles. Eficiencia: el diseño de la WebApp y su interfaz deben optimizar la eficiencia laboral del usuario, no la eficiencia del ingeniero Web que la diseña y la construye o el ambiente cliente-servidor que la ejecuta. Tognozzi [TOGOl] señala esto cuando escribe: "Esta simple verdad es por lo que es importante para todos los involucrados en un proyecto de software el apreciar la importancia de hacer propia la meta de productividad del usuario y entender la diferencia vital entre construir un sistema eficiente y fortalecer a un usuario eficiente." Flexibilidad: la interfaz debe ser lo suficientemente flexible como para permitir que algunos usuarios realicen tareas directamente y otros exploren la WebApp en una forma un tanto aleatoria. En todo caso, debe permitirle al usuario entender dónde está y ofrecerle la funcionalidad para que pueda deshacer los errores y volver a trazar las rutas de navegación mal elegidas. Enfoque: la interfaz de la WebApp (y el contenido que presenta) debe enfocarse en la(s) tarea(s) importante(s) para el usuario. En toda hipermedia existeTM una tendencia para dirigir al usuario hacia contenido mal relacionado. ¿Por qué? ¡Porque es muy fácil hacerlo! El problema es que el usuario rápidamente se puede perder en muchas capas de información de apoyo y perder el sitio del contenido original que quería en primer lugar.

PDF Editor 6

Tognozzi [TOGOl] señala que la única forma de garantizar que las expectativas del usuario se comprendan adecuadamente es mediante una amplia prueba r o r parte del usuario (capítulo 20)

576

P A R T E TRES


Ley de Fitt: "El tiempo para adquirir un objetivo es una Junción de la distancia a la que se halla y de su tamaño" [TOGOl). Con base en un estudio realizado en la década de 1950 [F1T54], la ley de Fitt "es un método efectivo de modelar rápidos movimientos dirigidos, donde un apéndice (como una mano) parte del reposo en una posición de inicio específica y se mueve hacia el reposo dentro de una área establecida como objetivo" [ZHA02], Si una tarea del usuario define una secuencia de selecciones o entradas estandarizadas (con muchas opciones diferentes dentro de la secuencia), la primer; selección (por ejemplo, selección de ratón) debe estar físicamente cerca de la siguien te selección. Por ejemplo, considere la interfaz de la página de inicio de una WebApp en un sitio de comercio electrónico que vende aparatos electrodomésticos. Cada opción del usuario implica un conjunto de elecciones o acciones de seguimiento del usuario. Por ejemplo, una opción "comprar un producto" requiere que e usuario ingrese una categoría de producto seguida por el nombre de éste. La categoría del producto (por ejemplo, equipo de audio, televisores, reproductores d e D \ T i | aparece c o m o un menú desplegable tan pronto como se selecciona "comprar un proReferencia Web

Web d e s a t e ú muchos

API en ¡ a v a . s u i u o m

o COtó, DCOM y msdn.Microsoft. caai.

ducto". En consecuencia, la siguiente elección es inmediatamente obvia (está cercaij y el tiempo para adquirir es despreciable. Si, por otra parte, la elección aparece en un menú ubicado en el otro lado de la pantalla, el tiempo para que el usuario lo s i quiera (y luego realice la elección) será demasiado. Objetos de interfaz humana: Se ha desarrollado una gran librería de objetos de intt' faz humana reutilizables para WebApps. Úselas. Es posible adquirir, de varias libreras de objetos, cualquier objeto de interfaz que pueda ser "visto, escuchado, tocado o x algún otro modo percibido" [TOGOl] por un usuario final. Reducción de latencia: Más que obligar al usuario a esperar el fin de alguna operj* ción interna (por ejemplo, descargar una imagen gráfica compleja), la WebApp debe usJ la multitarea en una forma que permita al usuario proceder con el trabajo como s. ¡ operación hubiese sido completada. Además de reducir la latencia, las demoras debea reconocerse d e modo que el usuario comprenda lo que está ocurriendo. Esto inc. j l ye 1) proporcionar retroalimentación de audio (por ejemplo, un "clic" o c a m p a n a c J cuando una selección no genera una acción inmediata de la WebApp; 2) despletaB un reloj animado o barra de progreso para indicar que el procesamiento está en m a n cha; 3) ofrecer algún entretenimiento (por ejemplo, una animación o presentación á l texto) mientras ocurra un procesamiento largo. TM

"El m e j o r viaje es el q u e tiene el m e n o r n ú m e r o d e pasos. Acorte la distancia e n t r e el usuario y su m e t a . "

PDF Editor

]

Facilidad de aprendizaje: La interfaz de una WebApp se debe diseñar para minirr .: J el tiempo de aprendizaje y, una vez aprendido, reducir el reaprendizaje requerido c u n > | do se vuelve a visitar la WebApp. En general, la interfaz debe acentuar un diseño s i J pie e intuitivo que organice el contenido y la funcionalidad en categorías obvias : J ra el usuario.

CAPÍTULO 19

577


Metáforas: una interfaz que utilice una metáfora de interacción es más fácil de aprender y de usar, en tanto la metáfora sea apropiada para la aplicación y el usuario. Una metáfora d e b e llamar imágenes y conceptos de la experiencia del usuario, p e r o no necesita ser una reproducción exacta de una experiencia del m u n d o real. Por ejemplo, un sitio de comercio electrónico que implementa el p a g o de c u e n t a s automatizado para una institución financiera usa una metáfora de lista de verificación (no de m a n e r a sorprendente) para asistir al usuario en la especificación y la calendarización de los pagos de cuentas. Sin embargo, c u a n d o un usuario "escribe" un cheque, no necesita ingresar el nombre completo del pagador sino que puede elegir de una lista de pagadores o hacer que el sistema seleccione con base en las primeras letras escritas. La metáfora p e r m a n e c e intacta, p e r o el usuario obtiene asistencia d e la WebApp. Mantener la integridad del producto de trabajo. Un producto de trabajo (por ejemplo,

•

i son una ¡poique r faenando Sólo ique ¡queseelilanoádo usuarios

una forma completada por el usuario, una lista especificada por el usuario) debe guardarse de manera automática de modo que no se perderá si ocurriese un error. Todo m u n d o ha experimentado la frustración asociada con el hecho de completar un gran formulario WebApp sólo para que el contenido se pierda debido a un error (que c o m e t e el usuario, la WebApp o la transmisión de cliente a servidor). Para evitar esto la WebApp se d e b e diseñar para autoguardar todos los d a t o s especificados por el usuario. Legibilidad: toda la información presentada a través de la interfaz debe ser legible para jóvenes y viejos. El diseñador de la interfaz d e b e enfatizar los estilos de letra legible, t a m a ñ o s de f u e n t e y opciones de fondo de color que mejoren el contraste. Estado de rastro: Cuando sea adecuado, el estado de la interacción del usuario debe rastrearse y almacenarse

de modo que un usuario pueda salir y regresar más tarde al lu-

gar de donde salió. En general, las cookies se pueden diseñar para a l m a c e n a r información de estado. Sin embargo, las cookies son una tecnología controvertida, y o t r a s soluciones de diseño pueden ser m á s a c e p ta b les para a l g u n o s usuarios. Navegación visible: una interfaz de WebApp bien diseñada proporciona

"la ilusión de

que los usuarios están en el mismo lugar, y que se les lleva el trabajo hasta sus lugares" [TOGOl]. Cuando se usa e s t e e n f o q u e la navegación no es preocupación del usuario. En lugar de eso, el usuario recupera objetos de contenido y selecciona funciones q u e se despliegan y ejecutan por medio de la interfaz.

TM La c o n v e r s a c i ó n : D o u g : Vinod, ¿el equipo y tú tuvieron oportunidad de reviso' el prototipo de la interfaz de comercio electrónico de HogorSegurolnc.com?

PDF Editor i a c t o r e s : Doug Miller (gerente del grupo de inge n en'a del software d e HogarSeguro) y Vinod Raman, -¡embro del equipo de ingeniería del software del pro wcto HogarSeguro.

V i n o d : Sí . todos lo experimentamos desde un punto

578

P A R T E TRES


de vista técnico y yo tengo un montón de notas. Ayer se los envié por correo electrónico a Sharon [gerente del equipo de ingeniería Web d e lo empresa subcontratista para el sitio Web de comercio electrónico de HogarSe-

güról-

!('•

•

D o u g : Sharon y tú se pueden reunir y discutir los pequeños detalles.. dame un resumen de los conflictos importante.

•<

'

"-V

' '¡Itóí

V i n o d : En general, hicieron un buen trabajo, nada d e labor profunda, pero es una típica interfaz de comercio electrónico, estética decente, plantilla razonable. Han considerado todas las funciones importantes...

D o u g : Todas son funciones principales, ¿no es así? V i n o d : Lo son, pero este es el punto... tú puedes comprar un sistema al ingresar una lista d e componentes., en realidad no necesitas describir la casa, si no quieres Yo sugerí sólo cuatro opciones d e menú en la página de inicio:

Aprenda acerca de HogarSeguro Especifique el sistema HogarSeguro sita Compre un sistema HogarSeguro Obtenga soporte técnico

que nece-

Doug (sonríe tristemente): ¿Pero?

Cuando selecciones especifique el sistema Hogar-

V i n o d : Bueno, existen algunas cositas...

Seguro q u e n e c e s i t a , entonces tendrás las Siguiente:opciones:

D o u g : ¿Como cuáles?

Vinod (muestra a Doug una secuencia de bosquejos para el prototipo de la interfaz): Aquí está el menú de funciones principales que se despliega en !a página de inicio:

Aprenda acerca d e HogarSeguro Describa su casa Obtenga recomendaciones de componentes d e HogarSeguro Compre un sistema HogarSeguro Obtenga soporte técnico El problema no es con estas funciones, todas están bien, pero el nivel de abstracción no es el correcto.

Seleccione componentes HogarSeguro Obtenga recomendaciones d e componentes de HogarSeguro Si eres un usuario avanzado, seleccionarás componente: d e un conjunto de menús desplegabies categorizados pe ra sensores, cámaras, paneles d e control, etcétera. Si necesitas ayuda, pedirás una recomendación y ésta requerirá que describas tu casa. Creo que es un poco más lógico. D o u g : Estoy de acuerdo. ¿Ya hablaste con Sharon acerc a de esto? V i n o d : No, primero quiero discutir esto con los de mercadotecnia; luego le hablaré por teléfono.

Nielsen y Wagner [NIE96] sugieren u n a s c u a n t a s directrices p r a g m á t i c a s e n el di s e ñ o de interfases (basados en su rediseño de u n a gran WebApp) que proporcior a un b u e n c o m p l e m e n t o a los principios sugeridos párrafos a t r á s e n esta sección: • La rapidez de lectura en un monitor de c o m p u t a d o r a e s a p r o x i m a d a m e n t e 25 por ciento m á s lenta respecto de la lectura en impresos. En consecuencia, no fuerce al usuario a leer voluminosas cantidades de texto, en particular cuandi TM se explica la operación d e la WebApp o se ofrece ayuda e n la navegación. • Evite los signos de "en construcción", crean expectativas y provocan un víncu.-: innecesario que e s seguro para la decepción.

PDF Editor

• Los usuarios prefieren no desplazarse. La información importante d e b e e s t a : dentro de las d i m e n s i o n e s de una v e n ta na típica de navegador.

• Los m e n ú s d e navegación y los e n c a b e z a d o s deben estar d i s e ñ a d o s d e m a n e ra consistente y deben estar disponibles en t o d a s las páginas que estén dispe-

CAPÍTULO 19


579

nibles para el usuario. El diseño no d e b e d e s c a n s a r e n las funciones del navegador para asistir en la navegación. • La estética nunca d e b e sustituir la funcionalidad. Por ejemplo, un simple botón p u e d e ser u n a mejor opción de navegación que u n a imagen o un icono estéticamente placenteros p e r o vagos, cuya intención n o es clara. • Las opciones de navegación deben ser obvias, incluso para el usuario casual. El usuario no d e b e tener que buscar en la pantalla para determinar c ó m o vincularse con o t r o contenido o servicio. Una interfaz bien diseñada mejora la percepción del usuario del contenido o servicios que proporciona el sitio. No n e c e s a r i a m e n t e tiene que ser ostentosa, sino que siempre d e b e estar bien estructurada y e r g o n ó m i c a m e n t e saludable. "Lo gente tiene muy poco paciencia con los sitios WWW pobremente diseñados" Jakob Nielsen y Annette Wagner p¿;-.

19.3.2 Mecanismos d e control de la interfaz Los objetivos de la interfaz de u n a WebApp son 1) establecer u n a v e n t a n a consistente con el contenido y la funcionalidad que proporciona, 2) guiar al usuario a través de una serie de interacciones con la WebApp, y 3) organizar las opciones de navegación y el contenido disponible para el usuario. Lograr una interfaz consistente requiere que el diseñador use primero el diseño estético (sección 19.4) con el fin de e s tablecer una "apariencia" c o h e r e n t e para la interfaz. Esto abarca m u c h a s características, p e r o d e b e subrayar la plantilla y la forma de los m e c a n i s m o s d e navegación. Para guiar la interacción del usuario, el diseñador de la interfaz puede emplear u n a metáfora apropiada 7 que permita al usuario adquirir una comprensión intuitiva de la interfaz. Las opciones de navegación las implementa el diseñador seleccionando de entre varios m e c a n i s m o s de interacción: • Mertús de navegación: m e n ú s clave (organizados vertical u horizontalmente)

smos

que m e n c i o n a n contenido o funcionalidad clave. Dichos m e n ú s se pueden imp l e m e n t a r de m o d o que el usuario pueda elegir de una jerarquía de s u b t e m a s

i ósuonibles ; diseñadores

que se despliegan c u a n d o se selecciona la opción de m e n ú primario.

c?

• ¡conosgráficos:

botón, interruptores e imágenes gráficas similares que permi-

ten al usuario seleccionar alguna propiedad o especificar una decisión. TM • Imágenes gráficas: alguna representación gráfica que el usuario pueda seleccionar y q u e implemente un vínculo hacia un objeto de contenido o funciona-

PDF Editor lidad de la WebApp.

7

En este contexto, una metáfora e s una representación (extraída d e la experiencia del m u n d o real del

usuario) q u e p u e d e modelarse d e n t r o del contexto d e la interfaz Un ejemplo simple p u e d e ser un interruptor deslizable con q u e se controla el volumen auditivo d e u n archivo ,mp3

580

PARTE TRES


Es importante anotar que uno o más de dichos mecanismos de control debe propcF] cionarse en cada nivel de la jerarquía de contenido.

19.3.3 Flujo de trabajo en el diseño de la interíaz Aunque un análisis detallado del diseño de la interfaz para WebApps es mejor de ; - l lo a libros de texto que s e dedican a la materia (por ejemplo, [GAL02], [RASOOS [NIE00]), vale la pena echar un vistazo a las tareas d e diseño clave. En el capítulo : J se señaló que el diseño de la interfaz del usuario comienza con la identificación » : éste, la tarea y los requisitos ambientales. Una vez que se han identificado las tarí del usuario, se crean y analizan sus escenarios (casos de uso) para definir un c o a } junto d e objetos y acciones de interfaz. Este trabajo se representa como parte modelo de análisis de la WebApp tratado en el capítulo 18. Las siguientes tareas representan un flujo de trabajo rudimentario para el di de la interfaz WebApp. 1. R e v i s a r la i n f o r m a c i ó n c o n t e n i d a e n e l m o d e l o d e a n á l i s i s y retinarla conforme se requiera. 2 . D e s a r r o l l a r u n b o s q u e j o a p r o x i m a d o d e la plantilla d e la i n t e r f a z d e WebApp. Como parte de la actividad d e modelado del análisis se pudo haber desarrollado un prototipo de la interfaz (que incluya la plantilla). Si ya exis.e la plantilla, debe revisarse y refinarse conforme se requiera. Si n o se ha desarrollado la plantilla de la interfaz, el equipo de ingeniería Web debe trabajar con los participantes para desarrollarla en este momento. En la figura 19.3 se muestra una primera versión de un bosquejo de plantilla.

Correlación d e l o s objetiv o s del usuario e n l a s a c ciones de l a interíaz.

Barra d e menú d e funciones principóle: I /

Lisia de objetivos del usuario Gráfico, logotipo y nombre de la compañía Objetivo #1 Objetivo #2

N

3 !

Objetivo # 3 Objetivo # 4 Objetivo #5

TM Gráfico

PDF Editor Objetivo #n

; Texto de la página inicial •

Menú de navegación

CAPÍTULO 19


581

3 . C o r r e l a c i o n a r l o s o b j e t i v o s del u s u a r i o c o n a c c i o n e s e s p e c í f i c a s d e la i n t e r f a z . Para la gran mayoría de las WebApps, el usuario tendrá un conjunto relativamente primario de objetivos primarios (usualmente entre cuatro y siete). Éstos deben correlacionarse con acciones específicas de la interfaz, como se muestra en la figura 19.3. 4. Definir u n c o n j u n t o d e t a r e a s de u s u a r i o q u e e s t é n a s o c i a d a s c o n cad a a c c i ó n . Cada acción de la interfaz (por ejemplo, "comprar un producto") está asociada con un conjunto de tareas de usuario. Dichas tareas se identificaron durante el modelado de análisis. Durante el diseño deben correlacionarse interacciones específicas que abarquen asuntos de navegación, objetos de contenido y funciones WebApp. 5. E l a b o r a r b o s q u e j o s c o n i m á g e n e s d e la p a n t a l l a p a r a c a d a a c c i ó n d e la i n t e r f a z . Conforme se considera cada acción, se debe crear una secuencia de imágenes en bosquejo (imágenes de pantallas) para esbozar cómo responde la interfaz a la interacción del usuario. Se deben identificar los objetos de contenido (incluso si todavía no se diseñan ni desarrollan), se debe mostrar la funcionalidad de la WebApp y se deben indicar los vínculos de navegación. 6. R e f i n a r la plantilla d e la i n t e r f a z y l o s b o s q u e j o s c o n el u s o d e e n t r a d a s d e s d e el d i s e ñ o e s t é t i c o . La plantilla aproximada y los bosquejos los completan los ingenieros Web, pero la apariencia y la percepción estética para un gran sitio comercial con frecuencia los desarrolla un artista, en lugar de profesionales técnicos. 7. I d e n t i f i c a r l o s o b j e t o s d e la i n t e r f a z d e l u s u a r i o q u e s e r e q u i e r a n p a r a i m p l e m e n t a r l a . Esta tarea puede requerir una búsqueda en una librería de objetos existente para encontrar aquellos objetos reutilizables (clases) apropiados para la interfaz de la WebApp. Además, en este m o m e n t o se especifican cualesquiera clases de personalización. 8 . 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 d e p r o c e d i m i e n t o d e la i n t e r a c c i ó n d e l u s u a r i o c o n la i n t e r f a z . Esta labor opcional usa diagramas de secuencia UML o diagramas de actividad (estudiados en el capítulo 18) para esbozar el flujo de actividades (y decisiones) que ocurren conforme el usuario interactúa con la WebApp. 9 . 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 del c o m p o r t a m i e n t o d e la i n t e r f a z . Esta tarea opcional utiliza diagramas de estado UML (estudiados en el capítulo TM 18) para representar las transiciones de estado y los eventos que las causan. Se definen los mecanismos de control (es decir, los objetos y acciones disponibles con que el usuario altera el estado de una WebApp).

PDF Editor

10. D e s c r i b i r la plantilla d e la i n t e r f a z p a r a c a d a e s t a d o . Con el uso de la información de diseño desarrollada en las tareas 2 y 5, se asocia una plantilla específica o imagen de pantalla con cada estado de la WebApp descrito en la tarea 9.

582

PARTE TRES


1 1 . R e f i n a r y r e v i s a r e l m o d e l o d e d i s e ñ o d e l a i n t e r f a z . La revisión de la interfaz se d e b e e n f o c a r en la facilidad de uso (capítulo 12). Es importante notar que el conjunto de tareas finales que haya elegido un equipo de ingeniería Web se d e b e adaptar a los requisitos especiales de la aplicación que se va a construir.

19.4

DISEÑO El diseño estético, también llamado diseño gráfico, e s un e s f u e r z o artístico q u e com-

ÔNSEJO^-

No todo ingeniero Web (o ingeniero efe software) tiene talento artístico (estético). Si se está en esto cotegorio, contrátese anáseñadorgiúko

p l e m e n t a los a s p e c t o s técnicos de la ingeniería Web. Sin él, una WebApp p u e d e ser funcional, p e r o sin atractivo. Con él, una WebApp lleva a sus usuarios a un munde que los incluye e n un á m b i t o t a n t o emocional c o m o intelectual. Pero, ¿qué e s estética? Existe un viejo dicho: "la belleza existe en los ojos de quier la ve". Esto es particularmente apropiado c u a n d o se considera el diseño estético para las WebApps. Para realizar u n diseño estético efectivo, de n u e v o se regresa a la jerarquía de usuarios desarrollada c o m o parte del modelo d e análisis (capítulo 18> : s e pregunta q u i é n e s s o n los usuarios de la WebApp y q u é "apariencia" d e s e a n .

estético. "Encontramos que la gente rápidamente evalúa un sitio sólo por su diseño visual." Directrices Stanford para la credibilidad en ta Web

19.4.1 Cuestiones de la plantilla Toda página Web tiene una cantidad limitada de "bien inmueble" que p u e d e usars-r para d a r soporte a la estética no funcional, características d e navegación, contentó: de información y funcionalidad dirigida al usuario. El "desarrollo" de e s t e bien inmueble se planea d u r a n t e el diseño estético. Al igual que las cuestiones estéticas, no existen reglas a b s o l u t a s c u a n d o se dise- j ña u n a plantilla de pantalla. Sin e m b a r g o , vale la p e n a considerar algunos linea-i mientos generales de plantilla: No temerle al espacio vacío. No es aconsejable rellenar c a d a centímetro c u a d r a d : I de u n a página Web con información. El a m o n t o n a m i e n t o resultante dificulta que e:l usuario identifique la información o características necesarias y crea un c a o s visua TM desagradable. Resaltar el contenido.

Después de todo, ésta es la razón por la cual el usuario es

PDF Editor

tá aquí. Nielsen [NIEOO] sugiere que la típica página Web debe ser 80 por ciento cortenido con el resto del bien inmueble dedicado a navegación y o t r a s características. Organizarlos

elementos de plantilla de arriba a la izquierda hacia abajo a la derechc

La gran mayoría de los usuarios explorarán una página Web en gran parte de la mis-l m a forma e n que exploran las páginas d e un libro: d e arriba a la izquierda hacia aba-j

CAPITULO 19

583


jo a la derecha. 8 Si los elementos de plantilla tienen prioridades específicas, los elementos de mayor prioridad deben colocarse en la porción superior izquierda de la página bien inmueble. Agrupar navegación, contenido y Junción geográficamente

dentro de la página. Los

h u m a n o s buscan patrones virtualmente en todas las cosas. Si n o existen patrones discernibles dentro de una página Web, es probable que a u m e n t e la frustración del usuario (debido a la búsqueda innecesaria de la información requerida). No extender el bien inmueble con la barra de desplazamiento.

Aunque con frecuen-

cia el desplazamiento e s necesario, la mayoría de los estudios indican que los usuarios preferirían no desplazarse. Es mejor reducir el contenido de la página o presentar el contenido necesario en varias páginas. Considerar la resolución y el tamaño de la ventana de navegador cuando diseñe plantillas. En vez de definir tamaños fijos dentro de una plantilla, el diseño debe especificar todos los artículos de la plantilla como un porcentaje del espacio disponible [N1E00].

19.4.2 Cuestiones de diseño gráfico El diseño gráfico considera cada aspecto de la presentación y percepción de una WebApp. El proceso de diseño gráfico comienza con la plantilla (sección 19.4.1) y procede hacia la consideración de esquemas de color globales, tipos de fuentes, tam a ñ o s y estilos, el uso de medios audiovisuales complementarios (por ejemplo, audio, video, animación) y todos los d e m á s elementos estéticos de una aplicación. El lector interesado p u e d e obtener sugerencias y directrices de diseño en muchos sitios Web que se dedican al tema (por ejemplo, www.graphic-design.com, www.grantasticdesigns.com, www.wpdfd.com) o de una o m á s fuentes impresas (por ejemplo, [BAG01], [CLOO1 ] o [HEI02]). INFORMACIÓN

Sitios Web bien diseñados En ocasiones, la mejor forma d e comprender el buen diseño d e las WebApps es observar unos ejemplos. En su artículo "The Top Twenly W e b DeTips" (Las mejores 2 0 sugerencias p a r a el diseño , Marcelle Toor (http://www.graphic-design.com/ ure/tips.html) sugiere los siguientes sitios W e b ejemplos d e buen diseño gráfico: primo.com: firma de diseño e n c a b e z a d a por Primo Angelí. workbook.com: este sitio sirve como a p a r a d o r p a r a

www.pbs.org/riverofsong: serie d e televisión p a r a la radio y la televisión públicas acerca d e la música estadounidense www.RKDINC.com: firma d e diseño con un portafolios en línea y buenas sugerencias d e diseño. www.commarts.com/career/index.html: revista Communication Arts, una publicación periódica p a r a diseñado-

TM

res gráficos. Una buena fuente p a r a otros sitios bien diseñodos. www.btdnyc.com: firma d e diseño e n c a b e z a d a por Beth

PDF Editor el trabajo d e ilustradores y diseñadores.

8

Toudreau.

Existen excepciones b a s a d a s en la cultura y el idioma, p e r o esta regla se aplica a la mayoría de los

usuarios.

P A R T E TRES

584

19.5


D I S E Ñ O PEE CONTENIDO El diseño del contenido se e n f o c a en dos a s u n t o s de diseño diferentes, cada uno : abordan individuos con distintos c o n j u n t o s de habilidades. El diseño del c o n t e n i ó J desarrolla una representación de diseño para los objetos de contenido y represer al los m e c a n i s m o s que se requieren para que establezcan s u s relaciones u n o con otr: J Esta actividad de diseño la dirigen los ingenieros Web. Además, el diseño de contenido se ocupa de la representación de la informacic-J dentro de un objeto de contenido específico: actividad de diseño que dirigen los r - J blicistas, los d i s e ñ a d o r e s gráficos y otros que g e n e r a n el contenido de u n a WebAppl "Los buenos diseñadores pueden crear normalidad a partir del caos; pueden comunicar las ideas con claridad por medio de la organización y el manejo de las palabras y los dibujos." m -<• " Jeffery Veer

19.5.1 Objetos de contenido La relación entre objetos de contenido, definida c o m o parte del modelo de a n á i i s J WebApp (por ejemplo, figura 18.3), y los objetos de diseño que representan c o n t e n n do es análoga a la relación entre las clases de análisis y los c o m p o n e n t e s de d i s e ñ * descritos en el capítulo 11. En el contexto de la ingeniería Web un objeto de coniam do está alineado de m a n e r a m á s c e r c a n a con un objeto de dato para s o f t w a r e c c e l

ComponentedeProducto

Representación del diseño d e los o b j e t o s d e contenido.

parleNúmero parteNombre parte Tipo descripción precio

Es parte d e

crea rN uevo Artíc u lo j) desplegarDescripc¡ón() d e s p l e g a r EspecTécnica Descr i pe i ó n d e C o m p o n ente

Sensor

Cómora

Panel d e Control

CaractSoftware

I

1 0.1

n Desc r i pe iónDeMarketi ng

TM

1..*|

0..1

Fotografía

Esquema

0..11 Video

PDF Editor •color lexto e s t i b fuente t a m a ñ o fuente e s p a c i a d o línea tamaño texto uso color fondo

dimensión horizontal dimensión vertical estilo b o r d e

dimensión horizontal dimensión vertical estilo bordo

dimensión horizontal dimensión vertical estilo b o r d e volumen audio

l| DescripciónTécrc; color texto estilo fuente t a m a ñ o fuente espacíamiento lire= t a m a ñ o texto imoger color f o n d o

CAPÍTULO 19


585

vencional. Un objeto de contenido tiene atributos que incluyen información especifica de contenido (normalmente definida durante el modelado de análisis WebApp) y atributos específicos de implementación que se especifican c o m o parte del diseño. Como ejemplo, considérese la clase de análisis que se desarrolló para el sistema de comercio electrónico HogarSeguro llamado C o m p o n e n t e d e P r o d u c t o que se desarrolló en el capítulo 18 y se representa c o m o aparece en la figura 19.4. En el capítulo 18 se mencionó un atributo d e s c r i p c i ó n que aquí se representa como una clase de diseño llamada D e s c r i p c i ó n d e C o m p o n e n t e , compuesta de cinco objetos de contenido: D e s c r i p c i ó n D e M a r k e t i n g , F o t o g r a f í a , D e s c r i p c i ó n T é c n i c a , E s q u e m a y Video, que se muestran como objetos sombreados en la figura. La información que contiene el objeto de contenido se registra como atributos. Por ejemplo, Fotog r a f í a (una imagen .jpg) tiene los atributos d i m e n s i ó n h o r i z o n t a l , d i m e n s i ó n vertical y estilo d e b o r d e Mediante una asociación UML y un agregado 9 se pueden representar relaciones entre los objetos de contenido. Por ejemplo, la asociación UML que se muestra en la figura 19.4 indica que se emplea una D e s c r i p c i ó n d e C o m p o n e n t e para cada instancia d e la clase C o m p o n e n t e d e P r o d u c t o . D e s c r i p c i ó n d e C o m p o n e n t e está integrado por los cinco objetos de contenido mostrados. Sin embargo, la multiplicidad de notación que se muestra indica que E s q u e m a y v i d e o son opcionales (es posible que se presenten cero ocurrencias), se requieren una D e s c r i p c i ó n D e M a r k e ting y D e s c r i p c i ó n T é c n i c a , y s e aplican una o más instancias de F o t o g r a f í a .

19.5.2 Cuestiones del diseño de contenido Una vez modelados todos los objetos de contenido, la información que cada objeto entregará debe crearse y luego formatearse para satisfacer mejor las necesidades del cliente. La creación del contenido es el trabajo de los especialistas que diseñan el ob-

! tienden o r el óesplazoi *rtkal más ¡que el tiento hori. ívitelos s de página

jeto de contenido al proporcionar un esbozo de la información que se entregará y una indicación de los tipos de los objetos de contenido genéricos (por ejemplo, texto descriptivo, imágenes gráficas, fotografías) mediante los cuales se entregará la información. También se puede aplicar el diseño estético (sección 19.4) para representar la apariencia y percepción adecuados para el contenido. Conforme se diseñan, los objetos de contenido se "despedazan" [POWOO] para formar páginas de la WebApp. El número de objetos de contenido que se incorporan en una sola página es en función de las necesidades del usuario, de las restricciones impuestas por la rapidez de descarga de las conexiones de Internet y debido a las TM tolerará. restricciones que impone la cantidad de desplazamiento que el usuario

PDF Editor

El diseño arquitectónico está enlazado con las metas establecidas para la WebApp, el contenido que se presentará, los usuarios que la visitarán y la filosofía de navega9

A m b a s representaciones se discuten e n el c a p i t u : : 8

586

P A R T E TRES


ción que se establezca. El diseñador arquitectónico d e b e identificar la arquitectura de contenido y la arquitectura de la WebApp. La arquitectura de contenido10

se cen-

tra en la forma en la que los objetos de contenido (u objetos c o m p u e s t o s c o m o las páginas Web) se estructuran para su presentación y navegación. La arquitectura de WebApp aborda la forma e n la que la aplicación se estructura para gestionar la interacción del usuario, m a n e j a r las t a r e a s de p r o c e s a m i e n t o internas, efectuar la navegación y presentar el contenido.

l

"[l]o estructura arquitectónico de un sitio bien diseñado no siempre es aparente para el usuario... ni lo debe ser." Thomas Powell

3

En la mayoría de los casos, el diseño arquitectónico se dirige en paralelo con e diseño de la interfaz, el estético y el de contenido. Puesto que la arquitectura WebApp p u e d e tener una fuerte influencia sobre la navegación, las decisiones tomadas durante esta actividad de diseño influirán en el trabajo dirigido durante el diseño ce navegación.

19.6.1 Arquitectura de contenido El diseño de la arquitectura de contenido se centra en la definición de la estructura h> j permedia global de la WebApp. El diseño se p u e d e elegir de cuatro diferentes estructuras de contenido [POWOO]: Las estructuras lineales (figura 19.5) se e n c u e n t r a n c u a n d o es c o m ú n u n a s e c u e r cia predecible de interacciones (con alguna variación o desviación). Un ejemplo cía-1 sico p u e d e ser u n a presentación tutorial en la que las páginas de información j u n t : con gráficos relacionados, videos cortos o audio se presentan sólo d e s p u é s de que se ha p r e s e n t a do información de prerrequisitos. La secuencia de la presentación ce contenido está predefinida y, por lo general, es lineal. Otro ejemplo p u e d e ser u n a j secuencia de e n t r a d a s para comprar u n producto, en la cual se d e b e detallar infor- J mación específica en un orden específico. En tales casos, son a p r o p i a d a s las estruc- ¡ turas m o s t r a d a s en la figura 19.5. Conforme el contenido y el p r o c e s a m i e n t o se vue.-j ven m á s complejos, el flujo m e r a m e n t e lineal m o s t r a d o a la izquierda de la figura caí ¡ p a s o a estructuras lineales m á s complejas en las que se p u e d e llamar contenido a -: ternativo u ocurre u n a desviación para adquirir contenido complementario (estructura m o s t r a d a a la derecha de la figura 19.5). Las estructuras en retícula (figura 19.6) son una opción arquitectónica aplicafc r: TM c u a n d o el contenido de la WebApp está organizado categóricamente en dos (o má= i] dimensiones. Por ejemplo, considérese u n a situación en la cual u n sitio de c o m e r á : !

PDF Editor

electrónico vende palos d e golf. La dimensión horizontal de la retícula representa r j tipo de palo que se v e n d e (por ejemplo, m a d e r a , hierro, wedges, putters). La dimer

10 El término arquitectura de información

también se utiliza para sugerir estructuras que conducen ;

una mejor organización, etiquetado, navegación y b ú s q u e d a d e objetos de contenido.

CAPÍTULO 19

M O D E L A D O DE DISEÑO PARA APLICACIONES WEB

587

sión vertical representa las ofertas de varios fabricantes de palos de golf. En consecuencia, un usuario puede navegar la retícula horizontalmente para encontrar la columna putters y luego verticalmente para examinar las ofertas de aquellos fabricantes que venden putters. Esta arquitectura de WebApp sólo e s útil cuando se encuentra contenido altamente regular [POWOO], TM Las estructuras jerárquicas (figura 19.7) son indudablemente las arquitecturas WebApp más comunes. A diferencia de las jerarquías de software factorizadas —que se estu-

PDF Editor

diaron en el capítulo 10—, que alinean el flujo de control sólo a lo largo de las ramas verticales de la jerarquía, una estructura jerárquica WebApp se puede diseñar en una forma que permita (vía ramificaciones de hipertexto) el flujo de control horizontalmente, a través de las ramas verticales de la estructura. Por lo tanto, el contenido presentado en la rama de la extrema izquierda de la jerarquía puede tener vínculos

P A R T E TRES

Estructura jerárquica.


1

de hipertexto que conduzcan a contenido que existe en la rama de en medio o a derecha de la estructura. Sin embargo, s e debe señalar que, a u n q u e tales ramificaciones permiten la navegación rápida a través del contenido de la WebApp, pue conducir a confusión en la parte del usuario. Una estructura en red o "Web pura" (figura 19.8) es similar en muchos sentidos la arquitectura que evoluciona para los sistemas orientados a objetos. Los compc nentes arquitectónicos (en este caso, páginas Web) están diseñados de modo pueden pasar el control (vía vínculos de hipertexto) virtualmente a cualquier componente en el sistema. Este enfoque permite una considerable flexibilidad en navegación, pero al mismo tiempo puede ser confusa para el usuario. Las estructuras arquitectónicas comentadas en los párrafos precedentes se puede combinar para formar estructuras compuestas. La arquitectura global de una W App puede ser jerárquica, pero parte de la estructura puede mostrar característi lineales, mientras que otra parte puede estar en red. La meta para el diseñador quitectónico es emparejar la estructura WebApp con el contenido que se present y el procesamiento que se llevará a cabo.

19.6.2 Arquitectura de WebApp La arquitectura de WebApp describe una infraestructura que permite TM a un sistema aplicación basados en Web lograr sus objetivos de negocios. Jacyntho y s u s colé [JAC02] describen las características básicas de esta infraestructura en la forma

PDF Editor guíente:

Las a p l i c a c i o n e s d e b e n c o n s t r u i r s e c o n el u s o d e c a p a s e n l a s q u e s e t o m e n e n c u e n t a l a s d i f e r e n t e s p r e o c u p a c i o n e s ; e n particular, l o s d a t o s d e la a p l i c a c i ó n s e d e b e n s e p a r a r d e los c o n t e n i d o s d e la p á g i n a ( n o d o s d e n a v e g a c i ó n ) , y d i c h o s c o n t e n i d o s , a s u v e z , d e b e n est a r c l a r a m e n t e s e p a r a d o s d e la a p a r i e n c i a y la p e r c e p c i ó n d e la i n t e r f a z (páginas).

CAPÍTULO 19


589

Los autores sugieren una arquitectura de diseño en tres capas que desacople la interfaz de la navegación y del comportamiento de la aplicación, y argumentan que mantener la separación de la interfaz, aplicación y navegación simplifica la implementación y mejora la reutilización.

V E MC terfaz

La arquitectura de modelo vista controlador (MVC) [KRA88]11 es uno de varios modelos d e infraestructura WebApp sugeridos para desacoplar la interfaz del usuario de la funcionalidad y el contenido de información de la WebApp. El modelo (a veces 11amado "objeto modelo") contiene todo el contenido específico de la aplicación y la lógica de procesamiento, e incluye todos los objetos de contenido, el acceso a fuentes

WebApp

de datos/información externas y toda la funcionalidad de procesamiento que son específicos de la aplicación. La vista contiene todas las funciones específicas de la interfaz y habilita la presentación del contenido y la lógica de procesamiento, e incluye todos los objetos de contenido, acceso a fuentes de datos/información externas y a toda la funcionalidad de procesamiento requerida por el usuario final. El controlador gestiona el acceso al modelo y a la vista y coordina el flujo de datos entre ellos. En una WebApp, "la vista la actualiza el controlador con datos provenientes del modelo con base en la entrada del usuario" [WMT02], En la figura 19.9 se muestra una representación esquemática de la arquitectura MVC. En referencia a la figura, las solicitudes o datos del usuario se manejan mediante el controlador. Éste también selecciona el objeto vista que es aplicable con base en la solicitud del usuario. Una vez que se determina el tipo de solicitud, se transmite TM una solicitud de comportamiento al modelo, que implementa la funcionalidad o recupera el contenido requerido para acomodar la solicitud. El objeto modelo puede tener acceso a datos almacenados en una base de datos corporativa, como parte de

PDF Editor

11 Se d e b e destacar q u e MVC e s en realidad u n patrón d e d i s e ñ o arquitectónico desarrollado p o r el am biente Smalltalk (véase http://www.cetus-links.org oc_sm.alltalk html) y se p u e d e usar para cual quier aplicación interactiva.

590

PARTE TRES

¡KM


La a r q u i t e c t u r a M V C ( a d a p t a d a d e [ J A C 0 2 ] ) .

un a l m a c é n de d a t o s local o c o m o una colección de archivos independientes d a t o s que desarrolla el modelo d e b e formatearlos y o r g a n i z a d o s el objeto vista a á m c u a d o y luego transmitirlo del servidor de la aplicación de vuelta al n a v e g a d o r b a s a do en el cliente para que se despliegue en la máquina de éste. En m u c h o s casos, la arquitectura de WebApp se define dentro del contexto ambiente de desarrollo e n el que la aplicación habrá de implementarse (por ejemr-iJ ASP.net, JWAA o J2EE). El lector interesado debe ver [FOW03] para u n a e x p o s i a ú i ulterior acerca d e los a m b i e n t e s de desarrollo m o d e r n o s y de su papel en el disc-i^ de las arquitecturas de aplicaciones Web. 19.7

D I S E Ñ O DE N A V E G A C I Ó N Una vez establecida la arquitectura de WebApp y la identificación de los comporeÉ t e s (páginas, guiones, applets y o t r a s funciones d e procesamiento), el diseñador de TM be definir las rutas de navegación que habiliten para los usuarios el a c c e s o al c nido y las funciones de la WebApp. Para lograr e s t o el diseñador debe 1) idenf la semántica de navegación para diferentes usuarios del sitio y 2) definir la m

PDF Editor ca (sintaxis) que logra la navegación.

"Sólo espera, Gretel, hasta que la luna se eleve, entontes veremos los trozos de pan que he desparramado, ellos nos mostrarán de nuevo el camino a tasa." Tomado de Hansel y

CAPÍTULO 19

591


19.7.1 Semántica de navegación Al igual que muchas actividades de ingeniería Web, el diseño de navegación comienza con una consideración de la jerarquía de usuario y los casos de uso relacionados (capítulo 18) desarrollados para cada categoría de usuario (actor). Cada actor puede usar la WebApp de manera un poco diferente y, por tanto, tener diferentes requisitos de navegación. Además, los casos de uso desarrollados para cada actor definirán un conjunto de clases que abarcan uno o más objetos de contenido o funciones de la WebApp. Conforme cada usuario interactúa con la WebApp, encuentra una serie de unidades semánticas de navegación (USN), "un conjunto de estructuras de información y navegación relacionadas que colaboran en el cumplimiento de un subconjunto de requisitos de usuario relacionados" [CAC02]. Gnaho y Larcher [GNA99] describen la USN en la forma siguiente: La e s t r u c t u r a d e u n a USN e s t á c o m p u e s t a d e u n c o n j u n t o d e s u b e s t r u c t u r a s d e n a v e g a c i ó n q u e se l l a m a r á n formas

de navegación

(FdN). Una FdN r e p r e s e n t a la m e j o r f o r m a o

r u t a d e n a v e g a c i ó n p a r a los u s u a r i o s c o n c i e r t o s perfiles p a r a l o g r a r s u m e t a o s u b m e t a d e s e a d a . En c o n s e c u e n c i a , el c o n c e p t o d e FdN e s t á a s o c i a d o c o n el c o n c e p t o d e Perfil d e Usuario. La e s t r u c t u r a d e u n a FdN e s t á i n t e g r a d a c o n u n c o n j u n t o d e nodos de navegación r e l e v a n t e s c o n e c t a d o s p o r vínculos

de navegación,

(NN)

q u e en o c a s i o n e s incluyen o t r a s FdN.

Esto significa q u e l a s FdN p u e d e n , en sí m i s m a s , s e r a g r e g a d a s p a r a f o r m a r u n a FdN d e nivel s u p e r i o r , o p u e d e n a n i d a r s e e n c u a l q u i e r p r o f u n d i d a d . P a r a ilustrar el d e s a r r o l l o d e u n a FdN, c o n s i d é r e s e el c a s o d e u s o seleccionar nentes

HogarSeguro

compo-

d e s c r i t o en la s e c c i ó n 18.1.2 y q u e s e r e p r o d u c e a c o n t i n u a c i ó n :

C a s o d e u s o : seleccionar

componentes

HogarSeguro

E n t o n c e s la W e b A p p r e c o m e n d a r á c o m p o n e n t e s d e p r o d u c t o (por e j e m p l o , p a n e l e s d e c o n t r o l , s e n s o r e s , c á m a r a s ) y o t r a s c a r a c t e r í s t i c a s (por e j e m p l o , f u n c i o n a l i d a d b a s a d a e n PC i m p l e m e n t a d a en s o f t w a r e ) p a r a c a d a h a b i t a c i ó n y la e n t r a d a e x t e r i o r . Si el u s u a r i o solicita o p c i o n e s , la W e b A p p l a s p r o p o r c i o n a r á si e x i s t e n . El u s u a r i o o b t e n d r á i n f o r m a ción d e s c r i p t i v a y d e p r e c i o s p a r a c a d a c o m p o n e n t e d e p r o d u c t o . La W e b A p p c r e a r á y m o s t r a r á u n a f a c t u r a d e m a t e r i a l e s c o n f o r m e s e s e l e c c i o n e n v a r i o s c o m p o n e n t e s . El u s u a r i o t a m b i é n p o d r á n o m b r a r la f a c t u r a d e m a t e r i a l e s y g u a r d a r l a p a r a r e f e r e n c i a f u t u r a ( v é a s e c a s o d e u s o : guardar

configuración).

IVE

Los artículos subrayados en la descripción del caso de uso representan clases y obdescribe los jetos de contenido que serán incorporados en una o m á s FdN que permitirán a un de TM componennuevo cliente realizar el escenario descrito en el caso de uso seleccionar : paro cada tes HogarSeguro. 350. En .laUSN La figura 19.10 bosqueja un análisis semántico parcial de la navegación que imcómo un actor plica el caso de uso seleccionar componentes HogarSeguro. Con la aplicación de la - entre los terminología introducida anteriormente, la figura también representa una FdN para 3e contenido o la WebApp HogarSegurolnc.com. Se muestran importantes problemas en las clases déla de dominio junto con objetos de contenido seleccionados (en este caso, el paquete

PDF Editor

592

PARTE TRES


Creación de una USN. « v í n c u l o de n a v e g a c i ó n » solicitar alternativa «vínculo de navegación» seleccionar Habitación Habitación

« v i n c u l o de n a v e g a c i ó n » «vínculo de navegación» *—I— mostrar ComponentedeProducto recomendar componenle(s) ComponentedeProducto

« v i n c u l o de n a v e g a c i ó n » \ regresar a Habitación « v i n c u l o de n a v e g a c i ó n » comprar ComponentedeProducto FacturaDeMateriales « v í n c u l o de n a v e g a c i ó n » ver FacturaDeMateriales

inculo de n a v e g a c i ó n » mostrar descripción DescripciónDeComponente

« v í n c u l o de n a v e g a c i ó n » comprar ComponentedeProducto

Descripción DeMarketing DescripciónTécnica

fotografía

esquema

d e objetos de contenido llamado D e s c r i p c i ó n C o m p , un atributo de la clase Comp o n e n t e d e P r o d u c t o ) . Dichos artículos son nodos de navegación. Cada una de las flechas representa un vínculo de navegación 1 2 y está etiquetado con la acción quel inicia el uso que causa que el vínculo ocurra. El diseñador de la WebApp crea una unidad semántica de navegación (USN) paral cada caso de uso asociado con cada papel de usuario [GNA99]. Por ejemplo, u d c l i e n t e n u e v o (figura 18.1) puede tener tres diferentes casos de uso, y todos res j l tan en acceso a diferente información y funciones de la WebApp. Para cada meta sel crea una USN. Durante las etapas iniciales del diseño de navegación se valora la arquitectura d a contenido de la WebApp para determinar una o m á s FdN para cada caso de uso. C mo se anotó anteriormente, una FdN identifica los nodos de navegación (por ejeT-J pío, contenido) y los vínculos que permiten la navegación entre ellos. Entonces . a l FdN s e organizan en USN. "El problema detanavegación en el sitio Web es conceptual, técnico, espacial, filosófico y logístico. Consecuentemente los soluciones tienden a pedir combinaciones de arte, ciencia y psicología organizacional improvisadas y complejos.' TimHorgai

19.7.2 Sintaxis de navegación

TM Conforme el diseño s e lleva a cabo se define la mecánica de navegación. Entre ir J chas posibles opciones están:

PDF Editor

• Vínculo de navegación individual: vínculos basados en texto, iconos, botones t j interruptores, y metáforas gráficas.

12 Eri ocasiones, a é s t o s se les conoce c o m o vínculos semánticos

de navegación (VSN) [CAC02]

CAPÍTULO 19

M O D E L A D O DE DISEÑO PARA A P U C A C I O N E S WEB

• Barra de navegación

horizontal:

593

lista de las principales categorías de conte-

nido o funcionales en u n a barra que contiene vínculos adecuados. En general, i délas

l ¡frise 5* r "mortal ¡no

se m e n c i o n a n entre cuatro y siete categorías. • Columna de navegación vertical: 1) lista de las principales categorías de contenido o funcionales, o 2) lista de virtualmente todos los principales objetos de contenido dentro de la WebApp. Si se elige la segunda opción, tales c o l u m n a s de navegación se pueden "expandir" para presentar objetos de contenido como parte de una jerarquía. • Pestañas: u n a metáfora que n o es m á s que u n a variación de la barra o columna de navegación, que representa las categorías de contenido o funcionales c o m o m a r c a s que se seleccionan c u a n d o se requiere un vínculo. • Mapas de sitio: proporcionan u n a tabla de contenido incluyente para la n a v e gación hacia todos los objetos de contenido y funcionalidad contenidos en la WebApp.

*

A d e m á s de elegir los m e c a n i s m o s de navegación, el diseñador también debe establecer c o n v e n c i o n e s y auxiliares d e navegación a d e c u a d o s . Por ejemplo, iconos y vínculos gráficos que deben parecer "oprimibles" mediante el biselado de los bordes p a r a que la imagen tenga u n a apariencia tridimensional. Debe diseñar retroalimentación visual o de audio para ofrecer al usuario u n indicador de que h a elegido u n a opción de navegación. En la navegación b a s a d a en texto d e b e usarse color para indicar los vínculos de navegación y proporcionar un indicador de los vínculos ya recorridos. Éstas son sólo algunas de las d o c e n a s de convenciones de diseño que hacen la navegación amigable al usuario.

Las m o d e r n a s aplicaciones Web entregan funciones de p r o c e s a m i e n t o cada vez m á s elaboradas que 1) realizan p r o c e s a m i e n t o localizado para generar capacidad de contenido y navegación en u n a forma dinámica; 2) ofrecen capacidades de c o m p u tación o procesamiento de datos que son a d e c u a d a s para el dominio de negocios de la WebApp; 3) proporcionan cuestionamientos y a c c e s o sofisticados a b a s e s de d a tos, 4) establecen interfases de d a t o s con sistemas corporativos externos. Para lograr e s t a s (y m u c h a s otras) capacidades, el ingeniero Web d e b e diseñar y construir comp o n e n t e s de p r o g r a m a que sean idénticos e n forma a los c o m p o n e nTM t e s de software para el s o f t w a r e convencional. En el capítulo 11 se considera c o n cierto detalle el diseño al nivel de c o m p o n e n -

PDF Editor

tes. Los métodos de diseño estudiados e n el capítulo 11 se aplican a los c o m p o n e n t e s WebApp con poca, si acaso, modificación. El ambiente de implementación, los leng u a j e s de programación y los p a t r o n e s de reutilización, m a r c o s de trabajo y s o f t w a re p u e d e n variar un poco, p e r o el enfoque de diseño global p e r m a n e c e igual.

P A U T E TRES

594

19.9


P A T R O N E S DE D I S E Ñ O H I P E R M E D I A Los p a t r o n e s de diseño aplicados en ia ingeniería Web a b a r c a n dos g r a n d e s clasesJ 1) patrones de diseño genérico que son aplicables a todos los tipos de software lp:rl ejemplo, [BUS96] y |GAM95]) y 2) patrones de diseño hipermedia

que s o n específiccsl

de las WebApp. En el capítulo 9 se trataron los p a t r o n e s de diseño genérico. A tra-l vés de Internet se p u e d e tener a c c e s o a varios catálogos y a l m a c e n e s de patrones o d hipermedia. 1 3 "Cada potrón es una regla de tres partes que expresa una relación entre cierto contexto, un problema y una solución Christopher Alexander

L_—

i

:• '' " riir;

"

_3|

C o m o se a p u n t ó a n t e s en este libro, los patrones de diseño son u n enfoque g e n é r co para resolver algún p e q u e ñ o problema de diseño que se p u e d e adaptar a una variedad m u c h o m á s amplia de problemas específicos. En el contexto de los sistema; | b a s a d o s en Web, Germán y Cowan [GER001 sugieren las siguientes categorías de pa-1 trones: P a t r o n e s a r q u i t e c t ó n i c o s . Estos p a t r o n e s auxilian en el diseño del contenido y s arquitectura de la WebApp. Las secciones 19.6.1 y 19.6.2 p r e s e n t a n p a t r o n e s arquitectónicos para el contenido y la arquitectura de la WebApp. Además, están disponibles m u c h o s patrones arquitectónicos relacionados (por ejemplo, Java Blueprints e- j java.sun.com/blueprints/) para los ingenieros Web que deben diseñar WebApps en una diversidad de dominios de negocios. P a t r o n e s d e c o n s t r u c c i ó n d e c o m p o n e n t e s . Estos p a t r o n e s recomiendan métodos para combinar c o m p o n e n t e s WebApp (por ejemplo, objetos de contenido, fur I *

ciones) e n c o m p o n e n t e s c o m p u e s t o s . Cuando se requiere la funcionalidad de proce-l Sarniento de d a t o s en una WebApp, son aplicables los p a t r o n e s de diseño arquitectónico y al nivel de c o m p o n e n t e que proponen [BUS96], 1GAM95] y otros. P a t r o n e s d e n a v e g a c i ó n . Estos patrones auxilian en el diseño de USN, vínculos tie navegación y el flujo global de navegación de la WebApp. P a t r o n e s d e p r e s e n t a c i ó n . Estos p a t r o n e s auxilian en la presentación del contenido c o m o se presenta al usuario vía la interfaz correspondiente. Los p a t r o n e s en esta categoría abordan c ó m o organizar las funciones de control de la interfaz del usuario para u n a mejor facilidad de uso; c ó m o mostrar la relación entre TMuna acción de la interfaz y los objetos de contenido que afecta; c ó m o establecer jerarquías de contenido efectivas; y m u c h a s otras.

PDF Editor

P a t r o n e s d e i n t e r a c c i ó n c o m p o r t a m i e n t o / u s u a r i o . Estos p a t r o n e s auxilian en el diseño de la interacción usuario-máquina. Los p a t r o n e s e n esta categoría abordan

13 Véase la barra lateral al final d e esta sección.

CAPÍTULO 19


595

cómo la interfaz informa al usuario de las consecuencias de una acción específica; cóm o un usuario expande el contenido con b a s e en el contexto de uso y sus deseos; c ó m o describir mejor el destino que implica un vínculo; c ó m o informar al usuario acerca del estado de una interacción en marcha y otros. Las fuentes de información acerca de los patrones de diseño hipermedia se han expandido en forma sustancial en a ñ o s recientes. Los lectores interesados deben consultar [GAR97], [PER991 y [GEROO], HERRAMIENTAS DE SOFTWARE

Almacenes

de patrones de diseño hipermedia

El sitio W e b lAWiki (http://iowiki.net/WebsitePatterns) es un espacio d e discusión conjunto l nformación d e los arquitectos y que contiene muchos i útiles. Entre ellos están vínculos a varios catálogos es d e patrones hipermedia útiles. Están represen¡ ; entos d e patrones d e diseño:

«én d e p a t r o n e s d e d i s e ñ o h i p e r m e d i a 'www.designpattern.lu.unisi.ch/

lionPatterns d e Tom Erickson , 'www.pliant.org/personal/Tom__Erickson/lnteracns.html

es d e d i s e ñ o W e b d e Martijn v a n W e l i e 'www.welie.com/patterns/

Mejora d e los s i s t e m a s d e información W e b con p a t r o n e s d e n a v e g a c i ó n http://www8.org/w8-papers/5b-hyper1ext-media/improving/improving.html

Un patrón d e l e n g u a j e HTML 2 . 0 http://www.anamorph.com/docs/patterns/default.html

Terreno c o m ú n http://www.mit.edu/~itidwell/interaction_patterns.html

Patrones p a r a sitios W e b p e r s o n a l e s http://www.rdrop.com/--half/Creations/WriHngs/Web. patterns/index.html

Indice d e l e n g u a j e s patrón http://www.es.brown.edu/~rms/lnformationStructures/ Indexing/Overview.html

•DO A OBJETOS ( M D H O O ) Durante las p as ad a s décadas se propusieron varios métodos de diseño para aplicaciones Web. A la fecha, ningún método es el dominante. En esta sección se presenta un breve p a n o r a m a de uno de los métodos de diseño WebApp m á s ampliamente analizados: MDHOO. H El método de diseño hipermedia orientado a objetos (MDHOO) lo propusieron originalmente Daniel Schwabe y sus colegas [SCH95, SCH98J. El MDHOO está compuesto de cuatro diferentes actividades de diseño: diseño conceptual, diseño de navegación, diseño abstracto de la interfaz e implementación. En la figura 19.11 s e muestra un resumen de estas actividades de diseño, y en las secciones que siguen se discuten TM brevemente.

19.10.1 Diseño conceptual por el MDHOO

PDF Editor

El diseño conceptual mediante el MDHOO crea una representación de los subsistemas, clases y relaciones que definen el dominio de aplicación para la WebApp. Se

14 Koch [KOC99] ha desarrollado una amplia c o m p a r a ; : - de los ciez métodos de diseño hipermedia.

596

CAPÍTULO 19


R e s u m e n d e l m é t o d o MDHOO ( a d a p t a d o d e [SCH95]). — T ~ —

Diseño conceptual

Productos d e t r a b a j o

Mecanismos d e diseño

Preocupaciones d e diseño

rB Diseño d e navegación

Diseño abstracto d e la interfaz

Implementación

Objetos abstractos d e la interfaz, | | respuestas a eventos externos, transformaciones

WebApp ejecutable

Clases, subsistemas, relaciones, atributos

Nodos, vínculos, estructuras d e a c c e s o , contextos d e navegación, transformaciones d e navegación

Clasificación, composición, agregación, generalización, especialización

Correlación entre objetos conceptúales y d e navegación

Correlación entre objetos d e navegación y perceptibles V.

Recurso proporcionado por ambiente objetivo

M o d e l a d o d e la semántica del dominio d e aplicación

Toma en cuenta el perfil del usuario y la t a r e a . Resalta los aspectos cognitivos.

M o d e l a d o d e los objetos perceptibles, implementación d e las metáforas elegidas. Descripción d e la interfaz p a r a los objetos d e navegación

Exactitud; desempeño d e la a p l i c a d o ' integridad

puede usar 1 5 UML para crear diagramas de clase adecuados, agregados y representaciones de clase compuestas, diagramas de colaboración y otra información que describe el dominio de la aplicación (véase la Parte 2 de este libro para m á s detalles-. Como un ejemplo simple de diseño conceptual del MDHOO, considérese de nuevo la aplicación de comercio electrónico de HogarSegurolnc.com. En la figura 19.12 se muestra un "esquema conceptual" parcial para HogarSeguroInc.com. Los diagram a s de clase, agregados e información relacionada desarrollados como parte de. análisis de la WebApp se reutilizan durante el diseño conceptual para representar relaciones entre clases.

19.10.2 Diseño de navegación mediante el MDHOO El diseño de navegación identifica un conjunto de "objetos" que se derivan de las clas e s definidas en el diseño conceptual. Se define una serie de "clases de navegación' o "nodos" para encapsular dichos objetos. Se puede usar UML para TM crear casos c t uso adecuados, gráficos de estado y diagramas de secuencia, todos ellos auxilian al diseñador a comprender mejor los requisitos de navegación. Además, es posib.r

PDF Editor

aplicar los patrones de diseño para el diseño de navegación conforme el diseño se desarrolle. El MDHOO utiliza un conjunto predefinido de clases de navegación: no-

15 El MDHOO n o prescribe una notación específica; sin embargo, el uso de UML e s común c u a n d o se aplica este método.

CAPÍTULO 19

MODELADO DE DISEÑO PAEA APLICACIONES WEB

597

Esquema conceptual parcial para HogarSeguroInc.com. cliente selecciona

recomendación de componente solicitada

Habitación

componente

parteNúmero parfeNombre parleTipo descripción precio

FacturaDeMateriales ¡Identificado' ListaFdM NúmeroArtícuios precioTotal

crearNuevoArticulo{) obtenerDescripción() obtenerEspecíécnica

KabitaciónNombre dimensiones exteriorVentanas exteriorPuertas

agregarEntradaj ]

nombré{} calculorPrecio( ¡ Sensor

Cámara

Panel Control

CaractSoRware

ArtículoFdM

cliente continúa selección componentes pedidoNúmero ciientelnfo facluraDeMateriales embarquelnfo cobran zolnfo

cliente solicita compra

cantidad parteNúmero parteNambre parteTípo precio agregaraUtíal j borrardelista|) obtenerSiguiente Eftfrodolista()

dos, vínculos, anclas y estructuras de acceso [SCH98]. Las estructuras de acceso son m á s elaboradas e incluyen mecanismos como un índice de la WebApp, un mapa de sitio o un paseo guiado. Una vez definidas las clases de navegación, el MDHOO "estructura el espacio de navegación mediante el agrupamiento de los objetos d e navegación en conjuntos llamados contextos" [SCH98], Schwabe describe un contexto en los términos siguientes: C a d a definición d e c o n t e x t o incluye, a d e m á s d e l o s e l e m e n t o s q u e e s t á n i n c l u i d o s e n él, la e s p e c i f i c a c i ó n d e su e s t r u c t u r a d e n a v e g a c i ó n i n t e r n a , u n p u n t o d e e n t r a d a , restriccion e s de acceso en términos d e clases de usuario y operaciones, y una estructura de acceso asociada. S e d e s a r r o l l a u n a plantilla d e c o n t e x t o ( a n á l o g a a las t a r j e t a s CRC e s t u d i a d a s e n el c a pítulo 8) y se e m p l e a p a r a r a s t r e a r l o s r e q u i s i t o s d e n a v e g a c i ó n d e c a d a c a t e g o r í a d e u s u a rio a t r a v é s d e v a r i o s c o n t e x t o s d e f i n i d o s e n el MDHOO. Al h a c e r e s t oTM surgen rutas e s p e c í f i c a s d e n a v e g a c i ó n (que s e l l a m a r o n FdN e n la s e c c i ó n 19.7.1).

PDF Editor 19.10.3 Diseño abstracto de la interfaz e implementación

La actividad de diseño abstracto de la interfaz especifica los objetos de la interfaz que

el usuario ve conforme interactúa con la WebApp. Un modelo formal de objetos de la interfaz, llamado visión abstracta de datos (VADi se utiliza para representar la re-

598

P A R T E TRES


Iación entre objetos d e la interfaz y objetos de navegación, y las características comportamiento de los objetos de la interfaz. El modelo VAD define una "plantilla estática" [SCH98] que representa la metáfo de la interfaz e incluye una representación de los objetos de navegación dentro i la interfaz y la especificación de los objetos de la interfaz (por ejemplo, menús, tones, iconos) que auxilian en la navegación y la interacción. Además, el mode »| VAD contiene un componente relacionado con el comportamiento (similar al diagr; ma de estado UML) que indica cómo los eventos externos "disparan la navegación qué transformaciones de la interfaz ocurren cuando el usuario interactúa con la ap cación" [SCHOIJ. Una exposición detallada del VAD el lector interesado puede hallala en [SCH98] y [SCH01], La actividad implementación del MDHOO representa una interacción de dis que es específica al ambiente en el que operará la WebApp. Las clases, la nave ción y la interfaz son caracterizadas en una forma que puede construirse para el; biente cliente/servidor, sistemas operativos, software de soporte, lenguajes de gramación y otras características del entorno relevantes respecto del problema.

Las métricas de diseño se deben caracterizar en una forma que proporcione a lo; : genieros Web un indicador de calidad en tiempo real. En esencia, un conjunto útil i medidas y métricas ofrece respuestas cuantitativas a las siguientes preguntas: • ¿La interfaz del usuario promueve la facilidad de uso? • ¿La estética de la WebApp es apropiada para el dominio d e la aplicación y confortable para el usuario? • ¿El contenido está diseñado en una forma que proporciona la mayor informa-1 ción con el menor esfuerzo? • ¿La navegación es eficiente y directa? • ¿La arquitectura de la WebApp se ha diseñado para acomodar las metas y < jetivos especiales de los usuarios de la WebApp, la estructura de contenido y funcionalidad, y el flujo de navegación requerido para usar el sistema de ma ñera efectiva? • ¿Los componentes están diseñados en una forma que reduce la complejidad TM de procedimientos y aumenta la exactitud, la confiabilidad y el d e s e m p e ñ o ' En la actualidad, cada una de estas preguntas se puede abordar de manera cua¡: tiva, 16 pero todavía n o existe un conjunto validado de métricas que ofrezcan puestas cuantitativas.

PDF Editor

16 Véase el capítulo 16 (sección 16.4) y la sección 19.1 l para una exposición cualitativa de la ca d e u n a WebApp

CAPITULO 19

599

M O D E L A D O DE DISEÑO P A E A APLICACIONES WEB

Las métricas para el diseño de WebApps están en desarrollo y pocas se han validado ampliamente. El lector interesado debería consultar [IVOOl] y [MENO!] para una muestra de las métricas propuestas para el diseño de WebApps.


Métricas técnicas para WebApps O b j e t i v o : Apoyar a los ingenieros W e b en el desarrollo de métricas W e b A p p significativas ofrezcan una visión acerca d e la calidad global d e aplicación. "iica: Las herramientas mecánicas varían.

-mientas representativas17 -hanic Toots, desarrollada por Netmechanic (www. -etmechanic.com), es una colección d e herramientas q u e ayudan a mejorar el desempeño d e un sitio W e b ;

W e b Slalic Analyzer

Tool ¡WebSATj:

verifica el HTML d e

la p á g i n a w e b contra los lineamientos d e facilidad d e uso típicos. Web Colegory Anolysis

Tool (WebCAT):

permite al inge-

niero d e facilidad d e uso construir y dirigir un análisis d e categoría Web. W e b Variable Instrumenter Program (WebVIP): instrumenta un sitio W e b p a r a capturar un registro d e interacción d e usuario. Framework for Logging Usability Dala fFLUD): implemen-

se enfoca sobre los temas específicos d e la implementa-

to un formateador y analizador gramatical de archivos

ción.

p a r a representar los registros d e interacción d e usua-

í Web Metrics Teslbed, desarrollado por The National -istitute of Standards and Technology (zing.ncsl.nist. gov/WebTools/), a b a r c a la siguiente colección d e herramientas útiles q u e están disponibles p a r a descargar-

rio. VisVIP Tool: produce una visualización tridimensional d e las rutas d e navegación del usuario a través d e un sitio Web. TreeDec: a g r e g a auxiliares d e navegación a las páginas d e un sitio Web.

La calidad de una WebApp —definida en términos de facilidad de uso, funcionalidad, confiabilidad, eficiencia, facilidad de mantenimiento, seguridad, escalabilidad y tiemp o en el mercado— se introduce durante el diseño. Para lograr dichos atributos d e calidad, un buen diseño WebApp debe posser simplicidad, consistencia, identidad, robustez, navegabilidad y apariencia visual. El diseño d e la interfaz describe la estructura y organización de la interfaz del usuario. Incluye una representación de la plantilla de pantalla, una definición de los modos de interacción y una descripción de los mecanismos de navegación. El diseño estético, también llamado diseño gráfico, describe la "apariencia y la TM percepción" de la WebApp e incluye e s q u e m a s de color, plantilla geométrica, tamañ o de texto, fuente y ubicación, el uso de gráficos y decisiones estéticas relaciona das. Un conjunto de lineamientos de diseño gráfico proporciona la base para un en-

PDF Editor foque de diseño.

17 Las h e r r a m i e n t a s a n o t a d a s son una muestra d e esta categoría

600

P A R T E TRES


El diseño de contenido define la plantilla, la estructura y el subrayado de todo ei contenido que se presenta como parte de la WebApp; además, establece las relacione s entre objetos de contenido. El diseño de contenido comienza con la representación de los objetos de contenido, sus asociaciones y relaciones. Un conjunto de corsideraciones elementales establece las bases para el diseño de navegación. El diseño de arquitectura identifica la estructura hipermedia global para la Web App y abarca tanto la arquitectura de contenido c o m o la de WebApp. Los estilos ar quitectónicos para el contenido incluyen estructuras lineal, en retícula, jerárquica > en red. La arquitectura de la WebApp describe una infraestructura que permite a un sistema o aplicación basado en Web lograr s u s objetivos d e negocios. El diseño de navegación representa el flujo de navegación entre los objetos ce contenido y para todas las funciones de la WebApp. La navegación s e define al des cribir un conjunto de unidades semánticas de navegación. Cada unidad está coir puesta de formas de navegación y d e vínculos y nodos d e navegación. Los mecanimos de sintaxis de navegación se aplican para afectar la navegación descrita corr í parte de la semántica. El diseño de componentes desarrolla la lógica de procesamiento detallada que se requiere para implementar los componentes funcionales de la WebApp. Las técnicas de diseño descritas en el capítulo 11 se aplican a la ingeniería de componentes Web App. Los patrones para el diseño de WebApps abarcan patrones d e diseño genéric: que se aplican a todos los tipos de software y patrones hipermedia especialmente re levantes para las WebApp, Se han propuesto patrones de diseño arquitectónico, de navegación, de componentes, de presentación y de comportamiento/usuario. El método de diseño hipermedia orientado a objetos (MDHOO) es uno de varic? métodos propuestos para el diseño WebApp. El MDHOO sugiere un proceso de diseñ o que incluye diseño conceptual, diseño de navegación, diseño abstracto de la irterfaz e implementación. Las métricas de diseño para ingeniería Web están en desarrollo y todavía tienen que validarse por completo. Sin embargo, se han propuesto varias medidas y métricas para abordar cada una d e las actividades de diseño reanalizadas en este capítulo

[AME96] Amento, B. eí al., "Fitt's Law", CS 5724: Models and Theories of Human Computer Inte ractions, Virginia Tech, 1996, disponible e n h t t p : / / e i . c s . v t . e d u / ~ c s 5 7 2 4 TM /gl/. [BAG01] B a g g e r m a n , L., y S. B o w m a n , Web Design That Works, Rockport Publishers, 2001. [BUS96] B u s c h m a n n , F. eí al., Pattern-Oriented Software Architecture, Wiley, 1996. (CAC02] C a c h e r o , C. et al., "Conceptual Navigation Analysis: a Device a n d Platform Independen! Navigation Specification", Proc. 2nd Intl. Workshop on Web-Oríented Technology, junio de 2002, s e p u e d e d e s c a r g a r de w w w . d s i c . u p v . e s / - w e s t / i w w o s t 0 2 / p a p e r s / c a c h e r o . p d f . [CLOOl] Cloninger, C., Fresh Styles for Web Designers, New Riders Publishing, 2001. [D1X99] Dix, A., "Design of User Interfaces for the Web", Proc. OfUser Interfaces to Data Systems Conference, septiembre d e 1999, s e p u e d e descargar d e h t t p : / / w w w . c o m p . l a n c s . a c . u k / c o m p u t i n g / users/dixa/topics/webarch/.

PDF Editor

CAPÍTULO 19

M O D E L A D O DE DISEÑO P A E A APLICACIONES WEB

601

(FIT54] Fitts, P., "The Information Capacity of t h e H u m a n Motor System in Controlling the Ampiitude of Movement", en Journal of Experimental Psychology, vol. 47, 1954, pp. 381-391. [FOW03] Fowler, M. et al., Patterns of Enterprise Application Architecture, Addison-Wesley, 2003. [GAL02) Galitz, W., The Essential Guide to User Interface Design, Wiley, 2002. 1GAM95] G a m m a , E. etal., Design Pattems, Addison-Wesley, 1995. [GAR97] Garrido, A., G. Rossi y D. Schwabe, " P a t t e m s Systems for Hypermedia", 1997, s e p u e d e d e s c a r g a r de w w w . i n f . p u c - r i o . b r / - s c h w a b e / p a p e r s / P l o P 9 7 . p d f . [GEROO] G e r m á n , D. y D. C o w a n , "Toward a Unified Catalog of Hypermedia Design Pattems", Proc. 33rd Hawaii Intl. Conf. on System Sciences, IEEE, vol. 6, Maui, Hawaii, junio de 2000, s e p u e d e d e s c a r g a r de w w w . t u r i n g m a c h i n e . o r g / - - d m g / r e s e a r c h / p a p e r s / d m g _ h i c s s 2 0 0 0 . p d f . [GNA99] G n a h o , C. y F. Larcher, "A User-Centered Methodology for Complex a n d Customizable Web Engineering", Proc. Ist ICSE Workshop on Web Engineering, ACM, Los Angeles, m a y o d e 1999. [HEI02] Heinicke, E„ Layout: Fast Solutions for Hands-On Design, Rockport Publishers, 2002. [IVOOl] Ivory, M., R. Sinha y M. Hearst, "Empirically Validated Web Page Design Metrics", ACM S1GCHI '01, Seattle, WA, abril d e 2001, disponible en h t t p : / / w w w . r a s h m i s i n h a . c o m / a r t i c l e s / WebTangoCHIOl .html. [IAC02] Jacyntho, D., D. S c h w a b e y G. Rossi, "An Architecture for Structuring Complex Web Applications", 2002, disponible e n h t t p : / / w w w 2 0 0 2 . o r g / C D R O M / a l t e m a t e / 4 7 8 / . [KAI02] Kaiser, J., "Elementó of Effective Web Design", About, Inc., 2002, disponible e n h t t p : / / w e b design.about.com/library/weekly/aa091998.htm. [KAL03] Kalman, S., Web Security Field Guide, Cisco Press, 2003. [KOC99] Koch, N., "A C o m p a r a t i v e Study of Methods for Hypermedia Development", Technical Report 9905, Ludwig-Maximilians Universitat, Munich, Alemania, 1999, se p u e d e d e s c a r g a r de h t t p : / / w w w . d s i c . u p v . e s / ~ w e s t 2 0 0 1 / i w w o s t 0 l / f i l e s / c o n t r i b u t i o n s / N o r a K o c h / h y p dev.pdf. [KRA88] Krasner, G. y S. Pope, "A Cookbook for Using the Model-View Controller User Interface Paradigm in Smalltalk-80", Journal of Object-Oriented Programming, vol. I, n ú m . 3, a g o s t o - s e p t i e m b r e d e 1988, pp.26-49. [LOW981 Lowe, D., y W. Hall (eds.), Hypertext and the Web—An Engineering Approach, John Wiley & Sons, 1998. [MCC01] McClure, S. ]. S c a m b r a y y G. Kurtz, Hacking Exposed, McGraw-Hill/Osbome, 2001. [MEN01) Mendes, E„ N. Mosley y S. Counsell, "Eslimating Design a n d Authoring Effort", e n IEEE Multimedia, e n e r o - m a r z o d e 2001, pp. 50-57. [MILOO] Miller, E., "The Website Quality Challenge", S o f t w a r e Research, Inc., 2000, h t t p : / / w w w . soft.com/eValid/Technology/White.Papers/website.quality.challenge.html. [NIE96] Nielsen, J. y A. Wagner, "User Interface Design for the WWW", Proc. CHI '96 Conf. On Human Factors in Computing Systems, ACM Press, 1996, pp. 330-331. [NIEOO] Nielsen, J., Designing Web Usability, New Riders Publishing, 2000. [NOR02J Northcutt, S. y J. Novak, Network Intrusión Detection, New Riders Publishing, 2002. [OFF02) Offutt, J., "Quality Attributes of Web Software Applications", e n IEEE Software, m a r z o abril d e 2002, pp. 25-32. [OLS98] Olsina, L„ "Building a Web-Based Information System Applying the Hypermedia Flexible Process Modeling Strategy", Proc. Ist Intl. Workshop on Hypermedia Development, 1998. [OLS99] Olsina, L. et al., "Specifying Quality Characteristics a n d Attributes for Web Sites", Proc. Ist ICSE Workshop on Web Engineering, ACM, Los Ángeles, m a y o d e 1999. [PER99] Perzel, K. y D. Kane, "Usability P a t t e m s for Applications o n t h e World Wide Web", 1999, s e p u e d e d e s c a r g a r d e h t t p : / / j e r r y . c s . u i u c . e d u / - p l o p / p l o p 9 9 / p r o c e e d iTM ngs/Kane/perzel_ kane.pdf. [POWOO] Powell, T„ Web Design, McGraw-Hill/Osbome, 2000. (RASOO] Raskin, J„ The Humane Interface, Addison-Wesley, 2000. [RH098] Rho, Y. y T. Gedeon, "Surface Structures in Browsing the Web", Proc. Australasian Com puter Human Interaction Conference, IEEE, diciembre d e 1998. [SCH95] Schwabe, D. y G. Rossi, "The Object-Oriented Hypermedia Design Model", e n CACM, vol. 38, n ú m . 8, a g o s t o de 1995, PP. 45-46.

PDF Editor

602

P A R T E TRES


[SCH98] S c h w a b e , D. y G. Rossi, "Developing Hypermedia Applications Using OOHDM", Proc Workshop on Hypermedia Development Process, Methods and Models, Hypertext '98, 1998, se p u e d e d e s c a r g a r de h t t p : / / c i t e s e e r . n j . n e c . c o m / s c h w a b e 9 8 d e v e l o p i n g . h t m l . 1SCH01] S c h w a b e , D., G. Rossi y S. B a r b o s a , "Systemalic Hypermedia Application Design Using OOHDM", 2 0 0 1 , d i s p o n i b l e e n h t t p : / / w w w - d i . i n i . p u c - r i o . b r / ~ s c h w a b e / H T 9 6 W W W , s e c t i o n l .html. [TILOO] Tillman, H. N., "Evaluating Quality On the Net", B a b s o n College, 3 0 d e m a y o de 2000, disponible en http://www.hopetillman.eom/findqual.html#2 [TOGOI] Tognozzi, B„ "First Principies", askTOG, 2001, disponible e n h t t p : / / w w w . a s k t o g . c o m basics/firstPrinciples.hlml. [WMT02] Web Mapping Testbed TUtorial, 2002, disponible e n h t t p : / / w w w . w e b m a p p i n g org/vcgdocuments/vcgTutorial/. [ZI1A02] Z h a o , H„ "Fitt's Law: Modeling M o v e m e n t Time in HC1", Theories in Computer Humar. Interaction, University of Maryland, o c t u b r e de 2002, disponible e n h t t p : / / w w w . c s . u m d . e d u class/fall2002/cmsc838s/tichi/fitts.html.

1 9 . 1 . ¿Por q u é el "ideal artístico" e s u n a filosofía d e d i s e ñ o insuficiente c u a n d o s e c o n s t r u y e las WebApps m o d e r n a s ? ¿Existe u n c a s o e n el q u e el ideal artístico sea la filosofía q u e d e b e se guirse? 1 9 . 2 . En e s t e capítulo s e a n a l i z ó u n a amplia variedad d e atributos d e calidad p a r a las Wer Apps. Elíjanse las t r e s q u e s e c o n s i d e r e c o m o las m á s i m p o r t a n t e s y e l a b ó r e s e un a r g u m e n : : q u e e x p l i q u e por q u é c a d a u n o d e b e r e s a l t a r s e en el t r a b a j o de d i s e ñ o d e ingeniería Web. 1 9 . 3 . A g r é g u e n s e al m e n o s c i n c o p r e g u n t a s a d i c i o n a l e s a la "Lista d e verificación d e la c a l i d a : del d i s e ñ o d e la WebApp" p r e s e n t a d a e n u n a b a r r a lateral e n la s e c c i ó n 19.1.1. 1 9 . 4 . Revisar los principios de d i s e ñ o de la interfaz de Tognozzi t r a t a d o s e n la s e c c i ó n 19.3. Considerar c a d a principio p a r a u n a WebApp operativa c o n la cual s e e s t é familiarizado. Calir c a r la WebApp ( ú s e n s e calificaciones A, B, C, D o F) e n relación c o n el g r a d o e n el cual ha : g r a d o el principio. Explicar la r a z ó n p a r a c a d a calificación. 1 9 . 5 . Diseñar u n a interfaz p r o t o t i p o p a r a la WebApp d e H o g a r S e g u r o l n c . c o m . Inténtese ser ir n o v a d o r pero, al m i s m o tiempo, se d e b e a s e g u r a r q u e la interfaz s e a j u s t a a los principios el b u e n d i s e ñ o d e la interfaz. 1 9 . 6 . ¿Se h a n e n c o n t r a d o m e c a n i s m o s d e control d e la interfaz q u e s e a n d i f e r e n t e s a los a t a d o s e n la Sección 19.3.2? Si e s así, d e s c r í b a n s e b r e v e m e n t e . 1 9 . 7 . El lector e s el d i s e ñ a d o r WebApp p a r a u n a c o m p a ñ í a de e n s e ñ a n z a a larga distancia intención e s i m p l e m e n t a r un " m o t o r d e a p r e n d i z a j e " b a s a d o en Internet q u e le permitirá en" g a r c o n t e n i d o del c u r s o a los e s t u d i a n t e s . El m o t o r d e a p r e n d i z a j e o f r e c e la i n f r a e s t r u c t u r a sica p a r a e n t r e g a r c o n t e n i d o d e a p r e n d i z a j e de cualquier m a t e r i a ( d i s e ñ a d o r e s de conten 1 p r e p a r a r á n el c o n t e n i d o a d e c u a d o ) . Desarróllese un d i s e ñ o de interfaz p r o t o t i p o p a r a el m de aprendizaje. 1 9 . 8 . ¿Cuál e s el sitio Web e s t é t i c a m e n t e m á s a g r a d a b l e q u e el lector haya hTM a visitado y por 1 9 . 9 . Considerar el o b j e t o d e c o n t e n i d o p e d i d o , g e n e r a d o u n a v e z q u e u n u s u a r i o de Ho S e g u r o l n c . c o m h a c o m p l e t a d o la selección d e t o d o s los c o m p o n e n t e s y e s t á listo p a r a final s u c o m p r a . Desarrollar u n a descripción UML d e p e d i d o j u n t o c o n t o d a s las r e p r e s e n t a c i o n e s diseño apropiadas.

PDF Editor

1 9 . 1 0 . ¿Cuál e s la diferencia e n t r e a r q u i t e c t u r a d e c o n t e n i d o y a r q u i t e c t u r a d e WebApp?

1 9 . 1 1 . R e c o n s i d é r e s e el " m o t o r de a p r e n d i z a j e " descrito e n el p r o b l e m a 19.7, s e l e c c i ó n e s e a r q u i t e c t u r a d e c o n t e n i d o q u e sería a p r o p i a d a p a r a la WebApp. C c o m é n t e s e por q u é s e hizo c h a elección.

CAPÍTULO 19

603

M O D E L A D O DE DISEÑO PARA A P L I C A C I O N E S WEB

1 9 . 1 2 . C o n UML d e s a r r ó l l e n s e tres o c u a t r o r e p r e s e n t a c i o n e s d e d i s e ñ o p a r a o b j e t o s d e c o n t e n i d o q u e p o d r í a n e n c o n t r a r s e c o n f o r m e s e d i s e ñ a el " m o t o r d e a p r e n d i z a j e " d e s c r i t o e n el p r o b l e m a 19.7. 1 9 . 1 3 . H a c e r u n p o c o d e i n v e s t i g a c i ó n a d i c i o n a l a c e r c a d e la a r q u i t e c t u r a MVC y decidir si s e ria u n a a r q u i t e c t u r a W e b A p p a p r o p i a d a p a r a el " m o t o r d e a p r e n d i z a j e " m e n c i o n a d o e n el p r o b l e m a 19.7. 1 9 . 1 4 . ¿Cuál e s la d i f e r e n c i a e n t r e s i n t a x i s d e n a v e g a c i ó n y s e m á n t i c a d e n a v e g a c i ó n ? 1 9 . 1 5 . Definir d o s o tres USN p a r a la W e b A p p d e H o g a r S e g u r o I n c . c o m . Describir c a d a u n a c o n c i e r t o detalle. 1 9 . 1 6 . H a c e r a l g u n a i n v e s t i g a c i ó n y p r e s e n t a r a s u c l a s e d o s o t r e s p a t r o n e s d e d i s e ñ o hipermedia completos.

A u n q u e s e h a n e s c r i t o c i e n t o s d e libros a c e r c a del " d i s e ñ o Web", m u y p o c o s a b o r d a n a l g u n o s m é t o d o s t é c n i c o s s i g n i f i c a t i v o s p a r a r e a l i z a r el t r a b a j o d e d i s e ñ o . C u a n d o m u c h o , s e p r e s e n t a n v a r i o s l i n c a m i e n t o s útiles p a r a el d i s e ñ o d e la W e b A p p , e j e m p l o s v a l i o s o s d e p á g i n a s Web y s e m u e s t r a p r o g r a m a c i ó n j a v a , y se a n a l i z a n los d e t a l l e s t é c n i c o s i m p o r t a n t e s p a r a i m p l e m e n t a r W e b A p p s m o d e r n a s . Entre los m u c h o s q u e s e o f r e c e n e n e s t a c a t e g o r í a , vale la p e n a c o n s i d e rar la d i s c u s i ó n e n c i c l o p é d i c a d e Powell [POWOO], A d e m á s , los libros d e Galitz [GAL02], H e i n i c k e |HE102], S c h m i t t (Designing CSS Web Pages, N e w Riders Publishing, 2002), D o n n e l l y (Designing Easy-toUse Websitcs, Addison-Wesley, 2001) y Nielsen [N1E00] p r o p o r c i o n a n u n a g u í a útil. La visión ágil del d i s e ñ o (y o t r o s tópicos) p a r a W e b A p p s la p r e s e n t a n W a l l a c e y s u s c o l e g a s {Extreme Programmingfor Web Projects, Addison-Wesley, 2003). C o n a l l e n (Building Web Applica tions with UML, s e g u n d a e d i c i ó n , Addison-Wesley, 2002) y R o s e n b e r g y Scott ( A p p f y i n g Use Ca se Driven Object Modeling wilh UML, A d d i s o n - W e s l e y , 2001) p r e s e n t a n e j e m p l o s d e t a l l a d o s d e W e b A p p s m o d e l a d a s c o n la a p l i c a c i ó n d e UML. Van D u y n e y s u s c o l e g a s (The Design of Sites: Pattems, Principies and Processes, A d d i s o n - W e s ley, 2002) e s c r i b i e r o n u n libro e x c e l e n t e q u e c u b r e los a s p e c t o s m á s i m p o r t a n t e s del p r o c e s o d e d i s e ñ o e n la i n g e n i e r í a Web. S e c u b r e n e n d e t a l l e l o s m o d e l o s d e p r o c e s o d e d i s e ñ o y los p a t r o n e s d e d i s e ñ o . W o d t k e [Information Architecture, N e w Riders Publishing, 2003), R o s e n f e l d y Morville (Information Architecturefor the World Wide Web, O'Reilly & A s s o c i a t e s , 2002), y Reiss (Prac tical Information Architecture, Addison-Wesley, 2000) a b o r d a n la a r q u i t e c t u r a d e c o n t e n i d o y o t r o s tópicos. Las t é c n i c a s d e d i s e ñ o t a m b i é n s e m e n c i o n a n e n libros e s c r i t o s a c e r c a d e a m b i e n t e s d e d e sarrollo específicos. Los lectores i n t e r e s a d o s d e b e n e x a m i n a r libros a c e r c a d e J2EE, Java, ASP.NET, CSS, XML, Perl y u n a d i v e r s i d a d d e a p l i c a c i o n e s d e c r e a c i ó n d e W e b A p p s (Dreamweaver, Home Page, Frontpage, GoLive, MacroMedia Flash, etc.) p a r a c o m e n t a r i o s d e d i s e ñ o útiles. En Internet e s t á d i s p o n i b l e u n a g r a n v a r i e d a d d e f u e n t e s d e i n f o r m a c i ó n a c e r c a d e d i s e ñ o p a r a i n g e n i e r í a Web. U n a lista a c t u a l i z a d a d e r e f e r e n c i a s e n la World Wide W e b s e e n c u e n t r a e n el sitio W e b d e SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P I T U L O

C Ó M O PROBAR APLICACIONES W E B

CONCEPTOS CLAVE características de error

606

dimensiones de calidad

605

estrategia . . . . 6 0 7 pruebas de base de datos

613

de carga

633

de configuración 6 2 8 de c o n t e n i d o . . 6 1 2 de desempeño 631 de facilidad de uso

E

xiste una urgencia que siempre permea el proceso de ingeniería Web. Con forme se dirigen la formulación, la planeación, el análisis, ei diseño y i construcción, los participantes —preocupados acerca de la competencia o otras WebApps, fustigados por las d e m a n d a s de los clientes e intranquilos porq _ perderán una ventana en el mercado— presionan para poner la WebApp en lir.-r Como consecuencia, las actividades técnicas que usualmenle ocurren en las últ m a s etapas del proceso de ingeniería Web, c o m o la prueba de la WebApp, en oc¿ siones reciben poca atención. Esto puede ser un error catastrófico. Para evitar el equipo de ingeniería Web debe asegurarse de que cada producto de trabajo c IWeb muestre alta calidad. Wallace y sus colegas [WAL03] advierten esto cuanc afirman: Llevar a c a b o la p r u e b a n o d e b e e s p e r a r h a s t a q u e t e r m i n e el p r o y e c t o . C o m i e n c e a p r o b a r a n t e s d e escribir u n a línea d e c ó d i g o . P r u e b e c o n s t a n t e y e f e c t i v a m e n t e y de-

620

de interfaz de usuario . . 6 1 6 de navegación 6 2 5 de nivel de componentes 6 2 3 de prueba de compatibilidad . . . 6 2 2

s a r r o l l a r á u n sitio W e b m u c h o m á s d u r a b l e .

Dado que los modelos de análisis y diseño no pueden ponerse a prueba en ¡ sentido clásico, el equipo de ingeniería Web debe dirigir revisiones técnicas 1c males (capítulo 26), así como pruebas ejecutables. El objetivo es descubrir y c: rregir errores antes de que la WebApp se ponga a disposición de sus usuarios f nales.

de tensión . . . 6 3 3

¿ Q u é e s ? El proceso de someter o prueba la WebApp es una suma de actividades relacionadas con una sola meta: descubrir errores en el contenido, la función, la facilidad de uso, ¡a navegabilidad, el desempeño, la capacidad y la seguridad de la WebApp. Esto se logra a lo largo de todo el proceso de ingeniería Web mediante la aplicación de una estrategia de prueba que abarca tanto revisiones como pruebas ejecutables. : ¿ Q u i é n lo h a c e ? Los ingenieros Web y otros participantes del proyecto (gerentes, clientes, usuarios finales) toman parte en el proceso de probar la WebApp. ¿ P o r q u é e s i m p o r t a n t e ? Si los usuarios finales encuentran errores que afecten su confianza en la WebApp, se irán a cualquier otra parte

por el contenido y la función que necesitan, y la WebApp fracasará. Por esta razón, los ingenieros Web deben trabajar para eliminar tantos errores como sea posible antes de que la WebApp esté en linea ¿ C u á l e s s o n los p a s o s ? El proceso de prueba de la WebApp comienza al enfocarse sobre aquellos aspectos de ésta que son visibles para el usuario y procede a probar dicha tecnología e infraestructura. La prueba consta de siete etaTM pas: contenido, interfaz, navegación, componente, configuración, desempeño y prueba de seguridad.

PDF Editor 604

¿Cuál es el producto obtenido? En algunos casos se produce un plan de prueba de la WebApp. En todos los casos se desarrolla un conjunto de casos prueba para cada etapa de la prue-

CAPÍTULO 20

C Ó M O PROBAR A P L I C A C I O N E S WEB

:c y se conserva un archivo de resultados de pruebas para uso futuro. ^ r i o p u e d o e s t a r s e g u r o d e q u e lo h e l e c h o c o r r e c t a m e n t e ? Aunque nunca se ;
20.1

605

se la seguridad de que la puesta en prueba ha descubierto errores (y que éstos se han corregido). Además, si se ha establecido un plan de prueba, puede verificarse para asegurar que se han realizado todas las pruebas planeadas.

P R U E B A DE C O N C E P T O S PARA W E B A P P S En el capítulo 13 se señaló que la prueba es el proceso de ejercitar al software con la finalidad de encontrar (y a final de cuentas corregir) errores. Esta filosofía fundamental no cambia para las WebApps. De hecho, puesto que los sistemas y aplicaciones basados en Web residen en una red e interoperan con muchos sistemas operativos diferentes, navegadores (u otros dispositivos de interfaz como PDA o teléfonos celulares), plataformas de hardware, protocolos de comunicaciones y aplicaciones "de cuarto trasero", la búsqueda de errores representa un desafío significativo para los ingenieros Web. La comprensión de los objetivos de las pruebas dentro de un contexto de ingeniería Web requiere considerar las diversas dimensiones de la calidad WebApp.' En el contexto de esta exposición se consideran las dimensiones de calidad que son particularmente relevantes en cualquier debate de las pruebas para el trabajo de ingeniería Web. También se considera la naturaleza de los errores que se encuentran como consecuencia de las pruebas, y la estrategia de poner a prueba aplicable para descubrir dichos errores.

20.1.1 Dimensiones de calidad La calidad se incorpora en una aplicación Web como consecuencia de un buen diseño. Se evalúa al aplicar una serie de revisiones técnicas que valoran varios elementos del modelo de diseño y al aplicar un proceso de prueba que se trata a lo largo de este capítulo. Tanto las revisiones como las pruebas examinan una o más de las siguientes dimensiones de calidad [MIL00]: se la ¿«tro del de una y su

• El contenido se evalúa tanto en el ámbito sintáctico como semántico. En el ámbito sintáctico, la ortografía, la puntuación y la gramática se valoran para TM los documentos basados en texto. En el ámbito semántico se valoran la exactitud (de la información presentada), la consistencia (a través de todos los objetos de contenido y objetos relacionados) y la falta de ambigüedad.

PDF Editor

• La función se prueba para descubrir errores que indiquen que no hay concordancia con los requisitos del cliente. Cada función de la WebApp se valora en

1

En el capitulo 19 también se consideró la calidad d e ¡a WebApp

606

PARTE TRES


c u a n t o a exactitud, inestabilidad y concordancia general con los e s t á n d a r e s de implementación apropiados (por ejemplo, estándares de lenguaje Java o XML). • La estructura se valora para asegurarse de que entrega a d e c u a d a m e n t e contenido y función de la WebApp, que es extensible y p u e d e sostenerse conforme se a ñ a d e n u e v o contenido o funcionalidad. • La facilidad de uso se prueba para garantizar que a cada categoría de usuario la soporta la interfaz; p u e d e a p r e n d e r y aplicar toda la sintaxis y s e m á n t i c a de navegación requerida. • La navegabiiidad

se p o n e a prueba para garantizar que toda la sintaxis y se-

mántica de navegación se ejercen para descubrir cualquier error de navegación (por ejemplo, vínculos rotos, vínculos inadecuados, vínculos erróneos). • El desempeño

se prueba e n una diversidad de condiciones operativas, configt

raciones y c a r g a s para a s e g u r a r q u e el sistema responde a la interacción del usuario y m a n e j a cargas e x t r e m a s sin que haya u n a degradación operativa inaceptable. • La compatibilidad

se prueba al ejecutar la WebApp en varias configuraciones

huésped, e n los lados tanto del cliente c o m o del servidor. El objetivo e s encontrar errores específicos respecto a sólo u n a configuración huésped. • La interoperabilidad

se prueba para a s e g u r a r que la WebApp realiza interfaces

a d e c u a d a s con otras aplicaciones o b a s e s de datos. • La seguridad se prueba al valorar las vulnerabilidades potenciales e intentar explotar cada una de ellas. Cualquier intento de penetración exitoso se cons. dera u n a falla en la seguridad. En este capítulo se estudian, m á s adelante, u n a estrategia y algunas tácticas que « han desarrollado para p o n e r a p r u e b a cada una de las anteriores características ce calidad de una WebApp. "La innovación es un asunto agridulce para quienes ponen a prueba el software. Justo cuando parece que se sabe cómo probar una tecnología particular, llega una nueva [WebApp] y todas las apuestas se pierden." James Bach

20.1.2 Errores dentro de un ambiente WebApp Ya se h a s e ñ a l a d o que el intento primario de realizar pruebas en cualquier contexto» TM de s o f t w a r e e s descubrir errores (y corregirlos). Los errores e n c o n t r a d o s c o m o c o r secuencia de la prueba exitosa de la WebApp tienen varias características únicas

PDF Editor [NGUOOJ:

1. Puesto que m u c h o s tipos de p r u e b a s de WebApp descubren problemas que se evidencian primero en el lado del cliente (es decir, a través de una interfaz implementada en un navegador específico, una PDA o un teléfono celular), d I ingeniero Web ve un síntoma del error, n o el error e n sí.

CAPÍTULO 20

2.

C Ó M O PROBAR A P L I C A C I O N E S WEB

607

Puesto que u n a WebApp se implementa en varias configuraciones diferentes y dentro de distintos ambientes, p u e d e ser difícil o imposible reproducir un error afuera del a m b i e n t e en el que el error se e n c o n t r ó originalmente.

3. i vil

ción HTML impropia (o algún otro lenguaje de programación), m u c h o s errores

l e s de Isaftware

Aunque algunos errores s o n resultado de u n diseño incorrecto o u n a codificapueden rastrearse hacia la configuración de la WebApp.

4.

Puesto que las WebApp residen dentro de u n a arquitectura cliente/servidor, el rastreo de los errores p u e d e ser difícil a través de las tres c a p a s arquitectónicas: el cliente, el servidor o la red en sí.

5.

Algunos errores se deben al ambiente operativo estático (es decir, la configuración específica en la que se desarrolla la prueba), mientras que otros son atribuibles al a m b i e n t e operativo dinámico (es decir, la carga instantánea de recursos o los errores relacionados con el tiempo).

Estos cinco atributos de error sugieren que el a m b i e n t e d e s e m p e ñ a un importante papel en el diagnóstico de todos los errores descubiertos d u r a n t e el proceso de ingeniería Web. En a l g u n a s situaciones (por ejemplo, prueba de contenido), el sitio del error es obvio, pero e n m u c h o s otros tipos de p r u e b a s de WebApp (por ejemplo, p r u e b a s de navegación, de d e s e m p e ñ o , de seguridad) la c a u s a subyacente del error tal vez sea considerablemente m á s difícil de determinar.

20.1.3 Estrategias de pruebas La estrategia para probar u n a WebApp adopta los principios básicos para t o d a s las p r u e b a s de s o f t w a r e (capítulo 13) y aplica una estrategia y las tácticas que se recom e n d a r o n respecto de los s i s t e m a s orientados a objetos (capítulo 14). Los siguientes p a s o s r e s u m e n el enfoque: 1. Se revisa el m o d e l o de contenido de la WebApp para descubrir errores.

kVE i global i la WebApp • asumir en > anotados

2 . Se revisa el m o d e l o de la interfaz para asegurarse que t o d o s los c a s o s de uso pueden a c o m o d a r s e . 3 . Se revisa el m o d e l o d e diseño de la WebApp para descubrir errores de navegación. 4 . Se prueba la interfaz del usuario para descubrir errores en la presentación o los m e c a n i s m o s de navegación. TM 5 . C o m p o n e n t e s funcionales seleccionados se prueban en forma individual.

6.

Se prueba la navegación a través de toda la arquitectura.

PDF Editor

7 . La WebApp se implementa en diversas configuraciones a m b i e n t a l e s y se prueba su compatibilidad con cada configuración.

8. Se realizan p r u e b a s de seguridad c o n el objetivo de explotar vulnerabilidades e n la WebApp o dentro de su ambiente.

608

P A R T E TRES

9.


Se llevan a c a b o p r u e b a s de d e s e m p e ñ o .

1 0 . La WebApp se prueba en u n a población controlada y monitoreada de usuan as finales; los resultados de su interacción con el sistema s e evalúan para busca.-] errores de contenido y navegación, relacionados con la facilidad de uso, cor la compatibilidad y con la confiabilidad y el d e s e m p e ñ o de la WebApp.

www.ílitkyminds. com/testlng-asp.

Puesto q u e m u c h a s WebApps evolucionan c o n t i n u a m e n t e , la prueba de la W e b A r J es una actividad d e seguimiento q u e dirige el equipo d e soporte Web, que u t n a l p r u e b a s de regresión derivadas de las p r u e b a s desarrolladas c u a n d o la WebApp s J sometió a ingeniería por primera ocasión.

20.1.4 Planeación de las pruebas El e m p l e o de la palabra planeación (en cualquier contexto) es a n a t e m a para algur : J d e s a b o l l a d o r e s Web. Como se a n o t ó en capítulos anteriores, dichos profesiona em sólo comienzan, p u e s t e m e n el surgimiento de algún s a b o t e a d o r de WebApps. Un r - | geniero Web reconoce que la planeación establece un m a p a vial para todo el trar.^J jo que sigue. Vale la p e n a el esfuerzo. En su libro acerca de las pruebas d e las WebApps, Splaine yjaskiel [SPL01] a f i r m a d E x c e p t o p o r el m á s s i m p l e d e los sitios Web, r á p i d a m e n t e se v u e l v e a p a r e n t e q u e e s nec e s a r i a cierta e s p e c i e d e p l a n e a c i ó n d e p r u e b a s . C o n d e m a s i a d a f r e c u e n c i a , el n ú m e r o inicial d e e r r o r e s q u e s e e n c u e n t r a n a p a r t i r d e u n a p r u e b a a d e c u a d a e s lo s u f i c i e n t e m e n t e g r a n d e c o m o p a r a q u e n o t o d o s s e fijen la p r i m e r a v e z q u e s e d e t e c t a n . E s t o p o n e u n a pre s i ó n a d i c i o n a l s o b r e la g e n t e q u e p r u e b a l o s sitios y a p l i c a c i o n e s Web. No s ó l o d e b e n c o r j u r a r n u e v a s p r u e b a s i m a g i n a t i v a s , t a m b i é n d e b e n r e c o r d a r c ó m o s e e j e c u t a r o n las p r u e b a s a n t e r i o r e s c o n la finalidad d e volver a p r o b a r c o n c o n f i a b i l i d a d el s i t i o / l a aplica c i ó n Web, y a s e g u r a r s e d e q u e l o s e r r o r e s c o n o c i d o s s e h a n r e m o v i d o y q u e n o s e h a n introducido otros nuevos.

C&VE El plan de prueba identifica un conjunto de tareas de prueba, los productos de trabojo que se desarrollarán y la forma en lo cual los resultados se evalúan, registran y reutilizan.

La pregunta para t o d o ingeniero Web es: ¿ c ó m o "conjuro n u e v a s pruebas i nativas" y e n qué se deben enfocar dichas pruebas? La respuesta se e n c u e n t r a tro de un plan de pruebas. Un plan de pruebas WebApp identifica 1) un conjunto de tareas 2 que se apli c u a n d o c o m i e n c e la prueba, 2) los productos de trabajo que se g e n e r a r á n coní se ejecute cada tarea de prueba, y 3) la forma en la q u e los resultados de las b a s se evalúan, registran y reutilizan c u a n d o s e realicen p r u e b a s de regresión. E"g u n o s casos, el plan de p r u e b a s se integra con el plan del proyecto; TM en otros, el de p r u e b a s e s un d o c u m e n t o s e p a r a d o .

PDF Editor 2

Los c o n j u n t o s de tareas se estudian en el capítulo 2. En este libro también se ha e m p l e a d o un

mino relacionado —flujo de trabajo— para describir la serie d e t a r e a s necesaria para completa:

actividad de ingeniería del software.

CAPÍTULO 20

20.2

609

C Ó M O PROBAR APLICACIONES WEB

E L P R O C E S O DE P R U E B A : UN P A N O R A M A Los procesos de prueba para ingeniería Web comienzan con pruebas que ejercitan el contenido y la funcionalidad de la interfaz que e s inmediatamente visible para los usuarios finales. Conforme se realizan las pruebas, se ejercitan los aspectos de la arquitectura d e diseño y la navegación. El usuario puede o n o conocer estos elementos de la WebApp. Finalmente, el foco se cambia a las pruebas que ejercitan las capacidades tecnológicas que n o siempre son aparentes para los usuarios finales: la infraestructura de la WebApp y cuestiones de instalación/implementación. "£n general, ¡as técnicos de prueba de software [capítulos 13 y 14] que se utilizan con otras i mismas que las empleadas en las aplicaciones basadas en Web... La diferencia entre los dos tipos de pruebas es que se multiplican las variables de tecnología en el ambiente Web."

La figura 20.1 yuxtapone el proceso d e prueba WebApp con la pirámide de diseñ o examinada en el capítulo 19. Nótese que, conforme se desarrolló el flujo de pruebas, de izquierda a derecha y de arriba abajo, los elementos del diseño WebApp visibles para el usuario (elementos superiores de la pirámide) se prueban primero, seguidos por los elementos de diseño de infraestructura.

Prueba Prueba d e la interfaz usuario Prueba d e navegación Diseño d e la interfaz Diseño estético Diseño de contenido

Prueba de componentes

Diseño de navegación Diseño arquitectónico Diseño de componentes tecnología

Prueba d e configuraciónTM

PDF Editor Prueba d e desempeño

Prueba d e seguridad

610

P A R T E TRES


La prueba de contenido

(y las revisiones) intentan descubrir errores en el c o n t é -

do. Esta actividad de prueba es similar en m u c h o s aspectos a la copia-edición de d o c u m e n t o escrito. De hecho, un gran sitio Web p u e d e reclutar los servicios de un rrector de estilo profesional para descubrir errores tipográficos, equívocos grama" cales, errores en la consistencia del contenido, inexactitudes e n las representacicr gráficas y fallas en las referencias c r u z a d a s . A d e m á s de e x a m in a r el contenido • tico e n busca de errores, esta etapa de las p r u e b a s también considera el conten : dinámico derivado de los d a t o s c o n s e r v a d o s c o m o parte de un sistema de b a s e d a t o s integrado a la WebApp. La prueba de la interfaz ejercita los m e c a n i s m o s d e interacción y valida los a s p e : tos estéticos de la interfaz del usuario. El objetivo e s descubrir los errores que re tan de mecanismos con u n a pobre implementación de interacción, u omisiones, r sistencias o ambigüedades que se han introducido a la interfaz en forma inadvertida La prueba de navegación

aplica c a s o s de uso, derivados c o m o parte d e la a c t r

dad de análisis, en el diseño de c a s o s de prueba q u e ejerciten c a d a escenario de contra el diseño de navegación. Los m e c a n i s m o s de navegación (por ejemplo, barras de menú) implementa dentro de la plantilla d e la interfaz se p r u e b a n contra c a s o s de uso y USN (capi 19) para garantizar que los errores q u e impiden completar un c a s o de uso se ide fiquen y corrijan. La prueba de componentes

ejercita el contenido y las unidades funcionales d e -

de la WebApp. Cuando se consideran las WebApps, cambia el c o n c e p t o d e un : (introducido en el capítulo 13). La "unidad" de elección dentro de la arquitectura contenido (capítulo 19) es la página Web. Cada página Web encapsula conter vínculos d e navegación y e l e m e n t o s d e p r o c e s a m i e n t o (formatos, guiones, app' Una "unidad" dentro de la arquitectura WebApp p u e d e ser un c o m p o n e n t e funci definido q u e proporciona servicio directamente a un usuario final o un c o m p o n de infraestructura q u e posibilita q u e la WebApp desarrolle t o d a s sus capacida Cada c o m p o n e n t e funcional se prueba, en gran parte, en la misma forma que prueba un módulo individual en el s o f t w a r e convencional. En la mayoría de los sos, las p r u e b a s están orientadas a las c a j a s negras. Sin e m b a r g o , si el p r o c e s a m to e s complejo, también se pueden usar p r u e b a s de c a j a s blancas. 3 Además de prueba funcional, también se ejercitan las c a p a c i d a d e s de b a s e s de datos.

\ CLAVE Lo estrategia para la prueba de integración depende de la arquitectura de la WebApp elegido durante el diseño.

Conforme se construye la arquitectura d e la WebApp, las p r u e b a s de la n a v ción y los c o m p o n e n t e s s e utilizan c o m o pruebas de integración. TM La estrategia la prueba de integración d e p e n d e del contenido y la arquitectura WebApp que se ya elegido (capítulo 19). Si la arquitectura de contenido se diseña con estructura

PDF Editor

neal, retícula o jerárquica simple, e s posible integrar páginas Web en gran parte la misma forma c o m o se integran módulos para el s o f t w a r e convencional. Sin bargo, si se usa u n a estructura de jerarquía mixta o de red (Web), la prueba de i 3

Las técnicas d e p r u e b a s d e caja negra y c a j a blanca se e x a m i n a n en el capítulo 14.

CAPÍTULO 20

611


gración es similar al enfoque u s a d o para los sistemas OO. Las pruebas basadas en ligas (capítulo 14) s e pueden aprovechar para integrar el conjunto de páginas Web (se puede usar una USN para definir el conjunto apropiado) requerido para responder a un evento d e usuario. Cada liga se integra y p o n e a prueba individualmente. Mediante las pruebas de regresión se asegura que no ocurran efectos colaterales. Las pruebas de agrupamiento integran un conjunto de páginas asociadas (determin a d a s mediante el e x a m e n de los casos de u s o y la USN). Los casos de prueba se derivan para descubrir los errores en las colaboraciones. Cada elemento de la arquitectura WebApp se prueba de manera unitaria en la m e dida de lo posible. Por ejemplo, en una arquitectura MVC (capítulo 19), los compon e n t e s modelo, vista y controlador se prueban cada uno d e manera individual. Después de la integración, el flujo de control y datos a través de cada u n o d e estos elementos se valora en detalle. Las pruebas de configuración

intentan descubrir los errores que son específicos

respecto de un cliente o ambiente de servidor particulares. Se crea una matriz de referencia cruzada que define todos los probables sistemas operativos, navegadores, 4 plataformas de hardware y protocolos de comunicación. Entonces las pruebas se encaminan a descubrir los errores asociados con cada posible configuración. La prueba de seguridad incorpora una serie de pruebas diseñadas para explotar las vulnerabilidades en la WebApp y su ambiente. El objetivo es demostrar la posibilidad de una brecha en la seguridad. La prueba de desempeño

abarca una serie de p r u e b a s diseñadas para valorar 1)

c ó m o afecta el a u m e n t o del tráfico de usuarios la respuesta en tiempo y confiabilidad d e la Web, 2) cuáles c o m p o n e n t e s de la WebApp son responsables d e la degradación del d e s e m p e ñ o y qué características de uso provocan que ocurra la degradación, y 3) c ó m o la degradación del d e s e m p e ñ o impacta los objetivos y requisitos globales de la WebApp.


Prueba d e Ja WebApp I. Revisar los requisitos d e los

Definir la estrategia d e prueba d e la W e b A p p al

participantes. Identificar las metas y objetivos d e los usuarios. Revisar los

describir los tipos d e pruebas (sección 20.2) q u e se realizarán.

casos d e uso respecto d e c a d a

Desarrollar un plan d e prueba.

categoría d e usuario. Establecer prioridades p a r a a s e g u r a r que c a d a meta • objetivo d e usuario se probarán d e manera adecuada.

Definir un calendario d e pruebas y asignar TM responsabilidades a c a d a prueba. Especificar herramientas automatizadas p a r a realizar las pruebas.

PDF Editor 4

y

Los n a v e g a d o r e s son notables porque i m p l e m e n t a r sus propios "estándares", sutilmente diferentes

en las interpretaciones de HTML y javascript

612

/ "

PARTE TRES


Definir criterios de aceptación p a r a c a d a clase d e prueba. Especificar mecanismos d e rastreo d e defectos.

Probar c a d a componente (por ejemplo, guión) para asegurar el funcionamiento a d e c u a d o , ó.

casos d e uso.

5. Realizar pruebas "unitarias". Revisar el contenido p a r a errores d e sintaxis y semántica.

Dirigir pruebas d e navegación. 7.

lado del cliente.

adecuados. operación correcta.

Realizar pruebas d e configuración. Valorar la compatibilidad d e configuración en el

Revisar el contenido p a r a clarificaciones y permisos Probar los mecanismos d e la interfaz p a r a una

Realizar pruebas d e "integración". Probar la semántica d e la interfaz respecto d e los

Definir mecanismos d e reporte d e problemas.

8.

Valorar configuraciones en el lado del servidor. Dirigir pruebas d e desempeño.

9.

Dirigir pruebas d e seguridad.

Los errores en el contenido de la WebApp pueden ser tan triviales c o m o errores I ^CONSEJO^

pográficos m e n o r e s o tan significativos c o m o información incorrecta, organizaci:

Aunque los revisiones técnicas formales no son porte de una prueba, se deben llevar a cabo revisiones de contenido para garantizar lo calidad del contenido.

impropia o violación de las leyes de propiedad intelectual. La prueba del conter intenta descubrir éstos y m u c h o s otros problemas a n t e s de que el usuario los cuentre. La prueba del contenido combina tanto revisiones c o m o la generación de casos : prueba ejecutables. La revisión se aplica para descubrir errores semánticos e n el cc tenido (examinados e n la sección 20.3.1). La prueba ejecutable se aprovecha para i cubrir errores de contenido susceptibles de rastrear hacia contenido dinámicamer derivado que hayan suministrado los datos adquiridos de u n a o m á s b a s e s de datos ]

20.3.1 Objetivos d e la prueba de contenido La prueba del contenido tiene tres objetivos importantes: 1) descubrir errores sinta:ticos (por ejemplo, errores tipográficos, equívocos gramaticales) en los document

CLAVE

Los objetivos de lo pruebo de contenido son 1) descubrir errores sintácticos en el contenido, 2) descubrir eirores semánticos y 3) encontrar errores estructurales.

b a s a d o s en texto, representaciones gráficas y otros m e d i o s audiovisuales, 2) des brir errores semánticos (es decir, errores en la precisión de la información o que i ta sea incompleta) en cualquier objeto de contenido p r e s e n ta do c o n f o r m e ocurra ! navegación, y 3) hallar errores e n la organización o estructura del contenido que i presenta al usuario final. El primer objetivo se logra e m p l e a n d o verificadores de ortografía y gramática i tomatizados. Sin embargo, m u c h o s errores sintácticos evaden la detección media TM te tales h e r r a m i e n t a s y d e b e descubrirlos un revisor h u m a n o (examinador). Como j a n o t ó en la sección anterior, la corrección de estilo es el mejor e n f o q u e para encc trar errores sintácticos.

PDF Editor

La prueba semántica se centra en la información p r e s e n t a d a dentro de cada

jeto de contenido. El revisor (examinador) d e b e responder las siguientes pregunt • ¿La información realmente es precisa? • ¿La información e s concisa y exacta?

CAPÍTULO 2 0

CÓMO PROBAR APLICACIONES WEB

613

¿La plantilla del objeto de contenido e s fácil de entender para el usuario?

preitos se

¿La información anidada en un objeto de contenido se encuentra con facilidad?

antear y para

¿Se han ofrecido referencias adecuadas para toda la información derivada de otras fuentes?

errores en el

¿La información presentada es consistente internamente y con la información que presentan otros objetos de contenido?

7

¿El contenido es ofensivo, engañoso o abre la puerta a litigios? ¿El contenido infringe derechos de autor o marcas registradas existentes? ¿El contenido contiene vínculos internos que complementan el contenido existente? ¿Los vínculos son correctos? ¿El estilo estético del contenido entra en conflicto con el estilo estético de la interfaz? La obtención de respuestas a cada una de estas preguntas en una WebApp grande (que contiene cientos de objetos de contenido) puede ser una labor atemorizante. Sin embargo, el fracaso para descubrir errores semánticos alterará la fe del usuario en la WebApp y puede conducir a fallas de la aplicación basada en Web. Los objetos de contenido existen dentro de una arquitectura que tiene un estilo específico (capítulo 19). Durante la prueba del contenido, la estructura y organización de la arquitectura del contenido se prueba para garantizar que el contenido requerido se presenta al usuario final en el orden y las relaciones adecuados. Por ejemplo, la WebApp HogarSeguroInc.com 5 presenta una variedad de información acerca d e sensores que se utilizan como parte de productos de seguridad y vigilancia. Los objetos de contenido proporcionan información descriptiva, especificaciones técnicas, una representación fotográfica e información relacionada. Las pruebas de la arquitectura de contenido de HogarSeguroInc.com s e esfuerzan por descubrir errores en la presentación de esta información (por ejemplo, una descripción del Sensor X se presenta con una fotografía del Sensor V).

20.3.2 Prueba de las bases de datos Las modernas aplicaciones Web hacen m u c h o más que presentar objetos de contenido estáticos. En muchos dominios de aplicación, la interfaz de las WebApps con bases de datos sofisticados gestionan sistemas y construyen objetos d e contenido dinámicos que se crean en tiempo real aprovechando datos adquiridos de una base de TM datos. Por ejemplo, una WebApp de servicios financieros puede producir compleja información basada en texto, tabular y gráfica acerca de una participación accionaria específica (por ejemplo, fondos de acciones o de inversión colectiva). El objeto de contenido compuesto que presenta esta información se crea dinámicamente después de

PDF Editor 5

La WebApp HogarSeguroInc.com se ha utilizado c o m o eiemplo a lo largo d e la Parte 3 de e s t e libro.

614

PARTE TRES


que el usuario ha consultado información acerca de una participación accionaria específica. Esto se logra mediante los siguientes pasos: 1) se consulta una gran base de datos de participaciones accionarias, 2) se extraen datos relevantes de la base de datos, 3) los datos extraídos se deben organizar como un objeto de contenido, y 4 este objeto de contenido (que representa información personalizada solicitada po: un usuario final) se transmite al ambiente del cliente para su despliegue. Los errores pueden ocurrir, y de hecho lo hacen, como consecuencia de cada uno de estas etapas. El objetivo de probar la base de datos e s descubrir dichos errores. La prueba de la base de datos para las WebApps es complicada por varios factores

®

1. La solicitud original de información en el lado del cliente rara vez se presenta en la forma (por ejemplo, lenguaje de consultas estructurado, [SQL, por sus siglas er. inglés]) que pueda introducirse en un sistema gestor de bases de datos (DBMS por sus siglas en inglés). En consecuencia, las pruebas se deben diseñar para descubrir errores cometidos al traducir la solicitud del usuario en una forma que puedan procesar dichos DBMS.

¿ Q u ¿ conflict o s complican

la p r u e b a d e b a s e s de d a t a s para WebApps?

2 . La base de datos quizá sea remota al servidor que hospeda la WebApp. Por lo tanto, se deben desarrollar las pruebas que descubran los errores en la comunicación entre la WebApp y la base de datos remota. 6 3 . Los datos brutos adquiridos de la base de datos se deben transmitir al servidor de la WebApp y formatearse adecuadamente para su transmisión subsecuente al cliente. En consecuencia, se deben desarrollar pruebas que demuestren la validez de los datos brutos que recibe el servidor WebApp, y también se deben crear pruebas adicionales que demuestren la validez de las transformaciones aplicadas a los datos brutos para crear objetos de contenido válidos. 4. Los objetos de contenido dinámico se deben transmitir al cliente en una forma que se pueda desplegar al usuario final. Por lo tanto, se debe diseñar una serie de pruebas para a) descubrir errores en el formato de objeto de contenido, y b) probar la compatibilidad con diferentes configuraciones de ambiente de cliente. Al considerar estos cuatro factores, se deben aplicar los métodos de diseño de casos de prueba para cada uno de los "estratos de interacción" [NGU01] anotados er la figura 20.2. Las pruebas deben asegurar que 1) información válida pasa entre e. cliente y el servidor desde el estrato de la interfaz; 2) la WebApp procese los guiones TM correctamente y extraiga o formatee adecuadamente datos del usuario; 3) los dato; del usuario pasen correctamente a una función de transformación de datos en el lado del servidor para formatear consultas apropiadas (por ejemplo, SQL); 4) las con

PDF Editor 6

Dichas p r u e b a s se vuelven complejas c u a n d o se e n c u e n t r a n b a s e s de d a t o s distribuidas o c u a n d :

se requiere el a c c e s o a u n almacén de d a t o s (capitulo 10).

CAPÍTULO 20


615

sultas pasen a un estrato de gestión de datos 7 que se comunique con rutinas de acceso a bases d e datos (potencialmente ubicadas en otra máquina). Los estratos de transformación d e datos, gestión de datos y acceso a bases de datos, que se muestran en la figura 20.2, usualmente se construyen con componentes reutilizables que se han validado por separado y como paquete. Si éste es el caso, las pruebas de la WebApp se centran en el diseño de casos de prueba para ejercitar las interacciones entre el estrato del cliente y los primeros dos estratos del servidor (WebApp y transformación de datos) mostrados en la figura. El estrato de la interfaz del usuario se prueba para garantizar que los guiones HTML están construidos de manera adecuada para cada solicitud de usuario y se transmiten adecuadamente al lado del servidor. La capa WebApp en el lado del servidor se prueba para asegurar que los datos del usuario se extraen adecuadamente de guiones HTML y se transmiten de manera adecuada al estrato de transformación de datos en el lado del servidor. Las funciones de transformación de datos se prueban para asegurar que se crea el SQL correcto y que pasa a componentes apropiados de gestión de datos. TMentender para Una exposición detallada de la tecnología subyacente que se debe diseñar apropiadamente dichas pruebas de bases de datos está más allá del alcance de este libro. El lector interesado debe consultar [SCE02], [NGU01] y [BROOl],

PDF Editor 7

La capa d e gestión d e d a t o s por lo general incorpora u n a interfase SQL al nivel d e llamada (SQL

CL1) c o m o p u e d e ser Microsoft OLE/ADO o ia Conectr. i J a d de Bases de Datos Java (Java Database Connectivity, JDBC)

616

PARTE TRES


"Como clientes electrónicos (ya sea de negocios o consumo) es improbable que tengamos confianza en un sitio Web que sufre de frecuentes periodos de inactividad, cuelga a la mitad de una transacción o tiene un mal sentido de la facilidad de uso. Las pruebas, por lo tanto, tienen un popel importantísimo en el proceso de desarrollo global." '5, ' ,• Wing Lam

20.4

P R U E B A DE LA I N T E R F A Z DEL U S U A R I O La verificación y validación de la interfaz del usuario de una WebApp ocurre en treí p u n t o s distintos d u r a n t e el proceso de ingeniería Web. Durante la formulación y el análisis de requisitos (capítulos 17 y 18) se revisa el modelo de la interfaz para garantizar que se ajusta a los requisitos del cliente y a otros e l e m e n t o s del m o d e l o de análisis. Durante el diseño (capítulo 19) se revisa el modelo de diseño de la interfaz para garantizar que se h a n alcanzado los criterios genéricos de calidad establecidos para t o d a s las interfaces de usuario, y que los conflictos en el diseño de la interfaz específicos de la aplicación se han abordado adecuadamente. Durante las pruebas, eenfoque se cambia a la ejecución de los aspectos específicos de la aplicación de la interacción del usuario según se manifiestan mediante la sintaxis y la semántica de la interfaz. Además, las pruebas proporcionan una valoración final de la facilidad de use.

20.4.1 Estrategia d e prueba d e la interfaz La estrategia global para la prueba de la interfaz es 1) descubrir los errores relacion a d o s con m e c a n i s m o s específicos de la interfaz (por ejemplo, errores en la ejecución a d e c u a d a de u n vínculo de m e n ú o la forma en que los d a t o s ingresan en ur formulario), y 2) descubrir los errores en la forma en que la interfaz implementa la semántica de navegación, la funcionalidad de la WebApp o el despliegue de contenido. El cumplimiento de esta estrategia requiere lograr varios objetivos: Las características de la interfaz se prueban para asegurar que las reglas del dise^ O N S E J O ^

Con excepción de especificidades orientados a la WebApp, la estrategia de la interfaz anotada oquí es aplicable a todos los tipos de software cliente/servidor.

ño, la estética y el contenido visual relacionado están a disposición del usuario sir error alguno. Las características incluyen tipo de fuentes, u s o de color, marcos, imágenes, bordes, tablas y e l e m e n t o s relacionados que se g e n e r a n conforme procede la ejecución de la WebApp. Los mecanismos

individuales de la interfaz se prueban en una forma análoga a la

prueba unitaria. Por ejemplo, las pruebas están d i s e ñ a d a s p a r a ejercitar todas las formas, creación de guiones en el lado del cliente, HTML dinámico, guioTM n e s CGI, clasificación por niveles de contenido y m e c a n i s m o s de interfaz específicos de la aplicación (por ejemplo, un carrito de c o m p r a s para u n a

PDF Editor

aplicación de comercio electrónico). En m u c h o s casos, las pruebas se pueden e n f o c a r exclusivamente en uno de dichos m e c a n i s m o s (la "unidad") para excluir otras características y funciones de la interfaz. Cada mecanismo

de la interfaz se prueba dentro del contexto de un caso de uso o

USN (capítulo 19) para una categoría de usuario específica. Este e n f o q u e de

CAPÍTULO 20


617

pruebas es análogo a las pruebas de integración (capítulo 13) en que las pruebas se llevan a cabo conforme los mecanismos de la interfaz se integran para permitir la ejecución de un caso de uso o una USN. La interfaz completa se prueba frente a los casos de uso y las USN seleccionadas para descubrir errores en su semántica. Este enfoque de pruebas es análogo a las pruebas de validación (capítulo 13), ya que el propósito es demostrar conformidad con la semántica específica del caso de uso o la USN. En el curso de esta etapa se lleva a cabo una serie de pruebas de facilidad de uso. La interfaz se prueba dentro de una diversidad de ambientes (por ejemplo, navegadores) para asegurar que será compatible. En la actualidad, esta serie de pruebas también se puede considerar como parte de las pruebas de configuración.

20.4.2 Prueba de mecanismos de la interfaz Cuando un usuario interactúa con una WebApp, la interacción ocurre por medio de uno o más mecanismos de la interfaz. En el párrafo siguiente se presenta un breve panorama de las consideraciones de prueba para cada mecanismo de la interfaz [SPL01]. [ CONSEJO

j de los sexternos ¡ -ealizorse o lo Í je roda la vida r WebApp. Paite ¡debe ser la ¡regular y i de los

V í n c u l o s . Cada vínculo de navegación se prueba para asegurar que se alcance el objeto de contenido o función adecuado. 8 El ingeniero Web construye una lista de todos los vínculos asociados con la plantilla de la interfaz (por ejemplo, barras de menú, artículos índice) y luego ejecuta cada uno de manera individual. Además, se deben ejercitar los vínculos dentro de cada objeto de contenido para descubrir malas URL o vínculos hacia objetos de contenido o funciones impropios. Finalmente, se deben probar los vínculos con WebApps externas para tener precisión y también deben evaluarse para determinar el riesgo de que se volverán inválidos con el tiempo. F o r m a t o s . En el ámbito microscópico las pruebas se realizan para garantizar que 1) las etiquetas identifican correctamente los campos dentro del formato y que los campos obligatorios están identificados visualmente para el usuario; 2) el servidor recibe toda la información contenida en el formato y ningún dato se pierde en la transmisión entre cliente y servidor; 3) se usan los valores por defecto adecuados cuando el usuario no selecciona de un menú desplegable o conjunto de botones; 4) las funcione s del navegador (por ejemplo, la flecha "retroceso") n o corrompen los datos ingresados en un formato; y 5) los guiones que realizan verificación de error en los datos TMerror significatiingresados funcionan de manera adecuada y ofrecen mensajes de vos. En un nivel más dirigido, las pruebas deben garantizar que 1) los campos del formato tienen ancho y tipos de datos adecuados; 2) el formato establece salvaguardas apropiadas para evitar que el usuario ingrese cadenas de texto más largas que cier-

PDF Editor 8

Dichas pruebas se pueden llevar a cabo c o m o ps-te de pruebas o de la interfaz o de navegación

618

^ O H S U O ^ -

Los pruebas de creación de guiones en el lado del cliente y las pruebes asociadas con el HTML dinámico se deben repetir siempre que se libere uno nuevo versión de un navegador popular.

P A R T E TRES


to máximo predefinido; 3) todas las opciones apropiadas para m e n ú s desplegables están especificadas y ordenadas en una forma significativa para el usuario final; 4 las características de "autollenado" del navegador no conducen a errores en la entrada de datos; 5) la tecla de tabulador (o alguna otra) inicia el movimiento adecuado entre campos de formato. C r e a c i ó n d e g u i o n e s e n e l l a d o d e l c l i e n t e . Las pruebas de caja negra s e llevar a cabo para descubrir los errores en el procesamiento conforme se ejecuta el guión (por ejemplo, Javascript). Dichas pruebas usualmente se acoplan con pruebas de formatos, ya que la entrada del guión por lo general se deriva de los datos proporcionados como parte del procesamiento de los formatos. Se debe realizar una prueba de compatibilidad para garantizar que el lenguaje de guión elegido funcionará adecuadamente en la configuración ambiental que soporta la WebApp. Además de poner a prueba el guión mismo, Splaine y Jaskiel [SPL01] sugieren que "debe asegurarse que los estándares de su compañía [WebApp] establecen el lenguaje preferido y la versión del lenguaje de creación de guiones que s e usará para la creación de guione s en el lado del cliente (y en el lado del servidor)". HTML d i n á m i c o . Cada página Web que contenga HTML dinámico se ejecuta para garantizar que el despliegue dinámico e s correcto. Además, se debe llevar a cabc una prueba de compatibilidad para garantizar que el HTML dinámico funciona adecuadamente en la(s) configuración (es) ambiental(es) que soporta la WebApp. V e n t a n a s p o p - u p . 9 Una serie de pruebas garantizan que 1) la pop-up está ubicada de manera adecuada y tiene un t a m a ñ o apropiado; 2) la pop-up n o cubre la ventana original de la WebApp; 3) el diseño estético de la pop-up e s consistente con el diseñ o estético de la interfaz; y 4) las barras de desplazamiento y otros mecanismos de control agregados a la pop-up funcionan, están ubicados adecuadamente y trabajar como se requiere. G u i o n e s CGI. Las pruebas de caja negra se dirigen centrándose en la integridad de los datos (conforme los datos pasan al guión CGI) y en el procesamiento del guiór una vez que los datos validados se han recibido. Además, se pueden llevar a cabc pruebas de desempeño para asegurarse de que la configuración del lado del servidor s e puede ajustar a las d e m a n d a s de procesamiento de invocaciones múltiples de los guiones CGI [SPL01]. C l a s i f i c a c i ó n p o r n i v e l e s del c o n t e n i d o . Las pruebas deben demostrar que la cía sificación por niveles de los datos está actualizada, s e despliega adecuadamente y se TM puede suspender sin error y volver a comenzar sin dificultad. Cookies. Se requieren pruebas tanto del lado del servidor como del lado del cliente En el lado del servidor, las pruebas deben garantizar que una cookie está construida de manera adecuada (contiene datos correctos) y se transmite de modo apropiado al

PDF Editor 9

La utilización de las pop-up se ha extendido m u c h o y son u n o de los principales motivos d e irrita-

ción para m u c h o s usuarios. Deben usarse juiciosamente o evitarlas por completo.

CAPÍTULO 2 0


619

lado del cliente c u a n d o se solicita contenido o funcionalidad específicos. Además, se prueba la propia persistencia de la cookie para garantizar que su fecha de expiración es correcta. En el lado del cliente, las p r u e b a s determinan si la WebApp u n e a d e c u a d a m e n t e las cookies existentes a u n a solicitud específica (enviada al servidor). M e c a n i s m o s d e la interfaz e s p e c í ñ c o s a la a p l i c a c i ó n . Las p r u e b a s c o n f o r m a n una lista de verificación de funcionalidad y características q u e se definen mediante el m e c a n i s m o de la interfaz. Por ejemplo, Splaine y Jaskiel [SPL01] sugieren la siguiente lista de verificación para la funcionalidad carrito de c o m p r a s definido para u n a aplicación de comercio electrónico: • La frontera (capítulo 14) prueba los n ú m e r o s mínimo y m á x i m o de artículos q u e pueden colocarse e n el carrito. • Probar una solicitud de "verificación" para un carrito vacío. • Probar el b o r r a d o a d e c u a d o d e un artículo del carrito. • Determinar mediante prueba si el contenido del carrito se vacía con una c o m pra. • Determinar mediante prueba la persistencia del contenido del carrito de c o m p r a s (esto se d e b e especificar c o m o parte de los requisitos del cliente). • Determinar mediante prueba si la WebApp p u e d e recuperar el contenido del carrito en alguna fecha futura (suponiendo q u e n o se ha realizado compra alguna) si el usuario solicita que el contenido se guarde.

20.4.3 Prueba de la semántica de la interfaz Una vez que cada m e c a n i s m o de la interfaz se ha p r o b a d o de m a n e r a "unitaria", el e n f o q u e de la prueba de la interfaz cambia para considerar la semántica d e ésta. La prueba de la s e m á n t i c a de la interfaz "evalúa cuán bien el diseño se ocupa de los usuarios, ofrece dirección clara, entrega retroalimentación y m a n t i e n e consistencia de lenguaje y enfoque" [NGU01]. Una revisión exhaustiva del modelo de diseño d e la interfaz p u e d e ofrecer resp u e s t a s parciales a las preguntas implícitas e n el párrafo anterior. Sin embargo, s e d e b e probar cada escenario de c a s o de uso (para cada categoría de usuario) una vez implementada la WebApp. En esencia, un c a s o de u s o s e convierte en la entrada p a ra el diseño de u n a secuencia de pruebas. La finalidad de la secuencia de p r u e b a s es descubrir ios errores que le impedirán al usuario lograr el objetivo asociado con el TM c a s o de uso. Conforme s e prueba cada c a s o de uso, el equipo de ingeniería Web m a n t i e n e u n a lista de verificación para asegurarse de que t o d o artículo del m e n ú se ha ejercido al

PDF Editor

m e n o s u n a vez, y que todo vínculo a n i d a d o d e n t r o de un objeto de contenido ha si-

d o e mp l e a d o . El objetivo es determinar si la WebApp ofrece un efectivo m a n e j o del error y recuperación.

PARTE TRES

620

A P L I C A C I Ó N DE L A INGENIERÍA W E B

20.4.4 Prueba de la facilidad de uso probarlofacilidadde uso se encuentra en www.ahref.com/ guides/design/

199806/0615$. html.

i

La prueba

de la facilidad

de uso e s similar a la p r u e b a d e la s e m á n t i c a d e la interfaz

(sección 20.4.3) e n el s e n t i d o d e q u e t a m b i é n e v a l ú a el g r a d o e n el c u a l los u s u a r i o s p u e d e n i n t e r a c t u a r e f e c t i v a m e n t e c o n la WebApp, a s í c o m o el g r a d o e n el cual U W e b A p p guía las a c c i o n e s d e los u s u a r i o s , p r o p o r c i o n a r e t r o a l i m e n t a c i ó n signific¿-| tiva y f o r t a l e c e u n e n f o q u e d e i n t e r a c c i ó n c o n s i s t e n t e . M á s q u e e n f o c a r s e fijamer:* e n la s e m á n t i c a de a l g ú n o b j e t i v o i n t e r a c t i v o , las r e v i s i o n e s y p r u e b a s d e la facilidad de u s o s e d i s e ñ a n p a r a d e t e r m i n a r el g r a d o e n el c u a l la i n t e r f a z d e la W e b A p p fac -J lita la vida del u s u a r i o . 1 0 Las p r u e b a s d e facilidad d e u s o p u e d e d i s e ñ a r l a s u n e q u i p o d e i n g e n i e r í a W e t v l App, p e r o l a s p r u e b a s m i s m a s las llevan a c a b o los u s u a r i o s finales. Se aplica la sig u i e n t e s e c u e n c i a d e p a s o s [SPL01]: 1.

Definir u n c o n j u n t o d e c a t e g o r í a s d e p r u e b a de facilidad d e u s o e identificar las m e t a s p a r a c a d a u n a .

2.

Diseñar pruebas que permitirán evaluar cada meta.

3.

S e l e c c i o n a r los p a r t i c i p a n t e s q u e dirigirán las p r u e b a s .

4.

I n s t r u m e n t a r la i n t e r a c c i ó n d e los p a r t i c i p a n t e s c o n la W e b A p p m i e n t r a s se

1

lleva a c a b o la p r u e b a . 5.

D e s a r r o l l a r un m e c a n i s m o p a r a v a l o r a r la facilidad d e u s o d e la WebApp.

La p r u e b a d e la facilidad de u s o p u e d e llevarse a c a b o e n v a r i o s g r a d o s d e abstrác-J ción: I) s e p u e d e v a l o r a r la facilidad d e u s o d e un m e c a n i s m o d e la i n t e r f a z e s p e c * j c o (por e j e m p l o , u n formulario); 2) s e p u e d e e v a l u a r la facilidad d e u s o d e u n a 1 n a Web c o m p l e t a ( a b a r c a n d o m e c a n i s m o s d e la interfaz, o b j e t o s d e d a t o s y fn e s r e l a c i o n a d a s ) ; o 3) s e p u e d e c o n s i d e r a r la facilidad d e u s o d e la W e b A p p pleta. El p r i m e r p a s o e n la p r u e b a d e la facilidad de u s o e s identificar u n c o n j u n t o de t e g o r i a s d e facilidad d e u s o y e s t a b l e c e r o b j e t i v o s d e p r u e b a p a r a c a d a c a t e g o r í a f ¿Qué caracteristicas de facilidad de uso se vuelven el f o t o de las pruebas, y qué objetivos específicos s e a b o r d a n ?

•

s i g u i e n t e s o b j e t i v o s y c a t e g o r í a s d e p r u e b a (escritos e n f o r m a d e p r e g u n t a ) il" este enfoque:" Irteractividad:

¿los m e c a n i s m o s de i n t e r a c c i ó n (por e j e m p l o , m e n ú s d e s p l e g

botones, punteros) s o n fáciles de e n t e n d e r y usar? Plantilla: ¿los m e c a n i s m o s de n a v e g a c i ó n , c o n t e n i d o y f u n c i o n e s e s t á n col e n u n a f o r m a q u e p e r m i t e n al u s u a r i o e n c o n t r a r l o s r á p i d a m e n t e ?

TM

PDF Editor

10 En este contexto se ha usado el término "amigable para el usuario". Desde luego, el problema es la percepción de un usuario de lo que es una interfaz "amigable" puede ser radicalmente di de la de otras. 11 Para preguntas adicionales acerca de la facilidad de uso, véase "Facilidad de uso" en el capí

CAPÍTULO 20

621

CÓMO P R O B A R A P L I C A C I O N E S W E B

Legibilidad:

¿el texto e s t á bien escrito y e s comprensible? 1 2 ¿Las r e p r e s e n t a c i o n e s

gráficas s o n fáciles d e e n t e n d e r ? Estética: ¿ia plantilla, el color, los c a r a c t e r e s y las características r e l a c i o n a d a s c o n d u c e n a un u s o m á s sencillo? ¿Los u s u a r i o s "se s i e n t e n c ó m o d o s " con la a p a r i e n cia y la percepción d e la WebApp? Características

de despliegue-, ¿la WebApp utiliza en f o r m a óptima el t a m a ñ o y la

resolución de la pantalla? Sensibilidad

del tiempo: ¿las características, f u n c i o n e s y c o n t e n i d o i m p o r t a n t e s

p u e d e n utilizarse o adquirirse d e m a n e r a o p o r t u n a ? Personalización:

¿la WebApp se a j u s t a por sí m i s m a a las n e c e s i d a d e s específicas

d e las d i f e r e n t e s c a t e g o r í a s d e u s u a r i o o u s u a r i o s individuales? Accesibilidad:

¿la WebApp e s accesible a las p e r s o n a s c o n d i s c a p a c i d a d e s ?

Dentro de c a d a u n a d e e s t a s c a t e g o r í a s s e d i s e ñ a u n a serie d e p r u e b a s . En a l g u n o s c a s o s , la "prueba" p u e d e ser u n a revisión visual d e u n a p á g i n a Web. En otros, s e p u e d e ejecutar de n u e v o la p r u e b a d e s e m á n t i c a d e la interfaz, p e r o en e s t a o c a s i ó n s o n m á s i m p o r t a n t e s las p r e o c u p a c i o n e s por la facilidad d e uso. C o m o e j e m p l o , c o n s i d é r e s e la valoración d e la facilidad d e u s o para la interacción y los m e c a n i s m o s d e la interfaz. C o n s t a n t i n e y Lockwood [CC>N03] sugieren q u e s e revise y p r u e b e la facilidad d e u s o d e la siguiente lista d e características d e la interfaz: a n i m a c i ó n , b o t o n e s , color, control, diálogos, c a m p o s , formularios, marcos, gráficos, etiquetas, vínculos, m e n ú s , m e n s a j e s , n a v e g a c i ó n , páginas, selectores, texto y b a r r a s d e h e r r a m i e n t a s . C o n f o r m e s e valora c a d a característica, los u s u a r i o s q u e realizan la p r u e b a la califican en u n a escala cualitativa. La figura 20.3 m u e s t r a un

TM

PDF Editor

12 Se pueden aprovechar el fndice de Legibilidad FOG y otros para proporcionar una valoración cuantitativa de la legibilidad. Véase para más detalles http //developer.gnome.org/documents/usability/ usability-readability.html

622

PARTE TRES


posible c o n j u n t o de "calificaciones" de valoración q u e p u e d e n seleccionar los usuarios. Estas calificaciones se aplican a c a d a característica individualmente, a una pagina Web c om ple ta o a la WebApp c o m o un todo.

20.4.5 Pruebas de compatibilidad Las WebApps d e b e n o p e r a r d e n t r o de a m b i e n t e s q u e difieren u n o de otro. Diferert e s c o m p u t a d o r a s , dispositivos de despliegue, s i s t e m a s operativos, n a v e g a d o r e s «

CLAVE

velocidad en las c o n e x i o n e s de red tienen u n a influencia significativa e n las v e l e i -

Los WebApps se ejecutan dentro de una

cidad de conexión. Las variaciones en el sistema operativo p u e d e n provocar c o n f l : -

variedad de ambientes en el lado del cliente. El objetivo de los pruebas de compatibilidad es descubrir errores asociados con un ambiente específico (por ejemplo, navegador).

d a d e s de p r o c e s a m i e n t o en el lado del cliente, la resolución de despliegue y las vel tos en el p r o c e s a m i e n t o de la WebApp. En ocasiones, los diferentes navegadores p r o d u c e n resultados ligeramente diferentes, sin importar el grado de estandarización HTML d e n t r o de la WebApp. Los plug-in requeridos p u e d e n o n o ser f á c i l m e n e accesibles p a r a u n a configuración particular. En a l g u n o s casos, los p e q u e ñ o s conflictos de compatibilidad n o representan prob l e m a s significativos, p e r o en otros se p u e d e n e n c o n t r a r serios errores. Por e j e m p . r j las velocidades de d e s c a r g a p u e d e n volverse inaceptables; la falta de u n plug-in requerido p u e d e h a c e r q u e el c o n t e n i d o n o sea disponible; la diferencias e n c u a n t o a l n a v e g a d o r p u e d e n c a m b i a r drásticamente la plantilla de página; los estilos de f u e - J tes se p u e d e n alterar y volverse ilegibles, o los f o r m a t o s p u e d e n e s t a r organizad : a l de m a n e r a i n a d e c u a d a . La prueba de compatibilidad se e s f u e r z a p a r a descubrir c - 1 c h o s p r o b l e m a s a n t e s de q u e la WebApp esté en línea. El primer p a s o en la prueba de compatibilidad e s definir u n c o n j u n t o de confie_raciones de c o m p u t a d o r a s "encontrado c o m ú n m e n t e " en el lado del cliente y s u s v a l riantes. En esencia, se crea una estructura de árbol que identifica c a d a plataforma de c o m p u t a d o r a , los dispositivos de despliegue típicos, los s i s t e m a s operativos s.:-J p o r t a d o s en la plataforma, los n a v e g a d o r e s disponibles, las probables velocidad-=• de conexión a Internet e información similar. A continuación, el equipo de i n g e n : e 3 ría Web p r o d u c e u n a serie de p r u e b a s de validación de compatibilidad, derivadas las p r u e b a s de la interfaz existentes, p r u e b a s de navegación, p r u e b a s de desem-'r-i ñ o y p r u e b a s de seguridad. La finalidad de estas p r u e b a s e s descubrir errores o p r : - i b l e m a s de ejecución q u e se p u e d e n rastrear h a s t a las diferencias de configuració". I

TM

Prueba de la WebApp

PDF Editor El e s c e n a r i o : Oficina d e Doug

Los a c t o r e s : Doug Miller (gerente del grupo de ingeniería del software de HogorSeguro) y Vinod Raman, miembro del « ¡ J p o de ingeniería del software del producto.

La conversación:

D o u g : ¿Qué piensas de la WebApp VO.O de c electrónico de HogarSegurolnc.com?

CAPÍTULO 20


s.bcontrotista hizo un buen trabajo. Sharon aesarrollo de la empresa] me dicen que la . mientras tú y yo conversamos. gastaría que tú y el resto del equipo hicieran prueba informal del sitio de comercio

623

Compre un sistema HogarSeguro Obtenga soporte técnico D o u g : Bien. Pero sigue las rutas de navegación hasta su conclusión. >

Vinod (observa los casos de uso en una c o m p u t a d o r a portátil): Sí, cuando eliges

m u e c a s ) : Creo que tendríamos j n a compañía de prueba para validar la ccavía nos estamos matando al intentar que ;'oducto salga a ta callo. iremos una empresa de prueba para las desempeño y seguridad, y nuestro . ya está haciendo pruebas. Sólo creo que oe .ista sería útil y, además, no gusta e:- costos en línea, así que... : ra):

¿Qué buscas?

estar seguro de que la interfaz y toda la son sólidos. > que podemos comenzar con los casos cada una d e las principales funciones de la

acerca de HogarSeguro el sistema HogarSeguro que

Especifique el sistema HogarSeguro que n e c e s i t a eso te llevará hasta

Seleccione componentes HogarSeguro Obtenga recomendaciones de componentes d e HogarSeguro Podemos ejercitar la semántica de cada ruta. D o u g : Mientras estás en eso, verifica el contenido que aparece en c a d a nodo de navegación. V i n o d : Desde luego... y los elementos funcionales también. ¿Quién está probando la facilidad d e uso? D o u g : Oh... la empresa de pruebas coordinará las pruebas de facilidad de uso. Hemos contratado una firma d e investigación de mercado que reclutará 20 usuarios típicos para el estudio de facilidad de uso, pero si ustedes descubren algún conflicto al respecto... V i n o d : Ya sé: dénselos a ellos. D o u g : Gracias, Vinod.

•5

P R U E B A AL —

PE COMPONENTES

Las pruebas al nivel de componentes,

también llamadas p r u e b a s de función, se enfo-

can s o b r e un conjunto de p r u e b a s que intentan descubrir errores en las funciones de la WebApp. Cada función WebApp es un m ó d u l o de s o f t w a r e (implementado en algún lenguaje de programación o guiones) y se puede probar e m p l e a n d o las técnicas de caja negra (y, e n algunos casos, d e caja blanca) e x a m i n a d a s en el capítulo 14. Los c a s o s de prueba al nivel de c o m p o n e n t e s con frecuencia se alimentan con entrada al nivel de formularios. Una vez definidos los datos de los formularios, el u s u a rio selecciona un botón u otro m e c a n i s m o de control para iniciar la ejecución. Son c o m u n e s los siguientes m é t o d o s de diseño de c a s o s de prueba (capítulo 14): • Partición de equivalencia. El dominio de e n tr a da de la función se TM divide e n categorías o clases de e n t r a da a partir de las cuales se derivan los c a s o s de prueba. La forma de entrada se valora p a r a determinar qué clases de d a t o s

PDF Editor

son relevantes para la función. Los c a s o s de prueba para cada clase de entrada se derivan y ejecutan mientras otras clases de e n tr a da se m a n t i e n e n c o n s tantes. Por ejemplo, u n a aplicación de comercio electrónico p u e d e

implementar u n a función que calcule los cargos de e m b a r q u e . Entre la diver-

624

PARTE TRES

A P L I C A C I Ó N DE LA INGENIERÍA W E B

sidad de información d e e m b a r q u e p r o p o r c i o n a d a m e d i a n t e un formulario, e s t á el código postal del usuario. Los c a s o s d e p r u e b a s e d i s e ñ a n con la fin d a d de descubrir e r r o r e s e n el p r o c e s a m i e n t o del código postal al especificar v a l o r e s de código postal q u e p u e d a n descubrir d i f e r e n t e s clases d e errores (por ejemplo, un código postal incompleto, un código postal correcto, un c g o postal inexistente, un f o r m a t o d e código postal erróneo). • Análisis de valores límite. Los d a t o s de los formularios se p r u e b a n en s u s lím: tes. Por ejemplo, la función d e cálculo d e e m b a r q u e s e ñ a l a d a a n t e r i o r m e n t e solicita el n ú m e r o m á x i m o d e d í a s requerido p a r a la e n t r e g a del producto, el formulario s e a n o t a n un m í n i m o d e 2 d í a s y un m á x i m o d e 14. Sin embaí go, las p r u e b a s d e valor de límite p u e d e n ingresar v a l o r e s d e 0, 1 , 2 , 13, 14 15 p a r a d e t e r m i n a r c ó m o r e a c c i o n a la función frente a los d a t o s en y fuera los límites de las e n t r a d a s válidas. 1 3 • Pruebas de ruta. Si la complejidad lógica d e la función e s alta,' 4 s e p u e d e i plear la p r u e b a d e ruta ( m é t o d o caja b l a n c a d e d i s e ñ o d e c a s o d e prueba) g a r a n t i z a r q u e s e h a ejercitado toda ruta i n d e p e n d i e n t e en el p r o g r a m a . A d e m á s de e s t o s m é t o d o s de d i s e ñ o d e c a s o s de prueba, s e utiliza u n a técnica m a d a p r u e b a d e error f o r z a d o [NGU01] p a r a producir c a s o s d e p r u e b a q u e deli d a m e n t e c o n d u c e n los c o m p o n e n t e s d e la WebApp hacia u n a condición d e error propósito e s descubrir los e r r o r e s q u e ocurren d u r a n t e el m a n e j o d e los e r r o r e s ejemplo, m e n s a j e s d e e r r o r e s incorrectos o inexistentes, falla de la WebApp c o n s e c u e n c i a del error, salida e r r ó n e a producida por e n t r a d a e r r ó n e a , e f e c t o s c terales r e l a c i o n a d o s c o n el p r o c e s a m i e n t o del c o m p o n e n t e ) . Cada c a s o d e p r u e b a al nivel d e c o m p o n e n t e s especifica t o d o s los valores d e trada y la salida e s p e r a d a q u e p r o p o r c i o n a r á el c o m p o n e n t e . La salida real pn da c o m o c o n s e c u e n c i a d e la p r u e b a se registra p a r a referencia futura d u r a n t e el porte y el m a n t e n i m i e n t o . En m u c h a s s i t u a c i o n e s la ejecución correcta de la función de u n a WebApp esta gada a u n a interfaz a d e c u a d a con u n a base d e d a t o s q u e p u e d e ser externa a la App. En c o n s e c u e n c i a , la p r u e b a d e la b a s e de d a t o s s e vuelve u n a p a r t e integral régimen de p r u e b a d e c o m p o n e n t e s . Hower [HOW97] e x a m i n a e s t o c u a n d o esc Los sitios Web a l i m e n t a d o s con b a s e s de d a t o s p u e d e n involucrar u n a interacción com pleja e n t r e n a v e g a d o r e s Web, s i s t e m a s operativos, aplicaciones plug-in, protocolos de co-

TM

PDF Editor

13 En este caso, un mejor diseño de entrada puede eliminar errores potenciales. El máximo núm días se podría seleccionar de un menú desplegable, con lo que se evita que el usuario espec una entrada fuera de los límites.

14 La complejidad lógica s e puede determinar al calcular la complejidad ciclomática del alg Véase el capítulo 14 para detalles adicionales.

CAPÍTULO 20

625


municación, servidores Web, b a s e s d e datos, p r o g r a m a s [lenguaje d e guión]..., m e j o r a s a ¡j¿!|I

la seguridad y cortafuegos. Tal complejidad imposibilita probar todas las posibles dependencias y todo lo que podría ir mal c o n un sitio. El típico proyecto de desarrollo d e un sitio Web también e s ta r á en un calendario agresivo, d e m o d o que el mejor enfoque d e prueba empleará análisis d e riesgo para determinar d ó n d e enfocar los e s f u e r z o s de prueba. Los análisis d e riesgo debe incluir consideración de c u á n t o coincidirá el ambiente d e prueba con el ambiente d e producción real... Otras consideraciones típicas en el análisis d e riesgo incluyen.

• ¿Cuál f u n c i o n a l i d a d e n el sitio W e b e s m á s crucial p a r a su p r o p ó s i t o ? • ¿Cuáles á r e a s del sitio r e q u i e r e n la m á s d u r a i n t e r a c c i ó n c o n la b a s e de d a t o s ? • ¿Cuáles a s p e c t o s d e los CGI, a p p l e t s , c o m p o n e n t e s ActiveX, etc., del sitio s o n los m á s c o m p l e j o s ? • ¿ Q u é tipos d e p r o b l e m a s c a u s a r í a la m a y o r í a d e las q u e j a s o la p e o r publicidad? • ¿ Q u é á r e a s del sitio s e r á n l a s m á s p o p u l a r e s ? • ¿ Q u é a s p e c t o s del sitio t i e n e n los m a y o r e s r i e s g o s d e s e g u r i d a d ? C a d a u n o d e los a s u n t o s r e l a c i o n a d o s c o n el r i e s g o q u e e x a m i n a H o w e r d e b e n c o n siderarse c u a n d o se diseñen c a s o s de prueba para c o m p o n e n t e s WebApp y funcion e s de bases de datos relacionadas.

20.6

P R U E B A S HE N A V E G A C I Ó N Un u s u a r i o viaja a t r a v é s d e u n a W e b A p p e n g r a n m e d i d a c o m o lo h a c e u n visitante al c a m i n a r por u n a t i e n d a o u n m u s e o . Existen m u c h a s r u t a s q u e s e p u e d e n t o m a r , m u c h a s p a r a d a s q u e s e p u e d e n realizar, m u c h a s c o s a s q u e a p r e n d e r y ver, actividades por iniciar y d e c i s i o n e s p o r t o m a r . C o m o y a s e h a c o m e n t a d o , e s t e p r o c e s o d e n a v e g a c i ó n e s p r e d e c i b l e e n el s e n t i d o e n q u e t o d o v i s i t a n t e t i e n e u n c o n j u n t o d e objetiv o s c u a n d o llega. Al m i s m o tiempo, el p r o c e s o de n a v e g a c i ó n p u e d e ser impredecible p o r q u e el visitante, influido p o r a l g o q u e ve o a p r e n d e , p u e d e elegir u n a ruta o iniciar u n a a c c i ó n q u e n o e s típica p a r a el o b j e t i v o original. El t r a b a j o d e p r o b a r la n a v e g a ción e s 1) g a r a n t i z a r q u e t o d o s los m e c a n i s m o s q u e p e r m i t e n al u s u a r i o d e la W e b App v i a j a r a t r a v é s d e ella s o n f u n c i o n a l e s , y 2) validar q u e c a d a u n i d a d s e m á n t i c a d e n a v e g a c i ó n (USN) p u e d a ser a l c a n z a d a p o r la c a t e g o r í a de u s u a r i o a d e c u a d a .

TM "No estamos perdidos. E n f r e n t a m o s un reto d e ubicación."

John M . Ford

PDF Editor 20.6.1 Prueba de la sintaxis d e navegación

La p r i m e r a f a s e d e la p r u e b a d e n a v e g a c i ó n e n r e a l i d a d c o m i e n z a d u r a n t e la p r u e b a

d e la i n t e r f a z . Los m e c a n i s m o s d e n a v e g a c i ó n s e p r u e b a n p a r a a s e g u r a r q u e c a d a

626

PARTE TRES


u n o realiza la función q u e s e busca. Splaine y Jaskiel [SPL01] sugieren q u e s e d p r o b a r c a d a u n o d e los m e c a n i s m o s d e n a v e g a c i ó n siguientes: • Vínculos de navegación.

Se d e b e n p r o b a r los vínculos i n t e r n o s d e n t r o d e la

WebApp, los vínculos e x t e r n o s hacia o t r a s WebApps y las a n c l a s d e n t r o de u n a p á g i n a Web específica p a r a g a r a n t i z a r q u e s e a l c a n z a r á n el c o n t e n i d o o la funcionalidad a d e c u a d o s c u a n d o el vínculo s e elija. • Redirigir. Dichos vínculos e n t r a n e n j u e g o c u a n d o un u s u a r i o solicita u n a URL inexistente o selecciona un vínculo c u y o d e s t i n o s e h a r e m o v i d o o c u y o nomb r e ha c a m b i a d o . Se despliega un m e n s a j e al u s u a r i o y la n a v e g a c i ó n s e redirige hacia otra página (por ejemplo, la p á g i n a d e inicio). La redirección se d e b e p r o b a r al solicitar vínculos i n t e r n o s incorrectos o URL e x t e r n a s y valora: c ó m o m a n e j a la WebApp d i c h a s solicitudes. • Bookmarks.

Aunque los b o o k m a r k s s o n f u n c i ó n del n a v e g a d o r , s e d e b e pro-

bar la WebApp p a r a a s e g u r a r q u e s e p u e d e e x t r a e r un título d e página significativo c u a n d o s e cree el b o o k m a r k . • Marcos y conjuntos

de marcos. Cada m a r c o c o n t i e n e el c o n t e n i d o d e u n a págj-

na Web específica; un c o n j u n t o d e m a r c o s c o n t i e n e múltiples m a r c o s y perm te el despliegue d e múltiples p á g i n a s Web al m i s m o tiempo. Puesto q u e e s posible a n i d a r m a r c o s y c o n j u n t o s d e m a r c o s u n o d e n t r o d e otro, s e d e b e n p r o b a r dichos m e c a n i s m o s d e n a v e g a c i ó n y despliegue para un c o n t e n i d o correcto, plantilla y t a m a ñ o a d e c u a d o s , d e s e m p e ñ o d e d e s c a r g a y compatibilidad de navegador. • Mapas de sitio. Las e n t r a d a s s e d e b e n p r o b a r p a r a g a r a n t i z a r q u e el vínculo lleva al u s u a r i o hacia el c o n t e n i d o o la funcionalidad a d e c u a d o s . • Motores de búsqueda

internos. Las WebApps c o m p l e j a s u s u a l m e n t e c o n t i e n e r

c i e n t o s o incluso miles d e o b j e t o s d e c o n t e n i d o . Un m o t o r d e b ú s q u e d a intern o p e r m i t e al u s u a r i o realizar u n a b ú s q u e d a por palabra clave d e n t r o de la WebApp para e n c o n t r a r el c o n t e n i d o n e c e s a r i o . La p r u e b a del m o t o r d e búsq u e d a valida la precisión y q u é t a n completa e s la b ú s q u e d a , las propiedades d e m a n e j o d e e r r o r e s del m o t o r d e b ú s q u e d a y las características d e búsqueca a v a n z a d a (por ejemplo, el u s o d e o p e r a d o r e s b o o l e a n o s e n el c a m p o d e búsqueda). Algunas d e e s t a s p r u e b a s p u e d e n desarrollarse m e d i a n t e h e r r a m i e n t a s a u t o m a t i z a - ] TM d a s (por e j e m p l o , verificador d e vínculos), m i e n t r a s q u e o t r a s s e d i s e ñ a n y ejecutan d e m a n e r a m a n u a l . La finalidad de to do esto e s a s e g u r a r q u e los e r r o r e s en las me-

PDF Editor

c á n i c a s d e n a v e g a c i ó n s e e n c u e n t r e n a n t e s d e q u e la WebApp esté en línea.

20.6.2 Prueba de la semántica de navegación

En el capítulo 19 s e definió u n a unidad s e m á n t i c a d e n a v e g a c i ó n (USN) c o m o

un

c o n j u n t o d e e s t r u c t u r a s d e i n f o r m a c i ó n y n a v e g a c i ó n r e l a c i o n a d a s q u e c o l a b o r a n en

CAPÍTULO 20


627

el c u m p l i m i e n t o d e un s u b c o n j u n t o d e requisitos d e u s u a r i o relacionados" [CAC02]. Cada USN s e define m e d i a n t e un c o n j u n t o d e r u t a s d e n a v e g a c i ó n (llamadas " f o r m a s d e navegar") que conectan n o d o s de navegación (por ejemplo, páginas Web, objetos d e c o n t e n i d o o funcionalidad). T o m a d a c o m o un todo, c a d a USN p e r m i t e al u s u a r i o lograr requisitos específicos definidos por m e d i o de u n o o m á s c a s o s d e u s o para u n a categoría d e usuario. La p r u e b a de n a v e g a c i ó n ejercita c a d a USN p a r a a s e g u r a r q u e dichos requisitos s o n asequibles. C o n f o r m e s e p r u e b a c a d a USN, el e q u i p o d e ingeniería Web d e b e r e s p o n d e r las siguientes preguntas: • ¿La USN s e logra en su totalidad sin error? • ¿Todo n o d o d e navegación (definido para u n a USN) e s asequible d e n t r o del c o n t e x t o d e las rutas d e n a v e g a c i ó n q u e define la USN? • Si la USN p u e d e a l c a n z a r s e e m p l e a n d o m á s d e u n a ruta d e n a v e g a c i ó n , ¿se ha p r o b a d o c a d a ruta relevante? • Si la interfaz del u s u a r i o proporciona u n a guía p a r a a y u d a r en la n a v e g a c i ó n , ¿las direcciones s o n c o r r e c t a s y c o m p r e n s i b l e s c o n f o r m e s e realiza la n a v e g a ción? • ¿Existe un m e c a n i s m o (distinto a la flecha "retroceso" del n a v e g a d o r ) p a r a reg r e s a r al n o d o d e navegación p r e c e d e n t e y hacia el c o m i e n z o d e la ruta d e navegación? • ¿Los m e c a n i s m o s d e n a v e g a c i ó n d e n t r o d e un gran n o d o d e n a v e g a c i ó n (es decir, u n a gran página Web) f u n c i o n a n a d e c u a d a m e n t e ? • Si u n a función s e ha de ejecutar en un n o d o y el u s u a r i o elige n o p r o p o r c i o n a r e n t r a d a , ¿se p u e d e c o m p l e t a r el resto d e la USN? • Si u n a función s e e j e c u t a en un n o d o y o c u r r e un error en el p r o c e s a m i e n t o d e la función, ¿se p u e d e c o m p l e t a r la USN? • ¿Existe u n a f o r m a para d e s c o n t i n u a r la n a v e g a c i ó n a n t e s d e q u e s e h a y a n alc a n z a d o t o d o s los nodos, p e r o e n t o n c e s r e g r e s a r a d o n d e s e d e s c o n t i n u ó la n a v e g a c i ó n y proceder d e s d e ahí? • ¿Todo n o d o s e a l c a n z a d e s d e el m a p a d e sitio? ¿Los n o m b r e s d e los n o d o s s o n significativos p a r a los u s u a r i o s finales? • Si un n o d o d e n t r o d e u n a USN s e a l c a n z a d e s d e a l g u n a f u e n t e TM externa, ¿es posible p r o c e d e r hacia el siguiente n o d o en la ruta d e n a v e g a c i ó n ? ¿Es posible regresar al n o d o previo en la ruta d e n a v e g a c i ó n ?

PDF Editor

• ¿El u s u a r i o e n t i e n d e su ubicación d e n t r o d e la arquitectura d e c o n t e n i d o c o n f o r m e s e ejecuta la USN?

La p r u e b a de n a v e g a c i ó n , c o m o las p r u e b a s d e la interfaz y facilidad d e uso, se

d e b e dirigir en t a n t o s participantes d i f e r e n t e s c o m o s e a posible. Las p r i m e r a s e t a p a s

628

PARTE TRES


de l a s p r u e b a s las dirigen los i n g e n i e r o s Web, p e r o e t a p a s u l t e r i o r e s l a s d e b e n n a v e g a c i ó n d e la W e b A p p .

20.7

P R U E B A DE LA C O N F I G U P A C I Ó M La variabilidad y la i n e s t a b i l i d a d d e la c o n f i g u r a c i ó n s o n f a c t o r e s i m p o r t a n t e s qjtffl h a c e n d e la i n g e n i e r í a W e b u n d e s a f í o . H a r d w a r e , s i s t e m a s o p e r a t i v o s , n a v e g a d o r e s ,1 c a p a c i d a d d e a l m a c e n a m i e n t o , r a p i d e z d e c o m u n i c a c i ó n d e la red y u n a d i v e r s i d a J d e o t r o s f a c t o r e s del l a d o del cl i ente s o n difíciles de p r e d e c i r p a r a c a d a u s u a r i o . A ó e J m á s , la c o n f i g u r a c i ó n p a r a u n u s u a r i o d a d o p u e d e c a m b i a r (por e j e m p l o , a c t u a l i zJ c i o n e s d e s i s t e m a o p e r a t i v o , n u e v o ISP y r a p i d e z d e c o n e x i ó n ) c o n r e g u l a r i d a d . El i e - J s u l t a d o p u e d e ser, e n el l a d o del cliente, u n a m b i e n t e proclive a e r r o r e s , t a n t o su J l e s c o m o significativos. La i m p r e s i ó n q u e u n u s u a r i o t e n g a d e la W e b A p p y la f o n - a l e n la q u e i n t e r a c t ú a c o n ella p u e d e diferir s i g n i f i c a t i v a m e n t e d e la e x p e r i e n c i a J o t r o u s u a r i o , si a m b o s n o t r a b a j a n d e n t r o d e la m i s m a c o n f i g u r a c i ó n d e l l a d o G J cliente. La l a b o r d e p r o b a r la c o n f i g u r a c i ó n n o e s e j e r c i t a r toda p o s i b l e c o n f i g u r a c i ó n « a l a d o del cliente. M á s bien, e s p r o b a r u n c o n j u n t o de p r o b a b l e s c o n f i g u r a c i o n e s d e I l a d o s del cl i ente y del s e r v i d o r p a r a g a r a n t i z a r q u e la e x p e r i e n c i a del u s u a r i o s e r á a l m i s m a e n t o d o s ellos y p a r a aislar e r r o r e s q u e p u e d a n s e r e s p e c í f i c o s d e u n a c o n ñ - 1 g u r a c i ó n particular.

20.7.1 Conflictos en el lado del servidor En el l a d o del servidor, los c a s o s d e p r u e b a d e c o n f i g u r a c i ó n s e d i s e ñ a n p a r a v e r i l e a r q u e la c o n f i g u r a c i ó n d e s e r v i d o r p r o y e c t a d a (es decir: s e r v i d o r WebApp, servid cr d e b a s e d e d a t o s , s i s t e m a s o p e r a t i v o s , s o f t w a r e c o r t a f u e g o s , a p l i c a c i o n e s concurrentes) p u e d e n s o p o r t a r la W e b A p p sin error. En e s e n c i a , la W e b A p p s e instala dentro del a m b i e n t e del l a d o del s e r v i d o r y s e p r u e b a c o n la i n t e n c i ó n d e e n c o n t r a r error e s r e l a c i o n a d o s c o n la c o n f i g u r a c i ó n . C o n f o r m e s e d i s e ñ a n la p r u e b a s d e c o n f i g u r a c i ó n del l a d o del servidor, el ingen i e r o W e b d e b e c o n s i d e r a r c a d a c o m p o n e n t e d e la c o n f i g u r a c i ó n del servidor. Entre las p r e g u n t a s q u e e s p r e c i s o p l a n t e a r y r e s p o n d e r d u r a n t e la p r u e b a d e configura¿ Q u é pre• g u n t a s se deben plantear y responder conforme se lleva a cabo la prueba de configuración en el lado del servidor?

ción del l a d o del s e r v i d o r s e e n c u e n t r a n :

TM

• ¿La W e b A p p e s t o t a l m e n t e c o m p a t i b l e c o n el s i s t e m a o p e r a t i v o del servidor? • ¿Los a r c h i v o s d e s i s t e m a , d i r e c t o r i o s y d a t o s d e s i s t e m a r e l a c i o n a d o s s e c r e a r

PDF Editor c o r r e c t a m e n t e c u a n d o la W e b A p p e s o p e r a t i v a ?

• ¿Las m e d i d a s d e s e g u r i d a d del s i s t e m a (por e j e m p l o , c o r t a f u e g o s o e n c r i p t a do) p e r m i t e n a la W e b A p p e j e c u t a r s e y d a r servicio a l o s u s u a r i o s sin interfer e n c i a o m e n o s c a b o del d e s e m p e ñ o ?

1

CAPÍTULO 20

629

C Ó M O P R O B A R A P L I C A C I O N E S 'ATE

• ¿La WebApp s e ha p r o b a d o c o n la configuración d e servidor distribuido 1 5 (si existe u n o ) q u e s e h a y a elegido? • ¿La WebApp e s t á a d e c u a d a m e n t e integrada con s o f t w a r e de b a s e d e datos? ¿La WebApp e s sensible a d i f e r e n t e s v e r s i o n e s del s o f t w a r e d e b a s e d e datos? • ¿Los g u i o n e s d e la WebApp en el lado del servidor s e ejecutan a d e c u a d a m e n t e ? • ¿Los e r r o r e s del a d m i n i s t r a d o r del s i s t e m a s e h a n e x a m i n a d o p a r a ver su efecto s o b r e las o p e r a c i o n e s d e la WebApp? • Si s e u s a n servidores proxy, ¿las diferencias en s u s c o n f i g u r a c i o n e s se h a n a b o r d a d o c o n p r u e b a s e n el sitio?

20.7.2 Conflictos en el lado del cliente En el lado del cliente las p r u e b a s d e configuración s e c e n t r a n principalmente en la compatibilidad d e la WebApp c o n las c o n f i g u r a c i o n e s q u e c o n t i e n e n u n a o m á s p e r m u t a c i o n e s de los s i g u i e n t e s c o m p o n e n t e s [NGU01]: • Hardware. CPU, m e m o r i a , a l m a c e n a m i e n t o y dispositivos de impresión. • Sistemas operativos.

Linux, Macintosh, Microsoft Windows, un sistema operati-

v o c o n b a s e móvil. • Software de navegación.

Internet Explorer, Mozilia/Netscape, Opera, Safari y

otros. • Componentes

de la interfaz del usuario. ActiveX, a p p l e t s Java y otros.

• Plug-ins. QuickTime, RealPlayer y m u c h o s otros. • Conectividad.

Cable, DSL, m ó d e m regular, TI.

A d e m á s d e e s t o s c o m p o n e n t e s , o t r a s variables incluyen el s o f t w a r e d e red, las variaciones del ISP y aplicaciones q u e c o r r e n al m i s m o tiempo. Al d i s e ñ a r p r u e b a s d e configuración en el l a d o del cliente el equipo d e ingeniería Web debe reducir el n ú m e r o d e variables d e configuración hacia un n ú m e r o m a n e jable. 1 6 Por tanto, s e valora c a d a categoría d e u s u a r i o p a r a d e t e r m i n a r las p r o b a b l e s c o n f i g u r a c i o n e s q u e s e e n c o n t r a r á n d e n t r o d e la categoría. A d e m á s , s e p u e d e n utilizar los d a t o s c o m p a r t i d o s en el m e r c a d o industrial para predecir las c o m b i n a c i o n e s m á s p r o b a b l e s d e c o m p o n e n t e s . Entonces la WebApp se p r u e b a d e n t r o d e e s t o s ambientes.

TM

PDF Editor

15 Por ejemplo, s e puede usar un servidor de aplicación y uno de base de datos por separado. La comunicación entre las dos máquinas ocurre por medio de una conexión de red. 16 Ejecutar pruebas en toda posible combinación de componentes de configuración consume demasiado tiempo.

630

PARTE TRES

2Q.8

A P L I C A C I Ó N DE L A I N G E N I E R Í A W E B

PRUEBAS PE SE<5VRIPAP La s e g u r i d a d d e l a s W e b A p p s e s u n a m a t e r i a c o m p l e j a q u e d e b e e n t e n d e r s e c o m p l e t o a n t e s de q u e s e p u e d a lograr u n a p r u e b a de s e g u r i d a d efectiva. 1 7 Las V. A p p s y los a m b i e n t e s e n el l a d o del c l i e n t e y e n el l a d o del s e r v i d o r e n los q u e i h o s p e d a d a s r e p r e s e n t a n u n b l a n c o a t r a c t i v o p a r a hackers,

empleados desconterd

competidores deshonestos y cualquiera otro que desee robar información ser m o d i f i c a r c o n t e n i d o m a l i c i o s a m e n t e , d i s m i n u i r el d e s e m p e ñ o , d e s h a b i l i t a r la f u r a nalidad o poner en apuros a u n a persona, organización o negocio. "El Internet es un fugar riesgoso poro llevar a tobo negocios o almacenar activos. Hackers, crackers, snoops, spoofers,.. ladrones, vándalos, lanzadores d e virus y proveedores de programas delictivos se pasean libremente Dorothy y P e t e r D e n á g Las p r u e b a s d e s e g u r i d a d e s t á n d i s e ñ a d a s p a r a p r o b a r l a s v u l n e r a b i l i d a d e s en a m b i e n t e del l a d o del cliente, las c o m u n i c a c i o n e s d e red q u e o c u r r e n m i e n t r a s i J d a t o s p a s a n del cl i ente al s e r v i d o r y d e vuelta, y el a m b i e n t e del l a d o del serví C a d a u n o d e e s t o s d o m i n i o s p u e d e recibir a t a q u e s , y e s l a b o r d e q u i e n p r u e b a la s e l g u r i d a d d e s c u b r i r las d e b i l i d a d e s q u e p u e d e n e x p l o t a r q u i e n e s t e n g a n la i n t e n o H de hacerlo. En el l a d o del cliente, l a s v u l n e r a b i l i d a d e s c o n f r e c u e n c i a s e p u e d e n r a s t r e a r h a s l t a e r r o r e s p r e e x i s t e n t e s e n los n a v e g a d o r e s , p r o g r a m a s d e c o r r e o e l e c t r ó n i c o o s e n ^CONSEJO^

w a r e d e c o m u n i c a c i ó n . Nguyen [NGU01] d e s c r i b e u n h o y o d e s e g u r i d a d típico: Uno de los errores mencionados comúnmente es el desbordamiento del buffer. Esto per-

Silo WebApp es crucial en el negocio, conservo datos sensibles o es un probable blanco de hackers, es bueno idea subcontratar las pruebas de seguridad con una empresa especializado en esto labor.

mite que un código malicioso se ejecute en la máquina cliente. Por ejemplo, al ingresar una URL en un navegador que es mucho mayor que el tamaño del buffer alocado para la URL provocará un error de sobreescritura de memoria (desbordamiento de buffer) si el navegador no tiene código de detección de error para validar la longitud de la URL ingresada. Un hacker estacional puede explotar astutamente este bug al escribir una URL grande con código ejecutable que puede provocar que el navegador reviente o altere las opciones de seguridad (de mayor a menor) o, peor aún, corrompa los datos del usuario. O t r a v u l n e r a b i l i d a d p o t e n c i a l e n el l a d o del cliente e s el a c c e s o n o a u t o r i z a d e • c o o k i e s c o l o c a d a s d e n t r o del n a v e g a d o r . Los sitios W e b c r e a d o s c o n i n t e n c i o n e s m a l i c i o s a s p u e d e n a d q u i r i r i n f o r m a c i ó n c o n t e n i d a d e n t r o d e c o o k i e s l e g í t i m a s y usar e s t a i n f o r m a c i ó n e n f o r m a s q u e p o n e n e n j u e g o la p r i v a c i d a d delTM u s u a r i o , o peor, est a b l e c e n el e s c e n a r i o p a r a el r o b o d e i d e n t i d a d . Los d a t o s c o m u n i c a d o s e n t r e el cliente y el s e r v i d o r s o n v u l n e r a b l e s a la simula-

PDF Editor ción (spoofirtg).

Ésta o c u r r e c u a n d o u n e x t r e m o d e la r u t a d e c o m u n i c a c i ó n lo sub-

17 Los libros de Trivedi [TRE03], McClure y sus colegas [MCC03] y Garfinkel y Spafford [GAR02] ofrecen información útil acerca del tema.

CAPÍTULO 20

631


vierte u n a e n t i d a d c o n i n t e n c i o n e s maliciosas. Por e j e m p l o , a u n u s u a r i o p u e d e e n g a ñarlo u n sitio W e b malicioso q u e a c t ú a c o m o si f u e s e el legítimo servidor d e la WebApp ( i d é n t i c o s e n a p a r i e n c i a y p e r c e p c i ó n ) . La i n t e n c i ó n e s r o b a r c o n t r a s e ñ a s , inform a c i ó n d e p r o p i e d a d o d a t o s de crédito. En el l a d o del servidor, l a s v u l n e r a b i l i d a d e s incluyen a t a q u e s d e n e g a c i ó n de s e r vicio y g u i o n e s m a l i c i o s o s q u e p u e d e n p a s a r al l a d o d e l cliente o e m p l e a d o s p a r a d e s h a b i l i t a r l a s o p e r a c i o n e s d e l servidor. A d e m á s , s e p u e d e t e n e r a c c e s o , sin a u t o r i z a c i ó n , a b a s e s d e d a t o s e n el l a d o del s e r v i d o r (robo d e d a t o s ) . La p r o t e c c i ó n c o n t r a é s t a s (y m u c h a s otras) v u l n e r a b i l i d a d e s r e q u i e r e i m p l e m e n tar u n o o m á s d e los s i g u i e n t e s e l e m e n t o s d e s e g u r i d a d [NGU01J: • C o r t a f u e g o s : m e c a n i s m o d e filtrado — c o m b i n a c i ó n d e h a r d w a r e y s o f t w a r e —

IVE s de segurii estar dise5 s o ejercitar s , autentifi! «criptodo y

q u e e x a m i n a c a d a p a q u e t e d e i n f o r m a c i ó n e n t r a n t e p a r a g a r a n t i z a r q u e llega d e u n a f u e n t e legítima y b l o q u e a c u a l q u i e r d a t o s o s p e c h o s o . • A u t e n t i f i c a c i ó n : m e c a n i s m o d e verificación q u e v a l i d a la i d e n t i d a d d e t o d o s los c l i e n t e s y s e r v i d o r e s , y p e r m i t e q u e l a c o m u n i c a c i ó n o c u r r a s ó l o c u a n d o a m b o s lados son verificados. • E n c r i p t a d o : m e c a n i s m o d e c o d i f i c a c i ó n q u e p r o t e g e los d a t o s s e n s i b l e s m e d i a n t e s u m o d i f i c a c i ó n e n u n a f o r m a q u e imposibilita la lectura d e q u i e n e s t e n g a n i n t e n c i o n e s m a l i c i o s a s . El e n c r i p t a d o s e f o r t a l e c e e m p l e a n d o certificad o s digitales q u e p e r m i t e n al cl i ente verificar el d e s t i n o al c u a l se t r a n s m i t e n los d a t o s . • A u t o r i z a c i ó n : m e c a n i s m o d e filtrado q u e p e r m i t e el a c c e s o al a m b i e n t e del c liente o el s e r v i d o r s ó l o a a q u e l l o s i n d i v i d u o s c o n c ó d i g o s d e a u t o r i z a c i ó n a p r o p i a d o s (por e j e m p l o , identificación del u s u a r i o y c o n t r a s e ñ a ) . La finalidad d e l a s p r u e b a s d e s e g u r i d a d e s e x p o n e r los h o y o s e n d i c h o s e l e m e n t o s d e s e g u r i d a d q u e p o d r í a n e x p l o t a r q u i e n e s t e n g a n i n t e n c i o n e s m a l i c i o s a s . El dis e ñ o a c t u a l de las p r u e b a s d e s e g u r i d a d r e q u i e r e u n c o n o c i m i e n t o p r o f u n d o d e los trabajos internos de cada e l e m e n t o de seguridad, así c o m o una extensa c o m p r e n sión d e u n a m p l i o r a n g o d e t e c n o l o g í a s d e red. En m u c h o s c a s o s , l a s p r u e b a s d e s e g u r i d a d s e s u b c o n t r a t a n c o n firmas q u e s e e s p e c i a l i z a n e n d i c h a s t e c n o l o g í a s .

Nada es m á s frustrante que u n a WebApp que tarda m i n u t o s e n cargar contenido

TM

c u a n d o los sitios d e la c o m p e t e n c i a d e s c a r g a n c o n t e n i d o similar e n s e g u n d o s . N a d a e s m á s a g r a v i a n t e q u e el i n t e n t o d e e n t r a r e n u n a W e b A p p y recibir u n m e n s a j e d e

PDF Editor

"servidor o c u p a d o " , q u e s e a c o m p a ñ a c o n la s u g e r e n c i a de i n t e n t a r l o m á s t a r d e . Nad a e s m á s d e s c o n c e r t a n t e q u e u n a W e b A p p q u e r e s p o n d e i n s t a n t á n e a m e n t e e n alg u n a s s i t u a c i o n e s , y luego, e n o t r a s o c a s i o n e s , p a r e c e irse a u n e s t a d o d e e s p e r a infinita. T o d o s e s t o s h e c h o s s u c e d e n e n la W e b t o d o s los días, y t o d o s e s t á n relacion a d o s c o n el d e s e m p e ñ o .

632

PARTE TRES


Las p r u e b a s del d e s e m p e ñ o s e aplican p a r a descubrir p r o b l e m a s de d e s e m p e ñ o que s e p r e s e n t a n debido a falta d e r e c u r s o s en el l a d o del servidor, a n c h o d e b a n d a de red inapropiado, c a p a c i d a d e s i n a d e c u a d a s d e b a s e d e datos, d e f e c t u o s a s o débiles c a p a c i d a d e s del sistema operativo, f u n c i o n a l i d a d WebApp mal d i s e ñ a d a y otros conflictos de h a r d w a r e o s o f t w a r e q u e p u e d e n conducir a un p o b r e d e s e m p e ñ o cliente-servidor. La finalidad e s doble: 1) c o m p r e n d e r c ó m o r e s p o n d e el sistema a la carga (es decir, n ú m e r o d e usuarios, n ú m e r o de t r a n s a c c i o n e s o v o l u m e n d e d a t o s global), y 2) recolectar m é t r i c a s q u e conducirán a modificaciones de diseño p a r a mejorar el d e s e m p e ñ o .

20.9.1 Objetivos de las pruebas del desempeño Las p r u e b a s del d e s e m p e ñ o s e d i s e ñ a n c o n el fin d e simular s i t u a c i o n e s d e carga de! m u n d o real. C o n f o r m e crece el n ú m e r o de u s u a r i o s s i m u l t á n e o s d e la WebApp, o au m e n t a el n ú m e r o de t r a n s a c c i o n e s en línea, o s e i n c r e m e n t a la cantidad d e d a t o s (descargados o cargados), las p r u e b a s de d e s e m p e ñ o a y u d a r á n a r e s p o n d e r las sig u i e n t e s preguntas: ÔNSEJOÂlgunos aspectos del desempeño de la WebApp, al menos como los peiciben los usuarios finales, son difíciles de probar, incluso lo cargo de red, las variaciones del hardware que establece uno interfaz con lo red y tópicos similores.

¿El tiempo de r e s p u e s t a del servidor se reduce h a s t a un p u n t o d o n d e e s apreciable e inaceptable? ¿En q u é p u n t o (en t é r m i n o s d e usuarios, t r a n s a c c i o n e s o carga d e datos) el d e s e m p e ñ o s e vuelve inaceptable? ¿Qué c o m p o n e n t e s del s i s t e m a s o n r e s p o n s a b l e s de la reducción del d e s e m peño? ¿Cuál e s el tiempo de respuesta p r o m e d i o p a r a los usuarios e n u n a variedad de c o n d i c i o n e s d e carga? ¿La reducción del d e s e m p e ñ o tiene i m p a c t o s o b r e la seguridad del sistema? ¿La confiabilidad o la precisión d e la WebApp s e afectan c o n f o r m e crece la carga del sistema? ¿Qué o c u r r e c u a n d o s e aplican c a r g a s que r e b a s a n la c a p a c i d a d m á x i m a del servidor? Para desarrollar r e s p u e s t a s a e s t a s preguntas, s e dirigen d o s p r u e b a s d e d e s e m p e ñ o diferentes:

TM • Prueba d e carga: la carga en el m u n d o real s e p r u e b a en u n a diversidad d e niveles d e carga y en u n a variedad d e c o m b i n a c i o n e s .

PDF Editor

• Prueba d e tensión: la carga se a u m e n t a hasta el p u n t o d e ruptura p a r a determ i n a r c u á n t a c a p a c i d a d p u e d e m a n e j a r el a m b i e n t e d e la WebApp.

Cada u n a d e e s t a s e s t r a t e g i a s d e p r u e b a s e c o n s i d e r a en las s e c c i o n e s siguientes.

CAPÍTULO 20


633

20.9.2 Pruebas de carga El objetivo de las p r u e b a s d e carga e s d e t e r m i n a r c ó m o la WebApp y su a m b i e n t e del lado del servidor r e s p o n d e r á n a varias c o n d i c i o n e s d e carga. C o n f o r m e p r o c e d e n las p r u e b a s , las p e r m u t a c i o n e s a las siguientes variables definen un c o n j u n t o d e condiciones d e p r u e b a : N , el n ú m e r o d e u s u a r i o s c o n c u r r e n t e s T , el n ú m e r o d e t r a n s a c c i o n e s en línea por u s u a r i o por u n i d a d de tiempo D, la carga d e d a t o s p r o c e s a d a por el servidor por t r a n s a c c i ó n En c a d a caso, e s t a s variables s e definen d e n t r o d e los límites o p e r a t i v o s n o r m a les del sistema. C o n f o r m e s e c o r r e c a d a condición de p r u e b a , s e recopilan u n a o m á s 3 utiliza ¡unidores reoja se t e n un f x muhiser-

d e las siguientes m e d i d a s : la r e s p u e s t a d e u s u a r i o promedio, el t i e m p o p r o m e d i o p a ra d e s c a r g a r u n a unidad d e d a t o s e s t a n d a r i z a d a o el tiempo p r o m e d i o para p r o c e s a r u n a transacción. El equipo de ingeniería Web e x a m i n a e s t a s m e d i d a s p a r a determinar si u n a disminución precipitada en el d e s e m p e ñ o s e p u e d e r a s t r e a r h a s t a u n a c o m b i n a c i ó n específica d e N , T y D . La p r u e b a de carga t a m b i é n s e aplica p a r a valorar la velocidad d e c o n e x i ó n recom e n d a d a p a r a los u s u a r i o s de la WebApp. La cantidad de información global p r o c e s a d a en u n a unidad d e tiempo, P, s e calcula d e la f o r m a siguiente: P = N x T x D C o m o ejemplo, c o n s i d é r e s e un popular sitio d e noticias deportivas. En u n m o m e n to d a d o , 20 000 usuarios c o n c u r r e n t e s realizan u n a solicitud (una transacción, T) u n a vez c a d a dos m i n u t o s en promedio. Cada transacción requiere q u e la WebApp descargue un n u e v o artículo q u e p r o m e d i a 3 Kbytes d e longitud. En c o n s e c u e n c i a , la cantidad de información p r o c e s a d a en u n a unidad de t i e m p o s e p u e d e calcular como: P = [20 000 x 0.5 X 3 K b ] / 6 0 = 500 K b y t e s / s e g = 4 m e g a b i t s por s e g u n d o Por lo tanto, la conexión d e red p a r a el servidor tendría que s o p o r t a r e s t a t a s a d e d a t o s y s e debería p r o b a r p a r a g a r a n t i z a r q u e la tiene.

20.9.3 Pruebas de tensión La p r u e b a de tensión (capítulo 13) e s u n a c o n t i n u a c i ó n d e la p r u e b a de carga, p e r o

kVE 3 de las •. y¡ tensión es r mejor cói sistema e se presiona t ie sus límites

en e s t a instancia las variables N, T y D s e f u e r z a n p a r a a l c a n z a r y luego s u p e r a r los límites operativos. La finalidad de e s t a s p r u e b a s e s r e s p o n d e r c a d aTM u n a d e las p r e g u n t a s siguientes: • ¿El s i s t e m a s e d e g r a d a "gentilmente" o el servidor s e d e s c o n e c t a c u a n d o s e

PDF Editor r e b a s a su c a p a c i d a d ?

• ¿El s o f t w a r e del servidor g e n e r a m e n s a j e s d e "servidor n o disponible"? De m a n e r a m á s general: ¿a los u s u a r i o s s e les advierte q u e n o p u e d e n a l c a n z a r el servidor?

634

PARTE TRES


• ¿El servidor p o n e en cola las solicitudes de recursos y vacía la cola u n a vez q u e la c a p a c i d a d d e m a n d a disminución? • ¿Las t r a n s a c c i o n e s se pierden c o n f o r m e se r e b a s a la capacidad? • ¿La integridad de los datos se afecta c u a n d o se rebasa la capacidad? • ¿Qué valores de N, Ty D f u e r z a n el fallo del a m b i e n t e del servidor? ¿Cómo se manifiesta la falla en sí m i s m a ? ¿Las notificaciones a u t o m á t i c a s se envían al e q u i p o de soporte técnico en el sitio del servidor? • Si el sistema falla, ¿ c u á n t o tardará en e s t a r en línea de nuevo? • ¿Ciertas f u n c i o n e s de la WebApp (por ejemplo, calcular funcionalidad inte c a p a c i d a d e s de flujo de datos) se d e s c o n t i n ú a n c u a n d o la capacidad alcanza el nivel de 80 o 90 por ciento? A una variación de la prueba de tensión a veces se le refiere c o m o prueba rebote [SPLOI ]. En este régimen de p r u e b a s la carga se lleva h a s t a su p u n t o m á r : de capacidad, luego se baja r á p i d a m e n t e h a s t a condiciones de o p e r a c i ó n n o r m y luego se s u b e de n u e v o al pico. Al rebotar la carga del sistema un e x a m i n a d o r de d e t e r m i n a r c u á n bien el servidor p u e d e p o n e r en orden los recursos p a r a sati cer la d e m a n d a muy elevada y luego liberarlos c u a n d o r e a p a r e c e n las condici n o r m a l e s (de m o d o q u e e s t é n listas p a r a el siguiente pico). HERRAMIENTAS DE SOFTWARE

Taxonomía de herramientas para pruebas de WebApp En su artículo acerca de la prueba de los sistemas de comercio electrónico, Lam [LAM01 ] presenta una útil taxonomía de las herramientas automatiz a d a s que tienen aplicabilidad directa en la realización de pruebas en un contexto de ingeniería Web. En cada categoría se indican herramientas representativas. 18

Las herramientas de configuración y de gestión d e l c o n t e n i d o gestionan la versión y cambian el control de los objetos de contenido y de los componentes funcionales de la WebApp. Herramienlalsl representativa(sl: En www.daveeaton.com/scm/CMTools.html se encuentra una extensa lista.

Las herramientas de desempeño de bases de d a t o s miden, por ejemplo, el tiempo para realizar consultas a boses de datos seleccionadas. Estas herramientas facilitan el mejoramiento de la base de datos.

Herramienta(s) representativas(s): BMC Software (www.bmc.com) Los programas depuradores (debuggers) son herramientas de programación comunes que encuentran y resuelven defectos de software en el código. Forman parte de la mayoría de los ambientes modernos de desarrollo de aplicaciones. Herramienlalsl representah'va(s): Accelerated Technology (www.acceleratedtechnology.com IBM VisualAge Environment (www.ibm.com) JDebug Tool (www.debugtools.com)

Los sistemas de gestión de defectos registran los defectos y rastrean su estatus y resolución. Algunos incluyen herramientas de reporte para ofrecer TMinformación de gestión acerca del defecto esparcido y las tasas de resolución de defectos.

PDF Editor V

Herramienlalsl representativa/s): EXCEL Quickbugs (www.excelsoftware.com)

18 Las herramientas expuestas aquí sólo representan una muestra de esta categoría. Además, los norr bres de las mismas son marcas registradas de las compañías mencionadas.

CAPÍTULO 2 0

635


TRUETrack (www.mccabe.com) ClearQuest (www.rational.com)

res y del software de servidores Web; vigilan los recursos ta les como el espacio de disco, el uso del CPU y la memoria.

a m i e n t a s d e s u p e r v i s i ó n d e r e d vigilan el tráfico de la red. Son útiles para identificar los ¡ de botella" de la red y probar los vínculos entre i de entrada y de salida. ienta(s¡ represenloliva(sj: .slac.stanford.edu/xorg/nmtf/nmtf-tools.html se una extensa lista. a m i e n t a s d e p r u e b a s d e r e g r e s i ó n ali casos y datos de prueba y se pueden volver a • oara casos de prueba después de cambios de softI sjcesivos. nienta(s) representativa(s): are QARun (www.compuware. producís/qacenter/qarun) VisualTest (www.rational.com) i Software (www.seque.com)

Herramienta(s) representativa(s): Successful Hosting.com (www.successfulhosting.com) Quest Software Foglight (www.quest.com) Las h e r r a m i e n t a s d e g e n e r a c i ó n d e d a t o s d e p r u e b a auxilian a los usuarios en dicha tarea. Herramienta(s¡ representativa(s): En www.softwareqatest.com/qatwebl.html se encuentra una extensa lista. Los c o m p a r a d o r e s d e r e s u l t a d o s d e p r u e b a s ayudan a comparar los resultados de un conjunto de pruebas con los de otro conjunto. Úsense para verificar que los cambios de código no han introducido cambios adversos en el comportamiento del sistema. Herramientals/ representativa(s): En www.aptest.com/resources.html se encuentra una lista útil.

i h e r r a m i e n t a s d e s u p e r v i s i ó n d e sitio vigilan eño de un sitio, usualmente desde una perspecti! usuario. Úsense para compilar estadísticas como el : de respuesta de extremo a extremo y la cantidad ación procesada en una unidad de tiempo, así i cara verificar periódicamente la disponibilidad de nienta(s) represenlaHva(s): ¡ Systems (www.keynote.com) i h e r r a m i e n t a s d e t e n s i ó n ayudan a los desarrot a explorar el comportamiento del sistema en coni de niveles elevados de uso operativo y a encon; puntos d e quiebre de un sistemo. nienta(s) representativa/s): 1 Interactive (www.merc-int.com) i Technologis (www.scapatech.com)

Los m o n i t o r e s d e t r a n s a c c i ó n miden el desempeño d e los sistemas de procesamiento de transacciones de alto volumen. Herramienta(s¡ representativa/si: QuotiumPro (www.quotium.com) Software Research eValid (www.soft.com/eValid/index.html) Las h e r r a m i e n t a s d e s e g u r i d a d d e sitios W e b ayudan a detectar potenciales problemas de seguridad. Con frecuencia pueden configurar herramientas de prueba y supervisión de la seguridad para que corran sobre una base calendarizada. Herramienta(s) representativa(s): En www.timberlinetechnologies.com/products/www.html se encuentra una extensa lista.

• s i s t e m a s d e s u p e r v i s i ó n d e r e c u r s o s son par! a mayoría de los sistemas operativos de los servido-

La m e t a d e p r o b a r l a s W e b A p p e s e j e r c i t a r c a d a u n a d e l a s m u c h a s d i m e n s i o n e s d e la c a l i d a d W e b A p p c o n la

finalidad

de encontrar errores o descubrir conflictos que

TM

p u d i e r a n c o n d u c i r a f a l l a s e n la c a l i d a d . L a s p r u e b a s s e c e n t r a n e n c o n t e n i d o , f u n ción, estructura, facilidad d e uso, navegabilidad, d e s e m p e ñ o , compatibilidad, intero-

PDF Editor

perabilidad, c a p a c i d a d y seguridad. Las p r u e b a s t a m b i é n i n c o r p o r a n revisiones q u e o c u r r e n c o n f o r m e s e d i s e ñ a la W e b A p p .

La e s t r a t e g i a d e p r u e b a d e la W e b A p p e j e r c i t a c a d a u n a d e l a s d i m e n s i o n e s d e c a -

lidad al e x a m i n a r inicialmente " u n i d a d e s " d e contenido, f u n c i o n a l i d a d o n a v e g a c i ó n . U n a v e z q u e l a s u n i d a d e s i n d i v i d u a l e s h a n s i d o v a l i d a d a s , el e n f o q u e s e c a m b i a a

PARTE TRES


p r u e b a s que ejerciten la WebApp c o m o un todo. Esto s e logra derivando m u c h a s prueb a s d e las perspectivas d e los u s u a r i o s y s e a l i m e n t a n c o n la información contenida en los c a s o s d e uso. Se desarrolla un plan d e p r u e b a d e ingeniería Web y s e identific a n los p a s o s d e prueba, los p r o d u c t o s de t r a b a j o (por ejemplo, c a s o s d e prueba) . los m e c a n i s m o s p a r a la evaluación d e los r e s u l t a d o s d e p r u e b a . El p r o c e s o d e prueba a b a r c a siete tipos diferentes de p r u e b a s . La p r u e b a del c o n t e n i d o (y las revisiones) s e c e n t r a en varias c a t e g o r í a s de contenido. La finalidad e s descubrir e r r o r e s t a n t o s e m á n t i c o s c o m o sintácticos q u e afecten la precisión del c o n t e n i d o o la f o r m a en la q u e se p r e s e n t a al u s u a r i o final. La p r u e b a de la interfaz ejercita los m e c a n i s m o s de interacción q u e p e r m i t e n q u e u s u a r i o s e c o m u n i q u e con la WebApp y valida los a s p e c t o s estéticos de la interfaz El objetivo e s descubrir e r r o r e s que resulten d e m e c a n i s m o s d e interacción mal irr.p l e m e n t a d o s , u omisiones, inconsistencias o a m b i g ü e d a d e s en la s e m á n t i c a d e la ir terfaz. La p r u e b a d e n a v e g a c i ó n aplica c a s o s d e uso, derivados c o m o p a r t e d e la activ. d a d de análisis, en el d i s e ñ o d e c a s o s d e p r u e b a q u e ejercitan c a d a u n o d e los escen a r i o s d e uso f r e n t e al d i s e ñ o de n a v e g a c i ó n . Los m e c a n i s m o s d e n a v e g a c i ó n s e p r u e b a n p a r a g a r a n t i z a r q u e s e identifican y corrigen los e r r o r e s q u e impiden e c o m p l e t a r un c a s o de uso. La p r u e b a de c o m p o n e n t e s ejercita las u n i d a d e s d e cont e n i d o y f u n c i o n a l e s d e n t r o de la WebApp. Cada p á g i n a Web e n c a p s u l a contenidc vínculos de n a v e g a c i ó n y e l e m e n t o s de p r o c e s a m i e n t o q u e f o r m a n u n a "unidad" dentro d e la arquitectura d e la WebApp. Se d e b e n p r o b a r d i c h a s u n i d a d e s . La p r u e b a d e configuración intenta descubrir ios e r r o r e s o los p r o b l e m a s de corr patibilidad específicos d e un a m b i e n t e particular d e cliente o servidor. E n t o n c e s s e llevan a c a b o p r u e b a s p a r a descubrir los e r r o r e s a s o c i a d o s c o n c a d a posible configuración. La p r u e b a de la s e g u r i d a d incorpora u n a serie d e p r u e b a s d i s e ñ a d a s para explotar las vulnerabilidades e n la WebApp y en su a m b i e n t e . La finalidad e s e n c o r trar h o y o s d e seguridad. La p r u e b a d e d e s e m p e ñ o a b a r c a u n a serie de p r u e b a s q u e s e diseñan p a r a valorar el tiempo d e r e s p u e s t a d e la WebApp y la confiabilidad cor f o r m e a u m e n t a la d e m a n d a en la c a p a c i d a d d e r e c u r s o s e n el l a d o del servidor.

[BROOI | Brown, B., Oracle9i Web Development, McGraw-Hill, 2a. ed„ 2001. [CAC02] Cachero, C. et al., "Conceptual Navigation Analysis: A Device and Platform Inde pendent Navigation Specification", Proc. 2nd Intl. Workshop on web-oriented technolog?. TM junio de 2002, se puede descargar de www.dsic.upv.es/~west/iwwost02/papers cachero.pdf [CON03J Constantine, L. y L, Lockwood, Software for Use, Addison-Wesley, 1999; veásr también http://www.foruse.com/. [GAR02] Garfinkel, S. y G. Spafford, Web Security, Prívacy and Commerce, O'Reilly & Asscciates, 2002. [HOW97] Hower, Rick, "Beyond Broken Links", Internet Systems, 1997, disponible er http://www.dbmsmag.com/9707i03.html. [LAMO 1 ] Lam, W„ "Testing E-Commerce Systems: A Practical Guide", en IEEE IT Pro, marzo-abril de 2001, pp. 19-28.

PDF Editor

CAPÍTULO 2 0

637

CÓMO PROBAR APiiCACICNtS WtS

[ M C C 0 3 | M c C I u r e , S., S. S h a h y S. S h a h . Web Hacking.

Attacks

and Defense,

Addison-Wes-

ley, 2 0 0 3 . |MIL00] Miller, E., " W e b S i t e T e s t i n g " , 2 0 0 0 , d i s p o n i b l e e n h t t p : / / w w w . s o f l . c o m / e V a l i d / T e c h n o l o g y / W h i t e . P a p e r s / w e b s i te. t e s t i n g . h t m l . [NGUOO] N g u y e n , H., " T e s t i n g W e b - B a s e d A p p l i c a t i o n s " , e n Software Testing and Quality Engineering, mayo-junio de 2000, disponible en h t t p : / / w w w . s t q e m a g a z i n e . c o m . [NGU0I1 N g u y e n , H., Testing Applications on the Web, Wiley, 2 0 0 1 . [SCE02] S c e p p a , D„ Microsoft ADO.NET, M i c r o s o f t P r e s s , 2 0 0 2 . [SPL01] S p l a i n e , S. y S. J a s k i e l , The Web Testing Handbook, STQE Publishing, 2001. [TRE03] T r i v e d i , R„ Professional Web Services Security, W r o x P r e s s , 2 0 0 3 . [WAL03] W a l l a c e , D., 1. R a g g e t t y J. A u f g a n g , Extreme Programmingfor Web Projects, A d d i son-Wesley, 2003.

2 0 . 1 . ¿Existen a l g u n a s s i t u a c i o n e s e n l a s c u a l e s l a s p r u e b a s d e la W e b A p p d e b a n i g n o r a r s e p o r completo? 20.2. Con a r g u m e n t o s p r o p i o s , c o m é n t e n s e l o s o b j e t i v o s d e la r e a l i z a c i ó n d e p r u e b a s e n el c o n t e x t o d e la i n g e n i e r í a Web. 2 0 . 3 . La c o m p a t i b i l i d a d e s u n a i m p o r t a n t e d i m e n s i ó n d e c a l i da d . ¿ Q u é d e b e p o n e r s e a p r u e b a p a r a garantizar que existe compatibilidad para una WebApp? 2 0 . 4 . ¿ Q u é e r r o r e s t i e n d e n a s e r m á s s e r i o s : l o s e r r o r e s del l a d o del c l i e n t e o los e r r o r e s del lad o del s e r v i d o r ? ¿Por q u é ? 20.5. ¿ Q u é e l e m e n t o s d e la W e b A p p p u e d e n " p r o b a r s e d e m a n e r a u n i t a r i a " ? ¿ Q u é tipos d e p r u e b a s s e d e b e n llevar a c a b o s ó l o d e s p u é s d e q u e e s t á n i n t e g r a d o s los e l e m e n t o s d e la W e b App? 20.6. ¿ S i e m p r e e s n e c e s a r i o d e s a r r o l l a r u n p l a n d e p r u e b a e s c r i t o d e m a n e r a f o r m a l ? Expliqúes e la r e s p u e s t a . 2 0 . 7 . ¿ E s j u s t o decir q u e la e s t r a t e g i a global d e p r u e b a s d e la W e b A p p c o m i e n z a c o n los e l e m e n t o s visibles p a r a el u s u a r i o y s e m u e v e h a c i a l o s e l e m e n t o s d e t e c n o l o g í a ? ¿Existen e x c e p ciones a esta estrategia? 20.8. ¿La p r u e b a del c o n t e n i d o realmente n o ? Explicar la r e s p u e s t a .

e s u n a p r u e b a e n el s e n t i d o c o n v e n c i o n a l del térmi-

20.9. Describir los p a s o s a s o c i a d o s c o n la p r u e b a d e l a s b a s e s d e d a t o s p a r a u n a W e b A p p . ¿La p r u e b a d e l a s b a s e s d e d a t o s e s u n a actividad p r e d o m i n a n t e m e n t e del l a d o del c l i e n t e o del lad o del s e r v i d o r ? 20.10. ¿Cuál e s la d i f e r e n c i a e n t r e l a s p r u e b a s q u e e s t á n a s o c i a d a s c o n los m e c a n i s m o s d e la i n t e r f a z y las p r u e b a s q u e a b o r d a n la s e m á n t i c a d e la i n t e r f a z ? 20.11. S u p o n e r q u e s e e s t á e n el desarrollo d e u n a f a r m a c i a e n línea (FarmaciadelaEsquina.com) q u e i n t e n t a s a t i s f a c e r l o s d e s e o s d e p a c i e n t e s g e r i á t r i c o s . La f a r m a c i a p r o p o r c i o n a las f u n c i o n e s u s u a l e s , p e r o t a m b i é n m a n t i e n e u n a b a s e d e d a t o s p a r a c a d a c l i e n t e TM de m o d o que p u e d e ofrecer información de m e d i c a m e n t o s y advertencias d e potenciales interacciones respecto d e m e d i c a m e n t o s . C o m e n t a r a l g u n a s p r u e b a s e s p e c i a l e s d e facilidad d e u s o p a r a e s t a W e b A p p .

PDF Editor

2 0 . 1 2 . S u p o n e r q u e s e ha i m p l e m e n t a d o u n a f u n c i ó n d e verificación d e i n t e r a c c i ó n d e m e d i c a m e n t o s p a r a F a r m a c i a d e l a E s q u i n a . c o m ( p r o b l e m a 20.11). E x a m i n e los tipos p r u e b a s al nivel d e c o m p o n e n t e q u e t e n d r í a n q u e llevarse a c a b o p a r a g a r a n t i z a r q u e e s t a f u n c i ó n t r a b a j a d e m a n e r a a d e c u a d a . [Nota: Se t e n d r í a q u e u s a r u n a b a s e d e d a t o s p a r a i m p l e m e n t a r e s t a función.)

638

PAETE TRES

APLICACIÓN DE LA INGENIERÍA W E B

2 0 . 1 3 . ¿Cuál e s la d i f e r e n c i a e n t r e p r o b a r la s i n t a x i s d e n a v e g a c i ó n y p r o b a r la s e m á n t i c a de navegación? 2 0 . 1 4 . ¿Es p o s i b l e p r o b a r c a d a c o n f i g u r a c i ó n q u e p r o b a b l e m e n t e e n c u e n t r e la W e b A p p en e. 1 l a d o del s e r v i d o r ? ¿En el lado del cliente? Si n o , ¿ c ó m o u n i n g e n i e r o W e b s e l e c c i o n a u n c o n j u r - J to s i g n i f i c a t i v o d e p r u e b a s d e c o n f i g u r a c i ó n ? 20.15. ¿Cuál e s el o b j e t i v o d e las p r u e b a s d e s e g u r i d a d ? ¿ Q u i é n lleva a c a b o e s t a actividad ¿ e \ prueba? 2 0 . 1 6 . F a r m a c i a d e l a E s q u i n a . c o m ( p r o b l e m a 20.11) s e ha v u e l t o e x i t o s a y el n ú m e r o d e USLÍ ] rios ha a u m e n t a d o d e m a n e r a significativa e n los p r i m e r o s d o s m e s e s d e o p e r a c i ó n . Dibuje i g ráfica q u e m u e s t r e el t i e m p o d e r e s p u e s t a p r o b a b l e c o m o f u n c i ó n del n ú m e r o d e u s u a r i o s i ra u n c o n j u n t o fijo d e r e c u r s o s e n el l a d o del servidor. Rotule la g r á f i c a p a r a indicar p u n t o s ; i n t e r é s e n la " c u r v a d e r e s p u e s t a " . 2 0 . 1 7 . En r e s p u e s t a a su éxito, F a r m a c i a d e l a E q u i n a . c o m ( p r o b l e m a 20.11) h a i m p l e m e n t i u n servicio e s p e c i a l e x c l u s i v a m e n t e p a r a m a n e j a r el r e s u r t i d o d e r e c e t a s . En p r o m e d i o , 1 u s u a r i o s c o n c u r r e n t e s giran u n a solicitud d e r e s u r t i d o u n a v e z c a d a d o s m i n u t o s . La Web d e s c a r g a u n b l o q u e d e d a t o s d e 5 0 0 b y t e s c o m o r e s p u e s t a . ¿Cuál e s la c a n t i d a d d e i n f o r m a c a p r o x i m a d a q u e s e n e c e s i t a p r o c e s a r p o r u n a u n i d a d d e t i e m p o p a r a e s t e servidor, en m e g a por s e g u n d o ? 2 0 . 1 8 . ¿Cuál e s la d i f e r e n c i a e n t r e p r u e b a d e c a r g a y p r u e b a d e t e n s i ó n ?

La literatura p a r a las p r u e b a s d e W e b A p p s t o d a v í a e s t á e n e v o l u c i ó n . Los libros d e Ash (The i Testing Companion, Wiley, 2003), D u s t i n y s u s c o l e g a s (Qualily Web Systems, A d d i s o n - W e 2002), N g u y e n [NGU01| y Splaine y Jaskiel (SPL01) s e e n c u e n t r a n e n t r e l o s q u e , p u b l i c a d o s I ta la f e c h a , p r e s e n t a n los t r a t a m i e n t o s m á s c o m p l e t o s del t e m a . M o s l e y (Client-Server! Testing on the Desklop and Ihe Web, Prentice-Hall, 1999) a b o r d a a s u n t o s d e p r u e b a t a n t o en • l a d o del cliente c o m o e n el lado del s e r v i d o r . S t o t t l e m e y e r (Aulomated Web Testing Toolkit, Wiley, 2001) p r e s e n t a i n f o r m a c i ó n útil a c e r c a : los m é t o d o s y e s t r a t e g i a s e n la p r u e b a d e l a s W e b A p p s , asi c o m o u n v a l i o s o a n á l i s i s d e las I r r a m i e n t a s d e p r u e b a a u t o m a t i z a d a s . G r a h a m y s u s c o l e g a s ( S o f t w a r e Test Aulomation, Addn Wesley, 1999) p r e s e n t a n m a t e r i a l a d i c i o n a l a c e r c a d e l a s h e r r a m i e n t a s a u t o m a t i z a d a s . Nguyen y s u s c o l e g a s (Testing Applications for the Web, s e g u n d a edición, Wiley, 2003) i r r o l l a r o n u n a g r a n a c t u a l i z a c i ó n [NGU01] y o f r e c e n u n a g u í a ú n i c a p a r a p r o b a r aplicacic m ó v i l e s . A u n q u e Microsoft ( P e r f o r m a n c e Testing Microsoft .NET Web Applications, Micr P r e s s , 2002) s e e n f o c a p r e d o m i n a n t e m e n t e e n su a m b i e n t e .NET, s u s c o m e n t a r i o s a c e r c a d e . p r u e b a s d e d e s e m p e ñ o p u e d e n s e r útiles p a r a c u a l q u i e r i n t e r e s a d o e n la m a t e r i a . S p l a i n e (Testing Web Security, Wiley, 2002), Klevinsky y s u s c o l e g a s (Hack I.T.: Through Penelration Testing, A d d i s o n - W e s l e y , 2002) , Chirillo (Hack Attacks Revealed, s e g e d i c i ó n , Wiley, 2003) y S k o u d i s {Counter Hack, Prentice-Hall, 2001) o f r e c e n m u c h a i n f o r m a útil p a r a q u i e n e s d e b e n d i s e ñ a r p r u e b a s d e s e g u r i d a d . En I n t e r n e t e s t á d i s p o n i b l e u n a g r a n v a r i e d a d d e f u e n t e s d e i n f o r m a c i ó n a c e r c a d e l a s | b a s p a r a i n g e n i e r í a Web. En el sitio Web d e SEPA s e e n c u e n t r a u n a lista a c t u a l i z a d a d e referí TM c i a s en la World Wide Web:

http://www.mhhe.com/pressman

PDF Editor

G E S T I Ó N DE PROYECTOS DE SOFTWARE

E

n esta parte de Ingeniería del software: un enfoque práctico se consideran las técnicas de gestión necesarias para planear, organizar, supervisar y controlar los proyectos de software. En los capítulos que siguen se abordan las siguientes preguntas: • ¿Cómo se deben gestionar el personal, el proceso y los problemas durante un proyecto de software? • ¿Cómo pueden emplearse las métricas de software para gestionar un proyecto de software y el respectivo proceso? • ¿Cómo se estiman el esfuerzo, el costo y la duración del proyecto? • ¿Qué técnicas pueden aplicarse para evaluar formalmente los riesgos que pueden incidir en el éxito del proyecto? • ¿Cómo selecciona un gestor de proyectos un conjunto de tareas de trabajo de ingeniería del software? • ¿Cómo se crea el programa cronológico de un proyecto? • ¿Qué es la gestión de calidad? • ¿Por qué son tan importantes las revisiones técnicas formaTM les? • ¿Cómo se gestionan los cambios durante el desarrollo del software de computadora y después de entregarlo al cliente?

PDF Editor

Una vez que se respondan estas preguntas se estará mejor preparado para gestionar proyectos de sortw are en una forma que conducirá a la entrega puntual de un producto de alta calidad. 639

C A P I T U L O ~

k.

2 1 L CONCEPTOS CLAVE ámbito del aftware

..651

coordinación . . . 6 S 0

C O N C E P T O S DE GESTIÓN DE PROYECTOS

E

n el prefacio de su libro acerca de la gestión de proyectos de software, Me» ler Page-Jones [PÁG85J h a c e una afirmación a la q u e p u e d e n s u m a r s e m u c h o s a s e s o r e s en ingeniería del s o f t w a r e :

He v i s i t a d o d o c e n a s d e t i e n d a s c o m e r c i a l e s , t a n t o b u e n a s c o m o m a l a s , y h e o b s e r v a d o registros d e g e r e n t e s de p r o c e s a m i e n t o de datos, d e n u e v o tanto b u e n o s comí

descomposició n del problema . . 6 5 2

m a l o s . Con m u c h a f r e c u e n c i a h e visto c o n h o r r o r c o m o d i c h o s g e r e n t e s l u c h a b a r

equipad. software . . . . . 6 4 5

t e m a s e n t r e g a d o s q u e i n d i g n a r o n a s u s u s u a r i o s y d e v o r a r o n e n o r m e s c a n t i d a d e s de

equipos ágiles

..649

líderes de EQUIPO

..644

participantes . . 6 4 4 personal

..643

prácticas ..658 principio W S HH

..65/

proceso . . . . . . 6 5 3 proyecto . . . . . 6 8 6

i n ú t i l m e n t e c o n p r o y e c t o s d e p e s a d i l l a , s u f r i e n d o p o r f e c h a s l í m i t e s i m p o s i b l e s o sistiempo de mantenimiento.

Lo q u e Page-Jones describe son s í n t o m a s q u e resultan de u n a serie de probá m a s de gestión y técnicos. Sin e m b a r g o , si se realizara u n a autopsia de cac proyecto, e s muy probable q u e se e n c o n t r a r a u n t e m a consistente: la gestión á proyecto fue débil. En este capítulo, y en los seis siguientes, se consideran los c o n c e p t o s cía i q u e c o n d u c e n a u n a gestión efectiva de proyectos de software. Este capí: considera c o n c e p t o s y principios básicos de gestión de proyectos de s o f t w a recapitulo 22 p r e s e n t a métricas del p r o c e s o y del proyecto, la b a s e p a r a una e:V tiva t o m a de decisiones de gestión. En los capítulos 23 y 24 se analizan las te nicas con q u e se estiman, s e define u n calendario realista y se establece un r : efectivo p a r a el proyecto. En el capítulo 25 se p r e s e n t a n las actividades de g e tión q u e c o n d u c e n a una efectiva supervisión, reducción y gestión del riesgo. F nalmente, en los capítulos 26 y 27 se consideran técnicas p a r a a s e g u r a r la c* dad c o n f o r m e un proyecto se lleva a c a b o y se g e s t i o n a n los c a m b i o s a lo lar de la vida de u n a aplicación.

¿ Q u é e s ? Aunque muchos (en sus momentos más oscuros) toman la visión de "gestión" de Dilberl, sigue siendo una actividad muy necesaria cuando se construyen sistemas y productos basados en computadoras. La gestión de proyectos involucra la planificación, supervisión y control del personal, el proceso y los eventos que ocurren mientras el software evoluciona desde un concepto preliminar hasta una implementación operativa. ¿ Q u i é n l o h a c e ? Todos "gestionan" en cierta medida, pero el ámbito de las actividades de

gestión varía entre las personas involucradas en un proyecto de software. Un ingeniero de software gestiona sus actividades diarias, y planifica, supervisa y controla las labores técni cas. Los gestores de proyecto planifican, superTMun equipo de ; visan y controlan el trabajo de :: ingenieros de software. Los gestores ejecutivos coordinan la relación entre el negocio y los profesionales del software. ¿ P o r q u é e s i m p o r t a n t e ? La construcción de software de computadora es una empresa com pleja, en particular si involucra a mucha gente que trabaja durante un tiempo relativamente

PDF Editor

CAPÍTULO 21


largo. Por esto los proyectos de software necesitan ser gestionados. |¡ . C u á l e s s o n l o s p a s o s ? Comprender las cuaro P: personal, producto, proceso y proyecto. El personal debe estar organizado para realizar el trabajo de software con efectividad. La comunicación con el cliente y otros participantes debe ocurrir de modo que sean comprensibles el ámbito y los requisitos del producto. Se debe seleccionar un proceso adecuado para el personal y el producto. El proyecto se debe planificar para estimar el esfuerzo y el tiempo para cumplir las labores del trabajo: definir productos de trabajo, establecer puntos de control de calidad e identificar mecanismos para supervisar y controlar el trabajo definido al planificar.

21,1

641

¿Cuál e s el producto obtenido? Cuando comienzan las actividades de gestión se produce un plan del proyecto. El plan define el proceso y las labores que se llevarán a cabo, el personal que hará el trabajo y los mecanismos para valorar los riesgos, controlar los cambios y evaluar la calidad.

¿Cómo p u e d o estar seguro d e q u e lo he h e c h o c o r r e c t a m e n t e ? Nunca se está completamente seguro de que el plan del proyecto es correcto hasta que haya entregado un producto de alta calidad a tiempo y dentro del presupuesto. Sin embargo, un gestor de proyecto hace lo correcto cuando alienta al personal de software a trabajar en conjunto como un equipo efectivo, y enfoca su atención tanto en b s necesidades del cliente como en b calidad del producto.

E L E S P E C T R O DE LA G E S T I Ó N La gestión eficaz de la gestión de proyectos de s o f t w a r e se e n f o c a s o b r e las c u a t r o P: personal, producto, proceso y proyecto. El orden n o e s arbitrario. El gestor q u e olvida q u e el trabajo de ingeniería del s o f t w a r e e s una e m p r e s a i n t e n s a m e n t e h u m a na n u n c a tendrá éxito en la gestión de proyectos. Un gestor q u e fracasa e n a l e n t a r la c o m u n i c a c i ó n amplia con los participantes e n e t a p a s t e m p r a n a s de la evolución de un proyecto se arriesga a construir u n a solución e l e g a n t e para el p r o b l e m a equivocado. El gestor q u e presta p o c a atención al p r o c e s o corre el riesgo de colocar m é todos y h e r r a m i e n t a s técnicos c o m p e t e n t e s en el vacío. El gestor que se e m b a r c a sin un plan de proyecto sólido arriesga el éxito del producto.

21.1.1 El personal La formación de personal de s o f t w a r e motivado y a l t a m e n t e calificado se ha debatid o desde los a ñ o s 60 del siglo p a s a d o (por ejemplo, [COU80], [WIT94], [DEM98]). De hecho, el "factor h u m a n o " e s tan importante que el Software Engineering Institute ha TM desarrollado un m o d e l o de m a d u r e z de la capacidad de gestión de personal (MMCGP) p a r a " a u m e n t a r la rapidez con la cual las organizaciones de s o f t w a r e a c o m e t e n las

PDF Editor

aplicaciones c a d a vez m á s complejas al ayudar a atraer, a u m e n t a r , motivar, desple-

gar y retener el talento necesario p a r a mejorar su capacidad de desarrollo de s o f t w a re" [CUR94].

El m o d e l o de m a d u r e z de gestión de personal define las siguientes á r e a s clave

prácticas p a r a el p e r s o n a l de s o f t w a r e reclutamiento, selección, gestión del d e s e m -

642

PARTE CUATRO

GESTIÓN DE PROYECTOS DE SOFTWARE

p e ñ o , e n t r e n a m i e n t o , retribución, desarrollo d e la carrera, d i s e ñ o d e la organización y el trabajo, y desarrollo de la cultura d e equipo. Las o r g a n i z a c i o n e s q u e logran altos niveles d e m a d u r e z en el á r e a d e gestión d e p e r s o n a l t i e n e n u n a mayor probabilidad d e i m p l e m e n t a r efectivas prácticas d e ingeniería del s o f t w a r e . El MMCGP e s c o m p a ñ e r o d e la Integración del Modelo d e Madurez de la Capacid a d d e S o f t w a r e (capítulo 2) q u e guía a las o r g a n i z a c i o n e s e n la creación de un p r o c e s o de s o f t w a r e m a d u r o . Más a d e l a n t e en este capítulo se consideran tópicos asociad o s con la gestión del p e r s o n a l y la estructura d e los proyectos de s o f t w a r e .

21.1.2 El producto Antes d e p l a n e a r u n proyecto se d e b e r í a n establecer los objetivos y el á m b i t o de ^ O H S E J O ^

En este contexto, el término producto se emplea para ahorcar cualquier software que se construye a solicitud de otros. No sólo incluye productos de software estandarizado, sino también sistemas basados en computadoras, software anidado, WebApps y software de resolución de problemas (por ejemplo, programas para resolución de problemas de ingeniería y científicos).

producto, c o n s i d e r a r s o l u c i o n e s alternativas e identificar las restricciones t é c n i c a s y d e gestión. Sin e s t a información e s imposible definir e s t i m a c i o n e s r a z o n a b l e s (y precisas) del costo, u n a valoración efectiva del riesgo, u n a división realista d e las t a r e a ; del proyecto o un c a l e n d a r i o de proyecto m a n e j a b l e q u e o f r e z c a u n a indicación fia ble del progreso. El desarrollador del s o f t w a r e y el cliente s e deben reunir para definir los objetivos y el á m b i t o del producto. En m u c h o s casos, esta actividad c o m i e n z a c o m o p a r t e de la ingeniería del sistema o d e la ingeniería del p r o c e s o d e n e g o c i o (capítulo 6) y continúa c o m o el primer p a s o e n la ingeniería d e requisitos d e s o f t w a r e (capítulo 7). Los objetivos identifican las m e t a s globales del p r o d u c t o (desde el p u n t o d e vista de. cliente) sin considerar c ó m o s e lograrán. El á m b i t o identifica los d a t o s primarios, las f u n c i o n e s y los c o m p o r t a m i e n t o s que c a r a c t e r i z a n al p r o d u c t o y, m á s importante, los i n t e n t o s por e n l a z a r tales características en u n a f o r m a cuantitativa. Una vez e n t e n d i d o s los objetivos y el á m b i t o del p r o d u c t o s e c o n s i d e r a n solucion e s alternativas. A u n q u e s e trata r e l a t i v a m e n t e p o c o detalle, las alternativas posibilitan q u e los g e s t o r e s y practicantes s e l e c c i o n e n un "mejor" e n f o q u e , c u m p l a n las restricciones q u e i m p o n e n las f e c h a s límites d e e n t r e g a , las restricciones p r e s u p u e s tarias, la disponibilidad del personal, las i n t e r f a s e s t é c n i c a s y miles d e factores más.

21.1.3 El proceso ÔNSEJO^ Quienes se adhieren o la filosofía del proceso ógil (capítulo 4) argumentan que sus procesos son más magros que otros. Esto puede ser cierto, pero ellos todavía tienen un proceso, y la ingeniería de software ágil toda••a requiere disciplino.

Un p r o c e s o d e s o f t w a r e (capítulos 2, 3 y 4) proporciona el m a r c o de t r a b a j o d e s d e e! cual s e p u e d e establecer un plan detallado para el desarrollo del s o f t w a r e . Un pequeñ o n ú m e r o d e actividades del m a r c o d e t r a b a j o e s aplicable a t o d o s los proyectos de s o f t w a r e , sin importar su t a m a ñ o o complejidad. Algunos c o n j u n tTM o s de t a r e a s difer e n t e s (tareas, hitos, p r o d u c t o s d e t r a b a j o y p u n t o s de control de calidad) permiten q u e las actividades del m a r c o d e t r a b a j o s e a d a p t e n a las características del proyec-

PDF Editor

to de software, así c o m o a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras (como el control de calidad del software, la gestión de configuración del software y la medición) cubren el modelo del proceso. Las actividades protectoras s o n i n d e p e n d i e n t e s d e cualquier actividad del m a r c o d e t r a b a j o y ocurren d u r a n t e tod o el p r o c e s o .

CAPÍTULO 21

643

CONCEPTOS DE GESTIÓN DE PSCYECTOS

21.1.4 El proyecto Los p r o y e c t o s d e s o f t w a r e s e r e a l i z a n de m a n e r a p l a n i f i c a d a y c o n t r o l a d a por u n a r a z ó n principal: e s la ú n i c a f o r m a c o n o c i d a d e g e s t i o n a r la c o m p l e j i d a d . I n c l u s o los e s f u e r z o s c o n t i n u a r á n . En 1998, los d a t o s i n d u s t r i a l e s i n d i c a r o n q u e el 2 6 p o r c i e n to d e l o s p r o y e c t o s d e s o f t w a r e f r a c a s a r o n p o r c o m p l e t o , y q u e el 4 6 p o r c i e n t o reb a s a r o n s u s c o s t o s y y t i e m p o s d e e n t r e g a [REE99]. A u n q u e la t a s a d e é x i t o p a r a los p r o y e c t o s d e s o f t w a r e h a m e j o r a d o u n p o c o , la t a s a de f r a c a s o d e p r o y e c t o s p e r m a n e c e m á s e l e v a d a d e lo q u e d e b i e r a . ' "Un proyecto es como un viaje por carretero. Algunos proyectos son simples y rutinarios, como conducir hacia la tienda a pleno luz del día. Pero la mayoría d e los proyectos que vale la pena realizar son m á s parecidos o conducir un camión «n So carretera, en la montaña, d e noche." Cent Koner, J o m e s Bach y Bret Pettichord

Para evitar el f r a c a s o del p r o y e c t o , u n g e s t o r d e p r o y e c t o d e s o f t w a r e y los i n g e n i e r o s d e s o f t w a r e q u e c o n s t r u y e n el p r o d u c t o d e b e n eludir un c o n j u n t o d e s e ñ a l e s d e a d v e r t e n c i a c o m u n e s , c o m p r e n d e r l o s f a c t o r e s d e é x i t o críticos q u e c o n d u c e n a u n a b u e n a g e s t i ó n del p r o y e c t o y d e s a r r o l l a r u n e n f o q u e d e s e n t i d o c o m ú n p a r a p l a nificar, s u p e r v i s a r y c o n t r o l a r el p r o y e c t o . C a d a u n o d e e s t o s t ó p i c o s s e t r a t a n e n la s e c c i ó n 2 1 . 5 y e n los c a p í t u l o s s i g u i e n t e s .

En u n e s t u d i o q u e p u b l i c ó el IEEE [CUR88] s e les p r e g u n t ó a los v i c e p r e s i d e n t e s d e ingeniería d e t r e s g r a n d e s c o m p a ñ í a s t e c n o l ó g i c a s c u á l e r a el c o n t r i b u y e n t e m á s imp o r t a n t e p a r a u n p r o y e c t o d e s o f t w a r e e x i t o s o . R e s p o n d i e r o n d e la s i g u i e n t e f o r m a : VP I: Supongo que si tienes que escoger alguna cosa que sea la más importante en nuestro ambiente, yo diría que no son las herramientas que utilizamos, es la gente. VP 2: El ingrediente más importante que fue exitoso en este proyecto fue el tener gente inteligente... en mi opinión, muy pocas cosas importan más... La cosa más importante que puedes hacer por un proyecto es seleccionar al equipo. .. El éxito de la organización de desarrollo de software está muy asociado con la habilidad de reclutar buen personal VP 3: La única regla que tengo en la gestión es asegurarme que tengo buen personal, verdadero buen personal, y que hago crecer al buen personal, y que proporciono un ambiente en el que el buen personal puede producir TM

PDF Editor

1 Dadas estas estadísticas, es razonable preguntar cómo el impacto de las computadoras continúa creciendo exponencialmente. El autor considera que parte de la respuesta es que un número sustancial de estos proyectos "fallidos" estuvo, en pnmer lugar, mal concebido Los clientes pierden interés rápidamente (porque el producto solicitado - o tue en realidad tan importante como lo que pensaron primero) y los proyectos se cancelar

644

PARTE CUATRO

G E S T I Ó N DE P R O Y E C T O S DE S O F T W A R E

De hecho, é s t e es un testimonio convincente acerca d e la importancia del personal e n los p r o c e s o s de ingeniería del software. Y sin embargo, todos, d e s d e los vicepresidentes de ingeniería hasta el profesional m á s modesto, u s u a l m e n t e n o prestan atención al personal. Los gestores a r g u m e n t a n (como lo h a c e el grupo anterior) que las p e r s o n a s son lo principal, pero sus acciones con frecuencia contradicen s u s palabras. En esta sección se e x a m i n a n los participantes e n el proceso de s o f t w a r e y la forma e n que se les organiza para realizar una ingeniería de s o f t w a r e efectiva.

21.2.1 Los participantes El proceso de s o f t w a r e (y cualquier proyecto de software) lo integran participantes q u e pueden clasificarse d e n t r o en una de cinco categorías: 1. Gestores ejecutivos, que definen los aspectos del negocio que u s u a l m e n t e tienen u n a influencia significativa en el proyecto. 2.

Gestores (técnicos) del proyecto, quienes planifican, motivan, organizan y controlan a los profesionales q u e realizan el trabajo de software.

3 . Profesionales, q u i e n e s proporcionan las habilidades técnicas n e c e s a r i a s para realizar la ingeniería de un producto o aplicación. 4 . Clientes, quienes especifican los requisitos para la ingeniería del s o f t w a r e y otros e l e m e n t o s que tienen un interés mínimo en el resultado. 5.

Usuarios finales, quienes interactúan con el s o f t w a r e una vez q u e se libera para su uso productivo.

Todo proyecto de s o f t w a r e lo integran p e r s o n a s que se clasifican en esta taxonomía. 2 Para ser eficaz, el equipo de proyecto d e b e estar o r g a n i z a d o e n una forma que maximice las c a p a c i d a d e s y habilidades d e cada persona. Y esta e s la labor del lídedel equipo.

21.2.2 Líderes de equipo La gestión del proyecto e s una actividad i n t e n s a m e n t e h u m a n a ; por tanto, los profesionales competentes con frecuencia no son buenos líderes de equipo. Simplemente r. :e tienen la mezcla correcta d e habilidades con el personal. Además, c o m o Edgemcnj afirma: "Desafortunadamente, y con d e m a s i a d a frecuencia, los individuos simple m e n t e c a e n en un papel d e gestor de proyecto y se vuelven gestores de proyecto a:-l cidentales" [EDG95], TM En un excelente libro acerca del liderazgo técnico, Jerry Weinberg [WE186] sugie-l re un m o d e l o MOI de liderazgo:

PDF Editor

M o t i v a c i ó n . La habilidad para alentar (mediante "empuje o jalón") al p e r s o

técnico para que p r o d u z c a según su mejor capacidad. 2

Cuando se desarrollan las aplicaciones Web (Parte 3 de este libro), en la creación de contenido

den involucrarse otras personas no técnicas.

C A P Í T U L O 21

buj. D i alguien M

ra

¿2

645


Organización. La habilidad para adecuar los procesos existentes (o inventar u n o s nuevos) que permitirán que el c o n c e p t o inicial s e a traducido en un producto fina[ I d e a s o i n n o v a c i ó n . La habilidad para alentar a la g e n t e a crear y sentir creativ a m e n t e , incluso c u a n d o deben trabajar d e n t r o de los límites establecidos por un producto o aplicación de s o f t w a r e particular. Weinberg sugiere q u e los líderes de proyecto exitosos aplican un estilo de gestión de resolución de problemas. Esto es: un gestor de proyecto de s o f t w a r e d e b e concentrarse en e n t e n d e r el problema que será resuelto, gestionar el flujo de ideas y, al m i s m o tiempo, hacer que todos los que forman el equipo c o n o z c a n (con palabras y, m u c h o m á s importante, con acciones) que la calidad es relevante y que n o será c o m prometida.

"En los términos más simples, un líder es aquel que sobe odónde quiere ir, y se levanta y va." John Erskine

Otra visión [EDG95] de las características que definen un gestor de proyecto eficiente resalta cuatro rasgos clave: R e s o l u c i ó n d e p r o b l e m a s . Un gestor de s o f t w a r e eficiente puede diagnosticar los conflictos técnicos y organizativos m á s relevantes, estructurar de m a n e r a sistemática una solución o motivar a d e c u a d a m e n t e a otros profesionales p a r a desarrollar la solución, aplicar en las n u e v a s situaciones las lecciones a p r e n d i d a s e n proyectos p a s a d o s , y m a n t e n e r s e lo suficientemente flexible c o m o para cambiar de dirección si los intentos iniciales en la solución del problema son infructuosos. D o t e s d e g e s t i ó n . Un b u e n gestor de proyecto d e b e e n c a b e z a r l o y dirigirlo. Debe tener la confianza de asumir el control c u a n d o e s necesario y la seguridad para permitir que los b u e n o s profesionales técnicos sigan sus instintos. I n c e n t i v o s . Para optimizar la productividad de un equipo de proyecto, un gestor d e b e r e c o m p e n s a r la iniciativa y los logros; a d e m á s , demostrar con s u s propias a c ciones que la toma de riesgos controlada n o será penalizada. Influencia y f o m e n t o d e la cultura d e e q u i p o . Un gestor de proyecto eficaz d e b e ser c a p a z de "leer" a la gente; de e n t e n d e r las s e ñ a l e s verbales y no verbales y reaccionar a las n e c e s i d a d e s de la g e n t e que las envía. El gestor d e b e m a n t e n e r el TM control en situaciones de alta tensión emocional.

21.2.3 El equipo de software

PDF Editor

Existen casi t a n t a s estructuras organizacionales de profesionales para el desarrollo

de s o f t w a r e c o m o organizaciones que tiene el m i s m o fin. Para bien o para mal, la estructura organizacional n o p u e d e ser fácilmente modificada. Las p r e o c u p a c i o n e s acerca de las c o n s e c u e n c i a s prácticas y políticas del c a m b i o organizacional no es-

646

PARTE CUATRO

GESTIÓN DE PROYECTOS DE S O F T W A R E

tá n d e n t r o del á m b i t o d e r e s p o n s a b i l i d a d del g e s t o r del p r o y e c t o de s o f t w a r e . S " | e m b a r g o , la o r g a n i z a c i ó n d e la g e n t e d i r e c t a m e n t e i n v o l u c r a d a e n u n p r o y e c t o o?I s o f t w a r e e s t á d e n t r o del á m b i t o del g e s t o r del p r o y e c t o . "No todo grupo es un equipo, y no todo equipo es eficiente." Glenn Parker

La " m e j o r " e s t r u c t u r a d e e q u i p o d e p e n d e del estilo d e g e s t i ó n d e c a d a o r g a n i z a ! ción, del n ú m e r o d e p e r s o n a s q u e i n t e g r a r á n el e q u i p o y de s u s g r a d o s de h a b i l i d a d l así c o m o d e la dificultad global del p r o b l e m a . Mantei [MAN81] d e s c r i b e siete f a c t : - l r e s d e p r o y e c t o q u e d e b e r í a n c o n s i d e r a r s e c u a n d o s e planifica la e s t r u c t u r a d e 1: J e q u i p o s d e i n g e n i e r í a del s o f t w a r e : 9 ¿Qué w tactores se deben considerar cuando se elige la estructura de un equipo de software?

• La dificultad del p r o b l e m a q u e s e r e s o l v e r á . • El " t a m a ñ o " del p r o g r a m a ( s ) r e s u l t a n t e ( s ) e n l í n e a s d e c ó d i g o o p u n t o s d e f u n l ción (capítulo 22). • El t i e m p o q u e el e q u i p o e s t a r á j u n t o (vida del e q u i p o ) . • El g r a d o e n el q u e el p r o b l e m a p u e d e s e p a r a r s e e n m ó d u l o s . • La c a l i d a d y confiabilidad r e q u e r i d o s del s i s t e m a q u e s e c o n s t r u i r á . • La rigidez d e la f e c h a de e n t r e g a . • El g r a d o de sociabilidad ( c o m u n i c a c i ó n ) q u e r e q u i e r e el p r o y e c t o . "Si quiere ser codo vez mejor: seo competitivo. Si quiere ser exponenciolmente mejor: seo cooperativo." Anónimo

C o n s t a n t i n e [CON93] s u g i e r e c u a t r o " p a r a d i g m a s o r g a n i z a c i o n a l e s " p a r a los e q i i l p o s d e ingeniería del s o f t w a r e : 9 !¿0«é • opciones s e tienen cuando se define la estructura de un equipo de software?

1.

Un paradigma

cerrado e s t r u c t u r a un e q u i p o a lo largo d e u n a j e r a r q u í a tradi-

c i o n a l de a u t o r i d a d . Es t o s e q u i p o s p u e d e n t r a b a j a r m e j o r c u a n d o p r o d u c e n s o f t w a r e m u y similar a los p r o y e c t o s a n t e r i o r e s , p e r o s e r á m e n o s p r o b a b l e q u e s e a n i n n o v a d o r e s c u a n d o t r a b a j e n d e n t r o del p a r a d i g m a c e r r a d o . 2.

Un paradigma

aleatorio e s t r u c t u r a un e q u i p o l i b r e m e n t e y d eTM p e n d e d e la ini- I

ciativa individual de los m i e m b r o s del e q u i p o . C u a n d o s e r e q u i e r e n i n n o v a ción o a d e l a n t o s t e c n o l ó g i c o s , los e q u i p o s q u e s i g u e n el p a r a d i g m a a l e a t o n : I

PDF Editor

s e r á n e x c e l e n t e s . Pero e s t o s e q u i p o s p u e d e n l u c h a r c u a n d o s e r e q u i e r e "des e m p e ñ o ordenado".

3.

Un paradigma

abierto i n t e n t a e s t r u c t u r a r un e q u i p o e n u n a f o r m a q u e logre a C |

g u n o s d e los c o n t r o l e s a s o c i a d o s c o n el p a r a d i g m a c e r r a d o , p e r o t a m b i é n m u c h a d e la i n n o v a c i ó n q u e o c u r r e c u a n d o s e a p l i c a el p a r a d i g m a a l e a t o r i :

I

CAPITULO 21

647

C O N C E P T O S DE G E S T I Ó N DE P R O Y E C T O S

El t r a b a j o s e d e s a r r o l l a e n c o l a b o r a c i ó n . La sólida c o m u n i c a c i ó n y la t o m a d e d e c i s i o n e s b a s a d a e n el c o n s e n s o s o n las m a r c a s c a r a c t e r í s t i c a s d e los e q u i p o s d e p a r a d i g m a abierto. Las e s t r u c t u r a s d e e q u i p o d e p a r a d i g m a a b i e r t o s e a d e c ú a n bien a la s o l u c i ó n d e p r o b l e m a s c o m p l e j o s , p e r o n o p u e d e n d e s e m p e ñ a r s e de m a n e r a tan eficiente c o m o otros equipos. 4.

Un paradigma

sincrónico

s e a p o y a en la c o m p a r t i m e n t a l i z a c i ó n n a t u r a l d e u n

p r o b l e m a y o r g a n i z a a los m i e m b r o s del e q u i p o p a r a t r a b a j a r e n p a r t e s del p r o b l e m a c o n p o c a c o m u n i c a c i ó n a c t i v a e n t r e ellos. "Trabajar con la gante es dificil, mas no imposible."

P e l e r Drucker C o m o n o t a histórica, u n a d e l a s p r i m e r a s o r g a n i z a c i o n e s d e los e q u i p o s d e s o f t w a r e f u e u n a e s t r u c t u r a d e p a r a d i g m a c e r r a d o o r i g i n a l m e n t e l l a m a d a equipo programador jefe. Esta e s t r u c t u r a la p r o p u s o o r i g i n a l m e n t e Harían Mills y la d e s c r i b i ó Baker [BAK72]. El n ú c l e o del e q u i p o lo c o m p o n e u n ingeniero

ejecutivo

(el p r o g r a m a d o r je-

fe), q u i e n planifica, c o o r d i n a y revisa t o d a s las a c t i v i d a d e s t é c n i c a s del e q u i p o ; personal técnico (por lo g e n e r a l , d e d o s a c i n c o p e r s o n a s ) , q u i e n e s dirigen l a s a c t i v i d a d e s d e análisis y d e s a r r o l l o ; y u n ingeniero

de respaldo,

q u i e n a p o y a al i n g e n i e r o ejecuti-

v o e n s u s a c t i v i d a d e s y p u e d e r e e m p l a z a r l o c o n m í n i m a p é r d i d a e n la c o n t i n u i d a d del proyecto. Al p r o g r a m a d o r j e f e p u e d e n asistirlo u n o o m á s especialistas

(por e j e m p l o , e x p e r -

t o s e n t e l e c o m u n i c a c i o n e s , d i s e ñ a d o r d e b a s e s d e d a t o s ) , personal

de apoyo

e j e m p l o , e s c r i t o r e s t é c n i c o s , p e r s o n a l a d m i n i s t r a t i v o ) y u n bibliotecario

(por

de software.

C o m o c o n t r a p a r t e a la e s t r u c t u r a de e q u i p o p r o g r a m a d o r jefe, el p a r a d i g m a a l e a torio de C o n s t a n t i n e [CON93] s u g i e r e u n e q u i p o de s o f t w a r e c o n i n d e p e n d e n c i a c r e a t i v a c u y o e n f o q u e p a r a t r a b a j a r p u e d e d e n o m i n a r s e m e j o r c o m o anarquía

inno-

vadora. A u n q u e s e h a a p e l a d o al e n f o q u e d e libre espíritu p a r a el t r a b a j o d e s o f t w a re, la c a n a l i z a c i ó n de la e n e r g í a c r e a t i v a h a c i a u n e q u i p o d e a l t o r e n d i m i e n t o d e b e s e r u n a m e t a c e n t r a l e n u n a o r g a n i z a c i ó n de i n g e n i e r í a del s o f t w a r e . Para lograr un equipo de alto rendimiento: • Los m i e m b r o s del e q u i p o d e b e n t e n e r s e m u t u a c o n f i a n z a . • La distribución de las h a b i l i d a d e s d e b e a d e c u a r s e al p r o b l e m a . • Tal v e z los d i s i d e n t e s d e b a n s e r e x c l u i d o s del e q u i p o si ha d e c o n s e r v a r s e s u cohesión.

TM

Sin i m p o r t a r la o r g a n i z a c i ó n del e q u i p o , el o b j e t i v o d e c u a l q u i e r g e r e n t e d e p r o y e c t o e s a p o y a r la c r e a c i ó n d e u n e q u i p o q u e m u e s t r e c o h e s i ó n . En su libro, Peoplewa

PDF Editor re, D e M a r c o y Lister [DEM98] e x a m i n a n e s t e tópico:

¿Qué e s un equipo "?

Tendemos a usar la palabra equipo con bastante libertad en el mundo de los negocios, y llamamos "equipo" a cualquier grupo de personas asignadas a trabajar juntas. Pero mu-

chos de estos grupos no parecen equipos No tienen una definición común de éxito o al-

PARTE CUATRO

GESTIÓN DE P R O Y E C T O S DE S O F T W A R E

gún espíritu de equipo identificable. Lo que s e ha perdido es un f e n ó m e n o que llamamos cuajar (jell). Un equipo c u a j a d o es un grupo d e p e r s o n a s tan f u e r t e m e n t e unido que el todo es mayor que la s u m a d e las partes... Una vez que un equipo comienza a cuajar, la probabilidad d e éxito a u m e n t a . El equipo p u e d e volverse imparable, un m o n s t r u o destructivo para lograr el éxito... No necesita ser g e s tio n ado en la forma tradicional, y ciertamente n o necesita ser motivado. Tiene ímpetu.

D e M a r c o y Lister s o s t i e n e n q u e los m i e m b r o s d e los e q u i p o s c u a j a d o s s o n significat i v a m e n t e m á s p r o d u c t i v o s y e s t á n m á s m o t i v a d o s q u e el p r o m e d i o . C o m p a r t e n una m e t a c o m ú n , u n a c u l t u r a c o m ú n y, e n m u c h o s c a s o s , u n " s e n t i m i e n t o elitista" que los h a c e ú n i c o s . P e r o n o t o d o s los e q u i p o s c u a j a n . De h e c h o , m u c h o s e q u i p o s s u f r e n de lo q u e J a c k m a n [JAC98] d e n o m i n a "toxicidad d e equipo". Ella d e f i n e c i n c o f a c t o r e s q u e "fom e n t a n u n a m b i e n t e de e q u i p o p o t e n c i a l m e n t e tóxico": 1) u n a a t m ó s f e r a d e traba] : f r e n é t i c a , 2) alta f r u s t r a c i ó n q u e p r o v o c a fricción e n t r e los m i e m b r o s del e q u i p o , 3) u n p r o c e s o d e s o f t w a r e " f r a g m e n t a d o o p o b r e m e n t e c o o r d i n a d o " , 4) u n a definición p o c o c l a r a d e los p a p e l e s del e q u i p o d e s o f t w a r e , y 5) " c o n t i n u a s y r e p e t i d a s expos: c i o n e s al f r a c a s o " . Para evitar u n a m b i e n t e d e t r a b a j o f r e n é t i c o , el g e s t o r del p r o y e c t o d e b e t e n e r la c e r t e z a d e q u e el e q u i p o t i e n e a c c e s o a t o d a la i n f o r m a c i ó n r e q u e r i d a p a r a realizar el t r a b a j o y q u e las m e t a s y objetivos, u n a v e z d e f i n i d o s , n o d e b e n m o d i f i c a r s e a m e n o s q u e s e a a b s o l u t a m e n t e n e c e s a r i o . Un e q u i p o d e s o f t w a r e p u e d e evitar la frustración (y el e s t r é s ) si s e le d a t a n t a r e s p o n s a b i l i d a d e n la t o m a de d e c i s i o n e s c o m o s e a posible. Un p r o c e s o i n a d e c u a d o (por e j e m p l o , t a r e a s d e t r a b a j o i n n e c e s a r i a s o a b r u m a d o r a s o p r o d u c t o s de t r a b a j o m a l elegidos) s e p u e d e evitar si s e c o m p r e n d e el p r o d u c t o q u e se c o n s t r u i r á y al p e r s o n a l q u e r e a l i z a el t r a b a j o , y al p e r m i t i r al equip o s e l e c c i o n a r s u p r o p i o m o d e l o d e p r o c e s o . El e q u i p o d e b e e s t a b l e c e r p o r sí m i s m o m e c a n i s m o s p a r a s u r e s p o n s a b i l i d a d (revisiones t é c n i c a s f o r m a l e s y la p r o g r a m a ción p o r p a r e s s o n e x c e l e n t e s f o r m a s d e lograrlo) y definir u n a serie de e n f o q u e s correctivos c u a n d o u n m i e m b r o del e q u i p o falle e n s u d e s e m p e ñ o . Y, finalmente, la clave p a r a evitar u n a a t m ó s f e r a d e f r a c a s o e s e s t a b l e c e r t é c n i c a s b a s a d a s e n el e q u i p o p a r a la r e a l i m e n t a c i ó n y r e s o l u c i ó n d e p r o b l e m a s .

"Hacer o no hacer. No existe intentar."

TM Y o d a , d e Star Wors

PDF Editor

A d e m á s d e las c i n c o t o x i n a s q u e d e s c r i b e J a c k m a n , u n e q u i p o d e s o f t w a r e usual-

m e n t e e n f r e n t a los d i f e r e n t e s r a s g o s h u m a n o s d e s u s m i e m b r o s . A l g u n o s m i e m b r o s del e q u i p o s o n e x t r o v e r t i d o s ; o t r o s , introvertidos. A l g u n a s p e r s o n a s r e c o p i l a n inform a c i ó n i n t u i t i v a m e n t e ; s e p a r a n los c o n c e p t o s a m p l i o s d e los h e c h o s d i s p a r a t a d o s .

CAPÍTULO 21


649

O t r o s p r o c e s a n la i n f o r m a c i ó n Iinealmente, r e ú n e n y o r g a n i z a n detalles m i n u c i o s o s d e los d a t o s p r o p o r c i o n a d o s . Algunos m i e m b r o s del e q u i p o s e s i e n t e n c ó m o d o s al t o m a r d e c i s i o n e s sólo c u a n d o s e p r e s e n t a un o r d e n a d o a r g u m e n t o lógico. Otros s o n intuitivos, por lo q u e d e s e a n t o m a r d e c i s i o n e s c o n b a s e en el "sentimiento". Algunos p r o f e s i o n a l e s prefieren u n a planificación detallada q u e incluya t a r e a s o r g a n i z a d a s q u e les p e r m i t a n lograr el cierre d e algún e l e m e n t o del proyecto. O t r o s prefieren un a m b i e n t e m á s e s p o n t á n e o en el q u e los t e m a s a b i e r t o s s o n bien vistos. Algunos trab a j a n d u r o p a r a h a c e r q u e las c o s a s e s t é n listas m u c h o a n t e s d e u n a f e c h a límite, y por c o n s i g u i e n t e evitan la tensión c o n f o r m e la fecha s e aproxime, m i e n t r a s q u e o t r o s s e sienten vigorizados por la prisa d e lograrlo e n el último m i n u t o del plazo. Un e x a m e n detallado d e la psicología d e e s t o s r a s g o s y las f o r m a s en las c u a l e s el líder e x p e r i m e n t a d o del e q u i p o p u e d e a y u d a r a la g e n t e c o n r a s g o s o p u e s t o s p a r a trabajar en c o n j u n t o está m á s allá del á m b i t o d e e s t e libro. 3 Sin e m b a r g o , e s i m p o r t a n te d e s t a c a r q u e el r e c o n o c i m i e n t o d e las diferencias h u m a n a s e s el primer p a s o h a cia la creación d e e q u i p o s q u e c u a j a n .

21.2.4 Equipos ágiles En a ñ o s recientes s e h a p r o p u e s t o el desarrollo del s o f t w a r e ágil (capítulo 4) c o m o a n t í d o t o p a r a m u c h o s d e los p r o b l e m a s q u e perjudican el t r a b a j o d e los proyectos d e s o f t w a r e . En síntesis, la filosofía ágil alienta la satisfacción del cliente y la t e m p r a n a e n t r e g a incremental d e s o f t w a r e ; p e q u e ñ o s e q u i p o s d e t r a b a j o e n o r m e m e n t e motivados; m é t o d o s informales; m í n i m o s p r o d u c t o s d e t r a b a j o de ingeniería del s o f t w a re; y simplicidad global d e desarrollo. El p e q u e ñ o e q u i p o d e t r a b a j o e n o r m e m e n t e motivado, t a m b i é n l l a m a d o equipo ágil, a d o p t a m u c h a s características d e los e q u i p o s de p r o y e c t o d e s o f t w a r e exitosos t r a t a d o s e n la sección p r e c e d e n t e y evitan m u c h a s d e las t o x i n a s q u e crean problem a s . Sin e m b a r g o , el e n f o q u e ágil s u b r a y a la c o m p e t e n c i a individual (miembros del equipo) en c o n j u n c i ó n c o n la colaboración del g r u p o c o m o f a c t o r e s d e éxito cruciales para el equipo. Cockburn y Highsmith [COCOl] d e s t a c a n e s t o c u a n d o escriben: Si el p e r s o n a l e n el p r o y e c t o e s lo s u f i c i e n t e m e n t e b u e n o , p u e d e n u s a r casi c u a l q u i e r p r o c e s o y l o g r a r s u c o m e t i d o . Si n o e s lo s u f i c i e n t e m e n t e b u e n o , n i n g ú n p r o c e s o r e p a r a r á s u i n c a p a c i d a d : " p e r s o n a m a t a p r o c e s o " e s u n a f o r m a d e decir e s t o . Sin e m b a r g o , la falta d e a p o y o del u s u a r i o y el e j e c u t i v o p u e d e n a n i q u i l a r u n p r o y e c t o : "política m a t a p e r s o n a " . El a p o y o i n a d e c u a d o p u e d e i n c l u s o e v i t a r q u e el b u e n p e r s o n a l l o g r e la t a r e a . . .

Para a p r o v e c h a r en f o r m a eficiente las c o m p e t e n c i a s d e c a d a m i eTM m b r o del equip o y f o m e n t a r la c o l a b o r a c i ó n eficaz a lo largo d e un proyecto d e s o f t w a r e , los equip o s ágiles s o n autoorganizados.

Un e q u i p o a u t o o r g a n i z a d o n o n e c e s a r i a m e n t e m a n -

PDF Editor 3

Una excelente introducción a e s t o s t e m a s , r e l a t a d » por equipos d e proyecto d e software, se p u e d e

encontrar en [FER98].

650

PARTE CUATRO

G E S T I Ó N DE P R O Y E C T O S DE SOFTWARE

t i e n e u n a sola e s t r u c t u r a d e e q u i p o , s i n o q u e m á s bien a p r o v e c h a e l e m e n t o s d e l a p a r a d i g m a s a l e a t o r i o , a b i e r t o y s i n c r ó n i c o d e C o n s t a n t i n e t r a t a d o s e n la s e c c i c ^ 21.2.3. " t a propiedad colectiva no es más que una partkularización de la ideo de que los productos deben ser atribuibles al e q u i p o [ á g i l ] , n o a ios individuos que integraron el equipo."

Jim Highsmith

M u c h o s m o d e l o s d e p r o c e s o ágil (por e j e m p l o , S e r u m ) b r i n d a n al e q u i p o ágil u n a a u t o n o m í a significativa p a r a r e a l i z a r la g e s t i ó n del p r o y e c t o y t o m a r las d e c i s i o n e s

CLAVE Un equipo ágil es un equipo autoorganizodo que tiene autonomía poro ploneor y tomar decisiones técnicas.

t é c n i c a s r e q u e r i d a s p a r a c u m p l i r el t r a b a j o . La planificación s e m a n t i e n e e n el m í r m o , y al e q u i p o s e le p e r m i t e s e l e c c i o n a r s u p r o p i o e n f o q u e (por e j e m p l o , p r o c e s o m é t o d o s , h e r r a m i e n t a s ) , s ó l o r e s t r i n g i d o p o r los r e q u i s i t o s del n e g o c i o y los e s t á r d a r e s o r g a n i z a c i o n a i e s . C o n f o r m e el p r o y e c t o a v a n z a el e q u i p o s e a u t o o r g a n i z a para e n f o c a r la c o m p e t e n c i a individual e n u n a f o r m a q u e s e a m á s b e n é f i c a p a r a el proy e c t o e n u n p u n t o d a d o e n el t i e m p o . Para lograrlo, u n e q u i p o ágil p u e d e dirigir bre v e s r e u n i o n e s d e e q u i p o d i a r i a s p a r a c o o r d i n a r y s i n c r o n i z a r el t r a b a j o q u e s e d e t e | lograr e s e día. C o n b a s e e n la i n f o r m a c i ó n o b t e n i d a d u r a n t e e s t a s r e u n i o n e s , el e q u i p o a d a p t a s u e n f o q u e d e f o r m a tal q u e logra u n i n c r e m e n t o de t r a b a j o . C o n f o r m e p a s a c a a día, la a u t o o r g a n i z a c i ó n c o n t i n u a y la c o l a b o r a c i ó n m u e v e n al e q u i p o h a c i a la conc l u s i ó n de u n i n c r e m e n t o d e s o f t w a r e .

21.2.5 Conflictos d e coordinación y comunicación Existen m u c h a s r a z o n e s p o r l a s c u a l e s los p r o y e c t o s d e s o f t w a r e s e v u e l v e n proble- ] m á t i c o s . La e s c a l a de m u c h o s e s f u e r z o s de d e s a r r o l l o e s g r a n d e , lo q u e c o n d u c e a c o m p l e j i d a d , c o n f u s i ó n y d i f i c u l t a d e s significativas e n la c o o r d i n a c i ó n d e los m i e r b r o s del e q u i p o . La i n c e r t i d u m b r e e s c o m ú n , lo q u e g e n e r a u n a c o r r i e n t e c o n t i n u a | d e c a m b i o s q u e m u e v e g r a d u a l m e n t e e n u n a s o l a d i r e c c i ó n al e q u i p o del p r o y e c i : La i n t e r o p e r a b i l i d a d s e h a c o n v e r t i d o e n u n a c a r a c t e r í s t i c a c l a v e d e m u c h o s siste m a s . El n u e v o s o f t w a r e d e b e c o m u n i c a r s e c o n el a n t e r i o r y a d e c u a r s e a las restricc i o n e s p r e d e f i n i d a s q u e i m p o n e el s i s t e m a o p r o d u c t o . E s t a s c a r a c t e r í s t i c a s del s o f t w a r e m o d e r n o — e s c a l a , i n c e r t i d u m b r e e i n t e r o p e r a bilidad— s o n a s p e c t o s d e la v i d a . Para lidiar c o n ellos e n f o r m a e f i c a z , un e q u i p o á t ingeniería de s o f t w a r e d e b e e s t a b l e c e r m é t o d o s e f i c i e n t e s p a r a cTM o o r d i n a r al p e r s o nal q u e r e a l i z a el t r a b a j o . Para lograrlo se d e b e n e s t a b l e c e r m e c a n i s m o s p a r a la c o | m u n i c a c i ó n f o r m a l e i n f o r m a l e n t r e los m i e m b r o s del e q u i p o y e n t r e m ú l t i p l e s e q u :

PDF Editor

p o s . La c o m u n i c a c i ó n f o r m a l s e logra p o r m e d i o d e "escritos, r e u n i o n e s estructuradas y otros canales de comunicación relativamente no interactivos e impersonales [KRA95]. La c o m u n i c a c i ó n i n f o r m a l e s m á s p e r s o n a l . Los m i e m b r o s d e u n e q u i p o de

s o f t w a r e c o m p a r t e n i d e a s s o b r e u n a b a s e ad hoc, p i d e n a y u d a c u a n d o s u r g e n p r o b l e m a s e interactúan u n o s con otros diariamente.

CAPÍTULO 21


651

EOGARSEGURO

Estructura de equipo El e s c e n a r i o : La oficina de Doug el inicio del proyecto d e software HogarSe-

D o u g : Está bien por mí, pero ustedes conocen el procedimiento.

r e s : Doug Miller (gerente del equipo de ingeB del software HogarSeguro! y Vinod Román, Jamie f otros miembros del equipo de ingeniería d e softI producto.

conversación: • g : ¿Ustedes han tenido oportunidad de echar un fcc o la información preliminar de HogarSegvro que pero mercadotecnia?

' '

lí

'

Jamie (sonríe y habla como si recitara algo): Tomamos decisiones tácticas, acerca de quién hace qué y cuándo, pero es nuestra responsabilidad tener el producto listo a tiempo.

Vinod: V con calidad. D o u g : Exactamente. Pero recuerda que existen restricciones. Mercadotecnia define los incrementos de software que se producirán... con nuestra asesoría, desde luego.

• d ¡afirma con la cabeza y mira a sus

Jamie: ¿Y?

« p a ñ e r o s d e e q u i p o ) : Sí. Pero tenemos muchas

D o u g : Y, vamos a usar UML como nuestro enfoque de modelado.

• g : Dejemos eso por el momento. Quiero hablar : ae cómo vamos a estructurar el equipo, quién es r - s a b l e de qué... : Yo realmente estoy con la filosofía ágil, Doug i debemos ser un equipo autoorganizado. ¡ Estoy de acuerdo. Dados el ceñido periodo de i y algo de ¡ncertidumbre, y al hecho de que todos ; somos competentes [risas], me parece que ese - el que debemos ir.

21,3

V i n o d : Pero manten la documentación extraña en un mínimo absoluto. D o u g : ¿Quién va a ser mi contacto? J a m i e : Decidimos que Vinod será el líder técnico. Él tiene más experiencia, así que Vinod es tu contacto, pero siéntete en libertad d e hablar con cualquiera de nosotros.

Doug (ríe): No te preocupes, lo haré.

EL PRPPVCTQ El gestor de un proyecto de s o f t w a r e se enfrenta con un dilema d e s d e el principio m i s m o de un proyecto de ingeniería del software. Se requieren estimaciones cuantitativas y un plan organizado, p e r o n o se dispone de información sólida. Un análisis detallado d e los requisitos de s o f t w a r e proporcionaría la información necesaria p a ra las estimaciones, pero, con frecuencia, el análisis t o m a s e m a n a s o m e s e s en c o m pletarse. Peor aún, los requisitos pueden ser fluidos, y cambian regularmente c o n forme el proyecto a v a n z a . Más todavía, ¡se necesita un plan "ahora"!TM En consecuencia, se deben e x a m i n a r el producto y el problema que se intenta resolver al inicio del proyecto. Como mínimo, se d e b e establecer y acotar el ámbito del producto.

PDF Editor 21.3.1 Ámbito del software

La primera actividad de gestión de un proyecto de s o f t w a r e es la determinación del

ámbito del software. El ámbito se define al r e s p o n d e r las siguientes preguntas:

652

PARTE CUATRO


C o n t e x t o . ¿Cómo e n c a j a el s o f t w a r e que se desarrollará e n un sistema m á s gr ( C O N S E J O ^ .

Si no puede acotar una característica del software que intenta construir, anote la característica como un riesgo del proyecto (capítulo 25).

de, producto o contexto de negocios, y qué restricciones se imponen c o m o resul do del contexto? O b j e t i v o s d e i n f o r m a c i ó n . ¿Qué objetos de d a t o s visibles al usuario (capítulo se p r o d u c e n c o m o resultado del software? ¿Qué objetos de d a t o s se requieren de trada? F u n c i ó n y d e s e m p e ñ o . ¿Qué funciones realiza el s o f t w a r e para transformar d a t o s de entrada e n salida? ¿Existen algunas características de d e s e m p e ñ o espe les que d e b a n abordarse? El á m b i t o del proyecto de s o f t w a r e no d e b e ser ambiguo ni incomprensible a niv de gestión y técnico. Se d e b e acotar un enunciado del ámbito del software. Esto se establecen de m a n e r a explícita los d a t o s cuantitativos (por ejemplo, n ú m e r o usuarios simultáneos, t a m a ñ o de la lista de correo, tiempo de respuesta máxi permitido); se a n o t a n las restricciones o limitaciones (por ejemplo, el costo del ducto restringe el t a m a ñ o de la memoria) y se describen los factores q u e red" riesgos (por ejemplo, los algoritmos d e s e a d o s se c o m p r e n d e n bien y están dis bles en C++).

21.3.2 Descomposición del problema La descomposición del problema, a veces llamada partición o elaboración del p ma, es u n a actividad q u e se asienta e n el núcleo del análisis de requisitos de so re (capítulos 7 y 8). Durante la actividad de fijación del á m b i t o n o se realiza int alguno por d e s c o m p o n e r c o m p l e t a m e n t e el problema. Más bien, la descomposi se aplica en dos g r a n d e s áreas: 1) la funcionalidad que d e b e entregarse y 2) el c e s o q u e s e e m p l e a r á para entregarla. ÔNSEJO^ B desarrollo de un plan de proyecto razonable requiere descomponer el problema. Estose puede lograr empleando una lista de funciones o de casos de uso o, en el traba¡o ágil, historias de usuario.

Los seres h u m a n o s tienden a aplicar u n a estrategia de divide y vencerás cu e n f r e n t a n un problema complejo. Dicho con simplicidad, un problema complejo divide e n problemas m e n o r e s que resultan m á s manejables. Ésta es la estrategia se aplica c u a n d o c o m i e n z a la planificación del proyecto. Las funciones d e softw descritas al enunciar el ámbito, se evalúan y refinan para proporcionar m á s de a n t e s del c o m i e n z o de la estimación (capítulo 23), Puesto que las estimaciones costo y planificación temporal están f u n c i o n a l m e n t e orientadas, con frecuencia útil cierto grado de descomposición. Por ejemplo, c o n s i d é r e s e un proyecto que construirá un n u e vTM o procesador de tos. Entre las características únicas del producto están la e n tr a da continua mer te voz, así c o m o por teclado, funciones muy sofisticadas de "edición automática

PDF Editor

copia", capacidad de diseño de página, índice y tabla d e contenido automáticos otras. El gestor del proyecto primero d e b e establecer un e n u n c i a d o del ámbito a c o t e e s t a s características (así c o m o otras funciones m á s usuales c o m o la edi la gestión de archivos, la producción de d o c u m e n t o s y o t r a s parecidas). Por ejem ¿la e n t r a da continua de voz requiere q u e el usuario del producto lo "entrene"?

CAPÍTULO 21


653

cíficamente, ¿qu é c a p a c i d a d e s p r o p o r c i o n a r á la característica de edición d e copia? ¿Cuán sofisticada s e r á la c a p a c i d a d d e d i s e ñ o d e p á g i n a ? C o n f o r m e evoluciona el e n u n c i a d o del á m b i t o ocurre n a t u r a l m e n t e un primer nivel d e partición. El e q u i p o del proyecto a p r e n d e q u e el d e p a r t a m e n t o d e m e r c a d o tecnia ha h a b l a d o c o n los clientes p o t e n c i a l e s y e n c o n t r ó que las siguientes funcion e s d e b e n integrars e a la edición a u t o m á t i c a d e copia: 1) c o m p r o b a c i ó n ortográfica, 2) c o m p r o b a c i ó n gramatical, 3) c o m p r o b a c i ó n d e r e f e r e n c i a s p a r a d o c u m e n t o s g r a n d e s (por e j e m p l o , ¿la referencia a u n a e n t r a d a bibliográfica se e n c u e n t r a en la lista d e e n t r a d a s e n la bibliografía?) y 4) validación de referencias d e sección y capítulo p a r a d o c u m e n t o s g r a n d e s . Cada u n a d e e s t a s características r e p r e s e n t a u n a s u b f u n c i ó n q u e d e b e i m p l e m e n t a r s e e n el s o f t w a r e . Cada u n a todavía p u e d e refinars e m á s si la d e s c o m p o s i c i ó n simplifica la planificación.

Las actividades del m a r c o d e t r a b a j o (capítulo 2) q u e c a r a c t e r i z a n al p r o c e s o d e softw a r e s o n aplicables a t o d o s los proyectos d e s o f t w a r e . El p r o b l e m a e s seleccionar el m o d e l o de p r o c e s o a p r o p i a d o p a r a q u e un e q u i p o d e proyecto s o m e t a al s o f t w a r e a ingeniería. El gestor del proyecto d e b e decidir cuál m o d e l o d e p r o c e s o e s m á s a d e c u a d o para 1) los clientes q u e h a n solicitado el p r o d u c t o y el p e r s o n a l q u e h a r á el trabajo; 2) las características del p r o d u c t o m i s m o , y 3) el a m b i e n t e del proyecto en el que trabaja el e q u i p o d e s o f t w a r e . C u a n d o s e ha s e l e c c i o n a d o u n m o d e l o d e p r o c e s o , e n t o n c e s el e q u i p o define un plan d e proyecto preliminar con b a s e en el c o n j u n t o de actividades del m a r c o d e t r a b a j o del proceso. Una vez que s e e s t a b l e c e el plan preliminar, c o m i e n z a la d e s c o m p o s i c i ó n del p r o c e s o . Esto es, s e d e b e crear un plan

* 7 de una ¡ veas" puede íheiramienkoción de s outomalizo¡24). La f :*ga con estiÍ de requisit tarsos, ¡ie inicio/fin y spertinentces puede testo red cori recursos poro ntoy t el proyecto.

completo, q u e refleje las t a r e a s de t r a b a j o r e q u e r i d a s para cubrir las actividades del m a r c o d e trabajo. Estas actividades s e exploran b r e v e m e n t e e n las s e c c i o n e s siguientes, y en el capítulo 24 s e p r e s e n t a u n a visión m á s detallada.

21.4.1 Combinación del producto y el proceso La p l a n e a c i ó n del proyecto c o m i e n z a c o n la c o m b i n a c i ó n del p r o d u c t o y el proceso. Cada función q u e el e q u i p o d e s o f t w a r e s o m e t e r á a ingeniería d e b e p a s a r a través del c o n j u n t o d e actividades del m a r c o d e t r a b a j o definidas p a r a u n a o r g a n i z a c i ó n d e s o f t w a r e . S u p ó n g a s e q u e la o r g a n i z a c i ó n ha a d o p t a d o el siguiente c o n j u n t o d e actiTM v i d a d e s del m a r c o d e t r a b a j o (capítulo 2): c o m u n i c a c i o n e s , planificación, m o d e l a d o , c o n s t r u c c i ó n y despliegue.

PDF Editor

Los m i e m b r o s del e q u i p o q u e t r a b a j a n e n u n a función d e p r o d u c t o le aplicarán

c a d a u n a d e las actividades del m a r c o d e trabajo. En e s e n c i a , s e crea u n a m a t r i z similar a la m o s t r a d a e n la figura 21.1. Cada f u n c i ó n de p r o d u c t o principal (en la figura s e a n o t a n f u n c i o n e s p a r a el s o f t w a r e del p r o c e s a d o r d e textos c o m e n t a d o a n t e riormente) s e m e n c i o n a e n la c o l u m n a izquierda Las actividades del m a r c o d e tra-

654

PARTE CUATRO

Combinación del p r o b l e m a y el proceso.


ACTIVIDADES C O M U N E S DEL M A R C O DE TRABAIO DEL P R O C E S O

/ /

A/// § / ^ / / ^

Funciones del producto

/

/

v g

zz //

E n t r a d a d e texto Edición y f o r m o t e a d o Edición a u t o m á t i c a d e c o p i a C a p a c i d a d d e plantilla d e p á a i n a índice y t a b l a d e c o n t e n i d o a u t o m á t i c o s Gestión d e archivos Producción d e documento

% CLAVE El marco de trabajo del proceso estoblece un esqueleto poní la plonifkooón del proyecto. Se odopta al ubicar un conjunto de táreos adecuodos paro el proyecto.

b a j o se m e n c i o n a n e n la hilera s u p e r i o r . Las l a b o r e s d e t r a b a j o d e i n g e n i e r í a del w a r e (para c a d a actividad del m a r c o d e t r a b a j o ) se i n g r e s a r í a n en la hilera sigu ; ~ te. 4 El t r a b a j o del g e s t o r del p r o y e c t o (y d e o t r o s m i e m b r o s del e q u i p o ) c o n s i s t e e s t i m a r los r e q u i s i t o s de r e c u r s o s p a r a c a d a c e l d a d e la m a t r i z , f e c h a s d e inicio y nal p a r a l a s t a r e a s a s o c i a d a s c o n c a d a celda, y los p r o d u c t o s d e t r a b a j o q u e p r : eirá c a d a t a r e a . Dichas a c t i v i d a d e s s e c o n s i d e r a n e n el c a p í t u l o 24.

21.4.2 Descomposición del proceso Un e q u i p o de s o f t w a r e d e b e t e n e r u n g r a d o significativo d e flexibilidad al elegir m o d e l o d e p r o c e s o d e s o f t w a r e q u e s e a m e j o r p a r a el p r o y e c t o y las t a r e a s de i"" niería del s o f t w a r e q u e i n t e g r e n el m o d e l o d e p r o c e s o u n a v e z elegido. Un pro" r e l a t i v a m e n t e p e q u e ñ o similar a o t r o s q u e s e h a y a n r e a l i z a d o p u e d e l o g r a r s e si s e utiliza el e n f o q u e s e c u e n c i a l lineal. Si s e i m p o n e n r e s t r i c c i o n e s d e t i e m p o c e ñ i d a s y el p r o b l e m a s e p u e d e c o m p a r t i m e n t a l i z a r m u c h o , tal v e z el m o d e l o de sarrollo r á p i d o de a p l i c a c i o n e s (DRA) s e a la o p c i ó n c o r r e c t a . Si la f e c h a límite e s c e ñ i d a q u e la f u n c i o n a l i d a d c o m p l e t a n o p u e d a a l c a n z a r s e , tal v e z s e a m e j o r u n a t r a t e g i a i n c r e m e n t a l . D e igual m o d o , los p r o y e c t o s c o n o t r a s c a r a c t e r í s t i c a s e j e m p l o , r e q u i s i t o s i n c i e r t o s , a v a n c e s e n la t e c n o l o g í a , c l i e n t e s difíciles, signi tivo p o t e n c i a l d e reutilización) c o n d u c i r á n a la s e l e c c i ó n de o t r o s m o d e l o s de ceso.5

TM

Una v e z e l e g i d o el m o d e l o d e p r o c e s o , el m a r c o d e t r a b a j o r e s p e c t i v o se a a él. En c u a l q u i e r c a s o s e p u e d e a p l i c a r el m a r c o d e t r a b a j o g e n é r i c o c o m e n t a d o

PDF Editor 4

Se debe destacar que las tareas de trabajo tienen que adaptarse a las necesidades específicas proyecto. 5 Recuérdese que las características del proyecto también tienen una fuerte influencia en la ra del equipo de software (sección 21.2.3).

CAPÍTULO 21


655

viamente: c o m u n i c a c i ó n , planificación, m o d e l a d o , c o n s t r u c c i ó n y despliegue. Funcionará para m o d e l o s lineales, iterativos e i n c r e m e n t a l e s , así c o m o evolutivos e inc l u s o p a r a m o d e l o s c o n c u r r e n t e s o d e e n s a m b l e d e c o m p o n e n t e s . El m a r c o d e trab a j o del p r o c e s o e s invariable y sirve c o m o b a s e p a r a t o do el t r a b a j o d e s o f t w a r e q u e realiza u n a organización de s o f t w a r e . Pero las t a r e a s d e t r a b a j o real varían. La d e s c o m p o s i c i ó n del p r o c e s o c o m i e n z a c u a n d o el g e r e n t e de proyecto pregunta: "¿Cómo l o g r a m o s esta actividad del m a r c o d e trabajo?". Por e j e m p l o , un proyecto p e q u e ñ o y r e l a t i v a m e n t e simple p u e d e requerir las s i g u i e n t e s t a r e a s d e t r a b a j o para la actividad d e c o m u n i c a c i ó n : 1. Desarrollar u n a lista d e conflictos q u e d e b e n clarificarse, 2.

Reunirse con los clientes p a r a a b o r d a r los conflictos q u e deben clarificarse.

3. Desarrollar en c o n j u n t o un e n u n c i a d o del ámbito. 4. Revisar el e n u n c i a d o del á m b i t o c o n t o d o s los implicados. 5.

Modificar el e n u n c i a d o del á m b i t o s e g ú n s e requiera.

Estos s u c e s o s p u e d e n ocurrir en un periodo m e n o r a 48 horas. R e p r e s e n t a n un proc e s o d e d e s c o m p o s i c i ó n a d e c u a d o p a r a el proyecto p e q u e ñ o y r e l a t i v a m e n t e simple. Ahora, c o n s i d é r e s e un p r o y e c t o m á s complejo, el cual tiene un á m b i t o m á s a m plio y un i m p a c t o comercial m á s significativo. Este proyecto p u e d e requerir las sig u i e n t e s t a r e a s d e t r a b a j o p a r a la actividad de c o m u n i c a c i ó n : 1. Revisar la petición del cliente. 2.

Planificar y p r o g r a m a r u n a reunión formal con el cliente.

3. Llevar a c a b o investigaciones p a r a especificar la solución p r o p u e s t a y los e n foques existentes. 4 . Preparar un " d o c u m e n t o d e trabajo" y u n a a g e n d a p a r a la reunión formal. 5. Celebrar la reunión. 6.

Desarrollar e n c o n j u n t o m i n i p r o s p e c t o s q u e reflejen los datos, función y características d e c o m p o r t a m i e n t o del s o f t w a r e . Alternativamente, s e desarrollan c a s o s d e u s o q u e describen al s o f t w a r e d e s d e el p u n t o d e vista del usuario.

7. Revisar c a d a m i n i p r o s p e c t o o c a s o d e u s o para valorar su corrección, consistencia y falta d e a m b i g ü e d a d . 8. 9-

E n s a m b l a r los m i n i p r o s p e c t o s en un d o c u m e n t o m á s amplio. TM Revisar el d o c u m e n t o m á s amplio o colección d e c a s o s d e u s o c o n t o d o s los

PDF Editor implicados.

10.

Modificar el d o c u m e n t o m á s amplio o c a s o s d e u s o s e g ú n s e requiera.

A m b o s proyectos realizan la actividad del m a r c o d e t r a b a j o que se llama " c o m u -

nicación", p e r o el p r i m e r equipo d e proyecto e f e c t u ó la mitad d e las t a r e a s d e traba-

jo d e ingeniería d e s o f t w a r e q u e realizó el s e g u n d o .

656

PARTE CUATRO

2 1 . 5


EL P R O Y E C T O La g e s t i ó n d e u n p r o y e c t o d e s o f t w a r e e x i t o s o r e q u i e r e e n t e n d e r q u é p u e d e salir rr all (de m o d o q u e s e a factible evitar los p r o b l e m a s ) . En un e x c e l e n t e artículo a c e r c a ó d p r o y e c t o s de s o f t w a r e , J o h n Reel [REE99] d e f i n e 10 s e ñ a l e s q u e indican q u e u n pr - ] y e c t o de s i s t e m a s d e i n f o r m a c i ó n e s t á e n peligro:

¿Cuáles son • las señales de que un proyecto de s o f t w a r e e s t á en peligro?

1. ^

El p e r s o n a l d e s o f t w a r e n o e n t i e n d e las n e c e s i d a d e s d e s u s clientes.

3. ^

Los c a m b i o s s e g e s t i o n a n mal.

5.

Las n e c e s i d a d e s c o m e r c i a l e s c a m b i a n [o e s t á n m a l d e f i n i d a s ] .

6.

Los p l a z o s de e n t r e g a n o s o n realistas.

7.

Los u s u a r i o s s e r e s i s t e n .

8.

Se p i e r d e el p a t r o c i n i o [o n u n c a s e o b t u v o de m a n e r a a d e c u a d a ] .

9.

El e q u i p o de p r o y e c t o c a r e c e de p e r s o n a l c o n las h a b i l i d a d e s a p r o p i a d a s .

10.

El á m b i t o del p r o d u c t o e s t á m a l definido.

La t e c n o l o g í a elegida c a m b i a .

Los g e s t o r e s [y los p r o f e s i o n a l e s ] e v i t a n las m e j o r e s p r á c t i c a s y las lecciones aprendidas.

Los p r o f e s i o n a l e s i n d u s t r i a l e s m u y e x p e r i m e n t a d o s c o n f r e c u e n c i a se refieren (rre-J dio f r i v o l a m e n t e ) a la regla 9 0 - 9 0 c u a n d o e s t u d i a n p r o y e c t o s d e s o f t w a r e particularm e n t e difíciles. El p r i m e r 90 p o r c i e n t o d e un s i s t e m a a b s o r b e el 90 p o r c i e n t o del e>-| f u e r z o y el t i e m p o a s i g n a d o s . El ú l t i m o 10 por c i e n t o t o m a el o t r o 90 p o r c i e n t o c a l e s f u e r z o y el t i e m p o a s i g n a d o s (ZAH94J. Las c a u s a s q u e c o n d u c e n a la regla del 9 ^ 1 9 0 e s t á n c o n t e n i d a s e n l a s s e ñ a l e s a n o t a d a s e n la lista p r e c e d e n t e . "No tenemos tiempo poro detenernos por combustible, yo vamos tarde." M. Clero' ¡Pero b a s t a de n e g a t i v i d a d ! ¿ C ó m o a c t ú a u n g e s t o r p a r a evitar los p r o b l e m a s re-j cién s e ñ a l a d o s ? Reel [REE99] s u g i e r e u n e n f o q u e de s e n t i d o c o m ú n de c i n c o p a r . e s j para proyectos de software: 1.

Comience

con el pie derecho.

E s t o s e logra t r a b a j a n d o d u r o (muy duro) p a r a

e n t e n d e r el p r o b l e m a q u e s e r á r e s u e l t o y e n t o n c e s e s t a b l e c eTM r o b j e t i v o s y exp e c t a t i v a s r e a l i s t a s p a r a t o d o s los q u e e s t a r á n i n v o l u c r a d o s e n el proyecto. Esto s e r e f u e r z a m e d i a n t e la c o n s t r u c c i ó n del e q u i p o c o r r e c t o (sección 21.2 3 I

PDF Editor

y al d a r l e al e q u i p o la a u t o n o m í a , a u t o r i d a d y t e c n o l o g í a n e c e s a r i o s p a r a hacer el t r a b a j o .

2.

Mantenga

el ímpetu.

M u c h o s p r o y e c t o s t i e n e n u n b u e n c o m i e n z o y l u e g o len

t a m e n t e s e d e s i n t e g r a n . Para m a n t e n e r el í m p e t u , el g e s t o r del p r o y e c t o d e b e p r o p o r c i o n a r i n c e n t i v o s p a r a c o n s e r v a r los r e v e s e s del p e r s o n a l e n u n míni-

CAPÍTULO 21


657

m o a b s o l u t o ; el e q u i p o d e b e r e s a l t a r la c a l i d a d e n c a d a t a r e a q u e realiza, y los g e s t o r e s e j e c u t i v o s d e b e h a c e r t o d o lo p o s i b l e p o r m a n t e n e r s e f u e r a del c a m i n o del e q u i p o . 6 3.

Rastree el progreso.

En u n p r o y e c t o d e s o f t w a r e el p r o g r e s o se r a s t r e a c o n f o r -

m e s e e l a b o r a n los p r o d u c t o s d e t r a b a j o (por e j e m p l o , m o d e l o s , c ó d i g o f u e n te, c o n j u n t o s d e c a s o s d e p r u e b a ) y s e a p r u e b a n ( m e d i a n t e r e v i s i o n e s t é c n i c a s f o r m a l e s ) c o m o p a r t e d e u n a act i vidad d e a s e g u r a m i e n t o de la calidad. Adem á s , s e p u e d e n recopilar y a p l i c a r p r o c e s o s del s o f t w a r e y m e d i d a s del p r o y e c t o (capítulo 22) p a r a v a l o r a r el p r o g r e s o c o n t r a los p r o m e d i o s e s t a b l e c i d o s p o r la o r g a n i z a c i ó n q u e d e s a r r o l l a s o f t w a r e . 4.

Tome decisiones

inteligentes.

En e s e n c i a , l a s d e c i s i o n e s del g e s t o r del p r o y e c t o

y del e q u i p o de s o f t w a r e d e b e n e n c a m i n a r s e a " m a n t e n e r l o simple". S i e m p r e q u e s e a posible, d e c í d a s e a e m p l e a r s o f t w a r e c o m e r c i a l ya d e s a r r o l l a d o o c o m p o n e n t e s d e s o f t w a r e e x i s t e n t e s , d e c í d a s e a evitar i n t e r f a s e s p e r s o n a l i z a d a s c u a n d o e s t é n d i s p o n i b l e s e n f o q u e s e s t á n d a r , d e c í d a s e a identificar y lueg o evitar r i e s g o s o b v i o s , y d e c í d a s e a a s i g n a r m á s t i e m p o q u e el q u e c o n s i d e r e n e c e s a r i o a las t a r e a s c o m p l e j a s o r i e s g o s a s ( n e c e s i t a r a c a d a m i n u to). 5.

Realice un análisis de resultados.

Establezca un m e c a n i s m o consistente para

e x t r a e r l e c c i o n e s a p r e n d i d a s p o r c a d a p r o y e c t o . E v a l ú e la planificación real y la prevista, r e c o l e c t e y a n a l i c e m é t r i c a s d e p r o y e c t o d e s o f t w a r e , o b t e n g a r e a l i m e n t a c i ó n d e los m i e m b r o s del e q u i p o y d e los c l i e n t e s , y registre los h a l l a z g o s en f o r m a escrita.

W

5

H H

En un e x c e l e n t e artículo a c e r c a d e los p r o c e s o s y p r o y e c t o s d e s o f t w a r e , Barry B o e h m [BOE96] e s t a b l e c e : "Usted n e c e s i t a un principio o r g a n i z a d o r q u e e s c a l e h a cia a b a j o p a r a p r o p o r c i o n a r p l a n e s [de proyecto) s i m p l e s p a r a p r o y e c t o s simples". B o e h m s u g i e r e u n e n f o q u e q u e a b o r d e los o b j e t i v o s del p r o y e c t o , los hitos y planificación, responsabilidades, gestión y enfoques técnicos y recursos requeridos. Boehm lo l l a m a el principio W 6 HH, e n h o n o r a u n a s e r i e d e p r e g u n t a s q u e c o n d u c e n a u n a d e f in ic ió n de l a s c a r a c t e r í s t i c a s c l a v e s del p r o y e c t o y al p l a n de p r o y e c t o r e s u l t a n t e : i ¿Cómo se definen los «titas i del o?

¿Por qué se desarrolla

el sistema?

La r e s p u e s t a a e s t a p r e g u n t a p e r m i t e a t o d a s l a s

TM

p a r t e s e v a l u a r la v a l i d e z d e las r a z o n e s del n e g o c i o p a r a el t r a b a j o de s o f t w a r e . Dic h o de otra f o r m a : ¿el p r o p ó s i t o del n e g o c i o justifica el g a s t o d e p e r s o n a l , t i e m p o y

PDF Editor dinero?

6

La implicación de este enunciado es que la burocracia se reduce al mínimo, las reuniones extrañas se eliminan y la adherencia dogmática a los procesos y reglas del proyecto se eliminan. El equipo debe ser autoorganizado y autónomo.

658

PARTE CUATRO


¿Qué se hará? La r e s p u e s t a a esta p r e g u n t a e s t a b l e c e el c o n j u n t o d e t a r e a s que i requerirá p a r a el proyecto. ¿Cuándo se hará? La r e s p u e s t a a e s t a pregunta a y u d a al e q u i p o a establecer i planificación del proyecto al identificar c u á n d o s e realizarán las t a r e a s del pro> y c u á n d o s e a l c a n z a r á n los objetivos. ¿Quién es el responsable

de una Junción? Párrafos a t r á s s e a n o t ó q u e el papel y i

responsabilidad de c a d a m i e m b r o del equipo de s o f t w a r e d e b e n e s t a r definidos, r e s p u e s t a a esta p r e g u n t a ayuda a lograrlo. ¿Dónde están ubicados en la organización?

No t o d o s los p a p e l e s y responsabilii

d e s residen en el equipo d e s o f t w a r e . El cliente, los u s u a r i o s y o t r o s participan!] t a m b i é n tienen responsabilidades. ¿Cómo se hará el trabajo desde los puntos de vista técnico y de gestión? Una vez i tablecido el á m b i t o del p r o d u c t o s e d e b e definir u n a estrategia d e gestión y técr para el proyecto. ¿Cuánto de cada recurso se necesita? La r e s p u e s t a a esta p r e g u n t a s e deriva al i sarrollar e s t i m a c i o n e s (capítulo 23) con base en las r e s p u e s t a s a las p r e g u n t a s ar riores. El principio WSHH d e Boehm s e aplica sin importar el t a m a ñ o o la complejidad de ; proyecto d e s o f t w a r e . Las p r e g u n t a s a n o t a d a s p r o p o r c i o n a n un excelente linearme to d e planificación para el gestor del proyecto y el equipo d e s o f t w a r e .

El Airlie Council 7 ha e l a b o r a d o u n a lista de "prácticas críticas d e s o f t w a r e para gestión b a s a d a en el d e s e m p e ñ o " . Dichas prácticas s o n " e m p l e a d a s consistenteme te por, y c o n s i d e r a d a s críticas por, p r o y e c t o s d e s o f t w a r e m u y exitosos y por orga z a c i o n e s cuya 'línea b a s e ' de d e s e m p e ñ o e s m u c h o m e j o r q u e los p r o m e d i o s de 1 industria" [AIR99]. Las prácticas críticas 8 incluyen: gestión d e proyecto b a s a d o en métricas (capítii 22), costo empírico y estimación d e la planificación (capítulos 2 3 y 24), seguimienti del valor g a n a d o (capítulo 24), gestión del riesgo formal (capítulo 25), seguimiento < d e f e c t o s f r e n t e a objetivos de calidad (capítulo 26) y gestión al tanto del person (sección 21.2). Cada u n a d e e s t a s prácticas criticas s e a b o r d a a loTM largo d e la p a r t e 1

d e e s t e libro.

PDF Editor 7

El Airlie Council es un equipo de expertos en ingeniería de software que reclutó el Departamento de |

Defensa de los Estados Unidos de América para ayudar a desarrollar lineamientos para mejores prácticas en la gestión de proyectos de software y de ingeniería del software.

8

Aquí sólo se anotan las prácticas críticas asociadas con la "integridad del proyecto".

CAPÍTULO 21

659



Herramientas de soítware para gestores de proyectos Las "herramientas" mencionadas aquí son ge-

herramienta tiene "calibradores" muy parecidos a un

néricas y se aplican a un amplio rango d e acti-

tablero y está implementada con Microsoft Excel. Está

s que realizan los gestores de proyecto. En los i capítulos se consideran herramientas d e gestión

disponible p a r a descarga en http://www.spmn.com/

i específicas (por ejemplo, herramientas d e

products_software.html. Ganlbead.com

ción, estimación, d e análisis d e riesgo).

nientas representativas 9 are Program Manager's Network (www.spmn.com)

ha desarrollado un conjunto d e útiles lisias

de verificación para gestores de proyecto que se puede descargar d e h t t p : / / w w w . g a n t t h e a d . c o m / . lttoolkit.com (www.ittoolkit.com) ofrece "una colección de

- c desarrollado una herramienta simple llamada Pror je-:' Control Panel q u e ofrece a los gestores d e proyec-

guías d e planificación, plantillas d e proceso y hojas de cálculo inteligentes" disponibles en CD-ROM.

l un aviso directo del estado del proyecto. La

La g e s t i ó n de p r o y e c t o s d e s o f t w a r e e s u n a actividad p r o t e c t o r a d e n t r o de la i n g e niería del s o f t w a r e . C o m i e n z a a n t e s d e iniciar c u a l q u i e r actividad t é c n i c a y c o n t i n ú a a lo l a r g o d e la definición, el d e s a r r o l l o y el s o p o r t e del s o f t w a r e d e c o m p u t a d o r a . Las c u a t r o P q u e t i e n e n u n a i n f l u e n c i a s u s t a n c i a l e n la g e s t i ó n de p r o y e c t o s de s o f t w a r e : p e r s o n a l , p r o d u c t o , p r o c e s o y p r o y e c t o . El p e r s o n a l d e b e e s t a r o r g a n i z a d o e n e q u i p o s eficientes, m o t i v a d o s p a r a h a c e r u n t r a b a j o d e s o f t w a r e de alta calidad y c o o r d i n a d o s p a r a lograr u n a c o m u n i c a c i ó n eficaz. Los r e q u i s i t o s del p r o d u c t o se deb e n c o m u n i c a r del cliente al d e s a r r o l l a d o r , s e r divididos ( d e s c o m p u e s t o s ) e n s u s p a r t e s c o n s t i t u t i v a s y distribuirse p a r a q u e t r a b a j e el e q u i p o d e s o f t w a r e . El p r o c e s o d e b e a d a p t a r s e al p e r s o n a l y al p r o b l e m a . Se s e l e c c i o n a un m a r c o de t r a b a j o d e p r o c e s o c o m ú n , s e a p l i c a u n p a r a d i g m a de i n g e n i e r í a de s o f t w a r e a d e c u a d o y s e elige u n c o n j u n t o d e t a r e a s d e t r a b a j o p a r a llevar a c a b o el t r a b a j o . F i n a l m e n t e , el p r o y e c t o d e b e e s t a r o r g a n i z a d o e n u n a f o r m a q u e p e r m i t a t r i u n f a r al e q u i p o d e s o f t w a r e . El e l e m e n t o c e n t r a l e n t o d o s los p r o y e c t o s d e s o f t w a r e e s el p e r s o n a l . Los i n g e n i e r o s d e s o f t w a r e p u e d e n o r g a n i z a r s e e n d i f e r e n t e s e s t r u c t u r a s de e q u i p o , q u e v a n d e s d e l a s j e r a r q u í a s d e control t r a d i c i o n a l e s h a s t a los e q u i p o s d e " p a r a d i g m a a b i e r to". Se p u e d e n aplicar v a r i a s t é c n i c a s d e c o o r d i n a c i ó n y c o m u n i c a c i ó n p a r a a p o y a r el t r a b a j o del e q u i p o . En g e n e r a l , las r e v i s i o n e s f o r m a l e s y la c o m u n i c a c i ó n i n f o r m a l d e p e r s o n a a p e r s o n a s o n las m á s v a l i o s a s p a r a los p r o f e s i o n a l e s .

TM

La a c tivi dad de g e s t i ó n del p r o y e c t o a b a r c a m e d i d a s y m é t r i c a s , e s t i m a c i ó n y p l a nificación, a n á l i s i s d e riesgos, s e g u i m i e n t o y c o n t r o l . C a d a u n o d e e s t o s t ó p i c o s s e

PDF Editor c o n s i d e r a e n los c a p í t u l o s s i g u i e n t e s .

9

Las herramientas registradas aquí son una muestra de esta categoría. En la mayoría de los casos los

nombres de las mismas son marcas registradas p e - s u s respectivos desarrolladores.

660

PARTE CUATRO


[AIR99] Airlie Council, " P e r f o r m a n c e Based M a n a g e m e n t : T h e Program M a n a g e r ' s Guide Bas o n the 16-Point Plan and Related Metrics", Drañ Report, 8 de m a r z o , 1999. [BAK72] Baker, F. T„ "Chief P r o g r a m m e r Team M a n a g e m e n t of Production Programming", i IBM Systems Journal, vol. 11, n ú m . I, 1972, pp. 56-73. [BOE96] Boehm, B., "Anchoring the S o f t w a r e Process", e n IEEE Sojbvare, vol. 13, n ú m . 4, de 1996, pp. 73-82. [COCO 1 ] Cockburn, A. y J. Highsmith, "Agile S o f t w a r e Development: The People Factor", e n /£ Computer, vol. 34, n ú m . 11, n o v i e m b r e de 2001, pp. 131-133. [CON93] Constantine, L„ "Work Organization: Paradigms for Project M a n a g e m e n t a n d Orga zation", e n CACM, vol. 36, n ú m . 10, octubre d e 1993, pp. 34-43. [COU8O] Cougar, J. y R. Zawacki, Managing and Motivating Computer Personnel, Wiley, 1980. [CUR88] Curtís, B. el al., "A Field Study of the Software Design Process for Large Systems", ¡EEETrans. Sojlware Engineering, vol. SE-31, n ú m . 11, n o v i e m b r e d e 1988, pp. 1268-1287 [CUR94] Curtís, B. el al., People Management Capability Maturity Model, S o f t w a r e Engineering I titute, 1994. [DEM98] DeMarco, T. y T. Lister, Peopleware, 2a. ed., Dorset House, 1998. [EDG95] E d g e m o n , ) . , "Right Stuff: How to Recognize It W h e n Selecting a Project M a n a g e r i Application Development Trends, vol. 2, n ú m . 5, m a y o d e 1995, pp. 37-42. [FER98] Ferdinandi, P. L„ "Facilitating Communication", e n IEEE Sofhvare, s e p t i e m b r e de 1S pp. 92-96. UAC98] J a c k m a n , M„ " H o m e o p a t h i c R e m e d i e s for Team Toxicity", e n IEEE Sojlware, julio 1998, pp. 43-45. IKRA95] Kraul, R. y L. Streeter, "Coordination in S o f t w a r e Development", e n CACM, vol. 38, nú 3, m a r z o d e 1995, pp. 69-81. [MAN81J Mantei, M„ "The Effect of P r o g r a m m i n g T e a m Structures o n P r o g r a m m i n g Tasks" i CACM, vol. 24, n ú m . 3, m a r z o d e 1981, pp. 106-113. [PAG85] Page-Jones, M., Practical Project Management, Dorset House, 1985, p. vii. [REE99] Reel, J. S., "Critical S u c c e s s Factors in S o f t w a r e Projects", en IEEE Sojlware, m a y o 1999, pp. 18-23. [WE186] Weinberg, G., On Becoming a Technical Leader, Dorset House, 1986. [WIT94] Whitaker, K., Managing Sojhvare Maniacs, Wiley, 1994. [ZAH94] Zahniser, R., "Timeboxing for Top Team Performance", e n Sojlware Development, i z o d e 1994, pp. 35-38.

21.1. Con b a s e en la información c o n t e n i d a en este capitulo y la experiencia propia, d e s a r llar "10 m a n d a m i e n t o s " para a l e n t a r el potencial de los ingenieros d e s o f t w a r e . Esto es: ela rar u n a lista d e 10 lincamientos q u e c o n d u c i r á n al personal q u e desarrolla s o f t w a r e a ejercer s potencial completo. 21.2. El m o d e l o de m a d u r e z de la c a p a c i d a d de gestión de personal (MMCGP) del Software I gineering Institute realiza u n estudio o r g a n i z a d o de las "áreas prácticas clave" (APC) q u e i va el b u e n personal d e s o f t w a r e . El instructor a s i g n a r á u n a APC para analizar TM y resumir. 21.3. Describir tres situaciones d e la vida real e n las c u a l e s el cliente y el usuario final son < mismo. Describir tres situaciones e n las c u a l e s s o n diferentes.

PDF Editor

21.4. Las decisiones q u e t o m a n l o s g e s t o r e s ejecutivos p u e d e n t e n e r u n i m p a c t o significati en la eficacia d e u n equipo de ingeniería del s o f t w a r e . Proporcionar cinco e j e m p l o s q u e ilusti q u e e s t o e s cierto. 2 1 . 5 . Repasar el libro de Weinberg [WEI86] y escribir un r e s u m e n d e d o s o tres p á g i n a s de tópicos q u e d e b e n c o n s i d e r a r s e al aplicar el m o d e l o MOI.

CAPÍTULO 21

C O N C E P T O S D E GEETIC Í Í D - : Í R ; Y B — O S

661

21.6. Usted ha s i d o n o m b r a d o g e s t o r d e p r o y e c t o d e n t r o d e u n a o r g a n i z a c i ó n d e s i s t e m a s d e i n f o r m a c i ó n . Su l a b o r e s c o n s t r u i r u n a a p l i c a c i ó n q u e s e a b a s t a n t e similar a o t r a s q u e h a c o n s truido su e q u i p o , a u n q u e é s t a e s m a y o r y m á s c o m p l e j a . El cliente h a d o c u m e n t a d o a m p l i a m e n te los r e q u i s i t o s . ¿ Q u é e s t r u c t u r a d e e q u i p o elegiría y p o r q u é ? ¿ Q u é m o d e l o ( s ) d e p r o c e s o d e s o f t w a r e elegiría y p o r q u é ? 21.7. Usted h a s i d o n o m b r a d o g e s t o r d e p r o y e c t o e n u n a p e q u e ñ a c o m p a ñ í a d e p r o d u c t o s d e s o f t w a r e . Su l a b o r e s c o n s t r u i r u n p r o d u c t o d e a v a n z a d a q u e c o m b i n e h a r d w a r e d e realidad virtual c o n s o f t w a r e d e ú l t i m a g e n e r a c i ó n . P u e s t o q u e la c o m p e t e n c i a e n el m e r c a d o del e n t r e t e n i m i e n t o c a s e r o e s i n t e n s a , e x i s t e u n a p r e s i ó n significativa p a r a c o m p l e t a r el t r a b a j o . ¿ Q u é e s t r u c t u r a d e e q u i p o elegiría y p o r q u é ? ¿ Q u é m o d e l o ( s ) d e p r o c e s o d e s o f t w a r e elegiría y p o r q u é ? 2 1 . 8 . Usted h a s i d o n o m b r a d o g e s t o r d e p r o y e c t o e n u n a g r a n c o m p a ñ í a d e p r o d u c t o s d e s o f t w a r e . S u l a b o r e s g e s t i o n a r el d e s a r r o l l o d e la v e r s i ó n d e s i g u i e n t e g e n e r a c i ó n d e su s o f t w a r e d e p r o c e s a m i e n t o d e t e x t o s a m p l i a m e n t e utilizado. P u e s t o q u e s e d e b e n g e n e r a r n u e v o s i n g r e s o s , s e h a n e s t a b l e c i d o y a n u n c i a d o f e c h a s límite p r e c i s a s . ¿ Q u é e s t r u c t u r a d e e q u i p o elegiría y p o r q u é ? ¿ Q u é m o d e l o ( s ) d e p r o c e s o d e s o f t w a r e elegiría y p o r q u é ? 21.9. Usted h a s i d o n o m b r a d o g e s t o r d e p r o y e c t o d e s o f t w a r e p a r a u n a c o m p a ñ í a q u e a t i e n d e al m u n d o d e la i n g e n i e r í a g e n é t i c a . Su l a b o r e s g e s t i o n a r el d e s a r r o l l o d e u n n u e v o p r o d u c t o d e s o f t w a r e q u e a c e l e r a r á el r i t m o d e la clasificación d e g e n e s . El t r a b a j o e s t á o r i e n t a d o l+D, p e r o la m e t a e s e l a b o r a r u n p r o d u c t o d e n t r o del s i g u i e n t e a ñ o . ¿ Q u é e s t r u c t u r a d e e q u i p o elegiría y p o r q u é ? ¿ Q u é m o d e l o ( s ) d e p r o c e s o d e s o f t w a r e elegiría y p o r q u é ? 2 1 . 1 0 . A u s t e d s e le pide d e s a r r o l l a r u n a p e q u e ñ a a p l i c a c i ó n q u e a n a l i c e l o s c u r s o q u e o f r e c e u n a u n i v e r s i d a d y r e p o r t e la calificación p r o m e d i o o b t e n i d a e n el c u r s o (para u n p e r i o d o d e t e r m i n a d o ) . Escriba u n e n u n c i a d o del á m b i t o q u e a b a r c a e s t e p r o b l e m a . 2 1 . 1 1 . Realice u n a d e s c o m p o s i c i ó n f u n c i o n a l d e p r i m e r nivel d e la f u n c i ó n plantilla d e p á g i n a t r a t a d a b r e v e m e n t e e n la s e c c i ó n 21.3.2.

OTRAS L E C T U R A S Y F U E N T E S P E INFORMACIÓN El Project M a n a g e m e n t Institute ( G u i d e t o the Project Management Body ofKnowledge, PMI, 20011 c u b r e t o d o s los a s p e c t o s i m p o r t a n t e s d e la g e s t i ó n d e p r o y e c t o s . Murch (Project Management Best Practicesfor IT Professionals, Prentice-Hall, 2000) e n s e ñ a h a b i l i d a d e s b á s i c a s y p r o p o r c i o n a u n a g u í a d e t a l l a d a p a r a t o d a s l a s f a s e s d e u n p r o y e c t o d e TI. L e w i s (Project Managers Desk Re ference, McGraw-Hill, 1999) p r e s e n t a u n p r o c e s o d e 16 p a s o s p a r a planificar, s u p e r v i s a r y c o n trolar c u a l q u i e r tipo d e p r o y e c t o . M c C o n n e l l (ProfessionaI Software Development, Addison-Wesley, 2004) o f r e c e c o n s e j o s p r a g m á t i c o s p a r a "lograr p l a n e s m á s c o r t o s , p r o d u c t o s d e m a y o r c a lidad y p r o y e c t o s m á s e x i t o s o s " . U n a e x c e l e n t e s e r i e d e c u a t r o v o l ú m e n e s e s c r i t o s p o r W e i n b e r g (Quality Software Management, D o r s e t H o u s e , 1 9 9 2 , 1 9 9 3 , 1 9 9 4 , 1 9 9 6 ) i n t r o d u c e c o n c e p t o s b á s i c o s d e p e n s a m i e n t o y g e s tión d e s i s t e m a s ; explica c ó m o u s a r m e d i c i o n e s e f e c t i v a m e n t e ; y a b o r d a la " a c c i ó n c o n g r u e n te", la h a b i l i d a d d e e s t a b l e c e r " a c o p l a m i e n t o " e n t r e las n e c e s i d a d e s del gestor, las n e c e s i d a d e s d e l e q u i p o t é c n i c o y l a s n e c e s i d a d e s del n e g o c i o . El libro b r i n d a r á i n f o r m a c i ó n útil a los g e s t o r e s t a n t o n u e v o s c o m o e x p e r i m e n t a d o s . Futrell y s u s c o l e g a s (Quality Software Project Manage ment, Prentice-Hall, 2002) p r e s e n t a n u n v o l u m i n o s o t r a t a m i e n t o d e la g e s t i ó n d e p r o y e c t o s . Phillips (IT Project Management: On TTack f,rom Start to Finish, M c G r a w - HTM i l l / O s b o r n e , 2002). C h a r v a t {Project Management Nation, Wiley, 2002), S c h w a l b e ( I n f o r m a t i o n Technology Project Ma nagement, 2 a . ed., C o u r s e Technology, 2001) y H o l t s n i d e r y Jaffe {ITManager's Handbook, Morg a n K a u f m a n n P u b l i s h e r s , 2000) s o n r e p r e s e n t a t i v o s d e l o s m u c h o s libros q u e s e h a n e s c r i t o a c e r c a d e la g e s t i ó n d e p r o y e c t o s d e s o f t w a r e . B r o w n y s u s c o l e g a s (AntiPatterns in Project Ma nagement, Wiley, 2000) e x a m i n a n q u é n o h a c e r d u r a n t e la g e s t i ó n d e u n p r o y e c t o d e s o f t w a r e . B r o o k s (The Mythical Man-Month, A n n i v e r s a r y Edition, A d d i s o n - W e s l e y , 1995) h a a c t u a l i z a d o s u libro c l á s i c o p a r a o f r e c e r u n a n u e v a visión e n l o s t e m a s d e p r o y e c t o d e s o f t w a r e y g e s tión. McConnell (Software Project Surviva! Cuide, Microsoft Press, 1997) p r e s e n t a u n a e x c e l e n t e guía p r a g m á t i c a p a r a q u i e n e s d e b e n g e s t i o n a r p r o y e c t o s d e s o f t w a r e . P u r b a y S h a h (How to Ma-

PDF Editor

662

PARTE CUATRO


nage a Successful Software Project, 2a. ed., Wiley, 2000) p r e s e n t a n varios c a s o s de estudio que indican por qué algunos proyectos tienen éxito y otros fracasan. Bennatan (On Time Within Budgel, 3a. ed., Wiley, 2000) presenta sugerencias y lincamientos útiles para gestores de proyectos de software. Se p u e d e a r g u m e n t a r que el aspecto m á s importante de la gestión de proyectos de software es la gestión de personal. Cockburn {Agüe Software Development, Addison-Wesley, 2002) presenta u n o d e los m e j o r e s análisis del personal d e software escrito hasta la fecha. DeMarco y Lister [DEM98] h a n escrito el libro definitivo acerca del personal d e software y los proyectos respectivos Además, en a ñ o s recientes se h a n publicado los siguientes libros en esta materia y vale la pena examinarlos: Beaudouin-Lafon, M., Computer Supported

Cooperative Work, Wiley-Liss, 1999.

Carmel, E., Global Software Teams: Collaborating Across Borders and Time Zones, Prentice Hall. 1999. Constantine, L., Peopleware Papers: Notes on the Human Side of Software, Prentice-Hall, 2001 Humphrey, W. S„ Managing Technical People: Innovation, Teamwork and the Software Process. Addison-Wesley, 1997. Humphrey, W. S., Introduction Jones, P. H„ Handbook ofTeam McGraw-Hill, 1997.

to the Team Software Process, Addison-Wesley, 1999. Design: A Practitioner's Guide to Team Systems Development,

Karolak, D. S„ Global Software Development: Managing Virtual Teams and Environments, Computer Society, 1998.

IEEE

Ensworth (The Accidental Project Manager, Wiley, 2001) ofrece p r o f u s a m e n t e guías útiles a quienes d e b e n sobrevivir "la transición d e técnico a gestor d e proyecto". Otro excelente libro ce Weinberg [WE186] es u n a lectura obligada para todo gestor de proyecto y todo líder d e equipe Este libro le brindará el conocimiento y la guía que le permitirán h a c e r su trabajo de manera m á s eficiente. Aun c u a n d o no se relacionan específicamente con el m u n d o del software, y en ocasiones sobresimplifican y generalizan e n extremo, los libros de "gestión" m á s vendidos de Bossidy (£>.e cution: The Discipline of Getting Things Done, Crown Publishing, 2002), Drucker (Managemer: Challengesfor the 2lst Century, Harper Business, 1999), Buckingham y Coffman (First, Break.-S the Rules: What the World's Greatest Managers Do Differently, Simón and Schuster, 1999) y Christensen (The Innovator's Dilemma, Harvard Business School Press, 1997) resaltan "nuevas reglas 1 que define u n a economía rápidamente cambiante. Los títulos viejos c o m o Who Moved My Chcr se?, The One-Minule Manager e In Search ofExcelience continúan ofreciendo valiosa información que p u e d e n ayudarle a gestionar p e r s o n a s y proyectos d e m a n e r a m á s eficaz. En Internet está disponible una amplia variedad de fuentes d e información acerca d e la gestión d e proyectos de software. Una lista actualizada de referencias en la World Wide Web se encuentra en el sitio Web de SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P Í T U L O

M É T R I C A S DE P R O C E S O Y PROYECTO CEPTOS

STE . . . .677

"o

L

22

a medición permite o b t e n e r una visión del proceso y el proyecto p u e s proporciona un m e c a n i s m o para lograr u n a evaluación objetiva. Lord Kelvin dijo u n a vez:

C u a n d o p u e d e m e d i r a q u e l l o d e lo q u e e s t á h a b l a n d o y e x p r e s a r l o e n n ú m e r o s s a b e

. . .679

a l g o a c e r c a d e ello; p e r o c u a n d o n o p u e d e m e d i r , c u a n d o n o p u e d e e x p r e s a r l o en n ú -

667

m e r o s , s u c o n o c i m i e n t o e s e s c a s o , d e f i c i e n t e p u e d e s e r el c o m i e n z o del c o n o c i m i e n to, p e r o , e n s u s p e n s a m i e n t o s , a p e n a s e s t á a v a n z a d o al á m b i t o d e la c i e n c i a .

...676

..674 .667

.670

..673

al . . .669

...666 . . . .666 ..674 de

.684

La c o m u n i d a d de la ingeniería del s o f t w a r e ha t o m a d o en serio las palabras de lord Kelvin ¡Mas no sin frustración y algo más que un p o c o de controversia! La medición se aplica al proceso de software con la finalidad de mejorarlo de m a n e r a continua. La medición se utiliza a lo largo de un proyecto de s o f t w a r e c o m o apoyo en la estimación, el control de calidad, la valoración de la productividad y el control del proyecto. Finalmente, la medición la aplican los ingenieros de software c o m o auxiliar en la evaluación de la calidad de los productos de trab a j o y para apoyar la toma de decisiones táctica c o n f o r m e avanza u n proyecto (capítulo 15). En su guía acerca de la medición de software, Park, Goethert y Florac [PAR96: a p u n t an las r a z o n e s p o r las que se mide: 1) para caracterizaren un e s f u e r z o por c o m p r e n d e r acerca "de los procesos, productos, recursos y entornos, y para establecer líneas b a s e p a r a c o m p a r a c i o n e s con e v a l u a c i o n e s futuras"; 2) para evaluar "determinando el e s t a d o con respecto a los planes"; 3) para predecir mediante "la comprensión de relaciones entre p r o c e s o s y productos y construir mo-

¿ Q u é e s ? El proceso de software y las métricas del proyecto son medidas cuantitativas que permiten a los ingenieros de software obtener una visión de la eficacia del proceso de oftware y los proyectos que llevan a cabo utilizando e! proceso como marco de trabajo. Se ecopilan datos básicos de calidad y productividad. Luego dichos datos se analizan, comparan :on promedios pasados y valoran para determinar si han ocurrido mejoras en la calidad y la productividad. Las métricas también se emplean para marcar las áreas problema de modo que se ouedan desarrollar remedios y mejorar el proceso de software.

¿ Q u i é n lo h o c e ? Los gestores de software analizan y evalúan las métricas del software. Con frecuencia, los ingenieros ele software recopilan las medidas. ¿ P o r q u é e s i m p o r t a n t e ? Si no se realizan mediciones el juicio sólo se basa en evaluación subjetiva. La medición permite- destacar las tendencias (ya sean buenas o malas) y hacer mejoTM res estimaciones, y con el tiempo se puede lograr una verdadera mejoría. ¿ C u á l e s s o n los p a s o s ? Se comienza definiendo un conjunto limitado de medidas del proceso y del proyecto que puedan recopilarse con facilidad Dichas medidas por io general sé normalizan emplenado métricas orientadas al tamaño

PDF Editor

663

PARTE CUATRO

664


o la función. El resultado se analiza y compara con promedios pasados para proyectos similares realizados dentro de la organización. Se valoran las tendencias y se generan conclusiones H H r a | | ¿Cuál e s el p r o d u c t o o b t e n i d o ? Un conjunto de métricas del software que proporcionan

amplia visión del proceso y un conocimiento detallado acerca del proyecto. ¿ C ó m o p u e d o e s t a r s e g u r o d e q u e lo h e h e c h o c o r r e c t a m e n t e ? Al aplicar un esquema de medición consistente pero simple con el cual no se valora, recompensa o castiga el desempeño individual. «MlllS

délos de dichas relaciones"; y 4) para mejorar al "identificar barricadas, c a u s a s raí; I ineficiencias y otras oportunidades para mejorar la calidad del producto y el deserr-j p e ñ o del p r o c e s o " . La medición es una herramienta de gestoría. Si se lleva a c a b o adecuadamente proporciona visión al gestor del proyecto. Y, c o m o resultado, apoya al gestor del pro-l yecto y al equipo de s o f t w a r e a t o m a r decisiones que conducirán a un proyecto ex.-| toso. 22.1

M É T R I C A S E N L O S D O M I N I O S DEL P R O C E S O Y EL P R O Y E C T O Las métricas del proceso se recopilan en el curso de todos los proyectos y durante !a:-l

\ CLAVE Los métricos del proceso tienen impocto o largo plazo. Su objetivo es mejorar el proceso en sí. Con frecuencia, las métricas del proyecto contribuyen al desarrollo de métricos del proceso.

gos periodos. Su objetivo es proporcionar un conjunto de indicadores de proceso q u a c o n d u z c a n a la mejora de los procesos de s o f t w a r e de largo plazo. Las métricas tiJ proyecto permiten que un gestor de proyecto de software 1) valore el e s t a d o de - n i proyecto en curso; 2) rastree los riesgos potenciales; 3) descubra las á r e a s problema a n t e s de que se vuelvan "críticas"; 4) ajuste el flujo de trabajo o las tareas, y 5) evalúe la habilidad del equipo del proyecto para controlar la calidad de los productos : a trabajo del software. Las m e d i d a s que recopila un equipo de proyecto y las que convierte en métricas para emplearlas durante un proyecto también se p u e d e n transmitir a quienes t i e n e s ! la responsabilidad de mejorar el proceso de software. Por esta razón, m u c h a s de i d m i s m a s métricas se u s a n t a n t o en el dominio del proceso c o m o en el del proyecto i

22.1.1 Métricas del proceso y mejora del proceso d e software La única forma racional de mejorar cualquier p r o c e s o es medir s u s atributos e s p e d í fieos, desarrollar un conjunto de métricas significativas con b a s e en dichos a t r i b u t a s y luego emplear las métricas para ofrecer indicadores que conducirán TM a una estra:e-j gia de mejora. Pero a n t e s de estudiar las métricas de s o f t w a r e y su impacto en la rre-l jora del proceso de s o f t w a r e es importante d e s t a c a r que el p r o c e s o sólo es u n o ral

PDF Editor

varios "factores controlables en la mejora de la calidad del s o f t w a r e y el d e s e m p e - d organizacional" [PAU94], En la figura 22.1 el proceso se asienta en el centro de un triángulo que conecta

tres factores con una profunda influencia en la calidad del s o f t w a r e y el d e s e m p e - »

organizacional. La destreza y la motivación del personal [BOE81] se m u e s t r a n c o i r :

CAPITULO 22

"ites la calidad software y la 'a acional ado de D-

MÉTRICAS

665

DE PROCESO Y PROYECTO

Producto

Características

Condiciones

d e l cliente

del n e g o c i o

Personal

Tecnología

el factor individual m á s influyente en la calidad y el d e s e m p e ñ o . La complejidad del producto puede tener un impacto sustancial sobre la calidad y el d e s e m p e ñ o del equipo. La tecnología (es decir, los m é t o d o s y h e r r a m i e n t a s de la ingeniería del software) que reside en el p r o c e s o t a m b i én tiene un impacto. Además, el triángulo de p r o c e s o existe d e n t r o de un círculo de condiciones a m bientales que incluyen el e n t o r n o de desarrollo (por ejemplo, herramientas CASE), condiciones del negocio (por ejemplo, fechas límite, reglas comerciales) y características del cliente (por ejemplo, facilidad de comunicación y colaboración). La eficacia de un proceso de s o f t w a r e se mide indirectamente. Esto es, se d e d u c e

CLAVE y del de software el trabajo factores más ¡que en la calidad

un c o n j u n t o de métricas b a s a d a s en los resultados que se derivan del proceso. Los resultados incluyen m e d i d a s de errores descubiertos a n t e s de liberar el software, los defectos que detectan y reportan los usuarios finales, los productos de trabajo entreg a d o s (productividad), el e s f u e r z o h u m a n o gastado, el tiempo de la planificación consumido, concordancia con la planificación y otras medidas. También se deducen métricas de proceso al medir las características de t a r e a s específicas de ingeniería del software. Por ejemplo, se mide el e s f u e r z o y el tiempo utilizados al realizar las actividades genéricas de la ingeniería del s o f t w a r e descritas en el capítulo 2. TM "Las métricas de software le permiten conocer cuándo reír y cuándo llorar."

PDF Editor

Grady [GRA92] a r g u m e n t a que existen u s o s "privados y públicos" para diferentes

tipos de datos de proceso. C o m o e s natural que los ingenieros de s o f t w a r e especiales sean sensibles al uso de las métricas recopiladas sobre una b a s e particular, di-

666

7 ¿Cuáles • la diferencia e n t r e usos privados y públicos de las métricas de software?

PARTE CUATRO

GESTIÓN DE P R O Y E C T O S DE SOFTWARE

c h o s d a t o s d e b e n s e r p r i v a d o s p a r a el individuo y f u n c i o n a r c o m o u n i n d i c a d o r s o l : p a r a él. Los e j e m p l o s d e métricas privadas

i n c l u y e n í n d i c e s d e d e f e c t o p o r individúe.

í n d i c e s d e d e f e c t o p o r c o m p o n e n t e d e s o f t w a r e y e r r o r e s e n c o n t r a d o s d u r a n t e el desarrollo. La filosofía d e " d a t o s d e p r o c e s o privados" s e a j u s t a bien al e n f o q u e de p r o c e s o pes o n a l del s o f t w a r e (capítulo 2) q u e p r o p o n e H u m p h r e y [HUM95]. H u m p h r e y r e c o n o c e q u e la m e j o r a e n el p r o c e s o d e s o f t w a r e p u e d e y d e b e c o m e n z a r e n el nivel i n d i v i d u a . Los d a t o s d e p r o c e s o p r i v a d o s p u e d e n f u n c i o n a r c o m o u n i m p o r t a n t e p r o m o t o r para q u e el t r a b a j o individual del i n g e n i e r o d e s o f t w a r e m e j o r e . A l g u n a s m é t r i c a s d e p r o c e s o s o n p r i v a d a s p a r a el e q u i p o del p r o y e c t o d e s o f t w a re, p e r o p ú b l i c a s p a r a t o d o s los m i e m b r o s del e q u i p o . Los e j e m p l o s incluyen defect o s q u e r e p o r t a n l a s g r a n d e s f u n c i o n e s de s o f t w a r e (las c u a l e s d e s a r r o l l a r o n vari :< p r o f e s i o n a l e s ) , e r r o r e s d e t e c t a d o s d u r a n t e l a s r e v i s i o n e s t é c n i c a s f o r m a l e s y líneas d e c ó d i g o o p u n t o s d e f u n c i ó n p o r m ó d u l o o función. 1 Dichos d a t o s los revisa ei equipo para descubrir indicadores que mejoren su desempeño. Las m é t r i c a s p ú b l i c a s p o r lo g e n e r a l a s i m i l a n i n f o r m a c i ó n q u e o r i g i n a l m e n t e era p r i v a d a p a r a los i n d i v i d u o s y e q u i p o s . Los í n d i c e s d e d e f e c t o al nivel del p r o y e c : : (que n o s e a t r i b u y e n por n i n g ú n m o t i v o a u n individuo), e s f u e r z o , p l a n i f i c a c i ó n y cat o s r e l a c i o n a d o s s e r e c o p i l a n y e v a l ú a n c o n la finalidad d e d e s c u b r i r i n d i c a d o r e s que p u e d e n m e j o r a r el d e s e m p e ñ o del p r o c e s o o r g a n i z a c i o n a l . Las m é t r i c a s del p r o c e s o de s o f t w a r e o f r e c e n b e n e f i c i o s significativos c o n f o r m e u n a o r g a n i z a c i ó n t r a b a j a e n m e j o r a r s u g r a d o global de m a d u r e z del p r o c e s o . S:r e m b a r g o , c o m o t o d a s las m é t r i c a s , é s t a s p u e d e n e m p l e a r s e m a l y c r e a r m á s problem a s de los q u e s o l u c i o n a n . Grady [GRA92] s u g i e r e un " c o n j u n t o d e r e g l a s de etíqueva p a r a l a s m é t r i c a s de s o f t w a r e " , a d e c u a d o t a n t o p a r a g e s t o r e s c o m o p a r a p r o f e s i o n a les c o n f o r m e instituyen u n p r o g r a m a d e m é t r i c a s del p r o c e s o : • Aplique s e n t i d o c o m ú n y s e n s i b i l i d a d o r g a n i z a t i v a c u a n d o i n t e r p r e t e d a t o s

9|¿Q«é * lineamientos s e deben aplicar cuando se recopilan métricas de s o f t w a r e ?

métricos. • O f r e z c a r e t r o a l i m e n t a c i ó n r e g u l a r a los i n d i v i d u o s y e q u i p o s q u e r e c o p i l a n medidas y métricas. • N o utilice las m é t r i c a s p a r a e v a l u a r a los individuos. • T r a b a j e c o n l o s p r o f e s i o n a l e s y e q u i p o s p a r a e s t a b l e c e r m e t a s c l a r a s y l a s mét r i c a s q u e se e m p l e a r á n p a r a c o n s e g u i r l a s . • N u n c a u s e m é t r i c a s p a r a a m e n a z a r a los i n d i v i d u o s o e q u i p oTM s. • Los d a t o s m é t r i c o s q u e i n d i c a n u n a á r e a p r o b l e m a n o d e b e n c o n s i d e r a r s e

PDF Editor

"negativos". Dichos d a t o s s ó l o s o n u n i n d i c a d o r d e la m e j o r a del p r o c e s o .

• No se o b s e s i o n e c o n u n a sola m é t r i c a y excluya o t r a s m é t r i c a s i m p o r t a n t e s

1

Las métricas de lineas de código y punto de función se estudian en las secciones 22.2.1 y 22.2.2

CAPÍTULO 22

M É T R I C A S DE P R O C E S O Y P R O Y E C T O

667

Conforme u n a organización se siente m á s c ó m o d a con la recopilación y el e m p l e o de las métricas de proceso, la deducción de indicadores simples da la p a u t a para un e n f o q u e m á s riguroso llamado mejora estadística del proceso de software (MEPS). En esencia, el MEPS aplica el análisis de falla de software para recopilar información acerca de t o d o s los errores y defectos 2 que se e n c u e n t r a n al desarrollar y utilizar u n a aplicación, sistema o producto.

22.1.2 Métricas del proyecto A diferencia de las métricas del proceso de software que se utilizan con propósitos estratégicos, las métricas del proyecto de s o f t w a r e son tácticas. Es decir, u n gerente de proyecto y un equipo de s o f t w a r e e m p l e a n las métricas del proyecto y los indicadores que se d e d u c e n de ellas para adaptar el flujo de trabajo del proyecto y las actividades técnicas. La primera aplicación de las métricas del proyecto en la mayoría de los proyectos de s o f t w a r e ocurre d u r a n t e la estimación. Las métricas recopiladas de los proyectos previos se aprovechan c o m o b a s e d e s d e la cual se realizan estimaciones de esfuerzo y tiempo para el trabajo de s o f t w a r e actual. Conforme el proyecto a v a n z a , la m e didas de e s f u e r z o y tiempo utilizados se c o m p a r a n con las estimaciones originales (y la planificación del proyecto). El gestor del proyecto emplea dichos d a t o s para supervisar y controlar el progreso. Mientras c o m i e n z a el trabajo técnico, las otras métricas del proyecto c o m i e n z a n a tener significado. Se miden los índices de producción r e p r e s e n t a d o s e n términos de modelos creados, h o r a s de revisión, puntos de función y líneas fuente entregadas. Además, se les da seguimiento a los errores descubiertos durante cada tarea de ingeniería del software. Conforme el software evoluciona d e s d e los requisitos hasta el diseño, se recopilan métricas técnicas para valorar la calidad del diseño y mejorar los indicadores que influirán en el e n f o q u e que se adopte para la generación y prueba del código. Cómo se mpleon las durante o?

La finalidad de las métricas del proyecto es doble. Primero, se e m p l e a n para minimizar el tiempo d e desarrollo haciendo los ajustes necesarios para evitar d e m o r a s y reducir los problemas y riesgos potenciales. Segundo, se utilizan para valorar la c a lidad del producto sobre u n a b a s e actual y, c u a n d o es necesario, modificar el enfoque técnico para mejorar la calidad. Conforme la calidad mejora los defectos se minimizan, y mientras e s t o s u c e d e también se reduce la cantidad de reelaboración requerida durante elTM proyecto. Esto conduce a una reducción en el costo global del proyecto.

PDF Editor 2

En este libro, un error se define como algún fallo en un producto de trabajo de ingeniería del soft ware que se descubre antes de que el software se entregue al usuario final. Un defecto es un fallo que se descubre después de la entrega al usuario final. Se debe advertir que otros no hacen esta distinción. En el capítulo 26 se presenta un mayor análisis

668

PARTE CUATRO


HOGARSEGURO e l

«fifi

Establecimiento

de un enfoque de métricas

' El e s c e n a r i o : La oficina d e Doug Miller cuando se está a punto d e iniciar el proyecto d e

mos mejor software. La única formo d e hacer esto e s midiendo.

software HogarSeguro.

J a m i e : Pero tenemos presión d e tiempo, Doug. N o es-

Los a c t o r e s : Doug Miller (gerente del equipo d e ingeniería del software HogarSeguro}

y Vinod Raman y Ja-

toy en favor d e más presión d e p a p e l e o . . . necesitamos el tiempo p a r a hacer nuestro trabajo, no recopilar datos.

mie Lazar, miembros del equipo cié ingeniería d e

D o u g ( c a l m a d a m e n t e ) : J a m i e , e l t r a b a j o d e un inge-

software del producto.

niero involucra recopilar datos, evaluarlos y aprovechar

La conversación:

los resultados p a r a mejorar el producto y el proceso.

D o u g : Antes d e comenzar a t r a b a j a r en este proyecto

¿Me equivoco?

me gustaría q u e definieran y reunieran un conjunto d e

J a m i e : No, pero...

¡9

métricas simples. Pora comenzar, tendrán que definir sus

D o u g : ¿Qué tal si dejamos el número d e medidas q u e

metas.

deben reunirse en no más d e cinco o seis y nos enfoca-

V i n o d ( c e ñ u d o ) : Nunca antes hemos hecho eso, y...

mos en la calidad?

J a m i e ( i n t e r r u m p e ) : Y con b a s e en la administración del tiempo d e la q u e se ha estado hablando, nunca ten-

V i n o d : N a d i e p u e d e estar en contra d e la alta calidad...

dremos el tiempo. A d e m á s , ¿qué tan buenas son las mé-

J a m i e : Cierto... pero, no sé, todavía creo q u e esto no

tricas?

es necesario.

Doug (eleva las m a n o s p a r a detener el ataq u e ) : Calma... relájense, chicos. El hecho d e q u e nunca

D o u g : Esta vez les pediré q u e me complazcan. ¿Cuánto saben acerca d e las métricas d e software?

antes lo hayamos hecho es la principal razón p a r a co-

Jamie (voltea y v e a Vinod): No mucho.

menzar a h o r a , y el trabajo d e las métricas d e las q u e estoy hablando no debería tomar mucho tiempo... d e hecho, puede ahorrarnos tiempo.

é

V i n o d : ¿Cómo? D o u g : Mira, haremos mucha ingeniería d e software en

D o u g : Aquí tienen algunas referencias d e la W e b . . . p e sen algunas horas organizándose p a r a aumentar la vele cidad,

•

J a m i e ( s o n r í e ) : Pensé que dijiste q u e esto no nos tomaría tiempo.

caso conforme nuestro producto se vuelve más inteligen-

D o u g : El tiempo que p a s a n aprendiendo nunca es tiem-

te, llegue a estar habilitado en la Web, todo eso... y ne-

p o perdido... vayan a hacerlo y luego estableceremos al-

cesitamos entender el proceso q u e utilizamos p a r a

g u n a s metas, plantearemos algunas preguntas y

construir software... y mejorarlo d e modo q u e construya-

definiremos las métricas q u e necesitamos reunir.

22.2

M E D I C I Ó N BEL SOFTWARE

TM

En el c a p í t u l o 15 se indicó q u e la m e d i c i ó n d e s o f t w a r e s e clasifica e n d o s categorías: 1) medidas

directas del p r o c e s o de s o f t w a r e (por e j e m p l o , c o s t o y e s f u e r z o apli-

PDF Editor

c a d o s ) y del p r o d u c t o (por e j e m p l o , l í n e a s d e c ó d i g o |LDC] p r o d u c i d a s , r a p i d e z de e j e c u c i ó n y d e f e c t o s r e p o r t a d o s a lo largo de c i e r t o p e r i o d o establecido) y 2) mea:das indirectas

del p r o d u c t o q u e incluyen f u n c i o n a l i d a d , calidad, c o m p l e j i d a d , eficier

cia, confiabilidad, facilidad d e m a n t e n i m i e n t o y m u c h a s o t r a s " h a b i l i d a d e s " t r a t a d a e n el c a p í t u l o 15.

CAPÍTULO 22

669


"No todo lo que puede ser contado cuenta, y no todo o que cuenta pu ide ser contodo." Alberl E'mstein Las m é t r i c a s del p r o y e c t o s e c o n s o l i d a n c o n el fin d e c r e a r m é t r i c a s del p r o c e s o q u e s e a n p ú b l i c a s p a r a la o r g a n i z a c i ó n d e s o f t w a r e c o m o u n todo. Pero, ¿ c ó m o c o m muchos

b i n a u n a o r g a n i z a c i ó n las m é t r i c a s p r o v e n i e n t e s d e d i f e r e n t e s i n d i v i d u o s o p r o y e c -

ttel

tos?

software, es métricas : equipos.

C o n fines ilustrativos, c o n s i d é r e s e un e j e m p l o s i m p l e . Los i n t e g r a n t e s de d o s dif e r e n t e s e q u i p o s d e p r o y e c t o registran y c a t e g o r i z a n l o s e r r o r e s q u e e n c u e n t r a n d u r a n t e el p r o c e s o del s o f t w a r e . Luego, las m e d i c i o n e s i n d i v i d u a l e s se c o m b i n a n p a r a d e s a r r o l l a r m e d i d a s d e e q u i p o . El e q u i p o A e n c o n t r ó 3 4 2 e r r o r e s d u r a n t e el p r o c e s o del s o f t w a r e p r e v i o al l a n z a m i e n t o . El e q u i p o B e n c o n t r ó 184 e r r o r e s . Si t o d a s las d e m á s c o s a s s e m a n t i e n e n iguales, ¿ q u é e q u i p o e s m á s e f i c i e n t e al d e s c u b r i r e r r o r e s a lo largo del p r o c e s o ? P u e s t o q u e n o s e c o n o c e n ni el t a m a ñ o ni la c o m p l e j i d a d d e los p r o y e c t o s , n o s e p u e d e r e s p o n d e r e s t a p r e g u n t a . Sin e m b a r g o , si las m e d i c i o n e s s e n o r m a l i z a n , e s p o s i b l e c r e a r m é t r i c a s d e s o f t w a r e q u e posibiliten la c o m p a r a c i ó n a promedios organizacionales m á s amplios. De esta forma, las métricas orientadas t a n t o al t a m a ñ o c o m o a la f u n c i ó n e s t á n n o r m a l i z a d a s .

22.2.1 Métricas orientadas al tamaño Las m é t r i c a s del s o f t w a r e o r i e n t a d a s al t a m a ñ o p r e c e d e n d e la n o r m a l i z a c i ó n d e l a s m e d i d a s de calidad o p r o d u c t i v i d a d c o n s i d e r a n d o el t a m a ñ o del s o f t w a r e q u e s e h a p r o d u c i d o . Si u n a o r g a n i z a c i ó n de s o f t w a r e m a n t i e n e r e g i s t r o s s i m p l e s e s factible c r e a r u n a tabla d e m e d i d a s o r i e n t a d a s al t a m a ñ o , c o m o la q u e s e m u e s t r a e n la fig u r a 22.2. En la tabla s e m e n c i o n a c a d a p r o y e c t o d e d e s a r r o l l o d e s o f t w a r e q u e s e h a c o m p l e t a d o e n a ñ o s p a s a d o s , así c o m o las m e d i d a s c o r r e s p o n d i e n t e s p a r a d i c h o s p r o y e c t o s . C o m o s e a d v i e r t e e n la e n t r a d a d e tabla (figura 22.2) p a r a el p r o y e c t o alfa: 12 100 l í n e a s d e c ó d i g o s e d e s a r r o l l a r o n c o n 2 4 p e r s o n a s - m e s d e e s f u e r z o a u n c o s t o d e 168 0 0 0 d o l a r e s . Se d e b e n o t a r q u e el e s f u e r z o y el c o s t o r e g i s t r a d o s e n la tabla r e p r e s e n t a n t o d a s las a c t i v i d a d e s d e i n g e n i e r í a del s o f t w a r e (análisis, d i s e ñ o , c ó d i g o y p r u e b a ) , n o s ó l o c o d i f i c a c i ó n . I n f o r m a c i ó n a d i c i o n a l del p r o y e c t o alfa indic a q u e s e d e s a r r o l l a r o n 3 6 5 p á g i n a s de d o c u m e n t a c i ó n , s e r e g i s t r a r o n 134 e r r o r e s a n t e s d e q u e el s o f t w a r e f u e s e l i b e r a d o y s e e n c o n t r a r o n 2 9 d e f e c t o s d e s p u é s d e la liberación al cl i ente d e n t r o del p r i m e r a ñ o d e o p e r a c i ó n . T r e s p e r s o n a s t r a b a j a r o n e n el d e s a r r o l l o del s o f t w a r e p a r a el p r o y e c t o alfa.

TM

El d e s a r r o l l o d e m é t r i c a s q u e s e a s i m i l e n c o n m é t r i c a s s i m i l a r e s p r o c e d e n t e s d e o t r o s p r o y e c t o s r e q u i e r e elegir líneas de código c o m o v a l o r d e n o r m a l i z a c i ó n . A p a r -

PDF Editor

tir d e los d a t o s r u d i m e n t a r i o s d e la t a b l a s e d e s a r r o l l a u n c o n j u n t o d e m é t r i c a s s i m p l e s o r i e n t a d a s al t a m a ñ o p a r a c a d a p r o y e c t o : e r r o r e s p o r KLDC (miles d e l í n e a s d e

código), d e f e c t o s p o r KLDC, c o s t o p o r KLDC. p á g i n a s d e d o c u m e n t a c i ó n p o r KLDC. Además, se p u e d e n calcular otras métricas interesantes: errores por persona-mes, KLDC p o r p e r s o n a - m e s , c o s t o por p á g i n a d e d o c u m e n t a c i ó n .

670

PARTE CUATRO

Métricas orientadas al tamaño.


Proyecto alfa beta gamma II! • »

LDC

Esfuerzo

$(000)

12 100 27 200 20 200

24 62 43

168 440 314

365 1 224 1 050

•. •

• •

•

• •

•

•

' « ,

%l

P a g . D
• •

134 321 256

29 86 64

3 5 6

•

.'•

Las m é t r i c a s o r i e n t a d a s al t a m a ñ o n o s e a c e p t a n u n i v e r s a l m e n t e c o m o la m e j o r f o r m a d e m e d i r el p r o c e s o del s o f t w a r e [JON86]. La m a y o r p a r t e d e la c o n t r o v e r s a

CLAVE Las métricas orientadas al tamaño son ampliamente utilizados, pero continúa el debate acerca de su valide; y aplicabilidad.

gira e n t o r n o al u s o d e l í n e a s d e c ó d i g o c o m o m e d i d a clave. Los p a r t i d a r i o s d e la medida LDC a f i r m a n q u e é s t a s s o n u n " a r t e f a c t o " d e t o d o s los p r o y e c t o s d e d e s a r r o : . : d e s o f t w a r e q u e p u e d e n f á c i l m e n t e c o n t a r s e , q u e m u c h o s m o d e l o s d e e s t i m a c i ó n de s o f t w a r e e x i s t e n t e s u s a n LDC o KLDC c o m o e n t r a d a clave, y q u e ya e x i s t e u n g r a c u e r p o d e bibliografía y d a t o s p u b l i c a d o s p a r a LDC. Por o t r a p a r t e , los d e t r a c t o r e s arg u m e n t a n q u e las m e d i d a s LDC d e p e n d e n del l e n g u a j e d e p r o g r a m a c i ó n , q u e , c u a r d o s e c o n s i d e r a la p r o d u c t i v i d a d , c a s t i g a n l o s p r o g r a m a s bien d i s e ñ a d o s , p e r o m a ; c o r t o s , q u e n o p u e d e n a m o l d a r c o n facilidad l e n g u a j e s q u e n o p r o v i e n e n del proce s o y c u y o e m p l e o e n la e s t i m a c i ó n r e q u i e r e un nivel d e detalle q u e s e r í a difícil de leg r a r (es decir, el p l a n i f i c a d o r d e b e e s t i m a r q u e las LDC s e p r o d u c i r á n m u c h o a n t e ; de q u e el a n á l i s i s y el d i s e ñ o s e h a y a n c o m p l e t a d o ) .

22.2.2 Métricas orientadas a la función Las m é t r i c a s d e s o f t w a r e o r i e n t a d a s a la f u n c i ó n e m p l e a n c o m o u n v a l o r d e normalización u n a m e d i d a d e la f u n c i o n a l i d a d q u e e n t r e g a la aplicación. La m é t r i c a o r i e t a d a a la f u n c i ó n utilizada c o n m a y o r a m p l i t u d e s el punto

de Junción

(PF). El cálcu-

lo del p u n t o d e f u n c i ó n s e b a s a é n c a r a c t e r í s t i c a s del d o m i n i o d e i n f o r m a c i ó n y 3 c o m p l e j i d a d del s o f t w a r e . La m e c á n i c a del c á l c u l o del PF s e t r a t óTM e n el C a p í t u l o 15

1

El p u n t o d e f u n c i ó n , al igual q u e la m e d i d a LDC, e s c o n t r o v e r s i a l . Los p a r t i d a r i o ; a f i r m a n q u e el PF e s i n d e p e n d i e n t e d e l l e n g u a j e de p r o g r a m a c i ó n , c a r a c t e r í s t i c a q u e

PDF Editor

lo h a c e ideal p a r a a p l i c a c i o n e s q u e utilizan l e n g u a j e s c o n v e n c i o n a l e s y n o procedímentales, y que s e basa en datos que es m á s probable q u e se conozcan temprano e n la e v o l u c i ó n d e u n p r o y e c t o , lo q u e h a c e al PF m á s a t r a c t i v o c o m o e n f o q u e de es-

3

Véase ta sección 15.3.1 para una detallada exposición del cálculo d e PF.

CAPITULO 22


671

limación. Los d e t r a c t o r e s a f i r m a n q u e el m é t o d o requiere cierta "prestidigitación" en c u a n t o a q u e el cálculo se b a s a en d a t o s subjetivos m á s q u e objetivos, q u e el c o n t e o del d o m i n i o d e información (y o t r a s dimensiones) p u e d e ser difícil d e recopilar d e s p u é s del hecho, y q u e el PF n o tiene significado físico directo.- e s sólo un n ú m e r o .

22.2.3 Reconciliación de las métricas LDC y PF La relación e n t r e líneas d e código y p u n t o s d e función d e p e n d e del l e n g u a j e d e prog r a m a c i ó n en q u e s e i m p l e m e n t a n el s o f t w a r e y la calidad del diseño. Varios e s t u d i o s h a n i n t e n t a d o relacionar las m e d i d a s d e PF y LDC. Por e j e m p l o Albrecth y Gaffn e y [ALB83]: La tesis de este trabajo es que la cantidad de función que se ofrecerá por medio de la aplicación (programa) se puede estimar a partir de pormenorizar los grandes componentes 4 de datos que se emplearán o proporcionarán. Más aún, esta estimación de la función debe estar correlacionada tanto con la cantidad de LDC que se desarrollará como con el esfuerzo de desarrollo necesario. La tabla 5 siguiente [QSM02] o f r e c e e s t i m a c i o n e s b u r d a s del n ú m e r o p r o m e d i o de lín e a s de código q u e s e requieren para construir un p u n t o d e función en varios lenguajes de programación: Una revisión d e e s t o s d a t o s indica q u e u n a LDC d e C++ proporciona a p r o x i m a d a m e n t e 2.4 v e c e s la "funcionalidad" (en promedio) d e u n a LDC d e C. Más a ú n , u n a LDC d e Smalltalk proporciona al m e n o s c u a t r o v e c e s la funcionalidad de u n a LDC d e un lenguaje d e programación convencional c o m o Ada, COBOL o C. La utilización de la información c o n t e n i d a en la tabla p e r m i t e " t o m a r c o m o c o n t r a f u e g o " [ION98] el softw a r e existente para e s t i m a r el n ú m e r o d e p u n t o s d e función, u n a v e z q u e s e c o n o z ca el n ú m e r o total de e n u n c i a d o s del l e n g u a j e d e p r o g r a m a c i ó n . Se ha e n c o n t r a d o q u e las m é t r i c a s b a s a d a s en p u n t o s d e f u n c i ó n y LDC s o n indic a d o r a s r e l a t i v a m e n t e precisos del e s f u e r z o y el c o s t o del desarrollo de s o f t w a r e . Sin e m b a r g o , e m p l e a r LDC y PF e n la estimación (capítulo 23) requiere e s t a b l e c e r u n a lín e a d e referencia histórica d e información. En c o n t e x t o del p r o c e s o y las métricas del proyecto, la p r e o c u p a c i ó n principal la g e n e r a n la productividad y la calidad: m e d i d a s d e la "salida" d e desarrollo d e softw a r e c o m o función del e s f u e r z o y el tiempo aplicados y m e d i d a s d e la "aptitud p a r a el uso" d e los p r o d u c t o s d e t r a b a j o obtenidos. Respecto a p r o p ó s i t o s d e m e j o r a del p r o c e s o y p l a n e a c i ó n del proyecto, el interés e s histórico. ¿Cuál fue la productividad TM 4

Es importante notar que "pormenorizar los grandes componentes" se puede interpretar en varias

PDF Editor

formas. Los ingenieros de software que trabajan en un entorno de desarrollo orientado a objetos usan el número de clases u objetos como el tamaño de métrica dominante. Una organización de man tenimiento puede considerar el t a m a ñ o del proyecto en términos del número de pedidos de cambios de ingeniería (capítulo 27). Una organización de s a e m a s de información quizá vea el número de

5

procesos comerciales que afecta una aplicaciónUtilizado con permiso de Quantitative Sotlv. are Mar,ag-smen: www.qsm.com), copyright 2002

672

PARTE CUATRO


d e d e s a r r o l l o del s o f t w a r e e n l o s p r o y e c t o s p a s a d o s ? ¿ C u á l f u e la c a l i d a d d e l s o f t w a r e q u e s e p r o d u j o ? ¿ C ó m o s e p u e d e n e x t r a p o l a r al p r e s e n t e la p r o d u c t i v i d a d y la calid a d p a s a d a s ? ¿ C ó m o p u e d e a y u d a r a m e j o r a r el p r o c e s o y p l a n i f i c a r n u e v o s p r o y e c t o s con mayor precisión? Lenguaje de programación

LDC por punto Promedio

Access Ada APS ASP 6 9 Ensamblador C C+ + Clipper COBOL Cool:Gen/IEF Culpril DBase IV Easytrievel Excel47 Focus FORTRAN FoxPro Ideal IEF/Cool:Gen Informix Java JavaScript JCl JSP Lotus Notes AAanlis Mapper Natural Oracle PeopleSofl Perl PL/I Powerbuilder REXX RPG ll/lll SAS Smalltalk SQL VBScript3ó Visual Basic

35 154 86 62 337 162 66 38 77 38 51 52 33 46 43

Mediana 38 —

83 —

315 109 53 39 77 31

de función Bajo

Alto

15 104 20 32 91 33 29 27 14 10

47 205 184 127 694 704 178 70 400 180

—

—

—

—

34

25 31 32

—

42

—

—

32 66 38 42 63 58 91 59 21 71 118 60 30 33 60 78 32 67 61 40 26 40 34 47

35 52 31 31 53 63 123 —

22 27 81 52 35 32 —

67 31 —

—

41 63 56

—

25 34 10 24 77 42 26 —

15 22 16 22 4 30 —

2 2 TM 11 —

PDF Editor 49 41 19 37 27 42

—

24 33 10 7 50 16

35 203 180 57 —

75 150 —

25 250 245 141 217 40 —

263 105 —

155 49 55 110 —

158

1

CAPÍTULO 22

673


22.2.4 Métricas orientadas a objetos Las métricas de proyectos de software convencionales (LDC o PF) se aplican en la estimación de proyectos de s o f t w a r e orientados a objetos. Sin embargo, e s t a s métricas n o proporcionan suficiente granularidad para la planificación y los ajustes de esf u e r z o que se requieren c o n f o r m e se itera a lo largo de un proceso evolutivo o incremental. Lorenz y Kidd [LOR94] sugieren el siguiente conjunto de métricas para proyectos OO:

• ite ¡ escenario tía 1u líos. En

, tengo > utilice t guión.

Número de guiones de escenario.

Un guión de escenario (análogo a los c a s o s

de uso estudiados a través de las partes 2 y 3 de este libro) es u n a secuencia detallada de p a s o s que describen la interacción entre el usuario y la aplicación. El n ú m e ro de guiones de escenario está directamente correlacionado con el t a m a ñ o de la aplicación y con el n ú m e r o de casos de prueba que se deben desarrollar para ejercitar el sistema u n a vez que se construya. Número d e c l a s e s clave.

Las clases clave son los " c o m p o n e n t e s e n o r m e m e n t e in-

dependientes" [LOR94] definidos con antelación en el análisis orientado a objetos (capítulo 8). 6 Puesto que las clases clave son centrales respecto del dominio del problema, su n ú m e r o indica la cantidad de e s f u e r z o necesario para desarrollar el software. También indican la potencial cantidad de reutilización que se aplicará d u r a n te el desarrollo del sistema.

* ¡pueden rmoño y I Por lo i b pena rio dosificól a s conteos de r moño y

Número de clases de apoyo.

Las clases de apoyo son necesarias en la implemen-

tación del sistema, p e r o no están i n m e d i a t a m e n t e relacionadas con el dominio del problema. Los ejemplos pueden s e r las clases 1U, los a c c e s o s a b a s e s de d a t o s y las clases de manipulación y las de cálculo. Además, las clases de apoyo se pueden desarrollar para cada u n a de las clases clave. El n ú m e r o de clases de apoyo es un indicio de la cantidad de e s f u e r z o indispensable para desarrollar el software, así c o m o un indicio de la potencial cantidad de reutilización que se aplicará d u r a n t e el desarrollo del sistema. Número promedio d e clases de apoyo por clase clave.

En general, las clases

clave se conocen en e t a p a s iniciales del proyecto. Las clases de apoyo se definen a lo largo del curso de éste. Si se conociese el n ú m e r o promedio de clases de apoyo p o r clase clave respecto d e un dominio de problema dado, la estimación (con b a s e en el n ú m e r o total de clases) se simplificaría mucho. Lorenz y Kidd sugieren que las aplicaciones con u n a GUI tienen entre dos y tres veces el n ú m e r o deTM clases de a p o yo que las clases clave. Las aplicaciones sin GUI tienen entre una y dos veces el núm e r o de clases de apoyo que las clases clave.

PDF Editor Número de subsistemas.

Un subsistema

e s un a g r e g a d o de clases que apoyan

una función visible para el usuario final de un sistema. Una vez identificados los s u b -

6

En la parte 2 de este libro a las clases clave se les refino c o m o clases de análisis.

674

PARTE CUATRO

GESTIÓN DE P R O Y E C T O S DE SOFTWARE

s i s t e m a s e s m á s fácil e x t e n d e r u n a planificación r a z o n a b l e en la cual s e h a y a he la partición del trabajo e n t r e el equipo del proyecto. La utilización eficiente en un e n t o r n o d e ingeniería d e s o f t w a r e o r i e n t a d a a o tos requiere recopilar métricas similares a las a n o t a d a s líneas arriba, j u n t o con didas del proyecto tales c o m o e s f u e r z o g a s t a d o , e r r o r e s y d e f e c t o s descubiertos m o d e l o s o p á g i n a s d e d o c u m e n t a c i ó n producidos. C o n f o r m e la b a s e d e d a t o s cr (después de c o m p l e t a d o s varios proyectos), las relaciones e n t r e m e d i d a s orienta a o b j e t o s y m e d i d a s de proyecto p r o p o r c i o n a r á n métricas q u e auxilien en la e s t i ción del proyecto.

22.2.5 Métricas orientadas a casos de uso Parecería r a z o n a b l e aplicar el c a s o d e uso 7 c o m o u n a m e d i d a d e normalización milar a la LDC o PF. C o m o el PF, el c a s o de u s o s e define en e t a p a s t e m p r a n a s proceso d e software, lo que permite emplearlo en la estimación a n t e s de iniciar las tividades significativas d e m o d e l a d o y construcción. Los c a s o s d e u s o describen m e n o s indirectamente) funciones y características visibles al usuario q u e s o n r e q " tos básicos para un sistema. El c a s o de uso e s independiente del lenguaje de pi mación. A d e m á s , el n ú m e r o d e c a s o s de u s o e s directamente proporcional al t a m d e la aplicación en LDC, así c o m o al n ú m e r o d e c a s o s de prueba que tendrán que s e ñ a r s e p a r a ejercitar c o m p l e t a m e n t e la aplicación. Puesto q u e los c a s o s d e u s o p u e d e n c r e a r s e c o n g r a d o s d e abstracción amp' m e n t e diferentes, n o existe t a m a ñ o e s t á n d a r p a r a ellos. Sin u n a m e d i d a estándar, aplicación c o m o m e d i d a d e normalización (por ejemplo, e s f u e r z o e m p l e a d o por s o de uso) e s s o s p e c h o s a . A u n q u e varios investigadores (por ejemplo, [SMI99]) intentado o b t e n e r métricas d e c a s o d e uso, todavía q u e d a m u c h o t r a b a j o por ha

22.2.6 Métricas de proyectos de ingeniería Web El objetivo de t o d o s los proyectos de ingeniería Web (parte 3 d e este libro) e s c truir u n a aplicación Web (WebApp) q u e p r o p o c i o n e u n a c o m b i n a c i ó n de c o n t é y funcionalidad al u s u a r i o final. Las m e d i d a s y m é t r i c a s q u e s e e m p l e a n en los y e c t o s de ingeniería de s o f t w a r e tradicionales s o n difíciles de traducir directame a la WebApp. Incluso, u n a organización d e ingeniería Web d e b e desarrollar u n a ' s e de d a t o s q u e le permita valorar su productividad y calidad i n t e r n a s a lo largo varios proyectos. Entre las m e d i d a s q u e s e p u e d e n recopilar e s t á n : TM N ú m e r o d e p á g i n a s Web e s t á t i c a s . Las p á g i n a s Web de c o n t e n i d o estático decir, el u s u a r i o final n o controla el c o n t e n i d o d e s p l e g a d o en la página) s o n las

PDF Editor

c o m u n e s d e t o d a s las características WebApp. Estas p á g i n a s r e p r e s e n t a n u n a c plejidad relativa baja y por lo general requieren m e n o s e s f u e r z o al construirlas

7

Los casos de uso se estudian a través de las partes 2 y 3 de este libro.

CAPÍTULO 22


675

las p á g i n a s dinámicas. Esta medida proporciona un indicio del t a m a ñ o global de la aplicación y el e s f u e r z o que se requiere para desarrollarla. N ú m e r o d e p á g i n a s W e b d i n á m i c a s . Las páginas Web de contenido dinámico (es decir, las acciones del usuario final g e n e r a n contenido personalizado q u e s e despliega en la página) son esenciales en t o d a s las aplicaciones de comercio electrónico, motores de búsqueda, aplicaciones financieras y m u c h a s otras categorías de WebApp. Estas páginas representan una mayor complejidad relativa y requieren m á s esfuerzo al construirlas que las p á g i n a s estáticas. Esta medida proporciona un indicio del t a m a ñ o global de la aplicación y el e s f u e r z o requerido para desarrollarla. N ú m e r o d e v í n c u l o s i n t e r n o s d e p á g i n a . Los vínculos internos de página son punteros que ofrecen un hipervínculo hacia alguna otra página Web dentro de la WebApp. Esta medida proporciona un indicio del g r a d o de a c o p l a m i e n t o arquitectónico d e n t r o de la WebApp. Conforme a u m e n t a el n ú m e r o de vínculos de la página, t a m bién lo h a c e el e s f u e r z o e m p l e a d o en el diseño y construcción de la navegación. N ú m e r o d e o b j e t o s d e d a t o s p e r s i s t e n t e s . Una WebApp p u e d e tener a c c e s o a u n o o m á s objetos de d a t o s persistentes (por ejemplo, una b a s e de d a t o s o archivo de datos). Conforme el n ú m e r o de objetos de d a t o s persistentes crece, también lo h a c e la complejidad de la WebApp y el e s f u e r z o para implementarla a u m e n t a proporcionalmente. N ú m e r o d e s i s t e m a s e x t e r n o s e n interfaz. Con frecuencia las WebApps deben hacer interfaz con aplicaciones comerciales "de cuarto trasero". Conforme crece el requisito para hacer interfaz, la complejidad del sistema y el e s f u e r z o de d e s a rrollo también a u m e n t a n . N ú m e r o d e o b j e t o s d e c o n t e n i d o e s t á t i c o . Los objetos de contenido estático a b a r c a n información estática b a s a d a en texto, gráfica, video, animación y audio que se incorporan dentro de la WebApp. En u n a página Web sencilla pueden a p a r e c e r múltiples objetos de contenido estático. N ú m e r o d e o b j e t o s d e c o n t e n i d o d i n á m i c o . Los objetos de contenido dinámico se g e n e r a n con b a s e en las acciones del usuario final y a b a r c a n información g e n e r a d a i n t e r n a m e n t e basada en texto, gráfica, video, animación y a u d i o q u e se incorporan dentro de la WebApp. En u n a página Web sencilla pueden a p a r e c e r múltiples objetos de contenido dinámico. N ú m e r o d e f u n c i o n e s e j e c u t a b l e s . Una función ejecutable (por ejemplo, u n guión o applet) ofrece cierto servicio computacional al usuario final.TM Conforme a u m e n t a el n ú m e r o de funciones ejecutables, también a u m e n t a n los e s f u e r z o s de m o delado y construcción.

PDF Editor

Cada u n a de e s t a s medidas s e p u e d e determinar en u n a etapa relativamente temprana del proceso de ingeniería Web. Por ejemplo, es posible definir u n a métrica q u e refleje el grado de personalización

de usuario final que se requiere para la WebApp y correlacionarla con el e s f u e r z o

676

PARTE CUATRO


e m p l e a d o e n el p r o y e c t o d e I W e b o l o s e r r o r e s d e s c u b i e r t o s c o n f o r m e s e l l e v a n a c a bo revisiones y pruebas. Para lograr esto, se define Nsp = n ú m e r o d e p á g i n a s W e b e s t á t i c a s Ndp

= n ú m e r o de páginas Web dinámicas

Entonces, í n d i c e d e p e r s o n a l i z a c i ó n , C = Ndp/(Ndp

+ Nsp)

El v a l o r d e C v a r i a d e 0 a 1. C o n f o r m e C c r e c e , e l n i v e l d e p e r s o n a l i z a c i ó n d e la W e b App se vuelve un conflicto técnico significativo. Es posible calcular y correlacionar m é t r i c a s similares d e aplicaciones W e b cor m e d i d a s del p r o y e c t o , t a l e s c o m o el e s f u e r z o e m p l e a d o , l o s e r r o r e s y d e f e c t o s desc u b i e r t o s y l o s m o d e l o s o p á g i n a s d e d o c u m e n t a c i ó n p r o d u c i d o s . C o n f o r m e la b a s e d e d a t o s crece (después d e q u e varios proyectos se h a n completado), las relaciones e n t r e l a s m e d i d a s W e b A p p y l a s m e d i d a s del p r o y e c t o p r o p o r c i o n a r á n indicadores q u e a u x i l i e n e n la e s t i m a c i ó n del p r o y e c t o .


Métricas del proyecto y el proceso O b j e t i v o : Ayudar en la definición, recopila-

PSM Insight, desarrollada por Practical Software and Sys-

ción, evaluación y reporte d e medidas y métri-

tems Measurement (www.psmsc.com), auxilia en la

cas d e software.

creación y subsiguiente análisis d e una base d e datos

M e c á n i c a : C a d a herramienta varía en cuanto a su apli-

d e medición del proyecto.

cación, pero todas ofrecen mecanismos p a r a recopilar y evaluar datos q u e conduzcan al cálculo d e métricas d e software. Herramientas representativas8 Funclion Point WORKBENCH,

desarrollada por Charisma-

tek (www.charismatek.com.au), ofrece una amplia variedad de métricas orientadas a PF. MetricCenter, desarrollada por Distributive Software (www.distributive.com), soporta recopilación automatiz a d a d e datos, análisis, formateo d e gráficos, generación d e reportes y otras tareas d e medición.

SUM lool sel, desarrollado

por QSM (www.qsm.com),

pro-

porciona un completo conjunto d e métricas y herramientas d e estimación. SPR lool sel, desarrollado por Software Productivity Research (www.spr.com), ofrece una colección detallada de herramientas orientadas a PF. TychoMelrics, desarrollado por Predícate Logic, Inc. (www predicate.com), es una suite d e herramientas p a r a gestionar recopilación d e métricas y reportes.

TM L a m e t a p r i m o r d i a l d e la i n g e n i e r í a d e l s o f t w a r e e s p r o d u c i r u n s i s t e m a , a p l i c a d o - !

PDF Editor

o p r o d u c t o de alta calidad d e n t r o de u n m a r c o t e m p o r a l q u e satisfaga u n a n e c e s i d a ;

8

Las h e r r a m i e n t a s a n o t a d a s aquí son una muestra de esta categoría. En la mayoría de los casos tas]

n o m b r e s de las m i s m a s son m a r c a s registradas por sus respectivos desarrolladores.

CAPÍTULO 2 2


677

del mercado. El logro de esta meta requiere que los ingenieros de s o f t w a r e apliquen m é t o d o s eficaces acoplados con h e r r a m i e n t a s m o d e r n a s dentro del contexto de un p r o c e s o de s o f t w a r e maduro. Además, un b u e n ingeniero de s o f t w a r e (y los b u e n o s gestores de ingeniería del software) debe medir si se logrará la alta calidad. Las métricas privadas reunidas por los ingenieros de s o f t w a r e individuales se asimilan con los resultados ofrecidos en el ámbito del proyecto. Aunque se p u e d e n reunir m u c h a s medidas de calidad, el impulso primario e n el ámbito del proyecto es m e dir los errores y defectos. Las métricas derivadas de e s t a s medidas proporcionan un indicio de la efectividad de la garantía de la calidad del s o f t w a r e y de las actividades de control t a n t o de los individuos c o m o del grupo. Las métricas c o m o los errores en el producto de trabajo (por ejemplo, requisitos o diseño) por p u n t o d e función, errores descubiertos por hora de revisión, y los error e s descubiertos por hora de prueba ofrecen u n a visión de la eficacia de cada una de las actividades implicadas en la métrica. Los d a t o s de error también se pueden e m plear en el cálculo de la eficacia en la eliminación de defectos (EED) para cada actividad del m a r c o de trabajo del proceso. La EED se estudia en la sección 22.3.2.

22.3.1 Medición de la calidad Aunque existen m u c h a s m e d i d a s de la calidad del software, 9 la corrección, la facilidad de mantenimiento, la integridad y la facilidad de uso ofrecen indicadores útiles para el equipo del proyecto. Gilb (GIL88] sugiere definiciones y mediciones para cada u n a de ellas. C o r r e c c i ó n . Un p r o g r a m a d e b e operar correctamente o proporcionará p o c o vai oielenle Instile ..

nocen» c cridad dé. ¡ § g | ¡ y tópicos 5 (incluso ) se encuentro • www. prftyworld.com.

lor para sus usuarios. La corrección es el g r a d o e n que el s o f t w a r e d e s e m p e ñ a la función para la que fue creado. La medida m á s c o m ú n para la corrección es defectos por KLDC, d o n d e un defecto se define c o m o u n a falta c o m p r o b a d a de concordancia con los requisitos. C u a n d o se considera la calidad global de un producto de s o f t w a re, los defectos son los p r o b l e m a s que reporta u n usuario del p r o g r a m a d e s p u é s de que éste se liberó para el uso general. Para los propósitos de la evaluación de la calidad, los defectos se c u e n t a n sobre un periodo estándar, u s u a l m e n t e un año. Facilidad d e m a n t e n i m i e n t o . El m a n t e n i m i e n t o del s o f t w a r e justifica m á s esfuerzos que cualquier otra actividad de la ingeniería del software. La facilidad de m a n t e n i m i e n t o es la sencillez con la que u n p r o g r a m a p u e d e corregirse si se encuentra un error, a d a p t a r s e si su e n t o r n o cambia, o mejorar si el cliente desea un cambio en los requisitos. No existe forma de medir directamente la facilidad de m a n TM tenimiento; en consecuencia, se deben emplear medidas indirectas. Una simple m e dida orientada al tiempo es el tiempo medio de cambio (TMC), el tiempo que toma

PDF Editor

analizar el c a m b i o solicitado, diseñar u n a modificación apropiada, implementar el

9

En el capitulo 15 se p r e s e n t ó una discusión detallada de los factores q u e influyen en la calidad del

s o f t w a r e y las métricas q u e se pueden usar para valorar la calidad del software.

678

PARTE CUATRO


cambio, probarlo y distribuir el c a m b i o a todos los usuarios. En promedio, los prog r a m a s susceptibles de m a n t e n i m i e n t o tendrán un TMC b a j o (para tipos de cambios equivalentes) que los p r o g r a m a s que n o lo son. Integridad. La integridad del s o f t w a r e se ha vuelto cada vez m á s importante en la edad de los ciberterroristas y hackers. Este atributo mide la habilidad de un sistem a para resistir a t a q u e s (tanto accidentales c o m o intencionales) a su seguridad. Los a t a q u e s se pueden realizar en los tres c o m p o n e n t e s del software: programas, datos y documentos. La medición de la integridad requiere definir dos atributos adicionales: a m e n a z a y seguridad. Amenaza es la probabilidad (que p u e d e estimarse o deducirse de evidencia empírica) de que un a t a q u e de u n tipo específico ocurrirá dentro de un tiempo dado. Seguridad

es la probabilidad (que puede estimarse o deducirse de evidencia

empírica) de que se repela el a t a q u e de un tipo específico. Entonces, la integridad de un sistema se p u e d e definir como: integridad = 1 - ( a m e n a z a x (1 — seguridad)) Por ejemplo, si la a m e n a z a (la probabilidad de que un a t a q u e ocurrirá) es 0.25 \ la seguridad (la posibilidad de repeler un ataque) es 0.95, la integridad del sistema es 0.99 (muy elevada). Si, por otra parte, la probabilidad de a m e n a z a e s 0.50 y la posibilidad de repeler un a t a q u e es sólo 0.25, la integridad del sistema es 0.63 (inaceptablemente baja). Facilidad d e u s o . Con frecuencia, un p r o g r a m a que n o es fácil de usar está cond e n a d o al fracaso, incluso si las funciones que realiza son valiosas. La facilidad de uso e s un intento por cuantificar la sencillez de la aplicación al utilizarla y se puedr medir en términos de las características p r e s e n t a d a s e n el capítulo 12. Los cuatro factores a p e n a s descritos sólo representan u n a muestra de los que se han propuesto c o m o m e d i d a s para la calidad del software. El capítulo 15 considera este tópico con mayor detalle.

22.3.2 Eficacia en la eliminación de defectos Una métrica de calidad que ofrece beneficios tanto en el ámbito del proyecto c o m o en el del proceso es la eficacia en la eliminación de defectos (EED). En esencia, la EEI es una medida de la habilidad de filtrar las actividades de la garantía de cualidad y de control conforme se aplica a través de todas las actividades del m a r c o de traba;:» TM del proceso. Cuando se considera un proyecto c o m o un todo, la EED se define de la manera siguiente:

PDF Editor EED = £ / ( £ + D)

d o n d e £ es el n ú m e r o de errores e n c o n t r a d o s a n t e s de entregar el s o f t w a r e al usuario final, y D es el n ú m e r o de defectos e n c o n t r a d o s d e s p u é s de la entrega.

CAPÍTULO 22

MÉTRICAS DE PROCESO y PROYECTO

679

El v a l o r ideal d e la EED e s 1. E s t o e s : n o s e e n c u e n t r a d e f e c t o a l g u n o e n el s o f t w a re. En realidad, D s e r á m a y o r q u e 0, p e r o el v a l o r de EED t o d a v í a p u e d e a c e r c a r s e a s baja t avanza en • el diseño, imós mejorarlo '.se los revi-

1. C o n f o r m e E a u m e n t a (para u n v a l o r d a d o d e D), el v a l o r global de EED c o m i e n z a a a c e r c a r s e a I. De h e c h o , c o n f o r m e E a u m e n t a , e s p r o b a b l e q u e el v a l o r final d e D d i s m i n u y a (los e r r o r e s s e filtran a n t e s de q u e s e c o n v i e r t a n e n d e f e c t o s ) . Si se utiliz a c o m o u n a m é t r i c a q u e p r o p o r c i o n a u n i n d i c a d o r de la h a b i l i d a d d e filtrado d e l a s a c t i v i d a d e s d e control y a s e g u r a m i e n t o d e la calidad, EED a l i e n t a a u n e q u i p o d e p r o y e c t o de s o f t w a r e a instituir t é c n i c a s p a r a e n c o n t r a r t a n t o s e r r o r e s c o m o s e a p o sible a n t e s de la e n t r e g a . La EED t a m b i é n s e p u e d e aplicar e n el p r o y e c t o p a r a v a l o r a r la h a b i l i d a d de u n e q u i p o de e n c o n t r a r e r r o r e s a n t e s d e q u e p a s e n a la s i g u i e n t e actividad del m a r c o d e t r a b a j o o a la siguiente t a r e a en la ingeniería del s o f t w a r e . Por ejemplo, la t a r e a de a n á lisis d e r e q u i s i t o s p r o d u c e un m o d e l o de a n á l i s i s q u e s e revisa p a r a e n c o n t r a r y c o rregir e r r o r e s . A q u e l l o s e r r o r e s q u e n o s e e n c u e n t r a n d u r a n t e la revisión del m o d e lo d e a n á l i s i s p a s a n al d i s e ñ o ( d o n d e p u e d e n o n o e n c o n t r a r s e ) . C u a n d o se aplica e n e s t e c o n t e x t o la EED s e r e d e f i n e c o m o EED,- = £ / ( £ , + £ / + l ) d o n d e E¡ e s el n ú m e r o d e e r r o r e s e n c o n t r a d o d u r a n t e la actividad i d e i n g e n i e r í a d e s o f t w a r e y E ¡ , , e s el n ú m e r o d e e r r o r e s e n c o n t r a d o d u r a n t e la actividad / + 1 d e ing e n i e r í a del s o f t w a r e q u e s e p u e d e seguir p a r a llegar a e r r o r e s q u e n o f u e r o n d e s c u b i e r t o s e n la actividad i d e i n g e n i e r í a del s o f t w a r e . Un o b j e t i v o d e calidad p a r a u n e q u i p o d e s o f t w a r e (o un i n g e n i e r o d e s o f t w a r e individual) e s lograr u n a EED, q u e s e a c e r q u e a 1. Esto es: los e r r o r e s d e b e n filtrarse a n t e s de q u e p a s e n a la s i g u i e n t e actividad.

HOGARSEGURO

Establecimiento de un enfoque de métricas El e s c e n a r i o : O f i c i n a d e D o u g

V i n o d : N u e s t r a s métricas se d e b e n e n f o c a r e n la cali-

dos d í a s d e s p u é s d e la reunión inicial a c e r c a d e -as d e software.

d a d . De h e c h o , nuestra m e t a global e s m a n t e n e r e n un ;

mínimo a b s o l u t o el n ú m e r o d e errores q u e pasamos, d e

e s : D o u g Miller ¡ g e r e n t e del e q u i p o d e inge-

u n a a c t i v i d a d d e i n g e n i e r í a del s o f t w a r e a l a siguiente.

s o f t w a r e d e HogarSeguro)

y Vinod R a m a n y

t o z a r , m i e m b r o s del e q u i p o d e ingeniería d e softdel p r o d u c t o .

ersación: ¿Ustedes d o s tienen o p o r t u n i d a d d e a p r e n d e r un a c e r c a d e métricos del p r o c e s o y el proyecto?

D o u g : Y a s e g ú r e n s e m u y bien d e q u e el n ú m e r o d e defectos l i b e r a d o s c o n el p r o d u c t o se m a n t e n g a tan c e r c a d e c e r o c o m o sea posible.

TM

V i n o d ( a s i e n t e c o n l a c a b e z a ) : Desde l u e g o . J a m i e : Me gusta la EED c o m o métrica,, y erijo q u e p o -

PDF Editor 1

y J a m i e : [ A m b o s asienten con la c a b e z a . ]

• S i e m p r e es u n a b u e n a idea establecer metas c u a n

a d o p t a n a l g u n a métricas. ¿Cuáles son las suyas?

d e m o s e m p l e a r l a e n todo el proyecto. A d e m á s , p o d e m o s aplicoHa c o n f o r m e nos m o v a m o s d e u n e a c t i v i d a d d e l m o r c o d e t r a b a d a le siguiente. Eso n o s a l e n t a r é p a r o encortror errores e n c o d o paso.

PARTE CUATRO


V i n o d : También me gustaría reunir el número de horas que pasamos en las revisiones

D o u g (sonríe): Creo que tendremos que conservar edé simple.

J a m i e : Y el esfuerzo global que pasamos en cada tarea de ingeniería del software.

V i n o d : Deberíamos, pero una vez que te metes en e asunto de las métricas, existen muchas cosas interese •= t que observar.

D o u g : Tú puedes calcular una razón d e revisión a desarrollo... podría ser interesante. J a m i e : Me gustaría seguir también algunos datos d e caso de-uso, Como la cantidad de esfuerzo requerido para desarrollar un caso de uso, la cantidad d e esfuerzo requerido para construir software para implementar un caso d e uso y...

2 2 . 4

D o u g : Estoy de acuerdo, pero caminemos antes de cc rrer, y apeguémonos a nuestra meta. Limiten los datos que recopilen a cinco o seis elementos, y estamos listo; para despegar. ^

I N T E G R A C I Ó N D E LAS M É T R I C A S D E N T R O DEL P R O C E S O DE SOFTV.AI La m a y o r í a d e los d e s a r r o l l a d o r e s de s o f t w a r e t o d a v í a n o m i d e n y, p o r d e s g r a r J m u c h o s t i e n e n p o c o d e s e o de c o m e n z a r . C o m o s e h a s e ñ a l a d o e n e s t e c a p í t u l : M p r o b l e m a e s cultural. El i n t e n t o d e recopilar m e d i d a s d o n d e n a d i e lo h a h e c h o en e: J s a d o c o n f r e c u e n c i a g e n e r a r e s i s t e n c i a . "¿Por q u é t e n e m o s q u e h a c e r e s t o ? " p r e r _ r J ta u n g e s t o r d e p r o y e c t o a c o s a d o . "No le v e o el caso", s e q u e j a u n p r o f e s i o n a l :xm exceso de trabajo. En e s t a s e c c i ó n s e c o n s i d e r a n a l g u n o s a r g u m e n t o s p a r a las m é t r i c a s d e softv, 2 J y s e p r e s e n t a un e n f o q u e p a r a instituir u n p r o g r a m a de r e c o p i l a c i ó n de m é t r i c a s u n a o r g a n i z a c i ó n de ingeniería del s o f t w a r e . P e r o a n t e s de c o m e n z a r , c o n v i e n e » s i d e r a r [GRA87] a l g u n a s p a l a b r a s d e c o r d u r a d e G r a d y y Caswell: Algunas d e las c o s a s que describimos aquí sonarán b a s t a n t e sencillas. En realidad, sir embargo, el establecimiento d e un programa d e métricas de software exitoso e n el á m t to de la compañía es un trabajo duro. C u a n d o decimos que se debe esperar al m e n o s tres a ñ o s a n t e s de q u e estén disponibles tendencias organizacionales amplias, se obtiene a g u n a idea del ámbito de tal esfuerzo.

Vale la p e n a p r e s t a r a t e n c i ó n a la a d v e r t e n c i a q u e s u g i e r e n e s t o s a u t o r e s , p e r o J : » b e n e f i c i o s d e la m e d i c i ó n s o n t a n c o n v i n c e n t e s q u e el t r a b a j o d u r o v a l e la p e n a

22.4.1 Argumentos para las métricas del software TM

¿Por q u é e s i m p o r t a n t e m e d i r el p r o c e s o d e ingeniería del s o f t w a r e y el producá» (software) q u e e l a b o r a ? La r e s p u e s t a e s r e l a t i v a m e n t e obvia. Si n o s e mide, n o e x s *

PDF Editor

te u n a f o r m a real d e d e t e r m i n a r si s e e s t á m e j o r a n d o . Y si n o se m e j o r a , s e está pe-' dido.

Al c u e s t i o n a r y e v a l u a r la p r o d u c t i v i d a d y las m e d i d a s d e calidad, u n e q u i p o

s o f t w a r e (y su gestión) p u e d e e s t a b l e c e r m e t a s significativas p a r a m e j o r a r el proce-J s o del s o f t w a r e . En el c a p í t u l o 1 s e a p u n t ó q u e el s o f t w a r e e s u n t e m a c o m e r c i a l e s J

CAPÍTULO 22

681

MÉTRICAS DE PROCESO Y PSOYECTO

t r a t é g i c o p a r a m u c h a s c o m p a ñ í a s . Si el p r o c e s o c o n el cual se d e s a r r o l l a p u e d e m e j o r a r s e , s e p r o d u c i r á u n i m p a c t o d i r e c t o e n lo s u s t a n c i a l . P e r o p a r a e s t a b l e c e r o b j e tivos de m e j o r a e s p r e c i s o c o m p r e n d e r el e s t a d o a c t u a l del d e s a r r o l l o d e s o f t w a r e Por lo t a n t o , la m e d i c i ó n s e e m p l e a p a r a e s t a b l e c e r u n a línea b a s e d e p r o c e s o a partir de la c u a l se e v a l ú a n las m e j o r a s .

"Gestionamos las cosas mediante los números en muchos aspectos de nuestras v i d a s . . . Estos números nos brindan paridad d e juicio y nos ayudan a dirigir nuestras acciones." Mfchael M a h y Larry Los r i g o r e s c o t i d i a n o s del t r a b a j o del p r o y e c t o d e s o f t w a r e d e j a n p o c o t i e m p o p a ra ejercitar el p e n s a m i e n t o e s t r a t é g i c o . Los g e s t o r e s d e p r o y e c t o s d e s o f t w a r e e s t á n preocupados con temas m á s concretos (aunque igualmente importantes): desarrollar e s t i m a c i o n e s d e p r o y e c t o significativas, p r o d u c i r s i s t e m a s d e alta calidad, t e n e r el p r o d u c t o e n circulación a t i e m p o . Si s e e m p l e a la m e d i c i ó n p a r a e s t a b l e c e r u n a lin e a b a s e del p r o y e c t o , c a d a u n o d e d i c h o s t e m a s s e v u e l v e m á s m a n e j a b l e . Ya s e ha m e n c i o n a d o q u e la línea b a s e sirve c o m o f u n d a m e n t o p a r a la e s t i m a c i ó n . Adicionaim e n t e , la r e c o p i l a c i ó n de m é t r i c a s d e calidad p e r m i t e q u e u n a o r g a n i z a c i ó n " s i n : : n i c e " s u p r o c e s o d e s o f t w a r e p a r a r e m o v e r las c a u s a s " p o c o vitales" d e los d e f e c t o ; q u e t i e n e n el m a y o r i m p a c t o s o b r e el d e s a r r o l l o del s o f t w a r e . 1 0

22.4.2 Establecimiento d e u n a línea base I ¿ Q u é e s una 11*1®

«le"6 irciona a un i de Ire -

Con el e s t a b l e c i m i e n t o d e u n a línea b a s e de m é t r i c a s s e o b t i e n e n b e n e f i c i o s e n los á m b i t o s del p r o c e s o , del p r o y e c t o y del p r o d u c t o (técnico). I n c l u s o la i n f o r m a c i ó n q u e

Se recoP"'a

n o

^ c e s i t a ser f u n d a m e n t a l m e n t e d i f e r e n t e . Las m i s m a s m é t r i c a s

p u e d e n servir a m u c h o s m a e s t r o s . La línea b a s e de m é t r i c a s c o n s i s t e d e d a t o s r e c o p i l a d o s e n p r o y e c t o s p r e v i o s d e d e s a r r o l l o d e s o f t w a r e y p u e d e n s e r tan s i m p l e s c o m o la t a b l a p r e s e n t a d a e n la figura 22.2 o tan c o m p l e j o s c o m o u n a b a s e d e d a t o s d e tallada q u e c o n t i e n e d o c e n a s d e m e d i d a s de p r o y e c t o s y las m é t r i c a s d e r i v a d a s de éstos. Para s e r un auxiliar eficaz e n el p r o c e s o de m e j o r a o de c o s t o y e s f u e r z o , los d a t o s d e la l í n e a b a s e d e b e n t e n e r los s i g u i e n t e s a t r i b u t o s : 1) los d a t o s d e b e n s e r r a z o n a b l e m e n t e p r e c i s o s : s e d e b e n evitar las " c o n j e t u r a s " a c e r c a d e los p r o y e c t o s p a s a d o s 2) los d a t o s d e b e n r e c o p i l a r s e p a r a t a n t o s p r o y e c t o s c o m o s e a posible; 3) l a s m e d i d a s d e b e n s e r c o n s i s t e n t e s , p o r e j e m p l o : u n a l í n e a de c ó d i g o d e b e i n t e r p r e t a r s e c o n s i s t e n t e m e n t e a t r a v é s d e t o d o s los p r o y e c t o s p a r a los q u e s e rTM e c o p i l a n los d a t o s ; 4) las a p l i c a c i o n e s d e b e n s e r s i m i l a r e s al t r a b a j o q u e se e s t i m a r á : t i e n e p o c o s e n t i d o e m p l e a r u n a línea b a s e e n u n t r a b a j o d e s i s t e m a s de i n f o r m a c i ó n e n b l o q u e p a r a es-

PDF Editor t i m a r u n a a p l i c a c i ó n a n i d a d a e n t i e m p o real.

10

En el capitulo 26 se tratan con detalle estas :deas. formalizadas en un enfoque denominado garan-

tía estadística de calidad del software.

682

PARTE CUATRO

G E S T I Ó N DE PROYECTOS DE S O F T W A R E

Proceso de recopilación de métricas de software.

d e métricas I

Indicadores

22.4.3 Recopilación, cálculo y evaluación de métricas

\ CLAVE

En la figura 2 2 . 3 s e ilustra el p r o c e s o c o n el q u e s e e s t a b l e c e u n a línea b a s e d e mé-

Los datos de métricos de lineo base deben recopilarse de uno gran muestra representativa de proyectos de software previos.

m e s e a v a n z a . Por d e s g r a c i a , e s t o rara v e z e s el c a s o . En c o n s e c u e n c i a , la recopila-

tricas. De m a n e r a ideal, l o s d a t o s n e c e s a r i o s p a r a h a c e r l o s e h a n r e c o p i l a d o conforción d e d a t o s r e q u i e r e u n a i n v e s t i g a c i ó n histórica d e los p r o y e c t o s p r e v i o s p a r a rec o n s t r u i r l o s d a t o s r e q u e r i d o s . U n a v e z q u e s e h a n r e c o p i l a d o las m e d i d a s (incuest i o n a b l e m e n t e el p a s o m á s difícil) e s p o s i b l e c a l c u l a r l a s m é t r i c a s . D e p e n d i e n d o de la a m p l i t u d d e las m e d i d a s r e c o p i l a d a s , l a s m é t r i c a s p u e d e n a b a r c a r u n a a m p l i a ga m a d e m é t r i c a s o r i e n t a d a s a la a p l i c a c i ó n (por e j e m p l o , LDC, PF, o r i e n t a d a a o b j e t o s , WebApp), así c o m o o t r a s o r i e n t a d a s a la c a l i d a d y al p r o y e c t o . F i n a l m e n t e , l a s métricas d e b e n e v a l u a r s e y a p l i c a r s e d u r a n t e la e s t i m a c i ó n del t r a b a j o t é c n i c o , el control del p r o y e c t o y la m e j o r a del p r o c e s o . La e v a l u a c i ó n d e l a s m é t r i c a s s e c e n t r a e r l a s r a z o n e s s u b y a c e n t e s d e l o s r e s u l t a d o s o b t e n i d o s y p r o d u c e u n c o n j u n t o d e indic a d o r e s q u e g u í a n el p r o y e c t o o p r o c e s o .

La g r a n m a y o r í a d e l a s o r g a n i z a c i o n e s d e d e s a r r o l l o d e s o f t w a r e tiene m e n o s d e 2C ÔNSfJO^ Sise estó comenzando o recopilar datos de métricas, recuérdese mantenerlos simples. Silos dalos abruman los esfuerzos de métricos ka/soto.

e m p l e a d o s . E s irracional, y e n la m a y o r í a d e los c a s o s irreal, e s p e TM r a r q u e t a l e s organ i z a c i o n e s d e s a r r o l l a r á n p r o g r a m a s d e t a l l a d o s d e m é t r i c a s d e s o f t w a r e . Sin e m b a r go, e s r a z o n a b l e s u g e r i r q u e l a s o r g a n i z a c i o n e s d e s o f t w a r e de t o d o s los t a m a ñ o s

PDF Editor

miden y luego emplean las métricas resultantes para ayudar a mejorar s u s procesos

d e s o f t w a r e l o c a l e s y la calidad y la p u n t u a l i d a d d e los p r o d u c t o s q u e e l a b o r a n . Un e n f o q u e de s e n t i d o c o m ú n r e s p e c t o d e la i m p l e m e n t a c i ó n d e c u a l q u i e r activi-

d a d r e l a c i o n a d a c o n el p r o c e s o d e s o f t w a r e e s m a n t e n e r l o simple, personalizarlo para s a t i s f a c e r l a s n e c e s i d a d e s l o c a l e s y a s e g u r a r s e d e q u e a g r e g a valor. En los p á r r a f o s

CAPÍTULO 22

¿Cómo se te un de de s o f t * simple"?

683


q u e s i g u e n se e x a m i n a c ó m o e s t o s l i n c a m i e n t o s s e r e l a c i o n a n c o n las m é t r i c a s p a ra p e q u e ñ o s negocios." " M a n t e n e r l o s i m p l e " e s u n a directriz q u e f u n c i o n a r a z o n a b l e m e n t e bien e n m u c h a s a c t i v i d a d e s . Pero, ¿ c ó m o s e d e d u c e u n c o n j u n t o "simple" d e m é t r i c a s de s o f t w a r e q u e a u n así p r o p o r c i o n e valor, y c ó m o s e g a r a n t i z a q u e d i c h a s m é t r i c a s s i m p l e s s a t i s f a r á n las n e c e s i d a d e s d e u n a o r g a n i z a c i ó n de s o f t w a r e p a r t i c u l a r ? Un b u e r . c o m i e n z o c o n s i s t e e n e n f o c a r s e n o s o b r e las m e d i c i o n e s s i n o m á s bien s o b r e los res u l t a d o s . Al g r u p o de s o f t w a r e s e le e n t r e v i s t a p a r a definir un o b j e t i v o sencillo q u e r e q u i e r e m e j o r a . Por e j e m p l o , "reducir el t i e m p o p a r a e v a l u a r e i m p l e m e n t a r los c a m b i o s solicitados". U n a o r g a n i z a c i ó n p e q u e ñ a p u e d e s e l e c c i o n a r el s i g u i e n t e c o r j u n t o d e m e d i d a s q u e s e r e c o p i l a n c o n facilidad: • T i e m p o ( h o r a s o días) t r a n s c u r r i d o d e s d e el m o m e n t o e n q u e s e h i z o u n a solicitud h a s t a q u e la e v a l u a c i ó n e s t á c o m p l e t a , tcola. • E s f u e r z o ( p e r s o n a - h o r a s ) p a r a r e a l i z a r la e v a l u a c i ó n , Tmal. • T i e m p o ( h o r a s o días) t r a n s c u r r i d o d e s d e q u e s e c o m p l e t a la e v a l u a c i ó n h a s t a la a s i g n a c i ó n del p e d i d o d e c a m b i o al p e r s o n a l , £„«/• • E s f u e r z o ( p e r s o n a - h o r a s ) r e q u e r i d o p a r a h a c e r el c a m b i o , Tcamh¡0. • T i e m p o r e q u e r i d o ( h o r a s o días) p a r a h a c e r el c a m b i o , tClimhi0. • Errores d e s c u b i e r t o s d u r a n t e el t r a b a j o p a r a h a c e r el c a m b i o , Ecambio. • D e f e c t o s d e s c u b i e r t o s d e s p u é s de q u e el c a m b i o e s liberado a la b a s e de clientes, Dcambio. Una v e z q u e se h a n r e c o p i l a d o d i c h a s m e d i d a s p a r a v a r i o s c a m b i o s s o l i c i t a d o s es posible calcular el t i e m p o t r a n s c u r r i d o total p r o m e d i o d e s d e q u e el c a m b i o se solicitó h a s t a la i m p l e m e n t a c i ó n del c a m b i o y el p o r c e n t a j e del t i e m p o transcurrido a b s o r b i d o p o r la cola d e e s p e r a inicial, la e v a l u a c i ó n y la a s i g n a c i ó n y la i m p l e m e n t a c i xi del c a m b i o . De igual m o d o , e s posible d e t e r m i n a r el p o r c e n t a j e del e s f u e r z o q u e req u i e r e n la e v a l u a c i ó n y la i m p l e m e n t a c i ó n . Estas m é t r i c a s se e v a l ú a n e n el c o n t e x t o de los d a t o s de calidad, Ecambto y Dcambio. Los p o r c e n t a j e s p r o p o r c i o n a n conocimierít d e t a l l a d o de d ó n d e s e vuelve lento el p r o c e s o de solicitud de c a m b i o y c o n d u c e a pas o s de m e j o r a del p r o c e s o p a r a reducir

Tavl, f m J / , Tcambi0 o Ecambk>. A d e m á s , la efica-

cia en la d e eliminación de d e f e c t o s s e p u e d e calcular c o m o EED = EamMg/(Ecamt,io + Dcarnb¡„)

TM

EED s e c o m p a r a c o n el t i e m p o t r a n s c u r r i d o y el e s f u e r z o total p a r a d e t e r m i n a r el im-

PDF Editor

p a c t o de l a s a c t i v i d a d e s d e a s e g u r a m i e n t o d e la calidad e n el t i e m p o y el e s f u e r z c requeridos para realizar un cambio.

11 Esta exposición es igualmente relevante para ios equipos de software que han adoptado un proceso de desarrollo de software ágil (capitulo 4

684

PARTE CUATRO

2 2 . 6


E S T A B L E C I M I E N T O DE UN P R O G R A M A DE M É T R I C A S DE SOFTWAT El S o f t w a r e E n g i n e e r i n g Institute (SE1) h a e l a b o r a d o u n a guía d e t a l l a d a [PAR96] para e s t a b l e c e r u n p r o g r a m a d e m é t r i c a s d e s o f t w a r e "dirigido p o r m e t a s " . La guía sugiere los s i g u i e n t e s p a s o s : 1.

identificar los o b j e t i v o s d e la e m p r e s a .

AGMefwGoolDtmi 2. Software Meosviement

se puede descargor de: www.sei.anii.edu.

Identificar lo q u e se q u i e r e c o n o c e r o a p r e n d e r .

3.

Identificar los s u b o b j e t i v o s .

4.

Identificar las e n t i d a d e s y a t r i b u t o s r e l a c i o n a d o s c o n los o b j e t i v o s s e c u n d a r i o s .

5.

F o r m a l i z a r l o s o b j e t i v o s d e la m e d i c i ó n .

6.

Identificar p r e g u n t a s c u a n t i f i c a b l e s y los i n d i c a d o r e s r e l a c i o n a d o s q u e s e emp l e a r á n c o m o a p o y o p a r a l o g r a r los o b j e t i v o s d e s u s m e d i c i o n e s .

7.

Identificar los e l e m e n t o s de d a t o s q u e s e r e c o p i l a r á n p a r a c o n s t r u i r los indic a d o r e s q u e a y u d a r á n a r e s p o n d e r las p r e g u n t a s .

8.

Definir las m e d i d a s q u e s e e m p l e a r á n y h a c e r q u e e s t a s d e f i n i c i o n e s s e a n operativas.

9.

Identificar las a c c i o n e s q u e s e t o m a r á n p a r a i m p l e m e n t a r l a s m e d i d a s .

10.

P r e p a r a r un p l a n p a r a i m p l e m e n t a r las m e d i d a s .

Una e x p o s i c i ó n d e t a l l a d a d e e s t o s p a s o s m e j o r s e d e j a p a r a el libro del SEI. Sin e m b a r g o , bien v a l e la p e n a d a r un b r e v e v i s t a z o a los p u n t o s clave.

CLAVE las métricas de software que s e elijan deben estar basados en las metas de negocios y técnicas que se deseon lograr.

P u e s t o q u e las f u n c i o n e s c o m e r c i a l e s d e a p o y o del s o f t w a r e d i f e r e n c i a n los siste m a s o p r o d u c t o s b a s a d o s e n c o m p u t a d o r a , o a c t ú a n c o m o u n p r o d u c t o e n sí m i s m o , las m e t a s d e f i n i d a s p a r a las e m p r e s a s c a s i s i e m p r e p u e d e n s e g u i r s e h a c i a a b a j o h a s ta m e t a s e s p e c í f i c a s al nivel d e la ingeniería del s o f t w a r e . Por e j e m p l o , c o n s i d é r e s e u n a c o m p a ñ í a q u e fabrica a v a n z a d o s s i s t e m a s de s e g u r i d a d p a r a el h o g a r q u e t i e n e c o n t e n i d o d e s o f t w a r e s u s t a n c i a l . Al t r a b a j a r c o m o e q u i p o , la i n g e n i e r í a del s o f t w a re y los g e s t o r e s del n e g o c i o p u e d e n c o n f e c c i o n a r u n a lista d e m e t a s p r i o r i z a d a s dei negocio: 1.

M e j o r a r la s a t i s f a c c i ó n de los c l i e n t e s c o n l o s p r o d u c t o s .

2.

H a c e r q u e los p r o d u c t o s s e a n m á s f á c i l e s d e u s a r .

3.

Reducir el t i e m p o q u e t o m a p o n e r u n p r o d u c t o e n el m e r c a d oTM .

4.

Simplificar el s o p o r t e p a r a l o s p r o d u c t o s .

PDF Editor 5.

M e j o r a r la o b t e n c i ó n global de utilidades.

La o r g a n i z a c i ó n d e s o f t w a r e e x a m i n a c a d a m e t a d e n e g o c i o s y p r e g u n t a : ¿ Q u é activ i d a d e s s e g e s t i o n a n o e j e c u t a n y q u é s e q u i e r e m e j o r a r d e d i c h a s a c t i v i d a d e s ? Para r e s p o n d e r e s t a s p r e g u n t a s el SEI r e c o m i e n d a la c r e a c i ó n d e u n a "lista e n t i d a d - p r e g u n t a " e n la q u e s e a n o t e n t o d a s las c o s a s (entidades) d e n t r o del p r o c e s o de s o f t w a -

CAPÍTULO 22

MÉTRICAS

DE PROCESO Y PROYECTO

685

re que s e gestionan o en las que influye la organización de software. Los ejemplos de entidades incluyen recursos de desarrollo, productos d e trabajo, código fuente, c a s o s de prueba, solicitudes de cambio, tareas de ingeniería del s o f t w a r e y planificaciones. Para cada entidad en la lista el personal de s o f t w a r e desarrolla un conjunto de preguntas que evalúan características cuantitativas de la entidad (por ejemplo, tam a ñ o , costo, tiempo de desarrollo). Las preguntas que se derivan de la creación de una lista entidad-pregunta c o n d u c e n a la derivación de u n c o n j u n t o de subobjetivos q u e se relacionan directamente con las entidades creadas y las actividades realizad a s c o m o parte del proceso del software. Considérese la cuarta meta: "Simplificar el soporte para los productos". Para esta meta se p u e d e derivar la siguiente lista de preguntas [PAR96]: • ¿La solicitud de c a m b i o del cliente contiene la información requerida para evaluar a d e c u a d a m e n t e el c a m b i o y luego implementarlo e n u n a forma oportuna? • ¿Cuán grande e s el registro de petición de cambio? • ¿El tiempo de respuesta para fijar los bugs e s aceptable con b a s e en las necesidades del cliente? • ¿Se sigue el proceso de control de cambios (capítulo 27)? • ¿Los c a m b i o s de alta prioridad se implementan en forma oportuna? Con b a s e en e s t a s preguntas la organización de software p u e d e deducir el siguiente subobjetivo: mejorar el desempeño

del proceso de gestión de cambio. Se identifican las

entidades y los atributos del proceso de s o f t w a r e relevantes respecto del subobjetivo, y se delinean las m e t a s de medición a s o c i a d a s con a m b o s elementos. El SEI [PAR96] proporciona u n a guía detallada para los p a s o s 6 al 10 de su enfoque de medición orientado a objetivos. En esencia, se aplica un proceso d e refinamiento p a s o a p a s o en el que los objetivos s e retinan en preguntas q u e posteriorm e n t e se refinan e n entidades y atributos que e n t o n c e s se retinan en métricas.

Establecimiento de un programa de métricas El Software Productivity Center (www.spc.ca) sugiere un enfoque d e ocho pasos para r un programa de métricas dentro de una ización d e software y que se puede emplear como va al enfoque del SEI descrito en la sección 22.ó. enfoque se resume a continuación.

Se definen las tareas asociadas con c a d a actividad. Se anotan las funciones de aseguramiento de la TM calidad. Se hoce una lista con los productos de trabajo producidos.

PDF Editor Entender el proceso de software existente. Se definen las actividades del marco de trabajo (capítulo 2). Se describe la información d e entrada para cada actividad.

\

2.

Definir los objetivos que se lograrán mediante el establecimiento de un programa de métricas. Ejemplos: mejorar la precisión de la estimación, mejorar lo colidod del producto.

y

686

r

3.

PARTE CUATRO


Identificar las métricas requeridas para lograr los objetivos. Se definen las preguntas que deben responderse; por ejemplo, ¿cuántos errores encontrados en una actividad de marco de trabajo pueden seguirse hasta la actividad del marco de trabajo precedente? Crear medidas y métricas que serán recopiladas y calculadas.

4.

Identificar las medidas y métricas que serán recopiladas y calculadas.

5.

Establecer un proceso de recopilación de medidas respondiendo las siguientes preguntas: ¿Cuál es la fuente de las mediciones? ¿Las herramientas se pueden emplear en la recopilación de los datos?

¿Qué mecanismos de validación se aplican para garantizar que los datos sean correctos? 6.

Adquirir herramientas adecuadas para apoyar la recopilación y evaluación.

7.

Establecer una base de datos de métricas. Se establece la complejidad relativa de la base de datos. Se explora el empleo de herramientas relacionadas (por ejemplo, un almacén SCM, capítulo 27). Se evalúan los productos de base de datos existentes.

8.

¿Quién requiere información de métricas en marcha? ¿Cómo se entregará la información?

¿Quién es responsable de la recopilación de datos? ¿Cuándo se recopilan y registran los datos? ¿Cómo se almacenan los datos?

Definir mecanismos de realimentación adecuados.

¿Cuál es el formato de la información? Una descripción considerablemente más detallada de esto; ochos pasos se puede descargar de http://www.spc.ca/resources/metrics/.

Las m e d i c i o n e s permite n que los g e s t o r e s y p r o f e s i o n a l e s m e j o r e n el p r o c e s o software; auxilien en la planificación, s e g u i m i e n t o y control d e un proyecto d e s< ware; y e v a l ú e n la calidad del p r o d u c t o (software) q u e se produce. Las m e d i d a s atributos específicos del p r o c e s o , proyecto y p r o d u c t o s e utilizan para calcular i tricas d e s o f t w a r e . Dichas métricas s e p u e d e n a n a l i z a r p a r a o f r e c e r indicadores i guíen las a c c i o n e s d e gestión y técnica. Las m é t r i c a s del p r o c e s o permite n q u e u n a o r g a n i z a c i ó n a d o p t e u n a visión estr tégica al p r o p o r c i o n a r información detallada d e la eficacia d e un p r o c e s o d e softv re. Las m é t r i c a s d e proyecto s o n tácticas; p e r m i t en q u e un gestor d e p r o y e c t o ada te el flujo de trabajo del proyecto y un e n f o q u e técnico realista en términos d e tiemp TM Las métricas o r i e n t a d a s t a n t o al t a m a ñ o c o m o a la función s e aplican a lo lar d e toda la industria. Las métricas o r i e n t a d a s al t a m a ñ o e m p l e a n la línea d e c ó d i j

PDF Editor

c o m o un factor d e normalización para o t r a s m e d i d a s c o m o p e r s o n a - m e s o defecto El p u n t o d e función se d e d u c e d e las m e d i d a s del d o m i n i o de la información y d e i

valoración subjetiva d e la complejidad del problema. A d e m á s , s e p u e d e n utilizar I m é t r i c a s o r i e n t a d a s a objetos y las m é t r i c a s d e aplicación Web.

Las m é t r i c a s d e calidad del s o f t w a r e , c o m o las métricas d e productividad, s e er

f o c a n s o b r e el proceso, el proyecto y el producto. Al desarrollar y a n a l i z a r u n a líne

CAPÍTULO 22


687

b a s e d e m é t r i c a s p a r a la c a l i d a d , u n a o r g a n i z a c i ó n p u e d e c o r r e g i r a q u e l l a s á r e a s d e l proceso de software que causan defectos de software. La m e d i c i ó n r e s u l t a e n c a m b i o s c u l t u r a l e s . La r e c o p i l a c i ó n d e d a t o s , el c á l c u l o y el a n á l i s i s d e m é t r i c a s s o n l o s t r e s p a s o s q u e p r e c i s o i m p l e m e n t a r p a r a c o m e n z a r u n p r o g r a m a d e m é t r i c a s . En g e n e r a l , u n e n f o q u e o r i e n t a d o a o b j e t i v o s a y u d a a q u e u n a o r g a n i z a c i ó n s e e n f o q u e e n l a s m é t r i c a s c o r r e c t a s p a r a s u n e g o c i o . Al c r e a r u n a línea base de métricas —una base de datos que contiene mediciones de proceso y p r o d u c t o — l o s i n g e n i e r o s d e s o f t w a r e y s u s g e s t o r e s p u e d e n c o m p r e n d e r m e j o r el t r a b a j o q u e h a c e n y el p r o d u c t o q u e e l a b o r a n .

[ALB831 Albrecht, A. J. y J. E. Gaffney, "Software Function, S o u r c e Lines of Code a n d Developm e n t Effort Prediction. A S o f t w a r e Science Validation", e n IEEE Ttans. Software Ertgirccring, n o v i e m b r e de 1983, pp. 639-648. [BOE81] Boehm, B„ Software Engineering Economics, Prentice-Hall, 1981. [GRA87| Grady, R. B. y D. L. Caswell, Software Metrics: Establishing a Company-Wide Program, Prentice-Hall, 1987. IGRA92] Grady, R. G., Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, 1992. [G1L88] Gilb, T„ Principies of Software Project Management, Addison-Wesley, 1988. [HET93] Hetzel, W., Making Software Measurement Work, QED Publishing Group, 1993. [HUM95] Humphrey, W., A Discipline for Software Engineering, Addison-Wesley, 1995. [1EE93] IEEE Software Engineering Standards, Standard 610.12-1990, pp. 47-48. [JON86] Jones, C., Programming Productivity, McGraw-Hill, 1986. [JON9I] Jones, C., Applied Software Measurement, McGraw-Hill, 1991. UON98] Jones, C., Estimating Software Costs, McGraw-Hill, 1998. [LOR94] Lorenz, M. y j . Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994. [PAR96] Park, R. E., W. B. Goethert y W. A. Florac, Goal Driven Software Measurement—A Guidebook, CMU/SE1-96-BH-002, S o f t w a r e Engineering Institute, Carnegie Mellon University, a g o s t o d e 1996. [PAU94] Paulish, D. y A. Carleton, "Case Studies of S o f t w a r e Process Improvement Measurement", en Computer, vol. 27, n ú m . 9, s e p t i e m b r e de 1994, pp. 50-57. [QSM02] "QSM Function Point L a n g u a g e Gearing Factors", Versión 2.0, Quantitative S o f t w a r e M a n a g e m e n t , 2002, h t t p : / / w w w . q s m . c o m / F P G e a r i n g . h t m l . IRAG95] Ragland, B„ "Measure, Metric or Indicator: What's the Difference?", e n Crosstalk, vol. 8, n ú m . 3, m a r z o d e 1995, pp. 29-30. |SMI99] Smith, J., "The Estimation of Effort Based o n Use-Cases", un artículo de Rational Corporation, 1999, s e p u e d e d e s c a r g a r de h t t p : / / w w w . r a t i o n a l . c o m / p r o d u c t s / r u p / w h i t e p a pers.jsp.

2 2 . 1 . Describir con palabras propias la diferencia e n t r e m é t r i c a s del p r o c e s o TM y del proyecto. 22.2. ¿Por q u é a l g u n a s m é t r i c a s d e s o f t w a r e d e b e n c o n s e r v a r s e "privadas"? Ofrecer e j e m p l o s d e tres m é t r i c a s q u e d e b a n ser p r i v a d a s Ofrecer e i e m p l o s d e tres m é t r i c a s q u e d e b a n ser públicas.

PDF Editor

22.3. ¿Qué es u n a m e d i d a indirecta y p o r q u e tales m e d i d a s s o n c o m u n e s e n el t r a b a j o d e m é tricas del s o f t w a r e ? 22.4. Grady sugiere u n c o n j u n t o de reglas de etiqueta r a r a las m é t r i c a s d e s o f t w a r e . ¿El lector p u e d e a g r e g a r tres reglas m á s a las m e n c i o r a - 3 5 e - 2 sección 22.1.1?

688

PARTE CUATRO


22.5 El equipo A e n c o n t r ó 342 errores d u r a n t e el p r o c e s o de ingeniería del s o f t w a r e previo a la liberación. El equipo B e n c o n t r ó 184 errores. ¿Qué m e d i d a s adicionales tendrían que realizar los proyectos A y B p a r a determinar cuál de los equipos eliminó los errores de m a n e r a m á s eficiente? ¿Qué métricas podrían p r o p o n e r s e p a r a ayudar a realizar la determinación? ¿Qué datos históricos p u e d e n ser útiles? 22.6. Presentar u n a r g u m e n t o contra las líneas d e código c o m o medida p a r a la productividad d e software. ¿El c a s o se sostiene c u a n d o s e consideran d o c e n a s o cientos de proyectos? 22.7. Calcular el valor de p u n t o d e función p a r a u n proyecto con las siguientes características d e dominio de información: Número Número Número Número Número

de de de de de

e n t r a d a s externas: 32 salidas e x t e m a s : 60 consultas externas: 24 archivos lógicos internos: 8 archivos d e interfaz externos: 2

S u p o n e r que t o d o s los valores de a j u s t e de complejidad s o n promedios. Utilizar el algoritmc a n o t a d o en el capitulo 15. 22.8. Emplear la tabla p r e s e n t a d a en la sección 22.2.3 para elaborar un a r g u m e n t o contra la utilización del lenguaje e n s a m b l a d o r b a s a d o en la funcionalidad e n t r e g a d a por e n u n c i a d o d e código. Véase d e nuevo la tabla y c o m e n t a r por q u é C++ presentaría u n a mejor alternativa que C 22.9. El s o f t w a r e utilizado para controlar u n a fotocopiadora requiere 32 000 LDC d e C y 4 2 0 : líneas de Smalltalk. Estimar el n ú m e r o de p u n t o s d e función para el s o f t w a r e dentro de la co- I piadora. 22.10. Un equipo d e ingeniería Web ha construido u n a WebApp d e comercio electrónico que contiene 145 p á g i n a s individuales. De e s t a s p á g i n a s 6 5 son dinámicas: e s t o es, s e g e n e r a n i r m a n e r a interna con b a s e en la e n t r a d a del usuario final. ¿Cuál e s el índice de personalización para e s t a aplicación? 2 2 . 1 1 . Una WebApp y su e n t o r n o de soporte n o han sido c o m p l e t a m e n t e reforzados contra a t a q u e s . Los ingenieros Web estiman que la probabilidad d e repeler u n a t a q u e sólo e s del 30 p o r ciento. El sistema n o c o n t i e n e información sensible o controversial, así q u e la probabilidad de a m e n a z a e s d e 2 5 por ciento. ¿Cuál e s la integridad d e la WebApp? 2 2 . 1 2 . En la conclusión d e u n proyecto q u e utilizó el Proceso Unificado (Capítulo 3) s e detem i n ó que 30 errores s e encont raro n d u r a n t e la fase de elaboración, y 12 errores hallados dui te la fase de construcción p o d í a n seguirse hasta errores q u e no fueron descubiertos en la f¡ d e elaboración. ¿Cuál e s la EED p a r a e s t a s dos fases? 22.13. Un equipo d e s o f t w a r e entrega un i n c r e m e n t o de s o f t w a r e a los u s u a r i o s finales, descubren o c h o d e f e c t o s d u r a n t e el primer m e s de uso. Antes de la entrega, el equipo de : w a r e e n c o n t r ó 242 errores d u r a n t e las revisiones técnicas formales y t o d a s las t a r e a s d e pr ba. ¿Cuál e s la EED global p a r a el proyecto?

TM La m e j o r a del proceso de software (MPS) ha recibido u n a cantidad significativa de atención i rante las d o s d é c a d a s p a s a d a s . Dado que la medición y las métricas d e s o f t w a r e s o n clave | mejorar exitosamente el p r o c e s o de software, m u c h o s libros acerca de la MPS también tratan métricas. Las f u e n t e s valiosas de información acerca de las métricas d e procesos incluyen:

PDF Editor

Burr, A. y M. Owen, Statistical Methods for Software Quaíity, International T h o m s o n Pub hing, 1996. El E m a m , K. y N. Madhavji (eds.), Elements of Software Process AssessmenC and Impr IEEE Computer Society, 1999.

CAPÍTULO 22

689


Florac, W. A. y A. D. Carleton, Measuring the Software Process: Statistical Process Control for Software Process lmprovemenl, Addison-Wesley, 1999. Garmus, D. y D. Herrón, Measuring the Software Process: A Practícal Cuide to Functional Measurements, Prentice-Hall, 1996. Humphrey, W„ Introduction to the Team Software Process, Addison-Wesley/Longman, 2000. Kan, S. H., Metrics and Models in Software Quality Engineering, Addison-Wesley, 1995. McGarry y sus colegas (Practica! Software Measurement, Addison-Wesley, 2001) presentan consejos a profundidad para valorar el proceso d e software. Haug y s u s colegas (Software Process Improvement: Metrics, Measurement, and Process Modeling, Springer-Verlag, 2001) han editado u n a colección d e artículos valiosos. Florac y Carlton (Measuring the Software Process, AddisonWesley, 1999) y Fenton y Pfleeger (Software Metrics: A Rigorous and Practical Approach, revisado, Brooks/Cole Publishers, 1998) tratan c ó m o se p u e d e n emplear las métricas d e software p a r a proporcionar los indicadores necesarios para mejorar el proceso de software. Putnam y Myers (Five Core Metrics, Dorset House, 2003) estudian u n a base de datos d e más de 6 000 proyectos de software p a r a demostrar c ó m o cinco métricas centrales —tiempo, esfuerzo, t a m a ñ o , confiabilidad y productividad de proceso— se p u e d e n e m p l e a r p a r a controlar los proyectos de software. Maxwell (Applied Statistics for Software Managers, Prentice-Hall, 2003) presenta técnicas p a r a analizar datos del proyecto d e software. Munson (Software Engineering Measurement, Auerbach, 2003) estudia un amplio abanico d e t e m a s de medición d e ingeniería del software. Jones (Software Assessments, Benchmarks and Best Pracüces, Addison-Wesley, 2000) describe tanto medidas cuantitativas c o m o factores cualitativos q u e ayudan a u n a organización a valorar s u s procesos y prácticas de software. Garmus y Herrón (Function PointAnalysis: Measurement Practices for Successful Software Projects, Addison-Wesley, 2000) examinan las métricas d e proceso con énfasis en el análisis d e los p u n t o s d e función. Lorenze y Kidd [LOR94] y DeChampeax (Object-Oriented Development Process and Metrics, Prentice-Hall, 1996) consideran el proceso OO y describen un conjunto de métricas para valorarlo. Whitmire (Object-Oriented Design Measurement, Wiley, 1997) y Henderson-Seliers (ObjectOriented Metrics: Measures of Complexity, Prentice-Hall, 1995) se e n f o c a n en las métricas técnic a s para el trabajo OO, pero también consideran medidas y métricas que se p u e d e n aplicar en el ámbito del proceso y del producto. Se ha publicado relativamente poco acerca de las métricas para el trabajo de ingeniería Web. Sin embargo, Stern (Web Metrics: Proven Methods for Measuring Web Site Success, Wiley, 2002), Inan y Kean (Measuring the Success ofYour Website, Longman, 2002) y Nobles y Grady (Web Site Analysis and Reporting, Premier Press, 2001) abordan las métricas Web desde u n a perspectiva d e negocios y de marketing. Lo m á s reciente en la investigación en el área de métricas lo resume el IEEE (Symposium on Software Metrics, publicado anualmente). En Internet está disponible u n a amplia variedad d e fuentes de información acerca de las métricas de proceso y proyecto. Una lista actualizada de referencias en la World Wide Web se encuentra en el sitio Web SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P I T U L O

23 CONCEPTOS CLAVE ámbito

693

complejidad . . . 7 0 3 estimación basada en LDC . . . . 7 0 0 b a s a d a en PF 7 0 2 basada en procesos 7 0 4 casos de uso . 7 0 5 conceptos. . . 6 9 8 reconciliación 7 0 8 factibilidad . . . . 6 9 3 planificación de proyecto

692

recursos

694


L

a gestión del proyecto de s o f t w a r e c o m i e n z a con un conjunto de actividades que en grupo se d e n o m i n a n planificación del proyecto. Antes de que el proyecto comience el gestor del proyecto y el equipo de s o f t w a r e deben e ; timar el trabajo que habrá de realizarse, los recursos que se requerirán y el tiempc que transcurrirá desde el principio hasta el final. Una vez que se completen esta; actividades, el equipo de software d e b e establecer un plan del proyecto que de fina las t a r e a s y fechas clave de la ingeniería del software, que identifique quices responsable de dirigir cada tarea y especifique las d e p e n d e n c i a s e n t r e tarea; que pueden ser d e t e r m i n a n t e s en el progreso. En una excelente guía para "sobrevivir el proyecto de software", Steve McConneE [MCC98] presenta una visión del mundo real de la planificación del proyecto: Muchos t r a b a j a d o r e s técnicos preferirán realizar el t r a b a j o técnico e n lugar de pasar el tiempo e n la planificación. Muchos gestores técnicos n o tienen suficiente ent r e n a m i e n t o en la gestión técnica para sentirse s e g u r o s d e q u e su planificación m e j o r a r á el r e s u l t a d o d e u n proyecto. Puesto q u e n i n g u n a parte quiere h a c e r la planificación, con frecuencia n o se realiza. Pero las fallas p a r a planificar e s u n o d e los m a y o r e s e r r o r e s q u e u n proyecto p u e d a c o m e t e r . . . s e n e c e s i t a la planificación eficaz para resolver los p r o b l e m a s corriente

ta del s o f t w a r e

. .698

arriba [ t e m p r a n o e n ei proyecto] a b a j o costo, m á s q u e corriente a b a j o [tarde e n el proyectol a alto costo. El proyecto p r o m e d i o g a s t a 80 por ciento d e su t i e m p o e n reelaboración: corrigiendo e r r o r e s q u e s e c o m e t i e r o n e n e t a p a s t e m p r a n a s del proyecto.

¿ Q u é e s ? Se ha establecido una necesidad real para el software; los participantes están a bordo; los ingenieros de software están listos para comenzar; y el proyecto está a punto de arrancar. Pero, ¿cómo se procederá? La planificación del proyecto de software abarca cinco grandes actividades: estimación, programa de trabajo, análisis de riesgos, planificación de la gestión de la calidad y planificación de la gestión del cambio. En el contexto de este capítulo sólo se considera la estimación: su intento por determinar cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto específico basado en software. ¿ Q u i é n lo h a c e ? Los gestores de proyecto del software, con base en la información solicitada

de los participantes e ingenieros de software y los datos de las métricas de software recopilados en proyectos previos. ¿ P o r q u é e s i m p o r t a n t e ? ¿Se construiría una casa sin saber cuánto dinero está a punto de gastarse, las tareas que se deben realizar y el tiempo para que ei trabajo se haga? Desde luego que no, y puesto que la mayoría de los sistemas y productos basados en computadora son conTM siderablemente más caros que construir una gran casa, parecería razonable desarrollar una estimación antes de comenzar a crear el software. ¿ C u á l e s s o n los p a s o s ? La estimación comienza con una descripción del ámbito del producto. Entonces el problema se descompone en un conjunto de problemas más pequeños, y cada uno de éstos se estima empleando datos históricos y

PDF Editor

CAPÍTULO 23

691

E S T I M A C I Ó N P A R A P R O Y E C T O S DE SOFTWARE

r •perienetet como guías. La complejidad y el esgo del problema se consideran antes de reaizar una estimación final, •el e s el p r o d u c t o o b t e n i d o ? Se genero .na simple tabla en la que se delinean las faros que deben realizarse, las funciones que - :¡brán de implementarse y el costo, esfuerzo y • : impo involucrados para cada uno. r.o p u e d o e s t a r s e g u r o d e q u e lo h e h e c h o c o r r e c t a m e n t e ? Eso es difícil, porque

en reclidad no se sabrá sino hasta que el proyecto se haya completado. Sin embargo, si se tiene experiencia y se sigue un enfoque sistemó tico, se generan estimaciones empleando datos históricos sólidos, se crean puntos de datos de estimación mediante al menos dos métodos diferentes, se establece un calendario realista y continuamente se adapta conforme el proyecto avanza, se puede estar seguró de que se está haciendo lo mejor.

McConell a r g u m e n t a que cualquier proyecto p u e d e e n c o n t r a r el tiempo para planificar (y adaptar el plan a lo largo del proyecto) s im p le m e n t e t o m a n d o un p e q u e ñ o p o r c e n t a j e del tiempo que se habría gastado en la reelaboración que ocurre debido a que no se planificó.

23.1

O B S E R V A C I O N E S A C E R C A DE LA E S T I M A C I Ó N La planificación requiere que los gestores técnicos y los miembros del equipo de s o f t w a r e establezcan un compromiso inicial, aun c u a n d o sea probable que este "compromiso" pruebe estar equivocado. Siempre que se realizan estimaciones se atisba al futuro y se acepta a u t o m á t i c a m e n t e algún grado de incertidumbre. Para citar a Frederick Brooks (BR075]: [NJuestras técnicas d e estimación están p o b r e m e n t e desarrolladas. Más seriamente, reflejan u n a suposición n o expresada que es b a s t a n t e incierta, es decir: que todo irá bien... Puesto q u e n o e s t a m o s seguros d e n u e s t r a s estimaciones, con frecuencia los gestores de software carecen d e la cortés testarudez para h a c e r que la gente espere un buen producto.

Aunque la estimación es tanto u n arte c o m o una ciencia, esta importante actividad no necesita realizarse en una forma improvisada. Existen técnicas útiles para la estimación de tiempo y esfuerzo. Las métricas del proceso y del proyecto ofrecen la perspectiva histórica y la energía para la generación de estimaciones cuantitativas. La experiencia (de toda la gente involucrada) p u e d e auxiliar e n o r m e m e n t e c o n f o r m e se desarrollan y revisan las estimaciones. Puesto que la estimación coloca los cimientos para las d e m á s actividades de planificación del proyecto, y ésta proporTM ciona la ruta para la ingeniería del s o f t w a r e exitosa, se estaría mal a c o n s e j a d o si se e m b a r c a r a sin ella.

PDF Editor "los buenos enfoques de estimación y los d o l o s históricos triunfará sobre demandas imposibles."

sóidos ofrecen

io mejor esperanza de que en realidad se Capers iones

PARTE CUATRO

692


La estimación d e recursos, c o s t o y p r o g r a m a d e t r a b a j o p a r a u n a tarea d e ingeniería de s o f t w a r e requiere experiencia, a c c e s o a b u e n a i n f o r m a c i ó n histórica (métricas) y el valor p a r a c o m p r o m e t e r s e c o n predicciones cuantitativas c u a n d o la i n f o r m a c i ó n cualitativa e s todo lo q u e existe. La estimación implica riesgo inherente, 1 y éste c o n d u c e a la incertidumbre. La disponibilidad d e información histórica tiene u n a fuerte influencia en el riesgo d e la estimación. Al mirar en retrospectiva, se p u e d e n e m u l a r las c o s a s q u e funcionaron y m e j o r a r las á r e a s d o n d e surgieron p r o b l e m a s . C u a n d o hay disponibles a m p l i a s m é t r i c a s d e s o f t w a r e (capítulo 22) d e proyectos previos, las e s t i m a c i o n e s se hacen con mayor seguridad, los p r o g r a m a s d e t r a b a j o se p u e d e n establecer p a r a evitar dificultades p a s a d a s y el riesgo global s e reduce. " t a característica de una mente instruida es descansar satisfecha con el grado de precisión que la naturaleza del asunta admite, y no buscar la exactitud cuando sólo es posible una aproximación de la verdad." Aristóteles El riesgo d e la e s t i m a c i ó n se m i d e por el g r a d o de incertidumbre en las estimaciones cuantitativas establecidas p a r a recursos, c o s t o s y p r o g r a m a d e trabajo. Si el á m b i t o del p r o y e c t o s e c o m p r e n d e en forma deficiente o los requisitos del p r o y e c t : están s u j e t o s a e v e n t u a l e s c a m b i o s , la i n c e r t i d u m b r e y el riesgo d e la estimación se i n c r e m e n t a n p e l i g r o s a m e n t e . El planificador y, en f o r m a m á s importante, el cliente d e b e n r e c o n o c e r q u e la variabilidad en los requisitos del s o f t w a r e significa inestabilidad en c o s t o y p r o g r a m a d e trabajo. Sin e m b a r g o , un gestor d e proyecto n o d e b e o b s e s i o n a r s e c o n las estimaciones. Los m o d e r n o s e n f o q u e s d e ingeniería del s o f t w a r e (por ejemplo, m o d e l o s de proces o incremental) a s u m e n u n a visión iterativa del desarrollo. En tales e n f o q u e s es posible, a u n q u e n o s i e m p r e a c e p t a b l e políticamente, r e e x a m i n a r las estimaciones (cuando s e c o n o z c a m á s información) y modificarlas c u a n d o el cliente c a m b i a los requisitos.

23.2

E L P R O C E S O DE P L A N I F I C A C I Ó N D E L P R O Y E C T O El objetivo d e la planificación del proyecto d e s o f t w a r e e s p r o p o r c i o n a r un m a r c o de

ÔNSEJO^.

t r a b a j o q u e p e r m i t a al g e s t o r e s t i m a r r a z o n a b l e m e n t e r e c u r s o s , c o s t o y p r o g r a m a

Mientras más conozco, mejor estimará. En consecuencia, actualice sus estimaciones conforme avance el pioyecto.

de trabajo. Además, las estimaciones deben intentar definir los e s c e n a r i o s de mejor y p e o r c a s o d e m o d o q u e los r e s u l t a d o s del proyecto s e p u e d a n acotar. Aunque existí TM un g r a d o i n h e r e n t e d e incertidumbre, el equipo de s o f t w a r e s e e m b a r c a en un piar establecido c o m o c o n s e c u e n c i a d e las tareas de planificación. Por lo tanto, el plan se

PDF Editor

d e b e a d a p t a r y actualizar c o n f o r m e a v a n c e el proyecto. En las s e c c i o n e s siguientes s e estudiará cada u n a de las actividades a s o c i a d a s c o n la planificación del proyec; de software. 1

En el capítulo 25 se presentan técnicas sistemáticas para el análisis del riesgo.

CAPÍTULO 23

693

E S T I M A C I Ó N P A R A P R O Y E C T O S DE S O F T W A R E


Conjunto de tareas para la planificación del proyecto b.

1. Establecer el ámbito del proyecto. 2. Determinar la factibilidad. 3. Analizar los riesgos (capítulo 25). Definir los recursos requeridos. a.

Determinar los recursos humanos requeridos.

b.

Definir los recursos de software reutilizables.

c.

Identificar los recursos del entorno.

Estimar costo y esfuerzo. a.

Descomponer el problema.

6.

Desarrollar dos o más estimaciones empleando tamaño, puntos d e función, tareas de proceso o casos de uso. c. Reconciliar las estimaciones. Desarrollar un plan del proyecto (capítulo 24). a. Establecer un conjunto de tareas significativo. b. Definir una red de tareas. c. Usar herramientas de planificación para desarrollar un cronograma. d. Definir mecanismos de seguimiento del programa de trabajo.

IRA DEL S O F T W A R E V F A C T I B I L I D A D

23.3

El ámbito del software describe las f u n c i o n e s y características q u e s e e n t r e g a r á n a los u s u a r i o s finales, los d a t o s que s o n e n t r a d a y salida, el "contenido" q u e s e p r e s e n t a a

CLAVE disten i z o n e s para

los u s u a r i o s c o m o c o n s e c u e n c i a d e e m p l e a r el s o f t w a r e , así c o m o el d e s e m p e ñ o , las restricciones, las interfases y la confiabilidad q u e acotan el sistema. El á m b i t o se defin e al u s a r una d e las d o s t é c n i c a s siguientes: 1. D e s p u é s d e u n a c o m u n i c a c i ó n c o n t o d o s los participantes s e desarrolla u n a descripción narrativa del á m b i t o del software.

i incompleto > requisitos

2.

Los u s u a r i o s finales desarrollan un c o n j u n t o de c a s o s d e uso. 2

Las f u n c i o n e s descritas en el e n u n c i a d o del á m b i t o (o d e n t r o d e los c a s o s d e uso) s e e v a l ú a n y en a l g u n o s c a s o s s e refinan para p r o p o r c i o n a r m á s detalles a n t e s d e c o m e n z a r la estimación. Puesto q u e las estimaciones de costo y p r o g r a m a d e trabajo e s t á n f u n c i o n a l m e n t e orientadas, c o n frecuencia e s útil cierto g r a d o d e d e s c o m p o sición. Las c o n s i d e r a c i o n e s del d e s e m p e ñ o a b a r c a n los requisitos d e p r o c e s a m i e n t o y t i e m p o d e r e s p u e s t a . Las restricciones identifican los límites c o l o c a d o s e n el softw a r e por el h a r d w a r e externo, la m e m o r i a disponible u o t r o s s i s t e m a s existentes. Una vez identificado el á m b i t o (con la participación del cliente) e s r a z o n a b l e preguntar: ¿es posible construir s o f t w a r e p a r a satisfacer e s t e á m b i t o ? ¿El p r o y e c t o e s factible? Con m u c h a frecuencia los ingenieros d e s o f t w a r e soslayan e s t a s p r e g u n t a s TM v e r s e e n r e (o g e s t o r e s o clientes i m p a c i e n t e s los p r e s i o n a n para hacerlo), sólo para d a d o s e n un proyecto c o n d e n a d o al fracaso. P u t n a m y Myers [PUT97a] a b o r d a n e s t e conflicto c u a n d o escriben:

PDF Editor 2

Los casos de uso se discutieron con detalle en las partes 2 y 3 de este libro. Un caso de uso es una descripción basada en escenario de la interacción del usuario con el software, desde el punto de vista del usuario.

PARTE CUATRO

694

ÔNSEJO^ La foctibilidad del proyecto es importante, pero uno consideración de los necesidades del negocio es incluso más importante. No es bueno construir un sistema o producto de alto tecnología que nadie quiere.

23.4


|N]o t o d o lo i m a g i n a b l e e s factible, i n c l u s o ni e n s o f t w a r e , t a n e v a n e s c e n t e c o m o p u e d e p a r e c e r a los e x t r a ñ o s . Por el c o n t r a r i o , la factibilidad del s o f t w a r e t i e n e c u a t r o d i m e n s i o n e s s ó l i d a s : Tecnología:

¿el p r o y e c t o e s t é c n i c a m e n t e factible? ¿Está d e n t r o del t e r r e n o d e

la disciplina? ¿Los d e f e c t o s se p u e d e n reducir a tal g r a d o q u e s e e m p a r e j e n c o n las n e c e s i d a d e s d e la a p l i c a c i ó n ? Finanzas:

¿es f i n a n c i e r a m e n t e factible? ¿Se p u e d e c o m p l e t a r el

d e s a r r o l l o a u n c o s t o q u e la o r g a n i z a c i ó n d e s o f t w a r e , su cliente o el m e r c a d o p u e d a n e n f r e n t a r ? Tiempo:

¿el p r o y e c t o llegará al m e r c a d o a n t e s y v e n c e r á a la c o m p e t e n c i a ? Re-

cursos: ¿la o r g a n i z a c i ó n tiene los r e c u r s o s n e c e s a r i o s p a r a t r i u n f a r ?

Putnam y Myers sugieren, a c e r t a d a m e n t e , que el ámbito no es suficiente. Una vez que el ámbito se comprende, el equipo de software y otros deben trabajar para determinar si se p u e d e h a c e r dentro de las d i m e n s i o n e s a n o t a d a s líneas arriba. Ésta es una parte crucial, a u n q u e con frecuencia ignorada, del p r o c e s o de estimación.

RECURSOS La s e g u n d a tarea de la planificación e s la estimación de los recursos necesarios para completar el esfuerzo d e desarrollo del software. La figura 23.1 muestra las tres g r a n d e s categorías de los recursos de ingeniería del software: personal, c o m p o n e r tes de s o f t w a r e reutilizables y el e n t o r n o de desarrollo (hardware y herramientas de software). Cada recurso se especifica con cuatro características: descripción de recurso; un informe de disponibilidad; c u á n d o se requerirá el recurso; tiempo durar te el cual el recurso se aplicará. Las últimas dos características se pueden ver coir o

Recursos del proyecto.

Herramientas i de software.

Número [Habilidade:

Hardware

Personal

Entorno Recursos d e red

Ubicación

Proyecto

TM Componentes OTS

Software reutilizqble

Nuevos componentes

PDF Editor Componentes d e experiencia . completa S

Componentes dé 1 experiencia parcial /

CAPÍTULO 2 3

695


una ventana de tiempo. La disponibilidad del recurso para una v e n t a n a específica d e b e establecerse lo m á s pronto posible.

23.4.1 Recursos humanos El planificador c o m i e n z a evaluando el ámbito del s o f t w a r e y seleccionando las habilidades requeridas para completar el desarrollo. Se especifican t a n t o la posición organizacional (por ejemplo, gestor, ingeniero de s o f t w a r e ejecutivo) c o m o la especialidad (por ejemplo, telecomunicaciones, b a s e de datos, cliente/servidor). En proyectos relativamente p e q u e ñ o s (unos pocos persona-meses) un solo individuo p u e d e realizar todas las t a r e a s de ingeniería del s o f t w a r e y consultar con especialistas conforme se requiera. En proyectos mayores el equipo de s o f t w a r e p u e d e estar geográficamente disperso en varios sitios. Aquí se especifica la ubicación de cada recurso humano. El n ú m e r o de p e r s o n a s que requiere un proyecto de s o f t w a r e sólo se determina d e s p u é s de que se ha h e c h o u n a estimación del e s f u e r z o de desarrollo (por ejemplo, personas-mes). Las técnicas para estimar el e s f u e r z o se tratarán m á s adelante en e s t e capítulo.

23.4.2 Recursos d e software reutilizables La ingeniería 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 (capítulo 30) enfatiza la reutilización; es decir, la creación y reutilización de bloques de construcción de s o f t w a r e [H0091]. Tales bloques, usualmente llamados componentes,

deben catalogarse para

consultarlos con facilidad, e s t a n d a r i z a r s e para facilitar su aplicación y validarse para integrarlos fácilmente. Bennatan [BEN92] sugiere c u a t r o categorías de recursos de s o f t w a r e que deben considerarse c o n f o r m e a v a n z a la planificación: Componentes

ya desarrollados.

El software existente se p u e d e adquirir de un ter-

cero o se desarrolló i n t e r n a m e n t e para un proyecto previo. Los CCYD (componeni olvide que r varios compo! de reutilización ! ser un reto nte. El 7 de lo intei con frecuencia iconfórmese i varios zryonentes.

tes comerciales ya desarrollados) se compran de un tercero, están listos para emplearlos e n el proyecto actual y han sido a m p l i a m e n t e validados. Componentes

experimentados.

Especificaciones, diseños, código o d a t o s de prue-

ba existentes que se desarrollaron para proyectos previos son similares al software que se construirá para el proyecto actual. Los m i e m b r o s del equipo de s o f t w a r e actual ya tienen experiencia en el á r e a de aplicación que representan dichos c o m p o n e n t e s . En consecuencia, las modificaciones que requieran los c o m p o n e n t e s eTM xperimentados serán relativamente de b a j o riesgo.

PDF Editor Componentes

de experiencia parcial. Especificaciones, diseños, código o d a t o s de

prueba existentes que se desarrollaron para proyectos previos están relacionados con el s o f t w a r e que se construirá para el proyecto actual p e r o requerirán modifica-

c i o n e s sustanciales. Los miembros del equipo de s o f t w a r e actual sólo tienen experiencia limitada e n el á r e a de aplicación q u e representan dichos c o m p o n e n t e s . Por

696

PARTE CUATRO


lo tanto, las modificaciones que requieren los c o m p o n e n t e s de experiencia p a r a ; i tienen un g r a d o considerable d e riesgo. Componentes

nuevos. El equipo de s o f t w a r e d e b e construir los c o m p o n e n t e s c ; J

s o f t w a r e específicamente para las necesidades del proyecto actual. Irónicamente, con frecuencia los c o m p o n e n t e s de s o f t w a r e reutilizables s o n despre- ¡ ciados durante la planificación, sólo para convertirse en una preocupación impc: tante d u r a n t e la fase de desarrollo del proceso de software. Es mejor especifica."! c u a n t o a n t e s los requisitos de recursos de software. De esta forma se p u e d e llevar a I c a b o la evaluación técnica de las alternativas y p u e d e ocurrir la adquisición oportuna '

23.4.3 Recursos del entorno El e n t o r n o que soporta un proyecto de software, con frecuencia d e n o m i n a d o e/ito/roj de ingeniería del software (E1S), incorpora h a r d w a r e y software. El h a r d w a r e proporciona u n a plataforma q u e soporta las h e r r a m i e n t a s (software) con que se prodúcelos productos de trabajo b a s a d o s en u n a buena práctica de la ingeniería del software. 3 Puesto que la mayor parte de las organizaciones de s o f t w a r e tienen múltiple;, i constituyentes que requieren a c c e s o al EIS, el planificador de proyecto d e b e prescr bir la v e n t a na de tiempo requerida por el h a r d w a r e y el software, y verificar que es:os; recursos e s t a r á n disponibles. C u a n d o un sistema b a s a d o en c o m p u t a d o r a (que incorpora h a r d w a r e y softwa-r especializados) se s o m e t e r á a ingeniería, el equipo de s o f t w a r e quizá requiera acces o a e l e m e n t o s de h a r d w a r e q u e están desarrollando otros equipos de ingeniería Por ejemplo, el s o f t w a r e de un contador numérico (CN) utilizado en un tipo ce máquinas-herramienta tal vez requiera una m á q u i n a - h e r r a m i e n t a específica (per] ejemplo, un CN de torno) c o m o parte del p a s o de prueba de validación; un p r o y e c r i d e s o f t w a r e para plantilla de página a v a n z a d a quizá necesite u n a impresora de a t i a j calidad e n algún p u n t o d u r a n t e el desarrollo. El planificador del proyecto de software d e b e especificar cada e l e m e n t o de hardware. 23.5

E S T I M A C I Ó N DE P R O Y E C T O S DE S O F T W A R E El s o f t w a r e e s el e l e m e n t o m á s caro de virtualmente todos los sistemas b a s a d o s e n c o m p u t a d o r a . En s i s t e m a s complejos, personalizados, un gran error en la estima ción del c o s t o p u e d e h a c e r la diferencia entre beneficio y pérdida. Rebasar el eos: :• TM p u e d e ser desastroso para el desarrollador. "En unn ero de subcontrotación y competencia creciente, lo habilidad para estimar con mayor precisión... ha surgido como un factor de éxito crucial paro muchos grupos de TI." Rob Thofflsett

PDF Editor 3

Otro hardware —el entorno objetivo— es la computadora en la que el software se ejecutará cuar»; > haya sido liberado al usuario final.

CAPÍTULO 2 3


697

La estimación del costo y el e s f u e r z o nunca será u n a ciencia exacta. 4 Demasiadas variables — h u m a n a s , técnicas, ambientales, políticas— pueden afectar el costo final é

del s o f t w a r e y el e s f u e r z o aplicado a desarrollarlo. Sin embargo, la estimación proyecto

de software

se puede transformar

del

de una práctica oscura en una serie de

p a s o s sistemáticos que proporcionan estimaciones con riesgo aceptable. Para lograr estimaciones confiables de costo y e s f u e r z o se tienen varias opciones: 1. Demorar la estimación hasta m á s tarde en el proyecto (obviamente, ¡se p u e d e lograr 100 por ciento de estimaciones precisas d e s p u é s de que el proyecto esté terminado!) 2.

Basar las estimaciones en proyectos similares que ya hayan sido completados.

3.

Emplear técnicas d e descomposición relativamente simples para generar estim a c i o n e s de costo y e s f u e r z o del proyecto.

4.

Utilizar u n o o m á s m o d e l o s empíricos en la estimación de costo y esfuerzo.

Desgraciadamente, la primera opción, a u n q u e atractiva, no es práctica. Las estimaciones de costos se tienen que proporcionar "por adelantado". No obstante, se d e b e reconocer que, mientras m á s se espere m á s se conocerá, y mientras m á s se c o n o z ca m e n o s probable es que se cometan serios errores en las estimaciones. La segunda opción p u e d e funcionar r a z o n a b l e m e n t e bien si el proyecto en curso es muy similar a los previos y a o t r a s influencias del proyecto (por ejemplo, el equipo de software, el cliente, las condiciones del mercado, el EIS, las fechas limite) son a p r o x i m a d a m e n t e equivalentes. Por desgracia, la experiencia no siempre ha sido un b u e n indicador de los resultados futuros. Las opciones restantes son e n f o q u e s viables para la estimación del proyecto de software. Idealmente, las técnicas m e n c i o n a d a s para cada opción deben aplicarse juntas, cada u n a e m p l e a d a c o m o una m a r c a de verificación para la otra. Las técnicas de descomposición a s u m e n un e n f o q u e de "divide y vencerás" respecto de la estimación del proyecto de software. Al d e s c o m p o n e r un proyecto en funciones principales y actividades de ingeniería del s o f t w a r e relacionadas, las estimaciones de costo y e s f u e r z o se pueden realizar en forma escalonada. Los modelos de estimación empírica son útiles p a r a c o m p l e m e n t a r las técnicas de descomposición y ofrecer un e n f o q u e de estimación potencialmente valioso por su propio derecho. Estos m o d e l o s se estudian en la sección 23.7. Cada u n a de las opciones viables de estimación de costo del s o f t w a r e será tan TMSi no existen b u e n a c o m o lo s e a n los d a t o s históricos en q u e se basa la estimación. d a t o s históricos, la estimación del c o s t o se b a s a r á en un f u n d a m e n t o m u y t a m b a leante. En el capítulo 22 se e x a m i n a n las características de algunas de las métricas

PDF Editor

de s o f t w a r e que proporcionan la b a s e para los d a t o s históricos de estimación. 4

Bennatan [BEN03] reporta que 40 por ciento de los desarrolladores de software continúan luchando

con las estimaciones y que el tamaño del software y el t empo de desarrollo son muy dificiles de estimar con precisión.

698

PARTE CUATRO


La estimación del proyecto de s o f t w a r e es una forma de resolver problemas; en la mayoría de los casos, el problema que d e b e resolverse (es decir, el desarrollo de una estimación de costo y e s f u e r z o para un proyecto de software) e s muy complejo comc para considerarlo u n a sola pieza. Por esta razón se d e s c o m p o n e el problema, recaracterizándolo c o m o un conjunto de problemas m á s p e q u e ñ o s (y, esperanzadoramente, m á s manejable). En el capítulo 21 se e x a m i n ó el enfoque de descomposición desde dos diferente; p u n t o s de vista: descomposición del problema y descomposición del proceso. L¿ estimación emplea u n a o a m b a s formas de partición. Pero a n t e s de que pueda realizarse una estimación, el planificador del proyecto d e b e e n t e n d e r el á m b i t o del softw a r e que se construirá y generar una estimación de su "tamaño".

23.6.1 Tamaño del software La precisión de la estimación de un proyecto de software se manifiesta en varios factores: 1) el grado con el cual el planificador h a estimado a d e c u a d a m e n t e el t a m a f . :

CLAVE El "tamaño" del software que se construirá puede estimorse empleando uno medido directo, LDC, o uno indirecta, PE.

del producto que se construirá; 2) la habilidad para traducir la estimación del tamaño en esfuerzo h u m a n o , programa de trabajo y dinero (una función de la disponibilidad de las métricas de s o f t w a r e confiables a partir de proyectos previos); 3) el g r a c : en el cual el plan del proyecto refleja las habilidades del equipo de software; y 4) .a estabilidad de los requisitos del producto y el e n t o r n o que soporta el esfuerzo de ingeniería del software. En esta sección se considera el problema del tamaño del software. Puesto que estimación de un proyecto sólo es tan b u e n a c o m o la estimación del t a m a ñ o del b a j o para realizarlo, el t a m a ñ o representa el primer gran desafio del planificador proyecto. En el contexto de la planificación del proyecto, tamaño se refiere a resultado cuantificable del proyecto de software. Si se a s u m e un enfoque directo, t a m a ñ o se p u e d e medir en líneas de código (LDC). Si se elige un e n f o q u e indir el t a m a ñ o se representa c o m o p u n t o s de función (PF). Putnam y Myers [PUT92] sugieren cuatro diferentes e n f o q u e s al problema tamaño:

¿Cómo se mide el tamaño del software que se planea construir?

•

• Tamaño de "lógica dijusa". La aplicación de e s t e e n f o q u e requiere que el piar: ficador identifique el tipo de aplicación, establezca su magnitud e n una e TM cualitativa y luego retine la magnitud dentro del rango original. • Tamaño de punto de función.

El planificador desarrolla estimaciones de las

PDF Editor

características del dominio de la información tratadas en el capítulo 15.

• Tamaño de componentes

estándar. El software se c o m p o n e de varios "cpmpc -

n e n t e s estándar", los cuales son diferentes y genéricos de una área particular

de la aplicación. Por ejemplo, los c o m p o n e n t e s e s tá n d ar de un sistema de información son subsistemas, módulos, pantallas, reportes, programas inter-

CAPÍTULO 23

ESTIMACIÓN P A R A PROYECTOS DE SOFTWARE

699

activos, p r o g r a m a s por lotes, archivos, LDC e instrucciones al nivel de objeto. El planificado!" del proyecto estima el n ú m e r o de ocurrencias de cada componente e s t á n d ar y luego aplica datos de proyectos históricos para determinar el t a m a ñ o de entrega por c o m p o n e n t e estándar. • Tamaño del cambio. Este e n f o q u e se aplica c u a n d o u n proyecto incluye la utilización de s o f t w a r e existente que d e b e modificarse en cierta forma c o m o parte de un proyecto. El planificador estima el n ú m e r o y tipo (por ejemplo, reutilización, código de adición, código de cambio, código de borrado) de las modificaciones que se d e b e n lograr. Putnam y Myers sugieren que los resultados de cada uno de estos e n f o q u e s de t a m a ñ o se combinen estadísticamente para crear una estimación de tres puntos o del valor esperado. Esto se logra desarrollando valores optimistas (bajos), m á s probables y pesimistas (altos) para el t a m a ñ o y c o m b i n á n d o l o s con la ecuación (23-1) descrita en la siguiente sección.

23.6.2 Estimación b a s a d a en el problema En el capítulo 22, las líneas de código y los p u n t o s de función se describieron c o m o medidas a partir de las cuales se calculan las métricas de productividad. Los d a t o s de las LDC y los PF se utilizan en dos formas al estimar el proyecto de software: I) i ¿Qué tienen en común las es ¡ en LDC y

c o m o u n a variable de la estimación para el "tamaño" de cada e l e m e n t o del software, y 2) c o m o métricas de línea b a s e recolectadas a partir de proyectos previos y utilizados en conjunción con variables de estimación para desarrollar proyecciones de costo y esfuerzo. Las estimaciones de LDC y PF son distintas técnicas de estimación, a u n q u e a m b a s tienen varias características en c o m ú n . El planificador del proyecto comienza con un e n f o q u e acotado del ámbito del software y a partir de ahí intenta d e s c o m p o n e r el s o f t w a r e en funciones problema que puedan estimarse individualmente. Entonces se

fcONSEJO^-

estiman las LDC o PF (las variables de estimación) para cada función. De m a n e r a

; recopile ¡cas de product.t ti para proyectos, i de estot una taxonomía

alternativa, el planificador p u e d e elegir otro c o m p o n e n t e para t a m a ñ o , c o m o clases

. £sto le ) calcular s específicos i dominio, lo que ¡ realizar estt | lociones más jRásas.

u objetos, cambios o procesos de negocios afectados. Entonces se aplican las métricas de la línea b a s e de productividad (por ejemplo, LDC/pm o PF/pm 5 ) a la variable de estimación apropiada, y se deriva el costo o esfuerzo de la función. Las estimaciones de función se combinan para producir u n a estimación global del proyecto completo. Sin embargo, es importante notar que con frecuencia existe una TM dispersión sustancial en las métricas de productividad de una organización, lo que hace sospechoso el uso de una sola métrica de línea b a s e de productividad. En general, el dominio

PDF Editor

del proyecto debe calcular los promedios de LDC/pm o PF/pm. Es decir, los proyectos deben agruparse por t a m a ñ o de equipo, área de aplicación, complejidad y otros

5

Las siglas pm significan persona-mes de esfuerzo

700

PARTE C U A T R O


p a r á m e t r o s relevantes. Luego se tienen que calcular los promedios de dominio local. Cuando se estima u n nuevo proyecto primero d e b e ubicarse en un dominio, y luegc aplicar el promedio del dominio apropiado para la productividad y así generar la estimación. Las técnicas de estimación LDC y PF difieren en en c u a n t o al detalle requeridc para descomposición y el objetivo de la partición. Al emplear LDC c o m o variable de estimación la descomposición es a b s o l u t a m e n t e esencial y con frecuencia se lleva £ grados considerables de detalle. Mientras mayor sea el g r a d o de partición es más probable que se desarrolle u n a estimación r a z o n a b l e m e n t e precisa de LDC. En las estimaciones de PF la descomposición funciona de m a n e r a diferente. Más

\

que e n f o c a r s e sobre la función, se estima cada una de las cinco características de

CLAVE

En las estimaciones PF la descomposición se enfoca sobre las característicos del dominio de información.

dominio de información, así c o m o los 14 valores de ajuste de complejidad estudiados en el capítulo 15. Entonces se pueden utilizar las estimaciones resultantes par£ derivar un valor de PF que se p u e d a ligar a datos previos y e m p l e a d o s para generar una estimación. Sin importar la variable de estimación que se utilice, el planificado! - del proyect; comienza e s t i m a n d o u n a g a m a de valores para cada función o valor de dominio de información. Al emplear d a t o s históricos o (cuando todo lo d e m á s falla) intuición, e: planificador estima u n valor de t a m a ñ o optimista, m á s probable, y pesimista para cada función o cuenta para cada valor de dominio de información. C u a n d o se especifica un r a n g o de valores se proporciona un indicio implícito del grado de incertidumbre.

7 ¿Córao s e • calcula el "valor esperado" para el tamaño de software?

Entonces se p u e d e calcular un valor de tres p u n t o s o u n o esperado. El valor espe rado para la variable de estimación (tamaño), S, se calcula c o m o un promedio pond e r a d o de las estimaciones optimista (Sop,), m á s probable (Sm) y pesimista (Spes). Poejemplo, S — (S0p[ + 4S m + SpesJ/6

(23-1)

brinda la credibilidad m á s fuerte a la estimación "más probable" y sigue una distribución de probabilidad beta. Se s u p o n e que existe una probabilidad muy p e q u e ñ a de que el t a m a ñ o real resultante se ubique fuera de los valores optimista y pesimista. Una vez d e t e r m i n a d o el valor e s p e r a d o para la variable de estimación se aplicar, los datos de productividad histórica de LDC o PF. ¿Son correctas las estimaciones? La única respuesta razonable a esta pregunta es: no se p u e d e estar seguro. Cualquier técnica de estimación, n o importa cuán sofisticada sea, debe contrastarse con otro TM enfoque. Incluso e n t o n c e s deben prevalecer el sentido c o m ú n y la experiencia.

23.6.3 Un ejemplo de estimación b a s a d a en LDC

PDF Editor

C o m o ejemplo de técnicas de estimación de LDC y PF b a s a d a s en el problema, considérese un p a q u e t e de software que será entregado para u n a aplicación de diseño asistido por c o m p u t a d o r a (CAD, por s u s siglas en inglés) destinado a c o m p o n e n t e s mecánicos. El s o f t w a r e se ejecutará en una estación de trabajo de ingeniería y debe

CAPÍTULO 23

*

CONSEJO

aplicaciones residen en red o son parte i arquitectura ir. Por lo asegúrese de sus estimaciones i el esfuerzo : pora desasoltware de

701


tener interfaz con varios periféricos que incluyen ratón, digitalizador, monitor de color de alta resolución e impresora láser. Se puede elaborar una descripción preliminar del ámbito del software: El s o f t w a r e CAD m e c á n i c o aceptará del ingeniero datos geométricos d e dos y tres dimensiones. El ingeniero interactuará y controlará el sistema CAD a través de u n a interfaz del usuario que exhibirá características d e buen d i s e ñ o d e interfaz h u m a n o - m á q u i n a . Todos los d a t o s geométricos y otra información d e soporte se conservarán en una b a s e d e datos CAD. S e desarrollarán m ó d u l o s d e análisis d e diseño para producir la salida requerida, la cual se desplegará en una diversidad de dispositivos gráficos. El software s e diseñará para controlar e interactuar con dispositivos periféricos q u e incluyen ratón, digitalizador, impresora láser y plotter.

Esta descripción del ámbito e s preliminar, no está acotada. Se tendría que expandir cada oración para ofrecer detalle concreto y acotación cuantitativa. Por ejemplo, antes de que comience la estimación, el planificador debe determinar qué significa "características de buen diseño d e interfaz humano-máquina" o cuáles serán el t a m a ñ o y la complejidad de la "base de datos CAD". En cuanto a los propósitos actuales, se supone que se ha llevado a cabo más refinamiento y que están identificadas las grandes funciones de software mencionadas ÔNSEJO^ suambaala i de utilizar
Tabla d e estimación para m é t o d o s LDC.

en la figura 23.2. Al continuar con la técnica de descomposición para LDC se elabora una tabla de estimación, la cual se muestra en la figura 23.2. En cada función se desarrolla un rango de estimaciones LDC. Por ejemplo, el rango de las estimaciones LDC para la función de análisis geométrico 3D es: optimista, 4 600 LDC; m á s probable, 6 900 LDC; y pesimista, 8 600 LDC. Al aplicar la ecuación 23-1 el valor esperado para la función de análisis geométrico 3D es 6 800 LDC. Otras estimaciones s e derivan en forma similar. Al sumar verticalmente en la columna de LDC estimadas, se establece una estimación de 33 200 líneas de código para el sistema CAD.

Función

LDC e s t i m a d a s

Facilidades d e interfaz del usuario y control (FIUC)

2 300

Análisis geométrico bidímensional (AG2D)

5 300

Análisis geométrico tridimensional (AG3D)

ó 800

Gestión d e base de datos (GBDj

3 350 4 950

Facilidades de presentación gráfica de

TM

PDF Editor computadora (FPGC)

Función d e control perilér co -CP

Módulos de análisis d e a se-o Líneas d e código estimabas

2 100

Z

8 400

33 200

702

PARTE C U A T R O


Una revisión de los datos históricos indica que el promedio organizacional de prcductividad para sistemas de este tipo es de 620 LDC/pm. Con base en una t a n a laboral de 8 000 dólares por mes, el costo por línea de código e s aproximadamer.:: de 13 dólares. Con base en la estimación de LDC y los datos históricos de productividad, el costo total estimado del proyecto e s de 431 000 dólares y el esfuerzo es:: m a d o es de 54 personas-mes. 6 HOGARSEGURO

Estimación £1 e s c e n a r i o : t a oficina de Doug Miller cuando comienza la planificación del proyecto, l o s a c t o r e s : Doug Miller (gerente del equipo de ingeniería del software d e HogarSeguro) y Vinod Raman, Jamie lazar y otros miembros del equipo de ingeniería de software del producto. La c o n v e r s a c i ó n :

J a m i e : ¡Vaya! ¿Cómo se supone que lo haremos? V i n o d : Yo lo he hecho en proyectos previos. Utilizas casos d e uso, determinas la funcionalidad requerida para implementar cada uno, supones el conteo de LDC para cada pieza de la función. La mejor aproximación e: que cada uno lo haga de manera independiente y luego comparamos los resultados.

O o u g : Necesitamos desarrollar una estimación del esfuerzo para el proyecto, y luego tenemos que definir un microprograma de trabajo pora el primer incremento y un macroprograma de trabajo para los incrementos

D o u g : O puedes hacer una descomposición funcional de todo el proyecto.

V i n o d ( a s i e n t a c o n la c a b e z a ) : Muy bien, pero no hemos definido ningún incremento todavía.

V i n o d : No.., se puede hacer en pocas horas... esto mañana, de hecho.

D o u g : Cierto, pero es por eso por lo que necesitamos estimar. |

D o u g : Estoy de acuerdo... no podemos esperar exactitud, sólo una idea aproximado d e cuál será el tamaño de HogarSeguro.

J a m i e ( m a l h u m o r a d a ) : ¿Quieres saber cuánto nos tomará? ' /., O o u g : He aquí lo que necesito. Primero, necesitamos descomponer funcionalmente el software d e HogarSeguro... a un nivel elevado... luego tenemos que estimar el número de lineas de código que tomará cada función... luego...

J a m i e : Pero eso tomará toda la vida, y ya tenemos que comenzar.

J a m i e : Creo que sólo debemos estimar el esfuerzo... eso es todo. D o u g : También haremos eso. Luego usaremos ambas estimaciones como comprobación mutua. V i n o d : Vamos a hacerlo...

23.6.4 Un ejemplo de estimación b a s a d a en PF La descomposición de la estimación basada en PF se centra en los valores de dominio TM de información m á s que en las funciones de software. Al consultar la tabla presentada en la figura 23.3 el planificador del proyecto estima e n t r a d a s externas, salidas

PDF Editor

externas, consultas externas, archivos lógicos internos y archivos de interfaz externos para el software CAD. Los PF se calculan usando la técnica estudiada en el capi-

6

Las estimaciones están redondeadas a 1 000 dólares y a la persona-mes más cercanos. Mayor precisión es innecesaria e irreal, dadas las limitaciones de precisión de la estimación.

CAPÍTULO 23

703

E S T I M A C I Ó N P A R A PROYECTOS DE SOFTWARE

Estimación d e valores d e d o m i n i o d e información.

Conteo Conteo Optim. Probable Pesim. estim. Peso PF

Valor de dominio de información Número d e entradas externas

20

24

30

24

4

97

Número d e salidas externas

12

15

22

16

5

78

Número d e preguntas externas

16

22

28

22

5

88

Número d e archivos lógicos internos

4

4

5

10

42

Número de archivos d e iriterfase externos

2

2

3

Conteo total

4 -

i'í--

15 320

iiiílWlii

tulo 15. En cuanto a los propósitos de esta estimación se supone que el factor ponderado de complejidad e s el promedio. La figura 23.3 presenta los resultados de esta estimación. Se estima cada uno de los factores ponderados de complejidad y el valor del factor ajustado se calculan c o m o se describe en el capítulo 15: Valor

Factor 1. Respaldo y recuperación

4

2. Comunicaciones d e datos

2

3. Procesamiento distribuido

0

4. Desempeño crítico

4

5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

Entorno operativo existenle Entrada d e datos en línea Transacción d e entrada sobre pantallas múltiples ILF actuolizado en línea Complejo d e valores d e dominio d e información Complejo de procesamiento interno Código diseñado para reutilización Con versión/instalación en diseño Instalaciones múltiples Aplicación diseñada para cambio

3 4 5 3 5 5 4 3 5 5

Factor d e a j u s t e d e v a l o r

1.17

TM

Finalmente, se deriva el número estimado de PF:

PDF Editor PFestimado =

COnteO total

X

[0.65 + 0.01

X X(F.)]

PFesUmado = 375

La productividad organizacional promedio para sistemas de este tipo es 6.5 PF/pm. Con base en una escala salarial de 8 000 c . .ares por mes, el costo por PF es aproxim a d a m e n t e I 230 dólares. Con base en ia estimación de PF y los datos de producti-

704

PASTE CUATRO


vidad históricos, el costo total estimado del proyecto e s de 461 000 dólares, y el esfuerzo estimado es de 58 personas-mes. ^CONSEJcffi Si el tiempo lo peimile, use la granalaridad fina cuando especifique las tareas en la figura 23.4. Por ejemplo, divida el análisis en sus toreas principales y estime cada una por separado.

23.6.5 Estimación b a s a d a en el proceso La técnica más común para estimar un proyecto es basar la estimación en el proceso que se empleará. Esto es, el proceso se descompone en un conjunto relativamente pequeño de tareas y se estima el esfuerzo requerido para lograr cada tarea Al igual que las técnicas basadas en el problema, la estimación basada en el proceso comienza con un bosquejo de las funciones del software obtenidas a partir de ámbito del proyecto. Cada función requiere realizar una serie de actividades del maree de trabajo. Las funciones y actividades 7 del marco de trabajo relacionadas se pre sentan como parte d e una tabla similar a la presentada en la figura 23.4.

Tabla de estimación CC

O Umfif-.ciAn r lanmcatiori

d e riesgo

Tarea-»-

Ingeniería

construcción

EC Totales

Análisis Diseñol C ó d i g o P r u e b a

Función

Y

M

FIUC

0.50

2.50

0.40

5.00

n/a

8.40

AG2D

0.75

4.00

0.60

2.00

n/a

7.35

AG3D

0.50

3,00 1.50

8.50

0.50

1.00 1.00

n/a

FPGC

4.00 3.00

n/a

6.00

GBD

0.50

3.00

0.75

1.50

n/a

5.75

FCP

0.25

2.00

0.50

1.50

n/a

4.25

MAD

0.50

2.00

0.50

2.00

n/a

5.00

3.50

20.50

4.75

16.50

8%

45%

10%

36%

Totales % esfuerzo

0.25 0.5%

0.25 0.5%

0.25 0.5%

C C = c o m u n i c a c i ó n d e l cliente

46.00

EC • e v a l u a c i ó n d e l cliente

Una vez que s e combinan las funciones del problema y las actividades del proceso, el planificador estima el esfuerzo (por ejemplo, personas-mes) que se requerir; para lograr cada actividad del proceso de software en cada función. Estos dato; TM se aplican laí constituyen la matriz central de la tabla en la figura 23.4. Entonces tasas de trabajo promedio (es decir, costo/unidad de esfuerzo) al esfuerzo estimac: para cada actividad del proceso. Es muy probable que la tasa de trabajo varíe er cada tarea. El equipo veterano está enormemente involucrado en las actividadef

PDF Editor 7

Las actividades del m a r c o de trabajo que se eligen para este proyecto difieren u n poco de la activ

d a d e s genéricas tratadas en el capítulo 2, que son la comunicación con el cliente (CC), la planificación, el análisis de riesgos, la ingeniería y la construcción-liberación.

CAPÍTULO 23

705


t e m p r a n a s del m a r c o de trabajo y g e n e r a l m e n t e es m á s c o s t o s o que el equipo m e n o s e x p e r i m e n t a d o involucrado e n la construcción y liberación. Los c o s t o s y el e s f u e r z o para c a d a función y actividad del m a r c o de trabajo se calculan c o m o el último paso. Si la estimación b a s a d a e n el proceso se realiza indep e n d i e n t e m e n t e de la estimación de LDC o PF, ahora se tienen dos o tres estimacion e s para costo y e s f u e r z o que se p u e d e n c o m p a r a r y armonizar. Si a m b o s c o n j u n t o s de estimaciones m u e s t r a n u n a concordancia razonable, existe u n a b u e n a razón para creer que las estimaciones son confiables. Si, por otra parte, los resultados de dichas técnicas de descomposición m u e s t r a n poca concordancia, se d e b e llevar a c a b o mayor investigación y análisis. "Es mejor comprender el trasfondo de uno estimación antes de utilizarlo." Barry Boehm y Richard Fairley

23.6.6 Un ejemplo de estimación b a s a d a en el proceso Para ilustrar el u s o de la estimación b a s a d a en el proceso considérese de n u e v o el s o f t w a r e CAD introducido en la sección 23.6.3. La configuración del sistema y las funciones del s o f t w a r e p e r m a n e c e n invariables y las indica el ámbito del proyecto. En la tabla b a s a d a e n el proceso que se muestra e n la figura 23.4 las estimacion e s del e s f u e r z o (en personas-mes) para cada actividad de ingeniería del s o f t w a r e s e proporcionan para cada función del s o f t w a r e CAD (abreviadas para mayor rapidez). Las actividades de ingeniería y de liberación de construcción se subdividen en las principales t a r e a s de ingeniería del s o f t w a r e que se m u e s t r a n . Las primeras estimaciones de e s f u e r z o corresponden a comunicación con el cliente, planificación y a n á lisis de riesgos, las cuales se registran en la hilera total al final de la tabla. Los totales horizontal y vertical ofrecen un indicio del e s f u e r z o e s t i m a d o que se requiere para análisis, diseño, código y prueba. Se d e b e señalar q u e 53 por ciento del e s f u e r z o s e emplea en las tareas de ingeniería del sistema de salida (análisis de requisitos y diseño), lo que indica la importancia relativa de e s t e trabajo. Con b a s e en la escala salarial promedio de 8 000 dólares por mes, el costo total estimado del proyecto e s de 368 000 dólares , y el e s f u e r z o estimado es de 46 personas-mes. Si se desea, los promedios de trabajo pueden asociarse con cada actividad del m a r c o de trabajo o tarea de ingeniería del software y calcularse por separado.

23.6.7 Estimación con casos de uso

TM

C o m o se ha s e ñ a l a d o a lo largo de las p a r t e s 2 y 3 de este libro, los c a s o s de uso permiten que un equipo d e s o f t w a r e c o m p r e n d a el ámbito del s o f t w a r e y los requisitos.

PDF Editor ^ •

¿Por qué es difícil desolar uno técnica i t estimación con • s o s de uso?

Sin e m b a r g o , desarrollar un e n f o q u e de estimación con c a s o s de uso e s problemático por las siguientes r a z o n e s [SM199]:

• Los c a s o s de uso se describen e m p l e a n d o m u c h o s formatos y estilos diferentes; n o existe un formato e s t á n d a r

706

PARTE C U A T R O


• Los casos de uso representan una visión externa (la visión del usuario) del software y con frecuencia están escritos con diferentes grados de abstracción. • Los casos de uso no abordan la complejidad de las funciones ni de las características que se describen. • Los casos de uso no describen el comportamiento complejo (por ejemplo, interacciones) que involucran muchas funciones y características, A diferencia de las LDC o un punto de función, el "caso de uso" de una persona ta vez requiera meses de esfuerzo mientras que el de otra quizá se implemente en ludia o dos. Aunque varios investigadores han considerado los casos de uso como una entrada a la estimación, a la fecha no ha surgido ningún método de estimación probad: Smith [SMI99] sugiere el empleo de los casos de uso en la estimación, pero sólo s se consideran dentro del contexto de la "jerarquía estructural" que los casos de u s : describen. Smith argumenta que cualquier nivel de esta jerarquía estructural se describe cor no m á s de 10 casos de uso. Cada uno de éstos abarcaría n o más de 30 escenarios distintos. Obviamente, los casos de uso que describen un sistema grande están escr tos con un grado mucho mayor de abstracción (y representan considerablemente más esfuerzo de desarrollo) que aquellos que describen un solo subsistema. En consecuencia, antes de que los casos de uso se empleen en la estimación, se establece el nivel en la estructura jerárquica, se determina la longitud promedio (en páginas de cada caso de uso, se define el tipo de software (por ejemplo, tiempo real, de negc cios, de ingeniería/científico, anidado) y se considera una arquitectura común del sistema. Una vez establecidas dichas características, los datos empíricos se aprovechan para establecer el número estimado de LDC o de PF por caso de uso (para caca nivel de la jerarquía). Entonces se utilizan los datos históricos para calcular el esfuerzo necesario para desarrollar el sistema. Enseguida se ilustra cómo realizar este cálculo; por tanto, considérese la siguier te relación: 8 LDC estimada = Nx

LDCprom + [(S„/Sh - 1) + {P„/Ph - 1)] x LDCa|uslc

(23-2)

donde TM N = número real de casos de uso LDCprom = promedio histórico de LDC por caso de uso para este tipo de subsis-

tema

PDF Editor 8

Es importante señalar que la expresión (23-2) se emplea sólo con propósitos ilustrativos. Al igual

que todos los modelos de estimación, debe validarse localmente antes de que se le pueda utilizacon seguridad.

CAPÍTULO 23


707

LDCajUSte = representa un ajuste con base en n por ciento de LDCprom donde n

Sa Sh Pa Ph

se define [ocalmente y representa la diferencia entre este proyecto y los proyectos "promedio" = escenarios reales por caso de uso = escenarios promedio por caso de uso para este tipo de subsistema = páginas reales por caso de uso = página promedio por caso de uso para este tipo de subsistema

Con la expresión (23-2) se desarrolla una estimación común del número de LDC con base en el número real de casos de uso ajustado mediante el n ú m e r o de escenarios y la longitud de la página de los casos de uso. El ajuste representa hasta n por ciento del promedio histórico de las LDC por caso de uso.

23.6.8 Un ejemplo de estimación b a s a d a en casos de uso El software CAD presentado en la sección 23.6.3 está compuesto de tres grupos de subsistemas: • Subsistema de interfaz del usuario (incluye FIUC). • Grupo de subsistema de ingeniería (incluye el subsistema AG2D, subsistema AG3D y el subsistema MAD). • Grupo de subsistema de infraestructura (incluye el subsistema FPCG y el subsistema FCP). Seis casos de uso describen el subsistema de interfaz del usuario. Cada caso de uso lo describen n o más de 10 escenarios y tiene una longitud promedio de seis páginas. El grupo de subsistema de ingeniería lo describen 10 casos de uso (considerados en un nivel más alto de la jerarquía estructural). Cada uno de los casos de uso n o tiene m á s de 20 escenarios asociados y tiene una longitud promedio de ocho páginas. Finalmente, el grupo de subsistema de infraestructura lo describen cinco casos de uso con un promedio de sólo seis escenarios y una longitud promedio de cinco páginas. Con la relación anotada en la expresión (23-2) y n = 30 por ciento se elabora la tabla de la figura 23.5. Si se considera la primera hilera de la tabla, los datos históricos indican que el software IU requiere un promedio de 800 LDC por caso de uso cuando éste n o tiene más de 12 escenarios y está descrito en m e n o s de cinco pági-

TM Estimación de caso de uso. casos de uso

PDF Editor Subsistema de interfaz del usuario Grupo de subsistema de ingeniería Grupo de subsistema de infraestructura Total LDC estimadas

6

10

5

escenarios páginas 10

6

20

8

6

5

12

5 8 6

LDC

560

3100 1650

LDC estimadas 3 366 31 2 3 3 7 970 42 568

708

PARTE C U A T R O


ñas. Estos d a t o s se a j u s t a n r a z o n a b l e m e n t e bien para el sistema CAD. Así pues, la estimación de LDC para el subsistema de interfaz del usuario se calcula mediante la expresión (23-2), Si se aplica el m i s m o enfoque, se realizan estimaciones para los grupos de s u b s i s t e m a s de ingeniería e infraestructura. La figura 23.5 r e s u m e las estim a c i o n e s e indica que el t a m a ñ o global del s o f t w a r e CAD se estima en 42 500 LDC Si se utilizan 620 LDC/pm c o m o la productividad promedio en los sistemas de este tipo y u n a escala salarial de 8 000 dólares por mes, el costo por línea de código es a p r o x i m a d a m e n t e de 13 dólares. Con b a s e en la estimación de c a s o de uso y lo? datos históricos de productividad, el c o s t o total estimado del proyecto es de 552 OOC dólares, y el e s f u e r z o estimado es de 68 p e r s o n a s - m e s .

23.6.9 Reconciliación de estimaciones Las técnicas de estimación estudiadas en las secciones precedentes dan por resultado múltiples estimaciones que deben reconciliarse para producir u n a sola estimador, de esfuerzo, duración del proyecto o costo. Este procedimiento de reconciliación se ilustra c o n s i d e r a n d o de nuevo el s o f t w a r e CAD p r e s e n t a d o en la sección 23.6.3.

"Tai vez los métodos complicados no produzcan una estimación m á s precisa, particularmente cuando los desabolladores pueden incorporar su propia intuición en la estimación."

;í

Philip Johnson el al.

El e s f u e r z o estimado total para el software CAD varía d e s d e u n b a j o de 46 perscn a s - m e s (obtenido e m p l e a n d o el enfoque de la estimación b a s a d a en el p r o c e s : hasta un alto de 68 p e r s o n a s - m e s (derivado con la estimación de c a s o de uso). L¿ estimación promedio (que utiliza los cuatro enfoques) es de 56 personas-mes. La variación de la estimación promedio es a p r o x i m a d a m e n t e 18 por ciento en el lado b a j : y de 21 por ciento en el lado alto. ¿Qué ocurre c u a n d o la concordancia entre las estimaciones es insuficienteResponder esta pregunta requiere reevaluar la información con que se hicieron las estimaciones. Las estimaciones a m p lia m e n te divergentes con frecuencia puederastrearse h a s t a u n a de dos causas: 1. El planificador no ha comprendido a d e c u a d a m e n t e o ha malinterpretado el TM ámbito del proyecto. 2.

Los datos de productividad que utilizan las técnicas de estimación b a s a d a s e r

PDF Editor

el problema son ¡napropiados para la aplicación, obsoletos (pues ya no refle-

jan con precisión la organización de ingeniería de software) o se h a n aplicad ; mal.

El planificador debe determinar la causa de la divergencia y luego reconciliar las estimaciones.

CAPÍTULO 23

709


INFORMACIÓN

Técnicas de estimación automatizada para proyectos de software Las herramientas de estimación automatizadas permiten que planificador estime costo y y realice análisis "si... entonces" respecto d e ntes variables del proyecto, como la fecha de o la plantilla de personal. Aunque existen muchas lientas de estimación automatizada (véase el Iro más adelante en este capítulo), todas presentan mismas características generales y realizan las tes seis funciones genéricas [JON96]: Tamaño de los entregables del proyecto. Se estima el "tamaño" de uno o más productos de trabajo del software. Los productos de trabajo incluyen la representación externa del software (por ejemplo, pantallas, reportes), el software en sí mismo (por ejemplo, KLDC), funcionalidad entregada (por ejemplo, puntos de función) e información descriptiva (por ejemplo, documentos). 2.

Selección de las actividades del proyecto. Se selecciona el marco de trabajo del proceso adecuado y se especifica el conjunto de tareas de ingeniería del software.

3.

Predicción de los niveles del personal. Se especifica el número de personas que estará disponible para realizar el trabajo. Puesto que la relación entre el personal disponible y el trabajo (esfuerzo predicho) es enormemente no lineal, ésta es una entrada importante.

4.

Predicción

dei

esfuerzo

de

software.

\

Las

herramientas de estimación emplean uno o más modelos (sección 23.7) que relacionan el tamaño de los entregables del proyecto con el esfuerzo requerido para producirlos. 5.

Predicción del costo del software. Dados los resultados del paso 4, los costos se calculan relacionando los índices de trabajo con las actividades del proyecto anotadas en el paso 2.

6.

Predicción del programa de trabajo del software. Cuando se conocen el esfuerzo, el nivel del personal y las actividades del proyecto es posible producir un anteproyecto de programa al ubicar el trabajo a través de las actividades de ingeniería del software con base en los modelos recomendados para la distribución del esfuerzo estudiados en el capítulo 24.

La aplicación de diferentes herramientas de estimación a los mismos datos de proyecto permite encontrar una variación relativamente grande en los resultados estimados. Más importante todavía, en ocasiones los valores predichos son significativamente diferentes de los valores reales. Esto refuerza la noción de que las salidas de las herramientas de estimación se deben emplear como un "punto de datos" a partir del cual se derivan las estimaciones, no como la única fuente para una estimación.

Un modelo de estimación para software de computadora utiliza fórmulas obtenidas

\

empíricamente para predecir el esfuerzo c o m o una función de LDC o PF.9 Los valo-

CLAVE

fc modelo de stimación refleja la xólacióa de proyectos :esde la que se ha jerivado. Por lo tanto, ú modelo es sensible d dominio.

res de LDC o PF se estiman mediante el enfoque descrito en las secciones 23.6.3 y 23.6.4. Pero, en lugar de emplear las tablas descritas en dichas secciones, los valores resultantes para LDC o PF se colocan en el modelo d e estimación. Los datos empíricos que apoyan la mayoría de los modelos de estimación proceden de una muestra limitada de proyectos. Por esta razón, ningún TM modelo de estimación es apropiado para todas las clases de software ni en todos los entornos de desarrollo. En consecuencia, los resultados obtenidos a partir de tales modelos se

PDF Editor deben emplear juiciosamente.

9

En la sección 23.6.7 se sugiere un modelo empírico que utiliza casos de uso como la variable independiente. Sin embargo, a la fecha han aparecido relativamente pocos en la respectiva bibliografía.

710

PARTE C U A T R O


Un modelo de estimación debe calibrarse para reflejar las condiciones locales, m o d e l o d e b e probarse mediante la aplicación de los d a t o s recopilados a partir proyectos completados, colocar los d a t o s en el m o d e l o y luego c o m p a r a r los r~ taos reales con los predichos. Si la concordancia e s insuficiente, el modelo debe narse y p o n e r s e a prueba n u e v a m e n t e a n t e s de que se pueda utilizar.

23.7.1 La estructura de los modelos de estimación Un m o d e l o de estimación típico se deriva m e d i a n t e el análisis de regresión de d a t o s recopilados de proyectos de s o f t w a r e previos. La estructura global de modelos toma la forma [MAT94] E = A + B x (ev)c

(23-3»

d o n d e A , B y C son c o n s t a n t e s obtenidas empíricamente, E es el e s f u e r z o en pers:n a - m e s y e v e s la variable de estimación (ya sea LDC o PF). Además de la relación a n o t a d a en la ecuación (23-3), la mayoría de los m o d e l o s de estimación tiene alguna forma de c o m p o n e n t e de ajuste del proyecto que permite ajustar £ por características del proyecto (por ejemplo, complejidad del problema, experiencia personal, e n t o r n o de desarrollo). Entre los m u c h o s m o d e l o s de estimación orienta(CONSEJO^ Ninguno de estos modelos se debe emplear sin uno colibración cuidadosa a su enlomo.

dos a LDC propuestos en la bibliografía se e n c u e n t r a n E = 5.2 x (KLDC) 09 '

m o d e l o Walston-Felix

E = 5.5 + 0.73 x (LDC) 116

modelo Bailey-Basili

E = 3.2 x (KLDC)105

modelo simple de Boehm

E = 5.288 x (KLDC) 10457

m o d e l o Doty para KLDC > 9

También se h a n propuesto modelos orientados a PF. Entre é s t o s se incluyen: E = - 9 1 . 4 + 0.355 PF

modelo de Albrecht y Gaffney

E = - 3 7 + 0.96 PF

modelo de Kemerer

E = - 1 2 . 8 8 + 0.405 PF

m o d e l o de regresión para proyecto pequeño

Un rápido e x a m e n de e s t o s modelos indica que cada u n o producirá u n resultad:» diferente para los m i s m o s valores de LDC o PF. La implicación es clara. ¡Los modelos de estimación deben calibrarse para las n e c e s i d a d e s locales!

23.7.2 El modelo COCOMO II En su libro clásico acerca de "economía de la ingeniería del software", Barry Boehm TM [BOE81] introduce u n a jerarquía de modelos de estimación de s o f t w a r e que lleva rl

En sunset.ust. edu/reseoré/ C0C0M0II/

-

n o m b r e de COCOMO, por COnstructive COst MOdel (Modelo Constructivo de Costo;

PDF Editor cocomo-moin.html

se puede obtener | cíomtodón detolloda acerca de COCOMO' II, jñdusosoftwme

El m o d e l o COCOMO original se volvió u n o de los m á s a m p lia m e n te utilizados y estudiados modelos de estimación de costo de s o f t w a r e en la industria. Además, h a evolucionado a un m o d e l o de estimación m á s amplio, llamado COCOMO II [BOE9f. BOEOO]. Al igual que su predecesor, COCOMO II es en realidad u n a jerarquía de m o d e l o s de estimación que aborda las á r e a s siguientes:

CAPÍTULO 23


• Modelo de composición

711

de la aplicación. Se emplea durante las primeras e t a p a s

de la ingeniería del software, c u a n d o son primordiales la elaboración de prototipos de las interfases de usuario, la consideración de la interacción del s o f t w a r e y el sistema, la valoración del d e s e m p e ñ o y la evaluación de la m a d u r e z de la tecnología. • Modelo de etapa de diseño temprano. Se utiliza u n a vez que se han estabiliz a d o los requisitos y se ha establecido la arquitectura básica del software. • Modelo de etapa posterior a la arquitectura. Se emplea d u r a n t e la construcción del software. Al igual que los m o d e l o s de estimación del software, los m o d e l o s COCOMOII requieren información de t a m a ñ o . C o m o parte de la jerarquía del m o d e l o hay disponibles tres opciones diferentes de t a m a ñ o : p u n t o s objeto, p u n t o s de función y líneas de código fuente. El modelo COCOMO II de composición de la aplicación emplea p u n t o s objeto, u n a medida indirecta d e s o f t w a r e que s e calcula mediante c o n t e o s del n ú m e r o de 1) p a n tallas (en la interfaz del usuario), 2) reportes y 3) c o m p o n e n t e s que p r o b a b l e m e n t e se requieran p a r a construir la aplicación. Cada instancia de objeto (por ejemplo, u n a pantalla o reporte) se clasifica en uno de tres niveles de complejidad (es decir, simple, m e d i o o difícil) aplicando criterios sugeridos por Boehm [BOE96]. En esencia, la complejidad es una función del n ú m e r o y origen de las tablas de d a t o s del cliente y el servidor que se requieren para generar la pantalla o reporte, y el n ú m e r o de vistas o secciones p r e s e n t a d a s c o m o parte de la pantalla o el informe. ¿Qué es M punto

Una vez q u e se ha d e t e r m i n a d o la complejidad, el n ú m e r o de pantallas, informes y c o m p o n e n t e s se pondera de a c u e r d o con la tabla ilustrada e n la figura 23.6. Entonces se determina la cuenta de p u n t o s objeto al multiplicar el n ú m e r o original de instancias de objeto por el factor de ponderación en la figura y se s u m a para obtener u n a cuenta total de p u n t o s objeto. Al aplicar el desarrollo b a s a d o e n c o m p o n e n t e s o la reutilización general de software se estima el porcentaje de reutilización (%reut) y se ajusta la cuenta de p u n t o s objeto: NPO = (puntos objeto) x [(100 - %reut)/100] d o n d e NPO se define c o m o n u e v o s p u n t o s objeto. Para o b t e n e r una estimación del e s f u e r z o con b a s e en el valor NPO calculado, se d e b e calcular una "tasa de productividad". La figura 23.7 presenta la tasa de producTM tividad PROD = N P O / p e r s o n a - m e s

PDF Editor

para diferentes niveles de experiencia del desarrollador y m a d u r e z del e n t o r n o de desarrollo. Una vez determinada la tasa de productividad se p u e d e obtener u n a estimación del e s f u e r z o del proyecto del m o d o siguiente: e s f u e r z o e s t i m a d o = NPO/PROD

712

PARTE C U A T R O

Ponderación d e complejidad p a t a tipos d e objeto [BOE96].


Peso de complejidad

Tipo d e objeto

Simple

Medio

Difícil

Pantalla

1

2

3

Reporte

2

5

8

C o m p o n e n t e 3GL

10

Tasa d e productividad por puntos objeto [BOE96],

Experiencia/capacidad del desarrollador

Muy baja

Boja

Nominal

Alta

Muy alta

Madurez/capacidad del entorno

Muy baja

Baja

Nominal

Alta

Muy alta

4

7

13

25

50

TASA PRODUCTIVIDAD (PROD)

En modelos COCOMO II m á s avanzados 1 0 se requieren varios factores de esca a. controladores de costo y procedimientos de ajuste. El lector interesado debe leer [BOEOO] o visitar el sitio Web de COCOMO II.

23.7.3 9 www.qsm.cogi infamación ocertode Miramientos de estimación de costo de software que hon evolucionado a poitir de lo ecuación softwoie.

La e c u a c i ó n d e l s o f t w a r e

La ecuación de software [PUT92] es un modelo multivariable que supone una distr bución específica del esfuerzo a lo largo de la vida de un proyecto de desarrollo ce software. El modelo procede de datos de productividad recopilados de casi 4 OC>: proyectos de software contemporáneos. Con base en estos datos, un modelo de esv mación de la forma E = [LDC x B° " 3 / P j 3 x (1/í 4 )

(23-4i

donde E = esfuerzo en personas-mes o personas-año t = duración del proyecto en meses o años B = "factor especial de habilidades" 1 '

TM

PDF Editor

10 Como se anotó anteriormente, estos modelos utilizan conteos de PFy KLDC para la variable tamaft: 11 B aumenta lentamente conforme "crecen la necesidad de integración, las pruebas, la garantía de calidad, la documentación y las habilidades de gestión" [PUT92]. Para programas pequeños (KLDC a 15), B = 0.16. Para programas más grandes que 70 KLDC, B = 0.39.

CAPÍTULO 23

713


P = "parámetro de productividad" que refleja: madurez global del proceso y prácticas de gestión, la medida en la que se emplean las buenas prácticas de ingeniería del software, el nivel de los lenguajes de programación utilizados, el estado del entorno del software, las habilidades y experiencias del equipo de software, y la complejidad de la aplicación. Los valores típicos pueden ser P = 2 000 para desarrollo del software anidado de tiempo real; P = 10 000 para software d e telecomunicaciones y sistemas; P = 28 000 para aplicaciones de sistemas de negocios. El parámetro de productividad se puede calcular para condiciones locales si se emplean datos históricos recopilados de esfuerzos de desarrollo previos. Es importante notar que la ecuación del software tiene dos parámetros independientes: 1) una estimación del t a m a ñ o (en LDC) y 2) una estimación de la duración del proyecto en meses o años calendario. Putnam y Myers [PUT92] sugieren un conjunto de ecuaciones derivadas de la ecuación del software para simplificar el proceso de estimación y emplear una forma más común para su modelo de estimación. El tiempo mínimo de desarrollo se define como t mjn = 8.14(LDC/P) 043 en meses para tmin > 6 meses E = 180Bí3 en personas-mes para E > 20 personas-mes

(23-5a) (23-5b)

Nótese que t se representa en a ñ o s en la ecuación (23-5b). Al utilizar las ecuaciones (23-5) con P = 12 000 (el valor recomendado para software científico) para el software CAD estudiado previamente en este capítulo, £mln = 8.14(33 200/12 000)" 43 tmin = 12.6 meses calendario £ = 180 X 0.28 X (1.05)3 E = 58 personas-mes Los resultados de la ecuación del software corresponden favorablemente con las estimaciones desarrolladas en la sección 23.6. Al igual que el modelo COCOMO señalado en la sección precedente, la ecuación del software ha evolucionado durante la década pasada. En [PUT97b] se puede encontrar una detallada exposición de una versión extendida de este enfoque de estimación. TM

Vale la p e n a complementar los métodos convencionales de estimación de costo del software con un enfoque diseñado explícitamente para software OO. Lorenz y Kidd [LOR94] sugieren el enfoque siguiente

PDF Editor

1. Desarrollar estimaciones aplicando la descomposición de esfuerzo, análisis de PF y cualquier otro método que sea aplicable en aplicaciones convencionales.

714

PARTE C U A T R O

2.


Aplicar el modelado de análisis orientado a objetos (capítulo 8), desarrollar casos de uso y determinar un conteo. Reconocer que el número de casos de uso puede cambiar conforme avance el proyecto.

3 . A partir del modelo de análisis, determinar el número de clases clave (llamadas clases de análisis en el capítulo 8). 4 . Categorizar el tipo de interfaz para la aplicación y desarrollar un multiplicad para las clases de soporte: Tipo d e i n t e r f a z

Multiplicador

Sin IUG Interfaz del usuario basada en texto IUG IUG com pleia

2.0 2.25 2.25 3.0

Multiplicar el número de clases clave (paso 3) por el multiplicador para obtener una estimación del número de clases de soporte. 5. Multiplicar el número total de clases (clave + soporte) por el número promedio de unidades de trabajo por clase. Lorenz y Kidd sugieren de 15 a 20 perscnas-día por clase. 6.

Comprobar de manera cruzada la estimación basada en clase al multiplicar e número promedio de unidades de trabajo por caso de uso.

Las técnicas de estimación estudiadas en las secciones 23.6, 23.7 y 23.8 se pue aplicar en cualquier proyecto de software. Sin embargo, cuando un equipo de : ware encuentra una duración de proyecto extremadamente corta (semanas más que 1 meses) —que probablemente tengan una continua corriente de cambios— la piar cación del proyecto en general y la estimación en particular se deben abreviar. 12 Ea | las secciones siguientes se examinan dos técnicas de estimación especializadas.

23.9.1 Estimación p a r a desarrollo ágil Puesto que los requerimientos para un proyecto ágil (capítulo 4) se definen como un ] conjunto de escenarios de usuario (por ejemplo, "historias" en programación extrema) es posible desarrollar un enfoque de estimación informal, TM aunque razonaba mente disciplinado y significativo dentro del contexto de la planificación del proye:to para cada incremento de software.

PDF Editor

La estimación para los proyectos ágiles aplica un enfoque de descomposición que ¡ abarca los pasos siguientes: 12 "Abreviar" no significa eliminar. Incluso los proyectos de corta duración deben planificarse, y la e s - | limación es el fundamento de la planificación sólida.

CAPITULO 23

¿Cómo se ' desarrollan iciones i se aplica i ágil?


715

1. Cada escenario de usuario (el equivalente de un minicaso de u s o c r e a d o en el c o m i e n z o m i s m o de un proyecto por los usuarios finales u otros participantes) se considera por s e p a r a d o respecto de propósitos de estimación. 2 . El escenario se d e s c o m p o n e e n el conjunto de funciones y las t a r e a s de ingeniería del s o f t w a r e que se requerirán para desarrollarlo. 3a.

Cada tarea se estima por separado. Nota: la estimación se p u e d e b a s a r en datos históricos, e n un modelo empírico o en la "experiencia".

3 b . Alternativamente, el "volumen" (tamaño) del escenario se p u e d e estimar en LDC, PF o alguna otra medida orientada a volumen (por ejemplo, p u n t o s objeto). [CONSEJO

4a. I -riexlo de lo i paro un >¥. ' e s una 7 del : global de un i usuario r.oPf.

Las estimaciones de cada tarea se s u m a n p a r a crear u n a estimación para el escenario.

4 b . Alternativamente, el volumen e s t i m a d o para el escenario se traduce e n esfuerzo mediante la aplicación de d a t o s históricos. 5.

Las estimaciones de e s f u e r z o acerca de t o d o s los e s c e n a r i o s que se implem e n t a r á n para un incremento de software d a d o se s u m a n con el fin de desarrollar el e s f u e r z o estimado para el incremento.

Puesto que la duración del proyecto requerido para el desarrollo de un in c r e m e n to de software es b a s t a n t e corta (usualmente de 3-6 s e m a n a s ) , este e n f o q u e de estimación tiene d o s propósitos: 1) asegurar que el n ú m e r o de escenarios que se incluirán en el incremento se integra con los recursos disponibles, y 2) establecer una b a s e p a r a ubicar el e s f u e r z o c o n f o r m e se desarrolla el incremento.

23.9.2 Estimación p a r a proyectos de ingeniería Web C o m o se a s e n t ó en el capítulo 16, los proyectos de ingeniería Web con frecuencia adoptan el modelo de proceso ágil. Es factible emplear una medición de p u n t o de función modificada, en c o n j u n t o con los p a s o s subrayados en la sección 23.9.1, con el fin d e desarrollar u n a estimación para la WebApp. Roetzheim (ROEOOj sugiere los siguientes valores de dominio de información c u a n d o se a d a p t a n p u n t o s de función (capítulos 15 y 22) para la estimación WebApp: • Entradas son c a d a pantalla o formato de entrada (por ejemplo, CGI o Java), cada pantalla de m a n t e n i m i e n t o y, si en alguna parte utiliza una etiqueta de TM metáfora de cuaderno, cada etiqueta. • Salidas son cada página Web estática, cada guión de página Web dinámica

PDF Editor

(por ejemplo, ASP, ISAPI u otro guión DHTML) y cada reporte (ya sea que e s t é b a s a d o en Web o sea del t o d o administrativo).

• Tablas son cada tabla lógica e n la b a s e de d a t o s más, si emplea XML para a l m a c e n a r d a t o s en un archivo, cada objeto XML (o colección de atributos XML).

716

PARTE C U A T R O


• Las interfaces retienen su definición c o m o archivos lógicos (por ejemplo, formatos de registro únicos) en las fronteras exteriores del sistema. • Consultas son cada interfaz publicada externamente o utiliza una interfaz orientada al mensaje. Un ejemplo típico son las referencias externas DCOM o COM. Los p u n t o s de función (calculados empleando los valores de dominio de información anotados) son un indicador razonable del volumen para una WebApp. M e n d e s y sus colegas [MEN011 sugieren que el volumen de una WebApp se determina mejor mediante la recopilación de medidas (llamadas "variables predictoras asociadas con la aplicación (por ejemplo, conteo de página, conteo de medios audiovisuales, conteo de función), las características de su página Web (por ejemplo, complejidad de página, complejidad de vinculación, complejidad gráfica), sus características de medios audiovisuales (por ejemplo, duración de los clips) y características funcionales (por ejemplo, longitud de código, longitud de código reutilizado) Dichas medidas se pueden emplear en el desarrollo de modelos de estimación emp:-


Estimación de esfuerzo y costo O b j e t i v o : El objetivo de las herramientas de • estimación de esfuerzo y costo es proporcionar al equipo del proyecto una estimación del esfuerzo requerido, de la duración del proyecto y del costo en una forma que aborde las características específicas del proyecto inmediato y el entorno en el que se construirá. M e c á n i c a : En general, las herramientas de estimación de costo utilizan una base de datos histórica procedente de proyectos locales, datos recopilados a través de la industria y un modelo empírico (por ejemplo, COCOMO II) que se emplea para calcular estimaciones de esfuerzo, duración y costo, tas características del proyecto y el entorno de desarrollo son entradas, y la herramienta proporciona un rango de estimación de salidas. Herramientas representativas13 Costar, desarrollado por Softstar Systems (www.softstarsystems.com), emplea el modelo COCOMO II para desarrollar estimaciones de software. Cost Xpert, desarrollado por Cost Xpert Group, Inc. (www.costxpert.com), integra modelos de estimación . múltiples y una base de datos histórica de proyectos,

Estímate Professional, desarrollado por el Software Productivity Center, Inc. (www.spc.com), está basado en COCOMO II y en el Modelo SUM. Knowledge Plan, desarrollado por Software Productivity Research (www.spr.com), utiliza la entrada de punto de función como el controlador primario para un paquete de estimación completo. Price 5, desarrollado por Price Systems (www.pricesystems.com), es una de las herramientas más viejas y ampliamente utilizadas en proyectos de desarrollo de software a gran escala. SEER/SEM, desarrollado por Galorath Inc. (www.galorath.com), proporciona una capacidad de estimación completa, análisis de sensibilidad, valoración de riesgo y otras características. SUM-Estimate, desarrollado por QSM (www.qsm.com), TM echa mano de "bases de conocimiento industrial" detalladas para ofrecer una "verificación sanitaria" de las estimaciones obtenidas empleando datos locales.

PDF Editor

13 Las herramientas anotadas aquí son una muestra de esta categoría. En la mayoría de los casos nombres de las mismas son marcas registradas por sus respectivos desarrolladores.

CAPÍTULO 23

717


rica para e s f u e r z o s de proyecto total, de creación de página, de creación de medios audiovisuales y de creación de guiones. Sin embargo, todavía falta realizar m á s trab a j o a n t e s de que tales m o d e l o s p u e d a n emplearse con confianza. 23.10

LA DECISIÓN DESARROLLAR-COMPRAR A m e n u d o , en m u c h a s á r e a s de aplicación de s o f t w a r e es m á s rentable adquirir que desarrollar s o f t w a r e de c o m p u t a d o r a . Los gestores de ingeniería del software e n f r e n t a n u n a decisión de desarrollar-comprar que tal vez se complique a ú n m á s por varias opciones de adquisición: 1) el s o f t w a r e se p u e d e c o m p r a r (o adquirir la licencia) ya desarrollado, 2) los c o m p o n e n t e s de software de "experiencia completa" o "experiencia parcial" (véase la sección 23.4.2) se pueden adquirir y luego modificar e integrar para satisfacer n e c e s i d a d e s específicas, o 3) el s o f t w a r e se p u e d e construir de m a n e r a personalizada por m e d i o de un contratista externo para satisfacer las n e c e s i d a d e s del comprador. Los p a s o s involucrados en la adquisición los definen lo crucial de! software que se c o m p r a r á y el costo final. En el análisis final, la decisión desarrollar-comprar se realiza b a s á n d o s e en las siguientes condiciones: 1) ¿El producto de s o f t w a r e estará disponible a n t e s que el software desarrollado de m a n e r a interna? 2) ¿El costo de adquisición m á s el costo de personalización será m e n o r que el costo de desarrollar el software de m a n e r a interna? 3) ¿El costo del soporte externo (por ejemplo, un contrato de mantenimiento) será m e n o r que el costo del soporte interno? Estas condiciones se aplican a cada u n a de las opciones de adquisición.

23.10.1 Creación de un árbol de decisión Los p a s o s recién descritos se p u e d e n a u m e n t a r m e d i a n t e técnicas estadísticas tales

¿Existe una forma ¡(a de las

c o m o el análisis del árbol de decisión [BOE89]. Por ejemplo, la figura 23.8 bosqueja un

con la

lizar c o m p o n e n t e s existentes de "experiencia parcial" para construir el sistema, 3)

árbol de decisión para un sistema b a s a d o e n software, X. En este caso, la organización de ingeniería del software p u e d e 1) construir el sistema X d e s d e cero, 2) reuticomprar un producto de software disponible y modificarlo para satisfacer las nece-

ollar7

sidades locales, o 4) contratar el desarrollo de software con una e m p r e s a externa. Si el sistema se construirá d e s d e c e r o existe un 70 por ciento de probabilidad de que el trabajo sea difícil. Al emplear las técnicas de estimación estudiadas a n t e s en este capítulo, el planificador del proyecto estima que un e s f u e r z o de desarrollo difíTM que costará cil costará 450 000 dólares. Un esfuerzo de desarrollo "simple" se estima 380 000 dólares. El valor esperado para el costo, calculado a lo largo de cualquier rama del árbol de decisión, e s

PDF Editor costo e s p e r a d o = I (probabilidad de la ruta

x (costo e s t i m a d o de la ruta),

d o n d e i es la trayectoria del árbol de decisión. Para la trayectoria de construcción, costo esperado c o n s t r u l I = 0.30(380K c .areí - 0.70(450K dólares) = 429K dólares

718

PARTE C U A T R O


Arbol d e d e c i s i ó n para apoyar la decisión desarrollarcomprar.

Simple (0.30)

3 8 0 0 0 0 dolores 4 5 0 0 0 0 dólares 2 7 5 0 0 0 dólares

3 1 0 0 0 0 dólares

4 9 0 0 0 0 dólares

2 1 0 0 0 0 dólares 4 0 0 0 0 0 dólares

3 5 0 0 0 0 dólares 5 0 0 0 0 0 dólares

Al seguir otras trayectorias del árbol de decisión también se muestran, en una diversidad de circunstancias, los costos proyectados para reutilización, compra y contratación. Los costos esperados para dichas trayectorias son costo esperado Ieuli | ¡zar = 0.40(275K dólares) = 0.60(0.20(310K dólares) + 0.80(490K dólares)] = 382K dólares costo esperadOcomprar = 0.70(210K dólares) + 0.30(400Kdólares) = 267K dólares costo esperado m n , r a l a r = 0.60(350K dólares) + 0.40(500K dólares) = 410K dólares Con base en la probabilidad y los costos proyectos que se han anotado en la figura 23.8, el costo esperado más bajo es la opción "comprar". Sin embargo, es importante señalar que se deben considerar muchos criterios —no sólo costo— durante el proceso de toma de decisión. Disponibilidad, experiencia del desarrollador-vendedor-contratista, concordancia con los requisitos, "políticas" locales y la probabilidad de cambiar son sólo algunos de los criterios que pueden incidir en la decisión final de construir, reutilizar, comprar o contratar.

23.10.2 Subcontratación

TM

Tarde o temprano, cualquier compañía que desarrolla software de computadora se plantea una pregunta fundamental: ¿existe una forma de conseguir los sistemas y software necesarios a un precio más bajo? La respuesta no es tan simple, y los debates emocionales que genera la pregunta siempre conducen a una sola palabra: subcontratación.

PDF Editor

Como concepto, la subcontratación es extremadamente simple. Las actividades de ingeniería del software se contratan con una tercera parte que realiza el trabajo

CAPÍTULO 2 3

719


a un c o s t o m á s b a j o y, así se espera, mayor calidad. El trabajo de s o f t w a r e llevado a c a b o dentro de u n a c o m p a ñ í a se reduce a u n a actividad de gestión de contratos. 1 4 " C o m o regla, la subcontratación requiere i n d u s o m á s gestión e x p e r t a q u e el desarrollo en casa."

Steve McCannell La decisión de subcontratar p u e d e ser estratégica o táctica. En el ámbito estratégico, los gestores comerciales consideran si u n a porción significativa de t o d o el trab a j o de s o f t w a r e se p u e d e contratar con otros. En el p l a n o táctico, un gestor d e proyecto determina si parte o todo un proyecto p u e d e lograrse mejor al subcontratar el trabajo de software. Sin importar la amplitud de la visión, la decisión de subcontratar u s u a l m e n t e es financiera.

Una exposición detallada del análisis financiero de la subcontratación

está m á s allá del á m b i t o de este libro y mejor se deja a otros (por ejemplo, [MIN95]). Sin embargo, vale la p e n a una breve revisión de los pros y contras de la decisión. En el lado positivo, usualmente es factible ahorrar e n el c o s t o reduciendo el n ú m e r o de personal de software y las instalaciones (por ejemplo, c o m p u t a d o r a s , infraestructura) que los soportan. En el lado negativo, u n a c o m p a ñ í a pierde cierto control sobre el s o f t w a r e q u e necesita. Dado que el s o f t w a r e es una tecnología que diferencia sus sistemas, servicios y productos, u n a c o m p a ñ í a corre el riesgo de poner el destino de s u competitividad en las m a n o s de u n a tercera parte.

HOGARSEGURO

Subcontratación

- S A I IP

El e s c e n a r i o : Sala de juntas de

a c t o r e s : Mal Golden, gerente ejecutivo, desarrollo producto; lee Warren, gerente de ingeniería; Joe VP ejecutivo, desarrollo comercial; Doug . gerente de proyecto, ingeniería de software, conversación: Joe: Estamos considerando subcontratar la porción de del software del producto HogarSeguro. ( i m p r e s i o n a d o ) : ¿Cuándo sucedió esto? Lee: Obtuvimos un presupuesto de un desarrollador = tierno. Presupuesta un 30 por ciento por debajo de lo

que tu grupo parece creer que costará. Aquí. [Extiende el presupuesto a Doug, quien lo lee.] Mal: Como sabes, Doug, estamos tratando de mantener los costos bajos, y 30 por ciento es 30 por ciento. Además, estas personas vienen muy bien recomendadas. D o u g ( t o m a un r e s p i r o e i n t e n t a r e c u p e r a r l a c a l m a ) : Me tomaron por sorpresa, pero antes de que tomen una decisión final, ¿algunos comentarios? J o e ( a s i e n t a c o n la c a b e z a ) : Seguro, adelante D o u g : No hemos trabajado con esta empresa TM subcontratista antes, ¿cierto? Mal: Cierto, pero ..

PDF Editor

14 La subcontratación se puede considerar, d e r r . a r e ' í —ás general, como cualquier actividad que conduce a la adquisición de software o algunos de sus componentes con una fuente externa a la organización de ingeniería del software.

PARTE CUATRO

720


D o u g : Y ellos anotan que cualquier cambio a las especificaciones será cobrado a una tasa adicional, jcierto 2 ¿

liberaciones d e producto, sin importar qué hagan en la primera, y 4) aprenderemos en e) camino lo relativo a un proyecto internacional.

J o e (frunce e l e n t r e c e j o ) ; Cierto, pero esperamos que las cosas serán razonablemente estables.

[Todos guardan silencio.]

D o u g : Una mala suposición, Joe. Joe! B u e n o . . . .

"1 >

1

<

D o u g : Es probable que liberemos nuevas versiones de este producto durante algunos años. Y es razonable suponer que el software proporcionará muchas de las nuevas características, ¿cierto? [Todos afirman con la cabeza.] D o u g : ¿Alguna vez hemos coordinado un proyecto internacional? Lee ( s e v e p r e o c u p a d o ) : No, pero me dijeron... D o u g (intenta suprimir s u e n o j o ) : Ásf que lo que me estáft diciendo es: 1) estamos a punto de trabajar con una empresa desconocida, 2) los costos para hacer esto no son tan bajos cómo parecen, 3) de facto nos estamos comprometiendo a trabajar con ellos durante muchas

23.11

RESUMEN

D o u g : Muchachos... creo qué"esto es un error, y me gustaría que tomaran un día para reconsiderar. Tendremos más control si hacemos el trabajo en casa. Tenemos la experiencia y puedo garantizar que no nos costará mucho más... el riesgo será más bajo y yo sé que todos tienen aversión por el riesgo, como yo. J o e ( c e ñ u d o ) : Has anotado buenos puntos, pero tú tienes un interés personal en mantener este proyecto en

CaSa,

\ 'í;íf i.:;:

'

D o u g : Es cierto, pero eso no cambia los hechos. J o e (con un s u s p i r o ) : Muy bien, pospongamos esto un día o dos, pensemos en ello un poco más y reunámonos de nuevo para una decisión final. Doug, ¿puedo hablar contigo en privado? D o u g : Claro... Realmente quiero estar seguro de que hacemos las cosas correctas.

2

?I

El planificador del proyecto de software debe estimar tres factores antes de que un proyecto comience: cuánto tiempo tomará, cuánto esfuerzo requerirá y cuánto pe: sonal estará involucrado. Además, el planificador debe predecir los recursos (har: ware y software) que se requerirán y el riesgo involucrado. La descripción del ámbito ayuda al planificador a desarrollar estimaciones emplear do una o m á s técnicas que se clasifican en dos amplias categorías: descomposicicn y modelado empírico. Las técnicas de descomposición requieren un bosquejo de las principales funci: nes del software, seguido por estimaciones de 1) el número de LDC, 2) valores seleccionados dentro del dominio de información, 3) el número de casos d e uso, 4) el número de personas-mes requerido para implementar cada función, TM o 5) el númer: de personas-mes requerido para cada actividad de ingeniería del software. Las técnicas empíricas usan expresiones para esfuerzo y tiempo obtenidas empíricamen:;

PDF Editor

para predecir estas cantidades del proyecto. Se pueden utilizar herramientas a u t o matizadas para implementar un modelo empírico específico. Por lo general, las estimaciones precisas de proyecto emplean al m e n o s dos de las tres técnicas anotadas. Al comparar y reconciliar las estimaciones obtenidas cor la aplicación de diferentes técnicas, el planificador tiene más probabilidad de calcu-

CAPÍTULO 23

721


lar una estimación precisa. La estimación del proyecto de software nunca será una ciencia exacta, pero una combinación de buenos datos históricos y técnicas sistemáticas puede mejorar la precisión de la estimación.

REFERENCIAS [BEN92] Bennatan, E. M., software Project Management: A Practiüoner's Approach, McGraw-Hill, 1992. [BEN03] Bennatan, E. M„ "So What is t h e State of Software Estimation?" en The CutterEdge (hoja informativa en línea), 11 de febrero d e 2002, disponible en h t t p : / / w w w . c u t t e r . c o m .

[BOE81] Boehm, B., Software Engineering Economics, Prentice-Hall, 1981. [BOE89] Boehm, B., Risk Management, IEEE Computer Society Press, 1989. 1BOE96J Boehm, B., "Anchoring the Software Process", en IEEE Software, vol. 13, n ú m . 4, julio d e 1996, pp. 73-82.

[BOEOO] Boehm, B. et al., Software Cost Estimation in COCOMO II, Prentice-Hall, 2000. [BR0751 Brooks, F„ The Mythical Man-Month,

Addison-Wesley, 1975.

[GAU89I Gause, D. C. y G. M. Weinberg, Exploring Requirements: Quality Before Design, Dorset House, 1989.

|H00911 Hooper, J. y R. O. Chester, Software Reuse Guidelines and Methods, Plenum Press, 1991. [JON96] Jones, C., "How Software Estimation Tools Work", en American Programmer, vol. 9, núm. 7, julio d e 1996, pp. 19-27. [LOR94] Lorenz, M. y j . Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994. [MAT94] Matson, J., B. Barrett y J. Mellichamp, "Software Development Cost Estimation Using

Function Points", en IEEE Trans. Software Engineering, vol. SE-20, núm. 4, abril de 1994, pp. 275-287.

[MCC98] McConnell, S„ Software Project Surviva! Guide, Microsoft Press, 1998. [MEN01] Mendes, E., N. Mosley y S. Counsell, "Web Metrics-Estimating Design and Authoring Effort", IEEE Multimedia, e n e r o - m a r z o de 2001, pp. 50-57. [MIN95] Minoli, D., Anafyzing Outsourcing, McGraw-Hill, 1995. [PHI98] Phillips, D„ The Software Project Manager's Handbook, IEEE Computer Society Press, 1998. [PUT78] Putnam, L., "A General Empirical Solution to the Macro Software Sizing and Estimation

Problem", en IEEE Trans. Software Engineering, vol. SE-4, núm. 4, julio de 1978, pp. 345-361. [PUT92] Putnam, L. y W. Myers, Measures for Excellence, Yourdon Press, 1992. [PUT97a] Putnam, L. y W. Myers, "How Solved Is the Cost Estimation Problem?", en IEEE Software, noviembre d e 1997, pp. 105-107.

[PUT97b] Putnam, L. y W. Myers, Industrial Strength Software: Effective Management Using Measurement, en IEEE Computer Society Press, 1997. [ROEOO] Roetzheim, W., "Estimating Internet Development", en Software Development, agosto d e 2000, disponible en h t t p : / / w w w . s d m a g a z i n e . c o m / d o c u m e n t s / s = 7 4 1 / s d m 0 0 0 8 d / 0 0 0 8 d . h t m . ¡SMI99] Smith,)., "The Estimation of Effort Based on Use Cases", Rational Software Corp., 1999, se p u e d e descargar d e h t t p : / / w w w rational.com/media/whitepapers/finalTP171.PDF.

PROBLEMAS Y PUNTOS A CPNSIPERAR

, TM

2 3 . 1 . Suponga q u e es el gestor de proyecto d e u n a compañía que construye s o f t w a r e p a r a robots caseros. Se le ha contratado p a r a construir el software destinado a un robot q u e corta el pasto. Describa por escrito el ámbito del software. Asegúrese d e q u e la descripción del ámbito e s t é acotada. Si n o está familiarizado con los robots, investigue un poco a n t e s d e c o m e n z a r a escribir. A d e m á s , e s t a b l e z c a s u s s u p o s i c i o n e s a c e r c a del h a r d w a r e que se requerirá. Alternativa: sustituya el robot que corta el p a s t o por otro problema robótico q u e le interese.

PDF Editor

2 3 . 2 . La complejidad del proyecto de s o f t w a r e influye en la precisión d e la estimación. Desarrollar u n a lista d e características de software :ar¡ecer prioridades en la lista.

722

PARTE C U A T R O


2 3 . 3 . El d e s e m p e ñ o e s u n a consideración i m p o r t a n t e d u r a n t e la planificación. C o m e n t a r c se p u e d e interpretar d e m a n e r a diferente el d e s e m p e ñ o , d e p e n d i e n d o del á r e a d e aplicación software. 2 3 . 4 . Haga u n a d e s c o m p o s i c i ó n funcional del s o f t w a r e robótico q u e describió e n el probl 23.1. Estime el t a m a ñ o de c a d a función e n LDC. S u p o n g a q u e su organización p r o d u c e LDC/pm con u n a escala salarial de 7 000 d ó l a r e s por p e r s o n a - m e s . Estime el e s f u e r z o y c requeridos para construir el s o f t w a r e e m p l e a n d o la técnica de estimación b a s a d a e n LDC crita en este capítulo. 2 3 . 5 . Emplear el m o d e l o COCOMO II e n la estimación del e s f u e r z o q u e requiere la constru del s o f t w a r e para una simple ATM q u e p r o d u c e 12 pantallas, 10 reportes y requerirá aproxim m e n t e 80 c o m p o n e n t e s de software. Suponer complejidad p r o m e d i o y m a d u r e z desarrol' e n t o r n o promedio. Emplear el m o d e l o d e composición de aplicación con p u n t o s objeto. 2 3 . 6 . Utilizar la e c u a c i ó n del s o f t w a r e p a r a estima r el s o f t w a r e del robot q u e corta pasto p r o b l e m a 23.1. Suponer q u e las e c u a c i o n e s (23-5) s o n aplicables y q u e P = 8000. 2 3 . 7 . C o m p a r a r las e s t i m a c i o n e s de e s f u e r z o o b t e n i d a s e n los p r o b l e m a s 23.4 y 23.6. ¿Cuál es la desviación e s t á n d a r y c ó m o afecta el g r a d o de c e r t i d u m b r e acerca d e la estimación? 2 3 . 8 . Utilizar los r e s u l t a d o s o b t e n i d o s e n el p r o b l e m a 23.7 p a r a d e t e r m i n a r si e s r a z o n a r í e s p e r a r q u e el s o f t w a r e s e c o n s t r u y a d e n t r o de los siguientes seis m e s e s y c u á n t o personal ¿e tendría q u e e m p l e a r para realizar el trabajo. 2 3 . 9 . Desarrollar u n m o d e l o d e h o j a s de cálculo q u e i m p l e m e n t e u n a o m á s de las técnicas e s t i m a c i ó n descritas e n este capitulo. Alternativamente, adquirir de f u e n t e s b a s a d a s e n v . e : u n o o m á s m o d e l o s en línea para la estimación d e proyectos de s o f t w a r e . 2 3 . 1 0 . Para u n e q u i p o d e proyecto, desarrollar u n a h e r r a m i e n t a d e s o f t w a r e q u e implemer.ií c a d a u n a d e las técnicas d e estimación d e s a r r o l l a d a s en este capítulo. 2 3 . 1 1 . Parece e x t r a ñ o q u e las e s t i m a c i o n e s de costo y p r o g r a m a d e t r a b a j o s e desarrolled u r a n t e la planificación del proyecto d e software, a n t e s d e q u e s e h a y a llevado a c a b o u n diseño o u n análisis detallado d e los requisitos de s o f t w a r e . ¿Por q u é c r e e q u e se h a g a esto? ¿Existec i r c u n s t a n c i a s en las c u a l e s n o s e d e b a h a c e r ? 2 3 . 1 2 . Vuelva a calcular los v a l o r e s a n o t a d o s p a r a el árbol de decisión e n la figura 23 : S u p o n g a q u e c a d a r a m a tiene u n a probabilidad d e 50-50. ¿Esto c a m b i a r í a su decisión final?

La mayoría d e los libros de gestión de proyectos de s o f t w a r e incluyen análisis de la e s t i m a c í c r de proyectos. El Project M a n a g e m e n t Institute (PMBOK Guide, PMI, 2001), Wysoki y s u s colegas

(.Effective Project Management, Wiley, 2000), Lewis (Project Planning Scheduling and Control, tercera edición, McGraw-Hill, 2000), Bennatan (On Time, Within Budget: Software Pro/e": Management Practices and Techniques, tercera edición, Wiley, 2000) y Phillips [PHI98] ofrecen u: les directrices d e estimación. Jone s (EStimating Software Costs, McGraw-Hill, 1998) h a escrito u n o d e TM los t r a t a m i e n t o s mas c o m p l e t o s de la m a t e r i a p u b l i c a d o s a la f e c h a . Su libro c o n t i e n e m o d e l o s y d a t o s aplicables a e s t i m a c i o n e s d e s o f t w a r e e n cualquier d o m i n i o de aplicación. C o o m b s (IT Project EstimaticCambridge University Press, 2002), Roetzheim y Beasley (Software Project Cost and Schedu *

PDF Editor

Estimating: Best Practices, Prentice-Hall, 1997) y Wellman (Software Costing, Prentice-Hall, 1992 p r e s e n t a n m u c h o s m o d e l o s útiles y sugieren directrices p a s o a p a s o para g e n e r a r las mejores e s t i m a c i o n e s posibles. El d e t a l l a d o t r a t a m i e n t o d e Putnam y Myers de la estimación de c o s t o del s o f t w a r e ([PUT91 y [PUT97b]) y los libros de Boehm a c e r c a de e c o n o m í a d e ingeniería del s o f t w a r e ([BOE811 y COCOMO II [BOEOO]) d e s c r i b e n m o d e l o s de estimación empíricos. Estos libros p r o p o r c i o n a n u n análisis d e t a l l a d o d e d a t o s derivados d e c i e n t o s d e proyectos de s o f t w a r e . Un libro excelente de

CAPÍTULO 23

723

ESTIMACIÓN PARA PRO YE ~ O S DE SOFTWARE

DeMarco (Controlling Software Projects, Yourdon Press, 1982) ofrece un valiosa visión d e gestión, medición y estimación de proyectos d e software. Lorenz y Kidd (Object-Oriented Software

Metrics, Prentice-Hall, 1994) y Cockbum (Survhing Object-Oriented Projects, Addison-Wesley, 1998) consideran la estimación para sistemas orientados a objetos. En Internet hay disponible u n a amplia variedad de f u e n t e s d e información acerca de estimación de software. Una lista actualizada de referencias en la World Wide Web se encuentra en el sitio Web d e SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P I T U L O

24 CONCEPTOS CLAVE anáfisis del trabajo . . . . 7 3 7 cronogramas.. .738 curvoPNR . . . . 7 3 0 demora

725

distribución d e esfuerzo

. . . . .732

personal y esfuerzo

729

principios básicos

728

red d e t a r e a s . . 7 3 5 refinamiento de toreas

734

seguimiento . . . 7 3 9

time-boxing .. .740 •ado . 7 4 2

CALENDARIZACIÓN DE P R O Y E C T O S DE S O F T W A R E

A

fínales de los d e los a ñ o s 60, un joven y brillante ingeniero fue elegidc para "escribir" un p r o g r a m a de c o m p u t a d o r a para u n a aplicación indus trial a u t o m a t i z a d a . La razón por la cual se le eligió fue simple: era la ún: c a persona en el grupo técriico que había asistido a un seminario de programa ción de computadoras. Él conocía las e n t r a d a s y salidas del lenguaje ensambla dor y de FORTRAN, pero nada acerca de ingeniería del software, e incluso me n o s acerca de calendarización y seguimiento de proyectos. Su jefe le dio los m a n u a l e s apropiados y u n a descripción verbal d e lo que te nía que hacer. Se le informó que el proyecto debía terminarse en dos meses. El ingeniero leyó los manuales, consideró su e n f o q u e y c o m e n z ó a escribir e código. Después de dos s e m a n a s , el jefe lo llamó a su oficina y le preguntó có m o iban las COSaS. - : '£• "Realmente bien", dijo el joven ingeniero con e n t u s i a s m o juvenil. "Esto fum u c h o m á s simple de lo que pensé. Probablemente h e terminado cerca del 7; por ciento." El jefe sonrió y alentó al joven ingeniero a seguir trabajando bien. Planearereunirse de n u e v o en u n a s e m a n a . Una s e m a n a después, el jefe llamó al ingeniero a s u oficina y le p r e g u n u "¿Dónde estamos?". 'Todo marcha bien", dijo el joven, "pero m e he encontrado con algunos pequr ños obstáculos. Los solucionaré y regresaré al ritmo de trabajo muy pronto." "¿Cómo ves la fecha límite?", p r e g u n t ó el jefe.

¿ Q u é e s ? Usted seleccionó un modelo de proceso apropiado; ic tíficó las tareas de ingeniería del software que es preciso realizar; estimó la cantidad de trabajo y el número de personas; conoce la fecha límite; incluso consideró los riesgos. Ahora es tiempo de unir los puntos. Esto es, tiene que crear una red de tareas d e ingeniería del software que le permitirán tener el trabajo Üsto a tiempo. Una vez creada la red, tiene que asignar responsabilidades a cada tarea, asegurarse de que se realice y adaptar la red conforme los riesgos se vuelvan realidad. En resumen, esto es la calendarización y el seguimiento del proyecto de software.

¿ Q u i é n lo h a c e ? En el ámbito del proyecto los gestores del proyecto de software emplean la información solicitada a los ingenieros de software. En el plano individual, los mismos ingenieros de software ¿ P o r q u é e s i m p o r t a n t e ? En la construcción de un sistema complejo muchas tareas de ingeniería del software ocurren en paralelo, y el resultado del trabajo realizadoTM durante una tarea puede tener un profundo efecto en el trabajo llevado a cabo en otra tarea. ¡Estas interdependencias son muy difíciles de comprender sin una calendarización. También es virtualmente imposible evaluar el progreso de un proyecto de software moderado y grande sin una calendarización detallada.

PDF Editor 724

CAPÍTULO 24

725

C A L E N D A R E A C I Ó N DE PROYECTOS DE SOFTWARE

¿Cuáles s o n l o s p a s o s ? Las Jareas de ingeniería del software que dicta el modelo de proceso de software se refinan para la funcionalidad que se construirá. A cada tarea se le asignan esfuerzo y duración, y se crea una red de tareas (también llamada una "red de actividad") de tal forma que permita al equipo de software cumplir con la fecha límite de entrega establecida. ..Cuál e s el producto o b t e n i d o ? La calendarizactán del proyecto y la información relacionada.

¿ C ó m o m e p u e d o a s e g u r a r q u e lo h e h e c h o c o r r e c t a m e n t e ? La calendarización adecuada requiere que 1} todas las tareas aparezcan en la red, 2) el esfuerzo y el tiempo estén asignados de manera inteligente en cada tarea, 3) las interdependencias entre tareas estén indicadas adecuadamente, 4) los recursos estén asignados para el trabajo que se realizara y 5) los Hitos estén espaciados de modo cercano para que se pueda seguir el progreso.

"No hay problema", dijo el ingeniero. "Estoy cerca de terminar el 90 por ciento." Si se ha trabajado en el m u n d o del s o f t w a r e durante u n o s c u a n t o s a ñ o s se e s cap a z de terminar la historia. No será sorpresa que el joven ingeniero 1 haya p e r m a n e cido en el 90 por ciento d u r a n t e t o d o el proyecto y terminado (con la ayuda de otros) u n m e s después. Esta historia se ha repetido d e c e n a s de miles de veces con desarrolladores de s o f t w a r e d u r a n t e las p a s a d a s cuatro décadas. La gran pregunta es por qué.

24.1

C O N C E P T O S BÁSICOS

—

Aunque existen m u c h a s r a z o n e s por las c u a l e s el s o f t w a r e s e entrega con retraso, la mayoría se e n c u a d r a e n u n a o m á s de las siguientes causas: • Una fecha límite irrealizable establecida por alguien externo al grupo de ingeniería del s o f t w a r e e impuesta a los gestores y profesionales del grupo. • Cambio en los requisitos del cliente que no se reflejan e n modificaciones a la calendarización. • Una subestimación razonable de la cantidad de e s f u e r z o o de recursos que se requerirán para realizar el trabajo. • Riesgos predecibles o impredecibles que n o se consideraron c u a n d o c o m e n z ó el proyecto. • Dificultades técnicas que n o pudieron preverse. • Dificultades h u m a n a s imprevisibles.

TM

• Falta de comunicación entre el personal del proyecto, lo que genera demoras.

PDF Editor

• Una falla en la gestión del proyecto porque n o reconoció el retraso ni e m p r e n dió u n a acción para corregir el problema

1

En caso de que el lector se lo pregunte la histona e s autobiográfica.

726

PARTE C U A T R O


"Los calendorizaciones excesivas o irracionales probablemente son la fuerza particular más destructiva en todo el software."

Capers Jones

Las fechas límite muy a u d a c e s (léase "irrealizables") son u n h e c h o de la vida en e negocio del software. En tales ocasiones las fechas límite se d e m a n d a n por razones legítimas, d e s d e el p u n t o de vista de la persona que las establece. Pero el sentido com ú n establece que la legitimidad también la d e b e n advertir las p e r s o n a s que hacer, el trabajo. Napoleón dijo alguna vez: "Cualquier c o m a n d a n t e en jefe que pretenda llevar a c a b o un plan que considera defectuoso c o m e t e un error; d e b e exponer sus razones insistir en que el plan d e b e cambiarse y finalmente p r e s e n t a r su renuncia en luga: de ser el instrumento de la destrucción de su ejército". Estas s o n palabras fuertes que m u c h o s gestores de proyectos de s o f t w a r e deben considerar. Las actividades de estimación estudiadas en el capítulo 23 y las técnicas de calen darización descritas en éste con frecuencia se implementan a te n d ie n d o la restricción de una fecha límite definida. Si las m e j o r e s estimaciones indican que la f e c h ; límite e s irrealizable, un gestor de proyecto c o m p e t e n t e d e b e "proteger a su equipo de la presión excesiva [de la calendarización]... [y] devolver la presión a quienes i3 originan" [PAG85]. Para ilustrarlo, s u p ó n g a s e que a un equipo de ingeniería del s o f t w a r e se le h a pedido construir un controlador en tiempo real para un instrumento de diagnóstico médico que será introducido al m e r c a d o en n u e v e m e s e s . Después de una estimación y un análisis de riesgo cuidadosos (capítulo 25), el gestor del proyecto llega a la conclusión de que el software, c o m o se solicitó, requerirá 14 m e s e s para crearlo c o r el personal disponible. ¿Cómo procede el gestor del proyecto?

"Adoro las fechas limite. Me gusto que pasan como una exhalación cuando se alejan."

Douglas Adams

Es irreal p r e s e n t a r s e e n la oficina del cliente (en este c a s o el probable cliente es mercadotecnia-ventas) y d e m a n d a r l e que cambie la fecha de entrega. Las presiones externas del m e r c a d o han dictado la fecha, y el producto d e b e liberarse. Es igualm e n t e torpe r e c h a z a r el trabajo (desde el p u n t o de vista profesional). Así que, ¿que TM hacer? En esta situación se recomiendan los siguientes pasos: 1. Realizar u n a estimación detallada e m p l e a n d o d a t o s históricos de proyectos

PDF Editor

previos. Determinar el e s f u e r z o y la duración estimados para el proyecto.

2.

Aplicar un modelo de proceso incremental (capítulo 3) y desarrollar u n a estrategia de ingeniería de s o f t w a r e que entregará la funcionalidad crítica en la fecha límite impuesta, p e r o d e m o r a r á otra. Documente el plan.

»

¿Qué se debe hacer sondo la gestión M a n d a que se • • p í a con una « h a limite que «imposible?

CAPÍTULO 24

3.

727

C A L E N D A R E A C I Ó N DE PROYECTOS DE SOFTWARE

Reunirse con el cliente y, con la estimación detallada, explicarle por qué la fecha límite impuesta es irrealizable. Asegúrese de señalar q u e t o d a s las estimaciones están b a s a d a s sobre el d e s e m p e ñ o e n proyectos previos. También asegúrese de indicar el porcentaje de mejoría que se requeriría para lograr la fecha límite vigente. 2 Son apropiados los siguientes comentarios: "Creo que p o d e m o s tener un problema con la fecha de entrega para el software controlador XYZ. Le he d a d o a cada u n o de u s t e d e s un análisis abreviado de las t a s a s de producción en proyectos previos y una estimación que h e m o s hecho en a l g u n a s formas diferentes. Notarán que he s u p u e s t o u n 20 por ciento de mejora respecto de ritmos de producción precedentes, pero todavía t e n e m o s una fecha de entrega que está a 14 m e s e s en lugar de 9."

4 . Ofrezca la estrategia de desarrollo incremental c o m o alternativa: "Tenemos u n a s c u a n t a s opciones y me gustaría que t o m a s e u n a decisión con b a s e en ellas. Primero, p o d e m o s a u m e n t a r el p r e s u p u e s t o y conseguir recursos adicionales de m o d o que t e n d r e m o s m u c h o éxito en lograr que e s t e trabajo esté h e c h o en n u e v e meses. Pero c o m p r e n d a que esto a u m e n t a r á el riesgo d e u n a calidad deficiente debido a la a p r e t a d a fecha límite. 3 Segundo, p o d e m o s remover varias de las funciones y capacidades de s o f t w a r e que está solicitando. Esto hará que la versión preliminar del producto s e a un poco m e n o s funcional, pero p o d e m o s a n u n c i a r toda la funcionalidad y luego entregarla e n el periodo de 14 meses. Tercero, p o d e m o s prescindir de la realidad y esperar que el proyecto se complete en nueve m e s e s . Terminaremos con nada q u e se pueda entregar a un cliente. La tercera opción, e s p e r o que e s t é d e acuerdo, es inaceptable. La historia y n u e s t r a s m e j o r e s estimaciones indican que es irreal y un boleto hacia el desastre." Habrá algunos gruñidos, p e r o si se p r e s e n t a n estimaciones sólidas b a s a d a s en b u e n o s d a t o s históricos es probable que se elegirán versiones n e g o c ia d a s de las opc i o n e s 1 o 2. La fecha límite irreal se evapora.

A Fred Brooks, el bien conocido autor de The Mythical Man-Month

[BR095], se le pre-

g u n t ó una vez c ó m o se retrasaban los proyectos de s o f t w a r e en la calendarización. Su respuesta fue tan simple c o m o profunda: "Un día a la vez." TM

PDF Editor

2 Si la mejora requerida es de 10 a 25 por ciento de hecho tal vez sea posible tener listo el trabajo. Pero, con mayor probabilidad, la mejora requerida en el desempeño del equipo será mayor que el 50 por ciento. Esta es una expectativa irreal 3 También puede agregar que el aumento en t rumero de personas no reduce proporcionalmente el tiempo.

728

ÔNSEJO^^

las toreos requeridos paro lograr el objetivo de una gestión de proyecto no se deben llevar o cabo manualmente. Cxisten muchas excelentes herramientas de calendarización. Úselos.

PARTE C U A T R O


La realidad de un proyecto técnico (ya sea que involucre la construcción de una planta hidroeléctrica o el desarrollo de un sistema operativo) es que cientos de peq u e ñ a s t a r e a s deben realizarse para lograr una meta mayor. Algunas de tales tareas están fuera de la corriente principal y se pueden completar sin p r e o c u p a r s e acerca de su impacto sobre la fecha de terminación del proyecto. Otras tareas se encuentran en la "trayectoria critica". Si e s t a s t a r e a s "criticas" se retrasan en la calendarización, la fecha de terminación del proyecto se p o n e en riesgo. El objetivo del gestor e s definir todas las tareas del proyecto, construir una red que bosqueje sus interdependencias, identificar las tareas cruciales dentro de la red y luego seguir su progreso para garantizar que la d e m o r a se reconoce "un día a la vez" Para lograrlo el gestor d e b e tener una calendarización que se haya definido e n un grado de resolución que permita supervisar el progreso y controlar el proyecto. La calendarización

del proyecto de software e s una actividad que distribuye estima-

ciones de e s f u e r z o a través de la duración planificada del proyecto al asignar el esfuerzo a t a r e a s específicas de ingeniería del software. Sin e m b a r g o , es importante señalar que la calendarización evoluciona a lo largo del tiempo. Durante las prime ras e t a p a s de la planificación del proyecto se desarrolla una calendarización macroscópica. Este tipo de calendarización identifica las principales actividades del marco de trabajo del proceso y las f u n c i o n e s de producto a las que se aplican. Conforme e; proyecto transcurre, c a d a entrada e n la calendarización macroscópica se refina e r u n a calendarización detallada. Aquí se identifican y calendarizan t a r e a s específicas del s o f t w a r e (requeridas para completar una actividad). "Una calendarización d e m a s i a d o optimista no g e n e r a una calendarización real m á s corta, sino u n a m a y o r . "

Sleve MtConnell La calendarización para proyectos de ingeniería de software se puede ver desde dos perspectivas m á s bien diferentes. En la primera ya se h a establecido (irrevocablemente) una fecha final para la liberación de un sistema basado en computadora. La organización de software está restringida a distribuir esfuerzo dentro del marco temporal prescrito. La segunda visión de la calendarización de software supone que se han comentado límites cronológicos aproximados, pero que la fecha final la establece la organización de ingeniería del software. El esfuerzo se distribuye para utilizar mejor los recursos y la fecha final se define después de un análisis cuidadoso del software. Por desgracia, la primera situación se encuentra con mucha m á s frecuencia que la segunda. TM

24.2.1 Principios básicos Al igual que otras á r e a s de ingeniería del software, varios principios básicos guían la

PDF Editor calendarización de los proyectos: Compartimentación.

El proyecto d e b e dividirse en c o m p a r t i m e n t o s en varias acti-

vidades, acciones y t a r e a s manejables. Lograrlo requiere d e c o m p o n e r tanto el producto c o m o el proceso.

CAPÍTULO 24

CALENDAREACIÓN DE PROVECTOS TE SOFTWARE

Interdependencia.

iVE ! desorrolle izoción, r t e s e el f l é t e n s e los dos d e 6 , asígnense i y tiempo o , defínonse ahitos.

729

Se debe determinar la interdependencia de cada actividad, ac-

ción o tarea compartimentada. Algunas tareas deben ocurrir en secuencia mientras que otras pueden ocurrir en paralelo. Algunas acciones o actividades n o pueden comenzar mientras no esté disponible el producto de trabajo producido por otros. Otras acciones o actividades pueden ocurrir de manera independiente. Asignación de tiempo. A cada tarea por calendarizar se le debe asignar cierto número de unidades de trabajo (por ejemplo, personas-día de esfuerzo). Además, a cada tarea se le debe asignar una fecha de inicio y una otra de terminación que sean función de las interdependencias, y ya sea que el trabajo sea realizado con base en tiempo completo o parcial. Validación del esjuerzo. Todo proyecto tiene un número definido de personas en el equipo de software. Conforme ocurre la asignación de tiempo, el gestor de proyecto debe asegurarse de que, en un tiempo dado, n o se han asignado m á s que el número de personas calendarizadas. Por ejemplo, considere un proyecto que tiene tres ingenieros de software asignados (por ejemplo, tres personas-día están disponibles por día de esfuerzo asignado). 4 En un día dado s e deben completar siete tareas al mismo tiempo. Cada tarea requiere 0.50 personas-día de esfuerzo. Se ha asignado m á s esfuerzo que el número de personas para hacer el trabajo. Definición de responsabilidades. miembro específico del equipo.

Toda tarea caiendarizada s e le debe asignar a un

Definición de resultados. Toda tarea caiendarizada debe tener un resultado definido. En proyectos d e software el resultado normalmente es un producto de trabajo (por ejemplo, el diseño de un módulo) o una parte de él. Los productos de trabajo usualmente se combinan en los entregables. Definición de hitos. Cualquier tarea o grupo de tareas debe estar asociado con un hito del proyecto. Un hito s e logra cuando se ha revisado la calidad de uno o más productos de trabajo (capítulo 26) y se han aprobado. Cada uno de estos principios se aplica conforme evoluciona la calendarización del proyecto.

24.2.2 Relación entre el personal y el esfuerzo En un p e q u e ñ o proyecto de desarrollo de software una sola persona puede analizar los requisitos, realizar el diseño, generar el código y dirigir las pruebas. Conforme aumenta el t a m a ñ o de un proyecto, más gente resulta involucrada.TM(¡Rara vez se puede dar el lujo de acometer un esfuerzo de 10 personas-año con una persona que trabaje durante 10 años!)

PDF Editor 4

En realidad, hay disponibles menos de tres personas-dia de esfuerzo debido a las reuniones no relacionadas, enfermedades, vacaciones y una diversidad de otras razones. Sin embargo, para los propósitos del texto, se supone una disponibilidad de X por ciento

730

PARTE C U A T R O

ÔNSEJcffi. Sise deben agregar personas o un proyecto rebosado, asegúrese de que se les ha asignado trabajo enormemente comparlimentado.


Existe un mito común que todavía creen muchos gestores responsables del esfuerzo de desarrollo del software: "Si nos retrasamos en la calendarización, siempre podemos incorporar más programadores y recuperarnos más adelante en el proyecto". Desgraciadamente, agregar más personas en etapas tardías de un proyecto con frecuencia tiene un efecto perturbador sobre éste, lo que provoca que la calendar zación se desfase aún más. Las personas que se agregan deben aprender el sistema y la gente que les enseña es la misma que estaba haciendo el trabajo. Durante la enseñanza no se realiza trabajo y el proyecto experimenta mayores retrasos. Además del tiempo que tarda en aprender el sistema, m á s personal aumenta e número de rutas de comunicación y la complejidad de ésta a lo largo de un proyecto. Aunque la comunicación es absolutamente esencial para el éxito del d e s a r r o l : de software, cada nueva ruta de comunicación requiere un esfuerzo adicional y, pee lo tanto, tiempo suplementario. A lo largo de los años, los datos empíricos y el análisis teórico han demostrac: que las calendarizaciones de proyecto son elásticas. Es decir, es posible comprim en cierta medida la fecha de terminación deseada del proyecto (al añadir recursos, adicionales). También e s posible extender la fecha de terminación (al reducir el nu mero de recursos). La Curva Putnam-Norden-Rayleigh (PNR)5 proporciona un indicio de la relación ertre el esfuerzo aplicado y el tiempo de entrega para un proyecto de software. En = figura 24.1 se muestra una versión de la curva, que representa el esfuerzo del proyecto como función del tiempo de entrega. La curva indica un valor mínimo, que indica el tiempo de entrega de menor costo (es decir, el tiempo de entrega que generará el menor gasto de esfuerzo). Conforme se mueve a la izquierda de t0 (es de cir, conforme intenta acelerar la entrega), la curva se eleva en forma no lineal. Relación entre esíuerzo y t i e m p o d e entrega.

Costo de esfuerzo

TM

PDF Editor 'o

Tiempo d e desarrollo

Tmi„-0.75Td

5

En [NQR70] y [PUT78) se puede encontrar investigación original.

CAPÍTULO 24

CALENDAMZACIÓN DE PROYECTOS DE SOFTWARE

731

Como ejemplo, supóngase que un equipo de proyecto ha estimado un nivel de es-

\

fuerzo E a que se requerirá para lograr un tiempo de entrega nominal, t d , que e s óp-

CLAVE

timo en términos de calendarización y recursos disponibles. Aunque es posible ace-

o entrego puede orse, la curvo ' indica q u e los del proyecto se reducir ialmente.

primir m á s allá de 0.75 t d . Si se intenta una mayor compresión, el proyecto se mueve hacia "la región imposible" y el riesgo de fracaso se eleva mucho. La curva PNR

lerar la entrega, la curva se eleva muy pronunciadamente hacia la izquierda de t d . De hecho, la curva PNR indica que el tiempo de entrega del proyecto no se p u e d e c o m -

también indica que la opción de entrega de menor costo, t„ = 2 t d . La implicación aquí es que la demora en la entrega del proyecto puede reducir los costos significativamente. Desde luego, esto d e b e sopesarse frente al costo del negocio asociado con la demora. La ecuación del software [PUT92], introducida en el capítulo 23, se obtiene de la curva PNR y demuestra la relación e n o r m e m e n t e lineal entre el tiempo cronológico para completar un proyecto y el esfuerzo h u m a n o aplicado a éste. El número de lín e a s de código entregadas (enunciados fuente), L, se relaciona con el esfuerzo y el

(CONSEJO^. la lecha é l proyecto se codo vez más, xonza un punto i que el traba jo xede completarse el calendario, nportarel ; de personas logan el trabajo, lo reolidod una nuevo de entrega.

tiempo de desarrollo mediante la ecuación: L = P x EW3tA/i donde E e s el esfuerzo de desarrollo en personas-mes; P, un parámetro de productividad que refleja una diversidad de factores que conducen a trabajo de ingeniería del software de alta calidad (los valores típicos d e P varían entre 2 000 y 12 000); y t , la duración del proyecto en m e s e s calendario. Al reordenar esta ecuación del software se puede llegar a una expresión para el esfuerzo de desarrollo E: E = LV(PJf)

(24-1)

donde E es el esfuerzo utilizado (en personas-año) durante el ciclo de vida para el desarrollo y mantenimiento de software, y f es el tiempo de desarrollo en años. La ecuación para el esfuerzo de desarrollo se p u e d e relacionar con el costo del desarrollo al incluir un factor de escala salarial (costo/persona-año). Esto conduce a u n o s resultados interesantes. Considérese un complejo proyecto de software de tiempo real estimado en 33 000 LDC, 12 personas-año de esfuerzo. Si se asignan o c h o personas al equipo del proyecto, éste se puede completar en aproximadamente 1.3 años. Sin embargo, si s e extiende la fecha final a 1.75 años, la naturaleza e n o r m e m e n t e n o lineal del modelo descrito en la ecuación (24-1) proTM duce: E = L 3 / ( P 3 f ) - 3.8 personas-año

PDF Editor

Esto implica que, al extender la fecha final seis meses, ¡se puede reducir el número

de personas de o c h o a cuatro! La validez de tales resultados está abierta al debate, pero la implicación es clara: se pueden obtener beneficios al emplear m e n o s personal durante un periodo un poco m á s largo para lograr el mismo objetivo.

732

PARTE C U A T R O


24.2.3 Distribución del esfuerzo O ¿Cómo se • debe distribuir el esfuerzo a lo largo del flujo de trabajo del proceso de software?

Cada una de las técnicas de estimación de proyectos de s o f t w a r e estudiadas en ei capítulo 23 conduce a estimaciones de unidades de trabajo (por ejemplo, personasmes) requeridas para completar el desarrollo del software. Una distribución recomendada del esfuerzo a través del proceso de software con frecuencia se conoce como la regla 40-20-40. Cuarenta por ciento de t o d o s los e s f u e r z o s se asignan al análisis y el diseño de sistemas de entrada. Un porcentaje similar se aplica en p o n e r a prueba los sistemas de salida. Usted p u e d e inferir correctamente que la codificación (20 por ciento del esfuerzo) no tiene t a n t o énfasis. Esta distribución del e s f u e r z o se d e b e u s a r solamente c o m o guía. 6 Las características de cada proyecto deben dictar la distribución del esfuerzo. El trabajo realizado en la planeación del proyecto rara vez explica m á s de 2 - 3 por ciento del esfuerzo, a m e n o s que el plan c o m p r o m e t a a u n a organización a grandes gastos con alto riesgo. Los análisis de requisitos p u e d e n c o m p r o m e t e r 10-25 por ciento del e s f u e r z o de. proyecto. El e s f u e r z o e m p l e a d o en el análisis o elaboración de prototipos d e b e aumentar e n proporción directa con el t a m a ñ o y la complejidad del proyecto. Un intervalo del 20 al 25 por ciento de esfuerzo normalmente se aplica al diseño de software También se d e b e considerar el tiempo utilizado en la revisión del diseño y la subsiguiente iteración. Debido al e s f u e r z o aplicado al diseño de software, el código d e b e seguir con relativamente poca dificultad. Se p u e d e lograr un rango de 15-20 por ciento del esfuerzo global. Las pruebas y la subsiguiente depuración explican el 30-40 por ciento de! esfuerzo de desarrollo del software. El carácter crucial del s o f t w a r e con frecuencia dicta la cantidad de p r u e b a s que se requieren. Si el software se clasifica d e s d e el p u n t o de vista h u m a n o (es decir, la falla del s o f t w a r e p u e d e resultar en pérdida de vidas), s o n usuales porcentajes todavía m á s altos.

En la parte 1 de e s t e libro se describieron varios m o d e l o s de proceso diferentes. Sin importar si un equipo de software elige un modelo secuencial lineal, un modelo incremental, un modelo evolutivo o alguna combinación, el modelo de proceso está poblado de un conjunto d e t a r e a s que le permiten a un equipo de s o f t w a r e definir, desarrollar y, a final de cuentas, brindar soporte al s o f t w a r e de computadora. Ningún conjunto de tareas es apropiado por sí solo para todos los proyectos. El TM conjunto de tareas que sería apropiado p a r a un sistema complejo y grande probable-

PDF Editor 6

En la actualidad, la regla 40-20-40 enfrenta una ofensiva. Algunos creen que más del 40 por ciento

del esfuerzo global se debe utilizar durante el análisis y el diseño. Por otra parte, algunos partidarios del desarrollo ágil (capítulo 4) argumentan que se debe emplear menos tiempo frontal "directo"

y que un equipo se debe mover rápidamente hacia la construcción.

CAPÍTULO 24

CALENDARIZACIÓN DE PROYECTOS E S SOFTWARE

733

mente se apreciaría como demasiado destructivo para un producto de software pequeño y relativamente simple. En consecuencia, un proceso de software eficaz debe definir una colección de conjuntos de tareas, cada una diseñada para satisfacer las necesidades de diferentes tipos de proyectos. Como se mencionó en el capítulo 2, un conjunto de tareas es una colección de tareas de trabajo de ingeniería del software, hitos y productos de trabajo que se deben terminar para completar un proyecto particular. El conjunto de tareas debe proporcionar suficiente disciplina para lograr alta calidad de software. Pero, al mismo tiempo, no debe abrumar al equipo del proyecto con trabajo innecesario. El desarrollo de una calendarización del proyecto requiere distribuir un conjunto d e tareas a lo largo de la línea de tiempo del proyecto. El conjunto de tareas variará según el tipo de proyecto y el grado de rigor con el que el equipo de software decide realizar su trabajo. Aunque es difícil desarrollar una taxonomía completa de tipos de proyecto de software, en la mayoría de las organizaciones del ramo se encuentran los siguientes proyectos: 1. Proyectos de desarrollo del concepto, los cuales se inician para explorar algunas aplicaciones o conceptos de negocios de alguna nueva tecnología. 2.

Proyectos de desarrollo de nuevas aplicaciones, los cuales se llevan a cabo como consecuencia de una solicitud específica del cliente.

3 . Proyectos de mejora de la aplicación, éstos ocurren cuando el software existente experimenta grandes modificaciones en la función, el desempeño o las interfases visibles para el usuario final. 4. Proyectos de mantenimiento de aplicación, los cuales corrigen, adaptan o extienden el software existente en formas que no sean obvias inmediatamente para el usuario final. i lio desmolido un adaptable (APM, por ¡ussigtOsa Dnjuntos de toreos jiro íorios (Moveclos * sotlwore. Uno .-•esaiptifa completo l wwwjspa.

:om/apm.

5 . Proyectos de reingeniería, éstos se llevan a cabo con la finalidad de reconstruir un sistema existente (heredado), en todo o en parte. Incluso dentro de un solo tipo de proyecto, muchos factores influyen en la elección del conjunto de tareas. Por ejemplo [PRE99]: t a m a ñ o del proyecto, número de usuarios potenciales, lo crucial de la misión, duración de la aplicación, estabilidad de los requisitos, facilidad de comunicación con el usuario o desarrollador, madurez d e la tecnología aplicable, restricciones del desempeño, características anidadas y no anidadas, equipo del proyecto y factores de reingeniería. Cuando se consideran en conTM junto, estos factores ofrecen un indicio del grado de rigor que se debe aplicar al proceso de software.

PDF Editor 24.3.1 Ejemplo de conjunto d e tareas

Cada uno d e los tipos de proyecto descritos puede abordarse mediante un modelo de proceso lineal, secuencial, iterativo (por ejemplo, los modelos de elaboración de prototipo o incrementales) o evolutivo (por ejemplo el modelo espiral). En algunos casos,

734

PARTE C U A T R O


un tipo de proyecto fluye suavemente hacia el siguiente. Por ejemplo, los proyect de desarrollo del concepto que triunfan con frecuencia evolucionan en proyectos c t desarrollo de nuevas aplicaciones. Cuando termina un proyecto de desarrollo de nuevas aplicaciones, en ocasiones comienza un proyecto de mejora de una aplicaciór Esta progresión es tanto natural como predecible y ocurrirá sin importar el mode:: de proceso que adopte la organización. En consecuencia, las principales tareas dt ingeniería del software descritas en las secciones que siguen son aplicables a todos los flujos de modelo de proceso. Como ejemplo, considérense las tareas de ingeniería del software para un proyecto de desarrollo del concepto. Los proyectos de desarrollo del concepto se inician cuando se debe explorar el potencial para alguna nueva tecnología. No existe certeza de que la tecnología será aplicable pero un cliente (por ejemplo, marketing) cree que existen beneficios potenciales. Los pro yectos de desarrollo del concepto se enfocan en aplicar las siguientes tareas principales 1.1 La d e t e r m i n a c i ó n del á m b i t o d e l c o n c e p t o precisa el ámbito global del proyecto. 1.2 La p l a n e a c i ó n p r e l i m i n a r del c o n c e p t o establece la habilidad de la organización para acometer el trabajo que entraña el ámbito del proyecto. 1.3 La v a l o r a c i ó n d e l r i e s g o d e la t e c n o l o g í a evalúa el riesgo asociado con la tecnología que se implementará como parte del ámbito del proyecto. 1.4

La p r u e b a d e l c o n c e p t o demuestra la viabilidad de una nueva tecnología en el contexto del software.

1.5 La i m p l e m e n t a c i ó n del c o n c e p t o pone en práctica la representación del concepto en una forma que pueda revisarla un cliente y se utiliza para propósitos de "mercadotecnia" cuando se debe vender un concepto a otros clientes o gestores. 1.6 La r e a c c i ó n del c l i e n t e al concepto solicita realimentación acerca de un concepto de nueva tecnología y se dirige a aplicaciones específicas de los clientes. Una rápida exploración de estas tareas debe producir pocas sorpresas. De hecho, el flujo de ingeniería del software para los proyectos de desarrollo del concepto (y también para todos los otros tipos de proyectos) es poco más que sentido común.

24.3.2 Refinamiento de las tareas principales Las tareas principales descritas en la sección precedente se pueden utilizar para definir la calendarización macroscópica de un proyecto. Sin embargo, TM esta calendarización se debe refinar para crear una calendarización detallada del proyecto. El refinamiento comienza al tomar cada tarea principal y descomponerla en un conjunto de subtareas (con productos de trabajo e hitos relacionados). Como ejemplo de descomposición de tarea, considérese la tarea 1.1, "determinación

PDF Editor

del ámbito del concepto". El refinamiento de la tarea se puede lograr empleando un bosquejo de formato, pero en este libro se aplica un enfoque de lenguaje en el diseño del proceso para ilustrar el flujo de la actividad de determinación del ámbito del concepto.

CAPÍTULO 24


735

Definición tarea: Tarea 1.1 Determinación del ámbito del concepto 1.1.1

Identificar necesidades, beneficios y clientes potenciales;

1.1.2 Definir eventos de salida/control y entrada deseados que impulsen la aplicación; Comienza Tarea 1.1.2 1.1.2.1

RTF: Revisar la descripoión escrita de la necesidad 7

1.1.2.2 Derivar una lista de salidas/entradas visibles al cliente 1.1.2.3 RTF: Revisar salidas/entradas con el cliente y modificar conforme s e requiera fintarea Tarea 1.1.2 1.1.3 Definir la funcionalidad/comportamiento para cada función principal; Comienza Tarea 1.1.3 1.1.3.1

RTF: Revisar los o b j e t o s de datos de salida y entrada derivados en la tarea

1.1.2; 1.1.3.2 Derivar un modelo funciones/comportamientos; 1.1.3.3 RTF: Revisar funciones/comportamientos con el cliente y modificar conforme se requiera: fintarea Tarea 1.1.3 1.1.4 Aislar aquellos elementos de la tecnología que s e implementará en el software; 1.1.5 Disponibilidad de investigación del software existente; 1.1.6 Definir factibilidad técnica: 1.1.7 Realizar estimación rápida del tamaño; 1.1.8 Crear una Definición del ámbito; fintarea definición: Tarea 1.1

Las tareas y subtareas a n o t a d a s en el proceso de refinamiento del lenguaje de diseño forman la b a s e de una planeación detallada de la actividad de determinar el á m b i t o del concepto.

24.4

D E F I N I C I Ó N PE UNA REP P E TAREAS Las t a r e a s y subtareas individuales tienen interdependencias b a s a d a s en su s e c u e n -

:ÜVVE [ s tareas es un I paro ríos ¡ entre : . determinar la

cia. Además, c u a n d o m á s de u n a persona está involucrada en un proyecto de ingeniería del software, es probable que las actividades y tareas de desarrollo se realicen en

paralelo. C u a n d o e s t o ocurre, las t a r e a s concurrentes deben estar c o o r d i n a d a s

r

de m o d o que se completarán cuando las tareas posteriores requieran sus productos de TM trabajo. Una red de tareas, también d e n o m i n a d a red de actividad, es una representación gráfica del flujo de t a r e a s en un proyecto. En ocasiones se utiliza c o m o el mecanis-

PDF Editor

m o mediante el cual la secuencia y d e p e n d e n c i a s de tareas son la entrada a una he-

rramienta a u t o m a t i z a d a de calendarizac: :r. del proyecto. En su forma m á s simple

7

RTF indica que se debe realizar una r e u s í>n

; i : : ~ = I capitulo 26)

736

PARTE C U A T R O


Red d e t a r e a s p a r a desarrollo del c o n c e p t o .

1.1

Determinación ámbito concepto

1.2

Planeación concepto

1.3c Evolua< riesgo

j

1.6

1.5c Implementoción concepto

Reacción cliente

J

(empleada cuando s e crea una calendarización macroscópica), la red de tareas muestra las principales tareas de la ingeniería del software. La figura 24.2 muestra una red de tareas esquemática para un proyecto d e desarrollo del concepto. La naturaleza concurrente de las actividades de ingeniería del software conduce a varios requisitos importantes de la calendarización. Puesto q u e las tareas paralelas ocurren de manera asincrona, el planificador debe determinar dependencias ir.tertareas para asegurar el progreso continuo hacia la finalización. Además, el gestor del proyecto debe estar atento a estas tareas que se encuentran en la ruta crítica. Esto es, las tareas q u e se deben completar en la calendarización si el proyecto como un todo se debe completar a tiempo. Más adelante en este capítulo se tratan con más detalle estos temas. Es importante notar q u e la red de tareas mostrada en la figura 24.2 e s macroscópica. En una red de tareas detallada (un precursor de una calendarización detallada) cada actividad que muestra la figura se debe expandir. Por ejemplo, la tarea 1.1 se expandiría para mostrar todas las tareas detalladas en el refinamiento de las tareas 1.1. mostradas en la sección 24.3.2. 24.5

CALENDARIZACIÓN

TM

La calendarización de un proyecto de software no difiere e n o r m e m e n t e de la de cualquier esfuerzo de ingeniería multitarea. En consecuencia, las técnicas y herra-

PDF Editor

mientas generalizadas de calendarización de proyecto s e pueden aplicar, poco modificadas, en proyectos de software. La técnica de evaluación y revisión de programa (PERT, por sus siglas en inglés) y el

método de ruta crítica (CPM, por sus siglas en inglés) son dos métodos de calendarización de proyecto que se pueden aplicar al desarrollo de software. Ambas técnicas

CAPÍTULO 24

737


reciben impulso de la información ya desarrollada en actividades t e m p r a n a s de la planeación del proyecto: • Estimación del esfuerzo. • Descomposición de la función del producto. • Selección del modelo de p r o c e s o y c o n j u n t o de t a r e a s apropiados. • Descomposición de tareas. Las interdependencias e n t r e las t a r e a s se p u e d e n definir e m p l e a n d o u n a red de tareas. Las tareas, e n ocasiones llamadas la estructura de análisis del trabajo (EAT, por s u s siglas en inglés), se definen para el producto c o m o un todo o para funciones individuales. "Todo lo q u e t e n e m o s q u e decidir es q u é h a c e r con el t i e m p o q u e nos h o n d a d o . " Gandalf en El señor de los anillos: la hermandad del anillo

—

•

Tanto PERT c o m o CPM ofrecen h e r r a m i e n t a s cuantitativas que permiten al planificador de s o f t w a r e 1) determinar la trayectoria critica: la cadena de tareas que determinan la duración del proyecto; 2) establecer las estimaciones de tiempo "más probables" para tareas individuales al aplicar modelos estadísticos; y 3) calcular los "tiempos límite" que definen u n a "ventana" de tiempo para una tarea particular.


OHM Calendarización de proyectos O b j e t i v o : El objetivo de las herramientas de calendarización de proyectos es permitir que un gestor defina las tareas de trabajo, establezca sus dependencias, asigne recursos humanos a las tareas y desarrolle una variedad de gráficas, diagramas y tablas que auxilian en el seguimiento y el control del proyecto de software. Mecánica: En general, las herramientas de calendarización de proyectos requieren la especificación de una estructura d e análisis de trabajo o la generación de una red be tareas. Una vez que se define el análisis de la tarea (un bosquejo) o red, a cada tarea se ligan fechas de inicio y fin, •ecursos humanos, fechas límite duras y otros datos. Entonces la herramienta genera una variedad de cronogramas y otras tablas que le permiten a un gestor valorar el flujo de «oreas de un proyecto. Dichos datos pueden actualizarse de -lanera continua conforme el proyecto se lleva a cabo.

Herramientas representativas8 AMS Realtime, desarrollada por Advanced Management Systems (www.amsusa.com), ofrece capacidades de calendarización para proyectos d e todos los tamaños y tipos. Microsoft Project, desarrollada por Microsoft (www.microsoft.com), es la herramienta d e calendarización de proyectos basada en PC más ampliamente usada. Viewpoint, desarrollada por Artemis Internation Solutions Corp. (www.atemispm.com), soporta todos los aspectos de la planificación del proyecto, incluso la calendarización.

TM

Una lista detallada de empresas y productos de software de gestión de proyectos se puede encontrar en www.infogool .cam/pmc/pmcswr.htm.

PDF Editor V

8

Las herramientas expuestas representan una rr ¡¿esra 2e esta categoría En casi todos los casos los nombres de las mismas son marcas registrada? cié -espectivos desarrolladores.

738

PAETE CUATRO


24.5.1 Cronogramas C u a n d o s e crea u n a calendarización de proyecto del software, el planificador mienza con un conjunto de tareas (la estructura de análisis del trabajo). Si se plean h e r r a m i e n t a s a u t o m a t i z a d a s , el análisis del trabajo se introduce c o m o una i de t a r e a s o e s b o z o de tareas. Entonces se introduce el esfuerzo, la duración y 1 cha de inicio de cada tarea. Además, las tareas se pueden asignar a individuos t cíficos.

\

C o m o consecuencia de esta entrada, se genera u n cronograma,

también llama

gráfico Gantl. Es posible desarrollar un c r o n o g r a m a para todo el proyecto. De ma

CLÁVE

Un cronogromo permite determinar qué toreos se realizarán en un punto dado en el tiempo.

ra alternativa, se pueden desarrollar c r o n o g r a m a s s e p a r a d o s para cada función i proyecto o para cada individuo que trabaje en él. La figura 24.3 ilustra el formato de un c r o n o g r a m a . Muestra u n a parte de la lendarización de un proyecto de s o f t w a r e que resalta la tarea de determinación i ámbito del concepto para un producto de software procesador de palabra (PP). das las tareas del proyecto (para la determinación del ámbito del concepto) se citan; la columna de la izquierda. Las barras horizontales indican la duración de cada Ejemplo d e cronograma

Semana 1 1.1.1

I d e n t i f i c a r n e c e s i d a d e s y r e s t r i c c i o n e s del p r o y e c t o Establecer e n u n c i a d o del producto I 1 2

1.1.3

1.1.4 1.1.5

1.1 ó

Semana 2

Semana 3

Semana 4

Identificar n e c e s i d a d e s y b e n e f i c i o s Reunirse c o n clientes

T

=

Hito e n u n c í o d o d e l p r o d u c t o d e f i n i d o Definir s a l i d a s / c o n t r o l / e n t r a d o s | S C E | d e s e a d a s A l c a n c e d e las f u n c i o n e s del t e c l a d o A l c a n c e d e las f u n c i o n e s d e e n t r a d a d e voz A l c a n c e d e l o s m o d o s d e íntera c c i ó n Alcance del diagnóstico d e documentos A l c a n c e d e o t r a s f u n c i o n e s del PP SCE del d o c u m e n t o RTF R e v i s i ó n d e S C E c o n el c l i e n t e M o d i f i c a r SCE c o n f o r m e se r e q u i e r a Hifo: SCG d e f i n i d a * Definir la f u n c i ó n / c o m p o r t a m i e n t o Definir f u n c i o n e s d e t e c l a d o Definir f u n c i o n e s d e e n t r a d a d e v o z Describir m o d o s d e interacción Describir verificación o r t o g r á f i c a / g r a m a t i c a l D e s c r i b i r o t r a s f u n c i o n e s d e l PP RTF R e v i s a r d e f i n i c i ó n S C E c o n eJ d i e n t e Modificar conforme se requiera Hito: d e f i n i c i ó n c o m p l e t a d e S C E Aislamiento d e elementos d e software Hito e l e m e n t o s d e s o f t w a r e d e f i n i d o s Investigar disponibilidad d e software existente I n v e s t i g a r c o m p o n e n t e s d e e d i c i ó n d e texto Investigar c o m p o n e n t e s d e e n t r a d a d e v o z Investigar c o m p o n e n t e s d e administración d e archivos Invesiigor c o m p o n e n t e s d e verificación o r t o g r á f i c a / gramatical Hito: i d e n t i f i c a r c o m p o n e n t e s r e u t i l i z a b l e s Definir f a c t í b i l i d a d t é c n i c a Evaluar e n t r a d a d e v o z Evaluar verificación gramatical Hito: f o c t i b i l i d a d t é c n i c a v a l o r a d a Estimación r á p i d a d e t a m a ñ o Crear una definición d e ámbito Revisar d o c u m e n t o d e á m b i t o c o n el c l i e n t e M o d i f i c a r el d o c u m e n t o c o n f o r m e se r e q u i e r a Hito: d o c u m e n t o d e á m b i t o c o m p l e t o

TM

PDF Editor 1.1.7 1.18

Semana 5

CAPÍTULO 24

739

CALENDARIZACIÓN DE PROYE CTC6 DE SOFTWARE

rea. C u a n d o en el calendario s e p r e s e n t a n al m i s m o tiempo múltiples barras, se implica la concurrencia de la tarea. Los d i a m a n t e s indican hitos. Una vez ingresada la información necesaria para generar el cronograma, la m a yoría de las h e r r a m i e n t a s de calendarización de proyectos de software producen tablas de proyecto: u n a lista tabular de todas las tareas del proyecto, sus fechas de inicio y conclusión, p l a n e a d a s y reales, y u n a variedad de información relacionada (figura 24.4). Si se utilizan en conjunto con el cronograma, las tablas de proyecto permiten que el gestor del proyecto dé seguimiento al progreso.

24.5.2 Seguimiento de la calendarización La calendarización del proyecto proporciona un m a p a de carreteras al gestor del proyecto d e software. Si se h a desarrollado de m a n e r a a d e c u a d a , la calendarización del proyecto define las t a r e a s e hitos que se deben seguir y controlar c o n f o r m e a v a n ce el proyecto. El seguimiento se p u e d e hacer de diferentes maneras: • Con la realización periódica de reuniones para valorar el e s t a d o del proyecto en las cuales cada u n o d e los miembros del equipo informa del progreso y los problemas. • Con la evaluación de los resultados de todas las revisiones realizadas a lo largo del proceso de ingeniería del software. • Con la determinación de si s e h a n logrado los hitos formales del proyecto e n la fecha p r o g r a m a d a (los d i a m a n t e s que se muestran en la figura 24.3). • Al comparar la fecha de inicio real con la fecha de inicio prevista para cada tarea del proyecto m e n c i o n a d a en la tabla de recursos (figura 24.4).

Ejemplo de tabla de recursos. Inicio previsto

Inicio real

R e u n i r s e c o n los c l i e n t e s

s e m 1, d i

sem í, di

sem I, d 2

s e m 1, d 2

identificar n e c e s i d a d e s y restricciones del proyecto

sem

1, d 2

sem I, d 2

sem I, d 2

sem

1, d 2

Esíablecer e n u n c i a d o del producto

sem

1, d 3

sem I, d3

sem

sem

1, d 3

Hito: e n u n c i a d o del p r o d u c t o d e f i n i d o

s e m 1, d 3

sem 1; d 3

s e m 1, d 3

Alcance d e las funciones del t e c l a d o

sem

I, d4

sem

1, d 4

sem. 2 , d 2

m

Alcance d e las funciones d e e n t r a d a d e voz

s e m I, d 3

sem

1, d 3

A l c a n c e d e lo» m o d o s d e i n t e r a c c i ó n

sém 2, di

sem 2 , d 3

MIL

Alcance del diagnóstico d e documentos

s e m 2, d i

sem 2, d 2

Alcance d e otras funciones del PP

sem

Tareas de t r a b a j o

Terminación Terminación P e r s o n a s Esfuerzo prevista real asignadas asignado

<)ent¡}¡ear n e c e s i d a d e s y b e n e f i c i o s

I, d 3

Definir s a l i d a s / c o n t r o l / e n t r a d a s |SCE) d e s e a d a s

Documento SCE

f-•!

y

I, d 4

s e m 1, d 4

sem:2,<Í2 s e m 2, d 3

s e m 2, d i

s e m 2, d 3

JPP

2p-d V;P"d

s e m 1, d 3 1.5 p d 2 p d 1 p
TM

1.5 p d

Mli

2Pd 3 pd

RTF: r e v i s i ó n d e S C E c o n e l c l i e n t e

sem 2. d 3

s e m 2. d 3

3 pd

Modificar SCE conforme se requiera

sem 2, d 4

s e m 2. d 4

3 pd

Hito: S C E d e f i n i d a s

sem 2, d 5

sem 2 , d 5

PDF Editor Definir la f u n c i ó n / c o m p o r t a m i e n t o

740

PARTE CUATRO


• Al reunirse de m a n e r a informal con los trabajadores para obtener su evaluación subjetiva del progreso hasta la fecha y los problemas que se vislumbran • Con el uso del análisis del valor obtenido (sección 24.6) para evaluar el progreso cuantitativamente. En realidad, todas e s t a s técnicas de seguimiento las utilizan los gestores de proye; to experimentados.

"La reglo básico del reporte del estado del software se puede resumir en una sola frase: no hay sorpresas." Capers Jones

ÔNSiiO^ El mejor indicador de piogieso es la terminación y revisión exitosa de un producto de trabajo de software definido.

El control lo emplea el gestor del proyecto para administrar los recursos del p r c - B yecto, lidiar con los problemas y dirigir al personal del proyecto. Si las c o s a s van bien I (es decir, el proyecto está dentro del calendario y del presupuesto, las revisiones r - I dican que se está realizando un progreso real y que los hitos se han alcanzado! d I control es ligero. Pero c u a n d o ocurren problemas, el gestor del proyecto d e b e ejer- I cer control para solucionarlos tan p r o n t o c o m o s e a posible. Cuando se haya diag- I nosticado el problema se destinan recursos adicionales al área correspondiente r e .

I

bicando personal o redefiniendo la calendarización. Cuando e n f r e n t a n severas presiones por la fecha límite, los gestores de p r o y e c a experimentados en ocasiones e m p l e a n una calendarización de proyecto y técnica c¡t\ control llamada time-boxing

(encajonamiento de tiempo) [ZAH95]. Esta estrategia re - I

c o n o c e que el producto completo n o podrá entregarse en la fecha límite p r o g r a ~ ; • I da. Por lo tanto, se elige un paradigma de software incremental (capítulo 3) y se eia- I bora una calendarización para c a d a entrega incremental. Entonces se e n c a j o n a n en el tiempo las t a r e a s asociadas con cada incre Esto significa que la calendarización para cada tarea se ajusta al trabajar haci d e s d e la fecha de e n t r e g a para c a d a incremento. Se coloca u n a "caja" alrededor ae cada tarea. Cuando una tarea se acerca al límite de su caja de tiempo (más o m e - s 10 por ciento), el trabajo se detiene y c o m i e n z a la siguiente tarea. La reacción inicial al enfoque del e n c a j o n a m i e n t o de tiempo u s u a l m e n t e es ne : ; tiva: si el trabajo se termina, ¿cómo se procederá? La respuesta se encuentra e r la forma en se realiza el trabajo. Cuando se llegue al límite de la caja de tiempo, es pro-j bable que se haya completado 9 90 p o r ciento de la tarea. El restante 10 por cier :iJ TM a u n q u e importante, p u e d e 1) d e m o r a r s e hasta el siguiente in c r e m e n to o 2) comp citarse m á s tarde si se requiere. Más que quedarse " e m p a n t a n a d o " e n la tarea, el pror yecto a v a n z a hacia la fecha de entrega.

PDF Editor

9 Un cínico puede recordar el dicho: el 90 por ciento del sistema toma 10 por ciento del tiempo; e¡ tante 10 por ciento del sistema toma 90 por ciento del tiempo.

CAPÍTULO 24

CALENDARIZACIÓN DE PROYECTOS

741

DE SOFTWARE

24.5.3 Seguimiento del progieso en un proyecto OO Aunque un modelo iterativo es el mejor m a r c o de trabajo para un proyecto OO, el paralelismo de las t a r e a s dificulta el seguimiento del proyecto. El gestor del proyecto p u e d e tener dificultades al establecer hitos significativos para un proyecto OO d e bido a varias c o s a s diferentes que ocurren a la vez. En general, los siguientes hitos principales se p u e d e n considerar "completados" c u a n d o se a l c a n z a n los criterios anotados. Hitos técnicos:

análisis

OO completado

• Se h a n definido y revisado todas las clases y la jerarquía de clase. • Se h a n definido y revisado los atributos de clase y las o p e r a c i o n e s asociadas con u n a clase. • Se han establecido y revisado las relaciones de clase (capítulo 8). • Se ha c r e a d o y revisado un modelo de c o m p o r t a m i e n t o (capítulo 8). • Se h a n a n o t a d o las clases reutilizables. \

Hitos técnicos:

diseño

OO completado

• Se ha definido y revisado el conjunto de subsistemas (capítulo 9). • Las clases se h a n revisado y asignado a los subsistemas. • Se h a establecido y revisado la asignación de tareas. • Se han identificado las responsabilidades y colaboraciones (capítulos 8 y 9). • Se ha c r e a d o y revisado el diseño de las clases. • Se h a c r e a d o y revisado el m o d e l o de comunicación. Hitos técnicos:

programación

OO completada

• Cada nueva clase se ha i m p l e m e n t a d o en código a partir del modelo de diseño. • Se h a n i m p l e m e n t a d o las clases obtenidas (de una librería de reutilización). • Se h a construido el prototipo o incremento. Hitos técnicos: ^CONSCIQ^ Lo depuración y yueba son simultó«os. Con frecuencia, ti estodo de lo depu-xión se evalúo al considerar el tipo y número de errores ibugs) "abiertos".

prueba

OO

• Se han revisado la corrección y que estén completos el análisis OO y los modelos de diseño. • Se ha desarrollado y revisado u n a red clase-responsabilidad-colaboración (caTM pítulo 8). • Se h a n diseñado c a s o s de prueba y se h a n llevado a c a b o pruebas al nivel de

PDF Editor clase (capítulo 14) para cada clase.

• Se han d i s e ñ a d o c a s o s de prueba, se h a n completado p r u e b a s de agrupamientos (capítulo 14) y se h a n integrado las clases.

• Se han completado las p r u e b a s al nivel de sistema.

742

PAUTE CUATRO


R e c u é r d e s e q u e el m o d e l o d e p r o c e s o OO e s iterativo, c a d a u n o d e e s t o s hitos p u r l d e r e v i s a r s e c o n f o r m e d i f e r e n t e s i n c r e m e n t o s s e e n t r e g u e n al cliente.

Seguimiento

El e s c e n a r i o : Oficina d e Doug Miller, ontes del inicio del proyecto de software HogarSe-

gwa-

''

¡,¡ i f e '

'

<"

Los a c t o r e s : Doug Miller ¡gerente del equipo de ingeniería del software de HogarSeguro) y Vinod Raman, JamieLazar y otros miembros del equipo de ingeniería del software del producto.

La conversación: Doug {mira una diapositiva PowerPoint): La calendarización para el primer incremento de HogarSeguro parece razonable, pero tendremos problemas para darle seguimiento al progreso.

Vinod {su rostro s e nota preocupado): ¿Por qué? Hemos calendarizado las tareas en una base diaria, llena de productos d e trabajo, y nos hemos asegurado que nos estamos asignando recursos de mós. D o u g : Todo está bien, ¿pero cómo sabemos cuándo está completo el modelo de análisis para el primer incre-

2 4 . 6

% C L Á V E El valor ganado ofrece un indicio cuantitativo del progreso.

1

de la calendarización J a m i e : Las cosas son iterativas, por eso es difícil. :

D o u g : Entiendo eso, pero... bueno, por ejemplo, tomemos análisis de clases definido. Tú indicaste esto como u hito.

Vinod: Así es.

!H

D o u g : ¿Quién hizo esa determinación? J a m i e (irritada): Están hechas cuando están hechos D o u g : Eso no es suficientemente bueno, Jamie. Tenemos que calendarízar RTF [revisiones técnicas formales, capitulo 26] y no lo han hecho. La conclusión exitosa de una revisión en el modelo de análisis, por ejemplo, es un hito razonable. ¿Entendido? J a m i e ( m a l h u m o r a d a ) : Está bien, de vuelta o la mesa d e dibujo. D o u g : No les debe tomar mós de una hora hacer las correcciones. . todos los demás pueden comenzar añore

A M Á L Í S I S DEL V A L O R G A M A D O En la s e c c i ó n 2 4 . 5 s e t r a t a r o n a l g u n o s e n f o q u e s c u a l i t a t i v o s e n c u a n t o al s e g u i m i e n to del p r o y e c t o . C a d a u n o o f r e c e al g e s t o r del p r o y e c t o u n indicio del p r o g r e s o , perru n a e v a l u a c i ó n d e la i n f o r m a c i ó n p r o p o r c i o n a d a e s un p o c o s u b j e t i v a . E s r a z o n a b . e p r e g u n t a r si existe u n a t é c n i c a c u a n t i t a t i v a p a r a e v a l u a r el p r o g r e s o c o n f o r m e el e q u i p o d e s o f t w a r e a v a n z a a t r a v é s d e las t a r e a s d e t r a b a j o a s i g n a d a s e n la c a l e n d a r i z a c i ó n del p r o y e c t o . De h e c h o , e x i s t e u n a t é c n i c a p a r a r e a l i z a r a n á l i s i s c u a n t i t a tivos del p r o g r e s o . Se l l a m a análisis

del valor ganado

(AVG). H u m p h r e y [HUM95"

c o m e n t a el valor g a n a d o e n la f o r m a siguiente:

TM

El sistema de valor ganado proporciona una escala de valor común para cualquier tarea [de proyecto de software], sin importar el tipo de trabajo que se realiza. Se estiman las horas totales para realizar todo el proyecto y a cada tarea se le da un valor ganado con base en su porcentaje estimado del total.

PDF Editor

E n u n c i a d o en u n a f o r m a m á s simple, el v a l o r g a n a d o e s u n a m e d i d a del p r o g r e s o P e r m i t e v a l o r a r el " p o r c e n t a j e r e a l i z a d o " de u n p r o y e c t o r e e m p l e a n d o el análisis c u a n t i t a t i v o e n l u g a r d e a p o y a r s e e n u n a o p i n i ó n p e r s o n a l . De h e c h o , Fleming y Kop-

CAPÍTULO 24

743


pleman [FLE98] a r g u m e n t a n que el análisis del valor g a n a d o "ofrece lecturas precisas y confiables del d e s e m p e ñ o desde u n m o m e n t o tan t e m p r a n o del proyecto com o el 15 por ciento realizado." Para determinar el valor g a n a d o se realizan los siguientes pasos: ¿Cómo se

1. Se determina el costo presupuestado

para el trabajo calendarizado

(CPTC) res-

pecto de cada tarea de trabajo representada en la calendarización. Durante la estimación se planifica el trabajo (en personas-hora o personas-día) de cada

calcula el ganado y i te utiliza

tarea de ingenieria. Por lo tanto, CPTC, e s el e s f u e r z o palnificado para la tarea

i evaluar el

de trabajo i. Para determinar el progreso en un p u n t o d a d o e n la calendariza-

o?

ción del proyecto, el valor de CPTC es la s u m a de los valores CPTC, para todas la tareas de trabajo que deben estar c o m p l e t a d a s e n dicho p u n t o e n el tiempo en la calendarización del producto. 2.

Los valores CPTC para t o d a s las t a r e a s de trabajo se resumen para obtener el presupuesto

a la terminación,

PAT. Por lo tanto,

PAT = I (PTCO para todas las t a r e a s k. 3.

A continuación se calcula el costo presupuestado

del trabajo realizado (CPTR).

El valor d e CPTR es la s u m a de los valores CPTC para t o d a s las tareas de trab a j o que en realidad se h a n completado e n un p u n t o en el tiempo e n la calendarización del proyecto. Wilkens [WIL99] señala que "la distinción e n t r e CPTC y CPTR e s que la primera representa el p r e s u p u e s t o de las actividades que s e planearon completar, y la última, el p r e s u p u e s t o de las actividades que en realidad se c o m p l e t a r o n " . Dados los valores de CPTC, PAT y CPTR, se pueden calcular importantes indicadores del progreso: índice de d e s e m p e ñ o en la calendarización, IDCa = CPTR/CPTC Varianza en la calendarización, VC = CPTR - CPTC IDCa es un indicador de la eficiencia con la que el proyecto utiliza los recursos cai vtiriedod de s ocefco del |BM)» •crsoien ».a
ri/p»/.

lendarizados. Un valor IDCa c e r c a n o a 1.0 indica una ejecución eficiente del proyecto calendarizado. VC simplemente es un indicador absoluto de la variación a partir d e la calendarización planeada. Porcentaje calendarizado para terminación = CPTC/PAT ofrece un indicador del porcentaje de trabajo que debe estar completado en el tiempo t. Porcentaje de completado = CPTR/PAT

TM

ofrece u n a indicación cuantitativa del porcentaje de a v a n c e del proyecto en un pun-

PDF Editor to d a d o en el tiempo, t.

También e s posible calcular el costo real del trabajo realizado, CRTR. El valor para

CRTR e s la s u m a del e s f u e r z o realmente utilizado en las tareas de trabajo que se h a n completado en un p u n t o en el tiempo en ia calendarización del proyecto. Entonces es posible calcular

744

PARTE CUATRO


índice d e d e s e m p e ñ o del c o s t o , IDCo = CPTR/CRTR V a r i a n z a del c o s t o , VC = CPTR - CRTR Un valor d e IDCo c e r c a n o a 1.0 o f r e c e u n f u e r t e i n d i c a d o r d e q u e el p r o y e c t o esta d e n t r o d e s u p r e s u p u e s t o definido, VC e s u n i n d i c a d o r a b s o l u t o del a h o r r o e n c o s t i (contra l o s c o s t o s p l a n e a d o s ) o r e c o r t e s e n u n a e t a p a p a r t i c u l a r d e un p r o y e c t o . Al igual q u e un r a d a r e n el h o r i z o n t e , el a n á l i s i s del v a l o r g a n a d o ilumina las c:ficultades

e n la c a l e n d a r i z a c i ó n a n t e s de q u e p u e d a n a d v e r t i r s e d e a l g u n a o t r a for-

m a . E s t o p e r m i t e q u e el g e s t o r del p r o y e c t o d e s o f t w a r e t o m e m e d i d a s c o r r e c t i v a s a n t e s d e q u e s e d e s a r r o l l e u n a crisis e n el p r o y e c t o .

La c a l e n d a r i z a c i ó n e s la c u l m i n a c i ó n d e u n a actividad d e planificación q u e e s un c o m p o n e n t e p r i n c i p a l d e la g e s t i ó n del p r o y e c t o d e s o f t w a r e . C u a n d o s e c o m b i r i c o n m é t o d o s de e s t i m a c i ó n y análisis d e riesgo, la c a l e n d a r i z a c i ó n e s t a b l e c e u n m a p a d e c a r r e t e r a s p a r a el g e s t o r d e p r o y e c t o s . La c a l e n d a r i z a c i ó n c o m i e n z a c o n el p r o c e s o d e d e s c o m p o s i c i ó n . Las c a r a c t e r i s t c a s del p r o y e c t o s e utilizan p a r a a d a p t a r u n c o n j u n t o d e t a r e a s a p r o p i a d o al t r a b a : q u e s e r e a l i z a r á . U n a red d e t a r e a s b o s q u e j a c a d a t a r e a d e i n g e n i e r í a , s u d e p e n d e r cia d e o t r a s t a r e a s y s u d u r a c i ó n p r o y e c t a d a . La red d e t a r e a s s e utiliza p a r a calcular la trayectoria crítica, u n c r o n o g r a m a y u n a v a r i e d a d d e i n f o r m a c i ó n del proyect : Al u s a r la c a l e n d a r i z a c i ó n c o m o guía, el g e s t o r del p r o y e c t o p u e d e d a r s e g u i m i e n : c y c o n t r o l a r c a d a p a s o e n el p r o c e s o del s o f t w a r e .

[BR095] Brooks, M., The Mythical Man -Month, edición de aniversario, Addison-Wesley, 1995 [FLE98] Fleming, Q. W., y J. M. Koppelman, "Earned Valué Project Management", Crosstalk, ve. 11, núm. 7, julio de 1998, p. 19. [HUM95] Humphrey, W., A Discipline for Software Engineering, Addison-Wesley, 1995. [NOR70] Norden, P., "Useful Tools for Project Management", en Management ofProduction, M. Starr (ed.), Penguin Books, 1970. [PAG85] Page-Jones, M., Practícal Project Management, Dorset House, 1985, pp. 90-91. [PRE99] Pressman, R. S., Adaptable Process Model, R. S. Pressman & Associates, 1999. [PUT78] Putnam, L., y W. Myers, Measures for Excellence, Yourdon Press, 1992. [W1L99] Wilkens, T. T., "Earned Valué, Clear and Simple", Primavera Systems, 1 de abril de 1999, p. 2 [ZAH95] Zahniser, R., "Time-boxing for Top Team Performance", en Software Development, mar z o de 1995, pp. 34-38. TM PROBLEMAS V PUNTOS A CONSIDERAR

PDF Editor

2 4 . 1 . Las fechas límite "irracionales" son un hecho de la vida en el negocio del software. ¿Cerno se debe proceder si se enfrenta con una? 2 4 . 2 . ¿Cuál es la diferencia entre una calendarización macroscópica y una calendarización detallada? ¿Es posible gestionar un proyecto si sólo se desarrolla una calendarización macroscópica? ¿Por qué?

CAPITULO 24


745

2 4 . 3 . ¿Existe algún caso donde un hito de un proyecto de software no esté ligado a una revisión? Si es así, ofrecer uno o más ejemplos. 2 4 . 4 . La "sobrecarga de comunicación" puede ocurrir cuando muchas personas trabajan en un proyecto de software. El tiempo empleado en la comunicación con otros reduce la productividad individual (LDC/persona-mes) y el resultado es menor productividad para el equipo. Ilustrar (cuantitativamente) cómo los ingenieros versados en las buenas prácticas de ingeniería del software y que usan revisiones técnicas formales pueden aumentar la tasa de producción de un equipo (cuando se compara con la suma de las tasas de producción individuales). Sugerencia: se puede suponer que las revisiones reducen la reelaboración y que ésta puede explicar el 2040 por ciento del tiempo de una persona. 2 4 . 5 . Aunque agregar personal a un proyecto de software retrasado puede retrasarlo más, existen circunstancias en las cuales esto no es cierto. Descríbanse. 2 4 . 6 . La relación entre personal y tiempo es enormemente no lineal. Mediante la ecuación del software de Putnam (descrita en la sección 24.2.2), desarrollar una tabla que relacione el número de personas con la duración del proyecto para un proyecto de software que requiera 50 000 LDC y 15 personas-año de esfuerzo (el parámetro de productividad es 5 000). Supóngase que el software debe entregarse en un máximo de 24 meses o en un mínimo de 12. 2 4 . 7 . Suponga que una universidad lo ha contratado para desarrollar un sistema de registro en línea a cursos (SRELC). Primero, actúe como el cliente (si es estudiante, ¡esto debe ser sencillo!) y especifique las características de un buen sistema. (Alternativamente, su instructor le proporcionará un conjunto de requisitos preliminares para el sistema.) Por medio de los métodos de estimación tratados en el capítulo 23, desarrolle una estimación del esfuerzo y la duración para el SRELC. Sugiera cómo: a) Definiría las actividades de trabajo paralelas durante el proyecto de SRELC. b) Distribuiría el esfuerzo a lo largo del proyecto. c) Establecería hitos para el proyecto. 2 4 . 8 . Seleccione un conjunto de tareas apropiado para el proyecto del SRELC. 2 4 . 9 . Defina una red de tareas para el SRELC o, alternativamente, para otro proyecto de software que le interese. Asegúrese de mostrar las tareas e hitos y de vincular las estimaciones de esfuerzo y duración a cada tarea. Si es posible, utilice una herramienta automatizada de calendarización para realizar este trabajo. 2 4 . 1 0 . Si está disponible una herramienta automatizada de calendarización, determine la trayectoria crítica para la red definida en el problema 24.9. Mediante una herramienta de calendarización (si está disponible) o papel y lápiz (si es necesario), desarrolle un cronograma para el proyecto del SRELC.

24.11.

Suponga que es gestor de proyectos de software y que se le ha pedido TM calcular las estadísticas del valor ganado de un pequeño proyecto El proyecto tiene planeadas 56 tareas de trabajo que se estima requerirán 582 personas-día para completarse. En el momento en que se le pide realizar el análisis del valor ganado. 12 tareas se han completado. Sin embargo, la calendarización del proyecto indica que se tenían que haber completado 15. Están disponibles los siguientes datos de la calendarización (en personas-día): 24.12.

PDF Editor Tarea

1

Esfuerzo previsto

E s t e r » red

12.0

12.5

746

PARTE CUATRO Toreo


Esfuerzo previsto

Esfuerzo real

2

15.0

11.0

3

13.0

17.0

4

8.0

9.5

5

9.5

9.0

6

18.0

19.0

7

10.0

10.0

8

4.0

4.5

9

12.0

10.0

10

6.0

6.5

11

14.0

4.0

12

14.0

14.5

13

16.0

—

14

6.0

—

15

8.0

—

Calcule el IDCa, la varianza de calendarización, el porcentaje calendarizado para terminación el porcentaje completado, IDCo y la varianza de costo para el proyecto.

Casi cualquier libro acerca de gestión de proyectos de software contiene una exposición de la calendarización. El Project Management Institute (PMBOK Guide, PM1, 2001), Wysoki y sus colegas (Effective Project Management, Wiley, 2000), Lewis (Project Planning Scheduling and Control, 3a. ed„ McGraw-Hill, 2000), Bennatan (On Time, Within Budget: Software Project Management Practices and Techniques, 3a. ed., Wiley, 2000), McConnell (Software Project Cost Survival Guide, Microsoft Press, 1998) y Roetzheim y Beasley (Software Project Cost and Schedule Estimating: Best Practices, Prentice-Hail, 1997) contienen análisis valiosos del tema. Boddie (Crunch Mode, Preniice-Hall, 1987) ha escrito un libro para todos los gestores que "tienen 90 días para hacer un proyecto de seis meses". McConnell (Rapid Development, Microsoft Press, 1996) presenta una excelente exposición de los conflictos que conducen a calendarizaciones de proyectos de software demasiado optimistas y qué puede hacer acerca de ello. O'Connell (How to Run SuccessJuI Projects II: The Silver Bullet, Prentice-Hall, 1997) presenta un enfoque paso a paso para la gestión de proyectos que le ayudará a desarrollar una calendarización realista para sus proyectos. Webb y Wake (Using Earned Valué: A Project Manager's Guide, Ashgate Publishing, 2003) y Fleming y Koppelman (Earned Valué Project Management, Project Management Institute Publications, 1996) examinan con considerable detalle el uso de las técnicas del valor ganado para planificación, seguimiento y control de proyectos. En Internet hay disponible una gran variedad de fuentes de información acerca de la calendarización de proyectos de software. Una lista actualizada de referencias de la World Wide TM Web se puede encontrar en el sitio Web de SEPA: http://www.mhhe.com/pressman.

PDF Editor

C A P I T U L O

GESTIÓN DEL R I E S G O CONCEPTOS CLAVE

alegorías :eriesgos . . . . 7 4 9 ütrategin rooctiva

748

Ktrotegia «•ctivo

748

tratación . . . . 7 5 7 exposición é riesgo

757

¡fcitificoción . .750 vincipios

750

inyección

754

-ffinomiento.. .762 KG«

761

Hgsridad i riesgos

763

«Éta «e

riesgos

755

E

n su libro acerca del análisis y la gestión del riesgo, Robert C h a r e t t e (CHA891 p r e s e n t a u n a definición c o n c e p t u a l de riesgo:

En primer lugar, el riesgo se relaciona con ios acontecimientos futuros. El hoy y el ayer están más allá de esta relación, pues ya se ha cosechado lo que previamente se sembró con nuestras acciones pasadas. La pregunta es: ¿podemos, por tanto, al cambiar nuestras acciones presentes, crear en lo futuro una oportunidad para una situación diferente, y esperanzadoramente mejor, para nosotros mismos? Esto significa, en segundo lugar, que el riesgo implica cambio, como cambios de mentalidad, opinión, acciones o lugares... [en tercer lugar] el riesgo implica elección y la incertidunv bre que ésta conlleva. Por ende, paradójicamente, el riesgo, al igual que la muerte y los impuestos, es una de las pocas certezas en la vida.

C u a n d o el riesgo s e c o n s i d e r a e n el c o n t e x t o d e la ingeniería del s o f t w a r e , las tres b a s e s c o n c e p t u a l e s de C h a r e t t e s i e m p r e se evidencian. El f u t u r o e s u n a p r e o c u p a c i ó n d e primer o r d e n : ¿qué riesgos c a u s a r í a n q u e el p r o y e c t o de softw a r e salga mal? El c a m b i o e s u n a p r e o c u p a c i ó n central: ¿ c ó m o a f e c t a r á n la actualidad y el éxito global los c a m b i o s e n los requisitos del cliente, las t e c n o l o g í a s de desarrollo, los e n t o r n o s q u e s e t i e n e n c o m o objetivo y t o d a s las o t r a s e n tidades vinculadas con el proyecto? Por último, e s necesario enfrentar las opciones: ¿ q u é m é t o d o s y h e r r a m i e n t a s s e d e b e n usar, c u á n t a s p e r s o n a s d e b e n e s t a r inv o l u c r a d a s , c u á n t o é n f a s i s s o b r e la calidad e s "suficiente"? Peter Drucker [DRU75] dijo u n a vez: "Aunque e s v a n o i n t e n t a r eliminar el riesgo, y c u e s t i o n a b l e i n t e n t a r minimizarlo, e s esencial q u e los riesgos t o m a d o s s e a n los riesgos correctos". A n t e s d e identificar los "riesgos correctos" q u e s e tom a r á n d u r a n t e u n p r o y e c t o d e s o f t w a r e , e s i m p o r t a n t e identificar los riesgos q u e s o n o b v i o s p a r a los g e s t o r e s y p r o f e s i o n a l e s .

¿ Q u é e s ? El a n á l i s i s y la g e s t i ó n del riesgo son una serie d e p a s o s q u e

c e r un p l a n d e c o n t i n g e n c i a e n c a s o d e q u e el p r o b l e m a se p r e s e n t e .

a y u d a n a un e q u i p o d e s o f t w a r e o c o m p r e n d e r y m a n e j a r la i n c e r t i d u m -

¿ Q u i é n l o h a c e ? Todos los involucrados en el TM

b r e . M u c h o s p r o b l e m a s p u e d e n desb o r d a r u n p r o y e c t o d e s o f t w a r e . Un r i e s g o e s un

t i c i p a n t e s ) i n t e r v i e n e n e n el a n á l i s i s y la g e s t i ó n

p r o b l e m a p o t e n c i a l : p u e d e o c u r r i r o no. Pero,

¿ P o r q u é e s i m p o r t a n t e ? Piénsese en el lema

p r o c e s o d e software (gestores, ingenieros y p a r -

del riesgo.

PDF Editor sin i m p o r t a r el r e s u l t a d o , en r e a l i d a d e s J - C

d e los b o y scout: " e s t a r p r e p a r a d o " . El s o f t w a r e

b u e n a i d e a identificarlo, e v a l u a r la p r o b a b i l i -

e s u n a e m p r e s a difícil. M u c h a s c o s a s p u e d e n s a -

d a d d e q u e o c u r r a , e s t i m a r su i m p a c t o y e s t a b l e -

lir rrio : y. R o n c a m e n t e , c o n m u c h a f r e c u e n c i a lo

747

PARTE CUATRO

748


h a c e n . Por esta r a z ó n estar p r e p a r a d o s (al comp r e n d e r los riesgos y tomar m e d i d a s proactivas p a r a evitarlos o gestionarlos) es un elemento clave d e una b u e n a gestión d e proyecto d e software.

¿ C u á l e s s o n l o s p a s o s ? Reconocer qué puede salir mal es el primer p a s o , l l a m a d o "identificación del riesgo". A continuación $e a n a l i z a c a d a riesgo p a r a determinar la p r o b a b i l i d a d d e q u e ocurrirá y el d a ñ o q u e c a u s a r á si en efecto ocurre. Una vez establecido esta información, los riesgos se clasifican según su p r o b a b i l i d a d e impacto. Finalmente, se desarrolla un p l a n p a r a gestionar aquellos riesgos con g r a n probabilid a d y alto impacto.

25.1

¿Cuál e s el p r o d u c t o o b t e n i d o ? Se produce un p l a n d e reducción, supervisión y gestión del riesgo (RSGR) o un conjunto d e h o j a s informativ a s d e riesgo.

¿Cómo puedo estar seguro de que lo he h e c h o c o r r e c t a m e n t e ? Los riesgos que se a n a l i z a n y gestionan d e b e n p r o c e d e r d e un estudio a m p l i o del personal, el producto, el proces o y el proyecto. El p l a n RSGR d e b e revisarse c o n f o r m e el proyecto a v a n z a p a r a a s e g u r a r s e d e q u e los riesgos están actualizados. Los planes d e contingencia p a r a la gestión del riesgo d e b e n , ser realistas.

ESTRATEGIAS PE RIESGO REACTIYAS Y PRPACTIYAS Las estrategias de riesgo reactivas h a n sido j o c o s a m e n t e d e n o m i n a d a s la "escuela Indiana Jones de gestión del riesgo" [TH092]. En las películas de la década de 1980 que llevaban su nombre, Indiana Jones, c u a n d o e n f r e n t a b a alguna dificultad abrum a d o r a , invariablemente decía: "¡No te preocupes, p e n s a r é en algo!". Al no preocuparse n u n c a por los problemas, s i n o hasta que ocurrían, Indy reaccionaba en alguna forma heroica. "Si usted no ateta activamente los riesgos, ellos lo atacarán ortivamente." Tom Gilb

Tristemente, el gestor p r o m e d i o de proyectos de s o f t w a r e no e s Indiana Jones, . los m i e m b r o s del equipo de proyecto de s o f t w a r e n o son s u s confiables compañeros. Más aún, la mayoría de los equipos de software se apoya exclusivamente en las estrategias de riesgo reactivas. Los riesgos se a p a r t a n para tratarlos, lo que puede convertirlos e n p r o b l e m a s reales. Más usualmente, el equipo d e s o f t w a r e n o hace nada acerca de los riesgos hasta que algo sale mal. Entonces el equipo se precipita e n la acción con la finalidad de corregir el problema rápidamente. Con frecuencia a esto s e le llama el modo bombero. C u a n d o e s t o falla, la "gestión TM de crisis" [CHA92 a s u m e el control y el proyecto está en un verdadero peligro. Una estrategia considerablemente m á s inteligente para la gestión del riesgo es ser

PDF Editor

proactivo. Una estrategia proactiva c o m i e n z a m u c h o a n t e s de que se inicie el trabajo técnico. Se identifican los riesgos potenciales, s e valoran su probabilidad e impacto, y se les clasifica según su importancia. Luego, el equipo de s o f t w a r e establece ur plan para gestionar el riesgo. El objetivo principal e s evitar el riesgo, p e r o debido a que no t o d o s los riesgos pueden evitarse, el equipo trabaja para desarrollar un plan

CAPÍTULO 25

749

GESTIÓN DEL RIESGO

de contingencia que le permitirá responder en una forma controlada y efectiva. A lo largo del resto del capítulo se examina la estrategia proactiva para la gestión del riesgo.

Aunque hay un considerable d e b a t e en torno a la definición propia para el riesgo de software, existe un a c u e r d o general en que el riesgo siempre involucra dos características [HIG95] : • Incertidumbre:

el riesgo p u e d e o n o ocurrir; e s t o es, no existen riesgos 100%

probables. 1 • Pérdida: si el riesgo se convierte en realidad, ocurrirán c o n s e c u e n c i a s o pérdidas indeseables. C u a n d o se analizan los riesgos e s importante cuantificar el grado de incertidumbre y el grado de pérdida a s o c i a d o con cada riesgo. Esto se logra c o n s i d e r a n d o diferent e s categorías de riesgos. ¿Qué tipos

•

de riesgos

Los riesgos del proyecto a m e n a z a n el plan del proyecto. Es decir, si los riesgos del

«s probable

proyecto se vuelven reales e s probable que la calendarización del proyecto se altere

•contrar

y que los c o s t o s a u m e n t e n . Los riesgos del proyecto identifican potenciales proble-

« • f o r m e se oNKtruye software?

m a s en presupuesto, calendarización, personal (plantillas y organización), recursos, participantes y requisitos, y su impacto s o b r e un proyecto de software. En el capítulo 23 la complejidad, t a m a ñ o y g r a d o de incertidumbre estructural del proyecto también se definieron c o m o factores de riesgo del proyecto (y de la estimación). Los riesgos técnicos a m e n a z a n la calidad y actualidad del s o f t w a r e q u e s e producirá. Si un riesgo técnico se vuelve real, la implementación se torna difícil o imposible. Los riesgos técnicos identifican potenciales problemas en diseño, implementación, interfaz, verificación y mantenimiento. Además, también son factores de riesgo la a m b i g ü e d a d de la especificación, la incertidumbre técnica, la obsolescencia técnica y la tecnología "de punta". Los riesgos técnicos ocurren porque el problema es m á s difícil de resolver de lo que en un principio se p e n s ó que sería. Los riesgos de negocios a m e n a z a n la viabilidad del s o f t w a r e que se construirá. Estos riesgos con frecuencia ponen en peligro el proyecto o el producto. Los candidatos para los cinco mayores riesgos de negocios son 1) la construcción de un producto o sistema excelente que en realidad nadie quiere (riesgo de mercado), 2) la construcTMde la c o m p a ción de un producto que ya n o e n c a j a en la estrategia comercial global ñía (riesgo de estrategia), 3) la construcción de un producto que la fuerza de ventas no s a b e c ó m o vender (riesgo de v e n t a s

4) la pérdida del a p o y o de los altos ejecuti-

PDF Editor

vos debido a un c a m b i o en el e n f o q u e o en el personal (riesgo administrativo), y 5) la pérdida presupuestaria o del personal asignado (riesgo presupuesta!). 1 Un riesgo 100 por ciento probable es una

socre e! proyecto de software

750

PARTE CUATRO


Es e x t r e m a d a m e n t e importante destacar que la simple clasificación de los riesgos n o siempre funciona. Algunos riesgos s im p le m e n t e son impredecibles. Charette [CHA89] h a propuesto otra categorización general de los riesgos. Los riesgos conocidos son aquellos susceptibles de descubrirse d e s p u é s de u n a evaluación cuidadosa del plan del proyecto, del e n t o r n o de negocios y técnico d e n t r o de los cuales se desarrollará el proyecto, y otras fuentes de información confiables (por ejemplo, fechas de entrega irreales, falta de requisitos d o c u m e n t a d o s o de ámbitc del software, pobre e n t o r n o de desarrollo). Los riesgos predecibies

se extrapolan de

la experiencia con proyectos previos (por ejemplo, cambios en el personal, mala comunicación con el cliente, disminución del e s f u e r z o del personal c o n f o r m e se atienden las solicitudes de mantenimiento). Los riesgos impredecibles

son el comodín de

la baraja. Pueden y de hecho ocurren, p e r o son e x t r e m a d a m e n t e difíciles de identificar con antelación. INFORMACIÓN

Siete principios de la gestión de riesgos ' El Software Engineering Institute (SEI) (www. sei.cmu.edu) identifica siete principios que "ofrecen un marco de trabajo para lograr una gestión de riesgos efectiva". Dichos principios son:

Mantenimiento de una perspectiva global: ver los riesgos de software dentro del contexto del sistema en el que está un componente y el problema de negocios que se intenta resolver.

Tener una visión previsora: pensar en los riesgos

los participantes y usuarios a sugerir riesgos en cualquier momento. Integración: en el proceso del software debe estar integrada una consideración de los riesgos.

Enfatizar un proceso continuo: el equipo debe estar atento a lo largo de todo el proceso de software, modificar los riesgos identificados conforme se tenga más información y agregar unos nuevos a medida que se logre un mejor criterio.

Desarrollo de una visión conjunta del producto:

que pudieran surgir en lo futuro (por ejemplo, debido a cambios en el software); establecer planes de contingencia de modo que los eventos futuros sean manejables.

si todos los participantes comparten la misma visión del software, es probable que ocurra mejor identificación y evaluación de riesgos.

Alentar la comunicación abierta: si alguien estable-

Alentar el trabajo en equipo: los talentos, habilida-

ce un riesgo potencial, no lo descarte. Si un riesgo se propone de una manera informal, considérelo. Aliente a todos

des y conocimiento de los participantes se deben mezclar cuando se lleven a cabo actividades de gestión de riesgos.

La identificación de los riesgos es un intento sistemático e n c a m i nTM a d o a especificar las a m e n a z a s al plan del proyecto (estimaciones, calendarización, carga de recursos, etc.). Al identificar los riesgos conocidos y predecibies, el gestor del proyecto da un

PDF Editor

primer p a s o para evitarlos c u a n d o es posible y a controlarlos c u a n d o es necesario. Existen dos tipos distintos de riesgos para cada u n a de las categorías que se han

p r e s e n t a do en la sección 25.2: los riesgos genéricos y los riesgos específicos del producto. Los riesgos genéricos

son una a m e n a z a potencial para todo el proyecto de

software. Los riesgos específicos del producto los pueden identificar sólo aquellos con

CAPÍTULO 25

751

GESTIÓN DEL RIESGO

un claro conocimiento de la tecnología, el personal y el entorno específico del software que se construirá. Los riesgos específicos del producto se identifican examinando el plan del proyecto y la declaración del ámbito del software, así c o m o desarrollando una respuesta para la siguiente pregunta: "¿Qué características especiales de e s t e producto podrían a m e n a z a r el plan del proyecto?". "Los proyectos sin riesgos reoles son perdedores. Estos proyectos cosi siempre están desprovistos de beneficios; por ello no fueron realizados años otras." Tom DeMarco y Tim Uster

^CONSEJO^krque es impoitante :ysideror los riesgos ¡enéticos, los riesgos isxcUkos del :mducto son los que j o m a n lo mayoría i los dolores de ateza. Asegúrese de rmpfeflf tiempo pora efenlifkar tontos vsgos específicos del mducto como sea xsMe.

Un m é t o d o para identificar riesgos consiste en crear u n a lista de verificación de riesgos. Con ésta se pueden identificar riesgos y enfocarse en algún subconjunto de riesgos conocidos y predecibles en las siguientes subeategorías genéricas: • Tamaño del producto: riesgos asociados con el t a m a ñ o global del software que se construirá o modificará. • Impacto en el negocio: riesgos asociados con las restricciones que impone la gerencia o el mercado. • Características del cliente: riesgos asociados con la sofisticación del cliente y la habilidad del desarrollador para c o m u n ic a r se con él en u n a forma oportuna. • Definición de! proceso: riesgos asociados con el grado en el que se ha definido el proceso de s o f t w a r e y en que le da seguimiento la organización que lo desarrolla. • Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las h e r r a m i e n t a s que se usarán en la construcción del producto. • Tecnología que construir: riesgos asociados con la complejidad del sistema que se construirá y la "novedad" de la tecnología que está e m p a q u e t a d a en el sistema. • Tamaño y experiencia de la plantilla de personal: riesgos asociados con la e x p e riencia global técnica y en el proyecto de los ingenieros de software que h a r á n el trabajo. La lista de verificación de riesgos se p u e d e organizar en diferentes formas. Las preguntas relevantes respecto de cada uno de los tópicos se pueden responder para TM que el planicada proyecto de software. Las r e s p u e s t a s a e s t a s preguntas permiten ficador estime el impacto del riesgo. Un formato diferente de lista de verificación de riesgos simplemente m e n c i o n a las características relevantes para c a d a subeategoría

PDF Editor

genérica. Finalmente, se menciona un conjunto de "componentes y controladores de riesgo" [AFC88] junto con s u probabilidad de ocurrencia. Los controladores del des e m p e ñ o , soporte, costo y calendarización se estudian c o m o respuesta a las últimas preguntas.

752

PARTE CUATRO


En la bibliografía s e h a n p r o p u e s t o v a r i a s listas d e verificación d e t a l l a d a s p a r a r i e s g o s del p r o y e c t o d e s o f t w a r e (por e j e m p l o , [SEI93], [KAR96]), l a s c u a l e s p r o p o r c i o n a n u n a visión útil de los r i e s g o s g e n é r i c o s p a r a p r o y e c t o s d e s o f t w a r e , y s e d e b e n u s a r s i e m p r e q u e s e i n s t i t u y a n a n á l i s i s y g e s t i ó n del r i e s g o . Sin e m b a r g o , s e p u e d e e m p l e a r u n a lista r e l a t i v a m e n t e c o r t a de p r e g u n t a s [KE198] p a r a p r o p o r c i o n a r u n indicio p r e l i m i n a r d e si u n p r o y e c t o e s t á "en riesgo".

25.3.1 Evaluación del riesgo global del proyecto Las s i g u i e n t e s p r e g u n t a s s e b a s a n e n los d a t o s d e r i e s g o o b t e n i d o s al entrevistar, e n d i f e r e n t e s p a r t e s del m u n d o , a g e s t o r e s d e p r o y e c t o d e s o f t w a r e e x p e r i m e n t a d o s [KEI98]. Las p r e g u n t a s e s t á n o r d e n a d a s s e g ú n s u i m p o r t a n c i a r e l a t i v a e n el éxito de un proyecto. ¿El proyecto •

1. ¿Los a l t o s e j e c u t i v o s d e s o f t w a r e y del cliente s e h a n c o m p r o m e t i d o f o r m a l -

M

de software

p a r a a p o y a r el p r o y e c t o ?

en el que actual-

s u a r i o s finales e s t á n c o m p r o m e t i d o s c o n el p r o y e c t o y el s i s t e m a / p r o -

mente trabaja enfrenta riesgos serios?

ducto q u e se construirá?

3.

¿Los r e q u i s i t o s l o s h a n e n t e n d i d o c o m p l e t a m e n t e el e q u i p o de i n g e n i e r í a d e s o f t w a r e y s u s clientes?

4.

¿Los c l i e n t e s e s t u v i e r o n c o m p l e t a m e n t e i n v o l u c r a d o s e n la d e f i n i c i ó n d e los requisitos?

Bjgggagg | M radares uno b a s e ! henamientns que ayudan o los gestores : o identificar, dosificar y comunico! los riesgos de proyecto. 5B puede encontraren '<< www.fpmn.com. |

5.

¿Los u s u a r i o s finales t i e n e n e x p e c t a t i v a s r e a l i s t a s ?

6.

¿El á m b i t o del p r o y e c t o e s e s t a b l e ?

7.

¿El e q u i p o de i n g e n i e r í a del s o f t w a r e t i e n e la m e z c l a c o r r e c t a d e h a b i l i d a d e s ?

8.

¿Los r e q u i s i t o s del p r o y e c t o s o n e s t a b l e s ?

9.

¿El e q u i p o del p r o y e c t o t i e n e e x p e r i e n c i a c o n la t e c n o l o g í a q u e s e i m p l e m e n tará?

10.

¿El n ú m e r o d e p e r s o n a s e n el e q u i p o d e p r o y e c t o e s a d e c u a d o p a r a r e a l i z a r e'. trabajo?

11.

¿ T o d o s los v o t a n t e s del c l i e n t e / u s u a r i o e s t á n d e a c u e r d o e n la i m p o r t a n c i a del p r o y e c t o y e n los r e q u i s i t o s p a r a el s i s t e m a / p r o d u c t o q u e s e c o n s t r u i r á ?

TM "La gestión d e riesgos es la gestión de proyectos para adultos." Tim Lister

PDF Editor

Si la r e s p u e s t a a a l g u n a d e e s t a s p r e g u n t a s e s n e g a t i v a s e d e b e n instituir sin d e m o ra los p a s o s de r e d u c c i ó n , s u p e r v i s i ó n y gestión. El g r a d o e n el q u e el p r o y e c t o está

e n r i e s g o e s d i r e c t a m e n t e p r o p o r c i o n a l al n ú m e r o d e r e s p u e s t a s n e g a t i v a s a e s t a s preguntas.

CAPÍTULO 25

753

GESTIÓN DEL RIESGO

25.3.2 Componentes y controladores del riesgo La Fuerza Aérea de Estados Unidos [AFC88] escribió un folleto con excelentes directrices para la identificación y supresión del riesgo de software. Este e n f o q u e requiere que el gestor del proyecto identifique los controladores del riesgo que afectan los c o m p o n e n t e s de riesgo del software: d e s e m p e ñ o , costo, soporte y calendarización. En el contexto de e s t e estudio los c o m p o n e n t e s de riesgo se definen en la forma siguiente: • Riesgo de desempeño:

g r a d o de incertidumbre de que el producto satisfaga los

requisitos y se ajuste al uso que se pretende darle. • Riesgo de costo: g r a d o de incertidumbre de que s e m a n t e n g a el p r e s u p u e s t o del proyecto. • Riesgo de soporte: grado de incertidumbre de que el software resultante será fácil de corregir, adaptar y mejorar.

\^Componentes Desempeño Categoría

Soporte

Costo

Calendarización

N. T

Catastrófico 2

1

Crítica

El f r a c a s o e n la satisfacción d e los requisitos resultaría e n un f r a c a s o d e la misión Cierta reducción en el d e s e m p e ñ o técnico

Software que no r e s p o n d e o no s e p u e d e soportar

Demoras menores e n Cierto recorte d e recursos financieros, las modificaciones del software posibles e x c e s o s

Cierta reducción en el d e s e m p e ñ o técnico

1

El f r a c a s o p a r a satisfacer los requisitos resultaría e n d e g r a d a c i ó n d e la misión secundario

2

1

Despreciable

Recortes financieros significativos, p r o b a b l e superación del presupuesto

COI inalcanzable

El f r a c a s o resulta en d e m o r a s operativos El f r a c a s o p a r a satisfacer los requisitos o incremento d e costos con valor esperesultaría en un d e s e m p e ñ o d e g r a d a d o del sistema h a s t a un punto d o n d e el éxito r a d o d e 100K a 5 0 0 K d ó l a r e s d e to misión es cuestionable

2

Marginal

El f r a c a s o resulta en el a u m e n t o d e costos y e n d e m o r a s e n la c a l e n d a r i z a c i ó n con valores e s p e r a d o s q u e s u p e r a n 50QK dls.

Mínima a p e q u e ñ a reducción en el d e s e m p e ñ o técnico

Respuesta d e soporte d e software

El f r a c a s o al satisfacer los requisitos crearía inconvenientes o impactos no operativos

Posible deslizamientos en la C O I

Deslizamiento d e costos, impactos o c a l e n d a r i z a c i ó n re c u p e r a b l e con valor e s p e r a d o d e 1K a 100K d ó l a r e s Suficientes recursos financieros

Calendarización alcanzable y realista

TM

El error resulta e n costo menor o impacto e n la c a l e n d a r i z a c i ó n con valor e s p e r a d o d e m e n o s d e 1K d ó l a r e s

PDF Editor 2

N i n g u n a reducción en el d e s e m p e ñ o técnico

Software al q u e fácilmente s e le d a soporte

Posible superávit presupuesta!

Nota: 1. Consecuencia potencial de errores o (ollas d e software n o deteclados. 2 . Consecuencia potencial si el resultado d e s e a d o no s e alcanzo.

COI fácilmente alcanzable

PARTE CUATRO

754


• Riesgo de calendarización.- grado de incertidumbre de que se m a n t e n g a la calendarización del proyecto y de que el producto se entregue a tiempo. El impacto de cada controlador de riesgo sobre el c o m p o n e n t e de riesgo se divide en cuatro categorías de impacto: despreciable, marginal, crítico o catastrófico. En la figura 25.1 [BOE89] se describe u n a caracterización de las c o n s e c u e n c i a s potenciales de los errores (hileras etiquetadas 1) o una falla que no permite lograr u n resultado d e s e a d o (hileras etiquetadas 2). La categoría de impacto se escoge con b a s e e n la caracterización que mejor e n c a j e con la descripción e n la tabla. 25.4

P B O Y E C C Í Ó M REÍ. P I E S G O La proyección del riesgo, t a m b i én llamada estimación del riesgo, intenta clasificar cada riesgo e n dos formas: 1) la posibilidad o probabilidad de que el riesgo sea real, j 2) las c o n s e c u e n c i a s de los problemas asociados c o n el riesgo, en c a s o de que ocurra. El planificador del proyecto, junto con otros gestores y personal técnico, realizar, cuatro p a s o s en la proyección del riesgo: 1. Establecimiento de u n a escala que refleje la posibilidad percibida de un riesgo. 2.

Ejemplo de tabla de riesgos antes de la clasificación.

Delineado de las c o n s e c u e n c i a s del riesgo.

Riesgos La estimación del tamaño puede ser significativamente b a j a Mayor número de usuarios d e los previstos Menos reutiltzación que la prevista Los usuarios finales se resisten al sistema La fecha límite d e entrega estará muy ajustada Pérdida d e fondos El cliente cambiará requisitos La tecnología no satisfará las expectativas Falta de entrenamiento acerca de las herramientas Personal inexperto Elevada movilidad del personal

Categoría Probabilidad Impacto RSGR 2

TP

60%

TP TP CO CO CL TP RT ED PE PE

30%

3

70% 40%

2

50%

2

3

40%

2

80% 30%

80%

3 2 2

30%

60%

TM

PDF Editor Valores d e impacto: 1: catastrófico 2: critico 3: marginal 4: despreciable

CAPÍTULO 25 3.

GESTIÓN DEL RIESGO

755

Estimación del impacto del riesgo e n el proyecto y el producto.

4 . Tomar nota de la precisión global de la proyección del riesgo de m o d o que no haya m a l a s interpretaciones. La finalidad de estos p a s o s es considerar los riesgos e n tal forma que c o n d u z c a n al establecimiento de prioridades. Ningún equipo de s o f t w a r e tiene los recursos p a r a enfrentar todos los riesgos potenciales con el m i s m o g r a d o de rigor. Al priorizar los riesgos el equipo p u e d e asignar los recursos d o n d e tengan el mayor impacto.

25.4.1 Desarrollo de u n a tabla de riesgos [CONSEJO

! mucho acerca

i aforare que está i de construir y justed o: ¿qué puede r vd? Cree su l í s t o y pida o s miembros del i que hagan lo

Una tabla de riesgos ofrece al gestor de un proyecto una técnica simple para la proyección de riesgos. 2 En la figura 25.2 se ilustra un ejemplo de tabla de riesgos. Un equipo de proyecto c o m i e n z a una lista de todos los riesgos (sin importar cuán r e m o t o s sean) e n la primera columna de la tabla. Esto s e logra con la ayuda de la lista de verificación de riesgos m e n c i o n a d a e n la sección 25.3. Cada riesgo s e clasifica en la segunda columna (por ejemplo, TP implica un riesgo de t a m a ñ o del proyecto, NE implica un riesgo de negocios). En la siguiente columna de la tabla se registra la probabilidad de que ocurra cada riesgo. El valor de la probabilidad de c a d a riesgo lo pueden estimar individualmente los m i e m b r o s del equipo. Éstos s e e n c u e s t a n en una forma de "todos contra todos" hasta que su evaluación de la probabilidad del riesgo comience a convergir. A continuación se evalúa el impacto de cada riesgo. Cada c o m p o n e n t e de riesgo se evalúa mediante la caracterización presentada e n la figura 25.1, y se determina u n a categoría de impacto. Las categorías para cada uno de los cuatro c o m p o n e n t e s de riesgo (desempeño, soporte, costo y calendarización) se p r o m e d i a n 3 para determinar un valor de impacto global. Una vez c o m p l e t a d a s las cuatro primeras c o l u m n a s de la tabla de riesgos, ésta se ordena según la probabilidad y el impacto. Los riesgos d e alta probabilidad y alto imp a c t o se filtran hacia lo alto de la tabla, y los riesgos de baja probabilidad caen al

\

CLAVE

i toblo de riesgos í ordenada por I yxobilidad e impacto m s dosificar los «sgos.

fondo. Esto logra u n a priorización del riesgo de primer orden. El gestor del proyecto estudia la tabla o r d e n a d a resultante y define u n a línea de corte. La línea de corte (dibujada horizontalmente en algún p u n t o en la tabla) implica que sólo los riesgos ubicados sobre la línea tendrán una atención posterior. Los riesgos debajo de la línea se reevalúan para lograr una priorización de s e g u n d o orden. En la figura 25.3 el impacto y la probabilidad de riesgo influyen de m a n e r a disTMu n a probabitinta en la gestión. Un factor de riesgo que tiene u n alto impacto, pero lidad de que suceda muy baja, n o debe a b s o r b e r u n a cantidad significativa de tiem-

PDF Editor

2 Es posible implementar la tabla de nesgc-s como un modelo en hoja de cálculo. Esto permite una manipulación sencilla y el ordenamiento de las er -.radas 3 El empleo de un promedio ponderado es facerle ; aigún componente de riesgo tiene mayor relevancia para un proyecto.

756

PARTE CUATRO


po de gestión. Sin e m b a r g o , los riesgos de alto impacto con m o d e r a d a a alta proba-i bilidad y los riesgos de bajo impacto con alta probabilidad deben trasladarse a I o n p a s o s de análisis de riesgo que siguen. Todos los riesgos ubicados sobre la línea de corte deben gestionarse. La columr.i I rotulada RSGR contiene una referencia que apunta hacia un Plan de reducción, supevisión y gestión de riesgo o, alternativamente, una colección de hojas de información de: riesgo desarrolladas para todos los riesgos que están sobre el corte. En las secciones; 25.5 y 25.6 se examinan el plan RSGR y las hojas de información de riesgo.

"[En la actualidad] nadie tiene el lujo de llegar a conocer una tarea tan bien que no se lleve sorpresas, y las sorpresa significan riesgo." Stephen Grey

La probabilidad del riesgo se determina realizando estimaciones individuales r luego desarrollando un solo valor de c o n s e n s o . Aunque dicho e n f o q u e es valioso, se: han desarrollado técnicas m á s elaboradas con las cuales determinar la probabilids: del riesgo [AFC88], Los controladores de riesgo se p u e d e n evaluar sobre u n a escala de probabilidad cualitativa que tiene los siguientes valores: imposible, improbable probable y frecuente. Entonces se asocia la probabilidad matemática con cada valer cualitativo (por ejemplo, u n a probabilidad de 0.7 a 0.95 implica un riesgo enorme m e n t e probable).

Riesgo y

preocupaclones de la gestión.

Muy alto

Impacto

Muy b a j o

Relevancia TM para la gestión

PDF Editor

CAPÍTULO 25

757

GESTIÓN DEL RIESGO

25.4.2 Evaluación del impacto del riesgo Tres factores afectan las c o n s e c u e n c i a s que son probables si un riesgo ocurre: su n a turaleza, ámbito y tiempo. La naturaleza indica los p r o b l e m a s que son probables si ocurre. Por ejemplo, u n a interfaz externa mal definida hacia el h a r d w a r e del cliente (un riesgo técnico) evitará un diseño y prueba t e m p r a n o s y tal vez g e n e r e p r o b l e m a s de integración de sistema m á s tarde. El á m b i t o combina la severidad (¿cuán serio es?) con su distribución global (¿cuánto del proyecto se afectará, o c u á n t o s clientes resultarán dañados?). Finalmente, el tiempo de un riesgo considera c u á n d o y d u r a n te qué periodo se sentirá el impacto. En la mayoría de los c a s o s un gestor de proyecto tal vez quiera q u e ocurran las "malas noticias" tan pronto c o m o sea posible, p e r o en a l g u n o s casos, mientras mayor sea la d e m o r a , mejor. Regresando una vez m á s al e n f o q u e de análisis de riesgo que p r o p u s o la Fuerza Aérea de Estados Unidos [AFC88], se recomiendan los siguientes p a s o s para determinar las c o n s e c u e n c i a s globales de un riesgo: 1. Determinar el valor promedio de la probabilidad de que ocurra para cada £ W

¿Cómo se valoran las

{••secuencias de • riesgo?

c o m p o n e n t e de riesgo. 2.

Empleando la figura 25.1, determinar el impacto para cada c o m p o n e n t e , con b a s e en los criterios mostrados.

3 . Completar la tabla de riesgos y analizar los resultados c o m o se describe e n las secciones precedentes. La exposición

al riesgo global, ER, se determina mediante la siguiente relación

[HAL98]: ER = P x C d o n d e P es la probabilidad de que ocurra un riesgo, y C, el costo al proyecto en c a s o de que ocurra el riesgo. Por ejemplo, suponga que el equipo de software define un riesgo de proyecto en la forma siguiente: I d e n t i f i c a c i ó n del riesgo. De hecho, sólo 70 por ciento de los c o m p o n e n t e s de s o f t w a r e calendarizados para reutilización se integra e n la aplicación. La funcionalidad restante tendrá que desarrollarse de m o d o personalizado. Probabilidad d e riesgo. 80 p o r ciento (quizá). I m p a c t o del riesgo. Se planificaron 60 c o m p o n e n t e s de s o f t wTM a r e reutilizables. Si sólo s e p u e d e emplear el 70 por ciento, 18 c o m p o n e n t e s tendrían q u e desarrollars e desde c e r o (además de otro s o f t w a r e personalizado que s e ha calendarizado pa-

PDF Editor

ra desarrollo). Puesto que el c o m p o n e n t e p r o m e d i o e s 100 LDC y los d a t o s locales indican que el c o s t o de ingeniería del software para c a d a u n o es de 14.00 dólares, el

c o s t o (impacto) global del desarrollo de los c o m p o n e n t e s sería 18 x 25 200 dólares.

E x p o s i c i ó n al riesgo. ER = 0.8C • 25 200 dólares - 20 200 dólares.

100 x

14 =

758

PARTE CUATRO


La e x p o s i c i ó n a i r i e s g o s e p u e d e c a l c u l a r p a r a c a d a r i e s g o e n la t a b l a d e r i e s g o s u n a v e z q u e s e e s t i m e el c o s t o del r i e s g o . La e x p o s i c i ó n al r i e s g o t o t a l p a r a t o d o s l o s r i e s g o s ( s o b r e la l í n e a d e c o r t e e n la t a b l a ) p u e d e o f r e c e r u n m e d i o c o n q u e a j u s t a r la e s t i m a c i ó n d e l c o s t o final d e u n p r o y e c t o . T a m b i é n s e e m p l e a p a r a p r e d e c i r el a u ÔNSEJO^ Compárese la ER de fodos los riesgos con lo estimación de costo para el proyecto. Si la ER es mayor que SO por ciento del costo del proyecto, lo viabilidad del proyecto debe leevaluarse.

m e n t o p r o b a b l e en los r e c u r s o s d e p e r s o n a l q u e s e requieran en varios p u n t o s du r a n t e la c a l e n d a r i z a c i ó n del p r o y e c t o . La p r o y e c c i ó n d e l r i e s g o y l a s t é c n i c a s d e a n á l i s i s d e s c r i t a s e n l a s s e c c i o n e s 2 5 . 4 . 1 y 2 5 . 4 . 2 s e a p l i c a n d e m a n e r a i t e r a t i v a c o n f o r m e a v a n z a el p r o y e c t o d e s o f t w a r e . El e q u i p o d e l p r o y e c t o d e b e r e v i s a r d e n u e v o la t a b l a d e r i e s g o s e n i n t e r v a l o s r e g u l a res, reevaluar c a d a riesgo p a r a d e t e r m i n a r c u á n d o n u e v a s circunstancias c a m b i a r á n s u p r o b a b i l i d a d e i m p a c t o . C o m o c o n s e c u e n c i a , tal v e z s e a n e c e s a r i o a g r e g a r n u e v o s r i e s g o s a la t a b l a , e l i m i n a r a l g u n o s riesgos q u e a h o r a s o n i r r e l e v a n t e s y c a m b i a r las posiciones relativas d e otros.

Análisis

de riesgos

El e s c e n a r i o : Oficina de Doug Mi> del proyecto de software HogarSeguro. : Doug Miller (gerente del equipo de ingedel software HogarSeguro) y Vinod Raman, Jamie Lazar y otros miembros del equipo de ingeniería del software del producto. La c o n v e r s a c i ó n : D o u g : Me gustaría pasar un poco de tiempo en uno lluvia de ideas acerca d e los riesgos que enfrenta el proyecto HogarSeguro.

V i n o d : Así que si creo que el riesgo es como lanzar una moneda, especifico un 5 0 por ciento de probabilidad, y si creo que tendrá un impacto d e proyecto moderado, especifico un 3, ¿cierto? D o u g : Exactamente. (Pasan cinco minutos; todos escriben.) D o u g : Muy bien, alto. Ahora haremos una lista del grupo en el pizarrón. Yo escribiré, diré una entrada d e su lista en formato de todos contra todos.

J a m i e ; ¿Cómo en qué puede salir mal?

(Pasan quince minutos; se crea la lista.)

D o u g : Sí. Aquí hay algunas categorías de dónde pueden salir mal las cosas. [Muestra a todos las categorías anotadas en la introducción de la sección 25.3.]

J a m i e ( s e ñ a l a a l p i z a r r ó n y ríe): Vinod, ese ríes go (apunta hacia una entrada en el pizarrón) es ridículo. Existe una enorme probabilidad de que todos seamos golpeados por un rayo. Debemos quitarlo.

V i n o d : Mmmmm... ¿quieres que sólo las mencionemos o...? D o u g : No. Esto es lo que creo que debemos hacer. Todos hagan una lista de riesgos... ahora.... (Pasan diez minutos; todos escriben.) D o u g : Muy bien, alto.

D o u g : No, dejémoslo por ahora. Consideremos todos los riesgos, sin importar cuán locos sean. Más tarde ventilaremos la lista.

TM

J a m i e : Pero ya tenemos casi 4 0 riesgos, dremos manejar todos?

PDF Editor J a m i e : (Pero no he terminado!

D o u g : Está bien. Volveremos a ver las listas. Ahora, en cada entrada de su lista, asignen un porcentaje de probabilidad de que el riesgo ocurrirá. Luego, asignan un impacto al proyecto en una escala de 1 (menor) a 5 (catastrófico).

¿cómo po

D o u g : No podemos. Por eso definiremos una línea de corte después de ordenar estas linduras. Yo haré eso más tarde y nos reuniremos de nuevo mañana. Por ahora regresen a trabajar... y en su tiempo libre, piensen acerca de cualquier riesgo que hayamos olvidado.

759

Durante las primeras e t a p a s de la planificación del proyecto se p u e d e establecer un riesgo de m a n e r a muy general. Conforme pasa el tiempo y s e a p r e n d e m á s acerca del proyecto y el riesgo, es posible refinar el riesgo e n un c o n j u n t o de riesgos m á s detallados, cada u n o un poco m á s sencillo de retinar, supervisar y gestionar. Una forma de hacer esto e s representar el riesgo en el formato condición-transiciónconsecuencia (CTC) [GLU94J. Es decir, el riesgo se establece en la forma siguiente: Dado que entonces existe una preocupación de que (posiblemente) cconsecuencia> Mediante el e m p l e o del formato CTC en lugar del riesgo de reutilización a n o t a d o en la Sección 25.4.2, se p u e d e escribir: Dado que todos los componentes de software reutilizables deben ajustarse con estándares de diseño específicos, y como algunos no lo hacen, entonces existe una preocupación de que (posiblemente) sólo 70 por ciento de los módulos reutilizables planeados puedan en realidad integrarse al sistema que se construirá, lo que resulta en la necesidad de ingeniería personalizada para el restante 30 por ciento de componentes. Esta condición general se p u e d e refinar en la forma siguiente: Subcondición 1. Ciertos componentes reutilizables fueron desarrollados por terceras personas sin conocimiento de los estándares de diseño internos. Subcondición 2 . El estándar de diseño para el componente de interfases no se ha concretado y tal vez no se ajuste con ciertos componentes reutilizables existentes. Subcondición 3. Ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el entorno destino. Las c o n s e c u e n c i a s asociadas con estas subcondiciones refinadas siguen siendo las m i s m a s (es decir, 30 por ciento de los c o m p o n e n t e s de s o f t w a r e tienen que s o m e terse a ingeniería personalizada), p e r o el refinamiento ayuda a aislar los riesgos suby a c e n t e s y p u e d e conducir a un análisis y r e s p u e s t a s m á s sencillos.

Todas las actividades del análisis de riesgo p r e s e n t a d a s h a s t a el m o m e n t o tienen una sola meta: ayudar al equipo del proyecto a desarrollar u n a estrategia para luchar con el riesgo. Una estrategia eficaz d e b e considerar tres temas-,

TM

• Evitar del riesgo.

PDF Editor • Supervisar el riesgo.

• Gestionar el riesgo y los p l a n e s de contingencia.

Si un equipo de s o f t w a r e adopta u r enfoque rroactivo hacia el riesgo, evitarlo

siempre es la mejor estrategia. Ésta se ¡ogra ¿es-arrollando un plan para reducir el

760

PARTE CUATRO


riesgo. Por ejemplo, s u p ó n g a s e que u n a elevada movilidad en el personal se anata c o m o un riesgo del proyecto, r,. Con b a s e en la historia y la intuición administrativa la probabilidad, /,, de u n a elevada movilidad se estima en 0.70 (70 por ciento, mai ¡ bien alta) y el impacto, x,, se proyecta c o m o critico. Esto es: u n a tasa elevada de mcvilidad tendrá un impacto crítico en el costo del proyecto y la calendarización.

"Si tomo demasiados precauciones, es porque no dejo nada al ozar." Napoleón

7

¿Q«é se

*

puede hacer

para reducir un riesgo?

Este riesgo se reduce si el gestor del proyecto desarrolla u n a estrategia para reducir la movilidad. Entre los posible p a s o s que s e t o m a n se encuentran: • Reunirse con el personal actual para determinar las c a u s a s de la movilidad (por ejemplo, limitadas condiciones de trabajo, b a j o s salarios, m e r c a d o laboral competitivo). • Reducir aquellas c a u s a s que se controlan a n t e s de que c o m i e n c e el proyectc • Una vez iniciado el proyecto, suponer que la movilidad ocurrirá y entonces desarrollar técnicas que aseguren la continuidad c u a n d o la g e n t e se aleje. • Organizar equipos de proyecto d e m o d o q u e la información acerca de cada actividad de desarrollo se disperse con amplitud. • Definir e s t á n d a r e s de documentación y establecer m e c a n i s m o s que asegure que los d o c u m e n t o s se desarrollen en una forma oportuna. • Llevar a c a b o revisiones por p a r e s de todo el trabajo (de m o d o que m á s de u n a persona esté "en ritmo"). • Asignar un m i e m b r o de personal de respaldo por cada tecnología crítica Conforme a v a n z a el proyecto se inician las actividades de supervisión del riesg: l l gestor del proyecto supervisa los factores q u e p u e d e n proporcionar un indicio ct a el riesgo se está volviendo m á s o m e n o s probable. En el c a s o d e la elevada t a s ; movilidad del personal, se p u e d e n supervisar los siguientes factores: • Actitud general de los miembros del equipo con b a s e en las presiones del r e yerto. • El g r a d o en el cual el equipo está cuajado.

TM

• Las relaciones interpersonales entre los miembros del equipo.

PDF Editor

• Potenciales p r o b l e m a s con las c o m p e n s a c i o n e s y los beneficios. • La disponibilidad de e m p l e o d e n t r o y fuera de la c o m p a ñ ía .

A d e m á s de supervisar e s t o s factores, u n gestor de proyecto d e b e supervisa-

efectividad de los p a s o s d e reducción del riesgo. Por ejemplo, un p a s o de r e d u c c . a s del riesgo a n o t a d o líneas arriba pide la definición de e s t á n d a r e s de d o c u m e n t a ; :TI

CAPÍTULO 25

GESTIÓN DEL RIESGO

761

y m e c a n i s m o s para garantizar que los d o c u m e n t o s se elaboran e n forma oportuna. Éste e s un m e c a n i s m o para a s e g u r a r la continuidad en c a s o de que un individuo crucial a b a n d o n e el equipo. El gestor del proyecto d e b e supervisar los d o c u m e n t o s cuid a d o s a m e n t e para asegurarse de que c a d a u n o p u e d e p e r m a n e c e r por si solo y que cada u n o contiene información que sería necesaria si una nueva persona se viera obligada a unirse al equipo de s o f t w a r e en algún m o m e n t o a la mitad del proyecto. La gestión del riesgo y los planes de contingencia s u p o n e n que los e s f u e r z o s de reducción h a n f r a c a s a d o y que el riesgo se ha vuelto una realidad. C o n tin u a n d o con el ejemplo, el proyecto ya está bien a v a n z a d o y varias p e r s o n a s a n u n c i a n que renunciarán. Si se ha seguido la estrategia de reducción, el respaldo está disponible, la información se h a d o c u m e n t a d o y el conocimiento se h a dispersado entre el equipo. Además, el gestor del proyecto p u e d e reenfocar t e m p o r a l m e n t e los recursos (y reajustar la calendarización del proyecto) hacia aquellas funciones c o m p l e t a m e n t e e s tructuradas, así permite que los n u e v o s e l e m e n t o s que d e b e n agregarse al equipo "tomen el ritmo". A los individuos que deciden marcharse se les pide detener t o d o el trabajo y pasar sus últimas s e m a n a s "aprendiendo el m o d o de transferencia". Esto p u e d e incluir la adquisición de conocimiento en videos, el desarrollo de "documentos c o m e n t a d o s " o reuniones con otros m i e m b r o s del equipo que p e r m a n e c e r á n en

fcONSEJO^^ Si ¡a ER paro un ->esgo específico es -enor que el costo de la reducción del riesgo, no se intente 'educir el riesgo sino continuar supervisándolo.

el proyecto. Es importante señalar que los p a s o s de reducción, supervisión y gestión del riesgo (RSGR) g e n e r a n costos adicionales en el proyecto. Por ejemplo, utilizar el tiempo para "respaldar" cualquier tecnología crítica cuesta dinero. Por lo tanto, parte de la gestión del riesgo consiste e n evaluar c u á n d o los beneficios que g e n e r a n los p a s o s RSGR se r e z a g a n frente a los costos asociados con su implementación. En esencia, el planificador del proyecto realiza un clásico análisis costo-beneficio. Si los p a s o s con que se evita el riesgo de elevada movilidad de personal a u m e n t a r a n tanto el costo del proyecto c o m o su duración en un estimado de 15 por ciento, pero el factor de costo p r e d o m i n a n t e es el "respaldo", el gestor p u e d e decidir n o implementar este paso. Por otra parte, si los p a s o s con que se evita el riesgo s e proyectan para a u m e n tar los c o s t o s en 5 por ciento y la duración en sólo 3 por ciento, el gestor probablem e n t e pondrá t o d o e n su lugar. En u n proyecto g r a n d e e s posible definir 30 o 40 riesgos. Si para cada u n o se identifican entre tres y siete p a s o s de gestión del riesgo, ¡ésta p u e d e convertirse por sí misma e n un proyecto! Por esta razón se adapta la regla 80-20 de Pareto al riesgo de software. La experiencia indica que 80 por ciento del riesgo del proyecto global TM (es decir, 80 por ciento del potencial para falla del proyecto) p u e d e explicarse sólo con 20 por ciento de los riesgos identificados. El trabajo realizado durante los prime-

PDF Editor

ros p a s o s del análisis de riesgo ayudará al planificador a determinar cuáles de los riesgos se e n c u e n t r a n en ese 20 por ciento ipor ejemplo, riesgos que c o n d u z c a n a la mayor exposición al riesgo). Por esta razón algunos de los riesgos identificados,

e v a l u a d o s y proyectados pueden no incluirse e n el plan RSGR, ya que n o s e ubican en el crítico 20 p o r ciento (los riesgos con a ™iayor prioridad de proyecto).

762

PARTE CUATRO

Un voluminoso archivo que contiene lodos los entrados del Foro ACM acerca de Riesgos al Público se puede encontraren

p u é s d e q u e el s o f t w a r e s e h a d e s a r r o l l a d o e x i t o s a m e n t e y e n t r e g a d o a l c l i e n t e . Es-


El riesgo n o e s t á l i m i t a d o al p r o y e c t o d e s o f t w a r e . L o s riesgos p u e d e n o c u r r i r d e s -

catless.ml.ac.uk/ Risks.

t o s riesgos e s t á n t í p i c a m e n t e a s o c i a d o s c o n l a s c o n s e c u e n c i a s d e la falla d e s o f t w a r e e n el c a m p o . El análisis

de seguridad

y peligros

de software

[LEV95] s o n a c t i v i d a d e s d e a s e g u r a -

m i e n t o d e la c a l i d a d del s o f t w a r e ( c a p í t u l o 26) q u e s e e n f o c a n e n la i d e n t i f i c a c i ó n y e v a l u a c i ó n d e l o s p e l i g r o s p o t e n c i a l e s q u e p u d i e r a n a f e c t a r al s o f t w a r e n e g a t i v a m e n t e y p r o v o c a r u n a f a l l a e n t o d o el s i s t e m a . Si los p e l i g r o s s e p u e d e n i d e n t i f i c a r t e m p r a n o e n el p r o c e s o d e i n g e n i e r í a d e l s o f t w a r e , l a s c a r a c t e r í s t i c a s d e d i s e ñ o d e s o f t w a r e s e p u e d e n e s p e c i f i c a r d e m o d o q u e e l i m i n e n o c o n t r o l e n los p e l i g r o s p o tenciales.

H o j a d e inform a c i ó n del riesgo [WIL97],

Hoja de información del riesgo ID d e riesgo: P02-4-32

Fecha: 9 / 5 / 0 4

Prob: 80%

Impacto: alto

Descripción: Sólo 7 0 por ciento d e los componentes de software calendarizados paro reutilización de hecho se integrarán en la aplicación. La funcionalidad restante tendrá que desarrollarse de manera personalizada.

Refinamiento/contexto: Subcondición 1: Ciertos componentes de reutilización fueron desarrollados por un tercer participante sin conocimiento d e los estándares de diseño internos. Subcondición 2: El estándar d e diseño para los componentes de interfaces no ha sido solidificado y tal vez no concuerden con ciertos componentes reutilizables existentes. Subcondición 3: Ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el entorno destino.

Reducción/supervisión: 1. Contactar con el tercer participante para determinar la concordancia con los estándares de diseño. 2. Presionar para completar los estándares d e interfaz; considerar la estructura del componente cuando se decida acerca del protocolo de la interfaz. 3. Verificar para determinar el número d e componentes en la categoría 3 de subcondición; verificar para determinar si se puede adquirir el soporte para el lenguaje.

Gestión/plan de contingencia/disparador: La ER se calcula en 2 0 2 0 0 dólares. Asignar esta cantidad dentro del costo TM de contingencia del proyecto. Desarrollar una calendarización revisada suponiendo que se tendrán que construir 18 componentes adicionales; asignar el personal en concordancia. Disparador: Los pasos de reducción son improductivos al 1 / 7 / 0 4 .

PDF Editor Estado actual:

1 2 / 5 / 0 4 : Inician los pasos de reducción.

Elaboró:

D. G a g n e

Asignado a:

B. Laster

CAPÍTULO 25

763

GESTIÓN DEL RIESGO

En el plan del proyecto de s o f t w a r e se p u e d e incluir una estrategia de gestión de riesgo o los p a s o s de gestión del riesgo organizarse por s e p a r a d o en un Plan de reducción, supervisión y gestión del riesgo. El plan RSGR d o c u m e n t a t o d o el trabajo realizado c o m o parte del análisis del riesgo y el gestor del proyecto lo emplea c o m o parte del plan global del proyecto. Algunos equipos de software n o elaboran un d o c u m e n t o RSGR formal. En su lugar, cada riesgo se d o c u m e n t a individualmente mediante u n a hoja de información del riesgo (HIR) [WIL97]. En la mayoría de los c a s o s la HIR se m a n t i e n e e m p l e a n d o un sistema de b a s e de datos, de m o d o que la creación y las e n t r a d a s de información, o r d e n a m i e n t o de prioridades, b ú s q u e d a s y otros análisis se logran fácilmente. En la figura 25.4 se ilustra el formato de la HIR. Una vez d o c u m e n t a d o el plan RSGR y que el proyecto ha c o m e n z a d o , se inician los p a s o s de reducción y supervisión del riesgo. C o m o ya se ha c o m e n t a d o , la reducción del riesgo es u n a actividad e n c a m i n a d a a evitar el problema. La supervisión del riesgo es u n a actividad de seguimiento del proyecto con tres objetivos principales: 1) valorar si los riesgos predichos de h e c h o ocurren; 2) a s e g u r a r que los p a s o s para evitar el riesgo definidos para é s t e s e están aplicando con propiedad; y 3) recopilar información que pueda usarse e n futuros análisis de riesgo. En m u c h o s casos, a los problemas que ocurren d u r a n t e un proyecto es posible darles seguimiento hacia m á s de un riesgo. Otra labor de la supervisión del riesgo es intentar ubicar el origen (qué riesgos provocaron qué problemas a través del proyecto).


Gestión del riesgo Objetivo: El objetivo de las herramientas de gestión del riego es ayudar al equipo del proyecto a definir los riesgos, valorar su impacto y probabilidad, y seguir los riesgos a través de todo el proyecto de software. M e c á n i c a : En general, las herramientas de gestión del riesgo auxilian en la identificación de riesgos genéricos al proporcionar una lista de riesgos usuales de proyecto y de negocios, ofrecer listas de verificación u otras técnicas "de entrevista" que auxilien en la identificación de riesgos específicos del proyecto, asignar probabilidad e impacto a

V

•\

cada riesgo, apoyar las estrategias de reducción del riesgo y generar muchos reportes relacionados con el riesgo.

Herramientas representativas 4 Riskman, desarrollada en Arizona State University (www. eas.asu.edu/~sdm/merrill/riskman.html), es un sistema experto en evaluación de riesgo que identifica riesgos relacionados con el proyecto. Risk Radar, desarrollada por SPMN (www.spmn.com), auTM xilia o los gestores de proyectos a identificar y gestionor riesgos.

PDF Editor

y

4 Las herramientas anotadas aquí son una muestra 3e esta categoría. En la mayoría de los casos los nombres de las mismas son marcas regístralas rxx sis respectivos desarrolladores.

764

PARTE CUATRO


R/s/íTra/c, desarrollada por RST (www.risktrac.com), apoya la identificación, el análisis, el reporte y la gestión de riesgos a través de un proyecto de software. R¡sk+, desarrollada por C / S Solutions (www.CS-solutions. com), se integra con Microsoft Project para cuantificar costos e incertidumbres de calendarización.

X.PRIMER, desarrollada por GrafP Technologies (www. grafp.com), es una herramienta genérica basada en Web que predice qué puede salir mal en un proyecto e identifica el origen de las causas de potenciales fallas y contramedidas efectivas.

Siempre que en un proyecto de s o f t w a r e esté m u c h o en juego, el sentido c o m ú n dicta el análisis de riesgos. Sin embargo, m u c h o s gestores de proyecto de software lo hacen informal y superficialmente, si e s q u e lo hacen. El tiempo e m p l e a d o en identificar, analizar y gestionar el riesgo paga por sí m i s m o dividendos e n m u c h a s formas: m e n o s trastornos d u r a n t e el proyecto, u n a mayor habilidad para seguir y controlar un proyecto, y la confianza q u e llega c u a n d o se planifican los problemas a n t e s de que ocurran. El análisis de riesgos p u e d e a b s o r b e r una cantidad significativa de e s f u e r z o de planificación del proyecto. La identificación, proyección, evaluación, gestión y supervisión t o m a n tiempo. Pero el e s f u e r z o bien vale la pena. Para citar a Sun Tzu, el general chino q u e vivió h a c e 2 500 años: "Si usted c o n o c e al e n e m i g o y se c o n o c e a si mismo, no necesita temer el resultado de cien batallas". El e n e m i g o del gestor del proyecto de s o f t w a r e es el riesgo.

REFERENCIA [AFC88] Software Risk Abatement, AFCS/AFLC Pamphlet 800-45, U.S. Air Forcé, 30 de septiembre de 1988. [BOE89I Boehm, B, W„ Software Risk Management, IEEE Computer Society Press, 1989. [CHA891 Charette, R. N., Software Engineering Risk Analysis and Management, McGraw-Hill/Intertext, 1989. [CHA92] Charette, R. N., "Building Bridges over Intelligent Rivers", en American Programmer, vol. 5, núm. 7, septiembre de 1992, pp. 2-9. [DRU75] Drucker, P„ Management, W. H. Heinemann, 1975. [G1L88J Gilb, T., Principies of Software Engineering Management, Addison-Wesley, 1988. 1GLU94] Gluch, D. P„ "A construct for Describing Software Development Risks", CMU/SEI-94TR-14, Software Engineering Institute, 1994. [HAL98J Hall, E. M., Managing Risk: Methods for Software Systems Development, Addison-Wesley, TM 1998. IHIG95] Higuera, R. P„ "Team Risk Management", en CrossTalk, U.S. Dept. of Defense, enero de 1995, pp. 2-4. [KAR96] Karoiak, D. W., Software Engineering Risk Management, IEEE Computer Society Press, 1996. [KEI98] Keil, M. et al., "A Framework for Identifying Software Project Risks", en CACM, vol. 41, núm. 1, noviembre de 1998, pp. 76-83. [LEV95] Leveson, N. G., Software System Safety and Computers, Addison-Wesley, 1995. [SEI93] "Taxonomy-Based Risk Identification", Software Engineering Institute, CMU/SEI-93-TR6, 1993.

PDF Editor

CAPÍTULO 25

765

GESTIÓN DEL RIESGO

[TH092] Thomsett, R„ 'The Indiana Jones School of Risk Management", en American Programmer, vol. 5, núm. 7, septiembre de 1992, pp. 10-18. [WIL97J Williams, R. C.,). A. Walker y A. J. Dorofee, "Putting Risk Management into Practice", en IEEE Software, mayo de 1997, pp. 75-81.

2 5 . 1 . Ofrecer cinco ejemplos de otros campos que ilustren los problemas asociados con una estrategia de riesgo reactiva. 2 5 . 2 . Describir la diferencia entre "riesgos conocidos" y "riesgos predecibles". 2 5 . 3 . Agregar tres preguntas o tópicos adicionales a cada una de las listas de verificación de riesgo que se presentan en el sitio Web SEPA. 2 5 . 4 . A usted se le ha pedido construir software para apoyar un sistema de edición de video de bajo costo. El sistema acepta como entrada video digital, almacena el video en disco y luego permite que el usuario haga una amplia variedad de ediciones al video digitalizado. El resultado puede entonces grabarse en DVD u otro medio audiovisual. Investigue un poco acerca de sistemas de este tipo y luego elabore una lista de riesgos tecnológicos que enfrentaría al comenzar un proyecto con estas características. 2 5 . 5 . Usted es el gestor de proyecto de una gran compañía de software. Se le solicita dirigir un equipo que está desarrollando software de procesamiento de textos de "nueva generación". Cree una tabla de riesgos para el proyecto. 2 5 . 6 . Describir la diferencia entre componentes de riesgo y controladores de riesgo. 2 5 . 7 . Desarrollar una estrategia de reducción de riesgo y especificar actividades de reducción de riesgo para tres de los riesgos anotados en la figura 25.2. 2 5 . 8 . Desarrollar una estrategia de supervisión de riesgo y especificar actividades de supervisión de riesgo para tres de los riesgos anotados en la figura 25,2. Asegúrese la identificación de los factores que se supervisarán para determinar si el riesgo se está volviendo más o menos probable. 2 5 . 9 . Desarrollar una estrategia de gestión del riesgo y especificar actividades de gestión del riesgo para tres de los riesgos anotados en la figura 25.2. 2 5 . 1 0 . Inténtese refinar tres de los riesgos anotados en la figura 25.2 y luego créense hojas de información de riesgo para cada uno. 2 5 . 1 1 . Represéntense tres de los riesgos anotados en la figura 25.2 empleando un formato CTC. 2 5 . 1 2 . Vuélvase a calcular la exposición al riesgo examinada en la sección 25.4.2 cuando el costo/LDC es de 16 dólares, y la probabilidad de 60 por ciento. 2 5 . 1 3 . ¿Puede pensar en una situación en la que un riesgo de alta probabilidad y alto impacto no seria considerado como parte de su plan RSGR? 2 5 . 1 4 . Descríbanse cinco áreas de aplicación de software en las que el análisis de la seguridad y los peligros del software serían una preocupación principal.

TM

O T R A S LECTURAS Y FUENTES

LI

INFORMACIÓN

PDF Editor

La bibliografía de gestión del riesgo de softw are se ha expandido significativamente durante la década pasada. DeMarco y Lister (Dancing \v.ih Bears Dorset House, 2003) han escrito un libro entretenido y lúcido que guía a los gestores y profesionales de software a través de la gestión del riesgo. Moynihan (Coping with IT/IS Risí Springer-Verlag, 2002) presenta consejos pragmáticos de gestores de proyecto que lidiar continuamente con él. Royer (Project Risk

766

PARTE CUATRO


Management, Management Concepts, 2002) y Smith y Merritt (Proactive Risk Management, Prcductivity Press, 2002) sugieren un proceso proactivo para la gestión del riesgo. Karolak (Software Engineering Risk Management, Wiley, 2002) ha escrito una guia que introduce un modelo ot' análisis de riesgo fácil de usar y que contiene valiosas listas de verificación y cuestionarios que se apoyan en un paquete de software. Schuyler (Risk and Decisión Analysis in Projects, PM1, 2001) considera el análisis de riesgo, desde una perspectiva estadística. Hall (Managing Risk: Methods for Software Systems Devc : ment, Addison-Wesley, 1998) presenta uno de los tratamientos más exhaustivos de la maten ¿ Myerson (Risk Management Processing for Software Engineering Models, Artech House, 1997» considera métricas, seguridad, modelos de proceso y otros tópicos. Grey (Practical RiskAsses¿ ment for Project Management, Wiley, 1995) escribió un útil manual de la evaluación del riesg: Su tratamiento abreviado ofrece una buena introducción a la materia. Capers Jones (Assessment and Control of Software Risks, Prentice-Hall, 1994) presenta una e > posición detallada de los riesgos de software que incluye datos recopilados a partir de cientos de proyectos de software. Jones define 60 factores de riesgo que pueden afectar el resultado c t los proyectos de software. Boehm [BOE89] sugiere excelentes formatos de cuestionario y listas, de verificación que pueden resultar invaluables en la identificación de riesgos. Charette [CHAépresenta un tratamiento detallado de las mecánicas del análisis de riesgo, y utiliza teoría de probabilidad y técnicas estadísticas para analizar riesgos. En un volumen adicional, Charette lAr plication Strategies for Risk Analysis, McGraw-Hill, 1990) analiza el riesgo en el contexto de = ingeniería tanto de sistemas como de software, y sugiere estrategias pragmáticas para la ges tión del riesgo. Gilb (Principies of Software Engineering Management, Addison-Wesley, 1988) prt senta un conjunto de "principios" (en ocasiones graciosos y a veces profundos) que pueden se-vir como una guía valiosa para la gestión del riesgo. Ewusi-Mensah (Software Development Failures: Anatomy of Abandoned Projects, MIT Pres; 2003) y Yourdon (Death March, Prentice-Hall, 1997) analizan lo que ocurre cuando los riesgos abruman a un equipo de proyecto de software. Bernstein (Against the Cods, Wiley, 1998) preseta una entretenida historia del riesgo que se remonta a tiempos antiguos. El Software Engineering Institute ha publicado muchos informes detallados y guías acerca del análisis y la gestión del riesgo. El folleto AFSCP 800-45 [AFC88] del Air Forcé Systems C o r mand describe las técnicas de identificación y reducción de riesgos. Cualquier número del ACW Software Engineering Notes tiene una sección titulada "Riesgos para el público" (editor, P. G. Ne_ mann). Si usted quiere las más recientes y mejores historias de horror de software, éste es el L gar al que tiene que ir. En internet hay disponible una amplia variedad de fuentes de información acerca de gesti: n del riesgo de software. Una lista actualizada de referencias en la World Wide Web se puede er contrar en el sitio Web SEPA: http://www.mhhe.com/presssman.

TM

PDF Editor

C A P Í T U L O

GESTIÓN DE LA CALIDAD CONCEPTOS CLAVE apTrfkacióii

te defectos ...77S aUad

769

aatrol á t cofidod

770

sito te calidad. . . . .775 ostos h tallas

771

SabiRdad

786

SO 9001: 2000

790

•wstreo

781

HH de SQA . . .791 • sones ; TF)

774

seguridad de software

788

seis sigma

785

SOA estadística 783

26

E

l e n f o q u e de ingeniería del s o f t w a r e descrito en este libro se dirige hacia u n a sola meta: producir s o f t w a r e de alta calidad. Aunque a m u c h o s lector e s les parecerá un reto la pregunta: ¿qué es calidad del software? Philip Crosby [CR079], en su libro fundamental acerca de calidad, ofrece u n a respuesta irónica a esta pregunta: El problema de la gestión de la calidad no es lo que la gente ignora acerca de ella. El problema es lo que creen saber... A este respecto, la calidad tiene mucho en común con el sexo Todo el mundo lo quiere. (En ciertas condiciones, desde luego.) Todos sienten que lo entienden. (Aun cuando no quieran explicarlo.) Todos piensan que su ejecución sólo es cuestión de seguir las inclinaciones naturales. (Después de todo, la gente se las arregla de alguna forma.) Y, desde luego, la mayoría de las personas piensa que los problemas en estas áreas los provocan otras personas. (Si sólo se tomaran el tiempo para hacer las cosas bien.)

Algunos desarrolladores de s o f t w a r e continúan creyendo que la calidad de é s t e es algo en lo que se d e b e c o m e n z a r a preocupar sólo d e s p u é s de que se h a ya g e n e r a d o el código. ¡Nada podría estar más alejado de la verdad! La gestión de la calidad (con frecuencia llamada garantía de Ja calidad del software) es u n a actividad protectora o de sombrilla (capítulo 2) que se aplica a lo largo del proc e s o de software. La gestión de la calidad abarca 1) un proceso de garantía de la calidad del s o f t w a r e (SQA, por sus siglas en inglés), 2) t a r e a s específicas d e a s e g u r a m i e n t o y control de la calidad (que incluyen revisiones técnicas formales y una estrategia de p r u e b a s de varios niveles); 3) prácticas efectivas d e ingeniería del s o f t w a r e (métodos y herramientas); 4) control de t o d o s los productos de trabajo del soft-

¿ Q u é e s ? N o es suficiente h a b l a r p o r h a b l a r d i c i e n d o q u e la c a l i d a d d e l s o f t w a r e e s importante. S e tiene q u e 1 ¡ definir explícitamente q u é q u i e r e decir c u a n d o d i c e " c a l i d a d del s o f t w a r e " , 2) c r e a r un c o n j u n t o d e actividad e s q u e ayudarán a asegurar q u e todo product o d e t r a b a j o d e ingenierí a del s o f t w a r e presen t a r ó a l t a c a l i d a d , 3) r e a l i z a r a c t i v i d a d e s d e control y a s e g u r a m i e n t o d e la c a l i d a d e n c o d a

p r o y e c t o d e s o f t w a r e , 4 ¡ u s a r métricas p a r a d e s a r r o l l a r e s t r a t e g i a s q u e m e j o r e n el p r o c e s o d e s o f t w a r e y, c o m o c o n s e c u e n c TM i a , la c a l i d a d del p r o d u c t o final. ' 'r,

¿ Q u i é n la h a c e ? Todos los involucrados en

PDF Editor

el o r c c e s o d e ingeniería del s o f t w a r e son resp o n s a b l e s d e la c a l i d a d .

¿Por q u é e s i m p o r t a n t e ? Es posible

h a c e r l o bien o h a c e r l o d e n u e v o o t r a v e z . Si u n e q u i p e c e s o b a r e s u b r a y a la c a l i d a d e n t o d a s

767

768

PARTE CUATRO


las actividades de ingeniería dei software, eilo reduce la cantidad de reelaboración que se d e b e realizar. Esto resulta en menores costos y, más importante, mejorará el tiempo d e llegada al mercado. ¿ C u á l e s s o n l o s p a s o s ? Antes de se que inicien las actividades de aseguramiento de la calidad del software es importante definir "calid a d def software" en diversos grados de abstracción. Una vez que entienda qué es calidad, un equipo de software d e b e identificar un conjunto de actividades SQA que filtrarán los errores d e los productos d e trabajo antes de que se aprueben.

¿Cuál e s el producto obtenido? Se crea un "Plan de aseguramiento de la calidad del

software" p a r a definir la estrategia SQA del equipo del software. Durante el análisis, diseño y generación de código el principal producto d e trabajo SQA es un breve informe de la revisión técnica formal. Durante las pruebas se producen los planes de prueba y los procedimientos. También se pueden generar otros productos de trabajo asociados con la mejora del proceso.

¿Cómo p u e d o estar seguro d e q u e lo h e h e c h o c o r r e c t a m e n t e ? ¡Encuentre los errores antes de que se conviertan en defectos! Es decir, trabaje p a r a mejorar su eficiencia en la eliminación de defectos (capítulo 22), con lo que se reduce la cantidad de reelaboración que su equipo de software tiene que realizar.

w a r e y los c a m b i o s q u e g e n e r a n (capítulo 27); 5) u n p r o c e d i m i e n t o p a r a g a r a n t i z a r la c o n c o r d a n c i a c o n los e s t á n d a r e s de d e s a r r o l l o del s o f t w a r e ( c u a n d o s e a aplicable), y 6) m e c a n i s m o s d e m e d i c i ó n e i n f o r m e . Este c a p í t u l o s e c e n t r a e n los t e m a s d e g e s t i ó n y las a c t i v i d a d e s e s p e c í f i c a s del p r o c e s o q u e p e r m i t e n a u n a o r g a n i z a c i ó n d e s o f t w a r e g a r a n t i z a r q u e h a c e las c o s a s c o r r e c t a s e n el m o m e n t o j u s t o y e n la f o r m a c o r r e c t a . 26.1

C O N C E P T O S DE C A L I D A D 1 El control de la variación

WO A A

e s el c o r a z ó n del c o n t r o l d e calidad. Un f a b r i c a n t e quiere

m i n i m i z a r la v a r i a c i ó n e n t r e los p r o d u c t o s q u e se p r o d u c e n , a u n c u a n d o h a g a algo .

CLAVE El control d e la variación es la clave pora un producto de alto calidad. En el contexto del software se lucha por controlar la variación en el proceso genérico que se oplico y el énfasis de calidad que permea el trabajo de ingeniería del software.

r e l a t i v a m e n t e s i m p l e c o m o d u p l i c a r DVD. S e g u r a m e n t e , e s t o n o p u e d e s e r u n p r o b l e m a : la d u p l i c a c i ó n d e los DVD e s u n a o p e r a c i ó n s i m p l e d e f a b r i c a c i ó n , y e s posible g a r a n t i z a r q u e s i e m p r e s e c r e e n d u p l i c a d o s e x a c t o s del s o f t w a r e . ¿Se p u e d e ? Es n e c e s a r i o a s e g u r a r s e de q u e las p i s t a s s e c o l o c a n e n l o s DVD dent r o de u n a t o l e r a n c i a e s p e c i f i c a d a d e m o d o q u e la m a y o r í a a b r u m a d o r a d e los c o n t r o l a d o r e s d e DVD p u e d a leer el m e d i o . Las m á q u i n a s d e d u p l i c a c i ó n de d i s c o s p u e d e n , y lo h a c e n , a c e p t a r y r e c h a z a r la t o l e r a n c i a . Así q u e i n c l u s o u n p r o c e s o "simple" c o m o la d u p l i c a c i ó n d e DVD p u e d e e n c o n t r a r p r o b l e m a s d e b i d o s a la variación entre muestras.

TM

¿ P e r o c ó m o s e a p l i c a e s t o al t r a b a j o d e s o f t w a r e ? ¿ C ó m o p u e d e u n a o r g a n i z a c i ó n

PDF Editor

d e d e s a r r o l l o d e s o f t w a r e n e c e s i t a r c o n t r o l a r la v a r i a c i ó n ? D e u n p r o y e c t o a o t r o se q u i e r e m i n i m i z a r la d i f e r e n c i a e n t r e los r e c u r s o s p r e d i c h o s n e c e s a r i o s p a r a c o m p l e 1

Esta sección, escrita por Michael Stovsky, ha sido adaptada de "Fundamentáis of ISO 9000", un libro de trabajo desarrollado para Esscntial Software Engineering, un video curriculum desarrollado por R S. Pressman & Associates, Inc. Reimpreso con permiso.

CAPÍTULO 26

769

GESTIÓN DE LA C A L I D A D

tar un proyecto y los recursos reales utilizados, que incluyen personal, equipo y tiempo. En general, se quisiera estar seguro de que el programa de pruebas abarca un porcentaje conocido del software, de u n a liberación a otra. No sólo se quiere minimizar el n ú m e r o de defectos que se liberan, sino que se quiere asegurar que la varianza en el n ú m e r o de bugs también se minimiza d e u n a liberación a otra. (Los clientes p r o b a b l e m e n t e se molestarán si la tercera liberación de un producto tiene diez vec e s m á s defectos que la liberación previa.) Nos gustaría minimizar las diferencias en rapidez y precisión de las r e s p u e s t a s de la línea de soporte para los p r o b l e m a s de los clientes. La lista p u e d e continuar indefinidamente.

26.1.1 Calidad El American Heritage Dictionary define calidad c o m o "una característica o atributo de algo". C o m o un atributo de un elemento, la calidad se refiere a características mensurables, es decir: c o s a s que se pueden comparar para conocer estándares, c o m o longitud, color, propiedades eléctricas y maleabilidad. Sin embargo, el software, principalm e n t e una entidad intelectual, es m á s difícil de caracterizar que los objetos físicos. No obstante, existen las mediciones de las características de un programa. Dichas propiedades incluyen complejidad ciclomática, cohesión, n ú m e r o de p u n t o s de función, líneas de código y m u c h a s o t r a s e x a m i n a d a s en el capítulo 15. C u a n d o se examina un e l e m e n t o con b a s e e n s u s características m e n s u r a b l e s se pueden e n c o n t r a r dos tipos de calidad: calidad de diseño y calidad de concordancia. La calidad de diseño se refiere a las características que los d i s e ñ a d o r e s especifican para un e l e m e n t o . La calidad de concordancia e s el grado en el que las especificacion e s de diseño se aplican durante la fabricación. "la gente olvido cuán rápido hiciste un trabajo, pero siempre recuerdan cuón bien lo hiciste." Howard Newton

En el desarrollo de software, la calidad del diseño incluye requisitos, especificaciones y el diseño del sistema. La calidad de concordancia es un tema e n f o c a d o principalmente en la implementación. Si ésta sigue el diseño y el sistema resultante satisface sus requisitos y m e t a s de d e s e m p e ñ o , la calidad d e concordancia es alta. ¿Pero la calidad del diseño y la calidad de concordancia son los únicos t e m a s q u e deben considerar los ingenieros de software? Robert Glass [GLA98] argumenta que e s conveniente una relación m á s "intuitiva TM satisfacción del usuario = producto m a n e j a b l e + buena calidad

PDF Editor + e n t r e g a d e n t r o de p r e s u p u e s t o y tiempo

En el fondo, Glass afirma que la calidad e s importante, pero si el usuario n o está s a tisfecho, nada m á s importa en realidad DeMarco [DEM99] refuerza esta visión cuando afirma: "La calidad de un producto e s j n a función de c u á n t o cambia el m u n d o para mejorar". Esta visión de la calidad afirma que si un producto de s o f t w a r e pro-

770

PARTE CUATRO


p o r c i o n a b e n e f i c i o s u s t a n c i a l a s u s u s u a r i o s finales, é s t o s e s t é n d i s p u e s t o s a tolera p r o b l e m a s o c a s i o n a l e s e n confiabilidad y d e s e m p e ñ o .

26.1.2 Control de calidad El c o n t r o l d e la v a r i a c i ó n p u e d e e q u i p a r a r s e c o n el control de calidad. Pero, ¿ c ó m : se logra el control d e calidad? Éste i n v o l u c r a la s e r i e de i n s p e c c i o n e s , r e v i s i o n e s y

? | . W i

p r u e b a s e m p l e a d a s a lo largo del p r o c e s o d e s o f t w a r e p a r a g a r a n t i z a r q u e c a d a p r :

calidad de software?

d u c t o de t r a b a j o s a t i s f a g a los r e q u i s i t o s q u e s e le h a n a s i g n a d o . El control de c a l i d a ; incluye un bucle d e r e t r o a l i m e n t a c i ó n c o n el p r o c e s o q u e c r e ó el p r o d u c t o d e t r a b a ; : La c o m b i n a c i ó n d e medición y r e t r o a l i m e n t a c i ó n p e r m i t e a f i n a r el p r o c e s o c u a n d o los p r o d u c t o s d e t r a b a j o c r e a d o s f r a c a s a n e n c u a n t o a s a t i s f a c e r s u s especificaciones. Un c o n c e p t o c l a v e del control de calidad e s q u e t o d o s los p r o d u c t o s de t r a b a j o tien e n e s p e c i f i c a c i o n e s d e f i n i d a s m e n s u r a b l e s c o n las c u a l e s se p u e d e c o m p a r a r la salida d e c a d a p r o c e s o . El b u c l e d e r e t r o a l i m e n t a c i ó n e s e s e n c i a l p a r a m i n i m i z a r los defectos producidos.

26.1.3 Garantía de la calidad La g a r a n t í a d e la c a l i d a d c o n s i s t e e n u n c o n j u n t o d e f u n c i o n e s d e a u d i t o r í a e inform a c i ó n q u e e v a l ú a n la efectividad y q u é t a n c o m p l e t a s s o n las a c t i v i d a d e s d e c o n t r a Utiles vínculos o recursos de SQA se pueden enconhor en www.qudifytree. tom/llnks/inde*. htm.

d e calidad. La m e t a del a s e g u r a m i e n t o de la calidad e s b r i n d a r l e al g e s t o r los dat os n e c e s a r i o s p a r a q u e e s t é i n f o r m a d o a c e r c a d e la calidad del p r o d u c t o , y p o r consig u i e n t e q u e c o m p r e n d a y c o n f i e e n q u e la calidad del p r o d u c t o e s t á s a t i s f a c i e n d o s u s m e t a s . D e s d e luego, si los d a t o s q u e o f r e c e el a s e g u r a m i e n t o d e la calidad identific a n p r o b l e m a s , e s r e s p o n s a b i l i d a d del g e s t o r a b o r d a r l o s y a p l i c a r los r e c u r s o s n e c e s a r i o s p a r a r e s o l v e r los c o n f l i c t o s de calidad.

26.1.4 Costo de la calidad El c o s t o de la calidad incluye t o d o s los c o s t o s q u e g e n e r a la b ú s q u e d a d e calidad o q u e d e m a n d a el d e s a r r o l l o d e las a c t i v i d a d e s r e l a c i o n a d a s c o n la calidad. Los estud i o s de c o s t o d e la c a l i d a d s e llevan a c a b o p a r a o f r e c e r u n a linea b a s e p a r a el cesto a c t u a l d e la calidad, identificar o p o r t u n i d a d e s q u e r e d u z c a n el c o s t o d e calidac \ p r o p o r c i o n a r u n a b a s e n o r m a l i z a d a d e c o m p a r a c i ó n . La b a s e d e la n o r m a l i z a d o s c a s i s i e m p r e e s m o n e t a r i a . Una v e z q u e s e h a n n o r m a l i z a d o los c o s t o s d e la c a l i d a ; s o b r e u n a b a s e m o n e t a r i a , se t i e n e n los d a t o s n e c e s a r i o s p a r a e v a l u a r d ó n d e se e r c u e n t r a n l a s o p o r t u n i d a d e s p a r a m e j o r a r los p r o c e s o s . Más t o d TM avía, se p u e d e e\aluar el e f e c t o de los c a m b i o s e n t é r m i n o s m o n e t a r i o s . Los c o s t o s d e calidad s e dividen e n c o s t o s a s o c i a d o s c o n p r e v e n c i ó n , e v a l u a c i ó n

PDF Editor ¿Cuáles

•

son los

componentes del

costo de calidad?

y fallas. Los costos de prevención

i n c l u y e n p l a n i f i c a c i ó n de la calidad, r e v i s i o n e s t e : -

n i c a s f o r m a l e s , e q u i p o de p r u e b a s y e n t r e n a m i e n t o . Los costos de evaluación

inclu-

yen a c t i v i d a d e s p a r a c o m p r e n d e r m e j o r la c o n d i c i ó n del p r o d u c t o la " p r i m e r a ve.: a t r a v é s d e " c a d a p r o c e s o . Los e j e m p l o s d e c o s t o s d e e v a l u a c i ó n incluyen i n s p e c c i : e n el p r o c e s o y e n t r e p r o c e s o s , c a l i b r a c i ó n y m a n t e n i m i e n t o de e q u i p o y p r u e b a s .

CAPÍTULO 26

771


relativo corregir Talla.

Req.

o » incurrir en -.costos tranquilo de i mersión

Diseño

Código

Des. pruebas

Pruebas O p e r a c i ó n d e sistema d e c a m p o

Los costos de fallas son aquellos que desaparecerían si no aparecieran defectos a n t e s de enviar un producto a los clientes. Estos costos se subdividen en costos de fallas internas y externas. Se incurre en los costos de fallas internas c u a n d o se detecta un defecto en el producto a n t e s del envío. Los costos de fallas internas incluyen reelaboración, reparación y análisis e n m o d o de falla. Los costos de fallas externas se asocian con defectos detectados después de que el producto ha sido enviado al cliente. Los ejemplos de costos de fallas externas son la resolución de las quejas, d e volución y r e e m p l a z o del producto, soporte de ayuda en línea y trabajo de garantía. Como se esperaba, los c o s t o s relativos para e n c o n t r a r y reparar un defecto aum e n t a n sustancialmente c o n f o r m e s e pasa de la prevención a detección y de los de falla interna a los de falla externa. La figura 26.1, b a s a d a en d a t o s recopilados por Boehm [BOE81] y otros, ilustra este f e n ó m e n o . 'Tomo menos tiempo hacer una cosa bien que explicar por qué la hiciste mal.' H. W. tongfellow

.2

G A R A N T Í A DE LA C A L I D A D DEL S O F T W A R E ( S Q . A ) Incluso los desarrolladores de s o f t w a r e m á s exhaustos estarán de a c uTM e r d o en que el s o f t w a r e de alta calidad es una m e t a importante. Pero, ¿cómo s e define calidad? Un bromista dijo una vez: "Todo programa h a c e algo bien, sólo q u e p u e d e ser la cosa

PDF Editor que no q u e r e m o s que haga".

En la bibliografía se h a n propuesto m u c h a s definiciones de la calidad del softwa-

re. En c u a n t o a los propósitos del presente texto, la calidad del software se define de la siguiente m a n e r a :

772 ¿Cómo se define la calidad del software?

PARTE CUATRO


Concordancia con los requisitos funcionales y de desempeño explícitamente establecidos, estándares de desarrollo explícitamente documentados y características implícitas que se esperan de cualquier software desarrollado profesionalmente. No hay d u d a de que esta definición p u e d e modificarse o extenderse. De hecho, la definición de calidad del s o f t w a r e podría debatirse interminablemente. En c u a n t o a lo? propósitos de e s t e libro, esta definición sirve para resaltar tres p u n t o s importantes: 1. Los requisitos de software son la b a s e de las medidas de la calidad. La falta de concordancia con los requisitos es una falta d e calidad. 2.

Los e s t á n d a r e s especificados definen un c o n j u n t o de criterios de desarrollo que guían la forma en que el s o f t w a r e se elabora. Si no se siguen los criterios, casi s e g u r a m e n t e resultará u n a falta de calidad.

3 . Con frecuencia no se m e n c i o n a un conjunto de requisitos implícito (por ejemplo, el d e s e o de uso sencillo y facilidad de mantenimiento). Si el s o f t w a r e concuerda con sus requisitos explícitos pero fracasa al satisfacer los requisitos implícitos, su calidad está en duda.

26.2.1 Algunos antecedentes El control y la garantía de la calidad son actividades esenciales e n cualquier negocie que elabore productos de c o n s u m o . Antes del siglo xx, el control de calidad era responsabilidad exclusiva del e m p r e s a r i o que fabricaba u n producto. La primera función formal de garantía y control de calidad la introdujeron los Laboratorios Bell er. 1916 y se extendió r á p i d a m e n t e a través del m u n d o industrial. Durante el decenio de 1940 se sugirieron e n f o q u e s m á s formales del control de calidad, los cuales se apoyaban e n la medición y la mejora continua de los p r o c e s o s [DEM86] c o m o los elem e n t o s clave de la gestión de la calidad. "Cometiste demosíodos malos errores." Yogi Berro En la actualidad, toda c o m p a ñ í a tiene m e c a n i s m o s que garantizan la calidad e r sus productos. De hecho, las afirmaciones explícitas de la preocupación de una compañía por la calidad se han convertido en u n a táctica de mercadotecnia durante las d é c a d a s pasadas. La historia de la garantía de la calidad en el desarrollo de s o f t w a r e a v a n z a paraTM lela a la de la calidad en la fabricación de hardware. Durante los primeros días de la computación (décadas de 1950 y 1960), la calidad era responsabilidad exclusiva de:

PDF Editor

programador. Los e s t á n d a r e s de garantía d e la calidad para el software se introdu-

jeron en los contratos militares de desarrollo de s o f t w a r e d u r a n t e el decenio de 1970 y se han extendido r á p i d a m e n t e en el desarrollo del s o f t w a r e en el m u n d o de los negocios [IEE94], Si se extiende la definición p r e s e n t a d a anteriormente, la garantía de la calidad del software es u n "patrón de acciones sistemático y planificado" [SCH98]

CAPITULO 26

773

GESTIÓN DE LA C A L I D A D

q u e s e r e q u i e r e p a r a g a r a n t i z a r alta c a l i d a d e n el s o f t w a r e . N u m e r o s o s y d i v e r s o s p a r t i c i p a n t e s t i e n e n r e s p o n s a b i l i d a d e n la g a r a n t í a d e la calidad del s o f t w a r e : i n g e n i e r o s d e s o f t w a r e , g e s t o r e s de p r o y e c t o , c l i e n t e s , v e n d e d o r e s y los i n d i v i d u o s q u e p a r t i c i p a n e n u n g r u p o d e SQA. El g r u p o d e SQA f u n c i o n a c o m o el r e p r e s e n t a n t e e n c a s a del cliente. Es decir, las p e r s o n a s q u e r e a l i z a n el SQA d e b e n o b s e r v a r el s o f t w a r e d e s d e el p u n t o d e vista del cliente. ¿El s o f t w a r e s a t i s f a c e a d e c u a d a m e n t e los f a c t o r e s d e calidad s e ñ a l a d o s e n el c a p í t u l o 15? ¿El d e s a r r o l l o d e s o f t w a r e s e h a l l e v a d o a c a b o d e a c u e r d o c o n los e s t á n d a r e s p r e e s t a b l e c i d o s ? ¿Las d i s c i p l i n a s t é c n i c a s h a n r e a l i z a d o a d e c u a d a m e n t e s u s t a r e a s c o m o p a r t e de la act i vi dad d e SQA? El g r u p o d e SQA i n t e n t a r e s p o n d e r é s t a s y o t r a s p r e g u n t a s p a r a g a r a n t i z a r q u e la c a l i d a d del s o f t w a r e s e c o n s e r v a .

26.2.2 Actividades d e SQA La g a r a n t í a d e la c a l i d a d d e s o f t w a r e s e c o m p o n e de u n a v a r i e d a d d e t a r e a s a s o c i a d a s c o n d o s i n t e g r a n t e s d i f e r e n t e s : los i n g e n i e r o s d e s o f t w a r e q u e r e a l i z a n el t r a b a jo t é c n i c o y u n g r u p o d e SQA q u e t i e n e la r e s p o n s a b i l i d a d d e planificar, s u p e r v i s a r , g u a r d a r r e g i s t r o s , a n a l i z a r y r e p o r t a r la g a r a n t í a d e calidad. L o s i n g e n i e r o s d e s o f t w a r e a b o r d a n la c a l i d a d (y r e a l i z a n a c t i v i d a d e s d e a s e g u r a m i e n t o y c o n t r o l d e calidad) al aplicar s ó l i d o s m é t o d o s y m e d i d a s t é c n i c a s , llevar a c a b o r e v i s i o n e s t é c n i c a s f o r m a l e s y d e s a r r o l l a r p r u e b a s de s o f t w a r e bien p l a n i f i c a d a s . En e s t e c a p í t u l o s ó l o s e e x a m i n a n l a s r e v i s i o n e s . Los t ó p i c o s d e t e c n o l o g í a s e t r a t a n e n las p a r t e s 1 , 2 , 3 y 5 d e e s t e libro. La m i s i ó n del g r u p o d e SQA e s auxiliar al e q u i p o d e s o f t w a r e a c o n s e g u i r u n p r o d u c t o final d e a l t a c a l i d a d . El S o f t w a r e E n g i n e e r i n g i n s t i t u t e (SE1) r e c o m i e n d a u n c o n j u n t o d e a c t i v i d a d e s d e SQA q u e a b o r d a n la p l a n i f i c a c i ó n , s u p e r v i s i ó n , c o n s e r v a ción d e registros, a n á l i s i s y e l a b o r a c i ó n d e i n f o r m e s d e a s e g u r a m i e n t o d e la calidad. D i c h a s a c t i v i d a d e s l a s r e a l i z a (o facilita) u n g r u p o d e SQA i n d e p e n d i e n t e q u e s e e n carga de las siguientes actividades:

•

¿Cuál es el

Preparar un plan d e SQA para un proyecto.

papel de un

p l a n i f i c a c i ó n del p r o y e c t o y lo revisan t o d o s los p a r t i c i p a n t e s . Las a c t i v i d a d e s d e

y v p o de SQA?

El p l a n s e d e s a r r o l l a d u r a n t e la

g a r a n t í a d e la c a l i d a d del e q u i p o d e i n g e n i e r í a del s o f t w a r e y del g r u p o d e SQA las rige el p l a n . É s t e identifica las e v a l u a c i o n e s q u e s e r e a l i z a r á n , las a u d i t o r í a s y revis i o n e s p a r a llevar a c a b o , los e s t á n d a r e s a p l i c a b l e s al p r o y e c t o , l o s p r o c e d i m i e n t o s p a r a el i n f o r m e y s e g u i m i e n t o d e e r r o r e s , los d o c u m e n t o s q u e d e b e p r o d u c i r el g r u p o d e SQA y la c a n t i d a d d e r e t r o a l i m e n t a c i ó n p r o p o r c i o n a d a al e q u i p o d e p r o y e c t o

TM

de s o f t w a r e .

P a r t i c i p a r e n e l d e s a r r o l l o d e la d e s c r i p c i ó n d e l p r o c e s o d e s o f t w a r e d e l proyecto.

El e q u i p o d e s o f t w a r e s e l e c c i o n a u n p r o c e s o p a r a el t r a b a j o q u e h a b r á

PDF Editor

d e r e a l i z a r s e . El g r u p o de SQA revisa la d e s c r i p c i ó n del p r o c e s o p a r a q u e c o n c u e r d e c o n l a s p o l í t i c a s o r g a n i z a c i o n a l e s los e s t á n d a r e s i n t e r n o s d e s o f t w a r e , los e s t á n d a r e s i m p u e s t o s d e m a n e r a e x t e r n a por e e m p l o 1 S 0 9 0 0 1 ) y o t r a s p a r t e s del plan d e p r o y e c t o del s o f t w a r e .

774

PARTE CUATRO


R e v i s a r las a c t i v i d a d e s d e ingeniería d e l s o f t w a r e para verificar q u e s e ajust e al p r o c e s o d e s o f t w a r e d e f i n i d o .

El grupo de SQA identifica, d o c u m e n t a y si-

gue las desviaciones del proceso y verifica que se hayan h e c h o las correcciones. Audita p r o d u c t o s d e trabajo d e s o f t w a r e s e l e c c i o n a d o s para verificar que s e a j u s t e n c o n l o s d e f i n i d o s c o m o p a r t e del p r o c e s o del s o f t w a r e .

El grupo

de SQA revisa los productos de trabajo seleccionados, identifica, d o c u m e n t a y sigue las desviaciones; verifica que se hayan h e c h o las correcciones; y periódicamente informa de los resultados de su trabajo al gestor del proyecto. Garantiza q u e l a s d e s v i a c i o n e s e n el trabajo d e l s o f t w a r e y e n l o s p r o d u c t o s d e trabajo e s t é n d o c u m e n t a d a s y s e m a n e j e n d e a c u e r d o c o n el p r o c e dimiento establecido.

Las desviaciones se pueden encontrar en el plan del pro-

yecto, en la descripción del proceso, en los e s t á n d a r e s aplicables o en los productos de trabajo técnicos. Registra c u a l q u i e r falta d e a j u s t e y l o i n f o r m a al g e s t o r e j e c u t i v o .

A los ele-

m e n t o s que no se ajustan se les da seguimiento hasta resolverlos. Además de estas actividades, el grupo de SQA coordina el control y la gestión de! cambio (capítulo 27) y ayuda a recopilar y analizar métricas de software.

^CONSEJO^ Las revisiones son como filtros en el flujo ¿e hoka¡o Jel pioceso de software. Muy poco y el flujo está "sucio". Demasiado y el flujo se reduce a un chorñto. Use métricas paia determinai qué revisiones funcionan y resáltelos.

Las revisiones del software son un "filtro" para el proceso de software. Esto es, las revisiones se aplican en varios p u n t o s durante la ingeniería del s o f t w a r e y sirven para descubrir errores y defectos que luego p u e d e n eliminarse. Las revisiones del softw a r e "purifican" las actividades de ingeniería del s o f t w a r e que se h a n d e n o m i n a d o análisis, diseño y codificación. Freddman y Weinberg [FRE90] abordan del m o d o siguiente la necesidad de las revisiones: El trabajo técnico necesita revisarse por la misma razón que los lápices necesitan gomas. Errar es humano. La segunda razón por la que se necesitan las revisiones técnicas es que, aunque la gente sea buena al captar algunos de sus propios errores, las grandes clases de errores escapan de su creador con más facilidad de lo que se le escapan a alguien más. Como parte de la ingeniería del s o f t w a r e se p u e d e n llevar a c a b o m u c h o s tipos de revisiones. Cada u n o tiene su lugar. Una reunión informal en torno a u n a máquina expendedora de café es u n a forma de revisión, si se e x a m i n a n losTM problemas técnicos. Una presentación formal del diseño de s o f t w a r e a un auditorio de clientes, gestores y personal técnico también es u n a forma de revisión. Sin embargo, este libro

PDF Editor

se enfoca sobre la revisión técnica formal, a veces llamada comprobación código (walkthrough)

manual del

o inspección. Una revisión técnica formal (RTF) es el filtro más

efectivo d e s d e un p u n t o d e vista de a s e g u r a m i e n t o de la calidad. Dirigida por los ingenieros de s o f t w a r e (u otras personas) para ingenieros de software, la RTF es un m e d i o efectivo para descubrir errores y mejorar la calidad del software.

CAPITULO 26

775


&

INFORMACIÓN

Bugs, errores y defectos

La meta del SQA es eliminar los problemas de calidad en el software. A estos problemas se les conoce con varios nombres: "bugs", "fallas", "errores" o 'defectos", por mencionar unos cuantos. ¿Cada uno de ést*s son términos sinónimos o existen sutiles diferencias enr e ellos? En este libro se ha hecho una clara distinción entre un e r o r (un problema de calidad descubierto antes de que el software sea liberado entre los usuarios finales) y un defecto (un problema de calidad detectado sólo después de que tí software ha sido liberado entre los usuarios finales).2 Se Ka hecho esta distinción porque los errores y defectos tienen impactos económicos, de negocios, psicológicos y huTionos muy diferentes. Como ingenieros de software se quiere descubrir y corregir tantos errores como sea posible rntes de que el cliente o usuario final los encuentre. Se quieren evitar los defectos porque (justificadamente) hacen «er mal a la gente de software.

Modelo d e amplilicación áe defecto.

Sin embargo, es importante mencionar que la distinción temporal hecha en este libro entre errores y defectos no es la tendencia predominante. El consenso general entre la comunidad de ingeniería del software es que defectos y errores, fallas y bugs son sinónimos. Es decir, el momento en que el problema se descubrió no tiene importancia en cuanto al término con que se describe el problema. Parte del argumento en favor de esta visión es que a veces es difícil distinguir con claridad entre preliberación y posliberación (por ejemplo, considérese un proceso incremental utilizado en el desarrollo ágil [capítulo 4]). Sin importar cómo se elija interpretar estos términos, reconózcase que el momento en que se descubre un problema sí importa y que los ingenieros de software deben intentar duro, muy duro, detectar los problemas antes de que los clientes y usuarios finales los encuentren. Si se tiene un interés posterior en este tema, una revisión razonablemente amplia de la terminología que rodea a los "bugs" se puede encontrar en www.softwaredevelopment.ca/bugs. shtml. y

Paso de desarrollo Defectos Detección Errores provenientes de pasos previos

Errores p a s a d o s por alto Errores a m p l i f i c a d o s 1 : x

Porcentaje d e eficiencia p a r o detección de errores

Errores que -pasan al paso siguiente

Nuevos errores g e n e r a d o s

26.3.1 Impacto de los defectos de software en el costo El o b j e t i v o p r i n c i p a l d e l a s r e v i s i o n e s t é c n i c a s f o r m a l e s e s d e s c u b r i r l o s e r r o r e s d u r a n t e el p r o c e s o , d e m o d o q u e n o s e c o n v i e r t a n e n d e f e c t o s d e s p u é s d e l i b e r a r e l s o f t w a r e . El b e n e f i c i o o b v i o d e l a s r e v i s i o n e s t é c n i c a s f o r m a l e s e s el d e s c u b r i m i e n t o t e m p r a n o d e l o s e r r o r e s d e m o d o q u e y a n o s e p r o p a g u e n al p a s o TM s i g u i e n t e e n el p r o c e s o del s o f t w a r e .

PDF Editor 2

Si se considera la mejora en el proceso de software, un problema de calidad que se propaga desde una actividad del marco de trabajo del proceso (por ejemplo, modelado) hacia otra (por ejemplo, construcción) también se puede llamar "defecto* porque el problema se debió haber descubierto antes de que un producto de trabajo (por eiemr.o ur. Tiodelo de diseño) se hubiese "liberado" hacia la actividad siguiente.

776

^CONSEJcffiEl objetivo principal de una Rlf es encontrar los errores antes de que posen a otra actividad de ingeniería del software o sean liberados ol usvario final.

PARTE CUATRO


Varios estudios industriales (realizados por TRW, NEC y Mitre Corp., entre otrosí indican que las actividades de diseño introducen entre 50 y 65 por ciento de los errores (y, a final de cuentas, de los defectos) durante el proceso de software. Sin embargo, las técnicas de revisión formal h a n m o s t r a d o hasta 75 por ciento de efectivida: [10N86] al descubrir fallos en el diseño. Al detectar y eliminar un gran porcentaje de dichos errores, el p r o c e s o de revisión reduce sustancialmente el costo de las activid a d e s s u b s e c u e n t e s en el proceso de software. Para ilustrar el impacto en el costo de la detección t e m p r a n a de errores, considérese u n a serie de costos relativos que se b a s a n en datos de costo real recopilados para g r a n d e s proyectos de software [IBM81].3 Supóngase que la corrección de uerror descubierto durante el diseño costará 1.0 unidad monetaria. En relación c o r este costo, el m i s m o error descubierto justo a n t e s de que comience el periodo de p r u e b a s costará 6.5 unidades; durante las pruebas, 15 unidades; y d e s p u é s de la liberación, entre 60 y 100 unidades.

26.3.2 Amplilicación y eliminación del defecto Se p u e d e usar un modelo de amplificación de defectos [IBM81] para ilustrar la generación y detección de errores d u r a n t e el diseño preliminar, el diseño de detalles y los p a s o s de codificación de un p r o c e s o de ingeniería del software. En la figura 26.2 se ilustra e s q u e m á t i c a m e n t e el modelo. Un recuadro representa u n p a s o de desarroi.: del software. Durante el paso, los errores se pueden generar de m a n e r a inadvertida. La revisión p u e d e fallar en descubrir errores g e n e r a d o s de m a n e r a reciente y errores de p a s o s anteriores, lo que resulta e n cierto n ú m e r o de errores que se p a s a n por alto. En algunos casos, los errores que se p a s a n por alto d e s d e p a s o s anteriores se am-

Diseño preliminar

Ampllíicación d e defecto sin revisiones.

0 0

Diseño detallado

0%

10

10 6

X

6 4 x 1.5

Pruebo c ó d i g o / u n i d a d 0%

10

25

94

20%


0 0

50%

47

1

94

25 'rueba d e validación A in Pruebo d e sistema 0 0

50%

TM 0

50%

12

0

PDF Editor

Errores l a t e n t e s

3 Aunque estos datos tienen más de 20 años de antigüedad, aún son aplicables en un contexto moderno.

CAPÍTULO 26

GESTIÓN DE

LA calidad

777

Diseño prel minar

Amplificación de defecto con revisiones.

0 0

Diseño d e t a l l a d o 70%

3

2

2

10

1.1.5 25

24

Prueba c ó d i g o / u n i d a d 50%

15 5

ü o


5 10.3

60%

24

25 Prueba d e validación

0 0

50%

~L

A in P r u e b a d e sistema

12

u

~L

0

50%

0 Errores latentes

plifican (factor de amplificación x) con el trabajo actual. Las subdivisiones de los recuadros representan cada u n a de e s t a s características y el porcentaje de eficiencia de la detección de errores, u n a función de la minuciosidad de la revisión.

i5, dicen los médicos, son fáciles de curar en sus inicios aunque difíciles de reconocer... pero en el transcurso del tiempo, cuando no han sido reconocidas a primera vista y tratadas, se vuelven fáciles de reconocer pero difíciles de curar."

La figura 26.3 ilustra un ejemplo hipotético de la amplificación del defecto para un proceso de s o f t w a r e en el que n o se llevan a c a b o revisiones. En la figura se s u p o n e q u e cada p a s o de prueba descubre y corrige, sin introducir n u e v o s errores, 50 por ciento de los errores que llegan (una suposición optimista). Diez defectos de diseño preliminar se amplificaron a 94 errores a n t e s de c o m e n z a r las pruebas. Doce defectos latentes se liberaron al campo. La figura 26.4 considera las m i s m a s condiciones excepto que la revisión del diseño y del código se llevaron a c a b o c o m o parte de c a da p a s o de desarrollo. En este caso, diez errores iniciales de diseño preliminar se amplificaron a 24 errores a n t e s de c o m e n z a r el periodo de pruebas. Sólo existen tres defectos latentes. Al considerar los costos relativos asociados con el descubrimiento y la corrección de errores se p u e d e establecer el costo global (con revisión y sin ella p a r a el ejemplo hipotético). El n ú m e r o de errores descubiertos dTM urante cada uno de los p a s o s a n o t a d o s en las figuras 26.3 y 26.4 se multiplica por el costo para elimin a r un error (1.5 unidades de c o s t o para diseño, 6.5 u n i d a d e s de c o s t o a n t e s de las

PDF Editor

pruebas, 15 unidades de c o s t o durante las pruebas, y 67 unidades de costo d e s p u é s de la liberación). Empleando e s t o s datos, el costo total para desarrollo y m a n t e n i miento es de 783 unidades c u a n d o se realizan revisiones. Si n o se realizan revisio-

n e s el costo total e s d e 2 177 unidades cas; tres veces m á s costoso.

778

PARTE CUATRO


En las revisiones un ingeniero de software debe utilizar tiempo y esfuerzo, y la organización desarrolladora, dinero. Sin embargo, los resultados del ejemplo precedente no dejan duda acerca de pagar ahora o hacerlo m á s tarde. Las revisiones técnicas formales (para el diseño y otras actividades técnicas) ofrecen un beneficio demostrable en el costo. Se deben llevar a cabo.

26.4 C u a n d o se * llevan a cabo RTF, ¿ c u á l e s son los o b j e t i v o s ?

Una revisión técnica formal (RTF) es u n a actividad de control de calidad del software que llevan a c a b o los ingenieros de software (y otros). Los objetivos de una RTF son 1) descubrir errores e n la función, lógica o implementación e n cualquier representación del software; 2) verificar que el software en revisión satisface sus requisitos; 3) garantizar que el s o f t w a r e se h a representado de acuerdo con los e s t á n d a r e s predefinidos; 4) lograr software desarrollado e n u n a m a n e r a uniforme; y 5) hacer proyectos m á s manejables. Además, la RTF sirve c o m o un c a m p o de e n t r e n a m i e n to, p u e s permite que los ingenieros m e n o s e x p e r i m e n t a d o s observen diferentes enf o q u e s respecto del análisis, el diseño y la construcción del software. La RTF también funge c o m o promotora del soporte y la continuidad, p u e s varias p e r s o n a s se familiarizan con las partes del software que de otra forma nunca verían. "No hay urgencia más grande que la que tiene un hombre por corregir el trabajo de otro." M a r k Twain

La RTF es en realidad u n a clase de revisión que incluye recorridos, inspecciones, revisiones cíclicas y otro p e q u e ñ o grupo de evaluaciones técnicas de software. Cada RTF s e realiza en u n a junta y tendrá éxito sólo si se planifica, controla y atiende apropiadamente. En las siguientes secciones se p r e s e n t a n directrices similares a las de un recorrido (por ejemplo, [FRE90], [GIL93J) que se presenta c o m o una revisión técnica formal representativa.

26.4.1 La junta d e revisión Sin importar el formato de RTF que se elija, cualquier junta de revisión debe atenerse a las siguientes restricciones: • En la revisión se deben involucrar (usualmente) entre tres y cinco personas. • Se debe preparar con anticipación, pero sin que requiera m á s de dos h o r a s de TM trabajo de cada persona. El G M M (libro fiuto de Inspección formal) de NASA SATC se puede descargar de

• La duración de la junta de revisión debe ser m e n o r a dos horas.

PDF Editor salc.gsfc.nasa.

gov/fl/fipage.

Dadas e s t a s restricciones, d e b e ser obvio que una RTF se enfoca en u n a parte específica (y pequeña) del software total. Por ejemplo, m á s que intentar revisar un diseño completo, se llevan a cabo recorridos para cada c o m p o n e n t e o grupo p e q u e ñ o de c o m p o n e n t e s . Al estrechar el enfoque, la RTF tiene u n a mayor probabilidad de descubrir errores.

CAPÍTULO 26

% CI?AVE

779


El enfoque de la RTF se dirige a u n producto de trabajo (por ejemplo, una porción de u n a especificación de requisitos, un diseño detallado de componente, u n a lista de código fuente de un componente). El individuo que ha desarrollado el producto de tra-

Uno RTF se enfoca en

b a j o —el productor—

ano porción

q u e se requiere una revisión. El jefe del proyecto se p o n e en contacto con un jefe de

-estivamente pequeña

revisión, quien evalúa la disponibilidad del producto, genera copias del material del

i¡ un producto de tobajo.

le informa al jefe del proyecto que el producto está completo y

producto y las distribuye a dos o tres revisores para q u e realicen sus observaciones a n t e s de la junta. Se espera que cada revisor e m p l e e e n t r e u n a y dos horas en revisar el producto, tomar n o t a s y familiarizarse con el trabajo. Al m i s m o tiempo, el jefe de revisión también revisa el producto y establece u n a a g e n d a para la junta de revisión, la que usualmente se p r o g r a m a para el día siguiente.

(CONSEJO^ : 1 algunos situaciones e buena idea hacer pe alguien distinto al yoductor recorra el uvducto que experim¡tn revisión. Esto induce o una interretoción literal del roducto de traba¡o y : un mejor reconoci-&ito de los errores.

A la junta de revisión asisten el jefe de revisión, todos los revisores y el productor. Uno de los revisores a s u m e el papel de registrador, es decir, el individuo que registra (por escrito) los t e m a s importantes que surjan durante la revisión. La RTF comienza con u n a presentación de la a g e n d a y una breve introducción a cargo del productor. Entonces el productor procede a recorrer el producto de trabajo y explica el material, mientras que los revisores exponen los problemas que descubrieron a n t e s de la junta. Cuando se descubren problemas o errores válidos el registrador a n o t a cada uno. Al final, todos los asistentes a la RTF deben decidir si 1) aceptan el producto sin modificaciones posteriores, 2) r e c h a z a n el producto debido a errores severos (una vez corregidos se tiene que realizar otra revisión) o 3) a c e p t a n el producto provision a l m e n t e (se encontraron errores m e n o r e s que es necesario corregir, p e r o n o se r e querirá revisión adicional). Cuando se t o m e la decisión, t o d o s los asistentes a la RTF llenan un d o c u m e n t o de finalización en el que indican su participación en la revisión y su conformidad con los hallazgos del equipo revisor.

26.4.2 Informe de la revisión y conservación d e registros Durante la RTF, un revisor (el registrador) registra a c t i v a m e n t e todos los p r o b l e m a s que hayan surgido. Éstos se r e s u m e n al final de la junta de revisión y se genera u n a lista de problemas

de revisión. Además, se llena un informe resumen de la revisión téc-

nica formal. Un informe r e s u m e n de la revisión responde tres preguntas: 1. ¿Qué se revisó? 2 . ¿Quién lo revisó? 3 . ¿Cuáles fueron los hallazgos y conclusiones?

TM

El informe r e s u m e n de la revisión es un formato de una sola página (con posibles anexos). Se vuelve parte del registro histórico del proyecto y e s posible distribuirlo

PDF Editor entre el jefe del proyecto y o t r a s partes interesadas.

La lista de problemas de la revisión cumple dos propósitos: 1) identificar á r e a s

problema e n el producto y 2) funcionar c o m o lista de verificación de e l e m e n t o s de

acción que guían al productor c o n f o r m e se hacen las correcciones. Normalmente al informe r e s u m e n se anexa u n a lista de p r o b l e m a s

780

PARTE C U A T R O


Es i m p o r t a n t e e s t a b l e c e r u n p r o c e d i m i e n t o d e s e g u i m i e n t o p a r a g a r a n t i z a r q u e los e l e m e n t o s e n la lista d e p r o b l e m a s s e h a n c o r r e g i d o a d e c u a d a m e n t e . A m e n o s q u e e s t o se h a g a , e s p o s i b l e q u e los p r o b l e m a s s u r g i d o s " c a i g a n e n t r e l a s g r i e t a s ' Un e n f o q u e c o n s i s t e e n a s i g n a r la r e s p o n s a b i l i d a d del s e g u i m i e n t o al j e f e de revisión. "A menudo una reunión es un suceso en el que se toman los minutos y se pierden las horas." Anónimo

26.4.3 Directrices d e la revisión Las directrices p a r a r e a l i z a r las r e v i s i o n e s t é c n i c a s f o r m a l e s e s n e c e s a r i o e s t a b l e c e r l a s c o n a n t i c i p a c i ó n , distribuirlas e n t r e t o d o s l o s revisores, s u s c r i b i r l a s y l u e g o seguirlas. U n a revisión d e s c o n t r o l a d a u s u a l m e n t e e s p e o r q u e c a r e c e r de u n a . Las sig u i e n t e s r e p r e s e n t a n u n c o n j u n t o m í n i m o d e d i r e c t r i c e s p a r a las r e v i s i o n e s técnicas formales: (CONSEJO^ No señale los errores de manera hiriente. Una formo de ser gentil es preguntar algo que permita al productor descubrir el error.

1.

Revisar el producto,

no al productor.

U n a RTF i n v o l u c r a p e r s o n a s y e g o s . Reali-

z a d a c o n p r o p i e d a d , la RTF d e b e d e j a r a t o d o s los p a r t i c i p a n t e s c o n u n cálido s e n t i m i e n t o de logro. Si se lleva a c a b o d e m a n e r a i n a d e c u a d a , la RTF p u e d e t o m a r u n a u r a inquisitorial. Los e r r o r e s s e d e b e n s e ñ a l a r c o n g e n t i l e z a ; el ton o d e la j u n t a d e b e s e r r e l a j a d o y c o n s t r u c t i v o ; la finalidad n o d e b e s e r a v e r gonzar o menospreciar. 2.

Establecer

una agenda y respetarla.

Un m a l clave de las j u n t a s d e c u a l q u i e r tipo

e s la d i v a g a c i ó n . U n a RTF t i e n e q u e m a n t e n e r el r u m b o y s e g u i r el p r o g r a m a . El j e f e d e revisión t i e n e la 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 el p r o g r a m a de la junta y n o vacilar e n l l a m a r la a t e n c i ó n d e la g e n t e c u a n d o s e e m p i e c e a divagar 3.

Limitar el debatey

la impugnación.

C u a n d o u n revisor p l a n t e e u n p r o b l e m a , tal

v e z n o h a y a u n a c u e r d o u n i v e r s a l s o b r e s u i m p a c t o . En l u g a r d e p e r d e r tiemp o d e b a t i e n d o la c u e s t i ó n , el p r o b l e m a s e d e b e r e g i s t r a r p a r a t r a t a r l o informalmente después. 4.

Enunciar señalado.

áreas de problemas,

pero no se intente resolver todos los que se hayan

Una revisión n o e s u n a s e s i ó n p a r a r e s o l v e r p r o b l e m a s . Esto s e d e b e

p o s p o n e r h a s t a d e s p u é s d e la j u n t a d e revisión. 5.

Tomar notas. En o c a s i o n e s e s b u e n a i d e a q u e el r e g i s t r a d o r t o m e n o t a s e n u n a

TM

p i z a r r a , d e m o d o q u e l a s p a l a b r a s y las p r i o r i d a d e s p u e d a n e v a l u a r l a s o t r o s r e v i s o r e s c o n f o r m e s e registra la i n f o r m a c i ó n .

PDF Editor 6.

Limitar el número

de participantes

e insistir en la preparación

anticipada.

D o s ca-

b e z a s p i e n s a n m e j o r q u e u n a , p e r o 14 n o n e c e s a r i a m e n t e s o n m e j o r e s q u e c u a t r o . M a n t é n g a s e el n ú m e r o d e p e r s o n a s i n v o l u c r a d a s e n el m í n i m o n e c e sario. Sin e m b a r g o , t o d o s los m i e m b r o s del e q u i p o r e v i s o r d e b e n p r e p a r a r s e p o r a n t i c i p a d o . El j e f e d e revisión d e b e solicitar c o m e n t a r i o s e s c r i t o s (lo q u e o f r e c e u n indicio de q u e el revisor h a a n a l i z a d o el material).

CAPÍTULO 2 6

781


7 . Desarrollar

una lista de verificación

de ser revisado.

para cada producto

que tenga probabilidad

U n a lista d e verificación a y u d a al j e f e d e revisión a e s t r u c t u r a r

la j u n t a d e RTF, y a c a d a r e v i s o r a e n f o c a r s e e n los p r o b l e m a s i m p o r t a n t e s . 8.

Asignar recursos y programar

las RTF. Las r e v i s i o n e s s e r á n e f e c t i v a s si s e p r o -

g r a m a n c o m o u n a t a r e a del p r o c e s o d e s o f t w a r e . A d e m á s , s e d e b e p r o g r a m a r t i e m p o p a r a r e a l i z a r l a s i n e v i t a b l e s m o d i f i c a c i o n e s q u e o c u r r i r á n c o m o result a d o d e u n a RTF. ' 9.

Realizar un entrenamiento

significativo

de todos los revisores.

Los p a r t i c i p a n t e s

e n la revisión s e r á n e f i c i e n t e s si r e c i b e n a l g ú n e n t r e n a m i e n t o f o r m a l . El e n t r e n a m i e n t o d e b e s u b r a y a r t a n t o los p r o b l e m a s r e l a c i o n a d o s c o n el p r o c e s o c o m o el l a d o p s i c o l ó g i c o y h u m a n o d e las revisiones. 10.

Analizar

las revisiones previas.

La j u n t a e s b e n e f i c i o s a p a r a d e s c u b r i r p r o b l e -

m a s e n el p r o c e s o de revisión m i s m o . El p r i m e r p r o d u c t o q u e se h a y a r e v i s a d o d e b e e s t a b l e c e r l a s directrices d e revisión. "Una de las compensaciones más hermosas de la vida es que ningún hombre puede intentar sinceramente ayudar a otro sin oyudarse a sí mismo."

Ralph Waldo Emerson

P u e s t o q u e m u c h a s v a r i a b l e s (por e j e m p l o , n ú m e r o d e p a r t i c i p a n t e s , tipo d e p r o d u c t o s d e t r a b a j o , t i e m p o y d u r a c i ó n , e n f o q u e e s p e c í f i c o d e revisión) inciden e n u n a revisión p r o v e c h o s a , u n a o r g a n i z a c i ó n de s o f t w a r e d e b e e x p e r i m e n t a r p a r a d e t e r m i n a r q u é e n f o q u e f u n c i o n a m e j o r e n u n c o n t e x t o local. Porter y s u s c o l e g a s |POR95] o f r e c e n u n a e x c e l e n t e guía p a r a e s t e tipo de e x p e r i m e n t a c i ó n .

26.4.4 Revisiones b a s a d a s en muestras En u n c o n t e x t o ideal, c a d a p r o d u c t o d e t r a b a j o d e ingeniería del s o f t w a r e d e b e r í a exp e r i m e n t a r u n a revisión t é c n i c a f o r m a l . En el m u n d o real d e los p r o y e c t o s d e s o f t w a r e , los r e c u r s o s s o n l i m i t a d o s y el t i e m p o e s corto. C o m o c o n s e c u e n c i a , u s u a l m e n t e l a s r e v i s i o n e s se s o s l a y a n , a u n q u e s e r e c o n o z c a s u v a l o r c o m o m e c a n i s m o d e control d e calidad. Thelin y s u s c o l e g a s [THEOl] a b o r d a n e s t e t e m a c u a n d o afirman: Las inspecciones [RTF] sólo son vistas como eficientes si se encuentran muchas fallas durante su búsqueda. Si en los artefactos [productos de trabajo] se encuentranTM muchas fallas, las inspecciones son necesarias. Si por otra parte, sólo se encuentran pocas fallas, la inspección ha sido una pérdida de tiempo para muchas personas involucradas en la ta-

PDF Editor

rea. 4 Más aún, los proyectos de software q - j e esian atrasados con frecuencia disminuyen el tiempo de las actividades de inspeccicr. '.o que conduce a una falta de calidad. Una so-

4

Desde luego, se puede argumentar que. a! llevar a ; = re. ; tres. se alienta a los productores a enfocarse en la calidad, incluso si no se encuendar e — t s

782

PARTE C U A T R O


lución sería asignar jerarquías a los recursos para las actividades de inspección y, en con-

ÔNSEJO^

secuencia, concentrar los recursos disponibles en los artefactos más proclives a las fallas

Las revisiones loman tiempo, peto es tiempo bien empleado. Sin embargo, si el tiempo es corto y no se tiene otra opción, no se dispensen las revisiones. ( n su lugar uÉ'cense revisiones basadas en muestms.

Thelin y s u s c o l e g a s s u g i e r e n u n p r o c e s o d e revisión b a s a d o e n q u e m u e s t r a s d e tcd o s l o s p r o d u c t o s de t r a b a j o de i n g e n i e r í a del s o f t w a r e , é s t a s s e i n s p e c c i o n a n pa-¿ d e t e r m i n a r q u é p r o d u c t o s d e t r a b a j o s o n m á s p r o c l i v e s al error. E n t o n c e s los recur s o s de las RTF c o m p l e t a s s e e n f o c a n s ó l o e n a q u e l l o s p r o d u c t o s d e t r a b a j o c o n p r : habilidad ( b a s á n d o s e e n los d a t o s r e c o p i l a d o s d u r a n t e el m u e s t r e o ) d e s e r proclives al error. Para s e r e f i c a z , el p r o c e s o d e revisión b a s a d o e n m u e s t r a s d e b e i n t e n t a r c u a n t i f c a r a q u e l l o s p r o d u c t o s d e t r a b a j o q u e s e a n o b j e t i v o s p r i n c i p a l e s p a r a las RTF corr p l e t a s . P a r a lograrlo s e s u g i e r e n l o s s i g u i e n t e s p a s o s [THE01]: 1.

I n s p e c c i o n a r u n a f r a c c i ó n a ¡ d e c a d a p r o d u c t o d e t r a b a j o d e s o f t w a r e i. Regist r e el n ú m e r o d e f a l l a s f e n c o n t r a d a s d e n t r o d e a¡.

2.

D e s a r r o l l a r u n a e s t i m a c i ó n b r u t a del n ú m e r o d e fallas d e n t r o del p r o d u c t o de t r a b a j o i al multiplicar f por 1 /a¡.

3.

O r d e n a r los p r o d u c t o s de t r a b a j o e n f o r m a d e s c e n d e n t e d e a c u e r d o c o n la est i m a c i ó n b r u t a del n ú m e r o d e fallas e n c a d a u n o .

4.

E n f o c a r los r e c u r s o s de revisión d i s p o n i b l e s e n a q u e l l o s p r o d u c t o s d e t r a b a j o c o n el m a y o r n ú m e r o e s t i m a d o d e fallas.

La f r a c c i ó n c o n la q u e s e h a h e c h o u n m u e s t r e o del p r o d u c t o d e t r a b a j o d e b e 1) ser r e p r e s e n t a t i v a del p r o d u c t o d e t r a b a j o c o m o u n t o d o , y 2) s e r lo s u f i c i e n t e m e n t e g r a n d e d e tal m a n e r a q u e s e a significativa p a r a los r e v i s o r e s q u e realicen el m u é s treo. C o n f o r m e a, a u m e n t a , la p r o b a b i l i d a d de q u e la m u e s t r a s e a u n a r e p r e s e n t a ción válida d e l p r o d u c t o d e t r a b a j o t a m b i é n c r e c e . Sin e m b a r g o , t a m b i é n a u m e n t a r los r e c u r s o s r e q u e r i d o s p a r a l e v a n t a r la m u e s t r a . Un e q u i p o de ingeniería del softw a r e d e b e e s t a b l e c e r el m e j o r v a l o r p a r a a ¡ s e g ú n l o s t i p o s d e p r o d u c t o s d e t r a b a j : producidos.5

HOGARSEGURO

Problemas en el SQA .

f I e s c e n a r i o : Oficina de Doug M¡-

La conversación:

TM

11er c u a n d o comienza el proyecto d e software HogarSeguro.

D o u g : Ya sé que n o hemos e m p l e a d o tiempo p a r a de-

L o s a c t o r e s : Doug Miller (gerente del e q u i p o d e inge-

sarrollar un plan d e S Q A p a r a este proyecto, p e r o y a

PDF Editor niería del software HogarSeguro)

y otros miembros del

e q u i p o d e ingeniería del software.

5

estamos en él y tenemos que considerar la c a l i d a d . . . ¿cierto?

Thelin y sus colegas han realizado una simulación detallada que puede ayudar a tomar esta determinación. Véase [THE01J para detalles.

CAPITULO 26

783


J a m i e : Claro. Yo hemos decidido que, conforme desa-

S h a k i r a : Leí a l g o a c e r c a d e u n a técnica d e muestren

rrollemos el modelo d e requisitos [capítulos 7 y 8], Ed se

[sección 2 6 . 4 . 4 ] q u e p u e d e a y u d a m o s o seleccionar los

no comprometido • desarrollar un procedimiento V&V

candidatos p a r a revisión. (Shakira explica el enfoque.)

p o r a c a d a requisito.

J a m i e : Tal v e z . . . p e r o no estoy s e g u r a d e q u e incluso

D o u g : Eso e s muy bueno, p e r o n o vamos a e s p e r a r has-

tengamos tiempo p a r a tomar muestras d e c a d a elemento

ta hacer las p r u e b a s p a r a evaluar la calidad, ¿ o si?

d e los modelos.

V i n o d ; ¡No! Desde luego que no. Hemos p r o g r a m a d o

V i n o d : ¿ Q u é quieres q u e h a g a m o s , Doug?

revisiones en el plan del proyecto p a r a este incremento de software. C o m e n z a r e m o s el control de calidad con las

D o u g : Robemos a l g o d e Programación Extrema [capítulo 4). Desarrollaremos los elementos d e c a d a modelo e n

revisiones. '

p a r e s —dos personas— y realizaremos u n a revisión In-

.

J a m i e : Estoy un p o c o p r e o c u p a d a d e q u e no tengamos - e m p o suficiente p a r a realizar todas las revisiones. De hecho, sé q u e n o p o d r e m o s D o u g : Mmmmm. ¿ Q u é propones?

formal d e c a d a , uno conforme a v a n c e m o s Luego seleccionaremos los elementos "cruciales" p a r a una revisión en e q u i p o más formal, p e r o conservaremos dichas revisiones e n un mínimo. De e s a forma, todo será o b s e r v a d o por m á s d e un conjunto d e ojos, p e r o a ú n asi conserva-

J a m i e : Sugiero que seleccionemos aquellos elementos

remos nuestras fechas d e entrega.

de los modelos de análisis y diseño cruciales p a r a Hogar-

J a m i e : Eso significa q u e tendremos q u e revisar la calen-

Seguro y que los revisemos

darización.

V i n o d : ¿Pero q u é ocurre si p e r d e m o s a l g o en una parte

D o u g : Así d e b e ser. La calidad triunfa sobre la calenda-

¡el m o d e lo que no revisemos?

rización en este proyecto.

26,5

E N F O Q U E S FORMALES ACERCA PEL S & A D u r a n t e las d o s d é c a d a s p a s a d a s , un p e q u e ñ o , p e r o ruidoso, s e g m e n t o d e la c o m u nidad de ingeniería del s o f t w a r e h a a r g u m e n t a d o q u e s e requiere un e n f o q u e m á s formal de la garantía de la calidad del software. Se p u e d e a r g u m e n t a r que un prog r a m a d e c o m p u t a d o r a e s un objeto m a t e m á t i c o [SOMOl]. En c a d a lenguaje d e prog r a m a c i ó n s e definen u n a sintaxis y u n a s e m á n t i c a rigurosas, y existe un e n f o q u e rig u r o s o r e s p e c t o d e la especificación d e requisitos d e s o f t w a r e (capítulo 28). Si el m o d e l o d e requisitos (especificación) y el lenguaje d e p r o g r a m a c i ó n s e r e p r e s e n t a n en u n a f o r m a rigurosa, deb e ser posible aplicar p r u e b a s m a t e m á t i c a s de exactitud para d e m o s t r a r q u e un p r o g r a m a c o n c u e r d a e x a c t a m e n t e c o n s u s especificaciones. Los i n t e n t o s e n c a m i n a d o s a p r o b a r la exactitud de los p r o g r a m a s (capítulos 28 y 29) n o s o n n u e v o s . Dijkstra [D1J76] y Linger, Mills y Witt [L1N79], e n t r e otros, a c o n s e j a r o n p r u e b a s de exactitud d e p r o g r a m a y los vincularon c o n la aplicación d e c o n TM c e p t o s d e p r o g r a m a c i ó n e s t r u c t u r a d a (capitulo II).

PDF Editor 26.6

G A R A N T Í A P E LA C A L I D A ? E S T A D Í S T I C A DEL S O F T W A R E La garantía d e la calidad estadística refleja u n a t e n d e n c i a , creciente e n la industria, por a d o p t a r un e n f o q u e m á s cuantitativo a c e r c a d e la calidad. Para el s o f t w a r e , la garantía d e la calidad estadística implica ios p a s o s siguientes:

784 ¿Qué posos se requieren para realizar SQA estadístico?

•

PARTE C U A T R O


1.

La i n f o r m a c i ó n a c e r c a d e l o s d e f e c t o s d e s o f t w a r e s e r e c o p i l a y clasifica.

2.

Se i n t e n t a d e t e r m i n a r la c a u s a s u b y a c e n t e d e c a d a d e f e c t o (por e j e m p l o , falta de c o n c o r d a n c i a c o n l a s e s p e c i f i c a c i o n e s , e r r o r e s d e d i s e ñ o , violación d e est á n d a r e s , d e f i c i e n t e c o m u n i c a c i ó n c o n el cliente).

3.

M e d i a n t e el principio d e P a r e t o (80 p o r c i e n t o d e los d e f e c t o s s e e n c u e n t r a e n 2 0 p o r c i e n t o d e t o d a s l a s c a u s a s posibles) s e aisla u n 2 0 p o r c i e n t o (los "vitales").

4.

Una vez q u e las c a u s a s vitales h a n sido identificadas, se corrigen los problem a s que h a n provocado los defectos.

Este c o n c e p t o r e l a t i v a m e n t e s i m p l e r e p r e s e n t a u n p a s o i m p o r t a n t e h a c i a la c r e a c i ó n d e u n p r o c e s o d e s o f t w a r e a d a p t a b l e e n el q u e los c a m b i o s s e h a g a n p a r a m e j o r a r a q u e l l o s e l e m e n t o s del p r o c e s o q u e i n t r o d u c e n e r r o r e s .

"20 por tiento del código tiene 80 por ciento de los errores. ¡Encuéntrelos, corrijnlos!"

Lowell Arthur

26.6.1 Un ejemplo genérico Para ilustrar la a p l i c a c i ó n d e los m é t o d o s e s t a d í s t i c o s e n el t r a b a j o d e i n g e n i e r í a del s o f t w a r e , s u p ó n g a s e q u e u n a o r g a n i z a c i ó n d e i n g e n i e r í a del s o f t w a r e r e c o p i l a información acerca de defectos durante un año. Algunos de los defectos s e descubren c u a n d o el s o f t w a r e e s t á e n d e s a r r o l l o ; o t r o s , d e s p u é s d e q u e s e h a l i b e r a d o e n t r e s u s u s u a r i o s finales. A u n q u e se d e s c u b r e n c i e n t o s d e d i f e r e n t e s d e f e c t o s , t o d o s t i e n e n u n a (o m á s ) d e l a s c a u s a s s i g u i e n t e s : • E s p e c i f i c a c i o n e s i n c o m p l e t a s o e r r ó n e a s (E1E). • Mala i n t e r p r e t a c i ó n d e la c o m u n i c a c i ó n del cliente (MCC). • D e s v i a c i ó n i n t e n c i o n a l de l a s e s p e c i f i c a c i o n e s (DIE). • Violación d e l o s e s t á n d a r e s de p r o g r a m a c i ó n (VEP). • E r r o r e s e n la r e p r e s e n t a c i ó n d e los d a t o s (ERD). • I n t e r f a z d e c o m p o n e n t e i n c o n s i s t e n t e (ICI). • Error e n la lógica d e l d i s e ñ o (ELD). • P r u e b a i n c o m p l e t a o e r r ó n e a (PIE).

TM

• D o c u m e n t a c i ó n i m p r e c i s a o i n c o m p l e t a (DII). • Error e n la t r a d u c c i ó n del d i s e ñ o al l e n g u a j e d e p r o g r a m a c i ó n (TLP).

PDF Editor • I n t e r f a z h o m b r e - c o m p u t a d o r a a m b i g u a o i n c o n s i s t e n t e (IHC). • M i s c e l á n e o (MIS).

Para a p l i c a r el a s e g u r a m i e n t o d e la c a l i d a d e s t a d í s t i c a del s o f t w a r e s e c o n s t r u y e la tabla d e la figura 26.5. La tabla indica q u e EIE, MCC y ERD s o n las c a u s a s v i t a l e s q u e

CAPÍTULO 26

Toral Error

785


Serios

Moderados

Núm

%

Núm

%

Núm

EIE

205

22%

34

27%

MCC

156

17%

12

9%

0IE

48

5%

1

VEP

25

3%

ERD

130

ICI

Menores %

Núm

%

68

18%

103

24%

68

18%

76

17%

1%

24

6%

23

5%

0

0%

15

4%

10

2%

14%

26

20%

68

18%

36

8%

58

6%

9

7%

18

5%

31

7%

ELD

45

5%

14

11%

12

3%

19

4%

PIE

95

10%

12

9%

35

9%

48

11%

CH1

36

4%

2

2%

20

5%

14

3%

TIP

60

6%

15

12%

19

5%

26

6%

IHC

28

3%

3

2%

17

4%

8

M!S_

^56

_£>%

_ 2

_Q%

_L£

_4%

Tolo les

942

100%

128

100%

379

100%

2% _9%

435

100%

explican el 53 p o r c i e n t o d e t o d o s los e r r o r e s . Sin e m b a r g o , s e d e b e o b s e r v a r q u e EIE, ERD, TLP y ELD s e s e l e c c i o n a r í a n c o m o las c a u s a s v i t a l e s si s ó l o s e c o n s i d e r a r a n los e r r o r e s s e r i o s . U n a v e z d e t e r m i n a d a s las c a u s a s vitales, la o r g a n i z a c i ó n d e i n g e n i e r í a del s o f t w a r e p u e d e c o m e n z a r la a c c i ó n correctiva. Por e j e m p l o , p a r a c o rregir MCC, el d e s a r r o l l a d o r d e s o f t w a r e p u e d e i m p l e m e n t a r t é c n i c a s q u e faciliten la r e c o p i l a c i ó n d e r e q u i s i t o s (capítulo 7) p a r a m e j o r a r la c a l i d a d d e la c o m u n i c a c i ó n y las e s p e c i f i c a c i o n e s del cliente. Para m e j o r a r ERD, el d e s a r r o l l a d o r p u e d e adquirir h e r r a m i e n t a s p a r a el m o d e l a d o d e d a t o s y e j e c u t a r r e v i s i o n e s d e d i s e ñ o d e d a t o s m á s rigurosas. Es i m p o r t a n t e a n o t a r q u e la a c c i ó n correctiva s e e n f o c a p r i n c i p a l m e n t e e n l a s vitales. C o n f o r m e é s t a s s e c o r r i g e n , n u e v a s c a n d i d a t a s o c u p a n la p a r t e s u p e r i o r de la clasificación. Las t é c n i c a s de g a r a n t í a e s t a d í s t i c a d e la calidad p a r a s o f t w a r e h a n d e m o s t r a d o q u e o f r e c e n u n a m e j o r a s u s t a n c i a l e n la calidad [ART97], En a l g u n o s c a s o s , las org a n i z a c i o n e s d e s o f t w a r e h a n a l c a n z a d o 5 0 p o r c i e n t o d e r e d u c c i ó n a n u a l e n los d e fectos d e s p u é s de aplicar estas técnicas. La a p l i c a c i ó n del SQA e s t a d í s t i c o y el principio de P a r e t o s e p u e d e n r e s u m i r e n u n a sola o r a c i ó n : Emplee su tiempo enfocándose ¡pero primero

asegúrese

de entender

en las cosas que realmente TM

qué es lo que realmente

importan,

importaí

Un d e t a l l a d o a n á l i s i s del SQA e s t a d í s t i c o e s t á m á s allá del á m b i t o de e s t e libro.

PDF Editor Los l e c t o r e s i n t e r e s a d o s d e b e n c o n s u l t a r [GOH02], [SCH98] o [KAN95],

26.6.2 Seis sigma p a r a ingeniería del software

Seissigma

e s la e s t r a t e g i a m á s a m p l i a m e n t e e - o l e a d a e n la a c t u a l i d a d p a r a el a s e -

g u r a m i e n t o d e la calidad e s t a d í s t i c o e n !a i n d u s t r i a . O r i g i n a l m e n t e p o p u l a r i z a d a p o r

786

PARTE C U A T R O


Motorola e n el d e c e n i o de 1980, la e s t r a t e g i a s e i s s i g m a " e s u n a m e t o d o l o g í a rigurosa y di s ci pl i nad a q u e utiliza a n á l i s i s d e d a t o s y e s t a d í s t i c o p a r a m e d i r y m e j o r a r e d e s e m p e ñ o o p e r a t i v o d e u n a c o m p a ñ í a al i d e n t i f i c a r y e l i m i n a r los ' d e f e c t o s ' e n la f a b r i c a c i ó n y los p r o c e s o s r e l a c i o n a d o s c o n el servicio" [ISI03). El t é r m i n o "seis sigm a " s e d e r i v a d e s e i s d e s v i a c i o n e s e s t á n d a r —3.4 i n s t a n c i a s (defectos) p o r m i l l ó n de o c u r r e n c i a s — , lo q u e implica u n e s t á n d a r d e c a l i d a d e x t r e m a d a m e n t e e l e v a d o . La metodología seis sigma define tres p a s o s centrales: ¿Cuáles son

• Definir los r e q u i s i t o s del cliente, e n t r e g a b l e s y m e t a s del p r o y e c t o p o r m e d i o

•

los posos centrales de lo metodología seis

d e m é t o d o s b i e n d e f i n i d o s d e c o m u n i c a c i ó n c o n el cliente. *

sigma?

M e

"

, r e

' p r o c e s o e x i s t e n t e y s u salida p a r a d e t e r m i n a r el d e s e m p e ñ o d e cali-

d a d a c t u a l (recopilación d e m é t r i c a s de d e f e c t o ) . • Analizar

las m é t r i c a s d e d e f e c t o y d e t e r m i n a r l a s c a u s a s p o c o vitales.

Si u n p r o c e s o d e s o f t w a r e e x i s t e n t e e s t á e n m a r c h a , p e r o s e r e q u i e r e m e j o r í a , seis sigma sugiere dos p a s o s adicionales: • Mejorar el p r o c e s o e l i m i n a n d o las c a u s a s o r i g i n a l e s d e los d e f e c t o s . • Controlar el p r o c e s o p a r a g a r a n t i z a r q u e el t r a b a j o f u t u r o n o v u e l v a a introducir las c a u s a s d e d e f e c t o s . E sto s p a s o s c e n t r a l e s y a d i c i o n a l e s a v e c e s s e c o n o c e n c o m o el m é t o d o DMAMC (definir, medir, a n a l i z a r , m e j o r a r y c o n t r o l a r ) . Si u n a o r g a n i z a c i ó n e s t á d e s a r r o l l a n d o u n p r o c e s o d e s o f t w a r e (en l u g a r de m e j o r a r u n p r o c e s o e x i s t e n t e ) , los p a s o s c e n t r a l e s s e a u m e n t a n d e la s i g u i e n t e m a n e ra: • Diseñar el p r o c e s o p a r a 1) e v i t a r l a s c a u s a s o r i g i n a l e s d e l o s d e f e c t o s y 2) s a t i s f a c e r los r e q u i s i t o s del cliente. • Verificar q u e el m o d e l o d e p r o c e s o , d e h e c h o , e v i t a r á los d e f e c t o s y s a t i s f a r á l o s r e q u i s i t o s del cliente. A e s t a v a r i a c i ó n a v e c e s s e le l l a m a m é t o d o DMADV (definir, medir, a n a l i z a r , dise ñ a r y verificar). U n a e x p o s i c i ó n d e t a l l a d a d e s e i s s i g m a s e e n c u e n t r a e n l a s f u e n t e s bibliográficas d e d i c a d a s a la m a t e r i a . El lector i n t e r e s a d o d e b e c o n s u l t a r [ISI03], [SNE03] y [PAN00].

TM 26.7

f l f t B I H P A P PEL SOFTWARE

PDF Editor

La fiabilidad del s o f t w a r e , a d i f e r e n c i a d e o t r o s f a c t o r e s d e c a l i d a d , s e p u e d e medir

dirigir y e s t i m a r e m p l e a n d o d a t o s h i s t ó r i c o s y d e d e s a r r o l l o . La fiabilidad del software s e d e f i n e e n t é r m i n o s e s t a d í s t i c o s c o m o "la p r o b a b i l i d a d d e la o p e r a c i ó n libre de fallas d e un p r o g r a m a de c o m p u t a d o r a e n u n e n t o r n o e s p e c í f i c o d u r a n t e u n t i e m p o

e s p e c í f i c o " [MUS87]. C o n fines ilustrativos, s e e s t i m a q u e el p r o g r a m a X t i e n e u n a

CAPÍTULO 26

fiabilidad

787


d e 0,96 d u r a n t e u n p e r i o d o de o c h o h o r a s de p r o c e s a m i e n t o . En o t r a s p a -

l a b r a s , si el p r o g r a m a X f u e s e e j e c u t a d o 100 v e c e s y r e q u i r i e s e un total d e o c h o hor a s de t i e m p o d e p r o c e s a m i e n t o (tiempo de e j e c u c i ó n ) , e s p r o b a b l e q u e o p e r a r í a c o r r e c t a m e n t e (sin falla) 9 6 v e c e s . "El precio inevitable de ID fiabilidad es la simplicidad."

C.A.R. Honre S i e m p r e q u e s e e s t u d i a la fiabilidad del s o f t w a r e , s u r g e u n a p r e g u n t a c e n t r a l : ¿ q u é significa el t é r m i n o falla? En el c o n t e x t o de c u a l q u i e r a n á l i s i s d e calidad y fiabilidad del s o f t w a r e , la falla e s la falta de c o n c o r d a n c i a c o n los r e q u i s i t o s del s o f t w a r e . Sin e m b a r g o , i n c l u s o d e n t r o de e s t a definición, e x i s t e n g r a d i e n t e s . Las fallas s ó l o p u e d e n s e r m o l e s t a s y c a t a s t r ó f i c a s . U n a falla p u e d e c o r r e g i r s e e n s e g u n d o s , m i e n t r a s q u e o t r a tal v e z r e q u i e r a s e m a n a s o i n c l u s o m e s e s . Para c o m p l i c a r el t e m a a ú n m á s , la c o r r e c c i ó n de u n a falla p u e d e , de h e c h o , r e s u l t a r e n la i n t r o d u c c i ó n d e o t r o s e r r o r e s q u e a final d e c u e n t a s r e s u l t a n e n o t r a s fallas.

26.7.1 Medidas de Habilidad y disponibilidad Los p r i m e r o s t r a b a j o s e n la fiabilidad del s o f t w a r e i n t e n t a r o n e x t r a p o l a r l a s m a t e m á ticas de la teoría d e fiabilidad del h a r d w a r e (por e j e m p l o , [ALV64]) a la predicción de

c f o v E sde í casi siempre i seguirse o s en diseño o

la fiabilidad del s o f t w a r e . La m a y o r í a de los m o d e l o s d e fiabilidad r e l a c i o n a d a c o n el h a r d w a r e t r a t a n a c e r c a de las fallas d e b i d a s al u s o m á s q u e a l a s q u e s e d e b e n a def e c t o s d e d i s e ñ o . En el h a r d w a r e , l a s fallas q u e s e d e b e n al u s o físico (por e j e m p l o , los e f e c t o s de la t e m p e r a t u r a , la c o r r o s i ó n , l o s c h o q u e s eléctricos) s o n m á s p r o b a b l e s q u e u n a falla r e l a c i o n a d a c o n el d i s e ñ o . D e s d i c h a d a m e n t e , lo o p u e s t o e s cierto p a r a el s o f t w a r e . De h e c h o , t o d a s las fallas d e s o f t w a r e s e o r i g i n a n e n p r o b l e m a s d e d i s e ñ o o i m p l e m e n t a c i ó n , el u s o (capítulo 1) n o e n t r a e n el c u a d r o . Ha h a b i d o d e b a t e s a c e r c a d e la relación e n t r e c o n c e p t o s c l a v e e n la fiabilidad del h a r d w a r e y s u aplicabilidad al s o f t w a r e (por e j e m p l o , [LIT89], [ R 0 0 9 0 ] ) . A u n q u e t o d a v í a s e t i e n e q u e e s t a b l e c e r u n v í n c u l o irrefutable, v a l e la p e n a c o n s i d e r a r u n o s cuantos conceptos simples que se aplican a elementos de a m b o s sistemas. Si s e c o n s i d e r a u n s i s t e m a b a s a d o e n c o m p u t a d o r a , u n a s i m p l e m e d i d a d e fiabi-

tVE

lidad e s el tiempo medio entre fallas (TMEF), d o n d e TMEF = TMDF + TMDR

s notar F y los s reiocionodos sen

i

x CPU, no en

Las s i g l a s TMDF y TMDR significan tiempo medio de falla y tiempo medio ción, r e s p e c t i v a m e n t e . 6

TM

M u c h o s i n v e s t i g a d o r e s a r g u m e n t a n q u e el TMEF e s c o n m u c h o m á s fácil d e m e -

PDF Editor i * reloj de

de repara-

dir q u e los d e f e c t o s / K L D C o los d e f e c t o s / P F . E s t a b l e c i d o d e m a n e r a simple, el u s u a rio final e s t á p r e o c u p a d o p o r las fallas, n o p o r el c o n t e o total d e e r r o r e s . D e b i d o a 6

Aunque se pueda requerir la depuración iy correcosnes relacionadas) como consecuencia de una falla, en muchos casos el software trabajara adecuadamente después de un reinicio sin otro cambio.

788

fcWWJO^ Algunos aspectos de la disponibilidad (no estudiados aquí) no tienen nada que ver con las follas. Por ejemplo, los recortes en la calendaiización (para funciones de soporte) provocan que el software no esté disponible.

PARTE CUATRO


que cada defecto contenido dentro de u n p r o g r a m a no tiene la misma tasa de falla, la cuenta de defectos totales ofrece poca información de la Habilidad del sistema. A d e m á s de u n a medida de fiabilidad, se d e b e desarrollar una medida de disponibilidad. La disponibilidad

del software es la probabilidad de que u n programa opere

de acuerdo con los requisitos en un p u n t o d a d o del tiempo, y se define c o m o Disponibilidad = [TMDF/(TMDF + TMDR)] x 100% La medida de fiabilidad TMEF es igualmente sensible a TMDF y TMDR. La medida de disponibilidad e s un poco m á s sensible a TMDR, y es una medida indirecta de la facilidad de m a n t e n i m i e n t o del software.

26.7.2 Seguridad del software La seguridad de! software [LEV86] es u n a actividad de a s e g u r a m i e n t o de la calidad de software que se e n f o c a e n la identificación y evaluación de los peligros potenciales que p u e d e n afectar n e g a t i v a m e n t e al software y provocar u n a falla de todo el sistema. Si los peligros se p u e d e n identificar t e m p r a n o e n el proceso d e software, las características de diseño de software se pueden especificar de m o d o que eliminarán c controlarán los peligros potenciales. "No puedo imaginar alguna condición que provoque que este barco se hunda. La industria naviera moderna ha ido más altó."

E. I. Smith, capitán del Titonk Como parte de la seguridad del software s e llevan a c a b o procesos de modeladc y análisis. Inicialmente, los peligros se identifican y clasifican por importancia y riesgo. Por ejemplo, algunos de los peligros asociados con un control b a s a d o en computadora para la conducción de un automóvil p u e d e n ser-, • Provoca aceleración descontrolada que no se p u e d e detener. • No responde a la presión del pedal de f r e n o (al apagarlo). • No responde c u a n d o el interruptor se activa. • Pierde o gana rapidez lentamente. Una vez identificados estos peligros en el nivel del sistema, m e d i a n t e técnicas de análisis se asignan severidad y probabilidad de ocurrencia. 7 Para ser eficaz, el software d e b e analizarse e n el contexto de todo el sistema. Por ejemplo, un sutil error TM de e n t r a da de usuario (las p e r s o n a s s o n c o m p o n e n t e s del sistema) tal vez lo magnifique u n a falla del software para producir d a t o s de control que posicionan de m a n e -

PDF Editor

ra i n a d e c u a d a un dispositivo mecánico. Si se reúne un conjunto d e condiciones am7 Este enfoque es similar a los métodos de análisis de riesgo descritos en el capítulo 25. La diferencia principal es el énfasis en los contlictos tecnológicos, más que en los tópicos relacionados con el proyecto.

CAPÍTULO 26

789


b i e n t a l e s e x t e r n a s (y s ó l o si ellas s e r e ú n e n ) , la p o s i c i ó n i n a d e c u a d a del dispositivo Jno colección d i o s o de ensayos aceita de itSurkWde software * puede encontrar en

m e c á n i c o p r o v o c a r á u n a falla d e s a s t r o s a . Las t é c n i c a s de análisis, c o m o el a n á l i s i s

www.safeware«g.com/.

peligros y la p r o b a b i l i d a d de q u e c a d a u n o de los e v e n t o s ocurrirá p a r a c r e a r la c a -

del árbol d e fallas [VES81), la lógica de t i e m p o real [JAN86] o l o s m o d e l o s de red d e Petri [LEV87], s e e m p l e a n p a r a p r e d e c i r la c a d e n a de e v e n t o s q u e p u e d e n p r o v o c a r dena. U n a v e z i d e n t i f i c a d o s y a n a l i z a d o s los peligros, se e s p e c i f i c a n los r e q u i s i t o s relac i o n a d o s c o n la s e g u r i d a d del s o f t w a r e . E s t o e s , la e s p e c i f i c a c i ó n p u e d e c o n t e n e r u n a lista d e e v e n t o s i n d e s e a b l e s y las r e s p u e s t a s d e s e a b l e s del s i s t e m a a n t e d i c h o s e v e n t o s . E n t o n c e s se indica el p a p e l del s o f t w a r e e n la g e s t i ó n d e los e v e n t o s i n d e seables. A u n q u e la c o n f i a b i l i d a d del s o f t w a r e y su s e g u r i d a d e s t á n e s t r e c h a m e n t e relacion a d a s , e s i m p o r t a n t e e n t e n d e r las sutiles d i f e r e n c i a s e n t r e ellas. La confiabilidad del s o f t w a r e utiliza análisis e s t a d í s t i c o p a r a d e t e r m i n a r la p r o b a b i l i d a d d e q u e o c u r r i r á u n a falla del s o f t w a r e . Sin e m b a r g o , el h e c h o de q u e o c u r r a u n a falla n o n e c e s a r i a m e n t e r e s u l t a e n u n p e l i g r o o p e r c a n c e . La s e g u r i d a d del s o f t w a r e e x a m i n a las form a s e n l a s c u a l e s las fallas r e s u l t a n e n c o n d i c i o n e s q u e p u e d e n c o n d u c i r a u n p e r c a n c e . Esto es, las fallas n o s o n c o n s i d e r a d a s e n el vacío, s i n o q u e s e e v a l ú a n e n el c o n t e x t o de t o d o un s i s t e m a b a s a d o e n c o m p u t a d o r a y e n s u e n t o r n o . A q u e l l o s lect o r e s c o n m a y o r i n t e r é s d e b e n r e m i t i r s e al libro de L e v e s o n [LEV95] p a r a p r o f u n d i z a r e n el t e m a .

DE C A L I D A D I S O

K

Es p o s i b l e definir u n sistema

900Q

8

de garantía de la calidad c o m o la e s t r u c t u r a o r g a n i z a c i o -

nal, r e s p o n s a b i l i d a d e s , p r o c e d i m i e n t o s , p r o c e s o s y r e c u r s o s p a r a i m p l e m e n t a r la

CÚVVE

k 9000 describe lo E se debe bocer pora r Tmejable, pero no ¡ cómo se debe

g e s t i ó n d e la c a l i d a d [ANS87]. Los s i s t e m a s d e g a r a n t í a d e calidad f u e r o n c r e a d o s p a r a a y u d a r a las o r g a n i z a c i o n e s a g a r a n t i z a r q u e s u s p r o d u c t o s y servicios s a t i s f a c e n l a s e x p e c t a t i v a s de los c l i e n t e s al c u m p l i r s u s e s p e c i f i c a c i o n e s . El e s t á n d a r ISO 9000 d e s c r i b e un s i s t e m a d e g a r a n t í a d e la calidad en t é r m i n o s g e n é r i c o s q u e s e aplic a n a c u a l q u i e r n e g o c i o sin i m p o r t a r los p r o d u c t o s o s e r v i c i o s o f r e c i d o s . El registro e n u n o d e los m o d e l o s de s i s t e m a d e g a r a n t í a de la calidad c o n t e n i d o s e n ISO 9 0 0 0 r e q u i e r e q u e los s i s t e m a s y o p e r a c i o n e s de calidad d e u n a c o m p a ñ í a los s o m e t a n a escrutinio auditores de una tercera entidad respecto de su concordancia c o n el e s t á n d a r y d e su f u n c i o n a m i e n t o e f i c a z . A n t e s del registro exitoso, los a u d i -

TM

t o r e s le e x t i e n d e n a la c o m p a ñ í a u n c e r t i f i c a d o d e la o r g a n i z a c i ó n d e registro q u e r e p r e s e n t a n . Entrevistas de a u d i t o r í a s e m i a n u a l e s g a r a n t i z a n la c o n c o r d a n c i a conti-

PDF Editor n u a c o n el e s t á n d a r .

8

Esta sección, escrita por Michael Stovsky se ha adaptado de "Fundamentáis of ISO 9000", un libro de trabajo desarrollado por EssentialSor.-, ore un video curriculum elaborado por R. S. Pressman & Associates, Inc. Reimpreso ccr. petir-iso

790

PARTE CUATRO


Referencia Web

El e s t á n d a r d e g a r a n t í a d e la calidad q u e s e a p l i c a a la i n g e n i e r í a del s o f t w a r e es

Extensos vínculos hocki

el ISO 9001:2000. El e s t á n d a r c o n t i e n e 2 0 r e q u i s i t o s q u e d e b e n e s t a r p r e s e n t e s par=

fecwsos ISO

9 0 0 0 / 9 0 0 1 se pueden encaitroi en www.tantara.ab. ca/info.htm.

u n s i s t e m a e f i c i e n t e d e g a r a n t í a d e la calidad. P u e s t o q u e el e s t á n d a r ISO 9001:200C e s a p l i c a b l e a t o d a s las d i s c i p l i n a s d e i n g e n i e r í a , s e h a d e s a r r o l l a d o u n c o n j u n t o esp e c i a l de d i r e c t r i c e s ISO (ISO 9000-3) q u e a y u d a n a i n t e r p r e t a r el e s t á n d a r p a r a emp l e a r l o e n el p r o c e s o d e s o f t w a r e . Los r e q u i s i t o s q u e d e l i n e a ISO 9001:2000 a b o r d a n t ó p i c o s c o m o r e s p o n s a b i l i d a c d e la g e s t i ó n , s i s t e m a de calidad, revisión d e c o n t r a t o , c o n t r o l d e d i s e ñ o , control de d o c u m e n t o s y d a t o s , identificación y s e g u i m i e n t o de p r o d u c t o , control de p r o c e s o i n s p e c c i ó n y p r u e b a s , a c c i o n e s c o r r e c t i v a s y p r e v e n t i v a s , c o n t r o l d e r e g i s t r o s de calidad, a u d i t o r í a s de c a l i d a d i n t e r n a , e n t r e n a m i e n t o , servicio y t é c n i c a s e s t a d í s t i c a s Una o r g a n i z a c i ó n d e s o f t w a r e o b t e n d r á el r e g i s t r o ISO 9 0 0 1 : 2 0 0 0 si e s t a b l e c e polític a s y p r o c e d i m i e n t o s p a r a a b o r d a r c a d a u n o d e los r e q u i s i t o s a n o t a d o s l í n e a s arriba (y otros) y, a d e m á s , s e r c a p a z d e d e m o s t r a r q u e s e s i g u e n d i c h a s p o l í t i c a s y p r o c e d í m i e n t o s . Para m a y o r i n f o r m a c i ó n a c e r c a d e ISO 9001, el lector i n t e r e s a d o d e b e c o n sultar [HOYQ2], [GAA01] O [CIA01].

INFORMACIÓN a estándar

ISO 9001:2000

Las siguientes líneas generales definen los elementos básicos del estándar ISO 9 0 0 1 : 2 0 0 0 . Información más amplia acerca del estándar se p u e d e obtener de International Organization for Standardization (www.iso.cK) y e n otras fuentes d e Internet (por e j e m p l o , www.praxiom.com).

Establecer los elementos de un sistema de gestión de calidad.

Definir un plan d e calidad q u e a b o r d e objetivos, responsabilidades y autoridad. Definir mecanismos d e comunicación entre los participantes. Establecer mecanismos d e revisión p a r a el sistema d e gestión de calidad. Identificar métodos d e revisión y mecanismos d e retroalimentación.

Desarrollar, implementar y mejorar el sistema.

Definir procedimientos d e seguimiento.

Definir una política que enfatice la importancia del siste-

Identificar recursos d e calidad que incluyan personal,

ma. Documentar el sistema d e calidad.

entrenamiento, elementos d e infraestructura. Establecer mecanismos d e control.

Describir el proceso.

Para planeación.

Producir un manual operativo.

Para requisitos del cliente.

Desarrollar métodos p a r a controlar (actualizar) los docu-

Para actividades técnicas (por ejemplo, análisis, diseño,

mentos.

TM

pruebas).

PDF Editor Establecer métodos p a r a la conservación d e registros.

Soporte del control y la garantía de calidad.

Promover la importancia d e la calidad entre todos los participantes.

,

Enfocarse en la satisfacción del cliente.

Para supervisión y gestión del proyecto.

Definir métodos p a r a corrección.

Valorar los datos y métricas d e calidad. Definir enfoques p a r a procesos continuos y mejora d e la calidad.

,

CAPÍTULO 26

2 6 . 9

791


E L P L A N DE S Q A El plan de SQA p r o p o r c i o n a un m a p a p a r a instituir la g a r a n t í a d e la c a l i d a d del s o f t w a r e . D e s a r r o l l a d o p o r el g r u p o d e SQA (o el e q u i p o d e s o f t w a r e si n o e x i s t e un g r u p o SQA), el p l a n f u n c i o n a c o m o plantilla p a r a las a c t i v i d a d e s d e SQA q u e s e instituyan para cada proyecto de software. En el IEEE [IEE94] s e h a p u b l i c a d o u n e s t á n d a r p a r a p l a n e s d e SQA. El e s t á n d a r r e c o m i e n d a u n a e s t r u c t u r a q u e identifica: I) el p r o p ó s i t o y á m b i t o del plan; 2) u n a d e s c r i p c i ó n de t o d o s los p r o d u c t o s d e t r a b a j o d e i n g e n i e r í a del s o f t w a r e (por e j e m plo, m o d e l o s , d o c u m e n t o s , c ó d i g o f u e n t e ) q u e c a e n d e n t r o del a l c a n c e del SQA; 3) t o d o s los e s t á n d a r e s y p r á c t i c a s a p l i c a b l e s q u e s e a p r o v e c h a n d u r a n t e el p r o c e s o d e s o f t w a r e ; 4) a c c i o n e s y t a r e a s d e SQA (incluso r e v i s i o n e s y auditorías) y s u u b i c a c i ó n a t r a v é s del p r o c e s o de s o f t w a r e ; 5) las h e r r a m i e n t a s y m é t o d o s q u e s o p o r t a n las a c c i o n e s y t a r e a s d e SQA; 6) p r o c e d i m i e n t o s d e g e s t i ó n d e c o n f i g u r a c i ó n d e s o f t w a r e (capítulo 27) p a r a g e s t i o n a r el c a m b i o ; 7) m é t o d o s p a r a e n s a m b l a r , s a l v a g u a r d a r y m a n t e n e r t o d o s los r e g i s t r o s r e l a c i o n a d o s c o n el SQA; y 8) p a p e l e s y r e s p o n s a b i l i d a d e s e n la o r g a n i z a c i ó n r e l a t i v a s a la calidad de p r o d u c t o .

fí


Gestión de la calidad del software O b j e t i v o : El objetivo d e las herramientas de SQA es auxiliar al e q u i p o d e proyecto p a r a va-

lorar y m e j o r a r la calidad del producto d e t r a b a j o d e software.

Quality Tools Cookbook,

desarrollado p o r Sytsma a n d

Manley (www.sytsma .com/tqmtools/tqmtoolmenu.html), proporciona descripciones útiles d e herramientas clásicas de gestión d e calidad tales c o m o los

M e c á n i c a : La mecánica d e las herramientas varía. En general, la finalidad es valorar la calidad d e un producto de t r a b a j o específico. Nota; con frecuencia, dentro d e la categoría d e herramientas d e SQA, se incluye una amplia

d i a g r a m a s d e control, d i a g r a m a s de dispersión, d i a g r a m a s d e afinidad y d i a g r a m a s d e matriz. Quality Tools and Templóles, desarrolladas por iSixSigma

variedad de herramientas d e p r u e b a d e software (capítulos

(http://www.isixsigma.com/tt/), describe una amplia

13 y 14).

v a r i e d a d d e herramientas y métodos útiles p a r a gestión

Herramientas representativas 9 ARM, desarrollado p o r la NASA (satc.gsfc.nasa.gov/tool-

TQM Tools, desarrollado por Bain & C o m p a n y (www.bain.

s/index.html), ofrece medidas con las cuales se evalúa

com), brinda descripciones útiles d e una v a r i e d a d d e

la calidad d e un documento d e requisitos d e software.

herramientas d e gestión u s a d a s p o r TQM y relaciona-

QPR ProcessGuide

and Scorecard,

desarrollada p o r QPR

Software (www.qpronline.com), ofrece soporte p a r a

V

d e calidad.

seis sigma y otros e n f o q u e s d e gestión d e calidad.

d a s con los métodos d e gestión d e calidad.

TM

PDF Editor 9

Las herramientas expuestas sólo representa- _na rruestra de esta categoría. En la mayoría de los casos los nombres de las mismas sor. marcas registradas por sus respectivos desarroliadores.

792

PARTE CUATRO


Pl». La g e s t i ó n de la calidad del s o f t w a r e e s u n a actividad p r o t e c t o r a o d e s o m — q u e i n c o r p o r a t a n t o c o n t r o l c o m o a s e g u r a m i e n t o d e la calidad— q u e s e aplica a c a d a p a s o e n el p r o c e s o del s o f t w a r e . La SQA a b a r c a p r o c e d i m i e n t o s p a r a la aplicación e f i c a z d e m é t o d o s y h e r r a m i e n t a s , r e v i s i o n e s t é c n i c a s f o r m a l e s , e s t r a t e g i a s t é c n i c a s d e p r u e b a s , p r o c e d i m i e n t o s p a r a c o n t r o l del c a m b i o , p r o c e d i m i e n t o s para g a r a n t i z a r la c o n c o r d a n c i a c o n los e s t á n d a r e s y m e c a n i s m o s de m e d i c i ó n y r e p o n e La SQA la c o m p l i c a la n a t u r a l e z a c o m p l e j a d e la c a l i d a d del s o f t w a r e , u n a t r i b t t o d e los 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 s e d e f i n e c o m o " c o n c o r d a n c i a c o n les r e q u i s i t o s e s p e c i f i c a d o s explícita e i m p l í c i t a m e n t e " . P e r o c u a n d o s e c o n s i d e r a ce m a n e r a m á s g e n e r a l , la calidad d e s o f t w a r e a b a r c a m u c h o s p r o d u c t o s d i f e r e n t e s , f a c t o r e s de p r o c e s o y m é t r i c a s r e l a c i o n a d a s . Las r e v i s i o n e s de s o f t w a r e s o n u n a de l a s a c t i v i d a d e s d e control d e calidad m á s i m p o r t a n t e s . Las r e v i s i o n e s sirven c o m o filtros a t r a v é s d e t o d a s las a c t i v i d a d e s ce ingeniería del s o f t w a r e , q u e e l i m i n a n los e r r o r e s m i e n t r a s s o n r e l a t i v a m e n t e p o c : c o s t o s o s d e e n c o n t r a r y corregir. La revisión t é c n i c a f o r m a l e s u n a j u n t a q u e h a dem o s t r a d o ser e x t r e m a d a m e n t e e f i c a z p a r a d e s c u b r i r e r r o r e s . La act i vi dad a d e c u a d a p a r a g a r a n t i z a r la c a l i d a d del s o f t w a r e r e q u i e r e recopilar e v a l u a r y distribuir los d a t o s a c e r c a de los p r o c e s o s de ingeniería del s o f t w a r e . La SQA e s t a d í s t i c a a y u d a a m e j o r a r la c a l i d a d del p r o d u c t o y el p r o c e s o d e s o f t w a r e e r sí m i s m o . Los m o d e l o s d e fiabilidad del s o f t w a r e e x t i e n d e n m e d i d a s , lo q u e p e r m i t e recopilar d a t o s d e d e f e c t o p a r a e x t r a p o l a r l o s e n l a s t a s a s d e falla p r o y e c t a d a s y las p r e d i c c i o n e s d e fiabilidad. En r e s u m e n , r e c u é r d e n s e las p a l a b r a s de D u n n y Ullman [DUN82]: "El a s e g u r a m i e n t o de la calidad del s o f t w a r e e s el m a p e o (correlación) d e l o s p r e c e p t o s g e r e n c i a l e s y l a s disciplinas d e d i s e ñ o d e la g a r a n t í a d e calidad en el e s p a c i o g e r e n c i a l y t e c n o l ó g i c o a p l i c a b l e d e la ingeniería del s o f t w a r e " . La habilidad p a r a g a r a n t i z a r la calidad e s la m e d i d a de u n a disciplina d e ingeniería m a d u r a . C u a n d o el m a p e o se log r a de m a n e r a e x i t o s a , el r e s u l t a d o e s la ingeniería d e s o f t w a r e m a d u r a .

[ALV64] Alvin, W. H., von (ed.), Reliability Engineering, Prentice-Hall, 1964. [ANS87] ANSI/ASQC A3-1987, Quality Systems Terminology, 1987. [ART92] Arthur, L. J., Improving Software Quality: an Insider's Guide toTM TQM, Wiley, 1992. |ART97] Arthur, L. J., "Quantum Improvements in Software System Quality, en CACM, vol. 40, núm. 6, junio de 1997, pp. 47-52. [BOE81] Boehm, B„ Software Engineering Economics, Prentice-Hall, 1981. [C1A01] Cianfrani, C. A. el al., ISO 9001:2000 Explained, 2a. ed., American Society for Quality,

PDF Editor 2001.

[CR0791 Crosby, P„ Quality Is Free, McGraw-Hill, 1979. |DEM86] Deming, W. E., Oul of the Crisis, MIT Press, 1986. [DEM99] DeMarco, T., "Management Can make Quality (im)possible", Cutter IT Summit, Boston, abril de 1999.

CAPÍTULO 26

793


[DIJ76] Dijkstra, E., A Discipline of Progromming, Prentice-Hall, 1976. [DUN82] Dunn, R., y R. Ullman, Quality Assurancefor Computer Software, McGraw-Hill, 1982. [FRE901 Freedman, D. P. y G, M. Weinberg, Handbook o/Walkthroughs, Inspections and Technical Reviews, 3a. ed., Dorset House, 1990. [GAAO1 ] Gaal, A., ISO 9001:2000for Small Business, Saint Lucie Press, 2001. (G1L93] Gilb, T., y D. Graham, Software Inspections, Addison-Wesley, 1993. [GLA98] Glass, R , "Defining Quality Intuitively", en IEEE Software, mayo de 1998,pp. 103-104,107. [GOH02] Goh, T., V. Kuralmani y M. Xie, Statistical Models and Control Chartsfor High Quality Pro cesses, Kluwer Academic Publishers, 2002. [HOY02] Hoyle, D„ ISO 9000 Quality Systems Development Handbook: A Systems Engineering Approach, 4a. ed., Butterworth-Heinemann, 2002. [IBM81] "Implementing Software Inspections", notas de curso, IBM Systems Sciences Institute, IBM Corporation, 1981. [1EE94] Software Engineering Standards, 1994, IEEE Computer Society, 1994. [ISI03] iSixSigma, LLC, "New to Six Sigma: A Guide for Both Novice and Experienced Quality Practitioners", 2003, disponible en http://www.isixsigma.com/library/content/six-sigmanewbie.asp. [)AN86] Jahanian, F. y A. K. Mok, "Safety Analysis of Timing Properties of Real-Time Systems", en IEEE TTans. Software Engineering, vol. SE-12, núm. 9, septiembre de 1986, pp. 890-904. [JON86] Jones, T. C., Programming Productivity, McGraw-Hill, 1986. [KAN95] Kan, S. H., Metrics and Models in Software Quality Engineering, Addison-Wesley, 1995. [LEV86] Leveson, N. G„ "Software Safety: Why, What, and How", en ACM Computing Surveys, vol. 18, núm. 2, junio de 1986, pp. 125-163. [LEV87] Leveson, N. G. y). L. Stolzy, "Safety Analysis Using Petri Neis", en IEEE TTans. Software Engineering, vo\. SE-13, núm. 3, marzo de \987, pp. 386-397. (LEV95) Leveson, N. G., Safeware: System Safety and Computéis, Addison-Wesley, 1995. [LIN79I Linger, R., H. Mills y B. Witt, Structured Programming, Addison-Wesley, 1979. ILIT89] Littlewood, B„ "Forecasting Software Reliability", en Software Reliability: Modeling and Identification (S. Bittanti, ed.), Springer-Verlag, 1989, pp 141-209. [MUS871 Musa, J. D., A. lannino y K. Okumoto, Engineering and Managing Software with Rcliahi lity Measures, McGraw-Hill, 1987. [PAN00] Nande, P. et al, The Six Sigma Way, McGraw-Hill, 2000. [POR95] Porter, A., H. Siy, C. A. Toman y L. G. Votta, "An Experiment to Assess the Cost-Benefits of Code Inspections in Large Scale Software Development", en Proc. ThirdACM SIG-SOFT Symposium on the Foundations of Software Engineering, Washington, D.C., octubre de 1995, ACM Press, pp. 92-103. [R0090] Rook, Software Reliability Handbook, Elsevier, 1990. [SCH98] Schulmeyer, G. C. y J. I. McManus (eds.), Handbook of Software Quality Assurance, 3a. ed., Prentice-Hall, 1998. [SOMOl] Somerville, I., Software Engineering, 6a. ed., Addison-Wesley, 2001. [SNE03] Snee, R. y R. Hoerl, Leading Six Sigma, Prentice-Hall, 2003. [THE01] Thelin, T., H. Petersson y C. Wohlin, "Sample Driven Inspections", en Proceedings Works hop on Inspection in Software Engineering (WISE'01), París, Francia, julio de 2001, pp. 81-91, se puede descargar de http://www.cas.mcmaster.ca/wise/wiseOI/thelinPetersson-Wohlin.pdf. [VES811 Veseley, W. E. et al., Fault Tree Handbook, U.S. Nuclear Regulatory Commission, NUREG0492, enero de 1981.

TM

PDF Editor

2 6 . 1 . En las primeras páginas de este capitulo se anotó que "el control de la variación e s el corazón del control de calidad". Dado que cualquier programa que se crea es diferente de todos los otros programas, ¿cuáles son las variaciones que se buscan y cómo se les controla?

2 6 . 2 . ¿Es posible valorar la calidad del sortv. are si el cliente cambia con frecuencia lo que se supone debe hacer?

794

PARTE C U A T R O


2 6 . 3 . La calidad y la fiabilidad son conceptos relacionados pero fundamentalmente diferente en varias formas. Coméntense. 2 6 . 4 . ¿Puede un programa ser correcto y aún así no ser fiable? Expliqúese. 2 6 . 5 . ¿Puede un programa ser correcto y aún así no mostrar buena calidad? Expliqúese. 2 6 . 6 . ¿Por qué con frecuencia existe tensión entre un grupo de ingeniería de software y un gr_po independiente de aseguramiento de la calidad del software? ¿Esto es saludable? 2 6 . 7 . A usted le han dado la responsabilidad de mejorar la calidad del software por medio ce su organización. ¿Qué es lo primero que debe hacer? ¿Qué sería lo siguiente? 2 6 . 8 . Además de contar errores y defectos, ¿existen otras características contables del software que impliquen calidad? ¿Cuáles son y cómo se pueden medir directamente? 2 6 . 9 . Una revisión técnica formal sólo es eficaz si todos se han preparado por anticipado. ¿Cerno reconoce en la revisión a un participante que no está preparado? ¿Qué hace si usted es e jefe de revisión? 2 6 . 1 0 . Algunas personas argumentan que una RTF debe valorar el estilo de programación, as como la corrección. ¿Ésta es una buena idea? ¿Por qué? 2 6 . 1 1 . Revise la tabla presentada en la figura 26.5 y seleccione cuatro causas vitales de eneres serios y moderados. Sugiera acciones correctivas empleando la información presentada en otros capítulos. 2 6 . 1 2 . Investigue la bibliografía acerca de la fiabilidad del software y escriba un ensayo que describa un modelo de fiabilidad de software. Asegúrese de proporcionar un ejemplo. 2 6 . 1 3 . El concepto de TMEF para software está abierto a críticas. ¿Puede p e n s a r e n algunas razones de por qué sucede así? 2 6 . 1 4 . Considere dos sistemas críticos de seguridad que se controlan mediante computadoras Haga una lista con al menos tres peligros para cada uno que puedan estar ligados directamente con las fallas de software. 2 6 . 1 5 . Adquiera una copia de ISO 9001:2000 e ISO 9000-3. Prepare una presentación que examine tres requisitos ISO 9001 y cómo se aplican en un contexto de software.

O T P A S l - E C T t l P A S Y PUEWTBS DE l N P O B M A C l 6 » Los libros de Moriguchi (Software Excellence: A Total Quality Management Cuide, Productivity Press, 1997) y Horch (Practicai Guide to Software Quality Management, Artech Publishing, 1996) son excelentes presentaciones, en el ámbito gerencial, de los beneficios de los programas formales de aseguramiento de la calidad del software de computadora. Los libros de Deming [DEM861, Juran (Juran on Quality by Design, Free Press, 1992) y Crosby ([CR079] y Quality Is Stili Free, McGraw-Hill, 1995) no se enfocan en el software, pero son una lectura obligada para los gestores ejecutivos con responsabilidad en el desarrollo de software. Gluckman y Roome (Everyday Heroes of the Quality Movement, Dorset House, 1993) humanizan los temas de calidad al contar la historia de los actores en el proceso de calidad. Kan (Metrics and Models in Software Quality Engineering, Addison-Wesley, 1995) presenta una visión cuantitativa deTM la calidad del software. Cianfani y sus colegas (ISO 9001:2000 Explained, segunda edición, American Society for Quality, 2001) y Gaal (/SO 9001.2000for Small Business: Implementing Process-Approach Quality Management, St. Lucie Press, 2001) estudian el estándar de calidad ISO 9001:2000. Tingley (Comparing ISO 9000, Malcolm Baldrige, and the SEI CMM for Software, Prentice-Hall, 1996) ofrecen una guía útil para las organizaciones que luchan por mejorar sus procesos de gestión de calidad. Los libros de George (Lean Six Sigma, McGraw-Hill, 2002), Pande y sus colegas (The Six Sigma Way Fieldbook, McGraw-Hill, 2001) y Pyzdek (The Six Sigma Handbook, McGraw-Hill, 2000)

PDF Editor

CAPÍTULO 26


795

describen seis sigma, una técnica estadística de gestión de calidad que conduce a productos que tienen muy bajas tasas de defectos. Radice {High Quality, Low Cost Software Inspections, Paradoxicon Publishers, 2002), Wiegers (Peer Reviews in Software: A Practical Cuide, Addison-Wesley, 2001), Gilb y Graham (Software Inspection, Addison-Wesley, 1993) y Freedman y Weinberg (Handbook o/Walkthroughs, Inspections and Technical Reviews, Dorset House, 1990) ofrecen directrices valiosas para llevar a cabo revisiones técnicas formales efectivas. Musa (Software Reliability Engineering: More Reliable Software, Faster Developmenl and Testing, McGraw-Hill, 1998) ha escrito una guía práctica para técnicas de fiabilidad de software aplicado. Kapur el al. (Contributions to Hardware and Software Reliability Modeling, World Scientific Publishing Co., 1999), Gritzalis (Reliability; Quality and Safely of Software-lntensive Systems, Kluwer Academic Publishers, 1997) y Lyu (Handbook of Software Reliability Engineering, McGraw-Hill, 1996) han editado antologías de importantes ensayos acerca de la fiabilidad del software. Hermann (Software Safety and Reliability, Wiley-IEEE Press, 2000), Storey (Safety-Critical Computer Systems, Addison-Wesley, 1996) y Leveson [LEV95] continúan siendo los estudios más detallados de la seguridad del software publicados a la fecha. Además, van der Meulen (Deftnitions for Hardware and Software Safety Engineers, Springer-Verlag, 2000) ofrece un compendio completo de importantes conceptos y términos de fiabilidad y seguridad. Gartner (Testing Safety-Related Software, Springer-Verlag, 1999) ofrece una guía especializada para probar sistemas cruciales de seguridad. Friedman y Voas (Software Assessment: Reliability Safety and Testability, Wiley, 1995) ofrecen modelos útiles para valorar la fiabilidad y la seguridad. En Internet hay disponible una amplia variedad de fuentes de información acerca de la gestión de calidad de software. Una lista actualizada de referencias en la World Wide Web se puede encontrar en el sitio Web SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

CAPITULO A

GESTIÓN DEL C A M B I O

CONCEPTOS ¡

E

l cambio e s inevitable c u a n d o se construye software de c o m p u t a d o r a . Y _ ¡ c a m b i o a u m e n t a el g r a d o d e c o n f u s i ó n e n t r e los i n g e n i e r o s d e s o f t w a r e que

CLAVE 813 797 control de lo versión . . 8 2 2

t r a b a j a n e n u n p r o y e c t o . La c o n f u s i ó n s u r g e c u a n d o los c a m b i o s n o s e a n a

lizan a n t e s de r e a l i z a r l o s , n o s e r e g i s t r a n a n t e s d e i m p l e m e n t a r l o s , n o se reporta n a q u i e n e s d e b e n s a b e r l o o n o s e c o n t r o l a n e n u n a f o r m a q u e m e j o r a r á ¡a

c a l i d a d y reducirá el error. Babich [BÁB86J a b o r d a e s t o c u a n d o a f i r m a :

control del cambio . . . . 8 1 0

El arte de coordinar el desarrollo de software para minimizar... la confusión se llama

depósito

803

ganizar y controlar modificaciones al software que se construye por medio de un

tCS

801

equipo de programación. La meta es maximizar la productividad al minimizar las

e s t á n d a r e s . . . .824 GCWebApp . . . 8 1 4 gestión del contenido . . 8 1 7 identificación . . 8 0 7 de estado

814

gestión de la configuración. La gestión de la configuración es el arte de identificar, or-

equivocaciones. La g e s t i ó n del c a m b i o , m á s u s u a l m e n t e l l a m a d a gestión de la configuración software

de

(GCS o GC), e s u n a act i vidad p r o t e c t o r a (sombrilla) q u e s e aplica a lo

l a r g o del p r o c e s o d e s o f t w a r e . P u e s t o q u e el c a m b i o p u e d e ocurrir e n cualquier m o m e n t o , las a c t i v i d a d e s d e GCS s e d e s a r r o l l a n p a r a 1) identificar el c a m b i o , 2 c o n t r o l a r el c a m b i o , 3) g a r a n t i z a r q u e el c a m b i o s e i r n p l e m e n t a r á de m a n e r a a d e c u a d a , y 4) r e p o r t a r los c a m b i o s a o t r o s q u e p u d i e r a n e s t a r i n t e r e s a d o s .

(mea» b a s e . . . . 8 0 0

E s i m p o r t a n t e distinguir c o n claridad e n t r e s o p o r t e d e s o f t w a r e y g e s t i ó n de

objetos de configuración . . 8 0 7

la c o n f i g u r a c i ó n del s o f t w a r e . El s o p o r t e e s u n c o n j u n t o d e a c t i v i d a d e s d e inge-

protoso de CCS . 8 0 6

f u e p u e s t o e n o p e r a c i ó n . La g e s t i ó n d e la c o n f i g u r a c i ó n del s o f t w a r e e s u n conj u n t o d e a c t i v i d a d e s d e s e g u i m i e n t o y c o n t r o l q u e s e inician c u a n d o c o m i e n z a

SVC

809

niería del s o f t w a r e q u e o c u r r e n d e s p u é s d e q u e é s t e s e h a e n t r e g a d o al cliente y

u n p r o y e c t o d e i n g e n i e r í a del s o f t w a r e y t e r m i n a n s ó l o c u a n d o é s t e s e retira de operación.

¿ Q u é e s ? C u a n d o se construye software d e computadora los cambios ocurren. Y puesto que ocurren, es necesario gestionarlos con eficacia. La gestión del cambio, también llamada gestión de la configuración del software (GCS), es un conjunto d e actividades diseñadas para gestionar el cambio al identificar los productos de trabajo que probablemente cambien, establecer relaciones entre ellos, definir mecanismos p a r a gestionar diferentes versiones

d e estos productos de trabajo, controlar los cambios impuestos y auditor e informar los cambios realizados. '7; ¿ Q u i é n l o h a c e ? Todos los involucrados en el TM proceso de software están involucrados con la gestión del cambio en alguna medida, pero en ocasiones se crean posiciones de soporte especializado para gestionar el proceso d e GCS. ¿ P o r q u é e s i m p o r t a n t e ? Si no se controla el cambio, él toma el control. Y eso nunca es bueno. Es muy fácil que una corriente de cam-

PDF Editor

CAPÍTULO 27

797

GESTIÓN DEL CAMBIO

bios incontrolados convierta en caótico un proyecto de software bien ¡mplementado. Por esta razón, ia gestión del cambio es una parte esencial de la buena gestión del proyecto y d e una sólida práctica de ingeniería de software. ¿ C u á l e s s o n l o s p a s o s ? Puesto que muchos productos de trabajo se producen cuand o se construye el software, cada uno d e b e identificarse en forma individual. Una vez hecho esto se establecen los mecanismos d e control d e versión y cambio. El proceso se audita p a r a garantizar que ia calidad se conserva conforme e¡ cambio se realiza y que quienes tienen necesidad d e conocerlo reciben información acerca de los cambios mediante los informes respectivos.

¿Cuál e s el p r o d u c t o o b t e n i d o ? Un plan de gestión de la configuración del software define la estrategia del proyecto para la gestión del cambio. Además, cuando se pide una GCS farmal, el procesó de control'del cambio producé solicitudes d e cambio d e software, informes y peticiones d e cambio de ingeniería. ¿ C ó m o p u e d o estar s e g u r o d e q u e lo he h e c h o c o r r e c t a m e n t e ? Guando cualquier producto d e trabajo p u e d e explicarse, seguirse y controlarse; cuando los cambios puede seguirse y analizarse; cuando todos los que necesitan saber acerca de un cambio han sido informados, el trabajo se ha hecho bien.

U n a m e t a p r i m o r d i a l de la ingeniería del s o f t w a r e e s m e j o r a r la facilidad c o n la q u e los c a m b i o s s e p u e d e n a c o m o d a r y r e d u c i r el e s f u e r z o c u a n d o los c a m b i o s se d e b e n realizar. En e s t e c a p í t u l o s e e s t u d i a n l a s a c c i o n e s e s p e c í f i c a s q u e p e r m i t e n g e s t i o n a r el c a m b i o .

27.1

G E S T I Ó N P E LA C O N F I G U R A C I Ó N BEL SOFTWARE La salida del p r o c e s o d e s o f t w a r e e s i n f o r m a c i ó n q u e s e p u e d e dividir e n t r e s a m p l i a s c a t e g o r í a s : 1) p r o g r a m a s de c o m p u t a d o r a (tanto al nivel de f u e n t e c o m o de f o r m a s e j e c u t a b l e s ) ; 2) p r o d u c t o s de t r a b a j o q u e d e s c r i b e n los p r o g r a m a s d e c o m p u t a d o r a (dirigidos t a n t o a p r o f e s i o n a l e s t é c n i c o s c o m o a u s u a r i o s ) , y 3) d a t o s ( i n t e r n o s o e x t e r n o s al p r o g r a m a ) . Los e l e m e n t o s q u e c o m p r e n d e n la i n f o r m a c i ó n p r o d u c i d a c o m o p a r t e del p r o c e s o d e s o f t w a r e s e d e n o m i n a n c o l e c t i v a m e n t e configuración

del

software. Si c a d a e l e m e n t o d e c o n f i g u r a c i ó n s i m p l e m e n t e c o n d u j e r a a o t r o s e l e m e n t o s h a b r í a p o c a c o n f u s i ó n . Por d e s g r a c i a , o t r a v a r i a b l e e n t r a e n el p r o c e s o : el cambio. Éste p u e d e ocurrir e n c u a l q u i e r m o m e n t o , p o r c u a l q u i e r r a z ó n . D e h e c h o , la p r i m e ra ley d e la ingeniería d e s i s t e m a s [BER801 a f i r m a : "No i m p o r t a d ó n d e s e e n c u e n t r e e n el ciclo de vida del s i s t e m a , el s i s t e m a c a m b i a r á y el d e s e o d e c a m b i a r l o p e r s i s t i rá a lo largo d e t o d o el ciclo d e vida".

TM

PDF Editor "No hoy nada permanente, excepto el cambio."

Herádito, 5 0 0 a . C

¿Cuál e s el o r i g e n d e e s t o s c a m b i o s ' La r e s p u e s t a e s ta n v a r i a d a c o m o los c a m -

b i o s m i s m o s . Sin e m b a r g o , e x i s t e n c u a t r o f u e n t e s f u n d a m e n t a l e s de c a m b i o :

798

PARTE CUATRO

A ¿Cuál es el W origen de los cambios que se requieren para el software?


• N u e v a s c o n d i c i o n e s e n el n e g o c i o o m e r c a d o d i c t a n los c a m b i o s e n los r e q u - ¡ s i t o s del p r o d u c t o o las r e g l a s del n e g o c i o . • N u e v a s n e c e s i d a d e s del cl i ente d e m a n d a n la m o d i f i c a c i ó n d e los d a t o s q u e p r o d u c e n l o s s i s t e m a s d e i n f o r m a c i ó n , d e la f u n c i o n a l i d a d q u e e n t r e g a n los productos o los servicios que entrega un sistema b a s a d o e n computadora. • La r e o r g a n i z a c i ó n o el c r e c i m i e n t o o r e d u c c i ó n del n e g o c i o p r o v o c a n c a m b i os e n las p r i o r i d a d e s del p r o y e c t o o e n la e s t r u c t u r a del e q u i p o d e ingeniería de! software. • R e s t r i c c i o n e s p r e s u p u é s t a l e s o d e c a l e n d a r i z a c i ó n i n d u c e n u n a redefinición del s i s t e m a o p r o d u c t o . La 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 w a r e e s u n c o n j u n t o d e a c t i v i d a d e s q u e s e h a d e s a r r o l l a d o p a r a g e s t i o n a r el c a m b i o a lo largo del ciclo d e vida del s o f t w a r e ce c o m p u t a d o r a . La GCS s e c o n s i d e r a c o m o u n a actividad d e a s e g u r a m i e n t o d e la ca. d a d del s o f t w a r e q u e s e a p l i c a a lo l a r g o del p r o c e s o r e s p e c t i v o . En l a s s e c c i o n e ; s i g u i e n t e s s e e x a m i n a n las p r i n c i p a l e s t a r e a s d e la GCS y c o n c e p t o s i m p o r t a n t e s que a y u d a n a g e s t i o n a r el c a m b i o .

27.1.1 Un escenario de GCS1 Un típico e s c e n a r i o o p e r a t i v o d e GCS i n v o l u c r a u n g e s t o r de p r o y e c t o a c a r g o d e un g r u p o d e s o f t w a r e ; u n g e s t o r de c o n f i g u r a c i ó n a c a r g o d e los p r o c e d i m i e n t o s y politicas de GC; los i n g e n i e r o s de s o f t w a r e r e s p o n s a b l e s del d e s a r r o l l o y m a n t e n i m i e r t o del p r o d u c t o d e s o f t w a r e , y el cl iente q u e e m p l e a el p r o d u c t o . En el e s c e n a n : s u p ó n g a s e q u e el p r o d u c t o e s p e q u e ñ o e i n v o l u c r a c e r c a d e 15 0 0 0 l í n e a s d e códigc q u e d e s a r r o l l a r á un e q u i p o de s e i s p e r s o n a s . (Nótese q u e s o n p o s i b l e s o t r o s e s c e n a rios d e e q u i p o s m e n o r e s o m a y o r e s , p e r o , e n e s e n c i a , e x i s t e n c o n f l i c t o s g e n é r i c o s q u e c a d a u n o d e e s t o s p r o y e c t o s e n f r e n t a e n r e l a c i ó n c o n la GC.) En el á m b i t o o p e r a t i v o el e s c e n a r i o i n v o l u c r a d i v e r s o s p a p e l e s y t a r e a s . La m e t ¿ del g e s t o r del p r o y e c t o e s g a r a n t i z a r q u e el p r o d u c t o s e e n t r e g u e d e n t r o d e c i e n c p e r i o d o . En c o n s e c u e n c i a , el g e s t o r s u p e r v i s a el p r o g r e s o del d e s a r r o l l o y r e c o n o c e ¿Cuáles son • las metas y las actividades realizadas por cada uno de los participantes involucrados en la gestión del cambio?

y r e a c c i o n a a n t e l o s p r o b l e m a s . Esto s e h a c e al g e n e r a r y a n a l i z a r los i n f o r m e s acerc a del e s t a d o del s i s t e m a d e s o f t w a r e y al r e a l i z a r r e v i s i o n e s e n el s i s t e m a . Las m e t a s del g e s t o r d e c o n f i g u r a c i ó n s o n g a r a n t i z a r q u e s e s i g u e n los procedim i e n t o s y políticas p a r a c r e a r , c a m b i a r y p o n e r a p r u e b a el c ó d i g o , así c o m o posibilitar el a c c e s o a la i n f o r m a c i ó n a c e r c a del p r o y e c t o . La i m p l e m eTM ntación de técnicas p a r a m a n t e n e r el c o n t r o l s o b r e los c a m b i o s d e c ó d i g o r e q u i e r e q u e e s t e g e s t o r introd u z c a m e c a n i s m o s p a r a solicitar o f i c i a l m e n t e c a m b i o s , e v a l u a r l o s ( m e d i a n t e u n a

PDF Editor

j u n t a d e c o n t r o l d e c a m b i o s , q u e e s la r e s p o n s a b l e d e a p r o b a r l o s c a m b i o s al siste-

I

Esta sección procede de [DAROII. El permiso especial para reproducir "Spectrum of Functionality ir. CM Systems" de Susan Dart [DAROI], © 2001 por Carnegie Mellon University, lo otorgó el Software Engineering Institute.

CAPÍTULO 27

799

GESTIÓN DEL CAMBIO

m a d e s o f t w a r e ) y a u t o r i z a r l o s . El g e s t o r c r e a y d i s t r i b u y e l a s l i s t a s d e t a r e a s p a r a l o s i n g e n i e r o s y b á s i c a m e n t e c r e a el c o n t e x t o del p r o y e c t o . A d e m á s , el g e s t o r recopila

kVE • un ¡poro rque los s amultóneos al : imponente

e s t a d í s t i c a s a c e r c a d e c o m p o n e n t e s e n el s i s t e m a d e s o f t w a r e , p o r e j e m p l o : la inform a c i ó n q u e d e t e r m i n a c u á l e s c o m p o n e n t e s s o n p r o b l e m á t i c o s e n el s i s t e m a . La m e t a de l o s i n g e n i e r o s d e s o f t w a r e e s t r a b a j a r c o n e f i c i e n c i a . Esto significa q u e n o i n t e r f i e r e n d e m a n e r a i n n e c e s a r i a u n o s c o n o t r o s e n la c r e a c i ó n y p r u e b a del c ó d i g o ni e n la p r o d u c c i ó n d e los d o c u m e n t o s d e s o p o r t e . No o b s t a n t e , al m i s m o tiempo, intentan comunicarse y coordinarse de m a n e r a eficiente. Específicamente, los i n g e n i e r o s utilizan h e r r a m i e n t a s q u e a y u d a n a c o n s t r u i r u n p r o d u c t o d e s o f t w a re c o n s i s t e n t e . Ellos s e c o m u n i c a n y c o o r d i n a n al n o t i f i c a r s e m u t u a m e n t e las t a r e a s q u e se r e q u i e r e n y las t a r e a s c u m p l i d a s . Los c a m b i o s s e p r o p a g a n p o r m e d i o del trab a j o d e c a d a u n o m e d i a n t e a r c h i v o s f u s i o n a d o s . Existen m e c a n i s m o s p a r a a s e g u r a r q u e , r e s p e c t o d e los c o m p o n e n t e s q u e e x p e r i m e n t a n c a m b i o s s i m u l t á n e o s , e x i s t e a l g u n a f o r m a d e r e s o l v e r los c o n f l i c t o s y f u s i o n a r los c a m b i o s . La historia d e la e v o lución d e t o d o s los c o m p o n e n t e s del s i s t e m a s e m a n t i e n e j u n t o c o n un registro d e l a s r a z o n e s d e los c a m b i o s y o t r o d e lo q u e c a m b i ó e n realidad. Los i n g e n i e r o s tien e n s u p r o p i o e s p a c i o d e t r a b a j o p a r a c r e a r , c a m b i a r , p r o b a r e i n t e g r a r c ó d i g o . En c i e r t o p u n t o , el c ó d i g o s e c o n v i e r t e e n u n a línea b a s e a partir d e la q u e c o n t i n ú a el d e s a r r o l l o p o s t e r i o r y d e s d e la q u e s e r e a l i z a n l a s v a r i a n t e s p a r a o t r a s m á q u i n a s q u e t a m b i é n s e a n el objetivo. El cliente e m p l e a el producto. D a d o q u e el p r o d u c t o lo c o n t r o l a la GC, el cliente sigue p r o c e d i m i e n t o s f o r m a l e s p a r a solicitar c a m b i o s e indicar los bugs e n el producto. I d e a l m e n t e , u n s i s t e m a d e GC u t i l i z a d o e n e s t e e s c e n a r i o a p o y a r í a t o d a s e s t a s f u n c i o n e s y t a r e a s ; e s t o e s , las f u n c i o n e s d e t e r m i n a n la f u n c i o n a l i d a d r e q u e r i d a de u n s i s t e m a d e GC. El g e s t o r del p r o y e c t o ve u n a GC c o m o un m e c a n i s m o d e auditoría; el g e s t o r d e c o n f i g u r a c i ó n , c o m o u n m e c a n i s m o d e c r e a c i ó n de c o n t r o l , s e g u i m i e n t o y políticas; el i n g e n i e r o d e s o f t w a r e , c o m o u n m e c a n i s m o d e c o n t r o l del c a m b i o , la c o n s t r u c c i ó n y el a c c e s o ; y el u s u a r i o , c o m o u n m e c a n i s m o d e g a r a n t í a d e la calidad.

27.1.2 Elementos de un sistema de gestión de la configuración En s u d e t a l l a d o artículo a c e r c a d e la g e s t i ó n d e la c o n f i g u r a c i ó n del s o f t w a r e , S u s a n Dart [DAR01] identifica c u a t r o i m p o r t a n t e s e l e m e n t o s q u e d e b e n e s t a r p r e s e n t e s c u a n d o s e d e s a r r o l l a u n s i s t e m a de g e s t i ó n d e la c o n f i g u r a c i ó n :

TM • Elementos

de componentes:

c o n j u n t o d e h e r r a m i e n t a s a c o p l a d a s d e n t r o de u n

s i s t e m a d e g e s t i ó n de a r c h i v o s por e j e m p l o , u n a b a s e de datos) q u e p e r m i t e n

PDF Editor el a c c e s o y la g e s t i ó n d e c a d a e l e m e n t o d e c o n f i g u r a c i ó n del s o f t w a r e .

• Elementos

de proceso:

serie de proce cimientos y tareas que definen un

e n f o q u e e f i c a z c o n el c u a l g e s t i o n a r el c a m b i o (y a c t i v i d a d e s r e l a c i o n a d a s ) p a r a t o d o s los p a r t i c i p a n t e s e r .a g e s t i ó n i n g e n i e r í a y utilización del s o f t w a r e de computadora.

800

PARTE CUATRO

• Elementos


de construcción:

c o n j u n t o d e h e r r a m i e n t a s q u e a u t o m a t i z a n la

c o n s t r u c c i ó n del s o f t w a r e al a s e g u r a r q u e s e h a e n s a m b l a d o u n c o n j u n t o a d e c u a d o d e c o m p o n e n t e s v a l i d a d o s (es decir: la v e r s i ó n c o r r e c t a ) . • Elementos

humanos:

la i m p l e m e n t a c i ó n d e u n a GCS e f i c a z r e q u i e r e q u e el

e q u i p o d e s o f t w a r e utilice u n c o n j u n t o d e h e r r a m i e n t a s y c a r a c t e r í s t i c a s de p r o c e s o s (que a b a r c a n o t r o s e l e m e n t o s d e GC). E sto s e l e m e n t o s (que s e e s t u d i a r á n c o n m á s detalle en s e c c i o n e s v e n i d e r a s ) n o s o r m u t u a m e n t e e x c l u y e n t e s . Por e j e m p l o , los e l e m e n t o s d e c o m p o n e n t e s t r a b a j a n e n c o n j u n t o c o n los d e c o n s t r u c c i ó n c o n f o r m e a v a n z a el p r o c e s o d e s o f t w a r e . Los elem e n t o s d e p r o c e s o g u í a n m u c h a s a c t i v i d a d e s h u m a n a s q u e s e r e l a c i o n a n c o n GCS y, p o r t a n t o , t a m b i é n p u e d e n c o n s i d e r a r s e e l e m e n t o s h u m a n o s .

(CONSUO£. La mayoría de los cambios de software están justificados, asi que no hay razón para quejarse acerco de ellos. Más bien, es necesario asegurarse de que se tienen los mecanismos apropiados pora manejarlos.

27.1.3 Líneas base El c a m b i o e s u n h e c h o d e vida e n el d e s a r r o l l o del s o f t w a r e . Los c l i e n t e s q u i e r e n m o d i f i c a r l o s requisitos. Los d e s a r r o l l a d o r e s q u i e r e n m o d i f i c a r el e n f o q u e técnico. Los g e s t o r e s q u i e r e n m o d i f i c a r la e s t r a t e g i a del p r o y e c t o . ¿Por q u é t o d a s e s t a s m o d i ficaciones?

La r e s p u e s t a , e n r e a l i d a d , e s b a s t a n t e s i m p l e . C o n f o r m e p a s a el t i e m p o ,

t o d o s los p a r t i c i p a n t e s s a b e n m á s (acerca de lo q u e n e c e s i t a n , q u é e n f o q u e sería el m e j o r , c ó m o h a c e r l o y a u n así o b t e n e r dinero). Este c o n o c i m i e n t o a d i c i o n a l e s la f u e r z a i m p u l s o r a d e t r á s de la m a y o r í a d e los c a m b i o s y c o n d u c e a u n a e x p r e s i ó n difícil de a c e p t a r p a r a m u c h o s p r o f e s i o n a l e s d e la ingeniería del s o f t w a r e : ¡la mayoría de los cambios

están justificados!

Una línea base e s u n c o n c e p t o d e g e s t i ó n d e la c o n f i g u r a c i ó n del s o f t w a r e q u e a y u d a a c o n t r o l a r el c a m b i o sin i m p e d i r s e r i a m e n t e el c a m b i o justificable. El IEEE (IEEE Std. No. 610.12-1990) d e f i n e u n a línea b a s e c o m o : Una especificación o producto que se ha revisado formalmente y se está de acuerdo con los resultados, y que a partir de ahí sirve como la base para el desarrollo ulterior y que puede cambiarse sólo por medio de procedimientos formales de control del cambio. A n t e s de q u e u n e l e m e n t o d e c o n f i g u r a c i ó n del s o f t w a r e s e c o n v i e r t a e n línea b a s e , e s p o s i b l e r e a l i z a r el c a m b i o r á p i d a e i n f o r m a l m e n t e . Sin e m b a r g o , u n a v e z e s t a b l e c i d a u n a línea b a s e , m e t a f ó r i c a m e n t e s e p a s a a t r a v é s d e u n a p u e r t a g i r a t o ria d e u n a s o l a dirección. Los c a m b i o s s e p u e d e n r e a l i z a r , p e r o se d e b e a p l i c a r u n p r o c e d i m i e n t o e s p e c í f i c o f o r m a l p a r a e v a l u a r y verificar c a d a u n o . En el c o n t e x t o d e la i n g e n i e r í a del s o f t w a r e , u n a línea b a s e e s uTM n h i t o e n el d e s a -

CLAVE

rrollo del s o f t w a r e . Se m a r c a u n a línea b a s e p a r a la e n t r e g a d e u n o o m á s e l e m e n -

Un producto de trobojo de ingeniería del software se convierte en lineo bose sólo Después de que se ha •?«sado y aprobado.

u n a revisión t é c n i c a f o r m a l (capítulo 26). Por e j e m p l o , los e l e m e n t o s de u n m o d e l o

O

t o s de c o n f i g u r a c i ó n del s o f t w a r e (ECS) q u e s e h a n a p r o b a d o c o m o c o n s e c u e n c i a d e

PDF Editor

d e d i s e ñ o s e h a n d o c u m e n t a d o y r e v i s a d o . Se h a n e n c o n t r a d o e r r o r e s y s e h a n c o r r e gido. Una v e z q u e t o d a s l a s p a r t e s del m o d e l o s e h a n r e v i s a d o , c o r r e g i d o y l u e g o a p r o b a d o , el m o d e l o de d i s e ñ o s e c o n v i e r t e e n línea b a s e . Los c a m b i o s p o s t e r i o r e s a la a r q u i t e c t u r a del p r o g r a m a ( d o c u m e n t a d o s e n el m o d e l o d e d i s e ñ o ) s ó l o s e p u e -

CAPÍTULO 27

ÔWSiiO^ >s preciso asegurarse Je que la base de :jíos del proyecto se -•rntiene en uno Moción central yitrolado.

801

GESTIÓN DEL CAMBIO

d e n e f e c t u a r d e s p u é s d e q u e c a d a u n o s e h a e v a l u a d o y a p r o b a d o . A u n q u e l a s lín e a s b a s e s e p u e d e n definir e n c u a l q u i e r g r a d o de detalle, e n la figura 27.1 s e m u e s t r a n las l í n e a s b a s e d e s o f t w a r e m á s c o m u n e s . En la figura 27.1 t a m b i é n s e m u e s t r a la p r o g r e s i ó n d e e v e n t o s q u e c o n d u c e n a u n a línea b a s e . Las t a r e a s d e i n g e n i e r í a del s o f t w a r e p r o d u c e n u n o o m á s ECS. D e s p u é s d e q u e é s t o s s e revisan y a p r u e b a n se c o l o c a n e n u n a base de datos del proyecto

( t a m b i é n l l a m a d a librería del proyecto

o depósito

de software,

que se examinan

e n la s e c c i ó n 27.2). C u a n d o u n m i e m b r o d e u n e q u i p o d e s o f t w a r e q u i e r e m o d i f i c a r u n ECS q u e s e h a c o n v e r t i d o e n línea b a s e , s e c o p i a d e la b a s e d e d a t o s del p r o y e c t o e n el e s p a c i o d e t r a b a j o p r i v a d o del i n g e n i e r o . Sin e m b a r g o , e s t e ECS e x t r a í d o s ó l o s e p u e d e m o d i f i c a r si s e s i g u e n los c o n t r o l e s d e la GCS ( t r a t a d o s m á s a d e l a n t e e n e s t e capítulo). Las flechas e n la figura 27.1 ilustran la t r a y e c t o r i a d e m o d i f i c a c i ó n p a r a u n ECS c o n v e r t i d o e n línea b a s e .

27.1.4 Elementos de configuración del software Un e l e m e n t o de c o n f i g u r a c i ó n del s o f t w a r e (ECS) e s i n f o r m a c i ó n q u e se c r e a c o m o p a r t e del p r o c e s o d e ingeniería del s o f t w a r e . En el e x t r e m o , s e p u e d e c o n s i d e r a r q u e u n ECS e s u n a sola s e c c i ó n d e u n a g r a n e s p e c i f i c a c i ó n o u n c a s o d e p r u e b a d e u n g r a n c o n j u n t o d e p r u e b a s . De m a n e r a m á s realista, un ECS e s u n d o c u m e n t o , u n c o n j u n t o c o m p l e t o d e c a s o s d e p r u e b a o u n c o m p o n e n t e d e un p r o g r a m a d a d o (por e j e m p l o , u n a f u n c i ó n C++ o u n applet d e Java). A d e m á s d e los ECS p r o v e n i e n t e s d e los p r o d u c t o s de t r a b a j o d e s o f t w a r e , m u c h a s o r g a n i z a c i o n e s d e ingeniería del s o f t w a r e t a m b i é n c o l o c a n l a s h e r r a m i e n t a s r e s p e c t i v a s b a j o c o n t r o l d e c o n f i g u r a c i ó n . E s t o es: v e r s i o n e s e s p e c í f i c a s d e e d i t o r e s , c o m -

ECS convertidos en línea b a s e y b a s e de d a t o s del proyecto.

Modificado

TM

PDF Editor

LINEAS BASE: Especificación del sistemo Requisitos d e software Especificación del d i s e ñ o C ó d i g o fuente Planes/procedimientos/ datos de prueba Sistema o p e r a t i v o

802

PARTE C U A T R O


piladores, n a v e g a d o r e s y otras h e r r a m i e n t a s a u t o m a t i z a d a s se "congelan" cc parte de la configuración del software. Puesto que dichas h e r r a m i e n t a s se utili2 para producir documentación, código f u e n t e y datos, deben estar disponibles al: lizar cambios en la configuración del software. Aunque los problemas son raros, i posible que u n a nueva versión de u n a herramienta (por ejemplo, u n compila produzca resultados diferentes a los de la versión original. Por esta razón, las her mientas, al igual que el s o f t w a r e que ayudan a producir, pueden convertirse en lii b a s e c o m o parte de un proceso global de gestión de configuración. En realidad, los ECS están o r g a n i z a d o s para formar objetos de configuración ¡ ceptibles de catalogar en la b a s e de datos del proyecto con un solo nombre. Un i to de configuración

tiene un nombre, atributos y está "conectado" con otros obje

por medio de relaciones. Si se observa la figura 27.2, los objetos de configurac EspecificacionDiseño,

ModeloDatos,

ComponenteN,

CodigoFuente

E s p e c i f i c a c i o n P r u e b a están definidos por s e p a r a d o . Sin embargo, c a d a uno de 1 objetos se relaciona con los otros c o m o lo m u e s t r a n las flechas. Una flecha indica u n a relación de composición. Esto es: M o d e l o D a t o s y C o m p o n e n t e N parte del objeto E s p e c i f i c a c i o n D i s e ñ o . Una flecha recta con doble punta ind una interrelación. Si se realizase un c a m b i o al objeto C o d i g o F u e n t e , las inter ciones permiten que un ingeniero de s o f t w a r e determine qué otros objetos (y EC5j] pueden afectarse. 2

Objetos de configuración.

TM

PDF Editor

Estas relaciones se definen dentro de la base de datos. La estructura de la base de datos (almacér. se estudia con mayor detalle en la sección 27.2.

CAPÍTULO 27

2 7 . 2

803

GESTIÓN DEL CAMBIO

E L D E P Ó S I T O DE E C S En los p r i m e r o s d í a s d e la ingeniería del s o f t w a r e los e l e m e n t o s d e c o n f i g u r a c i ó n s e c o n s e r v a b a n c o m o d o c u m e n t o s d e p a p e l (¡o t a r j e t a s p e r f o r a d a s ! ) , q u e s e c o l o c a b a n e n c a r t a p a c i o s o c a r p e t a s d e a n i l l o s y s e a l m a c e n a b a n e n a r c h i v e r o s m e t á l i c o s . Este e n f o q u e e r a p r o b l e m á t i c o por m u c h a s r a z o n e s : 1) c o n f r e c u e n c i a e r a difícil e n c o n t r a r u n e l e m e n t o d e c o n f i g u r a c i ó n c u a n d o s e le n e c e s i t a b a ; 2) u s u a l m e n t e e r a u n r e t o d e t e r m i n a r c u á l e l e m e n t o h a b í a s i d o c a m b i a d o , c u á n d o y p o r q u i é n ; 3) la c o n s trucción de u n a n u e v a v e r s i ó n d e u n p r o g r a m a e x i s t e n t e c o n s u m í a m u c h o t i e m p o y e r a proclive al error; 4) la d e s c r i p c i ó n d e r e l a c i o n e s d e t a l l a d a s o c o m p l e j a s e n t r e e l e m e n t o s d e c o n f i g u r a c i ó n e r a v i r t u a l m e n t e imposible. En la a c t u a l i d a d , los ECS se c o n s e r v a n e n u n a b a s e d e d a t o s o d e p ó s i t o del p r o yecto. El diccionario W e b s t e r d e f i n e la p a l a b r a depósito c o m o "cualquier c o s a o p e r s o n a q u e s e c o n s i d e r a c o m o c e n t r o d e a c u m u l a c i ó n o a l m a c e n a m i e n t o " . En los inicios d e la i n g e n i e r í a del s o f t w a r e , el d e p ó s i t o d e h e c h o e r a u n a p e r s o n a : el p r o g r a m a d o r , q u i e n t e n í a q u e r e c o r d a r la u b i c a c i ó n d e t o d a la i n f o r m a c i ó n r e l e v a n t e p a r a u n p r o y e c t o d e s o f t w a r e ; a d e m á s , t e n i a q u e r e c u p e r a r la i n f o r m a c i ó n q u e n u n c a s e h a b í a r e s p a l d a d o p o r e s c r i t o y r e c o n s t r u i r la i n f o r m a c i ó n p e r d i d a . T r i s t e m e n t e , e m p l e a r a u n a p e r s o n a c o m o " c e n t r o de a c u m u l a c i ó n y a l m a c e n a m i e n t o " ( a u n q u e c o n c u e r d e c o n la defi ni ci ón del diccionario) n o f u n c i o n a m u y bien. Hoy el d e p ó s i t o e s u n a "cosa": u n a b a s e de d a t o s q u e a c t ú a c o m o el c e n t r o t a n t o d e la a c u m u l a c i ó n c o m o del a l m a c e n a m i e n t o d e la i n f o r m a c i ó n d e i n g e n i e r í a del s o f t w a r e . El p a p e l d e la p e r s o n a (el i n g e n i e r o d e s o f t w a r e ) e s i n t e r a c t u a r c o n el d e p ó s i t o m e d i a n t e las h e r r a mientas que tiene integradas.

27.2.1 El papel del depósito El d e p ó s i t o d e ECS e s el c o n j u n t o de m e c a n i s m o s y e s t r u c t u r a s d e d a t o s q u e p e r m i te q u e u n e q u i p o d e s o f t w a r e m a n e j e el c a m b i o e n u n a f o r m a e f i c a z . El d e p ó s i t o p r o porciona las funciones obvias de u n sistema d e gestión de base de datos pero, adem á s , el d e p ó s i t o r e a l i z a o i m p u l s a l a s s i g u i e n t e s f u n c i o n e s [FOR89]: I ¿Qué W funciones nplemento un ••pósito de ECS?

• La integridad

de los datos incluye f u n c i o n e s p a r a validar las e n t r a d a s al

d e p ó s i t o , g a r a n t i z a r la c o n s i s t e n c i a e n t r e o b j e t o s r e l a c i o n a d o s y a u t o m á t i c a m e n t e r e a l i z a r m o d i f i c a c i o n e s "en c a s c a d a " c u a n d o u n c a m b i o e n u n o b j e t o d e m a n d a a l g ú n c a m b i o a los o b j e t o s r e l a c i o n a d o s c o n él. • El compartir

información

TM

o f r e c e u n m e c a n i s m o p a r a distribuir la i n f o r m a c i ó n

e n t r e m ú l t i p l e s d e s a r r o l l a d o r e s y h e r r a m i e n t a s , m a n e j a r y c o n t r o l a r los

PDF Editor

a c c e s o s a l o s d a t o s p o r p a r t e de m ú l t i p l e s u s u a r i o s y c e r r a r y a b r i r los o b j e t o s de m o d o que los cambios n o s e a n trasladados inadvertidamente hacia otros.

• La integración de herramientas

establece u n m o d e l o d e d a t o s al q u e se p u e d e t e n e r

a c c e s o m e d i a n t e m u c h a s h e r r a m i e n t a s d e ingeniería del software, controlar el

a c c e s o a los d a t o s y realizar f u n d o n e s a d e c u a d a s de gestión d e la configuración.

804

PARTE C U A T R O


• La integración

de los datos b r i n d a f u n c i o n e s d e b a s e d e d a t o s q u e p e r m i t e n

q u e v a r i a s t a r e a s d e GCS s e r e a l i c e n e n u n o o m á s ECS. • El fortalecimiento

de la metodología

define un modelo de entidad-relación

g u a r d a d o e n el d e p ó s i t o q u e implica u n m o d e l o d e p r o c e s o e s p e c í f i c o p a r a la i n g e n i e r í a del s o f t w a r e ; c o m o m í n i m o , las r e l a c i o n e s y o b j e t o s d e f i n e n u n c o n j u n t o d e p a s o s q u e s e d e b e n llevar a c a b o p a r a c o n s t r u i r los c o n t e n i d o s del d e p ó s i t o . • Estandarización

de los documentos

e s la definición d e los o b j e t o s e n la b a s e de

d a t o s q u e c o n d u c e d i r e c t a m e n t e a un e n f o q u e e s t á n d a r p a r a la c r e a c i ó n d e d o c u m e n t o s d e i n g e n i e r í a del s o f t w a r e . El d e p ó s i t o s e d e f i n e e n f u n c i ó n d e u n m e t a m o d e l o . P a r a lograr e s t a s f u n c i o n e s d metamodelo

d e t e r m i n a c ó m o s e g u a r d a la i n f o r m a c i ó n e n el d e p ó s i t o , c ó m o se tiene

a c c e s o a los d a t o s m e d i a n t e las h e r r a m i e n t a s y c ó m o los visualizan los i n g e n i e r o s c t s o f t w a r e , c u á n bien s e p u e d e m a n t e n e r la s e g u r i d a d e integridad d e los d a t o s , y cuan f á c i l m e n t e se p u e d e a m p l i a r el m o d e l o e x i s t e n t e p a r a a d e c u a r l a s n u e v a s necesida d e s . Para m a y o r i n f o r m a c i ó n , el lector i n t e r e s a d o d e b e c o n s u l t a r [SHA95] y [GR195;

27.2.2 Características y contenido generales Las c a r a c t e r í s t i c a s y el c o n t e n i d o del d e p ó s i t o s e c o m p r e n d e n m e j o r si s e l e s o b s e va d e s d e d o s p e r s p e c t i v a s : q u é se g u a r d a r á e n el d e p ó s i t o y q u é s e r v i c i o s específic o s o f r e c e é s t e . En la figura 2 7 . 3 s e p r e s e n t a u n a n á l i s i s d e t a l l a d o d e los tipos c e r e p r e s e n t a c i o n e s , d o c u m e n t o s y p r o d u c t o s d e t r a b a j o q u e se g u a r d a n e n el deposite

Contenido del depósito.

Reglas del negocio Funciones del negocio Eslrucrura d e la o r a a m z a c i ó n Arquitectura deintormoción

Contenido d e negocio

Casos de uso Modelo de análisis Diagramas basados en escenario Código fuente Diagramas orientados a flujo Diagramas basados en clase ^ - v (Código d e objeto Diagramas comportamentales / V Instrucciones de construcción del sistema Modelo de diseño / C o r r i d o de > Diagramas arqu, e n a n c a s ^comlrucc¡6„ Diagramas d e intertaz \ A Diagramas al nivel d e c o m p o n e n t e s V - ;¡& J Casos de prueba Métricas técnicas / N Guiones d e prueba Resultados de prueba Métricas de calidod Contenido de modelo Contenido VyV

TM Contenido d e gestión del proyecto

PDF Editor Estimaciones del proyecto Calendarización del proyecto Requisitos de GCS Solicitudes d e cambio Informes d e combios Requisitos de SQA Informes de proyecto/informes d e auditoría Métricas del proyecto

Documentos

Plan del proyecto Plan G C S / S Q A Especificaciones del sistema Especificaciones de requisitos Documento d e diseño Plon y procedimiento d e prueba Documentos de soporte Manual del usuario

CAPÍTULO 27

R«fcrencia Web

805

GESTIÓN DEL CAMBIO

Un depósito robusto proporciona d o s clases diferentes de servicios: 1) los m i s m o s tipos de servicios que se pueden esperar de cualquier sistema sofisticado de gestión

ese i obtener en •vww.softwore. bp.com/prodlKts/ SCMGR o en otn. •/

•

rtpotttoryJitml.

de b a s e de datos, y 2) servicios específicos del e n t o r n o de la ingeniería del software. Un depósito que atienda a un equipo de ingeniería de software debe 1) integrarse con o directamente apoyar las funciones de gestión de proceso; 2) apoyar reglas específicas que rigen la función de GCS y los d a t o s c o n s e r v a d o s d e n t r o del depósito; 3) ofrecer u n a interfaz a otras h e r r a m i e n t a s de ingeniería del software; y 4) a c o m o dar el a l m a c e n a m i e n t o de d a t o s sofisticados (por ejemplo, texto, gráficos, video, audio).

27.2.3 Características de la GCS El apoyo a la GCS requiere que el a l m a c é n o depósito tenga un c o n j u n t o de herramientas que ofrezca soporte para las siguientes características: Versiones.

Conforme un proyecto progrese se crearán m u c h a s versiones (sección

27.3.2) de productos de trabajo individuales. El depósito debe ser capaz de guardar todas e s t a s versiones para permitir la gestión eficaz de las liberaciones de producto y permitir que los desarrolladores regresen a versiones anteriores durante las prue-

\ CLAVE

bas y la depuración. El depósito d e b e ser capaz de controlar una amplia variedad de tipos de objetos,

El depósito debe ser

incluso texto, gráficos, m a p a s de bits, d o c u m e n t o s complejos y objeto únicos c o m o

copaz de montener los

definiciones de pantallas e informes, archivos de objeto, d a t o s de prueba y resulta-

E£S relacionados con

dos. Un depósito m a d u r o sigue las versiones de los objetos con grados arbitrarios de

cuchos versiones iferentes del software. Más mportonte, debe ofrecer los mecanismos

granularidad; por ejemplo, se p u e d e seguir u n a sola definición de d a t o s o un conjunto de módulos. G e s t i ó n d e l s e g u i m i e n t o d e la d e p e n d e n c i a y d e l c a m b i o .

El depósito gestio-

poro ensamblar dichos

na u n a amplia variedad de relaciones entre los objetos de configuración que guarda.

ECS en una

Se incluyen relaciones entre entidades y procesos empresariales, entre las partes de

configuración

un diseño de aplicación, entre c o m p o n e n t e s de diseño y la arquitectura de informa-

especifica de versión.

ción del proyecto, entre e l e m e n t o s de diseño y otros productos de trabajo, etcétera. Algunas de e s t a s relaciones son m e r a m e n t e asociaciones, y a l g u n a s son d e p e n d e n cias o relaciones obligatorias. La habilidad con que se da seguimiento a todas e s t a s relaciones es crucial para la integridad de la información guardada en el depósito y la generación de productos de trabajo b a s a d o s en ella, y es una de las aportaciones m á s importantesTM del concepto de depósito a la mejora del proceso de desarrollo de software. Por ejemplo, si se modifica un diagrama de clase UML, el depósito p u e d e detectar si las clases relacio-

PDF Editor

nadas, las definiciones de interfaz y los c o m p o n e n t e s de código también requieren modificación y pueden colocar en la atención del desarrollador los ECS afectados.

Seguimiento d e requisitos.

Esta función especial ofrece la habilidad de seguir

todos los c o m p o n e n t e s y entregables de diseño y construcción que resulten de una determinación específica de requisitos (seguimiento hacia adelante o seguimiento

806

PARTE C U A T R O


p r o p i a m e n t e dicho). Además, proporciona la habilidad de identificar qué requisitos generaron algún producto de trabajo d a d o (seguimiento hacia a t r á s o rastreo). G e s t i ó n d e la c o n f i g u r a c i ó n .

Una gestión de la configuración facilita la conser-

vación del rastro de u n a serie de configuraciones que representan hitos específicos del proyecto o liberaciones de producción. Rutas d e auditoría.

Una ruta de auditoría establece información adicional acerca

de cuándo, por qué y por quién se hicieron los cambios. La información acerca de la fuente de los cambios se p u e d e ingresar c o m o atributos de objetos específicos en el depósito.

El proceso de gestión de la configuración del s o f t w a r e define u n a serie de t a r e a s que tienen cuatro objetivos principales: 1) identificar t o d o s los elementos que colectivam e n t e definen la configuración del software; 2) gestionar los cambios a u n o o más de dichos elementos; 3) facilitar la construcción de diferentes versiones de una aplicación; y 4) garantizar que la calidad del s o f t w a r e se conserva c o n f o r m e la configuración evoluciona a lo largo del tiempo. Un proceso que logra estos objetivos no necesita ser burocrático y molesto, pero sí d e b e caracterizarse en u n a forma que permita que un equipo de s o f t w a r e desarrolle respuestas a u n conjunto de preguntas complejas: • ¿Cómo identifica un equipo de s o f t w a r e los elementos discretos de u n a configuración de software? • ¿Cómo gestiona una organización las n u m e r o s a s versiones existentes de un p r o g r a m a (y su documentación) en u n a forma que permita que el c a m b i o se qué preguntas se debe diseñar un proceso de GCS?

a c o m o d e eficientemente? • ¿Cómo controla una organización los c a m b i o s a n t e s y d e s p u é s de que el s o f t w a r e se libere al cliente? • ¿Quién tiene la responsabilidad de aprobar y clasificar los cambios? • ¿Cómo se garantiza que los cambios se hayan realizado a d e c u a d a m e n t e ? • ¿Con qué m e c a n i s m o se valoran otros cambios que se realizan? Estas preguntas c o n d u c e n a la definición de las cinco t a r e a s de la GCS ilustradas en TM auditoría de la la figura 27.4: identificación, control de la versión, control del cambio, configuración e informe. En la misma figura las tareas de la GCS se aprecian c o m o c a p a s concéntricas. Los

PDF Editor

ECS fluyen hacia a f u e r a a través de dichas c a p a s a lo largo de su vida útil, y a final de c u e n t a s se convierten e n parte de la configuración del s o f t w a r e de u n a o m á s versiones de u n a aplicación o sistema. Conforme un ECS se m u e v e a través de una capa, las acciones q u e implica cada capa de p r o c e s o d e la GCS pueden o no aplicarse. Por ejemplo, c u a n d o se crea un n u e v o ECS debe ser identificado. Sin embargo, si

CAPÍTULO 27

GESTIÓN DEL CAMBIO

807

Capas del proceso d e SCS.

Versión software ¡torio d e c o n f i g u r a d Control d e la versión Control d e j c a m b i ó Identificación /

n o se solicitan c a m b i o s p a r a el ECS, la c a p a d e control de c a m b i o n o s e a p l i c a . El ECS s e a s i g n a a u n a v e r s i ó n e s p e c í f i c a del s o f t w a r e (entran e n j u e g o m e c a n i s m o s d e c o n t r o l d e la versión). S e c o n s e r v a u n r e g i s t r o del ECS (su n o m b r e , f e c h a d e c r e a ción, d e s i g n a c i ó n d e v e r s i ó n , etc.) p a r a p r o p ó s i t o s d e a u d i t o r í a de la c o n f i g u r a c i ó n e i n f o r m e s a q u i e n e s n e c e s i t e n s a b e r l o . En las s e c c i o n e s s i g u i e n t e s s e e x a m i n a n c o n m á s d e t a l l e c a d a u n a d e e s t a s c a p a s del p r o c e s o d e GCS.

27.3.1 Identificación d e objetos en la configuración del software El c o n t r o l y la g e s t i ó n d e e l e m e n t o s d e c o n f i g u r a c i ó n del s o f t w a r e r e q u i e r e n o m b r a r cada u n o por separado y luego o r g a n i z a d o mediante un enfoque orientado a objetos. Es p o s i b l e identificar d o s tipos d e o b j e t o s [CH089]: b á s i c o s y a g r e g a d o s . 3 Un objeto

básico e s u n a u n i d a d d e i n f o r m a c i ó n c r e a d a p o r u n i n g e n i e r o d e s o f t w a r e

d u r a n t e el análisis, el d i s e ñ o , el c ó d i g o o las p r u e b a s . Por e j e m p l o , u n o b j e t o b á s i c o p u e d e ser u n a sección d e u n a especificación de requisitos, p a r t e de u n m o d e l o d e diseño, c ó d i g o f u e n t e p a r a u n c o m p o n e n t e , o un c o n j u n t o de c a s o s d e p r u e b a q u e se utilizan p a r a ejercitar el código. Un objeto agregado

e s u n a colección d e o b j e t o s b á s i c o s

y o t r o s o b j e t o s a g r e g a d o s . En la figura 27.2 E s p e c i f i c a c i o n D i s e ñ o e s TM un objeto agreg a d o . C o n c e p t u a l m e n t e , e s posible verlo c o m o u n a lista n o m b r a d a (identificada) d e p u n t e r o s q u e especifican o b j e t o s b á s i c o s c o m o s o n M o d e l o D a t o s y C o m p o n e n t e N .

PDF Editor 3

El concepto de objeto agregado [GUS89] se ha propuesto como un mecanismo para representar una versión completa de una configuración de software

PARTE CUATRO

%

CLAVE

Los interrelociones establecidos para los


Cada objeto tiene un conjunto de características distintivas que lo identifican m a n e r a exclusiva: u n nombre, u n a descripción, u n a lista de recursos, y una "ir zación". El n o m b r e del objeto es u n a c a d e n a de caracteres que identifican al sin ambigüedades. La descripción del objeto es u n a lista de e l e m e n t o s de datos identifican el tipo de ECS (por ejemplo, elemento modelo, programa, datos)

objetos de

representa el objeto, un identificador de proyecto e información de cambio y / o

configuración permiten

sión.

que un ingeniero de software evalúe el impacto del cambio.

La identificación del objeto de configuración también p u e d e considerar las reí: n e s entre los objetos nombrados. Por ejemplo, con la utilización de notación simplí DiagramadeClase < p a r t e d e > ModeloAnalisis; ModeloAnalisis < p a r l e d e > EspecificacionRequisitos;

se crea u n a jerarquía de ECS. (CONSEJO^ Incluso si lo tose de dolos del proyecto ofrece la habilidad pora establecer dichas ielaciones, éstos consumen tiempo en su establecimiento y dificultan mantener lo octuolizoáón. Aunque son muy útiles pata el anúlisis de impacto, no son esenciales pora la gestión global del cambio.

En m u c h o s casos, los objetos están interrelacionados a través de r a m a s de jerarquía de objetos. Dichas relaciones estructurales c r u z a d a s se representan e n la forma siguiente: ModeloDatos < i n t e r t e l a c i o n a d o > ModeloFlujoDatos ModeloDatos < ¡ n t e r r e l a c i o n a d o > CasoPruebaClaseM

En el primer c a s o la interrelación e s entre un objeto compuesto, mientras que la segunda relación es entre un objeto agregado ( M o d e l o D a t o s ) y un objeto básicc (CasoPruebaClaseM). El e s q u e m a de identificación para los objetos de configuración debe reconoce: que los objetos evolucionan a lo largo del proceso de software. Antes de que ur objeto se convierta e n línea b a s e p u e d e cambiar m u c h a s veces, e incluso d e s p u é s de establecida una línea b a s e los c a m b i o s quizá s e a n muy frecuentes.

27.3.2 Control d e la versión El control d e la versión combina procedimientos y h e r r a m i e n t a s para gestionar diferentes versiones de objetos de configuración que se crean d u r a n t e el proceso del software. Un sistema de control de la versión implementa o está directamente inte-

\

CLAVE

Uno facilidad "de hechura" permite a un

grado con cuatro g r a n d e s capacidades: 1) una b a s e de datos del proyecto (depósito) que guarda todos los objetos de configuración relevantes; 2) u n a capacidad de ges tión de la versión que a l m a c e n a t o d a s las versiones de un objeto de configuración (o permite que se construya cualquier versión e m p l e a n d o diferencias TM de versiones anteriores); 3) u n a facilidad de hechura que permita al ingeniero de s o f t w a r e recopi-

ingeniero de software

lar todos los objetos de configuración relevantes y construir u n a versión específica

obtener todos los objetos de

del software. Además, los sistemas de control de la versión y de control del cambio

PDF Editor configuración

relevantes y construir

con frecuencia implementan u n a capacidad de seguimiento m a d a seguimiento

de conflictos (también lla-

de bugs) que permiten al equipo registrar y hacer el seguimiento

v a versión específica

del e s t a d o de todos los conflictos destacados que se asocian con cada objeto de con-

é l software.

figuración.

CAPÍTULO 27

GESTIÓN DEL CAMBIO

809

"Cualquier cambio, incluso u n o pora mejorar, está acompañado con inconvenientes e incomodidades." Amold Bennetí

Varios s i s t e m a s d e c o n t r o l d e la v e r s i ó n e s t a b l e c e n u n conjunto

de cambio

—una

c o l e c c i ó n de t o d o s l o s c a m b i o s (con cierta c o n f i g u r a c i ó n de línea base)— q u e r e q u i e r e la c r e a c i ó n d e u n a versión e s p e c í f i c a del s o f t w a r e . Dart [DAR91] a d v i e r t e q u e u n c o n j u n t o d e c a m b i o s " c a p t u r a t o d o s los c a m b i o s d e t o d o s los a r c h i v o s e n la c o n f i g u r a c i ó n j u n t o c o n la r a z ó n p a r a los c a m b i o s y d e t a l l e s d e q u i é n los h i z o y cuándo". Es p o s i b l e identificar v a r i o s c o n j u n t o s d e c a m b i o n o m b r a d o s p a r a u n a a p l i c a c i ó n o s i s t e m a . E s t o p e r m i t e q u e un i n g e n i e r o d e s o f t w a r e c o n s t r u y a u n a v e r s i ó n del s o f t w a r e al e s p e c i f i c a r los c o n j u n t o s d e c a m b i o (por n o m b r e ) q u e s e d e b e n aplicar a la c o n f i g u r a c i ó n d e l í n e a b a s e . Esto s e logra a p l i c a n d o u n e n f o q u e d e modelado tema.

El m o d e l o d e s i s t e m a c o n t i e n e 1) u n a plantilla

de sis-

q u e incluye u n a j e r a r q u í a d e

c o m p o n e n t e s y u n " o r d e n d e c o n s t r u c c i ó n " p a r a los c o m p o n e n t e s q u e d e s c r i b e c ó m o se d e b e c o n s t r u i r el s i s t e m a , 2) r e g l a s d e c o n s t r u c c i ó n y 3) r e g l a s de verificación. 4 D u r a n t e las p a s a d a s d o s d é c a d a s s e h a n p r o p u e s t o v a r i o s e n f o q u e s a u t o m a t i z a d o s p a r a el control d e la v e r s i ó n . La principal d i f e r e n c i a e n l o s e n f o q u e s e s la s o f i s ticación d e l o s a t r i b u t o s q u e s e utilizan e n la c o n s t r u c c i ó n d e v e r s i o n e s e s p e c í f i c a s y v a r i a n t e s d e u n s i s t e m a y los m e c a n i s m o s del p r o c e s o de c o n s t r u c c i ó n . HERRAMIENTAS DE SOFTWARE

El Sistema d e Versiones Concurrentes (SVC) El empleo d e herramientas con que lograr el

del software. Esto se logra integrando al SVC otras

control d e la versión e s esencial p a r a u n a

herramientas (por ejemplo, Makefile).

El SVC no

gestión del c a m b i o eficaz. El sistema de versiones

implemento un proceso d e control d e c a m b i o (por ejemplo,

concurrentes

solicitudes d e cambio, informes d e cambio, seguimiento d e

(SVC; CVS, Concurrent Versions System) es

una herramienta ampliamente e m p l e a d a en el control d e versiones. Originalmente d i s e ñ a d a p a r a c ó d i g o fuente, pero útil p a r a cualquier archivo b a s a d o en texto, el sistema SVC 1) establece un depósito simple, 2) conserva todas las versiones d e un archivo e n un archivo con un solo n o m b r e al a l m a c e n a r sólo las diferencias entre versiones progresivas del archivo original, y 3) protege un archivo contra cambios simultáneos al establecer diferentes directorios p a r a c a d a desarrollador, con lo que se aislan uno d e otro. El SVC mezcla los cambios c u a n d o c a d a desarrollador completa su t r a b a j o .

bugs). Pese a sus limitaciones, el SVC "es un sistema dominante en el control d e versiones, transparente respecto a la red y d e fuente a b i e r t a [que] es útil p a r a todos, desde desarrolladores individuales hasta g r a n d e s equipos segmentados" [CVS02], Su arquitectura cliente/servidor permite que los usuarios a c c e d a n a los archivos mediante conexiones d e Internet y su filosofía d e fuente a b i e r t a

TM

facilita su disponibilidad en la mayoría d e las plataformas populares. El SVC está disponible sin costo p a r a entornos

PDF Editor Es importante notar q u e el SVC n o es un sistema "de

construcción"; esto es, no construye una versión específica

W i n d o w s , Macintosh y Unix. Visítese www.cvshome.org p o r a mayores detalles.

4 También es posible consultar el modelo de sistema para valorar cómo un cambio en un componente impactará a otros componentes.

810

PASTE CUATRO


27.3.3 Control del cambio La realidad del control del c a m b i o e n u n c o n t e x t o m o d e r n o de i n g e n i e r í a del softw a r e la r e s u m i ó b e l l a m e n t e J a m e s Bach [BAC98]: El control del cambio es vital. Pero las fuerzas que lo hacen necesario también lo tornan irritante. Nos preocupamos por los cambios porque una pequeña perturbación en el código puede crear una gran falla en el producto. Pero también puede resolver una gran falla o permitir maravillosas nuevas capacidades. Nos preocupamos por los cambios porque un solo desarrollador solitario podría hundir el proyecto; aunque en las mentes de dichos solitarios se originan ideas brillantes, y un proceso de control del cambio gravoso podría desalentarlos efectivamente de realizar trabajo creativo. B a c h r e c o n o c e q u e s e e n f r e n t a un a c t o d e equilibrio. D e m a s i a d o control del c a m b i o , y s e c r e a n p r o b l e m a s ; p o c o , y se c r e a n o t r o s p r o b l e m a s . "0 orte del progreso es prese»vor el orden entre el cambio, y preservar el cambio entre el orden," AHred North Whiteheod En un g r a n p r o y e c t o d e i n g e n i e r í a d e s o f t w a r e el c a m b i o i n c o n t r o l a d o c o n d u c e r á p i d a m e n t e al c a o s . R e s p e c t o a t a l e s p r o y e c t o s el control del c a m b i o c o m b i n a p r o -

CLAVE Se debe destocor que «arias sofciludes de cambo pueden combinar» pora resultar en uno soto

c e d i m i e n t o s h u m a n o s y h e r r a m i e n t a s a u t o m a t i z a d a s . En la figura 2 7 . 5 s e ilustra e s q u e m á t i c a m e n t e el p r o c e s o d e c o n t r o l del c a m b i o . Se e m i t e u n a solicitud

de cam-

bio y s e e s t i m a p a r a e v a l u a r los m é r i t o s t é c n i c o s , l o s p o t e n c i a l e s e f e c t o s c o l a t e r a l e s , el i m p a c t o global s o b r e o t r o s o b j e t o s d e c o n f i g u r a c i ó n y f u n c i o n e s del s i s t e m a , y el COStO p r o y e c t a d o del c a m b i o . Los r e s u l t a d o s d e la e v a l u a c i ó n s e p r e s e n t a n c o m o un

0(1 y que te 0(1

informe de cambio,

ifluolmenle resulten en cambios o múltiples

s o n a o g r u p o q u e t o m a n la d e c i s i ó n final a c e r c a del e s t a d o y la prioridad del c a m -

configuración.

q u e lo utiliza u n a autoridad

del control del cambio

bio. Se g e n e r a u n a orden de cambio en la ingeniería

(ACC): u n a p e r -

(OCI) p a r a c a d a c a m b i o a p r o b a d o .

La OCI d e s c r i b e el c a m b i o q u e s e d e b e realizar, las r e s t r i c c i o n e s i n s o s l a y a b l e s y l o s criterios d e revisión y a u d i t o r í a . El o b j e t o q u e se c a m b i a r á s e c o l o c a e n u n d i r e c t o r i o q u e c o n t r o l e e x c l u s i v a m e n te el i n g e n i e r o d e s o f t w a r e q u e r e a l i z a el c a m b i o . Un s i s t e m a d e control d e la v e r sión (véase el r e c u a d r o a c e r c a d e SVC) actualiza el a r c h i v o original u n a v e z r e a l i z a d o

^CONSEJO^

el c a m b i o . C o m o a l t e r n a t i v a , el o b j e t o q u e s e c a m b i a r á p u e d e "salir" d e la b a s e d e d a t o s del p r o y e c t o (depósito), r e a l i z a r el c a m b i o y a p l i c a r las a c t i v i d a d e s a p r o p i a d a s

Lo confusión conduce oemes, olgunosde ellos bostonte serios. B control del occeso y de lo sinaonizoción nton confusión, [mfliense ferro««Bitas de control de knKiánydel

de SQA. L u e g o el o b j e t o " e n t r a " a la b a s e de d a t o s y s e aplican m e c a n i s m o s a d e c u a d o s d e c o n t r o l d e v e r s i ó n (sección 27.3.2) p a r a c r e a r la s i g u i e n t e v e r s i ó n del s o f t ware.

TM

E s t o s m e c a n i s m o s de c o n t r o l d e la v e r s i ó n , i n t e g r a d o s e n el p r o c e s o d e c o n t r o l

PDF Editor

de c a m b i o s , i m p l e m e n t a n d o s i m p o r t a n t e s e l e m e n t o s de g e s t i ó n del c a m b i o : c o n t r o l del a c c e s o y d e la s i n c r o n i z a c i ó n . El control del acceso rige q u é i n g e n i e r o s d e s o f t -

w a r e e s t á n a u t o r i z a d o s p a r a i n g r e s a r y m o d i f i c a r u n o b j e t o d e c o n f i g u r a c i ó n particular. El control de la sincronización

a y u d a a g a r a n t i z a r q u e los c a m b i o s p a r a l e l o s ,

e f e c t u a d o s p o r d o s p e r s o n a s d i f e r e n t e s , n o s e s o b r e s c r i b e n u n o s o b r e otro[HAR89].

CAPÍTULO 27

GESTIÓN DEL CAMBIO

811

A l g u n o s l e c t o r e s q u i z á c o m i e n c e n a s e n t i r s e i n c ó m o d o s c o n el g r a d o d e b u r o c r a c i a q u e implica la d e s c r i p c i ó n del p r o c e s o d e c o n t r o l del c a m b i o m o s t r a d a en la figura 27.5. Este s e n t i m i e n t o e s c o m ú n . Sin las s a l v a g u a r d a s a d e c u a d a s el c o n t r o l del c a m b i o p u e d e r e t r a s a r el p r o g r e s o y c r e a r b u r o c r a c i a y p a p e l e o i n n e c e s a r i o s . La m a y o r í a d e los d e s a r r o l l a d o r e s de s o f t w a r e c o n m e c a n i s m o s d e control del c a m b i o ( d e s a f o r t u n a d a m e n t e m u c h o s n o los tienen) h a c r e a d o v a r i a s c a p a s d e control p a r a a y u d a r s e a evitar los p r o b l e m a s m e n c i o n a d o s aquí. A n t e s d e q u e u n ECS se c o n v i e r t a e n línea b a s e s ó l o s e n e c e s i t a a p l i c a r control de cambio informal.

El d e s a r r o l l a d o r del o b j e t o d e c o n f i g u r a c i ó n (ECS) e n c u e s t i ó n t i e n e

3 proceso d e control d e l cambio.

S e r e c o n o c e la n e c e s i d a d d e l c a m b i o

I Solicitud d e c a m b i o p o r p o r t e d e l u s u a r i o

I Evaluación del desarrollador

i

S e g e n e r a informe d e c a m b i o

La a u t o r i d a d d e control d e l c a m b i o d e c i d e

Solicitud s e p o n e en fila p a r a la a c c i ó n , s e g e n e r a O C I

I

Asignación d e individuos p a r a objetos d e configuración

í

S e n i e g a la solicitud d e c a m b i o

Í

S e informa el u s u a r i o

" S a l i d a " d e o b j e t o s d e c o n f i g u r a c i ó n (elementos)

I S e h a c e el c a m b i o

i Revisión (auditoría] d e l c a m b i o

I " E n t r a d a " d e los e l e m e n t o s d e c o n f i g u r a c i ó n q u e h a n c a m b i a d o

I

E s t a b l e c i m i e n t o d e u n a línea b a s e p a r a p r u e b a s

Realización d e actividades d e garantía d e calidad y d e p r u e b a s

I

" P r o m o c i ó n " d e los c a m b i o s p a r a incluirlos e n la s i g u i e n t e l i b e r a c i ó n (revisión)

TM

Reconstrucción d e la versión a p r o p i a d a d e l s o f t w a r e

PDF Editor I

Revisión (auditoría) d e l c a m b i o p a r a l o d o s los e l e m e n t o s d e c o n f i g u r a c i ó n

\

Inclusión d e los c a m b i o s e n la n u e v a v e r s i ó n

J

Distribución d e la n u e v a <

812

PARTE CUATRO

ÔNSEJO^ Óptese por un poco más de control de cambio del que se crea que necesitará. Es probable que demasiado será lo cantidad correcta.


la posibilidad d e r e a l i z a r c u a l e s q u i e r a c a m b i o s j u s t i f i c a d o s p o r el p r o y e c t o y los r e q u i s i t o s t é c n i c o s (en t a n t o l o s c a m b i o s n o a f e c t e n r e q u i s i t o s d e s i s t e m a mas a m p l i o s q u e s e e n c u e n t r a n f u e r a del á m b i t o d e t r a b a j o del d e s a r r o l l a d o r ) . U n a vez q u e el o b j e t o h a y a e x p e r i m e n t a d o u n a revisión t é c n i c a f o r m a l y h a y a s i d o a p r o b a d o s e p u e d e c r e a r u n a línea b a s e . 5 U n a v e z q u e u n ECS s e c o n v i e r t e e n línea b a s e se i m p l e m e n t a u n control de cambio

a nivel del proyecto.

Ahora, para realizar un cam

bio, el d e s a r r o l l a d o r d e b e o b t e n e r la a p r o b a c i ó n del g e s t o r del p r o y e c t o (si el c a m b : : e s "local") o d e la ACC si el c a m b i o a f e c t a o t r o s ECS. En a l g u n o s c a s o s , la g e n e r a ción f o r m a l d e las s o l i c i t u d e s d e c a m b i o , los i n f o r m e s d e c a m b i o y l a s OC1 s e distribuyen. Sin e m b a r g o , s e lleva a c a b o la evaluación d e c a d a c a m b i o , y t o d o s los c a m b i o s se siguen y revisan. C u a n d o el p r o d u c t o d e s o f t w a r e s e libera e n t r e los c l i e n t e s s e instituye el contro de cambio formal.

En la figura 2 7 . 5 se h a e s b o z a d o el p r o c e d i m i e n t o d e c o n t r o l de

cambio formal. "El combio es inevitable, excepto poro los máquinas expendedoras." Calcomanía en on parachoques La a u t o r i d a d d e control del c a m b i o j u e g a u n p a p e l a c t i v o e n la s e g u n d a y t e r c e r a c a p a s del control. D e p e n d i e n d o del t a m a ñ o y c a r á c t e r d e u n p r o y e c t o d e s o f t w a r e la ACC p u e d e e s t a r c o m p u e s t a d e u n a p e r s o n a (el g e s t o r del proyecto) o v a r i a s pers o n a s (por e j e m p l o , r e p r e s e n t a n t e s d e s o f t w a r e , h a r d w a r e , i n g e n i e r í a d e b a s e s de d a t o s , s o p o r t e , m e r c a d o t e c n i a ) . El p a p e l d e la ACC e s t e n e r u n a visión global, e s t o es: e v a l u a r el i m p a c t o del c a m b i o m á s allá del ECS e n c u e s t i ó n . ¿ C ó m o a f e c t a r á el c a m b i o al h a r d w a r e ? ¿ C ó m o a f e c t a r á al d e s e m p e ñ o ? ¿ C ó m o m o d i f i c a r á la p e r c e p ción del cl i ente a c e r c a del p r o d u c t o ? ¿ C ó m o a f e c t a r á la c a l i d a d y fiabilidad del p r o d u c t o ? E s t a s y m u c h a s o t r a s p r e g u n t a s l a s a b o r d a la ACC. HOGARSEGURO

Problemas en la GCS El e s c e n a r i o : Oficina de Doug

La conversación:

Milier c u a n d o comienza el proyecto del software

D o u g : Yo sé q u e es muy pronto, p e r o tenemos que

HogarSeguro.

hablar a c e r c a d e la gestión del c a m b i o .

Los actores: I

TM

ingeniería del software d e HogarSeguro)

y Vinod Raman,

Jamie Lazar y otros miembros del e q u i p o d e ingeniería

V i n o d (ríe): Apenas. Mercadotecnia llamó esta m a ñ a n a con unos cuantos "segundos pensamientos" N a d a importante, p e r o es sólo el comienzo.

PDF Editor del software del p r o d u d o .

5

Se puede crear una linea base también por otras razones. Por ejemplo, cuando se crean "construcciones diarias" todos los componentes que entran en un tiempo dado se convierten en la linea base para el trabajo del día siguiente.

CAPÍTULO 27

GESTIÓN DEL CAMBIO

Hemos sido bastante informales a c e r c a d e la

813

cómo conservamos los registros d e lo q u e a f e c t a el

del cambio en proyectos anteriores.

cambio.

.o sé, pero éste es mayor y m á s visible, y según

D o u g : Segundo, tenemos q u e obtener u n a herramienta

(asiente con la c a b e z a ) : Fuimos asesinados

d e GCS realmente buena p a r a control del c a m b i o y d e la versión.

; incontrolados en el proyecto d e control d e la en el h o g a r . . . recuerda las d e m o r a s q u e . . .

frunce el ceño): Una pesadilla que prefiero no

1

J a m i e : Podemos construir u n a b a s e d e datos p a r a todos nuestros productos d e t r a b a j o . V i n o d : Se llaman ECS e n este contexto, y la m a y o r í a d e las b u e n a s herramientas o f r e c e n cierto soporte p a r a eso.

• Asi q u e q u é hacemos. Como lo veo, tres cosas. Primero, tenemos que :r, o pedir prestado, un proceso d e control d e

D o u g : Ese e s un buen comienzo, a h o r a tenemos q u e . . . J a m i e : O y e , Doug: dijiste que e r a n tres cosas.,. D o u g ( s o n r í e ) : Tercera: todos tenemos que

2 Te

refieres a c ó m o la gente solicita los cambios?

Si, pero también c ó m o evaluamos el cambio, c u á n d o hacerlo ¡si eso es lo q u e decidimos) y

comprometernos a seguir el proceso d e gestión del c a m b i o y usar las herramientas, sin importar cuáles sean, ¿de a c u e r d o ?

27.3.4 Auditoría de la configuración La identificación, el control d e la v e r s i ó n y el control del c a m b i o a y u d a n al d e s a r r o Ilador del s o f t w a r e a m a n t e n e r el o r d e n e n lo q u e de o t r o m o d o s e r i a u n a s i t u a c i ó n c a ó t i c a e i n e s t a b l e . Sin e m b a r g o , incluso el m e c a n i s m o d e control m á s e x i t o s o s ó l o s i g u e u n c a m b i o h a s t a q u e n o s e g e n e r a u n a OCI. ¿ C ó m o se p u e d e g a r a n t i z a r q u e el c a m b i o s e h a i m p l e m e n t a d o c o n p r o p i e d a d ? La r e s p u e s t a e s doble: 1) r e v i s i o n e s t é c n i c a s f o r m a l e s y 2) a u d i t o r í a d e la c o n f i g u r a c i ó n del s o f t w a r e . La revisión t é c n i c a f o r m a l ( p r e s e n t a d a c o n detalle en el c a p í t u l o 26) s e e n f o c a e n la c o r r e c c i ó n t é c n i c a del o b j e t o d e c o n f i g u r a c i ó n q u e s e h a m o d i f i c a d o . Los r e v i s o r e s e v a l ú a n el ECS p a r a d e t e r m i n a r s u c o n s i s t e n c i a c o n o t r o s ECS, o m i s i o n e s o p o t e n c i a l e s e f e c t o s c o l a t e r a l e s . Se d e b e r e a l i z a r u n a revisión t é c n i c a f o r m a l e n casi la m a y o r í a d e los c a m b i o s triviales. U n a auditoría

de configuración

del software

c o m p l e m e n t a la revisión t é c n i c a for-

m a l al a b o r d a r las s i g u i e n t e s p r e g u n t a s : 1.

¿Se h a r e a l i z a d o el c a m b i o e s p e c i f i c a d o e n la OCI? ¿Se h a n i n c o r p o r aTM do modificaciones

2.

adicionales?

¿Se h a r e a l i z a d o u n a revisión t é c n i c a f o r m a l p a r a e v a l u a r la c o r r e c c i ó n téc-

PDF Editor ¿Cióles S M las

nica?

3.

que se durante de ?

¿Se h a s e g u i d o el p r o c e s o d e s o f t w a r e ? ¿Se h a n a p l i c a d o a d e c u a d a m e n t e los e s t á n d a r e s d e i n g e n i e r í a del s o f t w a r e ?

4.

¿El c a m b i o s e h a r e s a l t a d o e n el ECS? ¿Se h a n e s p e c i f i c a d o la f e c h a y el a u t o r

del c a m b i o ? ¿Los a t r i b u t o s del o b j e t o d e c o n f i g u r a c i ó n r e f l e j a n el c a m b i o ?

814

PARTE C U A T R O

5.


¿Se h a n s e g u i d o los p r o c e d i m i e n t o s d e GCS p a r a d e s t a c a r el c a m b i o , regist r a r l o e i n f o r m a r d e él?

6.

¿ T o d o s l o s ECS r e l a c i o n a d o s s e h a n a c t u a l i z a d o d e m a n e r a a d e c u a d a ?

En a l g u n o s c a s o s , l a s p r e g u n t a s d e la a u d i t o r í a s e p l a n t e a n c o m o p a r t e d e u n a rev*sión t é c n i c a f o r m a l . Sin e m b a r g o , c u a n d o la GCS e s u n a actividad f o r m a l , la a u d i : : ría d e GCS la lleva a c a b o por s e p a r a d o el g r u p o d e a s e g u r a m i e n t o de la c a l i d a ; Tales a u d i t o r í a s f o r m a l e s d e c o n f i g u r a c i ó n t a m b i é n a s e g u r a n q u e los ECS correct así (por v e r s i ó n ) s e h a n i n c o r p o r a d o e n u n a c o n s t r u c c i ó n e s p e c í f i c a y q u e t o d a la doc_ m e n t a c i ó n e s t á a c t u a l i z a d a y e s c o n s i s t e n t e c o n la v e r s i ó n q u e s e h a c o n s t r u i d o .

(CONSEJO^

27.3.5 Informe de estado El informe

ílabórese uno lista de "necesita conocer" para cada objeto de configuración y consérvese actualizada. Cuando se realice un cambio, es necesario asegurarse de que todos los de la lista sean notificados.

de estado de la configuración

(a v e c e s l l a m a d o contabilidad

de estado) es

u n a t a r e a d e GCS q u e r e s p o n d e l a s s i g u i e n t e s p r e g u n t a s : 1) ¿ q u é o c u r r i ó ? 2) ¿ q u i c io h i z o ? 3) ¿ c u á n d o o c u r r i ó ? 4) ¿ q u é o t r a c o s a s e r á a f e c t a d a ? En la figura 2 7 . 5 s e m u e s t r a el f l u j o d e i n f o r m a c i ó n p a r a el i n f o r m e d e e s t a d o ce la c o n f i g u r a c i ó n (IEC). C a d a v e z q u e s e le a s i g n a u n a identificación n u e v a o actual: z a d a a u n ECS s e e f e c t ú a u n a e n t r a d a d e IEC. C a d a v e z q u e la ACC a p r u e b a u n cam bio (es decir, s e e x p i d e u n a OCI) s e g e n e r a u n a e n t r a d a e n el IEC. C a d a v e z q u e se r e a l i z a u n a a u d i t o r í a d e la c o n f i g u r a c i ó n los r e s u l t a d o s s e r e p o r t a n c o m o p a r t e de a t a r e a d e IEC. El r e s u l t a d o del IEC e s p o s i b l e c o l o c a r l o e n u n a b a s e d e d a t o s e n línea o e n u n sitio Web, d e m o d o q u e los d e s a r r o l l a d o r e s y los e n c a r g a d o s del m a n t e n i m i e n t o del s o f t w a r e p u e d e n t e n e r a c c e s o a la i n f o r m a c i ó n del c a m b i o m e d i a r . : ; c a t e g o r í a s clave. A d e m á s , s e g e n e r a u n IEC c o n r e g u l a r i d a d y s u finalidad e s m a n t e n e r a los g e s t o r e s y p r o f e s i o n a l e s a l e r t a s a n t e d e los c a m b i o s i m p o r t a n t e s .


Soporte de la GCS Objetivo: Las herramientas de GCS proporcionan soporte a una o m á s d e las actividades del proceso e s t u d i a d a s en la sección 2 7 . 3 .

ClearCose,

desarrollada p o r Rational (www.rational.com),

ofrece una familia de funciones d e GCS. Concurrent

Versions Syslem (SVC), u n a herramienta d e

M e c á n i c a : La mayoría de tas m o d e r n a s herramientas d e

fuente a b i e r t a (www.cvshome.org), es u n o d e los

GCS funciona en conjunto con un depósito (un sistema d e

sistemas d e control d e versión m á s ampliamente

b a s e d e datos) y ofrecen mecanismos p a r a identificar, control d e la versión y el cambio, auditoría e informe.

e m p l e a d o s en la industria (véase un r e c u a d r o anterior). PVCS, distribuida p o r Merant (www.merant.com), ofrece

TM

Herramientas representativas 6

un conjunto completo d e herramientas d e G C S q u e son

CCC/Harvest,

aplicables tanto en software convencional c o m o en

distribuida p o r Computer Associates

(www.cai.com), es un sistema de GCS multiplataforma.

WebApps.

PDF Editor 6

y

Las herramientas mencionadas sólo representan una muestra de esta categoría. En la mayoría de los casos los nombres de las mismas son marcas registradas por sus respectivos desarrolladores

CAPÍTULO 27

/

f SourceForge,

GESTIÓN DEL CAMHO

distribuida p o r VA Software

815

Vesto, distribuida p o r C o m p a c (www.vestasys.org), es un

\

(sourceforge.net), ofrece gestión d e versión,

sistema d e GCS d e dominio público q u e p u e d e d a r

c a p a c i d a d e s de construcción, seguimiento d e

soporte tanto a proyectos pequeños (< 10 KLDC) como

p r o b l e m a s / b u g s y muchas otras características d e

a g r a n d e s ( 1 0 , 0 0 0 KLDC).

gestión. 5 .rroundSCM,

d e s a r r o l l a d a por S e a p i n e Software

(www.seapine.com), proporciona c a p a c i d a d e s

V

completas de gestión del cambio.

Una extensa lista d e herramientas comerciales y entornos p a r a GCS, se p u e d e encontrar en www.cmtoday.com/yp/commercial. html.

En la p a r t e 3 d e e s t e libro s e e s t u d i ó la n a t u r a l e z a e s p e c i a l d e las a p l i c a c i o n e s W e b y el p r o c e s o d e ingeniería W e b n e c e s a r i o p a r a construirlo. Entre las m u c h a s c a r a c terísticas q u e d i f e r e n c i a n a las W e b A p p s del s o f t w a r e c o n v e n c i o n a l s e e n c u e n t r a la n a t u r a l e z a u b i c u a del c a m b i o . La i n g e n i e r í a W e b utiliza u n m o d e l o d e p r o c e s o i n c r e m e n t a l iterativo (capítulo 16) q u e a p l i c a m u c h o s p r i n c i p i o s d e r i v a d o s del d e s a r r o l l o de s o f t w a r e ágil (capítulo 4). Al utilizar e s t e e n f o q u e , u n e q u i p o d e ingeniería c o n f r e c u e n c i a d e s a r r o l l a u n increm e n t o de W e b A p p e n u n p e r i o d o m u y c o r t o m e d i a n t e u n e n f o q u e b a s a d o e n el cliente. Los i n c r e m e n t o s s u b s e c u e n t e s a g r e g a n c o n t e n i d o y f u n c i o n a l i d a d a d i c i o n a l e s , y tal v e z c a d a u n o i m p l e m e n t e c a m b i o s q u e c o n d u z c a n a c o n t e n i d o a u m e n t a d o , m e j o r facilidad de uso, e s t é t i c a m e j o r a d a , m e j o r n a v e g a c i ó n , d e s e m p e ñ o a u m e n t a d o y m a y o r s e g u r i d a d . En c o n s e c u e n c i a , e n el m u n d o ágil de la i n g e n i e r í a W e b el c a m b i o se ve de m a n e r a u n p o c o d i f e r e n t e . Los i n g e n i e r o s W e b d e b e n a d o p t a r el c a m b i o , e i n c l u s o u n típico e q u i p o ágil evita t o d a s las c o s a s q u e p a r e c e n p e s a d o s p r o c e s o s , b u r o c r á t i c o s y f o r m a l e s . Por lo g e n e ral, s e c o n s i d e r a ( a u n q u e i n c o r r e c t a m e n t e ) q u e la gestión d e la c o n f i g u r a c i ó n del s o f t w a r e p o s e e e s t a s c a r a c t e r í s t i c a s . Esta a p a r e n t e c o n t r a d i c c i ó n s e r e s u e l v e al n o r e c h a z a r los principios, p r á c t i c a s y h e r r a m i e n t a s d e la GCS, s i n o m á s b i e n m o l d e á n d o l a s p a r a s a t i s f a c e r las n e c e s i d a d e s e s p e c i a l e s de los p r o y e c t o s d e ingeniería Web.

27.4.1 Problemas en la gestión d e la configuración p a r a WebApps C o n f o r m e l a s W e b A p p s s e v u e l v e n c a d a v e z m á s i m p o r t a n t e s p a r a la s o b r e v i v e n c i a y el c r e c i m i e n t o d e los n e g o c i o s , c r e c e la n e c e s i d a d de la g e s t i ó n d e la c TM onfiguración. ¿Por q u é ? P o r q u e sin c o n t r o l e s e f i c a c e s los c a m b i o s i n a d e c u a d o s a u n a W e b A p p ( r e c u é r d e s e q u e la i n m e d i a t e z y la e v o l u c i ó n c o n t i n u a s o n los a t r i b u t o s d o m i n a n t e s

PDF Editor ? ¿Qué • impacto Sene un cambio iescontrolado sobre una WebApp?

d e m u c h a s WebApps) c o n d u c i r í a n a la d i f u s i ó n n o a u t o r i z a d a d e i n f o r m a c i ó n d e un n u e v o p r o d u c t o ; f u n c i o n a l i d a d e r r ó n e a o p o b r e m e n t e p r o b a d a q u e f r u s t r a a los visit a n t e s a u n sitio Web; h o y o s e n la s e g u r i d a d q u e p o n e n e n peligro los s i s t e m a s intern o s d e la c o m p a ñ í a ; y o t r a s c o n s e c u e n c i a s e c o n ó m i c a m e n t e d e s a g r a d a b l e s o incluso desastrosas.

816

PARTE C U A T R O


Las estrategias generales para la gestión de configuración del s o f t w a r e (GCS) descritas en este capítulo son aplicables, p e r o las tácticas y h e r r a m i e n t a s se deber adaptar para que concuerden con la naturaleza única de las WebApps. Se deben considerar cuatro t e m a s c u a n d o se desarrollen tácticas para la gestión de la configuración de la WebApp: contenido, personal, escalabilidad y políticas. Contenido.

Una WebApp típica contiene u n a amplia variedad de contenido: texto

gráficos, applets, guiones, archivos de audio/video, formatos, e l e m e n t o s de página activos, tablas, d a t o s clasificados p o r niveles y m u c h o s otros. El reto e s organizar este o c é a n o de contenido e n un c o n j u n t o racional de objetos de configuración (sección 27.1.4) y luego establecer m e c a n i s m o s de control de configuración a d e c u a d o s para dichos objetos. Personal.

Puesto que un porcentaje significativo del desarrollo de la WebApp con-

tinúa realizándose e n u n a forma ad hoc, cualquier persona involucrada en la WebApp p u e d e (y con frecuencia lo hace) crear contenido. Muchos creadores de contenido no tienen conocimientos de ingeniería del s o f t w a r e e ignoran por completo la importancia de la gestión de la configuración. Por lo tanto, la aplicación crece y cambia en una forma descontrolada. Escalabilidad.

Las técnicas y los controles aplicados a u n a WebApp p e q u e ñ a no

se escalan bien hacia arriba. No es inusual que una WebApp simple crezca signific a t i v a m e n t e conforme se implementan interconexiones con los sistemas de información existentes, b a s e s de datos, depósitos de datos y portales. Conforme crecen el t a m a ñ o y la complejidad, los cambios p e q u e ñ o s p u e d e n tener efectos de largo alcance e imprevistos que p u e d e n ser problemáticos. En consecuencia, el rigor de los m e c a n i s m o s de control de la configuración d e b e ser directamente proporcionales a la escala de la aplicación. Políticas.

¿Quién "posee" una WebApp? Esta pregunta se plantea en c o m p a ñ í a s

grandes y pequeñas, y su respuesta tiene un impacto significativo en las actividades de gestión y control asociadas con la IWeb. En ciertas instancias, los desarrolladores Web se ubican fuera de la organización TI, lo que crea potenciales dificultades de comunicación. Dart [DAR99] sugiere las siguientes p r e g u n t a s para ayudar a entender las políticas asociadas con la IWeb: M : ¿ c °m° s e • determina Quién t i e n e lo

• ¿Quién a s u m e la responsabilidad de la precisión de la información en el sitio Web?

responsabilidad de la GC de la

TMcalidad a n t e s * ¿ Q u i é n a s e g u r a que se h a n seguido los procesos de control de de que la información se publique en el sitio?

WÂpp?

• ¿Quién es el responsable de realizar los cambios?

PDF Editor • ¿Quién a s u m e el costo del cambio?

Las r e s p u e s t a s a e s t a s p r e g u n t a s ayudan a determinar a las p e r s o n a s que, dentro

de una organización, deben adoptar un proceso de gestión de la configuración para las WebApps.

CAPÍTULO 27

GESTIÓN DEL CAMBIO

817

27.4.2 Objetos de configuración WebApp Las W e b A p p s a b a r c a n u n a a m p l i a g a m a d e o b j e t o s d e c o n f i g u r a c i ó n : o b j e t o s d e c o n t e n i d o (por e j e m p l o , texto, g r á f i c o s , i m á g e n e s , video, audio), c o m p o n e n t e s f u n c i o n a l e s (por ejemplo, guiones, applets) y o b j e t o s de interfaz (por ejemplo, COM o CORBA). Los o b j e t o s W e b A p p se p u e d e n identificar ( a s i g n á n d o l e s n o m b r e s d e archivo) e n c u a l q u i e r f o r m a q u e s e a a p r o p i a d a p a r a la o r g a n i z a c i ó n . Sin e m b a r g o , s e r e c o m i e n d a n las s i g u i e n t e s c o n v e n c i o n e s p a r a g a r a n t i z a r q u e s e c o n s e r v a la c o m p a t i b i l i d a d e n t r e p l a t a f o r m a s c r u z a d a s : los n o m b r e s d e a r c h i v o d e b e n e s t a r limitados a 32 c a r a c t e r e s d e longitud, s e d e b e n evitar los n o m b r e s c o n m a y ú s c u l a s m e z c l a d a s o t o d a s m a y ú s c u l a s , así c o m o el u s o d e s u b r a y a d o s . A d e m á s , l a s r e f e r e n c i a s URL (vínculos) d e n t r o d e u n o b j e t o d e c o n f i g u r a c i ó n s i e m p r e d e b e n u s a r t r a y e c t o r i a s r e l a t i v a s (por ejemplo, .../productos/sensoresdealarma.html). T o d o el c o n t e n i d o d e la W e b A p p t i e n e f o r m a t o y e s t r u c t u r a . Los f o r m a t o s intern o s d e a r c h i v o los d i c t a el e n t o r n o d e c ó m p u t o e n el q u e s e a l m a c e n a el c o n t e n i d o . Sin e m b a r g o , el formato gue)

de representación

( u s u a l m e n t e l l a m a d o formato

de desplie-

s e d e f i n e c o n el etilo e s t é t i c o y las r e g l a s d e d i s e ñ o e s t a b l e c i d a s p a r a la

WebApp. La estructura

del contenido

d e f i n e u n a a r q u i t e c t u r a d e c o n t e n i d o ; e s t o es:

d e f i n e la f o r m a e n la q u e los o b j e t o s d e c o n t e n i d o s e e n s a m b l a n p a r a p r e s e n t a r i n f o r m a c i ó n significativa a u n u s u a r i o final. Boiko IBOI02] d e f i n e la e s t r u c t u r a c o m o " m a p a s q u e u s t e d t i e n d e s o b r e u n c o n j u n t o d e t r o z o s [objetos] d e c o n t e n i d o p a r a o r g a n i z a r l o s y h a c e r l o s a c c e s i b l e s a las p e r s o n a s q u e los n e c e s i t a n " .

27.4.3 Gestión del contenido La gestión del contenido

s e r e l a c i o n a c o n la g e s t i ó n d e la c o n f i g u r a c i ó n e n el s e n t i d o

e n q u e u n s i s t e m a d e g e s t i ó n del c o n t e n i d o (SGC) e s t a b l e c e u n p r o c e s o ( a p o y a d o p o r h e r r a m i e n t a s ) q u e a d q u i e r e c o n t e n i d o e x i s t e n t e (de u n a m p l i o o r d e n a m i e n t o d e o b j e t o s d e c o n f i g u r a c i ó n de la WebApp), los e s t r u c t u r a e n u n a f o r m a q u e p e r m i t e p r e s e n t a r l o s a un u s u a r i o final y l u e g o los o f r e c e al e n t o r n o del l a d o del cliente p a r a su despliegue. "La gestión del contenido es un antídoto para el frenesí informativo de la actualidad." Bob Boiko El u s o m á s c o m ú n del s i s t e m a de g e s t i ó n del c o n t e n i d o o c u r r e c u a n d o s e c o n s -

TM

truye u n a W e b A p p d i n á m i c a . Este tipo d e W e b A p p c r e a p á g i n a s W e b "al vuelo". Es decir, u s u a l m e n t e el u s u a r i o c o n s u l t a la W e b A p p s o l i c i t a n d o i n f o r m a c i ó n e s p e c í f i c a . La W e b A p p c o n s u l t a u n a b a s e d e d a t o s , f o r m a t e a la i n f o r m a c i ó n e n c o n c o r d a n c i a y

PDF Editor

la p r e s e n t a al u s u a r i o . Por e j e m p l o , u n a c o m p a ñ í a m u s i c a l o f r e c e u n a librería d e CD

e n v e n t a . C u a n d o un u s u a r i o solicita u n CD o s u e q u i v a l e n t e e n m ú s i c a e l e c t r ó n i c a , s e c o n s u l t a u n a b a s e d e d a t o s y u n a v a r i e d a d d e i n f o r m a c i ó n a c e r c a del a r t i s t a , el CD (por e j e m p l o , su p o r t a d a o gráfica), el c o n t e n i d o m u s i c a l y m u e s t r a s d e a u d i o s e d e s c a r g a n y c o n f i g u r a n e n u n a plantilla d e c o n t e n i d o e s t á n d a r . La p á g i n a W e b resul-

818

PARTE CUATRO


t a n t e se c o n s t r u y e e n el l a d o d e l s e r v i d o r y p a s a al n a v e g a d o r del l a d o del clier.tr

\ CLAVE El subsistema de colección abarca todas las acciones que se requieren pora crear, adquirir o convertir el contenido en uno formo que se pueda presentar en el lado del cliente.

p a r a q u e la e x a m i n e el u s u a r i o final. En la figura 27.6 s e m u e s t r a u n a r e p r e s e n t a d o g e n é r i c a d e esto. En el s e n t i d o m á s g e n e r a l , u n SGC " c o n f i g u r a " el c o n t e n i d o p a r a el u s u a r i o f r al i n v o c a r t r e s s u b s i s t e m a s i n t e g r a d o s : de c o l e c c i ó n , d e g e s t i ó n y d e publicación [B0102). El s u b s i s t e m a d e c o l e c c i ó n .

El c o n t e n i d o p r o c e d e de los d a t o s y la información

q u e d e b e c r e a r o a d q u i r i r u n d e s a r r o l l a d o r de c o n t e n i d o . El subsistema

de colección

a b a r c a t o d a s las a c c i o n e s q u e s e r e q u i e r e n p a r a c r e a r y / o a d q u i r i r c o n t e n i d o , as. c o m o las f u n c i o n e s t é c n i c a s n e c e s a r i a s p a r a 1) convertir el c o n t e n i d o e n u n a form a t o q u e se p u e d a r e p r e s e n t a r e n u n l e n g u a j e d e m a r c a s (por e j e m p l o , HTML, XML y 2) o r g a n i z a r el c o n t e n i d o e n p a q u e t e s q u e s e p u e d a n d e s p l e g a r c o n e f i c a c i a e n e l a d o del cliente. El s u b s i s t e m a d e g e s t i ó n .

U n a v e z q u e el c o n t e n i d o existe d e b e g u a r d a r s e e n u n

d e p ó s i t o , c a t a l o g a r s e p a r a a d q u i s i c i ó n y u s o s u b s e c u e n t e s , y e t i q u e t a r s e p a r a definir 1) su e s t a d o a c t u a l (por e j e m p l o , el o b j e t o d e c o n t e n i d o e s t á c o m p l e t o o e n d e s a r r o llo), 2) la versión a p r o p i a d a del o b j e t o de c o n t e n i d o , y 3) los o b j e t o s d e c o n t e n i d o r e l a c i o n a d o s . Por lo t a n t o , el subsistema

de gestión

i m p l e m e n t a u n d e p ó s i t o que

a b a r c a los s i g u i e n t e s e l e m e n t o s : • Base de datos de contenido:

la e s t r u c t u r a de i n f o r m a c i ó n q u e s e h a e s t a b l e c i d o

p a r a a l m a c e n a r t o d o s los o b j e t o s de c o n t e n i d o .

Sistema d e gestión del contenido (SGC).

Base d e dalos

Sistema d e gestión del contenido

TM

PDF Editor Plantillas

Código HTML + g u i o n e s

Lado de! servidor

N a v e g a d o r l a d o d e l cliente

CAPÍTULO 27

\

819


• Capacidades de la base de datos funciones que permiten al SGC buscar objetos de contenido específicos (o categorías de objetos), a l m a c e n a r y recuperar los

CI?AVE

objetos, y gestionar la estructura de archivos que se ha establecido para el

a s i s t e ™ de

contenido.

i implemento un ) pora todo el o. Lo gestión i c configuración se w a cobo dentro de i s 9JÍBÍstemo.

• Funciones de gestión de la configuración: los elementos funcionales y flujo de trabajo asociado que soportan la identificación del objeto de contenido, control de la versión, gestión del cambio, auditoria del cambio y creación de informes. A d e m á s de estos elementos, el subsistema d e gestión implementa u n a función de administración q u e abarca los m e t a d a t o s y reglas que controlan la estructura global del contenido y la forma en la que recibe soporte. El s u b s i s t e m a d e p u b l i c a c i ó n .

El contenido se d e b e extraer del depósito, con-

vertirse en u n a forma que esté dispuesta para la publicación y f o r m a t e a r s e de m o d o que sea posible transmitirlo a los n a v e g a d o r e s del lado del cliente. El subsistema publicación

de

logra e s t a s t a r e a s m e d i a n t e una serie de plantillas. Cada plantilla es u n a

función que construye u n a publicación e m p l e a n d o u n o de tres c o m p o n e n t e s difer e n t e s [B0102]:

• Elementos estáticos: los textos, gráficos, medios audiovisuales y guiones q u e ya no requieren p r o c e s a m i e n t o ulterior se transmiten directamente al lado del

CLAVE u x s t e m o de i obtiene ) del depósito « sntrego o los r.*jodores en el lodo m iente.

cliente. • Servicios de publicación: función q u e solicita servicios específicos de recuperación y formateo que personalizan el contenido (mediante reglas predefinidas), efectúan conversión de d a t o s y construyen vínculos de navegación apropiados. • Servicios extemos: proporcionan a c c e s o a infraestructura de información corporativa externa c o m o datos d e la e m p r e s a o aplicaciones de "cuarto trasero". Un sistema de gestión de contenido que a b a r q u e cada uno de e s t o s s u b s i s t e m a s e s aplicable a grandes proyectos de ingeniería Web. Sin embargo, la filosofía básica y la funcionalidad asociados con un SGC son aplicables a todas las WebApps dinámicas. HERRAMIENTAS DE SOFTWARE

TM

Gestión del contenido O b j e t i v o : Auxiliar a los ingenieros d e

•

controlada. La mayoría establece un simple sistema d e gestión d e archivos q u e a s i g n a actualización p á g i n a p o r

PDF Editor software y desarrolladores d e contenido a

gestionar el contenido q u e se incorpora en las W e b A p p s .

M e c á n i c a : Las herramientas en esta categoría permiten zue los ingenieros W e b y p r o v e e d o r e s d e contenido

actualicen el contenido d e una W e b A p p en una forma

V"

p á g i n a y permisos d e edición p a r a varios tipos d e

contenido W e b A p p . Algunos mantienen un sistema de

versiones d e m o d o que se pueden lograr versiones previas d e contenido p a r a propósitos históricos.

y

820

PAETE CUATRO


Herramientas representativas7 Contení Management

Tools Suite, desarrollada por

N Tower IDM, desarrollada por Tower Technologies (www.towertech.com), es un sistema de procesamiento

conjunto d e herramientas d e gestión de contenido que

d e documentos y depósito de contenido p a r a gestionar todas las formas d e información comercial no

se enfoca en la gestión del contenido p a r a dominios d e

estructurada: imágenes, formatos, informes generados

interaclivetools.com (www.interactivetools.com/), es un

aplicación específicos (por ejemplo, artículos nuevos,

por computadora, cuentas y facturas, documentos

avisos clasificados, bienes raíces).

oficiales, correo electrónico y contenido Web.

eklron-CMS300,

desarrollada por ektron

En los siguientes sitios W e b se puede encontrar

(www.ektron.com), es un conjunto d e herramientas q u e

información adicional acerca d e la G C S y las

ofrece c a p a c i d a d e s d e gestión d e contenido, as! como herramientas de desarrollo Web.

herramientas d e gestión del contenido p a r a ingeniería Web:

OmniUpdate, desarrollada por WebsiteASP, Inc. (www.omniupdate.com), es una herramienta que

Web Developer's Virtual Encyclopedia

(www.wdlv.com),

permite a los proveedores d e contenido autorizados

WebDeveloper (www.webdeveloper.com), Developer Shed (www.devshed.com), webknowhow.net

desarrollar actualizaciones controladas d e contenido

(www.webknowhow.net) o WebReference

W e b A p p especificado.

(www. webreference .com).

27.4.4 Gestión del cambio El flujo de trabajo asociado con el control del cambio para software convencional (sección 27.3.3) generalmente es demasiado laborioso para la ingeniería Web. Es improbable que se logre la secuencia petición de cambios, informe de cambio v orden de cambio de ingeniería en una forma ágil y aceptable para la mayoría de los proyectos de desarrollo WebApp, Entonces, ¿cómo se gestiona una corriente continua de cambios solicitada para el contenido y la funcionalidad de la WebApp? La implementación de una gestión de cambio eficaz dentro de la filosofía "codifica y ve" que continúe dominando el desarrollo de las WebApps requiere modificar el proceso de control de cambios convencional. Cada cambio se debe clasificar en una de cuatro clases: Clase I: un cambio de contenido o función que corrija un error o mejore el contenido o funcionalidad locales. Clase 2: un cambio de contenido o función que tenga impacto sobre otros objetos de contenido o componentes funcionales. Clase 3: un cambio de contenido o función que tenga amplio impacto a través de una WebApp (por ejemplo, gran ampliación de la funcionalidad, mejora significativa o reducción del contenido, grandes cambios requeridos en la navegación). TM Clase 4: un gran cambio de diseño (por ejemplo, un cambio en el diseño de la interfaz o enfoque de navegación) que inmediatamente apreciarán una o m á s categorías de usuarios.

PDF Editor 7

Las herramientas expuestas sólo representan una muestra d e esta categoría. En la mayoría d e los

c a s o s los n o m b r e s d e las m i s m a s son m a r c a s registradas por sus respectivos desarrolladores.

CAPÍTULO 27

821


3estíón d e cambios para WebApps. C a m b i o clase 1

C a m b i o clase 4

C a m b i o clase 3

C a m b i o clase 2

Desarrollar b r e v e descripción escrita

evaluando

Transmitir a t o d o s los m i e m b r o s d e l

Transmitir a l o d o s los p a r t i c i p a n t e s

Cambios requeridos en objetos relacionados 5e requiere más evaluoción

(

" S a l i d a " d e objeto(s) d ser c a m b i a d o ! * )

Se r e q u i e r e Y más evaluación I De ocuerdo l e n realización

^ J

/Efectuar c a m b i o s d i s e ñ o A \ construcción, p r u e b a J

Una vez clasificados los cambios solicitados se pueden procesar de acuerdo con el algoritmo mostrado en la figura 27.7. En la misma figura, los cambios de las clases I y 2 se tratan de manera informal y se manejan en una forma ágil. En un cambio de clase 1 el ingeniero Web evalúa el TM externa. impacto del cambio, pero no se requiere revisión o documentación Conforme se realiza el cambio, los procedimientos estándar de entrada y salida se refuerzan mediante las herramientas de configuración de depósito. En cuanto a los

PDF Editor

cambios de la clase 2, es obligación del ingeniero Web revisar el impacto del cambio sobre objetos relacionados (o pedir a los desarrolladores responsables de éstos que lo hagan). Si el cambio e s factible sin que se requieran cambios significativos en otros objetos, la modificación ocurre sin revisión o documentación adicional. Si se requieren cambios sustantivos, son necesarias evaluación y planificación ulteriores.

822

PARTE CUATRO


Los cambios de las clases 3 y 4 también se tratan en una forma ágil, pero se requieren alguna documentación descriptiva y m á s procedimientos de revisiones formales. Los cambios de la clase 3 requieren el desarrollo de u n a descripción de. cambio que ofrezca u n a breve evaluación del impacto del cambio. La descripción se distribuye entre todos los miembros del equipo de ingeniería Web, quienes lo revisan para evaluar mejor su impacto. También respecto a los cambios de la clase 4 se desarrolla u n a descripción del cambio, pero e n este caso la revisión la llevan a cabo todos los participantes.


Gestión del cambio M O b j e t i v o : Auxiliar a los ingenieros W e b y desarrolladores de contenido a gestionar los cambios conforme se realizan éstos en objetos de configuración WebApp. M e c á n i c a : Las herramientas en esta categoría originalmente fueron desarrolladas p a r a software

d e gestión del cambio q u e ofrece c a p a c i d a d e s d e GCS. ClearCase, desarrollada por Rational (www.rational.com), es un conjunto d e herramientas q u e ofrecen c a p a c i d a d e s completas d e gestión d e configuración p a r a WebApps. PVCS, desarrollada por Merant (www.merant.com), es un

convencional, pero es posible a d a p t a r l a s a la ingeniería

conjunto d e herramientas q u e ofrecen c a p a c i d a d e s

W e b y realizar cambios controlados en las WebApps.

completas d e gestión de configuración p a r a WebApps.

Herramientas rep res ent a t i v a s 8 ChangeMan

WCM, desarrollada por Serena

(www.serena.com), es una d e un conjunto d e

Source Inlegríty, desarrollada por mks (www.mks.com), es una herramienta G C S que se p u e d e integrar con entornos d e desarrollo seleccionados.

J

herramientas

27.4.5 Control de la versión Conforme u n a WebApp evoluciona por medio de u n a serie de incrementos, es posible q u e existan al m i s m o tiempo varias versiones diferentes. Una versión (la WebApp operativa actual) está disponible para los usuarios finales por Internet; otra versión (el siguiente incremento de la WebApp) quizá esté en las etapas finales de prueba previas al lanzamiento; u n a tercera versión e s t á en desarrollo y representa u n a gran actualización en contenido, estética d e interfaz y funcionalidad. Los objetos de configuración

d e b e n estar claramente definidos, de m o d o que cada uno pueda estar

asociado con la versión adecuada. Además, deben estar establecidos los mecanismos de control. Dreilinger [DRE99] aborda la importancia del control de la versión (y TM del cambio) c u a n d o escribe: En un sitio descontrolado, donde múltiples autores tienen acceso para editar y contribuir,

PDF Editor

surge el potencial para el conflicto y los problemas, m á s aún si los autores trabajan desde

8

Las h e r r a m i e n t a s expuestas sólo representan una muestra d e esta categoría. En la mayoría d e los

c a s o s los n o m b r e s d e las m i s m a s s o n m a r c a s registradas por s u s respectivos desarrolladores.

CAPÍTULO 27

GESTIÓN DEL CAMBIO

823

diferentes oficinas en distintos m o m e n t o s del día y la noche. Usted p u e d e p a s a r el día m e jorando el archivo index.html p a r a un cliente. Después q u e ha realizado los cambios, otro desarrollador, quien trabaja en su casa d e s p u é s de su jornada laboral, o en otra oficina, p u e d e p a s a r la n o c h e c a r g a n d o su propia n o v e d o s a versión revisada del a r c h i v o index.html,

¡y sobrescribir por completo el trabajo que usted ha realizado, sin forma alguna

d e retroceder!

Esta situación debe sonar familiar a todos los ingenieros de software, así como a todos los ingenieros Web. Para evitarlo, se debe establecer un proceso de control de la versión. 1. Se debe establecer un depósito central para el proyecto WebApp. El depósito contendrá las versiones actuales de todos los objetos d e configuración de la WebApp (contenido, componentes funcionales y otros). 2.

Cada ingeniero Web crea su propia carpeta de trabajo. La carpeta contiene aquellos objetos creados o cambiados en algún momento dado.

3. Los relojes en las estaciones de trabajo de todos los desarroíladores deben estar sincronizados. Esto tiene como fin evitar los conflictos de sobrescritura cuando dos desarroíladores realizan actualizaciones que están muy cercanas en el tiempo una de otra. 4 . Conforme se desarrollan nuevos objetos de configuración o se cambian los objetos existentes se importan al depósito central. La herramienta de control de la versión (véase el estudio precedente del SVC en este capítulo) gestionará todas las funciones de entrada y salida de las carpetas de trabajo de cada ingeniero Web. 5. Conforme los objetos se importan al o exportan del depósito se elabora un mensaje automático de registro cronometrado. Esto ofrece información útil para auditoría y se puede convertir en parte de un efectivo esquema de elaboración de informes. La herramienta de control de la versión mantiene diferentes versiones de la WebApp y puede revertirse a una versión más antigua si se requiere.

27.4.6

Auditoría y elaboración de informes

En búsqueda de agilidad, las funciones de auditoría y elaboración deTM informes no se resaltan en el trabajo de ingeniería Web. Sin embargo, no se eliminan por completo. Todos los objetos que entran o salen del depósito se anotan en un registro que puede

PDF Editor

revisarse en cualquier punto en el tiempo. Es factible crear un informe de registro completo de modo que todos los miembros del equipo de ingeniería Web tengan una cronología de los cambios sobre un periodo definido. Además, se envía una notificación automática de correo electrónico (dirigida a los desarroíladores y participantes interesados) cada vez que un objeto entre o salga del depósito.

PARTE CUATRO


INFORMACIÓN

Estándares de GCS y

La siguiente lista d e estándares GCS

EIA CMB6-1C

(procedente en parte d e www, 12207.com) es

Referencias d e gestión d e configuración y datos

razonablemente extensa:

EIA CMB6-3

Identificación d e configuración

Estándares IEEE

standards.ieee.org/catalog/ olis

EIA CMB6-4

Control d e configuración

IEEE 8 2 8

Planes de gestión d e configuración

EIA CMB6-5

Libro d e texto p a r a contabilidad d e

del software IEEE 1 0 4 2

Gestión d e configuración del software

estado d e configuración EIA CMB7-1

Intercambio electrónico d e datos de

www-library.itsi.disa.mil

gestión d e configuración

Estándares ISO

www.iso.ch/iso/en/ ISOOonline.frontpage

Estándares militares estadounidenses

ISO 1 0 0 0 7 - 1 9 9 5

Gestión d e calidad, lineamientos

DoD MIL STD-973

Gestión d e configuración

MIL-HDBK-61

Guía p a r a gestión d e configuración

para GC ISO/IEC 1 2 2 0 7

ISO/IEC TR 15271 ISO/IEC TR 1 5 8 4 6

Tecnología de información; procesos d e ciclo d e vida de

Otros e s t á n d a r e s

software

DO-178B

Directrices p a r a el desarrollo de

ESA PSS-05-09

Guía p a r a gestión d e configuración

software d e aviación

Guía p a r a ISO/IEC 1 2 2 0 7 Ingeniería del software; procesos

d e software

d e ciclo d e vida de software; gestión d e configuración p a r a software

Estándares EIA

www.eia.org/

EIA 6 4 9

Estándar d e consenso nacional p a r a gestión d e configuración

EIA CMB4-1A

Definiciones de gestión d e la configuración p a r a programas d e

AECL CE-1001-STD rev. 1

crítico DOE SCM lista de verificación BS-6488

Identificación de configuración p a r a programas de computadoras digitales

cio.doe.gov/ITReform/sqse/ download/cmcklst.doc British Std., gestión d e configuración d e sistemas b a s a d o s en computadora

computadoras digitales EIA CMB4-2

Estándar p a r a ingeniería del software d e software d e seguridad

Mejores prócticas-RU

Oficina d e comercio

CMII

Instituto d e mejores prácticas en

gubernamental: www.ogc.gov.uk GC: www.icmhq.com

EIA CMB4-3

Librerías d e software d e computadora

Una Guía de recursos de gestión de configuración ofrece

EIA CMB4-4

Control d e cambio d e

información complementaria p a r a aquellos interesados en

configuración p a r a p r o g r a m a s d e computadoras digitales

procesos y prácticas de GC. Está disponible en www.quality.org/config/cm-guide.html.

TM

PDF Editor

y

La gestión de configuración del software es u n a actividad protectora que se aplica a lo largo del proceso de software. La GCS identifica, controla, audita e informa modificaciones que invariablemente ocurren mientras se desarrolla software y después de

CAPÍTULO 27

GESTIÓN DEL C A M B O

825

que se le libera a un cliente. Toda la información producida como parte de la ingeniería del software se vuelve parte de una configuración de software. La configuración está organizada de forma que permite la gestión ordenada del cambio. La configuración del software está compuesta de un conjunto de objetos interrelacionados, también llamados elementos de configuración del software, que se producen debido a alguna actividad de ingeniería del software. Además de documentos, programas y datos, el entorno de desarrollo que se utiliza para crear software también s e puede colocar bajo control de configuración. Todos los ECS se guardan en un depósito que implementa mecanismos y estructuras de datos para garantizar la integridad de los datos, ofrece soporte de integración para otras herramientas de software, apoya la distribución de información entre los miembros del equipo de software e implementa funciones en apoyo del control de la versión y del cambio. Una vez desarrollado y revisado un objeto de configuración se convierte en línea base. Los cambios a un objeto convertido en línea base generan la creación de una nueva versión de dicho objeto. La evolución de un programa puede seguirse al examinar la historia de revisión de todos los objetos de configuración. Los objetos básicos y compuestos forman una piscina de objetos a partir de la que se crean las versiones. El control de la versión e s el conjunto de procedimientos y herramientas para gestionar el empleo de dichos objetos. El control de cambios e s una actividad de procedimiento que asegura la calidad y la consistencia conforme los cambios se realizan en un objeto de configuración. El proceso de control de cambios comienza con una petición de cambio, conduce a una decisión para aceptar o rechazarla y culmina con una actualización controlada del ECS que se cambiará. La auditoría de la configuración es una actividad de SQA que ayuda a garantizar que la calidad se conserva conforme se realizan los cambios. Los informes de estad o ofrecen información acerca de cada cambio a quienes tengan necesidad de conocerla. La gestión de la configuración para ingeniería Web e s similar en muchos aspectos a la GCS para el software convencional. Sin embargo, cada una d e las tareas principales de GCS s e deben destacar para hacerlas tan simples como sea posible, y se deben implementar provisiones especiales para la gestión del contenido.

TM 1BAB86] Babich, W. A., Software Conjiguration Management, Addison-Wesley, 1986. [BAC98J Bach, J„ "The Highs and Lows of Change Control", en Computer, vol. 31, núm. 8, agosto d e 1988, pp. 113-115. (BER80) Bersoff, E. H., V. D. Henderson y S. G. Siegel, Software Conjiguration Management, Prentice-Hall, 1980. [BOIÜ2] Boiko, B., Content Management Bible, Hungry Minds Publishing, 2002. [CH0891 Choi, S. C„ y W. Scacchi, "Assuring the Correctness of a Configured Software Description", Procs. 2nd Intl. Workshop on Software Conñguraaon Management, ACM, Princeton, NJ, octubre de 1989, pp. 66-75.

PDF Editor

326

PARTE C U A T R O


[CVS02] Concurren! Versions System Web site, www.cvshome.org, 2002. (DAR91] Dart, S., "Concepts in Configuration M a n a g e m e n t Systems", Proc. Third Inlernalioni Workshop on Software Configuration Management, ACM SIGSOFT, 1991, se p u e d e d e s c a r g ; de:http://www.sei.cmu.edu/legacy/scm/abstracts/abscm_concepts.html. (DAR99) Dart, S„ "Change Management: Containing the Web Crisis", Proc. Software Configuranc Management Symposium, Toulouse, Francia, 1999, disponible en h t t p : / / w w w . perforce.coir perforce/conf99/dart.html. [DAR01] Dart, S., Spectrum of Functionality in Configuration Management Systems, Software Ergineering Institute, 2001, disponible en h t t p : / / w w w . s e i . c m u . e d u / l e g a c y / s c m / t e c h _ r e p TR11_90/TOC_TRI l_90.html. [DRE99] Dreilinger, S.. "CVS Versión Control for Web Site Projects", 1999, disponible en http://www.durak.org/cvswebsites/howto-cvs/howto-cvs.html. [FOR89] Forte, G., "Rally Round the Repository", en CASE Outlook, diciembre d e 1989, pp. 5-27 [GRI95) Griffen, J„ "Repositories: Data Dictionary Descendant Can Extend Legacy Code lnvestment" en Application Development Trends, abril de 1995, pp. 65-71. [GUS89] Gustavsson, A„ "Maintaining the Evolution of Software Objects in an Integratec Environment", Proc. 2nd Intl. Workshop on Software Configuration Management, ACM Princeton, NJ, octubre de 1989, pp. 114-117. [HAR89] Harter, R., "Configuration Management", en HPProfessional, vol. 3, núm. 6, junio de 1989. |1EE94] Software Engineering Standards, edición 1994, IEEE Computer Society, 1994. UAC02) Jacobson, I., "A resounding 'Yes' to Agile Processes-But Also More", en Cutter IT Journal. vol. 15, núm. 1, e n e r o de 2002, pp. 18-24. [REI89] Reichenberger, C., "Orthogonal Versión Management", Proc. 2nd Intl. Workshop on Software Configuration Management, ACM, Princeton, NJ, octubre de 1989, pp. 137-140. [SHA95] Sharon, D., y R. Bell, "Tools That Bind: Creating Integrated Environments", IEEE Software, m a r z o d e 1995, pp. 76-85. [TAY85] Taylor, B., "A Database Approach to Configuration M a n a g e m e n t for Large Projects". Proc. Conf Software Maintenance-1985, IEEE, noviembre de 1985, pp. 15-23.

2 7 . 1 . ¿Por qué es cierta la primera ley d e la ingeniería de sistemas? Ofrecer ejemplos específicos de cada u n a de las cuatro r a z o n e s fundamentales p a r a el cambio. 27.2. ¿ c u á l e s son los cuatro e l e m e n t o s q u e existen c u a n d o se i m p l e m e n t a un sistema eficaz d e GCS? Comentar cada u n o brevemente. 2 7 . 3 . Con palabras propias, c o m é n t e n s e las r a z o n e s para las lineas base. 2 7 . 4 . Suponga que usted es el gestor d e un p e q u e ñ o proyecto. ¿Qué líneas base definiría para el proyecto y c ó m o las controlaría? 2 7 . 5 . Emplear UML agregados o compuestos (capítulo 8) para describir las interrelaciones entre los ECS (objetos de configuración) en la lista d e la sección 27.1.4. 2 7 . 6 . Diseñar un s i s t e m a de b a s e de d a t o s (depósito) d e proyecto que le permitiría a un ingeniero de s o f t w a r e a l m a c e n a r , realizar referencias c r u z a d a s , rastrear, actualizar y cambiar t o d o s los e l e m e n t o s i m p o r t a n t e s de configuración de s o f t w a r e . ¿ C ó m o m a n e j a r í a la b a s e de TM datos las diferentes versiones del m i s m o p r o g r a m a ? ¿El código f u e n t e se manejaría de manera diferente a la d o c u m e n t a c i ó n ? ¿Cómo se evitaría que d o s desarrolladores realizasen diferentes cambios al mismo ECS en forma simultánea?

PDF Editor

2 7 . 7 . Investigar u n a herramienta existente d e GCS y describir c ó m o implementa el control de las versiones y los objetos de configuración en general. 2 7 . 8 . Las r e l a c i o n e s e r e p r e s e n t a n relaciones s i m p l e s e n t r e o b j e t o s d e configuración. Describir cinco r e l a c i o n e s adicionales q u e p u e d a n s e r útiles en el contexto de un depósito de GCS.

CAPÍTULO 2 7

GESTIÓN DEL CAMBKD

827

2 7 . 9 . Investigar u n a h e r r a m i e n t a e x i s t e n t e d e GCS y describir c ó m o i m p l e m e n t a los m e c a n i s m o s d e control de v e r s i o n e s De m a n e r a alternativa, leer d o s o tres d e los artículos a c e r c a d e GCS y describir las d i f e r e n t e s e s t r u c t u r a s de d a t o s y m e c a n i s m o s de referencia q u e se emplean p a r a el control d e las versiones 2 7 . 1 0 . Con la figura 27.5 c o m o guia, desarrollar un análisis todavía m á s d e t a l l a d o p a r a el control del cambio. Describir el papel d e la ACC y sugerir formatos p a r a la petición del cambio, el informe del cambio y la OCI. 2 7 . 1 1 . Desarrollar u n a lista d e verificación p a r a emplearla d u r a n t e las a u d i t o r í a s d e la configuración. 2 7 . 1 2 . ¿Cuál es la diferencia entre una auditoría GCS y una revisión técnica formal? ¿Sus funciones se pueden juntar en u n a revisión? ¿Cuáles son los pros y los contras? 2 7 . 1 3 . Describir b r e v e m e n t e las diferencias e n t r e GCS para el s o f t w a r e convencional y la GCS para WebApps. 2 7 . 1 4 . ¿Qué es la gestión del contenido? Empléese la Web para investigar las características de una herramienta de gestión del contenido y ofrézcase un breve resumen.

Lyon [Practical CM, Raven Publishing, 2003, disponible en www.configuration.org) ha escrito u n a guía detallada para profesionales de GC q u e incluye directrices pragmáticas para implem e n t a r c a d a a s p e c t o de un sistema d e gestión d e la configuración (actualizado anualmente). Hass {Conjiguration Management: Principies and Practice, Addison-Wesley, 2002) y León [A Guide to Sojtware Conjiguration Management, Artech House, 2000) ofrecen e x á m e n e s útiles del tema. White y Clemm (Sojtware Conjiguration Management Strategies and Rationai CiearCase, AddisonWesley, 2000) presentan la GCS dentro del contexto d e u n a d e las m á s populares herramientas de GCS. Mikkelsen y Pherigo (Practical Sojtware Conjiguration Management: The Latenight Developer's Handbook, Allyn & Bacon, 1997) y Compton y Callahan (Conjiguration Management for Sojtware, VanNostrand-Reinhold, 1994) ofrecen guias pragmáticas acerca d e importantes prácticas d e GCS. Ben-Menachem (Sojtware Configuration Management Guidebook, McGrawHill, 1994) y Ayer y Patrinnostro (Sojtware Conjiguration Management, McGraw-Hill, 1992) p r e s e n t a n b u e n o s p a n o r a m a s p a r a quienes necesitan mayor introducción a la materia. Berlack (Sojtware Conjiguration Management, Wiley, 1992) presenta un examen útil d e conceptos de GCS, d o n d e resalta la importancia del depósito y las herramientas en la gestión del cambio. Babich (BAB86) proporciona un tratamiento abreviado, a u n q u e eficaz, d e t e m a s pragmáticos en la gestión d e configuración del software. Arnold y Bohner (Sojtware Change impact Analysis, IEEE Computer Society Press, 1996) h a n editado una antología q u e estudia c ó m o analizar el impacto del cambio al interior d e s i s t e m a s complejos b a s a d o s en software. Berczuk y Appleton (Sojtware Conjiguration Management Patterns, Addison-Wesley, 2002) presentan u n a diversidad de p a t r o n e s útiles q u e auxilian en la comprensión de la GCS y la implementación d e sistemas de GCS eficaces. Brown et al. (Anti-Pattems and Patterns in Sojtware Conjiguration Management, Wiley, 1999) estudian las c o s a s q u e n o se hacen TM (antipatrones) c u a n d o se implementa un proceso d e GCS y luego consideran s u s remedios. Buckley (Implementing Conjiguration Management, IEEE Computer Society Press, 1993) considera enfoques de gestión d e la configuración para todos los e l e m e n t o s del sistema —hardware, software y firmware— con estudios detallados d e las principales actividades de GC. Rawlings (SCM for Network Development Environments, McGraw-Hill, 1994) considera el impacto d e la GCS para desarrollo de software en un e n t o r n o de red. Bays (Sojtware Release Methodology, Prentice-Hall, 1999) presenta u n a colección d e mejores prácticas para todas las actividades q u e ocurren d e s p u é s de que se r e a l z a n cambios en u n a aplicación. Conforme las WebApps se vuelven m á s dmámicas. la gestión del contenido se vuelve un tópico esencial p a r a los ingenieros Web Los libros d e Addey y s u s colegas (Contení Manage-

PDF Editor

828

PARTE C U A T R O


ment Systems, Glasshaus, 2003), Boiko [B0102], Hackos (Contení Managementfor Dynamic l'.fciDelivery, Wiley, 2002), N a k a n o (Web Content Management, Addison-Wesley, 2001) presentar, valiosos tratamientos de la materia. En Internet hay disponible una amplia variedad d e fuentes d e información acerca de la gestión de configuración del software. Una lista actualizada d e referencias en la World Wic; Web se p u e d e encontrar en el sitio Web SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

A

Cinco

TEMAS AVANZADOS EN INGENIERÍA DEL SOFTWARE

E

n esta parte de Ingeniería del software. Un enfoque práctico se consideran varios temas avanzados que ampliarán la comprensión del lector acerca de la ingeniería del software. En los siguientes capítulos se abordarán las siguientes preguntas: •

¿Qué notación y preliminares matemáticos ("métodos formales") se requieren para especificar formalmente el software?

• ¿Qué actividades técnicas clave se llevan a cabo durante el proceso de ingeniería del software de sala limpia? •

¿Cómo se emplea la ingeniería del software basada en componentes para crear sistemas a partir de componentes reutilizables?

•

¿Qué actividades técnicas se requieren para la reingeniería del software?

• ¿Cuáles son las tendencias futuras de la ingeniería del software? Una vez que se respondan estas preguntas, se entenderán los TM temas que tienen la posibilidad de tener un profundo impacto sobre la ingeniería del software durante la década siguiente.

PDF Editor

829

C A P I T U L O

28

MÉTODOS FORMALES

m m m m m

CONCEPTOS CLAVE especificocióii constructiva . . . 8 3 7 especificación formal

.842

esquemas

849

estadas

834

invariante de dolos

835

lenguaje Z . . . . 8 4 9 OCl

84S

operaciones

.. .834

operadores de conjuntos

838

Los métodos formales son controvertidos. Sus partidarios afirman que pueden revolucionar el desarrollo [del software). Sus detractores piensan que son increíblemen-

840

te difíciles. Mientras tanto, para la mayoría de la gente, los métodos formales son tan

operadores lógicos

pre y

L

os métodos de la ingeniería del software se pueden clasificar sobre un espectro de "formalidad" ligeramente vinculado con el grado de rigor matemático aplicado durante el análisis y el diseño. Por esta razón, los métodos de análisis y diseño estudiados previamente en este libro se ubican en el extremo informal del espectro. En la creación de modelos de análisis y diseño se utilizan combinaciones de diagramas, texto, tablas y notación simple, pero se ha aplicado poco rigor matemático. Considérese ahora el otro extremo del espectro de formalidad. Aquí, una especificación y diseño se describen empleando sintaxis y semánticas formales que especifican la función y el comportamiento del sistema. La especificación es matemática en forma (por ejemplo, el cálculo de predicados se utiliza como base para un lenguaje formal de especificación). En su estudio introductorio de los métodos formales, Anthony Hall [HAL90] afirma;

postondiciones .835

poco familiares que es difícil juzgar las afirmaciones en competencia.

En este capítulo se exploran los métodos formales y se examinan sus poten cíales impactos sobre la ingeniería del software en los años por venir.

¿ Q u é e s ? Los métodos formales permiten que un ingeniero de software cree una especificación más completa, consistente y precisa que las que se producen empleando métodos convencionales. Se utilizan ta notación de teoría de conjuntos y lógica para crear un claro planteamiento de hechos (requisitos). Esta especificación matemática luego se analiza para mejorar ¡o incluso probar) su corrección y consistencia. Puesto que la especificación se crea mediante notación matemática, es inherentemente menos ambiguo que los modos informales de representación. ¿ Q u i é n lo h a c e ? Un ingeniero de software especialmente entrenado crea una especificación formal. ¿ P o r q u é e s i m p o r t a n t e ? En los sistemas de seguridad o de misión críticas, las fallas tienen

un precio elevado. Cuando el software de computadora falla es posible que se pierdan vidas o surjan graves consecuencias económicas. En tales situaciones es esencial que los errores sean descubiertos antes de que el software sea puesto en operación. Los métodos formales reducen sustancialmente los errores de especificación y, como consecuencia, sirven como base para que el software íenga tan pocos errores una vez que el cliente comience a usarlo. ¿ C u á l e s s o n los p a s o s ? La notación y heurístiTM ca de conjuntos y la especificación constructiva —operadores de conjuntos, operadores lógicos y secuencias— forman la base de los métodos formales. Éstos definen los datos invariantes, estados y operaciones para la función de un sistema al traducir los requisitos formales del problema en una representación más formal.

PDF Editor

CAPÍTULO 28

¿ C u á l e s el p r o d u c t o o b t e n i d o ? Cuando se aplican los métodos formales se produce una especificación representada en un lenguaje formal como OCL o Z. ¿ C ó m o p u e d o e s t a r s e g u r o d e q u e lo h e h e c h o c o r r e c t a m e n t e ? Puesto que los métodos formales utilizan matemáticas discretas

28.1

831

MÉTODOS FORMALES

Conceptos

como mecanismo de especificación, se aplican pruebas lógicas a cada función del sistema para demostrar que la especificación es correcta. Sin embargo, incluso si no se aplican las pruebas lógicas, la estructura y disciplina de una especificación formal conducirán a una calidad de software mejorada.

BÁSICOS

La Encyclopedia of Sojtware Engineering

(MAR94] define así los m é t o d o s formales:

Un método es formal si tiene sólidas bases matemáticas, usualmente proporcionadas por un lenguaje formal de especificación. Esta base ofrece los medios de definir con precisión nociones como consistencia y completud, y, con más relevancia, especificación, implementación y corrección. Las propiedades d e s e a d a s de una especificación formal (consistencia, integridad y falta de ambigüedad) s o n los objetivos de t o d o s los m é t o d o s de especificación. Sin embargo, emplear m é t o d o s formales resulta en una probabilidad m u c h o mayor de lograr dichos ideales. La sintaxis de un lenguaje formal de especificación (sección 28.4) permite que los requisitos y el diseño se interpreten sólo e n u n a forma, lo que elimina la a m b i g ü e d a d que con frecuencia ocurre c u a n d o un lenguaje natural (por ejemplo, inglés) o una notación gráfica d e b e interpretarlos un lector. Las facilidades descriptivas de la teoría de c o n j u n t o s y la notación lógica (sección 28.2) permiten un p l a n t e a m i e n t o claro de los h e c h o s (requisitos). Para ser consistente, los h e c h o s plant e a d o s e n un lugar en u n a especificación no deben contradecirse en otro sitio. La consistencia se garantiza p r o b a n d o m a t e m á t i c a m e n t e que los h e c h o s iniciales pueden correlacionarse de m a n e r a formal (empleando reglas de inferencia) en planteamientos posteriores dentro de la especificación.

"Los métodos formales tienen un enorme potencial pora mejorar la claridad y la precisión defasespecificaciones de requisitos y paro encontrar los errores importantes y sutiles." Steve Easterbrook el al. La completud es difícil de lograr, a u n c u a n d o se apliquen los m é t oTM d o s formales. Algunos a s p e c t o s de un sistema tal vez queden indefinidos mientras se crea la especificación; o t r a s características quizá se omitan a propósito para permitir que los di-

PDF Editor

s e ñ a d o r e s tengan cierta libertad de elección en el e n f o q u e de implementación; y, finalmente,

es imposible considerar cada escenario operativo en un gran sistema

complejo. Las c o s a s tal vez se omitan p o r error

Aunque el formalismo que ofrecen las m a t e m á t i c a s es atractivo para a l g u n o s in-

genieros d e software, o t r o s (algunos dinan la mayoría) miran d e s p e c t i v a m e n t e la vi-

832

PAUTE C I N C O


sión matemática del desarrollo del software. Comprender por qué un e n f o q u e forn- ai tiene s u mérito requiere, primero, considerar las deficiencias a s o c i a d a s con los efoques m e n o s formales.

28.1.1

Deficiencias de los enfoques m e n o s formales 1

Los m é t o d o s estudiados para el análisis y el diseño en las p a r t e s 2 y 3 de ese libr: e m p l e a n a m p l i a m e n t e el lenguaje natural y u n a extensa g a m a de notaciones grar" cas. Aunque la aplicación cuidadosa de los m é t o d o s de análisis y diseño, en c o n j u r to con revisiones exhaustivas, puede conducir y de hecho conduce a software de al: i calidad, el descuido en la aplicación de e s t o s m é t o d o s crea u n a diversidad de prc blemas. Una especificación de sistema p u e d e contener contradicciones, ambigüeca des, vaguedades, p l a n t e a m i e n t o s incompletos y grados mixtos de abstracción. ^CONSEJO^ Aunque un buen Indice de documento no puede eliminar los contradicciones, sí puede ayudar o descubridos. Considérese lo creación de un índice poro los especificaciones y otros documentos.

Las contradicciones

son c o n j u n t o s de p l a n t e a m i e n t o s que divergen u n o s cor

otros. Por ejemplo, p a r t e de u n a especificación de sistema p u e d e afirmar que el sistema d e b e supervisar t o d a s las t e m p e r a t u r a s en un reactor químico, mientras que otra parte, que tal vez escribió otra persona, p u e d e afirmar que sólo deben supervis a r s e las t e m p e r a t u r a s que ocurran dentro de cierto intervalo. Las ambigüedades

son p l a n t e a m i e n t o s que se interpretan en varias formas. Por

ejemplo, el siguiente planteamiento e s ambiguo: La identidad del operador consiste de su nombre y la contraseña; ésta consiste de seis dígitos. Se debe mostrar en la UDV de seguridad y depositarse en el archivo de registro cuando un operador se registre en el sistema. En este fragmento, ¿se debe mostrar se refiere a la c o n t r a s e ñ a o a la identidad de! operador? Las vaguedades

con frecuencia ocurren porque la especificación de un sistema es

un d o c u m e n t o muy voluminoso. Lograr un elevado grado de precisión consistentem e n t e es una tarea casi imposible. "Cometer errores es humano. Repetirlos, también.' Malcolm F orbes La incompletud

es u n o de los p r o b l e m a s que ocurren c o n mayor frecuencia con

las especificaciones del sistema. Por ejemplo, considérese el requisito funcional: El sistema debe conservar el nivel horario del depósito a partir de los sensores profundos TM situados en el depósito. Dichos valores deben almacenarse respecto de los seis meses anteriores.

PDF Editor

Esto describe la parte principal del a l m a c e n a m i e n t o de d a t o s de un sistema. Si uno de los c o m a n d o s para el sistema fuese:

1 Esta sección y otras en la primera parte de este capítulo se han adaptado del trabajo de Darrel Ince para la edición europea de la quinta edición de Ingeniería del software. Un enfoque práctico.

CAPITULO 28

ÔNSEJÓ^ ios revisiones técnicos (órnales eficaces yueden eliminar muchos de estos problemas. Sin embargo, algunos no serón descubiertos. Debe estarse alerta de las deficiencias áuronte el diseño, lo :odificación y la puesta a prueba.

833

MÉTODOS FORMALES

La función del comando P R O M E D I O es desplegar en una PC el nivel de agua promedio para un sensor particular entre dos tiempos. y si s u p o n e que no se p r e s e n t a n m á s detalles para este c o m a n d o , los detalles del com a n d o estarían seriamente incompletos. Por ejemplo, la descripción del c o m a n d o n o incluye lo que debería ocurrir si un usuario de un sistema especifica un tiempo que f u e s e mayor a seis m e s e s a n t e s de la hora actual. Los grados mixtos de abstracción ocurren c u a n d o p l a n t e a m i e n t o s muy abstractos se m e z c l a n al a z a r con planteamientos que tienen un g r a d o m u c h o m e n o r de d e t a lle. Aunque a m b o s tipos de planteamientos son importantes en la especificación de un sistema, quienes la realizan con frecuencia m a n e j a n la mezcla e n tal forma q u e resulta muy difícil ver la arquitectura funcional global de un sistema.

28.1.2 Matemáticas en el desarrollo de software Las matemáticas tienen m u c h a s propiedades útiles para los desarroíladores de grandes sistemas. Una es que se p u e d e describir sucinta y e x a c t a m e n t e u n a situación física, un objeto o el resultado de una acción. Es posible desarrollar una especificación de un sistema b a s a d o en c o m p u t a d o r a e m p l e a n d o m a t e m á t i c a s especializadas, en form a muy similar a la que un ingeniero eléctrico aplica las m a t e m á t i c a s para describir un circuito. 2 Las m a t e m á t i c a s s u s t e n t a n la abstracción y por e n d e son un excelente medio pa ra el modelado. Puesto que se trata de un medio exacto, existe poca posibilidad de a m b i g ü e d a d . Las especificaciones pueden validarse m a t e m á t i c a m e n t e para contradicciones e incompletudes, y se pueden eliminar las vaguedades. Además, las m a t e máticas se emplean para representar, en una forma organizada, grados de abstracción en la especificación de un sistema. Finalmente, las m a t e m á t i c a s ofrecen un alto g r a d o de validación al e m p l e a r l a s c o m o un medio de desarrollo de software. Es posible aplicar u n a prueba matemática para d e m o s t r a r que un diseño e n c a j a en una especificación y q u e el código del programa es un reflejo correcto de un diseño.

28.1.3 Conceptos de métodos formales La meta de esta sección es presentar los principales conceptos involucrados e n la especificación matemática de los sistemas de software, sin atiborrar al lector con d e m a siados detalles matemáticos. Esto se logra empleado u n o s cuantos ejemplos simples. E j e m p l o 1: u n a tabla d e s í m b o l o s .

TM

Un p r o g r a m a s e emplea para m a n t e n e r u n a

tabla de símbolos, la cual se utiliza f r e c u e n t e m e n t e en diferentes tipos de aplicacio-

PDF Editor

2 En este momento es adecuada una advertencia. Las especificaciones del sistema matemático que se presentan en este capitulo no son tan sucintas como una especificación matemática para un circuito simple. Los sistemas de software sor - Monamente complejos y seria irreal esperar que se podrían especificar en una linea de mater- a!

834

;

%

cfovE

Un invariante de datos es un conjunto de condiciones verdaderas ejecución del sistemo que contiene una colección de datos.

PARTE C I N C O


nes. Consiste de u n a colección de e l e m e n t o s sin duplicación alguna. En la figura 28.1 se muestra un ejemplo de una tabla de símbolos c o m ú n . En ella se representa la tabla que utiliza un sistema operativo para retener los n o m b r e s de los usuarios del sistema. Otros ejemplos de tablas incluyen la colección de n o m b r e s del personal de u r sistema de n ó m i n a o la colección de los n o m b r e s de c o m p u t a d o r a s en un sistema de comunicaciones en red. Supóngase que la tabla presentada en este ejemplo consiste de no m á s de Maxlds miembros de personal. Este planteamiento, que coloca una restricción en la tabla, es un c o m p o n e n t e de una condición conocida c o m o invariante de datos, una importante idea que se retomará a lo largo de este capítulo.

ÔNSIJO^. Otra forma de observo/la noción de estado es decir que los datos determinan el estado. Esto es, se pueden examinarlos datos para ver en qué estado estó el sistema.

Un invariante de d a t o s es una condición verdadera a lo largo de la ejecución de. sistema que contiene u n a colección de datos. La invariante de datos que se mantiene para la tabla de símbolos a p e n a s estudiada tiene dos c o m p o n e n t e s : 1) que la tabla c o n t e n d r á no m á s de Maxlds n o m b r e s y 2) que n o habrá n o m b r e s duplicados e r la tabla. En el caso del programa de tabla de símbolos, e s t o significa que no importa c u á n d o se e x a m i n e la tabla durante la ejecución del sistema, siempre contendré no m á s de Maxlds identificadores de personal y no incluirá duplicados. Otro concepto importante es el de estado. Muchos lenguajes formales, c o m o OCL (sección 28.5), utilizan la noción de e s t a d o c o m o se le estudió en los capítulos 7 y 8 e s decir: un sistema p u e d e estar en u n o de varios estados, y cada u n o de ellos representa un m o d o de c o m p o r t a m i e n t o observable externamente. Sin embargo, una definición diferente para el término estado se utiliza e n el lenguaje Z (sección 28.6). Er. z (y en lenguajes relacionados), el e s t a d o de un sistema se representa mediante los d a t o s a l m a c e n a d o s del sistema (por tanto, Z sugiere un n ú m e r o m u c h o mayor de estados, que representan cada posible configuración de los datos). Al emplear la última definición en el ejemplo del p r o g r a m a de tabla de símbolos, el e s t a d o es la tabla de símbolos. El concepto final es el de operación. Ésta es u n a acción que ocurre dentro de un sistema y lee o escribe datos. Si el programa de tabla de símbolos está preocupado

1. Wilson

Tabla de símbolos.

2, Simpson 3. Abel 4. Fernandez Maxlds = 10

TM

5.

PDF Editor 6. 7. 8.

9.

10.

CAPÍTULO 2 8

MÉTODOS FORMALES

835

por añadir y remover n o m b r e s de personal de la tabla de símbolos, e n t o n c e s estará a s o c i a d o con dos operaciones: u n a p a r a añadir un n o m b r e específico a la tabla de símbolos, y u n a para eliminar un n o m b r e existente de la tabla. 4 Si el programa ofrece la capacidad de verificar si un n o m b r e específico está en la tabla, e n t o n c e s habría una operación que regresaría alguna indicación acerca de la presencia del n o m b r e e n la tabla. Tres tipos de condiciones se asocian con las operaciones: invariantes, precondiciones y poscondiciones. Un invariante define lo que está g a r a n t i z a d o que no c a m biará. Por ejemplo, la tabla de símbolos tiene un invariante que establece que el núm e r o de e l e m e n t o s siempre será m e n o r o igual a Maxlds. Una precondición

define las

circunstancias en las cuales es válida una operación particular. Por ejemplo, la preÔNSEJÓ^ _3 técnicas de lluvia é ideas pueden \ncmar bien cuando ¡e áebe desarrollar un 'wriante de datos ;aa una función rozo•:tkmente compleja, lado miembro del equipo de software ~ene que escribir los mites, restricciones y imitaciones para lo ijnción y luego combi-ryfos y editarlas.

Gestor de bloques.

condición para u n a operación que a ñ a d e un n o m b r e a la tabla de símbolos de identificadores de personal sólo es válida si el n o m b r e no está en la tabla y también si en ésta existen m e n o s de Maxlds identificadores de personal. La poscondición

de una

operación define lo que está g a r a n t i z a d o que será cierto hasta completar una operación. Esto lo define su efecto sobre los datos. En el ejemplo de una operación que a ñ a d e un identificador a la tabla d e símbolos de identificadores de personal, la poscondición especificaría m a t e m á t i c a m e n t e que la tabla ha a u m e n t a d o con el n u e v o identificador. Ejemplo 2: un g e s t o r d e b l o q u e s .

Una de las partes m á s importantes del siste-

ma operativo de una computadora es el subsistema que mantiene los archivos que hayan c r e a d o los usuarios. Parte del subsistema de archivado e s el gestor de bloques. Los archivos en el archivero están c o m p u e s t o s de bloques de a l m a c e n a m i e n t o que se m a n t i e n e n en un dispositivo de a l m a c e n a m i e n t o de archivos. Durante la opera-

Bloques no usados

1 3 4 6 9

Bloques usados

2 5 7 8 10 11 1 2

rn ¿i

Cuando se borran los archivos, los bloques

Fila para entrar en los bloques no usados

se

''ê,an

a

TM '° '''°

PDF Editor Archivo #1 Archivo #2 Archivo #3 La cola de bloques contiene bloques provenientes de los archivos borrados

3 Se debe señalar que añadir un nombre -o puede ocurrir en el estado lleno, y que borrar un nombre es imposible en el estado vacio

836

PARTE C I N C O


ción de la computadora, los archivos se crearán y borrarán, lo que requiere la adquisición y liberación de bloques de almacenamiento. El subsistema de archivado lidiará con esto manteniendo un depósito de bloques n o utilizados (libres) y dará seguimiento a los bloques que actualmente están en uso. Cuando se borra un archivo, los bloques liberados normalmente se agregan a una fila de bloques que esperan ser agregados al depósito de bloques no utilizados. Esto se muestra en la figura 28.2. En esta figura s e muestran varios componentes: el depósito de bloques n o utilizados, los bloques que actualmente constituyen los archivos que administra el sistema operativo y aquellos bloques que esperan agregarse al depósito. Los bloques en espera se mantienen en una fila, y cada elemento de ésta contiene un conjunto d e bloques provenientes de un archivo borrado. En este subsistema el estado es la colección de bloques libres, la colección de bloques utilizados y la fila de bloques devueltos. El invariante de datos, expresado en lenguaje natural, es: • Ningún bloque será marcado a la vez c o m o no utilizado y utilizado. • Todos los conjuntos d e bloques mantenidos en la fila serán subconjuntos de la colección de bloques actualmente usados. • Ningún número de bloque pertenecerá a dos o m á s elementos de la fila. • La colección de bloques utilizados y n o utilizados será la colección total de bloques que configuran los archivos. • La colección de bloques n o utilizados n o tendrá números de bloque duplicados. • La colección d e bloques utilizados no tendrá números de bloque duplicados. Algunas de las operaciones asociadas con el invariante de datos son: añadirf) una colección de bloques al final de la fila, eliminar() una colección de bloques utilizados del frente de la fila y colocarlos en la colección de bloques n o utilizados, y verificar() si la fila de bloques está vacía. La precondición de la primera operación es que los bloques que se añadirán deben estar en la condición de bloques utilizados. La poscondición e s que la colección de bloques ahora s e encuentra al final de la fila. La precondición d e la segunda operación es que la fila debe tener al menos un elemento en ella. TM La operación final —verificar si la fila d e bloques devueltos está vacía— n o tiene precondición. Esto significa que la operación siempre está definida, sin importar de qué valor sea el estado. La poscondición entrega el valor cierto si la fila está vacía y f a l s o de cualquier otro modo.

PDF Editor

En los ejemplos tratados en esta sección se introducen los conceptos clave de la especificación formal. Esto se hizo sin resaltar las matemáticas que se requieren para formalizar la especificación. En la sección 28.2 se consideran tales matemáticas.

CAPÍTULO 28

837

MÉTODOS FORMALES

La aplicación eficaz de los métodos formales requiere que un ingeniero de software tenga un conocimiento operativo de la notación matemática asociada con los conjuntos y las secuencias, y de la notación lógica utilizada en el cálculo de predicados. La finalidad de la sección e s proporcionar una breve introducción al tema. Para una exposición más detallada, se recomienda al lector consultar libros dedicados a estos temas (por ejemplo, [WIL87], [GRI93] y [ROS95]).

28.2.1

Conjuntos y especificación constructiva

Un conjunto es una colección de objetos o elementos, y se utiliza como piedra angular de los métodos formales. Los elementos que contiene un conjunto son únicos (es decir: n o se permiten duplicaciones). Los conjuntos con un n ú m e r o pequeño de elementos se escriben dentro de llaves, con los elementos separados por comas. Por ejemplo, el conjunto | C + + , Smalltalk, Ada, COBOL, Java) contiene los nombres de cinco lenguajes de programación. El orden en el que aparecen los elementos dentro de un conjunto e s irrelevante. Al n ú m e r o de elementos en un conjunto s e le conoce c o m o cardinalidad. El operador # proporciona la cardinalidad de un conjunto. Por ejemplo, la expresión #{A, B, C, D) = 4

¿Qué es

•

especificación

constructiva d e conjuntos?

implica que se ha aplicado el operador cardinalidad al conjunto mostrado, con un resultado que indica el número de elementos en el conjunto. Existen dos formas de definir un conjunto. Un conjunto s e define enumerando sus elementos (así se han definido los conjuntos mencionados). El segundo enfoque consiste en crear una especificación constructiva de conjuntos. La forma general de los miembros de un conjunto se especifica empleando una expresión booleana. La especificación constructiva de conjuntos es preferible a la enumeración porque ello permite una definición sucinta de conjuntos grandes. También define explícitamente la regla que se aplicó al construir el conjunto. Considérese el siguiente ejemplo de especificación constructiva: |n : N I n < 3 • n¡

TM

Esta especificación tiene tres componentes: una firma, n : N; un predicado, n < 3; y un término, n. La firma especifica el intervalo de valores que se considerarán cuand o se forme el conjunto; el predicado (una expresión Booleana) define cómo se restringirá el conjunto; y, finalmente, el término brinda la forma general del elemento del conjunto. En el ejemplo a n t e r i o r , ' , representa los números naturales; por lo tanto, se considerarán los números naturales El predicado indica que sólo se incluirán

PDF Editor

838

ÔNSUO^ Es indispensable el conocimiento de los operaciones de conjuntos cuando se desarrollen especificaciones formales. Debe pasarse algún tiempo familiarizándose con cado una, sise tiene la intención de aplicar métodos formales.

PARTE C I N C O


los n ú m e r o s naturales m e n o r e s que 3; y el término especifica que cada e l e m e n t o ce conjunto será de la forma n. En consecuencia, esta especificación define el conjunt : 10, 1 , 2 )

C u a n d o la forma de los e l e m e n t o s d e un conjunto es obvia, el término s e p u e d e om¡ tir. Por ejemplo, el c o n j u n t o precedente se podría especificar c o m o {/i : N I n < 3) Todos los c o n j u n t o s que se han descrito tienen e l e m e n t o s q u e son e l e m e n t o s individuales. También s e pueden formar c o n j u n t o s a partir de e l e m e n t o s que s e a n pares, t e m a s , etcétera. Por ejemplo, la especificación de c o n j u n t o {x,y : N Ix +y = 10 • ( x , y 2 ) )

describe el c o n j u n t o de p a r e s d e n ú m e r o s naturales que tienen la forma (x.y2) y dond e la s u m a de x ey es 10. Éste e s el c o n j u n t o {(1,81), (2, 64), (3, 4 9 ) , - ) Obviamente, la especificación constructiva de c o n j u n t o s requerida para representar algún c o m p o n e n t e de software de computadora será considerablemente m á s compleja que las a n o t a d a s aquí. Sin e m b a r g o , la forma y estructura básicas p e r m a necen iguales.

28.2.2

Operadores de conjuntos

En la representación de o p e r a c i o n e s de c o n j u n t o s y lógicas se utiliza simbologla especializada. El ingeniero de s o f t w a r e q u e pretenda aplicar los m é t o d o s formales debe c o m p r e n d e r e s t o s símbolos. El operador e indica la pertenencia de un conjunto. Por ejemplo, la expresión x

E

X

tiene el valor verdadero si x e s m i e m b r o del c o n j u n t o X y el valor falso e n c a s o contrario. Por ejemplo, el predicado 12 e |6, 1, 12, 22) tiene el valor verdadero d a d o q u e 12 e s m i e m b r o del conjunto. El o p u e s t o del operador e e s el operador e . La expresión x e X

TM

tiene el valor verdadero si x n o e s m i e m b r o del conjunto X y falso en c a s o contrario. Por ejemplo, el predicado

PDF Editor 13 z {13, 1, 124,22)

tiene el valor falso.

Los o p e r a d o r e s e y e tienen c o n j u n t o s c o m o sus o p e r a n d o s . El predicado ACB

CAPÍTULO 28

839

MÉTODOS FORMALES

tiene el valor verdadero si los miembros del c o n j u n t o s están en el c o n j u n t o 6 y tien e el valor falso en c a s o contrario. Por lo tanto, el predicado (1,2) c {4, 3, 1,2} tiene el valor verdadero. Sin embargo, el predicado {HD1, LP4, RC5) C |HD1, RC2, HD3, LP1, LP4, LP6) tiene un valor de falso porque el elemento RC5 no está en el conjunto a la derecha del operador. El operador c e s similar a c . Sin embargo, si sus o p e r a n d o s son iguales, tiene el valor verdadero. Por lo tanto, el valor del predicado ¡HD1, LP4, RC5} C |HDl, RC2, HD3, LP1, LP4, LP6| e s falso, y el predicado (HD1, LP4, RC5} C (HD1, LP4, RC51 e s verdadero.

—

"tas estructuras matemáticas están entre los descubrimientos más hermosos realizados por la mente humana." Douglas H a f s t a d t e r

Un conjunto especial es el c o n j u n t o vacío 0 . Éste c o r r e s p o n de a cero e n las m a temáticas normales. El conjunto vacío tiene la propiedad de ser un s u b c o n j u n t o de cualquier otro conjunto. Dos útiles identidades que involucran al conjunto vacío son 01>A=A

y 0DA

=0

para cualquier conjunto A, d o n d e u se c o n o c e c o m o el operador unión, a veces conocido c o m o taza; n e s el operador intersección,

a veces conocido c o m o gorra.

El operador unión admite dos c o n j u n t o s y forma u n o que contiene los e l e m e n t o s de los d o s c o n j u n t o s y elimina los duplicados. Por lo tanto, el resultado de la expresión {Archivol, Archivo2, Impuesto, Compilador) u (ImpuestoNuevo, D2, D3, ArchiV02)

es el conjunto (Archivol, Archivo2, Impuesto, Compilador, ImpuestoNuevo, D2, D3)

TM El operador de intersección admite dos c o n j u n t o s y forma u n o q u e consiste de los e l e m e n t o s c o m u n e s e n cada conjunto. Por lo tanto, la expresión

PDF Editor (12, 4, 99, 1} n {1, 13, 12, 77)

genera el conjunto (12, 1).

El operador diferencia de conjuntos,

\, c o m o su n o m b r e sugiere, forma un

conjunto al eliminar los e l e m e n t o s de su s e g u n d o o p e r a n d o de los e l e m e n t o s de su primer operando. Por lo tanto, el valor de la expresión

940

PARTE C I N C O


(Nuevo, Viejo, Archivolmpuesto, ParamSisj \ (Viejo, ParamSis) genera el conjunto (Nuevo, Archivolmpuesto). El valor de la expresión (a, b, c, d) n ( x , y ) será el conjunto vacío 0 . El operador siempre proporciona un conjunto; sin embargo, en este caso n o existen elementos comunes entre sus operandos, así que el conjunto resultante no tendrá elementos. El operador final e s el producto cruzado, x , a veces conocido c o m o producto cartesiano. Éste tiene dos operandos. El resultado e s un conjunto de pares donde cada par consiste d e un elemento t o m a d o del primer operando combinado con un elemento del segundo. Un ejemplo de una expresión que involucra al producto cruzado e s (1, 2) x {4, 5, 6) El resultado de esta expresión es ((1,4), (1,5), (1,6), (2, 4), (2,5), (2,6)) Nótese que cada elemento del primer operando está combinado con cada uno de los elementos del segundo. Un concepto importante en los métodos formales e s el de conjunto potencia. Un conjunto potencia de un conjunto es la colección de todos los posibles subconjuntos de dicho conjunto. El símbolo que se utiliza para este operador de conjunto en este capítulo es P. Se trata d e un operador unitario que, cuando s e aplica a un conjunto, devuelve el conjunto d e subconjuntos de su operando. Por ejemplo, P (1, 2 , 3) = { 0 , (1), (2), (3), ( 1 , 2 ) , (1, 3), (2, 3 ) , (1, 2 , 3))

ya que todos los conjuntos son subconjuntos de (1, 2, 3).

28.2.3

Operadores lógicos

Otro componente importante d e un método formal es la lógica: el álgebra de expresiones verdaderas y falsas. El significado de los operadores lógicos comunes lo comprende bien cualquier ingeniero d e software. Sin embargo, los operadores lógicos asociados con los lenguajes de programación comunes se escriben empleando símbolos disponibles fácilmente en el teclado. Los operadores matemáticos equivalenTM tes son

A

y

PDF Editor V

o

-i

no

=>

implica

La cuantificación universal es una forma de elaborar un planteamiento acerca de los elementos de un conjunto que resulta verdadero para cualquier miembro del

CAPÍTULO 28

841

MÉTODOS FORMALES

conjunto. La cuantificación universal utiliza el símbolo v. Un ejemplo de su utilización es V

, N • i >j =* i 2 > j 2

en donde se establece que para cada par de valores en el conjunto de números naturales, si / e s mayor que j, entonces i2 e s mayor que j2.

28.2.4 Sucesiones Una sucesión es una estructura matemática que modela el hecho de que s u s elementos están ordenados. Una sucesión s e s un conjunto de pares cuyos elementos varían de 1 al elemento de mayor número. Por ejemplo, {(1, Jones), (2, Wilson), (3, Shapiro), (4, Estavez)] e s una sucesión. Los elementos que forman los primeros elementos de los pares se conocen colectivamente como dominio de la sucesión, y la colección de segundos elementos s e conoce c o m o el intervalo de la sucesión. En este libro, las sucesiones están indicadas mediante corchetes angulados. Por ejemplo, la sucesión precedente normalmente se escribiría como (Jones, Wilson, Shapiro, Estavez). A diferencia de los conjuntos, la duplicación se permite en una sucesión, cuyo orden e s importante. Por lo tanto, (Jones, Wilson, Shapiro) * (Jones, Shapiro, Wilson) La sucesión vacía se representa como (). En las especificaciones formales se utilizan varios operadores de sucesión. La concatenación, —, e s un operador binario que forma una sucesión construida al agregar su segundo operando al final de su primer operando. Por ejemplo, (2,3,34,1)

(12,33,34,200)

genera la sucesión (2, 3, 34, 1,12, 33, 34, 200). Otros operadores que se aplican a las sucesiones son cabeza, cola, frente y último. El operador cabeza extrae el primer elemento de una sucesión; cola proporciona los últimos n - 1 elementos en una sucesión de longitud n; último extrae el elemento final en una sucesión; y frente proporciona los primeros n - 1 elementos en una sucesión de longitud n. Por ejemplo, cabeza (2, 3, 34, 1, 99, 101) = 2 cola (2, 3, 34, 1, 99, 101) = (3, 34, 1, 99, 101) último (2, 3,34, 1,99, 101)= 101 frente (2, 3, 34, 1, 99, 101) = (2, 3, 34, 1, 99)

TM

PDF Editor

Dado que una sucesión e s un conjunto de pares, se pueden aplicar todos los operadores de conjunto descritos en la sección 28.2.2. Cuando se emplea una sucesión en un estado, se debe designar mediante la palabra seq. Por ejemplo, ArchivoLista : seq ARCHIVOS NumUsuarios : N

342

PARTE C I N C O


describen un estado con dos c o m p o n e n t e s : una sucesión de archivos y u n número natural.

28.3

APLICACIÓN PE LA NOTACIÓN MATEMÁTICA PARA LA

«ACION FORMAL

El empleo de la notación m a t e m á t i c a en la especificación formal de un componente de s o f t w a r e se ilustrará r e p a s a n d o el gestor de bloques p r e s e n t a d o en la sección 28.1.3. Un importante c o m p o n e n t e de un sistema operativo de c o m p u t a d o r a mantiene los archivos que h a n creado los usuarios. El gestor de bloques m a n t i e n e un depósito de bloques no utilizados y también seguirá los bloques a c tu a lm e n t e en uso Cuando se liberan bloques de un archivo borrado n o r m a l m e n t e se a ñ a d e n a una fila de bloques que e s p e r a n ser añadidos al depósito de bloques no utilizados. En la figura 28.2 se ha bosquejado esto esquemáticamente. 4 ^ ¿Cómo s e • pueden r e p r e s e n t a r los estados e invariantes de iiftlAr aempieunuo mhIaahiia aaiu>

los o p e r a d o r e s lógicos y de conjuntos que ya se han introducido?

Un conjunto llamado BLOQUES consistirá de t o d o s los n ú m e r o s de bloque. TodosBloques es un conjunto de bloques que se ubica e n t r e 1 y MáxBloques.

El e s t a d o lo

modelarán dos c o n j u n t o s y u n a sucesión. Los dos c o n j u n t o s son usados y Ubres. Ambos contienen bloques: el conjunto usados contiene los bloques que a c tu a lm e n t e se están utilizando en los archivos, y el conjunto libres contiene los bloques disponibles para los archivos nuevos. La sucesión contendrá c o n j u n t o s de bloques que están listos para ser liberados de los archivos que se han borrado. El e s t a d o se p u e d e describir c o m o usados, libres-, P BLOQUES FilaBloques: seq P BLOQUES Esto es m u y parecido a la declaración de variables de programa. Establece que usa dos y libres serán c o n j u n t o s de bloques y que FilaBloques será una sucesión, cada elemento de la cual será un conjunto de bloques. El invariante de datos se p u e d e escribir c o m o usados n libres = 0 A usados u libres = TodosBloques

A

V i: d o m FilaBloques • FilaBloques i c usados A V i, j: d o m FilaBloques • i * j => FilaBloques i n FilaBloques j = 0 Infotmoción extemo acerco de ios métodos formales se puede encontrar en . w w w ,

afm.sbu.ac.uk.

Los c o m p o n e n t e s m a t e m á t i c o s del invariante de d a t o s se corresponden con cuatro de los c o m p o n e n t e s de lenguaje natural m a r c a d o s que se describieron anteriormente. La primera línea del invariante de d a t o s establece que no existiránTM bloques c o m u n e s en las colecciones de bloques u s a d o s y libres. La segunda línea afirma que la colec-

PDF Editor

4 Si no se recuerda bien el ejemplo del gestor de bloques, por favor véase de nuevo la sección 28.1.3 para revisar el invariante de datos, las operaciones, precondiciones y poscondiciones asociadas con el gestor de bloques.

CAPÍTULO 28

843

MÉTODOS F O R M A I S

ción de bloques usados y libres siempre será igual a toda la colección de bloques en el sistema. La tercera linea indica que el i-ésimo elemento en la fila de bloques siempre será un subconjunto de los bloques usados. La línea final afirma que, para cualesquier dos elementos de la fila de bloques que n o son el mismo, no habrá bloques comunes en estos dos elementos. Los dos componentes finales de lenguaje natural del invariante de datos se implementan en virtud del hecho de que usados y libres son conjuntos y por lo tanto n o contendrán duplicados. La primera operación que se definirá es la que elimina un elemento de la cabeza de la fila de bloques. La precondición es que debe existir al menos un elemento en la fila: # FilaBloques > 0, La poscondición es que la cabeza de la fila debe eliminarse y colocarse en la colección de bloques libres, y la Fila se debe ajustar para mostrar la eliminación: usados' = usados \ cabeza FilaBloques A libres' = libres u cabeza FilaBloques A FilaBloques' = cola FilaBloques Una convención que se utiliza en muchos métodos formales es que al valor de una variable después de una operación se le pone prima. Por lo tanto, el primer componente de la expresión precedente afirma que los nuevos bloques usados {usados') serán iguales a los antiguos bloques usados m e n o s los bloques que se han eliminado. El segundo componente afirma que los nuevos bloques libres (libres') serán los antiguos bloques libres más la cabeza de la fila de bloques. El tercer componente establece que la nueva fila de bloques será igual a la cola del antiguo valor d e la fila de ^ V

¿Cómo s e representan

•sprey M acondiciones?

bloques; esto es: todos los elementos en la fila, menos el primero. Una segunda operación agrega una colección de bloques, Abloques, a la fila de bloques. La precondición e s que Abloques sea actualmente un conjunto de bloques usados: Abloques c usados La poscondición es que el conjunto de bloques sea añadido al final d e la fila, y el conjunto de bloques usados y libres permanezca invariable: FilaBloques' = FilaBloques usados' = usados A libres' = libres

-Abloques A

TM

PDF Editor

No existe duda de que la especificación matemática de la fila de bloques es considerablemente más rigurosa que una narración en lenguaje natural o un modelo gráfico. El rigor adicional requiere esfuerzo, pero los beneficios obtenidos a partir de la consistencia y la completud mejoradas s e pueden justificar para muchos tipos de aplicaciones.

344

PARTE C I N C O


Un lenguaje formal de especificación usualmente está compuesto de tres componentes principales: 1) una sintaxis que define la notación específica con la que se representa la especificación, 2) semántica para ayudar a definir un "universo de objetos" [WIN90] que se empleará para describir el sistema, y 3) un conjunto de relaciones que definen las reglas que indican cuáles objetos satisfacen adecuadamente la especificación. Con frecuencia, el dominio sintáctico de un lenguaje formal de especificación se basa en una sintaxis que se deriva de la notación estándar de la teoría de conjuntos y el cálculo de predicados. Por ejemplo, variables tales como x,y y z describen un conjunto de objetos que se relacionan con un problema (en ocasiones llamado daminio del discurso) y se utilizan en conjunto con los operadores descritos en la sección 28.2. Aunque la sintaxis usualmente e s simbólica, también se pueden utilizar iconos (por ejemplo, símbolos gráficos como cajas, flechas y círculos) si n o son ambiguos. El dominio semántico de un lenguaje de especificación indica cómo el lenguaje representa los requisitos del sistema. Por ejemplo, un lenguaje de programación tiene un conjunto de semánticas formales que permite al desarrollador de software especificar algoritmos que transforman entrada en salida. Se puede utilizar una gramática formal (como BNF) para describir la sintaxis del lenguaje de programación. Sin embargo, un lenguaje de programación no hace un buen lenguaje de especificación porque sólo representa funciones de cómputo. Un lenguaje de especificación debe tener un dominio semántico más amplio, es decir, debe ser capaz de expresar ideas como "para toda x en un conjunto infinito A, existe una_y en un conjunto infinito B tal que la propiedad P se mantiene para x y / ' [WIN90], Otros lenguajes de especificación aplican semánticas que permiten la especificación del comportamiento del sistema. Por ejemplo, es posible desarrollar una sintaxis y una semántica para especificar estados y transiciones de estado, y eventos, junto con sus efectos sobre la transición de estado, la sincronización y la temporalidad. Es posible usar diferentes abstracciones semánticas para describir el mismo sistema en diferentes formas. En el capítulo 8 esto se hizo en una manera menos formal. Se representaron clases, datos, funciones y comportamiento. Se puede usar diferente notación de modelado para representar el mismo sistema. La semántica de cada representación ofrece visiones complementarias del sistema. Para ilustrar este enfoque cuando se usan métodos formales, suponga que se usa un TMlenguaje formal de especificación para describir al conjunto de eventos que provocan que ocurra un estado particular en un sistema. Otra relación formal bosqueja todas las funciones que ocurren dentro de un estado dado. La intersección de estas dos relaciones proporciona una indicación de los eventos que causarán que ocurran funciones especi-

PDF Editor

ficas. En la actualidad se emplean varios lenguajes formales de especificación. OCL [OMG03], Z ([1S002], [SPJ88], [SP192J), LARCH [GUT93] y VDM [JON91] son lenguajes

CAPÍTULO 2 8

845

MÉTODOS FORMALES

formales de especificación representativos que m u e s t r a n las características a n o t a das con anterioridad. En e s t e capitulo se presenta un breve p a n o r a m a de OCLy Z. PPHJPIM

H

5

El lenguaje restringido a objetos (OCL, por sus siglas en inglés) es una notación formal desarrollada de m o d o que los usuarios de UML p u e d a n conferirle mayor precisión a sus especificaciones. El lenguaje dispone de todo el poder de la lógica y la matemáticas discretas. Sin embargo, los diseñadores de OCL decidieron que en este lenguaje sólo deberían usarse caracteres ASCII (en lugar de notación matemática convencional). Esto permite que el lenguaje sea m á s asequible a las personas m e n o s inclinadas a las matemáticas y que la computadora los procese con mayor facilidad. Pero e s t o t a m bién favorece que OCL sea un p o c o farragoso en algunos lugares.

28.5.1

Un breve panorama de la sintaxis y la semántica del OCL

La utilización del OCL requiere que u n ingeniero de s o f t w a r e comience con uno o m á s d i a g r a m a s UML: las clases, estados o d i a g r a m a s de actividad m á s comunes. Por lo tanto, se agregan expresiones OCL que establecen hechos acerca de los elementos de los diagramas. Estas expresiones se llaman restricciones; cualquier implementación derivada del modelo d e b e garantizar que cada una de las restricciones siempre p e r m a n e z c a verdadera. Al igual que el lenguaje d e programación orientado a objetos, u n a expresión OCL R e f e r e n c i a Web

involucra o p e r a d o r e s que operan sobre los objetos. Sin embargo, el resultado de u n a expresión completa siempre d e b e ser booleana, e s decir: verdadero o falso. Los o b -

xereoc de encontrar» www-3.ibm.tMii/

jetos pueden ser instancias de la clase OCL C o l e c c i ó n , de la cual C o n j u n t o y Suc e s i ó n son d o s subclases.

software/

El objeto s e l f (propio) es el e l e m e n t o del diagrama UML en cuyo contexto s e eva-

awdtoolt/

luará la expresión OCL. Se pueden obtener otros objetos al navegar u s a n d o el sím-

faary/ itandords/

bolo . (punto) del objeto self. Por ejemplo:

od.hlmf.

• Si s e l f e s clase C, c o n atributo a, e n t o n c e s self.a evalúa al objeto a l m a c e n a d o en

a.

• Si C tiene una asociación multívoca llamada asoc con otra clase D, e n t o n c e s seif.aeoc evalúa un C o n j u n t o cuyos e l e m e n t o s son del tipo D. . Finalmente (y un p o c o m á s sutil), si D tiene un atributo b, e n t o n cTM e s la expresión self.asoc.b evalúa el c o n j u n t o de t o d a s las b que p e r t e n e c e n a todas las D.

PDF Editor 5

Esta sección es una aportación del profesor Timoíhv Lethbridge, de la Universidad de Ottawa, y se presenta aquí medíate autorización

346

PARTE C I N C O


El OCL proporciona operaciones construidas que implementan las matemáticas descritas en la sección 28.2, y más. En la tabla 28.1 se presenta una pequeña muestra de estas operaciones. TABLA 2 8 . 1

R E S U M E N DE N O T A C I Ó N C L A V E O C L

N o t a c i ó n OCL

Significado

x.y

Obtiene la propiedad y del objeto x. Uno propiedad puede se? un atributo, el conjunto d e objetos al final d e una asociación, el resultado d e evoluar una operación u otras cosas que d e p e dan del tipo d e diagrama UML. Si x e s un Conjunto, entonce; y se aplica a todo elemento d e x; los resultados se juntan en i nuevo Conjunto.

c->« 1

Aplica la operación OCL incorporada f a la Colección c misma (en oposición a c a d o uno d e los objetos en c). Los ejemplo: d e operaciones incorporadas se presentan líneas a b a j o .

y, or, = , O

y lógica, o lógica, igual, no igual.

p implies q

Verdadero si q es verdadera o p e s falsa.

Muestra d e o p e r a c i o n e s s o b r e colecciones (incluye conjuntos y secuencias) c->size(]

Número d e elementos en lo Colección c.

c->esEmpty|)

Verdadero si c no tiene elementos, falso d e cualquier otro modo.

e l — > i nc 1 udesAI l(c 2)

Verdadero si todo elemento d e c 2 se encuentra en c 1.

e l ->excludesAII(c2|

Verdadeio si ningún elemento d e c 2 se encuentra en e l .

e l ->forAII(elem 1 boolexpr)

Verdadero si boolexpr ¡expresión booleana) es verdadera cuand o se aplica a lodo elemento d e c. Conforme se evalúa un elemento, se liga a la variable elem |elemento|. que se p u e d e usar en boolexpr. Esto implementa cuantificación universal, estudiada previamente.

c->forAII(eleml, e¡em2 1 boolexprl

Lo mismo que antes, excepto que boolexpr se evalúa para lod o posible par d e elementos lomados d e c, incluso casos dond e el par consiste del mismo elemento.

c - > i s unique|elem 1 expr|

Verdadero si expr (expresión] evalúa un valor diferente cuando se aplica a lodo elementa d e c.

Muestra d e operaciones específicas a conjuntos s i ->interseclion(s2)

El conjunto de aquellos elementos que se encuentran TM en si y también en s2.

si - > u n i o n ( s 2 |

El conjunto de aquellos elementos que se encuentran en si o en s2.

PDF Editor si ->excluding(x)

El conjunto si con el objeto x omitido.

Muestra de operación especifica a secuencias seq—>first()

El objeto que e s el primer elemento en la sucesión seq.

CAPÍTULO 2 8

MÉTODOS FORMALES

847

28.5.2 Ejemplo de uso del OCL En esta sección se utiliza el OCL para ayudar a formalizar la especificación del ejemplo del gestor de bloques, introducido en la sección 28.1.3. El primer paso consiste en desarrollar un modelo UML. En este ejemplo se comienza con el diagrama de clase de la figura 28.3. Este diagrama especifica muchas relaciones entre los objetos involucrados; sin embargo, se deben agregar expresiones OCL que garanticen que quienes implementen el sistema conozcan con mayor precisión qué deben asegurar que permanezca verdadero conforme se desarrolle el sistema. Las expresiones OCL que se agregarán corresponden a las seis partes del invariante tratadas en la sección 28.1,3. Respecto de cada una se repetirá el invariante en español y luego se brindará la correspondiente expresión OCL. Se considera una buena práctica ofrecer el texto en español junto con la lógica formal; hacerlo ayuda al lector a comprender la lógica, y también apoya a los revisores a descubrir errores, por ejemplo: situaciones donde el español y la lógica no correspondan. 1. Ningún bloque se marcará al mismo tiempo como no usado y usado. c o n t e x t GestorBIoques inv: ( s e l f . u s a d o s - > i n t e r s e c t i o n ( s e l f . l i b r e s ) ) - > isEmpty()

Nótese que cada expresión comienza con la palabra clave context (contexto). Esto indica el elemento del diagrama UML que la expresión restringe. En forma alterna, el ingeniero de software podría colocar la restricción directamente en el diagrama UML, rodeada por llaves {). La palabra clave self se refiere a la instancia de GestorBIoq u e s ; e n l o q u e s i g u e , c o m o e s p e r m i s i b l e e n O C L , s e o m i t i r á self.

2. Todos los conjuntos de bloques que se mantienen en la cola serán subconjuntos de la colección de bloques usados actualmente. c o n t e x t GestorBIoques inv: colaBloques->forAII(aConjuntoBloques I usados->includesAII(aConjuntoBloques))

Diagrama de clase para un gestor d e bloques.

TM

PDF Editor

848

PARTE CINCO


3. Ningún número de bloque pertenecerá a dos o más elementos de la fila. c o n t e x t GestorBIoques inv: colaBloques->forAII(conjuntoBloquesl,conjuntoBloques2 | conjuntoBloquest O

c o n j u n t o B l o q u e s 2 ¡mplies

conjuntoBloquesl. elementos, número — >excludesAII(conjuntoBloques2. elementos.número))

La expresión antes de implies (implica) es necesaria para asegurar que se ignoran los pares donde a m b o s elementos son el mismo bloque. 4 . La colección de bloques utilizados y bloques sin usar será la colección total de bloques que constituyen los archivos, c o n t e x t GestorBIoques inv: alIBIooks = u s a d o s - > u n ¡ o n ( l ¡ b r e s )

5. La colección de bloques sin usar no tendrá números de bloques duplicados, c o n t e x t GestorBIoques inv: libres->¡sUnique(aBloque | aBloque.número)

6. La colección de bloques utilizados no tendrá números de bloques duplicados, c o n t e x t GestorBIoques inv: u s a d o s - > i s U n i q u e ( a B l o q u e | aBloque.número)

El OCL también se utiliza para especificar precondiciones y poscondiciones de operaciones. Por ejemplo, considérense las operaciones que eliminan y agregan conjuntos de bloques de la cola. La notación x@pre indica que el objeto x existe antes de la operación; esto es, opuesto a la notación matemática expuesta con anterioridad, donde la x después de la operación es la que está designada especialmente (como x'). c o n t e x t GestorBIoques: :eliminarBloques() pre: c o l a B l o q u e s - > s i z e ( ) > 0 post: usados = usado@pre -

c o l a B l o q u e s @ p r e - > f i r s t ( ) and

libres = l i b r e @ p r e — > u n i o n ( c o l a B l o q u e s @ p r e - > f i r s t ( ) and colaBloques = c o l a B l o q u e s @ p r e - > e x c l u d ¡ n g ( c o l a B l o q u e s @ p r e - > f i r s t ) c o n t e x t G e s t o r B l o q u e s : : a g r e g a r B l o q u e s ( a C o n j u n t o B l o q u e s .-ConjuntoBloques)

TM

pre: usados—>includesAII(aConjuntoBloques.elementos) p o s t : (colaBloques.elementos = c o l a B l o q u e s . e l e m e n t o s @ p r e

PDF Editor - >append(aConjuntoBloques))

and u s a d o s = u s a d o @ p r e and libres = libre@pre

El OCL es un lenguaje de modelado, pero tiene todos los atributos de un lenguaje formal. También permite la expresión de varias restricciones, precondiciones y poscon-

CAPITULO 28

MÉTODOS FORMALE

849

diciones, guardias y otras características que relacionan a los objetos representados en varios modelos UML.

Z es un lenguaje de especificación que ha evolucionado durante las dos décadas pasadas y hoy se utiliza ampliamente entre la comunidad de los métodos formales. El lenguaje Z aplica conjuntos tipificados, relaciones y funciones dentro del contexto de predicados lógicos de primer orden para construir esquemas, un medio para estructurar una especificación formal.

28.6.1 lotod - puede encontrai en «ww-users.fs. fOfk.iKJik/ -wson/obs/z.

Breve panorama de la sintaxis y semántica Z

Las especificaciones Z están organizadas como un conjunto de esquemas; e s decir, una estructura parecida a un recuadro que introduce variables y especifica la relación entre éstas. Un esquema es, en esencia, la especificación formal análoga del componente de lenguaje de programación. En la misma forma que los componentes se emplean para estructurar un sistema, los e s q u e m a s se utilizan al estructurar una especificación formal. Un esquema describe los datos almacenados a los que un sistema accede y altera. En el contexto de Z esto se denomina el "estado". La utilización del término estado en Z e s ligeramente diferente de la que se emplea en el resto de este libro.1" Además, el esquema identifica las operaciones que se aplican para cambiar estado y las relaciones que ocurren dentro del sistema. La estructura genérica de un esquema asume la forma: nombreEsquema declaraciones invariante

donde las declaraciones identifican las variables que comprenden el estado del sistema, y el invariante impone restricciones en la forma en la que el estado puede evolucionar. En la tabla 28.2 se presenta un resumen de la notación del lenguaje Z. TM

28.6.2 Un ejemplo que utiliza Z

En esta sección se utiliza el lenguaje de especificación Z para modelar el ejemplo del

PDF Editor

gestor de bloques introducido previamente en este capítulo. El siguiente ejemplo de un esquema describe el estado del gestor de bloques y el invariante de datos:

6

Recuérdese que en otros capítulos estado se emplea para identificar un modo de comportamiento observable externamente para un sistema

850

PARTE C I N C O


GestorBIoques usados, libres: P BLOQUES FilaBloques: seq P BLOQUES usados n libres = 0 A usados u libres = TodosBloques A V;': d o m ColaBIoques • FilaBloques i c usados A V/, j: dom ColaBIoques • + j => ColaBIoques i n ColaBIoques j = 0

TABLA 2 8 . 2

R E S U M E N DE N O T A C I Ó N Z

La notación Z se b a s a en teoría d e conjuntos tipificada y en lógica d e primer orden. Z proporciona ur constructo, llamado esquema, p a r a describir el espacio y las operaciones d e e s t a d o d e una especificación. Un esquema a g r u p a declaraciones d e variable con una lista d e predicados q u e restringen el posble valor d e una variable. En Z el esquema X se define por la forma X declaraciones predicados

las funciones globales y las constantes se definen por la forma declaraciones predicados Lo declaración brinda el tipo d e la función o constante, mientras q u e el predicado proporciona su v a b ' En esta tabla sólo se presenta un conjunto abreviado d e símbolos Z.

Conjuntos: S x x S S S S

:P X e S $ S CT u r n T \ T

0 (x) M S :FX max (S)

S es declarado como conjunto d e Xs. x e s miembro d e S. x no e s miembro d e S. S e s un subconjunto d e T: lodo miembro d e S también está en T. La unión d e S y T: contiene a todo miembro d e S o T o ambos. La intersección d e S y T: contiene a todo miembro q u e está tonto en S como en T. La diferencia d e S y T: contiene a todo miembro d e S, excepto a aquellos q u e también están en T. Conjunto vacío: no contiene miembros. TM Conjunto unitario: sólo contiene a x. El conjunto d e los números naturales 0 , 1, 2,... S es declarado como conjunto finito d e X. El máximo del conjunto no vacío d e números S.

PDF Editor Funciones: f:X >-» dom f ron f í©(*i-)y) dom f

f e s declarado c o m o una inyección parcial d e X a Y. El dominio d e f: el conjunto d e valores x paro los cuales está definida f(x|. El rango d e f: el conjunto d e valores q u e toma f(x| conforme x varía sobre el dominio d e f. Una función q u e concuerda con f, excepto que x se correlaciona con y. Una función como f, excepto q u e x e s eliminado d e su dominio.

CAPÍTULO 28 Lógica: PA Q P => Q 0 S'= 0 S

MÉTODOS FORMALE

851

P y Q : es verdadero si tanto P como Q son verdaderos. P implica Q : es verdadero si o Q es verdadera o P e s falsa. Ningún componente de! esquema S cambia en uno operación.

Como se ha señalado, el esquema consiste de dos partes. La parte sobre la línea central representa las variables del estado, mientras que la parte debajo de la línea central describe el invariante de datos. Siempre que el esquema especifica las operaciones que cambian el estado lo precede el símbolo A. El siguiente ejemplo de esquema describe la operación que elimina un elemento de la cola de bloques: EliminarBloques A GestorBloques #GestorBloques > 0, usados' = usados \ cabeza CoIaBloques A libres' = libres u cabeza CoIaBloques A CoIaBloques' = cola CoIaBloques

La inclusión de A GestorBloques resulta en todas las variables que configuran el estado que estará disponible para el esquema EliminarBloques y asegura que el invariante de datos se mantendrá antes y después de que la operación se haya ejecutado. La segunda operación, que añade una colección de bloques al final de la cola, está representada como AñadirBloquesA GestorBloques Abloques? : BLOQUES Abloques? c usados FilaBloques' = FilaBloques usados' = usados A libres' = libres A

(Abloques?) A

TM

PDF Editor

Por convención en Z, una variable de entrada que se lee pero n o forma parte del estado termina con un signo de interrogación. Por ende, Abloques?, que actúa como parámetro de entrada, termina con un signo de interrogación.

852

PARTE CINCO



Métodos formales O b j e t i v o : El objetivo d e las herramientas d e los métodos formales es auxiliar al equipo d e software en la especificación y verificación d e la corrección.

d e programación con el q u e p u e d e modelar sistemas de cómputo, como una herramienta p a r a ayudarlo a prob a r las propiedades d e dichos modelos". EVES, desarrollada por ORA C a n a d á (www.ora.on,ca/e-

M e c á n i c a : La mecánica d e las herramientas varía. En

ves.html), implemento el lenguaje Verdi p a r a especifi-

general, ayudan en la especificación y en la prueba auto-

cación formal y un g e n e r a d o r d e pruebas automatizado.

mática d e la corrección, usualmente al definir un lenguaje especializado p a r a la prueba d e teoremas. Muchas herramientas no se comercializan y se han desarrollado con propósitos d e investigación.

Una lista extensa con más d e 9 0 herramientas d e métodos formales se puede encontrar en http://www.afm.sbu.ac.uk/.

Herramientas representativas 7 ACL2, desarrollada en la Universidad d e Texas (www.cs.u^

t e x a s . e d u / u s e r s / m o o r e / a d 2 / ) , e s "tanto un lenguaje

La decisión de usar m é t o d o s formales en el m u n d o real n o es u n a q u e se tome a la ligera. Bowan y Hinchley [BOW95] h a n a c u ñ a d o "los diez m a n d a m i e n t o s de los métodos formales" c o m o u n a guía para aquellos que están a punto de aplicar este importante enfoque de la ingeniería de software. 8 1. Elegirás la notación apropiada. Para elegir con eficacia de u n a amplia variedad de lenguajes formales de especificación, un ingeniero de s o f t w a r e debe considerar el vocabulario del lenguaje, el tipo de aplicación q u e se especificará y la amplitud de uso del lenguaje.

2. Formalizarás pero no en exceso. Por lo general no es necesario aplicar los métodos formales en todos los aspectos d e un gran sistema. Aquellos compon e n t e s cruciales para la seguridad son las primeras elecciones, seguidos por los c o m p o n e n t e s cuya falla n o p u e d e tolerarse (por r a z o n e s de negocios). 3 . Estimarás los costos. Los m é t o d o s formales tienen elevados costos de arranque. El entrenamiento del equipo, la adquisición de herramientas de apoyo y la utilización d e consultores redunda en altos costos al inicio. Es preciso conTM la inversión siderar dichos costos c u a n d o se examina el rendimiento sobre asociada con los métodos formales.

PDF Editor

7 Las herramientas mencionadas sólo representan una muestra de esta categoría. En la mayoría de los casos, los nombres de las mismas son marcas registradas por sus respectivos desarrolladores. 8 Este tratamiento es una versión más abreviada de IBOW95],

CAPÍTULO 28

MÉTODOS FORMALES

853

4 . Tendrás un experto en métodos formales a tu disposición. El entrenamiento experto y la consultaría de seguimiento son esenciales para el éxito cuando se emplean los métodos formales por primera ocasión. 5. No abandonarás los métodos tradicionales de desarrollo. Es posible, y en muchos casos deseable, integrar los métodos formales con métodos convencionales u orientados a objetos (parte 2 de este libro). Cada uno tiene fortalezas y debilidades. Una combinación, si se aplica con propiedad, puede producir excelentes resultados. 9 6. Documentarás suficientemente.

Los métodos formales proporcionan un méto-

do conciso, sin ambigüedades y consistente para documentar los requisitos del sistema. Sin embargo, es recomendable que un comentario en lenguaje natural acompañe la especificación formal y sirva como mecanismo para reforzar la comprensión del lector acerca del sistema. 7. No comprometerás los estándares de calidad. "No hay nada mágico en los métodos formales" [BOW95], y por esta razón debe continuar la aplicación de otras actividades de SQA (capítulo 26) conforme los sistemas se desarrollen. 8.

No serás dogmático. Un ingeniero de software debe reconocer que los métodos formales no regarantizan la corrección. Es posible (alguien diría, probable) que el sistema final, aun cuando se desarrolle empleando métodos formales, puede tener pequeñas omisiones, bugs menores y otros atributos que no satisfagan las expectativas.

9. Probarás, probarás y probarás de nuevo. La importancia de las pruebas del software se ha estudiado en los capítulos 13 y 14. Los métodos formales n o absuelven al ingeniero de software de la necesidad de llevar a cabo pruebas extensivas bien planeadas. 10.

Reutilizarás. A largo plazo, la única forma racional de reducir los costos de software y aumentar la calidad de éste es mediante la reutilización (capítulo 30). Los métodos formales no cambian esta realidad. De hecho, es posible que los métodos formales sean un enfoque apropiado cuando se han de crear componentes para librerías de reutilización.

TM Aunque las técnicas formales de especificación b a s a d a s matemáticamente no se emplean con amplitud en la industria, sí ofrecen ventajas sustanciales sobre las técnicas menos formales. Liskov y Bersins [LIS86] resumen esto así:

PDF Editor 9

La ingeniería de software de sala limpia (capitulo 29) es un ejemplo de un enfoque integrado que utiliza métodos formales y métodos de desarrollo más convencionales.

PARTE C I N C O


Las especificaciones formales se p u e d e n estudiar m a t e m á t i c a m e n t e , pero n o las informales. Por ejemplo, un programa correcto se prueba para satisfacer s u s especificaciones, o se p u e d e probar que dos c o n j u n t o s alternativos d e especificaciones son equivalentes... Ciertas formas de incompletud o inconsistencia se p u e d e n detectar a u t o m á t i c a m e n t e .

Además, la especificación formal elimina la ambigüedad y alienta el mayor rigor en las primeras etapas del proceso de ingeniería del software. No obstante, los problemas persisten. La especificación formal se enfoca principalmente en la función y los datos. La temporalidad, el control y los aspectos de comportamiento de un problema son más difíciles de representar. Además, ciertos elementos de un problema (por ejemplo, interfaces h u m a n o / m á q u i n a ) se especifican mejor empleando técnicas gráficas o prototipos. Finalmente, la especificación que emplea métodos formales es más difícil de aprender que los métodos que incorporan notación UML y representan un significativo "choque cultural" para algunos profesionales del software.

Los métodos formales ofrecen un cimiento para los entornos de especificación que conducen a modelos de análisis m á s completos, consistentes y sin ambigüedades que aquellos producidos con métodos convencionales u orientados a objetos. Las facilidades descriptivas de la teoría de conjuntos y la notación lógica permiten que un ingeniero d e software cree un planteamiento claro de hechos (requisitos). Los conceptos subyacentes que rigen los métodos formales son 1) el invariante de datos, una condición verdadera a través d e la ejecución del sistema que contiene una colección de datos; 2) el estado, una representación del modo de comportamiento observable externamente de un sistema, o (en Z y lenguajes relacionados) los datos almacenados a los que un sistema tiene acceso y altera; y 3) la operación, una acción que tiene lugar en un sistema y lee o escribe datos a un estado. Una operación está asociada con dos condiciones: una precondición y una poscondición. Las matemáticas discretas —la notación y heurísticas asociados con conjuntos y la especificación constructiva, operadores de conjuntos, operadores lógicos y sucesiones— forman la base de los métodos formales. Las matemáticas discretas se implementan en el contexto de los lenguajes formales de especificación, tales como OCL y Z. Estos lenguajes tienen dominios tanto sintáctico como semántico. El domiTM nio sintáctico utiliza una simbología alineada de manera cercana con la notación de conjuntos y el cálculo de predicados. El dominio semántico permite que el lenguaje exprese los requisitos en una forma concisa. La decisión de usar métodos formales debe considerar los costos de arranque, así como los cambios culturales asociados con una tecnología radicalmente diferente. En la mayoría de las instancias, los métodos formales tienen mayores rendimientos

PDF Editor respecto de los sistemas cruciales para la seguridad y los negocios.

CAPÍTULO 28

MÉTODOS FORMALES

855

[BOW95] Bowan, J. P., y M. G. Hinchley, 'Ten C o m m a n d m e n t s of Formal Methods", en Computer, vol. 28, n ú m . 4, abril de 1995. [GRI95J Gries, D., y F. B. Schneider, A Logical Approach to Discrete Math, Springer-Verlag, 1993. [GUT93] Guttag, J. V., y j. J. Horning, Larch. Languages and Tools for Formal Specification, Springer-Verlag, 1993. [HAL90] Hall, A., "Seven Myths of Formal Methods", en IEEE Software, septiembre de 1990, pp. 11-20.

[HOR85J Hoare, C.A.R., Communicating Sequential Processes, Prentice-Hall International, 1985. [IS002] Zformal Specification Notation-Syntax, Type System and Semantics, 1SO/1EC 13568:2002, Intl. Standards Organization, 2002. LFON91] Jones, C. B., Systematic Software Development Using VDM, 2a. ed., Prentice-Hall, 1991. [US86] Liskov, B. H., y V. Berzins, "An Appraisal of Program Specifications", en Software Specification Techniques, N. Gehani y A. T. McKittrick (eds.), Addison-Wesley, 1986, p. 3. [MAR94] Marciniak, J. J. (ed.) Encyclopedia of Software Engineering, Wiley, 1994. IOMG03] "Object Constraint Language Specification", en Unified Modeling Language, v2.0, Object M a n a g e m e n t Group, septiembre de 2003, se p u e d e descargar de www.omg.org. IROS95] Rosen, K. H„ Discrete Mathematics and Its Applications, 3a. ed., McGraw-Hill, 1995. (SPI88) Spivey, J. M., Understanding Z: A Specification Language and Its Formal Semantics, Cambridge University Press, 1988. [SPI92) Spivey, J. M., The Z Notation: A Reference Manual, Prentice-Hall, 1992. ¡WIL87) Wiltala, S. A., Discrete Mathematics: A Unified Approach, McGraw-Hill, 1987. [WIN90] Wing, J. M., "A Specifier's Introduction to Formal Methods", Computer, vol.23, n ú m . 9, septiembre d e 1990, pp. 8-24. [YOU941 Yourdon, E., "Formal Methods", Guerrilla Programmer, Cutter Information Corp., octubre de 1994.

2 8 . 1 . Revisar los tipos d e deficiencias asociadas con los e n f o q u e s m e n o s formales para la ingeniería del software d e la sección 28.1.1. Ofrecer tres ejemplos d e cada u n o a partir d e la experiencia propia. 2 8 . 2 . Los beneficios de las m a t e m á t i c a s c o m o m e c a n i s m o de especificación se h a n tratado ext e n s a m e n t e en e s t e capítulo. ¿Existe algún a s p e c t o negativo? 2 8 . 3 . Usted ha sido asignado a un equipo que está desarrollando software p a r a un fax m ó d e m . Su tarea es desarrollar la parte de "directorio" d e la aplicación. La función directorio permite que a l m a c e n e n hasta MaxNombres p e r s o n a s junto con los asociados de n o m b r e s de c ompa ñía , núm e r o s d e fax y otra información relacionada. E m p l e a n d o lenguaje natural defina a) El invariante d e datos b) El estado. c) Las operaciones probables. 2 8 . 4 . Usted ha sido asignado a un equipo que está desarrollando software, llamado Duplicador de memoria, q u e ofrece mayor memoria a p a r e n t e p a r a u n a PC q u e la memoria física. TM Esto se logra al identificar, recopilar y reasignar bloques d e memoria que s e h a n a s i g n a d o a una aplicación existente pero que n o se utilizan. Los bloques n o utilizados se reasignan a las aplicaciones que requieren memoria adicional. Con las suposiciones apropiadas y el u s o d e lenguaje natural, defina

PDF Editor a) El invariante d e datos. b) El estado. c) Las operaciones probables

2 8 . 5 . Desarrolle u n a especificación consirucnva para un c o n j u n t o que contiene duplas d e núm e r o s naturales de la forma {x,y, z~\ tales q u e la s u m a d e x y y es igual a z.

856

PARTE C I N C O


2 8 . 6 . El instalador para u n a aplicación b a s a d a en PC determina primero si e s t á n presentes u conjunto aceptable d e hardware y recursos del sistema. Verifica la configuración del h a r d w a : ; para determinar si e s t á n p r e s e n t e s varios dispositivos (de m u c h o s posibles dispositivos) y determina si ya están instaladas versiones específicas de s o f t w a r e y controladores del s i s t e m a ¿Qué o p e r a d o r de conjunto se podría usar p a r a lograr esto? Ofrecer un ejemplo en este contexto. 2 8 . 7 . Intentar desarrollar u n a expresión utilizando o p e r a d o r e s lógicos y d e conjunto para el siguiente enunciado: "Para toda x ey, si x es el padre áeyyy es el padre de z, e n t o n c e s x es el abuelo d e z. Todos tienen un padre." Sugerencia: e m p l e a r las funciones P(x,y) y G(x, /.) p a r a representar las funciones padre y abuelo, respectivamente. 2 8 . 8 . Desarrollar u n a especificación constructiva de c o n j u n t o del conjunto de pares d o n d e el primer elemento d e c a d a par es la s u m a d e d o s n ú m e r o s naturales distintos de cero, y el segund o e l e m e n t o e s la diferencia entre los m i s m o s n ú m e r o s . A m b o s n ú m e r o s deben estar entre 100 y 200, inclusive. 2 8 . 9 . Desarrollar una descripción m a t e m á t i c a p a r a el estado y el invariante de datos del problema 28.3. Refinar esta descripción en el lenguaje de especificación OCL o Z. 2 8 . 1 0 . Desarrollar u n a descripción m a t e m á t i c a p a r a el estado y el invariante de datos del problema 28.4. Refinar esta descripción en el lenguaje de especificación OCL o Z. 2 8 . 1 1 . Mediante la notación OCL o Z p r e s e n t a d a s en las tablas 28.1 o 28.2, seleccionar alguna parte del sistema d e seguridad HogarSeguro descrito previamente en este libro e intentar describirla con OCL o Z. 2 8 . 1 2 . Empleando una o m á s de las fuentes d e información que a p a r e c e n en las referencias de este capítulo o en "Otras lecturas y f u e n t e s d e información", desarrollar u n a presentación de media hora acerca de la sintaxis y la semántica básicas de un lenguaje formal d e especificación distintos a OCL o Z.

V»*.®

A d e m á s de los libros e m p l e a d o s c o m o referencias en este capítulo, d u r a n t e la década pasada se publicaron n u m e r o s o s libros acerca d e t e m a s de métodos formales. A continuación se pres e n t a una lista de algunos d e los m á s útiles: Bowan, J., Formal Specijication

and Documentation

using Z: A Case Study Approach,

Interna-

tional Thomson Computer Press, 1996. Casey, C„ A Programming Approach lo Formal Methods, McGraw-Hill, 2000. Clark, T„ et al. (eds.), Object Modeling with OCL, Springer-Verlag, 2002. Cooper, D„ y R. Barden, Z in Practice, Prentice-Hall, 1995. Craigen, D., S. Gerhart y T. Ralston, Industrial Application of Formal Methods to Model, Design andAnalyze Computer Systems, Noyes Data Corp., 1995. Harry, A., Formal Methods Fact File: VDMyZ,

Wiley, 1997.

Hinchley, M., y J. Bowan, Applications of Formal Methods, Prentice-Hall, 1995.

TM

Hinchley, M., y J. Bowan, Industrial Strenght Formal Methods, Academic Press, 1997. H u s s m a n n , H., Formal Foundations for Software Engineering Methods, Springer-Verlag, 1997.

PDF Editor Jacky, J., The Way of Z: Practical Programming Press, 1997. Monin, F., y M. Hinchley, Understanding

with Formal Methods, Cambridge University

Formal Methods, Springer-Verlag, 2003.

Rann, D„ J. Turner y J. Whitworth, Z: A Beginner's Guide, C h a p m a n and Hall, 1994. Ratcliff, B., lntroducing 1994.

Specijication

Using Z: A Practical Case Study Approach, McGraw-Hill,

CAPÍTULO 28

857

MÉTODOS FORMALE;

Sheppard, D., An Introduction to Formal Specification

with Z and VDM, McGraw-Hill, 1995.

Warner,)., y A. Kleppe, Object Constraint Language, Addison-Wesley, 1998. Dean (Essence of Discrete Mathematics, Prentice-Hall, 1996), Gries y Schneider [GRI93] y Lipschultz y Lipson (2000 Solved Problems in Discrete Mathematics, McGraw-Hill, 1991) presentan información útil para q u i e n e s d e b e n a p r ender m á s acerca d e las b a s e s de los m é t o d o s formales. En Internet hay disponible una amplia variedad de f u e n t e s de información acerca de los métodos formales. Una lista actualizada d e referencias en la World Wide Web se p u e d e encontrar en el sitio Web SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P Í T U L O

29 CONCEPTOS CLAVE certificación . . . 8 7 4 especificación d e tajo de estado

.866

especificación d e coja transparente . . . . . . 8 6 6 especificación de caja negra

. . . .865

863

funcional . . . . . 8 6 3 estrategia de sala limpia . . . . 8 6 0 prueba estadística 873

refinamiento 867

«....869 verificación . . . . 8 6 7 verificación de corrección

La filosofía detrás de la ingeniería del software de sala limpia consiste en evitar la de-

prueba. Su modelo de proceso incorpora la certificación estadística de calidad de los incrementos de código conforme se acumulan en el sistema.

especificación

de diseño

E

! uso integrado del modelado convencional de ingeniería del software (y posiblemente los métodos formales), la verificación de programas (pruebas de corrección) y el SQA estadístico se han combinado en una técnica que puede conducir a software de calidad extremadamente alta. La ingeniería de! software de sala limpia es un enfoque que resalta la necesidad de construir la corrección en el software conforme se desarrolla. En lugar del clásico ciclo de análisis, diseño, código, prueba y depuración, el enfoque de sala limpia sugiere un punto de vista diferente [L1N94]:

tos de código correctos la primera vez y verificar su corrección antes de ponerlo a

de estructura

d e uso

DE SALA LIMPIA

pendencia de costosos procesos de eliminación de defectos al escribir los incremen-

especificación de cajas

I N G E N I E R Í A DEL SOFTWARE

. .868

En muchos aspectos, el enfoque de sala limpia eleva la ingeniería de software a otro nivel. Al igual que los métodos formales presentados en el capítulo 28, el proceso de sala limpia destaca el rigor en la especificación y el diseño, y la verificación formal de cada elemento de diseño mediante pruebas de corrección con bases matemáticas. Al extender el enfoque adoptado en los métodos formales, el enfoque de sala limpia también resalta las técnicas para el control estadístico de la calidad, incluso pruebas que se basan en el uso anticipado del software por parte de los clientes. Cuando el software falla en el mundo real, abundan los peligros inmediatos y a largo plazo. Los peligros se relacionan con la seguridad humana, las pérdidas económicas o la operación efectiva del negocio y la infraestructura social. La ingeniería del software de sala limpia es un modelo de proceso que elimina los defectos antes de que puedan generar peligros serios.

¿ Q u é e s ? ¿Cuántas veces se ha escuchado la expresión: "Hazlo bien la primera vez"? Esa es la filosofía primordial d e la ingeniería del software de sala limpia: un proceso que destaca la verificación matemática de la corrección antes de que comiencen la construcción del programa y la certificación de la confiabilidad del software como parte d e la actividad d e pruebas. El rasgo fundamental es tasas de falla

extremadamente b a j a s que serían difíciles O imposibles de lograr empleando métodos menos mer formales. ; TM

¿Quién lo hace? Un ingeniero de software esnerinlmf-ilte ftntrenodo

¿Por q u é e s importante? Los errores implican

PDF Editor

la reelaboración. Ésta lleva tiempo y aumenta los costos. ¿No sería a g r a d a b l e si se pudiese reducir sustancialmente el número de errores (bugs) introducidos conforme el software se dise-

CAPÍTULO 29

INGENIERÍA DEL SOFTWARE

ña y construye? Esa es la premisa de la ingeniería del software d e sala limpia.

¿Cuáles son los pasos? tos modelos de análisis y diseño se crean empleando una representación de estructura de cajas. Una "caja" encapsula el sistema {o a cierto aspecto del sistema) en un g r a d o específico de abstracción. La verificación d e la corrección se aplica una vez que está completo el diseño d e la estructura de cajas. Una vez verificada la corrección d e c a d a estructura d e c a ja comienzan las pruebas estadísticas de utilización. El software se prueba ai definir un conjunto de escenarios de utilización, al determinar la probabilidad de utilización p a r a c a d a escenario y luego definir pruebas aleatorias que concuerden con las probabilidades. Los registros de error resultantes se analizan p a r a permitir el

29.1

IX S A LA

859

LIMPIA

cálculo matemático de la fiabilidad proyectada dei componente de software.

¿Cuál e s el producto obtenido? Se desarro lian especificaciones de caja negra, caja de estado y caja transparente. Los resultados de las pruebas de corrección formales y de las pruebas estadísticas d e utilización se registran.

¿Cómo puedo estar seguro de que lo he hecho correctamente? La prueba formal de corrección se aplica a la especificación de estructura d e cajas. Las pruebas estadísticas de utilización ejercitan los escenarios d e utilización p a r a garantizar que los errores en la funcionalid a d de usuario se descubren y corrigen. Los datos d e prueba se utilizan para proporcionar un indicio d e la fiabilidad del software.

EL E N F O S U F . DE SALA L I M P I A La filosofía d e la "sala limpia" e n las t e c n o l o g í a s d e f a b r i c a c i ó n d e h a r d w a r e e n r e a lidad e s b a s t a n t e simple-, e s e f i c a z e n c u a n t o a c o s t o y t i e m p o p a r a e s t a b l e c e r u n e n f o q u e d e fabricación q u e evite la i n t r o d u c c i ó n de d e f e c t o s d e p r o d u c c i ó n . M á s q u e f a b r i c a r u n p r o d u c t o y l u e g o t r a b a j a r p a r a e l i m i n a r los d e f e c t o s , el e n f o q u e d e sala limpia d e m a n d a la disciplina r e q u e r i d a p a r a e l i m i n a r los e r r o r e s e n la e s p e c i f i c a c i ó n y el d i s e ñ o y l u e g o f a b r i c a r l o e n u n a f o r m a "limpia". Mills, Dyer y Linger [MIL87] p r o p u s i e r o n , d u r a n t e el d e c e n i o d e 1980, originalm e n t e la filosofía d e s a l a limpia p a r a la i n g e n i e r í a del s o f t w a r e . A u n q u e las p r i m e r a s e x p e r i e n c i a s c o n e s t e e n f o q u e d i s c i p l i n a d o r e s p e c t o al t r a b a j o d e s o f t w a r e f u e r o n s i g n i f i c a t i v a m e n t e p r o m e t e d o r a s [HAU94], n o o b t u v o g r a n d i f u s i ó n . H e n d e r s o n [HEN95] s u g i e r e t r e s p o s i b l e s r a z o n e s : 1.

Una c r e e n c i a d e q u e la m e t o d o l o g í a d e s a l a limpia e s d e m a s i a d o t e ó r i c a , d e m a s i a d o m a t e m á t i c a y d e m a s i a d o radical p a r a aplicarla e n el d e s a r r o l l o d e s o f t w a r e real.

2.

TM

N o a b o g a por u n a p r u e b a u n i t a r i a d e p a r t e d e los d e s a r r o l l a d o r e s , s i n o q u e la s u s t i t u y e c o n la verificación d e la c o r r e c c i ó n y el control e s t a d í s t i c o d e la cali-

PDF Editor

d a d , c o n c e p t o s q u e r e p r e s e n t a n u n a g r a n d e s v i a c i ó n d e la f o r m a e n la q u e se d e s a r r o l l a a c t u a l m e n t e la m a y o r í a del s o f t w a r e .

3.

La m a d u r e z d e la industria d e d e s a r r o l l o del s o f t w a r e . La utilización d e los p r o c e s o s d e s a l a limpia r e q u i e r e la rigurosa a p l i c a c i ó n d e p r o c e s o s d e f i n i d o s e n t o d a s l a s f a s e s del ciclo d e vida D a d o q u e g r a n p a r t e d e la industria conti-

860

PARTE CINCO


n ú a o p e r a n d o e n g r a d o s r e l a t i v a m e n t e b a j o s d e m a d u r e z del p r o c e s o , los ing e n i e r o s d e s o f t w a r e n o h a n e s t a d o listos p a r a a p l i c a r las t é c n i c a s d e s a l a limpia. A p e s a r de l o s e l e m e n t o s d e v e r d a d e n c a d a u n a d e e s t a s p r e o c u p a c i o n e s , los b e n e ficios p o t e n c i a l e s de la i n g e n i e r í a del s o f t w a r e de s a l a limpia s u p e r a n c o n m u c h o la inversión r e q u e r i d a p a r a s u p e r a r la r e s i s t e n c i a cultural u b i c a d a e n el c e n t r o d e esta? preocupaciones. "La único forma de que en un programa ocurran los errores es que un autor los coloque ahí. No se conocen otros mecanismos... Ln práctica correcta busca evitar la inserción de errores y, cuando se falla al respecto, eliminarlos antes de probarlo o cualquiera otra forma de ejecutar el programa." Harían Mills

29.1.1 La estrategia d e sala limpia El e n f o q u e d e s a l a limpia utiliza u n a v e r s i ó n e s p e c i a l i z a d a del m o d e l o d e p r o c e s e i n c r e m e n t a l (capítulo 3). M e d i a n t e p e q u e ñ o s e q u i p o s d e s o f t w a r e i n d e p e n d i e n t e s se d e s a r r o l l a u n a "línea de i n c r e m e n t o s d e s o f t w a r e " [LIN94|. C o n f o r m e c a d a increm e n t o s e certifica s e i n t e g r a e n el todo. Por e n d e , la f u n c i o n a l i d a d d e l s i s t e m a crece c o n el t i e m p o . En la figura 29.1 s e ilustra la s u c e s i ó n de las t a r e a s d e s a l a limpia p a r a c a d a increm e n t o . Los r e q u i s i t o s g l o b a l e s del s i s t e m a o p r o d u c t o s e d e s a r r o l l a n e m p l e a n d o los

Incremento 1

Modelo d e l

proceso de s a l a limpia.

TM

I

PDF Editor IS RR EEC DF VC

= = = = =

ingeniería d e sistemas recopilación d e requisitos especificación d e estructura d e c a j a s d i s e ñ o formal verificación d e corrección

GC IC PEU C PP

= = = = =

generación d e código inspección d e c ó d i g o p r u e b a estadística d e uso certificación planeación de pruebas

CAPÍTULO 29

861

INGENIERÍA DEL SOFTWA3E DE SALA LIMPIA

m é t o d o s de i n g e n i e r í a del s o f t w a r e e s t u d i a d o s e n el c a p í t u l o 6. La línea d e increm e n t o s d e s a l a limpia se inicia u n a v e z q u e la f u n c i o n a l i d a d s e h a a s i g n a d o al e l e m e n t o d e s o f t w a r e del s i s t e m a . Se p r o d u c e n las s i g u i e n t e s t a r e a s : ¿Cuáles son fas principales tareas llevate a cabo como Mrte de la inge• e r í a del s o f t w a re de sala limpia?

•

P l a n i f i c a c i ó n d e l i n c r e m e n t o . Se d e s a r r o l l a u n p l a n de p r o y e c t o q u e a d o p t a la e s t r a t e g i a i n c r e m e n t a l . Se c r e a n la f u n c i o n a l i d a d d e c a d a i n c r e m e n t o , su t a m a ñ o p r o y e c t a d o y u n p l a n d e d e s a r r o l l o de sala limpia. Se d e b e t e n e r e s p e c i a l c u i d a d o p a r a a s e g u r a r q u e los i n c r e m e n t o s c e r t i f i c a d o s se i n t e g r a r á n e n f o r m a o p o r t u n a . R e c o p i l a c i ó n d e requisitos. Mediante técnicas similares a las introducidas en el c a p í t u l o 7 s e e l a b o r a u n a d e s c r i p c i ó n m á s d e t a l l a d a d e los r e q u i s i t o s del cliente (para c a d a i n c r e m e n t o ) . E s p e c i f i c a c i ó n d e la e s t r u c t u r a d e c a j a s . Se utiliza u n m é t o d o d e e s p e c i f i c a ción q u e e m p l e a estructuras

de caja [HEV93] p a r a describir la e s p e c i f i c a c i ó n f u n c i o -

nal. Para a j u s t a r s e a los p r i n c i p i o s d e a n á l i s i s o p e r a t i v o t r a t a d o s e n los c a p í t u l o s 5 y 7, las e s t r u c t u r a s d e c a j a s "aislan y s e p a r a n la definición c r e a t i v a d e c o m p o r t a m i e n to, d a t o s y p r o c e d i m i e n t o s e n c a d a g r a d o d e r e f i n a m i e n t o " . D i s e ñ o f o r m a l . E m p l e a n d o el e n f o q u e d e e s t r u c t u r a d e c a j a s el d i s e ñ o d e s a l a limpia e s u n a e x t e n s i ó n n a t u r a l y u n i f o r m e d e la e s p e c i f i c a c i ó n . A u n q u e e s p o s i b l e f . nfomwcióíi y xursosp rgenieifo d

- soto limpio se pueril contrai e n w w w . -ansoft.tom.

e s t a b l e c e r u n a distinción c l a r a e n t r e l a s d o s a c t i v i d a d e s , la e s p e c i f i c a c i o n e s (llamad a s cajas negras)

s o n i t e r a t i v a m e n t e r e f i n a d a s ( d e n t r o d e u n i n c r e m e n t o ) p a r a vol-

v e r s e a n á l o g a s a los d i s e ñ o s a r q u i t e c t ó n i c o y al nivel d e c o m p o n e n t e ( l l a m a d o s cajas de estado y cajas transparentes,

respectivamente).

V e r i f i c a c i ó n d e la c o r r e c c i ó n . El e q u i p o d e sala limpia lleva a c a b o u n a serie d e r i g u r o s a s a c t i v i d a d e s de verificación de la c o r r e c c i ó n e n el d i s e ñ o y l u e g o e n el c ó d i g o . La verificación ( s e c c i o n e s 2 9 . 3 y 29.4) c o m i e n z a c o n la e s t r u c t u r a d e c a j a d e nivel s u p e r i o r (especificación) y se m u e v e h a c i a el detalle d e d i s e ñ o y el código. El p r i m e r nivel de verificación d e c o r r e c c i ó n o c u r r e al a p l i c a r u n c o n j u n t o d e " p r e g u n t a s d e c o r r e c c i ó n " [LIN88J. Si é s t a s n o d e m u e s t r a n q u e la e s p e c i f i c a c i ó n e s c o r r e c t a s e e m p l e a n m é t o d o s m á s f o r m a l e s ( m a t e m á t i c o s ) e n la verificación. G e n e r a c i ó n d e c ó d i g o , i n s p e c c i ó n y v e r i f i c a c i ó n . Las e s p e c i f i c a c i o n e s d e e s t r u c t u r a d e c a j a , r e p r e s e n t a d a s e n un l e n g u a j e e s p e c i a l i z a d o , s e t r a d u c e n al l e n g u a j e d e p r o g r a m a c i ó n a p r o p i a d o . E n t o n c e s s e utilizan c o m p r o b a c i o n e s m a n u a l e s e s t á n d a r o t é c n i c a s d e i n s p e c c i ó n (capítulo 26) q u e g a r a n t i z a n la c o n f o r m i d a d s e m á n t i c a del c ó d i g o y las e s t r u c t u r a s d e c a j a s , así c o m o la c o r r e c c i ó n s i n t á c t i c a del

TM

c ó d i g o . L u e g o s e lleva a c a b o la verificación d e la c o r r e c c i ó n p a r a el c ó d i g o f u e n t e .

PDF Editor

"La ingeniería del software de sala limpio logra el control estadístico de la calidad sobre el desarrollo del software al separar estrictamente el proceso de diseño del proceso de prueba en una línea de desarrollo incremental de software." Harían Mills

P l a n i f i c a c i ó n d e p r u e b a s e s t a d í s t i c a s . Se a n a l i z a el u s o p r o y e c t a d o del s o f t -

w a r e y s e planifica y d i s e ñ a u n c o n j u n t o d e c a s o s d e p r u e b a q u e e j e r c i t a n u n a "dis-

862

ÔNSUO^-

PARTE CINCO


tribución d e p r o b a b i l i d a d " d e utilización (sección 29.4). C o m o s e m u e s t r a e n la figur a 29.1, e s t a act i vi dad d e s a l a limpia s e lleva a c a b o e n p a r a l e l o c o n la especifica-

La sala limpia destococión, la verificación y la g e n e r a c i ó n d e c ó d i g o . las pruebas que P r u e b a e s t a d í s t i c a d e la u t i l i z a c i ó n . C o m o s e r e c o r d a r á , la p r u e b a e x h a u s t i ejercitan lo forma en v a del s o f t w a r e d e c o m p u t a d o r a e s i m p o s i b l e (capítulo 14), p o r lo q u e s i e m p r e e< que el softwore es realmente utilizado. n e c e s a r i o d i s e ñ a r u n n ú m e r o finito d e c a s o s d e p r u e b a . Las t é c n i c a s e s t a d í s t i c a s de Los cosos de uso u t i l i z a c i ó n [POO88] e j e c u t a n u n a s e r i e de p r u e b a s d e r i v a d a s d e u n a m u e s t r a estaofrecen uno introduc- dística (la distribución d e p r o b a b i l i d a d a n o t a d a p r e v i a m e n t e ) d e t o d a s l a s posibles ción al proceso de e j e c u c i o n e s d e p r o g r a m a p o r p a r t e d e t o d o s los u s u a r i o s a partir de u n a p o b l a d o r planeación de o b j e t i v o (sección 29.4). pruebas. C e r t i f i c a c i ó n . U n a v e z c o m p l e t a d a s la verificación, la i n s p e c c i ó n y l a s p r u e b a s d e utilización (y d e q u e t o d o s los e r r o r e s h a y a n s i d o c o r r e g i d o s ) , el i n c r e m e n t o se certifica listo p a r a la i n t e g r a c i ó n . Al igual q u e o t r o s m o d e l o s de p r o c e s o d e s o f t w a r e t r a t a d o s e n o t r a s p a r t e s d e este libro, el p r o c e s o d e sala limpia s e a p o y a s u s t a n c i a l m e n t e e n la n e c e s i d a d de producir análisis de alta calidad y m o d e l o s de diseño. C o m o s e verá m á s a d e l a n t e e n e s t e capítulo, la n o t a c i ó n d e e s t r u c t u r a d e c a j a s e s s i m p l e m e n t e o t r a f o r m a e n la q u e u n inge n i e r o d e s o f t w a r e p u e d e r e p r e s e n t a r los r e q u i s i t o s y el d i s e ñ o . La distinción real dei e n f o q u e d e s a l a limpia e s q u e la verificación f o r m a l s e aplica a los m o d e l o s d e ingeniería.

29.1.2 ¿Qué hace diferente a la sala limpia? Dycr [DYE92] a l u d e a las d i f e r e n c i a s del e n f o q u e d e s a l a limpia c u a n d o d e f i n e el p r o ceso: La sala limpia representa el primer intento práctico d e someter el proceso d e desarrollo de software al control estadístico d e la calidad con u n a estrategia bien definida para la mejora continua de los procesos. Con el fin d e alcanzar esta meta se definió un ciclo d e vida único d e sala limpia, el cual se enfoca en la ingeniería del software b a s a d a en matemátic a s para corregir diseños de s o f t w a r e y en la prueba de s o f t w a r e b a s a d a en estadísticas para la certificación d e la fiabilidad del software.

La ingeniería del s o f t w a r e d e sala limpia difiere d e los m é t o d o s c o n v e n c i o n a l e s y o r i e n t a d o s a o b j e t o s d e la i n g e n i e r í a del s o f t w a r e p o r q u e :

\ CLAVE Los más importantes coracteristicas distintivos de lo solo limpio son lo prueba de la corrección y las s estadísticas de

TM

1. E m p l e a e n f o r m a explícita el control e s t a d í s t i c o d e la calidad. 2.

Verifica las e s p e c i f i c a c i o n e s del d i s e ñ o u t i l i z a n d o u n a p r u e b a d e c o r r e c c i ó n ba-

PDF Editor sada matemáticamente.

3.

I m p l e m e n t a t é c n i c a s d e p r u e b a c o n u n a alta p r o b a b i l i d a d de d e s c u b r i r e r r o r e s de alto impacto.

O b v i a m e n t e , el e n f o q u e d e s a l a limpia a p l i c a la m a y o r í a , si n o t o d o s , l o s p r i n c i p i o s

y c o n c e p t o s b á s i c o s d e la ingeniería del s o f t w a r e p r e s e n t a d o s a lo largo d e e s t e libro.

CAPÍTULO 29

863

INGENIERÍA DEL SOFTWARE DE S A LA LIMPIA

Los b u e n o s a n á l i s i s y p r o c e d i m i e n t o s d e d i s e ñ o s o n e s e n c i a l e s si se q u i e r e o b t e n e r a l t a calidad. P e r o la i n g e n i e r í a d e sala limpia difiere d e las p r á c t i c a s del s o f t w a r e c o n v e n c i o n a l p o r q u e le r e s t a i m p o r t a n c i a ( a l g u n o s dirían, elimina) al p a p e l d e la p r u e b a u n i t a r i a y la d e p u r a c i ó n y r e d u c e d r á s t i c a m e n t e (o elimina) la c a n t i d a d de p r u e b a s q u e r e a l i z a el d e s a r r o l l a d o r del s o f t w a r e . 1 En el d e s a r r o l l o de s o f t w a r e c o n v e n c i o n a l los e r r o r e s se a c e p t a n c o m o un h e c h o ineludible. P u e s t o q u e los e r r o r e s e s t á n c o n d e n a d o s a ser inevitables, c a d a c o m p o n e n t e de p r o g r a m a d e b e p r o b a r s e e n f o r m a individual (para d e s c u b r i r los errores) y l u e g o d e p u r a r s e (para e l i m i n a r los errores). C u a n d o finalmente s e libera el s o f t w a r e , d u r a n t e s u utilización se d e s c u b r e n todavía m á s d e f e c t o s y c o m i e n z a o t r o ciclo d e p r u e b a y d e p u r a c i ó n . La r e e l a b o r a c i ó n a s o c i a d a c o n d i c h a s a c t i v i d a d e s e s c o s t o s a y c o n s u m e m u c h o tiempo. Peor a ú n , p u e d e resultar d e g e n e r a t i v a : la c o r r e c c i ó n de errores tal v e z c o n d u z c a (¡inadvertidamente!) a la introducción de m á s e r r o r e s todavía. "Un aspecto curioso de lo vida es que si te rehusas en absoluto a aceptar lo mejor con frecuencia lo obtienes." W. Somerset Maugham

En la i n g e n i e r í a del s o f t w a r e de s a l a limpia la p r u e b a u n i t a r i a y la d e p u r a c i ó n s e s u s t i t u y e n v e r i f i c a n d o la c o r r e c c i ó n y las p r u e b a s b a s a d a s e n e s t a d í s t i c a s . D i c h a s a c t i v i d a d e s , c o m b i n a d a s c o n la c o n s e r v a c i ó n d e r e g i s t r o s n e c e s a r i a p a r a la m e j o r a c o n t i n u a , h a c e n q u e el e n f o q u e d e s a l a limpia s e a ú n i c o .

29.2

ESPECIFICACIÓN FUNCIONAL Sin i m p o r t a r el m é t o d o d e a n á l i s i s elegido, se a p l i c a n l o s p r i n c i p i o s de a n á l i s i s o p e r a t i v o p r e s e n t a d o s e n el c a p í t u l o 7. Los d a t o s , l a s f u n c i o n e s y el c o m p o r t a m i e n t o s e m o d e l a n . Los m o d e l o s q u e s e o b t i e n e n d e b e n p a r t i c i o n a r s e (refinarse) p a r a p r o p o r c i o n a r c a d a v e z m a y o r detalle. El o b j e t i v o global e s m o v e r s e d e s d e u n a e s p e c i f i c a ción (o m o d e l o ) q u e c a p t u r e la e s e n c i a de u n p r o b l e m a h a s t a u n a e s p e c i f i c a c i ó n q u e ofrezca sustanciales detalles de implementación. La ingeniería del s o f t w a r e d e s a l a limpia c u m p l e c o n los p r i n c i p i o s d e a n á l i s i s o p e r a t i v o e m p l e a n d o u n m é t o d o l l a m a d o especificación

de estructura

de cajas. U n a

" c a j a " e n c a p s u l a al s i s t e m a (o a l g ú n a s p e c t o d e éste) e n a l g ú n g r a d o de detalle. Por m e d i o d e u n p r o c e s o d e e l a b o r a c i ó n o r e f i n a m i e n t o e n niveles, las c a j a s s e r e f i n a n

TM

e n u n a j e r a r q u í a d o n d e c a d a u n a tiene t r a n s p a r e n c i a referencial. Esto es: "el c o n t e n i d o d e i n f o r m a c i ó n de c a d a e s p e c i f i c a c i ó n d e c a j a e s s u f i c i e n t e p a r a definir su refin a m i e n t o , sin d e p e n d e r d e la i m p l e m e n t a c i ó n de a l g u n a otra c a j a " [LIN94], Esto le

PDF Editor

p e r m i t e al a n a l i s t a partir u n s i s t e m a j e r á r q u i c a m e n t e , m o v e r s e d e s d e la r e p r e s e n t a ción e s e n c i a l e n la p a r t e s u p e r i o r h a c i a u n detalle e s p e c í f i c o de la i m p l e m e n t a c i ó n e n el f o n d o . Se utilizan t r e s tipos d e c a j a s : 1

La prueba la realiza un equipo de prueba independiente.

864 ¿Cómo s e logra el refinamiento como parte de una especificación de estructura de cajas?

PARTE CINCO


Caja n e g r a . La c a j a n e g r a e s p e c i f i c a el c o m p o r t a m i e n t o d e u n s i s t e m a o d e una p a r t e de é s t e . El s i s t e m a (o p a r t e d e él) r e s p o n d e a e s t í m u l o s e s p e c í f i c o s (eventos) al aplicar u n c o n j u n t o d e r e g l a s d e t r a n s i c i ó n q u e c o r r e l a c i o n a n el e s t í m u l o c o n u n a respuesta. C a j a d e e s t a d o . La c a j a d e e s t a d o e n c a p s u l a los d a t o s de e s t a d o y s e r v i c i o s (operaciones) e n u n a f o r m a a n á l o g a a l o s o b j e t o s . En e s t a visión d e e s p e c i f i c a c i ó n se r e p r e s e n t a n l a s e n t r a d a s a la c a j a de e s t a d o (estímulos) y las s a l i d a s ( r e s p u e s t a s ) . La c a j a d e e s t a d o t a m b i é n r e p r e s e n t a la "historia d e e s t í m u l o " de la c a j a n e g r a , e s t o e s los d a t o s e n c a p s u l a d o s e n la c a j a de e s t a d o q u e d e b e n c o n s e r v a r s e e n t r e las transiciones implicadas. C a j a t r a n s p a r e n t e . Las f u n c i o n e s d e t r a n s i c i ó n q u e implica la c a j a de e s t a d o s e d e f i n e n e n la c a j a t r a n s p a r e n t e . E n u n c i a d o de m a n e r a simple, u n a c a j a t r a n s p a r e n te c o n t i e n e el d i s e ñ o de p r o c e d i m i e n t o p a r a la c a j a de e s t a d o . La figura 29.2 ilustra el e n f o q u e de r e f i n a m i e n t o e m p l e a n d o la e s p e c i f i c a c i ó n de e s t r u c t u r a de c a j a s . U n a c a j a n e g r a (CN,) d e f i n e r e s p u e s t a s p a r a u n c o n j u n t o c o m pleto d e e s t í m u l o s . CN, s e p u e d e r e f i n a r e n u n c o n j u n t o de c a j a s n e g r a s , CN, ., h a s t a

\CLAVE El refinomiento de la e s t r u c t u r o d e c o j o s y la verificación de la corrección ocurren simultáneamente.

CN,

c a d a u n a d e l a s c u a l e s a b o r d a u n a c l a s e d e c o m p o r t a m i e n t o . El r e f i n a m i e n t o

c o n t i n ú a h a s t a q u e s e identifica u n a c l a s e c o h e s i v a d e c o m p o r t a m i e n t o (por e j e m plo, CN,.,.,). E n t o n c e s s e d e f i n e u n a c a j a d e e s t a d o (CE, , , ) p a r a la c a j a n e g r a ( C N , , , ) En e s t e c a s o , CE,.,., c o n t i e n e t o d o s l o s d a t o s y s e r v i c i o s q u e s e r e q u i e r e n p a r a implem e n t a r el c o m p o r t a m i e n t o q u e d e f i n e CN,.,.,. F i n a l m e n t e , CE,.,., s e r e f i n a e n c a j a s t r a n s p a r e n t e s ( C T , y s e e s p e c i f i c a n los d e t a l l e s d e d i s e ñ o del p r o c e d i m i e n t o . C o n f o r m e o c u r r e c a d a u n o d e e s t o s p a s o s d e r e f i n a m i e n t o , t a m b i é n o c u r r e la verificación d e la c o r r e c c i ó n . Las e s p e c i f i c a c i o n e s d e c a j a d e e s t a d o se verifican p a r a

Refinamiento

d e estructura de cajas.

TM

PDF Editor

CAPÍTULO 29

865


Especificación de c a j a negra. f: S* — R

g a r a n t i z a r q u e c a d a u n o c o n c u e r d a c o n el c o m p o r t a m i e n t o d e f i n i d o por la especific a c i ó n p a d r e de c a j a n e g r a . De igual m o d o , las e s p e c i f i c a c i o n e s d e c a j a t r a n s p a r e n t e s e verifican c o n t r a la c a j a d e e s t a d o p a d r e . Se d e b e n o t a r q u e los m é t o d o s d e e s p e c i f i c a c i ó n b a s a d o s e n l e n g u a j e s c o m o OCL o Z (capítulo 28) e s p o s i b l e u s a r l o s e n c o n j u n c i ó n c o n el e n f o q u e d e e s p e c i f i c a c i ó n d e e s t r u c t u r a d e c a j a s . El ú n i c o r e q u i s i t o e s q u e c a d a g r a d o d e e s p e c i f i c a c i ó n s e a verificable f o r m a l m e n t e .

29.2.1 Especificación de c a j a negra Una especificación

de caja negra

describe una abstracción, estímulos y respuesta

m e d i a n t e la n o t a c i ó n m o s t r a d a e n la figura 29.3 [MIL88J. La f u n c i ó n / s e aplica a u n a s u c e s i ó n , S*, d e e n t r a d a s (estímulos), S, y las t r a n s f o r m a e n u n a salida ( r e s p u e s t a ) , R. R e s p e c t o a c o m p o n e n t e s d e s o f t w a r e s i m p l e s / p u e d e ser u n a f u n c i ó n m a t e m á t i c a , p e r o , e n g e n e r a l , / s e d e s c r i b e u s a n d o l e n g u a j e n a t u r a l (o u n l e n g u a j e f o r m a l d e especificación). M u c h o s d e los c o n c e p t o s i n t r o d u c i d o s p a r a los 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 t a m b i é n s o n a p l i c a b l e s r e s p e c t o d e la c a j a n e g r a . Las a b s t r a c c i o n e s d e d a t o s y l a s o p e r a c i o n e s q u e m a n i p u l a n d i c h a s a b s t r a c c i o n e s l a s e n c a p s u l a la c a j a n e g r a . Al igual q u e u n a j erarquí a d e c l a s e , la e s p e c i f i c a c i ó n d e c a j a n e g r a p u e d e exhibir el u s o d e j e r a r q u í a s e n las c u a l e s l a s c a j a s d e nivel inferior h e r e d a n las p r o p i e d a d e s d e c a j a s s u p e r i o r e s e n la e s t r u c t u r a de árbol.

Especificación de caja de estado.

TM

PDF Editor

PARTE CINCO


29.2.2 Especificación de c a j a de estado La caja de estado e s " u n a g e n e r a l i z a c i ó n s i m p l e d e u n a m á q u i n a d e e s t a d o " [MIL88], Si se r e c u e r d a la d e s c r i p c i ó n del m o d e l a d o d e c o m p o r t a m i e n t o y los d i a g r a m a s de e s t a d o del c a p í t u l o 8, u n e s t a d o e s a l g ú n m o d o o b s e r v a b l e d e c o m p o r t a m i e n t o del s i s t e m a . C o n f o r m e o c u r r e n los p r o c e s a m i e n t o s , u n s i s t e m a r e s p o n d e a los e v e n t o s (estímulos) m e d i a n t e la r e a l i z a c i ó n de t r a n s i c i o n e s d e s d e el e s t a d o a c t u a l h a s t a ciert o e s t a d o n u e v o . C o n f o r m e s e realiza la t r a n s i c i ó n e s p o s i b l e q u e o c u r r a u n a a c c i ó n . La c a j a d e e s t a d o utiliza u n a a b s t r a c c i ó n d e d a t o s p a r a d e t e r m i n a r la t r a n s i c i ó n h a c i a el s i g u i e n t e e s t a d o y la a c c i ó n (respuesta) q u e o c u r r i r á c o m o c o n s e c u e n c i a de la t r a n s i c i ó n . S e g ú n s e m u e s t r a e n la figura 29.4, la c a j a d e e s t a d o i n c o r p o r a u n a c a j a n e g r a . El e s t í m u l o , S, q u e i n g r e s a a la c a j a n e g r a llega d e s d e a l g u n a f u e n t e e x t e r n a y u n c o n j u n t o d e e s t a d o s i n t e r n o s del s i s t e m a , T. Mills [MIL88] p r o p o r c i o n a u n a d e s c r i p c i ó n m a t e m á t i c a de la f u n c i ó n , / d e la c a j a n e g r a c o n t e n i d a d e n t r o d e la c a j a d e e s t a d o : g:S*

xT"

->RxT

d o n d e o e s u n a s u b f u n c i ó n l i g a d a a u n e s t a d o específico, f. C u a n d o s e c o n s i d e r a n en c o n j u n t o , los p a r e s d e s u b f u n c i o n e s d e e s t a d o (£, g) d e f i n e n la f u n c i ó n / d e c a j a negra.

29.2.3 Especificación de c a j a transparente La e s p e c i f i c a c i ó n d e c a j a t r a n s p a r e n t e e s t á c e r c a n a m e n t e r e l a c i o n a d a c o n el d i s e ñ o d e p r o c e d i m i e n t o s y la p r o g r a m a c i ó n e s t r u c t u r a d a (capítulo 11). En e s e n c i a , la s u b f u n c i ó n g d e n t r o de la c a j a de e s t a d o se s u s t i t u y e c o n l a s e s t r u c t u r a s d e p r o g r a m a ción e s t r u c t u r a d a q u e i m p l e m e n t a g. c o m o e j e m p l o , c o n s i d é r e s e la c a j a t r a n s p a r e n t e q u e s e m u e s t r a e n la figura 29.5. La c a j a n e g r a , g, de la figura 29.4 s e s u s t i t u y e c o n u n a s u c e s i ó n d e e s t r u c t u r a s q u e i n c o r p o r a u n a c o n d i c i o n a l . Estas e s t r u c t u r a s , a s u v e z , s e r e f i n a n e n c a j a s t r a n s p a r e n t e s d e nivel inferior c o n f o r m e p r o c e d e el r e f i n a m i e n t o e n niveles.

Especificación de caja transparente.

Estado

r~

T

*—i

TM

PDF Editor R

CAPÍTULO 29

867

INGENIERÍA DEL SOFTWARE DE SALA U M P I A

Es i m p o r t a n t e o b s e r v a r q u e p u e d e d e m o s t r a r s e la c o r r e c c i ó n de la e s p e c i f i c a c i ó n d e p r o c e d i m i e n t o d e s c r i t a e n la j e r a r q u í a d e caja t r a n s p a r e n t e . Este t e m a s e c o n s i d e r a e n la s e c c i ó n s i g u i e n t e .

El e n f o q u e d e d i s e ñ o u t i l i z a d o e n la i n g e n i e r í a del s o f t w a r e d e s a l a limpia utiliza c o n a m p l i t u d la filosofía d e p r o g r a m a c i ó n e s t r u c t u r a d a . Pero, e n e s t e c a s o , la p r o g r a m a ción e s t r u c t u r a d a s e aplica m u c h o m á s r i g u r o s a m e n t e . Las f u n c i o n e s d e p r o c e s a m i e n t o b á s i c o ( d e s c r i t a s d u r a n t e las p r i m e r a s e t a p a s del r e f i n a m i e n t o d e la e s p e c i f i c a c i ó n ) s e r e f i n a n u t i l i z a n d o u n a " e x p a n s i ó n p r o g r e s i v a d e f u n c i o n e s m a t e m á t i c a s e n e s t r u c t u r a s d e c o n e c t i v o s l ó g i c o s [por e j e m p l o , if-then else] y s u b f u n c i o n e s , d o n d e la e x p a n s i ó n [se] r e a l i z a h a s t a q u e t o d a s l a s s u b f u n c i o n e s i d e n t i f i c a d a s p u e d a n e s t a b l e c e r s e d i r e c t a m e n t e e n el l e n g u a j e d e p r o g r a m a c i ó n u s a d o p a r a la i m p l e m e n t a c i ó n " [DYE92] El e n f o q u e d e p r o g r a m a c i ó n e s t r u c t u r a d a se e m p l e a c o n eficacia p a r a r e f i n a r la f u n c i ó n , ¿ p e r o q u é h a y a c e r c a d e l d i s e ñ o ? Aquí s e i n v o l u c r a n v a r i o s c o n c e p t o s f u n d a m e n t a l e s d e d i s e ñ o (capítulos 5 y 9). Los d a t o s d e p r o g r a m a s e e n c a p s u l a n c o m o u n c o n j u n t o d e a b s t r a c c i o n e s q u e a t i e n d e n las s u b f u n c i o n e s . Los c o n c e p t o s d e e n c a p s u l a d o d e d a t o s , o c u l t a m i e n t o d e i n f o r m a c i ó n y clasificación d e d a t o s se a p r o v e c h a n p a r a c r e a r el d i s e ñ o de d a t o s .

29.3.1 Refinamiento y verificación del diseño C a d a e s p e c i f i c a c i ó n d e c a j a t r a n s p a r e n t e r e p r e s e n t a el d i s e ñ o d e u n p r o c e d i m i e n t o ( s u b f u n c i ó n ) n e c e s a r i o p a r a lograr u n a t r a n s i c i ó n d e c a j a d e e s t a d o . Con la c a j a t r a n s p a r e n t e l a s e s t r u c t u r a s d e p r o g r a m a c i ó n e s t r u c t u r a d a y el r e f i n a m i e n t o p r o g r e sivo s e utilizan c o m o s e ilustra e n la figura 29.6. Una f u n c i ó n de p r o g r a m a , / s e refin a e n u n a s u c e s i ó n de s u b f u n c i o n e s g y h. Éstas, a s u v e z , s e r e f i n a n e n e s t r u c t u r a s c o n d i c i o n a l e s {if-then-else A

¿Qué condiciones son aplicables para probar que son adecuadas las estructuras estructuradas?

y do-while).

El r e f i n a m i e n t o a d i c i o n a l ilustra la c o n t i n u a -

ción del r e f i n a m i e n t o lógico. En c a d a nivel d e r e f i n a m i e n t o el e q u i p o d e s a l a limpia 2 r e a l i z a u n a verificación f o r m a l d e c o r r e c c i ó n . E s t o s e logra a n e x a n d o u n c o n j u n t o d e c o n d i c i o n e s d e c o r r e c ción g e n é r i c a s a las e s t r u c t u r a s de p r o g r a m a c i ó n e s t r u c t u r a d a . Si u n a f u n c i ó n / s e e x p a n d e e n u n a s u c e s i ó n g y h, la c o n d i c i ó n de c o r r e c c i ó n p a r a c u a l q u i e r e n t r a d a a fes

TM • ¿g s e g u i d a d e h h a c e / ?

C u a n d o u n a f u n c i ó n p se r e f i n a e n u n c o n d i c i o n a l d e la f o r m a if < c > t h e n q, e l s e r

PDF Editor

(si < c > e n t o n c e s q, d e o t r o m o d o r), la c o n d i c i ó n d e c o r r e c c i ó n p a r a c u a l q u i e r e n t r a -

da a p es 2

Puesto que el equipo completo está involucrado en e! proceso de verificación, es menos probable

que se cometa un error al realizar la verificación

868

PARTE CINCO


Refinamiento progresivo.

^CONSEJÓ^

• ¿ S i e m p r e q u e la c o n d i c i ó n < c > e s v e r d a d e r a , q h a c e p; y s i e m p r e q u e < c > e s f a l s a , r h a c e p?

Si el lector se limita C u a n d o la f u n c i ó n m s e r e f i n a c o m o u n b u c l e l a s c o n d i c i o n e s d e c o r r e c c i ó n p a r a sólo a los estructuras cualquier entrada a m son estructurados conforme desarrollo • ¿La t e r m i n a c i ó n e s t á g a r a n t i z a d a ? un diseño de procedi• ¿ S i e m p r e q u e e s v e r d a d e r a , n s e g u i d a d e m h a c e m; y s i e m p r e q u e < c > miento, lo prueba de corrección es directa. e s falsa, s o s l a y a r el bucle t o d a v í a h a c e m ? Sise violan las estructuras las pruebas de C a d a v e z q u e u n a c a j a t r a n s p a r e n t e s e r e f i n a al s i g u i e n t e nivel d e detalle s e a p l i c a n TM corrección son i dichas condiciones d e corrección. o imposibles. Es i m p o r t a n t e s e ñ a l a r q u e la utilización d e e s t r u c t u r a s d e p r o g r a m a c i ó n e s t r u c t u r a d a r e s t r i n g e el n ú m e r o d e p r u e b a s d e c o r r e c c i ó n q u e s e d e b e n realizar. U n a s o l a

PDF Editor

c o n d i c i ó n s e verifica p a r a las s u c e s i o n e s ; d o s c o n d i c i o n e s se p r u e b a n p a r a if-then-

else; y t r e s c o n d i c i o n e s s e verifican p a r a los b u c l e s .

La verificación d e c o r r e c c i ó n d e u n d i s e ñ o d e p r o c e d i m i e n t o s e ilustra e m p l e a n -

d o u n e j e m p l o s i m p l e q u e i n t r o d u j e r o n Linger, Mills y Witt [LIN79]. El o b j e t i v o e s d i s e ñ a r y verificar u n p e q u e ñ o p r o g r a m a q u e e n c u e n t r a la p a r t e e n t e r a , y, d e u n a

raíz c u a d r a d a de un e n t e r o d a d o , x. El d i s e ñ o d e p r o c e d i m i e n t o se r e p r e s e n t a en la figura 29.7 e m p l e a n d o el d i a g r a m a de flujo. Verificar la corrección d e e s t e d i s e ñ o requiere definir las c o n d i c i o n e s de e n t r a d a y salida c o m o s e indica en la figura 29.8. La condición d e e n t r a d a advierte q u e x d e b e ser mayor q u e o igual a 0. La condición d e salida requiere q u e x p e r m a n e z c a inalterada y q u e y satisfaga la expresión indicada e n la figura. Probar la corrección del d i s e ñ o requiere c o m p r o b a r que, en t o d o s los c a s o s , s o n v e r d a d e r a s las c o n d i c i o n e s inicio, bucle, cuenta, sí y salida q u e s e m u e s t r a n e n la figura 29.8. En o c a s i o n e s , a é s t a s s e les llama subpruebas•. 1. La condición inicio d e m a n d a q u e | x > 0 e y = 01. Con base en los requisitos del problema s e s u p o n e q u e la condición d e e n t r a d a e s correcta. 3 En c o n s e c u e n c i a ,

\ CLAVE

s e satisface la primera p a r t e de la condición inicio, x a 0. Según el d i a g r a m a d e flujo, el e n u n c i a d o q u e p r e c e d e i n m e d i a t a m e n t e a la condición inicio e s t a b l e c e

Probar que un diseño es correcto requiere, primero, identificar todos los condiciones y luego probor que cada una toma el volor booleano adecuado. A estas condiciones se les llama subpruebas.

y = 0. Por lo tanto, la s e g u n d a parte de la condición inicio t a m b i é n s e satisface. En c o n s e c u e n c i a , inicio e s v e r d a d e r a . 2.

TM 1) direcLa condición bucle s e p u e d e e n c o n t r a r en u n a d e d o s f o r m a s posibles: t a m e n t e a partir d e inicio (en este c a s o , la condición bucle s e satisface directamente) o por m e d i o del flujo d e control q u e p a s a a través d e la condición

PDF Editor

c u e n t a . D a d o q u e la condición c u e n t a e s idéntica a la condición bucle, bucle e s v e r d a d e r a sin importar la trayectoria d e flujo q u e c o n d u c e a ella.

3

En este contexto, un valor negativo para .a r a u cuadrada no tiene significado.

870

PARTE CINCO


se r

Prueba de q u e el diseño es c o n e c t o . Diseño c o n subpruebas.

cuenta: [y2 < x]

L

salida: x no c a m b i a y y2 < x <, (y + 1 ) 2

3.

La c o n d i c i ó n c u e n t a s e e n c u e n t r a s ó l o d e s p u é s d e q u e el v a l o r d e y a u m e n t a e n 1. A d e m á s , la t r a y e c t o r i a del flujo d e control q u e c o n d u c e a c u e n t a s e p u e d e inv o c a r s ó l o si la c o n d i c i ó n sí t a m b i é n e s v e r d a d e r a . Por lo t a n t o , si (y + l) 2 s x , se s i g u e q u e y 2 s x . L a c o n d i c i ó n c u e n t a s e s a t i s f a c e .

4.

La c o n d i c i ó n sí se p r u e b a e n la lógica c o n d i c i o n a l m o s t r a d a . Por lo t a n t o , la c o n d i c i ó n sí d e b e s e r v e r d a d e r a c u a n d o el flujo d e c o n t r o l s e m u e v e a lo largo d e la t r a y e c t o r i a m o s t r a d a .

5.

La c o n d i c i ó n salida d e m a n d a p r i m e r o q u e x n o h a y a c a m b i a d o . Un e x a m e n del d i s e ñ o indica q u e x n o a p a r e c e e n n i n g ú n sitio a la i z q u i e r d a d e un o p e r a d o r de a s i g n a c i ó n . No e x i s t e l l a m a d o d e f u n c i ó n q u e u s e x. Por lo t a n t o , n o c a m b i a . D a d o q u e la p r u e b a c o n d i c i o n a l (y + l ) 2 < x d e b e fallar p a r a a l c a n z a r la c o n d i ción salida, s e s i g u e q u e (y + l) 2 :< x. A d e m á s , la c o n d i c i ó n bucle t o d a v í a d e b e ser v e r d a d e r a (es decir,y 2 =s x). En c o n s e c u e n c i a , se p u e d e n c o m b i n a r (y + l) 2 > x y y 2 £ x p a r a s a t i s f a c e r la c o n d i c i ó n salida.

A d e m á s s e d e b e g a r a n t i z a r q u e el b u c l e t e r m i n a . Un e x a m e n de TM la c o n d i c i ó n bucle i n d i c a q u e , p u e s t o q u e y a u m e n t a y x > 0, el b u c l e a la larga d e b e t e r m i n a r . Los c i n c o p a s o s a p e n a s a n o t a d o s p r u e b a n la c o r r e c c i ó n del d i s e ñ o del a l g o r i t m o

PDF Editor

i n d i c a d o e n la figura 29.7. Ahora s e t i e n e c e r t e z a d e q u e el d i s e ñ o , de h e c h o , c a l c u lará la p a r t e e n t e r a d e u n a raíz c u a d r a d a .

Es p o s i b l e e m p l e a r u n e n f o q u e m a t e m á t i c o m á s r i g u r o s o e n el d i s e ñ o d e la veri-

ficación. Sin e m b a r g o , u n a exposición d e e s t e t e m a r e b a s a el á m b i t o d e e s t e libro. Los l e c t o r e s i n t e r e s a d o s p u e d e n c o n s u l t a r [LIN79J.

CAPITULO 29 4 j | ¿Qué s e w gana al real z a r pruebas de corrección?

871


29.3.2 Ventajas de la verificación del diseño 4 La v e r i f i c a c i ó n r i g u r o s a d e la c o r r e c c i ó n d e c a d a r e f i n a m i e n t o del d i s e ñ o de la c a j a t r a n s p a r e n t e tiene v a r i a s v e n t a j a s . Linger [LIN94] l a s d e s c r i b e de la s i g u i e n t e f o r m a : • R e d u c e n la verificación a un p r o c e s o finito. La m a n e r a s e c u e n c i a l y a n i d a d a e n q u e s e o r g a n i z a n las e s t r u c t u r a s d e control e n u n a c a j a t r a n s p a r e n t e d e f i n e c o n n a t u r a l i d a d u n a j e r a r q u í a q u e r e v e l a l a s c o n d i c i o n e s de c o r r e c c i ó n q u e s e d e b e n verificar. Un " a x i o m a d e r e e m p l a z o " [LIN79] p e r m i t e sustituir las f u n c i o n e s p r o y e c t a d a s c o n s u s r e f i n a m i e n t o s d e e s t r u c t u r a d e control e n la j e r a r q u í a de l a s s u b p r u e b a s . Por e j e m p l o , la s u b p r u e b a d e la f u n c i ó n p r o y e c t a d a fl de la figura 2 9 . 9 r e q u i e r e p r o b a r q u e la c o m p o s i c i ó n d e las o p e r a c i o n e s g l y g2 c o n la f u n c i ó n p r o y e c t a d a f2 t i e n e el m i s m o e f e c t o s o b r e l o s d a t o s q u e f l . N ó t e s e q u e f2 s u s t i t u y e t o d o s l o s d e t a l l e s d e s u r e f i n a m i e n t o e n la p r u e b a . Esta s u s t i t u c i ó n localiza el a r g u m e n t o d e p r u e b a c o n la e s t r u c t u r a d e control q u e s e e s t a e s t u d i a n d o . D e h e c h o , d e j a q u e el i n g e n i e r o de s o f t w a r e lleve a c a b o las p r u e b a s e n c u a l q u i e r o r d e n . • E s imposible s o b r e e s t i m a r el e f e c t o positivo q u e la r e d u c c i ó n d e la verificación a u n p r o c e s o finito t i e n e s o b r e la calidad. Aun c u a n d o t o d o s los p r o g r a m a s , e x c e p t o los m á s t r i v i a l e s , m u e s t r e n u n n ú m e r o e s e n c i a l m e n t e infinito d e t r a y e c t o r i a s d e e j e c u c i ó n , p u e d e n verificarse e n u n n ú m e r o finito d e p a s o s .

Diseño c o n subpruebas.

Subpruebas: [fl] DO gl g2 [f2] WHILE P' DO [f3] 83 [«] IF p2 THEN [f5] g5 EL8E [f6] ge

fl = [DO gl: g 2 : [f2] END] ?

f 2 = [WHILE pl DO [f3] END] ?

f 3 = [DO g3: [M]: g 8 END] ? f 4 = [IF p2; THEN [f5] EL8E [f6] END] 7

f S = [DO g4: g 5 END] 7

TM f 6 = [DO g6: g7 END] 7

PDF Editor 67

END g8 END END

4 Esta sección y las figuras 29.7 a 29.9 har. sido adaptadas de [LIN94] y se usaron con permiso.

872

PARTE CINCO • Permiten

CLAVE A pesar del número extremadamente grande de trayectorias de ejecución en un programa, el número de pasos para probar que el programa es correcto es bastante pequeño.


al equipo de sala limpia verificar cada línea de diseño y código. Los

e q u i p o s p u e d e n r e a l i z a r la verificación p o r m e d i o del a n á l i s i s y la d i s c u s i ó n e n g r u p o s o b r e la b a s e del t e o r e m a d e c o r r e c c i ó n , y s o n c a p a c e s d e p r o d u c i r p r u e b a s escritas d o n d e se requiere u n a confianza adicional e n u n sistema crucial p a r a la vida o la m i s i ó n . • Resultan

en un nivel de defecto cercano a cero. D u r a n t e u n a revisión d e e q u i p o

s e verifica por t u r n o s la c o n d i c i ó n d e c o r r e c c i ó n d e c a d a e s t r u c t u r a d e c o n t r o l . C a d a m i e m b r o del e q u i p o d e b e e s t a r d e a c u e r d o e n q u e c a d a c o n d i c i ó n e s c o r r e c t a , de m o d o q u e u n e r r o r s ó l o e s p o s i b l e si c a d a m i e m b r o del e q u i p o verifica d e m a n e r a i n c o r r e c t a u n a c o n d i c i ó n . El r e q u i s i t o del a c u e r d o u n á n i m e b a s a d o e n la verificación individual g e n e r a u n s o f t w a r e c o n pocos o ningún defecto a n t e s de su primera ejecución. • Es escaíable.

C u a l q u i e r s i s t e m a d e s o f t w a r e , sin i m p o r t a r c u á n g r a n d e s e a ,

tiene p r o c e d i m i e n t o s de c a j a t r a n s p a r e n t e d e nivel s u p e r i o r c o m p u e s t o s d e estructuras de sucesión, alternación e iteración. Cada u n a de ellas u s u a l m e n t e invoca un gran subsistema con miles de líneas de código, y cada u n o de dichos subsistemas tiene sus propios procedimientos y funciones proyectadas d e nivel s u p e r i o r . D e m o d o q u e l a s c o n d i c i o n e s d e c o r r e c c i ó n p a r a t a l e s e s t r u c t u r a s d e nivel s u p e r i o r s e verifican e n la m i s m a f o r m a q u e las e s t r u c t u r a s d e nivel inferior. La verificación e n n i v e l e s s u p e r i o r e s p u e d e t o m a r , y v a l e la p e n a , m á s t i e m p o , p e r o n o r e q u i e r e m á s t e o r í a . • Produce mejor código que la prueba

unitaria. La p r u e b a u n i t a r i a verifica l o s

efectos d e ejecutar sólo las trayectorias de prueba seleccionadas entre m u c h a s t r a y e c t o r i a s p o s i b l e s . Al b a s a r la verificación e n la teoría d e f u n c i o n e s , el e n f o q u e d e s a l a limpia p u e d e verificar c u a l q u i e r e f e c t o p o s i b l e s o b r e t o d o s los d a t o s p o r q u e , m i e n t r a s u n p r o g r a m a p u e d e t e n e r m u c h a s t r a y e c t o r i a s d e e j e c u c i ó n , s ó l o t i e n e u n a f u n c i ó n . La verificación t a m b i é n e s m á s e f i c i e n t e q u e la p r u e b a u n i t a r i a . La m a y o r í a d e l a s c o n d i c i o n e s d e verificación se puede comprobar e n u n o s c u a n t o s minutos, pero las pruebas u n i t a r i a s r e q u i e r e n un t i e m p o s u s t a n c i a l e n s u p r e p a r a c i ó n , e j e c u c i ó n y comprobación. Es i m p o r t a n t e a d v e r t i r q u e la verificación del d i s e ñ o d e b e , a final d e c u e n t a s , aplic a r s e al p r o p i o c ó d i g o f u e n t e . En e s t e c o n t e x t o , c o n f r e c u e n c i a s e le llama verificación de ¡a corrección.

TM

PDF Editor

La e s t r a t e g i a y las t á c t i c a s d e l a s p r u e b a s d e s a l a limpia s o n f u n d a m e n t a l m e n t e dife-

r e n t e s d e los e n f o q u e s d e p r u e b a c o n v e n c i o n a l e s . Los m é t o d o s c o n v e n c i o n a l e s g e n e r a n u n c o n j u n t o d e c a s o s d e p r u e b a p a r a d e s c u b r i r e r r o r e s d e d i s e ñ o y codific a c i ó n . La m e t a d e l a s p r u e b a s d e s a l a limpia e s validar los r e q u i s i t o s d e s o f t w a r e

CAPÍTULO 29

873

INGENIERÍA DEL SOFTWARE DE S A LA U M P I A

d e m o s t r a n d o q u e u n a m u e s t r a e s t a d í s t i c a d e c a s o s d e u s o (capítulo 7) s e ha e j e c u tado exitosamente. ""T— — "lo calidad no es un acto; es un hábito."

29.4.1 Pruebas estadísticas de uso El u s u a r i o d e u n p r o g r a m a d e c o m p u t a d o r a r a r a v e z n e c e s i t a e n t e n d e r los d e t a l l e s t é c n i c o s del d i s e ñ o . El c o m p o r t a m i e n t o del p r o g r a m a q u e ve el u s u a r i o lo a l i m e n t a n e n t r a d a s y e v e n t o s q u e c o n f r e c u e n c i a él m i s m o p r o d u c e . Pero, e n l o s s i s t e m a s c o m plejos, el p o s i b l e e s p e c t r o d e e n t r a d a s y e v e n t o s (es decir, los c a s o s d e uso) tal v e z s e a e x t r e m a d a m e n t e a m p l i o . ¿ Q u é s u b c o n j u n t o d e c a s o s d e u s o verificará a d e c u a d a m e n t e el c o m p o r t a m i e n t o del p r o g r a m a ? Esta e s la p r i m e r a p r e g u n t a q u e a b o r d a la p r u e b a e s t a d í s t i c a d e u s o . La p r u e b a e s t a d í s t i c a d e u s o " e q u i v a l e a p r o b a r el s o f t w a r e e n la f o r m a q u e los ^CONSIJO^

u s u a r i o s i n t e n t a r í a n u s a r l o " [LIN94], Esto s e logra si los e q u i p o s d e p r u e b a d e sala

limpia ( t a m b i é n l l a m a d o s equipos de certificación) d e t e r m i n a n u n a distribución d e incluso si no se es xrtidorio del enfoque p r o b a b i l i d a d d e u s o p a r a el s o f t w a r e . La e s p e c i f i c a c i ó n (caja negra) d e c a d a increde salo limpio, válelo m e n t o del s o f t w a r e s e a n a l i z a p a r a definir u n c o n j u n t o de e s t í m u l o s ( e n t r a d a s o xna considerar las e v e n t o s ) q u e p r o v o c a n el c a m b i o d e c o m p o r t a m i e n t o del s o f t w a r e . Con b a s e e n yuebas estadísticas de utilización como e n t r e v i s t a s c o n u s u a r i o s p o t e n c i a l e s , la c r e a c i ó n d e e s c e n a r i o s de u s o y u n a c o m p r e n s i ó n g e n e r a l del d o m i n i o d e la a p l i c a c i ó n , s e a s i g n a u n a p r o b a b i l i d a d de u s o a xrte integral de su estrategia de pruebas.c a d a e s t í m u l o . Los c a s o s d e p r u e b a se g e n e r a n p a r a c a d a c o n j u n t o d e e s t í m u l o s 5 d e a c u e r d o c o n la distribución d e p r o b a b i l i d a d d e u s o . Con f i n e s ilustrativos, c o n s i d é r e s e el s i s t e m a HogarSeguro

e s t u d i a d o p r e v i a m e n t e e n e s t e libro. La ingeniería del s o f t w a r e de s a l a

limpia s e aplica e n el d e s a r r o l l o d e u n i n c r e m e n t o d e s o f t w a r e q u e g e s t i o n a la inter a c c i ó n del u s u a r i o c o n el t e c l a d o n u m é r i c o del s i s t e m a d e s e g u r i d a d . R e s p e c t o de e s t e i n c r e m e n t o s e h a n i d e n t i f i c a d o c i n c o e s t í m u l o s . El a n á l i s i s indica el p o r c e n t a j e d e distribución d e p r o b a b i l i d a d d e c a d a e s t í m u l o . Con el fin simplificar la s e l e c c i ó n de los c a s o s d e p r u e b a d i c h a s p r o b a b i l i d a d e s e s t á n s e c o r r e l a c i o n a n c o n los interv a l o s n u m e r a d o s e n t r e 1 y 9 9 [LIN94] y s e ilustran e n la t a b l a siguiente: Estímulo del programa

Probabilidad

Intervalo

Habilitar/deshabilitar (HD)

50%

1-49

Fijar zona |FZ]

15%

5063

Consulla (C)

15%

64-78

TM

PDF Editor Prueba (P)

15%

79-94

Alarma(A)

5%

95-99

5

Es posible utilizar herramientas a u t o m a t i z a d a s para lograr esto. Véase [DYE92]para mayor infor-

mación.

874

PARTE CINCO


Crear u n a sucesión de c a s o s de prueba de uso que concuerde con la distribución de probabilidad de uso requiere g e n e r a r n ú m e r o s aleatorios entre 1 y 99. Cada n ú m e r o aleatorio corresponde a un intervalo en la distribución d e probabilidad precedente. Por lo tanto, la secuencia de c a s o s de prueba de u s o se define aleatoriamente, pero corresponde a la probabilidad correspondiente de presencia de estímulos Por ejemplo, s u p ó n g a s e que se g e n e r a n las siguientes s e c u e n c i a s d e n ú m e r o s aleatorios: 13-94-22-24-45-56 81-19-31-69-45-9 38-21-52-84-86-4 Al seleccionar los estímulos apropiados con b a s e en el intervalo de distribución que se muestra en la tabla se derivan los c a s o s de uso siguientes: HD-P-HD-HD-HD-FZ P-HD-HD-C-HD-HD HD-HD-FZ-P-P-HD El equipo de prueba ejecuta estos c a s o s de u s o y verifica el c o m p o r t a m i e n t o del softw a r e frente a la especificación del sistema. El tiempo para las p r u e b a s se registra de m o d o que sea posible determinar los tiempos de intervalo. Al usar tiempos de intervalo, el equipo de certificación tiene la posibilidad de calcular el tiempo medio entre fallas (TMEF). Si se lleva a c a b o una larga secuencia de p r u e b a s sin fallas, el TMEF es b a j o y e s probable que la fiabilidad del s o f t w a r e s e a alta.

29.4.2 Certificación Las técnicas de verificación y prueba ya descritas e n este capítulo llevan a c o m p o n e n t e s de software (e i n c r e m e n t o s completos) que pueden certificarse. En el contexto del enfoque de ingeniería del s o f t w a r e de sala limpia la certificación implica que la fiabilidad (medida en TMEF) se especifica para cada c o m p o n e n t e . El impacto potencial de los c o m p o n e n t e s de s o f t w a r e certificables va m u c h o más allá d e un solo proyecto de sala limpia. Los c o m p o n e n t e s de s o f t w a r e reutilizables se pueden a l m a c e n a r j u n t o con s u s e s c e n a r i o s de uso, estímulos d e p r o g r a m a y distribuciones de probabilidad. Cada c o m p o n e n t e tendría u n a fiabilidad certificada en el escenario de uso y el régimen de p r u e b a s descritos. Esta información es invaluable para o t r o s que intenten emplear los c o m p o n e n t e s . TM El e n f o q u e de la certificación involucra cinco p a s o s [WOH94): 1. Creación de e s c e n a r i o s de uso.

PDF Editor 2. Especificación de perfiles de uso.

¿Cómo se certifico un conponente de software?

•

3 . Generación de c a s o s de prueba a partir del perfil.

4 . Ejecución de p r u e b a s y registro y análisis de d a t o s de fallas. 5 . Cálculo y certificación de la fiabilidad.

CAPÍTULO 29

INGENIERÍA DEL SOFTWARE CE SALA LIMPIA

875

Los p a s o s del l al 4 s e h a n t r a t a d o e n u n a s e c c i ó n a n t e r i o r . Esta s e c c i ó n s e c o n c e n t r a r á e n la certificación d e la fiabilidad. La certificación p a r a la i n g e n i e r í a del s o f t w a r e d e s a l a limpia r e q u i e r e la c r e a c i ó n de tres modelos [P0093]: M o d e l o d e m u e s t r e o . La p r u e b a del s o f t w a r e e j e c u t a m c a s o s d e p r u e b a a l e a t o r i o s y s e certifica si n o o c u r r e n f a l l a s o u n n ú m e r o e s p e c í f i c o de é s t a s . El valor d e m s e deriva m a t e m á t i c a m e n t e p a r a a s e g u r a r q u e se logra la fiabilidad r e q u e r i d a . M o d e l o d e c o m p o n e n t e s . Se c e r t i f i c a r á u n s i s t e m a c o m p u e s t o d e n c o m p o n e n t e s . El m o d e l o d e c o m p o n e n t e s p e r m i t e q u e el a n a l i s t a d e t e r m i n e la p r o b a b i l i d a d d e q u e el c o m p o n e n t e i fallará a n t e s d e c o m p l e t a r s e . M o d e l o d e c e r t i f i c a c i ó n . La fiabilidad global del s i s t e m a s e p r o y e c t a y certifica. En el m o m e n t o d e c o m p l e t a r l a s p r u e b a s e s t a d í s t i c a s d e u s o el e q u i p o d e certific a c i ó n t i e n e la i n f o r m a c i ó n n e c e s a r i a p a r a e n t r e g a r el s o f t w a r e q u e tiene u n TMEF certificado, el c u a l s e c a l c u l a e m p l e a n d o c a d a u n o d e d i c h o s m o d e l o s . U n a d e s c r i p c i ó n d e t a l l a d a del c á l c u l o d e los m o d e l o s d e m u e s t r e o , c o m p o n e n t e s y certificación e s t á m á s allá del á m b i t o d e e s t e libro. El lector i n t e r e s a d o h a l l a r á d e t a lles a d i c i o n a l e s e n [MUS87], [CUR86] y [POQ93].

La ingeniería del s o f t w a r e d e sala limpia e s un e n f o q u e f o r m a l p a r a el d e s a r r o l l o d e s o f t w a r e q u e p u e d e llevar a s o f t w a r e c o n calidad n o t a b l e m e n t e alta. Utiliza la e s p e cificación d e e s t r u c t u r a de c a j a s (o m é t o d o s f o r m a l e s ) p a r a el m o d e l a d o d e a n á l i s i s y d i s e ñ o y r e s a l t a la verificación d e la c o r r e c c i ó n , e n l u g a r d e las p r u e b a s , c o m o el principal m e c a n i s m o p a r a d e t e c t a r y e l i m i n a r l o s e r r o r e s . Se a p l i c a n p r u e b a s e s t a d í s t i c a s d e utilización p a r a d e s a r r o l l a r la i n f o r m a c i ó n n e c e s a r i a de t a s a d e fallas c o n q u e certificar la fiabilidad del s o f t w a r e e n t r e g a d o . El e n f o q u e d e s a l a limpia c o m i e n z a c o n los m o d e l o s d e a n á l i s i s y d i s e ñ o q u e utilizan u n a r e p r e s e n t a c i ó n e n e s t r u c t u r a d e c a j a s . Una " c a j a " e n c a p s u l a el s i s t e m a (o a l g ú n a s p e c t o d e él) e n un g r a d o e s p e c í f i c o d e a b s t r a c c i ó n . Las c a j a s n e g r a s s e a p r o v e c h a n p a r a r e p r e s e n t a r el c o m p o r t a m i e n t o d e u n s i s t e m a o b s e r v a b l e d e m a n e r a e x t e r n a . Las c a j a s d e e s t a d o e n c a p s u l a n d a t o s y o p e r a c i o n e s d e e s t a d o . U n a c a j a t r a n s p a r e n t e s e e m p l e a e n el m o d e l a d o del d i s e ñ o d e p r o c e d i m i e n t o q u TM e implican los d a t o s y o p e r a c i o n e s de u n a c a j a de e s t a d o . La verificación de la c o r r e c c i ó n s e a p l i c a c u a n d o s e c o m p l e t a el d i s e ñ o d e la

PDF Editor

e s t r u c t u r a d e c a j a s . El d i s e ñ o d e p r o c e d i m i e n t o p a r a un c o m p o n e n t e d e s o f t w a r e s e divide e n u n a s e r i e d e s u b f u n c i o n e s . La p r u e b a d e la c o r r e c c i ó n d e l a s s u b f u n c i o n e s r e q u i e r e definir c o n d i c i o n e s d e salida p a r a c a d a s u b f u n c i ó n y s e a p l i c a u n c o n j u n t o de s u b p r u e b a s . Si c a d a c o n d i c i ó n d e salida s e s a t i s f a c e el d i s e ñ o d e b e s e r c o r r e c t o .

876

PARTE CINCO


U n a v e z c o m p l e t a d a la v e r i f i c a c i ó n d e la c o r r e c c i ó n c o m i e n z a la p r u e b a e s t a d í s t i c a d e u s o . A d i f e r e n c i a d é l a s p r u e b a s c o n v e n c i o n a l e s , la i n g e n i e r í a d e l s o f t w a r e d e s a l a l i m p i a n o s u b r a y a la i m p o r t a n c i a d e l a s p r u e b a s u n i t a r i a s o d e i n t e g r a c i ó n . En vez d e ello el s o f t w a r e s e p r u e b a d e f i n i e n d o u n c o n j u n t o d e e s c e n a r i o s d e uso. d e t e r m i n a n d o la p r o b a b i l i d a d d e u s o p a r a c a d a e s c e n a r i o y d e f i n i e n d o e n t o n c e s las p r u e b a s aleatorias q u e c o n c u e r d e n c o n las probabilidades. Los registros d e error resultantes s e c o m b i n a n con los m o d e l o s d e m u e s t r e o , c o m p o n e n t e s y certificación p a r a p e r m i t i r e l c á l c u l o m a t e m á t i c o d e la f i a b i l i d a d p r o y e c t a d a r e s p e c t o al c o m p o nente de software. La filosofía d e s a l a l i m p i a e s u n e n f o q u e r i g u r o s o p a r a la i n g e n i e r í a d e l s o f t w a r e . Es u n m o d e l o d e p r o c e s o d e s o f t w a r e q u e d e s t a c a la v e r i f i c a c i ó n m a t e m á t i c a d e la c o r r e c c i ó n y la c e r t i f i c a c i ó n d e l a f i a b i l i d a d del s o f t w a r e . La l í n e a f u n d a m e n t a l e s las t a s a s d e falla e x t r e m a d a m e n t e b a j a s q u e s e r í a n d i f í c i l e s o i m p o s i b l e s d e l o g r a r empleando métodos m e n o s formales.

[CUR86] Currit, P. A., M. Dyer y H. D. Mills, "Certifying the Reliability of Software", en IEEE Trans Software Engineering, vol. SE-12, n ú m . 1, enero d e 1994. [DYE92] Dyer, M„ The Cleanroom Approach to Quality Software Development, Wiley, 1992. [HAU94] Hausler, P. A., R. L i n g e r y C . Trammel, "Adopting Cleanroom Software Engineering with a Phased Approach", en IBM Systems Journal, vol. 33, núm 1, enero d e 1994, pp. 89-109. [HEN95] Henderson, J„ "Why isn't Cleanroom the Universal Software Development Methodology", en Crosstalk, vol. 8, núm. 5, mayo d e 1995, pp. 11-14. IHEV93] Hevner, A. R., y H. D. Mills, "Box Structure Methods for System Development with Objects", en IBM Systems Journal, vol. 31, n ú m . 2, febrero d e 1993, pp. 232-251. [LIN79] Linger, R. M., H. D. Mills y B. I. Witt, Structured Programming: Theoiy and Practice, Addison-wesley, 1979. ILIN881 Linger, R. M., y H. D. Mills, "A Case Study in Cleanroom Software Engineering: The IBM COBOL Structuring Facility", Proc. COMPSAC '88, Chicago, octubre de 1988. [L1N94] Linger, R., "Cleanroom Process Model", en IEEE Software, vol. 11, núm. 2, m a r z o d e 1994. pp. 50-58. [MIL87I Mills, H. D„ M. Dyer y R. Linger, "Cleanroom Software Engineering", en IEEE Software, vol. 4, núm. 5, septiembre d e 1987, pp. 19-24. [MIL88] Mills, H. D., "Stepwise Refinement and Veriflcation in Box Structured Systems", en Com puter, vol. 21, núm. 6, junio d e 1988, pp. 23-35. IMUS87] Musa,). D , A lannino y K. Okumoto, Engineering and Managing Software with Reliability Measures, McGraw-Hill, 1987. [ P 0 0 8 8 | Poore, J. H., y H. D. Mills, "Bringing Software Under Statistical Quality Control", en Qua tity Progress, noviembre d e 1988, pp. 52-55. [P00931 Poore, J. H., H. D. Mills y D. Mutchler, "Planning and Certifying Software System ReliaTM bility, en IEEE Software, vol. 10, n ú m . 1, e n e r o de 1993, pp. 88-99. [WOH94] Wohiin, C., y P. Runeson, "Certification of Software Components", en IEEE Trans. Soft ware Engineering, vol. SE-20, n ú m . 6, junio de 1994, pp. 494-499.

PDF Editor

2 9 . 1 . Si se tuviese que elegir un a s p e c t o d e la ingeniería del s o f t w a r e d e sala limpia que la hiciese radicalmente diferente de los e n f o q u e s convencionales d e ingeniería d e software, ¿cuál sería?

CAPÍTULO 2 9

877


29.2. ¿Cómo trabajan en conjunto un modelo d e proceso incremental y la certificación para producir software d e alta calidad? 2 9 . 3 . Empleando la especificación d e estructura d e cajas desarróllense m o d e l o s de análisis "de primer paso" y d e diseño para el sistema HogarSeguro. 2 9 . 4 . Desarróllese u n a especificación de estructura d e c a j a s p a r a u n a porción del sistema PHTRS p r e s e n t a d o en el problema 8.10. 29.5. Un algoritmo d e o r d e n a m i e n t o en burbuja se define del m o d o siguiente: procedure bubblesort; v a r i, t, i n t e g e r ; begin r e p e a t until t = a [ 1 ] t: = a[ I ]: f o r j: = 2 t o n d o if a [ j - l j > a | j ] t h e n b e g i n t: = a [ j - l ] ; a O - l ] : = a[j];

«DI: = 'i end endrep end Divídase el diseño en s u b f u n c i o n e s y defínase un c o n j u n t o d e condiciones que permitirían probar que e s t e algoritmo es correcto. 2 9 . 6 . Documéntese u n a prueba de verificación de corrección para el o r d e n a m i e n t o en burbuja tratado en el problema 29.5. 2 9 . 7 . Selecciónese un c o m p o n e n t e de programa q u e se haya diseñado en otro contexto (o u n o q u e haya asignado el instructor) y desarróllese respecto d e él u n a prueba completa de corrección. 2 9 . 8 . Selecciónese un programa que se u s e regularmente (por ejemplo, un gestor de correo electrónico, un procesador d e palabra, un programa de hojas d e cálculo) y créese un conjunto d e escenarios de u s o para el programa. Defínase la probabilidad de uso para cada escenario y luego desarróllese una tabla d e estímulos d e programa y d e distribución de probabilidad similar al que se m u e s t r a en la sección 29.4.1. 2 9 . 9 . Para la tabla d e estímulos d e programa y distribución d e probabilidad desarrollada en el problema 29.8, utilícese un g e n e r a d o r de n ú m e r o s aleatorios con el fin d e desarrollar un conjunto d e c a s o s de prueba p a r a emplearlo en p r u e b a s estadísticas de uso. 2 9 . 1 0 . Con palabras propias, descríbase el intento de certificación en el contexto d e ingeniería del s o f t w a r e d e sala limpia.

TM Prowell eí al. (Clcanroom Software Engineeríng: Technology and Process, Addison-Wesley, 1999) ofrecen un tratamiento detallado d e los aspectos importantes del e n f o q u e de sala limpia. Poore y Trammell (Cleanroom Software Engineeríng: A Reader, Blackwell Publishing, 1996) han editado exposiciones útiles d e t e m a s de sala limpia. B e c k e r y Whittaker (Cleanroom Software Engineeríng Practices, Idea Group Publishing, 1996) presentan un excelente p a n o r a m a p a r a quienes n o e s t á n familiarizados con las prácticas de sala limpia The Cleanroom Pamphlet (Software Technology Support Center, Hill AFBase, abril d e 1995) contiene reimpresiones d e varios artículos importantes Linger 1UN941 produjo una de las mejores introducciones a la materia. El Data and Analysis Center for Software (DACS) (www.dacs.dtic.mil) ofrece m u c h o s artículos útiles, libros guia y : t r a i fuentes de información acerca d e la ingeniería del software d e sala limpia.

PDF Editor

PARTE CINCO


Linger y Trammell ("Cleanroom Software Engineering Reference Model", SEI Technical Report CMU/SE1-96-TR-022, 1996) h a n definido un conjunto de 14 p r o c e s o s d e sala limpia y 20 productos d e trabajo que f o r m a n la b a s e para la SEI CMM d e la ingeniería d e software de sala limpia (CMU/SEI-96-TR-023). Michael Deck de Cleanroom Software Engineering (www.cleansoft.com) ha preparado una bibliografía acerca d e t e m a s de sala limpia. Muchos están disponibles en formato descargable. La verificación del diseño mediante la prueba de las correcciones se encuentra en el centro del enfoque d e sala limpia. Los libros de Stavely {Toward Zero-Defect Software, Addison-Wesley. 1998), Baber (Error-Free Software, Wiley, 1991) y Schulmeyer {Zero Defect Software, McGraw-Hill, 1990) a b o r d a n la prueba de corrección en forma muy detallada. En Internet hay disponible u n a amplia variedad d e fuentes de información acerca de la ingeniería del software d e sala limpia. Una lista actualizada de referencias en la World Wide Web se p u e d e encontrar en el sitio Web SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

C A P Í T U L O

I N G E N I E R Í A DEL SOFTWARE B A S A D A EN C O M P O N E N T E S CONCEPTOS CLAVE adoptación . . . . 8 8 8

30

E

n el c o n t e x t o de la i n g e n i e r í a del s o f t w a r e la reutilización e s u n a idea t a n t o a n t i g u a c o m o n u e v a . Los p r o g r a m a d o r e s h a n r e u t i l i z a d o i d e a s , a b s t r a c c i o n e s y p r o c e s o s d e s d e los p r i m e r o s d í a s d e la c o m p u t a c i ó n , p e r o el

e n f o q u e original p a r a la reutilización e r a e s p e c í f i c o . En la a c t u a l i d a d , los c o m p l e j o s s i s t e m a s d e alta calidad b a s a d o s e n c o m p u t a d o r a s s e d e b e n c o n s t r u i r e n

calificación

887

clasificación

892

DBC

886

u n t i e m p o m u y c o r t o y d e m a n d a u n e n f o q u e m á s o r g a n i z a d o d e la reutilización. La ingeniería del software basada en componentes (ISBC) e s u n p r o c e s o q u e

entorna de reotliindón .894

c o n c e d e p a r t i c u l a r i m p o r t a n c i a al d i s e ñ o y la c o n s t r u c c i ó n de s i s t e m a s b a s a d o s

ingeniería del dominio . . . 8 8 3

m e n t s [CLE95] d e s c r i b e así la ISBC:

ISBC

879

middleware . . . 8 9 0 economía

805

proceso

882

puntos de estroctura . . 8 9 7 tipos de componentes . .881

e n c o m p u t a d o r a s q u e utilizan " c o m p o n e n t e s " d e s o f t w a r e reutilizables. Cle-

[la ISBC] está cambiando la forma en que se desarrollan los grandes sistemas de software. [La fSBCj encama la filosofía de "comprar, no construir" de la cual son partida ríos Fred Brooks y otros. En la misma forma como las primeras subrutinas liberaron al programador de pensar acerca de los detalles, [la ISBC] cambió el interés de programar software por el de componer sistemas de software. La implementación ha dado paso a la integración como centro del enfoque. En sus cimientos está la suposición de que existe suficiente base común entre muchos grandes sistemas de software para justificar el desarrollo de componentes reutilizables para explotarla y satisfacerla. P e r o s u r g e n v a r i a s p r e g u n t a s . ¿Es p o s i b l e c o n s t r u i r s i s t e m a s c o m p l e j o s m e d i a n t e el e n s a m b l 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 reutilizables p r o v e n i e n t e s d e un c a t á l o g o ? ¿Esto se p u e d e lograr e n u n a f o r m a e f i c a z t a n t o e n c o s t o c o m o e n t i e m p o ? ¿Es p o s i b l e e s t a b l e c e r i n c e n t i v o s a d e c u a d o s q u e a l i e n t e n a los i n g e n i e r o s d e s o f t w a r e a reutilizar e n v e z d e r e i n v e n t a r ? ¿Los g e s t o r e s t i e n e n b u e n a d i s p o s i c i ó n p a r a incurrir e n el g a s t o a d i c i o n a l a s o c i a d o c o n la c r e a c i ó n d e c o m p o n e n t e s d e s o f t w a r e reutilizables? ¿La b i b l i o t e c a d e c o m p o n e n t e s e s n e c e s a r i a p a r a lograr q u e la reutilización s e c r e e e n u n a f o r m a q u e s e a a c c e s i b l e a q u i e n e s la n e c e s i t a n ? ¿Los c o m p o n e n t e s q u e e x i s t e n p u e d e n e n c o n t r a r l o s q u i e n e s los n e c e s i t e n ?

¿ Q u é e s ? Usted compra un sistema de entretenimiento y lo lleva a casa. C a d a componente ha sido diseñad o p a r a encajar en una arquitectura específica de audio y video: las conexiones son estandarizadas y el protocolo de comunicación se ha preestablecido. El ensamblado es sencillo porque usted no tiene que construir el

sistema a partir de cientos de partes discretas La ingeniería de software b a s a d a TM en componen tes (ISBC) lucha por lograr la misma coso. Un conjunto de componentes de software estandarizados preconstruidos se hacen disponibles p a r a encajar en un estilo arquitectónico específico para cierto dominio de aplicación. Entonces la aplicación es ensamblada usando dichos com

PDF Editor

879

880

PARTE CINCO


ponentes, en lugar de las partes discretas d e un lenguaje de programación convencional.

¿Quién lo hace? Los ingenieros de software aplican el proceso de ISBC. ¿ P o r q u é e s i m p o r t a n t e ? Toma sólo unos cuantos minutos ensamblar el sistema d e entretenimiento del hogar porque los componentes están diseñados para ser integrados con facilidad. Aunque el software es considerablemente más complejo, se sigue que los sistemas basados en componentes son más fáciles de ensamblar y por lo tanto menos costosos de construir que ios sistemas que se construyen a partir de partes discretas. Además, la ISBC alienta el uso d e patrones arquitectónicos predecibles y de infraestructura de software estándar, y por lo tanto conduce a un resultado de mayor calidad.

¿Cuáles son los pasos? La ISBC abarca dos actividades d e ingeniería paralelas: la ingeniería de dominios y el desarrollo basado en componentes. La ingeniería de dominios explora un dominio d e aplicación con la intención específica de encontrar componentes funcionales, de comportamiento y de datos que sean candidatos para la reutilización. Dichos componentes son colocados en librerías d e reutilización. El desarrollo basado en componentes obtiene requisitos de los clientes; selecciona un estilo arquitectónico apropiado para satisfacer los objetivos del

sistema a construir; y luego 1) selecciona componentes potenciales para reutilización, 2! califica los componentes para asegurarse de que encajan adecuadamente en la arquitectura para el sistema, 3) adapta los componentes si se deben hacer modificaciones para integrarlos adecuadamente, y 4) integra los componentes para formar subsistemas y la aplicación como un todo. Además, algunos componentes personalizados son sometidos a ingeniería para enfrentar aquellos aspectos del sistema que no pueden ser implementados con el uso de los componentes existentes.

¿Cuál es el producto de trabajo? Un software operativo, ensamblado con el uso de componentes d e software existentes y desarrollados recientemente, es el resultado de la ISBC.

¿Cómo puedo estar seguro de que lo he hecho correctamente? Use las mismas prácticas de SQA que se aplican en todo proceso de ingeniería del software: las revisiones técnicas formales valoran los modelos d e análisis y de diseño, las revisiones especializadas consideran los conflictos asociados con los componentes adquiridos, las pruebas se aplican para descubrir errores en el software desarrollado recientemente y en los componentes reutilizables que se han integrado en la arquitectura.

Incluso en la actualidad, los i n g e n i e r o s d e s o f t w a r e luchan c o n é s t a s y o t r a s p r e g u n t a s a c e r c a d e la reutilización de c o m p o n e n t e s d e s o f t w a r e . En este capítulo s e a b o r d a n a l g u n a s d e las r e s p u e s t a s .

30.1

Informoriónúliloceiai se puede encontrar en

I N G E N I E R Í A DE S I S T E M A S B A S A D A EN C O M P O N E N T E S En la superficie, la ISBC p a r e c e b a s t a n t e similar a la ingeniería del TM s o f t w a r e orientada a o b j e t o s convencional. El p r o c e s o c o m i e n z a c u a n d o un e q u i p o d e s o f t w a r e establece requisitos p a r a el s i s t e m a q u e s e construirá m e d i a n t e t é c n i c a s c o n v e n c i o -

PDF Editor www.cbd-hq.tom.

n a l e s d e investigación d e requisitos (capítulo 7). Se e s t a b l e c e un d i s e ñ o arquitectónico (capítulo 10), p e r o en lugar d e dirigirse i n m e d i a t a m e n t e hacia t a r e a s d e d i s e ñ o m á s detalladas, el e q u i p o e x a m i n a los requisitos p a r a d e t e r m i n a r q u é s u b c o n j u n t o está d i r e c t a m e n t e d i s p u e s t o p a r a la composición,

y n o p a r a la construcción. Es decir,

el equipo plantea las siguientes p r e g u n t a s para c a d a requisito del sistema:

CAPÍTULO 30

INGENIERÍA D A SOFTWARE EASADA EN COMPONENTES

881

• ¿Hay c o m p o n e n t e s c o m e r c i a l e s d e línea (CDL) d i s p o n i b l e s p a r a i m p l e m e n t a r los requisitos? • ¿Hay d i s p o n i b l e s c o m p o n e n t e s reutilizables d e s a r r o l l a d o s i n t e r n a m e n t e p a r a i m p l e m e n t a r los r e q u i s i t o s ? • ¿Las i n t e r f a s e s p a r a los c o m p o n e n t e s d i s p o n i b l e s s o n c o m p a t i b l e s d e n t r o de la a r q u i t e c t u r a del s i s t e m a q u e s e c o n s t r u i r á ? El e q u i p o tal v e z i n t e n t e m o d i f i c a r o e l i m i n a r a q u e l l o s r e q u i s i t o s del s i s t e m a q u e n o s e a p o s i b l e i m p l e m e n t a r c o n CDL o d e d e s a r r o l l o propio 1 . Si el r e q u i s i t o n o p u e d e c a m b i a r s e o e l i m i n a r s e s e a p l i c a n los m é t o d o s d e ingeniería del s o f t w a r e e n la construcción de aquellos nuevos c o m p o n e n t e s que deben desarrollarse para satisfacer los requisitos. P e r o p a r a l o s r e q u i s i t o s q u e se a b o r d a n c o n los c o m p o n e n t e s disp o n i b l e s c o m i e n z a un c o n j u n t o d i f e r e n t e d e a c t i v i d a d e s d e ingeniería del s o f t w a r e : cualificación, a d a p t a c i ó n , c o m p o s i c i ó n y a c t u a l i z a c i ó n . C a d a u n a d e e s t a s actividad e s d e ISBC s e e x a m i n a c o n m a y o r detalle e n la s e c c i ó n 30.4. En la p r i m e r a p a r t e d e e s t a s e c c i ó n s e h a u t i l i z a d o r e p e t i d a m e n t e el t é r m i n o componente,

a u n q u e falta u n a d e s c r i p c i ó n definitiva del t é r m i n o . B r o w n y W a l l n a u

[BR096] s u g i e r e n las s i g u i e n t e s posibilidades: • Componente:

p a r t e i m p o r t a n t e , c a s i i n d e p e n d i e n t e y r e e m p l a z a b l e d e u n siste-

m a q u e s a t i s f a c e u n a f u n c i ó n clara e n el c o n t e x t o d e u n a a r q u i t e c t u r a bien definida. • Componente

del software

en ejecución:

p a q u e t e d i n á m i c o de u n i ó n de u n o o

m á s p r o g r a m a s g e s t i o n a d o s c o m o u n i d a d y a los c u a l e s s e t i e n e a c c e s o p o r m e d i o d e i n t e r f a s e s d o c u m e n t a d a s q u e se p u e d e n d e s c u b r i r e n la e j e c u c i ó n . • Componente

de software:

unidad de composición que sólo tiene dependencias

d e c o n t e x t o explícitas y e s p e c i f i c a d a s e n f o r m a c o n t r a c t u a l . • Componente

de negocio• la i m p l e m e n t a c i ó n d e s o f t w a r e d e u n c o n c e p t o o p r o -

c e s o de negocio "autónomo". A d e m á s d e e s t a s d e s c r i p c i o n e s , los c o m p o n e n t e s d e 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 c o n b a s e e n s u s a p l i c a c i o n e s e n el p r o c e s o d e ISBC. A d e m á s d e los c o m p o n e n t e s CDL, el p r o c e s o d e ISBC p r o d u c e : • Componentes

cualificados:

e v a l u a d o s p o r i n g e n i e r o s de s o f t w a r e p a r a g a r a n t i -

z a r q u e n o s ó l o la f u n c i o n a l i d a d , s i n o el d e s e m p e ñ o , la fiabilidad, TM la facilidad d e u s o y o t r o s f a c t o r e s d e c a l i d a d (capítulo 26) c o n c u e r d a n c o n los r e q u i s i t o s del s i s t e m a o p r o d u c t o q u e se c o n s t r u i r á .

PDF Editor 1

La implicación es que la organización ajusta los requisitos de su negocio o producto de modo que la implementación basada en componentes se consiga sin que sea necesaria la ingeniería de personalización. Este enfoque reduce los costos y mejora el tiempo en que el producto llega al mercado, pero no siempre es posible

382

PARTE CINCO


• Componentes

adaptados:

mascarar o envolver) • Componentes

a d a p t a d o s p a r a m o d i f i c a r (acción t a m b i é n l l a m a d a en-

[BR096] c a r a c t e r í s t i c a s q u e n o s e r e q u i e r e n o i n d e s e a b l e s

actualizados:

s u s t i t u y e n el s o f t w a r e e x i s t e n t e c o n f o r m e e s t á n

d i s p o n i b l e s l a s n u e v a s v e r s i o n e s d e los c o m p o n e n t e s .

3Q.2

EL PROCESO P E I S B C El proceso

de ISBC s e c a r a c t e r i z a d e tal f o r m a q u e n o s ó l o identifica los c o m p o n e n -

t e s c a n d i d a t o s s i n o q u e t a m b i é n cualifica la i n t e r f a z d e c a d a c o m p o n e n t e , a d a p t a los c o m p o n e n t e s para eliminar las equivocaciones arquitectónicas, ensambla los comp o n e n t e s e n u n e s t i l o a r q u i t e c t ó n i c o s e l e c c i o n a d o y a c t u a l i z a los c o m p o n e n t e s conf o r m e los r e q u i s i t o s del s i s t e m a c a m b i a n [BR096], El m o d e l o d e p r o c e s o p a r a la i n g e n i e r í a del 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 d e s t a c a las p i s t a s p a r a l e l a s e n las c u a l e s la ingeniería del d o m i n i o (sección 30.3) s e lleva a c a b o c o n c u r r e n t e m e n t e c o n el d e s a r r o l l o b a s a d o e n c o m p o n e n t e s . La figura 30.1 ilustra u n m o d e l o d e p r o c e s o típico q u e e x p l í c i t a m e n t e a c o p l a la ISBC [CHR95], La ingeniería

del dominio

c r e a u n m o d e l o del d o m i n i o d e a p l i c a c i ó n

q u e s e utiliza 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 del u s u a r i o e n el flujo d e i n g e niería del s o f t w a r e . U n a a r q u i t e c t u r a g e n é r i c a d e s o f t w a r e p r o p o r c i o n a la e n t r a d a p a r a el d i s e ñ o d e la a p l i c a c i ó n . F i n a l m e n t e , d e s p u é s d e q u e los c o m p o n e n t e s reutilizables s e h a n c o m p r a d o , s e l e c c i o n a d o d e b i b l i o t e c a s e x i s t e n t e s o c o n s t r u i d o (co-

Medelo de proceso que a p o y a l a ISBC.

Ingeniería del dominio

Análisis del dominio

Desarrollo arquitectónico de software

Desarrollo de componentes reutilizables

Depósito de artefactos/ componentes reutilizables

TM

PDF Editor

CAPITULO 30

883


m o p a r t e d e la ingeniería del d o m i n i o ) , e s t á n d i s p o n i b l e s p a r a los i n g e n i e r o s d e s o f t w a r e d u r a n t e el d e s a r r o l l o b a s a d o e n c o m p o n e n t e s . Los p a s o s de análisis y diseño arquitectónico basado en componentes radigma

d e f i n i d o s c o m o p a r t e del desarrollo

(figura 30.1) s e p u e d e n i m p l e m e n t a r en el c o n t e x t o d e u n pa-

de diseño abstracto

(ADP, por s u s s i g l a s e n inglés) [DOG03], Un ADP implica

q u e el m o d e l o global del s o f t w a r e — r e p r e s e n t a d o c o m o d a t o s , f u n c i o n e s y c o m p o r t a m i e n t o (control)— s e p u e d e d e s c o m p o n e r j e r á r q u i c a m e n t e . C o n f o r m e la d e s c o m p o s i c i ó n c o m i e n z a , el s i s t e m a s e r e p r e s e n t a c o m o u n a c o l e c c i ó n d e m a r c o s de trab a j o a r q u i t e c t ó n i c o , c a d a u n o c o m p u e s t o d e u n o o m á s p a t r o n e s d e d i s e ñ o (capítulo 10). Un r e f i n a m i e n t o m a y o r identifica los c o m p o n e n t e s n e c e s a r i o s p a r a c r e a r c a da p a t r ó n d e d i s e ñ o . En u n c o n t e x t o ideal, t o d o s los c o m p o n e n t e s se a d q u i r i r í a n a partir d e u n d e p ó s i t o ( a p l i c a n d o a c t i v i d a d e s de calificación, de componentes). geniería

3Q.3

adaptación

y composición

C u a n d o s e r e q u i e r e n c o m p o n e n t e s e s p e c i a l i z a d o s s e aplica la in

de componentes.

I N G E N I E R Í A DEL P P M I N I Q La finalidad d e la ingeniería

del dominio

e s identificar, c o n s t r u i r , c a t a l o g a r y d i s e m i -

n a r u n c o n j u n t o d e c o m p o n e n t e s de s o f t w a r e q u e s e a n a p l i c a b l e s p a r a el s o f t w a r e e x i s t e n t e y f u t u r o e n u n d o m i n i o de a p l i c a c i ó n particular. La m e t a global e s e s t a b l e c e r m e c a n i s m o s q u e les p e r m i t a n a los i n g e n i e r o s d e s o f t w a r e c o m p a r t i r d i c h o s c o m p o n e n t e s — p a r a reutilizarlos— d u r a n t e el t r a b a j o e n s i s t e m a s n u e v o s y e x i s t e n t e s . La ingeniería del d o m i n i o incluye t r e s g r a n d e s a c t i v i d a d e s : análisis, c o n s t r u c c i ó n y diseminación.

"Lo ingeniería del dominio trata de encontrar los aspectos comunes entre los sistemas para identificar los componentes que seo posible aplicar en muchos sistemas, y para identificar familias de programas que se posicionen pora sacar la mayor ventaja d e dichos componentes." Paul (lements ^CONSEJO^. fIpioceso de análisis Se p u e d e a r g u m e n t a r q u e "la reutilización d e s a p a r e c e r á , n o p o r e l i m i n a c i ó n , s i n o estudiado en esta sec- p o r i n t e g r a c i ó n " e n la e s t r u c t u r a de la p r á c t i c a de la ingeniería del s o f t w a r e [TRA95], ción se enfoca en los C o m o la reutilización c a d a v e z t i e n e m a y o r a u g e a l g u n o s c r e e n q u e la ingeniería del componentes reutilizad bles. Sin embargo, el o m i n i o a d q u i r i r á t a n t a i m p o r t a n c i a c o m o la ingeniería del s o f t w a r e d u r a n t e la d é análisis de sistemas c a d a s i g u i e n t e . TM CDL completos (por ejemplo, aplicaciones30.3.1 El proceso d e análisis del dominio de comercio electróniEl e n f o q u e global p a r a el a n á l i s i s del d o m i n i o u s u a l m e n t e s e c a r a c t e r i z a e n el c o n co, aplicaciones de autexto d e la ingeniería del s o f t w a r e o r i e n t a d a a o b j e t o s . Los p a s o s e n el p r o c e s o s e tomatización de fuerza de ventas) definen como: también puede ser 1. Definir el d o m i n i o q u e s e investigará. una parte del análisis del dominio. 2 . C a t e g o r i z a r los e l e m e n t o s e x t r a í d o s del d o m i n i o .

PDF Editor

884 1 ¿Q«é • componentes identificados durante el análisis del dominio serán candidatos para la reutilización?

PARTE CINCO


3.

Recopilar u n a m u e s t r a r e p r e s e n t a t i v a d e las a p l i c a c i o n e s e n el d o m i n i o .

4.

A n a l i z a r c a d a aplicación e n la m u e s t r a y definir l a s c l a s e s d e a n á l i s i s .

5.

Desarrollar un modelo de análisis para las clases.

Es i m p o r t a n t e advertir q u e el a n á l i s i s del d o m i n i o e s a p l i c a b l e a c u a l q u i e r p a r a d i g m a d e i n g e n i e r í a del s o f t w a r e , y q u e s e p u e d e aplicar al d e s a r r o l l o c o n v e n c i o n a l y al orientado a objetos. A u n q u e los p a s o s c i t a d o s o f r e c e n u n m o d e l o útil p a r a el a n á l i s i s del d o m i n i o , n o b r i n d a n u n a guía p a r a decidir c u á l e s c o m p o n e n t e s d e s o f t w a r e s o n c a n d i d a t o s a la reutilización. H u t c h i n s o n y Hindley [HUT88] s u g i e r e n el s i g u i e n t e c o n j u n t o d e p r e g u n t a s p r á c t i c a s c o m o u n a guía p a r a identificar l o s c o m p o n e n t e s d e s o f t w a r e reutilizables: • ¿En las i m p l e m e n t a c i o n e s f u t u r a s s e r e q u i e r e la f u n c i o n a l i d a d del c o m p o n e n te? • ¿Cuán c o m ú n e s la f u n c i ó n del c o m p o n e n t e d e n t r o del d o m i n i o ? • ¿Existe duplicidad d e la f u n c i ó n del c o m p o n e n t e d e n t r o del d o m i n i o ? • ¿El c o m p o n e n t e d e p e n d e del h a r d w a r e ? Si e s así, ¿el h a r d w a r e p e r m a n e c e inv a r i a b l e e n t r e l a s i m p l e m e n t a c i o n e s o las e s p e c i f i c a c i o n e s del h a r d w a r e p u e den trasladarse hacia otro c o m p o n e n t e ? • ¿El d i s e ñ o e s t á lo s u f i c i e n t e m e n t e o p t i m i z a d o p a r a la s i g u i e n t e i m p l e m e n t a ción? • ¿ s e p u e d e n e s t a b l e c e r p a r á m e t r o s r e s p e c t o d e u n c o m p o n e n t e n o reutilizable d e m o d o q u e s e v u e l v a reutilizable? • ¿El c o m p o n e n t e e s reutilizable e n m u c h a s i m p l e m e n t a c i o n e s s ó l o c o n c a m bios menores? • ¿Es factible la reutilización p o r m e d i o de la m o d i f i c a c i ó n ? • ¿Un c o m p o n e n t e n o reutilizable s e p u e d e d e s c o m p o n e r p a r a p r o d u c i r c o m p o n e n t e s reutilizables? • ¿ C u á n válida e s la d e s c o m p o s i c i ó n d e u n c o m p o n e n t e p a r a la reutilización? Para i n f o r m a c i ó n a d i c i o n a l a c e r c a del a n á l i s i s del d o m i n i o v é a s e [ATK01], [HEI01] y [PRI93].

30.3.2 Funciones de caracterización

TM

A v e c e s e s difícil d e t e r m i n a r si u n c o m p o n e n t e p o t e n c i a l m e n t e reutilizable e s d e h e c h o a p l i c a b l e e n u n a s i t u a c i ó n particular. Esta d e t e r m i n a c i ó n r e q u i e r e definir u n

PDF Editor

c o n j u n t o de características del d o m i n i o q u e c o m p a r t a t o d o el s o f t w a r e d e n t r o d e u n dominio. U n a c a r a c t e r í s t i c a del d o m i n i o d e f i n e a l g ú n a t r i b u t o g e n é r i c o d e t o d o s los p r o d u c t o s q u e e x i s t e n d e n t r o d e él. Por e j e m p l o , las c a r a c t e r í s t i c a s g e n é r i c a s podrían incluir la i m p o r t a n c i a de la s e g u r i d a d y fiabilidad, el l e n g u a j e d e p r o g r a m a c i ó n , la c o n c u r r e n c i a e n el p r o c e s a m i e n t o y m u c h a s o t r a s .

CAPÍTULO 30

885


Un c o n j u n t o d e c a r a c t e r í s t i c a s d e d o m i n i o d e un c o m p o n e n t e reutilizable s e p u e Información útil acetco del anúlisis del dominio se puede encontrar en

d e r e p r e s e n t a r c o m o [Dp], d o n d e c a d a e l e m e n t o , D pj , e n el c o n j u n t o r e p r e s e n t a u n a c a r a c t e r í s t i c a e s p e c i f i c a del d o m i n i o . El v a l o r a s i g n a d o a Dpi r e p r e s e n t a u n a e s c a l a

www.sel.miu.

ordinal q u e indica la r e l e v a n c i a de la c a r a c t e r í s t i c a p a r a el c o m p o n e n t e p. U n a e s c a -

edu/sir/

la típica [BAS94] p o d r í a s e r

descriptions/ deda.html.

'I||

1: N o e s r e l e v a n t e si la reutilización e s a p r o p i a d a . 2:

Relevante sólo e n circunstancias inusuales.

3:

R e l e v a n t e : el c o m p o n e n t e s e m o d i f i c a p a r a u s a r l o , a p e s a r d e las d i f e r e n c i a s .

4:

C l a r a m e n t e r e l e v a n t e , y si el n u e v o s o f t w a r e n o t i e n e e s t a c a r a c t e r í s t i c a , la reutilización s e r á i n e f i c i e n t e p e r o tal v e z s e a posible.

5:

C l a r a m e n t e r e l e v a n t e , y si el n u e v o s o f t w a r e n o tiene e s t a c a r a c t e r í s t i c a , la reutilización s e r á i n e f i c i e n t e y la reutilización sin d i c h a c a r a c t e r í s t i c a n o se recomienda.

C u a n d o d e n t r o del d o m i n i o d e aplicación s e c o n s t r u i r á n u e v o s o f t w a r e , w, s e d e r i v a p a r a él u n c o n j u n t o d e c a r a c t e r í s t i c a s del d o m i n i o . E n t o n c e s s e c o m p a r a n Dp, y Dm p a r a d e t e r m i n a r si el c o m p o n e n t e e x i s t e n t e p s e reutiliza c o n eficacia e n la a p l i c a ción w. A u n q u e el s o f t w a r e q u e s e c o n s t r u i r á c l a r a m e n t e existe d e n t r o d e u n d o m i n i o d e a p l i c a c i ó n , los c o m p o n e n t e s r e u t i l i z a b l e s en él s e d e b e n a n a l i z a r p a r a d e t e r m i n a r s u aplicabilidad. En a l g u n o s c a s o s (con suerte, un n ú m e r o limitado), " r e i n v e n t a r la r u e d a " tal v e z s e a la m e j o r e l e c c i ó n en c u a n t o a c o s t o .

30.3.3 Modelado estructural y puntos de estructura C u a n d o s e aplica el a n á l i s i s del d o m i n i o el a n a l i s t a b u s c a l o s p a t r o n e s repetitivos e n l a s a p l i c a c i o n e s q u e r e s i d e n d e n t r o d e u n d o m i n i o . El m o d e l a d o e s t r u c t u r a l e s u n e n f o q u e d e ingeniería del d o m i n i o b a s a d a e n p a t r o n e s q u e f u n c i o n a b a j o la p r e m i s a de q u e c u a l q u i e r d o m i n i o d e aplicación tiene p a t r o n e s r e p e t i t i v o s (de f u n c i ó n , d a t o s y c o m p o r t a m i e n t o ) q u e t i e n e n u n p o t e n c i a l de reutilización. C a d a d o m i n i o d e a p l i c a c i ó n se c a r a c t e r i z a m e d i a n t e u n m o d e l o e s t r u c t u r a l (por e j e m p l o , l o s s i s t e m a s a v i ó n i c o s d e las a e r o n a v e s difieren e n o r m e m e n t e e n especific a c i o n e s , p e r o t o d o el s o f t w a r e m o d e r n o en e s t e d o m i n i o t i e n e el m i s m o m o d e l o e s tructural). Por lo t a n t o , el m o d e l o e s t r u c t u r a l e s u n estilo a r q u i t e c t ó n i c o (capítulo 10) q u e p u e d e y d e b e r e u t i l i z a r s e m e d i a n t e l a s a p l i c a c i o n e s d e n t r o del TMd o m i n i o . M c M a h o n [MCM95] d e s c r i b e u n punto

de estructura

c o m o " u n a e s t r u c t u r a distin-

ta d e n t r o d e u n m o d e l o e s t r u c t u r a l " . Los p u n t o s d e e s t r u c t u r a t i e n e n t r e s c a r a c t e r í s -

PDF Editor ®

¿Qué es un punto de e s tructura y cuáles son sus características?

ticas distintas: 1.

Un p u n t o d e e s t r u c t u r a e s u n a a b s t r a c c i ó n q u e d e b e t e n e r u n n ú m e r o limitado d e i n s t a n c i a s . A d e m á s , la a b s t r a c c i ó n d e b e r e c u r r i r a t r a v é s de l a s a p l i c a c i o n e s e n el d o m i n i o . De o t r o m o d o n o s e justifica el c o s t o d e verificar, d o c u m e n t a r y d i s e m i n a r el p u n t o d e e s t r u c t u r a .

886

PARTE CINCO 2.


Las r e g l a s q u e rigen el u s o del p u n t o d e e s t r u c t u r a d e b e n c o m p r e n d e r s e c o n facilidad. A d e m á s , la i n t e r f a z p a r a el p u n t o d e e s t r u c t u r a d e b e s e r r e l a t i v a m e n t e simple.

3.

El p u n t o de e s t r u c t u r a d e b e i m p l e m e n t a r la o c u l t a c i ó n d e i n f o r m a c i ó n ai aislar t o d a la c o m p l e j i d a d d e n t r o del m i s m o p u n t o de e s t r u c t u r a . Esto r e d u c e la c o m p l e j i d a d p e r c i b i d a del s i s t e m a g l o b a l e s c o n j u n t o .

\CLAVE

fe?

Un punto de estructuro es onólogo a un patrón d e diseño que se puede encontrar repetidamente en aplicaciones con un dominio específico.

C o m o un e j e m p l o de p u n t o s d e e s t r u c t u r a c o m o p a t r o n e s a r q u i t e c t ó n i c o s d e u n sist e m a , c o n s i d é r e s e el d o m i n i o d e s o f t w a r e d e s i s t e m a s d e a l a r m a . Este d o m i n i o p u e d e a b a r c a r s i s t e m a s t a n s i m p l e s c o m o HogarSeguro

(descritos e n c a p í t u l o s a n t e r i o r e s )

o t a n c o m p l e j o s c o m o el s i s t e m a de a l a r m a p a r a u n p r o c e s o industrial. Sin e m b a r go, e n c a d a c a s o s e e n c u e n t r a u n c o n j u n t o d e p a t r o n e s e s t r u c t u r a l e s p r e d e c i b l e s : u n a interfaz

q u e le p e r m i t e al u s u a r i o i n t e r a c t u a r c o n el s i s t e m a ; u n mecanismo

establecimiento

de límites

de

q u e le p e r m i t e al u s u a r i o e s t a b l e c e r límites a los p a r á m e -

t r o s q u e se m e d i r á n ; u n mecanismo

de gestión de sensores

los s e n s o r e s d e s u p e r v i s i ó n ; u n mecanismo

de respuesta

que se comunica con todos q u e r e a c c i o n a a la e n t r a d a

p r o p o r c i o n a d a por el s i s t e m a de g e s t i ó n d e s e n s o r e s , y u n mecanismo

de control q u e

le p e r m i t e al u s u a r i o c o n t r o l a r la f o r m a e n la q u e s e r e a l i z a la s u p e r v i s i ó n . C a d a u n o d e e s t o s p u n t o s de e s t r u c t u r a s e i n t e g r a e n u n a a r q u i t e c t u r a d e d o m i n i o . Es p o s i b l e definir p u n t o s de e s t r u c t u r a g e n é r i c o s q u e t r a s c i e n d a n d i f e r e n t e s d o m i n i o s d e aplicación [STA94]: t Aplicación

frontal (cliente): la GUI q u e incluye t o d o s los m e n ú s , p a n e l e s y e n -

t r a d a s y o r d e n a las f u n c i o n e s de e d i c i ó n . • Bases de datos: el d e p ó s i t o p a r a t o d o s los o b j e t o s r e l e v a n t e s r e s p e c t o del d o m i n i o d e la a p l i c a c i ó n . • Motor de cálculo: los m o d e l o s n u m é r i c o s y n o n u m é r i c o s q u e m a n i p u l a n d a tos. • Función de generación

de informes:

la f u n c i ó n q u e p r o d u c e s a l i d a s d e c u a l q u i e r

tipo. • Editor de aplicaciones:

el m e c a n i s m o p a r a p e r s o n a l i z a r la a p l i c a c i ó n r e s p e c t o a

las necesidades de usuarios específicos. Los p u n t o s d e e s t r u c t u r a se h a n s u g e r i d o c o m o u n a a l t e r n a t i v a a l a s l í n e a s d e c ó d i g o y p u n t o s de f u n c i ó n p a r a la e s t i m a c i ó n del c o s t o del s o f t w a r e [MCM95], En la s e c -

TM

ción 30.6.2 se p r e s e n t a u n a b r e v e d e s c r i p c i ó n del e m p l e o de los p u n t o s de e s t r u c t u ra e n la c o t i z a c i ó n .

PDF Editor El desarrollo

basado en componentes

(DBC) e s u n a actividad d e ISBC q u e o c u r r e e n

p a r a l e l o c o n la ingeniería del d o m i n i o . Al aplicar los m é t o d o s d e d i s e ñ o d e a n á l i s i s

y a r q u i t e c t ó n i c o y a t r a t a d o s e n e s t e libro, el e q u i p o de s o f t w a r e r e f i n a un estilo a r -

CAPÍTULO 30

887


q u i t e c t ó n i c o a p r o p i a d o p a r a el m o d e l o d e a n á l i s i s c r e a d o p a r a la aplicación q u e s e construirá.2 Una v e z q u e la a r q u i t e c t u r a s e h a e s t a b l e c i d o , d e b e n a g r e g á r s e l e c o m p o n e n t e s q u e I) e s t é n d i s p o n i b l e s e n b i b l i o t e c a s de reutilización 2) s e a n d i s e ñ a d o s p a r a satisf a c e r l a s n e c e s i d a d e s p e r s o n a l e s del cliente. Por t a n t o , el flujo d e t a r e a s p a r a el d e sarrollo b a s a d o e n c o m p o n e n t e s tiene d o s trayectorias p a r a l e l a s (figura 30.1). C u a n d o los c o m p o n e n t e s reutilizables e s t á n d i s p o n i b l e s p a r a s u p o t e n c i a l i n t e g r a c i ó n e n la arquitectura tienen que cualificarse y adaptarse. C u a n d o se requieren nuevos c o m p o n e n t e s e s p r e c i s o d i s e ñ a r l o s . E n t o n c e s los c o m p o n e n t e s r e s u l t a n t e s s e " c o m p o n e n " (integran) e n la plantilla a r q u i t e c t ó n i c a y s e p r u e b a n e n f o r m a m i n u c i o s a .

30.4.1 Calificación, adaptación y composición de componentes C o m o y a s e h a visto, la ingeniería del d o m i n i o p r o p o r c i o n a la biblioteca d e c o m p o n e n t e s reutilizables i n d i s p e n s a b l e s p a r a la ingeniería del 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 . Algunos d e e s t o s c o m p o n e n t e s s e desarrollan e s p e c i a l m e n t e p a r a el dominio, otros p u e d e n extraerse de aplicaciones existentes e incluso otros pueden adquirirse de terceras partes. D e s g r a c i a d a m e n t e , la e x i s t e n c i a d e c o m p o n e n t e s reutilizables n o g a r a n t i z a q u e p u e d a n i n t e g r a r s e c o n facilidad o e f i c a c i a e n la a r q u i t e c t u r a elegida p a r a u n a n u e v a aplicación. Por e s t a r a z ó n s e a p l i c a u n a s u c e s i ó n d e a c t i v i d a d e s d e d e s a r r o l l o b a s a d a e n c o m p o n e n t e s c u a n d o s e p r o p o n e el u s o d e u n c o m p o n e n t e . Calificación d e c o m p o n e n t e s .

Esta actividad g a r a n t i z a q u e el c o m p o n e n t e c a n -

d i d a t o r e a l i z a r á la f u n c i ó n r e q u e r i d a , " e n c a j a r á " a d e c u a d a m e n t e e n el e s t i l o a r q u i t e c t ó n i c o q u e e s p e c i f i c a el s i s t e m a y m o s t r a r á las c a r a c t e r í s t i c a s d e calidad (por e j e m p l o , d e s e m p e ñ o , fiabilidad, facilidad d e uso) q u e r e q u i e r e la aplicación. La d e s c r i p c i ó n de la i n t e r f a z s u m i n i s t r a i n f o r m a c i ó n útil a c e r c a d e la o p e r a c i ó n y ¿Qué facto• res se consideran durante la calificación de componentes?

la utilización d e u n c o m p o n e n t e de s o f t w a r e , p e r o n o p r o p o r c i o n a t o d a la i n f o r m a ción q u e s e r e q u i e r e p a r a d e t e r m i n a r si un c o m p o n e n t e p r o p u e s t o p u e d e , e n la p r á c tica, r e u t i l i z a r s e c o n e f i c a c i a e n u n a aplicación n u e v a . Entre los m u c h o s f a c t o r e s c o n s i d e r a d o s d u r a n t e la cualificación d e c o m p o n e n t e s e s t á n [BR096]: i n t e r f a z d e p r o g r a m a c i ó n de la a p l i c a c i ó n (IPA); h e r r a m i e n t a s d e d e s a r r o l l o e i n t e g r a c i ó n q u e r e q u i e r e el c o m p o n e n t e ; r e q u i s i t o s d e t i e m p o d e e j e c u c i ó n , q u e incluyen u s o d e rec u r s o s (por e j e m p l o , m e m o r i a o a l m a c e n a m i e n t o ) , t i e m p o s o v e l o c i d a d y p r o t o c o l o de red; requisitos d e servicio, q u e incluyen i n t e r f a s e s de s i s t e m a o p e r a t i v o y a p o y o d e

TM

o t r o s c o m p o n e n t e s ; c a r a c t e r í s t i c a s de s e g u r i d a d , q u e incluyen c o n t r o l e s de a c c e s o y p r o t o c o l o s de a u t e n t i c a c i ó n ; s u p o s i c i o n e s d e d i s e ñ o a n i d a d o , q u e incluyen el e m pleo de algoritmos numéricos o n o n u m é r i c o s específicos; y m a n e j o de excepciones.

PDF Editor 2

Se debe señalar que en el estilo arquitectónico con frecuencia influye el modelo estructural genérico creado durante la ingenieria del Con ir o rvease la ricura 30.1)

888

PARTE CINCO


C a d a u n o de e s t o s f a c t o r e s e s r e l a t i v a m e n t e sencillo d e e v a l u a r c u a n d o s e prop : n e n c o m p o n e n t e s reutilizables q u e s e h a n d e s a r r o l l a d o e s p e c i a l m e n t e p a r a la aplic a c i ó n . Sin e m b a r g o , e s m u c h o m á s difícil d e t e n n i n a r la o p e r a t i v i d a d i n t e r n a d e lc> CDL o d e c o m p o n e n t e s d e p r o v e n i e n t e s d e t e r c e r o s p o r q u e la ú n i c a i n f o r m a c i ó n d:s p o n i b l e tal v e z s e a la m i s m a e s p e c i f i c a c i ó n de la i n t e r f a z . Adaptación de componentes.

En u n c o n t e x t o ideal, la ingeniería del dominio

crearía u n a biblioteca de c o m p o n e n t e s q u e p o d r í a n i n t e g r a r s e f á c i l m e n t e e n u n a arq u i t e c t u r a d e aplicación. La i m p l i c a c i ó n de la " i n t e g r a c i ó n fácil" e s q u e 1) s e h a n imp l e m e n t a d o m é t o d o s c o n s i s t e n t e s d e gestión d e r e c u r s o s p a r a t o d o s los c o m p o n e n t e s en la biblioteca, 2) e x i s t e n a c t i v i d a d e s c o m u n e s c o m o la g e s t i ó n d e d a t o s p a r a todos los c o m p o n e n t e s , y 3) se h a n i m p l e m e n t a d o i n t e r f a s e s d e n t r o d e la a r q u i t e c t u r a \ c o n el e n t o r n o e x t e r n o e n u n a f o r m a c o n s i s t e n t e . ÔWSEJCÍ^.

En r e a l i d a d , i n c l u s o d e s p u é s d e q u e u n c o m p o n e n t e s e h a c u a l i f i c a d o p a r a e m plearlo dentro de una arquitectura de aplicación, es posible q u e haya conflictos en

Además de valorar si u n a o m á s de las á r e a s indicadas. Es t o s conflictos u s u a l m e n t e s e evitan u t i l i z a n d o u n a es justificado el costo t é c n i c a d e a d a p t a c i ó n l l a m a d a encubrimiento de componente [BR096]. C u a n d o u r de adaptación para lo e q u i p o de s o f t w a r e tiene p l e n o a c c e s o al d i s e ñ o i n t e r n o y el c ó d i g o de un c o m p o reutilización, el equipo de software también n e n t e (con f r e c u e n c i a n o e s el c a s o c u a n d o s e utilizan c o m p o n e n t e s CDL) s e aplica el de caja blanca. Al igual q u e s u c o n t r a p a r t e e n la p r u e b a d e s o f t w a r e evalúo si lograr la fun-encubrimiento cionalidad requerida y(capítulo 14), el e n c u b r i m i e n t o d e c a j a b l a n c a e x a m i n a los d e t a l l e s d e p r o c e s a m i e n el desempeño se puet o i n t e r n o del c o m p o n e n t e y h a c e m o d i f i c a c i o n e s e n el c ó d i g o p a r a e l i m i n a r cualden hacei eficientes de caja gris s e a p l i c a c u a n d o la b i b l i o t e c a d e c o m tBcpecto del tasto. q u i e r conflicto. El encubrimiento p o n e n t e s p r o p o r c i o n a u n l e n g u a j e d e e x t e n s i ó n de c o m p o n e n t e o IPA q u e p e r m i t e e l i m i n a r o e n m a s c a r a r los conflictos. El encubrimiento

de caja negra r e q u i e r e la in-

t r o d u c c i ó n de p r e y p o s p r o c e s a m i e n t o e n la i n t e r f a z del c o m p o n e n t e p a r a e l i m i n a r o e n m a s c a r a r los conflictos. El e q u i p o d e s o f t w a r e d e b e d e t e r m i n a r si el e s f u e r z o req u e r i d o p a r a e n c u b r i r a d e c u a d a m e n t e un c o m p o n e n t e e s t á justificado o si, e n lugar d e ello, d e b e d i s e ñ a r s e un c o m p o n e n t e p e r s o n a l i z a d o ( d e s i g n a d o p a r a e l i m i n a r los conflictos encontrados). Composición de componentes.

La t a r e a de c o m p o s i c i ó n d e c o m p o n e n t e e n -

s a m b l a c o m p o n e n t e s c u a l i f i c a d o s , a d a p t a d o s y d i s e ñ a d o s c o n el fin d e a g r e g á r s e l o s a la a r q u i t e c t u r a e s t a b l e c i d a p a r a u n a aplicación. Esto se logra e s t a b l e c i e n d o u n a inf r a e s t r u c t u r a q u e u n a los c o m p o n e n t e s e n u n s i s t e m a o p e r a t i v o . La i n f r a e s t r u c t u r a ( u s u a l m e n t e u n a biblioteca d e c o m p o n e n t e s e s p e c i a l i z a d o s ) p r o p o r c i o n a u n m o d e -

TM

lo p a r a c o o r d i n a r los c o m p o n e n t e s y los s e r v i c i o s e s p e c í f i c o s q u e p e r m i t e n q u e los c o m p o n e n t e s se c o o r d i n e n m u t u a m e n t e y r e a l i c e n t a r e a s c o m u n e s .

PDF Editor

Entre los m u c h o s m e c a n i s m o s q u e e x i s t e n p a r a c r e a r u n a i n f r a e s t r u c t u r a eficaz

h a y u n c o n j u n t o d e c u a t r o " i n g r e d i e n t e s a r q u i t e c t ó n i c o s " [ADL95] q u e d e b e e s t a r p r e s e n t e p a r a lograr la c o m p o s i c i ó n d e c o m p o n e n t e s : Modelo de intercambio de datos.

R e s p e c t o d e los c o m p o n e n t e s reutilizables

s e d e b e n definir m e c a n i s m o s q u e p e r m i t a n q u e los u s u a r i o s y a p l i c a c i o n e s interac-

CAPÍTULO 30 * ) ¿Qué ingre• clientes se necesitan para lograr la composición de componentes?

889


túen y t r a n s f i e r a n d a t o s (por e j e m p l o , a r r a s t r a r y soltar, cortar y pegar). Los m e c a n i s m o s de i n t e r c a m b i o d e d a t o s n o s ó l o p e r m i t e n la t r a n s f e r e n c i a de d a t o s h u m a n o - s o f t w a r e y c o m p o n e n t e - c o m p o n e n t e , s i n o t a m b i é n la t r a n s f e r e n c i a e n t r e r e c u r s o s del sist e m a (por e j e m p l o , a r r a s t r a r u n a r c h i v o a u n i c o n o d e i m p r e s o r a p a r a imprimirlo). A u t o m a t i z a c i ó n . Se d e b e n i m p l e m e n t a r v a r i a s h e r r a m i e n t a s , m a c r o s y g u i o n e s p a r a facilitar la i n t e r a c c i ó n e n t r e c o m p o n e n t e s reutilizables. A l m a c e n a m i e n t o e s t r u c t u r a d o . Los d a t o s h e t e r o g é n e o s (por e j e m p l o , d a t o s g r á f i c o s , v o z , video, t e x t o y d a t o s n u m é r i c o s ) q u e c o n t i e n e u n " d o c u m e n t o c o m p u e s t o " d e b e n e s t a r o r g a n i z a d o s y o f r e c e r a c c e s o c o m o u n a sola e s t r u c t u r a d e d a t o s y n o c o m o u n a c o l e c c i ó n d e a r c h i v o s s e p a r a d o s . "Los d a t o s e s t r u c t u r a d o s c o n s e r v a n u n índice d e s c r i p t i v o d e e s t r u c t u r a s a n i d a d a s p o r l a s c u a l e s l a s a p l i c a c i o n e s p u e d e n n a v e g a r l i b r e m e n t e p a r a ubicar, c r e a r o e d i t a r c o n t e n i d o s d e d a t o s i n d i v i d u a l e s s e g ú n o r d e n e el u s u a r i o final" [ADL95].

Referencia Web

M o d e l o d e o b j e t o s u b y a c e n t e . El m o d e l o d e o b j e t o a s e g u r a q u e los c o m p o -

Lo ¡rfom«KÍ6n más re-

n e n t e s d e s a r r o l l a d o s e n d i f e r e n t e s l e n g u a j e s d e p r o g r a m a c i ó n y q u e residen e n d i f e -

BA se puede obtener en w w w . o m g . o r g .

r e n t e s p l a t a f o r m a s p u e d e n s e r i n t e r o p e r a b l e s . Es decir, los o b j e t o s d e b e n ser c a p a c e s d e c o m u n i c a r s e a t r a v é s d e u n a red. Esto s e logra si el m o d e l o de o b j e t o d e f i n e u n e s t á n d a r p a r a la i n t e r o p e r a b i l i d a d d e los c o m p o n e n t e s . P u e s t o q u e el i m p a c t o p o t e n c i a l d e la reutilización y la ISBC s o b r e la industria del software es e n o r m e , varias g r a n d e s c o m p a ñ í a s y consorcios industriales han prop u e s t o e s t á n d a r e s p a r a el s o f t w a r e d e c o m p o n e n t e s :

Referencia Web

Lo información mis reciente acerco de COM

O M G / C O R B A . El G r u p o d e G e s t i ó n d e O b j e t o s (OMG, por s u s siglas e n inglés) h a p u b l i c a d o u n a arquitectura e n inglés). Un distribuidor

www.mkrosoft. (om/COM.

común de distribución

de objetos (CORBA: por s u s s i g l a s

de objetos (ORB, por s u s s i g l a s e n inglés) p r o p o r c i o n a u n a

diversidad de s e r v i c i o s q u e p e r m i t e n q u e los c o m p o n e n t e s reutilizables (objetos) s e c o m u n i q u e n c o n o t r o s c o m p o n e n t e s , sin i m p o r t a r s u u b i c a c i ó n d e n t r o de u n sistema. COM d e M i c r o s o f t . Microsoft h a d e s a r r o l l a d o u n modelo de objetos para componentes

(COM, p o r s u s siglas e n inglés) q u e o f r e c e u n a e s p e c i f i c a c i ó n p a r a utilizar

c o m p o n e n t e s producidos por varias e m p r e s a s dentro d e una sola aplicación que corra b a j o el s i s t e m a o p e r a t i v o W i n d o w s . El COM i n c l u y e d o s e l e m e n t o s : i n t e r f a c e s COM ( i m p l e m e n t a d a s c o m o o b j e t o s COM) y u n c o n j u n t o d e m e c a n i s m o s q u e registra y p a s a m e n s a j e s e n t r e i n t e r f a c e s COM.

TM

C o m p o n e n t e s S u n J a v a B e a n s . El s i s t e m a d e c o m p o n e n t e s J a v a B e a n s e s u n a i n f r a e s t r u c t u r a d e ISBC portátil e i n d e p e n d i e n t e d e la p l a t a f o r m a q u e utiliza y d e s a -

PDF Editor

rrolla e m p l e a n d o el l e n g u a j e d e p r o g r a m a c i ó n Java. El s i s t e m a d e c o m p o n e n t e s Ja-

v a B e a n s incluye u n c o n j u n t o d e h e r r a m i e n t a s , l l a m a d o Kit de Desarrollo Bean (BDK, Bean Development

Kit), q u e p e r m i t e a los d e s a r r o l l a d o r e s 1) a n a l i z a r c ó m o f u n c i o n a n

los B e a n s e x i s t e n t e s ( c o m p o n e n t e s ; 2) p e r s o n a l i z a r s u c o m p o r t a m i e n t o y a p a r i e n -

cia, 3) e s t a b l e c e r m e c a n i s m o s p a r a c o o r d i n a c i ó n y c o m u n i c a c i ó n , 4) d e s a r r o l l a r

890

PARTE CINCO

I' II !I'! HL l n 11 B e a n s Lo infamación mós recíente oceico de Jovobeons se puede obtener en javn.sun.tom/


p e r s o n a l i z a d o s p a r a u s a r l o s e n u n a a p l i c a c i ó n e s p e c í f i c a , y 5) p r o b a r y e v a -

l u a r el c o m p o r t a m i e n t o Bean. ¿Cuál d e e s t o s e s t á n d a r e s d o m i n a r á la i n d u s t r i a ? En e s t e m o m e n t o n o e x i s t e u n a r e s p u e s t a sencilla. A u n q u e m u c h o s d e s a r r o l l a d o r e s h a n a d o p t a d o u n o d e l o s e s t á n -

producís/

d a r e s , tal v e z las g r a n d e s o r g a n i z a c i o n e s d e s o f t w a r e q u i e r a n o p t a r p o r u n o d e los

javabeons/docs/

t r e s e s t á n d a r e s , s e g ú n las c a t e g o r í a s d e a p l i c a c i ó n y las p l a t a f o r m a s q u e elijan.

INFORMACIÓN

Arquitectura común de distribución de objetos 1

Los sistemas d i e n t e - s e r v i d o r se implementan

e m p l e n a d o c o m p o n e n t e s (objetos) d e s o f t w a r e q u e d e b e n ser c a p a c e s d e interactuar u n o s c o n otros d e n tro d e u n a sola m á q u i n a (cliente o servidor) o a través d e la r e d . Un distribuidor

de objetos

(ORB) e s middleware

(software p e r s o n a l i z a d o ) q u e p e r m i t e q u e un o b j e t o resid e n t e e n un cliente e n v í e un m e n s a j e a un m é t o d o q u e está e n c a p s u l a d o e n un o b j e t o residente e n un servidor. En e s en ci a , el ORB intercepta el m e n s a j e y m a n e j a las activid a d e s d e comunicación y coordinación necesarias p a r a e n c o n t r a r el o b j e t o al cual fue d i r i g i d o el m e n s a j e , invoca su m é t o d o , p a s a los d a t o s a p r o p i a d o s al o b j e t o y transfiere los d a t o s resultantes d e vuelta al o b j e t o q u e g e n e r ó primer o el m e n s a j e . de objetos.

En este r e c u a d r o CORBA se

u s a r á p a r a ilustrar el m i d d l e w a r e ORB,

Puesto q u e las peticiones d e o b j e t o s a través d e la red o c u r r e n e n t i e m p o d e ejecución, se d e b e establecer un mec a n i s m o p a r a a l m a c e n a r la descripción d e o b j e t o d e m o d o q u e la información pertinente a c e r c a del o b j e t o y su ubicación estén disponibles c u a n d o se necesite. El d e p ó s i t o d e interfaz l o g r a esto. C u a n d o u n a aplicación e n el cliente d e b e invocar un m é t o d o u b i c a d o d e n t r o d e un o b j e t o e n cualquier p a r t e del sistema, CORBA utiliza invocación d i n á m i c a p a r a 1) obtener información pertinente a c e r c a del m é t o d o d e s e a d o a partir del d e p ó s i t o d e interfaz, 2) c r e a r u n a estructura d e

En la figura 3 0 . 2 se ilustra la estructura b á s i c a d e u n a sistema cliente-servidor, los o b j e t o s servidores a m b o s se definen utilizando un lenguaje description

de descripción

languoge),

petición p a r a el o b j e t o , y 4) i n v o c a r la petición. Entonces la petición p a s a al núcleo del ORB — u n a p a r t e d e l sistema o p e r a t i v o d e la red e s p e c í f i c a d e la implementación q u e

a r q u i t e c t u r a CORBA. C u a n d o C O R B A se implemento e n un

(IDL, interface

sistema cliente-servidor.

d a t o s con p a r á m e t r o s q u e p a s a r á n al o b j e t o , 3) c r e a r u n a

CORBA, C O M y J a v a B e a n s implementan u n a filosofía d e distribuidor

la q u e se a c o m o d a n las peticiones d e objetos a lo l a r g o del

de ¡nterfase

un l e n g u a j e d e d e c l a -

r a c i o n e s q u e p e r m i t e q u e un i n g e n i e r o d e s o f t w a r e d e f i n a o b j e t o s , atributos, m é t o d o s y los m e n s a j e s q u e se r e q u i e r e n p a r a invocarlos. P a r a q u e un o b j e t o residente e n el cliente a c o m o d e u n a petición p a r a un m é t o d o r e s i d e n t e e n el servidor se c r e a n stubs ( a d a p t a d o r e s ) d e l IDL e n el cliente y el servidor. Los stubs p r o p o r c i o n a n la c o m p u e r t a a través d e

g e s t i o n a las peticiones— y se cumple la petición. La petición p a s a a través del núcleo y la p r o c e s a el servidor. En el sitio d e é s t e un a d a p t a d o r d e objeto a l m a c e n a i n f o r m a c i ó n d e la c l a s e y el o b j e t o e n un d e p ó s i t o d e interf a z residente e n el servidor, a c e p t a y g e s t i o n a las peticiones q u e llegan del cliente y r e a l i z a u n a d i v e r s i d a d d e o t r a s f u n c i o n e s d e gestión d e objetos. En el servidor stubs del IDL similares a los d e f i n i d o s e n la m á q u i n a cliente se utilizan c o m o la interfaz p a r a la implementación del o b j e t o real residente e n el sitio d e l servidor.

30.4.2 Ingeniería de componentes

TM

C o m o y a s e indicó e n e s t e capítulo, el p r o c e s o d e ISBC alienta el u s o d e c o m p o n e n -

PDF Editor

t e s d e s o f t w a r e existentes. Sin e m b a r g o , h a y o c a s i o n e s e n q u e los c o m p o n e n t e s d e b e n d i s e ñ a r s e . Es decir, s e d e b e n d e s a r r o l l a r n u e v o s c o m p o n e n t e s d e s o f t w a r e e integ r a r s e c o n l o s CDL y a e x i s t e n t e s y c o n los c o m p o n e n t e s d e d e s a r r o l l o p r o p i o . P u e s to q u e los n u e v o s c o m p o n e n t e s s e i n t e g r a n a la biblioteca p r o p i a d e c o m p o n e n t e s reutilizables, d e b e n d i s e ñ a r s e p a r a su reutilización.

CAPÍTULO 30

891


Arquitectura CORBA b á s i c a .

N o h a y n a d a m á g i c o e n la c r e a c i ó n d e c o m p o n e n t e s d e s o f t w a r e reutilizables. Los conceptos de diseño tales c o m o abstracción, ocultación, independencia funcional, refinamiento y programación estructurada, junto con m é t o d o s orientados a objeto, p r u e b a s d e SQA y m é t o d o s d e verificación d e c o r r e c c i ó n , t o d o s c o n t r i b u y e n a la c r e a c i ó n d e c o m p o n e n t e s d e s o f t w a r e reutilizables. 3 En e s t a s e c c i ó n n o s e v o l v e r á n a t r a t a r e s t o s t e m a s . M á s b i e n , s e c o n s i d e r a r á n los t e m a s e s p e c í f i c o s d e la reutilización q u e c o m p l e m e n t a n l a s p r á c t i c a s s ó l i d a s d e i n g e n i e r í a del s o f t w a r e .

30.4.3 Análisis y diseño p a r a la reutilización El m o d e l o d e a n á l i s i s s e a n a l i z a p a r a d e t e r m i n a r a q u e l l o s e l e m e n t o s del m o d e l o q u e a p u n t a n h a c i a los c o m p o n e n t e s reutilizables e x i s t e n t e s . El p r o b l e m a e s e x t r a e r inf o r m a c i ó n a partir del m o d e l o d e r e q u i s i t o s e n u n a f o r m a q u e c o n d u z c a a la " c o n cordancia de especificaciones". Si la c o n c o r d a n c i a d e e s p e c i f i c a c i o n e s p r o d u c e c o m p o n e n t e s q u e se a j u s t a n c o n las n e c e s i d a d e s d e la a p l i c a c i ó n actual, el d i s e ñ a d o r p u e d e e x t r a e r d i c h o s c o m p o n e n t e s d e u n a biblioteca (depósito) d e reutilización y a p l i c a r l o s e n el d i s e ñ o d e n u e v o s s i s t e m a s . Si n o e n c u e n t r a c o m p o n e n t e s de d i s e ñ o , el i n g e n i e r o d e s o f t w a r e d e b e

TM

a p l i c a r m é t o d o s d e d i s e ñ o c o n v e n c i o n a l u O O p a r a c r e a r l o s . En e s t e p u n t o — c u a n d o el d i s e ñ a d o r c o m i e n z a a c r e a r u n n u e v o c o m p o n e n t e — s e d e b e c o n s i d e r a r el diseño para la reutilización

(DPR).

PDF Editor

C o m o y a s e indicó, el DPR r e q u i e r e q u e el i n g e n i e r o d e s o f t w a r e a p l i q u e s ó l i d o s

c o n c e p t o s y p r i n c i p i o s d e d i s e ñ o d e s o f t w a r e (capítulo 9). P e r o t a m b i é n s e d e b e n

3

Para aprender más acerca de estos conceptos véanse las partes 2 y 5 de este libro.

892

ÔNSEJO^

PARTE CINCO


c o n s i d e r a r la c a r a c t e r í s t i c a s del d o m i n i o d e la a p l i c a c i ó n . Binder [BIN93] s u g i e r e v a rios t e m a s clave" q u e f o r m a n u n a b a s e p a r a el d i s e ñ o d e s t i n a d o a la reutilización.

El DPR puede sei bas- D a t o s e s t á n d a r . Se d e b e i n v e s t i g a r el d o m i n i o d e la a p l i c a c i ó n e identificar las tante difícil cuando los e s t r u c t u r a s d e d a t o s g l o b a l e s (por e j e m p l o , e s t r u c t u r a s d e a r c h i v o s o u n a b a s e d e dacomponentes deben estoi en interfaz o in- t o s c o m p l e t a ) . E n t o n c e s s e p u e d e n c a r a c t e r i z a r t o d o s los c o m p o n e n t e s d e d i s e ñ o tegrados con sistemas p a r a a p r o v e c h a r d i c h a s e s t r u c t u r a s d e d a t o s e s t á n d a r . heredados o con sisteP r o t o c o l o s d e i n t e r f a z e s t á n d a r . Se d e b e n e s t a b l e c e r t r e s n i v e l e s d e p r o t o c o mas múltiples cuyo arlo d quitectura y protocolos e i n t e r f a z : la n a t u r a l e z a d e l a s i n t e r f a c e s i n t r a m o d u l a r e s , el d i s e ñ o d e i n t e r f a c e s de interfaz sean in- t é c n i c a s (no h u m a n a s ) e x t e r n a s y la i n t e r f a z h o m b r e - m á q u i n a . consistentes. P l a n t i l l a s d e p r o g r a m a . El m o d e l o d e e s t r u c t u r a (sección 30.3.3) sirve c o m o u n a plantilla p a r a el d i s e ñ o a r q u i t e c t ó n i c o d e u n p r o g r a m a n u e v o . Una v e z e s t a b l e c i d a s las i n t e r f a s e s , los d a t o s e s t á n d a r y l a s plantillas d e p r o g r a m a , el d i s e ñ a d o r t i e n e u n m a r c o d e t r a b a j o e n el q u e p u e d e c r e a r el d i s e ñ o . Los n u e v o s c o m p o n e n t e s q u e se a j u s t e n a e s t e m a r c o d e t r a b a j o t i e n e n u n a m a y o r p r o b a b i lidad d e q u e s e les reutilice p o s t e r i o r m e n t e .

C o n s i d é r e s e u n a biblioteca universitaria. C i e n t o s d e m i l e s d e libros, p u b l i c a c i o n e s p e r i ó d i c a s y o t r a s f u e n t e s d e i n f o r m a c i ó n e s t á n d i s p o n i b l e s p a r a utilizarlos. P e r o el i n g r e s o a d i c h a s f u e n t e s r e q u i e r e d e s a r r o l l a r u n s i s t e m a d e clasificación. P a r a n a v e gar por e s t e g r a n v o l u m e n d e i n f o r m a c i ó n , los bibliotecarios h a n d e f i n i d o u n s i s t e m a d e clasificación q u e incluye el c ó d i g o d e clasificación d e la Biblioteca del C o n g r e s o (en los E s t a d o s Uni do s d e América), p a l a b r a s clave, n o m b r e s d e a u t o r y o t r a s e n t r a d a s d e índice. T o d o e s t o p e r m i t e q u e el u s u a r i o e n c u e n t r e r á p i d a y f á c i l m e n t e la fuente requerida. Ahora, considérese un gran depósito de componentes. Cientos de miles de c o m p o n e n t e s d e s o f t w a r e reutilizable s e h a l l a n e n él. Pero, ¿ c ó m o e n c u e n t r a u n ingeniero d e s o f t w a r e el c o m p o n e n t e q u e n e c e s i t a ? Para r e s p o n d e r e s t a p r e g u n t a s u r g e otra: ¿ c ó m o s e d e s c r i b e n los c o m p o n e n t e s d e s o f t w a r e e n t é r m i n o s clasificables y sin a m b i g ü e d a d e s ? Éstas s o n p r e g u n t a s difíciles y todavía n o s e h a d e s a r r o l l a d o u n a r e s p u e s ta definitiva. En e s t a sección s e e x p l o r a n las t e n d e n c i a s a c t u a l e s q u e permitirán a los f u t u r o s i n g e n i e r o s de s o f t w a r e n a v e g a r e n t r e las bibliotecas d e reutilización.

30.5.1 Descripción de los componentes reutilizables

TM

Un c o m p o n e n t e d e s o f t w a r e r e u t i l i z a b l e s s e d e s c r i b e e n m u c h a s f o r m a s , p e r o u n a

PDF Editor d e s c r i p c i ó n ideal incluye lo q u e Tracz [TRA90] h a l l a m a d o el modelo

3C: c o n c e p t o ,

contenido y contexto.

4

En general, se deben realizar preparativos para el DPR como parte de la ingeniería del dominio (sección 30.3).

CAPÍTULO 30 El concepto

893

INGENIERÍA D A SOFTWARE BASADA EN COMPONENTES

d e u n c o m p o n e n t e d e s o f t w a r e e s " u n a d e s c r i p c i ó n de lo q u e h a c e el

c o m p o n e n t e " [WHI95]. La i n t e r f a z c o n el c o m p o n e n t e e s t á c o m p l e t a m e n t e d e s c r i t a y la s e m á n t i c a — r e p r e s e n t a d a d e n t r o del c o n t e x t o d e las p r e c o n d i c i o n e s y las p o s c o n diciones—, identificada. El c o n c e p t o d e b e c o m u n i c a r la i n t e n c i ó n del c o m p o n e n t e . El contenido

d e u n c o m p o n e n t e d e s c r i b e c ó m o s e c o n s t r u y e el c o n c e p t o . En e s e n -

cia, el c o n t e n i d o e s i n f o r m a c i ó n o c u l t a p a r a l o s u s u a r i o s h a b i t u a l e s y q u e s ó l o n e c e s i t a n c o n o c e r l a q u i e n e s q u i e r a n m o d i f i c a r o p r o b a r el c o m p o n e n t e . El contexto

s i t ú a u n c o m p o n e n t e d e s o f t w a r e r e u t i l i z a b l e en s u d o m i n i o de aplica-

bilidad. Es decir, al e s p e c i f i c a r las c a r a c t e r í s t i c a s c o n c e p t u a l e s , o p e r a t i v a s y d e i m p l e m e n t a c i ó n el c o n t e x t o p e r m i t e q u e u n i n g e n i e r o d e s o f t w a r e e n c u e n t r e el c o m p o n e n t e a p r o p i a d o p a r a s a t i s f a c e r los r e q u i s i t o s d e la aplicación. P a r a q u e s e a n útiles e n la p r á c t i c a , c o n c e p t o , c o n t e n i d o y c o n t e x t o s e d e b e n traducir e n u n e s q u e m a d e e s p e c i f i c a c i ó n c o n c r e t o . Se h a n e s c r i t o d o c e n a s d e e n s a y o s y a r t í c u l o s a c e r c a de los e s q u e m a s d e clasificación p a r a c o m p o n e n t e s d e s o f t w a r e reutilizables (por e j e m p l o , [LUC01] y [WHI95] c o n t i e n e n bibliografías e x t e n s a s ) . Los m é t o d o s p r o p u e s t o s se p u e d e n clasificar e n t r e s g r a n d e s á r e a s : m é t o d o s d e bibliotec o n o m í a y d e c i e n c i a s de la c o m u n i c a c i ó n , m é t o d o s d e inteligencia artificial y sistem a s d e h i p e r t e x t o . La g r a n m a y o r í a del t r a b a j o r e a l i z a d o h a s t a la f e c h a s u g i e r e el e m p l e o de m é t o d o s de b i b l i o t e c o n o m í a p a r a la clasificación de c o m p o n e n t e s . La figura 3 0 . 3 p r e s e n t a u n a t a x o n o m í a de los m é t o d o s de i n d e x a c i ó n e n la bibliot e c o n o m í a . Los vocabularios

controlados

de indexación

limitan los t é r m i n o s o s i n t a x i s

c o n q u e s e clasifica u n o b j e t o ( c o m p o n e n t e ) . Los vocabularios

de indexación

no con-

trolados n o p o n e n r e s t r i c c i o n e s e n la n a t u r a l e z a de la d e s c r i p c i ó n . La m a y o r í a d e los e s q u e m a s d e clasificación p a r a los c o m p o n e n t e s d e s o f t w a r e s e incluye e n t r e s c a tegorías. C l a s i f i c a c i ó n e n u m e r a d a . Los c o m p o n e n t e s s e d e s c r i b e n m e d i a n t e u n a e s t r u c tura j e r á r q u i c a e n la cual s e d e f i n e n las c l a s e s y los n i v e l e s v a r i a b l e s d e s u b c l a s e s d e los c o m p o n e n t e s d e s o f t w a r e . La e s t r u c t u r a j e r á r q u i c a d e u n e s q u e m a de clasificación e n u m e r a d a facilita c o m p r e n d e r l o y utilizarlo. Sin e m b a r g o , a n t e s d e c o n s t r u i r u n a j e r a r q u í a s e d e b e llevar a c a b o la ingeniería del d o m i n i o d e m o d o q u e haya suficiente

c o n o c i m i e n t o de las e n t r a d a s a d e c u a d a s e n la j e r a r q u í a .

C l a s i f i c a c i ó n p o r f a c e t a s . Se a n a l i z a u n a á r e a del d o m i n i o y s e identifica u n c o n j u n t o de c a r a c t e r í s t i c a s d e s c r i p t i v a s b á s i c a s . Estas c a r a c t e r í s t i c a s , l l a m a d a s facetas, e n t o n c e s s e clasifican s e g ú n s u i m p o r t a n c i a y s e c o n e c t a n c o nTM un componente. U n a f a c e t a d e s c r i b e la f u n c i ó n q u e el c o m p o n e n t e realiza, los d a t o s q u e s e m a n i p u lan, el c o n t e x t o e n el q u e s e aplican o c u a l q u i e r a otra c a r a c t e r í s t i c a . El c o n j u n t o de

PDF Editor f a c e t a s q u e d e s c r i b e u n c o m p o n e n t e s e d e n o m i n a descriptor

de facetas.

En g e n e r a l ,

la d e s c r i p c i ó n por f a c e t a s s e limita a n o m á s d e siete u o c h o f a c e t a s .

C l a s i f i c a c i ó n d e v a l o r e s y a t r i b u t o s . Un c o n j u n t o d e a t r i b u t o s s e d e f i n e p a r a

t o d o s los c o m p o n e n t e s e n cierta á r e a del d o m i n i o . E n s e g u i d a s e a s i g n a n v a l o r e s a

d i c h o s a t r i b u t o s e n u n a f o r m a m u y similar a la clasificación por f a c e t a s . De h e c h o ,

894

PARTE CINCO


Indexación d e vocabularios

Taxonomía d e los métodos d e indexación [FRA94].

Controlado

Por clases

Descontrolado

P a l a b r a clave

— Enumerada

Términos extraídos del texto

— Descriptores

Por f a c e t a s

Encabezados d e materia

Términos no extraídos del texto

C o n sintaxis Sin sintaxis

Diccionario

la clasificación d e v a l o r e s y a t r i b u t o s e s similar a la clasificación p o r f a c e t a s , c o n las s i g u i e n t e s e x c e p c i o n e s : 1) n o s e limita el n ú m e r o d e a t r i b u t o s q u e s e p u e d e n utilizar, 2) n o s e a s i g n a n p r i o r i d a d e s a los a t r i b u t o s , y 3) n o s e utiliza la f u n c i ó n diccionario. C o n b a s e e n un e s t u d i o e m p í r i c o d e c a d a u n a d e e s t a s t é c n i c a s d e clasificación, F r a k e s y Pole [FRA94] indican q u e n o e x i s t e u n a t é c n i c a c l a r a m e n t e " m e j o r y q u e " n i n g ú n m é t o d o se d e s e m p e ñ ó m á s q u e m o d e r a d a m e n t e e n la eficacia d e b ú s q u e d a . . . " P a r e c e r í a q u e t o d a v í a falta realiza m á s t r a b a j o e n el d e s a r r o l l o d e e s q u e m a s d e clasificación e f i c a c e s p a r a b i b l i o t e c a s d e reutilización.

30.5.2 El entorno de reutilización La reutilización d e c o m p o n e n t e s d e s o f t w a r e d e b e a p o y a r l a u n e n t o r n o q u e incluya los s i g u i e n t e s e l e m e n t o s : • Una b a s e d e d a t o s d e c o m p o n e n t e s c a p a z d e a l m a c e n a r c o m p o n e n t e s d e s o f t w a r e , así c o m o la i n f o r m a c i ó n d e clasificación n e c e s a r i a p a r a r e c u p e r a r los. • Un s i s t e m a d e g e s t i ó n d e b i b l i o t e c a s q u e o f r e z c a a c c e s o a la b a s e d e d a t o s .

TM e j e m p l o , u n • Un s i s t e m a d e r e c u p e r a c i ó n d e c o m p o n e n t e s d e s o f t w a r e (por distribuidor d e o b j e t o s ) q u e p e r m i t a q u e u n a aplicación cliente r e c u p e r e c o m p o n e n t e s y s e r v i c i o s del s e r v i d o r d e la biblioteca.

PDF Editor

• H e r r a m i e n t a s d e ISBC q u e a p o y e n la i n t e g r a c i ó n d e los c o m p o n e n t e s reutilizados en un nuevo diseño o implementación.

C a d a u n a de e s t a s f u n c i o n e s i n t e r a c t ú a c o n o e s t á i n c o r p o r a d a e n los c o n f i n e s d e

u n a biblioteca d e reutilización.

CAPITULO 30

895


La biblioteca d e reutilización e s u n e l e m e n t o de un d e p ó s i t o d e s o f t w a r e m a y o r (capítulo 27) y p r o p o r c i o n a m e d i o s p a r a el a l m a c e n a m i e n t o d e c o m p o n e n t e s d e s o f t w a r e y u n a a m p l i a g a m a de p r o d u c t o s d e t r a b a j o reutilizables (por e j e m p l o , e s p e c i f i c a c i o n e s , d i s e ñ o s , p a t r o n e s , m a r c o s de t r a b a j o , f r a g m e n t o s d e c ó d i g o , c a s o s d e p r u e b a , g u i a s de usuario). La biblioteca c o n t i e n e u n a b a s e de d a t o s y las h e r r a m i e n t a s n e c e s a r i a s p a r a c o n s u l t a r l a y r e c u p e r a r c o m p o n e n t e s d e ella. Un e s q u e m a de clasificación de c o m p o n e n t e s (sección 30.5.1) sirve c o m o b a s e p a r a c o n s u l t a r la biblioteca. Las c o n s u l t a s u s u a l m e n t e s e c a r a c t e r i z a n m e d i a n t e el e l e m e n t o c o n t e x t o del m o d e l o 3C ya d e s c r i t o e n e s t a s e c c i ó n . Si u n a c o n s u l t a inicial r e s u l t a e n u n a e x t e n s a lista d e c o m p o n e n t e s c a n d i d a t o s , la c o n s u l t a se r e f i n a p a r a reducirla. E n t o n c e s s e e x liMI-liliHllidl

t r a e la i n f o r m a c i ó n d e c o n c e p t o y c o n t e n i d o ( d e s p u é s d e hallar los c o m p o n e n t e s c a n d i d a t o s ) p a r a auxiliar al d e s a r r o l l a d o r e n la s e l e c c i ó n del c o m p o n e n t e a p r o p i a d o . U n a d e s c r i p c i ó n d e t a l l a d a de la e s t r u c t u r a de las b i b l i o t e c a s de reutilización y d e

traren http://www.

M

cbd-hq.com/.

l a s h e r r a m i e n t a s q u e l a s g e s t i o n a n e s m e j o r d e j á r s e l a a las f u e n t e s e s p e c i a l i z a d a s e n la m a t e r i a . El lector i n t e r e s a d o o b t e n d r á m a y o r i n f o r m a c i ó n c o n s u l t a n d o [F1S00] y ILIN95], HERRAMIENTAS DE SOFTWARE

Desarrollo basado en componentes O b j e t i v o : Auxiliar en el modelado, diseño, revisión e integración d e los componentes d e soft-

Component

Manager,

desarrollada por Flashline (www-

.flashline.com), "es una aplicación q u e posibilita, pro-

w a r e como parte d e un sistema mayor.

mueve y mide la reutilización d e componentes de

M e c á n i c a : La mecánico d e las herramientas varía. En

software".

general, las herramientas d e DBC auxilian en una o más d e las siguientes capacidades: especificación y modelado de la arquitectura del software; navegación y selección d e los componentes d e software disponibles; integración d e componentes.

conjunto integrado d e productos p a r a el diseño d e softw a r e , revisión d e diseño, gestión d e servicios y componentes, gestión d e requisitos y generación d e código".

Herramientas representativas 5 ComponentSource

Select Component Factory, desarrollada por Select Business Solutions (www.selectbs.com/products), "es un

(www.componentsource.com) propor-

Software Through P¡ctures-ACD, distribuida por Aonix (www.aonix.com), permite el modelado integral em-

ciona un amplia serie d e componentes (y herramientas)

pleando UML p a r a la arquitectura que rige el modelo

d e software CDL a p o y a d o en muchos estándares d e

O M G ; un enfoque p a r a la ISBC abierta e independien-

componentes diferentes.

te d e la empresa.

TM

3Q.6

E C O N O M Í A PE LA I S B C

PDF Editor

La ingeniería del 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 tiene u n a t r a c t i v o intuitivo. En teoría, d e b e p r o p o r c i o n a r a u n a o r g a n i z a c i ó n d e s o f t w a r e v e n t a j a s e n c u a n t o a cali-

5

Las herramientas expuestas sólo representar una muestra de esta categoría. En la mayoría de los casos los nombres de las mismas son marcas registradas por sus respectivos desarrolladores.

896

PARTE CINCO


d a d y o p o r t u n i d a d , lo q u e d e b e t r a d u c i r s e e n a h o r r o s . Pero, ¿ e x i s t e n d a t o s r e a l e s q u e Uno diversidad de orft culos que ofrecen directrices poro el DBCy los sistemas bosodos en CDL se puede encontrar en w w w . s e i . c m u . edu.

a p o y e n e s t a intuición? La r e s p u e s t a a e s t a p r e g u n t a p r i m e r o requiere e n t e n d e r lo q u e e n realidad s e p u e d e r e u t i l i z a r e n un c o n t e x t o de ingeniería del s o f t w a r e y l u e g o c u á l e s s o n e n realidad los c o s t o s a s o c i a d o s c o n la reutilización. C o m o c o n s e c u e n c i a , s e r á p o s i b l e d e s a r r o llar u n a n á l i s i s c o s t o - b e n e f i c i o p a r a la reutilización d e c o m p o n e n t e s .

30.6.1 Impacto sobre la calidad, la productividad y el costo Existen n u m e r o s a s e v i d e n c i a s , a partir de e s t u d i o s de c a s o i n d u s t r i a l e s (por e j e m p l o , [ALL02], [HEN95], [MCM95]), q u e i n d i c a n la posibilidad d e d e r i v a r s u s t a n c i a l e s b e n e ficios d e n e g o c i o s a partir d e la reutilización v i g o r o s a del s o f t w a r e . M e j o r a n la calid a d del p r o d u c t o , la p r o d u c t i v i d a d d e d e s a r r o l l o y el c o s t o global. Calidad.

En u n e n t o r n o ideal, u n c o m p o n e n t e de s o f t w a r e q u e s e d e s a r r o l l e p a r a

reutilización s e verificaría c o m o c o r r e c t o ( v é a s e el c a p í t u l o 29) y n o c o n t e n d r í a d e fectos. En r e a l i d a d , la verificación f o r m a l n o se lleva a c a b o d e m a n e r a r u t i n a r i a y existe la posibilidad de q u e o c u r r a n d e f e c t o s , y de h e c h o o c u r r e n . Sin e m b a r g o , c o n c a d a reutilización los d e f e c t o s s e e n c u e n t r a n y e l i m i n a n , y, c o m o r e s u l t a d o , m e j o r a la calidad del c o m p o n e n t e . C o n el t i e m p o el c o m p o n e n t e q u e d a v i r t u a l m e n t e libre de defectos. En u n e s t u d i o r e a l i z a d o e n H e w l e t t - P a c k a r d , Lim [LIM94] r e p o r t ó q u e la t a s a de d e f e c t o s p a r a el c ó d i g o reutilizado e s d e 0.9 d e f e c t o s p o r KLDC, m i e n t r a s q u e la tas a p a r a s o f t w a r e d e s a r r o l l a d o r e c i e n t e m e n t e e s de 4.1 d e f e c t o s p o r KLDC. En u n a aplicación c o m p u e s t a d e 6 8 p o r c i e n t o d e c ó d i g o r e u t i l i z a d o la t a s a d e d e f e c t o f u e d e 2 . 0 d e f e c t o s p o r KLDC, e s decir: u n 51 por c i e n t o d e m e j o r a r e s p e c t o de la t a s a e s p e r a d a si la a p l i c a c i ó n h u b i e s e s i d o d e s a r r o l l a d a sin reutilización. Henry y Faller [HEN95] r e p o r t a u n 3 5 p o r c i e n t o d e m e j o r a e n la calidad. A u n q u e los r e p o r t e s a n e c d ó t i c o s a b a r c a n u n e s p e c t r o r a z o n a b l e m e n t e a m p l i o de p o r c e n t a j e s de m e j o r a e n la calidad, e s justo a f i r m a r q u e la reutilización o f r e c e u n b e n e f i c i o i m p o r t a n t e e n c u a n t o a la calidad y fiabilidad p a r a el s o f t w a r e e n t r e g a d o . Productividad.

C u a n d o los 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 a p l i c a n a lo largo del

p r o c e s o d e s o f t w a r e , s e d e d i c a m e n o s t i e m p o a la c r e a c i ó n d e p l a n e s , m o d e l o s , d o c u m e n t o s , c ó d i g o y d a t o s q u e s e r e q u i e r e n p a r a c r e a r u n s i s t e m a fiable. Por lo t a n to, s e e n t r e g a al cliente el m i s m o nivel d e f u n c i o n a l i d a d c o n m e n o s e s f u e r z o , lo q u e m e j o r a la p r o d u c t i v i d a d . A u n q u e los r e p o r t e s d e m e j o r a p o r c e n t u a l e n la productivi-

TM

d a d s o n n o t a b l e m e n t e difíciles d e i n t e r p r e t a r , 6 p a r e c e q u e la reutilización del 3 0 al 5 0 p o r c i e n t o p u e d e r e s u l t a r e n m e j o r a s e n la p r o d u c t i v i d a d e n el r a n g o del 2 5 - 4 0 p o r

PDF Editor ciento.

6

Muchas circunstancias atenuantes (por ejemplo, dominio de aplicación, complejidad del problema,

estructura y tamaño del equipo, duración del proyecto, tecnología aplicada) tienen un profundo impacto sobre la productividad del equipo del proyecto.

CAPÍTULO 30

^CONSEJO^-

Costo.

897

INGENIERÍA D A SOFTWARE BASADA EN COMPONENTES

Los a h o r r o s e n el c o s t o n e t o p o r la reutilización s e e s t i m a n al p r o y e c t a r el

c o s t o del p r o y e c t o si é s t e f u e s e d e s a r r o l l a d o d e s d e c e r o , C 0 , y l u e g o s e r e s t a la s u m a

El costo de desarrollard e los c o s t o s a s o c i a d o s c o n la reutilización, Cr, y el c o s t o real del s o f t w a r e e n el m o un componente reutilhm e n t o d e la e n t r e g a , Q . zable con frecuencia El f a c t o r C 0 s e p u e d e d e t e r m i n a r al a p l i c a r u n a o m á s d e las t é c n i c a s de e s t i m a es mayor que el de desarrolloi un compo-ción e s t u d i a d a s e n el capítulo 23. Los c o s t o s a s o c i a d o s con la reutilización, C„ incluyen nente específico para [CHR95]: a n á l i s i s y m o d e l a d o del d o m i n i o , d e s a r r o l l o de a r q u i t e c t u r a del d o m i n i o , una aplicación. Asegúa u m e n t o e n la d o c u m e n t a c i ó n p a r a facilitar la reutilización, s o p o r t e y m e j o r a d e los rese de que en el futuc o m p o n e n t e s d e r e u t i l i z a c i ó n , r e g a l í a s y l i c e n c i a s p a r a c o m p o n e n t e s a d q u i r i d o s ex ro habrá uno necesidad lespecto delt e r n a m e n t e , c r e a c i ó n o a d q u i s i c i ó n y o p e r a c i ó n de u n d e p ó s i t o d e reutilización, y e n componente reutiliza-t r e n a m i e n t o del p e r s o n a l e n d i s e ñ o y c o n s t r u c c i ó n p a r a reutilización. A u n q u e los ble. Aquí es donde se c o s t o s a s o c i a d o s c o n el a n á l i s i s del d o m i n i o (sección 30.3) y la o p e r a c i ó n d e un d e realiza lo retribución. p ó s i t o d e reutilización p u e d e n s e r s u s t a n c i a l e s , m u c h o s de los o t r o s c o s t o s i n d i c a d o s a q u í a b o r d a n los conflictos q u e f o r m a n p a r t e d e u n a b u e n a práctica de ingeniería d e s o f t w a r e , ya s e a q u e la r e u t i l i z a c i ó n s e a o n o u n a prioridad.

30.6.2 Análisis de costo empleando puntos de estructura En la s e c c i ó n 30.3.3 s e d e f i n i ó u n p u n t o d e e s t r u c t u r a c o m o un p a t r ó n a r q u i t e c t ó n i c o r e c u r r e n t e e n la t o t a l i d a d de un d o m i n i o de a p l i c a c i ó n particular. Un d i s e ñ a d o r de s o f t w a r e (o i n g e n i e r o d e s i s t e m a s ) p u e d e d e s a r r o l l a r u n a a r q u i t e c t u r a p a r a u n a n u e va a p l i c a c i ó n , s i s t e m a o p r o d u c t o al definir u n a a r q u i t e c t u r a del d o m i n i o y l u e g o d o tarla c o n p u n t o s de e s t r u c t u r a . Ésto s s o n o c o m p o n e n t e s r e u t i l i z a b l e s i n d i v i d u a l e s o p a q u e t e s d e c o m p o n e n t e s reutilizables. A u n q u e los p u n t o s de e s t r u c t u r a s e a n reutilizables, s u s c o s t o s d e cualificación, adaptación, integración y m a n t e n i m i e n t o n o son insignificantes. Antes de proceder a la reutilización el g e s t o r del p r o y e c t o d e b e c o m p r e n d e r los c o s t o s a s o c i a d o s c o n la utilización d e los p u n t o s d e e s t r u c t u r a . D a d o q u e t o d o s los p u n t o s d e e s t r u c t u r a (y los c o m p o n e n t e s reutilizables en g e neral) t i e n e n u n a historia, e s p o s i b l e recopilar d a t o s d e c o s t o s d e c a d a u n o . En u n c o n t e x t o ideal los c o s t o s d e calificación, a d a p 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 i a d o s c o n c a d a c o m p o n e n t e e n u n a biblioteca d e r e u t i l i z a c i ó n se m a n t i e n e n p a ra c a d a c a s o d e utilización. E n t o n c e s se p u e d e n a n a l i z a r d i c h o s d a t o s p a r a d e s a r r o llar los c o s t o s p r o y e c t a d o s r e s p e c t o del s i g u i e n t e c a s o d e reutilización. C o m o e j e m p l o , c o n s i d é r e s e u n a n u e v a a p l i c a c i ó n , X, q u e r e q u i e r e 6 0 por c i e n t o

TM

de c ó d i g o n u e v o y la reutilizació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 : PE,, PE2 y PE.,. C a d a u n o d e e s t o s c o m p o n e n t e s reutilizables s e h a u t i l i z a d o e n m u c h a s o t r a s aplicacion e s , y e s t á n d i s p o n i b l e s los c o s t o s p r o m e d i o p a r a cualificación, a d a p t a c i ó n , i n t e g r a -

PDF Editor ción y mantenimiento.

La estimación del e s f u e r z o necesario para entregar X requiere determinar lo siguiente: e s f u e r z o global = E n u

donde

898

PARTE CINCO


¿nuevo = e s f u e r z o r e q u e r i d o p a r a d i s e ñ a r y c o n s t r u i r n u e v o s c o m p o n e n t e s de s o f t w a r e ( d e t e r m i n a d o s e m p l e a n d o l a s t é c n i c a s d e s c r i t a s e n el capít u l o 23) Ecaiir

= e s f u e r z o r e q u e r i d o p a r a calificar PE,, PE 2 y PE 3

¿adapi

= e s f u e r z o r e q u e r i d o p a r a a d a p t a r PE,, PE 2 y PE 3

£int

=

e s f u e r z o r e q u e r i d o p a r a i n t e g r a r PE,, PE 2 y PE 3

El e s f u e r z o r e q u e r i d o p a r a cualificar, a d a p t a r e i n t e g r a r PE,, PE 2 y PE 3 s e d e t e r m i n a al t o m a r el p r o m e d i o d e los d a t o s h i s t ó r i c o s r e c o p i l a d o s p a r a la cualificación, a d a p t a c i ó n e i n t e g r a c i ó n d e los c o m p o n e n t e s reutilizables e n o t r a s a p l i c a c i o n e s .

La ingeniería del 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 o f r e c e b e n e f i c i o s i n h e r e n t e s e n la calidad del s o f t w a r e , la p r o d u c t i v i d a d del d e s a r r o l l a d o r y el c o s t o global del sistem a . Sin e m b a r g o , f a l t a s u p e r a r m u c h o s o b s t á c u l o s a n t e s d e q u e el m o d e l o d e p r o c e s o d e ISBC s e utilice a m p l i a m e n t e e n la industria. A d e m á s d e los c o m p o n e n t e s del s o f t w a r e , u n i n g e n i e r o de s o f t w a r e p u e d e adquirir u n a a m p l i a g a m a d e a r t e f a c t o s reutilizables. Entre é s t o s s e e n c u e n t r a n r e p r e s e n t a c i o n e s t é c n i c a s del s o f t w a r e (por e j e m p l o , e s p e c i f i c a c i o n e s , m o d e l o s a r q u i t e c t ó n i cos, d i s e ñ o s ) , d o c u m e n t o s , p a t r o n e s , m a r c o s d e t r a b a j o , d a t o s d e p r u e b a e i n c l u s o t a r e a s r e l a c i o n a d a s c o n el p r o c e s o (por e j e m p l o , i n s p e c c i o n e s t é c n i c a s ) . El p r o c e s o d e ISBC incluye d o s s u b p r o c e s o s c o n c u r r e n t e s : la i n g e n i e r í a del d o m i n i o y el d e s a r r o l l o b a s a d o e n c o m p o n e n t e s . La finalidad d e la i n g e n i e r í a del d o m i n i o e s identificar, construir, c a t a l o g a r y d i s e m i n a r u n c o n j u n t o d e c o m p o n e n t e s d e s o f t w a r e e n u n d o m i n i o d e a p l i c a c i ó n e s p e c í f i c o . E n t o n c e s el d e s a r r o l l o b a s a d o e n c o m p o n e n t e s califica, a d a p t a e integra d i c h o s c o m p o n e n t e s p a r a e m p l e a r l o s e n un n u e v o s i s t e m a . A d e m á s , el d e s a r r o l l o b a s a d o e n c o m p o n e n t e s d i s e ñ a los c o m p o n e n t e s n u e v o s q u e s e b a s a n e n los r e q u i s i t o s p e r s o n a l i z a d o s d e u n s i s t e m a n u e v o . Las t é c n i c a s d e a n á l i s i s y d i s e ñ o p a r a 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 b a s a n e n los m i s m o s principios y c o n c e p t o s q u e forman parte de una b u e n a práctica de ingeniería del s o f t w a r e . Los c o m p o n e n t e s reutilizables d e b e n d i s e ñ a r s e e n u n e n t o r n o q u e establezca estructuras de datos estándar, protocolos de interfaz y arquitecturas de p r o g r a m a p a r a c a d a d o m i n i o d e la a p l i c a c i ó n . La ingeniería del 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 utiliza un m o d e l o d e intercambio d e d a t o s , h e r r a m i e n t a s , a l m a c e n a m i e n t o e s t r u c t u r a d o y u n m o d TM e l o de o b j e t o suby a c e n t e p a r a construir las aplicaciones. El m o d e l o d e o b j e t o g e n e r a l m e n t e c o n c u e r d a c o n u n o o m á s e s t á n d a r e s de c o m p o n e n t e s (por ejemplo, OMG/CORBA) q u e d e f i n e n

PDF Editor

la f o r m a e n q u e u n a aplicación p u e d e a c c e d e r a los o b j e t o s reutilizables. Los e s q u e m a s d e clasificación p e r m i t e n q u e un d e s a r r o l l a d o r e n c u e n t r e y r e c u p e r e c o m p o n e n t e s reutilizables y s e a j u s t e a un m o d e l o q u e identifica c o n c e p t o , c o n t e n i d o y c o n t e x t o . La clasificación e n u m e r a d a , la clasificación p o r f a c e t a s y la clasificación d e v a l o r e s y a t r i b u t o s s o n r e p r e s e n t a t i v a s de m u c h o s e s q u e m a s de clasificación de c o m p o n e n t e s .

CAPÍTULO 30

INGENIERÍA DEL SOFTWARE BASADA EN C O M P O N E N T E S

899

La e c o n o m í a d e la reutilización del s o f t w a r e s e a b o r d a m e d i a n t e u n a sola p r e g u n ta: ¿es efectivo en costo el construir m e n o s y reutilizar m á s ? En general, la respuesta e s sí, p e r o un planificador de proyectos d e s o f t w a r e d e b e c o n s i d e r a r los c o s t o s imp o r t a n t e s a s o c i a d o s c o n la calificación, a d a p t a c i ó n e integración d e los c o m p o n e n tes reutilizables.

[ADL95] Adler, R. M., "Emerging Standards for Component Software", en Computer, vol 28, núm. 3, marzo de 1995, pp. 68-77. [ALL021 Alien, P., "CBD Survey: The State of the Practice", en The Cutter Edge, marzo de 2002, disponible en http://www.cutter.com/research/2002/edge020305.html.' [ATK0I) Atkinson, C., et al., Component-Based Product Line Engineeríng wilh UML, Addison-Wesley, 2001, [BAS94] Basili, V. R., L. C. Briand y W. M. Thomas, "Domain Analysis for the Reuse of Software Development Experiences", Proc. Of the I9th Annual Software Engineeríng Workshop, NASA/GSFC, Greenbelt, MD, diciembre de 1994. [B1N93] Binder, R., "Design for Reuse is for Real", en American Programmer, vol. 6, núm. 8, agosto de 1993, pp. 30-37. [BR0961 Brown, A. W., y K. C. Wallnau, "Engineeríng of Component-Based Systems", en Component-Based Software Engineeríng, IEEE Computer Society Press, 1996, pp. 7-15. (CHR951 Christensen, S. R„ "Software Reuse Initiatives at Lockheed", en CrossTalk, vol. 8, núm. 5, mayo de 1995, pp. 26-31. [CLE95J Clements, P. C., "From Subroutines to Subsystems: Component-Based Software Development", en American Programmer, vol. 8, núm. 11, noviembre de 1995. |DOG03] Dogru, A., y M. Tanik, "A Process Model for Component-Oriented Software Engineeríng", en IEEE Software, vol. 20, núm. 2, marzo-abril 2003, pp. 34-41. [FIS00] Fischer, B„ "Specification-Based Browsing of Software Component Libraries", en ). Automated Software Engineeríng, vol. 7, núm. 2, 2000, pp. 179-200, disponible en http://ase.arc.nasa.gov/people/fischer/papers/ase-00.html. [FRA94) Frakes, W. B., yT. P. Pole, "An Empirical Study of Representation Methods for Reusable Software Components", en IEEE Trans. Software Engineeríng, vol. SE-20, núm. 8, agosto de 1994, pp. 617-630. [HEI01] Heineman, G., y W. Councill (eds ), Component-Based Software Engineeríng, AddisonWesley, 2001. [HEN95J Henry, E„ y B. Faller, "Large Scale Industrial Reuse to Reduce Cost and Cycle Time", en IEEE Software, septiembre de 1995, pp. 47-53. [HUT881 Hutchinson, J. W., y P. G. Hindley, "A Preliminary Study of Large Scale Software Reuse", en Software Engineeríng Journal, vol. 3, núm. 5, 1988, pp. 208-212. [LIA93] Liao, H., y Wang, F., "Software Reuse Based on a Large Object-Oriented Library", en ACM Software Engineeríng Notes, vol. 18, núm. 1, enero de 1993, pp. 74-80. [L1M941 Lim, W. C., "Effects of Reuse on Quality, Productívity, and Economics", en IEEE Software, septiembre de 1994, pp. 23-30. |LIN95] Linthicum, D. S„ "Component Development (a Special Feature)", Application DevelopTM ment TYends, junio de 1995, pp. 57-78. (LUC01] deLucena, Jr., V., "Facet-Based Classification Scheme for Industrial Software Components", 2001, se puede descargar de http://research.microsoft.com/users/cszypers/events/WCOP2001 /Lucena.pdf [MCM95] McMahon, P. E., "Pattem-Based Architecture: Bridging Software Reuse and Cost Management", en Crosstalk, vol. 8. núrr 3, marzo de 1995, pp. 10-16. [ORF96] Orfali, R., D. HarkeyyJ. Edwards. The Essenüal Distributed Objects Survival Guide, Wiley, 1996. [PR193] Prieto-Díaz, R., "Issues and Exper.ences ¡n Software Reuse", en American Programmer, vol. 6, núm. 8, agosto de 1994, pp 67-68

PDF Editor

900

PARTE C I N C O


|POL94] Pollak, W. y M. Rissman, "Structural Models and Patterned Architectures", en Computer vol. 27, núm. 8, agosto de 1994, pp.67-68. [STA94] Staringer, W., "Constructing Applications from Reusable Components", en IEEE Software, septiembre de 1994, pp. 61-68. 1TRA90] Tracz, W., "Where Does Reuse Start?", Proc. Realities ofReuse Workshop, Syracuse Un versity CASE Center, enero de 1990. [TRA951 Tracz, W., "Third International Conference on Software Reuse-Summary", en ACM Software Engineering Notes, vol. 20, núm. 2, abril de 1995, pp. 21-22. [WH195] Whittle, B., "Models and Languages for Component Description and Reuse", en ACM Software Engineering Notes, vol. 20, núm. 2, abril de 1995, pp. 76-89. [YOU98] Yourdon, E.
30.1. Uno de los obstáculos clave para la reutilización consiste en hacer que los desarrolladores de software consideren la reutilización de componentes existentes en lugar de reinventar unos nuevos (después de todo, ¡construir cosas es divertido!). Sugerir de tres a cuatro formas diferentes en que una organización de software puede ofrecer incentivos para que los ingenieros de software empleen la reutilización. ¿Qué tecnologías deben existir para apoyar el esfuerzo de la re utilización? 30.2. Aunque los componentes de software son los "artefactos" reutilizables más obvios, se pueden reutilizar muchos otros productos de trabajo producidos como parte de la ingeniería del software. Considerar los planes de proyecto y las estimaciones de costo. ¿Cómo se pueden reutilizar y cuál es el beneficio de hacerlo? 30.3. investigúese un poco acerca de la ingeniería del dominio y detállese el modelo de proceso esbozado en la figura 30.1. Identifiqúense las tareas que se requieren para el análisis del dominio y el desarrollo arquitectónico del software. 30.4. ¿En qué son semejantes las funciones de caracterización para dominios de aplicación y los esquemas de clasificación de componentes? ¿En qué se diferencian? 30.5. Desarrollar un conjunto de características de dominio para sistemas de información que sean relevantes respecto al procesamiento de datos de estudiantes de una universidad. 30.6. Desarrollar un conjunto de características de dominio que sean relevantes para un software de procesamiento de textos y publicación. 30.7. Desarrollar un modelo estructural simple para un dominio de aplicación que asigne individualmente el instructor o uno con el cual se esté familiarizado. 30.8. ¿Qué es un punto de estructura? 30.9. Adquirir información acerca del más reciente estándar CORBA, COM o JavaBeans y elaborar un ensayo de tres a cinco páginas que aborde sus principales atributos. Obtener información acerca de una herramienta de distribución de solicitudes de objetos e ilustrar cómo la herraTM mienta se ajusta al estándar. Desarrollar una clasificación enumerada para un dominio de aplicación que asigne el instructor o uno con el que se esté familiarizado. 30.10.

PDF Editor

Desarrollar un esquema de clasificación por facetas para un dominio de aplicación que asigne el instructor o uno con el que se esté familiarizado. 30.11.

3 0 . 1 2 . Investigúese en la bibliografía para obtener datos recientes de calidad y productividad que apoyen el uso de la 1SBC. Preséntense los datos a la clase.

CAPÍTULO 30

901


En años recientes se han publicado muchos libros acerca del desarrollo basado en componentes y la reutilización de éstos. Heineman y Councill [HEI01 ], Brown (Large Scale Component-Based Development, Prentice-Hall, 2000), Alien (Realizing e-Business with Components, Addison-Wesley, 2000), Herzum y Sims (Business Component Factory, Wiley, 1999) y Alien, Frost y Yourdon (Component-Based Development for Enterprise Systems: Applying the Select Perspective, Cambridge University Press, 1998) cubren todos los aspectos importantes del proceso de ISBC. Apperly y sus colegas (Service- and Component-Based Development, Addison-Wesley, 2003), Atkinson [ATK01] y Cheesman y Daniels ( J M L Components, Addison-Wesley, 2000) examinan la ISBC poniendo especial cuidado en UML. Leach (Software Reuse: Methods, Models, and Costs, McGraw-Hill, 1997) proporciona un análisis detallado de los conflictos de costo asociados con la ISBC y la reutilización. Poulin (Measuring Software Reuse: Principies, Practices, and Economic Models, Addison-Wesley, 1996) sugieren algunos métodos cuantitativos para valorar los beneficios de la reutilización de software. En años recientes se han publicado docenas de libros que describen los estándares basados en componentes de la industria. En ellos se abordan las funciones internas de los estándares mismos, pero también consideran muchos tópicos importantes de la ISBC. A continuación se presenta una muestra de los tres estándares estudiados en este capitulo: CORBA

Bolton, F., Puré CORBA, Sams Publishing, 2001. Doss, G. M., CORBA Networking With Java, Wordware Publishing, 1999. Hoque, R„ CORBA for Real Programmers, Academic Press/Morgan Kaufmann, 1999. S i e g e l , C O R B A Fundamentáis and Programming, Wiley, 1999. Slama, D., J. Garbis y P. Russell, Enterprise CORBA, Prentice-Hall, 1999. COM

Box, D., K. Brown, T. Ewald y C. Sells, Effective COM: 50 Ways to Improve YourCOM- and MTSBased Applications, Addison-Wesley, 1999. Gordon, A., The COM and COM+ Programming Primer, Prentice-Hall, 2000. Kirtland, M., Designing Component-Based Applications, Microsoft Press, 1999. Tapadiya, P., COAÍ+ Programming, Prentice-Hall, 2000. Muchas organizaciones aplican una combinación de estándares de componentes. Los libros de Geraghty y sus colegas [COM-CORBA Interoperability, Prentice-Hall, 1999), Pritchard (COM and CORBA Side by Side: Architectures, Strategies, and Implementations, Addison-Wesley, 1999), y Rosen y sus colegas (Integrating CORBA y COM Applications, Wiley, 1999) consideran los conflictos asociados con el uso tanto de CORBA como de COM como la base para el desarrollo basado en componentes. JavaBeans

Asbury, S., y S. R. Weiner, Developing Java Enterprise Applications, Wiley, 1999. Anderson, G., y P. Anderson, Enterprise Javabeans Component Architecture, Prentice-Hall, 2002.

TM

Monson-Haefel, R., Enterprise Javabeans, tercera edición, O'Reilly & Associates, 2001. Román, E., etal., Mastering Enterprise Javabeans, 2a. ed., Wiley, 2001. En Internet hay disponible una amplia variedad de fuentes de información acerca de la ingeniería del software basada en componentes. Una lista actualizada de referencias en la World Wide Web se puede encontrar en el sitio Web SEPA http://www.mhhe.com/pressmaii.

PDF Editor

C A P I T U L O

^

31

CONCEPTOS CLAVE análisis de inventarios... .909 arquitecturas c/s

920

arquitecturas 00

921

economía

923

REINGENIERÍA

E

n u n r e l e v a n t e a r t í c u l o p u b l i c a d o e n la Harvard Business Review, Michael H a m m e r [HAM90] s e n t ó l a s b a s e s p a r a u n a r e v o l u c i ó n e n el 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 los p r o c e s o s d e n e g o c i o s y la c o m p u t a c i ó n :

Es el momento de dejar de pavimentar los senderos para vacas. En lugar de incrustar procesos anticuados en silicio y software, debemos eliminarlos y comenzar de nuevo. Debemos someter a "reingeniería" nuestros negocios: usar el poder de las modernas tecnologías de la información para rediseñar radicalmente nuestros pro cesos de negocios con la finalidad de alcanzar mejoras radicales en su desempeño. Cualquier compañía opera de acuerdo con una gran cantidad de reglas desarticu-

ingeniería directa

918

ingeniería inversa

ladas... La reingeniería lucha por separarse de las viejas reglas acerca de cómo organizar y dirigir nuestros negocios.

912

Al igual q u e t o d a s las revoluciones, el l l a m a d o a las a r m a s de H a m m e r g e n e r ó

mantenimiento .906

c a m b i o s p o s i t i v o s y n e g a t i v o s . D u r a n t e el d e c e n i o d e 1990, a l g u n a s c o m p a ñ í a s

modelo de proceso RPN...903

a p l i c a r o n u n e s f u e r z o l egí t i m o e n la r e a l i z a c i ó n d e r e i n g e n i e r í a , y los r e s u l t a d o s

proceso de reingeniería . . .908

e n el r e d i m e n s i o n a m i e n t o y la s u b c o n t r a t a c i ó n (en l u g a r d e la reíngeniería) p a r a

reestructuración 916

c o n p o c o p o t e n c i a l p a r a un c r e c i m i e n t o f u t u r o [DEM95].

reestructuro de datos

g e n i e r í a h a d e c a í d o , p e r o el p r o c e s o e n sí c o n t i n ú a e n c o m p a ñ í a s g r a n d e s y

las c o n d u j e r o n a m e j o r a r s u c o m p e t i t i v i d a d . O t r a s se a p o y a r o n e x c l u s i v a m e n t e m e j o r a r s u s l í n e a s b a s e ; p o r lo t a n t o , c o n f r e c u e n c i a r e s u l t a r o n o r g a n i z a c i o n e s D u r a n t e e s t a p r i m e r a d é c a d a del siglo xxi, la p r o m o c i ó n e x a g e r a d a d e la rein-

.917

p e q u e ñ a s . Los n e x o s e n t r e la r e i n g e n i e r í a de n e g o c i o s e i n g e n i e r í a del s o f t w a r e se e n c u e n t r a n e n u n a revisión d e s i s t e m a .

M

¿ Q u é e s ? Considere cualquier producto tecnológico que le haya servido bien. Usted lo utiliza regularmente, pero se está volviendo obsoleto. Se rompe con mucha frecuencia, su reparación toma más tiempo del que usted quisiera, y ya no representa más la nueva tecnología. ¿Qué hacer? Si el producto es hardware, probablemente usted lo tirará a la basura y comprará un modelo más nuevo. Pero si es software personalizado, dicha opción tal vez no esté disponible. Necesitará reconstruirlo. Creará un pro: . n o con una mejor funcionalidad, mejor desemV

peño y fiabilidad, así como una mejor facilidad d e mantenimiento. A eso se le llama reingeniería.

¿ Q u i é n la h a c e ? En el ámbito de las organizaciones, la reingeniería la llevan a c a b o especialistas en negocios (con frecuencia compañías consultoTM ras). En el ámbito del software la reingeniería la realizan los ingenieros d e software.

PDF Editor

¿Por q u é e s importante? Se vive en un mundo en cambio constante, tas d e m a n d a s acerca d e las funciones d e negocios y la tecnología d e la información que ios soportan están cambiando a un ritmo q u e impone una enorme presión competitiva en las

CAPÍTULO 3 1

903

REINGENIERÍA

organizaciones comerciales. Tanto el negocio como

¿Cuál e s el producto o b t e n i d o ? Se produce una

el software que soporta (o es) el negocio d e b e rediseñarse p a r a mantener el ritmo.

diversidad d e productos d e trabajo d e reingeniería

¿Cuáles s o n los p a s o s ? La reingeniería de proce-

ño, procedimientos d e prueba). El resultado final es Un p r o c e s o d e reíngeniería d e negocios o el software d e reingeniería que b soporta.

sos d e negocio (RPN) define las metas del negocio,

(por ejemplo, modelos d e análisis, modelos d e dise-

identifica y evalúa los procesos vigentes del negocio, y crea procesos d e negocios renovados que

¿Cómo puedo estar seguro de que lo he

cumplen mejor las metas actuales El proceso d e

h e c h o correctamente? Utilice las mismas prácti-

reingeniería d e software incluye análisis d e inventa-

c a s d e SQA que se aplican o cualquier procesa d e

rios, reestructuración d e documentos,

ingeniería del software: las revisiones técnicas formales evalúan los modelos d e análisis y d e diseño;

ingeniería

inversa, reestructuración de programas y datos, e ingeniería a v a n z a d a . La finalidad d e estas activida-

las revisiones especializadas consideran la aplica-

des es crear versiones d e programas existentes que

bifidad y ia compatibilidad en el negocio; y las prue-

muestren mayor calidad y mejor facilidad d e man-

b a s se aplican p a r a descubrir errores en contenido,

tenimiento.

funcionalidad e interoperabilidad.

\ CLAVE Lo RPN con frecuencia genera uno nueva funcionalidad de software, mientras que la reingeniería del software trabaja para reemplazor la funcionalidad del software existente con un mejor software y d e mayor facilidod de mantenimiento.

31.1

U s u a l m e n t e el s o f t w a r e e s la r e a l i z a c i ó n d e l a s r e g l a s del n e g o c i o q u e H a m m e r d e s c r i b e . C o n f o r m e c a m b i e n d i c h a s reglas, el s o f t w a r e t a m b i é n d e b e h a c e r l o . En la actualidad, las g r a n d e s c o m p a ñ í a s t i e n e n d e c e n a s d e m i l e s de 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 a p o y a n a las viejas reglas del negocio. A m e d i d a q u e los a d m i n i s t r a d o r e s t r a b a j e n e n la modificación d e las r e g l a s y logren m a y o r e s efectividad y competitivid a d , el s o f t w a r e d e b e m a n t e n e r el ritmo. En a l g u n o s c a s o s , e s t o implica la c r e a c i ó n d e m a y o r e s y n u e v o s s i s t e m a s b a s a d o s e n c o m p u t a d o r a . 1 Pero, e n m u c h o s o t r o s , significa la m o d i f i c a c i ó n o r e c o n s t r u c c i ó n d e l a s a p l i c a c i o n e s e x i s t e n t e s . En e s t e c a p í t u l o s e e x a m i n a la r e i n g e n i e r í a e n f o r m a d e s c e n d e n t e , c o m e n z a n d o c o n un b r e v e p a n o r a m a de la r e i n g e n i e r í a de p r o c e s o s d e n e g o c i o y d e s p u é s s e a b o r d a n c o n m a y o r detalle l a s a c t i v i d a d e s t é c n i c a s q u e s e llevan a c a b o al r e a l i z a r la r e i n g e n i e r í a del s o f t w a r e .

REÍNGENIERÍA PE PROCESOS PE

NESQCIP

La r e i n g e n i e r í a d e p r o c e s o s d e n e g o c i o (RPN) r e b a s a el á m b i t o d e las t e c n o l o g í a s d e la i n f o r m a c i ó n y d e la ingeniería del s o f t w a r e . Entre l a s m u c h a s d e f i n i c i o n e s (la m a y o r í a u n t a n t o a b s t r a c t a ) s u g e r i d a s p a r a la RPN d e s t a c a u n a p u b lTM i c a d a e n la revista Fortune [STE93]: "La b ú s q u e d a e i m p l e m e n t a c i ó n d e u n c a m b i o radical e n el p r o c e s o d e n e g o c i o s p a r a lograr r e s u l t a d o s de v a n g u a r d i a " . Pero, ¿ c ó m o se lleva a c a b o

PDF Editor

la b ú s q u e d a y c ó m o s e logra la i m p l e m e n t a c i ó n ? M á s i m p o r t a n t e a ú n , ¿ c ó m o s e p u e d e g a r a n t i z a r q u e el " c a m b i o radical" s u g e r i d o c o n d u c i r á a " r e s u l t a d o s d e v a n guardia" e n lugar de c a o s organizacional? I

La explosión de aplicaciones y sistemas basados en Web estudiados en la parte 3 de este libro es un indicio de esta tendencia.

904

PARTE C I N C O


"Enfrentar el m a ñ a n o con la ideo de emplear los métodos de ayer es visualizar la vido t o m o una parálisis." J a m e s Bell

31.1.1

Procesos d e negocios

Un p r o c e s o d e n e g o c i o e s "un c o n j u n t o d e t a r e a s l ó g i c a m e n t e r e l a c i o n a d a s q u e s e e j e c u t a n p a r a lograr u n r e s u l t a d o d e n e g o c i o s específico" [DAV90]. D e n t r o del p r o c e s o d e n e g o c i o , la g e n t e , el e q u i p o , l o s r e c u r s o s m a t e r i a l e s y l o s p r o c e d i m i e n t o s del n e g o c i o s e c o m b i n a n p a r a p r o d u c i r un r e s u l t a d o e s p e c í f i c o . Los e j e m p l o s d e p r o c e s o s d e n e g o c i o s incluyen el d i s e ñ o d e u n n u e v o p r o d u c t o , la c o m p r a d e s e r v i c i o s y s u m i n i s t r o s , la c o n t r a t a c i ó n d e u n n u e v o e m p l e a d o y el p a g o a p r o v e e d o r e s . C a d a u n o d e m a n d a u n c o n j u n t o d e t a r e a s y t a m b i é n e m p l e a d i v e r s o s r e c u r s o s d e n t r o del negocio. C a d a p r o c e s o d e n e g o c i o tiene u n cliente definido: u n a p e r s o n a o g r u p o q u e recib e el r e s u l t a d o (por e j e m p l o , u n a i d e a , u n i n f o r m e , u n d i s e ñ o , u n p r o d u c t o ) . A d e m á s , ÔNSEJO^

los p r o c e s o s d e n e g o c i o s t r a s p a s a n las f r o n t e r a s d e la o r g a n i z a c i ó n . Esto r e q u i e r e q u e d i f e r e n t e s g r u p o s d e o r g a n i z a c i o n e s p a r t i c i p e n en l a s " t a r e a s l ó g i c a m e n t e rela-

Como ingenieio de softwote, su trabajo lo desempeño en lo base de esto jerarquía. Sin embargo, asegúrese de que alguien ha pensado seriamente en los niveles superiores. Si esto no ha ocurrido, su trobojo

esiú en nesgo.

c i o n a d a s " q u e d e f i n e n el p r o c e s o . En el c a p í t u l o 6 s e i n d i c ó q u e t o d o s i s t e m a e s e n realidad u n a jerarquía de s u b s i s t e m a s . Un n e g o c i o n o e s la e x c e p c i ó n . C a d a s i s t e m a d e n e g o c i o ( t a m b i é n l l a m a do una función negocio) está c o m p u e s t o de u n o o m á s procesos de negocio, y a cada p r o c e s o d e n e g o c i o lo d e f i n e u n c o n j u n t o de s u b p r o c e s o s . La RPN s e p u e d e a p l i c a r e n c u a l q u i e r nivel d e la j e r a r q u í a , p e r o c o n f o r m e s e amplía su ámbito (es decir, c o n f o r m e u n o s e m u e v e hacia arriba en la jerarquía) los riesg o s a s o c i a d o s c o n ello c r e c e n s u s t a n c i a l m e n t e . Por e s t a r a z ó n , la m a y o r í a de los e s f u e r z o s de la RPN s e e n f o c a e n p r o c e s o s individuales o s u b p r o c e s o s . "Tan pronto se nos presento algo viejo en una cosa nueva, nos tranquilizamos." F. W. N i e t z s c h e

Referencia Web

Araplja infcímottón acerco de la RPff se puede encontrar en www.brinl.com/ BPR.htm.

31.1.2

Un modelo d e RPN

C o m o la m a y o r í a d e las a c t i v i d a d e s d e ingeniería, la r e i n g e n i e r í a d e p r o c e s o s de n e g o c i o e s iterativa. Las m e t a s del n e g o c i o y l o s p r o c e s o s c o n q u e se l o g r a n s e d e b e n a d a p t a r a u n e n t o r n o d e n e g o c i o s c a m b i a n t e . Por e s t a r a z ó n n o existe princip i o ni fin p a r a la RPN: s e t r a t a de u n p r o c e s o evolutivo. En la figura 31.1 s e m u e s t r a u n m o d e l o d e r e i n g e n i e r í a d e p r o c e s o s d e n e g o c i o . El m o d e l o d e f i n e s e i s a c t i v i d a des.

TM

D e f i n i c i ó n d e l n e g o c i o . Las m e t a s del n e g o c i o s e i d e n t i f i c a n d e n l e el c o n t e x t o

PDF Editor

de c u a t r o c o n t r o l a d o r e s clave: r e d u c c i ó n d e c o s t o , r e d u c c i ó n d e t i e m p o s , m e j o r a de la c a l i d a d y d e s a r r o l l o y f o r t a l e c i m i e n t o del p e r s o n a l . Es p o s i b l e definir las m e t a s al nivel del n e g o c i o o r e s p e c t o de u n c o m p o n e n t e e s p e c í f i c o del n e g o c i o . I d e n t i f i c a c i ó n d e l p r o c e s o . S e identifican los p r o c e s o s c r u c i a l e s p a r a lograr l a s

m e t a s p r e c i s a d a s e n la defi ni ci ón del n e g o c i o . L u e g o p o d r í a c l a s i f i c a r s e d e a c u e r d o

CAPITULO 3 1

905

REINGENIERÍA

con su importancia, necesidad de c a m b i o o en cualquier otra forma que sea a d e c u a d a para la actividad de reingeniería. E v a l u a c i ó n del p r o c e s o .

El proceso existente se analiza y mide exhaustiva-

mente. Se identifican las tareas del proceso; se anotan los costos y el tiempo que cons u m e n las tareas del proceso; y se aislan los problemas de calidad y d e s e m p e ñ o . Especificación y diseño del proceso.

Con b a s e en la retroalimentación obte-

nida durante las primeras tres actividades de la RPN, se preparan c a s o s de uso (capítulo 7) para cada p r o c e s o q u e será rediseñado. En del contexto de la RPN los c a s o s de uso identifican un escenario que entrega cierto resultado a un cliente. Con el cas de uso c o m o la especificación del p r o c e s o se diseña un n u e v o conjunto de tareas para el proceso. Elaboración d e prototipos.

Un proceso de negocio rediseñado d e b e conver-

tirse en prototipo a n t e s de que sea integrado por completo e n el negocio. Esta actividad "prueba" el proceso de m o d o que puedan llevarse a cabo refinamientos. R e f i n a m i e n t o y particularización.

Con b a s e en la retroalimentación del pro-

totipo, el proceso de negocio se refina y luego se particulariza dentro de un sistema de negocio. En ocasiones, estas actividades de RPN se utilizan junto con las h e r r a m i e n t a s de análisis de flujo de trabajo. La finalidad de e s t a s herramientas es elaborar un modelo de flujo de trabajo práctico, esfuerzo e n c a m i n a d o a analizar mejor los procesos existentes. Además, para implementar las primeras cuatro actividades descritas e n el m o d e l o de proceso se p u e d e n aplicar las técnicas de m o d e l a d o u s u a l m e n t e asociadas con las actividades de ingeniería de procesos de negocio (capítulo 6).

Modelo de RPN.

Definición del

TM

PDF Editor

906

PARTE C I N C O



Reingeniería d e procesos d e n e g o c i o (RPN) Objetivo: El objetivo de las herramientas de la RPN es apoyar el análisis y la evaluación de los procesos de negocio existentes y la especificación y el diseño de unos nuevos. M e c á n i c a : La mecánica de las herramientas varía. En general, las herramientas de la RPN permiten que un analista de negocios modele los procesos de negocio existentes en un esfuerzo destinado a evaluar las ineficiencias del flujo de trabajo o problemas funcionales. Una vez que se identifican los problemas existentes las herramientas permiten que los analistas elaboren prototipos o simulen procesos de negocio revisados. Herramientas representativas2 Extend, desarrollada por ImagineThat, Inc. (vAvw.imaginethatinc.com), es una herramienta de simulación para el modelado de procesos existentes y la exploración de unos nuevos. Extend proporciona una extensa capacidad "si... entonces" que permite que un analista de negocios explore diferentes escenarios , de proceso,

e-Work, desarrollado por Mefastorm (www.metastorm.com), apoya la gestión d e procesos de negocios en procesos manuales y automatizados. IceTools, desarrolladas por Blue Ice (www.blueice.com), es una colección de plantillas de RPN para Microsoft Office y Microsoft Project. SpeeDev, desarrollada por NimbleStar Group (www.nimblestar.com), es una de muchas herramientas que permiten que una organización modele flujos de trabajo de procesos (en este caso, flujo de trabajo de TI). Workflow tools, desarrolladas por MetaSoftware (www.metasoftware.com), incorpora un conjunto de herramientas para modelado, simulación y calendarización del flujo de trabajo. Una lista útil de vínculos a herramientas de RPN se puede encontrar en http://www.donaldfiresmith.com/Components/Producers/Tools/BusinessProce ssReengineeringTools.html.

El e s c e n a r i o e s l a n c o m ú n : u n a a p l i c a c i ó n h a c u b i e r t o l a s n e c e s i d a d e s d e n e g o c i o s d e u n a c o m p a ñ í a d u r a n t e 10 o 15 a ñ o s . D u r a n t e e s e l a p s o s e h a c o r r e g i d o , a d a p t a d o y m e j o r a d o m u c h a s v e c e s . El p e r s o n a l e n f r e n t ó e s t e t r a b a j o c o n l a s m e j o r e s i n t e n c i o n e s , p e r o l a s b u e n a s p r á c t i c a s d e i n g e n i e r í a del s o f t w a r e s i e m p r e f u e r o n s o s l a y a d a s ( d e b i d o a la p r e s i ó n d e o t r o s a s u n t o s i m p o r t a n t e s ) . A h o r a l a a p l i c a c i ó n es inestable. Todavía funciona pero, cada vez q u e se intenta un cambio, ocurren e f e c t o s c o l a t e r a l e s , i n e s p e r a d o s y s e r i o s . Y la a p l i c a c i ó n t o d a v í a t i e n e q u e e v o l u c i o nar. ¿Qué hacer? El s o f t w a r e al c u a l n o s e le p u e d e d a r m a n t e n i m i e n t o n o e s u n p r o b l e m a n u e v o . D e h e c h o , la i m p o r t a n c i a c a d a v e z m a y o r q u e s e le c o n c e d e a la r e i n g e n i e r í a d e l s o f t -

TM

w a r e la h a n i m p u l s a d o l o s p r o b l e m a s e n el m a n t e n i m i e n t o del s o f t w a r e q u e h a n i d o creciendo durante m á s de 40 años.

PDF Editor 2

Las herramientas expuestas el autor no las respalda; sólo representan una muestra de las herramientas incluidas en esta categoría. En la mayoría de los casos, los nombres de las herramientas son marcas registradas por sus respectivos desarrolladores.

CAPÍTULO 31

31.2.1

907

REINGENIERIA

Mantenimiento del software

D u r a n t e l a s t r e s d é c a d a s p a s a d a s el m a n t e n i m i e n t o del s o f t w a r e s e c a r a c t e r i z ó [CAN72] c o m o u n "iceberg". Se e s p e r a b a q u e lo i n m e d i a t a m e n t e visible f u e s e t o d o lo q u e h a b í a , p e r o s e s a b í a q u e b a j o la s u p e r f i c i e s e e n c o n t r a b a u n a e n o r m e m a s a d e p r o b l e m a s y c o s t o s p o t e n c i a l e s . A p r i n c i p i o s del d e c e n i o d e 1970, el m a n t e n i m i e n t o del i c e b e r g e r a s u f i c i e n t e m e n t e g r a n d e c o m o p a r a h u n d i r u n p o r t a a v i o n e s . En la a c t u a l i d a d , ¡ f á c i l m e n t e p o d r í a h u n d i r a t o d a la m a r i n a ! El m a n t e n i m i e n t o del s o f t w a r e e x i s t e n t e explica c a s i el 6 0 p o r c i e n t o del e s f u e r z o q u e e m p l e a u n a o r g a n i z a c i ó n d e d e s a r r o l l o , y el p o r c e n t a j e c o n t i n ú a e l e v á n d o s e c o n f o r m e s e p r o d u c e m á s s o f t w a r e (HAN93], Los l e c t o r e s c o n e s c a s o s c o n o c i m i e n t o s s o b r e el t e m a p o d r í a n p r e g u n t a r s e p o r q u é se r e q u i e r e t a n t o m a n t e n i m i e n t o y por q u é s e d e d i c a t a n t o e s f u e r z o . O s b o r n e y Chikofsky [C>SB90] o f r e c e n u n a r e s p u e s t a parcial: Gran parte del software del que dependemos en la actualidad tiene en promedio de 10 a 15 años de antigüedad. Aun cuando dichos programas se crearon empleando las mejores técnicas de diseño y codificación conocidas en la época [y la mayoría no lo eran|, se crearon cuando el tamaño de los programas y el espacio de almacenamiento eran las principales preocupaciones. Entonces emigraron hacia nuevas plataformas, se ajustaron para adecuarlos a los cambios en las máquinas y a la tecnología de los sistemas operativos y aumentaron para satisfacer las necesidades de nuevos usuarios; todo se hizo sin considerar lo suficiente la arquitectura global. El resultado es estructuras mal diseñadas, codificación deficiente, lógica inadecuada y escasa documentación de los sistemas de software por los que ahora se nos llama para mantenerlos en operación... O t r a r a z ó n r e s p e c t o del p r o b l e m a del m a n t e n i m i e n t o del s o f t w a r e e s la m o v i l i d a d del p e r s o n a l . Es p r o b a b l e q u e el e q u i p o (o p e r s o n a ) d e s o f t w a r e q u e r e a l i z ó el trab a j o original y a n o e s t é . Peor a ú n , l a s g e n e r a c i o n e s s u b s e c u e n t e s d e p e r s o n a l h a n m o d i f i c a d o el s i s t e m a y lo h a n d a ñ a d o . En la a c t u a l i d a d , tai v e z n o h a y a n a d i e q u e t e n g a a l g ú n c o n o c i m i e n t o d i r e c t o del s i s t e m a h e r e d a d o . C o m o s e indicó e n el c a p í t u l o 27, la n a t u r a l e z a u b i c u a del c a m b i o s u b y a c e e n t o d o el t r a b a j o d e s o f t w a r e . El c a m b i o e s inevitable c u a n d o s e c o n s t r u y e n s i s t e m a s b a s a d o s en computadora; en consecuencia, se deben desarrollar mecanismos para evaluar, controlar y efectuar modificaciones. "ID facilidad de mantenimiento de los programos y la comprensibilidad d e los programas son conceptos paralelos: TM mientras m á s difícil sea comprender un programa, m á s difícil será su mantenimiento." Geraid Berns

PDF Editor

D e s p u é s d e l e e r los p á r r a f o s a n t e r i o r e s u n l e c t o r p o d r í a p r o t e s t a r : "Pero y o n o

p a s o el 6 0 p o r c i e n t o d e mi t i e m p o c o m p o n i e n d o e r r o r e s e n l o s p r o g r a m a s q u e d e sarrollo". D e s d e luego, el m a n t e n i m i e n t o del s o f t w a r e e s m u c h o m á s q u e " c o m p o n e r e r r o r e s " . Es posible definir el m a n t e n i m i e n t o d e s c r i b i e n d o c u a t r o a c t i v i d a d e s [SWA76] q u e s e r e a l i z a n d e s p u é s d e q u e u r p r o g r a m a e s liberado p a r a s u utilización.

908

PARTE C I N C O


El m a n t e n i m i e n t o del s o f t w a r e s e d e f i n e i d e n t i f i c a n d o c u a t r o a c t i v i d a d e s d i f e r e n t e s :

\ CLAVE El montenimiento del software incluye cuatro actividades: corrección de error, adoptación, mejora y reingenien'o.

m a n t e n i m i e n t o correctivo, m a n t e n i m i e n t o a d a p t a t i v o , m e j o r a o m a n t e n i m i e n t o de p e r f e c c i o n a m i e n t o y m a n t e n i m i e n t o p r e v e n t i v o o r e i n g e n i e r í a . S ó l o c e r c a del 2 0 p o r c i e n t o del t r a b a j o de m a n t e n i m i e n t o se e m p l e a e n " c o m p o n e r errores". El r e s t a n t e 8 0 p o r c i e n t o s e d e d i c a a a d a p t a r los s i s t e m a s e x i s t e n t e s a los c a m b i o s e n s u e n t o r n o e x t e r n o , r e a l i z a r l a s m e j o r a s q u e solicitan los u s u a r i o s y r e d i s e ñ a r u n a aplicación p a r a u s a r l a e n lo f u t u r o . Al c o n s i d e r a r q u e el m a n t e n i m i e n t o incluye t o d a s e s t a s activ i d a d e s e s r e l a t i v a m e n t e sencillo o b s e r v a r p o r q u é a b s o r b e t a n t o e s f u e r z o .

31.2.2 Referencia Web

Uno excelente fuente de información ocerco s o t a r e Sé puede encontrar en www. reengineering.net.

Un modelo d e procesos d e reingeniería del software

La r e i n g e n i e r í a r e q u i e r e t i e m p o , c u e s t a c a n t i d a d e s significativas de d i n e r o y a b s o r be r e c u r s o s q u e de o t r o m o d o s e o c u p a r í a n e n p r o b l e m a s i n m e d i a t o s . Por t o d a s e s t a s r a z o n e s la r e i n g e n i e r í a n o s e logra e n u n o s c u a n t o s m e s e s , ni s i q u i e r a e n u n o s c u a n t o s a ñ o s . La r e i n g e n i e r í a d e los s i s t e m a s d e i n f o r m a c i ó n e s u n a actividad q u e a b s o r b e r á r e c u r s o s d e la t e c n o l o g í a d e la i n f o r m a c i ó n d u r a n t e m u c h o s a ñ o s . Por t a n t o , t o d a o r g a n i z a c i ó n n e c e s i t a u n a e s t r a t e g i a p r a g m á t i c a r e s p e c t o de la r e i n g e niería del s o f t w a r e . El m o d e l o d e p r o c e s o d e r e i n g e n i e r í a incluye u n a e s t r a t e g i a o p e r a t i v a . El m o d e l o s e t r a t a r á m á s a d e l a n t e e n e s t a s e c c i ó n , p e r o p r i m e r o s e p r e s e n t a r á n a l g u n o s principios b á s i c o s . La r e i n g e n i e r í a e s u n a act i vi dad d e r e c o n s t r u c c i ó n , y la r e i n g e n i e r í a d e los sistem a s d e i n f o r m a c i ó n s e c o m p r e n d e m e j o r si se c o n s i d e r a u n a actividad a n á l o g a : la r e c o n s t r u c c i ó n de u n a c a s a . C o n s i d é r e s e la s i g u i e n t e s i t u a c i ó n . El lector c o m p r a u n a c a s a e n o t r o e s t a d o . En r e a l i d a d n u n c a h a visto la p r o p i e d a d , p e r o la a d q u i r i ó e n un p r e c i o s o r p r e n d e n t e m e n t e bajo, c o n la a d v e r t e n c i a d e q u e tal v e z t e n g a q u e r e c o n s t r u i r s e p o r c o m p l e t o . ¿ C ó m o s e p r o c e d e r í a ? • A n t e s de q u e s e p u e d a iniciar la r e c o n s t r u c c i ó n sería r a z o n a b l e i n s p e c c i o n a r la c a s a . D e t e r m i n a r si e s n e c e s a r i o r e c o n s t r u i r l a r e q u i e r e q u e el lector (o u n i n s p e c t o r p r o f e s i o n a l ) e l a b o r e u n a lista de criterios d e m o d o q u e la i n s p e c c i ó n resulte s i s t e m á t i c a . • A n t e s de tirar y reconstruir t o d a la c a s a s e d e b e t e n e r la c e r t e z a q u e la e s t r u c tura e s débil. Si la c a s a es e s t r u c t u r a l m e n t e sólida tal v e z s e a posible " r e m o d e larla" sin reconstruirla (a un c o s t o m u c h o m á s b a j o y e n m u c h o m e n o s tiempo). • A n t e s d e iniciar la r e c o n s t r u c c i ó n s e d e b e t e n e r la c e r t e z a deTM que se entiende c ó m o se c o n s t r u y ó la original. E c h e un v i s t a z o d e t r á s d e las p a r e d e s . E n t i e n d a el a l a m b r a d o , la p l o m e r í a y los c o m p o n e n t e s e s t r u c t u r a l e s . Incluso si s e tiran

PDF Editor

t o d o s a la b a s u r a , la c o m p r e n s i ó n q u e s e a d q u i e r a s e r á útil c u a n d o c o m i e n c e la c o n s t r u c c i ó n .

• Si s e c o m i e n z a a r e c o n s t r u i r s ó l o se u t i l i z a r á n los m a t e r i a l e s m á s m o d e r n o s y d e larga d u r a c i ó n . E s t o p u e d e c o s t a r u n p o c o m á s a h o r a , p e r o a y u d a r á a evitar u n m a n t e n i m i e n t o c o s t o s o y t a r d a d o m á s a d e l a n t e .

CAPITULO 31

REINGENIERIA

909

• Si s e d e c i d e r e c o n s t r u i r e s p r e c i s o d i s c i p l i n a r s e e n c u a n t o a ello. Utilícense p r á c t i c a s q u e r e d u n d a r á n e n alta c a l i d a d , h o y y m a ñ a n a . A u n q u e e s t o s principios s e e n f o c a n e n la r e c o n s t r u c c i ó n d e u n a c a s a , t a m b i é n s e aplican i g u a l m e n t e bien a la r e i n g e n i e r í a d e s i s t e m a s y a p l i c a c i o n e s b a s a d a s e n computadoras. La i m p l e m e n t a c i ó n de e s t o s principios r e q u i e r e a p l i c a r un m o d e l o d e p r o c e s o d e r e i n g e n i e r í a del s o f t w a r e q u e d e f i n e s e i s a c t i v i d a d e s , c o m o s e m u e s t r a e n la figura 31.2. En a l g u n o s c a s o s d i c h a s a c t i v i d a d e s o c u r r e n e n u n a s e c u e n c i a lineal, p e r o é s t e n o s i e m p r e e s el c a s o . Por e j e m p l o , tal v e z la i n g e n i e r í a i n v e r s a ( c o m p r e n d e r el f u n c i o n a m i e n t o i n t e r n o d e un p r o g r a m a ) t e n g a q u e o c u r r i r a n t e s d e q u e c o m i e n c e la reestructuración de documentos. El p a r a d i g m a d e r e i n g e n i e r í a q u e s e m u e s t r a e n la figura e s u n m o d e l o cíclico. Esto significa q u e c a d a u n a d e las a c t i v i d a d e s p r e s e n t a d a s c o m o p a r t e del p a r a d i g m a p u e d e n v o l v e r a visitarse. En a l g ú n ciclo p a r t i c u l a r el p r o c e s o q u i z á t e r m i n e d e s p u é s de c u a l q u i e r a d e d i c h a s a c t i v i d a d e s . Análisis de inventarios.

Las o r g a n i z a c i o n e s d e s o f t w a r e d e b e r í a n t e n e r u n i n v e n -

tario d e t o d a s s u s a p l i c a c i o n e s . El i n v e n t a r i o tal v e z n o s e a m á s q u e un m o d e l o e n una hoja de cálculo que contenga información que proporcione una descripción d e t a l l a d a (por e j e m p l o , t a m a ñ o , e d a d , i m p o r t a n c i a p a r a el n e g o c i o ) d e las a p l i c a c i o n e s activas. Al o r d e n a r e s t a i n f o r m a c i ó n — d e a c u e r d o c o n la i m p o r t a n c i a p a r a el n e g o c i o , a n t i g ü e d a d , facilidad a c t u a l d e m a n t e n i m i e n t o y o t r o s criterios l o c a l m e n t e i m p o r t a n t e s — a p a r e c e n los c a n d i d a t o s p a r a r e i n g e n i e r í a . E n t o n c e s s e p u e d e n asign a r los r e c u r s o s a las a p l i c a c i o n e s c a n d i d a t a s p a r a el t r a b a j o d e r e i n g e n i e r í a .

Modelo de proceso d e la reingeniería del software.

Reestructuración TM de documentos

PDF Editor

910

PARTE CINCO


Es importante señalar que el inventario deberá visitarse con regularidad. El estado

ÔNSEJO^^

de las aplicaciones (por ejemplo, importancia respecto del negocio) puede cambiar

Si el tiempo y los temos escasean, puede considerar la aplicación del principio de Poreto al software que será sometido a ingeniería. Aplique el proceso de reingeniería al 20 por ciento del software que explica el 80 por ciento de los problemas.

en función del tiempo y, c o m o resultado, cambiarán las prioridades para la reinge-

^ÔNSEJO^^

niería. Reestructuración d e documentos.

La documentación débil es la marca de mu-

chos s i s t e m a s heredados. ¿Pero qué se h a c e acerca de ello? ¿Cuáles son las opciones? 1.

Crear

documentación

consume

muchísimo

tiempo.

Si el sistema funciona vivirá

con lo que se tenga. En algunos c a s o s é s t e es el e n f o q u e correcto. No es posible recrear documentación para cientos de p r o g r a m a s de c o m p u t a d o r a . Si un programa es relativamente estático está llegando al final de su vida útil, por lo que es improbable que experimente un cambio significativo, ¡déjelo ser! 2 . La documentación

debe

actualizarse,

pero se tienen

recursos

limitados.

Se utili-

zará un enfoque de " d o c u m e n t ar c u a n d o se toque". Tal vez sea innecesario volver a d o c u m e n t a r por completo la aplicación. En cambio, se d o c u m e n t a n

Cree solamente tanta documentación como necesite para entender el software, ni una página mús.

c o m p l e t a m e n t e aquellas porciones del sistema que en la actualidad experim e n t a n cambios. Con el tiempo evolucionará u n a colección de d o c u m e n t a ción útil y relevante. 3.

El sistema

es crucial

para

el negocio

y debe

volver

a documentarse

por completo.

Incluso en este c a s o un enfoque inteligente e s recortar la documentación a un mínimo esencial. Cada una de estas opciones es viable. Una organización de s o f t w a r e d e b e elegir la m á s apropiada para cada caso.

Ingeniería i n v e r s a . El término ingeniería inversa tiene sus orígenes en el m u n d o del hardware. Una c o m p a ñ í a d e s e n s a m b l a un producto de h a r d w a r e de un competidor con la finalidad de c o m p r e n d e r sus "secretos" de diseño y fabricación. Tales secretos podrían c o m p r e n d e r s e fácilmente si se obtuviesen las especificaciones de diseño y fabricación del competidor. Pero dichos d o c u m e n t o s están p a t e n t a d o s y no están disponibles para la c o m p a ñ í a que realiza la ingeniería inversa. En esencia, la ingeniería inversa exitosa obtiene u n a o m á s especificaciones de diseño y fabricación para un producto c u a n d o se e x a m i n a n e s p e c í m e n e s reales del producto. TM La ingeniería inversa para el s o f t w a r e es b a s t a n t e similar. Sin embargo, en a m b o s c a s o s el programa objeto de la ingeniería inversa no es el de un competidor, sino el trabajo de la propia c o m p a ñ í a (con frecuencia elaborado m u c h o s a ñ o s atrás). Los

PDF Editor

"secretos" que se c o m p r e n d a n serán oscuros, pues n u n c a se desarrolló u n a especificación. Por lo tanto, la ingeniería inversa del s o f t w a r e es el proceso de analizar un programa con la finalidad de crear u n a representación del p r o g r a m a en un mayor grado de abstracción que el código fuente. La ingeniería inversa es un proceso de recuperación de diseño. Las h e r r a m i e n t a s de la ingeniería inversa obtienen infor-

CAPÍTULO 31

Referencia Web

pota lo

obtener en www.tomp.lancs. ac.uk/projetts/ RenaissnnceWeb/.

911

REINGENIER1A

mación del diseño de datos, arquitectónico y de procedimientos a partir de un p r o grama existente. Reestructuración de código.

El tipo m á s c o m ú n de reingeniería (en realidad, e n

e s t e c a s o el e m p l e o del término reingeniería es cuestionable) es la reestructuración de código.-' Algunos sistemas h e r e d a d o s tienen una arquitectura de p r o g r a m a relativamente sólida, p e r o los módulos individuales se codificaron e n una forma q u e dificulta comprenderlos, probarlos y mantenerlos. En tales c a s o s se p u e d e reestructurar el código d e n t r o de los m ó d u l o s s o s p e c h o s o s . Llevar a c a b o esta actividad requiere analizar el código fuente e m p l e a n d o una herramienta de reestructuración. Se indican las violaciones de las estructuras de programación estructurada y e n t o n c e s el código se reestructura (esto se p u e d e hacer automáticamente). El código reestructurado resultante se revisa y prueba para garantizar que no se h a n introducido anormalidades. La documentación del código interno se actualiza. Reestructuración de datos.

Un p r o g r a m a con u n a arquitectura de d a t o s débil

será difícil de a d a p t a r y mejorar. De hecho, en m u c h a s aplicaciones la arquitectura de d a t o s está m á s relacionada con la viabilidad a largo plazo de un p r o g r a m a que el código fuente. A diferencia de la reestructuración de código, que ocurre en un grado relativam e n t e b a j o de abstracción, la reestructuración de d a t o s e s u n a actividad de reingeniería a gran escala. En la mayoría de los casos, la reestructuración de d a t o s c o m i e n z a con una actividad de ingeniería inversa. La arquitectura de datos actual se analiza con minuciosidad y se definen los modelos de d a t o s necesarios (capítulo 9). Se identifican los objetos de d a t o s y los atributos, y d e s p u é s se revisa la calidad de las estructuras de d a t o s existentes. C u a n d o la estructura de d a t o s e s débil (por ejemplo, a c t u a l m e n t e se implementan archivos planos, c u a n d o un enfoque relacional simplificaría e n o r m e m e n t e el procesamiento), los d a t o s se s o m e t e n a reingeniería. Puesto que la arquitectura de d a t o s tiene una fuerte influencia sobre la arquitectura del p r o g r a m a y los algoritmos que lo pueblan, los c a m b i o s a los d a t o s invariablemente resultarán e n cambios arquitectónicos o al nivel de código. Ingeniería d i r e c t a .

En un m u n d o ideal, las aplicaciones se reconstruirían e m p l e -

a n d o un "motor d e reingeniería" automatizado. El p r o g r a m a antiguo sería insertado e n el motor, analizado, reestructurado y luego r e g e n e r a d o en una TM forma que exhibiese los m e j o r e s aspectos de la calidad del software. A corto plazo e s improbable q u e tal "motor" aparezca, p e r o las e m p r e s a s h a n introducido h e r r a m i e n t a s q u e

PDF Editor

mejoran un limitado s u b c o n j u n t o de dichas capacidades que aborden dominios de aplicación específicos (por ejemplo, las aplicaciones que se implementan m e d i a n t e

3 La reestructuración de código tiene algunos de ios elementos de "refactorización", un concepto de rediseño introducido en el capitulo 4 y tratado en otras partes de este libro.

912

PARTE C I N C O


un s i s t e m a d e b a s e d e d a t o s específico). Más importante, d i c h a s h e r r a m i e n t a s de reingeniería se e s t á n volviendo c a d a vez m á s sofisticadas. La ingeniería directa, t a m b i é n l l a m a d a renovación o r e c l a m a c i ó n [CHI90], n o sólo recupera la información d e d i s e ñ o a partir del s o f t w a r e existente, t a m b i é n utiliza e s t a i n f o r m a c i ó n p a r a alterar o reconstituir el s i s t e m a existente c o n la finalidad de m e j o r a r su calidad global. En la mayoría d e los c a s o s el s o f t w a r e s o m e t i d o a reingeniería vuelve a implementar la función del sistema existente y también a ñ a d e n u e v a s f u n c i o n e s o m e j o r a el d e s e m p e ñ o global.

La ingeniería

inversa

invoca u n a i m a g e n d e " r a n u r a mágica". En la r a n u r a s e inserta

u n a lista f u e n t e sin d o c u m e n t a r y d i s e ñ a d o c a s u a l m e n t e , y del otro e x t r e m o sale u n a descripción (y toda la d o c u m e n t a c i ó n ) c o m p l e t a del d i s e ñ o p a r a el p r o g r a m a de c o m p u t a d o r a . D e s d i c h a d a m e n t e , la r a n u r a mágica n o existe. La ingeniería inversa p u e d e o b t e n e r información d e d i s e ñ o a partir del código fuente, p e r o el g r a d o d e a b s tracción, la c o m p l e t u d d e la d o c u m e n t a c i ó n , el g r a d o en el q u e las h e r r a m i e n t a s y un analista h u m a n o t r a b a j a n en c o n j u n t o , y la direccionalidad del p r o c e s o s o n e n o r m e m e n t e variables. El grado

de abstracción

d e un p r o c e s o d e ingeniería inversa y l a s h e r r a m i e n t a s uti-

lizadas para efectuarlo s e refieren a la sofisticación d e la i n f o r m a c i ó n del d i s e ñ o q u e e s posible o b t e n e r del código fuente. Idealmente, el g r a d o d e abstracción d e b e ser tan alto c o m o s e a posible. Esto es, el p r o c e s o d e ingeniería inversa d e b e ser c a p a z de derivar r e p r e s e n t a c i o n e s d e d i s e ñ o d e p r o c e d i m i e n t o (un g r a d o d e abstracción bajo), información d e estructura d e p r o g r a m a y d a t o s (un g r a d o d e abstracción un p o c o m á s elevado), m o d e l o s d e objeto, m o d e l o s d e flujo de d a t o s o control (un grado d e abstracción relativamente alto) y c l a s e s UML, d i a g r a m a s d e e s t a d o y despliegue (un g r a d o alto d e abstracción). C o n f o r m e el g r a d o d e abstracción a u m e n t a , el ingen i e r o d e s o f t w a r e o b t i e n e información q u e le permitirá c o m p r e n d e r c o n m á s facilid a d el p r o g r a m a . La completud

d e u n p r o c e s o d e ingeniería inversa s e refiere al g r a d o d e detalle q u e

s e o f r e c e en un g r a d o de abstracción. En la mayoría d e los c a s o s , la integridad disminuye c o n f o r m e el g r a d o d e abstracción a u m e n t a . Por e j e m p l o , d a d a u n a lista del código fuente, e s r e l a t i v a m e n t e sencillo desarrollar u n a r e p r e s e n t a c i ó n completa del d i s e ñ o del p r o c e d i m i e n t o . También s e p u e d e n derivar r e p r e s e nTM t a c i o n e s sencillas d e diseño, p e r o e s m u c h o m á s difícil desarrollar un c o n j u n t o c o m p l e t o d e d i a g r a m a s o m o d e l o s UML.

PDF Editor

La c o m p l e t u d m e j o r a e n proporción directa c o n la cantidad d e análisis q u e efec-

túa quien realiza la ingeniería inversa. La interactividad

s e refiere al g r a d o en el q u e

el ser h u m a n o está "integrado" c o n las h e r r a m i e n t a s a u t o m a t i z a d a s p a r a crear un p r o c e s o d e ingeniería inversa efectivo. En la mayoría d e los c a s o s , c o n f o r m e a u m e n ta el g r a d o d e abstracción la interactividad d e b e a u m e n t a r o la c o m p l e t u d sufrirá.

CAPÍTULO 31

Proceso d e ingeniería inversa.

913

REINGENIERÍA

Código Fuente sucio

Código íuente limpio

1

Especificación final

I

CLAVE Se d e b e n abordor tres t e m a s d e lo ingeniería inversa: g r a d o de abstracción, integridad y direccionalidad.

Si la direccionalidad del proceso de ingeniería inversa es unidireccional, toja la información extraída del código fuente se ofrece al ingeniero de software que ertonces puede usarla durante cualquier actividad de mantenimiento. Si la direccionalidad es bidireccional, la información alimenta a una herramienta de reingeniería que intenta reestructurar o regenerar el programa antiguo. En la figura 31.3 se representa el proceso de ingeniería inversa. Antes de que comiencen las actividades de ingeniería inversa, el código fuente no estructurado ("sucio") se reestructura (sección 31.4.1) de modo que sólo contenga las estructuras de programación estructurada. 4 Esto facilita la lectura del código fuente y ofrece la base para las subsecuentes actividades de ingeniería inversa. El núcleo de la ingeniería inversa es una actividad llamada extracción de abstracciones. El ingeniero debe evaluar el programa antiguo y, a partir del código fuente (con frecuencia sin documentar), desarrollar una especificación significativa del procesamiento que realiza, la interfaz del usuario que se aplica y las estructuras de datos del programa o las bases de datos que se utilizan. 31.3.1

Ingeniería inversa para comprender los d a t o s

TM

La ingeniería inversa de datos ocurre en diferentes grados de abstracción y con frecuencia es la primera tarea de reingeniería. Al nivel del programa, las estructuras de datos internos del programa usualmente deben someterse a reingenieria inversa

PDF Editor 4

El código se reestructura empleando un mcxor de reestructuración, una herramienta que reestructura código fuente.

914

Recursos útiles paro la

de programo" se pueden enctmtrof en wwwscl.iit.nrc. ca/projetls/dr/ dr.htmi

^CONSEJO^

PARTE C I N C O


como parte de un esfuerzo global de reingeniería. En el nivel del sistema las estructuras globales de datos (por ejemplo, archivos, bases de datos) con frecuencia se someten a reingeniería para ajusfarlos con los nuevos paradigmas de gestión de bases de datos (por ejemplo, el movimiento desde los archivos planos hacia los sistemas de bases de datos relaciónales u orientados a objetos). La ingeniería inversa de las actuales estructuras globales de datos establece el escenario para la intro ducción de una nueva base de datos que abarque todo el sistema. Estructuras de datos internos. Las técnicas de ingeniería inversa para datos internos del programa se enfoca en la definición de clases de objetos. Esto se logra al examinar el código del programa con el propósito de agrupar las variables de programa relacionadas. En muchos casos, la organización de los datos dentro del código identifica tipos abstractos de datos. Por ejemplo, estructuras de registro, archivos, listas y cyrnrjgstructuras de datos con frecuencia ofrecen una indicación inicial de las clases. *^7^

Los compromisos aparentemente insignificantes en los estructuras de datos pueden conducir a problemas potencialmente catastróficos en Estructura de bases de datos. Sin importar su organización lógica y estructura años futuros. física, una base de datos permite la definición de objetos de datos y apoya algún Considere como método para establecer relaciones entre los objetos. En consecuencia, la reingenieejemplo el problema ría de un esquema de base de datos en otro requiere comprender los objetos exism. tentes y sus relaciones. Los siguientes pasos [PRE94] se pueden utilizar para definir el modelo de datos existente como un precursor para la reingeniería de un nuevo modelo de base de datos: 1) construcción de un modelo inicial de objeto, 2) determinación de los candidatos clave, 3) refinar las clases tentativas, 4) definición de generalizaciones y 5) descubrimiento de asociaciones (empleo de técnicas análogas al enfoque CRC). Una vez que se conoce la información definida en los pasos precedentes, se aplica una serie de transformaciones [PRE94] para correlacionar la estructura antigua de la base de datos con una nueva estructura de base de datos. 31.3.2

Ingeniería inversa p a r a comprender el p r o c e s a m i e n t o

La ingeniería inversa para comprender el procesamiento comienza con un intento por comprender y luego extraer abstracciones de procedimientos representadas por el código fuente. Para comprender las abstracciones de procedimientos el código se analiza en grados variables de abstracción: sistema, programa, componentes, patrón TM y planteamiento. La funcionalidad global de todo el sistema de aplicación se debe comprender antes de que ocurra un trabajo de ingeniería inversa más detallado. Esto establece un contexto para un mayor análisis y ofrece poca visión de los conflictos de interoperabilidad entre las aplicaciones dentro del sistema. Cada uno de los programas que conforman el sistema de la aplicación representa una abstracción funcional en un mayor grado de detalle. Se crea un diagrama de bloques que representa la interacción entre dichas abstracciones funcionales. Cada componente realiza alguna

PDF Editor

CAPÍTULO 3 1

915

REINGENIERÍA

s u b f u n c i ó n y r e p r e s e n t a u n a a b s t r a c c i ó n d e p r o c e d i m i e n t o definida. P a r a c a d a c o m p o n e n t e s e d e s a r r o l l a u n 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 . En a l g u n a s s i t u a c i o n e s y a e x i s t e n e s p e c i f i c a c i o n e s del s i s t e m a , el p r o g r a m a y los c o m p o n e n t e s . C u a n d o é s t e e s el c a s o , las e s p e c i f i c a c i o n e s s e revisan p a r a verificar si c o n c u e r d a n c o n el c ó d i g o existente.5 "Existe u n o pasión por la comprensión, así como existe uno por la música. Dicho pasión es m á s común en los niños, pero más tarde se pierde en la mayoría de las personos." fllbert Einstein

Las c o s a s s e c o m p l i c a n m á s c u a n d o s e c o n s i d e r a el c ó d i g o d e n t r o d e un c o m p o n e n t e . El i n g e n i e r o b u s c a las s e c c i o n e s de c ó d i g o q u e r e p r e s e n t e n p a t r o n e s d e p r o c e d i m i e n t o g e n é r i c o s . Casi e n c a d a c o m p o n e n t e u n a s e c c i ó n del c ó d i g o p r e p a r a los d a t o s p a r a el p r o c e s a m i e n t o ( d e n t r o del m ó d u l o ) , u n a s e c c i ó n d i f e r e n t e d e c ó d i g o realiza el p r o c e s a m i e n t o y o t r a s e c c i ó n del c ó d i g o p r e p a r a los r e s u l t a d o s del p r o c e s a m i e n t o p a r a e x p o r t a r l o s d e s d e el c o m p o n e n t e . D e n t r o d e c a d a u n a d e e s t a s s e c c i o n e s s e p u e d e n e n c o n t r a r p e q u e ñ o s p a t r o n e s ; p o r e j e m p l o , la validación d e los d a t o s y la verificación de e n l a c e s c o n f r e c u e n c i a o c u r r e d e n t r o d e la s e c c i ó n d e c ó d i g o q u e p r e p a r a los d a t o s p a r a el p r o c e s a m i e n t o . En s i s t e m a s g r a n d e s la i n g e n i e r í a inversa, por lo g e n e r a l , se logra u t i l i z a n d o u n e n f o q u e s e m i a u t o m a t i z a d o . Las h e r r a m i e n t a s a u t o m a t i z a d a s s e utilizan p a r a a y u d a r al i n g e n i e r o d e s o f t w a r e a c o m p r e n d e r la s e m á n t i c a del c ó d i g o e x i s t e n t e . E n t o n c e s la salida de e s t e p r o c e s o p a s a a la r e e s t r u c t u r a c i ó n y a las h e r r a m i e n t a s d e i n g e n i e ría a v a n z a d a p a r a c o m p l e t a r el p r o c e s o d e r e i n g e n i e r í a .

31.3.3

Ingeniería inversa d e interfaces d e usuario

Las IGU s o f i s t i c a d a s a h o r a s o n i n d i s p e n s a b l e s en p r o d u c t o s b a s a d o s e n c o m p u t a d o ra y e n s i s t e m a s de t o d o tipo. En c o n s e c u e n c i a , d e s a r r o l l a r de n u e v o l a s i n t e r f a c e s d e u s u a r i o s e h a v u e l t o u n o d e los t i p o s m á s c o m u n e s de actividad de r e i n g e n i e r í a . P e r o a n t e s d e q u e u n a i n t e r f a z de u s u a r i o se p u e d a r e c o n s t r u i r d e b e r á r e a l i z a r s e u n a a ct i vi dad d e ingeniería inversa. E n t e n d e r p o r c o m p l e t o u n a i n t e r f a z d e u s u a r i o e x i s t e n t e r e q u i e r e e s p e c i f i c a r la e s t r u c t u r a y el c o m p o r t a m i e n t o d e la interfaz. Merlo y s u s c o l e g a s (MER931 s u g i e r e n t r e s p r e g u n t a s b á s i c a s q u e s e d e b e n r e s p o n d e r c o n f o r m e c o m i e n z a la i n g e n i e r í a i n v e r s a d e la IGU:

TM

• ¿ C u á l e s s o n las a c c i o n e s b á s i c a s (por e j e m p l o , p r e s i o n e s d e t e c l a o clics d e

PDF Editor r a t ó n ) q u e d e b e p r o c e s a r la i n t e r f a z ?

5

Con frecuencia, las especificaciones escritas en las primeras etapas en la historia de vida de un programa nunca se actualizan. Conforme los cambios se realizan, el código ya no concuerda más con las especificaciones.

916

PARTE C I N C O


• ¿Cuál e s la d e s c r i p c i ó n c o m p a c t a de las r e s p u e s t a s de c o m p o r t a m i e n t o del

¿Cómo • entender los funciones de una interfaz de usuario e x i s t e n t e ?

sistema a estas acciones? • ¿ Q u é s e e n t i e n d e p o r " r e e m p l a z o " o, m á s e x a c t a m e n t e , q u é c o n c e p t o d e e q u i v a l e n c i a de i n t e r f a c e s es r e l e v a n t e e n e s t e c a s o ? La n o t a c i ó n de m o d e l a d o de c o m p o r t a m i e n t o (capítulo 8) p u e d e o f r e c e r u n m e d i o p a r a d e s a r r o l l a r r e s p u e s t a s a las p r i m e r a s d o s p r e g u n t a s . G r a n p a r t e de la i n f o r m a ción n e c e s a r i a p a r a c r e a r un m o d e l o d e c o m p o r t a m i e n t o s e p u e d e o b t e n e r o b s e r v a n d o la m a n i f e s t a c i ó n e x t e r n a de la interfaz existente. P e r o la i n f o r m a c i ó n adicional n e c e s a r i a p a r a c r e a r el m o d e l o d e c o m p o r t a m i e n t o s e d e b e e x t r a e r del c ó d i g o . Es i m p o r t a n t e s e ñ a l a r q u e u n a GUI de r e e m p l a z o tal v e z n o refleje e x a c t a m e n t e la interfaz antigua (de h e c h o , q u i z á s e a r a d i c a l m e n t e diferente). Con f r e c u e n c i a v a l e la p e n a d e s a r r o l l a r n u e v a s m e t á f o r a s d e i n t e r a c c i ó n . Por e j e m p l o , u n a GUI a n t i g u a solicita q u e u n u s u a r i o p r o p o r c i o n e u n factor d e e s c a l a (que varía d e s d e 1 h a s t a 10) p a r a e n c o g e r o a m p l i a r u n a i m a g e n g r á f i c a . Una GUI s o m e t i d a a r e i n g e n i e r í a p u e d e utilizar u n a b a r r a d e d e s l i z a m i e n t o y u n r a t ó n p a r a r e a l i z a r la m i s m a f u n c i ó n .


Ingeniería inversa •

Objetivo: Ayudar a los Ingenieros de software a comprender la estructura de diseño interna de los programas complejos. M e c á n i c a : En la mayoría de los casos, las herramientas de ingeniería inversa aceptan código fuente como entrada y producen una diversidad de representaciones de diseño estructural, p r o c e d i m i e n t o , d a t o s y c o m p o r t a m i e n t o .

Herramientas representativas 6 Irnagix

4D,

d e s a r r o l l a d a p o r Imagix (wvAV.imagix.com),

" a y u d a a los d e s a b o l l a d o r e s d e s o f t w a r e a c o m p r e n d e r

software C y C++ complejo o heredado" al someter a ingeniería inversa y documentar el código fuente. Undersland, desarrollada por Scientific Toolworks, Inc. (www.scitools.com), analiza gramaticalmente Ada, Fortran, C, C++ y Java "para realizar ingeniería inversa, documentar automáticamente, calcular métricas de código y auxiliarlo a comprender, navegar y mantener el código fuente". Una extensa lista de herramientas de ingeniería inversa se puede encontrar em http://scgwiki.iam.unibe.ch:8080/ SCG/370.

La r e e s t r u c t u r a c i ó n d e s o f t w a r e m o d i f i c a el c ó d i g o f u e n t e o los d a t o s c o n la finalid a d d e a d e c u a r l o s p a r a f u t u r o s c a m b i o s . En g e n e r a l , la r e e s t r u c t uTM r a c i ó n n o modifica la arquitectura global del p r o g r a m a . Tiende a e n f o c a r s e s o b r e los detalles de d i s e ñ o de los m ó d u l o s individuales y e n l a s e s t r u c t u r a s d e d a t o s l o c a l e s d e f i n i d o s d e n t r o d e

PDF Editor

los m ó d u l o s . Si el t r a b a j o d e r e e s t r u c t u r a c i ó n s e e x t i e n d e m á s allá de las f r o n t e r a s 6

Las herramientas expuestas el autor n o las respalda; sólo representan una muestra de las herramientas incluidas en esta categoría. En la mayoría de los casos, los nombres de las herramientas son marcas registradas por sus respectivos desarrolladores.

CAPÍTULO 31

RHNGENIERÍA

917

del m ó d u l o y a b a r c a la arquitectura del s o f t w a r e , la reestructuración s e convierte en ingeniería a v a n z a d a (sección 31.5). La reestructuración ocurre c u a n d o la arquitectura básica d e u n a aplicación e s sólida, a u n c u a n d o el interior técnico n e c e s i t e trabajarse. Se inicia c u a n d o g r a n d e s p a r t e s del s o f t w a r e s o n f u n c i o n a l e s y sólo un s u b c o n j u n t o d e los c o m p o n e n t e s y d a t o s necesitan u n a modificación e x t e n s a . 7

31.4.1

Reestructuración del c ó d i g o

La reestructuración del código s e realiza para g e n e r a r un d i s e ñ o q u e p r o d u z c a la ÔNSiJO^

Aunque la reestiuctuloción del código puede aliviar inmediatamente los problemas asociados con lo depuiación o los cambios pequeños, eslonoes reingeniería. El beneficio real se logra sólo cuando se reestructuran los datos y lo arquitectura.

m i s m a función que el p r o g r a m a original, p e r o c o n m a y o r calidad. En general, las técnicas d e reestructuración d e código (por ejemplo, t é c n i c a s d e simplificación lógica d e Warnier [WAR74]) m o d e l a n la lógica del p r o g r a m a utilizando álgebra b o o l e a n a y luego aplican u n a serie d e reglas d e t r a n s f o r m a c i ó n q u e p r o d u c e n lógica reestructurada. El objetivo e s t o m a r el "tazón d e espagueti" d e código y derivar un d i s e ñ o d e p r o c e d i m i e n t o q u e c o n c u e r d e c o n la filosofía d e la p r o g r a m a c i ó n e s t r u c t u r a d a (capitulo 11). También s e h a n p r o p u e s t o o t r a s técnicas d e reestructuración p a r a utilizarlas c o n las h e r r a m i e n t a s d e reingeniería. Un d i a g r a m a d e intercambio d e r e c u r s o s correlaciona c a d a m ó d u l o d e p r o g r a m a y los r e c u r s o s (tipos d e datos, p r o c e d i m i e n t o s y variables) q u e s e i n t e r c a m b i a n e n t r e ellos y o t r o s m ó d u l o s . Mediante la creación d e r e p r e s e n t a c i o n e s del flujo d e r e c u r s o s se p u e d e reestructurar la arquitectura del prog r a m a para lograr m í n i m o s a c o p l a m i e n t o s e n t r e módulos.

31.4.2

Reestructuración d e los datos

Antes d e c o m e n z a r la reestructuración de d a t o s s e d e b e llevar a c a b o u n a actividad d e ingeniería inversa d e n o m i n a d a análisis

del

código

fuente.

Primero s e e v a l ú a n

t o d o s los e n u n c i a d o s del l e n g u a j e de p r o g r a m a c i ó n que c o n t e n g a n definiciones de datos, descripciones de archivos, I/O y descripciones d e interfaz. La finalidad e s extraer e l e m e n t o s y o b j e t o s d e d a t o s para o b t e n e r i n f o r m a c i ó n a c e r c a del flujo d e d a t o s y c o m p r e n d e r las e s t r u c t u r a s de d a t o s e x i s t e n t e s q u e s e h a n i m p l e m e n t a d o . Esta actividad a v e c e s s e d e n o m i n a análisis

de datos

[RIC89].

Una vez c o m p l e t a d o el análisis d e d a t o s c o m i e n z a el rediseño f o r m a m á s simple, un p a s o d e estandarización

de registro

de datos.

En su

d e d a t o s clarifica las defi-

niciones d e d a t o s p a r a lograr consistencia e n t r e los n o m b r e s d e e l e m e n t o s d e d a t o s

TM o f o r m a t o s d e registro físicos d e n t r o d e u n a estructura de d a t o s existente o formato de archivo. Otra f o r m a d e rediseño, d e n o m i n a d a racionalización

del nombre

d e los

d a t o s a s e g u r a q u e t o d a s las c o n v e n c i o n e s de n o m b r a m i e n t o d e los d a t o s c o n c u e r -

PDF Editor

d a n c o n el e s t á n d a r local y q u e los p s e u d ó n i m o s s e eliminan c o m o flujo d e d a t o s a través del s i s t e m a .

7

A veces e s difícil distinguir entre reestructuración extensa y volver a desarrollar. Ambos son reingeniería.

918

PARTE C I N C O


Cuando la reestructuración rebasa la estandarización y la nacionalización se realizan modificaciones físicas a las estructuras de datos existentes para lograr que el diseño de los datos sea más efectivo. Esto puede significar una traducción de un formato de archivo a otro o, en algunos casos, la traducción desde un tipo de base de datos a otro.


Reestructuración de software Objetivo: El objetivo d e las herramientas de reestructuración es transformar el antiguo software de computadora carente de estructura en lenguajes d e programación y estructuras de diseño modernos. Mecánica: En general, el código fuente se ingresa y transforma en un mejor programa estructurado. En algunos casos, la transformación ocurre dentro del mismo lenguaje de programación. En otros casos, un lenguaje de programación antiguo se transforma en un lenguaje más moderno. Herramientas representativas8 DMS Software Reengineering Toolkit, desarrollada por Semantic Design (www.semdesigns.com), proporciona

V

3 1 . 5

INGENIERÍA

*\

una diversidad d e capacidades de reestructuración para COBOL, C/C++, Java, FORTRAN 90 y VHDL. FORESYS, desarrollada por Simulog (www.simulog.fr), analiza y transforma programas escritos en FORTRAN. Function Encopsulaliort Tool, desarrollada en la Wayne State University (www.cs.wayne.edu/~vip/RefactoringTools/), refactoriza en C++ los antiguos programas en C. plusFORT, desarrollada por Polyhedron (www.polyhedron. com), es un conjunto de herramientas de FORTRAN que tiene capacidades para reestructurar en FORTRAN moderno o C estándar los programas en FORTRAN deficientemente diseñados.

DIRECTA

Un programa con flujo de control —el equivalente gráfico de un tazón de espagueti, con "módulos" que tienen 2 000 enunciados de longitud, con pocas líneas significativas de comentarios en los 290 000 enunciados fuente y ninguna otra documentación, se debe modificar para que se ajuste a los cambiantes requerimientos de los usuarios. Se tienen las siguientes opciones: ^ ¿Qué opcio* nes existen cuando se enfrenta un programa deficientemente diseñado e implementado?

1. Se puede trabajar modificación tras modificación, luchando con el diseño implícito y el código fuente para implementar los cambios necesarios. 2. Se puede intentar comprender el extenso funcionamiento interno del programa con el propósito de realizar modificaciones de manera más eficiente. 3. Se puede rediseñar, recodificar y probar aquellas porciones del TMsoftware que requieran modificación mediante la aplicación de un enfoque de ingeniería del software en todos los segmentos revisados.

PDF Editor 8

Las herramientas expuestas sólo representan una muestra de esta categoría. En la mayoría de los casos los nombres de las mismas son marcas registradas por sus respectivos desarrolladores.

CAPÍTULO 31

919

REINGENIERÍA

4 . Se p u e d e rediseñar, recodificar y probar ei p r o g r a m a c o m p l e t a m e n t e e m p l e a n d o h e r r a m i e n t a s d e reingeniería c o m o auxiliares p a r a c o m p r e n d e r el d i s e ñ o actual. No existe u n a opción individual "correcta". Las c i r c u n s t a n c i a s p u e d e n dictar la prim e r a opción, incluso si las o t r a s son m á s deseables. En lugar d e e s p e r a r h a s t a q u e s e reciba la solicitud d e m a n t e n i m i e n t o , la organiz a c i ó n d e desarrollo o soporte utiliza los r e s u l t a d o s del análisis de inventarios para seleccionar un p r o g r a m a q u e 1) s e e m p l e a r á d u r a n t e un n ú m e r o d e t e r m i n a d o d e a ñ o s , 2) a c t u a l m e n t e s e utilice con éxito, y 3) e s probable q u e e x p e r i m e n t a r á grand e s modificaciones o m e j o r a s en el futuro cercano. E n t o n c e s s e aplican las o p c i o n e s 2, 3 o 4. Este e n f o q u e d e mantenimiento bre de retrofit*

estructurado.

preventivo

lo introdujo Miller [MIL81 ] con el n o m -

Este c o n c e p t o s e define c o m o "la aplicación de las m e t o -

dologías de hoy a los s i s t e m a s del ayer p a r a a p o y a r los requisitos del m a ñ a n a " . A primera vista, la sugerencia d e q u e s e desarrolle de n u e v o un gran p r o g r a m a c u a n d o ya existe u n a versión operativa p u e d e p a r e c e r b a s t a n t e e x t r a v a g a n t e . Antes d e emitir un juicio, c o n s i d é r e n s e los p u n t o s siguientes: 1. El c o s t o d e m a n t e n e r u n a línea de código f u e n t e tal v e z oscile entre 20 y 40

ÔNSEJO^-

v e c e s el c o s t o d e su desarrollo inicial.

Lo reingeniería es muy porecida o lo limpieza denlol. Puede pensai en miles de tazones pata demorada, y la aplozató muchas veces. Peto eventualmente sus tócticos dilatorias regresarán para provocarte dolor.

2.

El r e d i s e ñ o de la arquitectura d e s o f t w a r e (estructura de p r o g r a m a o datos) e m p l e a n d o c o n c e p t o s m o d e r n o s d e diseño p u e d e facilitar e n o r m e m e n t e el m a n t e n i m i e n t o futuro.

3.

Puesto q u e ya existe un prototipo del s o f t w a r e , el desarrollo d e la productivid a d deb e ser m u c h o mayor q u e el p r o m e d i o .

4.

El u s u a r i o a h o r a tiene experiencia c o n el s o f t w a r e . En c o n s e c u e n c i a , los n u e vos requisitos y la dirección del c a m b i o p u e d e n a f i r m a r s e c o n m a y o r facilidad.

5.

Las h e r r a m i e n t a s a u t o m a t i z a d a s para reingeniería facilitarán a l g u n a s p a r t e s del trabajo.

6.

A n t e s d e terminar el m a n t e n i m i e n t o preventivo existirá u n a configuración completa del s o f t w a r e (documentos, p r o g r a m a s y datos).

C u a n d o u n a o r g a n i z a c i ó n d e desarrollo de s o f t w a r e v e n d e s o f t w a r e c o m o producto, el m a n t e n i m i e n t o preventivo s e considera c o m o " n u e v a s liberaciones" de un

TM

p r o g r a m a . Un gran desarrollador de s o f t w a r e local (por ejemplo, un g r u p o d e d e s a rrollo d e s o f t w a r e p a r a s i s t e m a s de n e g o c i o s d e s t i n a d o s a u n a gran c o m p a ñ í a c o n sumidora d e productos) p u e d e t e n e r 500-2 000 p r o g r a m a s de producción d e n t r o d e

PDF Editor *

El término retrofit (literalmente retroajustei recibe muchas denominaciones en español, entre las

que destacan: remodelado, modemizac: in. retrocambio, reajuste, modificación retroactiva. Para no generar confusión con otros conceptos y denominaciones similares, pero no relacionados, utilizaré el término original, que por lo demás es reconocido dentro del medio. (N.T.)

920

PARTE C I N C O


su d o m i n i o de responsabilidad. Dichos p r o g r a m a s p u e d e n clasificarse según su importancia y luego revisarlos c o m o c a n d i d a t o s p a r a m a n t e n i m i e n t o preventivo. El p r o c e s o d e ingeniería a v a n z a d a aplica los principios, c o n c e p t o s y m é t o d o s de la ingeniería del s o f t w a r e p a r a r e c r e a r u n a aplicación existente. En la mayoría d e los c a s o s , la ingeniería directa n o s i m p l e m e n t e crea el equivalente m o d e r n o d e un prog r a m a antiguo. Más bien, los n u e v o s requisitos d e u s u a r i o y tecnología s e integran en el t r a b a j o de reingeniería. El p r o g r a m a q u e s e desarrolla d e n u e v o amplía las c a p a c i d a d e s d e la aplicación anterior.

31.5.1

Ingeniería directa p a r a arquitecturas cliente/servidor

Durante las d é c a d a s p a s a d a s m u c h a s aplicaciones p a r a c o m p u t a d o r a central s e h a n s o m e t i d o a reingeniería para a d a p t a r l a s a a r q u i t e c t u r a s c l i e n t e / s e r v i d o r (incluso WebApps). En e s e n c i a , los r e c u r s o s d e c ó m p u t o c e n t r a l i z a d o s (que incluyen s o f t w a re) s e distribuyen e n t r e m u c h a s p l a t a f o r m a s cliente. Aunque s e p u e d e n d i s e ñ a r varios e n t o r n o s distribuidos diferentes, la aplicación típica d e c o m p u t a d o r a central q u e s e s o m e t e a reingeniería en u n a arquitectura c l i e n t e / s e r v i d o r tiene las siguient e s características: • La funcionalidad d e la aplicación migra hacia c a d a c o m p u t a d o r a cliente. • En los sitios cliente s e i m p l e m e n t a n n u e v a s interfases IGU. • Las f u n c i o n e s d e b a s e d e d a t o s s e a s i g n a n al servidor. • La funcionalidad especializada (por e j e m p l o , análisis i n t e n s o d e cómputo) p u e d e p e r m a n e c e r en el sitio servidor. • Tanto en los sitios cliente c o m o servidor s e d e b e n e s t a b l e c e r n u e v o s requisitos d e c o m u n i c a c i o n e s , seguridad, a r c h i v a d o y control. Es importante señalar q u e la migración desde la c o m p u t a d o r a central hacia el cómputo cliente/servidor requiere reingeniería t a n t o d e negocio c o m o de software. Además, ^CONSEJÓ^

s e debe establecer u n a "infraestructura d e red d e e m p r e s a " [JAY94J. La reingeniería p a r a aplicaciones c l i e n t e / s e r v i d o r c o m i e n z a c o n un a m p l i o a n á -

En algunos casos, lo migiación hacia lo arquitectura clienteservidor no debe enfocarse como reingenierío, sino como un nuevo esfuerzo de desorrollo. la reingeniería ingresa ol cuadro sólo cuando lo funcionalidad especifica del sistema antiguo se integrará en la nueva arquitec-

lisis del e n t o r n o d e n e g o c i o s q u e incluye la c o m p u t a d o r a central existente. Se p u e den identificar tres c a p a s d e abstracción. La c a p a d e base d e d a t o s p o n e los cimientos d e u n a arquitectura c l i e n t e / s e r v i d o r y gestiona las t r a n s a c c i o n e s y c o n s u l t a s d e s d e aplicaciones cliente. A u n q u e dichas t r a n s a c c i o n e s y c o n s u l t a s s e deben controlar d e n t r o del c o n t e x t o d e un c o n j u n t o d e reglas d e n e g o c i o s (definidas TM m e d i a n t e un p r o c e s o d e n e g o c i o existente o s o m e t i d o a reingeniería). Las aplicaciones cliente o f r e c e n la funcionalidad d e s e a d a p a r a la c o m u n i d a d d e usuarios.

PDF Editor

Las f u n c i o n e s del s i s t e m a d e gestión d e b a s e s d e d a t o s existente y la arquitectu-

ra d e d a t o s d e la b a s e d e d a t o s e x i s t e n t e d e b e n s o m e t e r s e a ingeniería inversa c o m o p r e c u r s o r e s del r e d i s e ñ o d e la c a p a d e b a s e d e datos. En a l g u n o s c a s o s s e crea un n u e v o m o d e l o d e d a t o s (capítulo 8). En c a d a c a s o la b a s e d e d a t o s c l i e n t e / s e r v i d o r s e s o m e t e a reingeniería para g a r a n t i z a r q u e las t r a n s a c c i o n e s s e e j e c u t a n en f o r m a

CAPÍTULO 31

REINGENIERÍA

921

consistente, q u e t o d a s las a c t u a l i z a c i o n e s las realizan sólo u s u a r i o s autorizados, q u e las reglas centrales del n e g o c i o s e r e f u e r z a n (por ejemplo, a n t e s d e q u e se borre el registro d e u n a e m p r e s a el servidor s e a s e g u r a de q u e n o haya c u e n t a s por pagar, c o n t r a t o s o c o m u n i c a c i o n e s r e l a c i o n a d o s c o n dicha e m p r e s a ) , que las c o n s u l t a s s e p u e d e n a j u s t a r e f i c i e n t e m e n t e y q u e s e ha establecido u n a c a p a c i d a d c o m p l e t a d e archivado. La capa

de reglas

de negocios

r e p r e s e n t a el s o f t w a r e q u e reside t a n t o en el clien-

te c o m o e n el servidor. Este s o f t w a r e realiza t a r e a s d e control y coordinación p a r a g a r a n t i z a r que las t r a n s a c c i o n e s y c o n s u l t a s e n t r e la aplicación cliente y la b a s e de d a t o s s e a j u s t a n al p r o c e s o de n e g o c i o s establecido. La capa

de aplicaciones

cliente

i m p l e m e n t a f u n c i o n e s de n e g o c i o s q u e requieren

g r u p o s específicos de u s u a r i o s finales. En m u c h a s instancias, u n a aplicación d e c o m p u t a d o r a central s e s e g m e n t a en varias aplicaciones d e escritorio m á s p e q u e ñ a s y s o m e t i d a s a reingeniería. La c o m u n i c a c i ó n e n t r e las aplicaciones d e escritorio ( c u a n d o e s necesario) s e controla m e d i a n t e la c a p a d e reglas d e negocios. Un estudio c o m p l e t o del diseño y la reingeniería del s o f t w a r e c l i e n t e / s e r v i d o r e s m a t e r i a d e libros especializados. El lector i n t e r e s a d o d e b e consultar [VAN02], [COUOO] y [ORF99].

31.5.2

Ingeniería directa p a r a arquitecturas orientadas a objetos

La ingeniería del s o f t w a r e orientado a o b j e t o s se ha convertido en la alternativa e n c u a n t o al p a r a d i g m a d e desarrollo p a r a m u c h a s o r g a n i z a c i o n e s d e s o f t w a r e . Pero, ¿qu é hay a c e r c a d e las aplicaciones existentes q u e s e desarrollaron e m p l e a n d o m é t o d o s c o n v e n c i o n a l e s ? En a l g u n o s c a s o s la r e s p u e s t a e s dejar tales aplicaciones " c o m o están". En otros, las aplicaciones viejas d e b e n s o m e t e r s e a reingeniería d e m o d o que s e integren c o n facilidad en g r a n d e s s i s t e m a s o r i e n t a d o s a objetos. La reingeniería del s o f t w a r e c o n v e n c i o n a l en u n a i m p l e m e n t a c i ó n o r i e n t a d a a o b j e t o s utiliza m u c h a s d e las m i s m a s t é c n i c a s e s t u d i a d a s en la p a r t e 2 d e este libro. Primero, el s o f t w a r e existente s e s o m e t e a ingeniería inversa de m o d o q u e s e a posible crear m o d e l o s de datos, f u n c i o n a l e s y d e c o m p o r t a m i e n t o apropiados. Si el sist e m a d e reingeniería amplía la funcionalidad o el c o m p o r t a m i e n t o de la aplicación original, s e crean c a s o s de u s o (capítulos 7 y 8). Luego los m o d e l o s de d a t o s c r e a d o s d u r a n t e la ingeniería inversa s e utilizan j u n t o con el m o d e l a d o CRC (capítulo 8) p a r a establecer la b a s e con q u e s e definirán las clases. Enseguida s e definenTM las jerarquías de clases, los m o d e l o s d e relación de objetos, los m o d e l o s d e c o m p o r t a m i e n t o d e o b j e t o s y los s u b s i s t e m a s y e n t o n c e s c o m i e n z a el d i s e ñ o o r i e n t a d o a objetos.

PDF Editor

C o n f o r m e la ingeniería directa o r i e n t a d a a objetos progresa d e s d e el análisis

h a s t a el d i s e ñ o s e p u e d e invocar un m o d e l o d e p r o c e s o ISBC (capítulo 30). Si la aplic a c i ó n a n t i g u a s e e n c u e n t r a en un d o m i n i o q u e ya o c u p a n m u c h a s aplicaciones o r i e n t a d a s a objetos, e s p r o b a b l e q u e haya u n a b u e n a biblioteca d e c o m p o n e n t e s y q u e s e p u e d a utilizar d u r a n t e la ingeniería directa.

922

PARTE C I N C O


En a q u e l l a s c l a s e s q u e d a b a n c o n s t r u i r s e d e s d e el principio tal v e z s e a p o s i b l e reutilizar a l g o r i t m o s y e s t r u c t u r a s d e d a t o s de la aplicación c o n v e n c i o n a l e x i s t e n t e Sin e m b a r g o , q u i z á s e a p r e c i s o d i s e ñ a r l o s d e n u e v o p a r a a j u s t a r l o s a la a r q u i t e c t u ra o r i e n t a d a a o b j e t o s .

31.5.3

Ingeniería directa d e interfaces d e usuario

C o n f o r m e l a s a p l i c a c i o n e s m i g r a n d e la c o m p u t a d o r a central h a c i a el escritorio, los u s u a r i o s y a n o d e s e a n t o l e r a r las i n t e r f a c e s de u s u a r i o m i s t e r i o s a s b a s a d a s en c a r a c t e r e s . De h e c h o , u n a p o r c i ó n significativa del t r a b a j o e m p l e a d o e n la transición d e la c o m p u t a d o r a central a la c o m p u t a c i ó n c l i e n t e - s e r v i d o r se p u e d e d e d i c a r a la reing e n i e r í a de las i n t e r f a c e s d e u s u a r i o de la aplicación cliente. Merlo y s u s c o l e g a s [MER95] s u g i e r e n el s i g u i e n t e m o d e l o p a r a la r e i n g e n i e r í a de i n t e r f a c e s de u s u a r i o : ÔNSEJO^

1.

Comprender

la interfaz original y los datos que se trasladan

la aplicación.

¿Qué pasos se deben seguir poro someter o reingenierío uno interfaz de usuario?

entre ella y el resto de

La finalidad e s e n t e n d e r c ó m o o t r o s e l e m e n t o s d e u n p r o g r a m a

i n t e r a c t ú a n c o n el c ó d i g o e x i s t e n t e q u e i m p l e m e n t a la i n t e r f a z . Si se d e s a r r o llará u n a n u e v a GUI, los d a t o s q u e fluyan e n t r e é s t a y el p r o g r a m a r e s t a n t e d e b e n s e r c o n s i s t e n t e s c o n los d a t o s q u e a c t u a l m e n t e fluyen e n t r e la i n t e r f a z b a s a d a e n c a r a c t e r e s y el p r o g r a m a . 2.

Remodelar

el comportamiento

abstracciones

implícito

en la interfaz existente

que tengan sentido en el contexto

en una serie de

de una GUI. A u n q u e el m o d o d e

i n t e r a c c i ó n p u e d e s e r r a d i c a l m e n t e diferente, el c o m p o r t a m i e n t o de n e g o c i o s q u e m u e s t r a n los u s u a r i o s d e l a s i n t e r f a s e s vieja y n u e v a ( c u a n d o s e le c o n s i d e r a en t é r m i n o s d e un e s c e n a r i o d e utilización) d e b e p e r m a n e c e r igual. Una interfaz r e d i s e ñ a d a d e b e r á p e r m i t i r q u e u n u s u a r i o m u e s t r e el c o m p o r t a m i e n t o de n e g o c i o s a p r o p i a d o . Por e j e m p l o , c u a n d o s e c o n s u l t a u n a b a s e de d a t o s la vieja i n t e r f a z p u e d e r e q u e r i r u n a larga serie d e c o m a n d o s b a s a d o s e n texto p a r a e s p e c i f i c a r la c o n s u l t a . La GUI s o m e t i d a a r e i n g e n i e r í a p u e d e dirigir Unmonuoldemósde 300 páginas acerco de los patrones ile (desarrollado como porte del proyecto FAMOOS ESPR1D se puede descargar desde www.iom.unihe. di/-stg/ Archive/famoos/ patterns/index3.

la c o n s u l t a a u n a p e q u e ñ a s e c u e n c i a d e e l e c c i o n e s c o n el r a t ó n , p e r o el p r o p ó s i t o y el c o n t e n i d o d e la c o n s u l t a p e r m a n e c e n i n t a c t o s . 3.

Introducir

mejoras que hagan más eficiente el modo de interacción.

Las fallas e r -

gonómicas de la interfaz existente se estudian y corrigen en el diseño de la nueva GUI. 4.

Construir e integrarla

nueva GUI. La existencia de bibliotecas d e c l a s e s y h e r r a -

TM

m i e n t a s a u t o m a t i z a d a s p u e d e reducir significativamente el t r a b a j o requerido para construir la GUI. Sin e m b a r g o , la integración c o n el s o f t w a r e de la aplica-

PDF Editor

ción existente p u e d e requerir m á s tiempo. Debe t e n e r s e c u i d a d o de g a r a n t i z a r q u e la GUI n o p r o p a g a r á e f e c t o s colaterales a d v e r s o s en el resto de la aplicación.

"Puede pagar poco dinero ahora, o puede pagor mucho dinero m á s adelante."

Anuncio de taller mecánico q u e sugiere un ajuste

CAPÍTULO 31

923

REINGENIERÍA

En u n m u n d o p e r f e c t o , c u a l q u i e r p r o g r a m a al q u e n o s e le p u d i e r a d a r m a n t e n i m i e n t o s e r i a r e t i r a d o i n m e d i a t a m e n t e , y sería s u s t i t u i d o p o r a p l i c a c i o n e s d e m a y o r calidad con reingeniería desarrollada e m p l e a n d o m o d e r n a s prácticas de ingeniería del s o f t w a r e . Sin e m b a r g o , se vive e n un m u n d o d e r e c u r s o s limitados. La r e i n g e niería d e m a n d a r e c u r s o s q u e p u e d e n utilizarse p a r a o t r o s p r o p ó s i t o s del n e g o c i o . En c o n s e c u e n c i a , a n t e s de q u e u n a o r g a n i z a c i ó n i n t e n t e s o m e t e r a r e i n g e n i e r í a u n a aplicación existente, d e b e realizar un análisis costo-beneficio. S n e e d [SNE95] h a p r o p u e s t o u n m o d e l o d e a n á l i s i s c o s t o - b e n e f i c i o p a r a la reing e n i e r í a . Se d e f i n e n n u e v e p a r á m e t r o s : P, — c o s t o d e m a n t e n i m i e n t o a n u a l a c t u a l p a r a u n a a p l i c a c i ó n P2 = c o s t o d e o p e r a c i ó n a n u a l a c t u a l p a r a u n a a p l i c a c i ó n P3 = valor de negocios anual actual de u n a aplicación P„ = c o s t o d e m a n t e n i m i e n t o a n u a l p r e d i c h o d e s p u é s d e la r e i n g e n i e r í a P 5 = c o s t o de o p e r a c i ó n a n u a l p r e d i c h o d e s p u é s de la r e i n g e n i e r í a P é = v a l o r d e n e g o c i o s a n u a l p r e d i c h o d e s p u é s d e la r e i n g e n i e r í a P 7 = c o s t o e s t i m a d o d e la r e i n g e n i e r í a P g = f e c h a e s t i m a d a d e la r e i n g e n i e r í a P 9 = f a c t o r d e riesgo d e la r e i n g e n i e r í a (P 9 = 1.0 e s el v a l o r n o m i n a l ) L = vida e s p e r a d a del s i s t e m a El c o s t o a s o c i a d o c o n el m a n t e n i m i e n t o c o n t i n u o d e u n a a p l i c a c i ó n c a n d i d a t a (es decir, si la r e i n g e n i e r í a n o s e realiza) s e p u e d e definir c o m o CMAN, = [P3 - (P, + P2)L X L

(31-1)

Los c o s t o s a s o c i a d o s c o n la r e i n g e n i e r í a s e d e f i n e n e m p l e a n d o la s i g u i e n t e r e l a c i ó n : Creing =

P«

~

(^4

+

Ps>

X ( í "

Pg) -

(P7 X P9)]

(31 - 2 )

C o n la utilización d e los c o s t o s p r e s e n t a d o s e n l a s e c u a c i o n e s (31-1) y (31-2) el b e n e f i c i o global d e la r e i n g e n i e r í a s e p u e d e c a l c u l a r c o m o c o s t o b e n e f i c i o = CRE¡NG - CMAM

(31-3)

El a n á l i s i s c o s t o - b e n e f i c i o p r e s e n t a d o e n las e c u a c i o n e s s e p u e d e r e a l i z a r p a r a t o d a s las a p l i c a c i o n e s d e alta p r i o r i d a d i d e n t i f i c a d a s d u r a n t e el a n á l i s i s d e i n v e n t a r i o (sec-

TM

ción 31.2.2). A q u e l l a s a p l i c a c i o n e s q u e m u e s t r e n el m a y o r c o s t o - b e n e f i c i o p o d r á n d e s t i n a r s e a la r e i n g e n i e r í a , m i e n t r a s el t r a b a j o c o n o t r a s s e p u e d e p o s p o n e r h a s t a q u e haya recursos disponibles.

PDF Editor

La r e i n g e n i e r í a s e p r e s e n t a e n d o s d i f e r e n t e s g r a d o s d e a b s t r a c c i ó n . En el á m b i t o del n e g o c i o , la r e i n g e n i e r í a s e c e n t r a e n el p r o c e s o de n e g o c i o s c o n el p r o p ó s i t o d e e f e c -

924

PARTE C I N C O


tuar los c a m b i o s p a r a m e j o r a r la competitividad en a l g u n a á r e a del negocio. En el á m b i t o del s o f t w a r e , la reingeniería e x a m i n a los s i s t e m a s y aplicaciones d e inform a c i ó n con la finalidad de reestructurarlos o reconstruirlos de m o d o q u e m u e s t r e n m a y o r calidad. La reingeniería d e p r o c e s o s d e n e g o c i o (RPN) define m e t a s del negocio, identifica y e v a l ú a los p r o c e s o s d e negocios e x i s t e n t e s (en el c o n t e x t o d e m e t a s definidas), especifica y d i s e ñ a p r o c e s o s revisados, y e l a b o r a prototipos, los refina y particulariza d e n t r o de un negocio. La RPN tiene un objetivo q u e va m á s allá del s o f t w a r e . Su resultado c o n frecuencia e s la definición d e las f o r m a s en las cuales las tecnologías de la información p u e d e n a p o y a r mejor a los negocios. La reingeniería d e s o f t w a r e c o m p r e n d e u n a serie d e actividades q u e incluyen análisis de inventario, reestructuración de d o c u m e n t o s , ingeniería inversa, reestructuración d e p r o g r a m a s y dalos, e ingeniería directa. La finalidad de e s t a s actividades e s crear versiones d e p r o g r a m a s e x i s t e n t e s q u e s e a n d e mayor calidad y t e n g a n mayor facilidad de m a n t e n i m i e n t o ( p r o g r a m a s q u e s e r á n viables ya m u y a v a n z a d o el siglo xxi). El análisis de inventarios permite q u e u n a organización evalúe c a d a aplicación s i s t e m á t i c a m e n t e , con la finalidad d e d e t e r m i n a r c u á l e s s o n c a n d i d a t a s a la reingeniería. La reestructuración de d o c u m e n t o s crea un m a r c o de trabajo de documentación que

necesario p a r a brindar a p o y o a largo p l a z o a u n a aplicación. La ingeniería isa e s el p r o c e s o de analizar un p r o g r a m a c o n el propósito d e o b t e n e r informa -

cion d e d i s e ñ o de datos, arquitectónico y de procedimiento. Finalmente, la ingeniería directa reconstruye un p r o g r a m a e m p l e a n d o m o d e r n a s prácticas d e ingeniería del s o f t w a r e y la i n f o r m a c i ó n a p r e n d i d a d u r a n t e la ingeniería inversa. El costo-beneficio d e la reingeniería s e d e t e r m i n a c u a n t i t a t i v a m e n t e . El c o s t o del statu quo, esto es, el c o s t o a s o c i a d o con el soporte y el m a n t e n i m i e n t o a c t u a l e s d e u n a aplicación existente, s e c o m p a r a con los c o s t o s p r o y e c t a d o s d e la reingeniería y la reducción resultante en los c o s t o s de m a n t e n i m i e n t o . En casi t o d o s los c a s o s en los q u e un p r o g r a m a t e n g a u n a vida larga y en la actualidad m u e s t r e e s c a s a facilidad d e m a n t e n i m i e n t o , la reingeniería r e p r e s e n t a u n a estrategia de n e g o c i o s efectiva en c u a n t o al costo.

[CAN72] C a n n i n g , R., "The M a i n t e n a n c e ' I c e b e r g ' " , e n EDPAnalyzer, vol. 10, n ú m . 10, o c t u b r e d e 1972. TM [CAS88] "Case Tools for R e v e r s e E n g i n e e r i n g " , e n CASE Outlook, CASE C o n s u l t i n g G r o u p , vol 2, n ú m . 2, 1988, pp. 1-15 . ICHI90] C h i k o f s k y , E. ). y ). H. C r o s s , II, " R e v e r s e E n g i n e e r i n g a n d D e s i g n R e c o v e r y : A T a x o n o m y , e n IEEE Software, e n e r o d e 1990, pp. 13-17. [COUOO] Coulouris, G., J. D o l l i m o r e y T. Kindberg, Distríbuted Systems: C o n c e p t s a n d D e s i g n , 3 a . ed., Addison-Wesley, 2000. |DAV90) D a v e n p o r t , T. H. y J. E. Y o u n g , "The N e w I n d u s t r i a l Engineering-, I n f o r m a t i o n T e c h n o l o g y a n d B u s i n e s s P r o c e s s R e d e s i g n " , en Sloan management Review, v e r a n o d e 1990, pp. 11-27.

PDF Editor

CAPÍTULO 31

REINGENIERÍA

925

[DEM95] DeMarco, T., "Lean a n d Mean", en IEEE Software, n o v i e m b r e de 1995, pp. 101-102. [HAM90) H a m m e r , M., "Reengineer Work: Don't A u t o m a t e , Oblitérate", en Harvard Business Review, julio-agosto d e 1990, pp. 104-112. [HAN93] M a n n a , M., " M a i n t e n a n c e Burden Begging for a Remedy", en Datamation, abril d e 1993, pp. 53-63. [JAY94| Ja y c h a n d r a , Y., Re-engineering the Networked Enterprise, McGraw-Hill, 1994. |MER93| Merlo, E. et al., "Reverse Engineeríng of user Interfaces", Proc. Working Conference on Reverse Engineeríng, IEEE, Baltimore, mayo d e 1993, pp. 171-178. [MER95] Merlo, E. et al., "Reengineering User Interfaces", en IEEE Software, e n e r o de 1995, pp. 64-73. 1M1L81] Miller,)., e n Techniques ofProgram and System Maintenance, (G. Parikh, ed.) w i n t h r o p Publishers, 1981. [ORF99] Orfali, R., D. Harkey y J. Edwards, Client/Server Suvival Guide, 3a. ed., Wiley, 1999. [OSB90] Osborne, W. M. y E. J. Chikofsky, "Fitting Pieces to t h e M a i n t e n a n c e Puzzle", en IEEE Software, e n e r o d e 1990, pp. 10-11. [PRE94J Premerlani, W. J. y M. R. Blaha, "An Approach for Reverse Engineeríng of Relational Databases", en CACM, vol. 37, n ú m . 5, m a y o d e 1994, pp. 42-49. [RIC89I Ricketts, J. A., ). C. DelMonaco y M. W. Weeks, "Data Reengineering for Application Systems", Proc. Conf. Software Maintenance-1989, IEEE, 1989, pp. 174-179. [SNE951 Sneed, H., "Planning the Reengineering of Legacy Systems", en IEEE Software, e n e r o d e 1995, pp. 24-25. [STE93] Stewart, T. A., "Reengineering: The Hot New Managing Tool", en Fortune, 2 3 d e a gos t o de 1993, pp. 41-48. [SWA76] S w a n s o n , E. B., "The D i m e n s i o n s of Maintenance", Proc. Second Intl. Conf. Software Engineeríng, IEEE, octubre d e 1976, pp. 492-497. [VAN02) Van Steen, M. y A. T a n e n b a u m , Distributed Systems: Principies and Paradigms. Prentice-hall, 2002. [WAR74] Wamier, J. D„ Ijygical Construction ofPrograms, Van Nostrand-Reinhold, 1974.

3 1 . 1 . Considerar cualquier empleo realizado en los últimos cinco años. Describir el proceso de negocio en el q u e se participó. Emplear el modelo d e RPN descrito en la sección 31.1.3 para recomendar cambios al proceso con la finalidad de hacerlo m á s eficiente. 3 1 . 2 . Investigar un p o c o a c e r c a d e la eficacia d e la reingeniería d e p r o c e s o s del negocio. Presentar a r g u m e n t o s en favor y en contra d e este enfoque. 3 1 . 3 . El instructor seleccionará u n o de los p r o g r a m a s q u e todos e n la c l a s e h a n desarrollado d u r a n t e e s t e curso. Intercambie su p r o g r a m a en f o r m a aleatoria con alguien m á s en la clase. No explique u o f r e z c a un "paseo" p o r el p r o g r a m a . Ahora, i m p l e m e n t e u n a m e j o r a (que haya especificado el instructor) en el programa que ha recibido. a) Realice t o d a s las t a r e a s d e ingeniería del s o f t w a r e , incluso u n a breve p r u e b a m a n u a l (mas n o con el autor del programa). b) C o n s e r v e un c u i d a d o s o s e g u i m i e n t o d e t o d o s los e r r o r e s e n c o n t r a d o s d u r a n t e las pruebas. TM c) Describa sus experiencias en clase. 3 1 . 4 . Explorar la lista d e verificación del análisis d e inventario p r e s e n t a d o en el sitio Web SEP e intentar el desarrollo d e un sistema cuantitativo d e calificación de software que pudiese aplicarse a p r o g r a m a s existentes c o n la finalidad d e elegir p r o g r a m a s candidatos p a r a reingeniería. El sistema debe rebasar el análisis presentado en la sección 31.6.

PDF Editor

3 1 . 5 . Sugerir o p c i o n e s a la d o c u m e n t a c i ó n p o r escrito o electrónica c o n v e n c i o n a l q u e p u d i e s e n servir c o m o b a s e p a r a la r e e s t r u c t u r a c i ó n d e d o c u m e n t o s . (Sugerencia: p i é n s e s e en las n u e v a s tecnologías descriptivas q u e se p u d i e r a n u s a r p a r a c o m u n i c a r el p r o p ó s i t o del software.)

PARTE C I N C O


31.6. Algunas p e r s o n a s creen q u e la tecnología d e inteligencia artificial a u m e n t a r á el gra d o d e abstracción del p r o c e s o d e ingeniería inversa. Realizar algo d e investigación acerca d e esta materia (es decir, el uso d e IA en la ingeniería inversa) y escribir un breve e n s a y o q u e contenga u n a opinión acerca d e e s t e punto. 31.7. ¿Por q u é la completud e s difícil d e lograr c o n f o r m e a u m e n t a el gra d o d e abstracción? 31.8.

¿Por qué debe a u m e n t a r la interactividad si la completud a u m e n t a ?

31.9. Con b a s e en la información obtenida vía Internet, p r e s e n t e a su clase las características d e tres herramientas d e ingeniería inversa. 31.10. Existe u n a sutil diferencia entre reestructuración e ingeniería directa. ¿Cuál es? 31.11. Investigue la bibliografía o f u e n t e s d e Internet p a r a e n c o n t r a r u n o o m á s escritos que borden estudios d e c a s o d e reingeniería d e c o m p u t a d o r a central a cliente-servidor. Presente un resumen. 3 1 . 1 2 . ¿Cómo determinaría de P,¡ a P7 en el modelo costo-beneficio presentado en la sección 31.6?

Al igual q u e m u c h o s t e m a s a p a s i o n a n t e s en la comunidad d e negocios, las exageraciones que rodeaban la reingeniería d e procesos d e negocio han d a d o p a s o a u n a visión m á s pragmática d e la materia. H a m m e r y Champy (Reengineering the Corporation, HarperBusiness, edición revisada, 2001) precipitó el interés t e m p r a n o con el éxito d e ventas d e su libro. Más tarde, Hammer (Beyond Reengineering. How the Processed-Centered Organization Is Changing Our Work and Our Lives, HarperColIins, 1997) refino su visión al enfocarse sobre los t e m a s "centrados en el proceso". Los libros d e Smith y Fingar (Business Process Management (BPM): The Third Wave, MeghanKiffer Press, 2003), Jacka y Keller (Business Process Mapping: Improving Customer Satisfaction, wiley, 2001), Sharp y McDermott (Workflow Modeling, Artech House, 2001), Andersen (Business Process improvement Toolbox, American Society for Quality, 1999) y Harrington et al. (Business Process Improvement Workbook, McGraw-Hill, 1997) presentan estudios de caso y directrices detalladas para la RPN Feldmann (The Practical Guide to Business Process Reeingineering Using IDEFO, Dorset House, 1998) analiza u n a notación d e modelado que auxilia en la RPN. Berztiss (Software MeLhods for Business Reengineering, Springer, 1996) y Spurr el ai (Software Assistancefor Business Reengineering, Wiley, 1994) examinan herramientas y técnicas que facilitan la RPN. Secord y s u s colegas (Modernizing Legacy Systems, Addison-Wesley, 2003), Ulrich (Legacy systems. rransformation Stratcgics, Prentice-Hall, 2002), Valenti (Successful Software Reengineering, IRM Press, 2002) y Rada (Reengineering Software: How to Reuse Programming to Build new, State-of-the-Art Software, Fitzroy Dearborn Publishers, 1999) se e n f o c a n en las estrategias y prácticas para la reingeniería en un contexto técnico. Miller (Reengineering Legacy Software Systems, Digital Press, 1998) "ofrece un m a r c o d e trabajo p a r a m a n t e n e r las aplicaciones d e los sistemas sincronizadas c o n las estrategias del negocio y los cambios tecnológicos". Umar (Application (Re)Engineering: Building Web-Based Applications and Dealing with Legacies, Prentice-Hall, 1997) ofrece lincamientos valiosos para las organizaciones que quieren transformar los s i s t e m a s h e r e d a d o s en un e n t o r n o b a s a d o e n Web. Cook (Building Enterprise Information Architectures: TM Reengineering Information Systems, Prentice-Hall, 1996) analiza el puente entre la RPN y la tecnología de la información. Aiken (Data Reverse Engineering, McGraw-Hill, 1996) estudia c ó m o recuperar, reorganizar y reutilizar datos de la organización. Arnold (Software Reengineering, IEEE Computer Society Press, 1993) ha reunido una excelente antología de los primeros ensayos que trataban acerca de las tecnologías d e la reingeniería del software. Una amplia variedad d e f u e n t e s d e información acerca d e reingeniería d e s o f t w a r e está disponible en Internet. Una lista actualizada d e referencias en la World Wide Web s e p u e d e e n c o n trar en el sitio Web SEPA: http://www.mhhe.com/pressman.

PDF Editor

C A P I T U L O

EL C A M I N O POR RECORRER CONCEPTOS CLAVE ámbito del cambio

929

32

E

n los 31 c a p í t u l o s p r e c e d e n t e s s e e x p l o r ó u n p r o c e s o p a r a la i n g e n i e r í a del

s o f t w a r e . Se p r e s e n t a r o n t a n t o p r o c e d i m i e n t o s d e g e s t i ó n c o m o m é t o d o s técnicos, principios básicos y técnicas especializadas, actividades orienta-

d a s a l a s p e r s o n a s y t a r e a s a d e c u a d a s p a r a a u t o m a t i z a r l a s , n o t a c i ó n de p a p e l y

conocimiento . .934

lápiz y h e r r a m i e n t a s d e s o f t w a r e . Se a r g u m e n t ó q u e la m e d i c i ó n , la disciplina y

datos

933

u n a vigilancia e s t r i c t a s o b r e la c a l i d a d g e n e r a r á n u n s o f t w a r e q u e s a t i s f a g a las

ética

936

n e c e s i d a d e s d e los c l i e n t e s , q u e sea:fiable, q u e t e n g a facilidad d e m a n t e n i m i e n t o ,

importancia del software -.928 información . . . 9 3 3 personas

930

proceso

931

tendencias tecnológicas . . .936

q u e s e a m e j o r . Sin e m b a r g o , n u n c a s e ha p r o m e t i d o q u e la ingeniería del software sea una panacea. C o n f o r m e s e c o n t i n ú e el v i a j e e n el n u e v o siglo, l a s t e c n o l o g í a s d e s o f t w a r e y s i s t e m a s s e g u i r á n s i e n d o un d e s a f í o p a r a los p r o f e s i o n a l e s del s o f t w a r e y l a s c o m p a ñ í a s que construyan sistemas b a s a d o s en computadoras. Aunque escribió e s t a s p a l a b r a s c o n u n a visión del siglo xx, M a x H o p p e r [HOP90] d e s c r i b i ó c o n p r e c i s i ó n el e s t a d o a c t u a l del a s u n t o : Puesto que los cambios en la tecnología de la información se están volviendo tan rápidos e implacables, y las consecuencias de caer ante ellos son irreversibles, las compañías dominarán la tecnología o morirán... Piense en ello como en un molino de tecnología. Las compañías tendrán que correr cada vez más rápido para permanecer en su lugar.

¿ Q u é e s ? El futuro nunca es fácil de predecir, no obstante eruditos, conferencistas televisivos y expertos industriales rio se resisten. El camino por recorrer, está plagado de restos de excitantes nuevas tecnologías que en realidad nunca lo fueron (a pesar d e las exageraciones publicitarias), y con frecuencia lo conforman las tecnologías más modestas que d e alguna forma modificaron la dirección y amplitud del camino principal. En consecuencia, no se intentará predecir el futuro sino que se estudiarán algunos de los conflictos que será necesario considerar pora comprender cómo el software y la ingeniería del software cambiarán en los años por venir. ¿ Q u i é n l o h a c e ? ¡Todo él mundo! ¿ P o r q u é e s i m p o r t a n t e ? ¿Por qué los antiguos reyes contrataban adivinos? ¿Por qué las grandes corporaciones multinacionales conirc-

tan firmas consultoras y grupos de analistas p a r a elaborar predicciones? ¿Por qué un porcentaje sustancial del público lee horóscopos? Porque quieren saber qué vendrá para estar preparados. ¿ C u á l e s s o n l o s p a s o s ? N o existe una fórmula para predecir el camino que se recorrerá. Se intenta hacerlo mediante la recopilación de datos —y su organización p a r a proporcionar información útil— y el examen de asociaciones sutiles para obtener conocimiento y, a partir de TM éste, sugerir probables hechos que predigan cómo serán las cosas en cierto tiempo futuro.

¿Cuál e s el producto obtenido? Una visión

PDF Editor

del futuro cercano que podría o no ser correcta.

¿Cómo puedo estar seguro d e que lo he h e c h o c o r r e c t a m e n t e ? Predecir el camino que se recorrerá es un arte, no una ciencia. De hecho, es bastante raro cuando una predicción

927

928

PARTE C I N C O


seria a c e r c a del futuro es a b s o l u t a m e n t e correcta o inequívocamente e r r ó n e a (con la excepción, por fortuna, d e las predicciones del fin del mundo). S e buscan tendencias y se intenta extra-

polarlas h a c i a a d e l a n t e en el tiempo. Las correcciones d e la extrapolación sólo se p u e d e n valor a r c o n f o r m e p a s a el tiempo.

Los cambios en la tecnología de ingeniería de software son de hecho "rápidos e implacables", mientras que, al mismo tiempo, el progreso, por lo general, es bastante lento. Pero cuando se toma la decisión de adoptar un nuevo método (o una nueva herramienta), de llevar a cabo el entrenamiento necesario para comprender su aplicación y de introducir la tecnología en la cultura de desarrollo del software, algo más nuevo (e incluso mejor) ha llegado, y el proceso comienza de nuevo. En este capítulo se examinan tendencias hacia el futuro. La finalidad no es explorar todas las áreas de investigación que resulten prometedoras. Tampoco es mirar en una "bola de cristal" y pronosticar el futuro. Más bien, se explora el ámbito del cambio y la forma en la que éste afectará el proceso de ingeniería del software en los años por venir. 3 2 . 1

LA

IMPORTANCIA

DEL SOFTWARE.

SEGUNDA

PARTE

La importancia del software de computadora se puede establecer en muchas formas. En el capítulo I el software se caracterizó como un diferenciador. La función que proporciona el software diferencia productos, sistemas y servicios, y ofrece una ventaja competitiva en el mercado. Pero el software es más que un diferenciador. Los programas, documentos y datos que constituyen el software ayudan a generar el producto más importante que cualquier individuo, negocio o gobierno pueda adquirir: informa ción. Pressman y Herrón [PRE91] describen al software en la forma siguiente: El software d e computadora es u n a de sólo u n a s c u a n t a s tecnologías clave que tendrán un impacto significativo en casi cualquier a s p e c t o d e la sociedad moderna... Es un m e c a nismo para automatizar negocios, industrias y gobiernos, y un medio para transferir nueva tecnología, un método d e captura de experiencias valiosas p a r a q u e las utilicen otros, un medio para diferenciar los productos d e una compañía d e los d e s u s competidores, y u n a ventana al conocimiento colectivo de u n a corporación. El software es un pivote p a r a casi cualquier a s p e c t o d e los negocios. Pero, en m u c h a s formas, el s o f t w a r e también es una tecnología oculta. Se encuentra software (usualmente sin darse cuenta dTM e ello) c u a n d o se viaja al trabajo, se realiza alguna c o m p r a al m e n u d e o , se detiene en el banco, se hace una llamada telefónica, se visita al médico o se realiza alguna de las cientos d e actividades c o -

PDF Editor tidianas que reflejan la vida moderna.

La omnipresencia del software conduce a una conclusión simple: siempre que una tecnología tenga un amplio impacto (un impacto que pueda salvar vidas o ponerlas en peligro, construir negocios o destruirlos, informar a los líderes de gobiernos o mal informarlos) debe manejársele con cuidado.

CAPÍTULO 32

929


"Las predicciones son m u y difíciles d e hacer, especialmente c u a n d o se relacionan con el f u t u r o . "

Mark Twoin

32.2

EL Á M B I T O P E L C A M B I O Los cambios en la informática durante los pasados 50 años han sido dirigidos por avances en las ciencias básicas: física, química, ciencia de materiales e ingeniería. Esta tendencia continuará durante el primer cuarto del siglo xxi. El impacto de las nuevas tecnologías es profundo: en las comunicaciones, la energía, el cuidado de la salud, la transportación, el entretenimiento, la economía, la industria manufacturera y la guerra, por mencionar sólo unas cuantas.

INFORMACIÓN

Tecnologías a observar. Las tecnologías para mirar. • Los editores de PC Magazine [PCM03] preparan un número anual de "Tecnologías del futuro" que "[busca] a través de todos los espacios de chat (hay varios de ellos) identificar las 2 0 tecnologías más prometedoras del mañana". Las tecnologías registradas abarcan toda una amplia gama, desde el cuidado de la salud hasta la guerra. Sin embargo, es interesante observar que el software y la ingeniería del software tienen un significativo papel que jugar en todas, ya sea como impulsores de la tecnología o como una parte integral de ellas. Las siguientes representan una muestra de las tecnologías registradas:

soldados para supervisar la presencia de armas biológicas o químicas. P a n t a l l a s OLED. Un OLED (diodo emisor de luz orgánico) "utiliza una molécula diseñadora con base de carbono que emite luz cuando una corriente eléctrica pasa a través de ella. Junte muchas de estas moléculas y obtendrá una pantalla muy delgada de asombrosa calidad; no requiere fuente de luz trasera que provoca pérdidas de energía" [PCM03], El resultado: pantallas ultradelgadas que se pueden enrollar o doblar, extender sobre una superficie curva o adaptarse de alguna otra forma a un entorno específico.

N a n o t u b o s d e c a r b o n o . Con una fina estructura parecida al grafito, los nanotubos de carbono pueden funcionar como alambres, para transmitir señales desde un punto a otro, y como transistores, usando cambios de señal para almacenar información. El uso d e estos dispositivos parece prometedor en el desarrollo de dispositivos electrónicos más pequeños, más rápidos, de menor energía y menos costosos (por ejemplo, microprocesadores, memorias, pantallas).

Retícula d e c ó m p u t o . Esta tecnología (disponible en la actualidad) crea una red que aprovecha los miles de millones de ciclos de CPU no utilizados de cada máquina en la red y permite que se completen tareas de cómputo excesivamente complejas sin contar con una supercomputadora. Véase un ejemplo práctico que abarca 4.5 millones de computadoras en http://setiathome.berlceley.edu/.

B i o s e n s o r e s . Los sensores microelectrónicos, externos o implantables, ya se utilizan ampliamente en la detección, desde agentes químicos en el aire que se respira hasta niveles de sangre en pacientes cardiacos. Conforme estos'sensores se vuelvan más sofisticados, podrán implantarse en pacientes médicos para supervisar una variedad de condiciones relacionadas , con la salud, o incorporarlos a los uniformes de los

M á q u i n a s c o g n i t i v a s . El "santo grial" en el campo de la robótica es desarrollar máquinas que estén conscientes de su entorno, que puedan "recabar pistas, responder a situaciones siempre cambiantes e interactuar con personas de modo natural" [PCM03]. Las máquinas cognitivas todavía están en las primeras etapas de desarrollo, pero el potencial (si se logra alguna vez) es enorme.

TM

PDF Editor

PARTE C I N C O

930


A largo p l a z o , los a v a n c e s r e v o l u c i o n a r i o s e n la i n f o r m á t i c a b i e n p u e d e n dirigirPara predicciones acerco del futuro de ta tecnología y otros materias, véase

los las c i e n c i a s s o c i a l e s : psicología h u m a n a , sociología,

filosofía,

antropología y

www.futurefacing.

c o m e n z a d o (por e j e m p l o , las c o m u n i d a d e s — u n a e s t r u c t u r a a n t r o p o l ó g i c a — d e

com.

u s u a r i o s , q u e s o n r a m i f i c a c i o n e s de las r e d e s d e p a r e s a pares).

o t r a s . El p e r i o d o d e g e s t a c i ó n d e l a s t e c n o l o g í a s i n f o r m á t i c a s q u e s e p u e d a n d e r i v a r d e e s t a s disciplinas e s m u y difícil de p r e d e c i r , p e r o las p r i m e r a s i n f l u e n c i a s y a h a n

La i n f l u e n c i a d e l a s c i e n c i a s s o c i a l e s q u i z á a y u d e a m o l d e a r la d i r e c c i ó n d e la investigación e n i n f o r m á t i c a e n l a s c i e n c i a s b á s i c a s . Por e j e m p l o , el d i s e ñ o d e las f u t u r a s c o m p u t a d o r a s tal v e z lo g u í e m á s el c o n o c i m i e n t o d e la p s i c o l o g í a c e r e b r a l q u e el d e la m i c r o e l e c t r ó n i c a c o n v e n c i o n a l . A c o r t o p l a z o , los c a m b i o s q u e incidirán e n la i n g e n i e r í a del s o f t w a r e d u r a n t e la s i g u i e n t e d é c a d a recibirán la influencia d e c u a t r o f u e n t e s s i m u l t á n e a s : 1) las p e r s o n a s q u e r e a l i c e n el t r a b a j o , 2) el p r o c e s o q u e a p l i q u e n , 3) la n a t u r a l e z a d e la inform a c i ó n y 4) la t e c n o l o g í a i n f o r m á t i c a s u b y a c e n t e . En las s e c c i o n e s q u e s i g u e n s e e x a m i n a n c o n m á s detalle c a d a u n o d e e s t o s c o m p o n e n t e s : p e r s o n a s , p r o c e s o , información y tecnología.

32.3

L A S P E R S O N A S Y I.A F O R M A E N LA Q U E C O N S T R U Y E N S I S T E M A S El s o f t w a r e q u e r e q u i e r e n los s i s t e m a s d e alta t e c n o l o g í a s e vuelve m á s c o m p l e j o c a d a a ñ o , y el t a m a ñ o d e l o s p r o g r a m a s r e s u l t a n t e s a u m e n t a p r o p o r c i o n a l m e n t e . El r á p i d o c r e c i m i e n t o e n el t a m a ñ o del p r o g r a m a " p r o m e d i o " p r e s e n t a r í a p o c o s p r o b l e m a s si n o f u e s e p o r u n h e c h o s i m p l e : c o n f o r m e a u m e n t a el t a m a ñ o del p r o g r a m a , t a m b i é n d e b e a u m e n t a r el n ú m e r o d e p e r s o n a s q u e d e b e n t r a b a j a r e n él. La e x p e r i e n c i a indica q u e c o n f o r m e a u m e n t a el n ú m e r o d e p e r s o n a s d e u n e q u i p o d e p r o y e c t o d e s o f t w a r e , tal v e z la p r o d u c t i v i d a d g l o b a l del g r u p o d i s m i n u y a . U n a f o r m a 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 o n s i s t e e n c r e a r e q u i p o s d e i n g e n i e r í a del s o f t w a r e , y e n c o n s e c u e n c i a dividir al p e r s o n a l e n g r u p o s d e t r a b a j o individuales. Sin e m b a r g o , c o n f o r m e c r e c e el n ú m e r o d e e q u i p o s d e t r a b a j o d e ingeniería del s o f t w a re, la c o m u n i c a c i ó n e n t r e ellos se v u e l v e ta n difícil y t a r d a d a c o m o la c o m u n i c a c i ó n e n t r e los individuos. Peor a ú n , la c o m u n i c a c i ó n (entre i n d i v i d u o s o e q u i p o s ) t i e n d e a s e r i n e f i c i e n t e ; e s decir, s e p a s a d e m a s i a d o t i e m p o t r a n s f i r i e n d o m u y p o c o c o n t e n i d o de i n f o r m a c i ó n , y c o n m u c h a f r e c u e n c i a la i n f o r m a c i ó n i m p o r t a n t e " c a e e n t r e l a s grietas".

TM "El choque del futuro es lo agotadora tensión y desorientación que inducimos en los individuos al sujetarlos o demasiados cambios en un periodo demasiado corto." Atvin Toffler

PDF Editor

Si la c o m u n i d a d d e la i n g e n i e r í a del s o f t w a r e t i e n e q u e t r a t a r c o n eficacia el dile-

m a d e la c o m u n i c a c i ó n , el c a m i n o q u e r e c o r r e r á n los i n g e n i e r o s d e s o f t w a r e d e b e incluir c a m b i o s r a d i c a l e s e n la f o r m a e n q u e los i n d i v i d u o s y l o s e q u i p o s s e c o m u n i c a n e n t r e sí. El c o r r e o e l e c t r ó n i c o , los sitios W e b y l a s c o n f e r e n c i a s de v i d e o c e n t r a -

CAPÍTULO 32

931


l i z a d a s a h o r a s o n m e c a n i s m o s c o m u n e s p a r a c o n e c t a r a u n g r a n n ú m e r o de p e r s o n a s a u n a red d e i n f o r m a c i ó n . La i m p o r t a n c i a d e e s t a s h e r r a m i e n t a s e n el c o n t e x t o del t r a b a j o d e i n g e n i e r í a del s o f t w a r e n o s e d e b e s o b r e v a l u a r . Con u n c o r r e o e l e c t r ó n i c o e f i c i e n t e o u n s i s t e m a d e m e n s a j e r í a i n s t a n t á n e a , el p r o b l e m a q u e e n c u e n tre u n i n g e n i e r o d e s o f t w a r e e n la c i u d a d de Nueva York p u e d e r e s o l v e r s e c o n la a y u d a d e u n c o l e g a e n Tokio. En r e a l i d a d , las s e s i o n e s d e c o n v e r s a c i ó n [chat]

sobre

u n t e m a p a r t i c u l a r y l o s g r u p o s de n o t i c i a s e s p e c i a l i z a d o s se v u e l v e n d e p ó s i t o s d e c o n o c i m i e n t o q u e p e r m i t e n q u e el s a b e r colectivo d e u n g r a n g r u p o d e t é c n i c o s s e a a p l i c a d o p a r a s o l u c i o n a r u n p r o b l e m a t é c n i c o o u n c o n f l i c t o de gestión. El v i d e o p e r s o n a l i z a la c o m u n i c a c i ó n . En el m e j o r d e los c a s o s , p e r m i t e q u e los c o l e g a s e n d i f e r e n t e s u b i c a c i o n e s (o e n d i f e r e n t e s c o n t i n e n t e s ) se " r e ú n a n " c o n cier ta r e g u l a r i d a d . A d e m á s , el v i d e o t a m b i é n o f r e c e o t r o b e n e f i c i o : se p u e d e u s a r c o m o d e p ó s i t o d e c o n o c i m i e n t o a c e r c a del s o f t w a r e y p a r a e n t r e n a r a los recién l l e g a d o s a un proyecto. "Lo respuesta artístico adecuada ante la tecnología digital es adoptarla como una nueva ventano a todo lo eternamente humano, y usarla con pasión, sabiduría, temeridad y alegría." Ralph Lambreglia

^CONSEJO^

Másymós'no programadores" están construyendo sus propias (pequeños) aplicaciones. Esta tendencia actual es probable que se acelere en lo futuro. ¿Estosíciviles' deberían aplicar la tecnología estudiado en este libro? Probablemente no. Pero deberían adoptar uno filosofía de ingeniería del software ágil, incluso si no adoptan la práctica.

La e v o l u c i ó n d e los a g e n t e s i n t e l i g e n t e s t a m b i é n c a m b i a r á los p a t r o n e s l a b o r a l e s de un i n g e n i e r o de s o f t w a r e al e x t e n d e r s u s t a n c i a l m e n t e las c a p a c i d a d e s d e las h e r r a m i e n t a s d e s o f t w a r e . Los a g e n t e s i n t e l i g e n t e s m e j o r a r á n la habilidad del ingen i e r o al c o m p r o b a r v a r i a s v e c e s los p r o d u c t o s d e t r a b a j o d e ingeniería e m p l e a n d o c o n o c i m i e n t o e s p e c í f i c o del d o m i n i o , r e a l i z a n d o t a r e a s a d m i n i s t r a t i v a s , l l e v a n d o a c a b o u n a i n v e s t i g a c i ó n dirigida y c o o r d i n a n d o la c o m u n i c a c i ó n e n t r e las p e r s o n a s . F i n a l m e n t e , la a d q u i s i c i ó n de c o n o c i m i e n t o e s t á c a m b i a n d o e n f o r m a radical. En I n t e r n e t , u n i n g e n i e r o de s o f t w a r e p u e d e s u s c r i b i r s e a g r u p o s de noticias q u e se e n f o q u e n e n á r e a s d e t e c n o l o g í a q u e le i n t e r e s e n d i r e c t a m e n t e . Una p r e g u n t a e n v i a da a u n g r u p o de noticias precipita las r e s p u e s t a s de o t r a s p a r t e s i n t e r e s a d a s a l r e d e d o r del m u n d o . La World Wide W e b o f r e c e a u n i n g e n i e r o d e s o f t w a r e la m á s g r a n d e biblioteca del m u n d o de t r a b a j o s e i n f o r m e s d e i n v e s t i g a c i ó n , m a n u a l e s , c o m e n t a r i o s y r e f e r e n c i a s a c e r c a d e la ingeniería del s o f t w a r e . Si la historia e s u n indicio, e s a c e r t a d o decir q u e las p e r s o n a s n o c a m b i a r á n . Sin e m b a r g o , las f o r m a s e n las q u e s e c o m u n i c a n , el e n t o r n o e n el q u e t r a b a j a n , la m a n e r a e n la q u e a d q u i e r e n c o n o c i m i e n t o , los m é t o d o s y h e r r a m i e n t a s q u e u s a n , la dis-

TM

ciplina q u e aplican y, p o r lo t a n t o , la cultura g e n e r a l del d e s a r r o l l o del s o f t w a r e c a m b i a r á n e n f o r m a s significativas e i n c l u s o p r o f u n d a s .

PDF Editor 3 2 . 4

EL "NUEYQ" P R O C E S O

DE

INGENIERIA

DEL

SOFTWARE

Es r a z o n a b l e c a r a c t e r i z a r las p r i m e r a s d o s d é c a d a s d e la p r á c t i c a d e la ingeniería del

s o f t w a r e c o m o la e r a del " p e n s a m i e n t o lineal' F o m e n t a d a p o r el m o d e l o c l á s i c o del ciclo vital, la i n g e n i e r í a del s o f t w a r e s e e n f o c ó c o m o u n a actividad lineal e n la q u e

932

PARTE C I N C O


se p o d r í a n a p l i c a r u n a serie de p a s o s s e c u e n c i a l e s c o n la finalidad d e r e s o l v e r p r o b l e m a s c o m p l e j o s . Sin e m b a r g o , l o s e n f o q u e s l i n e a l e s a c e r c a del d e s a r r o l l o d e s o f t w a r e c o r r e n c o n t r a la f o r m a e n la q u e la m a y o r í a d e los s i s t e m a s r e a l m e n t e s e c o n s truye. En r e a l i d a d , los s i s t e m a s c o m p l e j o s e v o l u c i o n a n i t e r a t i v a m e n t e , i n c l u s o e n f o r m a i n c r e m e n t a ! . Por e s t a r a z ó n , un g r a n s e g m e n t o d e la c o m u n i d a d de i n g e n i e ría del s o f t w a r e s e d e s p l a z a h a c i a m o d e l o s i n c r e m é n t a l e s ágiles p a r a el d e s a r r o l l o del s o f t w a r e . Los m o d e l o s d e p r o c e s o i n c r e m e n t a l ágil r e c o n o c e n q u e la i n c e r t i d u m b r e d o m i n a la m a y o r í a d e los p r o y e c t o s , q u e los p l a z o s d e e n t r e g a c o n f r e c u e n c i a s o n i m p o s i b l e s de cumplir y cortos, y q u e la iteración p r o p o r c i o n a la habilidad de d a r u n a solución parcial, incluso c u a n d o u n p r o d u c t o c o m p l e t o n o e s realizable d e n t r o del t i e m p o asign a d o . Los m o d e l o s evolutivos s u b r a y a n la n e c e s i d a d d e p r o d u c t o s de t r a b a j o increm é n t a l e s , análisis de riesgo, p l a n e a c i ó n y l u e g o revisión del plan, y r e t r o a l i m e n t a c i ó n c o n el cliente. En m u c h o s c a s o s el e q u i p o d e s o f t w a r e aplica u n " m a n i f i e s t o ágil" (capítulo 4) q u e s u b r a y a "los i n d i v i d u o s e i n t e r a c c i o n e s s o b r e los p r o c e s o s y h e r r a m i e n t a s ; el s o f t w a r e o p e r a t i v o s o b r e la d o c u m e n t a c i ó n d e t a l l a d a ; la c o l a b o r a c i ó n del c lie n te s o b r e la n e g o c i a c i ó n d e c o n t r a t o s ; y la r e s p u e s t a al c a m b i o s o b r e el s e g u i m i e n t o d e u n p l a n " [BEC01]. "La mejor preparación para el buen trabajo m a ñ a n a es hacer un buen trabajo hoy." Elbert Hubbard

Las t e c n o l o g í a s de o b j e t o s , j u n t o c o n la i n g e n i e r í a del 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 (capítulo 30), s o n u n a c o n s e c u e n c i a n a t u r a l d e la t e n d e n c i a h a c i a los m o d e l o s de p r o c e s o s i n c r e m e n t a l e s y evolutivos. A m b o s t e n d r á n u n p r o f u n d o i m p a c t o s o b r e la p r o d u c t i v i d a d del d e s a r r o l l o d e s o f t w a r e y la c a l i d a d del p r o d u c t o . La reutilización de c o m p o n e n t e s o f r e c e b e n e f i c i o s i n m e d i a t o s y c o n v i n c e n t e s . C u a n d o la reutilización s e u n e c o n las h e r r a m i e n t a s CASE p a r a los p r o t o t i p o s d e u n a aplicación, los i n c r e m e n t o s del p r o g r a m a s e p u e d e n c o n s t r u i r m u c h o m á s r á p i d a m e n t e q u e m e d i a n t e los e n f o q u e s c o n v e n c i o n a l e s . La e l a b o r a c i ó n de p r o t o t i p o s i n v o l u c r a al cl i ente c o n el p r o c e s o . En c o n s e c u e n c i a , e s p r o b a b l e q u e los c l i e n t e s y u s u a r i o s s e i n v o l u c r e n m u c h o m á s e n el d e s a r r o l l o del s o f t w a r e . Esto, a s u v e z , p u e d e c o n d u c i r a u n a m a y o r s a t i s f a c c i ó n del u s u a r i o final y e n g e n e r a l a m e j o r a r la c a l i d a d del s o f t w a r e . El r á p i d o c r e c i m i e n t o e n l a s t e c n o l o g í a s d e red y m u l t i m e dTM i a (por e j e m p l o , el a u m e n t o exponencial en las WebApps durante las p a s a d a s décadas) está cambiand o t a n t o al p r o c e s o de i n g e n i e r í a del s o f t w a r e c o m o a s u s p a r t i c i p a n t e s . De n u e v o ,

PDF Editor

se e s t á a n t e un p a r a d i g m a i n c r e m e n t a l ágil q u e d e s t a c a la i n m e d i a t e z , la s e g u r i d a d

y la e s t é t i c a , así c o m o p r e o c u p a c i ó n p o r la i n g e n i e r í a d e s o f t w a r e m á s c o n v e n c i o nal. Los m o d e r n o s e q u i p o s d e s o f t w a r e (por e j e m p l o , u n e q u i p o d e i n g e n i e r í a Web) c o n f r e c u e n c i a m e z c l a n t é c n i c o s c o n e s p e c i a l i s t a s d e c o n t e n i d o (por e j e m p l o , artistas, m ú s i c o s , v i d e o g r á f o s ) p a r a c o n s t r u i r u n a f u e n t e d e i n f o r m a c i ó n d e s t i n a d a a u n a

CAPÍTULO 32

933


c o m u n i d a d de u s u a r i o s g r a n d e e i m p r e d e c i b l e . El s o f t w a r e q u e s e h a d e s a r r o l l a d o con base e n estas tecnologías ha g e n e r a d o radicales c a m b i o s e c o n ó m i c o s y culturales. A u n q u e l o s c o n c e p t o s y p r i n c i p i o s b á s i c o s t r a t a d o s e n e s t e libro s o n a p l i c a b l e s , el p r o c e s o d e i n g e n i e r í a del s o f t w a r e se d e b e a d a p t a r .

A lo l a r g o d e la h i s t o r i a d e la i n f o r m á t i c a h a o c u r r i d o u n a t r a n s i c i ó n sutil e n la t e r m i n o l o g í a c o n q u e se d e s c r i b e el t r a b a j o d e d e s a r r o l l o del s o f t w a r e r e a l i z a d o p a r a la c o m u n i d a d d e n e g o c i o s . H a c e c u a r e n t a a ñ o s , el t é r m i n o procesamiento

de datos

era

la f r a s e o p e r a t i v a p a r a describir la utilización d e las c o m p u t a d o r a s e n u n c o n t e x t o de n e g o c i o s . En la a c t u a l i d a d , el p r o c e s a m i e n t o d e d a t o s h a d a d o p a s o a o t r a f r a s e —tecnología

de la información—

q u e significa lo m i s m o p e r o p r e s e n t a u n sutil c a m -

bio e n el e n f o q u e . La i m p o r t a n c i a r a d i c a n o s ó l o e n p r o c e s a r g r a n d e s c a n t i d a d e s d e d a t o s , s i n o e n o b t e n e r i n f o r m a c i ó n significativa d e d i c h o s d a t o s . O b v i a m e n t e , é s t a f u e s i e m p r e la finalidad, p e r o el c a m b i o e n la t e r m i n o l o g í a refleja u n c a m b i o m u c h o m á s i m p o r t a n t e e n la filosofía de la g e s t i ó n . C u a n d o en la a c t u a l i d a d s e a b o r d a n l a s a p l i c a c i o n e s de s o f t w a r e las p a l a b r a s datos

e información

a p a r e c e n r e p e t i d a m e n t e . La p a l a b r a conocimiento

se encuentra

e n a l g u n a s a p l i c a c i o n e s d e inteligencia artificial, p e r o su utilización e s r e l a t i v a m e n te e s c a s a . V i r t u a l m e n t e n a d i e s e r e f i e r e a la sabiduría

e n el c o n t e x t o d e las a p l i c a -

c i o n e s de s o f t w a r e . Los d a t o s s o n i n f o r m a c i ó n e n b r u t o : c o l e c c i o n e s d e h e c h o s q u e d e b e n p r o c e s a r se p a r a q u e s e a n significativos. La i n f o r m a c i ó n s e d e r i v a al a s o c i a r l o s h e c h o s e n u n

Espectro de "información". Datos: sin asociatividad

Información: asociatividad dentro de un contexto

TM

PDF Editor asociatividad dentro d e múltiples contextos

creación d e principios generalizados con base en el conocimiento procedente de fuentes diferentes

934

PARTE C I N C O


c o n t e x t o d a d o . El c o n o c i m i e n t o a s o c i a la i n f o r m a c i ó n o b t e n i d a e n u n c o n t e x t o c o n o t r a i n f o r m a c i ó n o b t e n i d a e n u n c o n t e x t o d i f e r e n t e . F i n a l m e n t e , la s a b i d u r í a s e p r e s e n t a c u a n d o los p r i n c i p i o s g e n e r a l i z a d o s s e d e r i v a n d e c o n o c i m i e n t o s d i s p a r e s . C a d a u n a d e e s t a s c u a t r o v i s i o n e s d e la " i n f o r m a c i ó n " s e r e p r e s e n t a e s q u e m á t i c a m e n t e e n la figura 32.1. A la f e c h a , la g r a n m a y o r í a del s o f t w a r e s e h a c o n s t r u i d o p a r a p r o c e s a r d a t o s o i n f o r m a c i ó n . Los i n g e n i e r o s d e s o f t w a r e a h o r a e s t á n i g u a l m e n t e p r e o c u p a d o s c o n los s i s t e m a s q u e p r o c e s a n el c o n o c i m i e n t o . 1 £1 c o n o c i m i e n t o e s b i d i m e n s i o n a l . La i n f o r m a c i ó n r e c o p i l a d a a c e r c a de u n a d i v e r s i d a d d e t e m a s r e l a c i o n a d o s e i n c o n e x o s s e r e l a c i o n a p a r a f o r m a r u n c u e r p o d e h e c h o s q u e s e l l a m a r á conocimiento.

La c l a v e

e s la h a b i l i d a d p e r s o n a l p a r a a s o c i a r la i n f o r m a c i ó n p r o v e n i e n t e d e d i v e r s a s f u e n t e s , q u e tal v e z n o t e n g a n a l g u n a c o n e x i ó n e v i d e n t e , y c o m b i n a r l a e n u n a f o r m a q u e o f r e z c a a l g ú n b e n e f i c i o distinto.

"La sabiduría es el p o d e r q u e p e r m i t e utilizar el conocimiento pora el beneficio d e nosotros m i s m o s y d e otros." Thomas J. W a f s o n Para ilustrar la p r o g r e s i ó n d e s d e d a t o s h a s t a c o n o c i m i e n t o , c o n s i d é r e n s e los d a t o s c e n s a l e s q u e i n d i c a n q u e los n a c i m i e n t o s e n 1996 e n E s t a d o s U n i d o s f u e r o n 4 . 9 m i l l o n e s . Este n ú m e r o r e p r e s e n t a un v a l o r d e d a t o s . Al r e l a c i o n a r e s t a p i e z a d e datos con las t a s a s de nacimiento para los 40 a ñ o s precedentes, s e p u e d e derivar u n a útil p i e z a d e información-, los c a d a v e z m á s v i e j o s baby

boomers

d e la d é c a d a d e

1950 y d e p r i n c i p i o s d e la d e 1960 h a c í a n u n ú l t i m o e s f u e r z o p a r a t e n e r h i j o s a n t e s del final de s u vida r e p r o d u c t i v a . A d e m á s , los g e n - X e r s ( m i e m b r o s d e la g e n e r a c i ó n X) c o m e n z a b a n su vida r e p r o d u c t i v a . Los d a t o s c e n s a l e s e n t o n c e s p u e d e n vinculars e c o n o t r a s p i e z a s d e i n f o r m a c i ó n a p a r e n t e m e n t e n o r e l a c i o n a d a . Por e j e m p l o , el n ú m e r o a c t u a l d e p r o f e s o r e s d e e s c u e l a e l e m e n t a l q u e s e r e t i r a r á n d u r a n t e la s i g u i e n t e d é c a d a , el n ú m e r o de e s t u d i a n t e s u n i v e r s i t a r i o s q u e s e g r a d u a r á n e n e d u c a c i ó n p r i m a r i a y s e c u n d a r i a , la p r e s i ó n s o b r e los políticos p a r a m a n t e n e r b a j o s l o s i m p u e s t o s y, p o r lo t a n t o , limitar los a u m e n t o s s a l a r i a l e s a los p r o f e s o r e s . Todos estos elementos d e información se pueden combinar para formular una r e p r e s e n t a c i ó n del c o n o c i m i e n t o : existirá u n a p r e s i ó n significativa s o b r e el s i s t e m a e d u c a t i v o e n E s t a d o s U n i d o s e n la p r i m e r a d é c a d a del siglo xxi, y e s t a p r e s i ó n c o n t i n u a r á d u r a n t e u n a d é c a d a . Con la utilización d e e s t e c o n o c i m i e n t o p u e d e surgir u n a o p o r t u n i d a d de n e g o c i o . Q u i z á h a y a significativas o p o r t u n i d aTM des para desarrollar n u e v o s m o d o s d e a p r e n d i z a j e q u e s e a n m á s e f i c a c e s y m e n o s c o s t o s o s q u e los e n f o q u e s actuales.

PDF Editor 1

El rápido crecimiento de las tecnologías de extracción y almacenamiento de datos refleja esta ten-

dencia creciente.

CAPÍTULO 32


935

El c a m i n o q u e recorrerá el s o f t w a r e c o n d u c e a s i s t e m a s q u e p r o c e s a n el c o n o c i m i e n t o . Se h a n e s t a d o p r o c e s a n d o d a t o s e m p l e a n d o c o m p u t a d o r a s d u r a n t e 50 a ñ o s y e x t r a y e n d o información d u r a n t e m á s de tres d é c a d a s . Uno de los desafios m á s significativos que enfrenta la c o m u n i d a d de ingeniería del software e s construir s i s t e m a s q u e d e n el p r ó x i m o p a s o a lo largo del espectro: s i s t e m a s q u e extraigan conocim i e n t o a partir d e los d a t o s e información en u n a forma práctica y beneficiosa.

La g e n t e q u e construye y utiliza s o f t w a r e , el p r o c e s o d e ingeniería del s o f t w a r e q u e s e aplica y la información q u e s e p r o d u c e resultan a f e c t a d o s por los a v a n c e s en el h a r d w a r e y la tecnología del s o f t w a r e . Históricamente, el h a r d w a r e ha servido c o m o el impulsor tecnológico en la c o m p u t a c i ó n . Una n u e v a tecnología d e h a r d w a r e proporciona potencial. E n t o n c e s los c o n s t r u c t o r e s d e s o f t w a r e r e a c c i o n a n a las d e m a n d a s d e los c o n s u m i d o r e s con la finalidad de a p r o v e c h a r el potencial. Es p r o b a b l e q u e las t e n d e n c i a s f u t u r a s d e la tecnología d e h a r d w a r e a v a n c e n por d o s trayectorias paralelas. A lo largo d e u n a trayectoria las t e c n o l o g í a s d e h a r d w a r e c o n t i n u a r á n e v o l u c i o n a n d o c o n rapidez. Ante la mayor c a p a c i d a d q u e o f r e c e n las a r q u i t e c t u r a s de h a r d w a r e tradicionales, las d e m a n d a s a los i n g e n i e r o s d e s o f t w a r e c o n t i n u a r á n creciendo. Pero los c a m b i o s v e r d a d e r o s en la tecnología d e h a r d w a r e podrían producirse en otra dirección. El desarrollo de a r q u i t e c t u r a s d e h a r d w a r e n o tradicionales (por ejemplo, n a n o t u b o s d e c a r b o n o , m i c r o p r o c e s a d o r e s EUL, m á q u i n a s cognitivas, retículas d e cómputo) podrían p r o v o c a r c a m b i o s radicales en el tipo de s o f t w a r e q u e s e construirá y c a m b i o s f u n d a m e n t a l e s en el e n f o q u e hacia la ingeniería del s o f t w a r e . D a d o q u e e s t o s e n f o q u e s n o tradicionales s e e s t á n m a d u r a n d o , e s difícil d e t e r m i n a r cuál t e n d r á un i m p a c t o significativo e incluso e s m á s difícil predecir c ó m o c a m b i a r á el m u n d o del s o f t w a r e p a r a a d a p t a r s e a ellos. Las t e n d e n c i a s futuras d e la ingeniería del s o f t w a r e las impulsan las tecnologías de s o f t w a r e . La reutilización y la ingeniería 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 o f r e c e n la mejor oportunidad en c u a n t o a m e j o r a s en la magnitud d e la calidad de los s i s t e m a s y en el t i e m p o en q u e llegan al m e r c a d o . De hecho, c o n f o r m e p a s a el tiempo, el n e g o c i o del s o f t w a r e p u e d e c o m e n z a r a p a r e c e r s e m u c h o al n e g o c i o d e h a r d w a r e d e la actualidad. Quizá haya e m p r e s a s q u e c o n s t r u y a n dispositivos discretos ( c o m p o n e n t e s de s o f t w a r e reutilizables), o t r a s e m p r e s a s TM que construyan c o m p o n e n t e s d e s i s t e m a s (por ejemplo, un c o n j u n t o d e h e r r a m i e n t a s para la interacción h o m b r e - m á q u i n a ) e integradores d e s i s t e m a s q u e o f r e z c a n s o l u c i o n e s (pro-

PDF Editor

d u c t o s y s i s t e m a s c o n s t r u i d o s d e f o r m a personalizada) p a r a el u s u a r i o final. La ingeniería del s o f t w a r e c a m b i a r á , de e s o s e p u e d e e s t a r seguro. Pero, sin

importar c u á n radicales s e a n los c a m b i o s , s e p u e d e e s t a r s e g u r o d e q u e la calidad n u n c a p e r d e r á su importancia, y d e q u e el análisis y el d i s e ñ o efectivos y las p r u e -

b a s c o m p e t e n t e s s i e m p r e t e n d r á n un lugar en el desarrollo de los s i s t e m a s b a s a d o s en computadoras.

PARTE C I N C O

936


INFORMACIÓN

Tendencias tecnológicas P. Cripwell Associates (www.jpcripwell.com), una firma de consultorio especializada en gestión del conocimiento e ingeniería de la información, analiza cinco impulsores tecnológicos que influirán en las direcciones de la tecnología en los años por venir. C o m b i n a c i ó n d e t e c n o l o g í a s . Cuando dos importantes tecnologías se funden, el impacto del resultado con frecuencia es mayor que la suma del impacto de cada una por separado. Por ejemplo, la tecnología de los satélites GPS (sistemas de posicionamiento global) junto con la capacidad de cómputo a bordo y las tecnologías de pantallas LCD han permitido construir sofisticados sistemas de localización en los automóviles. Las tecnologías con frecuencia evolucionan a rutas separadas, pero el impacto en los negocios o social significativo sólo ocurre cuando alguien los combina para resolver un problema. Fusión d e d a t o s . Mientras más datos se adquieran, más datos se necesitarán. Más importante aún, mientras más datos se adquieran, más difícil es extraer información útil. De hecho, con frecuencia se necesita adquirir todavía más datos para comprender qué datos son importantes; qué datos son relevantes para una necesidad o fuente particular, y qué datos se deben emplear para la toma d e decisiones. Este es el problema de la fusión de datos. J. P. Cripwell utiliza como ejemplo un sistema avanzado d e supervisión de tráfico automovilístico. Sensores digitales de rapidez (en el camino) y cámaras digitales detectan un a c c i d e n t e . La s e v e r i d a d del a c c i d e n t e se d e b e d e t e r m i n a r

(¿a través d e las cámaras?). Con base en la severidad, el sistema de supervisión debe contactar a la policía, los bomberos o ambulancias; el tráfico se debe redirigir; los medios de comunicación (radio) deben difundir

3 2 . 7

LA

RESPONSABILIDAD

advertencias; y debe informárseles a los automóviles individuales (si están equipados con sensores digitales o comunicación inalámbrica). Para lograrlo se debe tomar una variedad d e decisiones, con base en los datos adquiridos a partir del sistema de supervisión (fusión de datos). T e c n o l o g í a d e e m p u j e . En años pasados surgió un problema y se desarrolló tecnología para resolverlo. Puesto que el problema era evidente para muchas personas, el mercado para la nueva tecnología estaba bien definido. En la actualidad, algunas tecnologías evolucionan como soluciones que buscan problemas. Un mercado debe empujarse para reconocer que necesita la nueva tecnología (por ejemplo, teléfonos móviles, PDA). Conforme las personas reconocen la necesidad, la tecnología se acelera, mejora y con frecuencia se transforma conforme evoluciona la combinación de tecnologías. Red y c a s u a l i d a d . En este contexto, red implica conexiones entre personas o entre personas e información. Conforme crece la red, la probabilidad de sinergia entre dos nodos de red (por ejemplo, personas, fuentes de información) también crece. Una conexión fortuita (casual) puede conducir a una inspiración y a nueva tecnología o aplicación. S o b r e c a r g a d e i n f o r m a c i ó n . Un amplio océano de información está a disposición de cualquiera con una conexión de Internet. El problema, desde luego, es encontrar la información correcta, determinar su validez y luego traducirla en una aplicación práctica en un ámbito de negocios o personal.

DE LA I N G E N I E R Í A

DEL S O F T W A R E

La ingeniería del s o f t w a r e ha e v o l u c i o n a d o en u n a profesión r e sTM p e t a d a e n el á m b i t o mundial. C o m o profesionales, los ingenieros d e s o f t w a r e d e b e n regirse por un código d e ética q u e guíe el t r a b a j o q u e realizan y los p r o d u c t o s q u e p r o d u c e n . Una

PDF Editor je! código de ético 1CM/1EEE se puede

¡ncontroien

fuerza de trabajo conjunto ACM/IEEE-CS ha producido un Código

profesional

para los ingenieros

de software

de ética y práctica

(versión 5.1). El código [ACM98] afirma:

SMri.itsg.edu/

Los ingenieros d e software se deben c o m p r o m e t e r a sí m i s m o s a convertir el análisis, la

Codes/defoult.

especificación, el diseño, el desarrollo, la prueba y el m a n t e n i m i e n t o del software en u n a profesión beneficiosa y respetada. En concordancia c o n su c o m p r o m i s o c o n la salud, la

CAPÍTULO 32

937


seguridad y el b i e n e s t a r del público, los ingenieros de s o f t w a r e deben a d h e r i r s e a los siguientes Ocho Principios: 1. PÚBLICO. Los ingenieros d e s o f t w a r e d e b e n a c t u a r c o n s i s t e n t e m e n t e con el interés del público. 2. CLIENTES Y EMPLEADORES. Los ingenieros de s o f t w a r e d e b e n a c t u a r e n u n a forma q u e beneficie los i n t e r e s e s d e s u s clientes y e m p l e a d o r e s y s e a consistente c o n el interés p ú blico. 3. PRODUCTO. Los ingenieros de s o f t w a r e d e b e n g a r a n t i z a r q u e sus p r o d u c t o s y modific a c i o n e s r e l a c i o n a d a s satisfacen los m a y o r e s e s t á n d a r e s profesionales posibles. 4. JUICIO. Los ingenieros d e s o f t w a r e d e b e n m a n t e n e r la integridad y la i n d e p e n d e n c i a e n su juicio profesional. 5. GESTIÓN. Los g e s t o r e s y líderes d e la ingeniería del s o f t w a r e deben suscribir y p r o m o ver un e n f o q u e ético d e la gestión del desarrollo y el m a n t e n i m i e n t o del s o f t w a r e . 6. PROFESIÓN. Los ingenieros de s o f t w a r e d e b e n p r o m o v e r la integridad y la b u e n a reputación d e la profesión e n u n a forma c o n s i s t e n t e con el interés público. 7. COLEGAS. Los ingenieros de s o f t w a r e d e b e n ser j u s t o s con s u s c o l e g a s y apoyarlos. 8. COMPROMISO PERSONAL. Los ingenieros d e s o f t w a r e d e b e n participar e n u n a p r e n d i z a j e p e r m a n e n t e e n relación con la práctica de su profesión y p r o m o v e r u n e n f o q u e ético p a r a s u práctica.

A u n q u e c a d a u n o de e s t o s o c h o principios e s i g u a l m e n t e importante, a p a r e c e un t e m a m á s relevante: un ingeniero d e s o f t w a r e d e b e trabajar en pro del interés público. En el á m b i t o p e r s o n a l , un ingeniero d e s o f t w a r e d e b e a t e n e r s e a las s i g u i e n t e s reglas: • Nunca robar d a t o s p a r a beneficio personal. • Nunca distribuir o v e n d e r información p a t e n t a d a q u e h a y a o b t e n i d o c o m o p a r t e d e su t r a b a j o en un proyecto d e s o f t w a r e . • Nunca destruir o modificar m a l i c i o s a m e n t e los p r o g r a m a s , archivos o d a t o s d e otra p e r s o n a . • Nunca violar la privacidad de un individuo, grupo u o r g a n i z a c i ó n . • Nunca atacar

un s i s t e m a por deporte o beneficio.

• Nunca crear o difundir un virus o g u s a n o de c o m p u t a d o r a . • Nunca u s a r la tecnología d e c o m p u t a c i ó n p a r a facilitar la discriminación o el

TM

hostigamiento. D u r a n t e la d é c a d a p a s a d a , ciertos m i e m b r o s de la industria del s o f t w a r e h a n

PDF Editor c a b i l d e a d o por u n a legislación protectora q u e [SEE03]:

1. Permita a las c o m p a ñ í a s liberar el s o f t w a r e sin revelar los d e f e c t o s conocidos.

2.

Exentar a los d e s a r r o l l a d o r e s d e responsabilidad p e n a l por c u a l e s q u i e r a d a ñ o s q u e resulten debido a d i c h o s d e f e c t o s conocidos.

938

PARTE C I N C O

3.


Restringir a o t r o s la revelación d e d e f e c t o s sin p e r m i s o del desarrollador original.

4.

Permitir la incorporación d e s o f t w a r e d e "autoayuda" d e n t r o de un p r o d u c t o q u e p u e d a desactivar (vía c o m a n d o s remotos) la o p e r a c i ó n del producto.

5.

Exentar a los d e s a b o l l a d o r e s de s o f t w a r e c o n "autoayuda" d e los d a ñ o s en c a s o d e q u e el s o f t w a r e lo desactive u n a tercera p e r s o n a .

Al igual q u e con cualquier legislación, el debate con frecuencia s e centra en conflictos políticos, n o tecnológicos. Sin embargo, m u c h a gente (incluso este autor) considera q u e la legislación protectora, si s e p r o p o n e d e m a n e r a i n a d e c u a d a , entra en c o n flicto con el código d e ética d e la ingeniería del s o f t w a r e al e x e n t a r i n d i r e c t a m e n t e a los ingenieros de s o f t w a r e d e su responsabilidad para producir s o f t w a r e d e alta calidad.

Ya h a n p a s a d o 25 a ñ o s d e s d e q u e s e escribió la primera edición d e este libro. Todavía m e r e c u e r d o s e n t a d o en mi escritorio c o m o un joven profesor, escribiendo el m a n u s crito d e un libro a c e r c a de u n a materia de la q u e p o c a g e n t e se p r e o c u p a b a e inclus o todavía m e n o s r e a l m e n t e c o m p r e n d í a . Recuerdo las c a r t a s d e r e c h a z o d e los editores, q u i e n e s a r g u m e n t a b a n (gentil, p e r o firmemente) q u e n u n c a habría un m e r c a d o para un libro a c e r c a d e "ingeniería del software". A f o r t u n a d a m e n t e , McGraw-Hill decidió darle u n a oportunidad, 2 y el resto, c o m o dicen, e s historia. D u r a n t e los p a s a d o s 25 a ñ o s , e s t e libro h a c a m b i a d o s u s t a n c i a l m e n t e : en a l c a n ce, en t a m a ñ o , en estilo y en contenido. Al igual q u e la ingeniería del s o f t w a r e , ha crecido y (espero) m a d u r a d o c o n los a ñ o s . Un e n f o q u e de ingeniería p a r a el desarrollo del s o f t w a r e d e c o m p u t a d o r a e s a h o r a sabiduría convencional. A u n q u e el d e b a t e continúa a c e r c a del "paradigma correcto", la importancia d e la agilidad, el g r a d o de a u t o m a t i z a c i ó n y los m é t o d o s m á s efectivos, los principios s u b y a c e n t e s d e la ingeniería del s o f t w a r e a h o r a s o n a c e p t a d o s a lo largo d e la industria. ¿Por qué, e n t o n c e s , s e ha visto su amplia aceptación sólo recientemente? La respuesta, creo, s e e n c u e n t r a en la dificultad d e la transición tecnológica y el c a m b i o cultural q u e la a c o m p a ñ a . Aun c u a n d o la mayoría d e las p e r s o n a s aprecian la n e c e s i d a d de u n a disciplina de ingeniería para el s o f t w a r e , s e lucha c o n t r a la inerTM cia de la práctica p a s a d a y se e n f r e n t a n n u e v o s d o m i n i o s d e aplicación (y los d e s a rrolladores que t r a b a j a n en ellos), que parecen listos a repetir los errores del p a s a d o .

PDF Editor 2

En realidad, el crédito corresponde a Peter Freeman y Eric Munson, quienes convencieron a McGraw-

Hill de q u e valía la pena intentarlo.

CAPÍTULO 32

939


P a r a f a c i l i t a r la t r a n s i c i ó n s e n e c e s i t a n m u c h a s c o s a s : u n p r o c e s o d e s o f t w a r e ágil, a d a p t a b l e y s e n s i b l e ; m é t o d o s m á s e f e c t i v o s ; h e r r a m i e n t a s m á s p o d e r o s a s ; m e j o r aceptación d e los profesionales y a p o y o de los gestores; y n o p e q u e ñ a s dosis d e e d u c a c i ó n y " p u b l i c i d a d " . La i n g e n i e r í a del s o f t w a r e n o h a t e n i d o el b e n e f i c i o d e la p u b l i c i d a d m a s i v a , p e r o , c o n f o r m e p a s a el t i e m p o , el c o n c e p t o s e v e n d e a sí m i s m o . D e a l g u n a m a n e r a , e s t e l i b r o e s u n " a n u n c i o p u b l i c i t a r i o " p a r a la t e c n o l o g í a . El l e c t o r t a l v e z n o e s t é d e a c u e r d o c o n t o d o s l o s e n f o q u e s d e s c r i t o s e n e s t e libro. Algunas de las t é c n i c a s y o p i n i o n e s s o n controvertidas; o t r a s d e b e r á n a j u s t a r s e para t r a b a j a r bien en diferentes e n t o r n o s d e desarrollo d e s o f t w a r e , sin e m b a r g o , mi sinc e r a e s p e r a n z a e s q u e Ingeniería

del software.

Un enfoque

práctico

haya d e l i n e a d o los

p r o b l e m a s q u e s e e n f r e n t a n , d e m o s t r a d o la f u e r z a d e l o s c o n c e p t o s d e la i n g e n i e r í a del s o f t w a r e y o f r e c i d o u n m a r c o d e t r a b a j o d e l o s m é t o d o s y h e r r a m i e n t a s . C o n f o r m e s e a v a n z a e n el s i g l o xxi, el s o f t w a r e s e h a c o n v e r t i d o e n el p r o d u c t o m á s i m p o r t a n t e y e n u n a i n d u s t r i a p r i m o r d i a l e n el e s c e n a r i o m u n d i a l . Su i m p a c t o e importancia h a n transitado un largo camino. E incluso, una n u e v a generación de d e s a r r o l l a d o r e s d e s o f t w a r e d e b e e n f r e n t a r m u c h o s d e los m i s m o s d e s a f í o s q u e e n f r e n t a r o n l a s p r i m e r a s g e n e r a c i o n e s . E s p e r o q u e l a s p e r s o n a s q u e e n f r e n t e n el r e t o — i n g e n i e r o s d e s o f t w a r e — t e n d r á n la s a b i d u r í a d e d e s a r r o l l a r s i s t e m a s q u e m e j o r e n la c o n d i c i ó n h u m a n a .

[ACM98] ACM/IEEE-CS joint Task Forcé, Software Engineering Code of Ethics and Professional Practice, 1998, disponible en h t t p : / / w w w . a c m . o r g / s e r v i n g / s e / c o d e . h t m . [BECOl] Beck, K. el al., "Manifestó for Agile Software Development", h t t p : / / w w w . a g i l e m a n i f e s to.org/. [BOL91] Bollinger, T. y C. McGowen, "A Critical Look at software Capability Evaluations", en IEEE Software, julio de 1991, pp. 25-41. [GIL961 Giib, T„ "What is Level Six?", IEEE Software, enero d e 1996, pp. 97-98, 103. [HOP90] Hopper, M. D., "Rattling SABRE, New Ways to Compete on Information", en Harvard Business Review, mayo-junio d e 1990. [PAU931 Paulk, M. el al., Capability Maturity Modelfor Software, Software Engineering Institute, C a m e g i e Mellon University, 1993. (PCM03] "Technologies to Watch", en PC Maga/.ine, julio d e 2003, disponible en h t t p : / / w w w . p c mag.com/article2/0,4149,1130591 .OO.asp. [PRE911 Pressman, R. S. y S. R. Herrón, Software Shock, Dorset House, 1991. [SEE03) The Software Engineering Ethics Research Institute, "UC1TA Updates", 2003, disponible en h t t p : / / s e e r i . e t s u . e d u / d e f a u l t . h t m .

TM 3 2 . 1 . Obtener una copia d e las principales revistas de negocios y noticias de esta s e m a n a (por ejemplo, Newsweek, Time, Business Week). Elaborar u n a lista de c a d a elemento del artículo o noticia que se pueda utilizar para ilustrar la importancia del software.

PDF Editor

3 2 . 2 . Uno d e los dominios m á s reñidos d e la aplicación del software son los sistemas y aplicaciones b a s a d o s en Web. Estudiar c ó m o la gente, la comunicación y el proceso tienen que evolucionar para a d a p t a r s e al desarrollo d e las WebApps d e "siguiente generación".

940

PARTE C I N C O


3 2 . 3 . Escribir u n a breve descripción del e n t o r n o d e desarrollo d e un ingeniero de software ideal hacia el 2010. Describir los e l e m e n t o s del e n t o r n o (hardware, software y tecnologías de comunicación) y su impacto sobre la calidad y el tiempo en que llega al mercado. 3 2 . 4 . Revisar el estudio d e los modelos de proceso incrementales ágiles en el capítulo 4. Realizar u n a investigación y recopilar artículos recientes acerca de la materia. Resumir las fortalezas y debilidades d e los p a r a d i g m a s ágiles con b a s e en las experiencias s u b r a y a d a s en los artículos. 3 2 . 5 . Inténtese desarrollar un ejemplo que comience con la recopilación d e datos en bruto y llévese a cabo la adquisición de información, luego d e conocimiento y, por último, de sabiduría. 3 2 . 6 . Proporcionar ejemplos específicos q u e ilustren u n o de los o c h o s principios éticos d e la ingeniería del software m e n c i o n a d o s en la sección 32.7.

Los libros q u e estudian las tendencias futuras del software y la computación abarcan u n a amplia variedad d e t e m a s técnicos, científicos, económicos, políticos y sociales. Sterling (Tomorrow Now, Random House, 2002) recuerda q u e el progreso real rara vez e s o r d e n a d o y eficiente. Teich (Technology and the Future, Wadworth, 2002) presenta reflexivos e n s a y o s acerca del impacto social d e la tecnología y c ó m o la cultura c a m b i a n t e da forma a la tecnología. Naisbitt, Philips y Naisbítt (High Tech/High Touch, Nicholas Brealey, 2001) s e ñ a l a n q u e m u c h a s p e r s o n a s se h a n "intoxicado" c o n la alta tecnología y q u e la "gran ironía de la era d e la alta tecnología es q u e la humanidad se ha esclavizado a los dispositivos que se s u p o n e brindarían libertad". Zey (The Future Factor, McGraw-Hill, 2000) analiza cinco fuerzas que darán forma al destino h u m a n o durante este siglo. Cantón (Techno/utures, Hay House, 1999) estudia c ó m o la tecnología transformará los negocios en el siglo xxi. Robertson (The New Renaissance: Computéis and the Next Level of Civilization, Oxford University Press, 1998) argumenta q u e la revolución en la computación p u e d e ser el a v a n c e individual m á s significativo en la historia d e la civilización. Broderick (Spike, Forge, 2001) analiza el impacto d e las tecnologías emergentes. Dertrouzos y Gates (HTwf Will be: tlow the New World of Information Will Change Our Uves, Harper-Business, 1998) ofrecen un estudio detallado d e a l g u n a s d e las direcciones q u e p u e d e n tomar las tecnologías d e la información en las primeras d é c a d a s de e s t e siglo. Barnatt (Valueware: Technology, Humanity and Organization, Praeger Publishing, 1999) presenta un intrigante estudio d e u n a "economía de ideas" y c ó m o el valor económico se creará c o n f o r m e evolucionen los cibernegocios. El de Negroponte (Being Digital, Alfred A. Knopf, 1995) fue un éxito d e ventas a mediad o s del decenio d e 1990 y continúa ofreciendo u n a interesante visión de la computación y d e su impacto global. Kroker y Kroker (Digital Delirium, New World Perspectives, 1997) h a n editado u n a controvertida colección d e ensayos, p o e m a s y h u m o r que examinan el impacto d e las tecnologías digitales sobre las p e r s o n a s y la sociedad. Brin (The TTansparent Society: Will Technology Forcé Us to Choose Between Privacyand Freedom?, Perseus Books, 1999) vuelven a revisar el continuo debate asociado con la inevitable pérdida d e privacidad personal q u e a c o m p a ñ a al crecimiento d e las tecnologías d e la información. Shenk (Data Smog: Surviving the Information Olut, HarperCollins, 1998) estudia los p r o b l e m a s asociados con u n a "sociedad infestada de información" que se sofoca por el volumen d e información q u e produce el software. TM Brockman [The Next Fifly Years, Vintage Books, 2002) y Miller y s u s colegas (21st Centuty Technologies: Promises and Períls of a Dynamic Future, Brookings Institution Press, 1999) h a n editado u n a colección d e artículos y e n s a y o s acerca del impacto de la tecnología sobre las estructuras sociales, empresariales y económicas. Para aquellos interesados en los t e m a s técnicos, Luryi, Xu y Zaslavsky (Future Trcnds in Microelectronics, Wiley, 1999) han editado u n a colección de articulos acerca d e las probables direcciones para el hardware de computadora, c o n énfasis en las nanotecnologías. Hayzelden y Bigham (Software Agents for Future Communication Systems, Springer-Verlag, 1999) han editado una colección que analiza las tendencias en el desarrollo d e a g e n t e s d e software inteligentes.

PDF Editor

CAPÍTULO 32

941


Conforme el software se vuelve c a d a vez m á s parte de la fabricación de virtualmente todas las facetas d e la vida moderna, la "ciberética" ha evolucionado c o m o un t e m a importante de estudio. Los libros de Spinello (Cyberethics: Morality and Law in Cybcrspace, Jones & Bartlett Publishers, 2002), Halbert e Ingulli (Cyberethics, South-Western College Publishers, 2001) y Baird y s u s colegas (cyberethics: Social and Moral Issues in the ComputerAge, Prometheus Books, 2000) consideran el t e m a en detalle. El gobierno estadounidense ha publicado un voluminoso reporte en CD-ROM (2 Ist Centuiy Guide to Cybercrime, Progressive Management, 2003) que considera todos los aspectos del crimen computacional, conflictos d e propiedad intelectual y el Centro d e Protección a la Infraestructura Nacional (N1PC, por s u s siglas en inglés). Kurzweil (The Age of Spiritual Machines, When Computers Exceed Human Intelligcnce, Viking/Penguin Books, 1999) a r g u m e n t a que, dentro de 20 a ñ o s , la tecnología de h a r d w a r e tendrá la capacidad de modelar por completo el cerebro h u m a n o . Borgmann (Holding on lo Reahty. The Nature of Information al theTUrn of the Millenium, University of Chicago Press, 1999) ha escri to u n a interesante historia de la información, y rastrea su papel en la transformación de la cultura. Devlin (InfoSense: TUrning Information Into Knowledge, W. H. Freeman & Co., 1999) intenta darle sentido al c o n s t a n t e flujo d e información que b o m b a r d e a a la población diariamente. Gleick (Faster: The Acceleration offust About Eveiything, Pantheon Books, 2000) estudia la tasa siempre en aceleración del cambio tecnológico y su impacto sobre todos los aspectos d e la vida moderna. Jonscher (The Evolution ofwired Life: From the Alphabcl to the Soul-Catcher Chíp-HOW Infoi-mation Technologies Change Our World, Wiley, 2000) a r g u m e n t a que el p e n s a m i e n t o y la interacción h u m a n a s trascienden la importancia de la tecnología. En Internet hay disponible u n a amplia variedad d e fuentes d e información acerca d e las direcciones futuras en las tecnologías relacionadas c o n el s o f t w a r e y la ingeniería de software Una lista actualizada de referencias en la World Wide Web se p u e d e encontrar en el sitio Web SEPA: http://www.mhhe.com/pressman.

TM

PDF Editor

INDICE ANALÍTICO

ABC MPI, 37 Abstracción, 252 Accesibilidad, 3 7 5 Acciones, 2 5 Acoplamiento, 260, 482 niveles de, 329 medición, 487, 489 Actividades, 24 Actividades d e sombrilla, 2 4 , 2 8 Actividades del m a r c o d e trabajo, 24,26 genéricas, 26 Actores, 173, 206 Agilidad, 79. Véase también Proceso ágil definición de, 79 factores h u m a n o s , 82 principios d e la, 80 A l m a c e n a m i e n t o d e datos, 278 A m b i e n t e d e t r a b a j o , 368 Ámbito, 112 Ámbito del s o f t w a r e , 651, 6 9 3 límites, 6 9 3 Análisis, 192. Véase también Análisis d e los requisitos o r i e n t a d o a objetos, 201 p a t r o n e s , 183 (Véase también Patrones) reglas por experiencia, 194 Análisis d e inventario, 909 Análisis d e peligros, 762 Análisis d e requisitos, 192. Véase también Análisis objetivos del, 193 ingeniería Web, 545 Análisis de tareas, 361 Análisis del árbol d e decisión, 717 Análisis del dominio, 194 Análisis del flujo d e trabajo, 364 Análisis del usuario, m é t o d o s para el, 361 Análisis del valor d e frontera, 437, 624 Análisis del valor g a n a d o (AVG), 742 Análisis g r a m á t i c o , 212 Análisis Relación-Navegación (ARN), 589 Aplicaciones b a s a d a s en Web. Véase WebApps Árbol de datos, 552 Árbol de requisitos de la calidad, WebApps, 568 Arquetipos, 289 Arquitectura, 2 5 3 análisis d e sensibilidad, 294

aplicaciones b a s a d a s en Web, 587 de datos, 140 descripción d e la, 2 7 6 importancia d e la, 277 MVC, 589 Arquitectura d e aplicación, 8-9 Arquitectura de datos, 140 Arquitectura del a g e n t e p a r a solicitud de objeto, 890 Arquitectura del c o n t e n i d o , 586 estructuras, 586 A s e g u r a m i e n t o d e la calidad, 770 actividades, 773 estadístico, 783 historia, 772 plan, 791 A s e g u r a m i e n t o d e la calidad del s o f t w a r e (SQA). Véase Aseguramiento de la calidad Asociaciones, 232 Atributos, 222 Atributos d e los datos, 198 Auditoria de configuración, 813 a p l i c a c i o n e s b a s a d a s en Web, 823 Auditorías, 806. Véase también Auditoría de configuración Autentificación, 631 Autoridad del control del c a m b i o (ACC), 810 Autorización, 62 Base de d a t o s del proyecto, 800. Véase también Depósito Caja d e tiempo, 740 Calendarización, 724, 727, 736 c o n c e p t o s , 725 principios, 728 seguimiento, 739 v a r i a n z a , 743 Calidad c o n t e x t o d e la ISBC, 896 c o s t o d e la, 770 definición de, 463, 769 d e t e r m i n a n t e s , 665 directrices p a r a la IWeb, 5 1 3 factores, 464 f a c t o r e s del ISO 9126, 4 6 5 medición, 676 m e d i d a s d e la, 677 Calidad de la c o n c o r d a n c i a , 769 Calidad del diseño, 769 Calidad del s o f t w a r e . Véase Calidad Calificación de c o m p o n e n t e s , 887

Cambio, 6, 7, 114 á m b i t o del, 929 i m p a c t o s o b r e el s o f t w a r e , 6 origen del, 797 Caos, 48 Capital del s o f t w a r e , 22 Característica, definición de, 9 5 Cardinalidad, 199. 232 Casos de prueba características d e los, 420 derivación, 427 Categorías de usuario, definición d e las, 521 Centro de transacción, 306 Certificación, 874 Clase agregada compuesta, 230 multiplicidad, 232 Clase-responsabilidad-colaborador, 225. Véase también M o d e l a d o CRC Clases d e análisis aplicaciones b a s a d a s e n Web, 554 atributos, 221 características d e las, 221 identificación d e las, 219 operaciones, 223 tipos de, 219, 226-227 Clases d e controlador, 227 Clases d e d i s e ñ o , 2 5 9 características d e las, 2 6 0 tipos de, 259 Clases d e e n t i d a d , 2 2 6 Clases d e frontera, 226 Clientes, 111 COCOMO II, 710 Codificación, 631 Codificación, principios, 123 Código f u e n t e a nivel d e p r o g r a m a , 4 9 3 medición, 4 9 3 volumen, 493 Cohesión, 260, 4 8 3 medición para la, 489 niveles de, TM 326 Colaboración, 83, 110 definición d e CRC, 228 Complejidad, 482, 490 medición, 491 Complejidad ciclomática, 426 Componentes a d a p t a c i ó n de, 888 b a s a d o s en clases, 321 clasificación de, 8 9 3 c o m p o s i c i ó n de, 888 c o n v e n c i o n a l e s , 317, 340

PDF Editor

943

944

ÍNDICE ANALÍTICO

definición de, 315, 889 descripción de, 892 e j e m p l o de d i s e ñ o de, 321 ingeniería de, 890 n u e v o s , 696 reutilizables, 6 9 5 visión OO, 3 1 6 C o m p r o b a c i ó n d e corrección, 867, 868 Comprobaciones subordinadas, 869 C o m p u t a c i ó n ubicua, 10 Comunicación, 26, 110 c o n j u n t o d e tareas, 112 del cliente, 5 2 3 ingeniería Web, 510, 5 2 3 principios de la, 110 Concurrencia, 286 Condición posterior, 834 Condición previa, 833 Configuración del software, 797 C o n j u n t o d e base, 424, 4 2 5 C o n j u n t o d e c a m b i o s , 809 Conjunto de tareas c o m u n i c a c i ó n , 112 c o m u n i c a c i ó n con el cliente, 524 construcción, 124 definición del, 27 despliegue, 128 d i s e ñ o , 122

m o d e l a c i ó n del análisis, 118 planeación, l i é p l a n e a c i ó n del proyecto, 693 p r u e b a s , 125-126 p r u e b a s de aplicaciones b a s a d a s en la Web, 611 r e f i n a m i e n t o del, 737 selección. 732

Conocimiento, 934 C o n s e c u e n c i a s imprevistas, 1 Consejo Airlie, 658 Construcción, 26, 399

c o n j u n t o d e t a r e a s , 124 ingeniería Web, 510 práctica, 122 Construcción b a s a d a en c o m p o nentes, 8 Construcciones estructuradas, 340 Control d e calidad, 770 Control d e la variación, 768 Control d e la versión, 805, 808 aplicaciones b a s a d a s en la Web, 822 Control del cambio, 810 flujo d e trabajo, 811 tipos de, 811 Controlador vista del m o d e l o (MVC), 589 Controladores, 394

Corrección, 677 c o m p r o b a c i ó n de la, 868 condiciones, 869 verificación d e la, 867, 868 Cortafuegos, 631 Costo, v a r i a n z a , 744 C o s t o s de falla, 771 C o s t o s de prevención, 770 Costos d e valoración, 770 Cristal, 9 5 Curva d e la b a ñ e r a , 5 Curva Putnam-Raleigh-Norden, 730 C u r v a s d e falla, 7 Decisión d e h a c e r la c o m p r a , 717 Defectos, 775 D e p e n d e n c i a s , 232 Depósito, 801 características del, 804 contenido, 804 Depuración, 408 c o n s i d e r a c i o n e s psicológicas, 410 estrategias, 411 p r o c e s o de, 409 tácticas, 412 Desarrollo b a s a d o en c o m p o n e n t e s (DBC), 63, 886 Desarrollo c o n d u c i d o por la característica (DCC), 9 5 Desarrollo del s o f t w a r e a d a p t a t i vo (DSA), 89 Desarrollo o r i e n t a d o a a s p e c t o s , 65 Descomposición del p r o b l e m a , 652 Descomposición funcional, 362 Desgaste, 5, 6 Despliegue, 26 principios, 126 c o n j u n t o d e tareas, 128 ingeniería Web, 510

Despliegue d e la función d e calidad (QFD), 171 Deterioro, 6 Diagrama d e c a s o d e uso, 150 D i a g r a m a d e clase, 148, 2 2 3 Diagrama d e c o n t e x t o , 212 Diagrama de contexto d e la arquitectura (DCA), 2 8 8 D i a g r a m a d e c o n t e x t o del sistem a , 145 D i a g r a m a d e despliegue, 148 D i a g r a m a d e e s t a d o , 181,216, 237, 5 5 5 utilización d e p r u e b a s , 450 D i a g r a m a d e flujo, 340, 341 D i a g r a m a de flujo d e d a t o s (DFD), 212, 299 D i a g r a m a d e flujo del sistema (DFS), 146

D i a g r a m a s d e actividad, 148, 180, 208, 340 D i a g r a m a s d e relación de entidad, 200 Diagramas de secuencia, 238 a p l i c a c i o n e s b a s a d a s en la Web, 554, 5 5 5 Diseño, 245, 275, 314, 350 a nivel d e c o m p o n e n t e , 314, 593 aplicaciones b a s a d a s e n la Web, 566 arquitectónico, 275, 5 8 5 atributos d e calidad, 251 c o m p r o b a c i ó n de la corrección del, 868 c o n j u n t o d e tareas, 122, 252 directriz d e calidad, 2 4 9 estético, 582 hipermedia, 595 ingeniería del s o f t w a r e d e sala limpia, 867 interfaces con el usuario, 350 interfaces p a r a aplicaciones b a s a d a s en Web, 5 7 3 medición, 479 proceso, 250 verificación, 867 Diseño al nivel d e c o m p o n e n t e s , 314 aplicaciones b a s a d a s e n Web, 593 directrices, 326 pasos, 331 principios básicos, 322 Diseño arquitectónico, 275, 287 aplicaciones b a s a d a s en la Web, 585 complejidad del, 296 diagrama del flujo d e datos, 297 evaluación del, 294 r e f i n a m i e n t o del, 290, 310 Diseño d e d a t o s , 26 a nivel arquitectónico, 278 a nivel d e c o m p o n e n t e , 279 Diseño d e interfaz, 3 5 0 análisis del, 358 a p l i c a c i o n e s b a s a d a s e n la Web, 5 7 3 flujo d e trabajo, 368, 580 p a t r o n e s p a r a el, 371, 372 TM principios del, 351, 574 p r o c e s o del, 358 Diseño d e la interfaz con el usuario, 350 análisis de t a r e a s , 361 análisis del flujo de trabajo, 364 a s p e c t o s del, 372 e v a l u a c i ó n del, 377 medición, 492 principios del, 352

PDF Editor

945

ÍNDICE ANALÍTICO

proceso, 358 p a s o s , 368 reglas de oro, 351 Diseño de n a v e g a c i ó n , 590 Diseño del c o n t e n i d o , 584 Diseño estético, 572, 582 aplicaciones b a s a d a s en Web, 582 aspectos d e configuración, 582 Diseño gráfico. Véase Diseño estético Disponibilidad, a p l i c a c i o n e s b a s a d a s en Web, 569 Distribución, 286 Distribución del e s f u e r z o , 732 Dominio s e m á n t i c o , 844 ECS, 803 Ecuación del software, 712, 731 Eficacia en la remoción d e d e f e c tos (EED), 678 Eficiencia, 466 Elaboración, 159, 652 Elaboración d e objetos, 364 Elaboración d e tareas, 3 6 3 objetos, 364 tareas, 363 E l e m e n t o s de configuración del s o f t w a r e (ECS), 800 Elementos de diseño arquitectónico, 264 c o m p o n e n t e s , 266 datos, 263 despliegue, 267 interfaz, 264 E l e m e n t o s del sistema, 134 Encubrimiento de c o m p o n e n t e s , 888 Ensayo, 774. Véase también Revisiones Entrega i n c r e m e n t a l , 81 Envoltura, 888 Equipo de medición, MDOO, 4 8 5 Equipos ágiles, 82, 649 coordinación, 650 c u a j a d o s , 83, 90, 647 ingeniería Web, 526 organización propia, 83 p r o g r a m a d o r e n jefe, 647 tipos de, 646 Equipos ágiles, 649 Equipos d e s o f t w a r e . Véase Equipos Errores, 775 corrección de, 414 c o s t o relativo, 771 Escalabilidad, WebApps, 569 Escenarios del usuario, 172 Especificación, 160 Especificación constructiva, 837 Especificación d e caja d e e s t a d o ,

Especificación de c a j a negra, 865 Especificación d e c a j a t r a n s p a rente, 866 Especificación d e la estructura de caja, 864 Especificación del control (EC), 215 Especificación del p r o c e s o (EP), 217 Especificación formal, 842 Espectro d e la información, 933 Estado, 833 Estereotipo, 232 Estilos arquitectónicos, 280 c e n t r a d a en d a t o s , 281 -282 estratificada, 284 flujo de datos, 281 llamada y retorno, 2 8 3 o r i e n t a d a a objetos, 284 t a x o n o m í a d e los, 281 Estimación, 690, 696 aplicaciones b a s a d a s e n Web, 715 b a s a d a en PF, 702 b a s a d a en LDC, 700 b a s a d a en el problema, 699 b a s a d a en el proceso, 704 d e s c o m p o s i c i ó n , 698 desarrollo ágil, 714 estimación, 713 modelos, 710 m o d e l o s empíricos, 709 observaciones, 691 proyectos OO, 713 t é c n i c a s a u t o m a t i z a d a s , 709 u s o - c a s o s , 705 Estimación del proyecto. Véase Estimación Estimaciones ingeniería Web, 534 reconciliación, 708 Estructura de análisis d e t r a b a j o (EAT), 737 Estructura de superficie, 4 4 5 Estructura p r o f u n d a , 445 Ética, 936 código de, 936 c o n s i d e r a c i o n e s personales, 937 Evaluación del riesgo, 752, 757 Eventos, 215, 2 3 5 Evolución del software, 12 leyes de la, 13 Evolución. Véase Evolución del software Exposición al riesgo, 757 cálculo d e la, 757 Extracción de datos, 278

Factores d e calidad d e McCall, 463 Factores h u m a n o s , 82 Factorización, primer nivel, 302 Fiabilidad, 465, 786 m e d i d a s de, 787 Filtros, 2 8 3 Flujo d e t r a n s f o r m a c i ó n , 297 F o r m a s d e n a v e g a c i ó n (FdN), 591 F o r m a t o de c o n d i c i ó n - t r a n s m i s i ó n - c o n s e c u e n c i a (CTC), 759 Formulación, 510, 517 d e p r e g u n t a s , 519 recopilación d e requisitos, 520 Fuente abierta, 10 Funcionalidad, 4 6 5 F u n c i o n e s de ayuda, 3 7 3 F u n c i o n e s d e caracterización, 884 F u n d a m e n t o s , 741 p u n t o s de fijación, 59 GCS, 797, 815 e l e m e n t o s d e la, 799 escenario, 798 e s t á n d a r e s , 824 e s t r a t o s del proceso, 807 funciones, 805 gestión del cambio, 820 gestión del contenido, 817 identificación, 807 ingeniería Web, medición, 598 medición del valor d e n e g o cios, 538 m o d e l o d e análisis, 580 o b j e t o s de configuración, 817 jerarquía del usuario, 546 proceso, 806 p r u e b a s d e d e s e m p e ñ o , 631 p r u e b a s d e n a v e g a c i ó n , 625 p r u e b a s d e seguridad, 680 tipos de, 506 Gestión de la calidad, 767. Véase también A s e g u r a m i e n t o de la calidad Gestión de la configuración del s o f t w a r e . Véase GCS Gestión d e la c o n f i g u r a c i ó n , 829. Véase también SCM Gestión d e requisitos, TM 161 Gestión del cambio, 796. Véase también GCS a p l i c a c i o n e s b a s a d a s en Web, 815 Gestión del contenido, 817 Gestión del proyecto, 640 a s p e c t o s de la, 643 prácticas críticas, 658 Gestión del proyecto d e s o f t w a r e . Véase Gestión d e proyecto Gestión del riesgo, 747

PDF Editor 866

Facilidad d e m a n t e n i m i e n t o , 466, 677 Factibilidad, 693

946

ÍNDICE ANALÍTICO

Gráfica de flujo, 423, 425 Gráfica d e la estructura, 320 Gráfica de línea d e tiempo, 737 Graficación de la transacción, 306 Graficación de la t r a n s f o r m a c i ó n , 299 Graficación del flujo de datos, 298 Gráfico d e e s t a d o , 336 Granularidad, 114 Grupo i n d e p e n d i e n t e de p r u e b a (GIP), 386 GUI, 451 facilidad de uso, 620 jerarquía de clase, 444 m e d i c i o n e s para, 494 m é t o d o s OO, 441 m o d e l a c i ó n del flujo d e datos, 436 m o d e l a d o del flujo d e t r a n s a c ción, 436 modelación del e s t a d o finito, 435 m o d e l o s de c o m p o r t a m i e n t o , 451 navegación, 610 o p c i o n e s , 400 partición, 447 particiones de equivalencia, 436 p a t r o n e s , 455 principios, 124 p r o c e s o p a r a aplicaciones b a s a d a s en Web, 609 ruta básica, 423 servicios d e ayuda, 454 s i s t e m a s en t i e m p o real, 4 5 5 técnicas, 418

Herramientas, 24 a l m a c e n a m i e n t o de datos, 279

análisis estructurado, 218 b a s a d a s en Web, 599 calendarización, 737 c a s o s d e uso, 78 DBC, 8 9 5

depuración, 4 1 3 desarrollo de la interfaz con el usuario, 376 desarrollo ágil, 98-99 diseño de casos de prueba, 439 estimación, 716 gestión de la calidad, 791 gestión del cambio, 822 gestión del contenido, 819 gestión del proceso, 66 gestión del proyecto, 659 gestión del proyecto de ingeniería Web, 536

gestión del riesgo, 763 ingeniería d e los requisitos, 163 ingeniería inversa, 916 intermedias, 321 LDA, 297 medición de aplicaciones b a s a d a s en Web, 599 medición del producto, 4 9 5 medición del p r o c e s o y el p r o yecto, 676 m é t o d o s formales, 852 minería de datos, 279 m o d e l a d o de datos, 200 m o d e l a d o del análisis en UML, 239 m o d e l a d o del proceso, 4 3 m o d e l a d o del s i s t e m a , 151 PDL, 344 p l a n e a c i ó n de p r u e b a s , 408 p r u e b a s de aplicaciones b a s a d a s en Web, 633 reestructuración, 918 RPN, 905, 906 simulación del s i s t e m a , 139, 140 s o p o r t e d e la GCS, 814 UML/OCL, 339 Herramientas del software, véase Herramientas Historias del usuario, 85 HogarSeguro árbol de datos, 552 carta índice CRC, 226 c l a s e s de análisis, 220, 554 clases de diseño, 261 configuración de pantalla, 371 DCA, 289 d i a g r a m a de ACTIVIDAD, 209, 558 d i a g r a m a d e carriles, 210 d i a g r a m a d e clase, 181, 225 d i a g r a m a d e despliegue, 268 diagrama de estado, 216,237, 555 diagrama d e flujo d e datos, 2 1 2 , 2 1 3 , 300 d i a g r a m a d e s e c u e n c i a , 238, 554 d i a g r a m a u s o - c a s o , 178, 208 d i s e ñ o d e c o m p o n e n t e , 344 EP, 217 e s q u e m a c o n c e p t u a l , 597 estructura arquitectónica, 292, 306, 310 estructura de la función de seguridad, 292 m o d e l o CRC, 231 narrativa de p r o c e s a m i e n t o ,

USN,592 u s o - c a s o s , 175, 205, 369, 549 HogarSeguro (cuadros al m a r gen), 17, 5 7 , 6 2 , 111, 143, 170, 172, 177, 182, 185, 203, 2 0 7 , 2 1 6 , 2 2 4 , 2 3 1 , 258, 261, 265, 295, 305, 323, 328, 330, 354, 362, 388, 4 0 6 , 4 1 2 , 4 2 1 , 4 2 6 , 448, 477, 486, 521, 533, 549, 577, 622, 651, 668, 679, 702, 719, 742, 758, 782, 812 Hojas de información del riesgo, 757, 762 Idiomas, 270 IMCM, 29 a d o p c i ó n d e la, 32 m o d e l o continuo, 30 m e t a s , 32 m o d e l o por e t a p a s , 32 niveles.de capacidad, 3 0 prácticas, 31 Impurezas, 775 Incremento. Véase I n c r e m e n t o s del s o f t w a r e I n c r e m e n t o s d e software, 5 1 , 8 1 I n d e p e n d e n c i a funcional, 256 Indicadores, 466 índice d e calidad de la estructura del d i s e ñ o (1CED), 480 Información, r e p r e s e n t a c i ó n d e la, 9 3 3 Informe d e c a m b i o s , 810 Infraestructura, tecnología, 141 Ingeniería d e requisitos, 155 t a r e a s d e la, 157 Ingeniería d e s o f t w a r e d e sala limpia, 64, 850 certificación, 874 diferenciación d e características, 862 diseño, 867 especificación funcional, 863 estrategia, 860 p r u e b a s , 872 Ingeniería del diseño, 2 4 5 Ingeniería del dominio, 883 Ingeniería del p r o c e s o de n e g o cios (1PN), 903 jerarquía, 141 TM Ingeniería del producto, 142 Ingeniería del sistema jerarquía, 136 visión mundial, 136 Ingeniería del s o f t w a r e definición de la, 2 3 de sala limpia, 858 estratos, 24 ética, 936 f u t u r o de la, 927

PDF Editor 212

objetos del contenido, 584 relaciones d e clase, 290

947

ÍNDICE ANALÍTICO

práctica, 104. Véase también Práctica principios, 107 Ingeniería del s o f t w a r e asistida por c o m p u t a d o r a . Véase Herramientas Ingeniería 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 , 879, 880. Véase también ISBC Ingeniería directa, 9 1 1 , 9 1 8 cliente/servidor, 920 interfaces con el usuario, 922 s i s t e m a s OO, 921 Ingeniería inversa, 910, 912 d a t o s , 913-914 interfaces con el usuario, 9 1 5 p r o c e s a m i e n t o , 914-915 Ingeniería Web (IWeb), 502 actividades del m a r c o d e trabajo, 509 características del equipo, 527 c a s o s d e uso, 547 construcción del equipo, 528 desarrollo en casa, 533 directrices d e calidad, 5 1 3 d i s e ñ o a nivel d e c o m p o n e n te, 593 d i s e ñ o arquitectónico, 5 8 5 d i s e ñ o d e interfaz, 573 d i s e ñ o d e n a v e g a c i ó n , 590 d i s e ñ o del c o n t e n i d o , 584 estimación, 715 formulación, 517 (Véase también Formulación) GCS, 8 1 5 h e r r a m i e n t a s , 508 las p e o r e s prácticas, 539 las m e j o r e s prácticas, 512 métodos, 507 medición, 536 medición del diseño, 598 m o d e l a d o del análisis, 544 planeación, 525 p r e g u n t a s básicas, 511 proceso, 507, 508, 511 p r u e b a s , 604, 607, 612 subcontratación, 530 Ingeniería Web, pirámide d e diseño, 572 Inicio, 157 Inmediatez, 505 Inspecciones, 774. Véase también Revisiones Integridad, 678 Intereses g e n e r a l e s , 6 5 Interfaz con el usuario, 349. Véase también Interfaz análisis, 359 carga de memoria, 353 consistencia, 354 c o n t e n i d o del despliegue, 367 control del usuario, 351

ingeniería inversa, 915 m e c a n i s m o s de control, 579 m o d e l o d e análisis, 356 p a t r o n e s , 372 prototipo, 557, 580 p r u e b a s , 616 Intermedio (middleware), 322 Internacionalización, 3 7 5 Invariante d e datos, 834 ISAC. Véase H e r r a m i e n t a s ISBC, 879 análisis del costo, 897 e c o n o m í a d e la, 8 9 5 proceso, 882 ISO 9000, 790 ISO 9001: 2000, 38, 790 e s q u e m a del, 790 Itinerario del proyecto. Véase Calendarización Jerarquía del c o n t e n i d o , 552 j e r a r q u í a s d e usuario, 546 Lenguaje de d i s e ñ o d e p r o g r a m a . Véase LDP Lenguaje de especificación Z, 849 e j e m p l o , 849 n o t a c i ó n , 850 Lenguaje d e restricción d e objet o s (LRO), 338, 8 4 5 condiciones previas/posteriores, 337 e j e m p l o de, 847 invariante, 338 n o t a c i ó n , 846 visión general, 8 4 5 L e n g u a j e s d e descripción arquitectónica (LDA), 296 L e n g u a j e s de especificación formal, 844 Ley d e Deméter, 261 Ley d e Fiit, 576 Líder del equipo, 644 Línea de base, 800 definición de, 800 medición, 681 Lista de p r o b l e m a s , 169 Lista de verificación calidad del d i s e ñ o de WebApps, 570 validación de requisitos, 161, 186 Lista d e verificación d e e l e m e n t o s de riesgo, 750 Lista d e verificación p a r a la validación de requisitos, 161

Mantenimiento, 7, 12, 907 medición del, 496 M a n t e n i m i e n t o del s o f t w a r e , 7, 12, 907. Véase también Mantenimiento Marcos d e trabajo, 2 7 0 Matrices gráficas, 430 MDHOO, 5 9 5 d i s e ñ o a b s t r a c t o d e interfaz, 597 d i s e ñ o conceptual, 595 d i s e ñ o de navegación, 596 MDSD, 91 reinpeniería, 908 Medición (métricas), 467 a c o p l a m i e n t o , 487 análisis de, 474 a nivel d e c o m p o n e n t e s , 488 a p l i c a c i o n e s b a s a d a s en Web, 536, 598, 674 a r g u m e n t o s p a r a la, 680 atributos d e la, 471 b a s a d a e n la función, 474 calidad, 677 calidad d e la especificación, 477 código fuente, 492 cohesión, 489 complejidad, 491 definición, 467 diseño, 479 d i s e ñ o arquitectónico, 479 establecimiento, 684 etiqueta, 666 interfaz con el usuario, 492 linea d e base, 681 m a n t e n i m i e n t o , 496 o r i e n t a d a a la clase, 486 o r i e n t a d a al t a m a ñ o , 669 o r i e n t a d a a objetos, 481, 495, 673 o r i e n t a d a a la o p e r a c i ó n , 491 o r g a n i z a c i o n e s p e q u e ñ a s , 682 privada, 666 proceso, 663, 682 productividad, 699 proyecto, 462, 472, 667 p r u e b a s , 494 pública, 666 retos, 468 tipos de, 471 Medición d e TM Halstead, 4 9 3 Medición d e la productividad, 699 Medición d e línea d e c ó d i g o (LDC), 669 Medición del s o f t w a r e . Véase Medición Mediciones CK, 482 Medidas, 467 directas, 668 indirectas, 668

PDF Editor Manejo del error. 374 Manifiesto, desarrollo d e s o f t w a re ágil, 77 Manifiesto ágil, 77

948

INDICE ANALITICO

MEIEP, 37 Mejoramiento del proceso del s o f t w a r e (MPS), 664 estadístico, 667 Melé, 92 principios, 93 reuniones, 94 Metáfora, 577 Método de análisis del c a m b i o de arquitectura (MACA), 294 Métodos, 24 Métodos formales, 64, 830 conceptos, 830, 833 definición de, 830 directrices de los, 852 preliminares matemáticas, 837 Miniespecificaciones, 169 Mitigación del riesgo, 760 Mitos, 14-15 de la gestión, 13-14 del cliente, 15 del desarrollador, 16 Modalidad, 200 Modelado, 26 ingeniería Web, 510 Modelado ágil, 97 principios del, 97-98, 121 Modelado CRC, 225, 226 e n PE, 86 Modelado de datos, 197 Modelado de Hatley-Pirbhai, 144 Modelado del análisis, 1S9, 191 b a s a d o en clases, 181, 21? b a s a d o en escenarios, 179, 202 c o n j u n t o de tareas, 118 contenido, 551 del comportamiento, 181, 234 enfoques, 196 ingeniería Web, 544 interacción, 554 orientado al flujo, 182, 211 principios, 117 Modelado del diseño, principios, 119 Modelado del flujo de control, 215 Modelado del sistema, 137, 144 factores restrictivos, 138-139 UML, 147 Modelado estructural, 885 Modelo clásico del ciclo de vida, 50 Modelo CRC colaboraciones, 228 construcción, 225 responsabilidades, 227 revisión de directrices, 233 Modelo de amplificación del defecto, 776 Modelo de análisis

aplicaciones b a s a d a s en Web, 550 e l e m e n t o s del, 179, 197 relación con el diseño, 247 Modelo de comportamiento, 235 Modelo de desarrollo concurrente, 60 Modelo de espiral, 58 p r o b l e m a s con el, 59 Modelo de interacción, 554 Modelo de la cascada, 50 problemas con el, 51 Modelo del contenido, 551 Modelo del diseño, 247 dimensiones del, 263 relación con el análisis, 247 Modelo DRA, 53 retrocesos, 54 Modelo funcional, 557 Modelos de proceso ágil, 81 cascada, 50 Cristal, 95 DAR, 53 DAS, 89 DCC, 95 d e t e r m i n a d o s por el riesgo, 58 desarrollo concurrente, 60 diferencias, 28-29 especializado, 63 espiral, 58 e s t a d o s de bloqueo, 51 evolutivo, 54 incremental, 52 ISBC, 882 RPN, 904 Programación Extrema, 84 prescriptivo, 49 prototipos, 55 sala limpia, 859 Modelos evolutivos, 54-55 Modelos incrementales, 52 Modelos iterativos, 55 Modelos prescriptivos, 49. Véase también Modelos de proceso fallas de los, 78 Modo de bombero, 747 Modularidad, 254 Monitoreo del riesgo, 760 MS, 107 Multiplicidad, 232 Navegación, 559, 572 análisis de la, 559, 561 preguntas, 560 semántica, 591, 626 sintaxis, 590, 592, 625 Negociación, 112, 160, 184 Nodos de navegación, 591 Notación del diseño b a s a d a en texto, 242 comparación de la, 345

gráfica, 340 tabular, 342 Nueva economía, 10 Objeto de los datos, 197 Objetos de configuración, 802 aplicaciones b a s a d a s e n Web, 817 Objetos de contenido, 551, 584 Obtención, 158, 652 Obtención de requisitos, 166 Ocultamiento de información, 256 OMG/CORBA, 889 Operaciones, 223, 833 identificación, 223 Operadores de conjunto, 838 Operadores lógicos, 840 Orden del cambio, 810 Organización propia, 83-84 Orientado a objetos conceptos, 201 estimación, 713 seguimiento del proyecto, 741 Paquetes, 234 Paquetes de análisis, 234 Paradigma OPM, 469 Partición, 652 de equivalencia, 435, 623 Patrones, 108, 119, 124 análisis de, 183 arquitectónicos, 280, 281, 284 diseño, 254 diseño d e hipermedia, 594 depósitos de hipermedia, 595 interfaz con el usuario, 371 plantilla de p a t r o n e s para el análisis, 183 plantilla para los, 37 proceso, 36 pruebas, 455 Patrones arquitectónicos, 280 refinamiento de los, 287 tipos de, 586 Patrones de diseño, 254. Véase también Patrones descripción de los, 269 plantillas, 269 uso de, 270 Patrones del proceso, 34 ejemplo de, 36 TM PE. Véase Programación Extrema (PE) Persistencia, 286 Personal, 641, 930 a s p e c t o s de gestión, 641 relación con el esfuerzo, 729 usuarios, 643 PERT/CPM, 736 Peso del vínculo, 429, 433 Plan de SQA, 791

PDF Editor

949

ÍNDICE ANALÍTICO

Planeación, 26, 6 5 5 Planeación d e p r u e b a s , 381, 608 Planeación del ciclo a d a p t a t i v o (PCA), 90 Planeación del proyecto, 692 Plan RSGR, 761, 763 Plantilla m o d e l o del s i s t e m a , 145 Portabilidad, 465 Práctica (ingeniería del software), 103-132 Preguntas, libres d e contexto, 55 Primitivismo, 260, 482 Principio a b i e r t o - c e r r a d o (PAC), 322 Principio de c e r r a d u r a c o m ú n (PCC), 3 2 5 Principio d e equivalencia d e la reutilización (PER), 325 Principio d e inversión d e la d e p e n d e n c i a (PS1), 324 Principio d e Pareto, 125 Principio d e reutilización c o m ú n (PRC), 3 2 5 Principio de s e g r e g a c i ó n de interfase (PS1), 324 Principio de sustitución d e Liskov (PSL), 324 Principio W 5 HH, 115, 657 Principios, 113, 655 análisis, 117 codificación, 123 c o m u n i c a c i ó n , 110 c o n j u n t o d e tareas, 116 despliegue, 126 diseño, 119-120 ingeniería del s o f t w a r e , 107 IWeb, 511, 5 2 5 m o d e l a d o ágil, 121 p l a n e a c i ó n , 113 p r u e b a s , 124 Proceso, 24 a s p e c t o s d e la gestión del p r o yecto, 653 a s p e c t o s d e gestión, 642 d e s c o m p o s i c i ó n , 654 direcciones futuras, 931 evaluación, 37 m a r c o d e trabajo, 24 medición, 663 relación con el producto, 43 Proceso ágil, 81 política del, 81 P r o c e s o del s o f t w a r e en e q u i p o (PSE) actividades del m a r c o d e trabajo, 41 objetivos, 40 escritos, 41 Proceso del s o f t w a r e p e r s o n a l (PSP), 39 Proceso unificado (PU), 67 fases, 68

historia del, 67 p r o d u c t o s del trabajo, 71 P r o c e s o s de negocios, 904 Producto, 651 a s p e c t o s de gestión, 642 del trabajo, 173 relación con el p r o c e s o , 43 Producto esencial, 52 P r o g r a m a c i ó n e s t r u c t u r a d a , 340 P r o g r a m a c i ó n e x t r e m a (PE), 84 actividades del m a r c o d e trabajo, 8 5 codificación, 87 diseño, 86 planeación, 85 p r u e b a s , 88 P r o g r a m a c i ó n par, 87 Prototipos, 5 5 p r o b l e m a s con los, 57 Proyectos diferencias, 526 e s t i m a c i ó n , 690 medición OO, 673 medición para, 667 p r o b l e m a s , 656 seguimiento, 739 tipos de, 733 Proyectos de s o f t w a r e . Véase Proyectos Prudencia, 934 Prueba beta, 4 0 5 Prueba d e caja negra, 422, 433 Prueba d e ruta básica, 4 2 3 e j e m p l o de, 428 Prueba d e unidad, 88 Pruebas aleatorias, 48 a nivel de c o m p o n e n t e , 610, 623 a p l i c a c i o n e s b a s a d a s en Web, 604 arquitecturas c o n v e n c i o n a l e s , 386 arquitecturas OO, 388 b a s a d a s en el uso, 403 b a s a d a s en e s c e n a r i o s , 444 b a s a d a s en faltas, 4 4 3 b a s a d a s en gráficas, 434 b a s a d a s en la clase, 447 b a s a d a s en ligas, 403 b a s e de datos, 6 1 3 características genéricas, 3 8 3 c o n j u n t o de t a r e a s , 125 contenido, 610, 612 cliente/servidor, 452 criterio de completitud, 389 de clase múltiple, 449 d e u s o estadístico, 8 7 3 d o c u m e n t a c i ó n , 454 especializadas, 452 estrategias, 383, 390 e s t r a t e g i a s OO, 402

estructura de control, 430 estructura p r o f u n d a , 446 estructura de superficies, 446 exhaustivas, 422 ingeniería del s o f t w a r e d e sala limpia, 872 interfaces, 610, 616, 617, 619 límites, 437 tabla ortagonal, 438 Pruebas a la configuración aplicaciones b a s a d a s en Web, 611, 628 del lado del cliente, 629 del l a d o del servidor, 628

P r u e b a s a la unidad, 388, 392 a m b i e n t e p a r a las, 394 c o n s i d e r a c i o n e s d e las, 392 p r o c e d i m i e n t o s para las, 393 Pruebas a las b a s e s de datos, 613 P r u e b a s al flujo d e datos, 431 P r u e b a s al s i s t e m a , 388, 406 P r u e b a s alfa, 4 0 5 P r u e b a s d e aceptación, 88 P r u e b a s d e a g r u p a m i e n t o , 404 P r u e b a s d e bucle, 431 P r u e b a s d e caja blanca, 423 P r u e b a s d e carga, 633 P r u e b a s de compatibilidad, 622 P r u e b a s de condición, 431 Pruebas d e d e s e m p e ñ o , 408, 631 P r u e b a s de h u m o , 399 P r u e b a s de integración, 388, 394 P r u e b a s del c o n t e n i d o , 612 P r u e b a s d e tabla ortogonal, 438 a s c e n d e n t e s , 398 d o c u m e n t a c i ó n , 400 d e s c e n d e n t e , 396 estudio, 3 9 5 humo, 395 P r u e b a s d e n a v e g a c i ó n , 625 P r u e b a s d e recuperación, 407 P r u e b a s d e regresión, 398 P r u e b a s d e ruta, 624 P r u e b a s d e s o f t w a r e . Véase Pruebas P r u e b a s d e tensión, 408, 633 P r u e b a s de validación, 388, 404 criterios, 404 principios, 123 Pruebas estadísticas de uso, 873 PSE, 40 PSP, 39 TM P u n t o s d e fijación, 59 P u n t o s d e función, 474, 670 c ó m p u t o de, 476 lenguajes de programación, 672 reconciliación, 671 Puntos d e la estructura, 885 análisis del costo, 897 características de los, 885-886 Puntos de objeto, 711

PDF Editor

950

ÍNDICE ANALÍTICO

Puntos de prioridad, 165 Puntos vitales, 784-785 Recopilación de requisitos colaborativa, 167 [Véase también Obtención) directrices, 167 equipo, 168 Recopilación de requisitos, WebApps, 520 Recursos ambientales, 696 Recursos del proyecto, 694 Recursos h u m a n o s , 695 Red de actividad, 735 Red de tareas, 735 Reestructuración de código, 917 de datos, 917 Reestructuración d e código, 911 Reestructuración de datos, 911 Reestructuración de d o c u m e n t o s , 910 Refabricación, 87, 258 Refinamiento, 257 Refinamiento paso a paso, 257 Regla 40-20-40, 732 Reingeniería, 906 economía de la, 923 modelo del proceso, 908 Reingeniería del proceso de negocios (RPN), 903 modelo del proceso, 904 Relaciones del contenido, 554 Reportes de estado, 814 Requisitos de los aspectos, 65 Requisitos, validación de los, 186 Resguardos, 394

Responsabilidades, definición de CRC, 227 Retraso, 93 Reutilizabilidad, 64 Reutilización, 8, 109, 269, 325, 894

análisis y diseño, 891 medio ambiente, 894 Revisión de la configuración, 405 Revisiones, Véase también Revisiones técnicas formales (RTF) b a s a d a s e n muestra, 781 conservación del registro, 779 directrices, 780 junta de reunión, 778 reporte general, 779 reportes, 779 Revisiones b a s a d a s en muestra, 781 Revisiones del software, 774. Véase también Revisiones Revisiones técnicas formales RTF), 250, 577, 774. Véase teimbién Revisiones

Riesgo, 114 c o m p o n e n t e s , 753 estrategias, 747 formato CTC, 759 definición de, 748 controladores, 753 identificación, 750 impacto, 754, 757 planeación, 759 proyección, 754 refinamiento del, 759 tipos de, 748 Rotulación, m e n ú s y c o m a n d o s , 374 Ruta crítica, 736 Rutas de acción, 306 Rutas independientes, 424 Salvaguarda del software, 762, 788 Seguimiento de conflictos, 808 Seguimiento de la dependencia, 805 Seguimiento de requisitos, 805 Seguimiento del proyecto, IWeb, 535 Seguridad, 407, 506 aplicaciones b a s a d a s en la Web, 569 p r u e b a s de, 407, 630 Servicios otorgados, 807 Sigma seis, 785 Similaridad, 482 Simulación del sistema, 139 Sistema definición de, 134 e l e m e n t o macro, 135 Sistema de versiones concurrentes (SVC), 809 Sistemas b a s a d o s en c o m p o n e n tes, 880 Sitios Web, bien diseñados, 583 Software aplicaciones heredadas, 11 características del, 5 definición de, 4 mitos acerca del, 14 papel evolutivo del, 2 p r e g u n t a s fundamentales, 4-5 referencias históricas, 4 Software de ingeniería y científico, 9 Software de Inteligencia Artificial, 9-10 Software de línea de producto, 9 Software de sistema, 8 Software heredado, 11 calidad del, 12 Software, categorías de aplicación, 8-9 Software empotrado, 9 Solicitud de cambio, 810

Solución de problemas, 106 Solución pico, 86 Soporte, 126 SPICE, 37 Sprint, 94 Subcontratación, 718 ingeniería Web, 530 Sucesiones, 841 Suficiencia, 482 Susceptibilidad a las pruebas, características de la, 420 Tabla de decisión, 342 Tabla de recursos, 739 Tabla de riesgo, 754 Tablas de rastreabilidad, 162 Tamaño, 482 Tamaño, proyectos de software, 698 Tecnología del proceso, 42 Tecnologías, futuro, 929, 935 Tiempo de respuesta, 373 Tiempo en el mercado, aplicacion e s b a s a d a s en Web, 569 Tiempo medio de reparación (TMDR), 787 Tiempo medio entre fallas (TMDF), 787 Toxicidad del equipo, 648 Transacción, 298 Tubos, 282 UML diagrama de actividad, 148, 180 209, 335 diagrama de carriles, 209, 366 diagrama de c a s o de uso, 150, 178, 547 diagrama de colaboración, 332 diagrama de clase, 150, 180 diagrama de despliegue, 148, 268 diagrama de estado, 181,216, 247 diagrama de modelación del sistema, 148 d i a g r a m a s de secuencia, 238 elaboración del c o m p o n e n t e , 318 estereotipo, 233 gráfica de estado, 336 TM OCL, 337, 845 paquetes, 234 representaciones de interfaz, 265, 333 Unidad s e m á n t i c a de navegación (USN), 592, 626 Uso, c a s o s de, 360 análisis de tareas, 361 aplicaciones b a s a d a s en la Web, 524, 547, 554

PDF Editor

ÍNDICE ANALÍTICO

desarrollo del, 173 escritura, 202 identificación de e v e n t o s , 2 3 5 medición, 674 p r e g u n t a s a c e r c a del, 174175 Usuario, 26, 643 identificación del, 173 p u n t o s de vista múltiples, 173

Usuarios finales, 111 Validación, 161, 384 Velocidad del proyecto, 86 Verificación, 384 Vínculos de n a v e g a c i ó n , 591 Volatilidad, 483 WebApps, 9, 504 atributos de las, 504

TM

PDF Editor

Í N D I C E DE S I G L A S M Á S C O M U N E S EN I N G E N I E R Í A DEL S O F T W A R E

Siglas español/inglés Término equivalente en español

Término equivalente en inglés

ABC MPI (apreciación b a s a d a e n el CMM para el mejor a m i e n t o del p r o c e s o interno) 37 ACC (autoridad del control del cambio) 810 A D P (paradigma d e d i s e ñ o abstracto) 883 A E C O (acoplamiento e n t r e c l a s e s de objetos) 485 A G 2 D (análisis g e o m é t r i c o bidimensional) 701 A G 3 D (análisis g e o m é t r i c o tridimensional) 701 AIE (archivos de interfaz externos) 4 7 5 ALI (archivos lógicos internos) 474 A O O (análisis o r i e n t a d o a objetos) 201 A P D (acceso público a datos) 495 A P H (árbol d e profundidad de la herencia) 484 ARN (análisis relación-navegación) 560 AVG (análisis del valor ganado) 742 AVL (análisis de valores limite) 437 CAD (diseño asistido por computadora) 700 CCYD ( c o m p o n e n t e s comerciales ya desarrollados)

CMM (based appraisal for internal procces improvement CBA 1PI) CCA (change control authority) A D P (abstract design paradigm) C B O (coupling b e t w e e n object classes) 2 D G A (two-dimensional geometric analysis) 3 D G A (three-dimensional g e o m e t r i c analysis) E l F s (external interface files) ILFs (internal logical files) O O D A (object-oriented d o m a i n analysis) PAD (public a c c e s s to data m e m b e r s ) D I T (depth of the inheritance tree) RNA (relationship-navigation-analysis) EVA (earned valué analysis) BVA ( b o u n d a r y valué analysis) CAD (computer aided design) C O T S (comercial off-the-shelf)

695 C D L ( c o m p o n e n t e s comerciales de línea) CE (consultas externas) 474 CN (contador numérico) 6?6

881

C O (complejidad d e la operación) 491 C O C O M O (modelo constructivo d e costos) 710 C O M (modelo d e o b j e t o s p a r a c o m p o n e n t e s ) 889 CORBA (arquitectura c o m ú n de distribución d e objetos) 889 C P T C (costo p r e s u p u e s t a d o para el trabajo calendarizado) 743 C P T R (costo p r e s u p u e s t a d o del t r a b a j o realizado) 743 C R C (clase-responsabilidad-colaborador) 225 CRTR (costo real del t r a b a j o realizado) 743 CTC (condición-transición-consecuencia) 759 DAS (desarrollo adaptativo d e software) 89 DBC (desarrollo b a s a d o e n c o m p o n e n t e s ) 63 D B M S (gestor de b a s e s de datos) 614 DCA (diseño d e c o n t e x t o arquitectónico) 288 D C B D (descubrimiento d e c o n o c i m i e n t o e n b a s e d e datos) 2 7 8 DCC (desarrollo c o n d u c i d o por características) 95 D C S (diagrama de contexto del sistema) 145 D F D (diagrama de flujo d e datos) 211, 298 D F S (diagrama d e flujo del sistema) 146 DIE desviación intencional de las especificaciones) 784 DU documentación imprecisa o incompleta) 784

C O T S (comercial off-the-shelt) E Q s (external inquiries) NC (numerical control) O C (operation complexity) C O C O M O (coñstructive cost model) C O M (component object model) CORBA ( c o m m o n object request broker architecture) B C W S (budgeted cost of w o r k scheduled) B C W P (budgeted c o s t of work performed) FTR (formal technical reviews) A C W P (actual cost of work performer) C T C (condition-transition-consequence) A S D (adaptative s o f t w a r e development) C B D (component based development) D B M S (database m a n a g e r system) TM ACD (architecture context diagram) K D D (knowledge discovery in databases)

PDF Editor 952

F D D (feature driven development) S C D (system context diagram) D F D (data flow diagram) S F D (system flow diagram) I D S (intentional deviation from specifications) IID (inaccurate or incomplete d o c u m e n l a t i o n )

ÍNDICE DE SIGLAS M Á S COMUNES EN INGENIERÍA DEL SOFTWARE

DMADV (definir, medir, analizar, diseñar y verificar) 786 D P R (diseño para la reutilización) 891 DRA (desarrollo rápido de aplicaciones) 5 3 DSOA (desarrollo d e s oftwa r e orientado a aspectos) 6 5 DU (cadena definición-uso) 431 EAT (estructura de análisis del trabajo) 737 EC (especificación d e control) 2 1 5 E C S (elementos de configuración del software) 800 EDI (entornos d e desarrollo integrado) 413 EE (entradas e x t e m a s ) 474 E E D (eficacia en la eliminación d e defectos) 677 EIE (especificaciones incompletas o erróneas) 784 EIS (entorno d e ingeniería del software) 696 ELD (error d e la lógica del diseño) 784 E P (especificación d e proceso) 217 EPI (equipos d e p r o d u c t o integrado) 40 ER (exposición al riesgo) 757 E R D (errores d e la representación d e los datos) 784 FA (factor d e acoplamiento) 487 FCM (falta de cohesión e n métodos) 4 8 5 F C P (función d e control periférica) 701 FDN (formas d e navegación) 591 FIN (dependencia hacia dentro) 495 FIUC (facilidades de interfaz del usuario y control) 701 F P G C (facilidades de presentación gráfica de c o m p u t a dora) 701 G B D (gestión de b a s e s d e datos) 701 G C S (gestión de la configuración del software) 796 G I P (grupo independiente de prueba) 386 G U I s (interfaces gráficas d e usuario) 452 I C E D (índice d e calidad d e la estructura d e diseño) 480 ICI (interfaz de c o m p o n e n t e inconsistente) 784 ICOA (ingeniería d e c o m p o n e n t e s orientada a aspectos) 65 IDCO (índice d e d e s e m p e ñ o del costo) 744 IHC (interfaz h o m b r e - c o m p u t a d o r a ambigua o inconsistente) 784 IMCM (integración del m o d e l o d e capacidad de m a d u rez) 29 IMS (Índice d e m a d u r e z del software) 496 IPA (interfaz de p r o g r a m a c i ó n de la aplicación) 887 IPN (ingeniería d e p r o c e s o s d e negocios) 140 IR (ingeniería de requisitos) 157 ISBC (ingeniería del software basada en componentes) 879 ISO (organización internacional de estandarización) 38 IU (interfaz c o n el usuario) 264 KLDC (miles d e líneas de código) 669 LDA (lenguaje d e descripción arquitectónica) 296 L D P (lenguaje de d i s e ñ o d e programas) 217 MA (modelado ágil) 97 MACA (método d e análisis d e c o m p e n s a c i ó n para la arquitectura) 294 MAD (módulos d e análisis d e diseño) 701 M C C (mala interpretación d e la c o m u n i c a c i ó n del cliente) 784 M D H O O (método d e d i s e ñ o hipermedia o r i e n t a d o a objetos) 5 9 5

953

DMADV (define, measure, analyze, design, a n d verity) DFR (design for reuse) RAD (rapid application development) A O S D (aspect - oriented s o f t w a r e development) DU (definition-use chain) W B S (work b r e a k d o w n structure) C S P E C (control specification) s e i s (software configuration ítems) I D E s (integrated d e v e l o p m e n t environment) EIs (external inputs)

DRE ideffect removal efficiency) I E S (incomplete or e r r o n e o u s specification) SEE (software e n g i n e e r i n g environment) E D L (error in design logic) P S P E C (process specification) IPT (integrated product teams) RE (risk exposure) E R D (error in data representation) C F (coupling factor) LCOM (lack of cohesion in methods) FCF (peripheral control function) WoN (ways of navigating) FIN (fan-in) UICF (user interface a n d control facilities) C G D F (computer graphics display facilities) DBM (database m a n a g e m e n t ) SCM (software configuration m a n a g e m e n t ) ITG (independent test group) G U I s (graphical u s e r interfaces) DSQI (design structure quality Índex) ICI (inconsistent c o m p o n e n t interface) A O C E (aspect-oriented c o m p o n e n t engineering) CPI (cost p e r f o r m a n c e index) HCI ( h u m a n - c o m p u t e r interaction) CMMI (capability maturity model integration) SMI (software maturity index) API (application p r o g r a m m i n g interface) BPE (business p r o c e s s e s engineering) RE (requirements engineering) C B S E (component based soft w ar e engineering) ISO (international organization for standardization) UI (user interface) KLOC (thousands lines of code) TM A D L s (architectural description languages) PDL (program design language) AM (agile modeling) ATAM (architecture trade-off analisis method)

PDF Editor

DAM (design analysis modules) MCC (misinterpretation of c u s t o m e r communication) O O H D M (object-oriented hipermedia design method)

954

ÍNDICE DE SIGLAS MÁS COMUNES EN INGENIERÍA DEL SOFTWARE

M D S D (método de desarrollo de sistemas dinámicos) 91 ME (metas específicas) 31 M E I E M P ( m é t o d o d e evaluación d e la 1MCM e s t á n d a r p a r a el m e j o r a m i e n t o del proceso) 37 M E P S (mejora estadística del p r o c e s o de software) 667 MFH (método del factor de herencia) 487 MG (metas genéricas) 32 MIS (misceláneo) 784 M M C G P (modelo de m a d u r e z d e la c a p a c i d a d d e gestión de personal) 641 M P C ( m é t o d o s p o n d e r a d o s p o r clase) 484 MRC (método d e ruta critica) 736 MVC (modelo-vista-controlador) 589 NCR (número de clases raíz) 4 9 5 NCSC (nuevos c o m p o n e n t e s d e s o f t w a r e comerciales) 63 N D D (número d e d e s c e n d i e n t e s ) 485 NOA (número de o p e r a c i o n e s añadidas) 488 N P O (nuevos p u n t o s objeto) 711 N P O p r o m ( n ú m e r o p r o m e d i o de p a r á m e t r o s d e la o p e r a ción) 492 O C I (orden de c a m b i o de ia ingeniería) 810 O C L (lenguaje de restricción d e objeto) 332 O M G (grupo d e gestión de objetos) 889 OPM (objetivo/pregunta/métrica) 470 O R B (distribuidor de objetos) 889 PAC (principio abierto-cerrado) 322 P C C (principio del cierre c o m ú n ) 325 P C R (principio c o m ú n de la reutilización) 325 P D L (lenguaje d e d i s e ñ o de p r o g r a m a s ) 3 4 3 P E {prácticas e s p e c i f i c a s )

31

P E R (principio de equivalencia e n t r e reutilización y versión) 325

PERT (técnica de evaluación y revisión de programa) 736 P F (punto de función)

474

PG (prácticas genéricas) 32 P I D (principio de inversión de la d e p e n d e n c i a ) 324 P I E (prueba incompleta o errónea) 784 P N R (curva Putnam-Norden-Rayleigh) 730 P O A (programación o r i e n t a d a a aspectos) 65 P S E (proceso d e s o f t w a r e e n equipo) 40 PSI (principio d e s e g r e g a c i ó n de la interfaz) 324 P S L (principio de sustitución de Liskov) 324 P S P (proceso de s o f t w a r e personal) 39 P U (proceso unificado) 67 P Y P (porcentaje público y protegido) 495 Q F D (despliegue de la función de calidad) 171 R P C (respuesta p a r a u n a clase) 485 R S G R (reducción, supervisión y gestión del riesgo) 761 RTF (revisión técnica formal) 774 S C C T (sistema de clasificación de cinta transportadora) 145 SE (salidas externas) 474 SEI (instituto d e ingeniería del software) 2 9 S Q A (garantía d e la calidad del software) 767 S Q L l e n g u a j e d e c o n s u l t a s estructurado) 614

D S D M (dynamic s y s t e m s d e v e l o p m e n t method) SG (specific goals) S C A M P I (standard CMMI a s s e s s m e n t m e t h o d for p r o c e s s improvement) S S P I (statistical s o f t w a r e p r o c e s s improvement) MIF (method inheritance factor) GG (generic goals) M I S (miscellaneous) P M - C M M (people m a n a g e m e n t capability maturity model) W M C (weighted m e t h o d s per class) C P M (critical p a t h method) MVC (model-view-controller) ÑOR (number of root classes) NCSC (commercial off-the-self (COTS) s o f t w a r e c o m p o nent) N O C (number of children) NOA (number of o p e r a t i o n s a d d e d by a subclass) N O O (number of o p e r a t i o n s overridden by subclass) N P a v g (average n u m b e r of p a r a m e t e r s per operation) E C O (engineering c h a n g e order) O C L (object constraint language) O M G (object m a n a g e m e n t group) GQM (goal/question/metric) O R B (object request broker) O C P (open closed principie) C C P (common closure principie) C R P (common r e u s e principie) P D L (program design language) S P (specific practices) R E P (release r e u s e equivalency principie) PERT (program evaluation a n d review technique) F P (function points) G P (generic practices) D I P (dependency inversión principie) IET (incomplete or e r r o n e o u s testing) P N R (Putnam-Norden-Rayleigh curve) A O P (aspect-oriented p r o g r a m m i n g ) T S P (team s o f t w a r e process) I S P (interface s e g r e g a t i o n principie) L S P (Liskov substitution principie) P S P (personal s o f t w a r e process) UP (unified process) P A P (percent public protected) TM Q F D (quality function deployment) RFC (response for a class) R M M M (risk mitigation, monitoring a n d m a n a g e m e n t ) FTR (formal technical reviews) C L S S (conveyor line sorting system)

PDF Editor E O s (eos (external outputs) SEI (software e n g i n e e r i n g institute) S Q A (software quality a s s u r a n c e ) S Q L (structured query language)

ÍNDICE DE SIGLAS MÁS C O M U N E S EN INGENIERÍA DEL SOFTWARE

SVC (sistema de v e r s i o n e s c o n c u r r e n t e s ) 8 0 9 TC ( t a m a ñ o de la clase) 488 TI (tecnología d e la información) 2 7 8 T L P (error de la traducción del d i s e ñ o al l e n g u a j e d e programación) 784 T M C (tiempo m e d i o d e cambio) 677 T M D F y T M D R (tiempo m e d i o d e falla y t i e m p o m e d i o de reparación) 787 TMEF (tiempo m e d i o entre fallas) 787, 874 T M R (tiempo m e d i o de reparación) 407 T O p r o m ( t a m a ñ o p r o m e d i o de operación) 491 UML (lenguaje d e m o d e l a d o unificado) 68 USN (unidad s e m á n t i c a d e n a v e g a c i ó n ) 591 VAD (visión a b s t r a c t a de datos) 597 VC (varianza del costo) 744 V E P (violación d e los e s t á n d a r e s de p r o g r a m a c i ó n ) 784 VyV (verificación y validación) 384

955

CVS (concurrent v e r s i o n s system) CS (class size) IT (information technologies) PLT (error p r o g r a m m i n g l a n g u a g e translation) MTTC (mean-time-to-change) M T T C & MTTF ( m e a n - t i m e - t o - c h a r g e ) a n d ( m e a n time-to-failure) M T B F ( m e a n time b e t w e e n failures) MTTR (mean time to repair) O S a v „ (average operation size) UML (unified modeling language) NSU (navigation s e m a n t i c unit) ADV (abstract data view) CV (cost variance) V P S (violation of p r o g r a m m i n g s t a n d a r d s ) V&V (verification a n d validation)

Siglas inglés/español Término en inglés

Término equivalente en español

3 D G A (three-dimensional g e o m e t r i c analysis) 2 D G A (two-dimensional g e o m e t r i c anaiysis) ACD (architecture context diagram) A C W P (actual cost of w o r k performer) A D L s (architectural description languages) A D P (abstract d e s i n g paradigm) ADV (abstract data view) AM (agile modeling) AOCE (aspect-oriented c o m p o n e n t engineering)

A G 3 D (análisis g e o m é t r i c o tridimensional) 701 A G 2 D (análisis g e o m é t r i c o bidimensional) 701 DCA (diseño d e c o n t e x t o arquitectónico) 288 CRTR (costo real del t r a b a j o realizado) 743 LDA (lenguaje d e descripción arquitectónica) 2 9 6 A D P (paradigma d e d i s e ñ o abstracto) 883 VAD (visión a b s t r a c t a de datos) 597 MA (modelado ágil) 9 7 ICOA (ingeniería de c o m p o n e n t e s orientada a aspectos) 65 P O A (programación o r i e n t a d a a a s p e c t o s ) 6 5 D S O A (desarrollo d e s o f t w a r e o r i e n t a d o a aspectos) 65 IPA (interfaz d e p r o g r a m a c i ó n de la aplicación) 887 D A S (desarrollo a d a p t a t i v o de software) 8 9 MACA (método de análisis de c o m p e n s a c i ó n p a r a la arquitectura) 294 C P T R (costo p r e s u p u e s t a d o del t r a b a j o realizado) 743 C P T C (costo p r e s u p u e s t a d o p a r a el t r a b a j o c a l e n d a r i z a do) 743 IPN (ingeniería d e p r o c e s o s d e negocios) 140 AVL (análisis d e v a l o r e s límite) 437TM CAD (diseño asistido por c o m p u t a d o r a ) 700 D B C (desarrollo b a s a d o en c o m p o n e n t e s ) 63, 8 8 6 A E C O ( a c o p l a m i e n t o entre clases de objetos) 485 I S B C (ingeniería 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 ) 879 A C C (autoridad del control del cambio) 810 P C C (principio del cierre c o m ú n ) 325 FA (factor d e a c o p l a m i e n t o ) 487 F P G C (facilidades de p r e s e n t a c i ó n gráfica d e c o m p u t a d o r a ) 701

A O P (aspect-oriented programming) A O S D (aspect-oriented s o f t w a r e development) A P I (application p r o g r a m m i n g interface) A S D (adaptative s o f t w a r e d e v e l o p m e n t ) ATAM (architecture trade-off analisis method) B C W P (budgeted cost of w o r k performed) B C W S (budgeted cost of w o r k scheduled) B P E (business p r o c e s s e s engineering) BVA (boundary valué analysis) C A D (computer aided design) C B D (component based development) C B O (coupling b e t w e e n object classes) C B S E (component b a s e d s o f t w a r e engineering)

PDF Editor CCA (change control authority) C C P ( c o m m o n c l o s u r e principie) C F (coupling factor) C G D F (computer graphics display facilities)

956

ÍNDICE DE SIGLAS M Á S C O M U N E S EN INGENIERÍA DEL SOFTWARE

C O T S (comercial off-the-shelf) CLSS (conveyor line sorting system) CMM (based appraisal for internal procces improvement CBA 1PI) CMMI (capability maturity model integration) C O C O M O (constructive cost model) C O M (component object model) CORBA (common object request broker architecture) CPI (cost p e r f o r m a n c e index) CPM (critical path method) C R P (common r e u s e principie) CS (class size) CSPEC (control specification) CTC (condition - transition - consequence) CV (cost variance) CVS (concurrent versions system) DAM (design analysis modules) D B M (database m a n a g e m e n t ) D B M S (database m a n a g e r system) D F D (data flow diagram) DFR (design for reuse) D I P (dependeney inversión principie) D I T (depth of the inheritance tree) DMADV (define, measure, analyze, design, a n d verify) D R E (deffect removal efficiency)

DSDM (dynamic systems development method) D S Q I (design structure quality index) DU (definition-use chain)

ECO (engineering ctiange order) EDL (error in design logic) E I s (external inputs) EIFs (external interface files) E O s (external outputs) E Q s (external inquiries) E R D (error in data representation) EVA (earned valué analysis) F D D (feature driven development) FIN (fan-in) F P (function points) FTR (formal technical reviews) FTR (formal technical reviews) GG (generic goals) G Q M (goal/question/metric) G P (generic practices) G U I s (graphical u s e r interfaces) HCI ( h u m a n - c o m p u t e r interaction)

C D L (componentes comerciales d e linea) 695 S C C T (sistema de clasificación d e cinta transportadora) 145 ABC MPI (apreciación b a s a d a e n el c m m para el m e j o r a m i e n t o del p r o c e s o interno) 37 IMCM (integración del m o d e l o d e capacidad de madurez) 29 C O C O M O (modelo constructivo de costos) 710 C O M (modelo d e o b j e t o s p a r a componentes) 889 CORBA (arquitectura c o m ú n de distribución de objetos) 889 IDCO (índice d e d e s e m p e ñ o del costo) 744 M R C (método de ruta crítica) 736 P C R (principio c o m ú n de la reutilización) 325 TC (tamaño d e la clase) 488 EC (especificación de control) 215 CTC (condición-transición-consecuencia) 759 VC (varianza del costo) 744 SVC (sistema de versiones concurrentes) 809 MAD (módulos de análisis de diseño) 701 G B D (gestión de b a s e s de datos) 701 D B M S (gestor d e b a s e s de datos) 614 D F D (diagrama de flujo de datos) 211, 298 D P R (diseño p a r a la reutilización) 891 P I D (principio d e inversión de la d e p e n d e n c i a ) 324 A P H (árbol d e profundidad d e la herencia) 484 DMADV (definir, medir, analizar, diseñar y verificar) 786 E E D (eficacia e n la eliminación de defectos) 677 M D S D (método d e desarrollo d e s i s t e m a s dinámicos) 91 ICED (Indice d e calidad de la estructura de diseño) 480 DU (cadena definición-uso) 431 OCI (orden de c a m b i o d e la ingeniería) 810 ELD (error d e la lógica del diseño) 784 EE (entradas externas) 474 AIE (archivos de interfaz e x t e m o s ) 4 7 5 SE (salidas externas) 474 CE (consultas extemas) 474 E R D (errores d e la representación d e los datos) 784 AVG (análisis del valor ganado) 742 D C C (desarrollo conducido por características) 95 FIN (dependencia hacia dentro) 495 P F (punto de función) 474, 670 CRC (clase-responsabilidad-colaborador) 225 RTF (revisión técnica formal) 774 MG (metas genéricas) 32 TM O P M (objetivo/pregunta/métrica) 470 P G (prácticas genéricas) 32 G U I s (interfaces gráficas de usuario) 452 IHC (interfaz h o m b r e - c o m p u t a d o r a a m b i g u a o inconsistente) 784 ICI (interfaz de c o m p o n e n t e inconsistente) 784 E D I (entornos de desarrollo integrado) 413 DIE (desviación intencional de las especificaciones) 784 EIE (especificaciones incompletas o erróneas) 784 PIE (prueba incompleta o errónea) 784

PDF Editor ICI (inconsistent c o m p o n e n t interface) I D E s (integrated development environments) I D S lintentional deviation from specifications) IES uncomplete o r e r r o n e o u s specification) IET ¡ncomplete or e r r o n e o u s testing)

957

ÍNDICE DE SIGLAS M Á S COMUNES EN INGENIEBÍA DEL SOFTWASE

IID (inaccurate or i m c o m p l e t e d o c u m e n t a t i o n ) ILFs (internal logical files) I P T (integrated product teams) I S O (intemational organization for standardization) I S P (interface segregation principie) IT (information technologies) ITG (independen! test group) K D D (knowledge discovery in d a t a b a s e s ) KLOC ( t h o u s a n d s lines of code) L C O M (lack of c o h e s i o n in m e t h o d s ) LSP (Liskov subslitution principie) M C C (misinterpretation of c u s t o m e r c o m m u n i c a t i o n ) M I F (method inheritance factor) M I S (miscellaneous) M T B F (mean time b e t w e e n failures) M T T C & MTTF ( m e a n - t i m e - t o - c h a r g e ) a n d ( m e a n - t i m e to-failure) MTTC (mean-time-to-change) M T T R (mean time t o repair) MVC (model-view-controller) N C (numerical control) NCSC (commercial o f í - t h e - s e l f (COTS) s o f t w a r e component) N O A ( n u m b e r of o p e r a t i o n s a d d e d by a subclass) N O C ( n u m b e r of children) N O O (number of o p e r a t i o n s overridden by subclass) Ñ O R ( n u m b e r of root classes) NPavg (average n u m b e r of p a r a m e t e r s per operation) NSU (navigation s e m a n t i c unit) O C (operation complexity) O C L (object constraint language) O C P (open closed principie) O M G (object m a n a g e m e n t group) O O D A (object-oriented d o m a i n analysis) O O H D M (object-oriented hipermedia design method) O R B (object r e q u e s t broker) OS o u ( ( (average operation size) P A D (public a c c e s s t o data m e m b e r s ) P A P (percent public a n d protected) P C F (peripheral control function) P D L (program design language) P E R T (program evaluation and review technique) PLT (error p r o g r a m m i n g l a n g u a g e translation) P M - C M M (people m a n a g e m e n t capability maturity model)

DII ( d o c u m e n t a c i ó n imprecisa o incompleta)

PDF Editor P N R (Putnam-Norden-Rayleigh curve) P S P (personal s o f t w a r e process) P S P E C (process specification) Q F D (quality function deployment) R A D (rapid application development) RE (requirements engineering) RE (risk exposure)

784

ALI (archivos lógicos internos) 474 E P I (equipos d e p r o d u c t o integrado) 40 I S O (organización internacional d e e s t a n d a r i z a c i ó n ) 38 PSI (principio d e s e g r e g a c i ó n de la interfaz) 324 TI (tecnología de la información) 2 7 8 G I P (grupo i n d e p e n d i e n t e d e prueba) 386 D C B D (descubrimiento d e c o n o c i m i e n t o en b a s e d e datos) 2 7 8 KLDC (miles d e líneas d e código) 6 6 9 FCM (falta de c o h e s i ó n e n m é t o d o s ) 485 P S L (principio de sustitución d e Liskov) 324 M C C (mala interpretación d e la c o m u n i c a c i ó n del cliente) 784 M F H (método del factor d e herencia) 487 M I S (misceláneo) 784 T M E F (tiempo m e d i o entre fallas) 787 T M D F y T M D R (tiempo m e d i o d e falla y t i e m p o m e d i o de reparación) 787 T M C (tiempo m e d i o de cambio) 677 T M R (tiempo m e d i o de reparación) 407 MVC (modelo-vista-controlador) 5 8 9 CN (contador numérico) 696 NCSC (nuevos c o m p o n e n t e s d e s o f t w a r e comerciales) 63 N O A ( n ú m e r o d e o p e r a c i o n e s añadidas) 488 N D D ( n ú m e r o de d e s c e n d i e n t e s ) 485 N P O ( n u e v o s p u n t o s objeto) 711 NCR ( n ú m e r o de c l a s e s raíz) 495 N P O p r o m (número p r o m e d i o de p a r á m e t r o s de la operación) 492 USN (unidad s e m á n t i c a de navegación) 591 C O (complejidad de la operación) 491 O C L (lenguaje de restricción d e objeto) 332 PAC (principio abierto-cerrado) 322 O M G (grupo d e gestión de objetos) 889 A O O (análisis o r i e n t a d o a objetos) 201 M D H O O (método de d i s e ñ o h i p e r m e d i a o r i e n t a d o a objetos) 595 O R B (distribuidor de objetos) 889 T O p t o n l ( t a m a ñ o p r o m e d i o d e operación) 491 A P D (acceso público a datos) 495 P Y P (porcentaje público y protegido) 495 F C P (función de control periférica) 701 L D P (lenguaje d e d i s e ñ o de p r o g r a m a s ) 217 PERT (técnica de evaluación y revisión d e programa) 736 T L P (error de la traducción del d i s e TM ñ o al l e n g u a j e de programación) 784 M M C G P (modelo de m a d u r e z d e la c a p a c i d a d de gestión de personal) 641 P N R (curva Putnam-Norden-Rayleigh) 730 P S P (proceso de s o f t w a r e personal) 3 9 E P (especificación de proceso) 217 Q F D (despliegue de la función de calidad) 171 DRA (desarrollo rápido d e aplicaciones) 5 3 IR (ingeniería d e requisitos) 157 ER (exposición al riesgo) 757

958

ÍNDICE DE SIGLAS M Á S COMUNES EN INGENIERÍA DEL SOFTWARE

R E P (release r e u s e e q u i v a l e n c y principie)

P E R (principio d e e q u i v a l e n c i a e n t r e r e u t i l i z a c i ó n y versión) 3 2 5

R F C ( r e s p o n s e for a class) R M M M (risk m i t i g a t i o n , m o n i t o r i n g , a n d m a n a g e m e n t )

R P C ( r e s p u e s t a p a r a u n a clase)

RNA (relationship-navegation-analisys)

A R N (análisis r e l a c i ó n - n a v e g a c i ó n )

S C A M P I ( s t a n d a r d CMM1 a s s e s s m e n t m e t h o d for process improvement) S C D (system c o n t e x t d i a g r a m )

M E I E M P ( m é t o d o d e e v a l u a c i ó n d e l a IMCM e s t á n d a r p a r a el m e j o r a m i e n t o del p r o c e s o ) 37 D C S ( d i a g r a m a d e c o n t e x t o d e l s i s t e m a ) 145

S C I s ( s o f t w a r e c o n f i g u r a t i o n items)

E C S (elementos de configuración del software)

800

SCM (software configuration m a n a g e m e n t ) S G (specific goals)

G C S (gestión d e la c o n f i g u r a c i ó n d e l s o f t w a r e ) M E ( m e t a s e s p e c í f i c a s ) 31

796

SEE (software engineering environment) S E I ( s o f t w a r e e n g i n e e r i n g institute)

E I S (entorno de ingeniería del software) 696 S E I (instituto d e i n g e n i e r í a d e l s o f t w a r e ) 2 9

S F D (system flow d i a g r a m )

D F S ( d i a g r a m a d e flujo del s i s t e m a )

S M I ( s o f t w a r e m a t u r i t y index)

I M S (índice d e m a d u r e z del s o f t w a r e )

S Q A ( s o f t w a r e quality a s s u r a n c e )

S Q A ( g a r a n t í a d e la c a l i d a d d e l s o f t w a r e )

767

S Q L (structured query language)

S Q L (lenguaje de consultas estructurado) P E (prácticas e s p e c í f i c a s ) 31

614

S P (specific p r a c t i c e s )

485

R S G R ( r e d u c c i ó n , s u p e r v i s i ó n y g e s t i ó n del

riesgo)

146 496

S S P I (statistical s o f t w a r e p r o c e s s i m p r o v e m e n t ) T S P (team s o f t w a r e process)

M E P S (mejora estadística del p r o c e s o d e software)

U1 ( u s e r i n t e r f a c e )

IU (interfaz c o n el u s u a r i o )

U I C E (user i n t e r f a c e a n d c o n t r o l facilities)

F I U C (facilidades d e i n t e r f a z del u s u a r i o y c o n t r o l )

U M L (unified m o d e l i n g l a n g u a g e )

UML (lenguaje de m o d e l a d o unificado) P U ( p r o c e s o u n i f i c a d o ) 67

U P (unified p r o c e s s ) V & V ( v e r i f i c a r o n a n d validation)

761

560

P S E (proceso de s o f t w a r e e n equipo)

667

40

264

V y V (verificación y v a l i d a c i ó n )

701

68

384

V P S (violation of p r o g r a m m i n g s t a n d a r d s )

V E P (violación d e los e s t á n d a r e s d e p r o g r a m a c i ó n )

W B S (work b r e a k d o w n s t r u c t u r e )

E A T ( e s t r u c t u r a d e a n á l i s i s del t r a b a j o )

W M C (weighted m e t h o d s p e r class) W o N ( w a y s of n a v e g a t i n g )

F d N (formas d e navegación)

M P C ( m é t o d o s p o n d e r a d o s p o r clase)

737 484

591

TM

PDF Editor

784

Roger S. Pressmari es una autoridad reconocida a nivel internacional en el mejoramiento del proceso del software y en las tecnologías d e ingeniería del software.

Los 3 2 capítulos d e la sexta edición se han o r g a n i z a d o en cinco partes:

•

• • •

Parte 1. El proceso del software, presenta diferentes perspectivas del proceso del software y considera todos los modelos d e proceso importantes; a d e m á s , a b o r d a el d e b a t e entre las filosofías del proceso prescriptivo y del proceso ágil. Parte 2. Práctica de la ingeniería del software, presenta métodos d e análisis, diseño y prueba con especial interés en las técnicas orientadas a objetos y el m o d e l a d o UML. Parte 3. Aplicación de la ingeniería Web, presenta un enfoque completo d e ingeniería p a r a el análisis, diseño y prueba d e aplicaciones W e b . Parte 4 . Gestión de proyectos de software, presenta temas relevantes p a r a quienes planean, gestionan y controlan un proyecto d e software. Parte 5. Temas avanzados en ingeniería del software, presenta capítulos que a b o r d a n métodos formales, ingeniería del software d e sala limpia, ingeniería d e software b a s a d a en componentes, reingeniería y tendencias futuras.

Ademá s de muchos capítulos nuevos y significativamente revisados, la sexta edición incluye a p r o x i m a d a m e n t e 1 2 0 recuadros que: • Permiten al lector seguir a un equipo d e proyecto (ficticio) conforme planifica y diseña un sistema b a s a d o en computadora. • Proporciona estudios complementarios d e temas selectos. • Subraya los "conjuntos d e tareas" que describen el flujo d e trabajo p a r a actividades selectas d e ingeniería del software. Sugiere herramientas automatizadas d e interés p a r a los temas d e los capítulos.

McGraw-Hill Interamericana

TM

PDF Editor

Visite nuestra página WEB www.mcgraw-hiH-educacion.com

Ingenieria del Software - Roger S. Pressman 6ta edicion2.pdf

Recommend Documents