TESIS ELIET 25 (Gestion de Calidad)

INSTITUTO SUPERIOR MINERO-METALRGICO
Dr. Antonio Nez Jimnez

METALURGIA-ELECTROMECNICA
CALIDAD DE PRODUCTOS SOFTWARE

MTRICAS APLICADAS
Trabajo de diploma para optar por el ttulo de

Ingeniero Informtico
Autor:
Eliet Pea Nez
Tutores:
Dra. Yiezenia Rosario Ferrer

Dr. Arstides Alejandro Legr Lobaina
Holgun, junio, 2009

Ao del 50 Aniversario del Triunfo de la Revolucin
Cuando puedas medir lo que ests diciendo y expresarlo con
nmeros, ya conoces algo sobre ello; pero cuando no puedas
medirlo, cuando no puedas expresarlo con nmeros, su
conocimiento es precario e insatisfactorio: puede ser el
comienzo del conocimiento, pero apenas ests avanzando
hacia el escenario de la ciencia
Lord Kelvin
2
Declaracin de Autora
Declaro ser autor de la presente tesis y reconozco al ISMM los derechos

patrimoniales de la misma, con carcter exclusivo.
Para que as conste firmamos la presente a los ____ das del mes de Junio del
ao 2009.
Eliet Pea Nez
________________
Firma del Autor
Dra. Yiezenia Rosario Ferrer Dr. Arstides Alejandro Legr Lobaina
____________________________ ___________________________
Firma del Tutor Firma del Tutor
3
Dedicatoria
A mis padres, hermano y dems familiares, con los que tengo

una eterna deuda de gratitud.
A la Revolucin cubana, por hacer realidad los sueos de

tantos jvenes universitarios.
4
Agradecimientos
A nuestro Comandante en Jefe, Fidel Castro Ruz, por

ofrecerme la gran oportunidad de ser partcipe del proceso
social ms extraordinario de la historia y alcanzar las metas
trazadas en mi vida.
A mis tutores, Yiezenia Rosario Ferrer y Arstides Alejandro

Legr Lobaina por sus consejos y enseanzas.
A todos aquellos, que de una forma u otra han contribuido al

desarrollo de este trabajo, es imposible realizar la
culminacin del mismo sin significar mi ms profundo
agradecimiento.
5
Resumen
Actualmente las entidades en Cuba dedicadas a la produccin de software

tienen entre sus principales objetivos desarrollar productos y servicios
informticos de alta calidad. Para poder obtener estos resultados y lograr un
posicionamiento y un reconocimiento en el mercado, es necesaria la
implantacin de Modelos o Estndares de Calidad que garanticen la
comprobacin objetiva de la evaluacin de la calidad de los productos de
software, desarrollados en cada una de las entidades. La premisa principal del
presente trabajo de investigacin es: proponer un conjunto de mtricas
definidas internacionalmente, con el objetivo de que se apliquen durante el
proceso de evaluacin de la calidad de los productos de software, definido.
Adems con el desarrollo del mismo se persigue crear una conciencia en la
utilizacin de las mtricas en la Industria del Software. Para lograr lo antes
expuesto, se realiz un estudio de las mtricas estandarizadas
internacionalmente, de las cuales se seleccionaron, las que conforman la
propuesta y luego se efectu la validacin de la misma, obteniendo como
resultado que la propuesta sea aplicable en entidades dedicadas a la
evaluacin de los productos de software.
6
ndice de Contenidos
Introduccin ...........................................................................................................................11
1.1 Introduccin .................................................................................................................15
1.2 Situacin actual ...........................................................................................................16
1.3 La Industria Cubana del Software ...............................................................................17
1.4 Que es Calidad?........................................................................................................19
1.4.1 Qu es Calidad de Software?.............................................................................19
1.5 Mtricas de Software ...................................................................................................20
1.5.1 Caractersticas de las Mtricas.............................................................................21
1.5.2 Clasificacin de las Mtricas.................................................................................22
1.5.3 Por qu es importante medir? ............................................................................23
1.5.4 Proceso de Medicin ............................................................................................24
1.5.5 Establecimiento de una lnea base .......................................................................25
1.5.6 Mtricas del Proceso ............................................................................................26
1.5.7 Mtricas del Proyecto ...........................................................................................27
1.5.8 Mtricas del Producto ...........................................................................................28
1.6 Mtricas y Calidad .......................................................................................................28
1.6.1 Modelos de Calidad de Software a Nivel Producto ............................................... 29
1.6.2 La Evaluacin de los Productos de Software.........................................................31
1.6.3 Estndar Internacional ISO/IEC 9126....................................................................32
1.6.3.1 Modelo de calidad..........................................................................................33
1.6.3.2 Modelo para la calidad interna y externa .......................................................36
1.6.3.3 Mtricas Externas .........................................................................................37
1.7 Conclusiones ...............................................................................................................43
2.1 Introduccin .................................................................................................................44
2.2 Objetivos de la Propuesta de Solucin........................................................................44
2.3 Roles y responsabilidad de los participantes en el proceso de evaluacin .................45
2.4 Seleccin de las mtricas externas .............................................................................45
2.4.1 Criterios utilizados para la seleccin de las mtricas externas.............................46
2.4.2 Mtricas externas seleccionadas.........................................................................47
2.4.2.1 Mtricas de Funcionalidad .............................................................................47
2.4.2.2 Mtricas de Confiabilidad...............................................................................50
2.4.2.3 Mtricas de Usabilidad...................................................................................58
7
2.5 Descripcin de las fases del Proceso de evaluacin...................................................60
2.5.1 Recopilacin de Datos ..........................................................................................60
2.5.2 Establecimiento de los pesos ...............................................................................61
2.5.3 Clculo de Mtricas ..............................................................................................62
2.5.4 Valoracin de los Resultados de las Mtricas ......................................................64
2.5.5 Veredicto conclusivo .............................................................................................66
2.6 Conclusiones ...............................................................................................................68
3.1 Introduccin .................................................................................................................69
3.2 Gua para la validacin ................................................................................................69
3.3 Conclusiones ...............................................................................................................77
Conclusiones Generales........................................................................................................78
Recomendaciones .................................................................................................................79
Referencias Bibliogrficas ....................................................................................................80
Glosario de Trminos y Siglas...............................................................................................83
Anexos...................................................................................................................................85
Anexo 1 - Definiciones de las Caractersticas y Sub-caractersticas de calidad
propuestas por el estndar ISO/IEC 9126.........................................................................85
Anexo 2 - Tablas contentivas de las mtricas ...................................................................88
Anexo 3 - Plantilla # 1......................................................................................................101
Anexo 4 - Plantilla # 2......................................................................................................105
Anexo 5 - Plantilla # 3......................................................................................................107
Anexo 6 - Plantilla # 4......................................................................................................113
Anexo 7 - Modelo para la recogida de informacin referente al peso de los criterios .....115
Anexo 8 - Modelo para la recogida de informacin referente a la calificacin de los
criterios ............................................................................................................................117
8
ndice de Figuras
Figura 1. Concepto de Mtricas............................................................................................21

Figura 2. Proceso de recopilacin de Mtricas del Software................................................25
Figura 3. Proceso de evaluacin ..........................................................................................32
Figura 4. Relacin entre las normas de las series ISO/IEC 9126 e ISO/IEC 14598 ............34
Figura 5. La Calidad en el Ciclo de Vida...............................................................................35
Figura 6. Modelo para la Calidad Externa e Interna .............................................................36
Figura 7. Niveles de Maduracin ..........................................................................................38
Figura 8. Fases del Proceso de Evaluacin..........................................................................60
Figura 9. Extructura para el Peso .........................................................................................62
9
ndice de Tablas
Tabla 1. Datos de las variables contenidas en las mtricas ................................................61

Tabla 2. Establecimiento del peso ........................................................................................62
Tabla 3. Clculo de mtricas.................................................................................................63
Tabla 4. Puntuacin a las sub-caractersticas.......................................................................65
Tabla 5. Resultado del trabajo de expertos...........................................................................71
Tabla 6. Clculo de la Dispersin (S) para hallar la concordancia entre los expertos ..........72
Tabla 7. Tabla para el clculo de concordancia de Kendall..................................................73
Tabla 8. Tabla de calificacin de cada criterio ......................................................................74
10
Introduccin
En la actualidad el desarrollo del software ha aumentado considerablemente, lo

que hace que sea muy difcil lograr un posicionamiento y un reconocimiento en
el mercado internacional. Esto trae consigo que sea un reto para la Industria
del Software desarrollar las estrategias que le permitan alcanzar un nivel de
calidad realmente alto, por lo que se hace necesario todo un estudio para la
eleccin e implantacin del Modelo o Estndar de Calidad indicado. [ALLIANCE
2007]
En Cuba en los ltimos aos ha habido un auge en el desarrollo de software,

principalmente las empresas han comenzado la automatizacin e
informatizacin de varias reas donde el trabajo con las tecnologas se
desempea con mayor calidad y a corto plazo. Es por ello que el Gobierno
Cubano tiene como una de sus tareas principales desarrollar la Industria
Cubana del Software con el objetivo de informatizar la sociedad e insertarnos
en el mercado de software a nivel mundial. [La informatizacin en Cuba, 2005]
Con los avances cientfico-tcnicos, evidenciados mayormente en la creacin

de productos o servicios para satisfacer la demanda del mercado o de
determinados clientes, aumenta la competencia y por tanto la necesidad de
lograr una buena aceptacin por parte de los usuarios.
Este nivel de aceptacin est estrechamente ligado a la definicin de criterios

que guen el proceso de concepcin y creacin del producto. Partiendo de esto
surge la necesidad de definir cundo un producto, proceso o servicio tiene
calidad.
11
La calidad es un activo estratgico clave, del que dependen la mayor parte de
las organizaciones, no slo para mantener su posicin en el mercado sino
incluso para asegurar su supervivencia. El desarrollo de un producto que
satisfaga, en la mayor medida posible, los requerimientos del cliente, es la
medida de calidad buscada en la produccin.
Una especificacin y evaluacin integral y detallada de la calidad de los

productos de software es un factor clave para asegurar que la calidad sea la
adecuada. Esto se puede lograr definiendo de manera apropiada las
caractersticas de calidad, teniendo en cuenta el propsito del uso del producto
de software en la institucin.
Es importante especificar y evaluar cada caracterstica relevante de la calidad

de los productos de software, cuando esto sea posible, utilizando mediciones
validadas o de amplia aceptacin, que hagan tcnicamente transparente esta
actividad.
En el mundo actualmente existen normas o estndares internacionales para

medir la calidad de los productos de software. En Cuba a pesar de la
existencia de estos, no se han consolidado los conocimientos acerca de las
posibles mtricas a utilizar en el proceso de evaluacin, para medir la calidad
de los productos de software; adems estas no se aplican adecuadamente ni
se hace en correspondencia con la criticidad o nivel de riesgo del producto que
se est evaluando. La no utilizacin correcta de las mtricas para evaluar la
calidad de los productos de software puede provocar la ocurrencia de
desastres tecnolgicos como ha ocurrido a travs de la historia en diferentes
partes del mundo.
A raz del anlisis de todo lo anterior surge la interrogante: Cmo perfeccionar

el proceso de evaluacin de la calidad de los productos de software?
12
Entonces, el Problema Cientfico a resolver es el siguiente: El conjunto de
mtricas que se utilizan en la evaluacin de la Calidad de los Productos de
Software no garantizan un nivel satisfactorio de la calidad de los mismos.
El Objeto de estudio de la investigacin es la Calidad de los Productos de

Software y el Campo de Accin en el que se enfoca la investigacin son Las
Mtricas a aplicar para evaluar la Calidad de los Productos de Software.
Para proporcionarle una solucin al problema analizado se define como

Objetivo General: Proponer un sistema de mtricas que al ser aplicadas
durante el proceso de evaluacin de la calidad de los productos de software,
garanticen un nivel satisfactorio de la calidad de los productos de software.
Del objetivo global se derivan los siguientes Objetivos especficos:
Realizar un estudio de las mtricas estandarizadas internacionalmente

en vista a la seleccin.
Definir la propuesta de las mtricas en un proceso de evaluacin de
productos de software.
Proponer mtodos de evaluacin con la ayuda del empleo de las
mtricas.
Validar la propuesta.
Para el desarrollo de la investigacin se propone la siguiente Idea a Defender:

Si se utilizan las mtricas propuestas que constituyen un sistema funcional,
confiable y usable para evaluar la Calidad de los Productos de Software,
entonces ser posible aumentar la calidad del producto final.
13
Con el objetivo de guiar, controlar y evaluar la investigacin se definieron las
siguientes Tareas de investigacin:
Estudio y anlisis de mtricas estandarizadas internacionalmente

posibles a aplicar.
Seleccin de las mtricas para el desarrollo de la propuesta.
Diseo de una gua y estrategia de aplicacin de las mtricas
seleccionadas.
Anlisis del resultado de los estudios realizados para la aplicacin de la
gua de mtricas, con el objetivo de su validacin.
Esta propuesta traer consigo un mejoramiento de la calidad del producto final,

adems permitir ir perfeccionando el proceso de evaluacin de la calidad de
los productos de software. Actualmente, las entidades en Cuba dedicadas a
evaluar los productos de software no hacen uso de las mtricas propuestas, de
ah la importancia de la investigacin, la novedad y que el resultado obtenido
sea aplicado en las empresas dedicadas a la evaluacin de la calidad de los
La estrategia planteada para conducir la investigacin es del tipo Descriptiva,

ya que se persigue establecer la caracterizacin estructural de un cuerpo de
mtricas y su correlacin para dictaminar un veredicto de aceptacin de un
producto de software.
El presente trabajo de diploma consta de una Introduccin, 3 captulos con la

intencin de realizar una divisin por los contenidos que sern tratados, las
conclusiones generales, recomendaciones, referencias bibliogrficas utilizadas
durante el desarrollo del trabajo, un glosario de trminos y siglas y por ltimo
los anexos que complementan el cuerpo del trabajo y que son necesarios para
su entendimiento.
14
Captulo 1: Fundamentacin Terica. En este captulo se hace un anlisis de la
actualidad internacional y nacional sobre el tema Calidad del Software y las
Mtricas del Software profundizando en los trminos referentes al mismo,
adems se abordan las principales definiciones que se tienen en cuenta
durante todo el trabajo.
Captulo 2: Descripcin de la Propuesta de Solucin. En este captulo se

presentan las mtricas propuestas, el proceso de evaluacin para la aplicacin
de las mtricas, en el cual se describen cada uno de los elementos que
componen el proceso y se detallan los pasos que se realizan en la evaluacin.
Captulo 3: Validacin de la Propuesta de Solucin. En este captulo se

determina la probabilidad de xito que tiene la propuesta, para esto se realizan
un conjunto de clculos los cuales se detallan con el objetivo de lograr un
mayor entendimiento.
15
CAPTULO
1
FUNDAMENTACIN TERICA
1.1 Introduccin
La empresa de software cubana an siendo joven rene sus esfuerzos para

desarrollar software de calidad con los que pueda insertarse en el mercado
mundial. Un factor decisivo en el logro de este objetivo es el aseguramiento
(garanta) de calidad de un producto de software, determinado por el conjunto
de actividades planificadas y sistemticas necesarias para aportar la confianza
en que el producto (software) satisfar los requisitos dados de calidad.
Actividades como la Gestin de la Configuracin del Software , la Verificacin

y Validacin del Software a lo largo del ciclo de vida y el uso de las Mtricas
de Software en el control de Proyecto como herramienta fundamental a la hora
de garantizar calidad del producto. Actualmente el trmino mtricas de software
est siendo ampliamente difundido y utilizado. En el presente captulo, se hace
un anlisis crtico del concepto de mtrica y todo lo referente a este tema en
cuanto al estado del arte en el mundo, y en Cuba, adems se abordan los
trminos que sirven de soporte terico a la investigacin desarrollada y que
estarn presentes a lo largo de este trabajo.
16
1.2 Situacin actual
En la actualidad el uso de las mtricas se est poniendo en prctica con xito

en el amplio mercado del software pues las empresas productoras estn
reconociendo la importancia que tienen las mediciones para cuantificar y por
consiguiente gestionar de forma ms efectiva la calidad de los productos de
software.
Es vlido aclarar que en ocasiones los resultados de los procesos de medicin

no son interpretados de la mejor manera, pues an existen compaas que no
tienen una cultura adecuada sobre la medicin, desconociendo el alcance de
calidad que pudiera alcanzar el producto final.
Varios estndares han incluido a las mtricas de software, a continuacin se

mencionan algunos de ellos.
ISO 15504
Incluye dentro de la categora de los procesos organizacionales (en la segunda
parte de la norma) al proceso de medicin, incluyendo la definicin de mtricas,
la gestin de los datos (incluidos los histricos), y el uso de las mtricas en la
organizacin.
Familia ISO 9000

Se establece la necesidad de implementar el proceso de medicin con el
objetivo de controlar la calidad del producto, la capacidad del proceso y la
satisfaccin del cliente, la gestin usa mtricas como una entrada fundamental
para la planificacin, control y gestin del proyecto.
17
ISO/IEC 9126
Las normas de las familias ISO/IEC 9126 (Calidad de los productos de
software) y de la ISO/IEC 14598 (Evaluacin de los productos de software). Las
caractersticas de calidad de los productos de software definidas en esta parte
de la ISO/IEC 9126 pueden ser utilizadas para especificar tanto los requisitos
funcionales como no funcionales de los clientes y usuarios.
A pesar de la existencia de mtricas para evaluar la calidad de los productos de

software, en una encuesta realizada sobre el nivel de conocimiento en el tema,
en el sitio Web www.CalidaddelSoftware.com integrado por ms de 900
miembros de los cuales el 83% son de Espaa y 14% de Iberoamrica, cuyo
objetivo es mantener en contacto a personas y organizaciones interesadas en
la Calidad y la Mejora del Proceso Software, se pregunt: Sobre qu cree que
hay mayor carencia de conocimientos? El mayor porciento de votos entre las
nueve reas propuestas fue para la respuesta estimacin y mtricas con un
26.84%. [Encuestas]
Es un problema la gran variedad de mtricas que existen y que en la mayora

