Erratas en documentación

.vscode/settings.json

@@ -1 +1,13 @@
-{}
+{
+    "cSpell.language": "en,es-ES,es",
+    "cSpell.words": [
+        "BBDD",
+        "desplegarlo",
+        "distractores",
+        "mantenible",
+        "microservicios",
+        "modularidad",
+        "RTVE",
+        "SPARQL"
+    ]
+}

docs/src/01_introduction_and_goals.adoc

@@ -16,7 +16,7 @@ deben considerar. Entre estas se incluyen:
 Nuestro equipo de desarrollo ha sido contratado por la empresa HappySW para la creación de una aplicación de preguntas y respuestas similar al programa de RTVE "Saber y Ganar". Nuestro objetivo para este proyecto será:
 
 * Crear una aplicación web con preguntas creadas automáticamente, haciendo así un juego mucho más dinámico y actualizado.
-* Los usuarios podrán crear sus propia cuenta para acceder al historial de sus partidas.
+* Los usuarios podrán crear su propia cuenta para acceder al historial de sus partidas.
 
 
 === Vista de Requisitos
@@ -54,7 +54,7 @@ A continuación se muestran los requisitos de alto nivel para el desarrollo del
 
 |Condiciones de juego| Habrá un tiempo limitado de respuesta para cada pregunta
 
-|Acesso a información por parte del Sistema| El sistema tendrá acceso a la información de los usuarios, además de las preguntas generadas.
+|Acceso a información por parte del Sistema| El sistema tendrá acceso a la información de los usuarios, además de las preguntas generadas.
 |===
 
 Para información más detallada, se puede consultar el documento completo proporcionado por la empresa https://docs.google.com/document/d/1pahOfYFY--Wi7_9bbxiKOGevB_9tOSyRm78blncgBKg/edit[aquí] .
@@ -91,7 +91,7 @@ Una tabla con metas de calidad y escenarios concretos, ordenados por prioridades
 [role="arc42help"]
 ****
 .Contenido
-Vista detallada de las partes intersadas del sistema, es decir, toda persona, rol u organización que:
+Vista detallada de las partes interesadas del sistema, es decir, toda persona, rol u organización que:
 
 * Debe conocer la arquitectura
 * Debe estar convencida de la arquitectura
@@ -113,7 +113,7 @@ documentación
 [options="header",cols="1,2,2"]
 |===
 |Rol|Contacto con la aplicación|Expectativas
-| Usuarios | Interacionan directamente con la aplicación | Esperamos que el usuario considere nuestra aplicación divertida, accesible y usable. Además de que las preguntas les parezcan interesantes y no repetitivas
+| Usuarios | Interaccionan directamente con la aplicación | Esperamos que el usuario considere nuestra aplicación divertida, accesible y usable. Además de que las preguntas les parezcan interesantes y no repetitivas
 | Equipo de desarrollo | Son las personas encargadas de realizar el proyecto | Crear una aplicación sólida y mantenible en el tiempo, aprendiendo nuevas tecnologías
 | RTVE | Es la empresa contratante | Espera obtener una versión online experimental de un concurso de preguntas y respuestas similar a “Saber y Ganar”
 | HappySw | Es la empresa de desarrollo de software | Que el equipo de desarrollo realice un producto de buena calidad para que la empresa contratante este satisfecha con el producto final

docs/src/02_architecture_constraints.adoc

@@ -28,11 +28,11 @@ Si se requiere, se pueden subdividir en restricciones técnicas, organizacionale
 | Restricción | Explicación
 
 | 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, además del tiempo de acceso a esta API la cual puede relentizar el juego.
+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 ralentizar el juego.
 
 | Desplegar la aplicación en un servidor | La aplicación se debe desplegar en un servidor y que esta sea accesible desde un navegador. En este caso, para desplegar la aplicación se usa una máquina virtual creada en Azure, lo que puede suponer un problema si no se usa cuidadosamente ya que se puede agotar el crédito gratuito.
 
-| 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 y podría haber conflictos en los merge.
+| 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 aplicació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, el fallo de alguna de las pruebas bloqueará el despliegue.
 
@@ -48,7 +48,7 @@ También se debe tener en cuenta la estructura de Wikidata a la hora de acceder
 
 | 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|
+|Evaluaciones intermedias|Cada 3 semanas el proyecto será evaluado y se tomarán nota de los avances y correcciones que se deben hacer para la siguiente evaluación|
 
 |===
 

docs/src/03_system_scope_and_context.adoc

@@ -62,7 +62,7 @@ image::Business_Context.png[Contexto de negocio]
 [role="arc42help"]
 ****
 .Contenido
-Las interfases técnicas (medios de transmisión y canales) enlanzando al sistema con su ambiente. De manera adicional
+Las interfases técnicas (medios de transmisión y canales) enlazando al sistema con su ambiente. De manera adicional
 el mapeo de las entradas/salidas específicas del dominio a los canales, es decir, una explicación acerca de que entrada/salida
 utiliza cual canal.
 
