Introduction

 The maintenance of existing software can account for over 60 percent of all
development effort.
 Because change is inevitable, mechanisms must be developed for evaluating,
controlling and making modifications.
 Maintenance is a set of software engineering activities that occur after software
has been delivered to the customer and put into operation.
 70 per cent of the cost of software is devoted to maintenance.
 Maintenance activities can be divided into two types:
1. Modification
 As the specifications of computer systems change, reflecting
changes in the external world, so must the systems themselves.
2. Debugging
 Removal of errors that should never have been there in the first
place.
 More than two-fifths of maintenance activities are extensions and modifications
requested by the users.
 The magnitude of this proportion seems to reflect the lack of extendibility of
commonly implemented software.
 Changes in data formats is the next largest activity. The issue is not that some
part of the program knows the physical structure of the data but that this
knowledge is usually spread out over too many parts of the system.
 Emergency bug fixes cost more than routine, scheduled corrections. They are
performed under pressure, disrupt the orderly process of delivering new
releases and tend to introduce new errors.

Software Configuration Management

 Software configuration management activities are developed to identify
change, control change, assure that change is being properly implemented, and
report change to others who may have an interest.
 SCM is a set of tracking and control activities that begin when a software
development project begins and ends only when the software is retired.

Software Maintenance Activities

 Maintenance can be defined as four activities:
1. Corrective Maintenance
 A process that includes diagnosis and correction of errors.
 2. Adaptive Maintenance
 Activity that modifies software to properly interface with a
changing environment (hardware and software).
3. Perfective Maintenance
 Activity for adding new capabilities, modifying existing functions
and making general enhancements.
 This accounts for the majority of all effort expended on
maintenance.
4. Preventive Maintenance
 Activity which changes software to improve future
maintainability or reliability or to provide a better basis for future
enhancements.
 Still relatively rare.
 Distribution of maintenance activities (based on a study of 487 software
development organizations):

o Perfective: 50%
o Adaptive: 25%
o Corrective: 21%
o Others: 4%

Software Maintenance Characteristics

1. The activities required to accomplish the maintenance phase and the impact of
a software engineering approach (or lack thereof) on the efficacy of such
activities.
2. The costs associated with the maintenance phase.
3. The problems that are frequently encountered when software maintenance is
undertaken.

Activities

Unstructured Maintenance

If the only available element is the source code:

 painstaking evaluation of the code, complicated by poor internal

documentation,
 things such as program structure, global data structures, system interfaces,
performance and/or design constraints are difficult to ascertain and frequently
misinterpreted,
  ramifications of changes to the code are difficult to assess,
 regression tests are impossible to conduct because no record of testing exists.

Structured Maintenance

 Begins with an evaluation of the design documentation.

 The impact of required modifications or corrections is assessed and an
approach is planned.
 The design is modified and reviewed, new source code is developed and
regression tests are conducted.

Maintenance Costs

 Typical software organizations spend anywhere from 40 to 70 percent of all

funds conducting maintenance.
 Maintenance-bound organizations result --> loss or postponement of
development opportunities.
 Customer dissatisfaction when requests cannot be addressed.
 Reduction in overall software quality as a result of changes that introduce latent
errors in the maintained software.

Topic 25: Software Maintenance and Re-engineering

Synopsis
 What is "maintenance"
 
 Corrective maintenance
 
 Adaptive maintenance
 
 Perfective maintenance
 
 Preventative maintenance
 
 Structured vs unstructured maintenance
 
  Maintenance costs
 
 Typical problems with maintenance
 
 Software maintainability
 
 Maintenance process
 
 Maintenance side-effects
 
 Reverse engineering
 
 Re-engineering
 
 Reading

What is "maintenance"
 Not just "fixing mistakes"
 
 Any post-delivery modification to an existing system
 
 May be corrective, adaptive, perfective, or preventative

Corrective maintenance
 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"

Adaptive 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"

Perfective 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"

Preventative 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"

Structured vs unstructured 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

Maintenance costs
 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

Typical problems with maintenance

 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"

Software maintainability
 "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

Maintenance process
 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

Maintenance side-effects
 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 ¤)
Reverse engineering
 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

Re-engineering
 Preventative maintenance (prevent foreseen maintenance nightmares)
 
 An extension of reverse engineering
 
 Use (or modify) the reconstructed design to generate new and better source code

Reading
 Pressman: Chapters 19.7, 20
 Sommerville: Chapters 27 & 28