Presentation is loading. Please wait.

Presentation is loading. Please wait.

Systems Development and Analysis. ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-2 Introduction.

Similar presentations


Presentation on theme: "Systems Development and Analysis. ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-2 Introduction."— Presentation transcript:

1 Systems Development and Analysis

2 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-2 Introduction This lecture discusses three topics: system development life cycle process of demonstrating the feasibility of a new AIS behavioral aspects of change that companies must deal with to successfully implement a new system

3 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-3 The Systems Development Life Cycle What are the five steps in the systems development life cycle (SDLC)? 1. Systems analysis 2. Conceptual design 3. Physical design 4. Implementation and conversion 5. Operations and maintenance

4 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-4 The Systems Development Life Cycle Systems Analysis Conduct initial investigation Conduct system survey Conduct feasibility study Determine information needs and system requirements Deliver systems requirements Feasibility analysis and decision points

5 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-5 Systems Analysis When a new or improved system is needed, a written request for systems development is prepared. The request describes the current system’s problems, why the change is needed, and the proposed system’s goals and objectives. It also describes the anticipated benefits and costs.

6 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-6 The Systems Development Life Cycle Feasibility analysis and decision points Conceptual Design Evaluate design alternatives Develop design specifications Deliver conceptual design requirements

7 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-7 Conceptual Systems Design Evaluate design alternatives: The design team should identify and evaluate design alternatives using the following criteria: 1. How well it meets organizational and system objectives 2. How well it meets users’ needs 3. Whether it is economically feasible 4. Its advantages and disadvantages

8 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-8 Conceptual Systems Design Prepare design specifications: Once a design alternative has been selected, the team develops the conceptual design specifications for the following elements: 1. Output 2. Data storage 3. Input 4. Processing procedures and operations

9 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-9 Conceptual Systems Design Prepare conceptual systems design report: At the end of the conceptual design a conceptual systems design report is developed and submitted. 1. To guide physical systems design activities 2. To communicate how management and user information needs will be met 3. To help assess systems’ feasibility

10 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-10 The Systems Development Life Cycle Feasibility analysis and decision points Physical Design Design:output/database/input Develop programs Develop procedures Design controls Deliver developed system

11 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-11 Physical Systems Design Physical design translates the broad, user-oriented AIS requirements of conceptual design into detailed specifications that are used to code and test the computer program. Conceptual systems design Physical systems design

12 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-12 Physical Systems Design Output design: The objective of output design is to determine the characteristics of reports, documents, and screen displays. Output fits into one of four categories: 1. Scheduled reports 2. Special-purpose analysis 3. Triggered exception reports 4. Demand reports

13 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-13 Physical Systems Design File and database design: What are some file and database design considerations? – medium of storage – organization and access – processing mode – maintenance – size and activity level – Security – Error Detection

14 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-14 Physical Systems Design Input design: When evaluating input design, the design team must identify the different types of data input and optimal input method. What are the two principal types of data input? 1. Forms 2. Computer screens

15 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-15 Physical Systems Design Program design is one of the most time- consuming activities in the entire SDLC. Programs should be subdivided into small, well-defined modules to reduce complexity. What is this referred to as? – structured programming Modules should interact with a control module rather than with each other.

16 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-16 Physical Systems Design Procedures design should answer the who, what, where, and how questions related to all AIS activities. What should procedures cover? – input preparation – transaction processing – error detection and corrections – control

17 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-17 Physical Systems Design – reconciliation of balances – database access – output preparation and distribution – computer operator instructions

18 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-18 Physical Systems Design Control design: What are some control design considerations? – validity – authorization – accuracy – access – numerical control – audit trail – Security – Integrity

19 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-19 Physical Systems Design At the end of the physical design phase the team prepares a physical systems design report. This report becomes the basis for management’s decision whether to proceed to the implementation phase.

20 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-20 The Systems Development Life Cycle Feasibility analysis and decision points Implementation and Conversion Develop plan Install hardware and software Train personnel, test the system Complete documentation Convert from old to new system Fine-tune and review Deliver operational system

21 Systems Implementation Implementation planning Complete documentation Develop and test software programs Conversion Prepare site; install and test hardware Select and train personnel Test system

22 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-22 Systems Implementation Implementation planning: An implementation plan consists of implementation tasks, expected completion dates, cost estimates, and the person or persons responsible for each task. Planning MAY include adjustments to the company’s organizational structure.

23 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-23 Systems Implementation Develop and test software programs: Seven steps are followed when developing and testing software programs. 1. Determine user needs 2. Develop a plan 3. Write program instructions (code) 4. Test the program 5. Document the program

24 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-24 Systems Implementation 6. Train program users 7. Install and use the system Prepare site; install and test hardware: A PC requires little site preparation. A large system may require extensive changes, such as environmental controls, UPS power and raised floor space. Site preparation should begin well in advance of the installation date.

