Merge pull request #118 from Arquisoft/develop

Cambios de mis compañeros

docs/src/06_runtime_view.adoc

@@ -30,12 +30,21 @@ image::06-loginSecuencia.png["Login secuence diagram image"]
 6. Finally the app inform the user about his login process
 
 
-=== Request a question
+=== Generate a question
 
-image::06-generateQuestion.png["NextQuestion secuence diagram image"] 
+image::06-generateQuestion.png["GenerateQuestion secuence diagram image"] 
 
 1. The QuestionService wants to generate a question
 2. It requests all the necesary info to build a question to WikiData
 3. WikiData responds with the requested data
 4. The QuestionService builds the question with the data recieved
-5. Finally the QuestionService writes the new question in the QuestionsDB
+5. Finally the QuestionService writes the new question in the QuestionsDB
+
+=== Request a question
+
+image::06-requestQuestion.png["RequestQuestion secuence diagram image"] 
+
+1. The App needs a new question to show to the user so uses Rest to comunicate with the QuestionService
+2. The QuestionService requests that random question to our MongoDB of questions
+3. The DB sends that question to the QuestionService
+4. The QuestionService send again that question to the app so the user can continue with his experience

docs/src/07_deployment_view.adoc

@@ -11,6 +11,6 @@ image::07-diagramaDespliegue.png["Building Block general diagram"]
 Basically when a user wants to use the application, using his web browser
 he can connect to the application server that is a VM in hosted in Azure
 orientated to microservices. That means that all the modules inside it
-are dockerized in a container. The QuestionGenerator interacts with WikiData
-throught their API and we have also two MongoDB databases one for users
-and another to store questions.
+are dockerized in a container alse we can find 2 MongoDB databases in this 
+virtual machine one for users and another to store generated questions.
+The QuestionGenerator interacts with WikiData throught their API.

docs/src/11_technical_risks.adoc

@@ -6,9 +6,11 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 === Risks
 
+==== Internal Risks
+Risks that we can have under control and it´s our responsability to fight against them:
 [options="header" frame=all]
 |===
-|Risk |More detail |How to fight it  
+|Internal |More detail |How to fight it  
 
 |A member fire out the project
 |It's possible that due to reasons like having a lot of pressure or being overwhelmed by the project members of the group quit the project or the subject
@@ -30,9 +32,22 @@ ifndef::imagesdir[:imagesdir: ../images]
 |It can happen that we don't archieve what it's requested into the project in time and end up sending an uncompleted final product or during the middle deadlines 
 |To avoid this we have to keep a good rhythm advancing and planing good and adequated tasks in the weekly meetings done in the labs so we don't run out of time not done
 
+|===
+
+==== External Risks
+Risks that we can try to prevent but at the end doesn't depend on us:
+[options="header" frame=all]
+|===
+|External risk |More detail |How to fight it  
+
 |Depending on extern technologies
 |It's possible that due to depend on external libraries such as react or external services like Azure we can find ourselves with the poject not working derivated from failures on that external technologies
 |Try to investigate and use reliable services and libraries that are not likely to end up deprecated or with bugs and failures on their releases
+
+|Accidents in the presentation day 
+|Accidents can happen and if something like a train or bus not working or some unexpected problem that we can experience the presentation day (2nd May) it´s possible that someone can be absent in that final presentation
+|To avoid this we should try to be cautious and arrive with a big margin time and having alternatives
+
 |===
 
 === Technical Debt