Software Maintenance

1. What is Software Maintenance

1.1 Introduction

Software maintenance is often considered to be (if it is considered at all) an unpleasant, time consuming,
expensive and unrewarding occupation - something that is carried out at the end of development only
when absolutely necessary (and hopefully not very often). As such it is often considered to be the poor
relation of software development budgets often do not allow for it (or allow too little), and few
programmers given a choice would choose to carry out maintenance over developmental work. This view,
that software maintenance is the last resort is largely born out of ignorance. Misconceptions,
misunderstandings and myths concerning this crucial area of software engineering abound.

Software Maintenance suffers from an image problem due to the fact that although software has been
maintained for years, relatively little is written about the topic. Little funding for research about software
maintenance exists, thus, the academic community publishes relatively few papers on the subject.
Maintenance organisations within business publish even less because of the corporate fear of giving away
the "competitive edge". Although there are some textbooks on software maintenance, they are relatively
few and far between (examples are included in the bibliography). Periodicals address the topic
infrequently and few universities include software maintenance explicitly in their degree programmes .
This lack of published information contributes to the misunderstandings and misconceptions that people
have about software maintenance.
Part of the confusion about software maintenance relates to its definition; when it begins, when it ends
and how it relates to development. Therefore it is necessary to first consider what is meant by the term
software maintenance.

What is Software Maintenance?

In order to define software maintenance we need to define exactly what is meant by software. It is a
common misconception to believe that software is programs and that maintenance activities are carried
out exclusively on programs. This is because many software maintainers are more familiar with, or rather
are more exposed to programs than other components of a software system usually it is the program code
that attracts most attention.

1.2 A Definition of Software

A more comprehensive view of software is given by McDermid (1991) who states that it consists of the
programs, documentation and operating procedures by which computers can be made useful to man.
Table 1.1 below depicts the components of a software system according to this view and includes some
examples of each.

McDermid's definition suggests that software is not only concerned with programs - source and object
code - but also relates to documentation of any facet of the program, such as requirements analysis,
specification, design, system and user manuals, and the procedures used to set up and operate the
software system. McDermid's is not the only definition of a software system but it is comprehensive and
widely accepted.
 Software Components Examples
Program Source code

Object code

Documentation Analysis/specification: (a) Formal specification

(b) Context diagram
(c) Data flow diagrams
Design: (a) Flowcharts
(b) Entity-relationship charts
Implementation: (a) Source code listings
(b) Cross-reference listing
Testing: (a) Test data
(b) Test results
Operating Procedures 1. Instructions to set up and use the software system
2. Instructions on how to react to system failures

1.3 A Definition of Maintenance

The use of the word maintenance to describe activities undertaken on software systems after delivery has
been considered a misnomer due to its failure to capture the evolutionary tendency of software products.
Maintenance has traditionally meant the upkeep of an artifact in response to the gradual deterioration of
parts due to extended use, which is simply corrective maintenance. So for example, one carries out
maintenance on a car or a house usually to correct problems e.g. replacing the brakes or fixing the leaking
roof. If however we were to build an extension to the house or fit a sun roof to a car then those would
usually be thought of as improvements (rather than a maintenance activities). Therefore to apply the
traditional definition of maintenance in the context of software means that software maintenance is only
concerned with correcting errors. However, correcting errors accounts for only part of the maintenance
effort.

Consequently, a number of authors have advanced alternative terms that are considered to be more
inclusive and encompass most, if not all, of the activities undertaken on existing software to keep it
operational and acceptable to the users. These include software evolution, post-delivery evolution and
support. However it can be argued that there is nothing wrong with using the word maintenance provided
software engineers are educated to accept its meaning within the software engineering context regardless
of what it means in non-software engineering disciplines. After all, any work that needs to be done to keep
a software system at a level considered useful to its users will still have to be carried out regardless of the
name it is given.

1.4 Definitions of Software Maintenance

As a result of the above, attempts have been made to develop a more comprehensive definition of
maintenance which would be appropriate for use within the context of software systems. Some definitions
focus on the particular activities carried out during maintenance, for example, According to Martin and
McClure (1983), software maintenance must be performed in order to

• Correct errors
 • Correct design flaws
• Interface with other systems
• Make enhancements
• Make necessary changes to the system
• Make changes in files or databases
• Improve the design
• Convert programs so that different hardware, software, system features, and telecommunications
facilities can be used