@@ -71,14 +71,14 @@ Muchas partes relacionadas realizan decisiones arquitectónicas basadas en las i
 su contexto. Especialmente los diseñadores de infraestructura o hardware deciden estas interfases técnicas.
 
 .Forma
-Por ejemplo, diagramas UML de despligue describiendo los canales a sistemas vecinos, junto con una tabla de 
+Por ejemplo, diagramas UML de despliegue describiendo los canales a sistemas vecinos, junto con una tabla de 
 mapeo mostrando las relaciones entre los canales y las entradas/salidas.
 ****
 
 image::Technical_Context.svg[Contexto técnico] 
 
 |===
-| Tecnologías utilizadas | Decripción de uso 
+| Tecnologías utilizadas | Descripción de uso 
 | Azure Cloud | Utilizado para el despliegue de la aplicación
 | MongoDB | Base de datos NoSQL para guardar la información de la aplicación, como los usuarios y las preguntas base 
 | Navegadores | Permiten al usuario acceder a la aplicación una vez desplegada

docs/src/04_solution_strategy.adoc

@@ -21,11 +21,11 @@ o de arquitectura.
 Estas decisiones son las piedras angulares de la arquitectura. Son la base de muchas otras decisiones detalladas o reglas de implementación.
 
 .Forma
-Realice la explicación de las deciciones clave de manera breve. 
+Realice la explicación de las decisiones clave de manera breve. 
 
 Justifique las decisiones y porque se realizaron de esa manera, basado en el planteamiento del problema,
 las metas de calidad y restricciones clave.
-Refierase a los detalles en las secciones posteriores.
+Refiérase a los detalles en las secciones posteriores.
 ****
 
 === Decisiones Tecnológicas
@@ -34,26 +34,26 @@ Refierase a los detalles en las secciones posteriores.
 * **JavaScript**: es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se utiliza para crear páginas web dinámicas. 
 * **React**: es una biblioteca de JavaScript para construir interfaces de usuario.
 * **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.
+* **Docker**: se utiliza para hacer el despliegue de la aplicación.
 * **Bootstrap**: es un framework de código abierto para el diseño de sitios y aplicaciones web. 
 
 
 === 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. 
+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 fácilmente se puede crear interfaces. El resto de tecnologías son las más óptimas y las preestablecidas, 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.
+* **WikiData**: su uso es un requisito obligatorio de esta aplicación pero su sistema 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.
 
 
 === Decisiones sobre cómo alcanzar los objetivos clave de calidad
 * **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. 
-* **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.
+* **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.
 
 === Decisiones organizativas:

docs/src/05_building_block_view.adoc

@@ -18,7 +18,7 @@ Es la analogía al plano de una casa.
 .Motivación
 Mantener una visión general de su código fuente haciendo su estructura comprensible de manera abstracta.
 
-Esto permite comunicar a las partes interesades en un nivel abstracto sin entrar en detalles de implementación.
+Esto permite comunicar a las partes interesadas en un nivel abstracto sin entrar en detalles de implementación.
 
 .Forma
 La vista de bloques comprende una colección jerárquica de cajas negras y cajas blancas (ver figura de abajo)
@@ -30,7 +30,7 @@ image::05_building_blocks-ES.png["Jerarquía de bloques de construcción"]
 todos los bloques contenidos.
 
 *Nivel 2* hace zoom a los bloques de construcción del Nivel 1. Entonces contiene la descripción de Caja Blanca de los
-bloques de construcción selecionadas del nivel 1,junto con las descripciones de caja negra de sus bloques de construcción
+bloques de construcción seleccionadas del nivel 1,junto con las descripciones de caja negra de sus bloques de construcción
 internas.
 
 *Nivel 3* Hace zoom a los bloques selectos del nivel 2, y así sucesivamente.
@@ -53,7 +53,7 @@ interfaces
 ** Usar una lista de descripciones de caja negra de los bloques de construcción acorde a la plantilla de caja negra (ver abajo). Dependiendo de la herramienta utilizada, esta lista podría constar de sub-capítulos (en archivos de texto),
 sub-páginas (en un wiki) o elementos anidados (en una herramienta de modelado).
 * (opcional:) Interfases importantes, que no están explicadas en las plantillas de caja negra de un bloque de construcción,
-pero que son muy importantes para entender la caja blanca. En el peor de los casos se deberá especificar y desribir la
+pero que son muy importantes para entender la caja blanca. En el peor de los casos se deberá especificar y describir la
 sintaxis, semántica, protocolos, manejo de errores, restricciones, versiones, calidades, compatibilidades necesarias, entre
 otras. En el mejor de los casos bastará con ejemplos o la firma de los mismos.
 ****
@@ -62,7 +62,7 @@ otras. En el mejor de los casos bastará con ejemplos o la firma de los mismos.
 |===
 | Nombre | Descripción
 
-| Wikidata | Para formular las preguntas se extrará información de WikiData a través de su API.
+| Wikidata | Para formular las preguntas se extraerá información de WikiData a través de su API.
 
 | Base de datos | Se guarda información importante, como los datos de los usuarios y sus historiales.
 
