Giter VIP home page Giter VIP logo

website's Introduction

BenchLab Website

Installation & Development

Prerequisites

  1. Clone the repository.
  2. Open the website folder.
  3. Create a .env file in the website folder.
  4. Add the following environment variables to the .env file:
## Azure Blob Storage

AZURE_STORAGE_CONNECTION_STRING = 'connection_string'
AZURE_STORAGE_CONTAINER_SUBMISSION = 'container_name'
AZURE_STORAGE_CONTAINER_VALIDATOR = 'container_name'

## Backend 
SECRET_KEY = "secret_key"
DB_NAME = "benchlab"
DB_HOST = "localhost"
DB_USER = "benchlabuser"
DB_PASSWORD = "password"

DEBUG = "True"

EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_HOST = "mail.tptech.nl"
EMAIL_FROM = "[email protected]"
EMAIL_HOST_USER = "[email protected]"
EMAIL_HOST_PASSWORD = "password"
EMAIL_PORT = "587"
EMAIL_USE_TLS = "True"

FRONTEND_URL = "http://localhost:5173"

ALLOWED_HOSTS = "*"
CSRF_TRUSTED_ORIGINS = "http://localhost"
JUDGE_HOST = "localhost"

## Frontend 
VITE_API_URL = "http://localhost:8000/api"

For the value of EMAIL_HOST_PASSWORD, ask someone who set up the repository already.

Frontend

  1. Make sure you have Node.js 20 LTS installed on your machine. If not, please install it. LINUX ONLY: You might need to use Node Version Manager (nvm) to install this specific version of Node.js, as the default install command via apt has an older version.
  2. Install/Activate yarn (run corepack enable, this command might require admin priviliges).
  3. Open the frontend folder.
  4. Run yarn (this will install all dependencies). DO NOT USE NPM TO INSTALL DEPENDENCIES.
  5. To start vite you can run yarn vite.

MySQL

  1. Install MySQL.
  2. Create a basic server.
  3. Open the created database and run CREATE DATABASE benchlab; (using sudo mysql on Linux).
  4. The run CREATE USER 'benchlabuser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';.
  5. Finally run GRANT ALL PRIVILEGES ON benchlab.* TO 'benchlabuser'@'localhost';.
  6. Adjust the .env file based on the properties defined above, in case you modified any values (e.g. the password).

Backend

  1. Make sure you have Python 3.12 installed. On Linux, this can be done with sudo add-apt-repository ppa:deadsnakes/ppa, followed by sudo apt install python3.12 python3.12-venv python3.12-dev (since you also need venv and the Python development headers).
  2. On Linux, you also need the following: sudo apt install pkg-config default-libmysqlclient-dev build-essential (used by mysqlclient).
  3. Create a virtual environment by running python -m venv .venv in the website(root) directory.
  4. Select the virtual environment as your VS Code interpreter.
  5. Activate the virtual environment by running (Linux) source .venv/bin/activate or (Windows) .venv\Scripts\activate.bat.
  6. Navigate your command line into the backend folder (e.g. using cd backend).
  7. Run pip install -r requirements.txt (this will install all dependencies).
  8. Install the Ruff VSCode extension.
  9. Run migrations: python manage.py makemigrations and python manage.py migrate.
  10. Run seeder: python manage.py loaddata XXXX_filename.json where XXXX_filename.json is the file with the highest number in backend/api/fixtures.
  11. To start the server, use python manage.py runserver.

Folder Structure

After following the steps above, the folder structure should look like this:

website/
├─ .github/
├─ .venv/
├─ backend/
├─ docs/
├─ frontend/
├─ .env
├─ .gitignore
├─ README.md
├─ ruff.toml
├─ SECURITY.md

Deployment

Use the production branch to deploy the webapp.

Database seeding

To get initial data in the database run python manage.py loaddata XXXX_filename.json. To remove all data from the database run python manage.py flush this will permanently delete all data from the database so be carefull with this. Note: the passwords for the currently seeded accounts are admin, staff and user respectively

Making new seeder files

A convenient way to make new seeder files is by creating new entries in the tables via the django admin panel (localhost:8000/admin) and then running the following command: python manage.py dumpdata api --indent 4 --output=api/fixtures/XXXX_filename.json. Here count up from previous highest number in the folder and maybe give the new file a somewhat descriptive name.

You can also choose to write your own seeder files from scratch with json but that can be a bit of a hassle because you have to manually do all the foreign keys.

Workflow for when you alter models (no important data in the db)

