Final Release

Due: your product (via your repository) at 23:00 on December 6, 2016
Due: SRS postmortem at 23:00 on December 6, 2016 via course dropbox
Due: in-class product demo at 10:30-11:20 on December 7, 2016 in SMI 304
Due: in-class product demo at 10:30-11:20 on December 9, 2016 in SMI 304
Due: demo slides at 23:00 on December 9, 2016 via course dropbox
Due: individual retrospective at 23:00 on December 9, 2016 via course dropbox

Overview

Your final release contains the same components from your release candidate, with a few minor additions noted below.

The staff may review any materials that you submitted at any time during the project. This means that you could get penalized again for problems that were noted in earlier milestones but have not been fixed in the final release.

You may make improvements to your release candidate, if you noticed problems worth fixing in the meanwhile. You do not have to tell the staff which problems you fixed. Fixing a problem is usually, but not always, the right thing to do: your goal is high quality, and fixing a bug removes a defect, but has the chance to introduce new defects. So fixing very minor issues that might have significant impact may not be worthwhile at this stage. Fixing problems that are unlikely to impact the rest of the project (this should be most problems, if your software is well-designed!) is still worthwhile.

Deliverables

There are four deliverables for this assignment:

your product (via your repository),
one 2-page group document,
one group demo and slides, and
one 1-2 page individual document.

All documents and slides should be in PDF format and submitted via the course dropbox.

Requirements and schedule postmortem

First, update your SRS schedule. In your original SRS, you submitted an approximate schedule for how you thought your team would spend its time. Update your SRS with a new schedule showing how each member has actually spent his/her work time, which may be very different than your original estimate. In particular, describe approximately how much time you have actually spent so far on each of those features, along with estimates for how much more time you think it will take to finish any of them that went unfinished. Express all times in terms of days, and try to be accurate within a few developer-days for each feature; you may want to look at your version control logs to get a more accurate picture of how long you’ve spent working on each feature.

Then, write a postmortem document of at most 2 pages addressing the following points:

Features and Cuts. Have you completed the major functionality and features listed in your original SRS? What about the extra features and frills you listed? If not, why not? Did you add any additional features that were not listed in the SRS? 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?
Task assignments. What ended up being your team members’ current roles? What occupied the majority of each team member’s time and workload? How does this differ from your original expectations and specs? Where did you spend too much time, and why? Where did you spend too little time, and why?

Demo

You will give a final product demo / presentation during class. This presentation should be roughly 10 minutes long. Two or three of your group members must participate in the presentation, who did not participate in the previous demo or presentation in class. But as always, all members should be present. The staff would like to see:

A polished live demo of what you have accomplished and how a user interacts with your system. This will take the majority of the time, and should come first. You may use some slides in addition to the demo—do whatever you feel is appropriate.
Reflections on your experience, especially things you did not anticipate beforehand. You should use slides for this, even if you did not for the demo.

Submit the slides for your demo after your presentation.

Individual retrospective

Individually, write a 1-2 page reflection of lessons learned from the project experience. The lessons can be in terms of specifications, design, planning, teamwork, implementation, etc. Below are some questions that you might answer, though the format and specifics are up to you. You will be graded on the thoughtfulness and insight of your answers, not on what you actually believe.

What worked well? What would you do differently next time? What do you wish you had known ahead of time? What surprised you? What do you now believe that you did not believe at the beginning of the quarter, and why? What ideas taught in class do you still not believe, and why? What advice would you give future CSE 403 students? Are you happy/proud of the work you completed? If not, why, and what could you (not others) have changed so that you were happy/proud of your accomplishments? Do others on your team feel the same way you do?

Feedback to staff

Finally, the staff is very interested in your feedback about what went well in the class, and what should be done differently in the future. Creating a class is like engineering a system: tradeoffs are required, and some problems are inevitable, but feedback helps to identify which ones are most important and to fix those in the future. You’ll have an opportunity to fill out a course evaluation form, which we encourage you to complete. We also welcome additional comments in person, by email, etc. Providing us such feedback is not a requirement and will not be graded. Thanks!