PROCEDIMIENTO DE PRUEBAS NO FUNCIONALES PARA

SOFTWARE EDUCATIVO

NONFUNCTIONAL TEST PROCEDURE TO EDUCATIONAL SOFTWARE

Susej Beovides Luis1, Dayanis Castellanos Rodrguez2

1 Universidad de las Ciencias Informticas, sbeovides@uci.cu, 8372133
2 Universidad de las Ciencias Informticas, dcastellanosr@uci.cu, 8373201

Lnea temtica a las que tributa el trabajo: Impacto de las Nuevas Tecnologas Educativas

La Habana, octubre 2013

RESUMEN
Los Software Educativos son aquellos programas didcticos, creados con la finalidad de
ser usados para apoyar el proceso de enseanza aprendizaje. Para su estructura,
diseo y utilizacin se tienen en cuenta caractersticas y elementos fundamentales
especficos que definen este tipo de producto. En la actualidad el desarrollo de software
educativo presenta dificultades a la hora de comprobar el correcto funcionamiento de
los mismos en cuanto a requerimientos no funcionales, ya que solo se realizan acciones
aisladas en este sentido y debido a que se prioriza el desarrollo de las funcionalidades
del software y se le presta menor atencin a los requisitos no funcionales, siendo estos
tan o ms importantes que los funcionales.
Por este motivo en el presente trabajo se traza como objetivo general elaborar un
procedimiento para realizar pruebas a requisitos no funcionales de software educativos
e implementar una herramienta para automatizar la gestin de estas pruebas y que
sirva de apoyo para la aplicacin de este procedimiento. Como resultado de este
trabajo se obtuvo un procedimiento que define detalladamente cmo realizar las
pruebas no funcionales de portabilidad, mantenimiento, fiabilidad, usabilidad y eficiencia
a un software educativo y se desarroll una herramienta para gestionar estas pruebas.
Una vez confeccionada la propuesta, se prob la solucin dada en los laboratorios
virtuales que se desarrollan en el Centro de Informtica Industrial (CEDIN) de la
Universidad de las Ciencias Informticas (UCI), obteniendo muy buenos resultados y
proporcionndole as a estos productos una mejor calidad en cuanto a requisitos no
funcionales.
Palabras Clave: eficiencia, fiabilidad, mantenimiento pruebas no funcionales,
portabilidad, usabilidad.

ABSTRACT
The Educational Software are those didactic programs, created with the purpose to
develop such products with the highest possible quality to support the teaching and
learning process. For its structure, design and operation are taken into account specific
features and elements which defines this type of product. Nowadays the development of
educational software has difficulty to check its correct operation in terms of nonfunctional requirements , since only isolated actions are taken in this regard due to that it
is prioritized the development of software functionalities and pays less attention to nonfunctional requirements , these being as or more important than functional requirements.
For this reason it was created as a general objective, developing a procedure for testing
non-functional requirements of educational software and the implementation of a tool
that automates the management of non-functional testing. As a result of this work we
obtained a procedure that defines in detail how to test non-functional requirements of
portability, maintainability, reliability, usability and efficiency of educational software and
it was developed a tool to manage these tests. After the establishment of the proposal
was tested to the solution of virtual laboratories that it has been developed in Centro de
Informtica Industrial (CEDIN) Universidad de las Ciencias Informticas (UCI), obtaining
very good results and providing these products a better quality in terms of non-functional
requirements.
Keywords: efficiency, reliability, maintenance, non-functional testing, procedure,
portability, usability.

1. INTRODUCCIN
Actualmente el desarrollo tecnolgico crece a pasos gigantescos, provocando que las
industrias para mejorar la productividad y la calidad de los servicios a sus clientes
automaticen sus procesos. Debido a este crecimiento continuo de la produccin de
software la competencia cada da es ms potente, por lo que se hace vital que el
producto se desarrolle con la mayor calidad.
Cuando se trata de un software educativo, es de suma importancia que estos se
desarrollen con un alto grado de calidad y se le realicen las pruebas no funcionales,
puesto a que el desarrollo de este tiene como base, el poder desarrollar herramientas
que soporten efectivamente el proceso de enseanza-aprendizaje y no cumplira
objetivo si el software no fuera fcil de usar, seguro y fiable.
En la actualidad, los software educativos, presenta dificultades a la hora de comprobar
el correcto funcionamiento de los mismos en cuanto a requerimientos no funcionales, ya
que solo realiza acciones aisladas en este sentido, debido a que se prioriza el
desarrollo de las funcionalidades del software, siempre buscando cumplir con las
entregas y minimizar costos por retrasos. Esto provoca que se aparte la atencin de la
realizacin de estas pruebas y que no sean evaluados los requisitos no funcionales con
objetividad, generando problemas en cuanto a la utilidad del software, el tiempo de
respuesta de las funcionalidades, la seguridad de este, entre otras, ya que el error
encontrado en tiempo de ejecucin es ms costoso que el descubierto en un ambiente
controlado.
Por la situacin anteriormente planteada sera factible que los equipos de desarrollo de
software educativos contaran con una secuencia de pasos lgicos que guen cmo
llevar a cabo pruebas no funcionales, convirtiendo a los software en productos ms
confiables, usables y libre de errores. Estas pruebas pueden ser ejecutadas de
diferentes tipos, tales como pruebas de seguridad, rendimiento, usabilidad y
portabilidad.
Luego de un anlisis de las necesidades reales existentes y con el fin de solucionar la
situacin anterior, se plantea como problema cientfico realizar pruebas de software
para comprobar el cumplimiento de los requisitos no funcionales en software
1

