Information systems development Lecture notes

information systems development methodologies techniques and tools and project management, difference between information systems development and software engineering
Prof.EvanBaros Profile Pic
Prof.EvanBaros,United Kingdom,Teacher
Published Date:26-07-2017
Your Website URL(Optional)
Comment
Initial System Feasibility Risk Staffing Standards Workplan Analysis Plan Request Analysis Assessment Plan c01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 12/5/11 2:22 PM Page 3 PART ONE PLANNING PLANNING PHASE PHASE CHAPTER Project 1 Initiation The Planning Phase is the fundamental two-step process of understanding why an information system should be developed and creating a plan for how the project team will develop it. CHAPTER Project The deliverables from both steps 2 Management are combined into the project plan, which is presented to the project sponsor and approval committee at the end of the Planning Phase. They decide whether it is advisable to proceed with the system development project.c01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 12/5/11 2:22 PM Page 4 PLANNING Identify project. Develop systems request. Analyze technical feasibility. Analyze economic feasibility. Analyze organizational feasibility. Perform project selection review. Estimate project time. Identify project tasks. Create work breakdown structure. Create PERT charts. Create Gantt charts. Manage scope. Staff project. Create project charter. Set up CASE repository. Develop standards. Begin documentation. Assess and manage risk. T ASK CHECKLIST PLANNING ANALYSIS DESIGN ▼c01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 5 CHAPTER 1 THE SYSTEMS ANALYST AND INFORMATION SYSTEMS DEVELOPMENT his chapter introduces the role of the systems analyst in information systems devel- T opment projects. First, the fundamental four-stage systems development life cycle (planning, analysis, design, and implementation) is established as the basic framework for the IS development process. Next, ways in which organizations identify and initiate poten- tial projects are discussed. The first steps in the process are to identify a project that will deliver value to the business and to create a system request that provides the basic infor- mation about the proposed system. Next, the analysts perform a feasibility analysis to determine the technical, economic, and organizational feasibility of the system. OBJECTIVES ■ Explain the role played in information systems development by the systems analyst. ■ Describe the fundamental systems development life cycle and its four phases. ■ Explain how organizations identify IS development projects. ■ Explain the importance of linking the information system to business needs. ■ Be able to create a system request. ■ Describe technical, economic, and organizational feasibility assessment. ■ Be able to perform a feasibility analysis. CHAPTER OUTLINE Introduction Feasibility Analysis The Systems Analyst Technical Feasibility Systems Analyst Skills Economic Feasibility Systems Analyst Roles Organizational Feasibility The Systems Development Life Cycle Applying the Concepts at Tune Source Planning Appendix 1A—Detailed Economic Analysis Feasibility Analysis for Tune Source Design Implementation Project Identification and Initiation System Request Applying the Concepts at Tune Source IMPLEMENTATIONc01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 6 6 Chapter 1 The Systems Analyst and Information Systems Development INTRODUCTION The systems development life cycle (SDLC) is the process of determining how an information system (IS) can support business needs, designing the system, building it, and delivering it to users. If you have taken a programming class or have pro- grammed on your own, this probably sounds pretty simple. In the real world, how- ever, it is not so easy. In 2010, an estimated 2.4 trillion was spent by organizations and govern- ments on IT hardware, software, and services worldwide. This spending level was projected to increase by 3.5% in 2011.1 Unfortunately, a study conducted in 2008 found success is “improbable” in 68% of technology projects.2 Many of the systems that aren’t totally abandoned are delivered to the users significantly late, cost far more than expected, and have fewer features than originally planned. A 2009 study attempting to quantify the costs of this failure rate estimated a toll on the global economy of 6.2 trillion.3 While this specific outcome has been ques- tioned by some, the point remains that the cost of IT project failures is staggering both in terms of the proportion of projects that fail and the costs of those failures.4 Today, both businesses and governments experience embarrassing and costly errors in their information systems. Here is a sample of just a few notable software glitches that occurred in 2010: ■ A software error resulted in Toys R Us double billing some shoppers for pur- chases made on Black Friday. ■ Verizon Wireless had to refund 50 million to customers due to billing system errors. ■ Chase banking customers were unable to access their online banking accounts for over 24 hours due to a computer glitch. ■ McAfee’s anti-virus software product caused its users’ computers to lock up. McAfee offered affected customers a free 2-year subscription and reimbursement for costs incurred to repair the machines. ■ A U.S. Navy drone (unmanned aerial vehicle) reportedly flew into restricted air space near Washington D.C. when operators lost control for about 20 minutes due to a software issue.5 Although we would like to promote this book as a “silver bullet” that will keep you from experiencing failed IS projects, we must admit that such a silver bullet guaranteeing IS development success does not exist.6 Instead, this book will 1 http://www.gartner.com/it/page.jsp?id=1419513; accessed February, 2011. 2 http://www.iag.biz/images/resources/iag business analysis benchmark - full report.pdf; accessed February, 2011. 3 http://www.objectwatch.com/whitepapers/ITComplexityWhitePaper.pdf; accessed February, 2011. 4 http://www.zdnet.com/blog/projectfailures/critique-62-trillion-global-IT-failure-stats/7695?tag=mantle_ skin;content; accessed February, 2011. 5 http://www.zdnet.com/blog/projectfailures/ten-great-software-glitches-for-2010/11941?tag=mantle_skin; content; accessed February, 2011. 6 The idea of using the silver bullet metaphor was first described in a paper by Frederick Brooks. See Frederick P. Brooks, Jr., “No Silver Bullet—Essence and Accident in Software Engineering,” Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, H.-J. Kugler (ed.), 1986: 1069–76.c01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 7 Introduction 7 provide you with many fundamental concepts and practical techniques that you can use to improve the probability of success. The key person in the SDLC is the systems analyst, who analyzes the business situation, identifies opportunities for improvements, and designs an information system to implement the improvements. Many systems analysts view their profes- sion as one of the most interesting, exciting, and challenging jobs around. As a systems analyst, you will work as a team with a variety of people, including business and technical experts. You will feel the satisfaction of seeing systems that you designed and developed make a significant positive business impact, while knowing that your unique skills helped make that happen. It is important to remember that the primary objective of the systems analyst is not to create a wonderful system. The primary goal is to create value for the organ- ization, which for most companies means increasing profits. (Government agencies and not-for-profit organizations measure value differently.) Many failed systems were abandoned because the analysts tried to build a wonderful system without clearly understanding how the system would support the organization’s goals, improve business processes, and integrate with other information systems to provide value. An investment in an information system is like any other investment, such as a new machine tool. The goal is not to acquire the tool, because the tool is simply a means to an end; the goal is to enable the organization to perform work better so that it can earn greater profits or serve its constituents more effectively. This book will introduce you to the fundamental skills you will need to be a systems analyst. This is a pragmatic book that discusses best practices in systems development; it does not present a general survey of systems development that CONCEPTS 1-A MANAGERIAL CAUSES OF IT FAILURES IN ACTION A significant proportion of IT projects An analysis of these IT failures reveals several con- fail to fulfill their original objectives, resulting in wasted tributing factors. First, Qantas faced the challenges of a resources and a damaged reputation for the responsible complicated technical infrastructure and outdated legacy IT department. In many cases, the causes of the failure applications. More significantly, however, was the failure of are organizational issues, not technical issues. company leadership to understand basic IT issues. In pub- Qantas, the Australian national airline, has lic statements, the company CFO seemed not to care about endured two high-profile IT failures in recent years. In the user perspectives on new software, preferring instead to 1995, Project eQ, a 10-year technology services con- put in what management thought was appropriate. This atti- tract with IBM, was cancelled after four years, at a cost tude, in part, led to union problems and claims of poorly of 200 million. Poor planning contributed to the failure designed, hard-to-use software and inadequate training. to upgrade a complex and unwieldy IT infrastructure Aging applications and an unwieldy technical saddled with 700-odd applications written in older pro- infrastructure are challenges faced by many organiza- gramming languages. tions today. But the senior-management attitude that In 2008, Qantas canceled Jetsmart, a 40 million seemingly disregards the views of software users casts parts-management system implementation, due in part to serious questions about Qantas’ prospects for IT project a dispute with the unionized users (aircraft mechanics) of success in the future. the system. The union advised its members not to assist Source: http:/blogs.zdnet.com/projectfailures/, February 29, with the implementation, claiming the software unneces- 2008. sarily increased the members’ workload.c01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 8 8 Chapter 1 The Systems Analyst and Information Systems Development exposes you to everything about the topic. By definition, systems analysts do things and challenge the current way that an organization works. To get the most out of this book, you will need to actively apply the ideas and concepts in the examples and in the “Your Turn” exercises that are presented throughout to your own systems development project. This book will guide you through all the steps for delivering a successful information system. In the text, we illustrate how one organization, called Tune Source, applies the steps in one project, developing a Web-based digital music sales system. (Other illustrations of successful IS projects are provided on the course Web site.) By the time you finish the book, you won’t be an expert ana- lyst, but you will be ready to start building systems for real. In this chapter, we first introduce the role of the systems analyst in informa- tion systems development projects. We discuss the wide range of skills needed to be successful in this role, and we explain various specialties that systems analysts may develop. We then introduce the basic SDLC that information systems projects follow. This life cycle is common to all projects and serves as a framework for understanding how information systems projects are accomplished. We discuss how projects are identified and initiated within an organization and how they are initially described in a system request. Finally, we describe the feasibility analysis that is performed, which drives the decision whether to proceed with the project. THE SYSTEMS ANALYST The systems analyst plays a key role in information systems development projects. The systems analyst works closely with all project team members so that the team develops the right system in an effective way. Systems analysts must understand how to apply technology to solve business problems. In addition, systems analysts may serve as change agents who identify the organizational improvements needed, design systems to implement those changes, and train and motivate others to use the systems. Systems Analyst Skills New information systems introduce change to the organization and its people. Leading a successful organizational change effort is one of the most difficult jobs that someone can do. Understanding what to change, knowing how to change it, and convincing others of the need for change require a wide range of skills. These skills can be broken down into six major categories: technical, business, analytical, interpersonal, management, and ethical. Analysts must have the technical skills to understand the organization’s existing technical environment, the new system’s technology foundation, and the way in which both can be fit into an integrated technical solution. Business skills are required to understand how IT can be applied to business situations and to ensure that the IT deliv- ers real business value. Analysts are continuous problem solvers at both the project and the organizational level, and they put their analytical skills to the test regularly. Often, analysts need to communicate effectively, one-on-one with users and business managers (who often have little experience with technology) and with pro- grammers (who often have more technical expertise than the analyst does). They must be able to give presentations to large and small groups and to write reports. Not only do they need to have strong interpersonal abilities, but they also need toc01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 9 The Systems Analyst 9 SPOTLIGHT ON ETHICS-1 James is a systems analyst on a new account manage- James is uncomfortable with the request. He is not ment system for Hometown National Bank. At a recent sure the bank has the right to use a person’s data for pur- meeting with the project sponsor, James learned about poses other than the original intent. Who “owns” this some new ideas for the system that were not a part of the data, the bank that collected it as a part of a customer original project scope. Specifically, the bank’s marketing opening an account, or the customer who the data director has asked that some of the data that will be col- describes? Should James insist that the customers give lected by the new system from customers who open new authorization to use “their” data in this way? Or should checking and savings accounts also be used as the basis he say nothing and ignore the issue? Is it necessary (or of a marketing campaign for various loan products the appropriate) for a systems analyst to be an ethical watch- bank offers. dog in a systems development project? Why or why not? manage people with whom they work, and they must manage the pressure and risks associated with unclear situations. Finally, analysts must deal fairly, honestly, and ethically with other project team members, managers, and system users. Analysts often deal with confidential informa- tion or information that, if shared with others, could cause harm (e.g., dissent among employees); it is important for analysts to maintain confidence and trust with all people. Systems Analyst Roles As organizations and technology have become more complex, most large organiza- tions now build project teams that incorporate several analysts with different, but complementary, roles. In smaller organizations, one person may play several of these roles. Here we briefly describe these roles and how they contribute to a sys- tems development project. The systems analyst role focuses on the IS issues surrounding the system. This person develops ideas and suggestions for ways that IT can support and improve business processes, helps design new business processes supported by IT, designs the new information system, and ensures that all IS standards are main- tained. The systems analyst will have significant training and experience in analysis and design and in programming. 1-1 BEING AN ANALYST YOUR TURN Suppose you decide to become an QUESTION: analyst after you graduate. What type of analyst would Develop a short plan that describes how you will prepare you most prefer to be? What type of courses should you for your career as an analyst. take before you graduate? What type of summer job or internship should you seek?c01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 10 10 Chapter 1 The Systems Analyst and Information Systems Development The business analyst role focuses on the business issues surrounding the sys- tem. This person helps to identify the business value that the system will create, develops ideas for improving the business processes, and helps design new business processes and policies. The business analyst will have business training and expe- rience, plus knowledge of analysis and design. The requirements analyst role focuses on eliciting the requirements from the stakeholders associated with the new system. As more organizations recognize the critical role that complete and accurate requirements play in the ultimate success of the system, this specialty has gradually evolved. Requirements analysts understand the business well, are excellent communicators, and are highly skilled in an array of requirements elicitation techniques (discussed in Chapter 3). The infrastructure analyst role focuses on technical issues surrounding the ways the system will interact with the organization’s technical infrastructure (hardware, software, networks, and databases). This person ensures that the new information system conforms to organizational standards and helps to identify infrastructure changes that will be needed to support the system. The infrastructure analyst will have significant training and experience in networking, database administration, and various hardware and software products. Over time, an experienced infrastruc- ture analyst may assume the role of software architect, who takes a holistic view of the organization’s entire IT environment and guides application design decisions within that context. The change management analyst role focuses on the people and management issues surrounding the system installation. This person ensures that adequate doc- umentation and support are available to users, provides user training on the new system, and develops strategies to overcome resistance to change. The change man- agement analyst will have significant training and experience in organizational behavior and specific expertise in change management. The project manager role ensures that the project is completed on time and within budget and that the system delivers the expected value to the organization. The project manager is often a seasoned systems analyst who, through training and experience, has acquired specialized project management knowledge and skills. More will be said about the project manager in the next chapter. The roles and the names used to describe them may vary from organization to organization. In addition, there is no single typical career path through these professional roles. Some people may enter the field as a more technically-oriented programmer/analyst. Others may enter as a business-oriented functional specialist with an interest in applying IT to solve business problems. As shown in Figure 1-1, those who are interested in the broad field of information systems development may follow a variety of paths during their career. THE SYSTEMS DEVELOPMENT LIFE CYCLE In many ways, building an information system is similar to building a house. First, the owner describes the vision for the house to the developer. Second, this idea is transformed into sketches and drawings that are shown to the owner and refined (often, through several drawings, each improving on the other) until the owner agrees that the pictures depict what he or she wants. Third, a set of detailed blue- prints is developed that presents much more specific information about the housec01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 11/3/11 7:23 AM Page 11 The Systems Development Life Cycle 11 Change Requirements management analyst analyst Entry-level Business business function analyst specialist Project manager Systems analyst Entry-level programmer/ analyst Infrastructure Software analyst architect More common path Less common path FIGURE 1-1 Career Paths for System Developers (e.g., the layout of rooms, placement of plumbing fixtures and electrical outlets, and so on). Finally, the house is built following the blueprints—and often with some changes and decisions made by the owner as the house is erected. Building an information system using the SDLC follows a similar set of four fundamental phases: planning, analysis, design, and implementation (Figure 1-2). Each phase is itself composed of a series of steps, which rely on techniques that produce deliverables (specific documents and files that explain various elements of the system). Figure 1-3 provides more detail on the steps, techniques, and deliver- ables that are included in each phase of the SDLC and outlines how these topics are covered in this textbook. Figures 1-2 and 1-3 suggest that the SDLC phases proceed in a logical path from start to finish. In some projects, this is true. In many projects, however, the project team moves through the steps consecutively, incrementally, iteratively, or in Planning Analysis Design Implementation Idea System Success FIGURE 1-2 The Systems Development Life Cyclec01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 12 12 Chapter 1 The Systems Analyst and Information Systems Development Phase Chapter Step Technique Deliverable Planning 1 Identify opportunity Project identification System request Focus: Why build 1 Analyze feasibility Technical feasibility Feasibility study this system? Economic feasibility How to structure Organizational feasibility the project? 2 Develop workplan Time estimation Project plan Primary outputs: Task identification — work plan — System Request with Work breakdown structure feasibility study PERT chart — Project plan Gantt chart Scope management 2 Staff project Project staffing — Staffing plan Project charter 2 Control and direct project CASE repository — Standards list Standards — Risk assessment Documentation Timeboxing Risk management Analysis 3 Develop analysis strategy Business process automation System proposal Focus: Who, what, Business process improvement where, and when for Business process reengineering this system? 3 Determine business Interview — Requirements definition Primary output requirements JAD session — System proposal Questionnaire Document analysis Observation 4 Create use cases Use case analysis — Use cases 5 Model processes Data flow diagramming — Process models 6 Model data Entity relationship modeling — Data model Normalization Design 7 Design physical system Design strategy Alternative matrix Focus: How will this System specification system work? 8 Design architecture Architecture design — Architecture report Primary output: Hardware & software selection — Hardware & software specification — System specification 9 Design interface Use scenario — Interface design Interface structure Interface standards Interface prototype Interface evaluation 10 Design programs Data flow diagramming — Physical process model Program structure chart — Program design Program specification 11 Design databases and files Data format selection — Database & file specification Entity relationship modeling — Physical data model Denormalization Performance tuning Size estimation Implementation 12 Construct system Programming Test plan Focus: delivery and Software testing Programs support of completed Performance testing Documentation system Migration plan Primary output: 13 Install system Conversion strategy selection — Conversion plan — Installed system — Business contingency plan Training — Training plan 13 Maintain system Support selection Support plan System maintenance Problem report Project assessment Change request 13 Post-implementation Post-implementation audit Post-implementation audit report FIGURE 1-3 Systems Development Life Cycle Phasesc01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 13 The Systems Development Life Cycle 13 other patterns. Different projects may emphasize different parts of the SDLC or approach the SDLC phases in different ways, but all projects have elements of these four phases. For now, there are two important points to understand about the SDLC. First, you should get a general sense of the phases and steps that IS projects move through and some of the techniques that produce certain deliverables. In this section, we provide an overview of the phases, steps, and some of the techniques that are used to accomplish the steps. Second, it is important to understand that the SDLC is a process of gradual refinement. The deliverables produced in the analysis phase pro- vide a general idea what the new system will do. These deliverables are used as input to the design phase, which then refines them to produce a set of deliverables that describes in much more detailed terms exactly how the system should be built. These deliverables in turn are used in the implementation phase to guide the creation of the actual system. Each phase refines and elaborates on the work done previously. Planning The planning phase is the fundamental process of understanding why an informa- tion system should be built and determining how the project team will go about building it. It has two steps: 1. During project initiation, the system’s business value to the organization is identified—how will it lower costs or increase revenues? Most ideas for new sys- tems come from outside the IS area (from the marketing department, accounting department, etc.) in the form of a system request. A system request presents a brief summary of a business need, and it explains how a system that supports the need will create business value. The IS department works together with the per- son or department generating the request (called the project sponsor) to conduct a feasibility analysis. The feasibility analysis examines key aspects of the pro- posed project: ■ The technical feasibility (Can we build it?) ■ The economic feasibility (Will it provide business value?) ■ The organizational feasibility (If we build it, will it be used?) The system request and feasibility analysis are presented to an information sys- tems approval committee (sometimes called a steering committee), which decides whether the project should be undertaken. 2. Once the project is approved, it enters project management. During project management, the project manager creates a work plan, staffs the project, and puts techniques in place to help the project team control and direct the proj- ect through the entire SDLC. The deliverable for project management is a project plan that describes how the project team will go about developing the system. Analysis The analysis phase answers the questions of who will use the system, what the sys- tem will do, and where and when it will be used. (See Figure 1-3.) During this phase, the project team investigates any current system(s), identifies improvementc01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 14 14 Chapter 1 The Systems Analyst and Information Systems Development opportunities, and develops a concept for the new system. This phase has three steps: 1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy usually includes a study of the current system (called the as-is system) and its problems, and envisioning ways to design a new system (called the to-be system). 2. The next step is requirements gathering (e.g., through interviews, group work- shops, or questionnaires). The analysis of this information—in conjunction with input from the project sponsor and many other people—leads to the development of a concept for a new system. The system concept is then used as a basis to develop a set of business analysis models that describes how the business will operate if the new system were developed. The set typically includes models that represent the data and processes necessary to support the underlying business process. 3. The analyses, system concept, and models are combined into a document called the system proposal, which is presented to the project sponsor and other key decision makers (e.g., members of the approval committee) who will decide whether the project should continue to move forward. The system proposal is the initial deliverable that describes what business requirements the new system should meet. Because it is really the first step in the design of the new system, some experts argue that it is inappropriate to use the term analysis as the name for this phase; some argue a better name would be analysis and initial design. Because most organizations continue to use the name analysis for this phase, we will use it in this book as well. It is important to remember, how- ever, that the deliverable from the analysis phase is both an analysis and a high-level initial design for the new system. Design The design phase decides how the system will operate in terms of the hardware, software, and network infrastructure that will be in place; the user interface, forms, and reports that will be used; and the specific programs, databases, and files that will be needed. Although most of the strategic decisions about the system are made in the development of the system concept during the analysis phase, the steps in the design phase determine exactly how the system will operate. The design phase has four steps: 1. The design strategy must be determined. This clarifies whether the system will be developed by the company’s own programmers, whether its development will be outsourced to another firm (usually a consulting firm), or whether the com- pany will buy an existing software package. 2. This leads to the development of the basic architecture design for the system that describes the hardware, software, and network infrastructure that will be used. In most cases, the system will add to or change the infrastructure that already exists in the organization. The interface design specifies how the users will move through the system (e.g., by navigation methods such as menus and on-screen buttons) and the forms and reports that the system will use.c01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 15 Project Identification and Initiation 15 3. The database and file specifications are developed. These define exactly what data will be stored and where they will be stored. 4. The analyst team develops the program design, which defines the programs that need to be written and exactly what each program will do. This collection of deliverables (architecture design, interface design, database and file specifications, and program design) is the system specification that is used by the programming team for implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another decision is made by the project sponsor and approval committee about whether to terminate the project or continue. (See Figure 1-3.) Implementation The final phase in the SDLC is the implementation phase, during which the system is actually built (or purchased, in the case of a packaged software design and installed). This is the phase that usually gets the most attention, because for most systems it is the longest and most expensive single part of the development process. This phase has three steps: 1. System construction is the first step. The system is built and tested to ensure that it performs as designed. Since the cost of fixing bugs can be immense, test- ing is one of the most critical steps in implementation. Most organizations spend more time and attention on testing than on writing the programs in the first place. 2. The system is installed. Installation is the process by which the old system is turned off and the new one is turned on. There are several approaches that may be used to convert from the old to the new system. One of the most important aspects of conversion is the training plan, used to teach users how to use the new system and help manage the changes caused by the new system. 3. The analyst team establishes a support plan for the system. This plan usually includes a formal or informal post-implementation review, as well as a systematic way for identifying major and minor changes needed for the system. PROJECT IDENTIFICATION AND INITIATION Where do project ideas come from? A project is identified when someone in the organization identifies a business need to build a system. Examples of business needs include supporting a new marketing campaign, reaching out to a new type of customer, or improving interactions with suppliers. Sometimes, needs arise from some kind of “pain” within the organization, such as a drop in market share, poor customer service levels, unacceptable product defect rates, or increased com- petition. New business initiatives and strategies may be created and a system to support them is required, or a merger or acquisition may require systems to be integrated. Business needs also can surface when the organization identifies unique and competitive ways of using IT. Many organizations keep an eye on emerging tech- nology, which is technology that is still being developed and not yet viable forc01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/22/11 10:41 AM Page 16 16 Chapter 1 The Systems Analyst and Information Systems Development widespread business use. For example, if companies stay abreast of technological advances such as cloud computing, RFID (radio frequency identification), or Web 2.0, they can develop business strategies that leverage the capabilities of these tech- nologies and introduce them into the marketplace as a first mover. Ideally, companies can take advantage of this first mover position by making money and continuing to innovate while competitors trail behind. Today, many new information system projects grow out of business process management (BPM) initiatives. BPM is a methodology used by organizations to continuously improve end-to-end business processes. Business process manage- ment can be applied to internal organizational processes and to processes spanning multiple business partners. By studying and improving their underlying business processes, organizations can achieve several important benefits, including: ■ enhanced process agility, giving the organization the ability to adapt more rap- idly and effectively to a changing business environment; ■ improved process alignment with industry “best practices”; and ■ increased process efficiencies as costs are identified and eliminated from process workflows. BPM generally follows a continuous cycle of systematically creating, assess- ing, and altering business processes. Business analysts, with their in-depth business knowledge, play a particularly important role in business process management by: 1. defining and mapping the steps in a business process, 2. creating ways to improve on steps in the process that add value, 3. finding ways to eliminate or consolidate steps in the process that don’t add value, 4. creating or adjusting electronic workflows to match the improved process maps. The last step is particularly relevant to our discussion since the need for infor- mation systems projects is frequently identified here. In fact, the automation of business processes (termed Business Process Automation), is the foundation of many information technology systems. In these situations, technology components are used to complement or substitute for manual information management processes with the intent of gaining cost efficiencies. BPM practitioners recognize, however, that it is not always advisable to just “pave the cow paths” by simply adding automation to speed up existing processes (step 4 above). In many situations, Business Process Improvement results from studying the business processes, creating new, redesigned processes to improve the process workflows, and/or utilizing new technologies enabling new process struc- tures (steps 2, 3, and 4 above). For example, could a retail store’s checkout process be redesigned along the lines of the EZPass toll collection system on highways? Could customers check out and pay with their mobile devices while clerks simply review the contents of the customer’s shopping bag? Projects with a goal of business process improvement make moderate changes to the organization’s operations, and can improve efficiency (i.e., doing things right) and improve effectiveness (i.e., doing the right things). These types of projects involve more risk than business process automation projects since more significant changes are made to the organization’s operations. Business Process Management may also reveal the need for the complete revamping of the organization’s business processes, termed Business Processc01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/22/11 10:42 AM Page 17 Project Identification and Initiation 17 CONCEPTS 1-B SUCCESS FROM FAILURE . . . EVENTUALLY IN ACTION A project to streamline the work of are in this together, or we fail together.” In addition, it the Commonwealth of Massachusetts Senate and House was a time of relative political harmony—both the House of Representatives ended in failure. Ed Bell, veteran CIO and Senate got along. from the financial services industry, was hired as a Via an intranet, the new system provides workflow consultant to assess the failed project and advise how to alerts and to-do lists, so legislators know what is required proceed. of them as bills pass through the legislative process. After studying the situation, Bell recommended There is also a completely revamped public website that stepping back and re-thinking the entire situation. Bell will enable the public to stay informed of legislative embarked on a project that would create a platform for action nearly real time. the future and integrate all the workflow processes of the Bell recognized that the legislative process is built Massachusetts Senate and House. Having just experi- on relationships and connections. His vision for the sys- enced a project failure, legislative leaders and their staffs tem was not to try and change the way the legislative were more open-minded to the changes Bell proposed. process works, but to complement it. Bell emphasized educating the senior leadership team on what IT does, what a software development life cycle is, Linda Tucci, “Business process automation for the business’ what the roles of a project involve, and stressed that “we sake.” SearchCIO.com, Sept. 30, 2010. Reengineering (BPR). BPR means changing the fundamental way in which the organization operates—“obliterating” the current way of doing business and mak- ing major changes to take advantage of new ideas and new technology. As you might expect, BPR projects involve substantial risk due to the significant organiza- tional and operational changes that result. Top management support and careful management are critical in these fairly rare types of projects. Both IT people (i.e., the information systems experts) and business people (i.e., the subject matter experts) should work closely together to find ways for tech- nology to support business needs. In this way, organizations can leverage the exciting technologies available while ensuring that projects are based upon real business objectives such as increasing sales, improving customer service, and decreasing operating expenses. Ultimately, information systems need to affect the organization’s bottom line (in a positive way). When a strong business need for an information system is recognized, often as a result of BPM, a person (or group) who has an interest in the system’s success typ- ically steps forward. We call this person (or group) the project sponsor. Often, the project sponsor develops the initial vision of the new system. The project sponsor works throughout the SDLC to make sure that the project is moving in the right direc- tion from the perspective of the business and serves as the primary point of contact for the project team. Usually, the sponsor of the project is from a business function such as marketing, accounting, or finance; however, members of the IT area also can sponsor or cosponsor a project. The size or scope of the project often determines the kind of sponsor who is involved. A small, departmental system might be sponsored by a single manager; however, a large, organizational initiative might be sponsored by the entire senior management team and even the CEO. If a project is primarily technical in nature (e.g., improvements to the existing IT infrastructure or research into the viability of an emerging technology), then sponsorship from IT is appropriate. When projectsc01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 18 18 Chapter 1 The Systems Analyst and Information Systems Development YOUR 1-2 IMPLEMENTING A SATELLITE DATA NETWORK TURN A major retail store recently spent Midwest to start selling high-end (and high-profit) snow 24 million dollars on a large private satellite communi- throwers quite quickly, the company’s nearest warehouse cation system that provides state-of-the-art voice, data, can prepare next-day shipments to maintain a good and video transmission between stores and regional inventory balance, while the competitor may not move headquarters. When an item gets sold, the scanner soft- quite as quickly and thus lose out on such quick inventory ware updates the inventory system in real time. As a turnover. result, store transactions are passed on to regional and national headquarters instantly, which keeps inventory QUESTIONS: records up to date. One of the store’s major competitors 1. Do you think a 24 million investment in a private has an older system in which transactions are uploaded satellite communication system could be justified by at the end of a business day. The first company feels that a cost-benefit analysis? Could this be done with a its method of instant communication and feedback allows standard communication line (with encryption)? it to react more quickly to changes in the market, giving 2. How might the competitor attempt to close the “infor- the company a competitive advantage. For example, if mation gap” in this example? an early winter snowstorm causes stores across the upper have great importance to the business, yet are technically complex, joint sponsor- ship by both the business and IT functions may be necessary. The business need drives the high-level business requirements for the system. Business requirements describe the reasons for developing the system and outline the benefits it will provide the organization. These requirements need to be explained at a high level so that the approval committee and, ultimately, the project team under- stand what the business expects from the final product. Business requirements sum- marize the features and capabilities the information system will have to include, such as the ability to collect customer orders online or the ability for suppliers to receive inventory information as orders are placed and sales are made. The project sponsor has the insights needed to determine the business value that will be gained from the system, in both tangible and intangible ways. Tangible value can be quantified and measured easily (e.g., 2% reduction in operating costs). An intangible value results from an intuitive belief that the system provides impor- tant, but hard-to-measure, benefits to the organization (e.g., improved customer service, a better competitive position). Once the project sponsor identifies a project that meets an important business need and he or she can identify the business requirements and business value of the system, it is time to formally initiate the project. In most organizations, project initiation begins by preparing a system request. System Request A system request is a document that describes the business reasons for building a system and the value that the system is expected to provide. The project sponsor usually completes this form as part of a formal system project selection process within the organization. Most system requests include five elements: project spon- sor, business need, business requirements, business value, and special issues. (See Figure 1-4.) The sponsor describes the person who will serve as the primary contactc01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 19 Project Identification and Initiation 19 Element Description Examples Project Sponsor The person who initiates the Several members of the finance project and who serves as the department primary point of contact for the Vice president of marketing project on the business side IT manager Steering committee CIO CEO Business Need The business-related reason for Increase sales initiating the system Improve market share Improve access to information Improve customer service Decrease product defects Streamline supply acquisition processes Business Requirements The business capabilities that the Provide onIine access to information system will provide Capture customer demographic information Include product search capabilities Produce management reports Include online user support Business Value The benefits that the system will 3% increase in sales create for the organization 1% increase in market share Reduction in headcount by 5FTEs 200,000 cost savings from decreased supply costs 150,000 savings from removal of existing system Special Issues or Issues that are relevant to the Government-mandated deadline Constraints implementation of the system for May 30 that need to be known by the System needed in time for the approval committee Christmas holiday season Top-level security clearance needed by project team to work with data FIGURE 1-4  Full-time equivalent Elements of the System Request Form CONCEPTS 1-C INTERVIEW WITH DON HALLACY, PRESIDENT, TECHNOLOGY SERVICES, SPRINT CORPORATION IN ACTION At Sprint, network projects originate for technology, training, and development costs; and create from two vantage points—IT and the business units. IT a business case. This business case contains the economic projects usually address infrastructure and support needs. value added and the net present value of the project. The business-unit projects typically begin after a business Of course, not all projects undergo this rigorous need is identified locally, and a business group informally process. The larger projects require more time to be allo- collaborates with IT regarding how a solution can be cated to the analysis team. It is important to remain flexible delivered to meet customer expectations. and not let the process consume the organization. At the Once an idea is developed, a more formal request beginning of each budgetary year, specific capital expen- process begins, and an analysis team is assigned to inves- ditures are allocated for operational improvements and tigate and validate the opportunity. This team includes maintenance. Moreover, this money is set aside to fund members from the user community and IT, and they scope quick projects that deliver immediate value without going out at a high level what the project will do; create estimates through the traditional approval process. Don Hallacyc01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 20 20 Chapter 1 The Systems Analyst and Information Systems Development for the project, and the business need presents the reasons prompting the project. The business requirements of the project refer to the business capabilities that the sys- tem will need to have, and the business value describes the benefits that the organ- ization should expect from the system. Special issues are included on the document as a catchall category for other information that should be considered in assessing the project. For example, the project may need to be completed by a specific dead- line. Project teams need to be aware of any special circumstances that could affect the outcome of the system. The completed system request is submitted to the approval committee for consideration. This approval committee could be a company steering committee that meets regularly to make information systems decisions, a senior executive who has control of organizational resources, or any other decision-making body that governs the use of business resources. The committee reviews the system request and makes an initial determination, based on the information provided, of whether to investigate the proposed project or not. If so, the next step is to conduct a feasi- bility analysis. Applying the Concepts at Tune Source Throughout the book, we will apply the concepts in each chapter to a fictitious com- pany called Tune Source. For example, in this section, we will illustrate the creation of a system request. Tune Source is a company headquartered in southern California. Tune Source is the brainchild of three entrepreneurs with ties to the music industry: John Margolis, Megan Taylor, and Phil Cooper. Originally, John and Phil partnered to open a number of brick and mortar stores in southern California specializing in hard-to-find and classic jazz, rock, country, and folk recordings. Megan soon was YOUR 1-3 TOO MUCH PAPER, PART 1 TURN The South Dakota Department of were small—possibly documenting a minor cut or minor Labor, Workers’ Compensation division was sinking injury, and the employee was back to work after a brief under a load of paper files. As a state agency which treatment period. Other folders could be very large, with ascertains that employees are treated fairly when they numerous medical reports from several doctors verifying are injured on the job, the agency had a plethora of the extent of a serious injury and treatment (such as an arm paper files and filing cabinets. If a person (or company) amputation). A digital solution was suggested—reports called to see the status of an injury claim, the clerk who could be submitted online via a secure website. Medical received the call would have to take a message, get the reports could be submitted electronically, either as a pdf paper file, review the status, and call the person back. file or as a faxed digital file. This solution would also Files were stored in huge filing cabinets and were mean that the clerk taking the phone call could query the entered by year and case number (for example, the database by the person’s name and access the informa- 415th person injured in 2008 would be in a file num- tion in a matter of seconds. bered 08-415). But most callers did not remember the file number and would give their name and address and the QUESTION: date of injury. The clerk would look in a spiral notebook Prepare a systems request for this project. Fill in as much for the last name around the date that was given—and as you can on the basis of the information provided. then find the file number to retrieve the folder. Some foldersc01TheSystemsAnalystAndInformationSystemsDevelopment.qxd 9/21/11 11:14 AM Page 21 Project Identification and Initiation 21 invited to join the partnership because of her contacts and knowledge of classical music. Tune Source quickly became known as the place to go to find rare audio recordings. Annual sales last year were 40 million with annual growth at about 3%–5% per year. Background John, Megan, and Phil, like many others in the music industry, watched with alarm the rise of music-sharing websites like Napster, as music con- sumers shared digital audio files without paying for them, denying artists and record labels royalties associated with sales. Once the legal battle over copyright infringement was resolved and Napster was shut down, the partners set about estab- lishing agreements with a variety of industry partners in order to offer a legitimate digital music download resource for customers in their market niche. Phil has asked Carly Edwards, a rising star in the Tune Source marketing department, to spearhead the digital music download project. Tune Source currently has a website that enables customers to search for and purchase CDs. This site was initially developed by an Internet consulting firm and is hosted by a prominent local Internet Service Provider (ISP) in Los Angeles. The IT department at Tune Source has become experienced with Internet technology as it has worked with the ISP to maintain the site. System Request At Tune Source, new IT projects are reviewed and approved by a project steering committee that meets quarterly. The committee has representatives from IT as well as from the major areas of the business. Carly’s first step was to pre- pare a system request for the committee. Figure 1-5 shows the system request she prepared. The project sponsor is Carly, and the business needs are to increase sales and provide a music download capability demanded by a very competitive marketplace. Notice that the need does not focus on the technology associated with the project. The emphasis is on the business aspects: increasing sales and maintaining a competitive position in the company’s market. In the system request, the project sponsor focuses on describing his or her vision of the business requirements at a very high level. Carly has expressed a clear vision of how this system will affect Tune Source: sales of individual music downloads, revenue from customer subscriptions, sales from cross-selling of CDs, and sales of music download gift cards. Carly acknowledges customer demand for this capability and also recognizes the need to respond to this demand in order to retain the business of its loyal customer base. The estimates of tangible value were difficult to develop, since this venture is completely new to Tune Source. To prepare for this, Carly had several of her staff members conduct both an in-store customer survey and an online customer survey to assess the customers’ interest in individual music downloads, subscription programs, and gift cards. The surveys also attempted to gauge the customers’ price sensitivity for these offerings. From the survey results, Carly and her staff developed a range of sales pro- jections for the various revenue streams: a high-level estimate, a medium-level estimate, and low-level estimate. They also developed probability assessments for each of these outcomes, settling on a 25% likelihood for the high-level esti- mate, a 60% likelihood for the medium-level estimate, and a 15% likelihood for the low-level estimate. Based on the sales projections and the probability esti- mates, a weighted average estimated sales figure was computed for each revenue stream.

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.