systems
Problemsand solutionsin
sof~are maintenance
by A4 C ER
T
he information revolution has
brought important changes to
m~agement isolation sys-
tems; its impact on business systems
is apparent. With more and more
aspects of the management informa-
tion systems being computerized, the
data processing department is gradu-
ally becoming one of the important
departments in most corporations.
Until now a great deal of attention
has focused on software development,
namely, how to specify software sys-
tems using formal techniques and
how to implement software systems
within budgets and time constraints.
Attention has gradually shifted to
software rn~ten~~e where more
and more software systems are put
into operation and more and more
resources are being poured into soft-
ware maintenance activities. Some
corporations have already experienced
spending more than 70% of the DP
personnel salaries on software main-
tenance-3, and the cost of software
maintenance is increasing every year.
Thus, there is an urgent need to study
software maintenance problems and
to seek possible solutions to the crisis.
Abstract: The software ~~nt~~e cost has
risen to 7#% of the data procekrrg budget in
some corpor&ons. Some of the crucial factors
contributing to the sofnuare maintenance
problems are identiw and discussedand
mu-88~~ aud technical sozutionsto
the ~~~~ob~~ are proposed.
Keywords: sofmare maittteuance, sofmare
quality control, maintenance problems,
maintenance solutions.
M C Er is at the University of ~ollongong,
Australia.
~0126 no 6 july/august 1984 ~11~~4~84~~2~3$03.~
Definition of software
maintenance
In a very loose sense, software main-
tenance is an activity which makes
existing software operationable.
this respect, it includes corrections,
improvements, modifications and en-
hancements. The correction activity is
to fix up errors in computer pro-
grams, which may be due to specifka-
tion errors of coding errors. The
improvement activity is to increase
the execution efficiency of computer
programs, for instance. The modifica-
tion activity is to alter the code in
order to reflect the changes of legisla-
tion or of business environment. The
enhancement activity is to add more
facilities to existing software systems,
which are normally initiated by users.
The cost of each software main-
tenance activity depends to a large
extent on how substantial the changes
are made to the code. In general, the
m~~cation and enh~cement activi-
ties account for more than 70% of the
software maintenance cost.
Software maintenance problems
Why is software maintenance a pro-
blem at all? First of all, we need to
understand the intrinsic nature of
software in order to fully appreciate
the software maintenance problems
and the feasible solutions. Software is
totally different from hardware -
software never deteriorates due to
wear and tear but the hardware does.
Hence the techniques of hardware
maintenance cannot be applied to the
software maintenance directly. Gen-
eral-purpose computers have pushed
the complexity of computation one
Q 1984 Butte~o~b
level up to the software, making the
software the most crucial component
in any ~formation system. What is
built into the software is the computa-
tion logic which models the activities
In
of the outside world. In consequence,
when the outside world is changed,
the affected software shotid be
changed if it is to continue EOmake
sense at all. In this respect, if the
outside world is complex, so is the
internal structure of the software.
Obviously, the more frequently the
outside world is changed, the more
frequently the software needs to be
updated. Thus the software main-
tenance activity seems to be endless.
Coupled with the endless software
maintenance activity are the software
maintenance problems which are uni-
que in themselves.
Sofnoare maintenance is an
intellectual activity
Software maintenance is not as simpie
as changing a bulb or fixing a screw.
One needs the creativity to identify
the code to be changed and to make
an appropriate change without de-
stroying the integrity of the software
system as a whole.
The complexity of understanding
computer programs
The complexity of a computer pro-
gram depends to a large extend on its
size and the interaction of compo-
nents. In reading computer programs,
not only has one to understand the
code but one has also to relate it to the
operating environment and to make
sense out of it. Thus, in rn~ta~g
software, one has to suffer from the
& Co ~~ub~~h~s~ Ltd. 25
usual learning curve effect, and on top
of it one has to reconstruct the inter-
nal model manipulated by the com-
puter program. The larger the com-
puter program, the more complex is
this exercise. Unfortunately, this
aspect is often underestimated.
Maintainability of sofnoare
Many computer programs were writ-
ten without having maintainability in
mind. This is not due to the incompe-
tence of programmers; rather it is due
to the following two contributing
factors. First, most of the software is
developed under very tight budget
and time constraints and there is
virtually no time to ponder upon the
maintainability issue. Second, pro-
grammers are quite often not the
users of software products and it is
difficult to anticipate what course the
future will take.
Integrated software system is specific
to a corporation
A piece of software, say the payroll
system, could be contracted to a
software house. However, the integra-
ted software system is specific to each
corporation and cannot be contracted
to outside software houses.
Mobility of software personnel
The computer industry is a fast grow-
ing industry; the demand for software
specialists far exceeds the supply. To
gain quick promotion or better finan-
cial reward, software specialists fre-
quently change jobs. Yet, when a
software specialist quits, the corpora-
tion loses the expertise gained over a
long period of time. The long-term
effect of high turnover is that the
software will gradually degrade to a
state whereby its maintenance is too
costly or impossible.
Lack of documentation
The fact that most programmers write
poorly is of great concern. It is related
to the difficulty of expressing dynamic
26
computation in written language, the
lack of time during software deveiop-
ment to produce decent documents,
especially when the software is behind
schedule, the lack of an incentive to
produce high quality documents, and
the fact that poor documentation
means that others have to rely on the
programmers.
Management attitude
Management often regards software
maintenance as a second-rate job.
Consequently, not only is the financial
reward paid to the software main-
tenance personnel lower than that
paid to the software development
personnel, but also ill-qualified people
are assigned to maintain the software.
It is, therefore, not surprising that
competent programmers have chosen
to avoid software-maintenance jobs.
Management solutions
One of the most crucial elements
which will ensure the success of
software maintenance is a change of
management attitude. Unless soft-
ware maintenance staff are as well
paid as software development staff,
there is little hope that able program-
mers will be attracted to do the
maintenance jobs. The change of
attitude sounds simple, but in fact it is
the hardest part.
Some authorsy4 advocate the estab-
lishment of a separate independent
software maintenance department.
The supeticial advantages seem to be
better budgetary control, perfor-
mance measures and manpower plan-
ning. But the disadvantages seem to
outweigh the advantages. In the
separate department situation, the
people who maintain the software are
unlikely to be the original implemen-
tors. Communication problems may
then occur between the software
maintenance department and the soft-
ware development department. Worst
of all is that the software will degrade
at a faster rate, because people may
find it difficult to fit their thinking
into another persons framework.
Another fallacy is so-called preven-
tive softovaremaintenunce.A program
logic is either right or wrong; it
cannot be somewhere in between.
Thus, the preventive measure com-
monly used in hardware maintenance
cannot be carried over to software
maintenance. More importantly, the
more frequently the software is modi-
fied, the greater is the rate of its
degradation. A regular review (say
once every couple of years) of soft-
ware with users is perhaps a better
approach.
The above points suggest that ideal-
ly the person who maintains the
software should be the original imple-
mentor. Thus, the intuitive under-
standing of the internal model mani-
pulated by the program is not lost and
can be carried forward to the main-
tenance phase. Consequently, the
code can be modified in a systematic
manner. More importantly, if an error
is detected in the program, the origi-
nal implementor has a chance to
enhance his own understanding. Of
course, if the original implementor
has already left the operation, it does
not matter who is assigned to modify
the software. Some authors4 object to
this approach, claiming that the soft-
ware maintenance tends to use up
resources and the software develop-
ment eventually suffers. The problem
perhaps is due to the lack of proper
management control or insufficient
manpower or both.
Another innovation is the establish-
ment of a software quality control
(SQC) department. Obviously, such a
department should have independent
jurisdiction. In general, the function
of the SQC department is to control
the quality of software and its accom-
panying documents. More specifical-
ly, the activities of the SQC depart-
ment include the following:
l Approve the quality of system and
program specifications, and of final
programs - including program
validation, comprehensibility of
data processing

