BRAINWIQ

1. Introducción y objetivos

El proyecto WIQ es una iniciativa llevada a cabo en la Universidad de Oviedo, bajo la solicitud de la empresa de desarrollo de software HappySaw y contratada por RTVE, con el propósito de desarrollar una versión web del concurso "Saber y Ganar". El equipo de desarrollo comprometido a materializar este proyecto está formado por

Marina Seijo Gómez
Rubén Pérez Dafonte
David Muños Rio
Ángela Roza Moren

WIQ es una aplicación web que presentará un juego de preguntas y respuestas en el que los usuarios tendrán un tiempo limitado para seleccionar, entre diferentes opciones, la respuesta correcta a una pregunta.

1.1. Descripción de los requisitos

Los usuarios deberán registrarse para poder jugar o bien iniciar sesión si ya se han registrado previamente.
El sistema proporcionará preguntas de distintas temáticas junto con 4 posibles respuestas mediante el uso de Wikidata. Las preguntas serán variadas.
El sistema guardará información sobre la participación de los usuarios ofreciendo un histórico de: número de juegos, preguntas acertadas/falladas, tiempo etc.
El sistema ofrecerá una API de acceso a la información de los usuarios y de las preguntas generadas.
Habrá un límite de tiempo para responder cada pregunta.

1.2. Objetivos de calidad

Meta	Explicación
Usabilidad	Nuestra aplicación tiene que ser fácil de usar para todos los tipos de usuario, incluso para uno sin experiencia. Las vistas deben ser claras e intuitivas, y el usuario tiene que poder navegar con fluidez por toda la aplicación. Además, se deben implementar los mecanismos necesarios para facilitar el uso de la aplicación por parte de los usuarios.
Mantenibilidad	El sistema debe poder ser modificado fácilmente para por ejemplo, poder añadir nuevos modos de juego o nuevas temáticas. Para esto será necesaria también una documentacion clara y completa.
Estabilidad	Nuestra aplicacion debe asegurar estabilidad, ya que se tratará de un juego con preguntas extraidas y respondidas en tiempo real, por lo que necesitamos que sea resistente a posibles fallos y caidas.
Testeabilidad	La solicitud debería poder pasar por diferentes pruebas y completarlas con éxito. Además, la aplicación debe estar preparada para todos tipos de usos lógicos por parte del usuario.

1.3. Partes interesadas (Stakeholders)

Rol/Nombre	Contacto	Expectativas
Equipo de desarrollo/Estudiantes	Marina Seijo Gómez, Rubén Pérez Dafonte, David Muños Rio, Ángela Roza Moreno	Encargados del completo desarrollo y diseño de la aplicación. Aumentarán y mejorarán su experiencia como programadores y diseñadores. Además, aprenderán a trabajar en equipo.
Profesores	Jose Emilio Labra Gayo, Pablo González González, Cristian Augusto Alonso, Jorge Fidalgo Álvarez	Evaluarán el resultado final de la aplicación y ofrecerán ayuda al equipo de desarrollo.
RTVE	Radiotelevisión Española	Solicitantes del servicio. Esperan que los requisitos exigidos sean completados satisfactoriamente.
Usuarios	Cualquier usuario de la aplicación	Serán quienes emplearán el servicio. Deberán encontrarlo entretenido y sencillo de usar.

Rol/Nombre

Contacto

Expectativas

Equipo de desarrollo/Estudiantes

Marina Seijo Gómez, Rubén Pérez Dafonte, David Muños Rio, Ángela Roza Moreno

Encargados del completo desarrollo y diseño de la aplicación. Aumentarán y mejorarán su experiencia como programadores y diseñadores. Además, aprenderán a trabajar en equipo.

Profesores

Jose Emilio Labra Gayo, Pablo González González, Cristian Augusto Alonso, Jorge Fidalgo Álvarez

Evaluarán el resultado final de la aplicación y ofrecerán ayuda al equipo de desarrollo.

RTVE

Radiotelevisión Española

Solicitantes del servicio. Esperan que los requisitos exigidos sean completados satisfactoriamente.

Usuarios

