Chapter 10 Building Successful Information Systems Learning Objectives Describe the systems development life cycle (SDLC) as a method for developing information systems. Explain the tasks involved in the planning phase. Explain the tasks involved in the requirements-gathering and analysis phase. Explain the tasks involved in the design phase. Explain the tasks involved in the implementation phase. Explain the tasks involved in the maintenance phase. Describe new trends in systems analysis and design, including service-oriented architecture, rapid application development, extreme programming, and agile methodology. Detailed Chapter Outline I. Systems Development Life Cycle: An Overview In the information systems field, system failure can happen for several reasons, including missed deadlines, users’ needs that are not met, dissatisfied customers, lack of support from top management, and exceeding the budget. Using a system development method can help prevent these failures. To achieve this integration, designers often follow the systems development life cycle (SDLC), also known as the “waterfall model.” It is a series of well-defined phases performed in sequence that serves as a framework for developing a system or project. Systems planning today is about evaluating all potential systems that need to be implemented. A preliminary analysis of requirements for each is done, 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 extension 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 situations. II. Phase 1: Planning During the planning phase, which is one of the most crucial phases of the SDLC model, the systems designer must define the problem the organization faces, taking care not to define symptoms rather than the underlying problem. The problem can be identified internally or externally. After identifying the problem, an analyst or team of analysts assesses the current and future needs of the organization or a specific group of users by answering the following questions: Why is this information system being developed? Who are the system’s current and future users? Is the system new, or is it an upgrade or extension of an existing system? Which functional areas (departments) will be using the system? As a part of this assessment, analysts must examine the organization’s strategic goals, how the proposed system can support these goals, which factors are critical to the proposed system’s success, and the criteria for evaluating the proposed system’s performance. Establishing evaluation criteria ensures objectivity throughout the SDLC process. In addition, analysts must get feedback from users on the problem and the need for an information system. During this phase, they need to make sure users understand the four Ws: Why—why is the system being designed? Which decisions will be affected? 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? And will the Manufacturing Department be using the system as suppliers or as consumers of information? When—when will the system be operational? When in the business process (in what stages) will the system be used? What—what kind of capabilities will the system provide? How will these capabilities be used? 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. A. Formation of the Task Force To ensure an information system’s success, users must have input in the planning, requirements-gathering and analysis, design, and implementation phases. Generally, an information system has two groups of users from whom the task force should gather feedback: 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 users are not employees but do use the system; they include customers, contractors, suppliers, and other business partners. Although external users are not 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 (JAD) is a collective activity involving users, top management, and IT professionals. It centers on a structured workshop (called a JAD session) in which users and system professionals 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. An advantage of the JAD approach is that it incorporates varying viewpoints from different functional areas of an organization to help ensure that collected requirements for the application are not too narrow and one-dimensional in focus. B. Feasibility Study Feasibility is the measure of how beneficial or practical an information system will be to an organization; it should be measured continuously throughout the SDLC process. During the planning phase, analysts investigate a proposed solution’s feasibility and determine how best to present the solution to management in order to obtain funding. The tool used for this purpose is a feasibility study, and it usually has five major dimensions: economic, technical, operational, scheduling, and legal. Economic Feasibility Economic feasibility assesses a system’s costs and benefits. To conduct an economic feasibility study, the systems analyst team must identify all costs and benefits—tangible and intangible—of the proposed system. Opportunity costs measure what one would miss by not having a system or feature. To assess economic feasibility, the team tallies tangible development and operating costs for the system and compares them with expected financial benefits of the system. Development costs include the following: Hardware and software Software leases or licenses Computer time for programming, testing, and prototyping 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 Training employees who will be using the system An information system’s scope and complexity can change after the analysis or design phases, so the team should keep in mind that an information system project that is 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 a 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. Intangible benefits are difficult to quantify in terms of dollar amounts, but if they are not at least identified, many information system projects cannot be justified. After collecting information on costs and benefits, the team can do a cost-effectiveness analysis. This analysis is based on the concept that a dollar today is worth more than a dollar one year from now. If the system does not 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 analysis (CBA) report, used to sell the system to top management. Technical Feasibility Technical feasibility is concerned with the technology that will be used in the system. The team needs to assess whether the technology to support the new system is available or feasible to implement. Lack of technical feasibility can also stem from an organization lacking the expertise, time, or personnel to implement the new system. This problem is also called “a lack of organizational readiness.” 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. To assess operational feasibility, the team should address the following questions: Is the system doing what it is supposed to do? For example, will the information system for ABC reduce orders for raw materials by tracking inventory more accurately? Will the information system be used? Will there be resistance from users? Will top management support the information system? Will the proposed information system benefit the organization? Will the proposed information system affect customers (both internal and external) in a positive way? Scheduling Feasibility Scheduling feasibility is concerned with whether the new system can be completed on time. The problem of missing deadlines is common in the information systems field, but designers can often minimize this problem by using project management tools. Legal Feasibility Legal feasibility is concerned with legal issues; it typically addresses questions such as the following: Will the system violate any legal issues in the country where it will be used? Are there any political repercussions of using the system? Is there any conflict between the proposed system and legal requirements? For example, does the system take the Information Privacy Act into account? III. Phase 2: Requirements Gathering and Analysis In the requirements-gathering and analysis phase, analysts define the problem and generate alternatives 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 requirements. Several techniques are available for this step, including interviews, surveys, observations, and the JAD approach. The intent is to find out the following: 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 What tools are needed to examine data for the decisions that 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 during the requirements-gathering phase to understand the main problems, define the project’s scope—including what it should and should not do—and create a document called the “system specifications.” There are two major approaches to the analysis and design of information systems: the structured systems analysis and design (SSAD) approach and the object-oriented approach. The onset of the Web plus the release of Java, an object-oriented language, created the push for a different approach than SSAD. To understand the difference between the two approaches, it should be first understood that any system has three parts: process, data, and user interface. Analyzing requirements in the analysis phase is done from the perspective of the process and data. The SSAD approach treats process and data independently and is a sequential approach that requires completing the analysis before beginning the design. The object-oriented approach combines process and data analysis, and the line between analysis and design is so thin that analysis and design seem to be a single phase instead of the two distinct phases. The models created during the analysis phase constitute the design specifications. After confirming these specifications with users, analysts start designing the system. IV. Phase 3: Design During the design phase, analysts choose the solution that is the most realistic and offers the highest payoff for the organization. The design phase consists of three parts: conceptual design, logical design, and physical design. The conceptual design is an overview of the system and does not include hardware or software choices. The logical design makes the conceptual design more specific by indicating hardware and software, such as specifying Linux servers, Windows clients, an object-oriented programming language, and a relational DBMS. Finally, the physical design is created for a specific platform, such as choosing Dell servers running Ubuntu Linux, Dell laptops running Windows 8 and Internet Explorer, Java for the programming language, and SQL Server 2014 for the relational DBMS. A. Computer-Aided Systems Engineering Systems analysts use computer-aided systems engineering (CASE) tools to automate parts of the application development process. These tools are particularly helpful for investigation and analysis in largescale projects because they automate parts of the design phase. CASE tools support the design phase by helping analysts do the following: Keep models consistent with each other Document models with explanations and annotations Ensure that models are created according to specific rules Create a single repository of all models related to a single system, which ensures consistency in analysis and design specifications Track and manage changes to the design Create multiple versions of the design CASE tools are similar to computer-aided design (CAD) tools used by architects and engineers. Their capabilities vary, depending on the product, but generally include the following: Graphics tools, such as data flow diagrams, to illustrate a system’s operation Dictionary tools designed to record the system’s operation in detail Prototyping tools for designing input and output formats, forms, and screens Code generators to minimize or eliminate programming efforts Project management tools to help control the system’s schedule and budget CASE tools usually include the following output: Specifications documents Documentation of the analysis, including models and explanations Design specifications with related documentation Logical and physical design documents based on the conceptual design Code modules that can be incorporated into the system B. Prototyping Prototyping has been around for many years in physical science because building a small working model first is easier and less expensive than building the entire system. Prototyping has gained popularity in designing information systems because needs can change quickly and lack of specifications for the system can be a problem. Prototyping is also the fastest way to put an information system into operation. Prototypes are usually used for the following purposes: Gathering system requirements—during the planning phase, designing a prototype and showing it to users is a good way to gather additional information and refine requirements for the proposed system. Helping to determine system requirements—if users are not sure about the type of information system they want, a prototype can serve as a valuable tool for demonstrating the system’s functional capabilities, after which users can be asked for their reactions. Determining a system’s technical feasibility—if a system is not technically feasible or appears to be unfeasible, a prototype can be used to show users that a particular task can be done. This type of prototype is called a proof-of-concept prototype. Selling the proposed system to users and management—prototypes are sometimes used to sell a proposed system to users and management by showing some of its features and demonstrating how beneficial it could be to the organization. This type of prototype is called a selling prototype. Prototyping is usually done in four steps: Define the initial requirements. Develop the prototype. Review and evaluate the prototype. Revise the prototype. After completing the prototype, users begin using it and evaluating its performance. Depending on the outcome, one of the following decisions is made: revise the prototype, cancel the information system project, develop a new prototype, or build a complete system based on the prototype. At this point, the problem is better defined, and the system’s operations are understood more clearly. Prototyping Development Tools Widely used tools include spreadsheet packages, such as Microsoft Excel, and database management packages, such as Microsoft Access, whereas Visual Basic is commonly used to code the logic required for processes. CASE tools and third- and fourth-generation programming languages can be used to quickly develop prototypes. Prototyping tools for user interface design include GUI magnets, Designer Vista, and GUI Design Studio. Advantages and Disadvantages of Prototyping As mentioned, prototyping offers several advantages: It provides a method for investigating an environment in which the problem is poorly defined and information is difficult to gather. It reduces the need to train information system users because the users are involved in developing the system. It reduces costs because building a model is less expensive than building the complete system. It increases the system’s chance of success by encouraging users’ involvement. It is easier to modify a prototype than a complete system. It improves documentation because users and designers can walk through several versions of the system. It improves communication among users, top management, and information systems personnel because seeing a concrete model often prompts potential users of the system to ask questions, express opinions, point out shortcomings and strengths, and so forth. Prototyping has some disadvantages: It might require more support and assistance from users and top management than they are willing to offer. The prototype might not reflect the final system’s actual operation and, therefore, could be misleading. Developing a prototype might lead analysts and designers to forego comprehensive testing and documentation. V. Phase 4: Implementation During the implementation phase, the solution is transferred from paper to action, and the team configures the system and procures components for it. A variety of tasks takes place in the implementation phase, including the following: Acquiring new equipment Hiring new employees Training employees Planning and designing the system’s physical layout Coding Testing Designing security measures and safeguards Creating a disaster recovery plan When an information system is ready to be converted, designers have several options: Parallel conversion—in parallel conversion, the old and new systems run simultaneously for a short time to ensure the new system works correctly. Phased-in-phased-out conversion—in phased-in-phased-out conversion, as each module of the new system is converted, the corresponding part of the old system is retired. Plunge (direct cutover) conversion—in plunge (direct cutover) conversion, the old system is stopped and the new system is implemented. Pilot conversion—in pilot conversion, the analyst introduces the system in only a limited area of the organization, such as a division or department. A. Project Management Tools and Techniques Project management software such as Microsoft Project and Micro Planning International’s Micro Planner enable the systems analyst to study the cost, time, and resource impact of schedule changes. Project management techniques are also used, including PERT (Program Evaluation Review Technique), CPM (Critical Path Method), and Gantt charts. PERT and CPM techniques work by determining the “critical path” for the completion of a series of interrelated activities. To establish a PERT or CPM network, the analyst identifies all the activities needed for the completion of the project, identifies and establishes a prerequisite list (the activities that have to be accomplished first), and calculates the critical path duration. Using the critical path, the systems analyst can establish a Gantt chart. A Gantt chart lists the completion time (sometimes called the “milestone”) on the x-axis and all the activities on the y-axis. This allows the systems analyst to monitor the progress of the project and detect any delay in the daily operation of the project. Below are seven guidelines for a successful IT project management: Assign a project manager to the information systems being developed. Identify a goal for every project meeting. Document each project meeting with e-mail, memo, wiki, or (if applicable) internal social media. Conduct regular face-to-face meetings with project technical staff. A new person should take over as a project manager for team members who are falling behind. Build in slack time for a project without disclosing it to the team members. Assign the best available technical people to the project. B. Request for Proposal A request for proposal (RFP) is a written document with detailed specifications that is used to request bids for equipment, supplies, or services from vendors. It is usually prepared during the implementation phase and contains detailed information about the functional, technical, and business requirements of the proposed information system. Drafting an RFP can take 6 to 12 months, but with software, the Internet, and other online technologies, time and costs can be reduced. A crucial part of this process is comparing bids from single and multiple vendors. The main advantage of an RFP is that all vendors get the same information and requirements, so bids can be evaluated more fairly. Furthermore, all vendors have the same deadline for submitting bids, so no vendor has the advantage of having more time to prepare an offer. RFPs are also useful in narrowing down a long list of prospective vendors. A major disadvantage of an RFP is the time involved in writing and evaluating proposals. With the rapid changes in information technologies, a lengthy time frame makes RFPs less appealing. Many companies cannot wait 6 to 12 months to decide on a vendor for an information system. One alternative to an RFP is a request for information (RFI), a screening document for gathering vendor information and narrowing the list of potential vendors. An RFI can help manage the selection of vendors by focusing on the project requirements that are crucial to selecting vendors. However, an RFI has its limitations. It is not suitable for complex projects because it can be used only for selecting three or four finalists from a list of candidates. C. Implementation Alternatives The SDLC approach is sometimes called insourcing, meaning an organization’s team develops the system internally. Two other approaches for developing information systems are self-sourcing and outsourcing. Self-Sourcing The increasing demand for timely information has put pressure on information systems teams, who are already overloaded with maintaining and modifying existing systems. In many organizations, the task of keeping existing systems running takes up much of the available computing resources and personnel, leaving few resources for developing new systems. In recent years, therefore, more end users have been developing their own information systems with little or no formal assistance from the information systems team. These users might not know how to write programming code, but they are typically skilled enough to use off-the-shelf software, such as spreadsheet and database packages, to produce custom built applications. This trend, called self-sourcing (or end-user development), has resulted from long backlogs in developing information systems, the availability of affordable hardware and software, and organizations’ increasing dependence on timely information. With the help of development tools, such as query languages, report generators, and fourth-generation programming languages, self-sourcing has become an important part of information system resources. It is also useful in creating one-of-a-kind applications and reports. Self-sourcing can help reduce the backlog in producing information systems and improve flexibility in responding to users’ information needs. Although self-sourcing can solve many current problems, managers are concerned about end users’ lack of adequate systems analysis and design background and loosening of system development standards. Other disadvantages of self-sourcing include the following: Possible misuse of computing resources Lack of access to crucial data Lack of documentation for the applications and systems that end users develop Inadequate security for the applications and systems that end users develop Applications developed by end users not up to information systems standards Lack of support from top management Lack of training for prospective users Self-sourcing gives end users the power to build their own applications in a short time and create, access, and modify data. This power can be destructive, however, if the organization does not apply control and security measures. To prevent the proliferation of information systems and applications that are not based on adequate systems development principles, organizations should develop guidelines for end users and establish criteria for evaluating, approving or rejecting, and prioritizing projects. Classifying and cataloging existing applications are necessary to prevent end users from developing applications that basically handle the same functions as an existing application; this redundancy can be costly. In addition, data administration should be enforced to ensure the integrity and reliability of information. Outsourcing With the outsourcing approach, an organization hires an external vendor or consultant who specializes in providing development services. This approach can save the cost of hiring additional staff while meeting the demand for more timely development of information systems projects. With the development of Web 2.0, another form of outsourcing has become popular: crowdsourcing. This refers to the process of outsourcing tasks that are traditionally performed by employees or contractors to a large group of people (a crowd) through an open call. An outsourcing company that employs the SDLC approach has the following options: Onshore outsourcing—the organization chooses an outsourcing company in the same country. Nearshore outsourcing—the organization chooses an outsourcing company in a neighboring country, such as when a U.S. organization chooses a company in Canada or Mexico. Offshore outsourcing—the organization chooses an outsourcing company in any part of the world (usually a country farther away than a neighboring country), as long as it can provide the needed services. Although outsourcing has the advantages of being less expensive, delivering information systems more quickly, and giving an organization the flexibility to concentrate on its core functions as well as other projects, it does have some disadvantages. They include the following: Loss of control—relying on the outsourcing company to control information system functions can result in the system not fully meeting the organization’s information requirements. Dependency—if the organization becomes too dependent on the outsourcing company, changes in the outsourcing company’s financial status or managerial structure can have a major impact on the organization’s information system. Vulnerability of strategic information—because third parties are involved in outsourcing, the risk of leaking confidential information to competitors increases. VI. Phase 5: Maintenance During the maintenance phase, the information system is operating, enhancements and modifications to the system have been developed and tested, and hardware and software components have been added or replaced. As part of this phase, the team collects performance data and gathers information on whether the system is meeting its objectives by talking with users, customers, and other people affected by the new system. If the system’s objectives are not being met, the team must take corrective action. With the ongoing nature of the SDLC approach, maintenance can lead to starting the cycle over at the planning phase if the team discovers the system is not working correctly. VII. New Trends in Systems Analysis and Design The SDLC model might not be appropriate in the following situations: There is a lack of specifications—that is, the problem under investigation is not well defined. The input–output process cannot be identified completely. The problem is “ad hoc,” meaning it is a one-time problem that is not likely to reoccur. Users’ needs keep changing, which means the system undergoes several changes. The SDLC model might work in the short term, but in the long term, it is not suitable in this situation. A. Service-Oriented Architecture Service-oriented architecture (SOA) is a philosophy and a software and system development methodology that focuses on the development, use, and reuse of small, self-contained blocks of codes (called services) to meet the software needs of an organization. The fundamental principle behind SOA is that the “blocks of codes” can be reused in a variety of different applications, allowing new business processes to be created from a pool of existing services. SOA advocates that core business functions and the dynamic functions that change all the time should be decoupled. SOA allows an organization to pick and choose those services that respond most effectively to the customer’s needs and market demands. Services or “blocks of codes” can be replaced, changed, or even combined. Many organizations use SOA as a philosophy and methodology. For example, Starwood Hotels and Resorts Worldwide is replacing its legacy room-reservation system with an SOA-based system. By using SOA, they can offer as many as 150 service-based applications built on Web standards. B. Rapid Application Development Rapid application development (RAD) concentrates on user involvement and continuous interaction between users and designers. It combines the planning and analysis phases into one phase and develops a prototype of the system. RAD uses an iterative process (also called “incremental development”) that repeats the design, development, and testing steps as needed, based on feedback from users. One shortcoming of RAD is a narrow focus, which might limit future development. In addition, because these applications are built quickly, the quality might be lower. C. Extreme Programming Extreme programming (XP) is a recent method for developing software applications and information system projects. XP divides a project into smaller functions, and developers cannot go on to the next phase until the current phase is finished. The XP method delivers the system to users as early as possible and then makes changes that the user suggests. In the XP environment, programmers are usually organized into teams of two, sharing a workstation and working on the same code. This is called pair programming (also referred to as “sharing a keyboard”), each programmer performing the actions the other programmer is not currently performing. In this way, they can detect and correct programming mistakes as they go, which is faster than correcting them after the entire program has been written. Like RAD, XP uses a software library for reusable pieces that can be integrated into the new system. IBM, Chrysler, and Microsoft, among others, have used this method successfully. Its key features are: Simplicity Incremental process Responsiveness to changing requirements and changing technology Teamwork Continuous communication among key players Immediate feedback from users D. Agile Methodology Agile methodology is similar to XP in focusing on an incremental development process and timely delivery of working software. Agile methodology focuses on setting a minimum number of requirements and turning them into a working product. The Agile Alliance has written a manifesto that includes the following principles: Satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Have business people and developers work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Always attend to technical excellence. Good design enhances agility. At regular intervals, the team should reflect on how to become more effective, then tune and adjust its behavior accordingly. Instructor Manual for MIS Hossein Bidgoli 9781305632004, 9781337625999, 9781337625982, 9781337406925
Download
Close
Close
