Due:
code review and user testing documents at
23:00 on December 2, 2016
via course dropbox
A release candidate is a version of your system that you believe is complete in every way. No bugs remain that interfere with 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. We 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 are complete, 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, and will submit a document about each.
For this milestone, you will submit two documents via the course dropbox, as described below. Both documents should be in PDF format.
In addition to testing, code reviews are an excellent way to identify weaknesses in your implementation. Please choose one or more important parts 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, have a member of your team who has not been involved in that part of the implementation review that code. Finally, improve the code according to the results of the review.
It is generally best if the person doing the review understands the programming language that the code is written in, and you should strive to make that correct. However, code reviews can be quite productive even if the reviewer doesn’t know the programming language. The reviewer can still ensure that the overall architecture is clear, that the code is well-structured and commented, that the overall algorithms and data structures are appropriate, and so forth.
Deliverable: Write a brief (1 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). We also reserve the right to examine any code, so it is to your benefit to review and improve the code that you are most unsure about.
For your user tests, you must use 3 people, none of whom are CSE majors. Furthermore, your users should have no previous experience with your system. In other words, we want you to test your system on real users, not yourselves. You may fix problems in between the users, so start early. Each user test should last about one hour. You can ask the users to first perform some tasks of your choosing, but you should also leave time for the user to explore your application. The rules of a user evaluation are like those for paper prototypes:
Deliverable: 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.