Others insist on a general view which considers software maintenance as any work that is undertaken
after delivery of a software system, for example:

• ". . . changes that have to be made to computer programs after they have been delivered to the
customer or user." (Martin and McClure 1983).
• "Maintenance covers the life of a software system from the time it is installed until it is phased
out."(von Mayrhauser 1990).

The problem with these definitions is that they fail to indicate what is actually done during maintenance.
Also the common theme of the above definitions is that maintenance is an "after-the-fact" activity. Based
on these definitions, no maintenance activities occur during the software development effort (the pre-
delivery stage of the life cycle of a software system). Maintenance occurs after the product is in operation
(during the post-delivery stage). Schneiderwind (1987) believes that maintenance is difficult because of
this short-sighted view that maintenance is a postdelivery activity. During development little consideration
is made to the maintenance phase which is to follow, the developers considering their work done once the
system is handed over to users.

Other perspectives include:

• the 'bug-fixing' view which considers software maintenance as an activity involving the detection
and correction of errors found in programs,
• the 'need-to-adapt' view which sees maintenance as a activity which entails changing the software
when its operational environment or original requirement changes.
• the 'support' to users view where maintenance of software is seen as providing a service to users
of the system.

The IEEE software maintenance standard, IEEE STD 1219-1993, which draws on these different views,
defines software maintenance as:

Modification of a software product after delivery, to correct faults, to improve performance or

other attributes, or to adapt the product to a modified environment (Van Edelstein 1993).

Can also be defined as,

Maintenance is the activity associated with keeping operational computer systems continuously in tune
with requirements of users & data processing operation.

Software Maintenance is any work done to a computer program after its first installation and
implementation in an operational environment

The maintenance of software systems is motivated by a number of factors:

• To provide continuity of service: This entails fixing bugs, recovering from failures, and
accommodating changes in the operating system and hardware,
• To support mandatory upgrades: These are usually caused by changes in government regulations,
and also by attempts to maintain a competitive edge over rival products.
• To support user requests for improvements: Examples include enhancement of functionality, better
performance and customisation to local working patterns.
 • To facilitate future maintenance work: This usually involves code and database restructuring, and
updating documentation.

1.5 Maintenance image problems

The inclusion of the word maintenance in the term software maintenance has been linked to the negative
image associated with the area. Higgins (1988) describes the problem:

...programmers, ..tend to think of program development as a form of puzzle solving, and it is reassuring
to their ego when they manage to successfully complete a difficult section of code. Software maintenance,
on the other hand, entails very little new creation and is therefore categorised as dull, unexciting detective
work.

Similarly, Schneidewind (1987) contends that to work in maintenance has been akin to having bad breath.
Further, some authors argue that the general lack of consensus on software maintenance terminology has
also contributed to the negative image associated with it.

2. Why is Software Maintenance necessary

2.1 Overview

In order to answer this question we need to consider what happens when the system is delivered to the
users. The users operate the system and may find things wrong with it, or identify things they would like
to see added to it. Via management feedback the maintainer makes the approved corrections or
improvements and the improved system is delivered to the users. The cycle then repeats itself, thus
perpetuating the loop of maintenance and extending the life of the product. In most cases the
maintenance phase ends up being the longest process of the entire life cycle, and so far outweighs the
development phase in terms of time and cost. Error! Reference source not found. shows the lifecycle
of maintenance on a software product and why (theoretically) it may be never ending.

Figure 1.1 The Maintenance Lifecycle

Lehman's (1980) first two laws of software evolution help explain why the Operations and Maintenance
phase can be the longest of the life-cycle processes. His first law is the Law of Continuing Change, which
states that a system needs to change in order to be useful. The second law is the Law of Increasing
Complexity, which states that the structure of a program deteriorates as it evolves. Over time, the
structure of the code degrades until it becomes more cost-effective to rewrite the program.
3. Types of Software Maintenance

In order for a software system to remain useful in its environment it may be necessary to carry out a wide
range of maintenance activities upon it. Swanson (1976) was one of the first to examine what really
happens during maintenance and was able to identify three different categories of maintenance activity.

3.1 Corrective

Changes necessitated by actual errors (defects or residual "bugs") in a system are termed corrective
maintenance. These defects manifest themselves when the system does not operate as it was designed or
advertised to do.

A defect or bug can result from design errors, logic errors and coding errors. Design errors occur when for
example changes made to the software are incorrect, incomplete, wrongly communicated or the change
request misunderstood. Logic errors result from invalid tests and conclusions, incorrect implementation of
design specification, faulty logic flow or incomplete test data. Coding errors are caused by incorrect
implementation of detailed logic design and incorrect use of the source code logic. Defects are also caused
by data processing errors and system performance errors. All these errors, sometimes called residual
errors or bugs prevent the software from conforming to its agreed specification.

In the event of a system failure due to an error, actions are taken to restore operation of the software
system. The approach here is to locate the original specifications in order to determine what the system
was originally designed to do. However, due to pressure from management, maintenance personnel
sometimes resort to emergency fixes known as patching. The ad hoc nature of this approach often gives
rise to a range of problems that include increased program complexity and unforeseen ripple effects.

Increased program complexity usually arises from degeneration of program structure which makes the
program increasingly difficult, if not impossible, to comprehend. This state of affairs can be referred to as
the spaghetti syndrome or software fatigue. Unforeseen ripple effects imply a change to one part of a
program may affect other sections in an unpredictable fashion. This is often due to lack of time to carry
out a thorough impact analysis before effecting the change.

Corrective maintenance has been estimated to account for 20% of all maintenance activities.

3.2 Adaptive

Any effort that is initiated as a result of changes in the environment in which a software system must
operate is termed adaptive change. Adaptive change is a change driven by the need to accommodate
modifications in the environment of the software system, without which the system would become
increasingly less useful until it became obsolete.

The term environment in this context refers to all the conditions and influences which act from outside
upon the system, for example business rules, government policies, work patterns, software and hardware
operating platforms. A change to the whole or part of this environment will warrant a corresponding
modification of the software.

Unfortunately, with this type of maintenance the user does not see a direct change in the operation of the
system, but the software maintainer must expend resources to effect the change. This task is estimated to
consume about 25% of the total maintenance activity.

3.3 Perfective

The third widely accepted task is that of perfective maintenance. This is actually the most common type of
maintenance encompassing enhancements both to the function and the efficiency of the code and includes
all changes, insertions, deletions, modifications, extensions, and enhancements made to a system to meet
the evolving and/or expanding needs of the user. A successful piece of software tends to be subjected to a
succession of changes resulting in an increase in its requirements. This is based on the premise that as
the software becomes useful, the users tend to experiment with new cases beyond the scope for which it
was initially developed. Expansion in requirements can take the form of enhancement of existing system
functionality or improvement in computational efficiency.

As the program continues to grow with each enhancement the system evolves from an average-sized
program of average maintainability to a very large program that offers great resistance to modification.
Perfective maintenance is by far the largest consumer of maintenance resources, estimates of around
50% are not uncommon.

The categories of maintenance above were further defined in the 1993 IEEE Standard on Software
Maintenance (IEEE 1219 1993) which goes on to define a fourth category.

3.4 Preventive

The long-term effect of corrective, adaptive and perfective change is expressed in Lehman's law of
increasing entropy:

As a large program is continuously changed, its complexity, which reflects deteriorating structure,
increases unless work is done to maintain or reduce it. (Lehman 1985).

The IEEE defined preventative maintenance as "maintenance performed for the purpose of preventing
problems before they occur" (IEEE 1219 1993). This is the process of changing software to improve its
future maintainability or to provide a better basis for future enhancements.

The preventative change is usually initiated from within the maintenance organisation with the intention of
making programs easier to understand and hence facilitate future maintenance work. Preventive change
does not usually give rise to a substantial increase in the baseline functionality.

Preventive maintenance is rare (only about 5%) the reason being that other pressures tend to push it to
the end of the queue. For instance, a demand may come to develop a new system that will improve the
organisation competitiveness in the market. This will likely be seen as more desirable than spending time
and money on a project that delivers no new function. Still, it is easy to see that if one considers the
probability of a software unit needing change and the time pressures that are often present when the
change is requested, it makes a lot of sense to anticipate change and to prepare accordingly.

The most comprehensive and authoritative study of software maintenance was conducted by B. P. Lientz
and E. B. Swanson (1980). Figure 1.2 depicts the distribution of maintenance activities by category by
percentage of time from the Lientz and Swanson study of some 487 software organisations. Clearly,
corrective maintenance (that is, fixing problems and routine debugging) is a small percentage of overall
maintenance costs, Martin and McClure (1983) provide similar data.

Figure 1.2 Distribution of maintenance by categories