educativos, enmarcndose este trabajo en el rea del desarrollo de pruebas de

software pero centrado principalmente en el proceso para realizar pruebas no
funcionales a software educativos.
Se define posteriormente como objetivo de esta investigacin elaborar un procedimiento
para realizar pruebas no funcionales a software educativos e implementar una
herramienta para automatizar la gestin de estas pruebas.
Para la realizacin de la presente investigacin se estudiaron ideas, propuestas y
definiciones relacionadas con temas como, calidad, pruebas de software y pruebas no
funcionales, de diferentes autores, organismos e instituciones, tales como la
Organizacin Internacional de Normalizacin (ISO, por sus siglas en ingls), el Instituto
de Ingenieros Elctricos y Electrnicos (IEEE, por sus siglas en ingls), el Instituto de
Ingeniera de Software (SEI, por sus siglas en ingls), Roger Pressman, entre otros
materiales actuales que se enmarcan en esta rea del conocimiento.

2. CONTENIDO
A continuacin se describe el procedimiento para la realizacin de pruebas no
funcionales para software educativo. Dicho procedimiento fue creado para dar
cumplimiento a los objetivos planteados en la investigacin, se centra en definir los
roles y sus responsabilidades, las actividades correspondientes, los artefactos de
entrada y salida que intervienen en la evaluacin de los requisitos no funcionales,
especficamente de portabilidad, mantenimiento, fiabilidad, usabilidad y eficiencia. Se
describe adems una herramienta que se desarrollar para gestionar las pruebas no
funcionales que se describen en el procedimiento.
2.1.

Procedimiento para realizar pruebas a requisitos no funcionales de

software educativos

2.1.1. Objetivos

Proporcionar una gua que permita evaluar el cumplimiento de los requerimientos

no funcionales en un determinado software educativo.

Calcular las mtricas establecidas para la medicin de las caractersticas de

calidad referente a los requerimientos no funcionales de portabilidad, mantenimiento,

fiabilidad y eficiencia a travs de los resultados alcanzados en las pruebas.

Evaluar el grado de implementacin de las caractersticas de calidad referente a

los requerimientos no funcionales del software educativo que se evala.

2.1.2. Alcance
El procedimiento es aplicable a todo software educativo.
2.1.3. Referencias
ISO/IEC 25000
2.1.4. Roles, responsabilidades y habilidades
La siguiente tabla resume los roles involucrados en el procedimiento para evaluar el
cumplimiento de los requerimientos no funcionales en un determinado software
educativos, as como las responsabilidades de cada rol y sus habilidades.
Tabla I: Roles, responsabilidades y habilidades
Roles
Responsabilidades
Administrador
Asigna las tareas y los
de la calidad productos
[11].

de

trabajo

Habilidades
Dominar
tcnicas

los recoleccin de informacin.

probadores para la ejecucin de las

Dominar

el

ciclo

pruebas.

desarrollo de software.

Elabora los planes de prueba.

Participa en las revisiones ingeniera

tcnicas formales de los artefactos.

Dominar las materias de

y

gestin

de

software.
Dominar la programacin.

Dominar el modelo CMMI.

Gua el diseo y ejecucin de

Explotar con efectividad la

las pruebas internas.

de

Participa en las revisiones con

el cliente de los entregables.

de

suite de office.

Vela por el cumplimiento de

Dominar

los

tipos

de

las polticas de la organizacin y pruebas.

3

reglas bases del proyecto.

Dominar el trabajo con

Coordina y colabora con las herramientas de automatizacin

pruebas de liberacin externa al de pruebas.

proyecto.

Conocer los principales

Crea una cultura de calidad en conceptos relacionados con la

calidad de software.

el proyecto.

Probador

[11].

planes de pruebas.

tcnicas de las pruebas.

Ejecuta los casos de prueba.

Realiza revisiones estticas a herramientas

Encargado

de

seguir

los

Conocer

los

tipos

Dominar

y
las

de

pruebas

la documentacin.

definidas.

Genera No conformidades.

Registra los resultados de las procedimientos y lineamientos

pruebas.

que norman la produccin.

Analiza los resultados de las

pruebas realizadas.

Conocer los estndares,

Conocer las anomalas

de software y errores ms
comunes.

2.1.5. Trminos y definiciones

