ECE 453 – CS 447 – SE 465
Software Testing &
Quality Assurance
Lecture 25
Instructor
Paulo Alencar
1
Overview
Software Maintenance and Evolution
Definitions
Evolution Dynamics
 Software Maintenance
2
Terminology
Software Evolution
– a continuous change from a lesser, simpler, or
worse state to a higher or better state.
Software Maintenance
– consists of the activities required to keep a
software system operational and responsive after
it is accepted and placed into production.
3
Objective
• To explain why change is inevitable if
software systems are to remain useful
• To discuss software maintenance and
maintenance cost factors
• To describe the processes involved in
software evolution
• To discuss an approach to assessing
evolution strategies for legacy systems
4
Software Change
•
Software change is inevitable
–
–
–
–
–
•
New requirements emerge when the software is used;
The business environment changes;
Errors must be repaired;
New computers and equipment is added to the system;
The performance or reliability of the system may have
to be improved.
A key problem for organisations is implementing
and managing change to their existing software
systems.
5
Importance of Evolution
• Organizations have huge investments in
their software systems - they are critical
business assets.
• To maintain the value of these assets to the
business, they must be changed and updated.
• The majority of the software budget in large
companies is devoted to evolving existing
software rather than developing new
software.
6
Spiral Model of Evolution
7
Evolution Dynamics
• Program evolution dynamics is the study
of the processes of system change.
• After major empirical studies, Lehman and
Belady proposed that there were a number of
‘laws’ which applied to all systems as they
evolved.
• There are sensible observations rather than
laws. They are applicable to large systems
developed by large organisations. Perhaps
less applicable in other cases.
8
Lehman’s Laws
•
•
•
•
•
•
•
•
The Law of Continuing Change (1974)
The Law of Increasing Complexity (1974)
The Law of Self Regulation (1974)
The Law of Conservation of Organizational Stability (1980)
The Law of Conservation of Familiarity (1980)
The Law of Continuing Growth (1980)
The Law of Declining Quality (1996)
The Feedback System Law (1996)
Source: Lehman, M., et al, “Metrics and Laws of Software Evolution—The Nineties View,”
Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997.
9
Lehman’s Laws
Law
Description
Continuing change
A program must change or become progressively less
useful
Increasing complexity
As program changes, its structure becomes more
complex Extra resources are required.
Large program evolution
System attributes, (eg, size, time between releases) is
~invariant for each system release.
Organizational stability
A program’s rate of development is ~constant.
Conservation of familiarity
The incremental change in each release is ~constant.
Continuing growth
The functionality has to continually increase to maintain
user satisfaction.
Declining quality
Quality of systems appear to be declining unless adapted
to changing environments
Feedback system
Evolution processes involve feedback systems for
product improvement
10
Applicability of Lehman’s Laws
•
Lehman’s laws seem to be generally applicable to
large, tailored systems developed by large
organisations.
–
•
Confirmed in more recent work by Lehman on the
FEAST project
It is not clear how they should be modified for
–
–
–
–
Shrink-wrapped software products;
Systems that incorporate a significant number of COTS
components;
Small organisations;
Medium sized systems.
11
Software Maintenance
‘When the transition from development to evolution
is not seamless, the process of changing the software
after delivery is often called software maintenance’.
(Sommerville, 2004)
• Maintenance involves extra process activities:
• Program understanding
12
Software Maintenance
• Modifying a program after it has been put into
use.
• Maintenance does not normally involve major
changes to the system’s architecture.
• Changes are implemented by modifying
existing components and adding new
components to the system.
13
Maintenance is Inevitable
•
•
•
The system requirements are likely to change
while the system is being developed because
the environment is changing. Therefore a
delivered system won't meet its requirements!
Systems are tightly coupled with their environment.
When a system is installed in an
environment it changes that environment and
therefore changes the system requirements.
Systems MUST be maintained therefore if they
are to remain useful in an environment.
14
Types of Maintenance
•
Maintenance to repair software faults
–
•
Maintenance to adapt software to a different
operating environment
–
•
Changing a system so that it operates in a different
environment (computer, OS, etc.) from its initial
implementation.
Maintenance to add to or modify the system’s
functionality
–
•
Changing a system to correct deficiencies in the way
meets its requirements.
Modifying the system to satisfy new requirements.
Maintenance to detect and correct latent faults before
they become effective (preventive).
15
Types of Maintenance
•
•
•
•
Corrective Maintenance
Adaptive Maintenance
Perfective Maintenance
(Preventative Maintenance - Pressman)
•
•
Sommerville (2004) avoids the use of these names
because their definitions are uncertain
We will work with the following definitions
16
Corrective Maintenance
•
•
Focuses on fixing defects, ie, fault repair
It is a reactive process
– i.e. defects generally need to be corrected either
immediately or in the near future
•
Defects
– refer to the system not performing as originally
intended or as specified in the requirements
17% of maintenance is correcting faults
17
Adaptive Maintenance
It includes all changes to meet the evolving needs of the user
and the environment
– i.e. modifications to a system to cope with a changing
environment, eg changed hardware, operating system
18% of maintenance is change to adapt to a new environment
•
It includes work to enhance a system’s functionality
– i.e. relates to changing a system when requirements
change due to organisational or business changes
– The scale of this maintenance is often greater than for
other types of maintenance
65% of maintenance is new requirements
•
18
Perfective Maintenance
•
•
It includes all efforts to improve the quality of the
software
It includes restructuring code, creating and
updating documentation, improving reliability or
efficiency, improving performance
Maintenance work in the above categories is often
performed concurrently
19
Differences:
S/W Development and Maintenance
– Constraints of an existing system
» Changes must conform or be compatible with an
existing architecture, design and code constraints
– Shorter time frames
» Development spans 1 or more years
Maintenance spans hours or up to 6 months
– Available test data
» Development creates all test data from scratch
Maintenance uses existing test data with regression
testing creating new data for the changes
20
Distribution of Maintenance Effort
Fault repair
(17 %)
Software
adap tation
(18 %)
Functio nality
addition o r
modificatio n
(6 5%)
21
Relative Costs of Maintenance
3%
3%
5%
7%
15%
67%
Requirements definition
Preliminary design
Detailed design
Implementation
Testing
Operations and Maintenance
• The majority of a software budget in large companies is
devoted to maintaining systems
• Sommerville (2004) states that 90% of software costs are
evolution costs
22
Maintenance Costs
•
•
•
•
Usually greater than development costs (2* to
100* depending on the application).
Affected by both technical and non-technical
factors.
Increases as software is maintained.
Maintenance corrupts the software structure so
makes further maintenance more difficult.
Ageing software can have high support costs
(e.g. old languages, compilers etc.).
23
Development/Maintenance Costs
24
Maintenance Cost Factors
•
Team stability
–
•
Contractual responsibility
–
•
The developers of a system may have no contractual
responsibility for maintenance so there is no incentive to
design for future change.
Staff skills
–
•
Maintenance costs are reduced if the same staff are
involved with them for some time.
Maintenance staff are often inexperienced and have
limited domain knowledge.
Program age and structure
–
As programs age, their structure is degraded and they
become harder to understand and change.
25
Maintenance Prediction
•
Maintenance prediction is concerned with
assessing which parts of the system may cause
problems and have high maintenance costs
–
–
–
Change acceptance depends on the maintainability of
the components affected by the change;
Implementing changes degrades the system and
reduces its maintainability;
Maintenance costs depend on the number of changes
and costs of change depend on maintainability.
26
Maintenance Prediction
What p arts o f the sy stem
willbe themost expensive
to main tain?
What par tsof the system are
most likelyto be affectedby
change requests?
Predicting
maintain ability
Predicting sy stem
changes
How man y ch ange
requests can be
exp ected?
Predicting
maintenan ce
costs
What will be th e lifetime
maintenan ce co sts of this
system?
What will be th e costs o f
maintain ing th is sy stem
ov er the n ext y ear?
27
Change Prediction
•
•
•
Predicting the number of changes requires an
understanding of the relationships between a
system and its environment.
Tightly coupled systems require changes
whenever the environment is changed.
Factors influencing this relationship are
–
–
–
Number and complexity of system interfaces;
Number of inherently volatile system requirements;
The business processes where the system is used.
28
Complexity Metrics
•
•
•
Predictions of maintainability can be made by
assessing the complexity of system components.
Studies have shown that most maintenance effort
is spent on a relatively small number of system
components.
Complexity depends on
–
–
–
Complexity of control structures;
Complexity of data structures;
Object, method (procedure) and module size.
29
Process Metrics
• Process measurements may be used to assess
maintainability
– Number of requests for corrective maintenance;
– Average time required for impact analysis;
– Average time taken to implement a change
request;
– Number of outstanding change requests.
• If any or all of these is increasing, this may
indicate a decline in maintainability.
30