Cualquier usuario de la aplicación

Serán quienes emplearán el servicio. Deberán encontrarlo entretenido y sencillo de usar.

2. Restricciones de arquitectura

2.1. Restricciones técnicas

Restricción	Explicación
Docker	El proyecto de desplegará en un Host Docker.
Tecnología	Se empleará React.
Documentación	Se usará la plantilla Arc42.
Base de datos	Se empleará MongoDB como base de datos por su sencillez y facilidad de uso. Además es la base de datos empleada en la base del proyecto.
Pruebas	Cobertura, Pruebas de aceptación (e2e), Pruebas de carga.
WikiData	Se empleará WikiData para obtener la información para generar las preguntas y respuestas.

Restricción

Explicación

Docker

El proyecto de desplegará en un Host Docker.

Tecnología

Se empleará React.

Documentación

Se usará la plantilla Arc42.

Base de datos

Se empleará MongoDB como base de datos por su sencillez y facilidad de uso. Además es la base de datos empleada en la base del proyecto.

Pruebas

Cobertura, Pruebas de aceptación (e2e), Pruebas de carga.

WikiData

Se empleará WikiData para obtener la información para generar las preguntas y respuestas.

2.2. Restricciones organizativas

Restricción	Explicación
Reuniones	Se realizarán reuniones semanales los lunes de 13:00 a 15:00. Estas reuniones se verán reflejadas en GitHub a través de un acta. Podrían realizarse reuniones entre semana si fuese necesario.
GitHub Issues	Para permitir al profesorado llevar un seguimiento del trabajo en equipo se emplearán los Issues de GitHub para reflejar la asignación de tareas así como el diágolo entre semana del equipo.
Tamaño del equipo	El equipo está formado por 4 personas.

Restricción

Explicación

Reuniones

Se realizarán reuniones semanales los lunes de 13:00 a 15:00. Estas reuniones se verán reflejadas en GitHub a través de un acta. Podrían realizarse reuniones entre semana si fuese necesario.

GitHub Issues

Para permitir al profesorado llevar un seguimiento del trabajo en equipo se emplearán los Issues de GitHub para reflejar la asignación de tareas así como el diágolo entre semana del equipo.

Tamaño del equipo

El equipo está formado por 4 personas.

3. Alcance y Contexto del Sistema

3.1. Contexto de Negocio

Diagram

Elementos

Descripción

Inputs

Outputs

WIQ

La aplicación que gestiona el juego de preguntas. Utiliza los datos del usuario, Wikidata y MongoDB para generar y administrar el juego de preguntas y respuestas.

Datos de registro del usuario, datos de Wikidata basados en el tipo de pregunta que se quiere obtener,búsquedas y registros de información de MongoDB relacionados con el sistema.

Preguntas y respuestas generadas para el juego, historial de partidas y estadísticas del usuario.

User

Participa en el juego respondiendo preguntas y poseerá un historial de las partidas que jugó y sus estadísticas.

Datos de registro.

Historial de partidas y estadísticas.

Wikidata

Proporcionará los datos necesarios para generar preguntas y respuestas de manera automática. El propósito es acceder a esta información y se extraer aquellos datos que puedan resultar útiles para generar dichas preguntas.

Datos en base al tipo de pregunta que se quiere obtener.

Datos en base a la consulta para generar las preguntas y respuestas.

Base de datos (MongoDB)

Se encargará de guardar información pertinente de WIQ.

Realización de búsquedas y registro de información asociada relacionados con el sistema.

Cualquier dato que haya sido almacenado perteneciente al sistema.

3.2. Contexto técnico

Diagram

4. Estrategia de solución

4.1. Decisiones tecnologicas

