CSE 403

Home

Classwork

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

Administration

Syllabus Grading Academic Conduct Accommodations

Communication

Forum Wiki Email archives

CSE 403, Spring 2014
Assignment #9: Final Release

Due: Wednesday, June 4, 2014 by 23:00
Turnin: via your repository
Demos: during the final exam period on Monday, June 9, 2014 at 8:30 am
Reflection writeup: due individually, by 23:00 on Sunday June 8; via Catalyst

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.

Deliverables

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.)

GeoPost
Third parties can prepare sets of pins that users can add to their map by entering a URL into GeoPost. This URL must return pin data in some serialized format (e.g. JSON). These pins are displayed using a separate color, and can be filtered using the top-right menu. These pins behave in a similar way to other pins (can only be viewed within a certain radius) but do not contribute to a user's statistics and are not perminantly unlocked. In fact, no permanent data about these pins are stored - they persist for the duration of the app's runtime and are forgotten once the app is restarted. An example use of this feature would be for UW to prepare an unordered walking tour of the Seattle campus for prospective students.
LineUp
Student health services want to open an anonymous queue for their new mental health clinic's drop-in hours, but LineUp doesn't meet the confidentiality and privacy needs of their clients. Add the following features:
  • A scheme that allows queue manager to verify an anonymous user's position in the queue.
  • Allow anonymous users to join a queue while using the popular browser feature "private browsing mode".
  • Allow specific queues to be protected by a pin code or some other shared secret.
  • Allow specific queues to be configured so that they don't reveal enqueued users' identities.
OneDrinkAway
Users love using the app, and want to share their discoveries with their friends. However, they often become so joyous in the late hours of the night that they forget what exactly they drank, and thus can't share their find on Facebook. Add support for writing persistent, user-specific notes on a drink that can be shared through Facebook or Twitter with friends.
Lattice
Let users save a meal so that they can come back to it. A meal should be immutable; that is, if I have saved a meal with recipe A and someone edits recipe A, my meal should be based on the version of recipe A that I saved.
AgreeMates!
You realize that many users won't use your applications unless there are more protections on how other users create bills and chores (to prevent, for example, one user maliciously entering incorrect details of a bill without the verification of others). From now on, every item that a user creates that assigns responsibility to another user must be reviewed and approved by every other user before it becomes 'official'.
TeamPlayer
You realize that many users won't use your applications unless there are more protections on how other users create bills, tasks, and groups involving them (to prevent, for example, one user maliciously billing another). From now on, every item that a user creates involving another user must be reviewed and approved by every other user before it becomes 'official'.
Note 2 Flash
Support the generation of several flash cards from a 3-associative fact. Some users want to be able to associate multiple flash cards with a single "fact" that consists of multiple factoids. For example, a student of Japanese may want to memorize associations among a word's kanji characters, its phonetic spelling, and an english definition. Upon entering the fact, the software creates 6 flashcards to test memorization the triangular association (meaning to kanji, kanji to phonetic, phonetic to meaning, and the reverse of each). Also support explicitly omitting some associations, such as phonetic-to-meaning.
PocketPickup
For some reason, you can no longer use Parse (due to load/space constraints, costs, legal, etc.). Replace Parse with a solution of your own implementation.

Demo

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!