Project Name

Design and Planning Document

??/??/04, Version major.minor

Instructions

This is a design and planning document template for CS169. Please fill out this template carefully. Items in italics are information that you are to fill in, 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 send a copy of this completed document to brewer@cs.berkeley.edu by 5pm on the due date. The subject line of the email message must contain only the word “proj4”.

Document Revision History:

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

System Architecture

Here you should describe the high-level architecture of your system: the major pieces and how they fit together. Use graphical notations as much as possible in preference to English sentences. For example, you could describe the architecture using UML, or a finite automaton, if your system lends itself to these descriptions. Try to use standard architectural elements (e.g., pipe-and-filter, client-server, event-based). Make sure to describe the major interfaces between components.

Design Details

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.

Testing plan

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)

Plan

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).

Checklist

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.

Y N CONTENT

___ ___ Are all the interfaces to the system specified in detail?

___ ___ Are acceptable solution alternatives and their trade-offs specified?

___ ___ Are you satisfied with all parts of the document?

___ ___ Do you believe all parts are possible to implement?

___ ___ Are all parts of the document in agreement with the product

requirements?

___ ___ Is there risk associated with the proposed design? Is it discussed in the document?

___ ___ Will the goal for each type of testing be met with the testing that is described?

___ ___ Are the testing activities scheduled at the appropriate times?

___ ___ Is each part of the document in agreement with all other

parts?

COMPLETENESS

___ ___ Have alternative designs been considered and documented?

___ ___ Are the limitations of the specified implementation sufficiently documented?

___ ___ Are dependencies and assumptions thoroughly documented?

___ ___ Where information isn't available before review, are the areas of incompleteness specified?

___ ___ Are all the testing stages covered?

___ ___ Is the regression test strategy covered?

___ ___ Are there high-level validation tests necessary and covered (performance, security, etc.)?

CLARITY

___ ___ Is the solution at a fairly consistent and appropriate level of

detail?

___ ___ Is the solution clear enough to be turned over to an independent

group for implementation and still be understood?

___ ___ Is the control flow and the data flow clear?

___ ___ Is each requirement (or feature list item) measurable (will it be possible for independent

testing to determine whether each requirement has been satisfied)?

___ ___ Is the test strategy for each type of testing clearly described?

___ ___ Are the test report requirements clearly described?

___ ___ Are all items clear and not ambiguous? (Minor document

readability issues should be handled off-line, not in the review,