Artefacto: Cualquier informacin creada, cambiada o utilizada por las personas en el
desarrollo de sus actividades.
Plan de pruebas: Describir los objetivos de las pruebas, identificar los elementos que
debern ser probados, los mtodos que debern utilizarse, los recursos que son
necesarios y los documentos a entregar.
No conformidades: Defectos y/o sugerencias detectadas por el equipo de pruebas.
Especificaciones complementarias: Describe los requisitos no funcionales del
sistema.
Casos de pruebas: Un conjunto de condiciones o variables bajo las cuales se
determina si un requisito es parcial o completamente satisfactorio. Su propsito es
4

especificar una forma de probar el sistema que incluya las entradas, los resultados
esperados y las condiciones bajo las que ha de probarse.
Ticket: Tarea.
2.1.6. Descripcin general del Procedimiento para realizar pruebas a requisitos
no funcionales de software educativos
El procedimiento para la realizacin de pruebas no funcionales de software educativos
se centra en definir los roles y responsabilidades, las actividades correspondientes y los
artefactos de entrada y salida que intervienen en la evaluacin de los requisitos no
funcionales, especficamente de portabilidad, mantenimiento, fiabilidad y eficiencia,
evaluando estos a travs de las mtricas establecidas para medir estas caracterstica
de calidad (Ver Anexos 1, 2, 3 y 4). Verifica tambin el cumplimiento de la
caracterstica: usabilidad, a partir de una lista de chequeo de usabilidad (Anexo 5). El
procedimiento puede ser aplicado en las tres iteraciones de pruebas que se le deben
realizar al software.
Dicho procedimiento contiene cinco actividades generales, ellas son:
1. Preparar el entorno de la prueba.
2. Ejecutar la prueba segn el requerimiento no funcional a evaluar.
3. Existen No Conformidades?
4.

Registrar las no conformidades y asignar responsabilidades.

5.

Anlisis de resultados.

Cada una de estas actividades estn subdivididas en actividades que desempean

cada uno de los roles involucrados.
La siguiente tabla muestra el procedimiento general para la realizacin de las pruebas
no funcionales a software educativo.

Procedimiento general para realizar pruebas a requisitos no funcionales de

software educativos.
Tipos de pruebas: No funcionales.
Criterio de entrada Plan de pruebas.
Criterio de salida
Acta de liberacin del producto.
Roles
Entrada
Control
Actividades
Salida
Administrador

Requisitos no Ticket y plan de

de la calidad, funcionales y pruebas

lder
proyecto

del Plan

de proyecto.

y pruebas.

del

1. Preparar el
entorno de la

Ticket.
(actualizado)

prueba.

probador.
Probador

(Depende del
requerimiento
a evaluar)

2. Ejecutar la
prueba segn el
requerimiento no
funcional a evaluar.

Aplicacin
probada.

3.Existen No
Conformidades?

Probador

Probador

[si]
Plantilla de no 4. Registrar las no
conformidades conformidades y
asignar
y Registro de
responsabilidades.
No
[No]
Conformidades.
(Depende del Aplicacin para 5. Anlisis de
requerimiento la Gestin de resultados
a evaluar)
Pruebas
no

Ticket

(No

conformidades
asignadas).
Registro de No
conformidades.
Reportes

de

resultados

de

la aplicacin.

Funcionales.

El procedimiento general se trasformar en dependencia del requerimiento no funcional

a evaluar. Derivarn de este procedimiento, los procedimientos especficos para la
evaluacin del cumplimiento de cada uno de los requerimientos no funcionales. La
actividad 2, que es Ejecutar la prueba para cada requisito no funcional va a dividirse
en varias actividades correspondiente a las pruebas a ejecutar para dicho requerimiento
y por tanto vara la sucesin de pasos en el procedimiento especfico.
En el caso de los requisitos no funcionales de portabilidad, mantenimiento, fiabilidad y
eficiencia las actividades del procedimiento van dirigidas a orientar al probador para la
obtencin de los parmetros necesarios para el clculo de las mtricas que se
proponen en la ISO 25 000 para la evaluacin de cada uno de estos requisitos, una vez
obtenidos estos indicadores, para la ejecucin de la actividad 5 Anlisis de Resultados
se utiliza la herramienta para la Gestin de Pruebas no Funcionales (implementada en
el presente trabajo), donde se registran los parmetros necesarios para las mtricas. En
esta herramienta se van a mostrar los resultados de la evaluacin de cada uno de los
requisitos ejecutados.
Para el requisito de usabilidad se orienta al probador para que actualice una lista de
chequeo de usabilidad que se propone en la presente investigacin y en este mismo
artefacto se le propone una evaluacin al producto que se est probando en cuanto a la
usabilidad.
A continuacin se describe como vara en cada requisito a evaluar en el procedimiento
las actividades 1 y 2, as como sus artefactos de entrada y salida.
2.1.6.1.

Descripcin del Procedimiento para evaluar el cumplimiento de la

