Due:
URL to your repository at
23:00 on November 11, 2016
via course dropbox
Due:
in-class product demo at
10:30-11:20 on November 14, 2016
in SMI 304
Due:
in-class product demo at
10:30-11:20 on November 16, 2016
in SMI 304
For the Beta Release milestone, all the major components of your product should be in place and integrated at a basic level. The staff is expecting to see a testable, usable product that provides an adequate amount of functionality to get a feel for the system and how it will work. At least 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.
We also want to see that your team is using good software engineering practices, ensuring that the project will be completed on time and with good quality.
Your main deliverable is a beta release of your product, following the general guidelines outlined for the previous milestone. The deliverable will consist of a single URL pointing to your source repository, submitted via the course dropbox. All information related to your project must appear in the repository. Furthermore, users/developers should be able to find this information via README files, your website, etc.
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 (via your repository) 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 and/or design specification. You should do so by appending a brief description of the changes to your SRS/SDS documents. This description should be placed at the end of the documents, in a separate section entitled “Design changes and rationale”. 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.
Finally, update your developer documentation to 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, this description must be clearly marked and easy for the TAs to find. It 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 10 minutes. You will have a slot of 12 minutes but should leave the rest of the time for setup and for questions either during or after your demo.
You will use your own computer(s) for the demo. We strongly recommend that you show up early to class to ensure that your laptop connects properly to the projector, etc. You don’t want to waste time 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.