This overview of software maintenance is drawn from multiple sources. We are at a relatively strange period in software engineering where maintenance and evolution activities account for much, if not most, of software costs, yet most of our understanding is based on studies that are decades out of date.
Sommerville defines software maintenance as: “When the transition from development to evolution is not seamless, the process of changing the software after delivery is often called software maintenance” [1].
More generally, maintenance involves modifying a program after it has been put into use. We usually do not expect maintenance to involve major changes to the system’s architecture. Rather, changes are made by modifying existing components and adding new components to the system. From a programmer’s perspective, the key issue is that the programmer must understand the program and its structure.
Maintenance is important because software is crucial to company’s success and because software is very complicated. In today’s world, most of the software budget is devoted to modifying existing software rather than developing new software.
Successful software products are usually in use much longer than in development, making maintenance even more crucial. If software does not continue to adapt to changes in needs and environment, it becomes progressively less useful. Changes are inevitable, and occur for several reasons:
Some changes are due to the tight coupling with the environment. When software is installed, it changes that environment, in effect changing the software requirements
In practice, many software engineers and managers have falsely been convinced of several things that are simply not true. Some of these myths are explained and contradicted below.
Myth: “We already have a book that’s full of standards and procedures for
building software, won’t that provide my people with everything they need to
know?”
Reality: The book of standards may very well exist, but is it used?
In many cases, the answers to the following questions are “no.”
Myth: If we get behind schedule, we can add more programmers and catch up.
Reality: Software development is not a mechanistic process like manufacturing.
As Brooks said: “adding people to a late software project makes it
later.”
Myth: If I outsource the software project to a third party,
I can just relax and let that firm build it.
Reality: If an organization does not understand how to manage and
control software projects internally,
it will invariably struggle when it outsources software projects.
Myth: General objectives are enough to start programming—we can fill in the details later. Reality: A poor up-front definition is a major cause of failed software efforts. If you don’t know what you want at the beginning, you won’t get what you want.
Myth: Project requirements continually change, but change can be easily accommodated because software is flexible. Reality: It is true that software requirements change, but the impact of a change depends on when it is introduced.
Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that “the sooner you begin ‘writing code,’
the longer it’ll take you to get done.”
Industry data indicate that between 60 and 80 percent of all effort expended on software
will be expended after it is delivered to the customer.
Maintenance has traditionally been divided into four types. The percentages given in textbooks are all similar, and based on studies from the early 1980s. It seems unlikely the numbers still hold, so take these with a grain of salt. Unfortunately, they are all we have.
Some authors will consider emergency maintenance as being a type of corrective maintenance that is not scheduled.
A major change in the last 20 years in the way software is maintained is that companies often release an intentionally partial version, then add to it over time. It is not clear to me whether this is properly considered to be perfective, adaptive, or something else. But it is clear that the term evolution is more appropriate than maintenance. This is possible when software is easy to update. For example, software in our mobile devices can be updated every day, as opposed to software in submarines, which can normally only be updated when the submarine visits port. Indeed, this is a major driver behind the Intenet of Things movement. Fixing a software problem in my washing machine requires an expensive visit by a technician to replace a circuit board, whereas if my washing machine is on the internet, the company can download new software for almost no cost.
Modifying software, no matter how or when, is difficult and costly. When software and hardware is tightly integrated, software is also often looked at as the easiest part to change. But just because the manufacturing cost is so slow does not mean the design and implementation cost of making changes is free.
Large software programs are extremely complicated, and very difficult to understand. Yet they must be understood before they can be changed. Many changes are rushed, so the modifications are often poorly designed and implemented To make things worse, changing the software almost invariably injects new faults that must be repaired later.
Sommerville [1] claims that 90% of all software costs are related to software evolution. Even if that’s overstated, few would doubt that more than half of software costs are accrued after first deployment. The costs are due to both technical and non-technical factors. Most engineers agree that the cost of making the same type of change goes up as the software ages. This is due to many factors, including loss of memory about the initial design and construction, changes in technologies and languages, and the difficulty of understanding previous (often sloppy) changes.
Some common technical cost factors are:
Some common human cost factors are:
Most of these definitions are taken from IEEE standards [2] or textbooks (which probably derived them from the IEEE).
As said above, most of the available literature on maintenance and regression is 30 years old! The IEEE standards are from 1990, and only changed modestly from their 1983 versions. The major textbooks have been updated regularly since the 1980s, the information on maintenance has not changed much.
The literature is also conflicted over the use of maintenance and evolution. A possible distinction is:
I have also heard them distinguished as software maintenance being about fixing the software so that it is close to working as intended (adaptive, corrective, and preventive), whereas evolution is about changing its intended behavior (perfective).
Before concluding, any overview of maintenance or evolution must have a nod to Lehman’s laws. They were first proposed around 1980, and still seem to be relevant today.
[1] Sommerville, Software Engineering, edition 10, Addison-Wesley Publishing Company Inc., 2015
[2] IEEE, Standard Glossary of Software Engineering Terminology, ANSI/IEEE Std 610.12-1990, Institute of Electrical and Electronic Engineers, New York, 1990
[3] Wikipedia, Change impact analysis, https://en.wikipedia.org/wiki/Change_impact_analysis, accessed January 2018
[4] Wikipedia, Lehman’s laws of software evolution, https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution, accessed January 2018
Jeff Offutt
George Mason University
offutt@gmu.edu
January 2018