SYSTEMS DEVELOPMENT AND PROGRAM CHANGE ACTIVITIES

I. PARTICIPANTS IN SYSTEMS DEVELOPMENT

Four Broad Groups

1. Systems Professionals
o gather facts about problems with the current system, analyze these facts
and formulate a solution to solve the problems
o include: systems analysts, systems engineers and programmers

2. End Users
o for whom the system is built

3. Stakeholders
o individuals either within or outside the organization who have an interest in
the system but are not end users

4. Accountants/Auditors
o those professionals who address the controls, accounting, and auditing
issues for systems development

Why are accountants and auditors involved with SDLC?

 The creation of an information system entails significant financial
transactions.
 Accountants and auditors concern is with the nature of the products
that emerge from the SDLC.

How are accountants involved with the SDLC?

 Accountants are users.
 Accountants participate in systems development as members of the
development team.
 Accountants are involved in systems development as auditors.

II. INFORMATION SYSTEM ACQUISITION

1. In-House Development
o requires maintaining a full systems staff of analysts and programmers who
identify user information needs and satisfy their needs with custom
systems.

2. Commercial Systems
o systems are purchased from software vendors

Factors that stimulated the growth of commercial software market:

a. relatively low cost of general commercial software as compared to
customized software
b. emergence of industry-specific vendors who target their software to the
needs of particular types of businesses
c. a growing demand from businesses that are too small to afford in-house
systems’ development staff

Systems Development and Program Change Activities | 1

 d. trend towards downsizing of organizational units and the resulting move
toward the DDP environment

Types of Commercial Systems

a. Turnkey Systems
 completely finished and tested systems that are ready for
implementation
b. General Accounting Systems
 designed to serve a wide variety of user needs
c. Special-Purpose Systems
 target selected segments of the economy
d. Office Automation Systems
 improve the productivity of office workers
e. Backbone Systems
 provide a basic system structure on which to build
 vendor designs and programs the user interface to suit the client’s
needs
f. Vendor-Supported Systems
 hybrids of custom systems and commercial software
 vendor develops and maintains custom systems for its clients

Advantages of Commercial Software

a. Implementation Time
b. Cost
c. Reliability

Disadvantages of Commercial Software

a. Independence
b. Need for Customized Systems
c. Maintenance

III. SYSTEMS DEVELOPMENT LIFE CYCLE

PHASE I – SYSTEMS PLANNING

Objective:
 to link individual system projects or applications to the strategic objectives of
the firm

Who should do Systems Planning?

 Systems Steering Committee
– provide guidance and review the status of system projects

Responsibilities:
a. Resolving conflicts that arise from new systems
b. Reviewing projects and assigning priorities
c. Budgeting funds for systems development
d. Reviewing the status of individual projects under development
e. Determining at various checkpoints throughout the SDLC whether to
continue with the project or terminate it

Systems Development and Program Change Activities | 2

Two Levels:
1. Strategic Systems Planning
o involves the allocation of systems resources at the macro level
o similar to budgeting resources for other strategic activities
o deals with a time frame of 3-5 years

Why perform?
a. A plan that changes constantly is better than no plan at all
b. Strategic planning reduces the crisis component in systems
development
c. Strategic systems provides planning authorization control for the SDLC
d. Cost management

2. Project Planning
o purpose: to allocate resources to individual applications within the
framework of the strategic plan

Two formal documents:

a. Project Proposal
 provides management with a basis for deciding whether to
proceed with the project
purpose:
- it summarizes the findings of the study conducted to this point
into a general recommendation for a new or modified system
b. Project Schedule
 represents management’s commitment to the project
 a budget of the time and costs for all the phases of the SDLC

Auditor’s Role in Systems Planning

 ensures that adequate systems planning takes place, since planning greatly
reduces the risk that an organization has produced unneeded, inefficient
ineffective, and fraudulent systems

PHASE II – SYSTEMS ANALYSIS

Two-Step Process
1. Survey of the current system
2. Analysis of the user’s needs

Survey Step
 involves a detailed system survey
 facts pertaining preliminary questions about the system are gathered and
analyzed

Advantages
a. Identifying what aspects of the old system should be kept
b. Forcing systems analysts to fully understand the system
c. Isolating the root of problem symptoms

Disadvantages
a. Current physical tar pit
b. Thinking inside the box

Systems Development and Program Change Activities | 3

Broad Classes of Systems Facts
1. Data Sources
 include external entities as well as internal sources from other
departments
2. Users
 include both managers and operations users
3. Data Stores
 files, databases, accounts, and source documents used in the system
4. Processes
 manual or computer operations that represent a decision or an action
triggered by information
5. Data Flows
 movement of documents and reports between data sources, data stores,
processing tasks and users
6. Controls
 include both accounting and operational controls and may be manual
procedures or computer controls
7. Transaction Volumes
 capacity of systems
8. Error Rates
 acceptable error tolerances