@@ -103,7 +103,7 @@ importante. El título es el nombre de la caja negra.
 
 [role="arc42help"]
 ****
-Aqui se describe la <caja negra 1> acorde a la siguiente plantilla:
+Aquí se describe la <caja negra 1> acorde a la siguiente plantilla:
 
 * Propósito/Responsabilidad
 * Interfases, cuando no son extraídas como párrafos separados. Estas interfases pueden incluir características de calidad y rendimiento.

docs/src/07_deployment_view.adoc

@@ -20,11 +20,11 @@ Deberá documentarse la vista de despliegue de manera especial cuando el softwar
 con mas de una computadora, procesador, servidor o contenedor o cuando se diseñen los procesadores y chips de hardware propios.
 
 Desde una perspectiva de software es suficiente con capturar los elementos de la infraestructura necesarios para mostrar
-el despliegue de los bloques de construcción. Los arquitectos de hardware pueden ir más alla y describir la infraestructura
+el despliegue de los bloques de construcción. Los arquitectos de hardware pueden ir más allá y describir la infraestructura
 a cualquier nivel de detalle que requieran.
 
 .Motivación
-El software no corre sin haardware.
+El software no corre sin hardware.
 El hardware subyacente puede influenciar el sistema o algunos conceptos entrecruzados. Por ende, es necesario conocer
 la infraestructura.
 
@@ -33,7 +33,7 @@ Quizá el más alto nivel de diagrama de despliegue esté contenido en la secci
 propia infraestructura como UNA caja negra. En esta sección se deberá realizar un acercamiento a ésta caja negra 
 utilizando diagramas de despliegue adicionales:
 
-* UML provee diagramas de despliegue para expresar la vista. Uselos, probablemente con diagramas anidados.
+* UML provee diagramas de despliegue para expresar la vista. úselos, probablemente con diagramas anidados.
 * Cuando las partes relacionadas de Hardware prefieran otro tipo de diagramas además de los diagramas de despliegue,
 permítales usar cualquier tipo que permita mostrar los nodos y canales de la infraestructura.
 ****

docs/src/09_architecture_decisions.adoc

@@ -7,7 +7,7 @@ ifndef::imagesdir[:imagesdir: ../images]
 [role="arc42help"]
 ****
 .Contenido
-Decisiones arquitectónicas importantes, costosas, a larga escala o riesgosas incluyendo sus razonamientos.
+Decisiones arquitectónicas importantes, costosas, a larga escala o de riesgo incluyendo sus razonamientos.
 Con "Decisiones" nos referimos a la elección de una alternativa basada en cierto criterio.
 
 Se debe usar el juicio para decidir si una decisión arquitectónica debe ser documentada en esta sección
@@ -39,7 +39,7 @@ Varias opciones:
 
 | BackEnd | Node.js | Escogimos Node.js debido a su compatibilidad.
 
-| Arquitectura | MVC | El modelo MVC nos permite separar las capas para mantener el código ordenado, mantenible y es familiar para los intengrantes del grupo.
+| Arquitectura | MVC | El modelo MVC nos permite separar las capas para mantener el código ordenado, mantenible y es familiar para los integrantes del grupo.
 
 | Arquitectura | Microservicios | El modelo de microservicios se ajusta muy bien a las necesidades de la aplicación.
 

docs/src/10_quality_requirements.adoc

@@ -24,7 +24,7 @@ en cuenta los elementos importantes para las partes relacionadas que sean concre
 [role="arc42help"]
 ****
 .Contenido
-El árbol de calidad (Definido en ATAM - Método de análisis de compensación de arquitectura por sus silas en inglés) con 
+El árbol de calidad (Definido en ATAM - Método de análisis de compensación de arquitectura por sus siglas en inglés) con 
 escenarios de calidad/evaluación como hojas. 
 
 .Motivación
@@ -46,7 +46,7 @@ image::10_QualityTree.png[Quality Tree]
 [role="arc42help"]
 ****
 .Contenido
-Concretización de requerimientos de calidad (que pueden ser vagos o implícitos) utilizando escenarios de calidad.
+Concretar requisitos de calidad (que pueden ser vagos o implícitos) utilizando escenarios de calidad.
 
 Estos escenarios describen lo que debería pasar cuando un estímulo llega al sistema.
 
@@ -56,7 +56,7 @@ Para los arquitectos, son importantes dos tipos de escenarios:
 en tiempo de ejecución de un sistema a un determinado estímulo. Esto incluye también escenarios que describen la eficiencia
 o el rendimiento del sistema. Por ejemplo: El sistema reacciona a la petición de un usuario en un segundo.
 * Escenarios de cambios, describen la modificación del sistema a su ambiente inmediato. Por ejemplo: Cuando se implementa
-funcionalidad adicional o requerimietnos para el cambio de un atributo de calidad.
+funcionalidad adicional o requerimientos para el cambio de un atributo de calidad.
 
 .Motivación
 Los escenarios crean requerimientos de calidad concretos y permiten medirlos de manera mas sencilla o decidir si han sido