Ais Romney 2006 Slides 18 Introduction To Systems Development

1. HAPTER 18 Introduction to Systems Development and Systems Analysis

2. INTRODUCTION <ul><li>Questions to be addressed in this chapter include: </li></ul><ul><ul><li>What are the phases in the systems development life cycle? </li></ul></ul><ul><ul><li>Who are the individuals involved in systems development? </li></ul></ul><ul><ul><li>What techniques are used to plan the development of a system? </li></ul></ul><ul><ul><li>How do you determine whether a particular system is feasible? </li></ul></ul><ul><ul><li>How do people respond to systems changes, and how can dysfunctional behavior be minimized? </li></ul></ul>

3. INTRODUCTION <ul><li>As the environment, technology, and competition change, an information system must continually undergo changes </li></ul><ul><li>These changes range from minor adjustments to major overhauls. </li></ul><ul><li>Occasionally the old system is scrapped and replaced. </li></ul>

4. INTRODUCTION <ul><li>Companies change their systems for a variety of reasons: </li></ul><ul><ul><li>To respond to changes in user needs or business needs </li></ul></ul><ul><ul><li>To take advantage of or respond to technology changes </li></ul></ul><ul><ul><li>To accommodate improvements in their business process </li></ul></ul><ul><ul><li>To gain a competitive advantage and/or lower costs </li></ul></ul><ul><ul><li>To increase productivity </li></ul></ul><ul><ul><li>To accommodate growth </li></ul></ul><ul><ul><li>To accommodate downsizing or distribute decision making </li></ul></ul><ul><ul><li>To replace a system that is aged and unstable </li></ul></ul>

5. INTRODUCTION <ul><li>Developing quality, error-free software is difficult, expensive, and time-consuming. </li></ul><ul><li>Projects tend to deliver less than expected and consume more time and money. </li></ul><ul><li>A KPMG survey found that 35% of all major information systems projects were classified as runaways—hopelessly incomplete and over budget. </li></ul><ul><ul><li>Major cause of runaways: Skimping on systems development processes. </li></ul></ul><ul><li>Omitting basic systems development steps becomes tempting but may lead to disaster as developers create well-structured systems that fail to meet user needs or solve business problems. </li></ul>

6. INTRODUCTION <ul><li>This chapter discusses five topics: </li></ul><ul><ul><li>Systems development life cycle </li></ul></ul><ul><ul><li>Planning activities during the systems development life cycle </li></ul></ul><ul><ul><li>Feasibility analysis </li></ul></ul><ul><ul><li>Behavioral aspects of change </li></ul></ul><ul><ul><li>Systems analysis </li></ul></ul>

7. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>Whether systems changes are major or minor, most companies go through a systems development life cycle. </li></ul><ul><li>In this section, we discuss the steps in the cycle and the people involved. </li></ul>

8. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>The five stages in the systems development life cycle are: </li></ul><ul><ul><li>Systems analysis </li></ul></ul><ul><ul><li>Conceptual Design </li></ul></ul><ul><ul><li>Physical Design </li></ul></ul><ul><ul><li>Implementation and Conversion </li></ul></ul><ul><ul><li>Operation and Maintenance </li></ul></ul>

10. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>As organizations grow and change, they may need more or better information. </li></ul><ul><li>Systems analysis is the first step. It includes: </li></ul><ul><ul><li>Initial investigation </li></ul></ul><ul><li>Involves gathering the information needed to buy or develop a new system and determining whether it is a priority. </li></ul>

11. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>As organizations grow and change, they may need more or better information. </li></ul><ul><li>Systems analysis is the first step. It includes: </li></ul><ul><ul><li>Initial investigation </li></ul></ul><ul><ul><li>Systems survey </li></ul></ul><ul><li>If the system is a priority, survey the existing system to define the nature and scope of the project and identify the strengths and weaknesses of the system. </li></ul>

12. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>As organizations grow and change, they may need more or better information. </li></ul><ul><li>Systems analysis is the first step. It includes: </li></ul><ul><ul><li>Initial investigation </li></ul></ul><ul><ul><li>Systems survey </li></ul></ul><ul><ul><li>Feasibility study </li></ul></ul><ul><li>Involves an in-depth study of the proposed system to determine whether it’s feasible. </li></ul>

13. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>As organizations grow and change, they may need more or better information. </li></ul><ul><li>Systems analysis is the first step. It includes: </li></ul><ul><ul><li>Initial investigation </li></ul></ul><ul><ul><li>Systems survey </li></ul></ul><ul><ul><li>Feasibility study </li></ul></ul><ul><ul><li>Determination of information needs and system requirements </li></ul></ul><ul><li>Involves finding out and documenting what users and management need. </li></ul><ul><li>This is the most important aspect of systems analysis. </li></ul>

14. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>As organizations grow and change, they may need more or better information. </li></ul><ul><li>Systems analysis is the first step. It includes: </li></ul><ul><ul><li>Initial investigation </li></ul></ul><ul><ul><li>Systems survey </li></ul></ul><ul><ul><li>Feasibility study </li></ul></ul><ul><ul><li>Determination of information needs and system requirements </li></ul></ul><ul><ul><li>Delivery of systems requirements </li></ul></ul><ul><li>Involves preparation of a report summarizing the systems analysis work. </li></ul><ul><li>This report is submitted to the information systems steering committee. </li></ul>

16. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>In the conceptual design phase, the company decides how to meet user needs. </li></ul><ul><li>Tasks in this phase include : </li></ul><ul><ul><li>Identify and evaluate design alternatives </li></ul></ul><ul><li>Possibilities include: </li></ul><ul><ul><li>Buying software </li></ul></ul><ul><ul><li>Developing in-house </li></ul></ul><ul><ul><li>Outsourcing </li></ul></ul>

17. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>In the conceptual design phase, the company decides how to meet user needs. </li></ul><ul><li>Tasks in this phase include : </li></ul><ul><ul><li>Identify and evaluate design alternatives </li></ul></ul><ul><ul><li>Develop design specifications </li></ul></ul><ul><li>Involves writing up details of what the system is to accomplish and how it is to be controlled and developed. </li></ul>

18. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>In the conceptual design phase, the company decides how to meet user needs. </li></ul><ul><li>Tasks in this phase include : </li></ul><ul><ul><li>Identify and evaluate design alternatives </li></ul></ul><ul><ul><li>Develop design specifications </li></ul></ul><ul><ul><li>Deliver conceptual design requirements </li></ul></ul><ul><li>These requirements will be forwarded to the information systems steering committee. </li></ul>

20. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>In the physical design phase, the broad, user-oriented requirements of the conceptual design are translated into detailed specifications that can be used by programmers to code the programs. </li></ul><ul><li>Tasks include: </li></ul><ul><ul><li>Design outputs, database, and inputs </li></ul></ul><ul><ul><li>Develop programs </li></ul></ul><ul><ul><li>Develop procedures </li></ul></ul><ul><ul><li>Design controls </li></ul></ul><ul><ul><li>Deliver developed system </li></ul></ul><ul><ul><ul><li>Goes to information systems steering committee </li></ul></ul></ul>

22. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>This is the capstone phase during which everything comes together. </li></ul><ul><li>Tasks include: </li></ul><ul><ul><li>Develop an implementation and conversion plan </li></ul></ul><ul><ul><ul><li>Needed because of the complexity and importance of this phase </li></ul></ul></ul><ul><ul><li>Install any new hardware and software </li></ul></ul><ul><ul><li>Train personnel </li></ul></ul><ul><ul><ul><li>New employees may need to be hired and trained or existing employees relocated. </li></ul></ul></ul><ul><ul><li>Test the system and make any needed modifications. </li></ul></ul><ul><ul><li>Complete the documentation. </li></ul></ul><ul><ul><li>Convert from the old to the new system. </li></ul></ul><ul><ul><li>Deliver operational system. </li></ul></ul><ul><ul><ul><li>Send the final report to the IS steering committee. </li></ul></ul></ul>

24. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>Once the system is up and running, operations and monitoring continue. </li></ul><ul><li>Tasks include: </li></ul><ul><ul><li>Fine-tune and do post-implementation review. </li></ul></ul><ul><ul><li>Operate the system. </li></ul></ul><ul><ul><li>Periodically review and modify the system. </li></ul></ul><ul><ul><li>Do ongoing maintenance. </li></ul></ul><ul><ul><li>Deliver improved system. </li></ul></ul>

25. SYSTEMS DEVELOPMENT LIFE CYCLE <ul><li>Eventually a major modification or system replacement is necessary, and the systems development life cycle (SDLC) will start over. </li></ul><ul><li>In addition to the preceding five phases, three activities are performed throughout the life cycle: </li></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Managing behavioral reactions to change </li></ul></ul><ul><ul><li>Assessing ongoing feasibility </li></ul></ul><ul><li>These three activities will be discussed in this chapter. </li></ul><ul><li>Additionally, the first phase in the SDLC, systems analysis, will be discussed in more detail. </li></ul>

26. THE PLAYERS <ul><li>Many people are involved in developing and successfully implementing an AIS, including: </li></ul><ul><ul><li>Top management </li></ul></ul><ul><ul><li>Accountants </li></ul></ul><ul><ul><li>The information systems steering committee </li></ul></ul><ul><ul><li>The project development team </li></ul></ul><ul><ul><li>Systems analysts </li></ul></ul><ul><ul><li>Computer programmers </li></ul></ul><ul><ul><li>External players </li></ul></ul>

27. THE PLAYERS <ul><li>Many people are involved in developing and successfully implement an AIS, including: </li></ul><ul><ul><li>Top management </li></ul></ul><ul><ul><li>Accountants </li></ul></ul><ul><ul><li>The information systems steering committee </li></ul></ul><ul><ul><li>The project development team </li></ul></ul><ul><ul><li>Systems analysts </li></ul></ul><ul><ul><li>Computer programmers </li></ul></ul><ul><ul><li>External players </li></ul></ul>

28. THE PLAYERS <ul><li>Top management’s role in systems development is to: </li></ul><ul><ul><li>Provide support and encouragement and a clear signal that user involvement is important. </li></ul></ul><ul><ul><li>Help align the systems with corporate strategies. </li></ul></ul><ul><ul><li>Establish system goals and objectives. </li></ul></ul><ul><ul><li>Review IS department performance and leadership. </li></ul></ul><ul><ul><li>Establish policies for project selection and organizational structure. </li></ul></ul><ul><ul><li>Participate in important systems decisions. </li></ul></ul>

29. THE PLAYERS <ul><li>User management needs to: </li></ul><ul><ul><li>Determine information requirements for departmental projects. </li></ul></ul><ul><ul><li>Assist systems analysts with project cost-benefit estimates. </li></ul></ul><ul><ul><li>Assign key staff members to development projects. </li></ul></ul><ul><ul><li>Allocate funds. </li></ul></ul>

31. THE PLAYERS <ul><li>Accountants also play an important role in systems development: </li></ul><ul><ul><li>As AIS users, they must determine their information needs and systems requirements and communicate them to system developers. </li></ul></ul><ul><ul><li>As members of project development teams or steering committees, they help management in the development process. </li></ul></ul><ul><ul><li>They are also active in: </li></ul></ul><ul><ul><ul><li>Designing system controls and monitoring and testing these controls. </li></ul></ul></ul><ul><ul><ul><li>Ensuring the system is easy to audit. </li></ul></ul></ul><ul><ul><li>Controls and “auditability” need to be built in early to minimize costs and inefficiencies later. </li></ul></ul>

33. THE PLAYERS <ul><li>The information systems steering committee is an executive-level committee whose duty is to plan and oversee the IS function. </li></ul><ul><ul><li>Consists of high level management, such as: </li></ul></ul><ul><ul><ul><li>Controller </li></ul></ul></ul><ul><ul><ul><li>IS Manager </li></ul></ul></ul><ul><ul><ul><li>User department managers </li></ul></ul></ul><ul><ul><li>Sets policies to govern the AIS and assure top-management participation, guidance, and control. </li></ul></ul><ul><ul><li>Attempts to encourage goal congruence and reduce goal conflict. </li></ul></ul>

35. THE PLAYERS <ul><li>The project development team includes systems specialists, managers, accountants, auditors, and users whose responsibility is to guide development </li></ul><ul><li>Their job: </li></ul><ul><ul><li>Plan each project. </li></ul></ul><ul><ul><li>Monitor to ensure timely and cost-effective completion. </li></ul></ul><ul><ul><li>Ensure the human element is considered. </li></ul></ul><ul><ul><li>Communicate project status to top management and steering committee. </li></ul></ul><ul><ul><li>Communicate and meet with users to: </li></ul></ul><ul><ul><ul><li>Consider ideas </li></ul></ul></ul><ul><ul><ul><li>Discuss progress </li></ul></ul></ul><ul><ul><ul><li>Eliminate surprises </li></ul></ul></ul><ul><ul><li>The team approach produces more effective results and better user acceptance. </li></ul></ul>

37. THE PLAYERS <ul><li>Systems analysts study existing systems, design new ones, and prepare specifications that are used by programmers. </li></ul><ul><ul><li>They interact with technical personnel and users to bridge the gap. </li></ul></ul><ul><ul><li>They are responsible for ensuring the system meets user needs. </li></ul></ul>

39. THE PLAYERS <ul><li>Computer programmers write the computer programs, using the specs developed by the systems analysts. </li></ul><ul><li>They also modify and maintaining existing programs. </li></ul>

41. THE PLAYERS <ul><li>External players include: </li></ul><ul><ul><li>Customers </li></ul></ul><ul><ul><li>Vendors </li></ul></ul><ul><ul><li>Auditors </li></ul></ul><ul><ul><li>Governmental entities </li></ul></ul><ul><li>Their needs must also be met in systems development. </li></ul>

42. PLANNING SYSTEMS DEVELOPMENT <ul><li>Several activities must be performed at various times throughout the SDLC. </li></ul><ul><li>One of these activities is planning. </li></ul><ul><li>The organization should have plans for: </li></ul><ul><ul><li>The long range </li></ul></ul><ul><ul><li>Each systems development project </li></ul></ul><ul><ul><li>Each phase of each systems development project </li></ul></ul><ul><li>We’ll discuss these plans and a number of techniques to develop them. </li></ul>

43. PLANNING SYSTEMS DEVELOPMENT <ul><li>We’ve all experienced the disasters that occur when we fail to plan. </li></ul><ul><li>Suppose you bought a personal computer on impulse without thinking about what you wanted to do with it. </li></ul><ul><li>When you got it home, you realized it wasn’t compatible with your existing printer and scanner. </li></ul><ul><li>Furthermore, it wasn’t equipped for broadband internet access and you had been hoping to switch to broadband. </li></ul><ul><li>By the time you spend the money and buy the parts to equip the computer to do what you want it to do, you find that you could have bought a leading-edge computer for less money. </li></ul>

44. PLANNING SYSTEMS DEVELOPMENT <ul><li>Systems development planning is an important step for the following key reasons: </li></ul><ul><ul><li>Consistency with the organization’s strategic plan. </li></ul></ul><ul><ul><li>Efficiency achieved through coordination of the subsystems. </li></ul></ul><ul><ul><li>Cutting edge technology and techniques. </li></ul></ul><ul><ul><li>Lower costs due to lack of duplication, wasted effort, time overruns, and cost overruns. </li></ul></ul><ul><ul><li>Adaptability for future changes. </li></ul></ul>

