UNIVERSITY OF RIZAL SYSTEM

Province of Rizal
Binangonan Campus
COLLEGE OF ACCOUNTANCY

Chapter 5: Systems
Development and Program
Change Activities

Submitted by:
Camposano, Christin
Centillas, Robert
Mendoza, French Aira C.
BSA 3-2

Submitted to:
Prof. Liberty Ocampo

0
Chapter 5: System Development and Program Change Activities

Learning Objectives:

After studying this chapter, you should:

● Be able to identify the stages in the SDLC.
● Be familiar with common problems that can lead to failure in the systems
development process.
● Understand the importance of strategic system planning.
● Have a general understanding of how accountants participate in the SDLC.
● Be able to identify the basic features of both the structured and object-oriented
● approaches to systems design.
● Be able to identify and discuss the major steps involved in a cost-benefit
analysis of
● proposed information systems.
● Understand the advantages and disadvantages of the commercial software
option, and be able to discuss the decision-making process used to select
commercial software.
● Understand the purpose of a system walkthrough.
● Be familiar with the different types of system documentation and the purposes
they serve.

1
Chapter 5: System Development and Program Change Activities

Introduction:
One of the most valuable assets of the modern business organization is a
responsive, user-oriented information system. A well-designed system can increase
productivity, reduce inventories, eliminate non value-added activities, improve customer
service and management decisions, and coordinate activities throughout the
organization.
This chapter concludes our treatment of general control issues as they relate
to management and auditor responsibilities under SOX Section 404. It begins
by describing the roles of the participants involved in developing an organization’s
information system, including systems professionals, users, and stakeholders. Then it
outlines the key activities that constitute the systems development life cycle (SDLC).
These include systems planning, systems analysis, conceptual design, system
selection, detailed design, system implementation, and program change procedures
(systems maintenance). This multistage procedure is used to guide systems
development in many organizations. Finally, it discusses SDLC risks, controls, and audit
issues.

PARTICIPANTS IN SYSTEMS AND DEVELOPMENT

The participants in systems development can be classified into four broad groups:
systems professionals, end users, stakeholders, and accountants/auditors.
1. Systems professionals are systems analysts, systems engineers, and
programmers. They build systems by gathering, analyzing, and formulating
solutions.
2. End users are those for whom the system is built.
3. Stakeholders are individuals either within or outside the organization with an
interest in the system but are not end users, including accountants, internal and
external auditors, and the internal steering committee.
4. Accountants/Auditors address controls, accounting, and auditing issues for
systems development, including internal and IT auditors. SOX legislation
prohibits external auditors from direct involvement in systems development
activities.

Why Are Accountants and Auditors Involved with SDLC?

Accountants and auditors are interested in the Software Development Life

Cycle (SDLC) for two main reasons. Firstly, they ensure the integrity of financial
transactions within the SDLC by providing input on controls and financial aspects.
Secondly, they focus on the quality of products, especially accounting information
systems (AIS), to prevent errors or fraud in financial records.

2
How Are Accountants Involved with the SDLC?

Accountants are involved in systems development in three ways.

1. Accountants communicate their requirements to system professionals for

accurate financial transaction processing.
2. Accountants contribute to system development teams, offering advice and
assessing internal control risks.
3. Accountants ensure auditability in accounting information systems by being
involved in their early design stages, focusing on security and controls.

INFORMATION SYSTEMS ACQUISITION

Organizations usually acquire information systems in two ways: (1) they develop
customized systems in-house through formal systems development activities and
(2) they purchase commercial systems from software vendors. This section of the
text discusses these two alternatives.

In-House Development
Many organizations require systems that are highly tuned to their unique operations.
These firms design their own information systems through in-house systems
development activities. In-house development requires maintaining a full-time
systems staff of analysts and programmers who identify user information needs and
satisfy their needs with custom systems.

Commercial Systems
A growing number of systems are purchased from software vendors. Faced with
many competing packages, each with unique features and attributes, management
must choose the system and the vendor that best serve the needs of the
organization. Making the optimal choice requires that this be an informed decision.

Trends in Commercial Software

Four factors have stimulated the growth of the commercial software market:
​ (1) Commercial software is cheaper than customized options.
​ (2) Industry-specific vendors offer software tailored to specific business needs.
​ (3) Small businesses increasingly seek affordable software solutions.
​ (4) Downsizing and distributed data processing make commercial software
attractive to larger organizations.

Types of Commercial Systems

Turnkey systems are pre-built and thoroughly tested systems ready for

3
 implementation. They can be general or industry-specific, with limited customization
options. Users may have basic customization choices or the option to buy source
code for further modifications, often at an extra cost.
General accounting systems are mass-produced by vendors to cut costs
compared to in-house development. They offer modules like accounts payable,
receivable, payroll, and inventory control, allowing flexibility for different business
needs.

Special-purpose systems are designed by software vendors to meet the unique

accounting needs of industries like healthcare, banking, and government agencies.
They address specific industry practices not fully accommodated by
general-purpose systems, offering standardized solutions aligned with industry
requirements.

Office automation systems are computer systems that improve the productivity of
office workers. Examples of office automation systems include word processing
packages, database management systems, spreadsheet programs,and desktop
publishing systems.

Backbone systems provide a basic system structure on which to build with

pre-programmed primary processing modules. Vendors customize the user interface
to fit client needs. ERP systems, for instance, provide extensive modules for
business processes but are costly and time-consuming to customize, taking 18 to
24 months and costing $10 million to $100 million for installation.

