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 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 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. 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 PLANNING-
PHASE I
Auditors role in systems
planning
Auditability
Security
Controls
 SYSTEMS PLANNING-
PHASE 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 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
 SYSTEMS ANALYSIS-
PHASE II
Gathering facts
Data sources Transaction volumes
Users Error rates
Data stores Resource costs
Processes Bottlenecks
Data flows Redundant
Controls operations
 SYSTEMS ANALYSIS-
PHASE 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 DESIGN-
PHASE 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 & SELECTION-
PHASE IV
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
 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 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 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
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 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 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

Documentation
User
Implementation Review Flowcharts 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