SYSTEM

DEVELOPMENT
AND PROGRAM
CHANGE
ACTIVITIES
THE SYSTEM DEVELOPMENT LIFE CYCLE
is a structured, approach to developing
software or systems encompassing all phases
from initial planning and requirements
gathering to deployment and maintenance,
ensuring a well managed and efficient
development process.
SYSTEM PLANNING --PHASE 1
WHO SHOULD DO SYSTEM 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.
STRATEGIC SYSTEMS PLANNING
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.
PROJECT PLANNING
Aligns resources with the strategic plan by identifying
needs, assessing feasibility, prioritizing projects, and
scheduling tasks. It's 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.
SYSTEM ANALYSIS --PHASE 2
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 Current physical tar pit. This

OF SURVEYING
term describes the analyst
getting overly absorbed and

THE CURRENT
delayed by surveying the
outdated system.

STEPS Thingking 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
conversation during implementation.
Isolating the root of problem symptoms. Surveying the current system
enables analysts to pinpoint the root causes of reported problems.
 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 describes key
features, situations, and relationships of the system. System facts fall
into the following broad classes.

Data sources • control

users. • transaction volumes
Data stores • Error rates
Processes • Resource costs
data flows • 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.
 TASKS 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
followin:
-Organizational charts -Transaction listings
-Job descriptions - Budgets
-Accounting records - Forecasts
-Charts of Account - Mission statements
-Policy statement
-performance Reports
-System Flowcharts
-Source Documents
 THE ANALYSIS STEP
System analysis is an intellectual process that is commingled with fact gathering. The
analyst is simultaneously analyzing as he or she gather 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 system 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.
 THE AUDITORS 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 (CAATs) 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 format
 THE OBJECT ORIENTED APPROACH
The object-oriented design (OOD) approach is to build information
systemsfrom
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 similarneeds.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 AUDITORS 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 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 thisdecision-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.
1.PERFORM A DETAILED FEASIBILITY STUDY
4. Operational Feasibility - shows the degree of compatibility between the
firm's existing procedures and personnel skills and the operational
requirements of the 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 Recurring costs include the
following: following:
Hardware acquisition Hardware maintenance
Site preparation Software maintenance
Software acquisition Insurance
Systems Design Supplies
Programming and testing Personnel costs
data conversion
Training
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 list some common categories of intangible benefits.
3. Compare Costs and Benefits. The two 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.
 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
auditorshould ensurefive 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
In this phase, all system components (user views, database tables,
processes and controls) are meticulously specified.
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.
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.
 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).
 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.
1. Procedural Languages - requires the programmer to specify the
precise order in which the program logic is executed.
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.
3. Object-oriented Languages - central to achieving the benefits
of the object oriented approach is developing software in an
object -oriented programming 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.
Three benefits associated with modular programming.
. 1. Programming efficiency
. 2. Maintenance efficiency
. 3. Control
 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.
1. Testing Methodology
2. Testing offline before Deploying Online
3. Test data
 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.
a. Designer and Programmer Documentation. Systems designer
and programmers need documentation to debug errors and
perform maintenance on the system.
System flowchart
Program flowchart
Program Code
 b. Operator Documentation.
. 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, andoutput 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 - user need documentation describing how
to use the system.
The following is one possible 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

. Commonly found online features include

1. Tutorials - can be used to train the novice or the occasional user.
2. Help Features - 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.
1. Validation - the old data must be validated before conversion.
2. Reconciliation- After the conversion action, the new database
must be reconciled against the original.
3. Backup- Copies of the 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 cutover.

cold turkey Cutover -also called the '' Big Bang'' approach,
the firm switches to the new system and simultaneously
terminate old system.
Phased Cutover - Sometimes an entire system cannot or need
not be cut over at once.
Parallel Operation Cutover- involves running the old system
and the new system simultaneously for a period of time.
 The Auditor's role in System Implementation
External auditors are prohibited by SOX legislation from direct involvement
in systems.
Provide Technical Expertise
Specify Documentation Standards
Verify Control Adequacy and Compliance with SOX
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.
Systems Design Adequacy.
• 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)
• 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?
SYSTEM MAINTENANCE -- PHASE VIII
-Systems maintenance is a formal process by which
application programs undergo changes to accommodate
changes in user needs.
-Maintenance can also be extensive, such as making
major changes to an application’s logic and the user
interface. Depending upon the organization, the
systemsmaintenance period can last 5 years or longer.
Systems in highly competitive businessenvironments see
much shorter system life span
CONTROLLING AND AUDITING THE SDLC
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
activities pertain to systems maintenance procedures.
Systems Authorization Activities
User Specification Activities
Technical Design Activities
Internal Audit Participation
user test and Acceptance procedures
Audit Objectives Related to New Systems Development
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.
 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
A CONTROLLED SPL ENVIRONMENT
Password Control
Separate Test Libraries
Audit Trail and Management Reports
Program Version Numbers
Controlling access to Maintenance
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
arefree from material errors, and (3) program libraries are protected from
unauthorized access.

IDENTIFY UNAUTHORIZED CHANGES

Reconcile program version numbers

confirm maintenance authorization
 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
Review test results
Retest the program
TEST ACCESS TO LIBRARIES
Review programmer authority tables
Test authority table
THANK YOU