01 Bidgoli Chpt10 Systems Development Lifecycle

01 Bidgoli Chpt10 Systems Development Lifecycle - IS...

Info icon This preview shows pages 1–18. Sign up to view the full content.

View Full Document Right Arrow Icon
Image of page 1

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 2
Image of page 3

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 4
Image of page 5

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 6
Image of page 7

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 8
Image of page 9

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 10
Image of page 11

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 12
Image of page 13

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 14
Image of page 15

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 16
Image of page 17

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 18
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: IS Development, Enterprise Systems, M88 Part 3 Chapter ’I C) . end Emergir‘ng Tr'ends his chapter explains the systems de- velopment life cycle (SDLC), a model for developing a system or project. The cycle is usually divided into five phases, and you learn about the tasks involved in each phase. For example, in the first phase—planning—a feasibility study is typi— cally conducted, and the SDLC task force is formed. You also learn about two alternatives to the SDLC model: self-sourcing and outsourcing. Finally, you re- view new trends in systems analysis and design, such as rapid application development, extreme programming; and agile methodology. OUtCOFflSS Part 3: l5 Development. Enterprise Systems, M55. andEmerging Trends Development Life Cycle: An Overview n the information systems field, system failure can happen for several reasons—including missed deadlines, users” needs that weren’t met, dissatis- fied customers, lack of support from top management, and going over budget. Using a sound system development method can help overcome these potential failures in designing an information system. Designing a successful infor- mation system requires integrating people, software, and hardware. To achieve this integration, designers often follow the systems development life cycle (SDLC), also known as the “waterfall model.” It’s a [-3 series of well—defined phases performed in sequence that serve as a framework for developing a system or project. Exhibit 10.1 shows the phases of the SDLC, which are explained throughout this chapter. In this model, each phase’s output (results) becomes the input for the next phase. When following this model, keep in mind that the main goal of an information system is delivering useful information in a timely manner to the right decision maker. ,-:§¢:mw,w.:§nose;x;.~o§,wflc¥¥=’fmfi_fi> 2m .. flaw“; baggy: yifii'wwwya'g ugq'ggsfiea' m' . .. .__ H _ ,3.» a swag-swaggg-wafiga WW’5-§:&«fi‘¢*§;§§ik:§, VFfi-xfi‘ aas-aa.awew.y we; ext-aw.“ ' *-‘ 3‘ ~- w aSy temsdevelopment fife tygigfifl ah‘w-emuemwwwmaaex 4 “:x- . Iii Eilfiygaffflffilm‘gggfimfifigfifi péisgg (is: ' '- - - ~ 5 '39; - _ < . t _. . m afilfiéfiiflimigwefiififi £§¥§®Q smegma-9a '- wee-xa-fiweaa f“ as S's-a— {QEQJQ teerareaxemwe s: : - _ ~ 3 $5 ' ‘ Systems planning today is about evaluating all potential systems that need to be implemented. A pre- liminary analysis of requirements for each is done first, and a feasibility study is conducted for each system. Then the organization decides which ones are a “Go” and proceeds to the next phase. Information system projects are often an exten— sion of existing systems or involve replacing an old technology with a new one. However, sometimes an information system needs to be designed from scratch, and the SDLC model is particularly suitable in these sit— uations. For existing information systems, some phases might not be applicable, although the SDLC model can still be used. In addition, when designing information systems, projecting the organization’s growth rate is im— portant; otherwise, the system could become inefficient shortly after it’s designed. Phase ’1: Planning uring the planning phase, one of the most crucial phases of the SDLC model, the systems designer must understand and define the problem the organization faces, taking care not to define symp- toms rather than the underlying problem. The probieni can be identified internally or externally, such as from custom- ers or suppliers. For example, a problem identified internally might be management’s concern about the organization’s lack of a competitive edge in the market- place; a problem identified externally might be suppliers noting inefficiency in the inventory control procedure. After identifying the problem, an analyst or team of analysts assesses the current and future needs of the For: 3:13 Development, Enrerprfse Systems, M35, and Emerging Trends vs ,. f"¢'*fiaaaaas ©SupertrooperlShutterstock the following questions: 0 Why is this information system being developed? 0 Who are the system’s current and future users? 0 Is the system new or an upgrade or extension of an existing system? ' Which functional areas (departments) will be using the system? As part of this assessment, analysts must examine the organization’s strategic goals, how the proposed sys- tem can support these goals, which factors are critical to the proposed system’s success, and criteria for evalu- ating the proposed system’s performance. Establishing evaluation criteria ensures objectivity throughout the SDLC process. In addition, analysts must get feedback from us- ers on the problem and the need for an information system. During this phase, they need to make sure users understand the four Ws: 0 Why—Why is the system being designed? Which decisions will be affected? I Who—Who is going to use the system? Is it going to be used by one decision maker or a group of decision makers? This question is also about types of users. For example, will the marketing department be using the system? Will manufacturing also be using the system as suppliers or consumers of information? 0 Whenh—When will the system be operational? When' (in what stages) in the business process Will the system be used? 0 What—What kind of capabilities will the system provide? How will these capabilities be used? organization or a specific group of users by answering Chapter 10: Building Successful Information Systems The end result of this phase should give users and top management a clear View of what the problem is and how the information system will solve the problem. As an example, take a look at how ABC Furniture is planning for an information system to solve the prob- lem of inaccurate inventory forecasts. Currently, ABC Furniture buys wood from New England Wood (NEW). I Why—ABC Furniture needs an information system to track inventory, generate a more accurate forecast of product demand, and track requirements for wood to be ordered from NEW. Clearly, a more accurate inventory will help reduce inventory costs, improve ABC Furniture’s relationship with NEW and with distributors, ensure that the company’s products are available for retailers, and improve ABC’s image in the marketplace. 0 Who—The main users of the information system will be the procurement group responsible for placing orders with NEW, the manufacturing division responsible for tracking inventory and ensuring that demand for finished goods is met, the sales personnel who take orders from distributors, and possibly distributors who take orders from retailers. 0 Wken—Thesystem must become operational within the next 4 months because the company’s main competitor is planning to open a new store in 6 months. Further, the system must support the mate- rials-ordering stage, the production-planning stage, and the shipping stage of the manufacturing process. iIt must also supply information for the marketing campaign that ABC Furniture is planning to run in 5 months and'support ABC’s expansion into a new region. I - What—On the inbound side, the system must track pending and received deliveries, quantities of raw materials, orders placed for raw materials, and raw material levels from all of ABC’s suppliers, including NEW. 0n the operations side, the system must provide information on inventory levels of all products, raw materials, work in _ progress at each stage of manufacturing, quality of raw materials received, quality of finished goods inspected, and rejects. On the outbound side, the system must track placed orders, unful— filled orders, and fulfilled orders for each finished product as well as order history for each distrib- _ utor and retailer : _ ' wizmm demands. 2.1 Formation oftheTask Force To ensure an information system’s success, users must have input in the planning, requirements-gathering and analysis, design, and implementation phases. For this reason, a task force is formed, consisting of representa- tives from different departments (including IT), systems analysts, technical advisors, and top management. This team collects user feedback and tries to get users in— volved from the beginning. The system designers and analysts should explain the goals and benefits of the new system so that the task force knows what to look for in user input. Gener- ally, an information system has two groups of users the task force should gather feedback from: internal and external. Internal users are employees who will use the system regularly, and they can offer important feedback on the system’s strengths and weaknesses. External us- ers aren’t employees but do use the system; they include customers, contractors, suppliers, and other business partners. Although they aren’t normally part of the task force, their input is essential. Using a task force for designing an information system is similar to using the joint application design approach. Joint application design (JAB) is a collec- tive activity involving users, top management, and ’ 3» ” M9 w. t . "may W. WgEU§§E$¥§E triage. , 1. ire—:4 on an - so . ' zinc} c ,gomejrspcé’figacté‘éfisupplig‘rs; . na-Wfifiwag "Maggy. 5 “ii 'w.’ f" at? 9311mth 776 ©Yuri ArcurSJShutterstock IT professionals. It centers on a structured workshop (called a JAD session) where users and system profes— sionals come together to develop an application. It involves a detailed agenda, visual aids, a leader who moderates the session, and a scribe who records the specifications. It results in a final document contain— ing definitions for data elements, workflows, screens, reports, and general system specifications. An ad- vantage of the JAD approach is that it incorporates varying viewpoints from different functional areas of an organization to help ensure that collected require- ments for the application aren’t too narrow and one- dimensional in focus.1 2.2. Feasibility Study Feasibility is the measure of how beneficial or practi- cal an information system will be to an organization and should be measured continuously throughout the SDLC process. Upper management is often frustrated by information systems that are unrelated to the orga- nization’s strategic goals or have an inadequate payoff, by poor communication between system users and designers, and by designers’ lack of consideration for users’ preferences and work habits. A detailed feasibil— ity study that focuses on these factors can help ease management’s frustration with investing in information systems}, Parr 3: [5 Development. Enterprise Systemr, M55, and Emerging Trends During the planning phase, analysts investigate a proposed solution’s feasibility and determine how best to present the solution to management to get funding. The tool used for this purpose is a feasibility study, and it usually has five major dimensions, discussed in the following sections: economic, technical, operational, schedule, and legal. The following information box is an example of the need for a feasibility study. 2.2.1 Economic Feasibility Economic feasibility assesses a system’s costs and ben- efits. Simply put, if implementing the system results in a net gain of $250,000 but the system cost $500,000, the system isn’t economically feasible. To conduct an economic feasibility study, the systems analyst team must identify all costs and benefits—tangible and in- tangiblewof the proposed system. The team must also be aware of opportunity costs associated with the in- formation system.,0pportunity costs measure what you would miss by not having a system or feature. For ex— ample, if your competitor has a Web site and you don’t, what’s the cost of not having a site, even if you don’t really need one? What market share are you likely to lose if you don’t have a Web site? To assess economic feasibility, the team tallies tan- gible development and operating costs for the system and compares them with expected financial benefits of the system. Development costs include the following: i 0 Hardware and software ° Software leases or licenses ' Computer time for programming, testing, and prototyping O Maintenance costs for monitoring equipment and software ' Personnel costs—salaries for consultants, systems analysts, network specialists, programmers, data entry clerks, computer operators, secretaries, and technicians ° Supplies and other equipment 0 Training employees who will be using the system Operating costs for running the system are typically estimated, although some vendors and suppliers can sup- ply costs. These costs can be fixed or variable (depend- ing on rate of use). After itemizing these costs, the team creates a budget. Many budgets don’t allow enough for deveiopment costs, especially technical expertise (pro- grammers, designers, and managers), and for this reason, many information system projects go over budget. change after the analysis or design phases, so the team should keep in mind that an information system project that’s feasible at the outset could become unfeasible later. Integrating feasibility checkpoints into the SDLC process is a good idea to ensure the system’s success. Projects can always be canceled or revised at feasibility checkpoint, if needed. To complete the economic feasibility study, the team must identify benefits of the information system, both tangible and intangible. Tangible benefits can be quantified in terms of monthly or annual savings, such as the new system allowing an organization to operate with three employees rather than five or the new system resulting in increased profits. The real challenge is assess- ing intangible costs and benefits accurately; attaching a realistic monetary value to these factors can be difficult. Intangible benefits are difficult to quantify in terms of dollar amounts, but if they aren’t at least identified, many information system projects can’t be justified. Some examples of intangible benefits include improved An information system’s scope and complexity can ' | V'. I . we’ve“? '3‘ ashes-ettl‘ 2., *,&%g-g.o‘fi.&¥&- a _ .. nauseating, enter . ,il'liti‘rzfstarn‘gaéggg, nagging fits - ng‘lfir’idfiiim ma9«s&s%$_ l employee morale, better customer satisfaction, more efficient use of human resources, increased flexibility in business operations, and improved communication. For example, you could quantify customer service as main- taining Current total sales and increasing them by 10% to improve net profit, for example. Other measures have been developed to measure intangibles, such as quanti~ fying employee morale with rates of on-tirne arrival at work or working overtime. Customer satisfaction, al- though intangible, can be measured by using satisfaction surveys, and the Internet has made thismethod easier. After collecting information on costs and benefits, the team can do a cost—effectiveness analysis. This analy- sis is based on the concept that a dollar today is worth more than a dollar one year from now. If the system doesn’t produce enough return on the investment, the money can be better spent elsewhere. The most common analysis methods are payback, net present value (NPV), return on investment (ROI), and internal rate of return {IRR). The final result of this task is the cost-benefit anal- ysis (CBA) report, used to sell the system to top manage- ment. This report can vary in format but should include the following sections: executive summary, introduction, scope and purpose, analysis method, recommendations, justifications, implementation plans, summary, and ap— pendix items, which can include supporting documenta- tion. Some examples of useful supporting documentation are organizational charts, workflow plans, floor plans, statistical information, project sequence diagrams, and timelines or milestone charts. 2.2.2 Technical Feasibility Technical feasibility is concerned with technology to be used in the system. The team needs to assess whether technology to support the new system is available or feasible to implement. For example, a full-featured voice- activated monitoring system isn’t technically feasible at this point. However, given the pace of technological development, many of these problems will eventually have solutions. Lack of technical feasibility can also 3 .- aicusitéirfltfim ‘ {whining-iris " ' ' , yplfiéd Part 3: is Development, ©emily2kiShutterstock stem from an organization lacking the expertise, time, or personnel to implement the new system. This prob- lem is also caEled “a lack of organizational readiness.” in this case, the organization can take steps to address its shortcomings and then consider the new system. Exten- sive training is one solution to this problem. 2.2.3 Operational Feasibility Operational feasibility is the measure of how well the proposed solution will work in the organization and how internal and external customers will react to it. The major question to answer is “Is the information system worth implementing?” To assess operational feasibility, the team should address the following questions: 0 Is the system doing what it’s supposed to do? For example, will the information system for ABC reduce orders for raw materials by tracking inventory more accurately? 0 Will the information system be used? ° Will there be resistance from users? 0 Will top management support the information system? 0 Will the proposed information system benefit the organization? 0 Will the proposed information system affect customers {both internal and external) in a positive way? 2.2.4 Schedule Feasibility Schedule feasibility is concerned with whether the new system can be completed on time. For example, an or— ganization might need a wireless'network immediately because of a disaster that destroyed the existing net- work. However, if the new system can’t be delivered in time, the loss of customers could force the organization out of business. In this case, the proposed system isn’t Enterprise SystemS, M55, and Emerging Trends a 3: _'3 r. 12“ ii? 23E 1? i. it ii: a feasible from a schedule viewpoint. The problem of go ing over schedule is common in the information systems field, but designers can often minimize this problem by using project management tools. 2.2.5 Legal Feasibility Legal feasibiiity is concerned with legal issues and typi~ cally addresses questions such as the following: 0 Will the system violate any legal issues in the country where it will be used? 0 Are there any political repercussions of using the system? - Is there any conflict between the proposed syStern and legal requirements? For example, does the system take the Information Privacy Act into account? Phase 2: Requirements Gathering and Analysis- n the requirements—gathering and analysis phase, analysts define the problem and generate alterna- tives for solving it. During this phase, the team attempts to understand the requirements for the system, analyzes these requirements to determine the main problem with the current system or processes, and looks for ways to solve problems by designing the new system. The first step in this phase is gathering require- ments. Several techniques are available for this step, including interviews, surveys, observations, and the JAD approach described earlier in the chapter. The in- tent is to find out what users do, how they do it, what problems they face in performing their jobs, how the new system would address these problems, what users expect from the system, what decisions are made, what data is needed to make decisions, where data comes from, how data should be presented, and what tools are needed to examine data for the decisions users make. All this information can be recorded, and the team uses this information to determine what the new system should do (process analysis) and what data is needed for this process to be performed (data analysis}. The team uses the information collected in require- ments gathering to understand the main problems: define the project’s scope, including what it should and shouldn’t do, and create a document called the “system specifications.” This document is then sent t...
View Full Document

{[ snackBarMessage ]}

What students are saying

  • Left Quote Icon

    As a current student on this bumpy collegiate pathway, I stumbled upon Course Hero, where I can find study resources for nearly all my courses, get online help from tutors 24/7, and even share my old projects, papers, and lecture notes with other students.

    Student Picture

    Kiran Temple University Fox School of Business ‘17, Course Hero Intern

  • Left Quote Icon

    I cannot even describe how much Course Hero helped me this summer. It’s truly become something I can always rely on and help me. In the end, I was not only able to survive summer classes, but I was able to thrive thanks to Course Hero.

    Student Picture

    Dana University of Pennsylvania ‘17, Course Hero Intern

  • Left Quote Icon

    The ability to access any university’s resources through Course Hero proved invaluable in my case. I was behind on Tulane coursework and actually used UCLA’s materials to help me move forward and get everything together on time.

    Student Picture

    Jill Tulane University ‘16, Course Hero Intern