Vendor-supported systems blend custom development with commercial software.

Vendors act as in-house teams, creating and maintaining systems for clients,
especially in healthcare and legal sectors. Object-oriented approaches cut
development costs by reusing common modules.

Advantages of Commercial Software

● Implementation. Custom systems take time to develop in-house and may lead
to unmet needs if future requirements aren't anticipated. Commercial software
can be implemented quickly, meeting user needs without delay.
● Cost. In-house development costs are shouldered by a single user, while
commercial software costs are spread across many users, resulting in lower unit
costs.
● Reliability. Most reputable commercial software undergoes thorough testing
before release, with any remaining errors usually found and fixed by user
organizations soon after. Overall, commercial software is less error-prone than
in-house systems.

Disadvantages of Commercial Software

4
 ● Independence. Buying a vendor-supported system means relying on the vendor
for maintenance. However, there's a risk of the vendor ending support or going
out of business, which is a major drawback.
● The need for customized systems. In-house development allows for precise
customization to meet specific needs, a benefit lacking in commercial software
which may be too general or inflexible for unique and complex requirements.
● Maintenance. Commercial software may struggle to adapt to frequent changes
in business needs, while in-house development provides proprietary applications
that are economically maintainable and flexible to evolving requirements.

THE SYSTEMS DEVELOPMENT LIFE CYCLE

Companies combine in-house development with commercial packages, supported by
formal procedures, recognizing their complementarity. The Systems Development Life
Cycle (SDLC) applies to both, ensuring consistency and quality across eight phases,
including new systems development and maintenance which is the two major stages.

System Development Life Cycle (SDLC) phases:

Systems Planning—Phase I
Systems planning aims to align individual system projects with the strategic
objectives of the firm, typically based on the organization's business plan. The IT
strategic plan, derived from and aligned with the business plan, guides the analysis
of systems projects.

5
 Who Should Do Systems Planning?
Firms serious about systems planning establish a steering committee comprising
top executives, user area management, auditors, and external consultants. Typical
responsibilities for a steering committee include the following:
● Resolving conflicts that arise from new systems
● Reviewing projects and assigning priorities
● Budgeting funds for systems development
● Reviewing the status of individual projects under development
● Determining at various checkpoints throughout the SDLC whether to continue
with the project or terminate it

Systems planning occurs at two levels: strategic systems planning and project
planning.

Strategic Systems Planning

Strategic systems planning allocates resources over 3 to 5 years, akin to budgeting
for strategic activities. Unlike the SDLC, it focuses on broader resource allocation,
including employees, hardware, software, and telecommunications. It aims for
informed decision-making by considering factors like price, performance, security,
and control without excessive detail.

Why Perform Strategic Systems Planning?

There are four justifications for strategic systems planning:
1. Strategic plans offer direction, preventing aimless actions and guiding
adjustments.
2. Planning reduces crises by prioritizing user needs, enabling proactive
management.
3. It sets rules for system development authorization, aligning with firm objectives.
4. Evidence shows planning's cost-effectiveness in project management, aiding
cost control.

6
 Project Planning
Project planning aligns resources with the strategic plan by identifying needs,
assessing feasibility, prioritizing projects, and scheduling tasks. Its goal is efficient
resource allocation. Key documents include the project proposal, outlining system
recommendations and alignment with business objectives, and the project schedule,
detailing time and cost estimates for each SDLC phase. Success depends on a
diverse and competent team.

The Auditor’s Role in Systems Planning

Auditors routinely examine the systems planning phase of the SDLC. Planning
greatly reduces the risk that an organization has produced unneeded, inefficient,
ineffective, and fraudulent systems. Therefore, both internal and external auditors
are interested in ensuring that adequate systems planning takes place.

Systems Analysis—Phase II
Systems analysis, the second SDLC phase, involves evaluating the current system
and assessing user needs. It's crucial for the analyst to understand the business
problem fully to propose an effective solution. This phase lays the foundation for the
entire SDLC, ending with a formal report detailing findings and recommendations for
the new system.

The Survey Step

In system analysis, existing systems are assessed first. The analyst conducts
surveys and gathers facts to address initial questions, leading to iterative data
collection and analysis. This process, though time-consuming, offers both
disadvantages and advantages in evaluating the current system.

Disadvantages of Surveying the Current System

• Current physical tar pit. This term describes the analyst getting overly absorbed
and delayed by surveying the outdated system.
• Thinking inside the box. Studying the current system too closely can limit
innovative thinking, leading to improvements rather than radical changes in the new
system.

Advantages of Surveying the Current System

• Identifying what aspects of the old system should be kept. Analyzing the old
system guides analysts in determining which functional elements to keep or change
as a basis for the new system.
• Forcing systems analysts to fully understand the system. Understanding the
current system is crucial for smooth user conversion during implementation.
• Isolating the root of problem symptoms. Surveying the current system enables
analysts to pinpoint the root causes of reported problems.

7
 Gathering Facts
The survey of the current system is essentially a fact-gathering activity. The facts
gathered by the analyst are pieces of data that describe key features, situations,
and relationships of the system. System facts fall into the following broad classes.
• Data sources
• Users
• Data stores
• Processes
• Data flows
• Controls
• Transaction volumes
• Error rates
• Resource costs
• Bottlenecks and redundant operations

Fact-Gathering Techniques
Systems analysts employ several techniques to gather the previously cited facts.
Commonly used techniques include observation, task participation, personal
interviews, and reviewing key documents.

Observation. Observation involves passively watching the physical procedures of

the system. This allows the analyst to determine what gets done, who performs the
tasks, when they do them, how they do them, why they do them, and how long they
take.
Task Participation. Participation means analysts join user tasks to see challenges
up close. By doing tasks like taking orders, they find issues such as bad document
design, often leading to better ways of doing things.
Personal Interviews. Interviews gather facts about the current system and user
needs for the new one. They use open-ended questions or formal surveys.

• Open-ended questions let users explain problems and suggest solutions, though
analyzing answers can be challenging. The analyst needs to be a good listener and
focus on key facts.
• Questionnaires ask specific questions to gather detailed, objective facts about
procedures, transaction volumes, data sources, report users, and control issues.

Reviewing Key Documents. The organization’s documents are another source of

facts about the system being surveyed. Examples of these include the following:

• Organizational charts
• Job descriptions
• Accounting records

8
 • Charts of accounts
• Policy statements
• Descriptions of procedures
• Financial statements
• Performance reports
• System flowcharts
• Source documents
• Transaction listings
• Budgets
• Forecasts
• Mission statements

These documentation techniques are discussed in more detail in Chapter 6.

The Analysis Step

Systems analysis is an intellectual process that is commingled with fact gathering.
The analyst is simultaneously analyzing as he or she gathers facts. The mere
recognition of a problem presumes some understanding of the norm or desired
state. It is therefore difficult to identify where the survey ends and the analysis
begins.

Systems Analysis Report

The systems analysis phase concludes with a formal report outlining survey
findings, current system issues, and user requirements for the new system. It
focuses on what the system must achieve and serves as a contract between
stakeholders, detailing objectives and specifications. However, it avoids detailed
system design, allowing exploration of multiple options to meet user needs.

9
 The Auditor’s Role in Systems Analysis
Auditors are stakeholders in system proposals and require involvement in the needs
analysis phase to assess suitability for advanced audit features. Integration of
Computer-Assisted Audit Techniques (CAATTs) like embedded audit modules
discussed in Chapter 8 should occur during the SDLC.

Conceptual Systems Design—Phase III

During the conceptual design phase of the Systems Development Life Cycle
(SDLC), multiple conceptual systems are created to meet requirements, allowing
users to choose the most suitable option. This phase minimizes resource
investment in rejected designs. There are two main approaches: structured and
object-oriented design (OOD). Structured design starts from the top down, while
OOD builds from reusable modules, often using an iterative approach. OOD
facilitates flexible and efficient development by adding modules incrementally until
the entire system is formed.

The Structured Design Approach

The structured design approach breaks systems down from broad concepts to
detailed components using data flow and structure diagrams. It starts abstractly and
refines step by step. During conceptual design, differences between competing
systems are highlighted. General designs outline inputs, outputs, processes, and
unique features. However, these designs lack implementation details. For instance,
they do not include these necessary components:
• Database record structures
• Processing details
• Specific control techniques
• Formats for input screens and source documents
• Output report formats

10
 The Object-Oriented Approach
The object-oriented design (OOD) approach is to build information systems from
reusable standard components or objects. This approach may be equated to the
process of building an automobile. Car manufacturers do not create each new
model from scratch.
Concept of Reusability is central to the object-oriented approach to systems
design, allowing standard modules to be used in multiple systems with similar
needs. Ideally, the organization’s systems professionals will create a library
(inventory) of modules that can be used by other system designers within the firm.
The benefits of this approach include reduced time and cost for development,
maintenance, and testing and improved user support and flexibility in the
development process.

The Auditor’s Role in Conceptual Systems Design

● Auditors are important stakeholders in financial systems.
● Early auditor involvement ensures effective auditing processes.
● Embedding audit features enhances transparency and reliability.
● System design impacts auditability.
○ Some auditing techniques require special audit features.
○ These features must be specified during the design stage.

System Evaluation and Selection-Phase IV

The procedure for selecting the one system from the set of alternative conceptual
designs that will go to the detailed design phase. The systems evaluation and
selection phase is an optimization process that seeks to identify the best system.
This decision represents a critical juncture in the SDLC.
Purpose - to structure this decision-making process and thereby reduce both
uncertainty and the risk of making a poor decision. The evaluation and selection
process involves two steps:
1. Perform a detailed feasibility study
2. Perform a cost-benefit analysis

1. Perform a Detailed Feasibility Study

Five aspects of project feasibility
TELOS (technical, economic, legal, operational, and schedule feasibility)
1. Technical Feasibility - concerned with whether the system can be developed
under existing technology or if new technology is needed.
2. Economic Feasibility - pertains to the availability of funds to complete the
project.
3. Legal Feasibility - identifies any conflicts between the conceptual system and
the company's ability to discharge its legal responsibilities.
4. Operational Feasibility - shows the degree of compatibility between the firm's
existing procedures and personnel skills and the operational requirements of the

11
 new system. This may require adopting new procedures and retraining operations
