1. System Development, Acquisition & Maintenance Controls

2. Why Is Formal SDLC Necessary? Management –Avoid costly disasters –Competitive Advantage Auditors –Important element of internal control –Audit assurance on applications

3. 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

4. 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

5. 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

6. 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

7. Systems Development Life Cycle Investigation Requirements Analysis & Initial Design Acquisition/ Development Maintenance Implementation

8. 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

9. Capability Maturity Model Initial (1) + Disciplined process  Repeatable (2) +Standard consistent process  Defined (3) + Predictable process  Managed (4) + Continuously improving process  Optimizing (5)

10. 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

11. 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

12. 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

13. 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

14. Initial Design = Functional Specifications –Output –Input –System processing Stages of Development - Requirements Analysis & Initial Design Phase

15. Stages of Development - Acquisition/Development Strategic Decisions –Make vs Buy –Outsourcing vs In-House

16. 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

17. 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

18. 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

19. Stages of Development - Acquisition - Additional Steps Screen what is available RFP Evaluate potential suppliers Test/evalaute Negotiate agreement Install

20. Stages of Development - Implementation Scheduling conversions Site preparation Personnel recruitment and training File creation or conversion Implementation Post-implementation review

21. Stages of Development - Implementation Conversion: –Conversion Plan (steps, responsibilities, timing) –Verification of: Completeness Accuracy Authorization Cut-off

22. 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

23. 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

24. 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

25. Role of Auditor Assess Internal Control Help everyone understand importance Look at compliance with procedures Assess effectiveness Database administration controls Assess security

26. Role of Auditor Adequacy of Mgmt and Audit Trails Make sure information is accessible Make sure adequate trail exists

27. 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

28. 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

29. 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

30. 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