CHAPTER 5

SYSTEM DEVELOPMENT AND PROGRAM CHANGE ACTIVITIES

The learning objectives of this chapter is to identify how business acquire there information
system, to be able to identify and understand the stages in the systems development life cycle and
understand the risk, controls, and audit issues related to systems development and maintenance
procedures.
We will be starting this chapter on what is system development process and how the business
acquire its information systems and there advantages and disadvantages. This chapter will focuses on
System Development Life Cycle and Controlling and Auditing the SLDC. The two stages of system
development process or the systems development life cycle (SDLC) which are; fist, the “New systems
development” compose of seven phases which are systems planning, systems analysis, conceptual design,
systems selection, detailed design, programming and testing, and implementation, and second, the
“Program change procedures” compose of one phase which is maintenance.
System development process constitutes a set of activities by which organizations obtain IT-
based information systems. Auditors are interested in this activity because they want to ensure the
integrity of this process and to know the quality of accounting information presented in an organization’s
financial statements. The participants in this activity are the system professionals, end users and
stakeholders.
Most business acquire there information systems in either two ways which are “In-house
development” or “Commercial systems”. In-house development are systems that are highly unique
operations in short this systems are made only for the company while commercial systems are systems
that where purchased from software vendors.
Commercial software is group into three which are the “Turnkey systems”, “Backbone systems”,
and “Vendor-supported systems”. Turnkey systems are systems that are finished and tested systems that
are ready for implementation just like general accounting systems, special-purpose systems and office
automation systems. Backbone systems are systems that are designed and programmed the user interface
to suit the user’s needs. Vendor-supported systems are custom systems that the vendor develops and
maintains for the client organization.
Advantages of commercial software is that it can be implemented immediately once needed, it is
less costly and lastly it’s less likely to have an errors; in the other way around the disadvantages of
commercial software is that the firm is dependent on the vendor for maintenance, it is too general or too
inflexible, and lastly it is difficult to modify. Advantages of in-house development is that the firm will no
longer depend on the vendor for maintenance, it had the ability to produce applications, and lastly it
provides users with proprietary applications that can be economically maintained while the disadvantages
is that it take long time to develop, more costly and it is more likely to have an errors.

Phase 1: System Planning

 The first phase in the new system development is systems planning in which it link individual
system projects or applications to the strategic objectives of the firm. The one in charge in system
planning is the steering committee that is responsible to provide guidance and review the status of system
projects. The systems planning compose of two levels, the “Strategic systems planning” and “Project
planning”
First, strategic systems planning involve the allocation of systems resources at the macro level. If
technically speaking, strategic system planning is not part of SDLC because SDLC pertains to specific
application while strategic systems plan is more concerned with the allocation of systems, such as
employees, hardware, software and telecommunications. But why we still perform strategic systems
planning if it is not part of SDLC, we need to still perform strategic systems planning because it is better
to have a plan that changes than to have no plan at all, it helps to identify and prioritize user needs, it lays
out authorization rules to ensure that decisions to develop specific systems are congruent with the
objective of the firm and system planning is cost-effective. Second, project planning is to allocate
resources to individual applications within the framework of the strategic plan.
The output or product of this phase is project proposal and project schedule. Project proposal is a
proposal that summarizes the finding of the study conducted for new or modified systems and the outlines
of linkage between the objectives of the proposed systems and business objectives that provides decision
to the management whether to proceed with the project. Project schedule is the budget of the time and
costs for all the phases of SDLC and represents the management’s commitment to the project.

Phase 2: System Analysis

The second phase is the system analysis, a two-step process involving a survey of the current
system and then an analysis of the user’s need. Surveying the current systems will know the elements in
the current system should be preserved as part of the new system. Surveying the current system help what
aspects of the old system should be kept, the analyst will be able to fully understand the system and it
may also help in isolating the root of problem symptoms, but in surveying the current systems the analyst
may take long period of time in surveying the current dinosaur system and the analyst may develop a
constrained notion about how the new system should function. In surveying the current system and
analyzing the user’s need, the analyst should gather facts that help in describing the key features,
situations, and relationships of the systems. In order for the analyst to gather facts he/she must observe
the physical procedures of the system, takes active role in performing the user’s work, having personal
interviews through open-ended questions or questionnaires, and lastly through reviewing organization’s
documents about the system being surveyed.
The output of this phase in the systems analysis report, this report represents the management or
the steering committee the survey findings, the problem identified in the current system, the user’s need
and the requirements of the new system.

