Unit 16: Maintenance & Evolution
Objectives
Ð To introduce the challenge of maintaining a
continuously evolving software system
Ð To examine those aspects of a software system
that are likely to change
Ð To examine the types of changes that are likely to
take place
Ð To describe the activities & personnel involved in
the maintenance process
Ð To outline some maintenance tools and techniques
Development versus maintenance
Software
development
process
Software
maintenance
process
Software
goes ÒliveÓ
Boundaries can blur
1
Change
¥ Software changes; software systems evolve
¥ Why does software change?
¥ Perception that software is easy to change
Legacy software systems
Hardware failure
failure rate
infant mortality
wear out
time
2
Software failure (idealised)
failure rate
infant mortality
time
Software failure (actual)
failure rate
actual
change
idealised
time
3
ÒLawsÓ of software evolution
¥ Continuing change
[Lehman & Belady 1985]
¥ Increasing complexity
¥ Fundamental law of program evolution
¥ Conservation of organisational stability
¥ Conservation of familiarity
=> Software systems need to be built to
incorporate change
Describing how software can change
¥ Can categorise software systems in terms of how they
may change & how likely they are to change [Lehman
1980]
Ð S-systems
Ð P-systems
Ð E-systems
4
S-systems
¥ Systems that are formally
defined by & derivable
from a specification
¥ Unlikely to change
Real world
Problem
Reqts spec
System
Information
P-systems
¥ Systems that are based on an
abstraction of a problem rather
than a completely defined
specification
¥ Subject to incremental change
Real world
Problem
Abstraction
Reqts spec
System
Information
5
E-systems
¥ Systems that are embedded
in the real world & change
as the world changes
Real world
Problem
¥ Subject to constant change
Abstraction
Reqts spec
System
Information
Ways to deal with change
¥ Software maintenance - the general process of
changing a system once it has been delivered
We will focus on this
¥ Architectural transformation - modifying the
system architecture to a distributed configuration
(legacy systems & middleware)
¥ Software re-engineering - improving the system
structure to reduce the cost of future maintenance
Read about these in [Sommerville 2001]
6
Software maintenance
Types of software maintenance
¥ Corrective - maintaining control over day-to-day
operation
¥ Adaptive - maintaining control over modifications
¥ Perfective - perfecting existing functions
¥ Preventive - preventing performance degrading to
an unacceptable level
Not always so clear cut in practice
7
The who, why, what of maintenance
¥ Maintenance team
Good maintainers
are good detectives!
¥ Maintenance process
Change
requests
Impact
analysis
Fault
repair
Release
planning
Platform
adaptation
Change
implementation
System
release
System
enhancement
From [Sommerville 2001] p 610
Predicting maintenance effort
¥ Factors affecting effort include application type,
system novelty, turnover & staff availability, system
life-span, dependence on a changing environment,
hardware characteristics, design quality, code quality,
documentation quality, testing quality, code
complexityÉ
M = p + Kc-d
OR
Size = ASLOC(AA + SU + 0.4DM = 0.3CM + 0.3IM)/100
8
Techniques & tools for maintenance
¥ Key techniques
Ð Configuration management & change control
Ð Requirements traceability & impact analysis
¥ Key tools
Ð Text editors
Ð File comparators
Ð Compilers & linkers
Ð Debugging tools
Ð Cross-reference generators
Ð Static code analysers
Ð Configuration management repositories
When to stop maintenance?
¥ Is the cost of maintenance too high?
¥ Is the system reliability unacceptable?
¥ Can the system no longer adapt to further change
within a reasonable timescale?
¥ Is system performance still beyond prescribed
constraints?
¥ Are system functions of limited usefulness?
¥ Can other systems do the same job faster, better,
cheaper?
¥ Is the cost of maintaining the hardware great enough
to justify replacing it with cheaper, newer hardware?
[Pfleeger 1998, p418]
9
Key points
¥ The more a software system is linked to the realworld, the more likely it is to change
¥ Software maintenance is the most common approach
for dealing with change & there are 4 basic types of
maintenance depending on the type of change
¥ Projects need dedicated teams & processes for
maintenance activities
¥ The best way to lower maintenance effort is to build
quality in from the start!
Many related terms & concerns!
Core references
¥ Keith Bennett & Vaclav Rajlich, ÒSoftware Maintenance
& Evolution: A RoadmapÓ, in the FSE 2000 readings
You are expected to read this - the material is examinable!
¥ Roger Pressman, ÒSoftware Engineering: A PractitionerÕs
ApproachÓ, McGraw-Hill, 5th edition, ISBN: 0-07709677-0
Ð Issues discussed in
You are strongly advised to
various places
read one of these!
¥ Ian Sommerville, ÒSoftware EngineeringÓ, AddisonWesley, 6th Edition, ISBN: 0-201-39815-X (Chapter 27)
Ð Read the rest of Part 7 to get a wider perspective
10
Supplementary references
¥ M. M. Lehman & L. A. Belady, ÒProgram Evolution,"
Academic Press, January 1985
¥ Shari Lawrence Pfleeger, ÒSoftware Engineering:
Theory & PracticeÓ, Prentice Hall, 1998
¥ S. A. Bohner, ÒSoftware Change Impact AnalysisÓ,
IEEE Computer Society Press, 1996
¥ IEEE Software - Special issues on Maintenance topics
- Jan 1990, Jan 1993, Jan 1995
¥ Dedicated Journal - ÒSoftware Maintenance: Research
& PracticeÓ & an International Conference
11