NOTE: this is not yet a very streamlined workflow so if you find out stuff doesn't work or if you find a better way, please edit the file and make a pull request for it. When doing migrations, sometimes it's not necessary to change all the data, in those cases make a new fixture file after migrating so that the changes are reflected in the seeded data. If you do need to change data this can be a workflow:

  • run python manage.py makemigrations to generate the migration files.
  • run python manage.py migrate to migrate the changes.
  • adapt the seeder files to reflect the new changes in the db.
  • run python manage.py flush to empty the database.
  • run python manage.py loaddata XXXX_filename.json to seed the db with the new data.

If the migrate command gives an error, it might be easier to reset your entire database. This can be done with python manage.py reset_db, rather than the flush command.

Ruff

Ruff is a tool that checks, based on some rules, the Python code, similar to Java Checkstyle.

To change the settings or add features to ruff check the ruff.toml file. This can be found in the backend folder. This file also contains explanations for each setting/rule.

The following keybinds might be different on your machine:

Pressing Shift + Alt + F will allow you to use Ruff to format and fix the code. Keep in mind that Ruff is not able to fix all issues.

Pressing Shift + Alt + O will use isort to sort the imports.

Code quality analysis

What to do if checks fail?

Navigate to show output as shown below in the Usage section. If show output in the workflow failed and it states Code violations found!!!!! at the bottom then you're code does not adhere to the quality standards. The table in the output above shows which categories have violations (in red). For a better understanding of quality standards you can look at the tables in the Metrics section.

For any questions about this workflow or issues contact Tom.

Usage

This worklfow is run whenever a commit is pushed to main or a pr into main is made. It may take between 1 to 3 minutes to complete the analysis. To view the results do the following:

Navigate to the github action and click on the job Code Quality:

The Show output tab shows all the metrics gathered by the tools:

The output starts with some intermediate debug results, which you can ignore. The evaluation of you code is shown in the tables below. Threshold violation percentages is the percentage of files/code that violate the metrics shown in the table below. Ranks shows the combined rank for each maintainability attribute. It shows the grade that our code would get according to the metrics that the TU/e uses.

Metrics

For each characteristic we compute what percentage of the code is above the threshold. Then a rank is computed for that characteristic. For each Maintainability attribute we compute the average rank (based on its corresponding code characteristics).

Code characteristic Metric Threshold Maintainability attr.
Module size SLOC <=400 ADT
Class complexity Cyclomatic per method: average; max <10; <20 DT
Class design (for OO) WMC <=20 MRAD
Module design (for non OO) Functions per module/file <=20 MRAD
Module internal duplication % of duplicated SLOC inside modules N/A RAD
Code commenting % LOCM >15% A
Cyclic dependencies # of between classes 0 MRADT
Module coupling CBO <16 MR
Module external duplication % of duplicated SLOC between modules N/A MR
rank % of modules/classes/packages above threshold
+2 0-3%
+1 4-5%
0 6-10%
-1 11-20%
-2 21–100%
Code Maintainability attribute
M Modularity
R Reusability
A Analyzability
D Modifiability
T Testability

The code quality assessment document that TU/e uses can be found here.

Code analysis tools

TU/e uses simian to analyse code duplication. understand is used to derive all the other metrics.

Note: understand incorrectly computes Module coupling, it only accounts for classes in the same file.

Testing

In order to run backend unit tests, navigate to the backend folder, then run the following command: python manage.py test tests

When you want to run frontend unit tests for the first time, navigate to the fontend folder. You might have to run this command first to install the necessary dependencies: yarn To run frontend unit tests, navigate to the fontend folder, then run the following command: yarn run test If you would like to also see code coverage, run the following command instead: yarn run test --coverage

website's People

Contributors

doodshoofdaapje avatar andreitudorp avatar thijsegberts avatar discordturtle avatar tpgamesnl avatar marnikdenouden avatar thomasnagel avatar booksh avatar rijkman avatar stijnking avatar dependabot[bot] avatar

Stargazers

 avatar  avatar  avatar  avatar

website's Issues

As a PO I want the SDD to have an introduction (SDD Section 1)

Description

The Introduction of the SDD is filled with the appropriate sections. The purpose of the SDD and its intended readership described. The scope of the software is given. The terms and references have an initial version, for example parts used from the URD.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)
  • Feedback has been given again
  • The section has been refined after feedback

Acceptance Criteria

  • Section 1.1 is present with the purpose of this particular SDD and its intended readership.
  • Section 1.2 is present, the scope of the software is explained, Identifies the product by name, explains what the software will do.
  • There is a list of definitions and references present
  • Section 1.5 the overview is present and includes a short description of the rest of the SDD and how it is organized.

As a PO I want an Overview Section 2

Description

A summary of the process to be supported, the fundamental principles of the process, what the software does to support the process, what the user needs to supply to the software.

Acceptance Criteria

  • A desciption is given of what process the software supports, what problem it solves.
  • It is given what the software does to solve this problem and how it supports the user.
  • The dependencies of what the user supplies are given and explained.

As a PO I want to have Software change requests and Software Modification Reports, section 7 and 8

Description

Any changed that are requested in Section 7, once that were implemented are documented as such in Section 8.

Section 7: A list of software change requests raised during the transfer phase.
Section 8: A list of software modification reports completed during the transfer phase.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • Section 7 is finished
  • Section 8 is finished

As a PO I want to know the feasibility and resource estimates (SDD Section 4)

Description

Write section 4, a summary of computer resources needed to build, operate and maintain the software. Consider performance, response time, disk/memory usage.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • Section 4 has been written to include the description above

ATP - As a PO I want a Test plan (Section 2)

Description

There needs to be a plan which includes what is needed for the Acceptance Test.
For example: "In this chapter, we will introduce the items and features that need to be tested. A general overview of the testing process is also given. This includes which tests shall be performed, what the environmental needs are, and the criteria for passing or failing a test."

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • Section 2.1 is present with the items to be tested.
  • Section 2.2 is present with the features to be tested.
  • Section 2.3 is present with the test deliverables and has items that must be delivered before testing starts and when testing ends.
  • Section 2.4 is present with Testing tasks that are needed to prepare and carry out the tests.
  • Section 2.5 has the environmental needs with the properties required of the test environment.
  • Section 2.6 contains the test case pass/fail criteria.

ATP - As a PO I want Test reports (Section 5) and a Traceability matrix (Section 6)

Description

Traceability matrix shows which test case is for which requirement. The test reports refer to the relevant section in the STD.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • Section 5 is complete, refering to relevant sections in the STD
  • Section 6 has the full traceability matrix for atleast the must haves. Connection URD requirements with test cases in the ATP.

As a PO I want Configuration item list Section 4

Description

All configuration items (objects under version control) transferred.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • Section 4 is finished

As a PO I want all functionality as part of a session explained with a Tutorial Section 3

Description

First of, I want to salute you for considering doing this section. This section includes creating tutorials for how to do everything with the software. For each session or functionality, it is explained what the session achieves and what precautions should be taken. Then for each session, the procedure is given for how to do everything in a step by step way. We can use screenshots for this as well. Consider working together with some parts of the ATP as the functionality and steps can be the same. Lastly there is some informal error description.

Acceptance Criteria

All functionality is included in tutorial sessions each having:

  • 3.n.1 Functional description: What the tutorial session is supposed to achieve.
  • 3.n.2 Cautions and warnings: A list of precautions that may need to be taken.
  • 3.n.3 Procedures:
  • How to prepare for and start the task.
  • A step-by-step description of what the user must do and the response of the system.
  • What final results to expect.
  • 3.n.4 Likely errors: An informal description (not a list of errors) of likely errors and possible causes.

As a user I can register account information (front-end)

Description

A form with inputs for email and optional information. The page does not need to have functionality besides having some input fields and buttons required for later user stories.

Acceptance Criteria

  • A registration page exists with email field and optional information field. (username for now suffices)

EPIC: As a student I want to have fun

Description

As students we want to enjoy this project by having fun together.

User stories

  • Fun SEP day 21st of June
  • Minecraft Server
  • Fun breaks together

As a PO I want to have a Data model (SDD Section 3.4)

Description

Description of the persistent data stored in the system in the form of ER diagram, with an explanation.

Version 1.2 https://tuenl-my.sharepoint.com/personal/t_peters1_student_tue_nl/_layouts/15/doc.aspx?sourcedoc={d94ecb0a-9ddb-4018-a7ef-0dbd3c8b77b8}&action=edit
Version 1.4 https://tuenl-my.sharepoint.com/personal/t_peters1_student_tue_nl/_layouts/15/doc.aspx?sourcedoc={bf0fc952-77d9-4ac8-a6c0-2341d5fdad89}&action=edit I checked it and placed some comments (Evy)

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance criteria:

Section 3.4 of the SDD includes:

  • An ER diagram of the data stored in the system
  • An explanation of this diagram

As a user I can login using my email using email verification (front-end & back-end)