Phase 3: Conceptual System Design

Purpose: To produce several alternative conceptual system.
Conceptual System design approaches:
 1. Structured Design Approach- designing system from the top down; developing new system from
the scratch
 Top down-start with the “big picture” of the proposed system then gradually decomposed into
more detailed one.
- Documented by data flow diagrams (DFDs) and structure diagram

Example: Refer to Figure 5.4 and 5.5 on page 186-187

Figure 5.4 is a traditional batch purchasing system wherein the initial input for the process is the
purchase requisition.
Figure 5.5 utilizes EDI (Electronic Data Interchange) technology. The purchases system determines
the quantity and the vendor and then transmits the order online via EDI software.
2. Object-oriented Approach-build information system from reusable standard components or
objects
Example: New models of cars are built from standard components that also go into other models.
(Engine, gearbox, rear axle)

Phase 4: System Evaluation and Selection

Purpose: To identify and select the best system from the set of alternative conceptual designs.
Steps:
1. Feasibility Study (TELOS)
a. Technical Feasibility- concerned whether the system can be developed under existing
technology or if new technology is needed.
b. Economic Feasibility- pertains to the availability of funds to complete the project.
c. Legal Feasibility- Identifies any conflicts between the conceptual system and the company’s
ability to discharge its legal responsibilities.
d. Operational Feasibility- Shows the degree of compatibility between the firm’s existing
procedures and personnel skills and the operational requirements of the new system.
e. Schedule Feasibility- relates to the firm’s ability to implement the project within an
acceptable time.
2. Cost-Benefit Analysis
 Costs
a. One-time costs- non-recurring cost incurred
- Hardware Acquisition- cost of mainframe, minicomputers, microcomputers, and peripheral
equipment.
- Site Preparation- cost of building modifications, equipment installation, and freight
charges.
- Software Acquisition
- System Design (sunk costs) - incurred by the system professionals performing the planning,
analysis, and design functions.
- Programming and Testing
- Data Conversion- arise in the transfer of data from one storage medium to another.
- Training- educating users to operate the new system.
b. Recurring costs
 - Hardware Maintenance- upgrading the computer
- Software Maintenance- upgrading and debugging operating system, purchased applications,
and in-house developed applications.
- Insurance-covers hazards and disasters.
- Supplies- routine consumption of items such as papers, magnetic disks, CDs, and general
office supplies.
- Personnel Costs- salaries of individuals who are part of the information system.
 Benefits
a. Tangible benefits- those that increases revenue and those that reduces costs
b. Intangible benefits
- Increased customer satisfaction
- Improved employee satisfaction
- More current information
- Improved decision making
- More efficient operations
 Costs vs. Benefits
a. Net present value method- present value of costs is deducted from the present value of
benefits over the life of the system
- Optimal choice is the project with greatest net present value

Example: Refer to page 193-194

b. Payback method- length of time for the system to break-even cost and benefit.

Phase 5: Detailed Design

Purpose: produce a detailed description of the proposed system that both satisfy the system
requirements identified during systems analysis and in accordance with the conceptual design. System
components are specified and formally presented in a detailed design report.
Detailed design report- set of blueprint that specify input screen formats, output report layouts,
database structures, and process logic.

* Performance of system design walkthrough is needed to ensure that the design is free from conceptual
errors that could become programmed into the final system
*quality assurance group – simulate the operation of the system to uncover errors, omissions, and
ambiguities in the design.

Phase 6: Application Programming and Testing

A programming language is a set of commands, instructions, and other syntax use to create a
software program.

Types of Programming Language

