The Laws of Software Evolution

1
The Laws of Software Evolution

• Tori Bowman
• CSSE 375, Rose-Hulman
• September 25, 2007
• based on Don Bagerts lesson

2
State of 375

• Whats due?
• Thursday Status report (documents due Wednesday)
• Friday Project help (testing packaging)
• This
• Legal discussion F/OSS

3
References

• The Laws of Software Evolution Revisited by M. M.
  Lehman, 21 January 1997

4
Outline

• Background
• The Laws of Software Evolution
• Why does Lehman call them Laws?
• FEAST A feedback system for software evolution

5
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 1960s)
• Logica FW (a financial transaction system)

6
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

7
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

• 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

8
The Laws of Software Evolution

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

9
The Laws of Software Evolution

• II Increasing Complexity As a program is
  evolved its complexity increases unless work is
  done to maintain or reduce it.
• Related to the Second Law of Thermodynamics In
  all energy exchanges, if no energy enters or
  leaves the system, the potential energy of the
  state will always be less than that of the
  initial state." This is also commonly referred to
  as entropy.
• 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.

10
The Laws of Software Evolution

• III Self Regulation The program evolution
  process is self regulating with close to normal
  distribution of measures of product and process
  attributes.
• From Lehmans paper Checks and balances will
  have been established bymanagement to ensure
  that operational rules are followed and
  organizational goalsare metThis is one
  example of feedback driven growth and
  stabilization mechanismsThey establish a
  disciplined dynamics whose parameters are, in
  least in part normally distributed.

11
The Laws of Software Evolution

• IV 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 doesnt 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 Laws of Software Evolution

• V Conservation of Familiarity During the
  active life of an evolving program, the content
  of successive releases is statistically
  invariant.
• From Lehmans 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 themThe larger
  the work package the more challenging mastery of
  the matter to be acquired.

13
The Laws of Software Evolution

• VI 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 Laws of Software Evolution

• VII 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 Laws of Software Evolution

• VIII 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 organisational 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
• There has been further work since then
• http//www.doc.ic.ac.uk/mml/feast2/papers.html