Other Tutorials by

Visual Basic - Visual Basic tutorials

VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

You are here: > Systems Analysis and Design

Software Maintenance

It is impossible to produce systems of any size, which do not need to be changed. Over the lifetime of a system, its original requirements will be modified to reflect changing user and customer needs. The system's environment will change as new hardware is introduced. Error, undiscovered during system validaton, may merge and require repair.

The process of changing of a system after it has been delivered and is in use is called Software maintenance. The changes may involve simple changes to correct coding errors, more extensive changes to correct design errors or significant enhancement to correct specification errors or accomodate new requirements. Maintenance therefore, in this context, really means evolution. It is the process of changing a system to maintain its ability to survive.

There are three types of software maintenance with very blurred distinction between them.

  1. Corrective maintenance
  2. Adaptive maintenance
  3. Perfective maintenance

Follwing figure illustrates the maintenance effort distributionin software maintenance.

Maintenance Effort Distribution
Maintenance Effort Distribution

Corrective Maintenance

Corrective Maintenance is concerned with fixing reported errors in the software. Coding errors are usually relatively cheap to correct; design errors are more expensive as they may involves the rewriting of several programs components. Requirements errors are the most expensive to repair because of the extensive system redesign with may be necessary.

Adaptive maintenance

Adaptive maintenance means changing the software to new environment such as different hardware platform or for use with a different operating systems. The software functionality does not radically change.

Perfective maintenance

Perfective maintenance involves implementing ne wfunctional or non-functional system requirements. These are generated by software customers as their organization are business changes.

It is difficult to find up-to-date figures for their relative effort devoted to these different types of maintenance. A survey by Lientz and Swanson (1980) discovered that about 65% of maintenance was perfective, 18% adaptive and 17% corrective shown in figure. And also Lientz and Swanson found that large organizations devoted at least 50% of their total programming effort for maintaining existing systems. The costs of adding functionality to a system after it has been put into operation are usually much greater than providing similar functionality when software is originally developed. There are a number of reasons for this:

  1. Maintenance staffs are often relatively inexperienced and unfamiliar with the applications domain. Maintenance has a poor image among software engineers. It is seen as a less skilled process than system development and is often allocated to the most junior staff.

  2. The program being maintained may have been developed many years ago without modern software engineering techniques. Thay may be unstructured and optimized for efficiency rather than understandability.

  3. Changes made to a program may introduce new faults, which trigger further change requests. New faults may be introduced because the complexity of the system may make it difficult to access the effects of a change.

  4. As a system is changed, its structure tends to degrade. This makes the system harder to understand and makes further changes difficult as the program becomes less cohesive.

  5. The links between a program and its associated documentation are sometimes lost during the maintenance process. The documentation may therefore be an unreliable aid to program understanding.

The first of these problems can only be tackled by organization adapting enlightened maintenance management policies. management must demonstrate to engineer that maintenance is of equal value and is as challenging as original software development. The best designers and programmers should be challenged and motivated by system maintenance. Boehm (1983) suggested several steps that can improve maintenance staff motivation.

  1. Couple software objectives to organizational goals.

  2. Couple software maintenance rewards to organizational performance

  3. Integrate software maintenance personnel into operational teams.

  4. Create a discretionary, preventive maintenance budget, which allows the maintenance team to decide when to re-engineer parts of the software. Preventive maintenance means making changes to the software, which improve its structure so that future maintenance is simplified.

  5. Involve maintenance staff early in the software process during standard preparation, reviews and test preparation.

The second of the above problems, namely unstructured code, can be tackled using re-engineering and design recovery tecniques.

The other maintenance problems are process problems. Structure naturally degrades with changes. Organizations must plan to invest extra effort and resources in preventive maintenance with the aim of maintaining the structure. Good software engineerign practice such as the use of information hiding or object-oriented development helps minimize the structure degradation but effort for structure maintenance is still required.


<< Previous Page | Contents | Back to System Analysis Main Page>>


Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved