CHAPTER VIII

Compilation of Reports Accounting Information System

SYSTEMS DOCUMENTATION, MAINTENANCE AND POST-IMPLEMENTATION

AUDIT/REVIEW

After the systems problems have been investigated and analysed, solutions
have been designed, and the best alternative has been selected, the next phase is
implementation. When the system is operational, it must be maintained. Finally, it
must be reviewed, and the systems development life cycle is complete. All systems
must also be subject to audit, either internal or external.

SYSTEMS DOCUMENTATION
After the new system is tested and before users are trained, user procedures
should be developed, tested, and documented. These documented procedures form
the basis of user training. The user procedures are usually included in the final user
documentation.
Documentation is the collection of documents that describes the
requirements, capabilities, limitations, design, operation and maintenance of a
system. For short, it describes how the system works.

Characteristics of Systems Documentation

Created for intended audience
Specific
Relationship with other documentation
Up to date
Sufficiently comprehensive
Accessible
Secure

Three types of documentation that should be prepared for an information system:

Systems documentation provides technical information to programmers and
systems analysts on how the system is built. As each group works on a phase of
the SDLC, it is responsible for documentation of that phase. The general guideline
for systems documentation is to include information on the maintenance of the
system. Full documentation includes systems objectives, acceptance criteria,
design documents, systems specifications, project dictionary, data dictionary, test
procedures, and test results.
Operations documentation provides information to technical specialists on how
to troubleshoot for the system and solve day-to-day operating problems. The type
117

CHAPTER VIII

Compilation of Reports Accounting Information System

of information included in the operations documentation differs from system to

system, depending on the specific hardware and software environment. Often,
operations documentation includes back-up and recovery procedures, instructions
on how to react to error conditions and error messages, and system limitations.
Instructions on how to obtain technical support should also be included.
User documentation provides information to users on the systems capabilities
and operations. Well-written user documentation should include a table of contents,
a concise description of the features and functions of the system, clear and precise
step-by-step instructions on how to use the various features, sample output, as well
as an index of commands or a summary table of menus. User documentation must
be written in clear, concise language, free of computer jargon.
Users of Systems Documentation
Systems Designers and Programmers
Systems designer and programmers need documentation to debug
errors and perform maintenance on the system. They are involved on a highly
technical level which requires both general and detailed information.
Computer Operators
They use documentation describing how to run the manual called a Run
Manual.
Contents of a Run Manual:
1. Name of the screen
2. Run schedule
3. Required hardware device
4. File requirements used in the system
5. Runtime instruction
6. List of users who received the output from the run
End Users
They use documentation describing how to use the system
Classification Scheme of End Users:
1. Novices have little or no experience with the computers
and may be embarrassed to ask questions.
2. Occasional Users once understood the system but have
forgotten some essential commands or procedures.
3. Frequent Light Users familiar with limited aspects of the
system; although functional they tend to not explore beneath
the surface and lack depth of knowledge.

118

CHAPTER VIII

Compilation of Reports Accounting Information System

4. Frequent Power Users understand the existing system

and will readily adapt to the new systems and they are
intolerant of detailed instructions that waste their time.
Online Documentation guides the user interactively in the use of the
system.
Online Tutorials can be used to train novice or occasional users. The
success of this technique depends on the tutorials degree of realism.
Online Help Features range from simple to sophisticated. A simple help
feature may be nothing more than an error message displayed on the screen.
Accountants
With responsibility for the design of security procedures, accounting controls and
audit trails, accountants are stakeholders in any accounting information systems.
For these tasks, accountants may draw upon all the other documentations.
SYSTEMS MAINTENANCE
All systems need to be maintained, if for no other reason than to ensure that
they are still achieving the objectives for which they were designed. Also,
circumstances change, new ideas for improvements arise, technologies change, and
opportunities for profit arise. Some maintenance is minor or may be simple
modifications, but others may entail significant enhancements or even
recommencing the SDLC. It is important for an organization to establish standards
to control and effectively manage the maintenance of the information system,
including risk mitigation strategies and implementation and authorization controls.
Any changes to existing systems should be fully tested following the testing
approaches prior to being released in a live system environment to ensure no
adverse effects occur
.
Reasons for maintenance
Frequent minor maintenance has been proven to avoid major problems in the
future. Reasons for program maintenance include:

changes in business processes

