Chapter 11 INF Systems Analysis PDF

11 Systems Analysis Principles Learning Objectives Effective systems development requires...

11 Systems Analysis Principles Learning Objectives Effective systems development requires Identify the key participants in the systems development a team effort from stakeholders, users, process and discuss their roles. managers, systems development Define the term ‘information systems’ and ‘planning’ and specialists and various support list several reasons for initiating a systems project. personnel, and it starts with careful Discuss three trends that illustrate the impact of planning. enterprise resource planning software packages on systems development. Systems development often uses tools to Discuss the key features, advantages and select, implement and monitor projects, disadvantages of the traditional, prototyping, rapid including prototyping, rapid application application development and end-user systems development, CASE tools and object- development lifecycles. oriented development. Identify several factors that influence the success or failure of a systems development project. Discuss the use of CASE tools and the object-oriented approach to systems development. Systems development starts with State the purpose of systems investigation. investigation and analysis of existing Discuss the importance of performance and cost systems. objectives. State the purpose of systems analysis and discuss some of the tools and techniques used in this phase of systems development. 367 Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it. 368 PART 4 SYSTEMS DEVELOPMENT Why Learn About Throughout this book, you have seen many examples of the use of information systems. But where do these systems come from? Systems Analysis? How can you work with IS personnel, such as systems analysts and computer programmers, to get what you need to succeed on the job? This chapter, the first of two chapters on systems development, gives you the answer. You will see how managers can initiate the systems development process and analyze end users’ needs with the help of IS personnel. Systems investigation and systems analysis are the first two steps of the systems development process. This chapter provides specific examples of how new or modified systems are initiated and analyzed in a number of industries. In this chapter, you will learn how your project can be planned, aligned with corporate goals, rapidly developed and much more. The main thrust of this chapter and the next is about a company building its own information systems from scratch. However, in the next chapter we will look at alternatives to this – buying in a system that someone else has already built. We start with an overview of the systems development process. 11.1 An Overview of Systems Development In today’s businesses, managers and employees in all functional areas work together and use business information systems. Because they are central to project success, users are helping with development and, in many cases, leading the way. Users might request that a systems development team determine whether they should purchase a few PCs, update an existing order processing system, develop a new medical diagnostic or design and implement a new website. In other cases, systems development might involve purchasing or leasing a system such as an enterprise resource planning (ERP) package (discussed in Chapter 7). This chapter and the next provide you with a deeper appreciation of the systems development process and show how businesses can avoid costly failures. Calculating the cost of an IT project is difficult and a number of high-profile mistakes have been made. Most of these are from the public sector (as any mistakes from the private sector are quickly covered up!). In the UK there have been IT problems and soaring costs with the system for issuing passports, the system managing benefit payments and the system managing patient data in the National Health Service. Not all of these problems have been technical. The new National Health Service information sharing system was delayed because of problems caused by a lack of communication with patients.1 There was widespread criticism that the public had been left in the dark about the project. Participants in systems development, in this case government health ministers, hospital managers, doctors and patient groups, are critical to systems development success. Participants in Systems Development Effective systems development requires a team effort. The team usually consists of users, 11 managers, systems development specialists, various support personnel and other stakeholders. This team, called the development team, is responsible for determining the objectives of the new information system and delivering a system that meets these objectives. Many development teams use a project manager to head the systems development effort and to help coordinate the systems development process. A project is a planned collection of activities that achieves a goal, such as constructing a new manufacturing plant or developing a new decision support system.2 All projects should have a defined starting point and ending point, normally given as a specific date. Most have a set budget, such as €150,000. The project manager is responsible for coordinating all people and resources needed to complete the project on time. In systems development, the project manager can be an IS person inside the organization or an external Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.  CHAPTER 11 SYSTEMS ANALYSIS 369 consultant hired to see the project to completion. Project managers need technical, business and people skills. In addition to completing the project on time and within the specified budget, the project manager is usually responsible for controlling project quality, training personnel, facilitating communication, managing risks and acquiring any necessary equipment, including office supplies and sophisticated computer systems. One study reported that almost 80 per cent of responding IS managers believe that it is critical to keep project planning skills in-house instead of outsourcing them.3 Research studies have shown that project management success factors include good leadership from executives and project managers, a high level of trust in the project and its potential benefits, and the commitment of the project team and organization to successfully complete the project and implement its results. In the context of systems development, stakeholders are people who, either themselves or through the area of the organization they represent, ultimately benefit from the systems development project. Users are people who will interact with the system regularly. They can be employees, managers or suppliers. For large-scale systems development projects, where the investment in and value of a system can be high, it is common for senior-level managers, including the heads of functional areas (finance, marketing and so on), to be part of the development team. Depending on the nature of the systems project, the development team might include systems analysts and programmers, among others. A systems analyst is a professional who specializes in analyzing and designing business systems. Systems analysts play various roles while interacting with the users, management, vendors and suppliers, external companies, programmers and other IS support personnel (see Figure 11.1). Sometimes systems analysts work with specialist business analysts, experts in the business who try to identify ways in which new information systems can improve the current business processes. Like an architect developing blueprints for a new building, a systems analyst develops detailed plans for the new or modified system. The programmer is responsible for modifying or developing programs to satisfy user requirements. Like a contractor constructing a new building or renovating an existing one, the programmer takes the plans from the systems analyst and builds or modifies the necessary software. Figure 11.1 Role of the Systems Analyst The systems analyst plays an important role in the development team and is often the only person who sees the system in its totality. The systems Managers analyst is often called on to be a facilitator, moderator, negotiator and interpreter for development activities. 11 Users Software programmers Systems analyst Vendors and suppliers Technical specialists Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it. 370 PART 4 SYSTEMS DEVELOPMENT The other support personnel on the development team are mostly technical specialists, including database and telecommunications experts, hardware engineers and supplier representatives. One or more of these roles might be outsourced to outside experts. Depending on the magnitude of the systems development project and the number of IS systems development specialists on the team, one or more IS managers might also belong to the team. The composition of a development team can vary over time and from project to project. For small businesses, the development team might consist of a systems analyst and the business owner as the primary stakeholder. For larger organizations, IS staff can include hundreds of people involved in a variety of activities, including systems development. Every development team should have a team leader. This person can be from the IS department, a manager from the company or a consultant from outside the company. The team leader needs both technical and people skills. Regardless of the specific nature of a project, systems development creates or modifies systems, which ultimately means change. Managing this change effectively requires development team members to communicate well. Because you probably will participate in systems development during your career, you must learn communication skills. You might even be the individual who initiates systems development. Typical reasons for initiating IS projects are given in Table 11.1. Table 11.1 Typical Reasons to Initiate a Systems Development Project Reason Example Problems with existing system Not processing orders fast enough Desire to exploit new opportunities M-commerce Increasing competition New competitor enters industry Desire to make more effective use of information Wanting to set up a customer relationship management system to expand and exploit information stored on customers Organizational growth Expanding customer base Merger or acquisition Buying out a competitor Change in the environment New regulations imposed by government Information Systems Planning and Aligning Organization and IS Goals 11 The term information systems planning refers to translating strategic and organizational goals into systems development initiatives. The chief information officer (CIO) of the Marriott Hotel chain, for example, attends board meetings and other top-level management meetings so that he is familiar with, and can contribute to, the firm’s strategic plan. According to Doug Lewis, former CIO for many Fortune 100 companies, ‘strategic goals must be finite, measurable and tangible’. Proper IS planning ensures that specific systems development objectives support organizational goals. Aligning organizational goals and IS goals is critical for any successful systems development effort.4 Because information systems support other business activities, IS staff and people in Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.  CHAPTER 11 SYSTEMS ANALYSIS 371 other departments need to understand each other’s responsibilities and tasks. Determining whether organizational and IS goals are aligned can be difficult. One of the primary benefits of IS planning and alignment of business goals is a long-range view of information systems use in the organization. The IS plan should guide the development of the IS infrastructure over time. IS planning should ensure better use of IS resources – including funds, personnel and time for scheduling specific projects. The steps of IS planning are shown in Figure 11.2. Figure 11.2 The Strategic plan Steps of IS Planning Some projects are identified through overall IS objectives, whereas additional projects, called ‘unplanned projects’, Develop overall are identified from other objectives sources. All identified projects are then evaluated in terms of their organizational priority. Previously unplanned Identify IS projects systems projects Set priorities and select projects Analyze resource requirements Set schedules and deadlines Develop IS planning document 11 In today’s business environment, many companies seek systems development projects that will provide them with a competitive advantage. Thinking competitively usually requires creative and critical analysis. For example, a company might want to achieve a competitive advantage by improving its customer–supplier relationship. Linking customers and suppliers electronically can result in more efficient communication and, ultimately, superior products and services. By looking at problems in new or different ways and by introducing innovative methods to solve them, many organizations have gained significant advantages. In some cases, these new solutions are inspired by people and things not directly related to the problem. Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it. 372 PART 4 SYSTEMS DEVELOPMENT creative analysis The Creative analysis involves investigating new approaches to existing investigation of new approaches to problems. Typically, new solutions are inspired by people and events not existing problems. directly related to the problem. Critical analysis requires unbiased and critical analysis The unbiased careful questioning of whether system elements are related in the most and careful questioning of whether effective ways. It involves considering the establishment of new or different system elements are related in the most effective ways. relationships between system elements and perhaps introducing new elements into the system. Critical analysis in systems development involves the following actions: Questioning statements and assumptions. Questioning users about their needs and clarifying their initial responses can result in better systems and more accurate predictions. Too often, stakeholders and users specify certain system requirements because they assume that their needs can only be met that way. Often, an alternative approach would be better. For example, a stakeholder might be concerned because there is always too much of certain items in stock and not enough of other items. So, the stakeholder might request a new and improved inventory control system. An alternative approach is to identify the root cause of poor inventory management. This latter approach might determine that sales forecasting is inaccurate and needs improvement or that production cannot meet the set production schedule. All too often, solutions are selected before understanding the complete nature of the problem. Identifying and resolving objectives and orientations that conflict. Each department in an organization can have different objectives and orientations. The buying department might want to minimize the cost of spare parts by always buying from the lowest- cost supplier, but engineering might want to buy more expensive, higher quality spare parts to reduce the frequency of replacement. These differences must be identified and resolved before a new purchasing system is developed or an existing one modified. Establishing Objectives for Systems Development The overall objective of systems development is to achieve business goals, not technical goals, by delivering the right information to the right person at the right time. The impact a particular system has on an organization’s ability to meet its goals determines the true value of that system to the organization. Although all systems should support business goals, some systems are more pivotal in continued operations and goal attainment than others. These systems are called ‘key operational’. An order processing system, for example, is key operational. Without it, few organizations could continue daily activities, and they clearly would not meet set goals. The goals defined for an organization also define the objectives that are set for a system. A manufacturing plant, for example, might determine that minimizing the total cost of owning and operating its equipment is critical to meeting production and profit goals. Critical success factors 11 (CSFs) are factors that are essential to the success of certain functional areas of an organization. The CSF for manufacturing – minimizing equipment maintenance and operating costs – would be converted into specific objectives for a proposed system. One specific objective might be to alert maintenance planners when a piece of equipment is due for routine preventative maintenance (e.g. cleaning and lubrication). Another objective might be to alert the maintenance planners when the necessary cleaning materials, lubrication oils or spare parts inventory levels are below specified limits. These objectives could be accomplished either through automatic stock replenishment or through the use of exception reports. Regardless of the particular systems development effort, the development process should define a system with specific performance and cost objectives. The success or failure of the systems development effort will be measured against these objectives. Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.  CHAPTER 11 SYSTEMS ANALYSIS 373 Performance Objectives The extent to which a system performs as desired can be measured through its performance objectives. System performance is usually determined by factors such as the following: The quality or usefulness of the output. Is the system generating the right information for a value-added business process or a goal-oriented decision maker? The accuracy of the output. Is the output accurate and does it reflect the true situation? As a result of the Enron accounting scandal in the USA and similar instances when some companies overstated revenues or understated expenses, accuracy is becoming more important, and business leaders throughout the world are being held responsible for the accuracy of all corporate reports. The quality or usefulness of the format of the output. Is the output generated in a form that is usable and easily understood? For example, objectives often concern the legibility of screen displays, the appearance of documents and the adherence to certain naming conventions. The speed at which output is generated. Is the system generating output in time to meet organizational goals and operational objectives? Objectives such as customer response time, the time to determine product availability and throughput time are examples. The scalability of the resulting system. Scalability allows an information system to handle business growth and increased business volume. For example, if a mid-sized business realizes an annual 10 per cent growth in sales for several years, an information system that is scalable will be able to efficiently handle the increase by adding processing, storage, software, database, telecommunications and other information systems resources to handle the growth. The degree to which business risk is reduced. One important objective of many systems development projects is to reduce risk.5 The BRE Bank in Poland, for example, used systems development to create a model-based decision support system to analyze and reduce loan risk and a variety of related risks associated with bank transactions. The new project uses a mathematical algorithm, called FIRST (financial institutions risk scenario trends), to reduce risk. In some cases, the achievement of performance objectives can be easily measured (e.g. by tracking the time it takes to determine product availability). In other cases, it is sometimes more difficult to ascertain in the short term. For example, it might be difficult to determine how many customers are lost because of slow responses to customer enquiries regarding product availability. These outcomes, however, are often closely associated with business goals and are vital to the long-term success of the organization. Senior management usually dictates their attainment. Cost Objectives Organizations can spend more than is necessary during a systems development project. The benefits of achieving performance goals should be balanced with all costs associated with the system, including the following: Development costs. All costs required to get the system up and running should be included. Some computer vendors give cash rewards to companies using their systems 11 to reduce costs and as an incentive.6 Costs related to the uniqueness of the system application. A system’s uniqueness has a profound effect on its cost. An expensive but reusable system might be preferable to a less costly system with limited use. Fixed investments in hardware and related equipment. Developers should consider costs of such items as computers, network-related equipment and environmentally controlled data centres in which to operate the equipment. Ongoing operating costs of the system. Operating costs include costs for personnel, software, supplies and resources such as the electricity required to run the system. Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it. 374 PART 4 SYSTEMS DEVELOPMENT Balancing performance and cost objectives within the overall framework of organizational goals can be challenging. Setting objectives is important, however, because they allow an organization to allocate resources effectively and measure the success of a systems development effort. 11.2 Systems Development Lifecycles The systems development process is also called the ‘systems development lifecycle’ (SDLC) because the activities associated with it are ongoing. As each system is built, the project has timelines and deadlines until the system is installed and accepted. The life of the system then continues as it is maintained and reviewed. If the system needs significant improvement beyond the scope of maintenance, or if it needs to be replaced because of a new generation of technology, or if the IS needs of the organization change significantly, a new project will be initiated and the cycle will start over. A key fact of systems development is that the later in the SDLC an error is detected, the more expensive it is to correct (see Figure 11.3). One reason for the mounting costs is that if an error which occurred in a early stage of the SDLC isn’t found until a later phase, the previous phases must be reworked to some extent. Another reason is that the errors found late in the SDLC affect more people. For example, an error found after a system is installed might require retraining users when a ‘work-around’ to the problem has been found. Thus, experienced systems developers prefer an approach that will catch errors early in the project lifecycle. Figure 11.3 Relationship Between Timing of Errors and Costs The later that Cost to make a particular change system changes are made in the SDLC, the more expensive these changes become. Investigation Analysis Design Implementation Maintenance and review Time Several common systems development lifecycles exist: the traditional or waterfall approach, 11 prototyping, rapid application development (RAD) and end-user development. In addition, companies can outsource the systems development process. With many companies and most public sector organizations, these approaches are formalized and documented so that systems developers have a well-defined process to follow; in other companies, less formalized approaches are used. Keep Figure 11.3 in mind as you are introduced to alternative SDLCs in the sections that follow. The Traditional Systems Development Lifecycle Traditional systems development efforts can range from a small project, such as purchasing an inexpensive computer program, to a major undertaking. The steps of traditional systems development might vary from one company to the next, but most approaches have five common Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.  CHAPTER 11 SYSTEMS ANALYSIS 375 phases: investigation, analysis, design, implementation, and maintenance and review (see Figure 11.4). Traditional systems development is also known as the waterfall approach. Figure 11.4 The Systems investigation Traditional Systems Development Lifecycle Understand the problem Sometimes information learned in a particular phase requires cycling Analysis back to a previous phase. Systems analysis Determine what must be done to solve the problem Systems design Design The solution is planned out Systems implementation The solution is built or bought, and replaces the old system Implementation Systems maintenance and review The new system is evaluated In the systems investigation phase, potential problems and opportunities are identified and considered in light of the goals of the business. Systems investigation attempts to answer the questions, ‘What is the problem?’ and ‘Is it worth solving?’ The primary result of this phase is a defined development project for which business problems or opportunity statements have been 11 created, to which some organizational resources have been committed, and for which systems analysis is recommended. Systems analysis attempts to answer the question, ‘What must the information system do to solve the problem?’ This phase involves studying existing systems and work processes to identify strengths, weaknesses and opportunities for improvement. The major outcome of systems analysis is a list of requirements and priorities. Systems design seeks to answer the question, ‘How will the information system do what it must do to obtain the problem solution?’ The primary result of this phase is a technical design that either describes the new system or describes how existing systems will be modified. The system design details system outputs, inputs and user interfaces; specifies hardware, software, database, telecommunications, personnel and procedure components; and shows how these components are related. Systems Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it. 376 PART 4 SYSTEMS DEVELOPMENT implementation involves creating or buying the various system components detailed in the systems design, assembling them and placing the new or modified system into operation. An important task during this phase is to train the users. Systems implementation results in an installed, operational information system that meets the business needs for which it was developed. The purpose of systems maintenance and review is to ensure that the system operates as intended and to modify the system so that it continues to meet changing business needs. As shown in Figure 11.4, a system under development moves from one phase of the traditional SDLC to the next. The traditional SDLC allows for a large degree of management control. However, a major problem is that the user does not use the solution until the system is nearly complete. Table 11.2 lists advantages and disadvantages of the traditional SDLC. Table 11.2 Advantages and Disadvantages of Traditional SDLC Advantages Disadvantages Formal review at the end of each phase Users get a system that meets the needs as allows maximum management control understood by the developers; this might not be what is really needed This approach creates considerable system Documentation is expensive and time consuming documentation to create. It is also difficult to keep current Formal documentation ensures that system Often, user needs go unstated or are misunderstood requirements can be traced back to stated business needs It produces many intermediate products that can be Users cannot easily review intermediate products and reviewed to see whether they meet the users’ needs evaluate whether a particular product (e.g. a data-flow and conform to standards diagram) meets their business requirements Prototyping Prototyping, also known as the evolutionary lifecycle, takes an iterative approach to the systems development process. During each iteration, requirements and alternative solutions to the problem are identified and analyzed, new solutions are designed and a portion of the system is implemented. Users are then encouraged to try the prototype and provide feedback (see Figure 11.5). Prototyping begins with creating a preliminary model of a major subsystem or a scaled-down version of the entire system. For example, a prototype might show sample report formats and input screens. After they are developed and refined, the prototypical reports and input screens are used as models for the actual system, which can be developed using an end-user programming language such as Visual Basic. The first preliminary model is refined to form the second- and third-generation models and so on until the complete system is developed. One potential problem with prototyping is knowing when the system is finished as people can 11 always think of extra refinements they would like. Prototypes can be classified as operational or non-operational. An operational prototype is a prototype that has functionality – it does something towards solving the problem. It may accept input, partially process it and output the results. Then, perhaps in the second iteration, the processing is refined and expanded. A non-operational prototype is a mock-up or model. It typically includes output and input specifications and formats. The outputs include mocked up reports and the inputs include the layout of the user interface either on paper or on a computer screen. The primary advantage of a non-operational prototype is that it can be developed much faster than an operational prototype. Non-operational prototypes can be discarded, and a fully operational system can be built based on what was learned from the prototypes. Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.  CHAPTER 11 SYSTEMS ANALYSIS 377 Analysis Figure 11.5 Prototyping Prototyping is an iterative approach to systems development. Iteration 3 Iteration 2 Iteration 1 Implementation Design The advantages and disadvantages of prototyping are summarized in Table 11.3. Prototypes can be useful communication tools – imagine asking a user what they need the new system to do. Many people may find it difficult to verbalize what they want. However, if you show them a prototype, they will soon be able to say what is right and wrong with it. Table 11.3 Advantages and Disadvantages of Prototyping Advantages Disadvantages Users can try the system and provide constructive Each iteration builds on the previous one. The final feedback during development solution might be only incrementally better than the initial solution An operational prototype can be produced in weeks Formal end-of-phase reviews might not occur. Thus, 11 it is very difficult to contain the scope of the prototype, and the project never seems to end As solutions emerge, users become more System documentation is often absent or incomplete positive about the process and the results because the primary focus is on development of the prototype Prototyping enables early detection of errors System back-up and recovery, performance and and omissions security issues can be overlooked in the haste to develop a prototype Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it. 378 PART 4 SYSTEMS DEVELOPMENT Information Systems @ Work Open-Source Software Conquers Data Science R is a specialist programming language designed developer SAS, Anne Milley said, ‘I think [R] to handle statistics and the creation of statistical addresses a niche market for high-end data graphs. It is open source and has rapidly become analysts that want free, readily available code. We one of the most popular computer languages for have customers who build engines for aircraft. I data manipulation. The R developers describe am happy they are not using freeware when I get it as an ‘environment’, by which they mean it is on a jet’. a full computer language that allows users to Her view seems to be shared by others in add additional functionality by writing their own industry who prefer to use proprietary software. functions and code. These can be written in R Perhaps they genuinely do not see the benefit of itself, but R also has features that easily allow it to having code that has been read, tested and vetted run code written in C and several other languages. by a community of users. Or perhaps industry just The real power of R for many users, is that it has wants to be able to sue somebody if it all goes an online repository where the best functions are wrong (like all open-source software, R comes with shared (they are called ‘packages’). R has tools absolutely no warranty of any kind, a message that built in that make it exceptionally easy for anyone is displayed prominently every time it is opened). to install these packages. However, SAS later seemed to soften their attitude For example, let’s say a user in Australia writes to R. They have changed their software to add a new package to analyze geographic data. They support for R, allowing data to flow between R use it themselves for a few months and decide that and SAS programs, and they began work on an it is useful. So they give it a name (let’s say ‘geo’) interface to use R from within SAS. and submit it to the repository. It then undergoes some quality checks and if it passes, is added to Questions the list. Then if anyone wants to use it, all they have 1 Is R a threat to software developers like SAS? to do is open R and type: install.packages (‘geo’). 2 Which code would you trust more when flying in The breadth and length of the list of packages is a jet: proprietary or open source? impressive. It is a beautiful system. As has been said, R is open source. This 3 How can open source software be quality software? means that users can see – and if they wanted to, 4 Should businesses use R? change – the code of the language. More usefully to most users, however, is that it also means they can References see the code of the packages written by others. So R website. www.r-project.org/about.html. Accessed a few weeks after the geo package went online, 1 June 2020. dozens of R users – many of whom are world-class statisticians and programmers – will have assessed Vance, A. 2009. ‘Data Analysts Captivated by R’s it and reported back any problems that they find. Power’. New York Times. Available from: www. 11 The Australian developer can then fix them. In very nytimes.com/2009/01/07/technology/business- little time at all, the code is very high quality. computing/07program.html. Accessed 13 June Initially, not everyone appreciated this. In 2020. a famous New York Times interview, director Vance, A. 2009. ‘SAS Warms to Open-Source One of technology product marketing at software Letter at a Time’. New York Times. Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.  CHAPTER 11 SYSTEMS ANALYSIS 379 Rapid Application Development, Agile Development, Joint Application Development and Other Systems Development Approaches Rapid application development (RAD) employs tools, techniques and rapid application development methodologies designed to speed up application development. Some people (RAD) A systems development approach that employs tools, consider it to be the same as prototyping. Vendors, such as Computer techniques and methodologies Associates International, IBM and Oracle, market products targeting the RAD designed to speed application market. Rational Software, a division of IBM, has a RAD tool, called Rational development. Rapid Developer, to make developing large Java programs and applications easier and faster. Locus Systems, a program developer, used a RAD tool called OptimalJ to generate more than 60 per cent of the computer code for three applications it developed. Advantage Gen is a RAD tool from Computer Associates International. It can be used to rapidly generate computer code from business models and specifications. RAD reduces paper-based documentation, automatically generates program source code and facilitates user participation in design and development activities. It makes adapting to changing system requirements easier. Other approaches to rapid development, such as agile development, allow the systems to change as they are being developed. Agile development requires frequent face-to-face meetings with the systems developers and users as they modify, refine and test how the system meets users’ needs and what its capabilities are. Extreme programming (XP), a form of agile development, uses pairs of programmers who work together to design, test and code parts of the systems they develop. The iterative nature of XP helps companies develop robust systems, with fewer errors. RAD makes extensive use of the joint application development (JAD) process for data collection and requirements analysis. Originally developed by IBM Canada in the 1970s, JAD involves group meetings in which users, stakeholders and IS professionals work together to analyze existing systems, propose possible solutions and define the requirements of a new or modified system. JAD groups consist of both problem holders and solution providers. A group normally requires one or more top-level executives who initiate the JAD process, a group leader for the meetings, potential users and one or more individuals who act as secretaries and clerks to record what is accomplished and to provide general support for the sessions. Many companies have found that groups can develop better requirements than individuals working independently and have assessed JAD as a very successful development technique. Today, JAD often uses group support systems (GSS) software to foster positive group interactions, while suppressing negative group behaviour. RAD should not be used on every software development project. In general, it is best suited for DSSs and MISs and less well suited for TPS. During a RAD project, the level of participation of stakeholders and users is much higher than in other approaches. Table 11.4 lists advantages and disadvantages of RAD. Table 11.4 Advantages and Disadvantages of RAD 11 Advantages Disadvantages For appropriate projects, this approach puts This intense SDLC can burn out systems developers and an application into production sooner than other project participants any other approach Documentation is produced as a by-product This approach requires systems analysts and users to be of completing project tasks skilled in RAD systems development tools and RAD techniques RAD forces teamwork and lots of interaction RAD requires a larger percentage of stakeholders’ between users and stakeholders and users’ time than other approaches Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it. 380 PART 4 SYSTEMS DEVELOPMENT The End-User Systems Development Lifecycle The term end-user systems development describes any systems development project in which business managers and users assume the primary effort. Rather than ignoring these initiatives, astute IS professionals encourage them by offering guidance and support. Providing technical assistance, communicating standards and sharing ‘best practices’ throughout the organization are some ways IS professionals work with motivated managers and employees undertaking their own systems development. In this way, end-user-developed systems can be structured as complementary to, rather than in conflict with, existing and emerging information systems. In addition, this open communication among IS professionals, managers of the affected business area and users allows the IS professionals to identify specific initiatives so that additional organizational resources, beyond those available to business managers or users, are provided for its development. User-developed systems range from the very small (such as a software routine to merge data from Microsoft Excel into Microsoft Word to produce a personalized letter for customers) to those of significant organizational value (such as a customer contact database). Initially, IS professionals discounted the value of these projects. As the number and magnitude of these projects increased, however, IS professionals began to realize that for the good of the entire organization, their involvement with these projects needed to increase. End-user systems development does have some disadvantages. Some end users don’t have the training to effectively develop and test a system. Expensive mistakes can be made using faulty spreadsheets, for example, that have never been tested. Most end-user systems are also poorly documented and therefore difficult to maintain. When these systems are updated, problems can be introduced that make the systems error-prone. In addition, some end users spend time and corporate resources developing systems that are already available. A survey of South African employers found that the IS skills they want in their new employees are the ability to type, create documents and having a basic working knowledge of computer applications. Outsourcing and On-Demand Computing Many companies hire an outside consulting firm or computer company that specializes in systems development to take over some or all of its development and operations activities.7 Some companies, such as General Electric, have their own outsourcing subunits or have spun off their outsourcing subunits as separate companies.8 Outsourcing can be a good idea under the following circumstances: When a company believes it can cut costs. When a firm has limited opportunity to distinguish itself competitively through a particular IS operation or application. When uninterrupted IS service is not crucial. When outsourcing does not strip the company of technical know-how required for future IS innovation. When the firm’s existing IS capabilities are limited, ineffective or technically inferior. 11 When a firm is downsizing. The decision to outsource systems development is often a response to downsizing, which reduces the number of employees or managers, equipment and systems, and even functions and departments. Outsourcing allows companies to downsize their IS department and alleviate difficult financial situations by reducing payroll and other expenses. Organizations can outsource any aspect of their information system, including hardware maintenance and management, software development, database systems, networks and telecommunications, Internet and intranet operations, hiring and staffing, and the development of procedures and rules regarding the information system.9 Eurostar, for example, hired the outsourcing company Occam to develop a new website and back-end database to give its travel Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.  CHAPTER 11 SYSTEMS ANALYSIS 381 customers greater travel information.10 According to Scott Logie, managing director of Occam, ‘The quality and volume of data that Eurostar possesses is extremely valuable. By working together we will allow the firm to develop real insight into its customers. This can be used to drive a strong customer acquisitions strategy, which will enhance its business and customer relationships’. Reducing costs, obtaining state-of-the-art technology, eliminating staffing and personnel problems, and increasing technological flexibility are reasons that companies have used in the outsourcing and on-demand computing approaches.11 A number of companies offer outsourcing and on-demand computing services – from general systems development to specialized services. IBM’s Global Services, for example, is one of the largest full-service outsourcing and consulting services.12 IBM has consultants located in offices around the world. Electronic Data Systems (EDS) is another large company that specializes in consulting and outsourcing.13 EDS has approximately 140,000 employees in almost 60 countries and more than 9,000 clients worldwide. Accenture is another company that specializes in consulting and outsourcing.14 The company has more than 75,000 employees in 47 countries. Organizations can use a number of guidelines to make outsourcing a success, including the following:15 Keep tight controls on the outsourcing project. Treat outsourcing companies as partners. Start with smaller outsourcing jobs. Create effective communications channels between the organization and the outsourcing company. Carefully review legal outsourcing contracts, including rights and remedies clauses.16 Old Mutual South Africa has outsourced its IS infrastructure to T-Systems, to control its costs and access T-System’s expertise. Outsourcing has some disadvantages, however. Internal expertise can be lost and loyalty can suffer under an outsourcing arrangement. When a company outsources, key IS personnel with expertise in technical and business functions are no longer needed. When these IS employees leave, their experience with the organization and expertise in information systems are lost. For some companies, it can be difficult to achieve a competitive advantage when competitors are using the same computer or consulting company. When the outsourcing or on-demand computing is done offshore or in a foreign country, some people have raised security concerns. How will important data and trade secrets be guarded? Genetic Programming Instead of having a software engineer write the software, or getting end users to develop their own systems, or giving the job to a third party, an active area of research involves having a computer write its own code. Called Genetic Programming, this approach draws on principles Genetic Programming An of natural selection from biology to evolve code that solves a set problem. While approach to creating computer not ready yet to tackle most business problems, and still seen mainly in university code based on natural selection. Initially random code evolves labs, genetic programming has already created programs that can compete with through numerous iterations to 11 a human doing the same task. A typical setup works as follows. The system become a program that solves a starts with a set of computer programs that have been randomly created. Each set problem. program is run and tested to see how close it gets to solving the problem. This testing is the most difficult part of using genetic programming and involves a human creating what is known as a fitness function to rate how good each program is. The random program that is best gets copied to create a new set of programs, now less random than the first set. Then the testing happens again. The copying introduces random mutations into the code – in the same way that a human child is not exactly the same as its parents, the next generation of computer code is not exactly the same as the previous generation. This continues over time until a good enough solution (you can never say if it is the best solution) evolves. Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it. 382 PART 4 SYSTEMS DEVELOPMENT 11.3 Factors Affecting System Development Success Successful systems development means delivering a system that meets user and organizational needs – on time and within budget. There is no formula for achieving this, but the following factors are known to have an impact on success. Involvement Getting users and other stakeholders involved in systems development is critical for most systems development projects. Having the support of top-level managers is also important. The involvement of users throughout the development will mean they are less likely to resist the software when it is delivered. Historically, communication between people on the domain side (users, managers and other stakeholders) and on the systems side (systems analysts, programmers and other technical people) has been problematic, with there being little common ground between them. Each group has its own set of terminology and its own culture. Getting users and managers involved in systems development is one way of building bridges between the two and kick-starting dialogue. This may be done simply by inviting them to development meetings, organizing social gatherings, producing a questionnaire to survey user views, running interviews, etc. or by using joint application development. If users have been involved throughout development, they will be less likely to resist the changes the new system brings when it is implemented. Degree of Change A major factor that affects the quality of systems development is the degree of change associated with the project. The scope can vary from implementing minor enhancements to an existing system, up to major reengineering. The project team needs to recognize where they are on this spectrum of change. As discussed in Chapter 2, continuous improvement projects do not require significant business process or IS changes, or retraining of people; thus, they have a high degree of success. Typically, because continuous improvement involves minor improvements, these projects also have relatively modest benefits. On the other hand, reengineering involves fundamental changes in how the organization conducts business and completes tasks. The factors associated with successful reengineering are similar to those of any development effort, including top management support, clearly defined corporate goals and systems development objectives, and careful management of change. Major reengineering projects tend to have a high degree of risk but also a high potential for major business benefits (see Figure 11.6). Figure 11.6 Degree of Change The degree of change can greatly affect the probability of a project’s success. 11 Risk of failure Continuous improvement Business process reengineering Degree of change Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.  CHAPTER 11 SYSTEMS ANALYSIS 383 Managing Change The ability to manage change is critical to the success of systems development. New systems inevitably cause change. For example, the work environment and habits of users are invariably affected by the development of a new information system. Unfortunately, not everyone adapts easily, and the increasing complexity of systems can multiply the problems. Managing change requires the ability to recognize existing or potential problems (particularly the concerns of users) and deal with them before they become a serious threat to the success of the new or modified system. Here are several of the most common problems: Fear that the employee will lose his or her job, power or influence within the organization. Belief that the proposed system will create more work than it eliminates. Reluctance to work with ‘computer people’. Anxiety that the proposed system will negatively alter the structure of the organization. Belief that other problems are more pressing than those solved by the proposed system or that the system is being developed by people unfamiliar with ‘the way things need to get done’. Unwillingness to learn new procedures or approaches. Preventing or dealing with these types of problems requires a coordinated effort from stakeholders and users, managers and IS personnel. One remedy is simply to talk with all people concerned and learn what their biggest concerns are. Management can then deal with those concerns and try to eliminate them. After immediate concerns are addressed, people can become part of the project team. Quality and Standards Another key success factor is the quality of project planning. The bigger the project, the more likely that poor planning will lead to significant problems. Many companies find that large systems projects fall behind schedule, go over budget and do not meet expectations. A systems development project for the UK Child Support Agency, for example, fell behind schedule and over £250 million over budget.17 When it was delivered, two years late, there were problems – screens took too long to refresh and there was no delete key to undo accidental typing mistakes; staff training was also ineffective and inappropriate. The delayed project may have hurt the agency’s ability to deliver important services to children. Although proper planning cannot guarantee that these types of problems will be avoided, it can minimize the likelihood of their occurrence. Good systems development is not automatic. Certain factors contribute to the failure of systems development projects. These factors and countermeasures to eliminate or alleviate the problem are summarized in Table 11.5. 11 The development of information systems requires a constant trade-off of schedule and cost versus quality. Historically, the development of application software has overemphasized schedule and cost to the detriment of quality. Techniques, such as use of the ISO 9001 standards, have been developed to improve the quality of information systems. ISO 9001 is a set of international quality standards originally developed in Europe in 1987. These standards address customer satisfaction and are the only standards in the ISO 9001 family where third- party certification can be achieved. Adherence to ISO 9001 is a requirement in many international markets18 (see Figure 11.7). Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it. 384 PART 4 SYSTEMS DEVELOPMENT Table 11.5 Project Planning Issues Frequently Contributing to Project Failure Factor Countermeasure Solving the wrong problem Establish a clear connection between the project and organizational goals Poor problem definition and analysis Follow a standard systems development approach Poor communication There is no easy answer to this common problem Project is too ambitious Narrow the project focus to address only the most important business opportunities Lack of top management support Identify the senior manager who has the most to gain from the success of the project and recruit this person to champion the project Lack of management and user involvement Identify and recruit key stakeholders to be active participants in the project Inadequate or improper system design Follow a standard systems development approach Lack of standards Implement a standards system, such as ISO 9001 Poor testing and implementation Plan sufficient time for this activity Users cannot use the system effectively Develop a rigorous user training programme and budget sufficient time in the schedule to execute it Lack of concern for maintenance Include an estimate of employee effort and costs for maintenance in the original project justification Figure 11.7 ISO Home Page ISO 9001 is a set of international quality standards used by IS and other organizations to ensure the quality of products and services. 11 This screenshot, taken from the ISO webstore, is reproduced with the permission of the International Organization for Standardization, ISO. It can be obtained from the website of the ISO Central Secretariat under: www.iso.org. Copyright remains with ISO. Copyright 2021 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.  CHAPTER 11 SYSTEMS ANALYSIS