9. Resource Costs
 resources used the current system
10. Bottlenecks and Redundant Operations

Fact-Gathering Techniques
1. Observation
 involves passively watching the physical procedures of the system
2. Task Participation
 the analyst takes an active role in performing the user’s work
3. Personal Interviews
a. Open-ended Questions
b. Questionnaires
4. Reviewing Key Documents

Analysis Step
 the analyst is simultaneously analyzing as he gathers facts, therefore it is difficult
to identify where survey ends and analysis begins

Systems Analysis Report

 presents to management or the steering committee the survey findings, the
problems identified with the current system, the user’s needs, and the
requirements of the new system

Auditor’s Role in Systems Analysis

 accountant/auditor should be involved in the needs analysis of the proposed
system to determine if it is a good candidate for advanced audit features and
which features are best suited for the system

Systems Development and Program Change Activities | 4

PHASE III – CONCEPTUAL SYSTEMS DESIGN

Purpose:
 to produce several alternative conceptual systems that satisfy the systems
requirements identified during systems analysis

Two Approaches to Conceptual Systems Design:

1. Structured Design Approach
2. Object-Oriented Approach

Structured Design Approach

 consists of starting with the “big picture” of the proposed system that is gradually
decomposed into more and more detail until it is fully understood

Object-Oriented Approach
 building information systems from reusable standard components or objects

Auditor’s Role in Conceptual Systems Design

 auditor is a stakeholder in all financial systems and has an interest in the
conceptual design stage of the system
 auditability of a system depends in part on its design characteristics

PHASE IV – SYSTEM EVALUATION AND SELECTION

Two Steps:
1. Perform a detailed feasibility study
2. Perform a cost-benefit analysis

Perform a Detailed Feasibility Study

 by assessing the major constraints on the proposed system, management can
evaluate the project’s likelihood for success, before committing large amounts of
financial and human resources

Five Aspects
1. Technical Feasibility
o concerned with whether the system can be developed under existing
technology or if new technology is needed
2. Economic Feasibility
o pertains to the availability of funds to complete the project
3. Legal Feasibility
o identifies any conflicts between the conceptual system and the
company’s ability to discharge its legal responsibilities
4. Operational Feasibility
o shows the degree of compatibility between the firm’s existing procedures
and personnel skills and the operational requirements of the new system
5. Schedule Feasibility
o relates to the firm’s ability to implement the project within an acceptable
time

Systems Development and Program Change Activities | 5

Perform a Cost-Benefit Analysis
 helps management determine whether the benefits received from a proposed
system will outweigh its costs

Steps:
1. Identify Costs
a. one-time costs
b. recurring costs
2. Identify Benefits
a. tangible benefits
b. intangible benefits
3. Compare Costs and Benefits
o common methods:
a. Net Present Value Method
b. Payback Method

Prepare Systems Selection Report

 consists of a revised feasibility study, a cost-benefit analysis, and a list and
explanation of intangible benefits for each alternative design

Auditor’s Role in Evaluation and Selection

 primary concern is that economic feasibility of the proposed system is measured
as accurately as possible
 ensure that:
 only acceptable costs are used in calculations of cost savings benefit
 reasonable interest rate are used in measuring present values of cash
flows
 one-time and recurring costs are completely and accurately reported
 realistic useful lives are used in comparing competing projects
 intangible benefits assigned reasonable financial values

PHASE V – DETAILED DESIGN

Purpose:
 to produce a detailed description of the proposed system that both satisfies the
system requirements identified during systems analysis and in accordance with
the conceptual design

Perform a System Design Walkthrough

 to ensure that the design is free from conceptual errors that could become
programmed into a final system
 may be performed by a Quality Assurance Group
*Quality Assurance Group – stimulate the operation of the system to uncover
errors, omissions and ambiguities in the design

Review System Documentation

 detailed design report documents and describes the system to this point
 includes:
1. designs for all screen inputs and source documents for the system
2. designs for all screen outputs, reports and operational documents
3. normalized data for database tables
4. database structures and diagrams

Systems Development and Program Change Activities | 6

 5. updated data dictionary describing each data element in the database
6. processing logic (flow charts)

PHASE VI – APPLICATION PROGRAMMING AND TESTING

Program the Application Software

 select a programming language from among the various languages available and
suitable for the application
1. Procedural Languages
2. Event-Driven Languages
3. Object-Oriented Programming

 Programming the System – modern programs should follow a modular approach,

which produces small programs that perform narrowly defined tasks
benefits:
a. Programming Efficiency
b. Maintenance Efficiency
c. Control

Test the Application Software

1. Testing Methodology
 involves creating hypothetical master files and transaction files that are
processed by the modules being tested and the results of the tests are
then compared against predetermined results to identify programming and
logic errors
2. Testing Offline before Deploying Online
 implementing a system without testing offline is an invitation to disaster
3. Test Data
 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

PHASE VII – SYSTEMS IMPLEMENTATION

 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

