Due: your product by Tuesday, Mar 08, 2016, 23:00, via your repository Due: SRS postmortem by Tuesday, Mar 08, 2016, 23:00, via the course dropbox Due: product demo in class on Wednesday, Mar 09, and Friday, Mar 11, 2016 Due: individual retrospective by Friday, Mar 11, 2016, 23:00, via the course dropbox
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.
There are three deliverables for this assignment:
All documents and slides should be in PDF format and submitted via the course dropbox.
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 approximately 2 pages addressing the following points.
You will give a demo / presentation during class on Wednesday, Mar 09, and Friday, Mar 11. This is your opportunity to show off your deliverable and impress your customer in person. This presentation should be roughly 10-15 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, ready to share the commendations. You do not have to turn in your slides ahead of time, but please provide them to the course staff after your presentation, via the course dropbox. The customer would like to see, in particular:
You do not need to submit the slides ahead of time, but you are permitted to show them to the staff to ask for feedback, if you want to.
Individually: Write 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?
Finally, the staff is also 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!