Chapter 13

1. Chapter 13 The Systems Development Process, Part I: Introduction to the Systems Development Life Cycle

2. Objectives for Chapter 13 • Identify the seven stages in the SDLC • Common problems that can lead to failure in the SDLC process • Use of prototyping and computer-aided software engineering in the SDLC • Importance of strategic planning for systems • What transpires during systems analysis • Basic features of both the structured and object-oriented approaches to systems design • How accountants participate in the SDLC activities

3. The Systems Development Life Cycle (SDLC) • A logical sequence of activities used to identify new systems needs and to develop new systems to support those needs. • The SDLC model may be understood as consisting of two major phases comprising seven stages.

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

5. Participants in Systems Development • Systems Professionals - gather and analyze facts about problems with the current system and formulate a solution • systems analysts • systems designers • programmers • End Users - the primary users’ needs are solicited • Stakeholders - individuals who have an interest in the system but are not end users.

6. Why Are Accountants Involved with SDLC? • The creation of an information system consumes significant resources and has financial resource implications. • The quality of accounting information systems and their output rests directly on the SDLC activities that produce them.

7. How are Accountants Involved with the SDLC? • Accountants are users and must provide a clear picture of their problems and needs. • Accountants are members of the development team. • Accountants are involved in systems development as auditors to ensure the system is designed with appropriate computer audit techniques.

8. Up to 25% of all systems projects fail! Why? • Poorly specified systems requirements • communication problems • time pressures • Ineffective development techniques • paper, pencils, templates, erasers instead of software tools, such as CASE • Lack of user involvement in systems development systems developer end user

9. Prototyping • Prototyping is a technique for providing users a preliminary working version of the system. • It is built quickly and relatively inexpensively with the intention it will be modified. • As the users work with the prototype and make suggestions for changes, a better understanding of the true requirements of the system is achieved.

10. Prototyping Techniques Identify Conceptual User Specifications Change Prototype Per User Feedback Develop Prototype into Finished System Present Prototype to Users Obtain User Feedback Develop Prototype Discard Prototype and Develop System Under Traditional SDLC Procedures

11. Computer-Aided Software Engineering (CASE) • CASE technology involves the use of computer systems to build computer systems. • CASE tools are commercial software products consisting of highly integrated applications that support a wide range of SDLC activities.

12. Uses of CASE Tools • define user requirements • create physical databases from conceptual user views • produce system design specifications • automatically generate program code • facilitate the maintenance of programs created by both CASE and non-CASE techniques

13. CASE Spectrum of Support Tools for the SDLC SYSTEMS DEVELOPMENT LIFE CYCLE New Systems Development Systems Planning Systems Analysis Conceptual Design System Selection Detailed Design System Implementation Maintenance Coding Tools Modeling Tools Design Tools Maintenance Tools Analysis Tools BACK END, LOWER CASE TOOLS FRONT END, UPPER CASE TOOLS

14. Overview of CASE System CASE Outputs Lower CASE Models Upper CASE Models Context DFD Intermediate DFD DFD Model Prototype Model Design Model Coding Model Maintenance Model Elementary DFD Prototype Screens CASE System Structure Diagrams Central Repository Program Code Database Structures User Workstations

15. Data Flow Diagrams (DFDs) • DFDs are used to represent multiple levels of detail. • Context-level DFDs are used to present an overview model of the business activities and the primary transactions processed by the system. • It does not include a detailed definition of data files and specific procedures.

16. Reduced system complexityand maintenance cost Increased flexibility Capacity to review alternative designs Benefits Reusable program code and documentation Promotion of user involvement Advantages of CASE Quicker development process

17. Product cost Program efficiency Start-up time and cost Costs Incompatible CASE tools Disadvantages of CASE

18. Joint Application Development (JAD) • JAD employs CASE technology and prototyping to facilitate end user involvement in systems development. • JAD uses time efficiently and effectively to reduce the user-analyst communications barrier. • A typical JAD session is conducted in a conference room equipped with a CASE workstation and a JAD coordinator. • End users actively participate in the development process.

19. Stage 1: Systems Planning • The objective of systems planning is to link individual systems projects or applications to the strategic objectives of the firm. STRATEGIC OBJECTIVES OF THE FIRM Business Plan Systems Projects Systems Plan

20. Systems Steering Committee • The steering committee provides guidance and reviews the status of systems projects and typically includes the CEO, CFO, CIO, senior management from user areas and computer services, and an internal auditor. • Typical responsibilities are: • resolving conflicts • reviewing projects and assigning priorities • budgeting funds • reviewing the status of projects • determining whether projects should be continued

