Final submission

This section describes a project milestone. See the schedule for due dates.

At the end of the term, we will review your entire project. This section describes what you will be required to submit.

This submission should reflect all the work that you did during the term. You can and should be working towards these items incrementally. In the final weeks of the course, you should focus on making sure that documentation is updated and reflects what you actually accomplished!

Software release

You should produce a software release.

The following guidelines apply:

• Your project should be buildable from main using gradlew.
• Installers should also be buildable from main using gradlew. If there are manual steps required to build your project, they must be documented and made clear to the TA grading it.
• Unit tests must be included for all entities, models and view models.

Documentation

All documentation should be written in Markdown format, using Mermaid for injecting diagrams.

With the exception of the README.md file, each document should be a Wiki page that follows the naming convention here (e.g., create a document named “User documentation”, another named “Design documents” and so on). Consider linking your Wiki page to the top-level README file to make it easier to locate.

Your project should include the following sections.

1. README file

Your top-level document should serve as the landing page for your project, and a table-of-contents for the rest of your content.

It should include:

• Product title
• Product description
• Requirements to install/run your project
• Screenshot and/or introduction video
• Team names and contact info

It should also include links to the following Wiki documents:

• Project proposal (unchanged from initial release)
• Design proposal (unchanged from initial release)
• Meeting minutes
• Software releases, with links to release notes/installers (final release, plus previous submissions).
• User documentation (new, see below)
• Design diagrams (updated, see below)
• Team reflections (new, see below).

2. User documentation

You should expect to document your project! Documentation will include:

• Include brief instructions on how to install your product. Bullet points is fine.
  • Make sure that you should specify what device to use (e.g., Android AVD Medium Phone).
  • Include specific steps on how to install your application. For desktop, this should include steps on how to run the installer. For Android, discuss setting up the AVD and dragging the APK into it the launch it.
  • If there are any other instructions e.g., how to launch your server, include them here.
• Provide guidelines on how to use your main features. If they are complex, you should include diagrams or screenshots.
  • It is not required to describe all of your functionality, just provide a guide to the main features.
  • If you have multiple screens, describe what each ones does and how to navigate between them.

3. Design documents

We want to see both your original designs, and any updated documents. It should be clear when comparing them what, if anything, has changed.

Create new, revised versions of the following:

• Your personas
• Figma UI prototypes.
• A high-level component diagram showing your application structure e.g, layered architecture, with external systems for auth and database.

Create class diagrams for your main classes in your application.

• Focus on your “most important” classes: entities, models and view models. You do not need to create diagrams for external systems like your database or the user interface compose functions (although you do need to diagram view model classes, and it should be clear in your diagram which screen each one is supporting).
• Make sure that you illustrate where the classes “fit” in a Layered Architecture e.g., organise them into layers.

It’s entirely possible that you may not need to update your personas, or prototypes, or component diagram from earlier. That’s ok. In this case, just create copies of the earlier diagrams, and put the copies in the Design diagrams page.

4. Source code repository

Source code and other assets required to build your application should be stored in your project’s source code repository. The structure should look something like this by the end of the term.

.
├── .gitignore
├── README.md
├── application
│   ├── build.gradle
│   └── src
│       ├── main
│       │   └── kotlin
│       └── test
│           └── kotlin
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── releases
│   └── v0.1-release-notes.md
│   └── v0.1-installer.dmg
│   └── v0.1-installer.exe
├── server
│   ├── build.gradle
│   ├── gradle.properties
│   └── src
│       ├── main
│       │   ├── kotlin
│       │   └── resources
│       └── test
│           └── kotlin
├── settings.gradle
└── shared
    ├── build.gradle
    └── src
        └── main
            └── kotlin

For information on creating your project structure correctly, see Build configuration and Gradle documentation.

Updated project details

Your GitLab project should reflect the final (current) state of your application.

• Issues should be assigned to the appropriate sprint milestones.
• Issue status should be correct i.e. completed and merged features should be marked as closed in GitLab.

It’s acceptable to have open issues at the end of the project, but they should not be assigned to a milestone (and related code should be on a feature branch, not merged back into main).

Assessment

You will be graded on the documents above, as well as your final product release. When evaluating your product, marks will be assigned based on how well you have met project objectives.

See the Final Release rubric in Learn for grading details.

How to submit

You do not have to explicitly submit your final. We will grade based on what was submitted by the listed time and date using the criteria above.