Design and Planning Document
??/??/??, Version major.minor
This is a design and planning document template for CS130. Please fill out this template carefully. You are to fill in the various subsections of this document, beginning with the project name, date, and version number above. See below for an explanation of version numbers. If any sections is not applicable, put N/A in the body of the section (do not delete the section). Also, if the information has already been given in another document, refer to that document. Each team must submit a copy of this completed document to by 11:59am on April 27. Please submit a document in pdf format.
Your first version of this document is version 1.0. After that minor changes increment the minor version number (e.g., 1.1, 1.2, ...) and major changes increment the major version number and set the minor number to zero (e.g., 2.0, 3.0, ...). We will follow this convention with other documents as well.
Rev. 1.0 YYYY-MM-DD - initial version
In this section go those important facets that are not at the level of architecture, such as descriptions of critical algorithms, protocols, and key invariants. Also, wherever possible items should be linked back to your specification. Ideally, you can match up everything in the specification with where it is implemented in the design.
In this section goes a brief description of how you plan to test the system. Thought should be given to how mostly automatic testing can be carried out, so as to maximize the limited number of human hours you will have for testing your system. The purpose of this section is a reality check that your design will in fact be testable with a reasonable effort. You should specifically discuss design decisions that affect testing, and describe any test interfaces built into the system in this section. You must discuss here your plans for unit testing (approach, when are they created, when are they run), integration testing (what order), system testing (what kind), regression testing (how are you going to organize and run them).
From your design you should prepare a plan. In particular, you should list all of the tasks to be done, a preliminary assignment of tasks to people in the group, estimates of the time for each task, dependencies between tasks, and a preliminary division into builds (e.g., which features are implemented in the first build, second build, and so on). The plan should be designed to get some prototype system running as quickly as possible and then growing towards to the full project over a sequence of builds. Please pay extra attention to the dependency relationships between tasks; you will almost certainly run into the situation where one bit isn't done but everything else is waiting for it. In that case, you want to know exactly where resources need to go, and how urgent each bit is (hint: NOT proportional to its size or importance in the whole system).
The following checklist is provided to help the reviewers (and author) prepare for the review by providing a set of questions for the reviewer to answer about the design document. If the answer to any question is "no", that item should be identified as an issue at the review. The checklist is only a guideline; it should not be solely relied upon for a complete review. Reviewers may want to add their own questions to the checklist.