diff --git a/images/Sequence diagram.png b/images/Sequence diagram.png index c26816ec..c5e1de84 100644 Binary files a/images/Sequence diagram.png and b/images/Sequence diagram.png differ diff --git a/images/businesscontext.png b/images/businesscontext.png deleted file mode 100644 index 1609bb98..00000000 Binary files a/images/businesscontext.png and /dev/null differ diff --git a/images/technicalcontext.png b/images/technicalcontext.png deleted file mode 100644 index 3f41aa63..00000000 Binary files a/images/technicalcontext.png and /dev/null differ diff --git a/index.html b/index.html index 53021196..afecf8cb 100644 --- a/index.html +++ b/index.html @@ -444,67 +444,7 @@

arc42 T
Table of Contents
@@ -561,8 +501,20 @@

arc42 T

1. Introduction and Goals

-

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:

+

<<<<<<< HEAD

+
+
+
+
+

Describes the relevant requirements and the driving forces that software architects and development team must consider. +These include

+
+
+
+
+

WIQ! es un proyecto desarrollado para la asignatura "Arquitectura de Software" del grado de Ingeniería Informática de la Escuela de Ingeniería Informática de la Universidad de Oviedo. Este proyecto toma como base el proyecto wiq, puesto a la disposición de los alumnos por los profesores de la asignatura. +WIQ! ha sido encargado a la empresa HappySw por RTVE, con el objetivo de recrear su famoso concurso Saber y ganar en una versión web accesible para todo el mundo. Este proyecto será realizado por el equipo de desarrollo es1a formado por: +>>>>>>> 3eb24632ad8f32234457b6498042b6f03b9cfc5e

    @@ -581,55 +533,56 @@

    1. Introduction and Goals

-

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:

+

WIQ! es un software mediante el cual los usuarios pueden emular ser los participantes del concurso Saber y ganar, que cuenta con numerosas funcionalidades:

  • -

    Play several of the game modes seen on the show.

    +

    Jugar a varios de los modos de juego vistos en el programa

  • -

    Register to be able to keep track of their statistics in the game

    +

    Registrarse para poder llevar registro de sus estadísticas en el juego

  • -

    Play with friends

    +

    Jugar con amigos

  • -

    Adjust the themes of the questions, the answer time, the number of questions…​ +

    Ajustar las temáticas de las preguntas, el tiempo de respuesta, el número de preguntas…​ *

-
-

1.1. Requirements Overview

+
+

=== Requirements Overview

+
  • -

    The system will have at least one web frontend that will be deployed and accessed via the web.

    +

    El sistema contará al menos con un frontend web que estará desplegado y el acceso será a través de la 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.

    +

    Los usuarios podrán registrarse en el sistema y consultar el histórico de su participación en el sistema: número de juegos, preguntas acertadas/falladas, tiempos, etc.

  • -

    Questions will be automatically generated from Wikidata data.

    +

    Las preguntas serán generadas automáticamente a partir de los datos de Wikidata.

  • -

    Questions must be answered within a given time limit.

    +

    Las preguntas deberán responderse en un plazo de tiempo determinado.

  • -

    Each question will have one correct answer and several incorrect or distracting answers. Both correct and incorrect answers will be generated automatically.

    +

    Cada pregunta tendrá una respuesta correcta y varias respuestas incorrectas o distractoras. Tanto la respuesta correcta como las incorrectas se generarán automáticamente.

  • -

    The system shall allow access to user information through an API.

    +

    El sistema permitirá acceder a la información de los usuarios a través de un API.

  • -

    The system shall allow access to the information of the generated questions through an API.

    +

    El sistema permitirá acceder a la información de las preguntas generadas a través de un API.

+
+

=== Quality Goals

-
-

1.2. Quality Goals

@@ -646,143 +599,192 @@

1.2. Quality Goals

- - + + - - + + - - + +

1

Usability

The application should be intuitive for users, making it easy for them to interact with the application regardless of their skills.

Usabilidad

La aplicación debe ser intuitiva para los usuarios, facilitándoles la interacción con la misma independientemente de sus habilidades.

2

Mantainability

The application must have a well-defined and structured design, so that it is easy to make modifications and/or extensions.

Mantenibilidad

