# M7: Final Release

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

Your 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!

# Submission contents

You should produce a final software release, following that process.

Additionally, you should produce updated documentation, which will be stored in GitLab along with your other project documents. Minimally you should have the following:

# 1. README file

Your top-level document should serve as a table-of-contents for the rest of your content.

It should include:

• Product title
• Product description
• Screenshot and/or introduction video
• Team names and contact info

It should also include links to the following Wiki documents:

• Project proposal (unchanged, from previous submission)
• Design proposal (unchanged, from previous submission)
• Meeting minutes (which you should have from the entire term)
• 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. Documentation

Create the following documents. Store each one as a Wiki page, linked from the README file (see above). The name of each document should follow the naming convention here (e.g., create a document named "User documentation", another named "Design diagrams" and so on).

(a). User documentation

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

(b). Design diagrams

• Include revised, up-to-date versions of the following diagrams from your earlier proposals. Do not update the originals i.e. leave your earlier design proposal alone. Create new, revised versions for this section.
  • 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.

(c). Project reflections

• This should be a team contribution, maximum 1 page.
• Discuss the software engineering practices that you used:
  • What "best practices" did you adopt? Which ones were effective? Which ones were not effective?
  • How did you as a team adapt or change as the project progressed?
  • In your next project, what would you do differently?
  • Discuss technical/design challenges:
    • What design/solution are you particularly proud of, and why?
    • What was the most difficult technical challenge you faced as a team, and how did you overcome it?

# 3. Source tree

For your final demo, you should have followed the software release process, as you did with all prior releases. All of your code should be committed and merged to the main branch.

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

# 4. Project details

Your issues list in GitLab should accurately reflect the status of your project.

• Issues should be assigned to the appropriate sprint milestones.
• Issue status is 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 Project Submission rubric in Learn for the mark breakdown.

# How to submit