Software Evolution

1
Review {Testing}

 Validation & Verification

 Inspection & Testing
 Stages of Testing
 Development Testing: Unit, Component and System Testing
 Release Testing: Requirements testing, Performance Testing
 User Testing: Alpha, Beta and Acceptance Testing
 Test Driven Development

2
3
Evolution

Windows 3.11 Windows 98 Windows XP

Windows 10 4
Software change

 Software change is inevitable

 New requirements emerge when the software is used;
 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.
 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 changed if they are to remain useful in an environment.
 A key problem for all organizations is implementing and managing change to
their existing software systems.

5
O
r
g Importance of evolution
a
n
i
z
a
t
i
o
n
s

h
a
v
e

h 6
u
A spiral model of development and evolution

7
Stages of Software

8
Stages of Software

 Evolution
 The stage in a software system’s life cycle where it is in operational use and is evolving
as new requirements are proposed and implemented in the system.
 Servicing
 At this stage, the software remains useful but the only changes made are those required
to keep it operational i.e. bug fixes and changes to reflect changes in the software’s
environment. No new functionality is added.
 Phase-out
 The software may still be used but no further changes are made to it.

9
S
o
f Evolution processes
t
w
a
r
e

e
v
o
l
u
t
i
o
n 10
Change identification and evolution processes

11
The software evolution process

12
Change implementation

13
Change implementation

 Iteration of the development process where the revisions to the system are
designed, implemented and tested.
 The first stage of change implementation may involve program
understanding, especially if the original system developers are not
responsible for the change implementation.
 During the program understanding phase, you have to understand how the
program is structured, how it delivers functionality and how the proposed
change might affect the program.

14
U
r
g Urgent change requests
e
n
t

c
h
a
n
g
e
s

m
a
y 15
The emergency repair process

16
Agile methods and evolution

 Agile methods are based on incremental development so the transition from

development to evolution is a seamless one.
 Evolution is simply a continuation of the development process based on frequent system
releases.
 Changes may be expressed as additional user stories.

17
P
r
o Program evolution dynamics
g
r
a
m

e
v
o
l
u
t
i
o
n

d
y 18
n
 Lehman’s laws
Law Description

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

Continuing change change, or else become progressively less useful in that environment.

As an evolving program changes, its structure tends to become more

Increasing complexity complex. Extra resources must be devoted to preserving and simplifying the
structure.

Program evolution is a self-regulating process. System attributes such as

Large program evolution size, time between releases, and the number of reported errors is
approximately invariant for each system release.

Organizational stability Over a program’s lifetime, its rate of development is approximately constant
and independent of the resources devoted to system development.

19
Lehman’s laws
Law Description

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

Conservation of familiarity
release is approximately constant.

The functionality offered by systems has to continually increase to

Continuing growth
maintain user satisfaction.

Declining quality The quality of systems will decline unless they are modified to
reflect changes in their operational environment.

Evolution processes incorporate multi-agent, multi-loop feedback

Feedback system systems and you have to treat them as feedback systems to
achieve significant product improvement.

20
M
o
d Software maintenance
i
f
y
i
n
g

p
r
o
g
r
a 21
m
M
a
i Types of maintenance
n
t
e
n
a
n
c
e

t
o

r
e
p 22
a
U
s
u Maintenance costs
a
l
l
y

g
r
e
a
t
e
r

t
h 23
a
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.

24
R
e
- System re-engineering
s
t
r
u
c
t
u
r
i
n
g

o
r
25
r
R
e
d Advantages of reengineering
u
c
e
d

r
i
s
k
 T
h
e
r
e

i 26
s
S
o
u Reengineering process activities
r
c
e

c
o
d
e

t
r
a
n
s
l 27
a
T
h
e Reengineering cost factors

q
u
a
l
i
t
y

o
f

t
h
e

s 28
o
Preventative maintenance by refactoring

 Refactoring is the process of making improvements to a program to slow

down degradation through change.
 You can think of refactoring as ‘preventative maintenance’ that reduces the
problems of future change.
 Refactoring involves modifying a program to improve its structure, reduce its
complexity or make it easier to understand.
 When you refactor a program, you should not add functionality but rather
concentrate on program improvement.

29
Refactoring and reengineering

 Re-engineering takes place after a system has been maintained for some
time and maintenance costs are increasing.
 Refactoring is a continuous process of improvement throughout the
development and evolution process. It is intended to avoid the structure and
code degradation that increases the costs and difficulties of maintaining a
system.

30
O
r
g Legacy system management
a
n
i
s
a
t
i
o
n
s

t
h
a
t 31
L
o
w Legacy system categories

q
u
a
l
i
t
y
,

l
o
w

b 32
u
A
s
s Business value assessment
e
s
s
m
e
n
t

s
h
o
u
l
d
33
t
Issues in business value assessment

 The use of the system

 If systems are only used occasionally or by a small number of people, they may have a
low business value.
 The business processes that are supported
 A system may have a low business value if it forces the use of inefficient business
processes.
 System dependability
 If a system is not dependable and the problems directly affect business customers, the
system has a low business value.
 The system outputs
 If the business depends on system outputs, then the system has a high business value.

34
B
u
s System quality assessment
i
n
e
s
s

p
r
o
c
e
s
s

a 35
s