Elaboración y ejecución de un plan de pruebas de usabilidad para juego educativo Crossroads 2.0

Universidad de Valladolid Máster universitario Ingeniería Informática Trabajo Fin de Máster Elaboración y ejecución de un plan de pruebas de usabilidad para juego educativo Crossroads 2.0. Realizado por María Galindo Gómez z z z Universidad de Valladolid 16 de septiembre de 2021 Tutor: Yania Crespo González-Carvajal y David Escudero Mancebo Resumen Crossroads 2.0 es una aplicación desarrollada dentro del proyecto H2020 Locomotion [ 62 ] que cuenta en la actualidad con una versión alfa ,la cual permite jugar partidas y visualizar los resultados obtenidos. La aplicación pretende concienciar sobre las posibles consecuencias que pueden traer consigo la toma de decisiones políticas asociadas a clima y economía respecto al cambio climático, respondiendo a una serie de cuestiones y debatiendo acerca de las diferentes opciones disponibles. El objetivo del proyecto consiste en la definición y ejecución de un plan de pruebas contemplando tanto sesiones ya acontecidas como pruebas a realizar en un futuro. La finalidad que persigue la realización de dichas sesiones es poder documentar tanto los aspectos cuya implementación ha resultado ser adecuada como aquellos que requieran mejoras futuras. Se investigó sobre las diferentes dimensiones de usabilidad, así como conceptos de jugabilidad y elementos de los videojuegos para poder definir los aspectos a evaluar en la aplicación, elaborando y ejecutando el plan de pruebas correspondiente. En una primera sesión se mostró el prototipo de la aplicación, además de llevarse a cabo pruebas de estabilidad, robustez, compatibilidad y obtención de retroalimentación por parte de expertos. Además de planificar pruebas futuras con estudiantes. Las pruebas realizadas sirvieron para comprobar que las funcionalidades de la aplicación se ejecutan correctamente, así como detectar inconvenientes no contemplados con anterioridad relacionados con cuestiones como rendimiento y diseño de interfaces. La sesión con investigadores del equipo GEEDS también permitió obtener retroalimentación procedente de expertos acerca de aspectos como información e interacción que se tendrá en cuenta en implementaciones futuras. El trabajo realizado ha contribuido en el proyecto en términos de desarrollo, prueba de funcionalidades, obtención de retroalimentación y detección de inconvenientes no considerados. La aplicación actual incluye todo lo necesario para jugar una partida, pudiendo dar cabida a versiones futuras donde se incluyan mejoras como ayudas, aunque es conveniente considerar determinadas cuestiones de rendimiento y diseño que influyen en la utilización de Crossroads. Descriptores Locomotion, cambio climático, Crossroads, pruebas usabilidad, serious game, jugabilidad, gamificación I Abstract Crossroads 2.0 is an application which was developed within the H2020 Locomotion [ 62 ] project that currently has an alpha version, which allows you to play games and visualize results. The application aims to raise awareness about the possible consequences that political decision-making associated with climate and economics can bring about climate change, answering a series of questions and discussing the different available options. The objective of the project is to define a test plan considering both sessions that have already taken place and tests to be carried out in the future. The purpose of these sessions is to be able to document both the aspects whose implementation has proven to be adequate and those that require future improvements. We proceeded to investigate the different usability dimensions, as well as concepts of gameplay and elements of video games in order to define the aspects to be evaluated in the application, developing and executing the corresponding test plan. In a first session the prototype of the application was shown, in addition to tests of stability, robustness, compatibility and obtaining feedback from experts. In addition to planning future tests with students. The tests were useful to verify that the functionalities of the application are executed correctly, as well as to detect inconveniences not previously contemplated related to issues such as performance and interface design. The session with researchers from the GEEDS team also allowed to obtain feedback from experts on aspects such as information and interaction that will be taken into account in future implementations. This work has contributed to the project in terms of development, testing of functionalities, obtaining feedback and detection of inconveniences not considered. The current application includes everything you need to play a game, and can accommodate future versions that include enhancements such as aids, although it is convenient to consider certain performance and design issues that influence the use of Crossroads. Keywords Locomotion, climate change, Crossroads, tests, usability, serious game, playability, gamification II Índice general Índice general III Índice de figuras VII Índice de tablas VIII 1. Introducción 1 1.1. Motivación .................................... 3 1.2. Visión panorámica ............................... 4 1.3. Objetivos del proyecto ............................. 5 2. Marco conceptual y estado del arte 6 2.1. Evaluación de usabilidad ............................ 6 Dimensiones de análisis ............................. 6 Instrumentos de prueba ............................ 15 Sesiones de prueba ............................... 15 2.2. Juegos educativos, serious games y gamificación ............... 18 2.3. Evaluación de usabilidad en serious games .................. 18 Métodos e intrumentos para pruebas de usabilidad ......... 19 Medición de usabilidad en serious games ............... 20 Metodología general para evaluaciones de usabilidad en serious games 21 Proceso de evaluación ......................... 22 2.4. Trabajos relacionados .............................. 23 Videojuegos relacionados con el cambio climático .............. 23 Selección de criterios y realización de evaluaciones .............. 26 3. El videojuego Crossroads 2.0 28 3.1. Elementos formales ............................... 35 Jugadores .................................... 35 Invitación a jugar ................................ 37 III ÍNDICE GENERAL Cantidad de jugadores ............................. 37 Roles ....................................... 38 Patrones de interacción de jugadores ..................... 38 Objetivos del juego ............................... 39 Procedimientos ................................. 40 Recursos ..................................... 41 Conflictos .................................... 42 Límites ...................................... 43 3.2. Elementos dramáticos ............................. 43 Naturaleza del juego .............................. 44 Premisa ..................................... 45 Personajes .................................... 45 Historia ..................................... 46 4. Plan de pruebas 47 4.1. Presentación de mockups a usuarios en focus group ............. 47 A.-Objetivo: .................................. 47 B.-Responsables ................................. 47 C.- Recursos e instrumentos de evaluación .................. 47 D.- Informantes ................................. 48 E.- Protocolo y tareas ............................. 48 4.2. Pruebas de robustez .............................. 48 A.-Objetivo ................................... 48 B.-Responsables ................................. 48 C.-Recursos e instrumentos de evaluación ................... 48 D.-Informantes ................................. 49 E.-Protocolo y tareas .............................. 49 4.3. Pruebas de compatibilidad ........................... 58 A.-Objetivo ................................... 58 B.-Responsables ................................. 58 C.-Recursos e instrumentos de evaluación ................... 58 D.-Informantes ................................. 59 E.-Protocolo y tareas .............................. 59 4.4. Pruebas de estabilidad ............................. 68 A.-Objetivo ................................... 68 B.-Responsables ................................. 68 C.- Recursos e instrumentos de evaluación .................. 68 D.-Informantes ................................. 69 E.-Protocolo y tareas .............................. 69 4.5. Pruebas con usuarios finales .......................... 83 Sesión de pruebas con investigadores del equipo GEEDS .......... 83 A.-Objetivo ................................... 83 B.-Responsables ................................. 83 C.-Recursos e instrumentos de evaluación ................... 84 IV ÍNDICE GENERAL D.-Informantes ................................. 87 E.-Protocolo y tareas ............................. 87 Sesiones de pruebas con estudiantes de ingeniería que se realizarán en un futuro .................................. 88 A.-Objetivo ................................... 88 B.-Responsables ................................. 88 C.-Recursos e intrumentos de evaluación ................... 88 D.-Informantes ................................. 91 E.-Protocolo y tareas .............................. 91 5. Resultados 93 5.1. Presentación de mockups a usuarios en focus group ............. 93 Desarrollo .................................... 93 Observaciones y resultados ........................... 93 Recomendaciones ................................101 5.2. Pruebas de robustez ..............................102 Desarrollo ....................................102 Observaciones y resultados ...........................103 Recomendaciones ................................104 5.3. Pruebas de compatibilidad ...........................104 Desarrollo ....................................104 Observaciones y resultados ...........................105 Recomendaciones ................................105 5.4. Pruebas de estabilidad .............................105 Desarrollo ....................................106 Observaciones y resultados ...........................106 Recomendaciones ................................108 5.5. Pruebas con usuarios finales ..........................109 Desarrollo ....................................109 Observaciones y resultados ...........................110 Tiempos registrados ..............................117 Recomendaciones ................................121 6. Conclusiones y Líneas de trabajo futuras 124 Apéndices 127 Apéndice A Plan de Proyecto 128 A.1. Introducción ...................................128 A.2. Planificación temporal .............................128 A.3. Estudio de viabilidad ..............................130 Viabilidad económica ..............................130 Viabilidad legal .................................135 V ÍNDICE GENERAL Bibliografía 147 VI Índice de figuras 1.1. Desarrollo de la versión alfa de Crossroads 2.0 .................. 2 1.2. Funcionamiento de Crossroads 2.0 ......................... 4 2.3. Estructura de cuestionario SUS .......................... 20 3.4. Pantalla inicial para moderadores ......................... 28 3.5. Formulario para crear sala (1) y pantalla de espera para el moderador (2) . . . 29 3.6. Formulario introducir un código (1), formulario para registrar a un jugador (2) y pantalla de cinemática inicial .......................... 30 3.7. Pantalla que permite a un jugador unirse a un grupo .............. 31 3.8. Pantalla de Dashboard ............................... 31 3.9. Pantalla donde figura cada cuestión junto con el chat .............. 32 3.10. Matriz de respuestas y pantalla para resolución de conflictos .......... 33 3.11. Pantalla de resultados asociados a una ronda ................... 34 3.12. Pantalla de resultados finales asociados a una partida .............. 35 4.13. Línea del tiempo elaborada a partir de las actividades realizadas durante la sesión del 4 de junio. En rojo se marca el tiempo dedicado a actividades de explicación, el color azul se corresponde con las actividades de preparación y las tonalidades beige reflejan el trabajo en grupo (todo expresado en minutos) 91 5.14. Actividad principal y rango de edad asociado a los encuestados ........ 94 5.15. Experiencia en temática de juego y juegos online multijugador para cada encuestado ...................................... 95 5.16. Género de las personas encuestadas ........................ 96 5.17. Errores asociados al registro de moderador ....................103 5.18. Línea del tiempo asociada a la sesión con el equipo GEEDS (tiempos expresados en minutos) .....................................120 A.1. Planificación temporal ...............................128 A.2. Costes directos de personal .............................132 VII Índice de tablas 4.1. Descripción de la tarea Tolerancia a errores en registro ............. 50 4.2. Descripción de la tarea Tolerancia a errores en Inicio de sesión ......... 51 4.3. Descripción de la tarea Tolerancia a errores en creación de sala ......... 51 4.4. Descripción de la tarea Tolerancia a errores en inicio de partida ........ 52 4.5. Descripción de la tarea Tolerancia a errores en inicio de nueva ronda ..... 53 4.6. Descripción de la tarea Tolerancia a errores en finalización de partida ..... 53 4.7. Descripción de la tarea Tolerancia a errores al unirse a una sala ........ 54 4.8. Descripción de la tarea Tolerancia a errores al realizar el registro de un jugador 55 4.9. Descripción de la tarea Tolerancia a errores al unirse a un grupo ........ 56 4.10. Descripción de la tarea Tolerancia a errores al responder una cuestión . . . . 57 4.11. Descripción de la tarea Tolerancia a errores al enviar un mensaje ....... 57 4.12. Descripción de la tarea Creación de sala ..................... 61 4.13. Descripción de la tarea Inicio de partida ..................... 62 4.14. Descripción de la tarea Monitorización de estado ................ 62 4.15. Descripción de la tarea Inicio de nueva ronda .................. 63 4.16. Descripción de la tarea Finalización de partida .................. 64 4.17. Descripción de la tarea Descargar PDF ...................... 64 4.18. Descripción de la tarea Unirse a una sala ..................... 65 4.19. Descripción de la tarea Registrar jugador ..................... 65 4.20. Descripción de la tarea Responder cuestión .................... 66 4.21. Descripción de la tarea Enviar mensaje ...................... 67 4.22. Descripción de la tarea Resolución de conflictos ................. 68 4.23. Descripción de la tarea Creación de sala ..................... 71 4.24. Descripción de la tarea Inicio de partida ..................... 72 4.25. Descripción de la tarea Monitorización de estado ................ 72 4.26. Descripción de la tarea Inicio de nueva ronda .................. 73 4.27. Descripción de la tarea Finalización de partida .................. 74 4.28. Descripción de la tarea Descargar PDF ...................... 74 4.29. Descripción de la tarea Unirse a una sala ..................... 75 4.30. Descripción de la tarea Registrar jugador ..................... 76 VIII 2: Marco conceptual y estado del arte Para evaluar la usabilidad de la herramienta Crossroads 2.0, se analizan tanto las dimensiones de usabilidad a probar, los instrumentos de prueba a utilizar y las sesiones de evaluación realizadas. En el presente apartado, se presentan conceptos básicos relacionados con la evaluación de usabilidad, además de hacer mención a estudios que se han encargado de realizar diversas pruebas asociadas a la evaluación de determinadas aplicaciones y/o selección de posibles criterios, así como hablar sobre videojuegos que persiguen fines similares. 2.1. Evaluación de usabilidad Dimensiones de análisis La primera cuestión que surge es determinar a qué hace referencia exactamente el término “usabilidad”. Para poder responder a dicho interrogante, conviene tener presentes las cinco dimensiones de usabilidad recogidas por Quesenbery [ 89 ], describiendo cada una de ellas un aspecto relevante asociado a la experiencia de cada usuario. Dichas dimensiones se recogen a continuación: Eficacia: Mide el grado en el que el producto en cuestión satisface los objetivos de los usuarios. Se trata de un aspecto especialmente relevante cuando existen tareas que implican un amplio elenco de elecciones o bien que no pueden ser satisfechas completamente por el producto a desarrollar. Las diferentes metas pueden variar en función del contexto [88]: • Los usuarios de un sitio web que actúa como un repositorio pueden necesitar todos los documentos relevantes sobre un tema determinado, siendo muy importante la completitud de la búsqueda. • Un usuario tal vez necesite completar un formulario para realizar un pedido de forma inmediata. En ese caso, será necesario comprobar que todos los campos sean correctos y la información incluida no debe presentar ambigüedades. 6 2.1. EVALUACIÓN DE USABILIDAD Marco conceptual y estado del arte • Un sistema de soporte debe proporcionar la información necesaria para continuar trabajando de forma que su tarea se vea lo menos interrumpida posible. La eficacia requiere una comprensión de las metas que persiga el sistema correspondiente, así como la flexibilidad necesaria para alcanzarlos. En el caso de la aplicación Crossroads 2.0, la efectividad puede medirse analizando si el juego posibilita la comprensión de diferentes conceptos, como la relación existente entre la energía consumida, la sociedad y el clima, así como el fomento a la elaboración y discusión de estrategias para controlar diversos aspectos que pueden ejercer una notable influencia en futuros valores de PIB y/o temperatura . Eficiencia: Mide la velocidad con la que los usuarios completan cada tarea. De acuerdo con la norma ISO 9241 [ 7 ] el concepto “eficiencia” hace referencia al total de recursos empleados para completar una tarea de forma efectiva. Dichos recursos abarcan la cantidad de acciones que debe realizar un usuario y el tiempo invertido en cada una. Para realizar la medición de la eficiencia conviene tener presente cómo perciben los usuarios cada una de las diferentes tareas a realizar, en especial cuando existen tareas con múltiples funcionalidades o bien que no puedan ser completadas en su totalidad solamente utilizando el producto en cuestión. Volviendo al ejemplo de soporte para usuarios expuesto a la hora de hablar sobre eficiencia [ 88 ]. Este tipo de sistemas cuentan con requisitos de eficiencia, ya que el intervalo de tiempo en el que la ayuda interrumpe a cada usuario haciendo que dejen de realizar momentáneamente sus tareas ha de ser el menor posible. Por otro lado, otro aspecto que influye en la eficiencia es la claridad de los mensajes, ya que, si se emplean términos con los que no se hayan familiarizado los usuarios se incrementa el tiempo empleado en realizar tareas, influyendo negativamente en la eficiencia. En lo que respecta a Crossroads 2.0, es necesario medir la eficiencia analizando el rendimiento de la aplicación. Esto equivale a comparar los tiempos aproximados necesarios para completar las diferentes tareas en la aplicación con los de la actividad educativa expuesta en el apartado 1.1. Engaging: Mide la percepción de la aplicación por parte de los usuarios, es decir, si se sienten cómodos con el sistema y estarían dispuestos a seguir utilizándolo. Se trata de la dimensión más subjetiva, la cual no solo incluye la presentación estética de la interfaz, sino que también considera aspectos como el lenguaje empleado y la organización de la información [ 88 ]. Este último concepto hace referencia a la forma de comunicar la información a cada usuario e influye de forma importante en la presencia de esta dimensión. A modo de ejemplo, una tabla de contenidos debe ser presentada de forma que resulte sencillo entenderla, o bien, en el caso de manejar resultados complejos, estos deben presentarse de modo que puedan ser comprensibles para cualquier persona que utilice el sistema. 7 2.1. EVALUACIÓN DE USABILIDAD Marco conceptual y estado del arte En el caso de Crossroads 2.0 esta dimensión puede medirse examinando registros de actividad, además de guardar relación con la eficacia, puesto que se debe prestar atención a la exposición de aspectos como las cuestiones que deben contestar los jugadores en cada partida, así como a la forma de mostrar los resultados finales en pantalla. La dimensión en cuestión también se encuentra ligada a la eficiencia, en especial si se atiende al diseño de interfaces y lenguaje utilizado, ya que son factores que influyen en gran medida a la hora de completar tareas. Tolerancia a errores: Mide la capacidad del sistema para poder recuperarse en el caso de producirse algún error, ya sea debido a temas de programación, mala comprensión del modelo mental del usuario, o bien, simplemente errores cometidos por los usuarios. La aparición de errores puede deberse a cualquiera de los factores expuestos a continuación [88]: • Existencia de defectos en el código o determinadas condiciones no contempladas que influyen negativamente en la ejecución de la aplicación. • Entendimiento incorrecto por parte de los diseñadores del modelo mental asociado al usuario, de forma que se haya implementado una interfaz que no sea lo suficientemente intuitiva. •Podría tratarse simplemente de un error cometido por el usuario. Un sistema tolerante a errores ha de permitir al usuario recuperar el estado anterior del sistema cuando se produce un error proporcionando la información adecuada para resolver el problema correspondiente. El sistema debe adaptarse a errores producidos por accidentes, malas interpretaciones o desviaciones de otra índole. Con frecuencia, los defectos derivan de no contemplar posibles interacciones de usuarios con el sistema (o contemplarlas incorrectamente). Las medidas adecuadas para aplicar la tolerancia a fallos en estos casos son [88]: • Los errores relacionados con falta de información o datos en un formato no considerado con anterioridad deben considerarse parte de un proceso, además de incorporar su corrección a la interfaz en lugar de tratarlos como excepciones en un subsistema independiente. Es necesario que la dificultad a la hora de realizar acciones no válidas sea la mayor posible. Para lograr este objetivo conviene incluir listados donde figuren actividades las elecciones correctas, además de proporcionar ejemplos de entrada y deshabilitar determinadas opciones cuando no se utilicen. Por último, es importante tener en cuenta los errores que se deban a acciones realizadas por el propio usuarios, siendo algunos ejemplos los mostrados a continuación: [88]: 8 2.1. EVALUACIÓN DE USABILIDAD Marco conceptual y estado del arte • Fallo a la hora de seleccionar una determinada opción, eligiendo una diferente a la que pretendía en un inicio. El problema en cuestión puede deberse a la ausencia de información necesaria. Resolver estos problemas implica hacer que las acciones realizadas sean reversibles, incluyendo las funcionalidades necesarias para permitir el retroceso. • También existen situaciones de ambigüedad en las que se pueda confundir el significado de las diferentes opciones influyendo negativamente en la eficacia. En lo que respecta a Crossroads 2.0, la inclusión de tolerancia a fallos implica no permitir situaciones como dejar preguntas sin responder o enviar formularios sin rellenar mostrando los mensajes adecuados informando del error correspondiente. Además, es importante que el sistema pueda recuperarse ante errores como el cierre no intencionado del navegador durante una partida. Facilidad de aprendizaje: Requisito utilizado para determinar si la aplicación es intuitiva y, por lo general fácil de utilizar para cualquier posible usuario final. Una aplicación en la que destaque la facilidad de aprendizaje debe permitir la adquisición de conocimientos sin necesidad de realizar un gran esfuerzo. La facilidad de aprendizaje implica instrucciones adecuadas, ejemplos y pistas que proporcionen información, de forma que su interfaz sea intuitiva y consistente. Por un lado, la intuitividad implica ubicar los elementos en la localización esperada por los usuarios, además de poder aplicar conocimientos derivados del empleo de aplicaciones similares, utilizando patrones de interacción conocidos. En lo que respecta a consistencia, dicho concepto hace referencia al hecho de que la información nuca experimenta variaciones, además de implicar el comportamiento adecuado de funciones. En el caso de Crossroads 2.0, la facilidad de aprendizaje puede aplicarse a la ubicación de cuestiones, chats, así como diferentes elementos relacionados con tablas y resultados, además de tener en cuenta la información expuesta en la cinemática inicial y futuras ayudas que se incluirán. Tal y como se ha mencionado en la documentación, Crossroads2.0 es un juego educativo cuyo fin es concienciar a los usuarios sobre el cambio climático, motivo por el cual, también conviene tener presente un concepto bastante ligado a los anteriores : La jugabilidad. El término “jugabilidad” hace referencia al grado de calidad asociado a un videojuego, en términos de mecánicas, reglas, diseño y objetivos [ 109 ]. Se trata, pues, de un concepto ligado a la facilidad de aprendizaje, al implicar un diseño intuitivo que permita utilizarlo sin recurrir a un manual,así como engagement (si se hace referencia al grado de diversión, atractivo que ofrece el juego e incluso frustración que puede generar en los usuarios). A la jugabilidad se le asocia una serie de atributos que se asemejan a las dimensiones de análisis expuestas a lo largo del apartado. Concretamente, dichas dimensiones son [109]: 9 2.1. EVALUACIÓN DE USABILIDAD Marco conceptual y estado del arte Satisfacción: Gratificación derivada de jugar a un videojuego o de algún aspecto relacionado con él. La satisfacción se caracteriza a través de las siguientes propiedades: •Diversión: Uno de los objetivos principales de un videojuego es entretener, de modo que un juego incapaz de entretener jamás podrá satisfacer a los jugadores. •Decepción: Es muy importante asegurarse de que los jugadores no se sientan decepcionados y acaben abandonando el juego por aspectos como dificultad o facilidad excesiva. •Atractivo: Aspectos del videojuego que incrementan el grado de satisfacción de un usuario. La satisfacción puede ligarse con la dimensión engaging, al tratarse de un atributo subjetivo basado en la percepción del videojuego por parte de usuarios, abarcando su grado de comodidad y el hecho de estar dispuestos a continuar jugando, dependiendo los tres factores expuestos de aspectos como la consistencia e intuitividad, además de la presentación estética asociada a la interfaz (concretamente formando parte del atractivo del juego). Capacidad de aprendizaje: Se trata de la capacidad del jugador para comprender y dominar el videojuego y sus mecánicas (reglas, objetivos, formas de interaccionar con el juego, etc). La capacidad de aprendizaje sigue las características reflejadas a continuación: •Conocimiento del juego: El grado de conocimiento asociado a un determinado juego influirá en el efecto ejercido en el jugador por la curva de aprendizaje del videojuego en cuestión. •Habilidad: Se refleja en la forma de jugar (comprensión de los objetivos del juego, forma de superar desafíos para obtener recompensas, entre otros). •Dificultad: Puede ser baja o elevada, en función de la curva de aprendizaje, las habilidades del jugador y el tiempo que haya estado jugando. Un nivel de dificultad alto equivale a un mayor esfuerzo de aprendizaje por parte del jugador. •Frustración: Se trata de una característica vinculada a los sentimientos del usuario durante el proceso de aprendizaje cuando es incapaz de superar un determinado desafío o no ha comprendido algunos conceptos del juego. •Velocidad: La velocidad en la que se introducen los conceptos y contenidos del juego afecta directamente al proceso de aprendizaje. •Descubrimiento: Los diferentes recursos que se encuentran en un videojuego favorecen una mejor asimilación de sus contenidos, de modo que el tiempo necesario para que el jugador mejore sus habilidades y alcance determinados objetivos del juego sea menor. 10 2.1. EVALUACIÓN DE USABILIDAD Marco conceptual y estado del arte La capacidad de aprendizaje puede ligarse a la dimensión que Quesenbery [ 89 ] denomina ”facilidad de aprendizaje”, puesto que incluye características que determinan si una aplicación es lo suficientemente consistente e intuitiva para considerarse fácil de utilizar, solo que la información relativa a capacidad de aprendizaje se centra en el ámbito de los videojuegos teniendo en cuenta las características propias de los mismos presentadas en el apartado, concluyendo que un videojuego capaz de favorecer la capacidad de aprendizaje es aquel que presente de forma apropiada y en el momento adecuado los conceptos y contenidos correspondientes favoreciendo la comprensión de los mismos, así como la adquisición de la habilidad y el conocimiento necesario, además de contar con un grado de dificultad lo suficientemente aceptable para que no resulte frustrante ni aburrido (aunque este aspecto en ocasiones puede ser bastante subjetivo). Eficacia: Característica que comparte su nombre con una de las dimensiones establecidas por Quesenbery [ 89 ], haciendo referencia al tiempo y recursos necesarios para proporcionar diversión a los jugadores conforme van alcanzando los diferentes objetivos de un juego. A la hora de hablar sobre eficacia en videojuegos, es importante tener presentes las siguientes propiedades: •Complementariedad: Un juego en el que resalte la eficacia no debe contar en ningún momento con contenido que el jugador no considere interesante. •Estructura: Se dice que un juego está bien estructurado cuando existe un equilibrio entre los objetivos que se desea alcanzar y los desafíos a superar, de forma que el jugador disfrute durante todo el tiempo de juego. La dimensión que Quesenbery [ 89 ] denomina “eficacia” hace referencia al grado en el que un determinado producto satisface los objetivos de usuarios, existiendo un vínculo con la eficacia relativa a jugabilidad, ya que un objetivo principal que ha de perseguir todo videojuego es incluir los elementos necesarios para poder entretener a los usuarios y así favorecer la utilización del software en gran medida. Las características que definen la eficacia en videojuegos también pueden relacionarse con la dimensión engaging, puesto que, si un usuario considera un videojuego lo suficientemente interesante y entretenido lo utilizará con mayor frecuencia, aparte de recomendarlo a otros posibles jugadores. Ya se ha comentado en el presente apartado que Crossroads 2.0 pone especial énfasis en la eficacia, puesto que es fundamental para los jugadores comprender cada una de las decisiones tomadas y los efectos que podría causar su aplicación en aspectos relacionados con el cambio climático realizando una interpretación apropiada de los resultados expuestos al final de cada ronda y partida. No obstante, en un videojuego educativo la diversión también es un factor clave que favorece el alcance del objetivo principal (en este caso adquirir los conocimientos especificados y percibir la necesidad de trabajar para lograr un futuro más sostenible) y la comprensión de los conceptos correspondientes, siendo necesario considerarlo en el diseño e implementación de la 11 2.1. EVALUACIÓN DE USABILIDAD Marco conceptual y estado del arte aplicación en cuestión (aunque en ocasiones no sea sencillo, ya que puede tratarse de un aspecto subjetivo). Inmersión: En videojuegos, el término “inmersión” hace referencia al grado de credibilidad de los contenidos incluidos, de forma que los jugadores puedan sentirse directamente implicados en el “mundo virtual”. El concepto cuenta con los siguientes atributos asociados: •Consciencia: Grado en el que el jugador es consciente de las consecuencias derivadas de sus acciones en el mundo virtual. •Absorción: Grado en el que el jugador se encuentra implicado en el videojuego. Las situaciones en las que dicho atributo resalta son descritas con precisión en la siguiente frase de Mihaly Csikszentmihalyi: “Las personas se sienten tan implicadas en lo que están haciendo que la actividad se vuelve espontánea, casi automática. Dejan de ser conscientes de sí mismos como entidades separadas de la acción que están realizando” [73]. •Realismo: El grado de inmersión se incrementa conforme exista más realismo y situaciones creíbles dentro del universo del videojuego (contenido, utilización de controles y atmósfera),siendo una situación beneficiosa para el usuario, ya que favorece su entendimiento de objetivos y reglas del videojuego incitando al desarrollo de habilidades necesarias para superar los diferentes desafíos que se presenten. •Destreza: Habilidad del jugador para interactuar con los controles del juego y llevar a cabo diferentes acciones en el mundo virtual. •Proximidad: Otro factor clave en el tema de inmersión es la presencia de características socio-culturales con las que los usuarios puedan sentirse identificados. De nuevo, se habla de una característica ligada a la eficacia, facilidad de aprendizaje y engaging, puesto que, lograr que un jugador se sumerja en el “mundo del videojuego” favorece su nivel de comprensión relacionado con el contenido y los diferentes conceptos clave del juego, así como la adquisición de habilidades y el hecho de resultar lo suficientemente atractivo como para desear continuar jugando hasta el final. En Crossroads 2.0, los factores más destacados relacionados con la inmersión serían la absorción, el realismo y la proximidad. El primer aspecto mencionado depende en gran medida de las interacciones que se realicen en los diferentes grupos que juegan partidas para debatir sobre las cuestiones. Su importancia radica en que los usuarios puedan comprender el significado de cada opción para poder ligarlo a los resultados que se obtengan al final de la ronda y/o partida, motivo por el cual, un grado satisfactorio de absorción implicaría la existencia de al menos cinco intervenciones diferentes por parte de cada jugador en las distintas cuestiones del juego (siempre y cuando haya mínimo dos jugadores), 12 2.1. EVALUACIÓN DE USABILIDAD Marco conceptual y estado del arte reflejándose argumentos adecuados a favor o en contra de determinadas opciones y, finalmente, el argumento de cada jugador una vez se haya decantado por una respuesta. En lo que respecta al realismo, es un aspecto clave en aplicaciones de esta índole, puesto que la información mostrada ha de ajustarse a la realidad, obteniendo resultados fidedignos. Si sucediese lo contrario no solo los usuarios podrían abandonar la aplicación o realizar interpretaciones erróneas, sino que sería prácticamente imposible satisfacer el principal objetivo de la aplicación y, por ende, llegaría incluso a perder su utilidad. Finalmente, la proximidad ejerce un papel importante, puesto que es útil y necesario saber establecer una comparación de cada opción presentada respecto a la situación que se está viviendo actualmente tanto en nuestro país como a nivel mundial. Motivación: Características del juego que incitan a intentar realizar un conjunto de acciones específicas hasta conseguir completarlas. La motivación está definida por los siguientes factores: •Estímulo: Grado en el que el ánimo del jugador se encuentra afectado por la confianza que sienten a la hora de enfrentarse a nuevos desafíos intentando alcanzar determinados objetivos. •Curiosidad: Puede relacionarse con la inclusión de objetivos y otros elementos opcionales que amplíen las opciones de interacción disponibles para el jugador. •Auto mejora: Se manifiesta cuando el usuario desarrolla determinadas habilidades que le permiten superar desafíos. •Diversidad: Un elenco amplio de elementos hace que el juego resulte más atractivo para los usuarios evitando caer en la monotonía. La motivación se encuentra relacionada con la dimensión engaging, puesto que abarca métodos orientados a lograr que el usuario utilice con frecuencia el videojuego correspondiente, asegurándose de contar con diversas opciones de interacción que resulten atractivas para el jugador. Emoción: Impulso involuntario del jugador a modo de respuesta a un estímulo transmitido por el videojuego que desencadena determinados sentimientos o comportamientos. Una vez más, se describe un atributo relacionado con la dimensión engagement, puesto que los diferentes aspectos vinculados a emociones son factores clave a la hora de determinar si el usuario opta por seguir jugando, además de recomendar el juego. A la hora de hablar sobre emociones en los videojuegos, conviene tener presentes las siguientes características: •Reacción: Un videojuego puede actuar como fuente de estímulos que desencadenan determinadas reacciones por parte de jugadores. Cada una de estas reacciones puede estar asociada a un elenco amplio de emociones. 13 2.1. EVALUACIÓN DE USABILIDAD Marco conceptual y estado del arte •Conducta: Los videojuegos pueden actuar como mecanismos capaces de influir en la conducta del jugador durante el intervalo de tiempo en el que lo utiliza, produciendo diversas emociones gracias a los vínculos que genera. •Atractivo sensorial: Es necesario que el juego transmita un interés en lo que respecta a aspectos estéticos para atraer al usuario, empleando medios como diversos canales sensoriales (como pueden ser canales audiovisuales para estimular sus sentidos). En Crossroads 2.0, los elementos emotivos desempeñan un papel importante, especialmente en la cinemática inicial y presentación de resultados, puesto que, es conveniente presentar elementos llamativos y lo suficientemente impactantes como para lograr que los usuarios sean conscientes de los problemas desencadenados por el cambio climático y la necesidad de tomar las medidas adecuadas para atenuarlos. Socialización: Se trata del conjunto de atributos, elementos y recursos que promueven la dimensión social del juego en un determinado grupo. La socialización es un factor muy importante a la hora de definir la percepción del juego por parte de los distintos jugadores, influyendo de forma notable las relaciones establecidas entre jugadores, además de poder afectar a la conexión de cada usuario con determinados personajes del juego. En el ámbito asociado a la socialización en videojuegos se distinguen las siguientes propiedades: •Percepción social: Abarca tanto el grado de actividad social presente en las sesiones de juego como el percibido por los jugadores que participan. •Consciencia de grupo: Grado en el que los usuarios son conscientes de su participación en un grupo compartiendo objetivos y desafíos comunes. Es importante que los jugadores comprendan que forman parte de un grupo cuyo éxito depende de si logran o no alcanzar una serie de objetivos compartidos. •Implicación personal: El jugador ha de ser consciente de que un logro individual contribuye a la victoria final del grupo, de modo que. los recursos disponibles en el juego deben servir para poner énfasis en la contribución de cada jugador respecto al éxito total del grupo. •Compartición: Cuando se juega en grupo los objetivos y recursos son compartidos por todos los miembros. •Comunicación: Los juegos multijugador deben proporcionar medios para favorecer en la mayor medida posible el intercambio de información entre dos o más jugadores. •Interacción: Define el modo en el que los jugadores perciben las reglas, así como la forma en la que se relacionan los distintos personajes para superar los desafíos y alcanzar los objetivos del juego. La interacción puede ser competitiva si un jugador desea alcanzar objetivos personales que implicarían la derrota del resto, colaborativa si existen equipos que persiguen objetivos comunes, de 14 2.1. EVALUACIÓN DE USABILIDAD Marco conceptual y estado del arte forma que alcanzarlos equivaldría a una victoria en conjunto y cooperativa, en el caso de existir jugadores con sus propios objetivos, pero que puedan necesitar ayuda de otros usuarios para poder alcanzarlos. A raíz de la información expuesta en el apartado 1.1, es sencillo percatarse de la importancia que cobra la socialización en CrossRoads 2.0, puesto que el juego se basa en el trabajo en equipo para debatir y tomar una serie de decisiones que influirán en los futuros resultados. En la aplicación todos los jugadores que forman parte de una partida cuentan con un chat para interactuar en el que pueden enviar y visualizar mensajes a miembros de un mismo grupo o de la sala de juego en la que se encuentran. Finalmente, el juego Crossroads 2.0 sigue un modelo de interacción colaborativa, puesto que todos los miembros de un grupo persiguen un objetivo compartido: lograr que sus decisiones permitan obtener los mejores resultados posibles, de forma que puedan trabajar de ese modo en un futuro para atenuar los efectos del cambio climático. Instrumentos de prueba Para realizar pruebas de usabilidad conviene tener en cuenta la existencia de diversas herramientas que faciliten la labor, siendo las más significativas [106]: Observación: Método utilizado para poder conocer el modo de interactuar con el sistema por parte de cada usuario cuando se realizan las tareas de la evaluación. La observación puede realizarse de forma directa, o bien recurriendo a fuentes secundarias como documentos o vídeos (observación indirecta). Entrevistas individuales a cada componente o a miembros que cumplen unas determinadas características pudiendo tratarse de entrevistas estructuradas (siguen un esquema concreto de preguntas) o bien entrevistas no estructuradas. Cuestionarios: Preguntas estructuradas que han de entregarse a los participantes de las pruebas, de forma que se respondan sin la intervención de un entrevistador. Heurísticas: Evaluación llevada a cabo por expertos basándose en un conjunto de principios establecidos con anterioridad. Ensayo cognitivo: Evaluación de la facilidad de aprendizaje mediante el uso de prototipos. Thinking Aloud (pensamiento en voz alta): Se basa en solicitar a los participantes que expresen sus opiniones en voz alta. Sesiones de prueba A la hora de realizar pruebas de usabilidad conviene considerar una serie de cuestiones [106]: 15 2.3. EVALUACIÓN DE USABILIDAD EN SERIOUS GAMES Marco conceptual y estado del arte el ratio máximo coste/beneficio se puede alcanzar con cuatro participantes, además de que en un proyecto de tamaño mediano una cantidad superior a dieciséis usuarios supondría un coste extra, además de no aportar nueva información [76]. Evaluadores de la sesión: Otro aspecto a tener en cuenta es la cantidad de evaluadores que intervendrán en las futuras sesiones de evaluación. Si bien es cierto que contar con una cantidad amplia de evaluadores se podría traducir en un incremento de coste, es conveniente contar con varias personas encargadas de llevar a cabo la labor de evaluación, ya que podrían detectar diferentes problemas [ 53 ], existiendo la posibilidad de que alguno pase desapercibido en el caso de contar con un único evaluador. Instrumentos para evaluación de usabilidad en serious games Para los evaluadores que intervienen en una sesión con el fin de identificar posibles inconvenientes es necesario disponer de un método estructurado para establecer una clasificación de eventos distinguiendo las categorías necesarias. Recogida de datos: Las interacciones de usuarios pueden ser no verbales, rápidas e impredecibles. motivo por el cual, en ocasiones, llevar a cabo una anotación en tiempo real puede ser un proceso complejo o directamente imposible si la interacción se produce de forma rápida (como podría ser la comunicación a través del chat en el caso de Crossroads 2.0, ya que la idea principal es que todos los jugadores, antes de elegir su respuesta para cada cuestión se comuniquen escribiendo múltiples mensajes en dicho chat). Además, las operaciones de anotación podrían distraer a los participantes de la sesión, motivo por el cual, se recomienda recurrir a grabaciones. Prototipo listo para utilizar: El prototipo debe ser lo más cercano posible al producto final. El prototipo tiene que permitir emular una sesión de juego reflejando cada una de las funcionalidades y elementos de interfaz correspondientes. Utilizar un prototipo incompleto podría conducir a errores a la hora de reflejar la auténtica usabilidad del producto final. Guión de los objetivos que persigue la sesión de juego: Finalmente, se debe elaborar un guión de evaluación breve en el que se distingan claramente los objetivos. El guión en cuestión ha de incluir las tareas que realizará cada uno de los participantes y cómo se espera que estos últimos actúen. Puede que sea necesaria más de una sesión de juego para poder abarcar todos los objetivos clave. Proceso de evaluación Loa evaluadores han de seguir una metodología estructurada para identificar problemas y aspectos a mejorar. A continuación, se exponen de forma genérica los pasos vinculados a una sesión de evaluación para serious games [70]. 22 2.4. TRABAJOS RELACIONADOS Marco conceptual y estado del arte Diseño de sesión de juego: La sesión de evaluación ha de ser breve, además de haberse identificado claramente los objetivos perseguidos. Es necesaria la preparación de un guión detallado en el que se reflejen las tareas que va a realizar cada participante. El guión se debe basar en determinados objetivos relacionados con el aprendizaje. Selección de participantes: Las características de los participantes elegidos deben ser adecuadas teniendo en cuenta el contexto en el que se desarrolla el juego. Realización y grabación de sesiones: A los participantes se les da breves instrucciones sobre el juego y sus objetivos. Acto seguido, comienzan a jugar sin recibir ningún tipo de ayuda adicional salvo que se encuentren en una situación en la que no puedan continuar, además de permitirles expresar en todo momento sus pensamientos. Se recomienda grabar la sesión en vídeo, captando las reacciones verbales y no verbales de cada participante. Aplicación de instrumentos y anotación de resultados: Durante esta etapa se anotan todos los eventos significativos. Normalmente se trata de eventos negativos, que reflejan problemas encontrados en la usabilidad. Reconciliación de resultados: Esta etapa en cuestión se distingue cuando intervienen varios evaluadores. Puesto que cada evaluador puede haber recopilado distintas anotaciones, es necesario resolver discrepancias y diferentes interpretaciones de eventos. Preparación de un listado de cambios: La última etapa consiste en preparar una lista de posibles mejoras para el juego, identificando su grado de prioridad, cómo afectan al usuario o influyen en objetivos de aprendizaje. Se debe evitar que los cambios realizados influyan negativamente en aspectos clasificados como positivos por parte de los usuarios que intervinieron en la sesión, además de tener en cuenta los comentarios realizados por estos últimos. Para cada acción a realizar, es conveniente que exista un valor asociado al número de eventos es los que se ha sugerido dicha acción (valor de frecuencia), así como una cantidad que indique el número de usuarios afectados por dicha acción (extensión), además de ser aconsejable seguir un modelo incremental repitiendo los pasos mencionados en varias ocasiones, especialmente si se ha realizado una cantidad de cambios importante y/o exista la posibilidad de que los cambios puedan haber generado nuevos problemas de usabilidad que no fueron contemplados previamente. 2.4. Trabajos relacionados Videojuegos relacionados con el cambio climático En lo que respecta al cambio climático,de acuerdo con Jason S. Wu y Joey J. Lee [ 137 ], los primeros videojuegos se diseñaron hace más de treinta años, siendo juegos de tablero que trataban temas relacionados con el incremento de CO2 en la atmósfera terrestre. Desde la 23 2.4. TRABAJOS RELACIONADOS Marco conceptual y estado del arte publicación del primer artículo analizando este tipo de juegos, se produjo un incremento de los mismos, siendo más populares los juegos de rol, los online y, en tercera posición los de mesa. Un ejemplo importante de estos últimos es “Keep Cool”[ 18 ]. Se trata de un juego de mesa en el que los jugadores actúan como grupos de países que negocian acerca de problemas a tener en cuenta en lo que respecta al desarrollo de la economía y el cambio climático realizando operaciones como inversiones en investigación científica o decidir si se construyen fábricas estableciendo los niveles de emisiones (altos o bajos). El juego también tiene en cuenta condiciones extremas como inundaciones o periodos de sequía. Por otro lado, existen multitud de juegos online, siendo algunos de los más destacados los publicados en sitios web como “Climate Kids” [ 54 ] o “EcoKids”[ 55 ] .Se trata de una serie de juegos colaborativos orientados a la educación de los más jóvenes en cuestiones de cambio climático, basados sobre todo en la resolución de rompecabezas o trivial . La proliferación de las tecnologías móviles trajo consigo el desarrollo de juegos digitales más complejos, siendo uno de los más representativos “PowerAgent” [ 44 ], un juego para teléfonos móviles Java basado en completar misiones orientadas a la reducción del consumo de energía en hogares (para ver información sobre cómo se realizó una sesión de evaluación de esta aplicación véase el apartado 2.4), o bien títulos que tienen en cuenta la ubicación del dispositivo, como “Hábitat”[ 32 ].Dicho juego consiste en simular la adopción de un oso polar, así como resolver misiones y obtener insignias ubicadas en diferentes lugares. Además, completando un determinado número de misiones, los jugadores pueden desbloquear minijuegos adicionales y mejorar el nivel de salud del oso adoptado. La utilización de redes sociales también ha ejercido su influencia, estando presente en el videojuego “Greenify”[ 58 ], el cual, además de incluir la clásica resolución de misiones, ofrece a los jugadores la posibilidad de compartir sus ideas en redes sociales y ganar puntos, pudiendo comprometer de ese a un amplio grupo de usuarios de redes sociales en la actuación contra el el cambio climático. Actualmente, la amplia cantidad de plataformas y medios para acceder a videojuegos han animado tanto a desarrolladores independientes como a compañías importantes [ 33 ] a unirse a la lucha contra el cambio climático a través de la implementación de juegos basados en tecnologías más recientes. Un ejemplo relativamente reciente es el juego “Beyond Blue”. Se trata de un videojuego para diversas plataformas implementado por desarrolladores independientes, cuyo objetivo es concienciar a los jugadores sobre la necesidad de salvar los océanos a través de simulaciones relacionadas con aquello que un buceador puede encontrar en el fondo marino [77]. Por otra parte, es fundamental realizar el análisis de gamificación. Para ello se ha procedido a la revisión de dos estudios asociados a cambio climático. En su estudio titulado “Climate Change Gamification: A literature review” [ 90 ] Dorina Rajanen y Mikko Rajanen realizaron un análisis sobre publicaciones relacionadas con la aplicación de gamificación en el ámbito del cambio climático. El estudio en cuestión se basó relacionar una búsqueda de informes en la base de datos Scopus [ 98 ] relacionados con gamificación en el ámbito del cambio climático y el calentamiento global con el fin de analizar si la gamificación resultaba útil para fomentar el compromiso a combatir el cambio climático. En la investigación destacaron informes como uno que recopilaba una revisión de 43 estudios [ 31 ], proporcionando una 24 2.4. TRABAJOS RELACIONADOS Marco conceptual y estado del arte fuerte evidencia de que los denominados “serious games” tienen éxito en cuanto al compromiso y toma de decisiones relacionadas con el cambio climático, aunque no hacía mucho hincapié en el concepto de “gamificación”. Por lo general, la mayoría de informes analizados concluyeron que la aplicación de gamificación en el ámbito del cambio climático era una forma bastante adecuada a la hora de intentar fomentar el alcance de los objetivos establecidos (concretamente, solo se encontraron dos que presentaban discrepacias respecto a dicha afirmación [ 82 , 99 ]), destacando notablemente las conclusiones presentadas por cuatro de los informes analizados. ([78,31,71,85]). Basándose en una metodología similar a la del estudio realizado por Dorina Rajaneny Mikko Rajanen [ 90 ] descrito en el presente apartado, Georgina Guillen, Juho Hamari y Jaco Quist analizaron la relación existente entre el concepto de “gamificación” y el consumo sostenible individual, centrándose además en averiguar los métodos y mecánicas que han sido empleados con más frecuencia y los efectos ejercidos sobre el consumo sostenible [ 43 ], concluyendo que existe una relación importante entre los sistemas basados en gamificación y las acciones realizadas por cada individuo, siendo necesario sea consciente tanto de su responsabilidad como de su capacidad para producir resultados beneficiosos. Este hecho conduce a la necesidad de desarrollar e implementar medios que motiven la participación y permitan la exploración de métodos para consultar y comparar resultados, ya sea para reflejar el progreso individual o bien implicar a diversos grupos. Un posible objetivo futuro se basa en la investigación de interacciones en tiempo real, pudiendo posibilitar la identificación de determinados comportamientos por parte de los usuarios del sistema en el que se aplica la gamificación. También conviene tener presente el informe “A Bibliometric Review of research on higher education for sustainable development, 1998-2018” [ 45 ]. En dicho estudio, además de realizar la búsqueda en la base de datos Scopus se empleó la denominada “co-citación”, siendo un método de búsqueda capaz de ampliar los resultados obtenidos en la búsqueda de Scopus al incluir los informes que figuran en las referencias de cada resultado encontrado en la base de datos. El principal objetivo era analizar los estudios relacionados con la educación superior para el desarrollo sostenible. Se contó con un total de 1459 documentos publicados entre 1998 y 2018. Debido a la elevada cantidad de documentos obtenidos (mayor de la esperada), no se realizó el análisis de su totalidad, sino que se recurrió a selecciones aleatorias e intervalos de confianza. Una de las conclusiones más significativas fue la escasa presencia de documentación en sociedades que se encuentran en desarrollo, traduciéndose en la existencia de huecos socieconómicos y culturales, los cuales influyen negativamente en la implantación de soluciones relacionadas con problemas vinculados al desarrollo sostenible, además de hacer hincapié en la necesidad de incrementar la presencia de aspectos asociados a la sostenibilidad en educación superior, más allá de los centros vinculados a investigación académica. Finalmente, conviene destacar que los métodos de investigación presentan limitaciones, las cuales han de resolverse incluyendo diseños y herramientas de investigación más sofisticados. 25 2.4. TRABAJOS RELACIONADOS Marco conceptual y estado del arte Selección de criterios y realización de evaluaciones El siguiente punto a tener en cuenta es la forma en la que se han seleccionado criterios y realizado evaluaciones de videojuegos referentes al cambio climático. Un ejemplo de estudio basado en la selección de criterios de evaluación es “Criterios de evaluación de juegos en línea sobre cambio climático: Aplicación del método Delphi para su identificación” [ 81 ]. Tal y como indica su título, el estudio mencionado se basó en recoger opiniones grupales empleando el método Delphi para identificar cuáles son los criterios más relevantes en los que se ha de basar un juego sobre el cambio climático. El método en cuestión se basa en elaborar un cuestionario el cual ha de ser respondido por expertos. Una vez finalizado, se realiza un nuevo cuestionario que, de nuevo debe responder el grupo de expertos tras comunicarles los resultados de la iteración anterior. Los cuestionarios pueden repetirse hasta llegar a un consenso. Finalmente, se redactan las conclusiones partiendo de datos estadísticos relacionados con cada iteración [132]. En el estudio mencionado estuvo implicado un grupo de trece expertos especialistas en diversas ramas, garantizando su anonimato.Dicho estudio consistió en tres iteraciones realizándose la selección de criterios atendiendo a la existencia de al menos un 90% de consenso en lo que respecta a relevancia alta. El último cuestionario consistió en solicitar a cada experto reflejar su postura ante los criterios no elegidos en la segunda fase a través de un cuestionario con preguntas cerradas, siendo su finalidad confirmar la selección de criterios. En lo que respecta a resultados obtenidos, en la primera iteración el objetivo principal fue reflejar las ventajas con las que podría contar una herramienta de validación de juegos online centrados en el cambio climático. La segunda iteración persiguió el objetivo de realizar una primera selección de criterios atendiendo al porcentaje de consenso en lo que respecta a relevancia y, en la última iteración se confirmó la eliminación de los criterios con menor grado de relevancia en el cuestionario anterior. El siguiente ejemplo que a mencionar está relacionado con la evaluación por parte de profesores de un videojuego sobre cambio climático orientado principalmente a niños, con el fin de obtener su retroalimentación [ 35 ]. El grupo de profesores fue convocado a través de redes sociales, comprobándose que impartían clase a alumnos con edades comprendidas entre 6 y 14 años (estudiantes que se ajustan al público objetivo del juego). Se optó por emplear un checklist en el que se recogieron criterios básicos que podían seguir juegos relacionados con el cambio climático. El videojuego que probaron fue “Tito y sus amigos” en ordenadores portátiles. Se trata de un juego infantil en el que, a través de diferentes niveles y de interacciones con otros animales, un pingüino muestra diversas consecuencias que pueden derivar del cambio climático. Los docentes implicados realizaron una evaluación cualitativa de los siguientes aspectos: identificación, narrativa, contenidos, jugabilidad y elementos didácticos, concluyendo que el videojuego podía ser apto, útil y entretenido para niños contando con una variedad de conceptos importantes(aunque podrían ampliarse), un elevado peso narrativo y una curva de aprendizaje media. Pero no llega a disponer de las características necesarias para emplearlo en las aulas como medio didáctico. Un último ejemplo es el ya mencionado juego “Power Agent” [ 44 ].Para realizar la evaluación, se recogió la información sobre el consumo de energía asociado a dos grupos de tres 26 2.4. TRABAJOS RELACIONADOS Marco conceptual y estado del arte personas y sus familias situadas en dos ciudades de Suecia. Tras registrar la información, las tres personas de ambos grupos utilizaron el juego durante la primavera de 2008 compitiendo entre equipos constactando con los evaluadores mediante mensajería instantánea. Las respuestas se clasificaron en las diversas categorías atendiendo a su propósito. A continuación, se estimó el esfuerzo asociado a cada grupo comparando el consumo durante la sesión respecto a los datos tomados al inicio. Tras finalizar la partida, se examinó el consumo energético individual de los componentes de un grupo durante 57 días existiendo apenas desviaciones significativas respecto a la media salvo un caso puntual de un jugador durante las primeras semanas, aunque se resaltó la necesidad de seguir investigando sobre las posibles cifras de consumo a largo plazo. 27 3: El videojuego Crossroads 2.0 En el presente capítulo se procede a la exposición de los aspectos más relevantes en la versión actual de la aplicación, así como elementos a tener en cuenta en la creación de videojuegos con los que cuenta Crossroads 2.0. Las funcionalidades de la versión actual se presentan a continuación: Registro de moderador: En primer lugar, es necesario que el moderador se registre en el sistema. A través de la opción “registrarse como chair”, accede un formulario en el que se especifica el nombre, apellidos, nombre de usuario, email, fecha de nacimiento y contraseña asociada al nuevo moderador. Si el formato de los datos introducidos es correcto, el registro se lleva acabo con éxito redireccionando al moderador a una pantalla específica del rol desde la cual puede desempeñar sus tareas (ver figura 3.4). Figura 3.4: Pantalla inicial para moderadores Las opciones que se encuentran disponibles en la versión actual de la aplicación son: 28 El videojuego Crossroads 2.0 El videojuego Crossroads 2.0 Inicio de sesión: Un moderador que se haya registrado previamente el el sistema puede acceder a su pantalla específica de operaciones completando un formulario que le permite iniciar sesión. Para ello, en la pantalla de inicio elige la opción “organizar partida” accediendo un formulario de inicio de sesión donde se introduce el nombre de usuario y contraseña. Si los datos introducidos son correctos, el moderador es redireccionado a la página mostrada en la figura 3.4. Creación de sala: Como se ha mencionado, el moderador es el encargado de crear salas de juego. Para ello selecciona en su menú específico “Crear sala” accediendo un formulario con los siguientes campos (véase la figura 3.5): Una vez creada la sala, se genera un código que el moderador facilita a cada jugador para unirse, además de ser redireccionado a una pantalla de espera donde se muestran los datos de la sala y la opción “Empezar partida” (ver figura 3.5). Cabe destacar que la opción “grupos aleatorios” no se encuentra disponible en la versión actual de la aplicación. Figura 3.5: Formulario para crear sala (1) y pantalla de espera para el moderador (2) Unirse a una sala: Tras haber recibido el código, los jugadores pueden entrar en la sala correspondiente. Para ello, a través de la opción “Participar en juego” de la 29 El videojuego Crossroads 2.0 El videojuego Crossroads 2.0 pantalla inicial, acceden a un formulario (ver figura 3.6) donde se introduce el código y, acto seguido, el sistema solicita la introducción de sus datos, concretamente: Si los datos introducidos son correctos, el jugador correspondiente es redireccionado a una pantalla en la que puede visualizar una cinemática inicial de la aplicación (como se muestra en la figura 3.6). Figura 3.6: Formulario introducir un código (1), formulario para registrar a un jugador (2) y pantalla de cinemática inicial A continuación, el jugador accede a una pantalla de espera en la que selecciona el grupo al que desea unirse (ver figura 3.7). 30 El videojuego Crossroads 2.0 El videojuego Crossroads 2.0 Figura 3.7: Pantalla que permite a un jugador unirse a un grupo Iniciar partida: Una vez se hayan unido todos los jugadores a los grupos correspondientes, el moderador, desde su pantalla de espera elige la opción “Empezar partida”, siendo redirigido a la pantalla de dashboard (véase la figura 3.8). Figura 3.8: Pantalla de Dashboard La pantalla de dashboard cuenta con las siguientes funcionalidades: 1. Monitorización de jugadores: Seleccionando la ronda y grupo correspondientes, el moderador puede visualizar el estado de los jugadores en cualquier instante de la partida. 2. Siguiente ronda: Finaliza la ronda actual y da comienzo a la siguiente. 3. Terminar: Finaliza la partida mostrando a los jugadores los resultados finales (no es necesario que hayan terminado todas las rondas para poder finalizar la partida). 31 3.1. ELEMENTOS FORMALES El videojuego Crossroads 2.0 una implementación que permita alcanzar un rendimiento aceptable, teniendo en cuenta parámetros como el tiempo de respuesta (en el caso de Crossroads 2.0 sería conveniente que el tiempo de carga máximo se sitúe en torno a los dos segundos, o bien no se demore significativamente en el caso de que la cantidad de usuarios conectados sea más amplia [118], además de no producirse bloqueos si se da dicha situación). Por otro lado, tanto los chats como la matriz de conflictos (que contiene todas las respuestas marcadas por los diferentes componentes del grupo) han de actualizarse conforme existan modificaciones en la base de datos. Los chats deben mostrar siempre todos los mensajes correspondientes a un grupo o a jugadores de la sala (según la opción que se decida marcar) y, la matriz de conflictos debe actualizarse conforme los jugadores respondan cuestiones indicando si existe o no consenso en las respuestas dadas. Roles En diversos juegos que permiten la intervención de varios jugadores existen divisiones de roles. Cada usuario desempeña un papel distinto y cuenta con características exclusivas acordes al rol en cuestión. Si bien es cierto que no se trata de una cuestión estrictamente necesaria, puede servir de utilidad en temas relacionados con la creatividad, así como mejora de jugabilidad y experiencia de usuario, favoreciendo la inmersión de los usuarios en el “mundo del juego” (Para más información consulte el apartado 2.1). Trasladando los contenidos teóricos de este apartado a Crossroads 2.0, se puede afirmar, en primer lugar que, a pesar de contar con dos tipos de usuarios claramente identificados (véase el apartado 1.1) no puede considerarse la existencia de roles que favorezcan a la usabilidad y la inmersión en la aplicación. No obstante, se planea incluir en versiones futuras la posibilidad de que cada jugador que se una a una partida pueda escoger un rol diferente relacionado con el cambio climático Concretamente, los futuros roles a seleccionar serán: “experto en ecología, ciencias de la Tierra y clima”, “experto en sociología, política, ética y derechos humanos”, “experto en energía y transporte” y “experto en desarrollo, economía y empleo”. Además, todos los mensajes y ayudas presentadas a cada jugador dependerán del rol que haya seleccionado, contribuyendo a la mejora del grado de inmersión y, por ende, ejerciendo influencia en la eficacia del videojuego, ya que la inclusión de roles con características propias puede incitar al jugador a mostrar interés sobre las cuestiones que se están tratando . Patrones de interacción de jugadores Otro aspecto importante que conviene tener presente en el diseño de videojuegos es el establecimiento de patrones relacionados con la interacción. Los principales patrones se muestran a continuación: Un solo jugador que compite contra el sistema (como sucede en el caso del solitario) 38 3.1. ELEMENTOS FORMALES El videojuego Crossroads 2.0 Varios jugadores contra el sistema (Siendo un ejemplo Farmville 2 [123]) Competición directa entre dos jugadores (presente en los tradicionales juegos de lucha, como “Soul Calibur II” [135]). Competición unilateral: Un grupo de mínimo dos jugadores compite contra un único jugador. Competición multilateral: Competición de tres o más jugadores. Un ejemplo de este tipo de juegos es “Halo 4” [127]. Juego cooperativo: Dos o más jugadores compiten contra el sistema. Un ejemplo de este tipo de juegos es “Left 4 Dead” [129]. Competición de equipos: Implica la competición entre dos o más grupos. El patrón seguido por Crossroads 2.0 en el caso de optar por iniciar una partida que implique a más de un grupo es la competición de equipos, puesto que, una vez finalizada dicha partida, los jugadores acceden a una pantalla de resultados finales donde se muestran los equipos que hayan obtenido mejores puntuaciones en cada disciplina a tener en cuenta. Por otra parte, la aplicación también sigue un patrón de juego cooperativo, puesto que los jugadores de cada grupo interaccionan y debaten a través de un chat sobre sus puntos de vista relacionados con las opciones de cada cuestión. Objetivos del juego En los videojuego los objetivos son aquello que los jugadores desean alcanzar siguiendo las reglas . Alcanzar dichos objetivos ha de ser un reto posible de superar, de nuevo procurando que los jugadores no caigan en el aburrimiento por sencillez excesiva ni en la frustración por existir demasiada dificultad. Además, los objetivos definen el tono del juego (a modo de ejemplo: no es lo mismo un juego educativo cuyo objetivo sea el aprendizaje de palabras y números que uno consistente en eliminar fuerzas enemigas y salir victorioso de una guerra). Algunos videojuegos están diseñados de tal forma que cada jugador tenga que lograr objetivos diferentes, mientras que, en otras ocasiones, es el propio jugador quien define sus propias metas a medida que va avanzando. Por otro lado, conviene destacar los juegos en los que existan pequeños objetivos cuyo logro contribuya al alcance de la meta principal. Los objetivos en un videojuego son uno de los elementos más importantes a tener en cuenta, puesto que influyen tanto en los elementos formales de los videojuegos como en los elementos dramáticos expuestos en el apartado 3.2, puesto que, si los objetivos en cuestión encajan con la premisa del juego correspondiente, los aspectos dramáticos del mismo se acentuarán. A la hora de determinar los objetivos que persigue un videojuego, conviene hallar una respuesta para cada pregunta mostrada a continuación: ¿Cuáles son los objetivos de videojuegos que has probado anteriormente? 39 3.1. ELEMENTOS FORMALES El videojuego Crossroads 2.0 ¿Qué impacto ejercen dichos objetivos en el tono del juego? ¿Existen objetivos propios de ciertos géneros de videojuegos? ¿Qué sucede con los objetivos múltiples? ¿Los objetivos tienen que ser explícitos? ¿Qué sucede con los objetivos determinados por el jugador? En el ámbito de Crossroads 2.0, el principal objetivo es poder concienciar a los jugadores acerca de los efectos que tendrían sus decisiones en el futuro respecto al cambio climático. Dicha meta influye de forma clave en el tono del juego, puesto que, por un lado, conviene que los usuarios puedan visualizar unos resultados impactantes y llamativos, capaces de producir sensaciones relacionadas con la necesidad de responsabilizarse y trabajar para poder atenuar en mayor medida las consecuencias futuras del cambio climático. La presencia de elementos como puntuaciones y chats permite a los jugadores establecer sus propios objetivos, los cuales pueden ser desde convertirse en el grupo ganador obteniendo la mayor puntuación hasta intentar ajustarse de la mejor forma posible a los objetivos elegidos dedicando tiempo a pensar y debatir sobre las respuestas que puedan contribuir al logro de dicha meta. Además, en versiones futuras cada cuestión irá acompañada de una serie de ayudas, las cuales dependerán del rol seleccionado por el jugador (véase el apartado 3.1). Las ayudas en cuestión serán de utilidad para que los jugadores puedan adquirir conocimientos (en el caso de no contar con un experto en la materia ) y aplicarlos en sus debates de posibles respuestas. El objetivo principal de la aplicación es propio de juegos educativos orientados al problema del cambio climático. Concretamente, dicha meta se alcanza respondiendo cuestiones e interactuando con el resto de jugadores del grupo. Responder a cada cuestión puede definirse como un “mini objetivo” necesario para alcanzar la meta final. No se trata de objetivos explícitos como el principal, puesto que los usuarios, al iniciar una partida y ver cada cuestión en pantalla saben de antemano que solamente podrán avanzar en el juego si eligen y envían una respuesta. Procedimientos En el ámbito de los videojuegos, el término “procedimiento” hace referencia a las acciones que lleva a cabo el jugador para alcanzar los objetivos correspondientes. A la hora de definir procedimientos en un juego, conviene tener presentes las siguientes cuestiones: ¿El procedimiento va orientado a un jugador, un grupo concreto de jugadores o todos los jugadores? ¿Qué hace exactamente el jugador? 40 3.1. ELEMENTOS FORMALES El videojuego Crossroads 2.0 ¿Dónde se lleva a cabo el procedimiento? ¿Cuándo sucede? ¿Cómo se accede al procedimiento? Basándose en dichas preguntas, los procedimientos más comunes en videojuegos se muestran a continuación: Acción de inicio: Procedimiento necesario para comenzar el juego. Progresión de la acción: Procedimientos posteriores a la acción de inicio. Acciones especiales : Su disponibilidad depende de otros elementos o el estado de la partida. Acciones de resolución: Procedimientos orientados a la finalización del juego. En lo que respecta a Crossroads 2.0, las acciones de inicio consisten en la introducción de un código recibido del moderador por parte de cada jugador, registrar sus datos y unirse a un grupo. Por otro lado, el moderador confirma el inicio de ronda y partida. Los procedimientos que se corresponden a la progresión de la acción consisten en responder a cuestiones, debatir en chats y resolver conflictos en el caso de no existir consenso en alguna pregunta. Pueden calificarse como acciones especiales la consulta de resultados (los cuales dependen del estado de la partida,ya que solamente están disponibles si el moderador ha confirmado la finalización de la ronda o de la partida en cuestión) y el futuro acceso a ayudas (puesto que la disponibilidad de determinadas ayudas dependerá del rol elegido por el jugador). En cuanto al moderador, cuenta con la posibilidad de obtener documentos PDF con los resultados de rondas y generales de cada partida (de nuevo depende del estado, puesto que la información solamente está disponible en las circunstancias mencionadas).Finalmente, la acción de resolución es la confirmación por parte del moderador de la finalización de la partida. Recursos Un recurso puede definirse como un bien que puede utilizarse para alcanzar determinados objetivos. Los recursos dependen del tipo de juego, siendo los más frecuentes sistemas de vidas, salud, monedas virtuales, unidades, superpoderes, terrenos especiales, tiempo y acciones. Crossroads 2.0 se basa en el empleo de los dos últimos recursos mencionados. No existe un sistema de tiempo como tal que permita al jugador visualizar la cantidad de minutos y segundos restantes que quedan para finalizar una partida, ya que no disponen de una duración fija. No obstante, el propio moderador puede decidir finalizar una ronda o partida en cualquier momento recurriendo a la resolución automática de conflictos. Dicho 41 3.1. ELEMENTOS FORMALES El videojuego Crossroads 2.0 sistema ha sido creado principalmente para impedir que las partidas se prolonguen en exceso, especialmente en lo que respecta a pruebas de usabilidad, puesto que el límite establecido para dichas pruebas oscila entre 30 y 60 minutos [106]. La resolución automática de conflictos se basa en elegir las respuestas más votadas para cada cuestión en la que no se haya alcanzado un consenso y, finalmente, mostrar los gráficos y puntuaciones correspondientes. En lo que respecta a acciones, Crossroads 2.0 se basa en responder catorce cuestiones en cada ronda e interactuar con miembros del grupo compartiendo puntos de vista. Tanto las respuestas dadas como la cantidad de interacciones ejercen influencia en los resultados finales (gráficos y puntuaciones). Conflictos Los conflictos surgen cuando varios jugadores intentan alcanzar unos determinados objetivos en un mismo periodo de tiempo. Se producen al existir procedimientos, reglas y/u otro tipo de situaciones que impidan o dificulten en gran medida la consecución directa de determinados objetivos, obligando a los jugadores a desarrollar y emplear determinadas habilidades, creando un ambiente de competición. Los elementos causantes de conflictos más frecuentes en el mundo de los videojuegos son: Obstáculos: Se trata de elementos frecuentes tanto en videojuegos de un solo jugador como en los que implican a varios usuarios. Pueden estar presentes de forma física (siendo un posible ejemplo rocas que bloquean un camino) o tratarse de un desafío mental, como los conocidos rompecabezas. Oponentes: Se trata de la principal fuente de conflictos en videojuegos multijugador, puesto que son usuarios que persiguen un mismo objetivo o bien metas diferentes que puedan ser beneficiosas para ellos pero perjudiciales para el resto de usuarios. Un ejemplo conocido es la competición entre dos equipos en cada partida de “League Of Legends”[ 128 ], donde el grupo ganador es aquel que logre alcanzar la base de sus oponentes destruyendo su nexo. Dilemas: Otro elemento asociado a conflictos destacado es la toma de decisiones basadas en dilemas, de forma que las elecciones de cada jugador pueden influir de forma importante en el transcurso del juego. Se trata de un aspecto presente tanto en videojuego de un jugador como en los dirigidos a múltiples jugadores. Crossroads 2.0 presenta claramente dilemas, puesto que las respuestas marcadas en cada cuestión determinarán los resultados finales (incluyendo la retroalimentación recibida) conforme a gráficos y puntuaciones tanto en el ámbito de las rondas como al final de la partida. Por otro lado, la aplicación favorece la competición entre grupos de usuarios, mostrando en la pantalla final los grupos que han obtenido mejores resultados en cada una de las diferentes disciplinas (precisión, ecológico, participativo y compromiso). Finalmente, cada cuestión podría definirse como un desafío mental, puesto que requiere pensar y debatir acerca de las diferentes opciones disponibles antes de responder. 42 3.2. ELEMENTOS DRAMÁTICOS El videojuego Crossroads 2.0 Límites El último aspecto a tener en cuenta en el presente apartado es la existencia de límites en los videojuegos, es decir, aquello que separa a los elementos accesibles del resto. Dichos límites pueden ser físicos (como tamaño de campos de fútbol o casillas de tableros) o conceptuales (como establecer acuerdos para empezar una partida). La definición de límites es importante a la hora de determinar las estrategias y habilidades a utilizar, influyendo además en la experiencia de usuario. En Crossroads 2.0 existen diversos ejemplos de límites: En primer lugar, el moderador no puede crear una sala sin haberse registrado o iniciado sesión en la aplicación. Además, tampoco es posible partida si la sala no ha alcanzado su máximo de jugadores, iniciar una partida en curso o finalizar una partida que no haya comenzado. En lo que respecta al jugador, este no puede unirse a una sala sin haber introducido un código correcto facilitado previamente por el moderador, además de ser necesario registrar sus datos antes de poder unirse a un grupo. En una sala no puede haber dos o más usuarios con el mismo nombre. A esto hay que añadir que un jugador no puede acceder a una sala o unirse a un grupo que ha alcanzado el número máximo de usuarios permitido. Por otro lado, ningún jugador puede dejar una pregunta sin responder ni enviar mensajes sin haber introducido texto en el formulario correspondiente. Finalmente, ningún usuario con el rol de jugador puede ver las pantallas de resultados sin que el moderador haya confirmado la finalización de la ronda o la partida. 3.2. Elementos dramáticos Recurriendo de nuevo a la información expuesta en “A Playcentric Approach to Creating Innovative Games” [ 34 ], un videojuego no se trata simplemente de realizar un conjunto de tareas, sino de lograr que dichas tareas tengan un significado para el jugador y este último se sienta satisfecho al completarlas. Además de apreciarse el progreso de cada usuario conforme va avanzando en el juego, siendo la idea principal encontrarse con dificultades al inicio del mismo derivadas del desconocimiento de mecánicas, objetivos y reglas. Dichos inconvenientes pueden superarse conforme se van completando tareas en el juego. Estableciendo un paralelismo con la teoría de flujo presentada por el psicólogo Mihaly Csikszentmihalyi [ 73 ] si se cumple esta condición puede afirmarse que el juego presenta dinamismo, manteniéndose entre medias de los dos extremos negativos a tener en cuenta: frustración (existencia de una cantidad excesiva de dificultades) y aburrimiento (sucede cuando el videojuego resulta demasiado fácil). Tal y como puede apreciarse, de nuevo se exponen situaciones que pueden relacionarse con las dimensiones de usabilidad desarrolladas por Quesembery [ 89 ], concretamente engaging, facilidad de aprendizaje, tolerancia a errores e incluso eficacia, puesto que los aspectos expuestos ejercen una clara influencia en el grado de cumplimiento por parte del usuario asociado a los objetivos del juego. En lo que 43 3.2. ELEMENTOS DRAMÁTICOS El videojuego Crossroads 2.0 respecta a Crossroads 2.0, las tareas presentadas tienen un claro significado, puesto que no deja de ser un juego que emula la toma de decisiones relacionadas con temas de cambio climático por personas expertas en la materia, siendo el resultado final el efecto de las mismas en el futuro. No se trata simplemente de responder una serie de cuestiones, sino que conviene pararse a pensar y debatir poniéndose en la piel de un posible experto. En lo que respecta a los logros , el juego presenta una pantalla final en la que se muestran los grupos que hayan obtenido las mejores puntuaciones con un mensaje de felicitación por su trabajo, siendo una forma de generar satisfacción y animar a los jugadores a volver a utilizar la aplicación y/o a recomendarla. En cuanto a dinamismo , es muy probable que los jugadores obtengan mejores resultados tras haber jugado previamente al menos una partida, puesto que la situación más frecuente es que la aplicación no sea utilizada por expertos y resulte complicada la comprensión completa del contenido presentado en una única iteración, asemejándose dicha circunstancia a la reflejada en el inicio del presente apartado. Naturaleza del juego Otro aspecto relevante en lo que respecta a videojuegos es la libertad del jugador para actuar dentro de un conjunto de reglas y restricciones. Los puntos de vista sobre el concepto de “juego” son variados, pudiendo ser dicha actividad útil para adquirir conocimientos y habilidades, simplemente entretener o incluso experimentar. Ahora bien, ¿qué actividades pueden considerarse exactamente como juego?. Roger Caillois ofrece una respuesta a esta cuestión en su libro “Man, Play and Games” [11], distinguiendo cuatro tipos de juego: Juego competitivo: Abarca deportes en los que varias personas compiten entre ellos o formando equipos (fútbol, baloncesto, esgrima, etc). Juegos basados en suerte: En este grupo se incluyen los juegos de azar como loterías. Juegos de interpretación: Engloba actividades relacionadas con el teatro y el mundo del espectáculo en general. Juegos de vértigo: Hace referencia a deportes extremos como la escalada o el esquí. A raíz de la siguiente clasificación surge la cuestión sobre su aplicación en videojuegos. Conviene tener presente que los videojuegos no dejan de ser formas de emular determinados aspectos de la realidad. Crossroads 2.0 puede definirse como un videojuego que emula tanto juego competitivo (en el caso de estar implicado más de un grupo, ya que los equipos en cuestión compiten entre sí para comprobar quién obtiene mejores resultados) como juego de interpretación, puesto que cada jugador se pone en la piel de un experto en cuestiones de cambio climático. Este último aspecto cobrará mayor relevancia en versiones futuras, donde se contemplará la distinción de diversos roles para cada jugador (véase el apartado 3.1 para más información). 44 3.2. ELEMENTOS DRAMÁTICOS El videojuego Crossroads 2.0 Premisa Además de ofrecer desafíos, un videojuego también ha de incluir presente el concepto de “premisa” , el cual se utiliza para presentar metafóricamente las acciones y elementos principales del mismo. Tal y como se ha mencionado a lo largo del documento, Crossroads 2.0 se basa en responder una serie de cuestiones, siendo la principal premisa actuar como un experto en cambio climático para analizar los resultados derivados de las elecciones en cuestión. De esa forma, las preguntas respondidas adquieren un significado, motivo por el cual, la premisa acaba siendo un elemento clave e indispensable para proporcionar una mejor experiencia de juego. Personajes Los personajes pueden definirse como agentes cuyas acciones definen las situaciones dramáticas. Se trata de elementos clave puesto que, a través de ellos los espectadores entienden los acontecimientos de la historia que se desea contar, además de poder empatizar con ellos. Cada personaje puede contar con diferentes características, siendo más común el personaje usado para reflejar el tipo de historia que desea contarse, aunque también puede hacerse referencia a personajes simbólicos. El personaje principal es denominado “protagonista” y se ve comprometido en el conflicto principal a partir del cual se desarrolla la historia. A los objetivos del protagonista se opone el denominado “antagonista”, pudiendo tratarse de una persona o una fuerza que actúa en contra del protagonista. En función de su impacto en la historia, los personajes pueden ser principales o secundarios. Dicho impacto depende de factores como su forma de actuar o lo que se dice de ellos. Independientemente del grado de complejidad asociado a un personaje, es importante tener en cuenta lo que desea y necesita el personaje, además de aquello esperan y/o temen los jugadores. Los aspectos expuestos no se aplican exclusivamente a personajes de videojuegos, sino de cualquier tipo de obra. Al hablar sobre personajes también son importantes los conceptos de “acción” y “empatía”. En primer lugar, el término “acción” hace referencia a la función desempeñada por un personaje del juego para servir como representación del jugador pudiendo incluir aspectos como la identificación, creatividad y cuestiones relacionadas con roles. En cuanto a la empatía, se trata de la capacidad para desarrollar una atracción emocional hacia el personaje, sintiéndose identificado con sus objetivos y, por ende, con los del juego. Los conceptos de “acción” y “empatía” deben aplicarse en todos los puntos del juego que implican a los personajes. En el caso de Crossroads 2.0, no existen personajes definidos como tal en la versión actual. No obstante, cuando se lleve a cabo la inclusión de roles especificada en el apartado 3.1 existirán varios personajes especializados en determinadas disciplinas. Los personajes no contarán con una historia y un desarrollo en sí, sino que serán interpretados por los jugadores en su labor de proteger al planeta de los efectos producidos por el cambio climático. 45 3.2. ELEMENTOS DRAMÁTICOS El videojuego Crossroads 2.0 Historia Ligado a los conceptos expuestos en el apartado 3.2 se encuentra la historia. En el mundo de los videojuegos la historia suele desarrollarse como ampliación de una premisa inicial, siendo frecuente la creencia de que su potencial se incrementará si la historia en cuestión parte de la jugabilidad, en lugar de ceñirse a otra estructura. En la actualidad es más frecuente que el argumento de un videojuego se base en aventuras consistentes en la resolución de determinadas misiones para avanzar en la historia. No obstante, hoy en día también es tendencia experimentar con el fin de incrementar la profundidad de la historia sin que suponga el sacrificio de la jugabilidad. En el arco dramático tradicional el conflicto es el núcleo principal el cual, no solamente se basa en dificultar el alcance de diversos objetivos por parte de los jugadores, sino que los introduce en el juego generando un sentimiento de tensión y curiosidad acerca de los acontecimientos futuros. Respecto al rol de protagonista, en el caso de un videojuego puede tratarse del jugador en sí o bien de un personaje que represente al jugador. El conflicto en el que interviene el jugador puede deberse a la participación de otro jugador o un grupo de jugadores, así como a la presencia de obstáculos, dilemas o fuerzas de diferente índole. Los conflictos presentes en videojuegos se han dividido en diversas categorías, siendo ejemplos: jugador contra jugador, jugador contra sistema de juego, jugador contra múltiples jugadores o equipo contra equipo. De acuerdo con el arco dramático tradicional, una historia comienza presentando a los personajes principales e introduciendo el conflicto en forma de objetivo que dichos personajes desean alcanzar. El intento de resolver el conflicto desencadena una serie de acontecimientos que conducen a una acción creciente, la cual culmina en el clímax o punto álgido, momento en el que sucede un acontecimiento decisivo. Tras el clímax comienza un decremento de la acción, siendo un período durante el cual se resuelven los conflictos. En Crossroads 2.0 se parte de que existe el siguiente conflicto: nuestras acciones y forma de vivir actuales afectarán muy negativamente al planeta en el futuro, motivo por el cual, es necesario analizar cómo se ha de actuar con el fin de atenuar dichos efectos adversos. Los protagonistas (usuarios cuyo rol es el de jugador en la partida) intentan analizar a través de cuestiones las consecuencias que traerán consigo determinadas decisiones. Tras realizar diversos estudios (participar en varias rondas respondiendo cuestiones) se espera que los resultados obtenidos mejoren al haber comprendido conceptos recogidos en cada cuestión.Los resultados de la última interacción servirán de guía para aplicarlos a la vida real y poder mejorar la situación futura. 46 4: Plan de pruebas Una vez ubicadas las características de Crossroads de acuerdo a los diferentes elementos presentes en videojuegos, conviene hacer hincapié en las futuras pruebas que se realizarán, incluyendo el plan de pruebas a seguir, el cual se expone a continuación: 4.1. Presentación de mockups a usuarios en focus group A la hora de desarrollar un proyecto, el primer paso esencial consiste en presentar un prototipo a potenciales futuros usuarios explicando las consideraciones de análisis, diseño e implementación correspondientes. A.-Objetivo: Presentar un prototipo inicial de la aplicación a un grupo de profesores e investigadores con el fin de poder obtener su retroalimentación antes de comenzar a implementar la aplicación. En base a dichas respuestas comienza la implementación de las diferentes funcionalidades. B.-Responsables Tres miembros del grupo de investigación vinculado al proyecto. Dos de ellos ejercen el rol de observadores, tomando notas de aspectos relevantes, además de estar presentes para resolver posibles dudas, mientras que el miembro restante procede a exponer el prototipo a través de una presentación PowerPoint en la que figuran pantallas creadas con una herramienta de mockups. C.- Recursos e instrumentos de evaluación Duración aproximada de la sesión: 60 minutos Timing: Tras haber realizado un diseño inicial de mockups 47 4.2. PRUEBAS DE ROBUSTEZ Plan de pruebas Tarea 7 Descripción de la tarea Tolerancia a errores al unirse a una sala Descripción Cada jugador accede a una sala de juego a través de un código facilitado por el moderador que ha de introducir en un formulario. Para poder entrar en la sala, dicho código ha de coincidir con el recibido. Requisitos previos El moderador tiene que haber creado una sala de juego. Acciones de los moderadores Tras crear una sala de juego y facilitar el código correspondiente a los jugadores, el moderador es redireccionado a una sala de espera. Flujo En la primera partida, uno de los jugadores realiza las siguientes pruebas en el formulario empleado para introducir el código: Intentar enviar un código dejando un campo en blanco. Intentar acceder a la sala con un código distinto al facilitado por el moderador. Introducir el código correcto. Resultados esperados En los dos primeros casos se espera que el jugador no acceda a la sala mostrándose un mensaje de error informando sobre el hecho de que el código es incorrecto. Finalmente, en el último caso, los jugadores acceden a un formulario donde han de introducir sus datos. Tabla 4.7: Descripción de la tarea Tolerancia a errores al unirse a una sala Tarea 8 Descripción de la tarea Tolerancia a errores al realizar el registro de un jugador Descripción Una vez introducido el código correspondiente, cada jugador accede a un formulario donde introduce sus datos.Dicha información ha de seguir un formato determinado. Requisitos previos El moderador tiene que haber creado una sala de juego. Acciones de los moderadores Tras crear una sala de juego y facilitar el código correspondiente a los jugadores, el moderador es redireccionado a una sala de espera hasta que los jugadores se unan a los grupos correspondientes. 54 4.2. PRUEBAS DE ROBUSTEZ Plan de pruebas Descripción de la tarea Tolerancia a errores al realizar el registro de un jugador Tarea 8 Descripción de la tarea Tolerancia a errores al realizar el registro de un jugador Flujo En la primera partida,se realizan las siguientes pruebas: El primer jugador en acceder al formulario intenta enviarlo con los campos en blanco. Dicho jugador intenta registrarse introduciendo datos en formato incorrecto (nombre y país con un solo carácter). El jugador que entre a la sala en segundo lugar intenta registrarse con el mismo nombre que el primero. Un tercer jugador introduce el código e intenta registrarse rellenando el formulario (tras introducir los dos anteriores información correcta) Resultados esperados En todos los casos mencionados se tiene que mostrar un mensaje de error indicando que el formato de los datos introducidos no es correcto, o bien que la sala se encuentra llena y el jugador no puede unirse (en último caso mencionado).Si se introduce información correcta, los jugadores son redireccionados a la pantalla para visualizar la cinemática inicial. Tabla 4.8: Descripción de la tarea Tolerancia a errores al realizar el registro de un jugador Tarea 9 Descripción de la tarea Tolerancia a errores al unirse a un grupo Descripción Tras introducir sus datos, cada jugador debe seleccionar un grupo desponible para unirse. Salvo que la asignación de grupos sea aleatoria (función que se incluirá en versiones futuras), es obligatorio que cada jugador indique el grupo al que se unirá. Requisitos previos El moderador tiene que haber creado una sala de juego y los jugadores haber introducido el código de sala correspondiente y sus datos. Acciones de los moderadores Tras crear una sala de juego y facilitar el código correspondiente a los jugadores, el moderador es redireccionado a una sala de espera hasta que los jugadores se unan a los grupos correspondientes. 55 4.2. PRUEBAS DE ROBUSTEZ Plan de pruebas Descripción de la tarea Tolerancia a errores al unirse a un grupo Tarea 9 Descripción de la tarea Tolerancia a errores al unirse a un grupo Flujo En las diferentes partidas, se realizan las siguientes pruebas: En el caso de la primera partida, el primer jugador que accede a la sala intenta confirmar que se ha unido a un grupo sin haberlo seleccionado. En la primera ronda de la segunda partida, el segundo jugador que acceda a la pantalla para seleccionar un grupo intenta entrar en el del primero (grupo de un jugador que está lleno). Tras finalizar las pruebas, cada jugador selecciona un grupo disponible y confirma la elección. Resultados esperados En el primer caso el jugador no se une a ningún grupo, sino que aparece un mensaje de error indicando que ha de seleccionar un grupo. En el segundo caso la operación se realiza correctamente informando del éxito a través de un mensaje. Tabla 4.9: Descripción de la tarea Tolerancia a errores al unirse a un grupo Tarea 10 Descripción de la tarea Tolerancia a errores al responder una cuestión Descripción Cuando se inicia una partida, los jugadores acceden a una pantalla donde se encuentra la primera cuestión con sus respectivas opciones y un chat. Para responder una cuestión es necesario marcar una respuesta y escribir un argumento. Requisitos previos La partida tiene que haber comenzado. Acciones de los moderadores Tras confirmar el inicio de partida, el moderador accede a la pantalla de Dashboard, desde donde monitoriza la actividad de cada jugador. Flujo En la primera partida, se realizan las siguientes pruebas: El primer jugador que accede a la sala intenta enviar una respuesta a la primera cuestión sin haber marcado ninguna opción. El mismo jugador marca una opción, pero no especifica ningún argumento. El jugador en cuestión elige una opción e introduce su respectivo argumento confirmando el envío. 56 4.2. PRUEBAS DE ROBUSTEZ Plan de pruebas Descripción de la tarea Tolerancia a errores al responder una cuestión Tarea 10 Descripción de la tarea Tolerancia a errores al responder una cuestión Resultados esperados En los dos primeros casos se espera que no se envíe ninguna respuesta, sino que aparezcan mensajes de error especificando la necesidad de marcar una opción o introducir un argumento. En el caso de marcar una opción e introducir un argumento, se espera que el registro se realice correctamente y se pase a la siguiente cuestión. Tabla 4.10: Descripción de la tarea Tolerancia a errores al responder una cuestión Tarea 11 Descripción de la tarea Tolerancia a errores al enviar un mensaje Descripción Cuando se inicia una partida, los jugadores acceden a una pantalla donde se encuentra la primera cuestión con sus respectivas opciones y un chat destinado a debatir. Requisitos previos La partida tiene que haber comenzado. Acciones de los moderadores Tras confirmar el inicio de partida, el moderador accede a la pantalla de Dashboard, desde donde monitoriza la actividad de cada jugador. Flujo En la primera partida, se realizan las siguientes pruebas: El segundo jugador que accede a la sala intenta enviar un mensaje en la primera cuestión dejando el campo del formulario en blanco. El mismo jugador introduce un mensaje en el formulario y lo envía. Resultados esperados En el primer caso no se envía ningún mensaje, sino que se muestra un error indicando la necesidad de rellenar el campo correspondiente. En el caso de enviar un mensaje correctamente se muestra en el chat, siendo visible para los miembros indicados. Tabla 4.11: Descripción de la tarea Tolerancia a errores al enviar un mensaje En la primera partida, ambos jugadores responden a todas las preguntas accediendo a la pantalla en la que aparece la tabla que contiene las respuestas de cada uno para las diferentes cuestiones. Puesto que de las pruebas asociadas a robustez se encarga una única persona, esta última se asegura de que existe al menos un conflicto. El primer jugador que se une a la sala realiza las mismas pruebas de tolerancia a errores en lo que respecta a responder cuestiones y enviar mensajes a través de chat seleccionando una de las “X” y accediendo a la pantalla utilizada para resolver conflictos de la cuestión correspondiente. 57 4.3. PRUEBAS DE COMPATIBILIDAD Plan de pruebas 4.3. Pruebas de compatibilidad A.-Objetivo La siguiente sesión consiste en una serie de pruebas asociadas a compatibilidad de la aplicación con los navegadores Google Chrome, Microsoft Edge, Mozilla Firefox en tres sistemas operativos diferentes: Windows 10, Ubuntu 20.4 y macOS, con el fin de comprobar que la aplicación funciona adecuadamente en cada uno de ellos. B.-Responsables Las pruebas de compatibilidad en los sitemas operativos Ubuntu 20.4 y Windows 10 las realiza un miembro asociado al equipo de investigación (que también desempeña el rol de informante). Por otro lado, un segundo miembro implicado en las pruebas de estabilidad se encarga de informar sobre la compatibilidad en el sistema operativo macOS. C.-Recursos e instrumentos de evaluación Timing: Tras haber comprobado que el grado de robustez es adecuado. Duración aproximada: 60 minutos. Escenario: Estudio controlado, distribuido en los entornos de trabajo asociados a cada participante. Como se ha mencionado,se ejecuta la aplicación en tress sistemas operativos diferentes (Windows 10 ,Ubuntu 20.04 y macOS). Para ello, se recurre a la utilización de un equipo con Windows 10, otro con macOS y una máquina virtual cuyo sistema operativo es Ubuntu 20.04. La máquina virtual cuenta con las siguientes características: 4 GB de memoria RAM Un procesador Disco de 10 GB de almacenamiento El miembro del equipo de investigación que realiza las tareas en las pruebas de estabilidad utilizando macOS comunica los resultados obtenidos. A continuación, se muestran todos los instrumentos de evaluación utilizados en las pruebas de compatibilidad: 1. Formularios de Google Forms: a)Formulario para jugadores 58 4.3. PRUEBAS DE COMPATIBILIDAD Plan de pruebas b)Formulario para moderador 2. Documentos PDF que contienen los resultados 3. Registros en la base de datos: Para medir el rendimiento, se procederá a comparar las marcas de tiempo registradas en las tablas correspondientes de la base de datos mySQL. Concretamente, se tendrán en cuenta las marcas almacenadas en las tablas “choice”, “message”, “room”, “round”. D.-Informantes En esta ocasión, el papel de informante lo desempeñan ambos miembros implicados en la realización de pruebas. El primer miembro mencionado ha recogido la información en una encuesta de Google Forms, mientras que el segundo utiliza el sistema operativo macOs en las pruebas anteriores donde ha participado (existiendo como evidencia la grabación de las mismas). E.-Protocolo y tareas Durante la sesión de pruebas asociadas a compatibilidadtienen lugar las partidas mostradas a continuación: Partida con un grupo de dos jugadores y dos rondas para poder realizar pruebas relacionadas con resolución de conflictos (tanto automática como por parte de los propios jugadores).No se ha contemplado un caso “extremo” con una mayor cantidad de participantes puesto que el objetivo de las pruebas es comprobar la compatibilidad de la aplicación con varios navegadores y sistemas operativos. Partida con dos grupos de un único jugador y una sola ronda. Se trata de una partida breve para comprobar que el sistema operativo y/o navegador en cuestión presenta adecuadamente los resultados obtenidos por varios grupos en una partida. Partida con un único jugador y una ronda. . Las pruebas en las que se utiliza Windows 10 y Ubuntu 20.04 se realizan utilizando los navegadores: Prueba con Google Chrome Prueba con Mozilla Firefox Prueba con Microsoft Edge 59 4.3. PRUEBAS DE COMPATIBILIDAD Plan de pruebas Por otro lado, el miembro vinculado al grupo de investigación encargado de realizar pruebas con macOS utiliza Mozilla Firefox. A raíz de la división de roles establecida, se distinguen las siguientes actividades a realizar durante cada una de las pruebas distinguidas: Tareas realizadas por el moderador Tarea 1 Creación de sala Descripción El moderador cuenta con la posibilidad de crear salas de juego a las que se unirán los jugadores. Requisitos previos El moderador debe haberse registrado previamente en el sistema o iniciado sesión. Acciones del jugador El jugador se mantiene en espera hasta recibir el código para entrar en la sala. Flujo 1.El moderador elige la opción “Organizar partida” . 2.Una vez seleccionada la opción correspondiente, accede a un formulario con cuatro campos campos (ver figura 3.5):Nombre de la sala, número de rondas, número de grupos y tamaño del grupo. Además, existe una casilla para determinar si los jugadores son quienes deciden a qué grupo de la sala unirse o se les asigna uno aleatorio. Dicha opción estará disponible en versiones futuras (ver figura 3.5) 60 4.3. PRUEBAS DE COMPATIBILIDAD Plan de pruebas Creación de sala Tarea 1 Creación de sala 3.El moderador crea una sala introduciendo la información correspondiente en el formato correcto. Esta tarea se realizará en tres ocasiones introduciendo la siguiente información: Primera iteración: Nombre de la sala: Primera prueba compatibilidad. Número de rondas: Dos Número de grupos: Uno Tamaño de grupo: Dos Segunda iteración: Nombre de la sala: Segunda prueba compatibilidad. Número de rondas: Una Número de grupos: Dos Tamaño de grupo: Uno Tercera iteración: Nombre de la sala: Tercera prueba compatibilidad. Número de rondas: Uno Número de grupos: Uno Tamaño de grupo: Uno Resultado esperado Tiene que ser posible la creación de salas producirse ningún error, redireccionando una pantalla de espera (véase la figura 3.5) para el moderador. En lo que respecta a rendimiento, la situación ideal es comprobar que el registro de información tarda en realizarse a lo sumo dos segundos. Tabla 4.12: Descripción de la tarea Creación de sala Tarea 2 Inicio de partida Descripción Una vez se hayan unido todo los jugadores a una sala de juego, es el moderador el encargado de iniciar la partida. Requisitos previos El moderador debe haber creado una sala de juego y los jugadores se tienen que haber unido. 61 4.3. PRUEBAS DE COMPATIBILIDAD Plan de pruebas Inicio de partida Tarea 2 Inicio de partida Acciones de los jugadores El moderador facilita el código generado a cada jugador en voz alta y, mientras se encuentra en la sala de espera, los jugadores se unen a la sala introduciendo el código correspondiente, registrando sus datos y, finalmente, eligiendo el grupo al que se van a unir (ver tareas 10 y 11). Flujo 1.En la pantalla de espera, el moderador puede visualizar los datos de la sala, además de los jugadores que se han unido a ella. Si dicha cantidad coincide con el número máximo de jugadores especificados puede iniciar la partida eligiendo la opción correspondiente . 2.Una vez seleccionada la opción en cuestión, los jugadores acceden a la primera cuestión que han de responder, mientras que el moderador es redireccionado a la pantalla de dashboard(véase la figura 3.8). Resultado esperado Las partidas tienen que iniciarse correctamente redireccionando a las pantallas correspondientes sin producirse errores. En lo que respecta a rendimiento, la situación ideal es comprobar que la partida tarda en iniciarse a lo sumo dos segundos. Tabla 4.13: Descripción de la tarea Inicio de partida Tarea 3 Monitorización de estado Descripción Una vez iniciada la partida, el moderador puede monitorizar el estado de los jugadores seleccionando la ronda y grupo que desee inspeccionar. Requisitos previos Haber iniciado una partida. Acciones de los jugadores Mientras el moderador visualiza la pantalla de dashboard, los jugadores debaten y responden a cada una de las cuestiones, además de poder resolver conflictos en el caso de no existir consenso de respuestas (véase las tareas 9, 10 y 11 para más detalles). Flujo 1.El moderador selecciona la ronda de interés . 2.A continuación, se pulsa sobre el grupo que se desea monitorizar. Resultado esperado El estado de los jugadores tiene que visualizarse correctamente. En lo que respecta a rendimiento, la situación ideal es comprobar que la información tarda en mostrarse a lo sumo un segundo. Tabla 4.14: Descripción de la tarea Monitorización de estado 62 4.3. PRUEBAS DE COMPATIBILIDAD Plan de pruebas Tarea 4 Inicio de nueva ronda Descripción En las partidas que cuentan con más de una ronda es el moderador el que decide cuándo finaliza la actual comenzando la siguiente.Cada vez que termina una ronda, los jugadores son redireccionados a una pantalla de resultados y, tras haber transcurrido veinte segundos vuelven a la pantalla en la que figura la primera cuestión. Requisitos previos Se debe haber iniciado una partida. Acciones de los jugadores Cuando el moderador opta por iniciar una nueva ronda, los jugadores son redireccionados automáticamente a una pantalla donde figuran los resultados correspondientes a la ronda actual en forma de gráficos y puntuaciones. Transcurridos veinte segundos, regresan a la pantalla donde figura la primera cuestión con sus posibles respuestas. Flujo 1.En la pantalla de dashborad el moderador elige la opción “siguiente ronda” . 2.Los jugadores son redireccionados a la pantalla de resultados. Resultado esperado La ronda actual tiene que finalizar correctamente y comenzar la próxima. En lo que respecta a rendimiento, la situación ideal es comprobar que la información en la pantalla de resultados tarda en mostrarse a lo sumo cinco segundos. Tabla 4.15: Descripción de la tarea Inicio de nueva ronda Tarea 5 Finalización de partida Descripción El moderador es el encargado de decidir cuándo finaliza una partida permitiendo el acceso a una pantalla de resultados finales. Requisitos previos Se debe haber iniciado una partida. Acciones de los jugadores Cuando el moderador decide finalizar partida, todos los jugadores son redireccionados a la pantalla donde figuran los resultados de la ronda correspondiente y, transcurridos veinte segundos acceden a los leaderboards donde se muestran los mejores resultados de cada disciplina considerada. Flujo 1.En la pantalla de dashborad el moderador elige la opción “terminar” . 63 4.4. PRUEBAS DE ESTABILIDAD Plan de pruebas 2. Partida con un grupo de ocho personas y una sola ronda (20 minutos aproximados). El objetivo de la partida es hacer pruebas con una cantidad “extrema” de jugadores en un grupo. 3. Partida de ocho grupos de un jugador y una única ronda. (15 minutos aproximados). El objetivo de esta partida es realizar pruebas con una cantidad “extrema” de grupos y rondas. La sesión comienza con una pequeña explicación introductoria acerca de la aplicación Crossroads y sus principales objetivos. Acto seguido, se define el rol de cada participante informando de las pruebas a realizar y el modo de hacerlo. A raíz de la división de roles establecida, se distinguen las siguientes actividades a realizar: Tareas realizadas por el moderador Tarea 1 Creación de sala Descripción El moderador cuenta con la posibilidad de crear salas de juego a las que se unirán los jugadores. Requisitos previos El moderador debe haberse registrado previamente en el sistema o iniciado sesión. Acciones del jugador El jugador se mantiene en espera hasta recibir el código para entrar en la sala. Flujo 1.El moderador elige la opción “Organizar partida” . 2.Una vez seleccionada la opción correspondiente, accede a un formulario con cuatro campos campos (ver figura 3.5):Nombre de la sala, número de rondas, número de grupos y tamaño del grupo. Además, existe una casilla para determinar si los jugadores son quienes deciden a qué grupo de la sala unirse o se les asigna uno aleatorio. Dicha opción estará disponible en versiones futuras. 70 4.4. PRUEBAS DE ESTABILIDAD Plan de pruebas Creación de sala Tarea 1 Creación de sala 3.Se crea una sala introduciendo la información correspondiente en el formato correcto,concretamente: Esta tarea se realizara en tres ocasiones introduciendo la siguiente información: Primera iteración: Nombre de la sala: Sala de la primera partida Número de rondas: Dos Número de grupos: Cuatro Tamaño de grupo: Dos Segunda iteración: Nombre de la sala: Sala de la segunda partida Número de rondas: Una Número de grupos: Uno Tamaño de grupo: Cuatro Tercera iteración: Nombre de la sala: Sala de la tercera partida Número de rondas: Tres Número de grupos: Ocho Tamaño de grupo: Uno Resultado esperado Tiene que ser posible la creación de salas producirse ningún error, redireccionando una pantalla de espera (véase la figura 3.5) para el moderador. En lo que respecta a rendimiento, la situación ideal es comprobar que el registro de información tarda en realizarse a lo sumo dos segundos. Tabla 4.23: Descripción de la tarea Creación de sala Tarea 2 Inicio de partida Descripción Una vez se hayan unido todo los jugadores a una sala de juego, es el moderador el encargado de iniciar la partida. Requisitos previos El moderador debe haber creado una sala de juego y los jugadores se tienen que haber unido. 71 4.4. PRUEBAS DE ESTABILIDAD Plan de pruebas Inicio de partida Tarea 2 Inicio de partida Acciones de los jugadores El moderador facilita el código generado a cada jugador en voz alta y, mientras se encuentra en la sala de espera, los jugadores se unen a la sala introduciendo el código correspondiente, registrando sus datos y, finalmente, eligiendo el grupo al que se van a unir (ver tareas 10 y 11). Flujo 1.En la pantalla de espera, el moderador puede visualizar los datos de la sala, además de los jugadores que se han unido a ella. Si dicha cantidad coincide con el número máximo de jugadores especificados puede iniciar la partida eligiendo la opción correspondiente . 2.Una vez seleccionada la opción en cuestión, los jugadores acceden a la primera cuestión que han de responder, mientras que el moderador es redireccionado a la pantalla de dashboard(véase la figura 3.8). Resultado esperado Las partidas tienen que iniciarse correctamente redireccionando a las pantallas correspondientes sin producirse errores. En lo que respecta a rendimiento, la situación ideal es comprobar que la partida tarda en iniciarse a lo sumo dos segundos. Tabla 4.24: Descripción de la tarea Inicio de partida Tarea 3 Monitorización de estado Descripción Una vez iniciada la partida, el moderador puede monitorizar el estado de los jugadores seleccionando la ronda y grupo que desee inspeccionar. Requisitos previos Haber iniciado una partida. Acciones de los jugadores Mientras el moderador visualiza la pantalla de dashboard, los jugadores debaten y responden a cada una de las cuestiones, además de poder resolver conflictos en el caso de no existir consenso de respuestas (véase las tareas 9, 10 y 11 para más detalles). Flujo 1.El moderador selecciona la ronda de interés . 2.A continuación, se pulsa sobre el grupo que se desea monitorizar. Resultado esperado El estado de los jugadores tiene que visualizarse correctamente. En lo que respecta a rendimiento, la situación ideal es comprobar que la información tarda en mostrarse a lo sumo un segundo. Tabla 4.25: Descripción de la tarea Monitorización de estado 72 4.4. PRUEBAS DE ESTABILIDAD Plan de pruebas Tarea 4 Inicio de nueva ronda Descripción En las partidas que cuentan con más de una ronda es el moderador el que decide cuándo finaliza la actual comenzando la siguiente.Cada vez que termina una ronda, los jugadores son redireccionados a una pantalla de resultados y, tras haber transcurrido veinte segundos vuelven a la pantalla en la que figura la primera cuestión. Requisitos previos Se debe haber iniciado una partida. Acciones de los jugadores Cuando el moderador opta por iniciar una nueva ronda, los jugadores son redireccionados automáticamente a una pantalla donde figuran los resultados correspondientes a la ronda actual en forma de gráficos y puntuaciones. Transcurridos veinte segundos, regresan a la pantalla donde figura la primera cuestión con sus posibles respuestas. Flujo 1.En la pantalla de dashborad el moderador elige la opción “siguiente ronda” . 2.Los jugadores son redireccionados a la pantalla de resultados. Resultado esperado La ronda actual tiene que finalizar correctamente y comenzar la próxima. En lo que respecta a rendimiento, la situación ideal es comprobar que la información en la pantalla de resultados tarda en mostrarse a lo sumo cinco segundos. Tabla 4.26: Descripción de la tarea Inicio de nueva ronda Tarea 5 Finalización de partida Descripción El moderador es el encargado de decidir cuándo finaliza una partida permitiendo el acceso a una pantalla de resultados finales (véase la figura 3.12). Requisitos previos Se debe haber iniciado una partida. Acciones de los jugadores Cuando el moderador decide finalizar partida, todos los jugadores son redireccionados a la pantalla donde figuran los resultados de la ronda correspondiente y, transcurridos veinte segundos acceden a los leaderboards donde se muestran los mejores resultados de cada disciplina considerada. Flujo 1.En la pantalla de dashborad el moderador elige la opción “terminar” . 73 4.4. PRUEBAS DE ESTABILIDAD Plan de pruebas Finalización de partida Tarea 5 Finalización de partida 2.Los jugadores son redireccionados a la pantalla de resultados relacionada con la ronda actual. Veinte segundos después pueden visualizar el leaderboard donde figuran los resultados de los mejores grupos en cada disciplina. La primera partida finaliza tras haberse resuelto los conflictos existentes en la segunda ronda (véase la tarea 11 para más detalles). La segunda partida termina junto con la única ronda (se espera que los conflictos mencionados en la tarea 11 se resuelvan a través del debate de jugadores). Finalmente, la tercera partida también concluye al finalizar la ronda, con la salvedad de que no existirán conflictos al implicar a un único jugador. Resultado esperado La ronda actual tiene que finalizar correctamente y comenzar la próxima. En lo que respecta a rendimiento, la situación ideal es comprobar que la información en las pantallas de resultados tarda en realizarse a lo sumo dos segundos. Tabla 4.27: Descripción de la tarea Finalización de partida Tarea 6 Descarga de documento PDF Descripción El moderador cuenta con la posibilidad de descargar un documento PDF con los resultados de la partida. Requisitos previos Se debe haber finalizado una partida. Acciones de los jugadores Mientras el moderador descarga el documento PDF, los jugadores se encuentran visualizando la pantalla final de resultados. Flujo 1.En la pantalla de dashborad el moderador elige la opción “imprimir PDF” . 2.Una vez elegida la opción, el moderador visualiza el informe en pantalla. Resultado esperado El moderador debe poder ver el informe en pantalla. Tabla 4.28: Descripción de la tarea Descargar PDF Tareas del jugador Una vez expuestas las tareas que realiza el moderador, se procede a mostrar aquellas que son características del jugador. 74 4.4. PRUEBAS DE ESTABILIDAD Plan de pruebas Tarea 7 Unirse a una sala Descripción Los jugadores han de unirse a salas de juego introduciendo un código facilitado por el moderador.Dicho código se genera una vez se haya iniciado la partida. Requisitos previos El moderador tiene que haber creado una partida. Acciones del moderador Mientras los jugadores se unen a la sala, el moderador se encuentra en la sala de espera, ya que la partida no puede comenzar hasta que todos los jugadores se hayan unido a un grupo. Flujo 1.El jugador elige la opción “participar en juego” . 2.Una vez seleccionada la opción correspondiente, se accede a un formulario con un único campo en el que introduce el código (véase la figura 3.6). Si el código es correcto, el jugador será redireccionado a un formulario de registro. Resultado esperado El jugador debe poder acceder correctamente al formulario de introducción de sus datos. En lo que respecta a rendimiento, la situación ideal es que el tiempo empleado en validar el código introducido sea a lo sumo de un segundo. Tabla 4.29: Descripción de la tarea Unirse a una sala Tarea 8 Registrar jugador Descripción Una vez se hayan unido a la sala, los jugadores tienen que registrarse rellenando un formulario. Requisitos previos El jugador tiene que haberse unido a una sala. Acciones del moderador Mientras los jugadores se registran y se unen a un grupo, el moderador se encuentra en la sala de espera, ya que la partida no puede comenzar hasta que todos los jugadores hayan seleccionado un grupo. Flujo 1.El jugador accede a un formulario con tres campos (nombre, país y edad), que ha de introducir para poder unirse a un grupo . 2.Rellena el formulario con la información correspondiente. 75 4.4. PRUEBAS DE ESTABILIDAD Plan de pruebas Registrar jugador Tarea 8 Registrar jugador Resultado esperado El jugador debe poder registrarse correctamente. En lo que respecta a rendimiento, la situación ideal es que el tiempo empleado en realizar el registro sea a lo sumo de dos segundos.Una vez completado el registro, cada jugador es redireccionado a una pantalla de espera donde se selecciona el grupo al que se deseen unir. En la primera partida existen dos grupos (grupo 1 y grupo 2). Cada grupo contará con dos jugadores, distribuyéndose de la siguiente forma: Grupo 1: Jugador 1, jugador 2 Grupo 2: Jugador 3, jugador 4 Grupo 3: Jugador 5, jugador 6 Grupo 4: Jugador 7, jugador 8 La segunda partida cuenta con un solo grupo de cuatro personas. Por último, en la tercera partida existen ocho grupos de un solo jugador. Tabla 4.30: Descripción de la tarea Registrar jugador Tarea 9 Responder cuestión Descripción Cuando el moderador inicia una partida, los jugadores son redirigidos a una pantalla en la que aparece la primera cuestión con sus posibles respuestas (véase la figura 3.9).Cada jugador elige la respuesta que cree más razonable y argumenta el motivo de su elección.Cuando terminan de contestar, en el caso de que todos hayan llegado a un consenso, se calculan las puntuaciones, redireccionando automáticamente a los jugadores a la pantalla de resultados asociados a la ronda actual. Requisitos previos El moderador tiene que haber iniciado una partida. Acciones del moderador Mientras los jugadores responden cuestiones, el moderador se encuentra monitorizando sus estados en la pantalla de dashboard, esperando a que sean “esperando resultados” para finalizar la ronda o partida. Flujo 1.Tras iniciar la partida, los jugadores acceden a una pantalla donde figura la primera cuestión y un chat. 2.Los jugadores responden a cada cuestión argumentando la respuesta a través de un formulario que se despliega cuando seleccionan “siguiente”. 76 4.4. PRUEBAS DE ESTABILIDAD Plan de pruebas Responder cuestión Tarea 9 Responder cuestión Resultado esperado Las respuestas se han de almacenar correctamente, siendo la mejor situación en cuanto a rendimiento que cada registro se realice, a lo sumo en dos segundos, salvo si es necesario calcular puntuaciones. En dicha situación, el tiempo podría prolongarse hasta cinco segundos. Tabla 4.31: Descripción de la tarea Responder cuestión A medida que vayan respondiendo cuestiones, los jugadores seguirán los patrones de respuestas mostrados a continuación: Primera partida. Ronda 1 Grupo 1: •Jugador 1: Hipótesis 1:a; hipótesis 2:b; hipótesis 3:a; objetivo 1:c; objetivo 2:b; medida 1:c; medida 2:a; medida 3:b; medida 4:b; medida 5:a; medida 6:a; medida 7:c; medida 8:b; medida 9:c •Jugador 2: Hipótesis 1:b; hipótesis 2:b; hipótesis 3:a; objetivo 1:c; objetivo 2:b; medida 1:e; medida 2:a; medida 3:b; medida 4:b; medida 5:a; medida 6:a; medida 7:c; medida 8:b; medida 9:c Grupo 2: •Jugador 3: Hipótesis 1:b; hipótesis 2:c; hipótesis 3:c; objetivo 1:c; objetivo 2:a; medida 1:b; medida 2:b; medida 3:a; medida 4:a; medida 5:b; medida 6:a; medida 7:b; medida 8:b; medida 9:a •Jugador 4: Hipótesis 1:c; hipótesis 2:b; hipótesis 3:a; objetivo 1:a; objetivo 2:b; medida 1:a; medida 2:a; medida 3:b; medida 4:b; medida 5:a; medida 6:a; medida 7:a; medidqa 8:b; medida 9:c Grupo 3: •Jugador 5: Hipótesis 1:a; hipótesis 2:a; hipótesis 3:b; objetivo 1:b; objetivo 2:b; medida 1:a; medida 2:b; medida 3:b; medida 4:a; medida 5:b; medida 6:b; medida 7:a; medida 8:a; medida 9:b •Jugador 6: Hipótesis 1:a; hipótesis 2:c; hipótesis 3:b; objetivo 1:b; objetivo 2:b; medida 1:a; medida 2:a; medida 3:a; medida 4:a; medida 5:b; medida 6:b; medida 7:a; medida 8:b; medida 9:a Grupo 4: •Jugador 7: Hipótesis 1:a; hipótesis 2:a; hipótesis 3:b; objetivo 1:c; objetivo 2:b; medida 1:a; medida 2:a; medida 3:b; medida 4:a; medida 5:b; medida 6:b; medida 7:a; medida 8:a; medida 9:b 77 4.4. PRUEBAS DE ESTABILIDAD Plan de pruebas •Jugador 8: Hipótesis 1:a; hipótesis 2:c; hipótesis 3:b; objetivo 1 1:b; objetivo 2:c; medida 1:a; medida 2:a; medida 3:a; medida 4:a; medida 5:b; medida 6:b; medida 7:b; medida 8:a; medida 9:b Primera partida. Ronda 2 Grupo 1: •Jugador 1: Hipótesis 1:c; hipótesis 2:c; hipótesis 3:b; objetivo 1:a; objetivo 2:b; medida 1:e; medida 2:b; medida 3:a; medida 4:b; medida 5: b; medida 6:b; medida 7:a; medida 8:a; medida 9:c •Jugador 2: Hipótesis 1:c; hipótesis 2:c; hipótesis 3:b; objetivo 1:a; objetivo 2:b; medida 1:e; medida 2:b, medida 3:a; medida 3:b; medida 4:b; medida 5:b; medida 6:a; medida 7:a; medida 8:c Grupo 2: •Jugador 3: Hipótesis 1: b; hipótesis 2:a; hipótesis 3:b; objetivo 1:b; objetivo 2:a; medida 1:e; medida 2:a; medida 3:b; medida 4:a; medida 5:a; medida 6:b; medida 7:a; medida 8:a; medida 9:a •Jugador 4: Hipótesis 1:a; hipótesis 2:b; hipótesis 3:b; objetivo 1:b; objetivo 2:a; medida 1:e; medida 2:b; medida 3:a; medida 4:b; medida 5:b; medida 6:b; medida 7:b; medida 8:a; medida 9:c Grupo 3: •Jugador 5: Hipótesis 1:a; hipótesis 2:a; hipótesis 3:c; objetivo 1:c; objetivo 2:a; medida 1:b; medida 2:a; medida 3:b; medida 4:a; medida 5:a; medida 6:b; medida 7:a; medida 8:a; medida 9:a •Jugador 6: Hipótesis 1:a; hipótesis 2:a; hipótesis 3:c; objetivo 1:c;objetivo 2:a; medida 1:b; medida 2:a; medida 3:b; medida 4:a; medida 5:a; medida 6:b; medida 7:a; medida 8:a; medida 9:a Grupo 4: •Jugador 7: Hipótesis 1:b; hipótesis 2:a; hipótesis 3:a; objetivo 1:c; objetivo 2:a; medida 1:b; medida 2:a; medida 3:b; medida 4:a; medida 5:a; medida 6:b; medida 7:a; medida 8:a; medida 9:a •Jugador 8: Hipótesis 1:a; hipótesis 2:a; hipótesis 3:a; objetivo 1:c; objetivo 2:a; medida 1:b; medida 2:a; medida 3:b; medida 4:a; medida 5:a; medida 6:b; medida 7:b; medida 8:a; medida 9:c Segunda partida 78 4.4. PRUEBAS DE ESTABILIDAD Plan de pruebas Jugador 1: Hipótesis 1:c; hipótesis 2:a; hipótesis 3:b; objetivo 1:a; objetivo 2:a; medida 1:e,medida 2:a; medida 3:b; medida 4:b; medida 5:a; medida 6:b; medida 7:b; medida 8:a; medida 9:c Jugador 2: Hipótesis 1:c; hipótesis 2 :b; hipótesis 3:b; objetivo 1:a; objetivo 2:a; medida 1:e; medida 2:a; medida 3:b; medida 4:b; medida 5:b; medida 6:b; medida 7:a; medida 8:a; medida 9:c Jugador 3: Hipótesis 1:c; hipótesis 2:a; hipótesis 3:b; objetivo 1:a; objetivo 2:a; medida 1:e; medida 2:a; medida 3:b; medida 4:b; medida 5:a; medida 6:b; medida 7:b; medida 8:a; medida 9:c Jugador 4: Hipótesis 1: c; hipótesis 2:c; hipótesis 3:b; objetivo 1:a; objetivo 2:a; medida 1:e; medida 2:a; medida 3:b; medida 4:b; medida 5:b; medida 6:b; medida 7:a; medida 8:a; medida 9:c Jugador 5: Hipótesis 1:c; hipótesis 2:b; hipótesis 3:b; objetivo 1:a; objetivo 2:a; medida 1:e; medida 2:a; medida 3:b; medida 4:b; medida 5:a; medida 6:b; medida 7:b; medida 8:a; medida 9:c Jugador 6: Hipótesis 1:c; hipótesis 2:a; hipótesis 3:b; objetivo 1:a; objetivo 2:a; medida 1:e; medida 2:a; medida 3:b; medida 4:b; medida 5:a; medida 6:b; medida 7:b; medida 8:a; medida 9:c Jugador 7: Hipótesis 1:c; hipótesis 2:a; hipótesis 3:a; objetivo 1:a; objetivo 2:a; medida 1:c; medida 2:a; medida 3:b; medida 4:b; medida 5:a; medida 6:b; medida 7:b; medida 8:a; medida 9:c Jugador 8: Hipótesis 1:a; hipótesis 2:a; hipótesis 3:b; objetivo 1:a; objetivo 2:a; medida 1:e; medida 2:a; medida 3:b; medida 4:b; medida 5:a; medida 6:b; medida 7:b; medida 8:b; medida 9:b Última partida El patrón de respuestas elegido por cada jugador es aleatorio al tratarse de una partida cuyo objetivo es probar la aplicación con una cantidad atípica de grupos y rondas. Los patrones de respuestas en las dos primeras partidas se han elegido conforme a los siguientes criterios: Primera partida: Varias combinaciones de resultados basadas en el alcance de objetivos: Resultados de temperatura que no sobrepasan los objetivos establecidos en la primera ronda (en el caso del PIB el objetivo se rebasa en periodos determinados, al oscilar entre 5000 y 6000 el mínimo valor asociado a objetivos y tratarse de una función parabólica ascendente en un inicio y descendente tras alcanzar un máximo), un segundo patrón con resultados que sobrepasan en un momento determinado dichos objetivos tanto para PIB como para temperatura y, finalmente, un patrón cuyos 79 4.5. PRUEBAS CON USUARIOS FINALES Plan de pruebas • Una puntuación de 1 indica que el encuestado no está para nada de acuerdo con la afirmación reflejada en la cuestión. • Si la puntuación dada es de 2 significa que el encuestado está poco de acuerdo con la afirmación, sin rechazar completamente todas las ideas expuestas (pero sí la gran mayoría). • Una calificación de 3, es sinónimo de estar medianamente de acuerdo con la afirmación. • En el caso de que la puntuación dada sea 4 significa que el encuestado está de acuerdo con prácticamente la totalidad de las ideas expuestas en la afirmación correspondiente. • Finalmente, una puntuación de 5 es el equivalente a estar completamente de acuerdo con el enunciado. 3. Preguntas específicas: Abarca cuestiones relacionadas con metáforas y funcionalidades, así como los mecanismos de interacción. Las preguntas especificadas que hacen referencia a terminología empleada para definir diferentes elementos a tener en cuenta en una partida (sala, grupo, sala de espera, etc), así como aquellas vinculadas al modo en el que los usuarios intervienen en el sistema en función de su rol para realizar las diferentes tareas guardan relación con la dimensión asociada a la facilidad de aprendizaje. Por otro lado, también se incluyen cuestiones relacionadas con la evaluación de la dimensión engaging, concretamente las relacionadas con la forma de presentar la existencia o ausencia de consenso en respuestas. 4. Valoración general sobre la versión presentada: Finalmente, en este apartado se exponen cuestiones relacionadas con la dimensión de eficacia a la hora de comprobar si se comprende el objetivo de la aplicación, así como su público objetivo. Por otro lado, vuelve a estar presente la facilidad de aprendizaje a la hora de evaluar la comprensión de estados, secuencias y tareas a realizar en la aplicación. Existen cuestiones relacionadas con la dimensión engaging relacionadas mayoritariamente con la presentación de información en pantalla, además de tener presente la tolerancia a errores en el caso de que algún participante detecte algún inconveniente a la hora de utilizar la aplicación, proporcionando retroalimentación acerca del grado de facilidad con el que haya reuelto el error en cuestión. Como sucede en el caso de la segunda sección, tanto el apartado de preguntas específicas como el asociado a valoración general sobre la versión presentada se basan en el empleo de una escala de uno a cinco para definir una calificación en las diferentes cuestiones. Registros en la base de datos: Para medir el rendimiento y reforzar la evaluación de la eficiencia, se procederá a comparar las marcas de tiempo registradas en las 86 4.5. PRUEBAS CON USUARIOS FINALES Plan de pruebas tablas correspondientes de la base de datos mySQL. Concretamente, se tienen en cuenta las marcas almacenadas en las tablas “choice”, “message”, “room”, “round”. De esa forma, se podrá averiguar el tiempo dedicado a la realización de cada tarea. Documentos PDF que contienen los resultados de cada partida. D.-Informantes En esta sesión de pruebas los participantes son siete miembros del equipo de investigación GEEDS. E.-Protocolo y tareas En primer lugar, es necesario tener presentes las partidas que se llevan a cabo durante la sesión: 1. Partida con cuatro grupos de dos miembros cada uno y una única ronda. (Duración aproximada:20 minutos). El propósito principal de esta partida es permitir a los miembros del equipo GEEDS utilizar y evaluar las formas de reflejar y resolver conflictos entre jugadores en el caso de existir, recogiendo además comentarios de calidad que puedan tenerse en cuenta para desarrollar y documentar versiones futuras de la aplicación. 2. Partida con ocho grupos de una persona y una ronda. (Duración aproximada:10 minutos). El objetivo principal de esta partida es permitir a los participantes ver el funcionamiento asociado a la modalidad del juego donde todos compiten entre sí, sin trabajar en equipo. En ambas partidas, todos los miembros del equipo GEEDS desempeñan el rol de jugador uniéndose a uno de los grupos creados, mientras que un miembro del grupo de investigación vinculado con el proyecto es el componente que actúa como moderador, un segundo componente del grupo en cuestión también actúa como jugador para poder formar grupos con un número par de personas y el miembro restante del grupo el que ejerce el rol de observador con el objetivo de anotar tiempos y aspectos relevantes. Durante los primeros minutos de la sesión, se presenta brevemente la aplicación (puesto que el equipo GEEDS ya vio su funcionamiento en la reunión realizada durante el pasado día 4 de junio de 2021). A continuación, se solicita a los miembros del equipo GEEDS rellenar una encuesta inicial. Tras completar dicha encuesta comienza el periodo de utilización de la aplicación jugándose las dos partidas indicadas. En ambas partidas, tras recibir el código del moderador los jugadores comienzan a utilizar la aplicación. La idea principal es que los participantes puedan jugar recibiendo la menor cantidad de indicaciones posible (aunque cuentan con la posibilidad de contactar con el 87 4.5. PRUEBAS CON USUARIOS FINALES Plan de pruebas moderador en el caso de encontrarse con un inconveniente significativo que les impida avanzar, así como expresar en voz alta sus opiniones sobre diferentes aspectos de la aplicación). En lo que respecta a la posible necesidad de resolver conflictos presente en la primera partida, se solicita al moderador que finalice la partida cuando el estado de todos los jugadores sea “resultados de ronda obtenidos”, siendo la idea principal permitir el debate y resolución de conflictos por parte de los jugadores. Conforme avanza la partida, los jugadores pueden hacer preguntas y transmitir tanto opiniones como sugerencias en voz alta. Tras finalizar la fase de pruebas de la aplicación, se entrega a cada participante del equipo GEEDS una encuesta final que han de responder y enviar en un máximo de dos días. Resultados esperados Se espera que los participantes puedan identificar y llevar a cabo cualquier funcionalidad de la aplicación en el menor tiempo posible. Atendiendo a la cantidad de pulsaciones necesarias en el ratón, es conveniente que dicha cifra no sea superior a tres en la ejecución de cualquier función. En el caso de producirse algún error, es importante que los propios participantes sean capaces de resolverlo sin intervención del componente vinculado al grupo de investigación del proyecto, desempeñando un papel clave el lenguaje utilizado a la hora de mostrar los mensajes correspondientes y otros aspectos relacionados con la ya mencionada dimensión de tolerancia a errores (ver apartado 2.1) como la capacidad de recuperación asociada al sistema en el caso de producirse un problema, como el cierre no intencionado del navegador. Sesiones de pruebas con estudiantes de ingeniería que se realizarán en un futuro A.-Objetivo El último grupo de pruebas relacionadas con usuarios finales a contemplar es un conjunto de sesiones realizados en centros de educación con estudiantes de ingeniería, siendo el principal objetivo poder utilizar la aplicación en entornos similares a los de su futura implantación. B.-Responsables Dos miembros del equipo de investigación asociados al proyecto. C.-Recursos e intrumentos de evaluación Duración aproximada de cada sesión: 60 minutos Timing: Tras haber resuelto inconvenientes detectados relacionados con la escalabilidad. 88 4.5. PRUEBAS CON USUARIOS FINALES Plan de pruebas Escenario: Cada sesión será un estudio de campo que se desarrollará en laboratorios con conexión a Internet de centros educativos situados en Valladolid proporcionando a cada alumno un PC. Todas las sesiones serán presenciales y, con previo consentimiento, se grabarán en vídeo. Roles desempeñados Durante cada una de las sesiones se jugará una única partida en la que se distingan cuatro grupos de cinco personas, desempeñando cada uno de los estudiantes el rol de jugador, mientras que un miembro del grupo de investigación se encargará de interpretar el papel de moderador. El miembro restante del grupo de investigación ayudará al moderador a responder cuestiones que surjan a los jugadores conforme se desarrolla la partida. Instrumentos de evaluación utilizados y dimensiones evaluadas Los instrumentos utilizados son similares a los especificados en la descripción de la prueba que implica desarrolladores ajenos al proyecto, concretamente: Observación directa y grabación Tal y como se ha mencionado a la hora de describir las sesiones anteriores, la observación directa y grabación de sesión son instrumentos clave a la hora de recabar información inicial para poder analizar cada dimensión expuesta en el apartado 2.1. Encuesta previa (duración aproximada de diez minutos): De nuevo, la encuesta que se proporciona al inicio de la sesión seguirá el mismo esquema que la utilizada en las sesiones con desarrolladores y personas menos familiarizadas con las nuevas tecnologías, siendo el principal objetivo recoger información que será contrastada con los resultados obtenidos tras finalizar la partida, haciendo hincapié en la evaluación de la eficacia. Encuesta posterior: Siguiendo de nuevo la misma estructura que la encuesta de las sesiones en las que estarán implicados desarrolladores o personas poco familiarizadas con las nuevas tecnologías, contando con cuestiones que también se encuentran en la encuesta inicial para realizar comparaciones útiles a la hora de evaluar la dimensión de eficacia, preguntas relacionadas con la utilización de la aplicación donde se contemplan las diferentes dimensiones a tener en cuenta y cuestiones finales asociadas a la utilización de los videojuegos para favorecer el aprendizaje sobre el cambio climático. En la encuesta sigue la misma estructura que la utilizada para realizar pruebas de usabilidad con el grupo de investigadores GEEDS. Registros en la base de datos: Para medir el rendimiento y reforzar la evaluación de la eficiencia, se procede a comparar las marcas de tiempo registradas en las tablas correspondientes de la base de datos mySQL. Concretamente, se tienen en cuenta las marcas almacenadas en las tablas “choice”, “message”, “room”, “round”. De esa forma, se podrá averiguar el tiempo dedicado a la realización de cada tarea. 89 4.5. PRUEBAS CON USUARIOS FINALES Plan de pruebas Una vez obtenidas las marcas temporales correspondientes, se procede a evaluar el rendimiento de cada actividad en comparación de la actividad educativa que tuvo lugar durante el día 4 de junio de 2021 (véase el apartado 1.1) para más detalles. A la hora de analizar el rendimiento, las diferentes actividades se incluyen en uno de los grupos mostrados a continuación: 1. Actividades relacionadas con explicación de aspectos clave vinculados a la aplicación: Abarca la introducción inicial a los objetivos perseguidos por la aplicación, así como las intervenciones que realice el participante vinculado al proyecto en el caso de ser necesaria alguna aclaración importante durante el transcurso de las partidas. Puesto que los procedimientos mencionados no se registran en la base de datos, se medirá el tiempo empleado reproduciendo la grabación de la sesión. 2. Actividades de preparación: Se trata de las operaciones necesarias para obtener los recursos que permitan iniciar las diferentes partidas, así como visualizar los resultados finales. En este grupo se incluyen las tareas relacionadas con el registro e inicio de sesión del moderador, así como la creación de salas y la entrada a las mismas por parte de los jugadores escribiendo el código correspondiente, registrando sus datos y seleccionando un grupo disponible. En versiones futuras esta última opción estará disponible solo si no se opta por la asignación aleatoria de grupos marcando la casilla correspondiente. La tabla donde se guardan los datos de la sala cuenta con su propia marca temporal, siendo un atributo apreciable también en el caso de la tabla round, donde se almacena la información de las diferentes rondas para cada partida. Comparando ambas marcas (además de tener presente el tiempo dedicado a la explicación inicial) se puede estimar de forma aproximada el tiempo total dedicado a las operaciones iniciales de preparación. En lo que respecta a obtención de resultados, es importante tener en cuenta tanto los resultados de ronda como los asociados a una determinada partida.Para ello se tendrá en cuenta la marca temporal que figura como atributo en la tabla results_in_iteration teniendo en cuenta que en dicha tabla se añade un registro cada vez que los jugadores llegan a un consenso durante una ronda de la partida (o bien si se opta por la resolución automática de conflictos mediante las opciones del moderador “Siguiente ronda” y ´´Terminar”. 3. Actividades que implican trabajo en grupo: Finalmente, este conjunto de actividades incluye todas aquellas operaciones relacionadas con debatir utilizando el chat y respondiendo cuestiones, ya sea por primera vez o para resolver conflictos en el caso de no existir consenso. Las opciones elegidas se guardan en una tabla de la base de datos denominada “choice”, la cual incluye un atributo (time_choice) que refleja la fecha y hora exactas en las que se ha guardado la respuesta. Además, en la tabla donde se almacenan los mensajes también se incluye un atributo que actúa como marca temporal, favoreciendo el análisis del tiempo 90 4.5. PRUEBAS CON USUARIOS FINALES Plan de pruebas destinado a interactuar en otras pantallas que no incluyan formularios para responder cuestiones (concretamente, en la pantalla donde se muestra la matriz de respuestas escogidas por cada jugador del grupo y la pantalla de resultados asociados a una ronda). Los tiempos se miden para cada una de las rondas en las que se dividan las diferentes partidas. Una vez obtenidos, se calculará la media de tiempos obtenidos para cada uno de los tres grupos de actividades establecidos y se reflejarán en una línea del tiempo similar a la que se muestra en la figura 4.13 (elaborada a partir de los tiempos empleados en la actividad educativa del seminario que tuvo lugar el cuatro de junio con profesores y alumnos del máster de Cooperación Internacional). Figura 4.13: Línea del tiempo elaborada a partir de las actividades realizadas durante la sesión del 4 de junio. En rojo se marca el tiempo dedicado a actividades de explicación, el color azul se corresponde con las actividades de preparación y las tonalidades beige reflejan el trabajo en grupo (todo expresado en minutos) Finalmente, se procede a comparar los resultados reflejados en ambas líneas del tiempo con el fin de poder representar y argumentar sobre el rendimiento de la aplicación, así como las posibles ventajas y/o inconvenientes presentados. En principio, se espera que la línea del tiempo elaborada muestre de forma gráfica las ventajas expuestas en el apartado 1.1, traduciéndose en un grado elevado de eficiencia. D.-Informantes En cada sesión participa un grupo de veinte estudiantes de ingeniería (concretamente alumnos de la asignatura “Tecnología y Sociedad”), los cuales se encargarán de proporcionar la información necesaria a través de los diferentes intrumentos de evaluación. E.-Protocolo y tareas De forma similar a las sesiones de prueba explicadas anteriormente, en primer lugar, se procederá a realizar una explicación introductoria en la que se hable del juego y los objetivos que persigue. A continuación, los estudiantes reciben una encuesta inicial en la que se recogerán sus puntos de vista iniciales sobre el tema en cuestión. Tras responder a la encuesta, se despliega la aplicación en todos los equipos dando a los estudiantes las instrucciones necesarias. Posteriormente, el moderador inicia sesión en el sistema y creará la sala de juego a la que se unirán los estudiantes facilitando a cada uno el código 91 4.5. PRUEBAS CON USUARIOS FINALES Plan de pruebas correspondiente. Un miembro del grupo de investigación desempeñará el rol de moderador creando una sala con cinco grupos de cuatro jugadores y dos rondas. Los jugadores se unen a los grupos disponibles y el moderador confirma el inicio de partida. Cada jugador accede a la pantalla con la primera cuestión y sus posibles respuestas, mientras que el moderador se encuentra en la pantalla de dashboard monitorizando el estado de cada jugador en las diferentes rondas. El moderador opta por finalizar la primera ronda seleccionando “Siguiente ronda” o “Terminar” cuando el estado de cada jugador sea “resultados de ronda obtenidos”, con la idea de permitir a los estudiantes debatir e intentar llegar a un consenso en el caso de existir conflictos. No obstante, si transcurren diecisiete minutos desde el inicio de la partida y el estado de los jugadores es “resolviendo conflictos”, el moderador recurrirá a la resolución automática obteniendo las opciones más votadas a través de la opción “siguiente ronda”. Al elegir dicha opción, los jugadores son redireccionados a la pantalla de resultados asociados a la ronda en cuestión. Transcurridos veinte segundos volverá a cargarse la pantalla con la primera cuestión. La resolución de posibles conflictos se lleva a cabo del mismo modo en la segunda ronda, salvo por el hecho de que el moderador tiene que pulsar el botón “terminar” cuando el estado de todos los jugadores sea “resultados de ronda obtenidos” o bien si se da el caso de que hayan transcurrido diecisiete minutos desde el inicio de la partida y el estado de los jugadores sea “resolviendo conflictos”. Resultados esperados Se espera que los participantes puedan identificar y llevar a cabo cualquier funcionalidad de la aplicación en el menor tiempo posible. Atendiendo a la cantidad de pulsaciones necesarias en el ratón, es conveniente que dicha cifra no sea superior a tres en la ejecución de cualquier función. En el caso de producirse algún error, es importante que los propios participantes sean capaces de resolverlo sin intervención de ningún miembro del grupo de investigación, desempeñando un papel clave el lenguaje utilizado a la hora de mostrar los mensajes correspondientes y otros aspectos relacionados con la ya mencionada dimensión de tolerancia a errores (ver apartado 2.1) como la capacidad de recuperación asociada al sistema en el caso de producirse un problema, como el cierre no intencionado del navegador. 92 5: Resultados En el presente capítulo, se procede a exponer los resultados obtenidos en cada una de las pruebas realizadas. 5.1. Presentación de mockups a usuarios en focus group El día 21 de marzo de 2021 tuvo lugar una sesión de prueba con un grupo de investigadores, profesores de institutos y universidades, con el fin de presentar un prototipo inicial de la aplicación a través de PowerPoint. Desarrollo Participantes En la sesión intervino el ya mencionado grupo de profesores e investigadores, así como dos miembros del grupo de investigación asociado al proyecto (David Escudero Mancebo y Yania Crespo González-Carvajal). Tabién cabe destacar que el exalumno del grado en Ingeniería Informática Lucas Matías González Calderón se encargó de elaborar una presentación PowerPoint que contiene los prototipo creado a través de una herramienta de mockups. Información recogida Se recogió la información necesaria a través de una encuesta realizada a cada participante sobre diferentes aspectos de la aplicación.Empleando una escala de 1 a 5 donde se refleja el grado de acuerdo con las diferentes afirmaciones reflejadas en cada cuestión (siendo 1 la calificación mínima y 5 la máxima). Observaciones y resultados El cuestionario utilizado cuenta con diversas secciones: 93 5.1. PRESENTACIÓN DE MOCKUPS A USUARIOS EN FOCUS GROUP Resultados 1. Perfil del encuestado Sección utilizada para recoger información relacionada con la profesión, sexo y experiencia en diferentes aspectos del juego para cada participante. Su finalidad principal es el tratamiento estadístico. En el caso de la presente prueba, se obtuvieron los resultados mostrados en las figuras 5.14,5.15,5.16: Figura 5.14: Actividad principal y rango de edad asociado a los encuestados Los encuestados fueron investigadores y profesores que imparten enseñanza en universidades o institutos, mayoritariamente con una edad superior a cuarenta años. 94 5.1. PRESENTACIÓN DE MOCKUPS A USUARIOS EN FOCUS GROUP Resultados Figura 5.15: Experiencia en temática de juego y juegos online multijugador para cada encuestado En estos resultados se refleja el primer aspecto importante a tener en cuenta: La relativamente escasa experiencia con videojuegos online multijugador en comparación de los conocimientos asociados a la temática de Crossroads 2.0. Este hecho ejerce una especial influencia en futuras cuestiones relacionadas con el diseño y presentación tanto de información como de opciones, siendo el equivalente en términos de dimensiones expuestas por Quesenbery [ 89 ] las relacionadas con facilidad de aprendizaje y engaging. No proporcionar los medios necesarios para comprender la mecánica de videojuego multijugador online en Crossroads 2.0 traería consigo el posible abandono de la aplicación por parte de un público no familiarizado con el ámbito de los videojuegos, tratándose de un indicio asociado a un futuro fracaso del proyecto. Para finalizar con esta sección, se preguntó a los encuestados por su género, siendo predominante el masculino. 95 5.2. PRUEBAS DE ROBUSTEZ Resultados 10. La forma en la que se muestra que se ha alcanzado un consenso es confusa. 11. Cuesta distinguir entre argumentos positivos o negativos. 12. Complejidad al retroceder en las opciones relacionadas con el alcance de consenso. 13. Mayor control sobre el chat por parte del moderador, pudiendo intervenir en el caso de detectar comportamientos inapropiados. 14. Necesidad de elaborar y contemplar la presentación de resultados. 15. Clasificación de las medallas en “oro, plata y broce” o bien definir logros en su lugar ( salvar al planeta, trabajo en equipo, eficacia, eficiencia, argumentador). 16. Solamente se separan los aspectos considerados más relevantes (logros y trabajo en equipo). 17. Al finalizar la partida se podría añadir elementos de juego relativos a la sala, puesta en común de resultados de los grupos, algún logro de sala, además de adjuntar una imagen o cuadro de texto cuando el profesor es el único que tiene ordenador porque si no se pierden los argumentos de los grupos. Es importante que en el caso de la unión a un juego por código de sala y sin recurrir al inicio de sesión se recojan datos (bien sea para cada . a lumno. o "participante", o en general por el "profesor/moderador") sobre el perfil de los jugadores para guardar datos: rango de edad o edad concreta , sexo, país de residencia, etc. 18. No debería ser necesario unirse al grupo en la versión con un ordenador por grupo. 19. En simulaciones apaece el término “Ronda”. 20. en la opción de simulación, lugar de “buscar sala” y “crear sala” incluir el nombre del escenario correspondiente. Recomendaciones al analista 1. Especificar los datos personales de cada usuario que se almacenan. 2. Definir exactamente el concepto de “expulsión” en el ámbito de la aplicación. 5.2. Pruebas de robustez El día 14 de julio de 2021 tuvieron lugar las pruebas de robustez, basadas en analizar la dimensión de tolerancia a errores en la aplicación Crossroads 2.0, abarcando todas las posibles situaciones que pueden desencadenar un error a la hora de realizar determinadas operaciones. Desarrollo Participantes 102 5.2. PRUEBAS DE ROBUSTEZ Resultados En esta prueba únicamente ha intervenido un miembro del equipo de investigación (concretamente María Galindo Gómez) desempeñando los roles de moderador y jugador. Información recogida Por otro lado, la información relacionada con la prueba en cuestión se ha recogido los documentos PDF para cada una de las partidas, además de utilizar dos formularios en Google Docs (dirigidos al moderador y jugadores) donde se han incluido las capturas asociadas a cada resultado. Observaciones y resultados Las pruebas se han realizado siguiendo lo previsto, detectando un pequeño error, puesto que no se pueden registrar dos moderadores con el mismo nombre de usuario ni correo electrónico, motivo por el cual, en el caso de que alguno de los registros se repita se ha de mostrar un mensaje de error impidiendo el avance por parte del moderador. Se ha comprobado que esto sucede. No obstante, los mensajes de error correspondientes únicamente aparecen por consola (como se muestra en la figura 5.17), siendo necesario mostrarlos en pantalla, puesto que no se espera que los futuros usuarios recurran a la consola de desarrollador en el navegador correspondiente. Figura 5.17: Errores asociados al registro de moderador También conviene tener en cuenta pequeños matices como los mensajes que se muestran en la aplicación, siendo un caso un caso significativo el email en el formulario de registro vinculado al moderador en el que no se hace alusión a ningún formato en concreto partiendo de que es conocido por parte de cualquier usuario. 103 5.3. PRUEBAS DE COMPATIBILIDAD Resultados Tal y como se ha comentado a la hora de hablar sobre las pruebas de estabilidad, se incluirá un límite máximo para evitar bloqueos debido al elevado número de caracteres en mensajes, además de implementar la posibilidad de que cualquier jugador que cierre accidentalmente el navegador pueda reincorporarse a la partida y seguir respondiendo cuestiones. Recomendaciones Finalmente, se incluye una sección de recomendaciones en cuestiones de desarrollo y diseño. Recomendaciones al desarrollador: Tal y como se ha comentado, es necesario contempplar la posibilidad de que el usuario cierre el navegador erróneamente durante una partida, siendo necesario proporcionar los medios para permitir su reincorporación, además de limitar la cantidad de caracteres asociada a cada tipo de mensaje enviado. Por otro lado se encuentra la ya mencionada inclusión del mensaje de error en pantalla cuando el usuario se registra como moderador. Finalmente, también sería conveniente definir una longitud mínima a la hora de enviar mensajes tanto para comunicarse con otros jugadores como a modo de argumento. Recomendaciones al diseñador: 1. Convendría especificar los formatos válidos para el correo electrónico, como se ha mencionado en el formulario de registro para moderadores, con el fin de facilitar la utilización de la aplicación. 2. En el formulario de inicio de sesión para moderadores si se da el caso de introducir correctamente el nombre de usuario pero no la contraseña del mismo, podría ser de utilidad especificar que el campo mal introducido es la contraseña. 3. Por otro lado, es fácil que la longitud mínima asociada al nombre de una sala pase desapercibida al poder apreciarse únicamente situado el cursor sobre el campo del formulario, motivo por el cual, en el caso de no introducirla correctamente convendría incluir dicho formato en mensajes de error, tal y como se ha hecho a la hora de registrar la contraseña para moderadores. 5.3. Pruebas de compatibilidad Desarrollo Participantes En las pruebas de compatibilidad realizadas el día 15 de julio intervinieron dos participantes: Yania Crespo González-Carvajal (encargada de comunicar los resultados obtenidos de las tareas pertenecientes a las pruebas de estabilidad que realizó en macOS con el navegador Google Chrome) y María Galindo Gómez (realizando las pruebas en Ubuntu 20.04 y Windows 10 con los navegadores Google Chrome, Mozilla Firefox y Microsoft Edge). 104 5.4. PRUEBAS DE ESTABILIDAD Resultados Información recogida La información relacionada con las pruebas realizadas en Ubuntu 20.04 y Windows 10 se recoge en un formulario de Google Forms que además contiene PDF e imágenes de resultados asociados a cada partida. Por otro lado, a través de consultas a los registros en la base de datos mySQL con fecha 16 de julio de 2021, se puede comprobar que las tareas en cuestión se llevaron a cabo en el caso de macOS. Observaciones y resultados En cada sistema operativo y navegador mencionado se comprobó que las tareas se realizan del mismo modo, concluyendo la existencia de compatibilidad. Recomendaciones A pesar de haber demostrado la compatibilidad existen un par de aspectos a destacar relacionados con cuestiones de diseño: 1. Cuando se accede a la pantalla de resolución de conflictos en el caso de una cuestión que cuente con más de tres opciones, la tabla donde se muestran los votos y mensajes para cada respuesta se superpone con los botones inferiores sin ajustarse adecuadamente a su espacio reservado. Por ese motivo, es importante incorporar en versiones futuras una mejora que permita adaptar la tabla a dicho espacio en las situaciones mencionadas. 2. En Mozilla Firefox, los resultados asociados a gráficos aparecen completamente en color azul (tanto objetivos como valores de PIB y temperatura, cuando estos últimos deberían mostrarse en color rojo). Es importante tener en cuenta este aspecto, ya que podría dificultar la interpretación de resultados finales (además de que Mozilla Firefox es uno de los navegadores más utilizados a nivel mundial [ 67 ], hecho que eleva la probabilidad de que algún usuario opte por ejecutar la aplicación utilizando dicho navegador, como sucedió en la sesión dedicada a pruebas de usabilidad). 5.4. Pruebas de estabilidad El pasado 16 de julio de 2021 tuvo lugar una sesión orientada a pruebas de estabilidad para Crossroads 2.0. En principio, la idea principal era analizar la estabilidad a través de tres partidas centradas en abarcar tanto casos típicos como “extremos” (cantidad de jugadores y rondas fuera de lo común). 105 5.4. PRUEBAS DE ESTABILIDAD Resultados Desarrollo Participantes En primer lugar, es importante tener presentes los participantes que intervinieron: 1. Manuel Alda Peñafiel(desempeñando el rol de moderador) 2. Cristian Tejedor (jugador 1) 3. Yania Crespo González-Carvajal (jugadora 2) 4. David Escudero Mancebo (jugador 3) 5. Pablo García Fuente (jugador 4) 6. David Crespo (jugador 5) 7. Guillermo Sánchez Brizuela (jugador 6) 8. Juan Alonso Astruga (jugador 7) 9. Juan Carlos Garrote Gascón (jugador 8) 10. María Galindo Gómez (observadora) Información recogida A través de Google Forms, se facilitó a cada participante un formulario en función de su rol (moderador o jugador), en el que se recogieron los resultados obtenidos para cada tarea especificada en el capítulo 4. Por otro lado, se procedió a grabar la sesión en vídeo con el fin de poder acceder a información que podría no estar contemplada en los formularios. Finalmente, se descargaron los documentos PDF con los resultados de cada partida. Observaciones y resultados Las pruebas se llevaron a cabo con éxito, siendo de utilidad a la hora de comprobar que las funciones se ejecutan adecuadamente, además de detectar inconvenientes que pasaron desapercibidos a la hora de jugar partidas con una cantidad de jugadores reducida .Un problema detectado se asoció a la longitud de una respuesta proporcionada por uno de los participantes en el objetivo 2. Concretamente, debido al elevado número de caracteres ,superando al máximo permitido para el envío de mensajes (255), ya que, en mySQL cada mensaje se ha definido como VARCHAR(255) y no se había indicado el límite en el formulario correspondiente del frontend. El error impidió al jugador en cuestión seguir respondiendo cuestiones, puesto que en su equipo la aplicación de bloqueó. Por otro lado, el error también se manifestó a la hora de 106 5.4. PRUEBAS DE ESTABILIDAD Resultados resolver los conflictos automáticamente, puesto que únicamente el último grupo fue capaz de visualizar los resultados de la ronda correspondiente, además de existir problemas que desembocaron en el bloqueo de la pantalla dashboard. Al percatarse dicho inconveniente, se optó la segunda partida indicada en el plan, implicando a ocho jugadores en un único grupo (con la idea de repetir la primera tras haber jugado las dos restantes para comprobar si en verdad el error se debió a una cantidad excesiva de caracteres en un mensaje). En la segunda partida, todos los jugadores implicados lograron llegar a la pantalla en la que se muestra la matriz con las respuestas indicadas por cada jugador. No obstante, se descubrieron problemas asociados al rendimiento, manifestándose concretamente en el tiempo de carga y actualización asociado a la tabla en la que figuran las respuestas de cada jugador (en parte, conviene tener en cuenta que uno de los participantes estaba experimentando problemas de conexión en su equipo antes de comenzar a realizar la prueba). Los problemas mencionados pudieron deberse a una sobrecarga de la máquina virtual en la que se encuentra la aplicación. Con el fin de poder indagar sobre las posibles causas de los problemas expuestos en la segunda partida se procedió a organizar una nueva con un grupo de seis jugadores el día 17 de julio de 2021 desempeñando una única persona el rol de moderador y de cada uno de los seis jugadores utilizando varios navegadores en un único equipo. El rendimiento en operaciones relacionadas con almacenar respuestas y calcular puntuaciones se vio afectado, aunque no en gran medida. Por otro lado, las tabla de respuestas no experimentó el problema detectado en la partida con ocho jugadores, pudiendo visualizarse las actualizaciones prácticamente de forma inmediata, además, todos los jugadores pudieron acceder a sus resultados (tanto de ronda como asociados a la partida). A raíz de estos resultados se podría afirmar que las incidencias observadas durante el desarrollo de la partida pudieron deberse a sobrecarga por problemas de conexión. No obstante, puesto que el rendimiento por lo general se ve afectado, se ha optado por realizar futuras pruebas considerando grupos reducidos hasta disponer de una máquina virtual con mejores características. En lo que respecta a la tercera partida, esta se desarrolló sin presentar problemas y cada jugador pudo visualizar sus resultados de ronda y partida, verificándose además el correcto funcionamiento del podio mostrando los resultados de los tres mejores grupos por disciplina. Tras finalizar la tercera y última partida prevista, se procedió a repetir la primera. Se realizaron un total de dos partidas adicionales comprobándose en la primera que introducir mensajes excesivamente largos producía un error que impedía avanzar a sus autores. Varios jugadores redactaron mensajes extensos para comunicarse por el chat o bien a modo de argumento al responder una cuestión y los resultados obtenidos acabaron siendo los de la 107 5.4. PRUEBAS DE ESTABILIDAD Resultados primera partida, concluyendo la necesidad de establecer un límite en cuanto a caracteres a la hora de redactar un mensaje. Dos jugadores tuvieron que abandonar la sesión por cuestiones de reuniones y trabajos, motivo por el cual, la última partida se jugó con un total de seis personas (tres grupos de dos jugadores) y una única ronda. Todos los jugadores pudieron acceder a las pantallas de resultados correspondientes. A raíz de las pruebas realizadas durante la sesión del día 16 de julio de 2021 se concluyó que la aplicación podía funcionar sin problemas si se contaba con una cantidad de grupos y rondas típica o “extrema” (siempre y cuando se pusiese solución al problema del límite de caracteres ya mencionado), pero es necesario tener presentes aspectos de rendimiento y características de la máquina virtual, especialmente si se cuenta con grupos a los que se haya unido una cantidad “atípica de jugadores” (en este caso superior a cuatro). Recomendaciones A lo largo de la sesión, varios participantes expusieron una serie de recomendaciones para incluir en la aplicación. Atendiendo tanto a las sugerencias de participantes como a las incidencias detectadas en el momento de realizar las pruebas, las acciones a realizar se dividen en: Recomendaciones al desarrollador: 1. En lo que respecta a chats, dejar en blanco el campo de texto donde se inserta el mensaje una vez se haya enviado, además, para los jugadores es más cómodo que los mensajes mas recientes aparezcan en la parte superior del chat y no sea necesario descender para visualizarlos. 2. Existencia de un pequeño bug respecto a la actualización del estado cuando el moderador opta por finalizar una ronda o partida cuando algún jugador se encuentra en la pantalla para resolver conflictos de cualquier cuestión, puesto que, a pesar de poder visualizar sin problemas los resultados, su estado no aparece actualizado en la pantalla de dashboard. 3. En Mozilla Firefox, los gráficos asociados a resultados de ronda y partida no se muestran con los colores correctos. 4. Determinados textos asociados a retroalimentación cuentan con faltas de ortografía. Recomendaciones al diseñador: 1. Al unirse a un grupo, el mensaje del botón correspondiente podría cambiar cuando se realice la operación en cuestión indicando que el jugador ya se ha unido a un grupo. 108 5.5. PRUEBAS CON USUARIOS FINALES Resultados 2. Sería de utilidad especificar la ronda en la que se encuentran los jugadores indicándolo en la pantalla de cuestiones. De esa forma, los jugadores podrían saber con mayor facilidad cuándo comienza una nueva ronda. 3. La ubicación del formulario para enviar argumentos es diferente en función de la cantidad de opciones con las que cuenta la pregunta. Con el fin de mejorar la estética aconsejaron desplegarlo siempre en la parte central de la pantalla. 4. En las pantallas de cuestiones para resolver conflictos, si la pregunta cuenta com más de tres opciones, la tabla inferior no se ajusta correctamente, además de superponerse sobre los botones para enviar una nueva respuesta y cancelar. 5. El podio de los resultados finales es poco intuitivo debido a la ubicación de los nombres asociados a cada grupo ganador, motivo por el cual aconsejaron incluir el nombre correspondiente debajo de cada barra vinculada a puntuaciones. 6. Sugerencia de cambiar la palabra “temp” en los diferentes gráficos por “temperatura”, con el fin de evitar confusiones con posibles valores asociados al tiempo. Recomendaciones al analista: Posible necesidad de replantear atributos de calidad ante los problemas de rendimiento detectados que podrían deberse a características de la máquina virtual. 5.5. Pruebas con usuarios finales El día 23 de julio de 2021 tuvo lugar una sesión orientada a pruebas con investigadores expertos en cambio climático con el objetivo de obtener retroalimentación acerca de las diferentes funcionalidades disponibles en la versión actual, además de almacenar interacciones que incluyan respuestas elaboradas, las cuales, al proceder de expertos, pueden ser útiles para aplicarlas en versiones futuras de la aplicación. Desarrollo Participantes Como en las pruebas anteriores, se procede a exponer los participantes que intervinieron en la sesión acompañados de sus respectivos roles: 1. Manuel Alda Peñafiel (moderador) 2. Luis Javier Miguel González (jugador) 3. Luis Llases (jugador) 4. José María Enríquez Sánchez (jugador) 109 5.5. PRUEBAS CON USUARIOS FINALES Resultados 5. David Antelo (jugador) 6. Carmen Duce (jugadora) 7. Juan José Mediavilla (jugador) 8. David Escudero Mancebo (jugador) 9. Íñigo Capellán Pérez (jugador) 10. Yania Crespo González-Carvajal (observadora) 11. María Galindo Gómez (observadora) A través de Google Forms, se facilitó a cada jugador un formulario en el que se recogió la retroalimentación correspondiente para cada funcionalidad probada en la aplicación. La estructura de dicho formulario se asemeja al empleado en el ensayo cognitivo del prototipo, basándose en las mismas secciones y escala para definir el grado de acuerdo o desacuerdo, además de incluir campos de texto para indicar observaciones (para una explicación más detallada de este formulario véase el plan asociado a pruebas de usabilidad con el equipo de investigadores GEEDS en el capítulo 4). Por otro lado, se procedió a grabar la sesión en vídeo con el fin de poder acceder a información que podría no estar contemplada en los formularios. Finalmente, se descargaron los documentos PDF con los resultados de cada partida jugada. En este caso, la información del PDF ha sido utilizada para llevar a cabo una medición de tiempos en la primera partida (puesto que en dicha partida se guardaron los comentarios más relevantes, además de permitir a los jugadores probar la resolución de conflictos). Observaciones y resultados En primer lugar, se procede a la exposición de los resultados obtenidos en el formulario: Perfil del encuestado 110 5.5. PRUEBAS CON USUARIOS FINALES Resultados 111 5.5. PRUEBAS CON USUARIOS FINALES Resultados Los tiempos destinados a actividades de explicación se exponen a continuación: 1. Exposición de pautas para entrar a una sala y unirse a un grupo antes de iniciarse una partida: 3 minutos y 52 segundos 2. Exposición sobre la forma de responder a las cuestiones: 57 segundos 3. Respuesta a algunas cuestiones sobre el chat, ayudas y forma de responder las preguntas del juego, además de observaciones realizadas por los jugadores: 20 minutos y 56 segundos. 4. Explicación sobre la pantalla donde figuran las respuestas de cada jugador del grupo y los procedemientos seguidos para la resolución de conflictos: Un minuto y 56 segundos. 5. Cuestiones y observaciones sobre la pantalla donde figuran las respuestas de cada jugador del grupo, conflictos y bug al responder preguntas: 8 minutos. 6. Cuestiones, observaciones y explicación sobre resultados de ronda: 10 minutos y 26 segundos. 7. Cuestiones, observaciones y explicación sobre resultados finales: Un minuto y 2 segundos. Tiempo total aproximado dedicado a actividades de explicación: 47 minutos y 9 segundos. Preparación: Actividades que implican facilitar los recursos necesarios para poder iniciar una partida y/o mostrar resultados. A continuación, se muestran las actividades correspondientes: 1. Creación de sala: 34 segundos 2. Inicio de partida: 3 minutos y 52 segundos 3. Carga de resultados finales de partida tras finalizar una ronda: 20 segundos Tiempo total aproximado dedicado a actividades de preparación: 4 minutos y 46 segundos. Trabajo en grupo: Tiempo dedicado por los jugadores a debatir y responder cuestiones mediante cooperación en equipos. Para poder calcular una aproximación del tiempo invertido se han tomado como referencia las marcas temporales que figuran en el documento PDF cuyo contenido son las interacciones y resultados de la partida correspondiente. A continuación, se exponen los tiempos dedicados a trabajo en equipo por parte de cada jugador: 118 5.5. PRUEBAS CON USUARIOS FINALES Resultados Jugador Responder a todas las cuestiones Resolver conflictos Luis Javier Miguel González 22 minutos 15 minutos Luis Llases 28 minutos 18 minutos José María Enríquez Sánchez 20 minutos 14 minutos David Antelo 32 minutos No intervino Juan José Mediavilla 20 minutos No tuvo conflictos con su compañera de equipo Carmen Duce 22 minutos No tuvo conflictos con su compañero de equipo David Escudero Mancebo 25 minutos 12 minutos Íñigo Capellán Pérez 38 minutos (tuvo problemas en la Medida 8, motivo por el cual fue necesario que volviese a responder todas las cuestiones. El tiempo adicional no fue muy significativo al no repetir los comentarios detallados realizados en la iteración anterior) No intervino Tabla 5.46: Tiempo dedicado a trabajo en grupo para cada jugador A raíz de los resultados mostrados en las tablas, se procede a calcular el tiempo medio dedicado tanto a responder cuestiones como a la resolución de conflictos, obteniendo los siguientes resultados: Tiempo medio dedicado a responder cuestiones: 25,875 (26 minutos aproximados) Tiempo medio dedicado a resolver conflictos: 14,75 (15 minutos aproximados) Sumando los resultados obtenidos, el tiempo total dedicado al trabajo en grupo ascendió a 41 minutos aproximados. Las actividades asociadas a explicación se fueron realizando de forma simultánea a las de preparación (como la entrada a una sala y selección de grupos), así como al trabajo en equipo debatiendo y respondiendo cuestiones. 119 5.5. PRUEBAS CON USUARIOS FINALES Resultados Los tiempos calculados aparecen representados (expresados en minutos) en la figura 5.18 Figura 5.18: Línea del tiempo asociada a la sesión con el equipo GEEDS (tiempos expresados en minutos) Si bien es cierto que los perfiles de investigadores expertos no son comparables a los relacionados con estudiantes universitarios (cursando el máster de Cooperación Internacional) como los que participaron en el ya mencionado seminario, los tiempos obtenidos son de utilidad a la hora de realizar una posible estimación inicial de futuros resultados. Si se comparan los resultados asociados a la sesión de pruebas de usabilidad con los del seminario (expuestos en la figura 4.13), es sencillo apreciar una reducción bastante significativa en el tiempo destinado a tareas de preparación (teniendo en cuenta que la duración real aproximada de la sesión fue de 90 minutos). Es importante tener presente que la sesión del seminario se basó en la utilización de un juego con recursos físicos (concretamente cuestiones en papel y cartulinas con las letras de cada respuesta las cuales debían alzarse cada vez que se contestase a una pregunta). Además, los jugadores formaron grupos reuniéndose en el aula, mientras que la aplicación proporciona todos los medios necesarios para poder iniciar una partida creando una sala, accediendo a ella y uniéndose a grupos, así como la redirección a la pantalla de cuestiones y respuestas una vez haya iniciado la partida. Por otro lado, las actividades que han requerido más tiempo han sido aquellas relacionadas con la explicación de funcionalidades que presenta el juego, así como respuestas a preguntas que realizaban los participantes conforme se desarrollaba la partida. No obstante, el tiempo dedicado al trabajo en grupo ha sido considerablemente superior al del seminario (conviene recordar que la aplicación está siendo creada para fomentar el debate y exposición de diversos puntos de vista asociados a cada cuestión), diferenciándose en solamente 6 minutos aproximados respecto al periodo de explicación (a diferencia de las explicaciones que tuvieron lugar durante el seminario, en las que solamente la introducción a la aplicación se demoró tanto como la duración de la partida para evaluar la usabilidad con el equipo de investigadores GEEDS, representando el tiempo total dedicado a explicaciones un 62 % (cerca de 99 minutos si se tiene en cuenta que la sesión duró aproximadamente dos horas y media), dedicando apenas unos 34 minutos al trabajo en grupo. Tal y como se ha mencionado, la mejora estimada en lo que respecta a tiempos es notable, aunque es necesario reducir el tiempo empleado en actividades explicativas para versiones futuras, puesto que, una de las ideas principales que persiguen las pruebas de usabilidad es comprobar que la aplicación puede emplearse sin necesidad de recurrir a medios como cuestiones a encargados del proyecto o consulta frecuente de manuales para poder utilizarla. 120 5.5. PRUEBAS CON USUARIOS FINALES Resultados Durante la actividad del seminario, cada vez que los alumnos se preparaban para responder una cuestión, el docente encargado ofrecía una explicación sobre los conceptos más relevantes para poder comprender el significado de la elección tomada. En un futuro dicha explicación se incorporará a la aplicación en forma de ayudas presentes en cada una de las preguntas (ya que, no necesariamente tiene que existir un ponente experto en la materia cada vez que se utiliza), además de incluir un informe personal en la pantalla de resultados finales con el objetivo de que cada jugador pueda comparar su patrón de respuestas con el mejor de la partida en cuestión y seguir recomendaciones. Cabe destacar que, durante el transcurso del seminario, una alumna del máster de Cooperación Internacional señaló que la información contemplada tanto en cuestiones como en resultados finales mostrados podría asociarse a países nórdicos, existiendo complicaciones para aplicar el contenido en otro tipo de territorios, siendo una observación bastante importante para considerar en versiones futuras, puesto que, tal y como indicaron varios miembros del equipo GEEDS en la sesión de usabilidad, es conveniente revisar el contenido de las cuestiones, especialmente de aquellas que tomen partan de datos actuales o presenten respuestas equivalentes a medidas drásticas (como reducción de población). Recomendaciones Finalmente, como en los casos anteriores, se procede a mostrar las recomendaciones y mejoras propuestas por cada participante. Recomendaciones al desarrollador: En primer lugar, es necesario resolver el ya mencionado problema de escalabilidad que se manifiesta a la hora de responder cuestiones, pudiendo impedir el envío de las respuestas y, por ende el avance de la partida para el jugador afectado. Por otra parte, se propuso la idea de definir ficheros con los términos necesarios para facilitar la futura implementación de la opción para cambiar de idioma. Recomendaciones al diseñador: 1. Mejoras en textos(en especial suprimiendo el uso excesivo de mayúsculas) y diferentes formatos. 2. Inclusión de opciones que permitan navegar a cualquier cuestión que seleccione el jugador, con el fin de facilitar la labor asociada al cambio de opción elegida con anterioridad en el caso de ser necesario. 3. Revisar cuestiones y mejorar aspectos de redacción, así como la forma de mostrar los resultados. Por un lado, es necesario establecer la temperatura por debajo de 2 º C y disminuirlo en lo posible a 1,5 º C. Esos aspectos deben tenerse en cuenta para comprobar el logro del objetivo. Además, el texto asociado a cada retroalimentación podría reducirse y, en lo que respecta a puntuaciones, es necesario especificar qué mide exactamente cada indicador, pudiendo recurrir a 121 5.5. PRUEBAS CON USUARIOS FINALES Resultados colores que identifiquen a cada equipo, en lugar de hacer referencia al indicador en sí. 4. Necesidad de incrementar el tamaño asociado a muestras gráficas. 5. Es necesario prestar atención a diversas cuestiones relacionadas con el chat, puesto que, varios participantes han señalado el hecho de ser incómodo de utilizar, existiendo la posibilidad de eliminar la clasificación de mensajes (a favor, en contra y neutros), así como la inclusión de los mensajes más recientes en la parte superior del chat. Además, en la resolución de conflictos, convendría incluir en el chat únicamente los mensajes asociados a la cuestión elegida. 6. Ampliar la anchura del chat y del campo que es necesario rellenar para enviar un argumento. 7. Inclusión de opciones para consultar ayudas e/o instrucciones que sirvan de utilidad a lo largo del desarrollo de la partida (de esa forma, los futuros jugadores podrán entender qué están haciendo en cada momento). 8. Introducción de un botón al finalizar partida que permita acceder a un escenario cargado previamente como “propositivo”, con el fin de que los jugadores puedan visualizar las mejores combinaciones de medidas, evitando la aparición de frustración en el caso de no poder alcanzar buenos resultados. Atendiendo de nuevo a las dimensiones de Quesenbery [ 89 ], la aparición de frustación afecta muy negativamente a la eficacia (puesto que acaba resultando muy difícil conocer los objetivos que persigue el juego, siendo en este caso encontrar una combinación de respuestas lo suficientemente adecuada como para poder alcanzar un futuro sostenible) y engaging (especialmente en lo que respecta a futura utilización y recomendación de la aplicación). 9. Inclusión de avisos si se elige una opción poco coherente. 10. Inclusión de un reloj que contemple el tiempo restante para finalizar la partida (incluso el tiempo necesario para responder a cada cuestión). 11. El moderador podría recibir mensajes informativos en el caso de que no se perciban avances en un grupo determinado. Recomendaciones al analista: • Como se ha mencionado anteriormente, la aplicación se encuentra dirigida principalmente a un público joven, motivo por el cual, conviene reflexionar acerca de las siguientes cuestiones: ¿En verdad la versión actual de la aplicación interesaría a ese tipo de público? De no ser así, ¿qué cambios es necesario realizar?. • Necesidad de contemplar aspectos adicionales no dependientes de la temperatura ni del PIB en la pantalla de resultados (como la disponibilidad de minerales). • En lo que respecta a temperatura y PIB, tomar como referencia los valores industriales definidos desde el Acuerdo de París hasta la Cumbre de Río de 1992 en lugar de los actuales. 122 5.5. PRUEBAS CON USUARIOS FINALES Resultados • Inclusión de términos neutros en los futuros roles desempeñados por jugadores. • Determinar exactamente el significado de “RSP”, “hipótesis”, “objetivo” y “medida”. 123 6: Conclusiones y Líneas de trabajo futuras El presente TFM ha contribuido de forma relevante en el proyecto H2020 Locomotion al haber sido posible desarrollar parte de la aplicación gamificada, así como llevar a cabo las primeras pruebas de la misma. Gracias a las sesiones de prueba se pudo comprobar que las funcionalidades se ejecutan adecuadamente, además de detectar inconvenientes no contemplados previamente, obtener información de expertos útil para llevar a cabo la implementación de futuras versiones y llevar a cabo una evaluación inicial en lo que respecta al grado de adecuación asociado a usabilidad siguiendo los criterios establecidos para el formulario SUS [ 111 ]. La contribución en proyectos de esta índole es importante, puesto que la experiencia puede percibirse como una forma de participar en la divulgación y concienciación de la situación actual en lo que respecta a cambio climático, así como su futura evolución.Actualmente, es común oír y/o leer afirmaciones asociadas al incremento del nivel del mar, deshielo de los polos o aumento de temperaturas, entre otros inconvenientes significativos, pero el público posiblemente interesado no siempre conoce con claridad la influencia que ejercerían dichos acontecimientos en un futuro relativamente cercano. Crossroads es una aplicación orientada principalmente a un público adolescente y universitario centrada en concienciar y hacer hincapié en la importancia del cambio climático y sus posibles efectos adversos sobre aspectos como temperatura o PIB, de forma que sus usuarios decidan aportar en los futuros procesos de mitigación teniendo presente la información recogida en el juego, habiendo recibido una ayuda de FeCYT para la divulgación de Locomotion, haciendo hincapié en la realización de pruebas mediante el uso del videojuego. Por otro lado, en el documento también puede apreciarse una contribución en lo que respecta al análisis de elementos formales, elementos dramáticos, aspectos relacionados con jugabilidad y proyectos relacionados con el mismo tema, partiendo de los conceptos básicos asociados a usabilidad (dimensiones, instrumentos de evaluación y cuestiones a tener en cuenta a la hora de planificar sesiones de prueba). Dichos procesos de análisis son relevantes a la hora de identificar y analizar en profundidad cada uno de los elementos que compone el juego y ligarlos a las diferentes dimensiones de usabilidad, determinando el grado en el 124 Conclusiones y Líneas de trabajo futuras Conclusiones y Líneas de trabajo futuras que cada dimensión puede estar presente, puesto que, de acuerdo con Quesenbery [ 88 ], es una situación ideal alcanzar el equilibrio entre todas las dimensiones de usabilidad. No obstante, es difícil que se cumpla cierta situación, motivo por el cual es necesario analizar el grado en el que puede estar presente cada dimensión y así poder desarrollar una aplicación que ofrezca los mejores resultados, guardando una importante relación con las sesiones de pruebas llevadas a cabo, en especial aquellas realizadas con posibles usuarios potenciales de la aplicación, puesto que la información derivada de los principales aspectos a analizar (facilidad de uso, intiuitividad, modo de mostrar la información, entre otros) hacen referencia a cada una de las ya mencionadas dimensiones de usabilidad (eficacia, eficiencia, engaging, facilidad de aprendizaje y tolerancia a errores). Conviene destacar que el documento contempla aportaciones a la implementación realizadas en coordinación con los TFGs de Manuel Alda Peñafiel (quien se encargó de implementar funcionalidades hasta medidados de julio) y Elena Rodríguez Pastor (diseñadora de interfaces de usuario), habiendo sido importante la actividad realizada durante el periodo de prácticas en la asignatura I+D+I para poder llevar a cabo con éxito las operaciones relacionadas con la creación de salas, envío de respuestas a cuestiones y visualización de resultados vinculados a rondas (actividades principales a la hora de jugar una partida), además de descubrir algunos inconvenientes importantes como el bloqueo de operaciones por política de CORS (Cross-origin resource sharing) que imposibilitaba el correcto funcionamiento de la aplicación en navegadores cuya seguridad no fuese deshabilitada, constituyendo un obstáculo significativo en la realización de pruebas y la existencia de asincronía en funciones de Typescript. Los problemas en cuestión pudieron resolverse dando lugar a la versión actual de la aplicación. Como se ha mencionado, la principal contribución ofrecida en el TFM es la definición y ejecución parcial de un plan de pruebas distinguiéndose las sesiones realizadas por miembros del grupo de investigación y/o estudiantes tanto de grado como de máster de la última sesión en la que intervinieron expertos en cambio climático. Las sesiones relacionadas con pruebas de estabilidad, robustez y compatibilidad se centraron en el análisis del funcionamiento vinculado a la aplicación, obteniendo información relacionada especialmente con cuestiones de rendimiento y diseño de interfaces. Por otro lado, la intervención de expertos permitió obtener retroalimentación relacionada con la forma de mostrar la información y el contenido de la misma, además de analizar aspectos relacionados con complejidad de elementos, algunas carencias observadas y formas de mostrar la información en pantalla. Finalmente, se han planificado futuras sesiones con estudiantes de Ingeniería, de nuevo con el propósito de obtener información necesaria para implementar mejoras en el futuro. Como se ha apreciado a lo largo del documento, los resultados de las pruebas han sido satisfactorios, aunque, es importante tener en cuenta que también reflejan la necesidad de incluir mejoras relacionadas especialmente con cuestiones de diseño y rendimiento. Por un lado, en lo que respecta al rendimiento, es importante determinar el origen de dichos problemas que influyen claramente en cuestiones de escalabilidad (tiempos de carga mayores de lo previsto y dificultad a la hora de visualizar resultados en el caso de contar 125 Conclusiones y Líneas de trabajo futuras Conclusiones y Líneas de trabajo futuras con grupos de numerosos usuarios) y afectan a la dimensión de eficiencia, considerando especialmente el hecho de que la aplicación será utilizada en aulas de estudio, generalmente con grupos de entre quince y veinte personas, motivo por el cual, antes de proceder a la realización de nuevas pruebas asociadas a usabilidad convendría atenuar los inconvenientes en cuestión. El proyecto continúa en desarrollo, esperando de nuevo la intervención de Manuel Alda, trabajando durante el curso 2021-2022. 126 Apéndices 127 A.3. ESTUDIO DE VIABILIDAD APÉNDICE A. PLAN DE PROYECTO Componente Coste presupuestado Coste real Analista de tests 24,07 euros 0 euros Probadores 49,80 euros 0 euros Total 73,87 euros 0 euros Tabla A.3: Costes directos asociados a la utilización del servidor Por de pronto, la aplicación se encuentra alojada en una máquina virtual Ubuntu con las siguientes características: 4GB de memoria RAM. Disco duro de 10 GB de almacenamiento. Un procesador. Por último, es necesario llevar a cabo actividades periódicas relacionadas con el mantenimiento del servidor, suponiendo un coste adicional aproximado de 290 euros anuales [38] (de momento no se han llevado a cabo en la realidad). Teniendo en cuenta los diferentes resultados obtenidos, los costes directos totales presupuestados ascienden a 8.751,23 euros aplicando tarifas españolas y 9.766,25 euros si se habla de tarifas asociadas a la UE, mientras que la cantidad real equivale a 606,39 euros. Costes indirectos Partiendo de la información expuesta sobre costes indirectos en el presente apartado, se exponen sus valores correspondientes: Componente Coste presupuestado (España) Coste presupuestado (UE) Coste real Personal 5.055,17 euros 5.664 euros 342,08 euros Servicios y materiales 553,33 euros 553,33 euros 3,63 euros Total 5.608,49 euros 6.217,33 345,71 euros Tabla A.4: Costes indirectos A través de los resultados calculados, el coste total presupuestado es: 14.360,02 euros aplicando tarifas españolas y 15.983,58 euros en el caso de tener en cuenta tarifas europeas, mientras que el real asciende a 952,10 euros. Los costes presupuestados en ambos casos superan en mayor medida cantidad disponible para implementar el proyecto en la realidad, motivo por el cual no se trata de un proyecto económicamente viable si se tuviese que realizar de nuevo con los mismos medios. 134 A.3. ESTUDIO DE VIABILIDAD APÉNDICE A. PLAN DE PROYECTO Viabilidad legal Licencias de software implicadas en implementación En lo que respecta a la viabilidad legal vinculada a licencias de software, conviene tener presente, en primer lugar los siguientes conceptos [69]: Acción de licenciar un software: Se trata del procedimiento mediante el cual se concede a una persona el derecho de utilizar el software con fines específicos indicados en la propia licenacia(comerciales, personales e industriales). La licencia que autorice el modo de uso correspondiente puede obtenerse en forma de número de serie o documento (ya sea físico o electrónico). Licencia de software propietario: Tipo de licencia que requiere el permiso del propietario asociado al software en cuestión (en ocasiones a través de un pago) para poder realizar operaciones de copia, modificación, utilización y/o redistribución. Licencia de software de dominio público: Se trata de software sin copyright, aunque puede presentar ciertas versiones en las que el autor haya establecido restricciones relacionadas con la redistribución del software original o proyectos creados a partir del mismo. Licencia de software semilibre: No se trata de un software libre, pero permite la realización de operaciones relacionadas con es uso, modificación, copia y distribución sin fines de lucro. Licencia de software libre: Se trata de un tipo de licencia asociada a un software que permite la ejecución del mismo, creación de copias, así como modificación del programa con el fin de incluir mejoras o adaptarlo a una determinada necesidad. Licencia de software con copyleft: Se trata de un tipo de licencia asociada a software libre, que impide a su creador incluir restricciones adicionales. No obstante,este último puede retirar dicha licencia en cualquier momento (indemnizando a quienes la posean en ese instante). Licencia de software GPL (Licencia Pública General Reducida de GNU): Se trata de un ejemplo de licencia libre con copyleft, aunque no muy fuerte, ya que el software cuenta con la posibilidad de enlazarse con módulos que no seaqn libre, haciendo que la licencia en cuestión solo sea recomendable para circunstancias como la expuesta en este mismo apartado relacionada con MySQL. Licencia de freeware: Autoriza la utilización del software de forma libre, pero de acuerdo con determinadas condiciones, como inclusión de limitaciones o publicidad. Dos variantes de este tipo de licencia son Postcardware, la cual suele implicar el envío de una postal y Donationware, en la que se requiere el envío de un donativo. 135 A.3. ESTUDIO DE VIABILIDAD APÉNDICE A. PLAN DE PROYECTO Licencia de shareware: Tipo de licencia basada en la evaluación y posterior adquisición de un software a través de la compra del mismo. Suelen presentar limitaciones relacionadas con el tiempo de utilización permitido y/o disponibilidad de funciones. Licencia de Abandonware: Se trata de un tipo de licencia frecuente sobre todo en el ámbito de los videojuegos. Se trata de software descatalogado que ha sido liberado de derechos de autor. Un software se clasifica en la categoría de Abandonware si el propio creador ha cedido los derechos, además de haberse dejado de fabricar y distribuir, así como no contar con servicios como el soporte técnico. Licencia de código abierto: Este tipo de licencia cumple con las características expuestas a continuación [69]: 1. Distribución libre 2. Distribución del código fuente 3. Está permitida la modificación del código fuente, así como la creación de proyectos que deriven del software en cuestión y la redistribución tanto del software original como de dichos proyectos derivados. 4. Integridad del código fuente, ya que la propia licencia puede establecer que los proyectos derivados se redistribuyan con distinto nombre y/o versión respecto al producto original. 5. La licencia no debe presentar indicios de discriminación hacia determinados usuarios o grupo de usuarios ni restringir su utilización a determinados dominios o actividades. 6. Los derechos del programa se han de aplicar a todos los usuarios a quienes se ha redistribuido el producto en cuestión. Además, dichos derechos no han de depender de que el programa sea parte de una determinada distribución de software. 7. La licencia no debe presentar restricciones en otro software que se distribuya junto al producto asociado a la licencia. 8. La licencia ha de mostrar neutralidad en asuntos relacionados con la tecnología. Es importante tener en cuenta que una aplicación de código abierto no necesariamente tiene que ser gratuita [134]. La aplicación Crossroads 2.0 emplea cuatro tecnologías claramente diferenciadas : Spring Boot, Angular 12, MySQL y MongoDB. Teniendo en cuenta todas los tipos de licencias expuestas, Spring Boot, Angular 12 y MongoDB son de código abierto [ 136 , 126 , 130 ] (Angular se basa en la licencia MIT, la cual especifica el permiso de trabajar con una copia del software permitiendo operaciones como usar, copiar, distribuir o vender copias del software sin coste monetario alguno y sin garantía de ningún tipo [ 3 ]) . En lo que respecta 136 A.3. ESTUDIO DE VIABILIDAD APÉNDICE A. PLAN DE PROYECTO a la licencia de MySQL, esta es dual [ 131 ], es decir parte de la licencia es libre y otra parte es de carácter comercial. A continuación se procede a exponer las circunstancias en las que se necesita adquirir una licencia de esta índole [52]: Si se desea modificar el código MySQL y se desea redistribuir el software con dichas modificaciones sin ser gratuito. Si se desea incluir MySQL dentro del software y distribuirlo en conjunto. En esta ocasión puede optarse por no adquirir una licencia comercial, no obstante, sería necesario disponer de una licencia GPL, así como liberar el código. Cuestiones éticas implicadas en pruebas de usabilidad Esta última situación se daría en el caso de desear distribuir la aplicación Crossroads 2.0 de forma no gratuita,motivo por el cual sería conveniente disponer de una de las dos alternativas mencionadas para evitar problemas de carácter legal relacionados con derechos de autor. Por otro lado, en lo que respecta a la realización de pruebas de usabilidad, es conveniente tener presentes los factores éticos que rigen proyectos de investigación. Para ello, se procede al envío de una solicitud para participar en un proyecto de investigación accediendo a la web del Comité de ética de la Investigación (en el caso de Valladolid, un ejemplo es el Comité de Ética de la Investigación con Medicamentos, cuyo sitio web se encuentra en el enlace: https://www.icscyl.com/hcuv/ceimvalladolideste /envio-de-documentacion/) adjuntando los siguientes documentos: 1. Impreso solicitud de evaluación. 2. Impreso de Conformidad del Director de Departamento o Coordinador del G.I.R. 3. Memoria del proyecto, detallando los aspectos en los que se encuentran presentes implicaciones éticas (utilización de datos, custodia, participación de determinados grupos de personas, etc). 4. Si es necesario, se ha de seleccionar el modelo que se adecúe a su proyecto. La documentación ha de ser enviada lo antes posible teniendo en cuenta que los miembros asociados a comités de esta índole suelen reunirse una vez al mes. Una vez realizada la solicitud, se examina la documentación y, en el caso de ser correcta, el jefe de servicio proporciona un documento de conformidad, además de emitirse un dictamen favorable. Por otro lado, es necesario contar con el consentimiento de aquellas personas implicadas en pruebas de investigación, puesto que las sesiones de pruebas implican recoger información de carácter personal, además de recurrir a grabaciones de vídeo y audio y tener presente que, aunque la probabilidad sea baja, realizar pruebas en universidades puede implicar la presencia de algún menor de edad, motivo por el cual, en un caso de esta índole, los padres 137 A.3. ESTUDIO DE VIABILIDAD APÉNDICE A. PLAN DE PROYECTO o tutores legales del participante en cuestión son los encargados de decidir si proporcionan o no el consentimiento necesario para participar en pruebas. La solicitud de evaluación,el documento de conformidad asociado al jefe de servicio y la declaración de consentimiento se muestran a continuación. 138 Avda. Ramón y Cajal, 3 - 47003 Valladolid Tel.: 983 42 00 00 - Fax 983 25 75 11 [email protected] Solicitud de evaluación de un Ensayo/Estudio/Proyecto de Investigación por el CEIm del Área de Salud Valladolid-Este V.ABRIL -2020 1 DATOS DEL PROYECTO Título del proyecto: Realización de pruebas de usabilidad de aplicación informática CROSSROAD2 Servicio/Sección/Unidad responsable proyecto: Grupo de Investigación Reconocido GEEDS Otros Servicios/Secciones/Unidades participantes: Departamento de Informática Universidad de Valladolid Investigador principal: Luis Javier Miguel González E-mail Luis Javier Miguel González Teléfono 640609102 Equipo investigador * David Escudero (Profesor Departamento Informática) * Yania Crespo (Profesor Departamento Informática) * María Galindo (Becaria de la Fundación General) Financiación del ensayo/estudio/proyecto: La acción pertenece al proyecto H2020 Locomotion: Low-carbon society: an enhanced modelling tool for the transition to sustainability, liderado por nuestra Universidad Duración estimada del ensayo/estudio/proyecto: Inicio: abril 2021 Fin: diciembre 2021 El Investigador Principal así como sus colaboradores hacen constar: Que el estudio consistirá en la realización de pruebas con usuarios reales de una aplicación educativa en el contexto de institutos de la comunidad autónoma. La aplicación recoge los comentarios que emiten los estudiantes durante su uso convenientemente anonimizados. No se recoge información personal. Se espera grabar las sesiones de prueba para poder hacer análisis de usabilidad de la herramienta para lo que se ha preparado un consentimiento informado. También se adjunta, junto al consentimiento informado, el procedimiento de custodia de los datos, que por otro lado estarán anonimizados. Que el estudio respeta las normas éticas aplicables a este tipo de estudios. Que aceptan participar como Investigador Principal y como colaboradores en este estudio. Que cuenta con los recursos materiales y humanos necesarios para llevar a cabo el estudio, sin que ello interfiera en la realización de otro tipo de estudios ni en otras tareas que tiene habitualmente encomendadas. Que se comprometen a realizar el estudio siguiendo lo establecido en el protocolo, y que respetará las normas éticas y legales aplicables a este tipo de estudios siguiendo las normas de buena práctica clínica en su realización. La información de esta solicitud se incorporará a la base de datos de este CEIm. Valladolid a 13 de Abril de 2022 Avda. Ramón y Cajal, 3 - 47003 Valladolid Tel.: 983 42 00 00 - Fax 983 25 75 11 [email protected] Solicitud de evaluación de un Ensayo/Estudio/Proyecto de Investigación por el CEIm del Área de Salud Valladolid-Este V.ABRIL -2020 2 Firma Investigador Principal *Dr. Luis Javier Miguel González Firma Investigadores colaboradores. * Dr. David Escudero * Dr. María Galindo * Dr. Yania Crespo Avda. Ramón y Cajal, 3 - 47003 Valladolid Tel.: 983 42 00 00 - Fax 983 25 75 11 [email protected] CONFORMIDAD DEL JEFE DE SERVICIO Dr Luis Javier Miguel González como Jefe del Servicio de Grupo de Investigación GEEDS GEEDS Hago constar: Que conozco la documentación relativa al estudio que lleva por título “Realización de pruebas de usabilidad de aplicación informática CROSSROAD2“ Y cuyo investigador principal será el Dr./Dra. Luis Javier Miguel González delegando la ejecución de la misma en David Escudero, Yania Crespo y María Galindo Declaro tener conocimiento y apruebo la realización del ensayo clínico en este Servicio. En Valladolid a 12 de Abril de 2022 Fdo. Dr./Dra. Luis Javier Miguel González Jefe de Servicio de Grupo de Investigación Reconocido GEEDS Avda. Ramón y Cajal, 3 - 47003 Valladolid Tel.: 983 42 00 00 - Fax 983 25 75 11 [email protected] COMITÉ DE ÉTICA DE LA INVESTIGACIÓN CON MEDICAMENTOS ÁREA DE SALUD VALLADOLID Valladolid a 29 de abril de 2021 En la reunión del CEIm ÁREA DE SALUD VALLADOLID ESTE del 29 de abril de 2021, se procedió a la evaluación de los aspectos éticos del siguiente proyecto de investigación. PI 21-2270 NO HCUV REALIZACIÓN DE PRUEBAS DE USABILIDAD DE APLICACIÓN INFORMÁTICA CROSSROAD2 I.P.: LUIS JAVIER MIGUEL GONZÁLEZ EQUIPO: DAVID ESCUDERO, YANIA CRESPO UVA A continuación, les señalo los acuerdos tomados por el CEIm ÁREA DE SALUD VALLADOLID ESTE en relación a dicho Proyecto de Investigación: Considerando que el Proyecto contempla los Convenios y Normas establecidos en la legislación española en el ámbito de la investigación biomédica, la protección de datos de carácter personal y la bioética, se hace constar el informe favorable y la aceptación del Comité de Ética de la Investigación con Medicamentos Área de Salud Valladolid Este. Un cordial saludo. Dr. F. Javier Álvarez. CEIm Área de Salud Valladolid Este Hospital Clínico Universitario de Valladolid Farmacología, Facultad de Medicina, Universidad de Valladolid, c/ Ramón y Cajal 7,47005 Valladolid [email protected], [email protected] tel.: 983 423077 Ejemplar para el participante / investigador (tachar según corresponda) 1/4 CONSENTIMIENTO INFORMADO PARA LA PARTICIPACIÓN COMO INFORMANTE EN LAS SESIONES DE EVALUACIÓN Y USO DE LA APLICACIÓN EDUCATIVA CROSSROADS CROSSROAD2 La aplicación educativa Crossroad2 (o Crossroads) tiene por objeto dar a conocer las implicaciones cruzadas entre clima energía y cambio climático. Quiere dar a conocer la importancia de la tecnología en la sociedad y crear conciencia sobre el planteamiento de estrategias que permitan afrontar el problema del cambio climático. La aplicación se plantea como una herramienta gamificada en la que los alumnos trabajan en equipos en los que deben asumir roles de expertos en diversos ámbitos que deben tomar decisiones. Un simulador, permite comprobar los efectos de dichas decisiones. Este documento pretende explicar todas las cuestiones relativas a la utilización que se realizaría de los datos de participación en las sesiones de prueba de la aplicación educativa en el marco del proyecto 2020 LOCOMOTION liderado por la Universidad de Valladolid. Léalo atentamente y consulte con el/la educadora del centro todas las dudas que se le planteen. 1. ACERCA DE LA SESION DE PRUEBA El equipo investigador necesita probar la herramienta en un aula de ordenadores, de forma conjunta por varios alumnos simultáneamente, de forma supervisada por el profesor/a del centro. Queremos probar el uso de la herramienta de forma y agradecemos la necesaria colaboración de los alumnos y la autorización para que las sesiones sean grabadas y queden así recogidas como evidencias de resultados de investigación: registros de uso y cuestionarios de evaluación. No existen riesgos para los alumnos durante la realización de la prueba. Los alumnos podrán abandonarlo en cualquier momento antes o durante las pruebas. Las grabaciones y la información recogida en formularios garantizan el anonimato y serán custodiadas de acuerdo a la normativa tal y como se describe en la sección siguiente.