45. PLANNING SYSTEMS DEVELOPMENT <ul><li>When a system is poorly planned, a company must often return to a prior phase and correct errors and design flaws. </li></ul><ul><li>These returns are costly and result in delays, frustration, and low morale. </li></ul>

46. PLANNING SYSTEMS DEVELOPMENT <ul><li>Two types of systems development plans are needed: </li></ul><ul><ul><li>Individual project plans developed by the project teams. </li></ul></ul><ul><ul><li>A master plan developed by the IS steering committee. </li></ul></ul>

48. PLANNING SYSTEMS DEVELOPMENT <ul><li>Individual project plans contain: </li></ul><ul><ul><li>A cost-benefit analysis. </li></ul></ul><ul><ul><li>Developmental and operational requirements, including: </li></ul></ul><ul><ul><ul><li>Human resources </li></ul></ul></ul><ul><ul><ul><li>Hardware </li></ul></ul></ul><ul><ul><ul><li>Software </li></ul></ul></ul><ul><ul><ul><li>Financial resources </li></ul></ul></ul><ul><ul><li>A schedule of activities to develop and operate the new application </li></ul></ul>

50. PLANNING SYSTEMS DEVELOPMENT <ul><li>A master plan specifies: </li></ul><ul><ul><li>What the system will consist of </li></ul></ul><ul><ul><li>How it will be developed </li></ul></ul><ul><ul><li>Who will develop it </li></ul></ul><ul><ul><li>How needed resources will be acquired </li></ul></ul><ul><ul><li>Where the AIS is headed </li></ul></ul><ul><li>It also provides: </li></ul><ul><ul><li>Status of projects in process </li></ul></ul><ul><ul><li>Prioritization of planned projects and criteria for establishing priorities </li></ul></ul><ul><ul><li>Timetables for development </li></ul></ul>

51. PLANNING SYSTEMS DEVELOPMENT <ul><li>Projects with highest priority are first to be developed. </li></ul><ul><ul><li>These decisions are made by top management. </li></ul></ul><ul><li>Planning horizon: </li></ul><ul><ul><li>About a 3-year horizon </li></ul></ul><ul><ul><li>With updates at least 2-3 times/year—even more frequently in some companies. </li></ul></ul><ul><li>The CIO should determine: </li></ul><ul><ul><li>How soon technologies will be in wide use </li></ul></ul><ul><ul><li>Whether the company should adopt late or early </li></ul></ul><ul><ul><li>What business opportunities might arise from new technologies </li></ul></ul>

52. PLANNING SYSTEMS DEVELOPMENT <ul><li>Planning Techniques </li></ul><ul><ul><li>Two techniques for scheduling and monitoring systems development activities are: </li></ul></ul><ul><ul><ul><li>Program Evaluation and Review Technique (PERT) </li></ul></ul></ul><ul><ul><ul><li>Gantt Charts </li></ul></ul></ul>

53. PLANNING SYSTEMS DEVELOPMENT <ul><li>Planning Techniques </li></ul><ul><ul><li>Two techniques for scheduling and monitor systems development activities are: </li></ul></ul><ul><ul><ul><li>Program Evaluation and Review Technique (PERT) </li></ul></ul></ul><ul><ul><ul><li>Gantt Charts </li></ul></ul></ul>

54. PLANNING SYSTEMS DEVELOPMENT <ul><li>A PERT diagram requires that all activities in a project be identified along with the activities that precede and follow them. </li></ul><ul><li>These activities are used to draw a PERT diagram, which consists of a network of: </li></ul><ul><ul><li>Arrows—representing activities that require time and resources. </li></ul></ul><ul><ul><li>Nodes—representing completion and initiation of activities. </li></ul></ul>

55. PLANNING SYSTEMS DEVELOPMENT <ul><li>The critical path in a PERT diagram is the path requiring the greatest amount of time. </li></ul><ul><li>If an activity on the critical path is delayed, the whole project is delayed. </li></ul><ul><li>Resources may be shifted to the critical path to reduce the delay. </li></ul>

56. <ul><li>SAMPLE PERT CHART </li></ul><ul><ul><li>For building and selling a birdhouse. </li></ul></ul><ul><ul><li>Each block contains a task and a time estimate (may include best time, worst time, and average time) </li></ul></ul><ul><ul><li>May indicate who will be responsible for the task. </li></ul></ul>Design Birdhouse (2) (Bill) Buy Wood & Nails (1) (Bill) Buy Paint (1) (Sara) Build Base (2) (Bill) Build Roof (1) (Bill) Nail Together (2) (Bill) Paint & Decorate (3) (Sara) Sell (2) (Sara)

57. PLANNING SYSTEMS DEVELOPMENT <ul><li>Planning Techniques </li></ul><ul><ul><li>Two techniques for scheduling and monitor systems development activities are: </li></ul></ul><ul><ul><ul><li>Program Evaluation and Review Technique (PERT) </li></ul></ul></ul><ul><ul><ul><li>Gantt Charts </li></ul></ul></ul>

58. PLANNING SYSTEMS DEVELOPMENT <ul><li>A Gantt chart is a bar chart with project activities on the left and time across the top. </li></ul><ul><li>For each activity, a bar of expected time is drawn. </li></ul><ul><li>As activities are completed, the bar is filled in. </li></ul><ul><li>The Gantt chart makes it easy to eyeball the chart and understand the current status of a project. </li></ul><ul><li>But the chart does not show the relationship between activities like the PERT chart does. </li></ul>

59. <ul><li>SAMPLE GANTT CHART </li></ul>Complete Testing In Development Milestone

60. FEASIBILITY ANALYSIS <ul><li>During the systems analysis phase, a feasibility study (aka, a business case ) is prepared and is updated during the remaining steps in the SDLC. </li></ul><ul><li>The extent of the feasibility study depends on the size and nature of the system. </li></ul><ul><li>Feasibility team should include: </li></ul><ul><ul><li>Management </li></ul></ul><ul><ul><li>Accountants skilled in controls and auditing </li></ul></ul><ul><ul><li>Systems personnel </li></ul></ul><ul><ul><li>Users </li></ul></ul>

61. FEASIBILITY ANALYSIS <ul><li>The feasibility study and its updates are used by the steering committee as the project proceeds to decide whether to: </li></ul><ul><ul><li>Terminate the project </li></ul></ul><ul><ul><li>Proceed </li></ul></ul><ul><ul><li>Proceed if specific problems are resolved </li></ul></ul>

62. FEASIBILITY ANALYSIS <ul><li>Five aspects need to be considered during a feasibility study: </li></ul><ul><ul><li>Technical feasibility </li></ul></ul><ul><ul><ul><li>Is the technology there to do it? </li></ul></ul></ul><ul><ul><li>Operational feasibility </li></ul></ul><ul><ul><ul><li>Do we have people who can do it, and will it get used? </li></ul></ul></ul><ul><ul><li>Legal feasibility </li></ul></ul><ul><ul><ul><li>Does it comply with legal, regulatory, and contractual obligations? </li></ul></ul></ul><ul><ul><li>Scheduling feasibility </li></ul></ul><ul><ul><ul><li>Can it be done in time? </li></ul></ul></ul><ul><ul><li>Economic feasibility </li></ul></ul><ul><ul><ul><li>Will the benefits exceed the costs? </li></ul></ul></ul>

63. FEASIBILITY ANALYSIS <ul><li>Calculating Economic Feasibility Costs and Benefits </li></ul><ul><ul><li>Economic feasibility is probably the most important and frequently analyzed aspect. </li></ul></ul><ul><ul><li>This examination requires a careful investigation of costs and benefits. </li></ul></ul><ul><ul><li>It typically uses a capital budgeting model that considers: </li></ul></ul><ul><ul><ul><li>Cost savings and other benefits </li></ul></ul></ul><ul><ul><ul><li>Initial outlay costs </li></ul></ul></ul><ul><ul><ul><li>Operating costs </li></ul></ul></ul><ul><ul><ul><li>Other costs </li></ul></ul></ul>

