Coding & demos

This section describes a project milestone. See the schedule for due dates.

You are working through product iterations, where you plan, design, and code in two-week cycles. You always start with planning, and end with a demo of what you accomplished.

First day: planning

The first day of an iteration should include be a planning meeting, where you:

  • Review the results from the previous demo.
  • Review work that was not completed and decide if you wish to continue working on it.
  • Plan out the remaining work, taking into account everyone’s availability, priority of issues and so on.

By the end of your meeting on the first day, everyone should have issues and work assigned to them.

Middle days: design, coding

Over the remaining two weeks, you should meet occasionally to coordinate your work.

You and your team should meet at least twice each week to review your progress.

  • Record meeting minutes and store in the wiki. Meeting minutes need to include: date, who attended, what you decided.
  • See gitlab/templates for a sample of a meeting minute format.

Issues must be maintained and updated as you work. Document your work indicating what was done. Use GitLab issues as the primary place to store information about what you’re working on.

  • The issue list in GitLab should always reflect the state of the project.
  • Issues always stay assigned to the person responsible for that work.

Gitlab issue

Last day: demo

On demo days, you will meet your TA in class and present your progress.

  • See the project team schedule for your assigned timeslot.
  • You only need to be there for your assigned time.
  • You have 15 minutes for the demo.

Before the demo:

  • Meeting minutes should be complete and posted.
  • All code must be committed and changes merged back to the main branch. This includes implementation code and associated unit tests (which should pass).
  • All issues in GitLab should be up-to-date i.e., comments added and issues closed if completed.
  • You must walk through the software release process.
    • This means creating Release Notes in GitLab, with a list of issues that you fixed.
    • It should also include a link to an installer (or APK file if developing on Android).

During the demo:

  • You must have your application installed on a computer that you bring to the demo (running from an Android Virtual Device (AVD) is acceptable for Android projects).
  • Bring up the list of issues completed (Plan > Issue Boards).
  • Demonstrate each feature from the list using this machine.
    • Each person on the team should demonstrate what they completed.
    • We want to see working functionality when possible.
    • You are allowed to show GitLab documents, unit tests results, or other work that demonstrates what you accomplished (since these are things that cannot easily be demonstrated in your application).

Caution

Your demo will be graded based on the features that are working during your demo. We strongly advise that you have everything working ahead of time.

Coding in the hall before the demo is a really, really bad idea.

How to submit

You do not need to submit anything. Your grade is based on your in-class demo, and your TAs assessment of your progress.

Tip

You should expect your TA to git clone your project and run your code following the demo to review what you showed them.