Outcome#

There are two types of outputs from a project: artifacts, and deliverables. You will need to collect both for your project.

Everything that you produce in this course MUST be stored in your GitLab project, typically in one of three places:

1. The README.md, which is the landing page for your project, or
2. A wiki page which you create and link to the landing page, or
3. In your Git source tree.

Individual requirements usually state where and how they should be stored, so read carefully.

Artifacts#

Project artifacts are as a by-product of building software, often documents and other things that you record as you build your product. This includes things like meeting minutes, requirements documents, and tasks logged in a project tracking system.

The following sections are artifacts that you are expected to record and maintain as your project progresses. They will be assessed as part of your final grade (and some components, like tasks, will be checked during each demo).

Source Tree#

Your source tree needs to be stored in Git as part of your GitLab project.

• The directory structure should match the structure required by the Kotlin Toolchain.
• You may have additional directories as needed e.g., /docs for GenAI scripts.
• You should use feature branches and merge all changes back to main as part of the software release process.

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

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 below).

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 stored as a Wiki page, 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?

GenAI Usage#

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.

GitLab Project#

Your GitLab project should contain all of your project materials. The following should be maintained to always reflect your current 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.

Deliverables#

Deliverables represent what you would deliver to a customer e.g., product releases and documentation. We usually categorize source code, and assets (art, sound) as deliverables, even though they may be delivered to a customer.

Your user deliverables include multiple releases of your product, and user documentation.

Software Releases#

You will produce a software release for each formal Demo, following the instructions on the software release page. It will be linked to the top-level of your README file.

User Documentation#

You will need to produce user documentation, linked to the topic in your README file. It should include the items listed there.