new requests from stakeholders, users, and managers
bugs or errors in programs
technical and hardware problems
corporate mergers and acquisitions
government regulations
change in the hardware or operating system

Types of maintenance
119

CHAPTER VIII

Compilation of Reports Accounting Information System

It is probably best for most companies to adopt the four categories of

software maintenance generally used by software companies because these are
clearly defined in the industry. They are:
Slipstream upgrade a minor bug fix or code adjustment. Usually the software
must be recompiled, and because most of these upgrades do not undergo the
complete testing as for a new program, a minor fix often introduces new bugs. This
is why maintenance fixes handled internally should always be completely tested. Inhouse software modifications at this level may be done on the spot and,
unfortunately, are seldom properly documented.
Patch a minor change to correct a problem or make a minor enhancement. It is
usually the result of something overlooked in the original design or discovered
during operations. Patches are often made available on the Internet as a
downloadable file. When performing in-house maintenance, these fixes are usually
documented in the systems manual.
New release a significant change that usually requires alterations to the
documentation. The in-house staff usually identifies this as a major modification or
enhancement, and it is usually well documented in the systems manual, the
operating manual, and the users' manual.
New version a major change that includes numerous features not included on
the previous version. If this is an in-house system, it is major maintenance to the
degree that it is a new SDLC project.

System
maintenance
measures:

includes

the

following

post-implementation

Corrective correct bugs identified by end users

Adaptive react to changes in external environment
Enhancement extend capabilities beyond the original project scope
and system specifications
Preventive maintenance
Request for maintenance form

120

CHAPTER VIII

Compilation of Reports Accounting Information System

A few companies may have a request for maintenance form for handling
maintenance requests when an external vendor provides the software and/or
support. It is important that the group that does the actual maintenance provides
estimates that are agreed to by the user department paying for it. Many simple
requests actually require considerable time and effort, as well as a price tag that
exceeds the benefit received.
Performing maintenance
Who actually performs maintenance is a matter of company or IT department
policy. Some organizations assign this to the original development team, partly
because they are the ones most familiar with the system, and partly as an incentive
to build the systems better in the first place. Other companies assign new staff to
the maintenance task because it helps them to become familiar with the system.
Some organizations establish a maintenance team that specializes in handling
maintenance requests, and includes people with a variety of technical abilities and
skills.
The same tools are used in maintenance as in development, and
documentation is equally important for maintenance. Unfortunately, many
companies have wasted time and money in handling a modification because earlier
maintenance and changes were not documented. This is also true when support
comes from external sources. The only way to ensure that documentation is
performed properly is to have a checklist of tasks that includes updating all
documentation, and ensure that the maintenance staff follow the checklist and sign
off on each task.
Vendors are developing tools that make maintenance easier, some of which
include documentation. Some CASE tools also automatically update documentation
as maintenance is performed.

Financial implications
Maintenance is expensive (up to five times more than the cost of
development) and costs increase with age. It also uses up valuable people
resources. There comes a point when it is more cost-effective to replace the system
(an asset), for two reasons. One is that maintenance costs will exceed replacement
costs. The other is that the asset may not be capable of meeting new demands or
needs, and in order to attain important benefits, it must be replaced. Requests for
maintenance should include lost opportunities and unrealized benefits, or ideas for
enhancements that could not be met by the existing system.
121

CHAPTER VIII

Compilation of Reports Accounting Information System

Relationship between maintenance and design

Extra time spent in design will reduce maintenance costs. If a system is well
designed and well documented to begin with, it will save programming time and
cost during development. Also, fewer errors will need to be corrected and the
system will meet requirements better. Flexibility and maintainability should be built
into the original design. The use of structured design and modularity and other
techniques are part of good design, so are addressing requirement needs and
resolving small problems during the design phase. In the original analysis, creative
and critical analyses need to be applied to ensure that requirements will lead to an
effective system. Key users should understand the acceptance criteria for the
system and agree that they are appropriate before development gets under way.