Description

Users can be directed to a login page where they can fill in their email address. This is used by the system to send a verification email. The verification link can be used to login into the page. The user is logged in.

Acceptance Criteria

  • The connection to the system sending emails is made and working.
  • The email can verify the login.
  • The user is logged at the end if it verification succeeded.

Requirements

  • URF 2.3
  • URF 2.4
  • URF 2.5

Notes

There is a bug that does not display the data after logging in. The access to the backend does not seem to work although access tokens are present. Refreshing works for password login but not for email login.

As a PO I want to have an Acceptance test report summary and Software problem reports. Section 5 and 6

Description

After the Acceptance Test, a summary is written here.
Summary of test reports in the AT, user requirements not met, number of acceptance tests passed/failed.

If any software problems occur during transfer phase than these are written down in section 6. Basically empty if non occur.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • Section 5 is finished
  • Section 6 is finished

ATP - As a PO I want test procedures (Section 4)

Description

The test procedure indicates how the test will be executed, the procedure goes over the different test cases in a logical order. All you need to know to actually perform the test.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • The list of test procedures is present and includes all test cases
  • The purpose of each test case is clear
  • The procedure steps can be followed by the client and include: How to log, set up, start, proceed, measure, shut down, restart, stop the test.

As a PO I want all appendices present

Description

The appendices are present. More info can be seen in the example document.

Acceptance Criteria

The following appendices are present.

  • A. Error messages and recovery procedures: A list of all error messages; for each error: diagnosis and recovery procedure.
  • B. Glossary: An explanation of terms used.
  • C. Index: A list of topics and their pages.

backend Azure Blob Storage not in requirements

I get the error ModuleNotFoundError: No module named 'azure.storage' when trying to start the backend, because azure-storage-blob isnt installed. It should be added to the requirements.txt file to make sure people install it.

As a user I can have an overview of a problem occurence (front-end)

Description

As a user I can navigate form the overview of problem occurences to a specific overview for a selected problem occurence.

Acceptance Criteria

  • There is a problem occurence overview page
  • The problem occurence overview page can be navigated to from the overview of problem occurences
  • There is room for information on the problem occurence overview regarding settings, metrics and more.

Requirements

  • URF 4.2

As a PO I want the SDD to have an architectural design of the system (SDD Section 3.1)

Description

Section 3.1 of the SDD should detail the modular structure of the system, describing the composition and context: relations between the components (dependencies, flow), preferably graphical with textual explanation. This should include a high-level design, the front-end architecture (can look at/reuse the screens diagram from the URD), with an explanation of each of the pages, and diagram(s) with explanation of the back-end architecture.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance criteria:

Section 3.1 of the SDD includes:

  • A diagram of the high-level design of the system
  • A textual explanation of the high-level design of the system
  • A diagram of the front-end architecture of the system
  • A textual explanation of the front-end architecture of the system
  • A textual explanation of the back-end architecture of the system
  • A diagram of the judge architecture of the system
  • A textual explanation of the judge architecture of the system

As a PO I want to have Unit test report Section 9

Description

The unit tests are described. Both how they are run and the results. The results are discussed when there is no or low coverage.

Process

  • A draft version has been written (no term references)
    - Note: I wrote this section for the front-end unit tests, the back-end/judge unit tests are not included yet
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • 9.1 Unit test location and execution: Location of unit tests in the code tree and steps how to run them. Unit tests should cover only the code developed in the project (classes, methods, …).
  • 9.2 Test report: Pass/fail indication for each unit test. Report on coverage and explanation about low or no coverage.

As a PO I want all operations to have a Reference part in Section 4

Description

For all operations the descriptions are given and what warnings can occur.

Acceptance Criteria

For all operations the following is included:

  • 4.n.1 Functional description: What the operation (command, menu item, button, ...) achieves.
  • 4.n.2 Cautions and warnings: A list of cautions and warnings that apply to the operation.
  • 4.n.3 Formal description: A formal description of what the operation does and how it is used: required parameters, optional parameters, defaults, syntax and semantics.
  • 4.n.4 Examples: One or more examples of the use of the operation.
  • 4.n.5 Possible errors: A list of all possible errors for this operation and their causes.
  • 4.n.6 Related operations: References to, for example, operations to complete a task or logically related operations.

As a system I can store registration information for users (back-end)

Description

The system is able to store additional information. The account data is kept track of in some form of storage (discuss with others). Account data can be stored in a database. The system can be used to check account existence. The front-end can call a function with an email address to check email existing within an account.