La aplicación debe contar con un diseño bien definido y estructurado, de tal forma que sea sencillo realizar modificaciones y/o ampliaciones.

3

Privacy

The application must guarantee the privacy of its users' information, with mechanisms in place to prevent intrusions into the system.

Privacidad

La aplicación debe garantizar la privacidad de la información de sus usuarios, contando con mecanismos para evitar intrusiones en el sistema.
+
+

=== Stakeholders

-
-

1.3. Stakeholders

---+ - - - + - - - + - - - + - - - + - - - + - -
Role/NameContactExpectations<<<<<<< HEAD

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.

Role/Name

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.

Contact

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.

Expectations

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.

Alfredo Jirout Cid
-
-
-
-
-
-

2. Architecture Constraints

-
- ---- - - - + + + + - - - - + - - + - - + - - + - - + - - + - - + - - + + + +
Architecture constraintDescription

UO288443@uniovi.es

Aprobar (opcional)

Tecnología de Desarrollo

The application must be developed using web technologies compatible with RTVE’s requirements and standards.

Rodrigo Gracía Iglesias

Plataforma de Implementación

The application must be implemented on a web hosting platform that meets RTVE’s performance, security and scalability requirements.

UO276396@uniovi.es

Cumplimiento de Normativas de Privacidad

The architecture must ensure compliance with data privacy regulations, such as GDPR, to protect users' information.

No tomar de ejemplo a Miguel

Compatibilidad con Navegadores

The application should be compatible with a wide range of popular web browsers to ensure a consistent user experience.

Iyán Fernández Riol

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.

UO288231@uniovi.es

Escalabilidad

The architecture must be scalable to handle increased user traffic without compromising performance.

Sacar matricula

Mantenibilidad del Código

Software development practices that promote clean and well-documented code should be followed to facilitate future upgrades and maintenance.

Martín Cancio Barrera

Tiempo de Desarrollo

The application must be developed within a specific time frame, which may influence architectural decisions and technology selection.

UO287561@uniovi.es

Ser feliz
-
-
-

3. System Scope and Context

-
-
-

3.1. Business Context

-
-
-Business context +
+

|Role/Name|Contact|Expectations

+
+

| Estudiantes (HappySw) +| Martín Cancio Barrera, Iyán Fernández Riol, Rodrigo García Iglesias y Alfredo Jirout Cid +| Los estudiantes son los desarrolladores de la aplicación. Están a cargo del desarrollo completo, lo que mejorará sus habilidades tanto de programación como de trabajo en grupo.

+
+

| Usuarios +| Cualquier persona que utilice la aplicación +| Los usuarios son los que en última instancia van a utilizar la aplicación, por lo que debe ser intuitiva y fácil de entender.

-
-

3.2. Technical Context

-
-
-Technical Context +
+

| Profesores +| José Emilio Labra Gayo, Pablo González González, Jorge Álvarez Fidalgo y Cristian Augusto Alonso +| Son los supervisores del proyecto, y ayudarán a los estudiantes para asegurarse de que el proyecto llegue a buen puerto.

+
+

| RTVE +| RTVE +| Son los principales interesados en la aplicación, puesto que son los que la han encargado, para que sus espectadores puedan utilizarla. +>>>>>>> 3eb24632ad8f32234457b6498042b6f03b9cfc5e

-
+ +++ + + + + + +

<<<<

+

+== Architecture Constraints

+
+

| Restricción de Arquitectura | Descripción

+
+

| Tecnología de Desarrollo | La aplicación debe desarrollarse utilizando tecnologías web compatibles con los requisitos y estándares de RTVE.

+
+
+

| Plataforma de Implementación | La aplicación debe ser implementada en una plataforma de alojamiento web que cumpla con los requisitos de rendimiento, seguridad y escalabilidad de RTVE.

+
+
+

| Cumplimiento de Normativas de Privacidad | La arquitectura debe garantizar el cumplimiento de las regulaciones de privacidad de datos, como GDPR, para proteger la información de los usuarios.

+
+
+

| Compatibilidad con Navegadores | La aplicación debe ser compatible con una amplia gama de navegadores web populares para garantizar una experiencia de usuario consistente.

+
+
+

| Seguridad de la Información | Se deben implementar medidas de seguridad sólidas, como autenticación de usuarios, control de acceso y encriptación de datos, para proteger la información confidencial de los usuarios.

