Ch5 - System Development and Program Change Procedures

Chapter 5:
Systems Development and

Program Change Procedures
IT Auditing, Hall, 3e
© 2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or
duplicated, or posted to a publicly accessible website, in whole or in part.
Participants in Systems Development
 Systems professionals
 End users
 Stakeholders
 Accountants/ Auditors
 Internal
 External
 Limitations of involvement
duplicated, or posted to a publicly accessible website, in whole or in part. Hall, 3e 2
Accountants/ Auditors
 Why are accountants/auditors involved?
 Experts in financial transaction processes
 Quality of AIS is determined in SDLC
 How are accountants involved?
 Users (e.g., user views and accounting techniques)
 Members of SDLC development team
(e.g., Control Risk being minimized)
 Auditors (e.g., auditable systems)
Information Systems Acquisition
 Two methods of acquiring information

systems:
 In-house development
 Purchase commercial systems
Trends in Commercial Software
 Relatively low cost for general

purpose software
 Industry-specific vendors
 Businesses too small to have
in-house IS staff
 Downsizing & DDP
Types of Commercial Systems
 Turnkey systems
 General accounting systems

 Typically in modules
 Special-purpose systems
 Example banking
 Office automation systems
 Purpose is to improve productivity
 Backbone systems (ERP)

 SAP, Peoplesoft, Baan, Movex
 Vendor-supported systems
 Hybrids
Commercial Systems
 Advantages
 Implementation time
 Cost
 Reliability
 Disadvantages
 Independence
 Customization needs
 Maintenance
Systems Development Life Cycle (SDLC)
 New systems
1. Systems planning
2. Systems analysis
3. Conceptual systems design
4. System evaluation and selection
5. Detailed design
6. System programming and testing
7. System implementation
8. System maintenance
 SDLC – Figure 5-1
Preliminary Project
Feasibility Authorization
Systems Project Project
Planning Proposal Schedule
Systems System
Analysis Analysis Rpt
Conceptual DFD
Design (general)
Systems Feasibility Cost-Benefit System

Selection Study Analysis Selection Rpt
Detailed Detailed DFD ER Relational Normalized

Design Design Rpt (Detail) Diagram Model Data
System Post-Impl. Program User

Documentation
Implementation
© 2011 Cengage Learning. All Rights Reserved.Review
May not be scanned,Flowcharts
copied or Acceptance Rpt
Systems Planning –Phase I
Purpose: To link individual systems projects
to the strategic objectives of the firm.
 Who does it?
 Steering committee
 CEO, CFO, CIO, senior mgmt., auditors, external
parties
 Ethics and auditing standards limit when auditors can
serve on this committee
 Long-range planning: 3-5 years
 Allocation of resources - broad
 Level 1: Strategic Systems Planning
 Justifications:
1. A changing plan is better than no plan
2. Reduces crises in systems development
3. Provides authorization control for SDLC
4. Cost management
 Level 2: Project Planning
 Project proposal
 Project schedule
 Auditor’s role in systems planning
 Auditability
 Security
 Controls
Summary of Phase I
Identify user’s needs
Preparing proposals
Evaluating proposals
Prioritizing individual projects
Scheduling work
 Project Plan – allocates resources to specific
project
 Project Proposal – Go or not
 Project Schedule – represents management’s
commitment
Systems Analysis –Phase II
PURPOSE: Effectively identify and analyze the
needs of the users for the new system.
 Survey step
 Disadvantages:
 Tar pit syndrome
 Thinking inside the box
 Advantages:
 Identify aspects to keep
 Forcing analysts to understand the system
 Isolating the root of problem symptoms
Gathering Facts
 Data sources  Transaction

 Users volumes
 Data stores  Error rates
 Processes  Resource costs
 Data flows  Bottlenecks
 Controls  Redundant
operations
Fact-gathering techniques
 Observation
 Task participation
 Personal interviews
 Reviewing key documents
Systems analysis report

 Figure 5-3
Auditor’s role
 CAATTs (e.g., embedded modules)
