ISO/IEC 14764 presents: Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems. Corrective maintenance can be automated with automatic bug fixing. Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment. Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability. Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults. There is also a notion of pre-delivery/pre-release maintenance which is all the good things you do to lower the total cost of ownership of the software. Things like compliance with coding standards that includes software maintainability goals. The management of coupling and cohesion of the software. The attainment of software supportability goals (SAE JA1004, JA1005 and JA1006 for example). Some academic institutions are carrying out research to quantify the cost to ongoing software maintenance due to the lack of resources such as design documents and system/software comprehension training and resources (multiply costs by approx. 1.5-2.0 where there is no design data available). Maintenance factors Impact of key adjustment factors on maintenance (sorted in order of maximum positive impact) Not only are error-prone modules troublesome, but they can degrade performance too. For example, very complex spaghetti code is quite difficult to maintain safely. A very common situation which often degrades performance is lack of suitable maintenance tools, such as defect tracking software, change management software, and test library software. Below describe some of the factors and the range of impact on software maintenance. Impact of key adjustment factors on maintenance (sorted in order of maximum negative impact) Maintenance debt In a paper for the 27th International Conference on Software Quality Management in 2019, John Estdale introduced the term “maintenance debt” for maintenance needs generated by an implementation’s dependence on external IT factors such as libraries, platforms and tools, that have become obsolescent. The application continues to run, and the IT department forgets this theoretical liability, focussing on more urgent requirements and problems elsewhere. Such debt accumulates over time, silently eating away at the value of the software asset. Eventually something happens that makes system change unavoidable. The owner may then discover that the system can no longer be modified – it is literally unmaintainable. Less dramatically, it may take too long, or cost too