CSE 403



Calendar Lectures Assignments Turn-in Projects Software Tools Resources Old exams


Syllabus Grading Academic Conduct Accommodations


Forum Wiki Email archives

CSE 403, Spring 2011
Assignment #9: Final Release

Due: Wednesday, June 1, by 11:59pm
Turnin: via your repository
Demos: in class on Monday, June 6 at 8:30 am
Reflection writeup: due individually, by 11:59pm on Sunday June 5; turnin here

Release day is here! Your customers can't wait to receive the delivery of their product. This assignment is the final release. Your adoring fans, and fame and fortune, await. Full milestone payment will be given for a product that meets their requirements including reliability, extensibility, and maintainability. Evidence of good software practices during development is sure to convince them of these features.

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 your grade could go up, if you have fixed problems that were noted earlier. It also means that you could get penalized again, for being appraised of them but not fixing them, or if other problems are noticed.

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 four deliverables:

Extensibility exercise

As a measure of how well designed and extensible your system is, identify exactly what components must change, and how, to accommodate the below design changes. There should be enough detail for a competent developer to begin making the changes without having to make any significant design decisions. (Write this as a section of your design documentation.)

Cloud Composer
Book Sharing
Team Jtacck


You will give a demo / presentation during the final exam period, on Monday June 6 at 8:30am. This is your opportunity to show off your deliverable and impress your customer in person. This presentation should be roughly 10-15 minutes long. 2 or 3 of your group members must participate in the presentation, who did not participate in the previous demo (or in your architecture re-presentation, if applicable) 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. The customer would like to see, in particular:

  1. Working functionality: a 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.
  2. 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.

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.

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 approximately 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?

Individual retrospective

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 (some of which are not immediately obvious to someone who has not deeply studied the domain), 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. You may provide it before or after grades have been submitted. We find non-anonymous feedback much more useful, but you may submit it anonymously if you prefer. Thanks!