diff --git a/images/05-BussinesLogic-Level2.png b/images/05-BussinesLogic-Level2.png new file mode 100644 index 00000000..e6defb4a Binary files /dev/null and b/images/05-BussinesLogic-Level2.png differ diff --git a/images/05-Database-Level2.png b/images/05-Database-Level2.png new file mode 100644 index 00000000..51cc686b Binary files /dev/null and b/images/05-Database-Level2.png differ diff --git a/images/05-Level1.png b/images/05-Level1.png new file mode 100644 index 00000000..85a992da Binary files /dev/null and b/images/05-Level1.png differ diff --git a/images/05-ScopeAndContext.png b/images/05-ScopeAndContext.png new file mode 100644 index 00000000..0a63bda7 Binary files /dev/null and b/images/05-ScopeAndContext.png differ diff --git a/images/05-UserInterface-Level2.png b/images/05-UserInterface-Level2.png new file mode 100644 index 00000000..e8bb6923 Binary files /dev/null and b/images/05-UserInterface-Level2.png differ diff --git a/images/QualityTree.PNG b/images/QualityTree.PNG new file mode 100644 index 00000000..8725a813 Binary files /dev/null and b/images/QualityTree.PNG differ diff --git a/images/Sequence diagram.png b/images/Sequence diagram.png deleted file mode 100644 index 3f560336..00000000 Binary files a/images/Sequence diagram.png and /dev/null differ diff --git a/images/diagramaDespliegue.PNG b/images/diagramaDespliegue.PNG new file mode 100644 index 00000000..9bb7a0bf Binary files /dev/null and b/images/diagramaDespliegue.PNG differ diff --git a/images/loginSecuencia.png b/images/loginSecuencia.png new file mode 100644 index 00000000..38478165 Binary files /dev/null and b/images/loginSecuencia.png differ diff --git a/images/nextQuestion.png b/images/nextQuestion.png new file mode 100644 index 00000000..8b4ea2c5 Binary files /dev/null and b/images/nextQuestion.png differ diff --git a/images/registerSecuencia.png b/images/registerSecuencia.png new file mode 100644 index 00000000..b98e49b6 Binary files /dev/null and b/images/registerSecuencia.png differ diff --git a/index.html b/index.html index 56d8c75d..7c84d863 100644 --- a/index.html +++ b/index.html @@ -458,33 +458,38 @@