React: Biblioteca de JavaScript que usaremos para implementar la interfaz gráfica. Su principal ventaja es que utiliza un enfoque basado en componentes, lo que significa que las interfaces de usuario se dividen en componentes reutilizables que encapsulan el estado y el comportamiento.
Docker: Unidad de software que utilizaremos para ejecutar la aplicación de manera aislada de otros procesos del sistema mediante el concepto de imágenes, que son plantillas de solo lectura que contienen el sistema operativo, las herramientas, las bibliotecas y el código fuente de una aplicación.
JavaScript: Lenguaje de programacion elegido por ser un lenguaje dinámico y flexible, muy común en la programacion web y multiplataforma.
Node.js: Entorno de ejecución de JavaScript elegido por su rendimiento y velocidad, lo que lo hace ideal para aplicaciones en tiempo real como juegos.
Github Desktop: Utilizado por algunos miembros del equipo como Github IDE.
Wikidata: Base de datos colaborativa y abierta que usaremos para extraer las preguntas para nuestro juego.
MongoDB: Base de datos no relacional, basada en un modelo de datos de documentos JSON, lo que nos facilitará la evolución del esquema sin requerir una estructura fija como en las bases de datos relacionales tradicionales.

4.2. ¿Cómo se van a alcanzar los objetivos de calidad?

Usabilidad: Nuestras interfaces serán intuitivas y fáciles de usar para cualquier persona gracias al framework React.
Mantenibilidad: La aplicación sera facilmente adaptable gracias a nuestro enfoque por componentes, lo que nos permitirá tener un código poco acoplado y con mucha cohesión.
Eficiencia: La conexión con la base de datos y Wikidata para extraer las preguntas será rápida para mantener la atención de los usuarios.
Estabilidad: Nuestra aplicación será resistente a caidas y fallos para poder permitir una buena experiencia de juego.
Testeabilidad: El equipo testeará la aplicacion manual y automaticamente mediante pruebas de obertura, pruebas de aceptación (e2e) y pruebas de carga.

5. Vista de bloques

5.1. Nivel 0:

Diagram

Name	Responsibility
Usuario	Usuario que interactuará con la aplicación.
WIQ	Responsable de la gestión del juego.
WikiData	Permite generar preguntas y respuestas.

Name

Responsibility

Usuario

Usuario que interactuará con la aplicación.

WIQ

Responsable de la gestión del juego.

WikiData

Permite generar preguntas y respuestas.

5.2. Nivel 1:

Diagram

Name	Responsibility
Usuario	Usuario que interactuará con la aplicación.
WebApp	Interfaz gráfica de usuario. Mostrará las preguntas junto con sus posibles respuestas.
Microservicios	Partes encargadas de distintas funcionalidades.
MongoDB	Base de datos. Almacenaje de información acerca de los usuarios y las preguntas generadas.
WIQ	Responsable de la gestión de la aplicación. Engloba la GUI, los microservicios y la base de datos.
WikiData	Permite generar preguntas y respuestas.

Name

Responsibility

Usuario

Usuario que interactuará con la aplicación.

WebApp

Interfaz gráfica de usuario. Mostrará las preguntas junto con sus posibles respuestas.

Microservicios

Partes encargadas de distintas funcionalidades.

MongoDB

Base de datos. Almacenaje de información acerca de los usuarios y las preguntas generadas.

WIQ

Responsable de la gestión de la aplicación. Engloba la GUI, los microservicios y la base de datos.

WikiData

Permite generar preguntas y respuestas.

5.3. Nivel 2:

Diagram

Name	Responsibility
Usuario	Usuario que interactuará con la aplicación.
WebApp	Interfaz gráfica de usuario. Mostrará las preguntas junto con sus posibles respuestas.
UserService	Gestiona la creación de nuevos usuarios.
AuthService	Gestiona la autenticación de los usuarios (Inicio de sesión).
QuestionGenerator	Realiza consultas a WikiData para generar las preguntas y respuestas.
GameHistoryService	Genera y consulta el historial de los usuarios.
PerfilService	Genera el perfil del usuario consultando su información en la base de datos.
AllQuestionService	Gestiona la API de preguntas.
AllUsersService	Gestiona la API de usuarios.
GatewayService	Gestión de las peticiones.
MongoDB	Base de datos. Almacenaje de información acerca de los usuarios y las preguntas generadas.
WIQ	Responsable de la gestión de la aplicación. Engloba la GUI, los microservicios y la base de datos.
WikiData	Permite generar preguntas y respuestas.

Name

Responsibility