personnel. Question that must be answered - Can adequate procedural changes be
made, sufficient personnel retrained, and new skills obtained to make the system
operationally feasible?
5. Schedule Feasibility - relates to the firm's ability to implement the project
within an acceptable time. This impacts both the scope of the project and whether it
will be developed in-house or purchased from a software vendor.
2. Perform a Cost-Benefit Analysis
It helps management determine whether (and by how much) the benefits
received from a proposed system will outweigh its costs. This technique is
frequently used for estimating the expected financial value of business investments.
Three steps in the application of cost-benefit analysis: identify costs, identify
benefits, and compare costs and benefits.
1. Identify Costs. One method of identifying costs is to divide them into two
categories: one-time costs and recurring costs.
a. One-time costs include the initial investment to develop and
implement the system.
b. Recurring costs include operating and maintenance costs that recur
over the life of the system.
One-time costs include the following:
• Hardware acquisition - includes the cost of mainframe, minicomputers,
microcomputers, and peripheral equipment, such as tape drives and disk packs. Cost
figures can be obtained from the vendor.
• Site preparation - involves such frequently overlooked costs as building modifications
(e.g., adding air conditioning or making structural changes), equipment installation
(which may include the use of heavy equipment), and freight charges. Estimates of
these costs can be obtained from the vendor and the subcontractors who do the
installation.
• Software acquisition - apply to all software purchased for the proposed system,
including operating system software (if not bundled with the hardware), network control
software, and commercial applications (such as accounting packages). Estimates of
these costs can be obtained from vendors.
• Systems design - cost incurred by systems professionals performing the planning,
analysis, and design functions. Technically, such costs incurred up to this point are
“sunk” and irrelevant to the decision. The analyst should estimate only the costs needed
to complete the detailed design.
• Programming and testing - Programming costs are based on estimates of the
personnel hours required to write new programs and modify existing programs for the
proposed system. System testing costs involve bringing together all the individual
program modules for testing as an entire system.
• Data conversion - arise in the transfer of data from one storage medium to another.
For example, the accounting records of a manual system must be converted to
magnetic form when the system becomes computer-based. This can represent a
significant task. The basis for estimating conversion costs is the number and size of the
files to be converted.

12
• Training - involve educating users to operate the new system. In-house personnel
could do this in an extensive training program provided by an outside organization at a
remote site or through on-the-job training. The cost can be easily obtained. The cost of
an in-house training program includes instruction time, classroom facilities, and lost
productivity. This cost is often the first one cut to meet budgets, and such an action can
be fatal to systems development.
Recurring costs include the following:
• Hardware maintenance - involves the upgrading of the computer (increasing the
memory), as well as preventive maintenance and repairs to the computer and peripheral
equipment.
• Software maintenance - include upgrading and debugging operating systems,
purchased applications, and in-house developed applications. Maintenance contracts
with software vendors can be used to specify these costs fairly accurately. Estimates of
in-house maintenance can be derived from historical data.
• Insurance - covers such hazards and disasters as fire, hardware failure, vandalism,
and destruction by disgruntled employees.
• Supplies - incurred through routine consumption of such items as paper, magnetic
disks, CDs, and general office supplies.
• Personnel costs - the salaries of individuals who are part of the information system.
2. Identify Benefits. These may be both tangible and intangible.
a. Tangible benefits fall into two categories: those that increase revenue and
those that reduce costs.

b. Intangible benefits. Table 5.3 lists some common categories of intangible

benefits.

3. Compare Costs and Benefits. The two most common methods used for
evaluating information systems are net present value and payback.
a. Net present value method - is deducted from the present value of
the benefits over the life of the system. Projects with a positive net
present value are economically feasible. When comparing
competing projects, the optimal choice is the project with the
greatest net present value.
b. Payback method - variation of break-even analysis. The
break-even point is reached when total costs equal total benefits.

13
Prepare Systems Selection Report
- deliverable product of the systems selection process
- a formal document consists of a revised feasibility study, a cost-benefit analysis,
and a list and explanation of intangible benefits for each alternative design
The Auditor’s Role in Evaluation and Selection
The primary concern for auditors is that the economic feasibility of the proposed
system is measured as accurately as possible. Specifically, the auditor should ensure
five things:
1. Only escapable costs are used in calculations of cost savings benefits.
2. Reasonable interest rates are used in measuring present values of cash flows.
3. One-time and recurring costs are completely and accurately reported.
4. Realistic useful lives are used in comparing competing projects.
5. Intangible benefits are assigned reasonable financial values.

Detailed Design—Phase V
Purpose: to produce a detailed description of the proposed system that both
satisfies the system requirements identified during systems analysis and is in
accordance with the conceptual design.
In this phase, all system components (user views, database tables, processes,
and controls) are meticulously specified.
Output: components are presented formally in a detailed design report. This
report constitutes a set of blueprints that specify input screen formats, output report
layouts, database structures, and process logic. These completed plans then proceed to
the final phase in the SDLC—systems implementation—where the system is physically
constructed.
1. Perform a System Design Walkthrough
- involves a thorough review of the detailed design by a quality assurance group
comprising programmers, analysts, users, and internal auditors. By simulating system
operation, this process aims to uncover conceptual errors, omissions, and ambiguities,
reducing the likelihood of costly reprogramming by addressing design flaws early.
2. Review System Documentation
The detailed design report documents and describes the system to this point.
This report includes the following:
• Designs for all screen inputs and source documents for the system.
• Designs of all screen outputs, reports, and operational documents.
• Normalized data for database tables, specifying all data elements.
• Database structures and diagrams: Entity relationship (ER) diagrams describing
the data relations in the system, context diagrams for the overall system,
low-level data flow diagrams of specific system processes, structure diagrams for
the program modules in the system—including a pseudocode description of each
module.
• An updated data dictionary describing each data element in the database.
• Processing logic (flow charts).

14
Application Programming and Testing—Phase VI

