Maintenance

What is Software Maintenance?

Problems
Costs
 Costs
• A surveys undertaken in 1980 and 1984
showed that for large organisations,
- at least 50% of their total programming
effort was devoted to maintaining
existing systems
- between 65% and 75% of total effort
available was devoted to maintenance
• Today, almost certainly maintenance is
the biggest single software engineering
activity
 Why Does Software Need
Maintenance?
• Software doesn’t wear out
- Irrespective of how many times you run it
software does not degrade
• This unlike mechanical and electrical
systems, which have physical wear out
mechanisms
- You have to keep changing light bulbs!!
• The failure rate versus time curves for
software and hardware (introduced in
Lecture 1) are shown on the next slide
Hardware and Software Failure
Rates Vs. Time
 If Software Doesn’t Wear Out
Why Does it Need
maintenance?
• Software may need to be changed
because
- It was delivered bugs
• These need to be fixed - Corrective Maintenance
- The environment in which the software
operates may change
• For example, a new hardware platform - Adaptive
Maintenance
- The customer’s requirements may change
• For example, the software requires new features -
 Corrective Maintenance
• Fixing errors
- This may be
• Coding errors
- These are relatively cheap to fix
• Design errors
- More expensive as several modules may need to
be rewritten
• Analysis errors
- The most expensive, the program may require
significant redesign
• Surveys shows that about 17% of
maintenance is corrective
 Adaptive maintenance
• Adaptinf the software to changes in its environment
- The operating system may change, the hardware
platforms may change
• Suppose that you wrote a program 10 years ago for
PCs
- You may have gone through DOS, Windows 3.1 and
Windows 95, Windows 98, Windows NT versions
• Note that the functionalityy of the software does not
radically change
• Surveys shown that about 18% of maintenance is
adaptive
 Perfective Maintenance
• Cutomers’ requirements will change with time
- Some software programs have lifetime of greater
than 10 or 15 years
• New functional and non-functional requirements
will emerge as time goes by
• Surveys shows that about 65% of maintenance is
perfecrtive
• Perfective maintenance involves adding
functionality to existing software, this can cause
problems - see next slide
Problems in Adding Functionality
to Existing Software
• Maintenance is not very ‘ ‘
- Generally carried out by less experienced staff
• Programs might be old
- They may not have used modern Software Engineering techniques
• Changes to the program may introduce new faults
- Which in turn require more maintenance
• As the program is chnaged its structure degrades
- This leads to increasing unreliability
• Documentation and program become out of step
- Therefore documentation no longer describes the program
Failure Rate Vs. Time for
Software Maintenance
 Preventative Maintenance
• There is a fourth kind of maintenance activity
- This involves redesign, rewriting and
documentation of the code after the program has
been delivered and ltered due to maintenance
activities
• The idea is that preventative maintenance can improve
the code’s structure and design making subsequent
maintenance easier
- It tries to prevent degradation in the structure of the
code
 The Maintenance Process (I)
• A maintenance activity is initiated by the
raising of a Change Request
- This may be initiated by the customer, user,
marketing or management
• The Change Request is then subjected to
an Impact Analysis
- The impact analysis determines what needs to be
changed in the program to meet the Change
Request
 The Maintenance Process (II)
• The work to meet the Change Request is
then planned
- The maintenance may be adaptive, corrective
and /or perfective
• The work is carried out
• The new release of the system must then
be validated before delivered to the
customer
 Maintenance as Iterative
Development
• Ideally maintenance can be thought of
as an iteration through a standard
software development process

Change Change Update Software

Requests Analysis Requests Develop

Standard
Development
Process
 Maintenance as Fault Repair
• In practical situations, the maintenance
activity has to take place urgently to
respond to customer problems
- In this case iterative development is not
appropriate
- The following process occurs

Change Analyse Modify Delivered

Request Source Source Repaired
Code Code System
 Maintenance as Fault Repair
• Problems can occur
- Documents may not be updated
• Therefore design does not reflect actual program
- Time pressures may be extreme
• Therefore solutions are chosen that can be introduced in the
fastest possible time
• But these may not be the ‘best solutions’
• A preventative maintenance activity may review
the ‘emergency change later and review the
product using the interative development
approach
 Documents
• The importance of good documentation for maintenance purposes
cannot be understated
• Suppose that in C lab you are given another student’s project and
asked to
- fix some faults
- and add a significant new function
• Would the source code alone be sufficient
• Remember that programs developed in the laboratory are tiny by
industry standards
 Useful Documents (I)
• Requirements
- together with rationale
• Systems and program architecture
- This may be, for example a set of Structure Charts
for each program and an indication of how the
programs fit together
– There may be more than one program!!

• For each component (module) a

specification and design description
- This may be pseudocode
 Useful Documents (II)
• Program source code listings
• Validation documents describing how the
system and its constituent programs are
validated (tested)
• System maintenance document
– Describes all known problems
– Describes how the programs were designed
with evolution in mind
 Lehman’s Laws