Usuario

Usuario que interactuará con la aplicación.

WebApp

Interfaz gráfica de usuario. Mostrará las preguntas junto con sus posibles respuestas.

UserService

Gestiona la creación de nuevos usuarios.

AuthService

Gestiona la autenticación de los usuarios (Inicio de sesión).

QuestionGenerator

Realiza consultas a WikiData para generar las preguntas y respuestas.

GameHistoryService

Genera y consulta el historial de los usuarios.

PerfilService

Genera el perfil del usuario consultando su información en la base de datos.

AllQuestionService

Gestiona la API de preguntas.

AllUsersService

Gestiona la API de usuarios.

GatewayService

Gestión de las peticiones.

MongoDB

Base de datos. Almacenaje de información acerca de los usuarios y las preguntas generadas.

WIQ

Responsable de la gestión de la aplicación. Engloba la GUI, los microservicios y la base de datos.

WikiData

Permite generar preguntas y respuestas.

6. Vista de ejecución

6.1. Funcionamiento de las partidas

Un usuario solicita comenzar una partida. La interfaz de usuario (WebApp) pide una pregunta al generador de preguntas (QuestionGenerator), proceso que se repetirá tantas veces como número de preguntas haya solicitado el usuario. Diagram

6.2. Generación de preguntas

Cuando la interfaz de usuario solicita una pregunta el generador de preguntas deberá realizar una consulta a Wikidata obteniendo así información para formular la pregunta y sus respuestas. Diagram

6.3. Visualización del histórico y perfil de usuario

Cuando el usuario solicite visualizar el histórico se enviará una petición al GameHistoryService quien proporcionará la información al usuario. Diagram

Cuando el usuario solicite visualizar su perfil se enviará una petición al PerfilService quien proporcionará la información de su perfil al usuario.

Diagram

7. Vista de despliegue

Diagram

Elementos	Descripción
Azure	Servidor donde se desplegará la máquina virtual.
Máquina virtual	En la que se desplegará la aplicación.
Motor de Docker	Ejecutará los contenedores.
Microservicios	GameHistoryService, QuestionGenerator … Gestionarán la aplicación web.

Elementos

Descripción

Azure

Servidor donde se desplegará la máquina virtual.

Máquina virtual

En la que se desplegará la aplicación.

Motor de Docker

Ejecutará los contenedores.

Microservicios

GameHistoryService, QuestionGenerator … Gestionarán la aplicación web.

8. Conceptos transversales

8.1. Modelo de dominio

Diagram

Usuario: Representa el cliente de nuestra aplicación. Podrán jugar a un numero ilimitado de juegos, y tendrán un único historicos en el que se almacenaran sus partidas y sus estadísticas.

Juego: Es la propia partida en sí. Un juego siempre será único debido a la aleatoriedad de las preguntas. Por tanto, un juego contendrá las preguntas que aparecen en el.

Pregunta: Las preguntas tendrán las posibles respuestas y la correcta almacenadas, junto con su enunciado y el tiempo que tarda en responderla el usuario.

Historico: Representan las estadísticas del jugador, con datos como el número de preguntas acertadas, falladas, tiempo medio de juego, además de las partidas jugadas y sus preguntas.

9. Decisiones de arquitectura

Durante el desarrollo de la aplicación, va a ser necesario abordar problemas a medida que surjan, lo que conlleva la toma de decisiones a lo largo del proceso. Aunque inicialmente se establecieron ciertas decisiones, estas se verán sujetas a cambios a lo largo del proyecto. En el siguiente cuadro se detallan algunas de las decisiones de diseño que se adoptaron actualmente debido a restricciones arquitectónicas:

Decisión

Ventajas

Desventajas

React

Relativamente sencillo de aprender en comparación con otras bibliotecas front-end, y su popularidad en la web sigue creciendo.

No todos los componentes del equipo trabajaron con el.

Node.js

Plataforma de desarrollo eficiente y escalable para construir aplicaciones web y de red en tiempo real utilizando JavaScript.

La ejecución de operaciones intensivas de CPU puede ser menos eficiente debido al modelo de un solo subproceso.

