PROCEDIMIENTO DE PRUEBAS NO FUNCIONALES PARA SOFTWARE EDUCATIVO NONFUNCTIONAL TEST PROCEDURE TO EDUCATIONAL SOFTWARE

Transcripción

1 PROCEDIMIENTO DE PRUEBAS NO FUNCIONALES PARA SOFTWARE EDUCATIVO NONFUNCTIONAL TEST PROCEDURE TO EDUCATIONAL SOFTWARE Susej Beovides Luis 1, Dayanis Castellanos Rodríguez 2 1 Universidad de las Ciencias Informáticas, sbeovides@uci.cu, Universidad de las Ciencias Informáticas, dcastellanosr@uci.cu, Línea temática a las que tributa el trabajo: Impacto de las Nuevas Tecnologías Educativas La Habana, octubre 2013

2 RESUMEN Los Software Educativos son aquellos programas didácticos, creados con la finalidad de ser usados para apoyar el proceso de enseñanza aprendizaje. Para su estructura, diseño y utilización se tienen en cuenta características y elementos fundamentales específicos 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 atención a los requisitos no funcionales, siendo estos tan o más 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 gestión de estas pruebas y que sirva de apoyo para la aplicación de este procedimiento. Como resultado de este trabajo se obtuvo un procedimiento que define detalladamente cómo 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 solución dada en los laboratorios virtuales que se desarrollan en el Centro de Informática Industrial (CEDIN) de la Universidad de las Ciencias Informáticas (UCI), obteniendo muy buenos resultados y proporcionándole así a estos productos una mejor calidad en cuanto a requisitos no funcionales. Palabras Clave: eficiencia, fiabilidad, mantenimiento pruebas no funcionales, portabilidad, usabilidad.

3 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 Informática Industrial (CEDIN) Universidad de las Ciencias Informáticas (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.

4 1. INTRODUCCIÓN Actualmente el desarrollo tecnológico 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 producción de software la competencia cada día es más 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 enseñanza-aprendizaje y no cumpliría objetivo si el software no fuera fácil 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 atención de la realización 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 ejecución es más costoso que el descubierto en un ambiente controlado. Por la situación anteriormente planteada sería factible que los equipos de desarrollo de software educativos contaran con una secuencia de pasos lógicos que guíen cómo llevar a cabo pruebas no funcionales, convirtiendo a los software en productos más 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 análisis de las necesidades reales existentes y con el fin de solucionar la situación anterior, se plantea como problema científico realizar pruebas de software para comprobar el cumplimiento de los requisitos no funcionales en software 1

5 educativos, enmarcándose 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 investigación elaborar un procedimiento para realizar pruebas no funcionales a software educativos e implementar una herramienta para automatizar la gestión de estas pruebas. Para la realización de la presente investigación 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 Organización Internacional de Normalización (ISO, por sus siglas en inglés), el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE, por sus siglas en inglés), el Instituto de Ingeniería de Software (SEI, por sus siglas en inglés), Roger Pressman, entre otros materiales actuales que se enmarcan en esta área del conocimiento. 2. CONTENIDO A continuación se describe el procedimiento para la realización de pruebas no funcionales para software educativo. Dicho procedimiento fue creado para dar cumplimiento a los objetivos planteados en la investigación, se centra en definir los roles y sus responsabilidades, las actividades correspondientes, los artefactos de entrada y salida que intervienen en la evaluación de los requisitos no funcionales, específicamente de portabilidad, mantenimiento, fiabilidad, usabilidad y eficiencia. Se describe además una herramienta que se desarrollará para gestionar las pruebas no funcionales que se describen en el procedimiento Procedimiento para realizar pruebas a requisitos no funcionales de software educativos Objetivos Proporcionar una guía que permita evaluar el cumplimiento de los requerimientos no funcionales en un determinado software educativo. 2