3.5 Maintenance as Ongoing Support

This category of maintenance work refers to the service provided to satisfy non-programming related work
requests. Ongoing support, although not a change in itself, is essential for successful communication of
desired changes. The objectives of ongoing support include effective communication between maintenance
and end user personnel, training of end-users and providing business information to users and their
organisations to aid decision making.

• Effective communication is essential as maintenance is probably the most customer-intensive part

of the software life cycle, since a greater proportion of maintenance effort is spent providing
enhancements requested by customers than is spent on other types of system change. Good
customer relations are important for several reasons and can lead to a reduction in the
misinterpretation of users change requests, a better understanding of users' business needs and
increased user involvement in the maintenance process. Failure to achieve the required level of
communication between the maintenance organisation and those affected by the software changes
may eventually lead to software failure.
• Training of end users - typical services provided by the maintenance organisation include manuals,
telephone support , help desk, on-site visits, informal short courses, and user groups.

Business information - users need various types of timely and accurate business information (for example,
time, cost, resource estimates) to enable them take strategic business decisions. Questions such as should
we enhance the existing system or replace it completely may need to be considered.

4. The Importance of Categorising Software Changes

4.1 Overview

In principle, software maintenance activities can be classified individually. In practice, however, they are
often intertwined. For example, in the course of modifying a program due to the introduction of a new
operating system (adaptive change), obscure 'bugs' may be introduced. The bugs have to be traced and
dealt with (corrective maintenance). Similarly, the introduction of a more efficient sorting algorithm into a
data processing package (perfective maintenance) may require that the existing program code be
restructured (preventive maintenance). Figure 1.3 depicts the potential relations between the different
types of software change. Despite the overlapping nature of these changes, there are several reasons why
a good understanding of the distinction between them is important.

Firstly, it allows management to set priorities for change requests. Some changes require a faster
response than others. Secondly, there are limitations to software change. Ideally changes are
implemented as the need for them arises. In practice, however this is not always possible for several
reasons:

• Resource Limitations: Some of the major hindrances to the quality and productivity of maintenance
activities are the lack of skilled and trained maintenance programmers and the suitable tools and
environment to support their work. Cost may also be an issue.
• Quality of the existing system: In some 'old' systems, this can be so poor that any change can lead
to unpredictable ripple effects and a potential collapse of the system.
• Organisational strategy: The desire to be on a par with other organisations, especially rivals, can
be a great determinant of the size of a maintenance budget.
• Inertia: The resistance to change by users may prevent modification to a software product,
however important or potentially profitable such change may be.

Thirdly software is often subject to incremental release where changes made to a software product are not
always done all together. The changes take place incrementally, with minor changes usually implemented
while a system is in operation. Major enhancements are usually planned and incorporated, together with
other minor changes, in a new release or upgrade. The change introduction mechanism also depends on
whether the software package is bespoke or off-the-shelf. With bespoke software, change can often be
effected as the need for it arises. For off-the-shelf packages, users normally have to wait for the next
upgrade.

Swanson's definitions allow the software maintenance practitioner to be able to tell the user that a certain
portion of a maintenance organisations efforts is devoted to user-driven or environment-driven
requirements. The user requirements should not be buried with other types

Fig 1.3. The Relationship between the different types of software change

of maintenance. The point here is that these types of updates are not corrective in nature they are
improvements and no matter which definitions are used, it is imperative to discriminate between
corrections and enhancements.

By studying the types of maintenance activities above it is clear that regardless of which tools and
development model is used, maintenance is needed. The categories clearly indicate that maintenance is
more than fixing bugs. This view is supported by Jones (1991), who comments that organisations lump
enhancements and the fixing of bugs together. He goes on to say that this distorts both activities and
leads to confusion and mistakes in estimating the time it takes to implement changes and budgets. Even
worse, this "lumping" perpetuates the notion that maintenance is fixing bugs and mistakes. Because many
maintainers do not use maintenance categories, there is confusion and misinformation about
maintenance.

5. A Comparison between Development and Maintenance

5.1 Overview

Although maintenance could be regarded as a continuation of development, there is a fundamental

difference between the two activities. The constraints that the existing system imposes on maintenance
gives rise to this difference. For example, in the course of designing an enhancement, the designer needs
to investigate the current system to abstract the architectural and the low-level designs. This information
is then used to

• ascertain how the change can be accommodated

• predict the potential ripple effect of the change
• determine the skills and knowledge required to do the job

