Pvf's Purchasing System Implementation

Answers to Problems and Exercises

1. PVF's Purchasing Fulfillment System involves the following processes: get supplier data, get material data, generate supplier description, generate purchased goods specifications, and put materials orders, as well as other processes. Your students should describe whether they will employ stub testing, integration testing, system testing, or some combination of these testing methods. Students should also defend their choices. In creating the testing plan, your students should also think through the potential problem areas, list these areas, and develop ways to test for problems. The students should come up with a list of test cases, each of which may contain several individual tests, and then group these test cases into test cycles (see Figures 17-4 and 17-5).

2. PVF's Purchasing Department plays a central role in the operations of this manufacturing firm. Given the current concerns for delays in placing vendor orders and the growing use of just-in-time inventory control methods, PVF needs a relatively smooth, quick, and safe installation method. Thus, a parallel or phased conversion makes the most sense. The feasibility of a phased approach depends on how easy it is to unplug current modules and plug in new modules. A combination of parallel and phased is the most viable. A direct conversion is too risky, and single location conversion is not applicable for this one location situation. The inventory management system is equally important to the operations of Hoosier Burger, although this system is relatively smaller and simpler than the Purchasing Fulfillment System at PVF. Thus, in addition to the parallel or phased conversion, a direct conversion is feasible for Hoosier Burger, if the risk is deemed tolerable. The single location conversion also is not applicable for Hoosier Burger.

3. Students should first refer to the chapter's discussion of the four conversion methods. Students should pull from the discussion the essential characteristics of each of these methods and then derive a list of criteria to use to compare the four methods. Your students can use criteria such as risk, speed, cost, simplicity, time until installation begins and benefits of the new system are achieved, ability to identify and correct errors, confusion for users, and scope of problems with the new system. Next, your students should create a table with the four conversion methods on one axis and the criteria on the other axis. Your students should then fill in the boxes of the matrix with short descriptions for each method on each criterion; most comments can be taken from the text.

4. There are many factors to consider when choosing a (or several) pilot site for a single location conversion. You can choose a site that provides for a relatively simple, manageable pilot conversion, thereby increasing the chances of having a successful installation. Such a site might have a small number of users, might be relatively convenient for systems staff, and is willing to be an early adopter. On the other hand, you can choose a larger, more complex site for the pilot, to better test the quality of the system and/or to better prove to people that the system was well developed. Alternatively, you can choose a relatively high profile site, to increase the visibility of the new system. On the other hand, you can choose a relatively low profile site, so that the installation is not "under the microscope" of everyone in the organization. If possible, you can pick several sites that satisfy several criteria to get a representative mix. How the site is chosen and what factors are used is different for every situation. It all depends on what you want to accomplish with the installation.

5. It is important that, on whatever system your students choose to focus their answer, they present a logical set of criteria to use to judge whether their system is ready for general distribution. For example, if a student chooses a word processor, the student should present a convincing set of arguments for judging whether or not this single-user, shrink-wrapped software package is ready for mass distribution. For this type of system, massive beta testing should be conducted over a long period of time and with a great variety of users. Great care should be taken to ensure that this word processor at least matches and, preferably, goes beyond the capabilities of its competing word processing packages. Valid, reliable measures of usability should be established. The package should be reliable and nondestructive of data even when it fails. Security is an issue for some users. Ultimately, extensive acceptance testing within the target market of users should be conducted. Testing should cover the software and its printed documentation, on-line help, and technical support.

6. 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 helps the systems personnel 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.

7. Students have different views for this question. For example, they may argue that documentation should be as brief, graphical, to-the-point as possible, and available when needed but no sooner. Also, the importance of documentation is not necessarily how much documentation has been prepared; rather, it is important that the documentation