SYSTEMS REVIEW
Systems review completes the SDLC. The objective is to measure the success
of the system and of the process after the dust has settled. Its primary goal is to
ensure that the system operates in a manner that meets the functional
requirements and achieves the objectives for developing the system. This first stage
of review is often called post-implementation review (PIR) or postimplementation audit (PIA) because it looks at the results of the development
process, including costs and benefits, and compares them to the planning and
estimates. Although systems professionals strive to produce systems that are on
budget, on time and meet user needs, this does not always happen. The post
implementation review of the newly installed system can provide insight into ways
to improve the process for future systems.
PIA or PIR is a top-to-bottom evaluation of the hard benefits, such as changes
in return on investment from the original business case and savings as a result of
implementing the solution, and soft benefits of the installed system such as
improved communications, more consistent data, easier access to data, data
sharing among different groups, and improved regulatory compliance derived from
a strategic information system, the security of the system and the project
management process deploying it. It is usually timed to allow the new system to
operate for a given period, such as a quarter, to concentrate on ongoing issues
rather than those generated and resolved a cutover time.

The objectives of the post-implementation audit are:

to determine whether the conversion to a new system has met the
objectives originally identified (including performance and cost
objectives)
122

CHAPTER VIII

Compilation of Reports Accounting Information System

to compare the operational performance to the design objectives

to compare the actual costs of the development effort with the
budgeted costs
to learn from the project what the key success factors are and identify
the costs of any future system enhancements
This stage of review should be conducted for all systems projects. One of the
important outcomes is learning what problems occurred during the development
process, including project management problems, in order to avoid these problems
in future projects and thus achieve more cost-effective systems development.
A post-implementation review is usually conducted within six months to a
year of the acceptance of the system. The review may be conducted by IT staff or a
team that includes senior management representatives or outside consultants, as
well as internal or external auditors. The original project team does not conduct the
review, although one or more members may be included. The review committee
reports back to the steering committee.
A second stage of review, which generally occurs after the system has been
in place for some time, has different objectives, including the following:
to determine if the system still performs up to expectations and meets
current requirements
to determine if there are benefits and opportunities that cannot be
achieved
to determine whether there are problems not addressed by the current
system
to determine if there are known changes that require system
enhancements
to determine whether the system should be replaced

Types of review procedures

An event-driven review is triggered by a problem, an opportunity, or a
change in the environment. A time-driven review is performed periodically based
on a lapse of time (the post-implementation review is a time-driven review). Many
companies use both types of review.

Factors to consider during systems review

In a systems review, you should consider and determine the specifics of a
number of factors. The team investigates these factors based on documentation.
123

CHAPTER VIII

Compilation of Reports Accounting Information System

During systems review, the team would review systems documentation, operations
documentation, and user documentation review requests for maintenance,
improvements, and enhancements, as well as operating costs review company
policy and mission statements compare such factors as controls and reliability to
industry standards conduct interviews with key stakeholders use performance
measurement techniques and tools

Systems performance measurement

Most systems reviews include systems performance measurement, which
is measuring and monitoring the performance of the system and its components in
terms of errors, memory, speeds, response times, and other criteria. To assist them
in this part of the review, team members may use system performance products
that have been developed to measure components.
After systems performance measurement, the SDLC is now complete (other
than maintenance and enhancement)

124

CHAPTER VIII

Compilation of Reports Accounting Information System

Name:
Score:
MULTIPLE CHOICE.
Encircle the letter of your answer. In case the answer is not found in the given
choices, write Pabebe ako before the number. (15pts.)
1. It is a minor change to correct a problem or make a minor enhancement.
a. Patch
b. Slipstream update
c. New release
d. New version
2. It is a major change that includes numerous features not included on the
previous version.
a. Patch
b. Slipstream update
c. New release
d. New version
3. It is a significant change that usually requires alterations to the documentation.
a. Patch
b. Slipstream update
c. New release
d. New version
4. A review procedure that is performed periodically based on a lapse of time.
a. Event-driven
b. Document-driven
c. Data-driven
d.
Timedriven
5. The following are the objectives of post-implementation review, except
a.
to compare the operational performance to the design objectives
b.
to learn from the project what the key success factors are and identify the
costs of any future system enhancements
c. to determine whether the conversion to a new system has met the objectives
originally identified
d.
to compare the actual costs of the development effort with the budgeted cost
6.
a.
b.
c.
d.

All are reasons for systems maintenance except

government regulations
new requests from stakeholders, users, and managers
corporate mergers and acquisitions
bugs or errors in programs

7.

It includes back-up and recovery procedures, instructions on how to react to

error conditions and error messages, and system limitations.
Systems documentation
User documentation
Operations documentation
Audit documentation

a.
b.
c.
d.
8.
a.
b.
c.
d.

It provides technical information to programmers and systems analysts on

