Software Management - Software Implementation and Management - Software Engineering: A Methodical Approach (2014)

Software Engineering: A Methodical Approach (2014)

PART E. Software Implementation and Management

Chapter 18. Software Management

This chapter discusses software management as a vital part of the software engineering experience. As you are aware, it is the final phase of the SDLC. However, the truth is, unless you are very lucky, it is the most likely entry point into a career as a software engineer: In the marketplace, you will most likely have to start off by carrying out management responsibilities on existing software before you get a chance to develop a complete system from scratch. Being part of a proje0ct team that develops a major system from scratch is an achievement that every software engineer should aspire to experience at least once in his/her career. However, it is probably worth remembering that many practicing software engineers never experience this.

Software management involves product maintenance, product integration and product reengineering. Against this background, the chapter proceeds under the following captions:

· Introduction

· Software Maintenance

· Legacy Systems

· Software Integration

· Software Re-engineering

· Summary and Concluding Remarks

18.1 Introduction

Once the software has been implemented, it then enters a usage phase. During this time, the requirements of the software may change. Software maintenance ensures that the software remains relevant for the duration of its life cycle. Failure to maintain the software can reduce its life cycle, thus making it irrelevant and/or unwanted.

If, due to design and/or development flaws, or obsolescence, it has been determined that the cost of maintaining the software (nearly) outweighs the cost of replacing it, then at such point, a decision needs to be taken about the future role and usefulness of the software as well as its possible replacement. However, in the absence of such critical circumstance, the software must be maintained.

As you proceed through this chapter, bear in mind that various factors will affect the management decisions taken about a software product. Three such factors are mentioned in Figure 18-1.

image

Figure 18-1. Factors Affecting Software Management Decisions

18.2 Software Maintenance

In order to ensure that the software product remains relevant, despite the changing requirements of the user environment(s), software maintenance is necessary. We shall examine software maintenance under three subheadings:

· Software Modifications

· Software Upgrades and Patches

· Maintenance Cost

18.2.1 Software Modifications

Software modifications may be put into three broad classifications:

· Enhancements

· Adaptive changes

· Corrective changes

Enhancements are modifications that add to the usefulness of the software. Enhancements may add/improve features, add/improve functionality, or broaden the scope of the software. Most software changes tend to be enhancements.

Adaptive changes are peripheral changes, caused mainly due to changes in the operational environment of the software.

Corrective changes address flaws (bugs) in the software; a well-designed software product will have few bugs. Poorly designed software systems tend to have more bugs than well-designed ones.

Software modifications are not to be made in a flippant manner, but in a manner that ensures that established standards are conformed with. Typically the software manager establishes a formal organizational procedure for effecting software change. It may include activities such as

· Request by user on a standard change-request form (as illustrated in Figure 18-2)

image

Figure 18-2. System Modification Request

· Evaluation of the request by a user liaison officer and/or the software manager

· Evaluation of the request by a software engineer

· Decision taken on the request

· Action taken in response to the request

18.2.2 Software Upgrades and Patches

A software upgrade is a modification to a software product to improve its functionality or performance in specific areas. The upgrade may be in any combination of the following possibilities:

· Addition of new features (and possibly program files) that seamlessly integrate into the existing software

· Improvement of existing features and/or functionalities by replacement of existing program files with revised program files

· Removal of known bugs by replacement of existing program files with revised program files

Software engineering companies that market products to the consuming public usually issue software upgrades in the form of releases. Traditionally, software releases are typically numbered in the format that the sections of this text are numbered. However, a more recent trend is to number the versions based on the year of release and to add descriptive qualities to the version names. Following are three examples in three different product lines:

· Early versions of Borland Delphi were of the form V1Rx (or V1.x) up to V8Rx (or V8.x). This was followed by releases of Delphi 2006 Professional, Delphi 2006 Architect, and Delphi 2006 Enterprise; this trend continued into 2010 versions of the product line (except that it is now marketed by Embarcadero, and not Borland). Since then, the version names have been Delphi XE, Delphi XE2, Delphi XE3, and Delphi XE4.

· Microsoft product lines have been consistently named based on the year of introduction.

· Companies such as Oracle and IBM tend to favor the more traditional approach along with descriptive names, but Oracle applies a slight deviation, using version names such as Oracle 9I, Oracle 10G, Oracle 11G, and Oracle 12C.

