Architecture/Module Specifications/Design
As has been discussed in class, you have substantial flexibility in
choosing the specific form for the content of your deliverables. Below
is a list of items that should be included in your third deliverable.
Due Date
TBD.
Document Contents
Introduction
Expand your introduction to discuss your specific approaches to the
design of the system.
Understanding
This will basically be the same as in your original document. Make sure
it describes what steps or actions you took to understand each technology
or software. If you make changes to this section, add text describing why
the change was necessary, and why it more accurately reflects your new
understanding. If your understanding hasn't changed, then this section does
not need to be different.
Project Plan
This will be an iterative expansion of your previous submission. Expand
your project plan to represent how you have accomplished the work so far.
Expand your task network or work breakdown structure to the level of detail
needed to complete this task. Based on the work you have done, revise your
estimates on how much your team can accomplish and deliver. If you make
changes, add text describing why the change was necessary or why it will
improve the ability of your team to accomplish the work you have proposed.
Requirements
This will basically be the same as in your previous document. If any
requirements are changed, added or deleted, make this explicit. Describe
why the requirement was changed/added/deleted and by whom ( customer, developer,
etc.). Again make sure your requirements meet the objectives of completeness,
understandbility, utility, no ambiguity, consistency. If your requirements
have not changed, then this section may be identical to what you submitted
earlier.
Architecture/Module Specifications
- Architecture Overview
- Architectural Style
What style of architecture did you adopt? Provide a reference to a
defining document.
- 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, or an OS process view)
- Component Narrative -- what each subsystem means
- Major Limitations on the Current Design
- Modules/Objectives
- List of Objects within your system
- For each module/object, provide a Class Specification
- Name
- Definition - what it is/does
- Narrative/Comment, How it works
- What are the object's APIs? E.g., using Java terminology
- public
- private
- protected
- Data - What state does it keep, what variables? Who has the
access to it?
- 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?
- Other useful diagrams : Uses, Composed-of, API's Class-Category Diagrams,
Design Class diagrams, or other useful diagrams.
- Design Object Scenario. Pick one object/ module and show the complete
implementation detail of a key mechanism.
- File Structure and Global Data - how will your objects / modules
be kept, sub-directories, Makefiles , etc.
- Requirements Cross Reference - what objects/modules satisfy what requirements?
Make a table, make a table, make it complete and consistent.
- Testing Plan - How and when will you test it?
- Demonstration Plan - How and what will you demonstrate?
5. Documentation
- List the documents you have developed during this phase of the project.
- Reference Documents
List here the major sources of information that you will be using during
the remainder of the project.