Course Info
Team Project
Project Stages
Software Release

Software Release

Make sure to address feedback from Sprint 4.

This document describes your team’s final submission for the term.

Requirements

At this time of this submission, your project should be complete, with all features delivered and tested. Your project should be complete and consistent, meaning that what is described in your GitLab project and documentation reflects the features that you ultimately delivered.

For this submission, you are required to address the items below.

Section Description
A. Revise Documentation Complete and revise your documentation
B. Finalize your Source Code Merge branches, finalize unit tests, comment code
C. Update your GitLab project Close sprints, update and reassign issues
D. Produce a Software Release Generate an installable version of your product

These items are described in more details below. All of these items should be stored in your GitLab project.

A. Revise Documentation

Your project documentation will consist of the up-to-date versions of the documents that you have been generating all term, as well as some new documents.

The exception to this is historical documents e.g., the Project Proposal or your Meeting Minutes. 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.

Documentation should be stored as Wiki pages in your GitLab repository, and linked from the README file. Documents should be named after the sections provided e.g., as wiki pages names “User Documentation”, “Design Diagrams” and so on.

You should have the following documents in your GitLab repository.

README file

The README.md file in your source code repository is the landing page for your project. The contents of this file should reflect the final state of your project. You should have most of these contents already fleshed out, but new items are marked as such as explained in later sections.

Your README.md should contain the following sections and contents:

README Contents

1. Description (link)

  • The product title or name,
  • A brief product description,
  • Team names and contact info,
  • A screenshot of your main window/screen (new, embedded),
  • A link to a YouTube video showcasing your project (new, link),
  • Acknowledgements (new, embedded).
  • Releases (new, see below)

2. Project Information (link)

  • Team Contract (unchanged, link to earlier submission),
  • Project Proposal (unchanged, link to earlier submission),
  • Meeting Minutes (link to updated log files from the entire term),
  • Developer Logs (link to updated log files from the entire term),
  • Team Reflections (new, link to Wiki page).

3. User Guide (link)

  • Getting Started (new, see below),
  • Usage Guide (new, see below).

4. Design Documents (link)

  • ERD Diagram (link to updated diagram),
  • Class Diagrams (new, see below).

5. Grading Instructions (link)

  • Any additional information that your TA might need to grade your project.

Description

Much of this information should already be in your README.me file. New contents include:

  • Add a screenshot depicting your main window or screen. This should just be illustrative of what your application looks like.
  • Create a video walkthrough of your application (1m to 2m in length) and post it on YouTube.
    • This should be a brief introduction to your features for a new user. Link to the video here.
    • The video should be publically accessible from the link.
  • Acknowledgements should list any external sources that you used for your project. This includes but is not limited to:
    • A list of external source code references that you used, following our external contribution guidelines. This could be snippets from a website, or GitHub, or even source code copied from a book.
    • A list of third-party libraries that you used (name/link is sufficient).

Project Information

This section should link to your existing documentation.

Additionally you need to add a Team Reflections wiki page. Generating this should be a team activity, and it should be a maximum of 1 page.

  • What features did you not complete?
    • Why did you drop them? How did you choose?
  • Discuss the software engineering practices that you used:
    • What “best practices” did you adopt? Which ones were effective? Which ones were not effective?
    • Did you as a team adapt or change as the project progressed? If so, how and why?
    • 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?

User Guide

You are required to write a guide for new users, which supplements the introductory video that you created (above). This should be one or more Wiki pages.

You should have a Getting Started guide that includes:

  • Details on what platform and/or device is supported.
  • Instructions on how to install your product. A bulleted list is accepted as long as it’s clear.
    • 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.

You should also have a Usage Guide that provides guidelines on how to use your main product features.

  • If your product is complex, you should include diagrams or screenshots.
  • This section should be sufficient to explain to a new user how to use your product.

Design Documents

This section should include the following diagrams.

  • Entity-Relationship Diagram showing your final database schema.
  • UML class diagrams for the 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.
Diagrams should be created using Mermaid and placed inline in your documentation. See Documentation for details.

Grading Instructions

This section should include anything else that your TA might need to know before grading your project. e.g.,

  • “You need to set the environment variable AUTH_TOKEN” to a valid GitLab token…"
  • “We have a web service that needs to be launched, and here’s the instructions for doing that.”
If your installation instructions are sufficient, then you can just state in this section that “no additional information is required”. However, if there is configuration missing, or your project does not run, you risk losing substantial marks. TAs cannot make unspecified changes to your project to “make it work” if it fails to work properly using your instructions. Be careful.

B. Finalize Your 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 the main branch, either via Gradle or within an IDE.
  • Installers should be buildable from main using Gradle tasks. If there are manual steps required to build your project, they must be documented in grading instructions.
  • Unit tests must be included for all entities, models and view models.

C. Update your 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.

D. Product a Software Release

You should follow the software release process. This will result in an installable version of your software and release-notes wiki page containing details.

Make sure to link this page to your README file as well.

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.