1 the laws of software evolution tori bowman csse 375, rose-hulman september 25, 2007 *based on don...

1

The Laws of Software EvolutionThe Laws of Software Evolution

Tori BowmanTori BowmanCSSE 375, Rose-HulmanCSSE 375, Rose-Hulman

September 25, 2007September 25, 2007

*based on Don Bagert’s lesson*based on Don Bagert’s lesson

State of 375State of 375

What’s due?What’s due? Thursday: Status report (documents due Thursday: Status report (documents due

Wednesday)Wednesday) Friday: Project help (testing & Friday: Project help (testing &

packaging)packaging) ThisThis Legal discussion: F/OSSLegal discussion: F/OSS

2

3

ReferencesReferences

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

4

OutlineOutline

BackgroundBackground The Laws of Software EvolutionThe Laws of Software Evolution Why does Lehman call them “Laws”?Why does Lehman call them “Laws”? FEAST – A feedback system for software FEAST – A feedback system for software

evolutionevolution

5

Background – 1/2Background – 1/2

Relate primarily to perfective changeRelate primarily to perfective change Developed by M.M. LehmanDeveloped by M.M. Lehman The Laws themselves have “evolved”, The Laws themselves have “evolved”,

from three in 1968 to eight by 1997from three in 1968 to eight by 1997 Have been empirically demonstrated Have been empirically demonstrated

for at least two systems:for at least two systems: OS/360 (IBM mainframe OS in the 1960’s)OS/360 (IBM mainframe OS in the 1960’s) Logica FW (a financial transaction system)Logica FW (a financial transaction system)

6

Background – 2/2Background – 2/2

Is largely based on the concept of Is largely based on the concept of the existence of positive and the existence of positive and negative negative feedback systems feedback systems existing existing in the software environmentin the software environment

Examples of feedback systems:Examples of feedback systems: UsersUsers ManagementManagement DevelopersDevelopers GovernmentGovernment

DefinitionsDefinitions

S-type softwareS-type software Definition:Definition: those those

addressing a problem addressing a problem with a computational with a computational solution in an abstract solution in an abstract and closed, for example and closed, for example mathematical, domainmathematical, domain

Example:Example: floating point floating point package may be judged package may be judged correct versus the IEEE correct versus the IEEE standard for floating standard for floating pointpoint

E-type softwareE-type software DefinitionDefinition: produced : produced

because it satisfies because it satisfies some real world need some real world need and so is forced to and so is forced to evolve as the reality evolve as the reality changeschanges

ExampleExample: embedded : embedded code must fit the code must fit the hardware it is placed in hardware it is placed in and must change if the and must change if the hardware is changed – hardware is changed – majority of SW is heremajority of SW is here

7

8


I - Continuing Change: An E-type (evolutionary I - Continuing Change: An E-type (evolutionary type) program that is used must be continually type) program that is used must be continually adapted else it becomes progressively less adapted else it becomes progressively less satisfactory.satisfactory.

This is due in part to the fact that the software This is due in part to the fact that the software never exactly matches the desired operational never exactly matches the desired operational domain (the “Software Uncertainty Principle”).domain (the “Software Uncertainty Principle”).

9


II – Increasing Complexity: As a program is evolved II – Increasing Complexity: As a program is evolved its complexity increases unless work is done to its complexity increases unless work is done to maintain or reduce it.maintain or reduce it.

Related to the Second Law of Thermodynamics: “Related to the Second Law of Thermodynamics: “In all In all energy exchanges, if no energy enters or leaves the energy exchanges, if no energy enters or leaves the system, the potential energy of the state will always be system, the potential energy of the state will always be less than that of the initial state."less than that of the initial state." This is also commonly This is also commonly referred to as referred to as entropyentropy..

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

10


III – Self Regulation: The program evolution process III – Self Regulation: The program evolution process is self regulating with close to normal distribution of is self regulating with close to normal distribution of measures of product and process attributes.measures of product and process attributes.

From Lehman’s paper: From Lehman’s paper: “Checks and balances will “Checks and balances will have been established by…management to ensure have been established by…management to ensure that operational rules are followed and that operational rules are followed and organizational goals…are met…[This is] one organizational goals…are met…[This is] one example of feedback driven growth and example of feedback driven growth and stabilization mechanisms…[They] establish a stabilization mechanisms…[They] establish a disciplined dynamics whose parameters are, in least disciplined dynamics whose parameters are, in least in part normally distributed.” in part normally distributed.”

11


IV – Conservation of Organizational Stability IV – Conservation of Organizational Stability (invariant work rate): The average effective global (invariant work rate): The average effective global activity rate [total effort expended] on an evolving activity rate [total effort expended] on an evolving system is invariant over the product lifetime.system is invariant over the product lifetime.

This law on the face of it doesn’t make sense. This law on the face of it doesn’t make sense. However, various forces are at work that often However, various forces are at work that often counteracts attempts to increase productivity e.g. counteracts attempts to increase productivity e.g. management increasing the number of people on a management increasing the number of people on a project increases communication overhead. (This project increases communication overhead. (This was first described in was first described in The Mythical Man-Month The Mythical Man-Month by by Fred Brooks.)Fred Brooks.)

12