25 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-25 Systems Implementation Select and train personnel: Employees can be hired from outside the company or transferred internally. Effective AIS training should include employees’ orientation to new policies and operations. Training should occur before systems testing and conversion.

26 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-26 Systems Implementation Complete documentation: Three types of documentation must be prepared for new systems. 1. Development documentation 2. Operations documentation 3. User documentation

27 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-27 Systems Implementation Test system: There are three common forms of testing. 1. Walk-through 2. Processing of test transactions 3. Acceptance tests

28 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-28 Systems Implementation Conversion: There are four conversion approaches. 1. Direct conversion 2. Parallel conversion 3. Phase-in conversion 4. Pilot conversion

29 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-29 Systems Implementation Old system New system Direct Conversion Method

30 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-30 Systems Implementation Old system New system Parallel Conversion Method

31 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-31 Systems Implementation Phase-in Conversion Method Old system New system

32 Systems Implementation Pilot Conversion Method 12 3 312 3 3 2 2 1 1 Old New OldNew

33 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-33 Systems Implementation Data conversion: Data files may need to be modified in three ways: 1. Files may be moved to a different storage 2. Data content may be changed 3. File format may be changed

34 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-34 The Systems Development Life Cycle Operation and Maintenance Operate system Modify system Do ongoing maintenance Deliver improved system Systems Analysis

35 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-35 Operation and Maintenance What are some factors to consider during the postimplementation review? – goals and objectives – satisfaction – benefits – costs – reliability – controls and security

36 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-36 Operation and Maintenance What are some questions to answer during the postimplementation review? – Does the system produce accurate and complete data? – Is the system safeguarded against unintentional errors, fraud, and unauthorized intrusion? – Is the system documentation complete and accurate?

37 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-37 The Players Who are the people involved in developing and implementing AIS? – management – accountants – information systems steering committee – project development team – systems analysts and programmers – external players

38 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-38 The Players What are top management’s roles? – providing support and encouragement – establishing system goals and objectives – determine information requirements

39 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-39 The Players What are accountants’ roles? – determine their information needs – may be members of the project development team – play an active role in designing system controls – Assist with Cost / Benefit – Evaluate system including controls

40 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-40 The Players What are the steering committee’s roles? – set policies that govern the AIS in line with corporate strategy – ensures top-management participation – guidance and control – facilitates coordination and integration of IS activities

41 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-41 The Players What are the project development team’s roles? – plan each project – monitor project – make sure proper consideration is given to the human element – Implement, test & train users

42 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-42 The Players What are the system analyst’s and programmer’s roles? – study existing systems – design new systems and prepare specifications – write computer programs

43 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-43 Planning Systems Development Why is planning an important step in systems development? – consistency – efficiency – cutting edge – lower costs – adaptability

44 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-44 Why Do Projects Fail? 1. Failure to establish Senior Mgmt Commitment 2. Taking shortcuts with System Development methodology 3. Unclear project expectations 4. Resistance to Change 5. Inadequate monitoring, reporting or controls 6. Not enough resources to complete project

45 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-45 Why Do Projects Fail? 7. A project plan that is too simple, too complex or unrealistic 8. Imprecise objectives 9. Poor estimating techniques 10 Poorly trained analysts & programmers 11. Conflicting goals & objectives among project team members & users 12. Use of inappropriate software or hardware

46 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-46 Feasibility Analysis What five important aspects need to be considered during a feasibility study? 1. Technical feasibility 2. Operational feasibility 3. Legal feasibility 4. Scheduling feasibility 5. Economic feasibility

47 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-47 Feasibility Analysis Economic feasibility is the most frequently analyzed of the five aspects. What is the basic framework for feasibility analysis? – capital budgeting model

48 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-48 Feasibility Analysis What are some capital budgeting techniques? – payback period – net present value (NPV) – internal rate of return (IRR)

49 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-49 Behavioral Aspects of Change Individuals involved in systems development are agents of change who are continually confronted by people’s reaction and resistance to change. The best system will fail without the support of the people it serves.

50 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-50 Behavioral Aspects of Change Why do behavioral problems occur? – personal characteristics and background – manner in which change is introduced – experience with prior changes – communication – disruptive nature of the change process – fear

51 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-51 Behavioral Aspects of Change How do people resist AIS changes? – aggression – projection – avoidance

52 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-52 Behavioral Aspects of Change How can behavioral problems be improved? – meet needs of the users – keep communication lines open – maintain a safe and open atmosphere – obtain management support – allay fears – solicit user participation

53 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-53 Behavioral Aspects of Change – provide honest feedback – make sure users understand the system – describe new challenges and opportunities – reexamine performance evaluation – avoid emotionalism – present the system in the proper context – control the users’ expectations – keep the system simple

54 ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-54 End of Lecture


Download ppt "Systems Development and Analysis. ©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart Lecture 03-2 Introduction."

Similar presentations


Ads by Google