©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 1 Chapter 21 Software Evolution

©Ian Sommerville 2004 Software Engineering. Chapter 21 Slide 1

Chapter 21

Software Evolution


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


Topics covered

Software change Program evolution dynamics Software maintenance and maintenance

types Maintenance costs and cost factors Maintenance prediction


Topics covered




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.


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.


Spiral model of evolution

Specification Implemention

ValidationOperation

Start

Release 1

Release 2

Release 3


Topics covered




…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…


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?)


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)


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.


Topics covered




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”


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


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


Distribution of maintenance effort

Functionalityaddition or

modification(65%)

Fault repair(17%)

Softwareadaptation

(18%)


Topics covered




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


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


So what factors affect maintenance costs?

Maintenance cost factors


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)


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)


Topics covered




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.


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?






costs


system?


over the next year?


to maintain?


expected?


change requests?




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)


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)






costs


system?


over the next year?


to maintain?


expected?


change requests?




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.


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.






costs


system?


over the next year?


to maintain?


expected?


change requests?




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.)


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.


Chapter 21

Software Evolution

Documents

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 1 Chapter 21 Software Evolution