Assessment Criteria

The final application will be assessed based on the following five criteria:

  1. [30%] Functionality: The degree to which the user stories have been implemented.
  2. [20%] Application quality: The degree to which the application works.
  3. [20%] Usability: The level of usability the application achieves.
  4. [15%] Code quality: The quality of the code itself.
  5. [15%] Documentation: The quality of the documentation provided with the code.

The final mark is the weighted average of the individual criteria marks. Weighting is indicated by the percentage in square brackets.

Functionality

The functionality criterion measures the degree to which the user stories have been implemented. This is assessed by looking at the submitted source code, without running the application. Each user story is assessed on a four-point scale:

  1. Fully implemented: The user story is fully implemented.
  2. Partially implemented: The user story is partly implemented, for example the interface is implemented, but no interaction with the backend API has been implemented.
  3. Stubbed: Potentially relevant functions or files exist, but nothing has been implemented.
  4. Not-implemented: The user story is not implemented.

To ensure that this criterion can be assessed easily, you should reference the user story numbers in the code documentation.

The total mark for this criterion is calculated based on the fraction of user stories that have been fully implemented, partially implemented, or stubbed.

Application quality

The application quality criterion measures the degree to which the application is functional. This is assessed based on the integration tests that are required as part of the specification constraints. The integration tests will be manually assessed to determine the degree to which they cover the user story:

  1. Fully tested: All aspects of the user story are tested, including testing that invalid actions are not possible.
  2. Partially tested: Aspects of the user story are tested.
  3. Not tested: No test or no test code provided for the user story.

The total mark for this criterion is calculated based on the fraction of user stories that are fully or partially tested and the fraction of those tests that pass successfully.

Important

Before running the integration tests the database will be wiped. It is thus important that your tests work starting with an empty database.

It is recommended that you use the functionality documented in the “Administrative” section of the API to ensure that the database is emptied before running each test.

Usability

The usability criterion measures the ease of use of the application for the end-user. The mark is determined based on the following scale:

  1. >= 90: The application is highly usable and actively supports the user in achieving their tasks.
  2. 89 - 80: All aspects of the application are fully accessible according to WAI-ARIA.
  3. 79 - 70: The application gives appropriate and useful feedback to the user.
  4. 69 - 60: All aspects of the application can be used without difficulty.
  5. 59 - 50: All aspects of the application can be used, but often it is unclear how to achieve a given task.
  6. < 50: The application is essentially unusable, due to factors including, but not limited to: functionality is hidden behind labels that are incorrect, colour schemes make the content unreadable, the layout makes interaction with interface elements impossible.

Code quality

The code quality criterion measures the quality of the source-code, its readability, its maintainability, its consistency, and the clarity of its structure. The mark is determined based on the following scale:

  1. >= 90: The code has been structured so as to minimise code duplication.
  2. 89 - 80: The code has been simplified as much as possible.
  3. 79 - 70: The use of variable, function, object, and filenames is consistent and allows the reader to understand the element’s function.
  4. 69 - 60: The is consistently structured and indented.
  5. 59 - 50: The code is not consistently indented or structured.
  6. < 50: The code is essentially unreadable, poorly formatted, and no clear structure is apparent.

Documentation

The documentation criterion measures the quality of the documentation included with the source-code. The mark is determined based on the following scale:

  1. >= 90: The code documentation clearly explains how the various pieces of code work together and what the data and user flow is.
  2. 89 - 80: The code documentation consistently follows a standard for use with automated documentation tools.
  3. 79 - 70: The code is fully documented at the appropriate level of detail.
  4. 69 - 60: The code is fully documented, but the documentation is very brief.
  5. 59 - 50: The code is sporadically documented.
  6. < 50: The code is essentially undocumented.