Docker

La implementación es rápida y permite mover y mantener aplicaciones con facilidad. Además, resulta sencillo gracias a los ejemplos disponibles de DockerFiles.

Ningún miembro del equipo tiene experiencia con el.

MongoDB

No requiere activación manual y es gratuito, además de ser fácil de comprender.

Es menos común para el grupo trabajar con bases de datos no relacionales.

WikiData

Ofrece una fuente de datos colaborativa, estructurada y de acceso libre que alimenta numerosas aplicaciones y proyectos.

La fiabilidad y precisión de los datos pueden variar debido a su naturaleza colaborativa y abierta a ediciones de usuarios no verificados.

Plantilla Arc42

Proporciona una estructura clara y completa para documentar la arquitectura de software, facilitando la comprensión y la comunicación entre los equipos de desarrollo.

Puede resultar demasiado detallada y compleja para proyectos pequeños o simples.

10. Requerimientos de calidad

10.1. Árbol de calidad

Diagram

10.2. Escenarios de calidad

Requisito de calidad

Escenario de calidad

Prioridad

Usabilidad

Nuestra aplicación tiene que ser fácil de usar para todo tipo de usuario, incluso para uno sin experiencia. Las vistas deben ser claras e intuitivas, y el usuario tiene que poder navegar con fluidez por toda la aplicación. Además, se deben implementar los mecanismos necesarios para facilitar el uso de la aplicación por parte de los usuarios.

Alto

Estabilidad

Alto

Mantenibilidad

El sistema debe poder ser modificado fácilmente para por ejemplo, poder añadir nuevos modos de juego o nuevas temáticas. Para esto será necesaria también una documentacion clara y completa.

Medio-alto

Eficiencia

La velocidad de conexión y navegación debe ser lo suficientemente rápida para mantener la atención de los usuarios y no aburrirlos, brindando una experiencia fluida a través de la aplicación.

Medio-bajo

Testeabilidad

La solicitud debería poder pasar por diferentes pruebas y completarlas con éxito. Además, la aplicación debe estar preparada para todo tipo de usos lógicos por parte del usuario.

Medio-bajo

11. Riesgos y deuda técnica.

Riesgo	Explicación	Solución
Organización	Es la primera vez que nos enfrentamos a realizar un proyecto de cero en el que no tenemos unas pautas a seguir y debemos organizarnos, diseñar y desarrollar en base a los requisitos propuestos.	Realizar una análisis de los requisitos para comprender el proyecto solicitado. En base a este análisis dedicar tiempo para realizar una planificación detallada, en la que se incluya aspectos como: aprendizaje de nuevas tecnologías, prototipado y pruebas, implementación, redacción de la documentación etc.
Tiempo disponible	Al realizar este proyecto en paralelo a otras asignaturas el tiempo que tenemos disponible para el proyecto se reduce.	Semanalmente se hace un reparto de trabajo. El peso del trabajo semanal puede variar en función del tiempo del que disponga cada miembro del equipo, pero asegurandonos de que al final del proyecto todos hayamos contribuido lo mismo.
Docker	Es una tecnología con la que ningun miembro del equipo ha trabajado.	Dedicar tiempo de aprendizaje a esta tecnología.
GitHub	Aunque hemos trabajado previamente con Github estamos usando funcionalidades con las que aún no habíamos trabajado y por tanto, con las que no estamos familiarizados.	Dedicar tiempo de aprendizaje.
Comunicación	La comunicación se realiza mayoritariamente en diferido debido a que cada miembro del equipo tiene sus propios horarios. Esto puede ralentizar al resolución de dudas de los miembros del equipo, problemas de implementación etc.	Debemos hacer un esfuerzo para estar disponibles el mayor tiempo posible. Además si fuese necesario podrían realizarse reuniones a través de Discord.
Documentación	Previamente no habíamos realizado ninguna documentación técnica de un proyecto.	Es fundamental dedicar tiempo a esta parte del proyecto así como comunicar posibles dudas tanto a otros miembros del equipo como al profesorado.

Riesgo

Explicación

Solución

Organización