de los casos no se tiene un conocimiento explcito de sus objetivos y la manera
en que puedan aplicarse. Cada empresa es responsable de definir las mtricas
que va a implantar, teniendo en cuenta sus objetivos organizacionales y
necesidades de informacin, las mtricas deben estar alineadas con el
calendario, costo y niveles de calidad propuestos.
1.3 La Industria Cubana del Software
La Industria Cubana del Software (ICSW) est llamada a convertirse en una

significativa fuente de ingresos nacional, como resultado del correcto
aprovechamiento de las ventajas del considerable capital humano disponible.
Las Universidades cubanas juegan un papel importante en el desarrollo de la
ICSW, y en la materializacin de los proyectos asociados al programa cubano
de informatizacin. [La informatizacin en Cuba, 2005]
18
La preparacin de los recursos humanos especializados para las Tecnologas
de la Informtica y las Comunicaciones (TIC) es un factor clave de la estrategia
cubana de Informatizacin. Adems de las especialidades afines a la
Informtica en 17 de las universidades y 16 Institutos Superiores Pedaggico
(ISP), tambin se cuenta con la Universidad de las Ciencias Informticas (UCI),
con los 26 Institutos Politcnicos de Informtica (IPI) donde estudian ya ms de
40 000 estudiantes y la preparacin en los 600 Joven Club de Computacin
presentes en todos los municipios del pas que constituyen un intensivo para
todos los trabajadores y estudiantes que deseen incursionar en el mundo de las
computadoras, facilitando el desarrollo y aplicacin de la informtica en esferas
especficas correspondientes a un municipio o localidad determinada. [La
informatizacin en Cuba, 2005]
Sin embargo a pesar del capital humano y desarrollo tecnolgico con que
cuentan las empresas de software, en muchas ocasiones no se realizan
actividades relacionadas a la gestin del proyecto, la gestin de la
configuracin, la gestin de la calidad y las mediciones.
En estudios realizados por Centros de Estudios de Ingeniera de Sistemas

(CEIS) en empresas nacionales se detectaron problemas entre los que se
encuentran: los resultados alcanzados no cubren las expectativas, la
productividad es baja, la cantidad real de recursos a consumir (en tiempo
principalmente) es casi impredecible, el trabajo realizado casi nunca tiene la
calidad y profesionalidad requerida, los proyectos sufren atrasos excesivos y no
existen antecedentes de datos histricos sobre la calidad de los productos que
han sido elaborados. [Acosta 2007]
Entre tantos problemas identificados las empresas de software cubanas estn

dando los primeros pasos en el perfeccionamiento de la gestin de la calidad
con el objetivo de poder certificarse o al menos alcanzar algn nivel de
madurez para evolucionar y mejorar sus procesos desde procesos inmaduros a
procesos disciplinados, maduros con calidad, eficiencia mejorada y probada.
19
1.4 Que es Calidad?
El Diccionario de la Real Academia Espaola, concepta la Calidad como la

"propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar
su valor", y es sinnimo de "buena calidad" la "superioridad o excelencia".
[Infocalidad, 2005]
Por su parte, la ISO (International Organization for Standardization
Organizacin Internacional para la Estandarizacin), agrega otros aspectos
importantes a tener en cuenta cuando define la calidad como el conjunto de
propiedades y de caractersticas de un producto o servicio, que le confieren
aptitud para satisfacer unas necesidades explcitas o implcitas.
Las definiciones anteriores conducen a la siguiente conclusin:
Calidad, resume las caractersticas, propiedades, cualidades y en general

atributos propios de un producto, que determinan sobre este la ausencia de
defectos y la conformidad de todo el personal que de una forma y otra se
vinculan con l, (productores, clientes, usuarios, etc.). La calidad consiste en no
tener deficiencias.
1.4.1 Qu es Calidad de Software?
Se define la calidad de software como la ausencia de errores de

funcionamiento, la adecuacin a las necesidades del usuario, y el alcance de
un desempeo apropiado (tiempo, volumen, espacio), adems del
cumplimiento de los estndares. Los objetivos que la calidad persigue son: La
aceptacin (utilizacin real por parte del usuario) y la Mantenibilidad
(posibilidad y facilidad de correccin, ajuste y modificacin durante largo
tiempo). [Ingeniera del software, 2005]
La Calidad del Software es la concordancia con los requisitos funcionales y de
rendimiento explcitamente establecidos, con los estndares de desarrollo
explcitamente documentados y con las caractersticas implcitas que se espera
de todo software desarrollado profesionalmente. Es el conjunto de
caractersticas de una entidad que le confieren su aptitud para satisfacer las
necesidades expresadas y las implcitas. [Pressman, 1998]
20
Las definiciones anteriores conducen a las siguientes conclusiones:
La principal muestra de calidad es que el usuario quede satisfecho con

el producto.
La aplicacin de estndares es un factor importante en la obtencin de

productos con calidad.
Existen un conjunto de caractersticas que tienen que estar implcitas en

productos que tengan calidad.
1.5 Mtricas de Software
Todas las organizaciones de software exitosas implementan mediciones como

parte de sus actividades cotidianas pues estas brindan la informacin objetiva
necesaria para la toma de decisiones y que tendr un impacto efectivo en el
negocio y desempeo en la ingeniera.
Para poder asegurar que un proceso o sus productos resultantes son de

calidad o poder compararlos, es necesario asignar valores, descriptores,
indicadores o algn otro mecanismo mediante el cual se pueda llevar a cabo
dicha comparacin.
Para entender mejor el concepto de mtrica es necesario aclarar que los

trminos, mtricas, medicin y medida no tienen el mismo significado.
Medida: Proporciona una indicacin cuantitativa de la extensin, cantidad,

dimensiones, capacidad o tamao de algunos atributos de un proceso o
producto. [Pressman, 1998]
21
Medicin: La medicin es el acto de determinar una medida. [Pressman, 1998]
Mtrica: Es una medida cuantitativa del grado en que un sistema, componente

o proceso posee un atributo dado. [Pressman, 1998]
Se definen las mtricas de software como La aplicacin continua de

mediciones basadas en tcnicas para el proceso de desarrollo del software y
sus productos, para suministrar informacin relevante a tiempo, as el
administrador con el empleo de ests tcnicas mejorar el proceso y sus
productos.
Para una definicin ms completa deben incluirse los servicios relacionados al

software como la respuesta a los resultados del cliente (Ver Figura 1).
Figura 1. Concepto de Mtricas
1.5.1 Caractersticas de las Mtricas
Para que sea til en el contexto del mundo real, una mtrica del software debe
ser objetiva, simple y calculable, consistente en el empleo de unidades y
tamaos, persuasiva, adems debera ser independiente del lenguaje de
programacin y proporcionar una realimentacin eficaz para el desarrollador de
software. [Pressman, 1998]
22
Por qu asegurarnos de que las mtricas cumplen estas condiciones?
Las mtricas deben ser un instrumento que ayude a mejorar el proceso,

producto o proyecto de software, no tiene mucho sentido aplicar mtricas que
lejos de ayudar a los desarrolladores constituyan un problema; bien por ser
demasiado complejas, porque no se entiendan correctamente los objetivos que
persiguen o porque arrojen resultados imprecisos que no puedan ser
interpretados por los ingenieros de software.
Es importante entonces que una mtrica pueda obtenerse fcilmente, que se

entienda por qu y para qu se utiliza, que los clculos no produzcan
resultados ambiguos o en los que existan extraas combinaciones de
unidades, y que la interpretacin de valores obtenidos est acorde a las
nociones intuitivas del ingeniero de software o especialista. Por otra parte las
mtricas no deben ser especficas para ningn lenguaje de programacin o
metodologa de desarrollo.
1.5.2 Por qu es importante medir?
Una de las razones principales del incremento masivo en el inters por la

medicin de software ha sido la percepcin de que las mtricas son necesarias
para la mejora de la calidad del proceso.
Hay cuatro razones para medir los procesos del software, los productos y los
recursos [Pressman, 1998]:
1 Caracterizar: Para comprender mejor los procesos, los productos, los

recursos y los entornos y para establecer las lneas base para las
comparaciones con evaluaciones futuras.
2 Evaluar: Para determinar el estado con respecto al diseo. Las medidas
permiten conocer cundo los proyectos y procesos estn perdiendo la pista,
de modo que puedan ponerse bajo control. Adems para valorar si se
cumplen o no los objetivos de calidad trazados y para evaluar el impacto de
la tecnologa y las mejoras en los productos y procesos.
23
3 Predecir: Para poder planificar. Los valores que se observan para
algunos atributos pueden ser utilizados para predecir otros, lo que
contribuye a establecer objetivos alcanzables para el coste, planificacin y
calidad, de manera que se puedan aplicar los recursos apropiados,
adems permite analizar los riesgos y realizar intercambios diseo -
coste.
4 Mejorar: Se mide para mejorar cuando se recoge la informacin
cuantitativa que ayuda a identificar obstculos, problemas de raz,
ineficiencias y otras oportunidades para mejorar la calidad del producto y
el rendimiento del proceso.
1.5.3 Clasificacin de las Mtricas
Existen innumerables mtricas con propsitos diferentes que reflejan o

describen la conducta del software, estas pueden medir entre otros aspectos la
competencia, calidad, desempeo y la complejidad del software contribuyendo
a establecer de una manera sistemtica y objetiva una visin interna del trabajo
mejorando as la calidad del producto.
A continuacin se muestra la clasificacin de las mismas:
Mtricas de complejidad: Son todas las mtricas de software que definen de

una u otra forma la medicin de la complejidad; tales como volumen, tamao,
anidaciones, costo (estimacin) y configuracin. Estas son los puntos crticos
de la concepcin, viabilidad, anlisis, y diseo de software.
Mtricas de competencia: Son todas las mtricas que intentan valorar o medir
las actividades de productividad de los programadores o practicantes con
respecto a su certeza, rapidez, eficiencia y competencia.
Mtricas de desempeo: Corresponden a las mtricas que miden la conducta

de mdulos y sistemas de un software, bajo la supervisin del sistema
operativo o hardware. Generalmente tienen que ver con la eficiencia de
24
ejecucin, tiempo, almacenamiento, complejidad de algoritmos
computacionales, etc.
Mtricas estilizadas: Son las mtricas de experimentacin y de preferencia; por

ejemplo: estilo de cdigo, las limitaciones, etc. Pero estas no se deben
confundir con las mtricas de calidad o complejidad.
Mtricas de calidad: Son todas las mtricas de software que definen de una u
otra forma la calidad del software; tales como exactitud, estructuracin o
modularidad, pruebas, mantenimiento, reusabilidad, entre otras. Estas son los
puntos crticos en el diseo, codificacin, pruebas y mantenimiento.
Estas clasificaciones de mtricas fortalecen la idea, de que ms de una mtrica

puede ser deseable para valorar la complejidad y la calidad del software,
teniendo en cuenta que para ello es necesario medir los atributos del software.
1.5.4 Proceso de Medicin
Todo proceso de medicin del software tiene como objetivo fundamental

satisfacer necesidades de informacin a partir de las cuales se deben
identificar las entidades y los atributos que deben ser medidos.
El proceso de medicin, se caracteriza en cinco actividades [Pressman, 2002]:
1. Formulacin: Obtencin de medidas y mtricas del software apropiadas

para la presentacin del software en cuestin.
2. Coleccin: Mecanismo empleado para acumular datos necesarios para
obtener las mtricas formuladas.
3. Anlisis: Clculo de las mtricas y la aplicacin de herramientas
matemticas.
4. Interpretacin: La evaluacin de los resultados de las mtricas en un
esfuerzo por conseguir una visin interna de la calidad de la
presentacin.
5. Retroalimentacin: Recomendaciones obtenidas de la interpretacin de
mtricas y tcnicas transmitidas al equipo de desarrollo de software.
25
1.5.5 Establecimiento de una lnea base
Un punto de partida para realizar estimaciones es establecer una lnea base de

mtricas que permita a una organizacin sintonizar su proceso de ingeniera
del software para eliminar las causas de los defectos que tienen el mayor
impacto en el desarrollo del software, es fundamental que una lnea base
contenga datos recopilados de proyectos desarrollados anteriormente lo que
requiere una investigacin histrica de los mismos, la lnea base no es ms que
la recopilacin de medidas, mtricas e indicadores que guen el proyecto o el
proceso.
Figura 2. Proceso de recopilacin de Mtricas del Software
Por lo general la informacin reunida no necesariamente tiene que ser

diferente. Las mismas mtricas pueden obtener beneficios a nivel de proceso,
proyecto y producto.
26
1.5.6 Mtricas del Proceso
Las mtricas del proceso se recopilan de todos los proyectos y durante un largo
perodo de tiempo. Su intento es proporcionar indicadores que lleven a mejoras
de los procesos de software a largo plazo. [Pressman, 1998] Un indicador es
una mtrica o una combinacin de mtricas que proporcionan una visin
profunda del proceso del software, del proyecto de software o del producto en
si.
La medicin del proceso implica las mediciones de las actividades relacionadas

con el software siendo algunos de sus atributos tpicos el esfuerzo, el coste y
los defectos encontrados. Las mtricas permiten tener una visin profunda del
proceso de software que ayudar a tomar decisiones ms fundamentadas,
ayudan a analizar el trabajo desarrollado, conocer si se ha mejorado o no con
respecto a proyectos anteriores, ayudan a detectar reas con problemas para
poder remediarlos a tiempo y a realizar mejores estimaciones.
Para mejorar un proceso se deben medir los atributos del mismo, desarrollar
mtricas de acuerdo a estos atributos y utilizarlas para proporcionar
indicadores que conduzcan la mejora del proceso. Los errores detectados
antes de la entrega del software, la productividad, recursos y tiempo consumido
y ajuste con la planificacin son algunos de los resultados que pueden medirse
en el proceso, as como las tareas especficas de la ingeniera del software.
Actualmente existen muchas mtricas, y stas deben usarse conforme se
ajusten al proceso.
Las mtricas del proceso se caracterizan por:
1 El control y ejecucin del proyecto.

2 Medicin de tiempos del anlisis, diseo, implementacin, implantacin y
postimplantacin.
3 Medicin de las pruebas (errores, cubrimiento, resultado en nmero de
defectos y nmero de xito).
4 Medicin de la transformacin o evolucin del producto.
27
1.5.7 Mtricas del Proyecto
Dado que el proyecto engloba todos los recursos, actividades y artefactos, que
se organizan para lograr un producto de software es de vital importancia definir
algunas mediciones que ayuden al mejoramiento del mismo. A nivel de
proyecto se minimiza la planificacin de desarrollo haciendo los ajustes
necesarios para evitar retrasos o riesgos potenciales, minimizar los defectos, y
por tanto la cantidad de trabajo que ha de rehacerse, lo que ocasiona una
reduccin del coste global del proyecto, adems puede evaluarse la calidad de
los productos en el momento actual y cuando sea necesario.
La primera aplicacin de mtricas de proyectos en la mayora de los proyectos

de software ocurre durante la estimacin. Las mtricas recopiladas de
proyectos anteriores se utilizan como una base desde la que se realizan las
estimaciones del esfuerzo y del tiempo para el actual trabajo del software. A
medida que avanza un proyecto, las medidas del esfuerzo y del tiempo
consumido se comparan con las estimaciones originales (y la planificacin de
proyectos). El gestor de proyectos utiliza estos datos para supervisar y
controlar el avance. A medida que comienza el trabajo tcnico, otras mtricas
de proyectos comienzan a tener significado. Se miden los ndices de
produccin representados mediante pginas de documentacin, las horas de
revisin, los puntos de funcin y las lneas fuentes entregadas, en el proyecto
se sigue la pista de los errores detectados durante todas las tareas de
ingeniera del software. Cuando va evolucionando el software desde la
especificacin del diseo, se recopilan las mtricas tcnicas para evaluar la
calidad del mismo y para proporcionar indicadores que influirn en el enfoque
tomado para la generacin y prueba del cdigo. [Pressman, 1997]
Las mtricas del proyecto se caracterizan por:
1 Evaluar el estado del proyecto en curso.

2 Seguir la pista de los riesgos potenciales.
28
3 Detectar las reas de problemas antes de que se conviertan en
crticas.
4 Ajustar el flujo y las tareas del trabajo.
5 Evaluar la habilidad del equipo del proyecto en controlar la calidad de los
productos de trabajo del software.
1.5.8 Mtricas del Producto
Las mtricas del producto se centran en las caractersticas del software y no en

cmo fue producido. Un producto no es solo el software o sistema funcionando
sino tambin los artefactos, documentos, modelos, mdulos, o componentes
que lo conforman, por tanto, las mtricas del producto deben hacerse sobre la
base de medir cada uno de estos.
Las mtricas del producto son mediciones del producto software. Esta
definicin incluye el tamao del producto, la complejidad de la estructura lgica
y la complejidad de estructuras de datos, entre otros. Adems est
estrechamente relacionada con las mediciones del proceso. [Rossi 2003]
1.6 Mtricas y Calidad
El principal objetivo de los ingenieros del software es producir un sistema,

aplicacin o producto de alta calidad, para lo cual emplean mtodos y
herramientas efectivas dentro del contexto de un proceso maduro de desarrollo
del software y adems deben desarrollar mediciones que den como resultado
sistemas de alta calidad. Para obtener esta evaluacin, el ingeniero debe
utilizar medidas tcnicas, que evalan la calidad con objetividad, no con
subjetividad.
[Acosta 2007]
29
1.6.1 Modelos de Calidad del Software a Nivel Producto
Modelo FURPS
El modelo FURPS propuesto por Robert Grady y Heweltt Packard Co (HP)

cuenta con 5 caractersticas de calidad del software: (1) Funcionalidad,
(2) Facilidad de uso, (3) Confiabilidad, (4) Performance y (5) Facilidad de
soporte. Adems plantea 2 categoras de requerimientos, las cuales son:
1- requerimientos funcionales (F): especifican funciones que el sistema debe
ser capaz de realizar, sin tomar restricciones fsicas a consideracin, y se
definen a travs de las entradas y salidas esperadas.
2- requerimientos no funcionales (URPS): Usability (Facilidad de uso),
Reliability(Confiabilidad), Performance y Supportability (Facilidad de soporte).
Describen atributos del sistema o atributos del ambiente del sistema. [Scalone
2006]
Modelo GQM (Goal Que stion - Metric)
El modelo GQM (objetivo-pregunta- mtrica /goal question - metric)