Acceptance Criteria

  • Email addresses can be added to the database.
  • Optional account information can be stored. (for now username as an example suffices)
  • The system can check from the front end whether there exists a stored account with a certain email address

As a PO I want an Introduction Section 1

Description

The introduction section should be written to include the parts below. For an example see the example document on canvas.

Acceptance Criteria

The introduction section includes:

  • 1.1 Intended readership: User categories (end user, operator), level of experience assumed, which sections are most relevant.
  • 1.2 Applicability: Software releases the SUM applies to.
  • 1.3 Purpose: Purpose of the SUM and of the software.
  • 1.4 How to use this document: What each section contains and the relationships between sections.
  • 1.5 Related documents: All applicable documents.
  • 1.6 Conventions: All symbols, stylistic conventions and command syntax conventions used.
  • 1.7 Problem reporting: A summary how to report software problems.

EPIC: As a PO I want all must have requirements implemented

Description

A list to keep track of which must haves are finished and which ones are still being worked on. This should provide an overview of how far into the project we are. A must have is done once it is implemented such that it can be tested. No user stories should be left that involve the checked of requirements.

Acceptance Criteria

User Account Login

  • URF 2.1
  • URF 2.2
  • URF 2.3
  • URF 2.4
  • URF 2.5

Specified problem requirements

Problem occurrence requirements

  • URF 5.1 #90
  • URF 5.2 #90
  • URF 5.3
  • URF 5.6

Configuration requirement

  • URF 6.2 (competition or scientific type)

Problem instance requirements

Submission requirements

  • URF 8.1
  • URF 8.4 #92
  • URF 8.5
  • URF 8.8 #96

Code submission requirements

  • URF 9.2 (after submission start code submission evaluation) #103

Evaluation requirements

  • URF 12.1 (computing metrics should be shown on actual problem)
  • URF 12.2 #94 and #106
  • URF 12.10 #91

Code evaluation requirements

Problem occurrence leaderboard requirements

Problem instance leaderboard requirements

Security constraints requirement list

  • URC 1.1
  • URC 1.2
  • URC 1.3

Hardware and Software constraints requirement list

  • URC 2.1
  • URC 2.2 #89
  • URC 2.4

Usability constraints requirement list

  • URC 3.1
  • URC 3.2 (make easier and documented) #110

As a PO I want to have External interface definitions (SDD Section 3.5)

Description

This section describes the relationships with external systems (interface and file format definitions).

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance criteria:

Section 3.5 of the SDD includes:

  • An explanation of the external systems
  • For each external system, definitions of the interface and file format

As a PO I want to have Introduction Section 1 and preceding parts

Description

The necessary parts of the document that introduce the STD.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

The STD contains:

  • Abstract
  • Table of Contents
  • Document Status Sheet: Status sheet for configuration control (previous versions and their main contributions).
  • 1.1 Purpose: The purpose of this particular STD and its intended readership.
  • 1.2 Scope: Scope of the software. Identifies the product by name, explains what the software will do.
  • 1.3 List of definitions: The definitions of all used terms, acronyms and abbreviations.
  • 1.4 List of references: All applicable documents.

EPIC: As a develop I want to implement unit tests

Description

One of the tasks in developing software is to add tests. These tests should be run automatically as part of your development workflow (CI). These tests should be a good indicator for you that if passed, shows that existing functionality works as expected.

Focus on: Unit tests for frontend, backend, judge runner, judge queue.

User Stories

  • As a developer I want to implement unit tests such that I can automatically tests my code to verify that functionality is still working.
  • As a student, I want to fulfil the requirements around testing by the course (code coverage).
  • As a developer I want the unit tests to automatically run such that I know when my functionality breaks and I can prevent a PR from merging or code from releasing.

Tasks

ATP - As a PO I want test case specification (Section 3)

Description

The test cases specify how a specific part/feature is tested. It includes the input/output with the environment needed.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • There is a test case for all the requirements implemented
  • Identifiers and the items to be tested are present for all test case specifications
  • The input and output of the test case are specified.
  • The environmental needs are specified

As a developer I want to start with unit tests

Description

In order to start with creating tests a couple of unit tests should be created that can be used as an example for new unit tests. The tests are of various types, testing different type of code such that more unit tests can be created.

Acceptance Criteria

  • Different types of unit tests are created, which can serve as an example for new unit tests.

As a PO I want to have the Build procedure Section 2

Description

How and in which environment the software was built. Description of the continuous integration and testing environment. Version of the software which was built. Problems during build, time needed to build.

