Software change - ESSeRE

essere.disco.unimib.it

Software change - ESSeRE

Software evolution: Software Change

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 1


Objectives




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 (evolution dynamics)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 2


Topics covered



Strategies for changing software systems

• maintenance

• evolution

• re-engineering

Transformation of legacy systems from

centralised to distributed architectures

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 3


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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 4


Software change strategies





Software maintenance

• Changes are made in response to changed requirements

but the fundamental software structure is stable

Architectural transformation

• The architecture of the system is modified generally from

a centralised architecture to a distributed architecture

Software re-engineering

• No new functionality is added to the system but it is

restructured and reorganised to facilitate future changes

These strategies may be applied separately or

together

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 5


Importance of evolution




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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 6


Spiral model of evolution

Specification

Implemention

Release 1

Star t

Operation

Validation

Release 2

Release 3

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 7


Program evolution dynamics




Program evolution dynamics is the study of

the processes of system change.

After major empirical studies, Lehman and

Belady (1985) 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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 8


Lehman’s laws

Law

Continuing change

Increasing complexity

Large program evolution

Organisational stability

Conservation of

familiarity

Continuing growth

Declining quality

Description

A program that is used in a real-world environment necessarily

must change or become progressively less useful in that

environment.

As an evolving program changes, its structure tends to become

more complex. Extra resources must be devoted to preserving

and simplifying the structure.

Program evolution is a self-regulating process. System

attributes such as size, time between releases and the number of

reported errors is approximately invariant for each system

release.

Over a programÕs lifetime, its rate of development is

approximately constant and independent of the resources

devoted to system development.

Over the lifetime of a system, the incremental change in each

release is approximately constant.

The functionality offered by systems has to continually increase

to maintain user satisfaction.

The quality of systems will appear to be declining unless they

are adapted to changes in their operational environment.

Feedback system Evolution processes incorporate multi-agent, multi-loop

feedback systems and you have to treat them as feedback

systems to achieve significant product improvement.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 9


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 (Feedback Evolution And Software Technology)

• It is not clear how they should be modified for :

• wrapped software products;

• Systems that incorporate a significant number of COTS

components;

• Small organisations;

• Medium sized systems.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 10


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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 11


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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 12


Types of maintenance




Maintenance to repair software faults

• Changing a system to correct deficiencies in the way

meets its requirements.

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

• Modifying the system to satisfy new requirements.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 13


Types of maintenance





Corrective: maintenance for fault repair

Adaptive: adapting to a new requirements or

a new environment

Perfective: perfecting the sw by

implementing new requirements or

maintaining the system by improving its

structure and its performance

Preventive: activities aimed at increasing

system maintainability

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 14


Distribution of maintenance effort

Fault repair

(17% )

Software

adaptation

(18% )

Functionality

addition or

modification

(65% )

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 15


Maintenance costs





Usually greater than development costs (depending

on the application: business application vs.

embedded real-time systems).

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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 16


Maintenance costs


Cost-effective to invest effort when designing

and implementing a system vs. to add

functionality after delivery (need to

understand the system and analyze the

impact of system change)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 17


Development/maintenance costs

System 1

System 2

0 50 100 150 200 250 300 350 400 450 500

$

D evelopment costs

M aintenance costs

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 18


Maintenance cost factors





Team stability

• Maintenance costs are reduced if the same staff are

involved with them 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.

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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 19


Evolutionary Software


Rather than think of separate development

and maintenance phases, evolutionary

software is software that is designed so that

it can continuously evolve throughout its

lifetime

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 20


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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 21


Maintenance prediction

What parts of the system are

most likely to be affected by

change requests?

Predicting

maintainability

What par ts of the system

will be the most expensive

to maintain?

Predicting system

changes

Predicting

maintenance

costs

What will be the lifetime

maintenance costs of this

system?

How many change

requests can be

expected?

What will be the costs of

maintaining this system

over the next year?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 22


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 in which the system is used.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 23


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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 24


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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 25


Evolution processes



Evolution processes depend on

• The type of software being maintained;

• The development processes used;

• The skills and experience of the people

involved.

Proposals for change are the driver for

system evolution. Change identification and

evolution continue throughout the system

lifetime.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 26


Change identification and evolution

Change identification

process

New system

Change proposals

Software evolution

process

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 27


The system evolution process

Change

requests

Impact

analysis

Release

planning

Change

implementa tion

System

release

Fault repair

Platform

adaptation

S ystem

enhancement

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 28


Change implementation

