Topic 25: Software Maintenance and Re-engineering
Synopsis
- Not just "fixing mistakes"
- Any post-delivery modification to an existing system
- May be corrective, adaptive,
perfective, or preventative
- 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
- Inadequate documentation of software evolution
- Inadequate documentation of software design and structure
- Loss of "cultural" knowledge of software due to staff
turnover
- Lack of allowance for change in original software design
- Maintenance is unglamorous and may be viewed as a
"punishment task"
- "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
- Complex and varied (depends on type of maintenance)
- In general...
- ...request (in standard format)
- ...triage (determine priorities)
- ...analyse (for cost and consequences)
- ...design and implement
- ...test
- ...document
- 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
- Preventative maintenance (prevent foreseen maintenance
nightmares)
- An extension of reverse engineering
- Use (or modify) the reconstructed design to
generate new and better source code
- Pressman: Chapters 19.7, 20
- Sommerville: Chapters 27 & 28
This material is part of the CSE2305 - Object-Oriented
Software Engineering course.
Copyright © Jon McCormack & Damian Conway, 1998–2005. All rights
reserved.