"Creativity can solve almost any problem. The creative act, the defeat of habit by originality, overcomes everything." -- George Lois
|
Management Tips
|
{Project Name}
Module Design
{Module Name}
Remove italicized comments within this template from the final document
INDEX
CONTACT & DISTRIBUTION
REVISION HISTORY
Date of Revision |
Revised by |
Description of Revision |
Affected Modules |
|
|
|
|
QUALITY CONTROL
Development MethodologyFor the
purposes of this project, we are using a simplified Project Life Cycle, the
details of which can be found at www.kuhnllc.com.
Change ControlDetail the change
control plan in two contexts:
- The context of changes to the SPECIFICATIONS and DESIGN. Strongly discourage changes to the specifications and design. Encourage up-front thinking and you will be better able to maintain project focus as it proceeds.
- The context of change control for documentation, source, and
resources. List how revision control will be accomplished, where the
revision control is located, who has access, etc.
Audit PlanHow do we know we did a good
job? Testing and Peer Review should be addressed here. Reference
previous documentation via hypertext link.
MODULE DESIGN
Functional RequirementsA
statement of the module purpose with a list of functions the module must
perform. List requirements for this module only. Principles to remember are
that individual modules should be cohesive and loosely coupled.
Cohesive means that the module is designed to do one job well. Loosely
coupled means that interfaces are few and no assumptions are made.
Environment
PLATFORMIndicate the platform on which this
module resides.
LANGUAGE/TOOLSIndicate the
programming language and any specific development tools used to create and
compile this module.
LIBRARIESIndicate any programming
libraries required by this module.
EXTERNAL CONDITIONSList any
external conditions that are not listed in the System Design or that apply
only to this module.
PROCESS DEPENDENCIESList any
processes that must be active when this module executes.
OUTPUT QUEUESList any required
output queues here.
PATH REQUIREMENTSSpecify whether
any assumptions are made concerning the locations of information, required
path settings, etc.
Inputs/Outputs
PARAMETERSList parameters and data types,
and indicate desired function. This info will be used to build the
help switch info for interactive modules.
EXTERNAL VARIABLESList all
external variables to be used in this module. List their names, data types,
and usage (In/Out/Both)
FILES / TABLESList all files and
data tables to be used in this module.
File/Table Name |
Usage (Input/Output/Update) |
Index / Path |
Database |
|
|
|
|
OTHER OBJECTSList anything important
that I forgot.
SCREEN LAYOUTSThis should be a
graphical representation of the screen(s) or window(s), if applicable.
PROGRAM MESSAGESList all
messages, error or other type, used or issued by this module to other
modules, users or applications. Do not include system generated
error messages.
REPORT LAYOUTSThis should also be a
graphical representation of the report. Fields should be labeled and
described in a key.
Process Specifications
FUNCTIONAL
REPRESENTATIONPossible entries here:
- Flowchart
- Data Flow Diagram
- Graphically depict all components of the module and their
relationships in a hierarchical format following guidelines presented in
Hoskyns MADP course. (basically it's an organization chart depicting
functions instead of people).
- Whatever creative method that does the trick and concisely gives a
visual overview of what this thing does.
PSEUDOCODEInclude a functional outline or
pseudocode or action diagram if it isn't too repetitious. You may
want to pseudocode only those functions that aren't immediately obvious from
looking at the Functional Representation.
CALLING & CALLED
MODULES
- List all modules that will call this module with entry parameters,
if any.
- List all modules that will be called by this module and any
necessary parameters to pass.
- Describe data that will populate parameters.
ERROR HANDLINGList all internal
error handling processes or subroutines. Reference external error
handlers.
PROGRAM AUDIT TRAILList
procedures and checkpoints to be used to verify program results. Describe
any logging functions performed by the module.
Help TextSpecify where the help text
resides. An exhibit can be used to show the text and how it will be
displayed. Depending on how the project is structured, "Help" may be a
seperate module. If so, you still should create suggested help
information so that it can be catalogued and packaged with the remainder of
the help system. The rest of this document will be important for the
same reason.
UNIT TEST PLAN
Data RequirementsMake sure enough data is included in test files to trigger every condition that must be tested, and that there is a sufficient variety of legal parameters and external variables be indicated for the same reason. You'll want to include known invalid input to test error handling.
Test ScriptProvide a script that can be
used to test this particular module. Expected results are entered when
the test is designed. Actual results are filled in when the module is
tested.
Step |
Action |
Input Data |
Expected Result |
Actual Result |
# |
|
|
|
|
Unit Test ControlSpecify any
controls or features to be applied to the unit test environment
specifically.
| Home | About Us | Clients | Project Management Resources | Tools & Templates | Links |
|
|
|