64. FEASIBILITY ANALYSIS <ul><li>When possible, benefits and costs should be estimated and included even if they are not easily quantifiable. </li></ul><ul><li>If some costs and benefits cannot be accurately estimated, they should at least be listed, along with the likelihood of their occurrence and their expected impact. </li></ul>

65. FEASIBILITY ANALYSIS <ul><li>Benefits might include: </li></ul><ul><ul><li>Cost savings. </li></ul></ul><ul><ul><li>Improved customer service, productivity, decision making, or data processing. </li></ul></ul><ul><ul><li>Better management control. </li></ul></ul><ul><ul><li>Increased job satisfaction and employee morale. </li></ul></ul>

66. FEASIBILITY ANALYSIS <ul><li>Costs might include: </li></ul><ul><ul><li>Equipment costs </li></ul></ul><ul><ul><ul><li>Initial outlay plus ongoing operating costs </li></ul></ul></ul><ul><ul><li>Software costs </li></ul></ul><ul><ul><ul><li>Costs of acquiring, maintaining, supporting, and operating </li></ul></ul></ul><ul><ul><li>Human resource costs </li></ul></ul><ul><ul><ul><li>Salaries, as well as costs of hiring, training, and relocating staff </li></ul></ul></ul><ul><ul><li>Site preparation costs </li></ul></ul><ul><ul><li>Installation and conversion costs </li></ul></ul><ul><ul><li>Supplies </li></ul></ul><ul><ul><li>Overhead </li></ul></ul><ul><ul><li>Financial charges </li></ul></ul><ul><li>The primary operating cost is maintaining the system. </li></ul><ul><ul><ul><li>Makes up 65-75% of the organization’s system efforts </li></ul></ul></ul>

67. FEASIBILITY ANALYSIS <ul><li>Capital Budgeting </li></ul><ul><ul><li>Most organizations use a capital budgeting return on investment technique to evaluate the economic merits of different system alternatives. </li></ul></ul><ul><ul><li>There are three commonly used techniques </li></ul></ul><ul><ul><ul><li>Payback period </li></ul></ul></ul><ul><li>Calculates the number of years before the new savings from the project equal the initial cost of the investment. </li></ul><ul><li>Select projects with shorter payback periods. </li></ul>

68. FEASIBILITY ANALYSIS <ul><li>Capital Budgeting </li></ul><ul><ul><li>Most organizations use a capital budgeting return on investment technique to evaluate the economic merits of different system alternatives. </li></ul></ul><ul><ul><li>There are three commonly used techniques </li></ul></ul><ul><ul><ul><li>Payback period </li></ul></ul></ul><ul><ul><ul><li>Net present value (NPV) </li></ul></ul></ul><ul><li>Calculates and sums the discounted future cash flows of the costs and benefits. </li></ul><ul><li>Select projects with higher positive NPV. </li></ul>

69. FEASIBILITY ANALYSIS <ul><li>Capital Budgeting </li></ul><ul><ul><li>Most organizations use a capital budgeting return on investment technique to evaluate the economic merits of different system alternatives. </li></ul></ul><ul><ul><li>There are three commonly used techniques </li></ul></ul><ul><ul><ul><li>Payback period </li></ul></ul></ul><ul><ul><ul><li>Net present value (NPV) </li></ul></ul></ul><ul><ul><ul><li>Internal rate of return (IRR) </li></ul></ul></ul><ul><li>Calculates the effective interest rate that would result in a net present value of zero for the project. </li></ul><ul><li>Select projects with higher IRRs. </li></ul>

70. BEHAVIORAL ASPECTS OF CHANGE <ul><li>The best system will fail without the support of the people it serves. </li></ul><ul><li>So the behavioral aspects of change are crucial. </li></ul><ul><li>You need to be aware of and sensitive to the types of behavioral problems that can result from change. </li></ul>

71. BEHAVIORAL ASPECTS OF CHANGE <ul><li>Why Behavioral Problems Occur </li></ul><ul><ul><li>Employees will tend to view change as good if they believe it will affect them positively and vice versa. </li></ul></ul>

72. BEHAVIORAL ASPECTS OF CHANGE <ul><li>To minimize adverse behavioral reactions, it helps to understand why resistance occurs: </li></ul><ul><ul><li>Personal characteristics and background </li></ul></ul><ul><li>Employees are more likely to accept change if they are: </li></ul><ul><ul><li>Young; </li></ul></ul><ul><ul><li>Highly educated; or </li></ul></ul><ul><ul><li>Comfortable with technology. </li></ul></ul>

73. BEHAVIORAL ASPECTS OF CHANGE <ul><li>To minimize adverse behavioral reactions, it helps to understand why resistance occurs: </li></ul><ul><ul><li>Personal characteristics and background </li></ul></ul><ul><ul><li>Manner in which change is introduced </li></ul></ul><ul><li>The rationale used to sell the system may need to vary with the job responsibilities of the employees involved. </li></ul>

74. BEHAVIORAL ASPECTS OF CHANGE <ul><li>To minimize adverse behavioral reactions, it helps to understand why resistance occurs: </li></ul><ul><ul><li>Personal characteristics and background </li></ul></ul><ul><ul><li>Manner in which change is introduced </li></ul></ul><ul><ul><li>Experience with prior changes </li></ul></ul><ul><li>Fool me once, shame on me . . . </li></ul><ul><li>Let’s see if I even give you a second chance. </li></ul>

75. BEHAVIORAL ASPECTS OF CHANGE <ul><li>To minimize adverse behavioral reactions, it helps to understand why resistance occurs: </li></ul><ul><ul><li>Personal characteristics and background </li></ul></ul><ul><ul><li>Manner in which change is introduced </li></ul></ul><ul><ul><li>Experience with prior changes </li></ul></ul><ul><ul><li>Top management support </li></ul></ul>

76. BEHAVIORAL ASPECTS OF CHANGE <ul><li>To minimize adverse behavioral reactions, it helps to understand why resistance occurs: </li></ul><ul><ul><li>Personal characteristics and background </li></ul></ul><ul><ul><li>Manner in which change is introduced </li></ul></ul><ul><ul><li>Experience with prior changes </li></ul></ul><ul><ul><li>Top management support </li></ul></ul><ul><ul><li>Communication </li></ul></ul>

77. BEHAVIORAL ASPECTS OF CHANGE <ul><li>To minimize adverse behavioral reactions, it helps to understand why resistance occurs: </li></ul><ul><ul><li>Personal characteristics and background </li></ul></ul><ul><ul><li>Manner in which change is introduced </li></ul></ul><ul><ul><li>Experience with prior changes </li></ul></ul><ul><ul><li>Top management support </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Biases and natural resistance to change </li></ul></ul><ul><li>Employees may be too emotionally attached to their duties, i.e., “sacred cows.” </li></ul>

78. BEHAVIORAL ASPECTS OF CHANGE <ul><li>To minimize adverse behavioral reactions, it helps to understand why resistance occurs: </li></ul><ul><ul><li>Personal characteristics and background </li></ul></ul><ul><ul><li>Manner in which change is introduced </li></ul></ul><ul><ul><li>Experience with prior changes </li></ul></ul><ul><ul><li>Top management support </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Biases and natural resistance to change </li></ul></ul><ul><ul><li>Disruptive nature of the change process </li></ul></ul><ul><li>Disturbances often create negative feelings. </li></ul>

