Chapter 4:
Systems Development &
Maintenance Activities
PARTICIPANTS




Systems professionals
End users
Stakeholders
ACCOUNTANTS



Internal
External
Limitations of involvement
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)
IS Development




In-house development
Purchase commercial systems
General Rule: Never build if you can
acquire a system that will provide
80% of your needs.
Qstn: When would you want to build
your own system?
TRENDS IN COMMERCIAL
SOFTWARE

Trends in commercial software




Relatively low cost for general
purpose software
Industry-specific vendors
Businesses too small to have inhouse IS staff
Downsizing & DDP
TYPES OF COMMERCIAL
SYSTEMS

Turnkey systems

General accounting systems


Special-purpose systems


Example banking
Office automation systems


Typically in modules
Purpose is to improve productivity
Enterprise systems (ERP)

SAP, Peoplesoft, Baan, Oracle
COMMERCIAL SYSTEMS

Advantages




Implementation time
Cost
Reliability
Disadvantages



Independence
Customization needs
Maintenance
SYSTEMS DEVELOPMENT LIFE
CYCLE (SDLC)

New systems
1.
2.
3.
4.
5.
6.
7.
8.

Systems planning
Systems analysis
Conceptual systems design
System evaluation and selection
Detailed design
System programming and testing
System implementation
System maintenance
SDLC -- Figure 4-1 [p.141]
SYSTEMS PLANNING– PHASE I
PURPOSE:
To link individual systems projects to
the strategic objectives of the firm.

Link individual projects to strategic objectives of the firm Figure 4-2 [p.142]

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
SYSTEMS PLANNING-PHASE I
Level 1 = Strategic systems planning


Why?
1.
2.
3.
4.
A changing plan is better than no plan
Reduces crises in systems development
Provides authorization control for SDLC
It works!
Level 2 = Project planning



Project proposal
Project schedule
SYSTEMS PLANNING-PHASE I
 Auditor’s
role in systems
planning



Auditability
Security
Controls
SYSTEMS PLANNING-PHASE I
SUMMARY
 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 mgmt’s commitment
SYSTEMS ANALYSISPHASE 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
SYSTEMS ANALYSISPHASE II
Gathering facts






Data sources
Users
Data stores
Processes
Data flows
Controls





Transaction volumes
Error rates
Resource costs
Bottlenecks
Redundant operations
SYSTEMS ANALYSISPHASE II

Fact-gathering techniques





Systems analysis report


Observation
Task participation
Personal interviews
Reviewing key documents
(see list, p. 147)
Figure 4-3 (p.148)
Auditor’s role

CAATTs (e.g., embedded modules)
CONCEPTUAL SYSTEMS DESIGNPHASE III
PURPOSE: Develop alternative systems that satisfy
system requirements identified during system
analysis
1. Top-down (structured design)
[see Figure 4-4, p.150]



Designs general rather than specific
Enough details for design to demonstrate differences
Example: Figure 4-5, p. 151
Object-oriented approach (OOD)
2.


Reusable objects
Creation of modules (library, inventory of objects)
3. Auditor’s role

special auditability features
SYSTEM EVALUATION & SELECTION–
PHASE IV
PURPOSE: Process that seeks to identify the optimal solution
from the alternatives
Perform detailed feasibility study
1.




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]
Perform a cost-benefit analysis
2.



Identify costs
Identify benefits
Compare the two
SYSTEM EVALUATION & SELECTION-PHASE IV
Cost-Benefit Analysis: Costs
•
•
•
•
•
•
•
•
ONE-TIME COSTS:
Hardware acquisition
Site preparation
Software acquisition
Systems design
Programming
Testing
Data conversion
Training
RECURRING COSTS:
• Hardware maintenance
• Software maintenance
• Insurance
• Supplies
• Personnel
• Allocated existing IS
SYSTEM EVALUATON & SELECTION–PHASE IV
Cost-Benefit Analysis: Benefits
•
•
TANGIBLE:
Increased revenues
•
Increased sales in existing
markets
•
Expansion into new
markets
Cost Reduction 1
•
Labor reduction
•
Operating cost reduction
•
Supplies
•
overhead
•
Reduced inventories
•
Less expensive eqpt.
•
Reduced eqpt. maint.
•
•
•
•
•
•
•
•
INTANGIBLE 2:
Increased customer
satisfaction
Improved employee
satisfaction
More current information
Improved decision making
Faster response to
competitors’ actions
More effective operations
Better internal and external
communications
Improved control
environment
Cost-Benefit Analysis: Comparison
NPV 1 [Table 4-4]
Payback 2 [Figures 4-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”
DETAILED DESIGN– PHASE V
Quality Assurance

“Walkthrough”

Quality assurance
DETAILED DESIGN – PHASE V
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 4-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
SYSTEMS IMPLEMENTATION–
PHASE VII
Conversion
Converting the databases




Validation
Reconciliation
Backup
Converting the new system

Auditor involvement virtually stops!



Cold turkey cutover
Phased cutover
Parallel operation cutover
SYSTEMS IMPLEMENTATION–
PHASE VII
Post-Implementation Review
Reviewed by independent team to measure
the success of the system



Systems design adequacy [see list p. 170]
Accuracy of time, cost, and benefit estimates
[see list p. 170]
Auditor’s role






We’re back!!
Provide technical expertise
Specify documentation standards
Verify control adequacy
External auditors
SYSTEMS IMPLEMENTATION–
PHASE VII
Auditors’ Role

Provide technical expertise
AIS: GAAP, GAAS, SEC, IRS
Legal
Social / behavioral
IS/IT (if capable)







Specify documentation standards
Verify control adequacy


Effective and efficient ways to limit application
testing
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
Importance of documentation?




Facilitate efficient changes
Facilitate effective changes (at all!)
Preliminary
Feasibility
Project
Authorization
Project
Proposal
Systems
Planning
Systems
Analysis
System
Analysis Rpt
Conceptual
Design
DFD
(general)
Systems
Selection
Detailed
Design
System
Implementation
Feasibility
Study
Detailed
Design Rpt
Post-Impl.
Review
DFD
(Detail)
ER
Diagram
Program
Flowcharts
Project
Schedule
System
Cost-Benefit
Selection Rpt
Analysis
Relational
Model
Documentation
Normalized
Data
User
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 & 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
CONTROLLING & AUDITING THE SDLC
Audit Objectives & 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 174 for a list
CONTROLLING & AUDITING THE SDLC
Controlling Systems Maintenance
Four minimum controls:





Formal authorization
Technical specifications
Retesting
Updating the documentation
CONTROLLING & AUDITING THE SDLC
Controlling Systems Maintenance
Source program library controls





Why? What trying to prevent?
Unauthorized access
Unauthorized program changes
SPLMS [Figure 4-13, p. 177]
SPLMS Controls





Storing programs on the SPL
Retrieving programs for maintenance purposes
Detecting obsolete programs
Documenting program changes (audit trail)
CONTROLLING & AUDITING THE SDLC
Controlled SPL Environment
Password control


Separate test libraries
Audit trail and management reports





On a specific program
Describing software changes
Program version numbers
Controlling access to maintenance [SPL]
commands
CONTROLLING & AUDITING THE SDLC
Audit Objectives & Procedures
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
CONTROLLING & AUDITING THE SDLC
Audit Objectives & Procedures
Audit procedures

Figure 4-14, p.179
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
End Chapter 4:
Systems Development &
Maintenance Activities