diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 0000000..ae1c8ac --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,3 @@ +{ + "asciidoc.antora.enableAntoraSupport": true +} \ No newline at end of file diff --git a/docs/images/08_diagrama_modelo_dominio.png b/docs/images/08_diagrama_modelo_dominio.png new file mode 100644 index 0000000..54fe0a4 Binary files /dev/null and b/docs/images/08_diagrama_modelo_dominio.png differ diff --git a/docs/images/10_Arbol_de_calidad.jpg b/docs/images/10_Arbol_de_calidad.jpg new file mode 100644 index 0000000..bc70eea Binary files /dev/null and b/docs/images/10_Arbol_de_calidad.jpg differ diff --git a/docs/images/Diagrama de casos de uso para el juego de palabras.jpg b/docs/images/Diagrama de casos de uso para el juego de palabras.jpg new file mode 100644 index 0000000..d002bc2 Binary files /dev/null and b/docs/images/Diagrama de casos de uso para el juego de palabras.jpg differ diff --git a/docs/images/Digrama de secuencia Juego de preguntas.jpg b/docs/images/Digrama de secuencia Juego de preguntas.jpg new file mode 100644 index 0000000..c48c265 Binary files /dev/null and b/docs/images/Digrama de secuencia Juego de preguntas.jpg differ diff --git a/docs/images/diagrama_contexto_tecnico.drawio.png b/docs/images/diagrama_contexto_tecnico.drawio.png new file mode 100644 index 0000000..e5f0cf8 Binary files /dev/null and b/docs/images/diagrama_contexto_tecnico.drawio.png differ diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index aa23a98..7e10b9f 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/docs/src/01_introduction_and_goals.adoc @@ -1,96 +1,49 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-introduction-and-goals]] -== Introduction and Goals (wiq_es04c) +== Introducción y Ojetivos (wiq_es04c) -Trabajo realizado por David Alvarez, Zohaib Akhtar Kausar, Sara Lamuño Garcia, Yago Navajas Gonzalez y Santiago Lopez Laso. +nombre_del_proyecto es un proyecto desarrollado en la asignatura Arquitectura del Software. Consiste en la creacion de una aplicacion web al estilo "Saber y Ganar". Es decir, es un juego de preguntas de cultura general. +Los desarrolladores de la aplicacion son por David Álvarez Díaz, Zohaib Akhtar Kausar, Sara Lamuño García, Yago Navajas González y Santiago López Laso. -[role="arc42help"] -**** -Describes the relevant requirements and the driving forces that software architects and development team must consider. -These include +La aplicacion tendra su base para las preguntas y las respuestas en Wikidata , la base de conocimiento editada en colaboracion. -* underlying business goals, -* essential features, -* essential functional requirements, -* quality goals for the architecture and -* relevant stakeholders and their expectations -**** -=== Requirements Overview +=== Requisitos Funcionales -[role="arc42help"] **** -.Contents -Short description of the functional requirements, driving forces, extract (or abstract) -of requirements. Link to (hopefully existing) requirements documents -(with version number and information where to find it). - -.Motivation -From the point of view of the end users a system is created or modified to -improve support of a business activity and/or improve the quality. - -.Form -Short textual description, probably in tabular use-case format. -If requirements documents exist this overview should refer to these documents. - -Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents. - +* Los usuarios se deberan loggear en la pagina, esto servira para tener registro de unas serie de parametros, como puede ser las veces que se ha jugado. +* Se podran responder preguntas autogeneradas y ver si han acertado fallado asi como la respuesta correcta. +* Las preguntas deberan ser respondidas en un tiempo limite. +* Las preguntas seran seguiran la misma estructura: 1 pregunta correcta y 3 incorrectas, generadas automaticamente. +* Los usuarios prodran consultar datos sobre su cuentan, como pueden ser las veces que han jugado o el numero de preguntas que han acertadoo fallado. -.Further Information - -See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation. **** -=== Quality Goals - -[role="arc42help"] -**** -.Contents -The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. -We really mean quality goals for the architecture. Don't confuse them with project goals. -They are not necessarily identical. - -Consider this overview of potential topics (based upon the ISO 25010 standard): - -image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"] +=== Atributos de Calidad -.Motivation -You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. -Make sure to be very concrete about these qualities, avoid buzzwords. -If you as an architect do not know how the quality of your work will be judged... +[options="header",cols="1,2,2"] +|=== +|Prioridad | Objetivo | Descripcion +| 1 | Usabilidad | Todos los usuarios deben poder usar la aplicacion sin tener en cuenta sus limitaciones. +| 2 | Privacidad | Los datos sensibles de los usuarios deben estar restingidos al mismo usuario. +| 3 |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. +| 4 | Eficiciencia | Los tiempos entre operaciones han de ser asumibles. +| 5 | Fiabilidad | Los datos usados en la aplicación deben ser los correctos. +|=== -.Form -A table with quality goals and concrete scenarios, ordered by priorities -**** === Stakeholders -[role="arc42help"] -**** -.Contents -Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that - -* should know the architecture -* have to be convinced of the architecture -* have to work with the architecture or with code -* need the documentation of the architecture for their work -* have to come up with decisions about the system or its development - -.Motivation -You should know all parties involved in development of the system or affected by the system. -Otherwise, you may get nasty surprises later in the development process. -These stakeholders determine the extent and the level of detail of your work and its results. - -.Form -Table with role names, person names, and their expectations with respect to the architecture and its documentation. -**** - [options="header",cols="1,2,2"] |=== |Role/Name|Contact|Expectations -| __ | __ | __ -| __ | __ | __ +| Equipo de Desarrollo | Yago Navajas Gonzalez -> UO287746@uniovi.es + +David Álvarez Díaz -> UO283196@uniovi.es + +Zohaib Akhtar Kausar -> UO291060@uniovi.es + +Sara Lamuño García -> UO283706@uniovi.es + +Santiago Lopez Laso -> UO277369@uniovi.es | Los estudiantes que llevarán a cabo el desarrollo de la aplicación. Seran los encargados de la arquitectura, la documentación y la codificación. +| Profesores | labra@uniovi.es | Supervisores de los avances y encargados de evaluar la aplicacion final y el desarrollo de la misma. |=== diff --git a/docs/src/02_architecture_constraints.adoc b/docs/src/02_architecture_constraints.adoc index 226e501..4c16bef 100644 --- a/docs/src/02_architecture_constraints.adoc +++ b/docs/src/02_architecture_constraints.adoc @@ -1,27 +1,12 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-architecture-constraints]] -== Architecture Constraints - - -[role="arc42help"] -**** -.Contents -Any requirement that constraints software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies. - -.Motivation -Architects should know exactly where they are free in their design decisions and where they must adhere to constraints. -Constraints must always be dealt with; they may be negotiable, though. - -.Form -Simple tables of constraints with explanations. -If needed you can subdivide them into -technical constraints, organizational and political constraints and -conventions (e.g. programming or versioning guidelines, documentation or naming conventions) - - -.Further Information - -See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation. - -**** +== Restricciones de arquitectura +.Restricciones +[options="header",cols="1,2"] +|=== +|Restricción|Descripción +|Wikidata|Se usará la API de WIkidata para generar las preguntas automáticamente. +|Git|Control de versiones del proyecto. +|GitHub|Portal donde se guardará el código fuente del proyecto. +|=== \ No newline at end of file diff --git a/docs/src/03_system_scope_and_context.adoc b/docs/src/03_system_scope_and_context.adoc index c528e90..ca6d7da 100644 --- a/docs/src/03_system_scope_and_context.adoc +++ b/docs/src/03_system_scope_and_context.adoc @@ -3,73 +3,15 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-system-scope-and-context]] == System Scope and Context - -[role="arc42help"] -**** -.Contents -System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners -(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces. - -If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware). - -.Motivation -The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them. - -.Form -Various options: - -* Context diagrams -* Lists of communication partners and their interfaces. - - -.Further Information - -See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation. - -**** - - -=== Business Context - -[role="arc42help"] -**** -.Contents -Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces. -Optionally you can add domain specific formats or communication protocols. - -.Motivation -All stakeholders should understand which data are exchanged with the environment of the system. - -.Form -All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners. - -Alternatively (or additionally) you can use a table. -The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs. - -**** - -**** - -**** - -=== Technical Context - -[role="arc42help"] -**** -.Contents -Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel. - -.Motivation -Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces. - -.Form -E.g. UML deployment diagram describing channels to neighboring systems, -together with a mapping table showing the relationships between channels and input/output. - -**** - -**** - -**** - -**** +=== Contexto de negocio +En esta tabla se muestra el contexto de negocio de la aplicación. Las entradas son los mensajes que van desde el agente externo hacia la aplicación, y las salidas son los mensajes que van desde la aplicación hacia al agente externo. +[options="header",cols="1,2,3"] +|=== +|Agente externo|Entradas|Salidas +|Usuario|Datos registro, datos login, respuesta a cada pregunta|Preguntas, histórico +|Wikidata|Ítems(elementos) de Wikidata|Petición a la API de Wikidata +|=== + +=== Contexto técnico + +image::diagrama_contexto_tecnico.drawio.png["Diagrama de contexto técnico"] \ No newline at end of file diff --git a/docs/src/04_solution_strategy.adoc b/docs/src/04_solution_strategy.adoc index 7bf03f7..35764a9 100644 --- a/docs/src/04_solution_strategy.adoc +++ b/docs/src/04_solution_strategy.adoc @@ -24,6 +24,87 @@ Motivate what was decided and why it was decided that way, based upon problem statement, quality goals and key constraints. Refer to details in the following sections. +Decisiones tecnológicas + +Hemos decidido realizar la parte de Front-End con React y la parte de Back-End con la estructura de los microservicios. +El despliegue se realizará a través de una máquina virtual de Azure, con ayuda de Docker y GitHub Actions. + +[options="header",cols="1,2"] +|=== +|Aplicación +|Breve explicación +|React +|Biblioteca de JavaScript que nos servirá para realizar las interfaces de usuario necesarias para el Front-End. +|Microservicios +|Aquí es donde se unirá el uso de la API (Application Programming Interface) de WikiData, la cual nos sacará los datos para las preguntas y las respuestas +de la aplicación con el proyecto en sí. +|Azure +|Plataforma para la creación de la máquina virtual que servirá para desplegar la aplicación. +|Docker +|Encargado de dividir el contenido del proyecto en diversos contenedores (en nuestro caso 4) y sea más fácil de manipular el contenido de dicho proyecto. +|GitHub Actions +|Nos servirá para el despliegue del proyecto, pero de forma automática en vez de desplegarlo todo a mano. Cabe a destacar que también están implementados +unos test para asegurar el correcto despliegue del proyecto. +|=== + +Decisiones de cómo llegar a las metas principales (En desarrollo): +[options="header",cols="1,2"] +|=== +|Usabilidad +| +|Privacidad +| +|Mantenibilidad +| +|Eficiciencia +| +|Fiabilidad +| + +|=== + + + +Decisiones organizativas + +En la primera semana nos hemos dividido en dos equipos con el objetivo de tocar todas las partes del proyecto. La estructura de los equipos es la siguiente: + +---- +-> Equipo documentación + Sara Lamuño García -> UO283706@uniovi.es + Yago Navajas Gonzalez -> UO287746@uniovi.es +-> Equipo desarrollo del proyecto + David Álvarez Díaz -> UO283196@uniovi.es + Zohaib Akhtar Kausar -> UO291060@uniovi.es + Santiago Lopez Laso -> UO277369@uniovi.es +---- + +La realización de las actas de las reuniones diarias se le ha asignado la tarea a Sara Lamuño García. + +En las siguientes semanas habrá rotación o cambio de miembros en ambos equipos. + +En la segunda semana hemos decidido ponernos de manera más profunda con la documentación, asignando diferentes apartados de esta a cada miembro del equipo: + +[options="header",cols="1,2"] +|=== +| Miembro +| Documentación +| Sara Lamuño García +| 4, 6, 12 +| Yago Navajas Gonzalez +| 1, 8, 9 +| David Álvarez Díaz +| 5, 7 +| Zohaib Akhtar Kausar +| 10, 11 +| Santiago Lopez Laso +| 2, 3 +|=== + +Se han creado el mismo número de Issues como apartados de la documentación hay para asignarla a cada miembro. + +En cuanto al despliegue de la aplicación se van a arreglar los errores que salen en los test al intentar desplegarla, ya que se han cambiado +algunos valores predefinidos, por lo que los test también predefinidos fallarán. .Further Information diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc index e10f375..fb80e36 100644 --- a/docs/src/06_runtime_view.adoc +++ b/docs/src/06_runtime_view.adoc @@ -58,8 +58,52 @@ Alice -> Bob: Another authentication Request Alice <-- Bob: another authentication Response ---- -=== +[plantuml,"Sequence diagram",png] +Diagrama de secuencia con plantuml (se contempla sólo el uso correcto de la aplicación) +---- +actor usuario +actor system +database bbdd as "bbdd" +actor juego +usuario -> system: inicio sesión +system --> usuario: pedir nombre/contraseña +usuario -> system: dar nombre/contraseña +system -> bbdd: verificar usuario +bbdd --> system: verificación correcta +system --> usuario: inicio sesión correcto +usuario -> system: acceder al juego +system -> juego: iniciar juego +juego --> system: generar pregunta/respuestas +system --> usuario: mostrar pregunta/respuestas +usuario -> system: responder +system -> juego: verificar respuesta +juego --> system: respuesta correcta +system --> usuario: correcta +system -> juego: generar siguiente pregunta/respuestas -=== ... +---- -=== +=== +------------------------------------------------------------------------------------------------------------------------------------- +| -> Diagrama de secuencia | +| -> Descripción: diagrama de los usos básicos en la aplicación, como inicio de sesión, empezar a jugar y contestar las preguntas. | +| -> Aspectos notables: | +| - El usuario tiene que estar autentificado en la aplicación para poder entrar al juego. | +| - Los usuarios estarán en una base de datos para recoger los datos de manera más sencilla. | +| - En el diagrama se pone la opción de respuesta correcta, pero si fuera incorrecta también se seguiría jugando. | +------------------------------------------------------------------------------------------------------------------------------------- +image::Digrama de secuencia Juego de preguntas.jpg["Diagrama de secuencia"] + +=== +-------------------------------------------------------------------------------------------------------------------------------------- +| -> Diagrama de casos de uso | +| -> Descripción: diagrama básico de los distintos casos de uso que hay en el proyecto | +| -> Aspectos notables: | +| - El caso de uso de iniciar sesión del usuario está relacionado con el caso de uso de autentificar sesión del sistema, | +| - ya que para que el usuario pueda iniciar sesión debe de estar autentificado. | +| - Lo mismo ocurre con el caso de uso de contestar preguntas del usuario con el caso de uso de verificar respuestas del sistema, | +| - ya que para que el usuario pueda contestar preguntas, el sistema primero debe de verificar si dicha respuesta es correcta | +| - o no para pasar a la siguiente pregunta. | +-------------------------------------------------------------------------------------------------------------------------------------- + +image::Diagrama de casos de uso para el juego de palabras.jpg["Diagrama de caso de uso"] diff --git a/docs/src/08_concepts.adoc b/docs/src/08_concepts.adoc index 591ccf1..23e724c 100644 --- a/docs/src/08_concepts.adoc +++ b/docs/src/08_concepts.adoc @@ -1,73 +1,32 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-concepts]] -== Cross-cutting Concepts +== Conceptos Transversales +Estos conceptos todavia no han sido aprobados ni implemenmtados pero dan una idea general al proyecto. +=== Modelo de Dominio +Esta es una primera version del modelo del dominio muy simple para hacerse una idea como funcionara la aplicacion. -[role="arc42help"] -**** -.Content -This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system. -Such concepts are often related to multiple building blocks. -They can include many different topics, such as -* models, especially domain models -* architecture or design patterns -* rules for using specific technology -* principal, often technical decisions of an overarching (= cross-cutting) nature -* implementation rules +=== Experiencia de Usuario -.Motivation -Concepts form the basis for _conceptual integrity_ (consistency, homogeneity) of the architecture. -Thus, they are an important contribution to achieve inner qualities of your system. +El usuario sera capaz de interactura con una aplicacion web donde se podra registrar y jugar al juego de manera sencilla. -Some of these concepts cannot be assigned to individual building blocks, e.g. security or safety. +image::08_diagrama_modelo_dominio.png["Modelo de dominio simple provisional"] - -.Form -The form can be varied: - -* concept papers with any kind of structure -* cross-cutting model excerpts or scenarios using notations of the architecture views -* sample implementations, especially for technical concepts -* reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping) - -.Structure -A potential (but not mandatory) structure for this section could be: - -* Domain concepts -* User Experience concepts (UX) -* Safety and security concepts -* Architecture and design patterns -* "Under-the-hood" -* development concepts -* operational concepts - -Note: it might be difficult to assign individual concepts to one specific topic -on this list. - -image::08-Crosscutting-Concepts-Structure-EN.png["Possible topics for crosscutting concepts"] - - -.Further Information - -See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation. -**** - - -=== __ +=== Seguridad __ +=== Arquitectura y Patrones de Diseño +__ -=== __ +=== Desarrollo __ -... - -=== __ +=== Operaciones -__ +__ \ No newline at end of file diff --git a/docs/src/09_architecture_decisions.adoc b/docs/src/09_architecture_decisions.adoc index 51e9aad..2640737 100644 --- a/docs/src/09_architecture_decisions.adoc +++ b/docs/src/09_architecture_decisions.adoc @@ -1,35 +1,11 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-design-decisions]] -== Architecture Decisions - - -[role="arc42help"] -**** -.Contents -Important, expensive, large scale or risky architecture decisions including rationales. -With "decisions" we mean selecting one alternative based on given criteria. - -Please use your judgement to decide whether an architectural decision should be documented -here in this central section or whether you better document it locally -(e.g. within the white box template of one building block). - -Avoid redundancy. -Refer to section 4, where you already captured the most important decisions of your architecture. - -.Motivation -Stakeholders of your system should be able to comprehend and retrace your decisions. - -.Form -Various options: - -* ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Documenting Architecture Decisions]) for every important decision -* List or table, ordered by importance and consequences or: -* more detailed in form of separate sections per decision - -.Further Information - -See https://docs.arc42.org/section-9/[Architecture Decisions] in the arc42 documentation. -There you will find links and examples about ADR. - -**** +== Decisiones de Arquitectura + +|=== +| Decisión | Ventajas | Inconvenientes +| JavaScript / React | La base de la aplicación ya esta creada con este lenguaje y lo para la creación de sitios web es un versatil. | La baja o nula esperiencia con el lenguaje de algunos integrantes del grupo asi como sus limitaciones tecninas. +| Microservicios | La aplicacion se podra dividir en problemas que se podran solucionar dandole diferentes enfoques con diferentes lenguajes y metodologias. | AL igual que el primer punto, la baja experiencia con esta forma de trabajo al cual se tendra que adaptar el grupo. +| MongoDB | Parte de la implementacion ya está hecha. Por otra parte es de uso libre y existe bastante documentacion online para usarse correctamente | Al igual que los dos puntos anteriores, el grupo cuenta con poca experiencia usando esta tecnología y no somos concientes de todas sus limitaciones y fortalezas. +|=== diff --git a/docs/src/10_quality_requirements.adoc b/docs/src/10_quality_requirements.adoc index 68475e8..98f1c11 100644 --- a/docs/src/10_quality_requirements.adoc +++ b/docs/src/10_quality_requirements.adoc @@ -1,73 +1,41 @@ ifndef::imagesdir[:imagesdir: ../images] += Requisitos de Calidad 🌟 -[[section-quality-scenarios]] -== Quality Requirements +== Árbol de Calidad 🌳 +El árbol de calidad se organiza con "calidad" como raíz, desglosándose en varias ramas principales que representan categorías de calidad relevantes para el proyecto WIQ. Estas ramas incluyen: -[role="arc42help"] -**** +- *Usabilidad* 💡: Se refiere a la facilidad con la que los usuarios pueden utilizar un sistema para alcanzar sus objetivos de manera eficiente y satisfactoria. La usabilidad implica interfaces intuitivas, accesibilidad y una experiencia de usuario agradable. +- *Rendimiento* ⚡: Evalúa la eficiencia del sistema en términos de velocidad de respuesta, consumo de recursos y escalabilidad. Un buen rendimiento asegura que el sistema puede manejar cargas de trabajo elevadas con tiempos de respuesta rápidos. +- *Seguridad* 🔒: Implica proteger la información y los sistemas contra accesos no autorizados, divulgación, alteración o destrucción, garantizando la confidencialidad, integridad y disponibilidad de los datos. +- *Fiabilidad* 🛡️: La capacidad del sistema de funcionar correctamente y sin fallos durante un período determinado bajo condiciones específicas. La fiabilidad se centra en la consistencia del rendimiento y la prevención de fallos. +- *Mantenibilidad* 🔧: Se refiere a la facilidad con la que un sistema puede ser modificado para corregir fallos, mejorar su funcionamiento o adaptarse a un entorno cambiante. Una alta mantenibilidad facilita las actualizaciones y reduce los costos a largo plazo. +- *Portabilidad 🌍*: La capacidad de un sistema para ser utilizado en diferentes entornos operativos con mínimas modificaciones. La portabilidad permite que el software sea compatible con diversos dispositivos, sistemas operativos o navegadores web. -.Content -This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals) +image::10_Arbol_de_calidad.jpg[Árbol de Calidad,align="center"] -Here you can also capture quality requirements with lesser priority, -which will not create high risks when they are not fully achieved. +== Escenarios de Calidad -.Motivation -Since quality requirements will have a lot of influence on architectural -decisions you should know for every stakeholder what is really important to them, -concrete and measurable. +=== Usabilidad 💡 +- *Escenario*: Un nuevo usuario puede registrarse e iniciar a jugar en menos de 5 minutos después de su primer acceso al sitio web. La interfaz intuitiva y la guía de inicio rápido facilitan este proceso. 🚀 -.Further Information +=== Rendimiento ⚡ -See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 documentation. +- *Escenario*: El sistema responde a las solicitudes de los usuarios en menos de 2 segundos bajo condiciones normales de carga, asegurando una experiencia de juego fluida. 🏎️ -**** +=== Seguridad 🔒 -=== Quality Tree +- *Escenario*: Todos los datos personales de los usuarios están cifrados tanto en tránsito como en reposo, utilizando estándares de seguridad actuales para prevenir accesos no autorizados. 🔐 -[role="arc42help"] -**** -.Content -The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs. +=== Mantenibilidad 🔧 -.Motivation -The tree structure with priorities provides an overview for a sometimes large number of quality requirements. +- *Escenario*: El sistema permite la adición de nuevas funcionalidades (como tipos de preguntas o temáticas) sin necesidad de una reestructuración mayor, promoviendo una arquitectura modular. 🛠️ -.Form -The quality tree is a high-level overview of the quality goals and requirements: +=== Fiabilidad 🛡️ -* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root -* a mind map with quality categories as main branches +- *Escenario*: En caso de fallo del sistema, este debe ser capaz de recuperarse y volver a estar operativo en menos de 5 minutos, garantizando una alta disponibilidad. 🔄 -In any case the tree should include links to the scenarios of the following section. +=== Portabilidad 🌍 - -**** - -=== Quality Scenarios - -[role="arc42help"] -**** -.Contents -Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios. - -These scenarios describe what should happen when a stimulus arrives at the system. - -For architects, two kinds of scenarios are important: - -* Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second. -* Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change. - -.Motivation -Scenarios make quality requirements concrete and allow to -more easily measure or decide whether they are fulfilled. - -Especially when you want to assess your architecture using methods like -ATAM you need to describe your quality goals (from section 1.2) -more precisely down to a level of scenarios that can be discussed and evaluated. - -.Form -Tabular or free form text. -**** +- *Escenario*: La aplicación web es compatible con los navegadores web más utilizados (Chrome, Firefox, Safari, Edge) en sus últimas dos versiones principales, asegurando un amplio acceso. 🌐 \ No newline at end of file diff --git a/docs/src/11_technical_risks.adoc b/docs/src/11_technical_risks.adoc index dc5575f..6998b64 100644 --- a/docs/src/11_technical_risks.adoc +++ b/docs/src/11_technical_risks.adoc @@ -1,25 +1,16 @@ -ifndef::imagesdir[:imagesdir: ../images] -[[section-technical-risks]] -== Risks and Technical Debts - - -[role="arc42help"] -**** -.Contents -A list of identified technical risks or technical debts, ordered by priority - -.Motivation -“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.) - -This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning. - -.Form -List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts. - - -.Further Information - -See https://docs.arc42.org/section-11/[Risks and Technical Debt] in the arc42 documentation. - -**** += Risks and Technical Debts 🚀 + +[width="100%",options="header",cols="^,^"] +|====================== +| 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 equipo grande 👥 | La coordinación y comunicación en un equipo grande 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. +| 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. + +|====================== diff --git a/docs/src/12_glossary.adoc b/docs/src/12_glossary.adoc index 192b235..d534de7 100644 --- a/docs/src/12_glossary.adoc +++ b/docs/src/12_glossary.adoc @@ -34,9 +34,38 @@ See https://docs.arc42.org/section-12/[Glossary] in the arc42 documentation. |=== |Term |Definition -| -| +|React +|Biblioteca de Javascript que se encarga en la creación de interfaces de usuario de una manera fácil. Es eficiente y se puede incorporar +al código de una forma sencilla. + +|Node.js +|Entorno que usa Javascript, donde destaca en la creación de servidores web. Su programación es dirigida por eventos, es multi-plataforma, open-source +y soporta la concurrencia. + +|Microservicio +|Enfoque arquitectónico, donde el software se va a dividir en servicios de tamaño pequeño, que estarán unidos por la intervención de API's +(en nuestro caso Wikidata). Son rápidos, sencillos a la hora de su desarrollo y autonómos cuando estos están en ejecución. + +|API +|O también Application Programming Interface, es un intermediario que ayuda a las diferentes aplicaciones del proyecto a posibilitar la comunicación +entre ellas. Favorece a la eficiencia y agilidad del funcionamiento de dichas aplicaciones. + +|MongoDB +|Es uno de los tantos tipos de bases de datos, como MariaDB. Usa NoSQL, soporta múltiples lenguajes de programación y también soporta su funcionamiento en +gran variedad de sistemas operativos. Algo a tener en cuenta es que MongoDB realiza el guardado de datos de una forma distinta a la de las bases de datos de +tipo relacional, con tablas de datos, este lo guarda en archivos BSON, que es un derivado de JSON. + +|BSON +|O Binary JSON, son los archivos que usa la base de datos MongoDB para almacenar los datos de una manera más ágil y sencilla que con las tablas. Una +curiosidad de este tipo de archivo es que no tiene un tipo de MIME definido, mientras que JSON sí que lo tiene. + +|Mongoose +|Biblioteca que es encargada de crear una conexión con la base de datos MongoDB con el entorno de Node.js. Hace que el acceso y creación de los datos de MongoDB sea más fácil de realizar que con MongoDB en sí. + +|Docker +|Aplicación que realiza el despliegue de cualquier aplicación en formato de contenedores, similares a los contenedores que tienen los barcos. Es open-source y permite que el proceso de desplegar una aplicación sea bastante más fácil y ordenado. + +|GitHub Actions +|Plataforma que ayuda a automatizar los proyectos, haciendo posible el despliegue de estos desde el mismo Github. Soporta una gran variedad de lenguajes de +programación y sistemas operativos. -| -| -|===