The next stage of the SDLC is to select a programming language from among
the various languages available and suitable to the application. These include
procedural languages like COBOL, event-driven languages like Visual Basic, or
object-oriented programming (OOP) languages like Java or C++. This presents a brief
overview of various programming approaches. Systems professionals will make their
decision based on the in-house standards, architecture, and user needs.
1. Procedural Languages - requires the programmer to specify the precise
order in which the program logic is executed. Procedural languages are often called
third-generation languages (3GLs). Examples of 3GLs include COBOL, FORTRAN, C,
and PL1. In business (particularly in accounting) applications, COBOL was the
dominant language for years. COBOL has great capability for performing highly detailed
operations on individual data records and handles large files very efficiently.
2. Event-Driven Languages - the program’s code is not executed in a
predefined sequence. Instead, external actions or “events” that are initiated by the user
dictate the control flow of the program. For example, when the user presses a key, or
“clicks” on an icon on the computer screen, the program automatically executes code
associated with that event. This is a fundamental shift from the 3GL era. Now, instead of
designing applications that execute sequentially from top to bottom in accordance with
the way the programmer thinks they should function, the user is in control.
Microsoft’s Visual Basic is the most popular example of an event-driven
language.
3. Object-Oriented Languages - Central to achieving the benefits of the object
oriented approach is developing software in an object-oriented programming (OOP)
language. The most popular true OOP languages are Java and Smalltalk.
4. Programming the System. Regardless of the programming language used,
modern programs should follow a modular approach. This technique produces small
programs that perform narrowly defined tasks. The following three benefits are
associated with modular programming.
1. Programming efficiency. Modules can be coded and tested
independently, which vastly reduces programming time.
2. Maintenance efficiency. Small modules are easier to analyse and
change, which reduces the start-up time during program maintenance. Extensive
changes can be parcelled out to several programmers simultaneously to shorten
maintenance time.
3. Control. By keeping modules small, they are less likely to contain
material errors of fraudulent logic. Since each module is independent of the
others, errors are contained within the module.
Test the Application Software
All program modules must be thoroughly tested before they are implemented.
Some proven concepts about testing that should be followed by the system developers,
and considered by auditors in conducting audits.

15
 1. Testing Methodology. The process itself has structured steps to follow. The results
of the tests are then compared against predetermined results to identify programming
and logic errors.
2. Testing Offline Before Deploying Online. The first point that is critical in testing is
to never underestimate the principle of testing offline before deploying a system online.
Implementing a system without testing offline is an invitation to disaster. O
3. Test Data. This activity can, however, provide future benefits. To facilitate future
testing, test data prepared during the implementation phase should be retained for
reuse. This test data will give the auditor a frame of reference for designing and
evaluating future audit tests. For example, if a program has undergone no maintenance
changes since its original implementation, the test results from the audit should be
identical to the original test results. Having a basis for comparison, the auditor can thus
quickly verify the integrity of the program code. If changes have occurred, however, the
original test data can provide evidence regarding these changes. The auditor can thus
focus attention upon those areas.

System Implementation—Phase VII

In the system implementation phase, database structures are created and

populated with data, equipment is purchased and installed, employees are trained, the
system is documented, and the new system is installed. The implementation process
engages the efforts of designers, programmers, database administrators, users, and
accountants. The activities in this phase entail extensive costs and will often consume
more personnel-hours than all other pre implementation phases of the SDLC combined.
1. Testing the Entire System
During system-wide testing, all modules are integrated and tested collectively,
with user personnel overseeing the process to ensure it aligns with requirements.
Hypothetical data is processed through the system, and outputs are compared with
predetermined results, with documentation capturing the test outcomes. Upon
satisfactory results, a formal acceptance document is completed by the user, confirming
that the system meets specified requirements, which becomes crucial for
post-implementation reviews and assigning responsibility.
2. Documenting the System
- provides the auditor with essential information about how the system works.
The documentation requirements of three groups—systems designers and
programmers, computer operators, and end users—are of particular importance.
a. Designer and Programmer Documentation. Systems designers and programmers
need documentation to debug errors and perform maintenance on the system.
This group is involved with the system on a highly technical level, which requires
both general and detailed information. Some of this is provided through data flow
diagrams, entity relation (ER) diagrams, and structure diagrams. In addition,
system flowcharts, program flowcharts, and program code listings are important
forms of documentation.
● System flowchart shows the relationship of input files, programs, and
output files. However, it does not reveal the logic of individual programs

16
 that constitute the system.
● Program flowchart provides a detailed description of the sequential and
logical operation of the program. Each program in the system’s flowchart
is represented by a separate program flowchart, as shown in Figure 5.9.
From these, the programmer can visually review and evaluate the
program’s logic.
● Program code should itself be documented with comments that describe
each major program segment.

b. Operator Documentation. Computer operators use documentation called a run

manual, which describes how to run the system. The typical contents of a run manual
include
• The name of the system, such as Purchases System
• The run schedule (daily, weekly, time of day, and so on)
• Required hardware devices (tapes, disks, printers, or special hardware)
• File requirements specifying all the transaction (input) files, master files, and
output files used in the system
• Run-time instructions describing the error messages that may appear, actions
to be taken, and the name and telephone number of the programmer on call,
should the system fail
• A list of users who receive the output from the run
c. User Documentation. Users need documentation describing how to use the
system. User tasks include such things as entering input for transactions, making
inquiries of account balances, updating accounts, and generating output reports. The
nature of user documentation will depend on the user’s degree of sophistication with
computers and technology. Thus, before designing user documentation, the systems
professional must assess and classify the user’s skill level. The following is one possible