6 Calcular las métricas establecidas para la medición de las características de calidad referente a los requerimientos no funcionales de portabilidad, mantenimiento, fiabilidad y eficiencia a través de los resultados alcanzados en las pruebas. Evaluar el grado de implementación de las características de calidad referente a los requerimientos no funcionales del software educativo que se evalúa Alcance El procedimiento es aplicable a todo software educativo Referencias ISO/IEC 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 Habilidades Administrador Asigna las tareas y los Dominar técnicas de de la calidad productos de trabajo a los recolección de información. [11]. probadores para la ejecución de las Dominar el ciclo de pruebas. desarrollo de software. Elabora los planes de prueba. Dominar las materias de Participa en las revisiones ingeniería y gestión de técnicas formales de los artefactos. software. Participa en las revisiones con Dominar la programación. el cliente de los entregables. Dominar el modelo CMMI. Guía el diseño y ejecución de Explotar con efectividad la las pruebas internas. suite de office. Vela por el cumplimiento de Dominar los tipos de las políticas de la organización y pruebas. 3

7 Probador [11]. reglas bases del proyecto. Coordina y colabora con las pruebas de liberación externa al proyecto. Crea una cultura de calidad en el proyecto. Encargado de seguir los planes de pruebas. Ejecuta los casos de prueba. Realiza revisiones estáticas a la documentación. Genera No conformidades. Registra los resultados de las pruebas. Analiza los resultados de las pruebas realizadas. Dominar el trabajo con herramientas de automatización de pruebas. Conocer los principales conceptos relacionados con la calidad de software. Conocer los tipos y técnicas de las pruebas. Dominar las herramientas de pruebas definidas. Conocer los estándares, procedimientos y lineamientos que norman la producción. Conocer las anomalías de software y errores más comunes Términos y definiciones Artefacto: Cualquier información 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 deberán ser probados, los métodos que deberán 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 propósito es 4

8 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 Descripción general del Procedimiento para realizar pruebas a requisitos no funcionales de software educativos El procedimiento para la realización 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 evaluación de los requisitos no funcionales, específicamente de portabilidad, mantenimiento, fiabilidad y eficiencia, evaluando estos a través de las métricas establecidas para medir estas característica de calidad (Ver Anexos 1, 2, 3 y 4). Verifica también el cumplimiento de la característica: 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 según el requerimiento no funcional a evaluar. 3. Existen No Conformidades? 4. Registrar las no conformidades y asignar responsabilidades. 5. Análisis de resultados. Cada una de estas actividades están subdivididas en actividades que desempeñan cada uno de los roles involucrados. La siguiente tabla muestra el procedimiento general para la realización de las pruebas no funcionales a software educativo. 5

9 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 liberación del producto. Roles Entrada Control Actividades Salida Administrador de la calidad, líder del proyecto y Requisitos no funcionales y Plan de pruebas. Ticket y plan de pruebas del proyecto. 1. Preparar el entorno de la prueba. Ticket. (actualizado) probador. Probador (Depende del requerimiento a evaluar) 2. Ejecutar la prueba según el requerimiento no funcional a evaluar. Aplicación probada. 3. Existen No Conformidades? Probador Plantilla de no conformidades y Registro de No Conformidades. [si] 4. Registrar las no conformidades y asignar responsabilidades. [No] Ticket (No conformidades asignadas). Registro de No conformidades. Probador (Depende del requerimiento a evaluar) Aplicación para la Gestión de Pruebas no 5. Análisis de resultados Reportes de resultados de la aplicación. Funcionales. 6

10 El procedimiento general se trasformará en dependencia del requerimiento no funcional a evaluar. Derivarán de este procedimiento, los procedimientos específicos para la evaluación 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 varía la sucesión de pasos en el procedimiento específico. 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 obtención de los parámetros necesarios para el cálculo de las métricas que se proponen en la ISO para la evaluación de cada uno de estos requisitos, una vez obtenidos estos indicadores, para la ejecución de la actividad 5 Análisis de Resultados se utiliza la herramienta para la Gestión de Pruebas no Funcionales (implementada en el presente trabajo), donde se registran los parámetros necesarios para las métricas. En esta herramienta se van a mostrar los resultados de la evaluación 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 investigación y en este mismo artefacto se le propone una evaluación al producto que se está probando en cuanto a la usabilidad. A continuación se describe como varía en cada requisito a evaluar en el procedimiento las actividades 1 y 2, así como sus artefactos de entrada y salida Descripción 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 realización de pruebas no funcionales de un software educativo. Para realizar la primera actividad de dicho procedimiento general los artefactos de entrada son: Manual de instalación 7

