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 are held Friday during class.

• See the demo times for your team’s scheduled time.

Be prepared to:

• show your issue board (with issues open/closed/updated),
• demonstrate what you’ve completed (with code compiling) and
• ask and answer questions about anything that you’re working on.

Check-ins are meant to demonstrate progress, and provide opportunities to discuss your project, and get guidance from your TA.

See the Checkin Rubric in Learn for grading details.

Demos#

Demos are lengthier, formal demos of completed work. They are held every third Friday during class, and replace check-ins for that week.

• See the demo times for your team’s scheduled time.
• Each demo has it’s own objectives. See below.

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:
   • Product vision
   • 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.

Everything should be stored as part of your project’s documentation (README.md and/or Wiki pages).

See the Demo 1 Rubric in Learn for grading details.

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!

Everything should be stored as part of your project’s documentation (README.md and/or Wiki pages).

See the Demo 2/3 Rubric in Learn for grading details.

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.

Everything should be stored as part of your project’s documentation (README.md and/or Wiki pages).

See the Demo 4 Rubric in Learn for grading details.

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.

See the Final Submission Rubric in Learn for grading details.