Program Documentation

There are four main types of documentation: program documentation, system documentation, operations documentation, and user documentation. Program documentation describes program inputs, outputs, and logic. System documentation provides technical specifications and describes system functions and flow. Operations documentation contains information needed for processing and distributing output. User documentation includes instructions to help users interact with the system and must be clear, understandable, and accessible. Online documentation can range from simple text files to interactive help systems and is most commonly provided through web-based help systems, allowing users to access information online. However, online documentation also has disadvantages like lack of browsability and difficulties with navigation.

Uploaded by

Apple Sugala

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

138 views

Program Documentation

Uploaded by

Apple Sugala

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

You are on page 1/ 3

Documentation –

any communicable material that is used to describe, explain or instruct

regarding some attributes of an object, system or procedure, such as its parts, assembly,
installation, maintenance and use.

1. Program Documentation- It describes inputs, outputs, and processing logic for all
the program modules. The program documentation process starts in the system
analysis phase and continues during implementation. This documentation guides
programmers, who construct modules that are well supported by internal and
external comments and descriptions that can be understood and maintained easily.

2. System Documentation-serves as the technical specifications for the IS and how the
objectives of the IS are accomplished. Users, managers and IS owners need never
reference system documentation. System documentation provides the basis for
understanding the technical aspects of the IS when modifications are made.

 It describes each program within the IS and the entire IS itself.

 It describes the system’s functions; the way they are implemented, each program's
purpose within the entire IS with respect to the order of execution, information
passed to and from programs, and overall system flow.
 It includes data dictionary entries, data flow diagrams, object models, screen
layouts, source documents, and the systems request that initiated the project.
 Most of the system documentation is prepared during the system analysis and
system design phases.
 During systems implementation, an analyst must review system documentation to
verify that it is complete, accurate, and up-to-date, and including any changes made
during the implementation process.
3. Operations Documentation- contains all the information needed for processing and
distributing online and printed output. Operations documentation should be clear,
concise, and available online if possible.
It includes the following information −
 Program, systems analyst, programmer, and system identification.
 Scheduling information for printed output, such as report, execution frequency, and
deadlines.
 Input files, their source, output files, and their destinations.
 E-mail and report distribution lists.
 Special forms required, including online forms.
 Error and informational messages to operators and restart procedures.
 Special instructions, such as security requirements.
4. User Documentation- It includes instructions and information to the users who will
interact with the system. For example, user manuals help guides, and tutorials. User
documentation is valuable in training users and for reference purpose. It must be
clear, understandable, and readily accessible to users at all levels.
The users, system owners, analysts, and programmers, all put combined efforts to
develop a user’s guide.
User documentation should include −
 A system overview that clearly describes all major system features,
capabilities, and limitations.
 Description of source document content, preparation, processing, and,
samples.
 Overview of menu and data entry screen options, contents, and processing
instructions.
 Examples of reports that are produced regularly or available at the user’s
request, including samples.
 Security and audit trail information.
 Explanation of responsibility for specific input, output, or processing
requirements.
 Procedures for requesting changes and reporting problems.
 Examples of exceptions and error situations.
 Frequently asked questions (FAQs).
 Explanation of how to get help and procedures for updating the user manual.

5. Online Documentation- delivered with a system can range from simple ‘read me’
files that provide very limited information about the software through interactive
help systems to a complete web-based suite of system documentation including user
manuals, tutorials, etc. However, for most applications, a hypertext based help
system is the most commonly provided on-line documentation. Sometimes, this is a
built-in help system that is delivered as part of the application. More commonly,
however, the help system is web-based so that users need an Internet connection to
access the information. The main advantage with on-line documentation is, of
course, its accessibility. It is not necessary for users to find manuals, there is no
possibility of picking up out-of-date documentation and search facilities can be used
to locate information quickly. In principle, built-in help systems can have ‘context
awareness’ so that they know what system features are being used. This means that
they can give help to support the current user activities. Web-based help systems
can be used to provide information to potential system buyers about the features of
the system. However, built-in and web-based help systems have several
disadvantages, which means that many people still prefer paper-based
documentation.

These are:

 They lack ‘browsability’ so that readers cannot easily skim through them to find
the information they need. We often find it difficult to characterize the
information we want from documentation although we can recognize it when we
find it. Browsing is the key mechanism that we use when searching in this way.
Browsing also offers opportunities for serendipitous discovery of system
facilities that were unknown.
 Screens still have a much resolution than paper and hence it is more difficult and
tiring to read a document on the screen rather than on paper.
 It is very easy for users to get lost in web-based help systems and they
consequently find it difficult to navigate to where they want to go.

At the time of writing, tablets such as the iPad have only just been introduced and
they have not yet had any impact on the ways that on-line documentation is
accessed. It is possible that these will change the balance between paper and on-line
documents and paper-based documentation will be less and less used. When
designing screen-based documentation, you should always bear these problems in
mind. Consequently, although both screen-based and paper-based documents
should be well-written, different designs are needed for electronic and paper
documentation. Because of the differences between screens and paper, simply
converting a word processor document to a set of web pages rarely produces high-
quality on-line documentation. Online documentation is part of more general user
support systems that provide help and support to system users.