XAUDCIS

HOLY ANGEL UNIVERSITY

 Systems Professionals (for internally developed systems)
◦ Systems analysts
◦ Systems designers
◦ Programmers
 End Users
◦ Managers
◦ Operations personnel
◦ Accountants *
◦ Internal auditors *
 Stakeholders
◦ Accountants *
Note Accountants & Internal
◦ Internal auditors * Auditors fill multiple roles.
◦ External auditors

2
 Creation/purchase of IS consumes
significant resources and has financial
resource implications.
 Quality of AISs and their output rests
directly on SDLC activities that produce
them.

3
 As Users
 As members of
development team
 As Auditors

4
 Systems Strategy
◦ Help reduce risk of creating unneeded,
unwanted, inefficient, ineffective systems
 Conceptual Design
◦ Control implications
◦ Auditability of system
 Systems Selection
◦ Economic feasibility

5
 INHOUSE DEVELOPMENT
 COMMERCIAL SYSTEMS
 TRENDS IN COMMERCIAL SYSTEM
◦ Low Cost
◦ Emergence of Software Industry
◦ Growing Demand of Businesses
◦ Downsizing/ DDP IT Environment
 General
Turnkey Special Purpose
Accounting
Systems Systems
Systems

Office Vendor
Backbone
Automation Supported
Systems
Systems Systems

Advantages of Commercial Disadvantages of

Software Commercial Software

•Independence
•Implementation Time •The need for customized
•Cost systems (becomes dependent
•Reliability on vendor)
•Maintenance
Programming
& Testing
Test Results

MAINTENANCE
 Objective of Systems Planning is to link individual projects
or applications to the strategic objectives of the firm.
 STEERING COMMITTEE & RESPONSIBILITIES (6)

 STRATEGIC SYSTEMS PLANNING – allocation, processing,

budgeting, informed decisions by systems specialists
1. A plan that changes constantly is better than no plan at
all.
2. Strategic planning reduces the crisis component in
systems development.
3. Strategic systems planning provides authorization
control for the SDLC.
4. Cost Management
 Project Planning
 Project Proposal
 Project Schedule

 AUDITOR’S ROLE: Adequate Systems Planning

Takes Place
 1) The Survey Step & 2) Analysis of
User’s Need
 Serves as the foundation for the rest of SDLC
 The Survey Step
◦ Disadvantages
 Current Physical Tar Pit (sucked in & bogged down);
Thinking Inside the Box (improved current system
rather radically new approach)
◦ Advantages of Surveying Current System
 What old aspect should be kept, force analysis,
Isolating the root problem
GATHERING FACTS & FACTS GATHERING TECHNIQUES
Data Sources Data Stores Data Processes

Transaction
Data Flows Controls
Volumes

Bottlenecks
Error Rates Resource Costs and redundant
operations
 Observation Task Participation

Personal Interviews
• OPEN ENDED (allows to Reviewing Key
elaborate)
Documents
• QUESTIONNAIRES (more
specific, more detailed)
 Systems Analysis Report (pg 195)

 An accountant is a stakeholder, therefore it

should be involved in the analysis of needs of
the proposed system for advanced features.
 Authorizing development of new systems
 Addressing and documenting user needs
 Technical design phases
 Participation of internal auditors
 Testing program modules before implementing
◦ Testing individual modules by a team of users,
internal audit staff, and systems professionals
 Structured Design Approach (uses
Several alternatives that satisfy Identify/ compare all the
DFD) – Top Down; Starts with the
the system requirements during distinguishing features, input,
BIGGER PICTURE and then
system analysis (TWO process, output from one design
decomposed; uses data flow
APPROACHES) to another (figure 5.50)
diagrams

Object Oriented Approach (uses

Standard Components) ITERATIVE
APPROACH – reduced time for
cost dev’t, maintenance, testing
and improved user support &
flexibility
Auditor’s Role as a Stakeholder,
at least has an interest in the
conceptual design, because of the
impact on audit
Perform Detailed Feasibility Study
•Technical Feasibility – develop in existing technology
•Economic Feasibility – availability of funds
•Legal Feasibility – conflicts between conceptual concept & discharge liabilities
•Operational Feasibility - compatibility
•Schedule Feasibility- ability to implement w/in acceptable time

Perform Cost Benefit Analysis

•1. Identify Costs (One Time Costs vs Recurring Costs)
•2. Identify Benefits
•Tangible Benefits
•Intangible Benefits
•3. Compare Costs and Benefits
•NPV
•Payback Period
•Break Even Point
1) Escapable Costs
2) Interest Rates
3) One time & recurring Costs
4) Realistic Useful Lives
5) Intangible Values
 Detailed description of the proposed system