• These are a set of hypotheses that have
been derived from the observation of the
evolution of large software systems
• The ‘laws’ are derived from measurements
• It is claimed that these have wide
applicability
- They are useful way of considering the
maintenance and evolutiuon of large software
systems
 Continuing Change
• A program that is useful in a real-world
environment must change or become
progressively less useful in that
environment
• This says that you can’t get rid of
maintenance
- It is inevitable because the customer’s
requirements will change with time
 Increasing Complexity
• As an evolving program changes, its structure
tends to become more complex. Extra
resources must be devoted to preserving and
simplying the structure
• As change occurs, a program structure
degrades
• If the structure is not to degrade, additional
costs must be incurred in activities that reverse
the structural degradation
– This may be Preventative Maintenance
 Large Program Evolution (I)
• Program evolution is a self-regulating
process. Systems attributes such as size,
time between release and the number of
reported errors are approximately invariant
for each system release
• This says that the rate at which a large
program can change is not a function of
the effort that is expended but is a
fundamental property of the system itself
and the organisation that developed it
 Large Program Evolution (II)
• For instance, if a change is carried out, the
size of the system will mean that many
new faults are introduced
• These faults must be fixed, thus adding time to the
release
• Moreover, large systems are delivered by
large organiusation that have considerable
internal bureaucracies that inhibit the
speed at which decisions can be made
 Organisational Stability
• Over a program’s lifetime, its rate of developement is
approximately constant and independent of the
resources devoted to a system developement
• However, many Software Engineers that you allolcate
top the evolution activity the rate of p[rogresss will
always be the same
• If you allocate a lot of Software Engineers to the
product, the needs for comunication between the
members of the team will become large and the
amount of productive work per engineer will fail
Note on Organisational Stability
• This is related to a commonly observed
phenomena in Software Engineering
- Sometimes called the ‘Mongolian Horde Effect’
• Suppose you have a large software project
and it is running behind schedule
- The temptation is to allocate more resources to the
project (more people)
» A ‘Mongolian Horde’
- This does not fix the problem, because the overheads
in team communication take so much time
 Conservation of Familiarity
• Over the lifetime of the system, the
incremental change in each release is
approximately constant
• There is a seemingly fundamental rate at
which you can introduce new functionality
• For example
- If a new release of the system introduces a lot of
new functionality, another release is required
shortly afterwards to fix the bugs introduced into
the previous release
 Maintenance Costs
• Maintenance costs are depenmdent on a
number of factors, we’ll discuss these in a
minute
• One observation that can be made is the
better the original analysis, design,
implementation and test, the lower the
maintenance costs
- Certainly minimising development costs by cutting
corners can add considerably to both
» Validatioand maintenance costs
Maintenance Costs
Factors that affect Maintenance
Costs (I)
• Good Software Engineering
-Independent modules that exhibit information hiding
(loosely coupled and strongly cohesive) allow
modules to be changed without affecting other
modules
- Good Programming Style (meaningful variable
names and comments, style corresponding to house
standards) leads to readable code
- Good test and validation if this is carried out
properly there will be fewer errors in the program and
corrective maintenance costs will be reduced
Factors that affect Maintenence
Costs (II)
• Good Software Engineering (ctd)
- Quality of Documentation: Well-documented
programs are cheaper to maintain than those
with poor or non-existent documentation
- Good configuration management technique.
- Use of modern programming languages
 Facvtors that affect
Maintenance Costs (III)
• Understanding how the software is to be
used by the customer is important
- This is referred to as the application domain
- If the application domain is well understood
the system’s requirements should be good,
hence perfective maintenance will be minimized
- If the application domain, is not so well
understood, requirements will be less precise
and perfective maintenance may be higher
Factors that affect Maintenance
Costs (IV)
• If the person who wrote the code is responsible for
its maintenance, cost will be reduced
• The older the program, the more its structure
degrades, the more expensive it is to maintain
• If the external environment of the program is
stable, the program will require less maintenance
• If the program is designed for a particular
hardware platform, and that does not change
during the lifetime of the system, costs will be
reduced
Wrap Up
Metrics
Maintenance
Project Management
 Specification in this Course
• We can view a specification as being the goal of
the Analysis stage of the process models
discussed in the previous lectures
• We will not try to indicate how the analysis stage
arrives at the specification
- We will simply write specifications
- In later years you will learn about requirements
gathering and analysis (if there any such course
available, really I don’t know)
 Specification in Software
Engineering
• The goal of specification is to provide a complete
and unequivocal statement of what the software
must do
- This is far from easy
• There are many ways of writing specifications
- Using Natural Language (text)
- Using graphical notations (which may be formal)
- Using formal notations (which may be graphical)
Natural Language-Based Specifications (I)
• Many specifications in industry take the form of a textural
document that states the requirements for the system
- Such documents are often referred to as Requirement
Specifications
• There are problems with using natural language
- Documents can be very large
• Hundreds or even thousands of pages!
- Natural language is imprecise
• It’s very difficult to use natural language in a way that has only one
interpretation