+
+
+

| Escalabilidad | La arquitectura debe ser escalable para manejar un aumento en el tráfico de usuarios sin comprometer el rendimiento.

+
+
+

| Mantenibilidad del Código | Se deben seguir prácticas de desarrollo de software que promuevan un código limpio y bien documentado para facilitar futuras actualizaciones y mantenimiento.

+
+
+

| Tiempo de Desarrollo | La aplicación debe desarrollarse dentro de un marco de tiempo específico, lo que puede influir en las decisiones arquitectónicas y en la selección de tecnologías.

+
+ +++ + + + + + +

<<<<

+

+== System Scope and Context

+

=== Business Context

+

[plantuml, "businesscontext", png] +---- +Actor user as "User"

+

component wiq [system] as "WIQ!" +component apiusers [extern] as "API Users" +component apiquestions [extern] as "API Questions" +component wikidata [extern] as "Wikidata" +component authentication [extern] as "Authentication"

+

user -down.> wiq

+

wiq -left.> apiusers +wiq -.> apiquestions +wiq -right.> wikidata +wiq -.> authentication +----

+

=== Technical Context

+

[plantuml, "technicalcontext", png] +---- +Actor user as "User" +Actor admin as "Admin"

+

node cloud as "Cloud"{ + component wiq as "WIQ! Webapp" +}

+

component wikidata as "Wikidata"

+

user -down→ cloud: HTTP/HTTPS +admin -down→ cloud: SSH +wikidata -right- cloud: REST +----

+

<<<<

+

+== Solution Strategy

+

[role="arc42help"]

-
-

4. Solution Strategy

-
-
-
Contents

A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes

@@ -820,16 +822,14 @@

4. Solution Strategy

Further Information

See Solution Strategy in the arc42 documentation.

-
-
+
+
+
+

== Building Block View

+
-
-

5. Building Block View

-
-
-
Content

The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, …​) as well as their dependencies (relationships, associations, …​)

@@ -871,12 +871,13 @@

5. Building Block View

Further Information

See Building Block View in the arc42 documentation.

+
+
+
+

=== Whitebox Overall System

+
-
-

5.1. Whitebox Overall System

-
-

Here you describe the decomposition of the overall system using the following white box template. It contains

@@ -911,8 +912,8 @@

5.1. Whitebox Overall System

-
-
+
+

<Overview Diagram>

@@ -932,8 +933,8 @@

5.1. Whitebox Overall System

-
-
+
+

Insert your explanations of black boxes from level 1:

@@ -967,12 +968,13 @@

5.1. Whitebox Overall System

If you use a list of black box descriptions then you fill in a separate black box template for every important building block . Its headline is the name of the black box.

+
+
+
+

==== <Name black box 1>

+
-
-

5.1.1. <Name black box 1>

-
-

Here you describe <black box 1> according the the following black box template:

@@ -999,8 +1001,8 @@

5.1.1. <Name black box 1>

-
-
+
+

<Purpose/Responsibility>

@@ -1019,34 +1021,32 @@

5.1.1. <Name black box 1>

<(optional) Open Issues/Problems/Risks>

+
+

==== <Name black box 2>

-
-

5.1.2. <Name black box 2>

<black box template>

+
+

==== <Name black box n>

-
-

5.1.3. <Name black box n>

<black box template>

+
+

==== <Name interface 1>

-
-

5.1.4. <Name interface 1>

…​

+
+

==== <Name interface m>

+
+
+

=== Level 2

-
-

5.1.5. <Name interface m>

-
-
-

5.2. Level 2

-
-

Here you can specify the inner structure of (some) building blocks from level 1 as white boxes.

@@ -1055,41 +1055,41 @@

5.2. Level 2

Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. Leave out normal, simple, boring or standardized parts of your system

-
-
-
-

5.2.1. White Box <building block 1>

-
+
-

…​describes the internal structure of building block 1.

+

==== White Box <building block 1>

+

…​describes the internal structure of building block 1.

+
+
+
+

<white box template>

+
+

==== White Box <building block 2>

-
-

5.2.2. White Box <building block 2>

<white box template>

…​

+
+

==== White Box <building block m>

-
-

5.2.3. White Box <building block m>

<white box template>

+
+