If you are working for an organization that does not market its software systems, this meticulous version naming convention may not be necessary, but would nonetheless be advantageous.

Software upgrades from these established software engineering companies are usually made available via common portable storage media as well as via downloads from the World Wide Web (WWW). Again, if your organization is not in the business of marketing its software products, then this approach may or may not be necessary, depending on the prevailing circumstances.

A software patch is a modification to a software product to improve its functionality or performance in specific areas. The patch is more narrowly focused than an upgrade; it may be in any combination of the following possibilities:

· Improvement of existing features and/or functionalities by replacement of existing program files with revised program files

· Removal of known bugs by replacement of existing program files with revised program files

Software engineering companies that market products to the consuming public usually issue software patches in the form of service patches (SP). They are typically numbered sequentially (example SP1, SP2, etc.), with clear indications to consumers as to what versions (releases) of the software product, the patches relate to. Patches are commonly made available via the WWW, but may also be placed on common portable storage media.

18.2.3 Maintenance Cost

The more poorly designed the software, the more maintenance will be required and the higher will the maintenance cost be. Conversely, the better the design, the lower the maintenance cost is likely to be.

Maintenance cost is influenced by the following factors:

· Lifetime of the software: In many (but not all) cases, longer lifetime means more maintenance.

· Quality of the software design: Generally speaking, poor design leads to high maintenance cost.

· Amount of changes required: The greater the number of changes required, the higher the maintenance cost is likely to be.

· Quality and stability of the support staff: A very skilled and stable support staff is likely to reduce the maintenance cost.

· Complexity of software design and configuration: The more complex the design, the higher the maintenance cost is likely to be (there may be exceptions to this).

· The development software used (programming language, DBMS, etc.): Maintenance cost may be constrained by the cost of the software development tools employed.

· Software size (in terms of components and source code): Generally speaking, bigger the software system, the higher the maintenance cost (there may be exceptions to this).

As software engineering becomes more standardized, the cost of software maintenance should progressively lessen. If the maintenance cost is going in the opposite direction as time increases, this is a certain alert signal to the organization to be prepared to replace the product at some point in the future.

18.3 Legacy Systems

A legacy system is a system that was constructed using relatively old technology, but its useful life continues within the organization. Companies have legacy systems due to a number of compelling reasons:

1. A company, having made huge investments in a system, is not prepared throw it out, since this would mean significant financial loss.

2. The system might be very large and/or complex. Replacing it would therefore be very costly.

3. The system is mission critical: the company’s life revolves around it.

4. The complete system specification may not be known or documented, so that replacing it could be risky.

5. Business rules may be embedded (hidden) in the software and may not be documented anywhere else. Attempting to replace the software would therefore be risky.

6. Any attempt to replace the system must also include the conduct of a data conversion process that offers (infinitesimally close to) 100% guaranteed success. Companies prefer to delay this ultimate activity until they have no alternative, and/or they are guaranteed success.

There are three alternatives for treating legacy systems:

· Continue maintaining the system. If the system is stable and there are not many user requests for changes, this is the most prudent alternative.

· Scrap the old system and replace it with a new one. This alternative should be pursued when the following conditions hold: Firstly, the old system is showing signs of being a liability rather than an asset, that is, it has (almost) reached its scope of usefulness. Secondly, it has been determined that further maintenance would be an effort in futility. Finally, the company is confident that it has gathered enough information to successfully redesign the system.

· Transform the system to improve its maintainability. This process is referred to as software re-engineering, and will be discussed shortly.

18.4 Software Integration

In many cases, and for a number of reasons, a software product may be excellent in the provision of certain desirable services but deficient in the provision of others. In other cases, it might be difficult to find a single software product that provides all the services that an organization is looking for. Should such organizations abandon the investments made in these individual products, in search of a single product? Not necessarily. Rather, the organization could explore the path of software integration.

In software integration, a number of component software products are made to peacefully coexist – i.e. they are integrated. This is consistent with the CBSE model of earlier chapters (review chapters 1 and 9). In order to provide them with the set of services that they require, large organizations such as banks, insurance companies and universities often use a conglomeration of software products, merged together in an integrated information infrastructure. The term information infrastructure is used to mean the complete environment (hardware and software) of the organization, and is more appropriately discussed in as course in strategic information management.

