Course Info
Team Project
Project Stages
Software Release

Software Release

Make sure to address feedback from Sprint 4.

This is your team’s final deliverable. This section describes what you will be required to submit.

Requirements

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

Additionally, you should produce updated documentation, which will be stored in GitLab along with your other project documents. This should include 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.
  • Team contract.

It should also include links to the following Wiki documents:

  • Project Proposal (unchanged, link to earlier submission),
  • Meeting Minutes (link to log files from the entire term),
  • Developer Logs (link to log files from the entire term),
  • User Documentation (new, see below),
  • Design Diagrams (new, see below),
  • Team Reflections (new, see below).
You should not revise earlier documents even if you changed some details later in the project e.g., your Project Proposal may include some features that you didn’t implement, but you shouldn’t remove them from the proposal. New documents e.g., User Documentation should reflect the final state of your project.

2. Documentation

Create the following documents. Store each one as a Wiki page, linked from the README file. 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).

User Documentation

  • Include brief instructions on how to install your product. A bulleted list is accepted as long as it’s clear.
    • Make sure that you should specify what device to use (e.g., Android Pixel 7a).
    • 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 product features. If they are complex, you should include diagrams or screenshots. This section should be sufficient to explain to a new user how to use your product.

Design Diagrams

  • Include the following diagrams.
    • UML 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 classes into layers.
    • Entity-Relationship Diagram showing your database schema.
      • Include an up-to-date copy of your ERD. This should match your final design i.e., the code that is being submitted.

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?
Diagrams should be created using Mermaid and placed inline in your documentation. See Documentation for details.

3. Source Code

All of your code should be committed and merged to the main branch of your Git repository.

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

Your project in GitLab should accurately reflect the state of your project.

  • Issues should be assigned to the appropriate sprint milestones.
    • A completed Sprint should only contain the issues that were closed during that sprint.
    • Issues that are still unresolved should not be assigned to a Sprint.
  • Issue status is correct i.e. completed and merged features should be marked as closed in GitLab.
  • If an issue remains open, then the code for that issue should NOT be merged back into main, but should remain on a feature branch.

Submission

The deadline is 11:59 PM on the final day of the term; see the schedule for details. You do not need to actually submit anything; we will grade what is posted in your GitLab project at the deadline.

Grading

The grading scheme is available in Learn under Resources > Rubrics .

This is the final deliverable in the course. Per University Policy, the grades for this final submission will not be released in Learn. Your final course grade will be released along with other course grades at the end of the exam period.