17
classification scheme:
● Novices
● Occasional users
● Frequent light users
● Frequent power users
User Handbook. User documentation often takes the form of a user handbook, as well
as online documentation. The typical user handbook will contain the following items:
• An overview of the system and its major functions
• Instructions for getting started
• Descriptions of procedures with step-by-step visual references
• Examples of input screens and instructions for entering data
• A complete list of error message codes and descriptions
• A reference manual of commands to run the system
• A glossary of key terms
• Service and support information
Online documentation will guide the user interactively in the use of the system.
Commonly found online features include
1. Tutorials. Online tutorials can be used to train the novice or the occasional user.
The success of this technique is based on the tutorial’s degree of realism.
Tutorials should not restrict the user from access to legitimate functions.
2. Help Features. Online help features range from simple to sophisticated. A
simple help feature may be nothing more than an error message displayed on
the screen. The user must “walk through” the screens in search of the solution to
the problem. More sophisticated help is context-related. When the user makes an
error, the system will send the message, “Do you need help?” The help feature
analyzes the context of what the user is doing at the time of the error and
provides help with that specific function (or command).
Converting the Databases
Database conversion is a critical step in the implementation phase. This is the
transfer of data from its current form to the format or medium required by the new
system. The degree of conversion depends on the technology leap from the old system
to the new one. Some conversion activities are very labor intensive, requiring data to be
entered into new databases manually
1. Validation The old database must be validated before conversion. This
requires an- alyzing each class of data to determine whether it should be
reproduced in the new database.
2. Reconciliation After the conversion action, the new database must be
reconciled against the original. Sometimes this must be done manually, record by
record and field by field. In many instances, this process can be automated by
writing a pro- gram that will compare the two sets of data.
3. Backup Copies of the original files must be kept as backup against
discrepancies in the converted data. If the current files are already in magnetic
form, they can be conveniently backed up and stored. However, paper
documents can create storage problems. When the user feels confident about

18
 the accuracy and completeness of the new data- bases, he or she may destroy
the paper documents

Converting to the New System

The process of converting from the old system to the new one is called the cutover. A
system cutover will usually follow one of three approaches: cold turkey, phased, or
parallel operation.

