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)

I.S. AQUISITION
In-house development
Purchase commercial
systems

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
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.
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 PLANNINGPHASE I
Level 1 = Strategic systems planning
Why?
1. A changing plan is better than no plan
2. Reduces crises in systems development
3. Provides authorization control for SDLC
4. It works!

Level 2 = Project planning

Project proposal
Project schedule

SYSTEMS PLANNINGPHASE I
Auditors role in systems
planning
Auditability
Security
Controls

SYSTEMS PLANNINGPHASE I
SUMMARY
Identify users 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 mgmts
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

Observation
Task participation
Personal interviews
Reviewing key documents
(see list, p. 147)

Systems analysis report

Figure 4-3 (p.148)

Auditors 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

2. Object-oriented approach (OOD)

Reusable objects
Creation of modules (library, inventory of objects)

3. Auditors role

special auditability features

SYSTEM EVALUATION & 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 firms 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

SYSTEM EVALUATION & SELECTIONPHASE 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

Auditors role
Managerial accounting techniques

Escapable costs
Reasonable interest rates
Identify one-time and recurring costs
Realistic useful lives for competing projects
Determining financial values for intangible
benefits

DETAILED DESIGNPHASE 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 (DFDs)
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
Novices
Occasional users
Frequent light users
Frequent power users
User handbook
Tutorials
Help features

SYSTEMS IMPLEMENTATION
PHASE VII
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

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]

Auditors role

Were back!!
Provide technical expertise
Specify documentation standards
Verify control adequacy
External auditors

SYSTEMS IMPLEMENTATION
PHASE VII
Auditors Role

Were back!!
Provide technical expertise

Specify documentation standards

Verify control adequacy

AIS: GAAP, GAAS, SEC, IRS

Legal
Social / behavioral
IS/IT (if capable)
Effective and efficient ways to limit application
testing

COSO SAS No. 78 PCAOB Standard #1

Impact on scope of external auditors

SYSTEMS MAINTENANCEPHASE 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
Feasibility

Project
Authorization

Systems
Planning

Project
Proposal

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
clients 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 managements 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
On a specific program

Separate test libraries

Audit trail and management reports
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

Chapter 4:
Systems Development &
Maintenance Activities