Implementation

Implementation

76.1 Purpose

Implementation is the process of completing the system and turning it over to the user. This chapter discusses site preparation, documentation preparation, personnel training, system cutover, and system release.

76.2 Strengths, weaknesses, and limitations

As appropriate, the strengths and weaknesses associated with various techniques will be discussed in context.

76.3 Inputs and related ideas

Implementation occurs after the system has been analyzed, designed, constructed, and tested. Consequently, the results generated by all the tools and techniques covered in all preceding chapters can be considered inputs to the implementation phase. Additionally, the tasks performed during implementation set the stage for system operation and maintenance (Part VIII).

This chapter references (directly or indirectly) Chapters 31 (prototyping), 32 (rapid application development), 42 (hardware interface design), 67 (knowledge representation), 70 (documentation design), and 71 (security design).

76.4 Concepts

Implementation is the process of completing the system and turning it over to the user. This chapter discusses site preparation, documentation preparation, personnel training, system cutover, and system release.

76.4.1 Site preparation

Site preparation involves preparing the work environment, installing the hardware, and configuring any new equipment to work with existing computers and peripherals. See Chapter 42 for a discussion of hardware interface design.

The work environment must include sufficient space to hold the computer, its peripherals, desks, storage cabinets, printer stands, and other furniture, and to store such supplies as paper, ribbons, disks, backup media, forms, cleaning supplies, documentation, and procedure manuals. Wiring, communication lines, and other physical connections must be installed. A raised floor might be needed. Security features might be required.

A dependable power supply is essential. Large computer systems often require custom-designed power supplies. Although most small computer systems run on standard household current, the equipment can easily tax the limits of existing wiring (particularly in older buildings), so rewiring might be necessary. Surge protectors and an uninterruptable power source (UPS) are recommended for most systems.

Air conditioning is another factor. Computers are heat sensitive, and heat-related problems are difficult to trace. The computer itself generates heat, and that can add to the air conditioning load. The cost of inadequate air conditioning is often measured in excessive downtime and high maintenance costs.

Ergonomic requirements are intended to provide the users with a comfortable working environment. Key parameters include lighting, glare, airflow, noise, temperature, humidity, workspace, and the design of the furniture. Many organizations have implemented ergonomic standards.

76.4.2 Documentation preparation

Documentation consists of the specifications, instructions, tutorials, reference guides, and similar materials that accompany and explain a piece of software or a hardware component. A complete set of user documentation, systems documentation, software documentation, and operations documentation must be available to support the implementation process. In addition to procedures for performing system tasks, preparing paperwork, entering data, and distributing output, documentation for backup, recovery, auditing, and security procedures is also needed. Documentation tells the users how to operate the system, helps to resolve problems and errors, and supports the training process.

76.4.3 Training

Before the system is released, the users, system maintenance personnel, system operators, and other people affected by the system must be trained. The user manual and the written procedures form the core of the training plan. Initially, the analysts and other technical experts should show the users how to perform the various tasks. Gradually, the experts should do less and the users more until the users clearly understand the system. Following the initial intensive training period, the users should begin to work on their own, but the experts should be available to provide quick, accurate technical support. Over time the level of technical support should decline, but facilities for answering user questions (e.g., a help facility) should be maintained for the life of the system.

In addition to the primary users and system support people, back-up personnel must also be trained. Often the primary person trains his or her backup. People retire, resign, suffer injuries and illnesses, and earn promotions, so there will be turnover. Training does not end when the system is released; it is an ongoing activity.

In-house training is suitable when the system is developed internally. The training can be tailored to the system and the organization’s environment, touching on the relationship between the new system and existing systems and stressing user interests and needs. Unfortunately, users sometimes undervalue in-house training because they believe the in-house experts will always be available to provide assistance on request.

Third party training includes vendor-supplied training, developer-supplied training, and training from independent outside services. Such training is common when a company lacks in-house information system support or has no on-going training program, or when a third party develops the system.