de Basili y Rombach es una propuesta de objetivos / metas orientado a
la definicin de modelos de calidad. Se propone el paradigma GQM para
evaluar la calidad de cada proyecto. Este modelo utiliza una propuesta
para definir un modelo de calidad hasta obtener las mtricas respectivas
con el anlisis e interpretacin de los datos de las mediciones
respectivas. Plantea el enfoque de medicin para evaluar la calidad
del software basado en la identificacin de objetivos a lograr.[Scalone 2006]
30
Modelo de McCall
Hace ms de 25 aos se definieron factores de calidad como los primeros

pasos hacia el desarrollo de mtricas de calidad del software. El modelo de
McCall organiza los factores en tres ejes o puntos de vista desde los cuales el
usuario puede contemplar la calidad de un producto (1) Operacin del
producto, (2) Revisin del producto y (3) Transicin del producto. Cada punto
de vista se descompone en una serie de factores que determinan la calidad de
cada una de ellos. Cada factor determinante de la calidad, se descompone, a
su vez, en una serie de criterios o propiedades que determinan su calidad.
Los criterios pueden ser evaluados mediante un conjunto de mtricas y para
cada criterio deben fijarse unos valores mximo y mnimo
aceptables.[Scalone 2006]
Modelo de BOEHM
El modelo de Boehm (1978) agrega algunas caractersticas a las existentes en

el modelo de McCall y representa una estructura jerrquica de
caractersticas, cada una de las cuales contribuye a la calidad total.
Consiste en un modelo de descomposicin de caractersticas de calidad
del software en 3 niveles (usos principales, componentes intermedios y
componentes primitivos) previos a la aplicacin de mtricas. Este modelo
plantea factores de calidad formados por criterios de calidad y mtricas
respectivas.[Scalone 2006]
31
La calidad de un sistema, aplicacin o producto es tan buena como los
requisitos que describen el problema, el diseo que modela la solucin, el
cdigo que conduce a un programa ejecutable y las pruebas que ejercitan el
software para detectar errores, en este sentido los desarrolladores deben
realizar y utilizar mediciones. Para alcanzar esta evaluacin de la calidad en
tiempo real, se deben utilizar medidas tcnicas que evalan la calidad con
objetividad, no con subjetividad.
A pesar de que se pueden recolectar varias medidas de calidad, el primero de
los objetivos en el proyecto es medir los errores y defectos. Las mtricas que
provienen de estas medidas proporcionan una indicacin de la efectividad de
las actividades de control y de aseguramiento de la calidad en grupos o en
particulares. [Pressman, 2002]
1.6.2 La Evaluacin de los Productos de Software
La norma ISO/IEC 14598 (Evaluacin de los productos de software) establece

un proceso de evaluacin, que se muestra simplificadamente en la estructura
de la Figura 3, a partir de cuatro subprocesos bsicos:
Establecer los requisitos de la evaluacin.
Especificar la evaluacin.
Disear la evaluacin.
Ejecutar la evaluacin.
32
Figura 3. Proceso de evaluacin
Aunque la norma brinda estos amplios conceptos, no quedan bien definidos los
elementos relacionados con Establecer criterios de valoracin y Valorar
resultados, lo cual se sustentar ms detalladamente en la propuesta.
1.6.3 Estndar Internacional ISO/IEC 9126
La ISO/IEC 9126 es un estndar internacional para la evaluacin del software.

Es supervisado por el proyecto SquaRE (Security Quality Requirements
Engineering - Ingeniera de Requisitos de Calidad de Seguridad) y la ISO
25000:2005, que siguen los mismos conceptos generales.
33
El estndar se divide en cuatro partes que trata, respectivamente, los temas
siguientes: modelo de la calidad interna y externa; mtricas externas; mtricas
internas; y modelo de la calidad durante el uso.
Este estndar proviene del modelo establecido en 1977 por McCall y sus
colegas, propuesto para especificar la calidad del software. A pesar de que es
uno de los ms antiguos se ha extendido en todo el mundo y de l han
derivado muchos otros como el de Boehm (1978) o el SQM (Software Quality
Management) de Murine (1988) [Antonio, 2002].
1.6.3.1 Modelo de calidad
El modelo que describe para la calidad de los productos software se divide en

dos partes: a) calidad interna y externa, b) calidad durante el uso. Se
especifican seis caractersticas para la calidad interna y externa, que son
adems divididas en sub-caractersticas que se manifiestan externamente
cuando el software se usa como una parte del sistema computarizado, y son un
resultado de los atributos o cualidades internos del software. Para la calidad
durante el uso se definen cuatro caractersticas. La calidad durante el uso es el
efecto combinado que percibe el usuario de la calidad interna y externa del
software. [NC-ISO/IEC 9126-1, 2005]
La interrelacin entre las normas ISO/IEC 9126 y las normas de la serie

ISO/IEC 14598 se muestra en la Figura 4.
34
Figura 4. Relacin entre las normas de las series ISO/IEC 9126
e ISO/IEC 14598
La calidad de cualquiera de los procesos del ciclo de vida, contribuye a mejorar

la calidad del producto, y esta a su vez contribuye a mejorar la calidad en el
uso. Por consiguiente, evaluar y mejorar un proceso es un medio para mejorar
la calidad del producto; la evaluacin y mejora de la calidad del producto son
una va para mejorar la calidad durante el uso (Ver Figura 5). De igual modo, la
evaluacin de la calidad durante el uso permite la retroalimentacin para
mejorar un producto, y cuando se produce la evaluacin permite la
retroalimentacin para mejorar un proceso. [NC-ISO/IEC 9126-1, 2005]
35
Figura 5. La calidad en el ciclo de vida
Como muestra la Figura 5, las mtricas internas pueden ser aplicadas a los
productos intermedios que se desarrollan a lo largo del ciclo de vida de
desarrollo de un producto software, tales como solicitud de propuesta,
especificacin de requisitos, especificaciones de diseo o cdigo fuente. Las
mtricas internas le proporcionan a los desarrolladores la habilidad de medir la
calidad de estos productos intermedios, con lo cual se puede predecir la
calidad del producto final. Esto le permite a los desarrolladores identificar los
problemas que afecten la calidad e iniciar las acciones correctivas en las
etapas tempranas del ciclo de vida de desarrollo del producto. [ISO/IEC 9126-2,
2003]
Por su lado, las mtricas externas pueden ser usadas para medir la calidad del
producto software a travs de la medicin del comportamiento del sistema del
cual el software forma parte (Figura5). Las mtricas externas solo pueden ser
usadas durante las etapas de pruebas del proceso ciclo de vida y durante
cualquier otra etapa operacional. [ISO/IEC 9126-2, 2003]
Por ltimo, las mtricas de calidad en uso (Figura 5) miden si un producto

resuelve las necesidades de usuarios especficos para alcanzar metas
especficas con eficacia, productividad, seguridad y satisfaccin en un contexto
especfico de uso. Esto solo puede lograrse en un entorno real del sistema.
[ISO/IEC 9126-2, 2003]
36
Las necesidades de calidad del usuario pueden ser especificadas como
requisitos de calidad a travs de las mtricas de calidad en uso, las mtricas
externas y algunas veces las mtricas internas. Estos requisitos especificados
por las mtricas deben ser usados como criterios cuando el producto se evala.
[ISO/IEC 9126-2, 2003]
Es recomendable usar mtricas internas que tengan una relacin lo ms fuerte

posible con los objetivos de las mtricas externas, as ellas pueden ser usadas
para predecir los valores de las mtricas externas. Sin embargo, a menudo es
difcil disear un modelo terico riguroso que proporcione una relacin fuerte
entre las mtricas internas y externas. [ISO/IEC 9126-2, 2003]
1.6.3.2 Modelo para la calidad interna y externa
Este modelo se ha desarrollado en un intento de identificar los atributos ms

importantes para la calidad interna y externa en un producto software. El
modelo identifica seis caractersticas claves de calidad [NC-ISO/IEC 9126-1,
2005] donde cada una de ellas se descomponen en un conjunto de sub-
caractersticas como se muestra en la Figura 6.
Figura 6. Modelo para la calidad Interna y Externa
37
1.6.3.3 Mtricas Externas
Las mtricas externas usan valores de un producto del software derivados de

las medidas del comportamiento del sistema del que es parte al probar, operar
u observar el software o sistema ejecutable. Estos valores se emplean como
base de la medicin para la posterior evaluacin del software. Antes de
adquirir o usar un producto del software, el mismo debe evaluarse usando
mtricas basadas en objetivos comerciales relacionados al uso, explotacin y
gestin del producto en un ambiente organizacional y tcnico especificado.
Estas son las mtricas externas primarias y de ellas se da una relacin en las
Tablas contentivas de las mtricas de la ISO/IEC TR 9126-2. Las mismas
constituyen una ventaja para los usuarios, evaluadores, verificadores, y
diseadores pues le permiten medir la calidad del producto de software a
travs de la medicin del comportamiento del sistema del cual l forma parte,
as como evaluar la calidad del producto de software durante las pruebas o la
operacin. [NC ISO/IEC 9126-1, 2005]
Se recomienda utilizar mtricas internas que tengan una relacin tan fuerte
como sea posible con las mtricas externas planificadas, para que aquellas
puedan usarse para predecir los valores de las mtricas externas. Por supuesto
es generalmente difcil de disear un modelo terico riguroso que proporcione
una relacin slida entre las mtricas internas y las externas. [NC-ISO/IEC
9126-1, 2005]
En el presente trabajo se adoptan las mtricas externas correspondientes a las

caractersticas funcionalidad, confiabilidad y usabilidad, fundamentales para un
primer nivel de madurez, se arriba a una Gua para la aplicacin de mtricas
y la interpretacin de las mismas con los fines de la evaluacin de los
38
Optimizando
Proceso de (5)
Mejora continua
Proceso Gestionado
Predecible (4)
Proceso Definido
Consistente (3)
Proceso Repetible
Disciplinado (2)
Inicial
(1)
Fig 7. Niveles de maduracin
Un nivel de madurez es un sistema evolutivo y bien definido para alcanzar el

proceso de madurez de software. Cada nivel de madurez tiene dentro de si
mismo parmetros que permiten la mejora continua. Alcanzar cierto nivel
significa seguir en busca de mejores prcticas, lograr un producto controlado,
verificable, validado, medido y a la vez mantener los logros alcanzados.
[Cueva 1999]
1. Las mtricas para la medicin de la caracterstica

funcionalidad
Las mtricas externas de funcionalidad deben ser capaces de medir un atributo

como es el comportamiento funcional del sistema en el cual el software est
presente. Estas son:
1.1 Mtricas de idoneidad
Las mtricas externas de idoneidad deben ser capaces de medir un atributo

como es la ocurrencia de un funcionamiento insatisfactorio o la ocurrencia de
una operacin insatisfactoria.
39
Un funcionamiento u operacin insatisfactoria puede ser:
Funcionamiento u operacin que no se desempea de la forma especificada

en el Manual de usuario o la especificacin de requisitos.
Funcionamiento u operacin que no provee una salida aceptable o razonable
al tomar en consideracin un objetivo especfico de las tareas del usuario.
1.2 Mtricas de exactitud
Las mtricas externas de precisin deben ser capaces de medir un atributo

como es la frecuencia con que los usuarios se encuentren con la ocurrencia de
una falta de exactitud o de precisin, como pueden ser:
Resultados incorrecto o imprecisos causados por datos inadecuados; por

ejemplo, un dato con pocos dgitos significativos para un clculo de precisin.
Inconsistencia entre el procedimiento de operacin actual y el descrito en el
manual de operacin.
Diferencias entre el resultado actual y el razonablemente esperado producto
de una tarea ejecutada durante la operacin.
1.3 Mtricas de interoperabilidad
Las mtricas externas de interoperabilidad deben ser capaces de medir un

atributo como es el nmero de funciones o la ocurrencia de la menor
incomunicacin que involucre a datos y comandos o instrucciones que sean
transferidos entre el producto de software y otros sistemas, otros productos de
software u otros equipos a los cuales est conectado.
1.4 Mtricas de seguridad (informtica)
Las mtricas externas de seguridad (de la informacin o informtica) no se han

incluido para el primer nivel de maduracin objeto del presente trabajo.
40
1.5 Mtricas de conformidad de la funcionalidad
Las mtricas externas de conformidad de la funcionalidad deben ser capaces

de medir un atributo como lo es el nmero de funciones con dificultades en la
conformidad (o la ocurrencia de problemas de conformidad) con las
regulaciones, normas u otras convenciones relacionadas, lo cual haga que el
producto de software falle en adherirse a las mismas. Estas mtricas no se
incluyen para el primer nivel de maduracin objeto de este trabajo.
2. Las mtricas para la medicin de la caracterstica

confiabilidad
Las mtricas externas de confiabilidad deben ser capaces de medir atributos

relacionados con el comportamiento del sistema del cual el software forma
parte durante la ejecucin de las pruebas para indicar la magnitud de la
confiabilidad, o sea, seguridad de funcionamiento del software durante la
operacin del sistema, con las que en la mayor parte de los casos no se
distingue entre el software y el sistema. Ellas son:
2.1 Mtricas de madurez
Las mtricas externas de madurez deben ser capaces de medir un atributo

como la exencin de fallas en el software, causados por la ocurrencia de fallos
existentes en el propio software.
2.2 Mtricas de tolerancia ante fallos
Las mtricas externas de tolerancia ante fallos deben estar relacionadas con la
capacidad del software de mantener un nivel de ejecucin especfico en casos
de fallos de operacin, o se infrinjan las interfaces especificadas.
2.3 Mtricas de recuperabilidad
Las mtricas externas de recuperabilidad deben ser capaces de medir aquellos

atributos como son los software y sistemas capaces de reestablecer su nivel
adecuado de ejecucin y recuperar los datos directamente afectados en casos
de fallos totales.
41
2.4 Mtricas de conformidad de la confiabilidad
Las mtricas externas de conformidad de la confiabilidad deben ser capaces de

medir un atributo como lo es la cantidad de funciones con dificultades en la
conformidad, o la ocurrencia de problemas de conformidad con las
regulaciones, normas u otras convenciones relacionadas con la confiabilidad o
seguridad de funcionamiento. Dichas mtricas no se incluyen para un primer
nivel de maduracin del presente trabajo.
3. Las mtricas para la medicin de la caracterstica usabilidad
Las mtricas externas de usabilidad miden la dimensin con que el software

puede ser comprendido, estudiado, operado, atractivo y concordante con las
regulaciones y guas relativas a la usabilidad.
Resulta recomendable que la evaluacin de estas mtricas se haga por un

grupo (7, 8, aunque menores pueden obtener informacin de utilidad) de
usuarios o evaluadores usuarios simulados o clonados (pero representativos de
un rango de usuarios) sin que reciban asistencia externa alguna. A
continuacin se brindan las que en una primera etapa sern objeto de
utilizacin.
3.1 Mtricas de comprensibilidad
Las mtricas externas de comprensibilidad deben ser capaces de valorar cmo

un nuevo usuario podra comprender:
Si el software es idneo para la aplicacin a la cual lo destina.

Cmo el software puede ser usado para una tarea en particular.
42
3.2 Mtricas de cognoscibilidad
Las mtricas externas de cognoscibilidad (para medir el grado en que puede

ser estudiado) y las de operabilidad (para medir el grado en que puede ser
implementado y operado) emplean mtodos de aplicacin eminentemente de
usuarios y no son idneas para el empleo por terceros en una evaluacin de
certificacin, por lo que no se abordan en el presente trabajo.
3.3 Mtricas de atraccin
Las mtricas externas de atraccin deben ser capaces de evaluar la apariencia

del software, y van a estar influenciadas por factores tales como el color en la
pantalla y su diseo.
3.4 Mtricas de conformidad de la usabilidad
Las mtricas externas de conformidad de la usabilidad deben ser capaces de

evaluar la adherencia del software a las regulaciones, normas, convenciones,
guas y estilos relativos la usabilidad. Estas mtricas no se incluyen en este
trabajo.
43
1.7 Conclusiones
A nivel mundial la Industria de Software ha potenciado un gran

desarrollo, siendo una de las prioridades lograr la calidad en sus
productos y servicios, para lo cual centran sus esfuerzos en la mejora de
los procesos de desarrollo teniendo en cuenta modelos, normas,
estndares.
Uno de los factores que influyen en la calidad del software es la
utilizacin de mediciones que permitan analizar, evaluar, predecir y
mejorar los procesos y productos, proporcionando informacin valiosa
para la toma de decisiones y la evaluacin del estado en que se
encuentran los objetivos fijados.
La ISO/IEC TR 9126-2 proporciona un conjunto de mtricas a travs de
las cuales se podr comenzar a evaluar los productos de software a
partir de elementos cuantitativos y no solos con elementos cualitativos o
por deteccin de defectos como se ha venido haciendo hasta el
presente.
44
CAPTULO
2
DESCRIPCIN DE LA PROPUESTA DE SOLUCIN
2.1 Introduccin
En este captulo se realiza la descripcin de la propuesta que tiene como

objetivo el presente trabajo, para ello se describen los roles y responsabilidad
de las personas implicadas en el proceso de evaluacin, se definen las fases
necesarias para establecer una evaluacin con calidad, dentro de estos se
adaptan las mtricas estandarizadas internacionalmente seleccionadas para el
proceso de evaluacin y se establecen los artefactos que se utilizarn para la
recogida de informacin.
2.2 Objetivos de la Propuesta de Solucin
Proporcionar una gua para un proceso de evaluacin que facilite:
Una seleccin de mtricas, tanto preliminar para un primer nivel de

madurez del grupo evaluador o entidad de software, como dinmica
durante el proceso de evaluacin, y orientar su mejor aplicacin.
Interpretar el resultado de la medicin de cada una de ellas.
A partir de los resultados de todas las mtricas que se hayan aplicado,
desarrollar un mtodo de valoracin de resultados para el producto de
software en su conjunto, obtenido con una tcnica de trabajo en grupo.
45
2.3 Roles y responsabilidad de los participantes en el proceso
de evaluacin
Teniendo en cuenta las funciones a realizar en todo el proceso de evaluacin

