Merge branch 'doc' of https://github.com/Arquisoft/wiq_es1a

.vscode/settings.json

@@ -0,0 +1 @@
+{}

docs/src/01_introduction_and_goals.adoc

@@ -2,93 +2,77 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-introduction-and-goals]]
 == Introduction and Goals
-[role="arc42help"]
-****
-Describes the relevant requirements and the driving forces that software architects and development team must consider. 
-These include
-
-* underlying business goals, 
-* essential features, 
-* essential functional requirements, 
-* quality goals for the architecture and
-* relevant stakeholders and their expectations
-****
 
-=== Requirements Overview
+WIQ! is a project developed for the subject "Software Architecture" of the Computer Engineering degree of the School of Computer Engineering of the University of Oviedo. This project is based on the wiq project, made available to the students by the teachers of the subject.
+WIQ! has been commissioned to the company HappySw by RTVE, with the aim of recreating its famous quiz show Saber y ganar in a web version accessible to everyone. This project will be carried out by the development team is formed by:
 
-[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).
+* Martín Cancio Barrera, mailto:[email protected][_UO287561_].
 
-.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.
+* Iyán Fernández Riol, mailto:[email protected][_UO288231_].
 
-.Form
-Short textual description, probably in tabular use-case format.
-If requirements documents exist this overview should refer to these documents.
+* Rodrigo García Iglesias, mailto:[email protected][_UO276396_].
 
-Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
+* Alfredo Jirout Cid, mailto:[email protected][_UO288443_]. 
 
+WIQ! is a software by means of which users can emulate being the participants of the quiz show Saber y ganar, which has numerous functionalities:
 
-.Further Information
+* Play several of the game modes seen on the show.
 
-See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation.
+* Register to be able to keep track of their statistics in the game
 
-****
+* Play with friends
 
-=== Quality Goals
+* Adjust the themes of the questions, the answer time, the number of questions...
+***
+
+=== Requirements Overview
+
+* The system will have at least one web frontend that will be deployed and accessed via the web.
+* Users will be able to register in the system and consult the history of their participation in the system: number of games, number of correct/failed questions, times, etc.
+* Questions will be automatically generated from Wikidata data.
+* Questions must be answered within a given time limit.
+* Each question will have one correct answer and several incorrect or distracting answers. Both correct and incorrect answers will be generated automatically.
+* The system shall allow access to user information through an API.
+* The system shall allow access to the information of the generated questions through an API.
 
-[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.
+=== Quality Goals
 
-Consider this overview of potential topics (based upon the ISO 25010 standard):
+[options="header"]
+|===
+| Priority | Quality Goal | Motivation
 
-image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"]
+| *1*
+| *_Usability_*
+| The application should be intuitive for users, making it easy for them to interact with the application regardless of their skills.
 
-.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...
+| *2*
+| *_Mantainability_*
+| The application must have a well-defined and structured design, so that it is easy to make modifications and/or extensions.
 
-.Form
-A table with quality goals and concrete scenarios, ordered by priorities
-****
+| *3*
+| *_Privacy_*
+| The application must guarantee the privacy of its users' information, with mechanisms in place to prevent intrusions into the system.
+|===
 
 === Stakeholders
 
-[role="arc42help"]
-****
-.Contents
-Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
+[options="header"]
+|===
+|Role/Name|Contact|Expectations 
 
-* 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
+| *_Students (HappySw)_*
+| Martín Cancio Barrera, Iyán Fernández Riol, Rodrigo García Iglesias and Alfredo Jirout Cid
+| The students are the developers of the application. They are in charge of the complete development, which will improve their programming and teamwork skills.
 
-.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.
+| *_Users_*
+| Anyone who uses the application
+| Users are the ones who will ultimately use the application, so it must be intuitive and easy to understand.
 
-.Form
-Table with role names, person names, and their expectations with respect to the architecture and its documentation.
-****
+| *_Teachers_*
+| José Emilio Labra Gayo, Pablo González González, Jorge Álvarez Fidalgo and  Cristian Augusto Alonso. 
+| They are the supervisors of the project, and will help the students toensure that the project comes to fruition.
 
-[options="header",cols="1,2,2"]
-|===
-|Role/Name|Contact|Expectations
-| Alfredo Jirout Cid | [email protected] | Aprobar (opcional)
-| Rodrigo Gracía Iglesias | [email protected] | No tomar de ejemplo a Miguel
-| Iyán Fernández Riol | [email protected] | Sacar matricula
-| Martín Cancio Barrera | [email protected] | Ser feliz
+| *_RTVE_*
+| RTVE
+| They are the main stakeholders in the application, as they are the ones who commissioned it, so that their viewers can use it.
 |===

docs/src/02_architecture_constraints.adoc

@@ -3,25 +3,23 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-architecture-constraints]]
 == Architecture Constraints
 
