CS169 Software Engineering

March 15, 2000
Professor Doug Tygar

Design Phase Review

This handout defines the deliverables for the Design Phase Review, which outlines the design of the project. There are two primary deliverables: a 40-minute presentation on the idea (followed by 20 minutes of discussion) and a document that covers the module block diagram and the APIs.

The writeup is due Monday, April 5. Presentations will be shortly thereafter -- there will a sign-up sheet outside of 621 Soda. All group members must attend the review, and all must be prepared to answer questions, but not all must present material during the presentation. Everyone is expected to contribute to the content of the presentation. The goal is to nail down the design and schedule as much as possible. It is useful to be explicit about possible features the product will not have, if you are removing them since the Concept Phase Review.

I. The Design Doc
The design doc should contain each of the following:

• One-page module block diagram (MBD) with all major components of the project.
• For each line connecting blocks in the diagram, a one-page (maximum) summary of the interface for that line (the API). Typically, there will be 10-20 of these pages, but each one can be simple.
• One-page schedule that ends with a beta on May 8th. (The actual beta date will vary.) It should at least include each block in the MBD, and should include key dates such as integration of the pieces (there can be multiple integration dates), code freeze, and testing.

II. Presentation

• The MBD slide
• Trace the typical use of the product through the MDB, including start-up and exit.(1-2 slides)
• 3-4 slides on key modules (what they do)
• 3-4 slides on key APIs
• Status of the implementation to date (1 slide)
• Changes in the feature list (1-slide, more if needed)
• Schedule for completing the project (1-slide)
• Basic implementation plan: one-slide summary of how you will implement this project. Typically covers the language and tools used, and key components that you intend to take off the shelf.
• You may also include one or two key issues that you would like input on. For these cases, try to come up with explicit alternatives rather than open-ended questions.