CSE2305 - Object-Oriented Software Engineering
Week 13

Topic 25: Software Maintenance and Re-engineering

Synopsis

Impractical to exhaustively test a large software system
Therefore reasonable to assume that any large system will have errors
Testing should be thorough for common cases, so errors likely to be obscure
The process of receiving reports of such errors, diagnosing the problem, and fixing it is called "corrective maintenance"

Systems don't function in isolation
Typically they may interact with operating systems, DBMS's, GUI's, network protocols, other external software packages, and various hardware platforms
In the IT industry any or all of these may change over a very short period (typically six months)
The process of assessing the effects of such "environmental changes" on a software system, and then modifying the system to cope with those changes is known as "adaptive maintenance"

Users and marketers are never satisfied
Even if a system is wildly successful, someone will want new or enhanced features added to it
Sometimes there will also be impetus to alter the way a certain component of the system works, or its interface^¤
The process of receiving suggestions and requests for such enhancements or modifications, evaluating their effects, and implementing them is called "perfective maintenance"

Sometimes changes are needed for entirely internal reasons
Such changes have no direct discernible effect on the user, but lay the groundwork for easier maintenance in the future
Alternatively, such changes may improve reliability, or provide a better basis for future development
The process of planning such code reorganizations, implementing them, and testing to ensure that they have no adverse impact is known as "preventative maintenance"

Unstructured maintenance wades straight into the source code and makes changes based on that alone
Structured maintenance examines and modifies the original design, and then reworks the code to match it
Clearly structured maintenance is a more reliable and (usually) a more efficient process
Unfortunately, it's not always possible

Surveys in the 80's reveals up to 60% of organisational software effort spent in maintenance
$$$
Lost opportunities (for new development)
Customer dissatisfaction
Overall productivity

"The ease with which software can be understood, corrected, adapted, or enhanced." (Pressman)
Enhanced by....
...good initial design and understandable software structure
...comprehensive and accurate documentation (including design documents)
...use of standards (design, language, coding, etc.)
...availability of extensive test cases

Any error or undesirable behaviour^¤ that occurs as a result of modifications to a system
Coding side-effects (inadvertent removal of vital code, changes in semantics of code, unexpected changes in execution path)
Data side-effects (changes in data structures render older data invalid or incomplete, changes in global constants, changes in data ranges)
Documentation side-effects (forgetting to document code or data structure changes, changes not reflected in user manuals or interface^¤)

Build a specification and design out of existing code
Not just for industrial theft!
Legacy systems (what if the supplier no longer exists?)
May also be required if original system documentation was lost, poor, or non-existent