diff --git a/images/10_QualityTree.png b/images/10_QualityTree.png index e18090f6..592b0b7b 100644 Binary files a/images/10_QualityTree.png and b/images/10_QualityTree.png differ diff --git a/images/12-SonarCloud-Coverage.png b/images/12-SonarCloud-Coverage.png new file mode 100644 index 00000000..e7ef2890 Binary files /dev/null and b/images/12-SonarCloud-Coverage.png differ diff --git a/images/DeploymentView_2.png b/images/DeploymentView_2.png new file mode 100644 index 00000000..ad9e7f63 Binary files /dev/null and b/images/DeploymentView_2.png differ diff --git "a/images/Iniciar sesi\303\263n.png" "b/images/Iniciar sesi\303\263n.png" new file mode 100644 index 00000000..38d42776 Binary files /dev/null and "b/images/Iniciar sesi\303\263n.png" differ diff --git a/images/Jugar.png b/images/Jugar.png new file mode 100644 index 00000000..69b57d21 Binary files /dev/null and b/images/Jugar.png differ diff --git a/images/Registrar usuario.png b/images/Registrar usuario.png new file mode 100644 index 00000000..081c3d71 Binary files /dev/null and b/images/Registrar usuario.png differ diff --git a/images/Sequence diagram.png b/images/Sequence diagram.png deleted file mode 100644 index 641917c8..00000000 Binary files a/images/Sequence diagram.png and /dev/null differ diff --git a/images/Ver historial.png b/images/Ver historial.png new file mode 100644 index 00000000..624da890 Binary files /dev/null and b/images/Ver historial.png differ diff --git a/index.html b/index.html index 9be9cb3a..408d90ae 100644 --- a/index.html +++ b/index.html @@ -446,7 +446,7 @@