Proposed

changes

Requirements

analysis

Requirements

upda ting

Software

development

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 29


Urgent change requests


Urgent changes may have to be

implemented without going through all

stages of the software engineering process

• If a serious system fault has to be repaired;

• If changes to the system’s environment (e.g. an

OS upgrade) have unexpected effects;

• If there are business changes that require a

very rapid response (e.g. the release of a

competing product, new legislation).

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 30


Urgent change




It’s usually more important to make the

change quickly than to ensure that the formal

change process is followed

A workable solution rather than the best

solution (future changes become more

difficult)

Emergency fix is mode to the code of the

system to implement the change

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 31


Emergency repair

Change

requests

A nalyse

source code

M odify

sour ce code

D eliver modified

system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 32


Architectural evolution



There is a need to convert many legacy systems

from a centralised architecture to a client-server

architecture

Change drivers

• Hardware costs. Servers are cheaper than mainframes

• User interface expectations. Users expect graphical user

interfaces

• Distributed access to systems. Users wish to access the

system from different, geographically separated,

computers

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 33


Distribution Factors

F a c tor

B u sin ess im p or ta n ce

S ystem a g e

S ystem str u ctu r e

H a r d w a r e p r ocu r em en t

p olicies

D e sc r ip tion

R etu r n s on th e in vestm en t of d istr ibu tin g a leg a cy system d ep en d on its

im p or ta n ce to th e bu sin ess a n d h ow lon g it w ill rem a in im p orta n t. If

d istr ibu tion p r ovid es m or e efficien t su p p ort for sta ble bu sin ess p r ocesses

th en it is m or e lik ely to be a cost-effective evolu tion str a teg y.

T h e old er th e system th e m or e d ifficu lt it w ill be to m od ify its

a r ch itectu r e beca u se p r eviou s ch a n g es w ill h a ve d eg r a d ed th e str u ctu r e

of th e system .

T h e m or e m od u la r th e system , th e ea sier it w ill be to ch a n g e th e

a r ch itectu r e. If th e a p p lica tion log ic, th e d a ta m a n a g em en t a n d th e u ser

in terfa ce of th e system a r e closely in ter tw in ed , it w ill be d ifficu lt to

sep a ra te fu n ction s for m ig r a tion .

A p p lica tion d istr ibu tion m a y be n ecessa r y if th er e is com p a n y p olicy to

r ep la ce ex p en sive m a in fr a m e com p u ter s w ith ch ea p er server s. .

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 34


Legacy systems distribution

D e s k t o p P C c li en ts r u n n in g a p p l ic a t io n

L e g a c y sy st e m

A p p l i ca t io n

s er v ic e s

D a t a b a s e

M i d d le w a r e la y e r ( w r a p p e r )

U s e r i n t e r f a c e

L e g a c y sy st e m

C h ar a c t e r t e r m in a ls

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 35


Migrating difficulties




Not structured systems: components not

easily separated from other components

Services provided and the database not

clearly separated

Individual services not well distinguished

• But

• …user interface facilities, services and data

access are intermingled.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 36


User Interface Distribution




UI distribution takes advantage of the local

processing power on PCs to implement a

graphical user interface

Where there is a clear separation between

the UI and the application then the legacy

system can be modified to distribute the UI

Otherwise, screen management middleware

can translate text interfaces to graphical

interfaces

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 37


UI migration strategies

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 38


Key points


Software change strategies include software

maintenance, architectural evolution and

software re-engineering


Maintenance types are

• Maintenance for repair

• Maintenance for a new operating environment

• Maintenance to implement new requirements

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 39


Key points


The costs of software change usually exceed

the costs of software development


Architectural evolution is concerned with

evolving centralised to distributed

architectures


A distributed user interface can be supported

using screen management middleware

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 40


System re-engineering




Re-structuring or re-writing part or all of a

legacy system without changing its

functionality.

Applicable where some but not all sub-systems

of a larger system require frequent

maintenance.

Re-engineering involves adding effort to make

them easier to maintain. The system may be restructured

and re-documented.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 41


Advantages of reengineering



Reduced risk

• There is a high risk in new software

development. There may be development

problems, staffing problems and specification

problems.

Reduced cost

• The cost of re-engineering is often significantly

less than the costs of developing new software.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 42


Forward and re-engineering

S ystem

specification

D esign and

implementation

New

system

Forward eng ineering

Existing

softw are system

Softw are re-eng ineering

Understanding and

transf ormation

Re-engineered

system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 43