Software integration has become a very important aspect of software engineering. In recognition of this, large software engineering companies (for example Microsoft, IBM, Oracle, Borland, etc.) typically have the services of integration experts who are specially trained to provide technical advice and expertise to organizations that need to integrate component software products. Evidently, these experts are trained to promote the bias of the companies they represent. However, with some research (and by asking pointed questions), you can obtain a good perspective of what your integration options are. In many cases, the component products may be using different software standards. If this is the case, then the integration team must be prepared to write some interface coding.

Software integration has become a commonplace in contemporary software engineering. As more software products are written to ubiquitous standards, we can anticipate further proliferation of integration options. This is good for the industry, as it will force higher quality software products.

18.5 Software Re-engineering

In a situation where the system quality continues to deteriorate, and the level of user request for changes, as well as the cost of maintenance continues to be high, software re-engineering is the preferred treatment of legacy systems.

Re-engineering may include the following:

· Revising the underlying database of the system (a huge undertaking)

· Using a more modern or sophisticated development software (CASE tool, DBMS suite, or software development kit)

· Refining and/or revising business processes in the organization

· Superimposing a new user interface (wrapper) on top of an existing database

The main activities of software re-engineering are as follows:

· Source code translation or replacement

· Database transformation or replacement (a huge undertaking)

· Reverse engineering (i.e. the existing software is analyzed and the information extracted is used to document its organizational and functional requirements)

· Modernization (related components are grouped together, and redundancies removed; this may involve architectural transformations)

· Data conversion (from old format(s) to new format(s))

Software re-engineering is quite an involved and complex exercise, and must be carried out by qualified and experienced software engineers.

18.6 Summary and Concluding Remarks

It is time once again to summarize what we have covered in this chapter:

· During the usage phase of a software system, it must be managed. Factors affecting effective management of the software include size and complexity, technology, and support.

· Software maintenance involves modifications, upgrade, and the management of maintenance cost. Software modifications may be in the form of enhancements, adaptive changes, or corrective changes. Software upgrades come in the form of releases and service patches. The maintenance cost varies inversely to the software quality.

· A legacy system is a system that was constructed using relatively old technology, but its useful life continues within the organization. The software engineer must be familiar with the different ways of treating legacy systems.

· Software integration is the act of merging different software components so that they peacefully coexist. Component based software engineering (CBSE) has become very popular in recent years.

· Software re-engineering is useful in situations where the system quality continues to deteriorate, and the level of user request for changes, as well as the cost of maintenance continues to be high.

Effective management of a software system can lengthen its useful life, and thereby increase the organization’s return on its investment.

18.7 Review Questions

1. Describe how factors such as complexity, technology and support affect decisions taken about the maintenance of a software product.

2. Consider four categories of software. For each category, discuss how the above-mentioned factors (complexity, technology and support) have an influence on the maintenance programs for software products in each respective category.

3. Describe three types of changes that are likely to be made to a software product during its useful life.

4. What is the difference between a software upgrade and a software patch? Using appropriate examples, explain how engineering companies typically handle software upgrades and patches.

5. State four factors that affect the cost of software maintenance.

6. What are legacy systems? Why do they abound and will likely continue to do so for the foreseeable future? Describe three approaches for dealing with legacy systems.

7. When should software integration be considered? What benefits are likely to accrue from software integration?

8. When should software reengineering be considered? Describe the main activities that are involved in the reengineering process.

18.8 References and/or Recommended Readings

[Pfleeger, 2006] Pfleeger, Shari Lawrence. Software Engineering Theory and Practice 3rd ed. Upper Saddle River, NJ: Prentice Hall, 2006. See chapter 11.

[Pressman, 2005] Pressman, Roger. Software Engineering: A Practitioner’s Approach 6th ed. Crawfordsville, IN: McGraw-Hill, 2005. See chapter 27.

[Schach, 2005] Schach, Stephen R. Object-Oriented and Classical Software Engineering 6th ed. Boston, MA: McGraw-Hill, 2005. See chapter 15.

[Sommerville, 2006] Sommerville, Ian. Software Engineering 8th ed. Reading, MA: Addison-Wesley, 2006. See chapters 27 and 28.