Robustness (20): At full credit, your app is bulletproof. All features work as intended. User input is either constrained to only legal choices or is handled gracefully, no matter what the user does.
Feature Set (20): Your app supports an array of features appropriate to a modern implementation. This may include (but is not limited to) support for network-based interaction, user configuration, the ability to save data and recover it at a later time. This is a subjective measure, of course, and I'll reserve the right to judge what constitutes a "complete" set. In all cases, though, remember that nonexistence is better than broken. Put another way, a feature that does not work cannot be considered a feature.
Ease of Use (10):
Separation of Concerns (15): Your code is organized into packages, classes, and methods that clearly reflect the logical structure of entities in the system. The organization reflects a clean, well-thought architecture. If traditional design patterns are employed, it is clear from both code organization and documentation how each pattern is realized.
Clarity and Thoroughness of Contract Specification (10): Major methods are designed with explicit contracts, in the form of preconditions and postconditions on each method. There's a balance to be struck here between under-developed design (i.e. methods that clearly need contracts lack them) and over-developed (often, you'll write methods that are obviously correct, and adding contract checks to every one of these is an unnecessary burden).
In a similar spirit, all classes are designed with attention to the class's structural invariant, and in each case, these invariants are implemented as methods that facilitate runtime checking.
Testing is an artifact of the finished product, which is to say that I expect your tests to be implemented in a way that facilitates automating this process. You are strongly encouraged to use JUnit (or a comparable framework, for those of you not developing in Java), but if you want to roll your own test harnesses, that's okay (albeit a lot of extra work).
Testing should be done with attention to appropriate coverage of the possible test cases. If you miss some (and you will), that isn't going to hurt the assessment. What I want to see is that you've thought about this and that you've incorporated continual testing into your development process.
The testing process should include pre and post-condition checks, along with structural invariant checks. As we discussed several times in class, you can do this in a number of ways: the general spirit is to have something that is easy to deploy in a continual fashion during development and easy to remove from the finished release. We studied techniques for doing this with the insertion of assert statements, which are disabled in the JVM by default. There are equivalent constructs in many other languages.
System Architecture & Design Documentation: You should include in the technical documentation a high-level description of the organization of the important entities (typically, this is at the level of class definitions). With more time, we would have learned to express such ideas in UML (unified modeling language), a common notation for documenting designs. I won't expect you to use that here, of course, but you should include some presentation of the organization, explaining how classes depend on each other, which classes are associated with various conceptual "groups" (in software architecture, these are often called "layers")
Technical Documentation: This refers primarily to the practice of adequately documenting the non-obvious areas of your source code with embedded comments. There's a balance between too much and too little commenting, of course. The standard to aim for here is that you should be able to pick up your work after being away from it for a year and be up to speed within a couple of hours.
User Documentation: This can come in many forms, from a printed user manual to online help. The main expectation here is that all of the major user tasks in your system should be explained here.