IEEE defines Software Maintenance as “the process of modifying a software system or component after delivery to correct faults, improve performances or other attributes, or adapt to a changed environment.” Categories of maintenance include:
“Corrective maintenance: reactive modification of a software product performed after delivery to correct discovered faults.
Adaptive maintenance: modification of a software product performed after delivery to keep a computer program usable in a changed or changing environment.
Perfective maintenance: modification of a software product performed after delivery to improve performance or maintainability.
Emergency maintenance: unscheduled corrective maintenance performed to keep a system operational.”
The use of the term maintenance for software is different than other references to maintenance. Unlike the tires on your car, software does not “wear out”. If this is the case, then why does software maintenance account for such a high percentage of the Total Cost of Ownership for software?
The software maintenance definition refers to changes for defect correction, performance improvements, or adaptations to a changed environment (enhancements). According to this definition, if we build software that is defect-free, performs well, and contains user-controlled parameters to adjust processing rules in response to changing requirements then most maintenance would not be necessary. Could it be … that most software maintenance requirements could have been anticipated and avoided during the design process? In other words, maintenance is a form of waste.
Why does this happen? There are many reasons but the most common reasons are time constraints and lack of experience. Adding validation logic takes time so people make assumptions about the quality of in-bound data. Assumptions are also made about the volume of transactions and the impact on performance and the stability of the automated business processes. Finally, it is common for new software to be developed by younger developers who don’t understand the maintenance impacts of their designs.
The reality is that business requirements change and most of these assumptions are flawed. Transaction volumes increase, changing business processes require new transactions or new validation criteria, and software users will use the software incorrectly. The cost of software maintenance and the total cost of ownership can dramatically be reduced if developers built software that adjusted to changes in transaction volumes, validated all inbound data, and provided user-configurable options for decision logic and data validation.