79. BEHAVIORAL ASPECTS OF CHANGE <ul><li>To minimize adverse behavioral reactions, it helps to understand why resistance occurs: </li></ul><ul><ul><li>Personal characteristics and background </li></ul></ul><ul><ul><li>Manner in which change is introduced </li></ul></ul><ul><ul><li>Experience with prior changes </li></ul></ul><ul><ul><li>Top management support </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Biases and natural resistance to change </li></ul></ul><ul><ul><li>Disruptive nature of the change process </li></ul></ul><ul><ul><li>Fear </li></ul></ul><ul><li>May include fear of: </li></ul><ul><ul><li>The unknown </li></ul></ul><ul><ul><li>Failure </li></ul></ul><ul><ul><li>Technology </li></ul></ul><ul><ul><li>Losing respect or status </li></ul></ul><ul><ul><li>Losing their jobs </li></ul></ul>

80. BEHAVIORAL ASPECTS OF CHANGE <ul><li>How People Resist AIS Changes </li></ul><ul><ul><li>Resistance to change often takes one of three forms: </li></ul></ul><ul><ul><ul><li>Aggression </li></ul></ul></ul><ul><li>Behavior intended to destroy, cripple, or weaken the system’s effectiveness. </li></ul><ul><li>Examples: Increased error rates, disruptions, or deliberate sabotage. </li></ul>

81. BEHAVIORAL ASPECTS OF CHANGE <ul><li>How People Resist AIS Changes </li></ul><ul><ul><li>Resistance to change often takes one of three forms: </li></ul></ul><ul><ul><ul><li>Aggression </li></ul></ul></ul><ul><ul><ul><li>Projection </li></ul></ul></ul><ul><li>Blaming the new system for any and every unpleasant occurrence, i.e., the system becomes a scapegoat. </li></ul><ul><li>To preserve the integrity of the system, these criticisms must be controlled or answered. </li></ul>

82. BEHAVIORAL ASPECTS OF CHANGE <ul><li>How People Resist AIS Changes </li></ul><ul><ul><li>Resistance to change often takes one of three forms: </li></ul></ul><ul><ul><ul><li>Aggression </li></ul></ul></ul><ul><ul><ul><li>Projection </li></ul></ul></ul><ul><ul><ul><li>Avoidance </li></ul></ul></ul><ul><li>“ If I don’t use this thing, maybe it will go away!” </li></ul>

83. FEASIBILITY ANALYSIS <ul><li>Reactions to change can be improved by observing the following guidelines: </li></ul><ul><ul><li>Meet user’s needs with respect to the form, content, and volume of system output. </li></ul></ul><ul><ul><li>Keep communication lines open. Managers and users should be fully informed about: </li></ul></ul><ul><ul><ul><li>What changes are being made </li></ul></ul></ul><ul><ul><ul><li>Why </li></ul></ul></ul><ul><ul><ul><li>How it will benefit them </li></ul></ul></ul><ul><ul><ul><li>Who to contact with questions </li></ul></ul></ul>

84. FEASIBILITY ANALYSIS <ul><ul><li>Maintain a safe and open atmosphere. </li></ul></ul><ul><ul><ul><li>If employees become hostile, it’s an uphill battle you probably won’t win. </li></ul></ul></ul><ul><ul><li>Obtain management support. </li></ul></ul><ul><ul><li>Allay fears. </li></ul></ul><ul><ul><ul><li>To the extent possible, reassure employees that no major job losses or responsibility shifts will occur. </li></ul></ul></ul><ul><ul><ul><li>If employees are terminated, severance pay and outplacement services should be provided. </li></ul></ul></ul>

85. FEASIBILITY ANALYSIS <ul><ul><li>Solicit user participation. </li></ul></ul><ul><ul><ul><li>It is ego enhancing, challenging, and intrinsically satisfying. </li></ul></ul></ul><ul><ul><ul><li>Users who participate will be more committed to using the system. </li></ul></ul></ul><ul><ul><li>Provide honest feedback. </li></ul></ul><ul><ul><ul><li>Explain which suggestions are and are not being used and why. </li></ul></ul></ul><ul><ul><li>Make sure users understand the system. </li></ul></ul><ul><ul><ul><li>Don’t underestimate training needs. </li></ul></ul></ul>

86. FEASIBILITY ANALYSIS <ul><ul><li>Humanize the system. </li></ul></ul><ul><ul><ul><li>Employees shouldn’t feel the computer is controlling them or has usurped their positions. </li></ul></ul></ul><ul><ul><li>Describe new challenges and opportunities. </li></ul></ul><ul><ul><ul><li>The system can provide greater job satisfaction and increased opportunities. </li></ul></ul></ul><ul><ul><li>Reexamine performance evaluation. </li></ul></ul><ul><ul><ul><li>Are performance standards and criteria realistic in light of the change? </li></ul></ul></ul><ul><ul><li>Test the system’s integrity. </li></ul></ul><ul><ul><ul><li>It’ important to minimize bad impressions </li></ul></ul></ul>

87. FEASIBILITY ANALYSIS <ul><ul><li>Avoid emotionalism. </li></ul></ul><ul><ul><ul><li>Emotional issues should be allowed to cool, handled in a non-confrontational manner, or sidestepped. </li></ul></ul></ul><ul><ul><li>Present the system in the proper context. </li></ul></ul><ul><ul><ul><li>Address the concerns of the people to whom you’re speaking, not the concerns of management or developers. </li></ul></ul></ul><ul><ul><li>Control the user’s expectations </li></ul></ul><ul><ul><ul><li>Don’t oversell, and be realistic. </li></ul></ul></ul><ul><ul><li>Keep the system simple </li></ul></ul><ul><ul><ul><li>Avoid complex systems that cause radical changes. </li></ul></ul></ul>

88. FEASIBILITY ANALYSIS <ul><li>Ignoring the preceding steps can leave to behavior issues that are difficult or impossible to reverse. </li></ul>

89. SYSTEMS ANALYSIS <ul><li>When a new or improved system is needed, a written request for systems development is prepared. That request describes: </li></ul><ul><ul><li>The current system’s problems </li></ul></ul><ul><ul><li>The reasons for the proposed changes </li></ul></ul><ul><ul><li>The goals and objectives of a proposed system </li></ul></ul><ul><ul><li>The anticipated benefits and costs </li></ul></ul>

90. SYSTEMS ANALYSIS <ul><li>The project development team will conduct the systems analysis in five steps: </li></ul><ul><ul><li>Initial investigation </li></ul></ul><ul><ul><li>Systems survey </li></ul></ul><ul><ul><li>Feasibility study </li></ul></ul><ul><ul><li>Information needs and systems requirements </li></ul></ul><ul><ul><li>Systems analysis report </li></ul></ul>

91. SYSTEMS ANALYSIS <ul><li>The project development team will conduct the systems analysis in five steps </li></ul><ul><ul><li>Initial investigation </li></ul></ul><ul><ul><li>Systems survey </li></ul></ul><ul><ul><li>Feasibility study </li></ul></ul><ul><ul><li>Information needs and systems requirements </li></ul></ul><ul><ul><li>Systems analysis report </li></ul></ul>

92. SYSTEMS ANALYSIS <ul><li>The initial investigation is conducted to: </li></ul><ul><ul><li>Gain a clear picture of the problem or need. </li></ul></ul><ul><li>Sometimes what is thought to be the cause of the problem is not the real source. </li></ul>

93. SYSTEMS ANALYSIS <ul><li>The initial investigation is conducted to: </li></ul><ul><ul><li>Gain a clear picture of the problem or need. </li></ul></ul><ul><ul><li>Determine the viability of the project and expected costs and payoffs. </li></ul></ul>