The Readme's include already a lot of this information.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • Section 2 has been finished

As a PO I want the SDD to have a system overview (SDD Section 2)

Description

An initial version of the System overview section (section 2) of the SDD is written. This includes a section on the relation to current projects, as well as a section on the relation to predecessor and successor projects, a section explaining the function and purpose of the system, a section detailing the environment the system is meant to be used in and a section talking about the relation of the system to other systems.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance criteria:

  • Section 2.1 contains an explanation of the context of this project in relation to other current projects
  • Section 2.2 contains an explanation of the context of this project in relation to past and future projects
  • Section 2.3 contains a general overview of the function and purpose of the product, including a domain model, defining and discussing concepts of the system
  • Section 2.4 contains an explanation of the hardware and operating system of target system and development system, as well as who will use the system (user roles in URD)
  • Section 2.5 explains whether the product is part of an independent system, part of a larger system, replacing another system as well as the essential characteristics of these other systems

As a PO I have an overview of what will be stored

Description

An overview is created of the possible contents of the database. Where it is clear for the PO how the structure relates to the submissions and leaderboards.

Acceptance Criteria

  • The overview contains the terminology from the URD
  • The overview can be used to keep track of what needs to be stored
  • The PO has seen the overview and approves of the contents (nothing is missing or wrong)

As a PO I want a Logical model description (SDD Section 3.2)

Description

A description of the logical model (static structure) in the form of class diagram (UML or ER). This should be logical model, NOT a detailed implementation model or a reverse engineered implementation.
This class diagram should be explained and justified in text.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • Class diagram (UML or ER)
  • Explanation of entire class diagram
  • Contains all the functionality of Benchlab

As a system I can send emails to users (back-end)

Description

The system can send an email with content to an email address. This functionality will need to be used for email verification as a way for users to authenticate themselves on the platform.

Acceptance Criteria

  • The system can send an email with text content to a valid email addresses

As a PO I want the System Dynamic (SDD Section 3.3)

Description

Section 3.3 System dynamics including states, transitions, and reactions to events. Use message sequence charts showing the dynamic behavior and a textual explanation.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)
  • Feedback has been given again
  • The section has been refined after feedback

Acceptance Criteria

Sprint 3

  • 5 functionality sections are created with a sequence diagram for each.

Future Sprints

  • Sequence Diagrams are created for all functionality
  • General description is present for all functionality
  • Functionality is explained with format (goal, pre-, postcondition, etc.)
  • (Optional) A process model is created (e.g. Petri.net) (Section 3.3)
  • Sequence diagrams are added for currently not implemented features

As a PO I want to have Design rationale (SDD Section 3.6)

Description

Rationale for the architecture described before. Trade/offs and alternatives that have been considered. Design decisions are explained and motivated. Make sure that design aspects are considered and not only (implementation) technology choices.
Since not all design choices have been made yet, this section should be updated as we go to include all design choices that we make.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance criteria:

  • All design choices made so far are described in Section 3.6 of the SDD
  • Each design choice has an explanation and trade/offs, alternatives that have been considered

As a PO I want information about the document in Section 0

Description

Create the abstract, table of contents, document status sheet and document change records since previous issue. The basic things in the document that need to be included.

Acceptance Criteria

The SUM includes:

  • An abstract section
  • A complete table of contents
  • Up to date document status sheet Status sheet for configuration control (previous versions and their main contributions).
  • Document change records since previous issue (A list of document changes).

As a user I can create an account using only my email address (front-end & back-end)

Description

As a user I can create a new account by following the login procedure. The database is used to check account existence. The user is able to specify additional information. The account data is kept track of in the database.

Acceptance Criteria

  • During email authentication the database is checked for containing the email address.
  • Optional information and new account email is stored by the system.
  • Password field is removed.

As a PO I want to have the installation procedure Section 3

Description

How and in which environment the software was installed. Version of the software installed. Problems during installation, time needed to install.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • Section 3 has been finished

ATP - As a PO I want an Introduction in the ATP (Section 1)

Description

Create introduction, it can be similar to the URD with some changes.

Process

  • A draft version has been written (no term references)
  • Feedback has been given
  • The section has been refined after feedback (references are added for terms)

Acceptance Criteria

  • Section 1.1, The purpose of this particular section of the SVVP and its intended readership.
  • Section 1.2 Overview is present
  • Section 1.3 is present with the definitions of all used terms, acronyms and abbreviations
  • Section 1.4 is present with a list of references for all applicable documents.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.