V – Conservation of Familiarity: During the active V – Conservation of Familiarity: During the active life of an evolving program, the content of life of an evolving program, the content of successive releases is statistically invariant.successive releases is statistically invariant.

From Lehman’s paper: From Lehman’s paper: “One of the factors that “One of the factors that determines the progress of a software development determines the progress of a software development is the familiarity of all involved with its goals. The is the familiarity of all involved with its goals. The more changes & additions [in a] particular release, more changes & additions [in a] particular release, the more difficult is for all concerned to be aware, the more difficult is for all concerned to be aware, to understand and to appreciate what is required of to understand and to appreciate what is required of them…The larger the work package the more them…The larger the work package the more challenging mastery of the matter to be acquired.”challenging mastery of the matter to be acquired.”

13


VI – Continuing Growth: Functional content of VI – Continuing Growth: Functional content of a program must be continually increased to a program must be continually increased to maintain user satisfaction over its lifetime.maintain user satisfaction over its lifetime.

This is not the same as the first law, which This is not the same as the first law, which refers to the fact that software never exactly refers to the fact that software never exactly matches its operational domain. For the matches its operational domain. For the sixth law, the reason is that various factors sixth law, the reason is that various factors mean that user demands for more mean that user demands for more functionality will increase over time, and functionality will increase over time, and thus the functional content must also thus the functional content must also increase.increase.

14


VII – Declining Quality: E-type programs will VII – Declining Quality: E-type programs will be perceived as of declining quality unless be perceived as of declining quality unless rigorously maintained and adapted to a rigorously maintained and adapted to a changing operational environment.changing operational environment.

Otherwise, the system is perceived as older Otherwise, the system is perceived as older and less useful.and less useful.

15


VIII – Feedback System: E-type programming VIII – Feedback System: E-type programming processes constitute multi-loop, multi-level processes constitute multi-loop, multi-level feedback systems and must be treated as feedback systems and must be treated as such to be successfully improved.such to be successfully improved.

Multi-loop means that it is an iterative Multi-loop means that it is an iterative process and multi-level refers to the fact that process and multi-level refers to the fact that it occurs in more than one aspect of the it occurs in more than one aspect of the software and its documentation.software and its documentation.

16

Why does Lehman call them “Laws”? - 1/2Why does Lehman call them “Laws”? - 1/2

From his paper:From his paper: Observed phenomena reflected the behavior of human Observed phenomena reflected the behavior of human

designers, implementers, managers and users. Thus designers, implementers, managers and users. Thus they could not be laws in the normal sense of the wordthey could not be laws in the normal sense of the word

Phenomenology they reflect could be altered at will, by Phenomenology they reflect could be altered at will, by education for example. education for example.

Behavior described was intimately bound up with a Behavior described was intimately bound up with a particular organization and/or a particular [operating] particular organization and/or a particular [operating] system…system…

As such the observed phenomena lacked the generality As such the observed phenomena lacked the generality that use of the term that use of the term law law implies…implies…

17

Why does Lehman call them “Laws”? - 2/2Why does Lehman call them “Laws”? - 2/2

From his paper (continued):From his paper (continued): Laws reflect the cooperative activity of many individual Laws reflect the cooperative activity of many individual

and organizational behavior. and organizational behavior. Their analysis requires: experience in disciplines Their analysis requires: experience in disciplines

removed from computer science and software removed from computer science and software engineering, psychology, organizational theory and engineering, psychology, organizational theory and management science management science

Observed behavior reflects the environment within Observed behavior reflects the environment within which software engineering operates and the laws which software engineering operates and the laws governing that behavior are not part of that discipline. governing that behavior are not part of that discipline.

““From the point of view of software engineering they From the point of view of software engineering they must be accepted as laws…”must be accepted as laws…”

18

FEAST – FEAST – A feedback system for software evolution 1/3A feedback system for software evolution 1/3

FEAST stands for FEAST stands for FFeedback, eedback, EEvolution volution AAnd nd SSoftware oftware TTechnology.echnology.

It seeks to investigate the role and It seeks to investigate the role and influence of feedback in the evolution influence of feedback in the evolution of of EE-type software systems and on -type software systems and on the improvement of the software the improvement of the software process process

19


HypothesisHypothesisAs complex feedback systems As complex feedback systems EE-type software -type software processes evolve strong system dynamics and processes evolve strong system dynamics and the global stability tendency of other feedback the global stability tendency of other feedback systemssystems

Supporting observationSupporting observationProcesses adopted, applied and improved in Processes adopted, applied and improved in industry, will naturally evolve positive feedback to industry, will naturally evolve positive feedback to drive organisational growth and negative drive organisational growth and negative feedback controls - checks and balancesfeedback controls - checks and balances

20


Preliminary ResultsPreliminary Results Were for one particular systemWere for one particular system Suggest that the system dynamics is so Suggest that the system dynamics is so

strong that its parameters are fixed strong that its parameters are fixed quite early in the life cycle of the quite early in the life cycle of the evolving systemevolving system

There has been further work since There has been further work since thenthenhttp://www.doc.ic.ac.uk/~mml/feast2/papers.html

1 the laws of software evolution tori bowman csse 375, rose-hulman september 25, 2007 *based on don...

Documents