kuhnllc tools banner 

 kuhnllc templates banner
"Creativity can solve almost any problem. The creative act, the defeat of habit by originality, overcomes everything."
-- George Lois

Management Tips
Project Methodology
Project Close Lessons Learned
Project Planning
Project Management Templates
Project Manager Duties
Project Risk Management

{Project Name}

Module Design

{Module Name}

Remove italicized comments within this template from the final document

INDEX

CONTACT & DISTRIBUTION

    Prepared by:

    Include the name of the document's author, author's telephone and email address.

    Contributors:

    List contributors to this document, and the nature of their contributions.

    Primary Contact:

    All questions and comments about the project should be addressed to the primary contact.  It will be the responsibility of the primary contact to answer or direct the questions or comments to the appropriate parties.

    The primary contact is usually the Project Leader.  Include email link.

    Distribution:

    List the mailing list, Usenet group, web address, or other method of intended distribution.

REVISION HISTORY

Date of Revision Revised by Description of Revision Affected Modules

QUALITY CONTROL

Development Methodology

For 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 Control

Detail the change control plan in two contexts:
  1. 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.
  2. 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 Plan

How 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 Requirements

    A 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

      PLATFORM

      Indicate the platform on which this module resides.

      LANGUAGE/TOOLS

      Indicate the programming language and any specific development tools used to create and compile this module.

      LIBRARIES

      Indicate any programming libraries required by this module.

      EXTERNAL CONDITIONS

      List any external conditions that are not listed in the System Design or that apply only to this module.

      PROCESS DEPENDENCIES

      List any processes that must be active when this module executes.

      OUTPUT QUEUES

      List any required output queues here.

      PATH REQUIREMENTS

      Specify whether any assumptions are made concerning the locations of information, required path settings, etc.

    Inputs/Outputs

      PARAMETERS

      List parameters and data types, and indicate desired function.  This info will be used to build the help switch info for interactive modules.

      EXTERNAL VARIABLES

      List all external variables to be used in this module. List their names, data types, and usage (In/Out/Both)

      FILES / TABLES

      List all files and data tables to be used in this module.
      File/Table Name Usage (Input/Output/Update) Index / Path Database

      OTHER OBJECTS

      List anything important that I forgot.

      SCREEN LAYOUTS

      This should be a graphical representation of the screen(s) or window(s), if applicable.

      PROGRAM MESSAGES

      List 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 LAYOUTS

      This should also be a graphical representation of the report. Fields should be labeled and described in a key.

    Process Specifications

      FUNCTIONAL REPRESENTATION

      Possible entries here:
      1. Flowchart
      2. Data Flow Diagram
      3. 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).
      4. Whatever creative method that does the trick and concisely gives a visual overview of what this thing does.

      PSEUDOCODE

      Include 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

      1. List all modules that will call this module with entry parameters, if any.
      2. List all modules that will be called by this module and any necessary parameters to pass.
      3. Describe data that will populate parameters.

      ERROR HANDLING

      List all internal error handling processes or subroutines. Reference external error handlers.

      PROGRAM AUDIT TRAIL

      List procedures and checkpoints to be used to verify program results. Describe any logging functions performed by the module.

    Help Text

    Specify 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 Requirements

    Make 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 Script

    Provide 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 Control

    Specify any controls or features to be applied to the unit test environment specifically.

| Home | About Us | Clients | Project Management Resources | Tools & Templates | Links |