y la necesidad participativa de especialistas en el mismo, con el objetivo de
optimizar las tareas se definen los siguientes roles y responsabilidades
involucradas:
Lder del Equipo de Evaluacin y Calidad del Software: Responsable de

la evaluacin, debe estar capacitado y autorizado por el Asesor de
Calidad de la Entidad y debe asegurar que:
9 El proceso de evaluacin sea realizado conforme a la Gua

propuesta y que los resultados de sta sean representativos.
9 Los datos de la evaluacin sean registrados en el formato

adecuado para la evaluacin y conforme con lo indicado en la gua.
Equipo Evaluador: Personas con experiencias en Ingeniera de Software,

slidos conocimientos de la gua, el nmero de integrantes depender
de la complejidad del proyecto o la urgencia con que se realice la
evaluacin, estos realizan las siguientes actividades, recoleccin de
informacin, realizacin de la evaluacin e informacin del estado actual
del proyecto. Los integrantes sern:
9 Lder evaluador de la caracterstica Funcionalidad.
9 Lder evaluador de la caracterstica Confiabilidad.
9 Lder evaluador de la caracterstica Usabilidad.
Coordinador del proyecto: Miembro del proyecto encargado de

representarlo en la evaluacin.
2.4 Seleccin de las mtricas externas
Luego de realizar un detallado anlisis de las mtricas externas primarias

contenidas en las Tablas contentivas de mtricas de la ISO/IEC TR 9126-2 se
ha procedido a realizar una seleccin para propiciar su aplicacin en la
46
prctica, de modo escalonado y por niveles de madurez de la organizacin o
entidad donde se implanten.
2.4.1 Criterios utilizados para la seleccin de las mtricas

externas
Para seleccionar las mtricas se efectuaron varios pasos los cuales se

especifican a continuacin:
1er Paso Seleccionar las caractersticas a evaluar:

9 Para este primer nivel de madurez fueron seleccionadas las
caractersticas Funcionalidad, Confiabilidad y Usabilidad ya que la
NC ISO/IEC 12119 Tecnologa de la Informacin-Paquetes de
Software-Requisitos de Calidad y Pruebas (ISO 12119: 1994, IDT),
plantea que la evaluacin de las 3 caractersticas mencionadas
anteriormente no se puede dejar de realizar por ser esenciales en el
proceso de evaluacin de Calidad.
2do Paso Seleccionar las sub-caractersticas de las caractersticas
seleccionadas:
Fueron seleccionadas de la caracterstica Funcionalidad las sub-

caractersticas:
9 Idoneidad
9 Exactitud
9 Interoperabilidad
Fueron elegidas de la caracterstica Confiabilidad las sub-caractersticas:

9 Madurez
9 Tolerancia ante fallos
9 Recuperabilidad
Fueron escogidas de la caracterstica Usabilidad las sub-caractersticas:

9 Comprensibilidad
9 Atraccin
47
3er Paso Seleccionar las Mtricas de las sub-caractersticas
seleccionadas:
9 Se escogieron la gran mayora de las mtricas contenidas en
cada una de las sub-caractersticas seleccionadas, las cuales se
describen en el sub-epgrafe 2.4.2; algunas mtricas no fueron
elegidas por su complejidad. En total se hizo una seleccin de 26
mtricas.
2.4.2 Mtricas externas seleccionadas
A continuacin se detallan las mtricas que han sido seleccionadas del

conjunto de mtricas estandarizadas internacionalmente definidas en la
ISO/IEC TR 9126-2. En el Anexo 2 se presenta una tabla resumen con las
mtricas propuestas.
2.4.2.1 Mtricas de Funcionalidad
1.1 Idoneidad
a) Adecuacin funcional
Se propone la mtrica (1.1.a) que permite hacer un anlisis de cun adecuada

es la funcin evaluada.
Se define la mtrica como:
X = 1 - A/B
Donde:
A -Nmero de funciones en las cuales se detectaron problemas en la
evaluacin.
B -Nmero de funciones evaluadas.
48
b) Completitud de la implementacin funcional
Del conjunto de mtricas que presenta la sub-caracterstica Idoneidad,

tambin se propone la mtrica (1.1.b) que permite realizar una evaluacin de
cun completa ha sido la implementacin y su conformidad con la
especificacin de requisitos.
X = 1 - A/B
Donde:
A - Nmero de funciones perdidas detectadas en la evaluacin.
B - Nmero de funciones descritas en la especificacin de requisitos.
c) Cobertura de la implementacin funcional
Adems se propone la mtrica (1.1.c) que permite hacer un anlisis de cun

correcta ha sido la implementacin funcional.
X = 1 - A/B
Donde:
A - Nmero de funciones incorrectamente implementadas o funciones perdidas
detectadas.
B - Nmero de funciones descritas en la especificacin de requisitos.
1.2 Exactitud
a) Exactitud esperada
49
Se incluye en la gua la mtrica (1.2.a) que permite hacer un anlisis de las
diferencias entre los resultados actuales y los razonablemente esperados.
X = A/T
Donde:
A - Nmero de casos encontrados con diferencias entre los resultados
razonablemente esperados y aquellos resultantes ms all de lo permisible.
T - Tiempo de operacin.
1.3 Interoperabilidad
a) Intercambiabilidad de datos, en base a su formato
Tambin se propone emplear la mtrica (1.3.a) que permite realizar un anlisis

de cun correctamente ha sido implementado el intercambio de funciones de
interfaces para una transferencia de datos especfica.
X= A/B
Donde:
A - Nmero de formatos de datos intercambiados exitosamente con otros
software o sistemas durante las pruebas del intercambio de datos.
B - Nmero total de formatos de datos a intercambiar.
b) Intercambiabilidad de datos, en base al xito del intento
Se propone la mtrica (1.3.b.1) que permite hacer un anlisis de cun

frecuentemente fall el intento de intercambio de datos entre el software objeto
de la prueba y otro software.
50
1) X = 1 - A/B
Donde:
A - Nmero de casos en que se fall al proceder a un intercambio de datos con
otros software o sistemas.
B - Nmero de casos en que se intent proceder a un intercambio de datos.
Adems se propone la mtrica (1.3.b.2) que permite hacer un anlisis de cun

frecuentemente es satisfactoria la transferencia de datos entre el software
objeto de la prueba y otro.
2) Y = A / T
Donde:
A - Nmero de casos en que se fall al proceder a un intercambio de datos con
otros software o sistemas.
T - Perodo de tiempo de operacin.
2.4.2.2 Mtricas de Confiabilidad
2.1 Madurez
a) Latencia estimada de la intensidad de fallos
Se propone la mtrica (2.1.a) que permite determinar cuntos problemas an

existen que pueden emerger como futuros fallos.

X = (ABS (A1- A2)) / B
51
Donde:
ABS () - Valor absoluto.
A1 - Nmero total de fallos latentes predecibles en el producto de software.
A2 -Nmero total de fallos detectados realmente.
B - Tamao del producto.
b) Intensidad de fallos totales contra casos de prueba
Tambin se propone la mtrica (2.1.b) que permite determinar cuntos fallos

totales fueron detectados durante un perodo de pruebas definido.
X = A1 / A2
Donde:
A1 - Nmero total de fallos totales detectados.
A2 - Nmero de casos de pruebas ejecutados.
c) Grado de solucin ante fallos totales
Se propone la mtrica (2.1.c) que permite determinar cuntas condiciones de

fallo total estn resueltas.
X = A1 / A2
Donde:
A1 - Nmero de fallos totales solucionados.
A2 - Nmero total de problemas reales detectados.
52
d) Intensidad de fallos
Se incluye la mtrica (2.1.d) que permite determinar cuntos fallos fueron
detectados durante un perodo de pruebas definido.
X=A/ B
Donde:
A - Nmero total de fallos detectados.
e) Erradicacin de fallos
Se propone la mtrica (2.1.e.1) que permite determinar cuntos fallos han sido
corregidos.
1) X = A1 / A2
Donde:
A1 - Nmero de fallos solucionados.
A2 - Nmero total de fallos reales detectados.
Tambin se propone la mtrica (2.1.e.2).
2) Y = A1 /A3
Donde:
A1 - Nmero de fallos solucionados.
A3 - Nmero total de fallos latentes pronosticados.
53
f) Tiempo medio entre fallos totales
Se propone la mtrica (2.1.f.1) que permite realizar un anlisis de cun

frecuentemente el software fracasa en su operacin.
1) X = T1 / A
Donde:
T1 Tiempo de operacin.
A - Nmero total de fallos realmente detectados (fallos totales ocurridos
durante el tiempo de operacin observado).
Adems se propone la mtrica (2.1.f.2).
2) Y = T2 /A
Donde:
T2 Suma de los intervalos de tiempo entre los fallos totales consecutivos
producidos.
A - Nmero total de fallos realmente detectados (fallos totales ocurridos
durante el tiempo de operacin observado).
g) Cobertura de las pruebas
Se propone la mtrica (2.1.g) que permite hacer un anlisis de cuntos casos

de pruebas requeridos han sido ejecutados, detectados durante las pruebas.
54
X=A/ B
Donde:
A Nmero de casos de pruebas que han sido realmente ejecutados, y que
representan el escenario de operacin durante las pruebas.
B Nmero de casos de pruebas a ejecutar requeridos para cubrir los
requisitos.
h) Madurez de las pruebas
Se propone la mtrica (2.1.h) que permite determinar si est bien probado el

producto.
X=A/ B
Donde:
A Nmero de casos de pruebas que han obtenido un resultado satisfactorio al
ser ejecutados o durante su operacin.
B Nmero de casos de pruebas a ejecutar para cubrir los requisitos.
2.2 Tolerancia ante fallos
a) Evitacin de desastre
Se propone la mtrica (2.2.a) que permite hacer un anlisis de cun

frecuentemente el producto de software causa un desastre en el ambiente de la
produccin total.

X = 1- A /B
Donde:
A - Nmero de desastres.
B - Nmero de fallos totales.
55
b) Evitacin de operaciones incorrectas
Se propone la mtrica (2.2.b) que permite determinar cuntas funciones estn

implementadas con capacidad de evitacin de operaciones incorrectas.
X=A/B
Donde:
A - Nmero de ocurrencia de fallos totales crticos o serios evitada.
B - Nmero de casos de pruebas ejecutados a los patrones de operaciones
incorrectas (casi causantes de fallos) durante las pruebas.
2.3 Recuperabilidad
a) Grado de disponibilidad
Se propone la mtrica (2.3.a) que permite determinar cun disponible est el

sistema para su uso durante.
1) X = (To/To+Tr)
Donde:
To Tiempo de operacin.
Tr Tiempo de reparacin.
b) Tiempo medio de inactividad
La mtrica (2.3.b) tambin se propone, la cual permite determinar cul es el

tiempo promedio en que el sistema se mantiene no disponible cuando ocurre
un fallo total y antes de la arrancada gradual.
56
X=T/N
Donde:
T - Tiempo total de inactividad.
N - Nmero de desastres observados.
c) Tiempo medio de recuperacin
Se incluye la mtrica (2.3.c), esta permite determinar cul es el tiempo

promedio que toma el sistema para completar la recuperacin desde el inicio
de la recuperacin parcial.
X = SUM (Tn) / N
Donde:
T - Tiempo de recuperacin de la inactividad en cada n oportunidad.
N - Nmero de oportunidades en que el sistema entr en recuperacin.
d) Recargabilidad
Se propone la mtrica (2.3.d) que permite hacer un anlisis de cun

frecuentemente el sistema logra recargar luego de una ejecucin perdida
proveyendo nuevamente los servicios a los usuarios en el plazo de tiempo
previsto.
X= A/B
57
Donde:
A - Nmero de veces que se provoc el reinicio o recarga en el plazo de
tiempo previsto en la prueba especificada o en la implantacin.
B - Nmero total de veces que se provoc el reinicio o recarga durante la
prueba especificada o la implantacin.
e) Restaurabilidad
Se propone la mtrica (2.3.e) que permite hacer un anlisis de cun capaz es

el producto de auto restaurarse luego de un evento anormal o una solicitud.
X= A/B
Donde:
A Nmero de casos de restauracin exitosos.
B Nmero de casos de restauracin probados por los requisitos.
f) Efectividad de la restauracin
Se propone la mtrica (2.3.f) que permite hacer un anlisis de cun efectiva es

la capacidad de restauracin.
X= A/B
Donde:
A Nmero de casos de restauracin exitosos en el plazo de tiempo previsto.
B Nmero de casos de restauracin ejecutados.
58
2.4.2.3 Mtricas de Usabilidad
3.1 Comprensibilidad
a) Integridad de la descripcin de producto
Se propone la mtrica (3.1.a) que permite determinar qu proporcin de

funciones (o tipos de funciones) son comprendidas despus de leer la
descripcin del producto.
X=A/B
Donde:
A - Nmero de funciones comprendidas.
B - Nmero total de funciones.
b) Accesibilidad a demos
Se propone la mtrica (3.1.b) que permite hacer un anlisis de a qu

proporcin de demos/tutoriales pueden acceder los usuarios.
X=A/B
Donde:
A - Nmero de demos/tutoriales a los que pueden acceder los usuarios
exitosamente.
B - Nmero total de demos/tutoriales a los que se puede acceder.
59
c) Comprensibilidad de entradas y salidas
Tambin se propone la mtrica (3.1.c) que permite hacer un anlisis si pueden

los usuarios comprender lo que se requiere como entrada y lo que suministra el
sistema de software como salida.

X=A/B
Donde:
A - Nmero de elementos de entrada y que suministra el sistema de software
como salida comprendidas correctamente.
B - Nmero total de elementos de entrada y que suministra el sistema de
software como salida proporcionadas por el interfaz.
3.2 Atraccin
a) Adaptabilidad de la apariencia de la interfaz
Se propone la mtrica (3.2.b) que permite hacer un anlisis de qu proporcin

de los elementos de las interfaz puede ser, por su apariencia, adaptado por el
usuario para la satisfaccin del mismo.
X=A/ B
Donde:
A - Nmero de elementos de la interfaz del sistema cuya apariencia puede ser
adaptada por el usuario.
B - Nmero de elementos de la interfaz del sistema cuya apariencia querra
adaptar el usuario.
60
2.5 Descripcin de las fases del Proceso de evaluacin
En este sub-epgrafe se definen las diferentes fases que componen el proceso

de evaluacin sugerido para la aplicacin de las mtricas, el cual consta de 5
fases (Ver Figura 7), a continuacin se detallan cada una de ellas:
Figura 8. Fases del Proceso de evaluacin
2.5.1 Recopilacin de Datos
En esta fase se recopilan los datos de las variables implicadas en las frmulas
de medicin de las mtricas, para esto se brinda una plantilla # 1 (Ver Anexo
3) que es una tabla con el nombre de las mtricas y el significado de sus
correspondientes variables, que deben ser obtenidas en los procesos de
pruebas.
61
A continuacin se muestra un ejemplo de un fragmento de la plantilla # 1:
Tabla 1. Datos de las variables contenidas en las mtricas
Mtricas de Idoneidad
Nombre de la Variables Datos

mtrica
a) Adecuacin A - Nmero de funciones en las cuales se detectaron problemas en A=5
funcional la evaluacin.
B - Nmero de funciones evaluadas. B=8
Mtrica de Exactitud

mtrica
a) Exactitud A - Nmero de casos encontrados con diferencias entre los A=6
esperada resultados razonablemente esperados y aquellos resultantes ms
all de lo permisible. T=9
Mtricas de Interoperabilidad

mtrica
a) Intercam- A - Nmero de formatos de datos intercambiados exitosamente con A=4
biabilidad otros software o sistemas durante las pruebas del intercambio de
de datos, en datos.
base a su B - Nmero total de formatos de datos a intercambiar. B=5
formato
2.5.2 Establecimiento de los pesos
Despus de haber recopilado los datos de las variables se procede al

establecimiento de los pesos que posee cada sub-caracterstica en el proyecto
de software sometido a evaluacin, para ello se ofrece una plantilla # 2 (Ver
Anexo 4) para reflejar los resultados de este anlisis. Este peso lo establece el
evaluador antes de realizar los clculos de las mtricas, en dependencia de la
importancia que tenga la sub-caracterstica que se est evaluando sobre el
producto, se sugiere para el peso la siguiente estructura: 2 si la relevancia es
alta, 1 si es media y 0 si es baja (Ver Figura 8).
62
Figura 9. Estructura para el peso
A continuacin se muestra un ejemplo de un fragmento de la plantilla # 2 para

el establecimiento del peso:
Tabla 2. Establecimiento del peso

CARACTERISTICA SUBCARACTERISTICA PESOS METRICAS NIVEL RESUL-
REQUE- TADO
RIDO REAL
Funcionalidad Idoneidad 2 1.1.a) 1
X = 1 - A/B (0 <= X <= 1)
Exactitud 2 1.2.a) 0
X = A/T (0 <= X)
Interoperabilidad 2 1.3.a) 1
X= A/B (0 <= X <= 1)
2.5.3 Clculo de Mtricas
Una vez recopilados los datos y establecido el peso se prosigue con el clculo
de las mtricas. En esta fase se utiliza la plantilla # 2 (Ver Anexo 4) para
guardar los resultados del clculo de mtricas.
el clculo de las mtricas:
63
Tabla 3. Clculo de mtricas
CARACTERISTICA SUBCARACTERISTICA PESOS METRICAS NIVEL RESUL-
REQUE- TADO
RIDO REAL
Funcionalidad Idoneidad 2 1.1.a) 1 0.375
X = 1 - A/B (0 <= X <= 1)
Exactitud 2 1.2.a) 0 0.66

X = A/T (0 <= X)
Interoperabilidad 2 1.3.a) 1 0.8

X= A/B (0 <= X <= 1)
Escala para cuando el nivel requerido es 1
Rango Evaluacin Puntuacin

0 - 0,2 Mal 0
0,3 0,5 Regular 1
0,6 0,7 Bien 2
0,8- 1 Muy Bien 3
Escala para cuando el nivel requerido es 0
Rango Evaluacin Puntuacin