portabilidad en un software educativo

Para evaluar el cumplimiento de la portabilidad en un software educativo y conocer si el

producto de software puede ser transferido de un ambiente a otro, ya sea software o
hardware, se debe seguir el procedimiento general para la realizacin de pruebas no
funcionales de un software educativo. Para realizar la primera actividad de dicho
procedimiento general los artefactos de entrada son:
Manual de instalacin
7

 Instalador de la aplicacin.
Para la ejecucin de la prueba, que es la actividad 2 se desglosa en varias actividades
para apoyar la ejecucin de esta, tales como
2.1 Existe una versin de la aplicacin?
2.2. Ejecutar la versin anterior.
2.3. Ejecutar la Aplicacin que se est probando.
Para la realizacin de estas actividades se deben tener en cuenta artefactos como:
Plantilla de especificaciones complementarias del software que se est
probando.
Plantilla de control de versiones.
2.1.6.2.

Descripcin del Procedimiento para evaluar el mantenimiento de un

software educativo.

Para evaluar el cumplimiento del mantenimiento en un software educativo y conocer si

el producto de software puede ser modificado, se debe seguir el procedimiento general
para la realizacin de pruebas no funcionales de un software educativo. Para realizar la
primera actividad de dicho procedimiento general el artefacto de entrada es la planilla
de No Conformidades de tipo:
excepciones,
funcionalidad,
validacin,
opciones que no funcionan.
Para la actividad 2 se utilizan los artefactos de entrada de la actividad 1.
2.1.6.3.

Descripcin del Procedimiento para evaluar la fiabilidad en un software

educativo

Para evaluar el cumplimiento de la fiabilidad en un software educativo y conocer si el

sistema es libre de fallos se debe seguir el procedimiento general para la realizacin de
pruebas no funcionales de un software educativo. Para realizar la primera actividad de
dicho procedimiento general los artefactos de entrada son:
Diseo de casos de pruebas.
Para la actividad 2 se utilizan los artefactos de entrada de la actividad 1.
8

2.1.6.4.

Descripcin del Procedimiento para evaluar el cumplimiento de la

eficiencia en un software educativo

Para evaluar el cumplimiento de la eficiencia en un software educativo se debe seguir el

procedimiento general para la realizacin de pruebas no funcionales a un software
educativo. Para realizar la actividad 1 de dicho procedimiento general los artefactos de
entrada son:
Diseo de casos de pruebas.
Herramienta JMeter, para la ejecucin de pruebas de carga y rendimiento.
JMeter es una herramienta libre y escrita en Java, es la ms completa y til para
realizar pruebas de carga y rendimiento, se le puede aplicar a cualquier tipo de
aplicacin y existe experiencia en su uso en el Centro de Calidad de Software de la UCI
(CALISOFT), por lo que es una herramienta propuesta por las autoras para utilizar
dentro del procedimiento para evaluar la eficiencia.
Para la actividad 2 se utilizan los artefactos de entrada:
Diseo de caso de pruebas.
Especificaciones complementarias.
Plan de pruebas obtenido de JMeter.
Una vez ejecutadas las pruebas en JMeter siguiendo la descripcin detallada de las
actividades se obtienen los reportes de resultados de esta, de los cuales se toman los
parmetros necesarios para el clculo de las mtricas que se proponen en la ISO 25
000 para evaluar el cumplimiento de la eficiencia (Ver Anexo 4).
2.1.6.5.

Descripcin del Procedimiento para evaluar la usabilidad en un software

educativo

Para evaluar el cumplimiento de la usabilidad en un software educativo y conocer si el

producto de software puede ser comprendido, aprendido, utilizado y atractivo para el
usuario se debe seguir el procedimiento general para la realizacin de pruebas no
funcionales a un software educativo. Para realizar la actividad 1 de dicho procedimiento
general el artefacto de entrada es:
La lista de chequeo de usabilidad (Ver Anexo 5).
9

Para la actividad 2 se debe actualizar esta lista al verificar el cumplimiento de los

indicadores a evaluar.
2.2.

Herramienta para la Gestin de pruebas no funcionales

La herramienta para la Gestin de pruebas no funcionales surge a partir de la

necesidad de automatizar el clculo de las mtricas para evaluar los requerimientos no
funcionales. Es una aplicacin de escritorio, que permite la entrada de los datos
necesarios para el clculo de cada una de las mtricas correspondientes a las
caractersticas para la obtencin de la calidad del software en cuanto a requerimientos
no funcionales. La herramienta facilita el trabajo del probador para evaluar el
cumplimiento de estos requerimientos. Los requisitos que se evalan en la herramienta
son:
eficiencia,
portabilidad,
mantenimiento,
fiabilidad.
Estos requisitos son parte del procedimiento para realizar pruebas no funcionales de un
software educativo.
2.2.1. Caractersticas y requerimientos tcnicos
La herramienta posee diferentes caractersticas como las que sern mostradas a
continuacin, al igual que los requerimientos tcnicos que esta necesita para su
funcionamiento.
Caractersticas:
Aplicacin de Escritorio.
Multiplataforma.
Requerimientos tcnicos:
Sistema operativo: Windows, Linux.
Licencia: GPL.
Idioma: Espaol.
Tamao: 10.2 MB
10

 Memoria RAM: Mnimo 128 MB.