To explain the difference between new development and software maintenance further, Jones (1986)
provides an interesting analogy:

The task of adding functional requirements to existing systems can be likened to the architectural work of
adding a new room to an existing building. The design will be severely constrained by the existing
structure, and both the architect and the builders must take care not to weaken the existing structure
when additions are made. Although the costs of the new room usually will he lower than the costs of
constructing an entirely new building, the costs per square foot may be much higher because of the need
to remove existing walls, reroute plumbing and electrical circuits and take special care to avoid disrupting
the current site, (quoted in Corbi 1989).

6. The Cost of Maintenance

6.1 Overview

Although there is no real agreement on the actual costs, sufficient data exist to indicate that maintenance
does consume a large portion of overall software lifecycle costs. Arthur (1988) states that only a quarter
to a third of all lifecycle costs are attributed to software development, and that some 67% of lifecycle
costs are expended in the operations and maintenance phase of the life cycle. Jones (1994) states that
maintenance will continue to grow and become the primary work of the software industry. Table 1.2
(Arthur 1988) provides a sample of data complied by various people and organisations regarding the
percentage of lifecycle costs devoted to maintenance. These data were collected in the late 1970s, prior to
all the software engineering innovations, methods, and techniques that purport to decrease overall costs.

However, despite software engineering innovations, recent literature suggests that maintenance is gaining
more notoriety because of its increasing costs. A research marketing firm, the Gartner Group, estimated
that U.S. corporations alone spend over $30 billion annually on software maintenance, and that in the
1990s, 95% of lifecycle costs would go to maintenance (Moad 1990 Figure 1.4). Clearly, maintenance is
costly, and the costs are increasing. All the innovative software engineering efforts from the 1970s and
1980s have not reduced lifecycle costs.

Maintenance
Survey Year
(%)

Canning 1972 60

Boehm 1973 40-80

deRose/Nyman 1976 60-70

Mills 1976 75

Zeikowitz 1979 67

Cashman and
1979 60-80
Holt

Table 1.2 Maintenance Costs as a Percentage of Total Software Life-cycle Costs

Today programmers' salaries consume the majority of the software budget, and most of their time is
spent on maintenance as it is a labour intensive activity. As a result, organisations have seen the
operations and maintenance phase of the software life cycle consume more and more resources over time.

Others attribute rising maintenance costs to the age and lack of structure of the software. Osborne and
Chikofsky (1990) state that much of today's software is ten to fifteen years old, and were created without
benefit of the best design and coding techniques. The result is poorly designed structures, poor coding,
poor logic, and poor documentation for the systems that must be maintained.
 Figure 1.4 The Percentage of Software life-cycle costs devoted to maintenance.

Over 75% of maintenance costs are for providing enhancements in the form of adaptive and perfective
maintenance. These enhancements are significantly more expensive to complete than corrections as they
require major redesign work and considerably more coding than a corrective action. The result is that the
user driven enhancements (improvements) dominate the costs over the life cycle.

Several later studies confirm that Lientz and Swanson's data from 1980 was still accurate in 1990. Table
1.3 summarises data from several researchers and shows that noncorrective work ranges from 78% to
84% of the overall effort, therefore that the majority of maintenance costs are being spent on
enhancements. Maintenance is expensive therefore because requirements and environments change and
the majority of maintenance costs are driven by users.

Lientz & Swanson Ball Deklava Abran

Maintenance Category
1980 1987 1990 1990
Corrective 22% 17% 16% 21%
Non-corrective 78% 83% 84% 79%

Table 1.3 Percentage effort spent on Corrective and Non-Corrective maintenance

The situation at the turn of the millennium shows little sign of improvement.

The Maintenance Budget

Normally, after completing a lengthy and costly software development effort, organisations do not want to
devote significant resources to postdelivery activities. Defining what is meant by a significant resource is
in itself problematic how much should maintenance cost?

Underestimation of maintenance costs is partly human nature as developers do not want to believe that
maintenance for the new system will consume a significant portion of lifecycle costs. They hope that the
new system will be the exception to the norm as modern software engineering techniques and methods
were used. Therefore the software maintenance phase of the life cycle will not, by definition, consume
large amounts of money. Accordingly, sufficient amounts of money are often not allocated for
maintenance. With limited resources, maintainers can only provide limited maintenance. The lack of
financial resources for maintenance is due in large part to the lack of recognition that "maintenance" is
primarily enhancing delivered systems rather than correcting bugs.

