Finalize your project

Complete the implementation of your project in your GitHub repository.

Based on the provided instructions in the top-level README.md file, anyone should be able to understand the purpose of the project and easily find instructions for building, testing, and running the system without issues.

You are also expected to address the feedback from the peer review comments.

Complete this in the main branch of your repository by due date.

Record a demo and group reflection

Record a demo and group reflection presentation that’s 16-20 minutes long and in which all members participate in some way.

Your presentation should have two parts:

The actual demo of the system (8-10 minutes). Focus on the final system and how a user interacts with it for the majority of this time; afterwards, you may also highlight some key accomplishments and technical challenges.

A reflection on the overall group project (8-10 minutes). This part of your presentation should address and reflect on the following:

• Features and cuts:
  Have you completed the major functionality and features listed in your original requirements document?
  What about the extra features (stretch goals) you listed?
  Did you add any additional features during the project that were not listed in your original requirements document?
  If you did not implement all features, why not?
  What features did you cut to help you complete the project in time, and why did you choose these to be cut?
  How much work do you estimate you saved by cutting these features?

• Roles and responsibilities:
  What ended up being your team members' current roles?
  How does this differ from your original expectations and specifications?

• Process and timeline:
  Did you change your software developement process model?
  What occupied the majority of each team member's time and workload?
  How does this differ from your original expectations and specifications?
  Where did you spend too much time, and why?
  Where did you spend too little time, and why?

• Testing and tooling:
  How much time have you spent on testing; how much time have you spent on code reviews?
  Would you increase or decrease the amount of time spent on each, and why?
  What issues (bugs, invalid assumptions, etc.) did the peer-review process reveal?
  What would you change to identify and address issue earlier in the future?

• Planning and estimates:
  Briefly contrast what you ended up doing with your original plan and estimates.
  For example, your weekly progress reports and the version control logs are
  a good starting point for determining how each member has actually spent
  their time and how long it took to implement each feature -- these may be
  very different from your original estimates. You will not be graded on your
  original estimates, nor on whether your overall development process matches
  the one described in your original specification.