About arc42
arc42, the template for documentation of software and system architecture.
Template Version 8.2 EN. (based upon AsciiDoc version), January 2023
Created, maintained and © by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. See https://arc42.org.
1. Introducción y Objetivos
WIQ se trata de una aplicación web desarrollada por HappySw para RTVE que permite a los usuarios jugar online a un juego de preguntas y respuestas.
Los usuarios tienen la posibilidad de responder a estas preguntas seleccionando una de las cuatro opciones proporcionadas y ganar dinero por cada acierto. Podrán ver su histórico de participaciones para intentar mejorarlas y ver un ranking de los mejores jugadores.
Tanto preguntas cómo las respuestas son generadas de manera automática a partir de los datos de Wikidata para evitar su posible desactualización.
1.1. Descripción general de los requisitos
Los requisitos principales son:
-
Debe poder accederse al juego a través de la Web.
-
Los usuarios deben poder registrarse, acceder mediante sus credenciales y consultar el histórico de su participación en el sistema.
-
Las preguntas y sus posibles respuestas deben ser generadas automáticamente a partir de los datos de Wikidata.
-
Debe haber un tiempo máximo para contestar a todas las preguntas.
-
Cada pregunta debe tener una única respuesta correcta y tres incorrectas que see generan automáticamente.
-
Se debe poder acceder a la información de los usuarios y de las preguntas generadas a través de un API.
-
Debe permitir cambiar los parámetros del juego.
-
Debe haber un ranking de usuarios ordenado según sus estadísticas.
1.2. Objetivos de calidad
Los objetivos de calidad en orden de prioridad son los siguientes:
| Objetivo | Escenario | Prioridad |
|---|---|---|
Usabilidad |
La aplicación contará con una interfaz clara y fácil de entender, permitiendo a cualquier usuario jugar sin dificultades. |
Alta |
Disponibilidad |
La aplicación estará disponible durante al menos el 95% del tiempo para permitir a los usuarios jugar la mayor cantidad de tiempo posible minimizando interrupciones dejando unas 8 horas y media de mantenimiento semanales. |
Alta |
Rendimiento |
Los usuarios tendrán tiempos de respuesta cortos por parte del sistema contando con un máximo de 2 segundos para garantizar una mejor experiencia durante el juego. |
Media/Alta |
Mantenibilidad |
La aplicación debe programarse de manera que no genere muchos problemas hacer un cambio. |
Media |
Accesibilidad |
Cualquier usuario tendrá las mismas oportunidades que el resto sin importar sus capacidades físicas o cognitivas. |
Media |
1.3. Stakeholders
Los stakeholders de la aplicación junto con sus expectativas son:
| Rol | Contacto | Expectativas |
|---|---|---|
Cliente |
RTVE |
Tener una aplicación que permita acceder a un juego de preguntas y respuestas. |
Compañia desarrolladora |
HappySw |
Satisfacer al cliente. |
Desarrolladores |
Sergio Díaz, Laura Menéndez, Jesús García, Luis Miguel Gómez |
Crear una aplicacion que cumpla los requisitos del cliente. |
Coordinadores |
Jose Emilio Labra Gayo y Jorge Álvarez Fidalgo |
Proporcionar soporte a los desarrolladores para que consigan su objetivo. |
Usuarios |
Cualquiera que acceda a la aplicación |
Poder jugar a un juego de preguntas y respuestas. |
Tecnologías usadas |
JavaScript, React, Wikidata, Node.js, MongoDB, Azure… |
Conseguir promoción debido a su uso en diferentes proyectos. |
2. Restricciones de la arquitectura
Las restricciones de la arquitectura de este proyecto son las siguientes:
| Restricción | Explicación |
|---|---|
Uso de Wikidata |
Se debe usar obligatoriamente la API de Wikidata para obtener los datos necesarios para generar las preguntas y las respuestas dentro del juego. |
Despliegue |
La aplicación deberá consistir en una aplicación web, no pudiendo ser una aplicación móvil o de escritorio. |
Acceso a datos mediante APIs |
El acceso a datos relacionados con los usuarios que participan y las respuestas a las preguntas deberá realizarse con una API. |
Presupuesto reducido |
El presupuesto para el proyecto es limitado, reduciéndose únicamente a lo que cada desarrollador esté dispuesto a desembolsar de su propio bolsillo. |
Consecuencias de las limitaciones:
-
La aplicación web deberá estar suficientemente optimizada para su uso en navegadores, atendiendo a aspectos relacionados con el rendimiento, la usabilidad y la disponibilidad.
-
El presupuesto reducido implicará un uso mayor de herramientas de código abierto, reduciendo drásticamente el uso de software bajo licencia.
-
El uso de Wikidata reducirá la carga de trabajo de la aplicación, al no tener que trabajar sobre una base de datos local.
-
Al usar la api de Wikidata somos dependientes de su disponiblidad y en caso de fallar tambien fallaria nuestra aplicación.
3. Alcance y contexto del sistema
Nuestro proyecto, denominado "WIQ", consiste en una simulación inspirada en el famoso juego de RTVE "Saber y Ganar" (más información en: https://www.rtve.es/play/videos/saber-y-ganar/), en el cual los concursantes tienen la oportunidad de hacerse con una cantidad de dinero en función del número de respuestas acertadas a preguntas de diversas temáticas, con un límite establecido de tiempo para cada una de ellas.
La aplicación permitirá a los usuarios no solo acumular dinero al participar en la funcionalidad básica de juego de preguntas y respuestas, funcionalidad la cual es personalizable, sino que cuenta también con las opciones de visualizar un ranking, poder consultar su historial de jugadas así como el listado completo de usuarios registrados entre otras más.
3.1. Contexto de negocio
Al acceder a la página principal de la aplicación, los usuarios podrán ver una interfaz que les permitirá iniciar sesión para acceder a su cuenta. En caso de ser su primera vez y no tener cuenta, tendrán la opción de registrarse. Una vez autenticados, los usuarios se encontrarán con la opción tanto de empezar un nuevo juego como de realizar otras operaciones que se pueden visualizar en la barra de navegación, como el historial de jugadas, el ranking y la opción de modificar los ajustes de la partida.
Dentro del historial, este les mostrará el número de partidas totales realizadas y, por cada una de ellas, la fecha en la que se jugó, el número de respuestas acertadas, el dinero conseguido y el tiempo total que les llevó completarlo.
En el ranking, podrán ver destacados los tres usuarios con mejor porcentaje de aciertos, así como las estadísticas del ranking de todos los usuarios.
Aparte de todo lo anterior, el administrador contará con la opción de visualizar el listado completo de usuarios registrados hasta la fecha, así como la posibilidad de ver todo el historial de preguntas que se han generado.
3.2. Contexto técnico
Para el desarrollo de este proyecto, utilizaremos la API de Wikidata tanto para generar automáticamente las preguntas como para obtener las respuestas correctas a las mismas. En cuanto al lenguaje de programación, se utilizará JavaScript, utilizando React para el desarrollo del front-end. Además, haremos uso de Node.js y la implementación de microservicios para el back-end. Respecto a la base de datos, usaremos una NoSQL como MongoDB.
| Interfaz técnica | Explicación |
|---|---|
Wikidata |
API usada para generar automáticamente las preguntas y obtener su respuesta. |
JavaScript |
Lenguaje principal de la aplicación. |
React |
Librería JavaScript que nos permitirá construir la interfaz de la aplicación. |
MongoDB Cloud |
Base de datos NoSQL. |
Node.Js |
Entorno de servidor para tratar los endpoints. |
Azure |
Usado para el despliegue de la aplicación en la nube. |
4. Estrategia de solución
4.1. Decisiones tecnologicas
Para desarrollar la aplicación, seleccionamos las siguientes tecnologías:
-
React.js: Biblioteca de JavaScript que usaremos para implementar la interfaz gráfica.
-
Docker: Es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores de software.
-
JavaScript: Es un lenguaje de programacion orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico.
-
Node.js: Es una entorno de ejecucion muy conocido para el desarrollo del back-end de aplicaciones web
-
Wikidata: Base de conocimientos que usaremos para realizar las preguntasd de nuestra aplicación.
-
MongoDB Cloud: Es un sistema de base de datos NoSQL, orientado a documentos y de código abierto.
-
GitHub: Es una plataforma para alojar proyectos utilizando el sistema de control de versiones Gitç
-
Microsoft Azure: Es una plataforma de servicios en la nube que usaremos para el despliegue de la aplicación.
4.2. Descomposición de alto nivel
4.2.1. Herramientas de diagramado
Usaremos PlantUML, VisualParadigm y Draw.io para la creacion de diagramas para la documentacion.
4.3. Enfoques para lograr objetivos de máxima calidad
| Objetivo de calidad | Escenario | Enfoque de solución |
|---|---|---|
Usabilidad |
La ejecución de todas las funciones de la aplicación es crucial para la satisfacción del usuario. |
Optimizaremos la usabilidad gracias al framework React. |
Mantenibilidad |
La aplicacion debe poseer la capacidad de ser modificado con facilidad. |
Gracias al uso de patrones de diseño conseguiremos un codigo limpio y facil de mantener. Ademas, priorizaremos las pruebas durante el desarrollo. |
Escalabilidad |
La aplicacion debe adapatarse a los cambios futuros sin esfuerzo. |
Emplearemos microservicios para la minimizacion de la repeticion de codigo y mejorar la comprension de este. |
Accesibilidad |
Cualquier usuario tendrá las mismas oportunidades que el resto sin importar sus capacidades físicas o cognitivas. |
Haremos una interfaz limpia, clara, sencilla y con colores accesibles |
Rendimiento |
Los usuarios tendrán tiempos de respuesta cortos por parte del sistema contando con un máximo de 2 segundos para garantizar una mejor experiencia durante el juego. |
Optimizaremos las consultas a Wikidata y el codigo para minimzar los tiempos de respuesta. |
Disponibilidad |
La aplicación estará disponible durante al menos el 95% del tiempo para permitir a los usuarios jugar la mayor cantidad de tiempo posible. |
Se minimizaran interrupciones dejando unas 8 horas y media de mantenimiento semanales. |
4.4. Decisiones de organizacion
-
Idioma: El proyecto, que abarca código y documentación, se desarrollará en español como idioma principal.
-
Problemas: Todos los problemas encontrados y las tareas encomendads se documentarán como "issues" en GitHub.
-
GitHub: Con esta herramienta conseguiremos trabajar cooperativamente y usar las herramientas que ofrece para juntar los proyectos de los diferentes integrantes del equipo.
-
Comunicacion: Para la comunicación entre los integrantes del equipo, usaremos tanto la aplicacion de mensajeria móvil "WhatsApp", como "Discord".
-
Revisiones periódicas: Para hacer una en común de lo realizado, decisiones del trabajo que se iba a realizar a posterior, apertura y asignación de issues (apertura también de issues que se pudieran incorporar de cara al futuro). También lse llevan a cobo reuniones extraordinarias para cercionarnos que cumpliamos con todo correctamente en cada entrega.
-
Actas: Realización de hay un acta por cada reunión realizada, incluidas las extraordinarias, en ellas especificábamos los miembros que acudieron, la revisión de logros de lo llevado desde la última reunión, la toma de decisiones y las issues asignadas a cada persona.
-
No división entre front y back: Para trabajar todos los miembros en ambas partes y principalmente para no vernos limitados a que las personas dedicadas al front tengan que adaptarse a los tiempos y esperar a que se tenga terminado el back y de esta manera hacer un trabajo más fluido.
-
Ramas: Se decidió crear una rama para cada miembro del equipo, una rama Dev en la que volcaríamos el trabajo de cada rama individual y que posteriormente iría a máster. También se podrían crear otras ramas si se considerase necesario.
-
Issues: Las issues deben estan asignadas al menos a un par de personas para garantizar su desarrollo.
5. Vista de bloques de construcción
5.1. Vista general del sistema
A continuación se muestra el diagrama que muestra una vista completa y genérica de lo que será la estructura de la aplicación en su entorno. Se divide en tres principales componentes que mediante interacciones detalladas en los siguientes apartados lograrán una ejecución correcta del sistema.
Diagrama de vista general
- Motivación
-
La vista general de la aplicación y de su entorno es sencilla a la par que esquemática. Se observan tres componentes descriptivamente titulados: el individuo que hará uso de la aplicación (denominada "WIQ" en el diagrama) la cual a su vez recurrirá a un servicio externo, la API de WikiData, para llevar a buen puerto una serie de labores descritas en posteriores apartados.
- Bloques contenidos
Nombre |
Responsabilidad |
User |
Se trata del usuario que accede a la aplicación. |
WIQ |
Se trata del bloque genérico que contiene todo lo relativo a la aplicación que desarrollaremos. |
WikiData API |
Se trata de la api de Wikidata que da el contenido para la creación de las preguntas. |
5.2. Nivel 2
5.2.1. Caja blanca "WIQ"
En este apartado pasaré a describir en forma de "white box", bloque que en el diagrama de vista general hacía referencia a la aplicación al completo de manera genérica. En esta vista divisoria de la estructura de la aplicación ya comenzamos a distinguir componentes más concretos.
-
"WebApp" es el componente con el que interactúa el usuario cuando entra en la aplicación y que trabaja con los demás componentes de este diagrama. "Users Manager" se trata del bloque de la aplicación encargado, como su nombre indica, del manejo de los usuarios, tanto los nuevos como los ya registrados en nuestro sistema. "Question Manager" se trata del conjunto de microservicios encargado de la generación y almacenaje de preguntas. Además observamos ya el "Gateway Service" que hace de puerta de enlace para los diferentes microservicios gestionando el flujo de peticiones dentro de nuestro juego. Los microservicios a los que redirige sus peticiones el "Gateway Service", se detallarán más adelante.
Nombre |
Responsabilidad |
Gateway Service |
Su cometido es el de gestionar las peticiones dentro del juego para redirigirlas a los microservicios correspondientes, centralizando así las peticiones dentro del producto. |
Users Manager |
Se encarga de gestionar la autenticación de los usuarios que traten de loggearse con sus credenciales en la aplicación así como de llevar un registro de los usuarios que ya tengan sus credenciales guardadas en el sistema. |
Question Manager |
Su labor es interactuar con la API de WikiData para generar nuevas preguntas de manera dinámica así como de generar respuestas correctas e incorrectas para esas mismas cuestiones. |
5.3. Nivel 3
5.3.1. Caja blanca "Users Manager"
Este esquema concreta la estructura interna del bloque "Users Managemer" que se encarga, descrito de manera rápida y locuaz, de gestionar las credenciales, fechas de registro y peticiones de login de los usuarios ya registrados y también de aquellos que traten de registrarse por primera vez en nuestra aplicación. También está entre sus labores la de mantener un registro actualizado del ranking (porcentaje de aciertos, numero de partidas jugadas…) de cada uno de los usuarios registrado (lo hará en una base de datos dedicada específicamente a ello).
El diagrama se divide en tres principales componentes (User Service, Authentication Service, Ranking Service) que interactuan con sus respectivas bases de datos.
Nombre |
Responsabilidad |
User Service |
Microservicio encargado de llevar el registro de los usuarios que se vayan creando durante el tiempo que la aplicación permanece desplegada así como de sus credenciales, fecha de registro… |
Authentication Service |
Microservicio encargado de la autenticación de usuarios que traten de loggearse en la aplicación basándose en las credenciales registradas en la base de datos. |
Ranking Service |
Microservicio cuya labor consiste en registrar en la base de datos "rankingdb" los datos globales del conjunto de partidas jugadas por cada usuario registrado en "userdb". |
User Database |
Se encarga de almacenar información de la aplicación para garantizar la persistencia de la misma (p.e: usuarios, contraseñas, registro histórico de puntuaciones…). |
Ranking Database |
Almacena información sobre el histórico de cada usuario. Entre la información almacenada está: Porcentaje de aciertos, preguntas acertadas, preguntas falladas, número total de partidas y el nombre del usuario. |
5.3.2. Caja blanca "Question Manager"
Este segundo esquema trata de describir con mayor hondura el funcionamiento interno del bloque "Question Manager". Esta funcionalidad se divide en cuatro microservicios y tan solo uno de ellos interactúa directamente con la API de WikiData para extraer de este servicio externo la información trascendental y necesaria para producir nuevos interrogantes (preguntas) y respuestas a los mismos.
Cabe destacar que los microservicios "GeneratedQuestion Service" y "Create Service" comparten una misma base de datos "questiondb" pero utilizan dos colecciones diferentes ("generatedquestions" y "questions" respectivamente). El microservicio "GeneratedQuestions" se encarga de almacenar preguntas completas y, solamente, las respuestas correctas de cada una de las preguntas (lo hace para poder mostrar en cierta funcionalidad del juego las preguntas que ya han sido generadas a modo de "enciclopedia"). Por otro lado el microservicio "Create Service" almacena en su base de datos las plantillas de las preguntas (p.e: "¿Cuál es la capital de ") y el "typeQuestion" (cadena de texto) que resulta relevante dentro de la lógica del microservicio para extraer la "query" (consulta de WikiData) idónea para conseguir completar la pregunta y obtener sus respuestas correctas e incorrectas.
Los otros dos microservicios son "QuestionGenerator" y "Record". Cada uno de ellos utiliza una base de datos separada para almacenar: el primero de ellos las preguntas con todas sus respuestas (correcta e incorrectas) que se irían generando en el "CreateService"; el segundo de ellos las puntuaciones de cada una de las partidas que se juegen por cada uno de los usuarios.
Nombre |
Responsabilidad |
Create Service |
Se encarga de, gracias a la interacción con la API de WikiData, generar las preguntas que vayan a presentarse al usuario durante el transcurso de la partida en curso. |
GeneratedQuestion Service |
Se encarga de almacenar las preguntas generadas y sus respuestas correctas para mostrarlas en una especie de recopilatorio de preguntas generadas que se podrán consultar en la aplicación. |
QuestionGenerator Service |
Almacena las preguntas completas (interrogante, respuestas incorrectas y respuesta correcta) para poder mostrarlas durante la partida. |
Record Service |
Registra las estadísticas de cada una de las partidas (de manera independiente para cada partida) de cada uno de los jugadores. |
Question Database |
Contiene dos colecciones, una con las bases de las preguntas para generar las preguntas completas usando la API de wikidata y la segunda para almacenar las preguntas y respuestas correctas (que corresponderían a las que le han sido mostradas al usuario). |
QuestionGenerator Database |
Almacena las preguntas generadas de wikidata junto con su respuesta correcta y sus tres incorrectas. |
Record Database |
Almacena todas las jugadas realizadas. |
5.3.3. Gateway Service
Se trataría de un microservicio que hace de nexo entre los diferentes microservicos y las a estos desde el frontend
*Cabe destacar que hemos situado Record Service en el paquete relativo a las preguntas. Esto lo hemos hecho así porque creemos que mantiene mayor relación con las mismas y con el "juego" en sí, más que con el paquete relativo a la información de los usuarios. Sin embargo, la decisión contraria también tiene su lógica.
6. Vista en Tiempo de Ejecución
6.1. Registro en la aplicación
6.2. Inicio de sesión en la aplicación
6.3. Generacion de preguntas
6.4. Respuesta a una pregunta
6.5. Consulta del historial de usuarios
6.6. Consulta del historial de preguntas generadas
6.7. Consulta del historial de jugadas
6.8. Consulta del ranking
6.9. Cambio de ajustes de partida
7. Vista de despliegue
7.1. Infrastructura Nivel 1
- Características de calidad
-
La aplicación garantizará un correcto funcionamiento y respuesta independientemente del número de usuarios quela utilicen simúltaneamente para ofrecer una experiencia óptima.
- Mapeo de bloques de construcción a la infraestructura
Elemento |
Descripción |
Webapp |
Se trata del frontend de la aplicación que será desplegado en el navegador. |
Gateway |
Funciona de interemediario conectando la WebApp con los diferentes microservicios, conectando así todos los componentes. |
Services |
Son los microservicios encargados de implementar las diferentes funcionalidades de la aplicación. |
MongoDB |
Es la base de datos elegida para el almacenaje de la información crucial de la aplicación, se encuentra en la nube. |
Client |
Navegador con el que interactúa el usuario para hacer uso de la aplicación. |
8. Conceptos transversales
8.1. Descripción de conceptos
8.1.1. Dominio
8.1.2. Experiencia de usuario (UX)
-
Interfaz usable:
Facilidad de uso |
Se mostrará un diseño de interfaz sencilla de uso, predecible y familiar, colocando todos los elementos y opciones importantes de la aplicación de forma que sean fácilmente accesibles. Se usará también un estilo que hará alusión al famoso juego de "Saber y Ganar" en el que está basado. |
Intuitiva |
El sistema de juego de la aplicación seguirá lo más fielmente posible el formato de preguntas y respuestas del juego de "Saber y Ganar" en base al número de preguntas que se harán en cada jugada, el tiempo disponible para cada pregunta, el número de respuestas disponibles a seleccionar y la cuantía del premio para generar una sensación de familiaridad. |
Solidez |
Los tiempos de espera de carga de la aplicación se buscarán que sean los mínimos posibles para que la experiencia sea fluida. |
-
Inmediata retroalimnetacion: El usuario verá de forma inmediata si ha acertado o no la pregunta contestada. Así como el historial de jugadas, ranking, y preguntas generadas estará actualizado en todo momento.
8.1.3. Seguridad y protección
-
Control de acceso seguro: Seguridad en la autenticación del usuario, comprobando que sean correctos los datos introducidos y no dejando entrar en caso contrario.
-
Registro de actividad: La aplicación está hecha para garantizar la protección de los usuarios respecto a las contraseñas, las cuales se encripta. También el historial de jugadas esta protegido ya que cada usuario solo puede ver su propio historial.
8.1.4. "Under-the-hood"
-
Persistencia: Tanto los datos del usuario como de las jugadas quedarán almacenados asegurando su integridad y disponilibilidad.
-
Mantenibilidad: El código está escrito de forma clara y legible, se sigue un enfoque modular que permitirá la facilidad en su mantenimiento a la hora de tener que corregir fallos o añadir alguna mejora.
-
Extensibilidad: Aplicación construida de forma que se podrá añadir de una forma sencilla nuevas funcionalidades en el futuro sin afectar en gran manera a partes ya existentes.
8.1.5. Desarrollo
-
Implementación: Para la creación de esta aplicación se usará el lenguaje de programación JavaScript, para el front-end se utilizará React, Node.js y la construccion de microservicios para el back-end y MongoDB para la gestion de la base de datos NoSQL.
-
Pruebas: Se llevarán a cabo pruebas e2e, de carga y unitarias todas ellas para garantizar la ejecución correcta de todas las funcionalidades de la aplicación.
8.1.6. Estilo arquitecónico
-
Capas: Se utilizará un diseño basado en estas 3 capas principales para tener una mejor organización de la aplicación y otorgar a la misma una modularidad
Presentación |
Se va a utilizar para operar y generar la interfaz gráfica que se le mostrará al usuario. |
Negocio |
Aquí será donde se llevará a cabo toda la lógica correspondiente que hace posible el correcto funcionamiento de la aplicación. Se utilizará para poder generar las diferentes preguntas del juego de forma automática, así como sus posibles respuestas, entre otras funcionalidades como la creación del historial de cada jugador. |
Persistencia |
Para almacenar y obtener los diferentes datos que se necesiten, tanto para el jugador como para el sistema de juego de preguntas y respuestas. |
8.2. Mapa de conceptos
9. Decisiones arquitectonicas
| Decision | Razones |
|---|---|
React.js |
Hemos decidido usar React.js puesto que es una de las librerias mas populares de java. Tambien hay personas del equipo de desarrollo familiarizadas con el uso de esta libreria, por lo que pueden ayudar al resto del equipo con la implementacion del front-end. |
Javascript |
Elegimos seguir con Javascript para el desarrollo de esta aplicación web porque ya teniamos conocimientos de este lenguaje. Tambien porque es un lenguaje ampliamente conocido por su uso en aplicaciones web, permitiendo mejoras en la interfaz de usuario y paginas web dinámicas. |
Mongodb Cloud |
Lo consideramos más práctico puesto que todos los cambios hechos eran visibles por todos los miembros del grupo, especialmente a la hora de necesitar añadir datos por ejemplo para hacer pruebas o para las bases de las preguntas usadas para generar las preguntas completas de wikidata, de esta manera no necesitábamos añadirlos los cuatro en local para probar la aplicación. |
Node.js |
Para interactuar con la base de datos decidimos usar Node.js. Es una entorno de ejecucion muy conocido para el desarrollo del back-end de aplicaciones web, por lo que creemos que es buena idea usarlo. |
Microservicios |
Permite descomponer la aplicación en distintos componentes independientes, que fecilitan la escalabilidad y el despliegue independiente. También resulta mas sencillo a la hora de su mantenimiento. |
Azure |
A pesar de que no tenemos una gran experiencia con Azure, contamos con más conocimiento sobre esta plataforma en comparación con otros competidores, ya que ha sido utilizada anteriormente en otras asignaturas de esta carrera. |
10. Requisitos de calidad
Los requisitos de calidad son la piedra angular del desarrollo de nuestro proyecto/aplicación. En ellos debemos basar nuestra implementación y es nuestra obligación a la hora de desarrollar un producto de calidad el haber garantizado el cumplimiento de la inmensa mayoría (por no decir, de todos).
-
Tabla descriptiva: (los requisitos marcados con * son aquellos dotados de mayor prioridad)
Requisito de Calidad |
Descripción |
Escenario |
|
Usabilidad |
Nuestro objetivo será tratar de garantizar que la aplicación resulte fácil de utilizar para cualquier tipo de usuario (Interfaz de usuario clara y de sencilla comprensión). |
SC1 |
* |
Disponibilidad |
La aplicación deberá permanecer disponible en el mayor ratio de tiempo posible, proporcionando así una experiencia satisfactoria al público de la misma que pueda disfrutar de ella cuando deseen. |
* |
|
Seguridad |
Se asegurará la protección de los datos sensibles de los usuarios así como se dará garantía de que los datos almacenados a modo de registro hisrórico de puntuaciones permanecerán inmutables. Se bloquearán los accesos no autorizados a la aplicación. |
* |
|
Rendimiento |
Trataremos de minimizar los tiempos de respuesta por parte del sistema tratando así de garantizar la mejor experiencia por parte del usuario. |
SC2 |
* |
Variabilidad y Precisión |
Las preguntas y las respuestas generadas por nuestra aplicación deberán caracterizarse por tener la mayor precisión posible para garantizar que la respuesta correcta sea única. Además deberán abarcar diversos temas para no crear un juego de preguntas monotemáticas. |
SC3 |
|
Accesibilidad |
Aseguraremos una experiencia satisfactoria para todo tipo de usuario por lo que nuestra aplicación pondrá especial atención a la accesibilidad de la misma, previniendo las posibles dificultades que le podrían surgir a los distintos grupos de usuarios según sus capacidades físicas y/o cognitivas. |
SC4 |
* |
10.1. Árbol de requisitos de calidad
En este apartado podemos ver de manera más visual cuáles son los requisitos de calidad representados en forma de árbol con el conocido "quality tree" (tal y como se define en ATAM - Arquitecture Tradeoff Analysis Method) que cuenta con los requisitos en forma de hojas en su diagrama.
10.2. Escenarios de calidad
A la hora de describir los requisitos de calidad de la aplicación de generación de preguntas y respuestas que vamos a llevar a cabo es plausible que algunos de los mismos hayan sido explicados de manera excesivamente genérica. Es por esto que en este apartado vamos a mostrar algunos ejemplos más concretos para representar de una manera más comprensible lo que buscamos lograr con nuestra producto.
-
Cabe destacar lo que es un escenario:
-
Un escenario describe lo que debería ocurrir cuando un determinado estímulo llega al sistema/aplicación. También cabe destacar que para los arquitectos existen dos tipos de escenarios:
-
Escenario de uso: Describe la reacción del sistema en tiempo real ante un estímulo.
-
Escenario de cambio: Describe una modificación del sistema o de su entorno (p.e: Funcionalidades añadidas o cambios en los requisitos).
-
Escenarios de uso:
-
-
-
Id |
Explicación |
SC1 |
Un usuario nuevo podrá jugar a nuestro juego sin necesidad de que ninguno de nosotros le explique su funcionamiento. |
SC2 |
Cualquiera de las interacciones del usuario con el juego tendrá respuesta en menos de 2 segundos. |
SC3 |
A lo largo de una misma partida el usuario hará frente a preguntas de diversos temas (deportes, geografía, historia…) |
SC4 |
Un usuario con problemas de visión podrá distinguir todos los elementos de la aplicación (de la interfaz gráfica) perfectamente pudiendo jugar varias partidas y navegar por la aplicación sin problema alguno. |
-
Escenarios de cambio:
La incorporación de nuevos juegos dentro de la aplicación no debería afectar al sistema puesto que la manera en la que se va a implementar el juego propuesto de preguntas garantiza su flexibilidad ante el cambio y su posible extensión en un futuro. |
11. Riesgos y Deudas Técnicas
La lista de riesgos es la siguiente:
| Riesgo | Explicación | Medida |
|---|---|---|
Poca experiencia con las tecnologías usadas |
No tenemos mucha experiencia con las tecnologías que usaremos (React, Node.js, MongoDB…) y se nos puede complicar su uso. |
Investigar sobre ests tecnologías e intentar aprender cómo usarlas correctamente. |
Falta de tiempo |
Hay unos plazos para cada entrega y puede hacersenos corto. |
Ser constantes y hacer lo máximo diariamente. |
Trabajo en equipo |
Trabajar en equipo nos puede ser complicado al no haber hecho nunca un proyecto tan grande de esta manera. |
Mantener una buena comunicación y ser colaborativos. |
Reuniones poco productivas |
Perder mucho tiempo en reuniones y no conseguir avances puede generar problemas. |
Hacer una pequeña preparación de estas para saber que temas tratar en concreto. |
Abandono de un miembro |
Que un miembro deje el trabajo significaría tener que repartir sus tareas y que aumente la carga de trabajo. |
Asignar cada tarea a más de una persona e intentar ayudar para evitar un abandono. |
Fallo de servicios externos |
Un servicio externo utilizado en la aplicación cómo Wikidata o Azure dejan de funcionar durante un tiempo. |
Estar atentos a las novedades de los mismos e intentar que funcione de nuevo lo antes posible. |
La lista de deudas técnicas es la siguiente:
| Deuda técnica | Explicación | Medida |
|---|---|---|
Mala documentación |
No documentar adecuadamente puede generarnos problemas a para comprender el sistema en un futuro y dificultar su mantenimiento. |
Hacer la documentación de la m,manera más detallada y clara posible. |
Mal diseño de la base de datos |
Si se hace un mal diseño de la base de datos y se trabaja sobre él puede generar muchos problemas a medida que el sistema va creciendo. |
Hacer un buen estudio inicial antes de crear la base de datos o modificarla. |
Uso abusivo de una IA para generar código |
Su código generado puede no ser correcto del todo y suponernos un problema el caso de tener que mejorarlo en un futuro. |
Revisar este codigo antes de meterlo en el proyecto e intentar adaptarlo bien. |
12. Testing
Se llevarán a cabo pruebas unitarias, E2E y de carga para garantizar la ejecución correcta de todas las funcionalidades de la aplicación, así como también la monitorización de la aplicación.
12.1. Tests Unitarios
En nuestro proyecto, los tests unitarios son fundamentales para garantizar la correcta funcionalidad de cada componente del código. Cada función, método o clase será probado exhaustivamente para asegurar su integridad y rendimiento. Se intenta tener en todo momento un coverage al menos del 80% y que las pruebas comprueben todas las posibles opciones. En la parte del front y en el gateway utilizamos mocks para su realización.
12.2. E2E. Tests de integración
Buscaremos garantizar que la aplicación sea fácil de usar para proporcionar una experiencia satisfactoria al usuario. Nos centraremos en verificar diversas funcionalidades, desde la jugabilidad hasta acciones como el registro e inicio de sesión. Simularemos interacciones que haría un usuario real para asegurar que la aplicación sea intuitiva y funcione correctamente. Las funcionalidades probadas han sido:
-
Registro
-
Login
-
Registro + Login
-
Mostrado del juego
12.3. Tests de carga
Hemos realizado inicialmente una prueba con un usuario por segundo durante 60 segundos de tal forma que quedaría en un computo total de 60 usuarios. La prueba consiste en logearse, jugar una partida, consultar todos los apartados de la barra de navegación, cambiar los ajustes bajando el numero de preguntas y volviendo a jugar una partida.
Posteriormente realizamos siguiendo una tasa de 2 usuarios por segundo durante 60 segundos llegando a un total de 120 usuarios. Cada usuario haría las mismas operaciones que se han descrito antes.
Finalmente hemos hecho pruebas metiendo un total de 300 usuarios a una tasa de 5 usuarios por segundo duante un tiempo de 60 segundos. Los cuales probarian las mismas funcionalidades que los anteriores.
12.4. SonarCloud
En la siguiente imagen podemos comprobar todos los analisis realizados por SonarCloud.
12.5. Monitorización
Hemos añadido el perfil de producción tanto a prometeus como a grafana en el Docker compose, tras ello procedimos a abrir los puertos 9090 y 9091 en la máquina virtual tal y como se muestra en esta imagen:
12.5.1. Monitorización en remoto
Tras llevar a cabo todo lo anterior hemos pasado a comprobar que nos funcionaba todo correctamente, primero accediendo a prometheus el cual a pesar de abrir los puertos no lograbamos acceder correctamente:
Y por lo tanto a pesar de poder acceder correctamente a grafana no obtenemos ningun resutado del análisis de las distintas peticiones llevadas a cabo en la aplicación:
12.5.2. Monitorización en local
Hemos llevado a cabo también una monitorización en local en la rama master que ha resultado exitosa.
Tal y como se puede apreciar en este caso nos ha cargado correctamente prometheus:
Tras interaccionar con la aplicación un rato hemos accedido a posterior a grafana dando como resultado un número de peticiones falladas( E ) nulo y los consiguientes datos del número de peticiones por minuto( R ) y del tiempo de procesamiento de petición( D ):
13. Glosario
| Término | Definición |
|---|---|
TypeQuestions |
Las distintas categorias que hay de preguntas. |
Record |
Elemento del historial de jugadas. |
QuestionGenerator |
Generador de preguntas a traves de la API de Wikidata. |
Arc42 |
Conjunto de distintas pautas a seguir para la documentacion de un proceso de software. |
Microservicios |
Enfoque de arquitectura que usamos para desarrollar software de manera que se construyan aplicaciones de forma que estas se dividan en elementos pequeños e independientes entre si. |
Wikidata |
Página a partir de la que se obtienen los datos para las preguntas y sus respuestas. |