94. SYSTEMS ANALYSIS <ul><li>The initial investigation is conducted to: </li></ul><ul><ul><li>Gain a clear picture of the problem or need. </li></ul></ul><ul><ul><li>Determine the viability of the project and expected costs and payoffs. </li></ul></ul><ul><ul><li>Evaluate the scope and nature of the new AIS. </li></ul></ul><ul><li>A new AIS is useful when problems are a result of: </li></ul><ul><ul><li>Lack of information </li></ul></ul><ul><ul><li>Inaccessibility of data </li></ul></ul><ul><ul><li>Inefficient data processing </li></ul></ul><ul><li>A new AIS will not answer problems such as: </li></ul><ul><ul><li>A manager who has too many subordinates </li></ul></ul><ul><ul><li>A manager who lacks organizational skills </li></ul></ul><ul><ul><li>Failure to enforce existing problems </li></ul></ul>

95. SYSTEMS ANALYSIS <ul><li>The initial investigation is conducted to: </li></ul><ul><ul><li>Gain a clear picture of the problem or need. </li></ul></ul><ul><ul><li>Determine the viability of the project and expected costs and payoffs. </li></ul></ul><ul><ul><li>Evaluate the scope and nature of the new AIS. </li></ul></ul><ul><ul><li>Recommend whether to proceed. </li></ul></ul><ul><li>Either: </li></ul><ul><ul><li>Initiate the project as proposed. </li></ul></ul><ul><ul><li>Modify it. </li></ul></ul><ul><ul><li>Abandon it. </li></ul></ul>

96. SYSTEMS ANALYSIS <ul><li>If the project is approved: </li></ul><ul><ul><li>A proposal to conduct systems analysis is prepared. </li></ul></ul><ul><ul><li>The project is assigned a priority and added to the master plan. </li></ul></ul><ul><ul><li>The development team begins a survey of the existing AIS. </li></ul></ul><ul><ul><li>The proposal will be modified as more information becomes available. </li></ul></ul>

98. SYSTEMS ANALYSIS <ul><li>A systems survey involves an extensive study of the current AIS which could take weeks or months. Objectives are: </li></ul><ul><ul><li>Gain a thorough understanding of: </li></ul></ul><ul><ul><ul><li>Company operations, policies, and procedures </li></ul></ul></ul><ul><ul><ul><li>Data and information flow </li></ul></ul></ul><ul><ul><ul><li>AIS strengths and weaknesses </li></ul></ul></ul><ul><ul><ul><li>Available hardware, software, and personnel </li></ul></ul></ul><ul><ul><li>Make preliminary assessments of current and future processing needs, and determine extent and nature of needed changes. </li></ul></ul><ul><ul><li>Develop working relationships with users and build support. </li></ul></ul><ul><ul><li>Collect data that identify user needs, conduct a feasibility analysis, and make recommendations to management. </li></ul></ul>

99. SYSTEMS ANALYSIS <ul><li>Data can be gathered from: </li></ul><ul><ul><li>Employees. </li></ul></ul><ul><ul><li>Documentation such as organization charts and procedure manuals. </li></ul></ul><ul><ul><li>External sources such as: </li></ul></ul><ul><ul><ul><li>Consultants </li></ul></ul></ul><ul><ul><ul><li>Customers </li></ul></ul></ul><ul><ul><ul><li>Suppliers </li></ul></ul></ul><ul><ul><ul><li>Industry associations </li></ul></ul></ul><ul><ul><ul><li>Government agencies </li></ul></ul></ul>

100. SYSTEMS ANALYSIS <ul><li>Four common methods of gathering data are: </li></ul><ul><ul><li>Interviews </li></ul></ul><ul><ul><li>Questionnaires </li></ul></ul><ul><ul><li>Observation </li></ul></ul><ul><ul><li>System Documentation </li></ul></ul>

102. SYSTEMS ANALYSIS <ul><li>Advantages of interviews: </li></ul><ul><ul><li>Can answer “why” questions </li></ul></ul><ul><ul><li>Can allow for follow-up and clarification </li></ul></ul><ul><ul><li>Provides opportunity to build positive relationships with interviewees and support for new system </li></ul></ul><ul><li>Disadvantages of interviews: </li></ul><ul><ul><li>Time-consuming </li></ul></ul><ul><ul><li>Expensive </li></ul></ul><ul><ul><li>Personal biases or self-interest may produce inaccurate information </li></ul></ul>

103. SYSTEMS ANALYSIS <ul><li>When you do interviews: </li></ul><ul><ul><li>Make an appointment. </li></ul></ul><ul><ul><li>Explain the purpose ahead of time. </li></ul></ul><ul><ul><li>Indicate the amount of time needed. </li></ul></ul><ul><ul><li>Be on time. </li></ul></ul><ul><ul><li>Be familiar with the interviewee’s responsibilities. </li></ul></ul><ul><ul><li>Make notes on points to cover. </li></ul></ul><ul><ul><li>Put the interviewee at ease and let him/her do the talking. </li></ul></ul><ul><ul><li>Pay attention to nonverbal cues. </li></ul></ul><ul><ul><li>Take notes and augment them with impressions after the interview. </li></ul></ul><ul><ul><li>Request permission to tape critical interviews. </li></ul></ul>

105. SYSTEMS ANALYSIS <ul><li>Questionnaires can be used when: </li></ul><ul><ul><li>The amount of information to be gathered is small and well defined. </li></ul></ul><ul><ul><li>The information is to be obtained from many people or from those who are remotely located. </li></ul></ul><ul><ul><li>The information is intended to verify data from other sources. </li></ul></ul>

106. SYSTEMS ANALYSIS <ul><li>Advantages of questionnaires: </li></ul><ul><ul><li>Can be anonymous. </li></ul></ul><ul><ul><li>Not time-consuming to complete. </li></ul></ul><ul><ul><li>Inexpensive. </li></ul></ul><ul><ul><li>Allows the subject time to think about responses. </li></ul></ul><ul><li>Disadvantages of questionnaires: </li></ul><ul><ul><li>Does not allow in-depth questions or answers. </li></ul></ul><ul><ul><li>Does not allow follow-up or clarification. </li></ul></ul><ul><ul><li>Does not build relationships. </li></ul></ul><ul><ul><li>Difficult to develop. </li></ul></ul><ul><ul><li>May be ignored or completed superficially. </li></ul></ul>

108. SYSTEMS ANALYSIS <ul><li>Advantages of observations: </li></ul><ul><ul><li>Can verify how the system actually works rather than how it should work. </li></ul></ul><ul><ul><li>Results in greater understanding of systems. </li></ul></ul><ul><li>Disadvantages of observations: </li></ul><ul><ul><li>Time-consuming. </li></ul></ul><ul><ul><li>Expensive. </li></ul></ul><ul><ul><li>Difficult to interpret. </li></ul></ul><ul><ul><li>People may alter behavior while being observed. </li></ul></ul>

109. SYSTEMS ANALYSIS <ul><li>When you do observations: </li></ul><ul><ul><li>Identify what is to be observed and estimate the time required. </li></ul></ul><ul><ul><li>Obtain permission. </li></ul></ul><ul><ul><li>Explain what will be done and why. </li></ul></ul><ul><ul><li>Don’t make value judgments. </li></ul></ul><ul><ul><li>Take notes and document impressions ASAP. </li></ul></ul>

111. SYSTEMS ANALYSIS <ul><li>Advantages of systems documentation: </li></ul><ul><ul><li>Describes how the system should work. </li></ul></ul><ul><ul><li>Written form facilitates review and analysis. </li></ul></ul><ul><li>Disadvantages of systems documentation: </li></ul><ul><ul><li>Time consuming. </li></ul></ul><ul><ul><li>May be elusive. </li></ul></ul><ul><li>When you examine systems documentation: </li></ul><ul><ul><li>Keep in mind that the system doesn’t always work as it should per the documentation. </li></ul></ul><ul><ul><li>If documentation is unavailable, it may be worthwhile to develop it. </li></ul></ul>

