Software Engineering: A Methodical Approach (2014)
PART E. Software Implementation and Management
This division addresses the implementation and management of computer software. The objectives of this division are as follows:
· To emphasize the importance of having a wise software implementation plan
· To underscore the importance of good software management as an essential aspect of good software engineering
· To discuss the alternatives for organizing software engineering enterprises and/or ventures
The division consists of the following chapters:
· Chapter 17 — Software Implementation Issues
· Chapter 18 — Software Management
· Chapter 19 — Organizing for Effective Management
Chapter 17. Software Implementation Issues
Having successfully engineered the software product, it must be implemented in an environment where end users will find it useful. Unless this is done, the whole effort involved in investigation, analysis, design and development of the product would have been pointless. This chapter discusses important software implementation issues under the following subheadings:
· Introduction
· Operating Environment
· Installation of the System
· Code Conversion
· Change Over
· Training
· Marketing of the Software
· Summary and Concluding Remarks
17.1 Introduction
Irrespective of how the software is acquired (review chapter 1), it must eventually be implemented. Planning and preparation for this system implementation should start long before the completion of the acquisition. If the implementation is not carefully planned and all factors considered, the exercise can be very frustrating and misrepresenting of the system and professionals responsible for its introduction.
Poor implementation can cause the failure and rejection of a well-designed software system that actually meets the needs of its intended users. This underscores that software engineering does not end after product development. Users must be trained to use the product. To this end, the system must be installed, configured and monitored. If your organization is in the business of marketing computer software, then part of the implementation would be the development and pursuit of a marketing plan for the product. These and other related matters will be addressed in the upcoming sections.
17.2 Operating Environment
Consideration about the operating environment addresses the following questions:
· Will the system be centrally operated, or will a distributed computing environment be in place?
· What precautions will be necessary, given the environmental constraints?
17.2.1 Central System
The centralized approach is the traditional approach, where the software system runs on a particular machine, and is inaccessible except through that machine. Traditionally, data processing (DP) departments used this approach to manage centralized information systems that provided information services for the other departments in the organization. All data entry, maintenance, and processing were done centrally and reports were sent to various departments. This approach was (and still is) particularly useful in a batch-processing environment.
Advantages of this approach are as follows:
· There is a central locus of control, which allows for easy tracking of system problems.
· There is little or no ambiguity about accountability.
· The approach is ideal for embedded systems that do not need to interact with multiple end users.
The approach suffers from the following disadvantages:
· For information systems, the likelihood of interdepartmental delays regarding the transfer of information is very high. Information may therefore not arrive at the computing center on time. This would trigger a late entry of data into the system, which in turn would cause the late generation of reports. This lateness factor could ripple through the entire organization, causing untold problems.
· The organization’s information system would not very responsive.
· The approach is very restrictive and inflexible.
17.2.2 Distributed System
The distributed approach is the contemporary approach to software system implementation. All users have access to the software system (via work-stations). Data enters the system at various points of origin — via workstations operated by users in different departments, or via electronic transfers (that may be transparent to end users). The software system is accessed by various end-users as required without any intervention from the software engineering team.
Two broad approaches can be identified:
1. Distributed workstations are connected to a central network server in a local area network (LAN), a wide area network (WAN), or a metropolitan area network (MAN).
2. A distributed network (LAN, WAN or MAN), consisting of a conglomeration of servers and workstations, and encompassing different departments and/or branches, is constructed and managed.
There may be various configurations (topologies) of each approach, but this is a subject for another course (in either electronic communication systems or computer networks).
Advantages of the distributed approach include the following:
· The approach is ideal for multi-user environments.
· For information systems, immediate access to the system (especially mission critical information) is provided.
· For information systems, accountability on data accuracy is shifted from the software engineering team to user departments.
· The software engineering team can concentrate on ensuring that the system provides users with appropriate interfaces, data validity, system performance and other technical issues.
· Through user training and interaction, a clearer understanding between end-users and software engineering team is enhanced.
Disadvantages of the approach include the following:
· User training can be challenging. For information systems, even after comprehensive training, the odd user may key in inaccurate data and try to blame “the system” or the “IS/IT Department.”
· In the absence of adequately trained personnel, this approach could be a prescription for chaos.
17.2.3 Other Environmental Issues
Other environmental issues to be addressed in software implementation include (review chapter 3)
· The availability of adequate power supply
· Cooling (or heating) requirements
· Physical security and accessibility requirements
17.3 Installation of the System
In preparation for system installation, a fundamental question to address is whether the installation will involve new machines or just software.
If new machines are involved, an installation diagram (plan) showing where certain equipment will go, is required. Consideration must be given to the various installation alternatives (for example, in the case of a computer network various topologies apply) and the most appropriate one chosen.
If installation involves software only, then consideration should be given to
· The effect on the existing system
· Precautions involved
· Sites of installation (in case of a distributed system)
If installation involves both hardware and software, then obviously, considerations must be given to both areas as outlined above.
17.4 Code Conversion
Code conversion is applicable where a software system replaces an existing one, and the coding system used to identify data in one system is different in the other. In such a circumstance, the software engineer must do the following:
· Analyze both systems and clearly identify points of differences in the coding systems.
· Design and test a methodology of linking the differing coding systems.
· Design and test a methodology for converting data from the old format to the new format.
In many cases, some amount of interface coding is necessary. Figure 17-1 represents the main components of a code conversion system, while Figure 17-2 provides an example. The interface program(s) provide(s) conversion and communication between old and new codes.
Figure 17-1. Components of a Code-Conversion System
Figure 17-2. Code Conversion Example
17.5 Change Over
The previous section provided a clue to the current section: change over from an old software system to a new one. Four strategies can be identified:
· Direct changeover
· Parallel conversion
· Phased conversion
· Distributed conversion
17.5.1 Direct Change Over
The essence of direct changeover approach is that on a given date, the old system is dropped and the new system is put into use. After changeover, users cannot use the old system.
This approach can only be pursued if the new system (with all interfaces) is thoroughly tested and shown to be completely acceptable. At best, a minimal delay is expected.
17.5.2 Parallel Conversion
In the parallel conversion approach, the new and old systems are simultaneously run until users are satisfied with the new system. Then and only then is the old system discarded. This is traditionally the strategy used in converting from manual to computerized systems, but it may also be applied to changeover from an old computerized system to a newer one.
The approach gives users a sense of security, but is costly in terms of effort. This is so because in some cases, two sets of workers have to be employed to work on the parallel systems; in others cases, employees may be called upon to work overtime.
17.5.3 Phased Conversion
In phased conversion, change from old to new is gradual over a period of time. Aspects of the new system are gradually introduced. The approach is consistent with the phased prototype model of Chapter 1, but also applies to situations where the system was acquired by other methods apart from direct development.
The main drawback in phased conversion can be protracted over an extended period of time. This could potentially create anxiety between the project team and end users.
One advantage is that each component is thoroughly tested before use. Also, users are familiar with each component before it becomes operational. The main drawback is that of interfacing among components.
17.5.4 Distributed Conversion
In the distributed conversion approach, many installations of the same system are contemplated. Based on the evaluations of these installations a decision is made with respect to global implementation.
The approach is very common in large financial institutions with several branch offices (e.g. introducing ATM machines at various sites, a bank take-over, etc.).
17.6 Training
Training of end users is an integral part of software engineering. The training strategies are often determined by the following issues:
· Who is being trained
· Who is conducting the training
· What resources are available for the training
· Where the training will be conducted
Training may be conducted by software engineers, vendors, or in-house users of the software system. The following table (Figure 17-3) provides a rough guideline as to who may conduct training, given certain circumstances.
Figure 17-3. Who Should Train?
Training may be conducted at a specific (and specially prepared) training center, or on-site (at the request of the organization or department receiving the training), the latter being more expensive.
Training objectives (and performance criteria) must be clearly communicated to trainees as this helps them to appreciate what is expected of them, and to adequately prepare for the exercise. Who is being trained will affect the training objectives. For example, clerical staff for data entry requires a different approach from managers of an organization.
Methods used in training should involve visual, hearing, and practical (hands-on training) as is appropriate.
Training materials must be well prepared. Training materials are usually in the form of user guides, summary sheets and workbooks.
If trainee evaluation is required, it must be objective and based on the established performance criteria set. In some instances, the instructor may also be evaluated by the trainees, as a means of quality assurance by the company (or department) offering the training.
17.7 Marketing of the Software
If the product was developed by a software engineering company, to be placed on the market as a consumer product, then the earlier mentioned issues would be part of a much larger marketing strategy.
Issues such as operating environment, installation and code conversion, would be addressed in the product documentation. Changeover would be left up to the purchasing consumer. Training might be handled by the company, or other vendors who might be marketing the product.
Contemporary marketing strategies are typically based on the following five principles:
· Product: This relates to the product line(s) the software will be marketed with/as.
· Pricing: This relates to how the software will be priced (review Chapter 16).
· Promotion: This includes both positioning and packaging of the software. Positioning relates to how the product is introduced and marketed in the market place. Packaging relates to what other products that are marketed with the software.
· Placement (or Physical Distribution): This relates to the avenues through which the product eventually gets to the consumer.
· People: This relates to the customer services (including training and support) that will be provided for the product.
The marketing strategy is typically guided by a market research, which is planned and conducted by suitably qualified individuals. The findings of the research are then used to drive the marketing strategy.
17.8 Summary and Concluding Remarks
Here is a summary of what we have discussed in this chapter:
· Planning the software implementation is critical to the user acceptance of the software system.
· The operating environment for the software product may be a central system, or a distributed system.
· System installation must be carefully planned.
· If the software system is replacing a pre-existing system, then the matters of code conversion and system changeover become very important.
· System changeover may be direct, parallel, phased, or distributed.
· Implementation often requires training of the end users. This must be carefully planned.
· If the software system is to be marketed to the consuming public, then a marketing plan for the product must be developed and followed.
The following deliverables should be available at the end of a software engineering project:
· Initial System Requirements
· Feasibility Analysis Report
· Requirements Specification
· Design Specification
· System Manual(s)
· User's Guide(s)
· Help System
· The operational Software Product
The requirement specification, design specification, system manual(s), user guide(s) and help system constitute the software documentation. These items must be maintained along with the operational product. The next chapter will discuss software maintenance.
17.9 Review Questions
1. What are the critical issues to be managed during the software implementation?
2. If you were in charge of outlaying your college or university with a strategic information system for its core functions:
· What operating environment would you consider? Why?
· Describe a plan for the training of the faculty and staff.
· What strategy would you use for transitioning from an archaic system on which the institution relied heavily, to your new system? What precautions would you take?
3. Discuss the importance and relevance of code conversion during software implementation.
4. What are the possible approaches to system changeover? When would you use each approach?
5. What guidelines would you follow in conducting user training for a new software system?
17.10 Recommended Readings
[Kendall, 2005] Kendall, Kenneth E. and Julia E. Kendall. Systems Analysis and Design 6th ed. Upper Saddle River, NJ: Prentice Hall, 2005. See Chapter 17.
[Pfleeger, 2006] Pfleeger, Shari Lawrence. Software Engineering Theory and Practice 3rd ed. Upper Saddle River, NJ: Prentice Hall, 2006. See Chapters 10 and 11.
[Schach, 2005] Schach, Stephen R. Object-Oriented and Classical Software Engineering 6th ed. Boston, MA: McGraw-Hill, 2005. See Chapter 14.