Another factor influencing high maintenance costs is that needed items are often not included initially in
the development phase, usually due to schedules or monetary constraints, but are deferred until the
operations and maintenance phase. Therefore maintainers end up spending a large amount of their time
coding the functions that were delayed until maintenance. As a result development costs remain within
budget but maintenance costs increase.
As can be seen from Table 1.3, the maintenance categories are particularly useful when trying to explain
the real costs of maintenance. If organisations have this data, they will understand why maintenance is
expensive and will be able to defend their estimates of time to complete tasks and resources required.

7. A Software Maintenance Framework

7.1 Overview

To a large extent the requirement for software systems to evolve in order to accommodate changing user
needs contributes to the high maintenance cost. However, there are other factors which contribute
indirectly to this by hindering maintenance activities. A Software Maintenance Framework (which is a
derivative of the Software Maintenance Framework proposed by Haworth et al. 1992) will be used to
discuss some of the factors that contribute to the maintenance challenge. The elements of this framework
are the user requirements, organisational and operational environments, maintenance process,
maintenance personnel, and the software product (Table 1.4).

Component Feature
Requests for additional functionality, error correction and
1. Users & requirements improve maintainability
Request for non-programming related support
Change in policies
2. Organisational environment
Competition in the market place
Hardware innovations
3. Operational environment
Software innovations
Capturing requirements
Variation in programming and working practices
4. Maintenance process
Paradigm shift
Error detection and correction
Maturity and difficulty of application domain
Quality of documentation
Malleability of programs
5. Software product
Complexity of programs
Program structure
Inherent quality

Staff turnover
6. Maintenance personnel
Domain expertise

Table: Components of the Software Maintenance Framework

7.2 Users and their Requirements

Users often have little understanding of software maintenance and so can be unsupportive of the
maintenance process. They may take the view that

• Software maintenance is like hardware maintenance

• Changing software is easy
• Changes cost too much and take too long

Users may be unaware that their request

• may involve major structural changes to the software which may take time to implement
 • must be feasible, desirable, prioritised, scheduled and resourced
• may conflict against one another or against company policy such that it is never implemented

7.3 Organisational and Operational Environment

An environmental factor is a factor which acts upon the product from outside and influences its form or
operation. The two categories of environment are

• The organisational environment - e.g. business rules, government regulations, taxation policies,
work patterns, competition in the market place
• The operational environment - software systems e.g. operating systems, database systems,
compilers and hardware systems e.g. processor, memory, peripherals

In this environment the scheduling of maintenance work can be problematic as urgent fixes always go to
the head of the queue thus upsetting schedules and unexpected, mandatory large scale changes will also
need urgent attention. Further problems can stem from the organisational environment in that the
maintenance budget is often underfunded.

7.4 Maintenance Process

The term process here refers to any activity carried out or action taken either by a machine or
maintenance personnel during software maintenance. The facets of a maintenance process which affect
the evolution of the software or contribute to maintenance costs include

• The difficulty of capturing change (and changing) requirements - requirements and user problems
only become clearer when a system is in use. Also users may not be able to express their
requirements in a form understandable to the analyst or programmer - the 'information gap'. The
requirements and changes evolve, therefore the maintenance team is always playing catch-up
• Variation in programming practice this may present difficulties if there is no consistency, therefore
standards or stylistic guidelines are often provided. Working practices impact on the way a change
is effected. Time to change can be adversely affected by clever code; undocumented assumptions;
and undocumented design and implementation decisions. After some time, programmers find it
difficult to understand their own code.
• Paradigm shift - older systems developed prior to the advent of structured programming
techniques may be difficult to maintain. However, existing programs may be restructured or
revamped using techniques and tools e.g. structured programming, object orientation, hierarchical
program decomposition, reformatters and pretty-printers.
• Error detection and correction - error-free software is virtually non-existent. Software products
tend to have 'residual' errors. The later these errors are discovered the more expensive they are to
correct. The cost gets even higher if the errors are detected during the maintenance phase
7.5 Software Product

Aspects of a software product that contribute to the maintenance challenge include

