Chapter 5 Audcis Systems Development PDF
Document Details
Holy Angel University
Tags
Summary
This document presents information on CHAPTER 5 SYSTEMS DEVELOPMENT & PROGRAM CHANGE ACTIVITIES at Holy Angel University. It discusses the involvement of systems professionals, end users, and stakeholders in various stages of the system development life cycle (SDLC). The document also covers topics such as information systems acquisition, types of commercial systems, and different phases of the SDLC, such as systems planning, systems analysis, conceptual system design, system evaluation and selection, detailed design, application programming and testing, system implementation (go live), and maintenance with internal controls. The objective of this presentation is to explain the procedures of maintaining systems and controlling new systems.
Full Transcript
XAUDCIS HOLY ANGEL UNIVERSITY Systems Professionals (for internally developed systems) ◦ Systems analysts ◦ Systems designers ◦ Programmers End Users ◦ Managers ◦ Operations personnel ◦ Accountants * ◦ Internal auditors * Stakeholders...
XAUDCIS HOLY ANGEL UNIVERSITY Systems Professionals (for internally developed systems) ◦ Systems analysts ◦ Systems designers ◦ Programmers End Users ◦ Managers ◦ Operations personnel ◦ Accountants * ◦ Internal auditors * Stakeholders ◦ Accountants * ◦ Internal auditors * Note Accountants & Internal Auditors fill multiple roles. ◦ External auditors 2 Creation/purchase of IS consumes significant resources and has financial resource implications. Quality of AISs and their output rests directly on SDLC activities that produce them. 3 As Users As members of development team As Auditors 4 Systems Strategy ◦ Help reduce risk of creating unneeded, unwanted, inefficient, ineffective systems Conceptual Design ◦ Control implications ◦ Auditability of system Systems Selection ◦ Economic feasibility 5 INHOUSE DEVELOPMENT COMMERCIAL SYSTEMS TRENDS IN COMMERCIAL SYSTEM ◦ Low Cost ◦ Emergence of Software Industry ◦ Growing Demand of Businesses ◦ Downsizing/ DDP IT Environment General Turnkey Special Purpose Accounting Systems Systems Systems Office Vendor Backbone Automation Supported Systems Systems Systems Advantages of Commercial Disadvantages of Software Commercial Software Independence Implementation Time The need for customized Cost systems (becomes dependent Reliability on vendor) Maintenance Programming Test Results & Testing MAINTENANCE Objective of Systems Planning is to link individual projects or applications to the strategic objectives of the firm. STEERING COMMITTEE & RESPONSIBILITIES (6) STRATEGIC SYSTEMS PLANNING – allocation, processing, budgeting, informed decisions by systems specialists 1. A plan that changes constantly is better than no plan at all. 2. Strategic planning reduces the crisis component in systems development. 3. Strategic systems planning provides authorization control for the SDLC. 4. Cost Management Project Planning Project Proposal Project Schedule AUDITOR’S ROLE: Adequate Systems Planning Takes Place Data Sources Data Stores Data Processes Transaction Data Flows Controls Volumes Bottlenecks Error Rates Resource Costs and redundant operations 1) The Survey Step & 2) Analysis of User’s Need Serves as the foundation for the rest of SDLC The Survey Step ◦ Disadvantages Current Physical Tar Pit (sucked in & bogged down); Thinking Inside the Box (improved current system rather radically new approach) ◦ Advantages of Surveying Current System What old aspect should be kept, force analysis, Isolating the root problem GATHERING FACTS & FACTS GATHERING TECHNIQUES Observation Task Participation Personal Interviews OPEN ENDED (allows to Reviewing Key elaborate) Documents QUESTIONNAIRES (more specific, more detailed) Systems Analysis Report (pg 195) An accountant is a stakeholder, therefore it should be involved in the analysis of needs of the proposed system for advanced features. Authorizing development of new systems Addressing and documenting user needs Technical design phases Participation of internal auditors Testing program modules before implementing ◦ Testing individual modules by a team of users, internal audit staff, and systems professionals Structured Design Approach (uses Several alternatives that satisfy Identify/ compare all the DFD) – Top Down; Starts with the the system requirements during distinguishing features, input, BIGGER PICTURE and then system analysis (TWO process, output from one design decomposed; uses data flow APPROACHES) to another (figure 5.50) diagrams Object Oriented Approach (uses Standard Components) ITERATIVE Auditor’s Role as a Stakeholder, APPROACH – reduced time for at least has an interest in the cost dev’t, maintenance, testing conceptual design, because of the and improved user support & impact on audit flexibility Perform Detailed Feasibility Study Technical Feasibility – develop in existing technology Economic Feasibility – availability of funds Legal Feasibility – conflicts between conceptual concept & discharge liabilities Operational Feasibility - compatibility Schedule Feasibility- ability to implement w/in acceptable time Perform Cost Benefit Analysis 1. Identify Costs (One Time Costs vs Recurring Costs) 2. Identify Benefits Tangible Benefits Intangible Benefits 3. Compare Costs and Benefits NPV Payback Period Break Even Point 1) Escapable Costs 2) Interest Rates 3) One time & recurring Costs 4) Realistic Useful Lives 5) Intangible Values Detailed description of the proposed system satisfies system requirements during Phase 2 & Phase 3. Perform System Design Walkthrough – Quality assurance group Review System Documentation ◦ Inputs & source documents ◦ Outputs, reports & operational documents ◦ Normalized data for database tables ◦ Update data dictionary ◦ Processing logic or Flow Charts 1) PROGRAM THE APPLICATION SYSTEM 2) TEST THE APPLICATION SYSTEM Procedural Languages(Cobol, Fortran, C, PL1) Event Driven Languages- uses icons Microsoft VB; GUI Object Oriented Languages Programming the System-follow modular approach regardless of the language used 1. Programming Efficiency 2. Maintenance Efficiency 3. Control 2) Test the Application Software Testing Methodology ◦ Identifying programming & logical errors Testing Offline Before Deploying Online ◦ Never Ever Underestimate (Testing Environment vs Actual Environment) Test Data ◦ Should be retained for reuse ◦ Serves as a frame of reference for auditor in designing and evaluating future audit tests (i.e. the system has not undergone any change) Complete engagement of programmers, users, designers, database administrators, users and accountants Activities in this entail extensive costs 1. TESTING THE ENTIRE SYSTEM ◦ DOCUMENTING THE SYSTEM Designer & Programmer Documentation Operator Documentation User Documentation Novices Occasional Users Frequent Light Users Frequent Power Users ◦ USER HANDBOOK ◦ TUTORIALS ◦ HELP FEATURES 2. CONVERTING THE DATABASES 3. CONVERTING TO THE NEW SYSTEM Cold Turkey Cutover – most risky; all at once Phased Cutover- by modules; gradual Parallel Operation Cutover – simultaneous; reconciliation THE AUDITOR’S ROLE IN SYSTEM IMPLEMENTATION 1. Provide Technical Expertise 2. Specify Documentation Standards 3. Verify Control Adequacy & Compliance w/ SOX POST IMPLEMENTATION REVIEW 4. Systems Design Adequacy 5. Accuracy of Time, Cost and Benefit Estimates Accommodate Changes in Users’ Needs It could be extensive Maintenance represents significant outlay compared to initial development costs. Last, longest and most costly phase of SDLC ◦ Up to 80-90% of entire cost of a system Audit Procedures: ◦ All maintenance actions should require Technical specifications Testing Documentation updates Formal authorizations for changes Systems Authorization Activities User Specifications Activities Technical Design Activities Internal Audit Participation User Test and Acceptance Procedure Auditing objectives: ensure that... ◦ SDLC activities applied consistently and in accordance with management’s policies ◦ system as originally implemented was free from material errors and fraud ◦ system was judged to be necessary and justified at various checkpoints throughout the SDLC ◦ system documentation is sufficiently accurate and complete to facilitate audit and maintenance activities Maintenance Authorization, Testing & Documentation Source Program Library Controls – where application program source code are stored SPL – No Controls Controlled SPLMS Environment 1) Storing programs on the SPL 2) Retrieving programs for maintenance purposes 3) Deleting obsolete programs from lib 4) Documenting program changes to provide audit trail of the changes ◦ Password Control ◦ Separate Test Libraries ◦ Audit Trail & Management Reports ◦ Program Version Numbers ◦ Controlling Access to Maintenance Commands Audit Procedures: ◦ New systems must be authorized. ◦ Feasibility studies conducted. ◦ User needs analyzed and addressed. ◦ Cost-benefit analysis completed. ◦ Proper documentation completed. ◦ All program modules thoroughly tested before implementation. ◦ Checklist of problems was kept. ◦ Systems documentation complies with organizational requirements Auditor compares the current program version number in the documentation file vs current version number of the production program Auditor reconciles program maintenance requests, program listings and program changes to verify the need for and accuracy of program Figure 5.14 Auditing objectives: detect any unauthorized program maintenance and determine that... ◦ maintenance procedures protect applications from unauthorized changes Reconcile program version numbers Confirm maintenance authorization ◦ applications are free from material errors Reconcile the source code Review test results Retest the program ◦ program libraries (where programs are stored) are protected from unauthorized access Review programmer authority table Test authority table 32