Lenguaje de Implementacin: C++.
IDE: Qt Creator.
1.2.2. Interfaz grfica de la herramienta

Figura 1. Interfaz Mtricas para evaluar la portabilidad.

Figura 2. Interfaz Mostrar Resultados.

11

2.3.

Resultados

Para validar los resultados de esta investigacin se realiz un anlisis estadstico de los
resultados arrojados al aplicar una encuesta a una muestra formada por un grupo de 7
especialistas en calidad y pruebas de software. Todo este proceso ayud a la mejora de
la presente investigacin, el trabajo con los especialistas no solo aport valores
cuantitativos sino que tambin brind anlisis de los resultados que hicieron madurar
ms la propuesta. Luego del anlisis de resultados de la validacin se obtuvo una alta
probabilidad de xitos de la propuesta.
Posteriormente se aplic el procedimiento descrito, con el uso de la herramienta para la
Gestin de Pruebas no Funcionales en el proyecto Laboratorios Virtuales, proyecto
donde se obtienen software educativos de este tipo y que se desarrollan en el Centro
de Informtica Industrial (CEDIN), de la Universidad de las Ciencias Informticas (UCI),
obtenindose parmetros que hasta el momento se pensaban buenos pero que por la
aplicacin del procedimiento se constat que aun deban ser mejorados.
De esta forma se demostr la utilidad del procedimiento realizado para el desarrollo de
software educativo y la necesidad de aplicarlo a cuanto software de este tipo se
desarrolle para que estos productos en el futuro sean entregados a sus clientes con la
mayor calidad posible en cuanto al cumplimiento de los requisitos no funcionales.

CONCLUSIONES
En el presente trabajo se elabora y describe un procedimiento con el fin de desarrollar
pruebas no funcionales de un software educativo, haciendo uso de la herramienta para
la Gestin de Pruebas no Funcionales, herramienta desarrollada por las autoras de esta
investigacin, para apoyar dicho procedimiento.
Para dar cumplimiento a los objetivos planteados, se desarrollaron un grupo de tareas
de las que se puede concluir, de forma general, lo siguiente:

Se identificaron conceptos, definiciones y teoras en el campo de pruebas no

funcionales, los que facilitaron la comprensin del tema a desarrollar.

El procedimiento se organiz adecuadamente, identificando roles, requerimientos

a probar, actividades a seguir para dar cumplimiento al proceso de prueba no

12

funcionales de un software educativo con ayuda de herramientas automatizadas como

JMeter.

La creacin de la herramienta para la Gestin de Pruebas no Funcionales y su

posterior uso permiti gestionar la evaluacin de los requerimientos no funcionales de

portabilidad, mantenimiento, fiabilidad y eficiencia y de esta forma apoy la puesta en
prctica del procedimiento propuesto en el presente trabajo.

Se aplic el procedimiento de pruebas no funcionales propuesto en los

laboratorios virtuales que se desarrollan en el CEDIN, en la UCI, logrando una buena

aceptacin.

REFERENCIAS
1.
PRESSMAN, R. Ingeniera del Software. Un enfoque prctico. Edtion ed., 2005.
2.

IEEE Standard Glossary of Software Engineering Terminology. Edtion ed., 1991.

3.

ISO/IEC 9126. Edtion ed., 2001.

4.

ISO/IEC 25000. Edtion ed., 2005.

5.

GLENFORD J. MYERS, C. S., TOM BADGETT The Art of Software Testing.

Edtion ed., 2011.

6.

IEEE SWEBOK. Guide to the Software Engineering Body of Knowledge. Edtion

ed., 2004. ISBN 0-7695-2330-7.

7.

ALEJANDRO OCAMPO ACOSTA, L. M. C. T. IMPACTO DE LAS PRUEBAS NO

FUNCIONALES EN LA MEDICIN DE LA CALIDAD DEL PRODUCTO
SOFTWARE DESARROLLADO. In., 2011.

8.

Comit Tcnico y de Normalizacin NC/CTN 18 de Tecnologas de la

Informacin. ISO/IEC 9126-1. Ingeniera de software. Calidad del producto. Parte
1: Modelo de la calidad. . Edtion ed. Ciudad de La Habana: Oficina Nacional de
Normalizacin, 2005.

9.

AILYN FEBLES ESTRADA, T. C. G., YENISET LEN PERDOMO, ALIONUSKA

VELZQUEZ CINTRA, RAMSS DELGADO MARTNEZ, ROIG CALZADILLA
DAZ. Una experiencia novedosa para el testing desarrollada por un
departamento de pruebas de software. In. Revista Cubana de Ciencias
Informticas.
13