0 - 0,2 Muy Bien 3
0,3 0,5 Bien 2
0,6 0,7 Regular 1
0,8- 1 Mal 0
El resultado del clculo de la mtrica 1.1.a) es 0.375 y el nivel requerido es 1,

este resultado del clculo se ubica en la Tabla de la Escala para cuando el
nivel requerido es 1 y la puntacin que se le dara a la sub-caracterstica
Idoneidad en la plantilla # 3 es 1 (Regular).
El resultado del clculo de la mtrica 1.2.a) es 0.66 y el nivel requerido es 0,

este resultado del clculo se ubica en la Tabla de la Escala para cuando el
nivel requerido es 0 y la puntacin que se le dara a la sub-caracterstica
Exactitud en la plantilla # 3 es 1 (Regular).
El resultado del clculo de la mtrica 1.3.a) es 0.8 y el nivel requerido es 1, este

resultado del clculo se ubica en la Tabla de la Escala para cuando el nivel
64
requerido es 1 y la puntacin que se le dara a la sub-caracterstica
Interoperabilidad en la plantilla # 3 es 3 (Muy Bien).
Nota: Esta puntacin que se le da a las sub-caractersticas se hace teniendo
en cuenta el peso de la misma. En el caso de que el peso de una sub-
caracterstica sea 0 (Baja Relevancia) entonces se le da una puntuacin directa
de 3 (Muy Bien). En el caso de que el peso sea 1 o 2 entonces la puntuacin
ser la obtenida despus de llevar a las Tablas de las Escalas. En el caso de
que a una sub-caracterstica se le evale ms de una mtrica entonces el
resultado del clculo de las mtricas evaluadas se ubica en las Tablas de
Escalas, segn su nivel requerido, se halla el promedio entre los resultados
obtenidos despus de haber llevado a la escala y este valor del promedio ser
la puntuacin que se le dar a esa sub-caracterstica.
2.5.4 Valoracin de los Resultados de las Mtricas
Despus de haberse hecho el clculo de las mtricas se hace una valoracin

de los resultados de las pruebas y el comportamiento de las caractersticas de
calidad. Es decir se le da una puntacin a cada una de las sub-caractersticas
segn el resultado del clculo de las mtricas de esa sub-caracterstica y el
peso que tenga dicha sub-caracterstica en el producto de software que se est
evaluando, este peso lo establece el evaluador antes de realizar los clculos, el
resultado del clculo de las mtricas despus de haberse llevado a las Tablas
de la Escala, segn el nivel requerido y el peso se verifican en la plantilla # 2
(Ver Anexo 4). Luego se hace un resumen individual del resultado de cada
caracterstica, esto seria hallar el promedio entre las puntaciones de las sub-
caracterstica correspondientes a cada caracterstica, en caso del promedio
haber dado un nmero decimal se redondea a un nmero entero. Una vez
realizado este procedimiento se llega a una conclusin sobre el grado de
conformidad que tiene cada caracterstica sobre el producto que se est
evaluando, ste grado de conformidad se determina por el resultado del
promedio; y finalmente segn el grado de conformidad se emite un criterio de
evaluacin para dicha caracterstica. Todo este proceso lo hace el evaluador de
cada caracterstica a evaluar. Se provee una plantilla # 3 (Ver Anexo 5) a
utilizar en esta fase.
65
darle una puntuacin a cada una de las sub-caractersticas de la caracterstica
funcionalidad:
Tabla 4. Puntuacin a las sub-caractersticas
CARACTERISTICAS Y SUBCARACTERISTICAS DE CALIDAD PUNTUACION

3 2 1 0
1. FUNCIONALIDAD
1.1 Idoneidad. Capacidad del software para mantener un conjunto apropiado X
de funciones para las tareas y los objetivos del usuario especificados.
a) Funcionamiento correcto (ausencia de fallos totales ciclos infinitos,
interrupcin de la ejecucin o salidas abruptas-, errores crticos, errores de
ejecucin, resultados incorrectos, correspondencia de las descripciones con
los objetos, por ejemplo en el nivel de ayuda solicitado o los mensajes de
error segn el fallo detectado )
b) Correspondencia de las funciones con los requisitos funcionales de la
Descripcin del software (especificaciones)
1.2 Exactitud. Capacidad del software para proporcionar efectos o resultados X
correctos o convenidos con el grado de exactitud necesario.
a) Exactitud de los clculos

1.3 Interoperabilidad. Capacidad del producto de software para interactuar X
recprocamente con uno o ms sistemas especificados.
a) Funcionamiento correcto al interactuar (ausencia de fallos totales ciclos
infinitos, interrupcin de la ejecucin o salidas abruptas-, errores crticos,
errores de ejecucin, resultados incorrectos,)
Esto es otro ejemplo de la plantilla # 3 para hacer el resumen individual del

resultado de la caracterstica funcionalidad:
Despus de darle una puntacin a cada sub-caracterstica de la caracterstica

Funcionalidad se halla el promedio entre ellas, sera:
Promedio = (Puntacin Sub-caracterstica Idoneidad + Puntacin Sub-

caracterstica Exactitud + Puntacin Sub-caracterstica
Interoperabilidad)/3 = 1 + 1 + 3 = 5/3 = 1.66
66
El resultado del promedio es 1.66 redondeado es 2, por tanto el grado de
conformidad es Suficientemente conforme (2) y el criterio de evaluacin es
Pequeas modificaciones.
GRADO DE CONFORMIDAD
PUNTUACION 3 Conforme
2 Suficientemente
Funcionalidad 1.66 conforme
VALOR 2 1 Medianamente
conforme
0 No conforme
CRITERIO DE EVALUACION
( ) Sin modificaciones
( x ) Pequeas modificaciones
( ) Grandes modificaciones
( ) Nueva elaboracin
2.5.5 Veredicto conclusivo

En esta fase ya se llega a una conclusin final sobre el grado de aceptacin
que tiene el producto que se esta evaluando. Es decir despus de haberse
hecho un resumen individual del grado de conformidad de cada caracterstica
evaluada se llega a un veredicto conclusivo. En dicha fase se halla una
puntuacin promedia a partir de la individual de cada caracterstica evaluada,
en caso que el promedio sea un nmero decimal se lleva a un nmero entero.
Luego se toma el grado de conformidad por cada caracterstica, es decir por
cada seccin. Finalmente se llega a un veredicto sobre el grado de aceptacin
que tiene el producto, este grado puede ser aceptado, diferido o no aceptado.
Para esta fase se har uso de la plantilla # 4 (Ver Anexo 6).

hallar una Puntacin promedio a partir de la individual de cada caracterstica:
Suponiendo que se hizo el mismo procedimiento de la caracterstica

Funcionalidad para las caractersticas Confiabilidad y Usabilidad, cada una con
un promedio individual de 3 y 2 respectivamente. Una vez obtenidos los
67
promedios individuales entonces se puede hallar el promedio de las 3
caractersticas, sera:
Promedio = (Puntacin Caracterstica Funcionalidad + Puntacin
Caracterstica Confiabilidad + Puntacin Caracterstica Usabilidad)/3 = 2
+ 3 + 2 = 7/3 = 2.33
El resultado del promedio es 2.33 redondeado es 2.
PUNTUACION PROMEDIADA A PARTIR DE LA INDIVIDUAL
Funcionalidad 2
Confiabilidad 3
Usabilidad 2
VALOR* 2
GRADOS DE CONFORMIDAD POR SECCIONES (poner una X)

Seccin A ( ) Conforme
(X) Suficientemente conforme
( ) Medianamente conforme
( ) No conforme
Seccin B (X) Conforme
( ) Suficientemente conforme
( ) No conforme
Seccin C ( ) Conforme
(X) Suficientemente conforme
( ) No conforme
VEREDICTO
ACEPTADO
DIFERIDO
NO ACEPTADO
68
2.6 Conclusiones
En este captulo se desarroll la propuesta de solucin, obtenindose una gua

para la aplicacin de las mtricas propuestas. Para su creacin se definieron
los objetivos de la misma, los cuales se enfocaron en la obtencin de calidad
del producto final; se identificaron los roles y responsabilidades de cada rol, los
cuales se adaptaron a las caractersticas claves que debe poseer un producto
de software con calidad; se hizo la seleccin de las mtricas; se definieron las
fases que componen la gua del proceso de evaluacin para la aplicacin de
las mtricas seleccionadas, en las cuales se especificaron los artefactos que se
utilizarn para la recogida de informacin.
El desarrollo de la propuesta fue guiada por la ISO/IEC TR 9126-2 existente en

el mundo y que tiene resultados a nivel internacional, por lo que se espera que
si se aplica la misma se obtengan las siguientes ventajas:
Fcil comprensin.
Aumento de la calidad del producto final.
Determinacin del nivel de calidad real del producto.
69
CAPTULO
3
VALIDACIN DE LA PROPUESTA DE SOLUCIN
3.1 Introduccin
Para realizar la validacin de la propuesta de solucin, se utiliz el Mtodo de

Experto el cul se basa en la evaluacin cuantitativa de criterios definidos, que
permite realizar un estudio por expertos para determinar si se acepta o no la
propuesta analizada.
3.2 Gua para la validacin
Para llevar a cabo el desarrollo de la validacin se efectuaron un conjunto de

pasos, los cuales se detallan a continuacin:
1. Se elaboran los criterios de evaluacin que fueron utilizados en la validacin,

estos se agrupan por categoras.
Grupo No 1: Criterios de mrito cientfico.
1. Valor cientfico de la propuesta.

2. Calidad de la investigacin.
3. Contribucin cientfica.
4. Responsabilidad cientfica y profesionalidad de los investigadores.
Grupo No 2: Criterios de implantacin.
5. Necesidad de empleo de la propuesta.

6. Posibilidades de aplicacin.
70
Grupo No 3: Criterios de flexibilidad.
7. Adaptabilidad a entidades dedicadas a evaluar la calidad de los

8. Capacidad del proceso de evaluacin para la admisin de cambios que
impliquen mejoras.
Grupo No 4. Criterios de impacto.
9. Impacto en el rea para la cual est destinada la gua.

10. Organizacin en el proceso de desarrollo.
2. Se determina el peso relativo de cada grupo de criterios de acuerdo al por

ciento que representa cada grupo del total y los intereses a evaluar.
Grupo No.1 40
Grupo No.2 20
Grupo No.3 20
Grupo No.4 20
3. Se realiza una seleccin de 7 expertos en la cual se tiene en cuenta su

especialidad, grado cientfico y currculo.
4. Se le solicita a los expertos que den una evaluacin de cada uno de los
criterios, teniendo en cuenta que la suma del valor dado por parte de los
expertos a cada criterio de un grupo no exceda del peso relativo asignado a
este. Para recoger la informacin anterior se defini un modelo, el cual se
expone en el anexo 7 del trabajo (Ver Anexo 7).
5. Despus de recibir los valores del peso relativo de cada criterio se construye
la Tabla donde se guarda el resultado del trabajo de los expertos (Ver Tabla 5).
71
Tabla 5. Resultado del trabajo de expertos
G C/E E1 E2 E3 E4 E5 E6 E7 Ep
C1 8 10 10 5 8 10 10 8.71
C2 15 10 10 15 11 9 11 11.6
40
C3 8 10 10 5 10 10 8 8.71
C4 9 10 10 15 11 11 11 11
C5 15 10 10 10 10 11 10 10.8
20
C6 5 10 10 10 10 9 10 9.14
C7 10 15 15 15 11 10 11 12.4
20
C8 10 5 5 5 9 10 9 7.57
C9 10 10 10 10 10 10 10 10
20
C10 10 10 10 10 10 10 10 10
T 100 100 100 100 100 100 100 100
6. Se verifica la consistencia en el trabajo de los expertos, para lo que se utiliza

el coeficiente de concordancia de Kendall y el estadgrafo Chi cuadrado (X2).
Para esto se sigue el procedimiento siguiente:
Sea C el nmero de criterios que van a evaluarse y (E) el nmero de

expertos que realizan la evaluacin.
Para cada criterio se determina:
9 E: Sumatoria del peso dado por cada experto.
9 Ep: Puntuacin promedio del peso dado por cada experto.
9 ME: media de los E.
9 C: Diferencia entre E y ME.
72
Se determina la desviacin de la media, que posteriormente se eleva al
cuadrado para obtener la dispersin (S) por la expresin:
S = (E - E / C)2
Tabla 6. Clculo de la Dispersin (S) para hallar la concordancia entre los expertos
E E / C E - E / C (E - E / C)2
C1 61 6.1 -9 81
C2 81 8.1 11 121
C3 61 6.1 -9 81
C4 77 7.7 7 49
C5 76 7.6 6 36
C6 64 6.4 -6 36
C7 87 8.7 17 289
C8 53 5.3 -17 289
C9 70 7 0 0
C10 70 7 0 0
E / C - 70 - -
S = (E - E / C)2 - - - 982
Conociendo la dispersin se puede calcular el coeficiente de

concordancia de Kendall (W):
W = S / E2 (C3 C) / 12
El coeficiente de concordancia de Kendall permite calcular el Chi

cuadrado real:
2 = E (C-1) W
Los valores obtenidos se muestran en la Tabla 7.
73
Tabla 7. Tabla para el clculo de concordancia de Kendall
Expertos/Criterios E1 E2 E3 E4 E5 E6 E7 E Ep C C2
C1 8 10 10 5 8 10 10 61 8.71 9 81
C2 15 10 10 15 11 9 11 81 11.6 11 121
C3 8 10 10 5 10 10 8 61 8.71 9 81
C4 9 10 10 15 11 11 11 77 11 7 49
C5 15 10 10 10 10 11 10 76 10.8 6 36
C6 5 10 10 10 10 9 10 64 9.14 6 36
C7 10 15 15 15 11 10 11 87 12.4 17 289
C8 10 5 5 5 9 10 9 53 7.57 17 289
C9 10 10 10 10 10 10 10 70 10 0 0
C10 10 10 10 10 10 10 10 70 10 0 0
DC 100 100 100 100 100 100 100 700 99.93 82 982
M E 70
W 0.24
2 15.12
X2 (, c-1) 21.6660
El Chi cuadrado calculado se compara con el obtenido de las tablas

estadsticas y de esta forma se obtiene la siguiente conclusin.
Como se cumple la siguiente condicin:
2real < X2 (, c-1)
15.12 < 21.6660
Se puede decir que existe concordancia en el trabajo de expertos.
74
7. Despus de comprobar la consistencia del trabajo de expertos se puede
definir el peso relativo de cada criterio (P).
8. Conociendo el peso de cada criterio (P) y la calificacin dada por los

evaluadores en una escala de 1-5 se puede construir la Tabla 8, para obtener
el valor de de P c., donde (c), es el criterio promedio concebido por los
expertos.
Para recoger la calificacin dada por los expertos a cada uno de los criterios se
defini un modelo el cual se expone en el anexo 8 del trabajo. (Ver Anexo 8)
Tabla 8. Tabla de calificacin de cada criterio
Criterios Calificacin (c) P Pc
1 2 3 4 5
C1 X 0.0871 0.3484
C2 X 0.116 0.464
C3 X 0.0871 0.3484
C4 X 0.11 0.55
C5 X 0.108 0.54
C6 X 0.0914 0.457
C7 X 0.124 0.62
C8 X 0.0757 0.3008
C9 X 0.1 0.5
C10 X 0.1 0.4
Total 4.5286
9. Se calcula el ndice de Aceptacin del proyecto (IA).
IA = (P c) / 5
IA = 0.905
75
10. Por ltimo se determina la probabilidad de xito de la propuesta, para esto
se ubica el ndice de Aceptacin (IA) calculado anteriormente en rangos que
estn ya predefinidos, en dependencia de donde se ubique, ser la
probabilidad de xito que tenga la propuesta.
El ndice de Aceptacin calculado es 0.905.
Rangos predefinidos de ndice de Aceptacin.
IA > 0,7 Existe alta probabilidad de xito
0,7 > IA > 0,5 Existe probabilidad media de xito
0,5 > IA > 0,3 Probabilidad de xito baja
0,3 > IA Fracaso seguro
Por lo que existe alta probabilidad de xito.
76
Principales recomendaciones manifestadas por los expertos
9 Que se utilicen las mtricas dentro del proceso de ingeniera para

iniciar las acciones correctivas en las etapas tempranas del ciclo de vida
de desarrollo del producto.
9 Seguir trabajando en base a un aumento del nmero de mtricas

seleccionadas con sus respectivos criterios sometidos a medicin.
9 Continuar explotando los estndares internacionales a fin de lograr

perfeccionar la propuesta de solucin para un mayor nivel de madurez.
9 Que se prepare esta gua de evaluacin con el objetivo de ser aplicada

por una determinada entidad evaluadora de calidad de software
correspondiente a una especfica esfera de trabajo en nuestra sociedad,
como bien podra ser el campo de las Ciencias Mdicas.
77
3.3 Conclusiones
En este captulo se evalu la gua obtenida mediante el Mtodo de Expertos; el

cual permiti analizar los criterios de cada uno de los expertos y determinar el
ndice de aceptacin que tiene la propuesta del presente trabajo, obtenindose
concordancia en el trabajo de expertos y una alta probabilidad de xito de ser
aplicada en las entidades que se dedican a evaluar la calidad de los productos
de software.
78
Conclusiones Generales
En el presente trabajo se obtuvo una gua con los pasos imprescindibles para
la aplicacin de las mtricas propuestas en el proceso de evaluacin de la
calidad de los productos de software.
Se hizo un estudio de la situacin actual en el mundo y en Cuba, respecto a la

utilizacin de las mtricas en los procesos de evaluacin de la calidad de los
Se analizaron mtricas estandarizadas internacionalmente, definidas en la

ISO/IEC TR 9126-2, seleccionando las mtricas a proponer para este primer
nivel de madurez.
A partir de todo el trabajo realizado, se obtuvo la propuesta, la cual describe las

mtricas seleccionadas y el proceso de evaluacin para la aplicacin de las
mismas, facilitando que en futuros anlisis sea perfeccionada y aplicada en
diversas esferas debido a su carcter dinmico.
Finalmente se hizo la validacin de la propuesta, arrojando que la probabilidad