+|===
+| *_Architecture constraint_* | *_Description_*
 
-[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.
+| *_Tecnología de Desarrollo_* | The application must be developed using web technologies compatible with RTVE's requirements and standards.
 
-.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.
+| *_Plataforma de Implementación_* | The application must be implemented on a web hosting platform that meets RTVE's performance, security and scalability requirements.
 
-.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)
+| *_Cumplimiento de Normativas de Privacidad_* | The architecture must ensure compliance with data privacy regulations, such as GDPR, to protect users' information.
 
+| *_Compatibilidad con Navegadores_* | The application should be compatible with a wide range of popular web browsers to ensure a consistent user experience.
 
-.Further Information
+| *_Seguridad de la Información_* | Strong security measures, such as user authentication, access control and data encryption, must be implemented to protect users' confidential information.
 
-See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
+| *_Escalabilidad_* | The architecture must be scalable to handle increased user traffic without compromising performance.
 
-****
+| *_Mantenibilidad del Código_* | Software development practices that promote clean and well-documented code should be followed to facilitate future upgrades and maintenance.
+
+| *_Tiempo de Desarrollo_* | The application must be developed within a specific time frame, which may influence architectural decisions and technology selection.
+
+|===

docs/src/03_system_scope_and_context.adoc

@@ -3,73 +3,8 @@ 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.
-
-****
-
-**<Diagram or Table>**
-
-**<optionally: Explanation of external domain interfaces>**
+image::businesscontext.png[Business context]
 
 === 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.
-
-****
-
-**<Diagram or Table>**
-
-**<optionally: Explanation of technical interfaces>**
-
-**<Mapping Input/Output to Channels>**
+image::technicalcontext.png[Technical Context]

docs/src/08_concepts.adoc

@@ -56,18 +56,62 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 ****
 
 
-=== _<Concept 1>_
+=== _<User Interface >_
 
-_<explanation>_
+_<A user interface is the space where a human and a computer or device communicate and exchange information.>_
 
+=== _<Ergonomics >_
 
+_<Ergonomics is the science of designing and arranging workplaces, products, and systems to fit and adapt to the people who use them. Ergonomics aims to improve comfort, efficiency, and safety by considering human physical and psychological needs and limitations. >_
 
-=== _<Concept 2>_
+=== _<Internationalization >_
+
+_<Internationalization is the practice of designing and developing applications that can support multiple languages, formats, and conventions>_
+
+=== _<Security >_
+
+_<Security is a broad term that can refer to different aspects of protection, resilience, or prevention of harm. >_
+
+=== _<Safety  >_
+
+_<Is the state of being protected from danger or harm.>_
+
+=== _<Build, Test, Deploy >_
+
+_<- Build: This stage involves compiling, validating, and packaging the source code into executable or deployable artifacts. 
+- Test: This stage involves running various tests, such as unit tests, integration tests, and regression tests, to ensure the quality and functionality of the software. 
+- Deploy: This stage involves delivering or releasing the software to the target environment, such as a server, a cloud platform, or a user device. >_
+
+=== _<Code Generation >_
+
+_<Code generation is the process of creating executable or deployable code from various sources of information, such as natural language, images, or other code.>_
+
+=== _<Migration >_
+
+_<Migrating from one software application or platform to another, such as switching from a legacy system to a modern one, or from a local server to a cloud service.>_
+
+=== _<Configurability >_
+
+_<Configurability is the ability to modify or customize something, especially in computing, electronics, or de>_
+
+=== _<Administration >_
+
+_<The process or activity of managing, directing, or organizing something or someone>_
+
+=== _<Management >_
+
+_<Management is the process of organizing and directing the resources of a business or organization to achieve its goals. >_
+
+=== _<Disaster-Recovery >_
+
+_<Is the process of restoring the functionality and data of software applications after a disaster, such as a natural calamity, a cyberattack, or a human error.>_
+
+=== _<Architecture and design patterns  >_
+
+_<Architecture and design patterns are concepts that help software developers and architects design and build software systems that are efficient, scalable, and maintainable>_
 
-_<explanation>_
 
-...
 
-=== _<Concept n>_
+=== _<Concept >_
 
 _<explanation>_