CH-10 Systems Implementation and Operation – Essentials of Systems Analysis and Design : Book Guide

Chapter 10 Systems Implementation and Operation Chapter Overview Chapter 10 introduces students to many of the activities carried out during implementation and operation, including coding, testing, installation, documentation, user training, support, and maintenance. This chapter demonstrates that implementation is neither simple nor mechanical. Systems development is a change process, and for many users, the most obvious evidence of change comes during implementation. Once a new system has been coded, tested, and installed, the systems development team does not simply walk away. The organization members left with the new system, the users, will need a solid understanding of how the new system fits into their work lives and how the system can support them in their day-to-day work activities. User documentation, training, and continuing support are all parts of providing this solid understanding. In some organizations, other specialists in the IS department, such as technical communicators, trainers, local experts, and help desk employees, will be available to help the analyst complete this part of the implementation process. In other organizations, the analyst may have to do most of this work alone. In the latter case, the importance of user documentation, training, and support should not be overlooked. The success of a system implementation effort depends on what the users think of the system and their inclination to use it well. The training and support effort will have a definite effect on user attitudes and inclinations. Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor's point of view, the objectives of this chapter are to: 1. Discuss with students the subprocesses that make up system implementation. 2. Teach students about the many different types of testing that occur in implementation and when each one is appropriate. 3. Show students how to prepare a test plan for an information system. 4. Have students distinguish among four installation strategies: direct, parallel, single location, and phased installation and know when to use each one. 5. Explain the difference between system and user documentation, emphasizing that system documentation has been occurring throughout the SDLC. 6. Demonstrate the many different modes available for training users, including tutorials, courses, self-training, electronic performance support systems, and other types of embedded training. 7. Show students how to prepare a training plan for an information system. 8. Explain to students the issues associated with user support, whether internal or external to the organization. 9. Explain and contrast four types of maintenance. 10. Describe several factors that influence the cost of maintaining an information system and apply these factors to the design of maintainable systems. 11. Illustrate the role of CASE when maintaining information systems. Classroom Ideas 1. Most students will have completed programming courses and will be familiar with both coding and testing. Ask them to think about coding and testing in the context of what they have learned about systems development. What methods can they suggest that would help manage coding and testing in an on-going systems development project, as opposed to a series of isolated programming class projects? 2. Have students generate a test plan for one or more of the various systems development projects presented in the text; for example, Hoosier Burger’s food-ordering system or its inventory control system. Alternatively, have students develop a testing plan (at a general level) for a major packaged software release, such as a new version of a popular DBMS (e.g. Microsoft Access or Oracle’s DBMS) or a major application system, such as SAP. 3. Present a series of information system implementation scenarios. Have students determine which strategy should work for each scenario and why. 4. Many students have not seen very sophisticated program and system testing environments. It is likely that they have used some form of debugger, but they probably have not seen or used more thorough testing systems. Have your students locate articles about commercial testing software. If possible, you might contact these firms to get documentation or demonstration software and videos to use in class. 5. Encourage your students to think about being a user, not a developer or IS specialist, in which one’s focus is on doing the job, not using the software. You might bring in a “user’s manual” for a common product (e.g., a TV, VCR, microwave oven) and have the students analyze the features of this manual that make it a good or bad manual. 6. Have students bring in examples of documentation. Some students will have access to documentation prepared for customized applications developed for a variety of purposes and computer platforms. Have students present their documentation to the class. They should show at least the table of contents and samples from different sections of the documentation. 7. Use Table 10–5 as the starting point for a discussion of the various training modes. Prepare an example that utilizes several modes, so students can see how training varies by mode. For example, how would training for an order processing system operator look if the training were a tutorial? If it were a formal course? If it were provided by a local expert (e.g., the operator at the next station)? If it were embedded in the order processing software? 8. Have students include a detailed training plan in the user documentation they turn in as part of their semester projects. Have at least one group/student present their training plan in class for discussion. 9. Have students compare and contrast the different types of user support discussed in the chapter. For a particular system or job, which types of support would they, as users, prefer and why? Use this in-class discussion to develop recommendations on when to use the different forms of user support. 10. Ask an IS professional at a local organization to come in and discuss how his or her organization manages user documentation, training, and support. Ask this guest to discuss such topics as: • How is documentation tested? • Who manages updates and distribution of updated documentation? • How is updating documentation coordinated with updating the software? • What training methods do they employ? • Who does training and how are trainers trained? • How much does the organization spend on information systems training as a percentage of the total IS budget or IS development budgets? • How much does the organization spend on information systems support as a percentage of the total IS budget? • How have the help desk and information center functions changed over time? • What is their experience with EPSS? 11. Another very effective in-class exercise is to ask students who have maintained an information system to compare their experiences to the concepts presented in Chapter 10. This discussion can be a good way to elaborate on key system maintenance issues (e.g., role of CASE, how quality was measured, where change requests came from, etc.). 12. If you have access to practicing systems analysts, an insightful activity is to invite them into your class to discuss how they manage maintenance in their organization. Lecture Notes Systems implementation and operation is the last phase of the systems development life cycle. As Figure 10–1 shows, this phase consists of coding, testing, installation, documentation, training, support, and maintenance. Specifically, this chapter identifies where coding and testing fits in the overall scheme of implementation, stresses the view of implementation as an organizational change process, discusses the importance and types of documentation and training, overviews the types of testing, and introduces four types of installation. Systems Implementation and Operation The seven major activities of systems implementation and operation are: coding, testing, installation, documentation, training, support, and maintenance. During this phase, analysts are responsible for many activities, including the activities leading up to an operational system, activities that are necessary for successful system operation, and activities that are ongoing and needed to keep the system working and up-to-date. Although actual testing is performed during system implementation, test planning begins during the analysis phase. Once coding has begun, testing begins and proceeds in parallel with the coding activity. Installation replaces the current system with the new system. The coding, testing, and installation processes result in several deliverables; Table 10–1 identifies these deliverables. Code documentation is crucial to the continual and smooth operation of the system. Additionally, program and system testing results, a user’s guide, a user training plan, an installation and conversion plan, a hardware and software installation schedule, a data conversion plan, and a site and facility remodeling plan are important deliverables. Documentation receives formal attention during the implementation and operation phase. Documentation is prepared for two audiences: (1) the information systems personnel who will maintain the system throughout its productive life and (2) the people who will use the system as part of their daily lives. Table 10–2 lists the deliverables from documenting the system, training users, and supporting users. These deliverables address documentation, a user training plan, user training modules, and a user support plan. Maintaining an information system involves returning to the beginning of the SDLC and repeating development steps. Maintenance has four major steps; these include obtaining maintenance requests, transforming requests into changes, designing changes, and implementing changes. Figure 10–2 shows the maintenance activities in relation to the SDLC phases. The deliverables and outcomes of the maintenance process are the development of a new version of the software and new versions of all design documents developed or modified during the maintenance process. Main differences between new development and maintenance include: (1) maintenance reuses most existing system modules in producing the new system version, (2) a new system is developed when there is a change in the hardware or software platform, and (3) a new system is developed if the fundamental assumptions and properties of the data, logic, or process models change. Software Application Testing Although the actual testing activities are performed during implementation, testing begins earlier in the SDLC. During analysis an overall test plan is prepared; a unit test plan, an integration test plan, and a system test plan are prepared during system design. Table 10–3 identifies several different types of tests, including inspections, walkthroughs, desk checking, syntax checking, unit testing, integration testing, system testing, and stub testing. Figure 10–3 presents the guidelines for conducting a code walkthrough. Important issues to keep in mind about testing are that the purpose of testing is to confirm that the system satisfies requirements and that testing must be planned. As part of test planning, a set of test cases is developed. Figure 10–4 shows a test case description and summary form. A test case is a specific scenario of transactions, queries, or navigation paths that represent a typical, critical, or abnormal use of the system. A test case should be repeatable; and it needs to determine whether the new software works with other existing software. Figure 10–5 presents a testing harness called AppPerfect for analyzing Java source code. Upon completion of system testing, acceptance testing is performed. Acceptance testing determines if the new system meets user requirements and varies with the organization and the system in question. Acceptance testing includes both alpha testing, beta testing, and a system audit. Alpha testing includes recovery testing, security testing, stress testing, and performance testing. Installation Installation is the organizational process of changing over from the current information system to a new one. Direct, parallel, single location, and phased are four approaches to installation. Figure 10–6 and Table 10–4 compare these four installation approaches. Implementing the chosen installation strategy involves converting software, data, hardware, documentation, work methods, job descriptions, offices and other facilities, training materials, business forms, and other aspects of the system. Installation also involves choosing an appropriate time to install the system and being aware of the business cycle. Documenting the System Each system requires both system documentation and user documentation. System documentation provides detailed information about a system’s design specifications, its internal workings, and its functionality. Internal and external documentation are two types of system documentation. User documentation is written or other visual information about how an application system works and how to use it. Figure 10–7 shows an example of online user documentation for Microsoft Visio. Types of user documentation include reference guides, quick reference guides, user guides, release descriptions, system administrator’s guides, and acceptance sign-offs. Figure 10–8 illustrates the structure of an online reference user’s guide. Although user-oriented documentation is often supplied by the information systems department, vendors and the end users are now sources of user-oriented documentation. Training and Supporting Users Support provides ongoing educational and problem-solving assistance to information system users. Although training varies by system type and the user’s expertise, potential training topics include system use, general computing concepts, information system concepts, organizational concepts, system management, and system installation. Training delivery occurs in several ways. Table 10–5 summarizes these methods, including resident expert, computer-aided instruction, formal courses, software help components, tutorials, interactive training manuals, and external sources. Newer types of training include videos, interactive television, multimedia training, online tutorials, and electronic performance support systems (EPSS). Support is often automated through online support forums, bulletin board systems, on-demand fax, and voice-response systems. Additionally, organizations provide internal support by using automated issue tracking, automating support, and they may provide support through a help desk. Figure 10–9 shows an example of an automated issue tracking system and Table 10–6 identifies typical information that is collected in an issue tracking system. An organization may use a help desk, a single point of contact for all user inquiries and problems about a particular information system or for all users in a particular department. Support includes providing recovery and backup, disaster recovery, and PC maintenance; writing newsletters and offering other types of proactive information sharing; and setting up user groups. Why Implementation Sometimes Fails The two conditions necessary for a successful implementation effort are management support of the system under development and the involvement of users in the development process. Factors influencing implementation success or failure include risk, commitment to the project, commitment to change, extent of project definition and planning, and realistic user expectations. The extent to which a system is used and the user’s satisfaction of a system determines implementation success. Whether a user will use the new system is determined by the relevancy of the system to the user’s work, the ease of use and reliability of the system, user demographics, system uses, and user satisfaction. Project Closedown Project close down involves closing down the project, conducting post project reviews, and closing the customer contract. After a system is in operation, a system audit is often conducted. Conducting Systems Maintenance Maintenance refers to changes made to a system to fix or enhance its functionality. Table 10–7 summarizes the types of maintenance. The types of maintenance include corrective, adaptive, perfective, and preventive. Some organizations allocate as much as 80 percent of their information systems budget to maintenance activities. Several factors influence a system’s maintainability; these include latent defects, number of customers for a given system, quality of system documentation, maintenance personnel, tools, and well-structured programs. The number of failures, time between each failure and the type of failure are measures of maintenance effectiveness. The mean time between failures is a measurement of error occurrences that can be tracked over time to indicate the quality of a system. Managing maintenance requests is an important maintenance activity. Figure 10–10 is a flowchart showing how to control maintenance requests. Configuration management assures that only authorized changes are made to a system. A system librarian monitors the baseline modules and keeps copies of the build routines. When maintaining Web sites, special issues and procedures may arise. These issues include 24 x 7 x 365, checking for broken links, re-registration, and future editions. Maintaining an Information System at Pine Valley Furniture In this chapter, Pine Valley Furniture’s Purchasing Fulfillment System is used to illustrate information systems maintenance. PVF WebStore: Systems Implementation and Operation Using Pine Valley Furniture’s WebStore as an example shows that systems implementation and operation is no different than the processes used for other types of applications. Table 10–8 identifies several tests that were performed for Pine Valley Furniture’s WebStore. Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list. Review Questions Solutions 10-1. What are the deliverables from coding, testing, and installation? Answer: The deliverables from coding, testing, and installation are: (1) from coding, code and program documentation; (2) from testing, test scenarios and test data and the results of program and system testing; and (3) from installation, user guides, user training plans, and installation plans. 10-2. Explain the testing process for code. Answer: The testing process involves testing code for errors and functionality. The testing process, guided by a detailed testing plan, can begin as soon as modules are coded and proceeds in parallel with the rest of the coding process. Modules are tested individually and then as parts of larger programs and parts of larger systems. 10-3. What are the four approaches to installation? Which is the most expensive? Which is the most risky? How does an organization decide which approach to use? Answer: The four approaches to installation are direct, parallel, single location, and phased. With the direct approach, the old system is turned off, and the new one is turned on. In the parallel approach, both systems are run until management decides the old system can be turned off. In single location, the system is tried out in a pilot project at one location and then implemented elsewhere if the pilot is successful. With the phased approach, the new system is brought online gradually, usually function by function. Parallel is usually the most expensive due to the redundant costs, and direct is usually the most risky due to the potential hazards if the new system fails. An organization decides which approach to use depending on the scope and complexity of the change and the organization’s risk aversion. 10-4. List and define the factors that are important to successful implementation efforts. Answer: Several factors are important to the successful implementation of a system, including management support, the involvement of users, and user expectations. Additionally, commitment to the project, commitment to change, and extent of project definition and planning are important. Commitment to the project refers to managing the project so that the problem being solved is well understood and the target system actually solves the problem. Commitment to change means being willing to change behaviors and procedures. The premise of project definition and planning is that more extensive planning is more effective than less extensive planning. 10-5. What is the difference between system documentation and user documentation? Answer: System documentation is the detailed information about a system’s design specifications, its internal workings, and its functionality, whereas user documentation consists of written or other visual information about an application system, how it works, and how to use it. 10-6. List and define the various methods of user training. Answer: Methods of training include resident experts, computer-aided instruction, formal courses, software help components, tutorials, interactive training manuals, and external sources. Descriptions of these methods are provided in the chapter. 10-7. Describe the delivery methods many vendors employ for providing support. Answer: Vendors provide support through the following mechanisms: automated support, such as online support forums; bulletin board systems; on-demand fax; voice-response systems; help desk support; and technical support 800 telephone units, all or some of which can be either external or internal to the user organization. 10-8. List the steps in the maintenance process and contrast them with the phases of the systems development life cycle. Answer: Four major activities occur within maintenance; these are obtaining maintenance requests, transforming requests into changes, designing changes, and implementing changes. The first phase of the SDLC, systems planning and selection, is analogous to the maintenance process of obtaining a maintenance request. The systems analysis phase is analogous to the maintenance process of transforming requests into a specific system change. Systems design is similar to the designing changes process. Finally, the systems implementation and operations phase is similar to implementing changes. This similarity between the maintenance process and the SDLC is no accident. The concepts and techniques used to initially develop a system are also used to maintain it. 10-9. What are the different types of maintenance and how do they differ? Answer: Corrective, adaptive, perfective, and preventive are the four types of maintenance. Corrective maintenance is concerned with repairing design and programming errors; adaptive maintenance modifies the system to reflect environmental changes; perfective maintenance evolves the system to solve new problems or take advantage of new opportunities; preventive maintenance safeguards the system from future problems. 10-10. Describe the factors that influence the cost of maintenance. Are any factors more important? Why? Answer: Latent defects, number of customers for a given system, quality of system documentation, maintenance personnel, tools, and well-structured programs are factors that influence the cost of maintenance. Of these factors, three were described as being very important: defects, customers, and documentation. The number of latent defects refers to the number of unknown errors existing in the system after it is installed. Because corrective maintenance accounts for most maintenance activity, the number of latent defects in a system influences most of the costs associated with maintaining a system. If there are no errors in the system after it is installed, then maintenance costs will be relatively low. If there are a large number of defects in the system when it is installed, maintenance costs will likely be high. A second factor influencing maintenance costs is the number of customers for a given system. In general, the greater the number of customers, the greater the maintenance costs. A third major contributing factor to maintenance costs is the quality of system documentation. Without quality documentation, maintenance efforts can increase exponentially. 10-11. What types of measurements must be taken to gain an understanding of the effectiveness of maintenance? Why is tracking mean time between failures an important measurement? Answer: To measure effectiveness, you must measure the number of failures, time between each failure, and type of failure. Measuring the number and time between failures will provide you with the basis to calculate a widely used measure of system quality. This metric is referred to as the mean time between failures (MTBF). As its name implies, the MTBF measure shows the average length of time between the identification of one system failure to the next. Over time, you should expect the MTBF value to rapidly increase after a few months of use (and corrective maintenance) of the system. If the MTBF does not rapidly increase over time, it will be a signal to management that major problems exist within the system that are not being adequately resolved through the maintenance process. 10-12. Describe the process for controlling maintenance requests. Should all requests be handled in the same way or are there situations when you should be able to circumvent the process? If so, when and why? Answer: The chapter presents a flowchart that suggests one possible method for dealing with maintenance change requests. This chart suggests that you must determine the type of request. If, for example, the request is an error—that is, a corrective maintenance request—then the flowchart shows that a question must be asked related to the error's severity. If the error is “very” severe, then the request has top priority and is placed at the top of a queue of tasks waiting to be performed on the system. If, however, the error is considered not very severe, then the change request can be categorized and prioritized based upon its type and relative importance. If the change request does not concern an error, then you must determine if the request is to adapt the system to technology changes and/or business requirements or to enhance the system so it will provide new business functionality. For adaptation requests, they too will need to be evaluated, categorized, prioritized, and placed in the queue. For enhancement type requests, they must first be evaluated to see if they are aligned with future business and information systems plans. If not, the request will be rejected and the requester will be informed. If the enhancement appears to align with business and information systems plans, it is then prioritized and placed into the queue of future tasks. The method for reviewing maintenance requests strongly suggests that all requests should not be handled in the same way. The process also suggests what should be done with different types of requests. In situations where there is a catastrophic failure of the system, time may be of the essence, and a formal review of a request will take too long. In such a situation, the formal evaluation process is circumvented. 10-13. What is meant by configuration management? Why do you think organizations have adopted the approach of using a systems librarian? Answer: Configuration management is the process of assuring that only authorized changes are made to a system. A system librarian controls the baseline source code modules. If maintenance personnel are assigned to make changes to a system, they must first check-out a copy of the baseline system modules because no one can directly modify the baseline modules. This ensures that only those modules that have been checked-out and then formally checked-in can reside in the library. Organizations have adopted this approach so that before any code can be checked back into the librarian, they must pass the quality control procedures, testing, and documentation standards established by the organization. Problems and Exercises Solutions 10-14. Consider the reasons implementations fail. For at least three of these reasons, explain why this happens, if there is one (or more) type of implementation likely to minimize the occurrence, and if there is one (or more) type of installation more likely to induce failure for this reason. Answer: There are several reasons for failed implementation, some of which can be exacerbated by the methods chosen for installation. Some of the reasons include: • Lack of commitment to the project – Management and employee commitment are important to the successful implementation of an information system. Parallel installation can signal a lack of commitment by management. Direct installation, on the other hand, shows a complete confidence in making the system a success. Phased and single location installations can demonstrate successes, increasing commitment to the project so that the benefits of the new information system can be extended, either across all locations (in a single location installation) or across all functions (in a phased installation). • Lack of commitment to change – Much like commitment to the project, users must also be willing to change how they accomplish their work to include the new information system. Parallel implementation is more likely to leave users wishing to use the old system which could eventually lead to a failed implementation. Direct installation makes it more difficult to choose not to change, as restoring the old system can be difficult, time-consuming, and costly. Single location installation and phased installation can increase commitment by showing early successes with the system as a motivation for change in the other users. • Poorly conceptualized system – Systems may fail because they were not properly conceptualized or developed. This indicates a serious lack of planning and project definition. The form of installation would not be likely to impact this cause for failure. • Unrealistic user expectations – Users may not completely understand what the information system can and cannot do. When the users form unrealistic expectations, they are guaranteed to be disappointed by the system. Both direct and parallel installations are likely to enhance these feelings of disappointment; parallel installations let users see how the new system doesn’t solve all of the problems of the old system while direct installation may lead users to a feeling of nostalgia for the old system. Phased and pilot installations can be used to educate users as to what the new system will (and will not) do. • Users refuse to use the system – Users may simply refuse to use the system. This however usually happens for one of the other reasons listed. It can also happen because of characteristics of the users themselves. For instance, workers who have done their job the same way for 20 years may be resistant to the change irrespective of the information system involved. The installation method is not likely to influence these user-centric characteristics. Additionally, characteristics of the information system may make use of the system unpalatable. Cumbersome interfaces and error-riddled software can lead to low satisfaction. Direct installation is more likely to cause problems as phased, parallel, and pilot installations are more likely to discover issues before the product is rolled out to all users or when there is a backup readily at-hand (in the case of parallel). • Political reasons – Implementation may fail because of the misalignment of personal goals of politically powerful people. In such cases, the method of installation is unlikely to impact the outcome. 10-15. Two members of your project development team are disagreeing about the relative importance of training and documentation. Sam strongly believes that training is far more important because it will ensure the successful implementation of the information system and that the early usage is a positive experience. Pat counters that the user documentation is far more important because its impact can help not only the current users, but also future users. Which do you think is right, and why? Answer: Training and documentation are both critical to the success of the system. Students should choose one and justify their position. Some answers they may include are: Training: • Training users on the systems can increase productivity • Training can help users accept the need for change and prepare mentally for that process • Training can improve the perception of the system as they will know better how to use it • Training is more often customized to the particular functions the employee must do User documentation: • Documentation will remain available even after trainers have left • Documentation can answer questions not thought of until the system is in use • Users are more motivated to learn when they need to know, how to do an actual task, leading to “just-in-time knowledge” • User documentation can provide graphical representations of processes whereas training often just describes them in words Both training and documentation are crucial, but training is typically more immediate for successful implementation. Training ensures users understand and effectively use the system from the start, addressing issues in real-time and enhancing the initial experience. Documentation is essential for long-term support and reference, helping users solve problems independently and onboard future users. In summary, prioritize training for immediate implementation success, but ensure robust documentation is also in place for ongoing support. 10-16. Why is it important to keep a history of test cases and the results of those test cases even after a system has been revised several times? Answer: It is important to keep a history of test cases and results for a number of reasons. First, it is a good idea for the systems personnel to keep a clear record of what testing was done so that, if problems with the system occur later on, the systems personnel can show that they did, in fact, conduct tests. Second, if problems do occur even after a series of tests, the track record of testing will help the systems personnel to rule out pieces of the system that were tested as potential sources of these new system problems. Third, particularly for a situation where there have been several revisions of a system, there may be a need to retrace the steps of the system development back through the test history to diagnose problems or, worse, to make a decision to revert back to a former version of the system. Fourth, the history of test cases provides at least a baseline of test cases for future versions and results from prior tests to which results from current tests can be compared when possible. 10-17. What is the purpose of electronic performance support systems? How would you design one to support a word processing package? A database package? Answer: The purpose of an EPSS is to provide convenient online help embedded directly within the software package. The user never has to leave the application in order to gain the benefits of training. Users can learn a new system on their own time, on their own machines, without having to lose work time to remote group training sessions. Many application packages now incorporate “intelligent” features that assist the user when necessary. 10-18. Due to advances in technology and widespread computer literacy, many organizations use e-learning extensively to train employees. If you were managing a system implementation and had to train on a limited budget, you may find yourself choosing between e-learning or conducting face-to-face training with a subset of users who would then train their departments (called train-the-trainers). Which would you choose and why? Answer: Each method has benefits and challenges. Students should choose a method and support their answer with the benefits, including: Benefits of train-the-trainers: 1. Face-to-face interaction can ensure that the users understand the material presented. If there are misunderstandings, the trainer can clarify immediately. 2. By having end-users become the trainers, the knowledge they gain from training should be more customized to the processes and culture of their organization. 3. Face-to-face training can help users form personal relationships with the trainers. As such, when problems arise, they may feel more comfortable contacting that trainer directly. Benefits of e-learning: 1. All of the users can receive training from the trainers; as such, one person’s misconceptions will be less likely to impact a large number of people. 2. The training can be presented when and where it is most convenient. 3. Training sessions can be recorded and re-presented periodically to enhance the ongoing training. 10-19. Is it good or bad for corporations to rely on vendors for computing support? List arguments both for and against reliance on vendors as part of your answer. Answer: The arguments for and against relying on outside vendors for support are similar to the arguments for and against outsourcing in general. For a variety of reasons, outsourcing of nearly all aspects of information systems is becoming more and more popular. There are many reasons for relying on vendors for support. This can be a less expensive means for support. For example, the organization does not have to maintain its own in-house staff for this function, independent of demand. In addition, the organization can have state-of-the-art, professional support, and they do not have to worry as much about technological and methodological changes in support. Some of the reasons against relying on vendors for support include: (1) vendor support can be more expensive if not negotiated and/or planned well; (2) vendor’s employees might not be familiar with this specific technology and/or situation; (3) vendor’s employees might not be committed to the customer organization’s mission, goals, and objectives; and (4) there is a potential that trade secrets may be compromised. 10-20. Suppose you were responsible for establishing a training program for users of Hoosier Burger's inventory control system (described in previous chapters). Which forms of training would you use? Why? Answer: The students are likely to come up with a variety of ideas for training the users of Hoosier Burger’s inventory control system. What they propose to do is not as important as the soundness of the arguments they use to support their proposed methods. Given that the organization and user base are relatively small, one sound strategy would be to offer a short course for the few people that would be using the system. This course could be offered by someone from within the organization or could be outsourced to an external vendor. In addition, some software help components should be built into the system with the help of the users. A crucial element of the training program would be how to handle employee turnover, to the extent that people other than Bob and Thelma will use the system. Possibly a video tape or online tutorial, to be used as part of the overall orientation program for new employees, would be a good approach. For training users of Hoosier Burger's inventory control system, I would use a combination of the following forms: 1. Instructor-Led Training (ILT): Provides hands-on experience and allows for real-time feedback and interaction with an expert. 2. Online Tutorials and E-Learning Modules: Offers flexibility and can be accessed on-demand, allowing users to learn at their own pace. 3. Workshops and Simulations: Facilitates practical application of skills in a controlled environment, reinforcing learning through practice. 4. User Manuals and Quick Reference Guides: Serve as ongoing resources for users to refer to as they navigate the system. This blend ensures comprehensive coverage, catering to different learning styles and providing both initial training and ongoing support. 10-21. Suppose you work in a senior management position for a large corporation. A member of your team has suggested that your company outsource the helpdesk functions. Would you support a plan to outsource your helpdesk? Support your answer. Answer: The helpdesk is a point of contact for all users to call when they have a problem. Several organizations have outsourced this service. Students should choose an answer and support it with pros and cons, some of which are listed below: Pros: • Helpdesk personnel are difficult to find, train, and retain. Outsourcing may provide access to the human resources that are difficult to find. • Helpdesk support often deals with basic problems that can be answered by any technologically savvy person. In those cases, and outsourced helpdesk will be capable of responding to problems without added delay or hassle. • Outsourcing helpdesk functions may allow IT groups to focus on value-generating processes such as systems development. Cons: • Outsourced helpdesks are unlikely to be able to provide detailed information for idiosyncratic systems. • Assistance which requires in-house knowledge will likely take longer than if the helpdesk were kept in-house. • Helpdesk operation is critical to an organization’s ability to support the end users but outsourcing partners may not provide the level of service needed to support those end users. • Language barriers and different meanings for similar technical terms can cause problems if the outsourcing occurs across borders or industries. • Users are more likely to turn to in-house experts than to rely on outside sources. 10-22. If you were an analyst on a project team developing a new information system and you were given the task of organizing the user documentation, you would probably not be able to create all of the content by yourself from memory. List three sources you would tap for the documentation and explain how you would have to modify it for end-users. Answer: Many sources can be used to generate user documentation. They can include: 1. System documentation – This documentation describes the inner workings of the system. Such documentation can sometimes suggest how the functionality operates, leading to an understanding of what the user may need to know. However, such documentation would require a change in focus from the designers, implementers, and administrators to the end users. In addition, technical jargon may need to be replaced with language the intended user is likely to understand. 2. Internal documentation – This documentation can be found within the source code itself or generated automatically from the code. These are typically highly technical but may specifically describe how aspects of the information system are designed to work. As such, use of internal documentation is likely to require a similar change of focus and language as system documentation. 3. External documentation – This documentation includes the diagrams and other outputs from the system design process. As such, the intended uses of the software should be described. Use of such documents as the basis for user documentation is likely to require the analyst to interpret the experiences a user will face when actually interacting with the information system. 4. Other systems analysts – Systems analysts should have a very good understanding of what the users need, what the system is designed to do, and how it will be used. Collecting the knowledge from the various systems analysts may help in generating useful user documentation. Such contributions will probably require very little modification. 5. Programmers – Often programmers can give valuable insight into what the system will do and how users will need to do it. This is because the programmers will be intimately aware of the assumptions and choices made during development. Their input will likely need to be summarized and contextualized for the user documentation. 6. Users themselves – Some user documentation is generated by the users themselves. If a phased implementation has been used, then users may have created documentation for their own use or to help others. Collecting such documentation may help in crafting user documentation. It is most likely to be customized to how the work is done; however, it should be carefully checked for accuracy. 10-23. In what ways is a request to change an information system handled differently from a request for a new information system? Answer: For the most part, a request to change an information system is handled much like a request for a new information system. For a new system request, the systems personnel must estimate the duration and scope of the project and assess its risk and feasibility. However, a change request is handled somewhat differently. For instance, the systems personnel must determine how the requested change will affect the current system. Also, change requests are often batched together into a maintenance project to gain some economies of scale and to minimize the frequency of change for users. Thus, change requests interact with one another, and may be modified to meet conflicting and complementary needs of different requests. One could argue that for a new information system the parallel would be that systems personnel must determine how the new information system will affect and interact with other current information systems and business processes. 10-24. What can a systems analyst do to reduce the frequency of corrective maintenance, the most common form of maintenance? Answer: To reduce corrective maintenance the answer is clear: do a better job in analyzing, designing, coding, and implementing (including testing) new information systems. There is no better way to reduce the number of repairs to an information system than to do an effective, thorough job in the development process. Usually the most expensive errors to correct are those that fix incorrect requirements, so doing a thorough job in analysis (both requirements determination and structuring) not only reduces the need for corrective maintenance, but also provides the extensive documentation that can reduce maintenance time. Also, building systems using common tools and languages makes it easier for a variety of highly-trained maintenance personnel to quickly do their job. However, there are some problems requiring corrective maintenance that cannot be avoided or even foreseen. For example, some components purchased and installed from a third party as part of a new information system may later be found to be defective. A “Murphy’s Law” approach would be to do as good a job as possible in designing, coding, and implementing the system, and then be prepared for when the inevitable problems occur. 10-25. What other information should be collected on a System Service Request for maintenance as opposed to a System Service Request for a new system? Answer: The intent of an SSR is to briefly state the business problem or opportunity, along with general ideas of how to address the problem or opportunity. Pine Valley’s SSR does provide this information. However, the SSR could be modified to indicate the type of request (maintenance or new system development) being requested. Students will provide additional recommendations. 10-26. What can a systems analyst do to facilitate future maintenance? Answer: All forms of maintenance require developers to update the information system, usually by modifying the source code. As such, proper documentation is critical for future maintenance work. However, careful documentation is often not provided by the programmers, as they assume that nobody else will need to read the code, or that the purpose of the code is obvious. A system analyst can ensure that every module of code contains comments (a form of internal documentation), as well as to retain the external documentation from which the information system was built. In addition, changes to the system through the development process should be reflected in external documentation. Finally, systems analysts can ensure that the documents are available to the maintenance team. 10-27. Suppose an information system were developed following a rapid application development approach like prototyping. How might maintenance be different than if the system had been developed following the traditional life cycle? Why? Answer: RAD follows the same SDLC processes; however, these phases are combined and shortened. The problems of the RAD approach are indicative of some of the maintenance problems that might arise. For instance, RAD shortens the planning and design phases and often develops systems in isolation. A system may require rework because all of its requirements were not adequately identified or it now needs to better integrate with other systems. 10-28. This chapter contains a warning that maintenance activities could lead to further corrective maintenance work if not carefully designed and implemented. What processes or procedures can organizations use to reduce the likelihood of this occurring? Answer: The likelihood of a corrective maintenance request after maintenance activities is increased when proper development techniques are not followed in carrying out the maintenance activity. The same procedures used in the software development process should be used during maintenance such as planning, testing, and installation. Corrected versions of software must be installed much as a new information system would be. Discussion Questions Solutions 10-29. If possible, ask a systems analyst you know or have access to about implementation. Ask what the analyst believes is necessary for a successful implementation. Compare what the analyst believes are the factors that influence successful implementation to the factors discussed in this chapter. Answer: It will be useful for students to compare their answers to this question. This way they can learn about the perceptions of a variety of systems professionals. Students should keep in mind, however, that the perceptions of a handful of professionals in the field are not necessarily generalizable to all system implementations. These bits of anecdotal evidence should be integrated with research on system implementation in order to gain a more complete, accurate, generalizable understanding of system implementation. 1. Clear Objectives and Requirements: Analysts stress defining clear goals and system requirements to guide development and ensure alignment with business needs. 2. Stakeholder Involvement: Successful implementation often requires active participation from key stakeholders throughout the process. 3. Training and Support: Comprehensive training and ongoing support are crucial for user adoption and effective system use. 4. Change Management: Managing change effectively helps address resistance and ensures smooth transition. 5. Testing and Quality Assurance: Rigorous testing before full deployment helps identify and fix issues early. These factors align with common themes in successful implementation, such as thorough planning, user involvement, and robust support, which are typically discussed in implementation strategies. 10-30. Talk with people you know who use computers in their work. Ask them to get copies of the user documentation they rely on for the systems they use. Analyze the documentation. Would you consider it good or bad? Support your answer. Whether good or bad, how might you improve it? Answer: If the students find people that use best-selling packaged software, and if these people have available the user documentation that came with this software, then the students are likely to find that this documentation is relatively good and conforms to the guidelines discussed in this chapter. If these users do not have the necessary user documentation for this software, or if these users are using other types of software (e.g., internally developed application systems), then the students are likely to find a variety of quality in the documentation. In some cases, there might not be any documentation at all. For internally-developed systems, the students might inquire about how the documentation is tested and updated as the software evolves. One advantage of packaged software is that given the large number of users, vendors can invest (and need to invest for marketing purposes) in high-quality documentation. Individual organizations, under pressure to reduce the systems development backlog, often compromise on the scope and quality of user documentation. Good Documentation: • Clarity and Completeness: Provides clear, step-by-step instructions and covers all system features. • User-Friendly Format: Organized with a table of contents, index, and searchable content. • Visual Aids: Includes screenshots and diagrams to illustrate complex tasks. Bad Documentation: • Ambiguity: Lacks clear instructions or assumes prior knowledge. • Disorganization: Difficult to navigate with poor structure and no indexing. • Outdated Information: Doesn't reflect the latest system updates or features. Improvements: • Update Content Regularly: Ensure documentation reflects the latest system changes. • Enhance Organization: Use clear headings, a table of contents, and searchable features. • Include Practical Examples: Provide real-world scenarios to illustrate usage. Improving documentation involves making it more user-centric, accessible, and reflective of current system capabilities. 10-31. Volunteer to work for a shift at a help desk at your school's computer center. Keep a journal of your experiences. What kind of users did you have to deal with? What kinds of questions did you get? Do you think help desk work is easy or hard? What skills are needed by someone in this position? Answer: At a typical help desk at a university (or monitor in a student computing lab), students are likely to encounter users that are students, faculty, staff, administrators, and even people from the community. Users ask a variety of questions, including: “What are the hours of the computer lab?”; “How do I customize a header in my word processor?”; “Can you help me develop an e-mail distribution list for my class?”; “How do I download files from the Internet?”; “Can someone come over and help us with the new student records database?”; “How much does a new laser printer cost?” People might think that this kind of work is relatively easy, but it is not. Solving problems and dealing with people all day long is challenging, sometimes intense work. The diversity of questions is great, and customers are almost always in a hurry with an immediate need for answers. This type of work requires special communication skills, problem solving skills, and love for this kind of work. Journal Summary: Types of Users: • Students: Often seeking help with software issues, login problems, or printing. • Faculty: Requesting assistance with advanced features or system integration. • Staff: Needing support for administrative software or hardware issues. Types of Questions: • Basic Troubleshooting: How to reset passwords or resolve connectivity issues. • Software Guidance: Instructions on using specific programs or tools. • Hardware Problems: Issues with printers, computers, or peripherals. Difficulty of Help Desk Work: • Challenging Aspects: Requires patience, problem-solving skills, and the ability to handle a variety of issues efficiently. • Easier Aspects: Routine problems become easier with experience and familiarity with common issues. Skills Needed: • Technical Knowledge: Understanding of hardware and software systems. • Communication Skills: Ability to explain solutions clearly and patiently. • Problem-Solving Abilities: Quick thinking to diagnose and resolve issues. • Customer Service: Providing empathetic and effective support. Overall, help desk work can be demanding but rewarding, requiring a balance of technical proficiency and interpersonal skills. 10-32. Let's say your professor has asked you to help him or her train a new secretary on how to prepare class notes for electronic distribution to class members. Your professor uses word processing software and an e-mail package to prepare and distribute the notes. Assume the secretary knows nothing about either package. Prepare a user task guide that shows the secretary how to complete this task. Answer: The students’ guides should describe the task completely, in addition to any error messages that the user may see if a problem arises. Given that no word processing package or e-mail system was specified, it is not important that the students describe each step in detail. The students should at least present an outline of their user task guide. Alternatively, if the students know of a way to perform this task using a specific word processor and e-mail system, they should describe how it is done. User Task Guide: Preparing and Distributing Class Notes 1. Prepare Class Notes: • Open word processing software. • Create a new document. • Enter and format the notes. • Save the document. 2. Distribute Notes: • Open email package. • Compose a new email. • Attach the saved document. • Enter recipients' email addresses. • Write a brief message. • Send the email. Tips: • Verify formatting before saving. • Check email addresses carefully. 10-33. Study an information systems department with which you are familiar or to which you have access. How does this department measure the effectiveness of systems maintenance? What specific metrics are used, and how are these metrics used to effect changes in maintenance practices? If there is a history of measurements over several years, how can changes in the measurements be explained? Answer: Students are likely to find that their organization of choice is using the classical maintenance organizational structure; that is, the maintenance group is separate from the development group. However, many organizations are trying other structures for organizing this function (especially those that locate development and maintenance staff closer to users), so the students may find other forms being used. Students should find that the managers cite advantages to their particular maintenance organizational structure that are similar to those discussed in the chapter. Have the students compare their answers. If there are differences, have the students discuss why these different structures are being used in these different organizational settings. Similarly, if different reasons for using the same structure are cited across different organizations, have the students explore why different reasons were given. In an information systems department, effectiveness of systems maintenance is typically measured using the following metrics: 1. System Uptime/Downtime: Tracks the availability and reliability of systems. More uptime indicates effective maintenance. 2. Incident Response Time: Measures how quickly maintenance issues are addressed. Shorter times suggest efficient practices. 3. Number of Incidents: Counts the frequency of system problems. Fewer incidents indicate better maintenance. 4. User Satisfaction: Surveys or feedback on system performance and support services. Usage: • Effecting Changes: Metrics guide adjustments in maintenance practices, such as improving response times or addressing recurring issues. • Historical Trends: Changes in metrics over time reflect improvements or declines in maintenance practices, possibly due to updated technology, changes in staff, or evolving system demands. Example: • Improvement: Reduced downtime and faster response times over years might indicate successful updates to maintenance processes or tools. • Decline: Increased incidents could suggest inadequate maintenance practices or aging infrastructure. Overall, these metrics help in continuously refining maintenance strategies for better system performance and user satisfaction. Case Problems Solutions 10-34. Pine Valley Case Exercises Solutions a. Locate a technical writing article on the Web. Briefly summarize this article. Answer: Your students will easily locate numerous technical writing articles. Technical writing Web sites are plentiful and provide much information. If time permits, you can ask your students to present their findings to their classmates. You can also ask your students what was the most useful information that they found. Article Summary: The article discusses best practices in technical writing, focusing on creating clear and effective documentation. Key points include: • Clarity: Use simple, precise language and avoid jargon. • Structure: Organize content with headings, bullet points, and a logical flow. • Audience: Tailor the content to the needs and knowledge level of the intended readers. • Visuals: Incorporate diagrams, screenshots, and charts to support and clarify text. • Revisions: Regularly review and update documentation based on user feedback and changes in technology. This summary highlights essential practices for creating high-quality technical documentation. b. Which installation options are available for the Customer Tracking System? Which would you recommend? Answer: Pine Valley has several installation options, and each installation option has its merits and related problems. The most likely options are the direct and phased approaches. The direct installation is the riskiest alternative; phased installation limits the potential harm and costs PVF might incur. c. How can you determine if implementation has been successful? Answer: There are many ways for Pine Valley to determine if implementation has been successful. However, as the chapter suggests, the two most common ways are the extent to which the Customer Tracking System is used and the user’s satisfaction with this new system. d. What conditions are necessary for a successful implementation effort? Answer: The conditions most influential to a successful implementation effort are management support and the end user’s involvement. 10-35. Hoosier Burger Case Exercises Solutions a. What types of training will Hoosier Burger’s end users need? Answer: For the wait staff and cooks, user training is needed. Bob and Thelma can benefit from training in several areas; these areas include system use, general computing concepts, information system concepts, system management, and system installation. b. What types of documentation would you recommend for Hoosier Burger’s end users? Answer: Since Hoosier Burger’s new system should be easy to use, the delivery personnel, wait staff, and cooks may benefit from a reference guide, quick reference guide, and user’s guide. Since Bob and Thelma are involved with the system on different levels, they will benefit from several types of documentation. In particular, they will need a system administrator’s guide, a release description, and acceptance sign-off. c. Which installation strategy would you recommend pursuing? Answer: Hoosier Burger has several options. Since the new system is small and the risks associated with the system are small to moderate, the direct installation approach is an attractive alternative. d. What support issues should be considered? Answer: At a minimum, types of support include recovery and backup, disaster recovery, appropriate documentation, and PC maintenance. 10-36. Kitchen Plus Case Exercise Solutions a. Identify the tasks involved in project closedown. Answer: As mentioned in Chapter 2 and again in this chapter, project closedown involves closing down the project, conducting post project reviews, and closing the customer contract. Tasks Involved in Project Closedown: 1. Finalize Deliverables: Ensure all project outputs are completed and meet quality standards. 2. Obtain Client Approval: Get formal acceptance of deliverables from the client or stakeholders. 3. Complete Documentation: Finalize and archive all project documentation and records. 4. Conduct Post-Mortem Analysis: Review project performance, identify lessons learned, and document improvements. 5. Release Resources: Reallocate or release project resources, including team members and equipment. 6. Settle Finances: Complete final budget reconciliation and resolve any outstanding payments or financial issues. 7. Close Contracts: Finalize and close out any contracts or agreements related to the project. These tasks ensure that all aspects of the project are properly concluded and documented. b. How would you evaluate Joe’s performance? Answer: Joe’s performance will promote much discussion among the students. You should ask them what type of punishment (if any) Joe should receive. Several students will recommend termination; others will recommend a severe reprimand. To evaluate Joe’s performance, consider the following criteria: 1. Achievement of Goals: Did Joe meet the project objectives and deadlines? 2. Quality of Work: Was the work completed to a high standard and free of errors? 3. Skill Application: Did Joe effectively apply relevant skills and knowledge? 4. Problem-Solving: How well did Joe handle challenges and find solutions? 5. Team Collaboration: Was Joe cooperative and communicative with team members? 6. Adaptability: Did Joe adjust well to changes and new requirements? These criteria provide a comprehensive assessment of Joe’s performance in various aspects of his role. c. What types of maintenance problems can you expect from this information system? Answer: This system is like many other systems. The maintenance personnel can expect corrective, adaptive, perfective, and preventive maintenance issues to arise. d. What factors will influence the maintainability of this system? Answer: Latent defects, number of customers for a given system, quality of system documentation, maintenance personnel, tools, and well-structured programs are factors that influence a system’s maintainability. Petrie’s Electronics Case Question Solutions 10-37. Why don’t information systems projects work out as planned? What causes the differences between the plan and reality? Answer: Information systems projects often do not work out as planned for the same reason most projects don’t work out as planned – requirements change, resources change (increase or decrease), managers change (new managers might have different priorities and other plans), or it becomes evident the problem was not well understood initially so that the original solution is not feasible. 10-38. Why is it important to document change requests? What happens if a development team doesn’t? Answer: Requests to change the system go against the original plan, so they add work, cost, and time, and they change functionality. They replace or augment parts of the original plan, so they have to be documented as such. If change requests are not documents, then the actual functionality of the system is not documented, so no one will know what the system will actually do or how different components might interact. Further, management analyses will not take into account the added work, cost and time. 10-39. When a project is late, do you think that adding more people to do the work helps or not? Justify your answer. Answer: This question was answered by Brooks in the Mythical Man Month many years ago. While it is intuitive to think that adding people should help make a late project get back on time, adding people actually makes things worse. More people means more coordination between people and actually slows the project down even more. Adding more people to a late project can often hurt rather than help due to Brooks' Law, which states that "adding manpower to a late software project makes it later." Reasons include: 1. Increased Complexity: More team members can complicate communication and coordination. 2. Training Time: Newcomers need time to get up to speed, which can delay progress further. 3. Resource Dilution: Existing resources may be spread thinner, reducing overall efficiency. However, if properly managed, adding skilled and experienced personnel may help if the project suffers from a shortage of expertise. 10-40. What is the role of a pilot project in information systems analysis? Why do you think the Petrie’s team decided to do a pilot project before rolling out the customer loyalty system for everyone? Answer: Pilots give a project team the opportunity to observe the system in operation, so they can see what works and what doesn’t before deploying the system more widely. Problems can be identified and addressed, affecting few employees or customers. When the problems have been corrected, the system can then be rolled out to the rest of the company. This is the basic logic behind Jim and his team’s decision to have a pilot project. 10-41. Information systems development projects are said to fail if they are late, go over budget, or do not contain all of the functionality they were designed to have. Is the customer loyalty program a failure? Justify your answer. If not, how can failure be prevented? Is it important to avert failure? Why or why not? Answer: While it appears that the system has the designed functionality, it will be both late and over budget. By those measures, the system is a failure. However, calling the system a failure may be a little premature, as a pilot has not even been run yet. Once the pilot has been run, Jim will be in a better position to judge the system’s status. (On the other hand, some students may see the system as a failure now and be able to justify that view.) If the system has all the functionality it was designed to have and works as promised, and the cost and time overruns are relatively small, management may judge the system to be a success after all, especially if customers like it and use it and the system is associated with increased sales. Large cost and time overruns might diminish the success of the system, though, even if the functionality is delivered and customers are happy with the final result. Is it important to avert failure? Generally, yes, as success makes stakeholders happy and can lead to new and bigger projects for people like Jim down the road. No one likes failure. (Some students might have a different view, which could lead to some interesting class discussions.) Solution Manual for Essentials of Systems Analysis and Design Joseph S. Valacich, Joey F. George, Jeffrey A. Hoffer 9780133546231