Chapter 4: Systems Development & Maintenance Activities

1. Chapter 4:Systems Development & Maintenance Activities

2. PARTICIPANTS • Systems professionals • End users • Stakeholders • ACCOUNTANTS & AUDITORS • Internal • IT

3. 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, auditing with specific technique)

4. IS Development • In-house development staffs • 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?

5. 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 (cloud computing)

6. TYPES OF COMMERCIAL SYSTEMS • Turnkey systems (alpha and beta testing) • General accounting systems • Typically in modules • Special-purpose systems • Example banking • Office automation systems • Purpose is to improve productivity • Enterprise systems (ERP) • SAP, Peoplesoft, Baan, Oracle • Vendor-supported systems • Hybrids (custom system, commercial software)

7. Office automation systems

8. Vendor-supported systems • Healthcare

9. COMMERCIAL SYSTEMS • Advantages • Implementation time • Cost • Reliability • Disadvantages • Independence • Customization needs • Maintenance

10. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) • Some company may satisfy its information needs by purchasing commercial software and develop other system in-house. • Both are necessary and enhanced by formal procedures that lend structure to the decision making process • SDLC “best practices” for system development.

11. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) • New systems • 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]

12. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)

13. 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 (=strategic budget & other resources allocation: system resources hr, hw,sw, telco)

14. To link individual systems projects to the strategic objectives of the firm

15. SYSTEMS PLANNING-PHASE I • Level 1 = Strategic systems planning • Why? • 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

16. Project Proposal Report What you have found Recommendations Financially feasible • Problem Definition • Nature of the problem: • Separate problem from symptoms of problem • Scope of the project: • Establish boundaries.. • Budget and schedule • Objectives of the project: • What user thinks system should do

17. Resulting Management Decision • Drop • Fix a simple problem • Authorize the analysis phase

18. SYSTEMS PLANNING-PHASE I • Auditor’s role in systems planning • Auditability • Security • Controls • Reduce the risks (unneeded, inefficient, ineffective and fraudulent system)

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

20. SYSTEMS ANALYSIS-PHASE II PURPOSE:Effectively identify and analyze the needs of the users for the new system. Data Gathering And / Survey • Written documents. Reviewing key documents (see list, p. 147, 182) • Interviews • Structured • Unstructured • Questionnaires (Iterations are needed) • Observation • Visits by appointment • Participant observation • Sampling

21. SYSTEMS ANALYSIS-PHASE II • 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

22. SYSTEMS ANALYSIS-PHASE II Gathering facts • Data sources • Users • Data stores • Processes • Data flows • Controls • Transaction volumes • Error rates • Resource costs • Bottlenecks • Redundant operations

23. SYSTEMS ANALYSIS-PHASE II • Systems analysis report • Figure 4-3 (p.148) • Auditor’s role • CAATTs (e.g., embedded modules) Advanced audit features cannot be added easily to the existing systems due to technical (3GL: Cobol does not support ALE) auditor should analyze what is best suited for the systems

25. 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 • Object-oriented approach (OOD) • Reusable objects • Creation of modules (library, inventory of objects) 3. Auditor’s role • special auditability features

28. SDLC Major system aspects • Centralized or distributed • Online or batch • PC-based? • How will input be captured? • Necessary reports

29. SDLC • Make or buy decision • Packaged software • Meet at least 75% of requirements? • Change business procedures for part or all of remainder? • Customize for part of all of remainder? • Custom software • Programmers write code • Outsourcing • System is developed by external organization

30. SDLC • Build a prototype • Limited working system of subset • Does not need true functionality • Output looks like anticipated system output • Working model that can be modified and fine-tuned • Uses high-level software tools – CASE (Computer-Aided Software Engineering) • Best for small-scale systems

31. SDLC Presentation • All alternatives • Selected plan • Prototype of the system • Obtain authorization to proceed

32. SYSTEM EVALUATION & SELECTION– PHASE IV PURPOSE:Process that seeks to identify the optimal solution from the alternatives • Perform detailed feasibility study • Technical feasibility[existing IT or new IT?] • Economic feasibility • Legal feasibility (SOX and SAS 109 : privacy and confidentiality of information) • Operational feasibilityDegree 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 • Identify costs • Identify benefits • Compare the two

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

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

35. Cost-Benefit Analysis: Comparison • NPV 1[Table 4-4] NPV of Benefits (over life of system) – NPV costs (over life of system) = NPV If NPV > 0, economically feasible When choosing between projects, choose the one with the greatest NPV • Payback 2[Figures 4-7a, 7b]

37. 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 (Output requirements & Input requirements ) • Files and databases • Systems processing • Systems controls and backup

38. DETAILED DESIGN– PHASE V • Quality Assurance • “Walkthrough” • The process of inspecting algorithms and source code by following paths through the algorithms or code as determined by input conditions and choices made along the way • Algorithms : A process or set of rules to be followed in calculations or other problem-solving operations, esp. by a computer exp: a basic algorithm for division (9:3 = 3 9:3=2 IF THEN ELSE) • Quality assurance group (programmers, system analysts, users and internal auditors)

39. 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)

40. SYSTEM PROGRAMMING & TESTING– PHASE VI • Program the Application • Procedural languages (3GLs: COBOL, C) • Event-driven languages (VB aka GUI) • OO languages (Java) • Hybrid (C++ : to bridge 3GL and OOP) • Programming the system • Test the application {Figure 4-8] • Testing methodology • Testing offline before deploying online • Test data • Why? • Can provide valuable future benefits

41. 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 (modules are tested as a whole system) • Documenting the system • Designer and programmer documentation • Operator documentation (run manual) • User documentation (user skills varied: online tutorials, help features)

43. SYSTEMS IMPLEMENTATION–PHASE VII • Conversion The transfer of data from its current form to the format or medium required by the new system • Converting the databases • Validation • Reconciliation • Backup • Converting the new systemAuditor involvement virtually stops! • Cold turkey cutover (big bang) • Phased cutover (modular) • Parallel operation cutover

45. 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, 203] • Accuracy of time, cost, and benefit estimates [see list p. 170, 204] • Auditor’s role?

46. SYSTEMS IMPLEMENTATION–PHASE VII • Auditors’ Role • 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

47. SYSTEMS MAINTENANCE–PHASE VIII PURPOSE:Changing systems to accommodate changes in user needs • 80/20 rule • Importance of documentation? • Facilitate efficient changes

48. Project Authorization Preliminary Feasibility SystemsPlanning Project Proposal Project Schedule SystemsAnalysis System Analysis Rpt ConceptualDesign DFD (general) SystemsSelection System Selection Rpt FeasibilityStudy Cost-BenefitAnalysis DetailedDesign DFD (Detail) ER Diagram Detailed Design Rpt Relational Model Normalized Data System Implementation Post-Impl. Review Program Flowcharts Documentation User Acceptance Rpt

49. CONTROLLING & AUDITING THE SDLC • 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 • A properly functioning system development process ensures only needed application are created, properly specified and have adequate controls and thoroughly tested before implemented • The system maintenance process ensures that only legitimate changes are made to applications and are tested before implemented • If else, application testing and substantive testing is in place

50. CONTROLLING & AUDITING THE SDLC • Controlling New Systems Development • Systems authorization activities (economic justification and feasibility) • User specification activities (involvement) • Technical design activities • Documentation is evidence of controls • Documentation is a control! • Internal audit participation (control and liaison users and system pro) • User test and acceptance procedures (assurance group) • Audit objectives (p.206) • Audit procedures (p.206)