de xito es alta, lo que implica desde el punto de vista terico, el cumplimiento
de la idea a defender planteada y desde el punto de vista prctico, la
aplicabilidad de la propuesta en entidades dedicadas a la evaluacin de los
79
Recomendaciones
Los objetivos planteados en el presente trabajo se alcanzaron de manera

general, pero se considera que para seguir solucionando los problemas
respecto a la calidad del software, se necesita de un proceso investigativo
mucho ms amplio y este trabajo es slo el primer nivel de madurez del mismo,
teniendo en cuenta esto se pueden hacer las siguientes recomendaciones:
Hacer talleres, seminarios, conferencias, etc., donde se deje clara la

importancia de la aplicacin de las mtricas en el proceso de evaluacin
de productos de software.
Seguir trabajando en la seleccin de las mtricas.
Que la gua propuesta sea tomada en cuenta y aplicada en las entidades

dedicadas a evaluar la calidad de los productos de software,
principalmente en el Ministerio de Salud Pblica (MINSAP).
80
Referencias Bibliogrficas
ALLIANCE, B. S. Fuerte crecimiento del mercado del software, 2007. [2007].

Disponible en: http://www.bsa.org/espana/press/newsreleases/BSA-
destaca-el-fuerte-crecimiento-del-mercado-del-software-europeo-pero-
advierte-sobre-nuevos-riesgos-y-amenazas-potenciales.cfm
de Antonio J, Anglica. Gestin, Control y Garanta de la Calidad del Software,

2002. Disponible en:
http://www.inf.uach.cl/rvega/asignaturas/info265/G_Calidad.pdf
Encuestas. CAELUM 2007. [Disponible en:

http://www.calidaddelsoftware.com/modules.php?name=Surveys&op=res
ults&pollID=3
ESTRADA, A. F. Case Corporativo para el proceso de control de cambios. La

Habana, Instituto Superior Politcnico Jos Antonio Echeverra, Facultad de
Ingeniera Industrial, Centro de Estudios de Ingeniera y Sistemas, 2000. p.
ESTRADA, A. F. Un modelo de Referencia para la Gestin de Configuracin en

la PYME de Software. La Habana, Instituto Superior Politcnico Jos Antonio
Echeverra, Facultad de Ingeniera Industrial, Centro de Estudios de Ingeniera
y Sistemas, 2003. 16. p.
GARCA, F. Proceso Software y Gestin del Conocimiento, Departamento de

Tecnologas y Sistemas de Informacin. Escuela Superior de Informtica. 2007.
[Disponible en: http://alarcos.inf-cr.uclm.es/doc/psgc/doc/psgc-4a.pdf
GONZLEZ, D. Las Mtricas de Software y su Uso en la Regin. Mxico,

Universidad de las Amricas, Puebla, 2001. p.
81
Infocalidad 2005. [Disponible en:
http://www.infocalidad.net/gest_calidad_def/definicion.asp
Ingeniera del software. 2005. [Disponible en:

http://www.monografias.com/trabajos15/ingenieria-software/ingenieria-
software.shtml
La informatizacin en Cuba. Sitio del Ministerio de Relaciones Exteriores de

Cuba 2005. [Disponible en:
http://www.cubaminrex.cu/Sociedad_Informacion/Cuba_SI/Informatizacion
.htm
ISO/IEC_9126-1 (2001). Ingeniera de software. Calidad del producto. Parte 1.

Modelo de la calidad.
ISO/IEC TR 9126-2:2003 Software engineering Product quality Part 2:

External metrics. CH-1211 Ginebra, Suiza, 2003. 94 p.
NC ISO/IEC 12119 Tecnologa de la Informacin-Paquetes de Software-

Requisitos de Calidad y Pruebas (ISO 12119: 1994, IDT)
ISO/IEC 176/SC1N322 (2007) Organizacin Internacional para la

Estandarizacin. Concepts and Terminology. Revision of ISO 9000 Quality
management systems- Fundamentals and vocabulary Preliminary working draft.
2007. 45 p.
MARTNEZ, R. D. ConfigCASE 3.0 Herramienta de apoyo a la Gestin de

apoyo a la gestin de configuracin. Propuesta Arquitectnica., Instituto
Superior Politcnico Jos Antonio Echeverra, 2006. p.
NC_ISO/IEC_GUIA_60 (2005). EVALUACION DE LA CONFORMIDAD

CODIGO DE BUENA PRCTICA, Oficina Nacional de Normalizacin.
82
PRESSMAN, R. S. Ingeniera del Software. Un Enfoque Prctico. 5ta Edicin.
1998. p.
Pressman, Roger S. Ingeniera de Software, un enfoque prctico. 5ta edicin.

McGraw-Hill, 2002.
ROGER S. PRESSMAN. Ingeniera de Software. Un Enfoque Prctico. 4

edicin. 1997. 51-61 p.
Rossi, Bibiana. Mtricas de Software, 2003. Disponible en:

http://www.itba.edu.ar/capis/rtis/articulosdeloscuadernosetapaprevia/ROS
SI-METRICAS.pdf
Cueva Lovelle. J Manuel. Calidad de Software. Universidad de Oviedo, Espaa,

1999. Disponible en:
http://www.uniovi.es
Scalone. Fernanda. Estudio comparativo de los Modelos y Estndares de

Calidad del Software. Universidad Tecnolgica Nacional. Buenos Aires, 2006.
Acosta Montolla. Lizzet. Calidad y Estndares Internacionales. Universidad de

las Ciencias Informticas, 2007.
83
Glosario de Trminos y Siglas
Artefactos: Son los elementos de entrada y salida de las actividades. Son
productos tangibles del proyecto. Las cosas que el proyecto produce o usa
para componer el producto final (modelos, documentos, cdigo, ejecutables).
Atributos: Una unidad con nombre de un clasificador que describe el rango de

valores que las instancias de una propiedad pueden tomar.
CEIS: Centro de Estudios de Ingeniera de Sistemas.
Hardware: Se refiere a toda la infraestructura tecnolgica, componentes fsicos

(que se pueden tocar) de la computadora: discos, unidades de disco, monitor,
teclado, mouse, impresora, placas, chips, unidades de almacenamiento
externo, scanners, entre otros.
Gestin de Calidad: Determinacin y aplicacin de las polticas de calidad de

la empresa (objetivos y directrices generales).
Gestin de configuracin: Es el proceso de identificar y definir los elementos

en el sistema, controlando el cambio de estos elementos a lo largo de su ciclo
de vida, registrando y reportando el estado de los elementos y las solicitudes
de cambio, y verificando que los elementos estn completos y que sean los
correctos.
Gestin de proyecto: La gestin de proyectos es la disciplina de organizar y

administrar recursos de manera tal que se pueda culminar todo el trabajo
requerido en el proyecto dentro del alcance, el tiempo, y coste definidos.
ICSW: La Industria Cubana del Software.
IEC: Comisin Internacional para la Electrnica.
ISO: Organizacin Internacional para la Estandarizacin.
ISP: Instituto Superior Pedaggico.
84
IPI: Instituto Politcnico de Informtica.
Metodologa: Son un conjunto de procedimientos, tcnicas y ayudas a la

documentacin para el desarrollo de productos software.
NC: Norma Cubana.
Proceso: Conjunto de actividades mutuamente relacionadas o que interactan,

las cuales transforman elementos de entrada en resultados, utilizando
recursos.
Producto: Artefactos que se crean durante la vida del proyecto, como los
modelos, cdigo fuente, ejecutables, y documentacin.
Proyecto: Elemento organizativo a travs del cual se gestiona el desarrollo de

software. El resultado de un proyecto es una versin de un producto.
Requisitos: Son las funciones, servicios y restricciones operativas del sistema.
Requisitos funcionales: Son aquellos que describen lo que debe hacer el

sistema.
Requisitos no funcionales: Son aquellos que describen las facilidades que

debe proporcionar el sistema.
Sistema operativo: Programa que una vez cargado, normalmente al encender

el ordenador, maneja y controla los procesos y los programas (llamados
aplicaciones).
Software: Se refiere a los programas y datos almacenados en un ordenador.
SQM: Gestin de Calidad del Software.
SquaRE: Ingeniera de Requisitos de Calidad de Seguridad.
TIC: Tecnologas de la Informtica y las Comunicaciones.
TR: Reporte Tcnico.
UCI: Universidad de las Ciencias Informticas.
85
Anexos
Anexo 1 - Definiciones de las Caractersticas y Sub-
caractersticas de calidad propuestas por el estndar ISO/IEC
9126
La siguiente tabla muestra las definiciones de las caractersticas y sub-
caractersticas de calidad del estndar ISO/IEC 9126 [Pressman, 2002] [NC-
ISO/IEC 9126-1, 2005]:
1. Funcionalidad
Es la capacidad del software para proporcionar funciones que
satisfacen las necesidades declaradas e implcitas cundo el software
se usa bajo las condiciones especificadas. Es el grado en que el
software satisface las necesidades indicadas por las siguientes sub-
caractersticas:
a. Idoneidad Capacidad del software para mantener un conjunto apropiado de
funciones para las tareas y los objetivos del usuario especificados.
b. Exactitud Capacidad del software para proporcionar efectos o resultados
correctos o convenidos con el grado de exactitud necesario.
c. Interoperabilidad Capacidad del software para interactuar recprocamente con uno o
ms sistemas especificados.
d. Seguridad Capacidad del software para proteger informacin y los datos, para que
(informtica) personas o sistemas desautorizados no puedan leer o pueden
modificar los mismos, y las personas o sistemas autorizados tenga el
acceso a ellos.
e. Conformidad con Capacidad del software para adherirse a las normas que se le
la funcionalidad apliquen, convenciones, regulaciones, leyes y las prescripciones
similares relativas a la funcionalidad.
2. Confiabilidad o Fiabilidad
Es la capacidad del software para mantener un nivel de ejecucin
especificado cuando se usa bajo las condiciones especificadas.
Cantidad de tiempo que el software est disponible para su uso. Se
refiere a las sub-caractersticas:
a. Madurez Capacidad del software de evitar un fallo total como resultado de
haberse producido un fallo del software.
b. Tolerancia ante Capacidad del software de mantener un nivel de ejecucin o
fallos desempeo especificado en caso de fallos del software o de infraccin
86
de su interfaz especificada.
c. Recuperabilidad Capacidad del software de restablecer un nivel de ejecucin
especificado y recuperar los datos directamente afectados en caso de
fallo total.
d. Conformidad con Capacidad del software para adherirse a las normas que se le
la confiabilidad apliquen, convenciones, regulaciones, leyes y las prescripciones
similares relativas a la confiabilidad.
3. Usabilidad
Grado con que el software es fcil de usar. Viene reflejado por las
siguientes sub-caractersticas:
a. Comprensibilidad Capacidad del software para permitirle al usuario entender si el
software es idneo, y cmo puede usarse para las tareas y condiciones
de uso particulares.
b. Cognoscibilidad Capacidad del software para permitirle al usuario aprender su
aplicacin.
c. Operabilidad Capacidad del software para permitirle al usuario operarlo y controlarlo.
d. Atraccin Capacidad del software de ser atractivo o amigable para el usuario.
e. Conformidad con Capacidad del software para adherirse a las normas, convenciones,
la usabilidad guas de estilo o regulaciones relativas a la usabilidad.
4. Eficiencia
Capacidad del software para proporcionar una ejecucin o desempeo
apropiado. Grado con que el software hace ptimo el uso de los
recursos del sistema. Esta caracterstica est indicada por las
siguientes sub-caractersticas:
a. Rendimiento Capacidad del software para proporcionar apropiados tiempos de
respuesta y procesamiento, as como tasas de produccin de
resultados, al realizar su funcin bajo condiciones establecidas.
b. Utilizacin de Capacidad del software para utilizar la cantidad y el tipo apropiado de
recursos recursos cuando el software realiza su funcin bajo las condiciones
establecidas.
c. Conformidad con Capacidad del software de adherirse a las normas o convenciones que
la eficiencia se relacionan con la eficiencia.
5. Mantenibilidad
Capacidad del software de ser modificado. Las modificaciones pueden
incluir correcciones, mejoras o adaptaciones del software a cambios en
el ambiente, as como en los requisitos y las especificaciones
87
funcionales. Est reflejada por las siguientes sub-caractersticas:
a. Diagnsticabilidad Capacidad del software de ser objeto de un diagnstico para detectar
deficiencias o causas de los fallos totales en el software, o para
identificar las partes que van a ser modificadas.
b. Cambiabilidad Capacidad del software para permitir la aplicacin de una modificacin
especificada.
c. Estabilidad Capacidad del software para minimizar los efectos inesperados de las
modificaciones realizadas al software.
d. Comprobabilidad Capacidad del software para permitir la validacin de un software
modificado.
e. Conformidad con Capacidad del software para adherirse a las normas o convenciones
la mantenibilidad que se relacionan con la mantenibilidad.
6. Portabilidad
La facilidad con que el software puede ser llevado de un entorno a otro.
Se refiere a las sub-caractersticas:
a. Adaptabilidad Capacidad del software de ser adaptado a los ambientes especificados
sin aplicar acciones o medios de otra manera que aquellos
suministrados con el propsito de que el software cumpla sus fines.
b. Instalabilidad Capacidad del software de ser instalado en un ambiente especificado.
c. Coexistencia Capacidad del software de coexistir con otro software independiente en
un ambiente comn y compartir los recursos comunes.
d. Remplazabilidad Capacidad del software de ser usado en lugar de otro producto
software especificado para los mismos fines y en el mismo ambiente.
e. Conformidad con Capacidad del software de adherirse a las normas o convenciones
la portabilidad relativas a la portabilidad.
88
Anexo 2 - Tablas contentivas de las mtricas
1 - Tablas contentivas de las mtricas de funcionalidad
Tabla 1.1 Mtricas de idoneidad
Nombre La mtrica Mtodo de aplicacin Medicin Interpreta- Tipo de
de la se (frmula) cin del medida
mtrica propone valor
medir obtenido
a) Cun Nmero de funciones X = 1 - A/B 0 <= X <= 1 X = contab/
Adecua- adecuada idneas para ejecutar A - Nmero Contable
cin fun- es la funciones especficas en de funciones A mayor
cional funcin comparacin con el en las cuales cercana al 1 A = Contab
evaluada? nmero de funciones se resultar
evaluadas. detectaron ms B = Contab
problemas adecuada
en la
evaluacin
B - Nmero
de funciones
evaluadas
b) Cun Ejecutar las pruebas (de X = 1 - A/B 0 <= X <= 1 X = contab/
Completi- completa caja negra) funcionales A - Nmero A mayor Contable
tud de la ha sido la de acuerdo con la de funciones cercana al 1
imple- implement especificacin de perdidas resultar A = contabl
men- acin y su requisitos. detectadas mejor
tacin conformi- Cuente el nmero de en la B = contabl
funcional dad con la funciones perdidas evaluacin
especifica- detectadas y compare el B - Nmero
cin de resultado con el nmero de funciones
requisitos ? de funciones descritas descritas en
en la especificacin de especificaci
requisitos. n de
requisitos.
c)Cober- Cun Ejecutar las pruebas X = 1 - A/B 0 <= X <= 1 X = contab/
tura de la correcta ha funcionales (de caja A - Nmero A mayor Contable
implemen sido la negra) de acuerdo con la de funciones cercana al 1
-tacin implemen- especificacin de incorrecta- resultar A = contabl
funcional tacin requisitos. Cuente el mente imple- mejor
funcional? nmero de funciones mentadas o B = contabl
incorrectamente funciones
implementadas o perdidas
funciones perdidas detectadas.
detectadas y compare el
resultado con el nmero B - Nmero
total de funciones de funciones
descritas en la descritas en
especificacin de la especifica-
requisitos. Cuente el cin de
nmero de funciones que requisitos.
estn completas en
relacin con las que no
lo estn.
89
Tabla 1.2 Mtricas de exactitud
Nombre La Mtodo de aplicacin Medicin Interpreta- Tipo de
de mtrica (frmula) cin del medida
la se valor
mtrica propone obtenido
medir
a) Exac- Existen Ejecutar los casos de X = A/T 0 <= X X = contab/
titud diferencia pruebas de entrada A - Nmero A mayor tiempo
esperada s entre los versus salida y comparar de casos cercana al
resultados los resultados actuales y encontrados 0 resultar A = contabl
actuales y los razonablemente con diferen- mejor
los razo- esperados. cias entre los T = tiempo
nablement resultados
e Cuente el nmero de razonable-
esperados casos encontrados con mente
? diferencias inaceptables esperados y
en relacin con los aquellos
resultados resultantes
razonablemente ms all de
esperados. lo permisible.
.
T - Tiempo
de operacin
Tabla 1.3 Mtricas de interoperabilidad

de la mtrica (frmula) cin del medida
mtrica se valor
propone obtenido
medir
a) Cun Nmero Ejecutar las X= A/B 0 <= X <= 1 X = contab/
Intercam- correcta- pruebas a cada registro A- Contable
biabilidad mente ha de salida de las funciones Nmero de A mayor
de datos, sido de interfaces de acuerdo formatos de cercana al 1 A = Contab
en base implemen- con la especificacin de datos in- resultar
su tado el los campos de datos. tercambiado mayor inter.- B = Contab
formato intercambi Cuente el nmero de s cambiabilida
o de formatos de datos que exitosament d
funciones deben ser intercambiados e con otros
de con otros software o software o
interfaces sistemas durante las sistemas
para una pruebas en comparacin durante las
transfe- con el nmero total pruebas del
rencia de intercambio
datos de datos.
especfica B -
? Nmero
total de
formatos de
datos a
intercambiar
90
Tabla 1.3 Mtricas de interoperabilidad (continuacin)
mtrica se valor
propone obtenido
medir
b) Cun Ejecutar las pruebas. 1) X = 1 - 0 <= X <= 1 1) X = cont/
Intercam- frecuente- A/B cont
biabilidad mente Cuente el nmero de A mayor
de datos, fall el casos en que las A- cercana al 1 A = contabl
en base intento de funciones de interfaces Nmero de resultar
xito del intercambi fueron usadas y fallaron. casos en mejor B = contabl
intento o de datos que se fall
entre el al proceder 2) Y = cont/
software a un tiempo
objeto de intercambio
la prueba de datos T - tiempo
y otro con otros
software? software o
Cun sistemas.
frecuente- B -
mente ES Nmero de
SATIS- casos en
FACTORI que se 0 <= Y
A la intent
transfe- proceder a A mayor
rencia de un cercana al 0
datos intercambio resultar
entre el de datos mejor
software
objeto de 2) Y = A /
la prueba T
y otro?
T -
Perodo de
tiempo de
operacin
91
2 - Tablas contentivas de las mtricas de confiabilidad
Tabla 2.1. Mtricas de madurez