112. SYSTEMS ANALYSIS <ul><li>Once the data is gathered, document findings and model the existing system. </li></ul><ul><ul><li>Documentation consists of: </li></ul></ul><ul><ul><ul><li>Questionnaire copies </li></ul></ul></ul><ul><ul><ul><li>Interview notes </li></ul></ul></ul><ul><ul><ul><li>Memos </li></ul></ul></ul>

113. SYSTEMS ANALYSIS <ul><li>Another form of documentation is a system model: </li></ul><ul><ul><li>Physical models illustrate how a system functions by describing: </li></ul></ul><ul><ul><ul><li>Flow of documents. </li></ul></ul></ul><ul><ul><ul><li>Computer processes performed and the people doing them. </li></ul></ul></ul><ul><ul><ul><li>Equipment used. </li></ul></ul></ul><ul><ul><ul><li>Any other physical elements. </li></ul></ul></ul><ul><ul><li>Logical models illustrate what is being done regardless of how the flow is accomplished. </li></ul></ul>

114. SYSTEMS ANALYSIS <ul><li>When documentation is complete, analyze the existing system: </li></ul><ul><ul><li>Evaluate the AIS’s strengths and weaknesses to develop ideas for designing and structuring the new AIS. </li></ul></ul><ul><ul><ul><li>Try to retain strengths. </li></ul></ul></ul><ul><ul><ul><li>Correct weaknesses. </li></ul></ul></ul><ul><ul><li>Sometimes, you need revolutionary, rather than evolutionary change. </li></ul></ul><ul><ul><ul><li>Called re-engineering . </li></ul></ul></ul>

115. SYSTEMS ANALYSIS <ul><li>At the end of this phase, prepare systems survey report: </li></ul><ul><ul><li>Outlines and documents the data gathered. </li></ul></ul><ul><ul><li>Provides recommendations that result from the systems survey. </li></ul></ul>

117. SYSTEMS ANALYSIS <ul><li>After the systems survey, a more thorough feasibility analysis is conducted. </li></ul><ul><li>This analysis is updated regularly as the project proceeds and costs and benefits become clearer. </li></ul>

119. SYSTEMS ANALYSIS <ul><li>Once a project clears the feasibility hurdle, the company identifies the information needs of AIS users and documents systems processes, including: </li></ul><ul><ul><li>Processes </li></ul></ul><ul><li>Describes what is to be done and by whom. </li></ul>

120. SYSTEMS ANALYSIS <ul><li>Once a project clears the feasibility hurdle, the company identifies the information needs of AIS users and documents systems processes, including: </li></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Data elements </li></ul></ul><ul><li>Describes name, size, format, source, and significance of necessary data elements. </li></ul>

121. SYSTEMS ANALYSIS <ul><li>Once a project clears the feasibility hurdle, the company identifies the information needs of AIS users and documents systems processes, including: </li></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Data elements </li></ul></ul><ul><ul><li>Data structure </li></ul></ul><ul><li>A preliminary structure showing how the data elements will be organized into logical records. </li></ul>

122. SYSTEMS ANALYSIS <ul><li>Once a project clears the feasibility hurdle, the company identifies the information needs of AIS users and documents systems processes, including: </li></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Data elements </li></ul></ul><ul><ul><li>Data structure </li></ul></ul><ul><ul><li>Outputs </li></ul></ul><ul><li>Layouts of system outputs and a description of their purpose, frequency, and distribution. </li></ul>

123. SYSTEMS ANALYSIS <ul><li>Once a project clears the feasibility hurdle, the company identifies the information needs of AIS users and documents systems processes, including: </li></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Data elements </li></ul></ul><ul><ul><li>Data structure </li></ul></ul><ul><ul><li>Outputs </li></ul></ul><ul><ul><li>Inputs </li></ul></ul><ul><li>A copy of system inputs and a description of their contents, source, and who is responsible for them. </li></ul>

124. SYSTEMS ANALYSIS <ul><li>Once a project clears the feasibility hurdle, the company identifies the information needs of AIS users and documents systems processes, including: </li></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Data elements </li></ul></ul><ul><ul><li>Data structure </li></ul></ul><ul><ul><li>Outputs </li></ul></ul><ul><ul><li>Inputs </li></ul></ul><ul><ul><li>Constraints </li></ul></ul><ul><li>A description of deadlines, schedules, security requirements, staffing limitations, and legal requirements. </li></ul>

125. SYSTEMS ANALYSIS <ul><li>Once a project clears the feasibility hurdle, the company identifies the information needs of AIS users and documents systems processes, including: </li></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Data elements </li></ul></ul><ul><ul><li>Data structure </li></ul></ul><ul><ul><li>Outputs </li></ul></ul><ul><ul><li>Inputs </li></ul></ul><ul><ul><li>Constraints </li></ul></ul><ul><ul><li>Controls </li></ul></ul><ul><li>Controls that are needed to ensure accuracy and reliability. </li></ul>

126. SYSTEMS ANALYSIS <ul><li>Once a project clears the feasibility hurdle, the company identifies the information needs of AIS users and documents systems processes, including: </li></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Data elements </li></ul></ul><ul><ul><li>Data structure </li></ul></ul><ul><ul><li>Outputs </li></ul></ul><ul><ul><li>Inputs </li></ul></ul><ul><ul><li>Documentation constraints </li></ul></ul><ul><ul><li>Controls </li></ul></ul><ul><ul><li>Reorganizations </li></ul></ul><ul><li>Changes in staffing, job functions, etc., that would be necessary. </li></ul>

127. SYSTEMS ANALYSIS <ul><li>Issues: </li></ul><ul><ul><li>There is much to be specified, even for a simple AIS. </li></ul></ul><ul><ul><li>It may be difficult to get employees to accurately articulate their needs. </li></ul></ul><ul><ul><li>Errors are best caught early, as the cost to correct them increases significantly the farther you are into the project. </li></ul></ul>

128. SYSTEMS ANALYSIS <ul><li>Systems Objectives and Constraints </li></ul><ul><ul><li>Many entities take a systems approach to determining information needs and systems requirements. </li></ul></ul><ul><ul><li>Problems and alternatives are viewed from the standpoint of the entire organization—as opposed to a single department. </li></ul></ul>

129. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><li>Able to help users make decisions. </li></ul>

130. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><li>Benefits exceed costs. </li></ul>

131. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><li>Data is processed accurately and reliably. </li></ul>

132. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><li>You can access it when you need it. </li></ul>

133. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Timeliness </li></ul></ul><ul><li>More critical information is provided first. </li></ul>

134. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Timeliness </li></ul></ul><ul><ul><li>Customer service </li></ul></ul><ul><li>Efficient and courteous. </li></ul>

135. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Timeliness </li></ul></ul><ul><ul><li>Customer service </li></ul></ul><ul><ul><li>Capacity </li></ul></ul><ul><li>Can handle peak periods. </li></ul>

136. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Timeliness </li></ul></ul><ul><ul><li>Customer service </li></ul></ul><ul><ul><li>Capacity </li></ul></ul><ul><ul><li>Ease of use </li></ul></ul>

137. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Timeliness </li></ul></ul><ul><ul><li>Customer service </li></ul></ul><ul><ul><li>Capacity </li></ul></ul><ul><ul><li>Ease of use </li></ul></ul><ul><ul><li>Flexibility </li></ul></ul><ul><li>Can accommodate changes. </li></ul>

138. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Timeliness </li></ul></ul><ul><ul><li>Customer service </li></ul></ul><ul><ul><li>Capacity </li></ul></ul><ul><ul><li>Ease of use </li></ul></ul><ul><ul><li>Flexibility </li></ul></ul><ul><ul><li>Tractability </li></ul></ul><ul><li>Easily understood. </li></ul><ul><li>Facilitates problem solving and future development. </li></ul>

139. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Timeliness </li></ul></ul><ul><ul><li>Customer service </li></ul></ul><ul><ul><li>Capacity </li></ul></ul><ul><ul><li>Ease of use </li></ul></ul><ul><ul><li>Flexibility </li></ul></ul><ul><ul><li>Tractability </li></ul></ul><ul><ul><li>Auditability </li></ul></ul>

140. SYSTEMS ANALYSIS <ul><li>Systems objectives must be identified, so analysts and users can focus on those elements most vital to success of the AIS. These may include: </li></ul><ul><ul><li>Usefulness </li></ul></ul><ul><ul><li>Economy </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Timeliness </li></ul></ul><ul><ul><li>Customer service </li></ul></ul><ul><ul><li>Capacity </li></ul></ul><ul><ul><li>Ease of use </li></ul></ul><ul><ul><li>Flexibility </li></ul></ul><ul><ul><li>Tractability </li></ul></ul><ul><ul><li>Auditability </li></ul></ul><ul><ul><li>Security </li></ul></ul><ul><li>Available only to authorized users. </li></ul>

141. SYSTEMS ANALYSIS <ul><li>There are often trade-offs between objectives. </li></ul><ul><li>Organizational constraints make it impossible to develop all parts of an AIS simultaneously. </li></ul><ul><ul><li>You divide it into modules that are analyzed, developed, and installed independently. </li></ul></ul><ul><ul><li>When changes are made, only the affected modules need to be changed. </li></ul></ul><ul><ul><li>The modules should be properly integrated into a workable system. </li></ul></ul>

142. SYSTEMS ANALYSIS <ul><li>Success often depends on the project team’s ability to cope with organizational constraints, including: </li></ul><ul><ul><li>Requirements of governmental agencies. </li></ul></ul><ul><ul><li>Managerial policies and guidelines. </li></ul></ul><ul><ul><li>Lack of sufficient, qualified staff. </li></ul></ul><ul><ul><li>Capabilities and attitudes of users. </li></ul></ul><ul><ul><li>Available technology. </li></ul></ul><ul><ul><li>Limited financial resources. </li></ul></ul>

143. SYSTEMS ANALYSIS <ul><li>Strategies for Determining Requirements: </li></ul><ul><ul><li>One or more of the following four strategies are used to determine AIS requirements: </li></ul></ul><ul><ul><ul><li>Ask users what they need </li></ul></ul></ul><ul><li>This is the simplest and fastest strategy. </li></ul><ul><li>But many people don’t realize or understand their true needs. </li></ul><ul><li>It’s sometimes better to ask them what decisions they make and what processes they are involved in. </li></ul><ul><li>Users also need to think beyond their current information needs. </li></ul>

144. SYSTEMS ANALYSIS <ul><li>Strategies for Determining Requirements: </li></ul><ul><ul><li>One or more of the following four strategies are used to determine AIS requirements: </li></ul></ul><ul><ul><ul><li>Ask users what they need </li></ul></ul></ul><ul><ul><ul><li>Analyze existing systems </li></ul></ul></ul><ul><li>Internal and external systems should be analyzed to avoid reinventing the wheel. </li></ul>

145. SYSTEMS ANALYSIS <ul><li>Strategies for Determining Requirements: </li></ul><ul><ul><li>One or more of the following four strategies are used to determine AIS requirements: </li></ul></ul><ul><ul><ul><li>Ask users what they need </li></ul></ul></ul><ul><ul><ul><li>Analyze existing systems </li></ul></ul></ul><ul><ul><ul><li>Examine existing system use </li></ul></ul></ul><ul><li>Certain modules: </li></ul><ul><ul><li>May not be used as intended </li></ul></ul><ul><ul><li>May be augmented by manual tasks </li></ul></ul><ul><ul><li>May be avoided altogether </li></ul></ul><ul><li>Helps determine whether the system really needs to be simply modified rather than replaced. </li></ul>

146. SYSTEMS ANALYSIS <ul><li>Strategies for Determining Requirements: </li></ul><ul><ul><li>One or more of the following four strategies are used to determine AIS requirements: </li></ul></ul><ul><ul><ul><li>Ask users what they need </li></ul></ul></ul><ul><ul><ul><li>Analyze existing systems </li></ul></ul></ul><ul><ul><ul><li>Examine existing system use </li></ul></ul></ul><ul><ul><ul><li>Create a prototype </li></ul></ul></ul><ul><li>Entails roughing out a system for users to critique. </li></ul><ul><li>When they see something on a screen, it’s easier to identify what they like and don’t like. </li></ul><ul><li>Goes through iterations of improving and reviewing with users until users agree on their needs. </li></ul>

147. SYSTEMS ANALYSIS <ul><li>Documentation and Approval of User Requirements: </li></ul><ul><ul><li>Detailed requirements for the new AIS should be created and documented. </li></ul></ul><ul><ul><ul><li>How to produce the required features is determined during the design phases of the SDLC. </li></ul></ul></ul><ul><ul><ul><li>The requirements list should be supported by sample input and output forms and charts that make it easier to conceptualize. </li></ul></ul></ul><ul><ul><ul><li>A nontechnical summary is often prepared for management. </li></ul></ul></ul>

148. SYSTEMS ANALYSIS <ul><li>Once user requirements have been determined and documented, the project team: </li></ul><ul><ul><li>Meets with users. </li></ul></ul><ul><ul><li>Explains the requirements. </li></ul></ul><ul><ul><li>Obtains their agreement and approval. </li></ul></ul><ul><li>When an agreement is reached, user management should sign off on the requirements. </li></ul>

150. SYSTEMS ANALYSIS <ul><li>The last step in systems analysis is the systems analysis report. </li></ul><ul><ul><li>Summarizes and documents the activities. </li></ul></ul><ul><ul><li>Serves as a repository of data from which designers can draw. </li></ul></ul><ul><ul><li>Outlines: </li></ul></ul><ul><ul><ul><li>Goals and objectives of the new system. </li></ul></ul></ul><ul><ul><ul><li>Scope of the project. </li></ul></ul></ul><ul><ul><ul><li>How the new system fits into the company’s master plan. </li></ul></ul></ul><ul><ul><ul><li>User processing requirements and information needs. </li></ul></ul></ul><ul><ul><ul><li>Feasibility analysis. </li></ul></ul></ul><ul><ul><ul><li>Recommendations for the new system. </li></ul></ul></ul>

151. SYSTEMS ANALYSIS <ul><li>A go-no-go decision is usually made three times during systems analysis: </li></ul><ul><ul><li>During the initial investigation to determine whether to go ahead with a systems survey. </li></ul></ul><ul><ul><li>At the end of the feasibility study to determine whether to proceed with the information requirements step. </li></ul></ul><ul><ul><li>At the completion of the analysis phase to decide whether to proceed to the next phase (conceptual design). </li></ul></ul>

152. SYSTEMS ANALYSIS <ul><li>When systems analysis is completed, the project can move on to: </li></ul><ul><ul><li>Conceptual design phase </li></ul></ul><ul><ul><li>Physical design phase </li></ul></ul><ul><ul><li>Implementation and conversion </li></ul></ul><ul><ul><li>Operation and maintenance </li></ul></ul>

153. SUMMARY <ul><li>You’ve learned about the five phases in the systems development life cycle, with a particular emphasis on systems analysis. </li></ul><ul><li>You’ve learned who the players are in the systems development process. </li></ul><ul><li>You’ve learned about various techniques that are used to plan the development of a system. </li></ul><ul><li>You’ve reviewed some techniques for determining system feasibility. </li></ul><ul><li>You’ve learned about behavioral responses to systems changes and how dysfunctional behavior can be minimized. </li></ul>

Ais Romney 2006 Slides 18 Introduction To Systems Development

Sharing Slides Training

Ais Romney 2006 Slides 18 Introduction To Systems Development