Arquisoft · holmess23 · Mar 1, 2024 · Feb 22, 2024 · Feb 22, 2024 · Feb 22, 2024
diff --git a/.idea/.gitignore b/.idea/.gitignore
diff --git a/.idea/jsLibraryMappings.xml b/.idea/jsLibraryMappings.xml
diff --git a/.idea/misc.xml b/.idea/misc.xml
diff --git a/.idea/modules.xml b/.idea/modules.xml
diff --git a/.idea/proyecto.iml b/.idea/proyecto.iml
diff --git a/.idea/vcs.xml b/.idea/vcs.xml
diff --git a/.idea/workspace.xml b/.idea/workspace.xml
diff --git a/docs/images/5_image_1.png b/docs/images/5_image_1.png
diff --git a/docs/images/5_image_2.png b/docs/images/5_image_2.png
diff --git a/docs/images/business.png b/docs/images/business.png
diff --git a/docs/images/quality_tree.png b/docs/images/quality_tree.png
diff --git a/docs/images/technical.png b/docs/images/technical.png
diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc
@@ -1,93 +1,40 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-introduction-and-goals]]
-== Introduction and Goals
+== Introducción y Objetivos
 
-[role="arc42help"]
-****
-Describes the relevant requirements and the driving forces that software architects and development team must consider. 
-These include
+Saber y Ganar es el proyecto de Arquitectura de Software desarrollado por el equipo 6A. Los integrantes de este equipo son:
 
-* underlying business goals, 
-* essential features, 
-* essential functional requirements, 
-* quality goals for the architecture and
-* relevant stakeholders and their expectations
-****
+* Ángel Luis Álvarez Iglesias
+* Álvaro García Miranda
+* Ben James Coleman Kheyyali
+* Eloy Martín Reig
+* Óscar Abad López
+* Sara Fernández González
 
-=== Requirements Overview
+Con el profesor: Jorge Álvarez Fidalgo
 
-[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).
+Este proyecto consiste en una aplicación con un juego de preguntas y respuestas. Además los usuarios registrados podrán ver sus estadísticas y las de otros jugadores.
 
-.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.
+=== Objetivos de Calidad
+Segun ISO/IEC 25010
 
-.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.
-
-
-.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"]
-
-.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...
-
-.Form
-A table with quality goals and concrete scenarios, ordered by priorities
-****
+[options="header",cols="1,2,2"]
+|===
+|Objetivo de Calidad|Realización|Prioridad
+| Usabilidad | Para que la aplicación sea usable se buscará mantener un diseño uniforme y basarse en la predictibilidad para que el aprendizaje de uso de la aplicación sea sencillo y para que no se complique la experiencia del usuario.| 5
+| Testabilidad | Se realizarán pruebas lo más exhaustivas posible para asegurar el correcto funcionamiento de todos los servicios presentes en la aplicación. | 4
+| Rendimiento | Una de las prioridades del proyecto es que funcione en tiempo y forma y que no se generen grandes pantallas de carga y que el jugador no tenga que esperar demasiado para poder jugar cómodamente. | 4
+| Fiabilidad | Se buscará que el uso de recursos dentro de la aplicación sea lo más optimizado posible para que el funcionamiento de la aplicación no se vea afectado en velocidad o eficacia. | 3
+| Seguridad | Se debe buscar cumplir unos mínimos para que no sea fácil el acceso a cuentas que no te pertenecen y que la información de los usuarios no quede fácilmente expuesta. Pero no es uno de los objetivos clave. | 1
+|===
 
 === 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
-| _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_
-| _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_
+|Rol|Descripción|Expectativas
+| Cliente | Nuestro cliente es la empresa ficticia HappySw, este papel es realizado por los profesores de la asignatura. | Una aplicación que cumpla todos los requisitos enumerado en 1.1
+| Equipo de desarrollo | Los alumnos parte de este trabajo que han sido nombrados en la introducción. | Desarrollar una aplicación completa que tenga un reflejo adecuado en la documentación. Tiene que cumplir con los requisitos impuestos y además demostrar el trabajo puesto en el proyecto.
+| Usuarios | Las personas objetivo de la aplicación que probarían o usarían el producto final. Los jugadores. | Un juego divertido que funcione bien y que haga preguntas diversas para que suponga algún reto.
 |===
diff --git a/docs/src/02_architecture_constraints.adoc b/docs/src/02_architecture_constraints.adoc
@@ -1,27 +1,23 @@
-ifndef::imagesdir[:imagesdir: ../images]
-
 [[section-architecture-constraints]]
-== Architecture Constraints
+== Restricciones de arquitectura
+
+|===
+| *_Restricciones de arquitectura_* | *_Descripción_*
+
+| *_Tecnología de Desarrollo_* | El equipo de desarrollo debe desarrollar la aplicación empleando tecnologias web compatibles con los requerimientos y estandares actuales de RTVE.
 
+| *_Plataforma de Implementación_* | La aplicación deberá implementarse sobre una plataforma de alojamiento web que cumpla con los requisitos de rendimiento, seguridad y escalabilidad de RTVE.
 
-[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.
+| *_Cumplimiento de Normativas de Privacidad_* | La arquitectura debe seguir las regulaciones de privacidad de datos actualizadas para garantizar la privacidad de los concursantes.
 
-.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.
+| *_Compatibilidad con Navegadores_* | Para garantizar una experiencia de usuario consistente, la aplicación debe ser compatible con un gran abanico de navegadores web seguros.
 
-.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)
+| *_Seguridad de la Información_* | La solicitud deberá seguir estas medidas de seguridad: autenticación de concursantes, control de acceso y cifrado de datos; con el fin de proteger la información confidencial de los concursantes, pero permitiéndoles comprobarla.
 
+| *_Escalabilidad_* | La arquitectura debe ser escalable para manejar un mayor número de concursantes sin comprometer el rendimiento.
 
-.Further Information
+| *_Mantenibilidad del Código_* | La mejor opción es emplear técnicas de desarrollo de software que promuevan un código limpio y bien documentado. Esto facilitará la actualización y el mantenimiento.
 
-See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
+| *_Tiempo de Desarrollo_* | El equipo de desarrollo deberá desarrollar la aplicación cumpliendo los plazos establecidos. Incluso si eso significa utilizar tecnologías de desarrollo alternativas o cambiar las decisiones arquitectónicas originales.
 
-****
+|===