11 Instalador de la aplicación. Para la ejecución de la prueba, que es la actividad 2 se desglosa en varias actividades para apoyar la ejecución de esta, tales como 2.1 Existe una versión de la aplicación? 2.2. Ejecutar la versión anterior Ejecutar la Aplicación que se está probando. Para la realización 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 Descripción 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 realización 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, validación, opciones que no funcionan. Para la actividad 2 se utilizan los artefactos de entrada de la actividad Descripción 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 realización de pruebas no funcionales de un software educativo. Para realizar la primera actividad de dicho procedimiento general los artefactos de entrada son: Diseño de casos de pruebas. Para la actividad 2 se utilizan los artefactos de entrada de la actividad 1. 8

12 Descripción 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 realización de pruebas no funcionales a un software educativo. Para realizar la actividad 1 de dicho procedimiento general los artefactos de entrada son: Diseño de casos de pruebas. Herramienta JMeter, para la ejecución de pruebas de carga y rendimiento. JMeter es una herramienta libre y escrita en Java, es la más completa y útil para realizar pruebas de carga y rendimiento, se le puede aplicar a cualquier tipo de aplicación 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: Diseño de caso de pruebas. Especificaciones complementarias. Plan de pruebas obtenido de JMeter. Una vez ejecutadas las pruebas en JMeter siguiendo la descripción detallada de las actividades se obtienen los reportes de resultados de esta, de los cuales se toman los parámetros necesarios para el cálculo de las métricas que se proponen en la ISO para evaluar el cumplimiento de la eficiencia (Ver Anexo 4) Descripción 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 realización 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

13 Para la actividad 2 se debe actualizar esta lista al verificar el cumplimiento de los indicadores a evaluar Herramienta para la Gestión de pruebas no funcionales La herramienta para la Gestión de pruebas no funcionales surge a partir de la necesidad de automatizar el cálculo de las métricas para evaluar los requerimientos no funcionales. Es una aplicación de escritorio, que permite la entrada de los datos necesarios para el cálculo de cada una de las métricas correspondientes a las características para la obtención 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 evalúan en la herramienta son: eficiencia, portabilidad, mantenimiento, fiabilidad. Estos requisitos son parte del procedimiento para realizar pruebas no funcionales de un software educativo Características y requerimientos técnicos La herramienta posee diferentes características como las que serán mostradas a continuación, al igual que los requerimientos técnicos que esta necesita para su funcionamiento. Características: Aplicación de Escritorio. Multiplataforma. Requerimientos técnicos: Sistema operativo: Windows, Linux. Licencia: GPL. Idioma: Español. Tamaño: 10.2 MB 10

14 Memoria RAM: Mínimo 128 MB. Lenguaje de Implementación: C++. IDE: Qt Creator Interfaz gráfica de la herramienta Figura 1. Interfaz Métricas para evaluar la portabilidad. Figura 2. Interfaz Mostrar Resultados. 11

15 2.3. Resultados Para validar los resultados de esta investigación se realizó un análisis estadístico 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 investigación, el trabajo con los especialistas no solo aportó valores cuantitativos sino que también brindó análisis de los resultados que hicieron madurar más la propuesta. Luego del análisis de resultados de la validación se obtuvo una alta probabilidad de éxitos de la propuesta. Posteriormente se aplicó el procedimiento descrito, con el uso de la herramienta para la Gestión 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 Informática Industrial (CEDIN), de la Universidad de las Ciencias Informáticas (UCI), obteniéndose parámetros que hasta el momento se pensaban buenos pero que por la aplicación del procedimiento se constató que aun debían 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 Gestión de Pruebas no Funcionales, herramienta desarrollada por las autoras de esta investigación, 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 teorías en el campo de pruebas no funcionales, los que facilitaron la comprensión 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

