1

SE351-Software Construction and

development

Semester 5
 2
Outline

 Software Evolution
 Background
 Lehman’s Laws of Software Evolution
 Why does Lehman call them “Laws”?
 FEAST – A feedback system for software evolution
 3
What is Software evolution?

 Software evolution used in software engneering refers to the process of

developing software initially, then repeatedly updating it for various reasons.
 As with the passange of time the technology is evolving, the laws required to develope and
maintin a software also need to be created and justified.
 4
Background – 1/2

 Relate primarily to perfective change

 Developed by M.M. Lehman
 The Laws themselves have “evolved”, from three in 1968 to eight by 1997
 Have been empirically demonstrated for at least two systems:
 OS/360 (IBM mainframe OS in the 1960’s)
 Logica FW (a financial transaction system)
 5
Background – 2/2

 Is largely based on the concept of the existence of positive and negative feedback systems
existing in the software environment
 Examples of feedback systems:
 Users
 Management
 Developers
 Government
 6
Definitions

P-type software
 Definition: P-type systems might actually have a specification in terms of what
a 100% correct solution would be. There might even be a way of theoretically
reaching that perfect solution, but in practice it would be utterly infeasible to
actually implement that solution.
 So a good example of such a system would for example be chess if you want to
develop an algorithm that plays chess perfectly. It is theoretically possible to
construct the perfect solution, but in practice if you would run that solution the
combinatorial complexity is way too high. So it is intractable.

Definitions
S-type software
 Definition: those addressing a
problem with a computational
solution in an abstract and closed, for
example mathematical, domain
 Example: floating point package may
be judged correct versus the IEEE
standard for floating point
6
E-type software
 Definition: produced because it
satisfies some real world need and so
is forced to evolve as the reality
changes
 Example: embedded code must fit the
hardware it is placed in and must
change if the hardware is changed –
majority of SW is here
 7
The Lehman’s Laws of Software Evolution

 Continuing Change: An E-type (evolutionary type) program that is used must be

continually adapted else it becomes progressively less satisfactory.
 This is due in part to the fact that the software never exactly matches the desired operational
domain (the “Software Uncertainty Principle”).
 8
The Lehman’s Laws of Software Evolution

 Increasing Complexity: As a program is evolved its complexity increases unless work is

done to maintain or reduce it.

 This law exists because as the E-type software is adapted to the changing operational
environment, there is not only an increasing number of interactions, but an increasing number of
interactions that were adds-on to the original design of the system. If effort is expended to
combat this (through re-engineering and other techniques) this means less effort for new
functionality.
 9
The Lehman’s Laws of Software Evolution

 Self Regulation: The program evolution process is self regulating with close to normal
distribution of measures of product and process attributes.
 From Lehman’s paper: “Checks and balances will have been established by…management to
ensure that operational rules are followed and organizational goals…are met…[This is] one
example of feedback driven growth and stabilization mechanisms…[They] establish a
disciplined dynamics whose parameters are, in least in part normally distributed.”
 11
The Lehman’s Laws of Software Evolution

 Conservation of Organizational Stability (invariant work rate): The average effective

global activity rate [total effort expended] on an evolving system is invariant over the
product lifetime.
 This law on the face of it doesn’t make sense. However, various forces are at work that often
counteracts attempts to increase productivity e.g. management increasing the number of people
on a project increases communication overhead. (This was first described in The Mythical Man-
Month by Fred Brooks.)
 12
The Lehman’s Laws of Software Evolution

 Conservation of Familiarity: During the active life of an evolving program, the content of
successive releases is statistically invariant.
 From Lehman’s paper: “One of the factors that determines the progress of a software
development is the familiarity of all involved with its goals. The more changes & additions [in
a] particular release, the more difficult is for all concerned to be aware, to understand and to
appreciate what is required of them…The larger the work package the more challenging mastery
of the matter to be acquired.”
 13
The Lehman’s Laws of Software Evolution

 Continuing Growth: Functional content of a program must be continually increased to

maintain user satisfaction over its lifetime.
 This is not the same as the first law, which refers to the fact that software never exactly matches
its operational domain. For the sixth law, the reason is that various factors mean that user
demands for more functionality will increase over time, and thus the functional content must also
increase.
 14
The Lehman’s Laws of Software Evolution

 Declining Quality: E-type programs will be perceived as of declining quality unless

rigorously maintained and adapted to a changing operational environment.
 Otherwise, the system is perceived as older and less useful.
 15
The Lehman’s Laws of Software Evolution

 Feedback System: E-type programming processes constitute multi-loop, multi-level

feedback systems and must be treated as such to be successfully improved.
 Multi-loop means that it is an iterative process and multi-level refers to the fact that it occurs in
more than one aspect of the software and its documentation.
 16
Why does Lehman call them “Laws”? - 1/2

 From his paper:

 Observed phenomena reflected the behavior of human designers,
implementers, managers and users. Thus they could not be laws in the
normal sense of the word
 Phenomenology they reflect could be altered at will, by education for
example.
 Behavior described was intimately bound up with a particular organization
and/or a particular [operating] system…
 As such the observed phenomena lacked the generality that use of the term
law implies…
 17
Why does Lehman call them “Laws”? - 2/2

 From his paper (continued):

 Laws reflect the cooperative activity of many individual and organizational
behavior.
 Their analysis requires: experience in disciplines removed from computer
science and software engineering, psychology, organizational theory and
management science
 Observed behavior reflects the environment within which software engineering
operates and the laws governing that behavior are not part of that discipline.

 “From the point of view of software engineering they must be accepted as

laws…”
 18
FEAST –
A feedback system for software evolution 1/3

 FEAST stands for Feedback, Evolution And Software Technology.

 It seeks to investigate the role and influence of feedback in the evolution of E-type
software systems and on the improvement of the software process
 19
FEAST –
A feedback system for software evolution 2/3

 Hypothesis As complex feedback systems E-type software processes evolve strong system
dynamics and the global stability tendency of other feedback systems
 Supporting observation
Processes adopted, applied and improved in industry, will naturally evolve positive feedback to
drive organizational growth and negative feedback controls - checks and balances.
 20
FEAST –
A feedback system for software evolution 3/3

 Preliminary Results
 Were for one particular system
 Suggest that the system dynamics is so strong that its parameters are fixed quite early in the life
cycle of the evolving system
Reference

 Metrics and laws of software evolution-the nineties view by MM lehman (a paper)