©ian sommerville 2004 software engineering. chapter 21slide 1 chapter 21 software evolution
TRANSCRIPT
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 1
Chapter 21
Software Evolution
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 2
Objectives
To explain why change is inevitable (if software systems are to remain useful)
To describe different types of software maintenance
To identify maintenance cost factors To describe the maintenance prediction
process
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 3
Topics covered
Software change Program evolution dynamics Software maintenance and maintenance
types Maintenance costs and cost factors Maintenance prediction
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 4
Topics covered
Software change Program evolution dynamics Software maintenance and maintenance
types Maintenance costs and cost factors Maintenance prediction
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 5
Why software changes Software change is inevitable…
New requirements emerge when the software is used;
The business environment changes; Errors must be repaired; New computers and equipment are added to
the system; The performance or reliability of the system
may have to be improved.
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 6
Why effective change management is critical The ability to implement and manage
change is critical since… Organizations have huge investments in their
software systems - they are critical business assets.
To maintain the value of these assets, they must be changed and updated as necessary.
In fact, most of the software budget in large companies is devoted to evolving existing software rather than developing new software.
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 7
Spiral model of evolution
Specification Implemention
ValidationOperation
Start
Release 1
Release 2
Release 3
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 8
Topics covered
Software change Program evolution dynamics Software maintenance and maintenance
types Maintenance costs and cost factors Maintenance prediction
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 9
…is the study of the processes of system change.
After major empirical studies, Lehman and Belady proposed a number of “laws” which apply to large systems as they evolved.
They are actually sensible observations rather than “laws.”
Program evolution dynamics…
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 10
Lehman’s lawsLaw Description
Continuing change A program that is used in a real-world environment necessarilymust change or become progressively less useful in thatenvironment.
Increasing complexity As an evolving program changes, its structure tends to becomemore complex. Extra resources must be devoted to preservingand simplifying the structure.
Large program evolution Program evolution is a self-regulating process. Systemattributes such as size, time between releases and the number ofreported errors is approximately invariant for each systemrelease.
Organisational stability Over a programÕs lifetime, its rate of development isapproximately constant and independent of the resourcesdevoted to system development.
Conservation offamiliarity
Over the lifetime of a system, the incremental change in eachrelease is approximately constant.
Continuing growth The functionality offered by systems has to continually increaseto maintain user satisfaction.
Declining quality The quality of systems will appear to be declining unless theyare adapted to changes in their operational environment.
Feedback system Evolution processes incorporate multi-agent, multi-loopfeedback systems and you have to treat them as feedbacksystems to achieve significant product improvement.
1.
2.
3.
4.
5.
6.
7.
8.
(the “saturated state” idea)
(how to apply this?)
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 11
Limits of applicability Lehman’s laws seem to be generally
applicable to large, custom systems developed by large organizations.(But what about systems such as MS Word which originally operated in 256K of memory, but which is now a giant requiring many megabytes of memory?)
(cont’d)
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 12
Limits of applicability (cont’d) Also, it is not clear how the laws should
be modified for Shrink-wrapped software products; Systems that incorporate a significant
number of COTS components; Small organizations; Medium sized systems.
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 13
Topics covered
Software change Program evolution dynamics Software maintenance and maintenance
types Maintenance costs and cost factors Maintenance prediction
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 14
Modifying a program after it has been put into use to effect software change
Does not normally involve major changes to the system’s architecture
Changes are implemented by modifying existing components and/or adding new components to the system.
Software “maintenance”
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 15
Maintenance to repair software faults Maintenance to adapt software to a different
operating environment Maintenance to add to or modify the
system’s functionality
Types of maintenance
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 16
Maintenance to repair software faults Maintenance to adapt software to a different
operating environment Maintenance to add to or modify the
system’s functionality
How is maintenance effort typically divided among these three activities?
Types of maintenance
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 17
Distribution of maintenance effort
Functionalityaddition or
modification(65%)
Fault repair(17%)
Softwareadaptation
(18%)
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 18
Topics covered
Software change Program evolution dynamics Software maintenance and maintenance
types Maintenance costs and cost factors Maintenance prediction
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 19
Usually greater than development costs (2 to 100 times greater 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 very high support costs (e.g. old languages, compilers etc.).
Maintenance costs
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 20
Development/maintenance costs
0 50 100 150 200 250 300 350 400 450 500
System 1
System 2
Development costs Maintenance costs
$
reducing lifetime costs by spending more to increase maintainability during development
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 21
So what factors affect maintenance costs?
Maintenance cost factors
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 22
Team stability: Maintenance costs are reduced if the same staff are involved with the system for some time.
Contractual responsibility: The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change.
(cont’d)
Maintenance cost factors (cont’d)
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 23
Staff skills: 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.
Maintenance cost factors (cont’d)
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 24
Topics covered
Software change Program evolution dynamics Software maintenance and maintenance
types Maintenance costs and cost factors Maintenance prediction
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 25
Maintenance prediction…
…is concerned with assessing which parts of the system will be affected by change and what the costs of change will be.
This involves predicting: Number of changes that will be required and
the system parts that will be impacted; Maintainability of different system parts; and Short- and long-term cost of maintenance.
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 26
Maintenance prediction (cont’d)
Predictingmaintainability
Predicting systemchanges
Predictingmaintenance
costs
What will be the lifetimemaintenance costs of this
system?
What will be the costs ofmaintaining this system
over the next year?
What parts of the systemwill be the most expensive
to maintain?
How many changerequests can be
expected?
What parts of the system aremost likely to be affected by
change requests?
What parts of the system are most likely to be affected by change requests?
What parts of the system will be the most expensive to maintain?
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 27
Maintenance prediction (cont’d)
Predictingmaintainability
Predicting systemchanges
Predictingmaintenance
costs
What will be the lifetimemaintenance costs of this
system?
What will be the costs ofmaintaining this system
over the next year?
What parts of the systemwill be the most expensive
to maintain?
How many changerequests can be
expected?
What parts of the system aremost likely to be affected by
change requests?
What parts of the system are most likely to be affected by change requests?
What parts of the system will be the most expensive to maintain?
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 28
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.)
(cont’d)
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 29
Change prediction (cont’d)
Factors influencing this coupling are: Number and complexity of system interfaces; Number of inherently volatile system
requirements; and The business processes associated with
system use.
(cont’d)
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 30
Maintenance prediction (cont’d)
Predictingmaintainability
Predicting systemchanges
Predictingmaintenance
costs
What will be the lifetimemaintenance costs of this
system?
What will be the costs ofmaintaining this system
over the next year?
What parts of the systemwill be the most expensive
to maintain?
How many changerequests can be
expected?
What parts of the system aremost likely to be affected by
change requests?
What parts of the system are most likely to be affected by change requests?
What parts of the system will be the most expensive to maintain?
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 31
Product metrics
Studies have shown that most maintenance effort is spent on a relatively small number of system components.
Predictions of maintainability can be made by assessing the complexity of system components. E.g., Complexity of control structures; Complexity of data structures; Object, method (procedure) and module size.
(See, for example: Identifying Error-Prone Software - An Empirical Study (S.M. Thebaut,
V.Y. Shen, T.J. Yu, and L.R. Paulsen), IEEE Transactions on SE 11(4): 317-324, 1985.
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 32
Process metrics
Process measurements taken over time may also 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 unresolved change requests.
If any of these are increasing, it may indicate a decline in maintainability.
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 33
Maintenance prediction (cont’d)
Predictingmaintainability
Predicting systemchanges
Predictingmaintenance
costs
What will be the lifetimemaintenance costs of this
system?
What will be the costs ofmaintaining this system
over the next year?
What parts of the systemwill be the most expensive
to maintain?
How many changerequests can be
expected?
What parts of the system aremost likely to be affected by
change requests?
What parts of the system are most likely to be affected by change requests?
What parts of the system will be the most expensive to maintain?
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 34
Cost prediction
Use predicted change request and maintainability info together with intuition and experience to predict costs.
Cost estimation models (e.g., Boehm’s COCOMO 2) utilize estimates of program understandability and new code development effort to predict costs. (See Chap. 26.)
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 35
Key points Software development and evolution should
be seen as a single, iterative process. Lehman’s “Laws” describe a number of
insights into system evolution. Three types of maintenance are: bug fixing,
adapting software for a new environment, and adding/modifying functionality.
For custom systems, maintenance costs usually far exceed development costs.
©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 36
Chapter 21
Software Evolution