21. Strategic Systems Planning • involves the allocation of systems resources at the macro level for a time frame of 3 to 5 years • is important because: • it charts the path the firm will follow to reach its information systems goal • it reduces the crisis component in systems development • it provides authorization control for the SDLC

22. Project Planning • allocates resources to individual applications within the framework of the strategic plan • includes: • recognizing the problem • defining the problem • specifying system objectives • determining project feasibility

23. Specifying System Objectives • The strategic objectives of the firm and the operational objectives of the information systemsmust be compatible. • At this point, the objectives only need to be defined in general terms.

24. Preliminary Project Feasibility • Technical feasibility - is the technology necessary available? • Economic feasibility - are the funds available and appropriate for the system? • Legal feasibility - does the system fall within legal boundaries? • Operational feasibility - can procedural changes be made to make the system work? • Schedule feasibility - can the project be completed by an acceptable time period?

25. Systems Project Proposal • A systems project proposal provides management with a basis for deciding whether or not to proceed with the project. • It summarizes the findings of the study and makes a general recommendation. • It outlines the linkage between the objectives of the proposed system and the business objectives of the firm.

26. Project Schedules • present management’s commitment to the project • contain a budget of the time and costs for all phases of the SDLC

27. Announcing the New System Project • The most delicate aspect of the SDLC • All users need to be made to understand the objectives of the new system. • End user managers who view the new system as a potential benefit to their jobs, rather than a threat to their personal well-being, are more likely to comply and cooperate with the project team’s objectives.

28. The Accountant’s Role in Systems Planning • Accountants are often called on to provide expertise in evaluating the feasibility of projects during the planning process. • As auditors, accountants must routinely examine the systems planning phase of the SDLC since careful systems planning helps to prevent unnecessary development costs.

29. Stage 2: Systems Analysis • A business problem must be fully understood before a solution can be formulated. • A defective analysis will lead to a defective solution. • System analysis is a two-step process • surveyof the current system • an analysisof the users’ needs

30. The Survey Step • Facts must be gathered regarding: • data sources and data stores; users; processes; data flows; controls; transaction volumes; error rates; resource costs; bottlenecks and redundant operations • Fact-gathering techniques: • JAD sessions; observation; task; participation; personal interviews; reviewing key documents

31. Survey of Current System • Advantages • allows aspects of the old system which should be kept to be identified • aids in planning the implementation of the new system • may allow conclusive determination of the cause of the reported problem symptoms • Disadvantages • can stifle new ideas

32. The Analysis Step • The systems analysis is an intellectual process that is commingled with fact gathering. • A formal systems analysis report, prepared and presented to the steering committee, contains: • reasons for system analysis • scope of study • problem identified with current system • statement of user requirements • resource implications • recommendations

33. The Accountant’s Role in Systems Analysis • The accountants’ expertise makes them important players in the design of a good, well-controlled system: • internal control standards • audit trail requirements • external reporting requirements

34. Conceptual Systems Design • An objective of this phase is to reach consensus between users and systems professionals on plausible alternative designs for the new system. • JAD sessions are an effective mechanism for achieving this objective.

35. The Structured Design Approach • is a disciplined way of designing systems from the top down • starts with the “big picture” of the proposed system and gradually decomposes it into greater detail so that it may be fully understood • utilizes DFD and structure diagrams

36. Structured Design Level of Detail • The systems designs during the conceptual phase should be general. • The designs should identify all the • inputs • outputs • processes • special features • It is necessary to distinguish one alternative from another.

37. Object-Oriented Design Approach • It builds information systems from reusable standard components or objects. • Once created, standard modules can be used in other systems with similar needs. • A library of modules can be created for future use.

38. Elements of the Object-Oriented Approach • Objects - equivalent to nouns • vendors, customers, inventory, etc. • Attributes - equivalent to adjectives • part number, quantity on hand, etc. • Operations - equivalent to verbs • review quantity on hand, reorder item

39. Characteristics of an Inventory Object Quantity on Hand Attributes Order Quantity Part Number Description Reorder Point Inventory Object Review Quantity Reorder Operations Reduce Replace

40. Classes and Instances • An object class is a logical grouping of individual objects that share the same attributes and operations. • An instance is a single occurrence of an object within a class. Inventory Object Class Instance Water Pump Wheel Bearing Alternator

41. Inheritance • Inheritance means that each object instance inheritsthe attributesandoperations of the class to which it belongs. • Object classes may also inherit from other object classes.

42. The Role of the Accountant in Conceptual Design • Accountants are responsible for the conceptual system, and the systems professionals are responsible for the physical system. • If important accounting considerations are not conceptualized at this point, they may be overlooked and expose the organization to potential financial loss. • The auditability of a system depends in part on its design characteristics.