=== Level 3

+
-
-

5.3. Level 3

-
-

Here you can specify the inner structure of (some) building blocks from level 2 as white boxes.

@@ -1097,42 +1097,39 @@

5.3. Level 3

When you need more detailed levels of your architecture please copy this part of arc42 for additional levels.

-
-
-
-

5.3.1. White Box <_building block x.1_>

-
+
-

Specifies the internal structure of building block x.1.

+

==== White Box <_building block x.1_>

+
+
+

Specifies the internal structure of building block x.1.

+
+

<white box template>

+
+

==== White Box <_building block x.2_>

-
-

5.3.2. White Box <_building block x.2_>

<white box template>

+
+

==== White Box <_building block y.1_>

-
-

5.3.3. White Box <_building block y.1_>

<white box template>

+
+

== Runtime View

-
-
-

6. Runtime View

-
-
-
Contents

The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:

@@ -1191,10 +1188,11 @@

6. Runtime View

Further Information

See Runtime View in the arc42 documentation.

+
+
+
+

=== <Runtime Scenario 1>

-
-
-

6.1. <Runtime Scenario 1>

  • @@ -1214,26 +1212,21 @@

    6.1. <Runtime Scenario 1>

    Sequence diagram
+
+

=== <Runtime Scenario 2>

-
-

6.2. <Runtime Scenario 2>

- +
+

=== …​

-
-

6.3. …​

- +
+

=== <Runtime Scenario n>

-
-

6.4. <Runtime Scenario n>

+
+

== Deployment View

-
-

7. Deployment View

-
-
-
Content

The deployment view describes:

@@ -1284,12 +1277,13 @@

7. Deployment View

Further Information

See Deployment View in the arc42 documentation.

+
+
+
+

=== Infrastructure Level 1

+
-
-

7.1. Infrastructure Level 1

-
-

Describe (usually in a combination of diagrams, tables, and text):

@@ -1312,8 +1306,8 @@

7.1. Infrastructure Level 1

For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments.

-
-
+
+

<Overview Diagram>

@@ -1333,49 +1327,46 @@

7.1. Infrastructure Level 1

+
+

=== Infrastructure Level 2

+
+
-
-

7.2. Infrastructure Level 2

-
-

Here you can include the internal structure of (some) infrastructure elements from level 1.

Please copy the structure from level 1 for each selected element.

+
+
+
+

==== <Infrastructure Element 1>

-
-
-

7.2.1. <Infrastructure Element 1>

<diagram + explanation>

+
+

==== <Infrastructure Element 2>

-
-

7.2.2. <Infrastructure Element 2>

<diagram + explanation>

…​

+
+

==== <Infrastructure Element n>

-
-

7.2.3. <Infrastructure Element n>

<diagram + explanation>

+
+

== Cross-cutting Concepts

-
-
-

8. Cross-cutting Concepts

-
-
-
Content

This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system. @@ -1471,37 +1462,61 @@

8. Cross-cutting Concepts

Further Information

See Concepts in the arc42 documentation.

+
+
+
+

=== <Concept 1>

-
-
-

8.1. <Concept 1>

<explanation>

+
+

=== <Concept 2>

-
-

8.2. <Concept 2>

<explanation>

…​

+
+

=== <Concept n>

-
-

8.3. <Concept n>

<explanation>

+
+

== Architecture Decisions +JavaScript: + We will use the JavaScript language to create both the front-end and the backend of the application, is the default technology of the initial project.

+
+
+

ReactJS: + The base project they have given us uses ReactJS for the front-end of the application, although it is a framework with which we are not familiar. + We think that is a good oportunity to start using this framework.

+
+
+

NodeJS: + We use NodeJS for the back-end of the application, this is the default technology of the initial project and all the group thought it was a good idea + to use it.

+
+
+

MongoDB + The base project they have given us uses MongoDB for the back-end of the application, a DBMS with which we are not familiar, but it seemed like a + good idea to learn this GBD system.

+
+
+

Docker: + We will use Docker to package the application modules in containers, it is the initial technology of the project

+
+
+

MySQL: + The base project that they have given us uses MongoDB for the back-end of the application, a DBMS with which we are not familiar, however MySQL is another +database management system that we have used in other subjects. We decided to discard this option to learn how to use MongoDB