satisfies system requirements during Phase 2 &
Phase 3.

 Perform System Design Walkthrough – Quality

assurance group

 Review System Documentation

◦ Inputs & source documents
◦ Outputs, reports & operational documents
◦ Normalized data for database tables
◦ Update data dictionary
◦ Processing logic or Flow Charts
 1) PROGRAM THE APPLICATION SYSTEM 2) TEST
THE APPLICATION SYSTEM
 Procedural Languages(Cobol, Fortran, C, PL1)
 Event Driven Languages- uses icons Microsoft
VB; GUI
 Object Oriented Languages

 Programming the System-follow modular

approach regardless of the language used
1. Programming Efficiency
2. Maintenance Efficiency
3. Control
 2) Test the Application Software
 Testing Methodology
◦ Identifying programming & logical errors
 Testing Offline Before Deploying Online
◦ Never Ever Underestimate (Testing Environment vs
Actual Environment)
 Test Data
◦ Should be retained for reuse
◦ Serves as a frame of reference for auditor in
designing and evaluating future audit tests (i.e. the
system has not undergone any change)
 Complete engagement of programmers, users, designers, database
administrators, users and accountants
 Activities in this entail extensive costs
1. TESTING THE ENTIRE SYSTEM
◦ DOCUMENTING THE SYSTEM
 Designer & Programmer Documentation
 Operator Documentation
 User Documentation
 Novices
 Occasional Users
 Frequent Light Users
 Frequent Power Users
◦ USER HANDBOOK
◦ TUTORIALS
◦ HELP FEATURES
2. CONVERTING THE DATABASES
3. CONVERTING TO THE NEW SYSTEM
Cold Turkey Cutover – most risky; all at once
Phased Cutover- by modules; gradual
Parallel Operation Cutover – simultaneous; reconciliation
 THE AUDITOR’S ROLE IN SYSTEM
IMPLEMENTATION
1. Provide Technical Expertise
2. Specify Documentation Standards
3. Verify Control Adequacy & Compliance w/
SOX
POST IMPLEMENTATION REVIEW
4. Systems Design Adequacy
5. Accuracy of Time, Cost and Benefit Estimates
 Accommodate Changes in Users’
Needs
 It could be extensive
 Maintenance represents
significant outlay compared to
initial development costs.
 Last, longest and most costly phase of SDLC
◦ Up to 80-90% of entire cost of a system
 Audit Procedures:
◦ All maintenance actions should require
 Technical specifications
 Testing
 Documentation updates
 Formal authorizations for changes
 Systems Authorization
Activities
 User Specifications Activities
 Technical Design Activities
 Internal Audit Participation
 User Test and Acceptance
Procedure
 Auditing objectives: ensure that...
◦ SDLC activities applied consistently and in
accordance with management’s policies
◦ system as originally implemented was free from
material errors and fraud
◦ system was judged to be necessary and justified at
various checkpoints throughout the SDLC
◦ system documentation is sufficiently accurate and
complete to facilitate audit and maintenance
activities
 Audit Procedures:
◦ New systems must be authorized.
◦ Feasibility studies conducted.
◦ User needs analyzed and addressed.
◦ Cost-benefit analysis completed.
◦ Proper documentation completed.
◦ All program modules thoroughly tested before implementation.
◦ Checklist of problems was kept.
◦ Systems documentation complies with organizational
requirements
 Maintenance Authorization, Testing & Documentation
 Source Program Library Controls – where application
program source code are stored
 SPL – No Controls
 Controlled SPLMS Environment
 1) Storing programs on the SPL
 2) Retrieving programs for maintenance purposes
 3) Deleting obsolete programs from lib
 4) Documenting program changes to provide audit
trail of the changes
◦ Password Control
◦ Separate Test Libraries
◦ Audit Trail & Management Reports
◦ Program Version Numbers
◦ Controlling Access to Maintenance Commands
 Auditor compares the current program
version number in the documentation file vs
current version number of the production
program

 Auditor reconciles program maintenance

requests, program listings and program
changes to verify the need for and accuracy
of program
 Figure 5.14
Auditing objectives: detect any unauthorized program
maintenance and determine that...
◦ maintenance procedures protect applications
from unauthorized changes
 Reconcile program version numbers
 Confirm maintenance authorization
◦ applications are free from material errors
 Reconcile the source code
 Review test results
 Retest the program
◦ program libraries (where programs are stored)
are protected from unauthorized access
 Review programmer authority table
 Test authority table
32