Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Calidad en Sistemas Informaticos PDF
Calidad en Sistemas Informaticos PDF
I
alidad de istemas
I for aile s
Mario G. Piattini Velthuis
Felix O. Garda Rubio
Ismael Caballero Munoz-Reja
Alfaomega
Datos catalograficos
Piattini, Mario; Garcia, FelLx y Caballero, Ismael
Calidad de Sistemas Informaticos
Primera Edici6n
ISBN: 978-970·15·1267·8
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.
;\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
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
Ismael Caballero
INDICE
AUTORES ......................................................................................................................... XV
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 INFO~'vL-\ TICOS
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
1. INTRODUCCION ........................................................................................................... 97
2. GESTION DE LOS PROCESOS SOFTWARE .......................................................... 100
3. EL MODELADO DE LOS PROCESOS SOFTWARE .............................................. IO2
3.1. Elementos del Proceso Software ...................................................................... 103
3.2. Clasificaci6n de los Lenguajes de Modelado de Procesos (LMP) ................. 104
3.3. Metamodelos de proceso software ................................................................... 106
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 ORIENTADOS 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
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
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,
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.
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. PREFACIO XXI
El capitulo 2 resume las principales tecnicas utilizadas para la gestion de la cali dad,
pasando por las herramientas basicas de calidad, las estadisticas 0 las de gestion, entre
otras.
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.
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.
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.
1. Concepto de Calidad
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.
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 expresion «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).
CROSBY FEIGE7'lBAF\I
B~! 1.Estab1eeer que Ia
calidad es un proceso que
9. Eliminar las barreras entre
2. \!antener equil'os de abarca toda Ia
departamentos. animar a los
Parte del Proceso de \!cjom de mcjora. organizncion.
ditcrentes departamentos a
la CaIidad. 13. CtiIizar consejos de BM.J. Conseguir
trabajar conjuntamente en Ia
calidad. imp1icacion indi\'idual y de
resolucion dc problemas.
equipo (Ia calidad es
tmbajo de todost
10. Eliminar los objcti\'os
y cs16gancs
I1tlI110ricos. posters
10. Estabkccr control de
que cxigcn nuc\'os ni\'clcs de
configuracion sobre los
producti\·idad. sin
objcti\os de calidad.
proporcionar metodos de
mejora especiticos.
II. Eliminar est{mdares de
Presente en su libra Tora!
trabajo que cspccitican cuotas
QlIa/i~l' Comro! (aunquc
nurn~ricas. utilizar m~todos Parte del Proceso de \ !cjora de
no sc cite cxp1icitamente
cstadisticos para mcjorar 1a In Calidad.
en los principios ni en los
l'roducti\idad y calidad de
bcnchmarks I.
lQnna contmua.
12. Eliminar todas las batTeras
que impiJan a los trabajadorcs Pane del Proeesa de \ !cjora de 12, Tener un prograllla
s-(;ntir~(' l)rgullosos de $U la Calidad. de rcconocimicnto.
trabaio.
l~, Impbntar un prl)g:ran1u
Punc del Proccs~) de \kjura ('1.: ~. Tencr ronl1aci(~n
\'igoroso de cducacion y
la Calidad. 5upcl\'isada.
auto-mcjora,
B\12. Ca1idad e5 10 que las
clicntcs diccn que cs
B\!3. Calidad y coste s,'n
una suma no una
ditCr~ncia.
1. \!antener B\!6. Cali dad e
compromisa de 1a innoyacion son
direccion. mutuamente dependiemes.
3. Tener planes de B\!9. Calidad es cl camino
illcdici6n de la calidad. m{ls cfic[~z en costes y
loot In\'olucrar a tedo d
-+. Estimar el coste de 1a menos intensi\'o en capital
personal de Iu organizacilH1 en
Parte del Proc~so de \!cjora dc calidad. hilcia Ia producti\·idad.
la luella por conseguir la
1a Ca1id;1d. 7. Tener un progruma de B\!10. Calidad sc
transt~1nllacion. Esta es turea de
cero ddcct('ls. itnplcmenta con un sistema
todos.
.9. Lograr dias en los total concctilco con los
qu~c sea posible c1 iclltes y proyccdorcs.
encontrar cero defectos. 3. Calidad es csencial para
1-+. I-Iacer los 13 pasos 1a innovacion desde la
otm \'C2. 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)
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 ",
OPORTI..:";mAD
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
Hay que tener en cuenta adel11as que la calidad puede tener varios oIigenes (vease
figura 1.2):
Calidad Necesaria
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!.
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 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 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.
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.
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
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
5. (,Que diferencia hay entre una "acci6n correctiva" y una "correcci6n"? Ponga
ejemplos de ambas.
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 "
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.
alrnac. [~
interne
/ dato, I
Figura 2.1. Simbolos tipicos us ados en los Diagramas de Flujo
r I
I
1. Identificar
Dlme"'o.,, de -,- - r
Calidad
_ __
.:.sirven para
el problema?
2. Identificar
Metricas para
esas
dimensiones
N~----------~
4. Ejecutar el 3. Realizar un
5.0btener
Plan de plan de
Conclusiones
Mediciones mediciones
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
Fallos en los
-ilJ;> Sistemas
Informaticos
Ratones
Sueldos
Inferencia
bajos
Impresoras
Presion Procesamiento
Orden adores
3. Identificar de 3 a 6 espinas mayores que puedan ser las causas del problema
/ efecto principal.
7. Identificar causas de tercer nivel para cada causa de segundo nivel, y as!
sucesivamente.
Para elaborar un diagrama de Pareto hay que seguir los siguientes pasos:
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.
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
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
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
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
I Es posible detinir Llna serie de tests que demuestran estadisticamente que el proceso esta bajo control.
aunque todos los puntos es«~n entre los dos limites.
24 CALIDAD DE SISTEvl!\S INFOIUvi~TIeos @RA-MA
Los pasos que hay que dar para elaborar un diagrama de control pOl' variable son
los siguientes:
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 CAPiTULO 2: TECNICAS Y HERRAJvlIENTAS DE CAUDAD 25
340 UCL=339,5
320
3G'O
c
co
Q;l
L 280 X=275
Q,I
i5.
E
co 260
(I)
240
220
LQ=210,5
200 , , , ,
2 4 6 8 10 12 14 16 i8 20 22 24
Sample
Gr6fico It de Fallos de
Sistema de Informacion
200
R=88,5
o lCL=:O
, ,
2: 4 6 8 10 12 14 16 18 20 22 24
Sample
lCL=21O,5
2M~-. __- ,__- ,__- ,__- ,__- ,__- ,__- , , -__, , - - , , -__. -__. - . J
10 1;2 14 1$ 1S 20
sample
/
/~ ~/~\J\
/
'-J
\ /1', v--J+-<\, ~
---" /
L:::::;::=::;:=:::;::=:::;::=:::;::=:::;::==;:===;:===;:===;:===;===;=-.J L~L=O
8 10 12 14 16 18 20 22 2+
5ample
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
20,0
17,5
~
5 15,0
CJ
III
"E. 12,5
E
01
10,0
V~ (~
: : Alr' ,''m,.
\
1
3
1 1
6 9 U ffi ill
1
~
'¥aT\
~
1
v
1
~
LCL=5,61
Sample
Figura 2.10. Diagrama de Control por Atributos tipo np (generado con Minitab)
2.6. Histograma
12 UCL=1l,96
10
LCL=O
2 4 5 8 10 12 14 15 18 20
Sample
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 I]\iFOR.!vL~ TlCOS © RA.-IvL>\
120
iOJ -
5J
20
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
Q
0
0 0 C 0
0° v
0 0
y Q 0 0
0
°0
No y 0 0
Correlacion
0
o 0 C 0 0 0
Correlacion c 0
Negativa
0 00 0 0 0
0 0
x x
0
0
0
c 0
0
y 0 Correlacion
o 0 00
0 Positiva
o c o 0
o 0 0 y o 00
0 c (; 0 0
o
0
0 0 C 0 Correlacion
0 00 C c
X
0 0
0
0 Compleja
0
00
;::" 0 Correlacion
y 00 0 Fuertemente
00
0 0 Positiva
0 0
00
0 0
Los pasos que hay que dar para elaborar un diagrama de relaci6n son los siguientes:
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.
A c
Al igual que oh·as 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 enh·e 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.
... ~
VEWCIDAD I -4 I
S£GI3RIDAD I I 3
..
-:c- COl'T£NIDOS 5 I 3 I
Figura 2.15. Ejemplo de Diagrama Matricial
s RA-ivL\ CAPiTULO 2: TECNICAS Y HERRA.ivIIENTAS DE CAUDAD 33
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.
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 mosh·arse como un cuarto nivel.
5. Esrudia la viabilidad de cada plan de contingencia, mar·cando 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.
5. HERRAMIENTAS ESTADisTICAS
CORToPL4Z0 '
(h"i"IRAGRl1J>O)
LARwPtAZO
(h'i-m.-\GRD'.PO E,' PPU PPL
h"{lERGRllPO
En caso de ser necesario estudiar los dos, ambos deben valer como minima 1.33.
En otro caso, habra que aplicar acciones con'ectoras.
LSL
Prv-:~ss D.a:t;a;
1775;C1Cll)OCI
L5l USl
--Within
- - Over311
I
* Potential (Vnthin) Cap,bility
1825.JIOOOO
5"rnpl-= ""-=::tl) 18(t2)~S 149 Cp 0;23
S;rtlp.!~ N 1:; CPL 0,32
StD.;:vi)\IHhirl) 293308:9 CPLI QJ;;;:
StD.;v(O'~·\:r~!f) 28 .. 15313 <::pl; 0,2r.
CC?~~ (j:2~:
Overall Ca~'!!biSty
Pp 0,31)
PPl 0,3?
PPU 02~
P~k 0,2;
Cpm *"
Se ca1culan:
6. HERRAMIENTAS DE DISENO
Para realizar un proyecto usando QFD se deberian seguir estos pasos (Carretero et
al., 1999):
~
CARACTERisTICAS DEL
PRODUCTO
La voz dellngeniero
w
I-
z
w
::i >
U
..J,s "Ill
we
c.Sl ~~
enu inO
w- 0:3:
ZO MATRIZ DE RELACIONES oS:
0'" 3>
"t:I"
_ N
U 0 "';>;
«
u >
.., Clz
u::..J ~Gl
0
(j
W
"-
en
w
EVALUACION
Ponderaci6n de Requisitos
La tabla 2.1 muestra la infonnaci6n basica que se necesita manejar para realizar un
AMFE. Consta de los siguientes campos:
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
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.
7.2. Benchmarking
1. Planificar:
a. Definir los objetivos del estudio. Hay que elegir aquellos que sean
criticos para el exito organizacional.
2. Recopilar Datos:
3. i\nalizar:
c. DetenniI1ar las diferencias en las pnicticas que provo can dichas brechas.
4. Adaptar:
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:
N~'EL.nE lVlADli"REZ .J ..... ' .• \ DES<;,RIPClo.'\i. ..•. " to';.,>; TT~ C'. "".;.;:n.,: c";
No existe sistema de calidad fonnal 0 no se usa.
Reclamaciones y costes de fallos son altos.
." Auditorias
Bajo Coste de Cali dad
No hay mejora continua fonn~l
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.
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.
9. LECTURAS RECOMENDADAS
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.
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
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.
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».
Ortega y Gasset
1. INTRODUCCION
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.
Shewhart, y popularizado luego por W. Edwards Deming, por 10 que se conoce "Cicio de
Deming":
e Reconocirniento y celebraci6n
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
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-\
.
••••••
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.
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
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\1ATICOS ©RA-MA
Excelencia en
eI desempeiio
MINThlIZAR usn Eficiencia
DERECURSOS
Eficacia
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 Sistel~as 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
@ Enfoque bas ado en hechos para la torrta de decision: las decisiones eficaces
se basan en el analisis de los datos y la infOlmaci6n.
C informacion
+---- RESPONSABILlD,AD b'u
.. C
L DE LA DIRECCION
L
E
N
GESTION DE
RECURSOS
MEDICION. ANALISIS
Y MEJORA
--
info E
N
T
E
r--R-E-AL-IZA--C-I-O-N-' ~ T
DELPRODUCTO E
S requisitos
S
Figura 3.3. Enfoque de procesos segun la norma ISO 9000 (ISO, 2000a)
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,
CAPiTULO 3: MODELOS Y NORMAS DE CALIDAD 57
PORTADA
ANTECEDENTES
DECLARACION
PROLOGO
o INTRODUCCION
1 OBJETO Y CAMPO DE APLICACION
3 TERMINOS Y DEFINICIONES
5 RESPONSABILIDAD DE LA DIRECCION
BIBLIOGRAFiA
En cuanto al sistema de gesti6n de la calidad (apartado 4), la n0l111a sefiala que: "La
organizacion debe:
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,
En cuanto a los procesos relacionados con el cliente la nonna sefiala que: "La
organizacion debe determinar:
a) los requisitos especificados por el cliente, incll~vendo 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",
3.3.4.4. Compras
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.
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.
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
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 ~e !leva a cabo por medio de personas,
alian:::as), recursos, y procesos ".
e DesarTollo de alianzas
e Responsabilidad social
Resultados en
Personas
" uj " "vV~V v) las Personas
(9%)
Resultados
y Procesos en
liderazgo Clave de
Estragegia (10%) los Clientes
(10%) Desempeiio
(8%)
(10%)
Alianza y en
Recursos la Sociedad
(9%) (6%)
4.2.1. LIDERAZGO
<
, Niv¢ldeJ)eSempeiio "', " ",', "
Orientacion\. • "
4.2.3. PERSONAS
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 la tecnologia.
4.2.5. PROCESOS
4.2.6. CLIENTES
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. SEIS~SIGMA
• Prevenir defectos
• Reducir la vmiaci6n
• Centrarse en el cliente
• 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.
7. PREMIOS
Existen multitud de prellllos relacionados con la calidad, a continuacion
presentamos los mas irnportantes:
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.
5.
2. Planlficacion
Recursos
-( Estrategica
~~¢==:) .i
Humanos
. / .
~ 7. Resultados de "
.
:<f ~
/.----!!-~
Negocios
"'-.:.. ;/
4.Matiidas.Analls;s y GBStl6.n
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
8. LECTURAS RECOMENDADAS
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
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).
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.
CALIDAD DE SISTEMAS DE
INFORMACION
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.
Terninados
Con Exito
28%
Terninados
Gal
ceficiencias
49%
Terninados
Gal Fracaso
23%
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.
Estos dos factores definen cuah'o mercados, que requieren diferentes eSh'ategias de
negoclo:
c
o ;\1 Time
U
N C to CaUdad
H
S 0 Market
U S
M
I
D
P
o 0 Capacidad Coste
C
R 0
E S
S
pocos iv!UCHOS
PROVEEDORES
3. COMPONENTES DE LA CAUDAD
La calidad de un sistema infol1natico puede descomponerse en diferentes factores
que contribuyen a la misma.
Por otra parte, Stylianou y Kumar (2000) proponen una "vision holistica" de la
calidad 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
calidad de un sistema de infonnaci6n.
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 Calidad del personal
e Cali dad de la infonnacion
CAPiTULO 4: CAUDAD DE SISTE}'1AS DE INFORM.ACION 79
En los siguientes capitulos nos centraremos en los dos ultimos aspectos: calidad del
software, tanto de proceso como de producto, asi como calidad de la infonnaci6n, que son
los que mas atenci6n han recibido en los ultimos ailos.
4. LECTURAS RECOMENDADAS
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.
6. EJERCICIOS
1. Analice en que cuadrante del marco propuesto pOl' Card (1995) se situadan las
siguientes tecnicas:
b. Orientaci6n a objetos
c. HelTamientas CASE
d. Metodos agiles
80 CAUDAD DE SISTEtvL'\.S IN'FOIUvlA.TICOS © RA-tvL'\.
"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.
Vision de la direc!<.!c~i=o~n~~~~~====='V~i~s~io~n~de~l~d~e:s~a!.!.r!..!ro""I...,la",d",o,...r
Vision de usuario
Facilidad de uso- ~cr:;m~~I~~~1on
Comunicatividad
Seguridad (integrida Volumen y tasa de ElS
Operacion d Datos comunes
producto Eficiencia Control y audit. de acceso
Integridad de datos
Eficiencia de almacenam.
Eficiencia de ejecucion
Fiabilidad
Complecion
Trazabilidad
Revision de~ Facilidad de Consistencia
producto mantenimiento Precision
Facilidad de Tolerancia a errores
~~:~~~~i~li!!
P Concision
Flexibilida
rueba Autodescriptividad
Simplicidad
Modularidad
Transicion d~ Capacidad de Instrumentacion
producto reutilizacion Capacidad de ampliacion
Transportabilidat!7'"::::7C:::::::::=::~~~~ Generalidad
I Indep. maquina
Interoperabilida'lf'----------- ~~;!;jn~g:c.~eo~~t;~a
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.
i i
:
Requisitos de
I Evaluaci6n de
Calidad I Gesti6n de Calidad 2500n Calidad
2503n 2504n
j
Medici6n de Calidad
2502n
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
retroalimentaci6n
I t
Indica
Contribuye a especificar
~ I
Requisitos de Calidad
+-----------~
caUdad externa extern a
Validaci6n
I
Contribuye a especificar
i
Indica
~ I
Requisitos de
. CaUdad
+-----------~
caUdad interna interna
Verificaci6n
Calidad externa e
interna
. :
Capacidad de ser
entendldo Capacidad de ser
Adecuaci6n Adaptabilidad
rv1adurez Capacidad de ser Comportamiento analizado
Exactitud Instalabilidact
Tolerancla a rallos aprendldo temporal Capacidad de ser
Interoperabilidad Coexistencia
Capacidad de Capacidad de ser Utilizacion de cambiado
Seguridad de Capacidad de ser
recuperac16n operado recursos Capacidad de ser
aeceSD reemplazado
Capecidad de probado
Cump!imiento de atraccion Cumplimiento de
Cumphmiento de Cumplimiento de
la fiabiHdad la eficiencia Cump!imiento de
la funclonalidad Ja portabilidad
Cumplimiento de la mantenibi!idad
la usabilidad
2.2.1. FUNCIONALIDAD
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
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
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 fNrO~'vL'\TICOS © RA-?viA.
2.2.6. PORTABILIDAD
Capacidad del producto software para ser transferido de un entomo a otro. Esta
caracteristica se subdivide a su vez en:
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.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
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
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 declar·a 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
Tomar medidas
Valorar Resultados
niyel PlaneadO~
-
Excede los requisitos
val~~ satistbctorio
medido -=- Rango objetiyo
-
-
-
-
-
.
-
niyel actua~
-
-
- Minimanii!nte aceptabt~
-
-
el casu peo,--
insatistbctorio
-
-
-
- lnaceptabt~
-
-
-
escala de nii!dicion niveles de puntuaciOn
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.
Paso 1
Paso 3
Paso 4
Establecer Relaciones
Paso 5
entre entidades de calidad
4. LECTURAS RECOMENDADAS
• 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.
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
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).
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
EL PROCESO SOFTWARE
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).
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
Mejorar el
Proceso
Controlar el
Proceso
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.
Herramienta
D D
Figura 6.2. Elementos Basicos de un Modelo de Procesos
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
Lengu~es 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 Transiciones 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):
Organizaciona1
(Raffo y Kellner. 1999)
Lenguajes Fllncionales Lengu~es Fonna1es (Curtis et a/.. ! 992):
Funciona1
(Huff. 1996) I
;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
Compoliamental. Organizacional
actores (,{u y Mylopoulos. 1994)
I Es un modele explicito de los constmctores y reglas necesarias para constuir modelos especificos de
un detenninado dominio de interes.
(': 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 oh·os y por ella en la literatura se
puede enconh·ar 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.
Los diagramas de Gantt fueron creados por Hemy Gantt en el aii.o 1917.
Representan las diferentes actividades de un proceso como ban·as 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
Jlctjvidad 2
2Dias
A::tividad 1
/
1 Dia
\ Jlctjvidad 3
4Dias
----+
Jlctjvidad 4
3Dias
Entity
Decision Agent
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.
begin
Object Timepoint
end
at
participatesjn
in begin end
Activity
metamodelo, pero otras necesitan de mecamsmos mas potentes como OCL (Object
Constraint Language).
Pia n
Objective
Actio n
TimeSpec
E va lu a tio n C rite ria
Acto r Resource
may use /
from
may use may involve
is performed by
mayuse
3.3.8. SPEARMINT
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.
::>::':U
,
,'"isn:?!::,;",
,
,I
I
I
:
[ill -----------Ii> ~
I
~
Designer
3.3.9. PROMENADE
Model (UML)
MetaDocument I ! MetaRole
I SPMetamod
ModelElement (UML)
Trigger
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.
imports-modeJs
/
\ /
\ Imported Mod
1.'
maintaskMod 0 .. * \ / /0 ..•
has-as-maintask-cJass otherCI
~
0.. 1 model
dI SPMeiamod
I 1 has-as-other-cJass
I Class(UML) I
1 D <> 1Cl.", model
mOd~/ model "'" ", 1 has-as-roJes-cJass
has-as-task-CJa/,
'" "
''-.,
maintaskcl "
"'.
/
1.. '
1 1.: has-as-dc cument-cJass rolesCI
.'-.,"',
0.: I MetaTask iasksCI I
subtasksCI . doesCI 1.: MetaRole
....---; I
I
I
I
·......~ask II MetaDoeument i I I
supertaskCI
·'·... 1 I
0.. 1 '.
!
1 .
""
has-as-subtasks-cJass
has-as~~rameters
'. . ..
parameters ",....
doc
consists-of
1.,* ...... 1.:
"
I Parameter (UML) I
€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).
3.3.10. SPEM
usa produce
0 ..* 0 ..*
Actividad
ModelElement
(from Core)
Classifier
(from Core)
WorkProductKind
Parameter
(from Cora)
v:';ird Parame!erOirectionKind
0.:
Operation
(from Core)
ActivityParameter
nas\·:ctf.PerA:1Jl a::t : Bc:)~ean WorkProduct
-parer,tWOtk
0 .. " 0 .. 1
Activity . . Step ActionState
(from ActivitjGr<l;)hs)
ProcessRole -:es;::):':sloleRcle
.... sep
+asSs.ant 0 .. "
Los principales diagramas UML que pueden ser utilizados para representar las
distintas vistas de un proceso software son los siguientes:
Producto
/" ~,"
---=
//'~;d
:C6digo de :Base de
los Datos
Componentes Fisica Manual de
Usuario
<~Oisciplin~':>:=
!l7;;::4em~rt.-:e:-i';)n
o:<Clzci;;line::>::>
?rtP..<oas
Realizar
MOdelos
Sfstema
Arquttecto
clel
Sistema
Realizar
Modelns
Usuario
/"" <Step>
Revisar el Trabajo
Revisar los Realizar If.lejorar eJ
realizado en el
Modelos de l!lterfaz Prototipo
Proceso y las
deUsuario
Definiciones de
Initial Clases Final State
State
3.3.11. SMSDM
Proyaeto
Apflcaciones ------------r-----
Antiguas \
Inicio
Bahoraeion del Diseiio de fa Generacion de Espeemeaeion del Fin
Modelo de Datoll(p. Arqulteclura de A Especfficaciones l Plan de P[!mbas
DT.AYD.10l I', MOdulos del Sistema J ; de Construccioll (P- \ iP.DT-AlJD.40i
(P.DT.AYD.20) \ DT-AYD.3tJ) \ I
'i
\
'i
\
\
:Cuallernos
!IeCarya
:Cat4logo
Detan~do de
Req1iiSltos
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
!ModeIUnitUsase-Kind' I Notatio-o
!...l:;S~r.gh:;!~S:.a,~:;~ ,,"",,"0
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 Wor~1lo-\\'Kind, un cOI~unto cohesivo pero heterogeneo
de tare as que persiguen una serie,de objetivos. La unidad rmis simple de trabajo es la tarea
(TaskKilld) 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.
{lil
~
;;;?
0.. '
CornpOfliHl!
0.'
,
,,I ,
I
I I
I I I
I I I
I I I
I I I
_.~ I I __.___ L~_
ICumpmWI11
I T,,,k -I US05 ~ I
I
I
n
2;;
0'
I 0' :::r
:;;
~
o
'"
tT1
r
~~,_____
"tJ
,Contexl
6n
m
SL_ (f)
o
(f)
0: o
::q
,Con!m(j
~
Figura 6.22. RCpl'cscntaci{H1 dc los Aspcctos dc Proccso con SMSIlM (Hcndcrson-Scllcrs y Gonzalcz-Pcrcz, 201M) ,'-'
v,
126 CAUDAD DE SISTE;VIAS INFORM.A.TICOS .1;) RA-MA
1..'
.----,
-C.::lUGO
Performs. ~Erkc! A:rsUpcn '" .-SU::;jC:: WorkProduct I
1--____. , ' - - - - - - - - - - - j_ _ _-j------------j+Creat<):lDate
+Lasl:hangeDaie
1.: +Status
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.
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 APPLIA (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 hen·amientas. 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 . Motor de
Modelo de Capa de Comunicaci6n
Procesos y
Repositorio de
~ ... . <ill
Procesos
Procesos j. J. A
'f
"
Canales de
importacion Espaciode Espacio de
Trabajo Trabajo
y exportacion
Vf
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.
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).
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 "ot/~!ine" 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.1. SPADE
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.
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:
Filtro
Interfaz de
Comunicaci6n
SPADE
8
Cliente 02 C!lente 02
8
Clients 02
Servidor 02 . BBDD
00
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.
Campiladorl
Interprete _ _ _ _ _ _ _-'-_ _ _ _ __
_ ______v_
Saporte en Tiempo de Ejecuc!6n
Motor del Metodos Built-In
Proceso jyietoaos de Usu8no
Herramlentas de Usuario Servicios de
Ejecuci6n
Modelo
Principal
COlllroi:flolr
5D
4.3.3. SERENDIPITY
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.
m 1:modell -roles
@ ml . 1 : d<i'::~ ign~X'
d~s: igfl chtln9~S: "~d.~s: i9n~:J.~
miW
~ 'J';"'';
:'if""
(,r)
..... ©
d~$i9n~:c
X ~ {;!)
rR t1~d",1l",,,-
'''It-
I=:J ",dit,;
F\.J)H~ [EJ t"lk,; with
(.f) •. ~., ..
.....
...... .
r orm:f;u i Id",,- :IJ!.•••
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.
~fl
OO:@
Ii O,ew i) (Rdd l Delete 1
Conte!!t ) ( Undo ( Redo 1 l Cancel J
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.
5. LECTURAS RECOMENDADAS
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 N°1500, 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-
tlier.de/~ley/db/conflewspt/ 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
6. EJERCICIOS
1. Representar el proceso de METRICA 3 "Planificaci6n de Sistemas de
Informaci6n" (vease http://w.\vw.csi.map.es/csi/metrica3D utilizando los
siguientes Lenguajes de Modelado de Procesos:
a. Diagrama de Gantt.
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.
MODELOS DE PROCESO DE
CICLO DE VIDA
Goethe
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.
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.
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 serv·icio 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
MANTENIMIENTO VAUDACION
REVISION CONJUNT A
PROCESOS ORGANIZACIONALES
GESTION AUDITORiA
MEJORA USABIUDAD
..............
Figura 7.1. Procesos del cicio de vida software segun ISO 12207
--7 Se desarrolJa una estrategia para lJevar a cabo el aseguramiento de la cali dad
--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 desan·ollo 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
-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
MODELOS Y METODOS
OTRAS ENTRADAS
ESTANDAR
TIEMPO
DINERO
-
I--
DE
PROCESOS
DE CICLO DE
VIDA DEL
SOFTWARE
b\D
CASCADA
ISO/IEC
I REQUISITOS
I LEY
SEGURIDAD
I SEGURIDAD FislCA / METODOS
ENTORNO
MANUAL DE
CAUDAD
I
PROCEOIMIEI'HOS
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.
---? Actividades y tareas seleccionadas a partir de los procesos de soporte, tales como
Verificaci6n, Validaci6n, Revisiones Conjuntas, Auditorias y Resoluci6n de Problemas.
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.
4. LECTURAS RECOMENDADAS
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.
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.
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.
3. Lleve a cabo un estudio comparativo entre los estandares IEEE 1074, ISO 12207
e IEEE 12207.0, IEEE 12207.1, IEEE 12207.2.
"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.
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 ~ ~ ~
( Bootstrap)
~~
( MPSB, )
( MOPROSOFT )
( ISO 15939 )
•
~
(SsEl
~
( Baldrige)
(IeEel
~
---l> Sus:i:Uye a
... Basado en
< ISOIIEC 15288 )
... UsaReferen:::ia
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
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
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.
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.
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 CAPiTuLO 8: EVALL'ACION Y N!EJORA. DE PROCESOS 159
Pn3cticas Clave
(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.
Los dos principales metodos de evaluaci6n basados en CMM son SCE (Sofhrare
Capability Evaluation) y CBA-IPI (CMM-Based Appraisal for Internal Process
Jmpro1·ement). 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.
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.
t
Soporte para
t
Soporte para
t
Procesos de Toma de Procesos de
Procesos Tecnicos
Decisiones y Comunicaci6n y
Comunicaci6n Tecnicos
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.
PL~"IFICAR y
Identifica las areas en las que la organizacion careee de experiencia
(indicando un riesgo potencial)
REALIZAR LA PREPARACID:-'-
PARA LA • Deline el alcance de la cvaluacion.
EV.ALV.KID:-'- 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:
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.
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.
CAPiTULO 8: EVAlUACION Y MEJOR:\ DE PROCESOS l65
Aprendizaje
Estimu!o
. para fa
f.lejora
Iniciacion
Diagnostico
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:
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
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:
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
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:
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:
1315:05
CmUDZO
7:58
It FI"i
8:45
TlEMPO
{;I;TERRliP.
3
DELTA
..J...J.
I FASE
Planificar
!
COME2"TARIOS
Llamada telefono
Crear y revisar
8:47 10:29 2 100 Diseiiar
diseiio
Codificar main y
7:.+9 8:59 70 Codifiear I todas las nmeiones
9:15 9:46 31 Compilar Compilar y enlazar
Ejeeutar pruebas A.
9:47 10:10 l'
-.) Probar
I I I 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).
170 CAUDAD DE SISTEMAS INl'OR?vL~ TICOS &; M-Nt\
I 20 I
I... Ei";
C6digo
I EN
I COMPIL I
TIE:VJPO·
.CORRECCION
22
II CORREGIDO
13/5/05
N°
2
i
i
I
TIPO
20 I
Er,\,
C6digo
II EUlIcUNADO
EN
COMPIL I
TlEMPO
CORRECCION
[8 I
CORREGIDO
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.
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
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.
Equipos
Integrados de
Productp
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.
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 OU·os
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.
Practicas
de Mejora
Continua
Pr<3cticas
Medidas y
Autorizadas
Practicas
basad as en las
competencias
Practicas
Repetibles
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.
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
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
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.
Modelo de Referencia
Marco de Trabajo
del Proceso
de la Medici6n
- Dominic y Alcanc,:;
- Propos ito del Proceso
r-""""'11r----i - Nivelcs de Capacidad
- Atributos del Proceso
- Resultados del Proceso - EsciJ.!a de VaJoracion
Entrada Inicial
- Proposlto Salida
- Alcance Proceso de Evaluaci6n - Fectla
- Restriccion:;;s - Planificaci6n - Entrada de !a Evaluaci6n
- Jdentidades - Recopilacion de Datos - !dcntificacl6n de la E'Iid2ncia
- Validacion de Datos - ?rocesD d<;: =valua:;16n utiilzadc
de Competencla • Valoraci6n Je los Atributos del Proceso
- Generacion de Informes
Roles y Responsabilidades
- ?3Irocinaoor
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) 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
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. •
DISCIPLINADEL
MODELO .... MODELO FUENTE
.'.
DESCRfPCION MODELO FUE1';lE
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
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.
En la representaclon por etapas las areas son agrupadas dentro los niveles de
madurez que van del nivel2 al5 (figura 8.12).
Gesti6n \.,uam.lIa'Clva
(2 Areas de Proceso)
(7 Areas ce Pro:eso)
Figura 8.12. <~reas Clan de Proceso agrupadas segun la representacion pOl' etapas
(Philips, 2001)
£:. RA-ivLA. CAPiTULO 8: EV ALUACION Y lv!EJORA DE PROCESOS 185
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.
Representacion Continua
C
a 5
p 4
a
c 3
i 2
d
a
1
d o
Proceso
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
!
- Gl"':!ri6n til' Rl'qubitos - Ge'llit'11l de Confi~ur;\(::i()n
- DciinidtlO ProCl':;O Organizaciollai - :\lonituriL:tciull ) Control dt: _ Dt:~r:wr()110 de Requisitm - A.,i.'gunmlicnro de la CaUdad
- FOrlll:.ldrlll Org:lOiJacioIl!li _ ~oluciun Tecnica del PrnCl'SO y Pruducto
- Rt:ndimicnto - Inh'~nlci6n del Producto - .\It"dicioll y .\n:iJi:.i<.
- Inu(n :Jciun ~ Dhrribuciun d Sumini<.tflluor _ \'erificacillll - AIl:ilbi<. dt: Dt:(i~iont:" y Rt:~nlud6n
Organi/aciollai - Gestiim Inft:grad:l de Proyt'ctu:, _ Validacion - An:ilhl<, Cl.u,ai y Rt:,o]udtln
Gt:~ti6n de Rie\go':!
- Gc .. ti{I[l Cuantirati\a dt:
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
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 INFO~\tA.TICOS
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.
ISOIIEC 12207
ISOIIEC 15504 (SPICE) - -_ __
CMMI
Metodos de
Niveles de Madurez -<!,.I----il\lll>
Evaluaci6n
Guiade Gufade
Guia General
lmptementacion Eva!uacion
MPS
MPS MPS
Empresa 1
Empresa n
Figura 8.15. Modelo de referencia para la mejora de proceso software (MR pms)
."
GRADO DE
•··..·GRADODE
Ii\fPLEYIEi'ilAclON CARACTEruzAcroN . ",
ALC.4c"lCE .•
DE L.'\ PRACTrCA
Largamente • Existe por 10 menos un indicaj:lor indirecto y!o atimmci6n para > 50~o a
implementado confimmr una implementaci6n. 85%
• Fueron observados uno 0 mas defectos.
Parcialmente
implementado
·• Un indicador directo no esta presente 0 es juzgado inadecuado
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 OU·os roles involucrados. Ademas se considera a1
C1iente y a1 Usuario como roles extemos a 1a organizacion.
«Prcceso»
Gestio;'! de r~egodo
(from Alta D:recckSn)
<<Su!:l?roceso» <<$utJProceso»
«Proceso» genes, Servi::iQs e Inrraestru::tu:-a
';dmn:stracf::in de Proyectos Es;;ecifl::os {from GestiOn)
(from O;;eraci6n)
<<$wbProceso»
Desarool:o r'lenten:mento de Software
PYMES Iberamericanas
(beneficiarios - stakeholders)
Resultados de
la Investigacion
Resultados de
la aplicacion
Propuestas
empresas y organizaciones
participantes en el prayecto
(gropo eritico de referencia) Mejorade It:isProcesps Software
de las PYMES iberomericimas
(objeto itivestigado)
Itados refinados
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
7. LECTURAS RECOMENDADAS
• 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
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.
3. Definir una version del modelo CMMI pOl' etapas adaptada a las pequeiias y
medianas empresas (PyMES).
9. l\1edicion de Sistemas de
Info:rmacion
MEDICION DE SISTEMAS DE
INFORMACION
Tom Delvfarco
1. INTRODUCCION
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 contI·olar que es 10 que OCUlTe en los proyectos
y poder mejorar los procesos y productos (Fenton y Pfl~eger, 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).
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]
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 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 fl\;rO~'vLi. TICOS
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
Necesidad de Informacion
{!:"~'" C"r~"'.=".:"c::n y O!:>;e:;,es)
seCQrrea:::;r;:;e c:;n
Tipo de Es::ala
\fr:;;mMt-t!\e::!s)
Modelo de Calidad
e,"af:ia Concepto Medible
- :rc"'C"!'3~"''':'''Z':>'lyo::)e::,~) Escala Unidad
C0dase
de:;r;.:fopara
Entidad s;;: rea";;:;; S::;:JriJ Medici6n MtHrica Dire eta l't1etrica Indirects Indicador
t:ror.:-.li!etn:as) {~m M~:n~as)
s:;::;·Enidaj (!:-C'" C"r":;,.<:',,z,,:,::n y C::j~~~CS)
:;eir:c::!DC"
Medida
Fcmna de Medir
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 mett·icas. 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.
Una definicion y explicacion mis detaIl ada de los tel111inos de la ol1tologia puede
consultarse en (Garcia et af.. 2005).
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.
Identificacion
Reutilizaci6n
i Metrica Retirada
...
Objetivos ~ Hipotesis . Acreditacion
r'''''m,"","' j
Objetivos
y Requisitos
Creaci6n
Aplicacion
Objetivos
<I
r Metricas
Aceptadas
4,
A
Validacion Empirica ... Aceptacion
Validacion Metricas No
~- --- .. -- Experimentos Aceptadas
Te6rica
~, Explicacion PSicologica
Metricas Validas
<I> 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.
Practical SofwareMeasurement(PSM)
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.
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.
Alinear las
Actividades de
Analisis de la
Medici6n
Peesonal
Me dici6n de t..
4
~y.
Proporcionar
los resultados
de Ja Medici6n
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):
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
Datos Recopilados
2.2.1. PLAl'TIFICACION
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:
2.2.2. DEFINICION
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?
5. Revisar preguntas e hipotesis, para asegurar que se han fODnulado las preguntas
e hipotesis COlTectas.
~RA-MA CAPiTULO 9: ;"!EDICION DE SISTEMAS DE INFOR.!'vIACION 219
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.
Interpretacion
Objetivo .
Modelos
Implicitos Preguntas
Definicion
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:
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.
2.2.4. INTERPRETACION
COSrES BENEFICroS
Tiempo empleado por el equipo GQM en
Ventas adicionales derivadas de la mejora de
preparar un programa de medici6n (salario y
cali dad
gastos generales)
Tiempo empleado por el equipo del proyecto en Evitar decrecimiento en ventas debido a la
reuniones mejora de cali dad
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
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).
NFK (T)
RFK (T)
NA (T)
iii Pregunta 2:
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.
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).
Paso
I
Objetivos de Modelo Mental
Negocio
v
<1
Paso
c""" Q EI Proceso
C"C"".
Objetivos de
01 02
Medici6n
Objetivos de
Medici6n 01 02 Objetivos
:'\cgocio- SubObjcti\"os - \ledici6n PlantilIu de Definicion
Paso de Indicadorcs
.. <& . (Ji'I:.::i;(1
P:<!fl.::l''::'~
Preguntas
P1 P2 P2
Prcguntas
»A . <\
Paso (',Que quiera suber 0 aprcndcr'!
11 12 13 14
Indicadores
lndicadorcs
-e ~ » 1! ..
M1 M2 M3
MtHricas
Paso
.
Listas de Comprobaci6n
Definicion de .\Ictricas SLoe - EsfuerLo - Informes de
Definfciones Problemas
V
)(
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.
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: ~lEDICIOl\ DE SISTE~IAS 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.
PSM prop one un Modelo de Procesos de Medida (figura 9.10) que se divide en
cuatro actividades principales:
Realimentacion
de los usuarios
PROCESOS TECNICOS Y DE
GESTION
Analisis de
Objetivos y Resultados
Tareas
Analisis de
Resultados y
de la Realizacion de
Acciones de Mejora la Medida
Evaluaci6n ~
Ambito de PSM
Constructor de Medicion
Medida Medida
Indicador
.........fIi>- Producto de
Atributo Informacion
Base Derivada
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 I~FORlvL'\ TICOS
Factor
\!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 INFO~'vL-\(IO]\ 233
3. Analisis de los Resultados de las iVIetricas del Software. Paso compuesto por:
c. Procedimiento de yalidaci6n.
d. Requisitos adicionales.
234 CAUDAD DE SISTEMAS IN"FOR.cvlA TICOS :£,:
c. Procedimiento de validacion.
d. Requisitos adicionales.
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
Necesfdades Rea/imentacion
de Productos de los usuarios
Informacion Informativos
v
Establecer y
Mantener el :: Planificar el
Evaluaci6n
compromiso de proceso Productos
medici6n Compromiso
p!anfr7cacfon <I fnformativos
y
Resultados de
f.1edidas
Las tareas para las diferentes actividades del proceso de medicion de acuerdo al
estandar se muestran en la tabla 9.5.
I
ACTIVlDAI) 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
Definir los procedimientos de recoleccion de datos. analisis e infol111eS
Planificar el Proceso de Medicion
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
Tomar los datos
Realizar el Proceso de i\ledicion
Analizar los datos y desanollar productos de infol111acion
Comunicar los resultados
Eyaluar los prodllctos de infol111acion y el proceso de medicion
EYalllar la Medicion
Identiticar las mejoras Eotenciales
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
Metricas de Proceso
Metricas de Metricas de
Producto Producto
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).
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.
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.
las metlicas de codigo fuente mas imp0l1antes son Lineas de Codigo y longitud
Total.
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 ~l III +~12.
e Longitud global del programa: N' = III . log2 (Ill) + ~12' log2 (~12)
V(G)=A-N+2
~RA-MA C-\piTULO 9: MEDICION DE SISTEMAS DE INFO~'vlACION 2.+3
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.
.\·zimerode.\/elodosSohrees('}"iloS * .\"i,·elde.~llidamiellloEIILaJeranfzli'l
SIX .\"zimero TOlalDe.\/elOdos
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).
I :\DEP I Nllll1ero total de relaciones de dependencia.
:\GE:\ :\'llmero total de relaciones de generalizacion dentro de un diagrama de
I 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,
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.
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.
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
Archivo Externo:
Entrada: 1. Documento que se ha de revisar
- --------- --------- ----------
1. Nombre del documento que se ha de
revisar
Consulta:
1. l.Cuantas palabras
se lIevan procesadas? Comprobador
Usuario
Ortografico
Salida:
Archivo Interno:
1. Numero total de palabras revisadas
1. Diccionario
2. Numero total de errores detectados
3. Lista de palabras con errores ortograficos
15
PFSA= "LPesoi* Elementoi
i=l
10. Reusabilidad: indica si gran parte de la fUl1cionalidad del proyecto, esta pens ada
para un uso intensivo por otras aplicaciones.
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.
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:
Giles y Daich (1995) distinguen las u'es principales tareas que deben realizar las
herTamientas de l11euicas y las caracteristicas necesar~ias 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
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.
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.
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 Calidad de los
Calidad del SGBD
Modelo de Datos Datos
Calidad del
Calidad del Calidad del
Modelo
Modelo L6gico Modelo Fisico
I Conceptual
I
Figura 10.1. CaUdad de fa informacion .r de fa 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 r~FORMACI6!\ 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.
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
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 INFORc\L~ TICOS
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.
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
<I> Interpretacion de la audiencia (I): conjunto de todas las sentencias de las que
la audiencia piensa que consta el modelo.
<I> Conocimiento de los participantes (K): union de los conjw1tos de sentencias
de todos los actores sociales individuales.
MODELO
...:.:.J-' - LENGUAJE
CALIDAD tt PRAGj\lL~
CALIDAD
TICA
t ""
SEMANTICA
PERCIBIDA
.. ) CALIDAD
SOCIAL
CONOCIMIENTO INTERPRETACION
DEL PARTICIPANTE DE LA AUDIENCIA
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.
i
I MEDIOS
TIPOS DE CAUDAD OBJETfVOS
I PROPIEDADES :'IlODELO ACTIHDADES
Verif Consistencia
Validez \-iable Semantica fOTInal
SE\L-l,\'TJCA Insercion sentencias
Complccion viable Moditicabilidad
I BOlTado sentencias
Insercion sentencias
SE\lA?\'TICA
BOlTado sentencias
PERCIBIDA
Entrenamiento
I Inspeccion
.
I \-isualizacion
I
Economia .;xpr.;si\-a II Filtrado
I
Estetica Presentacion diag_ !
I
Paratl-ascar I
I
PRAGXIATICA Comprension \-iablc I
I Explicacion j
I I
I
I I Entrenamiento II
II
I I Ejecucion
i
Ejecutabilidad Animacioll
I
I Simulacion
I I
I
I :\n,\lisis punto \-ista
I II
SOCL-l.:L Acuerdo \-iable ~[odelado contlicto I Resolucion cont1icto
Fusi6n de modelos
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 I0:FO~'vlACI6N 265
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):
METODODE
STAKEHOLDER
EVALUACION
~ l\rIODELO
-,-~r
/
FACTOR D E .....
4.II1----iii!ilt>ilO>
CALIDAD
VALORACION
ESTRATEGIA DE MEJORA
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.
/ /
MODELO
DECALIDAD I'
V
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
;:
~
z;.;J Q a ~ -9
u 2: ~
Q
-:::
:::::
"- ~ g ~
<:::)
I
:::;
...l
~
;;;:
~
Q
.:::::
c;
2 ""
==
"- ::< '~ :3 ;;::
==
~
0 ~
u Ci5
~
r_ I..i !
.. , .. COMPRE\'iSIBILIDAD
'.
Sln'iPL'(CID.W ••
..
FlEXIBILJDAD
COMPLEtION
l;\fPLE;\IEi\TABrLID,W +
I:\TEGRIDAD
Tabla 10.4. iVIetricas para evaluar la calidad de modelos E/R (Moody, 1998)
268 CA.LIDAD DE SISTDIA.s I"'FOR..\L~TlCOS
~IETODO DE
YALORES !h':-------B~
___-"I 'pun,". E\ALL\CIO"
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 ot·o. 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
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.
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:
DliHENSIO:-''ES
..
USABILIDAD I
1·······USUAlUO ...•.•
USABILlDtill··
DISEl'/ADOR··
·j\h.!"lTENF
BILlDAD
IJ>REbSIONIRENl)~nE~tO
.. ....
Adecuaci6n al
X
problema
"'.:;.".< ......
.~~u.,,~"~w Validez X X
Consistencia X X X
I
:> Concisi6n X X X
.... : ..
Compleci6n X X X X
,..;; .•...
Cohesi6n X X
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.
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.
PRINCIPIOS I OBJETlVOS 1
Consenso a cerca de la definicion de la definicion del problema
Consenso a cerca de la representacion del modelo
Principio de adecuacion de la
Consistencia intra-modelo
I construccion
Consistencia inter-modelo
I Minimalidad
Correccion dellenguaje
Adaptacion dellenguaje
Principio de adecuacion dellenguaje Poder Sel11<lntico
Fonnalizacion
Comprensibilidad dellenguaje
Consenso
Principio de la eficiencia economica
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
Principio del disel10 sistematico comportamiento II
;\rquitectura.£ de los sistemas de infonnacion
I
Comparabilidad a nivel de meta modelo
Transfonnacion completa I
Principio de comparabilidad
Traduccion consistente
Comparabilidad a nivel del modelo I
Tabla 10.6. Principios de la Guia de Modelado (GoM)
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 calidad de las mismas.
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.
.METRICA NOTACION I .. .
Numero de
NA(T),
Atributos de una definida como el numero de atributos de una tabla T
Number of Attributes
Tabla
Numerode NFK(T),
Claves Ajenas Number of Foreign definida como el numero de c1aves ajenas de una tabla T
Keys
Definida como la profundidad maxima de todos los caminos
Profundidad del
DRT(T), referenciales del grafo que se forma, tomando la tabla T como el
Arbol
Depth of the nodo raiz del grafo y todas las tablas relacionadas con T mediante
Referencial de
Referential Tree. integridad referencial como el resto de nodos y siendo las
una Tabla
relaciones de integridad referenciallos arcos del mismo
definida como el porcentaje de atributos de la tabla T que son
Ratio de Claves c1aves ajenas
RFK(T),
Ajenas de una
Tabla
Ratio ofForeign Key RFK (T) = N~K (T)
iVA (T)
Numero de NT,
definida como el numero total de tab las que hay en el esquema
Tablas. Number of Tables
definida como la suma del numero de tablas al cuadrado que hay
en cada componente no conexa del grafo del esquema, siendo los
COS, nodos de este grafo las tab las del esquema y los arcos las
Cohesion del
Cohesion of the relaciones de integridad referencial
Esquema.
Schema 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
Ratio de NR.
Normalidad. Nonnality Ratio NR= NT3NF
NT
Siendo NT31\Tf es el numero de tab las en 3NF
NA, definida como el numero total de atributos que hay en el esquema
Numerode ST
Atributos.
Number of
Attributes
NA = L: NA(I;)
i=1
E:'>IPLEADO 10 :: 3 I /~
,
DEPARTA:'>IE:-iTO 4 I .) l/4
ESQCDIA 36 I 8 8 5 217
Trabaja_En
Empleado
C """"
"'I"
Dependiente
t+
Departamento
A1
~ii'
-+
Lugares_Depts
Proyecto
I
I I
LL .
Figura 10.S. Grafo Relacional del Ejemplo
Producci6n Instalaci6n
CodProducto Codlnstalacion
NombreProducto Nombrelnstalacion
Receta Localizacionlnstalaci6n
HechosProducci6n
ConGas l~--/~ ----~-------- Gestorlnstalaci6n
Oesnatado
1"-"-'- '" CodEjecuci6nProducci6n Estado
UnidadProduccion CodProducci6n
GestorProducci6n Codlnstalaci6n Momenta
CodMomento
CantidadProduccion
1-· CodMomento
- Fecha
NombreMes
Usolngrediente
Ingrediente NumeroMes
CodProduccion Ano
Codlngrediente Codlnstalaci6n 1-- Temporada
Nombrelngrediente -- ~---
CodEjecuci6nProduccion
Proveedor CodMomento
Ejecuci6nProduccion
Forma Codlngrediente
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)
METRfCA DESCRIPCION
NA(T) 7 5 5 6 5 5 7
NFK(T) 0 I 0 0 0 0 4 5
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:-;
Ratio de clm-es ajenas. ?'\llll1ero de atlibutos de la tabla de hechos que son claves
RFK(S)
I ajenas
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.
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
~a ~~~
r-----~~~~----,r------------------------~~==~~~~--------------------_J
l
NFT(Sc) Nlllnero de tab las de hechos del esquema
NSDT(Sc) Nllll1ero de tab las dimensionales compartidas por !11:)S 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
RScA(Sc)
dividido por el nllll1ero de atributos de las tablas de hechos I
!
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
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).
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.
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.
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.
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:
estado SI
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 I;\FO~\!''\ TICOS iZ R_-\-\!A
DI"\<IE7\5107\ DEH7\ICI07\
:\ccesibilidad I Los datos estan disponiblcs 0 bien son tacil y rapidamente recuperables. I
Cantidad apropiada de datos I El volumen de datos es adecuado para la tarea que se esui realizando. '
C omplecion I Los datos son complctos y suficientes para la (area que se eStil desaITollando. I
Comprenslbilidad I Los datos son tacilmentt: comprensibles
Credibilidad I Los datos pueden ser considerados como creibles y verdaderos.
Los datos estan 10 suficientementc actualizados para la (area que se esta
Disponibilidad temporal
desaITollando.
Facilidad de manipulacion Los datos son tacilmente aplicables y manipulables en diferentes tareas.
Los datos estan representados en el idioma apropiado. con una simbologia
InteIlxetabilidad
COITecta y adecuada y con la definicion apropiada.
Libres de en'or I Los datos son COITectos y liables.
ObjetiYldad Los datos son imparciales. sin prejuicios y sin connotaciones.
Releyancia 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
Reputacicin
comenidos.
EI acceso a los datos esui restringido apropiadameme para garantizar su
Seguriclad
seguridad.
\'alor aiiadido Los datos son bcndiciosos y otj'ecen wntajas alusarlos.
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.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:
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.
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).
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.
c ExistCll otros estudios ~nfocados a mejorar la calidad d~ los modelos conccptuales de datos como
Calero ct (il. (200 l) 0 Gen<.?ro (2002). Esta tesis csta oricntada al <.?studio d~ 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 Alat·cos a este campo, se
incluira un marco de evaluaci6n y mejora basado en modelos de madurez. al estilo de
CMM1.
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.
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:
<I> 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.
<I> 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.
<I> Ademas pem1ite al modelador implementar la calidad de info1111aci6n en la
fuente. Pem1ite asignar las responsabilidades de asegurar la calidad del
producto de infom1acion.
<I> 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.
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
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.
Seleccionar un proyecto piloto. pequei'io y manejable.
o Definir los problemas de negocio y medidas necesarias para resolverlos.
o Detlnir una cadena de valor y desanollar un imentario de datos.
o Desanollar una \aloracion de la calidad de la int0l111acion.
Calcular el \'alor del tiempo de vida del cliente.
o Cuantificar los costes de la no calidad en la info1111aci6n.
o Desanollar lazos de contlanza con los patrocinadores.
Deilnir los roles y la plantilla de calidad.
o Deilnir principios. procesos y objetivos de calidad de datos.
Analizar las batTeras sistemitticas.
o 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 INFO~\LA.CI6N 297
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.
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.
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 INFO~\HCI6l\' 299
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.
I.
PRI:<OCIPI
'.' ,- . ....
I I
hTEGILICIO:-;
II
YALID.\CIO:<o
II CO:<OTEXTO
II
ACTIYACIO:-;
I}
hFOlnIACIO:-; CO'IPRE:-;SIVO EXACTO
I CLARO ,IPLICABLE
~
RELEVA:-;TE
I y I I I '"
hFOR'LICIO'i CO:"\ClSA /
"" ~TE I/CORRECTO ACTCIL
"-
:0:-
-:
BLT';A
I I ~
"C.
Onnlll.·IDO
~
[
I'iFRAESTRLCTL'RA
FLIBLE
I
ACCESIBLE
I SEGrRA
I 'IA'iT['ilBLE
I R \PlD \
'"
-'.
~
~
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.
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).
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.
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 E~FORIvlACI6?\ 301
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.
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.
4.7.1. ·L11L.dU
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.
...
GEGCDI z; vv
~9
~
\;;
f--
~
g
~
Q GIR
GCI GE
FS
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.
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 INFO~vLi.TICOS &~-'\.-r.lA
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 cO!~unto 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
Se pretende que EVAMECAL 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, EVAMECAL, 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.
.\"zl!llt!roCompont!ntt's
Il~;lI1crocoll1!'ol1<!lIIcs NiveiCriticidad
j
Con estos h·es 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 INFO~YLA.TIeos © RA-:'IA
ACP I GCR-I
ACP
ACTIVtDADES ACP
GEGCDI.I. Detem1inar la composici6n I 60%
(GEGCDI) Gesti6n del Equipo de
del EGCDI.
Aseguramiento de Calidad de Datos y de 10%
GEGCDI.2. Definir un entomo
la Infonnaci6n.
operativo. 40%I
GP.!, Definici6n del PGI. 60'io
(GP)Gesti6n de Proyectos PGI. 15% GP.2. Definici6n e implementaci6n de I
un proyecto para la implantaci6n del 40°"
PGI.
30~o I
30° 0 I
GCR-' GCR-
I ACP
ACP
ACTlVlDADES ACP
:~
GPD.4. Implementacion de solueiones para la
25°0
0.
I elimiriacion de las causas de los problemas.
a GIOO.I. Creaeion de un infomle con las posibles
25° ()
<>
.2:
mejoras.
Z GIOO.2. Analisis de los datos para la mejora
~5°u
(GIOO) Gestion de la Innovacion y organizacional.
50'io
del Desarrollo de la Organizacion. GIOO.3. Disei'io de propuestas para la mejora de la
25°0
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
CAPITULO 10: CAUDAD DE LA Il\'FOR,\lACION 313
ESTADO
Ejecutado.
trabajo.
Ejecutado definidos.
No Satisfecho OS VCI -Ni'! S 90 Rango de valores para el VCI definido para el Nivel de
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.
Infonnaci6n. Satisfecho
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.
5. LECTURAS RECOMENDADAS
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
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.
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 I"FOR~!ACI6" 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'?
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.
15. Ap1ique EVA.MECAL. calculando todos los VCl. (,en que nivel de madurez esta'?
CAPITULO 11
Benjamin Franklin
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.
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 CO~OCE\lIE~TO 321
Nive! de Aplicacion
Inteligencia Sistema de Majores
Competitiva Practicas
Servicios de Gest"lon de
Servicios de Descubrimiento Servicios de Co[aboraci6n
Conoclmiento
Gestf6n de
Informacion y ruent8 de Correo
Documentos '.Neb
Conocimiento. Electrcnico
E!ectr6nicos
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
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)
Ademls. la gestlon del conocimiento implica una impOltante iI1\-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".
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 o
\~ACILITADORES CONOCIMIENTO R
\1-' -I-,f
,; I v G
A
'\/ N
I
Z
A
CONOCIMIENTO C
LOCAL I
o
N
A
L
li~TERPRET.
FACTORES
FACILITADORES
ORlE:-ITACIO:-l AL
CONOe.
LOCAL
GENERACION
CONOe.
X
I lVIEMORIA
ORGA1'ljlZ.
XX
CONOe.
X
:-IEGOCIO I
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 XX XX
:-IUEYO CO:-lOC. I
Tabla 11.2. Relaciones entre los procesos de creacion de conocimiento y los factores
facilitadores (Dyba, 2003)
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.
CULTURA
OPORTUNIDAD
DE APOYO
DE
(NIVEL ORG. E
APRENDER
INDIVIDUAL)
MOTIVACION COMPARTICION
DES EO
PARA DELCONOCIMIENTO
DE
DESCUBRIR ENINGENIERIADEL
APRENDER
CONOCIMIENTO SOFTWARE
EXPERIENCIA
PREVIA
ORGANIZACION
DE PROYECTO
DATOS
i-' PRODUCIDOS
EJECUCION I""""""
DEL PROCESO
I
Modelo de ejecucion
I
PLANIFICACION
~ EXPERIENCIA
DEL PROCESO I-
EMPAQUETADA
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.
2. Fijar objetivos.
3. Fijarareas.
6. Implementar el EBIS.
8. Mantener el EBIS.
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.
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.
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).
3.1.1.1. Definicion
3.1.1.2. Planificacion
Figura 11.5. Vision general del proceso experimental principales (WohHn et at., 2000)
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.
3.1.1.3. Operacion
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.
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.
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 ...
Baja potencia estadistica. \'iolar las suposiciones de los tests estadisticos. finalizacion y
Validez de la
ratio de error, fiabilidad de las metricas, fiabilidad 0 tratamiento de implementacion.
conclusion,
I irrele\'ancias aleatorias en eLambiente experimental.
Interpretacion pre-operacional inadecuada de los constructores. sesgo por mono-
operacion. sesgo por mono-metodo, confusion entre constructores y niveles de
Validez de
constructores. interaccion de diferentes tratamientos. interaccion de experimentacion y
constructo,
tratamientos, generalizacion restringida a traves de constructores, conjeturar hipotesis.
aprension en la evaluacion, expcctativas del experimentador.
Historia. madurez. experimentacion. instrumentacion. rcgresion estadistica. seleccion.
mortalidad. ambigiiedad sobre el senti do de la influencia causal, interaccion con la
Validez intema.
selecci6n, difusi6n de duplicados del tratamiento, igualaci6n compensatoria de los
tratamientos, rivalidad compensatoria. desmoralizaci6n resentida.
Interacci6n de la selecci6n y el tratamiento, interaccion del ambiente y el tratamiento.
Validez externa.
interacci6n de la historia y el tratamiento.
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.
Definici6n del
Contexto
Conducci6n Am31isis de la
Preparaci6n
Experimentos f---I!>/ Familia de
Experimentos
Individuales Datos
Material
Figura 11.6. Fases para el desarrollo de una Familia de Experimentos (Ciolkowski et al.,
2002)
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.
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:
Tarea Experimental
1° Experimento
Desarrollo
1
-r-
45 Estudiantes de 3' curso de
Ingenieria en Informatica
Universidad del Sannia
(Benevento, Italia)
I
2° Experimento 3° Experimento
:vlantenimiento
42 Estudiantes 3' ITIG
39 Estudiantes 3' ITIS
36 Estudiantes del Master
12 Estudiantes 5' Ingenieria
MUTS, y MUTEGS
t
Informatica
Universidad del Sannio Escuela Superior de
(Benevento, Italia) Informatica (Ciudad Real,
Espana)
I
I" Experimento
I
2° Experimento
I v
3" Experimento
(replica 2")
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.
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
REH1ERZODE REFUERZO DEL SIG~lFICACION
ROl'\DA
COl'\OCEvllENTO DE LOS CONOC!:VI1ENTO DE E:STADisnCA (,4 < 0,05)
PARES LOS SOLOS
Los datos estadisticos obtenidos a par1ir de los datos del segundo y tercer
expelimento se muestran en la tabla 11.5:
I SrGKIFIC-\CION
Pares 5°II( a)
Solos 5°II(~)
0,0309J.2
II 0.086
Pares 3°Gestion(a)
3°. Espana 0,00017 0,0009
Solos 3°Sistemas(~)
Pares 3°Gestion( a)
0.00000 0.042
Solos 3°Gestion(~)
3.1.3.3. Conclusiones
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.
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.
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).
Holistico
caso
Embebido Unidad de
anal isis 1
Unidad de
anal isis 2
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
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:
@ 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 © RA-tvL~
Ademas hay que elegir la unidad de toma de datos y la unidad de analisis, que
no deben ser confundidas, vease tabla 11.6.
,-._.-._.-.-.-.-.-._-_.-
. I
I .
I
I
I
escribir
I
realizar 1° I obtener
Informe de f-o'------'
caso de ~
I ,--t
I
conclusiones
I caso
I estudio intercasos
t ! individual
I
I 1
seleccionar
r> I modificar
casos !
I escribir teorfa
realizar 2°
desarrollar
,. ->
caso de
I-!---.
I
Informe de -> 1
teorfa caso
disefiar estudio I desarrollar
I individual implicaciones
protocolo i
L. politicas
de recogida I
I
de datos I
I
I
I
escribir
realizar I...i escribir conclusiones
:...... restantes I-----> Informe de f-o intercasos
caso de caso
estudio individual
I
1 Fu'El\"fE DERECOGlDA DE DATOS
--:-
" ", ,0 '"
CONCLUSIONES DEL
, ' , '
I
D I ,,'
I DE Ul'< L,\!)!VIDUO "
I DEu'NA
ORGANIZAOQN
ESTUDIO
I
S II ACERCADEUl'<
Comportamiento indhoidual
.Registros de archivo.
Otros comportamien- Si el caso de estudio
Actitl.ldes individl.lales
E tos. actitudes y per- es un individuo
I
Il\!)[V1DUO
N- Percepciones individuales
o' cepciones reportadas
,I
0 ACERCADE Como trabaja la organizacion Politic as de personal
Si el caso de estudio
UNA Por que trabaja la Productos de la
ORGAi'\lZAC!ON I organizacion organizacion I es una organizacion
€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 Constmcci6n de explicaciones.
€I Modelos 16gicos.
e Si se trata del infonne de un caso de eshldio que fonna parte de un eshldio mcis
amplio multimetodo.
Para que un caso de estudio sea ejemplar, debe poseer ciertas caracteristicas como:
II Ser significativo.
II Ser completo.
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>\
e Planificar la encuesta.
e Disefiar la encuesta.
e Validar el instrumento.
PRlJEB.""S
I T.kTICA.DECASO DE ESTUDIO
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).
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.
4. LECTURAS RECOMENDADAS
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 revista de la editorial
Kluwer especializada en Ingenieria del Software Empirica.
http://\\ww.kluweronline.com/issn/13 82-3256.
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
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.
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).
SC Subcomite
SCA.MPI Standard CMAll Appraisal Alethodfo!" Process IlIlpro,"elllenr
SI Sistema de Informacion
TC Technical Committee.
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.
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 INFO~'vIATICOS ©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 4·1(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 QlIali~l' (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.
BaIlOl~ 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 ~vlodel 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 (SMEF·O-l).
Bertoa. M. F. y Vallecillo. A. (2002). "Quality Anributes for COTS Components". 6th Intel'l1ational Workshop on
Qual1lilati\'e Approaches ill O~iect-Oriellted 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 Sen·ices. Serco. Ltd.: London. 10.
Disponible en: httn:.·.·www.usabilitv·.serco.com·tnl111Ddocuments.}.!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 ~Iethod for Software Quality Planning. Control.
and Evaluation". IEEE SO/l1mre 23 (2). marzoabril. pp. 69-77.
Botella. P.. X. Burgues. 1. P. Can·alIo. 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!" Srivastuv·a. R.P .. y Mak. B. (2003). "A Conceptual Framework and Belief-Ftmction Approach to
Assesing Overall Infonllation Quality". IlIIel71ational Journal o.(IlIIelligenl 5.n·lems. 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 INTOIUvlATICOS © RA-?vt.A.
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
Cah·o-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 :;Jaillle~~nce 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:I£I[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. •
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 ~!etrics 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. YGruhn. 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 Ana~\'sis 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: hnD:'w\\'\\'.oDenerouD.on!!archilectureto~af8-docarclYp4I11aturityfmat.htm (ultimo
acceso en Agosto de 2006).
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 fmprm·ement. (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.
\,' RA-?vL~ BIBLIOGR.~FiA 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 5,\~"ellls Applications (DE.'tA '93).
English. LP. (1999) flllpro\'ing Data Warehouse and Business Injimnation QualifY: Methodsfor reducing costs and
increasing Pr(jiits. Willey & Sons. 1999.
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 COl!!i:rellce on In/orlllalion
QualifY (/CIQ ·:COO]). pp.l87-196.
Eppler. M.1. (2001a). "Increasing Infommtion Quality through Knowledge ~lanagement 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= 1995 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.. .~nh-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.miLeduitdqmipapers93 ipass 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 Can·allo. 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.
~RA-MA 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.
Gendron. M. y D·Onofrio. M.J. (2002). "Formulation of a Decision Support Model Using Quality Attributes".
Proceedings of the Set'emh Co/?terence on b!{ol1nation Quality ICIQ·2003. 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 ofthe Telllh Australasian Conference on h?/ormatioll Systems .. Pp. 344-355.
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 .. YCasswelL D.L. (1987) So./hmre .I/etries: Establishing a Company- Wide Program. Prentice Hall.
37~ 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.
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.. Zowghi D.. Klemola T. y Parasuram S. (2002). "Sizing use cases: How to create a standard
metrical approach". 8th O~iect-Oriel1led 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. (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. YTIJayer. 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 (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 Technolog;~Sofnrare We cycle processes. Implementation considerations. IEEEfEIA
12207.2-1997. Institute of Electrical and Electronics Engineers. EEUU.
IEEE (2004). Gliide to the Sojilrare Engineering Body ofKnowledge. 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.
International Organization for Standarization. Ginebra, Suiza.
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.
International Organization for Standarization. Ginebra, Suiza.
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 technolog;~ Process assessmelll Part 2: Pe/fonning an
assessmelll. International Standards Organization. Ginebra. Suiza.
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 engineering~ 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 J5504-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 SISTE~lAS INfO~vL'\TICOS '~~~-MA
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).Juran·s 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 ~'Ioreno. 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 ofthe 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. ~l 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., YLinkman, 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 N°8, 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 Infl·oduction. 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 ofSystems 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.
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.
~vlissier, P. Y Batini. C (2002). DLl.A: Descriptioll a/the Gelleral Rejerellce Scellariojor All b?/imllatioll Quali£~'
Management Frallll?\\'orkjor Cooperath'e IlljomlCltion Systems. AIetodologie e Stl1lmenti per la Qualita dei Dati in Sistemi
Illjormati~'i Cooperath·i. 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
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.
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 ofthe 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 ofRetailing, 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
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.
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 I79%2C2 85 I971-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". C~iSE 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.
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 ofthe 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 (/CSE·03). 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, FESM~ 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)
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. YKumar. 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 ofReuse 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.
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
ofthe 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 ofData 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. YKing, 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
ofthe 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 ofthe 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!services·technolo!!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: !www.windlev.com·docs/eGo\"Crnment~o20e.!aturitv.pdf(ultim0
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 ofthe 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 (.·jfCCs.~ 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.
A D
G N
IDEAL 164 Q
IP-tvIAP, 291
ISO 12207, 142 QFD,38
ISO 14598,84,91 QIP, 326
ISO 15288, 142, 154
ISO 15504, 179,236
ISO 15939,234
R
ISO 19011,53
ISO 25000, 83 Registros. 14
ISO 9000,12,50,53
ISO 90003. 156
ISO 9001. 56. 59
s
ISO 9004. 53
ISO 9126. 83. 91 SCAl'v!P!. 186
SCE,161
Seis - Sigma. 67
L SERE)\:TI1PITY. 136
SMSDM.121
Lenguqje de especificacion de proceso. 109 SPADE. 130
Lenguajes de modelado de proceso. 103 Spearmint. 112
Linea de c6ciigo, 241 SPEi\1. 116
M T