Some training is done in a traditional classroom environment. In other cases, the trainer goes to the trainee, perhaps providing one-on-one or small group training on specific equipment or in the user’s environment. Videoconferencing is an economical training medium for a relatively brief time (hours, days, or weeks). Distance learning (via satellite or other communication media) is effective for longer periods (weeks, months, years). Interactive training software (on tape or CD) is both popular and cost effective. Computer-based training (CBT) utilizes the computer as a training tool; for example, an instruction system is a type of expert system (Chapter 67) that implements computer-based training.

76.4.4 Cutover strategies

System cutover is the process of turning the system over (or releasing the system) to the user. Some experts believe that a system should be released any weekday before Thursday, thus giving the users at least one day (Friday) to experiment and giving the installers the weekend to fix any last-minute problems. Other experts believe that a system should be released on Friday, thus giving the installers three full days to complete the installation before the users begin working with it. Friday conversion is more conservative.

Several cutover strategies are outlined below.

76.4.4.1 Direct cutover

With direct cutover (sometimes called crash cutover, or abrupt cutover), the old system is discontinued on a predefined date (often corresponding to the start of a new accounting period) and the entire organization switches directly to the new system. Direct cutover is risky because, if the new system fails, returning to the old system is virtually impossible. This strategy is relatively inexpensive, however, and it tends to promote user acceptance since there is no old system to serve as a basis for comparison. Direct cutover is often used in response to a government mandate (such as the implementation of new income tax withholding rules) or other legal concerns.

76.4.4.2 Parallel operation

As the term suggests, parallel operation means that the old and the new systems run in parallel for a time. Typically, the source data are processed twice, the results are compared, any discrepancies are carefully analyzed, and appropriate corrections are made. Note that a discrepancy might represent an error in the oldsystem.

Parallel operation is less risky than direct cutover, but concurrently running two systems is expensive. Parallel operation tends to be most effective when a computer-based system replaces a manual (or partially manual) system because concurrently running two computer-based systems is very expensive. It is an excellent choice when data accuracy, security, and/or reliability are important concerns. One intangible benefit of parallel operation is the opportunity to build user confidence in the new system (assuming it runs properly, of course) by comparing the new and old systems’ results.

76.4.4.3 Gradual cutover

Gradual cutover is a combination of direct and parallel. The idea is to run the new and old systems concurrently and gradually increase the number of transactions handled by the new system. Note that the data are notprocessed twice. Instead, some transactions are processed by the old system, some are processed by the new system, and the percentage sent to the new system gradually increases until the old system fades away.

76.4.4.4 Phased implementation

In a phased implementation, or partial conversion, the new system is released in stages, either by application or by location. For example, new data collection procedures might be implemented first, followed by inventory updating procedures, then new reorder procedures, and so on. Alternatively, the system might be released in one subdivision or location (e.g., a branch office) at a time.

Phased implementation allows for gradual installation and training, reduces user resistance to the new system, and gives the organization considerable flexibility. The installation period is likely to be quite lengthy, however, so phased implementation should not be used when the schedule or the budget is tight.

76.4.4.5 Pilot implementation

In a pilot (or location) implementation, the new system is first released in a single site, such as a branch office or a warehouse, thoroughly tested, and then ported to the other sites. The pilot site is called the beta site. After a pilot implementation, either direct cutover or phased implementation might be used to release the system to the other sites.

Pilot implementation is similar to phased implementation, but the system can be changed based on experiences gained at the pilot site. Pilot implementation is compatible with prototyping (Chapter 31) and rapid application development (Chapter 32). The pilot study gives the developers another opportunity to perfect the system and the rest of the organization is not impacted until the new system (or its prototype) proves its usefulness and reliability. On the other hand, user confidence in the system may be damaged if too many changes are made after the pilot study begins, the results may be biased by the unique characteristics of the pilot site, and system release will be delayed in other parts of the organization.

76.4.5 System release

After the system is installed and stable, it is released, or turned over, to the user. In most cases, the system release or system turnover process includes a formal user sign off that implies user acceptance of the system. If the system was developed in-house, system release marks the end of the developer team’s responsibility. If the system was developed by outside contractors or consultants, system release implies successful completion of the contract.

