Lehman's laws of software evolution
||The topic of this article may not meet Wikipedia's general notability guideline. (October 2008)|
In Software engineering, the Laws of Software Evolution refer to a series of laws that Lehman and Belady formulated starting in 1974 with respect to Software evolution. The laws describe a balance between forces driving new developments on one hand, and forces that slow down progress on the other hand.
Observing that most software is subject to change in the course of its existence, the authors set out to determine laws that these changes will typically obey, or must obey in order for the software to survive.
In his 1980 article, Lehman qualified the application of such laws by distinguishing between three categories of software:
- S-programs are written according to an exact specification of what the program can do
- P-programs are written to implement certain procedures that completely determine what the program can do (the example mentioned is a program to play chess)
- E-programs are written to perform some real-world activity; how they should behave is strongly linked to the environment in which they run, and these programs need to adapt to varying requirements and circumstances in that environment
The laws are said to apply only to the last category of systems.
All told eight laws were formulated:
- (1974) Continuing Change — E-type systems must be continually adapted or they become progressively less satisfactory.
- (1974) Increasing Complexity — As an E-type system evolves its complexity increases unless work is done to maintain or reduce it.
- (1974) Self Regulation — E-type system evolution process is self-regulating with distribution of product and process measures close to normal.
- (1978) Conservation of Organisational Stability (invariant work rate) - The average effective global activity rate in an evolving E-type system is invariant over product lifetime.
- (1978) Conservation of Familiarity — As an E-type system evolves all associated with it, developers, sales personnel, users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves.
- (1991) Continuing Growth — The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime.
- (1996) Declining Quality — The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes.
- (1996) Feedback System (first stated 1974, formalised as law 1996) — E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.
- Lehman, Meir M. (1980). "Programs, Life Cycles, and Laws of Software Evolution". Proc. IEEE 68 (9): 1060–1076.
- Lehman, M. M.; J. F. Ramil, P. D. Wernick, D. E. Perry, and W. M. Turski (1997). "Metrics and laws of software evolution—the nineties view". Proc. 4th International Software Metrics Symposium (METRICS '97). pp. 20–32. doi:10.1109/METRIC.1997.637156.
- Lehman, M. M. (1980). "On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle". Journal of Systems and Software 1: 213–221. doi:10.1016/0164-1212(79)90022-0.