1. Procedural Languages- specifies a series of well-structured steps and procedures within its
programming context to compose a program.

Examples: COBOL, FORTRAN, C, and PL1.

 2. Event Driven Languages- designed to respond to external actions or “events” that are initiated by
the user.

Example: Microsoft Visual Basic- a programmer uses a graphical user interface (GUI) to choose
and modify preselected sections of code written in the BASIC programming language.

3. Object Oriented Languages- approach to problem-solving where all computations are carried out
using objects.

 Object- real world phenomena that possess two characteristics:

a. State- represented by stored attributes
b. Behavior- displayed through methods, which are functions or procedures that are
performed on or by the object to change the state of its attributes.

 Class and Instance

1. Class- a blueprint that defines the attributes and the methods common to all objects
of a certain type.
2. Instance- a single occurrence of an object within a class.

 Encapsulation- the act of placing data and methods in the same class and thus restricting access
to the object’s components.

 Inheritance

 Polymorphism- allows multiple and different objects to respond to the same message.

Test the Application Software

 Testing Methodology- the process itself has structured step to follow

 Testing Offline before Deploying Online
 Test Data- this will give the auditor a frame of reference for designing and evaluating future
audit tests.

Phase 7: System Implementation

In the system implementation phase of the system development process, 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
When all modules have been coded and tested, they must be brought together and tested as a
whole. The procedure involves processing hypothetical data through the system. The outputs are
reconciled with predetermined results, and the test is documented to provide evidence of the system’s
performance. When those conducting the tests are satisfied with the results, they should complete a
formal acceptance document. This is an explicit acknowledgement by the user that the system in question
meets stated requirements.
Documenting the System
The system’s documentation provides the auditor with essential information about how the
system works. The documentation requirements of the three groups are of particular importance and these
are systems designers and programmers, computer operators, and end users.
Designers and Programmers Documentation
Designers and programmers need documentation to debug errors and perform
maintenance on the system. This is provided through DFDs, ER diagrams, and structure diagrams. In
addition, systems flowcharts, program flowcharts, and program code listings are important form of
documentation.
Operator Documentation
Computer operators use documentation called a run manual, which describes how to run
the system. Typical contents of a run manual include:

 Name of the system

 Run schedule (daily, weekly, time of the day, etc.)
 Required hardware devices
 File requirements specifying all the transaction 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

For security and control purposes, the activities of programmers and operators should be
separated.

User Documentation
Users documentation describing how to use the system. 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 classification scheme:

 Novices- users have little or no experience with computers. User training and
documentation for novices must be extensive and detailed.
 Occasional users- when users once understood the system but have forgotten some
essential commands and procedures. They require less training and documentation than
novices.
 Frequent light users- are familiar with limited aspects of the system. Although functional,
they tend not to explore beneath the surface and lack depth of knowledge. This group
knows only what it needs to know and requires training and documentation for unfamiliar
areas.
  Frequent power users- understand the existing system and will readily adapt to new
systems. They like to find shortcuts and use macro commands to improve performance.
This group requires only abbreviated documentation.

Converting the Databases

It is a critical step in the implementation phase. This is a transfer of data from its current form to
the format or medium that is required by the new system. Some conversion activities are very labor
intensive, requiring data to be entered into new databases manually. In other situations, data transfer may
be accomplished by writing special conversion programs. In any case, data conversion is risky and must
be carefully controlled. The following precautions should be taken.
1. Validation. The old database must be validated before conversion. This requires analyzing
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.
3. Backup. Copies of original files must be kept as backup against discrepancies in the
converted data.

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 approach, the firm switches to the new system and simultaneously
terminates the old system. It is the easiest and least costly approach and yet the riskiest. Cold turkey
cutover is akin to skydiving without a reserve parachute. Without a back system, an organization can find
itself unable to process transactions and meet its obligation to customers and creditors.
Phased Cutover
The phase cutover begins operating the new system in modules. By phasing in the new
system in modules, we reduced the risk of a devastating system failure. However, the phased approach
can create incompatibilities between the new subsystems and yet-to-be-replaced old systems. This
problem may alleviated by implementing special conversion systems that provide temporary interfaces
during the cutover period.

