Lec03 Fundamentals of Sfw Chg 1

Objectives
Discuss different types of software change and give
reasons why changes occur.
Show how on-going support, as well as software
change, can be classified as a maintenance activity.
Explain the tendency of software systems to evolve.
Introduce important areas of background theory via a
discussion of Lehman’s Laws.

Lec03 Fundamentals of Sfw Chg 2

The tendency to change is
necessary to optimally adjust to
environmental requirements
[Damste, 74]

Lec03 Fundamentals of Sfw Chg 3

Definitions
Adaptive change
A change made in order to become suited to different
conditions.
Corrective change
A change made in order to remove faults.
E-type system
A system in which the criteria for acceptability is that
stakeholders are satisfied with the system in terms of its
performance in a real world situation.
Perfective change
A change made in order to improve

Lec03 Fundamentals of Sfw Chg 4

Definitions
Post-delivery evolution
 Software revolution referring explicitly to the period after
the product is delivered to the customer.
Preventive change
 A change made in order to forestall or reverse deterioration.
Ripple effect
 Consequences of an action in one place, occurring elsewhere,
e.g. a stone dropped in a pond resulting in waves/ripples far
from the point of impact.
S-type system
 A system in which the criteria for acceptability is that it is
correct relative to an absolute specification.
Lec03 Fundamentals of Sfw Chg 5
Software Change
Corrective
Adaptive
Perfective
Preventive

Lec03 Fundamentals of Sfw Chg 6

Corrective Change
Refers to modification initiated by defects in the software.
Defects can result from
 Design errors occur when, for e.g., changes made to the
software are incorrect, incomplete, wrongly communicated
or the change request is misunderstood.
 Logic errors result from invalid tests and conclusion,
incorrect implementation of design specifications, faulty
logic flow or incomplete testing of data.
 Coding errors are caused by incorrect implementation of
detailed logic design and incorrect use of the source code
logic. Defects are also caused by data processing errors and
system performance errors.

Lec03 Fundamentals of Sfw Chg 7

Adaptive Change
A change driven by the need to accommodate
modifications in the environment of the software
system.
The term environment in this context refers to the
totality of all conditions and influences which act from
outside upon the system, for e.g. business rules,
government policies, work patterns, software and
hardware operating platforms.
A change to the whole or part of this environment will
warrant a corresponding modification of the software.

Lec03 Fundamentals of Sfw Chg 8

Perfective Change
Changes undertaken to expand the existing
requirements of a system.
A successful piece of software tends to be subjected to a
succession of changes resulting in an increase in its
requirements.
Expansion in requirements can take the form of
enhancement of existing system functionality or
improvement in computational efficiency. For e.g.
providing a MIS(Management Information System) with
a data entry module or a new message handling facility.

Lec03 Fundamentals of Sfw Chg 9

Diagram of a basic system, S
Module 1

S
Output 1
Y
S
Module 2
T
E
M

Module 3
Output 2

Lec03 Fundamentals of Sfw Chg 10

Diagram of an enhance system, S’
Module 1
Module 2

Module 3 S Output 1
Y
S Output 2
T Output 3
E
M

Output m-1
Module n-1
Output m
Module n

Lec03 Fundamentals of Sfw Chg 11

Preventive Change
The long term effect of corrective, adaptive and
perfective changes is expressed in Lehman’s law of
increasing entropy.
Work done on a software system to address problems
of deteriorating structure is known as preventive
change.
To prevent malfunctions or to improve
maintainability of the software.
E.g. code restructuring, code optimisation and
documentation updating.
Lec03 Fundamentals of Sfw Chg 12
Preventive Change
Unforeseen ripple effects imply that a change to one
part of a program may affect other sections in an
unpredictable fashion, thereby leading to a distortion
in the logic of the system.
This is due to the lack of time to carry out a thorough
impact analysis before effecting a change.
Program slicing techniques and concepts such as
modularization and information hiding can be used
to address these problems.

Lec03 Fundamentals of Sfw Chg 13

The Importance of Categorizing
Software Changes
In principle, software maintenance activities can be
classified individually. In practice, they are usually
intertwined.
E.g. In the course of modifying a program due to the
introduction of a new operating system (adaptive change),
obscure bugs may be introduced. The bugs have to be
traced and dealt with (corrective maintenance). Similarly,
the introduction of a more efficient sorting algorithm into
a data processing package (perfective maintenance) may
require that the existing program code be restructured
(preventive maintenance).

