Deliverables#

Deliverables represent things you are expected to produce as part of your project.

The most obvious deliverable is a working product, but along the way you will accumulate documentation, project artifacts and other items that help you keep track of your progress. Everything needs to be stored in your GitLab project.

This page details what needs to be complete at the end of the term. You are expected to demonstrate progress on these for each milestone. Everything should be completed for the final submission.

Landing Page#

Your Git source tree must have a single README.md file at the root level. This is the page that is displayed when you open your project, and it serves as a landing page for your project contents.

• The format should appear as shown below.
• Short items can be listed directly in your README e.g., team names.
• Longer items e.g., meeting minutes, software releases or team reflections, should link to separate Wiki pages.

README.md

Description

• The product name.
• A one or two line product description.
• A screenshot of your main screen (when available, see final submission).
• A link to a 1-2 min YouTube video, introducing your product (when available, see final submission).

Team Information

• Team names and contact info.
• Meeting minutes (see run team meetings).
• Team reflections (when available, see final submission).

User Documentation

• Instructions on how to install your product (when available, see documentation).
• Details on what platform and/or device your software is supported.
• An expanded description of your main features, and how they work. Screenshots may be useful.
• Any additional information required to setup or use your product.

Design Documents

• Proposal presentation (see prepare for demos).
• Class diagram (when available, see documentation).
• ER diagram (when available, see database lecture).

Software Releases

• One page per software release (see release software).
• Each software release page should include:
  • Date and version number.
  • A list of issues addressed.
  • Attribution i.e., libraries, external source code, GenAI if used in this release.
  • Link to an installer - desktop, or mobile as appropriate.

Team Reflections

• Link to your Team Reflections document (wiki).

Grading Instructions

• Any instructions that your TA needs to grade your final submission.
  • e.g., instructions for setting up an API key
• If nothing extra is required, just state that.
  • e.g., “See user documentation above. No additional information required.”

Team Reflections#

As part of your final submission, you are expected to produce a Team Reflections document. Generating this should be a team activity. It should be 2-4 pages in length, and address the following questions.

Team Reflections

1. Proposed vs final features

• How did your final product compare to your original vision?
  • What features did you not complete? How did you choose which features to drop from your product?
  • Did the features that you kept reflect the most critical ones, or the easiest ones to implement?
  • How would you improve on this for future projects?

2. Use of GenAI

• Did you use GenAI? Why did you decide to use it (or not)?
• If it was used:
  • Provide details of your harness and models used.
  • How did you use it? Which tasks did you apply it to?
  • Where was it most valuable and least valuable?
• If it was not used, why?

3. Teamwork

• What “best practices” did you adopt? Were they 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?

4. 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?

GitLab Project#

Your GitLab project should contain all of your project materials, including source code. The following should be configured properly and reflect your project state i.e., work items completed towards each milestone, items pending and so on.

Milestones#

Each of your demos is a milestone, and should be tracked as such in GitLab. Your final submission should also be tracked as a final deliverable.

Work Items#

You should be tracking all of your work as work items in GitLab, associated with the Milestone where they were completed.

• All completed work should be documented and work items “closed”.
• Incomplete work should be unassigned i.e., no milestone.

Code branches should be used to stage work-in-progress, and code commits should be coordinated with the issues associated with that commit.

Source Tree#

Finally, you need to have your source code up-to-date, with all changes committed. For each demo, you need to have:

• Passing unit tests for your code.
• Feature branches merged to main.
• All features included in your build should have corresponding code in Git.
• Software releases need to be built from main.

The final release should include all code changes that are relevant to the final features.

The structure of your source tree will vary based on the type of project that you created, but it should resemble a standard KT project configuration. e.g.,

.
├── amper
├── amper.bat
├── android-app
│   ├── module.yaml
│   └── src
├── ios-app
│   ├── module.xcodeproj
│   ├── module.yaml
│   └── src
├── jvm-app
│   ├── module.yaml
│   └── src
├── project.yaml
├── README.md
└── shared
    ├── module.yaml
    ├── src
    ├── src@android
    ├── src@ios
    ├── src@jvm
    ├── test
    ├── test@android
    ├── test@ios
    └── test@jvm

GenAI#

You must document AI usage in your Team Reflections. Additionally, if you use AI to plan and build tasks lists, you are expected to include the corresponding md files in your source tree.

e.g., a docs/ subdirectory in your source tree containing:

• docs/requirements.md - one or more specifications of your requirements, used for your prompts.
• docs/plan.md - an execution plan to generate a list of tasks to perform.
• docs/tasks.md - a detailed lists of tasks to complete.

Note that you may have multiples of each document e.g., more than one requirements document. If so, either use subdirectories e.g., docs/requirements/user-interface.md or name your files in a way that makes their scope obvious e.g., docs/requirements-user-interface.md.