Calidad en Sistemas Informaticos

alidad
I
alidad de istemas
I for aile s
Mario G. Piattini Velthuis
Felix O. Garda Rubio
Ismael Caballero Munoz-Reja
Alfaomega
Calidad de Sistemas Infol'maticos
Datos catalograficos
Piattini, Mario; Garcia, FelLx y Caballero, Ismael
Calidad de Sistemas Informaticos
Primera Edici6n
Alfaomega Grupo Editor, S.A. de c.v., Mexico
ISBN: 978-970-15-1267-8
Formato: 17 x 23 cm Paginas: 416
yiario G. Piattini Velthuis. Felix O. Garcia Rubio, Ismael Caballero Munoz-Reja
ISBN: 84-7897-734-1, cdici6n original public ada por RA-MA Editorial, Madrid, Espana
Derechos reser\'ados RA-MA Editorial
Primcra edici6n: Alfaomcga Grupo Editor, Mexico, mayo 2007
2007 Alfaomega Grupo Editor, S.A. de C.V.
1139. Col. Del Valle. 03100. yiexico D.F.
ylicrnbro de la Camara Nacional de la Industria Editorial Mexicana
Registro No. 2317
pag. Web: http://www.alfaomega.com.mx
E-mail: libl.el.iapitagol.as@alfaomega.com.mx
ISBN: 978-9701512678
Del'echos I'esenados:
La infoI111aci6n contenida en est a obra tiene un fin exclusi\'amente didactico y, por 10 tanto, no esta
pre\'isto su apro\'echamiento a nivel profesional 0 industrial. Las indicaciones tecnicas y programas
incluidos, han sido elaborados con gran cuidado por el autor y reproducidos bajo estrictas nOI1l1as
de control. .-\LF.-\O?\IEGA GRUPO EDITOR, S.A. de c.v. no sera juridicamente responsable
por: en'ores u omisiones; daii.os y perjuicios que se pudieran atribuir a1 uso de la inf0l111aci6n compren-
dida en este libro. ni por la utilizaci6n indebida que pudiera darsele.
Edici6n autOJizada para \'enta en Mexico y todo el continente americano.
Impl'eso en Mexico. Printed in Mexico.
Empresas del grupo:
;\lexico: Alfaomega Grupo Editor. S.A. de C. V. - Pitagoras 1139. Col. Del Valle. Mexico. D.E c.P. 03100.
Tel.: (52-55) 5089-7740 - Fax: (52-55) 5575-2420/2490. Sin costo: 01-800-020-4396
E-mail: \.entas1@Alfaomega.com.mx
Colombia: .-\Ifaom"ga Colombiana S . .-\. - Canera 15 No. 64 A 29 PBX (57-I) 2100[22
Fax: (57-1 ) 6068648 - E-mail: scliente@alfaornega.com.co
Chile: Alfaomega Grupo Editor. S.A. - Dr. Manuel Barros BorgoDo 21 Pro\'idencia. Santiago. Chile
Tel.: (56-2) 235-4248 - Fax: (56-2) 235-5786 - E-mail: agechile@a[faomega.cl
Argentina: Alfaomega Grupo Editor Argentino. S.A. - Paraguay 1307 P.B. "II". Capital Federal.
Buenos Aires. c.P. [057 - Tel.: (54- [[) 4811-7183 /8352, E-mail: agea@fibertel.com.ar
A Emilio del Peso, IIlla de las personas con mayor calidad hllmana
y pro/esional que he tellido la sllerte de conocer.
Mario Piattini
A mis padres, Felix y Tina, y a mis hermanas. Alayte y Miriam. por Sll siempre incolldicional apoyo
y por la alegria y los (lI1imos qlle me transmiten cada dia.
Felix Garcia
A inlllQ y a mis padres, por rada Sll apoyo, Sll paciencia,
Sl/ comprension y Sli cariiio.
Ismael Caballero
INDICE
AUTORES ......................................................................................................................... XV
PROLOGO ..................................................................................................................... XVII
PREFACIO ..................................................................................................................... XIX
P ARTEI: INTRODUCCION A LA CALIDAD ..................................... 1
CAPITULO 1. CONCEPTO DE CALIDAD ................................................................... 3
1. DEFINICION DE CALIDAD ........................................................................................... 3
2. EVOLUCION HISTORICA DE LA CALIDAD ............................................................. 9
3. CONCEPTOS RELACIONADOS CON LA CALIDAD ............................................. 12
3.1. Conceptos relacionados con la gesti6n de la calidad ........................................ 13
3.2. Conceptos relacionados con la docul11entaci6n de la calidad ........................... 14
4. LECTURAS RECOMENDADAS .................................................................................. 14
5. SITIOS WEB RECOMENDADOS ................................................................................ 15
6. EJERCICIOS ........................................................ ........................................................... 15
CAPITULO 2. TECNICAS Y HERRAlVIIENTAS DE CALIDAD ............................ 17
1. INTRODUCCION ........................................................................................................... 17
2. HERRAMIENTAS BAsICAS DE CALIDAD .............................................................. 18
2.1. Diagran1a de flujo ............................................................................................... 18
2.2. Diagrat11a causa-efecto ....................................................................................... 19
2.3. Diagran1a de Pareto ............................................................................................ 21
2.4. Hoja de chequeo 0 de c0l11probaci6n ................................................................. 22
2.5. Grafo 0 Diagral11a de control ............................................................................. 23
2.5.1. Tipos de diagral11a de control... ............................................................ 24
VIII CAUDAD DE SISTElvLA.S TICOS
2.6. Histogran1a .......................................................................................................... 28
2.7. Diagrama de Dispersion 0 de Correlacion ........................................................ 29
3. HERRAMIENTAS DE GESTION ................................................................................. 30
3.1. Diagralna de afinidad ......................................................................................... 30
3.2. Diagrmna de relaciones ...................................................................................... 31
3.3. Diagrama de matriz 0 matricial... ....................................................................... 32
3.4. MatJiz de amilisis de datos ................................................................................. 33
3.5. Diagrama de redes de actividad 0 de flechas .................................................... 33
3.6. Diagrmna de arbol .............................................................................................. 33
3.7. Diagrama de proceso de decisiones ................................................................... 33
4. HERRAMIENTAS DE CREATIVIDAD ...................................................................... 34
5. HERRAMIENTAS ESTADISTICAS ............................................................................ 35
5.1. Control estadfstico del proceso .......................................................................... 35
5.1.1. indices de Capacidad Cp, Pp, C
PK
Y PpK ............................................... 36
5.1.2. indices de Capacidad CPU, PPU, CPL, PPL ...................................... 37
5.2. Diseiio de expeIilnentos ..................................................................................... 37
6. HERRAMIENTAS DE DISENO .................................................................................... 38
6.1. QFD (Quality Function Deployment) ............................................................... 38
6.2. M1FE (Analisis Modal de Fallos y Efectos) .................................................... 39
7. HERRAMIENTAS DE MEDICION .............................................................................. 43
7.1. COQ (coste de la calidad) ................................................................................. .43
7.2. Benchmarking ..................................................................................................... 43
7.3. Encuestas ............................................................................................................. 44
8. NIVELES DE MADUREZ .............................................................................................. 45
10. SITIOS WEB RECOTvIENDADOS ............................................................................. .46
11. EJERCICIOS .................................................................................................................. 46
CAPITULO 3. MODELOS Y NORMAS DE CALIDAD ............................................ 49
1. INTRODUCCION ........................................................................................................... 49
2. GESTION DE LA CAUDAD TOTAL .................. , ...................................................... .49
3. NORMAS ISO 9000 ........................................................................................................ 50
3.1. ISO y el proceso de norrnalizacion .................................................................... 50
3.2. Norrnas sobre calidad ......................................................................................... 53
3.3. Nonna ISO 9001 ................................................................................................. 56
3.3.1. Sistema de gestion de la calidad .......................................................... 58
3.3.2. Responsabilidad de la direccion ........................................................... 58
3.3.3. Gestion de los recursos ......................................................................... 58
3.3.4. Realizacion del producto ...................................................................... 59
3.3.5. Medicion, analisis y mejora ................................................................. 61
4. MODELO EFQM ............................................................................................................. 62
4.1. Vision general ..................................................................................................... 62
RA-MA iNDlCE IX
4.2. Critelios del modelo ........................................................................................... 63
4.2.1. Liderazgo .............................................................................................. 63
4.2.2. Politic a y estrategia ............................................................................... 64
4.2.3. Personas ................................................................................................ 64
4.2.4. Alianzas y recursos ............................................................................... 65
4.2.5. Procesos ................................................................................................ 65
4.2.6. Clientes .................................................................................................. 66
4.2.7. Resultados en las personas ................................................................... 66
4.2.8. Resultados en la sociedad ..................................................................... 66
4.2.9. Resultados clave de desempefio ........................................................... 66
5. CAF: MARCO COMUN DE EVALUACION .............................................................. 66
6. SEIS-SIGI\1A .................................................................................................................... 67
7. PREMIOS ......................................................................................................................... 68
9. SITIOS \VEB RECOMEl\TJ)ADOS ................................................................................ 70
10. EJERCICIOS .................................................................................................................. 71
PARTE II: CALIDAD DE SISTEMAS INFORl'1A. TICOS ............... 73
CAPITULO 4. CALIDAD DE SISTEMAS DE INFORiVIACION ............................. 75
1. SITUACION DE LA CAUDAD DE SI... ...................................................................... 75
2. IMPORT Al'-JCIA DE LA CAUDAD EN LOS SI ......................................................... 76
3. COMPONENTES DE LA CAUDAD ........................................................................... 77
5. SITIOS \VEB RECOMENTIADOS ................................................................................ 79
6. EJERCICIOS ..................................................................................................................... 79
CAPITULO 5: CALIDAD DE PRODUCTO SOFTWARE ........................................ 81
1. MODELOS CLAsICOS ....................................... : .......................................................... 81
2. NORMAS ISO 25000 ...................................................................................................... 83
2.1. Aspectos de la calidad de un producto software ............................................... 84
2.2. Modelo de calidad interna y externa .................................................................. 85
2.2.1. Funcionalidad ....................................................................................... 85
2.2.2. Fiabilidad .............................................................................................. 86
2.2.3. Usabilidad ............................................................................................. 86
2.2.4. Eficiencia .............................................................................................. 87
2.2.5. Mantenibilidad ...................................................................................... 87
2.2.6. Portabilidad ........................................................................................... 88
X CAUDAD DE SISTEMAS 1N1'ORl'viATICOS RA-ivL"'-
2.3. Modelo de calidad en uso ................................................................................... 88
2.3.1. Efectividad ............................................................................................ 88
2.3.2. Productividad ........................................................................................ 88
2.3.3. Seguridad de uso ................................................................................... 89
2.3 A. Satisfacci6n ........................................................................................... 89
204. Evaluaci6n de un producto software .................................................................. 89
3. TRABAJOS BASAD OS EN LAS NORMA ISO 9126 E ISO 14598 .......................... 91
5. SITIOS WEB RECOMENDADOS ................................................................................ 92
6. EJERCICIOS .................................................................................................................... 92
PARTE III: CALIDAD DEL PROCESO SOFTWARE ...................... 95
CAPiTULO 6. EL PROCESO SOFTWARE ................................................................ 97
1. INTRODUCCION ........................................................................................................... 97
2. GESTION DE LOS PROCESOS SOFTWARE .......................................................... 1 00
3. EL MODELADO DE LOS PROCESOS SOFTWARE .............................................. IO2
3.1. Elementos del Proceso Software ...................................................................... 1 03
3.2. Clasificaci6n de los Lenguajes de Modelado de Procesos (LMP) ................. 1 04
3.3. Metamodelos de proceso software ................................................................... 1 06
3.3.1. Modelado de procesos: Diagramas de Gantt y Diagramas PERT ... 107
3.3.2. F0n11ato de Intercambio de Procesos ................................................. 108
3.3.3. Lenguaje de Especificaci6n de Procesos (PSL) ................................ 109
3.304. Modelo del Proceso Unificado .......................................................... 110
3.3.5. Core Plan Representation (CPR) ....................................................... 110
3.3.6. Definici6n de Proceso de la Workflow Management Coalition ....... 111
3.3.7. Arquitectura de Sistemas de Infonnaci6n Integrados (ARIS) .......... 112
3.3.8. SPEARMINT ..................................................................................... 112
3.3.9. PROMENADE ................................................................................... 114
3.3.10. SPEM ................................................................................................ 116
3.3.11. SMSDM ............................................................................................ 121
4. ENTORl"\JOS DE INGENIERlA DEL SOFTWARE ORIENT ADOS AL
PROCESO ...................................................................................................................... 126
4.1. Introducci6n y Caracteristicas .......................................................................... 126
4.2. Clasificaci6n de los PSEE ................................................................................ 128
4.3. Ejemplos de PSEE ............................................................................................ 130
4.3.1. SPADE ................................................................................................ 130
4.3.2. APEL ................................................................................................... 132
4.3.3. Serendipity .......................................................................................... 136
5. LECTURAS RECOMENDADAS ................................................................................ 139
6. EJERCICIOS .................................................................................................................. 140
G: R/\-MA iNDICE XI
CAPiTULO 7. MODELOS DE PROCESO DE CICLO DE VIDA ......................... 141
1. CONCEPTO DE CICLO DE VIDA ............................................................................. 141
2. PROCESOS DEL CICLO DE VIDA SOFTWARE .................................................... 142
2.1. Procesos principales ......................................................................................... 142
2.2. Procesos de soporte .......................................................................................... 144
2.3. Procesos organizacionales ................................................................................ 146
2.4. Proceso de adaptacion ...................................................................................... 148
3. PROCESOS DEL CICLO DE VIDA DE SISTEMAS ................................................ 150
5. SITIOS WEB RECOMENDADOS .............................................................................. 152
6. EJERCICIOS .................................................................................................................. 152
CAPiTULO 8: EV ALUACION Y MEJORA DE PROCESOS ................................ 153
I. PANOMMICA GENERAL ......................................................................................... 153
2. LA NORMA ISO 90003 ................................................................................................ 156
3. EL MODELO DE MADUREZ DE LA CAPACIDAD (CMM) Y LOS
METODOS MAs REPRESENTA TIVOS DE EV ALUACION Y
MEJORA ASOCIADOS ............................................................................................... 158
3.1. CMM ................................................................................................................. 158
3.2. SCE (Software Capability Evaluation) ............................................................ 161
3.3. CBA -IPI ( CMM -Based Appraisal for lntemal Process Improvement) ......... 162
3.4. IDEAL ............................................................................................................... 164
3.5. PSP (Personal Software Process) ..................................................................... 167
3.6. TSP (Team Software Process) ......................................................................... 171
3.7. People Capability Maturity Model (People-CMrvI) ........................................ 174
4. EL ESTANDARISO/IEC 15504 .................................................................................. 177
5. CIvIMI Y SCAMPI ......................................................................................................... 181
5.1. Representacion por etapas ................................................................................ 183
5.2. Representacion continua .................................................................................. 185
5.3. SCAMPI (Standard CMrvn Appraisal Method for Process Improvement) ... 186
6. MODELOS IBEROAtY1ERICANOS DE MADUREZ Y EV ALUACION ............... 188
6.1. Model0 de Referencia para melhOlia de processo de software (MR mps) .... 188
6.2. Modelos de Procesos para la Industria del Software (MoProSoft) ................ 190
6.3. Mejora de procesos para fomentar la competitividad de la pequefia y
mediana industria del software de Iberoamerica (COMPETISOFT) ............ 191
9. EJERCICIOS .................................................................................................................. 195
XII CAUDAD DE SISTEMAS
PARTE IV: OTROS ASPECTOS DE CALIDAD DE SISTEMAS
,
DE INFORJ.\llACION ............................................................................... 197
CAPITULO 9. MEDICI ON DE SISTEMAS DE INFORMACION ........................ 199
1. INTRODUCCION ......................................................................................................... 199
1.1. T eona de la Medicion del Software ................................................................. 200
1.2. Terminologia de la Medicion de Software ...................................................... 202
1.3. Proceso de creacion de M6tricas ...................................................................... 205
2. ESTANDARES Y METODOLOGIAS DE MEDICION ........................................... 209
2.1. La medicion en los modelos de madurez y metodos de evaluacion
y rnejora ............................................................................................................. 211
2.2. Goal Question Metric (GQM) .......................................................................... 214
2.2.1. Planificacion ....................................................................................... 215
2.2.2. Definicion ........................................................................................... 217
2.2.3. Recopilacion de datos ......................................................................... 220
2.2.4. Interpretacion ...................................................................................... 221
7 7 - E' 1 d l' " d GQM 777
_._.). Jernp 0 e ap rcaClon e ........................................................ __ _
2.3. Goal Question Indicator Metric (GQ(I)M) y Goal-Driml Softv,;are
;vleasllrement ......................................... ............................................................ 223
2.3.1. Plantilla para la definicion de indicadores ......................................... 228
2.4. Practical Software Measurement (PSM) ......................................................... 229
2.5. IEEE Std 1061-1998. Metodologia para M6tIicas de Calidad del
Sofhvare ............................................................................................................ 231
2.6. ISO/lEC 15939 ................................................................................................. 234
3. IYIETRICAS SOFT\V.A.RE ............................................................................................. 236
3.1. Medicion del Proceso ....................................................................................... 23 7
3.2. Medicion del Proyecto ..................................................................................... 238
3.3. Medicion del Producto ..................................................................................... 240
3.3.1. Metricas de codigo fuente .................................................................. 241
3.3.2. MetI'icas de complejidad .................................................................... 242
3.3.3. MetIicas para sistemas 00 ........... : .................................................... 243
3.3.4. Puntos funcion .................................................................................... 250
4. HERRAMlENT AS DE MEDIClON SOFTW ARE ..................................................... 255
6. SITIOS \VEB RECOMENDADOS .............................................................................. 256
7. EJERCIClOS .................................................................................................................. 256
CAPITULO 10. CALIDAD DE LA LNFORl\1ACION ............................................... 259
1. INTRODUCCION ......................................................................................................... 259
2. CAUDAD DE LOS MODELOS DE DATOS ............................................................ 261
h\D1CE XIII
2.1. Calidad de los Modelos Conceptuales ............................................................. 261
2.1.1. Propuesta de Lindland et al ................................................................ 262
2.1.2. Propuesta de Moody y Shanks ........................................................... 265
2.1.3. Propuesta de Shanks y Darke ............................................................. 268
2.1.4. Propuesta de Kesh .............................................................................. 269
2.1.5. Propuesta de Schuette y Rotthowe .................................................... 271
2.1.6. Propuesta del Grupo Alm'cos ............................................................. 273
2.2. Calidad de los Modelos L6gicos ...................................................................... 273
2.2.1. Bases de Datos Relacionales .............................................................. 274
2.2.2. Bases de datos l11ultidimensionales ................................................... 274
2.2.2.1. Metricas a nivel de Tabla ..................................................... 278
2.2.2.2. MetJicas a nivel de EstJella .................................................. 279
2.2.2.3. Metricas a nivel de Esquema ............................................... 279
3. CALID.A.D DE DATOS ................................................................................................. 281
3.1. Metodologia para la medici611 de la calidad de los datos ............................... 284
4. EV ALUACION Y MEJORA DE LA CAUDAD DE LA INFORMACION ............ 286
4.1. Metodologia TDQM ......................................................................................... 289
4.2. Metodologia de Evaluaci6n AIMQ ................................................................. 290
4.3. IP-MAP: Representaci6n del Producto de Info1l11aci6n ................................. 291
4.4. Metodologia TQdM (English. 1999) .............................................................. 292
4
- P' D Q' . ("M" . B . . 100/ ) '97
.). lOyecto a UIl1CIS . ISler y atll1l, _ _ ................................................... _
4.6. Marco de Trabajo de Eppler (2003) ................................................................. 298
4.6.1. Elementos del marco y criterios de calidad ....................................... 299
4.6.2. Pasos en el marco de Eppler .............................................................. 300
4.7. CALDEAy EVAMECAL ............................................................................... 301
4.7.1. CALDEA: Modelo de Madurez de calidad de infonnaci6n
basado en Niveles de Madurez .......................................................... 303
4.7.2. EVAMECAL: Metodologia de Evaluaci6n y Mejora del PGI ........ 308
4.7.3. Ejemplo de Aplicaci6n de CALDEA ................................................ 311
6. SnIOS WEB RECOMENDADOS .............................................................................. 316
7. EJERCICIOS .................................................................................................................. 316
CAPITULO 11. GESTION DEL CONOCIMIENTO ................................................ 319
1. INGENIERIA DEL SOFTWARE Y GESTION DEL CONOCIMIENTO ............... 319
1.1. Necesidades de gesti6n del conocimiento en organizaciones de software .... 319
1.2. La Gesti6n del Conocimiento y los procesos del cicio de vida
del sofuvare ....................................................................................................... 321
1.3. Tecnicas y henamientas para la Gesti6n del Conocimiento ........................... 322
1.4. Implantaci6n de la Gesti6n del Conocimiel1to ................................................ 323
1.5. [lilodelos de Gesti6n de Conocimiento en Ingenieria del SofuYare ................ 324
1.5.1. Modelo de Dyba (2003) ..................................................................... 325
1.5.2. Modelo SEKS ..................................................................................... 326
XIV CAUDAD DE SISTEMAS Il'iFO&'v!ATICOS RA-ivlA
2. F ACTORiA DE EXPERlENCIA Y P ARADIGMA DE MEJORA DE LA
CALIDAD (QIP) ............................................................................................................ 326
2.1. QIP (Paradigma de mejora de la calidad) ........................................................ 326
2.2. Factoria de experiencia ..................................................................................... 328
2.3. Base 0 repositorio de experiencia .................................................................... 329
3. FAMILIAS DE ESTUDIOS .......................................................................................... 331
3.1. Experirnentos .................................................................................................... 332
3.1.1. Descripci6n del proceso experimentaL ............................................ 332
3.1.2. Replicaci6n de los experimentos ....................................................... 338
3.1.3. Ejemplo: detenninaci6n de la eficacia del Pair Designing para la
compartici6n y difusi6n de conocimiento ......................................... 339
3.2. Casos de estudio ............................................................................................... 346
3.2.1. Definici6n y aplicaciones ................................................................... 347
3.2.2. Diseiio de casos de estudio ................................................................. 347
3.2.3. Fases de un caso de estudio ................................................................ 349
3.3. Encuestas ........................................................................................................... 353
3.4. Comparativa entre las estrategias empiricas .................................................... 355
6. EJERCICIOS .................................................................................................................. 357
ACRONIlVI0S ................................................................................................................... 359
BIBLIOGRAFIA .............................................................................................................. 363
iNDICE ALF ABETICO .................................................................................................. 387
AUTORES
MARIO GERARDO PIA TTINI VEL THUIS
Doctor y Licenciado en Informatica por la Universidad Politecnica de Madrid.
Licenciado en Psicologia por la Universidad Nacional de Educaci6n a Distancia. Master
en Auditoria InfonnMica (CEJ\TEI). Especialista en la Aplicaci6n de Tecnologias de la
Infonnaci6n en la Gesti6n Empresarial (CEPADE-UPM). CISA (Certified Information
System Auditor) y CISM (Certified Information System Manager) por la ISACA.
Diplomado en Calidad por la Asociaci6n Espanola para la Calidad. Ha trabajado como
consultor para numerosos organismos y empresas, entre las que destacan: Ministerio de
Industria y Energia, Ministerio de Administraciones Publicas, Siemens-Nixdorf, Unisys,
Hewlett-Packard, Oracle, rCM, Atos-Ods, etc. Socio fundador de la empresa Cronos
Iberica en la que ha sido Director de los Departamentos de Desarrollo y Metodologias, asi
como de Formaci6n e I + D. Ha sido profesor asociado en la Universidad Complutense y
en la Universidad Carlos III de Madrid. Actualmente es Catedratico de Universidad de
Lenguajes y Sistemas lnfonnaticos en la Escuela Superior de InfonnMica de la
Universidad de Castilla-La Mancha, donde dirige el grupo de investigaci6n Alarcos,
especializado en Calidad de Sistemas de Infol111aci6n. Tambien es Director del Centro
Mixto de Investigaci6n y Desarrollo de Software UCLM-Soluziona (Ciudad Real), asi
como Patrono de la Fundaci6n insula Barataria par,! el fomento de la sociedad de la
infon11aci6n y del conocimiento en Castilla-Ia Mancha y Miembro del Consejo Editorial
de Universia.net. Es autor de varios libros, un centenar de articulos, asi como numerosas
comunicaciones en congresos intemacionales y nacionales sobre Ingenieria y Calidad del
Software, Bases de Datos, Auditoria y SegUlidad de Sistemas de Infol111aci6n.
X:VI CAUDAD DE SISTE:VIAS INFORMATICOS
FELIX OSCAR GARCIA RUBIO
Doctor por la Universidad de Castilla-La Mancha, en la que tambien obtuvo los
titulos de lngeniero en lnfonmitica e lngeniero Tecnico en lnfonmitica de Gesti6n.
Profesor asociado en la Escuela Superior de Infonmitica de Ciudad Real. Es miembro del
gmpo de investigaci6n Alarcos especializado en sistemas de il1fonnaci611, bases de datos e
ingenieria del software. Sus temas de investigaci6n incluyen la calidad de los procesos
software. la medici6n, los metodos agiles y los procesos de negocio. Sobre estos temas ha
sido autor de varios capitulos de libro y numerosos articulos en revistas y conferencias
nacionales e intemacionales.
ISlVlAEL CABALLERO MuNOZ-REJA
Doctor en Infonnatica, Ingeniero en Infonmitica e lngeniero Tecnico en
Infol111atica por la UCLM. Ha sido profesor de F0l111aci6n Profesional en la rama de
Sistemas Infonnciticos. Actualmente es Profesor Asociado a tiempo parcial en la Escuela
Superior de lnfonncitica de Ciudad Real, labor que compagina con las umciones de
Ingeniero Software que tiene asignada en la Unidad de I+D de Soluziona Software
Factory de Ciudad Real. Colabora con el Grupo Alarcos des de 1999. donde desanolla su
investigaci6n en el campo de la gesti6n de la calidad de los datos y de la infon11aci6n. Ha
publicado diversos articulos sobre cali dad de datos y de infon11aci6n en revistas. libros y
congresos nacionales e intemacionales.
PROLOGO
* &
Hemos asistido en los ultimos afios a un avance espectacular de la denominada
Sociedad de la Infonnaci6n. En paralelo a este avance, la dependencia de nuestra sociedad
y economia de los sistemas infonmiticos para su funcionamiento e inc1uso supervivencia
se ha ido haciendo cada vez lTIllS mayor.
La Ingenielia y la Calidad del Sofuvare, que aportan tecnicas y herramientas para
lograr productos y servicios de gran fiabilidad que puedan satisfacer las necesidades de los
usuarios, han madurado considerablemente en estos ultimos afios. De un enfoque centrado
en el control de la cali dad y la detecci6n de disconforrnidades en los productos, se ha
pasado a estudiar la mejora de los procesos de creaci6n y desarrollo de sistemas
infonnaticos as! como la certificaci6n de los mismos.
Queda, sin embargo, mucha labor por hacer si comparamos la situaci6n de la
calidad en el sofuvare con la de otros sectores como el autom6vil, la industria qu!mica,
etc., 10 que es nonnal teniendo en cuenta la relativa juventud y la naturaleza tan peculiar
del sofuvare.
Varios paises han venido invirtiendo grandes cantidades de recursos con el fm de
potenciar la industria del sofuvare tanto para atender la demanda intema como para
convertir el sofuvare en uno de los sectores estrategicos de crecimiento. As!, se han
instal ado fabricas de sofuvare en muchas regiones, se han creado centros de estudio y de
investigaci6n y otras estructuras con el fm de disponer del personal cualificado y de las
tecnicas y herramientas adecuadas para la construcci6n de sofuvare de cali dad.
XVlIl CAUDAD DE SISTD[AS
En el caso de Espai'ia, la Secretaria de Estado de T elecomunicaciones y para la
Sociedad de la Infol111aci6n del Ministerio de Industria, Turismo y Comercio en el marco
del Plan Avanza 2006-2010 promueve la mejora de la calidad del software mediante
ayudas a las empresas para la obtenci6n de certificaciones basadas en los plincipales
modelos y n0l111aS de calidad como CMML ISO 15504, ISO 12207, ISO 90003. Por otra
pmte, se fomenta la creaci6n de Platafol111aS Tecnol6gicas Espai'iolas, hom610gas a las
europeas, entre las que destacan INES (Iniciativa Espai'iola de Sofuvare y Servicios) entre
cuyos objetivos esta precisamente la investigaci6n e innovaci6n en los temas relacionados
con la calidad de los productos y servicios software.
Creemos que estas iniciativas ofrecen una I11UY buena oportunidad para que la
industria espai'iola del sofuvare de un salto significativo en los aspectos relacionados con
la calidad y responda adecuadamente a los retos que suponen la creaci6n de diferentes
"e-servicios" que demanda la sociedad actual. Esta demanda se preve crezca
exponencialmente a medida que la socied2.d del conocimiento alcance la mayor parte de la
poblaci6n.
0tro aspecro que cabe res altar es la gran cantidad de recursos que se han destinado
a la creaci6n de modelos y estandares relacionados con la cali dad del sofuvare. En efecto.
es de gran imponancia en la sociedad globalizada que actualmente vivimos. que existan
estandares reconocidos internacionalmente que pel111itan a las empresas cOOl'dinar sus
esfuerzos, y reutilizar las "mejores practicas" de desanollo y gesti6n del sofuvare.
A este respecto quelTia destacar la labor llevada a cabo por A.r"'OR. especialmente
por el CT0i71. relativa a la creaci6n y seguimiento de diferentes estandares relacionaclos
con los procesos del ciclo de vida del sottware y los sistemas de infol111aci6n.
Este libro presenta los principales conceptos relacionados con la calidad del
sofuvare. ofreciendo una panoramica bastante completa sobre los estandares relacionados
con la calidad de los productos y procesos sofuvare. Ademas trata aspectos muy
impOltantes como son Ia medici6n d.; la calidad. ]a calidad de datos 0 la gesti6n del
conocimiento que complementan las areas mas tradicionales de esta materia.
Creo que el material del libro puede resultar lItil para que tanto los estudiantes
como los profesionales puedan construir y gestionar productos y servicios de mayor
calidad. contlibuyendo de esta manera a la consolidaci6n de la Sociedad de la
Inf0I111aci6n.
Madrid a 2 de junio de 2006
Victor M. Izquierdo Loyola
Subdirector General de Empresas de la Sociedad de la Inf0l111aci6n
Presidente del Comite Tecnico de Norn1alizaci6n 71 de AENOR
PREFACIO
Soda puede IOrcer el cUlilino de fa \'erdo(/.1' la calidad
pOl'qlle es{(/s adelga::an y no quiebrail.1' siempre (me/un
sobre Iii lIlel1lira y lo/eillU de indusrria, como el ace ire
sob!'e el agzl([,
Cerml1les, El Quiiole
La calidad de los sistemas infonmiticos Se he! cOlwertido hoy en dia en uno de los
principales objetivos estrategicos de las organizaciones debido a que, cada vez mas, los
procesos mas importantes de las organizaciones -y, por 10 tanto. su supervivencia-
depel1del1 de los sistemas info1111aticos para su buen funcionamiento,
Seglll1 la nonna ISO 9000 la calidad es el "grado en el qUe un conjunto de
caracteristicas inherentes cumple con los requisitos". Como los requisitos dependenin de
las diferentes partes interesadas (stakeholders), la calidad es un concepto
multidimensional, ya que puede ser sinonimo de eficiencia, flexibilidad, cOlTeccion.
confiabilidad, facilidad de mantenimiento, portabilidad, facilidad de uso, seguridad,
integridad. etc.
xx CAUDAD DE SISTEMAS INFORlvlATICOS Ri\-tvLA.
En la evolucion expelimentada por la calidad de los sistemas infonmiticos se ha
pas ado de un tratamiento centrado fundamentalmente en la inspeccion y deteccion de
errores en los programas, a una aproximacion mas sistematica, dada la importancia que ha
adquirido la cali dad en la ingenieria de sistemas y en la ingerueria del software. La
demanda de software por parte de las organizaciones y, en general, de la sociedad ha
crecido mucho mas deprisa que la capacidad de la industria para producir software de
calidad, haciendo cronica la denorninada "crisis del software".
En los ultimos afios se han publicado diversos estudios y estandares en los que se
exponen los principios que se deben seguir para la mejora de la cali dad de productos y
procesos. Todo ello ha influido de forma significativa en el papel que actualmente tiene la
calidad en las organizaciones, que pasa a conveltirse en una "filosofia", una ventaja
competitiva, una cultura, que afecta a toda la organizacion.
La presente obra reline diferentes aspectos de calidad relacionados con los sistemas
infonnaticos, por 10 que se ofrece una vision amplia sobre diferentes factores que se deben
tener en consideracion para la construccion de software de calidad.
En este libro se persiguen los siguientes objetivos:
o Presentar de forma clara los conceptos fundamentales relacionados con la
calidad de los sistemas informaticos.
o Exponer los aspectos mas significativos relacionados con la calidad de
productos y procesos software.
o Dar a conocer los diferentes estandares relacionados con la cali dad del
software.
o Tratar aspectos muy importantes para conseguir sistemas de infonnacion de
calidad como pueden ser la medici6n, la cali dad de la infonnacion 0 la gestion
del conocirniento.
A 10 largo de esta obra se ha combinado el rigor cientifico con la experiencia
practica, proporcionando una panorarnica actuaI y completa sobre la problematica
asociada a la calidad de los sistemas informaticos.
1. CONTENtDO
La obra consta de once capitulos, agrupados en cuatro partes. La primera parte
ofrece una vision general de los conceptos, tecrucas y nonnas de calidad. El primer
capitulo introduce el concepto de calidad partiendo de las defmiciones mas comunes hasta
su interpretacion por parte de los principales gurus y estandares intemacionales.
RA.-i'vLA. PREF ACIO XXI
El capitulo 2 resume las principales tecnicas utilizadas para la gestion de la cali dad,
pasando por las herramientas basicas de cali dad, las estadisticas 0 las de gestion, entre
otras.
En el capitulo 3 se exponen las aproximaciones mas importantes a la calidad, desde
la gestion de la calidad total, pasando por el modelo EFQM y hasta seis-sigma (six-
sigma), dedicando una gran parte a la explicacion de las normas de la familia ISO 9000.
La parte II consta de dos capitulos, en el capitulo 4 se presenta una vision holistic a
de la calidad de los sistemas de informacion, asi como algunos de los problemas de
calidad que presentan los mismos. EI capitulo 5 explora las diferentes caracteristicas y
subcaracteristicas de calidad de un producto software asi como el proceso de evaluacion,
basandose en las principales normas intemacionales.
En el sexto capitulo, con el que inicia la parte III relativa a la cali dad de proceso
software, se discuten los principales elementos del proceso software y los lenguajes de
modelado propuestos hasta la fecha. EI capitulo 7 resume los principales modelos de
procesos de ciclo de vida, especialmente el ISO 12207, que pemliten tener una idea
general de los procesos software.
En el capitulo 8 se presenta las plincipales propuestas relativas a la evaluacion y
mejora de procesos: modelos de madurez, nonnas intemacionales, metodos de evaluacion,
etc.
La cuarta y liltima parte dellibro aborda otros aspectos de la cali dad de los sistemas
de infonnacion. Asi, en el capitulo 9 se presentan los conceptos relativos a la medicion del
software, los plincipales modelos y nom1as relacionados con la medicion, y las metricas
mas utilizadas.
En el capitulo 10 se proponen conceptos relativos a la cali dad de la infonnacion, asi
como un modelo de madurez y un metodo de evaluacion relacionados con la calidad de la
infonnacion. A continuacion, el capitulo 11 se centra en la gestion del conocinliento y su
importancia para conseguir sistemas de infonnacionde calidad.
Por ultimo, se incluye la bibliografia y los acronimos utilizados en el texto.
2, ORIENT ACION A lOS lECTORES
Aunque un conocimiento en profundidad de la gestion de la calidad de los sistemas
de infom1acion puede estar reservado a expertos en la materia, nuestro proposito al
presentar este libro ha sido dirigimos a una audiencia mucho mas amplia que comprende:
X,"XII C.-\UDAD DE SISTE:vIAS INFOR\lATICOS RA-i\lA
I Alumnos de Escuelas y Facultades de Infonmitica.
I Participantes en seminarios 0 cursos monognificos sobre calidad de sistemas de
informacion 0 calidad de software.
I Profesionales infonmiticos que esten trabajando en el area del desalTollo de
Sistemas de Infol1nacion.
I Directivos que tengan entre sus responsabilidades el desalTollo y
mantenimiento de sistemas.
I Usuarios avanzados, que tengan interes en adquirir unos conocimientos sobre
las tecnicas y metodologias mas utilizadas para asegurar la calidad de los
sistemas de infol1nacion.
I Analistas 0 consultores que, allll teniendo conocimientos de la materia, quieran
abordarla de fOl1na mas sistematica.
Debido a la diversidad de la audiencia, el estudio de esta obra puede realizarse de
maneras muy distintas dependiendo de la finalidad y conocimientos previos del lector.
3. OTRAS OBRAS RELACIONADAS
Queremos destacar que existen algunos libros public ados tambien por la editorial
RA-MA que complementan la vision de la presente obra:
I Medicion para la gestion en la lngenierfa del Sofhmre. Dolado, l y
Fel11andez, L (eds). 2000, (ISBN 84-7897-403-2), que recopila diferentes
trabajos relacionados con la gestion cuantitativa de los proyectos y la calidad
del software.
I Calidad ell el desarrollo y mantellimiento del soj'hmre. Piattini, M. y Garcia,
F. 2003, (ISBN 84-7897-544-6), que ofrece una panoramic a actual sobre
diferentes investigaciones realizadas por grupos destacados en calidad y mejora
de procesos y productos.
I Amilisis y Diseiio de Aplicaciones lnforlllaticas de Gestioll. Una perspectiva de
lngenierfa del Sofhmre. Piattini, M., Calvo-Mazano, lA., Cervera, l y
Fel11andez, L. 2004, (ISBN 84-7897-587-X), que aborda el desalTollo y
mantenil11iento de software, asi como diferentes aspectos relacionados con la
calidad: pruebas, verificacion y validacion, etc.
PREFACIO
4. AGRADECIMIENTOS
Queniamos expresar nuestro agradecimiento, en plimer lugar, a los alumnos de la
asignahlra Calidad de Sistemas de li!/ormacion de la Escuela Superior de Infonnatica de
Ciudad Real, asi como a los asistentes a los diferentes seminmios y conferencias que
hemos organizado sobre diferentes aspectos de la calidad de los sistemas infonnaticos en
estos liltimos quince afios. Sus sugerencias, comentmios y ctiticas nos han pennitido
depurar el material que presentamos en esta obra y planteamos que podtia resultar lltil
disponer de un libro que ayudara a la gesti6n de la calidad de los SI.
Tambien deseamos dar las gracias a D. Victor Izquierdo Loyola por haber aceptado
escribir la presentaci6n de esta obra. Tambien queremos agradecer a la empresa
Alvadalejo S.L. que se encarg6 de la filmaci6n del libro, y a la editorial RA-MA,
especialmente a don Jose Luis Ramirez, por su continuo apoyo y colaboraci6n.
Mario G. Piattini Velthllis
FelL>; Oscar Garcia Rubio
/smael Caballero ivll11loz-Reja
Ciudad Real, agosto de 2006.
Introduccion a fa Cafidad
1. Concepto de Calidad
2. Tecnicas y Herramientas de CaUdad
3. Modelos y Normas de CaUdad
CAPiTULO 1
CONCEPTO DE CALIDAD
"No me preocupa si alga es cam a barato. S610 si es buena. Y si alga es 10 sl!ficientemente bueno,
entonces el pllblico pagara par ella. "
Walt Disnel'
1. DEFINICION DE CAUDAD
La calidad se ha convertido hoy en dia en uno de los principales objetivos
estrategicos para las organizaciones debido a que, cada vez mas, su supervivencia depende
de la calidad de los productos y servicios que ponen a disposicion de los usuarios y
clientes y de la satisfaccion de estos.
Segill1 el Diccionario de la Real Academia Espanola de la Lengua (DRAE, 2006),
la calidad es (en sus cuatro primeras acepciones):
1. Propiedad 0 conjunto de propiedades inlJerentes a algo, qlle permitenjllzgar Sll
valor.
2. Buena calidad, sliperioridad 0 excelencia.
3. Caracler, genio, indole.
4. Condicion 0 requisito que se pone en un contrato.
Aunque coloquialmente podria parecer mas adecuada la segunda definicion a la
hora de evaluar la calidad de un producto 0 un servicio (ya que se pretende -en sentido
absoluto- la "excelencia"), las organizaciones estan interesadas en la primera y tercera
acepci6n de calidad. En efecto, se intenta detenninar las propiedades inherentes a una cosa
4 CAUDAD DE SISTEMASIN"FOR,'vL,I" TICOS
RA-M.A.
que nos pennita conseguir que sea mejor que las otras, pero esto sera relativo, ya que
dependera del punto de vista utilizado. Por otra parte, las organizaciones deberan asegurar
los requisitos que se fijan en los contratos.
Histolicamente, los diferentes gurus de esta area han dado diversas definiciones de
calidad (Hoyer y Hoyer, 2001):
@ W.A. Shewhart: "Existen dos aspectos de la calidad EI primero tiene que vel'
con la cOl1sideracion de la calidad de IIna cosa como una realidad objetiva
independiente de la existencia del hombre, La otra tiene que vel' con 10 qlle
pensamos, sentimos 0 creemos como resllltado de la realidad objetiva. En
otras palabras hay lin [ado subjetivo de la calidad" (Shewhart, 1931).
@ Philip B. Crosby: "La prim era sllposicion erronea es que calidad significa
bondad, hljo, brillo 0 peso. La palabra calidad se utiliza para significar el
valor relativo de las cosas enfrases como bllena caUdad, mala calidad y
la ex presion calidad de vida ". Calidad de vida es lin cliche pOl'que cada
oyente aSlime que la persona que habla entiende exactamente 10 que para 131
signtjica la frase. Esta es precisamente la razon pOl' la que debemos definir
caUdad como conjormidad COil los requisitos si queremos gestionarla".
(Crosby, 1979).
@ Genichi Taguchi: "La calidad es la perdida que un producto causa a la
sociedad desplles de ser entregada ... ademas de las perdidas callsadas pOl' Sll
fill1cion intrinseca". (Taguchi y Wu, 1979).
@ Anlland V. Feigenbaum: "La caUdad de prodllcto 0 servicio puede ser
definida como las caracteristicas to tales compllestas de producto y senJicio de
marketing, ingenieria, fabricacion y mantenimiento por medio de las cuales el
prodllcto y servicio en lISO cllmplil'a las e.xpectativas del cliente".
(Feigenbaum, 1983).
@ Kaoru Ishikawa: ''Debemos enfati::ar la orientacion al cliente ... Como uno
intelpreta el temzino "calidad" es importante... Intelpretado
restringidamente, calidad signtjica alidad de prodllcto. Intelpretado
ampliamente, calidad signtfica calidad de trabajo, calidad de servicio, calidad
de informacion, calidad de proceso, calidad de division, calidad del personal
-inclll)'endo trabajadores, ingenieros, directivos y ejeclltivos-, calidad del
sistema, calidad de la elllpresa, calidad de objeti1'os, etc.". (Ishikawa, 1985).
@ W. Edwards Deming: "La dtficliitad de delinir calidad es traducir las
necesidadesfilturas delllsllario en caracteristicas lIledibles, de manera que un
prodllcto plleda ser diseiiado y producido para dar satisfaccion al llsuario al
precio qlle paga... (, QlIe es calidad? La calidad solo se puede dl?:jinir en
terminos del agente". (Deming, 1986).
!::': RA-MA CAPiTlJLO 1: CONCEPTO DE CA.LlDAD 5
Q Joseph M. Jman: "La palabra calidad tiene multiple significados. Los dos
significados que dominan el uso de la palabra son: 1. La cali dad consiste en las
caracteristicas del producto que satisfacen las necesidades de los clientes y les
proporcionan por tanto satisfacci6n con el producto. 2. Calidad consiste en
ausencia de deficiencias .... Es conveniente estandarizar en una corta definici6n
la palabra calidad como adecuacion at uso". (Jman, 1988).
DE1VflNG
I
JrlRAt'i CROSBY FElGEl\1JAUM
1. Ser constantes en el
Proceso de Planificaci6n de la
RM5. La calidad es una
prop6sito de mejorar el
Calidad (considerar las
fomm de gesti6n.
producto 0 servicio. con el
necesidades del cliente. diseiio. 10. Fijar objetivos de
I. Establecer una filosofia
objetivo de llegar a ser
capacidad de fabricaci6n y calidad.
de mejora continua y
competitivos. de pemmnecer en
desarrollar los objetivos del
pemmnente.
el negocio y de proporcionar
proceso y de la calidad).
2. Proporcionar sopone a
puestos de trabaio. la gesti6n.
2. Adoptar una nueva filosofia.
Pane del Proceso de Control de 5. Tener conciencia de la BM7. Comprender que la
Rechazar la aceptaci6n de
la Calidad. calidad. calidad es una etica.
defectos
3. Suprimir la dependencia de
la inspecci6n para lograr la
cali dad. Eliminar la necesidad Pane del Proceso de Control de
de la inspecci6n en masa. la Calidad.
incorporando la cali dad dentro
del producto en primer lugar.
4. Acabar con la practica de
hacer negocios sobre la base
del precio. En vez de ello.
EI papel de los metodos
minimizar el costo total.
Establecer la tendencia a tener
estadisticos se encuentra
un iinico proveedor para
cubieno por el Proceso de
cualquier articulo. con una
Control de la Calidad.
relaci6n a largo plazo. de
lealtad v confianza.
Proceso de Control de la
Calidad (induye control de
parametros de proceso, control
de medici6n, estandares de 2. Equipo de mejora de
desempeiio, interpretar valores lacalidad.
5. Encontrar problemas. Hacer actuales vs. Estandares). 6. Utilizar un sistenm de
BMS. Mantener un sistema
mejoras de manera continua y Parte del Proceso de ;VJejora de acciones correctivas.
de mejora continua.
para siempre. la Calidad 4 1. Mantener un sistema
(considera mejora de proceso y de eliminaci6n de causas
de producto, productividacL de error.
tiempos de ciclo, seguridad de
uso. entomo. reducci6n de
costes).
6. Instituir metodos de
Parte del Proceso de Mejora de S. Tener forrnaci6n
formaci6n modemos en el
trabaio.
la Calidad. supervisada.
7. Dar a todos los empleados
Parte del Proceso de Mejora de
las herrarnientas adecuadas
para hacer bien el trabaio.
la Calidad.
8. Desechar el miedo, de
manera que cada uno pueda Parte del Proceso de Mejora de
trabajar con eficacia para la la Calidad.
or
a
anizaci6n.
6 CAUDAD DE 10:FORM..\ TICOS
9. Eliminar las barreras entre
departamentos. animar a los
ditcrentes departamentos a
trabajar conjuntamente en Ia
resolucion dc problemas.
10. Eliminar los objcti\'os
I1tlI110ricos. posters y cs16gancs
que cxigcn nuc\'os ni\'clcs de
producti\idad. sin
proporcionar metodos de
mejora especiticos.
II. Eliminar est{mdares de
trabajo que cspccitican cuotas
utilizar
cstadisticos para mcjorar 1a
l'roducti\idad y calidad de
lQnna contmua.
12. Eliminar todas las batTeras
que impiJan a los trabajadorcs
l)rgullosos de $U
trabaio.
Impbntar un prl)g:ran1u
\'igoroso de cducacion y
auto-mcjora,
loot In\'olucrar a tedo d
personal de Iu organizacilH1 en
la luella por conseguir la
Esta es turea de
todos.
Parte del Proceso de \!cjom de
la CaIidad.
Parte del Proceso de \ !cjora de
In Calidad.
Pane del Proeesa de \ !cjora de
la Calidad.
Punc del de \kjura ('1.:
la Calidad.
Parte del de \!cjora dc
1a Ca1id;1d.
CROSBY
2. \!antener equil'os de
mcjora.
13. CtiIizar consejos de
calidad.
10. Estabkccr control de
configuracion sobre los
objcti\os de calidad.
12, Tener un prograllla
de rcconocimicnto.
T encr
5upcl\'isada.
1. \!antener
compromisa de 1a
direccion.
3. Tener planes de
illcdici6n de la calidad.
-+. Estimar el coste de 1a
calidad.
7 . Tener un progruma de
cero ddcct('ls.
.9. Lograr dias en los
sea posible
encontrar cero defectos.
1-+. I-Iacer los 13 pasos
otm \'C2.
FEIGE7'lBAF\I
1. Estab1eeer que Ia
calidad es un proceso que
abarca toda Ia
organizncion.
BM.J. Conseguir
imp1icacion indi\'idual y de
equipo (Ia calidad es
tmbajo de todost
Presente en su libra Tora!
Comro! (aunquc
no sc cite cxp1icitamente
en los principios ni en los
bcnchmarks I.
B\12. Ca1idad e5 10 que las
clicntcs diccn que cs
B\!3. Calidad y coste s,'n
una suma no una

B\!6. Cali dad e
innoyacion son
mutuamente dependiemes.
B\!9. Calidad es cl camino
m{ls en costes y
menos intensi\'o en capital
hilcia Ia producti\idad.
B\!10. Calidad sc
itnplcmenta con un sistema
total concctilco con los
c1 iclltes y proyccdorcs.
3. C alidad es csencial para
1a innovacion desde la
conccpcic\n del discno
hasta 1a utilizacicin par
parte del cliente .
.J. Reconocer que el coste y
]a calidad son
complementarios.
Tabla l.1. Comparacion de Filosofias de Calidad de los Cuatro Gurus (Mouradian, 2002)
En la tabla 1.1 se resumen y se comparan las principales ideas sobre la calidad de
los cuatro gurus del siglo XX: Deming C 14 puntas para fa gestion''j. Juran ("La Trifagfa
(; RA-\L-\ CAPiTULO I: COKCEPTO DE CALID.-\D 7
de Juran sobre como gestiol/ar la ca!idad"), Crosby ("14 pasos para fa ca!idad") y
Feigenbaum (,,4 principios de gestion y 10 djrectrices para fa ap!icacion de estos
prillcipios"). Cada fila ilustra la idea de cada uno con respecto al mismo critelio.
Por otro lado, en las principales n0l111aS intemacionales, la calidad se define como
"el grado en ef que UII cOlljunto de caracteristicas illherelltes clllnpfe COil los requisitos"
(ISO. 2000a), 0tra definicion interesante de calidad es la proporcionada por ISO 8402:
"Col!illl1tO de propiedades 0 caracteristicas de WI prodllcto 0 serdcio qlle Ie cOI?jieren
aptitud para satislacer 1I11ClS necesidades expresadas 0 implicitas ",
Asi se puede ver que la calidad no se trata de un concepto absoluto: el consumidor
la juzga con to do relatiyismo en un producto, En general (Piattini et al .. 2003). es posible
considerarIa como un concepto multidimensional (referida a muchas cualidades), sujeta a
restricciones (p, ej .. depende del presupuesto disponible) y ligada a compromisos
aceptables (p, ej .. plazos de entrega). Incluso. se puede considerar que no es ni total mente
subjeti\'3, (pOl'que ciertos aspectos pueden medirse) ni total mente objetiva (ya que existen
cualidades cuya evaluacion solo puede ser subjetiva). Asi pues. la calidad no es absoluta.
es multidimensional (vease la figura 1.1). Ademas la cali dad sllele ser transparente cuando
esta presente pero resulta facilmente reconocible cuando esta ausente (por ejemplo.
cuando el producto falla 0 el sel';icio es deficiente).
OPORTI..:";mAD
Figura 1.1. La calidad puede verse desd muchos puntos de vista
A este respecto merece la pena recordar las cinco "j'istas" de la calidad que sefiala
Garvin (1984):
8 CALlDAD DE SISTE?v!AS INFORM.\. TICOS RA,-MA
o Vista trascendental: la calidad es algo que se reconoce pero no se define. Por
10 que se puede concebir la calidad como un ideal al que se intenta llegar,
aunque no 10 conseguimos debido a deficiencias en la tecnologia, en el proceso
de fablicaci6n, en la comprensi6n, etc. Esta vista no resulta demasiado util para
la gesti6n de la calidad y es amlloga a la segunda acepci6n del DRAE (2005).
o Vista de usuario: la calidad es adecuacion al proposito. Por 10 que se puede
cuantificar las caracteIisticas de los productos, medirlos y establecer objetivos
a alcanzar.
o Vista de fabricante: la calidad es confonnidad con las especificaciones. Esta
concepcion de la calidad expande su alcance para exal11inar la cali dad durante
la produccion y despues de la entrega del producto. Se trata de una vista
centrada en el proceso.
o Vista del producto: que considera que la calidad esta unida a las
caracteIisticas inherentes del producto. Mientras que las vistas del usuario y
fabricante se tienen "des de fuera", la del producto es "des de dentro", ya que se
centra en la l11edida de los atIibutos internos de los productos.
o Vista basada en valor: la calidad depende de la cantidad que el cliente este
dispuesto a pagar.
Hay que tener en cuenta adel11as que la calidad puede tener varios oIigenes (vease
figura 1.2):
Calidad Necesaria
Figura 1.2. Los origenes de la calidad
9RA-1vV\ CAPiTULO I: CONCEPTO DE CAUDAD 9
(!) La calidad reatizada: la que es capaz de obtener la persona que realiza el
trabajo, gracias a su habilidad en la ejecucion de una tarea. Se potencia con la
mejora de las habilidades personales y tecnicas de los participantes en lill
proceso.
(!) La calidad programada: la que se ha pretendido obtener. Es la que aparece
descrita en una especificacion, en un docwnento de disefio 0 en un plano. Es,
por tanto, la que se Ie ha encomendado conseguir al responsable de ejecutar el
trabajo. Se potencia con la elaboracion de una especificacion que sirva de
buena referencia a los participantes en un proceso.
(!) La calidad necesaria: la que el cliente exige con mayor 0 menor grado de
concrecion 0, al menos, la que Ie gustaria recibir. Se potencia con una adecuada
obtencion de infonnacion de la idea de cali dad de los clientes.
La gestion de la cali dad pretendeni conseguir que estos tres circulos coincidan 10
mas posible. Todo 10 que este fuera de dicha coincidencia sera motivo de derroche, de
gasto superfluo 0 de insatisfaccion. De todas maneras, consideramos que tambien resulta
fundamental tener en cuenta la "calidad esperada" por el cliente, que no siempre
coincide con la necesaria, y ver su grado de coincidencia con la cali dad realizada, ya que
en el fondo muchos problemas de la calidad pueden tener su origen en falsas expectativas
por parte del cliente sobre las caracteristicas de un producto 0 servicio.
2. EVOLUCION HiSTORICA DE LA CAUDAD
La preocupacion por la calidad es tan antigua como la humanidad. de hecho los
restos arqueologicos dan fe de la mejora que experimentaron las herramientas que el
hombre plimitivo desarrollo con el fin de cazar animales y crear lugares donde habitar.
Como sefiala Juran (1995), ya en el siglo XI antes de Cristo en China se fijo un
sistema para controlar el desarrollo de productos artesanales con dos depariamentos
encargados de la calidad de los productos: uno de fommlar y ejecutar estandares y el otro
para supervision y prueba. Incluso se promulgarop decretos para prohibir la venta de
productos de calidad inferior y se presto tambien atencion a la medicion de longitud.
capacidad y peso. Mouradian (2002) sefiala que Kheops (rey del Antiguo Egipto
alrededor del 2680 AC.) fue el que establecio el "cubit'" (codo)! como la distancia que iba
desde su coda hasta la punta de su de do corazon. En el imperio egipcio se han llegado a
encontrar, como sefiala Juran (1995), las primeras especificaciones de calidad escritas en
papiros egipcios de mas de 3500 afios de antigiiedad. Ejemplos de calidad y de medicion
se pueden encontrar tambien en otras civilizaciones como la babilonia (de la que se tiene
! Para mas infomlaci6n se recomienda leer http: \\\vw.egiDtoIOf,ia.org cienci,l'll1atcmaticas
unidades.htm 0 httD: w\\w.I11etalunivers.com are.:;; metrologiadimensionaL tutorialm.:dicionantiguedad. hUll
10 CAUDAD DE SISTEtvLA.S IN"FOIUviA. TICOS &>RA-MA
constancia de una garantia de calidad que data del 429 A.c.), gIiega, romana, etc.;
impelios en los que la estandarizacion juega tambien un importante pape!.
Durante la Edad Media y el Renacimiento, la creacion de pueblos y ciudades
incremento la division del trabajo y el desanollo de habilidades especializadas. Cobran
impOltancia los artesanos que se familiarizan con los materiales utilizados y reciben un
entrenamiento especifico durante su aprendizaje, organizandose una jerarquia de
categorias (maestro, aprendiz, etc.) y los gremios con el fin de administrar los monopolios
y transmitir la experiencia y conocimientos. Juran (1995) destaca que en este momento
historico, los artesanos son los que realizan toda la secuencia de tareas para la creacion de
un producto y que el comprador es el responsable del "aseguramiento" de la calidad,
inspeccionando y probando el producto en los mercados. Este autor destaca tambien
excelentes sistemas de gestion de la calidad como el del "Arsenal de la Repziblica
Veneciana" durante los siglos XII al XVIII.
Precisamente, a mediados del siglo XVIII se inicia en InglatelTa la reyolucion
industrial que se expande al resto de Europa y otras partes del mundo, y en la que destacan
la gI'an cantidad de maquinas inventadas. Surgen las abricas que pe1111iten un aumento de
la productividad. y que implantan la produccion en mas a en la que las tareas se dividen
entre yarios trabajadores de la fabrica, dando como resultado una mayor produccion mas
asequible y un aumento de la demanda. Crece tambien la necesidad de estandarizacion de
las piezas: en este sentido Mouradian (2002) sefiala a Jean-Baptiste de Gribeauyal como el
primer inventor que introdujo el concepto de intercambiabilidad en 1767 para la
fablicacion de artilleria fiancesa. Se supervisan los productos resultantes de la cadena de
produccion y nace el control de calidad (pasa 0 no pasa).
Por otro lado, los trabajadores no se encuentran en estado de autocontrol pOl'que
no tienen contacto con e1 cliente. Esta situacion se agudizara alm mas C011 la adopcion del
sistema de produccion cientifica de F.W. Taylor en e1 que se separa claramente la
planificacion de la ejecucion (taylorismo). Se crearon los departamentos de inspeccion, se
aumento la produccion. pero se tel1nino dafiando las relaciones personales. 10 que tuvo a
la postre un efecto negativo sobre la cali dad.
La gestion y el concepto de "calidad moderna" surgen en 1924 en los Bel!
Telephone Laboratories. para atender las rec1amaciones de los clientes que instalaban
(inwntado en 1876). Se crea e1 Departamento de Aseguramiento de Calidad del
que fOl1no parte W.A Shew'hart, y a quien se Ie puede considerar como el padre del
modemo aseguramiento de la cali dad. Shewhart propUgI10 la utilizacion de tecnicas
estadisticas y control de procesos (la "plimera ola" del control estadistico de la calidad,
seglll1 Juran (1995). Shewhart introduce el grafo de controL el desanollo del muestreo
estadistico (Tague, 2005) y es el creador de1modelo PHV A (Planificar, Hacer, Verificar,
Actuar). El libro de Shewhart (1931), que subraya la impoltancia de los metodos de
control estadistico del proceso para reducir la variabilidad del proceso, se conviltio en el
texto basi co en las empresas sobre calidad en Japon y en EElJU.
(;. R.A. -?vlA CAPiTULO 1: CONCEPTO DE CAUDAD 11
Shewhart se dedic6 a impartir una serie de cursos durante los afios 1920 aplicando
algunas de las tecnicas citadas, Joseph Juran fue uno de los asistentes a estos cursos y
posterionnente trabajaria sobre control estadistico. Por su parte, W. Edwards Deming
tambien trabaj6 con Shewhart hacia 1920 y luego en el departamento de agricultura
norteamericano en el que impuls6 la utilizaci6n del Disefio de Experimentos (DOE)
propuesto por Fisher.
Durante la Segunda GuelTa Mundial, Juran y Deming colaboraron con las fuerzas
annadas nOlteamer1canas, que hicieron un gran uso de la inspecci6n por l11uestreo,
adaptando las tab las desalTolladas en Bell System, en 10 que Juran (1995) denol11ina la
"segunda ola" del control estadistico del proceso. Al acabar la guelTa se produjo una gran
escasez de productos, por 10 cual la calidad de los pocos que quedaron descendi6
considerablemente, porque los fabr1cantes dieron pl10l1dad a la producci6n de gr'andes
VOlL1l11eneS para conseguir cuota de mercado.
Por otra parte, los japoneses despues de la Segunda GuelTa Mundial se enfrentaron.
entre on'os muchos problemas, al desafio de cambial' su reputaci6n de productos de mala
calidad. Juran (1995) sei'iala n'es contribuciones impOltantes que llevadan a modificar
notablemente esta situaci6n: los cursos de fOl111aci6n organizados porIa Ch'i!
COllllllllllicatiolls Section de las fuerzas de ocupaci6n nOlteamericana. las conferencias de
Deming sobre conn'ol estadistico de la calidad y las conferencias de Juran sobre gesti6n de
la cali dad. La industria japonesa aplicando estos principios ganada gr'andes cuotas de
mercado a nivel intemacional con productos muy competitivos.
En los ai'ios cincuenta otros dos gUrLlS tambien influyeron notablemente en la
difusi6n de las ideas sobre calidad: Anmnd Feigenbaum, que public6 el libro Total
Quality Control en 1951 y Philip B. Crosby que impuls6 impOltantes programas de
mejora de la calidad desde el Quality College.
Durante estos ai'ios se crearon en muchas empresas norteamericanas y europeas los
departamentos de calidad, cuya misi6n se cenn'aba en separar los buenos productos de los
malos al final de la secuencia de producci6n. En estas empresas, como sefiala Juran (1995)
la producci6n se lleva a cabo por departamentos .estancos, y la fonnaci6n junto con la
necesidad de dar importancia a la cali dad se limita al departamento de calidad.
En los ai'ios sesenta cuatro aspectos desafiaron la adecuaci6n de la calidad en
EEUU:
I EI incremento del consumismo
I EI incremento de demandas judiciales sobre calidad
I EI incremento de la regulaci6n gubemamental sobre la calidad
I La revoluci6njaponesa de la calidad
12 CAUD.-ill DE SISTEMAS INFOR:'vL.\TICOS
Durante los 60 y 70 varios productos japoneses aumentaron su cuota de mercado
a nivel intemacional, mientras que tanto las empresas norteamericanas como europeas no
se habian tomado en serio el tema ya que pnicticamente se vendi a 10 que se producia.
En los 70 hubo una crisis de cali dad en estos paises que se supero en los ochenta
con exho11aciones a preocuparse por la calidad. mejora de la cali dad proyecto por
proyecto, y la "tercera ola" de control estadistico del proceso (Juran, 1995). Este autor
sel'iala como en los ochenta se reemplaza el taylorismo por el enriquecimiento del puesto
de trabajo transfiriendo a la mana de obra decisiones y acciones previamente asignadas a
los directivos. Se hace enfasis en el autocontrol, autoinspeccion, extension de los trabajos,
equipos de trabajo autodirigidos. mejora de la calidad, implicacion de 1a alta direccion,
p1anificacion estrategica de la calidad, reingenieria de procesos de negocio, fOn11aclOn,
medicion, benchmarking, etc. En definitiva, el significado de "ca1idad" cambia desde un
enfoque centrado solo en el producto a Lm enfoque de gesti6n organizacional, de significar
cumplir las especificaciones del producto a satisfacer todas las necesidades y expectativas
del c1iente. La calidad se extiende a la empresa en su conjunto y pasa a tener la maxima
prioridad. en el momenta en que el c1iente tiene mayores posibilidades de eleccion y que,
por tanto. aumenta continuamente su eXlgencla sobre los productos y servicios que
compra.
En estos anos se empezaron a usar 1a familia de nonnas ISO 9000 en Europa y se
desalTollan toda una pletora de premios sobre la calidad (como el Malcom Baldrige
:\'acional Quality Award de 1987).
En los noventa se desalTolla aim mas los temas de calidad y aparecen nuevos
enfoques. como Seis-Sigma.
SegllI1 Juran (1995) si el sig10 x,'( fue e1 Siglo de la Productividad, el siglo XXI
sera conocido como el Siglo de la Calidad.
3. CONCEPTOS RELACIONADOS CON LA CAUDAD
En la nonna UNE-EN ISO 9000:2000 Sistemas de gestion de la calidad.
FUlldol7lentas y mcabularia (ISO. 2000a) se ac1aran diferentes tenninos relacionados con
la calidad. AsL se tratan los tenninos requisito, entendido como "necesidad a expectativa
establecida. generalmente implicita 1I abligataric/' y satisfaccion del cliente, es decir, la
percepcion del c1iente (que puede ser extemo 0 intemo) sobre el grado en que se han
cumplido sus requisitos. Tambien se define la capacidad de una organizacion, sistema 0
proceso. como la aptitud para realizar un producto que cumple los requisitos para el
mismo.
gRA.-ivV\ CAPiTULO 1: CONCEPTO DE CAUDAD 13
3.1. Conceptos relacionados con la gestion de la caUdad
En esta nom1a se definen otros conceptos relacionados con la gesti6n de la cali dad:
e Politica de la calidad: intenciones glob ales y orientaci6n de una organizaci6n
relativas a la calidad tal como se expresan fonnalmente por la alta direcci6n.
e Sistema de gestion de la calidad: sistema de gesti6n para dirigir y controlar
una organizaci6n con respecto a la calidad.
e Planificacion de la calidad: parte de la gestion de la calidad enfocada al
establecimiento de los objetivos de la cali dad y a la especificaci6n de los
procesos operativos necesarios y de los recursos relacionados para cumplir los
objetivos de la calidad.
e Control de la calidad: parte de la gesti6n de la calidad orientada al
cumplirniento de los requisitos de la calidad.
e Aseguramiento de la calidad: parte de la gesti6n de la cali dad orientada a
proporcionar confianza en que se cumplinin los requisitos de la cali dad.
e Mejora de la calidad: parte de la gesti6n de la calidad orientada a aumentar la
capacidad de clill1plir con los requisitos de la calidad.
Tambien son muy importantes los tenninos relativos a la confonnidad, como
aceptaci6n del producto 0 servicio:
e Conformidad: cumplirniento de un requisito.
e No Conformidad: incumplirniento de un requisito.
e Defecto: incumpliIniento de un requisito asociado a un uso previsto 0
especificado.
e Accion Preventiva: aCClOn tomada para elin1inar la causa de una no
confonnidad potencial u otra situaci6n potencialmente indeseable.
e Accion Correctiva: accion tomada 'para eliminar la causa de una no
confonnidad detectada u otra situaci6n indeseable.
e Correccion: accion tomada para elimmar una no confonnidad detectada. Una
correccion puede ser por ejemplo un reproceso (acci6n tomada sobre un
producto no confonne para que cumpla con los requisitos) 0 una reclasificacion
(variac ion de la c1ase de un producto no confonne, de tal fonna que sea
confonne con requisitos que difieren de los irUciales).
e Reparacion: accion tomada sobre un producto no confonne para convertirlo
en aceptable para su utilizacion prevista.
14 CAUDAl) DE SISTEMAS I]\iFORlvLATICOS RA-MA
o Desecho: accion tomada sobre un producto no confonne para impedir su uso
inicialmente previsto.
3.2. Conceptos relacionados con la documentaci6n de la
cali dad
Otros conceptos importantes son los relativos a la documentacion, que seglin la
nonna contribuye a:
o Lograr la confonnidad con los requisitos del cliente y la mejora de la calidad.
o Proveer la fonnacion apropiada.
o La repetibilidad y la trazabilidad.
o Proporcionar evidencias objetivas.
o Evaluar la eficacia y la adecuacion continua del sistema de gestion de la
calidad.
En la nonna ISO 9000 se distingue entre:
o Manuales de la calidad: documentos que proporcionan infonnacion
coherente, interna y externamente, acerca del sistema de gestion de la calidad
de la organizacion.
o Planes de la calidad: documentos que describen como se aplica el sistema de
gestion de la calidad a un producto, proyecto 0 contrato especifico.
o Especificaciones: documentos que establecen requisitos.
o GUlas: documentos que establecen recomendaciones 0 sugerencias.
o Procedimientos documentados, instrucciones de trabajo y pIanos documentos
que proporcionan infonnacion sobre como efectuar las actividades y los
procesos de manera coherente.
e Registros: documentos que proporcionan evidencia objetiva de las actividades
realizadas 0 resultados obtenidos.
4. LECTURAS RECOMENDADAS
o Juran, J.M. (ed.) (1995). A History of Managing for Quality. ASQC Quality
Press, Milwaukee. Este libro editado por Juran, uno de los mayores gunis de la
calidad, recopila la historia de la calidad en diferentes paises y epocas,
centrandose en los grandes imperios antiguos y en el desarrollo industrial
europeo y norteamericano. Sin embargo, adolece del defecto de no tratar los
logros de calidad en el mundo iberoamericano.
o RA.-ivLA. CAPiTULO I: CONCEPTO DE CALIDAD 15
e Mouradian, G. (2002). The Quality Revolution: A Histol) of the Quality
Movement. University Press of America, Lanhan. En este libro se repasa la
historia de la cali dad desde los origenes de las civilizaciones hasta el siglo XXI.
e ISO (2000a). UNE-EN ISO 9000:2000 Sistemas de gesti6n de la calidad.
Flilldamentos y vocabulario. AENOR. Esta norma intemacional presenta los
principales conceptos basicos relacionados con la calidad y establece una
tenninologia aceptada en todos los paises iberoamericanos.
5. SITIOS WEB RECOMENDADOS
e http://\vww.aec.es La Asociaci6n Espanola para la Calidad es la mas
importante a nivel nacional y tiene varias secciones dedicadas a aspectos
especificos de la calidad. Adelmls edita la revista "Calidad".
e http://w\vw.asq.org La American Society for Quality es una de las asociaciones
mas importantes a nivel intemacional y posee un catalogo de libros
relacionados con la gesti6n de cali dad. Ademas edita varias revistas sobre
calidad, entre ellas Quality Progress (sobre diferentes aspectos de la calidad en
general) y Software Quality Journal (especializado en calidad de software).
e http://\v\vw.juran.com/Web del Instituto Juran donde se puede encontrar
informaci6n sobre la actividad de esta organizaci6n basada en las ideas de
Juran.
e http://w\vw.philipcrosbv.com/Web de Philip Crosby y asociados. Se muestra
la actividad empresarial de esta organizaci6n. Es posible acceder a una
colecci6n interesante de artfculos escritos por sus miembros, entre ellos, Philip
Crosby.
6. EJERCICIOS
1. De las definiciones de cali dad dadas por los gurus y nonnas intemacionales,
(,Cmll considera que refleja mejor la "vista de fabric ante" en tenninologia de
Garvin (1985)? (, Y cualla "vista de usuario"?
2. Comente estas dos apreciaciones sobre la calidad: Kitchenham afmna que "la
calidad es dificil de definir, imposible de medir y facil de reconocer", seglin
Gillies la cali dad es "tr-ansparente cuando esta presente, pero facilmente de
reconocer en su ausencia". Compare estas afirmaciones con las defmiciones de
calidad citadas en este capitulo.
3. Explore los sistemas de calidad existentes en los imperios Inca y Azteca. (,Que
funciones 0 roles existian relacionados con la calidad? (,Quienes las
desarro llaban?
16 CAUDAD DE SISTEMAS IN'FOfu'vlATICOS RA-ivlA
4. Describa la organizaci6n de la AEC (Asociaci6n Espanola de la Calidad), y de la
ASQ (American Society for Quality).
5. (,Que diferencia hay entre una "acci6n correctiva" y una "correcci6n"? Ponga
ejemplos de ambas.
6. Explique que actividades de la gesti6n de la calidad podrian considerarse de
"control de la cali dad" y cuMes de "asegurarniento de la calidad".
7. Especifique el contenido que deberia tener un Manual de la Cali dad, para ello
puede ser conveniente revisar la norma ISO 10013: Directrices para desarrollar
Manuales de la Cali dad.
8. Especifique un metodo para desarrollar un Plan de Calidad. ConsuIte, si 10 estirna
conveniente, la norma ISO 10005: Gesti6n de la Calidad - Directrices para Planes
de la Calidad.
9. Resuma la historia de la calidad en su pais desde 1960 hasta la actualidad,
senalando sus principales hitos: creaci6n de una asociaci6n nacional,
implantaci6n de prernios, difusi6n de normas, etc.
10. Estudie la evoluci6n de la calidad en las industrias automovilistica, farrnaceutica,
aeronautica y rnilitar.
*
CAPITULO 2
TECNICAS Y HERRAMIENTAS DE
CALIDAD
*'7 &
"Si no lIsamos las herramientas de calidad, pronto desclibriremos 10 poco zitiles que somas para
Illlestra comunidad ala hora de Gliadir valor a las lecciones que vamos aprendiendo "
Dr. Frank K. Toda
1. INTRODUCCION
Las herramientas de calidad son tecnicas y metodos mas 0 menos justificados que
ayudan a obtener informacion para mejorar un escenario de calidad. Aunque son muchas
las c1asificaciones que se pueden encontrar, en este libro se ha optado por la propuesta por
Okes (2002) para presentar las mas importantes. Esa c1asificacion pennite agrupar las
herrarnientas en las siguientes categorias.
CiI
herramientas basicas
CiI
herramientas de gestion
CiI
herramientas de creatividad
CiI
herrarnientas estadisticas
CiI
herrarnientas de disefio
CiI
herrarnientas de medicion
18 CAUDAD DE SISTEMAS INl'OR.cvlA TICOS @RA-lvlA.
En los siguientes apartados se expondran los fundamentos de cada una de ellas,
finalizando con una reflexion sobre los modelos de madurez y el uso de las herramientas.
2. HERRAMIENTAS BAslCAS DE CAUDAD
2.1. Diagrama de flujo
Los diagramas de flujos tienen como objetivo descomponer los pasos de un
proceso en una secuencia. Se pueden emplear los siguientes elementos: secuencias de
acciones, servicios 0 materiales que entran 0 salen del proceso, personas implicadas,
tiempo empleado en cada uno de los pasos y medidas del proceso.
Se pueden usar cuando se pretende describir como se desarrolla un proceso, 0
cuando pretende establecerse una comunicacion entre personas relacionadas con el
proyecto. Alguno de los simbolos que se puede utilizar son los representados en la figura
2.1:
alrnac.
~
interne
/ dato, I
Figura 2.1. Simbolos tipicos us ados en los Diagramas de Flujo
Para desarrollar un diagrama de flujo se recomienda seguir estos pasos:
1. Definir el proceso que debe ser representado.
2. Identificar y definir las actividades que deben ser desanolladas y el orden en el
que deben hacerlo.
3. Representar las actividades como cajas y la transicion entre actividades como
flechas de manera que sea posible hacer una traza de este desarrollo.
CAPiTULO 2: TECNICAS Y HERRA1\1IENTAS DE CAUDAD 19
4. Revisar el diagrama de flujo con otras personas implicadas en el proceso para
llegar a un consenso sobre su validez.
La figura 2.2 representa un ejemplo de diagrama de flujo.
1. Identificar
I Calidad
I __ _
.:.sirven para
el problema?
r Dlme"'o.,, de -, --r
N ~ ~
5.0btener
Conclusiones
4. Ejecutar el
Plan de
Mediciones
Figura 2.2. Ejemplo de Diagrama de Flujo
2.2. Diagrama causamefecto
2. Identificar
Metricas para
esas
dimensiones
3. Realizar un
plan de
mediciones
Tambien llamado diagrama de espina de pescado (por su forma) 0 diagram a de
Ishikawa (por su creador), el diagrama causa-efecto es una helTarnienta que se utiliza
para identificar, explorar, y mostrar todas las posibles causas de un problema especifico
(efecto).
Es una hen-amienta que, combinada con ou"as de identificacion de problemas como
la tormenta de ideas, facilita y potencia el u"abajo en grupo.
Su representacion consiste en un rectangulo situado a la derecha del esquema
donde se indica el efecto que se quiere analizar. Se dibuja una flecha de entrada (a modo
de columna vertebral del pescado) a este rectangulo, a donde llegaran las otras fechas
provenientes de los posibles focos de los problemas que generan el efecto que se esta
estudiando. A estas flechas, Ie Uegaran ou"as secundarias con posibles subcausas
relacionadas con dichos focos. A medida que el anal isis vaya teniendo niveles mas
profundos, las subdivisiones iran ampliandose. Los focos plincipales suelen enunciarse
como las 5 0 6 M: "j\1ano de Obm", "Maquinas", "Materiales", "Medidas", "j\;fedio
Ambiente" y "Merodos".
Para elaborar un diagrama de causa / efecto como el de la figura 2.3 se puede seguir
este procedimiento (Can-etero et al., 1999):
20 C."J.IDAD DE SISTEM.A.S INFORt\tA.TICOS RA-MA
Medidas Materiales Personal
Exactitud Compilador Programadores
Tiempo SGBDR Analistas
Fallos en los
-ilJ;>
Sistemas
Informaticos
Ratones
Sueldos
Inferencia
bajos
Impresoras
Presion Procesamiento
Orden adores
Medio Ambiente Metodos Maquinas
Figura 2.3. Ejemplo de diagram a causa/efecto
1. Elaborar un enunciado claro del efecto (problema) que se ha detectado.
2. Dibujar el diagrama de la espina de pescado, colocando el efecto (problema) en
un cuadro en ellado derecho.
3. Identificar de 3 a 6 espinas mayores que puedan ser las causas del problema
/ efecto principal.
4. Dibujar las espinas mayores como flechas inclinadas dirigidas a la flecha
principal.
.
5. Identificar causas de primer nivel relacionadas con cada espina mayor.
6. Identificar causas de segundo nivel para cada causa de primer nivel.
7. Identificar causas de tercer nivel para cada causa de segundo nivel, y as!
sucesivamente.
8. Observando los resultados, identificar la causa raiz que permita obtener
conclusiones en la resoluci6n del problema.
s RA-ivV\ C.-\PITULO 2: TECNICAS Y HERRAlv!lEJ\TAS DE CAUDAD 21
2.3. Diagrama de Pareto
Es una hen-amienta utilizada para establecer lma jerarquia de los problemas 0 las
causas que los generan, a partir de una representacion gnifica de los datos obtenidos,
dando una idea clara y cuantificada del orden en que deben ser abordados estos problemas
o causas. Establece que "al eliminar el 20% de las callsas que generan lin problema en
lIna sitllacion resalveria 1111 80% de elias, mientras que el 80% de las cal/sas restantes
resllelven el 20% de los problemas restalltes". EI nombre de Pareto fue dado a esta
heiTamienta por Juran en honor del economista italiano Wilfredo Pareto que definio la
regIa 80/20 para explicar la disttibucion de las riquezas.
Para elaborar un diagrama de Pareto hay que seguir los siguientes pasos:
1. Identificar el problema a analizar. seleccionando los problemas 0 variables que se
van a investigar. decidiendo los datos y la fom1a de clasificarlos y definiendo ei
metodo a utilizar en la recopilacion de datos.
2. Disei'iar una hoja de recopilacion de datos para que gum'dar datos sobre las causas
a investigar y el nlunero de veces que aparecen.
3. Reunir los datos y efechlar el calculo de porcentaje de las frecuencias de
apmici6n.
4. Ordenar los datos en orden decreciente de frecuencia.
5. Una vez en esta disposicion. calcular las frecuencias acumuladas para cada causa.
6. Dibujar dos ejes verticales y un eje hOlizontal. fvIarcar el eje vertical izquierdo
con la cantidad de causas acumuladas y el derecho con una escala de 0% hasta
100%. Luego se divide el eje horizontal en un numero de intervalos igual al
l1l1mero de items clasificados.
7. Construir un grafico de ban-as con el mism0 ancho y sin dejar espacio entt'e ellas:
este grMico esta bas ado en las cantidades y porcentajes de cada uno de los items
colocandolas de mayor a menor y de izquierda a derecha
8. Dibujar la curva de frecuencias acumuladas.
9. Escribir cualquier informacion necesaria sobre el diagrama (titulo. departamento
implicado. unidades. etc.) y sobre los datos (periodo de tiempo. l1umero total de
datos, etc.)
Para detenninar las causas de mayor incidencia en un problema, se traza una linea
horizontal a partir del eje vertical derecho. desde el punto don de se indica el 80% hasta su
21 CALIDAD DE SISTEMAS INFOfu'vlATICOS RA.-MA
interseccion con la curva acumulada. Desde este punto trazar una linea veltical hacia el eje
horizontal. Los items comprendidos entre esta linea veltical y el eje izquierdo (de
cantidades acumuladas) constituyen las causas cuya eliminacion resuelve el 80% del
problema. Asi en el ejemplo mostrado en la figura 2.4, las causas identificadas como A, G
y F representan ese 20% de las causas que alTeglalian el 80% de los problemas.
Diagrama de Pareto
-- ...... -- -=< -- -- - -- ...... - -- -- -- - 2-, .
Figura 2.4. Ejemplo de diagrama de Pareto
2.4. Hoja de chequeo 0 de comprobacion
La Hoja de Recopilacion de Datos tambien llamada Hoja de Registro. Lista de
Velificacion. Chequeo 0 Cotejo sirve para identificar y analizar tanto los problemas como
sus causas. Para ello establece los l11ecanismos necesarios para reunir y clasificar los datos
recabados seglll1 detenllinadas categolias, mediante la n o t ~ c i o n y registro de sus
fi'ecuencias para cada uno de los contextos posibles: verificacion (inspeccion, chequeo 0
tare as de mantenil11iento), localizacion de defectos en las piezas, distribucion de
variaciones de variables de los articulos, c1asificacion de articulos defectuosos, etc.
Para ello es preciso, por un lado, definir una estnlchlra, en la que se almacenan'll1
los datos: por otro. especificar el procedil11iento de recopilacion y analisis de dichos datos,
indicando quien. como y cuando hacer la planificacion y la caphlra.
RA-ivl"'- CAPiTULO 2: TECNICAS Y HERR.-\lVlIENTAS DE CAUDAD
De modo general las hojas de recopilaci6n de datos se pueden c1asificar seglin el
tipo de datos en:
o De velificaci6n. inspeccion, chequeo 0 tareas de mantenimiento.
I) De localizaci6n de defectos en las piezas.
I) De dishibuci6n de variaciones de variables de los articulos (peso, volumen,
longitud, calidad, etc.).
I) De c1asificaci6n de articulos defectuosos.
2.5. Grafo 0 Diagrama de control
Son representaciones gnlficas utilizadas para detem1inar desde un punto de vista
estadistico si un proceso esta 0 no bajo controL esto es, si hay variabilidad en el proceso y
descubrir a que obedece esta variabilidad. La variabilidad es cualquier desviaci6n que el
producto 0 servicio final puede tener respecto a la especificacion de los usuarios y que
puede ser deb ida a cualquiera de los elementos.
Los graficos de control sil-ven para representar una caracteristica de cali dad medida
o calculada a partir de muesh'as del producto que son tomadas a 10 largo de un espacio de
tiempo. Consta de una linea central (que suele ponerse en tomo a la media muestral ~ l y
dos limites de control superior (LCS) e inferior (LCI) que se basan en conceptos y
resultados estadisticos
l
(vease figura 2.5).
LCS
.Ll
LCI
Figura 2.5. LCS Y LCI para un diagrama de control
I Es posible detinir Llna serie de tests que demuestran estadisticamente que el proceso esta bajo control.
aunque todos los puntos e s ~ n entre los dos limites.
24 CALIDAD DE SISTEvl!\S TIeos
@RA-MA
En el gnifico se dibujan los datos correspondientes al proceso. Si todos los puntos
estan entre estos dos limites, puede decirse que el proceso esta bajo control.
2.5.1. TIPOS DE DIAGRANIA DE CONTROL
Existen dos familias de graficos de control: por variables y por atributos.
2.5.1.1. Gnificos de Control por Variables
Se utilizan como indicadores de calidad algunos parametros estadisticos asociados
a los valores medidos en las muestras de los productos tomados a intervalos regulares de
tiempo.
Los pasos que hay que dar para elaborar un diagrama de control pOl' variable son
los siguientes:
1. Detenninar el indicador de calidad que mejor describa la situacion de calidad a
controlar.
2. Tomar valores del indicador de muestras a intervalos regulares de tiempo. Como
minimo se recomienda tomar unos veinticinco valores.
3. Decidir el tipo de gnlfico de control por vatiable que deb a utilizarse.
4. Ca1cular los panimetros estadisticos necesarios (tamafio de la muestra. media.
recorrido y limites de control).
5. Representar el gnifico con una helTamienta software adecuada.
6. Analizar el grafico y actuar sobre el proceso en funcion del resultado obtenido.
En funcion de como esten agrupados los datos de las muestras y de los estadisticos
que se quieran es.tudiar. se pueden crear distintos tipos de grafos de control por variables.
Estos tipos son 16S siguientes:
@ X-Barra 0 de Medias: pennite estudiar como varian las medias de las
muestras estudiadas (vease figura 2.6).
@ R 0 Recorrido: pennite esmdiar como varian los rangos de los valores
muestrales estudiados. Se utiliza cuando el tamai'io de las muestras es inferior a
10 (vease figura 2.7).
@ S 0 de desviaciones tipicas (cr): pennite estudiar como varian las desviaciones
tipicas de los valores muestrales estudiados. Se utiliza cuando el nllmero de
muestras es superior a 10.
RA-MA
340
320
3G'O
c
co
Q;l
280
L
Q,I
i5.
E 260
co
(I)
240
220
200
200
o
CAPiTULO 2: TECNICAS Y HERRAJvlIENTAS DE CAUDAD 25
, ,
2 4 6
Grafico XBarra de Fallos
de Sistema de Informacion
, ,
8 10 12 14 16 i8 20 22 24
Sample
Figura 2.6. Ejemplo de Grafico de Control de Medias
Gr6fico It de Fallos de
Sistema de Informacion
, ,
2: 4 6 8 10 12 14 16 18 20 22 24
Sample
Figura 2.7. Ejemplo de Grafico de Control de Recorrido
UCL=339,5
X=275
LQ=210,5
R=88,5
lCL=:O
26 CAUDAD DE SISTEiVlA.S Il'iFORMATICOS RA-ivlA.
eX-Barra! Rode Medias-Recorridos: son la representaci6n conjunta de un
gritfico X-Ban-a con uno R. Se supone que si la variable estudiada sigue una
distribuci6n nonnal, entonces X-Ban-a y R son independientes. Si se presentan
gritficos paralelos, entonces la distribuci6n seria sesgada. Es interesante
siempre comparar la media de los rangos con la variaci6n pen-nitida (vease
figura 2.8).
Grafico XBarra-R de Fallos
de Sistema de Informacion

UCL=33'i/5
lCL=21O,5
__ -, __ -, __ -, __ -, __ -, __ -, __ -,,-__ ,,--,,-__ .-__ .-.J
10 1;2 14 1$ 1S 20
sample
200 1-========================, UCL=ZCJZ,O
/
\ /1', v--J+-<\
,
/ '-J
---" /
L:::::;::=::;:=:::;::=:::;::=:::;::=:::;::==;:===;:===;:===;:===;===;=-.J
8 10 12 14 16 18 20 22 2+
5ample
Figura 2.8. Ejemplo de Griifico de Control de Medias/Recorrido
2.5.1.2. Gnificos de Control por Atributos
El contexto estadistico en el que se desan-ollan esta regido por los mismos
principios que los graficos de control por variables, por 10 que para elaborar un diagrama
de Control por Atributos se sigue un procedimientC1 similar al descrito para los graficos de
control por variables.
Es posible hacer la siguiente clasificaci6n atendiendo a 10 que se pretende estudiar:
Numero de productos defectuosos: se pretende evaluar si el proceso esta 0 no
bajo control atendiendo al numero de productos defectuosos que genera. Es
posible encontrar los dos siguientes tipos de diagramas:
a. Tipo p 0 de Proporcion de Unidades No Conformes: es un grafico de
control que pennite representar la proporci6n de unidades no confonnes
de cada muestra respecto del tiempo. Dichas muestras no tienen por que
CAPiTULO 2: TECNICAS Y HERRA,'vllENTAS DE CAUDAD 27
ser del mismo tamafto. La figura 2.9 muestra un ejemplo de un gnifico de
control por atributos de la proporci6n del numero de defectos.
Grafico P de Datos Invalid os
0 , 8 ~ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
lJCL=O,7397
0,6
::: 0,5
o
:;::
13 0,4
Q.
o
is: 0,3
P=0,2692
0,2
0,1
0,0 lCL=O
,
2 4 6 8 10 12 14 18
8<3mple
Tests perfbrmed with unequal sample sizes
Figura 2.9. Ejemplo de Diagrama de Control por Atributos tipo p
b. Tipo np 0 de Numero de Unidades no conformes respecto del
tiempo: es un gnifico de control que pennite representar el numero de
unidades no conformes de la muestra respecto del tiempo. Pennite
analizar tanto el mimero de unidades no conformes como la posible
existencia de causas especiales. Al realizar la inspecci6n de un atributo se
clasifican las unidades en conformes 0 no confonnes (np). EI tamafto de
las muestras puede variar en cada inspecci6n. La figura 2.10 muestra un
ejemplo de un tipo de gnifico de control por atributos de unidades no
confonnes.
e Numero de Defectos por Producto. Se pretende detenninar si el proceso esta
bajo control, estudiando el numero de defectos que tiene cada producto. En
funci6n de la profundidad del estudio se pueden encontrar los siguientes tipos
de diagramas de control de esta clase:
c. Tipo Code numero de no conformidades: pennite representar el
numero de defectos 0 de no confonnidades de todas las unidades
producidas con respecto al tiempo. Para ella se contara el numero de
defectos c que tiene cada muestra. La figura 2.11 muestra un ejemplo de
este tipo en la que el proceso no esta bajo control.
28 CALIDAD DE IN"FORt\,LA. TICOS RA-MA
d. Tipo U 0 Numero Medio de No Conformidades: este tipo de diagrama
deriva del anterior, pero se realiza calculado la media del numero de
unidades no conformes de una muestra.
22,5
20,0
17,5

5 15,0
CJ
III
"E. 12,5
E
01
10,0
Graficos NP de Datos Invalidos
\

::: Alr' , ' 'm,. 'aT\
1 1 1 1 1 1
3 6 9 U ffi ill v
Sample
UCL=21,99
LCL=5,61
Figura 2.10. Diagrama de Control por Atributos tipo np (generado con Minitab)
2.6. Histograma
EI histograma 0 diagrama de distribucion de Jrecuencias es una representaci6n
gnifica por medio de barras verticales, que ilustra la frecuencia con la que ocurren eventos
relacionados entre sf. Se trata de un instrumento de sintesis muy potente que permite
apreciar la tendencia de un fen6meno.
El histograma puede ser usado para:
CD Obtener una comunicaci6n clara y efectiva de la variabilidad del sistema.
CD Mostrar el resultado de un cambio en el sistema.
CD Identificar anormalidades examinando las formas del grafico.
CD Comparar la valiabilidad con los lirnites de especificaci6n.
GRA-MA CAPiTULO 2: TECNICAS Y HERRA.l'v!lENTAS DE CAUDAD 29
Grafico C de Datos Invalidos
12 UCL=1l,96
10
LCL=O
2 4 5 8 10 12 14 15 18 20
Sample
Figura 2.11. Diagrama de Control pOl' Atributos tipo c
Adjunto al histograma es recomendable realizar un grMico denominado poligono
de frecuencias trazado sobre las marcas de clase de las barras del histograma. Se fOlma
uniendo los pumos fonnados por la intersecci6n de la marca de clase 0 punto medio, con
la fi:ecuencia absoluta 0 con la relativa desde la marca de clase antelior a la primera clase,
hasta la marca de clase posterior a la ultima, (estas clases ficticias tienen una frecuencia
cero). Visualizando ambos graficos se puede apreciar distintos tipos de histograma seglin
su fonna: nonnal, bimodaL de dientes rotos 0 de peine, cortado, distorsionado. etc. Un
ejemplo de histograma es el mostrado en la tigura 2.12.
2.7. Diagrama de Dispersion 0 de Correlaci6n
Tambien llamada Diagrama de Correlaci6n: esta heITamienta sirve para estudiar
una posible relaci6n entre dos vaIiables objeto de estudio de un control de calidad.
Para ella es preciso reunir datos de sucesos oClm-idos don de participan los dos
factores que se pretende detem1inar si tienen 0 no relaci6n. Los datos serall en la fonna
(x.y) donde "x" representa el valor que se pretende detenninar si influye (causa), e "y" el
valor del factor que se considera influido (consecuencia). Estos pares de puntos se dibujan
en un diagrama en el plano como una nube. La observaci6n de esta nube pem1itira
detenninar si hay 0 no relaci6n entre ellas. En caso de haber relaci6n, se espera poder
expresarla como una funci6n matematica y f(x). Nonnalmente, se espera que esta
relaci6n sea lineaL aunque otras funciones polin6micas son posibles.
30 CAUDAD DE SISTEMAS TlCOS RA.-IvL>\
120
iOJ -
5J
20
i70 168 iSJ 208 210
Figura 2.12. Ejemplo de Histograma
La figura 2.13 muestra las diferentes relaciones que pueden darse: correlaci6n
fueltemente positiva, positiva, no correlaci6n, negativa, y fueltemente negativa. Como
resultado del amilisis se obtendra un coeficiente de correlaci6n r, que indicara la fuerza de
la relaci6n, y si esta es positiva 0 negativa:
iii Si r es cero, entonces no hay correlaci6n entre los dos factores estudiados.
iii Cuanto mas cerca este r de 1 6 -1 mas fuelte es la relaci6n entre los dos
factores.
iii Si r > 0, entonces a medida que la magnitud de la causa crece, la magnitud de
la consecuencia tambien.
iii Si r<O, entonces a medida que la magnitud de la causa crece, la magnitud de la
consecuencia decrece.
3. HERRAMIENTAS DE GESTION
3.1. Diagrama de afinidad
Los diagramas de afinidad sil"Ven para organizar un gran nlunero de ideas en
categorias relacionadas, 0 afines (Tague 2005). Fue creado por Kawakita en los atlOS
sesenta.
Las ideas suelen venir de sesiones de trabajo 0 de sesiones de Tonnentas de Ideas.
CAPiTULO 2: TECNICAS Y HERRAMIENTAS DE CAlIDAD 31
Para elaborar un diagrama de afinidad, se recomienda seguir estos pasos:
1. Registrar todas las ideas y conceptos que sUljan en el glUpO de trabajo.
2. Crear categolias generales para esas ideas basandose en criterios de afinidad.
3. Asignar cada idea 0 concepto a dichas categorias, en funci6n del grado de
afinidad.
Q
0
0 v
0
0
C 0
0 0
y Q 0 0
0
0
No
y
0 0
Correlacion
o 0 C 0
Correlacion
0
0
0
c
0
Negativa
0
00 0
0
0
0
0
x
x
0
0
0
0
c 0
Correlacion y
0
o 0 00
0 Positiva
o c
o 0
o 0 0
y
o 00
0
c (; 0 0
Correlacion
o 0 0 C 0
X
0
0
0
00 C c
Compleja
0
0
0
;::" 0
0
00
Correlacion
y 0
0
0
Fuertemente
00
Positiva
0
0
0
0
00
0
0
Figura 2.13. Tipos de diagramas de correlacion
3.2. Diagrama de relaciones
Es una herramienta utilizada para identificar las causas mas significativas de un
problema y representar graficamente los vinculos que puedan existir entre los factores
relacionados con ese problema. Esta herramienta ayuda a un gmpo de trabajo a identificar
los enlaces naturales entre diferentes aspectos de una situaci6n compleja. Los diferentes
elementos del diagrama se relacionan entre SI con flechas.
Los pasos que hay que dar para elaborar un diagrama de relaci6n son los siguientes:
1. Identificar todas las causas posibles de un problema.
32 CAUDAD DE n'iFOIUvlA. TICOS
2. Proponer una causa como la mis probable
3. Estudiar la relaci6n entre esta primera causa y el resto de las causas, sefialando
con flechas las relaciones que vayan surgiendo. Es posible que haya diferentes
niveles de relaci6n.
4. Descartar en cada iteraci6n las causas no seleccionadas.
5. Repetir la iteraci6n hasta encontrar la causa que mas relaciones tenga.
La figura 2.14 muestra un ejemplo de diagrama de relaci6n.
A
c
D
B
Figura 2.14. Ejemplo de Diagrama de Relacion
3.3. Diagrama de matriz 0 matricial
Al igual que ohas henamientas de las citadas hasta ahora, pennite representar
grafical11ente la relaci6n existente entre varios factores. Para ella hay que colocar los
factores sobre las filas y colunmas de una l11atliz. Si existe relaci6n, se l11arca en la
intersecci6n de los factores. Es posible indicar el grado 0 intensidad de la relaci6n
existente. Se suele utilizar para definir la relaci6n enhe los distintos factores que
intervienen directa 0 indirectal11ente en un proceso de mejora de calidad. La figura 2.15
representa un ejemplo de diagrama mahicial.
VLOCIDAD
I SGGRIDAD
!
..
.COi'iiE:'<IDOS
VEWCIDAD
I -4
I
...
SGI3RIDAD
I I
3
-:c- COl'TNIDOS
..
5
I
3
I
Figura 2.15. Ejemplo de Diagrama Matricial
s RA-ivL\ CAPiTULO 2: TECNICAS Y HERRA.ivIIENTAS DE CAUDAD 33
3.4. Matriz de anal isis de datos
Algunos autores como Tague (2005) identifican esta herramienta como un sUbtipo
de la anterior, Hamada L-Shape, que relaciona dos grupos de elementos entre sl, 0 incluso
relaciona los elementos dentro del mismo grupo.
3.5. Diagrama de redes de actividad 0 de flechas
Figura 2.16. Diagrama de redes de actividad
Son una herramienta de planificaci6n que se emplea para representar gnificamente
y de forma estructurada la secuenciaci6n de actividades que hay que desarrollar en un plan
de mejora de calidad siguiendo un orden cronol6gico. La infonnaci6n que se debe mostrar
es la duraci6n de cada tarea, holgura, dependencias entre actividades. Tienen un principio
y un final, con 10 que es posible estimar em into tiempo se va a necesitar para desarrollar el
mencionado plan. Como las flechas indican caminos, es posible identificar caminos
criticos en la realizaci6n del plan. La figura 2.16 muestra un ejemplo de este tipo de
diagrama.
3.6. Diagrama de arbol
Se utiliza para representar jenirquicamente los diferentes niveles de complejidad de
un detenninado proceso 0 producto, partiendo de un primer nivel generico que se va
descomponiendo en niveles de mayor detalle hasta alcanzar un nivel basico 0
autodescriptivo.
3.7. Diagrama de proceso de decisiones
Define un plan de actuaci6n de cara a resolver un problema detenllinado. Se sue Ie
utilizar para implantar planes de actuaci6n de cierta complejidad.
34 CAUDAD DE SISTEMAS INrORJvLA.TICOS
@RA.-MA
Para elaborar un diagrama de este tipo, se deberia seguir este procedimiento:
1. Obtener 0 desarrollar un diagrama de arbol con el plan propuesto, teniendo en el
primer nivel el objetivo del plan, en el segundo, las actividades pl1ncipales para
conseguirlas y en el tercero, una lista de tareas para cada una de esas actividades.
2. Para cada tarea del tercer nivel identificar que es 10 que podria salir mal.
3. Revisar todas las listas de problemas potenciales y eliminar aquellos que sean
improbables 0 cuyas consecuencias pudieran llegar a ser poco significativas. Los
problemas resultantes poddan mosharse como un cuarto nivel.
4. Para cada problema potencial, identificar planes 0 acciones de contingencia que
mitiguen los efectos de esos problemas. Estos planes se pueden mostrar en un
quinto nivel.
5. Esrudia la viabilidad de cada plan de contingencia, marcando con una "X" los
impracticables y con una "0" los que Sl poddan llegarse a dar.
4. HERRAMIENTAS DE CREATIVIDAD
Aunque existen herramientas de creatividad como los mapas concephtales, el usa
de analoglas, etc. aqui se presentani solo la tonl1enta de ideas como la mas utilizada.
Es una herramienta de trabajo en grupo basada en la creatividad de los
componentes del grupo de trabajo. Se pretende obtener el mayor numero de ideas 0
soluciones en el menor tiempo posible, seleccionando poste1101111ente las mas indicadas,
es decir, aquellas que mejor se adaptan a los objetivos del problema. Para ella es necesar10
que el equipo de trabajo conozca dichos objetivos. Existen dos modos de realizacion de
esta tecnica:
EI Modo estructurado: todos los miembros del grupo se yen forzados a
participar, siguiendo un hImo riguroso ..
EI Modo Iibre: los miembros del grupo van aportando ideas seglll1 se Ie van a
ocun1endo sin seguir ningUn ru1110 preestablecido. Se crea un ambiente mas
relajado pero se corre el peligro de que haya personas que no participen y por
tanto no se conozcan sus ideas.
Las fases de una tonl1enta de idea son:
EI Definicion y comunicacion del asunto a tratar a todos y cada uno de los
miembros del gmpo. Se tiene que planificar una agenda para facilitar la
asistencia e todos los miembros.
CAPiTULO 2: TECNICAS Y HERRAMIENTAS DE CAUDAD 35
e Exposicion de ideas. Los pariicipantes van apOliando ideas en alguno de los
modos expuestos anterionnente y el moderador 0 director de la reuni6n las va a
anotando en alglin lugar visible por todos los pariicipantes.
e Seleccion de ideas. Cuando ya no haya mas ideas, todos los miembros deben
seleccionar aquellas dimensiones que mejor se adapten al objetivo de la
medici6n, descartando las peores.
5. HERRAMIENTAS ESTADisTICAS
5.1. Control estadistico del proceso
Se entiende por capacidad de un proceso el grado de aptitud que tiene para cumplir
con las especificaciones tecnicas deseadas. Cuando la capacidad de un proceso es alta, se
dice que es capaz. Cuando se mantiene estable a 10 largo del tiempo se dice que esta bajo
control. Para determinar si un proceso es 0 no capaz, se pueden utilizar las siguientes
herTamientas:
e Histogramas
e Graficos de Control
e Graficos de Probabilidad
e Estudios de indices de capacidad
Este apartado se centrara en los estudios de los indices de capacidad. Se considera
un indice de Capacidad como la relaci6n entre la variaci6n natural del proceso y el nivel
de variaci6n especificada. Se pueden hacer dos clasificaciones:
e Respecto a su posici6n:
a. indices cenrtados con respecto a los limites
b. indices descentrados con respecto a.los limites pero contenidos en ellos
c. S610 con limite superior
d. S610 con limite inferior
e Respecto a su a1cance temporal
a. A corto plazo 0 intragrupo (Capacidad Potencial)
b. A largo plazo 0 intragrupo e intergrztpo (Capacidad Global)
36 CAUDAD DE SISTEMAS INFOR.!YLA.TICOS
CORToPL4Z0 '
(h"i"IRAGRl1J>O)
RA-MA
LARwPtAZO
(h'i-m.-\GRD'.PO E,'
h"{lERGRllPO
PPU PPL
Figura 2.17. Definicion de los tipos de indices de capacidad
5.1.1. iNDICES DE CAP ACIDAD Cp, P p, C
PK
Y PPK
Sean LS Y LI los limites de tolerancia exigidos en las especificaciones, se defme el
indice de capacidad de proceso como:
C = LS-LI
LS - j.J j.J - LI
C
PK
= A1in{ , }
p 6u
3u 3u
Para afinnar que un proceso es capaz C
p
y/o C
PK
deben ser mayor 0 igual que 1.33,
10 que garantiza que el 99.994% de los productos fabricados 0 servicios prestados por el
proceso centrado esta dentro de las especificaciones.
En caso de ser necesario estudiar los dos, ambos deben valer como minima 1.33.
En otro caso, habra que aplicar acciones con'ectoras.
Estudio de Capacidad del Proceso
" Deteccion de fall os en el Sistema de Informacion"
L5l USl
--Within I
- - Over311
D.a:t;a;
LSL 1775;C1Cll)OCI
*
1825.JIOOOO
Potential (Vnthin) Cap,bility
Cp 0;23
CPL 0,32
CPLI QJ;;;:
<::pl; 0,2r.

5"rnpl-= ""-=::tl) 149
N 1:;
StD.;:vi)\IHhirl) 293308:9
28 .. 15313
Overall
Pp 0,31)
PPl 0,3?
PPU
0,2;
Cpm *"
1740 1750 1780 1800 1820 1840 1960
<,b:;-;:r./-=d P-=tfQtrnamo: V'!ithin P.;tr';;-liIun,:.;;: Exp. (J<[o:n:ll Po:rTorm,an:.:;:
PPM .=: l$l ::; LSL 1710$0;;:2 ppr'il =: LSL 1E>Ui4J$('
> IJSL PPM := ppr,i r= U;;L
ppr',., Tet::.! 413333 ..33 PPf,' 3':129,90 PPhl Tot,,! 377003,.01)
Figura 2.18. Ejemplo de Estudio de Capacidad de Proceso (generado con Minitab)
QRA.-MA CAPiTULO 2: TECNICAS Y HERRA.MIENTAS DE CAUDAD 37
En la figura 2.18 se muestra un ejemplo donde mediante la observacion de los
indices de capacidad potencial y global puede deducirse que el proceso no es capaz, ni a
largo ni a corto plazo, y que por tanto habra que aplicar correcciones
5.1.2. INDICES DE CAPACIDAD CPU, PPU, CPL, PPL
Se utilizan cuando el proceso solo tiene un limite de especificacion, bien superior
(CPU y PPU), bien inferior (CPL, PPL).
Se ca1culan:
CPU = L5-
30-
5.2. Diseno de experimentos
CPL = jl-LI
30-
El Disefio de Experimentos (DDE, DOE, Design of Experiments) tiene como
objetivo averiguar si unos deterrninados factores influyen en una 0 varias variables de
interes para la calidad, y si se demostrara dicha influencia, cuantificarla (Vilar, 2006).
Las etapas de las que consta un DOE pueden resumirse en:
1. Defmir los objetivos del experimento.
2. Identificar las causas posibles de variacion.
3. Elegir el disefio experimental adecuado.
4. Especificar medidas y procedirniento experimental.
5. Ejecutar un experimento piloto.
6. Especificar el modelo (lineal, etc.).
7. Esquematizar los pasos del analisis estadistico.
8. Deterrninar el tamafio muestral.
9. Revisar las decisiones anteriores.
38 CAUDAD DE SISTEivL<\S INrORo'viA TICOS
6. HERRAMIENTAS DE DISENO
6.1. QFD (Quality Function Deployment)
El Diagrama de Despliegue de la Funci6n de Calidad (Quality Function
Deployment) es una tecnica utilizada para planificar nuevos productos y servicios 0
realizar mejoras en los existentes a partir de metodos mauiciales, cuyo objetivo es que los
requisitos del c1iente lleguen a estar completamente contenidos en las espcificaciones
tecnicas del producto 0 servicio. La principal ventaja de esta tecnica es la reducci6n del
tiempo del disefio y la disminuci6n de los costes, manteniendo y mejorando la calidad.
Para realizar un proyecto usando QFD se deberian seguir estos pasos (Carretero et
al., 1999):
1. Fase de Organizacion: donde se delimitani el alcance del proyecto, definiendo
tanto el objetivo del proyecto como los miembros del equipo que deben trabajar
en el. Estas personas deben tener experiencia demostrable y pertenecer a los
distintos departamentos implicados en el proyecto.
2. Fase de Definicion. En esta fase se realiza la programaci6n temporal del proceso,
delimitandolo en el tiempo, y planificando temporalmente la duraci6n y las
precedencias de cada una de sus tareas. Tambien es necesario revisar el objetivo
del proyecto para adaptarlo a los recursos de la empresa.
3. Fase de Identificacion y Amilisis de Necesidades. A partir de este punto
comienza el desarrollo del QFD. En esta fase es donde se recopilanlos requisitos
del c1iente, se analizan y se interpretan por los miembros del grupo de u'abajo y
finalmente se relacionan con las caracteristicas del producto que deben sintonizar
con los requisitos de los c1ientes. Para ella se suelen utilizar cuatro tipos de
matrices importantes:
a. lv!atriz de planificacion del producto 0 servicio ("casa de la calidad'),
donde se relacionan las necesidaaes del c1iente con las caracteristicas del
producto 0 servicio a disefiar.
b. lv!atriz de desp/iegue de componentes, siendo su finalidad definir las
especificaciones 0 caracteristicas de las piezas, componentes 0
subsistemas mas significativos del proceso.
c. Matriz de planificacion del proceso, donde se van a relacionar las
caracteristicas y requisitos de los componentes analizados y ponderados
en la mahiz anterior con las especificaciones del proceso de fabricaci6n 0
prestaci6n del servicio.
RA.-ivlA CAPiTULO 2: TECNICAS Y' HERRAMIENTAS DE CAUDAD 39
d. jvlatri::. de pfantficacion de fa prodllccion, que va a recopilar la relaci6n
entr'e las especificaciones del diseno (registradas en la matriz de
planificaci6n del proceso) y la normas de producci6n, estableciendo el
procedimiento, la programaci6n y los puntos de control del proceso de
producci6n.
En la fase de identificaci6n y analisis de necesidades es donde tiene lugar la
planificaci6n critica, centr'andose principalmente en las definiciones del producto 0
servicio. Para completar esta fase, habria que trabajar sobre cada una de las matrices de la
figura 2.19; as!, habria que realizar las siguientes actividades:
1. Seleccionar un Producto/Servicio Importante a Mejorar
2. Obtener la Voz del Cliente
3. Identificar las Necesidades del Cliente
4. Organizar las Necesidades del Cliente
5. Priorizar las Necesidades del Cliente
6. Establecer los Parametros de Diseno
7. Generar la Matriz de Relaciones
8. Obtener la Evaluaci6n de Desempeno del C1iente
9. Correlacionar los Parametros de Diseno
10. Analizar los Resultados
11. Iterar el Proceso
6.2. AMFE (Analisis Modal de Fallos y Efectos)
AMFE (Failure Modes and Effects Anafysis-FiViEA) es un proceso sistematico,
planificado y participativo que se aplica cuando se disenan nuevos productos 0 procesos 0
cuando se rea1izan modificaciones importantes para evaluar 0 detectar fallos y causas que
se originan antes de que lleguen al c1iente. Los fallos se priorizan de acuerdo a la gravedad
de sus consecuencias, de su frecuencia de aparici6n y de 10 facil que sea detectar esos
fallos. Este proceso perrnite reducir costes y tiempos, mejorar y establecer ill1 contexto de
aseguramiento continuo de la cali dad y aumentar la fiabilidad de los productos.
40 CAUDAD DE SISTEivLA.S IN1'ORr'vlATICOS RA-MA
~
CARACTERisTICAS DEL
PRODUCTO
La voz dellngeniero
w
I-
z
w
::i
>
U
"Ill
..J,s
~ ~
we
c.Sl
enu
inO
w-
MATRIZ DE RELACIONES
0:3:
ZO oS:
0'"
3> _ N
"t:I" U 0
"';>;
>
Clz
u ..,
~ l u::..J
(j
0
W
"-
en
w
EVALUACION
Ponderaci6n de Requisitos
Figura 2.19. Estructura de la Matriz "Casa de la Calidad" (Carretero et aI., 1999)
La tabla 2.1 muestra la infonnaci6n basica que se necesita manejar para realizar un
AMFE. Consta de los siguientes campos:
Tabla 2.1. Docurnentaci6n basica del AMFE (Carretero et at, 1999)
CA.PiTULO 2: TECN1CAS Y HERRAt\1IENiAS DE CAUDAD 41
Funcion y/o Proceso: describe la funcion del elemento analizado. Si se
presentan varias funcionalidades, se separanin adecuadamente, ya que pueden
dar lugar a distintos modos de faUo.
Fallo: se refiere al incumplimiento de uno 0 varios requisitos 0
especificaciones del elemento, aunque no este observado par el cliente.
o Mada de Falla: es la forma en la que el elemento estudiado puede dejar
de cumplir las especificaciones para las que fue disenado.
o Ejecta de Falla: en el caso de que se produzca el faUo, en este apartado
deben completarse todos los datos correspondientes a las diferencias de
funcionamiento observadas. Habria que describir a que areas puede
afectar el faUo: si a seguridad, salud, medio ambiente, funcionamiento
correcto, ...
o Causa de Falla: hay que describir las anomalias de las que se tiene
sospecha que han podido producir el faUo: variaciones en los parametros
de manipulacion optima, deficiencias en el diseno del producto, servicio
o proceso, deficiencia en los materiales usados, uso indebido por parte
del cliente, etc.
Evaluacion de la Prioridad: que comprende los siguientes conceptos:
o Controles preventivos: hay que reflejar los resultados de los controles
preventivos previamente realizados a la aparicion del faUo, para estudiar
si es el resultado de un accidente fortuito 0 bien es por causa de alglin
tipo de desgaste.
o Jndice de Frecuencia (F): pennite asignar una probabilidad de que
ocurra lma causa potencial del modo de faUo.
o Jndice de Gravedad (G): sirve para estimar el nivel de consecuencias
sentidas por el cliente. Este indice de gravedad esta tabulado y es funcion
creciente de estos factores: insatisfaccion del cliente, degradacion en las
prestaciones. coste de reparacion.
o Indice de Deteccion (D): es el v l ~ r que mide la probabilidad de que la
causa y el faUo Ueguen al cliente, es decir, la probabilidad de que los
indices de deteccion no funcionen.
o Indice de Prioridad de Riesgo (JPR): mide cuales son los fallos cuyas
probabilidad de riesgo es mayor. Esto pennite identificar los fallos en los
que se deben concentrar principalmente la atencion para empezar a
aplicar ah! las acciones correctoras oportunas. Se obtiene calculando el
producto de los tres indices anteriores: IPR= FG-D.
42 CAUDAD DE SISTEivLA.S INFOIUvLATICOS RA-ivLA.
e Acciones Correctoras: para detem1inar las acciones conectoras es
conveniente seguir cada fallo, por 10 que se debe tener en cuenta el valor del
indice de Prioridad de Riesgo. En funcion de este indice, las acciones que se
pueden asociar se puede clasificar en "Eliminar la causa dellalla", "Redllcir la
probabilidad de acurrencia", "Redllcir la gravedad del lalla", "Alilnentar la
probabilidad de deteccion".
e Responsabilidad y plazo: sirve para anotar la persona 0 area que se hara cargo
de la ejecucion de las acciones conectoras indicadas anterionnente en los
plazos previstos.
e Resultados: tras adoptar las conespondientes acciones conectoras se refleja la
fecha de aplicacion. Tras esta fecha, se sei'ialan los nuevos valores de los
indices de frecuencia, de gravedad y de deteccion y se calcula de nuevo el IPR.
El procedimiento general para desaITollar cualquier tipo de AMFE podria ser el
siguiente (Tague, 2005):
1. FOl1nar un equipo multifuncional con conocimiento amplio y diverso sobre los
productos, servicios, procesos y necesidades de los usuarios. Otras fimciones que
deberian ser capaces de desanollar son las de disefio, producci6n, calidad,
pruebas, fiabilidad, mantenimiento, compras (y suministros), ventas (y atencion al
cliente) y servicios a clientes.
2. Estil11ar el alcance y los lil11ites de aplicacion del Ai\1FE, identificando el
producto, proceso 0 servicio a estudiar, as! como los modos de fallos potenciales,
las causas y las posibles consecuencias.
3. Elaborar y rellenar toda la documentacion relativa a la evaluaci6n de PriOlidad
para cada uno de los modos de los fallos potenciales objeto del estudio: esto
implica rellenar todos los campos de la tabla 2.1. Lo que aCaITea calcular los
conespondientes indices de Gravedad, F recuencia, Deteccion e IPR.
4. En funcion de los valores de IPR, estil11arJas acciones conectoras, identificar los
responsables y estimar el plazo.
5. Ejecutar las acciones conectoras, y una vez pas ada la fecha de aplicacion, volver
a calcular los conespondientes indices para comprobar la validez de las acciones
conectoras ejecutadas.
1;;: RA-lvLA CAPiTULO 2: TECNICAS Y HERRAMIENTAS DE CAUDAD 43
7. HERRAMIENTAS DE MEDICION
7.1. COQ (coste de la caUdad)
Tambien llamado Analisis de Costes de Pobre Calidad, el COQ es un proceso
uti liz ado para identificar problemas potenciales, y cuantificar los costes en los que habria
que incurrir por no hacer las cosas bien desde el plincipio.
Para realizar un analisis COQ se recomienda seguir estos pasos:
I. Obtener 0 dibujar un diagrama de flujo detallado del proceso.
2. Identificar todas las fases y actividades del proceso y marcar aquellas que
inculTan en costes de calidad: inspecci6n, reparaci6n y control de danos.
Cuestionarse las razones de que haya tanto muchas como pocas actividades
marcadas que inClllTan en costes de cali dad.
3. Para cada actividad marcada estimar el coste que puede implicar los fallos
procedentes de una deficiente calidad y el coste que puede suponer implementar
acciones bien cOlTectoras, bien preventivas para elTadicar/evitar esos problemas.
4. Estimar la viabilidad de las acciones COlTectoras.
5. Proponer aquellas acciones COlTectoras cuya viabilidad sea posible.
7.2. Benchmarking
Tague (2005) define benchmarking como un proceso estructurado que pennite
comparar las mejores practicas de las organizaciones, de manera que se pueden incorporar
aquellas que no se desalTollan 0 mejorar las que se desalTollan a la propia organizaci6n, 0
a los procesos de la organizaci6n.
Las fases para desalTollar un benchmarking es el siguiente:
1. Planificar:
a. Definir los objetivos del estudio. Hay que elegir aquellos que sean
criticos para el exito organizacional.
b. Fonnar un equipo muldisciplinar que afronte finnemente el estudio que
se va a desalTollar.
44 CAUDAD DE SISTENLA.S lNTORlvLA.. TICOS .:g RA-ivlA
c. Estudiar los propios procesos de la organizaclOn: es preciso conocer
como nmcionan las cosas intemamente para hacer un buen trabajo en la
comparacion.
d. Identificar los profesionales de la organizacion que podrian desanollas
las mejores pnicticas.
2. Recopilar Datos:
a. Recopilar los datos directamente de los profesionales de la organizacion.
Hay que recoger tanto las descripciones de los procesos como los datos
numericos, usando cuestionarios, entrevistas telefonicas y/o visitas.
3. i\nalizar:
a. Comparar los datos recolectados, tanto los numeric os como los
descriptivos.
b. Detenninar las brechas entre las medidas de rendiIniento de los procesos
de la propia organizacion con los de las ou-as organizaciones.
c. DetenniI1ar las diferencias en las pnicticas que provo can dichas brechas.
4. Adaptar:
a. DesaITollar objetivos para los procesos de la organizacion.
b. Desanollar planes de accion para conseguir esos objetivos.
c. Implementar y monitOlizar dichos planes.
7.3. Encuestas
Estan destinadas a detenninar la naturaleza de los procesos. Existen dos
modalidades:
e Intenogacion directa: los trabajadores del conocimiento intenogan
verbalmente al encuestado y anota sus respuestas.
e Intenogacion indirecta: se prop one un cuestionario escrito.
CAPiTULO 2: TECNICAS Y HERRA1\UENTAS DE CAUDAD 45
8. NIVELES DE MADUREZ
Varios autores han sefialado que las organizaciones pueden presentar diferentes
niveles en la gesti6n de la calidad. Asi, por ejemplo, Crosby (1979) distingue los
siguientes cinco niveles:
II Incertidumbre (uncertain!)). La direcci6n no entiende la calidad, por 10 que
el personal apaga fuegos constantemente sin investigar las causas de los
problemas. No hay mejora de calidad ni medidas del coste de la calidad ni
muchas inspecciones.
II Despertar (mvakening). La direcci6n no invierte tiempo ni dinero en la
cali dad, se pone enfasis en la valoraci6n pero no en la prevenci6n.
II Iluminacion (enlightenment). La direcci6n soporta la mejora de la calidad,
existiendo un departamento de calidad que reporta a la direcci6n.
II Sabiduria (wisdom). La direcci6n comprende la importancia de la calidad y
participa en el programa de cali dad, haciendo enfasis en la prevencion de
defectos.
II Certidumbre (certainty). Toda la organizacion esta involucrada en la mejora
continua.
En el mismo sentido, Silverman (1999) distingue los niveles de: aseguramiento de
la calidad, resoluci6n de problemas, alineamiento e integraci6n, obsesi6n por el cliente y
"despertar espiritual" (spiritual mvakening); mientras que Westcott (2001) los denomina:
disfuncional, despertar, desarrollo, madurez y sistema de c1ase mundial.
lVlADli"REZ
.J ..... ' . \
DES<;,RIPClo.'\i.
... "
."
to';.,>; C'.
"".;.;:n.,: c";
No existe sistema de calidad fonnal 0 no se usa.
Auditorias
Bajo
Reclamaciones y costes de fallos son altos.
Coste de Cali dad
No hay mejora continua
Control Estadistico de Proceso
Departamento de Calidad es responsable
Costes de cali dad intemos altos, los extemos
bajos. Encuestas clientes
Medio Cada departamento acepta su papel en sistemas FMEA! Dis. Exp.
de gestion de cali dad. Benchmarking
Proyectos de mejora con empleados
Los sistemas de gestion de calidad, seguridad,
finanzas, etc. estin integrados y dirigidos por la Herramientas de gestion
Alto estrategia de la organizacion. Encuestas a empleados
Los departamentos y procesos monitorizan QFD
desempefio y meiora diaria.
Tabla 2.2. Herramientas y niveles de madurez (Oakes, 2002)
46 CAUDAD DE SISTEMAS IN"FORJvLA. TICOS RA-MA
Las helTamientas que una organizaci6n puede utilizar varianin seglin el nivel de
madurez de calidad que presente. Okes (2002) presenta la propuesta que se refleja en la
tabla 2.2.
Ademas, se puede encontrar un cierto orden de prelaci6n a la hora de utilizar las
helTamientas, por ejemplo: SPC se tiene que utilizar antes que DOE, ya que un proceso
debe estar en condici6n estable antes de estudiarlo; COQ se utiliza antes que el
benchmarking, ya que COQ utiliza datos internos, mientras que benchmarking utiliza
datos externos.
e CalTetero, A, Ingelmo, P., Sanchez-Infantes, lA, Sanchez-Infantes, P.,
Sanchez, lA, (1999). Calidad. Editorial Editex. Se trata de un muy buen libro
de introducci6n a la cali dad en general.
e Florae, W. A Y Carleton, A D. (1999). Measuring the Software Process.
Statistical Process Control for Software Process Improvement. Addison
Wesley. Es sin duda uno de los mejores libros a la hora de aplicar las tecnicas
de control estadistico del proceso al software.
e Juran, lM., Blanton, A (2001) Manual de Calidad. Ed. McGraw-Hill. EI
Manual de Cali dad es uno de los libros considerados como c1asicos desde su
plimera edici6n. Presenta muchos conceptos de calidad a 10 largo de los
cuarenta y ocho capitulos de sus dos volumenes.
e Tague, N.R. (2005) The Quality Toolbo;r Segunda Edici6n. Quality Press,
Milwaukee. Este libro es la "caja de helTamientas" de calidad propuesta por la
American Society for Quality.
e http://\v\vw.asq.onrilearn-about-qualitv/qualitv-tools.htmILa American Society
for Quality mantiene un cataIogo de Libros muy interesante sobre todas las
helTamientas de calidad que se han presentado en este capitulo.
e http://www.qfdi.org Se trata de la web del QFD Institute que reline una amplia
cantidad de material sobre QFD.
11. EJERCICIOS
l. Tome un proceso concreto de su organizaci6n y utilizando un diagrama de flujo
representelo adecuadamente.
G R.A.-MA CAPiTULO 2: TECNICAS Y HERR.Au\1IENTAS DE CA.LIDAD 47
2. Analizar, mediante un diagrama de Ishikawa, las posibles causas que producen
los fallos del disefio del software de un sistema de infonnaci6n.
3. Preparar un cuestionario que inc1uya los datos necesarios para llevar a cabo un
estudio sobre los defectos de los datos en una base de datos atendiendo a tres
variables distintas: exactitud de los datos, fiabilidad de la fuente que los
proporciona y precisi6n de los datos.
4. Realizar un estudio sobre la insatisfacci6n de los c1ientes con un producto
software, desalTollando las siguientes actividades: para la identificaci6n y analisis
de los posibles problemas usar una tonnenta de ideas; jerarquizar los posibles
problemas usando las helTamientas estudiadas que se consideren mas adecuadas;
elaborar un diagrama causa/efecto; representar los diferentes graficos de control
(como histograma, Pareto, ... ).
5. Investigue las interpretaciones estadisticas de cada uno de los tests aplicables a
los graficos X-BanaJR 0 X-BalTa/So
6. Investigue la interpretaci6n estadistica de los distintos coeficientes definidos para
el estudio de capacidad de procesos.
7. En el proceso de puesta en marcha de un sistema de infonnaci6n, indique algunas
de las cusas de variabilidad; las acciones de mejora que pennitirian disminuir la
variabilidad de un proceso, y las causas sobre las que acrua cada acci6n de
mejora.
CAPiTULO 3
MODELOS Y NORMAS DE CALIDAD
%H
EI buen gusto como nonna eqllivale a lIna amonestacion para que neguemos nuestro sincero
gusto y 10 sustituyamos por otro que no es elnuestro, pel'O que es bueno.
1. INTRODUCCION
Ortega y Gasset
Desde mediados del siglo pasado hasta la actualidad se han propuesto diferentes
modelos para la gesti6n de calidad, y se han aprobado divers as nonnas, varias de las
cuales han sido aplicadas en las organizaciones. Dentro de las diferentes propuestas
destacan la Gesti6n de la Calidad Total, el modelo EFQM y, mas recientemente Seis-
Sigma.
En este capitulo se resumira muy brevemente todas estas nonnas dedicando, como
es 16gico, mayor atenci6n a las nonnas ISO 9000 debido a su gran difusi6n.
2. GESTION DE LA CAUDAD TOT.AL
La Gesti6n de la Calidad Total (en sus siglas inglesas TQM, Total Quality
Management), representa una "actitud" 0 "filosofia" por la cual la organizaci6n pretende
ofrecer a sus clientes productos y servicios que satisfagan completamente sus necesidades.
Para ella se impregna la "cultura de calidad" en todos los aspectos de la organizaci6n, se
implementan los procesos correctamente desde el principio y se intenta erradicar los
defectos en todo tipo de tareas.
La Gesti6n de la Calidad Total concibe la organizaci6n como un con junto de
procesos que se pueden gestionar siguiendo el ciclo "Planificar-Hacer- Verificar-Actuar"
(pDCA: Plan, Do, Check, Act) que fue desarrollado iniciahnente hacia 1920 por Walter
50 CAUDAD DE SISTEtvL,,-S INl'ORl'viA TICOS ~ R A t v L
Shewhart, y popularizado luego por W. Edwards Deming, por 10 que se conoce "Cicio de
Deming":
e Planificar, establecer los objetivos y procesos necesarios para conseguir
resultados de acuerdo con los requisitos del c1iente y las politicas de la
organizaci6n.
e Hacer, implementar los procesos.
e Verificar, realizar el seguirniento y la medici6n de los procesos y los
productos respecto a las politicas, los objetivos y los requisitos para el
producto, e informat sobre los resultados.
e Actuar, tomar acciones para mejorar continuatnente el desempeiio de los
procesos.
La gesti6n de la calidad total se basa ademas en otros principios (Hyde, 1992;
Martin, 1993) que persiguen la mejora continua de los procesos, incorporando el
conocimiento y la experiencia de los trabajadores:
e Comprorniso de la alta gesti6n con todos los empleados
e Reducci6n de los ciclos de desarrollo
e Producci6n "just in time"
e Reducci6n de costes de productos y servicios
II Implicaci6n y enriquecirniento del puesto de trabajo del personal
("empOlvennent")
e Reconocirniento y celebraci6n
e Propuesta de objetivos cuantificados y benchmarking
II T oma de decisiones basadas en hechos
3. NORMAS ISO 9000
3.1. ISO Y el proceso de normalizaci6n
La International Organization for Standarization (ISO http://w\Vw.iso.com)
naci6 en 1947 con el objetivo de facilitar la coordinaci6n internacional de las normas
CAPiTULO 3: MODElOS Y NORMAS DE CAUDAD 51
tecnicas en los diferentes campos de la industria. Pueden ser miembros de ISO todos
aquellos paises del mundo que 10 deseen, representados a traves de su organismo nacional
de nonnalizaci6n (vease la figura 3.1): pOl' ejemplo, ANSI (American National Standards
Institute) por EEUU 0 AENOR (Asociaci6n Espanola de Nonnalizaci6n y Certificaci6n)
por Espana.
EEUU ANSI
FRANCIA AFNOR
ESPANA
GRAN BRETANA
JTCI
SC27
Figura 3.1. Estructura de ISO
Los trabajos de elaboraci6n de nonnas estan encomendados a los Comites Tecnicos
(TC), que sue len subdividirse en Sub comites (SC) y estos, a su vez, en Orupos de Trabajo
(WO) para desarrollar temas especificos.
En algunas areas, ISO colabora con otras organizaciones; por ejemplo, en el campo
de las tecnologias de la infonnaci6n fonna junto con la International Electrotechnical
Commission (lEC) el Joint Technical Committee I UTC1), que se encuentra dividido en
varios subcomites, entre ellos el SC7 de Ingenieria del Software y Sistemas, que posee
diferentes gmpos de trabajo (v ease tabla 3.1).
52 CAUDAD DE SISTEl'v1AS INt'ORM . .A. TICOS RA-l'vL-\
. .. '.
I: ..
....
>
....
;

.>?G . .. .....

t TR.:\:BAJol,
I
..
y>
'-.-.. , .. ..",I
x
. \ ...... . .... " .
..
2 Documentaci6n de sistemas software
4
I
Herramientas y entomos CASE
6
Evaluaci6n de productos software y metricas para productos y procesos
software
7 Gesti6n del Ciclo de Vida
9
Aseguramiento de sistemas y software (gesti6n de riesgos, seguridad de
acceso, seguridad de uso, ... )
Metodos, pnicticas y aplicaci6n de evaluaci6n de procesos en la
10 adquisici6n, desarrollo, entrega, operaci6n, evoluci6n del producto
software y servicio relacionado
12 Medici6n del tamafio funcional
19
Lenguajes de modelado, metadatos y marco ODP, colaboraci6n con
OMG, ITU-T y otras organizaciones (como IEEE)
20 SWEBOK (Cuerpo de Conocimiento de la Ingenieria del Software)
21
I
Proceso de gesti6n de activos software
22
I
Vocabulario consolidado de Ingenieria de Sistemas y de Software
?'
-.)
I
Gesti6n de Calidad de Sistemas
24 Ciclos de vida del software para pequefias empresas
Tabla 3.1. Grupos de trabajo del SC7
El proceso de elaboracion de una nonna intemacional, hasta su publicacion
definitiva, puede ser bastante largo, ya que empieza con la decision del TC de incluir la
elaboracion de una nueva nonna en su programa de trabajo. A continuacion el WG
elabora diferentes Bon'adores de Trabajo (WD, Worldng Draft) hasta a1canzar el
suficiente consenso para elevar el docmnento a la consideracion del TC. Posterionnente,
el comite remite un Bon'adm' de Comite (CD, Committee Draft) a todos los paises
miembros para recabar sus comentarios, Una vez analizados los comentalios recibidos, se
elabora un Proyecto de NOl7na Intel71acional (DIS, Draft of Intel71ational Standard) que
se remite nuevamente a los paises miembros, Si los paises aprueban el DIS, se prepara un
Proyecto de Nonna Intemacional Final (FDIS, Final Draft of International Standard),
que se remite para aprobacion defmitiva. Por ultimo, se edita y publica la Nonna
Internacional (IS, International Standard) aprobada en la fuse anterior.
Todo este proceso hace que la nonna pueda contar con el suficiente consenso por
parte de los paises, pero a costa de alargar demasiado el tiempo necesario para aprobar
una nonna, sobre to do en areas como las TIC que evolucionan con mucha rapidez.
En Espana las nonnas intemacionales son traducidas y publicadas por AENOR
como nonnas UNE (Una Nonna Espai"1ola). A nivel europeo, otros organismos como el
1 EI nfunero y distribuci6n tanto de los subcomites como de los grupos de trabajos dentro de un
subcomite suele ir variando segtin los temas que se van abordando, por 10 que rernitimos al lector a
http://www.jtc1-sc7.onr/ para una informaci6n actualizada sobre los rnismos.
R.A.LA. CAPiTULO 3: J>.<1ODELOS Y NOR.t'vLA.S DE CAUDAD 53
CEN/CENELEC (Comite Europeo de Nonnalizaci6n) publican las nonnas
internacionales como nonnas EN (European Nann).
3.2. Normas sobre calidad
La primera publicaci6n de las nonnas ISO 9000 se realiz6 en 1987 y cumpliendo el
proto colo de ISO, que obliga a que todas las nonnas sean revisadas pOl' los menos cada
cinco afios, fueron revisadas en 1994 y por ultima vez en el afio 2000.
Actualmente, la familia de nonnas ISO 9000 esta compuesta de cuatro nonnas:
(i) U1\TE-EN ISO 9000. Sistemas de gestion de la calidad. Fundamentos y
vocabulario. Como su titulo indica, esta nonna describe los fundamentos de
los sistemas de gesti6n de la calidad y especifica su tenninologia (vease
capitulo 1).
(i) UNE-EN ISO 9001. Sistemas de gestion de la calidad. Requisitos. La nonna
ISO 9001 especifica los requisitos para un sistema de gesti6n de la cali dad que
pueden utilizarse para su aplicaci6n interna pOI' las organizaciones, para
certificaci6n 0 con fines contractuales. Se centra en la eficacia del sistema de
gesti6n de la calidad para dar cumplimiento a los requisitos del cliente.
(i) UNE-EN ISO 9004. Sistemas de gestion de la calidad. Directrices para la
mejora del desempefio. La nonna ISO 9004 proporciona orientaci6n sobre un
rango mas amplio de objetivos de un sistema de gesti6n de la calidad que la
Nonna ISO 9001, especialmente para la mejora continua del desempefio y de
la eficiencia glob ales de la organizaci6n, asi como de su eficacia. La nOlma
ISO 9004 se recomienda como una guia para aqueUas organizaciones cuya alta
direcci6n desee ir mas alla de los requisitos de la nonna ISO 9001,
persiguiendo la mejora continua del desempefio. Sin embargo, no tiene la
intenci6n de que sea utilizada con fines contractuales 0 de certificaci6n. En la
figura 3.2 se representa las diferencias entre ambas nonnas segll11 Cianfrani et
al. (2002), siguiendo una "jerarqztia de fa calidad'.
(i) l:.JNE-EN ISO 19011. Directrices para la auditoria de sistemas de gestion de
la calidad y/o medioambiental. Esta nonna proporciona directrices basicas
para la realizaci6n de una auditoria conjunta de ISO 9001 e ISO 14001.
Ademas, existen otras nonnas relacionadas con 1a familia de las nonnas ISO 9000.
que se reflejan en la tabla 3.2.
54 CAlIDAD DE SISTEMAS L'lFORc\1A TICOS RA-MA
9004
Excelencia en
eI desempeiio
MINThlIZAR usn
DERECURSOS
Ventaja competitiva
Eficiencia
Eficacia
Figura 3.2. Jerarquia de la calidad segun Cianfrani et al. (2002)
NOR'l-l.A.DE C-\LIDAD I .....
OBJETIVO
..
ISO 10002 Gestion de la calidad - Satisfacci6n del cliente - Directrices para gestionar
reclamaciones en las organizaciones
ISO 10005 Sistemas de Gestion de la Calidad - Directrices para Planes de la Calidad
ISO 10006 Sistemas de Gestion de la Calidad - Directrices para la Calidad en la
Gesti6n de Proyectos
ISO 10007 Sistemas de Gestion de la Calidad - Directrices para la Gesti6n de la
Configuracion
ISO 10012 I de Gesti6n de la Medici6n - Requisitos para los procesos y
eqllipamientos de medicion
ISO!TR 10013 Directrices para la Docllmentacion del Sistema de Gestion de la Calidad
ISO:TR 10014 Directrices para la Gestion de la Economia de la Cali dad
ISO 10015 Gesti6n de la Calidad - Directrices para la Fonnaci6n
ISO!TR 1001 7 Directrices sobre Tecnicas Estadisticas para la nonna ISO 900 I
ISO 10019 Directrices para la seleccion de consultores de sistemas de gesti6n de la
calidad y la utilizacion de sus servicios
Tabla 3.2. Otras normas relacionadas con la calidad
La familia de normas ISO 9000 se bas a en ocho plincipios de gesti6n de la cali dad
que pueden ser utilizados por la direcci6n con el fin de conducir a la organizaci6n hacia
una mejora en el desempeiio (ISO, 2000a):
12 RA-IvlA CAPiTULO 3: ?\10DELOS Y NOR.Jv!AS DE CAUDAD 55
@ Enfoque al cliente: las organizaciones dependen de sus clientes y por 10 tanto
deberian comprender las necesidades actuales y futuras de los c1ientes,
satisfacer los requisitos de los mismos y esforzarse en exceder sus expectativas.
@ Liderazgo: los lideres establecen la unidad de prop6sito y la 01ientaci6n de la
organizaci6n. Deberian crear y mantener un ambiente inte111o, en el cual el
personal pueda llegar a involucrarse totalmente en el logro de los objetivos de
la organizaci6n.
@ Participacion del personal: el personal, a todos los niveles, es la esencia de
una organizaci6n y su total compromiso posibilita que sus habilidades sean
usadas para el beneficio de la organizaci6n.
@ Enfoque basado en procesos: esta familia de n01111as promueve la adopci6n
de un enfoque basado en procesos cuando se desalTolla, implementa y mejora
un sistema de gesti6n de la calidad. El modelo de sistema de gesti6n de la
calidad basado en procesos, que se muestra en la figura 3.3, ilustra que los
c1ientes juegan un papel significativo para definir los requisitos como
elementos de entrada. El seguimiento de la satisfacci6ndel c1iente requiere la
evaluaci6n de la infOlmaci6n relativa a la percepci6n del cliente acerca de si la
organizaci6n ha cumplido sus requisitos. Una ventaja del enfoque bas ado en
procesos es el control continuo que proporciona sobre los vinculos entre los
procesos individuales dentro del sistema de procesos, asi como sobre su
combinaci6n e interacci6n.
@ Enfoque de sistema para la gestion: identificar, entender y gestionar los
procesos intelTelacionados como un sistema, contribuye a la eficacia y
eficiencia de una organizaci6n en ellogro de sus objetivos.
@ Mejora continua: la mejora continua del desempei'io global de la organizaci6n
deberia ser un objetivo pennanente de esta.
@ Enfoque bas ado en hechos para la torrta de decision: las decisiones eficaces
se basan en el analisis de los datos y la infOlmaci6n.
@ Relaciones mutuamente beneficiosas con el proveedor: una organizaci6n y
sus proveedores son interdependientes, y una relaci6n l11utuamente beneficiosa
aumenta la capacidad de ambos para crear valor.
56 CALIDAJ) DE SISTE:tvL,,-S IN"FORJvfA.TICOS RA-:tvL,,-
MEJORA CONTINUA DEL SISTEMA
DE GESTION DE LA CAUDAD
C informacion
+----
RESPONSABILlD,AD b ..
DE LA DIRECCION 'u
C
L
L
E
N
T
E
S
requisitos
GESTION DE
RECURSOS
MEDICION. ANALISIS
Y MEJORA
r--R-E-AL-IZA--C-I-O-N-'
DELPRODUCTO
info E
--
N
T
E
S
Figura 3.3. Enfoque de procesos segun la norma ISO 9000 (ISO, 2000a)
3.3. Norma ISO 9001
Esta norma intel11acional (ISO, 2000b) especifica los requisitos para un sistema
de gesti6n de la cali dad, cuando una organizaci6n:
e Necesita demostrar su capacidad para proporClOnar de fonna coherente
productos que satisfagan los requisitos del cliente y los reglamentarios
aplicables,
e Aspira a aumentar la satisfacci6n del cliente a traves de la aplicaci6n eficaz del
sistema, incluidos los procesos para la mejora continua del sistema y el
aseguramiento de la confonnidad con los requisitos del cliente y los
reglamentatios aplicables.
Todos los requisitos de esta nonna intel11acional son generic os y se pretende que
sean aplicables a todas las organizaciones sin importar su tipo, tamafio y producto
suminish'ado,
En la figura 3.4 se muestra el contenido de la n01111a ISO 9001(ISO, 2000b), cuyo
nllcleo 10 constituyen los apartados del 4 al 8 inclusive,
PORTADA
ANTECEDENTES
DECLARACION
PROLOGO
CAPiTULO 3: MODELOS Y NORMAS DE CALIDAD 57
PROLOGO DE LA VERSION EN ESPANOL
o INTRODUCCION
1 OBJETO Y CAMPO DE APLICACION
2 NORMAS PARA CONSULTA
3 TERMINOS Y DEFINICIONES
4 SISTEMA DE GESTION DE LA CALI DAD
5 RESPONSABILIDAD DE LA DIRECCION
6 GESTION DE LOS RECURSOS
7 REALIZACION DEL PRODUCTO
8 MEDICION, ANALISIS Y MEJORA
ANEXO A (Informativo) CORRESPONDENCIA ENTRE LAS NORMAS
ISO 9001:2000 E ISO 14001:1996
ANEXO B (Informativo) CORRESPONDENCIA ENTRE LAS NORMAS
ISO 9001:2000 E ISO 9001:1994
BIBLIOGRAFiA
ANEXO ZA (Normativo) REFERENCIAS NORMATIVAS A
PUBLICACIONES INTERNACIONALES CON SUS
CORRESPONDIENTES PUBLICACIONES EUROPEAS
Figura 3.4. Contenido de la norma ISO 9001 (ISO, 2000b)
58 CAUDAD DE SISTENV\S INFOR.,\LA. TICOS RA-NL-\
3.3.1. SISTEMA DE GESTION DE LA CALIDAD
En cuanto al sistema de gesti6n de la calidad (apartado 4), la n0l111a sefiala que: "La
organizacion debe:
a) identificar los procesos necesarios para el sistema de gestion de la calidady
Sll aplicacion a trm'es de la organizacion,
b) determinar la secuencia e interaccion de estos procesos,
c) determinar los criterios y metodos necesarios para asegllrarse de qlle tanto
la operacion como el control de estos procesos sean ejicaces,
d) asegllrarse de la disponibilidad de recursos e informacion necesarios para
apoyar la operacion y el seguimiento de estos procesos,
e) realizar el seguimiento, la medicion y el amilisis de estos procesos, e
f) implementar las acciones necesarias para alcanzar los resliltados planifica-
dos y la mejora continua de estos procesos. "
Ademas hata sobre los requisitos de la documentaci6n, inuicando que: "La
doclimentacion del sistema de gestion de la calidad debe incluir:
a) declaraciones documentadas de IIna politica de la calidad y de objetivos de
la calidad,
b) un manllal de la calidad,
c) los procedimientos documentados reqlleridos en esta norma internacional,
d) los docllmentos necesitados por la Olganizacion para asegurarse de la ejicaz
planificacion, operacion y control de sus procesos, y
e) los registros reqlleridos por esta norma internacional. "
3.3.2. RESPONSABILIDAD DE LA DIRECCION
En cuanto a la responsabilidad de la direcci6n (apartado 5), la norma trata varios
aspectos relativos a: Compromiso de la direcci6n, Enfoque al c1iente, Politica de la
calidad, Planificaci6n, Responsabilidad, Autoridad y Comunicaci6n, y Revisi6n par la
direcci6n.
3.3.3. GESTION DE LOS RECURSOS
El apartado 6, de gesti6n de los recursos, sefiala como: "La Olganizacion debe
determinar y proporcionar los reClfrsos necesarios para:
a) implementar y mantener ef sistema de gestion de fa calidad y mejorar
continuamente su ejicacia, y
b) allmentar la satisfaccion del cliente mediante el cumplimiento de SliS
reqllisitos. "
.\': R/\.-ivL"- CAPiTULO 3: MODELOS Y NORt\L,,-S DE CAUDAD 59
Tratandose diferentes aspectos relativos a los recursos humanos, infraestructura
(edificios, espacio de trabajo y servicios asociados; equipo para los procesos, y servicios
de apoyo, tales como transporte y comunicaci6n) y ambiente de trabajo,
3.3.4. REALIZACION DEL PRODUCTO
En el apartado 7 de la nonna ISO 9001 se tratan diversos aspectos relacionados con
la realizaci6n del producto:
3.3.4.1. Planificacion de la realizacion del producto
La nonna especifica que "La organizaci6n debe planificar y desarrollar los
procesos necesarios para la realizacion del producto, La planificpcion de la realizaci6n
del producto debe ser coherente con los requisitos de los oo'os procesos del sistema de
gesti6n de la calidad -y que- Durante la planificaci6n de la realizacion del producto, la
organizacion debe determinar, cuando sea apropiado, 10 siguiente:
a) los objetivos de la calidady los requisitos para el producto;
b) la necesidad de establecer procesos, doclimentos y de proporcionar recursos
especifzcos para el producto;
c) las actividades requeridas de ver[fzcaci6n, validaci6n, seguimiento, inspecci6n
y ensayo/prueba especifzcas para el producto asi como los criterios para la
aceptacion del mismo;
d) los regiso'os que sean necesarios para proporcionar evidencia de que los
procesos de realizaci6n y el producto resliltante cumplen los requisitos ",
La nom1a sefiala ademas que la elaboraci6n de planes de calidad puede servir para
definir la manera en que los requisitos del sistema de gesti6n de la cali dad cumpliran un
contrato especifico 0 con cada producto,
3.3.4.2. Procesos relacionados con el cliente
En cuanto a los procesos relacionados con el cliente la nonna sefiala que: "La
organizacion debe determinar:
a) los requisitos especificados por el cliente, los requisitos para las
actividades de eno'ega y las posteriores a la misma,
b) los requisitos no establecidos por el cliente pero necesarios para el lIS0
especificado 0 para elliso previsto, ClIando sea conocido,
c) los requisitos legales y reglamentarios relacionados con el producto, y
d) clIalqllier requisito adicional determinado porIa organizaci6n",
Ademas, la organizaci6n debe revisar los requisitos relacionados con el producto, y
detenninar e implementar disposiciones eficaces para la comunicaci6n con los clientes,
60 CALIDAD DE SISTEivIAS INFOfu'vLA. TICOS RA-ivIA
3.3.4.3. Disefio y desarrollo
La nonna tambien aborda el disefio y desarrollo, entendidos como "el con junto de
procesos que transforma los requisitos en caracteristicas especijicadas 0 en la
espec[ficacion de un prodlictO, proceso 0 sistema". La nonna sefiala que: debe
planificarse y controlarse el disefio y desarrollo del producto; deben deterrninarse los
elementos de entrada relacionados con los requisitos del producto y mantenerse registros;
deben proporcionarse los resultados del disefio y desarrollo de tal manera que perrnitan la
verificaci6n respecto a los elementos de entrada, y que deben aprobarse antes de su
liberaci6n; deben realizarse revisiones sistematicas del disefio y desarrollo, la verificaci6n
y la validaci6n de acuerdo con 10 planificado, manteniendo los registros correspondientes.
Tambien deben identificarse y mantenerse registros de los cambios del disefio y
desarrollo.
3.3.4.4. Compras
En cuanto al proceso de compras la nonna establece que: "La organizacion debe
asegurarse de que el prodllcto adqllirido eumple los requisitos de compra especijicados.
EI tipo y alcance del control aplicado al proveedor y al producto adquirido debe
de pender del impacto del produeto adquirido en la posterior realizacion del producto 0
sobre el producto final n.
Ademas, la nonna establece que "la organizacion debe eva/uar y seleccionar los
proveedores en fill1cion de su capacidad para suministrar productos de aeuerdo con los
requisitos de la organizacion" y que "la organizacion debe establecer e implementar la
inspeccion u on'as actividades necesarias para asegurarse de que ef producto comp'ado
cumple los requisitos de compra especijicados n.
3.3.4.5. Produccion y prestacion del servicio
En este epigrafe se aborda el control de la producci6n y de la prestaci6n del
servicio, la validaci6n de los procesos de la prodJ.lcci6n y de la prestacion del servicio, la
identificaci6n y trazabilidad, la propiedad del c1iente ("fa organizacion debe euidar fos
bienes que son propiedad del cliente miennm esten bajo el conn'of de fa organizacion 0
esten siendo lItilizados por fa misma"), asi como la preservaci6n del producto (que debe
inc1uir la identificaci6n, manipulacion, embalaje, almacenamiento y protecci6n).
3.3.4.6. Control de los dispositivos de seguimiento y de medicion
A este respecto la nonna sefiala que: "La organizacion debe detenninar ef
seguimiento y la medicion a realizar, y los dispositivos de medicion y seguimiento
necesarios para proporcionar la evidencia de fa confonnidad del producto con los
reqllisitos detenninados n.
0RA.-MA CAPiTULO 3: MODELOS Y NOR.!\1AS DE CAUDAD 61
3.3.5. MEDICION, ANA.LISIS Y MEJORA
En el apartado 8 la norma ISO 9000 establece que: "La orgallizacion debe
planifzear e implementar los proeesos de seguimiento, medicion, amilisis y mejora
necesarios para
a) demostrar la eonformidad del producto,
b) asegllrarse de la conformidad del sistema de gestion de la caUdad,
e) mejorar continuamente la ejieacia del sistema de gestion de la caUdad.
Esto debe comprender la detemlinacion de los metodos aplicables, incluyendo las
teenieas estadisticas, y el alcance de Sll utilizacion n.
En la nonna se establece que deberia realizarse un seguimiento y medici6n de la
satisfacci6n del c1iente. Seglin Saunders et al. (2002), las diversas fuentes de infonnaci6n
sobre la satisfacci6n del c1iente se pueden clasificar en:
e Activas. Si la organizaci6n va al c1iente y Ie pregunta cuestiones deliberadas 0
hace observaciones directas del comportamiento del c1iente. Se pueden
c1asificar en: Encuestas, Gmpos de discusi6n con participaci6n de c1ientes
("customerfoells group "), y Entrevistas personales.
e Pasivas, que se pueden c1asificar en:
e Receptivas, en las que el c1iente acude a la organizaci6n con
devoluciones 0 quejas. Se pueden dividir en: Quejas, Devoluciones,
Puntuaciones del proveedor.
e Indirectas, en las que se utilizan fuentes secundarias y que pueden ser:
Infonnes del cliente, Amilisis competitivo, Medios de noticias.
La nOl1na establece que: "la organizacion debe Ilemr a cabo a illtermlos
plantfieados allditorias intemas para determinar si tl sistema de gestion de la caUdad:
a) es C01?/orme eon las disposiciones planificadas (vease 7.1), eon los requisitos
de esta nonna illtenzacional y con los reqllisitos del sistema de gestion de la
calidad establecidos por la organizacion,
b) se ha il71plementado y se mantiene de manera ejicaz n.
Tambien u'ata sobre el seguimiento y medici6n de los procesos (a los que la
organizaci6n debe aplicar metodos que demuesu'en su capacidad para alcanzar los
resultados planificados) y del producto. As! como del conu'ol del producto no confol1ne
(que debe estar definido en un procedimiento documentado), del analisis de datos (que
deben ser "apropiados para demostrar la idoneidady la eficacia del sistema de gestioll de
62 CAUDAD DE SISTEivlA.S INFORMATICOS RA-ivlA.
la calidad y para evaluar donde puede realizarse la mejora continua de la eficacia del
sistema de gestion de la calidad".
POI' ultimo en la nOl1l1a se aborda la mejora, tanto la mejora continua, como las
acciones cOlTectivas y preventivas. En estos temas se profundizan en la nonna ISO 9004,
que propugna un enfoque de auto-evaluacion para evaluar la madurez del sistema de
gestion de la calidad para cada apartado de la nonna en una escala que flucrua de 1 (sin un
sistema fOl1l1al) hasta 5 (la mejor clase de desempefio), vease la tabla 3.3.
4. MODELO EFQM
4.1. Vision general
El modelo EFQM, que fue creado como marco para evaluar las organizaciones con
el fin de conceder el European Quality A.-ward, se puede utilizar como:
I> hel1'amienta para autoevaluacion,
I> fonna de comparacion (benchmark) con otras organizaciones,
I> guia para identificar las areas de mejora,
I> base para un vocabulario comun y una manera de pens aI',
I> estmctura para sistemas de gestion de la organizacion.
Este modelo se basa en nueve criterios, cinco "agentes facilitadores" -que abarcan
10 que hace una organizacion-, y cuatro "resultados" -que se ocupan de los que la
organizacion consigue- (vease figura 3.5). Segim el modelo EFQM "los resultados
excelentes respecto al desempeiio, clientes, personas y sociedad, se cOl1siguen mediante el
liderazgo que guia la politica y estrategia, que ~ !leva a cabo por medio de personas,
alian:::as), recursos, y procesos ".
El modelo EFQM se basa en una serie de principios:
I> Orientacion a los resultados
I> Orientaci6n al c1iente
I> Liderazgo y coherencia en los objetivos
I> Gestion pOI' procesos y hechos
~ RA-lvLA. CAPiTULO 3: ",mDELOS Y NORl\LA.S DE CAUDAD 63
e DesarTollo e implicacion de las personas
e Aprendizaje, innovacion y mejora continuos
e DesarTollo de alianzas
e Responsabilidad social
Personas
Resultados en
" uj
(9%)
" v V ~ V v) las Personas
Resultados
liderazgo
y
Procesos
en
Clave de
(10%)
Estragegia
(10%)
los Clientes
Desempeiio
(8%)
(10%)
Alianza y en
Recursos la Sociedad
(9%) (6%)
Figura 3.5. IVlodelo EFQM
En el ano 2003 se complemento este modelo con un conjunto de mar'cos
(frame'l'Orks) con el fin de atender las necesidades de las orgallizaciones de concentrar sus
mejoras en segmentos especificos de su sistema de calidad: Responsabilidad Social
Corporativa, Gestion de Riesgos, Innovacion, Gestioll del Conocimiento y Gestion de
Recursos Humanos.
4.2. Criterios del modelo
A continuacion se resumen los principales criterios, con sus respectivos
subcriterios, del modelo EFQM.
4.2.1. LIDERAZGO
Los subcriterios para los lideres excelentes se basan en que estos:
e DesalTollan la mision, vision, valores y principios eticos y acruan como modelo
de referencia de una cultura de excelencia,
e Se implican personalmente para garantizar el desalTollo, implantacion y mejora
continua del sistema de gestion de la organizacion,
64 CAUDAD DE SISTEl>.1AS j]\,TfORIvLA. TIeos RA-MA
Interacruan con clientes, proveedores y representantes de la sociedad,
Refuerzan una cultura de excelencia entre el personal de la organizaci6n,
Definen e impulsan el cambio en la organizaci6n.
<
, NivldeJ)eSempeiio "', "
",', "
Orientacion\.

"
1 Sin aproximaci6n fonnal No hay una aproximaci6n sistematica evidente;
sin resultados, resultados pobres 0 resultados
impredecibles
2 Aproximaci6n reactiva Aproximaci6n sistematica basada en el
problema 0 la prevenci6n; minimos datos
disponibles sobre el resultado de la mejora.
3 Aproximaci6n del sistema Aproximaci6n sistematica basada en el proceso,
fonnal estable etapa temprana de mejoras sistematicas; datos
disponibles sobre la confonnidad con los
objetivos y existencia de tendencias de mejora
4 Enfasis en la mejora continua Proceso de mejora en uso; buenos resultados y
tendencia mantenida de mejora.
5 Desempeno de "meja/' ell Sli Proceso de mejora ampliamente integrado;
clase" Resultados demostrados de "mejor en su c\ase"
por medio de estudios comparativos
(benclllllOrkim;)
Tabla 3.3. Niveles de Madurez del Sistema de Gestion de la calidad
4.2.2. POLiTICA Y ESTRATEGIA
Los subcritelios de este criterio son:
La politica y estrategia se basan en las necesidades y expectativas achmles y
ftlhlras de los grupos de interes.
La politica y estrategia se basan en la infonnaci6n de los il1dicadores de
desempefio, la investigaci6n, el aprendi:z;aje y las actividades extemas.
o La politica y estrategia se desarrollan, revisan y achlalizan.
La politic a y estrategia se comunica y despliega mediante un esquema de procesos
clave.
4.2.3. PERSONAS
En este cliterio se evallmn:
o Planificaci6n, gesti6n y mejora de los recursos humanos.
idRA-MA. CAPiTULO 3: MODELOS Y NORIvLA.S DE CAUDAD 65
Identificacion, desanollo y mantenimiento del conocimiento y la capacidad de
las personas de la organizacion.
Implicacion y asuncion de responsabilidades por parte de las personas de la
organizacion.
Existencia de un dialogo entre las personas y la organizacion.
Recompensa, reconocimiento y atencion a las personas de la organizacion.
4.2.4. ALIANZAS Y RECURSOS
Respecto a este criterio hay que tener en cuenta que las organizaciones excelentes
planifican y gestionan las alianzas extemas, sus proveedores y recursos intemos en apoyo
de su politic a y estrategia y del eficaz ftmcionamiento de sus procesos, pOl' 10 que se
detenrunan en el modelo los siguientes subcriterios:
Gestion de las alianzas extemas.
Gestion de los recursos economicos y financieros.
Gestion de los edificios, equipos y materiales.
Gestion de la tecnologia.
Gestion de la infonnacion y del conocimiento.
4.2.5. PROCESOS
En cuanto a los procesos se evalua:
Disefio y gestion sistematica de los mismos.
Introduccion de mejoras mediante innovacion.
Disefio y desanollo de productos y servicios basandose en las necesidades y
expectativas de los c1ientes.
Produccion, distribucion y servicio de atencion, de los productos y servicios.
Gestion y mejora de las relaciones con los c1ientes.
66 CAUDAD DE SISTEMAS INFOIUvL-\ TICOS @RA-MA
4.2.6. CLIENTES
Las organizaciones excelentes miden de manera exhaustiva y a1cat1Zan resultados
sobresalientes con respecto a sus clientes, por 10 que el modelo establece dos subcriterios
basados en medidas de percepci6n y en indicadores de rendimiento
4.2.7. RESULTADOS EN LAS PERSONAS
Las organizaciones excelentes tambien rniden de manera exhaustiva y a1canzan
resultados sobresalientes con respecto a las personas que las integran, por los que se
definen los mismos dos tipos de subcriterios que para los clientes.
4.2.8. RESULTADOS EN LA SOCIEDAD
De fonna amlloga a la anterior se evaluan los resultados en la sociedad.
4.2.9. RESULTADOS CLAVE DE DESEMPENO
Las Organizaciones Excelentes miden de manera exhaustiva y a1canzan resultados
sobresalientes con respecto a los elementos clave de su politica y estrategia, para 10 que se
tiene en cuenta tanto los resultados clave del desempefi.o de la organizaci6n como los
indicadores clave del desempefi.o de la organizaci6n.
5. CAF: MARCO COMON DE EVALUACION
Los ministerios responsables de Administraci6n Pliblica de la Uni6n Em'opea han
elaborado el Marco COmlll1 de Evaluaci6n (CAF, Common Assessment Frall1eH'ork)
tomando como base el modelo EFQM.
Como se senala en MAP (2003), el CAF tiene cuatro prop6sitos principales:
I. Identificar las caracteristicas comunes de las organizaciones del sector pllblico .
.
2. Servir como helTamienta para los administradores Pllblicos que de seen mejorar el
rendimiento de su organizaci6n.
3. Hacer de "puente" entre los diferentes modelos que se usan en la gesti6n de
calidad.
4. Facilitar el benclunarking entre las organizaciones del sector publico.
EI CAF se considera un modelo "ligero", adecuado para obtener una primera valora-
ci6n de c6mo acrua una organizaci6n. Se podria considerar un primer paso para avanzar
en la gesti6n de la calidad, que podria ser complementado facilmente con modelos mas
amplios como el EFQM, con el que es compatible.
i': Ri\-ivV\ CAPiTULO 3: MODELOS Y NORMAS DE CAUDAD 67
6. S E I S ~ S I G M
Seis-Sigma (Six-Sigma) tiene su origen en la estadistica, ya que sigma, como es
sabido, es el simbolo de la desviaci6n estandar. Un proceso que esta en nivel de seis
sigmas produce s610 3,4 defectos por cada mill6n. Se puede considerar como una filosofia
de gesti6n que agrupa varias tecnicas con el fin de conseguir procesos casi perfectos.
Seglll1 Tayntor (2003) se basa en los siguientes presupuestos:
Prevenir defectos
Reducir la vmiaci6n
Centrarse en el cliente
Tomar decisiones basadas en hechos
Alentar el trabajo en gmpo
EI proceso seis sigma se descompone en cinco fases, que responden al acr6nimo
DMAIC y que constan de varios pasos (Tayntor, 2003):
Definir el problema e identificar 10 que es importante: consiste en definir el
problema, fonnar un equipo, establecer un esquema del proyecto, desalTollar el
plan del proyecto, identificar los clientes, identificar las salidas clave,
identificar y priOlizar los requisitos de los clientes, y documentar el proceso
actual.
Medir el proceso actual, que incluye: detenninar que medir, llevar a cabo las
mediciones, calcular el nivel sigma actual, detenninar la capacidad del proceso,
y llevar a cabo comparaciones (benchmark) con Hderes del proceso.
Analizar 10 que esta mal y las soluciones potenciales, detenninando las causas
de la variaci6n, realizando una tonnenta de ideas para la mejora de procesos,
detenninando que mejoras tendrian el mayor impacto para satisfacer los
requisitos del cliente, desalTollando un mapa de procesos y evaluando los
riesgos asociados al proceso revisado.
Mejorar el proceso implantando las soluciones, 10 que lleva consigo: obtener
la aprobaci6n para los cambios propuestos, finalizar el plan de implementaci6n,
e implementar los cambios aprobados.
Controlar el proceso mejorado asegurando que los cambios se mantienen,
mediante el establecimiento de metricas clave, el desalTollo de la estrategia de
68 CAUDAD DE SISTEMAS INFO MiA. TICOS RA-MA
control, la celebracion y comunicacion de los exitos, la implementacion del
plan de control, y la medici on y comunicacion de las mejoras.
El objetivo de una organizacion que adopta esta filosofia es continuar la mejora
de sus procesos solo si los resultados son irnportantes para satisfacer los requisitos de
los clientes.
7. PREMIOS
Existen multitud de prellllos relacionados con la cali dad, a continuacion
presentamos los mas irnportantes:
II Premio Deming: se creo en 1951 a raiz de las conferencias de Deming en
Japon, es gestionado por la ruSE (Japanese Union 0/ Scientists and
Engineers) y se considera el premio indushial mas importante de Japon.
II Malcom Baldrige National Quality Award, se creo en 1987, tras el
fallecimiento del secretario de comercio del mismo nombre, con el fin de
premiar a las empresas que demostrasen un gran progreso en el area de la
calidad. Los Malcom Baldrige Criteria/or Peljonnance Excellence defmen un
conjunto de practicas de gestion de alto desempeiio en las categorias siguientes
(vease figura 3.6): Liderazgo, Planificacion Estrategica, Enfoque al Cliente y
Mercado, Medicion, Analisis y Gestion del Conocimiento, Enfoque a los
Recursos Humanos, Gestion de Procesos y Resultados de la empresa. Estos
criterios se basan en una serie de conceptos y valores fundamentales como son:
elliderazgo visionario, la excelencia dirigida al cliente, el aprendizaje personal
y organizacional, la valoracion de los empleados y los socios, la agilidad, la
gestion para la irmovacion, el centrarse en el futuro, la gestion basada en
hechos, 1a responsabilidad social, el centrarse en resultados y la creacion de
valor, y una perspectiva sistemica (Baldrige, 2005).
II European Quality Award, se creo eJl 1991 pOI' la European FOWldation for
Quality Management (EFQM), en colaboracion con la Comision Europea y la
European Organization for Quality. El premio se basa en el modelo EFQM, y
se da a la organizacion que demuesh-a que su aproximacion a la gestion de
cali dad total ha hecho una irnpOltante conhibucion a la satisfaccion de las
expectativas de los clientes, empleados, accionistas, y otras partes
involucradas.
II Premio Iberoamericano de la Calidad, es W10 de los Programas de
Cooperacion de la Cwnbre Iberoamericana de Jefes de Estado y de Gobiemo y
10 gestiona la Fundacion Iberoamericana de la Calidad - FUNDIBEQ. Se
otorga a las organizaciones que han destacado por sus resultados exitosos, f!Uto
CAPITULO 3: MODELOS Y NORJ"L\S DE CAUDAD 69
de una excelente calidad de su gesti6n, de acuerdo al Modelo Iberoamericano
de Excelencia en la Gesti6n.
PerfilOrganizacional: Entorno. RelacionesyRetos """
2. Planlficacion
5.
-( Estrategica
Recursos
Humanos
. i .. /

4.Matiidas.Analls;s y GBStl6.n
. .
7. Resultados de "
:<f Negocios
"'-.:.. ;/
Figura 3.6. Criterios para la Excelencia en el desempefio (Baldrige, 2005)
tl) Premios de la ASQ. Entre los que cabe destacar: Brumbaugh Award (al
articulo publicado el ano anterior que ha hecho la contribuci6n mas importante
al desarrollo de aplicaci6n industrial de control de calidad), Edwards Medal (a
la persona que demuestre el liderazgo mas destacado en la aplicaci6n de
metodos de control de cali dad modema); Deming Medal (a la persona que ha
combinado con exito la aplicaci6n del pensamiento estadistico y la gesti6n para
conseguir la calidad de productos y servicios); Feigenbaum Award (a la
persona que muestre "caracteristicas sobresalientes de liderazgo,
profesionalidad, y potencial en el campo de la calidad"); Eugene L. Grant
Award (a la persona que haya demostrado un liderazgo destacado en el
desarrollo y presentaci6n de un programa educacional en control de calidad);
Ishikmva Medal (a la persona 0 equipo que haya mostrado un liderazgo en la
mejora de los aspectos humanos de la calidad); E. Jack Lancaster (a la persona
en reconocimiento de su dedicaci6n y contribuciones destacables en la
fratemidad intemacional de los profesionales de la calidad); Shewhart Medal (a
la persona que haya realizado la contribuci6n mas detacable a la ciencia y
tecnicas del control de la calidad); Freund-Marquardt Medal (a las personas
que hayan tenido puestos de responsabilidad en el establecimiento de
estandares centrados en los sistemas de gesti6n de las organizaciones); Juran
70 CAUDAD DE SISTEMAS INFOR?vLA. TICOS RA-MA
ji;/edal (al lider organizacional que muestre un desempeno distinguido en un
papel sostenido, practicando los principios clave de la calidad)".
Cl Premios Principe Felipe, convocados por el Ministelio de Indushia,
Comercio y Turismo, tienen como objetivo "el reconocimiento Pllblico de las
empresas radicadas en Espaiia que hayan realizado lin importante esJuerzo
pOl' mejo/'Qr su cOlllpetitividad a fl-m'es de los principales Jactores que la
dejznen". Estos Premios pueden ser a la Excelencia Empresarial, contemplando
varias categorias, (asi, pOl' ejemplo, en su decima edici6n abarcaban: Calidad
Indushial, Diseno, Energias Renovables y Eficiencia Energetica, Intemacio-
nalizaci6n, Excelencia TUlistica, Sociedad de la Infom1aci6n y Tecnologias de
la Infonnaci6n y lasComunicaciones, y Gesti6n de la Marca Renombrada) 0 a
la Competitividad Empresalial, en dos modalidades: Pequenas y Medianas
Empresas (PYME) y Grandes Empresas (este premio tiene un rango superior al
de los delmis, en la medida en que reconoce una actuaci6n de conjunto
comprensiva de los factores de competitividad contemplados en las diferentes
modalidades de los Premios anteriores).
e Premio a la Calidad en la Administracion General del Estado, es
convocado por el Ministerio de Adminish'aciones Pllblicas, y esta basado en el
Modelo EFQM de Excelencia en su adaptaci6n a la Administraci6n Pllblica.
e Cianfrani, CA., Tsiakals, lJ. y West, lE. (2002). ISO 9001:2000 cOlllentada.
Madrid, Asociaci6n Espanola de Nonnalizaci6n y Certificaci6n. Este libro
profundiza en algunos aspectos de la nonna ISO 9000.
Cl Arthur, lL. (1992). Improving SoJnvare Quality - An Insider's Guide to TQM
Nueva York, Wiley. Arthur presenta la utilizaci6n de los principios de calidad
total y de sus helTamientas asociadas para la mejora de la calidad del software.
e Tayntor, C.B. (2003). Six Sigma Jor software development. Florida, EEUU,
CRC Press. Este libro se presenta la aplicaci6n de la filosofia "Seis Sigma" al
desalTollo de software
Cl wW\v.isixsigma.com Este sitio ofrece bastante infonnaci6n sobre las cuestiones
relacionadas con la filosofia Six Sigma
@ http://W\v.efqm.org Este es el portal de la EFQM, que es una fundaci6n sin
animo de lucro creada en 1989 y que ofrece infonnaci6n y fonnaci6n para las
orgamzaclones interesadas en alcanzar la "excelencia" en sus mercados y
negoclOS.
CAPiTULO 3: ivl0DELOS Y NOR:'vL-\S DE CAUDAD
10. EJERCICIOS
1. Analice las diferentes categorias utilizadas a la hora de conceder el Malcom
Baldrige National Quality Award. Vease http://\v"\vw.quality.nist.gov. Examine la
organizaci6n a la que la han concedido el premio este ano en funci6n de los
principios de calidad establecidos por los gurus (tabla 1 del tema 1).
2. En caso de trabajar en una Universidad publica, privada 0 "corporativa", estudie
los Educational Criteria for Pelformance Excellence que estim disponibles en:
http://www.quality.nist.gov Segtin Baldrige (200Sb), estos clitelios se disefiaron
para ayudar a las organizaciones a utilizar un enfoque integrado en la gesti6n del
desempefio organizacional, que de como resultado: Entrega de valor con mejora
continua a los estudiantes y personas involucradas, connibuci6n a la calidad de la
fonnaci6n, mejora de la eficiencia y capacidades organizacionales en su con junto,
aprendizaje personal y organizacional. (,Que opina sobre estos clitelios? (,Cree
que existe alguna relaci6n entre estos cliterios y el aprendizaje activo centrado en
el alumno?
3. Encuentre los diferentes prelnios a la calidad que se cone eden en su pais 0 paises
del entomo y compare los clitelios de estos premios respecto a los del Malcom
Baldlige National Quality Award y a los delmodelo EFQM. Sugerencia: acceda
a http://andes.fundibeq.org/redibexlpremios.html.
4. Bianualmente se celebran los "European CAF events", cuyas actas puede
encontrar en http://www.eipa.nllCAF/ConferenceActivities. Analice las
ponencias de las dos ultimas ediciones identificando los elementos de gesti6n de
calidad que reciben mas atenci6n por parte de los responsables de las
administraciones publicas europeas.
CaUdad de
Sistemas In(ormaticos
4. CaUdad de Sistemas de Informacion
5. CaUdad de Producto Software
C.<\PITULO 4
CALIDAD DE SISTEMAS DE
INFORMACION
"La calidad de fa vida esta detenninada por SllS actividades"
Arist6tefes
1. SITUACION DE LA CAUDAD DE SI
Desde hace varios anos se viene insistiendo en la "crisis" de la Ingenieria del
Software y en los desastres que los fallos de software pueden llegar a causar en las
organizaciones.
A este respecto cabe destacar los infonnes "CHAOS" del Standish Group que
peri6dicamente "fotografian" la situaci6n del sector. En el ultimo infonne (Standish,
2001), se senala que s6lo el 28% de los proyectos infonnMicos finalizan en el tiempo
estimado, con los recursos planificados y con una ca4.idad aceptable, mientras que casi una
cuarta parte no llegan a finalizar nunca. El resto 10 hace pero consumiendo muchos m<ls
recursos 0 con menos funcionalidades de las previstas (vease figura 4.1). A pesar de ella
debemos congratulamos ya que se ha pasado del 16% en 1994 a128% en el ano 2000, 10
que indica que se va progresando en este sentido.
En NIST (2002) se repasan las perdidas econonucas (de varios centenares de
millones de d6lares) y en vidas humanas debido a los fallos del software en diferentes
sectores como, por ejemplo, el aeroespacial (desastres como los del Ariane 5, las sondas
de la misi6n a Marte, algunos aviones comerciales, etc.).
Recientemente, Jorgensen y Molokken-Ostvold (2006) revisan la estimaci6n de un
189% de retraso en la entrega para los proyectos infonnMicos que senalaba el infonne
76 CAUDAD DE SISTEivV\S TICOS ) RA.-ivL\
CHAOS de 1994, por 10 que deberia cuestionarse, en opinion de estos autores, si la
industria del software ha mejorado desde entonces tanto como parece seglin los liltimos
estudios.
Terninados
Gal
ceficiencias
49%
Terninados
Con Exito
28%
Terninados
Gal Fracaso
23%
Figura 4.1. Finalizacion de Proyectos (Standish, 2001)
En la maYOlia de libros sobre Ingenieria del Software 0 Cali dad del Software se
pueden encontrar estudios parecidos, as! como casos famosos (Arnbulancias de Londres,
Aeropuerto de Denver, etc.) que tienen que hacer reflexionar a los lectores sobre la
impOltancia que los sistemas de infol111acion tienen para el funcionamiento de la sociedad
actual (que presenta una dependencia cada vez mayor de estos), as! como para el bienestar
de las personas, 10 que enfatiza almmas la impOltancia de la calidad.
2. IMPORTANCIA DE LA CAUDAD EN LOS SI
Seglm Card (1995) la indushia del software ha expelimentado una selie de modas:
durante los setenta la productividad era la preocupjlcion de moda, sustituida en los ochenta
por la calidad, y en los noventa por el "time-fa-market" y el desanollo rapido. Este autor
seiiala que las organizaciones deberian considerar la importancia del time-ta-market para
su exito, teniendo en cuenta los dos factores que detenninan el mercado: la cantidad de
consumidores y de proveedores (vease figura 4.2).
Estos dos factores definen cuah'o mercados, que requieren diferentes eSh'ategias de
negoclo:
e Capacidad. Cuando se inicia un mercado. la capacidad de ofrecer un producto es
10 mas importante ya que los primeros c1ientes estan dispuestos a aceptar menos
calidad de 10 habitual si existen pocos proveedores capaces de ofi'ecer el
producto.
~ RA-ivLA.
c
o
N
S
U
M
I
D
o
R
E
S
;\1
U
C
H
0
S
P
0
C
0
S
CAPiTULO 4: CAUDAD DE SISTE1vLA.S DE INFORMACION 77
Time
to CaUdad
Market
Capacidad Coste
pocos iv!UCHOS
PROVEEDORES
Figura 4.2. Mercados segun la cantidad de consumidores/proveedores (Card, 1995)
Coste. En un mercado con muchos proveedores pero pocos consumidores, el
consumidor es quien dicta la cali dad que desea, as! que la unica estrategia
posible para el proveedor es conseguir la calidad solicitada al menor coste
posible.
Time-to-market. En un mercado en el que pocos proveedores compiten por
muchos consumidores, 10 111<lS imp0l1ante sent poner el producto 10 antes
posible en elmercado.
Calidad. En los mercados maduros la cali dad es el detel1ninante principal del
exito, ya que sera dificil conseguir el coste mas bajo.
3. COMPONENTES DE LA CAUDAD
La calidad de un sistema infol1natico puede descomponerse en diferentes factores
que contribuyen a la misma.
En Wilkin y Castleman (2003) se describe un instrumento multidimensional
(denominado QUALIT) capaz de medir la calidad de los sistemas de infol1naci6n
entregados, en el que se diferencia entre la calidad del sistema (entendida como juicio
global sobre el grado en que los componentes tecnicos del mismo proporcionan la calidad
78 CAUDAD DE SISTEMAS INFORMATICOS RA-MA
de la infonnacion y servicio requerido por los stakeholders), calidad de la infonnacion
propocionada a los stakeholders (excluyendo manuales de usuario y pantallas de ayuda),
calidad del servicio (proporcionado por el departamento de SI y el personal de soporte).
Para cada uno de estos componentes los autores han identificado varias dimensiones; as!,
por ejemplo, para la calidad del sistema se consideran: funcionalidad, integracion,
usabilidad, fiabilidad y seguridad.
Por otra parte, Stylianou y Kumar (2000) proponen una "vision holistica" de la
cali dad de los sistemas de infonnacion, en la que se consideren diferentes dimensiones.
Basandonos en este trabajo, en la figura 4.3 proponemos diferentes dimensiones de la
cali dad de un sistema de infonnaci6n.
Figura 4.3. Dimensiones de calidad de SI, basada en Stylianou y Kumar (2000)
La cali dad de una empresa u organizacion depended de la cali dad de los procesos
de negocio sopOliados por el sistema de infonnacion, as! como la propia calidad de este.
A su vez en la calidad del sistema de infonnacion podremos distinguir:
e
Calidad de la infraestructura
e
Cali dad de la gesti6n
e
Calidad del servicio
e
Cali dad del personal
e
Cali dad de la infonnacion
CAPiTULO 4: CAUDAD DE SISTE}'1AS DE INFORM.ACION 79
I) Cali dad del software
En los siguientes capitulos nos centraremos en los dos ultimos aspectos: calidad del
software, tanto de proceso como de producto, asi como cali dad de la infonnaci6n, que son
los que mas atenci6n han recibido en los ultimos ailos.
I) Glass, R.L. (2003), Facts and Fallacies of Software Engineering. Addison-
Wesley, Boston. Con el fin de evitar los fallos en los proyectos software, 10
mejor es conocer los "hechos" y las "falacias" de la Ingenieda del Software. En
este libro Robert Glass presenta 55 hechos y 10 falacias que hay que conocer y
tener en cuenta a la hora de desalTollar sistemas de infonnaci6n.
I) Evans, I. (2004). Achieving Software Quality through Teamwork. Artech
House, Boston. En este libro podemos encontrar algunas claves sobre la
"calidad del personal", ya que su autora proporciona una visi6n general de la
cultura de equipo necesaria para desalTollar software de calidad.
II http://catless.ncl.ac.uk/Risks En esta direcci6n se puede encontrar el "Forum
On Risks To The Public In Computers And Related Systems" del Committee
on Computers and Public Polic)' de ACM, moderado pOI' Peter Neumann y
que estudia los peligros de la falta de cali dad de los sistemas de info1l11aci6n.
II http://w"\vw.stickvminds.com/. El sitio web de la revista Sticky Minds dedicado
a las pruebas y a la calidad del software, presenta muchas definiciones de
Calidad del Software dadas por profesionales; es un contrapunto interesante a
las definiciones mas academic as de este concepto.
6. EJERCICIOS
1. Analice en que cuadrante del marco propuesto pOl' Card (1995) se situadan las
siguientes tecnicas:
a. DesalTollo Rapido de Aplicaciones (RAD)
b. Orientaci6n a objetos
c. HelTamientas CASE
d. Metodos agiles
80 CAUDAD DE SISTEtvL'\.S IN'FOIUvlA. TICOS RA-tvL'\.
2. Lleve a cabo una revision sistematica, utilizando el metodo propuesto en
Kitchenham (2004) de los articulos que tratan el concepto de Calidad de Sistemas
de Informacion aparecidos en la revista A;JJS Quaterly (w\V\v.misq.om:) en los
ultimos 10 anos. Analizar la evolucion experimentada por este concepto durante
este periodo de tiempo.
3. Estime, consultando las fuentes bibliognificas que considere oportuno, el coste
total debido a la baja calidad del software en el que puede haber incurrido su pais
o comunidad.
4. Indique de que manera se puede adaptar el modelo SERVQUAL (Parasuraman,
A., V. A. Zeitharni y L. L. Berry (1998). "SERVQUAL: a multi-item scale for
measuring consumer perceptions of service quality". Joumal of Retailing. Vol.
67(4). pp. 420-450) ala calidad del servicio en un sistema de informacion.
CAPITVL05
CALIDAD DE PRODUCTO SOFTWARE
"Lo que ahoga a algllien no es caerse al rio, sino mantenerse sllmergido ell el"
Palilo Coelho
1. MODElOS CLAslCOS
Historicamente se han desarrollado para evaluar la calidad de los productos
software diferentes modelos que pretenden seguir las directrices de cali dad de otros tipos
de productos: descomponer la calidad en una categoria de caracteristicas mas sencillas que
facilita su estudio (Galin, 2004).
Uno de los modelos clasicos mas utilizados desde su creacion, incluso con vigencia
en nuestros dias, es el desarrollado por McCall (McCall et al., 1977), en el que la calidad
de un producto software se descompone en once caracteristicas 0 factores de calidad
agrupados en tres categorias (vease figura 5.1): Operacion de producto, Revision de
producto y transicion de producto.
A finales de los afios ochenta, fueron propuestos dos modelos altemativos a los de
McCall basados igualmente en la identificacion de factores: el modelo de factores de
Evans y Marciniak (1987) y el modelo de factores de Deutsch y Willis (1988).
En la tabla 5.1 puede encontrarse una comparativa entre los distintos modelos
donde se muestran los factores observados por cada uno de los autores en sus
correspondientes trabajos.
Otro modelo considerado como clasico es el reconocido como FURPS, acronimo
compuesto por las iniciales en ingles de las categorias Funcionalidad, Facilidad de uso,
Fiabilidad, Rendimiento y Capacidad del software; esta lista es una de las muchas
82 CAUDAD DE SISTEMAS ll\'FORt'vIA TICOS RA-MA
adaptaciones y/o complementaciones del modelo de McCall que cada organizaclon ha
ideado para sus propios trabajos, como la dada por Grady y Caswell (1987) para Hewlett
Packard.
Vision de usuario
Operacion d
producto
Vision de la
Facilidad de uso-
Comunicatividad
Seguridad (integrida Volumen y tasa de ElS
Datos comunes
Eficiencia Control y audit. de acceso
Integridad de datos
Fiabilidad
Eficiencia de almacenam.
Eficiencia de ejecucion
Complecion
Trazabilidad
Revision Facilidad de Consistencia
producto mantenimiento Precision
Facilidad de Tolerancia a errores
P
rueba Simplicidad
Concision
Flexibilida Autodescriptividad
Modularidad
Transicion Capacidad de Instrumentacion
producto reutilizacion Capacidad de ampliacion
Generalidad
I Indep. maquina
Interoperabilida'lf'-----------
Figura 5.1. Modelo de calidad de McCall (1976).
EVA'1SY
FACIOR CALIDAD SOFT\VARE MCCALL (1916) l\:h:RCINIAl( I. DHJISCHyWILLrs(1988)
.. .... (1981) I ..
Correccion
./ ./ ./
Fiabilidad
./ ./ ./
Eficiencia
./ ./ ./
Integridad
./ ./ ./
Usabilidad
I
./ ./ ./
Mantenibilidad
./ ./ ./
Flexibilidad
./
.
./ ./
Testeabilidad
./
Portabilidad
./
I
./ ./
Reusabilidad
./ ./ ./
Interoperabilidad
./ ./ ./
Verificabilidad
I
./
I
./
Expandibilidad
./
I
./
Seguridad de Uso
./
Manejabilidad
./
Capacidad de supervivencia
I
./
Tabla 5.1. Comparacion entre modelos de calidad de producto software (Galin, 2004)
..
f:RA-MA. CAPiTULO 5: C.ALIDAD DE PRODUCTO SOFTWARE 83
En cualquier caso, todos estos modelos requieren identificar metric as para esas
caracteristicas de cali dad que penni tan medir cuantitativamente como de bueno es un
software atendiendo a esos criterios. El capitulo 9 de este libro pretende cubrir este
aspecto.
2. NORMAS ISO 25000
El SC7 de ISO esta desarrollando la familia de nonnas ISO 25000 (ISO 2005a-n)
conocida con el nombre de SQuaRE (Software product Quality Requirements and
Evaluation) que se organiza en cinco apartados (vease figura 5.2) y que sustituye y amplia
las actuales nOlmas ISO 9126 (ISO, 1991; Tecnologia de la Infonnacion -Calidad de un
producto software) y 14598 (ISO, 1999; Tecnologia de la Infonnacion- Evaluacion de un
producto software).
i
i
Modelo de Calidad 2501 n
:
Requisitos de
I
Evaluaci6n de
Calidad I Gesti6n de Calidad 2500n Calidad
2503n 2504n
j
Medici6n de Calidad
2502n
ifi!3"&''}

'%'

Figura 5.2. Organizacion de la familia de normas ISO 25000
@ ISOJIEC 2500n - Division de Gestion qe Calidad. Las nonnas que fonnan
este apartado definen todos los modelos, tenninos y definiciones comunes
referenciados por todas las oh"as nonnas de la serie SQUARE.
@ ISOJIEC 2501n - Division de Modelo de Calidad. La nonna de este apartado
presenta un modele de cali dad detallada incluyendo caracteristicas para calidad
interna, externa y en uso.
@ ISOJIEC 2502n - Dhision de Medici6n de Calidad. Estas nonnas incluyen
un modele de referencia de la medicion de la calidad del producto, definiciones
de medidas de calidad (interna, extern a y en uso) y guias practicas para su
aplicacion.
84 CALIDAD DE SISTEi\1AS TICOS RA.-ivLA.
e ISOIlEC 2503n - Division de Requisitos de Calidad. Estas nonnas ayudan a
especificar requisitos de calidad que pueden ser utilizados en el proceso de
elicitaci6n de requisitos de calidad del producto software a desaITollar 0 como
entrada del proceso de evaluaci6n.
e ISOIlEC 2504n -Division de Evaluacion de Calidad. Este apartado incluye
nonnas que proporcionan requisitos, recomendaciones y guias para la
evaluaci6n de productos software.
En el momento de redactar este libro, las diferentes nonnas de la familia ISO 25000
alin no se han tenninado de elaborar, por 10 que a continuaci6n se explican las nonnas
ISO 9126 e ISO 14598, ya que probablemente los conceptos basicos se mantengan con
pocos cambios significativos en las nuevas nonnas.
Necesidades
de calidad
+----------
Cali dad en uso
del usuario
Uso y
I
retroalimentaci6n
t
Contribuye a especificar
Indica
I
Requisitos de Calidad
caUdad externa

extern a
Validaci6n
I i
Contribuye a especificar Indica
I
Requisitos de
.
CaUdad
caUdad interna

interna
Verificaci6n
Figura 5.3. Perspectivas de calidad segun la norma ISO 9126
2.1. Aspectos de la calidad de un producto software
En la cali dad de un producto sofhvare, as! como en las metric as asociadas en las
diferentes etapas del cicio de vida del software, se sue len distinguir tres aspectos
diferentes (ver figura 5.3): calidad intema: medible a paItir de las caracteristicas
Q RA-tvL-\ CAPiTULO 5: CAUDAD DE PRODUCTO SOFTWARE 85
intlinsecas, como el c6digo fuente, extema; medible en el comportamiento del producto,
como en una pmeba; 0 en uso: medible durante la utilizaci6n efectiva por parte del
usuario en un contexto determinado.
Siguiendo la filosofia de los modelos clasicos de calidad de un producto software,
la nom1a ISO 9126 descompone la calidadjerarquicamente en una serie de caracteristicas
y subcaracteristicas que pueden usarse como una lista de comprobaci6n de aspectos
relacionados con la calidad.
2.2. Modelo de calidad interna y externa
II modelo de calidad para calidad intema y extema categoliza los atributos de
calidad software en seis caracteristicas (funcionalidad, fiabilidad, usabilidad, eficiencia,
mantenibilidad y portabilidad), que se subdividen a su vez en subcaracteristicas (figura
5.4), que se resume a continuaci6n (ISO, 2001).
. :
Adecuaci6n
Exactitud
rv1adurez
Interoperabilidad
Tolerancla a rallos
Seguridad de
Capacidad de
recuperac16n
aeceSD
Cumphmiento de
Cump!imiento de
la funclonalidad
la fiabiHdad
Calidad externa e
interna
Capacidad de ser
entendldo
Capacidad de ser Comportamiento
aprendldo temporal
Capacidad de ser Utilizacion de
operado recursos
Capecidad de
atraccion Cumplimiento de
la eficiencia
Cumplimiento de
la usabilidad
Capacidad de ser
analizado
Capacidad de ser
cambiado
Capacidad de ser
probado
Cump!imiento de
la mantenibi!idad
Figura 5.4. lVIodelo para la caUdad extern a e intern a (ISO, 2001)
2.2.1. FUNCIONALIDAD
Adaptabilidad
Instalabilidact
Coexistencia
Capacidad de ser
reemplazado
Cumplimiento de
Ja portabilidad
Capacidad del producto software para proporcionar funciones que satisfacen
necesidades declaradas e implicitas cuando se usa bajo condiciones especificadas. Ista
caracteristica se subdivide a su vez en:
o Adecuacion. Capacidad del producto sofuvare para proporcionar un con junto
apropiado de funciones para tareas y objetivos de usuario especificados.
86 CAUDAD DE SISTEMAS INFOR.!\1A.TICOS RA-MA
iii Exactitud. Capacidad del producto software para proporcionar los resultados 0
efectos correctos 0 acordados, con el grado necesario de precision.
iii Interoperabilidad. Capacidad del producto software para interactuar con uno
o mas sistemas especificados.
iii Seguridad de acceso. Capacidad del producto software para proteger
informacion y datos de manera que las personas 0 sistemas no autorizados no
puedan leerlos 0 modificarlos, al tiempo que no se deniega el acceso a las
personas 0 sistemas autorizados.
iii Cumplimiento funcional. Capacidad del producto software para adherirse a
normas, convenciones 0 regulaciones en leyes y prescripciones sirnilares
relacionadas con funcionalidad.
2.2.2. FIABILIDAD
Capacidad del producto software para mantener un nivel especificado de
prestaciones cuando se usa bajo condiciones especificadas. Esta caracteristica se subdivide
a su vez en:
Madurez. Capacidad del producto software para evitar fallar como resultado
de fallos en el software.
iii Tolerancia a fallos. Capacidad del software para mantener un nivel
especificado de prestaciones en caso de fallos software 0 de infringir sus
interfaces especificados.
iii Capacidad de recuperacion. Capacidad del producto software para
reestablecer un nivel de prestaciones especificado y de recuperar los datos
directamente afectados en caso de fallo.
iii Cumplimiento de la fiabilidad. Capacidad del producto software para
adherirse a normas, convenciones 0 regulaciones relacionadas con la fiabilidad.
2.2.3. USABILIDAD
Capacidad del producto software para ser entendido, aprendido, usado y ser
atractivo para el usuario, cuando se usa bajo condiciones especificadas. Esta caracteristica
se subdivide a su vez en:
Capacidad para ser entendido. Capacidad del producto software que permite
al usuario entender si el software es adecuado y como puede ser usado para
unas tareas 0 condiciones de uso particulares.
Capacidad para ser aprendido. Capacidad del producto software que perrnite
al usuario aprender sobre su aplicacion.
lRA-MA CAPiTULO 5: CAUDAD DE PRODUCTO SOFTWARE 87
Capacidad para ser operado. Capacidad del producto software que pennite
al usuario operarlo y controlarlo.
Capacidad de atracci6n. Capacidad del producto software para ser atractivo
al usuario.
Cumplimiento de la usabilidad. Capacidad del producto software para
adherirse a nonnas, convenciones, guias de estilo 0 regulaciones relacionadas
con la usabilidad.
2.2.4. EFICIENCIA
Capacidad del producto software para proporcionar prestaciones apropiadas,
relativas a la cantidad de recursos usados, bajo condiciones determinadas. Esta
Comportamiento temporal. Capacidad del producto software para
proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados,
bajo condiciones determinadas.
Utilizaci6n de recursos. Capacidad del producto software para usar las
cantidades y tipos de recursos adecuados cuando el software lleva a cabo su
funci6n bajo condiciones determinadas.
Cumplimiento de la eficiencia. Capacidad del producto software para
adherirse a nonnas 0 convenciones relacionadas con la eficiencia.
2.2.5. MANTENmILIDAD
Capacidad del producto software para ser modificado. Las modificaciones podrian
incluir correcciones, mejoras 0 adaptaci6n del software a cambios en el entomo, y
requisitos y especificaciones funcionales. Esta caracteristica se subdivide a su vez en:
Capacidad para ser analizado. Es la capacidad del producto software para
serle diagnostic ad as deficiencias 0 causas de los fallos en el software, 0 para
identificar las partes que han de ser modificadas.
Capacidad para ser cambiado. Capacidad del producto software que pennite
que una detenninada modificaci6n sea implementada.
Estabilidad. Capacidad del producto software para evitar efectos inesperados
debidos a modificaciones del software.
Capacidad para ser probado. Capacidad del producto software que pennite
que el software modificado sea validado.
Cumplimiento de la mantenibilidad. Capacidad del producto software para
adherirse a nonnas 0 convenciones relacionadas con la mantenibilidad.
88 CAUDAD DE SISTE?vLA.S TICOS RA-?viA.
2.2.6. PORTABILIDAD
Capacidad del producto software para ser transferido de un entomo a otro. Esta
G Adaptabilidad. Capacidad del producto software para ser adaptado a
diferentes entomos especificados, sin aplicar acciones 0 mecanismos distintos
de aquellos proporcionados para este proposito por el propio software
considerado.
G Instalabilidad. Capacidad del producto software para ser instalado en un
entomo especificado.
G Coexistencia. Capacidad del producto software para coexlstlr con otro
software independiente, en un entomo comun, compartiendo recursos
comunes.
G Capacidad para ser reemplazado. Capacidad del producto software para ser
usado en lugar de otro producto software, para el nusmo prop6sito, en el
mismo entomo.
Cumplimiento de la portabilidad. Capacidad del producto software para
adhelirse a nonnas 0 convenciones relacionadas con la portabilidad.
2.3. Modelo de calidad en uso
La nonna ISO 9126 entiende por calidad en uso "fa capacidad def prodllcto
sofMare para pennitir a detenninados lIsliarios alcanzal' objetivos espectficados con
efectividad, prodllctividad, segllridad y satisfacci6n (figura 5.5), en contex:tos de lIS0
especificados".
La calidad en uso contempla las siguientes caracteristicas:
2.3.1. EFECTIVIDAD
Capacidad del producto software para pennitir a los usuarios alcanzar objetivos
especificados con exactitud y compleci6n, en un contexto de uso especificado.
2.3.2. PRODUCTIVIDAD
Capacidad del producto software para pennitir a los usuarios gastar una cantidad
adecuada de recursos con relaci6n a la efectividad alcanzada, en un contexto de uso
especificado.
RA-ivLA CAPiTIJLO 5: CAUDAD DE PRODUCTO SOFTWARE 89
Calidad de Uso
Figura 5.5. Modelo para la calidad en uso (ISO, 2005)
2.3.3. SEGURIDAD DE usa
Capacidad del producto software para alcanzar niveles aceptables del riesgo de
hacer dana a personas, al negocio, al software, a las propiedades 0 al medio ambiente en
un contexto de uso especificado.
2.3.4. SATISFACCION
Capacidad del producto software para satisfacer a los usuarios en un contexto de
uso especificado.
2.4. Evaluaci6n de un producto software
La nonna ISO 14598 da una vision general del proceso de evaluacion de un
producto software, explicando en sus diferentes partes como aplicar el proceso en
diferentes circunstancias. En la figura 5.6 (ISO, 1999) se resunie este proceso.
Esta nonna se apoya en la ISO 9126 ya que los aspectos cuantificables pueden
medirse cuantitativamente usando metricas de calidad, cuyo valor medido se sima en una
escala. La escala ha de dividirse en rangos que cOlTesponden a diferentes niveles de
satisfaccion de los requisitos. Por ejemplo:
G La division de la escala en dos categorias: satisfactOlio e insatisfactOlio.
G La division de la esc ala en cuatro categorias lirnitadas por el nivel actual de un
producto existente 0 altemativo, el peor caso y el nivel proyectado. El nivel
actual se declara con el fin de controlar que el nuevo sistema no suponga un
deterioro en relacion a la situacion actual. EI nivel proyectado es 10 que se
considera alcanzable con los recursos disponibles. El peor caso es la frontera
90 CAUDAD DE SISTEtvL">.S INFOR.,\V\ TICOS RA-MA
para aceptacion de! usuario por si acaso e! producto no cubre e! nive!
proyectado (figura 5.7).
Establecer Propos ito de fa Evaluaci6n
Establecer ___ -4
de Evaluaci6n
Identificar los tipos de producto(s)
Especificar el modelo de caUdad
Establecer niveles para las metricas
Establecer criterios de valoracion
Producir Plan de Evaluaci6n
Tomar medidas
Valorar Resultados
91261 Caracteristicas de Calidad
91262 Metricas Extemas
9126-3 Metricas Intemas
14598-6 Modulos de Evaluaci6n
Figura 5.6. Proceso de evaluacion de un producto software (ISO, 1999)
niyel
Excede los requisitos
-

medido -=-
satistbctorio
Rango objetiyo
-
-
-
- .
-
-
niyel
-
-
-
Minimanii!nte
-
-
el casu peo,--
insatistbctorio
-
-
-
-

-
-
-
escala de nii!dicion niveles de puntuaciOn
Figura 5.7. Rangos de una esc ala de medida (ISO, 1999)
<:: RA.-MA CAPiTULO 5: CAUDAD DE PRODUCTO SOFTWARE 91
3. TRABAJOS BASADOS EN LAS NORMAS ISO 9126 E
ISO 14598
Existen multitud de trabajos basados en las nonnas ISO 9126 e ISO 14598 que
puede ser de interes a la hora de plantearse la evaluacion de productos software. En este
apartado citamos algunos de los mas relevantes:
I SQUID (Boegh, 1. et 01., 1999), pennite la especificacion, planificacion,
evaluacion y control de la calidad de software a tI'aves de los procesos de
desanollo. La calidad queda definida como un comportamiento operacional de
los productos requeridos por sus usuarios. Ofrece un metodo y una henamienta
de soporte que reciben el nombre de SQUID.
I QUINT2 (Niessink, 2002) amplia el modelo de la ISO 9126 para evaluar la
calidad de arquitecturas software.
I Bertoa et 01., (2005). Adaptan la nom1a ISO 9126 a los componentes COTS.
I Losavio et 01. (2003) refinan el modelo de cali dad de la ISO 9126 para
arquitecturas software, llegando a proponer divers as medidas para los atIibutos
de calidad.
I Franch y Carvallo (2003), y Botella et. al (2003), desanollan una metodologia
que conduce a la constmccion de modelos de cali dad especificos de dominio
en tenninos del estandar ISO 9126, y que han aplicado a paquetes software
COTS (commercial off-the-shelj). Esta metodologia consta de siete pasos
(figura 5.8):
O. Definir el dominio
1. Detenninar subcaracteristicas de calidad
2. Definir unajerarquia de subcaracteristicas
3. Descomponer subcaracteristicas en atIibutos
4. Descomponer atIibutos derivados (aquellos que no sean medibles
directamente) en atIibutos basicos
5. Establecer relaciones entI'e entidades de calidad (por ejemplo, aumentar
la subcaracteristica de seguridad lleva consigo que aumente la madurez
de un producto)
6. Detenninar metIicas para los atIibutos.
I Simlo y Belchior (2003). Amplian las subcaracteristicas y atIibutos propuestos
por la nonna ISO 9126 llegando a identificar 124 atIibutos de cali dad para los
componentes software.
I Moraga et 01., (2005) proponen un modelo de calidad para portlets basada en
la adaptacion de ISO 9126 asi como en algunos de los trabajos anterionnente
citados.
92 CAUDAD DE SISTEMAS Il\1fOR,'vrA. TICOS RA-l\IA
Paso 1
Paso 3
Paso 4
Paso 5
Paso 6
Establecer Relaciones
entre entidades de calidad
Datarminar ivletricas
para los atributos
Figura 5.8. Metodologia para la construccion de modelos de calidad especificos de
dominio (Franch y Carvallo, 2003)
Cechich, A., Piattini, M. y Vallecillo, A. (eds.) (2003). Component-Based
Sofnvare Quality: jvfethods and Techniques. Splinger Verlag LNCS 2693. En
esta recopilacion se abordan diversos aspectos de la calidad relativa a los
sistemas sofuvare basados en componentes.
http://v{v{w.sei.cmu.edulsemaipresentations/zubrow/esepg/ Presentacion del
Sofnvare Engineering Institllte sobre IS.O 25000 Y el modelo CMMI.
6. EJERCICIOS
1. Compare las caracteIisticas y subcaracteIisticas de calidad del modelo de McCall
y de1l110delo propuesto en la nonna ISO 9126, (,cmille parece m1s completo?, (,a
que elementos de la calidad Ie concede 111<1S importancia McCall? y (,a cmiles la
non11a ISO 9126?, (,encuentra gran sil11ilitud entre ambos?
2. Como sefiala Kan (2003), los panimetros de satisfaccion del c1iente que
monitol1za IBM son: capacidad, funcionalidad, usabilidad, desel11pei'io, fiabilidad,
instalabilidad, l11antenibilidad, documentacion!infOlmacion, y servicio), mientras
GRA-?vLA,. CAPiTULO 5: CAUDAD DE PRODUCTO SOmVARE 93
que Hewlett-Packard utiliza: funcionalidad, usabilidad, fiabilidad, desempeiio y
servicio; compare estos panimetros con las caracteristicas de la nonna ISO 9126.
3. Tomando como base el proceso de selecci6n propuesto por la nonna ISO 14598,
defina un proceso de selecci6n para henamientas de amllisis y diseiio Olientado a
objetos, adaptando si fuera necesario el modelo de calidad de la ISO 9126.
Compare elmodelo definido con la nonna ISO 14102 (ISO, 1995).
4. Compare las diferentes propuestas existentes sobre modelos de calidad para
componentes (p.ej. Simao y Belchior (2003) 0 Bertoa et al. (2005)) analizando
que caracteristicas y subcaracteristicas de la nonna ISO 9126 se han adoptado tal
cual, l11odificado 0 descartado para este tipo de software.
5. Desanolle un proceso de analisis y selecci6n para sistemas de infonnaci6n
geognifica (SIG) teniendo en cuenta las caracteristicas distintivas de este tipo de
sistemas. Proponga a continuaci6n diferentes fonnas de medir las caracteristicas
propuestas.
6. Accediendo al portal de ISO (wlvw.iso.ch) investigue cual es la situaci6n actual
de las nOlmas de la familia ISO 25000, Y su trazabilidad respecto a las nonnas
ISO 9126 e ISO 14598.
7. Analice. utilizando una matriz, las diferentes interacciones que pueden darse entre
las subcaracteristicas del modelo de calidad de la ISO 9126. Por ejemplo, una
mayor funcionalidad podria influir en una men or facilidad de prueba.
CaUdad del Proceso
Software
6. EI Proceso Software
7. Modelos de Proceso de CicIo de Vida
8. Evaluacion y Mejora de Procesos
CAPiTULO 6
EL PROCESO SOFTWARE
"Los Procesos Software tall/bien son Software"
Leon Osten veil
1. INTRODUCCION
Tradicionalmente la Ingenieria del Software se ha centrado en metodologias y
lenguajes de programacion, modelos de desalTollo y helTamientas. Sin embargo, y
teniendo en cuenta la creciente complejidad de los sistemas, se hacia necesario incluir
detenninadas areas que hoy en dia son criticas para la ingenieria del software, como las
infraestructuras de gestion y organizacion, por 10 que surge la denominada ingenieria del
software basada en el proceso (Wang y King, 2000).
Tal como se destaca en numerosos estudios, actualmente la calidad de cualquier
producto no puede ser asegurada simplemente inspeccionando el producto por sl mismo 0
desalTollando controles de calidad estadisticos. Esta 'l.finnacion se basa en que existe una
cOlTelacion directa entre la calidad del proceso y la calidad del producto obtenido
(Fuggeta, 2000) y en consecuencia, una organizacion no puede garantizar la entrega de
productos de calidad centrando sus programas de calidad unicamente en el producto
(Satpathy y Harrison, 2002).
Durante las tres ultimas decadas, el estudio de los procesos de produccion de
software ha llevado al desalTollo de varios ciclos de vida en la ingenieria del software
como, por ejemplo, los modelos cascada, evolutivo y en espiral (Piattini et 01., 2003).
Estos modelos del ciclo de vida ayudan a los ingenieros y a los gestores a comprender
mejor el proceso software, y a detenninar el orden de las actividades necesarias en la vida
de un producto software.
98 CAUDAD DE !1\1fOR.tVlA TICOS
Sin embargo, es muy importante establecer claramente la diferencia entre proceso
software y ciclo de vida, ya que en much as ocasiones son tratados en la bibliografia como
conceptos equivalentes. Un ciclo de vida software es "un marco de referencia que
contiene los procesos, las actividades y las tareas invoilicradas en el desarrollo, fa
explotacion y el mantenimiento de lin producto de software, abarcando la vida del
sistema desde fa definicion de los reqllisitos hasta la finalizacion de Sll lISO" (ISO, 1995;
ISO, 2002b). El ciclo de vida software define los principios y las directrices de acuerdo a
las cuales se deben llevar a cabo estas etapas. Por ejemplo, el ciclo de vida en cascada
sugiere que antes de comenzar una nueva fase se deben haber finalizado los entregables de
la fase anterior. EI proceso software es un concepto mas amplio, bas ado en el de ciclo de
vida, y cubre todos los elementos necesarios (tecnologias, personal, artefactos,
procedimientos, etc.) relacionados con las actividades involucradas en la vida de un
producto software. En este contexto los ciclos de vida aportan un marco de referencia para
los procesos de desarrollo y mantenimiento del software (vease Capitulo 7).
Un proceso se define como un conjunto de actividades interrelacionadas que
transfommn entradas en salidas (ISO, 1995). Un proceso define quien esta haciendo que,
cuando, y como a1canzar un detenninado objetivo. Respecto al proceso software, en la
literatura podemos encontrar divers as definiciones:
EI "Con junto de actividades, Iluitodos, practicas y transformaciones que la gente
lisa para desarrollar), mantener software y los productos de trabajo asociados
(planes de proyecto, diseiio de doclllnentos, codigo, pruebas y manuafes de
uSliario) " (SEI, 1995).
EI "Proceso 0 conjlli1fO de procesos usados por una organizacion 0 proyecto,
para plantficar, gestionar, ejecutar, monitorizar, controlar y mejorar SliS
actividades software relacionadas" (ISO, 1998).
EI "Conjunto coherente de politicas, estructuras organizacionales, tecnologias,
procedimientos y artefactos que son necesarios para concebir, desarrollar,
empaquetar y mantener un producto software" (Fuggeta, 2000).
EI "Conjunto parcialmente ordenado de actividades lie vadas a cabo para
gestionar, desarrollar y mantener sistemas software" (Acuna et af., 2001).
EI "Ef proceso soff1vare define como se organiza, gestiona, mide, soporta y
mejora el desarrollo, independientemente de las tecnicas y lI1etodos usados"
(Demiame et al., 1999).
El proceso software es un proceso con una natmaleza especial, detenninada por las
siguientes caracteristicas (Demiame et al., 1999):
- EI Es complejo.
kRA.-MA CAPiTULO 6: EL PROCESO SOFTWARE 99
No es un proceso de produccion tipico; ya que esta dirigido por excepciones, se
ve muy detenninado por circunstancias impredecibles, y cada uno tiene
peculiaridades que 10 distingue de los delmis.
Tampoco es un proceso de ingenieria "pura"; ya que se desconocen las
abstracciones adecuadas, depende en gran medida de demasiada gente, el
diseno y la produccion no estan claramente diferenciados, y los presupuestos,
calendarios y calidad no pueden ser planificados de forma suficientemente
fiable.
e No es (completamente) un proceso creativo; ya que algunas partes pueden ser
descritas en detalle y algunos procedimientos son impuestos previamente.
e Esta bas ado en descublimientos que dependen de la comunicacion,
coordinacion y cooperacion dentro de marcos de trabajo predefinidos: los
entregables generan nuevos requisitos; los costes del cambio del software no
suelen reconocerse; y el exito depende de la implicacion del usuario y de la
coordinacion de muchos roles (ventas, desarrollo tecnico, c1iente, etc.).
La necesidad de participacion humana de forma creativa y la ausencia de
acciones repetitivas hacen que ni el desarrollo ni el mantenimiento del software sean
procesos de fabricacion, pero existen algunas similitudes entre ambos tipos de procesos
que son lltiles para comprender los procesos software con una perspectiva mas amplia. Al
igual que los procesos de fabricacion, los procesos software cons tan de dos subprocesos
interrelacionados (McLeod, 1990; Demiame et al., 1999):
e Proceso de Produccion, relacionado con la construccion y mantenimiento del
producto software.
e Proceso de Gestion, que es el encargado de estimar, planificar y controlar los
recursos necesarios (personas, tiempo, tecnologia, etc.) para poder llevar a cabo
y poder controlar el proceso de produccion. Este control genera infonnacion
sobre el proceso de produccion, que puede ser usada posterionnente para
mejorar el proceso y por tanto, mejorar la calidad del producto software.
Por 10 tanto, el proceso software es un campo de estudio amplio y complejo en el
mundo de la ingenieria del software, en el que debido a la gran cantidad y diversidad de
elementos relacionados, se podrian establecer en las siguientes categorias (Fuggetta,
2000):
e Tecnologia de Desarrollo Software, relacionado con el soporte tecnologico,
en fonna de herrarnientas, infraestmcturas y entomos.
II Metodos y Tecnicas de Desarrollo Software, que constituyen Hneas guia
sobre como se deben hacer las cosas: uso de la tecnologia y realizacion de las
actividades.
100 CAUDAD DE SISTEMAS IN'FORMATICOS R.-\-MA
e Comportamiento Organizacional, relacionado con los recursos humanos.
Los procesos software son llevados a cabo por equipos de personas que tienen
que estar coordinados y deben gestionarse desde una eficiente estructura
organizacional.
e Economia y Marketing, relacionado con la gestion de proyectos, debido a que
el producto software final debe cumplir con unos plazos y costes detenninados
y debe satisfacer las necesidades del cliente al que va destinado.
La integracion de las tecnologias de produccion y de gestion en un entomo de
trabajo constituye la esencia de la Tecnologia del Proceso Software y como resultado se
han desanollado los denominados Entornos de Ingenieria del Software orientados al
Proceso (PSEE, Process-centered Software Engineering Environment).
A pesar de su importancia y de los avances en la investigacion en estos temas, muy
pocas propuestas de PSEE han sido aplicadas de fonna pnictica en la indusnia. Tal y
como se ha comentado las razones son variadas, desde la ligidez de muchas de las
propuestas que ha dificultado su aplicacion indusnial en mercados diniunicos, a la
necesidad de introducir este tipo de entomos poco a poco, pmtiendo de un modelado
descriptivo de los procesos que ayude a su entendimiento y comunicacion, para
posterionnente afiadir los detalles necesmios para proporcionar sopOlte a su ejecucion.
Sin embargo y a pesar de que el tema de los procesos software no se ha establecido
alm como una disciplina que se ensefie y practique universalmente por la indusnia del
software es de esperar que en el fhturo las tecnologias de sopOlte a los procesos software
maduren y sean adoptadas por las organizaciones.
2. GESTION DE LOS PROCESOS SOFTWARE
Los requisitos de calidad mas significativos de los procesos software son: (1) que
produzcan los resultados esperados, (2) que esten basados en una COlTecta definicion y (3)
que sean mejorados en funcion de los objetivos de negocio, muy cambiantes ante la gran
competitividad de las empresas hoy en dia. E:;tos son los objetivos de la Gestion del
Proceso Sofuvare (Florac y Carleton, 1999). Para aplicar esta gestion de fonna efectiva es
necesario asumir cuatro responsabilidades clave: Definir, Medir, Controlar y Mejorar el
Proceso. Estas responsabilidades y sus relaciones se representan en la figura 6.1.
De acuerdo a estas responsabilidades, para llevar a cabo de una fonna eficiente la
mejora del proceso es necesario tener en cuenta los siguientes aspectos:
e Definicion del Proceso. La definicion del proceso es la primera
responsabilidad clave que hay que asumir para poder realizar una gestion
efectiva de los mismos. Para ello, es necesario modelar los procesos, es decir,
representar los elementos de interes que intervienen. EI modelado de los
procesos software, por 10 tanto, constituye un paso fundamental para la
t RA-iviA cAPinJLO 6: EL PROCESO SOFTIVARE 10 1
comprensi6n y mejora continua de los procesos de una organizaci6n (Arbaoui
et aI., 2003).
Mejorar el
Proceso
Controlar el
Proceso
Figura 6.1. Etapas Clave de la Gestion del Proceso Software
G Ejecucion y Control del Proceso. Los proyectos software de una empresa se
llevan a cabo de acuerdo a los modelos de procesos definidos. En este sentido,
es importante poder controlar en todo momento la ejecuci6n de estos proyectos
(yen consecuencia, de los procesos cOlTespondientes) para garantizar que se
obtienen los resultados esperados. Para ello, se han desalTollado en las dos
llltimas decadas los denominados "En 10177 os de lngenieria del Sofnmre
orientados a Procesos" (PSEE), que son los sistemas software que ayudan en
el modelado de los procesos software utilizando un determinado lenguaje y en
su posterior automatizaci6n por medio de Sll reificaci6n (enactment).
G Medicion y Mejora. Existe una importante cOlTelaci6n entre la medici6n y la
mejora de los procesos software. Antes de poder mejorar un proceso es
necesario llevar a cabo una evaluaci6n, cuyo objetivo es detectar los aspectos
que se pueden mejorar. Para ello, es conveniente disponer de un marco de
trabajo efectivo que facilite la identificaci611 de las entidades relevantes
candidatas a ser medidas. Con los resultados de la medici6n de los procesos es
posible disponer de una infomlaci6n objetiva que pennita planificar, identificar
y llevar a cabo de una manera eficiel1te las acciones de mejora necesarias. Dada
la importancia de estos aspectos, se estudian con mucho mayor detalle a 10
largo del libro. La medici6n del software es tratada en el capitulo 9, mientras
102 CAUDAD DE SISTEivl-\S INFOJUvlA TICOS RA-ivl-\
que los modelos y estandares de evaluacion y mejora de procesos se tratan en
el capitulo 8.
A continuacion se presentan las caractedsticas del model ado y ejecucion de los
procesos software.
3. EL MODELADO DE LOS PROCESOS SOFTWARE
Uno de los aspectos basicos y fundamentales para la tecnologia de soporte a los
procesos software es disponer de modelos de procesos que representen fielmente la fonna
de hacer las cosas de las organizaciones. En una empresa 0 en un dominio de aplicacion,
los procesos de diferentes proyectos tienden a seguir patrones comunes, bien porque las
"mejores practicas" son reconocidas fonnalmente, bien porIa existencia de estandares
utilizados. POl' 10 tanto se hace necesario intentar capturar estos aspectos comunes en una
representacion de proceso, la cual describe estas caractedsticas comunes y fomenta la
homogeneidad y la unificacion de criterios.
POI' 10 tanto, uno de los grandes objetivos de la tecnologia de procesos es lograr que
la representacion de procesos pueda ser us ada para gestionar los procesos aChmles de
desalTollo y mantenimiento del software. Como primer paso, la tecnologia de procesos
introduce la no cion de modelo de procesos, que consiste en la descripcion de un proceso
expresandolo en un lenguaje de modelado de procesos adecuado (Finkelstein et af., 1994).
Un modelo de procesos puede ser analizado, validado y simulado, si es ejecutable. En los
modelos de procesos se puede describir de una fonna precisa los diferentes aspectos
relacionados con los procesos software, de fonna que con diferentes modelos se puedan
expresar las diferentes vistas de un proceso.
Los objetivos y beneficios que motivan la introduccion de modelos de procesos son
varios, destacando los siguientes (Curtis et af., 1992):
G Facilidad de entendimiento y comunicacion, 10 que requiere que un modelo
de procesos contenga suficiente informacion para su representacion. Un
modelo, como representacion del pJ;oceso que es, puede ser usado para la
fonnacion del personal.
G Soporte y control de la gestion del proceso.
G Provision para la automatizacion orientada al rendimiento del proceso, 10
que requiere un entorno de desan'ollo efectivo del software, proporcionando
orientaciones, instrucciones y material de referencia al usuario.
II) Provision para el soporte auto matico a la ejecucion, para 10 cual es necesario
automatizar ciertas partes del proceso, dar soporte al trabajo en grupo,
compilacion de metricas y aseguramiento de la integridad del proceso.
G Soporte a la mejora del proceso.
9RA.-MA CAPITULO 6: EL PROCESO SOFTWARE l03
En la literatura se pueden encontrar diversos lenguajes y fonnalismos de modelado,
conocidos como "Lenguajes de Modelado de Procesos" (LMP), que tienen como
objetivo representar de una fonna precisa y no ambigua, los diferentes elementos
relacionados con un proceso software. A continuaci6n se describen los diferentes
elementos relacionados con el modelado de procesos, para 10 cual se abordan en primer
lugar los diferentes conceptos comunes relacionados con el proceso software. En el
siguiente apartado se presentan diversos lenguajes 0 metamodelos para la definici6n y
representaci6n de modelos de procesos.
3.1. Elementos del Proceso Software
En general, se puede identificar una serie de conceptos basicos relacionados con
los procesos software (Demiame et al., 1999) y que son comunes a los diferentes modelos
de procesos (v ease figura 6.2):
<> Actividad. Una actividad es una operaci6n at6mica 0 compuesta, 0 un paso de
un proceso. Las actividades se encargan de generar 0 modificar un conjunto
dado de artefactos; incorporan e implementan procedimientos, reglas y
politicas. Ademas, una actividad es un concepto con un cOl11ponente funcional
fuerte ya que acarrea entradas, salidas, y resultados intennedios.
<> Producto. El conjunto de artefactos a ser desarrollados, entregados y
mantenidos en un proyecto es 10 que se denomina producto.
<> Recurso. Un recurso es un activo que una actividad necesita para llevarse a
cabo. En este campo, hay dos recursos de principal importancia: por un lado
los desarrolladores (los agentes humanos en el proceso), y por otro, las
herral11ientas de desarrollo (los agentes computerizados que tradicionalmente
han sido usados en desarrollo del software como editores especializados y
herramientas para la gesti6n, compiladores, etc.) y las herramientas de
prop6sito general (como hojas de ca1culo, editores de diagral11as, etc. que
pueden ser usados para manejar el proceso).
<> Roles y Directivas. Norma1l11ente, las hen;anlientas estan fuertemente unidas a
las actividades en las que son usadas, mientras que los desarrolladores se
relacionan indirectamente a una actividad por medio de sus roles, es decir, el
conjunto de responsabilidades, obligaciones y tareas (por ejemplo disenadores,
jefes de proyecto, revisores, etc.). El caracter de la organizaci6n impacta en el
proceso indirectamente por medio de roles, y tambien directal11ente por medio
de directivas (politicas, reglas, y procedimientos) que gobieman las
actividades. Las directivas nonnalmente vienen en manuales, y por 10 tanto
deberian ser estructuradas.
104 CAUDAD DE SISTEivlAS Il'iFORJvIATICOS RA-MA
Herramienta
Actividad Producto Recurso Organizacion
D D
Figura 6.2. Elementos Basicos de un Modelo de Procesos
3.2. Clasificacion de los Lenguajes de Modelado de Procesos
(LMP)
Existen diferentes critelios para la clasificaci6n de los lenguajes de model ado de
procesos. Los procesos pueden ser modelados en diferentes niveles de abstracci6n y con
diferentes objetivos.
La infonnaci6n de un modelo de procesos se puede estmcturar bajo diferentes
puntos de vista (Curtis et al .. 1992):
e Funcional, que representa que elementos del proceso se estan implementando
y que flujos de infonnaci6n son impprtantes para los elementos basicos del
proceso.
e Compol"tamental, que representa cuando y bajo que condiciones se
implementan los elementos del proceso.
e Organizacional, que representa d6nde y pOl' que persona de la organizaci6n
son implementados los elementos del proceso.
e Informativo, que representa las entidades de infonnaci6n de salida 0
manipuladas pOl' un proceso, incluyendo su estmctura y sus relaciones.
Los diferentes lenguajes de model ado de procesos, proporcionan la notaci6n
necesaria para representar los procesos software y dicha representaci6n puede incluir las
CAPiTULO 6: EL PROCESO SOFTWARE 105
clases de infonnacion comentadas anterionnente. En la tabla 6.1 se resume un buen
l1Lllnero de las propuestas de modelado de proceso existentes, y los aspectos de
informacion que capturan (Acuna et al., 2001).
Otra posible clasificacion de los lenguajes de model ado es la establecida por
McChesney (1995) seg(ill la cuallos procesos se pueden clasificar en:
Descriptivos, cuyo objetivo es desclibir un proceso que se esta llevando a cabo
en una organizacion. Se distinguen dos tipos de modelos descliptivos :
o Informales, cuyo objetivo es proporcionar un modelo cualitativo e
infonnal.
o Formales, que estan relacionados con la evaluacion, mejora y
prediccion de procesos.
Prescriptivos, tienen como objetivo definir los medios necesmios 0
recomendados para la ejecucion de un proceso. Se clasifican en:
o l'vfanuales, que pueden ser estandares, metodologias y metodos
centrados en la gestion, desanollo, evaluacion, ciclo de vida del
software y procesos de soporte al ciclo de vida. Ejemplos de este tipo
de modelos son: metodologias tradicionales estmcturadas,
metodologias orientadas a objetos, metodologias de ingenieria del
conocimiento, estandares de ciclos de vida como ISO 12207.
o Automaticos, que realizan actividades relacionadas con la asistencia,
soporte, gestion y tecnicas de produccion de software asistida por
ordenador. Ejemplo de este proceso es el "Proceso Unificado de
Desanollo" (Jacobson et al., 1999). Ademas este tipo de modelos se
puede clasificar en: orientado a actividades u orientado a personas, en
funcion de los aspectos en los que se centran.
Existen oU'as clasificaciones de lenguajes de modelado, como la que proporciona
Ambriola et al. (1997), en la que se distinguen tres categorias en funcion del nivel de
abstraccion: Lenguajes de Especificacion de. Procesos (Process Specification
Languages, PSL), Lenguajes de Disefio de Procesos (Process Design Languages, PDL)
y Lenguajes de Implementacion de Procesos, (Process Implementation Languages.
PIL). Zamli y Lee (2001) proponen otra clasificacion mas generica y menos centrada en
los PSEE que la anterior, distinguiendose entre LMP:
No ejecutable (Noll-enactable), en la que se incluyen a los LMP que
proporcionan soporte lll1icamente a aspectos de entendimiento y comunicacion
y no a los aspectos de ejecucion.
Simulados (Simulated). que proporcionan una representacion de los procesos
software adecuada para su simulacion a alto niveL que n0l111almente sirve de
106 CAUDAD DE SISTEMAS INFOR.!\LA. TICOS C9 RA-ivLi\
ayuda para el disei'io de los procesos, pero no proporciona detalle suficiente
para la guia y control de ejecuci6n de los procesos.
Ii> Ejecutable (Enactable), que penniten que el modelo de procesos pueda ser
ejecutado para guiar activamente e inc1uso controlar un proceso software.
BASE PERsPEcnv AS DE L'iFORMACION
Funcional
Lenguaje de Programacion Procedural (Ramanathan y SarkaL 1988) Comportamental
Infonnativa
Amilisis y Diseiio de Sistemas. incluyendo Diagramas de Flujo de Funcional
Datos (Frailey. 1991) y tecnicas de amllisis y disello estructurado Organizacional
(McGo\\"an y Bohner, 1993) Infonnativa
y Aproximaciones de [nteligencia Artificial. incluyendo Funcional
las reglas y las pre'post condiciones (Ban!houti et a/ .. 1995) Comportal11ental
Eventos y Disparadores Control de Flujo (Finkelstein et a/ . 1994) COl11portal11ental
Diagral11as de T ransiciones de Estados y Redes de Pea; (Deiters y
Funcional
Gruhn. 1990): (Bandinelli et a/ .. 1995). Diagral11as de Estado
Comportamental
(Kellner y Hansen. 1989): (Kellner. 1991): (Harel y Politi. 1998):
(Raffo y Kellner. 1999)
Organizaciona1
Lenguajes Fllncionales Fonna1es (Curtis et a/ .. ! 992):
Funciona1
(Huff. 1996)
;Vlodelado de Datos. incluyendo diagramas entidadinterrelacion.
Infolmativo
datos estmcturados y declaraciones de re1acion (Penedo y Shu. 1991)
ivlodelado de Objetos (Engels y Groenewegen. 1994) Omanizacional. Infonnativo
Mode1ado Cllantitativo (Abdel-Hamid y {vladnick. 1991) COl11portal11ental
Redes de Precedencia. incluyendo l110delado de dependencias de
C ompoliamental. Organizacional
actores (,{u y Mylopoulos. 1994)
Tabla 6.1. Lenguajes de model ado de procesos y perspectivas de informacion
A continuaci6n se descIiben de fonna general una selie de lenguajes
representatiyos de 111odelado de proceso expresados en fonna de metamodelos de
procesos. En la bibliografia tambien podemos encontrar una gran diversidad de lenguajes
de 111odelado que han sido propuestos en relaci6n con Ento111os de IngenieIia del Software
Orientados al Proceso (PSEE), que se tratan adelante cuando se aborden estos
ento1110S.
3.3. Metamodelos
1
de proceso software
Como se ha explicado anterionnente, para poder gestionar los procesos software de
una organizaci6n es 111UY importante poder definir los 111is1110S de una fO!111a sistematica y
I Es un modele explicito de los constmctores y reglas necesarias para constuir modelos especificos de
un detenninado dominio de interes.
I
(': RA-MA CA.PiTlJLO 6: EL PROCESO SOFTWARE 107
precisa para su posterior ejecuci6n efectiva. En funci6n de los aspectos del proceso a
representar sera necesario incluir unos constructores u ohos y por ella en la literatura se
puede enconhar una gran diversidad de lenguajes para el model ado de los procesos
software. Ello supone la existencia de diversos fOl1nalismos para modelar los procesos
existiendo un alto grade de heterogeneidad. A continuaci6n se describen de f0l111a general
diferentes propuestas de modelado de procesos.
3.3.1. MODELADO DE PROCESOS: DIAGRAMAS DE GANTT Y
DIAGRAMAS PERT
Los diagramas de Gantt fueron creados por Hemy Gantt en el aii.o 1917.
Representan las diferentes actividades de un proceso como banas sobre un calendatio
aportando una representaci6n visual de las actividades, su duraci6n y su planificaci6n. En
la figura 6.3 se presenta un sencillo ejemplo de diagrama de Gantt.
Estuclio Preliminar
2 Ana!lsis de Requisttos
" Diseno
4 (ociifiulci6n
5 PruebEls
Figura 6.3. Diagrama de Gantt
EI metamodelo que representa el diagrama de Gantt es bastante simple y en eI s610
estan incluidos los conceptos de Actividad e Instante de Tiempo (TimePoint).
Jlctjvidad 2
/
2Dias
A::tividad 1
\
1 Dia
Jlctjvidad 3
----+
Jlctjvidad 4
4Dias 3Dias
Figura 6.4. Diagrama PERT
108 C.-\UDAD DE SISTE;V!AS Tleos
Los diagramas PERT (Program Evaluation and Review Techniqlle) representan
grMicamente los procesos mediante un grafo dirigido en el que se incluyen las tareas, su
duraci6n y sus relaciones de precedencia. Son mas dificiles de leer que un diagrama de
Gantt, pero a su vez penniten un analisis mas complejo del proceso, como la
identificaci6n de caminos criticos. En la figura 6.4 se muestra un ejemplo de un diagrama
PERT.
Estos lenguajes de procesos presentados son claros ejemplos de modos de
representaci6n simple, ya que definen el minimo numero de constmctores necesarios.
3.3.2. FORMATO DE INTERCAMBIO DE PROCESOS
EI fonnato de intercambio de procesos (Process Interchange Format, PIF) (Lee et
af., 1998), surge debido a la necesidad de diversas organizaciones (MIT, DEC, Stanford,
etc.) de compartir sus modelos de procesos. Dicha especificaci6n fue propuesta
originalmente en 1993 y desde entonces ha evolucionado y mejorado. EI concepto de
proceso en PIF es "1111 conjzmto de acth'idades COil ciertas relaciolles entre sf y con
objetos ell detenninados Instal/tes de Tiempo". En la figura 6.5 se representa en UrvIL la
jerarquia de entidades que componen elmetamodelo PIF.
Entity
Activity Object TimePoint
Relation
Decision Agent
Creates Modifies Before Uses
Performs
Activity Status Successor
Figura 6.5. Entidades del Metamodelo PIF
Los principales elementos. de acuerdo al metamodelo PIF son: la entidad
Actividad (Actidty) que se define como "cualquier cosa que OCUlTe en el tiempo", como
por ejemplo un proceso. una tarea. 0 incluso un evento; la entidad Relacion (Relation).
que representa la relaci6n entre dos entidades y puede ser de varios tipos, como por
ejemplo la relaci6n creates. que enlaza una actividad con los objetos (Objects) que
CAPiTulO 6: El PROCESO SOFT\VARE 109
produce; los instantes de tiempo (timepoillts) que pueden ser una hora precisa, 0 un
punto del tiempo en el que puede ocurrir un evento; y finalmente la entidad Objeto
(Object), que representa todas aquellas entidades implicadas en un proceso, como
artefactos, helTamientas y agentes.
3.3.3. LENGUAJE DE ESPECIFICACION DE PROCESOS (PSL)
El lenguaje de especificacion de procesos (Process Spectfication Language, PSL)
(Schlenoff et al., 1998) define una ontologia estimdar y un fOl1nato para el intercambio de
especificaciones de procesos de fabricacion. PSL define un proceso como "un conjunto de
actividades en las que patticipan algunos objetos en un instante de tiempo detem1inado".
En PSL los tres constmctores plincipales, a pattir de los cuales se derivan la mayoria de
los elementos de los modelos de procesos, son: actividad (activity), objeto (object) e
instante de tiempo (timepoint). El nuc1eo del lenguaje tambien inc1uye el concepto
oCUlTencia_de_actividad (activio_oclirrence). En la figura 6.6 se representa en UML el
mic1eo del metamodelo PSL.
begin
Object
Timepoint
end
at
participatesjn
in
begin
end
Activity
Figura 6.6. Nlicleo del Metamodelo PSL
En el nllcleo del metamodelo PSL se define la base minima necesaria para la
representacion de modelos de procesos. Esta base minima es extendida mediante modulos
de extension, como por ejel11plo extensiones para el ordenamiento temporal sobre
instantes de tiempo. El lenguaje PSL define de una fonna muy precisa y no ambigua
modelos de procesos mediante axiomas 0 definiciones usando KIF (KnOfl"/edge
Interchange Format). Algunas de estas especificaciones se pueden expresar en el
110 CALIDAD DE SISTEMAS INrORl'vLA.TICOS @RA-MA
metamodelo, pero otras necesitan de mecamsmos mas potentes como OCL (Object
Constraint Language).
3.3.4. MODELO DEL PROCESO UNIFICADO
El modelo del proceso unificado (Unified Process Model, UPM) (Kruchten,
1999) es una propuesta conjunta de organizaciones como IBM, Rational, Unisys, etc.
Este metamodelo de procesos se ha usado para definir el "Proceso Unificado de
Rational", un modelo de procesos de ingenieria del soft,vare comercializado por Rational
Software.
El metamodelo UPM inc1uye seis paquetes que son:
o Nombres (names), en el que se definen los mecanismos de nombrado
o Elementos Basicos (Basic Elements), defme los elementos basicos, que son
refinados en otros paquetes.
o Estructura del Proceso (Process Structure), define los principales conceptos
del proceso, como artefactos (arttfacts) , roles (roles), 0 productos de trabajo
(,\"Ork items).
o Guia (Guidance), define como deberia documentarse cada componente del
proceso.
II> Componentes del Proceso (Process Components), define mecamsmos de
empaquetamiento.
3.3.5. CORE PLAN REPRESENTATION (CPR)
CPR (Pease, 1998) es un metamodelo patrocinado por la agenda DARPA (Defense
Advanced Research Project Agency) y se concentra en la planificacion (especificacion de
un conjunto de acciones para dar sopolte a un conjunto de metas u objetivos) y la
planificacion (especificacion de las cantidades de recursos usadas a 10 largo del tiempo y
el tiempo en que dichas acciones tendran lugar). La base del metamodelo CPR es la
definicion de planes. Un plan (plan) es un conjunto de acciones (actions) necesarias para
satisfacer detenninados objetivos. En la realizacion de una accion un actor puede utilizar
cieltos recursos. El actor de una accion puede ser el recurso de otra accion. En la figura
6.7 se representa en UML el metamodelo CPR.
A pattir del metamodelo CPR es posible modelar el diseiio de un plan, pero no es
posible almacenar la informacion sobre como este plan esta siendo llevado a cabo en la
realidad. Para dar soporte a la ejecucion del proceso se ha aiiadido el concepto de Modelo
del Mundo (WorldModel). Un plan de ejecucion se esuuctura como un plan de diseiio
pero se usa para regisu"ar los resultados de la ejecucion del plan de diseiio.
r RA-ivLI\ CAPiTULO 6: EL PROCESO SOFTWARE III
Pia n
Actio n
Objective
TimeSpec
E va lu a tio n C rite ria
Acto r Resource
Figura 6.7. Metamodelo CPR
3.3.6. DEFINICION DE PROCESO DE LA WORKFLOW MANAGEMENT
COALITION
La coa1ici6n para 1a gesti6n de flujo de trabajo Management
Coalition) es una organizaci6n de vendedores, usuarios, ana1istas y gmpos de
investigaci6n cuyo objetivo es promover e1 uso de sistemas de flujo de trabajo. Esta
coa1ici6n ha propuesto un mode10 de flujos de trabajo de referencia (WfMC, 1998) en e1
que se define un metamode10 de procesos que esta mas orientado en 1a defmici6n de
aspectos de ejecuci6n frente a los aspectos de analisis. En 1a figura 6.8 se representa e1
metamode10 de procesos propuesto por 1a WfMC.
Workflow Process Definition
Workflow Relevant Data Workflow Process Activity
may use
/
from
may use may involve
Workflow Application Declaration to
is performed by
mayuse
Workflow Participant Specification Transition Infotmation
-------------
Figura 6.8. Metamodelo de Definicion de Proceso de la Wfl\;lC
112 CA.UDAD DE SISTEi\1AS INFORIvLA.TICOS :Q RA-IvLA.
De acuerdo a la WfMC el proceso se divide en Actividades del Proceso de Flujo
de Trabajo Process Activities), que pueden ser at6micas 0 podrian estar
compuestas por otros subprocesos. Estas actividades se planifican mediante Infonnacion
de Transicion (Transition b?lormation) sobre Datos Relevantes del Flujo de Trabajo
(Worliflmr Relevant Data). LasaCtividades son realizadas por alguien 0 algo definido por
una Especificacion de Participante del Flujo de Trabajo (WorJ...j7mr Participant
Specification) y pueden invocar Declaraciones de Aplicacion de Flujo de Trabajo
(WorkfloH' Aplication Declaration). Los datos relevantes del flujo de trabajo dan
cobertura a un subconjunto de datos del dominio de aplicacion que son necesarios para
especificar condiciones de h'ansicion 0 precondiciones y poscondiciones de actividad.
3.3.7. ARQUITECTURA DE SISTEMAS DE INFORMACION
INTEGRADOS (ARIS)
El metamodelo Arquitectura de Sistemas de lnfonnacion lntegrados (Architecture
of Integrated b?/o17nation Systems, ARIS) (Scheer, 1998), tiene como objetivo dar soporte
al modelado, analisis y reingenieria de procesos de negocio. De acuerdo a ARIS, un
proceso es un conjunto de Funciones (jzlIlctions) cuyo objetivo es satisfacer Metas
Corporativas (cOlporate goals). Una funcion produce Salidas (outputs) y procesa Objetos
de Infonnacion (bifonnation Objects) tales como eventos y mensajes. El trabajo es
realizado por Unidades Organizacionales (Organizational Units) que incluyen maquinas,
computadores y recursos humanos.
3.3.8. SPEARMINT
SPEARMINT (Becker-Komstaedt et al., 2003) es una herramienta desarrollada por
el Fraunhofer lESE (Institute .lor Experimental Sojhrare Engineering) (vease
w\vw.fraunhofer.de) para describir procesos software. SPEARMINT sopolia la captura,
documentacion, mantenimiento y amilisis de los modelos de procesos software. El
metamodelo (figura 6.9) en el que se basa la herramienta es 10 suficientemente expresivo
para el modelado descriptivo de los procesos.
Como se puede observar en la figura 6.9,las clases que constituyen elmkleo del
metamodelo son: "Entity", "Activity", "Arti/act", "Role", "Resollrce", y "Toof'. Las
asociaciones mas destacadas son: "contains", "consumes", "modifies", "produces", entre
actividades y aliefactos: "involves" enh'e los roles y actividades, "lIses" entre recursos y
actividades, y 'precedes" entre estados, clase absh'acta de la que heredan las actividades y
las bifurcaciones de control (clase JoinSplitState). Las clases "ProdlictFlmrGraph" y
"ControIFlo,rGraph" y sus asociaciones son especificas para elmodelado visual.
En base a este metamodelo, la herramienta proporciona una notacion grafica
similar a UML para la definicion de modelos de procesos. Ademas, de dar sopOlie al
modelado, SPEARMINT proporciona capacidades para el analisis y pel111ite generar guias
(Electronic Process Guide, EPG) y manuales de ayuda al entendimiento del proceso.
[;RA.-MA CAPiTULO 6: EL PROCESO SOFTWARE 113
Figura 6.9. Metamodelo de la herramienta SPEARl'VIINT (Becker-Kornstaedt
et al., 2003)
En la actualidad, las funcionalidades de SPEARMINT han sido integradas en la
herramienta VINCENT (vease http://\'l\\w.iese.fhg.de/Speannint EPGO. que constituye
un nuevo entomo tecno16gico desan'ollado por el tranhoufer lESE para la gesti6n del
proceso software y en el que se inc1uye un repositolio con infonl1aci6n sobre: los modelos
de procesos: los elementos necesarios para dar soporte a aspectos de rendimiento del
proceso (plantillas, listas de comprobaci6n, etc.): y sobre los productos de trabajo
producidos durante el desanollo de los proyectos.
Un ejemplo de definici6n de un modelo de procesos con la helTamienta es
mostrado en la figura 6.10.
114 CAUDAD DE S I S T E ~ l S I]\iFORIviATICOS
::>::':U ,'"isn:?!::,;",
,
I
I
,
I
I
: ,
[ill -----------Ii>
I
~
Designer
@R/\-MA
Figura 6.10. Definicion de una vista de un modelo de procesos con SPEARMINT
(Becker-Kornstaedt et aI., 2003)
3.3.9. PROMENADE
PROMENADE (Franch y RibO, 1999; 2003) es un lenguaje para la modelizacion
de procesos software que utiliza UML para describir sus constmctores, mediante la
generacion de un profile. En la figura 6.11 se representan la extension que PROMENADE
realiza sobre el metamodelo de UML para el modelado de procesos software.
Model (UML)
MetaDocument
I ! MetaRole
I SPMetamod
ModelElement (UML)
Trigger
Figura 6.11. Elementos basicos de PROMENADE (Franch y Ribo, 1999)
' RA-iviA CAPiTULO 6: EL PROCESO SOFTWARE 115
Como se puede observar en la figura 6.11, las clases que componen el nucleo de
PROMENADE son:
e lvfetaDocument, 1\1etaTask, MetaRole, que son consideradas como especializa-
ciones del constructor Clase de UML. Estas tres clases son los constructores
cuyas instancias caracterizan un modelo de procesos software.
e La clase SPMetamod (Software Process Metamodel) es una subclase del
constructor UML Model.
e Las clases Precedence y Trigger son constmctores utilizados para modelar los
aspectos dimimicos de los modelos de procesos.
Las relaciones basicas entre los nuevos constructores definidos en
PROMENADE se ilustran en la figura 6.l2.
imports-modeJs
\
/
/
\ Imported Mod
maintaskMod 0 .. * \
/0 1.'
/ ..
has-as-maintask-cJass
0 .. 1
d
SPMeiamod

model
otherCI
I
I Class(UML) I
I 1 has-as-other-cJass
1
D
<> 1 Cl.", model

"'" 1
model ", has-as-roJes-cJass
has-as-task-CJa/,
'"
"
''-.,
maintaskcl / "
1 .. '
1 1.: has-as-dc cument-cJass "'.
.'-.,"',
rolesCI
0.: I
MetaTask
subtasksCI .
iasksCI
doesCI 1.:
I
I
....---;
I
MetaRole
I i
I I
......
MetaDoeument
I
I
supertaskCI
' ... 1
I
I
0 .. 1
!
'.
""
1
.
has-as-subtasks-cJass

doc
' .
..
consists-of ..
parameters ",
....
1.,* ......
1.:
"
I
Parameter (UML)
I
Figura 6.12. Asociaciones basic as de PROMENADE (Franch y RihO, 1999)
Este lenguaje da soporte al modelado de los procesos software estableciendo dos
vistas fundamentales:
116 CAUDAD DE SISTEMAS INFORMATICOS RA-MA
I Parte estatica, que contiene la defmici6n de los elementos que fonnan parte de
un modelo de procesos software. Las clases fundamentales de este modelo son:
Tarea, Documento, Agente, Herramienta, Recurso, Rol y Comullicaciol1.
I Parte dinamica, que pennite establecer el comportamiento de los procesos
software. Para ello se establecen dos tipos de constmcciones: el control
proactivo, para establecer las precedencias temporales entre las tareas que
llevan a cabo el proceso, y el control reactivo, para describir el
comportamiento del proceso software especificando sus reacciones ante la
oculTencia de eventos. El control pro activo utiliza relaciones de precedencia,
definidas en el marco de UML como una clase especial de dependencia. El
control reactivo se basa en reglas ECA (evento-condici6n-acci6n).
PROMENADE adelmis sopolta la reutilizaci6n de modelos, para 10 cual se
proporcionan los mecanismos de abstracci6n, que penniten desechar detalles de un
modele; y adaptaci6n, para hacer que un modele sea mas especifico 0 preparado para ser
reutilizado.
3.3.10. SPEM
SPEM (Software Process Engineering lvletamodef) es una especificacion de
OMG (2002). SPEM describe un metamodelo generico para la descripcion de procesos
software concretos. Esta basado en MOF y utiliza UML como notacion de modelado. Por
tanto, se basa en los principios de orientacion a objetos. En esta propuesta no se da soporte
a la ejecucion (enactment) de los procesos, es decir, la planificacion y ejecucion de
proyectos usando un modele de proceso descrito con SPEM. Ademas del metamodelo, la
especificacion SPEM tambien esta estructurada como un perfil UML (UiViL profile), es
decir, una vatiante de UML que utiliza los mecanismos de extension de UML en una
fOlma estandar para un proposito particular. Esto pelmite intercambiar definiciones de
procesos, tanto con helTamientas basadas en MOF, como con las basadas en UML.
Como metamodelo. SPEM constituye una plantilla para la creacion de modelos
de procesos concretos, como podrian ser el "Proceso Unificado de DesalTollo de software
de Rational" (RUP) y el modelo de evaluacion y mejora de procesos de ISO 15504. El
modele conceptual de SPEM esta basado en la idea de que un proceso software consiste
en la colaboracion enh'e entidades absh'actas y activas denominadas "roles de proceso"
(process roles) que realizan operaciones denominadas "actividades" (actidties) sobre
entidades tangibles denominadas "productos de h'abajo" ('l'Ork products). EI fundamento
de los procesos software consiste en la interaccion 0 colaboracion de mllitipies roles
mediante el intercambio de productos de trabajo y la ejecuci6n 0 disparo de ciertas
actividades. El objetivo de un proceso es llevar un conjunto de productos de trabajo a un
estado bien definido. En la figura 6.13 se representa en UML este modele conceptual
basico.
~ RA-ivV\ CAPiTl'LO 6: EL PROCESO SOFTIVARE 117
Rol de Proceso = ~ ~ ~ ~ ~ Producto de Trabajo
0 . .*
+entrada 0 . .* 0 . .* +salida
usa produce
0 . .* 0 . .*
Actividad
Figura 6.13. Modelo conceptual basico de SPEM
SPEM especifica el conjunto minimo de elementos necesarios para describir
cualquier proceso software concreto, sin incluir constmctores para areas 0 disciplinas
especificas; de fonna que en SPEM se describe un metamodelo genelico. El objetivo
fundamental de esta especificaci6n es tratar de homogeneizar la diversidad tennino16gica
existente en los lenguajes de modelado de procesos software en los que los mismos
conceptos se tratan con nombres diferentes.
La especificaci6n SPEM esta compuesta por un conjunto de paquetes en los que se
des crib en cada uno de sus elementos. Todos estos paquetes se construyen a partir del
paquete SPElV!_Folllldatiol1, que es un subconjunto de UML 1.4 (OMG, 2001), y el
paquete de extensiones de SPEM (SPElvI_Exlensions_Package), que aflade los
constructores y la semantic a necesaria para la ingenieria del proceso software. El l1lkleo
de la estructura de SPEM esta basado en la del metamodelo de UPM, estando f0l111ada por
5 paquetes: Elementos Basicos (Basic Elements), Dependencias (Dependences),
Estructura del Proceso (Process Structllre). Componentes del Proceso (Process
Componems). y Cicio de Vida del Proceso (Process L)/ecycle).
Como se puede observar en la figura 6.14, en el paquete eSh1.1ctura del proceso se
incluyen los principales elementos estmcturales a' paltir de los cuales se constmye la
desclipci6n de un proceso. Los principales elementos de este paquete son: "Producto de
Trabajo" (WorkProdllct) 0 artefacto, que es cualquier cosa que es producida, consumida 0
modificada por un proceso. Podria ser un fragmento de infonnaci6n, un documento, un
modelo, c6digo fuente, etc; "Definici6n de Trabajo" (TVorkDe/inition) que es una clase no
abstracta de operaci6n que desclibe el trabajo realizado en el proceso. Tiene entradas y
salidas explicitas representadas mediante el constmctor "Parametro de Actividad"
(ActivityParameter); "Actividad" (Acth'ity), que es la principal clase en la que se
especializa Definici6n de Trabajo y desclibe una parte 0 partes de trabajo realizadas por
un rol de proceso tales como las tareas, las operaciones y acciones que un detenninado rol
realiza 0 asiste. Una actividad puede estar fonnada por un conjunto de elementos at6micos
denominados "Pasos" (steps): Realizador del Proceso (ProcessPelfomer) que describe el
lIS CAUDAD DE SISTEMAS INFOR.!'vlATICOS @RA-MA
encargado de realizar lll1 conjunto de "Defilliciones de Trabajo" que componen un
proceso y "Rol del Proceso" (ProcessRole) que es una subclase de Realizador del
Proceso y desclibe las responsabilidades asociadas a los "Productos de Trabajo" junto con
los roles que realizan y asisten en actividades especificas,
Operation
(from Core)
-,uoVio" WorkDefinition
0 .. '
0 .. '
-parer,tWOtk
Activity ..
0 .. '
{ordered}
0 .. "
.... sep
Parameter
(from Cora)
v:';ird Parame!erOirectionKind
ActivityParameter
nas\:ctf.PerA:1Jl a::t :
Classifier
(from Core)
ModelElement
(from Core)
WorkProductKind
0.:
WorkProduct
+perform:. ProcessPerformer
0 .. 1
ActionState
Step
ProcessRole
-:es;::):':sloleRcle (from ActivitjGr<l;)hs)
+asSs.ant
0 .. "
Figura 6.14. SPEM: Paquete Estructura del Proceso
SPEM no dispone de notaci6n gnifica propia, pero al ser un metamodelo basado en
los constructores de U1vlL y al estar definido como profile UML, es posible utilizar
notaci6n UML para representar modelos de procesos, para 10 cual se deben definir los
estereotipos e iconos asociados de los constructores propios de SPENt
Los principales diagramas UML que pueden ser utilizados para representar las
distintas vistas de un proceso software son los siguientes:
o Diagramas de Clases, En el contexte del modelado del proceso software los
diagramas de clases pueden utilizarse para representar: herencia, dependencias,
asociaciones simples, comentarios para asociar elementos de modele a guias
(mediante una uri por ejemplo), relaciones entre realizadores del proceso 0 rol del
proceso y productos de trabajo y la estmctura, descomposici6n y dependencias
entre productos de trabajo, Sin embargo, los diagramas de clases para modelar
RA-NLt\ CAPITULO 6: EL PROCESO SOFTWARE
procesos no pueden incluir interfaces, plantillas, agregaciones simples,
asociaciones cualificadas y asociaciones n-mias. En la figura 6.15 se muestra un
ejemplo de diagrama de clases para representar dependencias entre productos de
trabajo.
:C6digo de
los
Componentes
Producto
/" ~ ,
/ / ' ~ ; d
:Base de
Datos
Fisica
---=
Manual de
Usuario
Figura 6.15. Ejemplo de Dependencias entre productos de Trabajo representadas con un
diagram a de clases
En la figura 6.16 se muestra un ejemplo en el que mediante un diagrama de clases
se ilustra la relaci6n enh'e productos de trabajo y roles del proceso:
Figura 6.16. Ejemplo de Dependencias entre productos de Trabajo y Roles de
Proceso representadas mediante un diagrama de clases
120 CAUDAD DE SISTD.L-\S INFOR,'vlATICOS :9 R,-\-MA
e Diagramas de Paquetes. Los diagramas de paquetes penniten ia representaci6n
de: procesos, componentes de procesos, paquetes de proceso y discipiinas. En ia
figma 6.17 se muestra un ejempio de representaci6n de un proceso y sus
discipiinas asociadas.

o:<Clzci;;line::>::>
?rtP..<oas
Figura 6.17. Ejemplo de un Proceso y sus asociadas representado
con un Diagrama de Paquetes UML
Arquttecto
clel
Sistema
Realizar
MOdelos
Sfstema
Realizar
Modelns
Usuario
Figura 6.18. Ejemplo de un Diagrama de Casos de Uso para representar Actividades y
los Roles de Proceso asociados
f RA.-ivV\ CAPiTlJLO 6: EL PROCESO SOFTWARE 121
G Diagramas de Casos de Uso. Los diagramas de casos de uso se pueden utilizar
para representar la relaci6n entre los Roles del Proceso y las Definiciones de
T rabajo. En la figura 6.18 se muestra un ejemplo de utilizaci6n de los diagramas
de casos de uso para representar las actividades de una definici6n de trabajo y los
roles que asisten en su realizaci6n.
G Diagramas de Secuencia. Los diagramas de secuencia se pueden utilizar para
ilustrar la interacci6n entre instancias de elementos de SPEM.
G Diagramas de Transicion de Estados. Se utilizan para representar el
comportamiento de elementos de modelado SPEM, como, por ejemplo, los
estados y transiciones que representan el comportamiento de un detenninado
producto de trabajo. Cuando se utiliza este tipo de diagrama para modelado de
procesos el paralelismo y anidamiento estan pemlitidos, pero no se pueden
utilizar indicadores de historia y declaraciones de sefiales. En la figura 6.19 se
representa el compOltamiento de una actividad mediante un diagrama de
transici6n de estados en el que se especifican los pasos que componen la
actividad y su flujo de control.
Initial
State
Revisar el Trabajo
realizado en el
Proceso y las
Definiciones de
Clases
Revisar los
Modelos de l!lterfaz
deUsuario
/"" <Step>
Realizar If.lejorar eJ
Prototipo
Final State
Figura 6.19. Ejemplo de Diagrama de Transicion de Estados para representar la
Actividad "Revisar los Modelos de Usuario"
(i) Diagramas de Actividad. Los diagramas de actividad representan en el contexto
del model ado de procesos la secuenciaci6n de las actividades del proceso, asi
como los productos utilizados por dichas actividades y los roles responsables. En
la tlgura 6.20 se muesh'a un ejemplo de diagrama de actividad.
3.3.11. SMSDM
El metamodelo SMSDM (Standard jvletamodel for Sojhrare De\'eloplIIent
Methodologies) (Henderson-Sellers y Gonzalez-Perez, 2004; Standards Australia, 2004)
establece un marco de trabajo para la definici6n y extensi6n de metodologias de desalTollo
de sofuvare. incluyendo sus h'es aspectos principales: el proceso a seguir, los productos
uti liz ados y generados y las personas implicadas.
Este metamodelo esta basado principalmente en los metamodelos: SPEM y OPF
(OPEN Process FrameH'ork) para los COnShlJctores directamente relacionados con el
122 C\UD.-'l.D DE SISTEMAS INFOR\I.'\ TIeos &: RA-MA
modelado de procesos software, OOSPICE para la evaluaci6n de la capacidad de procesos
y LiveNet para sistemas de trabajo colaborativo basado en computador (Compllter-
Supported Collaborative Work, CSCW). SMSDM combina los anteriores metamodelos
para dar soporte no ll11icamente al modelado del proceso en si, sino tambien a los
productos y a la evaluaci6n de la capacidad tanto en el contexto del desalTollo de software
como de sistemas CSCW.
Apflcaciones
Antiguas \
Inicio
Bahoraeion del
Modelo de Datoll (p.
DT.AYD.10l
I
',
'i
\
'i
\
\
:Cat4logo
de
Req1iiSltos
Proyaeto
------------r-----
Diseiio de fa
Arqulteclura de
MOdulos del Sistema
(P.DT.AYD.20) \
Generacion de
A Especfficaciones l
J ; de Construccioll (P- \
DT-AYD.3tJ) \
:Cuallernos
!IeCarya
Figura 6.20. Ejemplo de Diagrama de Actividad
Espeemeaeion del Fin
Plan de P[!mbas
iP.DT-AlJD.40i
I
Las plincipales caracteristicas del metanlodelo SMSDM se pueden resumir en las
siguientes:
@ Facilita la instanciaci6n del metamodelo en fonna proyectos. Ello se debe a
que no s610 se proporciona un metamodelo, como OCUlTe en muchas oU'as
propuestas, sino ademls se inc1uyen las guias necesarias para instanciar el
metamodelo en fonna de proyectos. Para ello se utilizan "pOl rertypes" , que
pem1iten representar en el mismo modelo los elementos de metamodelado y
sus instancias (elementos concretos de una metodologia).
@ Integran los aspectos del proceso y del modelado en un unico metamodelo
para la definici6n de metodologias. Mienu'as que propuestas como SPEM U
CAPiTULO 6: EL PROCESO SOFTWARE
OOSPICE descliben los aspectos de proceso de las metodologias, estandares
como UML descliben los aspectos de modelado.
I El metamodelo incluye constructores especificos para modelar la cap acid ad
de los procesos definidos. Esta es una dimension muy significativa que puede
afectar a las metodologias definidas, y por tanto, debe ser considerada a nivel
de metamodelo.
El metamodelo SMSDM ha sido definido utilizando tres tipos de instrumentos
complementalios:
I Definiciones de cada concepto en lenguaje natural.
I Diagramas de Clases UML, en los que los conceptos son representados como
clases, y se muestran ademas sus atributos y relaciones.
I Equivalencias con otras propuestas. Cada concepto de SMSDM es relacionado
con conceptos equivalentes 0 similares en otras propuestas y enfoques.
En la figura 6.21 se representan en UML las clases que constituyen el micleo de
SMSDM. En el nivel mas alto de abstraccion SMSDM define las clases
lvlethodologyElement y ProjectElemellt para representar los elementos a nivel de
metodologia y a nivel de proyecto, respectivamente. Como se puede apreciar en la figura
6.21 entre las subclases de estos elementos existe una relacion basada en p01\"ert)pes
(representada mediante un pequeno circulo que parte del elemento de metamodelado y
conecta con una linea discontinua el elemento a nivel de modelo), ya que representan
elementos de distintos niveles de abstraccion. Los aspectos temporales del proceso son
representados con las clases StageKilld y Stage, los aspectos de trabajo mediante las clases
WorkUnitKind y vVorkUnit que representan operaciones cohesivas realizadas durante un
proyecto. Por otro lado los artefactos obtenidos 0 utilizados son modelados mediante las
clases FVorkProdllctKind y WorkProdlict. Las clases ActiollKind y Action representan el
acto especifico de utilizar un detenninado producto de trabajo por algunos tipos de
unidades de trabajo (workunits). Los roles son l11odelados mediante las clases
ProducelKind y Producer que son los responsables (nonnalmente humanos) para llevar a
cabo ciertas acciones. Finalmente, las clases ivlodelUflitKind y Model Un it representan los
bloques basicos de conshuccion de productos de trabajo y ModelUnitUsageKind y su
c1ase asociada a nivel de modelo Model Unit Usage representan usos especificos de una
detenninada unidad de modelo (modelunit) en un producto de h"abajo.
Por otro lado, la c1ase recurso se especializa en: Language, que representa un
conjunto interrelacionado de model unit kinds que pueden utilizarse para conshuir ciertos
modelkinds; Notation (un conjunto de artefactos, nonnalmente graficos, mas reglas de
usa, que pueden utilizarse para representar productos de h'abajo); Guideline (reglas y
directivas sobre el uso apropiado de un detenninado elemento de una metodologia);
Constraint (una condicion relacionada a la ejecucion de una accion) y Outcome (un
resultado visible del rendimiento de un detenninado producto de trabajo).
124 CAUDAD DE SISTEMAS INFOIUvlA. TlCOS 3RA-MA
En la figura 6.21 se representa la parte del l11etal110delo SMSDM donde se
l11uestran las relaciones entre las clases basicas dell11etamodelo WorkUnit y Stage:
!ModeIUnitUsase-Kind'
! ...
I Notatio-o
,,"",,"0
On
Figura 6.21. Nlicleo de SMSDM (Henderson-Sellers y Gonzalez-Perez, 2004)
Como se puede apreciar en la figura 6.21, los aspectos de proceso son modelados
mediante la inclusion de las clases WorkUllitKind, StageKind y sus respectivos subtipos.
H'orkUnitKind es especializado en un cohesivo pero heterogeneo
de tare as que persiguen una serie,de objetivos. La unidad rmis simple de trabajo es la tarea
(T askKilld) que utiliza detenninadas tecnicas (TeclllliqZleKind) para conseguir sus
objetivos. WorkUnitKind tambien se caracteriza pOI' su prop6sito (purpose), su nivel
minimo de capacidad al que puede ser realizado (lvlinCapabilityLet'el) y los resultados
esperados (outcomes). POI' su parte, en relacion a StageKind se distinguen dos tip os de
etapas: con duraci6n (Stage,\'ithDurationKind) y sin duracion 0 instantanea
(instantaneolisStageKind). A su vez, StageWithDZlrationKind es especializada en distintos
constructores mas concretos, como L[f'eCycleKind, que representa el proceso seguido en
un proyecto. 0 PhaseKind, que representa una etapa de larga duraci6n realizada con un
detem1inado enfoque y nivel de abstracci6n denu'o de un proyecto.
0.' I Con!oxt
CornpOfliHl!
0.'
ICumpmWI11
0'
,Contexl
0 .. '
,
I
,
,
I
I
I
I
_ . ~ I
I T,,,k -I
US05 ~
I
I
I
I
I
I
I
I
I
I
0.:
,
I
I
I
I
I
I
__ . ___ ~ _
0'
~
SL_ ~ ~ ____ _
0:
,Con!m(j
Figura 6.22. RCpl'cscntaci{H1 dc los Aspcctos dc Proccso con SMSIlM (Hcndcrson-Scllcrs y Gonzalcz-Pcrcz, 201M)
{lil
~
?
;;;
n
2;;
:::r
:;;
o
'"
tT1
r
"tJ
6
n
m
(f)
o
(f)
o
::q
~
,'-'
v,
126 CAUDAD DE SISTE;VIAS INFORM.A.TICOS .1;) RA-MA
La relaci6n entre proceso y producto es representada mediante la clase ActionKind
que es siempre realizada en el contexto de una detemlinada tarea y que se lleva a cabo
sobre un detenninado producto de trabajo (WorkProdllctKind). Esta relaci6n se muestra
en la figura 6.23.
-Cause
Performs.
+Effact
ActsUpcr
WorkProductKind
1..'
.----,
-C.::lUGO
Performs.

A:rsUpcn '" .-SU::;jC::
WorkProduct I
1--____ .,'-----------j ___ -j------------j+Creat<):lDate
1.:
+Lasl:hangeDaie
+Status
Figura 6.23. Relaci6n entre Proceso y Producto en SMSMD (Henderson-Sellers y
Gonzalez-Perez, 2004)
AChtalmente el metamodelo SMSDM ha sido aceptado como estindar en Australia
(Standards Australia, 2004) y esta siendo sometido a votaci6n para su aprobaci6n como
estandar ISO.
4. ENTORNOS DE INGENIERiA DEL SOFTWARE
ORIENTADOS AL PROCESO
4.1. Introducci6n y Caracteristicas
La Tecnologia de Procesos Software ha expel;mentado un intenso trabajo
investigador desde que, a finales de los afios 80, Leo Ostelweil imparti6 una charla
invitada en la conferencia intemacional leSE (International COI?j"erence on Sofhmre
Engineering) cuyo tihtlo fue "Sofhmre processes are sofhvare too" (Osterweil, 1987).
Este trabajo fue el inicio de una nueva fonna de abordar los procesos software, en el que
los modelos que representan los aspectos del proceso son ejecutados y controlados con la
ayuda de un entomo tecnol6gico denominado Entomo de Ingenieria del Software
Orientados al Proceso (PSEE).
RA.-i'.L-\ C-\piTULO 6: EL PROCESO SOFTWARE 127
Los PSEE dan soporte a los procesos de ingenielia, usados para concebir, diseilar.
desanollar y mantener un producto software. a traves de un mode10 de procesos explicito
definido mediante un LMP adecuado. Los modelos asociados a un PSEE especifican
como las personas deb en interachIar y trabajar, y tambien como y cmindo las helTamientas
utilizadas en el proceso deben ser utilizadas y/o activadas autolmiticamente. Un elemento
clave del ent0l110 10 constiruye el motor del proceso (process engine) que es el encargado
de guiar y ayudar a las personas a la hora de llevar a cabo las distintas actividades del
proceso, y automatiza la ejecucion de las actividades que no requieren intervencion
humana. El motor de procesos esta constiruido por los siguientes elementos (Cugola y
Ghezzi, 1998):
(i) Un Interprete del Modelo de Procesos, ejecuta el modelo controlando las
henamientas usadas durante e1 proceso, guiando a las personas participantes y
velificando que se satisfacen las restricciones especificadas en e1 mode10
(como por ejemp10 e1 orden de ejecucion de cieltas actividades).
(i) Un Entorno de Interaccion del Usuario, constihlido por las henamientas que
uti1izan los usuarios, como pueden ser editores, compi1adores, agendas,
henamientas de gestion de proyectos, etc. Estas henamientas son contro1adas
por e1 interprete, que las utiliza para recibir realimentacion de los usuarios y
darles soporte durante e1 proceso.
(i) Un Repositodo. gestiona la infol111acion que es persistente en e1 ent0l110.
Almacena los artefactos producidos durante el proceso y que son gestionados
pOl' el entol110, como pueden ser archivos de codigo fuente. documentacion.
ejecutables, casos de prueba. infol1nes, etc. Tambien se incluye toda la
infol111acion del estado achlal del proceso que esta siendo ejecutado.
Basado en los elementos anteriores se ha desanollado un modelo de referencia y
una propuesta arquitechlral para ent0l110S PSEE en general (Fugetta et at.. 1999). De
acuerdo a este modelo de referencia, un PSEE esta controlado por un motor de procesos,
cuyo objetivo es controlar el flujo de infol111acion entre los desanolladores de acuerdo al
modelo de procesos. El modelo es almacenado en un repositorio, junto con la definicion
del producto e infol111acion relevante sobre el estado del proceso. Ademas del repositorio,
existen otro nivel de memoria importante fOl1nado por los espacios de trabajo, que son
conjuntos de recursos infol1naticos que los desarTolladores utilizan cuando desempel'ian
un detel1ninado rol en cierta actividad 0 tarea. Un PSEE tambien tiene que tener la
capacidad para compartir datos con el exterior mediante canales de
importacioniexportacion, que per111itan el intercambio de productos y modelos en un
fOl1nato de comunicacion reconocible. En la figura 6.24 se resumen los componentes
esenciales de este modelo de referencia. La linea discontinua desde el motor de procesos a
la capa de comunicacion indica que el motor de procesos controla el PSEE esencialmente
controlando el flujo de infol111acion entre el repositorio y los espacios de trabajo, entre
unos espacios de trabajo y otros, y entre los usuarios y sus espacios de trabajos.
128 CAlID.AJ) DE SISTEMAS INFORJvlA TICOS RI\-JvV\
4.2. Clasificaci6n de los PSEE
En primer lugar cabe destacar que to do PSEE esta caractelizado por el LMP que
utiliza. Como se ha descrito en el apartado anterior, existe una gran multitud de LMPs y,
en el contexto de los PSEE, los LMPs utilizados pueden adoptar alguno de los siguientes
cuatro enfoques (Cugola y Ghezzi, 1998): Lenguaje Basado en la Progr,amaci6n,
consistentes en extender lenguajes de programacion existentes introduciendo conceptos
relacionados con el proceso software, como es el caso de APPLI A (Heimbigner et aI,
1990) que es una extension de Ada; Basados en Reglas, caracterizados por el uso de
reglas de produccion para describir los procesos software en los cuales las actividades se
des crib en mediante reglas f0l111adas por precondiciones, acciones y postcondiciones. Estas
reglas tienen asociados roles encargados de realizarlas y recursos necesarios como por
ejemplo henamientas. Ejemplos representativos de estos lenguajes son ManJel and
Merlin; Basados en Aut6matas Extendidos, como Diagramas de Estados 0 Redes de
Petri, fonnalismos que fueron extendidos para proporcionar una notacion mas expresiva
de los procesos software. Ejemplos de estos lenguajes son Leu y Process Weaver que estan
basados en Redes de Peni; Multiparadigma, que combinan dos 0 mas paradigmas para
describir los distintos aspectos de un proceso software. SPADE (Bandinelli et al., 1993) es
un ejemplo de este tipo, en el que su esnuctura Plincipal esta basada en Redes de Peni,
proporciona un modelo de datos orientado a objetos para describir atiefactos y utiliza un
lenguaje operacional para describir las acciones asociadas a las n'ansiciones definidas.
Usuarios
Usuarios

"
.
A
"

Producto, <ill ..
Modelo de
Capa de Comunicaci6n
Motor de
Procesos
Procesos y
...
<ill
Repositorio de
.
Procesos
j.
J. A
'f
"
Canales de
importacion
Espaciode
Espacio de
y exportacion
Trabajo
Trabajo
Vf
Figura 6.24. Arquitectura Funcional de un PSEE
RA-MA CAPiTULO 6: EL PROCESO SOFTWi\RE 129
Otro de los aspectos clave de los PSEE es el tipo de soporte que ofrecen a los
usuarios, distinguiendose entre cuatro posibles tipos (Bandinelli et aI., 1996):
III Rol Pasivo. El usuario guia el proceso y el PSEE opera en respuesta a las
peticiones del usuario.
III Guia Activa. El PSEE guia el proceso y pregunta al usuario cuando es
necesario, recordandoles en todo momento que actividades debedan realizar.
Los usuarios son libres para decidir y realizar las acciones sugeridas por el
entomo.
III Obligacion. El PSEE fuerza a los usuarios a actuar tal y como se ha
especificado en elmodelo de procesos.
III Automatizacion. El PSEE ejecuta las actividades Slll intervencion de los
usuarios.
Un mismo PSEE puede adoptar distintas fom1as de soporte al usuario, como por
ejemplo adoptar el enfoque de automatizacion para actividades que no requieren la
intervencion de los usuarios y el de obligacion para el resto.
Tambien es posible clasificar los PSEE en funcion de la fonna de controlar y guiar
el proceso. En este caso se distingue entre PSEE Proactivos, en los que el entomo inicia y
controla las operaciones realizadas por las personas y Reactivos en los que el entomo
queda subordinado a los usuarios.
En las ultimas dos decadas se han propuesto una gran diversidad de PSEE, entre los
que se pueden destacar los siguientes (Hanison et al., 1999), (Cugola y Ghezzi, 1998),
(Demiame et al., 1999): Adele (Belkhatir et al., 1991), APS (Balzer y Narayanaswamy,
1993), Arcadia (Taylor et aI., 1988), EPOS (Comadi et aI., 1994), HFSP (Katayama,
1989), Marvel (Kaiser et aI., 1990), Merlin (Junkermann et al., 1994), OIKOS
(Montangero y Ambriola, 1994), SPADE (Bandinelli et aI., 1993), GOODSTEP
(Emmerich et al., 1993), MELMAC (Deiters y Gmhn, 1990). Oz (Ben-Shad y Kaiser,
1994), PCTE (Boudier et al., 1988). Sin embargo, la repercusion industrial de estos
entomos ha sido minima, quedando en un plano 'meramente investigador a nivel de
prototipos. Solo algunos entomos han sido comercializados como es el caso de IPSE 2.S
(Warboys, 1990), SynerVision (HewlettIPackard Company, 1993), y ProcessWeaver
(F emstrom, 1993). Una comparativa de muchos de estos entomos es proporcionada por
Arbahoui et al. (2002).
A pesar de los grandes avances en la investigacion de los PSEE, la gran mayoda no
ha tenido la aceptacion industrial esperada. Una de las causas mas sigr1ificativas ha sido el
enfasis que los PSEE han dado a la descripcion de modelos de procesos como modelos
nonnativos cuyo seguimiento debia ser estricto. Ell0 Oligino PSEE muy dgidos que se
adaptaban mal a la naturaleza de las organizaciones, aspecto especialmente cdtico hoy en
dia en el que el mercado es muy dinamico y altamente competitivo (Demiame y Oquendo,
130 CALlD.-\D DE SISTEMAS !l\FOR..\IATICOS ; R..-\-MA
2004). Por otro lado, muchas de las propuestas incluyen LMP muy complejos y poco
intuitivos que ha dificultado su uso por los profesionales que prefieren lenguajes mas
intuitivos y que les facilite su comunicacion y entendimiento del proceso (Fugetta, 2000).
Todo ella ha OIiginado una importante reflexion en la comunidad investigadora siendo
algunos requisitos y retos importantes para el futuro los siguientes (Arbaoui et aI., 2002):
e EI PSEE debe dar soporte dimimico a la ordenacion de actividades. Si la
ordenacion de las actividades puede ser elaborada y modificada
dinamicamente. el motor de reificacion del PSEE debe ser capaz de continuar
apoyando y asistiendo durante la realizacion del proceso. Un aspecto clave son
las interacciones de los humanos con el PSEE. El PML y el PSEE (como
sopol1e del PML) deberian pel1nitir cierta flexibilidad que les pel1nita ser tltiles
dentro de la estrategia adoptada pOl' una compai'iia, que puede ir desde un
estlicto y disciplinado proceso "dirigido por el plan" hasta un proceso
completamente libre don de "la desviacion es la n0l111a".
e EI PSEE debe dar soporte a la distribucion de procesos software, 10 cual
comprende la modulmidad, heterogeneidad, interoperabilidad y
componibilidad de procesos y la federacion de fragmentos de proceso.
Tambien implica que el PSEE debe ser capaz de dar sop0I1e a la comunicacion,
coordinacion. cooperacion y negociacion entre los usuarios realizadores con
sus diferentes roles.
e EI PSEE debe dar sop0I1e a la evolucion de procesos software: tanto
evolucion como "all-line". En este caso deben tenerse en cuenta las
consecuencias en los procesos que estan en curso y en los que ya han
sobrepasado el punto de cambio en el modelo. Los PSEE tambien deben dar
sop0I1e a la evolucion privada: el cambio sera local a la instancia de modelo de
proceso que se esta ejecutando. sin impactar ni en elmodelo reificado ni en el
modelo en si mismo. Las desviaciones del proceso respecto del modelo deben
ser sop0I1adas y negociadas. y su impacto debe ser gestionado.
4.3. Ejemplos de PSEE
En este apartado se ilustran las caracteristicas de los PSEE mediante la presentacion
de algunos ejemplos representativos de la bibliografia.
4.3.1. SPADE
El ent0l110 SPADE (Bandinelli et aI., 1993; 1995: 1996) es un PSEE disefiado en la
Universidad Politecnica de Milan que proporciona soporte al anaJisis, disefio y ejecucion
(enactment) de los procesos software. Para el modelado de los procesos utiliza el
f0l111alismo SLANG (SPADE Language), que es un LMP basado en una extension de
Redes de Petri a alto nivel. En SLANG un proceso se descIibe como una jerarquia de
actividades. Cada actividad puede incluir interacciones con usumios/helTamientas y
\"' R:\.-MA
acceso a datos del proceso. Existe un interfaz de la actividad "Run Tests". que es invocada
por la actividad "Test jVfodule Collection". "Run Tests" tiene dos transiciones simples de
entrada y salida, denominadas, respectivamente "Start Test'" y "End Test", dos lugares de
entrada (""Executable Module" y "Ready Test Cases") y un lugar de salida ("Final Test
Results "). En la parte derecha de la figura se ilustra una posible implementaci6n para la
actividad en la que se representa como un m6dulo ejecutable (executable module) que es
ejecutado repetidamente. cada vez con un detenninado caso de prueba (ready test cases).
Los resultados de cada ejecuci6n se comparan con los resultados esperados y el resultado
de la comparaci6n se afiade a los resultados de prueba acumulados. Cuando se han
ejecutado todas las pruebas la actividad tennina.
Las actividades y estados de actividad en SLANG son representados como redes
de Petli, mientras que los datos del proceso se representan como tokens. Un modelo de
procesos en SLANG esta compuesto basicamente por los siguientes elementos:
e ProcessT)pes, que es un conjunto de definiciones de tipos organizadas de
fonna jerarquica de acuerdo a un estilo 00. En SLANG todos los datos del
proceso son caracterizados como tipos y organizados en jerarquias de herencia.
El elemento raiz es el tipo ProcessData, del que heredan el resto de tipos.
8 ProcessActivities. es un conjunto de definiciones de actividad. Una definici6n
de actividad es una red de Petri a alto nivel donde se incluyen lugares (places),
arcos (acs) y transiciones (transitions). Cada lugar tiene un nombre y un tipo y
se compOlta como un repositorio que ll11icamente contiene tokens de su tipo 0
cualquiera de sus sUbtipos. Los lugares pueden cambiar sus contenidos como
consecuencia de transiciones de disparo (fire transitions). Un caso particular
son los lugares de inteliaz de usuario, que se representan mediante circulos
dobles y son lugares que pueden cambiar sus contenidos como consecuencia de
la intervenci6n humana. Se utilizan para transferir eventos extemos causados
por humanos. Las transiciones representan eventos cuya oculTencia sup one una
cantidad de tiempo despreciable y llevan asociadas una condici6n de guarda y
una acci6n. La condici6n de guarda es un predicado sobre los tokens que
peltenecen a los lugares de la transici6n de enh'ada y se usa para decidir si se
dispara la transici6n. EI compOltamiento dinamico de una transici6n se
desclibe mediante las reglas de disparo. Cuando se dispara la transici6n se
ejecuta la acci6n asociada y los tokens de entrada pasan a los lugares de salida.
La invocaci6n de helTamientas en SLANG se modela mediante "h'ansiciones
negras" (black transitions). en las que la acci6n es la invocaci6n de una rutina
ejecutable (ejemplo un fichero ejecutable en UNIX). La ejecuci6n se lleva a
cabo de fonna asincrona. Los arcos en la red pueden llevar asociados pesos
(por defecto el valor es 1). EI peso indica el numero de tokens que fluyen tras el
disparo de una hansici6n. Este peso puede ser definido de fonna estcitica 0
dinamica sefialada mediante un caracter "*,, en cuyo caso se establece en
tiempo de ejecuci6n y puede valiar en el tiempo. Aparte del tipo nOlTnal de
arco, SLANG establece dos tipos especiales para mejorar la entendibilidad:
132 CAUDAD DE SISTEMAS INFORJvlA-TICOS '9 R A i v l ~
read-on(l', para conectar arcos a transiciones y overwrite para conectar
transiciones a lugares.
EI entomo SPADE proporciona soporte multiusuario y pennite el paralelismo entre
actividades, mediante la asociaci6n de cada actividad conCUlTente con diferentes motores
de proceso (instancias del intel-prete SLANG) que pueden estar distribuidos en una red de
estaciones de trabajo. Las helTamientas son integradas en el entomo y su invocaci6n es
descrita en el modelo de procesos. Los datos del proceso (incluyendo los propios
modelos) son almacenados en un repositorio gestionado por un SGBD Olientado a
objetos. SPADE esta tambien constituido por un entomo de interacci6n del usuario, que
gestiona la interacci6n entre los usuarios y las helTamientas. Este entomo de interacci6n
esta basado en DEC (Digital Equipment Corporation) FUSE (Friend(v Unified Software
Environment), que facilita la integraci6n entre helTamientas, para 10 cual ofrece una serie
de servicios que pueden ser invocados a traves de intelfaces de programaci6n que definen
protocolos para facilitar la cooperaci6n entre henamientas. En resumen, la arquitectura de
SPADE esta constituida pOl' tres elementos fundamentales (vease figura 6.25):
e EI Entorno de Interaccion de Usuario. fonnado pOI' instancias de DEC
FUSE.
e Un Filtro, denominado SCI (SPADE Communication Intel.iace), que
constituye el subsistema de comunicaci6n y pem1ite conectar los motores de
proceso con las instancias de DEC FUSE.
e EI Entorno de Ejecucion del Proceso, que contiene los motores de proceso
(instancias de intel-pretes SLANG) y el repositorio.
En SPADE, de acuerdo a su arquitectura, cuando un usuario se conecta al sistema,
se crea un nuevo servidor de mensajes que se conecta al SCI y el usuario interactlla con un
intelfaz de control que Ie pennite ejecutar helTamientas y configurar su propia instancia
FUSE a traves de la cual va participar en la ejecucion del proceso de acuerdo a sus
responsabilidades.
4.3.2. APEL
APEL (Dami et al., 1998; Estublier et al., 1998: 2003) es un PSEE desan'ollado en
el Laboratoire Logiciels, Systemes, Reseallx, en Francia. Los objetivos fundamentales que
persigue se basan en dar soporte ala:
I. Interoperabilidad entre PSEE heterogeneos, pel111itiendo al disefiador del
proceso construir una "federacion" de PSEE (Estublier et aI., 2003) capaces de
gestionar procesos complejos y distribuidos.
2. Evolucion del Proceso, con el fin de hacer frente a situaciones imprevistas
durante la ejecuci6n.
o RA-:VLA.
Usuario 1
Entomo de Interaccion del Usuario
Servidor de Mensajes
FUSE
Servidor de Mensajes
FUSE
8
Cliente 02
Usuario n
Filtro
Interfaz de
Comunicaci6n
SPADE
C!lente 02
Servidor 02
Entomo de Ejecucion del Proceso
(Process Enactment Environment PEE)
8
Clients 02
. BBDD
00
Figura 6.25. Arquitectura de SPADE
Para dar soporte a la federacion de PSEE existentes, APEL adopta una arquitectura
mixta basada en dos arquitecturas basicas: arquitectura basada en controL en la que las
interacciones entre los PSEE se produce mediante llamadas a rutinas de proceso, en la que
cada PSEE es una entidad autonoma que encapsula solo la parte del proceso del que es
responsable. En esta arquitectura existe un supervisor de PSEE que gestiona el modelo de
procesos COl11lll1 a todos los PSEE y en el que se expresa el orden relativo de ejecucion de
los subprocesos que tienen que llevarse a cabo por otros PSEE: arquitectura basada en
estados, en la que cada PSEE compm1e una representacion COI11Lll1 del estado del proceso
global de f0111m que la interaccion entre PSEE es implicita (no se realizan nunca llamadas
directas entre PSEE). Cada PSEE de la federacion puede l110dificar su estado local 0
cambial el estado COmlll1 como resultado de variaciones en su estado local.
134 CAUDAD DE SISTE'.IAS lNFOR{>'IATICOS QRA-'.IA
La arquitectura basica del ent0l110 APEL (Dami et ai., 1998) se ilustra en la figura
6.26.
APEL tiene dos fonnas de representaci6n del proceso: gnifica, destinada a
usuarios finales del proceso y para desclipciones del proceso a alto nivel y textual, para
usuarios avanzados y henamientas. Como se puede apreciar en la figura 6.26, la
arquitectura consiste basicamente en:
III Un editor gnifico para capturar y modelar procesos.
III Un traductor de la representaci6n grafica en textual.
III Un compilador de la representaci6n textual a un fonnalismo ejecutable.
III Un estado comun, que mantiene el estado actual del proceso en ejecuci6n y de
las entidades creadas durante la ejecuci6n.
Un conjunto de servicios que varian desde serVlClOS de interfaz de usuano a
servicios de control.
Para dar soporte a la interoperabilidad entre distintos PSEE la arquitechlra basic a
de APEL ha evolucionado para incorporar los siguientes elementos adicionales (Eshlblier
et al., 1998):
III Metamodelo Comun, para facilitar el intercambio de infonnaci6n y
entendimiento de los distintos PSEE de la federaci6n.
III Modelo de Procesos Comun.
III Servidor del Proceso, que en tiempo de ejecuci6n contiene el modelo de
procesos y la reificaci6n de todas las entidades creadas por el proceso en
ejecuci6n. Su intelfaz pennite a los componentes crear cualquier entidad y
cambiar de fonna arbitraria el proceso actual, asi como el modelo. Este es el
aspecto basico que da soporte a la evoluci6n del proceso en APEL.
III Servidor de Eventos, que captura y gestiona todos los eventos (tal y como se
han definido en el modelo de procesos 'tomllIl).
III Motor Comun del Proceso, que en funci6n de los eventos que recibe del
servidor de eventos se encarga de la ejecuci6n del modelo de procesos comllIl
asegurando que se cumple la semantica del proceso del servidor del proceso.
III Modelo de Interoperabilidad, que recibe peticiones de los motores de
proceso en fonna de evento y transfonna si es necesario, esos eventos en
peticiones a otros servidores de proceso. Tambien se encarga de garantizar la
consistencia en la federaci6n.
Campiladorl
Interprete _______ -'-_____ _
Motor del
Proceso
Saporte en Tiempo de Ejecuc!6n
Metodos Built-In
jyietoaos de Usu8no
Herramlentas de Usuario
Modelo
Principal
_ ______ v_
Servicios de
Ejecuci6n
Figura 6.26. Arquitectura Basica de APEL
El entomo APEL recibe su nombre del lenguaje de modelado utilizado: Abstract
Process Engine Langllage. Los conceptos basicos del fom1alismo APEL para elmodelado
de los aspectos estaticos son: actividad, producto y agente. Estos elementos pueden tener
estados, que vaIian como consecuencia de transiciones que se disparan debido a la
ocurrencia de eventos. La noci6n de estado y evento constituyen el nllcleo de los aspectos
dinamicos del metamodelo APEL. En APEL, los ~ s p e t o s dinamicos del proceso son
descIitos mediante:
e El flujo de control, que representa las actividades y las reglas que pem1iten su
ejecuci6n y ordenaci6n en el tiempo. Describe los aspectos relacionados con la
secuenciaci6n de las operaciones y la interacci6n entre operaciones
concurrentes.
e El flujo de datos, muestra c6mo los productos fluyen a traves de las
actividades que los producen, u'ansfonnan 0 consumen. De este modo, un flujo
de datos conecta la salida de una actividad a la enu'ada de otra actividad y
representa un estado de datos intennedio dentro de un proceso.
136 CAUDAD DE SISTEMAS INFO&vlA TlCOS @ RA.-ivLA.
e Diagramas de Estados (State Diagrams, SD), que son definidos para un
producto, agente 0 actividad y representan la evolucion de dichos elementos en
el tiempo as! como los eventos y condiciones que producen los cambios de
estado.
COlllroi:flolr
5D
Figura 6.27. Representacion en APEL de flujos de control, flujos de datos y diagram as de
estados (Dami et al., 1998)
En la figura 6.27 se muestra un ejemplo en el que se pueden apreciar como se
representan gnificamente en APEL las actividades. flujos de datos y control y diagramas
de estados.
4.3.3. SERENDIPITY
Serendipity (Grundy y Hosking, 1998) lOonstituye un ejemplo muy representativo
de la influencia e importancia de los entomos de soporte al trabajo colaborativo
(Computer-Supported Cooperative Work, CSeW) en los PSEE.
Este PSEE integra el modelado de procesos y el soporte al trabajo cooperativo para
dar sopOIte a gI'andes sistemas de naturaleza colaborativa. Para ello. proporciona un nuevo
lenguaje gnlfico de modelado de procesos que pen11ite tanto el modelado descriptivo de
procesos indicando el trabajo a realizar, as! como una extension que pen11ite modelar los
eventos que intervienen en la ejecucion del proceso.
Como lenguaje de modelado Serendipity usa EVPL ().:tended Visual Planning
Language), que es una extension del lengIlaje VPL (Swenson. 1994), que preserva la
RAYLA. cAPIn.JLo 6: EL PROCESO SOFTIV.-\RE 137
nocion de "planes de trabajo" (H'ork plans) pero afiade capacidades especificas para dar
soporte al modelado de procesos genericos. De este modo EVPL puede ser utilizado para
modelar, desde modelos de procesos de trabajo genericos y reutilizables, hasta planes de
trabajo concretos para lill proyecto en particular. Algunas novedades que incorpora EVPL
son: identificadores de proceso, para mejorar la entendibilidad y las referencias entre
modelos; representaciones para elementos relevantes del modelo como los roles,
aliefactos y henamientas y conexiones de "uso" entre etapas del proceso y
representaciones de roles artefactos y henamientas. La figura 6.28 muestra un ejemplo de
un modelo de procesos representado con EVPL, que representa la definicion del
subproceso "modificaciones del disefio" en el que se muestran las actividades (stages) a
realizar, sus dependencias temporales y los roles y henamientas necesarios.
@
miW

X

{;!)
I=:J

[EJ

m 1 :modell -roles
ml . 1 :
:'if""
'J';"''; (,r)
igfl
.....

rR
'''It-
",dit,;
t"lk,; with
rR d"',;ign
fI..:>dif i",,; (U)
... ,J;.. .. )
r orm:f;u i Id",,-
(A)

ml .2 :
(.f) . ..
. ....
u,;.::,;
, .. "dif i",; (U)
. ..... .
:IJ!.
ml .:3 : t",;t.::r

Figura 6.28. Ejemplo de EVPL (Grundy y Hosking, 2003)
Los elementos de EVPL descritos hasta el momenta solo penniten la descripcion
estcitica de un modelo de procesos en los que linicamente se incluyen flujos de
"ejecucion" entre actividades. Sin embargo, es necesario especificar por ejemplo
138 CAUDAD DE SISTEMAS IN"FORIvlA TIeos RA-MA.
dependencias entre etapas del proceso que pertenecen a distintos modelos, eventos de
modificaci6n de artefactos y de invocaci6n de herramientas, asi como reglas y
restricciones de los modelos. Para ella EVPL incorpora constructores especificos, basados
fundamentalmente en los conceptos de "filtros" y "acciones", que reciben eventos de
etapas del proceso, artefactos, herramientas, roles u otros filtros y acciones.
Una vez definido el modelo de procesos en Serendipity, este puede ser ejecutado
por los usuarios para un detenninado proyecto en cualquier momento. Los procesos en
ejecuci6n pueden ser modificados en cualquier momento con el fin de extender y mejorar
la propia especificaci6n del proceso. Un modelo de procesos es ejecutado mediante la
selecci6n de la etapa del proceso a ejecutar a traves del interfaz de usuario del entomo. El
usuario tambien debe especificar el motivo de la ejecuci6n y si la etapa del proceso tiene
defmidos submodelos de procesos, se debe indicar la etapa de comienzo. Una vez iniciada
la ejecuci6n por el usuario, el entomo envia un evento de ejecuci6n (enactment) a la etapa
del proceso a ejecutar, que a su vez envia eventos de enactment a todas sus etapas
conectadas. Cuando se ha completado el trabajo asociado a dicha etapa del proceso 0 un
subproceso se producen eventos de finalizaci6n iniciandose la ejecuci6n (en funci6n del
tipo de conexi6n) de las siguientes etapas.
En la figura 6.29 se muestra un modelo de procesos que esta siendo ejecutado. Las
etapas que aparecen sombreadas son aquellas que estan en ejecuci6n (sin haber finalizado
alm). De la misma fonna los flujos de eventos que han activado alguna etapa tambien
aparecen destacados en el modelo, mientras que la etapa actual sobre la que el usuatio esta
trabajando es destacada en negrita. La intelfaz del entomo facilita al usuatio seleccionar
cualquier etapa a ejecutar y visualizar una lista de las etapas que ha ejecutado.

OO:@
: ;;;;;i:::
. 22/3/1996 11: 45: IS j cb.... l>'t::lrt.-:.d this :;''::"::9-1:. -,.,.i'th " :1::: dc,.!'< igrl
"I _ 2.213/1996 11:4'5:49 jOM this :;t:::tge with" .:;:top fi:tin
Ii O,ew i) (Rdd
Conte!!t ) ( Undo
l Delete 1
( Redo 1 l Cancel J
Figura 6.29. Ejemplo de Modelo en Ejecucion (Grundy y Hosking, 2003)
CAPiTULO 6: EL PROCESO somv ARE 139
Para dar soporte al trabajo colaborativo en Serendipity, las vistas de los modelos de
procesos pueden ser compartidas entre los desarrolladores de forma sincrona, semi-
sincrona y asincrona. La edici6n sincrona usa la metMora del espacio de trabajo
compartido en el que todos los usuarios comparten los mismos datos y las vistas de estos
datos son editadas sincronamente usando un enfoque "10 que tll ves es 10 que yo veo". En
la forma de edici6n asincrona, cada usuario tiene una versi6n alternativa del modelo de
procesos la cual modifican independientemente de otros usuarios. Los usuarios pueden
exportar su alternativa al espacio de trabajo compartido de forma que los usuarios pueden
mezclar dos 0 mas altemativas para producir una nueva versi6n. En la forma de trabajo
semi-sincrona, los cambios hechos por un usuario son enviados a otros usuarios de interes
mediante dialogos y vistas de forma que estos usuarios puedan elegir si incorporar esos
cambios en sus modelos.
Para facilitar el trabajo colaborativo, Serendipity ha sido integrado con pequenas
herramientas CSCW, que proporcionan facilidades de edici6n de notas, mensajeria,
conversaci6n y comunicaci6n en general entre las personas que interacruan con el entomo.
o Cugola, G. y Ghezzi, e. Sofnmre processes: a retrospective and a path to the
jiltllre, Sofnmre process - Improvement and practice, vol. 4, pp. 101-123,
1998. Este articulo presenta las caracteristicas de los principales enfoques que
se han seguido en la investigaci6n de los procesos software a 10 largo de la
his tori a, identificando sus puntos fuertes y debiles, asi como los aspectos a
mejorar que pennitan seguir avanzando en el futuro.
o Derniame J.e., Wastell D., Kaba A. (eds) (1999). Sofnvare Process:
Principles, Methodology and Technology, LNCS N1500, Springer Verlag,
January 1999. Este libro proporciona al lector una panoramica completa del
campo de los procesos software enfocada en las tecnologias de proceso
software, y mas concretamente en los Entomos de Ingenieria del Software
Olientados al Proceso y los Lenguajes de Modelado de Procesos que Ie dan
soporte.
o Fuggetta, A. (2000). Sofnvare Process: A roadmap. Proceedings of the 22th
International Conference on Sofuvare Engineering, Limerick (Ireland), pp. 25-
34. Este articulo presenta de fonna general la historia en la investigaci6n del
proceso sofuvare, evaluando de fonna critica los logros obtenidos y las
direcciones en las que se deben enfocar los trabajos futuros.
o Proceedings of the European Workshop on Sofnvare Process Technology
(EWSPT). Lecture Notes in Computer Science. http://w\vw.infonnatik.uni-
El workshop constituye la referencia europea mis
importante en la investigaci6n en tecnologias de proceso Sofuvare. Este
workshop fue iniciado en el ano 1991 bajo la denominaci6n "Workshop
140 CAUDAD DE SISTEvU\S fNFORc\l'\ TICOS
Europeo sobre Modelado de Procesos Software", nombre que fue cambiado en
el ano 1992 por el actual.
" Revista NOV ATICA. MOl1ografia sobre Teenologia de Proeeso Sofhrare.
Ruiz, F. y Canfora, G. (eds). Ntllnero 171, Septiembre-Octubre 2004. Versi6n
en ingles UPGRADE: The European Journal for Informatics Professional. En
http://w\vw.upgrade-cepis.onv'issues/2004/5/upQ:rade-vol-V -5 .html. Este nu-
mero especial de la Revista NovaticalUpgrade presenta una monografia sobre
la tecnologia de los procesos software.
6. EJERCICIOS
1. Representar el proceso de METRICA 3 "Planificaci6n
Informaci6n" (vease http://w.\vw.csi.map.es/csi/metrica3D
siguientes Lenguajes de Modelado de Procesos:
a. Diagrama de Gantt.
b. Diagramas de Actividad UML.
c. SPEM (Software Process Engineering Metamodel).
de Sistemas de
utilizando los
(,Que lenguaje de los utilizados anterionnente proporciona mayor expresividad
para representar dicho proceso?
2. Realizar una busqueda bibliografica para analizar la influencia que tienen los
sistemas de h'abajo cooperativo basado en computador (CSCW) en los Entornos
de Ingenieria del Software Orientados al Proceso.
3. Analizar la influencia de la tecnologia de los Procesos de Negocio, y en particular
de los Sistemas Gestores de Flujos de Trabajo en los Procesos Software,
incluyendo un ejemplo de aplicaci6n.
4. Realizar un ejemplo en el que se aplique uno de los Entornos de Ingenieria del
Software Orientado al Proceso analizados en este capitulo para un caso particular
de Proceso Software.
5. (,Cuai ha sido ia evoiuci6n en ia tecnoiogias de procesos software hasta nuestros
dias? (veanse lecturas recomendadas).
CAPITULO 7
MODELOS DE PROCESO DE
CICLO DE VIDA
.. Una vida illlitil es lIna mllerte prematura "
Goethe
1. CONCEPTO DE CICLO DE VIDA
Uno de los problemas IU:is importantes en cualquier depaItamento de sistemas de
informacion es definir un marco de referencia comun que pueda ser empleado por todas
las personas que participan en el desaITollo de los sistemas, y en el que se definan los
procesos, las actividades y las tareas a desarrollar.
A 10 largo de la historia se han propuesto diferentes paradigmas 0 ciclos de vida
para el software: desde el ciclo en cascada, pasando por el modelo en espiral de Boelun,
hasta los mas recientes ciclos de vida orientados al objeto, como el ciclo de vida fuente
(Piattini et aI., 2003).
Las organizaciones profesionales y los organismos intemacionales se han venido
ocupando del ciclo de vida del sofuvare, tanto IEEE como ISOIlEC han publicado normas
tituladas, respectivamente, "IEEE Standard for Developing Software Ltfe C.vcle
Processes" (Estandar IEEE para el Desarrollo de Procesos del Ciclo de Vida del
Sofuvare) (IEEE, 1995, 1998c), e "Information technology - Software ltfe-cycle
processes" (Proceso del ciclo de vida sofuvare) (ISO, 1995a; ISO, 2002a, 2004e). La
nonna ISO 12207 entiende por modelo de ciclo de vida "lin marco de referencia que
contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la
explotacion y el mantenimiento de un prodllcto de softlvare, abarcando la vida del
sistema desde la definicion de los requisitos hasta la Jlnalizacion de Sll lISO". Por otro
142 CAUDAD DE SISTEMAS INFOIUvl;\TICOS
lado, la nonna ISO 15288 (ISO, 2003) define cicio de vida de los sistemas como "fa
evofllcion en ef tiempo de lin sistema de inten?s desde su concepcion hasta su retirada",
destacando que un modelo de cicio de vida es "un marco de procesos y actividades
relativas af cicio de vida que actlia tambibl como una referencia comzin para fa
cOlllllnicacion y ef entendimiento".
El cicio de vida abarca, por tanto, toda la vida del sistema, comenzando con su
concepcion y finalizando cuando ya no se utiliza. A veces tambien se habla de "cicio de
desarrollo", que es un subconjunto del anterior y que empieza en el amilisis y finaliza con
la entrega del sistema al usuario.
A continuacion se resumen los principales estandares relacionados con los ciclos
de vida propuestos por las nonnas ISO 12207 y 15288.
2. PROCESOS DEL CICLO DE VIDA SOFTWARE
En la nonna ISO 12207, las actividades que se pueden realizar durante el cicio de
vida del software se agrupan en procesos principales, procesos de soporte y procesos
generales (de la organizacion), vease figura 7.1, as! como un proceso que pennite adaptar
el cicio de vida a cada caso concreto.
Hay que destacar que la nonna no fomenta 0 especifica ningtin modelo concreto
de cicio de vida, gestion del software 0 metodo de ingenieria, ni prescribe como realizar
ninguna de las actividades.
2.1. Procesos principales
Los procesos principales son aquellos que son titiles a las personas que inician 0
realizan el desarrollo, la explotacion 0 el mantenimiento del software durante su cicio de
vida. Los procesos plincipales son:
e Proceso de adquisicion. El propos ito ,de este proceso es obtener el producto 0
servicio que satisface la necesidad expresada por el cliente. Este proceso consta
de cuatro subprocesos: preparacion de la adquisicion, seleccion de proveedor,
supervision del proveedor y aceptacion del cliente.
e Proceso de suministro. Este proceso proporciona un producto 0 servicio al
cliente que satisface los requisitos acordados.
e Proceso de desarrollo. El proposito de este proceso es transfonnar un
conjunto de requisitos en un producto 0 sistema bas ado en sofuvare que
satisface las necesidades planteadas por el cliente. Debido al interes que tiene
este proceso, se resumen a continuacion sus principales subprocesos:
(; RA.-lvLA CAPITULO 7: MODELOS DE PROCESO DE CICLO DE VIDA 143
PROCESOS PRINCIPALES
ADQUISICION
SUMINISTRO
DESARROLLO
. EXPLOT ACION
MANTENIMIENTO
PROCESOS ORGANIZACIONALES
GESTION
INFRAESTRUCTURA
MEJORA
RECURS OS HUMANOS
GESTION DE ACTIVOS
GEST. PROG. REUTIUZACION
INGENIERiA DE DOMINIO
PROCESOS DE SOPORTE
DOCUMENT ACION
GESTION DE LA CONFIGURACION
ASEGURAMIENTO DE CAUDAD
VERIFICACION
VAUDACION
REVISION CONJUNT A
AUDITORiA
GEST. RESOLUe. PROBLEMAS
USABIUDAD
..............
EV ALUACION DE PRODUCTO
GEST. PETICIONES DE CAMBIO
PROCESODE
ADAPTACION
Figura 7.1. Procesos del cicio de vida software segun ISO 12207
o Elicitacion de requisitos, cuyo objetivo es recopilar, procesar y seguir la traza
de las necesidades y requisitos del cliente a 10 largo del ciclo de vida del
producto 0 servicio, as! como establecer una linea de configuraci6n (baseline)
que sirva como base para definir los productos de trabajo necesarios.
o Analisis de requisitos del sistema, cuyo objetivo es tranSf0l111ar los requisitos
definidos por los participantes 0 implicaClos (stakeholders) en un conjunto de
requisitos tecnicos del sistema deseado que guianln el disefio del sistema.
o Disefio arquitectonico del sistema, euyo objetivo es identificar que requisitos
del sistema que deben ser ubicados en los elementos del mismo.
o Analisis de los requisitos del software, euyo objetivo es estableeer los
requisitos de los elementos de software del sistema.
o Disefio del software, cuyo objetivo es proporcionar un disefio para el software
que implemente los requisitos y pueda ser velifieado respecto a los mismos.
o Construccion del software, cuyo objetivo es produeir unidades de software
ejecutable que reflejen apropiadamente el disefio del software.
144 CALIDAD DE SISTEMAS INrORM.ATICOS :&:RA-MA
I Integracion del software, cuyo objetivo es combinar las unidades de software
produciendo elementos de software integrados, consistentes con el disefio
software, que demuestra que se satisfacen los requisitos funcionales y no
funcionales sobre una platafonna equivalente 0 completa.
I Prueba del software, cuyo objetivo es confinnar que el producto sofuvare
integrado satisface los requisitos defmidos.
I Integracion del sistema, cuyo objetivo es integrar los elementos del sistema
(incluyendo elementos sofuvare, elementos hardware, operaciones manuales, y
otros sistemas) para producir un sistema completo que satisfaga el disefio del
sistema y las expectativas de los clientes expresadas en los requisitos del
sistema.
I Prueba del sistema, cuyo objetivo es asegurar que la implementaci6n de todos
los requisitos del sistema se prueba para la confonnidad y que el sistema esta
listo para entre gar.
I Instalacion del software, cuyo objetivo es instalar el producto sofuvare que
satisface los requisitos acordados en el entomo objetivo.
I Proceso de operacion. Este proceso incluye la operaci6n del producto
software en su entomo final y proporcionar soporte a los clientes del mismo.
Consta de dos subprocesos: usa operacional y soporte al cliente.
I Proceso de mantenimiento. Este proceso incluye la modificaci6n de un
sistema 0 producto sofuvare despues de la entrega para cOl1'egir los fallos,
mejorar el renditniento u otros atributos, 0 adaptarlo a un entomo modificado.
Esta modificaci6n 0 la retirada de los productos existentes debe hacerse
preservando la integridad de las operaciones organizacionales.
2.2. Procesos de soporte
Estos procesos sirven de apoyo al resto y se aplican en cualquier punto del ciclo
de vida. Los procesos de soporte son los siguientes:
I Proceso de documentacion. Este proceso sirve para desaITollar y mantener la
infonnaci6n sofuvare registrada producida por un proceso.
I Proceso de gestion de la configuracion. Este proceso sirve para establecer y
mantener la integridad de todos los productos de trabajo de un proceso 0
proyecto y hacerlos disponibles para las partes involucradas.
RA.-MA CA.piTlJLO 7: MODE LOS DE PROCESO DE CICLO DE VIDA 145
e Proceso de aseguramiento de la calidad. Este proceso asegura que los
productos de trabajo y los procesos cumplen las previsiones y planes
predefinidos. En la tabla 7.1 se reflejan los resultados de este proceso segllI1 el
estandar ISO 12207.
--7 Se desarrolJa una estrategia para lJevar a cabo el aseguramiento de la cali dad
--7 Se produce y mantiene evidencia del aseguramiento de la calidad
--7 Se identifican y registran los problemas y/o no confonnidades con los requisitos
acordados
--7 . Se veri fica el cumplimiento por parte de los productos. procesos y actividades de los
estandares, procedimientos y requisitos aplicables
Tabla 7.1. Resultados del proceso de aseguramiento de la caUdad segun ISO 12207
e Proceso de verificacion. Este proceso sirve para confinnar que todos los
productos de trabajo y/o servicios software de un proceso 0 proyecto reflejan
de fonna apropiada los requisitos especificados.
e Proceso de validacion. Este proceso sirve para confinnar que se cumplen los
requisitos para el uso pretendido del producto de trabajo software.
e Proceso de revision conjunta. Este proceso sirve para mantener un
entendimiento COmllI1 entre las diferentes partes involucradas sobre el progreso
respecto de los objetivos del acuerdo y 10 que debe hacerse para ayudar a
asegurar el desanollo de un producto que satisface a las partes involucradas.
Estas revisiones conjuntas se dan a 10 largo de toda la vida del proyecto tanto a
nivel de gesti6n del proyecto como a nivel tecnico.
e Proceso de auditoria. Este proceso pemlite detenninar, de fonna
independiente, la confonnidad de los productos y procesos seleccionados con
los requisitos, planes y acuerdos.
e Proceso de gestion de la resolucion de problemas. Este proceso pennite
asegurar que todos los problemas descubiertos se identifican, analizan,
gestionan y controlan hasta su resoluci6n.
e Proceso de usabilidad. Este proceso pennite asegurar que se consideran los
intereses y necesidades de las partes involucradas con el fin de pennitir la
optimizaci6n del sopOlte y de la fonnaci6n, la mejora de la productividad y
calidad del trabajo, la mejora de las condiciones de trabajo de las personas y la
reducci6n de la probabilidad de rechazo del sistema por parte del usuario.
e Proceso de evaluacion de productos. Este proceso pennite asegurar,
mediante el examen y la medici6n sistem<iticos, que un producto satisface las
necesidades implicitas y explicitas de los usuarios de ese producto.
146 CALlDAD DE SISTElvt\S Il'lFORl\1A. TICOS RA-MA
e Proceso de gestion de las peticiones de cambio. El prop6sito de este proceso
es asegurar que las peticiones de cambio son gestionadas, sometidas a
seguimiento y controladas.
2.3. Procesos organizacionales
Se emplean para establecer, implementar y mejorar la organizaci6n consiguiendo
ser mas efectiva. Se llevan a cabo nonnalmente a nivel organizativo, fuera del ambito de
proyectos y contratos especificos.
e Proceso de gestion. Este proceso persigue organizar, monitOlizar, y controlar
el inicio y el desempefio de cualquier proceso para conseguir sus objetivos de
negocio de la organizaci6n. Este proceso sirve para asegmar la aplicaci6n
consistente de practicas para la organizaci6n y los proyectos. Estas practicas
son inherentes a la gesti6n de una organizaci6n pero deben concebirse para ser
instanciadas para cada uno de los proyectos. Debido al interes que tiene este
proceso para la gesti6n de la calidad, se resumen a continuaci6n sus principales
subprocesos:
e Alineamiento organizacional, cuyo objetivo es asegmar que los procesos
software necesarios para la organizaci6n para proporcionar productos y
servicios software, sean consistentes con los objetivos de negocio.
e Gestion organizacional, cuyo objetivo es establecer y llevar a cabo las
practicas de gesti6n del sofuvare que sean consistentes con los objetivos de
negocio de la organizaci6n, dmante la realizaci6n de los procesos necesarios
para proporcionar productos y servicios sofuvare.
o Gestion de proyectos, cuyo objetivo es identificar, establecer, cOOldinar y
monitOlizar las actividades, tareas y recmsos necesarios para que un proyecto
produzca un producto y/o servicio en el contexte de los requisitos y
reshicciones del proyecto.
o Gestion de calidad, cuyo objetivo es conseguir la satisfacci6n de los c1ientes,
monitorizando la calidad de los y servicios, a nivel organizacional y
de proyecto, con el fin de asegmar que estos satisfacen los requisitos de los
c1ientes. En la tabla 7.2 se reflejan los resultados de este proceso seglin el
estandar ISO 12207.
o Gestion de riesgos, cuyo objetivo es identificar, gestionar, analizar y controlar
los riesgos de fonna continua, tanto a nivel organizacional como tecnico.
o Medicion, cuyo objetivo es recopilar y analizar datos relacionados con los
productos desanollados y los procesos implementados en la organizaci6n y sus
proyectos, para sopOliar la gesti6n eficaz de los procesos y demoshar de fonna
objetiva la calidad de los productos.
RA-ivlA CAPiTULO 7: MODElOS DE PROCESO DE CIClO DE VIDA 147
-7 Se establecen objetivos de cali dad basados en requisitos de calidad implicitos y
explicitos definidos por el c1iente
-7 Se desarrolla una estrategia global para conseguir los objetivos definidos
-7 Se establece un sistema de gesti6n de calidad para implementar dicha estrategia
-7 Se realiza, y se confim1a el desempefio, de las actividades de control y aseguramiento
de la calidad identificadas
-7 Se monitoriza el desempefio real respecto a los objetivos de calidad
-7 Se toman las acciones oportunas cuando no se logran los objetivos de cali dad
Tabla 7.2. Resultados del proceso de gestion de calidad segun ISO 12207
e Proceso de infraestructura. Este proceso pennite mantener una
infraestructura fiable y estable necesaria para soportar el desempeiio de los
o1:ros procesos. Esta infraestructura puede incluir hardware, software, metodos,
henamientas, tecnicas, estandares y facilidades para el desanollo, operacion 0
mantenimiento.
e Proceso de mejora. Este proceso sirve para mejorar de fonna continua la
efectividad y eficiencia a u'aves de los procesos utilizados y mantenidos de
fomm alineada con las necesidades de negocio. Las fuentes de infom1acion que
pueden proporcionar las entradas para el cambio son: resultados de valoracion
de procesos, auditorias, infonnes de satisfaccion del cliente,
eficiencialefectividad organizacional, coste de la calidad. El estado actual de
los procesos podria detel1ninarse mediante el proceso de valoracion. Se
compone de u'es subprocesos: establecimiento de procesos, valoracion de
procesos y mejora de procesos.
e Proceso de recursos humanos. Este proceso sirve para proporcionar a la
organizacion los recursos humanos adecuados y mantener su competencia,
consistente con las necesidades de la empresa. Este proceso incluye tres
subprocesos: Gestion de Recursos Humanos, FOl1nacion y Gestion del
Conocimiento.
e Proceso de gestion de activos. Este proceso sirve para gestionar la vida de los
activos reutilizables desde su concepcion hasta su retirada.
e Proceso de gestion del programa de reutilizacion. Este proceso sirve para
planificar, establecer, gestionar, conu'olar y monitorizar el programa de
reutilizacion de una organizacion y explotar de fonna sistematica las
oportunidades de reutilizacion. Las partes afectadas podrian incluir a los
adminisu'adores del programa de medicion, gestores de activos, ingenieros del
dominio, desanolladores, encargados de operacion y encargados de
mantenimiento.
148 CAlIDAD DE SISTEMAS INFORM .. A. TICOS :g RA-ivL-'I.
e Proceso de ingenieria de dominio. Este proceso sirve para desalTollar y
mantener modelos de dominio, arquitecturas de dominio y activos para el
dominio.
2.4. Proceso de adaptacion
Este proceso sirve para realizar la adaptacion basic a de la nonna ISO 12207 con
respecto a los proyectos de software. Como se sabe, las variaciones en las politicas y
procedirnientos de la organizacion, los metodos y estrategias de adquisicion, el tamano y
complejidad de los proyectos, los requisitos de sistema y los metodos de desaITollo, entre
otros, influencian la fonna de adquirir, desalTollar, explotar 0 mantener un sistema (vease
figura 7.2).
OTRAS ENTRADAS
TIEMPO
-
DINERO
I--
I REQUISITOS
I
LEY
SEGURIDAD
I SEGURIDAD FislCA
CREDENCIALES
(ISO 9001, ..... )
CAPACIDAD DE LA r--
ORGANlZACION /"
MANUAL DE
CAUDAD
I PROCEOIMIEI'HOS
ESTANDAR
DE
PROCESOS
DE CICLO DE
VIDA DEL
SOFTWARE
ISO/IEC
APLlCACfON
ADAPTACfON
EVALUACION
PRUEBAS
ETC.
MODELOS Y METODOS
b\
D
CASCADA
/
METODOS
ENTORNO
MATRIZ DE RESPONSABILIDADES
AOQ sm.1 DES
Figura 7.2. Ejemp\o de aplicacion de la norma ISO 12207
En el estandar IEEE (1998d) se dan recomendaciones sobre como registrar datos
del cicio de vida resultantes de los procesos del cicio de vida del estandar IEEE (1998c).
Estos datos tienen que dar soporte a las siguientes acciones:
(;'RA-MA CAPiTULO 7: );lODElOS DE PROCESO DE CIClO DE VIDA 149
e Describir y registrar infoDnacion sobre el producto software durante su ciclo de
vida.
e Dar soporte a la usabilidad y mantenibilidad de un producto software.
e Definir y controlar los procesos del ciclo de vida.
e Comunicar informacion sobre el sistema, producto 0 serVlClO software y
proyecto a quien 10 necesite.
e Proporcionar la historia de 10 sucedido durante el desan-ollo y mantenimiento
para dar soporte a la gestion y mejora de procesos.
e Proporcionar evidencia de los procesos que se han seguido.
e Asistir la planificacion logistica (replicacion, distJibucion, instalacion,
fODnacion) para un producto software.
e Proporcionar historia sobre los cambios de los datos.
Identificar. planificar y programar las actividades de aseguramiento de la cali dad para el
proceso 0 producto.
Identificar estandares. metodologias. procedimientos y herramientas para llevar a cabo
las actividades de aseguramiento de la cali dad y su adaptaci6n al proyecto.
Identificar los recursos y las responsabilidades para la realizaci6n de las actividades de
aseguramiento de la calidad.
Establecer y garantizar la independencia de los responsables de llevar a cabo las
actividades de aseguramiento de la calidad.
Realizar las actividades identificadas de aseguramiento de la calidad en consonancia
con los planes. procedimientos y programaciones releYantes.
Aplicar los sistemas de gesti6n de cali dad organizacionales ai proyecto.
Tabla 7.3. Objetivos del proceso de aseguramiento de la calidad segun IEEE (1998a)
Estos datos del ciclo de vida deben ser no ambiguos, completos, velificables,
consistentes, modificables, tJ'azables, presentables (recuperables y visibles), seguros y
privados, protegidos, con-ectos y adecuados. Debetian tener contenido relativo a datos de
requisitos, datos de disefio, datos de prueba, datos de configuracion, datos de usuatio,
datos de gestion y datos de calidad. Estos ultimos abarcan planes y procedimientos de
calidad, estado de las acciones con-ectivas, analisis de causas raices, caracteristicas de
calidad del producto y datos de medici ones de proceso, y critelios y fundamentos para las
dccisiones clave.
En la tabla 7.4 se presenta el contenido del plan de asegurat11iento de calidad de
software.
ISO CAUDAD DE SISTEMAS IN"FORMATICOS R A N L ~
---? Infonnaci6n de un plan generico para el aseguramiento de la calidad del software.
---? Estandares de calidad, metodologias, procedimientos y herramientas para llevar a cabo
las tareas de aseguramiento de la calidad (0 las referencias correspondientes de la
organizaci6n en su documentaci6n oficial.
---? Procedimientos para la identificaci6n, co\ecci6n, clasificaci6n y disposici6n de los
registros de calidad.
---? Recursos, programaciones y responsabilidades para dirigir las actividades de
aseguramiento de cali dad.
---? Actividades y tareas seleccionadas a partir de los procesos de soporte, tales como
Verificaci6n, Validaci6n, Revisiones Conjuntas, Auditorias y Resoluci6n de Problemas.
Tabla 7.4. Contenido del plan para el aseguramiento de la calidad
En el estandar se dan guias para el contenido de las descripciones, planes,
procedimientos, registros, infonnes, peticiones, especificaciones, etc. Se dan guias
especificas sobre el contenido de los planes de adquisici6n, peticiones de modificaci6n,
descripciones de disefio de bases de datos, planes del proceso de desarrollo, de
mantenimiento, descripci6n de arquitectura software, etc.
3. PROCESOS DEL CICLO DE VIDA DE SISTEMAS
De fonna amlloga a la nonna ISO 12207 para el software, en la nonna ISO 15288
se presentan los principales procesos del cicIo de vida de los sistemas agrupados en cuatro
categorias:
Ell Procesos de acuerdo, que incIuyen los procesos de adquisici6n y suministro.
Ell Procesos empresariales, que incIuyen: el proceso de gesti6n del entomo
empresarial (cuyo objetivo es definir y mantener las polfticas y procedimientos
necesarios para las actividades de la organizaci6n), gesti6n de la inversi6n
(cuyo objetivo es iniciar y mantener suficientes y adecuados proyectos con el
fin de conseguir los objetivos de la organizaci6n), gesti6n de los procesos del
cicIo de vida de sistemas (cuyo objetivo es asegurar que se encuentran
disponibles para ser utilizados por la organizaci6n procesos efectivos de cicIo
de vida del sistema), gesti6n de recursos (para proporcionar recursos a los
proyectos), gesti6n de la calidad (la nonna establece que el prop6sito del
proceso de gesti6n de cali dad es "asegurar que los prodllctos, servicios e
implementaciones de los procesos del ciclo de vida clIInplen los objetivos de
calidad de fa empresa)' logran la satisfaccion del cliente"; en la tabla 7.5 se
resumen las actividades que presenta este proceso).
Ell Procesos de proyecto, que se utilizan para establecer y hacer evolucionar
planes de proyecto, valorar los logros actuales y el progreso respecto a los
planes y controlar la ejecuci6n del proyecto hasta su culminaci6n. Dentro de
este apartado encontramos los procesos de planificaci6n de proyectos,
f:RA-lvL\ CAPiTULO 7: lvlODELOS DE PROCESO DE CIClO DE VIDA 151
evaluacion de proyectos, control de proyectos, torna de decisiones, gestion de
riesgos, gestion de configuracion y gestion de infonnacion.
-+ Establecer politicas, estandares y procedimientos de gesti6n de la calidad
-+ Establecer objetivos de gesti6n de la calidad de la organizaci6n basados en la estrategia
empresarial para la satisfacci6n del cliente
-+ Definir las responsabilidades y autoridades para implementar la gesti6n de la cali dad
-+ Evaluar e informar sobre la satisfacci6n del cliente
-+ Llevar a cabo revisiones peri6dicas de planes de calidad de proyectos
-+ Monitorizar el estado de las mejorar de calidad de los productos y servicios
Tabla 7.5. Actividades del Proceso de Gestion de la Calidad (ISO, 2003)
e Procesos tecnicos, que incluyen el proceso de definicion de requisitos de las
partes irnplicadas en el producto, analisis de requisitos, disefio arquitectonico,
irnplernentacion, integracion, verificacion, transicion, validacion, operacion,
rnantenirniento y retirada.
Al igual que la nonna ISO 12207 tarnbien la 15288 prop one un proceso de
adaptacion de estos procesos a las necesidades concretas de una organizacion. Adernas,
sefiala en el anexo B que las "etapas" (stages) se pueden utilizar para constmir marcos
conceptuales en los que los procesos del cicio de vida del sistema se utilicen para modelar
ciclos de vida, describiendo el proposito y las salidas de seis etapas: concepcion,
desanollo, produccion, utilizacion, soporte, y retirada.
e IEEEIEIA 12207.0-1996. Standardfor Information Technology - Software Life
Cycle Processes. Institute of Electrical and Electronics EngineerslElectronic
Industries Alliance. 01-Mar-1998.
e IEEEIEIA 12207.2-1997. Industry Implementation of International Standard
ISOIIEC 12207: 1995; Standardfor Information Technology - Software Life
Cycle Processes - Implementation Considerations. Institute of Electrical and
Electronics EngineerslElectronic Industries Alliance. 01-Apr-1998
e IEEEIEIA 12207.1-1997. Industl), Implementation of ISOIIEC 12207:1995 -
Standard for Iriformation Technology - Software Life Cycle Processes - Life
Cycle Data. Institute of Electrical and Electr'onics EngineerslElectr'onic
Industries Alliance. 01-May-1997.
Este gmpo de estandares IEEE proporcionan la implementacion industrial de la
nonna ISO/IEe 12207. El docurnento 12207.0-1996 (el estandar base) consiste
15
J
CAUDAD DE SISTEMAS
RA-1vL-\
basicamente en el texto del estandar ISO 12207 junto con anexos explicativos. Los otros
dos documentos contienen recomendaciones adicionales delivadas de MIL-STD-498 y de
los estandares de ingenieria de IEEE, con algunas influencias adicionales.
e http://\v\vw.l2207.comJ Sitio web con infonnacion actualizada y completa
sobre la norma ISO 12207 y sus estandares y propuestas relacionadas.
e http://w\vw.ieee.onz Sitio web de la organizacion IEEE.
e http://\v\vw.incose.on!l Sitio \veb que proporciona infonnacion adicional sobre
los procesos del cicIo de vida de sistemas.
6. EJERCICIOS
1. Especifique cuales de los procesos de cicIo de vida software que aparecen en la
nonna ISO 12207 son mas aplicables para pequefias y medianas empresas de
desarTollo de software.
2. Establezca el tipo de participacion de los diferentes "stakeholders" (jefes de
proyecto, analistas, programadores, responsables de cali dad, etc .. ) en cada uno de
los procesos de cicIo vida.
3. Lleve a cabo un estudio comparativo entre los estandares IEEE 1074, ISO 12207
e IEEE 12207.0, IEEE 12207.1, IEEE 12207.2.
4. Analice las diferencias entre el proceso de soporte de la ISO 12207
"Aseguramiento de la Cali dad" y la n0l111a ISO 90003 (vease capitulo 8).
CAPITULO 8
EV ALUACION Y MEJORA DE PROCESOS
*
"Sin 1111 continllo progreso y crecimiento, palabras tales como mejora, logro y exito no tienen
ningzln signijicado "
Benjamin Franklin
1. PANORAMICA GENERAL
Hoy en dia la calidad del software no puede garantizarse imicamente centrando los
programas de cali dad en el producto, dado que, tal y como se ha comentado en el capitulo
6, la cali dad final del producto software esta muy directamente relacionada con la fOlma
en que se desarrolla y mantiene, es decir, con el proceso. Todo ella ha motivado en gran
medida que las organizaciones dedicadas al desarrollo y mantenimiento del software se
preocupen cada vez mas de la mejora de sus procesos.
Ante esta situaci6n, los modelos de evaluaci6n y mejora de procesos y su
estandarizaci6n han adquirido un papel muy impOltan!e para la identificaci6n, integracion,
medici on y optimizacion de las buenas practicas existentes para el desarrollo y
mantenimiento del software. La evaluaci6n y mejora de los procesos software pel1niten
juzgar y decidir sobre la calidad de los procesos que estan sujetos a analisis, con el
objetivo de poder establecer una estrategia para su mejora. La evaluaci6n de los procesos
software se hace principalmente por dos motivos: bien para detel1ninar la capacidad de ill1
proveedor de cara a su contrataci6n, 0 bien para mejorar los procesos.
Como resultado de los esfuerzos de la comunidad cientifica, se han propuesto toda
una serie de modelos y estandares para promover la aplicaci6n de este proceso en las
organizaciones. La aparicion en el mercado de estas propuestas esta ofreciendo a las
empresas y departamentos de desarrollo infol1natico la posibilidad de adaptarse a una
nueva fOlma de trabajo caracterizada principalmente por buscar la satisfaccion de los
154 CAUDAD DE SISTE;VV\S INFORMA TICOS
clientes y disponer de una mejor visibilidad y control de la calidad de los procesos y de
los productos finales.
Sin embargo, en los ultimos alios estamos asistiendo a una gran proliferaci6n de
propuestas para la evaluaci6n y mejora de los procesos. En SelTad y Lake (1998) se
destaca la gran cantidad de marcos que pueden convertir este campo en "Zlna cirinaga en
fa qZle se empalltallen los esfiterzos de mejora de procesos si ZIlla organizaci6n 110 es
cllidadosa". Para ello conviene distinguir (vease figura 8.1):
( People CMM

( ISO 15939 )

---l> Sus:i:Uye a
... Basado en
... UsaReferen:::ia
(IeEel

( MOPROSOFT )
(SsEl

( Baldrige)
( Bootstrap)
( MPSB, )
< ISOIIEC 15288 )
Figura 8.1. La cienaga de los estandares y modelos de referencia de la madurez,
evaluaci6n y mejora de procesos (adaptado.de http://\Hyw.software.org/guagmire)
I!l Modelos de procesos del cicIo de vida, como el ISOIlEe 12207 0 el ISO
15288 para la ingenielia de sistemas, que han sido resumidos en el capitulo
anterior.
I!l Estandares y guias, que establecen 10 que deb eli a hacerse en una situaci6n
contractual, como las nonnas ISO, estandares como el EIA Interim Standard
(IS) 632 para procesos de ingenielia de sistemas, 0 los estandares militares
como el MIL-STD-498 (desanollo y documentaci6n de software).
I!l Modelos de rnejora y rnetodos de valoracion interna, que establecen un
camino a seguir describiendo las caractelisticas de los buenos procesos, como
C RA.-MA CAPiTULO 8: EYAlUACION Y MEJORA DE PROCESOS 155
CMM/CMMI y sus modelos asociados (PSP, TSP, etc), Bootstrap, Trillium
para telecol11unicaciones, etc.
En la tabla 8.1 se muestra un resumen de modelos representativos de referencia
para la madurez, evaluaci6n y mejora de procesos software propuestos en la literatura. De
entre todas estas iniciativas cabe destacar la influencia que tuYO CMM en la mejora del
software, y, en la aChtalidad, su sucesor CMMI, as! como el estandar ISO 15504 y la
reciente nonna ISO 90003, que promueve la adopci6n de un enfoque basado en procesos
cuando se desalTolla, implementa y mejora un sistema de gesti6n de la calidad.
MODELO {JRL
. ...
...
BOOTSTRAP (Kuvaja et al., 1994)
I
h!!Q:/!www.cse.dcu.ie
i
essiscoQe
i
sm5/aQQroaclv
boot-2.html
EIA 632. Processes for Engineering a System. (Sheard y
h!!Q://\vww.eia.org
Lake, 1998)
ISO/IEC 15504 (ISO, 2004a-e) http:!;\\\\\\".iso.org
ISO/1EC 90003 (ISO/IEe. 2004f) http://\v\\\\".iso.org
MIL STD-498 h!!Q:/I\v\\\\".Qogner.demon.co.uk!mil 498/
MOPROSOFT (Oktaba et al .. 2003)
w\v\v.lania.mxJbibliotecaimanualesimoprosoft!
V%20 1.1 %20DocumentoBase.pdf
Mps BPR (Weber y Rocha. 2004) http://\\\\w.softex.br/
SEI GvIMI- Capability Maturity Model Integration
httQ://\\ \V w .sei.cmu.edulcmmi!
(SEI,2002)
SCAtvIPI (Standard CMrvfI Appraisal Method for h!!Q:i;\\\\\\".sei.cmu.edu/Qublications!document
Process Improvement) (SEL 200 I) SiO l.reQorts/O I hbOO I.hunl
SEI Software Capability Evaluation (SCE) (Bymes y httD:/!\\\\\\".sei.cmu.edu!Qublications'document
Philips, 1996) s!96.reQorts!96.tr.002.html
SEI SE-GvIM Capability Maturity Model for Systems
httQ:ii\\\\w.sei.cmu.edulcmnvse-cmm.html
Engineering (SEI. 1995)
SEI P-CMM People Capability Maturity Model (Curtis
h!!Q:!/w\\w.sei.cmu.edwcmm-Qi
etal., 2001)
SEI IDEAL Model (Gremba y Myers, 1997) http://\\\\w.sei.cmu.edulideallideal.html
SEI Personal Software Process (PSP) (Humphrey. 1997) http://v\\\\\".sei.cmu.edu/tsQiQsQ.html
Systems Security Engineering Capability Maturity
http://\\\\w.ssc-cmm.org
Model (SSE-CMMl (Departtnent of Defense U.S.A.
1999)
SEI SW-CMM Capability l'vlaturity Model SM for
h!!Q:! 1\\".\ \\" .sei.cmu.edulcmnV cmm.html
Software (SEI, 1995)
SEI Team Software Process (TSP) (Humphrey, 2000a;
htm:! 1\\\\w.sei.cmu.edu/tsQ!tsQ.httnl
2000b)
Software Development Capability Evaluation (SDCE) h!!Q:; \\\\\v.stsc.hill.af.millcrosstalklI997/04/de
(AFMC, 1994) veloQment.asQ
Tickit (Tickit Project Office, 1992)
I
http://\\\\w.tickit.org/
Trillium (Trillium Team. 1994) (April Y Coallier. 1995)
I
htt12: !v,\\"\\2.umassd.edulswI1i1BeIICanadaitrilli
um-htmlltrillium.html
Tabla 8.1. Resumen de los Modelos de Madurez y Metodos de Evaluaci6n y Mejora del
Sofnvare (ultimo acceso de enlaces web en agosto de 2006)
156 CAUDAD DE SISTEMAS IN"FOR.,vlATICOS
o Metodos de seleccion de contratistas, que especifican el examen de los procesos
de una organizaci6n por alguien extemo (segunda 0 tercera parte) con el fin de
comparar las fortalezas y debilidades de los contratistas para poder minimizar el
riesgo de la compra. Por ejemplo, Software Capability Evaluation (SCE) 0 el
SDCE de las Fuerzas Annadas de EEUU.
o Premios a la calidad, como el Malcolm Baldrige Nacional Quality A,mrd,
European Quality Award, que han sido tratados en el capitulo 3.
Siguiendo esta "filosofia" tambien se han propuesto otros muchos modelos de
madurez especificos: para pruebas (Olsen y Staal, 1998; Krause, M., 1994), gestion de
proyectos (Ibbs y Hwak, 2000; McBride et al., 2004; Crawford, 2002; PMI, 2004),
ingenieria de requisitos (Somerville y Ransom, 2005), desarrollo distribuido
(Ramasubbu et al., 2005), mantenimiento (April et al., 2005), usabilidad (Earthy, 1997:
Bevans, 2000), olltsourcing (Raffoul, 2002); arquitecturas (Burke, 2002; DoC, 2003;
Gartner, 2002: Luftman, 2000; OMB, 2004; Van del' Raadt et al. 2005; NASCIO, 2003:
Schekkennan, 2003); seguridad (Department of Defense U.S.A, 1999), reutilizaci6n
(Topaloglu, 1998); proveedores de servicios de tecnologias de la informacion
(Niessink et al .. 2002); datos (Mullins, 2002); senicios e-Government (Windley, 2002):
open-source (Widdows y Duijnhomver, 2003), etc.
Tambien merecen especial atenci6n las propuestas de modelos de evaluaci6n y
mejora adaptados a pequefias y median as empresas. Para este tipo de empresas el
problema de muchos de los modelos tradicionales es que, al haber sido concebidos para
grandes empresas, su adaptaci6n a las Pymes es dificil y costosa, tal y como atestiguan
divers as investigaciones (vease, por ejemplo, Batista y Figueiredo, 2000: Hareton y
Terence, 2001, Tuffley et at., 2004; Calvo-Manzano, 2000). Ademas, como sefiala en su
reciente estudio Mekelburg (2005), las organizaciones, inc1uso las gI'andes, tienden a
adoptar gIupos de procesos relacionados como un mas que procesos de fonna
independiente como, por ejemplo, en elmodelo CMMI.
En este capitulo se presentan de fonna resumida una serie de modelos
representativos propuestos en la bibliografia para la mejora de calidad en las
organizaciones y sus metodos de evaluaci6n y mejora asociados. Tambien se resumen dos
propuestas de modelos iberoamericanos de madurez de procesos, adaptados a las
especiales caracteristicas de las empresas, en su mayoria Pymes, de los paises en los que
se proponen.
2. LA NORMA ISO 90003
La nonna ISOIIEC 90003 (ISO, 2004) proporciona la guia necesaria en las
organizaciones para la aplicacion de la ISO 9001 (ISO, 2000b) a la adquisici6n,
suministro, desalTollo, operaci6n y mantenimiento de software y sus servicios
relacionados. Identifica todos los aspectos que deberian ser tratados y es independiente de
CAPiTULO 8: EVALUACION Y MEJORA DE PROCESOS 157
la tecnologia, modelos de ciclo de vida, procesos de desanollo y estmcturas
organizacionales. La nonna ISO 9001, especifica los requisitos para un sistema de gestion
de la calidad cuando una organizacion necesita demostrar su capacidad de proporcionar de
f0l111a coherente productos que satisfagan los requisitos del cliente y aspira a aumentar su
satisfaccion a traves de la aplicacion eficaz del sistema, incluyendo los procesos para la
mejora continua del sistema, y el aseguramiento de la confOlmidad con los requisitos y de
acuerdo a las reglamentaciones existentes.
El estandar ISO 90003 surge debido a que la gestion de la calidad que prop one
ISO 9001 aun siendo un buen marco de partida, es excesivamente general y se queda corta
para abordar proyectos de disefio e implantacion de sistemas de gestion de la calidad mas
especializados. Las directrices proporcionadas en esta nonna intemacional no estan
enfocadas a ser utilizadas como criterios de evaluacion en la certificaci6nJregistTO del
sistema de gesti6n de la calidad.
Seglll1 la nOlma ISO 90003 la organizaci6n debe establecer, documentar,
implementar y mantener un sistema de gestion de la calidad software y mejorar
continuamente su eficacia de acuerdo con los siguientes requisitos generales:
Identificar los procesos necesarios para el sistema de gestion de la calidad y
su aplicaci6n a traves de la organizaci6n. En este punto la organizaci6n deberia
identificar tambien los procesos de desanollo. operaci6n y mantenimiento de
software.
Determinar la secuencia e interaccion de estos procesos. La organizacion
deberia tambien detinir la secuencia e interacci6n de los procesos en: los
modelos de ciclos de vida del desanollo de software, por ejemplo, modelos en
cascada, incremental y en espiral (evolutivos); la planificaci6n de la calidad y
el desan'ollo, que deberia basarse en un modelo de cicIo de vida.
Determinar los criterios y metodos necesados para asegurarse de que tanto
la operaci6n como el control de estos procesos sean eficaces.
Asegurarse de la disponihilidad de recursos e informacion necesarios para
apoyar la operaci6n y el seguimiento de es'tos procesos.
Realizar el seguimiento. la medicion y el analisis de estos procesos.
Implementar las acciones necesarias para a1canzar los resultados
planificados y la mejora continua de estos procesos.
i58 CAUDAD DE SISTEMAS INFORMATICOS
3. EL MODEJ,.O DE MAQUREZ DE LA CAPACIDAD (CMM)
Y LOS METODOS MAS REPRESENTATIVOS DE
EVAlUACION Y MEJORA ASOCIADOS
3.1. CMM
Desde la decada de los alios 80, el Instituto de Ingenieria del Software (SEI,
So./hmre Engineering institute) de la Universidad de Camegie Mellon se ha centrado en
proporcionar la base necesaria para mejorar el desaITollo del software considerando a las
tareas de desanollo del software como una selie de procesos que se pueden definir, medir
y controlar. Como resultado se han obtenido modelos de referencia de la capacidad de los
procesos y modelos de evaluaci6n de dicha capacidad.
CMM (SEI, 1995) es el modelo propuesto por el SEI como referencia para
detenninar la capacidad de los procesos software de una organizaci6n. CMM proporciona
a las organizaciones de software el modelo de referencia necesaIio como sopolie para el
control de sus procesos de desanollo y mantenimiento y para facilitar su evoluci6n hacia
una cultma de la Ingenieria del Software y de excelencia en la gesti6n. Es un modelo con
la finalidad de:
e Evaluar la madurez de los procesos de desanollo de software dentro de una
organizaci6n.
e Proponer un plan de mejora de los procesos de desalTollo de software de
acuerdo a una serie de niveles.
A la hora de establecer la madmez de los procesos de una organizaci6n en CMM se
establecen cinco niveles de capacidad, que definen una esc ala ordinal para representar la
evoluci6n del proceso software desde un nivel inicial ca6tico (procesos ad hoc cuyos
resultados no son predecibles) hasta un estado de mejora continua (maduro). Las
caracteristicas de cada nivel de madmez se resumen en la tabla 8.2.
EI modelo de referencia CMM establece una serie de areas clave (hasta un total de
dieciocho) agrupadas en los distintos niveles de madurez. Para que una organizaci6n
pueda estar en un detel111inado nivel de madurez debe satisfacer los cliterios de evaluaci6n
asociados con las areas clave que pertenecen a ese nivel y a los niveles anteriores. Cada
area clave de proceso 0 KPA (Ke.' Process Area) se desclibe en funci6n de una serie de
practicas clave (KPs, Ke.' Practices), que a su vez se organizan en una selie de
caracteristicas comunes (COllllllon features). Las relaciones entre estos conceptos del
modelo CMM se ilustran en la figura 8.2.
RA-MA
NIYEL
I:\IClAL
REPETIBLE
DUl:\IDO
GESTlO:\ADO
OPTl:\lIZADO
CAPiTuLO 8: EVALL'ACION Y N!EJORA. DE PROCESOS 159
CARACTERiSTIC\S
Auseneia de gestion de proyeetos.
EI proceso de software cs eambiantc e irregular.
Los grupos abandonan f<ieilmente los planes y se centran en
la codificacion y pruebas.
Los planes. estimaciones y calidad son il11predeeibles.
EI rendimiento depende de la capacidad individual de los
miel11bros del grupo.
Se estableeen programas de fonnaci6n del personal de
desarrollo y mantenimiento.
Los proeesos de software son estables y repetibles.
La organizacion estableee politic as de gerencia de proyectos
v procesos.
La planiticacion se basa en proyeetos similares.
Existen estandares detinidos y exigidos.
EI proceso se enmarca en un sistema de gerencia de
proyeetos basado en experieneias pasadas.
Los procesos son de!inidos. estandarizados. documentados e
institucionalizados.
Los procesos de ingenieria y gestion son estables y se
integran en uno solo.
Existe un entendimiento comun de los procesos. funciones y
responsabilidades.
La organizacion mantiene un grupo dedicado a la definicion.
mejordmiento y difusion del proceso de Ingenieria de
Software.
Los procesos son mediblcs 0 euantiticables.
La produeti\'idad y la ealidad se miden y registran para cada
proyecto de la organizacion.
Se fijan metas cuantitativas de la ealidad del software.
Mediante el uso de metricas de software. se crea una base
euantitativa para la evaluaeion y estimacion en proyeetos
futuros.
Los procesos se mejoran continuamente.
La organizacion busca lograr el ni\'e1l11aximo de eapaeidad.
Se incorporan nuevas tecnologias y metodos para mejorar los
procesos.
Tabla 8.2. Niveles de Capacidad de CMM
RESULTADOS
Productividad y
calidad escasa.
Riesgo m;iximo
Productividad y
calidad baja.
Riesgo alto.
Productividad y
calidad media.
Riesgo medio.
Productividad y
calidad alta.
Riesgo minimo.
Productividad y
calidad total.
Riesgo nulo.
160 CAUDAD DE SISTE!vlA.S r"iFORlvlA. TICOS
Areas Clave del Proceso (KPAs)
Grupo de Acthidades que satisfacen un
conjllnto de objetivos
Pn3cticas Clave
Actividades e infraestructura que
contribuyen en su mayoria a la
implementaci6n de un al'ea clave de proceso
RA-MA
Figura 8.2. Estructura de CMM como modelo de referencia para la evaluacion
Como se puede observar en la figura 8.2, CMM proporciona la estructura
necesaria para poder aplicar de fonna sistematica un proceso de evaluaci6n al estar
claramente definido cada nivel de madurez en base a:
Q Areas clave del proceso. Cada nivel de madurez. excepto el nivel inicial se
descompone en diterentes areas clave del proceso. Ejemplos de areas clave son
la gesti6n de configuraci6n y planificaci6n del proyecto del segundo nivel de
madurez, 0 la prevenci6n de defectos y gesti6n de cambio del proceso.
cOlTespondientes al nivel quinto de madurez. Cada area clave contiene un
conjunto de objetivos 0 metas, que descliben de fonna general que se debe
hacer para dar soporte a un area clave de proceso. Las metas se us an para
cOl11probar si efectivamente se implementa adecuadamente un area clave de
proceso detenninada.
Q Caracteristicas Comunes. Cada area clave de proceso se organiza en una
selie de caracteristicas comunes que representan los atIibutos que debe tener el
proceso. Mediante la evaluaci6n de las caracteristicas comunes se puede
averiguar si la il11plel11entaci6n de un area clave de proceso se ha realizado de
fOlma que sea efectiva, repetible y duradera.
GRA.-MA CAPiTULO 8: EVALUACIOl\ Y YIEJORA. DE PROCESOS 161
(i) Pnicticas Clave. Constituyen los ejemplos de que se debe hacer para
satisfacer los objetivos de un area clave de proceso sin entrar en detalle de
como hacerlo.
Para poder conocer el nivel de madurez de una organizacion es necesario realizar
la evaluacion de sus procesos software. Por este motivo y con el fin de proporcionar el
medio necesario para realizar evaluaciones basadas en CMM y para poder comparar los
resultados de evaluacion se creo el marco de trabajo CAF (Ci"\;fM Appraisal Framework),
que identifica los requisitos y caracteristicas necesarias en un metodo de evaluacion
basado en CMM para mejorar la consistencia y la fiabilidad de los diferentes metodos de
evaluacion y sus resultados.
Los dos principales metodos de evaluaci6n basados en CMM son SCE (Sofhrare
Capability Evaluation) y CBA-IPI (CMM-Based Appraisal for Internal Process
Jmpro1ement). Por otra parte, el marco de mejora de procesos del SEI, bas ado en CMM,
10 constituye elmodelo IDEAL. A continuacion se resumen todos ellos.
3.2. SeE (Software Capability Evaluation)
SCE (Bymes y Philips, 1996) es el metodo desarTollado para evaluar los procesos
software de una organizacion con el objetivo de detel1ninar su capacidad. La capacidad de
un proceso se refiere al rango de los resultados esperados que se pueden obtener aillevar a
cabo un proceso detel1ninado.
Las principales areas de aplicacion de SCE son: la seleccion del suministrador, la
monitorizacion del proceso y la evaluacion interna. SCE usa el modelo de madurez de
capacidad (CMM) como modelo de referencia. El objetivo de la evaluacion de SCE es el
proceso software. y en particular. se centra en conjuntos de procesos (0 10 que en CMM se
considera como areas clave de procesos) que se pueden agrupar en tres categorias:
procesos organizacionales. que contienen un conjunto de areas clave que se centran
sobre la gestion organizacional de los procesos software: los procesos de gestion de
proyectos. centrados en aspectos de gestion de proyectos como su planificaci6n y
seguimiento: y los procesos de ingenieria. que incluyen aspectos de desarTollo del
producto como la gestion de requisitos, ingenieria del producto, revisiones por pares, etc.
Aunque en el modelo CMM se consideran los procesos de produccion tecnica,
estos no se incluyen en el alcance de la evaluacion proporcionada por SCE. tal y como se
puede observar en la figura 8.3.
El proceso de evaluacion definido en SCE esta compuesto basicamente por las
siguientes actividades: planificar y preparar la evaluacion. !levar a cabo la evaluacion e
infol1nar sobre los resultados de la evaluacion. Las principales caracteristicas y
responsables de estas actividades se resumen en la tabla 8.3.
162 C.-\LIDAD DE SISTE0.iAS IMORMATICOS
Ejemplos
- Planificaci6n del Proyecto
- Seguimiento del Proyecto
- Gestion de la Configuraci6n
- Aseguramiento de la CaUdad
t
Soporte para
Procesos de T oma de
Decisiones y
Comunicaci6n
Soporte a Ia Construcci6n Operacional
del Producto
Ejemplos
- Revisiones par pares
tJ RA-MA
-Ingenieria del Producto Operaciones de Desarrollo
- Gestion de Requisitos
t
Soporte para
Procesos de
Comunicaci6n y
Tecnicos
Ejemplos
- Entornos de ingenieria
- Metodo!ogias de Amllisis de Requisitos
- Metodologias de Diseno
-C6digo
t
Procesos Tecnicos
Evaluado por SeE
No Evaluado por
seE
Figura 8.3. Procesos Evaluados por SeE
Como se puede apreciar en la tabla 8.3, el equipo de evaluaci6n SCE lleva a cabo
una planificaci6n en la que basicamente identifica las areas de proceso a evaluar para
realizar un proceso de evaluaci6n basado en rigurosas revisiones de documentaci6n y
entrevistas en el que, mediante un proceso de analisis, se establecen las debilidades y
fortalezas de la evaluaci6n para finalmente realizar los infol1nes adecuados en funci6n de
los resultados obtenidos.
3.3. CBAIPI (CMM-Based Appraisal for Internal Process
Improvement)
CBA-IPI (Dunaway y Masters, 2001) es un metodo que facilita a una organizaci6n
conocer la capacidad de sus procesos software mediante la identificaci6n de las fortalezas
y debilidades y la relaci6n de estas fortalezas y debilidades en base al modelo CMM, con
el fin de establecer y dar pliOlidad a planes de mejora software y para facilitar que la
organizaci6n se centre en la mejora de los aspectos que Ie resulten mas beneficiosos en
funci6n de su nivel de madurez y sus objetivos de negocio.
El metodo consiste en la evaluaci6n de la capacidad del proceso software de una
organizaci6n a traves de un grupo de profesionales adecuadamente entrenados que
trabajan como un equipo para aveliguar y valorar las distintas areas clave del proceso de
CMM que se encuentran en el alcance de la evaluaci6n. Los datos necesarios para la
\:" RA-M.-\ CAPiTULO 8: EVAWACIOl\ Y :VIEJORA, DE PROCESOS 163
valoracion se obtienen a par1ir de datos obtenidos de cuestionarios, revisiones de
documento, presentaciones y ent:revistas con gestores, jefes de proyecto y agentes
software,
FASE seE v 3.0
y
REALIZAR LA PREPARACID:-'-
PARA LA
EV.ALV.KID:-'-
REALIZAR
LA EVALLACID:-'-
!:-'-FORi\lAR LOS RES(JL TADOS
DE LA EVALLAClD:-'-
ACTIVlDADES Y RESULTADOS
La Organizacion Patrocinadora:
Deteffilina los atributos deseados del producto
Detennina la eapacidad del proceso mas apropiada para alcanzar los
objetivos de negocio (ia capacidad objeti\"o del proceso)
Sclecciona y lonna al equipo de la evaluacion (SCE)
Resultado: se definen los objeti\"os y los requisitos de la evuluacion
EI Equipo SCE:
Identifica las areas en las que la organizacion careee de experiencia
(indicando un riesgo potencial)
Deline el alcance de la cvaluacion.
Resultado: se detlne el alcance de la evaluacion y se complctan las preparaciones a
alto niwl para c\"aluar a la organizacion de desarrollo,
EI Equipo SCE:
Selecciona los proyectos a evaluar.
Prepara los temas especitlcos para la c\'aluacion.
Analizar los datos
Resultado: se completan las preparaciones detalladas para cvaluar un sitio de
desarrollo.
EI Equipo SCE:
Inwstiga cada tema planitlcado en el sitio de desarrollo"
Conduce actividades de recopilacion de datos mediante la
rcalizacion de cntrcvistas. revisiones de documentos y
presentaciones.
Consolida la infoffilacion recogida y valida las observacioncs.
Deteffilina los puntos fuertcs. debiles y las aeti\'idades de mejora"
Resultado: Datos del Proceso consolidados y se deteffilinan los resultados.
EI Equipo SCE:
Presenta y entrega los resultados al patrocinador y a la organizacion,
Produce un infoffile final para el patrocinador.
Realiza recomendaciones para el uso de los resultados.
Resultado: sc deterrninan y doeumentan los resultados de la e\'aluacion Datos del
Proceso consolidados y se deterrninan las biJ,quedas,
Tabla 8.3. Fases y Actividades de la evaluacion SeE
Los dos plincipales objetivos de CBA IPI son:
It Dar sop0l1e, habilitar y animar a una organizacion a la mejora del proceso
software.
164 CAUDAD DE SISTEMAS IKFOfu'vLA.TICOS
-f' RA.-:VL-I.
Ii> Proporcionar una vision exacta de las fortalezas y debilidades de los procesos
software aChlales de la organizacion, usando CMM como modelo de referencia
y para identificar las areas clave del proceso que es necesario mejorar.
Las actividades y a1cance del proceso de evaluacion del metodo CBA-IPI son
basicamente los mismos que en el metodo SCE (planificacion, conduccion y generacion
de infol1nes). En realidad, CBA-IPI es muy similar a SCE con la diferencia fundamental
de que CBA IPI es una evaluacion centrada en la mejora de procesos, mientras que SCE
suele orientarse mas a la seleccion de suministradores, aunque tambien se puede usar para
la evaluacion intema de procesos.
De acuerdo a la tel111inologia usada en los modelos de evaluacion basados en
CMM. se considera que CBA IPI es un metodo para la valoracion (assessment) de la
capacidad para mejora de procesos. mientras que SCE es un metodo de evaluacion
(emillation) con el fin de seleccionar suministradores 0 para medir el progreso de las
mejoras. La diferencia fundamental entre la valoracion y la evaluacion es que la primera
consiste en un proceso que una organizacion hace para sl misma, mientras la segunda es
un proceso en el que un grupo extemo llega a una organizacion y examina la capacidad de
sus procesos para tomar decisiones respecto de posibles negocios 0 tratos llhlroS. EI
a1cance de una \-aloracion es relativo a las necesidades de la organizacion y objetivos de
negocio del patrocinadoL que es usualmente el gestor senior de la organizacion evaluada.
En contraste. el alcance de una evaluacion es relativo a las necesidades del patrocinador.
que es la persona 0 grupo de personas responsables de decidir si se hace la evaluacion de
la organizacion con la que se pretende hacer negocios. En la tabla 8.4 se representan las
diferencias entre un proceso de valoracion y un proceso de evaluacion.
Los resultados de la evaluacion de los metodos comentados anteri0l111ente se
pueden utilizar en el contexto de la mejora de procesos software. ya sea para la mejora de
los procesos de la propia organizacion evaluadora (CBA-IPI) 0 para mejora en la
organizacion evaluada (SCE).
3.4. IDEAL
EI marco de mejora de procesos del SEr 10 constihlye el modelo IDEAL
(McFee ley, 1996: Gremba y l'vlyers. 1997) en el que se define un marco de ciclo de vida
para la mejora de procesos. Este modelo lIe concebido originalmente como un cicIo de
vida para la mejora de procesos software basado en el modelo CMM y posterionnente el
l110delo IDEAL lIe revisado en la version 1.1 para proporcionarle un a1cance mas amplio.
IDEAL constihlye un enfoque usable y entendible para la mejora continua estableciendo
los pasos necesarios que se deb en seguir para llevar a cabo un programa de mejora y
proporcionando un enfoque ingenieril y disciplinado. En la figura 8.4 se l11uestra la
estruchlra de este modelo.
I
I.
I
CAPiTULO 8: EVAlUACION Y MEJOR:\ DE PROCESOS l65
V ALOR-\CION (ASSESSMEi\"T) (E\'ALUATION) ..
OBJETIVO Mejora de Procesos Selecci6n y monitorizaci6n de
suministradores
Los desarrolladores 10 usan para medir el
progreso de la mejora
COi\It1NICACION Se usan en la organizaci6n evaluada Los resultados se hacen saber al
DE REsULtADOS patrocinador
EQL1PO
I
Colaborativo. Los miembros de la Los miembros de la organizacion podrian
organizacion deben [onnar un no estar en un equipo
equipo
ALCANCE Se aplica a la organizacion. no a
I
Se aplica a necesidades especificas del
proyectos individuales 0 contratos patrocinador
USODELOS
I
Como entradas al plan de mejora Como entrada a la seleccion de
RESULTADOS suministrador. gestion de riesgos y
medici ones de la mejora intema
Tabla 8.4. Diferencias entre Valoracion y Evaluacion
Estimu!o
. para fa
f.lejora
Iniciacion
Aprendizaje
Diagnostico
Figura 8.4. El modelo IDEAL (McFeeley, 1996)
Como se puede observar en la figura 8.4, e1l110delo IDEAL esta cOl11puesto por
cinco fases, cada una de las cuales esta fom1ada pOl' una serie de actividades:
til Iniciacion, que constituye el punto de paItida, en el cual se establece la
infi'aestructura, los roles y responsabilidades que hay que asul11ir y se asignan
los recursos necesarios. En esta fase se elabora el plan de mejora de procesos
que proporciona la guia necesaria para completar el inicio y llevar a cabo las
fases de diagnostico y establecimiento. Adermls, se decide la aprobacion del
166 CAUDAD DE SISTEMAS INrORMATICOS
programa de l11ejora, se establecen los recursos necesarios y se establecen los
objetivos generales de la l11ejora a partir de las necesidades de negocio de la
organizacion. Estos objetivos son refinados en la fase posterior de
establecil11iento. Respecto a la infraestmctura, se establecen dos cOl11ponentes
fundal11entales: un gmpo directivo de la gestion (Management Steering
Group, MSG) y un gmpo de procesos de ingenieria del software (sofhmre
engineering process group, SEPG). Durante la fase de inicio tal11bien se
realizan planes para cOl11unicar el cOl11ienzo de la iniciativa de mejora y se
sugiere la necesidad de realizar evaluaciones para detenninar la preparacion
de la organizacion a la hora de llevar a cabo una iniciativa de mejora de
procesos.
EI Diagnostico, en la que se lleva a cabo el trabajo preliminar necesaJio para
realizar las fases posteliores. En esta fase se inicia el plan de accion de la
mejora de acuerdo con la vision de la organizacion, el plan de negocio
estrategico, las lecciones aprendidas de esfuerzos de l11ejora realizados en el
pasado, aspectos clave a los que se enfrenta la organizacion y los objetivos a
largo plazo. Se realizan actividades de valoracion para establecer una linea
base del estado actual de la organizacion, entregandose sus resultados y
recomendaciones en las acciones del plan de l11ejora.
EI Establecimiento, durante la cual se priorizan los aspectos que la
organizacion ha decidido l11ejorar, se desanollan las estrategias necesaJias
para obtener las soluciones de mejora y se cOl11pleta el bon'ador del plan de
mejora definido en las fases anteliores. En esta fase tal11bien se desanollan
objetivos l11edibles a partir de los objetivos generales fijados en la fase de
inicio y que son incluidos en el plan de l11ejora. Ello conlleva adel11as la
definicion de las l11ehicas necesmias para el conh'ol del progreso y se
preparan los recursos y se proporciona la fonnacion necesalia a los gl1lpOS de
trabajo tecnico (Technical 'Working Groups, IFVG). El plan de accion
desaJTollado debe guiar las actividades de mejora de acuerdo a los aspectos
detectados para la l11ejora ordenados seglll1 su priOlidad y segtll1 las
recol11endaciones de la fase de diagnostico. Tambien durante esta fase se
crean plantillas de acciones tactic as que los gl1lpOS de trabajo tecnico deben
cOl11pletar y llevar a cabo.
EI Actuacion, en la que se crean y se llevan a cabo las acciones destinadas a
l11ejorar las areas identificadas en las fases previas. Se desauollan planes para
ejecutar las acciones de l11ejora y para evaluar 0 probar los procesos nueyos 0
mejorados. Una vez completada exitosamente la pl1leba de nuevos procesos y
tras detenninar su adecuacion para ser adoptados en la organizacion. se
desanollan y ejecutan lcs planes necesarios para su implantacion.
CAPITULO 8: EVALUACION Y ;,,!EJORA. DE PROCESOS 167
& Aprendizaje, cuyo objetivo es tratar de hacer mcls efectiva la siguiente
iteracion por el modelo IDEAL cuando sea necesaria. Una vez alcanzada esta
fase, se han desanollado las soluciones, se han aprendido importantes
lecciones del proceso y se han tomado mediciones sobre el rendimiento y la
consecucion de los objetivos marcados. Estos artefactos son afiadidos a la
base de datos del proceso, que constituye una fuente de infonnacion muy
relevante para el personal implicado en la proxima iteracion por las fases del
modelo. La infonnacion reunida pennite realizar una evaluacion sobre la
estrategia, los metodos y la infraestmctura utilizada en el programa de
mejora, 10 que pennite su coneccion y ajuste de cara a thturas mejoras. Es
necesario plantear algunas preguntas, como por ejemplo sobre el rendimiento
de la infraestmctura (equipos de trabajo MSG, SEPG, TWG, etc.) y los
metodos empleados por los TWG en sus actividades de desanollo de la
solucion. Una respuesta adecuada a cada una de estas preguntas es
fundamental para plantear el siguiente ciclo delmodelo IDEAL.
3.5. PSP (Personal Software Process)
En el contexto del modelo CMM y a la hora de facilitar la aplicacion de los
procesos de evaluacion y mejora en una organizacion, es necesario implantar buenas
pnicticas en el desanollo software. Con tal fin se desanollo el metodo PSP (Humphrey,
1997). EI Proceso de Software Personal (PSP) apoya a las empresas que estan llevando
a cabo 0 tienen planeado implementar un plan de mejora de procesos basados en un
modelo como CMM, ayudando a crear personal capacitado y disciplinado en su trabajo.
Esta plincipalmente bas ado en CMM y pennite implementar las practicas de
ingenieria del software descritas en dicho modelo a nivel individual, incorporando de
fonna efectiva, eficaz y a bajo costa aspectos tales como la planificacion y seguimiento de
proyectos, las revisiones e inspecciones, el proceso de ingenieria del producto, el enfoque
y la medicion cuantitativa del proceso, la prevencion de defectos, la evaluacion de calidad,
etc.
Al igual que en CMM, PSP se basa sobre los principios de mejora del proceso, sin
embargo, mientras que CMM se centra en mejorar la capacidad de la organizacion, PSP se
centra en la mejora de los ingenieros software aplicando la gestion y.control del proceso a
nivel individual. Con PSP los ingenieros desanollan software usando un enfoque
disciplinado y estmcturado, siguiendo un proceso definido y planificando, midiendo,
realizando un seguimiento de su trabajo, gestionando la calidad del producto y aplicando
la realimentacion obtenida para mejorar sus procesos de trabajo individuales.
Entre los beneficios que PSP ofrece a los mgemeros software destacan los
siguientes:
168 CAUDAD DE SISTErvt\S INFORJvV\TICOS
Q Proporciona una selie de principios al ingeniero para llevar a cabo un proceso
personal disciplinado.
Q Asiste a los ingenieros en la realizacion de planes precisos.
Q Detennina los pasos que los ingenieros deben seguir para mejorar la calidad del
producto.
Q Establece bancos de pruebas para medir la mejora del proceso personal.
Q Detennina el impacto que los cambios del proceso tienen sobre el rendimiento
del ingeniero.
Estos resultados son obtenidos haciendo que los partlclpantes recopilan datos
especificos relacionados con el proceso y el producto y estableciendo la linea base que
proporcione a los ingenieros con un contexto para mejorar el proceso.
En la figura 8.5 se muestran los siete procesos que constituyen PSP agrupados por
niveles. Para alcanzar un nivel se deben cumplir los requisitos establecidos en los niveles
previos, 1m1s los nuevos impuestos en dicho nive!. Estos niveles son:

EI Proceso Personal
Ciclico
Desarrollo Ciciico
.' .,
PSP 2.1
Revision Disefio
Revision Codigo Plantillas de Disefio
Gestion Personal de la Calidad
r<. :"::1'" ..... ;.
PSP 1.1
Estimacion TamaRo
Informe Pruebas
Planificaci6n de Tareas
Planificaci6n de Calendario
.
Gestion Personal del Proyecto
I.> ....
PSP 0.1
i.- Medidas Sase del
Estandar de Codificacion
Proceso Actual
Mejora del Proceso
Tamaiio
Medici6n
Linea Base del
Proceso Personal
Figura 8.5. Niveles de Proceso de PSP
Q La Linea Base del Proceso Personal (PSPO y PSPO.l), que proporciona una
introduccion al PSP y establece la base inicial a partir del histolico de datos
de tamai'io, tiempos y defectos. A este nivel los lI1gemeros escriben tres
FECHA
1315:05
I
CAPfTCLO 8: EVALUACION Y MEJORA DE PROCESOS 169
programas y se les pennite usar sus metodos actuales, pero dentro del marco
de trabajo compuesto por los siguientes seis pasos representados en la tabla
8.5:
PASO FASE
I
DESCRIPCIO"l
I Planificar Planificar el trabajo y documentar el plan
:: Diseiiar Diseiiar el programa
3 Codificar Implementar el diseiio
..J.
I
Compilar
Compilar el programa y corregir y registrar los defeetos
encontrados
5 Probar
Realizar las pruebas del programa y cOITegir y registrar
los defeetos encontrados
6 Postmortem
Registrar los tiempos reales de tamaii.o. tiempos y
defeetos en el plan
Tabla 8.5. Pasos de la Linea Base PSP
Las tres medidas base de PSP son: tiempo de desalTollo, defectos y tamafio.
Todas las delmis medidas en PSP son derivadas de las anteliores. EI proceso de
medicion en PSP se introduce desde las tres primeras asignaciones del proceso en
los niveles PSPO y PSPO.l. En las tab las 8.5 y 8.6 y se muestran ejemplos de los
fonnularios que se utilizan para el registro de tiempos y defectos:
FORiVIU4\RIO DE REGISTRO DE TfDIPOS
I
TlEMPO T.
I
!
CmUDZO
I
FI"i
{;I;TERRliP. DELTA
FASE COME2"TARIOS
t
7:58 8:45 3 ..J...J. Planificar Llamada telefono
8:47 10:29 2 100 Diseiiar
Crear y revisar
diseiio
7:.+9 8:59 70 Codifiear
I
Codificar main y
todas las nmeiones
9:15 9:46 31 Compilar Compilar y enlazar
9:47 10:10
I
l'
Probar
I
Ejeeutar pruebas A.
-.)
ByC
4:33 4:51 16 Postmol1em
I
Tabla 8.6. Formulario Ge Regist"ro de Tiempos
o Gestion Personal del Proyecto (PSP 1 Y PSP 1.1). se centra en las tecnicas
para la gestion del proyecto a nivel individual. Se se introducen metodos para
la estimacion del esfuerzo y planificacion y seguimiento de calendario. Las
estimaciones de tamai'io y esfuerzo se realizan usando el metodo PROBE
(Proxy-Based Estimating). con el que los ingenieros usan el tamai'io relativo
del Proxy. como por ejemplo objetos. puntos funci6n. procedimientos. y los
transfonnan a lineas de c6digo (LOC).
I
170 CAUDAD DE SISTEMAS TICOS &; M-Nt\
...
e Gestio" Personal de la Calidad (PSP2 y PSP2.1), afiade metodos de gesti6n
de la calidad a PSP tales como: revisiones personales de disefio y codigo, una
notacion para el disefio, plantillas de disefio, tecnicas de verificacion y
meuicas para gestionar la calidad del proceso y del producto. EI objetivo es
enconu'ar y eliminar todos los defectos antes de llegar a la primera
compilacion, para 10 cual se define una metrica de rendimiento de fin ida como
el porcentaje de defectos inu-oducidos que fueron eliminados antes de la
compilacion. Los nuevos pasos del proceso "revisal' el diseiio" y "revisal' el
c6digo" son incIuidos en PSP2 para ayudar a los ingenieros a obtener un
100% en la meuica de rendimiento. Las revisiones son realizadas por el
ingeniero sobre su propio disefio y codigo, y son revisiones esuucturadas,
diligidas pOl' datos y son guiadas por listas de comprobacion derivadas de los
datos histOlicos de los defectos introducidos por el ingeniero.
FOlUluLARIO DE REGISTRO DE DEFECTOS
..
I I
Il"TRODlJCIDO
I
ELIMll"ADO
I TIE:VJPO
I
DEFECTO
FECRA N" TIPO
Ei"; EN . CORRECCION CORREGIDO ...
13/5/05 1
I
20
I
C6digo
I
COMPIL
I
22
I
Descripci6n Error de sintaxis en sentencia SCGI?l
.
I
I hrRODUCIDO
I
EUlIcUNADO I TlEMPO I
DEFECTO
N TIPO
CORRECCION CORREGIDO
i
Er,\, EN
i
13/5/05 2
I
20
I
C6digo
I
COMPIL
I
[8
I
Descripci6n Error de dec1araci6n de funci6n
N
j
TIPO
I L\TRODuCIDO
I
EUMINADO I
TlEMPO
i
DEFECTO
I
CORRECCIOl" I CORREGIDO
....
EN El"
13/5/05 3-6
I
20
I
C6digo
I
COMPIL
I
1
I
Descripci6n Faltaba:
Tabla 8.7. Formulario de Registro de Defectos
e Proceso Personal Ciclico (PSP3), que resuelve la necesidad de escalar PSP
de manera eficiente a proyectos de n1ayor tamafio sin saclificar la cali dad 0 la
productividad. En este nivel los ingenieros deben aprender a alcanzar la
productividad m<ls alta en un detenninado rango de tamafio. POl' debajo de
este rango la productividad tiende a disminuir debido a costes generales. Por
encima de este range la productividad tambien tiende a disminuir pOl'que se
ha alcanzado el limite de escalabilidad del proceso. PSP3 soluciona este
limite introduciendo una estrategia de desalTollo cicIico en la que los
programas grandes se descomponen en paries que luego son integradas. Esta
esu-ategia asegura que los ingenieros u-abajan en sus niveles mc1ximos de
productividad y calidad con solo costes incrementales. no exponenciales, en
grandes proyectos. Respecto a los niveles anteliores se introducen dos nuevos
fonnularios: un res limen de ciclo para resumir el tamafio, tiempo de
desalTollo y defectos en cada cicIo; y un registro de segllimiento de
!; RA-ivlA CAPiTULO 8: EV ALUACION Y iv[ElORA DE PROCESOS 171
problemas, para documentar los aspectos que pueden afectar a los ciclos
futuros 0 completados. Usando PSP3 los ingenieros descomponen su
proyecto en series de ciclos PSP2.1, y luego integran y prueban las salidas de
cada cicio. Teniendo en cuenta que los programas que se producen con
PSP2.1 son de alta calidad, los costes de integracion y pruebas se minimizan.
3.6. TSP (Team Software Process)
EI Proceso de Software de Equipo (TSP) (Humphrey, 2000a; 2000b) ayuda a
conformar equipos para el desalTollo de software de calidad. TSP proporciona ill1 marco
de trabajo, que se constnlye sobre la base de PSP, con fases de desalTollo bien definidas,
en las que los productos de software se generan en varios ciclos.
Ademas, se establecen medidas estandares para la calidad del producto y para el
desempeilo de los equipos y de los desalTolladores y se aplican evaluaciones por rol y del
equipo, fomentando una disciplina en el proceso y proporcionando una guia para resolver
los problemas del trabajo en equipo. TSP es un proceso que los equipos utilizan para
planificar su trabajo, ejecutar sus planes y mejorar de forma continua sus procesos de
desarTollo software. EI proceso TSP se define a traves de una serie de guiones en los que
se descliben todos los aspectos de planificacion de proyectos y desalTollo de productos.
En este proceso se incluyen las definiciones de los roles del equipo, las mehicas definidas,
y el proceso poshnortem. TSP se considera como una instancia del nivel 5 de CMM,
definida para equipos.
EI origen de TSP se debe a las limitaciones que PSP tenia en el ambito industrial
(McAndrews, 2001). PSP ha tenido un gran exito en entomos academicos y de hecho los
datos obtenidos de los almTIl10s que han aplicado PSP han sido muy consistentes. Este
hecho creo una evidencia muy significativa sobre los beneficios que los ingenieros
obtendrian al usar PSP: les pennitiria tener el control de su proceso personal mediante la
mejora de sus habilidades de estimacion y la reduccion de los defectos inh'oducidos en los
productos sin afectar a su productividad. Sin embargo no quedaba claro como los
ingenieros podrian aplicar estas habilidades en la pnictica dentro de las empresas. Como
resultado no se aplico PSP de fonna efectiva en la indushia salvo en algunas empresas.
Ademas, se descubrio en empresas fonnadas en PSP, que los gestores no proporcionaban
el entomo necesario e incluso volvian a repetir las mismas practicas caoticas que
utilizaban antes de aprender PSP. Como consecuencia, Humphrey desalTollo el Team
Software Process como una respuesta operacional al problema de implementar PSP en
equipos dentro de las organizaciones. PSP cubre solo las fases de desalTollo de software
desde el disefio a las pruebas unitarias. Era necesario un proceso mas practico que cubriera
tambien los requisitos, las pruebas de integracion, la documentacion y otras actividades
tipicas en todo proyecto de desalTollo. Por otro lado, TSP debia incluir otros aspectos
importantes como los roles de equipo, intelTelaciones dentro de la organizacion y la
definicion de un proceso de equipo para ser utilizado dentro de los procesos existentes en
la organizacion.
172 CAUDAD DE SISTEMAS I?\FOR\LATICOS
TSP proporciona un proceso operacional definido para guiar a los ingenieros y
gestores sobre los pasos necesarios en la construcci6n de equipos. Los procesos
operacionales son procesos que definen de fonna precisa el trabajo a realizar y se
consideran como guiones mas que como las desclipciones textuales muy extensas que
aparecen en los libros de definici6n de los procesos de la organizaci6n. Estos guiones son
disei'iados para facilitar su uso pOl' los miembros de equipo cuando estan realizando su
trabajo. El proceso especifica los pasos necesarios para establecer un ent0l110 efectivo de
trabajo en equipo. Sin una guia especifica los ingenieros tienden a saltarse pasos, 0
realizarlos en un orden poco productivo, 0 gastando tiempo pensando que hacer despues.
TSP les proporciona los procesos operacionales necesarios para fOlmar equipos de
ingenietia, establecer un ent0l110 de equipo efectivo y guiar a los equipos a la hora de
realizar su trabajo.
TSP para calldad
de los productos
score coste
calsilcL::rio
Figura 8.6. Relacion entre PSP, TSP Y C:\<L\I/C\BH
En la figura 8.6. se muestra la relaci6n de TSP con PSP y el modelo CMM. CMM
proporciona el marco de trabajo general de mejora necesario para un trabajo efectivo de
ingenietia en una organizaci6n. PSP proporciona las disciplinas que los ingenieros
software necesitan para usar de forma consistente un proceso definido, planificado y
medible. TSP acopla los principios de los equipos de producto integrados con los metodos
de PSP y CMM para producir equipos efectivos de trabajo. CMM y PSP proporcionan el
contexto y las habilidades para una ingenietia efectiva mientras que TSP guia a los
equipos a realizar realmente el trabajo necesario, de fonna que TSP se basa en la
preparaci6n que se adquiere de PSP y CMM proporcionando ademas una guia explicita
sobre c6mo realizar el trabajo.
C\PiTCLO 8: E\-ALCACIO;-'; Y :VIEJOR--\ DE PROCESOS 173
Antes de que los miembros puedan participar en un equipo TSP, deben conocer
como realizar un trabajo disciplinado. Tal y como se muestra en la figura 8.7, es necesario
que los ingenieros que usan TSP esten f0I111ados en PSP. La f0I111acion en PSP incluye el
aprendizaje necesario para: realizar planes detallados, reunir y usar datos del proceso,
desarTollar planes. usar los valores obtenidos (earned vallles) para realizar un seguimiento
del proyecto, medir y gestionar la calidad del producto y definir y usar procesos
operacionales. En TSP, la tar'ea de construir el equipo es un proceso de planificacion de
cuatro dias denominado lanzamiento del equipo (team launch). En este proceso, todos los
miembros del equipo desarTollan la estrategia. el proceso y el plan para hacer su proyecto.
El lanzamiento del equipo esta compuesto por nueve reuniones, cada una de las cuales
tiene un guion con las actividades a seguir descritas en detalle y que el entrenador
(denominado "'alil/ch coach ") utiliza para guiar al equipo. Como resultado se obtiene un
plan, en los que todos los miembros del equipo deberian haber participado y con el que
deben estar comprometidos. Una vez completado este proceso inicial, el equipo sigue su
proceso definido para hacer el trabajo necesario.
Construcci6n de
Habilidades
Planes Personales
de Planifjcacion
Valor Obtenido
(earned value)
Datos del Proceso
rledidas de Calidad
Proceso5 Definidos
Disciplinas de
Ingenieria
Construcci6n de Equipos
Compromiso
Planes AgresivQs
Propiedad de la Calidad
Netas del Proyecto
Detalle del Plan
Roles del Equipo
Recursos de! Equipo
Disciplinas de
Equipo
Equipos
Integrados de
Productp
Trabajo en Equipos
Prioridad de la Calidad
Coste de la Cali dad
Seguir el Proceso
Revisar el Estado
Revisar la Calidad
Comunicacion
Gestion del Cambia
Disciplinas de
Gesti6n
Figura 8.7. Formaci6n de Equipos en TSP (Humphrey, 2000b)
De acuerdo a TSP, los equip os S011 relanzados periodicamente. Ello se debe a que
TSP sigue una estrategia de desarrollo iterativa y evolutiva, 10 que hace que los
relanzamientos periodicos sean necesarios de fonna que cada fase 0 cicio pueda ser
planificado de acuerdo al conocimiento obtenido en los ciclos previos. El relanzamiento
tambien es necesario para actualizar los planes detallados de los ingenieros, que
nonnalmente son precisos solo para unos pocos meses. En cada relanzamiento los equipos
hacen un plan global y un plan detallado de los tres meses 0 cuatro meses posteriores.
174 CAUDAD DE SISTEMAS INt'ORt'vl.A. TICOS RA-lvLi\
Durante cada lanzamiento del equipo tambien se elabora el plan de calidad. Para
gestionar la cali dad los equipos establecen metricas y objetivos de calidad asi como planes
para alcanzar dichos objetivos y los medios para conocer el progreso y llevar a cabo
acciones cOlTectivas cuando no se satisfacen los objetivos. TSP ensei'ia a los equipos como
deben realizar este proceso de gestion de cali dad mediante guiones en los que se definen
las metric as a usaI' como parte del proceso. Las metricas pueden ser de tamafio (pOl'
ejemplo en miles de lineas de cOdigo, KLOC), tiempo (en minutos y horas), calidad (en
fonna de defectos), rendimiento del proceso (% de defectos eliminados antes de una fase
detem1inada) y densidad de defectos (defectosIKLOC) de los productos obtenidos. En
TSP se establece como estas metricas son definidas, estimadas, recopiladas, presentadas y
analizadas. Tambien se hace uso en el proceso de datos histolicos de los equipos, y de
lineas guia sobre calidad y planificacion.
Algunos ejemplos de expeliencias industriales en la aplicacion de TSP pueden ser
consultados en (Humphrey, 2000a) y (McAndrews, 2001). Desde el punto de vista
academico, Oktaba e IbargHengoitia (2002) demuestran al usaI' TSP como mater1al
didactico de apoyo que se fomenta el aprendizaje a u'aves de la practica obteniendose
importantes beneficios para los alumnos como: f0l111acion en el proceso de desalTollo
incremental e iterativo: roles y responsabilidades bien definidos: incorporacion de las
met11cas en el proceso de desarTOllo: uso de tecnicas de inspeccion y revision de los
productos: insistencia en la estandar1zacion de la documentacion y del c6digo y analisis
post-mortem.
3.7. People Capability Maturity Model (Peopie=CMM)
El modelo de madurez de capacidad de las personas (People Capability iv/aturity
,Hodel. People CMM) (CUltis et al., 2001) es un marco de trabajo que ayuda a las
organizaciones a resolver de fonna exitosa los aspectos ctiticos relacionados con sus
recursos humanos. Esta bas ado en las mejores practicas en campos como los recursos
humanos. la gestion del conocimiento y el desalTollo organizacional para guiar a las
organizaciones a la hora de mejorar sus procesos de gestion y desalTollo de sus
empleados. People CMlv/ proporciona un pr:,ograma de desalTollo continuo de los
empleados, establece pri0l1dades para acciones de mejora. integra el desalTollo de los
empleados con la mejora de procesos y establece una cultura de excelencia.
El modelo People CMM esta disefiado sobre la premisa de que las practicas de
mejoras de los empleados no tendran exito al menos que el compOltamiento de la
organizacion cambie para darles sopOlte. Es un modele basado en el proceso que asume
que las practicas de los empleados son procesos estandares de la organizacion que pueden
ser mejorados de fonna continua mediante los mismos metodos que se utilizan para OUos
procesos de negocio. People OHM consiste en cinco niveles de madurez a traves de los
cuales las practicas y procesos de las fuerzas de trabajo van evolucionando. Estos niveles
establecen las bases necesa11as para la mejora continua de las competencias individuales,
el desalTollo de equipos efectivos, la motivacion en la mejora del rendimiento y el
CAPiTULO 8: EVALUACION Y MEJORt'.. DE PROCESOS 175
establecimiento de las fuerzas de trabajo que la organizacion necesita para llevar a cabo
sus planes de negocio.
Desde la perspectiva de People ClvIM, la madurez de la organizacion se deliva de
las pnicticas de fuerzas de los empleados que son realizadas de forma rutinaria y el punto
hasta el cual estas pnicticas han sido integradas dentro de un proceso institucionalizado
para mejorar su capacidad. En una organizacion madura, los individuos responsables
realizan pnicticas repetibles como requisitos ordinarios y esperados de acuerdo a su puesto
de trabajo. A medida que una organizacion es mas madura, mayor capacidad tiene para
atraer, desanollar y retener el talento que necesita para ejecutar sus negocios. En la figura
8.8 se muestran los niveles de madurez de People Cj\;IM y la naturaleza de las
tranSf0l111aciones impuestas sobre las practicas del personal de la organizacion a la hora de
alcanzar cada nivel.
Practicas
de Mejora
Continua
Pr<3cticas
Medidas y
Autorizadas
Practicas
basad as en las
competencias
Practicas
Repetibles
Figura 8.8. NiYeles de i'Iadurez de People.-CMM (Curtis et a/., 2001)
Con la excepcion del nivel inicial, cada nivel de madurez en People CMM esta
caractelizado por un conjunto de practicas intelTelacionadas entre si y relativas a areas
critic as de gestion de fuerzas de trabajo.
En el nivel inicial, las organizaciones tienen dificultades para retener a los
individuos con talento y a pesar de su importancia. las practicas de los empleados son ad
hoc e inconsistentes. En algunas areas no existen definidas practicas para los empleados y
en las que existen, el personal no esta fonnado para llevarlas a cabo. E1 primer paso hacia
1a mejora de la capacidad de los empleados consiste en obtener directores que asuman las
actividades de los empleados como responsabilidades de alta pliOlidad. Las practicas
176 CAUDAD DE SISTEMAS INFORM:\TICOS
implementadas en el niveI gestionado se cenh'an en la atencion del director sobre
aspectos a nivel unitario como dotacion de personaL compromisos de coordinacion,
proporcionar recursos, gestionar el rendimiento, tomar decisiones de compensacion, etc,
Por 10 tanto, el nivel 2 de madurez se cenh'a en establecer pnicticas base dentro de las
unidades que resuelva los problemas mas ilUl1ediatos y prepare a los directores para
implementar pnicticas mas sofisticadas en niveles superiores, Las organizaciones que
estan en nivel 2, se encuentran con que aunque esten realizando practicas basicas de los
empleados, existe inconsistencia en como estas practicas son llevadas a cabo a traves de
distintas unidades, con la consiguiente falta de sinergia en la organizacion.
En el niveI definido, la organizacion construye un marco de h'abajo de
competencias de los empleados a h'aves de toda la organizacion. Cada competencia de
empleado es un elemento de la arquitectura y se descliben las interacciones entre estos
elementos mediante dependencias entre los procesos basados en competencias, Esta
arquitectura es de caracter esh'ategico y por 10 tanto debe evolucionar de acuerdo a la
evolucion de las cOlldiciones de negocio y de la tecnologia, En el nivel definido la
organizacion adapta sus empleados a las necesidades de negocio mediante el desanollo de
competencias. Una vez definidas las competencias, la fon11acion y las practicas de
desanollo pueden ser mas sistematicamente enfocadas en desmTollar el conocimiento y las
habilidades necesmias. A este nivel las practicas de los empleados implementadas en el
nivel 2 estim ahora estandarizadas y adaptadas para animar y recompensar el crecimiento
de la organizacion en sus competencias de fuerzas de h'abajo,
En el niveI predecibIe. la organizacion gestiona y explota la capacidad creada en el
nivel antelior. En este punto, la organizacion es capaz de gestionar su capacidad y
rendimiento de fon11a cuantitativa y ella Ie pelmite predecir su capacidad para realizar su
trabajo. Denh'o de cada unidad 0 grupo de h'abajo, se mide el rendimiento a la hora de
realizar los procesos basados en competencias que son criticos para los objetivos de
negocio, Las medidas obtenidas son utilizadas para establecer las lineas base del
rendimiento del proceso y valorar los procesos basados en competencias que requieran
acciones de mejora,
En el nivel optimizante, la organizaclon al completo se cenh'a en la mejora
continua. La organizacion usa los resultados del nivel anterior para guiar las mejoras de
este niveL Estas mejoras estan Olientadas a la capacidad de los individuos y grupos de
trabajo, al rendimiento de los procesos basados en competencias y a las practicas y
actividades de los empleados,
Cada nivel de madurez, excepto el inicial, consiste en un grupo de entre h'es a siete
areas de proceso, cada una de las cuales identifica un grupo de practicas relacionadas que
cuando se realizan de fon11a colectiva obtienen un conjunto de objetivos considerados
importantes para extender la capacidad de los empleados,
RA,-\IA CAPiTULO 8: EVALUACIO:-': Y :VIEJORA DE PROCESOS 177
4. EL ESTANDAR ISO/lEe 15504
EI estimdar ISOiIEC 15504 (ISO, 2004a; 2004b; 2004c: 2004d: 2006)
proporciona un marco de trabajo para la evaluacion de procesos sofhvare y establece los
requisitos minimos para realizar una evaluacion que asegure la repetibilidad y consistencia
de las valoraciones obtenidas, La evaluacion del proceso es aplicable en el contexto de
una organizacion que acrua en su nombre 0 representando otra organizacion para:
entender el estado de sus propios procesos con el fin de mejorarlos; detenninar la
capacidad de los procesos de otra organizacion a a'aves de un contrato; detenllinar la
capacidad de sus propios procesos ante un requisito 0 clase de requisitos en particular. La
parte info1111ativa del estimdar proporciona la guia necesmia sobre como utilizar un
proceso de evaluacion dentro de un programa de mejora 0 dentro de un tipo de proceso
para la detenninacion de la capacidad,
El estandar esta compuesto por cinco partes (que sustituyen las nueve partes de la
wrslOn anterior de 1998), y de las cuales la quinta se encuentra actualmente en
preparacion. EI contenido de cada una de estas partes se resume en la tabla 8.8.
PARTES DEL-\.;\OR'Y!A
ISOfIEC 15504
I CO!'iTENIDO
, II Proporciona una introduccion general a los conceptos de la e\'aluacion de
L Conceptos y Vocabulario
los procesos y un 2:10sario de tenninos relacionados,
Realizaeiol1de la
Evalu3cion
I
Establece los requisitos minimos necesarios para realizar una evaluacion
que garantice la consistencia y repetibilidad de las valoraciones, Los
I
requisitos ayudan a asegurar que la valoracion de salida es consistente y
proporciona la e\'idencia necesaria para corroborar los resultados y verificar
su contonnidad con los requisitos,
3: Guia,paralaRealizacionde I Proporciona una guia para interpretar los requisitos a la hora de realizar una
Ia Evaluaci6n e\'aluacion,
4., Guia sobre eI
Mejora de! proceso y ]a
Detemlinaci6n dela
Capacidad del Proceso
5, UnEjemplo de iyfodelo de
EvaIu3cionde Procesos(en
preparaciol1)
I
Identifica la E\'aluacion del proceso como una actividad que puede ser
realizada como parte de una iniciativa de mejora de procesos 0 como parte
de un enfoque de detenninacion de la capacidad, EI proposito de la mejora
de los procesos es mejorar de fonna continua la eficiencia y efecti\'idad de
la organizacion, El objetivo de la detem1inacion de la capacidad es
identificar las fortalezas. debilidades y riesgos de los procesos
seleccionados respecto a un reqhisito particular especificado a trm'es de los
procesos utilizados y de su alineamiento con las necesidades de negocio,
Contiene un ejemplo de un modele para realizar la evaluacion de los
procesos basados en el modelo de referencia de procesos definido en el
estandar ISO/TEC 12207, Una evaluacion se !leva a cabo utilizando un
modele de evaluacion de procesos relacionado con uno 0 mas model os de
referencia de rocesos,
Tabla 8.8. Contenido de ISO/IEC 15504.
El objetivo de la evaluacion del proceso es conocer la capacidad de los procesos de
una organizacion. Como resultado de una exitosa implementacion de la evaluacion de los
procesos se detennina la infonnacion que caracteriza los procesos evaluados y el punto
178 CAUDAD DE SISTEMAS INFOR!\tA. TICOS
RA,-MA
hasta el ellal los proeesos realizan Sll prop6sito, En la figura 8.9 se mllesh-an las
aetividades y las entradas y salidas del proceso de evaluaci6n de ISO 15504.
Entrada Inicial
- Proposlto
- Alcance
- Restriccion:;;s
- Jdentidades
Modelo de Referencia
del Proceso
Marco de Trabajo
de la Medici6n
r-""""'11r----i -Nivelcs de Capacidad
- Atributos del Proceso
- Dominic y Alcanc,:;
- EsciJ.!a de VaJoracion
- Propos ito del Proceso
- Resultados del Proceso
Modelo de Evaluaci6n del Proceso
- Alcance
- Indicadores
- Correspondencia
- Interpretacion
Salida
Proceso de Evaluaci6n
- Planificaci6n
- Recopilacion de Datos
- Validacion de Datos
- Fectla
- Entrada de !a Evaluaci6n
- !dcntificacl6n de la E'Iid2ncia
- ?rocesD d<;: =valua:;16n utiilzadc
de Competencla
Valoraci6n Je los Atributos del Proceso
- Generacion de Informes
Roles y Responsabilidades
- ?3Irocinaoor
Figura 8.9. EI proceso de Eyaluacioll del Estalldar ISO 15504.
Como se puede obselTar en la figura 8.9, en todo proceso de evaluaci6n se incluye
una entrada inicial donde se establece el alcance, proposito, restricciones, etc., la
infol111acion sobre los recursos y las responsabilidades necesarias asi como las
caracteristicas de las salidas a obtener. Otros elementos significativos del proceso de
evaluacion son los siguientes:
o Modelo de Referencia de Procesos, que describe un conjunto de uno 0 mas
procesos en tel1ninos de su propos ito y de los resultados esperados. El
proposito describe los objetivos a alto nivel que se deberian realizar mientras y
los resultados esperados des crib en los resultados que se deberian obtener tras
una exitosa ejecucion de dichos procesos. Los estandares ISO/IEC 12207: 1995
y ISO/lEC 15288 proporcionan modelos de referencia de procesos.
o Marco de Trabajo de Medici6n para la Capacidad del Proceso, que define
una escala ordinal de seis valores para representar la capacidad del proceso
(figura 8.10) que varia desde los procesos que no son capaces de realizar su
propos ito (nivel 0) a los procesos que optimizan su rendimiento de f0l111a
continua (nivel 5). Dentro del marco de trabajo cada medicion de la capacidad
se basa en un conjunto de atlibutos del proceso (Process Attributes, PA). Cada
ahibuto define un aspecto particular de la capacidad del proceso y el conjunto
de ahibutos constituye el perfil del proceso (Process Profile, PP). Cada
atributo se caracteriza por Sll valor, que indica el punto hasta el cual se realiza
CAPiTULO 8: EVALUACION Y ivfEJOR.A. DE PROCESOS 179
dicho atlibuto. Los valores estan definidos de acuerdo a la siguiente escala: no
conseguido (del 0 al 15% de realizaci6n), parcialmente conseguido (del 15 al
50% de realizaci6n), bastante conseguido (del 50 al 85% de realizaci6n) y
completamente conseguido (mas de 85% de realizaci6n). La combinaci6n del
grado de realizaci6n de los atlibutos de proceso para un detenninado grupo de
attibutos detennina el nivel de capacidad del proceso. Aunque los atlibutos se
definen de fonna que puedan ser puntuados de fonna independiente, ella no
implica que no existan relaciones entle ellos. Por ejemplo, el grado de
realizaci6n de un atlibuto podria estar relacionado con la realizaci6n de otlo
atributo dentro de la dimensi6n de la capacidad.
Figura 8.10. :\iveles de capacidad de Procesc en ISO/lEe 15504
I Modelo de Evaluacion del Proceso, que proporciona el mecanismo
mediante el cual se relacionan los modelos de evaluaci6n del proceso y el
marco de trabajo de la medici6n. Los modelos de evaluaci6n se basan en las
desClipciones de proceso incluidas en los modelos de referencia del proceso.
Con el fin de asegurar que los resultados de la evaluaci6n son traducibles a
un perfil de proceso de ISO 15504 de- una fonna fiable y repetible, los
modelos de evaluaci6n deben adhelirse a cielios requisitos, de f0l111a que un
modelo de evaluaci6n de procesos es confonne si: es adecuado de acuerdo al
prop6sito de la evaluaci6n; sus elementos relevantes se cOITesponden con los
procesos desclitos en el modelo de procesos de referencia y con los atlibutos
de proceso desclitos en la segunda parte de ISO 15504; constituye la base
para obtener, durante la evaluaci6n, la infonnaci6n sobre los productos y
procesos mediante un conjunto de indicadores; tiene un mecanismo fOlmal y
velificable para expresar la infonnaci6n tomada. En la parie 5 del estandar se
muestra un ejemplo de modelo de referencia de evaluaci6n del proceso
bas ado en el modelo de referencia de la ISO 12207. Un modelo de
evaluaci6n del proceso esta relacionado con uno 0 mas l110delos de referencia
180 CAUDAD DE SISTE\!AS I"-JFOR\Li. TICOS
de procesos. Constituye la base para la obtencion de la evidencia necesaria
para valorar la capacidad del proceso. EI modelo de evaluacion proporciona
una vista bidimensional de la capacidad del proceso. En una dimension, se
desclibe un conjunto de entidades del proceso relacionadas con los procesos
del modelo de referencia. En la otra dimension el modelo de Evaluacion
describe las capacidades que se relacionan con los niveles de capacidad del
proceso y los atlibutos de proceso definidos en ISO 15504.
Ii) Herramientas de Evaluacion, que deben dar soporte a la reunion, registro.
almacenamiento, analisis, recuperacion y presentaci6n de los datos de la
evaluacion. Para ella puede ser necesario el uso de varias helTamientas que
pueden ser "paper-based', como f0l111Ularios, cuestionarios 0 listas de
comprobacion, y helTamientas software para casos en los que el volumen y
complejidad de los datos es mayor.
EI proceso de evaluacion esta compuesto por las siguientes actividades:
II Planiticacion. en e1 que se debe desarrollar un plan de 1a eva1uacion en e\
que a1 menos se deberia incluir: las entradas requeridas que estan
especificadas en el estandar, las actividades a realizar para \levar a cabo 1a
evaluacion. los recursos y e1 calendario asignado a las distintas actividades, la
identidad y responsabi1idades de los participantes en la evaluacion. los
criterios para velificar que se cump1en los requisitos del estandar y una
desclipcion de las salidas planificadas de la eva1uacion.
Ii) Recopilacion de datos, en 1a que se deben obtener los datos requeridos para
evaluar los procesos dentro del alcance de la eva1uacion e inf0l111acion
adicional. Esta recopilacion debe realizarse de una f0l111a sistematica y debe
contemplar la estrategia y las tecnicas necesarias para la seleccion, obtencion.
analisis de los datos y una justificacion de las valoraciones realizadas.
Ii) Validacion de los datos, para COnfil111ar de f0l111a objetiva 1a evidencia de
los datos obtenidos: asegurar que 1h evidencia es suficiente y representativa
para cubrir el alcance y proposito de la evaluacion; asegurar que los datos son
consistentes en su conjunto.
Ii) Valoracion de los Atributos del Proceso, de f0l111a que se les asigna una
puntuacion en base a los datos validados. El conjunto de puntuaciones de los
atributos del proceso debe ser registrado en el perfil del proceso para la
unidad organizacional definida. Durante la evaluacion, el conjunto de
indicadores definidos en el modelo de evaluacion del proceso se debe usar
para dar soporte a los asesores a la hora en puntuar los atJibutos del proceso
con el fin de establecer la base para la repetibilidad en las diferentes
evaluaciones. Se debe registJ'ar el proceso de toma de decisiones utilizado
C\PiTUO 8: EVALF-\CIO;-'; Y Y[EJOR.-\ DE PROCESOS lSI
para derivar las puntuaciones y se debe mantener la trazabilidad entre las
puntuaciones de los atlibutos y las evidencias utilizadas para detel111inar
dichas puntuaciones.
e Generacion de Informes. en los que se presentan los resultados de la
Evaluacion asi como el minimo de salidas de la evaluacion exigidas de
acuerdo al estandar.
5. CMMi Y SCAMPI
El exito y amplia aceptacion de CMM propicio la aparicion de modelos similares
inc1uso en otras disciplinas ademas del software. Esta proliferacion de modelos ha
facilitado la aparicion de conflictos en los objetivos y tecnicas de la mejora de procesos,
debido al considerable incremento en el entrenamiento requerido, y a la confusion por
parte de los que los aplican. de cm'!l de los modelos usar segLll1 sus necesidades
especificas. CMMI constituye un solo modelo que cubre mLlltiples disciplinas y se creo
con el objetivo de eliminar esas desventajas.
El proyecto CMMI persigue objetivos tanto a corto como a largo plazo. Los
objetivos iniciales (los cuales se llevaron a cabo en el 2000 con la publicacion de la
version 1.0 de los modelos CMMI-SE/SW y CMMI-SESWiIPPD) consistian en integrar
tres modelos de mejora de procesos especificos: software, ingenieria de sistemas y
desaITollo de procesos y productos integrados. CMMI-SE/S\V especifica el 1110delo
CMMI que contiene las disciplinas de ingenieria de sistemas y software.
CMMI-SE/SW/IPPD indica el modelo que afiade material para la integracion de procesos
y desaITollos de procesos ell CMMI-SE/SW. Esta integracion fue propuesta para reducir
el coste de la mejora de procesos basados en modelos e implementados mediante varias
disciplinas de la siguiente manera:
e Eliminando inconsistencias.
e Reduciendo duplicaciones.
e Incrementando la claridad y comprension.
e Proporcionando terminologia C01111111.
e Proporcionando estilos consistentes.
e Estableciendo reg las de construccion unifon11es.
e Manteniendo componentes comunes.
e Asegurando la consistencia con ISO 15504.
e Siendo susceptible a la inferencia de esfuerzos legales.
l82 CAUDAD DE SISTEivLA.S Ij\IFORMATICOS fJRA-MA
Los objetivos a largo plazo consisten en establecer la base necesaria para la
posterior inclusion de otras disciplinas (tales como adquisicion y seguridad). Para facilitar
ambos modelos de integracion actuales y fuhlroS, el equipo de desalTollo de CMMI creo
un marco de trabajo automatizado y extensible y definio reglas para la posible inclusion
de mas disciplinas dentro de este marco de trabajo. Los modelos en los que se basa CMMI
son los que aparecen en la tabla 8.9.
DISCIPLINADEL
MODELO FUENTE DESCRfPCION MODELO FUE1';lE
MODELO .... .'.
Modelo que describe los principios y pnicticas
fundamentales de la madurez de procesos software.
El CMM para software El CMM est! organizado para ayudar a la
Software (SW-CMM) organizaciones de software a mejorar mediante una
trayectoria evolutiva, creciendo con fines especificos,
desde un ambiente ca6tico hacia unos maduros y
disciplinados procesos de software
Modelo de Capacidad de Integraci6n de todas las disciplinas de sistemas para
Ingenieria de Sistemas Ingenieria de Sistemas que conozcan las necesidades tecnicas y de negocio
(ELMS 731) de la fom1a Im1s efectiva
Proceso integrado de
Desarrollo integrado de Enfoque sistematico para el desarrollo del producto
desarrollo de
producto CM!v! que incrementa la satisfacci6n del cliente mediante
productos
(IPDCMNI) una colaboraci6n oportuna de las disciplinas
necesarias a 10 largo del cicio de vida del producto
Tabla 8.9. Modelos de CMMI
Un concepto fundamental de todos los modelos CMMI es el area de procesos. No
to do 10 relacionado con procesos y mejora de procesos esta incluido en un modelo de
mejora de procesos. Como sus predecesores, CMMI selecciona solo los aspectos mas
importantes de la mejora de procesos y entonces agrupa estos aspectos denu"o de "areas".
Desde el punto de vista de los contenidos del modelo CMMI, hay que indicar que
en este modelo se hace una distincion de los 111ismos en tres categorias principales, que
por orden de importancia son: requerido, esperado e infonnativo.
e Material requerido. Es esencial para el modelo y para la comprension de que
es necesalio para la mejora de procesos y para hacer demosu"aciones de
confonnidad con el modelo. EI lmico componente requelido del modelo
CMMI es el "objetivo". Un objetivo representa un estado final deseable, un
hecho notable, el cual indica que se ha conseguido un cielto grado del proyecto
y un cielto control de los procesos. Cuando un objetivo es unico en un area de
procesos simple, se Ie llama un objetivo especifico. En contraste, cuando un
objetivo puede aplicarse a todas las areas de procesos, se Ie llama un objetivo
generico. Cada area de procesos tiene enu"e uno y cuatro objetivos especificos.
Ri\.-ivLA. CAPiTULO 8: EV ALUACION Y MEJORA DE PROCESOS 183
La versi6n 1.0 del modelo CMMI-SE/SWIIPPD abarca un total de cincuenta y
cuatro (54) objetivos especificos.
EI Material esperado. No es un matelial esencial para el modelo, y en algunos
casos, podda no estar presente en una organizaci6n que use el modelo CMMI
con exito. Sin embargo, el material esperado se considera que juega un papel
fundamental en la mejora de procesos. EI lmico componente esperado del
modelo CMMI es la declaraci6n de una "Pnictica". Una pnictica representa el
metodo "esperado" para el cumplimiento de un objetivo. Cada pnictica en el
modelo CMMI esta destinada exactamente a un objetivo.
EI Material Inforrnativo. Es el mas extenso y constituye la mayoda del modelo.
Proporciona una guia lltil para mejorar los procesos, y ofrecer una mayor
clmidad para la comprensi6n de los componentes requeridos y esperados.
Otro aspecto impOliante y muy nove do so en el modelo CMMI, es que usa dos
tipos de representaciones de sus modelos, incluyendo de esta f0l111a la representaci6n de
CMM y la representaci6n de ISO 15504: representaci6n por etapas y continuo.
5.1. Representacion por eta pas
Un modelo por etapas proporciona un marco predefinido para la mejora
organizacional basada en el agrupamiento y ordenaci6n de procesos y en las relaciones
organizacionales asociadas. EI tennino "por etapas" viene de la fonna en la que elmodelo
describe este marco como una serie de "etapas", denominadas "niveles de madurez". Cada
nivel de madurez tiene un conjunto de areas de procesos que indican en que aspectos
debeda centrarse una organizaci6n para la mejora sus procesos. Cada area de procesos
esta descrita en tenninos de practicas que contribuyen a satisfacer sus objetivos. Las
practicas describen la infi-aestmctura y actividades que mas contribuyen en la
implementaci6n e institucionalizaci6n efectiva de las areas de procesos. EI progreso
ocurre satisfaciendo los objetivos de todas las areas de proceso en un nivel de madurez
detel111inado. EI CMM para software es el ejemplo primordial de modelo por etapas. En la
figura 8.11 se muestra la estructura de la representaci6n por etapas.
Como se puede observar en la figura 8.11, la representaci6n por etapas se estmctura
en t0l110 a niveles de madurez, que se van alcanzando en la medida que se cumplen en la
organizaci6n las areas clave de proceso asociadas a cada nivel de madurez. Esta
representaci6n pennite evaluar los procesos de una organizaci6n para establecer la
madurez global de la misma.
18.+ CAUDAD DE SISTEL-\S
Figura 8.11. Representacion por etapas de CMMI
En la representaclon por etapas las areas son agrupadas dentro los niveles de
madurez que van del nivel2 al5 (figura 8.12).
Mejora Continua del Proceso
(2 ,A.reas de Pieceso)
Gesti6n \.,uam.lIa'Clva
(2 Areas de Proceso)
\,11 Areas ce ProceSO)
(7 Areas ce Pro:eso)
- Gl""'>lion lnlli.;rm.la del
(lS.\j,
(01'1))
Figura 8.12. Clan de Proceso agrupadas segun la representacion pOl' etapas
(Philips, 2001)
:. RA-ivLA. CAPiTULO 8: EV ALUACION Y lv!EJORA DE PROCESOS 185
5.2. Representacion continua
Los modelos continuos proporcionan una guia menos especifica con respecto al
orden en el cual deberia realizarse el proceso de mejora. Se denominan continuos porque
ninguna etapa discreta esta asociada con la madurez de la organizacion. Como los
modelos por etapas, los modelos continuos tienen areas de procesos que contienen
practicas. A diferencia de los modelos por etapas, las practicas de un area de procesos en
un modelo continuo estin organizadas de fonna que dan sopOlte a la mejora y al
crecimiento de procesos individuales. La mayoria de las practicas asociadas con la mejora
de procesos son genericas; son extemas a las areas de procesos individuales y son
aplicables a todas las areas de procesos. Las practicas generic as estan agrupadas bajo
niveles de capacidad, cada una de las cuales tiene una defmicion que es casi equivalente a
la definicion de niveles de madurez en los modelos por etapas. El modelo EIAllS 731 es
un ejemplo de un modelo continuo. En la figura 8.13 se muestra la representacion
continua de CMMI.
C
a
p
a
c
i
d
a
d
5
4
3
2
1
o
Representacion Continua
Proceso
Figura 8.13. Representacion Continua de CMMI
Como se puede observar en la figura 8.13, la representacion continua no se
estmctura en tomo a niveles de madurez, sino que 10 que se facilita es la evaluacion de
procesos individuales, pennitiendo que una organizacion pueda seleccionar un conjunto
de sus procesos individuales para evaluarlos y conocer la madurez concreta de dichos
procesos.
Desde el punto de vista de la evaluacion de los procesos, el concepto clave de
CMMI 10 constituyenlas areas de proceso. Elmodelo CMMI-SE/SW/IPPD tiene 24 areas
de proceso que definen la dimension delmodelo. Estas areas son las mismas en todas las
representaciones de la arquitechlra de CMMI. En la representacion continua, las areas de
186 CAUDAl) DE SISTEivL1>,.S INr-GRJ"LA. TICGS
proceso se agrupan por las categorias (figura 8.14): Gesti6n de procesos, Gesti6n de
Proyectos, Ingenieria y Apoyo 0 Soporte.
!
Gestion de I
Proyectos !
- Ellfoqnc Proct:<,o Oq.!,ani/":lcionai - PI:ll1il1C::lcifJIl dd ProYi.:cto
- DciinidtlO ProCl':;O Organizaciollai - :\lonituriL:tciull ) Control dt:
- FOrlll:.ldrlll Org:lOiJacioIl!li
- Rt:ndimicnto
- Inu(n :Jciun Dhrribuciun
Organi/aciollai
d Sumini<.tflluor
- Gestiim Inft:grad:l de Proyt'ctu:,
de Rie\go':!
- Gc .. ti{I[l Cuantirati\a dt:
- Enh'nlc1 p:,:.! b Im;;,;r:!-:i"'ln
- Equipo
- Gl"':!ri6n til' Rl'qubitos - Ge'llit'11l de
_ de Requisitm - A.,i.'gunmlicnro de la CaUdad
_ Tecnica del PrnCl'SO y Pruducto
- del Producto - .\It"dicioll y .\n:iJi:.i<.
_ \'erificacillll - AIl:ilbi<. dt: y
_ Validacion - An:ilhl<, Cl.u,ai y Rt:,o]udtln
- y \!uniwrli'::.:i\';n l::;j
- (j:>l:,"il 11ll:..'gr ... ;.!:.; ,:t:l ...
- (ll>t!,jn C':':.lntlt.,ti .. ;, Jd Sum:ni ... 1L!(h'f
Figura 8.14. Areas Clave de Proceso agrupadas segiin la representacion continua
(Philips, 2001)
5.3. SCAMPI (Standard CMMI Appraisal Method for Process
Improvement)
Para la evaluaci6n basada en el modelo CMMI se usa el metodo SCAlVIPI (SEI.
2001). SCAMPI es un metodo de evaluaci6n aplicable a un amplio rango de modelos de
evaluaci6n, incluyendo tanto las evaluaciones intel11as (valoraciones) como la
detenninaci6n de la capacidad extel11a. SCAlYfPI es un metodo de evaluaci6n de c1ase A
de acuerdo a la c1asificaci6n establecida en ARC- (Appraisal Requirements for Civflvil) y
puede dar soporte a la conducci6n de evaluaciones basadas en ISOIlEC 15504.
SCAMPI incorpora las mejores pnicticas del dominio de evaluaci6n, y esta bas ado
en las caracteristicas de anteriores metodos significativosde evaluaci6n como son:
Eil CMM-Based Appraisal for Intel11al Process Improvement (CBA IPI) v 1.1
Eil Electronic Industlies Alliance/Interim Standard (EIAlIS) 731.2 Appraisal
Method (EIA, 1998).
Eil Software Capability Evaluation (SCE) V3.0 Method Description.
1:RA-MA cAPinJLO 8: EVALUACION Y MEJORA DE PROCESOS 187
Las principales aplicaciones del metodo SCAMPI se resumen en la tabla 8.1 O .
APLICAClON DESCRIPClON
......
.
- La evaluaci6n interna de los procesos se aplica en las organizaciones para:
"
Establecer una linea base de su nivel de capacidadJrnadurez.
"
Establecer 0 actualizar un prograrna de rnejora del proceso.
"
Medir el progreso en la irnplernentaci6n de un prograrna de mejora.
- Las aplicaciones de evaluaci6n interna incluyen:
Mejora Interna del
Proceso
..
Medici6n del progreso de la mejora .
"
Conducci6n de auditorias del proceso.
"
Enfoque sobre domini os especificos 0 lineas de productos.
"
Evaluar proyectos especificos.
"
Preparaci6n para evaluaciones externas conducidas por el c1iente.
Los resultados se usan como factores discriminantes para la selecci6n de
Selecci6n del
suministradores y para establecer los riesgos relacionados con el proceso de
Suministrador
aceptaci6n de un contrato. Constituyen un factor mas de selecci6n y constituyen
la linea base para un posible posterior control de los procesos del suministrador
seleccionado.
Monitorizaci6n del Se puede usar la evaluaci6n como mecanismo de control de los procesos del
Proceso suministrador una vez que ha sido seleccionado.
Tabla 8.10. Aplicaciones del metodo SCAMPI
Al igual que los metodos de evaluacion CBAlIPI y SCE las principales fases de la
evaluacion SCAMPI son:
Planificacion y preparacIOn de la evaluacion, en la que se incluyen el
anaIisis de los requisitos de la evaluaci6n (objetivos, alcance, restricciones,
etc.), el desalTollo del plan de evaluacion, la seleccion y preparacion del
equipo, el conocimiento de las actividades y procesos de la organizacion a
evaluar y la preparacion de las estrategias de recopilacion de los datos.
Realizacion de la evaluacion, en la que se recaba la infom1acion necesaria
para la evaluacion relacionando la infonnacion con el modelo de referencia, se
verifica y valida la infom1acion obtenida, se documentan los datos
transfonmindolos en registros que representen la implementacion de las
practicas y las fortalezas y debilidades y se generan los resultados de la
evaluacion en los que se calculan los niveles de capacidadlmadurez de los
procesos en base a los datos tomados y la aplicacion de algOlitmos de calculo
sobre esos datos.
Informe de resultados, en el que se entregan y archivan los resultados de
fom1a adecuada.
188 CAUDAD DE SISTEwLo\.S
6. MODELOS IBEROAMERICANOS DE MADUREZ Y
EVALUACION
Se estan desanollando y utilizando diversos modelos de madurez en varios paises
iberoamericanos. A continuaci6n se des crib en brevemente algunos de los mas
representativos.
6.1. Mode/o de Referencia para me/horia de processo de
software (MR mps)
La empresa SOFTEX de Brasil, que tiene como misi6n tranSf0l111ar Brasil en un
centro de excelencia mundial en la producci6n y exportaci6n de software, cOOl'dina un
proyecto para la mejora del proceso software denominado (Proyecto mps Br). Este
proyecto engloba dos modelos (Weber y Rocha, 2004):
El Modelo de Negocio para la mejora de proceso de software (MN mps), que
puede ser personalizado para una empresa 0 de fonna cooperativa para un
conjunto de empresas. Las empresas negocian con instituciones acreditadas
para la implementaci6n (ICI) y con instituciones acreditadas para la evaluaci6n
(ICA) de la mejora del proceso software.
El Modelo de Referencia para la mejora de proceso de software (MR pms) que
como se puede ver en la figura 8.15, comprende niveles de madurez y un
metodo de evaluaci6n.
Se contemplan los veintid6s (22) procesos de la nonna ISO 12207 (ISO, 2002), Y
siete (7) niveles de madurez: A (en optimizaci6n), B (cuantitativamente gestionado). C
(definido), D (grandemente/largamente definido), E (parcialmente definido), F
(gestionado), G (parcialmente gestionado). Con esta mayor granularidad en los niveles se
pretende facilitar una implementaci6n mas gradual, adecuada y en plazos mas cortos para
las empresas pequei'ias y l11edianas de Brasil.
EI me to do de evaluaci6n se bas a en la nonna ISO 15504. EI grado de
il11plementaci6n de una practica se evallJa de acuerdo a cuatro niveles: totalmente
il11plementado, bastante implementado, parcialmente implementado, no implementado; y
se basa en tres tipos de indicadores: directos (productos intennedios), indirectos
(documentos que indican que una actividad fue realizada), y afinnaciones (resultantes de
entrevistas ).
En la tabla 8.11 se presentan las reglas para caracterizar el grado de
implementaci6n de las practicas COnf0l111e a SPICE y CMMI.
t R.A.-MA CAPITULO 8: EVALUACION Y i>.fEJOR.A. DE PROCESOS 189
ISOIIEC 12207
ISOIIEC 15504 (SPICE) --__ _
CMMI
Modelo para la Mejora de los Procesos Software (MPS Sr)
Niveles de Madurez -<!,.I----il\lll>
Guiade
lmptementacion
MPS
Instituciones Certificadas para
la Implementacion de MPS
ICll ICI2
Empresa 1
Empresa n
ICln
Guia General
MPS
Metodos de
Evaluaci6n
Gufade
Eva!uacion
MPS
lnstituciones Certificadas para
la Evaluacion de MPS
ICAl ICA2 ICAn
Figura 8.15. Modelo de referencia para la mejora de proceso software (MR pms)
GRADO DE
."
.. GRADODE
Ii\fPLEYIEi'ilAclON CARACTEruzAcroN . ",
DE L.'\ PRACTrCA
ALC.4c"lCE .

Un indicador dirccto esta presente y es juzgado
adecuadamentc.
Totalmente

Existe por 10 menos un indicador yio afimmci6n para confimmr
>85%a
implementado
la impiementaci6n.
100%

No nle observado nimrun defecto substancial

en indicador directo esta presente y juzgado adecuado.
Largamente
Existe por 10 menos un indicaj:lor indirecto y!o atimmci6n para
> 5 ~ o a
implementado
confimmr una implementaci6n.
85%

F ueron observados uno 0 mas defectos.
Parcialmente

Un indicador directo no esta presente 0 es juzgado inadecuado
> 15%a
implementado

Artefactos 0 afirmaciones sugieren que algunos aspectos de la
50%
pnictica estan implementados
No implementado
O%a 15%

Cualquier situaci6n diferente de las de arriba
Tabla 8.11. Reglas para caracterizar el grado de implementacion de las pnicticas en el
MRmps
190 CAUDAD DE SISTEMAS INFOR.!'vLA.TICOS
6.2. Modelos de Procesos para la Industria del Software
(MoProSoft)
RA-M4
Un grupo de expertos mexicanos dirigido por la profesora Hanna Oktaba de la
Universidad Nacional Autonoma de Mexico, a solicitud de la Secretatia de Economia, ha
desanollado un "Modelo de Procesos para la Industria de software (MoProSoft)"
(Oktaba et al., 2005).
Recientemente y basado en este modelo se publico la nonna mexican a NMX-059-
NYCE-2005 "Teenologia de la Iriformacion-Soft1l'are-Modelos de proeesos de
evaluacion para desarrollo y mantenimiento del sofnvare", con las siguientes partes:
e Parte 1: Definicion de conceptos y productos
e Parte 2: Requisitos de Procesos (MoProSoft)
e Parte 3: Guia de implantacion de Procesos
e Parte 4: Directrices para la evaluacion (EvaIProSoft)
El proposito de MoProSoft es fomentar la estandarizacion de su operacion a traves
de la incorporacion de las mejores practicas en gestion e ingenietia de software,
proporcionando a la indusuia de software en Mexico, que en su gran maYOlia es pequefia
y mediana, un 1110delo basado en las l11ejores practicas intemacionales con las siguientes
caractetisticas: facil de entender, facil de aplicar, no ser costoso en su adopcion y ser la
base para alcanzar evaluaciones exitosas con otros 1110delos 0 n0l111as, tales como ISO
9000:2000 0 CMM V 1.1.
Ell11odelo de procesos (MoProSoft) tiene tres categotias de procesos (figura 8.16):
Alta Direccion, Gestion y Operacion que reflejan la estrucUlra de una organizacion.
En cada proceso estan definidos los roles responsables por la ejecucion de las
practicas. Los roles se asignan al personal de la organizacion de acuerdo a sus habilidades
y capacitacion para desempefiarlos. En MOPl:OSOft se c1asifican los roles en Grupo
Directivo, Responsable de Proceso y OUos roles involucrados. Ademas se considera a1
C1iente y a1 Usuario como roles extemos a 1a organizacion.
Las principa1es caracteristicas de las categOlias de procesos de MoProSoft son:
e La categoria de Alta Direccion contiene el proceso de Gestion de Negocio. E1
propos ito de Gestion de Negocio es estab1ecer la razon de ser de 1a
organizacion, sus objetivos y las condiciones para 10grarlos, para 10 cua1 es
necesario considerar las necesidades de los c1ientes, as! como evaluar los
resultados para poder proponer cambios que pennitan la l11ejora continua.
:. RA-ivV\
<<Catecor.a
Alta !).rec6on ~
Proceso
Gesti6n de Procesos
(from Gestion)
Proceso
';dmn:stracf::in de Proyectos Es;;ecifl::os
(from O;;eraci6n)
Desarool:o r'lenten:mento de Software
CA PiTIJLO 8: EVALUACION Y MElORA DE PROCESOS 191
Prcceso
Gestio;'! de r ~ e g o d o
(from Alta D:recckSn)
?roceso
Gestifln de Prayectos
(frem Gestion)
-1---- ---.
<<Cate!; ..
~ O;;eracion
Proceso
G::stl:in de R=cursos
{from Ge:stion)
-_ ..... _----- .---.. ~
<<Su!:l?roceso
genes, Servi::iQs e Inrraestru::tu:-a
{from GestiOn)
<<$wbProceso
<<$utJProceso
Figura 8.16. Categorias y Relaciones de Procesos del modelo MoProSoft
e La categoria de Gestion esta integrada por los procesos de Gesti6n de
Procesos, Gesti6n de Proyectos y Gesti6n de Recursos. El prop6sito de Gesti6n
de Procesos es establecer los procesos de la organizaci6n, en funci6n de los
procesos requelidos identificados en el plan estrategico. Asi como definir,
planear, e implantar las actividades de mejora en los mismos. El prop6sito de la
Gesti6n de Proyectos es asegurar que los proyectos contribuyan al
cumplimiento de los objetivos y estrategias de la organizaci6n. El prop6sito de
Gesti6n de Recursos es conseguir y dotar a la organizaci6n de los recursos
humanos, infraestructura, ambiente de trabajo y proveedores, asi como crear y
mantener la base de conocimiento de la organizaci6n. La finalidad es apoyar el
cumplimiento de los objetivos del plan estrategico de la organizaci6n. Este
ultimo esta constituido por los subprocesos de Recursos Humanos y Al11biente
de Trabajo, Bienes, Servicios e InfraestrlJctura y Conocil11iento de la
Organizaci6n.
e La categoria de Operacion esta integrada por los procesos de Adl11inistr-aci6n
de Proyectos Especificos y de Desanollo y Mantenil11iento de Software.
6.3. Mejora de procesos para fomentar la competitividad de la
pequena y mediana industria del software de
Iberoamerica (COMPETISOFT)
Como sabemos, la industria de software representa una actividad econ6l11ica de
suma il11portancia para todos los paises del mundo, y especialmente para los
iberoal11ericanos, ya que ofrece Imiltiples nlentes de ingresos y empleo y se perfila como
una de las oportunidades mas impOltantes en los paises en via de desalTollo.
192 CAUDAD DE SISTEivlAS I)\iFORlvLA\ TICOS RA-ivLA.
Desafortunadamente, en los paises iberoamericanos la industria de software es
incipiente e inmadura (M&G, 2004), 10 que lleva consigo una falta de competitividad que
dificulta, a su vez, su crecimiento.
A principios de 2006 se ha iniciado el proyecto COMPETISOFT: mejora de
procesos para fomentar la competitividad de la pequefia y mediana industria del software
de Iberoamerica, financiado por el Programa CYTED (Programa Iberoamericano de
Ciencia y Tecnologia para el Desarrollo), en el que participan universidades, empresas,
centros publicos y organismos de estandarizacion de 13 paises de la region, y que se
desarrolla siguiendo el metodo de investigacion en accion como muestra la figura 8.17.
v
Resultados de
la Investigacion
Propuestas
empresas y organizaciones
participantes en el prayecto
(gropo eritico de referencia)
PYMES Iberamericanas
(beneficiarios - stakeholders)
Resultados de
la aplicacion
Mejorade It:isProcesps Software
de las PYMES iberomericimas
(objeto itivestigado)
Itados refinados
Grupos de I+D participantes en el proyecto
(investigador)
Entregables (norm as. modelos, metodos,
herramientas, manuales, etc.)
Figura 8.17. Integracion en el Proyecto Competisoft
Este proyecto pretende aglutinar las diferentes alternativas existentes (como las
resumidas en los epfgrafes anteriores), aprovechando la sinergia y los conocimientos de
los diferentes pafses para conseguir un marco metodologico de ambito verdaderamente
iberoamericano. El hecho de que los pafses iberoamericanos compartan un Modelo de
Procesos, un Modelo de Capacidades y un Metodo de Evaluacion aportara gr-andes
GRA-MA CAPiTULO 8: EVALUACION Y MEJORA. DE PROCESOS 193
ventajas ya que facilitani la colaboraci6n entre empresas de diferentes paises, la movilidad
de los profesionales infonmiticos, el reconocimiento de certificaciones, la compartici6n de
herramientas de desarTollo, y el abaratamiento de los recursos fonnativos. Esto facilitani
un aumento en la calidad y en la cantidad de software desarrollado en Iberoamerica,
aumentando las exportaciones y tambien el nLllnero de factorias de software instaladas en
la regi6n, asi como incrementando el numero de empleados en el sector.
Ahem, D., Clouse, A. y Turner, R. (2003). OVIlvD Distilled: A Practical
Introduction to Integrated Process Improvement, Addison-Wesley, Septiembre
2003. Este libro constituye una referencia muy completa sobre el modelo
CMMI, tanto desde el punto de vista tecnico como de gesti6n. Proporciona a
los lectores los fundamentos y el valor de la mejora de procesos software y les
orienta sobre c6mo llevar a cabo dichas mejoras utilizando el modelo CMMI.
Humplu'ey, W. (1989). j\.;/anaging the Sojhmre Process. Addison-Wesley. Este
libro constituye una de las guias pnicticas 111<is importantes existentes en la
bibliografia sobre la gesti6n de los procesos software desde sus diferentes
puntos de vista. El autor aprovecha su amplia experiencia en organizaciones
como IBM y SEI para proporcionar al lector una guia para la mejora de los
procesos software basada fundamentalmente en el entendimiento y la gesti6n
adecuada de dichos procesos.
Hunter, R. y Thayer, R. (eds) (2001). Sojilmre Process Improvement., Wiley-
IEEE Computer Society Press, November 2001. Este libro recopila lma serie
de alticulos (tanto originales como publicados previamente) relevantes en el
area de la evaluaci6n y mejora de los procesos software en los que describen
diversos estandares y modelos representativos de evaluaci6n, se presentan
guias para realizar las evaluaciones de acuerdo a dicho estandares asi como
experiencias de aplicaci6n de la evaluaci6n y mejora de procesos en las
empresas de software.
Revista Sojilmre Process: Improvement .and Practice, Willey Interscience.
Disponible en http://w\vw3.interscience.wilev.com/cgi-binlihomeI15482. Esta
revista recopila trabajos de investigaci6n y expeliencia practica con el fin de
promover la evaluaci6n y mejora de la calidad, productividad y rendimiento de
los procesos software.
Revista CrossTalk: The Journal of Defense Sojilmre Engineering, Disponible
en: http://w>vw.stsc.hill.af.mil/crosstalkl. CrossTalk, es una revista del
ministerio de defensa de los Estados Unidos con el fin de promover la mejora
de los procesos de ingenieria del software, para 10 cual se incluyen trabajos
representativos tanto de investigaci6n como de aplicaci6n practica.
19.. CAUDAD DE SISTElvL".S Il'\"FORl\-LA.TICOS RA-MA
II Proceedings de las conferencias intel11acionales:
o European So/nmre Process Improvement COl?ference (EUROSPI). En
http://\v\vw.eurospi.netl. EuroSPI es una conferencia de ambito europeo
que u'ata de promover el intercam-bio de experiencias y conocimiento
sobre evaluaci6n y mejora de procesos softwa-re. La conferencia se
divide en dos grandes sesiones: "research track" en la que se exponen
articulos de investigaci6n fundamentalmente provenientes del ambito
academico e; "indusuial track" en la que se presentan experiencias en la
industIia de programas de evaluaci6n y mejora de procesos.
o Product Focused So/nvare Process Improvement (PROFES). LNCS
Springer. El objetivo de esta conferencia intel11acional es proporcionar
un foro a la indusuia y a la academia para la discusi6n sobre los llltimos
resultados de la investigaci6n y la practica en las areas de mejora de
productos y procesos software.
o International COl?ference on So/nvare Process Improvement (ICSPI).
Esta conferencia intel11acional se cenu'a en metodos pnicticos para Ia
mejora de los procesos software de la organizaci6n, independientemente
de los modelos de evaluaci6n. Incluye tanto articulos de indole
academica como industrial.
II www.sei.cmu.edu Software Engineering Institute. Call1egie-Mellon University.
EI Software Engineering Institute es el promotor del CMMI. En este sitio web
se pueden enconu'ar las llltimas versiones del modelo, asi como diferente
infonnaci6n sobre su utilizaci6n. fonnaci6n necesaria, etc. Adermls se pueden
encontrar todos sus modelos y propuestas relacionadas.
CiI http://w\vw.sqi.Q:ll.edu.au/spice/ Software Process Improvement and Capability
dEtermination Website.
CiI http://\V\vw.ipd.uni-karlsruhe.de!mitacbeitel"!111uellem1!PSP Pagina de recursos
del Proceso PSP elaborada por la Universidad de Karslruhe (Alemania).
II http://www2.umassd.edu/SWPI/SWPIpage.html Colecci6n de recursos de
Proceso Software elaborada por la Universidad de Massachussets (Estados
Unidos) en la que se incluyen marcos de u'abajo de procesos software.
materiales para la fonnaci6n, estandares. resultados de la investigaci6n.
mejores practicas y esu'ategias para la mejora de procesos.
II http://www.tantara.ab.ca/info.htm Lista de Distribuci6n sobre Mejora de
Procesos Software. Esta lista, mantenida por una empresa consultora de
Canada proporciona una colecci6n muy completa de enlaces a recursos sobre
mejora de procesos software.
e RA-ivlA. CAPiTULO 8: EVALUACION Y MEJORA DE PROCESOS 195
9. EJERCICIOS
1. Aplicar el proceso de TSP para el desarrollo de dos pequeiios proyectos software
rellenando la infonnacion de tiempos y defectos (vel' tablas 9.6 y 9.7). Realizar
una comparativa de los dos proyectos destacando los progresos obtenidos a nivel
personal.
2. Realizar un estudio bibliognifico sobre la aplicacion de modelos de madurez en
empresas que siguen metodologias agiles.
3. Definir una version del modelo CMMI pOl' etapas adaptada a las pequeiias y
medianas empresas (PyMES).
4. AnalizaI' la confonnidad de la nonna MOPROSOFT con el estandar ISO 15504.
5. DesatTolla la correspondencia entre el estandar ISO 9000 y los modelos CMMI y
MoProSoft.
Otros aspectos de Calidad
de Sistelnas de In{Orlnaci6n
9. l\1edicion de Sistemas de
Info:rmacion
10. CaUdad de la Info:rmacion
11. Gestion del Conocimiento
1. INTRODUCCION
CAPITULO 9
MEDICION DE SISTEMAS DE
INFORMACION
"No se puede contra/ar /0 que 110 se puede medir"
Tom Delvfarco
Una de las razones principales del incremento masivo en el interes por las metIicas
software ha sido la percepcion de que son necesmias para la mejora de la calidad del
proceso (Fenton, 2001). Para poder asegurar que un proceso 0 sus productos resultantes
son de calidad 0 poder compararlos, es necesmio asignar val ores, descriptores, indicadores
o alglll1 otro mecanismo mediante el cual se pueda llevar a cabo dicha comparacion. Para
ello, es necesario llevar a cabo un proceso de medicion del software, que en general,
persigue tres objetivos fundamentales: ayudamos a entender que OCUlTe durante el
desalTollo y el mantenimiento, pel1nitimos contIolar que es 10 que OCUlTe en los proyectos
y poder mejorar los procesos y productos (Fenton y 1997).
En efecto, las metIicas son un buen medio para entender, monitorizar, controlar,
predecir y probar el desalTollo de software y los proyectos de mantenimiento (Briand et
al., 1996) y pueden ser utilizadas por profesionales e investigadores para tomar mejores
decisiones (Pfleeger, 1997).
En este capitulo en primer lugar se presentan de fonna intIoductOlia algunos
fundamentos de la medicion del software, para 10 cual se analizan las apOliaciones de la
teolia, la tenninologia y los aspectos 111<lS relevantes a considerar en el proceso de
obtencion de metIicas. A continuacion se presentan los metodos y estindares mas
200 CAUDAD DE SISTEMAS INFOIUvL.\ TICOS :g RA-\IA
representativos de la medicion software, para finalmente analizar la medicion de los
distintos tipos de entidades software (procesos, proyectos y productos).
1.1. Teoria de la Medici6n del Software
Uno de los campos mas influyente en los origenes de la disciplina de la medici6n
del software ha sido la te0l1a de la medicion. La medicion es una actividad que aplicamos
continuamente en nuestra vida cotidiana y nos pennite obtener infonnacion que nos guia
en la toma de decisiones, seleccionar entre distintas altemativas la que mas ventajosa nos
resulta 0 desechar una opcion por no adaptarse para nada a 10 que de ella esperabamos.
Fenton y Pfleeger (1997) definen la medicion como: "el proceso de asignar Illimeros a
simbolos a los atriblltas de las entidades del Illllndo real de forllla que se puedan
describir de acuerdo a lInas reglas claramente definidas".
De acuerdo a la anterior definicion, una entidad puede ser un objeto fisico, un
evento que ocurre en un determinado momento de tiempo 0 una actividad que transCUlTe
en un detenninado intervalo de tiempo, como por ejemplo: un programa, un hi to y la fase
de pruebas de un proyecto software, respectivamente. Un atIibuto es una caracteristica de
una entidad, como por ejemplo el tamafio del c6digo de un detenninado programa 0 el
esfuerzo requerido para llevar a cabo una detenninada actividad.
Por 10 tanto, en el campo de la medici6n es necesario especificar tanto las entidades
como los atIibutos que se evalllan de dichas entidades. Algunos aspectos relevantes a
considerar en el contexto de la te0l1a de la medicion aplicada a la medici6n del software
son los siguientes (Fenton y Pfleeger. 1997):
e Escala. Las escalas penniten establecer el tipo de representacion mas adecuado
para un atributo de fom1a que se puedan comparar los valores de los mismos.
Considerando que diferentes escalas pueden mediI' el mismo atI'ibuto, una
cuesti6n importante a plantear es que esc ala es mas apropiada en cada caso.
Para ello, en la te0l1a de la medicion aplicada al sofuvare destacan cinco tipos
principales de escalas:
o Escala Nominal. Es la esc ala mas bitsica, que sirna a las entidades en
diferentes c1ases 0 categorias asignando al atI-ibuto un nombre. De este
modo las c1ases se identifican lll1icamente mediante un nlunero 0
simbolo que no puede ser interpretado salvo como un mero identificador.
Por ejemplo, distinguir de fonna nominal a los jugadores de un equipo de
baloncesto pOl' su dorsal. EI jugador "30" no puede interpretarse como
dos veces superior al jugador "15".
o Escala Ordinal. Con esta esc ala, los atributos pueden ser ordenados en
rangos pero la distancia entI'e los mismos no es significativa. POl'
ejemplo, las respuestas a una encuesta podrian ser: "O==totalmente en
desacllerda", "1 == ni de acuerda ni ell desacllerdo", "2 == de aClierdo ".
CAPiTULO 9: \IEDICI00: DE SISTE\IAS DE 10:FOR-vIACI00: 20]
"3=nzllY de aClierdo", "4= tota/mente de aClierdo". En este caso cuanto
mayor es el valor hay un mayor acuerdo con 10 planteado en la pregunta,
pero la distancia entre los val ores 0 y 1 no tiene por que ser igual que
entre los valores 2 y 3.
o Escala de Intervalo. Este tipo de esc ala es como la ordinal pero con la
diferencia de que la distancia entre los atlibutos S1 tiene sentido. Por
ejemplo, si se mide la temperatura en grados cent1grados (DC), la
distancia entre 30 y 40 es la misma que entre 60 y 70. Sin embargo, en
esta escala las comparaciones de tipo ratio no tienen sentido, como por
ejemplo: 80 DC no es el doble de calor que 40 DC (aunque el valor S1 es el
doble).
o Escala de Ratio, que es la tmis (Itil en la medici6n del sofuvare. ya que
preserva el orden, el tamai'io de los intervalos y tambien los ratios entre
las entidades. Ademas, tiene un punto fijo de referencia: el cero. La
esc ala debe comenzar en el 0 y se incrementa en pasos iguales. Ademas,
con los valores de esta escala se pueden realizar las operaciones
matematicas de suma, resta, multiplicaci6n y divisi6n. El peso es, por
ejemplo, una variable de tipo ratio.
o Escala absoluta, que es utilizada 11l1icamente cuando s6lo hay una fonna
posible de medir un atributo. En generaL los atributos evaluados
mediante un metodo basado en con tar el numero de elementos son de
este tipo de escala, como por ejemplo el n(1l11erO de defectos encontrados
o el n(nnero de personas en un proyecto.
@ Clasificacion de Entidades. En medici6n del sofuvare se puede distinguir
entre tres tipos de entidades:
o Proceso, en el que se incluyen las medici ones relacionadas a las
actividades del sofuvare.
o Pmduclo, que incluye los entregables y documentos resultantes de las
actividades de los procesos.
o Recllrsos, que incluye los recursos necesarios para el desarrollo de los
proyectos sofuvare tales como personal, sofuvare, hardware. etc.
@ Atributos intern os y extern os. Los atributos intemos son aquellos que pueden
ser medidos de una entidad sin necesidad de evaluar el compOltamiento
extemo de dicha entidad. Ejemplos de atributos intemos son: tamai'io y
complejidad de c6digo fuente. que pueden ser evaluados sin necesidad de
ejecutar el c6digo. Los atributos extemos son mediciones sobre c6mo una
entidad est} relacionada con el entomo, como por ejemplo los atlibutos calidad
y estabilidad de requisitos. en cuyo caso es necesario ejecutar el c6digo para
obtenerlos. Estos atributos son mucho mas dificiles de evaluar que los atributos
202 CAUDAD DE SISTEMAS TICOS
intemos y la necesidad de disponer de mediciones de atributos intemos para
obtener el valor de atributos extemos es bastante clara. Por ejemplo, para
evaluar el atlibuto extemo cali dad del sofhvare es necesario conocer atlibutos
intemos como por ejemplo el nlu11ero de fallos obtenidos en la actividad de
pruebas.
Mediciones directas e indirectas. Otro de los aspectos a destacar de la teOlia
de la medicion es la distincion que establece entre mediciones directas e
indirectas. Una medici6n directa es la medicion de un atributo de una entidad
sin estar otras entidades implicadas. Por ejemplo, el atIibuto tamafio de la
entidad c6digo fnente puede ser me dido sin necesidad de evaluar ninglm
atIibuto de otras entidades. Las mediciones indirectas requieren de otros
atlibutos, como por ejemplo la medicion del atlibuto productividad, que
requiere las mediciones tanto del tamafio como del esfuerzo y es obtenido
media ante la division de ambos.
1.2. Terminologia de la Medici6n de Software
Dado que la medicion de software es una disciplina relativamente joven, no existe
alm un consenso general sobre la definicion exacta de los conceptos y tenninologfa que
maneja. A pesar de COI1tar con diversos estandares intemacionales que tratan de
n0l111alizar estos temas (IEEE, 1998b; ISO. 1993; 1999: 2002a), se han detectado ciertas
lagunas e inconsistencias en los tenninos que dichos estandares definen. como son por
ejemplo los conceptos de medida. metrica, medici6n, indicador. etc. La situaci6n no es
mucho mejor en los contextos academic;)s e industriales, donde las distintas propuestas de
modelos de medicion de software tampoco han logrado consensuar una te!111inologia
coherente y ampliamente aceptada entI'e toda la comunidad cientifica (Garcia et al . 2005).
Con el fin de contribuir a la an11onizacion de los diferentes estandares y
propuestas de investigacion y de establecer una tenninologia consistente (en el sentido de
consenso y libre de contradicciones) se ha desaITollado una ontologia de la medicion del
software (Garcia et al .. 2005).
En la figura 9.1 se muestra de fon11a grafica mediante un diagrama en UTvIL los
conceptos de la ontologfa y sus relaciones.
El objetivo de esta ontologia es establecer una guia de referencia que incluya los
conceptos relacionados con la medicion del software. Para facilitar su comprension. la
ontologia de la medici6n del software se divide en las siguientes sub-ontologias:
Caracterizacion y Objetivos de la Medicion Software, con los elementos
sobre los que se puede aplicar un proceso de medicion y sus propiedades.
Tambien se reflejan los objetivos que se persiguen con la medici6n del
software.
<;; R/\.-MA CAPiTULO 9: ;-'!EDICION DE SISTEiv!AS DE INFOR.!'vIACIOl\ 203
CiI Accion de Medir, en la que se identifican los conceptos relacionados con la
fOlma en la que se lleva a cabo la medici6n software.
Necesidad de Informacion
y O!:>;e:;,es)
seCQrrea:::;r;:;e c:;n
Modelo de Calidad
e,"af:ia Concepto Medible
C0dase
-
de:;r;.:fopara
Categoria de Entidad :',,:-:2 Atributo
(!r::.", C:n::::,.=r;:,,:.C<1 y
Entidad s;;: rea";;:;; S::;:JriJ
Medici6n
s:;::;Enidaj (!:-C'" C"r":;,.<:',,z,,:,::n y
Medida
52 de::neparo
MtHrica Dire eta
t:ror.:-.li!etn:as)
Tipo de Es::ala
\fr:;;mMt-t!\e::!s)
Escala
Metrica
{:rcmMeL"i:::as)
l't1etrica Indirects

Fcmna de Medir
Figura 9.1. Ontologia de la Medici6n del Software
Unidad
Indicador
:;eir:c::!DC"
CiI Metricas. en la que se especifica la definici6n y caracteristicas basicas de las
metricas software. Una mettica se define como una fonna de medir (metodo de
medici6n, funci6n de caJculo 0 modelo de anaJisis) y una escala, definidas para
realizar medici ones de uno 0 varios attibutos. Las metric as pueden ser de tres
tipos en funci6n de su fonna de medir:
o Metricas Directas cuya fonna de medir es un metodo de medici6n, es
decir, se pueden realizar medici ones de dicha metric a sin depender de
ninguna otra.
204 CALlD .. \D DE SISTEYL-,\S 10:FOR.\L.\TICOS
o MHricas Indirectas, cuya f0l111a de medir es una fi.ll1cion de calculo, es
decir, las mediciones de dicha l11etlica utilizan las l11edidas obtenidas en
mediciones de ott'as l11etlicas directas 0 indirectas.
o Indicadores, cuya f011na de medir es un modelo de analisis, es decir. las
mediciones de dicha mettica utilizan las l11edidas obtenidas en las
medici ones de otras metlicas (directas, indirectas 0 indicadores) junto
con cliterios de decision.
e Formas de Medir. en la que se descliben las distintas f011nas de medir
metticas software.
En la elaboracion y division de la ontologia de la medicion del software en sub-
ontologias, se han identificado y establecido los conceptos y aspectos mas relevantes
relacionados con la medicion del software y las etapas fundal11entales componen dicho
proceso.
Todo proceso de medicion del software tiene como objetivo fundamental
satisfacer necesidades de info11nacion. Un proceso de medicion no puede obtener
resultados utiles si estos no satisfacen alguna necesidad de info11nacion detectada en la
empresa en la que se lleva a cabo. A pattir de las necesidades de inf01111acion se deben
identificar las entidades y los attibutos de dichas entidades que son candidatos a ser
medidos. Esta patte significativa del proceso de medicion es la que se aborda en la sub-
ontologia de caracterizacion y objetivos.
Una vez identificados los attibutos objeto de la medici on, se deben definir las
metlicas necesatias. Para clatificar que elementos generales hay que considerar en la
definicion de las metricas se ha definido la sub-ontologia de las metticas. en la que se
identifican los principales tipos de metricas que se pueden definir. En la definicion general
de una metrica se deben especificar aspectos como la unidad en la que se expresa. la
escala a la que pertenece. el atributo 0 atributos para los que se define. etc.
La definicion de las metricas se debe realizar a distintos niveles 0 alcances. ya
que resultaria excesivamente complejo definir ae forma directa metric as a partir de las
cuales se satisfagan las necesidades de inf01111acion. Por ello. es fundamental definir en
primer lugar metric as que se aplican directamente sobre las caracteristicas de una entidad
para evaluar un dete11ninado atlibuto. A pattir de estas metticas directas se pueden definir
metric as indirectas y finalmente se podrian definir metricas con el objetivo de
proporcionar infonnacion litil para la toma de decisiones, y por 10 tanto. mas cercanas a
satisfacer las necesidades de infonnacion. Estos aspectos se tratan en la sub-ontologia de
las fonnas de medir. en la que se identifican los metodos concretos para definir 0 calcular
las metricas definidas en fimcion de su tipo.
Finalmente se !leva a cabo el proceso de medicion propiamente dicho. a pattir de
la definicion de las metricas y de la caracterizacion de los atributos de las entidades objeto
_':;-RA-\IA
O.PiTUO 9: \IEDICIO" DE SISTE\IA.S DE 205
de la medicion. mediante la realizacion de medici ones que como resultado obtienen
medidas. Estos conceptos se tratan en la subontologia de la accion de medir.
Una definicion y explicacion mis detaIl ada de los tel111inos de la ol1tologia puede
consultarse en (Garcia et af.. 2005).
1.3. Proceso de creaci6n de Metricas
Desde los ai'ios setenta se han propuesto una gran cantidad de metlicas para
capturar atlibutos de los procesos y productos software de una f0l111a cuantitativa (vease
apartado 4.3 de este capitulo). Tradicionalmente estas metricas se han realizado confiando
en el conocimiento de los expeltos, y si bien esta experiencia es impoltante, puede resultar
110 ser suficiente. En la actualidad muchas de las metric as propuestas han fracasado,
siendo solo un as pocas las que han sobrevivido con ex ito la fase inicial de definicion y son
usadas actualmente en la industria. Ello es debido a varios problemas (Briand et al.,
1999):
e Las meuicas no estan siempre definidas en un contexto en el que el objetivo de
interes industrial que se pretende alcanzar mediante su utilizacion es explicito y
queda bien definido. Por ejemplo: la reduccion del esfuerzo de desanollo 0 la
reduccion de los fallos presentes en los productos software.
e En ocasiones. aunque el objetivo sea explicito, las hipotesis experimentales a
menudo no estan hechas de fon11a explicita. por ejemplo ;,qlle se pretende
dedllcir del analisis? (:reslilta creible el resultado?
e Las definiciones de metricas no siempre tienen en cuenta el ent0l110 0 el
contexto en el cual seran aplicadas, por ejemplo ;,se puede IItilizar lIna llIetrica
definida para lin entorno no orientado a objetos en un contexto orientado a
objetos?
e A menudo, no es posible realizar una adecuada validacion teorica de las
metricas porque el atributo que una metrica pretende cuantificar no esta bien
definido, por ejemplo, la nocion de complejidad .
.
e Un gran numero de metr'icas no han sido nunca objeto de validacion empiric a,
por ejemplo ;,c6mo se sabe que lina metrica de tamalio predice mejor el
esjiter::.o en lin elltorno de desarrollo?
Esta situacion ha conducido frecuentemente a cierto grado de ambigUedad e
imprecision en las definicion, propiedades y suposiciones de las meuicas, haciendo que su
uso sea dificil, la interpretacion peligrosa y que los resultados sean conu"adictorios en
varios esuldios de validacion.
Los problemas citados anteri0l111ente son propios de cualquier disciplina joven, y
especialmente de aquellas que son intensamente humanas, como es el caso que se esta
206 CAUDAD DE SISTElvV\S INFORIvL-\ TICOS
RA-MA
tratando. Los fenomenos estudiados en este campo implican un ntllnero de variables que
dependen del comportamiento humano y no pueden ser controladas facilmente. No se
debe esperar, por tanto, encontrar leyes cuantitativas que sean validas y aplicables de
modo general, y que tengan la misma precisi6n y exactitud que, por ejemplo, las leyes
fisicas.
Objetivos
A
Validacion
Te6rica
Identificacion
~ Hipotesis
y Requisitos
Creaci6n
4,
Validacion Empirica
~ - --- .. -- Experimentos
~ Explicacion PSicologica
Reutilizaci6n
i Metrica Retirada
...
Acreditacion
..
Objetivos
r '''''m,"","' j
Aplicacion
Objetivos
r Metricas
Aceptadas
<I
...
Aceptacion
Metricas No
Aceptadas
Metricas Validas
Figura 9.2. Metodo Alarcos para la Definicion de Metricas Software
Todas estas caracteristicas no significan que no se pueda progresar en el campo de
las meh1cas software, pero para poder conseguir este prop6sito las meh1cas deb en ser
definidas de una fonna metodol6gica y disciplinada, teniendo dicha definici6n una base
s61ida con objetivos de medici6n claros y debiendo satisfacer las necesidades de la
organizaci6n. Con este fin, se puede encontrar en.la bibliografia diversos metodos para la
definici6n de meh1cas software en los que se integran todos los aspectos que es necesario
tener en cuenta en la validaci6n de las metricas, como el metodo MMLC (lvIeaslire lvIode!
Lt[e Cycle) (Cantone y DonzeIIi, 2000) y la propuesta del Grupo Alm'cos (Sen'ano et aI.,
2002), que se ilustra en la figura 9.2 y en la que las flechas continuas representan el flujo
de las metric as y las discontinuas representan el flujo de infonnaci6n a 10 largo de todo el
proceso.
La propuesta del Grupo Alarcos consta de dos fases:
fi!I Identificacion. En esta etapa se pretende identificar los objetivos de la
medici6n y las hip6tesis bajo las cuales se crean las meh1cas. Los objetivos
fRA-MA CAPiTULO 9: MEDICION DE SISTEMAS DE INFORt'vlACION 207
indican 10 que se pretende conseguir con la utilizacion del proceso de medicion
y representan la razon por la que se llevani el proceso de medicion (el
"porque"). Las hipotesis son la f0l111a en la que se pretende llevar a cabo la
medicion (el "como"), identificando la infonnacion que se debe manejar para
conseguir a1canzar los objetivos deseados. Este proceso suele estar basado en la
experiencia y el conocimiento de los expertos y puede utilizar mecanismos
basados en Goal-Question-Meric (GQM: Basili and Weiss, 1984; Basili y
Rombach, 1988; Van Solingen and Berghout, 1999). Como resultado de esta
fase se deben obtener los requisitos que debe cumplir la metrica, los cuales
senin utilizados en la etapa de creacion. Ademas, como se observa en la figura
9.2, los objetivos seran utilizados en las etapas de aceptacion, aplicacion y
acreditacion.
e Creacion. El proceso de creacion es aquel en el que a partir de los requisitos
obtenidos en la etapa de identificacion se creara una metIica valida, lista para
ser aplicada en entornos reales. El proceso de creacion de las metricas es
evolutivo e iterativo y se subdivide en varias etapas intel111edias. Como
resultado de la realimentacion, las metricas deb en ser redefinidas de acuerdo a
las validaciones, teoricas 0 empiricas, fallidas. Al final de la etapa de creacion,
las metricas se consideraran validas y aquellas que no sean validas, seran
descartadas. Las etapas en las que se subdivide la creacion son:
o Definicion. Es el primer paso de esta fase que debe realizarse
considerando las caractetisticas del producto que vamos a medir y la
experiencia de los profesionales. En la definicion se deben considerar
objetivos claros, es decir, realizar una definicion de la metrica Olientada
al objetivo identificado en la fase anterior para evitar obtener una
definicion de la metrica que no cumple con el objetivo deseado. Es
deseable que la definicion de las metIicas se realice de manera fonnal
para evitar ambigtiedades.
o Validacion teorica. El objetivo principal de la validacion teorica es
demostrar que la metIica mide el atIibuto que pretende medir, es decir,
comprobar si la idea intuitiva acerca.del atributo que esta siendo medido
se refleja en la metrica. Ademas la validacion teorica proporciona
infOl1Uacion relacionada con las escalas de las metricas y asi se puede
detenninar que tipo de operaciones matematicas y tests estadisticos
aplicar a la hora de analizar los valores de las metricas en estudios
empiricos. Lamentablemente no existe un estandar para la validacion
teorica a traves del cual obtener la infonnacion matematica de las
metric as definidas, sin embargo, hay dos tendencias principales en la
validacion: los marcos basados en propiedades (que definen fonnalmente
propiedades deseables de las metricas para un atributo software concreto)
(Weyuker, 1988; Briand et al., 1996) y los que se basan en la teotia de la
medida (WhitInire, 1997; Zuse, 1998; Poels y Dedene, 2000), cuyo
208 CAUDAD DE SISTE\!AS fNFOR\l;\ TICOS i:':. R:\-\L-\
objetivo es obtener la escala matem::itica a la que peltenece una metrica,
y por tanto sus transfonnaciones admisibles, estadisticos y tests
aplicables y especificar un marco general en el que las metlicas deb en ser
definidas.
o Validacion empirica. EI objetivo de esta etapa es pro bar la utilidad
pnictica de las metlicas propuestas. EI saber general, la intuici6n 0 la
especulaci6n, no son fuentes fiables de conocimiento (Basili et al., 1999)
por 10 que es necesmio realizar validaciones empilicas de las meuicas.
La validaci6n empiric a se utiliza para obtener infoI1naci6n objetiva sobre
la utilidad de las meuicas propuestas ya que puede que una meuica sea
COITecta des de un punto de vista f0l111aL pero no tener relevancia pnictica
para un problema detenninado. Asi pues, el estudio empiIico resulta
necesmio para comprobar y entender las implicaciones de las metricas de
nuesuos productos. Esto se consigue a uaves de hip6tesis en el mundo
reaL mas alla de la pura teoria, que habra que comprobar con datos
empiricos. Algunos trabajos relevantes que proporcionan la guia
necesmia para llevar a cabo estudios empilicos son los realizados por
Robson (1993), Wohlin et al. (2000), JUIista y Moreno (2001), Basili et
al. (1999) Y Peny et al. (2000) (vease capihllo II).
o Explicacion psicologica. Idealmente es necesmio tener la capacidad de
explicar la influencia de los valores de las meDic as desde un punto de
vista psicol6gico. Algunos autores. como Siau (1999). proponen el usa
de la psicologia cognitiva como una disciplina de referencia. De esta
manera, las teorias como ACT (Adaptative Control of Thought)
(Anderson, 1983) pueden justificar la influencia de ciertas metricas en la
comprensi6n de los sistemas.
II Aceptacion. Suele ser necesaria la existencia de una fase de pruebas en
laboratOlio en la que se realice una experimentaci6n sistematica en entOI11OS
reales y con usum10s reales para verificar si cumple los objetivos buscados
dentro de un entOI11O de trabajo real. Esta etapa se diferencia de los casos de
eshldio en que en estos (lltimos se. suele trabajar en el entOI11O final de
aplicaci6n. En definitiva, en esta etapa se intenta averiguar si las metlicas
"validas" que se consiguieron al final de la fase de creaci6n son aceptables en
entOI11OS de aplicaci6n reales, teniendo en cuenta los objetivos obtenidos en la
etapa de identificaci6n. Esta etapa debe ser realizada con proyectos no critic os
y con riesgos conuolados. Idealmente deberia usarse en proyectos piloto de
manera que el fracaso de aceptaci6n de la meDica no suponga un fracaso en un
proyecto impOltante. Si se consigue demosuar que la metric a sigue cumpliendo
los objetivos, es posible pasar a la etapa de aplicaci6n, y si no es asi, es
necesario volver a la etapa de creaci6n.
II Aplicacion. En esta etapa se utiliza la metrica ya aceptada en el entOI11O real.
Esta fase se lleva a cabo en paralelo con la fase de acreditaci6n.
C-\PiTULO 9: \IEDICIO:--; DE SISTE\IAS DE INFOR\lACION 209
 Acreditacion. Esta liitima fase del proceso es una etapa dimlmica que persigue
el aseguramiento de la metrica y la mejora continua de la misma, en funcion de
como evoluciona el ent0ll10 de aplicacion, de manera que se puedan seguir
cumpliendo los objetivos que se perseguian al principio del metodo. En
ocasiones el entO!11O puede variar tanto (por ejemplo, pasar de un entorno
estmcturado a uno orientado a objetos) que la metrica no sea aplicable. en este
caso, la metrica deberia ser descartada y el conocimiento adguirido durante su
tiempo de vida deberia realil11entarse a la etapa de identificacion de manera que
podal110s crear una metric a adecuada para el nuevo entO!11O cumpliendo los
objetivos perseguidos. Ademas al utilizar la expeliencia de la utilizacion de la
metrica descartada, se tendran mas probabilidades de fO!111Ular hipotesis
COITectas en la etapa de identificacion.
2. ESTANDARES Y METODOLOGiAS DE MEDICION
Antes de poder aplicar planes de l11ejora en una organizacion es necesario partir
de una base cuantitativa que pennita detenninar de una fonna objetiva los puntos fuertes y
debiles de los procesos. Las metricas software constihlyen la base necesaria para poder
llevar a cabo un proceso de evaluacion y posterionnente, una mejora de los procesos
software. Por ello, la medici on es un aspecto que se tiene muy en cuenta en los modelos
de evaluacion como en ISO/IEC 15504. en el que se define un proceso de la medicion, 0
como CMMI en el que se incluye un area clave de proceso en el nivel dos de madurez
denol11inada "Medicion y Analisis. Como soporte al proceso de medicion se pueden
destacar diversos marcos de trabajo como el mencionado GQM 0 PSM (Practical
Sojhrare Measurement) (McGarry et al . 2002), as! como cielios estandares, entre los que
destacan ISO 15939 (ISO. 2002c) e IEEE Std 1061-1998 (IEEE, 1998b). EI objetivo de
estos estandares y marcos de trabajo es proporcionar la referencia necesaria para poder
llevar a cabo el proceso de medicion de una fonna efectiva y sistematica, partiendo de la
base de que la medicion es un proceso que debe ser llevado a cabo en base a una selie de
objetivos.
Ante las distintas propuestas metodologic,as existentes sobre la medicion de
software es necesario analizar la relacion entre las mismas. Para ella se ha seguido la
cOl11parativa realizada por Jones (2003) con la que se llega a la conclusion de que existe
un cada vez mayor esfuerzo por cOOl'dinar las distintas propuestas. En la figura 9.3 se
muestra la relacion existente entre algunas de las propuestas mas significativas
relacionadas con la medicion del software.
Los plincipales aspectos a considerar en la relacion entre las diferentes propuestas
son los siguientes:
 PSM constiruye el documento base a pariir del que se ha elaborado el nuevo
estandar ISO/IEC 15939 sobre la medicion del software. PSM proporciolla
detalles adicionales respecto de las actividades y tareas de ISO 15939.
210 CAUDAD DE SISTEMAS INFOR.!vIA TICOS
:& RA-iV1A
., EI objetivo y los resultados del proceso de medici6n de ISO 15939 ha sido
afiadido a la revisi6n del estandar ISO 12207 dentro de un nuevo proceso de
soporte denominado Medici6n y a la nonna ISO 90003 (aplicaci6n de la nonl1a
ISO 9001 :2000 al software).
Practical SofwareMeasurement(PSM)
ISO/IEG 15939, Proceso de Medici6n de Software
15288 (conceptos de medicion)
9126 (terminologia coordinada)
14598 (terminologia coordinada)
ISO 90003 (objetivos)
Figura 9.3. Coordinacion existente entre PSM, CMMI y los estandares ISO en el area de
la Medicion de Software (adaptado de Jones, 2003)
., Los conceptos del dominio de la medici6n de ISO 15939 han sido afiadidos al
estandar ISO/IEC 15288 (Procesos de Cicio de Vida del Sistema). De la misma
fOlma, la nueva tenninologia de la 'medici6n ha sido coordinada con las
revisiones en los estandares ISO/IEC 9126 (Calidad del Producto Software) e
ISO/IEC 14598 (Evaluaci6n de Productos Software) con el objetivo de que
todos los estandares que us en el dom.inio de la medici6n esten basados en una
misma tem1inologia .
., EI area Medici6n y Analisis de CMMI proporciona una metodologia para
evaluar si un programa de medici6n de un proyecto es acorde con el estandar
ISO 15939, por 10 que utiliza este estandar como referencia.
Por 10 tanto, el intento de coordinaci6n existente entre estos documentos de
referencia significa que existe till conjunto de estandares de medici6n, que tiende a ser
RA-MA CAPiTULO 9: DE SISTEMAS DE INFORt'v!ACION 211
cada vez mas consistente, dirigidos por objetivos 0 necesidades de informacion que
proporcionan la guia necesaria para la implementacion de la medicion de forma efectiva.
A continuacion se desclibe como se aborda la medicion del software en los distintos
1110delos, estandares y metodos de evaluacion y mejora y se presentan los modelos y
l11etodos mas representativos relacionados con el soporte a la medicion software.
2.1. La medici6n en los modelos de madurez y metodos de
evaluaci6n y mejora
La medicion juega un papel fundamental en las organizaciones que pretenden
conseguir un alto grado de madurez en sus procesos. Este hecho se demuestra observando
el tratamiento y la importancia que los modelos y estandares de madurez y evaluacion y
l11ejora dan al proceso de medicion:
CD EI Modelo de Madurez de la Capacidad (CMlVI) asigna un impoltante rol a
la medicion a la hora de detenninar el estado de los procesos software.
Partiendo de la base de que "no hay actllalmente lin modelo 1I1liversalmente
aceptado de medidas del proceso sofnrare 0 de la caUdad' el modelo insta a
las organizaciones a identificar para cada Area Clave del Proceso, uno 0 mas
conjuntos de medidas significativas que puedan proporcionar visibilidad en el
rendimiento del proceso (llevado a cabo en fOl111a de proyectos). Partiendo de
un conjunto en el que los objetivos de la medicion son conocidos, cada
organizacion especffica tiene la libeltad de seleccionar metricas concretas
adecuadas para su entol110, industria 0 cultura. EI proceso de medicion se
desclibe en el aspecto comun dell110delo denol11inado "Medici on y AnaIisis".
Los tipos de mediciones incluidos para cada nivel de madurez son:
o Nivel Repetible: basado en disponer de un con junto representativo de
metlicas a nivel de gestion del proyecto. Los valores de estas l11etricas se
utilizan en futuras estil11aciones de proyectos.
o Nivel Definido: se dispone de un conjunto de l11etricas a nivel
organizacional que facilita realizar valoraciones sobre los proyectos en su
conjunto. A este nivel tambien se l11etlicas relacionadas con la
calidad y funcionalidad de los productos.
o Niveles Gestionado y Optimizante: la l11edicion se basa en la
planificacion y gestion de las calidad de los procesos y productos de una
fonna estadistica.
CD EI estandar ISO 15504, incluye en la dimension del proceso del l110delo de
referencia (patte 2 de la n0l111a) el proceso de l11edicion, dentro de la categoria
de los procesos organizacionales, proceso que cubre todos los procesos que
establecen y dan soporte a la consecucion de los objetivos organizacionales de
negocio. EI proceso de l11edicion supone la definicion de metricas, la gestion de
los datos (incluidos los datos historicos), y el uso de las metricas en la
212 CAUDAD DE SISTE:VIAS INFOR:'vL.\ T1COS
organizaClOn. EI objetivo que se pre ten de es el de implementar metric as de
proceso y de producto como soporte a la gesti6n efectiva y a la posibilidad de
demostrar objetivamente la calidad de los productos.
G La familia de n0l111as ISO 9000:2000, establecen la necesidad de implementar
el proceso de medici6n con el objetivo de controlar la calidad del producto, la
capacidad del proceso y la satisfacci6n del cliente. La gesti6n usa metricas
como entrada fundamental para la planificaci6n, control y gesti6n del proyecto,
y para tambien controlar la cali dad del producto. todo ella orientado a la
mejora continua del proceso.
G CMMI, proporciona a la medici6n una gran importancia en la madurez de los
procesos al incorporar una nueva area del proceso denominada "Medicion y
Amllisis", cuyo a1cance es mucho mas amplio y mas explicito que el
tratamiento de la medici6n en el modelo CMM. La incorporaci6n de fonna
explicita de esta nueva area de proceso en el modelo CMMI proporciona una
gesti6n con el enfoque y la visibilidad que las organizaciones necesitan para
guiar el uso de la medici6n en sus esfuerzos de mejora (Goldenson et al ..
2003). EI objetivo de esta area es desanollar y establecer una capacidad de
medici6n que se pueda usar para dar soporte a las necesidades de informaci6n
de la organizaci6n. 10 que implica una ampliaci6n a los conceptos incluidos en
el modelo CMM. Da soporte al resto de areas de proceso proporcionando un
marco de trabajo a las organizaciones a la hora de alinear los objetivos y
necesidades de medici6n con un enfoque de medici6n bas ado en proporcionar
resultados objetivos que sean lltiles para la toma de decisiones y acciones
conectivas. Este enfoque es consistente con las ideas de GQM y del estandar
ISO 15939 (ISO/lEe 2002). En la figura 9.4 se representa mediante un
diagrama de flujo de datos. los principales procesos relacionados con esta area.
y las relaciones de datos entre los mismos.
Como se puede observar en la figura 9.4. a la hora de establecer un proceso de
medici6n efectivo en una organizaci6n es necesario conseguir dos objetivos
fundamentales:
G Alinear las acovidades de analisis de la medicion. Para conseguir este
objetivo en CMMI se identifican las siguientes pnkticas: establecer los
objetivos de la medici6n, especificar medidas, especificar procedimientos de
recopilaci6n y almacenamiento y especificar procedimientos de analisis. A
partir de estas practicas se establece un plan para la medici6n y el analisis con
el que se pretende resolver cuestiones tales como: GPor que se mide? (: que se
1'(1 a medir? Gcomo se va a medir?, etc.
G Proporcionar los resultados de la medicion. Las practicas asociadas con la
consecuci6n de este objetivo son: reunir los datos de la medici6n, analizarlos.
almacenar los datos y resultados y comunicar los resultados. Por 10 tanto, con
estas practicas se pretende establecer un buen proceso de recopilaci6n y
CAPiTL'LO 9: \lEDICIOl\' DE SlSTE\lAS DE E\FORMACIOl\' 213
comunicacion de los resultados, ya que estos deben proporcionarse a la persona
adecuada para satisfacer sus necesidades de informacion.
Alinear las
Actividades de
Analisis de la
Medici6n
Peesonal de t..
Medici6n
4
~ y
Proporcionar
los resultados
de Ja Medici6n
Figura 9.4. Area Clave ":\Iedici6n y Analisis" de CMMI
Por 10 tanto. el plimer paso del proceso de medicion es el de identificar los objeti-
vos de la medicion para. en un segundo paso, implementar el proceso de medicion y
analisis. 10 que requiere la integracion de la medicion en los distintos procesos del trabajo
de una organizacion.
PRACTIC\
I
OBJETIVO
2.8. Monitorizar y Controlar el
I
;v[onitorizar y controlar cl proceso respecto al plan para Ia realizacion del
Proceso proceso y !leyar a cabo las aeciones cOITeeti\'as apropiadas.
Reunir productos de trabajo. medidas. resultados de Ia medicion. c
3.2 Recopilar Infol1naeion de infol111acion de Ia mcjora deri\ada de Ia planiticacion y realizaeion del
:v[ejora proceso para dar soporte a su uso nlturo y a Ia mejora dc los proeesos de
Ia organizacion.
-f.l.Estabiecer Objetiyos
Establecer y mantcner objetiyos cuantitati\'os sobre Ia ealidad y
Cuantitativos para el Proceso
rendimiento del proceso. basados sobre las necesidades de los clientes y
los objetiYos de negocio.
-f.2. Estabilizar el Rendimiento
Estabilizar el rendimiento de uno 0 milS subprocesos del proccso para
de los SubProcesos
detenninar su habilidad para obtener Ia cali dad establecida de l'Ol1na
cuantitativa y los objeti\'os de rendimiento del proceso.
,
5.1. .-\segurar Ia \ lejora Asegurar Ia mejora continua del proceso en Ia consecucion de objetiyos
Continua del Proceso de negocio relevantes dc Ia organizaeion.
Tabla 9.1. Practicas Genericas de CM:\II relacionados con la medici6n
214 CAUDAD DE SISTEivlAS INFOR.J'vlATICOS
La importancia de la medicion en el modelo CMMI tambien se ve claramente
reflejada en su incorporacion a varias pnicticas generic as tal y como se puede apreciar en
la tabla 9.1 (Goldenson et aI., 2003).
En definitiva, de acuerdo al marco de medicion de CMMI, es muy importante
para una organizacion que quiera implantar un proceso efectivo de medicion, poder
definir de fonna precisa modelos concretos de medida que, siendo soportados por una
helTamienta integrada de medici on, pennitan una automatizacion adecuada y necesaria
para la evaluacion de los procesos.
2.2. Goal Question Metric (GQM)
Elmetodo GQM fue originariamente definido por Basili y Weiss (1984) y ex-
tendido posteri0l111ente por Rombach (1990) como resultado de muchos afios de
experiencia pnictica e investigacion academica. EI principio basico que subyace tras el
metodo GQM es que la medicion debe ser realizada, siempre, orientada a un objetivo.
GQM define un objetivo. refina este objetivo en preguntas y define metricas que
intentan dar informacion para responder a estas preguntas.
Elmetodo GQM se lleva a cabo en las siguientes fases (van Solingen y Berghout
1999):
1. Planificacion. durante la cual se selecciona, define, caracteriza y planifica un
proyecto para la aplicacion de la medicion obteniendose como resultado un plan
de proyecto.
2. Definicion, durante la cual se define y documenta el programa de la medicion
(objetivos, preguntas, metric as e hipotesis).
3. Recopilacion de Datos, en la que se relll}enios datos reales de la medicion.
4. Interpretacion, en la que se procesan los datos recopilados respecto a las
metric as definidas en fonna de resultados de medicion, que proporcionan
respuestas a las preguntas definidas, a partir de las cuales se puede evaluar el
logro del objetivo planteado.
EI proceso se ilustra en la figura 9.5. La fase de planificacion se lleva a cabo para
satisfacer los requisitos basic os que penni tan que un programa de medicion GQM sea un
exito. para 10 cual se incluyen aspectos de fonnacion, implicacion en la gestion y
planificacion de proyectos. Durante la fase de definicion se elaboran los entregables, que
estan principalmente basados en entrevistas eSh1.1cturadas u otras tecnicas de adquisicion
de conocimiento. En la fase de definicion se identifica un objetivo, y todas las preguntas.
C.-\PiTULO 9: ivlEDICION DE SISTEvlAS DE INFOIUvlACION 215
l11etlicas y expectativas (hipotesis) de las l11ediciones. Cuando se han cOl11pletado todas las
actividades de la medicion, la l11edicion real puede COl11enzar. Durante la fase de
recopilacion de datos se definen, rellenan y almacenan en una base de datos una serie de
fonnularios en los que se obtienen todos los datos de las mediciones. Finall11ente, durante
la fase de interpretacion, las mediciones son utilizadas para responder a las preguntas
fonnuladas, y las respuestas son usadas de nuevo para ver si se han logrado los objetivos
planteados.
Pregunta Respuesta
Metrica Medicion
Plan del Proyecto
Definicion Interpretacion
Datos Recopilados
Planificacion Recopilacion de Datos
Figura 9.5. EI Proceso GQM (van So ligen y Berghout, 1999)
A continuacion se describen con mayor detalle las cuatro fases de GQM.
2.2.1. PLAl'TIFICACION
Los objetivos principales de esta fase son la recopilacion de toda la infol1nacion
necesaria para un inicio exitoso del proyecto de medicion, as! como la motivacion y
preparacion de los miembros de la organizacion p"ara llevar a cabo el programa de
medicion. EI plan del proyecto constituye el principal entregable de esta fase. en que se
incluyen los documentos, procedimientos, calendarios y objetivos del progral11a de
l11edicion. as! como un plan de fonnacion de los desalTolladores implicados en el
programa. El plan proporciona la base para el fomento y aceptacion del programa de
medici on por paIte de la directiva. Las etapas que componen la fase de planificacion son:
1. Establecer el equipo GQM. que es una etapa fundamental ante la necesidad de
garantizar la continuidad de los programas de medici on. En much as ocasiones.
cuando los plazos de entrega de los productos estim cerca se dedica menos
atencion a las actividades del programa de medicion, por 10 que se requiere un
equipo GQM que deberia tener las siguientes cualidades: ser independiente de los
216 C\UDAD DE SISTE\L-\S ["iFOR\L'\TICOS E RA-\IA
equipos del proyecto y no tener especial interes en los resultados de la medicion:
poseer suficiente conocimiento previo sobre los objetos de la medicion; respetar a
los miembros del proyecto cuando llevan a cabo las tareas del proyecto y
reconocer que son ellos los que llevan a cabo las acciones de medicion y mejora:
tener una mentalidad de Olientacion a la mejora, incluso sobre si mismos: ser
entusiastas para motivar a los miembros del proyecto. Los roles del equipo GQM
son: gestor (manager), que es el responsable de dar continuidad en to do momento
del programa de medicion. "coach" que es experto en GQM e ingeniero de
soporte (support engineer), que da sopOlte a las actividades de medicion. Las
principales actividades del equipo de GQM son: planificar los programas de
medicion en el contexto de los proyectos de desanollo: realizar las actividades de
definicion de la medicion y desanollar los entregables QGM: comprobar los
datos recogidos por el equipo del proyecto y los datos disponibles del proceso:
preparar la interpretacion de los datos de la medicion e: infol111ar sobre el
progreso del equipo de proyecto y de gestion y comunicar los resultados.
J Seleccionar las areas de mejora, en la que se seleccionan las posibles areas de
mejora de los productos 0 procesos, como podrian ser: problemas evidentes a los
que se enfrenta la organizacion. areas a mejorar identificadas tras una valoracion
de procesos 0 areas de mejora de productos en base a objetivos de negocio de alto
nivel. Esta seleccion debe realizarse en fi.mcion de los objetivos de negocio. y en
especial en relacion a los costes. tiempo, riesgos y calidad. Una vez seleccionada
un area adecuada. el equipo GQM deberia considerar todos los detalles. como: los
problemas que podIian oCUITir: influencias extel11as como las personas
implicadas. tecnologias. leyes. procesos y productos: y el conocimiento y
experiencia previa en medici on que tienen las personas que van a participar en el
proyecto.
3. Seleccionar el proyecto de aplicacion y establecer un equipo del proyecto. El
exito de un programa de medicion depende fundamental mente de la voluntad.
motivacion y entusiasmo de los miembros del equipo de proyecto. ya que son
ellos los que van a realizar las actividades de medicion. Por ello. el equipo GQM
debe hacer un esfi.lerzo para alinear los objetivos de la medicion con las ideas de
mejora del equipo del proyecto. Para ello deben controlar y estimular
continuamente la dedicacion del equipo del proyecto a las actividades de
medici on.
4. Crear el plan del proyecto, actividad que se realiza una vez se ha establecido el
equipo del proyecto y se han seleccionado las areas de mejora. Como resultado se
obtiene el plan del proyecto que deberia contener los siguientes elementos:
a. Reslimen de fa Gestion. que presenta de fOlma resumida (en 20 line as
aproximadamente) el programa de medici on.
Q RA-ylA CAPiTULO 9: :"lEDICIO?\, DE SISTEylAS DE IMOR.vlACION 217
b. Introduccion, que presenta el alcance del programa de medicion, asi
como la relacion entre los objetivos de la mejora y los objetivos del
proyecto de desalTollo de software.
c. Calendario, que incluye la planificacion temporaL entregables,
asignaciones de recursos y amilisis coste-beneficio del programa de
medicion.
d. Organi:::acioll, que describe las eshl1cturas organizacionales, del proyecto
y equipo GQM que son relevantes en el programa de medicion.
e. Procesos de gestion, que contiene pliOlidades, procedimientos de
generacion de infol1nes de gestion asi como actividades de conh'ol de
nesgos.
f. Forlllacioll y promocion. que presenta el plan para la f0l111acion de los
miembros del equipo del proyecto y la comunicacion de los resultados en
la organizacion.
5. Formacion y promocion, en la que el equipo GQM debelia organizar sesiones
frecuentes de fonnacion y promocion en las que se presenten de fOl1na clara los
objetivos de medicion propuestos, los beneficios del programa de medicion, el
impacto del programa de medici on en las actividades diarias del equipo de
proyecto y las experiencias en otros proyectos u organizaciones. El objetivo es
motivar y f0l111ar a los miembros del equipo del proyecto en la realizacion del
programa de medicion.
2.2.2. DEFINICION
En esta fase se incluyen las actividades necesarias para definir fOl1nalmente el
programa de medicion y como resultado se obtienen los planes GQM, de medicion y de
amilisis. Las etapas de la fase de definicion son:
I. Definir los objetivos de la medicion, para 10 que se consideran los objetivos de
mejora del plan del proyecto definidos en la fase anterior. Como resultado se
obtiene una definicion f0l111al y bien estmcturada de los objetivos, para 10 cual se
utilizan plantillas como la que se muesh'a en la tabla 9.2, donde los elementos de
la plantilla son los siguientes:
I> El objeto del estudio es la entidad que se estudia en el experimento, la cual
puede ser producto, proceso, recurso, modelo, mehica, teolia, etc.
EI proposito define cmil es la intencion del experimento.
I> El enfoque de la calidad es el efecto principal que se estudia en el experimento.
218 CAUDAD DE SISTEMAS
e La perspectiva nos define el punto de vista desde el cual se van a interpretar
los resultados del experimento.
e EI contexto es el "entomo" en el que se lleva a cabo el experimento. EI
contexto define brevemente el personal (sujetos) implicado y los artefactos
software (objetos) que se utilizan en el expelimento.
ANALlZ.'I.R el ob.ieto de estudio bajo medici6n
CON EL PROPOSlTO DE entender, controlar, 0 mejorar el objeto
CON RESPECTO A el enfoque de caUdad del objeto en el que se centra la
...
medici6n
.. DESDE EL P:L;NTO DE\'1STADE o perspectiva de las personas que miden el objeto
E)I; ELCO)l;TE.UO DE el entorno en el que la medici6n tiene lugar
Tabla 9.2. PlantiIIa de Definicion de GQM (Basili et al., 1994)
2. Revisar 0 producir los modelos de proceso software. Estos modelos de
procesos deben dar soporte a la definicion de las mediciones. Si existen
previamente en la organizacion, estos deben ser revisados y si es necesario
mejorados. Si no existen, los modelos de procesos deb en ser definidos por el
equipo GQM y aprobados por el equipo del proyecto.
3. Realizar entrevistas GQM, de fODna que los miembros del equipo GQM
puedan extraer de los miembros del equipo del proyecto toda la informacion
relevante en relacion a los objetivos de la medicion. Para ello se realizan
entrevistas individuales en las que para facilitar la comunicacion se puede hacer
uso de las hojas de abstraccion ("abstraction sheets "). Las hojas de abstraccion
incluyen los aspectos basicos a considerar en las entrevistas GQM, tales como:
GCl/ales son las metricas para medir el objeto asociado a lin determinado
objetivo, de acuerdo a los miembros del proyecto?, Gcual es el conocimiento
actual del miembro del proyecto respecto a estas metricas?, Gque factores
extern os pueden il?jluenciar las metricas J de que modo?
4. Definir preguntas e hipotesis, en base. a los objetivos de la medicion de f0l111a
que se de soporte a la interpretacion de los datos. De la misma f0l111a que los
objetivos se definen a un alto nivel de abstraccion, las preguntas constituyen un
refinamiento de los objetivos a un nivel mas operacional. Con la respuesta a las
pregllntas planteadas, se deberia poder concluir si se cumple un detel1ninado
objetivo. Para cada pregunta, las respuestas esperadas son fOl1nuladas como
hipotesis que son comparadas en la fase de interpretacion con los resultados
reales de la medicion.
5. Revisar preguntas e hipotesis, para asegurar que se han fODnulado las preguntas
e hipotesis COlTectas.
~ R A M A CAPiTULO 9: ;"!EDICION DE SISTEMAS DE INFOR.!'vIACION 219
6. Definir las metricas. Las metlicas deben proporcionar la infonnacion
cuantitativa que pel111ita responder las preguntas planteadas de una fonna
satisfactoria. Por 10 tanto, las metlicas son el refinamiento de las preguntas en
mediciones de los productos 0 procesos.
7. Comprobar consistencia y completitud de las metric as, de fonna que la
definicion de los objetivos preguntas y metricas sea consistentes y completa con
respecto al objeto sujeto a medici on.
8. Producir el plan GQM, en el que se inc1uyen los objetivos, preguntas, metlicas
e hipotesis de un detenninado programa de medicion. Sirve como guia para la
interpretacion de los datos y para el desalTollo del plan de medicion y amllisis.
9. Producir el plan de medici6n, en el que se inc1uye la definicion f0l111al,
descripcion textual y todos los resultados 0 valores posibles de las metlicas
directas asi como la persona responsable de recoger dichos valores (programador,
ingeniero, gestor del proyecto, etc.). Tambien se inc1uye el momento de tiempo
en el que se debe tomar el valor de cada metlica directa y el medio (helTamienta 0
fonnulario) que la persona encargada debe usar.
10. Producir el plan de amilisis, que es un documento en el que se simula la
interpretacion de los datos de acuerdo al plan GQM. Para ello se presentan
simulaciones de los resultados de las mehicas, as! como gn'ificos y tab las en
relacion a los objetivos y preguntas planteadas. EI plan de amilisis pretende
basicamente describir como la infonnacion relevante de la medicion debe ser
procesada con el fin de que pueda ser interpretada fikilmente por el equipo del
proyecto.
II. Revisar los planes, que deben adelmis ser aprobados por el equipo del proyecto
antes de que comience la obtencion de los datos reales de las mediciones.
Modelos
Implicitos
Definicion
Objetivo .
Interpretacion
Preguntas
Figura 9.6. Fase de Definicion de GQM (Basili y Weis, 1984)
220 CAUDAD DE SISTD!AS IMOR".['A TICOS
En resumen, la definicion de metricas con el metodo GQM se realiza mediante una
aproximacion atTiba-abajo (figura 9.6) en tres niveles: el nivel conceptual en el que se
definen los objetivos (goal). el nivel operacional en el que se definen las preguntas
(question) y el nivel cuantitativo en el que se definen las metricas (metric).
2.2.3. RECOPILACION DE DATOS
Esta fase se inicia, una vez se han completado todas las actividades de definicion.
Como resultado se obtienen una serie de fonnulatios cumplimentados y almacenados en
una base de datos. Las principales etapas que componen esta fase son:
l. Formacion y arranque de la obtencion de datos, que incluye:
a. Periodo de Entrenamiento (Hold Trial). Este periodo de pmeba es
llevado a cabo antes de comenzar la toma real de datos y durante el
mismo se definen y prueban los procedimientos de recogida de datos asi
como las hen-amientas y fonnularios. Esta actividad suele llevarse a cabo
por dos personas como maximo (una al menos es preferible que sea un
ingeniero senior) durante uno 0 dos dias y el principal objetivo es evitar
en'ores y detectar posibles mejoras a realizar en los procedimientos.
helTal11ientas 0 fOl11mlarios.
b. Sesion de Inicio (Kick ofj), durante la que todos los participantes en el
programa de l11edicion deben estar presentes. El principal objetivo es
llegar a un acuerdo con el equipo del proyecto para el cOl11ienzo de la
recogida de datos de la medicion y se instruye a sus miembros en los
procedimientos de recogida de datos, hen-amientas y fonnulatios.
c. Recogida de Datos. durante la que se rellenan los fonnulatios y se
entregan al equipo GQM de manera frecuente, preferiblemente de f0l111a
diaria. El equipo GQM comprueba la consistencia y con-eccion y
almacena los fonnularios, estableciendo la base de metric as para el
posterior establecimiento del sistema de soporte a la medicion.
2. Construccion del sistema de soporte a la medicion (lvieaslirement Support
~ v s t e m MSS). Este sistema constituye un elemento esencial del programa de
medicion siendo su base un conjunto de hen-amientas generic as tales como hojas
de calculo, helTamientas estadisticas, aplicaciones de bases de datos y
hen-amientas de presentacion. El sistema MSS debe dar soporte a todas las
actividades de medicion, en las que se incluyen la obtencion, almacenamiento,
procesamiento, presentacion y empaquetamiento de los datos de medicion. El
sistema MSS esta fonnado por tres partes basicas:
1\."'.-\1:\ C'.PiTCLO 9: \IEDICIO;-; DE SISTE\IAS DE IMOR\l:\CIO;-; 221
a. Base de Merricas lvf55, que contiene los datos recabados,
b. Hojas de Analisis M55, que son los distintos tipos de presentaci6n de los
datos obtenidos respecto a diferentes niveles de abstracci6n, que en
orden ascendente son: capa de datos sin procesar, capa de datos
procesados y capa de gn'ificos y diagramas. Cada hoja de analisis debe
incluir: la descripci6n del objetivo y todas las preguntas derivadas del
mismo (como en el plan GQM); todos los datos necesmios para
responder las preguntas planteadas de una fOll11a satisfactoria con
respecto a los objetivos e hip6tesis.
c. Transparencias de Analisis ivJ55, que son las transparencias de
presentaci6n que son mantenidas de fOll11a que cualquier cambio de las
hojas de analisis produzca su actualizaci6n inmediata.
2.2.4. INTERPRETACION
La fase de interpretaci6n utiliza los datos tomados en la medici6n para responder
las preguntas planteadas y de esta fOll11a. para identificar si se alcanzan 0 no los objetivos.
Las etapas incluidas en esta fase son:
I. Preparacion de las sesiones de realimentacion, en la que los miembros del
equipo GQM deberia preparar todo el material necesario. como: hojas de analisis,
diapositivas de presentaci6n, material adicional. etc. EI material de realimentaci6n
deberia ser util para los miembros del equipo del proyecto durante estas sesiones.
2. Sesiones de Realimentacion. Durante estas reuniones se deben debatir los
resultados de la medici6n y se suelen celebrar cada seis u ocho semanas con una
duraci6n tipica de una hora y media ados horas. Durante estas reuniones el
equipo del proyecto. como expertos en el objeto bajo medici6n. deben analizar
los resultados y obtener conclusiones y acciones a realizar. Para ella se centran
en: evaluar puntos de acci6n de sesiones previas: analizar e interpretar los datos
recogidos en la medici6n respecto a los objetivos y preguntas del plan GQM y
obtener conclusiones y traducir estas conclusiones en acciones concretas. Para
ella los miembros del equipo del proyecto deben adoptar un enfoque constructivo
y dirigido por objetivos.
3. Generacion de informes de interpretacion de los resultados de la medicion.
Al final de cada sesi6n de realimentaci6n el equipo GQM escribe un informe en
el que se incluyen todas las observaciones. inteq)!'etaciones. conclusiones y
puntos de acci6n relevantes formulados. Este infolll1e es distribuido a los
miembros del equipo del proyecto.
222 CAUDAD DE SISTEMAS INFOIUvlA. TICOS :9RA-MA
4. Amilisis de costes y beneficios de un programa de medicion. EI factor
fundamental del exito de un programa de medici6n es el logro de los objetivos
planteados. Sin embargo, es necesario incluir tambien en el infonne final un
amilisis de costes/beneficios. En la tabla 9.3 se muestran costes y beneficios
asociados a los programas de medici6n.
COSrES BENEFICroS
Tiempo empleado por el equipo GQM en
Ventas adicionales derivadas de la mejora de
preparar un programa de medici6n (salario y
gastos generales)
cali dad
Tiempo empleado por el equipo del proyecto en Evitar decrecimiento en ventas debido a la
reuniones mejora de cali dad
Tiempo empleado por el equipo del proyecto en
Ahorro de tiempo y esfuerzo en el desarrollo de
cumplimentar fonnularios
software debido a un mejor entendimiento de
los procesos de desarrollo
Tiempo empleado para desarrollar el MSS
Ahorro de tiempo debido a una mejor gesti6n
de los recurs os
Compra de hardware y software adicional para
dar soporte al programa de medici6n
Evitar costes debido a una mejor gesti6n de
Tiempo empleado por el equipo GQM para
recursos
procesar los datos de la medici6n y preparar las
sesiones de realimentaci6n
Tabla 9.3. Beneficios y Costes Potenciales de los Pl-ogramas GQM
2.2.5. EJEMPLO DE APLICACION DE GQM
Como ejemplo de definici6n de metric as utilizando el metodo GQM se va a
describir la propuesta de metricas de Calero (2001) para evaluar la mantenibilidad de
bases de datos relacionales.
El objetivo de acuerdo a GQM seria el que se muestra en la tabla 9.4.
Ac"iALlZAR.
I
BD Relacionales
1
CON EL PRopoSnODE
.1
ase!Wrar
1
..
CON RESPECTOA
I
la mantenibilidad
I
DESDE ELPliNTODE VlSTA DE
I
los disefiadores de BD
1
EXELCONTEXTO DE
1
desarrollo y mantenimiento de BD
1
Tabla 9.4. Ejemplo de Aplicacion de GQM (Calero, 2001)
Para satisfacer el objetivo anterior se definen las siguientes preguntas:
RA.-MA CAPiTULO 9: MEDICION DE SISTEMAS DE
iii Pregunta 1. ;,C6mo il?fluye la complejidad de las tab las en la mantenibilidad
de las bases de datos relacionales?
iii Pregunta 2. (,C6mo influye la complejidad entre tablas en la mantenibilidad de
las bases de datos relacionales?
Para responder a las preguntas planteadas se de fin en las siguientes metricas:
iii Pregunta 1:
o Numero De Atributos De Una Tabla (NA(T)), definida como el
numero de atributos de una tabla T.
o Numero De Claves Ajenas (NFK(T)), definida como el numero de
claves ajenas de una tabla T.
o Ratio De Claves Ajenas De Una Tabla (RFK(T)), definida como el
porcentaje de atlibutos de la tabla T que son claves ajenas (ver figura
9.7).
iii Pregunta 2:
RFK (T)
NFK (T)
NA (T)
Figura 9.7. Metrica RFK(T)
o Numero De Tablas (NT), definida como el nlllnero total de tablas que
hay en el esquema.
o Numero De Atributos (NA), definida como el nlllnero total de ahibutos
que hay en el esquema.
o Numero De Claves Ajenas (NFK), definida como el nlllnero total de
claves ajenas que hay definidas en el. esquema.
Fuggetta et al. (1998), Lindstrom (2004), y van Solingen y Berghout (2001)
proporcionan oh'os ejemplos relevantes de aplicaci6n de GQM en la indushia.
2.3. Goal Question Indicator Metric (GQ(I)M) y Goal-Driven
Software Measurement
La l11etodologia GQ(I)M identifica y define mehicas software que dan soporte al
negocio de la empresa, la l11ejora de sus procesos y los objetivos de sus proyectos,
asegurando la relevancia y trazabilidad de los objetivos respecto a los datos obtenidos.
GQ(I)M comparte much as similitudes con la metodologia antelionnente descrita GQM,
224 CAUDAD DE SISTEMAS INFORNIA TICOS
salvo en el aspecto de que aiiade soporte explicito a los indicadores. Por ello, el artefacto
mas relevante de esta metodologfa es la "Plantilla de Indicadores", que es utilizada para
definir de fonna precisa el "quien", "que", "donde", "cwindo", ''par que" y "como" de un
indicador. asf como para documentar el alineamiento del mismo con los objetivos de la
organizaci6n. Todo ella garantiza disponer de una colecci6n consistente de metricas a la
hora de constmir un indicador y proporciona elementos adicionales para asegurar una
interpretaci6n consistente del propio indicador (Goethelt y Siviy, 2004).
EI proceso que sigue la metodologia GQ(I)M es el propuesto por el SEI en su
enfoque "Goal-Driven Software Measurement" (Park et aI., 1996). La metodologia esta
f0l111ada por diez pasos organizados en tome a h'es conjuntos generales de actividades
(Park et aI., 1996: Zubrow, 1998):
Paso
Paso
I
Objetivos de
Negocio
v
)i>l,Que quiero lograr?
Para hacer estc.
necesitare ....
V <1
P a ~ o
3
i,Que necesito saber?
y
SubObielivos
p
Paso
Modelo Mental
v
EI Proceso
c""" Q C"C"".
;... Entidades
v ~
Atributos
P'"
Paso
V ~
Entidades
V ~
Atributos
?
Enlidades
v ~
Atributos
?
Objetivos de
Medici6n
01 02
Figura 9.8. Identificacion de ObjetiYos en GQ(I)i\I (Park et at .. 1996)
1. Identificaci6n de ObjetiYos. Que se divide en los siguientes pasos (vease figura
9.8):
a. Paso 1. Identijicar los objetivos de negocio. En este primer paso se
deben identificar los objetivos que dirigen los esfuerzos de la
organizaci6n y puede iniciarse en cualquier nivel de la organizaci6n en el
que se puedan establecer de fonna razonable dichos objetivos. Una vez
identificados dichos objetivos es necesario priorizarlos. Como resultado
se obtiene una lista de objetivos ordenada seglll1 su prioridad.
R.-\-?v1:\ CAPiTLLO 9: \IEDICI00i DE SISTE\IAS DE 10iFORMACI00i 225
b. Paso 2. Identijicar 10 que se quiere co/weer 0 aprender. Una vez
identificados los objetivos de negocio, el siguiente paso es comenzar a
identificar 10 que a la organizaci6n Ie gustaria saber con el fin de
entender. yalorar. predecir 0 mejorar las actividades relacionadas con la
consecuci6n de los objetivos. Para ello se fonnulan preguntas tales como
"(:QlII? aetividades tengo que gestionar 0 reali::ar?" y se completan
sentencias del tipo "Para !weer esto. neeesitare...". Ello implica en este
paso la traducci6n de los objetivos de negocio en declaraciones a nivel
operacional. Los objetivos son enlazados con el conocimiento obtenido
de los procesos de negocio y estrategias de la organizaci6n. Las
preguntas relacionadas con los objetivos planteados son estmcturadas en
fonna de entidades (productos de trabajo 0 actividades) y ahibutos
(tamafio, esfuerzo 0 calidad) asociados con los procesos de la
organizaci6n. En muchas ocasiones la descripci6n de los procesos de
trabajo de la organizaci6n no es explicita y se encuentra m::is bien como
un modelo mental en la misma. En todo caso es de gran relevancia
identificar los productos de trabajo. actividades y otras entidades que
puedan ofrecer oportunidades de mejora.
c. Paso 3. ldelltijicar los subobjetivos. Los subobjetivos proporcionan un
refinamiento a nivel operacional de los objetivos generales. Se obtienen
analizando las similitudes y aspectos comunes de las preguntas
planteadas sobre las entidades. agrupando las mismas en funci6n de los
aspectos que h'atan de resolver. Ello pem1ite identificar mas claramente
la relaci6n entre los resultados obtenidos (respuestas a las preguntas) y
los objetivos.
d. Paso 4. Identijicar las entidades y atriblltos relacionados COil los sllb-
objetivos. En este paso se utilizan las preguntas para refinar el modelo
mental del proceso y sus entidades y atributos asociados. Esto pennite
establecer un conjunto bien definido de objetivos de negocio que son
utilizados para el ananque del proceso GQ(I)M propial11ente dicho. Este
paso cOl11ienza seleccionando las prt3guntas que se consideran relevantes
y que sue len estar asociadas con los subobjetivos de mayor prioridad.
Una vez que se tiene una lista de preguntas es necesario identificar las
entidades implicadas y sus atributos. La cuantificaci6n de estos atributos
debe pel111itir obtener respuestas a las preguntas planteadas. Este paso es
iterativo 10 que puede conducir al refinamiento de las cuestiones y
subobjetivos a medida que se l11ejora el esbozo 0 esquema mental del
proceso.
e. Paso 5. FOl'lJIa/i;,ar los objetivos de negocio. En este paso se traducen
los objetiYos de negocio en objetivos de medici6n. que une el prop6sito y
las perspectivas de los objetivos del negoclo con las posibilidades de
226 CAUDAD DE SISTENIAS INFOIUvL-I. TIC OS
medicion que existen en la organizacion de acuerdo a sus procesos de
trabajo. AdetTI<ls, el objetivo de medicion expresa los factores del entomo
que es impOltante en tender por todos q u ~ l l o s encargados del diseno y
realizacion de las actividades de medicion y amilisis. Para estar bien
estructurados los objetivos de medicion deben incluir: el objeto de interes
(entidad); el proposito, la perspectiva y una de scrip cion del entomo y
restricciones. EI proposito de la medici on puede ser: entender, predecir,
planificar, controlar, comparar, valorar 0 mejorar algll11 aspecto de
calidad 0 productividad del objeto 0 entidad. La perspectiva identifica
qui en 0 quienes son los interesados en los resultados de la medicion. La
infom1acion del contexto 0 entomo ayuda en la interpretacion de los
resultados de la medicion.
2. Definicion de Indicadores. Que se compone de:
a. Paso 6. Idelltijicar preguntas cllalltijicables y los illdicadol'es
I'elacionados. En este paso se identifican las preguntas e indicadores a
partir de cada uno de los objetivos de medicion planteados. Los
indicadores representan los productos obtenidos en las actividades de
medicion y son utilizados por los directores de proyectos y profesionales
como fuente de infonnacion de sopOlte para la toma de decisiones. A la
hora de disenar un indicador hay que considerar aspectos tales como la
frecuencia de toma de datos, el tiempo requerido para generar el
indicador, la necesidad de datos historicos, etc. En este sentido es muy
uti 1 el uso de plantillas que faciliten la definicion de indicadores. En el
apattado 2.3.1 se describe la plantilla de definicion de indicadores de la
metodologia GQ(I)M. Otro aspecto impOltante para facilitar a las
organizaciones entender claramente si han alcanzado sus objetivos es
distinguir los tipos de indicadores que se pueden definir. Goethert y
Saviy (2004) distinguen tres tipos de indicadores:
lndicadores de progreso. Estos indicadores se utilizan para reali-
zar el seguimiento del progreso en la ejecucion de las tareas defi-
nidas. POI' ejemplo, las tecnicas de "Valor Anadido" (earned va-
llie) 0 los diagramas de Gantt penniten construir buenos indicado-
res de este tipo. El cumplimiento de los val ores de este tipo de in-
dicador significani que la ejecucion de las tare as se esta lievando a
cabo con exito pero no garantiza la consecucion de los objetivos
de negocio aunque un falio en este indicador puede significar un
problema impottante para conseguir dichos objetivos.
lndicadores de alllilisis. Este tipo de indicadores es utilizado para
ayudar en el an3.lisis de las salidas producidas por las tareas.
R./\.-MA CAPiTULO 9: ;-'fEDICION DE SISTEMAS DE INFORJvL\CION 227
Un indicador que representa el nillnero y tipo de defectos detecta-
do en cada fase del desarrollo es un ejemplo de este tipo de indi-
cadores.
b. Paso 7. Identificar los elementos de datos. Los indicadores reflejan los
elementos de datos que son necesarios. En esta etapa se identifican estos
elementos 10 que significa que no es necesario aim que se definan las
metricas, tarea que se realiza en el siguiente paso.
c. Paso 8. Definir las metricas. Una vez identificados los elementos de
datos hay que definir las metricas necesarias que perrnitan obtener
respuesta a las preguntas planteadas. La definicion de las metricas es un
paso clave para obtener una interpretacion adecuada de los datos
recogidos y debe realizarse teniendo en mente el proposito del indicador
o indicadores. Para facilitar una definicion no ambigua de las metric as el
SEI ha propuesto una serie de marcos de trabajo de la medici on con listas
de comprobacion para metricas que evalilan atributos como el tamafio,
esfuerzo, consecucion de hitos y defectos (Park, 1992; Florac, 1992;
Goethert, 1992).
En la figura 9. 9 se muestra el esquema general para la definicion de indicadores.
Objetivos de
01 02
Medici6n
.. <& ..
Preguntas
P1 P2 P2
A .. <\
11 12 13 14
Indicadores
-e 1! ..
M1 M2 M3
MtHricas
..
Listas de Comprobaci6n
Definicion de .\Ictricas
Definfciones
V
)(
Paso
Paso
Paso
Objetivos
:'\cgocio- SubObjcti\"os - \ledici6n
Prcguntas
(',Que quiera suber 0 aprcndcr'!
lndicadorcs
SLoe - EsfuerLo - Informes de
Problemas
PlantilIu de Definicion
de Indicadorcs
(Ji'I:.::i;(1

Figura 9. 9. Definicion de Indicadores en GQ(I)M (Adaptado de Goethert y Siviy, 2004 y
Park et al., 1996)
3. Crear un plan de accion, compuesto por los siguientes pasos:
228 CAUDAD DE S!STE'.IAS !?\FOR:VI.A. TICOS
a. Paso 9. Identificar las acciolles a implementm: Hasta el momento ya se
dispone de la definicion de los indicadores y metricas que pueden dar
respuesta a las preguntas planteadas en funcion de los objetivos de
negocio. Ahora es el momento de analizar la situacion actual en la
organizacion con respecto a las necesidades de infonl1acion planteadas.
Es necesario identificar las fuentes de informacion existentes en 11
organizacion ya que los elementos de datos requeridos podrian
encontrarse en una gran diversidad de fuentes que incluyen planes de
proyectos, sistemas de seguimiento de defectos. de gestion de
configuracion. de generacion de infonnes de esfuerzo. etc. Del mismo
modo, hay que hacer un amilisis de los datos que son necesarios y no
estan disponibles en la organizacion en el que se valore la cantidad de
esfherzo que requiere su obtencion. En este aspecto se considera si son
necesarias nuevas helTamientas. fOl11mlarios 0 incluso fonl1acion para
obtener los datos. En este paso tambien se deben pliorizar los datos
respecto a los indicadores de los que dependen. Por ella para cada
elemento de datos se debe detel111inar su estado respecto de si existe una
explicita definicion de una metrica para dicho elemento de datos. si se
han detenninado los puntos en el proceso en el que se realizaran las
medici ones y su frecuencia. si hay fOl11mlarios y procedimientos para
recoger y registrar los datos. quien tomara dichos datos: como se
analizaran. si hay helTamientas de soporte. etc.
b. Paso 10. Preparar lIll plan de accion. Una vez que se ha realizado el
analisis necesario y se conocen los datos requeridos y las actividades de
medicion a llevar a cabo para obtenerlos es el momenta de definir el plan
en el que se incluyan las acciones concretas a llevar a cabo para satisfacer
las necesidades de infor111acion planteadas.
2.3.1. P L l ~ T I L L PARA LA DEFINICION DE INDICADORES
La plantilla para la definicion de indicadores constituye el artetacto claw de la
metodologia GQ(I)M. Las organizaciones frectlentemente no obtienen los beneficios
potenciales de un buen programa de medicion debido a las inconsistencias en la
construccion e interpretacion de los indicadores deri\'ados de los datos de la medicion.
Para ella es impor1ante disponer de una plantilla para su definicion y de una guia
que facilite la utilizacion de la misma. tal y como proponen Goethel1 y Siviy (2004). La
plantilla de un indicador se utiliza para documentar de for111a precisa un indicador. asi
como la fonna de obtenerlo y de interpretarlo y presentarlo COlTectamente. Tambien ayuda
para asegurar la recopilacion consistente de las metricas necesarias para obtener el
indicador asi como los criterios necesarios para la interpretacion de las metricas obtenidas.
Para la definicion de un indicador la plantilla incluye los siguientes campos:
e ObjetiYo del indicador: el objetivo 0 proposito del indicador.
RA-M.-'.. C-'..PiTlJLO 9: DE DE Il\FOR?v1ACIOl\ 229
(!) Preguntas: la lista de preguntas que el usuario del indicador intenta responder
con su definicion.
(!) Representacion Gnifica del indicador.
(!) Perspectiva 0 punto de vista, es decir, la descripcion de la audiencia de interes
para la que se ha definido el indicador.
(!) Entradas: la lista y definiciones de las metricas requeridas para constmir el
indicador.
(!) Algoritmos: la descripcion del algoritmo usado para constmir el indicador a
partir de las metticas definidas.
(!) Suposiciones: la lista de suposiciones sobre la organizaclon, sus procesos,
modelo de ciclo de vida, y todos aquellos datos que sean impOltantes para
obtener y usar el indicador.
(!) Informacion de toma de datos: en la que se indica como, cuando, con que
frecuencia, quienes, etc. relll1en los elementos de datos requelidos en la
construccion del indicador.
(!) Informacion de generacion de informes de datos: infonnacion sobre qui en
es responsable para generar los infonnes de los datos, para quienes y la
frecuencia de almacenamiento, recuperacion y segUlidad de los datos.
(!) Amilisis e Interpretacion de los resultados: infonnacion sobre como analizar
e interpretar el indicador.
Las organizaciones pueden adaptar la estructura de esta plantilla a sus entomos
particulares ya que la plantilla propuesta par el SEI incluye los campos que se consideran
COl11unes para la definicion de indicadores.
Algunos ejemplos de aplicacion de la plantilla de indicadores pueden consultarse
en Goethert y Siviy (2004).
2.4. Practical Software Measurement (PSM)
La l11etodologia PSM (Practical Sofhmre Measurement) (McGan), et al., 2002) se
basa en la experiencia obtenida por docenas de organizaciones para saber cual es la mejor
manera de il11plementar un programa de medida de software con garantias de exito. Las
practicas y principios que prop one se han llevado a cabo con exito en multitud de
proyectos software. No se trata de una aproximacion general, sino que incluye !ineas guia
para ajustar los marcos de trabajo de la medida y las practicas a la situacion de cada
proyecto en cada orgallizacion.
230 CAUDAD DE SISTEvlAS TICOS
PSM prop one un Modelo de Procesos de Medida (figura 9.10) que se divide en
cuatro actividades principales:
I. Planificacion de la Medicion. En esta actividad se definen las mehicas
necesarias que proporcionen la visibilidad en los proyectos necesaria para
satisfacer las necesidades de infom1aci6n. Esta actividad inc1uye identificar que
necesitan saber los beneficiarios de la medici6n (encargados de la toma de
decisiones), relacionar las necesidades de infonnaci6n con las entidades que
pueden ser medidas y seleccionar y especificar meh"icas basadas en los proyectos
y en los procesos organizacionales.
2. Realizacion de la Medicion. Esta actividad implica reunir los datos de las
mediciones, realizar el amilisis y presentar los resultados para que la infonnaci6n
pueda ser util para la toma de decisiones.
3. Evaluacion de la Medida. En esta actividad tanto el proceso de medici6n como
las propias mehicas definidas deben evaluarse y mejorarse peri6dicamente segll11
sea necesano.
4. Establecimiento y mantenimiento del Compromiso. Esta actividad implica
establecer los recursos, fonnaci6n y henamientas necesarias para implementar un
programa de medici6n de fonna efectiva, y 10 que es m:ls importante, asegurar
que hay una gesti6n que usa la infonnaci6n producida.
Establecer y
Mantener el
compromiso de
medici6n
Ambito de PSM
Realimentacion
de los usuarios
PROCESOS TECNICOS Y DE
GESTION
Objetivos y
Tareas
.. Planificar el
.......
.. proceso
Plan de Medida
Analisis de
Resultados
.. Realizar las
Nuevas Tareas
mediciones
Analisis de
Resultados y
de la Realizacion de
Acciones de Mejora la Medida
Evaluaci6n
Figura 9.10. Modelo de Procesos de Medicion de PSM
\;': RA.-MA CAPiTULO 9: MEDICION DE SISTElvl""S DE INTOR.'vIACION 231
Un aspecto basico para disponer de programas de medicion efectivos es el hecho de
disponer, al final del proceso, de infom1acion (itil para los encargados de la toma de
decisiones. Para ella PSM incorpora un modelo de infonnacion de la medicion que
relaciona las entidades que son medidas con las medidas definidas y en ultima instancia
con las necesidades de infonnacion que se satisfacen. Este modelo incorpora una
estructura denominada constructor de la medicion que describe como los atributos
relevantes de los productos y procesos se cuantifican y se convierten en indicadores, que
son elementos que proporcionan la base necesaria para la toma de decisiones. Todo
constructor de la medicion implica tr'es niveles de medida: medidas base, medidas
derivadas e indicadores. La relacion que establece un constr1.1ctor de la medicion entre 10
que se mide y la necesidad de infonnacion que se tiene (que se satisface con un producto
de informacion) se representa en la figura 9.11.
Atributo
Medida
Base
Constructor de Medicion
Medida
Derivada
Indicador
.........fIi>- Producto de
Informacion
Figura 9.11. Relacion entre necesidades de informacion y atributos
En definitiva, PSM proporciona un metodo sistematico para la planificacion y
realizacion del proceso de medicion y analisis. Constiulye la referencia en la que se basa
el estandar intemacional ISOIIEC 15939, Y ambos se han convertido en la referencia para
la industria proporcionando ademas un lenguaje COmlll1 que facilita la comunicacion en el
ambito de la medicion software.
2.5. IEEE Std 1061-1998. Metodologia para Metricas de
Calidad del Software
Seglll1 este estandar (IEEE. 1998b) la calidad del software se puede considerar
como el grado en el que el software posee una combinacion cIaramente definida y
deseable de atIibutos de calidad. Este estandar, pues, trata de definir la calidad del
software para un sistema mediante una lista de atributos de calidad del software
requeridos por el propio sistema.
El proposito de las metIicas del software es hacer evaluaciones a traves del cicIo de
vida del software para comprobar si los requisitos de calidad del software se estan
cumpliendo, aunque sin que ella elimine la necesidad de un juicio humano en las
evaluaciones de software.
232 CAUDAD DE SISTE\L-\S TICOS
EI uso de esta metodologia pennite a una organizaci6n:
I) Lograr sus objetivos de cali dad.
I) Establecer requisitos de calidad para un sistema en su inicio.
I) Establecer criterios de aceptaci6n y estandares.
I) Evaluar el nivel de calidad logr'ado frente a los requisitos establecidos.
I) Detectar anomalias 0 problemas en el sistema.
I) Predecir el nivel de calidad que se lograra en el futuro.
I) Evaluar la facilidad de cambio en el sistema durante la evoluci6n del producto.
I) Nonnalizar, escalar, calibrar 0 validar una metrica.
En la figura 9.12 se muestra el marco de trabajo para las metl1cas de calidad de
sofuvare. Es un marco disei'iado para ser flexible y aplicable a todos los sistemas.
adaptandose a cada caso concreto sin cambiar los conceptos basicos.
Factor
CaUdad del Software
de un Sistema
\!etrica
Figura 9.12. Marco de trabajo para metricas de calidad de software en IEEE 1061-1998
EI estandar IEEE 1061-1998 propone una metodologia con el fin de establecer los
requisitos de calidad e identificar, implementar, analizar y validar el proceso y los
productos de calidad del sofuvare. Esta metodologia consta de los pasos que se detaIl an a
continuaci6n:
{; RA-'\IA (APiTCLO 9: \IE01(I00: DE SISTE:VIAS DE 233
I. Identificacion de las iVIetricas de Calidad del Software. Las acciones a realizar
en este paso son:
a. Aplicar el marco de trabajo de las metricas de calidad del software.
b. Realizar un amllisis coste-beneficio.
c. Identificar los costes de la implementaci6n de las metlicas.
d. Identificar los beneficios al aplicar las metIicas.
e. Ajustar el conjunto de metlicas.
f. Adquirir un compromiso con el conjunto de metlicas.
2. Implementacion de las iVIetricas de Calidad del Software. Para ella es
necesano:
a. Definici6n de los procedimientos de la colecci6n de datos.
b. Realizar un prototipo del proceso de medici6n.
c. Agrupar los datos y calcular los val ores de las metlicas.
3. Analisis de los Resultados de las iVIetricas del Software. Paso compuesto por:
a. Interpretar los resultados.
b. Identificar la calidad del sofuvare.
c. Hacer predicciones de la calidad del sofuvare.
d. Garantizar la confonnidad con los requisitos.
4. Validacion de las iVIetricas de CaUdad del Software. Para 10 cllal se realizan
las siguientes acciones:
a. Propuesta de validaci6n de las metricas.
b. Uso de criterios de yalidaci6n.
c. Procedimiento de yalidaci6n.
d. Requisitos adicionales.
234 CAUDAD DE SISTEMAS IN"FOR.cvlA TICOS
:,:
5. Validaci6n de las Metricas de Calidad del Software. Para 10 cual se realizan
las siguientes acciones:
a. Propuesta de validacion de las mehicas.
b. Uso de critelios de validacion.
c. Procedimiento de validacion.
d. Requisitos adicionales.
2.6. ISOIIEe 15939
Este estandar intemacional (ISO, 2002c) identifica las actividades y tare as
necesarias para identificar, definir, seleccionar, aplicar y mejorar de manera exitosa la
medicion de software dentro de un proyecto general 0 de la eShl.lctura de medicion de una
empresa. Tambien proporciona las definiciones de los tenninos de uso comlll1 relativos a
la medicion dentro de la indush-ia del software.
De acuerdo a este estandar, el principal objetivo del proceso de medicion del
software es reunir, analizar y proporcionar datos relativos a los productos desalTollados y
a los procesos implementados dentro de una organizacion, para ayudar a una gestion
efectiva de los procesos y demostrar objetivamente la calidad de los productos. Como
resultado de esta implementacion:
o Se establece y mantiene un acuerdo dentro de la organizacion a la hora de
medir.
o Se identifican las necesidades de informacion de los procesos tecnicos y de
gestion.
o Se identifica yio define un conjunto apropiado de medidas en funcion de las
necesidades de infonnacion.
o Se identifican las actividades de la medici on.
o Se recopilan, almacenan y analizan los datos necesarios y se interpretan los
resultados.
o Se usan productos de infonnacion para apoyar las decisiones y proporcionar
una base objetiva para la comunicacion.
o Se eva III an el proceso de la medida y las propias medidas.
o Las mejoras se comunican al responsable del proceso de medicion.
RA-\1A CAPiTULO 9: \[EDICION DE SISTE;VIAS DE INFORl'vlACION 235
Tal y como ya se ha comentado, este estandar define las actividades y tareas
necesmias para implementar un proceso de medicion de software. Una actividad es un
conjunto de tareas relacionadas que contribuyen a alcanzar el objetivo y los resultados del
proceso de medicion de software. Una tarea es un segmento de trabajo bien definido. Lo
que este estandar no especifica es como realizar cada una de las tare as que componen cada
actividad.
El proceso de medicion de software propuesto en el estandar se compone de cuah'o
actividades principales (figura 9.13) que se suceden en un proceso iterativo pennitiendo
una realimentacion y una mejora continua del proceso de medici on.
Los Procesos Tecn;cos y de Gest;on de una organizacion no se encuentran dentro
del ambito de este estandar, aunque son una intelfaz extema impOIiante para las
actividades de medicion que se incluyen en el estandar.
Hay dos actividades que se consideran el nllcleo del proceso de medici on:
Planificar y Realizar el Proceso de Medicion. Son las actividades que indican
principalmente la implicacion del usuario de la medicion. Las otras dos actividades
proporcionan la base del nllcleo del proceso y realimentacion para el propio mkleo e
involucran mas al propietario del proceso.
Requerimientos de t.1edicion
PROCESOS TECNICOS Y DE GESTION
Necesfdades
de
Informacion
Establecer y
Mantener el
compromiso de
:: Planificar el
medici6n Compromiso
Ambito de ISO/lEG
15939
proceso
p!anfr7cacfon <I
Base de experiencias de Medic<6n
acc/ones de majora
Productos
Informativos
Rea/imentacion
de los usuarios
v
Evaluaci6n
<I
Productos
fnformativos
y
Resultados de
f.1edidas
Productos Informativos
}' Resultados de eva/uacian
Figura 9.13. i\Iodelo de Procesos de Medicion de Software (ISO/lEe 15939)
Como se aprecia en la figura 9.13, para cada necesidad de infonnacion, el nllcleo
proporciona un producto de infonllacion que la satisfaga y este se comunica a la
organizacion para que sirva como base en la toma de decisiones.
236 CAUDAD DE SISTE"L\S
La Base de Experiencia de Medicion pretende capturar productos de infonnacion
de iteraciones anteriores del ciclo. evaluaciones anteriores de productos de infonnacion y
evaluaciones de iteraciones anteriores del proceso de medicion. As! se incluyen las
medidas que han resultado ser lltiles en la organizacion.
Las tareas para las diferentes actividades del proceso de medicion de acuerdo al
estandar se muestran en la tabla 9.5.
ACTIVlDAI)
I
TAREAS
Establecer y Mantener el Aceptar los requisitos de la l11edicion
Compromiso de Medicion Asignar recursos
Obtener las caracteristicas de la organizacion
Identificar las necesidades de infol111acion
Seleccionar las medidas
Planificar el Proceso de Medicion
Definir los procedimientos de recoleccion de datos. analisis e infol111eS
Detlnir los criterios de eyaluacion de los productos de infol1mcion y el
proceso de medicion
Reyisar. aprobar y proporcionar recursos para las tareas de medicion
Adquirir y utilizar tecnologias de apoyo
Integrar los procedimientos
Realizar el Proceso de i\ledicion
Tomar los datos
Analizar los datos y desanollar productos de infol111acion
Comunicar los resultados
EYalllar la Medicion
Eyaluar los prodllctos de infol111acion y el proceso de medicion
Identiticar las mejoras Eotenciales
Tabla 9.5. Actividades y tareas en ISO/lEe 15939
3. METRiCAS SOFTWARE
Tal y como se ha descrito en los apm1ados anteriores, el objetivo de todo proceso
de medicion es recopilar indicadores cuantitativos sobre entidades software. siendo una
entidad software to do elemento software sobre el que se puede aplicar un proceso de
medici6n y que estan caracterizadas por una serie de atributos (tamailo, tiempo, etc .. ).
Para realizar Ia medicion es necesmio identificar'tanto las entidades como los atributos a
medir. es decir. no se puede medir una entidad 0 un atributo de fonna aislada. como por
ejemplo medir un programa 0 medir el tamano. sino que se tienen que medir de fonna
conjunta. especificando que 10 que se qui ere medir es el tamano de un programa
(Morasca. 2001).
Con todo ello, para el estudio de la medicion del software hay que estudiar las
entidades que pueden ser objeto de medicion as! como los atributos caracteristicos de
dichas entidades. En este apartado se aporta una vision general sobre el campo de las
metric as software.
CAPiTCLO 9: l-.lEDICIO:--: DE SISTE\,lAS DE f:\:FORMACIO;-'; 237
De acuerdo a modelos de evaluacion y mejora como ISO 15504, CMM, 0 CMMI.
a la hora de incrementar el nivel de madurez de una organizacion hay que establecer una
base cuantitativa que de menor a mayor grado de madmez esta enfocada sobre:
o Medicion del Proyecto, basado en la gestion de proyectos.
o Medicion del Producto. centrado en su calidad y aspectos tecnicos.
o Medicion del Proceso, bas ado en el estudio y control de la capacidad de los
procesos, as! como en la gestion de los cambios en el proceso.
La relacion entre las metricas de proceso, proyecto y producto se muestra en la
figura 9.14. Como se puede observar en dicha figura, el proceso software constituye la
base a partir de la cual se realiza el trabajo denh'o de una organizacion. Dichos procesos se
aplican en la practica en fonna de proyectos. Como resultado de la ejecucion de proyectos
concretos se utilizan recursos y se obtienen productos. Por 10 tanto, para establecer un
marco de medici6n denh'o de una organizacion es necesario definir, recoger y analizar
metIicas sobre el proceso, el proyecto y recursos asociados as! como el producto
software, A continuaci6n se da una vision general sobre las metlicas de estos tres tipos de
entidades software.
Metricas de
Producto
Metricas de Proceso
Metricas de
Producto
Figura 9.14. Tipos de Entidades de :vIedici6n del Software
3.1. Medici6n del Proceso
La medicion del proceso implica las medici ones de las actividades relacionadas con
el software siendo algunos de sus atributos tipicos el esfuerzo. el coste y los defectos
enconh'ados (Fenton y Pfleeger, 1997).
238 CAUDAD DE SISTE?vlAS INFOIUv1A TICOS
De acuerdo a Pressman (2002) las metric as del proceso de software se utilizan para
prop6sitos estrategicos y en muchas propuestas, la medici6n del proceso se realiza
extrayendo las caracteristicas de tareas especificas de la ingenieria de software y
obteniendo como resultados metlicas sobre los en'ores detectados antes de la entrega del
software, defectos detectados e infol111ados por los usuarios finales, productos de trabajo
entregados, el esfuerzo humano y tiempo consumido, ajuste con la planificaci6n, etc. Por
ello, en la bibliografia, el enfoque de medici6n del proceso se ha centrado en recopilar una
selie de meuicas de todos los proyectos y durante un largo peliodo de tiempo con el
objetivo es proporcionar indicadores que lleven a mejoras de los procesos software a lar'go
plazo. En este senti do un area clave de investigaci6n es el control estadistico de procesos
(Florac y Carleton, 1999).
Otro posible enfoque de l11edici6n del proceso es a nivel conceptual, ya que es
posible que la complejidad u oU'as caracteristicas de calidad del modelo puedan afectar a
su ejecuci6n (enactment) y por consiguiente a la calidad de los productos finales
obtenidos. En este aspecto se pueden encontrar algunos estudios de para evaluar la
mantenibilidad de los modelos de procesos software (Garcia, 2004; Canfora et al., 2005).
3.2. Medici6n del Proyecto
La medici6n del proyecto y sus recursos asociados constituye el elemento
principal sobre el que se basa el estudio de las l11etlicas del proceso software. Cuando se
mide el proyecto el objetivo fundamental que se pretende es el de reducir el coste total del
proyecto, y el tiempo de desarTollo del mismo. Los indicadores de proyecto penniten al
administrador de software (Pressman, 2002):
Evaluar el estado del proyecto en curso.
Realizar un seguimiento de los liesgos potenciales.
Detectar las areas de problemas antes de que se conviertan en "criticas".
Ajustar el flujo y las tareas de uabajo.
Evaluar la habilidad del equipo del proyecto en controlar la calidad de los
productos de trabajo de la ingenieria del software.
En relaci6n a las metricas de proceso, las mediciones del proyecto de software
son tacticas, es decir, las metric as de proyectos y los indicadores derivados de ellos son
utilizados por un adminisu'ador de proyectos y por un equipo de software para adaptar el
flujo de u'abajo del proyecto y las actividades tecnicas.
El primer tipo de meuicas de proyectos software pueden ser obtenidas durante la
fase de estimaci6n. Las metricas recopiladas de proyectos anteriores se utilizan como la
base a partir de la cual se realizan las estimaciones del esfuerzo y del tiempo necesario
para el proyecto actual. A medida que avanza un proyecto, las metric as del esfuerzo y del
!': RA-MA CAPITULO 9: MEDICION DE SISTEMAS DE INFORivLA.CION 239
tiempo consumido se comparan con las estimaciones originales (y la planificacion del
proyecto). EI administrador de proyectos utiliza estos datos para supervisar y controlar el
avance. Para la estimacion del tamai'io del software cabe destacar la metrica de "Punta
FZlI1cion" (vease apartado 3.3.4) mientras que para la estimacion de costes de un proyecto
caben destacar los modelos COCOMO (COnstmctive COst MOdel) creado por Larry
BoelU11 en 1981 y su posterior refinamiento en la version actualmente en vIgor
COCOMO II.
En relacion a la estimacion de proyectos software existen model os como el de
Putnam y Myers (1992) en el que se desarrollan una ecuacion basica del software
expresada como:
Producto = Productividad * Esfuerzo * Tiempo,
donde "Prodllcta" representa la funcionalidad expresada en tamano, "Esfiterza" el
esfuerzo total del personal del proyecto para desarrollar el producto, "Tiempo" es la
duracion del proyecto, y la "Prodllctividad' depende de divers os factores que se pueden
clasificar en factores de producto (como su dificultad tecnica en funcion de aspectos como
restricciones hardware, complejidad algoritmica, complejidad logica, complejidad de
gestion, estabilidad de la plataforma) y de proceso (dependiente de las herramientas y
metodos us ados as! como del perfil del personal utilizado).
La anterior ecuacion fue posteriol1nente ajustada en base al aniilisis de resultados
historicos de una gran base de datos de proyectos, quedando:
Tamafio Producto = Indice de Productividad * Esfuerzo
a
* Tiempob.,
siendo a = 113 y b=4/3, el "Tamaiia" igual al numero de lineas de codigo fuente (nuevas
y modificadas pero sin considerar espacios en blanco y comentarios), y esfuerzo y
tiempo representan los mlos de esfuerzo y duracion de todas las fases del proyecto.
Otro de los elementos clave a mediI' a nivel de proyectos son sus recursos, que son
entre otros, el personal implicado, las infi:aestructuras. hardware y software, etc.
Una metlica muy utilizada es la productividad del personal, que se obtiene
dividiendo el tamano pOl' el esfuerzo. Esto implica dividir una metlica de producto pOI'
una metrica de proceso para obtener una metlica de recurso. En general se considera la
productividad como la division de la salida poria entrada. En Ingenieria del Software es
habitual indicar la entl'ada como el esfuerzo en personas mes, y la salida como el numero
de lineas de codigo. Al utilizar lineas de codigo como metlica de tammlo existen algunas
dificultades sobre to do para comparar distintos proyectos en los que se utilizan otros
lenguajes 0 entomos de programacion.
2,)0 CALlD.-\D DE SISTE\IAS I,\FOR:\L'\ TICOS 1': R.-\-\L-\
La metric a anterior solo mide la productividad del personal durante la
implementacion. Autores como Fenton and Pfleeger (1997) sugieren utilizar otras
metric as de productividad ya que la productividad del personal no considera la calidad del
codigo obtenido.
Otros recursos relevantes a considerar son los equipos de trabajo y las hen-amientas
(Fenton y Pfleeger, 1997). La productividad de los miembros del equipo de trabajo
depende de muchos factores, como par ejemplo la estructura del equipo. las helTamientas
y los metodos utilizados. Por otro lado tambien se considera la experiencia como un factor
importante de productividad, aunque es dificil de medir. Tambien es impOltante
considerar de fonna separada ia expeIiencia de los individuos y la experiencia del equipo,
ya que aunque los integrantes de un equipo puedan tener buena experiencia. el equipo
puede que no funcione bien y la productividad sea baja. En general la experiencia
individual se puede mediI' con escalas ordinales pero es importante considerar que la
expeIiencia se actualiza con mucha frecuencia. En relacion a las hen-amientas, es
importante establecer su relacion con otras variables del proyecto como la eficacia de las
hen-amientas en tel111inos de la calidad obtenida, tiempo de entrega y la productividad del
personal que las utilizo. De hecho los modelos de estimacion consideran el uso de las
hen-amientas a la hora de estimar el tamafio 0 coste de desan-ollo de software.
Tal y como indica Pressman (2002), otras metric as de proyectos pueden ser
obtenidas una vez que comienza el desaITOllo del producto propiamente dicho y en este
aspecto es impOltante realizar un seguimiento de los en-ores detectados durante todas las
tare as de ingenieria del software. A medida que el software va evolucionando desde la
especificacion al disefio. se recopilan las metricas tecnicas para evaluar la calidad del
disei'io y para proporcionar indicadores que influirim en el enfoque a seguir para la
generacion de codigo y para las pruebas. El uso de metricas para los proyectos tiene dos
caracteristicas fundamentales (McDennid. 1991): estas metlicas se utilizan para minimizar
la planificacion de desan-ollo guiando los ajustes necesarios que eviten retrasos y atemien
problemas y riesgos potenciales; y se utilizan para evaluar la calidad de los productos en
el momenta actual con el fin de poder mejorarlos.
3.3. Medici6n del Producto
La medicion del producto software esta centrada en evaluar la calidad de los
entregables. Los productos del software son las salidas del proceso de produccion del
sofuvare, que incluyen todos los aItefactos entregados 0 documentos que son productos
durante el ciclo de vida del sofuvare. En la literatura existe una gran diversidad de
propuestas relacionadas con la medici on del producto. A continuacion se resumen a modo
de ejemplo algunas propuestas representativas de metIicas de producto.
(". R.>\-\IA C>\PiTCLO 9: \IEDICIO:\ DE SISTE\IAS DE Ii\'FOR.vIACIO:\ 2-11
3.3.1. lVlETRICAS DE CODIGO FUENTE
las metlicas de codigo fuente mas imp0l1antes son Lineas de Codigo y longitud
Total.
Lineas de cOdigo (LOC, Lines of Code), es la metrica mas popular a nivel de
codigo de programa. Sin embargo. a pesar de ser ampliamente conocida y utilizada, el
problema de esta metric a ha sido la falta de consenso existente a la hora de definir que es
una linea de codigo. ya que esta definicion variara en n.mci6n de las necesidades 0 de la
persona que la aplique. Por ejemplo. seglm el objetivo perseguido por la medicion sera
importante contar las lineas de comentario como line as de codigo mientras que en otras
ocasiones sera imprescindible no contar los comentarios como lineas de codigo. Por ello,
para aplicar esta metrica es fundamental establecer claramente que elementos hay que
considerar como linea de c6digo y como deben contarse. En particular es necesario
clarificar elementos como las lineas en blanco. los comentarios. las declaraciones de datos
y las lineas que contienen instrucciones separadas. En general se recomienda separar en la
medicion de la longitud las lineas de codigo y los comentarios, quedando (Fenton y
Pfleeger. 1997):
Se define Longitud Total (L T) como la suma del Nlll11ero de Lineas de Codigo
que no son comentarios (NClOC) mas e1 nlll11ero de lineas de codigo que son
comentarios (ClOC).
A par1ir de la metrica anterior se pueden definir otras metric as derivadas titiles.
como 1a densidad de comentarios (ClOC/lOC). que puede dar una idea sobre e1 punto
hasta e1 cual esta documentado e1 codigo.
Para facilitar 1a obtencion e interpretacion de la metric a lOC, el SEI ha definido
listas de comprobacion (Park, 1992) en las que se indica que como linea de cOdigo se debe
considerar todo el codigo ejecutable, declaraciones no ejecutables y directivas de
compilacion. pero no las lineas en blanco. Tambien se debe considerar en la medici on la
fon11a en la que el codigo ha sido producido (programando. usando generadores de codigo
n.lente, copiado 0 reutilizado sin realizar cambi@s. modificado 0 conver1ido con
traductores automiiticos).
Otras metricas definidas para evaluar la longitud de un programa son:
e Numero de sentencias de programacion. Presenta el mlsmo tipo de
problemas de ambigiiedad que la metrica lOC.
e SIZEl. Definida como el nll111ero de puntos y coma (li y Henry, 1993). Se
creo intentando paliar el problema de ambigiiedad de definicion de las lineas de
codigo. Como se puede deducir esta metrica solo es aplicable a programas que
utilicen este simbolo para separar un as sentencias de otras.
2.+2 CAUDAD DE SISTEMAS INFOIUvL.\ TICOS : R,\-;vIA
e Metricas de la Ciencia del Software (Soff1mre Science). Propuestas por
Halstead (1977) para intentar independizar las metric as del lenguaje de
programaci6n. Se basan en los tokens (unidades sintacticas elementales
distinguibles pOl' el compilador) y que pueden ser divididos en operadores y
operandos. Las metricas son la longitud de un programa, el volumen de un
programa y el esfuerzo de implementaci6n de un programa. Las metricas base
definidas para estos elementos son:
o Ill: el nllmero de operadores diferentes que aparecen en el programa
o 112: el numero de operandos diferentes que aparecen en el programa
o N1: el nlllnero total de veces que aparece el operador
o N2: el nlunero total de veces que aparece el operando
A partir de las metri.cas base Halstead define una seli.e de metri.cas deli.vadas que
penni ten evaluar (Pressman, 2002): la longirud global del programa; el volumen
minima potencial para un algOli.trno; el volumen real (nlllnero de bits requeridos
para especificar un programa); el nivel del programa (una medida de la
complejidad del software); nivel del lenguaje (una constante para un lenguaje
dado); y otr'as caracteristicas tales como esfuerzo de desalTollo, tiempo de
desalTollo e incluso el nlunero esperado de fallos en el software. Como metri.ca mas
representativa para evaluar la longirud Halstead prop one la metli.ca N, que es la
suma de N1 y N2. Del resto de metri.cas cabe destacar:
e Volumen de un programa: V = N . log2 (11), siendo III
e Longitud global del programa: N' = III . log2 (Ill) + log2
Fenton y Pfleeger (1997) consideran que aunque la propuesta de Halstead ha
tenido un gran imp acto en la medici6n software, constitrlye un ejemplo de
medici6n inadecuada, al proporcionar algunas metri.cas con definiciones confusas
10 que puede provocar diversas interpretaciones de las mismas.
3.3.2. METRICAS DE COMPLEJIDAD .
Entre las metricas de complejidad destacan las siguientes:
e Complejidad Ciclomatica (V(G)), propuesta par McCabe (1976), para
evaluar la complejidad de un programa. Esta metri.ca es, ademas de la primera
metri.ca conocida, una de las mas estudiadas y utilizadas. La metrica V(G) esta
basada en la teoria de grafos y mide el numero de caminos linealmente
independientes de un programa, que puede representarse mediante un grafo de
flujo de contro!' Esta metri.ca puede calcularse de la siguiente fonna:
V(G)=A-N+2
C-\piTULO 9: MEDICION DE SISTEMAS DE 2.+3
siendo A el numero de arcos del grafo y N el nlllllero de nodos.
A mayor valor de la metrica V(O) mayor complejidad del programa.
McCabe indico tambien que un valor razonable de esta metrica para que un
modulo fuera mantenible debia ser menor de diez. Diversos estudios empiricos
han encontrado una fuelte cone lac ion entre la metrica de McCabe y el numero
de enores que existen en el codigo fuente, as! como el tiempo requelido para
encontr'ar y conegir dichos enores. Otr-a de las aplicaciones de esta metric a ha
sido a nivel de pmebas del software ya que puede utilizarse para predecir la
cantidad de esfuerzo necesario para probar un modulo 0 programa.
o Fan-in (concentracion) y fan-out (expansion). Propuestas por Henry y
Kafura (1981). Ambas metr-icas trabajan sobre la estr1.1ctura de un modulo
representada como un arbol 0 grafo de llamadas entre modulos_ Eljan-in de un
modulo m es el numero de flujos que tenninan en m mientr'as que eljan-ollt es
el numero de flujos que salen de m.
o Complejidad de un modulo, que esta basada en las dos metricas anteriores y
creada tambien pOl' Henry y Kafura (1981) siendo su definicion:
MHK = longitud (i) . [fan-in (i) + fan-out(i)]2,
donde la longitud (i) es el numero de sentencias en lenguaje de programacion
en el modulo i.
Henry y Kafhra amplian la definicion de concentracion y expansion no
s610 como el nllmero de conexi ones de control del modulo (llamadas al
modulo), sino tambien el nlllllero de estmcturas de datos del que el modulo i
relme (concentracion) 0 actualiza (expansion) datos.
3.3.3. METRICAS PARA SISTEIVlAS 00
El software desan-ollado siguiendo el paradigma 00 difiere en importante medida
del desanollado utilizando enfoques tradicionales. Ello planteo la necesidad de definir
nuevas metricas adaptadas a las caracteristicas parti.culares de este paradigma, de las
cuales se presentan a continuacion algtUlas propuestas representativas.
o Conjunto de Metric as MOOSE, compuesto por las siguientes seis metricas
propuestas por Chidamber y Kemerer (1994):
o Metodos ponderados por clase (WMC, 'Weighted Methods per Class),
que mide la complejidad de una c1ase. Si todos los metodos son
igualmente complejos, entonces WMC es igual al numero de metodos
definidos en una c1ase. Sea la c1ase C que tiene los metodos j'vh ...... , Ml1
siendo su complejidad respectiva cJ, .... , Cn, es posible definir la fonnula:
24-1 CAUDAD DE SISTDIAS TICOS ' R.Vv!A
o Profundidad del l<\rbol de Herencia de una Clase, (DIT. Depth ot"
inheritance Tree). La metric a DIT mide el maximo nivel en la jerarquia
de herencia. Se trata de la cuenta directa de los niveles de la jerarquia de
herencia. considerando que en elnivel cero de la jerarquia se encuentra la
clase raiz. DIT se considera como una metric a del nlunero de clases
antecesoras que una clase podIia potencialmente afectar, debido a que
cuanto mayor sea elnivel de profundidad de herencia de una clase mayor
es el nl1l11ero de metodos y atributos que hereda de otras clases.
o Numero de Hijos (NOC, Number of Children). NOC es el nllmero de
subclases subordinadas a una clase en la jerarquia, es decir, la cantidad
de subclases que peltenecen a una clase. Seglll1 Chidamber y Kemerer
(1994), NOC es un indicador del nivel de reutilizacion. de la posibilidad
de hacer creado abstracciones elToneas, y delnivel de pruebas requerido.
o Acoplamiento entre Objetos (CBO. COZlpiing Between La
metrica CBO indica para una clase el nlunero de otras clases con las que
esta acoplada. Se considera que un objeto esta acoplado a otro cuando
actlJa sobre ese otro objeto, por ejemplo cuando un metodo de un objeto
utiliza un metodo de otro objeto. Esta metIica se considera lltil para
predecir el esfherzo necesario para el mantenimiento y las pruebas.
o Respuesta de una clase (RFC, Response For a Class), RFC indica el
nlll11ero de metodos que pueden ser ejecutados potencialmente como
respuesta a un mensaje recibido por un objeto de esa clase. RFC pOI' 10
tanto se ca1cula contando las oCLllTencias de llamadas a otras clases de
una clase particular.
o Falta de cohesion en los metodos (LCOM. Lack of Cohesion in
Methods). LCOM establece en que medida los metodos hacen referencia
a atIibutos. Se ca1cula como el nllmero de pares de umciones sin
variables compartidas de instancia menos el numero de pares de
umciones con valiables de instancia compartidas. LCOM es una metrica
de la cohesion de una clase en base al nllmero de atributos comunes
usados por diferentes metodos. Un valor alto en LCOM implica falta de
cohesion. es decir, escasa similitud entre los metodos siendo siempre
deseable un alto grado de cohesion en los metodos de una clase.
e Metricas MOOD (Brito e Abreu y Calapuca. 1994). EI objetivo de las metric as
MOOD es medir los plincipales mecanismos del paradigma 00, tales como
encapsulamiento, herencia, polimorfismo y paso de mensajes, asi como polimorfismo
y su consecuente int1uencia sobre la cali dad del software y la productividad en el
desalTollo. Las metI-icas MOOD se pueden utilizar en las fases de disei'io y se
definieron para ser aplicadas a nivel de diagrama de clases (vease tabla 9.6).
e Metricas de Lorenz y Kidd (1994). Lorenz y Kidd (1994) propusieron un conjunto
de metricas llamadas '"metricas de diseiio'. que se refieren a caracteristicas estaticas
RA-\!A C\PiTCLO 9: \!EDICIO?\ DE SISTEMAS DE I0:FOR.c'vIACIOl\' 2.+5
del disefio de un producto software. Estos autores clasificaron las metncas en:
metricas de tamai'io, metric as de herencia y metricas de caracteristicas intemas de las
clases. En la tabla 9.7 se muestran aquellas metricas que pueden aplicarse a un disefio
de alto nive!.
NOMBRE
I
""
DEFINICIOr;
i
EI Factor de Ocultamiento de los Metodos (,He/ed Hiding Factor) mide la proporcion
entre los metodos ddinidos como protegidos 0 prh'ados y el nt1!nero total de J11i'!todos.
\IHF
MHF se propone como una medida de encapsulacion. cantidad relativa de infoTInacion
oculta.
EI Factor de Ocultamiento de los Atributos (.-!.ltribwe Hiding FaclOr) se define como el
cociente entre la suma de las invisibilidades de todos los atributos detinidos en todas las
AHF clases y el nt1!nero total de atributos definidos en el sistema considerado. La invisibilidad
de un atributo es el porcentaje del total de clases desde las cuales los atributos son
im"isibles. AHF se definio como una medida de encapsulacion.
EI Factor de Herencia de los Metodos (Method inheritance Factor) se define como el
cociente entre la suma de los metodos heredados en todas las clases del sistema
\IlF considerado y el numero total de metodos existentes (tanto los detinidos localmente
como los heredados) en todas las clases. MIF se define como una medida de herencia. y
por 10 tanto como una medida del nivel de reutilizacion.
EI Factor de Herencia de los Atributos (Auribllle inheritance FaclOr) se define como el
cociente entre In suma de los atributos heredados ell todas las clases del sistema
AIF considerado y d numero total de atlibutos existentes (tanto los detinidos localmente
como los heredados) en todas las clases. Al igual que :vlIF. AIF se considera como un
medio para expresar la capacidad de reutilizacion en un sistema.
EI Factor de Polimorfismo FaclOr) se define como el cociente entre el
PF
ntllnero actual de posibles diferentes situaciones de polimortismo. y cl nLlmero maximo
de posibks situaciones distintas de polimortismo para la clase Ci. PF es una medida del
polimodismo y una medida indirecta de la asociacion dinamica en un sistema.
Tabla 9.6. Metricas MOOD que se pueden aplicar a la fase de diseiio
En resumen. se consideran las relaciones de inclusi6n y extensi6n y las relaciones
de control y de dependencia de datos. La intuici6n aconseja que. cuantas lmis relaciones
haya en el modelo. 111<1S dificil sera hacer cualquier cambio. Otro factor que influye en la
modificabilidad de los casos de usa es el tipo de caSG de uso. Simplificando la idea, si un
caso tiene yarios objetivos (tipos para Saeki), es mas susceptible de cambiar que si tiene
s610 un objetiyo. Para aproximar la modificabilidad. se definen las metric as NOD
(Numero de Dependencias) y NUCT (NCul1ero de Tipos de Casos de Uso). El objetivo
alcanzado por el autor consisti6 en un indicador (0::; MODIFIABILITY::; 1) que
revelaba el grado de modificabi-lidad de un modele de casos de uso. Tambien existen
otras propuestas especificas para casos de usa, como pOI' ejemplo las propuestas de Feldt
(2000). Henderson-Sellers et af. (2002) y Bemardez et af. (2004). Un estudio mas
prof undo sobre metricas para casos de uso y diagramas de casos de usa puede encontrarse
en Genero et al. (2004).
I Metricas para UML. En la bibliogratla se pueden encontrar diversas
propuestas de metricas para los distintos tipos de diagramas UML:
DE SISTEvlAS INFOR.;\L.I. TIeos s RA-\,L-\
o Casos de Uso. Existen pocas propuestas de metricas especificas para
diagramas de casos de uso, tales como: Marchesi (1998) que propuso un
conjunto de metricas de complejidad para diagramas de casos de uso
consistente en el nl1l11ero de casos de uso (N cc ), el nllll1ero de actores
TIPO
\IETRIC-\S DE
TA:\IA:\O
\IETRlC.-\S DE
HERE"CIA
\IETRICAS DE
CAR-\CTERisTIc.-\s
I"TER"AS DE LAS
CLASES
( Na ) Y el nllll1ero de relaciones de inclusi6n Y extensi6n. Basandose en
estas metricas tambien defini6 un indicador global de la complejidad del
sistema; Saeki (2003) se definen un conjunto de metricas para diagramas
de casos de uso, con el fin de obtener un indicador de modificabilidad.
La idea basica de estas metlicas que es que si se necesita cambiar un caso
de uso, probablemente habra que cambiar otros casos de uso: aquellos
que tengan una relaci6n con el caso de uso que se cambi6 originalmente.
i
NmIBRE DEFE\ICIO:-;
EI Nllll1ero de Metodos de Instancia Pl1blicos de una clase es el
PI:\I nllll1erO total de metodos Pl1blicos de instancias. Los metodos Pl1blicos
son aquellos que estan disponibles como servicios para otras clases.
EI Nl1111ero de de Instancia es la suma de todos los metodos
NI:\I de una clase. considerando tanto los metodos Pl1blicos como los
protegidos y pri\"ados"
EI 0."l1111ero de Variables de Instancia es el nllll1erO total de variables a
NIY nivel de instancia que tiene una clase. considerando las \"ariables
privadas y protegidas disponibles en una clase.
EIl\lunero de i\letodos de Clase es el nlllnero total de l11<?todos a niwl
NOI de c1ase. !lor ejemplo. aquellos metodos que son globales a todas las
instancias que tiene una clase.
N\,'
EI 0."llmero de variables de Clase es elnllll1erO total de variables a
nivel de clase que tiene una clase.
N\IO
EI 0."llll1ero dc Metodos Sobrecargados es el nl1111ero tOlal de l11i?todos
sobrecargados por una subclase.
N\II
EIl\llmero de \Ietodos Heredados es elnl1mero total de metodos que
una clase hereda.
EI 0."llmero de Afiadidos es elnlllnero total de metodos que
N\IA
se detlnen en una subclase. Esta metrica se dctlnio para mediI' la
cali dad del uso de la herencia. ya que examina la relacion de herencia
entre subclases y superclases.
EI indice de Especializacion para cada c1ase se detlne asi:
.\zimerode.\/elodosSohrees('}"iloS *
SIX .\"zimero TOlalDe.\/elOdos
Esta metrica mide hasta que punto una subclase redetlne el
comportamiento de una sllperclase.
EI Promedio de Parametros por Metodo se define asi:
.\"zimero Tola IDeP([nimel rosPod/clO do
APP:\-I
.\"zimero TOia IDe.\IelOdos
Tabla 9.7. \Ietricas de Lorenz y Kidd (1994)
I
I
It-\-MA C.-\PiTCLO 9: ? .. [EDICrO" DE SrSTE?v[AS DE 247
o Diagramas de Clases UML. Genero et al. (2004) definieron un
conjunto de metric as para la complejidad eShlJctural de diagramas de
clase de UML debido al uso de relaciones de UML, tales como:
asociaciones, generalizaciones, dependencias y agregaciones (vease tabla
9.8). Los autores suponen que estas metticas pueden ser buenos
indicadores de las caractetisticas de mantenibilidad de un diagrama de
clases de UML. Bansiya et al. (1999; 2002) tambien definieron l11etticas
a nivel de clase para evaluar propiedades de diseno como la
encapsulal11iento, el acoplal11iento, la cohesi6n, la c0l11posici6n y la
herencia.
METRlCAS
I
DEFJ;,\IClO;,\
:\Assoc
I
NllIl1CrO total de asociaciones.
:\AGG Nllll1ero total de relaciones de agregacion dentro de un diagrama de
clases (cada par todo-par1e de una relacion de agregacion).
:\DEP
I
Nllll1ero total de relaciones de dependencia.
:\GE:\
I
:\'llmero total de relaciones de generalizacion dentro de un diagrama de
clases (cada par padre-hijo de una relacion de generalizacion).
:\AGGH :\'llll1ero total de jerarquias de agregacion (estructuras todo-par1e) dentro
de un diagrama de clases.
:\GE:\H N llmero total de jerarquias de generalizacion dentro de un diagrama de
clases.
;\IAxDIT EI \'alor maximo de la metrica D1T (Depth olInheritallce Tree.
Profundidad del Arbol de Herencia) calculada para cada clase del
diagrama de clases, EI valor de D1T para una clase dentro de una
jerarquia de generalizacion es el camino mas largo desde la clase hasta la
raiz de la jerarquia.
;\L-\xHAGG EI \'alor m,iximo de la metrica HAgg calculada para cad a clase del
diagrama de clases. EI yalor de HAgg para una clase dentro de una
jerarquia de agregacion es el camino J11:is largo desde la clase hasta las
hojas,
Tabla 9.8. JUtric{[s para complejidad est1'1lctural de diagralllas de clases UJIL
o Diagramas de Estados. DeIT (1995) defini6 el nll111erO de estados y el
nll111erO de trallsiciones como metric as que miden la cOl11plejidad de los
diagramas de estados OMT (aunque tambien se pueden aplicar a lJTvIL).
Carbone et al. (2002) propusieron dos metricas: totSta(c), que representa
el Illl111ero total de estados para una clase y totActioll(c) que cuenta el
nll111ero total de acciones para una clase. Estas metric as son utilizadas
junto a otras para diagramas de clases, diagramas de casos de uso, etc.,
para detenl1inar la complejidad total de un sistema 00. En cualquier
caso, ambas propuestas no han pasado mas alla de la definici6n.
Un trabajo mas completo es el propuesto por Miranda et al.
(2003). Con la hip6tesis de que el tamai'io y la complejidad estructural de
los diagramas de estados de UML puede influenciar su facilidad de
entendimiento (y por tanto su mantenibilidad). definieron un conjunto de
2.+8 CAUDAD DE SISTE\lAS I);"FORyL\ TICOS f R.-\-\lA
metric as para la complejidad estructural y el tamai'io de los diagramas de
estados de UML
Como metlicas de tamai'io se definieron: NEntr}A. Nllmero total
de acciones de entrada, es decir, las acciones que se realizan cada vez
. que se entra en un estado; NExitd, nll111ero total de acciones de salida, es
decir, las acciones que se realizan cada vez que se abandona un estado:
NA, nll111ero total de actividade? (do/activity); NSS, nllmero total de
estados, considerando tambien los estados simples dentro de los estados
compuestos: NCS. nl1mero total de estados compuestos: NE, l1l1mero
total de eventos; NC. nllmero total de condiciones de guarda. Como
metricas de complejidad estructural definieron: NT, l1l1mero total de
transiciones, considerando las transiciones comunes (los estados origen y
destino son diferentes), las transiciones inicial y finaL las auto-
transiciones (los estados origen y destino son el mismo) y las transiciones
intemas (transiciones denu'o de un estado que responden a un evento
pero sin dejar el estado); CC (Nllmero Ciclomatico de McCabe), definido
como INSS-NTI+2.
La validez teorica de las metricas propuestas se demostro a
traves de la validacion siguiendo el marco de trabajo de Briand et a/.
(1996), concluyendo que las metricas NA NSS, NCS, NE. NEntryA.
}\rExitA y NG son de tamafio; y las metlicas NT y CC son de
complejidad. Ademas, su validacion tambien aplicando el marco de
u'abajo DISTANCE (Poels y Dedene, 2002) garantiza que las metricas
puedan usarse como inSU1tmentos de medicion en esc ala de ratio. Su
hipotesis fue cOlToborada empiricamente en cierta medida a traves de un
experimento controlado y su replica. Como resultado del trabajo de
expelimentacion, concluyeron que las metIicas NA NSS, NG y NT
parecen estar altamente cOlTelacionadas con el tiempo de entendimiento
de los diagramas de estados de UML
o Expresiones OCL O ~ i e c t Constraint Language). La lmica propuesta
hasta la fecha de metricas para. expresiones OCL es la realizada por
Reynoso et a/. (2004). quienes tomaron como hipotesis que las
propiedades estructurales de una expresion OCL tienen un impOltante
impacto en la complejidad cognitiva de los modeladores. ya que cuando
los desalTolladores tratan de comprender una expresion OCL
(considerada en este estudio como una abstraccion mental simple: un
"chunk") aplican tecnicas cognitivas. como el "chunking" y el "tracing".
Estas tecnicas se aplican conCUlTente y sinergeticamente en resolucion de
problemas y son parte del Modelo de Complejidad Cognitiva (CMM)
definido por Cant et a/. (1992: 1994). Este modelo proporciona una
teoria cognitiva general de la complejidad del sofuvare relacionada con
el impacto de la estmctura sobre la comprension. EI "c!zlll1king" implica
el reconocimiento de un conjunto de infolll1acion de declaracion y
c R.-\-:'IA CAPiTULO 9: :'IEDICIO;-,; DE SISTEMAS DE INFOR:vlACIO;-'; 249
extraccion, que se recuerda como un "chunk", mientras que el "tracing"
implica explorar. hacia adelante 0 hacia atnis, para identificar los
"chunks". El "tracing" se ha observado como una actividad fundamental
en la comprension del software. Por esa razon, estos antores han definido
metric as relacionadas con estas tecnicas cognitivas, agrupandolas en tres
gr'andes grl.lpOS de conceptos de OCL (vease tabla 9.9).
Tic'\'IC'I. I CO:\W,\,ES DEL E.lnrPLos DE CO,",CEPTOS OCL RELACIO'\'ADOS
COG:-IITn'A GRDPO DE CO,\,CEPTOS DCL CO'"' CADA GRUPO
Conceptos OCL que penniten que l\avegacion y operacion de colecciones.
una expresion uti lice propiedades Mensajeria. parametros cuyos tipos son
Tracing que pertenezcan a otras clases 0 clasificadores definidos en el diagrama de clases.
interfaces. diferentes al tipo de la etc.
instancia contexmal.
ChlllZkillg
SC[\'icios OCL relacionados con
I
Ddiniciones de vmiables a de expresiones
GI1IPO I
el propio lengllaje, let. Expresiones condicionales It: \'ariables
iterativas predetinidas. literales. etc,
Conceptos OCL relacionados con Rcferencia a atributos 1I operadores de la instancia
Chzll1king la instancia contextual y algllna de contextual. valores posttijos de by variables
Grupo 2 'us propiedadcs. ddinidas a de restriccioncs defInition.
etc.
Tabla 9.9. Grupos detinidos de conceptos Oel de acuerdo a tecnicas cognitivas
Aunque las expresiones OCL pueden anadirse a cualquier diagrama de UML.
Reynoso et al. (:200-1-) han comenzado la definicion de metricas para expresiones OCL que
puedan usarse en un diagr'ama de clases de UML. Algunos ejemplos de metr1cas
relacionadas con el "tracing" son (entre otras): Nlllnero de Relaciones Navegadas (NNR),
que cuenta el numero total de relaciones que se na\'egan en una expresion. Si una relacion
se navega dos veces. pOl' ejemplo usando propiedades diferentes de una clase 0 interfaz.
esta relacion se cuenta solamente una vez. Siempre que una clase asociacion se navegue,
consideraremos la asociacion a la que la clase asociacion \'a unida: Nzilllero de Atriblilos
referidos a tran?s de las .Vcnegaciolles (XLV), que cuenta el nlllnero total de atributos que
son referidos a traves de las navegaciones de una expresi6n: Nztlllero de Clases
Nm'egadas (NNC). que cuenta el nltmero total de clases. clases de asociacion 0 interfaces
a las que navega una expresion. Si una clase contiene una relacion reflexiva y una
expresion la navega. la clase se considerara solo una vez en la metrica, Ademas, como una
clase puede alcanzarse desde una clase/interfaz inicial navegando de fonna diferente (es
decir, siguiendo relaciones diferentes) debemos considerar esta situaci6n como un caso
especial: Si una c1ase se usa en dos (0 mas) navegaciones diferentes, la clase se cuenta
solo una vez.
Estas metricas tambien se validaron teoricamente usando el marco de Briand et
al. (1996). Por ejemplo, las metricas NNR, 1\1NC Y NAN se validaron como metric as de
acoplamiento basadas en la interaccion. La intuici6n dice que las metr1cas relacionadas
con el "tracing" podrian tener mas influencia en la facilidad de entendimiento y la
250 CAUDAD DE SISTEMAS J}..TfORJvlATICOS
modificabilidad de las expresiones OeL. Pero este hecho debe comprobarse a traves de
estudios empiricos. No hay ninguna prueba de su validaci6n empirica. Sin embargo, los
autores planean realizar un experimento controlado para validar algunas de las metricas
propuestas como indicadores de la facilidad de entendimiento y la modificabilidad de las
expresiones OCL.
En definitiva, los diagramas de clases UML han sido de los mas investigados
desde el punto de vista de la medici6n. En menor medida se han propuesto y validado
metricas para diagramas de caso de uso de UML, diagramas de estados de UML y, casi
ninguna para expresiones OCL. Otros modelos UML, que cubren aspectos dinamicos de
los sistemas 00, como los diagramas de secuencia, los diagramas de actividad, etc., no se
han tenido en cuenta (de momento) en el campo de la medici6n.
3.3.4. PUNTOS FUNCION
La metric a de puntos funci6n fue definida por Albrecht (1979) con el fin de
predecir el esfuerzo y el coste de desarrollo. Esta constituye una de las metric as mas
conocidas y utilizadas de la literatura.
Un punto de funci6n es una medida sintetica del tamano funcional de un sistema
independiente de la tecnologia y lenguaje de programaci6n utilizado para desarrollarlo. La
f6nnula general para calcular los puntos funci6n es:
PF = PFSA * FCT,
donde PFSA son los puntos ftmci6n sin ajustar y FCT es un factor de correcci6n tecnica.
Para calcular los puntos funci6n sin ajustar es necesario contar el numero de
elementos de cada uno de los siguientes tipos (que se pueden obtener a partir de la
especificaci6n del sistema):
iii Entradas Externas (entradas): cualquier entrada (pantalla, fonnulario,
cuadro de dialogo, control 0 mensaje) que tenga un fonnato lmico 0 un solo
procesamiento, a traves de la cual el' usuario u otro programa puede anadir,
borrar 0 cambiar datos.
iii Salidas extern as (salidas): cualquier salida (pantalla, infonne, grafico.
mensaje) que tenga un fonnato diferente 0 requiera un procesamiento diferente
a otros tipos de salida, generada para el usuario U otro programa.
iii Consultas externas (consuItas): combinaciones de entrada/salida en las que
cada entrada genera una salid simple e inmediata.
iii Archivos Iogicos internos (archivos): plincipales grupos 16gicos de datos de
usuarios 0 de control que estan controlados completamente por el programa
(una tabla de un SGBDR).
~ RA-MA CAPiTULO 9: MEDICION DE SISTEMAS DE INFORMACION 251
CI Archivos de interfaz externos (interfaces): cada uno de los grupos de datos
16gicos 0 infonnaci6n de control que entra 0 sale del programa.
Por ejemplo, si el DFD del sistema es el de la figura 9.15, el IlLunero de elementos
de cada tipo selia: Enh'adas 1; Salidas 3; Consultas= 1; Archivos = 1; Intelfaces = 1. EI
numero total selia 7.
Archivo Externo:
Entrada:
1. Documento que se ha de revisar
Salida:
---------- --------- ----------
1. Nombre del documento que se ha de
revisar
Usuario
Consulta:
1. l.Cuantas palabras
se lIevan procesadas?
1. Numero total de palabras revisadas
2. Numero total de errores detectados
3. Lista de palabras con errores ortograficos
Comprobador
Ortografico
Archivo Interno:
1. Diccionario
Figura 9.15. Ejemplo de DFD de un Sistema de Comprobacion Ortognifica
Cada uno de estos elementos se debe clasificar de acuerdo a su complejidad (alta,
baja 0 media). EI valor de PFSA se calcula como la suma de cada uno de los tipos de
elementos ponderada por su complejidad (peso).
15
PFSA= "LPesoi* Elementoi
i=l
En la tabla 9.10 se muestran los pesos a aplicar en funci6n de la complejidad de
cada tipo de elemento.
BAJA .MEDIA
_______ CmWLEJIDAD .
ELEME"'TO ....
.... El\'TRADASExTER'<AS .... 3 4 6
." S A L I J ~ S R'ITERt"'AS ... ' I 4 5 7
.. CONSllL TAsEX"TERt.'<AS 3 4 6
ARCHIVOS LOGICOS II'I'TIR"'OS 7 10 15
ARCHIVOS DE L'<TERF Ai R'X"rER",os 5 7 10
Tabla 9.10. Pesos de Complejidad de los PFSA
252 CAUDAD DE SISTE\!AS lPiFOR\L'\ TICOS
Para hacer menos subjetiva la valoraci6n de la complejidad, algunas tecnicas
incluyen tablas orientativas para cada tipo de nll1ciones de usuario. Por ejemplo, la tabla
de complejidad para las Entradas tiene en cuenta dos aspectos: nlunero de tipos de
elementos de datos incluidos, y nllll1ero de archivos 16gicos intemos referenciados (tabla
9.11 ).
Tabla 9.11. Complejidad de las Entradas
EI valor del factor de cOlTecci6n tecnica depende de catorce (14) factores de
complejidad que son valorados de fonna subjetiva asignimdoles un valor de cera (0) a
cinco (5). Estos factores son:
1. Comunicaciones de datos: concemiente a la transmisi6n de datos 0 infonnaci6n
de control. enviados 0 recibidos mediante alglll1 sistema de comunicaciones.
! Procesamiento distribuido: concemiente a si una aplicaci6n es monolitica y se
ejecuta en un lmico procesador. 0 si la aplicaci6n consiste en c6digo
independiente ejecutandose en procesadores distintos y persiguiendo un fin
comtll1.
3. Objetivos de rendimiento: tendnin una puntuaci6n de 0 si el rendimiento de la
aplicaci6n no es relevante. 0 por el contrario la puntuaci6n sera 5 si es un factor
critico.
4. Contiguracion de uso intensivo: indica si el sistema se va a implantar en un
entomo operativo que sera utilizado de manera intensa.
5. Tasas de transacciones nipidas: tendril una puntuaci6n de 5 si el volumen de
transacciones es suficientemente alto como para requerir un esnlerzo de
desalTo!lo especial para conseguir la productividad deseada.
6. Entrada de datos en linea: tendrii una puntuaci6n de 0 si son interactivas menos
del 15 por ciento de las transacciones, y tendra una puntuaci6n de 5 si mas del 50
por ciento de las transacciones son interactivas.
7. Amigabilidad en el disefio: detemlina si las entradas de datos interactivas
requieren que las transacciones de entrada se !leven a cabo sobre mtlltiples
panta!las 0 variadas operaciones.
RA.-MA cAPin;LO 9: DE SISTE1>!AS DE [l\FORMACION 253
8. Actualizacion de datos en linea: tendni puntuacion maxIma si las
actualizaciones en linea son obligatOli[.s y especialmente dificultosas, quiza
debido a la necesidad de realizar copias de seguridad, 0 de proteger los datos
contra cambios accidentales.
9. Procesamiento complejo: se puntuara con 5 si se requieren gran cantidad de
decisiones logicas, complicados procedimientos matematicos 0 dificil manejo de
excepclOnes.
10. Reusabilidad: indica si gran parte de la fUl1cionalidad del proyecto, esta pens ada
para un uso intensivo por otras aplicaciones.
11. Facilidad de instalacion: un valor de 5 denota que la instalacion del sistema es
tan importante que requiere un esfuerzo especial para desaIToliar el software
necesmio para realizarla.
12. Facilidad operacional: un valor de 5 indica que el sistema realiza pccas
operaciones.
13. Adaptabilidad: una puntuacion maxima indicaria que e1 sistema se ha disei'iado
para sopOliar mtlltiples instalaciones en diferentes entornos y organizaciones.
14. Versatilidad: detel111ina si la aplicacion se ha realizado para facilitar los cambios
y para ser utilizada por el usuario.
El valor del factor de cOlTeccion tecnica se obtiene:
FeT = 0,65+0.01 ;'SUMA(GI),
siendo SUMA(GI) la suma de los grados de influencia de 14 factores que intluyen en la
complejidad del proceso.
Una vez que se conocen los puntos funciol)., ya se tiene un indicador sobre el
tamano del soft\vare en la fase de analisis. que puede ser utilizado para realizar
estimaciones de esfuerzo. El valor de puntos funcion puede ser traducido a otras metric as
como por ejemplo a LOC. en cuyo caso se utilizan tab las de equivalencia en la que se
tiene en cuenta el tipo de lenguaje de programacion.
Otra metrica relevante relacionada con los puntos funcion es la de Objetos
Funcion que es solo aplicable a sistemas 00. Para calcular esta metric a en primer lugar se
deben contar el nLlmero de pantallas. infol111eS y componentes de tercera generacion que
son 0 seran parte de la aplicacion. Cada pantalla 0 infol1ne se c1asifica como simple.
medio 0 dificil, mientras que los componentes de tercera generacion se consideran todos
con el mismo peso. La suma ponderada por complejidad de todos estos elementos pel111ite
254 CAUDAD DE SISTE!'vL"'S INFORr\'LS, TICOS
obtener el numero de puntos de objetos simples. Para calcular los puntos de objetos
nuevos se tiene en cuenta un factor de reutilizacion r, que representa el porcentaje de
puntos de objetos reutilizados de otros proyectos, quedando la fonnula:
NOP (New object points) = (OP) * (100 - r) / 100,
siendo OP el numero de puntos de objetos. Los puntos objetos se utilizan en el modelo de
estimacion de costes CO COMO II (Boehm et aI., 2000).
Tambien merece especial atencion la propuesta de Full Flincion Points (FFP)
elaborada por el consorcio COSMIC (Common Software j\1easllrement international
Consortium). La propuesta COSMIC-FFP (COSMIC, 2003) proporciona un metodo
estandar para la medicion del tamafio funcional del software y a partir de esta propuesta se
ha derivado el estandar ISO/IEC 19761 "Software Engineering - COSMIC-FFP - A
functional size measurement method".
COSMIC-FFP puede ser empleado para aplicaciones de negocio software, es decir,
domini os como la banca, contabilidad, gestion de personal, compra, distribucion 0
fabricacion, etc., asi como para sistemas software de tiempo real y sistemas hibridos de
los anteriores. Sin embargo este metodo aun no cubre piezas software que esten
caractelizadas por aigOlih110S matematicos complejos u oh'as reglas, como las encontradas
en sistemas expertos), software de simulacion, de pronostico, de autoaprendizaje, etc.
El metodo COSMIP-FFP requiere la aplicacion de un conjunto de modelos, reglas
y procedimientos a una detenninada pieza de codigo de acuerdo a tal y como dicha pieza
es percibida desde la perspectiva de los requisitos funcionales del usumio. Como resultado
se obtiene una cantidad l1l11nelica que representa el tamafio funcional de dicho software.
EI proceso de COSMIP-FFP consiste en dos fases fundamentales: Fase de "Mapping".
en la que se reciben como entrada los requisitos funcionales del usuario y mediante la
aplicacion de una serie de reglas y procedimientos dichos requisitos son expresados de
acuerdo almodelo de software generico de COSMIC-FFP y la; Fase de Medicion, que a
partir del modelo genelico produce un valor de tamafio funcional del modelo de acuerdo
al siguiente plincipio "el tamai'io funcional del software es directamente proporcional al
nlllnero de sus movimientos de datos". Los movimientos de datos pueden ser de cuah'o
tipos: entrada, salida, lecrura y escrirura.
Otros consorcios como el IF PUG (International Function Point User Group)
proporcionan tambien un amplio sopOlte para la aplicacion de las mehicas relacionadas
con los puntos funcion.
CAPiTULO 9: MEDICIO]\ DE SISTEMAS DE NFORMACION 255
4. HERRAMIENTAS DE MEDICION SOFTWARE
El desalTolIo de un marco efectivo p&a la medici6n requiere un soporte
metodo16gico, pero tambien es muy impOltante el aspecto tecno16gico (Lavazza, 2000).
Es decir, para que las meuicas puedan ser evaluadas de un modo pnictico, eficiente y
ex acto es necesario contar con helTamientas que pennitan automatizar la adquisici6n, la
presentaci6n y el amilisis de los valores de las metlicas (Giles y Daich, 1995). Las
ventajas de contar con una helTamienta que pennita automatizar tanto la adquisici6n y la
presentaci6n como el analisis de los valores de las meu'icas son (Lavazza, 2000):
EI Posibilitar la obtenci6n de los valores de las meuicas sin mayor esfuerzo
EI Minimizar los elTores en el ca1culo de las metlicas, logrando una mayor
exactitud en sus val ores
EI Pel111itir central110S en el analisis de los resultados de la medici6n y no en la
etapa de adquisici6n
Una helTamienta de metlicas de software puede definirse como una helTamienta
para el modelado y el calculo de componentes de desaITolIo de software, bien sean del
proceso, del producto 0 de los recursos (SMLab Project, 2002).
El proceso de desaITolIo de software tambien incluye la preparaclOn de los
componentes del software y del proceso de evaluaci6n. Asi pues, es necesario contar con
hen'amientas que den sopOlte a la medici6n de software como un gmpo denu'o del
conjunto de metricas. Son las denominadas herTamientas CA1VIE (Computer Assisted
Software Measurement and Evaluation), es deciI', HelTamientas para la Medici6n y
Evaluaci6n de Software Asistidas por COl11putador.
Existen varios estudios dedicados a la evaluaci6n y comparaci6n de herTamientas
de metlicas (Giles y Daich, 1995; Daich y Giles, 1995; Daich et al., 1995; Erickson y
Steadman, 1995; Kingsbury y Dawood, 1995; Giles y Bal11ey, 1995).
Giles y Daich (1995) distinguen las u'es principales tareas que deben realizar las
herTamientas de l11euicas y las caracteristicas que deben implementar para que
dichas tare as se puedan lIevar a cabo:
EI Adquisicion de datos: manual, semiautol11atica, autol11atica y programable.
EI Analisis de las medici ones: almacenamiento de los datos, recuperaci6n de los
datos, analisis ariunetico y analisis estadistico.
EI Presentaci6n de los datos: tablas, graficos, posibilidad de exportar archivos a
otras aplicaciones
Dumke y Kompf (1997) clasifican las helTamientas de l11etlicas atendiendo al
entomo 0 dominio en el que se utilizan.
256 CAUDAD DE SISTEMAS INFOR;\L'\ TICOS
5. lECTURAS RECOMENDADAS
(l) Proceedings de IEEE A1ETRlCS Symposillm. Este simposio intel11acional
constituye una de las conferencias mas importantes centradas en los aspectos
de investigacion y practica en el campo de la medicion del software.
Proporciona un foro de debate para analiza!' y prom over el uso de la medicion
software como medio para entender, evaluar y modelar los fenomenos de la
Ingenieria del Software.
(l) http:hvww.aemes.fi.upm.es!, Asociacion Espanola de Metricas del Software
(l) http://w"\vw.cosmicon.com/. Sitio de COSMIC (Common Software
Measurement Intel11ational Consortium)
(l) http://W\\w.ifplUI.Orgj Sitio web delIFPUG (Intel11ational Funtion Point Users
Group)
(l) http://ww,v.isbsg.onz/ Sitio de Intel11ational Software Benchmarking Stan-
dards Group
e http://w\v\\.nesma.org!english! Sitio Web de NEStvlA (Netherlands Software
Metrics Users Association)
(l) http:!.\nnv.uksma.co.uk! Sitio de MARK II (United Kingdom Software
Metrics Association)
7. EJERCICIOS
I. Representar mediante la ontologia de la medici on software el siguiente caso de
estudio: supongamos una organizacion que lleva a cabo un proyecto de desaITollo
de software. En un detenninado momenta el responsable del proyecto necesita
saber si la productiyidad es adecuada. en concreto es necesario conocer el nivel
de productividad de los programadores. del proyecto en comparacion con 10
habihlal en otros proyectos en la organizacion. Las metricas a utilizar podrian ser:
a. LCF (lineas de codigo fuente escritas). que se puede obtener contando las
lineas utilizando como instrumento una heITamienta CASE.
b. HPD (horas-programador diarias). EI responsable del proyecto anota
cada dia las horas dedicadas por los programadores al proyecto.
c. CHP (coste por hora-programador. en unidades monetarias). EI metodo
de medicion es consultar el plan del proyecto. donde se hlVO que indicar
este valor. previa consulta a un responsable de personal.
RA.-:'!A C\PiTULO 9: 0.!EDICI00; DE SISTE?vlAS DE !0;FOR;yL-\CI01\ 257
d. HPT (horas-programador totales), que se puede obtener a partir de la
siguiente fOIl11Ula: HPT = HPD
L..dias
e. LCFH (Iineas de codigo fuente por hora de programador), LCFH = LCF
IHPT.
f CTP (coste total actual del proyecto, en unidades I11onetarias), CTP
CHP '" HPT
g. CLCF (coste por linea de codigo fuente). CLCF = LCF/CTP.
h. PROD (productividad de los programadores). Para ello se usa un modelo
de awllisis basado en extraer de una base historica de proyectos de la
organizacion los valores medios de LCF, HPT, LCFH (LCFHvm) y CTP
del subconjunto de proyectos similares (aquellos que tienen LCF entre el
80% y el 120% ). Los critelios de decision establecidos son:
1. LCFHlLCFHvm < 0'70 => PROD='muy baja'.
I!. 0'70:s; LCFHiLCFHvm < 0'90 => PROD='baja'.
111. 0'90:S; LCFH/LCFHvm < 1'10 => PROD='nonnar.
IV. 1'10:S; LCFHlLCFHvm < 1 '30 => PROD='alta'.
v. 1'30:s; LCFH/LCFHvm => PROD='muy alta'.
1. CAR (carestia del proyecto). De la base histolica de proyectos se
obtienen los valores medios de LCF, CLCF, y PROD del subconjunto de
proyectos simi lares. Los criterios de decision son bidimensionales. La
primera dimension compara el valor de CLCF del proyecto con el valor
medio historico (CLCFvm) para de!enninar si el coste de cada linea es
mas alto 0 bajo de 10 nonna!. La segunda dimension simplemente
compara PROD con PRO Dvm para ayudar a decidir si la razon de ese
coste alto (0 bajo) pOl' linea es 0 no debida a la baja (0 alta)
productividad. De esta manera, los val ores de CAR seran cualitativos del
tipo: 'muy alta pOl' baja productividad', 'nonnal a pesar de productividad
baja'. etc.
2. Definir un conjunto de metric as para evaluar la facilidad de entendimiento de un
diagrama de actividad UML aplicando el metodo GQM.
3. Definir utilizando la plantilla GQ(I)M los indicadores del ejercicio 1.
258 C:\UDAD DE SISTEMf\S Il'-IFOIUvlA. TIeos
4. Realizar un estudio bibliognifico sobre la aplicaci6n de la medici6n en la
industria de desarrollo de software.
5. Analizar que tipos de metricas son aplicables en cada nivel de madurez del
modelo CMMI.
CAPiTULO 10
CALIDAD DE LA INFORMACION
"Los en'ores callsados par los datos il1adecllados SOil Illucho lllel10reS que los que se debel1 a la
total allsel1cia de datos"
Charles Babbage
1. INTRODUCCION
Actualmente las organizaciones pueden almacenar inmensas cantidades de datos
obtenidas a un precio relativamente bajo. Sin embargo, estos datos quizas no
proporcionen infonnaci6n (Gardner, 1998), pOl'que en algunos casos adolecen de
problemas de poluci6n, inconsistencia, etc. Esta poluci6n puede llegar a tener graves
consecuencias tanto desde el punto de vista tecnico -como en la implementaci6n de
almacenes de datos-, como organizacional -perdida de c1ientes (Redman, 1996), gI'andes
perdidas financieras (Loshin, 2001) 0 insatisfacci6n de los trabajadores (English, 1999)-
e inc1uso legal -basta recordar el articulo 4 del Titulo II de la actual LOPD (Del Peso,
2000)-. Es esencial poder asegurar la calidad de la in.fonnaci6n que contienen las bases 0
los almacenes de datos
l
ya que se han convertido en la principal henamienta para la toma
de decisiones, tanto operacionales como estrategicas. Ademas, "las empresas deben
gestionar la informacion como lin prodllcto importante, capitalizar el conocimiento como
lin activo principal y, de esta manera, sobrevivir y prosperaI' ell la ecol1olllia digital"
(Huang et al., 1999). La calidad de los datos y de la infonnaci6n viene detenninada tanto
por la calidad de la bases de datos como por la calidad de la presentaci6n de los datos (vel'
la figura 10.1).
I A partir de ahora se hablara de bases de datos en general, incluyendo en este termino los almacenes
de datos (datalmrehollse), datamarts, y cualquier otro repositorio de datos.
260 C\UDAD DE SISTE'vl-\S INFOR.'vlATICOS
Calidad de la
Informaci6n

Cali dad de la Base de Datos
Calidad de la Presentaci6n

Calidad del SGBD
Calidad del Calidad de los
Modelo de Datos Datos
I
Calidad del
I
Calidad del Calidad del
Modelo
Modelo L6gico Modelo Fisico
Conceptual
Figura 10.1. CaUdad de fa informacion .r de fa base de datos
De hecho, es l11UY importante que los datos de la base de datos reflejen
COlTectamente el mundo reaL pero es tambien muy importante que los datos puedan ser
interpretados conectamente. En la calidad de una base de datos. se deben considerar tres
aspectos: la calidad del SGBD (Sistema Gestor de Base de Datos) -relacionaL orientado a
objetos. objeto-relacional. multidimensional, XML etc.- que 10 sopOlia. la calidad del
modelo de datos (tanto conceptuaL logico como fisico) y la cali dad de los propios datos
contenidos en la base de datos.
Para asegurar la calidad del SGBD. se puede usar un estil11dar intemacional como el
ISO 9126 (vease capitulo 5), 0 alguno de los estudios comparativos de productos
existentes. Este tipo de calidad debe ser considerada en la etapa de seleccion de productos
dentro del ciclo de vida de la base de datos y posteri0l111ente asegurada durante la
i1l1plantacion y ad1l1inistracion del SGBD. Como es logico tambien la calidad del modelo
de la base de datos tiene una gran influencia en la calidad de la infol111acion. Modelo que
puede existir a nivel conceptual -expresado en E/R 0 UML-: a nivel logico.
pred01l1inantemente relacional con algunas extensiones. y a nivel fisico -ya que el
disei'iador tiene que elegir las tab las fisicas. los indices. particiones de datos.
agrupamientos. etc. que l11eJor representan la base de datos logica y que facilitan su
funcionalidad-.
La calidad de los propios datos (los datos que estan almacenados ya en la base de
datos) viene detel111inada plincipalmente por los procesos de extraccion. filtrado.
li1l1piado. sincronizacion, agregacion y carga que deben tener en cuenta ciertos requisitos
RA,-\lA C.-\PiTCLO 10: C.-\LIDAD DE LA 261
de calidad de datos de los usuarios: asi como de los procedimientos y procesos de mejora
de la c:tlidad de datos existentes en la organizacion.
En este capihIlo se mostrani como se puede analizar y eshldiar la calidad del
modelo de datos. de los propios datos y de la infol111acion que gestionan las empresas.
2. CAUDAD DE LOS MODELOS DE DATOS
2.1. CaUdad de los modelos conceptuales
Ai111 cuando el modelado conceptual representa solo una porcion del esfuerzo total
de desarTOllo de un SL su impacto en el resultado final es probablemente mucho mayor
que el de cualquier otra fase. Por ello. el modelado conceptual se ha conveI1ido en una
tarea clave en las primeras etapas del ciclo de vida de los SI. Cuando se habla del
modelado conceptual. se debe distinguir entre la calidad del producto y la calidad del
proceso. La calidad del producto esta relacionada con las caracteristicas del modelo
concephlal (el producto). mientras que la calidad del proceso esta relacionada con como se
desarTollan los modelos concephlales (el proceso). Este capihllo se centra enla calidad del
producto. mientras que las cuestiones relacionadas con la calidad del proceso estan
parcialmente tratadas en Moody ( 1998) Y Maier (2001 ).
Algunos antores han definido la calidad de los modelos concephlales como una
lista de propiedades "deseables" que debe satisfacer el modelo de datos (vel' tabla 10.1) Y
han propuesto una serie de transformaciones con el objetivo de mejorar la calidad de los
mlsmos.
ALTORES PROPIEDADES
Complccioll. com;cciotl. minimalidad. cxprcsi\idad.
Batini ct al. ( 1992)
lcgibilidad. auto(:xpiicacion. (:xt(:nsibilidad y nOl1nalidad.
Com:;ccion conccp.ual. compiecion conceptual. com::ccion
Reingl1lber \1. Y Gregory \ \". ( 199.+) .
; sintactica. complecion sintactica. conocimiento de Ia .:mprcsa.
Facilidad de comprension. COlTcccion semantica. cstabilidad.
Boman et al. ( 1997)
compiecion. enfoque conceptual.
Tabla 10.1. Propiedades "deseables" para el modelo conceptual de datos
Aunque estas Iistas de propiedades proveen un punto de partida i!til para entender y
mejorar la calidad en el model ado concephlal. la mayoria no son estnlchlradas. usan
definiciones imprecisas. a menudo se solapan, se mezclan caracteristicas de la
especificacion con las del metodo y del lenguaje de modelado. se presupone la existencia
262 CAUDAD DE SISTE:VIAS TICOS
de disefio/implementacion, y se presentan objetivos poco realistas 0 imposibles de
alcanzar (Lindland et af., 1994).
Una estrategia mas adecuada para abordar la calidad es definir marcos de referencia
que organicen y estmcturen los conceptos claves y caracteristicas en el modelado
conceptual de datos. Ademas, se han publicado algunos marcos de referencia que
penni ten abordar la calidad en el model ado conceptual de una manera mas sistematica.
Aunque estos marcos son relevantes en el senti do de que contribuyen a un mejor
entendimiento sobre el h'atamiento de la calidad de los modelos conceptuales, carecen de
medidas cuantitativas que pennitan evaluar la calidad de los modelos conceptuales de
datos de fonna objetiva. Resulta evidente que definir solo "propiedades deseables" no es
suficiente para evaluar la calidad, ya que diferentes personas pueden dar diferentes
interpretaciones sobre el mismo concepto, por 10 que es necesario contar con medidas que
pennitan evaluar la calidad de los modelos conceptuales de datos de fonna cuantitativa y
objetiva, evitando as! los sesgos en el proceso de evaluacion de su calidad.
A continuacion se resumen algunos de estos marcos de referencia para la mejora de
la cali dad de datos del modele conceptual.
2.1.1. PROPUESTA DE LINDLAND ET AL.
Este marco, basado en la teoria semiotica, se presento en Lindland et al. (1994) con
el objetivo de paliar las deficiencias detectadas en los enfoques de listas de propiedades, al
mismo tiempo que se separan los objetivos de cali dad de los medios para alcanzarlos y se
utiliza lill fundamento mate matico en su descripcion. En Krogstie et al. (1995) se ha
extendido este marco con el fin de incorporar el concepto de acuerdo social de Pohl
(1994), con 10 que se pueden identificar los siguientes elementos (vease figura 10.2):
G Audiencia (A): union del conjunto de actores individuales, el conjunto de
actores sociales organizacionales y el conjunto de actores tecnicos que
necesitan relacionarse con el esquema.
G Modelo (l\'I): conjunto de todas las sentencias expresadas explicita 0
implicitamente.
G Lenguaje (L): conjunto de todas las sentencias que se pueden expresar de
acuerdo al vocabulario y la gramatica de los "lenguajes de modelado"
utilizados.
G Dominio (D): conjunto de todas las sentencias que sedan COlTectas y
relevantes acerca del problema.
<;: Ri\-MA CAPiTULO 10: CAUDAD DE lA INFORlvL-\CION 263
 Interpretacion de la audiencia (I): conjunto de todas las sentencias de las que
la audiencia piensa que consta el modelo.
 Conocimiento de los participantes (K): union de los conjw1tos de sentencias
de todos los actores sociales individuales.
DOMINIO
CALIDAD
SEMANTICA
CALIDAD
SEMANTICA
PERCIBIDA
...:.:.J-' -
t
"" ..
CONOCIMIENTO
DEL PARTICIPANTE
MODELO
CALI DAD
SINTACTICA
t CALIDAD
t TICA
)
INTERPRETACION
DE LA AUDIENCIA
CALIDAD
SOCIAL
LENGUAJE
Figura 10.2. Marco para la calidad del modelado conceptual, Krogstie et al. (1995).
Como es natural, se considerani que un modelo tiene una mayor calidad semfmtica
cuanto mejor sea la conespondencia entre el modelo conceptual que se ha disenado y el
dominio que pretendemos representar. Sin embargo, como senalan los autores de este
marco, es imposible establecer 0 verificar directamente esta conespondencia, ya que para
disenar el esquema se debe acudir al conocimiento que tiene el publico sobre el dominio y
para verificarlo se debe emplear la interpretacion que el publico hace del modelo.
En este marco se prop one distinguir varios tipos de calidad:
 Calidad sintactica: que viene detenninada por la conespondencia entre el
modelo y ellenguaje, y cuyo objetivo es la con'eccion sintactica.
 Calidad semantica: (percibida), que comprende tanto la validez (10 expresado
en el modelo es conecto y relevante para el problema) como la complecion (el
modelo contiene todas las sentencias acerca del dominio que son conectas y
relevantes ).
 Calidad pragmatica: cuyo objetivo es que el modelo sea comprendido.
 Calidad social: que persigue distintos tipos de acuerdo tanto en la
interpretacion del modelo como respecto al conocimiento del dominio.
I
264 C-\UDAD DE SISTE:V!AS NFOR"L.I. Tleos
i
I
MEDIOS
TIPOS DE CAUDAD OBJETfVOS
I
PROPIEDADES :'IlODELO ACTIHDADES
SINT..tCTICA
I
COlTeccion sintactica Sintaxis fOTInul
I
Verif Sinl<\ctica
Verif Consistencia
Validez \-iable Semantica fOTInal
SE\L-l,\'TJCA Insercion sentencias
Complccion viable Moditicabilidad
BOlTado sentencias
Insercion sentencias
SE\lA?\'TICA
BOlTado sentencias
PERCIBIDA
Entrenamiento
I
Inspeccion
I
\-isualizacion
.
I
Economia .;xpr.;si\-a I
Filtrado
I
I
Estetica Presentacion diag_
!
I
Paratl-ascar
I
I
PRAGXIATICA Comprension \-iablc
I
I
Explicacion
j
I
I
I
Entrenamiento
I
I
I
I
I
I
I
Ejecucion I
i
I
Ejecutabilidad Animacioll
I
Simulacion
I I
I
:\n,\lisis punto \-ista
I
I
I I
SOCL-l.:L Acuerdo \-iable ~ o d e l a d o contlicto I Resolucion cont1icto
Fusi6n de modelos
Tabla 10.2. Objetiyos y medios de conseguir la calidad (Krogstie et aI., 1995).
Este marco prop one ademas distintos medios para mejorar los diferentes tipos de
calidad. La tabla 10.2 muestra los objetivos .y los medios para alcanzarlos de acuerdo los
conceptos de cali dad propuestos en los marcos de Lindland et at. (1994) .y Krogstie et at.
(1995). que si bien unos son extensiones de otros. persiguen el mismo objetivo. que es
en tender el concepto de la cali dad en el modelado conceptual basandose en conceptos
semi6ticos.
CAPITULO 10: CAUDAD DE LA 265
2.1.2. PROPUESTA DE MOODY Y
Otro marco, con un enfoque mas practico que el antelior, fue presentado por
Moody y Shanks (1994) y refinado en Moody et a1. (1998). Pretende ayudar a los
disefiadores a la hora de elegir entre distintas altemativas de disefio y de poder acomodar
las distintas visiones de los distintos implicados ("stakeholders") en el proceso de
model ado de datos. Este marco presenta los siguientes elementos relacionados con el
esquema (vease figura 10.3):
STAKEHOLDER

FACTOR D E ..... 4.II1----iii!ilt>ilO>
CALIDAD
l\rIODELO

ESTRATEGIA DE MEJORA
/
METODODE
EVALUACION
VALORACION
Figura 10.3. Elementos del Marco de Moody y Shanks (1994).
o Factor de Calidad: propiedad deseable de un esquema conceptual.
o Implicado (stakeholder): persona involucrada en la construccion 0 utilizacion
del esquema.
o Estrategia de mejora: tecnica para meJorar la cali dad de los esquemas
conceptuales.
o Metodo de evaluacion: modo sistematico 'de evaluar factores de calidad.
o Peso: que sirve para definir la importancia relativa de los factores de calidad.
o Valores: representan la valoracion de un factor de calidad por alguno de los
implicados.
En la revision de este marco (Moody et aI., 1998), se prop on en los ocho factores de
calidad que aparecen enla figura 10.4.
Para Moody estos factores significan:
266 CAUDAD DE SISTEMAS INFORc'vLA. TICOS iRA-MA
9 Complecion: capacidad delmodelo de tener toda la infol1naci6n necesmia para
cumplir los requisitos del usuario.
9 Comprensibilidad: facilidad con la que el esquema puede ser entendido.
9 Correccion: se refiere a si el esquema cumple las reglas de las tecnicas de
modelado utilizadas.
e Flexibilidad: facilidad con la que el esquema se puede adaptar a los cambios
en los requisitos.
9 Integracion: nivel de consistencia del esquema con el resto de los datos de la
organizaci6n.
e Integridad: grado en el que las reglas del negocio que se aplican a los datos
estc'm definidas en el esquema conceptual.
e Simplicidad: significa que el esquema contiene los minimos constructores
posibles.
e Implementabilidad: facilidad con la que el esquema puede ser implementado
dentro de las restricciones de tiempo, presupuesto y tecnologia del proyecto.
usuano usuano
analista analista
usuano usuano
admin. desan'ollador
datos
/ /
MODELO
I'
DECALIDAD
V
Figura 10.4. Factores de calidad, (:Vloody et aI., 1998).
Este marco se ha validado en varios casos pn'icticos, en los que tambien se ha
estudiado la influencia que ejercen unos factores sobre otros; as!, por ejemplo. aumentar la
implementabilidad del esquema puede acalTear una disminuci6n de su flexibilidad y
compleci6n, como muestra la tabla 10.3.
Moody (1998) propone 25 mehicas c1asificadas seglll1 los factores de calidad de la
figura 10.4: algunos calculados de fOl1na objetiva (por ejemplo, el nllll1ero de entidades
(; RA-?vL'\ CAPiTULO 10: CAUDAD DE LA INFOR3vlACION 267
del esquema), mientras que otros resultan de la puntuaci6n subjetiva de los implicados en
el disefio (vease tabla 10.4).
..
...
Q I
. ..
I Q
~
Z
;:
Q
~
a
-9
-:::
z
Q
~
u
2:
~
Q
;.;J
~
g
:::; ~
.:::::
:::::
<:::) ...l
;;;:
~
"-
""
I
~ :3
c;
2 "-
::<
;;::
0 == ~
~
!
==
~ u
Ci5 r_ I..i
.. , .. COMPRE\'iSIBILIDAD
'.
Sln'iPL'(CID.W
..
FlEXIBILJDAD
COMPLEtION
l;\fPLE;\IEi\TABrLID,W +
I:\TEGRIDAD
Tabla 10.3. Interacciones positivas y negativas entre factores.
,
FACTOR DE CALIDAD METRICAS
N de elementos del modelo de datos que no corresponden con requisitos de usuario
CmIPLECIO:-;
1\0 de requisitos de usuario no representados en e[ modelo de datos
N" de elementos de datos quc corresponden a requisitos de usuario pero ddinidos de fomla
inexacta
N" de inconsistencias con eI modelo de procesos
I:-;TEGRIDAD
1\" de reglas del negocio que no se hac en eumplir por elmodelo de datos
N de restriceiones de integlidad incluidas en eI modelo de datos que no eorresponden a politieas
del negocio
FLEXIBILIDAD
N" de elementos en eI modelo que est,in sujetos a cambios en el futuro
Costes estimados de los cambios
Importancia estrati:gica de los cambios
Yaloraci6n de los usuarios sobre la comprensibi[idad del modelo
CO:\IPRE:\SIBILIDAD Capacidad de los usuarios de interpretar elmodelo correctamente
Valoraei6n de los desarrolladores de aplieaciones sobre la eomprensibi[idad del modele
N"'de \'iolaeiones de las convenciones de modelado de d,ltos
CORRECCI6:-; ,"," de \'iolaciones a Jas fortnas nortnales
N" de instaneias de redundancia en cl modele
N de entidades
SnlPLICIDAD N de cntidades e interrelaciones
);0 de constructores (aN
E
b1\" - c1\\)
N" de eont1ictos con el modelo de datos corporativo
I:-;TEGRACI6:-; N de conflictos con [os sistemas existentes
\'aloraci6n de los representanleS de todas las areas de negocio
\' a[oraci6n de riesgo tccnico
hIPLDIE:\TA- Valoraci6n de riesgo de planificaci6n
BILIDAD
Estimaci6n del coste de desarrollo
N" de elementos fisicos incluidos en e[ modele de datos
Tabla 10.4. iVIetricas para evaluar la calidad de modelos E/R (Moody, 1998)
268 CA.LIDAD DE SISTDIA.s
2.1.3. PROPUESTA DE SHAl'\fKS Y DARKE
Shanks y Darke (1997) han propuesto integrar el marco de Moody y Shanks
(1994) con el de Lindland et af. (1994), ya que ambos se complementan (este liltimo
des de un punto de vista 111<1S teorico, mientras que el de Moody y Shanks se enfoca mas
hacia la practica) y ademas comparten conceptos: los implicados (stakeholders) podrian
asimilarse al pllblico, los objetivos y las propiedades a los factores de calidad y el
concepto de modelo es compatible en los dos marcos (vease figura 10.5).
!
DE
YALORES
___ -"I 'pun,". E\ALL\CIO"
Figura 10.5. :Yletamodelo propuesto por Shanks y Darke (1997)
Los conceptos comunes son integrados en este marco. y los conceptos disjuntos son
incorporados al mismo, como se muestra en la figlira 10.5. En dicha figura se indican los
conceptos referentes a la cali dad en el modelado de datos basados en la teoria, y ademas
los conceptos que soportan la evaluacion de la calidad en la practica.
Los conceptos que estan basados tanto en la practica como en la teOlia se muestran
en la parte central (sombreada con un color mas oscuro) de la figura 10.5, la cual pennite
entender la relacion entre ambos marcos y como uno infonna al oto. Este marco
integra do puede aplicarse en cualquier etapa del proceso de modelado conceptual, y tiene
en cuenta el concepto de calidad tanto en el modelado del producto como en el proceso de
modelado delmismo.
LRA-MA CAPiTULO 10: CAUDAD DE LA INFOIUvIACI01'.' 269
2.1.4. PROPUESTA DE KESH
Kesh (1995) propuso el desanollo de un modelo, una metodologia y metricas para
evaluar la calidad del modelo E/R. La figura 10.6 muestra el marco de referencia utilizado
para evaluar la calidaJ, que considera dos tipos de componentes: de compOltamiento y
ontol6gicos.
Los modelos E/R estan fonnados por dos componentes ontol6gicos: la estructllra y
el contenido. La estructura se refiere a las entidades y sus relaciones y el contenido se
refiere a los a1:J.ibutos de las entidades. Entre los factores que influyen en la calidad de la
es1:J.uctura, se pueden citar:
II Adecuaci6n al problema: la adecuaci6n de la eStlLlctura, se refiere a S1 el disefio
delmodelo EIR refleja la es1:J.uctura del problema que se esta modelando.
II Concisi6n: se refiere a que el modelo EIR no tenga redundancia.
II Consistencia: se refiere a si el modelo no muestra contradicciones.
II Validez: se refiere al cumplimiento de plincipios tecnicos de disefio.
Y entre los facto res que influyen en la calidad del contenido, se tienen:
II Cohesi6n: se refiere a la cercania que existe entre los atJ.ibutos de una entidad.
II Compleci6n: se refiere a que todos los atlibutos que sean relevantes deb en ser
incluidos.
II Validez: se refiere a que los a1:J.ibutos sean conectamente asignados a las
entidades.
Como muestra la figura 10.6, existe una fuerte relaci6n en1:J.e la es1:J.uctura y el
contenido. Para obtener un modelo EIR de buena calidad, es necesario evaluar la calidad
tanto del contenido como de la estructura. Los componentes ontol6gicos, la es1:J.uctura y el
contenido, detenninan el compOltamiento del sistema.
Factores que influyen en la calidad del comportamiento:
II Mantenibilidad (M): es la facilidad con que un diagrama E/R puede ser
l110dificado, conegido y extendido ante futuros requerirnientos.
II Precisi6n (P): se refiere a la exactitud con que el diagral11a EIR refleja el
problema que se esta modelando.
II Rendil11iento (R): se refiere a un disefio eficiente del diagrama EIR, y la
eficiencia es el nlllnero de entidades, relaciones y atJ.ibutos con relaci6n al tipo
de tarea que la base de datos representa.
270 CAUDAD DE SISTElvLA.S ll\'FORt'vlATICOS
RA-!v1A
It Usabilidad: se refiere a si un diagrama EIR es conveniente y pnictico para su
uso. Los disenadores y los usuarios tienen diferentes puntos de vista acerca de
la usabilidad, por eso es conveniente subdividirla en usabilidad para el usuario
CUU) y usabilidad para el disenador (UD).
Figura 10.6. Marco de Referenda para la evaluacion de la calidad (Kesh, 1995)
La tabla 10.5 muestra como los factores ontol6gicos afectan a los factores de
comportamiento.
AderTI<ls Kesh (1995) prop one una metodologia y metricas para evaluar la calidad
de los modelos EIR que detallamos a continuaci6n.
Una vez construido un modelo EIR se. debe evaluar su calidad utilizando la
siguiente metodologia:
1. Calcular el valor de cada componente ontol6gico en fomm individual.
2. Para componente de comportamiento combinar los valores de los componentes
ontol6gicos que Ie son relevantes.
3. Combinar los val ores de los componentes de comportamiento para calcular el
valor global de la calidad.
I
<';RiI.-MA CAPiTULO 10: CAUDAD DE LA INFORJvl;\ClON 271
4. Si el valor de un componente ontol6gico esta por debajo de un cielto valor, debe
ser investigado y su valor debe ser mejorado antes de seguir adelante.
DliHENSIO:-''ES
USABILIDAD I USABILlDtill
j\h.!"lTENF
I
1USUAlUO ....
..
DISEl'/ADOR BILlDAD
.. ....
Adecuaci6n al
X
problema
"'.:;.".< ......
Validez X X
Consistencia X X X
:> Concisi6n X X X
.... : ..
Compleci6n X X X X
,..;; ....
Cohesi6n X X
i .. . Validez X
I
Tabla 10.5. Relaci6n entre los factores ontol6gicos y los de comportamiento
Kesh (1995) ademas propone una medida para ca1cular el valor global de la
calidad, teniendo en cuenta la influencia que tienen los factores ontol6gicos sobre los
factores de comportamiento, como muestra la tabla 10.5.
2.1.5. PROPUESTA DE SCHUETTE Y ROTTHOWE
La propuesta de Schuette y Rotthowe (1998) se basa en la suposici6n de que la
postura subjetiva del modelador es un aspecto relevante para el resultado del model ado
conceptual y por 10 tanto tal subjetividad debe ser manejada y comprendida.
El enfasis de la subjetividad en el proceso de modelado requiere medidas
especificas para el manejo de la subjetividad para poder desan'ollar modelos
subjetivamente comparables y probables. El hecho de resaltar la subjetividad enfatiza la
importancia del disefiador.
Como la subjetividad del modelado no puede ser eliminada completamente pero
solo control ada, es necesario contar con reglas que tengan que ser seguidas en el proceso
de modelado. Siguiendo ciertas reglas durante el proceso de modelado es posible construir
modelos subjetivamente comparables. Especialmente en proyectos donde intervienen
muchos disefiadores tales reglas son absolutamente necesarias. Adelmis, un usuario del
modelo, quien no estuvo involucrado en el proceso de modelado, podria entender los
modelos, solo si conoce las reglas subyacentes del proceso de modelado.
Schuette y Rotthowe (1998) definen:
I
I
272 CAUDAD DE SISTE:VL,,-S IKFOR,\Li. TICOS
EiI Una Guia de modelado (GoM) obtenida a partir de los problemas que surgen
del proceso subjetivo de disefio de un sistema GoM contiene seis principios
que pem1iten mejoran la calidad del model ado de la infonnaci6n.
EiI La arquitectura GoM, que es un marco estructural en el cual son ubicados
cada uno de los componentes de esta guia.
La idea de los autores al proponer una Guia de Modelado (GoM) es presentar un
marco de principios que mejore la cali dad de los modelos de infom1aci6n reduciendo el
slIbjetivislIlo en el proceso de modelado de la infonnaci6n. La calidad de los modelos se
basa en recomendaciones para lograra un eficiente, comprensivo Y COlTecto disefio de los
modelos de infom1aci6n. La tabla 10.6 muestra los objetivos de cada uno de los seis
principios generales de GoM, que son los que fonnan la base de la Arquitectura GoM.
PRINCIPIOS
I
OBJETlVOS
,
1
Consenso a cerca de la definicion de la definicion del problema
Principio de adecuacion de la
Consenso a cerca de la representacion del modelo
Consistencia intra-modelo
construccion
Consistencia inter-modelo
Minimalidad
Correccion dellenguaje
Adaptacion dellenguaje
Principio de adecuacion dellenguaje Poder Sel11<lntico
F onnalizacion
Comprensibilidad dellenguaje
Principio de la eficiencia economica
Consenso
La comprensibilidad y aplicacion dellenguaje
Comparabilidad estructura sistematica
Disefio jerarquico
Disefio del esquema
Principio de claridad Filtrado
Filtros metodicos
Filtros de contenido
I
Consistencia inter-modelo entre los modelos de la estructura y el
I Principio del disel10 sistematico comportamiento
;\rquitectura. de los sistemas de infonnacion
I
I
Comparabilidad a nivel de meta modelo
I
Principio de comparabilidad
Transfonnacion completa
I
T raduccion consistente
Comparabilidad a nivel del modelo
Tabla 10.6. Principios de la Guia de Modelado (GoM)
La Guia del Modelado, ademas del esfuerzo de estandarizaci6n, tiene en cuenta la
inteiTelaci6n entre el problema a ser modelado y su representaci6n, la eficiencia
econ6mica del model ado y medidas para mejorar la claridad delmodelo.
[ R.-'I.-MA CAPiTULO 10: C-'l.UD.-'l.D DE LA INFOR.\jACrOl\' 273
2.1.6. PROPUESTA DEL GRUPO ALARCOS
La complejidad de un modelo conceptual puede estar altamente influenciada pOl'
los diferentes elementos que 10 componen, tales como entidades/clases, a1:Iibutos,
relaciones, generalizaciones, etc. POl' 10 tanto no es aconsejable definir una medida general
para su complejidad (Fenton. 1994). Siguiendo este razonamiento Piattini et af. (2001)
han propuesto un conjunto de medidas para mediI' la complejidad estmctural de un
modelo ER (vel' tabla 10.7), siguiendo la nocion de complejidad estructural 0 del producto
de Henderson-Sellers (1996).
I
NOMBRE DEFE\l.CION .'
NE Numero total de Entidades dentro de un modelo ER.
Nlunero total de Atributos en un modelo ER. teniendo en cuenta los atributos de las relaciones
NA como los de las entidades. En este nlunero se incluyen atributos simples. compuestos y
multiyaluados.
NTIA Nlunero total de Atributos Derivados en una modelo ER.
NCA Nllmero total de Atributos Compuestos en un modelo ER.
NMVA Nlllnero total de Atributos Multiyaluados en un modelo ER.
NN"R
Numero total de Relaciones en una modelo ER. teniendo en cuenta solamente relaciones
comunes.
NM:NR Nlllnero total de Relaciones M:N en un modelo ER.
Nl:NR Numero total de Relaciones I:N (incluyendo tambien relaciones I: I) en un modelo ER.
NBinaryR Numero total de Relaciones Binarias en un modelo ER.
NN-AryR Nlllnero total de Relaciones N-arias (no binarias) en un modelo ER.
NIS AR
I
Numero total de Relaciones Es_Un (generalizaci6nJespecializaci6n) que existen en un modelo
ER. En este caso. se considera una relaci6n por cada par padre-hijo, dentro de la relaci6n Es Un.
NretR
I
Numero total de Relaciones Reflexivas que existen en un modelo ER.
NRR Numero de Relaciones Redundantes en un modelo ER.
Tabla 10.7. l\Ietricas para modelos ER (Piattini et al., 2001).
2.2. CaUdad de los modelos logicos
A nivel logico, el (mico cliterio que se ha venido aplicando tradicionalmente es la
teolia de la nonnalizacion para las bases de datos relacionales. Parece sorprendente que,
existiendo centenares de metric as de software, las metricas para bases de datos han sido
descuidadas (Sneed y Foshag. 1998). Esta situacion puede ser explicada ya que hasta hace
no demasiado tiempo, las bases de datos jugaban un papel relativamente secundalio
dentro de los sistemas de infonnacion siendo los programas los verdaderos protagonistas.
Ello justifica la gran presencia de me1:Iicas orientadas a programas que podemos encon1:I'ar
en la literatura. propuestas por muy diferentes autores. Sin embargo, aunque las bases de
datos se han convertido en el corazon de los Sistemas de InfoTI11acion (SI) mas relevantes
para el n.mcionamiento de la sociedad, su disei'io sigue siendo una tarea larga, dificil y
costosa. Ademas, el tamano y la naturaleza de los datos pueden influir, en gran medida, en
muchos aspectos de un SI como el esn.lerzo de desarrollo (MacDonnell et al., 1997).
274 CAUDAD DE SISTE1vLA-S INFOIUvL;\ TICOS :9 RA-1vLA-
Seglin la ISO 9126, tres de los factores que influyen en la mantenibilidad son la
analizabilidad, la cambiabilidad y la facilidad de prueba, los cuales a su vez, seglin Li y
Cheng (1987) estan influenciados por la complejidad. Henderson-Sellers (1996) divide la
complejidad en tres: complejidad computacional, complejidad psicol6gica y complejidad
representacional, y para la psicol6gica define tres componentes: complejidad del
problema, factores cognitivos humanos y complejidad del producto. A su vez, las metricas
de producto pueden ser divididas en intra-modulares e inter-modulares (Kitchenham y
Linkman, 1990). En la complejidad del producto, tanto inteilliodular como intramodular
es en la que se ha centrado el trabajo del grupo Alarcos.
Por tanto, el objetivo fundamental fue disefiar metric as de producto (que capturen
las caracteristicas especificas de los diferentes tipos de bases de datos) que nos pennitan
medir la complejidad de las bases de datos, a traves de 10 cual estaremos tambien
rnidiendo la cali dad de las mismas.
Concretamente, centraremos el estudio en las bases de datos relacionales, activas,
objeto-relacionales y multidimensionales (almacenes de datos).
2.2.1. BASES DE DATOS RELACIONALES
La tabla 10.8 reswne las plincipales metric as para modelos relacionales.
Como ejemplo de uso de estas metricas, en la tabla 10.9 se muestran los resultados
obtenidos al aplicarla al ejemplo de la figura 10.7 (Elmasri y Navathe, 1997), cuyo grafo
relacional asociado se representa en la figura 10.8.
2.2.2. BASES DE DATOS MULTIDIMENSIONALES
Un disefio multidimensional es un reflejo directo de la manera en que se yen los
procesos de negocio. Estos disefios capturan las mediciones de importancia de un negocio
y los parametros por los que se identifican estas mediciones. Las medici ones se
denorninan hechos 0 medidas. Los parametros por los que un hecho puede ser visto se
denominan dimensiones (Adamson y Venerable, 1998).
Nonnalmente los modelos de datos multidimensionales se representan como
esquemas en estrella en bases de datos relacionales, los cuales consisten en una tabla
central y varias tablas de dimensi6n. Las medidas de interes es almacenan en la tabla de
hechos (por ejemplo, ventas, 0 inventario). Para cada dimensi6n del modele
multidimensional existe una tabla dimensional (por ejemplo, producto, tiempo) que
almacena la infonnaci6n acerca de estas dimensiones (Jarke et al., 2000).
.METRICA
Numero de
Atributos de una
Tabla
Numerode
Claves Ajenas
Profundidad del
Arbol
Referencial de
una Tabla
Ratio de Claves
Ajenas de una
Tabla
Numero de
Tablas.
Cohesion del
Esquema.
Ratio de
Normalidad.
Numerode
Atributos.
Numero de
Claves Ajenas
Profundidad del
Arbol
Referencial
Ratio de Claves
Ajenas
NOTACION
NA(T),
Number of Attributes
NFK(T),
Number of Foreign
Keys
DRT(T),
Depth of the
Referential Tree.
RFK(T),
Ratio ofForeign Key
NT,
Number of Tables
COS,
Cohesion of the
Schema
NR.
Nonnality Ratio
NA,
Number of
Attributes
NFK.
Number of Foreign
Keys
DRT,
Depth of the
Referential Tree
RFK.
Ratio of Foreign
Key
CAPiTULO 10: CAUDAD DE LA INFORJvlACION 275
I ... .
definida como el numero de atributos de una tabla T
definida como el numero de c1aves ajenas de una tabla T
Definida como la profundidad maxima de todos los caminos
referenciales del grafo que se forma, tomando la tabla T como el
nodo raiz del grafo y todas las tablas relacionadas con T mediante
integridad referencial como el resto de nodos y siendo las
relaciones de integridad referenciallos arcos del mismo
definida como el porcentaje de atributos de la tabla T que son
c1aves ajenas
RFK (T) = N ~ K (T)
iVA (T)
definida como el numero total de tab las que hay en el esquema
definida como la suma del numero de tablas al cuadrado que hay
en cada componente no conexa del grafo del esquema, siendo los
nodos de este grafo las tab las del esquema y los arcos las
relaciones de integridad referencial
cs
cos = INTr;s,
definida como la relacion entre el numero de tab las en tercera
fom1a nonnal (0 superior) entre el numero total de tablas
NR= NT3NF
NT
Siendo NT31\Tf es el numero de tab las en 3NF
definida como el numero total de atributos que hay en el esquema
ST
NA = L: NA(I;)
i=1
definida como el numero total de claves ajenas que hay definidas
en el esquema
.\T
NFK = INFK(I;)
i=l
Definida como la profundidad maxima de todos los caminos
referenciales del grafo que se fonna tomando las tablas del
esquema como los nodos y las relaciones de integridad referencial
como los arcos del mismo
DRT = a x ~ (DRT(T;))
definida como el porcentaje de atributos del esquema que son
c1aves ajenas
RFK
NFK
NA
Tabla 10.8. Resumen de Metricas para el Modelo Relacional
276 CALIDAD DE SISTDL-\S INFOR\lATICOS
CRE.-\ TE TABLE DIPLEADO(
NO\IBREP VARCHAR( 15) NOT NULL.
INIC CHAR.
APELLIDO VARCHAR(I5) NOT NULL.
NSS CHAR(9) NOT NeLL.
FECHAEN DATE.
DIRECCIOPi VARCH.-\R(30).
SEXO CHAR.
S.-\L-\RIO DECIMAL(IO.2).
NSSSUPER CHAR(9).
ND INT NOT MiLL.
CO'\STRAJNT CLPP,IP PRl\IARY KEY (PiSS).
COPiSTRA.li\ 1 CLESCPERE\IP FOREIGN KEY
C-.'SSSUPER) REFERENCES E\IPLE.--\DO(NSS)
ON DELETE SET NULL ON UPDATE CASCADE.
COPiSTRA.Il\T CLEDEPTOE\IP FOREIGPi KEY (PiD)
REFERENCES DEPARTA\IENTO CPiU'VIEROD)
ON DELETE SET DEFAULT ON
CPDA TE CASCADE):
CRE.-\ TE TABLE DEPARTAME:\TO
NO\IBRED VARCHAR(l5)
NU\IEROD INT
PiSSGTE CHAR(9)
FECHAINICGTE DATE.
NOTl'\uLL.
NOT NULL.
NOT ?\ULL.
CONSTRAINT CLPDEPTO PRI\lARY KEY
(NUMEROD).
CO'\STRAIl\T CLSDEPTO UNIQUEC";OMBRED).
CONSTRAINT CLEGTEDEPTO FOREIGN KE'{
(NSSGTE) REFERENCES EMPLEADO(NSSJ ON
DELETE SET DEF.--\UL T ON UPDATE CASCADE):
CREATE TABLE LUGAR_DEPTS
(
NU\IEROD INT NOT NULL.
LUGARD VARCHAR(l5) NOT NULL.
PRll\IAR'{ KEY (NU?vIEROD. LUGARD).
FOREIGN KEY (NU\IEROD) REFERENCES
DEPARTAMENTO (PiU;VIEROD) ON DELETE
CASCADE O?\ UPDATE CASCADE):
CREATE TA.BLE PROYECTO
(
NO\1BREPR V.--\RCHAR( 15) NOT NUL.
?\lI\1EROPR INT NOT l\ULL.
LUGARPR VARCHAR(I5).
l\U\1D I?\T NOT PiULL.
PRIMARY KEY (l\U\lEROPJ.
UNIQUE (NOMBREP).
FOREIG?\ KEY (NU\ID) REFERENCES
DEPART.-\\IENTO (({U;YIEROD)):
CREATE TABLE TR-\BAJA_E:\
(
NSSE CHAR(9)
NUMP Il\T
HORAS DECEvL-\L(3.I)
PRI\!:-\RY KEY (({SSE. ({UMP).
PiOTNULL.
l\OT1\'UL.
NOT?\ULL.
FOREIGN KEY (NSSE) REFERENCES E;YIPLEADO
(({SS).
FOREIGN KE'{ (({U\IP) REFERENCES PROYECTO
(({UMEROP)):
CREATE T.-\BLE DEPE:\DIE:\TE
(
NSSE CHAR(9) NOT l\UL
NO\1BRE DEPEND VARCHAR(l5) 1\'OT l\UL.
SEXO CHAR.
FECHAAl\ DATE.
RELACIOl\ VARCHAR(8).
PRl;vL-\RY KEY (i'iSSE.l\O?vIBRE_DEPEPiD).
FOREiGPi KEY (NSSE) REFEREPiCES EMPLE.-\DO
(NSS)):
Figura 10.7. Esquema del Ejemplo
[ R/\-:vIA CAPiTULO 10: DE LA INFOR.\L-\CIO", 277
NA(f) l\TK(T) DRT(T) RFK(T) COS NR NA NFK DRT RFK
E:'>IPLEADO 10 :: 3
I ~
DEPARTA:'>IE:-iTO 4 I
,
l/4 .)
LCGARES DEPTS :: I .:I li2
PROYECTO .:I I 4 114
TR-\BAJA E:-i 3 2 5 2/3
DEPE:-iDlE:-iTE 5 I .:I 1/5
ESQCDIA 36 I 8 8 5 217
Tabla 10.9. Valores de las distintas metricas para el ejemplo
Trabaja_En
C
Empleado
""
""
"'I"
Dependiente
t+
Departamento
A1
~ i i
-+
Proyecto
Lugares_Depts
I
I
I
LL
.
Figura 10.S. Grafo Relacional del Ejemplo
Enla figura 10.9 se puede observar el ejemplo de un esquema multidimensional, en
el que se tienen dos tab las de hechos (HechosProducci6n y Usolngrediente) y cinco tab las
dimensionales (Producci6n, Ingrediente, Instalaci6n, Momento, Ejecuci6nProducci6n).
278 CAUDAD DE SISTEivV\S INFOR.J\LA. TICOS RA,1-.IA
Producci6n
Instalaci6n
CodProducto
Codlnstalacion
NombreProducto
Nombrelnstalacion
Receta
HechosProducci6n
l ~ / ~ ~
Localizacionlnstalaci6n
ConGas
1"-"-'- '"
Gestorlnstalaci6n
Oesnatado CodEjecuci6nProducci6n
Estado
UnidadProduccion CodProducci6n
GestorProducci6n Codlnstalaci6n
Momenta
CodMomento 1-
CantidadProduccion CodMomento
- Fecha
Usolngrediente
NombreMes
NumeroMes
Ingrediente
CodProduccion Ano
Codlngrediente Codlnstalaci6n
1--
Temporada
Nombrelngrediente -- ~ CodEjecuci6nProduccion
Proveedor CodMomento
Forma Codlngrediente
Ejecuci6nProduccion
UnidadMedida Temporada
CodEjecuci6nProducci6n
CosteTotal
NombreProducci6n
LineaProducci6n
CapacidadMensualLineaProduccion
UnidadMedidaCapacidad
I
Figura 10.9. Ejemplo de un almacen de datos (Adamson y Venerable, 1998)
A la hora de definir metricas para modelos de datos de almacenes de datos se
calculanln a tres niveles distintos: Nivel de Tabla, Nivel de Estrella y Nivel de Esquema
Por ello, se definen metIicas para estos tres niveles (Calero et al, 2001)
2.2.2.1. Metricas a nivel de Tabla
En la tabla 10,10 se pueden observar las metI-icas definidas a nivel de tabla y en la
tabla 10.1 L los valores obtenidos de esas metIicas para el esquema de la figura 10,9,
METRfCA DESCRIPCION
]\iA(T) Nlimero de atribulos de una tabla
0:FK(T) Numero de claws ajenas de una tabla
Tabla 10.10. Metricas a niyel de tabla.
I
TABLAS Ejecucion Hechos Uso
Produccion Ingrediente Instalaeion Momento
(T) Produccion Produce ion Ingredientes
NA(T) 7 5 5 6 5 5 7
NFK(T) 0
I
0 0 0 0 4 5
Tabla 10.11. Valores de las metricas a niYel de tabla.
I
I
I
I
CAPiTULO 10: CAUDAD DE LA Il\'FORJvlACION 279
2.2.2.2. Metricas a nivel de Estrella
A continuaci6n se detail an, en 1a tabla 10.12. las metric as propuestas para e1 nive1
de estrella, e1emento principal de un a1macen de datos.
METRlCA DESCRlPCIO:-;
NOT(S) Numero de tab las dimensionales de una estrella
NT(S) Nllmero de tab las de la estrella
NAOT(S) Numero de atributos de las tab las dimensionales de una estrella
NAFT(S) NLlll1ero de atributo;, de la tabla de hechos de la estrella
NA(S) Nllll1ero de atributos de la estrella.
?\FK(S)
I
?'\llll1ero de claves ajenas de una estrella
Ratio de atributos de la estrella. NLullero de atributos de las tab las dimensionales
RSA(S)
di\-idido por el nlllllero de atributos de las tabla de hechos
Ratio de clm-es ajenas. ?'\llll1ero de atlibutos de la tabla de hechos que son claves
RFK(S)
ajenas
Tabla 10.12. i\-Ietrica a nivel de Estrella.
En 1a tabla 10.13 se puede observar los valores de las metricas de nivel de estrella
(ver tabla 10.12) para el esquema del ejemplo que se esta estudiando.
METRIC-\.
I
NA NFK
I
RSA NOT
I
NT
I
NAOT
I
NAFT RFK
HECHOSPRODt:CCIO:-; J 28 --+ I
23;5
--+
I
5
I
7'
_J
I
5 4/28
USOI:sGREDIE:-;TE
I
35 5
I
287 5
I
6
I
28
I
7 5/35
Tabla 10.13. Valores para las metricas a nivel de estrella.
2.2.2.3. Metricas a nivel de Esquema
Por llltililO se presentan, en 1a tabla 10.14, las metricas al nivel del esquema de
a1macen de datos completo. e1 cual puede contener una 0 varias estrellas.
En la tabla 10.15 se puede observar los valores que obtienen las metricas del nivel
de esquema para e1 esquema de 1a figura 10.9.
Las metricas se han validado mediante diversos experimentos (Serrano et ai, 2002;
2004). en las que hemos obtenido que las metricas NFT (Nlnnero de tab las de hechos),
NT (Nlrmero de tablas) y NFK (Nlnnero de c1aves ajenas) parecen ser buenos indicadores
de la comp1ejidad de los almacenes de datos.
280 CAUDAD DE SISTE\lAS INFOR.\L.\TICOS
l

NFT(Sc) Nlllnero de tab las de hechos del esquema
NDT(Sc)
I
Numero de tab las de dimension del esquema
NSDT(Sc) Nllll1ero de tab las dimensionales compartidas por !11:)S de una estrella
NT(Sc) Numero de tab las del esquema
NAFT(Sc) Nllll1ero de atributos de las tab las de hechos del esquema
NADT(Sc) NllIl1ero de atributos de las tablas de dimension del esquema
NASDT(Sc) Nllmero de atributos de las tab las de dimension compartidas
NA(Sc) Nllll1ero de atributos del esquema
I
NFK(Sc) Nllll1ero de claves ajenas del esquema.
I
Ratio de de tablas dimensionales compartidas. Cantidad de tablas dimensionales que
RSDT(Sc)
estan relacionadas con mas de una estrella
RT(Sc) Ratio de tablas. Cantidad de tablas dimensionales por cada tabla de hechos
!
Ratio de anibutos del esquema. Numero de atributos de las tab las dimensionales
I
RScA(Sc)
dividido por el nllll1ero de atributos de las tablas de hechos
!
I
RFK(Sc) Ratio de claws ajenas. Nllll1ero de atributos que son claves ajenas
I
Ratio de atributos de las tab las dimensionales compartidas. NllIl1ero de atributos del
RSDTA(Sc)
esquema que son compartidos
Tabla 10.14. Metricas a nhel de Esquema
METRIC\ VALOR METRICA
I
VALOR
I
METRIC.",
I
VALOR
I
NA 40 NAFT
I
12 RSDT
I
45
I I
:
NFK 9 RFK 940 RT

NDT
I
5 NFT
I
')
I
RScA
I
2812
NT
I
7
I
NSDT
I
4
I
RSDTA
I
23140
I
I
NADT
I
28
I
NASDT
I
"
-.)
I
I
Tabla 10.15. Valores para las metric as a ninl de Esquema
\: R..-\-\!A CAPiTCLO 10: CALlD.-\D DE L-\ INFOR)'L-'..CION 281
3. CAUDAD DE DATOS
Una vez que se ha eShldiado la cali dad de los modelos de datos y como medirlo. se
atl-onta ahora el hecho de medir la calidad de los propios datos almacenados en la base de
datos. Para empezar es necesario definir el concepto de calidad de los propios datos. En la
literahlra se intenta definir este concepto en nmcion de unos deter111inados criterios. como
pueden ser el ciclo de vida de los datos (Redman, 1996) 0 los tipos de investigacion
realizadas (Huang et al.. 1999, 'Nand y Wang. 1994) 0 simplemente la f01111a en 1a que se
usan los datos (English. 1999). Pero todos los autores estim de acuerdo en que la calidad
de datos es un concepto multidimensional que comprende distintos aspectos seglm las
necesidades de los consumidores de datos 0 de los diseiladores de sistemas.
Una estrategia habitual que se suele utilizar para detel1ninar el grado de cali dad de
datos de una aplicacion es detinir un marco de trabajo para detel111inar las dimensiones de
calidad de datos para un contexto. que puede ser generico 0 bien especia1izado en un area,
y metricas asociadas a esas dimensiones. Las dimensiones de calidad de datos y de
infol111acion son criterios racionales que representan los requisitos de los mediante los
cuales es posible juzgar la cali dad de un dato. Estas a su \ez pueden dividirse en otras que
complementen su significado (ISO. 2001). Es posible llegar a necesitar un conjunto de
varias dimensiones para detinir el estado de la cali dad de datos y de informacion en una
detel111inado aplicacion (Huang et al.. 1999).
EI problema radica en la diticultad para identiticar las dimensiones de calidad para
cada uno de estos componentes. Muchos aLltores como Redman (1996). English ( 1999).
Strong et ai. (1997a) han explicado como identiticar estas dimensiones de calidad de
datos e incluso como medir ciertos aspectos caracteristicos de calidad de datos en ciertas
aplicaciones y entomos. Redman (1996) explica un procedimiento mediante el cual es
posible obtener las dimensiones de calidad de datos a partir de los requisitos de calidad de
datos de los usuarios y de la cadena de intol111acion: se retmen los requisitos de cali dad de
datos de los usuarios y se catalogan. identiticando adecuadamente las necesidades y
preferencias de todos los usuarios para posteri0l111ente intentar compatibilizarlas. Despues
de haberlas catalogado se escriben de f0I111a que los disei'iadores puedan ar'iadirlas a las
especiticaciones del sistema. teniendo en cuenta su detinicion y como afectan a los datos
existentes. Por ttltimo, se comprueba la validez de la dimension elegida. Este proceso es
iterativo hasta obtener un conjunto consistente de dimensiones de calidad de datos. Por
otro lado. Strong et al. (1997b) proponen LIl10S procedimientos de identiticacion de
dimensiones de calidad datos consistentes en aislar problemas frecuentes con los datos.
Muchas de estas metodologias de eleccion de dimensiones de calidad de datos
llevan aparejada la definicion de un conjunto de dimensiones por parte del autor que
sirven como referencia para su aplicacion. La e\'aluacion de estos marcos rev-ela con
demasiada tiecuencia que los marcos de referencia han sido definidos para un dominio.
con 10 que son nlertemente dependientes del contexto (Eppler. 2001 a). As! es posible
encontrar un catalogo de dimensiones de calidad para entomos medicos (Kosar. 1999:
282 CAUDAD DE SISTEMAS IN1'ORIvL.\ TICOS
Davidson et af., 2004), militares (Burzynski, 1998), para sistemas de apoyo a la decisi6n
(Gendron y D'Onofrio, 2002; Shankaranarayan et af., 2003), para la web (Eppler y
Muezenmayer, 2002), para pequenos negocios (Leonowich-Graham y Willshire, 2003),
sistemas cooperativos (Mecella et aI., 2002), para teolias evolucionista de la calidad de los
datos (Liu y Chi, 2002) e incluso para "COIparate Hal/seliafding" (Madnick et af., 2004).
No obstante un esquema que empieza a ser COmlll1mente utilizado para la elecci6n de las
dimensiones de calidad de datos es el propuesto por Strong et af. (1997a), donde se
establece un conjunto de cuatro categolias de dimensiones de calidad, mostradas en la
tabla 10.16:
.
C.UEGORIADt CAUDAD DE DATOS DIMENSlONES DE CALlDADDE DATOS.
Intrinsecas Exactitud, Objetividad. Credibilidad, Reputaci6n
Accesibilidad Accesibilidad. Acceso Seguro
Relevancia. Valor Afiadido. Oportunidad, Compleci6n.
Contextual
Cantidad de Datos
Interpretabilidad. Facilidad de entendimiento, Representaci6n
Representacional
Concisa. Representaci6n Consistente
Tabla 10.16. Dimensiones de Calidad de Datos de Strong et al. (1997)
De todos modos, es posible que este esquema no satisfaga con-ectamente todas las
necesidades de los usuarios (Eppler, 2003), y se podlia pretender desan-ollar un modele de
referencia universal valido para cualquier situaci6n, pero como afiTInan Pipino et af.
(2002) esto es imposible debido al hecho de que la calidad de datos y de infomlaci6n
depende fueltemente de los problemas particulares que las organizaciones tienen con sus
datos y su infoTIl1aci6n.
Otro de los problemas que se puede encontrar a la hora de definir el catalogo de
dimensiones es la cantidad de factores que pueden afectar a dicha dimension. Uno de los
casos mas impOltantes es el rol de la persona que va a utilizar el recurso cuya dimensi6n
de calidad de datos y de infoTInacion se pretende definir (Gialmocaro et aI., 1999).
Sea cual sea el metodo de elecci6n de las dimensiones, y los factores que
condicionan la elecci6n de las climensiones, el numero de las elegidas que fOTIl1aran este
conjunto debe ser 6ptimo y minimo: optimo para que represente convenientemente la
calidad de datos en la base de datos y minimo para evitar el gasto imlecesario de recursos
y la complejidad computacional.
Como se sabe, la calidad de un producto depende del proceso mediante el cual se
disena y produce el producto, as! que la cali dad de los datos estara relacionada con el
proceso de captura, de diseno, 0 de utilizaci6n de los mismos. En Wand y Wang (1996) se
GRA.-MA CAPiTULO 10: CAUDAD DE LA INFORJ'v1ACION 283
analizan algunas de las causas de la mala calidad de los datos debida a deficiencias en
disefio basandose en principios onto16gicos, vease tabla 10.17. De todos modos, hay que
tener en cuenta, desde un punto de vista practico, que las mayores deficiencias en la
calidad de los datos provienen de su no utilizaci6n. Al igual que pasa con los miembros y
6rganos del cuerpo humano, los datos que no se utilizan tenninan "atrofiandose", y su
calidad se deteriora (On, 1998).
DIMENSION CALIDADDE
NATUR."-LEZ--\ DEL-\ DEEICIE1\iOA FUENTE DELADEI'1C:!ENCIA
DATOS
."" .
Representacion impropia:
Complecion Fallo en el diseiio
Estados SI
2
ausentes
Representacion impropia:
No ambigtiedad Varios estados del MR3 mapeados al mismo Fallo en el diseiio
estado SI
Estados SI sin sentido y confusion: mapeo a Fallo en el diseiio y fallo en la
Significacion
estado sin senti do operacion
Correccion Confusion: mapeo a un estado incorrecto Fallo en la operacion
Tabla 10.17. Calidad de los datos y deficiencias del diseiio.
Dado que la calidad tiene componentes objetivas y subjetivas (Pipino et aI, 2002),
es necesario catalogar los requisitos de calidad de datos de los usuarios segun unas
detenninadas dimensiones de calidad. En Huang et al. (1999) se prop one considerar
diferentes tipos de metric as conespondientes a esas componentes: subjetivas (basadas en
el juicio de los usuarios de los datos), objetivas independientes de la aplicaci6n (como la
conecci6n) y objetivas dependientes de la aplicaci6n (especificas para un dominio
detenrunado). La tabla 10.18 muestra algunos ejemplos de dimensiones de calidad que
pueden tener una medici6n objetiva y otras que pueden tener una medici6n subjetiva.
Por tanto, las empresas tendran que, por un lado, definir una politica de calidad que
establezca las obligaciones de cada rol (en general, directivo de infonnatica, creadores y
suministradores de datos, disefiadores, operadores, etc.) con el fin de asegurar la calidad
de los datos en todas sus dimensiones; mienh'as que por otro deberan implementar un
proceso con el fin de evaluar la cali dad de la infom1aci6n de que disponen.
2 SI = Sistema de Informacion
3 MR = Mundo Real
28-1 CALlD.-\D DE SISTE\HS TICOS iZ R_-\-\!A
DI"\<IE7\5107\
:\ccesibilidad
Cantidad apropiada de datos
C omplecion
Comprenslbilidad
Credibilidad
Disponibilidad temporal
F acilidad de manipulacion
InteIlxetabilidad
Libres de en'or
ObjetiYldad
Releyancia
Reputacicin
Seguriclad
\'alor aiiadido
DEH7\ICI07\
I Los datos estan disponiblcs 0 bien son tacil y rapidamente recuperables. I
I El volumen de datos es adecuado para la tarea que se esui realizando. '
I Los datos son complctos y suficientes para la (area que se eStil desaITollando. I
I Los datos son tacilmentt: comprensibles
I Los datos pueden ser considerados como creibles y verdaderos.
I
Los datos estan 10 suficientementc actualizados para la (area que se esta
desaITollando.
Los datos son tacilmente aplicables y manipulables en diferentes tareas.
Los datos estan representados en el idioma apropiado. con una simbologia
COITecta y adecuada y con la definicion apropiada.
Los datos son COITectos y liables.
Los datos son imparciales. sin prejuicios y sin connotaciones.
Los datos son lltilcs y aplicables en la tarea ue sc esta desaITollando.
Los datos cstan representados de una fonna compacta.
Todos los datos se represcman en cl mismo tonmno. que adem,is es el m,ls '
adeeuado para la wrea que se esta desaITollanclo.
Los datos estan altamcnte rdacionados en tennino, de sus filCl1teS 0
comenidos.
EI acceso a los datos esui restringido apropiadameme para garantizar su
seguridad.
Los datos son bcndiciosos y otj'ecen wntajas alusarlos.
Tabla 10.18. Algunas dimensiones de CaUdad de Datos (Pipino et at .. 2002)
Dentro de este proceso resulta fundamental disponer de medidas 0 metricas que
pem1itan analizar y mejorar la calidad en funcion de las dimensiones de calidad de datos
identificadas.
3.1. Metodoiogia para ia medici6n de la caUdad de los datos
En este apartado se muestra una metodologia para medir la calidad de los datos
guardados en un almacen de datos. Basada en las ideas propuestas por Orman et Cll.
l 1994). que proponen almacenar informacion referente a la cali dad de los datos en la
misma base de datos. esta metodologia propone una serie de pasos bien estructurados y
definidos que. partiendo de los requisitos de ca1iclad de datos de los usuarios. trata de
identificar las dimensiones de calidad que mejor describen esos requisitos_ para despues
obtener metricas a partir de ese conjunto de dimensiones: despues se realiza el proceso de
medicion propiamente dicho. que consiste en generar un valor numerico como resultado
de un juicio de un detenninado valor del dato con respecto a la dimension elegida:
posteriormente los resultados se gum-dan en el mi5mo almacen de datos. para despues
analizar los resultados. La forma de gum-dar los datos depende fuertemente del modelo de
datos elegido para el almacen de datos.
EI objetivo fundamental de ]a metodologia que a continuacion se resume. es ofrecer
al usuario un marco de trabajo para detenninar la cali dad de los datos de una base de datos
atendiendo a la calidad de los datos propiamente dicho.
( RA-\lA
CAPiTCLO DE L\ I:-;FOR\lACIO?\ 285
Las fases de la que consta la metodologia son las siguientes:
Fase 1: Identificaci6n de los objetivos y de las medidas. Es una fase de amilisis, donde
a partir de los requisitos de calidad de los usuarios se obtendrian una serie de productos de
trabajo tras completar cada una de las siguientes actividades:
1.1. Detenl1inar el objetivo de la medicion. Se trata de detel111inar las razones por
las que se qui ere medir el nivel de calidad de datos.
1.2. Detenninar los panimetros e indicadores de cali dad. A partir de los requisitos
de los usuarios se identifican las dimensiones y metricas de calidad de datos mas
significativos para acotar el problema de calidad de datos.
1.3. Localizar los datos a valorar. Esta actividad se di\'ide en las siguientes
subactividades:
1.3.1. Detenl1inar la cantidad de datos que deben ser \alorados. Se
trataria de decidir si para detenninar la calidad de los datos hay que
tomarlos todos 0 bastaria con tomar una muestra de ellos y luego
extrapolar los resultados.
1.3.2. Localizar los datos en la base de datos. Se pretende indicar ellugar
ex acto don de logica y.o fisicamente estan los datos a valorar.
1.3.3. Elegir el momento en el que debe hacerse la \aloracion de los
datos. Puede oCUlTir que el estado de la calidad de los datos que es
verdaderamente significativo se de en un momento detenllinado. Se trata
de definir ese momento para que la medici on de la calidad sea la
apropiada.
1.3.4. Identificar las fuentes de los datos. Para comparar un valor
almacenado con el \'alor real. se necesita conocer la fuente de
informacion para preguntarle por el \;alor del dato original.
1.4. Detinicion de criterios de calidad. Se trata de establecer criterios de valoracion
para juzgar la bondad de un dato y de definir criterios de evaluaci6n para
detenl1inar la bondad del conjunto de los datos.
Fase 2: Creaci6n de una estructura de calidad. Es la fase de disefio. donde el objetivo
es dotar al almacen de datos de una estructura para guar'dar los val ores que mas tarde se
recopilaran para las medidas de calidad. En funcion del nllll1ero de veces que se haya
analizado la calidad de los datos guardados en el almacen de datos, se pueden presentar
alguna de estas tres situaciones:
286 CAUDAD DE SISTE1>L4.S lNFORJv1A TICOS
2.1. Que no haya ni siquiera almacen de datos, con 10 que sera necesario disei'iarlo
afiadiendole directamente los aspectos de calidad que se consideren mas
adecuados.
2.2. Que haya almacen de datos pero que no de soporte para los aspectos 0
dimensiones de cali dad. Lo que habra que hacer sera modificar el modelo para
dar el citado soporte.
2.3. Que el almacen de datos ya cuente con estmctura de calidad debido a analisis
realizados anteliol111ente.
En cualquiera de las circunstancias en las que haya que modificar el modelo del
almacen de datos hay que tener presente que se pueden ver afectados todos los procesos
que manejaban esos datos, pOI' 10 que se recomienda tener en cuenta todos esos cambios.
Fase 3: Medicion de los atributos de calidad. Una vez que el almacen de datos disponga
de una estmctura para guar'dar las medidas de las dimensiones de cali dad, esta fase
consiste en reunir valores para dichas medidas en las dimensiones especificadas. Puede
llegar a ser necesario que para algunas dimensiones de calidad se deba conocer el valor
del dato real y compararlo con el del dato almacenado. En funci6n de la cantidad de datos
y del nivel de calidad exigido puede ser necesario mediI' los valores de todos los datos 0
seleccionar pOl' muestreo s6le. una parte de esa totalidad. En cualquier caso estas
medici ones se guardaran en el almacen de datos.
Fase 4: Amllisis y Evaluacion de los valores de los atributos de calidad. En esta fase.
se someteran los valores individuales medidos en la fase anterior a los critelios de
valoraci6n para detel111inar el grado de bondad de un dato, y Segllll elnllmero de datos con
calidad y los criterios de evaluaci6n establecidos se juzgaran si esos datos tienen 0 no el
grado de calidad deseado. Si es as!. se celtifican los datos como validos para la aplicaci6n.
En caso contrario se desechan como invalidos. procediendo posteri0l111ente como mejor
convenga: cOlTecci6n de los datos existentes 0 captura de nuevos datos.
Com') ejemplo de metrica de calidad de datos podria darse la siguiente el Numero
de valores incolTectos para un atributo (1\TVI (A)), entendiendo que un atIibuto es
incolTecto cuando su valor no esta dentro del rango de valores de dominio definido para
ese atributo. En este rango de val ores podria estar 0 no el valor nulo.
4. EVALUACION Y MEJORA DE LA CAUDAD DE LA
INFORMACION
A medida que la Infol111atica se ha ido conviltiendo en una de las helTamientas mas
importantes para las organizaciones, el valor empresarial del software ha ido creciendo
hasta conveltirse en uno de los activos mas impOltantes a nivel estrategico (Bobrowski et
al., 1999). F recuentemente se piensa que la calidad del software es el pilar basico para que
C\PiTULO 10: C\UDAD DE LA 287
los Sistemas de Infol111aci6n que utilizan Iecnologias de Infol111aci6n (II) sean 10
suficientemente eficientes como para asegurar la supervivencia de una organizaci6n. Pero
el dia a dia de las instituciones esta demostrando que los datos que se necesitan recopilar,
almacenar y procesar para la producci6n de la infol111aci6n son tambien un factor basico
para el desanollo de sus operaciones comerciales (Eppler, 2001a; Geltz et al., 2004) ya
que datos e infol111aci6n constituyen un activo fhndamental para las decisiones tacticas,
estrategicas u operativas (Ballou y Iayi, 1999; Bovee et al., 2003; Redman, 1996; Strong
et al., 1997a).
En la actualidad, la mayor parte de las empresas yen en la tenencia de datos un
medio indispensable para hacer frente a un mercado cada dia mas competitivo (Huang et
al .. 1999). Asi, sus directivos piensan que cuanto mayor sea la cantidad de datos, mayores
seran las ventajas que supondra tenerlos. Esto se traduce numerosas veces en una obsesi6n
pOI' reunir y almacenar datos, muchas veces sin una planificaci6n previa, para poder
atender a un mayor numero de potenciales c1ientes. Este hecho obliga a las organizaciones
a tener que enfrentarse pas ado un tiempo a un grave problema de poluci6n de los datos: se
dispone de demasiados datos, la mayoria de ell os probablemente inlltiles e improductivos.
Las organizaciones estan empezando a darse cuenta de que una situaci6n de datos
con una calidad insuficiente es inaceptable (Piattini et aI., 2000a) ya que las decisiones
que pueden llegar a tomarse no seran mejores que los datos sobre los que estan tomadas
(Redman, 1996) y pOI' tanto pueden general' ciertos enores que impactaran negativamente
en la eficiencia global de la organizaci6n (Burgess et al., 2003; Kim y Choi, 2003:
Redman, 1996: Wand y Wang, 1996). Ieniendo en cuenta que un nllIllero importante de
organizaciones no tienen todavia las herramientas adecuadas para mantener un alto nivel
de calidad de datos (Kim y Choi. 2003). los equip os de gesti6n de calidad de datos y de
infol111aci6n deben ser los encargados de empezar a pres tar atenci6n a este aspecto tan
importante de las organizaciones que viene siendo descuidado desde hace mucho tiempo
(Helfert y von Maur, 2002: Hinrichs, 2000), y de extender esta preocupaci6n al resto de
los trabajadores de la organizaci6n a fin de introducir cambios y lograr compromisos que
puedan servir de base para la mejora de la calidad de los datos (Motha y Viktor, 2000). Se
sabe que el tratamiento de los problemas de cali dad de datos y la infol111aci6n es un as unto
tan importante como dificil (Ballou et al .. 2004). no es trivial, no es gratis y se requieren
muchos reCllrsos (Xu, 2003), porque, generalmente el aseguramiento de la calidad es un
proceso complejo, en el que la diferencia entre costes y necesidades de calidad queda
intimamente vinculado pOI' el contexto de aplicaci6n y pOI' los requisitos de la
organizaci6n (Bringel et al., 2004).
Se hace pOI' tanto imprescindible para el buen rrmcionamiento de los Sistemas de
Infol111aci6n de las organizaciones abordar el tema de la calidad de los datos y de la
infol111aci6n desde la gesti6n. Idealmente, deberian ser las organizaciones quienes tienen
que descubrir las causas de la pobre calidad de sus datos e institucionalizar programas de
mejora para solventarlos (Jin y EmbUlY, 2001). No obstante, cientificos, investigadores y
profesionales de empresa se han venido preocupando en esta ultima dec ada pOI' esta
288 CAUDAD DE SISTDIAS 1,\ FGR:Vl.'\ TICGS i;; R.-\-\l.-\
creciente impoltancia de la cali dad de la infol111acion; esta preocupacion ha motivado
muchas nuevas lineas de investigacion tratando diferentes asuntos de la cali dad de datos y
de la infom1acion des de distintos puntos de vista (Eppler y Wittig, 2000: Wang et 01..
1995). :\0 obstante. aim no ha sido definido un manual de buenas practicas y
procedimientos que pel111ita a las organizaciones valorar 0 mejorar un deteI111inado grado
de la calidad de sus datos de un modo integrador (Geltz et 01., 2004) que vaya mas alla de
la definicion de las dimensiones de h cali dad de los datos (Xu. 2003). Es necesario. por
tanto. mejorar la calidad de los datos y de la infoI111aciolf
1
para conseguir asi mejorar la
satisfaccion de los clientes y. al mismo tiempo. la satisfaccion del personal. 10 que hara
mejorar la organizacion en su conjul1to.
Estudiando a los autores clasicos de calidad como Deming. Juran 0 Crosby, se llega
a la conclusion de que 1a clave para 1a mejora de la cali dad de los datos y de 1a
infol111acion en las organizaciones debe hacerse a traves de dicha gestion de ca1idad (Liu y
Chi. 2002). Esta gestion de la calidad incluye conceptos y actividades como politic as de
calidad. estrategia de calidad. p1anificacion de la cali dad. control y aseguramiento de la
calidad y mejora de 1a ca1idad (Helfelt y von Maur. 2002). y como demuestra Kreut=berg
(2000) esta gestion va a tener un efecto positivo sobre 1a calidad de los datos y de 1a
inf01111acion. Estas acti\'idades necesitan encuadrarse en un marco de trabajo que pel111ita
evaluar y mejorar la calidad de 1a infol111acion de una f01111a integradora a traves de una
gestion proactiva: coordinando y organizando todos los recursos (incluyendo humanos.
software. hardware. datos e infol111acion). a traves de un camino. en e1 que teniendo
conocimiento sobre 1a organizacion y sobre los "procesos de/cilwicacion de informacion"
(\Vang. 1998) se pueda alcanzar cielto grado de eficiencia en e1 tratamiento de sus datos.
Muchos de estos esfberzos comienzan con la evaluacion/va10racion del estado actual de 1a
calidad de los datos y de 1a infol111acion y continLtan con la optimizacion de los
procedimientos. A pesar de que algunas investigaciones proporcionan varias medidas para
la valoracion de la calidad de 1a infol111acion y metodologias para la valoracion (English.
1999: Eppler. 2003: Huang et 01 .. 1999: Lee et al .. 2001: Olson. 2003: Redman. 1996:
\Vang et al .. 2001). ninguna de ell as trata como optimizar la calidad de la infom1acion
coordinando grupos de esfuerzos 0 compromisos que alcancen a las organizaciones
completamente tanto de manera pragmatica como analitica (Eppler y Wittig. 2000). Es
posible afiI111ar que estos marcos de trabajos son fueiteS bien desde un punto de vista 0
desde el otro. pero rara vez abarcan los dos a la vez. son demasiado dependientes del
contexto y. en la mayoria de los casos. demasiado centrados en aspectos concretos de
dichos contextos.
En los siguientes subapartados se \'an a mostrar algunos de los proyectos. entomos
o iniciati\'as mas imp01tantes en la gestion de 1a calidad de los datos y de la infol1113cion.
c ExistCll otros estudios a mejorar la calidad los modelos conccptuales de datos como
Calero ct (il. (200 l) 0 Gen<.?ro (2002). Esta tesis csta oricntada al <.?studio la cali dad de los propios datos y de
la inlormaci6n.
\: R.-\-'.lA
Se comenzani por TDQM (Wang. 1998) desatTollado en el MIT como uno de los
marcos mas ampliamente aceptados por la comunidad investigadora y por las empresas. y
que supone la base de otros proyectos como DaQuincis. desalTollado en la Universidad de
la Sapienza de Roma (Missier y Batini. 2002) 0 TQdM, desalTollado por English (1999).
Tambien se incluyen otros marcos de especial importancia como AIMQ (Lee et al., 2002)
o IP-MAP (Shankaranarayan et al .. 2000) desalTollados dentro del ent0l110 de TDQM. Es
impOitante resaltar la inclusi6n del marco de Eppler (2003) por ser el de mas reciente
publicaci6n. Otro de los marcos a tener en cuenta pero que no va a ser incluido pOl'que no
se centra en la calidad de los datos y de la infol1naci6n. sino s610 en la calidad de
almacenes de datos es el proyecto ESPRIT 22469 DWQ
(http:;!w\\w.dbnet.ece.ntua.gr-d\yqf) desatTollado en la Uni6n Europea (Jarke y
Vassiliou. 1997). Finalmente. y como contribuci6n del Grupo Alatcos a este campo, se
incluira un marco de evaluaci6n y mejora basado en modelos de madurez. al estilo de
CMM1.
4.1. Metodoiogia TDQM
<
El fundamento de este proyecto norteamericano soportado por el Massaclzllssets
Institllte of'Technology (MIT - httl!web.mit.edwtdqm) es considerar la infol1naci6n
como resultado de un proceso de producci6n: para mantener una alta calidad de los
productos de inf0I111aci6n es necesario definir. medir. analizar y mejorar continuamente la
calidad de la infol1naci6n. Para esta mejora continua. Wang (1998) establece como
principio te6rico basico el ciclo de Deming adaptado '-, la producci6n de informaci6n.
La metodologia TDQM consta de cuatro pasos principales. que se repiten en un
bucle celTado siguiendo el ciclo de Deming (Deming. 1986) PlclI1ifical'-Hacer-
C olllprobal'-Actllal' (Plan-Do-Check-.4.cf;:
I!J Definicion del Producto de Informacion. Se identifican los principales
productos de inf0l111aci6n cuya calidad de informaci6n es basica para las
necesidades de los usuarios: tambien se identifican aquellos requisitos de
calidad de informaci6t:. segll11 los cuales los usuarios deben enjuiciar la calidad
de los citados productos de infol1naci6n. Las caracteristicas del producto de
informaci6n deben ser definidas en dos niveles:
c: En un nivel superior. el producto de infOI111aci6n es conceptualizado en
tel111inos de sus funcionalidades para los consumidores de informaci6n.
C) En un nivel inferior. se deberian identificar los elementos basicos del
producto de informacion y sus componentes.
G Medicion del Producto de Informacion. En esta fase el objetivo es identificar
las metric as de calidad de infOimaci6n mas eficientes para medir dicha cali dad
y proceder a su medici6n. La clave para medir reside en el desaJTollo de las
metric as de cali dad que se obtienen a pattir de las dimensiones de calidad de
datos. tales como precision. exactitud. etc. Estas metricas pueden calcularse a
290 CAUDAD DE SISTEMAS INFORIvL4 TlCOS
!{.A,.-MA.
partir de los propios datos almacenados en la base 0 almacen de datos, aunque
a un nivel mas complejo, pueden definirse reglas de negocio que necesiten ser
observadas.
$ Amilisis del Producto de Informacion. Consiste en el desan"ollo de un
amilisis diIigido por datos y por procesos para descubrir las causas de la pobre
calidad de los datos en los productos de infonnaci6n seleccionados. A partir de
los resultados de las metricas, se POrn"a investigar las causas potenciales de los
problemas de calidad de datos. Los metodos y helTamientas para desarTOllar
esta tarea pueden ser simples como una inspecci6n visual 0 complejos como el
cOlmol estadistico de proceso.
$ Mejora del Producto de Informacion. Cuyo plincipal objetivo es disefiar e
implementar estrategias para mejorar la calidad de infonnaci6n de los
productos de infol111aci6n sobre las causas encontradas en el paso anterior. Una
vez que la fase de analisis esta completa, entonces puede comenzar la fase de
mejora. El equipo del Producto de infonnaci6n necesita identificar las areas
claves para las mejoras. como el alineamiento del flujo de la infol111aci6n y del
flujo de trabajo con la infi"aestructura de la organizaci6n y el realineamiento de
las caracteristicas de la infonnaci6n con las necesidades del negocio.
4.2. Metodologia de Evaluaci6n AIMQ
Fue propuesta por Lee et al. (2002). Parten del hecho de que la calidad de la
infonnaci6n se ha conveltido en un factor critico para las organizaciones y en una area
activa de investigaci6n en el campo de Gesti6n de Sistemas de Infonnaci6n (Management
b?formation Systems - JiflS) Y que con el crecimiento de los almacenes de datos y el
acceso directo a la infol111aci6n desde varias y diversas fuentes por gestores y usuarios se
ha incrementado la necesidad de tener cuidado de la calidad de la infol111aci6n en las
orgal11ZaClones.
Justifican su propuesta basandose en que a pesar de una decada de investigaci6n y
experiencias, s6lo han podido desauollarse tecnjcas propietarias para medir, analizar y
mejorar la calidad de los datos en las organizaciones, pero las organizaciones deberian
tener un banco de pruebas (benchmark) que pennita comparar sus esfuerzos con los de
otras organizaciones. Sin la capacidad de valorar la calidad de su infol111aci6n las
organizaciones no pueden detelminar 0 estimar el estado de su organizaci6n con respecto
a la calidad de la infonnaci6n para monitOlizar su mejora. Para ellos, el reto de la
investigaci6n consiste en desauollar un modelo global con un instrumento de medici6n de
la calidad de infonnaci6n. El reto the matelializado en una metodologia llamada
Assessment and Improvement Methodology for Quality (AIMQ), que proporciona, seglll1
sus autores, una base rigurosa y pragmatica para la valoraci6n de la calidad de la
infolmaci6n. Consta de tres elementos:
{;; R/\.-MA CAPITULO 10: CAUDAD DE LA 291
e Un modele de las medidas que son lltiles a los consumidores y a los gestores de
infonnacion. Este modele tiene cuatro cuadrantes, dependiendo de si la
infonnacion es considerada como un producto 0 como un servicio; y de si las
mejoras pueden ser valoradas como especificacion fonnal 0 como expectativas
del c1iente
e El segundo componente es un cuestionario para medir la calidad de la
infonnacion a traves de las dimensiones de cali dad que son consideradas
impOltantes tanto para los consumidores como para los gestores. Varias de
estas dimensiones juntas miden la calidad de la infonnacion para cada
cuadrante del modele anterior. Este instrumento puede ser aplicado para
valorar la cali dad de la infonnacion en las organizaciones.
e El tercer componente de AIMQ consiste en dos tecnicas de analisis para
interpretar las valoraciones obtenidos por los cuestiOnaI10s. Estas dos tecnicas
ayudan a las organizaciones a enfocar los esfuerzos para mejorar la calidad de
los datos. La primera tecnica compara la calidad de la infol111acion con los
resultados de un banco de pruebas de mejores practicas de una organizacion.
La segunda tecnica mide las distancias entre las valoraciones de los diferentes
implicados en un sistema de produccion de infol111acion.
4.3. IP-MAP: Representacion del Producto de Informacion
Este ent0l110, propuesto por Shankaranarayanan et at. (2000) y vinculado con el
proyecto TDQM. considera la creacion de la infonnacion como si fuera un producto de
inf0l111acion. Los autores se basan en que aunque ha habido intentos de desaITollar
modelos para la produccion de sistemas de infol111acion, cieltos aspectos cIiticos de las
fases del desanollo de un producto de inf0l111acion dentro del sistema de infol111acion
todavia no han sido atendidos. Casi todos son incapaces de representar sistematicamente
el proceso de produccion y tienen deficiencias en constructores para representar
explicitamente los detalles de produccion. Los autores proponen un mapa para los
productos de infonnacion (IP-MAP) como un metodo para representar sistematicamente
la produccion de los productos de infol111acion, que :oerviIia como base sobre la cual se
pueden elegir las dimensiones de calidad.
Esta representacion ofrece distintas ventajas. Primero, usando esta representacion,
el gestor del producto de infonnacion debe ser capaz de visualizar las fases mis
impOltantes en el proceso de produccion e identificar las fases cIiticas que afectan a su
calidad. Segundo, la representacion conceptual debeIia pel111itir a los gestores de
productos de infonnacion cenh'arse en los problemas ocasionados en los cuellos de botella
de los sistemas de produccion de infonnacion y estimar el tiempo para desan'ollar cada
uno de los productos. Tercero, basandose en los principios de mejora continua para los
procesos implicados. la representacion del IP-MAP debeIia no solo ayudar a identificar a
los propietaI10S de los procesos en cada una de las fases, sino adel11i:'ls ayudar a
292 CAUDAD DE SISTE:-'L-\S I?--:FORYL'\ TICOS
implementar la calidad en las fuentes de los datos. CUaIto. la representaciol1 pe1111itiria a
los gestores de los productos de i11f01111acion entender las unidades organizacionales de
negocio como los limites del sistema de info1111acion traspasados por los distintos
procesos usados en la produccion del IP. Finalmente. pennite la medida de la calidad del
IP en las distintas fases del proceso de produccion usando las dimensiones de calidad
apropiadas.
El marco propuesto por IP-MAP. tiene por tanto como objetivo la creacion de una
representacion sistematica para la captura de detalles asociados a la produccion de un
producto de inf01111acion. Los objetivos de esta representacion son los siguientes:
 Ofrecer un conjunto de construcciones que faciliten la representacion de los
pasos implicados en la produccion del IP. Estas construcciones ayudan a
modelar los distintos pasos del proceso de produccion y ayudan al modelador
en su visualizacion. La representacion sirve como modelo conceptual para la
produccion del producto de infon11acion.
 La representacion pennite al modelador ex.a111inar criticamente los pasos en el
proceso de produccion. Estos pasos incluyen la llegada de elementos de datos
(materias primas). la localizaci6n para el almacenamiento de estos datos. los
procesos impJicados en la creaci6n. conYers ion y 0 ensamblaje de estos 0
nuevos elementos de datos. y los procedimientos para la eyaluaci6n del
producto de infon11aci6n. Aqui el modelador.usuario puede localizar las
Fuentes potenciales de problemas de calidad de informacion y 10 mas
importante. disei'iar procedimiento para rectificar estos problemas asegurando
as! una alta calidad del producto de informaci6n.
 Ademas pem1ite al modelador implementar la calidad de info1111aci6n en la
fuente. Pem1ite asignar las responsabilidades de asegurar la calidad del
producto de infom1acion.
 Finalmente. ofrece una representaci6n que puede ser us ada para \alorar la
calidad de un producto de informacion basada en las dimensiones de calidad de
in1'o1111aci6n seleccionadas.
La principal critica que se Ie ha impuesto a IP-NIAP es que no prop one ninguna
metodologia de eyaluacion y mejora. sino un modelo que permite representar
adecuadamente la construcci6n de un producto de informacion
4.4. Metodologia TQdM (English, 1999)
A continuacion se presenta un resumen de la metodologia TQdM (Toto! QlIality
data MOllagcmcnrj recogida por LallY English en su libro Improving Data \Yarehouse
and Business Quality (English. 1999).
( R.-\-'\L-\ C.-\PiTCLO 10: C.-\UD.-\D DE LA ['\FOR.\!ACrO" 293
TQdM se traduce en la mejora continua de dos categorias de procesos:
Ii) Procesos de desalTo[[o de sistemas de infolmaci6n para definir informaci6n.
desalTo[[ando e implementando procesos de negocio. sistema de infol111acion. y
arquitectura de infol111aci6n y bases de datos.
Ii) Procesos de manufacturaci6n y negocios que crean. actualizan y bOll'an datos.
distribuyen 0 repa11en infol111aci6n y recuperan 0 presentan infolmacion a los
productores de infoll11acion 0 a los trabajadores del conocimiento.
TQd?vI busca conseguir estos objetivos integrando los principios y IIl1itodos de
calidad en Ia cllltlira de Ia empresa.
La gestion de Ia calidad de la infolmacion consta de cinco procesos de medida y de
mejora de la calidad de la informacion y un proceso que abarca a toda Ia organizaci6n
para crear un ent0l110 de calidad de informaci6n.
Los procesos de valoracion y mejora de los procesos de calidad que constituyen Ia
metodologia TQdM son:
" Proceso 1: Valoracion de ia CaUdad de Definicion de Datos y de [a
Arquitectura de ia Informacion. EI proceso de medida de Ia definici6n de
datos y de Ia arquitechlra de Ia informaci6n es el predecesor de Ia medida de Ia
calidad de la infoll11aci6n. No se puede medir Ia calidad de un producto sin
saber que las especificaciones de los productos son tan exactas como deberia
ser. A fin de medir la cali dad de la infol1naci6n en una base de datos 0 en la
salida de un proceso, hay que analizar primero la calidad de la definicion de los
datos y de la arquitectura de Ia informac;6n. Los pasos de este proceso son los
siguientes:
c
Identificar las medidas de calidad de definicion de datos.
Identificar los grupos de infoll11acion a valorar.
Identificar a los implicados en la informacion.
Valorar Ia calidad tecnica de la definicion de los datos.
Valorar Ia calidad del disei'io de Ia base de datos y de la arquitechlra de Ia
informacion.
Valorar Ia satisfacci6n de los c1ientes con Ia calidad de Ia definici6n de
datos.
" Proceso 2: Valoraci6n de Ia Calidad de Ia Informacion. EI proceso de medir
la cali dad de la informaci6n es ana logo al de Ia medici6n de Ia calidad de un
producto manufachlrado. Existen medidas tecnicas de confoll11idad con las
especificaciones y de disminucion de variabilidad con respecto a los productos
desalTo[[ados. Hay modos de medir el grado de satisfacci6n de los clientes con
294 CAUDAD DE SISTEMAS TICOS @RA.-MA
respecto a sus expectativas sobre el producto. Los ocho pasos de este proceso
son los siguientes:
o Identificar los grupos de Infonnacion que deb en ser valorados.
o Establecer las medidas y los objetivos de la calidad de informacion.
o Identificar el valor de la info1TI1acion y la cadena de costes.
o Detenninar los ficheros 0 los procesos a valorar.
o Identificar las fuentes de validacion de datos para valorar su exactitud.
o Extraer muestras aleatorias de datos.
o Medir la calidad de la infonnacion.
o Infonnar e interpretar adecuadamente la cali dad de infonnaciOn.
e Proceso 3: Medida de los costes de la No CaUdad. Uno de los mitos de la
calidad de la infonnacion es que los costes producidos por una pobre calidad
de infonnacion 0 por la falta de ella no pueden ser medidos. Sin embargo estos
costes S1 que pueden ser analizados y medidos en tenninos de beneficios
reducidos 0 de no ingresos. EI proceso desalTollado en esta etapa describe
como medir y cuantificar los costes debidos a la falta de infonnacion. Se
establecen los casos de negocio para la gestion de la infolmacion y para la
mejora de la Calidad de Infonnacion. Este proceso consta de seis pasos que
toman como entrada resultados de los dos pasos anteriores y que producen un
an3.lisis del valor de la infonnacion y de la cadena de coste. Los pasos de este
proceso son los siguientes:
o Identificar medidas de desalTollo de negocio.
o Calcular los costes de infonnacion.
o Calcular los costes de la falta de cali dad de infonnacion.
o Identificar segmentos de clientes.
o Calcular el valor del tiempo de vjda del cliente.
o Calcular el valor de la infonnacion.
e Proceso 4: Reingenieria y Limpieza de Datos. EI proceso de reingenieria y
limpieza de la info1TI1acion es aqueI en que se mejoran los productos de
infonnacion. Sirve para tomar los datos elToneos y cOlTegir sus deficiencias
para llevarlos a un nivel adecuado de calidad. Los datos limpios quedan
cOlTegidos. Los datos que no pueden limpiarse deben desecharse 0 identificarse
como no cOlTegidos. Este proceso consta de nueve pasos que toman como
entrada las salidas de los procesos anteriores y produce distintas salidas. Los
pasos de este proceso son los siguientes:
o Identificar las fuentes de datos.
R;\-MA CAPiTULO 10: CAUDAD DE lA INFOIUvV\CION 295
o Extraer y analizar datos de fuentes.
o Estandarizar Datos.
o COlTegir y completar los datos.
o Comparar y consolidar los datos.
o Analizar los tipos de defectos de datos.
o Transfonnar y mejorar los datos en los objetivos.
o Calcular las derivaciones y resumen de los datos.
o Auditar y controlar la extracci6n, transfonnaci6n y carga de datos.
II Proceso 5: Mejora de la calidad de los Procesos de Informacion. Este
proceso analogo al anterior se centra en mejorar la calidad de los procesos que
usan datos de la organizaci6n para producir datos nuevos 0 para presentarios a
los trabajadores del conocimiento para su posterior amilisis. Los pasos del
Proceso seran los siguientes:
o Seleccionar los procesos para la mejora de la calidad de la infonnaci6n.
o DesalTollar un plan para la mejora de calidad de infonnaci6n.
o Implementar las mejoras de la calidad de infonnaci6n.
o Comprobar el impacto de las mejoras de la calidad de la infol111aci6n.
o Actuar para estandarizar la mejora de la calidad de la infon11aci6n.
II Proceso 6: Establecimiento del entorno de calidad de informacion.
Representa los requisitos sistematicos, culturales, de gesti6n para la creaci6n de
lm entOl11O de calidad de infonnaci6n. Sin un entomo de estas caractensticas,
las iniciativas para dicha calidad de infon11aci6n no pasanl.n de ser esfuerzos
puntuales que no prosperaran hacia una cultura de cali dad en el entomo
empresarial a largo plazo que busca todo proceso de calidad. Lo que se busca
es que cada individuo de la organizaci6n sea responsable de sus propios
productos y procesos de infol111aci6n, para.lo que se requiere:
o Comprender la cadena de valor de la infonnaci6n y el hecho de que cada
empleado es independiente de los productos de infonnaci6n de otros
empleados para desalTollar con exito sus objetivos.
o Perfilar COlTectamente quienes son los clientes de la infon11aci6n y que
esperan de los productos de infonnaci6n.
o Fon11ar a todos los empleados en el campo de la calidad mediante cursos
y haciendo que dispongan de toda la documentaci6n necesaria para saber
en to do momenta c6mo deben hacer 10 que tienen que hacer.
296 CAUDAD DE SISTE\ !'-\S IMOR\ \...\ TICOS RA-\lA
o Ai'iadir a los objetivos de la empresa la satisfaccion tanto de los clientes.
como de los de la empresa. y entre ellos los que son mas
importantes desde el punto de vista de la calidad de la infonnaci6n: los
trabajadores del conocimiento.
Es un proceso transversal que tiene raices en los cinco procesos anteriores. Los
pasos de este proceso son los siguientes:
o Dirigir una valoraci6n del grado de madurez de la gestion de la calidad
de la infonnacion.
o Crear una vision. mision y objetivos.
c; Identificar y enfatizar el rol de lider de calidad de infonnacion.
o Diligir una valoraci6n del grado de satisfaccion de los clientes.
o Identificar otras transrormaciones de negocio. iniciativas de mejora 0
recursos extel110s.
o
o
o
o
o
o
o
Seleccionar un proyecto piloto. pequei'io y manejable.
Definir los problemas de negocio y medidas necesarias para resolverlos.
Detlnir una cadena de valor y desanollar un imentario de datos.
Desanollar una \aloracion de la calidad de la int0l111acion.
Calcular el \'alor del tiempo de vida del cliente.
Cuantificar los costes de la no calidad en la info1111aci6n.
Desanollar lazos de contlanza con los patrocinadores.
Deilnir los roles y la plantilla de calidad.
Deilnir principios. procesos y objetivos de calidad de datos.
Analizar las batTeras sistemitticas.
Ofrecer una iC1l111aci6n tonnal en :esti6n de calidad de iniol111aci6n para
los directivos.
Dirigir un proyecto de mejora de iniol111aci6n.
s Establecer mecanismos regulares de comunicacion. educaci6n e
implicacion de los directivos .
. :) :Vlantener los procesos de mejora continua para la calidad de los datos.
CAPiTULO 10: CAUDAD DE LA 297
4.5. Proyecto DaQuincis (Misier y Batini, 2002)
El proyecto DaQuincis es un desalTollo conjunto
del Departamento de Infonmitica y Sistemas de la Universidad de "La Sapienza" de
Roma, del Departamento de Electronica e Infonnacion del Politecnico de Milan y del
Depattamento de Sistemas de Infomlacion y Comunicaciones de la Universidad de Milan
Bicoca.
Missier y Batini (2002) muestran a traves de la coleccion de documentos
del proyecto DaQuincis la justificacion de su
trabajo. Para ellos, los sistemas de infonllacion que son gestionados de fonna autonoma
por diferentes organizaciones pueden cooperar en procesos de negocio distribuidos y que
se ejecutan entre distintas organizaciones, en los cuales la infonnacion se produce y se
consume de manera compleja por cada una de las organizaciones. Para ella introducen el
concepto de sistema de info1Tl1acion cooperativo (CIS) como "aquel sistemaformado por
WI conjzmto de organizaciones que cooperan a trm'es de IIna infi"aestructllra softH'Gre de
C0ll11lllicacion, qlle pllede ofj'ecer servicios sofhmre, denominados senoicios de
iJ?fraestructllra, a las OIgani:::aciones a fI'Gves de COllllillicacionesfiables ".
Parten de la base de que las teorias tradicionales de gestion de calidad de datos no
dan soporte suficiente para la gestion de la infom1acion en estos tipos de sistemas, por 10
que a pattir de la metodologia TDQM (Wang, 1998) desatTOllan un marco homogeneo
para la gestion de proyectos de calidad de infom1acion en entomos cooperativos.
Los autores proponen un marco basado en TDQM (Wang, 1998) que esta fom1ado
por los siguientes pasos:
1. Determinar el alcance del Proyecto, Este paso tiene como objetivo detenninar
que Productos de Infonnacion estan dentro del a1cance del proyecto y por que.
Las actividades que hay que realizar son las siguientes:
1,1. Identificar los productos de infom1acion criticos.
1.2. Realizar un anaIisis dirigido por datos de los productos de Infolmacion.
1.3. Realizar un anaIisis dirigido por procesos tie los productos de infonllacion.
2. Analisis: Detem1inar como someter a los productos de infol111acion seleccionados
al control de calidad. Las actividades de este paso son los siguientes:
2.1. AnaIisis de los Requisitos de Calidad de Infom1acion. Define el concepto de
"adecllado para Sll IIS0 .. para cada uno de los elementos de datos recopila-
dos en el a1cance.
2.2. Analisis de las oportunidades y planificacion eSh'ategica. Los entomos ope-
racionales ofrecen diferentes oportunidades para la gestion de calidad. Da-
dos un entomo especifico y un conjunto de requisitos de calidad de datos, el
objetivo es detenllinar una eSh"ategia y h"azar un plan para la gestion de cali-
dad de infol1nacion.
298 CAUDAD DE SISTDIAS
Analisis de costelbeneficio. Los niveles de calidad exigidos por los requisi-
tos de calidad de infOlmaci6n garantizan una serie de beneficios organiza-
cionales. EI objetivo de esta actividad es encontrar un equilibrio entre costes
y beneficios.
3. Planificacion del Proyecto tecnico. Define un plan para el proyecto tecnico que
pennite implementar las estrategias propuestas. Debe tener en cuenta todos los requi-
sitos tecnicos derivados de la planificacion estrategica. Algunos de los elementos
mas relevantes del entomo son los siguientes: requisitos tecnicos detenninados por el
analisis de la estrategia y por los patrones de mejora de calidad.
4. Implementacion del Plan y ejecucion. Comprende las siguientes actividades:
4.1. Monitorizaci6n de los niveles de calidad. El plan del proyecto detenninada
el modo y frecuencia en el que deben monitOlizarse los niveles de calidad.
Un sistema en operaci6n debe satisfacer este plan usando los procedimientos
implementados.
4.2. Gesti6n de las operaciones del sistema. Gesti6n ordinaria a nivel de sistema.
5. Valoracion de los niveles de Calidad de Informacion y seguimiento del proyecto.
Un analisis posterior basado en datos de monitorizacion analiticos. Ofrece un enlace
desde el desanollo de esh'ategias de infom1aci6n regresando a las fases previas que
han sido discutidas.
4.6. Marco de Trabajo de Eppler (2003)
EI marco propuesto pOI' Eppler (2003) se centra en los procesos intensivos en
conocimiento (h'aducido de KnoH'iedge-intensil'e process). Un proceso intensivo en
conocimiento podria definirse como "ulla sel'ie productim de actividades que implicCin
tl'Clns/ol'llIacion de ia in/o/'lllClcion y l'eqlliel'en WI conocimiento projes iOllai
especiaii::ado ".
Eppler (2003) propone un marco que deberia ayudar a pensar mejor sobre los
problemas y seleccionar la mejor soluci6n entre las distintas altemativas eSh'ategicas. Para
desanollar este marco se impuso una serie de condiciones que deberia satisfacer:
o Deberfa ayudar a identificar los problemas de calidad de datos y de
infonnaci6n de una fom1a mas sistematica y mas comprensiva,
o Deberia habilitar un modo de analizar esos problemas con mas detalle y rigor y
detem1inar sus CclUsas potenciales.
o Deberia ser lltil para evaluar 0 monitorizar las soluciones a los problemas de
calidad de infonnaci6n.
R.'\-yl.-'.. CAPiTULO 10: CAUDAD DE LA 299
e Deberia ofi-ecer medidas para disei'iar y gestionar soluciones sostenibles
basadas en las conclusiones obtenidas a partir de un amllisis de las medidas
tomadas en las dimensiones de calidad.
e Deberia servir tambien como un instrumento de fonnaci6n en el aprendizaje y
aplicaci6n pnictica de los conceptos de calidad de infonnaci6n.
A continuaci6n se exponen los elementos que el citado marco debe poseer.
4.6.1. ELEMENTOS DEL MARCO Y CRITERIOS DE CALIDAD
I
Los elementos que Eppler propone para este marco son los siguientes (vease figura
10.10):
.
e Una estructura vertical con cuatro vistas 0 niveles de calidad de infonnaci6n
que categOlizan los criterios cruciales de calidad de infonnaci6n para la
comunidad destino del marco, el producto de infonnaci6n, el proceso de
infol111aci6n y la infraestnlchlra.
e Una estruchlra horizontal dividida en cuatro fases que representan el ciclo de
vida de infol111aci6n desde el punto de vista de un usuario.
IDE:-;T1FICICle):"\ EUU:.ICIO:-; LOCALlZACIO:"\ ApUCACIO:-;
PRI:<OCIPI
I I
hTEGILICIO:-;
II
YALID.\CIO:<o
II
CO:<OTEXTO
II
ACTIYACIO:-;
I
'.' ,- . ....
}
hFOlnIACIO:-;
I
CO'IPRE:-;SIVO EXACTO
I
CLARO
I
,IPLICABLE
I

RELEVA:-;TE
""
y
I
'"
"-
I I
:0:-
hFOR'LICIO'i
I
CO:"\ClSA /

I/CORRECTO
ACTCIL
-:
BLT';A

"C.
I I
" PROCESO CO'iv['ilE'iTE OPORrr'iO

SEGll'll['iTO
I
!'iTER ICHI I
Onnlll.IDO

:}
I'iFRAESTRLCTL'RA
I
ACCESIBLE
I
SEGrRA
I I
[
'IA'iT['ilBLE R \PlD \
'"
FLIBLE
-'.

Figura 10.10. Marco de Referencia de Calidad de Informacion (Eppler. 2003)
Los recuadros con el fondo en gris claro son dimensiones de calidad relativas al
contexto. los que tienen el fondo blanco son dimensiones relacionadas con el tiempo, los
que tienen el fondo gris oscuro son dimensiones relacionadas con el fon11ato de la
infon11aci6n. Las flechas representan conflictos potenciales entre las dimensiones.
En la maYOlia de los marcos de cali dad de datos y de infon11aci6n propuestos en la
literarura, sus respectivos autores proponen las dimensiones de calidad agrupadas en
300 CAUDAD DE SISTEMAS INFORMATICOS
categorias. 10 que Ie resta aplicabilidad. En su marco, mas que categOlias, Eppler. 10 que
prop one son vistas 0 perspectivas de la calidad de la infonnaci6n. Estas cuatTo
perspectivas son las que cOlTesponden a los Plincipios de gesti6n: inf0l111aci6n relevante,
infonnaci6n buena (en el sentido de estar libre de fallos), proceso optimizado, y fiabilidad
de la infraestructura. Estas pueden agmparse en dos bloques: calidad del contenido (que
agmparia infol111aci6n relevante), y calidad de los medios (que agruparia proceso
optimizado e infraestmctura fiable).
4.6.2. P ASOS EN EL MARCO DE EPPLER
El marco en sf consta de cuatro pasos. La estruchlra vertical del marco refleja una
secuencia crono16gica 0 fases desde el punto de vista del usuatio. que tiene los cuatro
siguientes pasos (figura 10.11):
o La fase de identificaci6n consiste en localizar la fase donde la infol111aci6n y el
dominio en el que se encuadra. as! como los recursos cOlTespondientes.
o La fase de evaluaci6n consiste en un conjunto de actividades que ayudan
juzgar mejor la bondad y la relevancia de la infonnaci6n identificada y de la
fuente de la que proviene.
o La fase de 10calizaci6n contiene un conjunto de actividades que ayudan a
adaptar la infol111aci6n al nuevo contexto de aplicaci6n. reduciendola,
ampliill1dola, 0 cambiando su f0l111at.o original.
o La fase de aplicaci6n es en la que la infonnaci6n es puesta en usc, directamente
o tras un periodo de fonnaci6n adecuado.
[DE'iTIFICACIO'i EVALL\CIO'i
I..: fa
crcdihilidad elt.' hIJilt!n!r.:
dt! fa honda"
.1' rt:ft!l',mcia dt! fa h?/hrma-
cic)n.
I
! E,',,/w.1L.'ifJn dr.' la dc{/{alidad
l'dt! la COl1sislt!!1cia.
Comparacicjn cull olras.!Uf.:'/1-
les
LOC\UZACIO'i
CO!1h!rsilm Lk{formalO de
R..:ducci6n dt..'! a/cane..: d,.,' fa
jilt/nIt!
ReCOf?tigurochJn dt! /a

Etrt!,,-,"i!JI1 y t.'l1riLjuecimi:..'f1!O
de /,1 ilUcJ}"macicin
'-\PLlCACIO'i
/11lt..'ruccit;n con /0
Ohl..:m:i()n clL' conell/siones d
portir dt.' la
L ",ili::acj(jn de fa
para id rt.' ...ofllchJn cit}
proh/ellIus.
L "rili:acit!n cOlic/ialla cit! fa
h!/iJrnlachjn
Figura 10.11. CicIo de utilizacion de la informacion (Eppler, 2003)
En cada una de las fases, las caracteristicas, criterios 0 dimensiones de calidad que
el autor ha identificado. son importante los siguientes criterios (vease figura 10.11):
o Para la fase de identificaci6n. es necesario que la infollnaci6n tenga las
caracteristicas de comprensibilidad. sea concisa. conveniente y accesible.
G R.".-MA CAPiTlJLO 10: CAUDAD DE LA 301
Para la fase de evaluacion. se exige que la infonnacion sea precisa, consistente,
oportuna y segura.
Para la fase de localizacion. es importante que la infor111acion sea clara,
con'ecta, susceptible de hacer un seguimiento y mantenible,
 Finalmente, para la fase de aplicacion, se exige que la inf01111acion sea
aplicable, actual, interactiva y nipida.
4.7. CALDEA Y EVAMECAL
Nos propusimos desaITOllar un marco de h'abajo para la evaluacion y mejora de la
calidad de los datos y de la infonnacion que supliera las deficiencias de los presentados
anteri01111ente y que ademas, cumpliera las condiciones que Eppler y Wittig (2000)
imponen para un buen marco de h'abajo de calidad de datos y de la inf01111acion:
 Debe proporcionar un conjunto sistematico y conciso de criter10s con los que
se pueda evaluar los datos y la inf01111acion.
 Debe proporcionar un esquema para analizar y resolver problemas de calidad
de datos y de inf01111acion.
 Debe proporcionar las bases para la gestion de calidad de los datos y de la
infonnacion y para una gestion proactiva.
 Debe proporcionar a la comunidad investigadora un mapa conceptual que
pueda usarse para eshucturar varias teorias y fenomenos relacionados con la
calidad de datos.
Como se sabe, un sistema de Informacion puede verse como un conjunto de
procesos de Produccion Chorizontales") que son conh'olados por distintos procesos de
gestion de calidad ("verticales"). Una de las ideas basicas de esta propuesta es considerar
la infor111acion como el valor afiadido a los datos que alguien obtiene cuando usa un
producto de datos (Eppler, 2001 b). Un producto de datos, como 10 define Wang (1998), es
el resultado de un proceso de h'ansf01111acion (produtcion) de datos, en el que los datos
son considerados como la materia prima en el proceso de produccion (Ballou y Tayi,
1996; Huang et al., 1999; Wang, 1998), aunque los datos tengan caracteristicas diferentes
de las mater1as primas tradicionales (Ballou y Tayi, 1999). El asunto fundamental de la
cuestion pasa por modelar 0 definir ese proceso de produccion de infonnacion y como
gestionar la cali dad de los productos que genera, ya que la cali dad de un proceso depende
de su disefio y de su operacion (Dedeke, 2003). Esta analogia de infol111acion con
productos, y de datos con materias primas, pennite aplicar los principios clasicos de
gestion de calidad de productos ala gestion de calidad de los datos (Firth y Wang, 1993) y
de infor111acion des de un punto de vista ingenieril, como han suger1do algunos autores de
fonna implicita 0 explicita (como Bobrowski et al., 1998). Para que pueda decirse que un
producto de datos tiene cali dad, debe satisfacer todos los requisitos del cliente (Crosby,
302 C.-\UDAD DE SISTEylAS TICOS :f; R.-\-?vlA
1979) 0 ser adecuado para su uso (Juran, 1988). Esto justifica la existencia de los procesos
"velticales" de gesti6n de calidad que puede afectar a varios procesos "horizontales" de
producci6n.
Es necesario articular alglll1 razonamiento para englobar y enlazar todas estas ideas
y conceptos. Si se busca una analogia con la definici6n de Proceso Software dada par
Fuggetta (2000)5. y teniendo en cuenta que la calidad de cualquier producto no puede ser
asegurada simplemente inspeccionando el producto 0 realizando meros controles
estadisticos. se podria !legar a pensar que una buena aproximaci6n a la gesti6n de la
calidad de los datos y de la infol111aci6n en las organizaciones podria ser definir un
Proceso Software de Gestion de Informacion (PGI). en e1 que se detlniera quien esta
haciendo que. cuando. que recursos se usan y c6mo se gestiona 1a calidad tanto de los
productos que se generan como de los recursos que se usan. Esta bip6tesis esta respa1dada
por McLeod (1990) que explica que todo proceso software esta formado por dos
subprocesos: uno de producci6n propiamente dicho y otro de gesti6n que incide en el de
producci6n para controlarlo y que la ejecuci6n 0 no de alguna de las acti\idades del
subproceso de gesti6n incide directamente en la calidad del producto de datos que se
desarrolla.
Esto habilita la evaluaci6n y mejora de la calidad de 121 informaci6n a tra\es de 11
e\'aluaci6n y la mejora de un proceso software encargado de la gesti6n de 11 informaci6n.
Aunque existen \arios marcos de trabajo para la e\aluaci6n y 11 mejora de los procesos
so1"\\\are. como Cv['vlI 0 ISOIEC 1:5:504. ninguno de ellos se centra en 11 calidad de los
datos y de 11 informaci6n.
Para conseguir evaluar y mejorar la calidad de datos \' de infol111aci6n en una
organizaci6n y teniendo el concepto de PGI como concepto mticulador de esta propuesta.
se han definido en el marco dos componentes principales:
Ln Modelo de calidad basado en Gesti6n de Calidad de los datos y de la
Informaci6n estructurado en 1\iveles de Yladurez. llamado C-\LDEA. 211 estilo
de Cv1YII y ISOIEC 1 :5504. donde se establecen distintas Areas Clave de
Proeesos (ACP) con actividades de .caracter tanto tecnico como de gesti6n.
Para caela ACP. y en aras de conseguir un marco de trabajo 10 mas universal
posible. se proponen algunas hel1'amientas. teenicas. estandares. tareas
6
v
'Proccso So/ilmre eS lIil COlljUll1O cohereille de po/ilicas, eSll"/iCll!raS orgulli::aciolla/es, lec-
i/%gias, procedimielllos ,1' urlejilcl()S 'jue SOil necesarios para concebi/', desarrollul', ills/a/ar ,1' liIWilcner
1111 procillc/o sofhm/'e "
,. Al estilo de las pnicticas de C\[M y Ci\[ivU pero utilizando la tenl1inologia de Metrica \'.3
RA-MA CWiTULO 10: CALID,AD DE LA INFORt'vIACIOl\ 303
metIicas requelidas, De esta manera cada organizacion puede usar 10 que sea
mas apropiado para sus necesidades.
III Una Metodologia de Evaluacion y Mejora de la Cali dad de infol111acion,
conocida como EVAMECAL, del estilo de CBA-IPI (Dunaway, 1996),
SCAMPI (SE1, 2001) 0 la cuarta parte de ISO/IEC 15504 (ISO, 2004a-d.
Redondo. 2004), que consiste en un conjunto de pasos que proporciona una
base para la evaluacion y ejecucion de la mejora de la calidad de datos y de la
infor111acion a traves de una gestion proactiva, La evaluQcion y mejora necesita
un modelo de proceso (Humphrey. 1989) que encuentra en CALDEA.
Con estos dos componentes. la idea del marco puede resumirse como sigue: elegir
un PGI de la organizQcion cuya cali dad de los datos y de la infol1mcion sea suceptible de
mejora. aplicar EVAMECAL para evaluarlo segLll1 el modelo de referencia indicado por
CALDEA y mejorarlo planificando la realizacion de acciones COlTectoras para satisfacer
los objetivos de calidad de datos y de infol1nacion establecidos en CALDEA.
Los siguientes subapartados describen los componentes del modelo propuesto.
4.7.1. L11L.dU
CALDEA representa en el marco propuesto. el modelo de referencia que debe
seguir un PGI para la mejora continua. Para poder lle\ar a cabo de fOl11m efectiva la
gestion de los procesos sofnvare de gestion de informacion es necesario asumir cuatro
resjJonsabilidades claws (Florac y Carlenton, 1999): definir. medir. controlar y mejorar el
proceso. Se han asimilando estas responsabilidades clmes como referencias en la
definicion del modelo de proceso de gestion de infol111acion pueden establecerse cinco
niveles de madurez en la gestion de calid2d de datos y de infol1nacion. al estilo de los
propuestos por CvlMI. Un nivel de madurez indica la capacidad de un proceso (Cue\as et
al.. 2002), En cada niwl es necesario obsenar una serie de acti\'idades fundamentales
para el cumplimiento de los objeti\os de gestion. CM\/ll reLIne estas actividades en grupos
de actividades. llamados Areas Claw de Proceso (.4>.CPL Cada una de las ACP debe
contemplar las acti\'idades necesQrias para implementar los procesos de produccion de
productos de informacion y las acti\'idades encaminadas a lograr 0 alcanzar un
detenninado objetivo de calidad de datos y de informacion. Es interesante reseilar que se
ha optado poria representacion en etapas de CMMI. porque parecia mas facil trabajar con
secuencias de mejoras bien definidas (que abarcan desde los fundamentos basicos de la
gestion de proyectos hasta los asuntos de gestion de la calidad de los datos) y ademas esto
pe1111itia asegurar la primera condicion impuesta por Eppler y Wittig (2001) de ofrecer un
conjunto conci50 de cliterios sistematicos para evaluar y meJorar la calidad de la
infon11acion,
Se han definido los siguientes niveles de madurez para la gestion de la cali dad de
los datos y de la info1111acion: Inicial, Definicion, Integracion, Gestion Cuantitativa y
30-1 CAUDAD DE SISTEMAS INFORMA. TICOS
Optimizante, cada uno con sus ACP. Estas ACP estan a su vez compuestas por
actividades. Para la realizacion de cada actividad, es necesmio la eleccion de una serie de
tecnicas, estandares y heITamientas que penIDtan convertir los productos de entrada en
productos de salida. A fin de hacer el modelo 10 mas universal posible se ha optado por
proponer, no por imponer una serie de tecnicas y heITamientas que dilijan hacia el
objetivo de la ACP. Tambien es importante senalar que en cada nivel de madurez se
puede ir modificando tanto elmodelo de procesos del PGI como elmodelo de datos, para
que puedan recopilar todos los requisitos de calidad de datos y de la infonnacion.
Los cinco niveles de madurez en la gestion de calidad de datos y de la infonnacion
de los que consta CALDEA son los siguientes (en la tabla 10.19 se muestran las ACP de
cada uno de ellos):
GEGCDI
...
z; vv
~
~ f--
\;;
~
g
~
Q GIR
GCI GE
FS
Tabla 10.19. Areas claves de proceso de CALDEA
1. Inicial (1). Un PGI se dice que esta en elpivel inicial cuando no se ha gestionado
ni coordinado ninglin esfuerzo con el fin de asegurar la calidad de los datos y de
1a informacion, es decir puede estar en un estado ca6tico.
2. Definido (2). Un PGI se dice que esta Definido 0 en e1 Nivel de Definicion
cuando se ha planificado e1 proceso de gestion de infol111aci6n, identificando y
defmiendo todos los elementos y componentes (tantos pasivos como activos), 1a
relacion entre ellos y el modo en que se han ido desan"ollando de acuerdo al plan
previsto. Por tanto un PGI se dice que esta definido cuando se ha gestionado un
proyecto para su definicion. Las ACP de este nivel son las siguientes:
e (GEGCDl) Gestion del Equipo de Aseguramiento de Calidad de la
Informacion. Las iniciativas de gesti6n de calidad de datos y de infonnacion
Q RA-MA CAPiTULO 10: CAUDAD DE lA INl'ORMACION 305
necesitan personas que puedan dar soporte a las actividades que se deben
realizar. Estas personas deb en trabajar en concordancia con las ideas y las
tendencias de la organizaci6n y deben estimular a la plantilla mostrando un
compromiso con las politicas de calidad de infonnaci6n (Ballou y Tayi, 1999),
haciendo esfuerzos para satisfacer las ACPs del modelo de madurez. Redman
(2001) sefiala la necesidad de que los altos directivos se impliquen en las
iniciativas de calidad de datos y de infoffilaci6n.
e (GP) Gestion de Proyecto para PGI. EI objetivo de esta ACP es crear un
plan para coordinar y organizar los esfuerzos y redactar un documento. que
describa claramente una agenda de actividades y un presupuesto en recursos
para optimizar el PGI. Este documento se puede realizar de acuerdo a IEEE
( 1987).
e (GR) Gestion de Requisitos de Usuarios. Los requisitos de usuarios deben
ser recopilados y documentados convenientemente. Se deb en identificar tres
clases de requisitos (Wang y Madnick, 1993): los relacionados con el producto
final de infoffilaci6n (ERU-PI), los relacionados con el PGI (ERU-PGI) y los
relacionados con la Calidad de la Infonnaci6n (ERU-CI). Estos tres grupos de
requisitos son el punto de partida para modelar el PGI. Existen tecnicas y
helTamientas que pueden ayudar a desalTollar cada documento (IEEE, 1998), Y
alguna mis especifica para aspectos concretos como, IP-MAP
(Shankaranarayanan et ai., 2000), que bien podna ser utilizado para modelar el
PGI.
e (FS) Gestion de Fuentes de Datos y Destinos de Producto de Informacion.
Por las caractensticas de los datos, es necesario identificar y documentar las
fuentes de datos y los objetivos de los datos de ERU-PGI para evitar problemas
de redundancia y de fonnato de intercambio de los datos (Loshin, 2001). En
Ballou et al. (1998) Y en Bouzeghoub y Kedad (2000) se discuten estos temas
y sugiere fOffilas para tratar la infonnaci6n de multiples fuentes. En almacenes
de datos se deben usaI' helTamientas como ETLs para unificar la selmintica y
los fonnatos de datos (English, 1999).
e (ADN1) Gestion de Proyecto de Mantenimiento, Desarrollo 0 Adquisicion
de Bases de Datos 0 Almacenes de Datos. Los datos us ados como matenas
primas deben ser recopilados y almacenados en BD apropiadas 0 en almacenes
de datos. Para asegurar mejor la calidad de la infoffi1aci6n, es mejor elaborar lill
proyecto para la gesti6n de la adquisici6n, desalTollo 0 mantenimiento de un
SGBD 0 un almacen de datos, debiendo sopOliar los requisitos establecidos en
ERU-PI, ERU-CI y ERU-PGI. Esta ACP pennite incluir otras actividades
como Aseguramiento de la Calidad de los Datos (Jar'ke y Vassiliou, 1997).
e (GCl) Gestion de la Calidad de la Informacion en Componentes PGI. El
uso de mehicas para medir la eficiencia del PGI pennite ayudar a mejorarlo. Es
necesano identificar a partir de las ERU-CI tanto las dimensiones de calidad de
306 CAUDAD DE SISTEvlAS TICOS
la infonllacion (como se prop one en ISO/IEC 9126 para el software) para cada
uno de los componentes que se debe controlar (Hoxmaier. 2001; Huang et al.,
1999). como las metIicas que mejor se adapten a cada una de estas dimensiones
(Eppler. 2003: Kahn et al., 2002: Pipino et al., 2002). Para conseguir que
nuestro marco sea 10 mas geneIico posible. no se prop one ninguna dimension
como obligatoria. ya que esto no es posible salvo para contextos concretos
(Pipino et al., 2002). Como guia. suele utilizarse como estandar el de
dimensiones de calidad de datos propuesto pOI' Strong et al. (1997b). Como
ayuda en esta labor. se puede utilizar una metodologia generic a como IEEE
(1992) 0 GQM descrita en (yan Soligen y Berghout. 1999). Autores como
Ballou y Tayi (1999). Bouzeoghoub y Kedad (2000) 0 Calero y Piattini (2002)
han propuesto metricas para la mejora de componentes especificos de un PGI.
Para obtener medidas mas fiables es interesante automatizar el proceso de
medicion como sugiere Hinrinchs (2000).
3. Integrado (3). Un PGI se dice en e! ni\el de Integracion 0 que esta integra do.
cuando habiendose alcanzado el niYeI 2. se hacen esfuerzos por ejecutar el
proyecto seglll1 las politicas de calidad de datos de la organizacion. La idea de
estar integrado responde a la necesidad de estar dentro de en un entomo
determinado. la organizacion. respondiendo a1 111is1110 enfoque de bllsqueda de
caliclad de datos y de la informacion que el resto de los recursos (English. ! 999:
Loshin. 2001). a fin de que pueda ser controlado bajo los panimetros propios del
conte:\to (Florac y Carlenton. 1999). Las ACP de este niYeI son las siguientes:
'alidacion y Yerii1cacion de del PGI y Productos de
Tanto los productos de informacion como los componentes del
PG! tienen que ser \erificados y validaclos para corregir clefectos y cliferencias
con las ERUs. Se poclria usar las inspecciones de software (Fagan. 1976: Gilb
y Graham .. 1993). aclaptaclas a los aspectos cle caliclacl. Una metodologia mas
especifica que se puecle usar es. clata testing propuesta pOl' Kiszkumo et uf..
(2001 ). e:\tenclicla al PGI. Se podria cliseii.ar y reclactar un plan cle pruebas para
coorclinar los esfuerzos relati,'os a !a \aliclacion \' a la Yerificacion
1986).
" (GIR) Gestion del Impacto de la CaUdad de Informacion y de los Riesgos.
Es necesario cletenninar el impacto sobre la organizacion cle una pobre caliclacl
cle la informacion en el PGI y acotar que riesgos se procluciran si se asume
(English. 1999). Getto (2002) propone una metoclologia que se puecle aclaptar a
aspectos cle calidad de la inf0I11lacion para reunir y clocumentar toclos los
nesgos.
'" (GE) Gestion de la Estandarizacion de la CaUdad Ie la Informacion.
T oclas las lecciones aprencliclas a traves cle la experiencia se cleben reunir.
clocumentar y transmitir a la base cle conocimientos de la organizacion, Un
<;' RA-:'vlA CAPITULO 10: CAUDAD DE LA INFORMACION 307
ejemplo de proceso de estandarizacion podria ser el sexto proceso de TDQM
(English,2002).
Ii> (GPO) Gestion de las Politic as de Calidad de la Informacion Organizativa.
Una forma de implementar todos los esfherzos mencionados anterio1111ente
consiste en la definicion de politicas de cali dad de la info1111acion basadas en
estandares previamente definidos. que afectan a la organizacion.
4. Gestion Cuantitativa (4). Un PGI se dice que esta en el nivel de gestion
cuantitativo 0 que esta gestionado cuantitativamente cuando estando integrado
en una cultura organizacional de cali dad de datos. se desanollan esfuerzos para
tomar medidas relacionadas con el y con sus componentes. Por tanto. el objetivo
principal de este niwl es obtener una confo11nidad cuantitatiya del rendimiento
del PGI en un periodo de tiempo razonable que sea consistente con 10 reguerido
en te11ninos de variac ion y estabilidad (Florae y Carleton. 2002). Para este niwl
se han definido las siguientes ACP:
c;; (GP;\I) Gestion de Planes de Medicion del PGI. EI objetivo de esta ACP es
conseguir metric as que se pueden usar para comprobar la conformidad de la es-
pecificaciones (Grimmer y Hinrinchs. 200\: Loshin. 2001). Como afi11na
Ivleredith (2002). un plan para la medicion de la calidad del sofmare comienza
con la decision de tomar medidas e implica elegir "que". "cU21ndo" y "como"
medir. como representar esas medidas y "a quien". Autores como English
( 1999) 0 Loshin (200!) prop on en el uso de diagramas de control como forma
de representar los datos referentes al PGI. Otra fOl1na de mostrar los resultados
es el uso de diagramas de Ki\iat como propone Humphrey (2002).
c;; Gestion para la Automatizacion de Planes de :Yledida. Para
conse-guir un aumento de fiabilidad y repetibilidad de las medidas. algunos de
los pro-cedimientos de medidas y algoritmos (definidos en GQM) deben ser
automatizados (Hinrinchs.2000).
5. (5). Un PGI se dice que esta en el ni\el cuando. los
valores de las metricas I'eferentes a las dim,ensiones de calidad de datos y de
informacion recogidas de los componentes del PGI y del producto de informacion
son utilizados para identificar TIlentes de defectos 0 la forma de optimizar el
proceso completo. cumpliendo as! con la tlltima de las actividades de gestion
propuestas por Florac y Carienton (1999). Para este tiitimo nivel las ACP que se
definen son las siguientes:
Ii> (GPD) Amilisis Causal para la Gestion de Prevencion de Defectos. El
Control Estadistico del Proceso (CEP) pueden aplicarse para detectar defectos
de calidad de infol111acion e identificar sus causas. Las conc\usiones obtenidas
proporcionan una base para eliminar defectos detectados en los recursos
afectados. Smith y Heights (2002) ofrecen un marco de trabajo para prevenir
los defectos.
308 CAUDAD DE SISTE\lAS f\FOR,\t.i. TICOS : R.-\-\!A
@ (GIDO) Gestion de la Innovacion y del Desarrollo de la Organizacion.
Son las bases para el concepto de mejora continua. Similar al anterior ACP, los
resultados se pueden usar para mejorar el PGI.
4.7.2. EV AlVlECAL: METODOLOGiA DE EV ALUACION Y lVIEJORA
DELPGI
Se pretende que EV AMECAL sea una metodologia orientada al PGl como una
f0l111a de asegurar la cali dad del producto de inf0l111acion a traves del propio proceso de
produccion y todo 10 relacionado con ese proceso de producci6n. Esto hace que los
metodos de evaluacion y mejora de procesos software como CBA-IPl (Dunaway, 1996).
SCAtV1PI (SEl, 2001), la tercera y la cuarta patte de ISO/IEC 15504 (Redondo, 2004), ...
deban ser tenidas en cuenta a la hora de la elecci6n y definici6n de pasos; y dado que las
citadas metodologias estan orientadas a la mejora continua, EV AMECAL, 10 esta.
Por OtTO lado, y al igual que OClUTe con las mencionadas metodologias para
procesos software, la evaluaci6n y la mejora debe hacerse con respecto a un modelo de
referencia. En el caso que nos ocupa. los miembros del EGCDI deben usar EVAIvIECAL
tomando como referencia para la evaluacion y la mejora el modelo de calidad bas ado en
niveles de madurez definido por CALDEA. Esto quiere decir que el resultado de la
evaluacion sera un detel1ninado nivel de madurez (y otros valores numericos como se
indicara posteriol1nente) y que la mejora debe hacerse bus cando incorporar las actividades
de las cOITespondientes ACP propuestas para los niveles de cara a garantizar los objetivos
de calidad definidos para cada una de ellas.
Antes de comenzar la presentaci6n de la metodologia es interesante explicar los
tel1ninos en los que se va a llevar a cabo la evaluaci6n y la mejora para cada uno de los
conceptos asociados al PGI: Nivel de madurez, ACP, actividad y componente. Los
diferentes estados para cada elemento del marco pueden ser c1asificados como sigue
(vease tambien tabla 10.22):
@ Cada Nivel de Madurez puede estar en uno de estos estados:
{ "Consolidado .. , "No Consolidado '/.
e Cada ACP puede estar en uno de estos estados: rCompietamente Satis/echo".
"Satisfecho", ''Parciaimente Satisjecho", "No Satisfecho"}.
e Cada actividad en las ACPs puede estar en uno de estos estados:
{"Completamente Ejeclltado", "Ejeclltado", "Parciaimente Ejeclltado", "No
Ejeclltado"}
e Cada componente puede estar en uno de estos estados: {"Compietamente
Optimizado", "Optimizado", "Parcialmente Optimizado", "No Optimizado"}.
Para ca1cular estos estados se necesitan tres valores:
10: CAUDAD DE LA 309
I Valor de Calidad de la Informacion (VCl) para cada elemento como un
indicador del grado de calidad de datos y de la infOl1llacion. Se calcula como la
media ponderada de las calificaciones l1l1meriCaS obtenidas por cada uno de sus
componentes en la evaluacion. Se define un VCl para cada componente: de
esta f01111a, el Valor de Calidad de Informacion para una Actividad (VCI-
A) podda ser definido con la media ponderada de los valores de dimension de
calidad de datos de cada componente del PGI que pmticipe en dicha actividad
teniendo en cuenta su grado de cri.ticidad. Un VCI para una ACP (VCl-ACP)
puede definirse como la media ponderada de todos los VCl-A para esa ACP; y
un Nivel de Madurez-VCI para el Nivel de Madurez (VCI-NM) puede ser
definido como la media de todos los VCl -ACP para ese nivel y as!
sucesivamente (vease figura 10.l2) .
. \"zl!llt!roCompont!ntt's
I GradoCriticidad
j
'" VaioracionComponeJZte
i
VCI = __ _----:-:--,-----::-___________ _
NiveiCriticidad
j
Figura 10.12. Formula para caIcular los estados de los componentes
I Grado de Criticidad (GCr) para cada uno de los componentes dentro de su
grupo: as! es posible encontrar un Grado de Criticidad para cada ACP en los
Niveles de r,;ladurez. para cada Actividad de las ACP y para cada Componente
en la Actiyidad. Estos grados de criticidad pem1iten cuantificar la impOltancia
de un elemento denho de un grupo de elementos. La tabla 10.20 muesha los
grados de criticidad para las ACP y las actividades del nivel de definicion,
mienhas que la tabla 10.21 muestra los mismos elementos para el resto de
niveles.
I Valoracion de cada componente. Que representa una medici on de una de las
dimensiones de calidad de datos y/o de info1111acion de cada uno de los
componentes. Para los niveles de madurez. s.e ha elaborado un cuestionario que
pretende guiar las subsecuentes mediciones.
Con estos hes valores y aplicando la for1llula dada en la figura 10.12 es posible
obtener un VCl. Ese valor se mapea segill1 los rangos de valores definidos (compatibles
con ISO/IEC 15504) en la tabla 10.22 para obtener el estado de cada uno de los
componentes estudiados.
4.7.2.1. La Metodologia
La metodolog!a EVAMECAL establece los pasos que hay que dar para valorar y
mejorar un PGl. Las valoraciones del PGI y los objetivos de mejora se establecen en
DE SISTEMAS TIeos RA-:'IA
tenninos de niveles de madurez. Basado en el ciclo PDCA de Deming, EV AIvlECAL
puede resumirse como sigue:
EI EV (ElVIC-P). fase don de se analiza la situacion actual del
PGl y se estable'cen los cOlTespondientes objetivos de mejora. Consta de las
siguientes actividades:
EMC-P.1. Valoracion del estado actual de la calidad de datos y de
infol111acion del PGl en tenninos de VCl y niveles de madurez.
EMC-P.2. Definicion de objetivos de mejora para los componentes del
PGl en los mismos tenninos en los que se hizo la valoracion.
ACP
(GEGCDI) Gesti6n del Equipo de
Aseguramiento de Calidad de Datos y de
la Infonnaci6n.
(GP)Gesti6n de Proyectos PGI.
I GCR-I
ACP
10%
15%
ACTIVtDADES ACP
GEGCDI.I. Detem1inar la composici6n I 60%
del EGCDI.
GEGCDI.2. Definir un entomo
operativo.
GP.!, Definici6n del PGI.
I 40%
60'io
40"
GP.2. Definici6n e implementaci6n de I
un proyecto para la implantaci6n del
PGI.
I
30 0 I
25%
(ADM) Gesti6n de Proyecto de
Mantenimiento. Desarrollo 0 Adquisici6n
de Bases de Datos 0 Almacen de Datos.
I AD1\1.2. Ejecuci6n del Proyecto. I -+0 0 I
Gc.l. Identitk3ci6n de las dimensiones I
de calidad de datos v de infonnaci6n.
60 0 I
I
(GCl) Gesti6n de la Calidad de la
Infonnaci6n en Componentes PGI.
GC.2. Identificaci6n de las metlicas para I
cada una de las dimensiones de cali dad
de datos y de infOl111aci6n.
40"0 I
Tabla 10.20. Grados de Criticidad de ACP y Actiyidades del Niyel de Definicion
El EVAlVIECAL-DO (ElVIC-D), que pretende desaITollar soluciones para lograr
los objetivos propuestos. Consta de las siguientes actividades:
EMC-D.l. Analisis de causas potencies y desan'ollo de un plan de
mejora. Consta de las siguientes subactividades:
Q. R.A-.MA CAPiTULO 10: CAUDAD DE lA INFORlvLACION 311
EMC-D.l.l. Amilisis y comprension del problema
EMC-D.1.2.Amilisis detallado de las causas reales del problema.
EMC-D.l.3. Desanollo de un plan de mejoras.
EMC-D2. Ejecucion del plan de mejoras.
I EV AIVIECAL-CHECK (EMC-C), donde el objetivo es comprobar la
eficiencia del plan de mejora ejecutado. Consta de la siguiente actividad.
EMC-C.l. Comprobar la eficiencia del plan de mejora. Consta de las
siguientes subactividades:
EMC-C. 1. 1. Valoracion del PGI y de sus elementos tras el plan
de mejora
EMC-C. I .2.Comparacion de los resultados con los obtenidos en
la subactividad EMC-P. 1. 1.
EMC-C.1.3. Elaboracion de los infoI1nes peltinentes.
I EVAMECAL-ACT (EMC-A). fase en la que se pretende estandarizar los
conocimientos adquiridos en to do este proceso. Consta de las siguientes
actividades:
EMC-A.l. Obtener conclusiones a partir de los inf0l111es del plan de
meJora.
EMC-A.2. Estandarizar las lecciones aprendidas para evitar problemas
similares en el futuro.
4.7.3. EJEMPLO DE APLiCACiON DE CALDEA
Como ejemplo de utilizacion de CALDEA y EV AMEC.AL se presentan a
continuacion los resultados obtenidos cuando se aplic6 a un PGI de una organizaci6n con
experiencia en gesti6n de infoI1naci6n. EV AMECAL fue aplicado siguiendo los pasos
previamente descritos.
La principal actividad de la compania es desanollar sofuvare. Poseen un s6lido
conocimiento y fOI1nacion en estandai'es de calidad de sofuvare e Ingenieria del Sofuvare.
La compania ha obtenido la certificaci6n ISO 9000. Los servicios que ofrece son
consultoria, desanollos a medidas. f0l111acion, atencion tecnica, ventas de licencias. bases
de datos y administraci6n de almacenes de datos. proyectos de planificaci6n de sistemas y
migracion a importantes SGBD. Con un total de ochenta y nueve empleados, los
dieciocho del Departamento de Sistemas son los que organizan los recursos que dan
sopOlte infol111atico al resto de los departamentos.
312 CAUDAD DE SISTE'vL-\S INFOR.ivL-\ TICOS
I
ACP
GCR-'
ACTlVlDADES ACP
GCR-
ACP Acnv
VV.I. Disel1.0 de un Plan de pruebas para la
(VV) \Oalidacion y Verificacion de veritlcacion y la validacion de los componentes del
60"
Componentes de PGI y Productos de
25%
PGI Y del producto de infomlacion.
Informacion. VV.2. Ejecucion del Plan de pruebas para la
40%
verifieaeion y la validacion.
(GIR) Gestion del Impacto de la
GIR.!. Estimacion impacto de la pobre calidad de
60"
Pobre Calidad de Infol1nacion y de
,,)-01
datos y de infol1nacion
_) /0
GIR.2. Definicion de planes de contingencia para
los Riesgos.
esos riesgos.
400
0
GE.I. Eleccion de Estandares de Calidad de Datos
30
0
"
-0
Y de Infol1nacion.
0
>
GE.2. Eleccion de Politicas Organizacionales de
Z
(GE) Gestion de la Estandarizacion
Calidad de Datos y de Infomlacion.
300
de la Calidad de la Infol1nacion.
GE.3. Revision y complecion de las ERU con la
infomlacion expuestas en los estandares y las 400
politicas.
(GPO) Gestion de las Politicas de
25%
I
GPO.l. Disel1.0 Politicas Organizacionales. 1000
Calidad de la Infol1nacion
""
GPM.l. Identificacion de los aspectos necesarios 600
o;
para cada una de las metricas.
(GM) Gestion de los
B
Planes de Medida. 70%
'""

GPM.2. Definicion de un plan de medida para cada
Co.;
400
una de las metricas.
I
GAPi\l.l. Estudio para la automatizaeion de los
60" 0
(GAPM) Gestion de la planes de medida.
Automatizacion de los Planes de 30 10
GAPM.2. Implementacion de los aspectos de
400
Medida. automatizacion de las metricas.
GPO. I. Crear un infol1ne con los defectos
250
encontrados.
(GPD)Gestion de Prevencion de
50%
GPD.2. de la simacion para Ia

Defectos para el Analisis de Causas. detenninacion de causas de problemas.
GPD.3. Disefio de soluciones para la eliminacion
250

de las causas de los defectos.
I
GPD.4. Implementacion de solueiones para la
250
elimiriacion de las causas de los problemas.
0.
GIOO.I. Creaeion de un infomle con las posibles
a
25 ()
<> mejoras.
.2:
GIOO.2. Analisis de los datos para la mejora
Z

(GIOO) Gestion de la Innovacion y
50'io
organizacional.
del Desarrollo de la Organizacion. GIOO.3. Disei'io de propuestas para la mejora de la
250
calidad de los datos y de la infonnaeion.
GIOO.4. Implementacion de soluciones para la
25 ()
obteneion de las mejoras.
Tabla 10.21. Grados de Criticidad de Areas ClaYes de Proceso y ActiYidades del resto de
niveles de CALDEA
i
!
i
I
i
I
I
I
i
!
l
CAPITULO 10: CAUDAD DE LA Il\'FOR,\lACION 313
NmmRE R\NGOVCJ DESCRIPCloN
ESTADO
No Optimizado os VCIS20 Hay poca 0 ninguna evidencia de la consecucion del estado
No Ejecutado. para el elemento evaluado.
Parcialmente 21 S VCI s 60 Hay evidencia de aproximacion y consecucion del estado
Optimizado' para el elemento evaluado. Algunos aspectos de la
Parcialmente consecucicin pueden scr impredecibles.
Ejecutado.
Optimizado 61S VCI s85 Hay evidencia de aproximacicin y consecucion signiticativa
Ejecutado. del estado para el elemento evaluado. EI rendimiento del
proceso puede variar en algunas areas 0 unidades de
trabajo.
Completamente 86 S VCI s 100 Hay e\-idencia de una completa aproximacion y
Optimizado' consecucicin del estado para el elemento evaluado_ No
Completamente existen debilidades significativas en los componentes
Ejecutado definidos.
No Satisfecho OS VCI -Ni'! S 90 Rango de valores para el VCI definido para el Nivel de
Satisfecho. 91 S VCI -NM S 100 Madurez
Tabla 10.22. Estados de los componentes y rangos de valores segun IQV
Entre todos los PGI de la organizaci6n, el marco de trabajo se aplic6 al Proceso de
Gesti6n de Fon11aci6n. que es responsabilidad del Departamento de Consultoria. El
principal objetivo del PGI estudiado es la gesti6n de los datos relativos a la fon11aci6n,
consistente en satisfacer demandas intemas y extemas' para la fom1aci6n, eligiendo quien
va a ser el fon11ador. detem1inando que recursos se van a usar y gestionando distintos
aspectos de calidad de la fon11aci6n. Este proceso esta adecuadamente especificado y
documentado en elmanual de calidad de la e:11presa.
Existen fon11ularios para recabar datos sobre cursos demandados y para las
evaluaciones de la calidad de los ejercicios propuestos, mateliales didacticos
proporcionados, y para la capacidad de los profesores, instalaciones, asistencia y uso de
recursos.
La organizaclOn utiliza para la gesti6n de estos temas una aplicaci6n llamada
SINCRO, desalTollada intemamente. Uno de los empleados del Departamento de
314 CAUDAD DE SISTEi-!AS I!'-;FORIvL-\. TICOS
Consultoria, es el responsable de transcribir datos de los forrnularios a la aplicacion y
obtener la infonnacion que sera transmitida a la persona adecuada.
T odas las preguntas de los infonnes se realizaron al Director del Departamento de
ConsultOlia. En la tabla 10.23 se muestran los plincipales resultados de las encuestas.
RESULTADOSDE LoslNFORMES .' .
....
NIVELnE DEFINICION ". <
.
No EJEctTrAl>O
(GEAGI) Gesti6n del Equipo de Aseguramiento de Calidad de la
No Satisfecho
InfoTInaci6n.
(GRU) Gesti6n de Requisitos de Usuarios. No Satisfecho
(GFDDPI) Gesti6n de Fuentes de Datos y DestiTIos de Producto de Parcialmente
Infonnaci6n. Satisfecho
(GPMDABDD) Gesti6n de Proyecto de Mantenimiento, Desarrollo 0 Parcialmente
Adquisici6n de Bases de Datos 0 Datawarehouse. Satisfecho
(GCl) Gesti6n de la Calidad de la InfoTInaci6n en Componentes PGI. No Satisfecho
.' '.
NIVEL DE l'\TEGR,,"CION NoEJECuTADO
(VV) Validaci6n y Verificaci6n de Componentes de PGI y Productos de
No Satisfecho
Infonnaci6n
(GR) Gesti6n del Impacto de la Pobre Calidad de InfoTInaci6n y de los
No Satisfecho
Riesgos.
(GEC!) Gesti6n de la Estandarizaci6n de la Cali dad de la InfoTInaci6n No Satisfecho
(GPCIO) Gesti6n de las Politicas de Calidad de la Infonnaci6n
No Satisfecho
Organizativa .
.
.
NIVEL DE GESTION CUANTITAmA
'.
No EJECUTADO
(GM) Gesti6n de las Metricas del PGI No Satisfecho
(GAPM) Gesti6n para la Automatizaci6n de Planes de Medida No Satisfecho
.....
. NIVEL DE lVlEJOR,,"
.' ' .. .....
No EJEcuTAl>O .
(ACGPD) Amilisis Causal para la Gesti6n de Prevenci6n de Defectos No Satisfecho
(GIDO) Gesti6n de la Innovaci6n y del Desarrollo de la Organizaci6n No Satisfecho
Tabla 10.23. Resultados obtenidos despues de aplicar EV AMECAL al PGI Gestion de
Formacion
RA-:v!A CAPiTULO 10: CAUDAD DE LA rNFORMACION 315
Los resultados reflejan que ninguna de las ACPs que pertenecen al nivel 2 y a
niveles supeliores pertenecen como mlnimo "Satisfecho ", todos los niveles estan en el
estado "No ejecutado ". Acorde con el grado de criticidad de cada ACPs, se propusieron
las siguientes recomendaciones para satisfacer el nivel de definici6n de las ACPs:
G Fonnar un Equipo de Aseguramiento de la Calidad de la Infonnaci6n que
asuma la responsabilidad de gestionar el PGI.
G Gestionar adecuadamente los requisitos de los usuarios.
G Identificar y definir tanto fuentes de datos como destino de los productos de
infonnaci6n y los fonnatos de intercambio de datos.
G A partir las ERU, gestionar adecuadamente las dimensiones de calidad de la
infonnaci6n para cada uno de los componentes del PGI.
G Modificar la base de datos 0 la Datawarehouse para dar soporte a infonnaci6n
de calidad.
G Planificar un proyecto para el desarrollo del PGI.
G English, L.P. Improving Data Warehouse and Business Iriformation Quality:
klethods for reducing costs and increasing Profits. Willey & Sons, 1999. Libro
considerado como uno de los c1asicos del campo de calidad de datos y de
infol111aci6n, afronta c6mo tratar la calidad de los datos mediante una
metodologia muy completa y exhaustiva que implica a la propia organizacion
como "brazo annado" de las iniciativas de mejora.
G Eppler, M. J. Alanaging Iliformation Quality. Springer. Alemania 2003. En
este libro, el autor da su visi6n paIiicular sobre la gestion de la calidad de la
infonnaci6n, proponiendo un modelo muy interesante.
G Genero, M., Piattini, M. y Calero, C. (eds.) (2005). Metrics for Conceptual
Models. Imperial College Press, UK. En esta obra se resume el estado del arie
sobre las metricas para modelos conceptm!les, especialmente de los diferentes
modelos de UML.
G Huang, K.T., Lee, Y., Wang, R. Quality liiformation and Knowledge. Prentice
Hall, Upper Saddle River, 1999. Referencia de obligada lectura que trata sobre
el modelo TDQM propuesto por el MIT. Se establecen los principios basicos
de esta filosofia sobre la calidad de los datos.
G Piattini, M., Calero, C. y Genero, M. (eds.) (2002). liiformation and database
quality. Kluwer Academic Publishers, Norwell, EEUU. En esta recopilaci6n se
abordan diversos aspectos de la calidad de los datos y de la infOlmaci6n.
316 CAUDAD DE SISTEMAS ll'iFORM.A.TICOS
e http://web.mit.edu/tdqm/.esla web del proyecto TDQM, coordinado por
Richard Wang. Puede ser considerado como el proyecto matriz de much as de
las investigaciones academicas sobre el tema.
e http://www.iqconference.onz.esla web del International C01?(erence on
li!(ormation Quality (ICIQ), organizado por el Sloan School of lvlanagement
del MIT (Boston, EE.UU), es uno de los congresos mas antiguos y con mas
solera de calidad de datos y de info11naci6n. En este congreso confluyen los
resultados de los desatTollos de investigaci6n de las universidades con las
necesidades de las empresas en los proyectos de evaluaci6n y mejora de la
cali dad de los datos y de la infol111aci6n.
7. EJERCICIOS
1. c, Que caracteristicas de la n01111a ISO 9126 cree que son aplicables a la hora de
evaluar la calidad de un SGBD?
2. Daniel Moody en los liitimos cinco anos ha llevado a cabo diferentes eshldios con
el fin de validar tanto el marco (Moody y Shanks, 1994) como las metricas
(Moody, 1998) propuestas para la evaluaci6n de modelos E/R. Analice los
eshldio que pueda encontrar en la bibliografia y detelmine hasta que punto
validan sus propuestas.
3. c,Que similihldes y que diferencias encuentra entre la propuesta de Kesh y la de
Moody? Analice la aplicabilidad en la practica de ambas propuestas.
4. En este capihllo se han presentado algunas metricas para bases de datos
relacionales pero no tienen en cuenta las restlicciones presentes en las mismas.
Proponga. siguiendo el Metodo Alarcos para metlicas software presentado en el
capihllo algunas metlicas para las restlicciones (clallsulas CHECK y
ASSERTION) de bases de datos que sigan el estandar SQL. c,C6mo podria
demostrar que las metlicas propuestas pem1iten predecir la mantenibilidad de las
bases de datos relacionales?
5. c,Que metricas de bases de datos relacionales opina que pueden seguir siendo
validas para bases de datos objeto-relacionales? c,Que metric as de las defmidas
para sistemas Olientados a objetos pueden utilizarse para bases de datos objeto-
relacionales? c,Que nuevas metricas podrian proponerse?
6. Analice la variaci6n que sufi'en los valores de las metlicas propuestas para
almacenes de datos cuando se utiliza un esquema en "copo de nieve" (snmtjlake)
respecto al esquema en estrella.
C; R.-\-:-'lA CAPiTCLO 10: C.-\UDAD DE LA 31 i
7. Compare las dimensiones para calidad de datos propuestas por English (1999)
con las de Pipino et al. (2002).
8. (,Que indicadores para la cali dad de datos Ie parecen m:1S relevantes'? (,Que
dificultades presentan a la hora de calcular sus val ores'?
9. Proponga alguna tecnica (0 extensi6n de las existentes) para reflejar requisitos de
calidad en especificaciones de requisitos tanto textuales como gnificas.
10. Ana1ice hasta que punto elmodelo CALDEA es conf0I111e a las especificaciones
de la nonna ISO 15504.
11. Ana1ice hasta que punto el modelo CALDEA es COnf0I111e a las especificaciones
de CMMl.
12. Analice hasta que punto la metodo10gia EV AMECAL es confo1111e a SCAMPI
13. Describa algllI1 Proceso de Gesti6n de Infonnaci6n (PGI) de su organizaci6n.
14. Identifique dimensiones de ca1idad de datos y de infonnaci6n y las metricas
cOITespondientes que puedan ser aplicadas al PGI que acaba de describir.
15. Ap1ique EVA.MECAL. calculando todos los VCl. (,en que nivel de madurez esta'?
CAPITULO 11
GESTION DEL CONOCIMIENTO
"lnvertir en conocimiento produce los nzejores bene/icios "
Benjamin Franklin
1. INGENIERIA DEL SOFTWARE Y GESTION DEL
CONOCIMIENTO
1.1. Necesidades de gestion del conocimiento en
organizaciones de software
Como seiialan Basili et al. (2001) pnicticamente todas las organizaciones que
desarrollan y mantienen sofuvare comparten las siguientes necesidades:
Comprender los procesos y productos.
Evaluar los exitos y fracasos.
Aprender de las expeliencias.
Empaquetar experiencias exitosas.
Reutilizar expetiencias exitosas.
Estos autores afmnan que cuando un empleado se va de la organizacion, con el se
"pierde" la expetiencia que este ha ido adquilido a 10 largo del tiempo que ha estado
trabajando (a veces, incluso, ni se sabe que es 10 que se ha perdido); otras veces se
"redescubren" experiencias cuya existencia se desconocfa; en ocasiones se vetifica que
no se cumplen las promesas realizadas a los clientes, simplemente por desconocimiento
de las mismas, y que el personal no se desarrolla adecuadamente por falta de
conocimiento.
320 IMORlvL.\ TIeos 1;:; R ~ l v L
Esto es debido a que las organizaciones dedicadas al desalTollo del software
rcquieren y generan grandes cantidades de conocimiento, de diverso tipo:
e Conocimiento del producto.
e Conocimiento del proceso.
e COllOcimiento del proyecto.
La calidad del software y de los SI no puede ser mejorada si to do este
conocimiento no se encuentra disponible 0 no se utiliza adecuadamente, ya que los
procesos de desatTollo y mantenimiento de software dependen -adelmis de la creatividad
de las personas y el funcionamiento de los equip os- en gran medida, de dichos
conocimientos.
En este sentido, Lindvall y Rus (2003) afil111an que la gestion del conocimiento
pennite 'producir mejor so./hmre. de una '/or/lla mas rapida y economica, as! como
tomar mejores decisiones", ya que facilita:
e La localizacion de Ulentes de conocimiento.
e La reutilizacion de experiencias.
e La mejora de los procesos de desalTollo del software.
e La reutilizacion de artefactos del proceso de desatTollo.
Existe ya bastante experiencia en organizaciones de todo tipo que demuestran
como se puede gestionar el conocimiento (Davenpori y Pl1lsak, 2000; Tiwana. 2000) y
que empiezan a adoptar arquitecturas de gestion de conocimiento como la que se muestra
en la figura ILl (Lawton, 2001). Como puede observarse en esta figura, la gestion de
conocimiento se puede considerar el nexo que une las actividades de produccion diatias
con las iniciativas de mejora y los objetivos de negocio.
En este sentido hay que destacar que varias de las actividades de gestlon del
conocimiento en general (como la reutilizacion .de activos, la gestion de documentacion,
la gestion de competencias, la colaboracion 0 las redes de expelios) pueden resultar muy
titiles para la Ingenieria del Software (Aul1lm et al., 2003). Adelmis, en las
organizaciones software, la gestion del conocimiento se da especificamente en las
siguientes areas:
e Gestion de configuracion y control de versiones, ya que los sistemas de este
tipo crean indirectamente la memoria del proyecto, que indica la evolucion del
software y puede servir para identificar experios (quien ha hecho determinados
cambios).
e Decisiones de diseiio C'design rationale"), que es una aproximaclon que
consiste en capturar explicitamente decisiones de diseilo para crear una
memoria del prodllcto.
CAPiTCLO II: GESTIO;-; DEL 321
e Trazabilidad. que contlibuye indirectamente a la memoria del producto.
e Informe de problemas y trazabilidad de defectos, los cuales, pudiendose
considerar fuentes de conocimiento "llegativo", podrian llegar a transfonnarse
en conocimiento 'positivo".
e Herramientas CASE y entornos de desarrollo de software.
Nive! de Aplicacion
Interfaces
Servicios de Gest"lon de
Conoclmiento
Taxonomia Corporativa
Gesti6n de Contenidos
Inrraestructura
Informacion y ruent8 de
Conocimiento.
Inteligencia
Competitiva
Sistema de Majores
Practicas
Portal de Conocimiento
Servicios de Descubrimiento Servicios de Co[aboraci6n
r .. 1apa de Conocimiema
RepoSltorio de Co nacimiento
Correo Electronico. Servidores de Fichera y Servicios de ImernetfExtranet
Gestf6n de
Documentos
E!ectr6nicos
Correo
Electrcnico
'.Neb
Figura 11.1. Arquitectura de gesti6n de conocimiento (Lawton, 2001)
1.2. La gestion del conocimiento y los procesos del cicio de
vida del software
En la nOIma ISO 12207 aparece un subproceso rc1ativo a la gesti6n del
conocimiento dentro del proceso organizacional de Recursos Humanos, cuyo prop6sito
cs "asegumr que ef conocimiento, fa informacion y las Izabilidades individuafes se
recogen. cOil/parten, relltili::.an y mejomn a 10 largo de la OIgani::.acion". SegllIl esta
nonna, como resultado de la gesti6n del conocimiento:
e Se establece y mantiene una infraestrLlctma para la compartici6n de la
intonnaci6n comllI1 y de dominio a traves de la organizaci6n.
322 CAUDAD DE SISTEMAS lNFORIvlATICOS @RA-MA
o El conocimiento se encuentra disponible n'tpidamente y compartido por toda la
organizaci6n.
o La organizaci6n seleccionan't la estrategia de gesti6n del conocimiento
apropiada.
A continuaci6n se resumen las tareas relativas a la gesti6n del conocimiento (ISO,
2000):
o El director planificani los requisitos para gestionar los activos de conocimiento
de l'l organizaci6n, incluyendo la infraestmctura y la fonnaci6n para sopOliar
los contribuidores y los usuarios de los activos de conocimiento de la
organizaci6n, el esquema de clasificaci6n y los criterios para estos activos.
o EI director estableceni una red de expelios dentro de la organizaci6n y se
asegurani que se mantiene actualizada.
o El director estableceni un mecanismo para soportar el intercambio de
infonnaci6n entre expeltos y el flujo de la infonnaci6n de los expertos en los
proyectos de la organizaci6n.
o Se llevani a cabo la gesti6n de configuraci6n de los activos de acuerdo con el
proceso de gesti6n de configuraci6n.
En el siguiente apartado se muestran tecnicas y herramientas utilizables para la
realizaci6n de estas tareas.
1.3. Tecnicas y herramientas para la Gesti6n del
Conocimiento
Se pueden destacar diferentes tecnicas y herramientas para la gesti6n del
conocimiento:
o Sistemas cooperativos y de trabajo en grupo (groupware).
o Aprendizaje asistido pOI' ordenador (e-Iearning).
o Sistemas de gesti6n documental, bibliotecas y repositOlios de conocimiento.
o Portales e intranets de conocimiento.
o Sistemas de soporte a la toma de decisiones.
o Lecciones aprendidas, patrones y buenas pnicticas.
o Modelos de predicci6n.
o Sistemas de razonamiento basado en casos.
o "Caliografia" de conocimiento.
RA-MA
CAPiTULO 11: rcc--rrr,,' DEL CONOCIMIENTO 323
Tecnicas de descubrimiento de conocimiento ("Knowledge discovel)' ").
Comunidades de pnicticas, y de trabajadores de conocimiento.
Gestores de habilidades y sistemas de apoyo a la localizaci6n de expertos.
Redes extemas, como la "Softlrare Process Improvement Netlvork." (SPIN) 0
los grupos de interes de IEEE 0 ACM.
Centro de soporte de fabricantes, como el Oracle Support Center.
Estandares y nonnas de ISO, IEEE, etc.
GUlas para proyectos, plantillas, etc.
Flujos de conocimiento.
Proyectos cuyo objetivo es construir bases de conocimiento en ingenieda del
software como CeBASE y ViSEK.
En Vizcaino y Piattini (2006) se profundiza y presentan ejemplos de estas
diferentes tecnicas y henamientas.
1.4. Implantacion de la Gestion del Conocimiento
En la implantaci6n de estrategias de gesti6n de conocimientos, Lawton (2001)
destaca los siguientes obstaculos:
Cuestiones tecnologicas: a veces no es posible integrar los diferentes sistemas
para conseguir los niveles adecuados de acceso y distribucion de
conocimiento. Deseado.
Cuestiones organizacionales, tales como fallos del proceso de estrategia e
implementacion de gestion del conocimiento.
Cuestiones particulares de los h'abajadores de la organizacion, tales como falta
de tiempo de los empleados, el no querer compartir 0 reutilizar el
conocimiento, etc.
Por otro lado, existen h'es factores importantes que posibilitan el proceso de
implantaci6n de estrategias de gestion del conocimiento en las organizaciones de
software:
La tecnologia disponible en la organizacion para los desarrolladores, que Ie
pennitira crear un repositolio de memoria organizacional accesible a toda la
organizacion.
Elliderazgo que pretende impulsar la gestion de conocimiento en el desanollo
de los productos y servicios software as! como en los procesos de trabajo.
324 C.-\UD/\D DE SISTEi--HS Ii'FORyL-\ TIeos I:RA-MA
(I La cultura organizacional que soporte la comparticion de conocimiento,
experiencias, tecnologias e innovacion.
Para dar sopOlte a una gestion efectiva de conOClImento en el desalTollo de
software, se requiere el soporte tanto de la propia gestion como de los niveles tecnicos, y
puede realizarse en:
(I Soporte del proceso software. modelos de mejora de procesos. actividades,
resultados de los procesos, etc.
(I SopOlte del producto software. disefio, ingenieria, modelado.
(I SopOlte al personaL adaptar una helTamienta de flujos de trabajo (1\orl;1701\").
etc.
Ebert et al. (2003) sefiala que para garantizar el exito de un programa de gestion
del conocimiento es obligatorio elegir el modelo de gestion del conocimiento adecuado.
El modelo de gestion del conocimiento se enlaza con la estrategia empresariaL la
organizacion de la gestion del conocimiento. los conceptos de gestion del cOllocimiento y
el tipo de conocimiento (vease tabla 11.1)
ESTRATEGIA MODELODE
ORG.{MLKION CO?\CEI'TOS
TlPODE
DIPRESARIAL GESnO" co:\ocnUE:i\TO
Reducci6n de
Productividad
Compartir. evitando Base de
Explicita
costes redundancia in!ollnaci6n
Especializaci6n Cali dad Mcjores pnicticas
Proccsos
Explicito
comunes
I
Integraci6n y
Conocil11icnto
Innovaci6n Creatividad c0l11binaci6n de
dinul11ico
Tacita
conocil11icnto
Tabla 11.1. :\Iodelos de Gesti6n de Conocimiento y estrategias empresariales (Ebert et
al., 2003)
Ademls. la gestlon del conocimiento implica una impOltante i I1\-eI"S IOn. que se
refleja en la necesidad de crear un grupo dedicalio a la mejora de los procesos sofuyare
-que se denomina de diferentes fonnas: SPEG (Sojhmre Process Engineering Group).
SPI (Sojhmre Process JllIpr01'elllent) group, Experience Factory Group. etc.- e
idealmente crear la funcion de "Chie/Knowledge Otficer".
1.5. Modelos de Gesti6n de Conocimiento en ingenieria del
Software
Existen muchos modelos de gestion del conocimiento en general. y en los tlltimos
ai'ios han aparecido yarios especificos para la ingenieria del sofuvare, entre los que
destacan los propuestos por Dyba (2003) y Oliver et al. (2003).
I
.;: RA-MA CWiTULO 11: GESTIO!\' DEL CO?-:OCIMIE?-:TO 325
1.5.1. MODELO DE DYBA (2003)
Dyba (2003) propone un modelo dimimico que se centra en las necesidades de
comunicacion, coordinacion y colaboracion. Este modelo trata de como los equipos de
software adquieren y utili zan conocimiento en un entomo organizacional para l11ejorar
sus procesos software. En este modelo se integra las actividades de creacion del
conocimiento junto con el "trabajo real" del desaITollo de software. Este modelo consta
de cuatro elementos principales (vease figura 11.2):
e Contexto organizacionaL que describe el entomo general que impone
restricciones y opOltunidades acerca de 10 que puede y no hacer la
organizacion.
Ii) CicIo de aprendizaje, que comprende el proceso dialectico que integra 1a
experiencia local y los conceptos organizacionales.
e Desempefio organizacionaL que agrupa los resultados de las actividades de
mejora de la organizacion.
e Factores facilitadores. que reflejan las condiciones que facilitan la creacion
de conocimiento y la mejora de procesos software.
Este autor define la creacion del conocimiento en Ingenieria del Software como el
intercambio dimimico entre dos dialecticas: entre el conocimiento organizacional y el
local: y entre la generacion y la interpretacion del conocimiento organizacional.
i
MEMORIAl
, ORGANIZACIONALI
/,_, _ :_i\
/ FACTO RES ) INTERPRETACION
CONOCIMIENTO
\1-' -I-,f
,; I v
'\/
CONOCIMIENTO
LOCAL
o
R
G
A
N
I
Z
A
C
I
o
N
A
L
Figura 11.2. Modelo dimimico de gestion del conocimiento (Dyba, 2003)
326 CAUDAD DE SISTE?vIAS INFORtvL-'. TICOS R.",-MA
Ademas, Dyba identifica seis factores facilitadores en la creaci6n de conocimiento
de ingenieria del sofuvare y analizando las relaciones entre los procesos de creaci6n de
conocimiento y otros factores facilitadores (vease tabla 11.2).
FACTORES CONOe. GENERACION
I
lVIEMORIA
FACILITADORES LOCAL CONOe. ORGA1'ljlZ. CONOe.
ORlE:-ITACIO:-l AL
I
X XX X
:-IEGOCIO
I:\IPLICACIO:-l DE LOS X XX X
LiDERES
PARTICIPACIO;-'; DE XX XX X XX
LOS DIPLEADOS
PREOCUPACIO:-l POR XX X
LA :\IEDICIO:-l
EXPLOTACIO:-l DEL X XX X X
CO;-.;OC. EXISTEi\TE
EXPLOR-\CIO;-'; DE
I
XX XX
:-IUEYO CO:-lOC.
Tabla 11.2. Relaciones entre los procesos de creacion de conocimiento y los factores
facilitadores (Dyba, 2003)
1.5.2. MODELO SEKS
Por su parte, Oliver et al. (2003) presentan el modelo SEKS (Software
Engineering Knowledge-Sharing). Este modelo (vease figura 11.3) reconoce la
interacci6n entre los individuos y dentro de los equipos como producto de tres factores:
motivaci6n para descubrir conocimiento, una cultura de apoyo y la experiencia previa.
Asociados a estos factores se encuentran el deseo y la oportunidad de aprender.
Las dificultades mas importantes que sefialan la mayor parte de los autores son
hacer tacito el conocimiento explicito y mantenerlo actualizado. Ademas, en el desarrollo
y mantenimiento de software podemos encontrar tanto conocimiento del dominio del
problema como conocimiento del dominio de la soluci6n.
2. FACTO RIA DE EXPERIENCIA V PARADIGMA DE
MEJORA DE LA CAUDAD (QIP)
2.1. QIP (Paradigma de mejora de la calidad)
Basili et al. (1995) presentan el paradigma de mejora de la cali dad (QIP, Quality
Improvement Paradigm), que es una aproximaci6n a la medici6n y control de la calidad
dirigida por objetivos, basada en una infraestructura organizativa denominada 'factoria
de experiencia".
RA-MA
OPORTUNIDAD
DE
APRENDER
DES EO
DE
APRENDER
CAPiTULO ii: GESTION DEL CONOClMIENTO 327
CULTURA
DE APOYO
(NIVEL ORG. E
INDIVIDUAL)
MOTIVACION
PARA
DESCUBRIR
CONOCIMIENTO
EXPERIENCIA
PREVIA
Figura 11.3. Modelo SEKS (Oliver et al., 2003)
COMPARTICION
DELCONOCIMIENTO
ENINGENIERIADEL
SOFTWARE
EI objetivo de este paradigma es la adquisici6n de competencias bcisicas que
sopOlien competencias estrategicas y la mejora de la calidad en el entomo de desarTollo
-en lugar de en el de producci6n- mediante la reutilizaci6n del conocimiento y la
expenencla.
EI proceso de mejora de la calidad, que es un proceso iterativo que a cada iteraci6n
redefine y mejora las caracteristicas y los objetivos, ocwTe en seis pasos, agmpados en
dos ciclos:
I. CicIo de Aprendizaje Corporativo, que consta de los siguientes pasos:
e Caracterizaci6n, la empresa construye modelos del entomo actual.
e Fijaci6n de objetivos, sobre 10 que quiere conseguir para el siguiente producto
y aprender acerca del negocio.
e Elecci6n de procesos, metodos, tecnicas y herramientas adecuadas al
problema.
328 CAUDAD DE SISTE',!AS lMOR"!.'\' TICOS DRAAIA
e Ejecucion. durante la cual se analiza los resultados intel1nedios para ver si se
satisfacen los objetivos.
2. Cicio de Aprendizaje de Proyecto. que comprende las siguientes actividades:
e Se inicia con la ejecucion.
e La organizacion analiza los resultados para aprender de ellos.
e La organizacion almacena y propaga el conocimiento.
As!, por un lado. existe un '"cicio de control" que es la realimentacion al proyecto
durante la fase de ejecucion, y que proporciona infol1nacion analitica acerca del
desempeflo del proyecto. Esta infol1nacion se utiliza para prevenir y solventar problemas,
monitorizar y soportar el proyecto y realinear el proceso con los objetivos. Por otro, cabe
destacar, un "cicio de capitalizacion". la realimentacion a la organizacion, con el fin de
capturar la experiencia, acumularla y transferirla, para aplicarJa a otros proyectos.
2.2. Factoria de experiencia
La factoria de experiencia consiste en una organizacion basada en la capacidad. en
la que la reutilizacion de experiencia y el aprendizaje colectivo se convielien en una
cuestion corporativa. La factoria de experiencia proporciona "ellister de cOlllpetencias"
denominados ''paqlletes de experiencias".
Como se muestra en la figura 11.4. la organizacion de proyectos proporciona a la
factoria de experiencia caracteristicas del proyecto y entol11o, datos de desanollo.
infol1nacion sobre la utilizacion de recursos, registros de calidad. infol111acion sobre el
proceso, los productos, planes y modelos utilizados, as! como los datos obtenidos durante
el desanollo y la explotacion. La factoria de expeIiencias transfol1na estos elementos en
unidades reutilizables y proporciona. a la organizacion de proyectos, configuraciones
base, henamientas, lecciones aprendidas, y datos. parametrizados de alguna fOI111a para
adaptarse a las caracteristicas de los proyectos especificos.
Los beneficios que aporta una factoria de experiencia a la organizacion son
variados:
e Establecer un proceso de mejora de software sus tent ado y controlado por datos
cuantitativos.
e Producir un repositolio de datos y modelos software que esten basados
emp!ricamente en la pnictica diaria.
e Desanollar una organizacion de sopOlie intel110 que limite la sobrecarga y
proporcione beneficios sustanciales de desempei'i.o de coste y calidad.
(;: It/>''-\lA CAPiTULO II: GESTION DEL CONOCI?vlIE]\TO 329
'" Proporcionar un mecanismo para identificar, valorar, e incorporar en los
procesos nuevas tecnologias que hayan demostrado ser valiosas en contextos
similares.
'" Incorporar y sopOltar la reutilizaci6n en el proceso de desan'ollo de software.
ORGANIZACION
DE PROYECTO
EJECUCION I""""""
DEL PROCESO
I
Modelo de ejecucion
I
PLANIFICACION

DEL PROCESO
i-'
I-
DATOS
PRODUCIDOS
EXPERIENCIA
EMPAQUETADA
Figura 11.4. Factorla de Experiencia propuesta por el Prof. BasHi
Ejemplos reales de factorias de experiencia son el SEL (Sofhmre Engineering
Laboratory) del Goddard Space Flight Center de la NASA, el SEC (Sofhmre Experience
Center) de DaimlerCluysler. 0 el EPIK (Engineering Process JmprOl'ement and
Kn01t1edge Sharing) de ICL.
2.3. Base 0 repositorio de experiencia
Seglll1 Basili y Caldiera (1995), una base de experiencia debe:
'" Contener el conocimiento relevante para la organizaci6n.
'" Residir en un marco de aprendizaje bien concebido.
'" Disponer de metodologias que establezcan como se estructura la experiencia.
'" Disponer de procesos. procedimientos y reglas que establezcan C01110 se
gestiona la experiencia diariamente.
330 CAUDAD DE SISTE\e[AS rNFOR:'vLA. TICOS R.,\,,-NL-\
(I) Estar automatizada 10 maximo posible.
Estos autores prop on en una serie de pasos para crear un sistema de gestion de
expeliencia (SGE):
e Caractelizar la organizacion e identificar los procesos y conocimientos
actuales.
e Identificar los usuarios y definir roles de usuario.
(I) Desanollar casos de uso.
e Definir tipos de paquetes (taxonomias).
e Generar los atributos que describen los tipos de paquete.
(I) Definir valores aceptables para cada atributo.
& Definir un documento de requisitos para el SGE.
e Construir, integrar e instalar el SGE.
e Evaluar y hacer evolucionar el SGE.
De fonna parecida, en Althoff y Pfahl (2003) se presenta una metodologia
("DISER"- Design and Implementation on So./hmre Engineering Repositories) para
construir y operar EBIS (Experience-Based li!/ormatioll Systems) que se resume en los
siguientes pasos:
1. Desanollar una vision del EBIS.
2. Fijar objetivos.
3. Fijarareas.
4. Definir escenarios de utilizaci6n y cumplimentaci6n.
5. Modelar la ontologia de la experiencia.
6. Implementar el EBIS.
7. Poner en-linea el EBIS.
8. Mantener el EBIS.
9. Integrar el conocimiento existente y generar nuevo conocimiento
Hay que tener en cuenta diferentes aspectos de calidad a la hora de construir y
gestionar un repositorio de experiencia (Schneider y von Hunnius, 2003):
1': RA.-MA CAPiTULO 11: GESTION DEL CONOCI1\lIENTO 331
e Guia al usuario, sobre todo para empezar reutilizando las expeJiencias.
e Usabilidad, ya que una pobre usabilidad puede alejar al usuario.
e Confol1nidad con el proceso, hacer un proceso mejorado centrado en el
repositorio de expeliencias, siguiendo la estructura del proceso subyacente.
e Mecanismos de realimentaci6n, pOl' medio de diferentes canales (colTeo
electr6nico, pizalTas electr6nicas, F AQ, contactos personales y telef6nicos,
etc.).
e Mantenibilidad, para que las reestructuraciones sean faciles.
POl' 10 que respecta a las lecciones aprendidas, estos autores recomiendan:
e Ser especifico, ya que si el contenido de la base de datos esta desordenado y
no se guia al usuario se limita drasticamente los beneficios del repositorio.
e Agrupar varias expeliencias alrededor de una sola descripci6n de procesos.
e Intentar simplificar la estructura y el fOl1nato de pagina, mejorando la
usabilidad.
e Facilitar la incorporaci6n de la realimentacion de los usuarios.
3. FAMILIAS DE ESTUDIOS
Una de las fOl1nas mas imp0I1antes de obtener conocimiento relacionado con el
desalTollo y mantenimiento del software es mediante la realizaci6n de familias de
estudios. En este senti do. Basili et af. (2001) sefialan algunos criterios para la
construccion de cuerpos de conocimiento en areas de IngenieJia del Software:
I. Fijar hip6tesis de alto nivel que sean de in teres para la comunidad de IngenieIia
del Software.
2. Hipotesis detalladas escritas en un contexto que pennitan estudios empiricos bien
definidos.
3. Variables de contexto. sugelidas pOl' las hipotesis, que puedan modificarse para
pel1nitir vmiaciones en el diseilo experimental.
4. Una cantidad suficiente de infol1nacion para que el estudio pueda ser replicado.
5. Una comunidad de investigadores que comprendan la experimentacion. la
necesidad de replica y que esten dispuestos a colaborar y replicar.
Los estudios empiricos resultan necesarios para comprobar y entender las
implicaciones relacionadas con la medicion de las entidades software. Esto se consigue a
332 C\UDAD DE SISTE\lAS INFOR?-.!..\ TIeos
traveS de hipotesis en el mundo real, ll1l:lS alla de la pura teolia, que habra que comprobar
con datos empiricos. Hay tres tipos principales de estrategias empiricas que pueden ser
llevadas a cabo (Robson, 1993): experimentos, casos de estudio y encuestas. En los
siguientes apartados se descliben con mayor detalle estas estrategias.
3.1. Experimentos
La ventaja de un experimento es que puede detenninar en que situaciones cielias
afil111aciones son ciertas y puede proporcionar el contexto en el que cielios estandares,
metodos y helTamientas son recomendables. Solo si el experimento se realiza
adecuadamente, es posible obtener conclusiones acerca de las relaciones entre la causa y
el efecto para la cual se fonnulan la hipotesis (Wohlin et al., 2000). Los expelimentos
necesitan ser planificados cuidadosamente si se pre ten de que proporcionen resultados
lltiles y significativos (Juristo y Moreno, 2001).
Basili et al. (1999) comentan que la experimentacion en la ingenielia del software
es necesaria. pero bastante dificil. Una razon de esta dificultad es la gra!1 cantidad de
variables del contexto, 10 cual implica que para conseguir una comprension adecuada de
los resultados de los experimentos, se necesita un mecanismo para explicar los estudios e
incorporar los resultados.
3.1.1. DESCRIPCION DEL PROCESO EXPERIMENTAL
El proceso experimental consta de seis etapas principales (Wohlin et al .. 2000),
como muestra la figura 11 .. En los siguientes apartados se resume cada una de estas
etapas.
3.1.1.1. Definicion
EI proposito de la fase de definicion es definir los objetivos de un experimento.
fOl11mlado a partir de un problema a resolver. Para recoger los objetivos de un
expelimento se sigue la plantilla GQM de con las sugerencias de Briand et al.
(2002) y Lott y Rombach (1996) (ver tabla 9.2 en apartado 2.2.2 del capitulo 9).
3.1.1.2. Planificacion
Despues de la definicion del experimento tiene lugar la planificacion. La
definicion detem1ina por que se va a realizar el experimento, mientras que la
planiticacion establece como se llevara a cabo. Esta etapa se puede dividir en los
siguientes seis pasos:
C RA-\L-\ CAPiTULO 11: GESTIO?\ DEL CO?\OCIMIENTO 333
Figura 11.5. Vision general del proceso experimental principales (WohHn et at., 2000)
1. Seleccion del contexto. EI contexto del experill1ento queda caracterizado de
acuerdo con cuatro dill1ensiones:
'" Ojlline ,s. On-line. Los experimentos pueden realizarse en proyectos reales
(on-line) 0 bien en paralelo a los proyectos reales (off-line).
'" EstZldiantes vs. Profesionales. Los experimentos pueden IIevarse a cabo con
sujetos profesionales 0 estudiantes.
'" Simlilacion 1"5. Problemas reales. EI experimento puede enfocarse en un
problema real 0 en una simulacion.
'" Espec(jico vs. Genera!. Los resultados del. expelill1ento pueden ser vcilidos en
un contexte especifico 0 en el dominio general de la ingenieria del software.
2. Formulacion de hipotesis. La definicion del experimento se fonnaliza por medio
de hipotesis. Deben fonnularse dos hipotesis: una hipOtesis nula (Ho) y una
hipotesis alternativa (HI). La comprobacion de las hipotesis entrafia diferentes
tipos de liesgos: algunos tests estadisticos pueden rechazar una hipotesis
verdadera ailll siendo cierta (elTores tipo I), mientras que otros tests no rechazan
una hipotesis falsa ailll siendo falsa (elTores tipo II). EI tamafio de los elTores
depende de diferentes factores. Un ejemplo es la capacidad del test estadistico
para revelar un patron verdadero en una coleccion de datos, que se conoce como
la potencia del test.
334 CAUDAD DE SISTEMAS INFOIUvLS, TICOS
RA-MA
3. Seleccion de variables. Antes de comenzar con el diseflo tenemos que elegir las
variables dependiente e independiente que se van a considerar, junto con la fonna
en que se van a medir y sus respectivas escalas de medici6n.
4. Seleccion de sujetos. La selecci6n de sujetos 0 muestra de la poblaci6n que se
utilizara en el experimento esta estrechamente relacionada con la generalizaci6n
de los resultados del mismo. Para generalizar los resultados a la poblaci6n
deseada, la selecci6n de sujetos debe ser representativa de esa poblacion. La
muestra de la poblaci6n puede ser probabilistic a 0 no probabilistica. Ejemplos
de tecnicas para obtener muestras de poblaci6n probabilisticas son el muestreo
simple al azar, muestreo sistematico y muestreo estratificado al azar; y para
obtener muestras no probabilisticas las tecnicas a utilizar son el muestreo por
conveniencia y el muesh'eo por cuotas. EI tamaflo de la muestra tambien tiene
influencia sobre la generalizaci6n de los resultados: cuanto mas grande es la
muesh'a, men or sera el elTor de la generalizaci6n de los resultados.
5. Disefio del experimento. El diseflo de un experimento describe como estan
organizados los tests y c6mo se ejecutaran. Para diseflar el experimento, es
necesario observar las hip6tesis y decidir que analisis estadisticos hay que ejecutar
para rechazar la hip6tesis nula.
Cuando se disei1a un expe11mento se puede distinguir enh'e diseflos intra-sujetos
(todos los sujetos realizan todos los tratamientos) y disei10s inter-sujetos (se
seleccionan diferentes sujetos para cada tratamiento). Los primeros tienen la
ventaja de garantizar el control de todas las variables debido a diferencias entre
sujetos, 10 que podlia interferir en los resultados de la investigaci6n y, ademas,
pennite reducir el esfuerzo de enconh'ar la misma infonnaci6n con un bajo
nlunero de sujetos. Sin embargo, los diseflos intra-sujetos pueden presentar
algunos problemas:
a) Antes de realizar el experimento existen efectos que pueden
comprometer la validez intema de los experimentos inh'a-sujetos como
los efectos de persistencia (una [onna de controlarlos es que los sujetos
realicen el experimento una sola vez, no 10 repitan), los efectos de fatiga
(apreciables sobretodo en experimentos excesivamente largos), y los
efectos debidos a la falta de motivaci6n.
b) Durante la realizaci6n del experimento. Debemos de considerar los
efectos de aprendizaje (que se evitan presentando las diferentes tareas a
realizar en todos los diferentes 6rdenes posibles), los efectos de
persistencia (cuando se sospecha que los efectos de un tratamiento
persisten s610 se realizara una vez ese tipo de exper1mento con ese grupo
de sujetos).
CAPiTULO II: GESTION DEL CONOCIMIENTO 335
6. InstrumentaciOn. La instlUmentacion para un experimento se selecciona en la
etapa de planificacion y puede ser de tres tipos: objetos particulares,
instrucciones e instrumentos de medicion. Antes de la ejecucion, se desalTollan
los instlUmentos especificos para el experimento. Los objetos del experimento
pueden ser, pOI' ejemplo, especificacion 0 codigo de documentos. Las
instlUcciones son necesm1as para organizar a los participantes durante el
expe11mento, e incluyen los procesos descriptivos y las listas de comprobacion. Si
se comparan diferentes metodos en el experimento, tienen que prepararse las
instrucciones para cada metodo. Ademas de las instrucciones, los participantes
tambien necesitan entrenamiento en los metodos que se van a usar. Las
mediciones en un experimento se realizan a traves de los datos recabados.
3.1.1.3. Operacion
En la etapa operacional de un expe11mento, se aplican los tratamientos a los
sujetos. Esta etapa se divide en tres partes:
A) Preparacion. Antes de que el expe11mento se 1111Cle, se debe encontrar el
personal que se comprometa a pmiicipar como los sujetos delmismo. Es esencial
que los sujetos que pariicipen en el experimento esten motivados y pmiicipen
voluntariamente en todas las paries del expe11mento. Los siguientes aspectos
deberian ser considerados respecto a los sujetos que participan en un
expe11mento:
e Obtener consentimiento. Los pmiicipantes tienen que estar de acuerdo con los
objetivos de la investigacion.
e Resultados sensibles. Si los resultados obtenidos en el experimento son
sensibles a los participantes, es importante hacer saber a los participantes que
el resultado de su rendimiento personal en el expe11mento se mantendra
confidencial.
e incentivos. Un modo de atraer a la gente a un experimento es ofrecer algtin
tipo de incentivo.
e Frallde. El fi:aude, es decir, "engafiar" a los pmiicipantes, generalmente no
favorecera al experimento. Si el fraude fuese la (mica altemativa solo deberia
llevarse a cabo si concieme aspectos que sean insignificantes para los
participantes y no afecten su voluntad de pmiicipar en el experimento.
B) Ejecucion. El experimento puede ser ejecutado de diferentes modos. Algunos
experimentos se llevan a cabo de una vez juntando a todos los pmiicipantes, por
ejemplo, en una sesion. La ventaja de este metodo es que el resultado de la
obtencion de datos se puede obtener directamente en la sesion y no es necesario
contactar posteriomlente con cada uno de los participantes para reque11rle los
resultados. Otra ventaja es que el experimentador esta presente durante la
336 CAUDAD DE SISTE\!AS INFOR\!.'\ TICOS
realizacion y si surge alguna dud a se puede resolver directamente. Sin embargo,
otros experimentos se llevan a cabo durante un intervalo de tiempo mucho
mayor, y no es posible que el experimentador participe en cada detalle del
experimento y en la recogida de datos. Los datos se pueden recoger tanto de
fonna manual por los participantes que rellenan fonnulaIios como
automaticamente a traves de helTamientas.
C) Ejecucion. El expeIimento puede ser ejecutado de diferentes modos. Algunos
experimentos se llevan a cabo de una vez juntando a todos los participantes, por
ejemplo, en una sesion. La ventaja de este metodo es que el resultado de la toma
de datos se puede obtener directamente en la sesion y no es necesario contactar
posteIionnente con cada uno de los participantes para requeIirle los resultados.
Otra ventaja es que el experimentador esta presente durante la realizaci6n y si
surge alguna duda se puede resolver directamente. Sin embargo, otros
experimentos se llevan a cabo durante un intervalo de tiempo mucho mayor, y no
es posible que el experimentador participe en cada detalle del expeIimento y en
la recopilacion de datos. Los datos se pueden obtener tanto de fonna manual por
los participantes que rellenan fonnularios como automaticamente a traves de
helTamientas.
D) Validacion de los datos. Una vez que los datos han sido recopilados, el
experimentador debe comprobar si los datos son razonables y se han obtenido
COlTectamente. Para ella es necesario verificar que los participantes han
comprendido bien los fOl111Ularios y que, por 10 tanto, los han rellenado
corTectamente. Tambien es importante revisar que los expeIimentos se han
desarTollado tal y como se habia previsto.
3.1.1.4. Amilisis e Interpretacion
Una vez recabados los datos empiricos, deben ser analizados adecuadamente.
Hay tres elementos principales a considerar cuando elegimos las tecnicas de analisis: la
naturaleza de los datos que se han obtenido, por que se ejecuta el experimento, y el
tipo de disefio experimental. Dependiendo del. prop6sito del experimento, se pueden
utilizar diferentes tecnicas para probar las hip6tesis.
3.1.1.5. Evaluacion de la validez
Una cuesti6n fundamental relacionada con los resultados del experimento es la
validez de esos resultados, ya que el grado de credibilidad de un experimento depende de
la validez de las conclusiones que se obtengan. Se pueden distinguir cuatro tipos de
cIiterios de evaluacion de los experimentos (Campbell y Stanley, 1963; Cook y
Campbell, 1979):
e Validez de constructo. Define el grado en el que las variables dependiente e
independiente miden fielmente los constructos te6ricos establecidos en las
CAPiTULO II: GESTIO)\; DEL CO)\;OCIMIE)\;TO 337
hip6tesis. La amenaza a la validez de constmcto es la falta de evidencia
teorica sobre si las metricas para las valiables dependiente e independiente
miden realmente los conceptos que se pretende medir.
fa Validez interna. La validez intema es el grado de confianza en la relaci6n
causa-efecto entre los factores de interes y los resultados observados, es decir,
el grado en el que se pueden obtener conclusiones sobre el efecto causal que la
variable independiente tiene sobre la variable dependiente. Los factores que
tienen repercusi6n en la validez intema son la seleccion y division de los
sujetos en diferentes grupos, las diferencias entre sujetos y el balanceo de
los mismos durante el experimento, el material utilizado en el experimento,
etc.
e Validez de la conclusion. Trata sobre la validez estadistica de las
conclusiones obtenidas en el estudio empirico.
e Validez externa. La validez extema es el grado en el que los resultados de la
investigaci6n pueden ser generalizados a la poblaci6n estudiada y a otros
entomos. Cuanto mayor es la validez extema, en mayor medida pueden
generalizarse los resultados de un estudio empirico como una pnictica real de
ingenieria del software. La validez extema no s610 se ve afectada por el disei'io
del expelimento sino tambien por los objetos del expelimento y los sujetos que
10 realizan. Existen principalmente tres liesgos: no tener los sujetos
adecuados para el experimento, realizar el experimento en un entorno
erroneo y ejecutarlo en unas circunstancias que condicionen los resultados.
En la tabla 11.3 se muestra una lista de las diferentes amenazas a la validez de los
expelimentos, que deberian ser controladas para obtener resultados vitlidos en cualquier
estudio empirico.
MIENi\Zi\S AU.:
D.ESCRlPCION
..
Vi\LIDEZ ...
Validez de la
I
Baja potencia estadistica. \'iolar las suposiciones de los tests estadisticos. finalizacion y
conclusion,
ratio de error, fiabilidad de las metricas, fiabilidad 0 tratamiento de implementacion.
irrele\'ancias aleatorias en eLambiente experimental.
Interpretacion pre-operacional inadecuada de los constructores. sesgo por mono-
Validez de
operacion. sesgo por mono-metodo, confusion entre constructores y niveles de
constructo,
constructores. interaccion de diferentes tratamientos. interaccion de experimentacion y
tratamientos, generalizacion restringida a traves de constructores, conjeturar hipotesis.
aprension en la evaluacion, expcctativas del experimentador.
Historia. madurez. experimentacion. instrumentacion. rcgresion estadistica. seleccion.
Validez intema.
mortalidad. ambigiiedad sobre el senti do de la influencia causal, interaccion con la
selecci6n, difusi6n de duplicados del tratamiento, igualaci6n compensatoria de los
tratamientos, rivalidad compensatoria. desmoralizaci6n resentida.
Validez externa.
Interacci6n de la selecci6n y el tratamiento, interaccion del ambiente y el tratamiento.
interacci6n de la historia y el tratamiento.
Tabla 11.3. Amenazas a la validez de los experimentos
338 CAUDAD DE SISTEMAS INFOIUvlA TICOS 9 RA.-?\lA
3.1.1.6. Presentacion y Empaquetamiento
Es esencial no olvidar, para la presentacion y difusion de un experimento, los
aspectos impoltantes y la infonnacion necesaria que necesitamos para llevar a cabo las
replicas y obtener beneficios del experimento y del conocimiento obtenido a u-aves de el.
Para ello, es impOltante elaborar "paquetes de lab oratorio" (laboratory packages) (Basili
et al., 1999; Shull et al.; 2003; Ciolkowski et al., 2002) que faciliten la replicacion de los
experimentos, que incluyan: el amilisis y objetivos del experimento; la motivacion a la
hora de realizar las decisiones clave del disefio, etc.; el disefio experimental, incluyendo
las amenazas a la validez y los puntos fueltes del experimento; el contexto en el cual se
llevo a cabo el experimento; el proceso para ejecutar el experimento; y los metodos
utilizados durante el amilisis de los datos empilicos.
3.1.2. REPLICACION DE LOS EXPERIMENTOS
Es importante ademas realizar replicas de los experimentos, porque con los
resultados de un unico experimento es dificil apreciar si los resultados son generalizables
y poder asi concluir que sus resultados son validos. Existen diferentes tipos de replicas
(Basili et al., 1999):
1. Replicas que no varian las hipotesis. Las replicas de este tipo no varian ni las
variables dependientes ni las independientes del experimento Oliginal. Denu-o de
este tipo de replicas se puede distinguir enu-e:
e Estlictas, que duplican el expelimento Oliginal y son necesarias para
incrementar la fiabilidad en la conclusion sobre la validez del experimento.
Demuestran que los resultados del experimento Oliginal son repetibles.
e Replicas que modifican la fonna en que el experimento se realiza, que intentan
incrementar nuestra confianza en los resultados expelimentales estudiando las
mismas hipotesis pero altemando algunos detalles del experimento_
2. Replicas que varian las hipotesis. Aunque varian algunas variables pemmnecen
en el mismo nivel de especificidad que el experimento original. Se puede
distinguir entre:
e Replicas que varian las variables independientes. Estas replicas investigan que
aspectos del proceso son impOltantes variando sistematicamente alguna
variable independiente y examinando los resultados.
e Replicas que varian variables inuinsecas al objeto de estudio. Estas replicas
cambian la fonna en que se mide la efectividad para intentar entender que
dimensiones de que tareas son mas importantes.
e Replicas que varian las variables de contexto en el entomo en el que la
solucion es evaluada. Estos estudios identifican potencialmente los aspectos
CAPiTULO II: GESTION DEL CONOCIMIENTO 339
del entomo que son impOltantes ya que afectan a los resultados del proceso en
investigaci6n y por tanto nos ayudan a entender la validez extema.
3. Replicas que extienden la teoria. Ayudan a detem1inar los limites de la
efectividad de un proceso, haciendo gr'andes cambios en los procesos, los
productos y/o los modelos del contexto para vel' si los principios basicos siguen
dandose.
Estas replicas deberian encuadrarse dentro de la planificaci6n de una familia de
expel1mentos como el que se muestra en la figura 11.6 (Ciolkowski et aI., 2002).
Preparaci6n
Experimentos
Definici6n del
Contexto
Conducci6n
Experimentos f---I!>/
Individuales
Material
Am31isis de la
Familia de
Datos
Figura 11.6. Fases para el desarrollo de una Familia de Experimentos (Ciolkowski et al.,
2002)
Como se puede observar en la figura 11.5, la planificaci6n de una familia de
expel1mentos se inicia con una fase de preparaci6n en la que se definen los objetivos
generales de la familia de experimentos y se planifica c6mo se van a analizar los
resultados, para posterionnente !levar a cabo cada experimento de fonna individual
teniendo en cuenta el contexto general establecido y elmatel1al necesar10, y finalmente se
analizan los resultados de los experimentos de fonna global.
3.1.3. EJEMPLO: DETERMINACION DE LA EFICACIA DEL PAIR
DESIGNING PARA LA COMPARTICION Y DIFUSION DE
CONOCIMIENTO
3.1.3.1. La importancia de Pair designing para la gestion de conocimiento
Uno de los aspectos relevantes a estudio en el ambito de la Ingenieria del software
es la transferencia de conocimiento cuando se trabaja en pares. Dentro de las tecnicas que
3-+0 CAUDAD DE SISTE\L".S INFOR;"l.-\ TICOS 1':: RA.-\lA
favorecen esta transferencia de conocimiento se encuentra la denominada Pair designing,
que es una pnictica utilizada en metodologias agiles consistente en que dos
programadores trabajan "hombro con hombro" (side by side) en el desan-ollo de una
misma pieza de c6digo_ Un programador, que asume el rol de conductor (driver) escribe
activamente el c6digo mientras que el otro que asume un rol de meramente observador
(obserl;er) identificando defectos y aspectos tacticos y estrategicos_ Los roles se
intercambian peri6dicamente_
Un beneficio de esta practica es que se refuerza el incremento de conocimiento de
los participantes, y en concreto el conocimiento tacito (F oresythe et or 1998: Williams y
Kessler, 2000)_ Este tipo de conocimiento no se puede f011nalizar y transferir facilmente,
excepto mediante la comunicaci6n y el dialogo_ El disefio de software requiere de
conocimiento tacito, y en concreto de mucha experiencia. De hecho, un programador de
sofuvare se convierte en disenador de sofuvare s610 despues de algunos ai'ios de
experiencia.
Como resultado del analisis anterior se podria pensar que la practica de pair
programming podria ser aplicada al disei'io con los mismos beneficios. En este caso la
practica se ha denominado Pair designing, consistente en el que el dri"\'er edita
activamente el documento de diseno mientras que el observer realiza una revisi6n
continua. Con todo ella se planific6 una familia de experimentos cuyo objetivo fue
demostrar la relaci6n existente entre la aplicaci6n de la practica Pair designing y la
construcci6n y difusi6n de conocimiento.
Por difusi6n del conocimiento se entiende la transferencia de conocimiento entre
los miembros del equipo, mientras que el refuerzo del conocimiento se refiere al
incremento del conocimiento global de los miembros del equipo mediante la
combinaci6n del conocimiento individual de sus miembros.
3.1.3.2. Una familia de experimentos para evaluar la difusi6n y refuerzo del
conocimiento de la tecnica Pair Designing
De acuerdo al metodo de Ciolkowski et or (2002) se slgmeron las siguientes
etapas para la realizaci6n de la familia de experimentos:
1. Preparaci6n de Experimentos. El objetivo general de los experimentos es el de
demostrar la utilidad de la practica pair designing en relaci6n a la difusi6n y
transferencia de conocimiento. Usando la plantilla GQM este objetivo se puede
definir de la siguiente f011na:
e Analizar la tecnica de Pair Designing.
e Con el proposito de evaluarlas en relaci6n a su capacidad de ser usadas
como tecnica para mejorar la difusi6n y refuerzo del conocimiento.
\: RA.-YIA CAPiTULO 11: GESTIO]\; DEL CO;-';OCIMIE]\;TO 341
G Desde el punta de l'ista de los investigadores.
G En el contexto de alumnos de ingenieria del software y profesionales de
los sistemas de infol111acion.
A paItir de este objetivo se plantearon las hipotesis generales de la investigacion.
2. Definicion del Contexto. Con el fin de poder generalizar los resultados se
identificaron dos grandes grupos de SlUetos experimentales a la hora de
establecer el contexto de cada experimento individual.
G Profesionales. Son los sujetos ideales a la hora de poder generalizar los
resultados, por 10 siempre que sea posible se deben seleccionar este tipo
de sujetos.
@ Alumnos. A la hora de llevar a cabo experimentos, los alunmos juegan
un papel l11uy impoltante, ya que antes de realizar estos estudios en
entomos industriales, 10 cual no siempre es posible (gasto significativo
de tiempo, esfuerzo y recursos), en muchas ocasiones los investigadores
llevan a cabo estudios piloto con alumnos en entomos academicos
(Carver et al., 2003). De hecho, hay que considerar que los alumnos
constituyen la proxima generacion de profesionales (Kitchenham et al.,
2002). Bajo cieltas circunstancias, las diferencias entre los alumnos y los
profesionales son pequer1as y las tare as requeridas en cieltos
experimentos no requieren experiencia industrial, por ello se puede
considerar la experimentacion con alurID10s como viable (Host et aI.,
2000: Basili et al.. 1999).
Por 10 tanto. a la hora de planificar el contexto de los experimentos
individuales se debe tener en cuenta la utilizacion de estos grupos de sujetos.
3. Material. El material experimental debe ser el mas adecuado para satisfacer los
objetivos planteados. De acuerdo al objetivo -de la investigacion y a las tare as
planificadas en el experimento se preparo la documentacion de un sistema para la
venta de libros de segunda mano a traves de Intemet. Dependiendo de las tareas
requeridas en cada experimento individual el material estaba compuesto por:
G Una especificacion textual y una lista de requisitos candidatos sobre el
sistema de venta de libros Book m'er the globe,
@ Dos diagramas de casos de uso junto con descripciones textuales de los
m1smos.
342 CAUDAD DE SISTEMAS TICOS :0
e Dos gramas de clases en tres capas (presentacion, dominio y
persistencia) con el disei'io del sistema.
EI Cuestionarios de Evaluacion de Conocimiento. Cada cuestionario
incluia un conjunto de preguntas de respuesta (SiINo) para evaluar el
conocimiento de los sujetos sobre el sistema software a desalTollar 0
mantener.
4. Conducci6n de Experimentos Individuales. Teniendo en cuenta la
planificacion general se planificaron y realizaron tres experimentos individuales
con el objetivo de satisfacer los objetivos generales. Para la realizacion de cada
experimento individual se siguio el proceso establecido pOI' Wholin et al. (2000).
Es importante destacar que a la hora de llevar a cabo cada experimento
individual. junto con el marco general establecido en la familia de experimentos
se debe tener en cuenta la realimentacion obtenida como resultado de lievar a
cabo los experimentos previos. En la figura 11. se muestra una vision general de
los experimentos llevados a cabo:
Tarea Experimental
1
Desarrollo -r-
I
:vlantenimiento
t
1Experimento
45 Estudiantes de 3' curso de
Ingenieria en Informatica
Universidad del Sannia
(Benevento, Italia)
I
I" Experimento
2Experimento
36 Estudiantes del Master
MUTS, y MUTEGS
Universidad del Sannio
(Benevento, Italia)
I
2 Experimento
3 Experimento
42 Estudiantes 3' ITIG
39 Estudiantes 3' ITIS
12 Estudiantes 5' Ingenieria
Informatica
Escuela Superior de
Informatica (Ciudad Real,
Espana)
I v
3" Experimento
(replica 2")
Figura 11.7. Vision general de la familia de experimentos lIeyada a cabo
Como se puede observar en la figura 11., los experimentos quedaron divididos
en dos grandes grupos en funcion de las tare as a realizar en cada uno:
I Desarrollo. En el primer experimento la tare a experimental que los sujetos
debieron realizar fue el desanollo del sistema Book m'e!' the globe para 10 cual se
RA-illA C\PiTLiLO 11: GESTION DEL CONOCIMIENTO 343
les proporciono la lista textual de requisitos y cinco cuestionarios para evaluar su
conocimiento del sistema. El objetivo de este expelimento se centro en los
aspectos de construccion de conocimiento.
e Mantenimiento. Para la realizacion del segundo experimento y de su replica (30
expel1mento) se pidio a los sujetos que realizaran tareas de mantenimiento del
sistema. Para ello ademas de la especificacion de requisitos y de los cuestionarios
a los sujetos se les proporcionaron los diagramas de casos de uso y de clases del
sistema. Sus tareas de mantenimiento consistian en: reducir la complejidad del
diseno, mediante la eliminacion de entidades (clases, casos de uso, actores,
metodos, atributos, etc.) 0 relaciones entre entidades que no fueran
fundamentales para el funcionamiento y la comprension del sistema; mejora de
la legibilidad del diseno, realizando modificaciones sobre las entidades existentes
o ailadiendo nuevas.
Como se puede verse en la figura 11., los sujetos que partlClparon en los
experimentos fueron estudiantes de distintas universidades en Italia y Espana.
Todos los sujetos antes de proceder con el experimento recibieron una sesion
de entrenamiento y se familiarizaron con la tecnica de pair designing y con el tipo de
tare as a realizar en el experimento.
El proceso expel1mental que siguieron los sujetos en el primer experimento
fue dividido en tres sesiones 0 rondas. Al principio y final de cada ronda ten ian que
contestar un cuestionario de fonna individual para evaluar sus conocimientos del
sistema. La mitad de los sujetos trabajaron en cada ronda aplicando la fonna
tradicional de disefio (que denominaremos solo designing) mientras que la otra mitad
fueron distribuidos en parejas y aplicaron pair designing. Al final de cada ronda los
sujetos producian los diagramas cOlTespondientes que respectivamente fueron:
diagramas de casos de uso, diagramas de clases y diagramas de interaccion.
Por su pmte el proceso seguido en el segundo y tercer experimento nle:
e Cada sujeto estudiaba la documentacion ind'i\"idualmente durante 30 minutos.
e Cada sujeto respondia al cuestionario de entrada. de forma individual durante
15 minutos. El cuestionario inicial tenia como fin establecer el punto de
pmtida: por ejemplo: ni\"el de conocimiento del sistema antes de trabajar con
el y que habia sido construido lmicamente a partir de la lechlra de la
documentacion.
e Los sujetos trabajando sobre el diseilo del sistema en pares 0 de forma
individual realizaron las tare as de mantenimiento durante dos horas.
e Cada sujeto respondio el cuestionario de salida individualmente.
IKFOR:VIA TIeos
La distribucion de los sujetos en sus modalidades de trabajo fueron las siguientes:
e En el segundo experimento los estudiantes fueron organizados en nmcion del
tipo de Master que estaban estudiando: MUTS (Master en Tecnologias
Software), para estudiantes de titulaciones tecnicas y MUTEGS (Master de
Gestion y Tecnologias Software) para estudiantes de tihllaciones de
humanidades y ciencias sociales. De ese modo se fonnaron 5 parejas MUTS, 5
MUTEGS, 10 parejas mixtas MUTS-MUTEGS, 8 eshldiantes MUTS en
modo solo y 8 eshldiantes MUTEGS en modo solo. Una vez considerada la
tihIlacion de los miembros de la pareja la seleccion de cada sujeto para cada
pareja nle totalmente aleatoria.
e En el tercer experimento los sujetos se dividieron en tres gmpos: alutlll10s con
tihllacion de ingenieria tecnica en infonmitica de gestion (ITIG), Ingenieria
Tecnica en Infonmitica de Sistemas (ITIS) e Ingenieria en Infonmitica (II). De
acuerdo al nlllnero de sujetos y a la tihllacion se f0!111aron 32 pares y 32
sujetos trabajaron en modo solo designing.
Las variables dependientes nleron medidas de la siguiente fOlma:
e Dinlsion del Conocimiento, a partir de las punhlaciones de los cuestionarios
de salida (rellenados una vez habian finalizado las rondas de trabajo).
e Renlerzo del conocimiento, ca1culado como la diferencia de puntuacion entre
el cuestionario de salida y el cuestionario de entrada.
En Visaggio CW05) y Bellini et al. (2005) se puede consultar
infonnacion mas de tall ada acerca de la realizacion de los tres experimentos de la
familia.
5. Analisis de la Familia de Datos. Una vez obtenidos los resultados de cada
experimento individual. es impOltante no solo obtener conclusiones locales de
cada experimento. sino extraer unas conclusiones globales. Para analizar los
resultados individuales de cada experimento se aplicaron analisis estadisticos, en
concreto el test de Mann Whitney, dado- que los datos obtenidos no seguian la
distribucion estadistica nonnai. Los resultados individuales de cada experimento
se resumen en la tabla 11.4 (los del experimento 1) Y en la tabla 11.5 (los de los
experimentos :2 y 3):
A partir de los resultados de la tabla. se puede que el nivel de reforzamiento de
conocimiento de los sujetos que aplicaron pail' designing nle mayor que el valor
promedio de los que no aplicaron solo designing siendo ademas los resultados de la
primera ronda estadisticamente significativos (nivel de significacion a <0.05). Sin
embargo. los resultados de las otras dos rondas no n:eron estadisticamente significativos.
10 que pudo ser debido principalmente a una amenaza de la validez experimental deb ida a
que los sujetos no hlvieron un nlerte compromiso con el proceso del experimento. La
CAPiTULO 11: GESTION DEL CONOCIMIENTO 345
primera ronda conto con todos los sujetos, mientras que en las ott'as dos rondas el nlllnero
de sujeto disminuyo. Un cierto nlllnero de sujetos abandonaron en la ronda 2 y en la
ronda 3 porque 10 consideraron como una actividad de fOnllacion innecesaria para el
curso que estaban siguiendo. Este fue un importante aspecto de reflexion que se tllVO en
cuenta en los siguientes expelimentos inc1uyendo mecanismos para la motivacion de los
.
PROMEDlO DE LA PRO:VlEDlO DE LA
ROl'\DA
REH1ERZODE REFUERZO DEL
COl'\OCEvllENTO DE LOS CONOC!:VI1ENTO DE E:STADisnCA (,4 < 0,05)
PARES LOS SOLOS
I: Caso de Uso
I
1,75 -0.25 0,019
II: Diagrama de Clases 2.27
I
1.36
I
0.53
!
III: Diagrama de
1.86 -0.5 I 0.26
-
"
ImeraCClOn
Tabla 11.4. Resultados Estadisticos del Experimento 1
Los datos estadisticos obtenidos a par1ir de los datos del segundo y tercer
expelimento se muestran en la tabla 11.5:
!
",,-
I
SrGKIFIC-\CION
,rlf,'" I ESTADisTICA
TESTS ESTAD1S"rlCOS
, L"tUI:' II
!
I

I
REFORZA:VU"iTO DE
CO;"iiOCrynENTO
Pares MUTS (a)
0.049
I
0,0102
Solos MUTS
2. Italia
Pares lvfUTEGS (al
0.270 0.2[6
Solo lvIUTEGS
Pares ivIUTS (a)
0.023 0.0428
Pares MUTEGS
Pares 5II( a)
0,0309J.2
I
0.086
Solos
I
3. Espana
Pares 3Gestion(a)
0,00017 0,0009
Solos
Pares 3Gestion( a)
0.00000 0.042
Solos
Tabla 11.5. Resultados Estadisticos de los Experimentos 2 y 3
Los resultados de la tabla indican para el segundo expelimento que se obwvieron
diferencias significativas (a<O,05) en la construccion y difusion de conocimiento de los
pares respecto a los solos para los grupos MUTS, pero no fue asi para los MUTEGS. Esto
puede ser debido al hecho de que habia alumnos con habilidades muy distintas. Los
346 CAUDAD DE SISTEMAS INFORMA TICOS RA-ivlA
almllllos de MUTS provenian de estudios de ciencias mientras que los MUTEGS
provenian de otro tipo de estudios. Los alurnnos del curso MUTS se supone que estaban
mas familiarizados con los algoritmos y con el razonamiento deductivo que los alurnnos
MUTEGS. A partir de estas observaciones se puede plantear la hip6tesis de que la
eficacia en la aplicaci6n de pair designing podria verse afectada por la habilidad de los
sujetos a la hora de aplicarlo. De hecho se obtuvo evidencia estadistica de que el
rendimiento de las dos muestras en terminos de conocimiento fue diferente, tal y como se
muestra en la tercera fila de la tabla.
Los resultados del analisis estadistico en el tercer experimento fueron tambien
significativos, ya que se demostr6 que los pares obtuvieron mejores resultados en
construcci6n y difusi6n de conocimiento que los que trabajaron aplicando solo designing.
Estos resultados fueron en general significativos para los tres grupos de titulaciones. S610
en el caso del reforzamiento de conocimiento de los ingenieros superiores no se pudieron
confirmar las diferencias entre solos y pares.
3.1.3.3. Conclusiones
A partir de los resultados anteriores se puede llegar a las siguientes conclusiones:
Pair designing pennite reforzar y difundir mejor el conocimiento que solo
designing.
La eficacia de pair designing a la hora de difundir y reforzar el conocimiento
sobre el disefio podria verse afectada por el tipo de poblaci6n, y en concreto
por su formaci6n academica. Este hecho fue confinnado en el tercer
experimento para las parejas en las que uno de los miembros tenia una
titulaci6n cientifica 0 tecnica y el otro no.
En el caso particular de esta familia de experimentos la realimentaci6n obtenida
con el primer experimento de la familia permiti6 refinar y enfocar la investigaci6n de los
otros dos experimentos.
3.2. Casos de estudio
Los casos de estudio se utilizan para monitorizar proyectos, actividades 0
asignaciones y estan orientados normalmente a analizar un determinado atributo 0
establecer relaciones entre diferentes atributos. Son estudios observacionales (es decir, se
llevan a cabo mediante la observaci6n de un proyecto 0 actividad que esta en marcha)
mientras que los experimentos son estudios controlados (Zelkowitz y Wallace, 1998).
Hay que destacar que la mayoria de los aspectos considerados a la hora de
realizar un experimento se tienen en cuenta a la hora de realizar un caso de estudio, ya
que un caso de estudio requiere los mismos pasos que los experimentos. Asi, por
ejemplo, tambien en un caso de estudio es necesario minimizar los efectos de los factores
RA-MA CAPiTULO 11: GESTION DEL CONOCIMIENTO 347
confusos, sin embargo, no se tiene el mismo control en un caso de estudio que el que se
tiene en un experimento. Los casos de estudio son valiosos porque incorporan cualidades
que un experimento no puede visualizar, por ejemplo, la escala, la complejidad, la falta
de predictibilidad y el dinamismo.
A continuaci6n se resumen los principales aspectos de los casos de eshldio
siguiendo a Yin (2003).
3.2.1. DEFINICION Y APLICACIONES
Se puede definir "caso de estudio" como una investigaci6n empirica que aborda un
fen6meno contemponineo dentro de su contexto real, especialmente cuando:
iii Las fronteras entre el fen6meno y el contexto no son claramente evidentes.
iii Trata con situaciones distintivas tecnicamente en las cuales habra muchas mas
variables de interes que datos.
iii Se basa en mUltiples fuentes de evidencia, con datos necesarios para converger
de una manera triangular.
iii Se beneficia del desanollo prevlO de proposiciones te6ricas para guiar la
obtenci6n y anaIisis de datos.
Se pueden distinguir varias aplicaciones de los casos de estudio:
iii Explicar los supuestos enlaces causales en intervenciones reales que son muy
complejos para las estrategias de encuesta 0 experimento.
iii Describir una intervenci6n y el contexto real en la que ha ocurrido.
iii Ilustrar ciertos t6picos en una evaluaci6n, en modo descriptivo.
iii Explorar las situaciones en las que la intervenci6n que esta siendo evaluada no
tiene un con junto claro de resultados unicos.
iii Estudiar un estudio de evaluaci6n (metaevaiuaci6n).
Aunque, la tendencia general de todos los tipos de caso de esmdio, es que intentan
aclarar una decisi6n 0 conjunto de decisiones: por que se tomaron, c6mo se
implementaron, y con que resultado (Schramm, 1971).
3.2.2. DISENO DE CASOS DE ESTUDIO
Se puede distinguir cuatro tipos de diseiio de casos de estudio segUn sea de
caso unico 0 multiples casos y embebido u holistico.
3-18 CAUDAD DE SISTE:VIAS fNFORM.ATICOS 'iR:\-MA
A) Diseiio de caso unico: es amilogo a un experimento unico y se justifica cuando:
e Representa un caso critico para probar una teoria.
III Representa un caso extrema 0 ll11ico.
e Representa un caso representativo 0 tipico.
e Es un caso revelador (una oportunidad de observar y analizar un fen6meno
previamente inaccesible).
e Es un caso longitudinal.
Holistico
Embebido
Caso simple
caso
Unidad de
anal isis 1
Unidad de
anal isis 2
Caso multiple
Figura 11.5. Tipos de disefio de casos de estudio
B) Multiples casos de estudio: se considera la evidencia mas s6lida y el estudio mas
robusto. La 16gica de replicaci6n es anaJoga a la utilizada en mUltiples experimentos.
Pueden ser a su vez, subdivididos en holisticos 0 embebidos, ya que el mismo
caso de estudio puede involucrar a mas de una unidad de analisis (vease figura 1l.5).
A la hora de elegir entre los diferentes tipos de diseiio, hay que tener en cuenta
que cada caso debe ser seleccionado con cui dado de manera que:
CAPiTULO II: GESTlON DEL CONOCIMIENTO 3-+9
1. Prediga resultados similares (replicacion literal).
2. Prediga resultados contrarios pero por razones predecibles (replicacion teorica).
3.2.3. F ASES DE UN CASO DE ESTUDIO
Las principales fases de una investigacion basada en casos de estudio, se muestran
en la figura 11.6.
Las principales fases de un caso de estudio se resumen a continuacion.
3.2.3.1. Preparacion en la obtencion de datos
La primera fase de preparacion consta de diferentes tareas:
A) FOl1nacion y preparacion para un caso de estudio especifico.
B) Protocolo del caso de estudio. Para mejorar la fiabilidad del caso de estudio
debe establecerse un protocolo, con las siguientes secciones:
@ Una vision general del proyecto de caso de estudio (objetivos y patrocinios.
cuestiones, lecturas relevantes acerca del tema investigado).
@ Procedimientos de campo (presentacion de credenciales, acceso a los sitios.
fuentes de infol1nacion, etc.).
@ Cuestiones de caso de estudio (puestas al investigador). Pueden plantearse a
diferentes niveles:
I. Nivel I . Cuestiones preguntadas a entrevistadores concretos.
2. Nivel 2. Cuestiones preguntadas sobre el caso individual.
3. Nivel 3. Cuestiones preguntadas sobre el patron de hallazgos a 10 largo
de varios casos.
4. Nivel 4. Cuestiones sobre el estudio completo.
5. Nivel 5. Cuestiones nOl1nativas sobre recomendaciones de politica y
conclusiones.
@ Una guia para el infol111e del caso de estudio (contenidos, formato de los
datos. utilizacion y presentacion de otra documentacion, infol111acion
bibliognifica).
350 CAUDAD DE SISTEMAS INFORMATICOS A t v L ~
D
I
S
E
N-
0
Ademas hay que elegir la unidad de toma de datos y la unidad de analisis, que
no deben ser confundidas, vease tabla 11.6.
C) Llevar a cabo un caso de estudio pilato.
,-._.-._.-.-.-.-.-._-_.-
. I
I .
I
I
I
escribir
I
realizar 1 obtener I
Informe de
f-o'------'
I
,--t
caso de ~ conclusiones
I
I caso
I estudio
! individual
intercasos
t
I
1
I
r>
seleccionar
I
modificar
casos
!
teorfa
escribir
realizar 2
I
desarrollar
->
I-!---. Informe de -> 1
teorfa
,.
caso de I
caso
desarrollar
disefiar
estudio
I
I individual
implicaciones
protocolo
i
L.
de recogida
I
politicas
de datos
I
I
I
I
I
escribir
realizar
I...i
escribir conclusiones
:......
restantes
I----->
Informe de
f-o
intercasos
caso de caso
estudio individual
Figura 11.6. Investigaci6n basada en casos de estudio (Yin, 2003)
1
Fu'El\"fE DERECOGlDA DE DATOS
" ",
I
,0 '" ,','
I
I
--:-
I
DEu'NA
CONCLUSIONES DEL
DE Ul'< L,\!)!VIDUO " ESTUDIO
I
,,' ORGANIZAOQN
I Comportamiento indhoidual
.Registros de archivo.
I
ACERCADEUl'<
Actitl.ldes individl.lales
Otros comportamien- Si el caso de estudio
I
Il\!)[V1DUO
Percepciones individuales
tos. actitudes y per- es un individuo
o'
cepciones reportadas
ACERCADE
,I
Como trabaja la organizacion Politic as de personal
I I
Si el caso de estudio
UNA Por que trabaja la Productos de la
es una organizacion
ORGAi'\lZAC!ON organizacion organizacion
Tabla 11.6. Unidad de recogida de datos Ys. Unidad de anaIisis
RA-MA CAPiTULO ll: GESTlON DEL CONOCIMIENTO 35l
3.2.3.2. Recopilacion de evidencias
La evidencia en los casos de estudio proviene de varias fuentes: documentos,
registros de archivos, entrevistas, observaci6n directa, observaci6n participante, artefactos
fisicos, etc. Se deb en seguir tres principios fundal11entales a la hora de reunir datos:
I Varias fuentes de evidencias, la triangulaci6n es el motivo para usar diferentes
fuentes de evidencia. Hay varios tipos de triangulaci6n: de fuentes de datos, entre
diferentes evaluadores, de perspectivas del misl110 conjunto de datos, de
metodos, etc.
I Una base de datos del caso de estudio, el caso de estudio consta de dos
colecciones separadas: datos de la base de evidencia y el infonne del
investigador (articulo 0 infonne).
I Una cadena de evidencias, aumenta la fiabilidad. Asi, por ejemplo, podel11os
establecer la siguiente cadena: cuestiones de caso de estudio -7 protocolo de
caso de estudio (enlaza cuestiones con temas del protocolo) -7 citaciones a
fuentes de evidencia especificas -7 base de datos del caso de estudio -7 infonne
del caso de estudio.
3.2.3.3. Analizar la evidencia del caso de estudio
A la hora de analizar la evidencia del caso de estudio se pueden distinguir tres
tipos de estrategias generales:
I Basarse en proposiciones te6ricas.
I Pensar acerca de explicaciones rivales.
I DesarTollar una descripci6n del caso.
Tambien se pueden utlizar varias tecnicas analiticas especificas:
I Descubrimiento de patrones (pattern matching). que ayuda a l11ejorar la validez
intema.
I Constmcci6n de explicaciones.
I Amilisis de series temporales.
I Modelos 16gicos.
I Sintesis de casos cmzados.
352 CAUDAD DE SISTEMAS INFOIUvlA TICOS RA.-MA
3.2.3.4. Elaboraci6n del informe del caso de estudio
A la hora de elaborar el caso de eShldio, hay que tener en cuenta:
e Audiencia: academicos, profesionales, gmpos especiales (tribunales de tesis),
patrocinadores de subvenciones.
e Si se trata del infonne de un caso de eshldio que fonna parte de un eshldio mcis
amplio multimetodo.
e La estruchlras elegida para el caso de estudio (tabla 11.7).
...
J
PROPOSITO DEL CASO DE ESTUDIO
TIPOnE ESTRUCTIJRA
EXPLICATIVO
I
DESCRIPTNO EXPLORATORIO

I
X
J
x X
I
COMPAR,\TIVA
I
X
I
X X
CRONOLOGICA .. X
I
X
I
X
CONTRUCCION DE
X
I
X
TEORlA
....
"SUSPENSO"
I
X
I I
NO SECUENCIAL
I
X
Tabla 11.7. Estructuras para la composicion de informes sobre casos de estudio
Las principales caracteristicas de estas estmchlras son:
e Estructura analitico-lineaI: es la forma estandar de componer infol111eS de
investigacion. La secuencia de sUbtopicos empieza con la cuestion 0 problema
que esta siendo eShldiado y una revision de la literatura relevante existente.
e Estructura comparativa: repite el mismo caso de eshldio dos 0 mas veces,
comparando descripciones 0 explicaciones altemativas delmisl110 caso.
e Estructura cronologica: presenta la evidencia del caso de estudio en orden
cronologico.
e Estructura de construccion de teo ria: la secuenCIa de los capihllos sigue
alguna logica de construccion de teoria.
e Estructura de suspenso: invierte la estruchlra lineal-analitica y la "respuesta'
directa 0 producto del caso de eshldio se presenta al principio.
e Estructura sin secuencia: la secuencia de los capihllos no tiene ninguna
importancia.
RA.-ivlA C\PiTULO II: GESTION DEL CONOClivlIENTO 353
3.2.3.5. Validacion del caso de estudio
Para que un caso de estudio sea ejemplar, debe poseer ciertas caracteristicas como:
II Ser significativo.
II Ser completo.
II Considerar perspectivas altemativas.
II Mostrar suficiente evidencia.
II Debe componerse en una manera atractiva.
Habra que tener en cuenta adem as los diferentes tipos de validez:
II Validez de constructo: establecer las medidas operacionales COlTectas para los
conceptos que estan siendo estudiados.
II Validez interna: (s610 para estudios explicativos 0 causales, no exploratorios 0
descriptivos) establecer la relaci6n causal en las que ciertas condiciones se
muestra que conducen a otras condiciones, distinguiendolas de las relaciones
espmias.
II Validez externa: establecer el dominio en el que los resultados de un estudio
pueden ser generalizados. Hay que tener en cuenta que las encuestas se basan en
la generalizaci6n estadistica, mientras que los casos de estudio (y los
experimentos) se basan en la generalizaci6n analitica (en la que el investigador
intenta generalizar un conjunto de resultados particulares a una teoria mas
amplia). Se obtiene mediante replicaci6n.
II Fiabilidad: demostrar que las operaciones de un estudio -tales como los
procedimientos de obtenci6n de datos- ploleden repetirse con los mismos
resultados
En la tabla 11.8 se presentan algunas tacticas para conseguir estos tipos de
validez.
3.3. Encuestas
Una encuesta, como sei'ialan Pfleeger y Kitchenham (2001-2003), no s610 es el
instrumento (cuestionario 0 lista de control) utilizado para obtener infol111aci6n, sino que
es un sistema mas amplio que sirve para desclibir, comparar 0 explicar conocimientos,
354 CAUDAD DE SISTEMAS INFOR.,\L'\TICOS RA-ivL>\
actitudes y comportamientos. EI proceso de una en cuesta comprende las siguientes
actividades:
e Fijar objetivos especificos y medibles.
e Planificar la encuesta.
e Asegurar que los recursos apropiados estan disponibles.
e Disefiar la encuesta.
e Preparar el instmmento de recogida de datos.
e Validar el instrumento.
e Seleccionar los paIiicipantes.
e Administrar y calificar el instrumento.
e Analizar los datos.
e Reportar los resultados.
PRlJEB.""S
I
T.kTICA.DECASO DE ESTUDIO
F ASE DE LA INVESTIGAcrON EN
QUE OCURRELA TACTICA
Usar varias fuentes de evidencia
I
Toma de datos
Establecer una cadena de
I
Toma de datos
evidencias
Validez de constructo
Hacer que infonnadores clave
revisen el bon-ador del infonne de
Composicion
caso de estudio
Hacer pal/em-marching
Hacer construccion de
Validez intern a
explicaciones Analisis de datos
Abordar las explicaciones ri\ales
Utilizar model as logicos
I
Utilizar teoria en casas de estudio
Validez externa
imicos
Diseiio de la investigacion
Utilizar l6gica de replicacion en
casas multiples
Utilizar protocolo de caso de
Fiabilidad
estudio
Toma de datos
Desarrollar una base de datos dc
casas de estudio
Tabla 11.8. Tacticas para conseguir la validez de los casos de estudio
I
RA-MA CAPITULO 11: GESTION DEL CONOCI.MIENTO 355
Estas autoras recomiendan tener en cuenta algunos aspectos importantes a la hora
de !levar a cabo una encuesta:
Ii) Disefio de la encuesta. A la hora de disefiar una encuesta se pretende conseguir
que sea efectiva, en sentido de que sea resistente a los sesgos, apropiada respecto
al contexto de la poblaci6n y a la complejidad de la propia encuesta, y efectiva en
coste (dentro de los medios disponibles) y tiempo de los encuestados. El disefio
puede ser: descliptivo, en el caso de un estudio observacional, 0 experimental.
Ii) Tamafio de la muestra, que tiene que escogerse para que esta sea representativa
de la poblaci6n, y abordable en coste (sobre to do si la encuesta requiere
asistencia presencial 0 telef6nica).
Ii) Construccion del instrumento para la encuesta, especialmente la selecci6n de
las preguntas (inteligibles, en numero apropiado, con prop6sito claro, concretas,
etc.) y el f0l111ato del cuestionario (legible, con infol111aci6n e instrucciones
adecuadas, etc.)
Ii) Evaluacion del cuestionario, mediante un foclis group 0 un estudio piloto. Y
estudio de la fiabilidad (test-retest, interobservador, consistencia intern a, etc.) y
validez (de contenido, criterio, constmcto, etc.) del misrno
3.4. Comparativa entre las estrategias empiricas
Los prerrequisitos de una investigaci6n limitan la elecci6n de las estrategias de
investigaci6n. Es posible realizar una comparaci6n de las estrategias de acuerdo a los
siguientes factores:
Ii) Control de la ejecucion. Describe cminto control tiene el investigador sobre el
estudio. Por ejemplo, en un caso de estudio los datos son tornados durante la
ejecuci6n de un proyecto. Si se decide suspender el estudio, por ejemplo por
razones econ6micas, el investigador no puede continuar con el estudio. Por el
contrario en un experimento el investigador tiehe control pleno sobre la ejecuci6n.
Ii) Control de la medicion. Es el grado en el que el investigador puede decidir las
medidas que deben ser recogidas y las que deben ser incluidas 0 excluidas durante
la ejecuci6n del estudio. En una en cuesta no es posible incluir medidas.
Ii) Coste de la investigacion. Dependiendo de la estrategia elegida, el coste asociado
a la investigaci6n varia. Esto esta relacionado, por ejemplo, con el tamafio de la
investigaci6n y las necesidades de recurs os. La encuesta es la estrategia de men or
coste, ya que no requiere gr'andes cantidades de recursos.
356 CAUDAD DE SISTEMAS INFOJUv!A TICOS
e Facilidad de replica. Se refiere a la facilidad con la que podemos replicar la
situacion base que estamos investigando. Si la replicacion no es posible, no se
puede llevar a cabo un experimento. Gracias a la posibilidad de replicacion de los
expelimentos sus resultados son mas generalizables.
La tabla 11.9 muestra cada uno de los factores mencionados antes para cada una
de las estrategias y se puede usar como guia a la hora de decidir que estrategia seguir.
FACTOR
I
ENCUESTA
I
CASO DE ESTI5DIO
I
EXPERiiY1E:STO
Control de la ejecuci6n
I
No
I
No
I
Si
Control de la medici6n
I
No
I
Si
I
Si
Coste de Investigaci6n
I
Bajo
I
Medio
I
Alto
Facilidad de replica
I
Alto
I
Bajo
I
Alto
Tabla 11.9. Factores de las estrategias de investigacion (Wohlin et al., 2000)
e Aurum, A., Jeffery, R., Wohlin, c.. Handzic, M. (eds.) (2003). j\lianaging
So.fhmre Engineering KnOlrlegde. Berlin, Springer. Esta recopilacion reline
los trabajos mas importantes sobre gestion del conocimiento en ingenieria del
software a nivel intemacional.
e Kitchenham. B., Pfleeger. S . Pickard. L.. Jones. P., Hoaglin. D . El Emam, K ..
Rosenberg, L 2002. Preliminary Guidelines for Empirical Research in
So.fhmre Engineering. IEEE Transactions on Software Engineering, 28(8).
721-734. Este articulo da pautas sobre como llevar a cabo investigacion
empirica en ingenieria del software de manera rigurosa.
e Pfleeger. S.H. y Kitchenham. B.A. (2001-2003). Principles of SlIlWY
Research. Software Engineering Notes. ACM. Se trata de una serie de seis
articulos en los cuales se presentan los principios para llevar a cabo encuestas
de una manera rigurosa.
Revista "Empirical So.fhmre Engineering". es una
Kluwer especializada en Ingenieria del
http://\\ww.kluweronline.com/issn/13 82-3256.
revista de la editorial
Software Empirica.
e Vizcaino. A. y Piattini, M. (eds.) (2006). Gestion del conOClIIllento en
Ingenieria del So.fhmre. Universidad de Castilla-La Mancha. En esta
recopilacion se abordan diversos aspectos de la gestion del conocimiento
aplicada al desanollo y mantenimiento del software: uso de ontologias.
henamientas, metodos. etc.
e Wohlin c.. Runeson P., Host M., Ohlson M., Regnell B. and Wesslen A.
(2000) Experimentation in So.fhmre Engineering: An Introduction. Kluwer
Academic Publishers. Juristo, N. y Moreno. A.M. (2001) Basics ofSo.fhmre
Engineering Experimentation. Kluwer Academic Publishers. Estos dos libros
[ RA-MA CAPiTULO 11: GESTIO;-'; DEL COl\OCIMIENTO 357
han sido los primeros en abordar rigurosamente la experimentaci6n en el
campo de la Ingenieria del software.
Iil Yin, R.K. (2003). Case Study Research: Design and Methods. Thousand
Oaks, Sage Publications. Es el libro mas representativo para la utilizaci6n de
casos de estudio, si bien no esta adaptado ni a la Ingenieria del Software ni a
los Sistemas de Infonnaci6n.
Iil w\vw.cebase.orQ/ EI Center for Sojt.l'([re Engineering
(CeBASE) reline modelos empiricos con el fin de proporcionar a las
organizaciones guias para seleccionar tecnicas y modelos. recomendar areas
de investigaci6n y sopOliar la fonnaci6n en ingenieria del software.
<!;) http://ww\v.iese.t112:.de/ISERN/ La red ISERN (Jntel71acional Sofhrare
Empirical Research Net1l'Ork) agrupa a los principales investigadores en el
campo de la Ingenieria del Software Empirica.
6. ERCiCIOS
I. Para la obtencion de conocimiento uno de los principales metodos es la
realizaci6n de un estado del ane 0 revision sistematica sobre 1a cuesti6n que se
quiere conocer. Analice la propuesta de Kitchenham (2004) "Procedures for
Perfonning Systematic Reviews". Keele University. 28. Nllmero de lnfonne
0400011 T.l. sobre c6mo llevar a cabo estados del arie de manera sistematica.
2. Siguiendo el metodo propuesto por Kitchenham, realice el estado del arte de la
gestion del conocimiento en la ingenieria del software, destacando que aspectos
(tecnologicos, organizativos. metod610gicos. etc.) han recibido mayor atenci6n
hasta el momento.
3. Siguiendo la propuesta de Lawion (2001) que se presenta en la figura 11.1,
analice la arquitectura de gesti6n de conocimiento de su organizaci6n
identificando las posibles deficiencias de la misma.
4. Si en su organizacion se utilizan sistemas cooperativos y de trabajo en grupo 0
Intranets estudie la utilidad de los mismos como sistemas de gestion de
conocimiento.
5. Presente un plan razonado (costes, calendario, etc.) de implantaci6n de una
factoria de experiencia en su organizacion. (, Cuales cree que seran los principales
obstaculos que se encontraria en la implantacion de una estructura de este tipo?
358 CAUDAD DE SISTEMAS I1'IFORMA TICOS RA-MA
6. Lleve a cabo un estudio sobre el significado y las implicaciones desde el punto
de vista tanto investigador como practico del concepto de Evidence-based
Software Engineering (Ingenieria del Software basada en evidencias).
7. Replique alglin experimento sobre alglin tema de su interes, como por ejemplo,
sobre los beneficios de pair designing para la mejora de la difusi6n y el
reforzamiento del conocimiento (vease apartado 3.1.3).
8. Lleve a cabo un caso de estudio sobre la implantaci6n de alguna metodologia 0
herramienta en su organizaci6n.
9. T. Lethbridge llev6 a cabo una en cuesta para deterrninar en cuales areas de la
infonniitica pensaban los profesionales que necesitaban una mejor forrnaci6n
(vease "11171at Imowledge is important to a software professionaf', IEEE Computer,
Mayo 2000). Lleve a cabo una encuesta similar en su organizaci6n y compare los
resultados entre las dos encuestas.
ACT
ACP
AEC
AENOR
AFNOR
AIO
AlvlFE
ANSI
API
ARC
ARIS
ASQ
BSI
CAF
CALDEA
CASE
CBA-IPI
CMM
Cl'vLvfI
CMMI-SE/SW/IPPD
COCOTS
Adaptatil'e Control of Thought
Area Clave de Proceso
Asociaci6n Espanola de la Calidad
ACRONIMOS
Asociaci6n Espanola de Nonnalizaci6n y Certificaci6n
Association Franqaise de Nonnalisation
Abstract Interaction Object
Analisis Modal de Fallos y Efectos
American National Standard Institute
Application Programming Inteljace
Appraisal Requirements for CALM!
Architecture of Integrated Information Systems
American Societyfor Quality
British Standards Institute
CMMAppraisal Framework
Cali dad de ALmacenes de Datos
Computer Aided Software Engineering
CJIM-BasedAppraisalfor Intemal Process Improvement
Capability Maturity Model
Capability }v/aturit)' Model Integration
CMADfor Systems Engineering. Software Engineering and Integrated
Constl1lctil'e COTS
360 CAUDAD DE SISTEMAS I0:FORMA TICOS
COQ
CORBA
COTS
CPL
CPR
CPU
CRE
CTh
DDE
DEC
DOE
EFQ\l
ElA
ElAIS
EIS
EJB
E\
EOQ
ER
E\".-\:vIEC.-\L
F\lE
F\lEA
FMESP
FPKD
GC
GCR
GQM
GUI
HCI
HTML
I+D
L-\-SI
IEC
IEEE
IFPUG
IMS
COSI OfQllaliZl', Cosle de la Calidad.
C0ll11110n ObjecI Reqllesl Broker ,lrchileC1Iire
C oll1l11ercial-O(l: The-Shelf'
Capaciz\ Process Coger
Core Plan Repre.'ientatioJ]
Capacil)' Process Gpper
COTS-Based ReqIlirenlelltS Engineering
Comite Tecnico \acional
Disefio de Experimentos.
Digiwl Eqllipmel11 COIporulicm
Desing OfExperimel11s. n'ase DDE
European Foundation tor Quality \lanagement
Eiecfl'(JIlic Indllslries .llIiance
Elec!rOlzic Jndzlsrrius .llliwice inlerin1 Slolldurc/
Entomo de Ingenieria del Sot1\\'are
Enterprise J.-\ \ '.-\ Beans
European :\onn
Europ-=an Organization for Quali!)"
Entidad-Inten'elacion
E\'.-\luaci0n y \lEjora de la C\Lidad de los datos y de la intomlUci6n
Formal \kthods Europe
F ailllre .lIodes and E.t/cCls Ana(l'sis, \'ease .-\\,lFE
Frumel\Drkj!Jr Ihe .\Joe/ding and EmIllalion o/'So/il!'C1I'e Processes
Fuzzy Prototypical Knowledge Discovery
Gesti6n de la Configuraci6n
Grupo Critico de Referencia
Goal Question \!etric
Graphical User Interface
Human Computer Interaction
Hypenext \!arkup Language
Investigaci6n y Desarrollo
Investigaci6n-Acci6n en Sistemas de Infoffilaci6n
International Eleclroleclmical Commission
Institute of Electrical and Electronics Engineers
International Function Point Users Group
indice de Madurez del Software
;;; R.-\-MA
RA.-ivLA.
IPD-CMM
IPR
ISO
JTCI
JUSE
KDD
KIF
KP
KPA
LCI
LCS
LMP
LOC
LOPD
MDC
ivllT
ivL'vlHQ
Miv[LC
MOF
OCL
OMG
PDCA
PERT
PHVA
PI
PIF
PMBOK
PSEE
PSL
PSM
PSP
QFD
RUP
SC
SCA.MPI
SCE
Inregrated Prodllct De,eloplllenr Capability MallIrity Model
in dice de Priori dad de Riesgo.
InrernationalStandardi::ation Organi::ation
Joint Technical Committee I
Japanese Union of Scientists and Engineers
Knowledge Discovery in Databases
Knowledge Il1Ierchange Format
Key Practices (Pnicticas clave)
Key Process Area (Vease ACP)
Limite de Control Inferior
Limite de Control Superior
Lenguaje de Modelado de Procesos
Lines Of Code
Ley Organica de Proteccion de Datos
:\leta Data Coalition
Massachllsells Institute ofTecl1l1ology
Multimedia House of Quality
,\/eaSllre Model L!ie Cycle
.\/eta Object Facility
Object Constraint Language
Object Management Group
Plan. Do. Check. Act (Vease PHCA)
Program Emluation and Re"iew Technique
Planificar. Hacer. Verificar. Actuar
Productivity Index
Process Interchange F 017lzat
Project .\JanagellIent Body o/Knowledge
Process-centered So/tv-.-are Engineering Ent'ironment
Process Spec!izcalion Language
Practical Sofnmre .\1easllrellIenr
Pel:wnal Sofnmre Process
Quality Function Deployment
Rational Cni/zed Process
Subcomite
Standard CMAll Appraisal Alethodfo!" Process IlIlpro,"elllenr
So/hrare Capability Emillation
ACRONIMOS 361
362 CAUDAD DE SISTElvLAS INFORMATICOS
SEI
SGBD
SGC
SI
SMSDM
SPEM
SQL
SQuaRE
SUMI
SUS
SW-ClvL'v!
TC
TOO
TQM
TSP
UEM
UML
LJNE
UPM
WfMC
WG
SO/Al'are Engineering Institute
Sistema Gestor de Base de Datos
Sistema de Gestion de la Calidad
Sistema de Informacion
Standard Metamodel for Sofnmre De\'elopme!1/ Methodologies
SO/Mare Process Engineering Metamodel
Stl1lctured Quel)' Language
Sofill'are Product Quality Requirements and Emluation
So/nmre Usability /lJeasuremel1l!m'entOl)'
System Usability Scale
Capability Maturity Model for SO/Mare
Technical Committee.
Tecnologia Orientada a Objetos
Total Quality Management
Team Software Process
Usability Emillation Methods
u'n!fied .\/odeling Language (Lenguaje Unificado de Modelado)
Una Norma Espanola
Unified Process Model
Management Coalition
Working Group. Grupo de Trabajo.
RA-MA
BIBLIOGRAFiA
Abdel-Hamid, T, Y Madnick, S. (1991). Sofnrare Project Dynamics: An IllIegrated Approach. Prentice-Hall.
Acuna. S. T., De Antonio, A, Ferre, x., Mate, L y Lopez, M. (2001). "The Software Process: Modelling. Evaluation
and Improvement". In S. K. Chang (Ed.), Handbook of Sofnrare Engineering and Knowledge Engineering. (Vol. l.
Fundamentals .. pp. 193-237). New Yersey (EE.UlJl. World Scientific.
Adamson. Christopher y Venerable, Michael (1998). Data Warehouse Design Solutions. Jo1m Wiley and Sons.
USA.
AFMC (1994) Acquisition - Sofnrare DCI'elopmelll Capability Emluation, Air Force Materiel Conmland (AFMC)
Pamphlet 63-103, Volumes I and 2, June IS, 1994.
A1bretch, A. (1979). ivfeasuring Application Developmelll Productivity. Proceedings of the IBM Application
Development Symposium, Monterey, pp. 83-92.
Althoff, K. Y Pfahl. D. (2003) "Integrating Experienced-Based Knowledge Management with Sustained Competence
Development". En Afanaging Sofnrare Engineering Knowlegde. Aurum, A .. Jeffery. R., Wohlin. c., Handzic, tv!. (eds.)
Berlin. Springer.
Ambrio1a, V., Conradi, R. y Fuggetta. A (1997). "Assessing Process-Centered Software Engineering
Environments". ACM Transactions on Sofnrare Engineering and Method070gy 6,3 (July 1997), pp.283-328.
Anderson, J. R. (1983). The architecture of cognition. Cambridge: Harvard University press.
April, A. Y Coallier, F. (1995). 'Trillium: a model for the assessment of telecom software system development and
maintenance capability". 2nd IEEE Software Engineering Standards Symposium, pp. 175.
April, A, Huffman. J., Abran, A. y Dumke, R. (2005). "Software Maintenance Maturity Model: the software
maintenance process model'. Joul7lal ofSofnrare Maintenance and Emlution: Research and Practice 17, pp. 197-223.
Arbaoui, S., Haurat A .. Oquendo, F .. Theroude, F. y Verjus. H. (2003). "Languages and Mechanisms for Software
Processes and Manufacturing Enterprise Processes: Similarities and Differences". Proceedings of the 5th Intemational
Co/?terence on Ente/prise biformation Systems IICElS 2003), pp. 474-482.
364 CAUDAD DE SISTEMAS RA.-MA
Aurum. A .. JetTery. R .. Wohlin. c.. Handzic. M. (cds.) (2003). Managing Sojilrare Engineering Knowlegde. Berlin.
Springer.
Baldrige (2005). Criteria .tin- PerF017I1WICe Ercellence. The Malcolm Baldrige National Quality Award Program.
Disponible en: http:\\ww.gualitv.nisLgov CCltimo acceso Agosto de 2006).
Ballou D .. Wang R .. Pazer. H .. y Tayi. G.K. "Modeling Information Manufacturing Systems to Determine
lnfornmion Product Quality". Management Science 41(4). pp. 462-484. 1998.
Ballou. D. Y Tayi. G.K. (1996). ";-'Ianagerial Issues in Data Quality". Proceedings of the First International
Conlerellce on h?/ol7lwtion (fClQ '96). pp. 186-206.
Ballou. D. Y Tayi. G.K. (1999) "Enhancing data quality in Data Warehouse Fnvironments". Communications oltlze
ACAf. 1'0142. So I. January 1999.
D .. Madnick. S., y Wang. R. (2004). "Special Section: Assuring Information Quality". Journal of
.\Ianagemelll h?jol7lwtion Systems. 20(3). pp. 9- I I.
Ballou. D .. Wang. R .. Pazer. H .. y Tayi. G.K. (1998). "Modeling Infonnation Manufacturing Systems to Determine
Infornmtion Product Quality". Management Science, 44(4). pp. 462-484.
Balzer. R. Y Narayanaswamy. K. (1993). "Mechanisms for Generic Process Support". Proceedings oOhe First AC\!
SIGSOFT Symposiulll 011 FOlindatiollS ofSojnmre Enginering. AClvL Software Engineering Notes. 18(5), December 1993.
Bandinelli. S .. Di Nitto. E. y Fuggetta. A. (1996). "Supporting Cooperation in the SPADE-I Em'ironmenCIEEE
Transactions on Sojnmre Engineering. 22(2), December 1996.
Bandinelli. S .. Fuggetta. A .. Ghezzi. C. (1993). "Software Process Model Evolution in the SPADE Environment".
IEEE Transactions on Sojnmre Engineering. I 9( 12). December 1993.
Bandinelli. S .. Fuggetta, A .. Lavazza. L Loi, M. y G. P. (1995). "Modeling and improving an industrial software
process". IEEE Transactions on So./nmre Engineering. 21(5), pp. 440-454.
Bansiya 1. y Davis c.. (2002). "A Hierarchical for Object-Oriented Design Quality Assessment". IEEE
Transactions Oil Soll1mre Engineering, 2S(I). pp. 4-17.
Bansiya L Etzkorn L Davis C. y Li W. (1999). "A Class Cohesion Metric For Object-Oriented Designs". Tlze
JOllrnal oj'Ol'iect-Oriellled Programming, 11(S), 1999, pp. 47-52.
Barghouti. N .. Rosenblum. D .. Belanger. D. y Alliegro. C. (1995). "Two case studies in modelling real. corporate
processes". Sojnmre Process -IlIlprol'emclll and Practice (Pilot Issue). pp. 17-32.
Basili. V. R. y Rombach, H.D. (1988) "Towards A Comprehensive Framework for Reuse: A Reuse-enabling
Software Environment". Uni\'ersit:y of Maryland. CS-TR-2I5S. UAllACS-TR-SS-9:!. December 1988.
Basili. V .. Shull. F. y Lanubile. F. (1999). "Building knowledge through families of experiments". IEEE
Transactions on Sojnmre Engineering. 25(4). pp. 435-437.
Basili. V.R. Y Caldiera. G. (1995). "Improve Software Quality by Reusing Knowledge & Experience". Sloan
.\fanagemel/l Redl!\\'. \IIT Press, 37(1): pp. 55-64.
Basili. V.R. Y Reaman. C. (2002). 'The Experience Factory Organization". IEEE So/nmre. 19(3): pp. 30-31.
Basili. V.R. Y Weiss. A. (1984) "\Iethodology for Collecting Valid Software Engineering Data". IEEE Transactions
on Sojnmre Engineering. SE-IO. ]\;0. 6. pp.728-738. 1984.
RA.-MA BIBLlOGRAFiA Y REFERENCIAS 365
Basili. V.R .. Costa. P. Lindvall. M .. N!endonca. M .. Seaman. C. Tesoriero. R .. y MaIyin Zclkowitz. M. (2001). "An
Experience Management System for a Software Engineering Research Organization ". ::6,i. Annl/a/ .VASA Goddard Sojilmre
Engineering Workshop. Pp. 26-35.
Batini C. Ceri S. y Navathe S. (1992). Concepllial daTabase design. An emily relationship approach. Benjamin
Cununings Publishing Company.
Batista J. y Figueiredo A. (2000). "SPI in very small team: a case with CMM". Sojilmre Process ImprOl'elllelll and
Praclice 5 (-I). 2-13-250.
Becker-Komstaedt.. U .. Bella. F .. .\!linch. L Neu. H . Ocampo. A y Zenc!. J. (2003). SPEARM!:VTf" i Lser
:\[anual. Fraunhofer Institute. lESE report n 072.02;E .. v. 1.1. 2003.
Belkhatir. N.. Estublier. J y .\!elo. W.L (1991). "Adele2: A Support to Large Software Development Process".
Proceedings of the 1st IllIel'l1ational Con/i!rence on the Sojilmre Process. Redondo Beach CA (USA). October 1991.
Ben-Shad. I. y Kaiser. G. (1994). "A Paradigm for Decentralized Process Modeling and its Realization in the Oz
Environment". Proct!edings a/the 16th Imel7lational Con/i!J'cncc on Sojilmre Engineering.
Bemardez. 8.. Duran. A .. y Genero. NL (200-1). "An empirical review of use cases metrics for requirements
\erification". Actas del SoJilmre Measurement European Fomlll (SMEFO-l).
Bertoa. M. F. y Vallecillo. A. (2002). "Quality Anributes for COTS Components". 6th Intel'l1ational Workshop on
Qual1lilati\'e Approaches ill So/ilmre Engineering (QAOOSE'2002). Malaga
Bertoa. !\!.. Troya. 1.M .. y Vallecillo. A. (2005) "Measuring the usability of software components". JOlll7lal 0/
5.\slems and Solimre. Agosto 2005.
Bevans N. (2000). Imrodllction to l/sabili(r mallirizr asseSSlIlenl. Serco Csability Senices. Serco. Ltd.: London. 10.
Disponible en: httn:..www.usabilitv.serco.comtnl111Ddocuments.}.!aturitv assessment.opLodf (Ultimo acceso en Mayo de
2006)
Bobrowski. M .. Marre. M .. y YaIlkele\ich. D. (1998) "A Software Engineering View of Data Quality". Proceedings
o.rSecond IlIIel7l(J/ional So.filmre Quality in Europe. Belgium. November 1998.
Boegh.1.. DePanlilis S .. Kitchenhanl B .. Pasquini A. (1999). "A for Software Quality Planning. Control.
and Evaluation". IEEE SO/l1mre 23 (2). marzoabril. pp. 69-77.
Boman M. Bubenko l .. lohannesson P. y Wangler 8. (1997). ConceptuaIJ/odelling. Prentice HalL
Botella. P .. X. Burgues. 1. P. CanalIo. X. Franch. 1. A. Pastor y t. Quer (2003). "Towards a Quality Model for the
Selection ofERP Systems". Component-Based So.filrare Quality. pp. 225-245.
Boudier. G .. Gallo. F .. Minot. R. y Thomas. 1. (1988). "An Oven'iew of PCTE and PCTE-". Proceedings o.r
SIGSOFT'88: Third 5.l7npOSillfll on so.rl1mre De\'elopmelll EI1\ironmellls. November 1988.
Bouzeghoub. M. y Kedad. Z. (2000) "A quality-based framework for Physical Data Warehouse Desi&'Il".
Proceedings or the IlIIel71C1tional Workshop on Design and J/anagemelll o.r Data Warehouse (DMDH"2000). Stockholm.
Sweden. June 5-6. 2000.
Bo\ee. ;V!" Srivastuva. R.P .. y Mak. B. (2003). "A Conceptual Framework and Belief-Ftmction Approach to
Assesing Overall Infonllation Quality". IlIIel71ational Journal o.(IlIIelligenl 5.nlems. 1'01 18. pp. 51-7-1.
Briand. L. El Emam K. y Morasca S. (1995). "Theoretical and empirical validation of software product measures".
Technical report ISER.V-95-03. Intemalional Sojilmre Engineering Research .\ieMork.
366 CAUDAD DE SISTEMAS INTOIUvlA TICOS RA-?vt.A.
Briand. L Morasca S. y Basili V. (1996). "Property-Based Software Engineering Measurement'". IEEE
Transactions on Sojhrare Engineering. 22( I). pp. 68-86.
Briand. L Morasca. S. y Basili. V. (2002). "An operational process for goal-driven definition of measures". IEEE
Transactions on So/nrare Engineering, 28(2), pp. 1106-1125.
BringeL H .. Caetano. A .. y Tribolet. 1. (2004). "Business Process Modeling Towards Data Quality Assurance".
Proceeding 0/ICEIS'2004 Porto (Portugal). pp. 565-568.
Brito e Abreu F. y Carapuya R. (1994). "Object-Oriented Software Engineering: Measuring and controlling the
development process". 4th Int Con(erence on So/nrare Quality. McLean. VA. USA.
Brito e Abreu F. y Melo W. (1996). "Evaluating the Impact of Object-Oriented Design on Software Quality".
Proceedings 0/3rd Il1Iel71ational Metric Symposium. pp. 90-99.
Burgess. M.S.E .. Gray. W.A .. y Fiddian. N.J. (2003) "A flexible quality ftamework for use within information
retrieval". Proceedings a/the Eighth International COl!lerence on b!formation Qualit)' (lCIQ ']003). pp. 297-313
Burke. B. (2002). "Evolving Architecture Maturity. Enterprise Planning and Architecture Strategies". EPAS Meta
Practices 67. Meta Group.
Burzy11ski T. (1998). "Establishing the Environment for Implementation of a Data Quality Management Culture in
the Military Health System". Proceedings o/the Third Conference on In/ol7nation Quality ICIQ '1998. pp. 18 ..... 6
Bymes. P. y Philips. M. (1996). Sojhrare Capability Emluation I ersion 3.0. Method Description. Technical Report
CMUiSEI-96-TR-002 ESC-TR-96-002.
Calero. C (2001) Definicion de III/ Conjunto de Merricas para la Afalllenibilidad de Bases de Datos Relacionales,
Actims y Objeto-Relacionales. Tesis DoctoraL Universidad de Castilla-La Mancha.
Calero. C y Piattini. M. (2002) "Metrics for databases: a way to assure the quality". En: b!lormation and Database
Quali(\. Kluwer Academic Publishers. Pp. 57-84. 2002
Calero. C. Piattini. ivl.. PascuaL C. y Serrano. M.A. (2001). "Towards Data Warehouse Quality Metrics". Aetas del
3rd Workshop on Design and Managemelll olData Warehouses (DMDW'OI). Agosto. 2001
Caho-Manzano. 1.A. (2000). Merodo de Mejora del Proceso de desarrollo de sistemas de informacion en la
pequel1a y medicllIa empresa. Tesis Doctoral. Universidad de Vigo.
CampbelL D. y Stanley. 1. (1963). E.\perimelllal and quasi-e.\perimelllal desigllS .lor research. Boston. Houghton
Mifflin Co
Canfora. G .. Garcia. F .. Piattini. M .. Ruiz. F. v Visa!.!!.!io. CA. (2005). "Pair Desi!.!Oing as Practice for Enforcin!.! and
Diffusing Design Knowledge". Joumal o{So/nrare and Emlution: ReseCII":ch ;;nd Practice. Wiley 17(6). pp.
401-423.
Canfora. G .. Garcia. F.. Piattini. ivl.. Ruiz. M. y Visaggio. A. (2005). "A Family of Experiments to Validate ?vletrics
for Software Process Models". Joumal o.{S),stems and So.{l\mre. 77 (2). pp. 113-129.
Cant. S .. Henderson-Sellers B.. y Jeflery. R. (1994) "Application of Cognitive Complexity Metrics to Object-
Oriented Programs". Journal o./Dbject-Oriellled Programming. 7(4). 199,). pp. 52-63.
Cant. S .. Jeffery R. y Henderson-Sellers B. (1992). "A Conceptual Model of Cognitiw Complexity of Elements of
the Programming Process". b!lol7l1atioll and Sofilrare Technology. 7, 1992. pp. 351-362.
i'; R.-'\-MA BIBLlOGR.-'\FiA Y REFERENCL-'\S 367
Cantone. G. y Donzelli. P. (1000). "Production and maintenance of software measurement models". Journal of
Software Engineering and Knowledge Engineering. 5. pp. 605-616.
Carbone M. y Santucci G. (1001) "Fast&&Serious: a UML based metric for effort estimation. 6th Intemational
ECOOP Workshop on Quantitati\'e Approaches" in Object-Oriented Software Engineering (QAOOSE"]OO]). 1002. pp. 35-
44
Card. D.N. (l995). "The R.-,\D Fad: Is Timing Really EYerythingry"IEEE Sofnmre. Septiembre, Pp. 19-11.
Carretero. A. Ingelmo. P .. Sanchez-Infantes. lA. Sanchez-Infantes. P .. y Sanchez. 1.A.(l999). Calidad. Madrid:
Editex.
Carver. 1.. 1accheri. L.. Morasca. S. y Shull. F. (1003). "Issues in Using Students in Empirical Studies in Software
Engineering Education". Proceedings of the 9th IllIemational SO/Mare Metrics Symposium (AfETRlCS'03). pp.139-251.
Cechich. A, Piattini. M. y Vallecillo. A (eds.) 2003. Component-Based Sofnmre Quality: Methods and Techniques.
Springer. Alemania. Lecture Notes in Computer Science 2693
Chidamber S. Y Kemerer C. (1994). "A Metrics Suite for Object Oriented Design". IEEE Transactions on SojAmre
Engineering. 10(6). pp. 476-493. 1994.
Cianmmi. C.A. Tsiakals. 1.1 .. West. 1 (1002).150 9001: ]000 E.'plained ]nd Edition. Quality Press
Ciolkowski. M .. Shull. F. y Biffl. S. (2002). "A Family of Experiments to Investigate the Influence of Context on the
Effect of Inspection Techniques". Proceedings of the 6Th International Conterenee on Empirical Assessment in Sofnmre
Engineering (E.iS!. Keele (UK). pp. 48-60.
CMMJ. (2002) Capabili(\' Maturity Moder Integration (CMIIl'\!). Version I.I C:II[f\fjor Systems Engineering.
SO/Amre Engineering. IfIlegrated Product and Process De\'eIopment and Supplier Sourcing (CMMI-SE;SWilPPDfSS, VI. I )
Staged Repre-sentation CMUfSEI-2002-TR-012 ESC-TR-2002-012. en http://www.sei.cmu.edu
!publications
/
documents
i
02.reports:02tr002.hunl (ultimo acceso rvlarzo 2006)
Conradi. R .. Larsen. 1 .. Nguyen. M .. Munch. B .. Westby. P .. Zhu. W .. 1accheri. M .. Liu. C. (1994). "EPOS: Object-
Oriented and Cooperative Process Modelling". En A Finkelstein. 1 Kramer. and B. Nuseibeh. editors. SojAmre Process
Modelling and Technology. Research Studies Press Limited (1. Wiley).
Cook. T. y Campbell. D. (1979). Quasi-e.'perimefllation: design and anaZ\'sis issues for field settings. Boston,
Houghton Mifflin Co.
Crawford, 1 (2002). Proiect Managemefll Maturi/)' :Hodel Pro\'iding a Prol'en Path to Project Management
Ercellence. Publisher Marcel Dekker/Center for Business Practices.
Crosby. P.B. (1979). Quali(1" is Free. Nueva York. McGraw-Hill.
Cuevas, G .. Amescua, A .. San Feliu, T .. Arcilla. M .. Cerrada. lA. Calvo-Manzano. lA., Garcia Cordero. M. (2002).
GesTion del Proceso Sofnmre. Ed. Centro de Estudios Ramon Areces. S.A.
Cugola. G. y Ghezzi. C. "Software processes: a retrospective and a path to the future". SO/Amre process -
ImprOl'ement and practice. vol. 4. pp. 101-123. 1998.
Curtis, B.. Hefley, B. y Miller. S. (1001). People Capabili(\' Malllri/)' Model (p-CIL_n. Versioll 2.0. Software
Engineering Institute. CMUSEI-200 I-MM-OO I.
Curtis. B .. Kellner. M. y Over. 1 (1992). "Process Modeling". COlllmullications olACI/. 31( II). pp. 1268-1287.
368 CAUDAD DE SISTEMAS lNFORMATICOS gRA-?vlA
Daich. G. y Giles. A. (1995). "Universal Tools". Crosstalk. The Journal ofDe/ense Sofnrare Engineering.
Septiembre 1995.
Dami. S .. Estublier. J. y M. Amiour. (1998). ".-\PEL: a Graphical Yet Executable Fom1alism for Process Modeling".
Klwrer Academic Publishers. pp. 60 - 96. Boston. January 1998.
Dawnport. T.H. y Prusak. L. (2000). Working KnOlv/edge. Haryard Business School Press.
Davidson. B.. Lee. Y.L y Wang. R. (200'+). "Dewloping data productions maps: meeting patient discharge data
submission requirements". International Journal Healthcare Technology and Mallagemelll, 6C!). pp. 223-2'+0.
Dedeke. A. (2003). "Managing Processes for Information Quality: A Framework for Process !vletadata
Development"'. Proceedings of the Eigth IllIernational Conference on b!formation Quality (lCIQ '2003). pp. 22'+-233.
Deiters. W. Y Gruhn. V. (1990). "Managing Software Processes in the Environment MELMAC. Proceedings of the
Fourth Symposium on Sofl1rare De\'elopmelll Enl'ironmel1ls. December 1990.
Deiters. W. Y Gruhn. V. (1991). "Software process analysis based on FlJNSOFT nets". Systems Modelling
Simulation. 8('+-5). pp. 315-325.
Del Peso. E. (2000). Ley de Proteccion de Datos: La nuem LORTAD. Madrid. Diaz de Santos.
Deming W. (1986). Ollt olthe Crisis. MIT Center for Advanced Engineering. Cambridge.
Department of Defense U.s.A (1999). Systems Security Engineering Capability Maturity .Hodel (SSE-OIM).
I'ersion 3.0. Department of Defense. Arlington VA. 326.
Dernian1e J.e.. Wastell D .. y Kaba A. (eds) (1999). Software Process: Principles. Methodology and Technology.
LNCS W1500. Springer Verlag. January 1999.
Derniame. J.C Y Oquendo. F. (200-+). "Cuestiones Clave y Nueyos Retos en la Tecnologia de Proceso Software" .
.YO 1:4 TICA 11" 171.
Derr. K. (1995) ApP(\'ing OMT. SIGS Books. Prentice Hall. New York. 1995.
Deustch. M.S .. y Willis. R. R. (1988) Sofnrare Quality Engineering. A Total Technical Managemelll Approach.
Chapter 3. Prentice Hall. Englewoods Cliffs. NJ.
DoC (2003). US Departmelll of Commerce. fTArchitecture Capability .i/atllrit)' Model rACif.ifJ. The Open Group:
Burlington ivlA. 2003: Disponible en: (ultimo
acceso en Agosto de 2006).
DRA.E (2006). DicciOllario de la Real Academia de la Lengua.
Dumke. R. Y Winkler. A. (1997) "CAME Tools for an Efficient Software Maintenance". Proc. of the Euromicro'97.
March 17-19. Berlin.pp. 74-81.
Dunaway. D. K. CJIM S.il -Based Appraisal/or Intemal Process fmprmement. (CBA IPf) Lead Assessor's Guide
(CMUSEl-96-HB-003r Software Engineering Institute. Carnegie Mellon UniYersity. Pinsburgh. 1996.
Dunaway. D. Y Masters. S. (200 I). Cif.illi1 -Based Appraisalfor IlIIemal Process fmpra\'cmelll (CBA IPI). Version
1.2 Method Description.
\,' Y REFERENCIAS 369
Dybil. T.. (2003) "Factors of software process improvement success in small and large organizations: an empirical
study in the scandinavian context"". European Sofnmre Engineering COI!(erencl! (ESEC! FOlllldafions of Sojilrare
Engineering (SIGSOFT FSE). pp.148-157.
Earthy. 1. (19971. "Usability ?v!uturity \!odel: Processes". IXLSED5.I . .f(p). EC /.YLSE (IE :COI6J.iinol de/iI'erabie
(l'ersion 0.]). London. Lloyd's Register.
Ebert. C. De?vlan. 1. y Schelenz. F. (2003) "e-R&D: Effectively \'!unaging and using R&D Knowledge". En
Managing Sojilmre Engineering KnOll'iegde. Aurum. A" JetTef)'. R" Wohlin. c.. Handzic. \1. (eds.) Berlin. Springer.
Elmasri R.y S. Navuthe. Dafabase Sysfellls. Second Ed .. Addison-Wesley. \!assachussets. 1997.
Emmerich. W" Kroha. P . y Schafer. W. (1993 I. "Object-Oriented Database Management Systems for Construction
of CASE Environments'. Proceedings offile Conference on Database and Expert Applications (DE.'tA '93).
Engels. G. Y Groenewegen. L (19941. "SOCCA: Specitlcations of coordinated and cooperative activities'. En
Sojilrare Process .I/ode//ing and Technology (pp. 71-102). Research Studies Press.
English. LP. (1999) flllpro\'ing Data Warehouse and Business Injimnation QualifY: Methodsfor reducing costs and
increasing Pr(jiits. Willey & Sons. 1999.
Eppler.?vl. 1. (2003) :llanaging b!fimnarion Qualizl'. Springer. Gennany. 2003.
Eppler. ?vI. 1. y Muezenmayer. P. (2002). "Measuring Infonnation Quality in the Web Context: A Survey of State-of-
the-Art Instruments and an Application \!ethodoloi,'Y". Proceedings of fhe Eigth fl1lernarionol C Ol!!i:rellce on In/orlllalion
QualifY (/CIQ :COO]). pp.l87-196.
Eppler, M. 1. y Wittig. D. (2000) "Conceptualizing Infommtion Quality: A review of Information Quality
Frameworks !Tom the last ten years." Proceedings orthe ]000 Conference on fn:jimllation Qllalil). Pp 83-96.
Eppler. M.1. (2001a). "Increasing Infommtion Quality through Knowledge Systems Services".
Proceedings of the ]001 fntemillional 5,\'InposiulII onl!!!ormotion 5,ntem and Engineering (/S'01) June 25-28. Las Vegas.
Ne\ada.
Eppler. M.1. (2001b). "The Concept ofinfonnation Quality: An Interdisciplinary haluation of recent Infonl1ation
Quality Frame\\Toks". Smdies in Communication Sciences I (]OOf). pp. 167-182.
Erickson. D. Y Steadman. A. (1995) "Metrics Tools: Effort and Schedule". CrossTalk: The Journal of'Defense
So/ilmre Engineering. \Iarch of 1995. Disponible en:
httD:' \\Ww.stsc.hill.a[mil crosstalk fmmes.aso'!uri= 1 995 03.\!etrics.aso (ultimo acceso en Agosto de 2006).
Estublier. 1.. Cunin. P.Y. y Be1khatir, N. (1998). "Architectures for Process Support System Interoperability".
Prooceedings (jf'the Filih fntemationol Conterence on the S()!ilmre Process. Lisle. IL June 1998.
Estublier. 1.. Villalobos. 1.. Tuyet LE. Sanlaville. S .. Vega. G. (2003 I. "An Approach and Framework for
Extensible Process Support System". 9th European Workshop on Sojilmre Process Technolog}' (EHSPT;. pp. 46-61.
hans ?vl.\\" .. Y ?vlarciniak, J.1. (1987) SojiH'are QualifY Assurance and Managemelll. Capitulo; 7 y 8. John Willey &
Sons. New York.
Fagan. M. (19761 Design and Code Inspections to Reduce Errors in program de\e!opment. IBM Systems Joumal
15.3. pp. 182-211.
Feigenbaum. A.V. (1961). Toral QualifY Control: Engineering and ,\lonagcmelll. McGraw-HilL Nueva York.
370 CAUDAD DE SISTEl'vV\S INFORJvLA..TICOS
RA.-MA
Feldt. P. (2000). Requiremel1ls merrics based 011 use cases. Master's thesis. Department of Communication Systems.
Lund Institute of Technology. Lund University. Box 118. S-221 00 Lund. Sweden.
Fenton N. (1994). "Software Measurement: A Necessary Scientific Basis". IEEE Trallsacriolls On Sofhmre
Engineering. 20(3). pp. 199-206.
Fenton N. y Neil. M. (2000). "Software Metrics: a Roadmap". Furure of Software Engineering". ed. Anthony
Finkelstein. ACM. pp.359-370.
Fenton N. y Pfleeger S. (1997). Sofl1mre !,.,ferrics: A Rigorous Approach. 2" edicion. Londres. Chapman & Hall.
Fenton. N. (200 I) "Viewpoint Article: Conducting and Presenting Empirical Software Engineering". Empirical
Sofhmre Engineering 6(3): pp. 195-200 (2001).
Fernstrom. c.. (1993) "ProcessWEA VER: Adding process support to UNL'C. in 2nd Inrematiollal Conference an
rhe SO/Mare Process. IEEE CS Press, Berlin. Gertnany, February 1993. pp. 12-26.
Finkelstein. A., Kramer. 1 y Nuseibeh, B. (1994). Sofhmre Process Modeling and Technology. Research Studies
Press.
Firth, c.. y Wang. R. (1993). "Closing the Data Quality Gap: Using ISO 9000 to study Data Quality". En
http:! web.miLedu
i
tdqmipapers93ipass I '93-03.html (Ultimo acceso en Agosto de 2006)
Florac. W. A. Y Carleton, A.D. (2002) "Using Statistical Process Control to Measure Software Process". In
Fundamel1lal Concepfsjor fhe SO/Mare QualifY Engineer. Taz Daughtrey Edi-tor. American Society for Quality. Pp.133-144.
2002.
Florae. W. (1992). Sojhmre Qualil}' Measuremel1l: A Fran/elrorkjor COllilling Problems alld Defecrs (CMUlSE!-
92-TR-22). Software Engineering Institute. Carnegie Mellon University. Pittsburgh. Pa .. September 1992.
Florae. W. A. Y Carleton. A. D. (1999). Measuring rhe Sojhmre Process. S{atisrical Process Comrolfor So/hmre
Process Impro\emel1l. Addison Wesley.
FOreS)1he G.B. Hedlund 1.. Snook S., Horvath lA . Williams W.M .. Bullis R.c.. Dennis M" y Sternberg R. (1998).
"Construct validation of tacit Knowledge for military Leadership". Anllllal JIeefing 0/ fhe American EdllCClrion Research
Associatioll. 1998.
Frailey. D. (1991) "Detlning a corporate-wide software process". Proceedings of the Firsr Imernational Con/i?J'ence
on the Sofl1mre Process. pp.113-12!.
Franch. X. Y Ribci. 1 M. (1999). "Using UML for Modelling the Static Part of a Software Process". Proceedings (jf
U.\fL '99. Forth Collins (USA). LNCS. \'01. 1713. Springer-Verlag.
Franch. X. Y Ribci. 1 M. (2003). "Promenade: Un Lenguaje para la Modelizacicin de Procesos Software". f7!J
JOl'l1adas de Ingenieria del S(jfl1mre y Bases de Datos (JISBD'03). Alicante (Espana). pp. 231-240.
Franch. X .. Y Canallo. J.P. (2003) "Using Quality Models in Software Package Selection". IEEE S(jfl1mre 20(1):
pp.34-4!.
Fuggeta. A. "Software Process: A roadmap". Thejiilure of'Sofhmre Engineering. ed. A. Finkelstein ACvL Press.
Pp.27-34.2000
Fuggetta. A .. Godart. C. y Jahnke. 1 (1999): "Architectural Views and Alternatives". En Sofhmre Process:
Principles. Methodology and Technology. LNCS 1500. Springer-Verlag. pp. 95-116.
~ R A M A BIBLIOGRAFLA. Y REFERENCIAS 371
Fuggetta. A .. Lavazza. L.. ?vlorasca. S .. Cinti. S .. Oldano. G. y Orazi. E. (1998). "Applying GQM in an Industrial
Software Factory". A CM TrclIlsactions on Softwore Engineering and Methodology. VoL 7. No.4. Octubre 1998. pp. 411-448.
Galin. D .. (2004) Sojilmre Quality Assurance: ./i"om theory to implementation. Pearson Addisson Wesley. Harlow
(UK).
Garcia. F. (2004) Flv/ESP: Marco de Trabajo lmegrado para el Modelado), la Medicion de los Procesos SofMare.
Tesis DoctoraL Universidad de Castilla-La Mancha.
Garcia. F .. Bertoa. tvl.. Calero. c.. Vallecillo. A .. Ruiz. F .. Piattini.lvl.. y Genero. M. (2005). "Towards a Consistent
Tern1inology for Software iVleasurement"'.lnformation and Sojilmre Tecllllolog).
Gardner. S.R. (1998). "Building the data warehouse". Communications of the Ael/. voL 41. N" 9. September. pp.
52-60.
Gartner (2002). Architeclllre Maturity Assesment Emluation. Gartner. Inc.
Ganin. D. (1984). Hhat is Qualit)':' Sloan Management Review. Otono.
Gendron. M. y DOnofrio. M.J. (2002). "Formulation of a Decision Support Model Using Quality Attributes".
Proceedings of the Set'emh Co/?terence on b!{ol1nation Quality ICIQ2003. pp. 305-316.
Genero M" Pianini M. y Calero M. (Eds.) (2004) .\/etrics/or Sojilrare Conceptual Models. Imperial College Press.
UK. 2004.
Gertz. M .. Tamer.:V1.. Saake. G .. y Sanler. K .. (2004) "Report on the Dagstuhl Seminar 'Data Quality on the web' ".
Proceedings o{SIGJIOD record. 1'01.33. .vo.I. March 2004.
Geno G. (2002). "Risk ivlanagement Supporting Quality ivlanagement of Software Acquisition Projects". En
Daughtrey. T. (Ed.) Fundamental Concepts/or the So/hmre Qualit)' Engineer. (Pp.25-38). Milwaukee. WI: American Society
for Quality.
Giannocaro. A .. Shanks. G. y Darke. P. (1999). "Stakeholder Perceptions of Data Quality in a Data Warehouse
Environment"'. Proceedings of the Telllh Australasian Conference on h?/ormatioll Systems .. Pp. 344-355.
Gilb. T. y Graham D. (1993). So/hrare Inspection. London: Addison-Wesley Longman.
Giles. A. Y Barney. D. (1995). "?-.letrics Tools: Software Cost Estimation". CrossTalk: The Journal o/Defense
SO{llrare Engineering. May 1995. httn:' www.stsc.hiILaf.mil crosstalk rrames.asn?uri=199505\letrics.aso (ultimo acceso en
Agosto de 2006).
Giles. A. Y Daich. G. (1995). "Metrics Tools'. Crosstalk. The Journal o{De{ense SofMare Engineering. Febrero.
Goethert. W. (1992). Sojhmre E.{!ort '\/easuremelll: A Framellwk/or Coullling Stat}: HOllrs (ClfU/SEJ-92-TR-2I I.
Software Engineering Institute. Carnegie ivlellon Uniyersity. Pittsburgh. Pa .. September 1992.
Goethert. \Y'. Y Siyiy.1. (2004). "Applications of the Indicador Template for Measurement and Analysis ". Technical
.\'ole CJfLiSEI-2004- T.\'-024. Software Engineering Institute. Septiembre 2004.
Goldenson. D .. Jarzombek. J. y Rout. T. (2003). "Measurement and Analysis in Capability Maturity Model
Integration Models and Software Process Impro\ement". CROSSTALK The Journal of Defense So/hrare Engineering
(Software Engineering Technology). pp. 20-24.
Grady. R.B .. Y CasswelL D.L. (1987) So./hmre .I/etries: Establishing a Company- Wide Program. Prentice Hall.
CALID.A.D DE SISTEMAS INFORMATICOS
Grembn. J. Y Myers. C. (1997). "The IDEAL Model: .-\ Practical Guide for Improvement". Bridge, Software
Engineering Institute (SE/) publicC/tion.issue three.
Grimmer. 1.J .. y Hinrichs. H. (2001 J. "'-\ methodological approach to data quality management supported by data
mining". Proceedings O/i/II! Sixfh International conterenc!.! on ili/ormatioll Quality. pp. 217-232.
Gnmdy.l y Hoskins. 1 (1998). "Serendipity: integrated environment support for process modelling. enactment and
work coordination". Autoll/ated Software Engillel'l'illg: An Imernational Journal: Special Issue 0/1 Pracess Technology. 5( I).
pp.27-60.
Halstead. 1'v!. H .. (1977) Elell/ellls orSojnmre Science. Else\'ier North Holland. The Netherlands.
Hare!. D. y Politi. 1vl. (1998). J/odel/ing Reactiw Systems ll'ith Statecharts. The Statemate approach. McGraw-HilI.
Hareton. L. y Terence. Y. (2001) ... .-\ Process Framework for Small Projects". Sojnmre Process Improl'elllelll alld
Practice 6. pp. 67-83.
Harrison R .. Counsell S. y. Nithi. R. (1999). "An Evaluation of the MOOD set of Object-Oriented Software
Metrics". IEEE TrallSactions on SOrMare Engineering. 24(6). pp. 491-496.
Heimbigner. D .. Sunon. S. y Osterweil. L. (1990). "Managing Change in Process-Centered Emironments".
Proceedings ';th ACMSIGSOFT SymposiulII Sojnrare Dewlopmelll EI1\irol1l11eIll5. ACM Software Engineering Notes. vol.
J 5. December 1990.
Helfert. "I.. y von yIaur. E. (2002) ".-\ Strategy for Ylanaging Data Quality in data WarehoLlse Systems".
Proceedings o(the Sixth IlIIemational COI!(erence on In/orlllation Quality. pp. 62-76.
Henderson-Sellers B. (1996). Object-oriellled ,I/etrics-.I/easures o(complexity_ Prentice-Hall. Upper Saddle River.
Nueva Jersey.
Henderson-Sellers B .. Zowghi D .. Klemola T. y Parasuram S. (2002). "Sizing use cases: How to create a standard
metrical approach". 8th lnjormarion Systems 2002. Lecture Notes in Computer Science. 2425. Springer-
Verlag. pp. 409--421.
Henderson-Sellers. B. y Gonzalez-Perez. C. (2004) ... .-\ Comparison of four process metamodels and the creation of
a new generic standard". In/ormatioll and Sojilmre Teclmolog). 47 (2005). pp. 49-65.
Henry. S. y Kafura. S. (J 981). "Software Structure "jetrics Based on Infom1ation Flow". IEEE TramCictions on
So/ill'ore Engineering. 7(5). pp. 510-518.
Hinrichs. H. (2000) "CLIQ- Inteligent Data Quality Management". Proceedillgs q(thejourtiI IEEE illlernational
Baltic Workshop on darabases and b?/ormation System. 2000
Hinrichs. H. yAden. T. (200 J ) ".-\n ISO 900 J :2000 compliant quality management System for Data Integration in
Data Warehouse System". Proceedings ql'the International Workshop 011 Design and .I/anogemelll o( Data Warehouse
(D.lfDJI"2001) Interlaken. Switzerland. June 4. 200J.
Host. "I.. Regnel!. B. y \\llOlin. C. (2000). "Using Sllldents as Subjects - A comparative Sllldy of Sllldents &
Professionals in Lead-Time Impact Assessment". Proceedings of the ';th Conference on Empirical Assessment & Emluation
ill So/nl'are Engilleering (LISE!. Keele University. UK. pp. 20 J -214.
Hoxmaier. lA. (200 J) Dimensions of Database Quality. In Dl!l'eloping Qualit)' Complex Database Sy,tems:
Practices. Techniques. and Technologies. Editor Shirley Becker. Idea Group Publishing. 200 I.
Hoyer. R.W. y Hoyer. B.B.Y. (2001). H7wt is QualifY. Quality Progress. Julio.
BIBLIOGRAFiA Y REFERENCIAS 373
Huang. K. T.. Lee. Y .. y Wang. R. (19991. Qualil)' In/ormation and KnO\r/edge. Prentice Hall. Upper Saddle RiYer.
Hutf. K. (19961. "Software process modelling". En Sofllmre Process. John Wiley & Sons.
Humphrey. W. (1989) Managing the so/im".e process. Addison \Yes!cy. Reading ylass. 1989.
Humphrey. W. (1997)./mroductionto Personal Sojhrare Process. Addison Wesley.
Humphrey. W. (2000a). Introduction to Team Sofm'are Process. Addison Wesley.
Humphrey. W. (2000b). The Team Sojhmre Process (TSP). TECHYICIL REPORT CllUiSEJ-1000-TR-023 ESC-
TR-1000-013. Software Engineering Institute. Noyember 2000.
Humprhey. W. (2002) "The Software Standard Profile". In Fundamental Concepts for the Sqlhmre Quality
Engineer. Taz Daughtrey Editor. American Society for Quality. Pp. 3-16. 2002.
Hunter. R.B. Y TIJayer. R.H. (200 I) (eds.). Sqlhmre Process ImprolWlent. IEEE Computer Society.
Hyde. A. (1992). 'The Proyerbs of Total Quality Management: Recharting the Path to Quality Improyement in the
Public Sector". Public Productil"ity and J!cmagement Redell'. 16(1). pp. 25-37.
Ibbs. CW. y Kwak. Y.H. (2000). "Assessing Project Management e.1aturity. ProieCl Jfanagement Journal 31.
pp.32-43.
IEEE (19861 IEEE STD 1011-1986 IEEE Standardjor Sqlhmre I'ailication (Ind I'alidation Plans.
IEEE (1987) IEEE STD 1058.1-1987 IEEE Siandardjor Sofllmre ProjeCl .\fanagement Plal15.
IEEE (1988) IEEE-982.1-1988. Standard Dictionary qfMeasures to Proc/uce Reliable Sqlhmre.
IEEE (1992) IEEE STD 1061-1992. IEEE Swndard jar a Sqlhmre Qualil)' Metrics Methodology.
IEEE (1995). IEEE Standardfor Del'eloping Sofilrare Life Cycle Processes. IEEE Sid 1074-1995. Institute of
Electrical and Electronics Engineers. EEUU.
IEEE (19971 IEEE ELi 11107.1-1997. !I/duslly Implementation ollSO/IEC 11107:1995 - Standardjor b!/ormation
Teeill/olog;' - Sojilmre Life Cycle Processes - Life Cycle Data Institute of Electrical and Electronics EngineersiElectronic
Industries Alliance. 0 I -!vlay- I 997.
IEEE (1998a) IEEE STD 830-1998. IEEE Siandard guide 10 So/hmre Requirelllellls Specification. IEEE ,Vel\" l"ork
(LSi) IEEE Complller Sociel).
IEEE (I 998b I. IEEE Std 1061- I 998 IEEE Siandarel/or a Sofhmre Qllality Metric, Methodolog;.
IEEE (1998cl. InduSII)' Implemelllotion of IlIIernational Standard ISO/IEC 12107: 1995 (ISO;fEC 11107)
Standard/or In/orlllation Technology-Software life cycle processes. IEEEiEIA 12207.0-1996. Institute of Electrical
and Electronics Engineers. EEUU.
IEEE (l998d). IlIdllsll)' IlIIplemelllalion qlllllernational Standard ISO/IEC 11107: 1995 (!SO;lEC 11107)
Standard for li!/imnation Technology-Software life cycle processes. Life cycle data. IEEE"EIA 12207.1-1997.
Institute of Electrical and Electronics Engineers. EEUC.
374 CAUDAD DE SISTENlAS Il'lFOIUvlA. TICOS
RA-NlA
IEEE (l998e). Indllstry Implemel1lation of International Standard ISO/IEC 12207: 1995 (lSO/IEC 12]07;
Standard for In[ormation We cycle processes. Implementation considerations. IEEEfEIA
12207.2-1997. Institute of Electrical and Electronics Engineers. EEUU.
IEEE (2004). Gliide to the Sojilrare Engineering Body of Knowledge. IEEE Computer Society.
Ishikawa, K. (1985). H71C1t is Total QlIality COlllrol?: The Japanese \l'(e\". Prentice-Hall, Englewood Cliffs, Londres.
ISO (1993). ISO/IEC International Standard ISO 17M. International VocablllCll)' of Basic and General Terms in
Metrolog;. International Organization for Standarization. Ginebra, Suiza.
ISO (1995a). ISO/IEC 12]07. Intemational Standard In[ol7nation technolog;' - Sofnrare life-cycle processes.
International Organization for Standarization. Ginebra, Suiza.
ISO (1995b). ISO/lEe. Guideline for eraillation and selection of CASE tools. International Standard ISO/lEC IS
14102, International Organization for Standarization. Ginebra, Suiza.
ISO (1998). ISO IEC 15504 TR2: 1998. part 2: A reference model jar processes and process capability.
International Organization for Standarization. Ginebra. Suiza.
ISO (1999). ISO ]./598: /999-2001. 1n[017l1C1tion Tecllllolog;' - Sofnrare Prodllct Em/llation - Parts 1-6.
ISO (2000a). lINe-EN ISO 9000:2000 Sistemas de gestion de la calidad Flindamelllos y vocablilario. AENOR.
Madrid.
ISO (2000b). LiNE-EN ISO 900 I :2000 Sistemas de gestion de 10 calidad ReqllisilOs. A..ENOR. Madrid.
ISO (2000c). LiNE-EN ISO 9004:2000 Sistemas de gestion de la calidad. Directrices para la lI1ejora del
desempeJio. AENOR. Madrid
ISO (2001) Sofnrare Prodllct Em/liation-QlIality Characteristics and Gliidelinesjar their Use. ISO/lEC Standard
9126. International Organization for Standarization. Ginebra. Suiza.
ISO (2002a). 1S0/IEC 12]07. International Standard lnjarmation technolog;' - Sofia'are life-cycle processes.
Amendment 1. International Organization for Standarization. Ginebra, Suiza.
ISO (2002b).IS0/IEC 15939: Sofnrare Engineering - Sofnrare Measllremelll Process. International Organization
for Standarization. Ginebra, Suiza.
ISO (2003). ISO/IEC 15288: b?formation Technolog;' - L!re Cycle Management -System L!fe Cycle Processes.
ISO (2004a). ISO/IEC 1550-1-1:2003. h?/armation tecllllolog;' - Process assessmelll - Part 1: Concepts and
vocablila/). International Standards Organization. Ginebra. Suiza.
ISO (2004b). ISO/IEC 1550-1-2:2003. h!formation Process assessmelll
assessmelll. International Standards Organization. Ginebra. Suiza.
Part 2: Pe/fonning an
ISO (2004c). ISO/IEC 1550-1-3:2003. b!/al7l1C1tion teclmolog;' - Process assessment - Part 3: Gliidance on
pe/fo17ning an assessment. International Standards Organization. Ginebra, Suiza.
ISO (2004d). ISO/fEC 15504-4:2003. Information technolog;' - Process assessmelll- Part 4: Guidance on use for
process impro\'ement and process capability detenninalioll. International Standards Organization, Ginebra, Suiza.
~ RA,-ivLA BlBLIOGRMiA Y REFERENCIAS 375
ISO (200-le), b?/Cmnatian Tecilllologt, - Sofnrare Life Cycle Processes, AlIImendmelll 2, International Organization
for Standarization, Ginebra. Suiza,
ISO (200-lf), ISO/IEC 90003:2004, SofMare engineering-Guidelines for the application of ISO 9001:2000 to
computer software, International Organization for Standarization, Ginebra. Suiza,
ISO (2005a). lS0/lEC 25000 Sofnrare and system engineering Sofnrare product Quality Requiremellls and
El'aluation (SQuaRE) -Guide to SQuaRE. International Organization for Standarization. Ginebra. Suiza.
ISO (2005b). lS0/lEC 25001 Sofnrare and system engineering - Sofnrare product Quality Requirements and
Emluation (SQuaRE)-Emluatioll planning and managemelll. International Organization for Standarization. Ginebra. Suiza.
ISO (2005e). lS0/lEC 25010 Sojhrare and system engineering - SofMare product Quality Requiremellls and
Emluation (SQuaRE) Quali(l' model and guide. International Organization for Standarization. Ginebra. Suiza.
ISO (2005d). lS0/lEC 25020 S(jfnrare and system engineering - S(jfhmre product Quality Requirements and
Emlua/ion (SQuaRE) - Measurement re.terence model and guide, International Organization for Standarization. Ginebra.
Suiza.
ISO (2005e). ISO/IEC 25021 S(jlhrare and system engineering Sofnrare product Quality Requiremellls and
Emluation (SQuaRE) - Measurement primitil'es. International Organization for Standarization, Ginebra. Suiza.
ISO (2005f), ISO/IEC 25022 S(jfnmre engineering - Sofnrare product Quali(l' Requirements and Emluation
(SQuaRE) Measurement of internal quality. International Organization for Standarization. Ginebra. Suiza,
ISO (2005g). ISOlfEC 25023 S(jfnrare and system engineering - Sofnrare product Quality RequiremellIs and
Emlua/ion (SQuaRE) -Measuremelll ofextemal quality, International Organization for Standarization, Ginebra. Suiza.
ISO (2005h), ISO/IEC 2502-1 S(jfnmre and system engineering S(jfnmre product Quality Requirements and
Emluation (SQuaRE)-MeasuremellI (jf quality in use. International Organization for Standarization, Ginebra. Suiza,
ISO (2005i), ISO/IE C 25030 S(jfhrare and system engineering - S(j(i\\'are product Quality Requirements and
Emluation (SQuaRE)-Qualit)' requirements. International Organization for Standarization. Ginebra. Suiza.
ISO (2005j), ISO/IEC 25040 Software and system engineering Sofnrare product Quality Requiremellls and
Emluation (SQuaRE) -Quality emluation Ol'eITieH' and guide, International Organization for Standarization. Ginebra. Suiza,
ISO (2005k), ISO/IEC 25041 S(jfnmre and system engineering - Sofnrare product QualiZl' Requirements and
Emluation (SQuaRE)-Emluationmodules. International Organization for Standarization. Ginebra, Suiza.
ISO (20051). ISO/IEC 25042 Sojhmre and system n g i n r i n g ~ S(j(ilmre product Quality Requirements and
Emluation (SQuaRE)-Processfor del'elopers, International Organization for Standarization, Ginebra. Suiza,
ISO (2005rn). ISO/IEC 250-13 S(jfnrare and system engineering Sojhrare product Quality Requirements and
Emlua/ion (SQuaRE) -Process for acquirers. International Organization for Standarization. Ginebra. Suiza,
ISO (2005n), ISO/IEC 250-1-1 Sofnmre and system engineering - Sofnrare product Quality Requirements and
Emluation (SQuaRE)-Processjor emluators. International Organization for Standarization. Ginebra, Suiza.
ISO (2006). ISO/IEC J 5504-5:2003. lnformationtecilllologt, - Process assessment- Part 5: An exemplar Process
Assessmelll Model. International Standards Organization. Ginebra, Suiza,
Jacobson. I.. Booeh. G. y Rurnbaugh.l (1999), EI Proceso Unificado de Desarrollo de S(jfhrare. Addison Wesley.
376 CAUDAD DE TICOS
Jarke. M" Y Vassiliou. Y. (1997). "Data Warehouse Quality: A rcview ofthc DWQ Project". Proceedings o/Second
Con(erence on In/iJl7nation Quality. :Vlassachusetls Institute of Technology. Cambridge.
Jarke. M" Lenzerini. M" Yassiliou. Y. y Vassiliadis. P. (2000). Fundamel1lals o.(Data Warehollses. Ed. Springer.
Jin y Embury (2001). "Non-Intrusive Assessment of Organizational Data Quality". Proceedings of the Sixth
Il1Iernational Con(erence on In/ormation Quality. pp. 398-411.
Jones. C. (2003). "Making Measurement Work". Crosstalk The Journal 0.( Defense Sojhmre Engineering. pp. 15-
19.
Jorgensen. M. y Ylolokken-Ostvold. K. (2006). "How large are software costs overruns" A review of the 1994
CHAOS report". 14017nation and So.fhmre Technology 48. pp. 297-301.
Junkermann. G" Peuschel. B" Schafer. W. y Walt: S. (1994). "MERLIN: Supporting Cooperation in Software
Development Through a Knowledge-Based Environment". En A. finkelstein. 1. Kramer. and B. Nuseibeh. editors. Sofllmre
Process Modelling and Technology. Research Studies Press Limited (1. Wiley).
Juran. J.M. (ed.) (1988).Jurans Quality Control Handbook. 4" ed. Nueva York. McGraw-Hill.
Juran. J.!\1. (ed.) (1995). A History o.OIanagingfor Quality. ASQC Quality Press. Milwaukee.
Juristo. N. y A. CWO I ). Basics o/So.jhmre Engineering Erperimel1lation. Kluwer Academic Publishers.
Kahn. B .. Strong. D .. y \Vang. R. (2002) "Information Quality Benchmarks: Product and Sen'ice Perfonnance".
Communications of the AC\fApril 200:Ylol, -15, .vo. -I.
Kaiser. G" Barghouti. N. y Sokols!"y. M. (I (90). "Preliminary Experience with Process Modeling in the Man'e!
Software Development Kernel". Proceeding o.(the 23
d
Il1Iemational Con(erence on System Sciences.
Kan. S.H. (2003). Metrics and Models in Sojhmre Quality Engineering. 2" ed. Boston. Addison-Wesley.
Katayama. T. (1989) "A Hierarchical and functional Software Process Description and its Enaction". Proceedings o(
the 11th II1Iel71ationai COI!ference 0/1 Sojhmre Engineering.
Kellner. M. (19911. "Software process modelling support for management planning and control". Proceedings o.f'the
First International Conjerence on Sojr.mre Process. pp. 8-28.
Kellner. y Hansen. G. (1989). "Software process modelling .. -'\ case study". Proceedings of'the 22nd .inHal
Hcnmi lmemational COI!terence on System Sciences. Hawai. pp. 175-.1 88.
Kesh. S .. (1995). "Evaluating the Quality of Entity Relationship Models". lnjiJl7nation and SO(lH'are Technology.
Vol. 37. No.12. Pp. 681-689.
Kim. Woo y Choi. B" (2003) "Towards Quantitying Data Quality Costs". Journal of Object Technology. Vol. 2.
noA" Pp. 69-76.July-August 2003.
Kingsbury. 1. y Dawood. :V1. (1995) "Metrics Tools: Quality - Defect Tracking". CrossTalk: The Journal o.fDefense
Sofllrare Engineering. Nlay 1995. http: \\Ww.stsc.hill.afmikrosstalki frames,asp'?uri= I 995:05,;\ktrics.as 0 (ultimo acceso en
Agosto de 2006).
Kiszkumo. E.. y Yankclcyich. D . (2001) "Data Testing". ASSE 200 I Proceedings of'SADJO. pp. 125-134.
RA-MA BIBLIOGRAFiA Y REFERENCIAS 377
Kitchenham B. y Linkman, SJ. (1990), "Design Metrics in Practice", Inf Soft. Technology, Vol. 32, No.4, pp.304-
310,1990.
Kitchenham B., Pflegger S. y Fenton N. (1995). "Towards a Framework for Software Measurement Validation".
IEEE Transactions o/So/tware Engineering, 21(12), pp. 929-943.
Kitchenham B., Y Linkman, SJ. (1990), "Design Metrics in Practice", Inf Soft. Technology, Vol. 32, No.4, pp.304-
310,1990.
Kitchenham, B. y Pfleeger, S.L. (1996). "Software Quality: The Elusive Target". IEEE Software 20(1),
enero/febrero,12-21.
Kitchenham, B., (2004) Procedures for Peifonning Systematic Revie .... s. Keele University, Technical Report
TRlSE0401.
Kitchenham, B., Pfleeger, S., Pickard, L., Jones, P., Hoaglin, D., EI Emam, K. y Rosenberg, J. (2002). "Preliminary
Guidelines for Empirical Research in Software Engineering". IEEE Transactions 011 Software Engineering, Vol. 28 N8, pp.
721-734.
Kitchenham, B., y Pfleeger, S. (2002) "Principles of Survey Research. Part 5: PopUlations and Samples". ACM
SIGSOFT. Software Engineering Notes, vol. 27, n. 5, pp. 17-20,2002.
Kitchenham, B., y Pfleeger, S. (2002a) "Principles of Survey Research. Part 3: Constructing a Survey Instrument".
ACM SIGSOFT. Software Engineering Notes, vol. 27, n. 2, pp. 20-24, 2002.
Kitchenham, B., y Pfleeger, S. (2002b) "PrinCIples of Survey Research. Part 2: Designing a Survey". AC\1
SIGSOFT. So/tlmre Engineering Notes, vol. 27, n. I, pp. 18-20,2002.
Kitchenham, B., y Pfleeger, S. (2002c) "Principles of Survey Research. Part 4: Questionnaire Evaluation". AC\I
SIGSOFT. Soft .... are Engineering Notes, vol. 27, n. 3, pp. 20-23, 2002.
Kitchenham, B., y Pfleeger, S. (2003) "Principles of Survey Research. Part 6: Data Analysis". ACM SIGSOFT.
So/tlmre Engineering Notes, vol. 28, n. 2, pp. 24-27,2003.
Kosar, D. (1999). "Developing a Framework to Manage Data Quality in Healthcare". Proceedings o/the Fourth
Conference on In/onnation Quality ICIQ' 1999, pp. 58-76.
Krause, M. (1994). "Software: A maturity model for automated software testing". Afedical Devices and Diagnostic
Indusfl), Maga::ine, 16(12), pp. 103-108.
Kreutzberg, 1. (2000). "Has quality management any effect on qrtality?-Analysis of quality management by a non-
linear model". Proceedings o/the 2000 Conference on In/onnation Quality, pp. 242-259.
Krogstie, 1., Lindland, O. y Sindre, G. (1995). "Towards a Deeper Understanding of Quality in Requirements
Engineering". CAiSE 1995, Jyvash:yla, Finland, pp. 82-95.
Kruchten, P. (1999) The Rational Unified Process. An Infloduction. Addison-Wesley, 2nd edition.
Kuvaja, P., Simila, 1., Kizanik, L., Bicego, A., Koch, G. y Saukkonen, S. (1994). So/tlmre Process Assessment and
Improvement: The BOOTSTRAP Approach, Blacbvell Business Publishers, Oxford, UK.
Lavazza, L., (2000) "Providing Automated Support for the GQM Measurement Process". IEEE SO/Mare 17(3).
Lawton, G. (2001) "Knowledge Management: Ready for Prime Time?". IEEE Computer 34. FebnlalJ' (2001), pp.
12-14.
378 CAUDAD DE SISTEMAS INFOR.!'v!ATICOS RA-MA
Lee. J . Grunninger. M . Jin. Y . Malone. T . Tate. A. y Yost. G. (1998). "The PIF Process Interchange Format and
Framework Version LT. The Knowledge Engineering Review. 13(1). pp. 91-120.
Lee. Y.W . Strong. 0 .. Kahn. 8.. Y Wang. R. (2002) "AIMQ: A methodology for Information Quality Assessment".
Infol7nation & Management . 40. 2 (2002). pp. 133-146.
Leonowich-Graharn. P. Y Willshire, MJ. (2003). "A data quality framework for small business". Proceedings of the
Eigth International COf!ference onI'?fol7nation Quality (ICIQ-03), pp. 239-244.
Ley Organica 151l999. Ley Orgclllica de Proteccion de Datos Personales. BOE num. 298, December 14.1999.
Li, W. Y Henry S.(1993). "Object-Oriented metrics that predict maintainability". Jou17lal of Systems and Software".
vol. 23 n 2, pp. 111-122.
Li, H. F. y Cheng, W. K. (1987) "An Empirical Study of Software Metrics", IEEE Trans. on Software Engineering,
Vol. 13, No.6, pp. 679-708,1987.
Lindland 0., Sindre G., y Solvberg A. (1994). "Understanding Quality in Conceptual Modelling". IEEE Software,
vol. II. n 2. pp. 42-49.
Lindstrom. B. (2004). A Sofl1mre JHeasurement Case Study Using GQJI;f. Master's Thesis. Department of
Communication Systems. Lund University. LUTEDX(TETS-5522)/I-72/(2004) & local 27.
Lind\all. M .. Y Rus, I. (2003) "Lessons Learned from Building Experience Factories for Software Organizations".
Wissensmanagemelll 2003: pp. 59-63.
Liu. L. y Chi. L N. (2002) "Evolutional Data Quality: a theory-specific \iew". Proceedings of the Seventh
IllIernarionai COI!terence on b!formation Qualit) (ICIQ-02), pp. 292-304.
Lorenz M. y Kidd J. (1994). Object-Oriented Sofl1mre Metrics: A Practical Guide. Prentice Hall, Englewood Cliffs,
Nueva Jersey.
Losavio. F.. Chirinos, L. Le\y, N. y Ramdane-Cherif. A. (2003). "Quality Characteristics for Software
Architecture". in Joul71al of Object Technology, vol. 2. no. 2. March-April 2003. pp. 133-150.
http://www.jOLfi11iisslles/issue 2003 03/article" (ultimo acceso en Agosto de 2006).
Loshin 0 .. (200]) EllIe/prises Knowledge Managemelll: The Data Qualit) Approach. Morgan Kauffman, San
Francisco (California).
Lon. C. y Rombach. H. (1996). "Repeatable Software Engineering Experiments for Comparing Defect-Detection
techniques". Jou/7/al o.fEmpirical So.thmre Engineering. 1(3). pp. 244-277.
Luftman. J.N. (2000) "Assessing Business-IT Alignment Maturity". Communication o.fAIS 4 (14).
M&G (2004). "Mayer & Bunge Informatica LTDA". Panorama de la Industria del So.thmre en Larinoallllirica.
BrasiL 2004.
1v!acDonelL S.G. MJ. Shepperd y PJ. Sallis. "Metrics for Database Systems: All Empirical Study", Proc. Fourth
International Sofilmre Marics Symposium- Metrics '97, Albuquerque, IEEE Computer Society, pp. 99-107, 1997.
Madnick. S .. Wang, R .. Xian. X. (2004). "The design and Implementation of a Corporate Householding
Knowledgement Processor to Improve Data Quality". JOllmal o.fJfanagemelll Infol7lJation Systems. 20(3), pp. 41-69.
BffiLIOGRAFiA Y REFERENCLA,.S 379
Maier R. (200 I). "Organizational concepts and measures for the evaluation of data modelling". Chapter I. in
Developing quality camplex databases systems: practices. techniques and technologies. Ed. Becker S.. Idea Group
Publishing. Pp. 1-27.
;VLA..? (2003). CAF - El Marco Comlln de Emluacioll. Ministerio de Administraciones PlIblicas. Direccion General
de Inspeccion. Simplificacion y Calidad de los Servicios. Madrid. 2003.
Marchesi. M. (1998). "OOA Metrics for the Unified Modeling Language". 2nd Euromicro COI?ference on SojMare
Mailllenallce alld Reengineering. 1998. pp. 67-73.
Martin. L. (1993). "Total Quality Management in the Public Sector". National Producth'ity Rel'ieH'. 10. 195-213.
McAndrews. D. (2001). The Team Sojnmre Process (TSPS): An Oven'iew and Preliminary Results oj Using
Disciplined Practices. Technical Report CMUiSEI-2000-TR-015 ESC-TR-2000-015. Software Engineering Institute.
McBride. T . Henderson-Sellers. B. y Zowghi. D. (2004). "Project Management Capability Levels: An Empirical
Study'. Proc. Ojthe 11th Asia-Pacific SojMare Engineering Coi?ference (APSEC04), IEEE Computer Society.
McCabe. 1. (1976). "A Sofuvare Complexity Measure". IEEE Transactions on Sojnmre Engineering. 2. pp. 308-
320.
McCall. 1. A.. Richards. P.K. y Walters GF (1977) FactO/'S ill sojnmre quality. Vols I. II, III: US Rome Air
Development Center Reports NTIS ADiA-049 014.015. 055.
:VlcDermid.1. (1991). Sojnmre Engineering Reference Book. Butterworth Heinemann.
McFeeley. B .. (1996) IDEAL: A User's Guidejor Sojnmre Process Improl'elnelll. tech. report CMU/SEI-96-HB-
001. Sofuvare Eng. Inst.. 1996.
McGarry. L Card. D . Jones. C. Layman. B.. Clark. E.. Dean. 1. y Hall. F. (2002). Practical Sojtware AJeasuremelll.
Objecth'e b?formationjor Decision Makers. Addison-Wesley.
McGowan. C y Bohner. S. (1993). "Model based process assessments". Proceedings ojthe 15th JllIemational
Conference on Sojt.mre Engineering. pp. 202-211.
McLeod. R. (1990). Managemelll InjomlCltion Systems. New Yark, j\,'Y: McMillan Publishing.
Mecella M .. Scannapieco, M .. Virgilito, A.. Baldoni. R .. Catarci, T.. Batini. C (2002). "Managing Data Quality in
Cooperative Information Systems". En Meersman, R. y Tari, Z. (Eds) CooPIIDOAIODBASE 2002. LYCS 2519. pp 486-502.
ivlekelburg, D. (2005). "Sustaining Best Practices: How Rt!al-World Software Organizations Improve Quality
Processes". Sojnmre Quality Projessional7 (3), pp. 4-13.
Meredith. D.C (2002). "Managing with Metrics: Theory into Practice". In Fundamental Conceptsjor the Sofnmre
Quality Engineer. Taz Daughtrey Editor. American Society for Quality. 2002. pp. 145-154.
Miranda D .. Genero M. y Piattini ;VI. (2003). "Empirical validation of metrics for UlvIL statechart diagrams". 5th
International Coi?ference on Ellie/prise Information Systems !lCEIS 03), 1. 2003. pp. 87-95.
P. Y Batini. C (2002). DLl.A: Descriptioll a/the Gelleral Rejerellce Scellariojor All b?/imllatioll
Management Frallll?\\'orkjor Cooperath'e IlljomlCltion Systems. AIetodologie e Stl1lmenti per la Qualita dei Dati in Sistemi
Cooperathi. Programma di Ricerca Cofinanziato dal MIUR. http://www.dis.uniromal.it!-dg. (Ultimo acceso
Agosto de 2006).
380 CAUDAD DE SISTEMAS INFORl'v!A.TICOS RA-MA
Montangero, C. Y Ambriola, V. (1994). "Oikos: Consuucting process-centered" SDEs. En A. Finkelstein, 1. Kramer,
and B. Nuseibeh, editors. Software Process Modelling and Technology. Research Studies Press Limited (1. Wiley).
Moody D. (1998). "Metrics For Evaluating the Quality of Entity Relationship Models". Proceedings of the
Seventeenth Intel7lational COl!ference on ConceplZlal Modelling (ER '98), Singapore, noviembre 16-19, pp. 213-225.
Moody D. Y Shanks G. (1994) "What Makes A Good Data Model? EValuating The Quality of Entity Relationships
Models". Proceedings of the 13th IllIemational COliference on Canceplllal Modelling (ER '94), Manchester, Inglaterra,
December 14-17, 1994, pp. 94-111.
Moody D., Shanks G., y Darke P. (1998). "Improving the Quality of Entity Relationship Models-Experience in
Research and Practice". Proceedings of the Seventeenth Intel7lational COliference 011 Conceptual Modelling (ER '98),
Singapore, pp. 255-276.
Moraga, M.A.., Calero, c., Paz, 1., Diaz, O. y Piattini, M. (2005). "A Reusability model for Portlets". En Workshop
on Web biformation Systems Quality. Web biformation Systems Engineering - WISE 2005 Workshops, pp. 21-32, ISBN: 3-
540-30018-X, LCNS 3807. New York (USA) 20-22 November 2005.
Morasca, S. (2001). "Software Measurement". En Handbook ofSoftl\'Ore Engineering and Knowledge Engineering.
Vol. 1: Fundamentals, pp. 239-276.
Motha, W. M. y Viktor H.L. (2000). "Expanding Organizational Excellence: The Interplay between Data Quality
and Organizational Performance". Intemational COliference on Systems, (vbel71etics and !lifonnatics (SCI'2001), Orlando:
USA, July 22-25, Volume XI, pp. 60-65.
Mouradian, G., (2002) The quality Remlution A History of the Quality movement. University Press of America.
Boston.
Mullins, C. (2002). "The capability maturity model from a data perspective". The Data Administration Newsletter.
Robert Seiner: Pittsburgh PA, 2002; 3. Disponible en: http://www.tdan.comli003fe04.htm(ultimoaccesoAgostode2006).
NASCIO (2003). "National Association of State Chief Financial Officers". Enterprise Architecture Maturity Model,
Version 1.3. National Association of State Chief Financial Officers: LeXington KY; 16. Dispouible en:
https:!!www.nascio.orllinotlssues/EAlEA.MM.pdf(ultimo acceso en Agosto de 2006).
Niessink, F. (2002). "Sofrware Requirements: Functional & Non-functional Software Requirements". Disponible en:
http://\Vww.cs.uu.nl!wiki/SwaiWebHome (Ultimo acceso Agosto de 2006).
Niessink. F., Clerc, V., van Vliet, H. (2002). The IT Service Capability Maturity lvfodel. Release L2+ 3-0.3 Draft.
Software Engineering Research Centre: Utrecht. The Netherlands. Disponible en http://www.itservicecmm.onvdoc!itscmm-
123-0.3.pdf(ultimo acceso en Agosto de 2006).
N1ST (2002). Planning Report 02-3.The Economic Impacts of Inadequate In/rastl1lcture for SofMare Testing.
National Institute of Standards & Technology. Program Office Strategic Planning and Economic Analysis Group.
Okes, D. (2002) "Organize your quality tool belt". Quality Progress. Vol. 35, No.7, July 2002, pp. 25-29.
Oktaba, H. e Ibargtiengoitia, G. (2002). "Calidad en Procesos de Software: Ejemplo de TSP'. En Calidad en el
desan'ollo y mantenimiento del sofMare, Piattini, M .. Garcia, F. (eds), pp. 251-271.
Ok1aba, H .. Esquivel, c., Su Ramos. A .. Martinez, A., Quintanilla, G., Ruvalcaba, M., Lopez, F., Rivera. M .. Orozco,
M., Fermlndez, Y., Flores, M. (2003). "Modelo de Procesos para la Industria de Software MoProSoft, Version l.l Mayo
2003". Dispouible en: http://www.lania.m'(}biblioteca/manualesimoprosofiiV%201.!%20 DocumentoBase .pdf (Ultimo
acceso en Agosto de 2006).
RA-MA BIBLIOGRAFiA Y REFERENCIAS 381
Oliver, G" D'Ambra, 1., y Van Toonn, C (2003), "Evaluating an Approach to Sharing Software Engineering
Knowledge to Facilitate Learning", En Jl,fanaging Software Engineering Knowlegde, Aurum, A" Jeffery, K, Wohlin, C,
Handzic, M. (eds.) Berlin, Springer.
Olsen. K. y Staal, P. (1998). ''Testing Maturity Model". EPIC meeting on Software Improvement and Quality
Testing.
Olson, 1. E. (2003). Data Quality: the accuracy dimension. San Francisco, CA: Morgan Kaufmann Publishers.
OMS (2004). OMB Entelprise Architecture Assessment I' 1.0. TIle Office of Management and Budget, The
Executive Office of the President.
OMG. (2001). OAIG Unified .Modeling Language Specification; \'ersion 1.4. Object Management Group.
OMG. (2002). Software Process Engineering Metamodel Specification; adopted specification. Object Management
Group.
Onnan, L, Storey. V .. y Wang. R. (1994) "Systems Approaches to Improving Data Quality". Agosto 1994.
http://web.mit.eduitdgm\vww!papers/94/94-05.htrnl (lJltimo acceso en Agosto de 2006)
Orr. K. (1998) "Data Quality and System Theory". Communication of the ACM, 41 (2). pp. 66-71.
Osterweil, L (1987). "Software Processes Are Software Too". Proceedings of the 9th Il1Iel71ational Conference on
Software Engineering. pp. 2-13. Monterey, CA. March 1987. IEEE Computer Press.
ParasuranJan, A., Zeitharnl. VA. y Berry, LL (1988): "SERVQUAL: A Multiple-item Scale for Measuring
Consumers Perceptions of Service Quality". Joul7lal of Retailing, mi. 64. (Spring), pp. 12-40.
Park. R. (1992). Sojhmre Si::e Measurement: A Framework for Counting Source Statemel1ls (CMU/SEI-92-TR-20).
Software Engineering Institute, Carnegie Mellon University. Pittsburgh. Pa., September 1992.
Park, R., Goethert. W .. Florac, W. (1996). Goal-Drh'ell Software lvfeasuremel1l - A Guidebook. Handbook
CMU/SEI-96-HB-002. Software Engineering Institute. Agosto 1996.
Paton, M. y Diaz. O. (1999) "Active Database Management Systems". ACM Computing SUlTeys. Vol. 31, No.1.
pp. 63-103, 1999.
Paulk- M .. C Weber, B. Curtis. y Chrissis. M. The Capabili(\' Maturity Model Guidelinejor Improt'ing the sojilmre
Process. Addison-Wesley. Reading. Mass. 1995
Pease. A (1998). Core Plan Representation. version 4.
Penedo. M. H. y Shu. C (1991). "Acquiring experiences with the modelling and implementation of the project life-
cycle process: the PMDB work". So/hmre Engineering Joumal. 6(5), pp. 259-274.
Perry, D .. Porte. A. y Votta. L (2000). Empirical Studies ofSofnmre Engineering: A Roadmap. Fwure oj'Sojhmre
Engineering. Ed. Anthony Finkelstein. ACM. pp, 345-355.
Pfleeger. S. L. (1997), "Assessing Software Measurement". IEEE S()fnmre. March! ApriL pp, 25-16.
Pfleeger. S .. y Kitchenham. B. (200 I) "Principles of Survey Research. Part I: Turning Lemons into Lemonade",
..leH SIGSOFT. S()ft\mre Engineering Notes. 1'01, 26, n. 6. pp, 16-18.2001.
Pfleeger, S.L. (200 I). Software Engineering Theory and Practice. 2' cd. Prentice-HalL
382 CAUDAD DE SISTEMAS INFOIUv1A.TICOS RA-MA
Philips. M. (2001). CMMI 1.1 Ow"iew. NASA Software Engineering Conference: Carnegie Mellon. Software
Engineering Institute.
Piattini. M.. Calero. e., Genero. M. (2002) In{ol7nation and Database Qualit)'. Boston. Kluwer Academic
Publishers.
Piattini. M .. Calero, e., y Genero, M. (2001) "Table Oriented Metrics for Relational Databases", SO/l1mre Quality
Joul71al, Vol. 9, pp. 79-97,2001.
Piattini, M .. Calvo Manzano, J., Cervera, J. y Fernandez, L. (2003). AllIilisis y Diseiio de Aplicaciones
In/ormaticas de Gestion Una perspectim de Ingenieria del Software. 2' edici6n actualizada y ampliada. Madrid, Ra-Ma.
Pipino. L., Lee, Y., y Wang, R. (2002) "Data Quality Assessment". Communications a/the A CAl. April2002Noi.
45. No.4.
PMI (2004) A Guide to the Project Management Body 0/ Knowledge. 2004 edition. Project Management Institute
Communications, USA. http://www.pmi.ore.!infoidefault.asp (ultimo acceso en Agosto de 2006).
Poe Is, G. y Dedene, G. (2000). "Distance-based software measurement: necessary and sufficient properties for
software measures". In{ol7nation and SO/l1mre Technology, 42( I), pp. 35-46.
Pohl, K. (1994). 'The three dimensions of requirements engineering: a framework and its applications". Inrol7nation
systems, 19(3), pp. 243-258, April 1994.
Pressman. R. (2002). Ingenieria del Sojiware: un el!foqul! practico. McGraw-Hill, Madrid.
Putnam. L. H. y Myers, W. (1992). Measures Jar E>:cellence - Reliable soJllmre on time. \I'ithin budget, Prentice
Hall. New Jersey. 1991.
Raffo. D. y Kellner. M. (1999). "ivlodelling software processes quantitatively and e\'aluating the perfonnance of
process alternati\es". Elements a/Software Process Assessment and Impro\ement. CS Press. IEEE.
Raffoul W. (2002). The Outsourcing Maturit), Model. Meta Group: Stamford CT. Disponible en:
htm:iitechupdate.zdnet.comlechupdatc!stories/[nain ,ooolC 14 I 79%2C2 85 I 971-2%2COO.html#lc\cl I (ultimo acceso en
Agosto de 2006).
Ramanathan. 1. y Sarkar. S. (1988). "Providing customized assistance for software lifecycle approaches". IEEE
Transactions on SO/Mare Engineering, 14(6), pp. 749-757.
Ramasubbu, N., Krihsnan, M.S. y Kompalli. P. (2005). "Leveraging Global Resources: A Process Maturity
Framework for Managing Distributed Development". IEEE Sojhmre. '80-86.
Redman, T.e. (1996) Data Qualify/or the Information Age. Artech House Publishers, Boston. 1996.
Redman. T.e. (2001) Data Quality: The Field Guide. Digital Press. 2001.
Redondo. L. (2004). "Estado del Arte en la ISOI1EC 15504". Calidad. Septiembre 2004, pp. 22-26.
Reingruber M. y Gregory W. (1994). The Data Modelling Handbook. A best-practice approach to building quality
data models. Jolm Wiley & Sons, Inc.
Reynoso L., Genero M. y Piattini M. (2004) "Measuring OCL Expressions: An Approach Based on Cognitive
Techniques". Chapter 5 en l'vfetrics/or SO/Mare COl1ceptual Models (Eds. Genero M., Piattini ivl. and Calero e.). Imperial
College Press, UK. 2004.
g;'RA-MA BIBLIOGRAFiA Y REFERENCIAS 383
Robson. C. (1993). Reallmrld research: A resourcefor social sciemists and practitioners-researchers. Blacbvell.
Rombach. H. D. (1990). "Design measurement: some lessons leamed".IEEE SofMare. 7(3). pp. 17-25.
Saeki. M. (2003) "Embedding Metrics into Infonnation Systems Development Methods: An Application of Method
Engineering Technique". ~ i S E 2003: Pp. 374-389
Satpathy, M. y Harrison. R. (2002). "A Typed Generic Process Model for Product Focused Process Improvement".
Proceedings of the 26th Annual Intemational Computer SofMare and Applications COIiference (COMPSAC'02). Oxford
(England), pp. 379-384.
Saunders, M.N., Lewis, P .. y Thornhill. A. (2002) Research Methods for Business Students. 3rd Edition. Prentice-
Hall.
Scheer, A. W. (1998). ARlS- Business Process FramL7Jmrks. Springer.
Schekkennan, J. (2003) "Extended Enterprise Architecture Maturity Model (E2AMM)". Institute for Public
Enterprise Architecture Development. http: www.entemrise-architecture.info (ultimo acceso Agosto de 2006)
Schlenoff. c., Knutilla, A. y Ray. S. (1998). "A Robust Process Ontology for Manufacturing Systems Integration".
Proceedings of the 2nd International COI!ference on Engineering Design andAutomation. Maui (Hawaii), pp. 7-14.
Sclmeider. K. l' von Hunnius, J-P. (2003). "Effective Experience Repositories for Software Engineering". Proc. 0/
the 25'" Int. C04 on Software Engineering (/CSE03). IEEE Computer Society.
Schramm. W. (1971). Notes on case studies o/instl1lctionalmedia projects (December ed.). Washington DC: The
Academy for Educational Development.
Schuene R .. l' Rotthowe T. (1998). "The Guidelines of Modeling-An Approach to Enhance the Quality in
Infonnation "'10dels". Proceedings of the Sel'enteenth International COI!ference on ConceplZlal Modelling (ER '98).
Singapore. pp. 240-254.
SEI (1995). The Capabiliz\' Maturiz\' Model: Guidelinesjor bnpro\'ing the So/nmre Process. Software Engineering
Institute.
SEI (2001). Standard C\JAfI Appraisal :\Iethodfor Process Improvement (SCAMPI). r ersionI.I: Method De./inition
Document. CMU!SEI-2001-HB-00I.
SEI (2002) Capability /'v/alZlrity Model IT Imegration (CMMP!). Version 1.1 CMAflSM .lor Systems Engineering.
Sojhmre Engineering. Integrated Product cnd Process Del'elopment and Supplier Sourcing (CvlMI-SE SW;lPPDSS. VI. I )
http://\\"\\w.sei.cl11u.edU!publications'documents'02.reDort.'i'02trOO".html(ultimo acceso Agosto 1006).
SEI (2004). Capability MalZlriz\' Model Integration (e\/MI). rersion 1.1 CMAfI (CMMI-SDSHilPPD;SS. n.I)
Staged Representation CA/UISEl-2002-TR-012 ESC-TR-2002-012. En
http://\\"\\w.sei.cmu.eduioublications!documents02.reports02trOO". html (Ultimo acceso en Agosto de 2006).
Serrano. M. Calero. c..y Pianini. M. (2002) "Validating Metrics for Data Warehouses'. Proceedings (jlthe
Conference on Empirical Assessment in Sofnrare Engineering (EASE 2002). Keele, Reino Unido, pp. 8-10. abril 2002.
Serrano, M .. Calero. c.. Trujillo. J.C" Lujan-Mora. S. l' Piattini, M. (2004) "Empirical Validation of Metrics for
Conceptual Models of Data Warehouses". Lecture Notes in Computer Science 3084. Person, A. y Stima. 1. (eds.). pp. 506-
520. 16'" Intemational COIiference on Admnced In/ormation Systems Engineering (C.4iSE 2004). Riga (Letonia) Agosto
1004.
384 CAUDAD DE SISTEMAS INFORt'vlATiCOS RA-MA
Shankaranarayanan, G" Wang, R., y Ziad, M. (2000) "IP-MAP: Representing the Manufacture of an Information
Product". Proceedings olthe 2000 Conference 011 Inlol7nation Quality, pp. 1-16.
Shankaranarayanan, G., Ziad, M" y Wang, R.Y. (2003). "Managing Data Quality in Dynamic Decision
Environments: An Information Product Approach". Joumal olDatabase Mallagement, 14(4), pp. 14-32.
Shanks, G. y Darke, P. (1997) "Quality in Conceptual Modelling: Linking Theory and Practice", Proc. Pacific Asia
Conlerence ollinlol7nation Systems, Brisbane, Queensland University of Technology, (May), pp. 805-814.
Sheard, S. y Lake, 1. (1998). Systems Ellgineering Standards alld Models Compared Soltware Productivity
Consortium, NFP, 1998. En http://www.software.or!lipub!extemalpapetS
i
9804-2.html (ultimo acceso en Agosto de 2006).
Shewhart W.A. (193 I). Economic Control olQuality olManulactured Product. D. Van Nostrand Company, Nueva
York.
Shull, F., Carver, 1., Travassos, G., Maldonado, 1.. Conradi, R. y Basili, V. (2003). "Replicated Studies: Building a
Body of Knowledge about Software Reading Techniques". In N. Juristo y A. Moreno (Eds.), Lecture Notes on Empirical
Soll1mre Ellgineering (pp. 39-84). Singapore. World Scientific.
Siau, K. (1999) "Information Modeling and Method Engineering: A Psychological Perspective". Joumal Database
Mallagement. 10(4): pp. 44-50 (1999).
Silverman. 1., (1999) "Quality Today: Recognizing the Critical Shift", Quality Progress, February. pp. 53-60.
Simao, R.P.S., Y Belchior. A.D (2003) "Quality Characteristics for Software Components: Hierarchy and Quality
Guides". Compollelll-Based Soll1mre Quality 2003: pp. 184-206.
Smith, c., y Heights, A. (2002) "Defect Prevention: The road less Traveled". In Fundamental Concepts lor the
Soll1mre Quality Engineer. Taz Daughtrey Editor. American Society for Quality.
Sneed. H.M. y Foshag, O. (1998) "Measuring Legacy Database Structures". Proc 01 The Europeall Soll1mre
Afeasurement Conference, F S M ~ 98, Antwerp, May 6-8. Coombes. Van Huysduyllen and Peeters (Eds.), pp.1 99-21 I. 1998.
Sommerville, I. y Ransom, 1. (2005). "An Empirical Study of Industrial Requirements Engineering Process
Assessment and Improvement". A CM Transactiolls 011 Soll1mre Ellgieering alld Methodology 14 (I). pp. 85-117.
Standards Australia (2004). Standard Metamodellor Sofl1mre Del"eiopment Methodologies, drafi spec[ticatioll
AS4651-2004 fhttu:iiwww.standards.orf1.aul. ultimo acceso en Agosto de 2006)
Standish (2001) Extreme CHAOS D. Standish Group 1l1ternational. En
http:!;\\ww.standishf1roup.com!samole research;PDFpaf1es
/
extreme cl1aos.pdf(ultimo acceso en Abril de 2006)
Strong, D.M., Lee. Y.W .. y Wang. R.Y. (I 997a) "Data quality in context". Communication of the ACM, 40 (5), pp.
103-110.
Strong. D.M .. Lee, Y.W" y Wang. R.Y. (I 997b) "Ten potholes in the road to information quality". IEEE Computer
August 1997, pp. 38-46.
Stylianou, A.C. Y Kumar. R. 1. (2000) "An integrative framework for IS quality management". ComlllUllications of
ACM 43(9): pp. 99-104 (2000)
Swenson, K.D. (1993) "A Visual Language to Describe Collaborative Work". Proceedings of the 1993 IEEE
Symposium on Visual Languages, IEEE CS Press, 1993, pp. 298-303.
RA-MA BIBLlOGRAFiA Y REFERENCIAS 385
Taguchi G., y Wu. Y. (1979) Imroduction to Qtfline Quality COlllrol. Negaya, Japan: Central Japan Quality Control
Association.
Tague, N.R. (2005). n1e Quality Toolbox. Second Edition. Quality Press. Milwaukee. Wisconsin.
Taylor, R., Selby, R., Young. M., Belz. F., Clark, L., Wileden, J. OsterweiL L., Wolf, L. (1988). "Foundations of the
Arcadia Environment Architecture". Proceedings of the Third ACM SIGSOFTISIGPLAN Symphosium on SofMare
Development Ent"ironments.
Tayntor, c.B.. (2003) Six Sigma Software Developmelll. Auerbach Publications. Boca Raton (Florida).
TickIT Project Office (1992). Guide to Sofnmre Quality Managemelll System Constl1lction and Certification using
EN2900J, Issue 2.0, UK Department ofTrade and Industry and BCS.
Tiwana, A. (2000) The Knowledge Managemelll Toolkit. practical techniques for building a Ia/owledge
management system, Prentice Hall PTR.
Topaloglu. N. (1998). Assessment of Reuse Maturity. Computer Engineering Department Ege University, Bornova-
Izmir, Turkey.
Trillium Team (1994). Alodelfor the Telecom Product Developmelll and Support Process Capability. Bell Canada.
Tumey, A .. Grove, B. y McNairm G. (2004). "SPICE For Small Organisations". SofMare Process Improvement and
Practice, 9, pp. 23-31.
Van der Raadt, B., Hoorn, 1.F. y Van Vliet H. (2005). "Alignment and Maturity are siblings in architecture
assessment'". Caise 2005, Pastor, O. y Falcao e Cunha, J. (eds.), LNCS 3520, 357-371.
van Solingen. R. y Berghout E. (1999). The Goal/Question/Metric MetllOd, A Practical Guide for Quality
ImprOl'elnelll ofsofnmre Del-e!opment. London. England: McGraw-Hill International (UK). ISBN 007 709553 7,1999.
van Solingen. R. y Berghout, E. (2001). "Integrating Goal-Oriented Measurement in Industrial Software
Engineering: Industrial Experiences with and Additions to the Goal!Question/Metric Method (GQM),. P;'oceedings Sel'elllh
Intel7lational sofnmre Metrics Symposium (METRlCs'OI). pp. 246-258.
Vilar. 1.. (2006) Estadistica 2: resllmenes de los capitulos. http://\\'\\w.udc.es
Idep!mate
f
estadistica2!estadistica_2.htrn (ultimo acceso Agosto 2006).
Visaggio. C. A. (2005): Empiricall'alidation of Pair Programming. Tesis Doctoral. Departamento de Ingenieria.
Universidad del Sannio. Benevento (ltalia).
Vizcaino. A. Y Piattini. M. (eds.) (2006). Gestion del conocimielllO en ingenieria del Soft .... are. Universidad de
Castilla- La Mancha. Cuenca.
Wand, Y. y Wang, R. (1996) "Anchoring Data Quality Dimensions in Ontological Foundations". Communications
of the AC.\J (CACM). 39. (II). Pp. 86-95
Wang. R., (1998) "A product perspective on data quality management". Communications of the AC.H 1'014112) pp.
58-65. February 1998.
Wang. R .. Kon. H .. y Madnick S. (1993) "Data Quality Requirements Analisys and Modeling" . . Vinth International
Conference of Data Engineering. Viena. Austria, pp. 670 - 6i7.
Wang. R .. Storey: V., y Firth. c.. (1995). "A framework for analysis of data quality Reseach'. IEEE Transaction on
Kno\l'ledge and Data Engineering 7(4). pp 623-642.
386 CAUDAD DE SISTEMAS INFORMATICOS RA-tvlA
Wang. R., Ziad, M., y Lee, Y. W. (200 I) Data quality. Kluwer Academic Publishers. Massachussets (USA).
Wang, Y. Y King, G. (2000). Software Engineering Processes: Principles andApplicatiollS. CRC Press.
Warboys, B. (1990). "The IPSE 2.5 project: process modeling as the basis for a support environment". Proceedings
of the First Intemational Conference on System Development Environments and Factories.
Weber, K. y Rocha, A. (2004). "Modelo de Referencia para Melhoria de Processo de Software: uma abordagem
brasileira". Proceedings of the QUA TIC 2004, pp. 73-78.
Westcott, R.I. (2001) Lel'els o.fMaturity Matrix. Old Saybrook, CI: R.I. Westcott and Associates.
Weyuker E. (1988). "Evaluating software complexity measures". IEEE Transactions Software Eng., Vol. 14 No.9,
pp. 1357-1365.
WiMC Workflow Management Coalition (1999) Tel7ninology & GlOSSOlY. Document number WFMC-TC-IOII,
Version 3.0: Disponible en: http://www.aiim.om:iwfi11cistandards!docs.htm (ultimo acceso en Abril de 2006).
Whitmire, S. (1997). Object Oriented Design Measurement. John Wiley & Sons. Inc.
Widdows C y Duijnhouwer, F. (2003). Open Source Maturity Model. Cap Gemini Ernst & Young: New York NY.
Disponible en: http://www.capQ:emini.com!servicestechnolo!!Viooensource (ultimo acceso en Agosto de 2006).
Wilkin. C y Castleman, I. (2003) "Development of an Instrument to Evaluate the Quality of Delivered Infoffi1ation
Systems". Proceedings o.fthe 36th Hmmii International Conference on System Sciences.
Williams. L. Y Kessler B (2000). "The effects of 'Pair-Pressure' and 'Pair-Learning' ". Proceedings Conference on
So.fMare Engineering Education and Training (CSEE&T 2000). IEEE Computer Society Press: Los Alamitos CA. pp.59-{j5
Windley P. (2002). eGo\"el?1mel1l Maturity. State of Utah: Salt Lake City UI. 2002: Disponible en
htto: acceso en Agosto de 2006).
Wohlin. C. Runeson. P., Host. M .. Ohlson. M .. Regnell. B. y Wessh';n. A. (2000). Erperimel1lation in SofMare
Engineering: An Introduction. Kluwer Academic Publishers.
Xu. H. (2003). "Would organization size matter for data quality". Proceedings of the Eighth Conference on
Infol7nation Quality ICIQ '2003. pp. 365-379.
Yin. R.K. (2003). Case Stuc(l' Research: Design and .\/ethods. TIlOusand Oaks. Sage Publications.
Yu. E. S. K. Y Mylopoulos. 1. (1994). "Understanding 'why' in software process modelling. analysis. and design".
Proceedings of the 16 th Il1lernafional COI!ference 011 Software Engineering. pp. 1-10.
Zarnli, K. Y Lee. P. (2001). "Iaxonomy of Process Modeling Languages". ACSiIEEE International Conference on
Complller Systems andApplicalions 2001). Beirut (Lebanon). 26-29 June 2001. pp. -135-437.
Zelkowitz M. y D. Wallace. "Experimental models for validating technology". IEEE Computer. 31. 5. 1998.23-31.
Zubrow, D. (1998). "Measurement With a Focus: Goal-Driven Software Measurement?". CrossTalk 1](9),
Septiembre 1998. pp. 2-1-26.
H. (1998). A Framelmrk ofSojhmre MeasuremellI. Berlin, Walter de Gruy1er.
AHvlQ.189
.A.MFE.39
APEL.132
A
Arquitectura de Sistemas de Infomlaci6n Integrados. 112
ASQ.14.69
Benchmarking. 40. 66
CAF.66
CALDEA.303
Calidad de datos. 301
B
c
Calidad de la informaci6n. 289
Cali dad de los modelos conceptuales. 261
Calidad de los modelos 16gicos. 273
Calidad de producto software. 73
Calidad de Sistemas de Informaci6n. 75
Cali dad en uso. 84
Calidad extema 84
Calidad intema. 84
Casos de estudio. 346
CBA-IP!. 161
Cielo de vida de sistemas. 150
Cielo de vida software. 141
CrvfMI. 154. 181.214
Compelisoft. 191
Complejidad. 148
Control Estadistico del Proceso. 35
Core Plan Representation. 110
Coste de la calidad. 43
INDICE ALFABETICO
Definici6n de Calidad 3
Diagrarna de afinidad. 30
Diagrama de controL 23
Diagrama de dispersi6n. 29
Diagrall1a de matriz. 32
D
Diagrarna de procesos de decisiones. 33
Diagrama de redes de actividad. 33
Diagrama de relaciones. 31
Diagrama de causa-efeclo. 19
Diagrama de lujo. 19
Diagrama de Pareto. 21
Eficiencia. 85
EFQM.62
Encuestas. 73. 353
E
EnlOmos de Ingenieria del Software. 126
EV AMECAL. 308
Experimentos. 332
F actoria de experiencia. 326
Farnilias de estudio. 331
Fiabilidad. 86
F
Formato de intercambio de proceso. 108
Funcionalidad 85
388 CAUDAD DE SISTEMAS INFORMATICOS
G
Gestion de la calidad total, 49
Gestion de la calidad, 12,58, lSI
Gestion del conocimieto, 319
Goal Question Indicator Metric (GQ(I)}vf), 223
Goal Question Metric (GQivf), 214
Goal-Driven Software Measurement, 223
Histograma, 28
Hoja de chequeo, 22
IDEAL 164
IP-tvIAP, 291
ISO 12207, 142
ISO 14598,84,91
ISO 15288, 142, 154
ISO 15504, 179,236
ISO 15939,234
ISO 19011,53
ISO 25000, 83
ISO 9000,12,50,53
ISO 90003. 156
ISO 9001. 56. 59
ISO 9004. 53
ISO 9126. 83. 91
H
I
L
Lenguqje de especificacion de proceso. 109
Lenguajes de modelado de proceso. 103
Linea de c6ciigo, 241
M
Malcom Baldrige Nacional Quality Award. 68
Mantenibi1idad. 87
Manual de la Ca1idad. 14
Medicion del proceso, 237
Medicion del producto. 240
ivledicion del proyecto, 238
Medicion del Software. 199
Metamodelo de proceso software. 106
Metricas. 209. 236
Modelo de madurez de la capacidad (ClvEv!). 158
Modelo de McCalL 81
Modelo de proceso unificado. 110
MoProSoft. 190
MRmps, 188
N
Niveles de madurez, 45. 158
p
People-CMA!, 174
Personal Software Process (PSP), 167
Plan de la Calidad, 14
Portabilidad. 88
Practical Sofllmre Management (PSM), 229
Premio Deming, 68
Proceso somvare, 97
Promenade. 114
Puntos funcion, 250
QFD,38
QIP, 326
Registros. 14
SCAl'v!P!. 186
SCE,161
Seis - Sigma. 67
SERE)\:TI1PITY. 136
SMSDM.121
SPADE. 130
Spearmint. 112
SPEi\1. 116
TDQM.298
Q
R
s
T
Team Sofnmre Process ITSP). 171
TQdM,292
u
Usabilidad. 86
w
WorAjlow Management Coalition. III
RA-MA

Calidad en Sistemas Informaticos

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Calidad en Sistemas Informaticos

Загружено:

Авторское право:

Доступные форматы

alidad

Вам также может понравиться