16 funcionales de un software educativo con ayuda de herramientas automatizadas como JMeter. La creación de la herramienta para la Gestión de Pruebas no Funcionales y su posterior uso permitió gestionar la evaluación de los requerimientos no funcionales de portabilidad, mantenimiento, fiabilidad y eficiencia y de esta forma apoyó la puesta en práctica 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 aceptación. REFERENCIAS 1. PRESSMAN, R. Ingeniería del Software. Un enfoque práctico. Edtion ed., IEEE Standard Glossary of Software Engineering Terminology. Edtion ed., ISO/IEC Edtion ed., ISO/IEC Edtion ed., GLENFORD J. MYERS, C. S., TOM BADGETT The Art of Software Testing. Edtion ed., IEEE SWEBOK. Guide to the Software Engineering Body of Knowledge. Edtion ed., ISBN ALEJANDRO OCAMPO ACOSTA, L. M. C. T. IMPACTO DE LAS PRUEBAS NO FUNCIONALES EN LA MEDICIÓN DE LA CALIDAD DEL PRODUCTO SOFTWARE DESARROLLADO. In., Comité Técnico y de Normalización NC/CTN 18 de Tecnologías de la Información. ISO/IEC Ingeniería de software. Calidad del producto. Parte 1: Modelo de la calidad.. Edtion ed. Ciudad de La Habana: Oficina Nacional de Normalización, AILYN FEBLES ESTRADA, T. C. G., YENISET LEÓN PERDOMO, ALIONUSKA VELÁZQUEZ CINTRA, RAMSÉS DELGADO MARTÍNEZ, ROIG CALZADILLA DÍAZ. Una experiencia novedosa para el testing desarrollada por un departamento de pruebas de software. In. Revista Cubana de Ciencias Informáticas. 13

17 10. SÁNCHEZ, E. R. V. Educatrónica: Innovación en el aprendizaje de las ciencias y la tecnología. edited by E.D.D. SANTOS. Edtion ed., ISBN ISBN , PROGRAMA DE MEJORA 0516_ROLES Y RESPONSABILIDADES. Universidad de las Ciencias Informáticas. 14

18 ANEXOS: Anexo 1. Métricas para la medición de la característica portabilidad. Nombre Definición Metas Procedimiento de análisis Facilidad instalación (Instalabilidad) Facilidad reintento ejecución instalador (Instalabilidad) de de de del Conformidad de la portabilidad Función de la inclusión. (Reemplazabilidad) X = A/B A = número de casos en los cuales el usuario tiene éxito en las operaciones para una instalación adecuada a su conveniencia. B = número total de casos en los cuales el usuario intenta adecuar la instalación a su conveniencia. X = A/B A = Número de casos en los cuales el usuario no tiene éxito al reintentar ejecutar el instalador. B = Número total de casos en los cuales el usuario reintenta ejecutar la instalación durante la operación de instalación. X = 1 - A/ B A = Número de elementos especificados que requiriendo estar en conformidad no han sido implementados durante las pruebas. B = Número total de elementos especificados que requieren estar en conformidad. X = A / B A = número de funciones que producen resultados similares como los previamente producidos y donde los cambios no han sido requeridos. B = número de funciones que son probadas similares a las funciones proporcionadas por otro software. Puede el usuario instalar fácilmente el producto de software en su ambiente de operación? Puede el usuario o Serviciador fácilmente reintentar ejecutar el programa instalador del software? Cuán conforme es la portabilidad del producto de software con las regulaciones, las normas y convenciones que les son aplicables? Puede el usuario o Mantenedor fácilmente continuar utilizando funciones similares después de la sustitución de este software a uno anterior? Es la migración del sistema de software un éxito? Observe el comportamiento del usuario cuando tratan de instalar el producto de software en su ambiente de operación 0 <= X <= 1 Más cercano al 1 resultará mejor. Observe el comportamiento del usuario o serviciador cuando tratan de reinstalar el producto de software. 0 <= X <= 1 Más cercano al 1 resultará mejor. 0 <= X <= 1 A mayor cercanía al 1 mejor. La observación del usuario o el comportamiento del mantenedor cuando el usuario está reemplazando un software con uno anterior? 0<= X <=1 Mientras mayor sea, mejor. Anexo 2. Métricas para la medición de la característica mantenimiento. Nombre Definición Metas Procedimiento de análisis Capacidad de análisis de fallos (Analizabilidad). X = 1- A / B A = Número de fallos cuyas causas aún no han sido encontradas. B = Número total de fallos registrados Se puede identificar la operación específica que causó el fracaso? Puede el personal de mantenimiento fácilmente encontrar la causa del fallo? Observar el comportamiento de los usuarios o el personal de mantenimiento responsable de resolver los fallos. 0 <= X <= 1 Mientras más cercano al 1, mejor. 15