Es la primera vez que nos enfrentamos a realizar un proyecto de cero en el que no tenemos unas pautas a seguir y debemos organizarnos, diseñar y desarrollar en base a los requisitos propuestos.

Realizar una análisis de los requisitos para comprender el proyecto solicitado. En base a este análisis dedicar tiempo para realizar una planificación detallada, en la que se incluya aspectos como: aprendizaje de nuevas tecnologías, prototipado y pruebas, implementación, redacción de la documentación etc.

Tiempo disponible

Al realizar este proyecto en paralelo a otras asignaturas el tiempo que tenemos disponible para el proyecto se reduce.

Semanalmente se hace un reparto de trabajo. El peso del trabajo semanal puede variar en función del tiempo del que disponga cada miembro del equipo, pero asegurandonos de que al final del proyecto todos hayamos contribuido lo mismo.

Docker

Es una tecnología con la que ningun miembro del equipo ha trabajado.

Dedicar tiempo de aprendizaje a esta tecnología.

GitHub

Aunque hemos trabajado previamente con Github estamos usando funcionalidades con las que aún no habíamos trabajado y por tanto, con las que no estamos familiarizados.

Dedicar tiempo de aprendizaje.

Comunicación

La comunicación se realiza mayoritariamente en diferido debido a que cada miembro del equipo tiene sus propios horarios. Esto puede ralentizar al resolución de dudas de los miembros del equipo, problemas de implementación etc.

Debemos hacer un esfuerzo para estar disponibles el mayor tiempo posible. Además si fuese necesario podrían realizarse reuniones a través de Discord.

Documentación

Previamente no habíamos realizado ninguna documentación técnica de un proyecto.

Es fundamental dedicar tiempo a esta parte del proyecto así como comunicar posibles dudas tanto a otros miembros del equipo como al profesorado.

12. Informe de pruebas

12.1. Pruebas de cobertura

Las pruebas de cobertura prueban la funcionalidad de la aplicación creando, al mismo tiempo, una métrica que indica cuanto del código creado está cubierto por dichas pruebas. Las pruebas se han realizado en todos los servicios de la aplicación, a fin de comprobar que la funcionalidad de estos es la esperada.

Para las pruebas de cobertura se ha utilizado, principalmente, las liberías:

testing-library/react
supertest
axios
sinon

A continuación, se explica para que se ha utilizado cada una de dichas librerías:

Librería	Contenido	Uso
testing-library/react	Contiene todas las funciones necesarias para hacer pruebas con los componentes de REACT como: render, fireEvent, act o waitFor	Para los tests de los componentes de REACT que se encuentran en webapp
supertest	La función request que se utiliza para realizar peticiones	Para todas aquellas pruebas que requieran comprobar una petición a una URL, incluyendo el envío de parámetros y la comprobación de la respuesta
axios	Todas las funciones necesarias para hacer Mocks	Para todos los tests que requerían del uso de mocks. Por ejemplo, para probar el juego hemos mockeado las llamadas al generador de preguntas, para no depender de este
sinon	Contiene la función stub que permite sobresscribir los métodos HTTP al realizar peticiones	Principalmente, para los tests en los que había que simular un cierto valor de respuesta o un error en la petición sin necesidad de causar dicho error al hacer la petición

Librería

Contenido

Uso

testing-library/react

Contiene todas las funciones necesarias para hacer pruebas con los componentes de REACT como: render, fireEvent, act o waitFor

Para los tests de los componentes de REACT que se encuentran en webapp

supertest

La función request que se utiliza para realizar peticiones

Para todas aquellas pruebas que requieran comprobar una petición a una URL, incluyendo el envío de parámetros y la comprobación de la respuesta

axios

Todas las funciones necesarias para hacer Mocks

Para todos los tests que requerían del uso de mocks. Por ejemplo, para probar el juego hemos mockeado las llamadas al generador de preguntas, para no depender de este

sinon

Contiene la función stub que permite sobresscribir los métodos HTTP al realizar peticiones

Principalmente, para los tests en los que había que simular un cierto valor de respuesta o un error en la petición sin necesidad de causar dicho error al hacer la petición

