Merge branch 'master' of https://github.com/Arquisoft/wiq_es05c

docs/index.adoc

@@ -6,7 +6,7 @@
 // configure EN settings for asciidoc
 include::src/config.adoc[]
 
-= image:wiq2.png[WIQ Logo] image:arc42-logo.png[arc42] Documentación WIQ-ES05C
+= image:wiq2.png[WIQ Logo] Documentation WIQ-ES05C
 
 
 :revnumber: 8.2 EN
@@ -30,10 +30,6 @@ ifdef::backend-html5[]
 ++++
 endif::backend-html5[]
 
-
-include::src/about-arc42.adoc[]
-
-// horizontal line
 ***
 
 [role="arc42help"]

docs/src/01_introduction_and_goals.adoc

@@ -3,72 +3,16 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-introduction-and-goals]]
 == Introduction and Goals (wiq_es05c)
 
-[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
-****
-
 WIQ is a Web application requested by RTVE, in order to create an experimental online version of a question and
 answer contest similar to “Saber y Ganar”. 
 The development of said application has been entrusted to our company, HappySw.
 
 === Requirements Overview
 
-[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.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation.
-
-****
-
 The main requirements to be met by our application will be link:requirements.adoc[found here].
 
 === 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"]
 |===
 |Goals | Description
@@ -80,26 +24,6 @@ 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"]
 |===
 |Role/Name | Expectations

docs/src/06_runtime_view.adoc

@@ -67,7 +67,7 @@ image::06-getRanking.png["GetRanking secuence diagram image"]
 1. The user wants to see the ranking of all players
 2. The app requests to the HistoryService that ranking
 3. The HistoryService gets the ranking from the History data base
-5. Finally the ranking is shown to the user
+4. Finally the ranking is shown to the user
 
 === Multiplayer game
 
@@ -76,7 +76,7 @@ image::06-multiplayer.png["Multiplayer game secuence diagram image"]
 1. Two users want to join a room and play a multiplayer game
 2. The application sends a request to the RoomsService
 3. This RoomsService where a room was created moments ago create a socket for each player 
-5. The RoomsService gets from the app the game details, questions and logic.
-6. All the game is managed by the RoomsService
-7. When the game is finished the RoomsService sends a response to the application
-8. Then the application sends all the results to the players
+4. The RoomsService gets from the app the game details, questions and logic.
+5. All the game is managed by the RoomsService
+6. When the game is finished the RoomsService sends a response to the application
+7. Then the application sends all the results to the players

docs/src/08_concepts.adoc

@@ -21,6 +21,9 @@ Additionally, they can start a new game at any time and, upon completion, view t
 Here you can see the home page of our webapp.
 
 
+image::Inicio.png["Index WebApp Result"] 
+
+
 === Security & Safety
      - Privacy: The data introduced will be private and not visible to other users.
      - The password will be stored encrypted.

docs/src/10_quality_requirements.adoc

@@ -27,53 +27,10 @@ See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 docume
 
 === Quality Tree
 
-[role="arc42help"]
-****
-.Content
-The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.
-
-.Motivation
-The tree structure with priorities provides an overview for a sometimes large number of quality requirements.
-
-.Form
-The quality tree is a high-level overview of the quality goals and requirements:
-
-* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root
-* a mind map with quality categories as main branches
-
-In any case the tree should include links to the scenarios of the following section.
-
-
-****
-
 image::QualityTree.PNG["Quality Tree"]
 
 === 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.
-****
-
 [options="header",cols="1,2,2"]
 |===
 |Quality Goal | Scenario | Description

docs/src/11_technical_risks.adoc

@@ -55,8 +55,6 @@ Risks that we can try to prevent but at the end doesn't depend on us:
 
 === Technical Debt
 
-TO-DO 
-
 [options="header" frame=all]
 |===
 |Technical Debt |Description 

docs/src/13_tests.adoc

@@ -130,6 +130,3 @@ In summary, load testing allows us to ensure performance and identify bottleneck
 
 image::TestCarga.png["Load Tests Result"] 
 
-
-[[section-mointorig-results]]
-=== Monitoring Results

webapp/e2e/steps/basicButtons-form.steps.js

@@ -133,7 +133,7 @@ defineFeature(feature, test => {
       const backgroundColor = await page.$eval('#navbar', el => getComputedStyle(el).backgroundColor);
 
       // Verifica que el color de fondo coincide con el claro
-      expect(backgroundColor).toBe('rgb(254, 245, 198)');
+      expect(backgroundColor).toBe('rgb(55, 190, 176)');
     });
   })