Due: Friday, May 22, by 8:00pm
Turnin: via your repository
This release of your system builds on the beta release: now all major functionality should be present, and a user should be able to perform any of the tasks that are part of your requirements.
It is permissible for some bugs to remain in your product, but they should be few and should not seriously affect usability.
The user documentation should be complete or nearly complete.
All requirements and design information should be up to date (including any UML diagrams). You must clearly indicate any changes since the beta release. (Do this in a manner that is up to you.)
You will be evaluated on the thoroughness of your tests, which should be in a solid and essentially complete state. Furthermore, it must be apparent to someone reading them that they are sufficiently complete. (That is, like any other part of your code, they must be comprehensible!) In addition to (not instead of) their documentation, you may include information such as how to run a coverage tool in order to provide evidence of their quality.
The code should be well-written and well-documented, and use good style.
In addition to validating your code via testing, choose one particularly important part of your system on which to perform reasoning. (You will be graded down if you choose something trivial, where reasoning is not appropriate or necessary. A reasonable choice would be someplace where violations of the rep invariant have already caused problems in the past.) You should have already written a representation invariant for it. (Even if it is not a class in an object-oriented programming language, you can still write a rep invariant; for instance, many properties should be true of the records in a database or of data structures in any programming language.) Argue that the representation invariant is always satisfied.
Hint: We strongly recommend that before any public release (namely, the weekly milestones), you manually test any instructions that appear in your documentation. This is crucial in detecting any problems in what you have written down. If the instructions are easy to follow, this will not be an odious responsibility.