Chapter 14

1. Chapter 14 The Systems Development Process, Part II: System Selection, Detailed Design, and System Implementation

2. Objectives for Chapter 14 • Factors to be considered in a detailed feasibility study • The three major steps involved in a cost-benefit analysis of proposed information systems • Advantages and disadvantages of the commercial software option, and the decision-making process used to select commercial software • The sequence of events that constitute the detailed design phase of the SDLC • The design procedure for both hard-copy and electronic input and output media • The design of the process component of a system • Principal features of a system implementation, including the use of PERT and GANTT charts to create an implementation schedule • The different types of system documentation and the purposes they serve • Procedures employed in database and system conversion

3. The Seven Stages of the SDLC SYSTEMS DEVELOPMENT LIFE CYCLE New Systems Development System Implementation Conceptual Design System Selection Detailed Design Systems Planning Systems Analysis Maintenance Multiple Conceptual Designs Fully Documented System Systems Analysis Report System Selection Report Detailed System Design Project Proposals & Schedules Required Documentation

4. Stage 4: System Evaluation and Selection • This phase is an optimization process that seeks to identify the best system and make an informed decision under uncertain circumstances. • Two steps • detailed feasibility study • cost-benefit analysis

5. Detailed Feasibility Study • This should be performed by an informed, but independent group: • the project manager • user representatives • systems professionals who are not a part of the project

6. Feasibility Factors • Technical - well-established and understood technologies represent less risk and will receive a higher score • Legal - need to assess critical control, security, audit trail, and privacy issues • Operational - the availability of well-trained, motivated, and experienced users must be assessed • Schedule - need to assess available development tools, the technology platform, the systems design, and user training requirements • Economic - costs are becoming better defined and assessment becomes easier

7. Cost-Benefit Analysis • Cost-benefit analysis helps management determine whether the benefits received from a proposed system will outweigh its costs. • It is useful for comparing competing systems designs. • Intangible benefits make this process difficult.

8. Cost-Benefit Analysis • Identify the costs. • Identify the benefits. • Compare the two. 500 400 300 200 100 0 $ Present Value of Total Costs Payback Point Present Value of Total Benefits 1 2 3 4 5 6 7 Period

9. Identification of Costs and Benefits • Examples of One-Time Costs: • hardware and software acquisition • training personnel • Examples of Recurring Costs: • hardware and software maintenance • personnel • Examples of Tangible Benefits: • increased sales within existing markets • labor reduction • Examples of Intangible Benefits: • increased customer satisfaction • improved employee satisfaction

10. Systems Selection Report • This formal document consists of a: • revised feasibility study • cost-benefit analysis • list and explanation of intangible benefits for each alternative • On the basis of this report, the steering committee will select a single system.

11. The Purchase of Commercial Systems Packages • Four factors have stimulated the growth of commercial software: • relatively low cost • prevalence of industry-specific vendors • growing demand by small businesses • trend toward downsizing and distributed data processing

12. Types of Commercial Systems Packages • Turnkey systems are completely finished and tested systems that are ready for implementation. • Backbone systems provide a basic system structure on which to build. • Vendor-supported systems are custom-developed and maintained by a vendor for a customer. • ERP systems are difficult to classify since they have characteristics of all of the above.

13. Pros and Cons of Commercial Software • Advantages: • decreased implementation time • decreased cost • reduced probability of program errors • Disadvantages: • reduced independence - the customer is dependent on the vendor for maintenance • less flexibility in system • greater difficulty in modifying the system as needs change over time

14. Four Steps in Choosing a Commercial Package • Analyze needs and develop detailed specifications of the system requirements. • Send out the Request for Proposals to all prospective vendors to serve as a comparative basis for initial screening. • Gather the facts about each vendor’s system using multiple sources and techniques. • Analyze the findings and make a final selection.

