Milestones#

A milestone represents a significant date in your project. In this course, milestones are meetings where you meet your TA to present your progress.

We will work in three week cycles i.e. two weeks with check-ins, followed by a demo in the third week. See the schedule for details.

Check-Ins#

Check-ins are quick, informal discussions of your progress with your TA.

• They will be held Friday during class, and are graded.
• See the demo schedule for exact times.

What is the format for check-ins?#

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.

These demos are meant to ensure that you are making reasonable progress on your project. They also provide more opportunities for advice and guidance from your TA. Use these sessions to prepare for your formal Demos!

What is graded?#

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

Demos#

Every three weeks you will have a more formal demo, where you are expected to present your progress. These are also graded, but weighted much more heavily than check-ins.

• See the demo schedule for exact time.
• 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.

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 are expected to do the following.

1. Present features.
   • Planned features should be working as intended. You should have significant work completed 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.
   • Issues related for this milestone are updated and/or closed.
   • Unresolved issues are set to the next milestone and ready to be assigned.
   • Any project changes should be reflected in your documentation.
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 a nearly-completed product, with most-to-all features complete. We will grade what is submitted on the day of the presentation.

For this release:

1. Complete main 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.

How should you prepare?#

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

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!

Final Submission#

Your final submission is due at the end of the term, after the end of lectures. It is the culmination of all of your work, and should include everything described in the Deliverables section, plus any changes you choose to make after Demo 4.

Update documentation and other deliverables through the term, and the final submission should come together fairly quickly. Don’t leave everything to the last minute!