User stats

docs/src/10_quality_requirements.adoc

@@ -31,7 +31,7 @@ These are:
 
 === Quality Scenarios
 
-### Usage Scenarios
+#### Usage Scenarios
 
 [options="header"]
 |===
@@ -43,12 +43,13 @@ These are:
 |===
 
 
-### Change Scenarios
+#### Change Scenarios
 
 [options="header"]
 |===
 | Aspect | Source | Stimulus | Artefact | Environment | Response | Response Measurement
 | Security / Maintainability | Developers | We want to add the option of logging in with an e-mail instead of an username | Login system is well structured so it is easy to modify it or add new ways of logging in | Normal conditions | The development team implements the new login method easily, ensuring that neither the current data or the new credentials will be compromised | Successful integration of the new login method without compromising data 
 | Security | Developers | The decision is made to transition from MongoDB to another database system | User data migration to a new database system is secured | Database migration phase | The system initiates a secure data migration process, ensuring all user data, including usernames and passwords, is transferred to the new database system intact and encrypted | Successful transfer of user data without compromise 
 | Maintainability | Developers | Developers want to add a new game mode | The game's code is well-structured and documented | Development phase | Due to code being well-structured and documented, it is easy to add new functionality to our system without risking our already implemented functionality | Successful addition of new game mode 
-| Maintainability | Developers | An error is identified in the game that needs to be corrected. | The game's code is well-structured and documented | Error identification and resolution phase | Due to code being well-structured and documented, developers can easily locate the error and correct it | Successful identification and correction of the error 
+| Maintainability | Developers | An error is identified in the game that needs to be corrected. | The game's code is well-structured and documented | Error identification and resolution phase | Due to code being well-structured and documented, developers can easily locate the error and correct it | Successful identification and correction of the error 
+|===

docs/src/11_technical_risks.adoc

@@ -2,37 +2,13 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-technical-risks]]
 == Risks and Technical Debts
-
-JavaScript: A dynamic, weakly typed language that can have bugs and problems. 
 
-ReactJS: A framework for creating user interfaces, but with difficulties and challenges. A high learning curve is required
-
-NodeJS: An environment for running JavaScript on the server, but with limitations and risks.
-
-MongoDB: A NoSQL database that offers scalability, flexibility, and performance, but with trade-offs and challenges. It does not support transactions, joins, or schemas, which can affect the consistency, integrity, and reliability of the data. It has a different language and data model than SQL databases, which implies a paradigm shift.
-
-Docker: A platform for building and running applications in isolated containers, but with drawbacks and risks. It can increase the complexity and cost of deploying and handling your applications as you need additional tools and configurations. 
-
-The wikidata api, since it is the first time we use it and we will have to learn how to use it to create questions and also learn how to generate templates for those questions
-
-Communication and group work can be complicated at times, so you should always try to maintain a good working atmosphere with the whole team
-
-[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.) 
-
-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.
-
-****
+[options="header"] 
+|===
+| Priority | Description of Risk/Technical Debt | Suggested Measures 
+| High     | Vulnerabilities in user authentication | Implement additional security measures, such as password encryption 
+| High     | Potential application malfunctions | Implement unit tests for key components and critical functions, along with extensive testing with real users 
+| Medium   | Slow performance of database queries | Optimize database queries, avoid unnecessary queries 
+| Low      | Unoptimized styles | Optimize CSS styles to improve application performance and loading times 
+| Low      | Insufficient documentation | Provide comprehensive documentation of architecture, code structure, development processes, and deployment to facilitate team maintenance and collaboration 
+|===

stats/model/partidas.json

@@ -0,0 +1,38 @@
+[
+    {
+        "username": "vagrant",
+        "points": 200,
+        "correctQuestions": 7,
+        "incorrectQuestions": 3
+    },
+    {
+        "username": "vagrant",
+        "points": 400,
+        "correctQuestions": 16,
+        "incorrectQuestions": 4
+    },
+    {
+        "username": "jose123",
+        "points": 200,
+        "correctQuestions": 8,
+        "incorrectQuestions": 2
+    },
+    {
+        "username": "vagrant",
+        "points": 1000,
+        "correctQuestions": 40,
+        "incorrectQuestions": 10
+    },
+    {
+        "username": "rober200",
+        "points": 100,
+        "correctQuestions": 3,
+        "incorrectQuestions": 2
+    },
+    {
+        "username": "jose123",
+        "points": 40,
+        "correctQuestions": 1,
+        "incorrectQuestions": 1
+    }
+]

stats/model/stats-getter.js

@@ -0,0 +1,52 @@
+const fs = require('fs');
+
+class StatsForUser {
+
+    getStatsForUser(username){
+        // Leer el archivo JSON de partidas
+        const data = fs.readFileSync("./model/partidas.json");
+        const partidas = JSON.parse(data);
+
+        let nGamesPlayed = 0;
+        let totalPoints = 0;
+        let totalCorrectQuestions = 0;
+        let totalIncorrectQuestions = 0;
+
+        // Calcular las estadísticas para el usuario
+        for (const partida of partidas){
+            if (partida.username === this.username){
+                nGamesPlayed++;
+                totalPoints += partida.points;
+                totalCorrectQuestions += partida.correctQuestions;
+                totalIncorrectQuestions += partida.incorrectQuestions;
+            }
+        }
+
+        // Calcular el promedio de puntos por juego
+        const avgPoints = nGamesPlayed > 0 ? totalPoints / nGamesPlayed : 0;
+
+        // Calcular el ratio de preguntas acertadas/falladas
+        const ratioCorrectToIncorrect = totalIncorrectQuestions !== 0 ? totalCorrectQuestions / totalIncorrectQuestions : totalCorrectQuestions;
+
+        // Construir el objeto JSON con las estadísticas
+        const statsJSON = {
+            username: this.username,
+            nGamesPlayed: nGamesPlayed,
+            avgPoints: avgPoints,
+            totalPoints: totalPoints,
+            totalCorrectQuestions: totalCorrectQuestions,
+            totalIncorrectQuestions: totalIncorrectQuestions,
+            ratioCorrectToIncorrect: ratioCorrectToIncorrect
+        };
+
+        return statsJSON;
+    }
+
+    existsUser(username){
+        //TODO
+        return true;
+    }
+}
+
+module.exports = StatsForUser;
+