Milestones#

A milestone represents a significant date in your project. Our milestones are regular meetings where you meet your TA to present your progress.

We have two different styles of meetings: check-ins and demos.

Check-Ins#

Check-ins are quick, informal discussions of your progress with your TA. They will be held every week during the Fri class and graded.

What is the format for check-ins?#

1. When you come into class on Fri, write your team number on the board below your TAs name.
2. Each TA will work through the list, spending 5-10 mins with each project team.

These are informal meetings. Be prepared to show your issue board (with issues open/closed), demonstrate what you’ve completed (compiling code) and ask questions about anything that you’re working on.

What’s the purpose of these demos?#

These demos are meant to ensure that you are making reasonable progress on your project. They also provide more opportunities for advice and guidance before your formal presentation. Frequent feedback is useful!

What is graded?#

You are graded based on prepareness for the demo (i.e. code compiles, issues list up-to-date) and whether you’ve made any progress from the previous demo.

Being absent results in an automatic zero. If the entire team is absent, everyone receives a zero for this deliverable.

Demos#

Every three weeks you will have a more formal demo, where you are expected to present your progress. These are also graded.

• Demos are scheduled for 20-mins for each team. See the demo schedule for the exact day and time.
• Demos are held in both sections i.e. some teams will present on Wed, and some on Fri. You are not expected to come to class if you are not presenting.
• Your TA will assign a team grade based on your presentation and what is documented in your GitLab project. Make sure that everything is complete going into the demo.
• Everyone will normally receive the same grade.

How should you prepare?#

Each demo has different objectives. For details on the format, see how to prepare for a demo.

Demo 1: Proposal#

This is your initial project proposal. The purpose of this presentation is for your and your TA to agree on what you intend to build, and for them to provide you with feedback and suggestions on what you might need to change. Your grade for this section is based on the viability and cohesiveness of your project plan i.e., are your features complete, will you be able to deliver these features on-time.

For this demo, you will need to produce:

1. Project Proposal (PDF format), which includes:
   • a description of a typical user and a description of how your product solves a problem for that user.
   • a list of requirements, 1-2 sentences each, which describe your final product.
   • sketches or mockups of your product screens (low-fidelity prototypes).
2. GitLab project, which includes:
   • Basic product information (product name and description, team details, team contract).
   • Milestones for each demo, with high-level features assigned to each demo.
   • Gantt chart showing your timeline. Identify reading week and other disruptions.

Demos 2-3: Iterations#

The intermediate presentations are meant to show progress on your features. You are not expected to bring a formal presentation (i.e. slides are not required), but should be able to show actual project artifacts related to what you accomplished. The goal is to get feedback, make adjustments and set yourselves up for the next demo.

For these presentations, you will need to complete the following.

1. Complete features.
   • Features should be working as intended. You should push to have significant work done for each demo.
   • Source code changes should be made on feature branches, then merged and committed to main.
   • Automated tests are created, with the expectation that test coverage will improve as the course progresses. Tests should pass.
2. Project artifacts are updated.
   • Any project changes should be reflected in your documentation.
   • Issues related for this milestone are updated and/or closed.
   • Unresolved issues are set to the next milestone and ready to be assigned.
3. A software release should be produced and linked to your README.
   • See release software.
   • Your TA should be able to install and execute your program!

Demo 4: Wrapup#

Your final demo should show your finished product, with all features complete. We will grade what is submitted on the day of the presentation.

For this release:

1. Complete all features.
   • Source code changes were made on feature branches, then merged and committed to main.
   • All anticipated features are completed in this release. All of your features should be complete. If you originally planned something that you will not be able to implement, you can discuss this in your final report.
   • Test coverage is adequate and complete. All tests pass.
2. Project artifacts are updated.
   • Issues for this milestone are closed.
   • Unresolved issues are unassigned.
3. A software release should be produced and linked to your README.
   • This includes installers for supported platforms.
   • See release software.
4. Documentation is updated, see deliverables. This includes:
   • Your user guide + and YouTube video.
   • A team reflections page.
   • Grading instructions.

All of your project artifacts must be stored in your GitLab project.

How are demos graded?#

For each demo, you are graded on everything that is listed above. This is a team-grade, where everyone receives the same grade.

What contributes to your team grade?

• Everyone being ready, and on-time.
• Features that were completed
  • Did you complete meaningful features, and make reasonable progress?
  • Is your source code structured properly, versioned?
  • Do you have passing unit tests for all of your features?
• Artifacts and project tracking
  • Are issues up-to-date, and do they reflect the work done?
• Software release
  • Did you produce an installable version of your software that can be tested?
  • Did you include release notes?
  • Did you follow the process appropriately?

Remember that your TA will be reviewing your GitLab project after the demos are complete. Avoid the temptation to change things after the demo; you risk breaking things instead!