Adición apartados 10 y 11 de la documentación.

docs/src/10_quality_requirements.adoc

@@ -1,73 +1,43 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
-[[section-quality-scenarios]]
+[[section-quality-requirements]]
 == Quality Requirements
 
+A continuación se muestra el árbol de atributos de calidad, cuyas hojas son los escenarios de calidad descritos en la tabla.
 
-[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.
-
-****
 
 === 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:
+image::quality_tree.png["Quality Tree"]
 
-* 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.
+=== Quality Scenarios
 
+.Quality Scenarios
+|===
+|Atributo de Calidad|Descripción
 
-****
+| SC1
+| Para mantener la usabilidad de la aplicación, se buscará mantener un diseño uniforme.
 
-=== Quality Scenarios
+| SC2
+| Para no complicar el aprendizaje de uso, la experiencia del usuario se basará en la predictabilidad.
 
-[role="arc42help"]
-****
-.Contents
-Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.
+| SC3
+| Se realizarán pruebas exhaustivas para asegurar el correcto funcionamiento de todos los servicios presentes en la aplicación.
 
-These scenarios describe what should happen when a stimulus arrives at the system.
+| SC4
+| Para mantener la fiabilidad, se buscará un uso de recursos optimizado.
 
-For architects, two kinds of scenarios are important:
+| SC5
+| Se buscará un rendimiento eficiente y rápido para no afectar la experiencia de usuario.
 
-* 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.
+| SC6
+| En cuanto a la seguridad, se bloqueará el acceso a cuentas ajenas.
 
-.Motivation
-Scenarios make quality requirements concrete and allow to
-more easily measure or decide whether they are fulfilled.
+| SC7
+| Se mantendrán los datos de usuario privados y seguros.
 
-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.
-****
+.Nota del editor:
+A medida que se desarrolla el proyecto, se actualizará esta sección con escenarios de calidad más específicos.

docs/src/11_risks_and_technical_debts.adoc

@@ -0,0 +1,41 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-technical-risks]]
+== Risks and Technical Debts
+
+A continuación, se presentan en formato tabla los riesgos y posibles deudas técnicas consideredas por el equipo de desarrollo.
+
+.Development Team Risks
+|===
+|Riesgo|Descripción|Medida Preventiva
+
+| Faltas de comunicación entre los miembros del equipo.
+| Las faltas de comunicación podrán causar conflictos en la aplicación desarrollada, que supone una deuda técnica.
+| Se hará uso de varias vías de comunicación para evitar faltas y despejar dudas. Ejemplos de estos son Discord y WhatsApp.
+
+| Posible abandono de algún miembro del equipo.
+| El abandono debido a la carga de trabajo incurrirá una deuda técnica que deberá compensar el resto de miembros del equipo.
+| Se repartirán las tareas en grupos de trabajo de 2 o más miembros para minimizar el impacto que supondría un abandono.
+
+| Inexperiencia con las tecnologías empleadas.
+| Debido a la posible inexperiencia con las tecnologías empleadas en el proyecto, se pueden producir deudas técnicas.
+| Para minimizar el impacto, se recomienda investigar y probar las tecnologías para alcanzar un grado de control mínimo sobre ellas.
+
+|===
+
+.Software Risks
+|===
+|Riesgo|Descripción|Medida Preventiva
+
+| Conflictos en el repositorio GitHub.
+| El acceso múltiple y simultáneo al repositorio desde varios usuarios supone un riesgo de sobreescritura y conflictos de código.
+| Se hará uso de ramas de trabajo para realizar las tareas, además de las vías de comunicación  para coordinar las modificaciones al repositorio.
+
+| Conflictos con los programas desarrollados.
+| El trabajo en paralelo sobre los módulos de la aplicación supone un riesgo de conflicto si no hay estándares para código común a dichos módulos.
+| Se planteará una plantilla de código o nomenclatura de clases, métodos, etc común para aquellos módulos que tengan puntos en común.
+
+|===
+
+.Nota del editor:
+A medida que se desarrolla el proyecto, se actualizará esta sección con los riesgos o deudas técnicas consideradas para los ámbitos de la aplicación.