15. The Role of Accountants in Evaluation and Selection • The accountant should ensure that: • only escapable costs are used in calculations of cost savings benefits • reasonable interest rates are used in measuring present values of cash flows • one-time and recurring costs are completely and accurately reported • realistic useful lives are used in comparing competing projects • intangible benefits are assigned reasonable financial values

16. Stage 5: Detailed Systems Design • This stage follows a logical sequence of events: • data model the business process and design conceptual views • design the normalized database tables • design the physical user views (output and input views) • develop the process modules • specify the system controls • perform a system walkthrough

17. Data Modeling • Data Modeling is the task of formalizing the data requirements of the business process as a conceptual model. • The primary tool is the ER diagram which is used to depict the entities or data objects in the system. • Each entity in an ER diagram is a candidate for a conceptual user view that must be supported by the database.

18. The Normalization Process • A process which systematically splits unnormalized complex tables into smaller tables that meet two conditions: • all nonkey (secondary) attributes in the table are dependent on the primary key • all nonkey attributes are independent of the other nonkey attributes • When unnormalized tables are split and reduced to third normal form, they must then be linked together by foreign keys.

19. Designing Output Views • Output is the information produced by the system to support user tasks and decisions. • Output attributes: • relevant • summarization • except orientation • timely • accurate • complete • concise

20. Output Reporting Techniques • Different users prefer different styles of output (tables, matrices, charts, and graphs) and modes of output (hard copy vs. display screen). • Systems designers must identify these styles and provide output in the desired style.

21. Designing Input Views • Data input views are used to capture the relevant facts about the resources, events, and agents involved in business process transactions. • Input may be either hard copy input documents or electronic input.

22. Designing Hard Copy Input • Items to Consider: • How will the document be handled? What quality paper? • How long will the form be stored and in what type of environment? • How many copies are required? • What size form is necessary? Non-standard form can cause printing and storage problems.

23. Hard Copy Form Design • The objective is to design the form so as to reduce clerical errors and omissions and allow the data to be collected as efficiently as possible. • Zones- areas that contain related data-use lines, captions, or boxes • Embedded instructions - should be on the form, not as a separate sheet, and should be written in an active voice

24. 9 10 9 10 9 10 9 10 User’s View - Purchase Order 1 Purchase Order PO 39763 2 Vendor Name Vendor Address 3 4 Telephone: Order Date Date Required Vendor Number 6 Terms 8 7 5 Part No. Unit Price Extended Price Description Qty 11 12 11 12 Calculated Field 11 12 11 12 13 Total Cost

25. Source Document Electronic Input Source Document Electronic Input Designing Electronic Input Input may be from either a source document or data found directly in the computer system. Economic Event Data Collection Transaction File Audit Trail Input From Source Document File Audit Trail Direct Input Transaction File Economic Event

26. Direct Input • This method can reduce the input errors that result from additional clerical steps involved in input from source documents. • Direct data collection uses intelligent forms for online editing that help the user complete the forms and make calculations automatically.

27. Data Entry Devices • point-of-sale terminals • touch screens • mouse • magnetic ink character recognition devices • optical character recognition devices • voice and touch-tone recognition devices

28. Designing the Process Component • This phase begins with the DFDs produced in the general design phase. • The first task is to decompose the existing DFDs to a degree of detail that will serve as the basis for creating structure diagrams. • The structure diagrams will provide the blueprints for writing the actual program modules.

29. Lower-Level DFD for an AP Process 1.1 1.2 1.3 Receive Goods Authorize Purchase Order Goods Vendor Purchase Req Purchase Order Receiving Report Invoice 1.4.1 1.4.2 1.4.3 1.4.4 Receive P.R. Receive P.O. Receive Rec. Rpt. Receive Invoice 1.5 Prepare Payment PR File Open PO File RR File Invoice File 1.4.5 Review & Compare Approved Liabilities 1.4.7 Payment Voucher Prepare Voucher AP Sub- Ledger Post Voucher Register 1.4.6 Post General Ledger Department Update AP & Prepare Voucher Posting Data Journal Voucher

