Due in Class/Discussion Two Weeks from your Prototype Demonstration Date

Assignment Requirements

Purpose and Content

The design document should also be an evolving document, or a living document.  You should begin by documenting the conceptual model of your system.  As you continue working, this model will be refined to include more detail, and some things will change.  By the time you turn in your design document, it should contain a reasonably accurate description of your final system.  You will also be asked to turn in a final version of the document at the end of the quarter that will include changes made to the requirements and design during the later stages of implementation.

The design document will consist of the following sections.  Sections 1-4 and 8-13 are updates of what you turned in for the Requirements Document.  The remaining sections, 5-7 and 14, are new to the Design Document.

1. Title Page
2. Summary
3. Glossary
4. Use Cases, Scenarios, Mock-up's

(whichever you focused on in Assignment 2)
 
 
 
5. Architecture Overview
• Architectural Style

What style of architecture did you adopt? Provide a reference to a defining document.

Shaw and Garlan have identified the following list of architectural styles:

  1.Data Flow Style
        Batch Sequential
        Pipes and Filters
  2.Call and Return Style
        Main Program and Subroutines
        Hierarchical layers
        Object-oriented (client/server)
  3.Independent Components
        Communicating processes
        Event systems
  4.Virtual Machines
        Rule-based systems
        Interpreters
  5.Data-Centered Systems
        Transactional Database Systems
        Blackboard Systems
 

• System Architecture Overview

This is the place for your "one great diagram" that shows how your system is built. You might want to use more than one diagram, to show, e.g., some different abstractions of the design (such as a data flow view, a layers of abstraction view, an object view, or an OS process view)
• Subsystem Narrative

What each subsystem means
• Major limitations on the current design
6. Modules Specification
• List of Modules within your system
• For each module, provide a Module Specification
• Name
• Definition/Purpose - what it is/does
• Narrative/Comment - how it works
• What are the interfaces or APIs? E.g., using Java terminology

public
private
protected
• Data - What state does it keep, what variables?
• Access - Who has access to the module/object/data?
• How does it fit into the inheritance/with/uses heirarchy?
• Constraints - what constraints are there for this object/module?
• Cardinality - How many will there be?
7. Team Specific diagrams

See your TA but likely notations include Entity-Relationship (ER) Diagrams for Database Projects, UML Sequence Diagrams for the Error Injection Projects
8. Deliverables
9. Delivery Platform
10. Terms and Authorization
11. Development Platform.
12. Milestones and Effort

Provide milestones and effort in a tabular or bulleted form. Show former estimates of time next to current estimates (or actual time in the case of achieved milestones). This will enable you to recognize shortcomings of your own ability to estimate and the difficulty in general of estimations.
13. Acceptance Test Plan

To be more specific in the update of your Acceptance Test Plan, create a script (2-4 pages) of your intended final presentation. The script may be in the form of an outline or bulleted list. In some cases, it will be close to your prototype demonstration. It should tell a choherent and convincing story that will make your client enthusiastic about signing off on your project!
You may refer to figures in other parts of your document such as use cases and / or mock-up's.
 
 
 
14. Unit and Integration Test Plans

Enumerate several key tests for evaluating individual modules and combinations of modules in your system.
For each test
• Test ID
• Purpose of Test
• Item(s) being tested
• Input specification or specific data being tested
• Output specification
• Expected Results or Test Oracle Mechanism
• Test environmental needs or special test procedures

ICS125 WQ00 Assignments
ICS125 WQ00
David F. Redmiles Home Page
University of California, Irvine CA 92717-3425