Conceptual Systems Design –Phase III
PURPOSE: Develop alternative systems that
satisfy system requirements identified
during system analysis
1. Top-down (structured design)
[see Figure 5-4]
 Designs general rather than specific
 Enough details for design to demonstrate differences
 Example: Figure 5-5
2. Object-oriented approach (OOD)
 Reusable objects
 Creation of modules (library, inventory of objects)
3. Auditor’s role
 special auditability features
System Evaluation and Selection –Phase IV
PURPOSE: Process that seeks to identify the optimal
solution from the alternatives
1. Perform detailed feasibility study
 Technical feasibility [existing IT or new IT?]
 Legal feasibility
 Operational feasibility
Degree of compatibility between the firm’s
existing procedures and personnel skills, and
requirements of the new system
 Schedule feasibility [implementation]
2. Perform a cost-benefit analysis
 Identify costs
 Identify benefits
 Compare the two
Cost-Benefit Analysis: Costs

ONE-TIME COSTS: RECURRING COSTS:
 Hardware acquisition  Hardware maintenance
 Site preparation  Software maintenance
 Software acquisition  Insurance
 Systems design  Supplies
 Programming  Personnel
 Testing  Allocated existing IS
 Data conversion
 Training
Cost-Benefit Analysis: Costs
TANGIBLE: INTANGIBLE 2:
 Increased revenues  Increased customer satisfaction
 Increased sales in  Improved employee satisfaction
existing markets  More current information
 Expansion into new  Improved decision making
 Faster response to competitors’
markets
actions
 Cost Reduction 1
 More effective operations
 Labor reduction  Better internal and external
 Operating cost communications
reduction  Improved control environment
 Supplies
 overhead
 Reduced inventories
 Less expensive eqpt.
 Reduced eqpt. maint.
Cost-Benefit Analysis:
Comparison
 NPV 1 [Table 5-4]
 Payback 2
[Figures 5-7a, 7b]
 BE
 Auditor’s role
 Managerial accounting techniques 3
 Escapable costs
 Reasonable interest rates
 Identify one-time and recurring costs
 Realistic useful lives for competing projects
 Determining financial values for intangible
benefits
Detailed Design –Phase V
PURPOSE: Produce a detailed description of
the proposed system that satisfies system
requirements identified during systems
analysis and is in accordance with
conceptual design.
 User views
 Database tables
 Processes
 Controls
 i.e., a set of “blueprints”
Quality Assurance
 “Walkthrough”
 Quality assurance
Detailed Design Report
 Designs for input screens and source
documents
 Designs for screen outputs, reports,
operational documents
 Normalized database
 Database structures and diagrams
 Data flow diagrams (DFD’s)
 Database models (ER, Relational)
 Data dictionary
 Processing logic (flow charts)
SYSTEM PROGRAMMING & TESTING– PHASE VI
Program the Application

 Procedural languages
 Event-driven languages
 OO languages
 Programming the system
 Test the application [Figure 5-8]
 Testing methodology
 Testing offline before deploying online
 Test data
 Why?
 Can provide valuable future benefits
Systems Implementation –Phase VII
PURPOSE: Database structures are created and populated
with data, applications are coded and tested,
equipment is purchased and installed, employees are
trained, the system is documented, and the new system
is installed.
 Testing the entire system

 Documenting the system
 Designer and programmer documentation
 Operator documentation
 User documentation
 Novices, occasional users, frequent light users,
frequent power users, user handbook, tutorials, help
features
Conversion
 Converting the databases
 Validation
 Reconciliation
 Backup
 Converting the new system
Go live …
 Auditor involvement virtually stops!
 Cold turkey cutover
 Phased cutover
 Parallel operation cutover
Post-Implementation Review
 Reviewed by independent team to measure
the success of the system
 Systems design adequacy
 Accuracy of time, cost, and benefit estimates
 Auditor’s role
 Provide technical expertise

 Specify documentation standards
 Verify control adequacy
 External auditors
Auditors’ Role
 Provide technical expertise
 AIS: GAAP, GAAS, SEC, IRS
 Legal
 Social / behavioral
 IS/IT (if capable)
 Effective and efficient ways to limit application