-
-

9. Architecture Decisions

-
-
-
Contents

Important, expensive, large scale or risky architecture decisions including rationales. @@ -1542,16 +1557,14 @@

9. Architecture Decisions

See Architecture Decisions in the arc42 documentation. There you will find links and examples about ADR.

-
-
+
+
+
+

== Quality Requirements

+
-
-

10. Quality Requirements

-
-
-
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)

@@ -1570,35 +1583,13 @@

10. Quality Requirements

Further Information

See Quality Requirements in the arc42 documentation.

-
-
-
-
-

Quality Requirements

+
+
-

In our project, we have some quality goals or expectations that we want to be met. -These are:

+

=== Quality Tree

+
-
-
    -
  • -

    Performance: ability of the software system to respond well to user interactions and perform tasks efficiently.

    -
    • -
  • -

    Security: protection of the system from unauthorized access, data breaches, and malicious activities, ensuring safety of sensitive information.

    -
    • -
  • -

    Usability: intuitiveness of the software interface, making it easy for users to interact with the system.

    -
    • -
  • -

    Maintainability: how easily the software system can be modified, updated, and extended without significant effort or risk.

    -
    • -
-
-

.1. Quality Tree

-
-
Content

The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.

@@ -1624,57 +1615,13 @@

.1. Quality Tree

In any case the tree should include links to the scenarios of the following section.

+
+
+
+

=== Quality Scenarios

-

Quality Tree

-
-
    -
  • -

    Quality

    -
    • -
  • -

    Performance

    -
    • -
  • -

    Response time

    -
    • -
  • -

    Throughput

    -
    • -
  • -

    Security

    -
    • -
  • -

    Data encryption

    -
    • -
  • -

    Access control

    -
    • -
  • -

    Usability

    -
    • -
  • -

    Intuitive interface

    -
    • -
  • -

    User guidance

    -
    • -
  • -

    Maintainability

    -
    • -
  • -

    Code readability

    -
    • -
  • -

    Documentation

    -
    • -
-
-
-

.1. Quality Scenarios

-
-
Contents

Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

@@ -1709,211 +1656,106 @@

.1. Quality Scenarios

Form

Tabular or free form text.

+
+
+
+
+

== Risks and Technical Debts

-

Quality Scenarios

-
-

1. Usage Scenarios

-
- --------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AspectSourceStimulusArtefactEnvironmentResponseResponse Measurement

Performance

User

While playing, a user selects a response to a question.

User Interface

Normal gameplay conditions.

The system updates its interface very fast and the user knows if they responded correctly, so they can keep playing.

Interface update time is less than 0.5 seconds.

Security

User

A new user registers in the game by providing their username and password.

Encrypting system

User registration process.

The server encrypts the user’s password before storing it in the MongoDB database, so it is safe from data leaks.

Passwords are encrypted using a strong hashing algorithm.

Usability

User

A new user starts playing the game.

User Interface

Initial game setup.

The user interface displays available options and provides clear instructions on how to play, including a 'Help' button.

User can navigate through the interface without guidance.

Performance

User

A user finishes playing a game and wants to start a new one.

System and User Interface

Post-game completion.

The system ends the current game, displays the user’s score, resets all game elements, and offers the option to start a new game.

Score is saved accurately, and game restarts without errors.

+
+
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.)

-
-

2. Change Scenarios

-
+
+

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 Risks and Technical Debt in the arc42 documentation.

+
+
+
+
+
+

== Glossary

+
+
+
+
+
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 Glossary in the arc42 documentation.

+
+
+
-------++ - - - - - - - + + - - - - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - + +
AspectSourceStimulusArtefactEnvironmentResponseResponse MeasurementTermDefinition

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

<Term-1>

<definition-1>

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

-

<<<<

-

-== Risks and Technical Debts

-

[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 Risks and Technical Debt in the arc42 documentation.

-

*

-

# Technical Risks / Debts

-

[options="header"]

<Term-2>

<definition-2>
-
-

| 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

- --- - - - - - -

<<<<

-

-== 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 Glossary in the arc42 documentation.

-

*

-

[cols="e,2e" options="header"]

-
-

|Term |Definition

-
-

|<Term-1> -|<definition-1>

-
-
-

|<Term-2> -|<definition-2>

-
- -