diff --git a/docs/images/IndexAccesibility.png b/docs/images/IndexAccesibility.png index ca19a1f..1ba3f07 100644 Binary files a/docs/images/IndexAccesibility.png and b/docs/images/IndexAccesibility.png differ diff --git a/docs/images/Inicio.png b/docs/images/Inicio.png new file mode 100644 index 0000000..980669d Binary files /dev/null and b/docs/images/Inicio.png differ diff --git a/docs/index.adoc b/docs/index.adoc index e3831b2..9b2621e 100644 --- a/docs/index.adoc +++ b/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"] diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index a11395c..5010163 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/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 diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc index 3f22aa9..b193633 100644 --- a/docs/src/06_runtime_view.adoc +++ b/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 \ No newline at end of file +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 \ No newline at end of file diff --git a/docs/src/08_concepts.adoc b/docs/src/08_concepts.adoc index 48b3508..6a4e018 100644 --- a/docs/src/08_concepts.adoc +++ b/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. diff --git a/docs/src/10_quality_requirements.adoc b/docs/src/10_quality_requirements.adoc index bf974e8..41ec8ec 100644 --- a/docs/src/10_quality_requirements.adoc +++ b/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 diff --git a/docs/src/11_technical_risks.adoc b/docs/src/11_technical_risks.adoc index 431b5dd..aad056c 100644 --- a/docs/src/11_technical_risks.adoc +++ b/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 diff --git a/docs/src/13_tests.adoc b/docs/src/13_tests.adoc index 733fa6d..7998578 100644 --- a/docs/src/13_tests.adoc +++ b/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 diff --git a/webapp/e2e/steps/basicButtons-form.steps.js b/webapp/e2e/steps/basicButtons-form.steps.js index 08cd415..3b60b5b 100644 --- a/webapp/e2e/steps/basicButtons-form.steps.js +++ b/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)'); }); })