Merge pull request #17 from Arquisoft/documentation_alejandro_liliana

Documentation alejandro liliana RECORDAR VOLVER A AÑADIR LOS APARTADOS DE HELP más adelante
Arquisoft · Feb 16, 2024 · b51ae3a · b51ae3a
2 parents aed4335 + 8236c20
commit b51ae3a
Show file tree

Hide file tree

Showing 5 changed files with 65 additions and 122 deletions.
diff --git a/docs/images/QualityTree.png b/docs/images/QualityTree.png
diff --git a/docs/src/09_architecture_decisions.adoc b/docs/src/09_architecture_decisions.adoc
@@ -6,30 +6,23 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [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).
+[options="header",cols="1,3,3"]
+|===
+|Architecture decisions
+|Advantages
+|Disagvantanges
 
-Avoid redundancy. 
-Refer to section 4, where you already captured the most important decisions of your architecture.
+|React
+|It is the most used javascript framework and there is a lot of documentation about it. 
+|All of us in the team will have to learn how to use it because we have never worked with it.
 
-.Motivation
-Stakeholders of your system should be able to comprehend and retrace your decisions.
+|JavaScript
+|It is a language we have all used. 
+|It is a complex language that can cause us problems while other simpler languages could make our work easier. 
 
-.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.
+|MongoDB
+|Being a non-relational database, it is easier to use. In addition, it is used by large telecommunications companies.
+|Non-relational databases are the ones with which we have the least experience.
 
 ****
diff --git a/docs/src/10_quality_requirements.adoc b/docs/src/10_quality_requirements.adoc
@@ -4,70 +4,51 @@ ifndef::imagesdir[:imagesdir: ../images]
 == Quality Requirements
 
 
-[role="arc42help"]
 ****
 
-.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)
-
-Here you can also capture quality requirements with lesser priority,
-which will not create high risks when they are not fully achieved.
-
-.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.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 documentation.
+To describe the quality requirements that the game will have, we will use quality scenarios. Quality scenarios describe 
+the action to be performed by the user or the system (stimulus) in order to generate a response to the interaction.
 
 ****
 
 === 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 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.
-****
+Quality scenarios, also known as use cases, are detailed descriptions of situations in which a user interacts with 
+a system and describe the expected outcomes along with the conditions of the environment in which the interaction 
+occurs.
+
+[options="header",cols="1,3,3,1"]
+|===
+|Quality goal
+|Motivation
+|Usage Scenarios
+|Priority
+
+|Privacy
+|In order to be able to play, the user must log in to the application.
+|Only the user who created/owns the account will have access to it (unless he/she gives someone else his/her credentials).
+|High 
+
+|Usability
+|The ease of interaction with the user should be enhanced through intuitive and simple interfaces to enhance the user experience. 
+|Users will be able to understand how the game works thanks to the clarity of its rules and ease of navigation.
+|High
+
+|Diversity
+|The questions provided by the application will be of various topics.
+|The user must correctly answer questions on different topics. This will improve the user experience and maintain the interest of the participants.
+|High
+
+|Integrity
+|The game must be played without errors.
+|The answer determined as correct for each question by the system shall be the one that is actually correct.
+|High
+
+|Interactivity
+|The user must answer a series of questions in which the user must select the correct answer in each case.
+|For each of the questions, the user must select the correct answer from those provided by the system.
+|High
+|===
diff --git a/docs/src/11_technical_risks.adoc b/docs/src/11_technical_risks.adoc
@@ -6,20 +6,13 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [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.) 
+[options="header"]
+|===
+|Risk                       |Consequence
 
-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.
+|Knowledge of REACT         |It is a framework that no team member has used before. Therefore, we have all had to learn how to use it. 
+|Internal group conflicts   |Lack of free time for team members makes group work difficult. 
+|===
 
 ****
diff --git a/docs/src/12_glossary.adoc b/docs/src/12_glossary.adoc
@@ -4,39 +4,15 @@ ifndef::imagesdir[:imagesdir: ../images]
 == Glossary
 
 [role="arc42help"]
-****
-.Contents
-The most important domain and technical terms that your stakeholders use when discussing the system.
-
-You can also see the glossary as source for translations if you work in multi-language teams.
-
-.Motivation
-You should clearly define your terms, so that all stakeholders
-
-* have an identical understanding of these terms
-* do not use synonyms and homonyms
-
-
-.Form
-
-A table with columns <Term> and <Definition>.
-
-Potentially more columns in case you need translations.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-12/[Glossary] in the arc42 documentation.
-
 ****
 
 [cols="e,2e" options="header"]
 |===
-|Term |Definition
+|Term           |Definition
 
-|<Term-1>
-|<definition-1>
-
-|<Term-2>
-|<definition-2>
+|MongoDB        |NoSQL database system that, instead of storing data in tables as a relational database does, stores data in JSON-like documents with a flexible schema. 
+|REACT          |Open source JavaScript library developed by Facebook to build interactive and responsive user interfaces (UI). It is one of the most popular tools for modern web application development.
+|Usability      |Ease with which users can interact with a product, system or application to achieve their objectives effectively, efficiently and satisfactorily. 
 |===
+
+****