System Development,
Acquisition &
Maintenance
Controls
Why Is Formal SDLC Necessary?
Management
– Avoid costly disasters
– Competitive Advantage
Auditors
– Important element of internal control
– Audit assurance on applications
Why Is Formal SDLC Necessary?
• Allstate - rather than 5yrs - $8 million ended at $100 million
• Oklahoma - $500,000 workmen's comp ended at $4 million
• Blue Cross & Shield - $200 million system
didn't work - $60 million in overpayments lost 35,000 members
Why Is Formal SDLC Necessary?
• Gartner Group survey (J of A, Feb 2001) found:
• 40% of IT projects don’t produce intended results
• Typical project scheduled for 27 weeks
• Cancelled project lasted 14 weeks, costing $1 million on
unsatisfactory results
• Project team members knew they were working on
projects that would fail 6 weeks before cancellation -Mum effect; Deaf effect
Why Is Formal SDLC Necessary?
• Standish Group survey (CACM, April 2001) found:
• 26 % of IT projects delivered on time, on budget and with
promised functionality
• 46% completed over budget and behind schedule, and
with fewer features
• 28% not completed
Common Causes of System Failure
•
•
•
•
•
•
•
•
Lack of user involvement
Inadequate planning and budgeting
Mismanagement of available workers
Poor or incomplete design
Insufficient testing
Undocumented or unenforced development standards
Lack of security over data and programs
No change or project management function
Systems Development Life Cycle
Investigation
Maintenance
Implementation
Requirements Analysis
& Initial Design
Acquisition/
Development
Capability Maturity Model
• Applicable to organizations in software business
• The capability maturity model identifies 5 levels
of software process maturity
• Maturity level is a well-defined evolutionary
plateau toward achieving a mature software
process
Capability Maturity Model
Initial (1)
+ Disciplined process
 Repeatable (2)
+Standard consistent process  Defined (3)
+ Predictable process
 Managed (4)
+ Continuously improving process  Optimizing (5)
Project Management
• Initiation - prelim survey, feasibility study,
prioritization, resource allocation
• Planning - objectives, deliverables, methods,
activities, staff, budget
• Execution - implement plan, manage personnel,
quality control, communication
• Control - monitor activities, controls, quality; report
• Termination - transition
Stages of Development Investigation Phase
• Determine problem and whether a new/modified
system is needed
• Decision needs to be in accordance with policies,
need to determine costs, savings and benefits
• Problem ID and Initiation - have users involved to
reduce semantic gap - different perceptions from
reality, need to manage resultant change
Stages of Development Investigation Phase
• Preliminary survey - assess problem, needs,
alternatives, system costs system benefits
• Feasibility study - documentation of system
review, hardware/software, transaction streams.
Assessment of existing procedures
Stages of Development Requirements Analysis &
Initial Design Phase
• Requirements analysis = Meet User Needs
–
–
–
–
Observe users/functions, documentation
Assess why each step performed
What info used by each user
What else needed
Stages of Development Requirements Analysis &
Initial Design Phase
• Initial Design = Functional Specifications
– Output
– Input
– System processing
Stages of Development Acquisition/Development
• Strategic Decisions
– Make vs Buy
– Outsourcing vs In-House
Stages of Development Acquisition/Development
• Detailed design specifications
–
–
–
–
–
–
–
–
outputs, media and methods,
file content, access methods, retention, back-up
processing steps, modes, functions
data preparation/entry
hardware/software
testing plan
implementation plan
documentation
– control requirements
• completeness, accuracy, authorization, timeliness, audit trail
Stages of Development Acquisition/Development
• Systems/programming standards - approvals and
testing, control over conversion, stages of system
development, required approvals at each stage,
conventions to be used, testing and system
documentation
• Documentation - for clear understanding and
safeguard when turnover occurs
Stages of Development Acquisition/Development
• System testing - not discrete but throughout the process
–
–
–
–
Code inspection
String testing
Performance/load testing
Pilot testing - large volume of test or live data and carefully
check results
– Parallel testing - data processed under new and old systems
– Acceptance testing - hands on by users, system works right,
recoveries of data timely, no lost messages, response times met
Stages of Development Acquisition - Additional Steps
•
•
•
•
•
•
Screen what is available
RFP
Evaluate potential suppliers
Test/evalaute
Negotiate agreement
Install
Stages of Development Implementation
•
•
•
•
•
•
Scheduling conversions
Site preparation
Personnel recruitment and training
File creation or conversion
Implementation
Post-implementation review
Stages of Development Implementation
• Conversion:
– Conversion Plan (steps, responsibilities, timing)
– Verification of:
•
•
•
•
Completeness
Accuracy
Authorization
Cut-off
Stages of Development Maintenance
• More than 50% of a system’s life time cost is
incurred in the “Maintenance” phase
• Need control over subsequent changes
• Emergency changes - segregation of duties to
prevent fraud
Auditor Participation in
Phases of System
Acquisition/Development
• Investigation phase - review economic feasibility
analysis, ensure responsibility for control and
audibility established
• Design phase - correction and reprocessing of
rejected transactions, changes to master file info,
accuracy of programmed accounting procedures
Auditor Participation in
Phases of System
Acquisition/Development
• Development - review progress reports - cradle to
grave test
• Implementation - review pre-implementation
plans monitor conversion procedures
• Maintenance - instill control consciousness adequacy of program change controls
Role of Auditor
Assess Internal Control
•
•
•
•
•
Help everyone understand importance
Look at compliance with procedures
Assess effectiveness
Database administration controls
Assess security
Role of Auditor
Adequacy of Mgmt and Audit Trails
• Make sure information is accessible
• Make sure adequate trail exists
Role of Auditor
• Accounting Principles - new principles could be
adopted - for example a new inventory method
• Link between Mgmt and IS - auditors can be
liaison
• System conversions - concern with data accuracy proper-cutoff
Role of Auditor
Monitoring Compliance with Sys Dev Stds
• Adherence to standards results in controlled
auditable systems
• Assess appropriateness of control practices
• Verify adherence to policies
• Review design, development and implementation
of application controls
Role of Auditor
Post-Implementation Reviews
• Compare system performance to objectives
• Assess reliability and accuracy
• Verify compliance with application controls
• Assess applicability and usefulness of information
Issue of Auditor Independence
• Balancing act - give advice but client makes
decision
• Use 2 different audit teams
• In written report clearly state scope of review
• Standardize the scope and approach of review