76.4.6 Post-implementation review

A post-implementation (or post-release) review should be scheduled some time after the system is released. During the post-implementation review the developers should investigate any remaining problems and compare the project’s objectives, cost estimates, and schedules to the actual outcomes. The idea is not simply to find discrepancies, but to explain them. Knowing why mistakes were made is the key to improving the organization’s analysis, design, scheduling, and cost estimating procedures.

During the post-implementation review, such general concepts as the design philosophy and the design strategy should be discussed. The hardware platform, the inputs, the outputs, the interfaces, the dialogues, the processes, the files and databases, and the documentation should all be carefully studied to ensure that the system performs as designed.

76.5 Key terms

Beta site —

The pilot site in a pilot implementation.

Cutover —

The process of turning the system over to the user; see also system release.

Direct cutover (crash cutover, abrupt cutover) —

A system release strategy in which the old system is discontinued on a predefined date and the entire organization switches directly to the new system.

Documentation —

The specifications, instructions, tutorials, reference guides, and similar materials that accompany and explain a piece of software or a hardware component.

Ergonomics —

The study of the relationship between human beings and their workplaces.

Gradual cutover —

A system release strategy in which the new and old systems run concurrently and the number of transactions handled by the new system is gradually increased.

Implementation —

The process of completing the system and turning it over to the user.

Parallel operation —

A system release strategy in which the old and the new systems run in parallel for a time.

Phased implementation (partial conversion) —

A system release strategy in which the new system is released in stages.

Pilot implementation (location implementation) —

A system release strategy in which the new system is first released in a single site, such as a branch office or a warehouse, thoroughly tested, and then por-ted to the other sites.

Post-implementation review (post-release review) —

A review of the system development process conducted after the system is released.

Site preparation —

The process of preparing the work environment, installing the hardware, and configuring any new equipment to work with existing computers and peripherals.

System release —

The stage in the system development life cycle when the system is turned over to the user.

Training —

Generally, a series of experiences designed to modify behavior; often, a set of activities designed to teach someone how to do something.

76.6 Software

Not applicable.

76.7 References

  1. Beizer, B., Software Testing and Quality Assurance, Van Nostrand Reinhold, New York, 1984.

  2. Beizer, B., Software Testing Techniques, Van Nostrand Reinhold, New York, 1983.

  3. Burch, J. G., Systems Analysis, Design, and Implementation, Boyd & Fraser, Boston, MA, 1992.

  4. Capron, H. L., Systems Analysis and Design, Benjamin/Cummings, Redwood City, CA, 1986.

  5. Davis, W. S., Business Systems Analysis and Design, Wadsworth, Belmont, CA, 1994.

  6. Dewitz, S. D., Systems Analysis and Design and the Transition to Objects, McGraw-Hill, New York, 1996.

  7. Fournier, R., Practical Guide to Structured System Development and Maintenance, Prentice-Hall, Englewood Cliffs, NJ, 1991.

  8. Howden, W. E., Functional Program Testing & Analysis, McGraw-Hill, New York, 1987.

  9. Hoffer, J. A., George, J. F., and Valacich, J. S., Modern Systems Analysis and Design, Benjamin/Cummings, Redwood City, CA, 1996.

10.  King, D., Creating Effective Software: Computer Program Design Using the Jackson Methodology, Prentice-Hall, Englewood Cliffs, NJ, 1988.

11.  Lamb, D. A., Software Engineering: Planning for Change, Prentice-Hall, Englewood Cliffs, NJ, 1988.

12.  Norman, R. J., Object-Oriented Systems Analysis and Design, Prentice-Hall, Upper Saddle River, NJ, 1996.

13.  Power, M. J., Cheney, P. H., and Crow, G., Structured Systems Development: Analysis, Design, Implementation, 2nd ed., Boyd & Fraser, Boston, MA, 1990.

14.  Pressman, R. S., Software Engineering: A Practitioner’s Approach, 2nd ed., McGraw-Hill, New York, 1987.

15.  Saldarini, R. A., Analysis and Design of Business Information Systems, Macmillan, New York, 1989.