arc42 T
  • 3.2. Technical Context
    • -
  • 4. Solution Strategy
    • -
  • 5. Building Block View +
  • 4. Solution Strategy
    • -
  • 6. Runtime View +
  • 5. Building Block View (In progress)
    • -
  • 7. Deployment View +
  • 6. Runtime View
    • +
  • 7. Deployment View
  • 8. Cross-cutting Concepts
  • 9. Architecture Decisions
    • @@ -494,7 +499,12 @@

    arc42 T
  • 10.2. Quality Scenarios
    • -
  • 11. Risks and Technical Debts
    • +
  • 11. Risks and Technical Debts + +
  • 12. Glossary
    • @@ -578,6 +588,11 @@

    1. Introduction and Goals (wiq_es05c) +
    +

    WIQ is a Web application requested by RTVE, in order to create an experimental online version of a question and +answer contest similar to “Saber y Ganar”. +The development of said application has been entrusted to our company, HappySw.

    +

    1.1. Requirements Overview

    @@ -607,6 +622,22 @@

    1.1. Requirements Overview

    +
    +

    The main requirements to be met by our application will be:

    +
    +
    + +

    1.2. Quality Goals

    @@ -638,6 +669,36 @@

    1.2. Quality Goals

    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + +
    GoalsDescription

    Usability

    The user must be able to use the system in a simple and intuitive way, so that a good experience is provided.

    Accesibility

    The system should provide the necessary help to the user to be able to navigate through the program without any doubt.

    Privacy

    The system must ensure the privacy of users. In addition, they will not see the history of other users.

    Performance

    The application must have good performance, without excessive loading times.

    1.3. Stakeholders

    @@ -680,27 +741,31 @@

    1.3. Stakeholders

    ---++ - - - - + + - - - + + + + + + + + + +
    Role/NameContact Expectations

    <Role-1>

    <Contact-1>

    <Expectation-1>

    HappySw

    Interested in making the application work as well as possible to please users and their contractors.

    <Role-2>

    <Contact-2>

    <Expectation-2>

    Developer Team

    Interested in improving their skills by completing this application.

    RTVE

    Interested in the social and financial success of the application.

    Users

    Interested in the application being entertaining and simple.
    @@ -711,30 +776,97 @@

    1.3. Stakeholders

    2. Architecture Constraints

    -
    -
    -
    -
    Contents
    -

    Any requirement that constraints software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.

    -
    -
    Motivation
    -

    Architects should know exactly where they are free in their design decisions and where they must adhere to constraints. -Constraints must always be dealt with; they may be negotiable, though.

    +

    1.Technical Constraints

    + ++++ + + + + + + + + + + + + + + + + + + + + +
    ConstraintDescription

    Docker

    Software that allows automating the deployment of applications. The application will be running on a Docker host.

    React

    JavaScript library required for building user interfaces for the web.

    MongoDB

    Default choice for non-relational database selected for the task.

    -
    Form
    -

    Simple tables of constraints with explanations. -If needed you can subdivide them into -technical constraints, organizational and political constraints and -conventions (e.g. programming or versioning guidelines, documentation or naming conventions)

    +

    2.Organizational Constraints

    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + +
    ConstraintDescription

    Team

    A team formed by 5 individuals who will need to learn to work and coordinate together.

    Time

    We need to learn how to manage time effectively as we must optimize the time between meetings, in-class work, and homework. The lack of experience and the learning curve associated with new technologies can lead to issues.

    New Technologies

    The majority of technologies are new to us, and we need to learn how to work with them.

    Communication Difficulties

    The lack of familiarity within the team can lead to misunderstandings or a lack of communication and coordination.

    -
    Further Information
    -

    See Architecture Constraints in the arc42 documentation.

    -
    -
    +

    3.Convention Constraints

    + ++++ + + + + + + + + + + + + + + + + + + + + +
    ConstraintDescription

    Documentation

    Arc42 is a template for architecture documentation. It is the one we should use to generate the documentation.

    Code

    The code should follow an order that does not pose any problem when understanding it for another team member.

    Structure

    The project must follow a fixed structure, both the documentation and the code must be done under the same standards.

    @@ -799,10 +931,24 @@

    3.1. Business Context

    -

    <Diagram or Table>

    +

    In our business setting, we have developed a web application called WIQ, where users engage in a question-based game. +This application draws inspiration from the renowned Spanish television program "Saber y Ganar," providing users with an interactive and entertaining experience.

    -
    -

    <optionally: Explanation of external domain interfaces>

    +
    +
    @@ -824,15 +970,41 @@

    3.2. Technical Context

    -
    -

    <Diagram or Table>

    -
    -
    -

    <optionally: Explanation of technical interfaces>

    -
    -
    -

    <Mapping Input/Output to Channels>

    -
    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TechnologiesDescription

    JavaScript

    A fundamental programming language for web development. It’s used to create logic and interactivity in web and mobile applications.

    React

    A JavaScript framework used to build interactive and dynamic user interfaces. It’s especially popular for developing single-page applications (SPAs).

    MongoDB

    A NoSQL database that uses JSON documents to store data. It’s widely used in web and mobile applications, especially those requiring flexible and fast scalability.

    NodeJS

    JavaScript runtime environment

    Docker

    A container platform that simplifies the deployment and management of applications. It allows packaging an application and all its dependencies into lightweight, +portable containers, making it easy to deploy across different development and production environments.

    @@ -840,52 +1012,40 @@

    3.2. Technical Context

    4. Solution Strategy

    -
    -
    +
    +

    4.1. Technology Decisions

    -
    Contents
    -

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

    -
    -
    -
      -
    • -

      technology decisions

      -
      • -
    • -

      decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern

      -
      • -
    • -

      decisions on how to achieve key quality goals

      -
      • -
    • -

      relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.

      -
      • -
    +

    The following technologies are used in the development of our application: +* React: JavaScript library for building efficient user interfaces. +* JavaScript: Chosen language for application development. +* GitHub: Platform that allows us to have a repository where to develop the project and perform different actions such as creating issues or tasks. +* MongoDB: Non-relational database we will use for the project. +* Docker: Virtualization platform where we will deploy the project. +* Wikidata: Wikidata is a knowledge base that provides data sources, used to obtain information for the game. In this case, it is mandatory.

    -
    -
    Motivation
    -

    These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.

    -
    -
    Form
    -

    Keep the explanations of such key decisions short.

    +
    +

    4.2. Top-level Decomposition

    +
    -
    -

    Motivate what was decided and why it was decided that way, -based upon problem statement, quality goals and key constraints. -Refer to details in the following sections.

    +
    +

    4.3. Key quality goals

    +
    +
    +

    4.4. Organizational decisions

    -
    Further Information
    -

    See Solution Strategy in the arc42 documentation.

    -
    -
    +

    Here are the organization decisions made: +* Language: We will use English as the primary language for both documentation and code. +* GitHub issues: We will use GitHub issues as the main source for problem resolution, so that whenever something poses an obstacle, it will be documented in GitHub issues. +* GitHub projects: GitHub projects allow us to organize work based on issues in a Kanban-style, enabling us to see issues that are in progress, those that are not, and those that are completed.

    +
    -

    5. Building Block View

    +

    5. Building Block View (In progress)

    @@ -932,8 +1092,18 @@

    5. Building Block View

    +
    +
    +Scope and Context +
    +
    -

    5.1. Whitebox Overall System

    +

    5.1. Whitebox WIQ

    +
    +
    +Level 1 +
    +
    @@ -979,12 +1149,32 @@

    5.1. Whitebox Overall System

    Motivation
    -

    <text explanation>

    +

    The motivation for undertaking this decomposition is to gain a clear vision of the system developed for the WIQ application. +By breaking down the system into its constituent building blocks, we aim to establish a comprehensive understanding of its structure and functionality.

    Contained Building Blocks

    <Description of contained building block (black boxes)>

    +
    +
    +
    +

    User Interface (Frontend)

    +
    +
    +

    Business Logic (Backend)

    +
    +
    +

    Database

    +
    +
    +

    API User

    +
    +
    +

    API Questions

    +
    +
    +
    Important Interfaces

    <Description of important interfaces>

    @@ -1014,11 +1204,11 @@

    5.1. Whitebox Overall System

    <black box 1>

    -

     <Text>

    +

    <Text>

    <black box 2>

    -

     <Text>

    +

    <Text>

    @@ -1029,7 +1219,7 @@

    5.1. Whitebox Overall System

    -

    5.1.1. <Name black box 1>

    +

    5.1.1. User Interface

    @@ -1060,8 +1250,13 @@

    5.1.1. <Name black box 1>

    -
    -

    <Purpose/Responsibility>

    +
    +
    +
    Responsibility
    +
    +

    Provides the interface to register, play and check participation history

    +
    +

    <Interface(s)>

    @@ -1080,25 +1275,61 @@

    5.1.1. <Name black box 1>

    -

    5.1.2. <Name black box 2>

    +

    5.1.2. Business Logic

    +
    +
    +
    Responsibility
    +
    +

    Automatically generate questions and corresponding answers from Wikidata data. +Manages the time frame allocated for answering questions.

    +
    +
    +
    -

    <black box template>

    +

    …​

    -

    5.1.3. <Name black box n>

    -
    -

    <black box template>

    +

    5.1.3. Database

    +
    +
    +
    Responsibility
    +
    +

    Stores information about users, games, questions and correct/failed answers.

    +
    +
    +
    +
    +
    +

    5.1.4. API User

    +
    +
    +
    Responsibility
    +
    +

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

    +
    +
    +
    +
    +
    +

    5.1.5. API Questions

    +
    +
    +
    Responsibility
    +
    +

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

    +
    +
    -

    5.1.4. <Name interface 1>

    +

    5.1.6. <Name interface 1>

    …​

    -

    5.1.5. <Name interface m>

    +

    5.1.7. <Name interface m>

    @@ -1117,7 +1348,12 @@

    5.2. Level 2

    -

    5.2.1. White Box <building block 1>

    +

    5.2.1. White Box User Interface

    +
    +
    +Level 2 User Interface +
    +
    @@ -1130,16 +1366,35 @@

    5.2.1. White Box <building block 1&g

    -

    5.2.2. White Box <building block 2>

    -
    -

    <white box template>

    +

    5.2.2. White Box Business Logic

    +
    +
    +Level 2 Business Logic +
    -

    …​

    +

    <white box template>

    -

    5.2.3. White Box <building block m>

    +

    5.2.3. White Box Database

    +
    +
    +Level 2 Database +
    +
    +
    +

    <white box template>

    +
    +
    +
    +

    5.2.4. White Box API User

    +
    +

    <white box template>

    +
    +
    +
    +

    5.2.5. White Box API Questions

    <white box template>

    @@ -1190,246 +1445,130 @@

    5.3.3. White Box <_building block y.1_

    6. Runtime View

    -
    +
    +

    6.1. Register user

    +
    -
    -
    Contents
    -

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

    +Register secuence diagram image
    -
    -
      +
    +
    +
    1. -

      important use cases or features: how do building blocks execute them?

      +

      The user wants to register in the sistem

    2. -

      interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?

      +

      The app redirects the register request to the RegisterService

    3. -

      operation and administration: launch, start-up, stop

      +

      The register service sends to the database the data to get information about it

    4. -

      error and exception scenarios

      +

      A response is sent by the database with information about that user in process of registration

      5. - +
    5. +

      The RegisterService validates if the user is correct with that info recieved

      +
      6. +
    6. +

      If the check was afirmative then the RegisterService registre the user

      +
      7. +
    7. +

      The RegisterService inform with the result the app

      +
      8. +
    8. +

      Finally the app carries that result to the user

      +
      9. +
    -
    -

    Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their architectural relevance. It is not important to describe a large number of scenarios. You should rather document a representative selection.

    -
    -
    Motivation
    -

    You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. -You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).

    +
    +

    6.2. Login

    +
    +
    +Login secuence diagram image
    -
    -
    Form
    -

    There are many notations for describing scenarios, e.g.

    -
    -
      +
      +
      1. -

        numbered list of steps (in natural language)

        +

        The user wants to login his account

      2. -

        activity diagrams or flow charts

        +

        The app redirects the login request to the LoginService

      3. -

        sequence diagrams

        +

        The LoginService request information about that login data recieved

      4. -

        BPMN or EPCs (event process chains)

        +

        A response is sent by the database with the requested data

      5. -

        state machines

        +

        After checking if it’s a valid login the LoginService sends a response to the app

      6. -

        …​

        +

        Finally the app inform the user about his login process

        7. -
    -
    -
    -
    Further Information
    -

    See Runtime View in the arc42 documentation.

    -
    +
    -

    6.1. <Runtime Scenario 1>

    -
    -
      -
    • -

      <insert runtime diagram or textual description of the scenario>

      -
      • -
    • -

      <insert description of the notable aspects of the interactions between the -building block instances depicted in this diagram.>

      -
      • -
    -
    -
    -

    It is possible to use a sequence diagram:

    -
    +

    6.3. Request a question

    -Sequence diagram -
    +NextQuestion secuence diagram image
    -
    -

    6.2. <Runtime Scenario 2>

    - -
    -
    -

    6.3. …​

    - -
    -
    -

    6.4. <Runtime Scenario n>

    -
    -
    -
    -
    -
    -

    7. Deployment View

    -
    -
    -
    -
    -
    Content
    -

    The deployment view describes:

    -
    1. -

      technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and

      +

      The user asks for a new question

    2. -

      mapping of (software) building blocks to that infrastructure elements.

      +

      The app redirects that request to the QuestionGenerator

      3. -
    -
    -
    -

    Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.

    -
    -
    -

    Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips.

    -
    -
    -

    From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture.

    -
    -
    -
    Motivation
    -

    Software does not run without hardware. -This underlying infrastructure can and will influence a system and/or some -cross-cutting concepts. Therefore, there is a need to know the infrastructure.

    -
    -
    -
    Form
    -

    Maybe a highest level deployment diagram is already contained in section 3.2. as -technical context with your own infrastructure as ONE black box. In this section one can -zoom into this black box using additional deployment diagrams:

    -
    -
    -
    • -

      UML offers deployment diagrams to express that view. Use it, probably with nested diagrams, -when your infrastructure is more complex.

      +

      The QuestionGenerator generates a heather for the question

    • -

      When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.

      +

      The QuestionGenerator requests the correct answer to WikiData

      • -
    -
    -
    -
    Further Information
    -

    See Deployment View in the arc42 documentation.

    -
    -
    -
    -
    -

    7.1. Infrastructure Level 1

    -
    -
    -
    -

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

    -
    -
    -
    • -

      distribution of a system to multiple locations, environments, computers, processors, .., as well as physical connections between them

      +

      WikiData sends that answer data

    • -

      important justifications or motivations for this deployment structure

      +

      The QuestionGenerator builds the question with the answer and wrong options

    • -

      quality and/or performance features of this infrastructure

      +

      The built question is sent to the app

    • -

      mapping of software artifacts to elements of this infrastructure

      +

      The app shows the question to the User

      • -
    -
    -
    -

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

    -
    -
    +
    -
    -

    <Overview Diagram>

    +
    -
    -
    -
    Motivation
    -
    -

    <explanation in text form>

    -
    -
    Quality and/or Performance Features
    -
    -

    <explanation in text form>

    -
    -
    Mapping of Building Blocks to Infrastructure
    -
    -

    <description of the mapping>

    -
    -
    -
    -

    7.2. Infrastructure Level 2

    -
    +
    +

    7. Deployment View

    +
    +
    -
    -

    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.

    -
    -
    -
    -
    -

    7.2.1. <Infrastructure Element 1>

    -
    -

    <diagram + explanation>

    -
    -
    -
    -

    7.2.2. <Infrastructure Element 2>

    -
    -

    <diagram + explanation>

    -
    -
    -

    …​

    +Building Block general diagram
    -
    -

    7.2.3. <Infrastructure Element n>

    -

    <diagram + explanation>

    +

    Basically when a user wants to use the application, using his web browser +he can connect to the application server where the web app will use some +services also alocated there such as the QuestionGenerator or the LoginManager. +Also these services make use of the WikiData API and database and also of +a database unique for the application to save things as player statistics +or info of them.

    -
    -

    8. Cross-cutting Concepts

    @@ -1533,25 +1672,75 @@

    8. Cross-cutting Concepts

    -

    8.1. <Concept 1>

    +

    8.1. Domain concepts

    -

    <explanation>

    +

    User Model +- ID (Primary Key) +- First Name +- Last Name +- Email +- Password +- Role

    -

    8.2. <Concept 2>

    +

    8.2. User Experience

    -

    <explanation>

    +

    The user interface is the part of our application with which users interact directly. +It’s designed to be intuitive and easy to use, providing a smooth and pleasant experience for users as they navigate through the various functions and features of the application.

    -

    …​

    +

    The user will either register in the application or log in if they have already registered before. +If they have played before, they will be able to view different metrics regarding those games. +Additionally, they can start a new game at any time and, upon completion, view the statistics of their results.

    -

    8.3. <Concept n>

    +

    8.3. Security & Safety

    +
    +
      +
    • +

      Privacy: The data introduced will be private and not visible to other users.

      +
      • +
    • +

      The password will be stored encrypted.

      +
      • +
    +
    +
    +
    +

    8.4. Architecture and design patterns

    -

    <explanation>

    +

    In development…​

    +
    +
    +

    8.5. Under the hood

    +
    +

    In development…​

    +
    +
    +
    +

    8.6. Development concepts

    +
    +
      +
    • +

      Build, Test, Deploy

      +
      • +
    • +

      Code generation

      +
      • +
    • +

      Migration

      +
      • +
    • +

      Configurability

      +
      • +
    +
    +
    +
    +

    8.7. Operation concepts

    @@ -1603,6 +1792,68 @@

    9. Architecture Decisions

    + ++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    DateTitleStateContextDecisionConsequences

    08/02/2024

    Language Selection for documentation

    Accepted

    The project requires documentation to be written

    English, is chosen for its widespread international use

    The project documentation can reach more people, but since it is not our first language, it may not be very well written

    08/02/2024

    Programming Languages

    Accepted

    The proyect requires the develop of a web app

    React and Javascript, JavaScript is selected due to team proficiency

    We need to learn how to use React, and maybe other languages are better suited for this project

    08/02/2024

    Database Platform

    Accepted

    The project requires storing user and question data

    MongoDB is chosen as the default database solution

    Learning MongoDB is necessary

    08/02/2024

    Version Control System

    Accepted

    As a team and scalable project, version control software is needed

    Git-GitHub is chosen as it’s a project constraint.

    The choice of Github is dictated by project constraints

    08/02/2024

    Data Collection Method

    Accepted

    The project requires dynamically generated questions

    WikiData is chosen as it’s a project constraint

    The choice of WikiData is dictated by project constraints

    @@ -1662,6 +1913,11 @@

    10.1. Quality Tree

    +
    +
    +Quality Tree +
    +

    10.2. Quality Scenarios

    @@ -1703,6 +1959,42 @@

    10.2. Quality Scenarios

    + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Quality GoalScenarioDescription

    Usability

    A new user registers on the WIQ platform

    The registration process should be intuitive and straightforward. The user should be able to easily navigate through the registration form and submit the required information without encountering any confusion or errors.

    Accesibility

    A user with vision problems accesses the application

    The platform must have the necessary font size and sufficient contrast with the background so that all the text is completely legible.

    Privacy

    A user views their participation history on the WIQ platform.

    The platform should only display the participation history of the authenticated user and should not allow access to the history of other users. User data should be securely stored and protected from unauthorized access.

    Performance

    Multiple users simultaneously play a game on the WIQ platform.

    The platform should maintain fast response times even under heavy load, ensuring that users can answer questions within the specified time limit without experiencing delays or interruptions.

    @@ -1710,32 +2002,82 @@

    10.2. Quality Scenarios

    11. Risks and Technical Debts

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

    -
    -
    +
    +

    11.1. Risks

    + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    RiskMore detailHow to fight it

    A member quit 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

    Try to communicate with each other and having a sensible rhythm advancing with the project. Also helping each other when we can

    First time delivering a full stack app

    We could have a lack of experience with a project as big as this that have a bit of every field.

    Searching and learning the new things we could need during the project and talking with the other members if we know more of a determined field trying to help them

    Lack of time

    We can have some though weeks because we have other subjects to study and other projects and exams that can consumpt our time

    Attemp to be responsible with our time and tasks and try to organize ourselves as good as we can

    New technologies

    Some technologies that we will use in the projects are new for us such as React or managing a database due to our lack of experience

    Learning the new things that we don’t know and not being unwilling to confront new things such as technologies or languages that are new for us or near to new

    Not arriving deadlines

    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

    +
    +

    11.2. Technical Debt

    + ++++ + + + + + + + + + + + + + + + + + + + + +
    Technical DebtDescription

    Space 1.1

    Space 1.2

    Space 2.1

    Space 2.2

    Space 3.1

    Space 3.2

    +

    12. Glossary

    @@ -1803,7 +2145,7 @@

    12. Glossary