30. The Modular Approach • Each module performs a single task. • Correctly designed modules possess two attributes: • loosely coupled (low amounts of exchange of data between modules) • strongly cohesive (small number of tasks performed in each module)

31. Pseudocode • Allows the functional characteristics and logic of the modules to be expressed without having to code in any specific programming language • Allows end users to be actively involved in this step even though they may lack programming skills

32. Design System Controls • The last step in the detailed design phase. Need to consider: • computer processing controls • database controls • manual controls over input to and output from the system • operational environment controls • This step allows the design team to review, modify, and evaluate controls with a system-wide perspective that did not exist when each module was being designed independently.

33. System Design Walkthrough • This step is performed by the development team to ensure the design is free from conceptual errors that could become programmed into the final system. • Some firms may use a quality assurance group to perform the task. This is an independent group of programmers, analysts, users, and internal auditors.

34. Stage 6: Systems Implementation • The steps that have the greatest impact on accountants and auditors are: • managing the systems implementation • developing system software • documenting the system software • converting the databases • converting to the new system • conducting the post-implementation review

35. Managing the Systems Implementation • An implementation schedule must be created. • Project Evaluation and Review Techniques (PERT) Charts - show the relationships among the many activities. The critical path shows which activities, if delayed, can cause the overall project to be delayed. • GANTT Charts - a horizontal bar chart which shows the project time frame at a glance and compares budget with actual implementation times.

36. Developing Application Software • If the organization intends to develop software in-house, then a programming language must be selected.

37. Programming Languages

38. 3rd Generation Languages • COBOL, FORTRAN, C, BASIC, and PL1, among others • 3GLs function efficiently because they are compiled programs. • The operational procedures are specified in precise detail which allows greater control over process functionality. • The code is clearly visible to the programmers, which facilitates debugging and maintenance.

39. 4th Generation Languages • Program generators, query languages, and screen and report generators • The designer may more easily experiment and design as they go. • These languages are easier for non-technical staff to use.

40. The Modular Approach to Programming • Promotes programming efficiency since modules can be both programmed and tested independently • Promotes maintenance efficiency since small modules are easier to analyze and change • Promotes greater control since they are less likely to contain material errors of fraudulent logic

41. Software Testing • Programs must be thoroughly tested before they are implemented. • Individual modules should be tested with test data containing both “good” and “bad” data. All logic procedures should be tested. • After the individual modules have been tested, the entire system should be tested as a whole.

42. Documenting the System • Documentation describes how the system works and should be made for: • designers and programmers - comment lines in programs, system flowcharts, and program flowcharts • operator documentation - run manuals • user documentation - instructions on how to use the system, tutorials, and help features • accountants and auditors - all of the above as well as document flowcharts

43. Converting the Databases • This is the transfer of data from its current form to the format or medium required by the new system. • Data conversion is risky and must be carefully controlled by the following precautions: • validation - old database must be inspected before conversion • reconciliation - after the conversion, the new database must be reconciled against the original • backup - copies of the original files must be kept as backup against discrepancies in the converted data

44. Converting to the New System Three approaches: • Cold turkey cutover (plunge) - the firm switches to the new system on a particular day and simultaneously terminates the old system. This is the riskiest approach. • Phased cutover - modules are implemented in a piecemeal fashion. The risk of a devastating failure can be reduced. • Parallel cutover - the old system and new system are run simultaneously. This is the safest, yet costliest, approach.

45. Post-Implementation Review • The objectiveis to measure the success of the system and of the process after the dust has settled. Want to assess: • system design adequacy • accuracy of time, cost, and benefit estimates • This information can provide feedback to improve future systems development projects.

46. The Role of Accountants • Most system failures are due to poor designs and improper implementation. Accountants should provide their expertise to help avoid inadequate systems by: • providing technical expertise for financial reporting requirements • specifying documentation standards for auditing purposes • verifying control adequacy in accordance with SAS 78