diff --git a/docs/package-lock.json b/docs/package-lock.json index 78b5494..ae39a37 100644 --- a/docs/package-lock.json +++ b/docs/package-lock.json @@ -5,7 +5,6 @@ "requires": true, "packages": { "": { - "name": "docs", "version": "1.0.0", "dependencies": { "gh-pages": "^3.2.3", diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index 350d8c3..19c7ff1 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/docs/src/01_introduction_and_goals.adoc @@ -3,22 +3,20 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-introduction-and-goals]] == Introducción y Objetivos 🎇 -El proyecto de WIQ 04D es un proyecto desarrollado en la asignatura Arquitectura del Software. Consiste en la creación de una aplicación web al estilo "Saber y Ganar". Es decir, es un juego de preguntas de cultura general generadas de forma automática con ayuda de Wikidata, una base de conocimiento que puede ser leída y editada por humanos y por máquinas. +El proyecto WIQ 04D es un desarrollo en el marco de la asignatura de Arquitectura del Software, que consiste en la creación de una aplicación web similar al estilo de "Saber y Ganar". Este es un juego de preguntas de cultura general que se generan automáticamente con la ayuda de Wikidata, una base de conocimientos accesible tanto para humanos como para máquinas. Los desarrolladores de la aplicación son Zohaib Akhtar Kausar, Yago Navajas González y Santiago López Laso. === Requisitos Funcionales **** -* Los usuarios deberán iniciar sesión en la página; esto servirá para tener registro de una serie de parámetros, como puede ser las veces que se ha jugado. -* Se podrán responder preguntas autogeneradas y se mostrará si han acertado o fallado, así como la respuesta correcta. +* Los usuarios deben iniciar sesión en la página, lo cual permitirá registrar parámetros como la cantidad de veces que han jugado. +* Se podrán responder preguntas autogeneradas y se indicará si las respuestas son correctas o incorrectas, junto con la respuesta correcta. * Las preguntas deberán ser respondidas dentro de un tiempo límite. -* Las preguntas seguirán la misma estructura: 1 pregunta correcta y 3 incorrectas, generadas automáticamente. -* Los usuarios podrán consultar datos sobre sus cuentas, como las veces que han jugado o el número de preguntas que han acertado o fallado. -* Existirá un ranking que ordenará a los 10 mejores jugadores según una métrica determinada. -* Se podrá acceder a los servicios de la aplicación a través de una API REST - - +* Las preguntas seguirán la estructura de una pregunta correcta y tres incorrectas, generadas automáticamente. +* Los usuarios podrán consultar datos sobre sus cuentas, como la cantidad de veces que han jugado y el número de preguntas acertadas o falladas. +* Habrá un ranking que clasificará a los 10 mejores jugadores según una métrica determinada. +* Se podrá acceder a los servicios de la aplicación a través de una API REST. **** === Atributos de Calidad @@ -26,25 +24,24 @@ Los desarrolladores de la aplicación son Zohaib Akhtar Kausar, Yago Navajas Gon [options="header",cols="1,2,2"] |=== | Prioridad | Objetivo | Descripción -| 1 | Usabilidad | Todos los usuarios deben poder usar la aplicación sin tener en cuenta sus limitaciones. -| 2 | Rendimiento | Los tiempos entre operaciones han de ser asumibles, aun teniendo varios usuarios usando la aplicación a la vez. -| 3 | Seguridad | Los datos sensibles de los usuarios deben estar restringidos al mismo usuario. -| 4 | Mantenibilidad | El código y documentación de la aplicación ha de estar conformado de tal forma que sea factible hacer cambios y ampliaciones en la aplicación. -| 5 | Portabilidad | La aplicación web es compatible con los navegadores web más utilizados (Chrome, Firefox, Safari, Edge). +| 1 | Usabilidad | La aplicación debe ser accesible y fácil de usar para todos los usuarios, independientemente de sus limitaciones. +| 2 | Rendimiento | Los tiempos de respuesta deben ser adecuados, incluso con múltiples usuarios accediendo a la aplicación simultáneamente. +| 3 | Seguridad | Los datos sensibles de los usuarios deben estar protegidos y accesibles únicamente para cada usuario. +| 4 | Mantenibilidad | El código y la documentación de la aplicación deben estar organizados de manera que faciliten futuras modificaciones y ampliaciones. +| 5 | Portabilidad | La aplicación web debe ser compatible con los navegadores más utilizados como Chrome, Firefox, Safari y Edge. |=== - === Stakeholders [options="header",cols="1,2,2"] |=== -|Role/Name|Contact|Expectations +| Rol/Nombre | Contacto | Expectativas | Equipo de Desarrollo | Yago Navajas González + Zohaib Akhtar Kausar + -Santiago López Laso | Los estudiantes que llevarán a cabo el desarrollo de la aplicación. Serán los encargados de la arquitectura, la documentación y la codificación. -| Profesores | Jose Emilio Labra Gayo | Supervisores de los avances y encargados de evaluar la aplicación final y el desarrollo de la misma. -| Usuario | Jugador de la aplicación | Personas que puedan interactuar tanto con el registro de usuarios como con el juego en sí y completar correctamente una partida. -| HappySw | Empresa responsable | Empresa contratada, cuyo trabajo será el desarrollo del juego de la mano del equipo de desarrollo. -| Wikidata | Proveedor de la información de las preguntas | Si la aplicación tiene éxito, para Wikidata es publicidad gratis. Por tanto, le interesa este proyecto. +Santiago López Laso | Estudiantes encargados del desarrollo de la aplicación, incluyendo la arquitectura, la documentación y la codificación. +| Profesores | Jose Emilio Labra Gayo | Supervisores de los avances y encargados de evaluar la aplicación final y su desarrollo. +| Usuarios | Jugadores de la aplicación | Personas que interactuarán con el registro de usuarios y el juego, y deberán ser capaces de completar una partida correctamente. +| HappySw | Empresa responsable | Empresa contratada para colaborar en el desarrollo del juego junto al equipo de desarrollo. +| Wikidata | Proveedor de la información para las preguntas | Interesado en el éxito de la aplicación como forma de obtener publicidad gratuita. | RTVE | Empleador | Interesados en la creación del juego e impulsores de su desarrollo. |=== diff --git a/docs/src/02_architecture_constraints.adoc b/docs/src/02_architecture_constraints.adoc index 112b37a..9e4f0d4 100644 --- a/docs/src/02_architecture_constraints.adoc +++ b/docs/src/02_architecture_constraints.adoc @@ -4,9 +4,9 @@ ifndef::imagesdir[:imagesdir: ../images] == Restricciones de arquitectura ⛔ [options="header",cols="1,2"] |=== -|Restricción|Descripción -|Wikidata|Se debe usar Wikidata para obtener la información de las preguntas. El número de consultas en un tiempo específico es la mayor limitación de la API, junto con la disponibilidad de los datos. Esto puede afectar a tiempos de carga, por ejemplo. -|Git|Conflictos al realizar trabajo por separado por parte de más de un miembro sobre un mismo recurso. -|GitHub|La falta de experiencia puede conducir a problemas en la gestión del proyecto así como en su despliegue y lo que ello conlleva. -|Integración continua/despliegue continuo (CI/CD)|Restricciones en la configuración de pipelines de CI/CD para automatizar las pruebas, compilaciones y despliegues de la aplicación en el servidor Docker, lo que podría afectar la velocidad y la frecuencia de las entregas de nuevas características o correcciones de errores. -|=== \ No newline at end of file +| Restricción | Descripción +| Wikidata | El uso de Wikidata para obtener información para las preguntas es obligatorio. Las principales limitaciones de esta API incluyen el número máximo de consultas por unidad de tiempo y la disponibilidad de datos, lo que puede repercutir en los tiempos de carga. +| Git | Posibilidad de conflictos cuando varios miembros del equipo trabajan simultáneamente en el mismo recurso, requiriendo una gestión cuidadosa de las ramificaciones y fusiones. +| GitHub | La falta de experiencia con GitHub puede conducir a problemas en la gestión del proyecto y en el despliegue del mismo, impactando la eficacia del trabajo en equipo y la entrega de resultados. +| Integración continua/despliegue continuo (CI/CD) | Restricciones en la configuración de pipelines de CI/CD pueden limitar la capacidad para automatizar pruebas, compilaciones y despliegues en un servidor Docker, afectando la velocidad y frecuencia de actualizaciones y correcciones. +|=== diff --git a/docs/src/04_solution_strategy.adoc b/docs/src/04_solution_strategy.adoc index 5c65a4b..c57f48a 100644 --- a/docs/src/04_solution_strategy.adoc +++ b/docs/src/04_solution_strategy.adoc @@ -5,18 +5,17 @@ ifndef::imagesdir[:imagesdir: ../images] === Decisiones tecnológicas -* Se usará la biblioteca de JavaScript React para facilitar la implementación de la interfaz. -* Se usará una arquitectura basada en microservicios para los diferentes componentes del proyecto como la generación de preguntas o el registro de usuarios en el sistema. -* Para el alojamiento de la página web se usará una máquina virtual Azure con el crédito de estudiante proporcionado. -* Se usará GitHub Actions para el despliegue del proyecto, pero de forma automática en vez de desplegarlo todo a mano. Cabe destacar que también están implementados unos tests para asegurar el correcto despliegue del proyecto. -* Se harán pruebas de usabilidad para comprobar la usabilidad de la aplicación. -* Se harán pruebas de carga para comprobar el rendimiento de la aplicación. +* Se utilizará la biblioteca de JavaScript, React, para facilitar la implementación de la interfaz de usuario. +* Se adoptará una arquitectura basada en microservicios para los diferentes componentes del proyecto, como la generación de preguntas y el registro de usuarios. +* Para el alojamiento de la página web, se utilizará una máquina virtual de Azure aprovechando el crédito para estudiantes proporcionado. +* Se empleará GitHub Actions para el despliegue automático del proyecto, complementado con tests para asegurar su correcta ejecución. +* Se realizarán pruebas de usabilidad para verificar la facilidad de uso de la aplicación. +* Se efectuarán pruebas de carga para evaluar el rendimiento de la aplicación. === Decisiones organizativas -* Este grupo (wiq_es04d) ha sido formado a partir de un grupo ya existente (wiq_es04c) pasando de 5 integrantes a 3. Se ha decidido volver al proyecto inicial cuando se dio la situación de ruptura del grupo para empezar de 0. +* Este grupo (wiq_es04d) se formó a partir de un grupo preexistente (wiq_es04c), reduciendo su tamaño de cinco a tres integrantes. Se decidió retomar el proyecto inicial tras la disolución del grupo anterior, empezando de cero. -* No existe una división clara entre las funcionalidades que desempeña cada usuario, todos hacen de todo. - -* Se realizará al menos una reunión a la semana en clase para organizar y llevar recuento del trabajo realizado y que será lo siguiente en lo que se va a trabajar. Se pueden realizar reuniones adicionales fuera de clase. +* No se ha establecido una división clara de roles específicos; todos los integrantes participan en todas las áreas. +* Se llevará a cabo al menos una reunión semanal en clase para organizar y revisar el progreso del trabajo, así como planificar las siguientes tareas. Se podrán realizar reuniones adicionales fuera del horario de clase. diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc index 8269c4d..d22139a 100644 --- a/docs/src/06_runtime_view.adoc +++ b/docs/src/06_runtime_view.adoc @@ -3,19 +3,15 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-runtime-view]] == Vista de Ejecución 📽️ - === Escenario de Ejecución 1 -Jugar una partida cuando la base de datos tiene suficientes preguntas. El proceso de mostrar una pregunta y procesar la respuesta se repite para cada pregunta de la partida. En este escenario se asume que son 3 preguntas por partida. -La pregunta "n" es la última pregunta. +Este escenario describe el proceso de jugar una partida cuando la base de datos cuenta con suficientes preguntas disponibles. El proceso implica mostrar una pregunta y procesar la respuesta del usuario. Esto se repite para cada una de las 3 preguntas en la partida. La pregunta "n" representa la última pregunta de la serie. [plantuml,"Sequence diagram",png] - -image::Diagrama de secuencia plantuml 1.png["Diagrama de secuencia 1"] - +image::Diagrama de secuencia plantuml 1.png["Diagrama de secuencia 1", width="600", height="400"] === Escenario de Ejecución 2 -Jugar una partida cuando la base de datos no tiene suficientes preguntas. -Antes de "acceder al juego", la ejecución es la misma que el escenario de ejecución 1. -A partir de "mostrar primera pregunta", la ejecución es la misma que el escenario de ejecución 1. +Este escenario aborda una partida cuando la base de datos no tiene suficientes preguntas. +Hasta el momento de "acceder al juego", la ejecución sigue el mismo flujo que el escenario de ejecución 1. +Desde "mostrar primera pregunta", la ejecución continúa conforme al escenario de ejecución 1. -image::Diagrama de secuencia plantuml 2.png["Diagrama de secuencia 2"] +image::Diagrama de secuencia plantuml 2.png["Diagrama de secuencia 2", width="600", height="400"] diff --git a/docs/src/08_concepts.adoc b/docs/src/08_concepts.adoc index fd67155..f5b351b 100644 --- a/docs/src/08_concepts.adoc +++ b/docs/src/08_concepts.adoc @@ -5,40 +5,37 @@ ifndef::imagesdir[:imagesdir: ../images] === Experiencia de Usuario -La Experiencia de Usuario en nuestra aplicación es la impresión general que los usuarios tienen al interactuar con ella. Se refiere a cómo se sienten y qué piensan cuando utilizan nuestra aplicación web. Esto incluye aspectos como la facilidad para registrarse o iniciar sesión, o lo intuitivo que es el juego de preguntas. +La Experiencia de Usuario en nuestra aplicación refleja la impresión general que los usuarios tienen al interactuar con ella. Se refiere a cómo se sienten y qué piensan al utilizar nuestra aplicación web, incluyendo aspectos como la facilidad para registrarse, iniciar sesión y lo intuitivo del juego de preguntas. -Para nuestra aplicación, la Experiencia de Usuario significa comprender profundamente las necesidades y expectativas de nuestros usuarios. Siguiendo la regla de "Keep It Simple Stupid" (KISS), hemos diseñado cada aspecto de la interfaz para que sea lo más sencillo y directo posible, facilitando una experiencia efectiva y agradable. Esto implica asegurar que la navegación sea intuitiva, que la información esté presentada de manera clara y accesible, que las acciones sean fáciles de realizar y que el sistema responda de manera rápida y confiable a las interacciones del usuario. +Para nuestra aplicación, la Experiencia de Usuario implica comprender profundamente las necesidades y expectativas de nuestros usuarios. Siguiendo la regla de "Keep It Simple Stupid" (KISS), hemos diseñado cada aspecto de la interfaz para que sea lo más sencillo y directo posible, facilitando una experiencia efectiva y agradable. Esto implica asegurar que la navegación sea intuitiva, que la información esté clara y accesible, que las acciones sean fáciles de realizar y que el sistema responda de manera rápida y confiable a las interacciones del usuario. -Nos esforzamos por crear una experiencia de usuario cómoda y accesible, donde cada detalle esté cuidadosamente diseñado para brindar una experiencia fluida y satisfactoria. Nuestro objetivo es ofrecer un juego entretenido y funcional, manteniendo siempre la simplicidad en cada elemento. +Nos esforzamos por crear una experiencia de usuario cómoda y accesible, donde cada detalle está cuidadosamente diseñado para brindar una experiencia fluida y satisfactoria. Nuestro objetivo es ofrecer un juego entretenido y funcional, manteniendo la simplicidad en cada elemento. === Arquitectura -Utilizaremos una arquitectura basada en microservicios para mantener la independencia entre las distintas partes de la aplicación. Esta estructura ofrece una arquitectura flexible y modular, con beneficios significativos en términos de escalabilidad, flexibilidad tecnológica, agilidad en el desarrollo, resistencia a fallos y mantenimiento del software. - +Utilizaremos una arquitectura basada en microservicios para mantener la independencia entre las distintas partes de la aplicación. Esta estructura ofrece una arquitectura flexible y modular, con beneficios significativos en términos de escalabilidad, flexibilidad tecnológica, agilidad en el desarrollo, resistencia a fallos y facilidad de mantenimiento. === Desarrollo -En el desarrollo de nuestra aplicación, nos centramos en varios aspectos para garantizar su eficacia: - -* Mantenibilidad del código: Escribimos nuestro código de manera clara y organizada, siguiendo las mejores prácticas de desarrollo, para facilitar su mantenimiento y futuras actualizaciones. +En el desarrollo de nuestra aplicación, nos centramos en varios aspectos clave para garantizar su eficacia: -* Automatización de pruebas: Implementamos pruebas automatizadas para garantizar que nuestra aplicación funcione correctamente en diferentes situaciones y escenarios. Esto nos ayuda a identificar y corregir errores de manera oportuna, manteniendo la calidad del software. +* **Mantenibilidad del código:** Escribimos nuestro código de manera clara y organizada, siguiendo las mejores prácticas de desarrollo para facilitar su mantenimiento y futuras actualizaciones. -* Integración continua: La implementación exitosa de CI/CD proporciona un camino continuo hacia la entrega de software de alta calidad, permitiendo la automatización de pruebas, integración y despliegue, agilizando así el ciclo de vida del desarrollo y garantizando una entrega rápida y confiable de valor al cliente. +* **Automatización de pruebas:** Implementamos pruebas automatizadas para asegurar que nuestra aplicación funcione correctamente bajo diferentes situaciones y escenarios. Esto nos ayuda a identificar y corregir errores de manera oportuna, manteniendo la calidad del software. -* Optimización de rendimiento: Nos esforzamos por mejorar el rendimiento de nuestra aplicación, optimizando el tiempo de carga, la velocidad de respuesta y el consumo de recursos. +* **Integración continua:** La implementación exitosa de CI/CD proporciona un camino continuo hacia la entrega de software de alta calidad, permitiendo la automatización de pruebas, integración y despliegue, agilizando así el ciclo de vida del desarrollo y garantizando una entrega rápida y confiable de valor al cliente. -En resumen, en el desarrollo de nuestra aplicación nos esforzamos por mantener un código mantenible, implementar pruebas automatizadas, lograr una integración continua eficiente y optimizar el rendimiento. Esto nos permite ofrecer una aplicación confiable y de alta calidad a nuestros usuarios. +* **Optimización de rendimiento:** Nos esforzamos por mejorar el rendimiento de nuestra aplicación, optimizando el tiempo de carga, la velocidad de respuesta y el consumo de recursos. === Gestión del proyecto En la gestión de nuestro proyecto, nos enfocamos en garantizar un entorno de producción estable y eficiente: -* Gestión de infraestructura: Utilizamos una máquina virtual de Azure para administrar la infraestructura de nuestra aplicación, garantizando así su disponibilidad y un rendimiento óptimo. +* **Gestión de infraestructura:** Utilizamos una máquina virtual de Azure para administrar la infraestructura de nuestra aplicación, garantizando su disponibilidad y rendimiento óptimo. -* Gestión de versiones: Gestionamos las versiones utilizando etiquetas (tags) en nuestro proyecto de GitHub, que luego se despliegan en la máquina virtual, asegurando actualizaciones controladas y sin interrupciones en el servicio. +* **Gestión de versiones:** Gestionamos las versiones utilizando etiquetas (tags) en nuestro proyecto de GitHub, que luego se despliegan en la máquina virtual, asegurando actualizaciones controladas y sin interrupciones en el servicio. -* Desarrollo del equipo: Nuestro equipo ha progresado en el proyecto mediante el autoaprendizaje de las tecnologías utilizadas. Esto garantiza una comprensión profunda de la aplicación y contribuye a mantener un entorno operativo eficiente. +* **Desarrollo del equipo:** Nuestro equipo ha progresado en el proyecto mediante el autoaprendizaje de las tecnologías utilizadas, garantizando una comprensión profunda de la aplicación y manteniendo un entorno operativo eficiente. === Seguridad @@ -46,4 +43,4 @@ Nos comprometemos a proteger la información personal y sensible de nuestros usu Para ello, implementamos medidas de seguridad como la encriptación de datos y la autenticación de usuarios mediante contraseñas. -Queremos que nuestros usuarios se sientan seguros y protegidos mientras utilizan nuestra aplicación. \ No newline at end of file +Queremos que nuestros usuarios se sientan seguros y protegidos mientras utilizan nuestra aplicación. diff --git a/docs/src/11_technical_risks.adoc b/docs/src/11_technical_risks.adoc index 878a565..1ce71ed 100644 --- a/docs/src/11_technical_risks.adoc +++ b/docs/src/11_technical_risks.adoc @@ -1,29 +1,28 @@ - [[section-technical-risks]] == Riesgos y Deuda Técnica ⚠️ === Riesgos [options="header",cols="1,2"] -|====================== +|=== | Riesgo | Descripción -| Tiempo de entrega | Estamos limitados por el plazo de entrega y también por el tiempo que dedicaremos a trabajar en otras asignaturas. -| Proyecto grande y trabajo en equipo | La coordinación y comunicación en un equipo pueden ser desafiantes. -| Diseño inadecuado o enfoque incorrecto | La presencia de errores en etapas tempranas puede ser devastadora, ya que estas son cruciales. Un mal diseño detectado en etapas avanzadas podría ser irreparable, subrayando la importancia de una planificación y visión previsoras. -| Falta de familiaridad con las tecnologías | El equipo comienza con conocimiento limitado sobre las herramientas necesarias, lo que puede resultar en un uso subóptimo de estas. -| Errores de implementación | Errores no críticos en la lógica de negocio pueden permanecer ocultos por largo tiempo, afectando la calidad del sistema. +| Tiempo de entrega | Estamos limitados por el plazo de entrega del proyecto y el tiempo que podemos dedicar mientras trabajamos en otras asignaturas. +| Proyecto grande y trabajo en equipo | La coordinación y comunicación dentro de un equipo grande pueden ser desafiantes. +| Diseño inadecuado o enfoque incorrecto | Los errores en las etapas tempranas pueden tener consecuencias devastadoras, y un mal diseño descubierto tarde podría ser difícil de corregir. Esto subraya la importancia de una planificación cuidadosa y una visión previsora. +| Falta de familiaridad con las tecnologías | El equipo comienza con un conocimiento limitado sobre las herramientas necesarias, lo que puede resultar en un uso subóptimo de estas. +| Errores de implementación | Los errores no críticos en la lógica de negocio pueden permanecer ocultos durante mucho tiempo, afectando la calidad del sistema. | Comunicación deficiente entre miembros | Las diferencias y desacuerdos pueden obstaculizar la colaboración efectiva, esencial para el éxito del equipo. -| Distribución desigual del trabajo | Una asignación desequilibrada puede sobrecargar a algunos miembros mientras deja a otros con menos responsabilidades. -| Reducción del tamaño del equipo | La salida inesperada de miembros puede desafiar la continuidad y el avance del proyecto, requiriendo adaptaciones rápidas y eficientes. -| Incumplimiento de normas | Si el proyecto no cumple con las regulaciones o estándares de seguridad pertinentes, podría enfrentar sanciones legales o multas. -|====================== +| Distribución desigual del trabajo | Una asignación desequilibrada del trabajo puede sobrecargar a algunos miembros mientras deja a otros con menos responsabilidades. +| Reducción del tamaño del equipo | La salida inesperada de miembros del equipo puede desafiar la continuidad y el avance del proyecto, requiriendo adaptaciones rápidas y eficientes. +| Incumplimiento de normas | La falta de cumplimiento con regulaciones o estándares de seguridad pertinentes podría resultar en sanciones legales o multas. +|=== === Deuda Técnica [options="header",cols="1,2"] -|====================== +|=== | Deuda Técnica | Descripción -| Uso del proyecto base creado por los profesores | Para evitar la creación del proyecto desde cero, hemos decidido utilizar el proyecto ya creado por los profesores. Esto implica revisar y comprender el código existente, así como ampliarlo con nuestro propio código, lo que puede llevar a errores y pérdida de tiempo. Además, requiere aprender nuevas tecnologías y cómo utilizarlas. -| Uso de React | El uso de este framework puede facilitar el desarrollo en algunas etapas, pero también puede complicarlo al no estar familiarizados con esta tecnología y todas sus características. -| Dependencias desactualizadas | Utilizar versiones obsoletas de bibliotecas, frameworks o plataformas puede resultar en vulnerabilidades de seguridad o limitaciones de rendimiento que deben abordarse en el futuro. -| Falta de una abundancia de pruebas automatizadas | A medida que avanza el proyecto, la falta de pruebas puede acumular deuda técnica al no poder realizarse cambios de manera rápida y eficaz sin la capacidad de probarlos de inmediato. -| Empezar desde el principio de nuevo | Debido a problemas, el grupo ha tenido que reiniciar el proyecto desde cero, lo que ha provocado un retraso significativo con todas las implicaciones que esto conlleva. -|====================== \ No newline at end of file +| Uso del proyecto base creado por los profesores | Hemos optado por utilizar el proyecto base creado por los profesores para evitar empezar desde cero. Esto requiere revisar y comprender el código existente y expandirlo con nuestro propio código, lo cual puede introducir errores y llevar tiempo. Además, implica aprender nuevas tecnologías y su aplicación. +| Uso de React | Aunque React puede facilitar el desarrollo en ciertas etapas, nuestra falta de familiaridad con este framework y sus características puede complicar el proceso. +| Dependencias desactualizadas | El uso de versiones antiguas de bibliotecas, frameworks o plataformas puede resultar en vulnerabilidades de seguridad y limitaciones de rendimiento que necesitarán ser abordadas en el futuro. +| Falta de pruebas automatizadas | La escasez de pruebas automatizadas a medida que el proyecto avanza puede acumular deuda técnica, ya que impide realizar cambios rápidos y efectivos sin la capacidad de probarlos de inmediato. +| Empezar desde cero | Debido a problemas previos, el equipo ha tenido que reiniciar el proyecto desde cero, lo cual ha provocado un retraso significativo y las implicaciones correspondientes. +|=== diff --git a/docs/src/12_glossary.adoc b/docs/src/12_glossary.adoc index ae6c277..8367d1a 100644 --- a/docs/src/12_glossary.adoc +++ b/docs/src/12_glossary.adoc @@ -7,28 +7,28 @@ ifndef::imagesdir[:imagesdir: ../images] |=== |Término | Definición -|React | Biblioteca de JavaScript que facilita la creación de interfaces de usuario de manera sencilla y eficiente. Se integra fácilmente en el código. +|React | Biblioteca de JavaScript diseñada para crear interfaces de usuario de forma eficiente y sencilla. Se integra fácilmente en proyectos existentes. -|Node.js | Entorno de ejecución de JavaScript, destacado en la creación de servidores web. Su programación es dirigida por eventos, es multiplataforma, de código abierto y compatible con la concurrencia. +|Node.js | Entorno de ejecución para JavaScript orientado al desarrollo de servidores web. Es dirigido por eventos, multiplataforma, de código abierto y maneja la concurrencia de manera eficaz. -|Microservicio | Enfoque arquitectónico donde el software se divide en servicios pequeños, conectados mediante APIs (En nuestro caso usamos un gateway). Son rápidos, simples de desarrollar y autónomos en ejecución. +|Microservicio | Enfoque arquitectónico que divide un software en pequeños servicios independientes que se comunican a través de APIs. Son rápidos, simples de desarrollar y pueden ejecutarse de manera autónoma. -|API | Interfaz de programación de aplicaciones, que facilita la comunicación entre diferentes servicios del proyecto, mejorando su eficiencia y agilidad. +|API | Acrónimo de Interfaz de Programación de Aplicaciones. Facilita la comunicación entre diferentes partes de un software, permitiendo que los servicios interactúen de manera eficiente. -|MongoDB | Tipo de base de datos NoSQL, compatible con múltiples lenguajes de programación y sistemas operativos. Almacena datos en archivos BSON, un formato derivado de JSON. +|MongoDB | Base de datos NoSQL que es compatible con múltiples lenguajes de programación y sistemas operativos. Almacena datos en documentos BSON, un formato binario que extiende JSON. -|BSON | Formato de archivo usado por MongoDB para almacenar datos de manera eficiente. No tiene un tipo MIME definido como JSON. +|BSON | Formato binario utilizado por MongoDB para almacenar documentos de manera eficiente. A diferencia de JSON, BSON está optimizado para ser más rápido en la lectura y escritura. -|Mongoose | Biblioteca que facilita la conexión entre Node.js y MongoDB, simplificando el acceso y la manipulación de datos en la base de datos. +|Mongoose | Biblioteca que proporciona una solución sencilla para modelar datos en aplicaciones Node.js que utilizan MongoDB. Simplifica la manipulación y el acceso a los datos. -|Docker | Plataforma que despliega aplicaciones en contenedores, similares a los contenedores de carga de los barcos. Es de código abierto y facilita el despliegue ordenado de aplicaciones. +|Docker | Plataforma que permite empaquetar aplicaciones dentro de contenedores, asegurando que funcionen de manera uniforme en cualquier entorno. Es de código abierto y facilita el despliegue escalable de aplicaciones. -|GitHub Actions | Plataforma que automatiza proyectos, permitiendo el despliegue desde GitHub. Es compatible con diversos lenguajes y sistemas operativos. +|GitHub Actions | Herramienta de automatización que permite la ejecución de flujos de trabajo directamente desde un repositorio en GitHub. Soporta múltiples lenguajes y sistemas operativos, y es especialmente útil para la integración y despliegue continuo. -|Integración continua/despliegue continuo (CI/CD) | CI/CD es una práctica de desarrollo de software que combina la integración continua (CI) y la implementación continua (CD). La CI implica la integración automática y frecuente de cambios de código en un repositorio compartido, mientras que la CD automatiza el proceso de implementación de esos cambios en entornos de producción. +|Integración continua/despliegue continuo (CI/CD) | Metodología de desarrollo de software que integra la integración continua (CI), la cual implica integrar automáticamente y con frecuencia los cambios de código en un repositorio compartido, y el despliegue continuo (CD), que automatiza la implementación de esos cambios en entornos de producción. -|Interfaz de Usuario (UI) | La Interfaz de Usuario (UI) se refiere a la parte visual y tangible de un sistema informático a través de la cual los usuarios interactúan con él. Esto incluye elementos como botones, menús, formularios y cualquier otro componente con el que los usuarios puedan interactuar para utilizar el sistema. +|Interfaz de Usuario (UI) | Aspecto visual y funcional de un sistema informático a través del cual los usuarios interactúan. Incluye elementos como botones, menús y formularios, facilitando la interacción con el sistema. -|Express (en el contexto de Node.js) | Express es un framework de desarrollo web para Node.js, que proporciona una serie de características y herramientas para crear aplicaciones web y APIs de manera más fácil y rápida. +|Express (en el contexto de Node.js) | Framework de desarrollo web para Node.js, que ofrece herramientas y características que simplifican la creación de aplicaciones web y APIs de manera eficiente. |===