Cold Turkey Cutover. Under the cold turkey cutover approach (also called the "Big
Bang" approach), the firm switches to the new system and simultaneously terminates
the old system. When implementing simple systems, this is often the easiest and least
costly approach. With more complex systems, it is the riskiest.
Phased Cutover. Sometimes an entire system cannot, or need not, be cut over at
Once. The phased cutover begins operating the new system in modules.
Parallel Operation Cutover. Parallel operation cutover involves running the old system
and the new system simultaneously for a period of time. Figure 5.11 illustrates

This approach, which is the most time-consuming and costly of the three. Running two
systems in parallel essentially doubles resource consumption. During the cutover
period, the two systems consume twice the resources of a single system. This includes
twice the source documents, twice the processing time, twice the databases, and twice

19
the output production.
The advantage of parallel cutover is the reduction in risk. By running two systems, the
user can reconcile outputs to identify errors and debug errors before running the new
sys- tem solo. Parallel operation should usually extend for one business cycle, such as
one month. This allows the user to reconcile the two outputs at the end of the cycle as a
final test of the system’s functionality.

The Auditor's Role in System Implementation

External auditors are prohibited by SOX legislation from direct involvement in
systems. implementation. Being a stakeholder in all financial systems, internal auditors
should lend their expertise to this process to guide and shape the finished system.
Specifically, internal auditors may get involved in the following ways.

Provide Technical Expertise The detailed design phase involves precise specific
actions of procedures, rules, and conventions to be used in the system. In the case of
an AIS, these specifications must comply with GAAP, GAAS, SEC regulations, and IRS
codes. Failure to so comply can lead to legal exposure for the firm.

Specify Documentation Standards In the implementation phase, the auditor plays a

role in specifying system documentation. Since financial systems must periodically be
audited, they must be adequately documented.

Verify Control Adequacy and Compliance with SOX

The AIS applications that emerge from the SDLC must possess adequate controls.
In addition, compliance with SOX legislation requires management to certify the
existence and effectiveness of those controls.

Post-Implementation Review
One of the most important steps in the implementation stage actually takes place
some months later in a post-implementation review. The review is conducted by an
independent team to measure the success of the system and of the process after the
dust has settled. Although systems professionals strive to produce systems that are on
budget, on time, and meet user needs, this goal is not always attained.

Systems Design Adequacy The physical features of the system should be reviewed to
see if they meet user needs. The reviewer should seek answers to the following types of
questions

• Does the output from the system possess such characteristics of information as
relevance, timeliness, completeness, accuracy, and so on?
• Is the output in the format most useful and desired by the user (such as tables,
graphs, electronic, hard copy, and so on)?

20
• Are the databases accurate, complete, and accessible?
• Were data lost, corrupted, or duplicated by the conversion process?
• Are input forms and screens properly designed and meeting user needs?
• Are the users using the system properly?
• Does the processing appear to be correct?
• Can all program modules be accessed and executed properly, or does the user
ever get stuck in a loop?
• Is user documentation accurate, complete, and easy to follow?
• Does the system provide the user adequate help and tutorials?

Accuracy of Time, Cost, and Benefit Estimates The task of estimating time, costs,
and benefits for a proposed system is complicated by uncertainty. This is particularly
true for large projects involving many activities and long time frames.

Systems Maintenance-Phase VIII

Once a system is implemented, it enters the final phase in its life cycle. Systems
maintenance is a formal process by which application programs undergo changes to
accommodate changes in user needs. Some application changes are trivial, such as
modifying the system to produce a new report or changing the length of a data field.
Maintenance can also be extensive, such as making major changes to an application’s
logic and the user interface. Depending upon the organization, the systems
maintenance period can last 5 years or longer. Systems in highly competitive business
environments see much shorter system life spans.

CONTROLLING AND AUDITING THE SDLC

In this chapter we have reviewed the highly technical and complex processes
that constitute the SDLC. Before proceeding, it is useful to place this material in
perspective with regard to audit objectives. Simply stated, the purpose of a financial
audit is to provide an expert opinion regarding the fair presentation of the financial
statements.
The systems development and maintenance process is common to all applications. A
properly functioning systems development process ensures that only needed
applications are created, that they are properly specified, that they possess adequate
controls, and that they are thoroughly tested before being implemented. The systems
maintenance process ensures that only legitimate changes are made to applications
and that such changes are also tested before being implemented.

Controlling New Systems Development

The first five controllable activities discussed next deal with the authorization,
development, and implementation of the original system. The last two controllable

21
activities pertain to systems maintenance procedures.

Systems Authorization Activities

All systems must be properly authorized to ensure their economic justification and
feasibility. As with all material transactions, authorizing the development of a new
information system should be a formal step in the process.

User Specification Activities

Users must be actively involved in the systems development process. Their
involvement should not be stifled because the proposed system is technically complex.
Technical Design Activities
The technical design activities translate the user specifications into a set of detailed
technical specifications of a system that meets the user’s needs.

Internal Audit Participation

The internal auditor plays an important role in the control of systems development
activities, particularly in organizations whose users lack technical expertise. The internal
auditor can serve as a liaison between users and the systems professionals to ensure
an effective transfer of knowledge.

User Test and Acceptance Procedures

Just before implementation, the individual modules of the system must be tested
as a unified whole. A test team comprising user personnel, systems professionals, and
internal audit personnel subjects the system to rigorous testing. Once the test team is
satisfied that the system meets its stated requirements, the system is formally accepted
by the user department(s).

Audit Objectives Related to New Systems Development

• Verify that SDLC activities are applied consistently and in accordance with
management’s policies.
• Determine that the system as originally implemented was free from material
errors and fraud.
• Confirm that the system was judged to be necessary and justified at various
checkpoints throughout the SDLC.
• Verify that system documentation is sufficiently accurate and complete to
facilitate audit and maintenance activities

Audit Procedures Related to New Systems Development

The auditor should select a sample of completed projects (completed in both the current

22
period and previous periods) and review the documentation for evidence of compliance
with SDLC policies. Specific points for review should include determining the following:
• User and computer services management properly authorized the project.
• A preliminary feasibility study showed that the project had merit.
• A detailed analysis of user needs was conducted that resulted in alternative
general designs.
• A cost-benefit analysis was conducted using reasonably accurate figures.
• The project's documentation shows that the detailed design was an appropriate
and accurate solution to the user's problem.
• Test results show that the system was thoroughly tested at both the individual
module and the total system level before implementation. (To confirm these test results,
the auditor may decide to retest selected elements of the application.)
• There is a checklist of specific problems detected during the conversion period,
along with evidence that they were corrected in the maintenance phase.
• Systems documentation complies with organizational requirements and
standards.

The Controlling Systems Maintenance

The last two controllable activities pertain to systems maintenance. Upon
implementation, the system enters the maintenance phase of the SDLC. This is the
longest period in the SDLC, often spanning several years. It is important to recognize
that systems do not remain static throughout this period. Rather, they may undergo
substantial changes that constitute a financial outlay many times their original cost. If an
application has undergone maintenance (and even if it has not), its integrity may have
been compromised since implementation. The auditor’s review may, therefore, extend
into the maintenance phase to determine that application integrity is still intact.

Maintenance Authorization, Testing, and Documentation

The benefits achieved from controlling new system development can be quickly
lost during system maintenance if control does not continue into that phase. Access to
systems for maintenance purposes increases the possibility of systems errors, Logic
may be corrupted either by the accidental introduction of errors or intentional acts to
defraud.

Source Program Library Controls

In spite of the preceding maintenance procedures, application integrity can be
jeopardized by individuals who gain unauthorized access to programs. The remainder of
this section deals with control techniques and procedures for preventing and detecting
unauthorized access to application programs. In larger computer systems, application
program source code is stored on magnetic disks called the source program library
(SPL). Therefore, the SPL is a sensitive area, which, to preserve application integrity,
must be properly controlled.

The Worst-Case Situation: No Controls

23
1. Access to program is completely unrestricted. Programmers and others can
access any programs stored in the library, and there is no provision for detecting an
unauthorized intrusion.

2. Because of these control weaknesses, programs are subject to unauthorized

changes. Hence, there is no basis for relying on the effectiveness of other controls
(maintenance authorization, program testing, and documentation).
Control is always in conflict with operational flexibility and efficiency. For these reasons,
systems professionals who must work daily within this environment sometimes oppose
controlling the SPL.

A Controlled SPL Environment

To control the SPL, protective features and procedures must be explicitly addressed,
and this requires the implementation of an SPL. Management system (SPLMS). The
black box surrounding the SPL. Signifies the SPLMS. This software is used to control
four routine but critical functions: (1) storing programs on the SPL, (2) retrieving
programs for maintenance purposes, (3) deleting obsolete programs from the library,
and (4) documenting program changes to provide an audit trail of the changes.
You may have recognized the similarities between the SPI. Management system
and a database management system. This is a valid analogy, the difference being that
SPL software manages program files and DBMSs manage data files. SPLMSs may be
supplied by the computer manufacturer as part of the operating system or may be
purchased through software vendors. Some organizations, to provide special control
features, develop their own SPL software

24
Password Control
Assigning passwords provides one form of access control over the SPL. This is
similar to password controls used in a DBMS to protect data files. Every financially
significant program stored in the SPL. Can be assigned a separate password. As
previously discussed, passwords have drawbacks. When more than one person is
authorized to access a program, preserving the secrecy of a shared password is a
problem.

Separate Test Libraries

Figure 5.13 illustrates an improvement on the shared pass word approach through
the creation of separate password-controlled libraries (or directories) for each
programmer. A relatively cost-free enhancement to this control feature is the
implementation of program naming conventions. The name assigned a program clearly
distinguishes it as being either a test or a production program.

Audit Trail and Management Reports

An important feature of SPL. Management software is the creation of reports that
enhance management control and the audit function. The most useful of these are
program modification reports, which describe in detail all program changes (additions
and deletions) to each module. These reports should be part of the documentation file
of each application to form an audit trail of program changes over the life of the
application.

Program Version Numbers.

25
 The SPLMS assigns a version number automatically to each program stored on the
SPL. When programs are first placed in the libraries (upon implementation), they are
assigned a version number of 0. With each modification to the program, the version
number is increased by 1. An unauthorized change is signaled by a version number on
the production load module that cannot be reconciled to the number of authorized
changes.

Controlling Access to Maintenance Commands

SPL management systems use powerful maintenance commands to alter or eliminate
program passwords, alter the pro gram version (modification) number, and temporarily
modify a program without generating a record of the modification. There are legitimate
technical reasons why systems designers and administrators need these commands.

Audit Objectives Related to System Maintenance

● Detect unauthorized program maintenance (which may have resulted in
significant processing errors or fraud). Determine that (1) maintenance
procedures protect applications from unauthorized changes, (2) applications are
free from material errors, and (3) program libraries are protected from
unauthorized access.

Audit Procedures Related to System Maintenance

26
Identify Unauthorized Changes To establish that program changes were authorized,
the auditor should examine the audit trail of program changes for a sample of
applications that have undergone maintenance. The auditor can confirm that
authorization procedures were followed by performing the following tests of controls.

● Reconcile program version numbers - The permanent file of the application

should contain program change authorization documents that correspond to the
current version number of the production application

● Confirm maintenance authorization - The program maintenance authorization

documents should indicate the nature of the change requested and the date of
the change. It should also be signed and approved by the appropriate
management from both computer services and the user departments.

Identify Application Errors.

The auditor can determine that programs are free from material errors by performing
three types of tests of controls: reconciling the source code, reviewing the test results,
and retesting the program.

● Reconcile the source code Each application’s permanent file should contain the
current program listing and listings of all changes made to the application. These
documents describe in detail the application’s maintenance history.

● Review test results Every program change should be thoroughly tested before
being implemented. Program test procedures should be properly documented by
test objectives, test data, and processing results, which support the
programmer’s decision to implement the change

● Retest the program The auditor can retest the application to confirm its integrity.
We examine several techniques for application testing in Chapter 7.

Test Access to Libraries

The existence of a secure program library is central to preventing errors and
program fraud. One method is to assign library access rights exclusively to individuals
who act as librarians. Their function is to retrieve applications from the program libraries
for maintenance and to restore the modified programs to the library.

● Review programmer authority tables The auditor can select a sample of

programmers and review their access authority. The programmer’s authority
table will specify the libraries a programmer may access.

● Test authority table The auditor should simulate the programmer’s access

27
 privileges and then violate the authorization rules by attempting to access
unauthorized libraries.

SUMMARY

One of the most valuable assets of the modern business organization is a

responsive, user-oriented information system. A well-designed system can increase
productivity, reduce inventories, eliminate non value-added activities, improve customer
service and management decisions, and coordinate activities throughout the
organization.
This chapter examined the purpose, control, and audit of the systems development
life cycle. It began by describing the roles of the participants involved in systems
development, including systems professionals, users, and stakeholders. Then it outlined
the key activities associated with SDL.C. This process consists of two primary sets of
activities: new systems development and maintenance. The former, which is used to
guide the development of information systems in many organizations, includes systems
planning. systems analysis, conceptual design, system selection, detailed design,
system programming and testing, and system implementation. A properly functioning
systems development process ensures that only needed applications are created, that
they are properly specified, that they possess adequate controls, and that they are
thoroughly tested before being implemented. Upon implementation, new systems enter
the systems maintenance phase, where they remain until they are terminated and
ultimately replaced. The systems maintenance process ensures that only legitimate
changes are made to applications and that such changes are also tested before being
implemented.
The systems development and maintenance process is common to all applications.
Together, they establish the accuracy of new applications and preserve their integrity
throughout the period under review.
The auditor's objective in testing controls over these processes is to establish
application integrity and thus limit the tests of application controls and substantive
testing that needs to be done.

28
29