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.

  • Check-ins are meant to be relatively informal. We won’t use the demo times, but TAs will walk around and chat with you when you’re available.

Be prepared to:

  • discuss what you’re working on, ideally related to that week’s lecture topics.
  • demonstrate what you’ve completed (including code compiling).
  • ask and answer questions about anything that you’re working on.

Check-ins are meant to demonstrate progress, 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:
    • Basic product information (product name and description, team details, team contract).
    • Product vision statement
    • Milestones created for each demo, with high-level requirements (features) assigned to each demo. These do not have to be final; they’re a starting point for your planning conversations!
    • Gantt chart showing your timeline. Identify reading week and other expected disruptions e.g., someone on vacation, midterms.

Where to store this?

  • Store your proposal in a Wiki page named Project Proposal, and link it from your README.md file.
  • The other details (above) should be added directly to your README.md file.

See the Outcomes page for formatting details.

In demo itself, you should plan to:

  • Walk through the presentation (5 mins), identifying key points from above. Take turns presenting! Each person should talk.
  • Discuss how to expect to tackle this (5 mins). Identify key features and risky features. You should try and address risks early in the project.
  • Get feedback from your TA (5 mins). Are features adequate for the problem you are solving? Is your solution achievable?

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.

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.

Backward Steps to Follow Outcomes Forward