Due: Friday, May 16, 2014 by 23: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: Monday and Wednesday, May 19 and 21, 2014, 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 be in place and integrated at a basic level. The customers are looking to see a significant effort to implement a testable, usable product that implements an adequate amount of functionality to get a feel for the system and how it will work. At minimum, one use case that touches all the major parts of your system should be operational. (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.) Most groups will have more than one use case 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.
Your main deliverable is a beta 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).
We expect you to be using your version control system properly, making small and numerous check-ins with descriptive commit messages to indicate what has changed. If version control appears to be an afterthought in your project (for example, if you just do a few very large check-ins at the very end that contain most all of your source code, indicating that you didn't really use the system along the way), you may not get full credit.
Any known significant bugs in your system should be documented in your bug-tracking system. A user testing the system should not encounter a non-trivial number of bugs that are unlisted in your bug-tracking system. for full credit, it should have at least one bug filed for each active developer. We expect that it will include both some bugs that have already been resolved/fixed and others that are still open. If possible, the bugs should list priority, status and a timeline to fix them.
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.)
You must submit updated System Requirements Specification (SRS) and System Design Specification and Plan (SDS) documents. You must keep these up to date throughout the quarter.
Describe any changes to your requirements or specification documents. You can do so by writing a brief description of the changes, by marking up a copy, by use of a word processor's change bars, or in any other way that you consider appropriate. We are interested in content changes (including schedule 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”; it can be incorporated in your SDS/SRS, or it can be separate) that is made available to developers.
Finally, please describe how your software design utilizes two design patterns or principles discussed in class. Identify the pattern/principle and the code to which it applies. Use meaningful, not trivial, examples. For the purposes of grading, we want a list somewhere easy for the TAs to find, in the developer documentation. That list is allowed to point to the source code (this 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 (this may make sense for a pattern that spans files or appears in many places).
Plan for your demo to last about 8 minutes. You will have a slot of 10-11 minutes but should leave the rest of the time for setup and for questions either during or after your demo.
You may use your own computer(s) for the demo. If you do so, we strongly recommend that you show up early to class to ensure that your laptop connects properly to the projector, that the document projector camera works (if you will need it), etc. You don't want to waste your time, and that of the audience, trying to get these working during your actual presentation slot.
To make your demo more realistic, it is a good idea to pre-populate any database or other data source with the sort and amount of data that a typical user would see.