Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Calidad en Sistemas Informaticos
Calidad en Sistemas Informaticos
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
Alfaomega Grupo Editor, S.A. de
c.v., Mexico
ISBN: 978-970-15-1267-8
Formato: 17 x 23 cm
Paginas: 416
c.P. 03100.
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
PROLOGO ..................................................................................................................... XVII
PREFACIO ..................................................................................................................... XIX
VIII
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
3.
4.
5.
6.
RA-ivL"'-
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
XII
h\D1CE
3.
4.
5.
6.
7.
XIII
XIV
RA-ivlA
AUTORES
X:VI
PROLOGO
*
&
PREFACIO
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 supervivenciadepel1del1 de los sistemas info1111aticos para su buen funcionamiento,
Seglll1 la nonna ISO 9000 la calidad es el "grado en el qUe un conjunto de
caracteristicas inherentes cumple con los requisitos". Como los requisitos dependenin de
las diferentes partes interesadas (stakeholders), la calidad es un concepto
multidimensional, ya que puede ser sinonimo de eficiencia, flexibilidad, cOlTeccion.
confiabilidad, facilidad de mantenimiento, portabilidad, facilidad de uso, seguridad,
integridad. etc.
xx
Ri\-tvLA.
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 capitulo 3 se exponen las aproximaciones mas importantes a la calidad, desde
la gestion de la calidad total, pasando por el modelo EFQM y hasta seis-sigma (sixsigma), dedicando una gran parte a la explicacion de las normas de la familia ISO 9000.
La parte II consta de dos capitulos, en el capitulo 4 se presenta una vision holistic a
de la calidad de los sistemas de informacion, asi como algunos de los problemas de
calidad que presentan los mismos. EI capitulo 5 explora las diferentes caracteristicas y
subcaracteristicas de calidad de un producto software asi como el proceso de evaluacion,
basandose en las principales normas intemacionales.
En el sexto capitulo, con el que inicia la parte III relativa a la cali dad de proceso
software, se discuten los principales elementos del proceso software y los lenguajes de
modelado propuestos hasta la fecha. EI capitulo 7 resume los principales modelos de
procesos de ciclo de vida, especialmente el ISO 12207, que pemliten tener una idea
general de los procesos software.
En el capitulo 8 se presenta las plincipales propuestas relativas a la evaluacion y
mejora de procesos: modelos de madurez, nonnas intemacionales, metodos de evaluacion,
etc.
La cuarta y liltima parte dellibro aborda otros aspectos de la cali dad de los sistemas
de infonnacion. Asi, en el capitulo 9 se presentan los conceptos relativos a la medicion del
software, los plincipales modelos y nom1as relacionados con la medicion, y las metricas
mas utilizadas.
En el capitulo 10 se proponen conceptos relativos a la cali dad de la infonnacion, asi
como un modelo de madurez y un metodo de evaluacion relacionados con la calidad de la
infonnacion. A continuacion, el capitulo 11 se centra en la gestion del conocinliento y su
importancia para conseguir sistemas de infonnacionde calidad.
Por ultimo, se incluye la bibliografia y los acronimos utilizados en el texto.
RA-i\lA
sus
responsabilidades
el
desalTollo
PREFACIO
4. AGRADECIMIENTOS
Queniamos expresar nuestro agradecimiento, en plimer lugar, a los alumnos de la
asignahlra Calidad de Sistemas de li!/ormacion de la Escuela Superior de Infonnatica de
Ciudad Real, asi como a los asistentes a los diferentes seminmios y conferencias que
hemos organizado sobre diferentes aspectos de la calidad de los sistemas infonnaticos en
estos liltimos quince afios. Sus sugerencias, comentmios y ctiticas nos han pennitido
depurar el material que presentamos en esta obra y planteamos que podtia resultar lltil
disponer de un libro que ayudara a la gesti6n de la calidad de los SI.
Tambien deseamos dar las gracias a D. Victor Izquierdo Loyola por haber aceptado
escribir la presentaci6n de esta obra. Tambien queremos agradecer a la empresa
Alvadalejo S.L. que se encarg6 de la filmaci6n del libro, y a la editorial RA-MA,
especialmente a don Jose Luis Ramirez, por su continuo apoyo y colaboraci6n.
Introduccion a fa Cafidad
1. Concepto de Calidad
2. Tecnicas y Herramientas de CaUdad
3. Modelos y Normas de CaUdad
CAPiTULO 1
CONCEPTO DE CALIDAD
"No me preocupa si alga es cam a barato. S610 si es buena. Y si alga es 10 sl!ficientemente bueno,
entonces el pllblico pagara par ella. "
Walt Disnel'
1. DEFINICION DE CAUDAD
La calidad se ha convertido hoy en dia en uno de los principales objetivos
estrategicos para las organizaciones debido a que, cada vez mas, su supervivencia depende
de la calidad de los productos y servicios que ponen a disposicion de los usuarios y
clientes y de la satisfaccion de estos.
Segill1 el Diccionario de la Real Academia Espanola de la Lengua (DRAE, 2006),
la calidad es (en sus cuatro primeras acepciones):
1. Propiedad 0 conjunto de propiedades inlJerentes a algo, qlle permitenjllzgar Sll
valor.
2. Buena calidad, sliperioridad 0 excelencia.
3. Caracler, genio, indole.
4. Condicion
CAUDAD DE SISTEMASIN"FOR,'vL,I"TICOS
RA-M.A.
que nos pennita conseguir que sea mejor que las otras, pero esto sera relativo, ya que
dependera del punto de vista utilizado. Por otra parte, las organizaciones deberan asegurar
los requisitos que se fijan en los contratos.
Histolicamente, los diferentes gurus de esta area han dado diversas definiciones de
calidad (Hoyer y Hoyer, 2001):
@
W.A. Shewhart: "Existen dos aspectos de la calidad EI primero tiene que vel'
con la cOl1sideracion de la calidad de IIna cosa como una realidad objetiva
independiente de la existencia del hombre, La otra tiene que vel' con 10 qlle
pensamos, sentimos 0 creemos como resllltado de la realidad objetiva. En
otras palabras hay lin [ado subjetivo de la calidad" (Shewhart, 1931).
Philip B. Crosby: "La prim era sllposicion erronea es que calidad significa
bondad, hljo, brillo 0 peso. La palabra calidad se utiliza para significar el
valor relativo de las cosas enfrases como bllena caUdad, mala calidad y
la 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
Joseph M. Jman: "La palabra calidad tiene multiple significados. Los dos
significados que dominan el uso de la palabra son: 1. La cali dad consiste en las
caracteristicas del producto que satisfacen las necesidades de los clientes y les
proporcionan por tanto satisfacci6n con el producto. 2. Calidad consiste en
ausencia de deficiencias .... Es conveniente estandarizar en una corta definici6n
la palabra calidad como adecuacion at uso". (Jman, 1988).
DE1VflNG
1. Ser constantes en el
JrlRAt'i
CROSBY
FElGEl\1JAUM
Proceso de Planificaci6n de la
Calidad (considerar las
necesidades del cliente. diseiio.
capacidad de fabricaci6n y
desarrollar los objetivos del
proceso y de la calidad).
5. Tener conciencia de la
calidad.
prop6sito de mejorar el
producto 0 servicio. con el
objetivo de llegar a ser
competitivos. de pemmnecer en
el negocio y de proporcionar
puestos de trabaio.
2. Adoptar una nueva filosofia.
Rechazar la aceptaci6n de
defectos
3. Suprimir la dependencia de
la inspecci6n para lograr la
cali dad. Eliminar la necesidad
de la inspecci6n en masa.
incorporando la cali dad dentro
del producto en primer lugar.
4. Acabar con la practica de
hacer negocios sobre la base
del precio. En vez de ello.
minimizar el costo total.
Establecer la tendencia a tener
un iinico proveedor para
cualquier articulo. con una
relaci6n a largo plazo. de
lealtad v confianza.
Proceso de Control de la
Calidad (induye control de
parametros de proceso, control
de medici6n, estandares de
desempeiio, interpretar valores
actuales vs. Estandares).
Parte del Proceso de ;VJejora de
la Calidad
(considera mejora de proceso y
de producto, productividacL
tiempos de ciclo, seguridad de
uso. entomo. reducci6n de
costes).
2. Equipo de mejora de
lacalidad.
6. Utilizar un sistenm de
acciones correctivas.
4 1. Mantener un sistema
de eliminaci6n de causas
de error.
S. Tener forrnaci6n
supervisada.
6. Instituir metodos de
formaci6n modemos en el
trabaio.
7. Dar a todos los empleados
las herrarnientas adecuadas
para hacer bien el trabaio.
8. Desechar el miedo, de
manera que cada uno pueda
trabajar con eficacia para la
ora anizaci6n.
CROSBY
FEIGE7'lBAF\I
B~! 1.
I1tlI110ricos. posters
2. \!antener equil'os de
mcjora.
13. CtiIizar consejos de
calidad.
organizncion.
BM.J. Conseguir
imp1icacion indi\'idual y de
equipo (Ia calidad es
tmbajo de todost
lQnna contmua.
Estab1eeer que Ia
calidad es un proceso que
abarca toda Ia
Proccs~)
de \kjura ('1.:
la Calidad.
de rcconocimicnto.
~.
Tencr
ronl1aci(~n
5upcl\'isada.
Parte del
Proc~so
de \!cjora dc
1a Ca1id;1d.
1. \!antener
compromisa de 1a
direccion.
3. Tener planes de
illcdici6n de la calidad.
-+. Estimar el coste de 1a
calidad.
7. Tener un progruma de
cero ddcct('ls.
.9. Lograr dias en los
qu~c sea posible
encontrar cero defectos.
1-+. I-Iacer los 13 pasos
otm \'C2.
Tabla l.1. Comparacion de Filosofias de Calidad de los Cuatro Gurus (Mouradian, 2002)
(; RA-\L-\
de Juran sobre como gestiol/ar la ca!idad"), Crosby ("14 pasos para fa ca!idad") y
Feigenbaum (,,4 principios de gestion y 10 djrectrices para fa ap!icacion de estos
prillcipios"). Cada fila ilustra la idea de cada uno con respecto al mismo critelio.
Por otro lado, en las principales n0l111aS intemacionales, la calidad se define como
"el grado en ef que UII cOlljunto de caracteristicas illherelltes clllnpfe COil los requisitos"
(ISO. 2000a), 0tra definicion interesante de calidad es la proporcionada por ISO 8402:
"Col!illl1tO de propiedades 0 caracteristicas de WI prodllcto 0 serdcio qlle Ie cOI?jieren
aptitud para satislacer 1I11ClS necesidades expresadas 0 implicitas ",
Asi se puede ver que la calidad no se trata de un concepto absoluto: el consumidor
la juzga con to do relatiyismo en un producto, En general (Piattini et al.. 2003). es posible
considerarIa como un concepto multidimensional (referida a muchas cualidades), sujeta a
restricciones (p, ej .. depende del presupuesto disponible) y ligada a compromisos
aceptables (p, ej .. plazos de entrega). Incluso. se puede considerar que no es ni total mente
subjeti\'3, (pOl'que ciertos aspectos pueden medirse) ni total mente objetiva (ya que existen
cualidades cuya evaluacion solo puede ser subjetiva). Asi pues. la calidad no es absoluta.
es multidimensional (vease la figura 1.1). Ademas la cali dad sllele ser transparente cuando
esta presente pero resulta facilmente reconocible cuando esta ausente (por ejemplo.
cuando el producto falla 0 el sel';icio es deficiente).
OPORTI..:";mAD
A este respecto merece la pena recordar las cinco "j'istas" de la calidad que sefiala
Garvin (1984):
RA,-MA
Vista del producto: que considera que la calidad esta unida a las
caracteIisticas inherentes del producto. Mientras que las vistas del usuario y
fabricante se tienen "des de fuera", la del producto es "des de dentro", ya que se
centra en la l11edida de los atIibutos internos de los productos.
Hay que tener en cuenta adel11as que la calidad puede tener varios oIigenes (vease
figura 1.2):
Calidad Necesaria
9RA-1vV\
(!)
(!)
(!)
10
constancia de una garantia de calidad que data del 429 A.c.), gIiega,
impelios en los que la estandarizacion juega tambien un importante pape!.
&>RA-MA
romana, etc.;
11
Shewhart se dedic6 a impartir una serie de cursos durante los afios 1920 aplicando
algunas de las tecnicas citadas, Joseph Juran fue uno de los asistentes a estos cursos y
posterionnente trabajaria sobre control estadistico. Por su parte, W. Edwards Deming
tambien trabaj6 con Shewhart hacia 1920 y luego en el departamento de agricultura
norteamericano en el que impuls6 la utilizaci6n del Disefio de Experimentos (DOE)
propuesto por Fisher.
Durante la Segunda GuelTa Mundial, Juran y Deming colaboraron con las fuerzas
annadas nOlteamer1canas, que hicieron un gran uso de la inspecci6n por l11uestreo,
adaptando las tab las desalTolladas en Bell System, en 10 que Juran (1995) denol11ina la
"segunda ola" del control estadistico del proceso. Al acabar la guelTa se produjo una gran
escasez de productos, por 10 cual la calidad de los pocos que quedaron descendi6
considerablemente, porque los fabr1cantes dieron pl10l1dad a la producci6n de gr'andes
VOlL1l11eneS para conseguir cuota de mercado.
Por otra parte, los japoneses despues de la Segunda GuelTa Mundial se enfrentaron.
entre on'os muchos problemas, al desafio de cambial' su reputaci6n de productos de mala
calidad. Juran (1995) sei'iala n'es contribuciones impOltantes que llevadan a modificar
notablemente esta situaci6n: los cursos de fOl111aci6n organizados porIa Ch'i!
COllllllllllicatiolls Section de las fuerzas de ocupaci6n nOlteamericana. las conferencias de
Deming sobre conn'ol estadistico de la calidad y las conferencias de Juran sobre gesti6n de
la cali dad. La industria japonesa aplicando estos principios ganada gr'andes cuotas de
mercado a nivel intemacional con productos muy competitivos.
En los ai'ios cincuenta otros dos gUrLlS tambien influyeron notablemente en la
difusi6n de las ideas sobre calidad: Anmnd Feigenbaum, que public6 el libro Total
Quality Control en 1951 y Philip B. Crosby que impuls6 impOltantes programas de
mejora de la calidad desde el Quality College.
Durante estos ai'ios se crearon en muchas empresas norteamericanas y europeas los
departamentos de calidad, cuya misi6n se cenn'aba en separar los buenos productos de los
malos al final de la secuencia de producci6n. En estas empresas, como sefiala Juran (1995)
la producci6n se lleva a cabo por departamentos .estancos, y la fonnaci6n junto con la
necesidad de dar importancia a la cali dad se limita al departamento de calidad.
En los ai'ios sesenta cuatro aspectos desafiaron la adecuaci6n de la calidad en
EEUU:
I
La revoluci6njaponesa de la calidad
12
gRA.-ivV\
13
14
RA-MA
La repetibilidad y la trazabilidad.
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.
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
RA-ivlA
4.
5.
(,Que diferencia hay entre una "acci6n correctiva" y una "correcci6n"? Ponga
ejemplos de ambas.
6.
7.
8.
9.
CAPITULO 2
TECNICAS Y HERRAMIENTAS DE
CALIDAD
*
*'7
&
"Si no lIsamos las herramientas de calidad, pronto desclibriremos 10 poco zitiles que somas para
Illlestra comunidad ala hora de Gliadir valor a las lecciones que vamos aprendiendo "
Dr. Frank K. Toda
1. INTRODUCCION
Las herramientas de calidad son tecnicas y metodos mas 0 menos justificados que
ayudan a obtener informacion para mejorar un escenario de calidad. Aunque son muchas
las c1asificaciones que se pueden encontrar, en este libro se ha optado por la propuesta por
Okes (2002) para presentar las mas importantes. Esa c1asificacion pennite agrupar las
herrarnientas en las siguientes categorias.
CiI
herramientas basicas
CiI
herramientas de gestion
CiI
herramientas de creatividad
CiI
herrarnientas estadisticas
CiI
herrarnientas de disefio
CiI
herrarnientas de medicion
18
@RA-lvlA.
alrnac.
interne
dato,
[~
2.
3.
4.
19
r
I
1. Identificar
.:.sirven para
el problema?
Dlme"'o.,, de -,- - r
Calidad
_ __
2. Identificar
Metricas para
esas
dimensiones
N~----------~
5.0btener
Conclusiones
4. Ejecutar el
Plan de
Mediciones
3. Realizar un
plan de
mediciones
20
Medidas
RA-MA
Materiales
Exactitud
Personal
Programadores
Compilador
Tiempo
Analistas
SGBDR
-ilJ;>
Fallos en los
Sistemas
Informaticos
Ratones
Sueldos
bajos
Inferencia
Impresoras
Presion
Procesamiento
Orden adores
Medio Ambiente
Metodos
Maquinas
1.
2.
3.
Identificar de 3 a 6 espinas mayores que puedan ser las causas del problema
/ efecto principal.
Identificar causas de tercer nivel para cada causa de segundo nivel, y as!
sucesivamente.
8.
s RA-ivV\
21
2.
Disei'iar una hoja de recopilacion de datos para que gum'dar datos sobre las causas
a investigar y el nlunero de veces que aparecen.
3.
4.
5.
Una vez en esta disposicion. calcular las frecuencias acumuladas para cada causa.
6.
Dibujar dos ejes verticales y un eje hOlizontal. fvIarcar el eje vertical izquierdo
con la cantidad de causas acumuladas y el derecho con una escala de 0% hasta
100%. Luego se divide el eje horizontal en un numero de intervalos igual al
l1l1mero de items clasificados.
7.
Construir un grafico de ban-as con el mism0 ancho y sin dejar espacio entt'e ellas:
este grMico esta bas ado en las cantidades y porcentajes de cada uno de los items
colocandolas de mayor a menor y de izquierda a derecha
8.
9.
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
RA.-MA
interseccion con la curva acumulada. Desde este punto trazar una linea veltical hacia el eje
horizontal. Los items comprendidos entre esta linea veltical y el eje izquierdo (de
cantidades acumuladas) constituyen las causas cuya eliminacion resuelve el 80% del
problema. Asi en el ejemplo mostrado en la figura 2.4, las causas identificadas como A, G
y F representan ese 20% de las causas que alTeglalian el 80% de los problemas.
Diagrama de Pareto
--
......
--
-=<
--
--
--
......
--
--
--
2-, .
de comprobacion
RA-ivl"'-
I)
I)
I)
2.5. Grafo
Diagrama de control
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
@RA-MA
2.
3.
4.
5.
6.
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:
@
RA-MA
340
UCL=339,5
320
3G'O
co
Q;l
L 280
c
X=275
Q,I
i5.
E
co 260
(I)
240
220
LQ=210,5
200
,
2
,
6
10
,
12 14
Sample
,
16
i8
20
22
24
Gr6fico It de Fallos de
Sistema de Informacion
200
R=88,5
o
2:
,
4
10
12 14
Sample
16
18
20
,
22
lCL=:O
24
25
26
RA-ivlA.
UCL=33'i/5
2M~-.
__- ,__- ,__- ,__- ,__- ,__- ,__- , , -__, , - - , , -__. -__. - . J
10
1;2
14
1$
1S
lCL=21O,5
20
sample
200
1-========================,
\
/1',
UCL=ZCJZ,O
v--J+-<\,
/
/~ ~/~\J\
/
'-J
/
---"
L:::::;::=::;:=:::;::=:::;::=:::;::=:::;::==;:===;:===;:===;:===;===;=-.J L~L=O
8
10
12
14
5ample
16
18
20
22
2+
27
lJCL=O,7397
0,6
::: 0,5
o
:;::
13
0,4
Q.
is: 0,3
P=0,2692
0,2
0,1
0,0
lCL=O
,
2
10
12
14
18
8<3mple
Tests perfbrmed with unequal sample sizes
b.
28
d.
RA-MA
22,5
UCL=21,99
20,0
17,5
15,0
CJ
III
"E. 12,5
E
01
10,0
V~
(~
: : Alr' ,''m,.
\
'aT\
ffi
ill
LCL=5,61
Sample
Figura 2.10. Diagrama de Control por Atributos tipo np (generado con Minitab)
2.6. Histograma
EI histograma 0 diagrama de distribucion de Jrecuencias es una representaci6n
gnifica por medio de barras verticales, que ilustra la frecuencia con la que ocurren eventos
relacionados entre sf. Se trata de un instrumento de sintesis muy potente que permite
apreciar la tendencia de un fen6meno.
El histograma puede ser usado para:
CD
CD
CD
CD
GRA-MA
29
UCL=1l,96
10
LCL=O
10
12
Sample
14
15
18
20
de Correlaci6n
30
RA.-IvL>\
120
iOJ -
5J
20
i70
168
iSJ
208
210
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
iii
iii
iii
3. HERRAMIENTAS DE GESTION
3.1. Diagrama de afinidad
Los diagramas de afinidad sil"Ven para organizar un gran nlunero de ideas en
categorias relacionadas, 0 afines (Tague 2005). Fue creado por Kawakita en los atlOS
sesenta.
Las ideas suelen venir de sesiones de trabajo 0 de sesiones de Tonnentas de Ideas.
31
2.
3.
Q 0
0 0 C
No
Correlacion
0 C 0
0
0
0 0
0
0
00 0
Correlacion
Negativa
x
0
y
o
0
0
00
0
Correlacion
Positiva
o c
o
0 0
o
0
0 0
;::" 0
00
00 0
00
0 0
0 0
00
0 0
o 0
00
c (;
0
0
0
0
C 0
00 C
Correlacion
Compleja
Correlacion
Fuertemente
Positiva
32
RA-lvL~
2.
3.
Estudiar la relaci6n entre esta primera causa y el resto de las causas, sefialando
con flechas las relaciones que vayan surgiendo. Es posible que haya diferentes
niveles de relaci6n.
4.
5.
matricial
Al igual que ohas henamientas de las citadas hasta ahora, pennite representar
grafical11ente la relaci6n existente entre varios factores. Para ella hay que colocar los
factores sobre las filas y colunmas de una l11atliz. Si existe relaci6n, se l11arca en la
intersecci6n de los factores. Es posible indicar el grado 0 intensidad de la relaci6n
existente. Se suele utilizar para definir la relaci6n enhe los distintos factores que
intervienen directa 0 indirectal11ente en un proceso de mejora de calidad. La figura 2.15
representa un ejemplo de diagrama mahicial.
VLOCIDAD
SGGRIDAD
-4
I
I
I
I
I
I
VEWCIDAD
... ~
SGI3RIDAD
-:c- COl'TNIDOS
..
.. .COi'iiE:'<IDOS
s RA-ivL\
33
de flechas
34
@RA.-MA
2.
Para cada tarea del tercer nivel identificar que es 10 que podria salir mal.
3.
Revisar todas las listas de problemas potenciales y eliminar aquellos que sean
improbables 0 cuyas consecuencias pudieran llegar a ser poco significativas. Los
problemas resultantes poddan mosharse como un cuarto nivel.
4.
5.
Esrudia la viabilidad de cada plan de contingencia, marcando con una "X" los
impracticables y con una "0" los que Sl poddan llegarse a dar.
4. HERRAMIENTAS DE CREATIVIDAD
Aunque existen herramientas de creatividad como los mapas concephtales, el usa
de analoglas, etc. aqui se presentani solo la tonl1enta de ideas como la mas utilizada.
Es una herramienta de trabajo en grupo basada en la creatividad de los
componentes del grupo de trabajo. Se pretende obtener el mayor numero de ideas 0
soluciones en el menor tiempo posible, seleccionando poste1101111ente las mas indicadas,
es decir, aquellas que mejor se adaptan a los objetivos del problema. Para ella es necesar10
que el equipo de trabajo conozca dichos objetivos. Existen dos modos de realizacion de
esta tecnica:
EI
EI
35
Seleccion de ideas. Cuando ya no haya mas ideas, todos los miembros deben
seleccionar aquellas dimensiones que mejor se adapten al objetivo de la
medici6n, descartando las peores.
5. HERRAMIENTAS ESTADisTICAS
5.1. Control estadistico del proceso
Se entiende por capacidad de un proceso el grado de aptitud que tiene para cumplir
con las especificaciones tecnicas deseadas. Cuando la capacidad de un proceso es alta, se
dice que es capaz. Cuando se mantiene estable a 10 largo del tiempo se dice que esta bajo
control. Para determinar si un proceso es 0 no capaz, se pueden utilizar las siguientes
herTamientas:
e
Histogramas
Graficos de Control
Graficos de Probabilidad
Respecto a su posici6n:
a.
b.
c.
d.
b.
36
RA-MA
CORToPL4Z0 '
(h"i"IRAGRl1J>O)
LARwPtAZO
(h'i-m.-\GRD'.PO E,'
h"{lERGRllPO
PPU
PPL
P p,
C PK Y PPK
= LS-LI
CPK
6u
= A1in{
LS - j.J j.J - LI
,
}
3u
3u
Para afinnar que un proceso es capaz Cp y/o CPK deben ser mayor 0 igual que 1.33,
que garantiza que el 99.994% de los productos fabricados 0 servicios prestados por el
proceso centrado esta dentro de las especificaciones.
10
En caso de ser necesario estudiar los dos, ambos deben valer como minima 1.33.
En otro caso, habra que aplicar acciones con'ectoras.
Estudio de Capacidad del Proceso
" Deteccion de fall os en el Sistema de Informacion"
L5l
Prv-:~ss
LSL
USl
D.a:t;a;
1775;C1Cll)OCI
--Within
""-=::tl)
S;rtlp.!~
StD.;:vi)\IHhirl)
StD.;v(O'~\:r~!f)
Over311
1825.JIOOOO
5"rnpl-=
18(t2)~S 149
1:;
293308:9
28 .. 15313
Cp
0;23
CPL
0,32
CPLI
QJ;;;:
<::pl;
0,2r.
CC?~~
(j:2~:
Overall Ca~'!!biSty
Pp
0,31)
PPl
0,3?
PPU
02~
P~k
0,2;
Cpm
*"
E~p,
p~r"'1
PPM
PPf,'
V'!ithin P.;tr';;-liIun,:.;;:
::; LSL 1710$0;;:2
:= U~!..
Tot~1
2::S1S'~J'Je:
3':129,90
QRA.-MA
37
CPU = L530-
CPL
= jl-LI
30-
2.
3.
4.
5.
6.
7.
8.
9.
38
6. HERRAMIENTAS DE DISENO
6.1. QFD (Quality Function Deployment)
El Diagrama de Despliegue de la Funci6n de Calidad (Quality Function
Deployment) es una tecnica utilizada para planificar nuevos productos y servicios 0
realizar mejoras en los existentes a partir de metodos mauiciales, cuyo objetivo es que los
requisitos del c1iente lleguen a estar completamente contenidos en las espcificaciones
tecnicas del producto 0 servicio. La principal ventaja de esta tecnica es la reducci6n del
tiempo del disefio y la disminuci6n de los costes, manteniendo y mejorando la calidad.
Para realizar un proyecto usando QFD se deberian seguir estos pasos (Carretero et
al., 1999):
1.
2.
3.
donde se relacionan las necesidaaes del c1iente con las caracteristicas del
producto 0 servicio a disefiar.
b.
c.
RA.-ivlA
d.
39
2.
3.
4.
7.
8.
9.
40
RA-MA
~
CARACTERisTICAS DEL
PRODUCTO
La voz dellngeniero
w
w
I-
::i
>
..J,s
"Ill
~~
we
c.Sl
inO
enu
wZO
_
N
0'"
MATRIZ DE RELACIONES
>
..,
0:3:
oS:
3>
"t:I"
"';>;
Clz
~Gl
u::..J
(j
W
"en
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:
41
Causa de Falla: hay que describir las anomalias de las que se tiene
sospecha que han podido producir el faUo: variaciones en los parametros
de manipulacion optima, deficiencias en el diseno del producto, servicio
o proceso, deficiencia en los materiales usados, uso indebido por parte
del cliente, etc.
Indice de Prioridad de Riesgo (JPR): mide cuales son los fallos cuyas
probabilidad de riesgo es mayor. Esto pennite identificar los fallos en los
que se deben concentrar principalmente la atencion para empezar a
aplicar ah! las acciones correctoras oportunas. Se obtiene calculando el
producto de los tres indices anteriores: IPR= FG-D.
42
RA-ivLA.
Responsabilidad y plazo: sirve para anotar la persona 0 area que se hara cargo
de la ejecucion de las acciones conectoras indicadas anterionnente en los
plazos previstos.
2.
3.
4.
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
43
7. HERRAMIENTAS DE MEDICION
7.1. COQ (coste de la caUdad)
Tambien llamado Analisis de Costes de Pobre Calidad, el COQ es un proceso
uti liz ado para identificar problemas potenciales, y cuantificar los costes en los que habria
que incurrir por no hacer las cosas bien desde el plincipio.
Para realizar un analisis COQ se recomienda seguir estos pasos:
I.
2.
Identificar todas las fases y actividades del proceso y marcar aquellas que
inculTan en costes de calidad: inspecci6n, reparaci6n y control de danos.
Cuestionarse las razones de que haya tanto muchas como pocas actividades
marcadas que inClllTan en costes de cali dad.
3.
Para cada actividad marcada estimar el coste que puede implicar los fallos
procedentes de una deficiente calidad y el coste que puede suponer implementar
acciones bien cOlTectoras, bien preventivas para elTadicar/evitar esos problemas.
4.
5.
7.2. Benchmarking
Tague (2005) define benchmarking como un proceso estructurado que pennite
comparar las mejores practicas de las organizaciones, de manera que se pueden incorporar
aquellas que no se desalTollan 0 mejorar las que se desalTollan a la propia organizaci6n, 0
a los procesos de la organizaci6n.
Las fases para desalTollar un benchmarking es el siguiente:
1.
Planificar:
a.
Definir los objetivos del estudio. Hay que elegir aquellos que sean
criticos para el exito organizacional.
b.
44
.:g RA-ivlA
c.
d.
2. Recopilar Datos:
a.
3.
i\nalizar:
4.
a.
b.
c.
DetenniI1ar las diferencias en las pnicticas que provo can dichas brechas.
Adaptar:
a.
b.
c.
7.3. Encuestas
Estan destinadas a detenninar la naturaleza de los procesos. Existen dos
modalidades:
e
conocimiento
intenogan
45
8. NIVELES DE MADUREZ
Varios autores han sefialado que las organizaciones pueden presentar diferentes
niveles en la gesti6n de la calidad. Asi, por ejemplo, Crosby (1979) distingue los
siguientes cinco niveles:
II
II
II
II
II
Bajo
Medio
Alto
.J
..... ' . \
DES<;,RIPClo.'\i.
... "
to';.,>;
TT~
C'.
"".;.;:n.,: c";
Auditorias
Coste de Cali dad
Control Estadistico de Proceso
Encuestas clientes
FMEA! Dis. Exp.
Benchmarking
Herramientas de gestion
Encuestas a empleados
QFD
46
RA-MA
Las helTamientas que una organizaci6n puede utilizar varianin seglin el nivel de
madurez de calidad que presente. Okes (2002) presenta la propuesta que se refleja en la
tabla 2.2.
Ademas, se puede encontrar un cierto orden de prelaci6n a la hora de utilizar las
helTamientas, por ejemplo: SPC se tiene que utilizar antes que DOE, ya que un proceso
debe estar en condici6n estable antes de estudiarlo; COQ se utiliza antes que el
benchmarking, ya que COQ utiliza datos internos, mientras que benchmarking utiliza
datos externos.
9. LECTURAS RECOMENDADAS
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.
http://www.qfdi.org Se trata de la web del QFD Institute que reline una amplia
cantidad de material sobre QFD.
11. EJERCICIOS
l.
G R.A.-MA
47
2.
3.
Preparar un cuestionario que inc1uya los datos necesarios para llevar a cabo un
estudio sobre los defectos de los datos en una base de datos atendiendo a tres
variables distintas: exactitud de los datos, fiabilidad de la fuente que los
proporciona y precisi6n de los datos.
4.
5.
6.
7.
CAPiTULO 3
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 SeisSigma.
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.
50
~RA-tvL"-
Shewhart, y popularizado luego por W. Edwards Deming, por 10 que se conoce "Cicio de
Deming":
e
II
Implicaci6n y enriquecirniento
("empOlvennent")
del
puesto
de
Reconocirniento y celebraci6n
II
trabajo
del
personal
51
tecnicas en los diferentes campos de la industria. Pueden ser miembros de ISO todos
aquellos paises del mundo que 10 deseen, representados a traves de su organismo nacional
de nonnalizaci6n (vease la figura 3.1): pOl' ejemplo, ANSI (American National Standards
Institute) por EEUU 0 AENOR (Asociaci6n Espanola de Nonnalizaci6n y Certificaci6n)
por Espana.
EEUU
ANSI
FRANCIA
AFNOR
ESPANA
GRAN BRETANA
JTCI
SC27
52
2
4
6
7
9
10
12
19
20
21
22
?'
-.)
24
I
I
I
..
....
>
y>
....
RA-l'vL-\
'-.- ..
i\~~o
.. ..",I x
.>?G .
..... . .....
.
. \ ......
"
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.
publican
las
53
nonnas
(i)
(i)
(i)
Ademas, existen otras nonnas relacionadas con 1a familia de las nonnas ISO 9000.
que se reflejan en la tabla 3.2.
54
RA-MA
9004
Ventaja competitiva
Excelencia en
eI desempeiio
MINThlIZAR usn
DERECURSOS
Eficiencia
Eficacia
I .....
ISO 10002
ISO 10005
ISO 10006
ISO 10007
ISO 10012
ISO!TR 10013
ISO:TR 10014
ISO 10015
ISO!TR 1001 7
ISO 10019
OBJETIVO
..
12 RA-IvlA
55
56
RA-:tvL,,-
informacion
+----
RESPONSABILlD,AD
DE LA DIRECCION
GESTION DE
RECURSOS
MEDICION. ANALISIS
Y MEJORA
N
T
r--R-E-AL-IZA--C-I-O-N-'
b'u
..
C
L
-info
DELPRODUCTO
requisitos
E
N
T
E
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,
PORTADA
ANTECEDENTES
DECLARACION
PROLOGO
PROLOGO DE LA VERSION EN ESPANOL
o INTRODUCCION
1 OBJETO Y CAMPO DE APLICACION
2 NORMAS PARA CONSULTA
3 TERMINOS Y DEFINICIONES
4 SISTEMA DE GESTION DE LA CALI DAD
5 RESPONSABILIDAD DE LA DIRECCION
6 GESTION DE LOS RECURSOS
7 REALIZACION DEL PRODUCTO
8 MEDICION, ANALISIS Y MEJORA
ANEXO A (Informativo) CORRESPONDENCIA ENTRE LAS NORMAS
ISO 9001:2000 E ISO 14001:1996
ANEXO B (Informativo) CORRESPONDENCIA ENTRE LAS NORMAS
ISO 9001:2000 E ISO 9001:1994
BIBLIOGRAFiA
ANEXO ZA
(Normativo)
REFERENCIAS
NORMATIVAS A
PUBLICACIONES
INTERNACIONALES
CON
SUS
CORRESPONDIENTES PUBLICACIONES EUROPEAS
Figura 3.4. Contenido de la norma ISO 9001 (ISO, 2000b)
57
58
RA-NL-\
.\': R/\.-ivL"-
59
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",
Ademas, la organizaci6n debe revisar los requisitos relacionados con el producto, y
detenninar e implementar disposiciones eficaces para la comunicaci6n con los clientes,
60
RA-ivIA
3.3.4.4. Compras
En cuanto al proceso de compras la nonna establece que: "La organizacion debe
asegurarse de que el prodllcto adqllirido eumple los requisitos de compra especijicados.
EI tipo y alcance del control aplicado al proveedor y al producto adquirido debe
depender del impacto del produeto adquirido en la posterior realizacion del producto 0
sobre el producto final n.
Ademas, la nonna establece que "la organizacion debe eva/uar y seleccionar los
proveedores en fill1cion de su capacidad para suministrar productos de aeuerdo con los
requisitos de la organizacion" y que "la organizacion debe establecer e implementar la
inspeccion u on'as actividades necesarias para asegurarse de que ef producto comp'ado
cumple los requisitos de compra especijicados n.
0RA.-MA
61
62
RA-ivlA.
la calidad y para evaluar donde puede realizarse la mejora continua de la eficacia del
sistema de gestion de la calidad".
POI' ultimo en la nOl1l1a se aborda la mejora, tanto la mejora continua, como las
acciones cOlTectivas y preventivas. En estos temas se profundizan en la nonna ISO 9004,
que propugna un enfoque de auto-evaluacion para evaluar la madurez del sistema de
gestion de la calidad para cada apartado de la nonna en una escala que flucrua de 1 (sin un
sistema fOl1l1al) hasta 5 (la mejor clase de desempefio), vease la tabla 3.3.
4. MODELO EFQM
4.1. Vision general
El modelo EFQM, que fue creado como marco para evaluar las organizaciones con
el fin de conceder el European Quality A.-ward, se puede utilizar como:
I>
I>
I>
I>
I>
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 ".
El modelo EFQM se basa en una serie de principios:
I>
I>
Orientaci6n al c1iente
I>
I>
RA-lvLA.
DesarTollo de alianzas
Responsabilidad social
"
liderazgo
(10%)
Resultados en
Personas
uj
63
"
(9%)
y
Estragegia
(8%)
"vV~V
v)
Procesos
(10%)
Alianza y
las Personas
en
los Clientes
Resultados
Clave de
Desempeiio
(10%)
en
la Sociedad
(6%)
Recursos
(9%)
4.2.1. LIDERAZGO
Los subcriterios para los lideres excelentes se basan en que estos:
e
64
RA-MA
<
Aproximaci6n reactiva
clase"
",',
"
Orientacion\.
"
(benclllllOrkim;)
4.2.3. PERSONAS
En este cliterio se evallmn:
o
idRA-MA.
65
Gestion de la tecnologia.
4.2.5. PROCESOS
En cuanto a los procesos se evalua:
66
@RA-MA
4.2.6. CLIENTES
Las organizaciones excelentes miden de manera exhaustiva y a1cat1Zan resultados
sobresalientes con respecto a sus clientes, por 10 que el modelo establece dos subcriterios
basados en medidas de percepci6n y en indicadores de rendimiento
2.
Servir como helTamienta para los administradores Pllblicos que de seen mejorar el
rendimiento de su organizaci6n.
3.
4.
EI CAF se considera un modelo "ligero", adecuado para obtener una primera valoraci6n 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\
6.
67
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.
68
RA-MA
7. PREMIOS
Existen multitud de prellllos relacionados con la calidad, a continuacion
presentamos los mas irnportantes:
II
II
II
II
~RA-rvL\
69
-(
2. Planlficacion
Estrategica
"""
5.
~~==:)
Recursos
Humanos
.i
. /
/.----!!-~
~ 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
RA-MA
8. LECTURAS RECOMENDADAS
e
Cl
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.
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.
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.
2.
3.
Encuentre los diferentes prelnios a la calidad que se cone eden en su pais 0 paises
del entomo y compare los clitelios de estos premios respecto a los del Malcom
Baldlige National Quality Award y a los delmodelo EFQM. Sugerencia: acceda
a http://andes.fundibeq.org/redibexlpremios.html.
4.
CaUdad de
Sistemas In(ormaticos
C.<\PITULO 4
CALIDAD DE SISTEMAS DE
INFORMACION
"La calidad de fa vida esta detenninada por SllS actividades"
Arist6tefes
1. SITUACION DE LA CAUDAD DE SI
Desde hace varios anos se viene insistiendo en la "crisis" de la Ingenieria del
Software y en los desastres que los fallos de software pueden llegar a causar en las
organizaciones.
A este respecto cabe destacar los infonnes "CHAOS" del Standish Group que
peri6dicamente "fotografian" la situaci6n del sector. En el ultimo infonne (Standish,
2001), se senala que s6lo el 28% de los proyectos infonnMicos finalizan en el tiempo
estimado, con los recursos planificados y con una ca4.idad aceptable, mientras que casi una
cuarta parte no llegan a finalizar nunca. El resto 10 hace pero consumiendo muchos m<ls
recursos 0 con menos funcionalidades de las previstas (vease figura 4.1). A pesar de ella
debemos congratulamos ya que se ha pasado del 16% en 1994 a128% en el ano 2000, 10
que indica que se va progresando en este sentido.
En NIST (2002) se repasan las perdidas econonucas (de varios centenares de
millones de d6lares) y en vidas humanas debido a los fallos del software en diferentes
sectores como, por ejemplo, el aeroespacial (desastres como los del Ariane 5, las sondas
de la misi6n a Marte, algunos aviones comerciales, etc.).
Recientemente, Jorgensen y Molokken-Ostvold (2006) revisan la estimaci6n de un
189% de retraso en la entrega para los proyectos infonnMicos que senalaba el infonne
76
RA.-ivL\
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.
.~
RA-ivLA.
77
c
o
N
S
U
M
I
D
o
R
;\1
U
C
H
0
S
0
C
0
S
Time
to
Market
CaUdad
Capacidad
Coste
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.
En Wilkin y Castleman (2003) se describe un instrumento multidimensional
(denominado QUALIT) capaz de medir la calidad de los sistemas de infol1naci6n
entregados, en el que se diferencia entre la calidad del sistema (entendida como juicio
global sobre el grado en que los componentes tecnicos del mismo proporcionan la calidad
78
RA-MA
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
I)
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)
I)
Glass, R.L. (2003), Facts and Fallacies of Software Engineering. AddisonWesley, 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.
Evans, I. (2004). Achieving Software Quality through Teamwork. Artech
House, Boston. En este libro podemos encontrar algunas claves sobre la
"calidad del personal", ya que su autora proporciona una visi6n general de la
cultura de equipo necesaria para desalTollar software de calidad.
II
6. EJERCICIOS
1. Analice en que cuadrante del marco propuesto pOl' Card (1995) se situadan las
siguientes tecnicas:
a.
b.
Orientaci6n a objetos
c.
HelTamientas CASE
d.
Metodos agiles
80
RA-tvL'\.
2.
3.
4.
CAPITVL05
1. MODElOS CLAslCOS
Historicamente se han desarrollado para evaluar la calidad de los productos
software diferentes modelos que pretenden seguir las directrices de cali dad de otros tipos
de productos: descomponer la calidad en una categoria de caracteristicas mas sencillas que
facilita su estudio (Galin, 2004).
Uno de los modelos clasicos mas utilizados desde su creacion, incluso con vigencia
en nuestros dias, es el desarrollado por McCall (McCall et al., 1977), en el que la calidad
de un producto software se descompone en once caracteristicas 0 factores de calidad
agrupados en tres categorias (vease figura 5.1): Operacion de producto, Revision de
producto y transicion de producto.
A finales de los afios ochenta, fueron propuestos dos modelos altemativos a los de
McCall basados igualmente en la identificacion de factores: el modelo de factores de
Evans y Marciniak (1987) y el modelo de factores de Deutsch y Willis (1988).
En la tabla 5.1 puede encontrarse una comparativa entre los distintos modelos
donde se muestran los factores observados por cada uno de los autores en sus
correspondientes trabajos.
Otro modelo considerado como clasico es el reconocido como FURPS, acronimo
compuesto por las iniciales en ingles de las categorias Funcionalidad, Facilidad de uso,
Fiabilidad, Rendimiento y Capacidad del software; esta lista es una de las muchas
82
RA-MA
Vision de usuario
Operacion d
producto
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
Facilidad de uso~cr:;m~~I~~~1on
Seguridad (integrida
Comunicatividad
Volumen y tasa de ElS
Datos comunes
Eficiencia
Fiabilidad
~~:~~~~i~li!!
Transicion d~ Capacidad de
producto
reutilizacion
Complecion
Trazabilidad
Consistencia
Precision
Tolerancia a errores
Concision
Autodescriptividad
Simplicidad
Modularidad
Instrumentacion
Capacidad de ampliacion
Transportabilidat!7'"::::7C:::::::::=::~~~~ Generalidad
I
Indep. maquina
Interoperabilida'lf'----------- ~~;!;jn~g:c.~eo~~t;~a
l\:h:RCINIAl(
. . (1981)
MCCALL (1916)
..
Correccion
Fiabilidad
Eficiencia
Integridad
Usabilidad
Mantenibilidad
Flexibilidad
Testeabilidad
Portabilidad
Reusabilidad
Interoperabilidad
Verificabilidad
Expandibilidad
Seguridad de Uso
Manejabilidad
Capacidad de supervivencia
./
..
I. DHJISCHyWILLrs(1988)
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
./
I
I
./
./
./
./
Tabla 5.1. Comparacion entre modelos de calidad de producto software (Galin, 2004)
f:RA-MA.
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.
:
Requisitos de
Calidad
2503n
;~l;;t;?
Evaluaci6n de
Calidad
2504n
Medici6n de Calidad
2502n
t;~~?;~'hi/';;(y':1?#J!z '%'
'.i&4~
84
RA.-ivLA.
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
del usuario
+----------
Uso y
retroalimentaci6n
t
Indica
Contribuye a especificar
~
Requisitos de
caUdad externa
I
+-----------~
Calidad
extern a
Validaci6n
I
Contribuye a especificar
Indica
~
Requisitos de
caUdad interna
.
+-----------~
CaUdad
interna
Verificaci6n
Q RA-tvL-\
85
Calidad externa e
interna
Adecuaci6n
Exactitud
Interoperabilidad
Seguridad de
aeceSD
Cumphmiento de
la funclonalidad
rv1adurez
Tolerancla a rallos
Capacidad de
recuperac16n
Cump!imiento de
la fiabiHdad
Capacidad de ser
entendldo
Capacidad de ser
aprendldo
Capacidad de ser
operado
Capecidad de
atraccion
Cumplimiento de
la usabilidad
Comportamiento
temporal
Utilizacion de
recursos
Cumplimiento de
la eficiencia
Capacidad de ser
analizado
Capacidad de ser
cambiado
Capacidad de ser
probado
Cump!imiento de
la mantenibi!idad
Adaptabilidad
Instalabilidact
Coexistencia
Capacidad de ser
reemplazado
Cumplimiento de
Ja portabilidad
2.2.1. FUNCIONALIDAD
Capacidad del producto software para proporcionar funciones que satisfacen
necesidades declaradas e implicitas cuando se usa bajo condiciones especificadas. Ista
caracteristica se subdivide a su vez en:
o
86
iii
iii
iii
iii
RA-MA
2.2.2. FIABILIDAD
Capacidad del producto software para mantener un nivel especificado de
prestaciones cuando se usa bajo condiciones especificadas. Esta caracteristica se subdivide
a su vez en:
iii
iii
iii
Madurez. Capacidad del producto software para evitar fallar como resultado
de fallos en el software.
Tolerancia a fallos. Capacidad del software para mantener un nivel
especificado de prestaciones en caso de fallos software 0 de infringir sus
interfaces especificados.
Capacidad de recuperacion. Capacidad del producto software para
reestablecer un nivel de prestaciones especificado y de recuperar los datos
directamente afectados en caso de fallo.
Cumplimiento de la fiabilidad. Capacidad del producto software para
adherirse a normas, convenciones 0 regulaciones relacionadas con la fiabilidad.
2.2.3. USABILIDAD
Capacidad del producto software para ser entendido, aprendido, usado y ser
atractivo para el usuario, cuando se usa bajo condiciones especificadas. Esta caracteristica
se subdivide a su vez en:
Capacidad para ser entendido. Capacidad del producto software que permite
al usuario entender si el software es adecuado y como puede ser usado para
unas tareas 0 condiciones de uso particulares.
Capacidad para ser aprendido. Capacidad del producto software que perrnite
al usuario aprender sobre su aplicacion.
lRA-MA
87
Capacidad para ser operado. Capacidad del producto software que pennite
al usuario operarlo y controlarlo.
2.2.4. EFICIENCIA
Capacidad del producto software para proporcionar prestaciones apropiadas,
relativas a la cantidad de recursos usados, bajo condiciones determinadas. Esta
caracteristica se subdivide a su vez en:
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 cambiado. Capacidad del producto software que pennite
que una detenninada modificaci6n sea implementada.
Capacidad para ser probado. Capacidad del producto software que pennite
que el software modificado sea validado.
88
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
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
89
Calidad de Uso
2.3.4. SATISFACCION
Capacidad del producto software para satisfacer a los usuarios en un contexto de
uso especificado.
90
RA-MA
Tomar medidas
Valorar Resultados
niyel
PlaneadO~
val~~
medido -=-
Rango objetiyo
niyel actua~
-
satistbctorio
Minimanii!nte aceptabt~
el casu peo,--
insatistbctorio
lnaceptabt~
escala de nii!dicion
niveles de puntuaciOn
<:: RA.-MA
91
O.
1.
2.
3.
4.
5.
6.
Definir el dominio
Detenninar subcaracteristicas de calidad
Definir unajerarquia de subcaracteristicas
Descomponer subcaracteristicas en atIibutos
Descomponer atIibutos derivados (aquellos que no sean medibles
directamente) en atIibutos basicos
Establecer relaciones entI'e entidades de calidad (por ejemplo, aumentar
la subcaracteristica de seguridad lleva consigo que aumente la madurez
de un producto)
Detenninar metIicas para los atIibutos.
92
RA-l\IA
Paso 1
Paso 3
Paso 4
Paso 5
Establecer Relaciones
entre entidades de calidad
Paso 6
Datarminar ivletricas
para los atributos
4. LECTURAS RECOMENDADAS
http://v{v{w.sei.cmu.edulsemaipresentations/zubrow/esepg/ Presentacion
Sofnvare Engineering Institllte sobre IS.O 25000 Y el modelo CMMI.
del
6. EJERCICIOS
1.
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,.
93
Tomando como base el proceso de selecci6n propuesto por la nonna ISO 14598,
defina un proceso de selecci6n para henamientas de amllisis y diseiio Olientado a
objetos, adaptando si fuera necesario el modelo de calidad de la ISO 9126.
Compare elmodelo definido con la nonna ISO 14102 (ISO, 1995).
4.
5.
6.
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.
6. EI Proceso Software
7. Modelos de Proceso de CicIo de Vida
8. Evaluacion y Mejora de Procesos
CAPiTULO 6
EL PROCESO SOFTWARE
"Los Procesos Software tall/bien son Software"
Leon Osten veil
1. INTRODUCCION
Tradicionalmente la Ingenieria del Software se ha centrado en metodologias y
lenguajes de programacion, modelos de desalTollo y helTamientas. Sin embargo, y
teniendo en cuenta la creciente complejidad de los sistemas, se hacia necesario incluir
detenninadas areas que hoy en dia son criticas para la ingenieria del software, como las
infraestructuras de gestion y organizacion, por 10 que surge la denominada ingenieria del
software basada en el proceso (Wang y King, 2000).
Tal como se destaca en numerosos estudios, actualmente la calidad de cualquier
producto no puede ser asegurada simplemente inspeccionando el producto por sl mismo 0
desalTollando controles de calidad estadisticos. Esta 'l.finnacion se basa en que existe una
cOlTelacion directa entre la calidad del proceso y la calidad del producto obtenido
(Fuggeta, 2000) y en consecuencia, una organizacion no puede garantizar la entrega de
productos de calidad centrando sus programas de calidad unicamente en el producto
(Satpathy y Harrison, 2002).
Durante las tres ultimas decadas, el estudio de los procesos de produccion de
software ha llevado al desalTollo de varios ciclos de vida en la ingenieria del software
como, por ejemplo, los modelos cascada, evolutivo y en espiral (Piattini et 01., 2003).
Estos modelos del ciclo de vida ayudan a los ingenieros y a los gestores a comprender
mejor el proceso software, y a detenninar el orden de las actividades necesarias en la vida
de un producto software.
98
EI
EI
EI
EI
El proceso software es un proceso con una natmaleza especial, detenninada por las
siguientes caracteristicas (Demiame et al., 1999):
- EI
Es complejo.
kRA.-MA
99
II
100
R.-\-MA
t RA-iviA
10 1
Mejorar el
Proceso
Controlar el
Proceso
102
RA-ivl-\
II)
9RA.-MA
l03
<>
<>
<>
104
RA-MA
Herramienta
Actividad
Producto
Recurso
Organizacion
105
106
C9 RA-ivLi\
PERsPEcnvAS DE L'iFORMACION
Funcional
Comportamental
Infonnativa
Funcional
Organizacional
Infonnativa
Funcional
Comportal11ental
COl11portal11ental
Funcional
Comportamental
Organizaciona1
Funciona1
Infolmativo
Omanizacional. Infonnativo
COl11portal11ental
Compoliamental. Organizacional
I Es un modele explicito de los constmctores y reglas necesarias para constuir modelos especificos de
un detenninado dominio de interes.
(': RA-MA
107
precisa para su posterior ejecuci6n efectiva. En funci6n de los aspectos del proceso a
representar sera necesario incluir unos constructores u ohos y por ella en la literatura se
puede enconhar una gran diversidad de lenguajes para el model ado de los procesos
software. Ello supone la existencia de diversos fOl1nalismos para modelar los procesos
existiendo un alto grade de heterogeneidad. A continuaci6n se describen de f0l111a general
diferentes propuestas de modelado de procesos.
DIAGRAMAS PERT
Los diagramas de Gantt fueron creados por Hemy Gantt en el aii.o 1917.
Representan las diferentes actividades de un proceso como banas sobre un calendatio
aportando una representaci6n visual de las actividades, su duraci6n y su planificaci6n. En
la figura 6.3 se presenta un sencillo ejemplo de diagrama de Gantt.
Estuclio Preliminar
2
Ana!lsis de Requisttos
"
Diseno
(ociifiulci6n
PruebEls
A::tividad 1
1 Dia
/
\
Jlctjvidad 2
2Dias
Jlctjvidad 3
Jlctjvidad 4
----+
4Dias
3Dias
108
Activity
Object
Decision
Agent
Relation
TimePoint
Creates
Modifies
Performs
Before
Activity Status
Uses
Successor
109
produce; los instantes de tiempo (timepoillts) que pueden ser una hora precisa, 0 un
punto del tiempo en el que puede ocurrir un evento; y finalmente la entidad Objeto
(Object), que representa todas aquellas entidades implicadas en un proceso, como
artefactos, helTamientas y agentes.
Timepoint
Object
end
at
participatesjn
in
begin
end
Activity
110
@RA-MA
metamodelo, pero otras necesitan de mecamsmos mas potentes como OCL (Object
Constraint Language).
Elementos Basicos (Basic Elements), defme los elementos basicos, que son
refinados en otros paquetes.
II>
RA-ivLI\
III
Pia n
Objective
Actio n
TimeSpec
Acto r
Resource
may use
/
may use
from
may involve
to
is performed by
mayuse
Transition Infotmation
-------------
112
:Q
RA-IvLA.
INTEGRADOS (ARIS)
El metamodelo Arquitectura de Sistemas de lnfonnacion lntegrados (Architecture
of Integrated b?/o17nation Systems, ARIS) (Scheer, 1998), tiene como objetivo dar soporte
al modelado, analisis y reingenieria de procesos de negocio. De acuerdo a ARIS, un
proceso es un conjunto de Funciones (jzlIlctions) cuyo objetivo es satisfacer Metas
Corporativas (cOlporate goals). Una funcion produce Salidas (outputs) y procesa Objetos
de Infonnacion (bifonnation Objects) tales como eventos y mensajes. El trabajo es
realizado por Unidades Organizacionales (Organizational Units) que incluyen maquinas,
computadores y recursos humanos.
3.3.8. SPEARMINT
SPEARMINT (Becker-Komstaedt et al., 2003) es una herramienta desarrollada por
el Fraunhofer lESE (Institute .lor Experimental Sojhrare Engineering) (vease
w\vw.fraunhofer.de) para describir procesos software. SPEARMINT sopolia la captura,
documentacion, mantenimiento y amilisis de los modelos de procesos software. El
metamodelo (figura 6.9) en el que se basa la herramienta es 10 suficientemente expresivo
para el modelado descriptivo de los procesos.
Como se puede observar en la figura 6.9,las clases que constituyen elmkleo del
metamodelo son: "Entity", "Activity", "Arti/act", "Role", "Resollrce", y "Toof'. Las
asociaciones mas destacadas son: "contains", "consumes", "modifies", "produces", entre
actividades y aliefactos: "involves" enh'e los roles y actividades, "lIses" entre recursos y
actividades, y 'precedes" entre estados, clase absh'acta de la que heredan las actividades y
las bifurcaciones de control (clase JoinSplitState). Las clases "ProdlictFlmrGraph" y
"ControIFlo,rGraph" y sus asociaciones son especificas para elmodelado visual.
En base a este metamodelo, la herramienta proporciona una notacion grafica
similar a UML para la definicion de modelos de procesos. Ademas, de dar sopOlie al
modelado, SPEARMINT proporciona capacidades para el analisis y pel111ite generar guias
(Electronic Process Guide, EPG) y manuales de ayuda al entendimiento del proceso.
[;RA.-MA
113
114
@R/\-MA
::>::':U
,
,
,'"isn:?!::,;",
,I
I
[ill -----------Ii> ~
Designer
3.3.9. PROMENADE
PROMENADE (Franch y RibO, 1999; 2003) es un lenguaje para la modelizacion
de procesos software que utiliza UML para describir sus constmctores, mediante la
generacion de un profile. En la figura 6.11 se representan la extension que PROMENADE
realiza sobre el metamodelo de UML para el modelado de procesos software.
Model (UML)
MetaDocument
I !
MetaRole
I SPMetamod
ModelElement (UML)
Trigger
' RA-iviA
115
Como se puede observar en la figura 6.11, las clases que componen el nucleo de
PROMENADE son:
e
lvfetaDocument, 1\1etaTask, MetaRole, que son consideradas como especializaciones del constructor Clase de UML. Estas tres clases son los constructores
cuyas instancias caracterizan un modelo de procesos software.
Las clases Precedence y Trigger son constmctores utilizados para modelar los
aspectos dimimicos de los modelos de procesos.
nuevos
constructores
definidos
en
imports-modeJs
maintaskMod 0 .. * \
has-as-maintask-cJass
0.. 1
dI
1
0.:
subtasksCI .
supertaskCI
0.. 1
has-as-subtasks-cJass
1.'
......~ask
II
'... 1
'.
""
"
''-.,
. ..
rolesCI
MetaRole
I
I
I
doc
'.
consists-of
parameters ",....
1.,* ......
"
1.. '
.'-.,"',
I
i
"'.
1.:
MetaDoeument
has-as~~rameters
model
'"
doesCI
Class(UML)
has-as-dc cument-cJass
iasksCI
1 has-as-other-cJass
"
1.:
otherCI
model
MetaTask
....---;
Imported Mod
/ /0 ..
D <> 1Cl.",
has-as-task-CJa/,
maintaskcl
1
SPMeiamod
mOd~/
1.:
Parameter (UML)
116
RA-MA
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.
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
SPEM (Software Process Engineering lvletamodef) es una especificacion de
OMG (2002). SPEM describe un metamodelo generico para la descripcion de procesos
software concretos. Esta basado en MOF y utiliza UML como notacion de modelado. Por
tanto, se basa en los principios de orientacion a objetos. En esta propuesta no se da soporte
a la ejecucion (enactment) de los procesos, es decir, la planificacion y ejecucion de
proyectos usando un modele de proceso descrito con SPEM. Ademas del metamodelo, la
especificacion SPEM tambien esta estructurada como un perfil UML (UiViL profile), es
decir, una vatiante de UML que utiliza los mecanismos de extension de UML en una
fOlma estandar para un proposito particular. Esto pelmite intercambiar definiciones de
procesos, tanto con helTamientas basadas en MOF, como con las basadas en UML.
Como metamodelo. SPEM constituye una plantilla para la creacion de modelos
de procesos concretos, como podrian ser el "Proceso Unificado de DesalTollo de software
de Rational" (RUP) y el modelo de evaluacion y mejora de procesos de ISO 15504. El
modele conceptual de SPEM esta basado en la idea de que un proceso software consiste
en la colaboracion enh'e entidades absh'actas y activas denominadas "roles de proceso"
(process roles) que realizan operaciones denominadas "actividades" (actidties) sobre
entidades tangibles denominadas "productos de h'abajo" ('l'Ork products). EI fundamento
de los procesos software consiste en la interaccion 0 colaboracion de mllitipies roles
mediante el intercambio de productos de trabajo y la ejecuci6n 0 disparo de ciertas
actividades. El objetivo de un proceso es llevar un conjunto de productos de trabajo a un
estado bien definido. En la figura 6.13 se representa en UML este modele conceptual
basico.
RA-ivV\
Rol de Proceso
--=~~~~~-
117
Producto de Trabajo
0 . .*
+entrada
usa
0 ..*
0 ..* +salida
produce
0 ..*
0 ..*
Actividad
lIS
@RA-MA
ModelElement
(from Core)
Classifier
(from Core)
WorkProductKind
Parameter
(from Cora)
v:';ird
Parame!erOirectionKind
0.:
Operation
ActivityParameter
(from Core)
nas\:ctf.PerA:1Jl a::t :
-,uoVio"
0 .. '
WorkProduct
Bc:)~ean
+perform:.
WorkDefinition
ProcessPerformer
0 .. '
0 .. '
{ordered}
-parer,tWOtk
0 .. "
Step
Activity . .
.... sep
ActionState
(from ActivitjGr<l;)hs)
0 .. 1
ProcessRole
+asSs.ant
-:es;::):':sloleRcle
0 .. "
RA-NLt\
Producto
/"
~,"
//'~;d
:C6digo de
los
Componentes
:Base de
Datos
Fisica
---=
Manual de
Usuario
120
:9 R,-\-MA
<~Oisciplin~':>:=
!l7;;::4em~rt.-:e:-i';)n
o:<Clzci;;line::>::>
?rtP..<oas
Realizar
MOdelos
Sfstema
Arquttecto
clel
Sistema
Realizar
Modelns
Usuario
f RA.-ivV\
121
Initial
State
Revisar el Trabajo
realizado en el
Proceso y las
Definiciones de
Clases
Revisar los
Modelos de l!lterfaz
deUsuario
/""
<Step>
Realizar If.lejorar eJ
Prototipo
Final State
(i)
3.3.11. SMSDM
El metamodelo SMSDM (Standard jvletamodel for Sojhrare De\'eloplIIent
Methodologies) (Henderson-Sellers y Gonzalez-Perez, 2004; Standards Australia, 2004)
establece un marco de trabajo para la definici6n y extensi6n de metodologias de desalTollo
de sofuvare. incluyendo sus h'es aspectos principales: el proceso a seguir, los productos
uti liz ados y generados y las personas implicadas.
Este metamodelo esta basado principalmente en los metamodelos: SPEM y OPF
(OPEN Process FrameH'ork) para los COnShlJctores directamente relacionados con el
122
&: RA-MA
Proyaeto
------------r-----
Apflcaciones
Antiguas \
Inicio
Bahoraeion del
Modelo de Datoll(p.
Diseiio de fa
Arqulteclura de
MOdulos del Sistema
DT.AYD.10l I',
(P.DT.AYD.20) \
Generacion de
A Especfficaciones l
J ; de Construccioll (P- \
DT-AYD.3tJ)
Espeemeaeion del
Plan de P[!mbas
Fin
iP.DT-AlJD.40i
\
'i
\
'i
\
\
:Cuallernos
!IeCarya
:Cat4logo
Detan~do de
Req1iiSltos
124
3RA-MA
!ModeIUnitUsase-Kind'
!...l:;S~r.gh:;!~S:.a,~:;~
Notatio-o
,,"",,"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.. '
0.'
0.:
I Con!oxt
CornpOfliHl!
0.'
,
,,I
ICumpmWI11
I
I
I
_.~ I
T,,,k
I
I
I
I
I
I
-I
__.___ L~_
US05 ~
2;;
I
I
0'
0'
:::r
:;;
o
'"
tT1
~~,_____
,Contexl
SL_
0:
"tJ
6n
m
(f)
o
o
(f)
::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
.1;) RA-MA
Performs.
ActsUpcr +Su~lec:
+Effact
WorkProductKind
1..'
.----,
WorkProduct
~Erkc!
A:rsUpcn '" .-SU::;jC::
Performs.
1--____. , ' - - - - - - - - - - - j_ _ _-j------------j+Creat<):lDate
+Lasl:hangeDaie
1.:
+Status
-C.::lUGO
RA.-i'.L-\
127
Los PSEE dan soporte a los procesos de ingenielia, usados para concebir, diseilar.
desanollar y mantener un producto software. a traves de un mode10 de procesos explicito
definido mediante un LMP adecuado. Los modelos asociados a un PSEE especifican
como las personas deb en interachIar y trabajar, y tambien como y cmindo las helTamientas
utilizadas en el proceso deben ser utilizadas y/o activadas autolmiticamente. Un elemento
clave del ent0l110 10 constiruye el motor del proceso (process engine) que es el encargado
de guiar y ayudar a las personas a la hora de llevar a cabo las distintas actividades del
proceso, y automatiza la ejecucion de las actividades que no requieren intervencion
humana. El motor de procesos esta constiruido por los siguientes elementos (Cugola y
Ghezzi, 1998):
(i)
(i)
(i)
128
RI\-JvV\
Usuarios
Usuarios
~
"
A
Producto,
Modelo de
Procesos y
Repositorio de
Procesos
"
<ill
Capa de Comunicaci6n
...
j.
Canales de
importacion
y exportacion
<ill
J.
'f
"
Espaciode
Trabajo
Espacio de
Trabajo
Vf
Motor de
Procesos
RA-MA
129
Otro de los aspectos clave de los PSEE es el tipo de soporte que ofrecen a los
usuarios, distinguiendose entre cuatro posibles tipos (Bandinelli et aI., 1996):
III
III
III
III
Slll
intervencion de los
Un mismo PSEE puede adoptar distintas fom1as de soporte al usuario, como por
ejemplo adoptar el enfoque de automatizacion para actividades que no requieren la
intervencion de los usuarios y el de obligacion para el resto.
Tambien es posible clasificar los PSEE en funcion de la fonna de controlar y guiar
el proceso. En este caso se distingue entre PSEE Proactivos, en los que el entomo inicia y
controla las operaciones realizadas por las personas y Reactivos en los que el entomo
queda subordinado a los usuarios.
En las ultimas dos decadas se han propuesto una gran diversidad de PSEE, entre los
que se pueden destacar los siguientes (Hanison et al., 1999), (Cugola y Ghezzi, 1998),
(Demiame et al., 1999): Adele (Belkhatir et al., 1991), APS (Balzer y Narayanaswamy,
1993), Arcadia (Taylor et aI., 1988), EPOS (Comadi et aI., 1994), HFSP (Katayama,
1989), Marvel (Kaiser et aI., 1990), Merlin (Junkermann et al., 1994), OIKOS
(Montangero y Ambriola, 1994), SPADE (Bandinelli et aI., 1993), GOODSTEP
(Emmerich et al., 1993), MELMAC (Deiters y Gmhn, 1990). Oz (Ben-Shad y Kaiser,
1994), PCTE (Boudier et al., 1988). Sin embargo, la repercusion industrial de estos
entomos ha sido minima, quedando en un plano 'meramente investigador a nivel de
prototipos. Solo algunos entomos han sido comercializados como es el caso de IPSE 2.S
(Warboys, 1990), SynerVision (HewlettIPackard Company, 1993), y ProcessWeaver
(F emstrom, 1993). Una comparativa de muchos de estos entomos es proporcionada por
Arbahoui et al. (2002).
A pesar de los grandes avances en la investigacion de los PSEE, la gran mayoda no
ha tenido la aceptacion industrial esperada. Una de las causas mas sigr1ificativas ha sido el
enfasis que los PSEE han dado a la descripcion de modelos de procesos como modelos
nonnativos cuyo seguimiento debia ser estricto. Ell0 Oligino PSEE muy dgidos que se
adaptaban mal a la naturaleza de las organizaciones, aspecto especialmente cdtico hoy en
dia en el que el mercado es muy dinamico y altamente competitivo (Demiame y Oquendo,
130
R..-\-MA
2004). Por otro lado, muchas de las propuestas incluyen LMP muy complejos y poco
intuitivos que ha dificultado su uso por los profesionales que prefieren lenguajes mas
intuitivos y que les facilite su comunicacion y entendimiento del proceso (Fugetta, 2000).
Todo ella ha OIiginado una importante reflexion en la comunidad investigadora siendo
algunos requisitos y retos importantes para el futuro los siguientes (Arbaoui et aI., 2002):
e
4.3.1. SPADE
El ent0l110 SPADE (Bandinelli et aI., 1993; 1995: 1996) es un PSEE disefiado en la
Universidad Politecnica de Milan que proporciona soporte al anaJisis, disefio y ejecucion
(enactment) de los procesos software. Para el modelado de los procesos utiliza el
f0l111alismo SLANG (SPADE Language), que es un LMP basado en una extension de
Redes de Petri a alto nivel. En SLANG un proceso se descIibe como una jerarquia de
actividades. Cada actividad puede incluir interacciones con usumios/helTamientas y
\"' R:\.-MA
acceso a datos del proceso. Existe un interfaz de la actividad "Run Tests". que es invocada
por la actividad "Test jVfodule Collection". "Run Tests" tiene dos transiciones simples de
entrada y salida, denominadas, respectivamente "Start Test'" y "End Test", dos lugares de
entrada (""Executable Module" y "Ready Test Cases") y un lugar de salida ("Final Test
Results "). En la parte derecha de la figura se ilustra una posible implementaci6n para la
actividad en la que se representa como un m6dulo ejecutable (executable module) que es
ejecutado repetidamente. cada vez con un detenninado caso de prueba (ready test cases).
Los resultados de cada ejecuci6n se comparan con los resultados esperados y el resultado
de la comparaci6n se afiade a los resultados de prueba acumulados. Cuando se han
ejecutado todas las pruebas la actividad tennina.
Las actividades y estados de actividad en SLANG son representados como redes
de Petli, mientras que los datos del proceso se representan como tokens. Un modelo de
procesos en SLANG esta compuesto basicamente por los siguientes elementos:
e
132
'9
RA-ivl~
4.3.2. APEL
APEL (Dami et al., 1998; Estublier et al., 1998: 2003) es un PSEE desan'ollado en
el Laboratoire Logiciels, Systemes, Reseallx, en Francia. Los objetivos fundamentales que
persigue se basan en dar soporte ala:
I.
2.
o RA-:VLA.
133
Servidor de Mensajes
Servidor de Mensajes
Usuario 1
FUSE
Usuario n
FUSE
Filtro
Interfaz de
Comunicaci6n
SPADE
Cliente 02
C!lente 02
Servidor 02
Clients 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
QRA-'.IA
La arquitectura basica del ent0l110 APEL (Dami et ai., 1998) se ilustra en la figura
6.26.
APEL tiene dos fonnas de representaci6n del proceso: gnifica, destinada a
usuarios finales del proceso y para desclipciones del proceso a alto nivel y textual, para
usuarios avanzados y henamientas. Como se puede apreciar en la figura 6.26, la
arquitectura consiste basicamente en:
III
III
III
III
III
III
III
III
III
135
Campiladorl
Interprete _ _ _ _ _ _ _-'-_ _ _ _ __
_ ______v_
Motor del
Proceso
jyietoaos de Usu8no
Herramlentas de Usuario
Servicios de
Ejecuci6n
Modelo
Principal
El flujo de control, que representa las actividades y las reglas que pem1iten su
ejecuci6n y ordenaci6n en el tiempo. Describe los aspectos relacionados con la
secuenciaci6n de las operaciones y la interacci6n entre operaciones
concurrentes.
136
RA.-ivLA.
COlllroi:flolr
5D
4.3.3. SERENDIPITY
Serendipity (Grundy y Hosking, 1998) lOonstituye un ejemplo muy representativo
de la influencia e importancia de los entomos de soporte al trabajo colaborativo
(Computer-Supported Cooperative Work, CSeW) en los PSEE.
Este PSEE integra el modelado de procesos y el soporte al trabajo cooperativo para
dar sopOIte a gI'andes sistemas de naturaleza colaborativa. Para ello. proporciona un nuevo
lenguaje gnlfico de modelado de procesos que pen11ite tanto el modelado descriptivo de
procesos indicando el trabajo a realizar, as! como una extension que pen11ite modelar los
eventos que intervienen en la ejecucion del proceso.
Como lenguaje de modelado Serendipity usa EVPL ().:tended Visual Planning
Language), que es una extension del lengIlaje VPL (Swenson. 1994), que preserva la
RAYLA.
137
nocion de "planes de trabajo" (H'ork plans) pero afiade capacidades especificas para dar
soporte al modelado de procesos genericos. De este modo EVPL puede ser utilizado para
modelar, desde modelos de procesos de trabajo genericos y reutilizables, hasta planes de
trabajo concretos para lill proyecto en particular. Algunas novedades que incorpora EVPL
son: identificadores de proceso, para mejorar la entendibilidad y las referencias entre
modelos; representaciones para elementos relevantes del modelo como los roles,
aliefactos y henamientas y conexiones de "uso" entre etapas del proceso y
representaciones de roles artefactos y henamientas. La figura 6.28 muestra un ejemplo de
un modelo de procesos representado con EVPL, que representa la definicion del
subproceso "modificaciones del disefio" en el que se muestran las actividades (stages) a
realizar, sus dependencias temporales y los roles y henamientas necesarios.
m 1:modell -roles
@
miW
'J';"'';
"~d.~s: i9n~:J.~
(,r)
.....
d~$i9n~:c
{;!)
rR
t1~d",1l",,,-
'''It-
I=:J
F\.J)H~
ml . 1 : d<i'::~ ign~X'
:'if""
",dit,;
[EJ
e~
~:
t"lk,; with
rR d"',;ign
... ,J;.. .. )
u,;.::,;
ml .:3 : t",;t.::r
(A)
ch~c}~ cn.tln9~s
~.
ml .2 : cod~:C:!r
(.f) . ~., ..
.....
...... .
r orm:f;u i Id",,-
:IJ!.
138
RA-MA.
dependencias entre etapas del proceso que pertenecen a distintos modelos, eventos de
modificaci6n de artefactos y de invocaci6n de herramientas, asi como reglas y
restricciones de los modelos. Para ella EVPL incorpora constructores especificos, basados
fundamentalmente en los conceptos de "filtros" y "acciones", que reciben eventos de
etapas del proceso, artefactos, herramientas, roles u otros filtros y acciones.
Una vez definido el modelo de procesos en Serendipity, este puede ser ejecutado
por los usuarios para un detenninado proyecto en cualquier momento. Los procesos en
ejecuci6n pueden ser modificados en cualquier momento con el fin de extender y mejorar
la propia especificaci6n del proceso. Un modelo de procesos es ejecutado mediante la
selecci6n de la etapa del proceso a ejecutar a traves del interfaz de usuario del entomo. El
usuario tambien debe especificar el motivo de la ejecuci6n y si la etapa del proceso tiene
defmidos submodelos de procesos, se debe indicar la etapa de comienzo. Una vez iniciada
la ejecuci6n por el usuario, el entomo envia un evento de ejecuci6n (enactment) a la etapa
del proceso a ejecutar, que a su vez envia eventos de enactment a todas sus etapas
conectadas. Cuando se ha completado el trabajo asociado a dicha etapa del proceso 0 un
subproceso se producen eventos de finalizaci6n iniciandose la ejecuci6n (en funci6n del
tipo de conexi6n) de las siguientes etapas.
En la figura 6.29 se muestra un modelo de procesos que esta siendo ejecutado. Las
etapas que aparecen sombreadas son aquellas que estan en ejecuci6n (sin haber finalizado
alm). De la misma fonna los flujos de eventos que han activado alguna etapa tambien
aparecen destacados en el modelo, mientras que la etapa actual sobre la que el usuatio esta
trabajando es destacada en negrita. La intelfaz del entomo facilita al usuatio seleccionar
cualquier etapa a ejecutar y visualizar una lista de las etapas que ha ejecutado.
~fl
OO:@
Ii
O,ew
i)
(Rdd
Conte!!t ) ( Undo
l Delete 1
( Redo
l Cancel
~ RA-tvL~
139
Para dar soporte al trabajo colaborativo en Serendipity, las vistas de los modelos de
procesos pueden ser compartidas entre los desarrolladores de forma sincrona, semisincrona y asincrona. La edici6n sincrona usa la metMora del espacio de trabajo
compartido en el que todos los usuarios comparten los mismos datos y las vistas de estos
datos son editadas sincronamente usando un enfoque "10 que tll ves es 10 que yo veo". En
la forma de edici6n asincrona, cada usuario tiene una versi6n alternativa del modelo de
procesos la cual modifican independientemente de otros usuarios. Los usuarios pueden
exportar su alternativa al espacio de trabajo compartido de forma que los usuarios pueden
mezclar dos 0 mas altemativas para producir una nueva versi6n. En la forma de trabajo
semi-sincrona, los cambios hechos por un usuario son enviados a otros usuarios de interes
mediante dialogos y vistas de forma que estos usuarios puedan elegir si incorporar esos
cambios en sus modelos.
Para facilitar el trabajo colaborativo, Serendipity ha sido integrado con pequenas
herramientas CSCW, que proporcionan facilidades de edici6n de notas, mensajeria,
conversaci6n y comunicaci6n en general entre las personas que interacruan con el entomo.
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
140
6. EJERCICIOS
1.
Diagrama de Gantt.
b.
c.
Realizar una busqueda bibliografica para analizar la influencia que tienen los
sistemas de h'abajo cooperativo basado en computador (CSCW) en los Entornos
de Ingenieria del Software Orientados al Proceso.
3.
4.
5.
CAPITULO 7
MODELOS DE PROCESO DE
CICLO DE VIDA
.. Una vida illlitil es lIna mllerte prematura "
Goethe
142
lado, la nonna ISO 15288 (ISO, 2003) define cicio de vida de los sistemas como "fa
evofllcion en ef tiempo de lin sistema de inten?s desde su concepcion hasta su retirada",
destacando que un modelo de cicio de vida es "un marco de procesos y actividades
relativas af cicio de vida que actlia tambibl como una referencia comzin para fa
cOlllllnicacion y ef entendimiento".
El cicio de vida abarca, por tanto, toda la vida del sistema, comenzando con su
concepcion y finalizando cuando ya no se utiliza. A veces tambien se habla de "cicio de
desarrollo", que es un subconjunto del anterior y que empieza en el amilisis y finaliza con
la entrega del sistema al usuario.
A continuacion se resumen los principales estandares relacionados con los ciclos
de vida propuestos por las nonnas ISO 12207 y 15288.
servicio al
(; RA.-lvLA
PROCESOS PRINCIPALES
PROCESOS DE SOPORTE
ADQUISICION
DOCUMENT ACION
SUMINISTRO
GESTION DE LA CONFIGURACION
DESARROLLO
ASEGURAMIENTO DE CAUDAD
. EXPLOT ACION
VERIFICACION
MANTENIMIENTO
VAUDACION
PROCESOS ORGANIZACIONALES
REVISION CONJUNT A
GESTION
AUDITORiA
INFRAESTRUCTURA
MEJORA
143
USABIUDAD
..............
RECURS OS HUMANOS
EV ALUACION DE PRODUCTO
GESTION DE ACTIVOS
PROCESODE
ADAPTACION
Figura 7.1. Procesos del cicio de vida software segun ISO 12207
o
144
:&:RA-MA
~ RA.-MA
--7
--7
--7
--7
145
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.
Proceso de validacion. Este proceso sirve para confinnar que se cumplen los
requisitos para el uso pretendido del producto de trabajo software.
146
RA-MA
RA-ivlA
-7
-7
-7
-7
-7
-7
Se toman las acciones oportunas cuando no se logran los objetivos de cali dad
147
Tabla 7.2. Resultados del proceso de gestion de calidad segun ISO 12207
e
Proceso de gestion de activos. Este proceso sirve para gestionar la vida de los
activos reutilizables desde su concepcion hasta su retirada.
148
:g RA-ivL-'I.
MODELOS Y METODOS
OTRAS ENTRADAS
TIEMPO
I--
DINERO
ESTANDAR
DE
PROCESOS
DE CICLO DE
VIDA DEL
SOFTWARE
ISO/IEC
b\
D
CASCADA
I REQUISITOS
I
LEY
SEGURIDAD
I SEGURIDAD FislCA
CREDENCIALES
(ISO 9001, ..... )
CAPACIDAD DE LA
ORGANlZACION
r--
APLlCACfON
ADAPTACfON
EVALUACION
PRUEBAS
ETC.
METODOS
ENTORNO
MATRIZ DE RESPONSABILIDADES
AOQ
sm.1
DES
/"
MANUAL DE
CAUDAD
PROCEOIMIEI'HOS
(;'RA-MA
149
serVlClO software y
Tabla 7.3. Objetivos del proceso de aseguramiento de la calidad segun IEEE (1998a)
Estos datos del ciclo de vida deben ser no ambiguos, completos, velificables,
consistentes, modificables, tJ'azables, presentables (recuperables y visibles), seguros y
privados, protegidos, con-ectos y adecuados. Debetian tener contenido relativo a datos de
requisitos, datos de disefio, datos de prueba, datos de configuracion, datos de usuatio,
datos de gestion y datos de calidad. Estos ultimos abarcan planes y procedimientos de
calidad, estado de las acciones con-ectivas, analisis de causas raices, caracteristicas de
calidad del producto y datos de medici ones de proceso, y critelios y fundamentos para las
dccisiones clave.
En la tabla 7.4 se presenta el contenido del plan de asegurat11iento de calidad de
software.
ISO
RA-NL~
---?
---?
---?
---?
---?
Ell
Ell
f:RA-lvL\
151
-+
-+
-+
-+
-+
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.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.
15 J
RA-1vL-\
basicamente en el texto del estandar ISO 12207 junto con anexos explicativos. Los otros
dos documentos contienen recomendaciones adicionales delivadas de MIL-STD-498 y de
los estandares de ingenieria de IEEE, con algunas influencias adicionales.
6. EJERCICIOS
1.
2.
3.
Lleve a cabo un estudio comparativo entre los estandares IEEE 1074, ISO 12207
e IEEE 12207.0, IEEE 12207.1, IEEE 12207.2.
4.
CAPITULO 8
1111
continllo progreso y crecimiento, palabras tales como mejora, logro y exito no tienen
ningzln signijicado "
Benjamin Franklin
1. PANORAMICA GENERAL
Hoy en dia la calidad del software no puede garantizarse imicamente centrando los
programas de cali dad en el producto, dado que, tal y como se ha comentado en el capitulo
6, la cali dad final del producto software esta muy directamente relacionada con la fOlma
en que se desarrolla y mantiene, es decir, con el proceso. Todo ella ha motivado en gran
medida que las organizaciones dedicadas al desarrollo y mantenimiento del software se
preocupen cada vez mas de la mejora de sus procesos.
Ante esta situaci6n, los modelos de evaluaci6n y mejora de procesos y su
estandarizaci6n han adquirido un papel muy impOltan!e para la identificaci6n, integracion,
medici on y optimizacion de las buenas practicas existentes para el desarrollo y
mantenimiento del software. La evaluaci6n y mejora de los procesos software pel1niten
juzgar y decidir sobre la calidad de los procesos que estan sujetos a analisis, con el
objetivo de poder establecer una estrategia para su mejora. La evaluaci6n de los procesos
software se hace principalmente por dos motivos: bien para detel1ninar la capacidad de ill1
proveedor de cara a su contrataci6n, 0 bien para mejorar los procesos.
Como resultado de los esfuerzos de la comunidad cientifica, se han propuesto toda
una serie de modelos y estandares para promover la aplicaci6n de este proceso en las
organizaciones. La aparicion en el mercado de estas propuestas esta ofreciendo a las
empresas y departamentos de desarrollo infol1natico la posibilidad de adaptarse a una
nueva fOlma de trabajo caracterizada principalmente por buscar la satisfaccion de los
154
People CMM
~ ~ ~
(
~~
(
de
se
en
es
MPSB,
Bootstrap)
MOPROSOFT )
ISO 15939 )
~
(SsEl
~
Baldrige)
(IeEel
~
---l> Sus:i:Uye a
... Basado en
<
ISOIIEC 15288 )
... UsaReferen:::ia
I!l
I!l
0 el ISO
15288 para la ingenielia de sistemas, que han sido resumidos en el capitulo
anterior.
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).
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
155
MODELO
BOOTSTRAP (Kuvaja et al., 1994)
....
...
I
I
h!!Q:; \\\\\v.stsc.hill.af.millcrosstalklI997/04/de
veloQment.asQ
http://\\\\w.tickit.org/
htt12: !v,\\"\\2.umassd.edulswI1i1BeIICanadaitrilli
um-htmlltrillium.html
Tabla 8.1. Resumen de los Modelos de Madurez y Metodos de Evaluaci6n y Mejora del
Sofnvare (ultimo acceso de enlaces web en agosto de 2006)
156
157
los
resultados
i58
RA-MA
NIYEL
CARACTERiSTIC\S
I:\IClAL
REPETIBLE
DUl:\IDO
GESTlO:\ADO
RESULTADOS
Productividad y
calidad escasa.
Riesgo m;iximo
Productividad y
calidad baja.
Riesgo alto.
Productividad y
calidad media.
Riesgo medio.
Productividad y
calidad alta.
Riesgo minimo.
OPTl:\lIZADO
159
Productividad y
calidad total.
Riesgo nulo.
160
RA-MA
Pn3cticas Clave
Actividades e infraestructura que
contribuyen en su mayoria a la
implementaci6n de un al'ea clave de proceso
Areas clave del proceso. Cada nivel de madurez. excepto el nivel inicial se
descompone en diterentes areas clave del proceso. Ejemplos de areas clave son
la gesti6n de configuraci6n y planificaci6n del proyecto del segundo nivel de
madurez, 0 la prevenci6n de defectos y gesti6n de cambio del proceso.
cOlTespondientes al nivel quinto de madurez. Cada area clave contiene un
conjunto de objetivos 0 metas, que descliben de fonna general que se debe
hacer para dar soporte a un area clave de proceso. Las metas se us an para
cOl11probar si efectivamente se implementa adecuadamente un area clave de
proceso detenninada.
Caracteristicas Comunes. Cada area clave de proceso se organiza en una
selie de caracteristicas comunes que representan los atIibutos que debe tener el
proceso. Mediante la evaluaci6n de las caracteristicas comunes se puede
averiguar si la il11plel11entaci6n de un area clave de proceso se ha realizado de
fOlma que sea efectiva, repetible y duradera.
GRA.-MA
(i)
161
162
tJ RA-MA
Ejemplos
- Planificaci6n del Proyecto
- Seguimiento del Proyecto
- Gestion de la Configuraci6n
- Aseguramiento de la CaUdad
Operaciones de Desarrollo
- Gestion de Requisitos
Ejemplos
- Entornos de ingenieria
- Metodo!ogias de Amllisis de Requisitos
- Metodologias de Diseno
-C6digo
Soporte para
Procesos de Toma de
Decisiones y
Comunicaci6n
Soporte para
Procesos de
Comunicaci6n y
Tecnicos
Procesos Tecnicos
No Evaluado por
seE
Como se puede apreciar en la tabla 8.3, el equipo de evaluaci6n SCE lleva a cabo
una planificaci6n en la que basicamente identifica las areas de proceso a evaluar para
realizar un proceso de evaluaci6n basado en rigurosas revisiones de documentaci6n y
entrevistas en el que, mediante un proceso de analisis, se establecen las debilidades y
fortalezas de la evaluaci6n para finalmente realizar los infol1nes adecuados en funci6n de
los resultados obtenidos.
\:" RA-M.-\
163
ACTIVlDADES Y RESULTADOS
La Organizacion Patrocinadora:
PL~"IFICAR y
REALIZAR LA PREPARACID:-'PARA LA
EV.ALV.KID:-'-
REALIZAR
LA EVALLACID:-'-
DE LA EVALLAClD:-'-
164
Ii>
-f' RA.-:VL-I.
Las actividades y a1cance del proceso de evaluacion del metodo CBA-IPI son
basicamente los mismos que en el metodo SCE (planificacion, conduccion y generacion
de infol1nes). En realidad, CBA-IPI es muy similar a SCE con la diferencia fundamental
de que CBA IPI es una evaluacion centrada en la mejora de procesos, mientras que SCE
suele orientarse mas a la seleccion de suministradores, aunque tambien se puede usar para
la evaluacion intema de procesos.
De acuerdo a la tel111inologia usada en los modelos de evaluacion basados en
CMM. se considera que CBA IPI es un metodo para la valoracion (assessment) de la
capacidad para mejora de procesos. mientras que SCE es un metodo de evaluacion
(emillation) con el fin de seleccionar suministradores 0 para medir el progreso de las
mejoras. La diferencia fundamental entre la valoracion y la evaluacion es que la primera
consiste en un proceso que una organizacion hace para sl misma, mientras la segunda es
un proceso en el que un grupo extemo llega a una organizacion y examina la capacidad de
sus procesos para tomar decisiones respecto de posibles negocios 0 tratos llhlroS. EI
a1cance de una \-aloracion es relativo a las necesidades de la organizacion y objetivos de
negocio del patrocinadoL que es usualmente el gestor senior de la organizacion evaluada.
En contraste. el alcance de una evaluacion es relativo a las necesidades del patrocinador.
que es la persona 0 grupo de personas responsables de decidir si se hace la evaluacion de
la organizacion con la que se pretende hacer negocios. En la tabla 8.4 se representan las
diferencias entre un proceso de valoracion y un proceso de evaluacion.
Los resultados de la evaluacion de los metodos comentados anteri0l111ente se
pueden utilizar en el contexto de la mejora de procesos software. ya sea para la mejora de
los procesos de la propia organizacion evaluadora (CBA-IPI) 0 para mejora en la
organizacion evaluada (SCE).
3.4. IDEAL
EI marco de mejora de procesos del SEr 10 constihlye el modelo IDEAL
(McFee ley, 1996: Gremba y l'vlyers. 1997) en el que se define un marco de ciclo de vida
para la mejora de procesos. Este modelo lIe concebido originalmente como un cicIo de
vida para la mejora de procesos software basado en el modelo CMM y posterionnente el
l110delo IDEAL lIe revisado en la version 1.1 para proporcionarle un a1cance mas amplio.
IDEAL constihlye un enfoque usable y entendible para la mejora continua estableciendo
los pasos necesarios que se deb en seguir para llevar a cabo un programa de mejora y
proporcionando un enfoque ingenieril y disciplinado. En la figura 8.4 se l11uestra la
estruchlra de este modelo.
V ALOR-\CION (ASSESSMEi\"T)
Mejora de Procesos
OBJETIVO
I.
Se usan en la organizaci6n evaluada
COi\It1NICACION
DE REsULtADOS
EVALUAtl(~N (E\'ALUATION) ..
Selecci6n y monitorizaci6n de
suministradores
Los desarrolladores 10 usan para medir el
progreso de la mejora
Los resultados se hacen saber al
patrocinador
Los miembros de la organizacion podrian
no estar en un equipo
EQL1PO
l65
I
ALCANCE
USODELOS
RESULTADOS
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:
til
166
EI
EI
&
167
168
Detennina los pasos que los ingenieros deben seguir para mejorar la calidad del
producto.
Detennina el impacto que los cambios del proceso tienen sobre el rendimiento
del ingeniero.
Estos resultados son obtenidos haciendo que los partlclpantes recopilan datos
especificos relacionados con el proceso y el producto y estableciendo la linea base que
proporcione a los ingenieros con un contexto para mejorar el proceso.
En la figura 8.5 se muestran los siete procesos que constituyen PSP agrupados por
niveles. Para alcanzar un nivel se deben cumplir los requisitos establecidos en los niveles
previos, 1m1s los nuevos impuestos en dicho nive!. Estos niveles son:
<'{'t~~~:t:'cg,i'?'.
EI Proceso Personal
Ciclico
Desarrollo Ciciico
PSP 2.1
Revision Disefio
Revision Codigo
Plantillas de Disefio
r<. :"::1'" . . . ;.
Estimacion TamaRo
Informe Pruebas
PSP 1.1
Planificaci6n de Tareas
Planificaci6n de Calendario
PSP 0.1
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
169
programas y se les pennite usar sus metodos actuales, pero dentro del marco
de trabajo compuesto por los siguientes seis pasos representados en la tabla
8.5:
PASO
FASE
Planificar
Diseiiar
Codificar
::
3
..J.
Compilar
Probar
Postmortem
DESCRIPCIO"l
Las tres medidas base de PSP son: tiempo de desalTollo, defectos y tamafio.
Todas las delmis medidas en PSP son derivadas de las anteliores. EI proceso de
medicion en PSP se introduce desde las tres primeras asignaciones del proceso en
los niveles PSPO y PSPO.l. En las tab las 8.5 y 8.6 y se muestran ejemplos de los
fonnularios que se utilizan para el registro de tiempos y defectos:
FORiVIU4\RIO DE REGISTRO DE TfDIPOS
T.
FI"i
TlEMPO
{;I;TERRliP.
DELTA
7:58
8:45
..J...J.
8:47
10:29
100
Diseiiar
7:.+9
8:59
70
Codifiear
9:15
9:46
31
Compilar
9:47
10:10
l'
-.)
Probar
4:33
4:51
16
Postmol1em
FECHA
CmUDZO
1315:05
It
FASE
Planificar
COME2"TARIOS
Llamada telefono
Crear y revisar
diseiio
Codificar main y
todas las nmeiones
Compilar y enlazar
Ejeeutar pruebas A.
ByC
I
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
FECRA
N"
13/5/05
13/5/05
TIPO
20
i
i
I hrRODUCIDO
Er,\,
....
TIPO
13/5/05
3-6
20
Descripci6n
C6digo
II
II
DEFECTO
CORREGIDO
DEFECTO
EUlIcUNADO
TlEMPO
CORRECCION
CORREGIDO
EN
[8
COMPIL I
I
Descripci6n
I
Descripci6n
M-Nt\
..
...
&;
I L\TRODuCIDO
EN
I
C6digo
TlEMPO
i DEFECTO
EUMINADO
CORREGIDO
El"
CORRECCIOl"
1
I
I COMPIL I
Faltaba:
!; RA-ivlA
171
problemas, para documentar los aspectos que pueden afectar a los ciclos
futuros 0 completados. Usando PSP3 los ingenieros descomponen su
proyecto en series de ciclos PSP2.1, y luego integran y prueban las salidas de
cada cicio. Teniendo en cuenta que los programas que se producen con
PSP2.1 son de alta calidad, los costes de integracion y pruebas se minimizan.
172
calsilcL::rio
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.
173
Antes de que los miembros puedan participar en un equipo TSP, deben conocer
como realizar un trabajo disciplinado. Tal y como se muestra en la figura 8.7, es necesario
que los ingenieros que usan TSP esten f0I111ados en PSP. La f0I111acion en PSP incluye el
aprendizaje necesario para: realizar planes detallados, reunir y usar datos del proceso,
desarTollar planes. usar los valores obtenidos (earned vallles) para realizar un seguimiento
del proyecto, medir y gestionar la calidad del producto y definir y usar procesos
operacionales. En TSP, la tar'ea de construir el equipo es un proceso de planificacion de
cuatro dias denominado lanzamiento del equipo (team launch). En este proceso, todos los
miembros del equipo desarTollan la estrategia. el proceso y el plan para hacer su proyecto.
El lanzamiento del equipo esta compuesto por nueve reuniones, cada una de las cuales
tiene un guion con las actividades a seguir descritas en detalle y que el entrenador
(denominado "'alil/ch coach ") utiliza para guiar al equipo. Como resultado se obtiene un
plan, en los que todos los miembros del equipo deberian haber participado y con el que
deben estar comprometidos. Una vez completado este proceso inicial, el equipo sigue su
proceso definido para hacer el trabajo necesario.
Construcci6n de
Habilidades
Construcci6n de Equipos
Trabajo en Equipos
Planes Personales
Compromiso
r-.lI~todos
Planes AgresivQs
Prioridad de la Calidad
Coste de la Cali dad
Propiedad de la Calidad
Seguir el Proceso
Revisar el Estado
Revisar la Calidad
Comunicacion
de Planifjcacion
Valor Obtenido
(earned value)
Datos del Proceso
rledidas de Calidad
Proceso5 Definidos
Disciplinas de
Ingenieria
Disciplinas de
Equipo
Disciplinas de
Gesti6n
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
RA-lvLi\
Durante cada lanzamiento del equipo tambien se elabora el plan de calidad. Para
gestionar la cali dad los equipos establecen metricas y objetivos de calidad asi como planes
para alcanzar dichos objetivos y los medios para conocer el progreso y llevar a cabo
acciones cOlTectivas cuando no se satisfacen los objetivos. TSP ensei'ia a los equipos como
deben realizar este proceso de gestion de cali dad mediante guiones en los que se definen
las metric as a usaI' como parte del proceso. Las metricas pueden ser de tamafio (pOl'
ejemplo en miles de lineas de cOdigo, KLOC), tiempo (en minutos y horas), calidad (en
fonna de defectos), rendimiento del proceso (% de defectos eliminados antes de una fase
detem1inada) y densidad de defectos (defectosIKLOC) de los productos obtenidos. En
TSP se establece como estas metricas son definidas, estimadas, recopiladas, presentadas y
analizadas. Tambien se hace uso en el proceso de datos histolicos de los equipos, y de
lineas guia sobre calidad y planificacion.
Algunos ejemplos de expeliencias industriales en la aplicacion de TSP pueden ser
consultados en (Humphrey, 2000a) y (McAndrews, 2001). Desde el punto de vista
academico, Oktaba e IbargHengoitia (2002) demuestran al usaI' TSP como mater1al
didactico de apoyo que se fomenta el aprendizaje a u'aves de la practica obteniendose
importantes beneficios para los alumnos como: f0l111acion en el proceso de desalTollo
incremental e iterativo: roles y responsabilidades bien definidos: incorporacion de las
met11cas en el proceso de desarTOllo: uso de tecnicas de inspeccion y revision de los
productos: insistencia en la estandar1zacion de la documentacion y del c6digo y analisis
post-mortem.
175
establecimiento de las fuerzas de trabajo que la organizacion necesita para llevar a cabo
sus planes de negocio.
Desde la perspectiva de People ClvIM, la madurez de la organizacion se deliva de
las pnicticas de fuerzas de los empleados que son realizadas de forma rutinaria y el punto
hasta el cual estas pnicticas han sido integradas dentro de un proceso institucionalizado
para mejorar su capacidad. En una organizacion madura, los individuos responsables
realizan pnicticas repetibles como requisitos ordinarios y esperados de acuerdo a su puesto
de trabajo. A medida que una organizacion es mas madura, mayor capacidad tiene para
atraer, desanollar y retener el talento que necesita para ejecutar sus negocios. En la figura
8.8 se muestran los niveles de madurez de People Cj\;IM y la naturaleza de las
tranSf0l111aciones impuestas sobre las practicas del personal de la organizacion a la hora de
alcanzar cada nivel.
Practicas
de Mejora
Continua
Pr<3cticas
Medidas y
Autorizadas
Practicas
basad as en las
competencias
Practicas
Repetibles
Con la excepcion del nivel inicial, cada nivel de madurez en People CMM esta
caractelizado por un conjunto de practicas intelTelacionadas entre si y relativas a areas
critic as de gestion de fuerzas de trabajo.
En el nivel inicial, las organizaciones tienen dificultades para retener a los
individuos con talento y a pesar de su importancia. las practicas de los empleados son ad
hoc e inconsistentes. En algunas areas no existen definidas practicas para los empleados y
en las que existen, el personal no esta fonnado para llevarlas a cabo. E1 primer paso hacia
1a mejora de la capacidad de los empleados consiste en obtener directores que asuman las
actividades de los empleados como responsabilidades de alta pliOlidad. Las practicas
176
RA,-\IA
177
PARTES DEL-\.;\OR'Y!A
ISOfIEC 15504
CO!'iTENIDO
L Conceptos y Vocabulario
II
II
178
RA,-MA
hasta el ellal los proeesos realizan Sll prop6sito, En la figura 8.9 se mllesh-an las
aetividades y las entradas y salidas del proceso de evaluaci6n de ISO 15504.
Modelo de Referencia
del Proceso
- Dominic y Alcanc,:;
- Propos ito del Proceso
- Resultados del Proceso
Marco de Trabajo
de la Medici6n
r-""""'11r----i -
Nivelcs de Capacidad
- Atributos del Proceso
- EsciJ.!a de VaJoracion
Alcance
Indicadores
Correspondencia
Interpretacion
Entrada Inicial
Salida
- Proposlto
- Alcance
Proceso de Evaluaci6n
- Restriccion:;;s
- Planificaci6n
- Recopilacion de Datos
- Jdentidades
- Validacion de Datos
de Competencla
- Fectla
- Entrada de !a Evaluaci6n
- !dcntificacl6n de la E'Iid2ncia
- ?rocesD d<;: =valua:;16n utiilzadc
Roles y Responsabilidades
- ?3Irocinaoor
~RA-iv1A
179
180
Ii)
Ii)
Ii)
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.
Reduciendo duplicaciones.
l82
fJRA-MA
....
Software
Ingenieria de Sistemas
Proceso integrado de
desarrollo de
productos
MODELO FUENTE
.'.
Modelo de Capacidad de
Ingenieria de Sistemas
(ELMS 731)
Desarrollo integrado de
producto CM!v!
(IPDCMNI)
Ri\.-ivLA.
183
EI
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.
18.+
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)
(01'1))
(7 Areas ce Pro:eso)
Figura 8.12. <~reas Clan de Proceso agrupadas segun la representacion pOl' etapas
(Philips, 2001)
:. RA-ivLA.
185
Representacion Continua
C
4
3
2
1
a
c
i
d
a
d
o
Proceso
Figura 8.13. Representacion Continua de CMMI
186
proceso se agrupan por las categorias (figura 8.14): Gesti6n de procesos, Gesti6n de
Proyectos, Ingenieria y Apoyo 0 Soporte.
Gestion de
Proyectos
Organi/aciollai
_ ~oluciun Tecnica
- Ge'llit'11l de Confi~ur;\(::i()n
- A.,i.'gunmlicnro de la CaUdad
del
PrnCl'SO
y Pruducto
_ \'erificacillll
_ Validacion
de Rie\go':!
- Enh'nlc1
- Equipo
Org:lni.l:~.:i\-'n:.:.j
inh:.;rJd~l
p:,:.! b Im;;,;r:!-:i"'ln
Sd~~~ion
y \!uniwrli'::.:i\';n l::;j
Sunm1!~tr:hk',
Eil
Eil
1:RA-MA
187
"
"
"
Selecci6n del
Suministrador
Monitorizaci6n del
Proceso
..
"
"
"
"
Al igual que los metodos de evaluacion CBAlIPI y SCE las principales fases de la
evaluacion SCAMPI son:
188
EVALUACION
Se estan desanollando y utilizando diversos modelos de madurez en varios paises
iberoamericanos. A continuaci6n se des crib en brevemente algunos de los mas
representativos.
El
Se contemplan los veintid6s (22) procesos de la nonna ISO 12207 (ISO, 2002), Y
siete (7) niveles de madurez: A (en optimizaci6n), B (cuantitativamente gestionado). C
(definido), D (grandemente/largamente definido), E (parcialmente definido), F
(gestionado), G (parcialmente gestionado). Con esta mayor granularidad en los niveles se
pretende facilitar una implementaci6n mas gradual, adecuada y en plazos mas cortos para
las empresas pequei'ias y l11edianas de Brasil.
EI me to do de evaluaci6n se bas a en la nonna ISO 15504. EI grado de
il11plementaci6n de una practica se evallJa de acuerdo a cuatro niveles: totalmente
il11plementado, bastante implementado, parcialmente implementado, no implementado; y
se basa en tres tipos de indicadores: directos (productos intennedios), indirectos
(documentos que indican que una actividad fue realizada), y afinnaciones (resultantes de
entrevistas).
En la tabla 8.11 se presentan las reglas para caracterizar el grado de
implementaci6n de las practicas COnf0l111e a SPICE y CMMI.
t R.A.-MA
189
ISOIIEC 12207
ISOIIEC 15504 (SPICE) - -_ __
CMMI
Guiade
-<!,.I----il\lll>
Gufade
Eva!uacion
MPS
MPS
Evaluaci6n
Guia General
lmptementacion
MPS
ICll
Metodos de
ICAl
ICln
ICA2
ICAn
Empresa 1
Empresa n
Figura 8.15. Modelo de referencia para la mejora de proceso software (MR pms)
."
GRADO DE
Ii\fPLEYIEi'ilAclON
DE L.'\ PRACTrCA
Totalmente
implementado
Largamente
implementado
No implementado
CARACTEruzAcroN
Un indicador
adecuadamentc.
Parcialmente
implementado
..GRADODE
",
ALC.4c"lCE .
dirccto
esta
presente
es
juzgado
>85%a
100%
>
50~o
85%
> 15%a
50%
O%a 15%
190
RA-M4
:. RA-ivV\
<<Catecor.a
191
<<Cate!; ..
Alta !).rec6on ~
O;;eracion
Prcceso
Gestio;'! de
r~egodo
Proceso
Gesti6n de Procesos
(from Gestion)
?roceso
Proceso
Gestifln de Prayectos
(frem Gestion)
G::stl:in de R=cursos
{from Ge:stion)
-1---- ---.
-_
Proceso
';dmn:stracf::in de Proyectos Es;;ecifl::os
..... _ - - - - <<Su!:l?roceso
genes, Servi::iQs e Inrraestru::tu:-a
{from GestiOn)
. - - -..
---~--
<<$utJProceso
(from O;;eraci6n)
<<$wbProceso
Desarool:o
r'lenten:mento de Software
192
RA-ivLA.
Resultados de
la Investigacion
Resultados de
la aplicacion
Propuestas
empresas y organizaciones
participantes en el prayecto
(gropo eritico de referencia)
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
193
7. LECTURAS RECOMENDADAS
Hunter, R. y Thayer, R. (eds) (2001). Sojilmre Process Improvement., WileyIEEE 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.
19..
II
RA-MA
CiI
CiI
II
II
e RA-ivlA.
195
9. EJERCICIOS
1.
2.
3.
Definir una version del modelo CMMI pOl' etapas adaptada a las pequeiias y
medianas empresas (PyMES).
4.
5.
9. l\1edicion de Sistemas de
Info:rmacion
10. CaUdad de la Info:rmacion
11. Gestion del Conocimiento
CAPITULO 9
MEDICION DE SISTEMAS DE
INFORMACION
"No se puede contra/ar /0 que 110 se puede medir"
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 contIolar 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).
En este capitulo en primer lugar se presentan de fonna intIoductOlia algunos
fundamentos de la medicion del software, para 10 cual se analizan las apOliaciones de la
teolia, la tenninologia y los aspectos 111<lS relevantes a considerar en el proceso de
obtencion de metIicas. A continuacion se presentan los metodos y estindares mas
200
:g RA-\IA
Escala Nominal. Es la esc ala mas bitsica, que sirna a las entidades en
diferentes c1ases 0 categorias asignando al atI-ibuto un nombre. De este
modo las c1ases se identifican lll1icamente mediante un nlunero 0
simbolo que no puede ser interpretado salvo como un mero identificador.
Por ejemplo, distinguir de fonna nominal a los jugadores de un equipo de
baloncesto pOl' su dorsal. EI jugador "30" no puede interpretarse como
dos veces superior al jugador "15".
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 ".
20]
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).
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.
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
<;;
R/\.-MA
CiI
203
seCQrrea:::;r;:;e c:;n
y O!:>;e:;,es)
Tipo de Es::ala
\fr:;;mMt-t!\e::!s)
Modelo de Calidad
Concepto Medible
e,"af:ia
C0dase
:rc"'C"!'3~"''':'''Z':>'lyo::)e::,~)
Escala
Unidad
de:;r;.:fopara
:',,:-:2
Categoria de Entidad
(!r::.", C:n::::,.=r;:,,:.C<1 y
Entidad
s:;::;Enidaj
Atributo
52
Metrica
de::neparo
{:rcmMeL"i:::as)
C:;;<:'~>r-~l
Medici6n
l't1etrica Indirects
t:ror.:-.li!etn:as)
{~m M~:n~as)
Indicador
:;eir:c::!DC"
Medida
Fcmna de Medir
204
En la elaboracion y division de la ontologia de la medicion del software en subontologias, se han identificado y establecido los conceptos y aspectos mas relevantes
relacionados con la medicion del software y las etapas fundal11entales componen dicho
proceso.
Todo proceso de medicion del software tiene como objetivo fundamental
satisfacer necesidades de info11nacion. Un proceso de medicion no puede obtener
resultados utiles si estos no satisfacen alguna necesidad de info11nacion detectada en la
empresa en la que se lleva a cabo. A pattir de las necesidades de inf01111acion se deben
identificar las entidades y los attibutos de dichas entidades que son candidatos a ser
medidos. Esta patte significativa del proceso de medicion es la que se aborda en la subontologia de caracterizacion y objetivos.
Una vez identificados los attibutos objeto de la medici on, se deben definir las
metlicas necesatias. Para clatificar que elementos generales hay que considerar en la
definicion de las metricas se ha definido la sub-ontologia de las metticas. en la que se
identifican los principales tipos de metricas que se pueden definir. En la definicion general
de una metrica se deben especificar aspectos como la unidad en la que se expresa. la
escala a la que pertenece. el atributo 0 atributos para los que se define. etc.
La definicion de las metricas se debe realizar a distintos niveles 0 alcances. ya
que resultaria excesivamente complejo definir ae forma directa metric as a partir de las
cuales se satisfagan las necesidades de inf01111acion. Por ello. es fundamental definir en
primer lugar metric as que se aplican directamente sobre las caracteristicas de una entidad
para evaluar un dete11ninado atlibuto. A pattir de estas metticas directas se pueden definir
metric as indirectas y finalmente se podrian definir metricas con el objetivo de
proporcionar infonnacion litil para la toma de decisiones, y por 10 tanto. mas cercanas a
satisfacer las necesidades de infonnacion. Estos aspectos se tratan en la sub-ontologia de
las fonnas de medir. en la que se identifican los metodos concretos para definir 0 calcular
las metricas definidas en fimcion de su tipo.
Finalmente se !leva a cabo el proceso de medicion propiamente dicho. a pattir de
la definicion de las metricas y de la caracterizacion de los atributos de las entidades objeto
_':;-RA-\IA
205
206
RA-MA
tratando. Los fenomenos estudiados en este campo implican un ntllnero de variables que
dependen del comportamiento humano y no pueden ser controladas facilmente. No se
debe esperar, por tanto, encontrar leyes cuantitativas que sean validas y aplicables de
modo general, y que tengan la misma precisi6n y exactitud que, por ejemplo, las leyes
fisicas.
Identificacion
Reutilizaci6n
~
Objetivos
...
Hipotesis
.
Objetivos
Requisitos
Metrica Retirada
Acreditacion
r'''''m,"","' j
Creaci6n
Aplicacion
Objetivos
Metricas
Aceptadas
<I
4,
Validacion
Te6rica
...
Validacion Empirica
~-
~,
Aceptacion
Metricas No
Aceptadas
--- .. -- Experimentos
Explicacion PSicologica
Metricas Validas
fRA-MA
207
208
i:':. R:\-\L-\
II
II
<I>
209
Acreditacion. Esta liitima fase del proceso es una etapa dimlmica que persigue
el aseguramiento de la metrica y la mejora continua de la misma, en funcion de
como evoluciona el ent0ll10 de aplicacion, de manera que se puedan seguir
cumpliendo los objetivos que se perseguian al principio del metodo. En
ocasiones el entO!11O puede variar tanto (por ejemplo, pasar de un entorno
estmcturado a uno orientado a objetos) que la metrica no sea aplicable. en este
caso, la metrica deberia ser descartada y el conocimiento adguirido durante su
tiempo de vida deberia realil11entarse a la etapa de identificacion de manera que
podal110s crear una metric a adecuada para el nuevo entO!11O cumpliendo los
objetivos perseguidos. Ademas al utilizar la expeliencia de la utilizacion de la
metrica descartada, se tendran mas probabilidades de fO!111Ular hipotesis
COITectas en la etapa de identificacion.
210
:& RA-iV1A
.,
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 .
.,
RA-MA
211
cada vez mas consistente, dirigidos por objetivos 0 necesidades de informacion que
proporcionan la guia necesaria para la implementacion de la medicion de forma efectiva.
A continuacion se desclibe como se aborda la medicion del software en los distintos
1110delos, estandares y metodos de evaluacion y mejora y se presentan los modelos y
l11etodos mas representativos relacionados con el soporte a la medicion software.
CD
212
213
Alinear las
Actividades de
Analisis de la
Medici6n
Peesonal
Me dici6n de
t..
~y.
Proporcionar
los resultados
de Ja Medici6n
Por 10 tanto. el plimer paso del proceso de medicion es el de identificar los objetivos de la medicion para. en un segundo paso, implementar el proceso de medicion y
analisis. 10 que requiere la integracion de la medicion en los distintos procesos del trabajo
de una organizacion.
PRACTIC\
OBJETIVO
214
1.
2.
3.
4.
215
l11etlicas y expectativas (hipotesis) de las l11ediciones. Cuando se han cOl11pletado todas las
actividades de la medicion, la l11edicion real puede COl11enzar. Durante la fase de
recopilacion de datos se definen, rellenan y almacenan en una base de datos una serie de
fonnularios en los que se obtienen todos los datos de las mediciones. Finall11ente, durante
la fase de interpretacion, las mediciones son utilizadas para responder a las preguntas
fonnuladas, y las respuestas son usadas de nuevo para ver si se han logrado los objetivos
planteados.
Pregunta
Respuesta
Metrica
Medicion
Definicion
Interpretacion
Datos Recopilados
Planificacion
Recopilacion de Datos
2.2.1. PLAl'TIFICACION
Los objetivos principales de esta fase son la recopilacion de toda la infol1nacion
necesaria para un inicio exitoso del proyecto de medicion, as! como la motivacion y
preparacion de los miembros de la organizacion p"ara llevar a cabo el programa de
medicion. EI plan del proyecto constituye el principal entregable de esta fase. en que se
incluyen los documentos, procedimientos, calendarios y objetivos del progral11a de
l11edicion. as! como un plan de fonnacion de los desalTolladores implicados en el
programa. El plan proporciona la base para el fomento y aceptacion del programa de
medici on por paIte de la directiva. Las etapas que componen la fase de planificacion son:
1.
216
E RA-\IA
3.
4.
Crear el plan del proyecto, actividad que se realiza una vez se ha establecido el
equipo del proyecto y se han seleccionado las areas de mejora. Como resultado se
obtiene el plan del proyecto que deberia contener los siguientes elementos:
a.
Q RA-ylA
5.
217
b.
c.
d.
e.
f.
2.2.2. DEFINICION
En esta fase se incluyen las actividades necesarias para definir fOl1nalmente el
programa de medicion y como resultado se obtienen los planes GQM, de medicion y de
amilisis. Las etapas de la fase de definicion son:
Definir los objetivos de la medicion, para 10 que se consideran los objetivos de
mejora del plan del proyecto definidos en la fase anterior. Como resultado se
obtiene una definicion f0l111al y bien estmcturada de los objetivos, para 10 cual se
utilizan plantillas como la que se muesh'a en la tabla 9.2, donde los elementos de
la plantilla son los siguientes:
I.
I>
I>
218
CON EL PROPOSlTO DE
CON RESPECTO A
...
E)I; ELCO)l;TE.UO DE
2.
3.
Realizar entrevistas GQM, de fODna que los miembros del equipo GQM
puedan extraer de los miembros del equipo del proyecto toda la informacion
relevante en relacion a los objetivos de la medicion. Para ello se realizan
entrevistas individuales en las que para facilitar la comunicacion se puede hacer
uso de las hojas de abstraccion ("abstraction sheets "). Las hojas de abstraccion
incluyen los aspectos basicos a considerar en las entrevistas GQM, tales como:
GCl/ales son las metricas para medir el objeto asociado a lin determinado
objetivo, de acuerdo a los miembros del proyecto?, Gcual es el conocimiento
actual del miembro del proyecto respecto a estas metricas?, Gque factores
extern os pueden il?jluenciar las metricas J de que modo?
4.
5.
Revisar preguntas e hipotesis, para asegurar que se han fODnulado las preguntas
e hipotesis COlTectas.
~RA-MA
219
6.
7.
8.
9.
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
220
2.
b.
c.
1\."'.-\1:\
221
a.
b.
Hojas de Analisis M55, que son los distintos tipos de presentaci6n de los
datos obtenidos respecto a diferentes niveles de abstracci6n, que en
orden ascendente son: capa de datos sin procesar, capa de datos
procesados y capa de gn'ificos y diagramas. Cada hoja de analisis debe
incluir: la descripci6n del objetivo y todas las preguntas derivadas del
mismo (como en el plan GQM); todos los datos necesmios para
responder las preguntas planteadas de una fOll11a satisfactoria con
respecto a los objetivos e hip6tesis.
c.
2.2.4. INTERPRETACION
La fase de interpretaci6n utiliza los datos tomados en la medici6n para responder
las preguntas planteadas y de esta fOll11a. para identificar si se alcanzan 0 no los objetivos.
Las etapas incluidas en esta fase son:
I.
2.
3.
222
4.
:9RA-MA
BENEFICroS
I
.1
I
1
BD Relacionales
ase!Wrar
la mantenibilidad
los disefiadores de BD
desarrollo y mantenimiento de BD
1
1
I
1
1
RA.-MA
iii
iii
Pregunta 1:
o
RFK
(T)
NFK (T)
NA (T)
Pregunta 2:
o
224
salvo en el aspecto de que aiiade soporte explicito a los indicadores. Por ello, el artefacto
mas relevante de esta metodologfa es la "Plantilla de Indicadores", que es utilizada para
definir de fonna precisa el "quien", "que", "donde", "cwindo", ''par que" y "como" de un
indicador. asf como para documentar el alineamiento del mismo con los objetivos de la
organizaci6n. Todo ella garantiza disponer de una colecci6n consistente de metricas a la
hora de constmir un indicador y proporciona elementos adicionales para asegurar una
interpretaci6n consistente del propio indicador (Goethelt y Siviy, 2004).
EI proceso que sigue la metodologia GQ(I)M es el propuesto por el SEI en su
enfoque "Goal-Driven Software Measurement" (Park et aI., 1996). La metodologia esta
f0l111ada por diez pasos organizados en tome a h'es conjuntos generales de actividades
(Park et aI., 1996: Zubrow, 1998):
Paso
I
Modelo Mental
Objetivos de
Negocio
c"""
EI Proceso
Paso
C"C"".
<1
Enlidades
;... Entidades
Paso
"V~
Entidades
y
Pa~o
SubObielivos
p
"v~
Atributos
Paso
P'"
Objetivos de
Medici6n
01
"V~
Atributos
"v~
Atributos
02
R.-\-?v1:\
225
b.
c.
d.
Paso 4. Identijicar las entidades y atriblltos relacionados COil los sllbobjetivos. En este paso se utilizan las preguntas para refinar el modelo
mental del proceso y sus entidades y atributos asociados. Esto pennite
establecer un conjunto bien definido de objetivos de negocio que son
utilizados para el ananque del proceso GQ(I)M propial11ente dicho. Este
paso cOl11ienza seleccionando las prt3guntas que se consideran relevantes
y que sue len estar asociadas con los subobjetivos de mayor prioridad.
Una vez que se tiene una lista de preguntas es necesario identificar las
entidades implicadas y sus atributos. La cuantificaci6n de estos atributos
debe pel111itir obtener respuestas a las preguntas planteadas. Este paso es
iterativo 10 que puede conducir al refinamiento de las cuestiones y
subobjetivos a medida que se l11ejora el esbozo 0 esquema mental del
proceso.
e.
226
lndicadores de progreso. Estos indicadores se utilizan para realizar el seguimiento del progreso en la ejecucion de las tareas definidas. POI' ejemplo, las tecnicas de "Valor Anadido" (earned vallie) 0 los diagramas de Gantt penniten construir buenos indicadores de este tipo. El cumplimiento de los val ores de este tipo de indicador significani que la ejecucion de las tare as se esta lievando a
cabo con exito pero no garantiza la consecucion de los objetivos
de negocio aunque un falio en este indicador puede significar un
problema impottante para conseguir dichos objetivos.
R./\.-MA
227
Un indicador que representa el nillnero y tipo de defectos detectado en cada fase del desarrollo es un ejemplo de este tipo de indicadores.
b.
c.
Objetivos de
01
Medici6n
02
Objetivos
:'\cgocio- SubObjcti\"os - \ledici6n
Preguntas
..
<&
P1
P2
A
11
Paso
P:<!fl.::l''::'~
P2
Prcguntas
Paso
MtHricas
14
13
lndicadorcs
~
M2
1! ..
M3
Paso
Listas de Comprobaci6n
Definicion de .\Ictricas
Definfciones
<\
12
Indicadores
-e
M1
PlantilIu de Definicion
de Indicadorcs
(Ji'I:.::i;(1
)(
3.
228
a.
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.
RA-M.-'..
(!)
(!)
(!)
(!)
(!)
(!)
(!)
(!)
(!)
229
230
PSM prop one un Modelo de Procesos de Medida (figura 9.10) que se divide en
cuatro actividades principales:
I.
2.
3.
4.
PROCESOS TECNICOS Y DE
GESTION
Analisis de
Resultados
Objetivos y
Tareas
Establecer y
Mantener el
compromiso de
medici6n
.......
.. Planificar el
..
proceso
Plan de Medida
.. Realizar las
mediciones
Nuevas Tareas
Analisis de
Resultados y
de la Realizacion de
la Medida
Acciones de Mejora
Evaluaci6n
Ambito de PSM
\;': RA.-MA
231
Constructor de Medicion
Atributo
Medida
Base
Medida
Derivada
Indicador
.........fIi>- Producto de
Informacion
232
I)
I)
I)
I)
Detectar anomalias
I)
I)
I)
problemas en el sistema.
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
I.
2.
3.
4.
233
a.
b.
c.
d.
e.
f.
a.
b.
c.
Analisis de los Resultados de las iVIetricas del Software. Paso compuesto por:
a.
b.
c.
d.
a.
b.
c.
Procedimiento de yalidaci6n.
d.
Requisitos adicionales.
234
:,:
5.
a.
b.
c.
Procedimiento de validacion.
d.
Requisitos adicionales.
RA-\1A
235
Productos
Informativos
Rea/imentacion
de los usuarios
v
Establecer y
Mantener el
compromiso de
medici6n
::
Compromiso
Planificar el
proceso
Evaluaci6n
p!anfr7cacfon
Ambito de ISO/lEG
15939
Productos
fnformativos
y
Resultados de
f.1edidas
<I
<I
Productos Informativos
}' Resultados de eva/uacian
acc/ones de majora
236
ACTIVlDAI)
Establecer y Mantener el
Compromiso de Medicion
EYalllar la Medicion
TAREAS
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.
237
Metricas de Proceso
Metricas de
Producto
Metricas de
Producto
238
De acuerdo a Pressman (2002) las metric as del proceso de software se utilizan para
prop6sitos estrategicos y en muchas propuestas, la medici6n del proceso se realiza
extrayendo las caracteristicas de tareas especificas de la ingenieria de software y
obteniendo como resultados metlicas sobre los en'ores detectados antes de la entrega del
software, defectos detectados e infol111ados por los usuarios finales, productos de trabajo
entregados, el esfuerzo humano y tiempo consumido, ajuste con la planificaci6n, etc. Por
ello, en la bibliografia, el enfoque de medici6n del proceso se ha centrado en recopilar una
selie de meuicas de todos los proyectos y durante un largo peliodo de tiempo con el
objetivo es proporcionar indicadores que lleven a mejoras de los procesos software a lar'go
plazo. En este senti do un area clave de investigaci6n es el control estadistico de procesos
(Florac y Carleton, 1999).
Otro posible enfoque de l11edici6n del proceso es a nivel conceptual, ya que es
posible que la complejidad u oU'as caracteristicas de calidad del modelo puedan afectar a
su ejecuci6n (enactment) y por consiguiente a la calidad de los productos finales
obtenidos. En este aspecto se pueden encontrar algunos estudios de para evaluar la
mantenibilidad de los modelos de procesos software (Garcia, 2004; Canfora et al., 2005).
!': RA-MA
239
2,)0
1': R.-\-\L-\
(". R.>\-\IA
2-11
2.+2
: R,\-;vIA
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
~l
~12'
III
+~12.
log2
(~12)
~RA-MA
2.+3
24-1
' R.Vv!A
RA-\!A
2.+5
del disefio de un producto software. Estos autores clasificaron las metncas en:
metricas de tamai'io, metric as de herencia y metricas de caracteristicas intemas de las
clases. En la tabla 9.7 se muestran aquellas metricas que pueden aplicarse a un disefio
de alto nive!.
NOMBRE
\IHF
AHF
\IlF
AIF
PF
""
DEFINICIOr;
s RA-\,L-\
NmIBRE
PI:\I
NI:\I
\IETRIC-\S DE
TA:\IA:\O
NIY
NOI
N\,'
N\IO
N\II
N\IA
\IETRlC.-\S DE
HERE"CIA
SIX
\IETRICAS DE
CAR-\CTERisTIc.-\s
I"TER"AS DE LAS
CLASES
APP:\-I
DEFE\ICIO:-;
I
EI Nllll1ero de Metodos de Instancia Pl1blicos de una clase es el
nllll1erO total de metodos Pl1blicos de instancias. Los metodos Pl1blicos
son aquellos que estan disponibles como servicios para otras clases.
EI Nl1111ero de ~letodos de Instancia es la suma de todos los metodos
de una clase. considerando tanto los metodos Pl1blicos como los
protegidos y pri\"ados"
EI 0."l1111ero de Variables de Instancia es el nllll1erO total de variables a
nivel de instancia que tiene una clase. considerando las \"ariables
privadas y protegidas disponibles en una clase.
EIl\lunero de i\letodos de Clase es el nlllnero total de l11<?todos a niwl
de c1ase. !lor ejemplo. aquellos metodos que son globales a todas las
instancias que tiene una clase.
EI 0."llmero de variables de Clase es elnllll1erO total de variables a
nivel de clase que tiene una clase.
EI 0."llll1ero dc Metodos Sobrecargados es el nl1111ero tOlal de l11i?todos
sobrecargados por una subclase.
EIl\llmero de \Ietodos Heredados es elnl1mero total de metodos que
una clase hereda.
EI 0."llmero de ~'Ietodos Afiadidos es elnlllnero total de metodos que
se detlnen en una subclase. Esta metrica se dctlnio para mediI' la
cali dad del uso de la herencia. ya que examina la relacion de herencia
entre subclases y superclases.
EI indice de Especializacion para cada c1ase se detlne asi:
.\zimerode.\/elodosSohrees('}"iloS * .\"i,elde.~llidamiellloEIILaJeranfzli'l
.\"zimero TOlalDe.\/elOdos
It-\-MA
247
METRlCAS
:\Assoc
:\AGG
:\DEP
:\GE:\
:\AGGH
:\GE:\H
;\IAxDIT
;\L-\xHAGG
DEFJ;,\IClO;,\
2.+8
f R.-\-\lA
c R.-\-:'IA
249
Tracing
ChlllZkillg
GI1IPO I
Chzll1king
Grupo 2
ICAR~CTERfSTICAS
CO:\W,\,ES DEL
GRDPO DE CO,\,CEPTOS DCL
250
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.
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
iii
iii
iii
~ RA-MA
CI
251
Entrada:
---------
---------
----------
Archivo Externo:
1. Documento que se ha de revisar
Usuario
Consulta:
1. l.Cuantas palabras
se lIevan procesadas?
Comprobador
Ortografico
Salida:
1. Numero total de palabras revisadas
2. Numero total de errores detectados
3. Lista de palabras con errores ortograficos
Archivo Interno:
1. Diccionario
_ _ _ _ _ _ _CmWLEJIDAD .
ELEME"'TO . . . . ~
.... El\'TRADASExTER'<AS
....
."
..
BAJA
.MEDIA
3
4
3
7
5
5
4
10
7
7
6
15
10
252
3.
4.
5.
6.
7.
~ RA.-MA
253
8.
9.
10. Reusabilidad: indica si gran parte de la fUl1cionalidad del proyecto, esta pens ada
para un uso intensivo por otras aplicaciones.
11. Facilidad de instalacion: un valor de 5 denota que la instalacion del sistema es
tan importante que requiere un esfuerzo especial para desaIToliar el software
necesmio para realizarla.
12. Facilidad operacional: un valor de 5 indica que el sistema realiza pccas
operaciones.
13. Adaptabilidad: una puntuacion maxima indicaria que e1 sistema se ha disei'iado
para sopOliar mtlltiples instalaciones en diferentes entornos y organizaciones.
14. Versatilidad: detel111ina si la aplicacion se ha realizado para facilitar los cambios
y para ser utilizada por el usuario.
El valor del factor de cOlTeccion tecnica se obtiene:
254
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:
255
EI
EI
EI
EI
256
5. lECTURAS RECOMENDADAS
(l)
(l)
(l)
(l)
(l)
COSMIC
(Common
Software
Sitio de
7. EJERCICIOS
I.
LCF (lineas de codigo fuente escritas). que se puede obtener contando las
lineas utilizando como instrumento una heITamienta CASE.
b.
c.
RA.-:'!A
257
d.
e.
g.
h.
I!.
111.
IV.
v.
1.
2.
3.
258
4.
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
Calidad de la
Informaci6n
~~
Cali dad de la Base de Datos
Calidad de la Presentaci6n
~ ~
Calidad del SGBD
Calidad del
Modelo
Conceptual
Calidad del
Modelo de Datos
Calidad de los
Datos
Calidad del
Modelo L6gico
Calidad del
Modelo Fisico
RA,-\lA
261
de calidad de datos de los usuarios: asi como de los procedimientos y procesos de mejora
de la c:tlidad de datos existentes en la organizacion.
En este capihIlo se mostrani como se puede analizar y eshldiar la calidad del
modelo de datos. de los propios datos y de la infol111acion que gestionan las empresas.
PROPIEDADES
262
imposibles de
Una estrategia mas adecuada para abordar la calidad es definir marcos de referencia
que organicen y estmcturen los conceptos claves y caracteristicas en el modelado
conceptual de datos. Ademas, se han publicado algunos marcos de referencia que
penni ten abordar la calidad en el model ado conceptual de una manera mas sistematica.
Aunque estos marcos son relevantes en el senti do de que contribuyen a un mejor
entendimiento sobre el h'atamiento de la calidad de los modelos conceptuales, carecen de
medidas cuantitativas que pennitan evaluar la calidad de los modelos conceptuales de
datos de fonna objetiva. Resulta evidente que definir solo "propiedades deseables" no es
suficiente para evaluar la calidad, ya que diferentes personas pueden dar diferentes
interpretaciones sobre el mismo concepto, por 10 que es necesario contar con medidas que
pennitan evaluar la calidad de los modelos conceptuales de datos de fonna cuantitativa y
objetiva, evitando as! los sesgos en el proceso de evaluacion de su calidad.
A continuacion se resumen algunos de estos marcos de referencia para la mejora de
la cali dad de datos del modele conceptual.
<;: Ri\-MA
<I>
<I>
263
CALIDAD
SEMANTICA
CALI DAD
SINTACTICA
DOMINIO
...:.:.J-' -
CALIDAD
SEMANTICA
PERCIBIDA
""
CONOCIMIENTO
DEL PARTICIPANTE
..
LENGUAJE
tt PRAGj\lL~
CALIDAD
TICA
CALIDAD
SOCIAL
INTERPRETACION
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.
En este marco se prop one distinguir varios tipos de calidad:
<I>
<I>
<I>
<I>
264
TIPOS DE CAUDAD
SINT..tCTICA
OBJETfVOS
MEDIOS
I PROPIEDADES :'IlODELO
I COlTeccion sintactica
Sintaxis fOTInul
ACTIHDADES
Verif Sinl<\ctica
Verif Consistencia
Validez \-iable
Semantica fOTInal
Complccion viable
Moditicabilidad
Insercion sentencias
SE\L-l,\'TJCA
BOlTado sentencias
Insercion sentencias
SE\lA?\'TICA
BOlTado sentencias
PERCIBIDA
Entrenamiento
Economia .;xpr.;si\-a
Inspeccion
\-isualizacion
I
II
I
Estetica
PRAGXIATICA
Comprension \-iablc
I
I
I
II
I
I
i
I
I
Ejecutabilidad
Acuerdo \-iable
Filtrado
Presentacion diag_
Paratl-ascar
I
I
I
Explicacion
Entrenamiento
contlicto
I
II
Ejecucion
Simulacion
~[odelado
Animacioll
SOCL-l.:L
I
I
Resolucion cont1icto
I
I
II
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.
265
STAKEHOLDER
l\rIODELO
-,-~r
METODODE
EVALUACION
FACTOR D E .....
4.II1----iii!ilt>ilO>
CALIDAD
VALORACION
ESTRATEGIA DE MEJORA
Figura 10.3. Elementos del Marco de Moody y Shanks (1994).
o
Peso: que sirve para definir la importancia relativa de los factores de calidad.
utilizacion
En la revision de este marco (Moody et aI., 1998), se prop on en los ocho factores de
calidad que aparecen enla figura 10.4.
Para Moody estos factores significan:
266
iRA-MA
Integridad: grado en el que las reglas del negocio que se aplican a los datos
estc'm definidas en el esquema conceptual.
usuano
usuano
usuano
usuano
MODELO
DECALIDAD I'
analista
analista
admin.
datos
desan'ollador
(; RA-?vL'\
267
del esquema), mientras que otros resultan de la puntuaci6n subjetiva de los implicados en
el disefio (vease tabla 10.4).
...
z;.;J
:::::
"2
0
""
==
a
g
"~
Ci5
..
...
I
;:
u
:::;
2:
'~
-9
<:::)
...l
::<
~
r_
I..i
;;;:
:3
~
==
-:::
.:::::
c;
;;::
.. , .. COMPRE\'iSIBILIDAD
'.
Sln'iPL'(CID.W
..
FlEXIBILJDAD
COMPLEtION
l;\fPLE;\IEi\TABrLID,W
I:\TEGRIDAD
FACTOR DE CALIDAD
CmIPLECIO:-;
I:-;TEGRIDAD
FLEXIBILIDAD
CO:\IPRE:\SIBILIDAD
CORRECCI6:-;
SnlPLICIDAD
I:-;TEGRACI6:-;
hIPLDIE:\TABILIDAD
METRICAS
Tabla 10.4. iVIetricas para evaluar la calidad de modelos E/R (Moody, 1998)
268
YALORES !h':-------B~
___-"I
'pun,".
~IETODO
DE
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 oto. Este marco
integra do puede aplicarse en cualquier etapa del proceso de modelado conceptual, y tiene
en cuenta el concepto de calidad tanto en el modelado del producto como en el proceso de
modelado delmismo.
LRA-MA
269
II
II
II
Y entre los facto res que influyen en la calidad del contenido, se tienen:
II
II
II
Cohesi6n: se refiere a la cercania que existe entre los atJ.ibutos de una entidad.
Compleci6n: se refiere a que todos los atlibutos que sean relevantes deb en ser
incluidos.
Validez: se refiere a que los a1:J.ibutos sean conectamente asignados a las
entidades.
Como muestra la figura 10.6, existe una fuerte relaci6n en1:J.e la es1:J.uctura y el
contenido. Para obtener un modelo EIR de buena calidad, es necesario evaluar la calidad
tanto del contenido como de la estructura. Los componentes ontol6gicos, la es1:J.uctura y el
contenido, detenninan el compOltamiento del sistema.
Factores que influyen en la calidad del comportamiento:
II
II
II
270
It
RA-!v1A
La tabla 10.5 muestra como los factores ontol6gicos afectan a los factores de
comportamiento.
AderTI<ls Kesh (1995) prop one una metodologia y metricas para evaluar la calidad
de los modelos EIR que detallamos a continuaci6n.
Una vez construido un modelo EIR se. debe evaluar su calidad utilizando la
siguiente metodologia:
1.
2.
3.
<';RiI.-MA
4.
..
..
271
USABILIDAD
1USUAlUO ....
USABILlDtill
DISEl'/ADOR
j\h.!"lTENF
BILlDAD
IJ>REbSIONIRENl)~nE~tO
....
Adecuaci6n al
X
problema
"'.:;.".< ......
.~~u.,,~"~w
:>
: ..
....
,..;;
i..
Validez
Consistencia
Concisi6n
Compleci6n
....
.
X
X
Cohesi6n
Validez
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.
272
EiI
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.
La arquitectura GoM, que es un marco estructural en el cual son ubicados
cada uno de los componentes de esta guia.
Principio de adecuacion de la
construccion
I
Principio de adecuacion dellenguaje
Principio de claridad
OBJETlVOS
Principio de comparabilidad
II
I
I
I
[ R.-'I.-MA
273
NE
NA
NTIA
NCA
NMVA
NN"R
NM:NR
I Nl:NR
NBinaryR
NN-AryR
NIS AR
NretR
NRR
DEFE\l.CION
.'
274
:9 RA-1vLA-
Seglin la ISO 9126, tres de los factores que influyen en la mantenibilidad son la
analizabilidad, la cambiabilidad y la facilidad de prueba, los cuales a su vez, seglin Li y
Cheng (1987) estan influenciados por la complejidad. Henderson-Sellers (1996) divide la
complejidad en tres: complejidad computacional, complejidad psicol6gica y complejidad
representacional, y para la psicol6gica define tres componentes: complejidad del
problema, factores cognitivos humanos y complejidad del producto. A su vez, las metricas
de producto pueden ser divididas en intra-modulares e inter-modulares (Kitchenham y
Linkman, 1990). En la complejidad del producto, tanto inteilliodular como intramodular
es en la que se ha centrado el trabajo del grupo Alarcos.
Por tanto, el objetivo fundamental fue disefiar metric as de producto (que capturen
las caracteristicas especificas de los diferentes tipos de bases de datos) que nos pennitan
medir la complejidad de las bases de datos, a traves de 10 cual estaremos tambien
rnidiendo la calidad de las mismas.
Concretamente, centraremos el estudio en las bases de datos relacionales, activas,
objeto-relacionales y multidimensionales (almacenes de datos).
.METRICA
Numero de
Atributos de una
Tabla
Numerode
Claves Ajenas
NOTACION
NFK(T),
Number of Foreign
Keys
DRT(T),
Depth of the
Referential Tree.
Ratio de Claves
Ajenas de una
Tabla
RFK(T),
Ratio ofForeign Key
Numero de
Tablas.
NT,
Number of Tables
Cohesion del
Esquema.
Ratio de
Normalidad.
Numerode
Atributos.
Numero de
Claves Ajenas
I ..
NA(T),
Number of Attributes
Profundidad del
Arbol
Referencial de
una Tabla
COS,
Cohesion of the
Schema
NR.
Nonnality Ratio
NA,
Number of
Attributes
NFK.
Number of Foreign
Keys
275
(T)
= N~K
(T)
iVA (T)
cos = INTr;s,
definida como la relacion entre el numero de tab las en tercera
fom1a nonnal (0 superior) entre el numero total de tablas
NR= NT3NF
NT
Siendo NT31\Tf es el numero de tab las en 3NF
definida como el numero total de atributos que hay en el esquema
ST
NA =
L: NA(I;)
i=1
NFK
= INFK(I;)
i=l
Profundidad del
Arbol
Referencial
DRT,
Depth of the
Referential Tree
DRT
Ratio de Claves
Ajenas
RFK.
Ratio of Foreign
Key
= max;~ (DRT(T;))
276
NU\IEROD
INT
NOT NULL.
LUGARD
VARCHAR(l5)
NOT NULL.
PRll\IAR'{ KEY (NU?vIEROD. LUGARD).
FOREIGN KEY (NU\IEROD) REFERENCES
DEPARTAMENTO (PiU;VIEROD) ON DELETE
CASCADE O?\ UPDATE CASCADE):
NO\1BREPR
V.--\RCHAR( 15)
NOT NUL.
?\lI\1EROPR
INT
NOT l\ULL.
LUGARPR
VARCHAR(I5).
l\U\1D
I?\T
NOT PiULL.
PRIMARY KEY (l\U\lEROPJ.
UNIQUE (NOMBREP).
FOREIG?\ KEY (NU\ID) REFERENCES
DEPART.-\\IENTO (({U;YIEROD)):
CREATE TABLE TR-\BAJA_E:\
(
NO\IBRED
VARCHAR(l5)
NOTl'\uLL.
NU\IEROD
INT
NOT NULL.
PiSSGTE
CHAR(9)
NOT ?\ULL.
FECHAINICGTE DATE.
CONSTRAINT CLPDEPTO PRI\lARY KEY
(NUMEROD).
CO'\STRAIl\T CLSDEPTO UNIQUEC";OMBRED).
CONSTRAINT CLEGTEDEPTO FOREIGN KE'{
(NSSGTE) REFERENCES EMPLEADO(NSSJ ON
DELETE SET DEF.--\UL T ON UPDATE CASCADE):
PiOTNULL.
NSSE
CHAR(9)
NUMP
Il\T
l\OT1\'UL.
HORAS
DECEvL-\L(3.I)
NOT?\ULL.
PRI\!:-\RY KEY (({SSE. ({UMP).
FOREIGN KEY (NSSE) REFERENCES E;YIPLEADO
(({SS).
FOREIGN KE'{ (({U\IP) REFERENCES PROYECTO
(({UMEROP)):
CREATE T.-\BLE DEPE:\DIE:\TE
(
NSSE
CHAR(9)
NOT l\UL
NO\1BRE DEPEND VARCHAR(l5) 1\'OT l\UL.
SEXO
CHAR.
FECHAAl\
DATE.
RELACIOl\
VARCHAR(8).
PRl;vL-\RY KEY (i'iSSE.l\O?vIBRE_DEPEPiD).
FOREiGPi KEY (NSSE) REFEREPiCES EMPLE.-\DO
(NSS)):
[ R/\-:vIA
DE LA INFOR.\L-\CIO",
CAPiTULO 10:
NA(f)
l\TK(T)
DRT(T)
RFK(T)
E:'>IPLEADO
10
::
I /~
DEPARTA:'>IE:-iTO
.)
l/4
LCGARES DEPTS
::
.:I
li2
PROYECTO
.:I
114
TR-\BAJA E:-i
2/3
DEPE:-iDlE:-iTE
.:I
1/5
ESQCDIA
277
COS
NR
NA
NFK
DRT
RFK
36
217
Trabaja_En
Empleado
""""
"'I"
Dependiente
t+
Departamento
A1
~ii'
-+
Proyecto
Lugares_Depts
LL
I
I
278
RA,1-.IA
Instalaci6n
Producci6n
CodProducto
NombreProducto
Receta
ConGas
Oesnatado
UnidadProduccion
GestorProducci6n
1"-"-'- '"
1-
Ingrediente
Codlngrediente
Nombrelngrediente
Proveedor
Forma
UnidadMedida
Codlnstalacion
Nombrelnstalacion
Localizacionlnstalaci6n
HechosProducci6n
l~--/~ ----~-------- Gestorlnstalaci6n
Estado
CodEjecuci6nProducci6n
CodProducci6n
Codlnstalaci6n
Momenta
CodMomento
CodMomento
CantidadProduccion
- Fecha
NombreMes
Usolngrediente
NumeroMes
Ano
CodProduccion
1-Temporada
Codlnstalaci6n
CodEjecuci6nProduccion
CodMomento
Ejecuci6nProduccion
Codlngrediente
Temporada
CodEjecuci6nProducci6n
CosteTotal
NombreProducci6n
LineaProducci6n
CapacidadMensualLineaProduccion
UnidadMedidaCapacidad
--
~---
I
Figura 10.9. Ejemplo de un almacen de datos (Adamson y Venerable, 1998)
DESCRIPCION
]\iA(T)
0:FK(T)
Ejecucion
Hechos
Uso
Produccion
Produce ion
Ingredientes
NA(T)
NFK(T)
279
DESCRlPCIO:-;
NOT(S)
NT(S)
NAOT(S)
NAFT(S)
NA(S)
?\FK(S)
RFK(S)
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.
METRIC-\.
I
I
I HECHOSPRODt:CCIO:-; J
I USOI:sGREDIE:-;TE I
NA
28
35
NFK
--+
I
I
I
RSA
23;5
287
NOT
--+
I
I
I
NT
5
6
I
I
I
NAOT
7'
_J
28
I
I
I
NAFT
5
7
RFK
4/28
5/35
280
~a
~~~
NFT(Sc)
r-----~~~~----,r------------------------~~==~~~~--------------------_J
NDT(Sc)
NSDT(Sc)
NT(Sc)
NAFT(Sc)
NADT(Sc)
NASDT(Sc)
NA(Sc)
NFK(Sc)
I
I
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
RFK(Sc)
Ratio de atributos de las tab las dimensionales compartidas. NllIl1ero de atributos del
RSDTA(Sc)
esquema que son compartidos
METRIC\
VALOR
METRICA
VALOR
NA
40
NAFT
NFK
RFK
METRIC.",
VALOR
12
RSDT
45
940
RT
NFT
')
I
I
I
5.~2
NDT
NT
NSDT
I
I
NADT
28
NASDT
-.)
"
RScA
RSDTA
I
:
2812
23140
\: R..-\-\!A
281
3. CAUDAD DE DATOS
Una vez que se ha eShldiado la cali dad de los modelos de datos y como medirlo. se
atl-onta ahora el hecho de medir la calidad de los propios datos almacenados en la base de
datos. Para empezar es necesario definir el concepto de calidad de los propios datos. En la
literahlra se intenta definir este concepto en nmcion de unos deter111inados criterios. como
pueden ser el ciclo de vida de los datos (Redman, 1996) 0 los tipos de investigacion
realizadas (Huang et al.. 1999, 'Nand y Wang. 1994) 0 simplemente la f01111a en 1a que se
usan los datos (English. 1999). Pero todos los autores estim de acuerdo en que la calidad
de datos es un concepto multidimensional que comprende distintos aspectos seglm las
necesidades de los consumidores de datos 0 de los diseiladores de sistemas.
Una estrategia habitual que se suele utilizar para detel1ninar el grado de cali dad de
datos de una aplicacion es detinir un marco de trabajo para detel111inar las dimensiones de
calidad de datos para un contexto. que puede ser generico 0 bien especia1izado en un area,
y metricas asociadas a esas dimensiones. Las dimensiones de calidad de datos y de
infol111acion son criterios racionales que representan los requisitos de los mediante los
cuales es posible juzgar la cali dad de un dato. Estas a su \ez pueden dividirse en otras que
complementen su significado (ISO. 2001). Es posible llegar a necesitar un conjunto de
varias dimensiones para detinir el estado de la cali dad de datos y de informacion en una
detel111inado aplicacion (Huang et al.. 1999).
EI problema radica en la diticultad para identiticar las dimensiones de calidad para
cada uno de estos componentes. Muchos aLltores como Redman (1996). English ( 1999).
Strong et ai. (1997a) han explicado como identiticar estas dimensiones de calidad de
datos e incluso como medir ciertos aspectos caracteristicos de calidad de datos en ciertas
aplicaciones y entomos. Redman (1996) explica un procedimiento mediante el cual es
posible obtener las dimensiones de calidad de datos a partir de los requisitos de calidad de
datos de los usuarios y de la cadena de intol111acion: se retmen los requisitos de cali dad de
datos de los usuarios y se catalogan. identiticando adecuadamente las necesidades y
preferencias de todos los usuarios para posteri0l111ente intentar compatibilizarlas. Despues
de haberlas catalogado se escriben de f0I111a que los disei'iadores puedan ar'iadirlas a las
especiticaciones del sistema. teniendo en cuenta su detinicion y como afectan a los datos
existentes. Por ttltimo, se comprueba la validez de la dimension elegida. Este proceso es
iterativo hasta obtener un conjunto consistente de dimensiones de calidad de datos. Por
otro lado. Strong et al. (1997b) proponen LIl10S procedimientos de identiticacion de
dimensiones de calidad datos consistentes en aislar problemas frecuentes con los datos.
Muchas de estas metodologias de eleccion de dimensiones de calidad de datos
llevan aparejada la definicion de un conjunto de dimensiones por parte del autor que
sirven como referencia para su aplicacion. La e\'aluacion de estos marcos rev-ela con
demasiada tiecuencia que los marcos de referencia han sido definidos para un dominio.
con 10 que son nlertemente dependientes del contexto (Eppler. 2001 a). As! es posible
encontrar un catalogo de dimensiones de calidad para entomos medicos (Kosar. 1999:
282
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
Intrinsecas
Accesibilidad
Contextual
Cantidad de Datos
Interpretabilidad. Facilidad de entendimiento, Representaci6n
Representacional
Concisa. Representaci6n Consistente
De todos modos, es posible que este esquema no satisfaga con-ectamente todas las
necesidades de los usuarios (Eppler, 2003), y se podlia pretender desan-ollar un modele de
referencia universal valido para cualquier situaci6n, pero como afiTInan Pipino et af.
(2002) esto es imposible debido al hecho de que la calidad de datos y de infomlaci6n
depende fueltemente de los problemas particulares que las organizaciones tienen con sus
datos y su infoTIl1aci6n.
Otro de los problemas que se puede encontrar a la hora de definir el catalogo de
dimensiones es la cantidad de factores que pueden afectar a dicha dimension. Uno de los
casos mas impOltantes es el rol de la persona que va a utilizar el recurso cuya dimensi6n
de calidad de datos y de infoTInacion se pretende definir (Gialmocaro et aI., 1999).
Sea cual sea el metodo de elecci6n de las dimensiones, y los factores que
condicionan la elecci6n de las climensiones, el numero de las elegidas que fOTIl1aran este
conjunto debe ser 6ptimo y minimo: optimo para que represente convenientemente la
calidad de datos en la base de datos y minimo para evitar el gasto imlecesario de recursos
y la complejidad computacional.
Como se sabe, la calidad de un producto depende del proceso mediante el cual se
disena y produce el producto, as! que la cali dad de los datos estara relacionada con el
proceso de captura, de diseno, 0 de utilizaci6n de los mismos. En Wand y Wang (1996) se
GRA.-MA
283
analizan algunas de las causas de la mala calidad de los datos debida a deficiencias en
disefio basandose en principios onto16gicos, vease tabla 10.17. De todos modos, hay que
tener en cuenta, desde un punto de vista practico, que las mayores deficiencias en la
calidad de los datos provienen de su no utilizaci6n. Al igual que pasa con los miembros y
6rganos del cuerpo humano, los datos que no se utilizan tenninan "atrofiandose", y su
calidad se deteriora (On, 1998).
DIMENSION CALIDADDE
NATUR."-LEZ--\ DEL-\ DEEICIE1\iOA
DATOS
.""
FUENTE DELADEI'1C:!ENCIA
Representacion impropia:
Complecion
Estados SI 2 ausentes
Fallo en el diseiio
Representacion impropia:
No ambigtiedad
Fallo en el diseiio
estado SI
Estados SI sin sentido y confusion: mapeo a
operacion
Fallo en la operacion
Significacion
Correccion
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.
SI = Sistema de Informacion
MR = Mundo Real
28-1
iZ R_-\-\!A
DI"\<IE7\5107\
DEH7\ICI07\
:\ccesibilidad
Cantidad apropiada de datos
C omplecion
Comprenslbilidad
Credibilidad
Disponibilidad temporal
Facilidad de manipulacion
InteIlxetabilidad
Libres de en'or
ObjetiYldad
Releyancia
Reputacicin
Seguriclad
\'alor aiiadido
( RA-\lA
CAPiTCLO
DE L\ I:-;FOR\lACIO?\
285
1.3. Localizar los datos a valorar. Esta actividad se di\'ide en las siguientes
subactividades:
1.3.1. Detenl1inar la cantidad de datos que deben ser \alorados. Se
trataria de decidir si para detenninar la calidad de los datos hay que
tomarlos todos 0 bastaria con tomar una muestra de ellos y luego
extrapolar los resultados.
1.3.2. Localizar los datos en la base de datos. Se pretende indicar ellugar
ex acto don de logica y.o fisicamente estan los datos a valorar.
286
2.1. Que no haya ni siquiera almacen de datos, con 10 que sera necesario disei'iarlo
afiadiendole directamente los aspectos de calidad que se consideren mas
adecuados.
2.2. Que haya almacen de datos pero que no de soporte para los aspectos 0
dimensiones de cali dad. Lo que habra que hacer sera modificar el modelo para
dar el citado soporte.
2.3. Que el almacen de datos ya cuente con estmctura de calidad debido a analisis
realizados anteliol111ente.
En cualquiera de las circunstancias en las que haya que modificar el modelo del
almacen de datos hay que tener presente que se pueden ver afectados todos los procesos
que manejaban esos datos, pOI' 10 que se recomienda tener en cuenta todos esos cambios.
Fase 3: Medicion de los atributos de calidad. Una vez que el almacen de datos disponga
de una estmctura para guar'dar las medidas de las dimensiones de cali dad, esta fase
consiste en reunir valores para dichas medidas en las dimensiones especificadas. Puede
llegar a ser necesario que para algunas dimensiones de calidad se deba conocer el valor
del dato real y compararlo con el del dato almacenado. En funci6n de la cantidad de datos
y del nivel de calidad exigido puede ser necesario mediI' los valores de todos los datos 0
seleccionar pOl' muestreo s6le. una parte de esa totalidad. En cualquier caso estas
medici ones se guardaran en el almacen de datos.
Fase 4: Amllisis y Evaluacion de los valores de los atributos de calidad. En esta fase.
se someteran los valores individuales medidos en la fase anterior a los critelios de
valoraci6n para detel111inar el grado de bondad de un dato, y Segllll elnllmero de datos con
calidad y los criterios de evaluaci6n establecidos se juzgaran si esos datos tienen 0 no el
grado de calidad deseado. Si es as!. se celtifican los datos como validos para la aplicaci6n.
En caso contrario se desechan como invalidos. procediendo posteri0l111ente como mejor
convenga: cOlTecci6n de los datos existentes 0 captura de nuevos datos.
Com') ejemplo de metrica de calidad de datos podria darse la siguiente el Numero
de valores incolTectos para un atributo (1\TVI (A)), entendiendo que un atIibuto es
incolTecto cuando su valor no esta dentro del rango de valores de dominio definido para
ese atributo. En este rango de val ores podria estar 0 no el valor nulo.
287
288
i;; R.-\-\l.-\
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 Alatcos a este campo, se
incluira un marco de evaluaci6n y mejora basado en modelos de madurez. al estilo de
CMM1.
Colllprobal'-Actllal' (Plan-Do-Check-.4.cf;:
I!J
c:
C)
290
!{.A,.-MA.
{;; R/\.-MA
291
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
292
<I>
<I>
<I>
( R.-\-'\L-\
293
Ii)
"
294
@RA.-MA
respecto a sus expectativas sobre el producto. Los ocho pasos de este proceso
son los siguientes:
~ R;\-MA
II
II
Estandarizar Datos.
295
296
RA-\lA
Es un proceso transversal que tiene raices en los cinco procesos anteriores. Los
pasos de este proceso son los siguientes:
o
c;
.:)
297
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.
298
Analisis de costelbeneficio. Los niveles de calidad exigidos por los requisitos de calidad de infOlmaci6n garantizan una serie de beneficios organizacionales. EI objetivo de esta actividad es encontrar un equilibrio entre costes
y beneficios.
3.
Planificacion del Proyecto tecnico. Define un plan para el proyecto tecnico que
pennite implementar las estrategias propuestas. Debe tener en cuenta todos los requisitos tecnicos derivados de la planificacion estrategica. Algunos de los elementos
mas relevantes del entomo son los siguientes: requisitos tecnicos detenninados por el
analisis de la estrategia y por los patrones de mejora de calidad.
4.
5.
Deberia habilitar un modo de analizar esos problemas con mas detalle y rigor y
detem1inar sus CclUsas potenciales.
R.'\-yl.-'..
299
IDE:-;T1FICICle):"\
I.
PRI:<OCIPI
'.'
,-
. ....
hFOlnIACIO:-;
RELEVA:-;TE
hFOR'LICIO'i
BLT';A
PROCESO
Onnlll.IDO
I'iFRAESTRLCTL'RA
FLIBLE
hTEGILICIO:-;
I
II
CO'IPRE:-;SIVO
CO:"\ClSA /
YALID.\CIO:<o
EXACTO
""
II
I
LOCALlZACIO:"\
ApUCACIO:-;
CO:<OTEXTO
ACTIYACIO:-;
CO'iv['ilE'iTE
ACCESIBLE
I
I
OPORrr'iO
SEGrRA
I}
I
I
I
f~ ~IL SEGll'll['iTO
'IA'iT['ilBLE
I
I
'"
":0:-
-:
ACTCIL
I/CORRECTO
I
I
,IPLICABLE
CLARO
~TE
II
"C.
!'iTER ICHI I
R \PlD \
:}
"
~
[
'"
-'.
~
~
300
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).
[DE'iTIFICACIO'i
EVALL\CIO'i
EJ~jl{iciall1it...>l1fo
I..: fa
! E,',,/w.1L.'ifJn
dr.'
CO!1h!rsilm Lk{formalO de
la dc{/{alidad
la COl1sislt!!1cia.
Comparacicjn cull olras.!Uf.:'/1-
LOC\UZACIO'i
l'dt!
les
b~f;}nJlt.lcic)!1
Etrt!,,-,"i!JI1 y t.'l1riLjuecimi:..'f1!O
de
/,1 ilUcJ}"macicin
'-\PLlCACIO'i
/11lt..'ruccit;n con /0
Ohl..:m:i()n
clL' conell/siones d
portir dt.' la
il~t()f"mach)n.
L ",ili::acj(jn de fa iJ~t(),.maci61I
para id rt.' ...ofllchJn cit}
proh/ellIus.
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
G R.".-MA
301
<i>
<i>
<i>
<i>
302
:f;
R.-\-?vlA
1979) 0 ser adecuado para su uso (Juran, 1988). Esto justifica la existencia de los procesos
"velticales" de gesti6n de calidad que puede afectar a varios procesos "horizontales" de
producci6n.
Es necesario articular alglll1 razonamiento para englobar y enlazar todas estas ideas
y conceptos. Si se busca una analogia con la definici6n de Proceso Software dada par
Fuggetta (2000)5. y teniendo en cuenta que la calidad de cualquier producto no puede ser
asegurada simplemente inspeccionando el producto 0 realizando meros controles
estadisticos. se podria !legar a pensar que una buena aproximaci6n a la gesti6n de la
calidad de los datos y de la infol111aci6n en las organizaciones podria ser definir un
Proceso Software de Gestion de Informacion (PGI). en e1 que se detlniera quien esta
haciendo que. cuando. que recursos se usan y c6mo se gestiona 1a calidad tanto de los
productos que se generan como de los recursos que se usan. Esta bip6tesis esta respa1dada
por McLeod (1990) que explica que todo proceso software esta formado por dos
subprocesos: uno de producci6n propiamente dicho y otro de gesti6n que incide en el de
producci6n para controlarlo y que la ejecuci6n 0 no de alguna de las acti\idades del
subproceso de gesti6n incide directamente en la calidad del producto de datos que se
desarrolla.
Esto habilita la evaluaci6n y mejora de la calidad de 121 informaci6n a tra\es de 11
e\'aluaci6n y la mejora de un proceso software encargado de la gesti6n de 11 informaci6n.
Aunque existen \arios marcos de trabajo para la e\aluaci6n y 11 mejora de los procesos
so1"\\\are. como Cv['vlI 0 ISOIEC 1:5:504. ninguno de ellos se centra en 11 calidad de los
datos y de 11 informaci6n.
Para conseguir evaluar y mejorar la calidad de datos \' de infol111aci6n en una
organizaci6n y teniendo el concepto de PGI como concepto mticulador de esta propuesta.
se han definido en el marco dos componentes principales:
Ln Modelo de calidad basado en Gesti6n de Calidad de los datos y de la
Informaci6n estructurado en 1\iveles de Yladurez. llamado C-\LDEA. 211 estilo
de Cv1YII y ISOIEC 1:5504. donde se establecen distintas Areas Clave de
Proeesos (ACP) con actividades de .caracter tanto tecnico como de gesti6n.
Para caela ACP. y en aras de conseguir un marco de trabajo 10 mas universal
6
posible. se proponen algunas hel1'amientas. teenicas. estandares. tareas v
'Proccso So/ilmre eS lIil COlljUll1O cohereille de po/ilicas, eSll"/iCll!raS orgulli::aciolla/es, leci/%gias, procedimielllos ,1' urlejilcl()S 'jue SOil necesarios para concebi/', desarrollul', ills/a/ar ,1' liIWilcner
1111
,. Al estilo de las pnicticas de C\[M y Ci\[ivU pero utilizando la tenl1inologia de Metrica \'.3
RA-MA
303
metIicas requelidas, De esta manera cada organizacion puede usar 10 que sea
mas apropiado para sus necesidades.
III
Con estos dos componentes. la idea del marco puede resumirse como sigue: elegir
un PGI de la organizQcion cuya cali dad de los datos y de la infol1mcion sea suceptible de
mejora. aplicar EVAMECAL para evaluarlo segLll1 el modelo de referencia indicado por
CALDEA y mejorarlo planificando la realizacion de acciones COlTectoras para satisfacer
los objetivos de calidad de datos y de infol1nacion establecidos en CALDEA.
Los siguientes subapartados describen los componentes del modelo propuesto.
4.7.1.
L11L.dU
30-1
Optimizante, cada uno con sus ACP. Estas ACP estan a su vez compuestas por
actividades. Para la realizacion de cada actividad, es necesmio la eleccion de una serie de
tecnicas, estandares y heITamientas que penIDtan convertir los productos de entrada en
productos de salida. A fin de hacer el modelo 10 mas universal posible se ha optado por
proponer, no por imponer una serie de tecnicas y heITamientas que dilijan hacia el
objetivo de la ACP. Tambien es importante senalar que en cada nivel de madurez se
puede ir modificando tanto elmodelo de procesos del PGI como elmodelo de datos, para
que puedan recopilar todos los requisitos de calidad de datos y de la infonnacion.
Los cinco niveles de madurez en la gestion de calidad de datos y de la infonnacion
de los que consta CALDEA son los siguientes (en la tabla 10.19 se muestran las ACP de
cada uno de ellos):
...
GEGCDI
z;
~9
\;;
vv
f--
g
~
GCI
GIR
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.
2.
RA-MA
305
necesitan personas que puedan dar soporte a las actividades que se deben
realizar. Estas personas deb en trabajar en concordancia con las ideas y las
tendencias de la organizaci6n y deben estimular a la plantilla mostrando un
compromiso con las politicas de calidad de infonnaci6n (Ballou y Tayi, 1999),
haciendo esfuerzos para satisfacer las ACPs del modelo de madurez. Redman
(2001) sefiala la necesidad de que los altos directivos se impliquen en las
iniciativas de calidad de datos y de infoffilaci6n.
e
306
&~-'\.-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).
"
'"
<;' RA-:'vlA
307
4.
c;;
c;;
5.
Ii>
308
: R.-\-\!A
estar
en
uno
de
estos
estados:
10: CAUDAD DE LA
"'rv""\l_~'L
309
VCI = _ _
GradoCriticidadj
'"
VaioracionComponeJZte i
=i~,-l_----:-:--,-----::-_ _ _ _ _ _ _ _ _ _ __
Il~;lI1crocoll1!'ol1<!lIIcs NiveiCriticidad
Con estos hes valores y aplicando la for1llula dada en la figura 10.12 es posible
obtener un VCl. Ese valor se mapea segill1 los rangos de valores definidos (compatibles
con ISO/IEC 15504) en la tabla 10.22 para obtener el estado de cada uno de los
componentes estudiados.
4.7.2.1. La Metodologia
La metodolog!a EVAMECAL establece los pasos que hay que dar para valorar y
mejorar un PGl. Las valoraciones del PGI y los objetivos de mejora se establecen en
DE SISTEMAS INFO~YLA.TIeos
RA-:'IA
EI
I GCR-I
ACP
ACTIVtDADES ACP
GEGCDI.I. Detem1inar la composici6n I 60%
del EGCDI.
GEGCDI.2. Definir un entomo
40%
operativo.
10%
15%
60'io
I
40"
30~o
30 0
-+0 0
25%
Q. R.A-.MA
311
312
ACP
GCR-'
ACP
ACTlVlDADES ACP
25%
,,)-01
_) /0
-0
>
Calidad de la Infol1nacion
25~;o
25%
""
o;
~g
'""
GCRAcnv
60"
40%
60"
400
0
30 "
300
400
1000
600
!
i
70%
GPM.2. Definicion de un plan de medida para cada
una de las metricas.
Co.;
400
i
I
(GAPM) Gestion de la
Automatizacion de los Planes de
Medida.
(GPD)Gestion de Prevencion de
Defectos para el Analisis de Causas.
30 10
50%
:~
0.
<>
.2:
Z
50'io
60" 0
400
250 II
i
~5o
250 l
250
25 ()
~5u
250
25 ()
Tabla 10.21. Grados de Criticidad de Areas ClaYes de Proceso y ActiYidades del resto de
niveles de CALDEA
NmmRE
313
R\NGOVCJ
DESCRIPCloN
os VCIS20
ESTADO
No Optimizado
No Ejecutado.
Parcialmente
21 S VCI s 60
Optimizado'
Parcialmente
Ejecutado.
Optimizado
Ejecutado.
unidades de
trabajo.
Completamente
86 S VCI s 100
Optimizado'
Completamente
Ejecutado
definidos.
No Satisfecho
OS VCI -Ni'! S 90
Satisfecho.
Madurez
314
....
NIVELnE DEFINICION
".
<
No EJEctTrAl>O
No Satisfecho
Parcialmente
Infonnaci6n.
Satisfecho
Parcialmente
Satisfecho
No Satisfecho
.'
'.
NIVEL DE l'\TEGR,,"CION
NoEJECuTADO
No Satisfecho
'.
No EJECUTADO
No Satisfecho
No Satisfecho
.....
. NIVEL DE lVlEJOR,,"
.'
'
..
.....
No EJEcuTAl>O.
No Satisfecho
No Satisfecho
RA-:v!A
315
Los resultados reflejan que ninguna de las ACPs que pertenecen al nivel 2 y a
niveles supeliores pertenecen como mlnimo "Satisfecho ", todos los niveles estan en el
estado "No ejecutado ". Acorde con el grado de criticidad de cada ACPs, se propusieron
las siguientes recomendaciones para satisfacer el nivel de definici6n de las ACPs:
G
5. LECTURAS RECOMENDADAS
G
316
7. EJERCICIOS
1.
c, Que caracteristicas de la n01111a ISO 9126 cree que son aplicables a la hora de
evaluar la calidad de un SGBD?
2.
Daniel Moody en los liitimos cinco anos ha llevado a cabo diferentes eshldios con
el fin de validar tanto el marco (Moody y Shanks, 1994) como las metricas
(Moody, 1998) propuestas para la evaluaci6n de modelos E/R. Analice los
eshldio que pueda encontrar en la bibliografia y detelmine hasta que punto
validan sus propuestas.
3.
4.
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 objetorelacionales? 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
31 i
7.
Compare las dimensiones para calidad de datos propuestas por English (1999)
con las de Pipino et al. (2002).
8.
(,Que indicadores para la cali dad de datos Ie parecen m:1S relevantes'? (,Que
dificultades presentan a la hora de calcular sus val ores'?
9.
10. Ana1ice hasta que punto elmodelo CALDEA es conf0I111e a las especificaciones
de la nonna ISO 15504.
11. Ana1ice hasta que punto el modelo CALDEA es COnf0I111e a las especificaciones
de CMMl.
12. Analice hasta que punto la metodo10gia EV AMECAL es confo1111e a SCAMPI
13. Describa algllI1 Proceso de Gesti6n de Infonnaci6n (PGI) de su organizaci6n.
14. Identifique dimensiones de ca1idad de datos y de infonnaci6n y las metricas
cOITespondientes que puedan ser aplicadas al PGI que acaba de describir.
15. Ap1ique EVA.MECAL. calculando todos los VCl. (,en que nivel de madurez esta'?
CAPITULO 11
IMORlvL.\ TIeos
320
1;:; RA~lvLA
La reutilizacion de experiencias.
321
Nive! de Aplicacion
Interfaces
Servicios de Gest"lon de
Conoclmiento
Inteligencia
Competitiva
Sistema de Majores
Practicas
Portal de Conocimiento
Servicios de Descubrimiento
Servicios de Co[aboraci6n
Taxonomia Corporativa
r..1apa de Conocimiema
Gesti6n de Contenidos
RepoSltorio de Co nacimiento
Inrraestructura
Informacion y ruent8 de
Conocimiento.
Gestf6n de
Documentos
E!ectr6nicos
Correo
Electrcnico
'.Neb
@RA-MA
Modelos de predicci6n.
"Caliografia" de conocimiento.
RA-MA
323
Flujos de conocimiento.
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:
(I
I:RA-MA
(I
(I
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)
MODELODE
ESTRATEGIA
DIPRESARIAL
GESnO"
ORG.{MLKION
CO?\CEI'TOS
Base de
in!ollnaci6n
Proccsos
comunes
Reducci6n de
costes
Productividad
Compartir. evitando
redundancia
Especializaci6n
Cali dad
Mcjores pnicticas
Innovaci6n
Creatividad
Integraci6n y
c0l11binaci6n de
conocil11icnto
Conocil11icnto
dinul11ico
TlPODE
co:\ocnUE:i\TO
Explicita
Explicito
Tacita
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".
.;: RA-MA
325
Ii)
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.
MEMORIAl
,ORGANIZACIONALI
/,_,_ :_i\
/
FACTO RES
\~ACILITADORES
\1-'
,;
-I-,f
'\/
CONOCIMIENTO
LOCAL
INTERPRETACION
CONOCIMIENTO
o
R
G
A
N
I
Z
A
C
I
o
N
A
L
R.",-MA
CONOe.
LOCAL
ORlE:-ITACIO:-l AL
:-IEGOCIO
lVIEMORIA
ORGA1'ljlZ.
li~TERPRET.
XX
CONOe.
I:\IPLICACIO:-l DE LOS
LiDERES
PARTICIPACIO;-'; DE
LOS DIPLEADOS
PREOCUPACIO:-l POR
LA :\IEDICIO:-l
EXPLOTACIO:-l DEL
CO;-.;OC. EXISTEi\TE
EXPLOR-\CIO;-'; DE
:-IUEYO CO:-lOC.
GENERACION
CONOe.
XX
XX
XX
XX
XX
XX
XX
XX
Tabla 11.2. Relaciones entre los procesos de creacion de conocimiento y los factores
facilitadores (Dyba, 2003)
RA-MA
OPORTUNIDAD
DE
APRENDER
CULTURA
DE APOYO
(NIVEL ORG. E
INDIVIDUAL)
DES EO
DE
APRENDER
MOTIVACION
PARA
DESCUBRIR
CONOCIMIENTO
327
COMPARTICION
DELCONOCIMIENTO
ENINGENIERIADEL
SOFTWARE
EXPERIENCIA
PREVIA
DRAAIA
Establecer un proceso de mejora de software sus tent ado y controlado por datos
cuantitativos.
(;: It/>''-\lA
329
'"
'"
ORGANIZACION
DE PROYECTO
DATOS
EJECUCION
DEL PROCESO
I""""""
i-' PRODUCIDOS
I
I
Modelo de ejecucion
PLANIFICACION
DEL PROCESO
I-
EXPERIENCIA
EMPAQUETADA
2.3. Base
repositorio de experiencia
'"
'"
'"
C01110
se
(I)
R.,\,,-NL-\
Estos autores prop on en una serie de pasos para crear un sistema de gestion de
expeliencia (SGE):
e
(I)
(I)
&
2.
Fijar objetivos.
3.
Fijarareas.
4.
5.
6.
Implementar el EBIS.
7.
8.
Mantener el EBIS.
9.
1': RA.-MA
331
3. FAMILIAS DE ESTUDIOS
Una de las fOl1nas mas imp0I1antes de obtener conocimiento relacionado con el
desalTollo y mantenimiento del software es mediante la realizaci6n de familias de
estudios. En este senti do. Basili et af. (2001) sefialan algunos criterios para la
construccion de cuerpos de conocimiento en areas de IngenieJia del Software:
I.
Fijar hip6tesis de alto nivel que sean de in teres para la comunidad de IngenieIia
del Software.
2.
3.
Variables de contexto. sugelidas pOl' las hipotesis, que puedan modificarse para
pel1nitir vmiaciones en el diseilo experimental.
4.
Una cantidad suficiente de infol1nacion para que el estudio pueda ser replicado.
5.
traveS de hipotesis en el mundo real, ll1l:lS alla de la pura teolia, que habra que comprobar
con datos empiricos. Hay tres tipos principales de estrategias empiricas que pueden ser
llevadas a cabo (Robson, 1993): experimentos, casos de estudio y encuestas. En los
siguientes apartados se descliben con mayor detalle estas estrategias.
3.1. Experimentos
La ventaja de un experimento es que puede detenninar en que situaciones cielias
afil111aciones son ciertas y puede proporcionar el contexto en el que cielios estandares,
metodos y helTamientas son recomendables. Solo si el experimento se realiza
adecuadamente, es posible obtener conclusiones acerca de las relaciones entre la causa y
el efecto para la cual se fonnulan la hipotesis (Wohlin et al., 2000). Los expelimentos
necesitan ser planificados cuidadosamente si se pre ten de que proporcionen resultados
lltiles y significativos (Juristo y Moreno, 2001).
Basili et al. (1999) comentan que la experimentacion en la ingenielia del software
es necesaria. pero bastante dificil. Una razon de esta dificultad es la gra!1 cantidad de
variables del contexto, 10 cual implica que para conseguir una comprension adecuada de
los resultados de los experimentos, se necesita un mecanismo para explicar los estudios e
incorporar los resultados.
3.1.1.1. Definicion
EI proposito de la fase de definicion es definir los objetivos de un experimento.
fOl11mlado a partir de un problema a resolver. Para recoger los objetivos de un
expelimento se sigue la plantilla GQM de aCl~erdo con las sugerencias de Briand et al.
(2002) y Lott y Rombach (1996) (ver tabla 9.2 en apartado 2.2.2 del capitulo 9).
3.1.1.2. Planificacion
Despues de la definicion del experimento tiene lugar la planificacion. La
definicion detem1ina por que se va a realizar el experimento, mientras que la
planiticacion establece como se llevara a cabo. Esta etapa se puede dividir en los
siguientes seis pasos:
C RA-\L-\
333
Figura 11.5. Vision general del proceso experimental principales (WohHn et at., 2000)
1.
2.
'"
'"
'"
Espec(jico vs. Genera!. Los resultados del. expelill1ento pueden ser vcilidos en
un contexte especifico 0 en el dominio general de la ingenieria del software.
RA-MA
3.
Seleccion de variables. Antes de comenzar con el diseflo tenemos que elegir las
variables dependiente e independiente que se van a considerar, junto con la fonna
en que se van a medir y sus respectivas escalas de medici6n.
4.
5.
6.
335
3.1.1.3. Operacion
En la etapa operacional de un expe11mento, se aplican los tratamientos a los
sujetos. Esta etapa se divide en tres partes:
Preparacion. Antes de que el expe11mento se 1111Cle, se debe encontrar el
personal que se comprometa a pmiicipar como los sujetos delmismo. Es esencial
que los sujetos que pariicipen en el experimento esten motivados y pmiicipen
voluntariamente en todas las paries del expe11mento. Los siguientes aspectos
deberian ser considerados respecto a los sujetos que participan en un
expe11mento:
A)
B)
Obtener consentimiento. Los pmiicipantes tienen que estar de acuerdo con los
objetivos de la investigacion.
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.
337
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.:
Vi\LIDEZ ...
Validez de la
conclusion,
Validez de
constructo,
Validez intema.
Validez externa.
D.ESCRlPCION
Baja potencia estadistica. \'iolar las suposiciones de los tests estadisticos. finalizacion y
ratio de error, fiabilidad de las metricas, fiabilidad 0 tratamiento de implementacion.
irrele\'ancias aleatorias en eLambiente experimental.
Interpretacion pre-operacional inadecuada de los constructores. sesgo por monooperacion. sesgo por mono-metodo, confusion entre constructores y niveles de
constructores. interaccion de diferentes tratamientos. interaccion de experimentacion y
tratamientos, generalizacion restringida a traves de constructores, conjeturar hipotesis.
aprension en la evaluacion, expcctativas del experimentador.
Historia. madurez. experimentacion. instrumentacion. rcgresion estadistica. seleccion.
mortalidad. ambigiiedad sobre el senti do de la influencia causal, interaccion con la
selecci6n, difusi6n de duplicados del tratamiento, igualaci6n compensatoria de los
tratamientos, rivalidad compensatoria. desmoralizaci6n resentida.
Interacci6n de la selecci6n y el tratamiento, interaccion del ambiente y el tratamiento.
interacci6n de la historia y el tratamiento.
..
9 RA.-?\lA
2.
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
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.
339
del entomo que son impOltantes ya que afectan a los resultados del proceso en
investigaci6n y por tanto nos ayudan a entender la validez extema.
3.
Definici6n del
Contexto
Preparaci6n
Experimentos
Conducci6n
Am31isis de la
Experimentos f---I!>/ Familia de
Individuales
Datos
Material
Figura 11.6. Fases para el desarrollo de una Familia de Experimentos (Ciolkowski et al.,
2002)
1':: RA.-\lA
\: RA.-YIA
341
Material. El material experimental debe ser el mas adecuado para satisfacer los
objetivos planteados. De acuerdo al objetivo -de la investigacion y a las tare as
planificadas en el experimento se preparo la documentacion de un sistema para la
venta de libros de segunda mano a traves de Intemet. Dependiendo de las tareas
requeridas en cada experimento individual el material estaba compuesto por:
G
EI
4.
:0 RA-;"L~
Tarea Experimental
1 Experimento
Desarrollo
-r-
I
:vlantenimiento
I" Experimento
2 Experimento
3 Experimento
2 Experimento
3" Experimento
(replica 2")
RA-illA
343
Como se puede verse en la figura 11., los sujetos que partlClparon en los
experimentos fueron estudiantes de distintas universidades en Italia y Espana.
Todos los sujetos antes de proceder con el experimento recibieron una sesion
de entrenamiento y se familiarizaron con la tecnica de pair designing y con el tipo de
tare as a realizar en el experimento.
El proceso expel1mental que siguieron los sujetos en el primer experimento
fue dividido en tres sesiones 0 rondas. Al principio y final de cada ronda ten ian que
contestar un cuestionario de fonna individual para evaluar sus conocimientos del
sistema. La mitad de los sujetos trabajaron en cada ronda aplicando la fonna
tradicional de disefio (que denominaremos solo designing) mientras que la otra mitad
fueron distribuidos en parejas y aplicaron pair designing. Al final de cada ronda los
sujetos producian los diagramas cOlTespondientes que respectivamente fueron:
diagramas de casos de uso, diagramas de clases y diagramas de interaccion.
Por su pmte el proceso seguido en el segundo y tercer experimento nle:
e
IKFOR:VIATIeos
5.
345
primera ronda conto con todos los sujetos, mientras que en las ott'as dos rondas el nlllnero
de sujeto disminuyo. Un cierto nlllnero de sujetos abandonaron en la ronda 2 y en la
ronda 3 porque 10 consideraron como una actividad de fOnllacion innecesaria para el
curso que estaban siguiendo. Este fue un importante aspecto de reflexion que se tllVO en
cuenta en los siguientes expelimentos inc1uyendo mecanismos para la motivacion de los
~~.
ROl'\DA
PROMEDlO DE LA
REH1ERZODE
COl'\OCEvllENTO DE LOS
PARES
PRO:VlEDlO DE LA
REFUERZO DEL
CONOC!:VI1ENTO DE
LOS SOLOS
1,75
-0.25
I: Caso de Uso
II: Diagrama de Clases
2.27
III: Diagrama de
"
ImeraCClOn
1.86
SIG~lFICACION
0,019
I
1.36
0.53
-0.5
0.26
Los datos estadisticos obtenidos a par1ir de los datos del segundo y tercer
expelimento se muestran en la tabla 11.5:
TESTS ESTAD1S"rlCOS
2. Italia
3. Espana
!I
",,-
,rlf,'"
, L"tUI:' II
"'USiO~ CONOCnIIE~TO
I
!
SrGKIFIC-\CION
ESTADisTICA
REFORZA:VU"iTO DE
CO;"iiOCrynENTO
0.049
0.270
0.2[6
0.023
0.0428
Pares 5II( a)
Solos 5II(~)
0,0309J.2
Pares 3Gestion(a)
Solos 3Sistemas(~)
0,00017
0,0009
Pares 3Gestion( a)
Solos 3Gestion(~)
0.00000
0.042
II
0,0102
0.086
RA-ivlA
3.1.3.3. Conclusiones
A partir de los resultados anteriores se puede llegar a las siguientes conclusiones:
RA-MA
347
confusos, sin embargo, no se tiene el mismo control en un caso de estudio que el que se
tiene en un experimento. Los casos de estudio son valiosos porque incorporan cualidades
que un experimento no puede visualizar, por ejemplo, la escala, la complejidad, la falta
de predictibilidad y el dinamismo.
A continuaci6n se resumen los principales aspectos de los casos de eshldio
siguiendo a Yin (2003).
iii
iii
iii
Explicar los supuestos enlaces causales en intervenciones reales que son muy
complejos para las estrategias de encuesta 0 experimento.
iii
iii
iii
iii
Explorar las situaciones en las que la intervenci6n que esta siendo evaluada no
tiene un conjunto claro de resultados unicos.
Estudiar un estudio de evaluaci6n (metaevaiuaci6n).
Aunque, la tendencia general de todos los tipos de caso de esmdio, es que intentan
aclarar una decisi6n 0 conjunto de decisiones: por que se tomaron, c6mo se
implementaron, y con que resultado (Schramm, 1971).
'iR:\-MA
III
Es un caso longitudinal.
ll11ico.
Caso simple
tipico.
Caso multiple
Holistico
caso
Embebido
Unidad de
anal isis 1
Unidad de
anal isis 2
3-+9
1.
2.
I.
2.
3.
4.
5.
Una guia para el infol111e del caso de estudio (contenidos, formato de los
datos. utilizacion y presentacion de otra documentacion, infol111acion
bibliognifica).
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.
C) Llevar a cabo un caso de estudio pilato.
,-._.-._.-.-.-.-.-._-_..
I
I
I
I
,--t
I
I
t
r>
I
escribir
realizar 1 I
obtener
Informe de f-o'------'
caso de ~
conclusiones
I
caso
estudio
intercasos
individual
!
I
desarrollar
teorfa
seleccionar
casos
modificar
teorfa
!
->
,.
disefiar
protocolo
L.
de recogida
de datos
realizar 2
caso de
estudio
I-!---.
I
I
I
escribir
Informe de
caso
individual
->
desarrollar
implicaciones
politicas
i
I
I
I
I
escribir
conclusiones
intercasos
realizar I...i
escribir
:...... restantes I-----> Informe de f-o
caso de
caso
estudio
individual
D
I
S
E
N0
I
I
II
,,'
Comportamiento indhoidual
Actitl.ldes individl.lales
Percepciones individuales
ACERCADEUl'<
Il\!)[V1DUO
o'
ACERCADE
UNA
ORGAi'\lZAC!ON
--:-
,I
"
",
.Registros de archivo.
Otros comportamientos. actitudes y percepciones reportadas
Politic as de personal
Productos de la
organizacion
,0
'"
, ' , '
CONCLUSIONES DEL
ESTUDIO
DEu'NA
ORGANIZAOQN
Si el caso de estudio
es un individuo
Si el caso de estudio
es una organizacion
RA-MA
35l
Constmcci6n de explicaciones.
Modelos 16gicos.
RA.-MA
Si se trata del infonne de un caso de eshldio que fonna parte de un eshldio mcis
amplio multimetodo.
TIPOnE ESTRUCTIJRA
Al~ALiT1CA.:.LI~EAL
COMPAR,\TIVA
CRONOLOGICA .
CONTRUCCION DE
....
TEORlA
"SUSPENSO"
NO SECUENCIAL
J
I
I
I
I
X
X
X
X
X
X
I
X
RA.-ivlA
353
Ser significativo.
II
Ser completo.
II
II
II
II
II
II
II
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,
RA-ivL>\
Planificar la encuesta.
Disefiar la encuesta.
Validar el instrumento.
Validez de constructo
Validez intern a
F ASE DE LA INVESTIGAcrON EN
QUE OCURRELA TACTICA
T.kTICA.DECASO DE ESTUDIO
Toma de datos
Toma de datos
Composicion
Hacer pal/em-marching
Hacer construccion de
explicaciones
Analisis de datos
Validez externa
Fiabilidad
I
Diseiio de la investigacion
I
Toma de datos
RA-MA
355
Ii)
Ii)
Ii)
Ii)
Ii)
La tabla 11.9 muestra cada uno de los factores mencionados antes para cada una
de las estrategias y se puede usar como guia a la hora de decidir que estrategia seguir.
FACTOR
ENCUESTA
Control de la ejecuci6n
Control de la medici6n
Coste de Investigaci6n
Facilidad de replica
I
I
No
No
Bajo
Alto
I
I
I
I
CASO DE ESTI5DIO
I
I
No
Si
Medio
Bajo
I
I
I
I
I
EXPERiiY1E:STO
Si
Si
Alto
Alto
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.
[ RA-MA
357
Yin, R.K. (2003). Case Study Research: Design and Methods. Thousand
Oaks, Sage Publications. Es el libro mas representativo para la utilizaci6n de
casos de estudio, si bien no esta adaptado ni a la Ingenieria del Software ni a
los Sistemas de Infonnaci6n.
<!;)
6.
ERCiCIOS
I.
2.
3.
4.
5.
RA-MA
6.
7.
Replique alglin experimento sobre alglin tema de su interes, como por ejemplo,
sobre los beneficios de pair designing para la mejora de la difusi6n y el
reforzamiento del conocimiento (vease apartado 3.1.3).
8.
9.
ACRONIMOS
ACT
ACP
AEC
AENOR
AFNOR
AIO
AlvlFE
ANSI
API
ARC
ARIS
ASQ
BSI
CAF
CALDEA
CASE
CBA-IPI
CMM
Cl'vLvfI
CMMI-SE/SW/IPPD
COCOTS
360
COQ
CORBA
COTS
Coll1l11ercial-O(l: The-Shelf'
CPL
CPR
CPU
CRE
CTh
DDE
Disefio de Experimentos.
DEC
DOE
EFQ\l
ElA
ElAIS
EIS
EJB
E\
EOQ
ER
E\".-\:vIEC.-\L
F\lE
F\lEA
FMESP
FPKD
European :\onn
GC
Gesti6n de la Configuraci6n
GCR
GQM
GUI
HCI
HTML
I+D
L-\-SI
IEC
IEEE
IFPUG
IMS
Investigaci6n y Desarrollo
Investigaci6n-Acci6n en Sistemas de Infoffilaci6n
International Eleclroleclmical Commission
;;; R.-\-MA
RA.-ivLA.
ACRONIMOS
IPD-CMM
IPR
ISO
InrernationalStandardi::ation Organi::ation
JTCI
JUSE
KDD
KIF
KP
KPA
LCI
LCS
LMP
LOC
Lines Of Code
LOPD
MDC
ivllT
ivL'vlHQ
Miv[LC
MOF
OCL
OMG
PDCA
PERT
PHVA
PI
PIF
PMBOK
PSEE
PSL
PSM
PSP
QFD
RUP
SC
SCA.MPI
SCE
Subcomite
Standard CMAll Appraisal Alethodfo!" Process IlIlpro,"elllenr
So/hrare Capability Emillation
361
362
SEI
SGBD
SGC
SI
SMSDM
SPEM
SQL
SQuaRE
SUMI
SUS
SW-ClvL'v!
TC
Sistema de Informacion
Standard Metamodel for Sofnmre De\'elopme!1/ Methodologies
SO/Mare Process Engineering Metamodel
Stl1lctured Quel)' Language
Sofill'are Product Quality Requirements and Emluation
TOO
TQM
TSP
UEM
UML
LJNE
UPM
WfMC
WG
Wor~110>1"
Management Coalition
RA-MA
BIBLIOGRAFiA
Abdel-Hamid, T, YMadnick, S. (1991). Sofnrare Project Dynamics: An IllIegrated Approach. Prentice-Hall.
Acuna. S. T., De Antonio, A, Ferre, x., Mate, L y Lopez, M. (2001). "The Software Process: Modelling. Evaluation
and Improvement". In S. K. Chang (Ed.), Handbook of Sofnrare Engineering and Knowledge Engineering. (Vol. l.
Fundamentals .. pp. 193-237). New Yersey (EE.UlJl. World Scientific.
Adamson. Christopher y Venerable, Michael (1998). Data Warehouse Design Solutions. Jo1m Wiley and Sons.
USA.
AFMC (1994) Acquisition - Sofnrare DCI'elopmelll Capability Emluation, Air Force Materiel Conmland (AFMC)
Pamphlet 63-103, Volumes I and 2, June IS, 1994.
A1bretch, A. (1979). ivfeasuring Application Developmelll Productivity. Proceedings of the IBM
Development Symposium, Monterey, pp. 83-92.
Application
Althoff, K. Y Pfahl. D. (2003) "Integrating Experienced-Based Knowledge Management with Sustained Competence
Development". En Afanaging Sofnrare Engineering Knowlegde. Aurum, A.. Jeffery. R., Wohlin. c., Handzic, tv!. (eds.)
Berlin. Springer.
Ambrio1a, V., Conradi, R. y Fuggetta. A (1997). "Assessing Process-Centered Software Engineering
Environments". ACM Transactions on Sofnrare Engineering and Method070gy 6,3 (July 1997), pp.283-328.
Anderson, J. R. (1983). The architecture ofcognition. Cambridge: Harvard University press.
April, A. Y Coallier, F. (1995). 'Trillium: a model for the assessment of telecom software system development and
maintenance capability". 2nd IEEE Software Engineering Standards Symposium, pp. 175.
April, A, Huffman. J., Abran, A. y Dumke, R. (2005). "Software Maintenance Maturity Model: the software
maintenance process model'. Joul7lal ofSofnrare Maintenance and Emlution: Research and Practice 17, pp. 197-223.
Arbaoui, S., Haurat A .. Oquendo, F.. Theroude, F. y Verjus. H. (2003). "Languages and Mechanisms for Software
Processes and Manufacturing Enterprise Processes: Similarities and Differences". Proceedings of the 5th Intemational
Co/?terence on Ente/prise biformation Systems IICElS 2003), pp. 474-482.
364
RA.-MA
Springer.
Baldrige (2005). Criteria .tin- PerF017I1WICe Ercellence. The Malcolm Baldrige National Quality Award Program.
Disponible en: http:\\ww.gualitv.nisLgov CCltimo acceso Agosto de 2006).
Ballou D .. Wang R.. Pazer. H.. y Tayi. G.K. "Modeling Information Manufacturing Systems to Determine
lnfornmion Product Quality". Management Science 41(4). pp. 462-484. 1998.
Ballou. D. Y Tayi. G.K. (1996). ";-'Ianagerial Issues in Data Quality". Proceedings of the First International
Conlerellce on h?/ol7lwtion 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
Transactions Oil Soll1mre Engineering, 2S(I). pp. 4-17.
~vlodel
Bansiya L Etzkorn L Davis C. y Li W. (1999). "A Class Cohesion Metric For Object-Oriented Designs". Tlze
JOllrnal oj'Ol'iect-Oriellled Programming, 11(S), 1999, pp. 47-52.
Barghouti. N .. Rosenblum. D .. Belanger. D. y Alliegro. C. (1995). "Two case studies in modelling real. corporate
processes". Sojnmre Process -IlIlprol'emclll and Practice (Pilot Issue). pp. 17-32.
Basili. V. R. y Rombach, H.D. (1988) "Towards A Comprehensive Framework for Reuse: A Reuse-enabling
Software Environment". Uni\'ersit:y of Maryland. CS-TR-2I5S. UAllACS-TR-SS-9:!. December 1988.
Basili. V.. Shull. F. y Lanubile. F. (1999). "Building knowledge through families of experiments". IEEE
Transactions on Sojnmre Engineering. 25(4). pp. 435-437.
Basili. V.R. Y Caldiera. G. (1995). "Improve Software Quality by Reusing Knowledge & Experience". Sloan
.\fanagemel/l Redl!\\'. \IIT Press, 37(1): pp. 55-64.
Basili. V.R. Y Reaman. C. (2002). 'The Experience Factory Organization". IEEE So/nmre. 19(3): pp. 30-31.
Basili. V.R. Y Weiss. A. (1984) "\Iethodology for Collecting Valid Software Engineering Data". IEEE Transactions
on Sojnmre Engineering. SE-IO. ]\;0. 6. pp.728-738. 1984.
RA.-MA
BIBLlOGRAFiA Y REFERENCIAS
365
Basili. V.R .. Costa. P. Lindvall. M.. N!endonca. M.. Seaman. C. Tesoriero. R.. y MaIyin Zclkowitz. M. (2001). "An
Experience Management System for a Software Engineering Research Organization ". ::6,i. Annl/a/ .VASA Goddard Sojilmre
Engineering Workshop. Pp. 26-35.
Batini C. Ceri S. y Navathe S. (1992). Concepllial daTabase design. An emily relationship approach. Benjamin
Cununings Publishing Company.
Batista J. y Figueiredo A. (2000). "SPI in very small team: a case with CMM". Sojilmre Process ImprOl'elllelll and
Praclice 5 (-I). 2-13-250.
Becker-Komstaedt.. U.. Bella. F.. .\!linch. L Neu. H. Ocampo. A y Zenc!. J. (2003). SPEARM!:VTf" i Lser
:\[anual. Fraunhofer Institute. lESE report n 072.02;E .. v. 1.1. 2003.
Belkhatir. N.. Estublier. J y .\!elo. W.L (1991). "Adele2: A Support to Large Software Development Process".
Proceedings of the 1st IllIel'l1ational Con/i!rence on the Sojilmre Process. Redondo Beach CA (USA). October 1991.
Ben-Shad. I. y Kaiser. G. (1994). "A Paradigm for Decentralized Process Modeling and its Realization in the Oz
Environment". Proct!edings a/the 16th Imel7lational Con/i!J'cncc on Sojilmre Engineering.
Bemardez. 8.. Duran. A.. y Genero. NL (200-1). "An empirical review of use cases metrics for requirements
\erification". Actas del SoJilmre Measurement European Fomlll (SMEFO-l).
Bertoa. M. F. y Vallecillo. A. (2002). "Quality Anributes for COTS Components". 6th Intel'l1ational Workshop on
Qual1lilati\'e Approaches ill O~iect-Oriellted So/ilmre Engineering (QAOOSE'2002). Malaga
Bertoa. !\!.. Troya. 1.M.. y Vallecillo. A. (2005) "Measuring the usability of software components". JOlll7lal
5.\slems and Solimre. Agosto 2005.
0/
Bevans N. (2000). Imrodllction to l/sabili(r mallirizr asseSSlIlenl. Serco Csability Senices. Serco. Ltd.: London. 10.
Disponible en: httn:..www.usabilitv.serco.comtnl111Ddocuments.}.!aturitv assessment.opLodf (Ultimo acceso en Mayo de
2006)
Bobrowski. M.. Marre. M.. y YaIlkele\ich. D. (1998) "A Software Engineering View of Data Quality". Proceedings
o.rSecond IlIIel7l(J/ional So.filmre Quality in Europe. Belgium. November 1998.
~Iethod
366
RA-?vt.A.
BringeL H.. Caetano. A.. y Tribolet. 1. (2004). "Business Process Modeling Towards Data Quality Assurance".
Proceeding 0/ICEIS'2004 Porto (Portugal). pp. 565-568.
Brito e Abreu F. y Carapuya R. (1994). "Object-Oriented Software Engineering: Measuring and controlling the
development process". 4th Int Con(erence on So/nrare Quality. McLean. VA. USA.
Brito e Abreu F. y Melo W. (1996). "Evaluating the Impact of Object-Oriented Design on Software Quality".
Proceedings 0/3rd Il1Iel71ational Metric Symposium. pp. 90-99.
Burgess. M.S.E .. Gray. W.A .. y Fiddian. N.J. (2003) "A flexible quality ftamework for use within information
retrieval". Proceedings a/the Eighth International COl!lerence on b!formation Qualit)' (lCIQ ']003). pp. 297-313
Burke. B. (2002). "Evolving Architecture Maturity. Enterprise Planning and Architecture Strategies". EPAS Meta
Practices 67. Meta Group.
Burzy11ski T. (1998). "Establishing the Environment for Implementation of a Data Quality Management Culture in
the Military Health System". Proceedings o/the Third Conference on In/ol7nation Quality ICIQ '1998. pp. 18.....6
Bymes. P. y Philips. M. (1996). Sojhrare Capability Emluation I ersion 3.0. Method Description. Technical Report
CMUiSEI-96-TR-002 ESC-TR-96-002.
Calero. C (2001) Definicion de III/ Conjunto de Merricas para la Afalllenibilidad de Bases de Datos Relacionales,
Actims y Objeto-Relacionales. Tesis DoctoraL Universidad de Castilla-La Mancha.
Calero. C y Piattini. M. (2002) "Metrics for databases: a way to assure the quality". En: b!lormation and Database
Quali(\. Kluwer Academic Publishers. Pp. 57-84. 2002
Calero. C. Piattini. ivl.. PascuaL C. y Serrano. M.A. (2001). "Towards Data Warehouse Quality Metrics". Aetas del
3rd Workshop on Design and Managemelll olData Warehouses (DMDW'OI). Agosto. 2001
Caho-Manzano. 1.A. (2000). Merodo de Mejora del Proceso de desarrollo de sistemas de informacion en la
pequel1a y medicllIa empresa. Tesis Doctoral. Universidad de Vigo.
CampbelL D. y Stanley. 1. (1963). E.\perimelllal and quasi-e.\perimelllal desigllS .lor research. Boston. Houghton
Mifflin Co
Canfora. G.. Garcia. F.. Piattini. M.. Ruiz. F. v Visa!.!!.!io. CA. (2005). "Pair Desi!.!Oing as Practice for Enforcin!.! and
Diffusing Design Knowledge". Joumal o{So/nrare :;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 ObjectOriented 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. 3544
Card. D.N. (l995). "The R.-,\D Fad: Is Timing Really EYerythingry"IEEE Sofnmre. Septiembre, Pp. 19-11.
Carretero. A. Ingelmo. P.. Sanchez-Infantes. lA. Sanchez-Infantes. P.. y Sanchez. 1.A.(l999). Calidad. Madrid:
Editex.
Carver. 1.. 1accheri. L.. Morasca. S. y Shull. F. (1003). "Issues in Using Students in Empirical Studies in Software
Engineering Education". Proceedings of the 9th IllIemational SO/Mare Metrics Symposium (AfETRlCS'03). pp.139-251.
Cechich. A, Piattini. M. y Vallecillo. A (eds.) 2003. Component-Based Sofnmre Quality: Methods and Techniques.
Springer. Alemania. Lecture Notes in Computer Science 2693
Chidamber S. Y Kemerer C. (1994). "A Metrics Suite for Object Oriented Design". IEEE Transactions on SojAmre
Engineering. 10(6). pp. 476-493. 1994.
Cianmmi. C.A. Tsiakals. 1.1 .. West. 1 (1002).150 9001: ]000 E.'plained ]nd Edition. Quality Press
Ciolkowski. M .. Shull. F. y Biffl. S. (2002). "A Family of Experiments to Investigate the Influence of Context on the
Effect of Inspection Techniques". Proceedings of the 6Th International Conterenee on Empirical Assessment in Sofnmre
Engineering (E.iS!. Keele (UK). pp. 48-60.
CMMJ. (2002) Capabili(\' Maturity Moder Integration (CMIIl'\!). Version I.I C:II[f\fjor Systems Engineering.
SO/Amre Engineering. IfIlegrated Product and Process De\'eIopment and Supplier Sourcing (CMMI-SE;SWilPPDfSS, VI. I )
Staged
Repre-sentation
CMUfSEI-2002-TR-012
ESC-TR-2002-012.
en
http://www.sei.cmu.edu
!publications /documents i 02.reports:02tr002.hunl (ultimo acceso rvlarzo 2006)
Conradi. R.. Larsen. 1.. Nguyen. M .. Munch. B.. Westby. P .. Zhu. W .. 1accheri. M .. Liu. C. (1994). "EPOS: ObjectOriented 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.
368
~!etrics
gRA-?vlA
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).
DRA.E (2006). DicciOllario de la Real Academia de la Lengua.
Dumke. R. Y Winkler. A. (1997) "CAME Tools for an Efficient Software Maintenance". Proc. of the Euromicro'97.
March 17-19. Berlin.pp. 74-81.
Dunaway. D. K. CJIM S.il -Based Appraisal/or Intemal Process fmprmement. (CBA IPf) Lead Assessor's Guide
(CMUSEl-96-HB-003r Software Engineering Institute. Carnegie Mellon UniYersity. Pinsburgh. 1996.
Dunaway. D. Y Masters. S. (200 I). Cif.illi1 -Based Appraisalfor IlIIemal Process fmpra\'cmelll (CBA IPI). Version
\,'
BIBLIOGR.~FiA Y REFERENCIAS
RA-?vL~
369
Dybil. T.. (2003) "Factors of software process improvement success in small and large organizations: an empirical
FOlllldafions of Sojilrare
study in the scandinavian context"". European Sofnmre Engineering COI!(erencl! (ESEC!
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
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).
Engels. G. Y Groenewegen. L (19941. "SOCCA: Specitlcations of coordinated and cooperative activities'. En
Sojilrare Process .I/ode//ing and Technology (pp. 71-102). Research Studies Press.
English. LP. (1999) flllpro\'ing Data Warehouse and Business Injimnation QualifY: Methodsfor reducing costs and
increasing Pr(jiits. Willey & Sons. 1999.
Eppler.?vl. 1. (2003) :llanaging b!fimnarion Qualizl'. Springer. Gennany. 2003.
Eppler. ?vI. 1. y Muezenmayer. P. (2002). "Measuring Infonnation Quality in the Web Context: A Survey of State-ofthe-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. y Wittig. D. (2000) "Conceptualizing Infommtion Quality: A review of Information Quality
Frameworks !Tom the last ten years." Proceedings orthe ]000 Conference on fn:jimllation Qllalil). Pp 83-96.
Eppler. M.1. (2001a). "Increasing Infommtion Quality through Knowledge
~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
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).
So/ilmre
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
15.3. pp. 182-211.
to
Feigenbaum. A.V. (1961). Toral QualifY Control: Engineering and ,\lonagcmelll. McGraw-HilL Nueva York.
370
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".
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 Canallo. J.P. (2003) "Using Quality Models in Software Package Selection". IEEE S(jfl1mre 20(1):
pp.34-4!.
Fuggeta. A. "Software Process: A roadmap". Thejiilure of'Sofhmre Engineering. ed. A. Finkelstein ACvL Press.
Pp.27-34.2000
Fuggetta. A .. Godart. C. y Jahnke. 1 (1999): "Architectural Views and Alternatives". En Sofhmre Process:
Principles. Methodology and Technology. LNCS 1500. Springer-Verlag. pp. 95-116.
~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.
Gartner (2002). Architeclllre Maturity Assesment Emluation. Gartner. Inc.
Ganin. D. (1984). Hhat is Qualit)':' Sloan Management Review. Otono.
Gendron. M. y DOnofrio. M.J. (2002). "Formulation of a Decision Support Model Using Quality Attributes".
Proceedings of the Set'emh Co/?terence on b!{ol1nation Quality ICIQ2003. pp. 305-316.
Genero M" Pianini M. y Calero M. (Eds.) (2004) .\/etrics/or Sojilrare Conceptual Models. Imperial College Press.
UK. 2004.
Gertz. M .. Tamer.:V1.. Saake. G .. y Sanler. K.. (2004) "Report on the Dagstuhl Seminar 'Data Quality on the web' ".
Proceedings o{SIGJIOD record. 1'01.33. .vo.I. March 2004.
Geno G. (2002). "Risk ivlanagement Supporting Quality ivlanagement of Software Acquisition Projects". En
Daughtrey. T. (Ed.) Fundamental Concepts/or the So/hmre Qualit)' Engineer. (Pp.25-38). Milwaukee. WI: American Society
for Quality.
Giannocaro. A.. Shanks. G. y Darke. P. (1999). "Stakeholder Perceptions of Data Quality in a Data Warehouse
Environment"'. Proceedings ofthe Telllh Australasian Conference on h?/ormatioll Systems .. Pp. 344-355.
Gilb. T. y Graham D. (1993). So/hrare Inspection. London: Addison-Wesley Longman.
Giles. A. Y Barney. D. (1995). "?-.letrics Tools: Software Cost Estimation". CrossTalk: The Journal o/Defense
SO{llrare Engineering. May 1995. httn:' www.stsc.hiILaf.mil crosstalk rrames.asn?uri=199505\letrics.aso (ultimo acceso en
Agosto de 2006).
Giles. A. Y Daich. G. (1995). "Metrics Tools'. Crosstalk. The Journal o{De{ense SofMare Engineering. Febrero.
Goethert. W. (1992). Sojhmre E.{!ort '\/easuremelll: A Framellwk/or Coullling Stat}: HOllrs (ClfU/SEJ-92-TR-2I I.
Software Engineering Institute. Carnegie ivlellon Uniyersity. Pittsburgh. Pa .. September 1992.
Goethert. \Y'. Y Siyiy.1. (2004). "Applications of the Indicador Template for Measurement and Analysis ". Technical
.\'ole CJfLiSEI-2004- T.\'-024. Software Engineering Institute. Septiembre 2004.
Goldenson. D.. Jarzombek. J. y Rout. T. (2003). "Measurement and Analysis in Capability Maturity Model
Integration Models and Software Process Impro\ement". CROSSTALK The Journal of Defense So/hrare Engineering
(Software Engineering Technology). pp. 20-24.
Grady. R.B .. YCasswelL D.L. (1987) So./hmre .I/etries: Establishing a Company- Wide Program. Prentice Hall.
37~
Grembn. J. Y Myers. C. (1997). "The IDEAL Model: .-\ Practical Guide for Improvement". Bridge, Software
Engineering Institute (SE/) publicC/tion.issue three.
Grimmer. 1.J .. y Hinrichs. H. (2001 J. "'-\ methodological approach to data quality management supported by data
mining". Proceedings O/i/II! Sixfh International conterenc!.! on ili/ormatioll Quality. pp. 217-232.
Gnmdy.l y Hoskins. 1 (1998). "Serendipity: integrated environment support for process modelling. enactment and
work coordination". Autoll/ated Software Engillel'l'illg: An Imernational Journal: Special Issue 0/1 Pracess Technology. 5( I).
pp.27-60.
Halstead. 1'v!. H.. (1977) Elell/ellls orSojnmre Science. Else\'ier North Holland. The Netherlands.
Hare!. D. y Politi. 1vl. (1998). J/odel/ing Reactiw Systems ll'ith Statecharts. The Statemate approach. McGraw-HilI.
Hareton. L. y Terence. Y. (2001)....-\ Process Framework for Small Projects". Sojnmre Process Improl'elllelll alld
Practice 6. pp. 67-83.
Harrison R.. Counsell S. y. Nithi. R. (1999). "An Evaluation of the MOOD set of Object-Oriented Software
Metrics". IEEE TrallSactions on SOrMare Engineering. 24(6). pp. 491-496.
Heimbigner. D.. Sunon. S. y Osterweil. L. (1990). "Managing Change in Process-Centered Emironments".
Proceedings ';th ACMSIGSOFT SymposiulII Sojnrare Dewlopmelll EI1\irol1l11eIll5. ACM Software Engineering Notes. vol.
J5. December 1990.
Helfert. "I.. y von yIaur. E. (2002) ".-\ Strategy for Ylanaging Data Quality in data WarehoLlse Systems".
Proceedings o(the Sixth IlIIemational COI!(erence on In/orlllation Quality. pp. 62-76.
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.
"I..
Host.
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
10
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
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\".
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;' vocablila/). International Standards Organization. Ginebra. Suiza.
Process assessmelll -
Part 2: Pe/fonning an
Part 3: Gliidance on
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
'~~~-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. 1519.
Jorgensen. M. y Ylolokken-Ostvold. K. (2006). "How large are software costs overruns" A review of the 1994
CHAOS report". 14017nation and So.fhmre Technology 48. pp. 297-301.
Junkermann. G" Peuschel. B" Schafer. W. y Walt: S. (1994). "MERLIN: Supporting Cooperation in Software
Development Through a Knowledge-Based Environment". En A. finkelstein. 1. Kramer. and B. Nuseibeh. editors. Sofllmre
Process Modelling and Technology. Research Studies Press Limited (1. Wiley).
Juran. J.M. (ed.) (1988).Jurans Quality Control Handbook. 4" ed. Nueva York. McGraw-Hill.
Juran. J.!\1. (ed.) (1995). A History o.OIanagingfor Quality. ASQC Quality Press. Milwaukee.
Juristo. N. y ~'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
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.304310,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.304310,1990.
Kitchenham, B. y Pfleeger, S.L. (1996). "Software Quality: The Elusive Target". IEEE Software 20(1),
enero/febrero,12-21.
Kitchenham, B., (2004) Procedures for Peifonning Systematic Revie....s. Keele University, Technical Report
TRlSE0401.
Kitchenham, B., Pfleeger, S., Pickard, L., Jones, P., Hoaglin, D., EI Emam, K. y Rosenberg, J. (2002). "Preliminary
Guidelines for Empirical Research in Software Engineering". IEEE Transactions 011 Software Engineering, Vol. 28 N8, pp.
721-734.
Kitchenham, B., y Pfleeger, S. (2002) "Principles of Survey Research. Part 5: PopUlations and Samples". ACM
SIGSOFT. Software Engineering Notes, vol. 27, n. 5, pp. 17-20,2002.
Kitchenham, B., y Pfleeger, S. (2002a) "Principles of Survey Research. Part 3: Constructing a Survey Instrument".
ACM SIGSOFT. Software Engineering Notes, vol. 27, n. 2, pp. 20-24, 2002.
Kitchenham, B., y Pfleeger, S. (2002b) "PrinCIples of Survey Research. Part 2: Designing a Survey". AC\1
SIGSOFT. So/tlmre Engineering Notes, vol. 27, n. I, pp. 18-20,2002.
Kitchenham, B., y Pfleeger, S. (2002c) "Principles of Survey Research. Part 4: Questionnaire Evaluation". AC\I
SIGSOFT. Soft....are Engineering Notes, vol. 27, n. 3, pp. 20-23, 2002.
Kitchenham, B., y Pfleeger, S. (2003) "Principles of Survey Research. Part 6: Data Analysis". ACM SIGSOFT.
So/tlmre Engineering Notes, vol. 28, n. 2, pp. 24-27,2003.
Kosar, D. (1999). "Developing a Framework to Manage Data Quality in Healthcare". Proceedings o/the Fourth
Conference on In/onnation Quality ICIQ' 1999, pp. 58-76.
Krause, M. (1994). "Software: A maturity model for automated software testing". Afedical Devices and Diagnostic
Indusfl), Maga::ine, 16(12), pp. 103-108.
Kreutzberg, 1. (2000). "Has quality management any effect on qrtality?-Analysis of quality management by a nonlinear model". Proceedings o/the 2000 Conference on In/onnation Quality, pp. 242-259.
Krogstie, 1., Lindland, O. y Sindre, G. (1995). "Towards a Deeper Understanding of Quality in Requirements
Engineering". CAiSE 1995, Jyvash:yla, Finland, pp. 82-95.
Kruchten, P. (1999) The Rational Unified Process. An Infloduction. Addison-Wesley, 2nd edition.
Kuvaja, P., Simila, 1., Kizanik, L., Bicego, A., Koch, G. y Saukkonen, S. (1994). So/tlmre Process Assessment and
Improvement: The BOOTSTRAP Approach, Blacbvell Business Publishers, Oxford, UK.
Lavazza, L., (2000) "Providing Automated Support for the GQM Measurement Process". IEEE SO/Mare 17(3).
Lawton, G. (2001) "Knowledge Management: Ready for Prime Time?". IEEE Computer 34. FebnlalJ' (2001), pp.
12-14.
378
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
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. 308320.
McCall. 1. A.. Richards. P.K. y Walters GF (1977) FactO/'S ill sojnmre quality. Vols I. II, III: US Rome Air
Development Center Reports NTIS ADiA-049 014.015. 055.
:VlcDermid.1. (1991). Sojnmre Engineering Reference Book. Butterworth Heinemann.
McFeeley. B.. (1996) IDEAL: A User's Guidejor Sojnmre Process Improl'elnelll. tech. report CMU/SEI-96-HB001. 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 Cooperathi. Programma di Ricerca Cofinanziato dal MIUR. http://www.dis.uniromal.it!-dg. (Ultimo acceso
Agosto de 2006).
380
RA-MA
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
Executive Office of the President.
I'
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
Pease. A (1998). Core Plan Representation. version 4.
Penedo. M. H. y Shu. C (1991). "Acquiring experiences with the modelling and implementation of the project lifecycle 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
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
Una perspectim de Ingenieria del Software. 2' edici6n actualizada y ampliada. Madrid, Ra-Ma.
In/ormaticas de Gestion
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.
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. PrenticeHall.
Scheer, A. W. (1998). ARlS- Business Process FramL7Jmrks. Springer.
Schekkennan, J. (2003) "Extended Enterprise Architecture Maturity Model (E2AMM)". Institute for Public
Enterprise Architecture Development. http: www.entemrise-architecture.info (ultimo acceso Agosto de 2006)
Schlenoff. c., Knutilla, A. y Ray. S. (1998). "A Robust Process Ontology for Manufacturing Systems Integration".
Proceedings 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.
the 25'" Int. C04 on Software Engineering (/CSE03). IEEE Computer Society.
0/
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. 506520. 16'" Intemational COIiference on Admnced In/ormation Systems Engineering (C.4iSE 2004). Riga (Letonia) Agosto
1004.
384
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)
Standish
(2001)
Extreme
CHAOS
D.
Standish
Group
1l1ternational.
http:!;\\ww.standishf1roup.com!samole research;PDFpaf1es /extreme cl1aos.pdf(ultimo acceso en Abril de 2006)
En
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.
BIBLlOGRAFiA Y REFERENCIAS
RA-MA
385
Taguchi G., y Wu. Y. (1979) Imroduction to Qtfline Quality COlllrol. Negaya, Japan: Central Japan Quality Control
Association.
Tague, N.R. (2005).
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, BornovaIzmir, Turkey.
Trillium Team (1994). Alodelfor the Telecom Product Developmelll and Support Process Capability. Bell Canada.
Tumey, A.. Grove, B. y McNairm G. (2004). "SPICE For Small Organisations". SofMare Process Improvement and
Practice, 9, pp. 23-31.
Van der Raadt, B., Hoorn, 1.F. y Van Vliet H. (2005). "Alignment and Maturity are siblings in architecture
assessment'". Caise 2005, Pastor, O. y Falcao e Cunha, J. (eds.), LNCS 3520, 357-371.
van Solingen. R. y Berghout E. (1999). The Goal/Question/Metric MetllOd, A Practical Guide for Quality
ImprOl'elnelll ofsofnmre Del-e!opment. London. England: McGraw-Hill International (UK). ISBN 007 709553 7,1999.
van Solingen. R. y Berghout, E. (2001). "Integrating Goal-Oriented Measurement in Industrial Software
Engineering: Industrial Experiences with and Additions to the Goal!Question/Metric Method (GQM),. P;'oceedings Sel'elllh
Intel7lational sofnmre Metrics Symposium (METRlCs'OI). pp. 246-258.
Vilar.
1..
(2006)
Estadistica
2:
resllmenes
Idep!mate f estadistica2!estadistica_2.htrn (ultimo acceso Agosto 2006).
de
los
capitulos.
http://\\'\\w.udc.es
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
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!servicestechnolo!!Viooensource (ultimo acceso en Agosto de 2006).
Wilkin. C y Castleman, I. (2003) "Development of an Instrument to Evaluate the Quality of Delivered Infoffi1ation
Systems". Proceedings o.fthe 36th Hmmii International Conference on System Sciences.
Williams. L. Y Kessler B (2000). "The effects of 'Pair-Pressure' and 'Pair-Learning' ". Proceedings Conference on
So.fMare Engineering Education and Training (CSEE&T 2000). IEEE Computer Society Press: Los Alamitos CA. pp.59-{j5
htto:
Windley P. (2002). eGo\"el?1mel1l Maturity. State of Utah: Salt Lake City UI. 2002: Disponible en
acceso en Agosto de 2006).
!www.windlev.comdocs/eGo\"Crnment~o20e.!aturitv.pdf(ultim0
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
(.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.
ZU5~
INDICE ALFABETICO
A
AHvlQ.189
.A.MFE.39
APEL.132
Arquitectura de Sistemas de Infomlaci6n Integrados. 112
ASQ.14.69
B
Benchmarking. 40. 66
c
CAF.66
CALDEA.303
Calidad de datos. 301
Calidad de la informaci6n. 289
Cali dad de los modelos conceptuales. 261
Calidad de los modelos 16gicos. 273
Calidad de producto software. 73
Calidad de Sistemas de Informaci6n. 75
Cali dad en uso. 84
Calidad extema 84
Calidad intema. 84
Casos de estudio. 346
CBA-IP!. 161
Cielo de vida de sistemas. 150
Cielo de vida software. 141
CrvfMI. 154. 181.214
Compelisoft. 191
Complejidad. 148
Control Estadistico del Proceso. 35
Core Plan Representation. 110
Coste de la calidad. 43
D
Definici6n de Calidad 3
Diagrarna de afinidad. 30
Diagrama de controL 23
Diagrama de dispersi6n. 29
Diagrall1a de matriz. 32
Diagrarna de procesos de decisiones. 33
Diagrama de redes de actividad. 33
Diagrama de relaciones. 31
Diagrama de causa-efeclo. 19
Diagrama de lujo. 19
Diagrama de Pareto. 21
E
Eficiencia. 85
EFQM.62
Encuestas. 73. 353
EnlOmos de Ingenieria del Software. 126
EV AMECAL. 308
Experimentos. 332
F
Factoria de experiencia. 326
Farnilias de estudio. 331
Fiabilidad. 86
Formato de intercambio de proceso. 108
Funcionalidad 85
388
RA-MA
G
Gestion de la calidad total, 49
Gestion de la calidad, 12,58, lSI
Gestion del conocimieto, 319
Goal Question Indicator Metric (GQ(I)}vf), 223
Goal Question Metric (GQivf), 214
Goal-Driven Software Measurement, 223
H
Histograma, 28
Hoja de chequeo, 22
N
Niveles de madurez, 45. 158
p
People-CMA!, 174
Personal Software Process (PSP), 167
Plan de la Calidad, 14
Portabilidad. 88
Practical Sofllmre Management (PSM), 229
Premio Deming, 68
Proceso somvare, 97
Promenade. 114
Puntos funcion, 250
IDEAL 164
IP-tvIAP, 291
ISO 12207, 142
ISO 14598,84,91
ISO 15288, 142, 154
ISO 15504, 179,236
ISO 15939,234
ISO 19011,53
ISO 25000, 83
ISO 9000,12,50,53
ISO 90003. 156
ISO 9001. 56. 59
ISO 9004. 53
ISO 9126. 83. 91
QFD,38
QIP, 326
R
Registros. 14
s
L
SCAl'v!P!. 186
SCE,161
Seis - Sigma. 67
SERE)\:TI1PITY. 136
SMSDM.121
SPADE. 130
Spearmint. 112
SPEi\1. 116
M
Malcom Baldrige Nacional Quality Award. 68
Mantenibi1idad. 87
Manual de la Ca1idad. 14
Medicion del proceso, 237
Medicion del producto. 240
ivledicion del proyecto, 238
Medicion del Software. 199
Metamodelo de proceso software. 106
Metricas. 209. 236
Modelo de madurez de la capacidad (ClvEv!). 158
Modelo de McCalL 81
Modelo de proceso unificado. 110
MoProSoft. 190
MRmps, 188
TDQM.298
Team Sofnmre Process ITSP). 171
TQdM,292
u
Usabilidad. 86
w
WorAjlow Management Coalition. III