10.

SNCHEZ, E. R. V. Educatrnica: Innovacin en el aprendizaje de las ciencias y

la tecnologa. edited by E.D.D. SANTOS. Edtion ed., 2007. ISBN ISBN
8479788224, 9788479788223.

11.

PROGRAMA DE MEJORA 0516_ROLES Y RESPONSABILIDADES.

Universidad de las Ciencias Informticas.

14

ANEXOS:
Anexo 1. Mtricas para la medicin de la caracterstica portabilidad.
Nombre
Facilidad

Definicin
de

Metas

Procedimiento de anlisis

X = A/B

Puede el usuario instalar

Observe el comportamiento

instalacin

A = nmero de casos en los cuales el

fcilmente el producto de

del usuario cuando tratan de

(Instalabilidad)

usuario tiene xito en las operaciones

software en su ambiente de

instalar

para una instalacin adecuada a su

operacin?

software en su ambiente de

el

producto

de

conveniencia.

operacin

B = nmero total de casos en los cuales

0 <= X <= 1 Ms cercano al 1

el usuario intenta adecuar la instalacin a

resultar mejor.

su conveniencia.
Facilidad

de

X = A/B

Puede el usuario o

reintento

de

A = Nmero de casos en los cuales el

Serviciador

ejecucin

del

usuario no tiene xito al reintentar

reintentar

ejecutar

el

instalador

ejecutar el instalador.

programa

instalador

del

(Instalabilidad)

B = Nmero total de casos en los cuales

software?

Observe el comportamiento

fcilmente

del

usuario

serviciador

cuando tratan de reinstalar el

producto de software.
0 <= X <= 1 Ms cercano al 1

el usuario reintenta ejecutar la instalacin

resultar mejor.

durante la operacin de instalacin.

Conformidad de la

X = 1 - A/ B

Cun

conforme

es

portabilidad

A = Nmero de elementos especificados

portabilidad del producto de

que requiriendo estar en conformidad no

software

han sido implementados durante las

regulaciones, las normas y

pruebas. B = Nmero total de elementos

convenciones que les son

especificados que requieren estar en

aplicables?

con

la

0 <= X <= 1
A mayor cercana al 1 mejor.

las

conformidad.
Funcin

de

la

X=A/B

Puede el usuario o

La observacin del usuario

inclusin.

A = nmero de funciones que producen

Mantenedor

(Reemplazabilidad)

resultados

similares

comportamiento

del

continuar utilizando funciones

mantenedor

similares

usuario est reemplazando

cambios no han sido requeridos.

sustitucin de este software a

un

B = nmero de funciones que son

uno anterior?

anterior?

probadas

Es la migracin del sistema

0<= X <=1

de software un xito?

Mientras mayor sea, mejor.

las

los

el

previamente producidos y donde los

similares

como

fcilmente

funciones

proporcionadas por otro software.

despus

de

la

software

cuando
con

el
uno

Anexo 2. Mtricas para la medicin de la caracterstica mantenimiento.

Nombre
Capacidad
anlisis

de

(Analizabilidad).

Definicin
de
fallos

Metas

Procedimiento de anlisis

X = 1- A / B

Se puede identificar la

Observar el comportamiento de

A = Nmero de fallos cuyas causas an

operacin especfica que

los usuarios o el personal de

no han sido encontradas. B = Nmero

caus el fracaso?

mantenimiento responsable de

total de fallos registrados

Puede el personal de

resolver los fallos.

mantenimiento

0 <= X <= 1 Mientras ms

encontrar

la

fcilmente
causa

del

cercano al 1, mejor.

fallo?

15

Tiempo empleado en

(Tout Tin) / N

Puede el personal de

Observar el comportamiento del

implementar

Tout = Tiempo promedio en que se

mantenimiento

usuario

resuelven los fallos.

fcilmente

cambio

un

por

personal

el
de

realizar

cambios

al

el

mantenimiento

personal
al

tratar

de
de

Tin = Tiempo promedio en el que se

software para resolver los

cambiar el software. En caso

mantenimiento.

encuentran los fallos.

problemas de fracaso?

contrario, investigar en el informe

(Cambiabilidad)

N = Nmero de fallos registrados y

de resolucin de problemas o el

eliminados.

informe de mantenimiento.
0 < Tp.
Entre ms se acerque a cero
mejor.

Fallos

encontrados

X = Na/Ta

Puede el usuario operar

Observar el comportamiento del

despus del cambio.

Na = Nmero de casos en los que el

el sistema de software sin

usuario o mantenedor del sistema

(Estabilidad)

usuario encuentra errores durante la

fallos

de

operacin despus que el software fue

mantenimiento?

cambiado.

El

Ta = El tiempo de funcionamiento

fcilmente

durante el perodo de observacin

averas causadas por los

contemplado despus que el software

efectos

es cambiado.