Además de todas estas librerías externas, utilizamos, para practicamente todas las pruebas, el framework jest, muy utilizado para hacer las pruebas de proyectos que utilizan REACT, como es nuestro caso. Este framework es el que nos permite definir los casos de prueba y controlar las peticiones que realizamos utilizando, por ejemplo, la función spyOn que nos permite espionar una función o petición.

12.2. Pruebas de usabilidad

A pesar de no disponer del tiempo suficiente para realizar pruebas de usabilidad con muchos participantes decidimos, para detectar posibles mejoras, realizarlas con un número bajo de usuarios.

12.2.1. Resultados

Usuarios con un nivel informático alto

Observaciones

Rápida comprensión de la aplicación.
No encontraron problemas para acceder a todo el contenido de la aplicación.
Destacan poder filtar el ranking en base a diferentes valores.
Destacan que la interfaz de la aplicación es original y distinta a otras de este mismo tipo de juegos.

Propuestas

Mejora en los tiempos de respuesta de algunas preguntas.
Añadir música y/o sonidos.
Mejorar el tiempo de espera de las preguntas.
Añadir un sistema de cambio/recuperación de contraseña.

Puntuación media de los usuarios: 9.5

Usuarios con un nivel informático medio

Observaciones

Buena comprensión de la aplicación.
Dificultad para responder algunas preguntas.
En un principio escogieron un tiempo bajo. Al ver que algunas preguntas eran dificiles aumentaron el tiempo en las siguientes partidas, esto mejoró su experiencia.
No pueden ver el tiempo en algunas preguntas de imagenes.

Propuestas

Añadir preguntas más sencillas.
Intentar ajustar mejor el tamaño de las imagenes para que se pueda ver el tiempo.

Puntuación media de los usuarios: 8.25

Usuarios con un nivel informático bajo

Observaciones

Media/baja comprensión de la aplicación.
Mejor experiencia con la versión de móvil debido a una dificultad con el uso del ratón.
Dificultad para responder preguntas de informática, y alguna de cultura.
No accedieron al menú lateral por lo que no visualizaron todo el contenido de la aplicación.
Dificultad para leer algunos textos.
Entretenida y con una buena temática general.

Propuestas

Aumento del tamaño del letra.

Puntuación media de los usuarios: 7

13. Glosario

Término	Definición
API	Application Programming Interface. Pieza de código que permite a diferentes aplicaciones comunicarse entre sí y compartir información y funcionalidades.
Docker	Plataforma software que permite crear, probar e implementar aplicaciones rapidamente empaquetando software en unidades estandarizadas llamadas contenedores.
GitHub	Servicio basado en la nube que aloja un sistema de control de versiones llamado Git.
Plantilla Arc42	Estructura para documentas sistemas de software
React	Libreria de JavaScript para el desarrollo de aplicaciones móviles y web
Software	Conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora.
Stakeholders	Individuos o grupos interesados en un producto.
Usabilidad	Facilidad con que las personas pueden utilizar una herramienta particular o cualquier otro objeto fabricado por humanos con el fin de alcanzar un objetivo concreto.
WikiData	Es una base de conocimientos editada en colaboración y alojada por la Fundaciín Wikimedia

Término

Definición

API

Application Programming Interface. Pieza de código que permite a diferentes aplicaciones comunicarse entre sí y compartir información y funcionalidades.

Docker

Plataforma software que permite crear, probar e implementar aplicaciones rapidamente empaquetando software en unidades estandarizadas llamadas contenedores.

GitHub

Servicio basado en la nube que aloja un sistema de control de versiones llamado Git.

Plantilla Arc42

Estructura para documentas sistemas de software

React

Libreria de JavaScript para el desarrollo de aplicaciones móviles y web

Software

Conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora.

Stakeholders

Individuos o grupos interesados en un producto.

Usabilidad

Facilidad con que las personas pueden utilizar una herramienta particular o cualquier otro objeto fabricado por humanos con el fin de alcanzar un objetivo concreto.

WikiData

Es una base de conocimientos editada en colaboración y alojada por la Fundaciín Wikimedia