19 Tiempo empleado en (Tout Tin) / N Puede el personal de Observar el comportamiento del implementar un Tout = Tiempo promedio en que se mantenimiento realizar usuario y el personal de cambio por el resuelven los fallos. fácilmente cambios al mantenimiento al tratar de personal 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 = Número de fallos registrados y de resolución de problemas o el eliminados. informe de mantenimiento. 0 < Tp. Entre más se acerque a cero mejor. Fallos encontrados X = Na/Ta Puede el usuario operar Observar el comportamiento del después del cambio. Na = Número de casos en los que el el sistema de software sin usuario o mantenedor del sistema (Estabilidad) usuario encuentra errores durante la fallos después de su de software después de su operación después que el software fue mantenimiento? mantenimiento. cambiado. El mantenedor puede 0<=X Ta = El tiempo de funcionamiento fácilmente reducir las Cuanto más pequeño y cercano a durante el período de observación averías causadas por los 0 es mejor. contemplado después que el software efectos secundarios de es cambiado. mantenimiento? Pruebas sin X = Sum(T)/N Puede el usuario y el Observar el comportamiento del esfuerzo. T = Tiempo empleado en probar con el mantenedor fácilmente usuario o el mantenedor, quienes (Facilidad de prueba) fin de asegurar si el informe de fallo ha realizar pruebas de están probando el sistema sido o no resuelto. funcionamiento y después del mantenimiento. N = Números de fallos resueltos determinar si el software 0<X Cuanto más cercano a cero está listo para funcionar o mejor. no? Anexo 3. Métricas para la medición de la característica fiabilidad. Nombre Definición Metas Procedimiento de análisis Madurez (Prueba de Madurez). Tolerancia fallos Desglose) ante (Evitar X=A/B A = Número de casos de prueba que han pasado realmente ejecutados. B = Número de casos de prueba que se realizan según los requisitos. X=1-A/B A = Número de averías B = Número de fallos. Es el producto de pruebas de pozos? Este comentario es para predecir la tasa de éxito que el producto alcanzará en la prueba en el futuro. Con qué frecuencia el producto de software hace qué el desglose del entorno de producción total falle? Observar la cantidad de casos de prueba que fueron realmente ejecutados y comparando con el número total de pruebas que deberían realizarse según los requisitos. 0 <= X<=1, el más cercano a 1.0 es la mejor Probar la madurez teniendo éxito en contar el número de averías con respecto al número de fallos. 0 <= X<=1, el más cercano a 1.0 es la mejor. 16

20 Tolerancia ante X = A/B Cómo muchas de las Probar la madurez logrando fallos (Evitar un A = Número de ocurrencias que evitan funciones se implementan con expresar el número de casos funcionamiento fallos críticos y graves la capacidad de evitar de prueba que tuvieron un incorrecto) B = Número de casos de prueba operaciones incorrectas? funcionamiento incorrecto que ejecutados de los patrones de evitaron causar fallos críticos funcionamiento incorrecto (fallos casi y compararlo con el número causa) durante la prueba. de casos de prueba ejecutados de los patrones de funcionamiento incorrecto. 0 <= X<=1, el más cercano a 1.0 es mejor debido a que se evita una operación más de usuario incorrecto. Recuperabilidad. X= { To / (To+Tr) } Cómo se encuentra Se mide el período de tiempo (Disponibilidad) Y= A1/A2 To = Operación de tiempo Tr = tiempo de reparación A1 = Total de casos de uso a disposición del usuario de software de éxito. A2 = Total de casos de intento de usuario para utilizar el software durante la medición del tiempo. disponible el sistema para su uso durante el período de tiempo especificado? de reparación cada vez que el sistema no está disponible. 0 <= X<=1, el más grande y más cercano a 1.0 es mejor que el usuario puede utilizar el software para obtener más tiempo. 0 <= Y<=1, el más grande y más cercano a 1.0 es la mejor. Valor de una sub-característica específica Descripción. Definición. El objetivo de esta métrica es conocer el valor de la subcaracterística debido a que hay varios casos donde existe más de una métrica para la misma sub-característica, se pretende con esto conocer un único valor. Vsub = Valor de la sub-característica. CmSub = Valor obtenido después de haber realizado el cálculo de la métrica para esa sub-característica CM = Cantidad de métricas de la sub-característica. Por ciento de Fiabilidad Descripción. Definición. Con esta métrica se calcula el por ciento de Fiabilidad de un componente con respecto a las sub-características escogidas esta fórmula depende del resultado anterior calculado de la fórmula. Pfi = Por ciento Fiabilidad. VSub = Valor de la sub-característica. CSub = Cantidad de sub-características. Nivel de Fiabilidad Nivel Intervalo Porciento Final Alto 0.8 X 1 80% % Medio 0.5 X < %----79% Bajo X < 0.5 Menor o igual que 49% 17

21 Anexo 4. Métricas para la medición de la característica eficiencia. Nombre Definición Metas Procedimiento Tiempo de respuesta T = Tiempo empleado en obtener el resultado. Cuánto tiempo toma completar una tarea en particular? Cuánto toma antes de que el Comience una tarea específica. Mida el tiempo que esta toma en completar una muestra hasta que concluya la operación sistema responda a una emprendida. Guarde los registros de cada determinada operación? intento. 0 < T a mayor prontitud (menor tiempo) resultará mejor. Tiempo de espera X = Ta/Tb Ta = Tiempo total dedicado Qué proporción del tiempo los usuarios dedican a esperar por Ejecutar los casos de pruebas en situaciones características y tareas a esperar. una respuesta del sistema? concurrentes. Mida el tiempo que toma 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 situación. 0 <= X Cuanto menor resultará mejor. Relación entre los X = A/T Cuántos errores de memoria Calibre las condiciones de prueba. Emule errores de A = Número de mensajes fueron identificados durante el una condición en que el sistema haya memoria y el de alerta o fallos del período de tiempo especificado, alcanzado un máximo de carga. Ejecute la tiempo (Utilización sistema. y con una utilización de aplicación y registre el número de errores de recursos). T = Tiempo de operación recursos especificada? debido a fallos de memoria. del usuario. 0 < X Más pequeña, mejor. Anexo 5. Resumen de los elementos más importantes de la plantilla Lista de chequeos de usabilidad 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 técnicos en la verificación y evaluación de las especificaciones de usabilidad del software. Recogerá los puntos eficientes e ineficientes que tienen los elementos chequeados Alcance. Esta planilla es aplicable a cada una de las revisiones de especificaciones de usabilidad del software educativo que se desarrolle Definiciones y acrónimos. Peso: Define si el indicador a evaluar es crítico o no. Evaluación (Eval): Es la forma de evaluar el indicador en cuestión. Este se evalúa 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 señalamientos o sugerencias que quiera incluir la persona que aplica la lista de chequeos. 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 IEEE Standard

22 4. Estructura de la lista de chequeo. Pantalla de Bienvenida Peso Indicador a evaluar Eval (NP) Cantidad de elementos afectados El software presenta un identificador visual? Presenta la versión del producto? Presenta la entidad que desarrolla el producto? Presenta la información de soporte: información de los teléfonos, correos, equipo de soporte? Presenta la pertenencia legal del producto: Especificación de la propiedad intelectual y comercial del producto? La página de bienvenida está diseñada profesionalmente y va a crear una primera impresión positiva? Minimizar carga de usuarios Crítico Está el sistema libre de información irrelevante e innecesaria? Crítico En la interfaz se utiliza el lenguaje de los usuarios y no uno propio relacionado con la tecnología? Crítico Son pocos los pasos que el usuario tiene que efectuar para realizar una acción específica? Crítico Entiende bien el usuario lo que tiene que hacer? 5. Evaluación. Se aborta la revisión del software evaluado si: Existen al menos dos indicadores críticos evaluados de mal. Existen más de una falta de ortografía en pantalla. Incumple más del 50% de los indicadores a evaluar de la sección Estructura de la lista de chequeo. Se mantienen las No Conformidades de una revisión a otra. Se evalúa de regular la calidad usabilidad del software revisado si no cumple los criterios para ser abortado y: Existe una No Conformidad crítica. 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 crítico. Si la cantidad de elementos afectados de un indicador que no sea crítico no es mayor que 2. Evaluación: Nombre y apellidos del evaluador: Comentarios 19