Document Sample
Documentation Powered By Docstoc
Documentation is something that a few
   people like to write.
It also seems that lot of users do not want to
   bother reading it.
However documentation is extremely
   important in answering questions and
   solving problems.
How we define Documentation?

          It is a term used to describe all
the instructions ,programs, narratives or
virtually anything written about an
information system.
            Changing Roles of

During System Design    After Installation
It is the evolving product Acts as a basis for
developed by the design making changes to the
team and users.            system
Significance of Documentation
 A good documentation serves to reduce
  the conflict between users and IS Dept
  since a well documented system is easier
  for users to understand.
 Thorough documentation means that
  adequate reference is available when
  problems arise and this information helps
  users learn how to solve their problems
  with the system.
          Uses of CASE tools in
• If we use a CASE tool much of the
  documentation needed to describe a project will
  come from the CASE tool.
• One of the main benefits for using a CASE tool
  is the single, authoritative information it provides
  regarding the system which can be later used for
  creating different type of documentation and for
  reference in making changes and
  enhancements to the system.
Upper CASE             Lower CASE
Diagramming Tools      Code Generator
Screen and Report      Code Restructures
Repository (Huge
database for storing
everything about a
system (database
design, DFD etc)
Different Type of Documentation

      Design Documentation

      User Training Documentation

      Operation Documentation

      User Reference Documentation
          Design Documentation
1. Aids communication among those on a design
2. Provide control over design ie,provide a record of
   what has been developed and and about changes.
3. Control is also the ability to retrieve past test
   runs and old versions of programs or files. This
   Documentation builds an excellent database for
   building future estimates of how long it will take
   to develop a similar system.
What can be the contents of Design
•   Table of Contents (Preferably in a Tree
•   Survey
•   Feasibility Study
•   Existing Systems Specification
• Specifications for new System
         3.File Version
         4.Logic Specification
         5.program modules in Hierarchical Manner
         6.Actual Programs
                 6.1Program Outline
                 6.2Cross reference for variables
                 6.4Module Interface
6.5Variable Identifier Library (Keeping
 a variable identifier library is crucial in
 database management applications.
 The same piece of data should be
 known by the same identifier or
 variable name in all programs.

For E.g. It is confusing to have
 in one program and “Current Balance”
 in other program.
Standardizing on one name throughout
 the system makes things simpler.

Someone from design team should be
 designated as librarian /DBA and
 he/she should distribute list of
 identifiers to programmers. Identifiers
 should be highly descriptive of entity
 they represent. When programmers
 need to add new identifiers they
 should check the existing list
            Design of test procedures
            Test Data description
            Description of how the test run
should be carried out and what are the
expected results.
•  Manual procedure
                    manual procedure surrounding
   the system should be specified. What volume
   of activity will there be? How much time is
   required to perform manual tasks?
1. Flowcharts
2. Narratives
3. Error Controls (Centralization of the record of
   error messages and error controls promotes
   coordination among team member work.)
• The Work Plan
• The Progress Record (These items
  provide valuable data for post-
  implementation audits and for developing
  benchmarks for system design activities in
  the Org.)
    User Training Documentation
• Training Documentation prepares the user
  for the implementation and the eventual use
  of the system.
• User Training Documentation is used to
  bridge the gap between the old, existing
  procedures and those required for the new
    Who should develop User Training
   This should be developed by the user members
    of the design team in conjunction with other
    users of the org.
         Contents of User Training
   Overview of the system
   Menu Tree (for an interactive application the
    user can often learn a great deal about the
    system by looking at a menu of options offered
    by the system.)
   Input transactions and the files necessary to
    produce the desired output.
    Output documentation (Focus on key
    decisions and reports)
Transitional Considerations :Testing,
  Conversion (This section deals with
  the changeover of the system. During
  gradual implementation of the system
  the process will slowly evolve from the
  current manual procedures to a fully
  computerized approach)
For e.g.: During the first days of
  implementation, the data files will not
  have sufficient data to do the expected
  processing, as the data will be
  developed over time.
    Who should perform the training?
   If the users had designed the system and had a
    significant say in its development, they have
    reviewed all relevant parts of the system
    during development, they should be well
    prepared for training.
   If new problems arise in the training the user
    group are expected to solve them.
   Training should be coordinated by user
    members of the design team or by
    knowledgeable users who are not on the team.
         Operations Documentation
   Provide information on normal operating
    procedures and on how to respond to errors.
 Who should prepare Operations
Best prepared by SA and programmers and
  much of it can be derived from design
     Contents of Operations Documentation
1.    System Flowchart (Identify programs and their execution in sequence)
2.    List of programs to be run in order
3.    For each program
                 I/P required (Any special input required is to be mentioned)
                 Output produced
                 files required
                 processing narration
                 Error conditions, messages and operator responses
         (operators should know possible error conditions and            how to
      respond to them)
     machine components used
     Set up requirements
4. Details regarding the distribution and
  processing of printed output.
5.Maintenance programmer responsible for
  maintaining the routine operation of the
6 List of users responsible for process of the
7.Terminals accessing the system.
User Reference Documentation
When should we develop User
Reference Documentation?
This documentation should be
developed for user reference after
the system has become
Why User Reference
is considered to be important?
 • This information should be referred
   to by the user who has a question or
   a problem before he/she contacts IS
 • There is a tremendous amount of
   frustration when something goes
   wrong with an information system
   and user does not understand why it
   has a problems or how to fix it.
• If the documentation is of
  sufficient quality the problem can
  be solved without the help of IS
Contents of User Reference
   Table of contents
   Input documents (sample versions)
   output documents
   Processing Logic
   Error conditions and fix-ups
   List of Program and maintenance staff.
   User representative

For extremely good example of user reference
  manual see Documentation accompanies with
  packages like Word or Windows

Shared By: