Due: Friday, May 15, by 8:00pm
Turnin: all information related to your project must appear in your
repository. Furthermore, users/developers should be able to find it; they
might do so via README files, your website, etc.
Demos: Wednesday and Thursday, May 20 and 21, in class
CS Rocks Inc. is excited to see the progress you're making on their product. This assignment is a milestone delivery to the company, in exchange for which they'll give you a milestone payment (points towards your GPA, in fact!). While they don't expect a full-featured product, all the major components of the product should in place and integrated at a basic level. (For example, in the case of a web application, a user command invoked from the front end should be able to return data from the back end. For other applications, a use case that touches all the major parts of your system should be operational.)
They also would like to see that your team is using good software engineering practices for your work, assuring them that the project will be completed on time, with good quality, and in a good position to evolve with their needs.
For the most part, you will create another release of your product, following the general guidelines outlined for the previous milestone. (You may want to look at those guidelines again, since some of them have been updated/clarified since that assignment.)
It is permitted for some functionality to be missing, but the system should already be useful, even if in a limited way. A substantial number of use cases should work — as a general rule of thumb, about half of the use cases that the system will eventually support. (Your grade won't depend on the exact fraction.) The documentation must reflect which commands or other features are working.
Your product need not necessarily be 100% bug-free to receive full credit. Any known bugs should be documented, and a user testing the system should not encounter a non-trivial number of bugs that are unlisted in your bug-tracking system. Your system should be robust: errors should be gracefully handled as much as possible.
Your software should be supported by tests, including at least the following:
Don't forget that tests need documentation, just like other code.
Part of your grade is dependent on participation by all members of your group. For example, your version control repository should show roughly equal amounts of effort (possibly of different varieties).
In addition to the release itself, you will submit some other information that software engineers usually produce for use by management. (The distributed software is only part of their output.) For this assignment, that includes a description of any changes to your requirements or specification documents. You can do so by marking up a copy, by use of a word processor's change bars, by writing a brief description of the changes, or in any other way that you consider appropriate. We are interested in content changes, not wordsmithing and polish. For each substantial change, please add a note discussing the tradeoffs that were involved. These tradeoffs are usually captured in a design document (sometimes called a "design rationale") that is made available to developers.
Finally, please describe how your software design utilizes one design pattern or principle discussed in class. Identify the pattern/principle and the code to which it applies. Use a meaningful, not a trivial, example. For the purposes of grading, we want a list somewhere easy for the TAs to find, in the developer documentation. That list allowed to point to the source code (makes sense for a pattern that is expressed entirely within a single file) or elsewhere, such as in the developer documentation or other overview materials (may make sense for a pattern that spans files or appears many places).