Due: Friday, May 29, by 8:00pm
Turnin: via your repository
A release candidate is a version of your system that you believe is complete in every way. No bugs remain that mar the user experience. The user manual (and/or online help) is complete and accurate, and makes a positive difference for users. The system is packaged in a way that permits a user to easily begin using it, or a developer to easily begin extending it. The requirements and design are accurately documented (in their final form: all documents have been updated as appropriate). The code is commented: both its overall structure, and individual design patterns, algorithms, and procedures. Automated tests (both unit tests and integration/system tests) cover most or all of your system, and the most important or error-prone modules have extra tests and/or correctness arguments.
In other words, you would be willing to release your project as is. (But you call this a "release candidate" just in case you learn of some problem at the last moment. On a well-run project, there won't be anything.)
Since all features were complete last week, the release candidate is an opportunity to refactor your implementation and to fix bugs, and for you to evaluate whether your system meets the needs of users. To do so, you will perform code reviews and user tests.
In addition to testing, code reviews are an excellent way to identify weaknesses in your implementation. Please choose an important part of your implementation, or one whose quality you are particularly concerned about. (You will be graded down if you choose a trivial or uninteresting part of your code.) Then, review that code and improve the code according to the results of the review. Also write a brief (one-page) description of what you learned from the review and what you changed. Be sure to indicate what code was reviewed. We will examine that code (and possibly code related to it).
For your user tests, you must use 5 people, none of whom are CSE majors or have a career in computing. Furthermore, your users should have no previous experience with your system. In other words, we want you to test your system on real users (like those your customers will be), not on people like yourselves. You may fix problems in between the user, so start early! Each user test should last about one hour. You can ask the users to first perform some tasks of your choosing (much like you did for the paper prototype assignment), but you should also leave time for the user to explore your application. The rules of a user evaluation are like those for the paper prototype:
Write a 2-page description of your user evaluation. It should describe your design (what you asked users to do, any other details); who the people were and their background; a description of what occurred; what you learned (about your product, and also about doing a user evaluation); and what you changed as a result. As always, this should go in your repository so that future developers can benefit from it.