The re-engineering process

Original

program

Program

documentation

M odularised

program

Original data

Reverse

eng ineering

Source code

translation

Program

modularisation

D ata

re-engineering

Prog ram

structure

improvement

Structured

prog ram

Re-engineered

data

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 44


Reengineering process activities






Source code translation

• Convert code to a new language.

Reverse engineering

• Analyse the program to understand it;

Program structure improvement

• Restructure automatically for understandability;

Program modularisation

• Reorganise the program structure;

Data reengineering

• Clean-up and restructure system data.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 45


Re-engineering approaches

Automa ted pr ogram

restructuring

Program and da ta

restructuring

Automa ted sour ce

code con version

Automa ted restructuring

with man ual changes

Restructuring plus

architectur al changes

Increased cost

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 46


Reengineering cost factors





The quality of the software to be

reengineered.

The tool support available for reengineering.

The extent of the data conversion which is

required.

The availability of expert staff for

reengineering.

• This can be a problem with old systems based

on technology that is no longer widely used.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 47


Legacy system evolution



Organisations that rely on legacy systems must

choose a strategy for evolving these systems

• Scrap the system completely and modify business

processes so that it is no longer required;

• Continue maintaining the system;

• Transform the system by re-engineering to improve its

maintainability;

• Replace the system with a new system.

The strategy chosen should depend on the system

quality and its business value.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 48


System quality and business value

High business value

Low quality

High business value

High quality

9

10

6

7

8

Low business value

Low quality

Low business value

High quality

1

2

3 4

5

System quality

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 49


Legacy system categories





Low quality, low business value

• These systems should be scrapped.

Low-quality, high-business value

• These make an important business contribution but are

expensive to maintain. Should be re-engineered or

replaced if a suitable system is available.

High-quality, low-business value

• Replace with COTS, scrap completely or maintain.

High-quality, high business value

• Continue in operation using normal system maintenance.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 50


Business value assessment



Assessment should take different viewpoints

into account

• System end-users;

• Business customers;

• Line managers;

• IT managers;

• Senior managers.

Interview different stakeholders and collate

results.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 51


System quality assessment




Business process assessment

• How well does the business process support the

current goals of the business?

Environment assessment

• How effective is the system’s environment and

how expensive is it to maintain?

Application assessment

• What is the quality of the application software

system?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 52


Business process assessment



Use a viewpoint-oriented approach and seek

answers from system stakeholders

• Is there a defined process model and is it followed?

• Do different parts of the organisation use different

processes for the same function?

• How has the process been adapted?

• What are the relationships with other business processes

and are these necessary?

• Is the process effectively supported by the legacy

application software?

Example - a travel ordering system may have a low

business value because of the widespread use of

web-based ordering.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 53


Environment assessment 1

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 54


Environment assessment 2

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 55


Application assessment 1

Factor

Understandability

Documentation

Questions

How difficult is it to understand the source code of the

current system? How complex are the control structures

that are used? Do variables have meaningful names that

reflect their function?

What system documentation is available? Is the

documentation complete, consistent and up-to-date?

Data Is there an explicit data model for the system? To what

extent is data duplicated in different files? Is the data used

by the system up-to-date and consistent?

Performance

Is the performance of the application adequate? Do

performance problems have a significant effect on system

users?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 56


Application assessment 2

Programming

language

Configuration

management

Test data

Personnel skills

Are modern compilers available for the programming

language used to develop the system? Is the programming

language still used for new system development?

Are all versions of all parts of the system managed by a

configuration management system? Is there an explicit

description of the versions of components that are used in

the current system?

Does test data for the system exist? Is there a record of

regression tests carried out when new features have been

added to the system?

Are there people available who have the skills to maintain

the application? Are there only a limit ed number of people

who understand the system?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 57


System measurement


You may collect quantitative data to make an

assessment of the quality of the application

system

• The number of system change requests;

• The number of different user interfaces used by

the system;

• The volume of data used by the system.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 58


Key points





Software development and evolution should

be a single iterative process.

Lehman’s Laws describe a number of

insights into system evolution.

Three types of maintenance are bug fixing,

modifying software for a new environment

and implementing new requirements.

For custom systems, maintenance costs

usually exceed development costs.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 59


Key points




The process of evolution is driven by requests

for changes from system stakeholders.

Software re-engineering is concerned with restructuring

and re-documenting software to

make it easier to change.

The business value of a legacy system and its

quality should determine the evolution strategy

that is used.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 60

More magazines by this user
Similar magazines