mtrica se valor
propone obtenido
medir
a) Cuntos Cuente el nmero de X = (ABS 0 <= X X=
Latencia problemas fallos detectados durante (A1- A2)) / Contabl
estimada an el perodo definido de B En dependencia /
de la existen pruebas y pronostique el del estadio de las
intensida que nmero potencial de ABS() - pruebas, En Tama
d de pueden futuros fallos utilizando Valor etapas ms o
fallos emerger un modelo de estimacin absoluto avanzadas,
como de la fiabilidad. mientras ms A1 =
futuros A1 - pequeo, mejor Cont
fallos? Nmero
total de A2 =
fallos Cont
latentes
predecibles B=
en el Tama
producto de o
software
A2 -
Nmero
total de
fallos
detectados
realmente
B -
Tamao del
producto.
Tabla 2.1. Mtricas de madurez (continuacin)

Nombre La Mtodo de aplicacin Medicin Interpreta-cin Tipo
de la mtrica (frmula) del valor de
mtrica se obtenido medida
propone
medir
b) Intensi- Cuntos Cuente el nmero de X = A1 / A2 0 <= X X =
dad de fallos fallos totales detectados y Contabl
fallos totales el nmero de casos de A1 - En dependencia /
totales fueron pruebas. Nmero del estadio de las
contra detectado total de pruebas, En contabl
casos de s durante fallos etapas ms e
prueba un totales avanzadas,
92
perodo detectados mientras ms A1 =
de pequeo, mejor Cont
pruebas A2 -
definido? Nmero de A2 =
casos de Cont
pruebas
ejecutados
c) Grado Cuntas Cuente el nmero de X = A1 / A2 0 <= X <= 1 X =
de condicion fallos totales que no se Contabl
solucin es de fallo repitieron en determinado A1 - A mayor /
ante total estn perodo de pruebas bajo Nmero de cercana al 1
fallos resueltas? condiciones similares. fallos resultar mejor, contabl
totales Mantenga un reporte de totales cuanto ms fallos e
solucin de problemas solucionado totales estn
describiendo la situacin s resueltos A1 =
de todos los fallos totales. Cont
A2 -
Nmero A2 =
total de Cont
problemas
reales
detectados.
d) Intensi- Cuntos Cuente el nmero de X = A / B 0 <= X X =
dad de fallos fallos detectados y Depende del Contabl
fallos fueron compute su intensidad. A - estadio de las /
detectado Nmero pruebas, En
s durante total de etapas ms tamao
un fallos avanzadas,
perodo detectados mientras ms A =
de pequeo, mejor Cont
pruebas B -
definido? Tamao del B =
producto Tama
o
93
Tabla 2 .1. Mtricas de madurez (continuacin)
Nombre La mtrica Mtodo de aplicacin Medicin Interpreta-cin Tipo

de la se propone (frmula) del valor de
mtrica medir obtenido medida
e) Cuntos Cuente el nmero de 1) X = A1 / 0 <= X <= 1 1) X =
Erradica- fallos han fallos resueltos durante el A2 cont/
cin de sido perodo de pruebas y A1 - Nmero A mayor
fallos corregidos? comprelos con el de fallos cercana al 1 cont
nmero total de fallos solucionados resultar mejor A1 =
detectados y el nmero A2 - Nmero (cuanto menos cont
total de fallos total de fallos fallos queden) A2 =
pronosticados. reales cont
detectados. 2) Y =
2) Y = A1 0 <= Y cont/
/A3
A3 - Nmero A mayor contabl
total de fallos cercana al 0 e
latentes resultar mejor A3 =
pronosticado (cuanto menos cont
s fallos queden)
f) Cun . Cuente el nmero de 1) X = T1 / A 0 < X, Y 1)

Tiempo frecuente- fallos totales ocurridos 2) Y = T2 /A X
medio mente el durante el perodo de A mayor =tiemp
entre software operacin definido y T1 Tiempo resultar mejor, o/
fallos fracasa en compute el intervalo de operacin cuanto mayor
totales su promedio entre fallos T2 suma sea el perodo cont
operacin.? totales. de los de tiempo entre 2)
intervalos de fallos Y=
tiempo entre tiempo/
los fallos 0 <= Y
totales cont
consecutivos A mayor
producidos. cercana al 0 A=
A - Nmero resultar mejor cont
total de fallos (cuanto menos
realmente fallos queden) T1 =
detectados tiempo
(fallos totales T2 =
ocurridos tiempo
durante el
tiempo de
operacin
observado)
A3 =
cont
94
Tabla 2.1. Mtricas de madurez (continuacin)
Nombre La mtrica Mtodo de aplicacin Medicin Interpreta-cin Tipo de
de la se propone (frmula) del valor medida
mtrica medir obtenido
g)Cobert Cuntos Cuente el nmero de X=A/ B 0 <= X <= 1 X =
ura casos de casos de pruebas que Contabl/
de las pruebas han sido ejecutados A Mientras ms
pruebas requeridos detectados durante las Nmero de cercano al 1, contabl
han sido pruebas y comprelo con casos de mejor cobertura. e
ejecutados el nmero de casos de pruebas que
detectados pruebas requeridos han sido A =
durante las para obtener una realmente Cont
pruebas? adecuada cobertura de ejecutados, y
pruebas. que B =
representan Cont
el escenario
de operacin
durante las
pruebas.
B
Nmero de
casos de
pruebas a
ejecutar
requeridos
para cubrir
los requisitos
h) Est bien Cuente el nmero de X = A / B 0 <= X <= 1 X =
Madurez probado el casos de pruebas que Contabl/
de las producto? han obtenido un resultado A Mientras ms
pruebas satisfactorio de los casos Nmero de cercano al 1, contabl
realmente ejecutados y casos de mejor. e
comprelo con el nmero pruebas que
total de casos de pruebas han obtenido A =
requeridos para cubrir los un resultado Cont
requsitos. satisfactorio
al ser B =
ejecutados o Cont
durante su
operacin.
B
Nmero de
casos de
pruebas a
ejecutar
para cubrir
los requisitos
95
Tabla 2.2. Mtricas de tolerancia ante fallos
Nombre La mtrica Mtodo de aplicacin Interpreta-cin

Medicin Tipo de
de la se propone del
(frmula) valor medida
a) Cun Cuente el nmero de X = 1- A /B 0 <= X <= 1 X =
Evitacin frecuenteme desastres detectados con Contabl/
de nte el respecto al nmero de A - Nmero A mayor
desastre producto de fallos totales. de cercana al 1 contable
software desastres resultar mejor,
causa un A = Cont
desastre en B - Nmero
el ambiente de fallos B = Cont
de la totales
produccin
total?
b) Cuntas Cuente el nmero de X=A/B 0 <= X <= 1 X =

Evitacin funciones casos de prueba de A - Contabl/
de opera- estn operaciones incorrectas Nmero de A mayor
ciones implementa que fueron evitadas para ocurrencia cercana al 1 contable
incorrect das con que no causaran fallos de fallos resultar mejor,
as capacidad totales crticos o serios, y totales cuanto ms A = Cont
de evitacin comprelo con el nmero crticos o operaciones
de de casos de pruebas serios incorrectas del B = Cont
operaciones ejecutados a los patrones evitada usuario sean
incorrectas? de operaciones incorrectas B - evitadas
considerados perodo de Nmero de
pruebas bajo condiciones casos de
similares. pruebas
ejecutados
a los
patrones de
operaciones
incorrectas
(casi
causantes
de fallos)
durante las
pruebas.
96
Tabla 2.3. Mtricas de recuperabilidad

a) Grado Cun Pruebe el sistema en la 1) X =(To 0 <= X <= 1 X =
de disponible produccin como ambiente /To+Tr) Tiempo /
disponi- est el durante un perodo de 2) Y = A1 / A mayor
bilidad sistema tiempo especificado A2 cercana al 1 Tiempo
para su uso ejecutando todas las resultar mejor
durante? operaciones del usuario. To To
Tiempo de Tiempo
operacin Tr
Tr Tiempo Tiempo
de
reparacin
A1 Total Y =
de casos de Contabl/
uso del
software contable
disponibles
exitosament A1 =
e, cuando Cont
se han
intentado A2 =
utilizar. A2 Cont
- Total de
casos de
uso del
software
que se han
intentado
utilizar
durante el
tiempo de
observacin
.
Tabla 2.3. Mtricas de recuperabilidad (continuacin)

b) Cul es el Mida el tiempo de X = T / N 0<X X =
Tiempo tiempo inactividad cada vez que el tiempo/
medio de promedio en sistema se encuentre no T - tiempo Cuanto menor
inactivida que el disponible durante un total de sea mejor, el contable
d sistema se perodo de prueba inactividad sistema estar
mantiene no especificado y compute el N - Nmero inactivo por T =
disponible tiempo medio. de menos tiempo. tiempo
97
cuando desastres
ocurre un observados. N =
fallo total y Cont
antes de la El peor caso
arrancada o la
gradual? distribucin
del tiempo
de
inactividad
debe ser
medido.
c) Tiempo Cul es el Mida el tiempo total de X =SUM( 0 < X X =

medio de tiempo recuperacin cada vez que Tn) / N tiempo/
recupera- promedio haya pasado a la T - Cuanto menor
cin que toma el inactividad (cado el tiempo de sea mejor. contable
sistema sistema) y calcule el recuperaci
para tiempo promedio invertido n de la T =
completar la en la recuperacin. inactividad tiempo
recuperaci en cada n
n desde el oportunidad N =
inicio de la N - Cont
recuperaci Nmero de
n parcial? oportunidad
es en que el
sistema
entr en
recuperaci
n

d) Recar- Cun Contar el nmero de veces X= A/B 0 <= X <= 1 X=
gabilidad frecuente- que el sistema se reinicia o A mayor contab/
mente el se recarga y ofrece cercana al 1
sistema exitosamente sus servicios A - Nmero mejor, el usuario contab
logra a los usuarios en el plazo de veces puede reiniciar o
recargar de tiempo previsto, y que se recargar ms A=
luego de comprelo con el nmero provoc el fcilmente. contabl
una de de veces que el reinicio o
ejecucin sistema se reinici como recarga en B=
perdida resultado de una cada en el plazo de contabl
proveyendo inactividad durante un tiempo
nuevamente perodo de prueba previsto en
los servicios especificado. la prueba
a los especificada
usuarios en o en la
el plazo de implantaci
tiempo n.
previsto?
B -
Nmero
98
total de
veces que
se provoc
el reinicio o
recarga
durante la
prueba
especificada
o la
implantaci
n.

e) Cun Cuente el nmero de de X= A/B 0 <= X <= 1 X =
Restaura- capaz es el restauraciones exitosas y A mayor contab/
bilidad producto de comprelo con el nmero cercana al 1
auto de restauraciones mejor y el contab
restaurarse probadas requeridas por A producto es ms
luego de un las especificaciones. Nmero de capaz de de A =
evento casos de restaurarse en contabl
anormal o Ejemplos de requisitos de restauracin casos definidos.
una restauracin son: exitosos B =
solicitud? contabl
- funcin deshacer, B
- funcin rehacer Nmero de
casos de
restauracin
probados
por los
requisitos
f) Efecto- Cun Cuente el nmero de X = A / B 0 <= X <= 1 X =
vidad de efectiva es restauraciones que A mayor contab/
la la cumplen con el plazo de cercana al 1
restaura- capacidad tiempo previsto y A Nmero mejor, y los contab
cin de comprelo con el nmero de casos de procesos de
restauracin de restauraciones y restauracin restauracin del A =
? comprelo con el nmero exitosos en producto son ms contabl
de restauraciones el plazo de efectivos.
requeridas en el plazo de tiempo B =
tiempo especificado.** previsto contabl
B
Nmero de
casos de
restauracin
ejecutados
99
3 - Tablas contentivas de las mtricas de usabilidad
Tabla 3.1 Mtricas de comprensibilidad

a) Qu Conduzca las pruebas de 1) X = A / B 0 <= X <= 1 X =
Integrida proporcin usuario. Realice cont/cont
d de la de entrevistas a usuarios con A - nmero A mayor A
descripci funciones (o cuestionarios preparados de cercana al 1 =
n de tipos de al efecto. Observe el funciones resultar mejor Contable
producto funciones) comportamiento del comprendid B
son usuario. Cuente el nmero as =
comprendid de funciones que fueron B Contable
as despus adecuadamente - nmero
de leer la comprendidas en total de
descripcin comparacin con el funciones
del nmero total de funciones
producto? en el producto.
b) - A qu Conduzca las pruebas de X = A / B 0 < X <= 1 X =

Accesibi- proporcin usuario. Observe el Contable
lidad a de comportamiento del A - mientras /contable
demos demos/tutori usuario. nmero de cercano al 1,
ales pueden demos/tutori mejor A =
acceder los ales a los Contable
usuarios? que pueden
acceder los B =
usuarios Contable
exitosament
e.
B
- nmero
total de
demos/tutori
ales a los
que se
puede
acceder
Tabla 3.1 Mtricas de comprensibilidad (continuacin)
Nombre de La mtrica Mtodo de aplicacin Medicin Interpreta-cin Tipo de

la mtrica se propone (frmula) del valor medida
medir obtenido
c) Com- Pueden Conduzca las pruebas X=A/B 0 <= X <= 1
prensibi- los usuarios de usuario. Realice A X =
lidad de comprender entrevistas a usuarios - nmero de Mientras cercano Cont/co
entradas y lo que se con cuestionarios elementos al 1, mejor nt
salidas requiere preparados al efecto. de entrada y
como Observe el que
100
entrada y lo comportamiento del suministra el A =
que usuario. Cuente el sistema de Contabl
suministra nmero de elementos de software e
el sistema entrada . como salida
de software comprendida B =
como s Contabl
salida? corectament e
e
B
- nmero
total de
elementos
de entrada y
que
suministra el
sistema de
software
como salida
pproporciona
dos por el
interfaz.
Tabla 3.2 Mtricas de atraccin

b) Qu Conduzca las pruebas X = A / B 0 <= X <= 1 X =
Adapta- proporcin de usabilidad. Observe el A - nmero mientras con/con
bilidad de de los comportamiento del de elementos cercano al 1, A
la elementos usuario. de la interfaz mejor =
aparienci de las del sistema Contable
a de la interfaz cuya B
interfaz puede ser, apariencia =
por su puede ser Contable
apariencia, adaptada por
adaptado el usuario
por el B - nmero
usuario para de elementos
la satis- de la interfaz
faccin del del sistema
mismo? cuya
apariencia
querra
adaptar el
usuario
101
Anexo 3 - Plantilla # 1
Variables que deben ser obtenidas en los procesos de pruebas por estar
implicadas en las frmulas de medicin de la tablas contentivas de las
mtricas.
1 Tabla para determinar las variables contenidas en las mtricas de

Funcionalidad
Mtricas de idoneidad

mtrica
a) Adecuacin A - Nmero de funciones en las cuales se detectaron problemas en
funcional la evaluacin.
B - Nmero de funciones evaluadas.
b) Completitud A - Nmero de funciones perdidas detectadas en la evaluacin.

de la implemen- B - Nmero de funciones descritas en especificacin de requisitos.
tacin funcional
c)Cobertura de A - Nmero de funciones incorrecta-mente implementadas o

la implemen- funciones perdidas detectadas.
tacin funcional B - Nmero de funciones descritas en la especificacin de
requisitos.
Mtrica de exactitud

mtrica
a) Exactitud A - Nmero de casos encontrados con diferencias entre los
esperada resultados razonable-mente esperados y aquellos resultantes ms
all de lo permisible.
Mtricas de interoperabilidad

mtrica
a) Intercam- A - Nmero de formatos de datos intercambiados exitosamente con
biabilidad otros software o sistemas durante las pruebas del intercambio de
de datos, en datos.
base su formato B - Nmero total de formatos de datos a intercambiar.
b) Intercam- A - Nmero de casos en que se fall al proceder a un intercambio de

biabilidad de datos con otros software o sistemas.
datos, en base B - Nmero de casos en que se intent proceder a un intercambio
xito del intento de datos.
T - Perodo de tiempo de operacin.
102
Confiabilidad
Mtricas de madurez

mtrica
a) Latencia ABS () - Valor absoluto.
estimada A1 - Nmero total de fallos latentes predecibles en el producto de
de la intensidad software.
de fallos A2 - Nmero total de fallos detectados realmente.
b) Intensidad de A1 - Nmero total de fallos totales detectados.

fallos totales A2 - Nmero de casos de pruebas ejecutados.
contra casos de
prueba
c) Grado de A1 - Nmero de fallos totales solucionados.

solucin ante A2 - Nmero total de problemas reales detectados.
fallos totales
d) Intensidad de A - Nmero total de fallos detectados.

fallos B - Tamao del producto.
e) Erradicacin A1 - Nmero de fallos solucionados.

de fallos A2 - Nmero total de fallos reales detectados.
A3 - Nmero total de fallos latentes pronosticados.
f) Tiempo T1 - Tiempo de operacin.

medio entre T2 - Suma de los intervalos de tiempo entre los fallos totales
fallos totales consecutivos producidos.
A - Nmero total de fallos realmente detectados (fallos totales
ocurridos durante el tiempo de operacin observado).
g)Cobertura A - Nmero de casos de pruebas que han sido realmente

de las pruebas ejecutados, y que representan el escenario de operacin durante las
pruebas.
B - Nmero de casos de pruebas a ejecutar requeridos para cubrir
los requisitos.
h) Madurez A - Nmero de casos de pruebas que han obtenido un resultado

de las pruebas satisfactorio al ser ejecutados o durante su operacin.
B - Nmero de casos de pruebas a ejecutar para cubrir los
requisitos.
Mtricas de tolerancia ante fallos

