Course project: Final release

Overview

Finalize your group project, take additional (peer-review) feedback into account, present a live demo of the final release of your system and provide a group reflection on your project experience.

Due date: Tues 12/5/23, 11:59pm PT. Submit in Canvas and GitHub as directed (check Calendar for any updates).

Set up

Work with your project group to (1) finalize your group project and (2) prepare and present a live demo of your project (3) conduct a final group reflection/retrospective.

Instructions

1. Finalize your project (50%)

• Complete the implementation of your project in your GitHub repository.

• In the top-level README.md file, specify completed features/functionality. Include the version id of this final release.

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

• This release should address the feedback from the peer review comments and issues filed. This release should reflect all the good software engineering practices discussed during the quarter and build on those initiated in your earlier releases.

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

2. Prepare and present a live in-class demo (20%)

• Create a presentation that is at most 10 minutes long and in which all members participate in some way.

• Part 1: Focus on demo'ing the final system and how a user interacts with it. This should use the majority of your time.

• Part 2: Briefly speak to your key learnings from the project.

• Save any slides used in the presentation (if applicable) as ProjectName_FinalDemo.pdf.

• Email the staff (cse403-staff@cs.washington.edu) with the name of who will be hosting the presentation, so we can send the zoom meeting link for class. When it is time to present, you can screen-share from your laptop.

3. Conduct a project retrospective (30%)

Provide a retrospective on the overall group project. Your retrospective should address and reflect on the following major components. You should include what were the main lessons learned that you would take forward to your next project.

• 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' roles the majority of the time? How does this differ from your original expectations and specifications? Did you change how you operated/interacted as a team during the quarter, to improve your delivery?

• Process and timeline: Was having a formal (vs ad hoc) software development process useful? Did you change your software development process throughout the quarter? What occupied the majority of your team'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 did you spend on testing; how much time did you spend on code reviews? Would you increase or decrease the amount of time spent on each, and why? Did you find continuous integration (CI) valuable, and why (or why not)? What issues (bugs, invalid assumptions, etc.) did the peer-review process reveal? What would you change to identify and address such issues earlier in the future?

• Planning and estimates: Briefly contrast what you ended up doing vs your original task 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 and the integration of features. These may be different from your original estimate; are there learnings?

Your project retrospective should be at most three (3) pages long. Save your retrospective as a PDF file named ProjectName_GroupRetrospective.pdf.

4. Submit and present

• Zip files for #2 and #3 together into a file named ProjectName_FinalRelease.zip and upload it to Canvas by due date.

Clarifications (posted in Ed)

• How should we respond to peer feedback?
Prioritize and address the most important items first. For others, if you won't respond to them (due to they don't align with your vision, or you don't have time and will cue them up for a future release) be sure to capture the items somewhere in your github repo (e.g., file them as an issue). Future developers will want to leverage this information.
• Do we need slides for the presentation?
The majority of your time should be on the live demo. However you also are asked to briefly speak to your key learnings from the project. You may want to use slides to act as a backdrop for this part of your presentation.
• Can you share more on the doc format of the project group retrospective?
The font and font size is up to you but please don't use anything smaller than Calibri 11pt. Single spaced is fine. You can write shorter but no longer than 3 pages. Write meaningfully - make your submission long enough to get your thoughts across. As per the assignment, we are looking for meaningful reflections and what were the main lessons learned that you would take forward to your next project.