• Maturity and difficulty of the application domain: The requirements of applications that have been
widely used and well understood are less likely to undergo substantial modifications than those that
are still in their infancy.
• Inherent difficulty of the original problem: For example, programs dealing with simple problems
such as sorting are obviously easier to handle than those used for more complex computations
such as weather forecasting.
• Quality of the documentation: The lack of up-to-date systems documentation effects maintenance
productivity. Maintenance is difficult to perform because of the need to understand (or
comprehend) program code. Program understanding is a labour-intensive activity that increases
costs. IBM estimated that a programmer spends around 50% of his time in the area of program
analysis.
• Malleability of the programs: The malleable or 'soft' nature of software products makes them more
vulnerable to undesirable modifications than hardware items. Inadvertent software changes may
have unknown and even fatal repercussions. This is particularly true of 'safety-related' or 'safety-
critical' systems.
• Inherent quality: The tendency for a system to decay as more changes are undertaken implies that
preventive maintenance needs to be undertaken to restore order in the programs.

7.6 Maintenance Personnel

This refers to individuals involved in the maintenance of a software product. They include maintenance
managers, analysts, designers, programmers and testers. The aspects of personnel that affect
maintenance activities include the following:

• Staff turnover: Due to high staff turnover many systems end up being maintained by individuals
who are not the original authors therefore a substantial proportion of the maintenance effort is
spent on just understanding the code. Staff who leave take irreplaceable knowledge with them.
• Domain expertise: Staff may end up working on a system for which they have neither the system
domain knowledge nor the application domain knowledge. Maintainers may therefore inadvertently
cause the â œripple effectâ . This problem may be worsened by the absence of documentation
or out of date or inadequate documentation. A contrary situation is where a programmer becomes
â ˜enslavedâ ™ to a certain application because she/he is the only person who understands it.

Obviously the factors of product, environment, user and maintenance personnel do not exist in isolation
but interact with one another. Three major types of relation and interaction that can be identified are
product/environment, product/user and product/maintenance personnel (Figure 1.6).

• Relationship between product and environment - as the environment changes so must the product
in order to be useful.
• Relationship between product and user - in order for the system to stay useful and acceptable to its
users it also has to change to accommodate their changing requirements.
• Interaction between personnel and product - the maintenance personnel who implement changes
also act as receptors of the changes. That is, they serve as the main avenue by which changes in
the other factors - user requirements, maintenance process, organisational and operational
environments - act upon the software product. The nature of the maintenance process used and
the attributes of the maintenance personnel will impact upon the quality of the change.
 Figure 1.6 Inter-relationship between maintenance factors

8. Potential Solutions to the Maintenance Problem

A number of possible solutions to maintenance problems have been suggested, they include

• Budget and Effort Reallocation

• Complete Replacement of the System
• Maintenance of the Existing System

8.1 Budget and Effort Reallocation

Based on the observation that software maintenance costs at least as much as new development, some
authors have proposed that rather than allocating less resource to develop unmaintainable or difficult to
maintain systems, more time and resource should be invested in the development specification and
design of more maintainable systems. However, this is difficult to pursue, and even if it was possible,
would not address the problem of legacy systems that are already in a maintenance crisis situation.

8.2 Complete Replacement of the System

One might be tempted to suggest that if maintaining an existing system costs as much as developing a
new one, then why not develop a new system from scratch. In practice of course it is not that simple as
there are costs and risks involved. The organisation may not be able to afford the capital outlay and there
is no guarantee that the new system will function any better than the old one. Additionally the existing
system represents a valuable knowledge base that could prove useful for the development of future
systems thereby reducing the chance of re-inventing the wheel. It would be unrealistic for an organisation
to part with such as asset.

8.3 Maintenance of the existing system

In most maintenance situations budget and effort reallocation is not possible and completely redesigning
the whole software system is usually undesirable (but nevertheless forced in some situations). Given that
these approaches are beset with problems, maintaining the existing system is often the only alternative.

Maintenance could be achieved, albeit it in an ad hoc fashion by making necessary modifications as

patches to the source code, often by hitting alien code head-on. However this approach is fraught with
difficulty and is often adopted because of time pressures. Corrective maintenance is almost always done in
this way for the same reason.

An alternative and cost-effective solution is to apply preventative maintenance. Preventative maintenance

may take several forms, it may:

• be applied to those sections of the software that are most often the target for change (this
approach may be very cost effective as it has been estimated that 80% of changes affect only 30%
of the code).
• involve updating inaccurate documentation
• involve restructuring, reverse engineering or the re-use of existing software components

Unfortunately preventive maintenance is rare; the reason being that other pressures tend to push it to the
end of the queue.