diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index b70cee55..2928773f 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/docs/src/01_introduction_and_goals.adoc @@ -30,7 +30,7 @@ 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 98% del tiempo para permitir a los usuarios jugar la mayor cantidad de tiempo posible minimizando interrupciones dejando unas 3 horas y media de mantenimiento semanales. | 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 diff --git a/docs/src/02_architecture_constraints.adoc b/docs/src/02_architecture_constraints.adoc index 9a255e79..db7c5664 100644 --- a/docs/src/02_architecture_constraints.adoc +++ b/docs/src/02_architecture_constraints.adoc @@ -35,4 +35,6 @@ y la disponibilidad. 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. diff --git a/docs/src/03_system_scope_and_context.adoc b/docs/src/03_system_scope_and_context.adoc index 2da7ae5e..49725ab2 100644 --- a/docs/src/03_system_scope_and_context.adoc +++ b/docs/src/03_system_scope_and_context.adoc @@ -37,9 +37,12 @@ Para el desarrollo de este proyecto, utilizaremos la API de Wikidata tanto para | React | Librería JavaScript que nos permitirá construir la interfaz de la aplicación. -| MongoDB +| 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. |=== diff --git a/docs/src/04_solution_strategy.adoc b/docs/src/04_solution_strategy.adoc index fcb62493..e17c8449 100644 --- a/docs/src/04_solution_strategy.adoc +++ b/docs/src/04_solution_strategy.adoc @@ -11,14 +11,14 @@ Para desarrollar la aplicación, seleccionamos las siguientes tecnologías: * 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: Es un sistema de base de datos NoSQL, orientado a documentos y de código abierto. +* 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. === Descomposición de alto nivel ==== Herramientas de diagramado -Usaremos VisualParadigm y Draw.io para la creacion de diagramas para la documentacion. +Usaremos PlantUML, VisualParadigm y Draw.io para la creacion de diagramas para la documentacion. === Enfoques para lograr objetivos de máxima calidad @@ -47,8 +47,8 @@ Usaremos VisualParadigm y Draw.io para la creacion de diagramas para la document | Optimizaremos las consultas a Wikidata y el codigo para minimzar los tiempos de respuesta. | Disponibilidad -| La aplicación estará disponible durante al menos el 98% del tiempo para permitir a los usuarios jugar la mayor cantidad de tiempo posible. -| Se minimizaran interrupciones dejando unas 3 horas y media de mantenimiento semanales. +| 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. |=== === Decisiones de organizacion @@ -57,4 +57,8 @@ Usaremos VisualParadigm y Draw.io para la creacion de diagramas para la document - *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. diff --git a/docs/src/05_building_block_view.adoc b/docs/src/05_building_block_view.adoc index f57007d7..69c5a663 100644 --- a/docs/src/05_building_block_view.adoc +++ b/docs/src/05_building_block_view.adoc @@ -19,7 +19,9 @@ La vista general de la aplicación y de su entorno es sencilla a la par que esqu 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. |=== @@ -48,7 +50,7 @@ image::05_bbv_level03.jpg["Level3"] 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 cuatro principales componentes (_User Service_, _Authentication Service_, _Ranking Service_) que interactuan con sus respectivas bases de datos. +El diagrama se divide en tres principales componentes (_User Service_, _Authentication Service_, _Ranking Service_) que interactuan con sus respectivas bases de datos. |=== |Nombre|Responsabilidad @@ -66,7 +68,7 @@ Este segundo esquema trata de describir con mayor hondura el funcionamiento inte 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); el segundo de ellos las puntuaciones de cada una de las partidas que se juegen por cada uno de los usuarios. +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 @@ -74,6 +76,13 @@ Los otros dos microservicios son "QuestionGenerator" y "Record". Cada uno de ell |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. |=== -_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._ +==== 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._ diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc index 7724db85..44e648b0 100644 --- a/docs/src/06_runtime_view.adoc +++ b/docs/src/06_runtime_view.adoc @@ -5,163 +5,244 @@ ifndef::imagesdir[:imagesdir: ../images] === Registro en la aplicación -[plantuml,"Sequence diagram",png] +[plantuml,"Registro usuario",png] ---- actor User participant App -database DB +participant Gateway +participant UserService +database DBuser User -> App: Selecciona opción de registro User <-- App: Muestra pantalla de registro User -> App: Ingresa datos de registro -App -> DB: Comprueba los datos -App <-- DB: Valida los datos +App -> Gateway: Envía los datos +Gateway -> UserService: Envía los datos +UserService -> UserService: Comprueba los datos + alt usuario válido - App -> DB: Guarda datos de registro - App <-- DB: Confirma registro + + UserService -> DBuser: Guarda datos de registro + UserService <-- DBuser: Confirma registro + Gateway <-- UserService : Confirma registro + App<-- Gateway: Confirma registro User <-- App: Confirma Registro -alt usuario inválido + +else usuario no valido + + Gateway <-- UserService: Deniega registro + App <-- Gateway: Deniega registro User <-- App: Deniega registro + +end ---- === Inicio de sesión en la aplicación -[plantuml,"Sequence diagram",png] +[plantuml,"Login usuario",png] ---- actor User participant App -database DB - -User -> App: Ingresa credenciales de inicio de sesión -App -> DB: Verifica cerdenciales -App <-- DB: Válida las credenciales -alt credenciales válidas - User <-- App: Confirma inicio de sesión - alt usuario que nunca habia iniciado sesion - App -> DB: Crea ranking para el usuario - App -> DB: Pide datos de los records de todos los usuarios - App <-- DB: Devuelve datos de los records de todos los usuarios - App -> DB: Actualiza los rankings de todos los usuarios -else credenciales inválidas - User <-- App: Deniega inicio de sesión ----- +participant Gateway +participant AuthService +database DBuser -=== Generacion de preguntas +User -> App: Ingresa credenciales +App -> Gateway: Envía los datos +Gateway -> AuthService: Envía los datos +AuthService-> DBuser: Comprueba los datos -[plantuml,"Sequence diagram",png] +alt usuario válido + + AuthService<-- DBuser: Confirma login + Gateway <-- AuthService: Confirma login + App<-- Gateway: Confirma login + User <-- App: Confirma login + +else usuario no valido + AuthService <-- DBuser : Deniega login + Gateway <-- AuthService: Deniega login + App <-- Gateway: Deniega login + User <-- App: Deniega login + +end ---- -participant WApi -database DB -loop cada 2 segundos - WApi -> DB: Genera una pregunta y la guarda +=== Generacion de preguntas + +[plantuml,"Generacion preguntas",png] +---- +database DBquestions +participant CreateService +participant Gateway +participant QuestionGeneratorService +database DBquestiongenerator + +loop cada 60 segundos + CreateService -> DBquestions: Pide plantilla de pregunta + CreateService <-- DBquestions: Devuelve plantilla de pregunta + CreateService -> CreateService: Genera una pregunta + Gateway <-- CreateService: Envía la pregunta generada + Gateway -> QuestionGeneratorService: Envía la pregunta generada + QuestionGeneratorService-> DBquestiongenerator: Envía la pregunta generada + DBquestiongenerator-> DBquestiongenerator: Guarda la pregunta generada alt mas de 500 preguntas generadas - WApi -> DB: Borra la pregunta que más tiempo lleva guardada + DBquestiongenerator-> DBquestiongenerator: Borra la pregunta que más tiempo lleva guardada + else pregunta existente + DBquestiongenerator-> DBquestiongenerator: Actualiza la pregunta + end +end ---- === Respuesta a una pregunta -[plantuml,"Sequence diagram",png] +[plantuml,"Respuesta pregunta",png] ---- actor User participant App -participant WApi -database DB +participant Gateway +participant GeneratedQuestionService +database DBquestions +participant QuestionGeneratorService +database DBquestiongenerator +participant RecordService +database DBrecords User -> App: Pide una pregunta -App -> DB: Pide una pregunta -App <-- DB: Devuelve una pregunta generada +App -> Gateway: Pide una pregunta +Gateway-> QuestionGeneratorService: Pide una pregunta +QuestionGeneratorService -> DBquestiongenerator: Pide una pregunta +QuestionGeneratorService <-- DBquestiongenerator: Devuelve una pregunta generada +Gateway <-- QuestionGeneratorService : Devuelve una pregunta generada +App <-- Gateway: Devuelve una pregunta generada User <-- App: Muestra pregunta con opciones +Gateway -> GeneratedQuestionService: Envía la pregunta generada +GeneratedQuestionService-> DBquestions: Guarda la pregunta generada alt tiempo no finalizado User -> App: Selecciona opción de respuesta - App -> DB: Verifica respuesta seleccionada - App <-- DB: Confirma la respuesta - App -> DB: Guarda o actualiza la pregunta con su respuesta correcta + App -> App: Verifica respuesta seleccionada alt respuesta correcta alt ultima pregunta User <-- App: Muestra mensaje de respuesta correcta y finaliza el juego - App -> DB: Guarda los datos de la partida + App -> RecordService: Envía los datos de la partida + RecordService -> DBrecords: Guarda los datos de la partida User <-- App: Muestra los datos de la partida else no ultima pregunta User <-- App: Muestra mensaje de respuesta correcta y continua el juego + end else respuesta incorrecta alt ultima pregunta - User <-- App: Muestra mensaje de respuesta correcta y finaliza el juego - App -> DB: Guarda los datos de la partida + User <-- App: Muestra mensaje de respuesta incorrecta y finaliza el juego + App -> RecordService: Envía los datos de la partida + RecordService -> DBrecords: Guarda los datos de la partida User <-- App: Muestra los datos de la partida else no ultima pregunta - User <-- App: Muestra mensaje de respuesta correcta y continua el juego + User <-- App: Muestra mensaje de respuesta incorrecta y continua el juego + end + end else tiempo finalizado - User <-- App: Finaliza el juego - App -> DB: Guarda los datos de la partida + App -> RecordService: Envía los datos de la partida + RecordService -> DBrecords: Guarda los datos de la partida User <-- App: Muestra los datos de la partida +end ---- === Consulta del historial de usuarios -[plantuml,"Sequence diagram",png] +[plantuml,"Historial usuarios",png] ---- actor User participant App -database DB +participant Gateway +participant UserService +database DBuser +alt usuario admin User -> App: Selecciona opción de ver el historial de usuarios -App -> DB: Consulta el historial de usuarios -App <-- DB: Devuelve el historial de usuarios +App -> Gateway: Pide el historial de usuarios +Gateway -> UserService: Pide el historial de usuarios +UserService -> DBuser: Pide todos los usuarios +UserService <-- DBuser: Devuelve todos los usuarios +Gateway <-- UserService: Devuelve todos los usuarios +App <-- Gateway: Devuelve todos los usuarios User <-- App: Muestra el historial de usuarios +end ---- === Consulta del historial de preguntas generadas -[plantuml,"Sequence diagram",png] +[plantuml,"Historial preguntas",png] ---- actor User participant App -database DB +participant Gateway +participant GeneratedQuestionService +database DBgeneratedquestions +alt usuario admin User -> App: Selecciona opción de ver el historial de preguntas generadas -App -> DB: Consulta el historial de preguntas generadas -App <-- DB: Devuelve el historial de preguntas generadas +App -> Gateway: Pide el historial de preguntas generadas +Gateway -> GeneratedQuestionService: Pide el historial de preguntas generadas +GeneratedQuestionService -> DBgeneratedquestions: Pide todas las preguntas generadas +GeneratedQuestionService <-- DBgeneratedquestions: Devuelve todas las preguntas generadas +Gateway <-- GeneratedQuestionService: Devuelve todas las preguntas generadas +App <-- Gateway: Devuelve todas las preguntas generadas User <-- App: Muestra el historial de preguntas generadas +end ---- === Consulta del historial de jugadas -[plantuml,"Sequence diagram",png] +[plantuml,"Historial jugadas",png] ---- actor User participant App -database DB +participant Gateway +participant RecordService +database DBrecord User -> App: Selecciona opción de ver el historial de jugadas -App -> DB: Consulta el historial de jugadas -App <-- DB: Devuelve el historial de jugadas +App -> Gateway: Pide el historial de jugadas +Gateway -> RecordService: Pide el historial de jugadas +RecordService-> DBrecord: Pide todas las jugadas +RecordService<-- DBrecord: Devuelve todas las jugadas +Gateway <-- RecordService: Devuelve todas las jugadas +App <-- Gateway: Devuelve todas las jugadas User <-- App: Muestra el historial de jugadas ---- === Consulta del ranking -[plantuml,"Sequence diagram",png] +[plantuml,"Ranking usuarios",png] ---- actor User participant App -database DB +participant Gateway +participant RankingService +database DBranking User -> App: Selecciona opción de ver el ranking -App -> DB: Consulta el ranking -App <-- DB: Devuelve el ranking +App -> Gateway: Pide el ranking +Gateway -> RankingService: Pide el ranking +RankingService-> DBranking: Pide todos los rankings +RankingService<-- DBranking: Devuelve todos los rankings +Gateway <-- RankingService: Devuelve todos los rankings +App <-- Gateway: Devuelve todos los rankings User <-- App: Muestra el ranking ---- === Cambio de ajustes de partida -[plantuml,"Sequence diagram",png] +[plantuml,"Ajustes partida",png] ---- actor User participant App -database DB +participant Navegador User -> App: Selecciona opción de ajustes de partida -App -> User: Muestra ajustes de partida actuales +App-> Navegador: Pide los ajustes de partida actuales +App <-- Navegador: Devuelve ajustes de partida actuales +User <-- App: Muestra ajustes de partida actuales User -> App: Cambia ajustes de partida actuales +App-> Navegador: Guarda ajustes de partida actuales ---- \ No newline at end of file diff --git a/docs/src/09_architecture_decisions.adoc b/docs/src/09_architecture_decisions.adoc index e5506a82..3ab4ff91 100644 --- a/docs/src/09_architecture_decisions.adoc +++ b/docs/src/09_architecture_decisions.adoc @@ -10,8 +10,9 @@ ifndef::imagesdir[:imagesdir: ../images] 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 |Para el back-end hemos decidido usar la base de datos NoSQL Mongodb, creemos que es una opcion adecuada para almacenar los datos necesarios para el desarrollo de la -aplicacion. +|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. |=== diff --git a/docs/src/10_quality_requirements.adoc b/docs/src/10_quality_requirements.adoc index dec923c5..dd84fb43 100644 --- a/docs/src/10_quality_requirements.adoc +++ b/docs/src/10_quality_requirements.adoc @@ -13,7 +13,7 @@ Los requisitos de calidad son la piedra angular del desarrollo de nuestro proyec |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|* -|Variedad 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| +|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|* |=== diff --git a/docs/src/11_technical_risks.adoc b/docs/src/11_technical_risks.adoc index 1ab6c35f..5e69b285 100644 --- a/docs/src/11_technical_risks.adoc +++ b/docs/src/11_technical_risks.adoc @@ -13,6 +13,7 @@ La lista de riesgos es la siguiente: | 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: diff --git a/docs/src/12_testing.adoc b/docs/src/12_testing.adoc index 9d7e42e5..f7a941b7 100644 --- a/docs/src/12_testing.adoc +++ b/docs/src/12_testing.adoc @@ -6,10 +6,16 @@ Se llevarán a cabo pruebas unitarias, E2E y de carga para garantizar la ejecuci === 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. +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. === 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. +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 === 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. diff --git a/docs/src/13_glossary.adoc b/docs/src/13_glossary.adoc index c195d6a6..43c65fbc 100644 --- a/docs/src/13_glossary.adoc +++ b/docs/src/13_glossary.adoc @@ -7,9 +7,6 @@ ifndef::imagesdir[:imagesdir: ../images] |=== | Término | Definición -| BodyQuestions -| Los diferentes cuerpos que vamos a utilizar de las preguntas base. - | TypeQuestions | Las distintas categorias que hay de preguntas.