how the system is built
Systems documentation
User documentation
Operations documentation
Audit documentation

125

CHAPTER VIII
9.
a.
b.
c.
d.
10.
a.
b.
c.
d.
11.

Compilation of Reports Accounting Information System

Corporate mergers and acquisitions; Compare the operational performance to

the design objectives
Objectives of post-implementation review; Objectives of maintenance
Reasons of post-implementation review; Objectives of maintenance
Objectives of post-implementation review; Reasons for maintenance
Reasons of post-implementation review; Reasons for maintenance
Determine if the system still performs up to expectations and meets current
requirements; Determine whether the conversion to a new system has met
the objectives originally identified
Reasons of post-implementation review; Objectives of maintenance
Objectives of post-implementation review; Reasons for maintenance
Objectives of pot-implementation review; Objectives of the second stage of
review
Reasons for post-implementation review; Reasons for the second stage of
review
The post-implementation review is a time-driven
implementation review is an event-driven review
a. True; False
b. True; True
c. False; True

review;

The

post-

d. False; False

12.

All systems need to be maintained, if for no other reason than to ensure that
they are still achieving the objectives for which they were designed; Also,
circumstances change, new ideas for improvements arise, technologies
change, and opportunities for profit arise
a. True; False
b. True; True
c. False; True
d. False; False

13.

The general guideline for systems documentation is to include information on

the maintenance and test procedures of the system; Well-written operational
documentation should include a table of contents, a concise description of
the features and functions of the system, clear and precise step-by-step
instructions on how to use the various features, sample output, as well as an
index of commands or a summary table of menus
a. True; False
b. True; True
c. False; True
d. False; False

14.

It guides the user interactively in the use of the system.

a. User documentation
b. Online documentation
c. Operation documentation
d. None of the above

15.

The following are the contents of a run manual except

a. Runtime instruction b. Run schedule
c. Both a & b

d. b only

TRUE or FALSE.
Write #AlDub if the statement is true, otherwise, write #WalangForever. (10pts.)
1. Extra time spent in design will reduce maintenance costs

126

CHAPTER VIII

Compilation of Reports Accounting Information System

2. In the original analysis, creative and critical analyses need to be applied to

ensure that requirements will lead to an efficient system
3. A post-implementation review is usually conducted within three months to
a year of the acceptance of the system
4. The general guideline for systems documentation is to include information
on the maintenance of the system
5. All systems must be subject to audit, either internal or external
6. Any changes to existing systems should be fully tested following the
testing approachesafter it is released in a live system environment to
ensure no adverse effects occur
7. Who actually performs maintenance is a matter of company or HR
department policy
8. Maintenance is expensive
9. Maintenance costs decrease with age
10. It is important for an organization to establish standards to control and
effectively manage the maintenance of the information system, including
risk mitigation strategies and implementation and authorization controls
IDENTIFICATION.(15pts.)
_____________1. A minor bug fix or code adjustment
_____________2. It looks at the results of the development process, including costs
and benefits, and compares them to the planning and estimates
_____________3. Its primary goal is to ensure that the system operates in a manner
that meets the functional requirements and achieves the objectives for developing
the system
_____________4. It is the measuring and monitoring of the performance of the system
and its components in terms of errors, memory, speeds, response times, and other
criteria
_____________5. It is triggered by a problem, an opportunity, or a change in the
environment
_____________6. Provides information to technical specialists on how to troubleshoot
for the system and solve day-to-day operating problems
_____________7. It must be written in clear, concise language, free of computer
jargon
_____________8. It is the collection of documents that describes the requirements,
capabilities, limitations, design, operation and maintenance of a system. For short,
it describes how the system works.
_____________9. They once understood the system but have forgotten some essential
commands or procedures.
_____________10. The success of this technique depends on the tutorials degree of
realism.
_____________11. They are familiar with limited aspects of the system and they tend
to not explore beneath the surface and lack depth of knowledge
_____________12. Describes how to run the manual
_____________13. This type of system maintenance tries to react to changes in the
external environment.
_____________14. They need documentation to debug errors and perform
maintenance on the system.
127

CHAPTER VIII

Compilation of Reports Accounting Information System

_____________15. They use documentation describing how to use the system.

ESSAY.
1. Enumerate and discuss the users of Systems Documentation (5pts.)
2. Explain briefly and concisely the PIA or PIR (5pts.)

128