mantenimiento?

Pruebas

sin

despus

de

su

software

despus

de

su

mantenimiento.

mantenedor

puede

reducir

las

secundarios

0<=X
Cuanto ms pequeo y cercano a
0 es mejor.

de

X = Sum(T)/N

Puede el usuario y el

Observar el comportamiento del

esfuerzo.

T = Tiempo empleado en probar con el

mantenedor

usuario o el mantenedor, quienes

(Facilidad de prueba)

fin de asegurar si el informe de fallo ha

realizar

sido o no resuelto.

funcionamiento

N = Nmeros de fallos resueltos

determinar si el software

0<X Cuanto ms cercano a cero

est listo para funcionar o

mejor.

fcilmente
pruebas

de
y

estn

probando

el

sistema

despus del mantenimiento.

no?

Anexo 3. Mtricas para la medicin de la caracterstica fiabilidad.

Metas

Procedimiento de anlisis

Madurez (Prueba de

Nombre
X=A/B

Definicin

Es el producto de pruebas

Observar la cantidad de casos

Madurez).

A = Nmero de casos de prueba que

de pozos?

de

han pasado realmente ejecutados.

Este

B = Nmero de casos de prueba que se

predecir la tasa de xito que

comparando con el nmero

realizan segn los requisitos.

el producto alcanzar en la

total de pruebas que deberan

prueba en el futuro.

realizarse

comentario

es

para

prueba

realmente

que

fueron

ejecutados

segn

los

requisitos.
0 <= X<=1, el ms cercano a
1.0 es la mejor
Tolerancia
fallos
Desglose)

ante
(Evitar

X=1-A/B

Con

el

Probar la madurez teniendo

A = Nmero de averas B = Nmero de

producto de software hace

qu

frecuencia

xito en contar el nmero de

fallos.

qu el desglose del entorno

averas

de produccin total falle?

nmero de fallos.

con

respecto

al

0 <= X<=1, el ms cercano a

1.0 es la mejor.

16

X = A/B

Cmo

las

Probar la madurez logrando

A = Nmero de ocurrencias que evitan

funciones se implementan con

expresar el nmero de casos

funcionamiento

fallos crticos y graves

la

de prueba que tuvieron un

incorrecto)

B = Nmero de casos de prueba

Tolerancia
fallos

