Final submission

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

At the end of the course, we will review your entire project. Make sure that you have completed everything listed here.

Description

At the end of the term, your GitLab project, documentation and source code should be complete and consistent with one another. This means someone reading your proposal should see the features that you describe, unit tests should run properly, code should compile and run correctly and so on.

Additionally, your project artifacts need to be updated and reflect the end of your project.

• 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 incomplete code should be on a feature branch, not merged back into main).
• All code should be committed and merged back to main. We should be able to build from main without errors.

What to include

1/ Project documentation

The following project documentation should exist and be stored in your GitLab project. Everything should be written in Markdown format, using Mermaid for injecting diagrams.

You should have a top-level README.md file, and a series of Wiki pages listed here.

README (README.md 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 the following sections:

# SUPER-COOL-PROJECT-NAME

## Title
A description of your project e.g., "an Uber-eats app for parakeets!". 

## Project Description
A short description of your project, identifying your intended users, 
and the problem that you are solving. (ED: think of this as your 15 
second "elevator-pitch" of what your project is about).

## Video/Screenshots
Embed a video or series of screenshots that demonstrates using your 
application (maximum 1 minute in length).

## Getting Started
Instructions on how to install and launch your project. If you have any 
additional instructions that the TA needs, please put them here 
(e.g., how to launch from a Docker container; how to install keys so 
that they can connect to your database and so on).

## Team Details
Basic team information including:
* Team number
* Team members. Include full names and email addresses.

This should be followed by a Table of Contents section, with links to your Wiki pages.

## Documentation
* Project proposal (unchanged from initial release)
* Design proposal (unchanged from initial release)
* User documentation (new, **see below**)
* Design diagrams (new, **see below**)

## Project Information
* Team contract
* Meeting minutes

## Releases
* Bullet list of software release notes

Project Proposal (Wiki page)

This should be your original project proposal. Add a section at the end titled “Revisions” and describe any deviations you made from your original proposal, to what you delivered. If there are no deviations at all, then indicate that in this section.

Design Proposal (Wiki page)

This should be your original design proposal. Add a section at the end titled “Revisions” and describe any deviations you made from your original proposal, to what you delivered. If there are no deviations at all, then indicate that in this section.

User Guide (Wiki page)

This is a new requirement. You are required to write documentation explaining to your users how to use your product. You should include:

• Installation instructions, only if more detailed instructions are required (beyond what you provided in the README file).
• Installation requirements. List the operating systems and versions (if applicable) that you support. This is a good place to indicate what you used for testing.
• Features. Describe your main features and how they work. Screenshots are very helpful for doing this.

Design Diagrams (Wiki page)

This is a new requirement. Create the following diagrams using Mermaid.

• 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 the critical internal classes: views, view models, entities, models and service classes. You do not need to create class diagrams for external systems like your database or the user interface compose functions (which are presumably behind an API).
• Make sure that you illustrate where the classes “fit” in a Layered Architecture e.g., show them grouped into layers.

Team Contract (Wiki page)

This is your original contract. There is no need to update it (as long as nothing drastic changed!)

Meeting Minutes (Wiki page)

These are the minutes that you were expected to record through the term.

Software Releases

You should have produced software releases for each Demo that you did, plus optionally, one final release - see below.

2/ Source code repository

Source code and other assets required to build your application should be stored in your project’s source code repository.

1. Gradle project

Your project needs to be a Gradle project, as discussed in class. It should be buildable using standard Gradle tasks (e.g., gradle build, gradle test and so on).

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

2. Unit tests

You should have “adequate” coverage of your features, supporting the main execution path for your code.

• User interfaces (i.e. Composables/views) do not require unit tests, but the ViewModels should have appropriate tests.
• External systems (e.g., databases) can be tested either by mocking, or by having your automated tests check against test data on these systems.

3/ Final software release

Your code should be frozen after Demo 4, meaning that you should not make significant changes after that release.

However, sometimes last minute changes are required. If you need to produce a final build, you may do so, provided that you

• Follow the software release process (as you did with every other build), and
• You add it to the software releases section of your README.

We will grade the most recent release that is listed in your software releases.

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.

You should anticipate your TA grading based on what is committed in Git and in your GitLab project. Make sure everything is committed and tested by the due date!