Parallel Operation Cutover

It involves running the old system and the new system simultaneously for a period of
time. This is the most time consuming and costly of the three approaches. Running two systems in
parallel essentially doubles resource consumption.
The advantage of parallel cutover is the reduction of risk. By running the two systems,
the user can reconcile outputs to identify errors and debug errors before running the new system 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.
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. The post implementation review of a newly installed system can provide
management with insights into ways to improve the process for future systems. It can also provide
auditors with evidence regarding the adequacy of the SDLC in general and the risk associated with a
particular system.

PHASE 8: Systems Maintenance

Systems maintenance is a formal process by which application programs undergo changes to
accommodate changes in user needs. Depending upon the organization, the systems maintenance period
can last five years or longer. Systems in highly competitive business environments see much shorter
system life spans. If it is not feasible anymore they scrapped it and create a new system development life
cycle again.

CONTROLLING AND AUDITING THE SLDC

1. A properly functioning 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.
2. System maintenance procedures ensure that only legitimate changes are made to applications and
that those changes are also tested before being implemented.

 These two establish the accuracy of new applications and preserve their integrity throughout the
period under review.

A. CONTROLLING AND AUDITING NEW SYSTEMS DEVELOPMENT

1. Systems Authorization Activities
All systems must be properly authorized to ensure their economic justification and feasibility.

2. User Specification Activities

Users should be actively involved in the systems development process. Their involvement should not be
stifled because the proposed system is technically complex. The creation of a user specification document
often involves the joint efforts of the user and systems professionals.
3. Technical Design Activities
The scope of these activities includes systems analysis, general system design, feasibility analysis, and
detailed system design. The adequacy of these activities is measured by the quality of the documentation
that emerges from each phase. Documentation is both a control and evidence of control and is critical to
the system’s long-term success.
4. Internal Audit Participation
THE AUDITOR’S ROLE IN SYSTEMS PLANNING- It reduces the risk that an organization has
produced unneeded, inefficient, defective, or fraudulent systems. The internal auditors review the
planning process to verify that the systems produced are consistent with the organizations goal and
objectives.
THE AUDITOR’S ROLE IN SYSTEM ANALYSIS- An internal audit group astute in computer
technology and with a solid grasp of the business problems of the users serves in an essential liaison
capacity in the meeting of the minds that must occur early in the development process.
THE AUDITOR’S ROLE IN CONCEPTUAL SYSTEMS DESIGN- The internal auditor is best
qualified to determine if the system under consideration is a good candidate for an integrated audit
features which feature is best suited for the system.
AUDITOR’S ROLE IN EVALUATION AND SELECTION- The auditor should ensure five things;
1. Only escapable costs are used in calculations of savings benefits.
2. Reasonable interest rates are used in measuring present value 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.
THE AUDITOR’S ROLE IN SYSTEM IMPLEMENTATION- Internal auditors should lend their
expertise to guide and shape the finished system. The may get involved in the following ways;

 Provide Technical Expertise

 Specify Documentation Standards
 Verify Control Adequacy and Compliance with SOX

5. User Test and Acceptance Procedures

An individual modules of the system must be tested as a unified whole. A test team comprising user
personnel, system professionals and internal audit personnel subjects the system rigorous testing. The
formal testing and acceptance of the system by the user is considered by many auditors to be the most
important control over the SDLC.
AUDIT OBJECTIVES RELATED TO NEW SYSTEM 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 check-points
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

 End user and IT 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.

B. THE CONTROLLING AND AUDITING SYSTEMS MAINTENANCE

 Upon implementation, the system enters the maintenance phase and this is the longest period in
SDLC.
 Systems do not remain static throughout period rather, they may undergo substantial changes that
constitute financial outlay.
 Auditor’s review should extend into maintenance phase to determine that application integrity is
still intact.

1. Maintenance Authorization, Testing, and Documentation