program logic and documentation;
* ensure the comprehensibility of
user guides;
l approve the quality of any modified
programs.
The disadvantages of setting up an
SQC department are:
* Delay of software operation time,
* additional SQC staff who must be
qualified programmers are re-
quired.
However, the long-term benefits
gained by the corporation outweigh
the disadvantages:
The software quality can be main-
tained at a satisfactory level,
the software maintenance cost will
be reduced substantially.
Nevertheless, the management solu-
tions do not guarantee that all soft-
ware maintenace problems will dis-
appear. I now turn to a discussion of
technical solutions which are com-
plementary to the management solu-
tions.
Technical Solutions
Computer science is a relatively new
science and many of its theories and
techniques are still under rapid deve-
lopment. Software maintenance has
only surfaced as a major disaster in
recent years, when software has been
used over a long period requiring the
maintaining effort of programmers.
No completely satisfactory technical
solutions have been found. In what
follows, I identify some of the tech-
nical problems - hopefully future
research effort will be directed at
them - and some of the tangible
solutions which require disciplined
practice.
Structured programming technique
does rwt work
In developing computer programs,
the structured programming techni-
~0126 no 6 julylaugust 1984
que has been proved to be one of the
most helpful techniques. But when it
comes to software maintenance, struc-
tured programming techniques do
not work well. The reason is that, in
software maintenance, one tries to
modify the structure of programs
which are already inflexible. The al-
ternative approach is to rewrite the
affected programs!
Modularity of computer programs
A module is the smallest logical pack-
age within a program that provides a
set of common functions. The modu-
larity of computer programs will in-
crease the maintainability of soft-
ware5. U~ortunately, conventional
programming languages, like COBOL,
FORTRAN and ~~11, do not support
information encapsulation very well.
Isolation encaps~ation is essential
for making the modularity a success.
New programming languages, such as
ADA and MOJXJLA-Z, provide a more
effective way of hiding unncessary
information. Sadly, such new pro-
gramming languages are incompatible
with COBOL, which is the most widely
used Prolog language in com-
mercial applications.
Rwwing what to document m
c~~~pro~a~
Some programmers do not know what
to document in computer programs or
purposely do not document the most
complex parts. The concept of soft-
ware quality control discussed in the
foregoing section will alleviate the
problem. As a general rule, all vari-
ables and all modules should bear
comments. Also, the more time a
programmer spends on a piece of
code, the more essential it is to
document the reasons beside the
code. The use of hierarchical charts
will also help to put the logic of
computer programs into perspective.
Knowing when to rewrite computer
programs
When computer programs are de-
systems
graded to beyond feasible mainte-
nance, it is time to rewrite them. But
even before this stage is reached,
some programs may be worth rewrit-
ting. Such a judgement depends very
much on the individuals experience.
Failure to recognize this point will no
doubt increase the software mainte-
nance cost.
Conclusion
The high cost of software mainte-
nance and the software maintenance
problems are mainly due to the use, in
the sixties and seventies, of immature
programming languages and systems
in the computerization of manage-
ent notation systems. The lack of
suitable programming languages and
the high cost of converting software
from one form to another have virtu-
ally ruled out any lasting solutions.
Hence corporations have to shoulder
the software maintenance burden.
Nevertheless, in the above discussion,
I have identified the software main-
tenance problems and have proposed
some management and technical solu-
tions that will help to alleviate some of
the pressing problems and to reduce
the cost of software maintenance.
References
1 Agresti, W W, Managing program
maintenance, 3 System Management,
vol 33, no 2(1982) pp 34-37.
2 Forney, R H, Race, R G and Nash-
leanas, R P, Data processing: a manage-
ment paradox, 3 Systems Management,
~0134, no 5 (1983) pp 21-23.
3 Glass, R L, Persistent software errors,
IEEE Trans Sofrware Engineering, vol
SE-7, no 2 (1981) pp 162-168.
4 Martin, G N, EDP systems mainte-
nance, 3 Systems Maggoty vol 30,
no 9 (1979) pp 18-21.
5 You, S S and Collofello, J S, Some
stability measures for software mainte-
nance, IEEE Trans Sofnuare Engineer-
ing, vol SE-6 no 6 (1980) pp 545-552.
0
Departmentof ComputingScience, University
of Woilongong,P. 0. Box 1144, Wollougong,
NSW 2500, Australia. Tel: (042) 270859.
27