testing
 Specify documentation standards
 Verify control adequacy
 COSO – SAS No. 78 – PCAOB Standard #1
 Impact on scope of external auditors
Systems Maintenance –Phase VIII
PURPOSE: Changing systems to accommodate
changes in user needs
 80/20 rule 1
 Importance of documentation?
 Facilitate efficient changes
 Facilitate effective changes (at all!)
Preliminary Project
Feasibility Authorization
Systems Project Project
Planning Proposal Schedule
Systems System
Analysis Analysis Rpt
Conceptual DFD
Design (general)
Systems Feasibility Cost-Benefit System

Selection Study Analysis Selection Rpt
Detailed Detailed DFD ER Relational Normalized

Design Design Rpt (Detail) Diagram Model Data
System Post-Impl. Program User

Documentation
Implementation
© 2011 Cengage Learning. All Rights Reserved.Review
May not be scanned,Flowcharts
copied or Acceptance Rpt
A materially flawed financial
application will eventually
corrupt financial data, which will
then be incorrectly reported in
the financial statements.
Therefore, the accuracy and
integrity of the IS directly affects
the accuracy of the client’s
financial data.
Controlling and Auditing the SDLC
Controlling New Systems
Development
 Systems authorization activities
 User specification activities
 Technical design activities
 Documentation is evidence of controls
 Documentation is a control!
 Internal audit participation
 User test and acceptance procedures
 Audit objectives
 Audit procedures
Audit Objectives and Procedures
 Audit objectives
 Verify SDLC activities are applied consistently and in
accordance with management’s policies
 Verify original system is free from material errors and
fraud
 Verify system necessary and justified
 Verify documentation adequate and complete
 Audit procedures
 How verify SDLC activities applied consistently?
 How verify system is free from material errors and fraud?
 How verify system is necessary?
 How verify system is justified?
 How verify documentation is adequate and complete?
 See page 208 for a list
Controlling Systems Maintenance
 Four minimum controls:

 Formal authorization
 Technical specifications
 Retesting
 Updating the documentation
Controlling Systems Maintenance
 Source program library controls

 Why? What trying to prevent?
 Unauthorized access
 Unauthorized program changes
 SPLMS [Figure 5-13]
 SPLMS Controls
 Storing programs on the SPL
 Retrieving programs for maintenance purposes
 Detecting obsolete programs
 Documenting program changes (audit trail)
Controlled SPL Environment
 Password control
 On a specific program
 Separate test libraries
 Audit trail and management reports
 Describing software changes
 Program version numbers
 Controlling access to maintenance [SPL]
commands
 Audit objectives
 Detect any unauthorized program
changes
 Verify that maintenance procedures
protect applications from
unauthorized changes
 Verify applications are free from
material errors
 Verify SPL are protected from
unauthorized access
 Audit procedures
 Figure 5-14
 Identify unauthorized changes
 Reconcile program version numbers
 Confirm maintenance authorization
 Identify application errors
 Reconcile source code [after taking a sample]
 Review test results
 Retest the program
 Testing access to libraries
 Review programmer authority tables
 Test authority table

Ch5 - System Development and Program Change Procedures

Uploaded by

Copyright:

Available Formats

You might also like

Ch5 - System Development and Program Change Procedures

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ch5 - System Development and Program Change Procedures

Uploaded by

Copyright:

Available Formats

Chapter 5:

Systems Development and

 Two methods of acquiring information

 Relatively low cost for general

 General accounting systems

 Backbone systems (ERP)

Systems Feasibility Cost-Benefit System

Detailed Detailed DFD ER Relational Normalized

System Post-Impl. Program User

 Data sources  Transaction

Systems analysis report

Cost-Benefit Analysis: Costs

Program the Application

 Testing the entire system

 Provide technical expertise

Systems Feasibility Cost-Benefit System

Detailed Detailed DFD ER Relational Normalized

System Post-Impl. Program User

 Four minimum controls:

 Source program library controls

You might also like