Four controls to minimize the possible increase of systems errors or intentional acts to defraud:

 Formal Authorization
 Technical Specification of the changes
 Retesting the system
 Updating the documentation

2. Source Program Library Controls

- Where application source code is stored on magnetic disks (large computer systems)
- Sensitive area, which, to preserve application integrity, must be properly controlled

A. The Worst-Case Situation: No Controls

- SPL without controls has the potential to create the following two serious forms of exposure:
a. Access to programs is completely unrestricted
b. Programs are subject to unauthorized changes
- To achieve a mutually acceptable control flexibility between the needs of systems professionals
and auditors, both must understand the exposures that are created when control features are not
employed.
- The no controls approach is often the choice that management makes
B. A Controlled SPL Environment
- Requires implementation of an SPL management system
- Used to control four routine but critical functions:
a. Storing programs on the SPL
b. Retrieving programs for maintenance purposes
c. Deleting obsolete programs from the library
d. Documenting program changes to provide an audit trail of the changes
 SPL Management Database
Systems Management
System
Manages program Manages data files
files

 Password Control
- Provides one form of access control over the SPL
- When more than one person is authorized to access a program, preserving the secrecy of a shared
password is a problem
 Separate Test Libraries
- Programs are copied into the programmer’s library for maintenance and testing
- This technique greatly reduces the risk of accidentally running an untested version of program in
place of the production program
 Audit trail and Management Reports
- Creation of reports that enhance management control and the audit function (modification
reports-most useful)
- These reports should be part of documentation file of each application to form an audit trail
 Program Version Numbers
- When combined with the audit trail reports provides evidence in identifying unauthorized
changes to program modules
 Controlling Access to Maintenance Commands
- Use powerful maintenance commands to alter or eliminate program passwords, alter program
verification number and temporarily modify a program without generating a record of the
modification
- Should be controlled by management or the security group

Audit Procedures Related to System Maintenance

 Identify Unauthorized changes

a. Reconcile program version numbers
- Permanent file of the application should contain program change authorization documents that
correspond to the current version number of the production application
b. Confirm maintenance authorization
- The program maintenance authorization documents should indicate the nature of the change
requested and the date of the change
- Signed and approved by appropriate management
 Identify Application Errors
a. Reconcile the source code
- Auditor should select a sample of applications and reconcile each program change with the
appropriate authorization documents
- The reduced complexity of these modules enhances the auditor’s ability to identify irregularities
that indicate errors, omissions, and fraud
b. Review test results
- Program change should be tested before implementing
 - Program test procedures should be documented
c. Retest the program
- To confirm its integrity
 Test Access to Libraries
a. Review programmer authority tables
- Programmer’s authority table will specify the libraries a programmer may access and should be
matched against the programmer’s maintenance authority to ensure that no irregularities exist
b. Test authority table
- Auditor should simulate the programmer’s access privileges and then violate the authorization
rules by attempting to access unauthorized libraries.

QUESTIONS:
1. The steering committee is the one in charge in systems planning. TRUE
2. This is the foundation for the rest of the system development and life cycle. SYSTEMS
ANALYSIS
3. Users who have little or no experience with computers. NOVICES
4. Under this approach, the firm switches to the new system and simultaneously terminates the old
system. COLD TURKEY APPROACH
5. Which of these are performed in the analysis phase?
a. Approve all project requests
b. Perform detailed analysis of the old system
c. Build a prototype
d. Review and allocate resources to the project
6. Acquire hardware and software is done in which phase?
a. Planning
b. Analysis
c. Design
d. Implementation
7. Which one is incorrect feasibility assessment?
a. Technology Feasibility
b. Technical Feasibility
c. Economic Feasibility
d. Operation Feasibility
8. Conduct preliminary investigation and perform detailed analysis are the two major activities in
maintenance. FALSE
9. Checks for errors, bugs and interoperability. The goal is to ensure that defects are recognized as
soon as possible. This is part of TESTING.
10. Select all the ways in which a system analyst can gather information about a current system.
a. Interviews
b. Questionnaires
c. Observation
d. Inspection of records
e. All of the above