mtrica
a) Evitacin de A - Nmero de desastres.
103
desastre B - Nmero de fallos totales.
b) Evitacin de A1 - Nmero de ocurrencia de fallos totales crticos o serios evitada.

operaciones A2 - Nmero de casos de pruebas ejecutados a los patrones de
incorrectas operaciones incorrectas (casi causantes de fallos) durante las
pruebas.
Mtricas de recuperabilidad

mtrica
a) Grado de To - Tiempo de operacin.
disponibilidad Tr - Tiempo de reparacin.
b) Tiempo T - Tiempo total de inactividad.

medio de N - Nmero de desastres observados.
inactividad
c) Tiempo T - Tiempo de recuperacin de la inactividad en cada n oportunidad.

medio de N - Nmero de oportunidades en que el sistema entr en
recuperacin recuperacin.
d) Recar- A - Nmero de veces que se provoc el reinicio o recarga en el

gabilidad plazo de tiempo previsto en la prueba especificada o en la
implantacin.
B - Nmero total de veces que se provoc el reinicio o recarga
durante la prueba especificada o la implantacin.
e) Restaura- A - Nmero de casos de restauracin exitosos.

bilidad B - Nmero de casos de restauracin probados por los requisitos.
f) Efectovidad A - Nmero de casos de restauracin exitosos en el plazo de
de la restaura- tiempo previsto.
cin B - Nmero de casos de restauracin ejecutados.
104
Usabilidad
Mtricas de comprensibilidad

mtrica
a) Integridad de A - Nmero de funciones comprendidas.
la descripcin de B - Nmero total de funciones.
producto
b) Accesibilidad A - Nmero de demos/tutoriales a los que pueden acceder los

a demos usuarios exitosamente.
B - Nmero total de demos/tutoriales a los que se puede acceder.
c) Comprensibi- A - Nmero de elementos de entrada y que suministra el sistema de

lidad de entradas software como salida comprendidas correctamente.
y salidas B - Nmero total de elementos de entrada y que suministra el
sistema de software como salida proporcionados por el interfaz.
Mtrica de atraccin

mtrica
b) Adaptabilidad A - Nmero de elementos de la interfaz del sistema cuya apariencia
de la apariencia puede ser adaptada por el usuario.
de la interfaz B - Nmero de elementos de la interfaz del sistema cuya apariencia
querra adaptar el usuario.
105
Plantilla de preevaluacin y medicin de la calidad con las mtricas.

Calidad externa
Proyecto No. ____________________ Siglas: ____________________
Denominacin: _____________________________________________
CARACTERISTICA SUBCARACTERISTICA PESOS METRICAS NIVEL RESU

REQUE- L-
RIDO TADO
REAL
Funcionalidad Idoneidad 1.1.a) 1
X = 1 - A/B (0 <= X <= 1)
1.1.b) 1
X = 1 - A/B (0 <= X <= 1)
1.1.c) 1
X = 1 - A/B (0 <= X <= 1)
Exactitud 1.2.a) 0
X = A/T (0 <= X)
Interoperabilidad 1.3.a) 1
X= A/B (0 <= X <= 1)
1.3.b.1) 1
X = 1 - A/B (0 <= X <= 1)
1.3.b.2) 0
Y=A/T (0 <= Y)
Confiabilidad Madurez 2.1.a) (0 <= X)

X = (ABS
(A1 - A2)) /
B
2.1.b) (0 <= X)
X = A1 / A2
2.1.c) 1
X = A1 / A2 (0 <= X <= 1)
2.1.d) (0 <= X)
X=A/ B
2.1.e.1) 1
X = A1 / A2 (0 <= X <= 1)
2.1.e.2) 0
106
Y = A1 /A3 (0 <= Y)
2.1.f.1) 0 < X, Y
X = T1 / A
2.1.f.2) 0
2) Y = T2 /A (0 <= Y)
2.1.g) 1
X=A/ B (0 <= X <= 1)
2.1.h) 1
X=A/ B (0 <= X <= 1)
Tolerancia ante fallos 2.2.a) 1

X = 1- A /B (0 <= X <= 1)
2.2.b) 1
X=A/B (0 <= X <= 1)
Recuperabilidad 2.3.a) 1
X=(To (0 <= X <= 1)
/To+Tr)
2.3.b) 0
X=T/N (0 < X)
2.3.c) 0
X =SUM( (0 < X)
Tn) / N
2.3.d) 1
X= A/B (0 <= X <= 1)
2.3.e) 1
X= A/B (0 <= X <= 1)
2.3.f) 1
X= A/B (0 <= X <= 1)
Usabilidad Comprensibilidad 3.1.a) 1

X=A/B (0 <= X <= 1)
3.1.b) 1
X=A/B (0 < X <= 1)
3.1.c) 1
X=A/B (0 <= X <= 1)
Atraccin 3.2.b) 1
X=A/ (0 <= X <= 1)
107
Escala para cuando el nivel requerido es 1 Escala para cuando el nivel requerido es 0
Rango Evaluacin Puntuacin Rango Evaluacin Puntuacin

0 - 0,2 Mal 0 0 - 0,2 Muy Bien 3
0,3 0,5 Regular 1 0,3 0,5 Bien 2
0,6 0,7 Bien 2 0,6 0,7 Regular 1
0,8- 1 Muy Bien 3 0,8- 1 Mal 0
CUESTIONARIO INDIVIDUAL DE EVALUACION

DE LA CONFORMIDAD
SECCION A
VALORACION DE LOS RESULTADOS DE LAS PRUEBAS Y EL
COMPORTAMIENTO DE LAS CARACTERISTICAS DE CALIDAD
Proyecto No. ____________________ Siglas: ____________________________

Denominacin: ____________________________________________
Nivel de Clasificacin: _______________________ Software crtico: No crtico:
Control No.:________________ Etapa: ____________________________________

3 2 1 0
1. FUNCIONALIDAD
1.1 Idoneidad. Capacidad del software para mantener un conjunto apropiado
de funciones para las tareas y los objetivos del usuario especificados.
a) Funcionamiento correcto (ausencia de fallos totales - ciclos infinitos,
interrupcin de la ejecucin o salidas abruptas-, errores crticos, errores de
ejecucin, resultados incorrectos, correspondencia de las descripciones con
los objetos, por ejemplo en el nivel de ayuda solicitado o los mensajes de
error segn el fallo detectado )
b) Correspondencia de las funciones con los requisitos funcionales de la
Descripcin del software (especificaciones)
1.2 Precisin. Capacidad del software para proporcionar efectos o
resultados correctos o convenidos con el grado de exactitud necesario.
a) Exactitud de los clculos

1.3 Interoperabilidad. Capacidad del producto de software para interactuar
recprocamente con uno o ms sistemas especificados.
a) Funcionamiento correcto al interactuar (ausencia de fallos totales ciclos
infinitos, interrupcin de la ejecucin o salidas abruptas-, errores crticos,
errores de ejecucin, resultados incorrectos,)
108
DE LA CONFORMIDAD
SECCION B

Denominacin: _____________________________________________
Control No.:________________ Etapa: ____________________________________

3 2 1 0
2 CONFIABILIDAD
2.1 Madurez. Capacidad del producto de software de evitar un fallo total
como resultado de haberse producido un fallo del software.
a) Mantenimiento del funcionamiento correcto ante la aparicin de un fallo
(ausencia de fallos totales - ciclos infinitos, interrupcin de la ejecucin o
salidas abruptas-, errores crticos, errores de ejecucin, resultados
incorrectos,)
b) Uniformidad del retorno al procesamiento ante la aparicin de un fallo
(restablecimiento de pantallas, mens y ayudas)
2.2 Tolerancia ante fallos. Capacidad del producto de software de mantener
un nivel de desempeo o ejecucin especfico en caso de fallos del
software o de infraccin de sus interfaces especificadas
a) Verificacin de la memoria interna y externa (para la instalacin del
producto, la reconfiguracin del producto o para la salva de la informacin)
b) Validacin previa de condiciones potenciales de errores (particiones de
trabajo inexistentes, disponibilidad e integridad de los ficheros, disponibilidad
de los perifricos)
c) Tratamiento de los errores (procedimientos para la deteccin y correccin
de errores internos del software
d) Procesamiento degradado (procedimiento para el funcionamiento
degradado en caso de los fallos no recuperables como la ausencia de
ficheros o deficiencias del hardware)
2.3 Recuperabilidad. Capacidad del producto de software de restablecer un
nivel de ejecucin especificado y recuperar los datos directamente
afectados en caso de fallo total
a) Opciones de recuperabilidad (prdida o deterioro de datos y elementos
componentes del software, errores del operador)
109
DE LA CONFORMIDAD
SECCION C

Denominacin: _____________________________________________
Control No.:________________ Etapa: ____________________________________
CARACTERISTICAS Y SUBCARACTERISTICAS DE CALIDAD 3 2 1 0

3 USABILIDAD
3.1 Comprensibilidad. Capacidad del producto de software para
permitirle al usuario entender si el software es idneo, y cmo puede usarse
para las tareas y condiciones de uso particulares
a) Terminologa (acorde con la actividad especfica de la aplicacin o actividad
del usuario)
b) Ayuda en lnea (presencia de diferentes niveles de ayudas, sistema,
pantalla, campo)
c) Interfaz de usuario adecuada (representacin de los objetos con anlogos
en el ambiente del usuario, utilizacin de iconos)
3.2 Cognoscibilidad. Capacidad del producto del software para permitirle al
usuario aprender su aplicacin
a) Existencia de un DEMO
b) Existencia de un Tutorial
3.3 Operabilidad. Capacidad del producto del software para permitirle al
usuario operarlo y controlarlo
a) Utilidad de las ayudas (utilidad de la informacin que brinda la ayuda)
b) Operabilidad de las ayudas (facilidad de desplazamiento en la ventana de
ayuda)
c) Carga automtica (generacin durante la instalacin del fichero de
comandos para la ejecucin del producto de software)
d) Minimizacin del trabajo extra del usuario (durante la operacin y en caso
de fallos)
e) Facilidades de operacin opcional (seleccin de opciones mediante el
cursor de barras, video invertido, brillantez de las opciones, mouse)
3.4 Atraccin. Capacidad del producto del software de ser atractivo o
amigable para el usuario
a) Uniformidad de la estructura, del contenido y del formato de los elementos
componentes
b) Uniformidad del vocabulario, de la simbologa y de otras convenciones
utilizadas
110
DE LA CONFORMIDAD
SECCION A
RESUMEN DEL CUESTIONARIO INDIVIDUAL
Funcionalidad 2 Suficientemente
VALOR conforme
1 Medianamente
conforme
0 No conforme
( ) Pequeas modificaciones
(rea de firma)
Evaluador: Fecha:
__________________
Cargo:
111
DE LA CONFORMIDAD
SECCION B
Confiabilidad 2 Suficientemente
VALOR conforme
1 Medianamente
conforme
0 No conforme
(rea de firma)
Evaluador: Fecha:
__________________
Cargo:
112
DE LA CONFORMIDAD
SECCION C
Usabilidad 2 Suficientemente
VALOR conforme
1 Medianamente
conforme
0 No conforme
(rea de firma)
Evaluador: Fecha:
__________________
Cargo:
113
CUESTIONARIO COLECTIVO DE EVALUACION DE

LA CONFORMIDAD
RESUMEN GENERAL
Proyecto No. ____________________ Siglas: _____________________________

Denominacin: _____________________________________________
Control No.:________________ Etapa:
____________________________________
PUNTUACION PROMEDIADA A PARTIR DE LA INDIVIDUAL

Funcionalidad
Confiabilidad
Usabilidad
VALOR*
*Nota: Este valor no se obtiene matemticamente, sino por medio del

razonamiento lgico en conformidad con el los objetivos de la evaluacin, la
aplicacin y criticidad del software y otros factores. De requerirse votacin (por
no existir consenso) el lder evaluador cuenta con 2 votos.
GRADOS DE CONFORMIDAD POR SECCIONES (poner una X)

Seccin A ( ) Conforme
( ) No conforme
Seccin B ( ) Conforme
( ) No conforme
Seccin C ( ) Conforme
( ) No conforme
114
VEREDICTO
ACEPTADO
DIFERIDO
NO ACEPTADO
(rea de firma)
Evaluador lider: Fecha: ___________

Cargo:
Evaluador:
Cargo:
Evaluador:
Cargo:
Evaluador:
Cargo:
115
Anexo 7 - Modelo para la recogida de informacin referente al
peso de los criterios
Gua para informar el peso de los criterios.
Fecha de recepcin00/00/00.
Fecha de entrega....00/00/00.......
Nombre y Apellidos del evaluador
Le otorgar un peso a cada criterio de acuerdo a su opinin y el peso total

de cada grupo debe sumar:
Grupo No.1 40
Grupo No.2 20
Grupo No.3.20
Grupo No.4.20
Para que el peso total asignado sea 100.

Peso..........
Peso..........
Peso..........
Peso..........
116

Peso..........
Peso..........

Peso..........
impliquen mejoras.
Peso..........

Peso..........
Peso..........
117
Anexo 8 - Modelo para la recogida de informacin referente a la
calificacin de los criterios
Fecha de recepcin00/00/00..
Fecha de entrega.... 00/00/00........
Nombre y Apellidos del
Evaluador
Criterios de medida que se evalan en una escala de 1 - 5

Evaluacin..........
Evaluacin..........
Evaluacin..........
Evaluacin..........

Evaluacin..........
Evaluacin..........

Evaluacin..........
118
impliquen mejoras.
Evaluacin..........

Evaluacin..........
Evaluacin..........
Categora final del proyecto

___ Excelente: Alta novedad cientfica, con aplicabilidad y resultados
relevantes.
___ Bueno: Novedad cientfica, resultados destacados.
___ Aceptable: Suficientemente bueno con reservas.
___ Cuestionable: No tiene relevancia cientfica y los resultados son malos.
___ Malo: No aplicable.
Valoracin final
Sugerencias del experto para mejorar la calidad del proyecto
Elementos crticos que deben mejorarse.
119

TESIS ELIET 25 (Gestion de Calidad)

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TESIS ELIET 25 (Gestion de Calidad)

Transféré par

Droits d'auteur :

Formats disponibles

INSTITUTO SUPERIOR MINERO-METALRGICO

Dr. Antonio Nez Jimnez

CALIDAD DE PRODUCTOS SOFTWARE

Trabajo de diploma para optar por el ttulo de

Eliet Pea Nez

Dra. Yiezenia Rosario Ferrer

Holgun, junio, 2009

Declaro ser autor de la presente tesis y reconozco al ISMM los derechos

Eliet Pea Nez

Firma del Autor

Dra. Yiezenia Rosario Ferrer Dr. Arstides Alejandro Legr Lobaina

Firma del Tutor Firma del Tutor

A mis padres, hermano y dems familiares, con los que tengo

A la Revolucin cubana, por hacer realidad los sueos de

A nuestro Comandante en Jefe, Fidel Castro Ruz, por

A mis tutores, Yiezenia Rosario Ferrer y Arstides Alejandro

A todos aquellos, que de una forma u otra han contribuido al

Actualmente las entidades en Cuba dedicadas a la produccin de software

Figura 1. Concepto de Mtricas............................................................................................21

Tabla 1. Datos de las variables contenidas en las mtricas ................................................61

En la actualidad el desarrollo del software ha aumentado considerablemente, lo

En Cuba en los ltimos aos ha habido un auge en el desarrollo de software,

Con los avances cientfico-tcnicos, evidenciados mayormente en la creacin

Este nivel de aceptacin est estrechamente ligado a la definicin de criterios

Una especificacin y evaluacin integral y detallada de la calidad de los

Es importante especificar y evaluar cada caracterstica relevante de la calidad

En el mundo actualmente existen normas o estndares internacionales para

A raz del anlisis de todo lo anterior surge la interrogante: Cmo perfeccionar

El Objeto de estudio de la investigacin es la Calidad de los Productos de

Para proporcionarle una solucin al problema analizado se define como

Del objetivo global se derivan los siguientes Objetivos especficos:

Realizar un estudio de las mtricas estandarizadas internacionalmente

Para el desarrollo de la investigacin se propone la siguiente Idea a Defender:

Estudio y anlisis de mtricas estandarizadas internacionalmente

Esta propuesta traer consigo un mejoramiento de la calidad del producto final,

La estrategia planteada para conducir la investigacin es del tipo Descriptiva,

El presente trabajo de diploma consta de una Introduccin, 3 captulos con la

Captulo 2: Descripcin de la Propuesta de Solucin. En este captulo se

Captulo 3: Validacin de la Propuesta de Solucin. En este captulo se

La empresa de software cubana an siendo joven rene sus esfuerzos para

Actividades como la Gestin de la Configuracin del Software , la Verificacin

En la actualidad el uso de las mtricas se est poniendo en prctica con xito

Es vlido aclarar que en ocasiones los resultados de los procesos de medicin

Varios estndares han incluido a las mtricas de software, a continuacin se

Familia ISO 9000

A pesar de la existencia de mtricas para evaluar la calidad de los productos de

Es un problema la gran variedad de mtricas que existen y que en la mayora

1.3 La Industria Cubana del Software

La Industria Cubana del Software (ICSW) est llamada a convertirse en una

En estudios realizados por Centros de Estudios de Ingeniera de Sistemas

Entre tantos problemas identificados las empresas de software cubanas estn

El Diccionario de la Real Academia Espaola, concepta la Calidad como la

Las definiciones anteriores conducen a la siguiente conclusin:

Calidad, resume las caractersticas, propiedades, cualidades y en general

1.4.1 Qu es Calidad de Software?

Se define la calidad de software como la ausencia de errores de

La principal muestra de calidad es que el usuario quede satisfecho con

La aplicacin de estndares es un factor importante en la obtencin de

Existen un conjunto de caractersticas que tienen que estar implcitas en

1.5 Mtricas de Software

Todas las organizaciones de software exitosas implementan mediciones como

Para poder asegurar que un proceso o sus productos resultantes son de

Para entender mejor el concepto de mtrica es necesario aclarar que los

Medida: Proporciona una indicacin cuantitativa de la extensin, cantidad,