Testing the Entire System

 user personnel should direct system-wide testing as a prelude to the formal
system implementation

Documenting the System

 system documentation provides the auditor with essential information about how
the system works
1. Designer and Programmer Documentation
2. Operator Documentation
3. User Documentation

Systems Development and Program Change Activities | 7

Converting the Databases
 transfer of data from its current form to the format or medium required by the new
system
Precautions to be taken:
a. Validation
b. Reconciliation
c. Backup

Converting to the New System

 cutover – process of converting from the old system to the new one

Approaches:
a. Cold Turnkey Cutover
 the firm switches to the new system and simultaneously terminates the
old system
b. Phased Cutover
 the entire system need not be cutover at once
c. Parallel Operation Cutover
 involves running the old system and the new system simultaneously

Auditor’s Role in System Implementation

a. Provide Technical Expertise
b. Specify Documentation Standards
c. Verify Control Adequacy and Compliance with SOX

Post-Implementation Review
 review is conducted by an independent team to measure the success of the
system and of the process after the dust has settled
 post-implementation evidence:
a. Systems Design Adequacy
b. Accuracy of Time, Cost and Benefit Estimates

PHASE VIII – SYSTEMS MAINTENANCE

 a formal process by which application programs undergo changes to
accommodate changes in user needs

Systems Development and Program Change Activities | 8

Systems Development Life Cycle

Systems Development and Program Change Activities | 9

IV. CONTROLLING AND AUDITING THE SDLC

A. Controlling New Systems Development

Systems Authorization Activities
o all systems must be properly authorized to ensure their economic
justification and feasibility

User Specification Activities

o users must be actively involved in the systems development process

Technical Design Activities

o translate the user specification into a set of detailed technical
specifications of a system that meets the user’s needs
o adequacy of these activities is measured by the quality of documentation
that emerges from each phase

Internal Audit Participation

o internal auditor can serve as a liaison between users and the systems
professionals to ensure an effective transfer of knowledge
o auditor should become involved at the inception of the process to make
conceptual suggestions regarding system requirements and controls

User Test and Acceptance Procedures

o before implementation, the individual modules of the system must be
tested as a unified whole
o formal testing and acceptance of the system by the user is considered
by many auditors as to be the most important control over the SDLC

Audit Objectives
a. verify that SDLC activities are applied consistently and in accordance
with management’s policies
b. determine that the system as originally implemented was free from
material errors and fraud
c. confirm that the system was judged to be necessary and justified at
various checkpoints throughout the SDLC
d. verify the system documentation is sufficiently accurate and complete to
facilitate audit and maintenance activities

Audit Procedures
o auditor should select a sample of completed projects and review the
documentation for evidence of compliance with SDLC policies
Specific Points for Review:
a. proper authorization of the project
b. preliminary feasibility
c. detailed analysis of user needs
d. cost-benefit analysis using reasonably accurate figures
e. project’s documentation shows that detailed design was appropriate
and accurate solution to problem
f. test results at both the individual module and the total system level
g. checklist of specific problems along with evidence that they were
corrected
h. systems documentation complies with requirements and standards

Systems Development and Program Change Activities | 10

B. Controlling Systems Maintenance

Minimizing the Potential Exposure

 all maintenance actions should require four controls:
a. Formal Authorization
b. Technical Specification of the Changes
c. Retesting the System
d. Updating the Documentation

Source Program Library (SPL) Controls

 SPL is a sensitive area, which, to preserve application integrity, must be
properly controlled

SPL without Controls:

a. Access to programs is completely unrestricted
b. Programs are subject to unauthorized changes

Controlled SPL Environment

a. Password Control
 assigning passwords provides one form of access controls over
the SPL to protect data files
b. Separate Test Libraries
 programs are copied into the programmer’s library for
maintenance and testing
c. Audit Trail and Management Reports
 important feature of SPL management software is the creation
of reports that can be part of the documentation file of each
program to form an audit trail of program changes over the life
of the application
d. Program Version Numbers
 SPL management software assigns a version number
automatically to each program stored on the SPL
 when programs are first placed in the libraries, version number
is 0; and with each modification, the version number is
increased by 1
e. Controlling Access to Maintenance Commands
 access to the maintenance commands themselves should be
password-controlled, and the authority to use them should be
controlled by management or the security group

Audit Objectives
 detect unauthorized program maintenance
 determine that maintenance procedures protect applications from
unauthorized changes
 determine that applications are free from material errors
 program libraries are protected from unauthorized access

Audit Procedures
1. Identify Unauthorized Changes
a. Reconcile program version numbers
b. Confirm maintenance authorization

Systems Development and Program Change Activities | 11

 2. Identify Application Errors
a. Reconcile the source code
b. Review test results
c. Retest the program

3. Test Access to Libraries

a. Review programmer authority tables
b. Test authority table

REFERENCES:

Systems Development and Program Change Activities | 12