(Evitar

ante
un

ejecutados

de

los

patrones

muchas

capacidad

de
de

evitar

operaciones incorrectas?

funcionamiento incorrecto que

de

evitaron causar fallos crticos

funcionamiento incorrecto (fallos casi

y compararlo con el nmero

causa) durante la prueba.

de

casos

de

prueba

ejecutados de los patrones de

funcionamiento incorrecto.
0 <= X<=1, el ms cercano a
1.0 es mejor debido a que se
evita una operacin ms de
usuario incorrecto.
Recuperabilidad.

X= { To / (To+Tr) }

Cmo

encuentra

Se mide el perodo de tiempo

(Disponibilidad)

Y= A1/A2

disponible el sistema para su

de reparacin cada vez que el

To = Operacin de tiempo

uso durante el perodo de

sistema no est disponible.

Tr = tiempo de reparacin

tiempo especificado?

0 <= X<=1, el ms grande y

se

A1 = Total de casos de uso a

ms cercano a 1.0 es mejor

disposicin del usuario de software de

que el usuario puede utilizar el

xito.

software para obtener ms

A2 = Total de casos de intento de

tiempo.

usuario para utilizar el software durante

0 <= Y<=1, el ms grande y

la medicin del tiempo.

ms cercano a 1.0 es la
mejor.

Valor de una sub-caracterstica especfica

Descripcin.

Definicin.

El objetivo de esta mtrica es conocer el valor de la subcaracterstica debido a que hay varios casos donde existe ms
de una mtrica para la misma sub-caracterstica, se pretende

Vsub = Valor de la sub-caracterstica.

con esto conocer un nico valor.

CmSub = Valor obtenido despus de haber realizado el clculo

de la mtrica para esa sub-caracterstica
CM = Cantidad de mtricas de la sub-caracterstica.
Por ciento de Fiabilidad

Descripcin.

Definicin.

Con esta mtrica se calcula el por ciento de Fiabilidad de un

componente con respecto a las sub-caractersticas escogidas
esta frmula depende del resultado anterior calculado de la

Pfi = Por ciento Fiabilidad.

frmula.

VSub = Valor de la sub-caracterstica.

CSub = Cantidad de sub-caractersticas.
Nivel de Fiabilidad

Nivel

Intervalo

Porciento Final

Alto

0.8 X 1

80% ----100%

Medio

0.5 X < 0.8

50%----79%

Bajo

X < 0.5

Menor o igual que 49%

17

Anexo 4. Mtricas para la medicin de la caracterstica eficiencia.

Nombre

Tiempo de
respuesta

Definicin

Metas

Procedimiento

T = Tiempo empleado en

Cunto tiempo toma completar

Comience una tarea especfica. Mida el

obtener el resultado.

una tarea en particular?

tiempo que esta toma en completar una

Cunto toma antes de que el

muestra hasta que concluya la operacin

sistema

emprendida. Guarde los registros de cada

responda

una

determinada operacin?

intento.
0 < T a mayor prontitud (menor tiempo)
resultar mejor.

Tiempo de espera

X = Ta/Tb

Qu proporcin del tiempo los

Ejecutar

Ta = Tiempo total dedicado

usuarios dedican a esperar por

situaciones

a esperar.

una respuesta del sistema?

concurrentes. Mida el tiempo que toma

los

casos

de

pruebas

caractersticas

en

tareas

Tb = Tiempo consumido

completar las operaciones seleccionadas.

por la tarea.

Guarde un registro de cada intento y

calcule el tiempo medio para cada caso o
situacin.
0 <= X Cuanto menor resultar mejor.

Relacin entre los

X = A/T

Cuntos errores de memoria

Calibre las condiciones de prueba. Emule

errores

A = Nmero de mensajes

fueron identificados durante el

una condicin en que el sistema haya

de

memoria

de
y

el

alerta

fallos

del

perodo de tiempo especificado,

alcanzado un mximo de carga. Ejecute la

tiempo (Utilizacin

sistema.

aplicacin y registre el nmero de errores

de recursos).

T = Tiempo de operacin

recursos especificada?

con

una

utilizacin

de

del usuario.

debido a fallos de memoria.

0 < X Ms pequea, mejor.

Anexo 5. Resumen de los elementos ms importantes de la plantilla Lista de

chequeos de usabilidad.
1.1.

Objetivo.

El objetivo general de la lista de chequeo de usabilidad es evaluar los atributos y propiedades de usabilidad para determinar si se
les dio cumplimiento en el desarrollo del producto <nombre del producto>. Esta planilla ha sido confeccionada para guiar a
desarrolladores, especialistas o expertos tcnicos en la verificacin y evaluacin de las especificaciones de usabilidad del software.
Recoger los puntos eficientes e ineficientes que tienen los elementos chequeados.
1.2.

Alcance.

Esta planilla es aplicable a cada una de las revisiones de especificaciones de usabilidad del software educativo que se desarrolle.
1.3.

Definiciones y acrnimos.

Peso: Define si el indicador a evaluar es crtico o no.

Evaluacin (Eval): Es la forma de evaluar el indicador en cuestin. Este se evala de 1 en caso de mal y 0 en caso de
que no presente errores.

Cantidad de elementos afectados: Especifica la cantidad de errores encontrados sobre el mismo indicador.

Comentario: Especifica los sealamientos o sugerencias que quiera incluir la persona que aplica la lista de chequeos.

1.4.

NP. (No procede): Se usa para especificar que el indicador a evaluar no se puede evaluar en ese caso.
Referecia.

IEEE.1991 IEEE Standard Glossary of Software Engineering Terminology. Spring 1991 Edition. 1991. IEEE Standard 610.12-1990.

18

4.

Estructura de la lista de chequeo.

Pantalla de Bienvenida
Peso

Indicador a evaluar

Eval

(NP)

Cantidad

de

Comentarios

elementos afectados
El software presenta un identificador visual?
Presenta la versin del producto?
Presenta la entidad que desarrolla el producto?
Presenta la informacin de soporte: informacin de los
telfonos, correos, equipo de soporte?
Presenta la pertenencia legal del producto: Especificacin de
la propiedad intelectual y comercial del producto?
La pgina de bienvenida est diseada profesionalmente y
va a crear una primera impresin positiva?
Minimizar carga de usuarios
Crtico

Est el sistema libre de informacin irrelevante e

innecesaria?

Crtico

En la interfaz se utiliza el lenguaje de los usuarios y no uno

propio relacionado con la tecnologa?

Crtico

Son pocos los pasos que el usuario tiene que efectuar para
realizar una accin especfica?

Crtico

Entiende bien el usuario lo que tiene que hacer?

5. Evaluacin.
Se aborta la revisin del software evaluado si:

Existen al menos dos indicadores crticos evaluados de mal.

Existen ms de una falta de ortografa en pantalla.

Incumple ms del 50% de los indicadores a evaluar de la seccin Estructura de la lista de chequeo.

Se mantienen las No Conformidades de una revisin a otra.

Se evala de regular la calidad usabilidad del software revisado si no cumple los criterios para ser abortado y:

Existe una No Conformidad crtica.

La cantidad de elementos afectados de un indicador evaluado de mal es superior a 3.

El software es evaluado de bien si no cumple ninguno de los criterios anteriores y:

No existe ninguna No Conformidad relacionada con indicadores con peso crtico.

Si la cantidad de elementos afectados de un indicador que no sea crtico no es mayor que 2.

Evaluacin: ___________
Nombre y apellidos del evaluador: _____________________________________________

19