arc42WI -
  • 11. Riesgos y deuda técnica
    • -
  • 12. Glosario
    • +
  • 11. Riesgos y deuda técnica + +
    • +
  • 12. Pruebas realizadas + +
    • +
  • 13. Glosario
    • @@ -604,7 +614,7 @@

    1. Introducción y Metas

    -

    1.1. Vista de Requerimientos

    +

    1.1. Vista de Requisitos

    @@ -646,8 +656,12 @@

    1.1. Vista de Requerimientos

    -

    Creación de usuarios e historial

    -

    Un usuario se podrá registrar en la web y consultar los resultados de sus anteriores partidas.

    +

    Creación de usuarios

    +

    Para acceder al juego, el usuario tendrá que estar registrado en la aplicación.

    + + +

    Historial

    +

    Un usuario registrado podrá consultar los resultados de sus anteriores partidas a través de un historial.

    Preguntas creadas automáticamente

    @@ -706,10 +720,6 @@

    1.2. Metas de Calidad

    La interfaz de usuario será sencilla de entender y de usar

    -

    Rendimiento

    -

    La aplicación tendrá tiempos de carga rápidos y respuestas ágiles

    - -

    Adaptabilidad

    La aplicación se podrá usar en distintos dispositivos

    @@ -773,9 +783,9 @@

    1.3. Partes interesadas (Stakeholders) -Role/Name -Contact -Expectations +Rol +Contacto con la aplicación +Expectativas @@ -797,7 +807,12 @@

    1.3. Partes interesadas (Stakeholders)

    HappySw

    Es la empresa de desarrollo de software

    -

    Que el equipo de desarrollo realice un producto extraordinario para que la empresa contratante este satisfecha con el producto final

    +

    Que el equipo de desarrollo realice un producto de buena calidad para que la empresa contratante este satisfecha con el producto final

    + + +

    Profesores Arquitectura del Software

    +

    Personas encargadas de evaluar el proyecto

    +

    Esperan que el equipo de desarrollo cumpla con los requisitos obligatorios en la aplicación final

    @@ -845,7 +860,8 @@

    2.1. Restricciones técnicas

    API Wikidata

    -

    Las preguntas y soluciones a estas deben ser generadas a través de la API de Wikidata, que permite acceder a toda la información alojada en ella. Sin embargo, esta información puede ser poco fiable debido a que es de acceso público y puede ser modificada por cualquiera. También se debe tener en cuenta la estructura de Wikidata a la hora de acceder a los datos, ya que se basa en entidades y relaciones.

    +

    Las preguntas y soluciones a estas deben ser generadas a través de la API de Wikidata, que permite acceder a toda la información alojada en ella. Sin embargo, esta información puede ser poco fiable debido a que es de acceso público y puede ser modificada por cualquiera. +También se debe tener en cuenta la estructura de Wikidata a la hora de acceder a los datos, ya que se basa en entidades y relaciones, además del tiempo de acceso a esta API la cual puede relentizar el juego.

    Desplegar la aplicación en un servidor

    @@ -853,11 +869,11 @@

    2.1. Restricciones técnicas

    GitHub

    -

    Todo el código de la aplicación se alojará en GitHub y se usarán ramas para ejecutar cualquier tipo de cambio significativo a la apliación. Los commits deben tener nombres explicativos.

    +

    Todo el código de la aplicación se alojará en GitHub y se usarán ramas para ejecutar cualquier tipo de cambio significativo a la apliación. Los commits deben tener nombres explicativos y podría haber conflictos en los merge.

    Pruebas

    -

    Se crearán pruebas de distintos tipos. La aplicación debe pasar estas pruebas para asegurar su funcionamiento.

    +

    Se crearán pruebas de distintos tipos. La aplicación debe pasar estas pruebas para asegurar su funcionamiento, el fallo de alguna de las pruebas bloqueará el despliegue.

    @@ -884,6 +900,10 @@

    2.2. Restricciones de organización

    Actas e Issues

    Todas las decisiones y trabajo hecho se debe ver reflejado en el GitHub del grupo. Cada semana se deben hacer actas donde se tomen decisiones y se reparta el trabajo, que se verá reflejado en los issues.

    + +

    Evaluaciones intermedias

    +

    Cada 3 semanas el proyecto será evaluado y se tomarán nota de los avances y correccciones que se deben hacer para la siguiente evaluación

    +
    @@ -1116,19 +1136,25 @@

    4.1. Decisiones Tecnológicas

    • -

      Microsoft Azure: es una plataforma de computación en la nube que ofrece servicios de infraestructura, plataforma y software como servicio, para poder administrar servicios en línea.

      +

      Microsoft Azure: es una plataforma de computación en la nube que ofrece servicios de infraestructura, plataforma y software como servicio, para poder administrar servicios en línea.

    • -

      MongoDB: es un sistema de bases de datos NoSQL, es decir, una base de datos orientada a documentos. Este almacena datos con formato similar JSON, que no tienen que cumplir con una estructura predefinida.

      +

      MongoDB: es un sistema de bases de datos NoSQL, es decir, una base de datos orientada a documentos. Este almacena datos con formato similar JSON, que no tienen que cumplir con una estructura predefinida.

    • -

      TypeScript: es un lenguaje de programación de código abierto desarrollado y mantenido por Microsoft. Es un superconjunto tipado de JavaScript que compila a JavaScript puro y es compatible con todas las funcionalidades de este último.

      +

      JavaScript: es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se utiliza para crear páginas web dinámicas.

    • -

      WikiData: es una base de datos libre, colaborativa y multilingüe, que sirve como una base de datos secundaria y que recopila datos estructurados para dar soporte a Wikipedia, Wikimedia Commons…​

      +

      React: es una biblioteca de JavaScript para construir interfaces de usuario.

    • -

      Docker: se utiliza para hacer el despligue de la aplicación.

      +

      WikiData: es una base de datos libre, colaborativa y multilingüe, que sirve como una base de datos secundaria y que recopila datos estructurados para dar soporte a Wikipedia, Wikimedia Commons…​

      +
      • +
    • +

      Docker: se utiliza para hacer el despligue de la aplicación.

      +
      • +
    • +

      Bootstrap: es un framework de código abierto para el diseño de sitios y aplicaciones web.

    @@ -1138,16 +1164,44 @@

    4.2. Motivaciones

    Hemos escogido TypeScript por su mayor parecido a Java, ya que nuestro equipo en su mayoría lo domina. En cuanto React nos basemos en que facilmente se puede crear interfaces. El resto de tecnologías son las más óptimas y las prestablecidas, en el proyecto. Realmente estamos a la espera de los resultados de estas decisiones, ya que en su mayoría son tecnologías desconocidas para el equipo.

    +
    +
      +
    • +

      Microsoft Azure: la universidad nos proporciona crédito para Azure, por lo que no tendremos que pagar por el servicio y es una plataforma que ya conocemos por otras asignaturas del grado.

      +
      • +
    • +

      MongoDB: el formato de los datos de MongoDB nos facilita mucho el guardado de datos en la aplicación

      +
      • +
    • +

      JavaScript: aunque no lo dominamos completamente, es un lenguaje que nos era familiar y muy usado en el desarrollo web, además combinamos su uso con la biblioteca de React.

      +
      • +
    • +

      React: esta biblioteca facilita el uso de los componentes de la aplicación y, además el proyecto inicial lo usaba por lo que no se ha tenido que construir la aplicación desde cero.

      +
      • +
    • +

      WikiData: su uso es un requisito obligatorio de esta aplicación pero su istema de consultas SPARQL ha resultado muy útil a la hora de obtener las preguntas de forma dinámica y actualizada para el juego.

      +
      • +
    • +

      Docker: ya configurado en el proyecto inicial por lo que pudimos crear contenedores de forma sencilla.

      +
      • +
    • +

      Bootstrap: permite crear la interfaz de usuario de forma más sencilla y con diseños más agradables al cliente.

      +
      • +
    +

    4.3. Decisiones sobre cómo alcanzar los objetivos clave de calidad

    • -

      Usabilidad: Queremos una aplicación que no cause quebraderos de cabeza al usuario, que sea simple y eficiente.

      +

      Usabilidad: Será una aplicación sencilla, sin demasiados distractores y con los enlaces necesarios para el funcionamiento correcto del juego únicamente. Se tratará de que resulte intuitiva y fácil de usar.

      +
      • +
    • +

      Seguridad: Se configurarán los endpoints para que un usuario no autentificado pueda acceder a partes restringidas de la aplicación. Además los usuarios serán guardados con su contraseña encriptada.

    • -

      Seguridad: Autenticación de usuarios y encriptado de contraseñas.

      +

      Disponibilidad: El uso de Azure nos garantiza un 99,9% de disponibilidad, aunque hay que restar la dependencia que tenemos con otros servicios como wikidata o mongoDB, de todas maneras se tratará de que la aplicación tenga la mayor disponibilidad posible.

    • Utilizaremos el patrón MVC(Modelo, Vista, Controlador): Facilita la modularidad, la reutilización y el mantenimiento del código, provocando una aplicación eficiente.

      @@ -1160,14 +1214,20 @@

      4.4. Decisiones organizativas:

      • -

        Reparto de tareas: Las tareas se reparten teniendo en cuenta las habilidades de cada uno de los integrantes del equipo.

        +

        Las tareas se reparten teniendo en cuenta las habilidades de cada uno de los integrantes del equipo y su disponibilidad.

      • -

        Los miembros del equipo mantenemos comunicación por Whatsaap para las dudas que surjan.

        +

        Los miembros del equipo mantenemos comunicación más directa a través de WhatsApp y Discord para las dudas que surjan u otras decisiones que haya que tomar en conjunto.

      • Si un miembro del equipo tiene problemas con su tarea, entre los integrantes del grupo se resolverá.

        • +
      • +

        Durante el laboratorio de la asignatura, se realizarán reuniones en las que se expondrá el trabajo realizado y si alguno ha tenido algún problema con su tarea.

        +
        • +
      • +

        Si algún miembro decide abandonar el proyecto, se repartirán sus tareas pendientes entre los miembros restantes.

        +
      @@ -1473,37 +1533,48 @@

      6. Vista de Ejecución

    -

    6.1. <Escenario de ejecución 1>

    -
    -
      -
    • -

      <insert runtime diagram or textual description of the scenario>

      -
      • -
    • -

      <insert description of the notable aspects of the interactions between the -building block instances depicted in this diagram.>

      -
      • -
    -
    +

    6.1. Registrar usuario

    -

    It is possible to use a sequence diagram:

    +

    Un usuario se registra para poder jugar.

    -Sequence diagram +Registrar usuario
    -

    6.2. <Runtime Scenario 2>

    - +

    6.2. Iniciar sesión

    +
    +

    Un usuario que ya está registrado, inicia sesión con su usuario y contraseña para jugar.

    +
    +
    +
    +Iniciar sesión +
    +
    -

    6.3. …​

    - +

    6.3. Ver historial

    +
    +

    Un usuario quiere ver su historial del juego.

    +
    +
    +
    +Ver historial +
    +
    -

    6.4. <Runtime Scenario n>

    +

    6.4. Jugar y generación de preguntas

    +
    +

    Un usuario procede a jugar, se generan las preguntas y a continuación iniciará el juego.

    +
    +
    +
    +Jugar +
    +
    @@ -1634,7 +1705,7 @@

    7.2.1. <Elemento de Infraestructu

    -Deployment View +Deployment View
    @@ -1755,39 +1826,29 @@

    8. Conceptos Transversales (Cross-cutting)

    -

    Este es el modelo inicial de nuestra aplicación, pero evolucionará con el tiempo.

    +

    Modelo de la aplicación:

    -
    clase Usuario{
-    id: String
-    nombre: String
-    fecha_registro: String
+
    clase Usuario {
+    username: String
+    password: String
+    createdAt: String
 }
 
-clase Partida{
-    id: String
-    puntuación: int
-    preguntas: Array<Pregunta>
-    preguntas_acertadas: int
-    preguntas_falladas: int
+clase Record {
+    username: String
+    correctQuestions: int
+    totalQuestions: int
+    totalTime: int
+    doneAt: Date
 }
 
-clase Pregunta{
-    id: String
-    texto: String
-    respuestas: Array<Respuesta>
-}
-
-clase Respuesta{
-    id: String
-    texto: String
-    correcta: boolean
-}
-
-Usuario 1 ---> * Partida
-Partida 1 ---> (5..20) Pregunta
-Pregunta 1---> (2..4) Respuesta
    
+clase Pregunta {
+    pregunta: String
+    correcta: String
+    incorrectas: Array<String>(3)
+}
    @@ -1797,25 +1858,19 @@

    8.1. Arquitectura principal

    -

    8.2. Reglas al usar una tecnología específica:

    -
    -

    Realmente no sabemos demasiado sobre las tecnologías elegigidas, con la evolución del equipo mejoraremos esta sección.

    -
    -
    -
    -

    8.3. Reglas de implementación

    +

    8.2. Reglas de implementación

    Como es un proyecto en equipo creemos que la colaboración es lo más importante, por eso hemos decidido comentar lo máximo posible nuestro propio código para que sea entendible por otras personas/compañeros de equipo.

    -

    8.4. Interfaz de usuario.

    +

    8.3. Interfaz de usuario.

    Queremos crear una aplicación accesible para todos los usuarios, que sea simple de entender y de jugar, que lo máximo que tengas que pensar sean las preguntas del juego.

    -

    8.5. Privacidad

    +

    8.4. Privacidad

    Los usuarios se tienen que autenticar para poder utilizar la aplicación, además sus contraseñas están encriptadas.

    @@ -2028,19 +2083,14 @@

    10.2. Escenarios de calidad

    El usuario quiere utilizar la aplicación con facilidad

    -

    La aplicación tendrá tiempos de ejecución cortos

    -

    Rendimiento

    -

    Cuando el usuario comience una partida en el juego habrá tiempos de espera cortos

    - -

    La aplicación podrá ser usada en distintos dispositivos

    Adaptabilidad

    Un usuario podrá usar la aplicación en móvil, tablet u ordenador

    -

    La aplicación estará disponible la mayoría del tiempo

    +

    La aplicación estará disponible el 95% del tiempo.

    Disponibilidad

    -

    La aplicación no tendrá caídas inesperadas

    +

    Un usuario accede a la aplicación a las 6 de la tarde y esta estará disponible

    Los datos de cada usuario estarán guardados de forma segura

    @@ -2078,6 +2128,8 @@

    11. Riesgos y deuda técnica

    +
    +

    11.1. Riesgos

    @@ -2091,28 +2143,95 @@

    11. Riesgos y deuda técnica

    + + + + + + + + - - + + + + +

    Abandono de miembros del grupo

    Cuantas menos personas seamos, más trabajo tendremos que realizar los demás miembros.

    Trabajo en equipo

    La falta de coodinación y comunicación puede llevar a malos resultados en el trabajo. Tampoco tenemos experiencia trabajando en una aplicación desde 0.

    Abandono de miembros del equipo

    Si uno o más miembros abandonan el equipo de desarrollo, la carga de trabajo para el resto se incrementará y, por tanto, aumentará la probabilidad de errores y deuda ténica por falta de tiempo.

    Falta de experiencia con WikiData

    No estamos muy familiarizados con WikiData y su estructura. Tenemos que aprender a hacer queries a la API de WikiData.

    Desconocimiento de React

    Nunca hemos trabajado con React.

    Desconocimiento de algunas tecnologías utilizadas como NodeJS o React

    Hasta el desarrollo de esta aplicación no habíamos trabajado con estas tecnologías y, por tanto, pueden ocasionar errores o retrasos durante el parendizaje de las mismas.

    +
    +
    +

    11.2. Deuda Técnica

    +
    +

    Se ha ocasiaonado deuda técnica en el proyecto debido en gran medida a la falta de tiempo y al abandono de 4 miembros del equipo, 2 de ellos nunca se presentaron y los otros 2 abandonaron la asigntura durante el desarrollo. A continuación se inidican las principales decisiones tomadas que han ocasionado deuda técnica en este proyecto:

    +
    + ++++ + + + + + + + + + + - - + + + + + +
    Deuda TécnicaExplicación

    Pruebas de carga

    No se han podido realizar pruebas de carga ya que por los factores anteriormente indicados, decidimos priorizar las pruebas unitarias y las de end to end frente a las de carga.

    Desconocimiento de Node.js

    Nunca hemos trabajado con Node.js.

    Requisitos opcionales

    Se ha priorizado aquellos requisitos obligatorios frente a los opcionales, pudiendo realizar solo uno de estos.

    Rendimiento de las preguntas

    Nos gustaría haber tenido el rendimiento como atributo de calidad pero debido al abandono de varios miembros del grupo se decidió dar prioridad a terminar el proyecto completo, que a mejorar otros aspectos como el rendimiento.
    +
    -

    12. Glosario

    +

    12. Pruebas realizadas

    +
    +
    +

    A continuación se recogen los diferentes tipos de pruebas realizados para garantizar el correcto funcionamiento de la aplicación y cumplir con el límite de coverage del 80% que se requería para el proyecto.

    +
    +
    +

    12.1. Pruebas Unitarias

    +
    +

    Se han realizado un total de 43 pruebas unitarias repartidas entre los servicios y componentes de la aplicación. Se ha utilizado la librería Jest para realizar estas pruebas, además de otras más especializadas dependiendo del test como la librería de testing de React para los componentes o Axios para simular las llamadas a los endpoints.

    +
    +
    +

    Con estos test se ha conseguido cubrir un 90'9% del código presente en la aplicación, proporcionando una alta fiabilidad del correcto funcionamiento de la misma. +A continuación se muestra el resumen proporcionado por SonarCloud sobre la calidad de nuestro código:

    +
    +
    +
    +12 SonarCloud Coverage +
    +
    +
    +
    +

    12.2. Pruebas E2E (End to End)

    +
    +

    Se han realizado 5 pruebas E2E a las funciones más importantes de la aplicación: Login, register, Game y Record. Estas pruebas se han reallizado utilizando las librerías de Pupeteer y Jest-Cucumber, las cuales nos permiten probar su funcionalidad utilizando Chromium.

    +
    +
    +
    +
    +
    +
    +

    13. Glosario

    @@ -2163,14 +2282,6 @@

    12. Glosario

    -

    WikiData

    -

    Base de conocimientos con una gran cantidad de datos. Extraeremos datos de WikiData a través de la API que nos proporciona. Construiremos las preguntas con estos datos.

    - - -

    MVC

    -

    Modelo de arquitectura de software. Las aplicaciones que siguen este modelo se dividen en 3 capas, Modelo, Vista y Controlador.

    - -

    GitHub

    Plataforma de desarrollo colaborativo. Todo el código del equipo, su trabajo realizado y sus reuniones se documentan aquí.

    @@ -2179,21 +2290,25 @@

    12. Glosario

    Es un sistema de base de datos NoSQL, orientado a documentos. La base de datos de nuestra aplicación esta hecha con MongoDB.

    -

    React

    -

    Biblioteca JavaScript diseñada para crear interfaces de usuario. La usaremos para hacer el front-end de la aplicación.

    +

    MVC

    +

    Modelo de arquitectura de software. Las aplicaciones que siguen este modelo se dividen en 3 capas, Modelo, Vista y Controlador.

    Node.js

    Es un entorno en tiempo de ejecución para la capa del servidor basado en JavaScript. La usaremos para gran parte de el back-end de la aplicación.

    -

    TypeScript

    -

    Es un lenguaje de programación que esencialmente añade tipos estáticos y objetos basados en clases. Lo usaremos como lenguaje de programación para nuestra aplicación.

    - -

    Query

    Conjunto de palabras o frase que se utiliza cómo término de búsqueda. Usaremos queries para conseguir información de la base de datos o de WikiData.

    + +

    React

    +

    Biblioteca JavaScript diseñada para crear interfaces de usuario. La usaremos para hacer el front-end de la aplicación.

    + + +

    WikiData

    +

    Base de conocimientos con una gran cantidad de datos. Extraeremos datos de WikiData a través de la API que nos proporciona. Construiremos las preguntas con estos datos.

    +
    @@ -2202,7 +2317,7 @@

    12. Glosario