Lec03 Fundamentals of Sfw Chg 14

Lec03 Fundamentals of Sfw Chg 15
Incremental Release
The changes made to a software product are not
always done all together. The changes take place
incrementally, with minor changes usually
implemented while a system is in operation.
With bespoke software, change can often be effected
as the need for it arises.
For off-the-shelf packages, users normally have to
wait for the next upgrade.

Lec03 Fundamentals of Sfw Chg 16

Incremental product release

Release 1 Release 2 Release 3 Release N

Opportunity to introduce change

Lec03 Fundamentals of Sfw Chg 17

Ongoing support
Effective communication
Training of end-users
Providing business information

Lec03 Fundamentals of Sfw Chg 18

Lehman’s Eight Laws of Software
Evolution
Law of continuing change (1974)
Systems must be continually adapted or they become
progressively less satisfactory to use. This law says that
systems evolve in a way comparable with biological
organisms. The difference is that it is the variance
between the system and its operational context that
leads to feedback pressures forcing change in the
system.

Lec03 Fundamentals of Sfw Chg 19

Lehman’s Eight Laws of Software
Evolution
Law of increasing complexity (1974)
As a system evolves, its complexity increases unless
work is done to maintain or reduce it. If changes are
made with no thought to system structure, complexity
will increase and make future change harder. If
resource is expended on work to combat complexity,
less is available for system change. No matter how this
balance is reconciled, the rate of system growth
inevitably slows.

Lec03 Fundamentals of Sfw Chg 20

Lehman’s Eight Laws of Software
Evolution
Law of self-regulation (1974)
Evolutionary aspects of system evolution processes
tend to display a degree of statistical regularity.
Industrially produced E-type software is implemented
within the context of a wider organization. Thus the
objective of getting the system finished is constrained
by the wider objectives and constraints of
organizational goals at all levels. Positive and negative
feedback controls within this wider context ultimately
determine the way the system evolves.

Lec03 Fundamentals of Sfw Chg 21

Lehman’s Eight Laws of Software
Evolution
Law of conservation of organizational stability (1978)
The average work rate in an E-type process tends to
remain constant over periods of system evolution. This
is counter-intuitive as one tends to assume that
management decision-making will determine the effort
expended on system change. However, analyses to date
suggest that the many inputs to satisfactory system
change combine to give an essentially constant work
rate.

Lec03 Fundamentals of Sfw Chg 22

Lehman’s Eight Laws of Software
Evolution
Law of conservation of familiarity (1978)
The average incremental growth of systems tends to
remain constant or decline. The more changes that are
required means it is harder for those involved to get to
grips with all that is required of them. This affects the
quality and progress of the change.

Lec03 Fundamentals of Sfw Chg 23

Lehman’s Eight Laws of Software
Evolution
Law of continuing growth (1991)
Functional capability must be continually increased
over a system’s lifetime to maintain user satisfaction.
This is closely related to the first law. In any system
implementation, requirements have to be constrained.
Attributes will be omitted. These will become the
irritants that trigger future demand for change. Thus,
E-type system growth is driven by feedback from its
users.

Lec03 Fundamentals of Sfw Chg 24

Lehman’s Eight Laws of Software
Evolution
Law of declining quality (1996)
Unless rigorously adapted to meet changes in the
operational environment, system quality will appear to
decline. A system is built on a set of assumptions, and
however valid these are at the time, the changing world
will tend to invalidate them. Unless steps are taken to
identify and rectify this, system quality will appear to
decline especially in relation to alternative products
that will come onto the market based on more recently
formulated assumptions.

Lec03 Fundamentals of Sfw Chg 25

Lehman’s Eight Laws of Software
Evolution
Law of feedback systems (1996)
Evolution processes are multi-level, multi-loop, multi-
agent feedback systems. Feedback plays a role in all the
laws. Studies in the 1970’s showed self-stabilizing
feedback system behavior. The process leads to an
organization and a process dominated by feedback.

Lec03 Fundamentals of Sfw Chg 26