1. Software Evolution – part 2
CSEM01 SE Evolution & Management Anne Comer Helen Edwards

2. Topics covered Software Evolution Strategies E-, and S-type Software
Lehman’s ‘Laws’
Further Research

3. Objectives
To explain analysis of the evolution, the change, of software systems
Software maintenance
Software re-engineering
To define E- and S-type software
To contextualise, present, and explain Lehman’s ‘Laws’

4. Software Evolution
Software evolution is the study of the phenomena of system change
After major empirical study, Lehman and Belady proposed that there were a number of ‘laws’ which applied to all systems as they evolved
Rather than laws, it is more sensible to say ‘observations’. They are applicable to large systems developed by large organisations

5. Evolution / Maintenance
Evolving, E-type, software should be designed and developed by a recorded process so that it can manageably evolve throughout its lifetime
Software evolution is inevitable
New requirements emerge when the software is used
The application domain modifies
Errors must be repaired
New functionality must be accommodated
Performance and/or reliability may have to be improved
Software evolution is inevitable
The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements!
Systems are tightly coupled with their environment. When a system is installed in an environment it changes that environment and therefore changes the system requirements.
Systems MUST be maintained therefore if they are to remain useful in an environment

6. Software evolution strategies
Software maintenance
Adaptive, Corrective, Perfective, Preventative
Software re-engineering
No new functionality is added to the system but it is restructured and reorganised to facilitate future changes
Maintenance and re-engineering may be applied separately or together
Maintenance
Modifying a program after it has been put into use
Maintenance does not normally involve major changes to the system’s architecture
Changes are implemented by modifying existing components and adding new components to the system

7. Lehman’s ‘laws’ - background
The following ‘laws’ emerged over period of 25 years.
The laws seek to describe the phenomena in software evolution process/product.
The laws are not independent – they are not linearly ordered
Initial (3) laws came out of the IBM OS/360 evolution study; further support for them came from an ICL study.
Support for (6 of) the laws has come from collaborators (ICL, Logica, Matra BAe Dynamics – FEAST/1 project)
The remaining two “reflect a basic truth whose precise nature still needs clarification”

8. E- and S-type Software
E-type software is a solution to real-world problem, used and embedded in a real-world domain. It is judged as satisfactory by its functionality, quality factors (usability, etc.), performance, changeability, and so on.
S-type software has the sole criterion of being mathematically correct with respect to a fixed and constant specification.

9. Lehman’s ‘laws’ (i – iv)
1974
Continuing Change
E-type systems must be continually adapted else they become progressively less satisfactory in use
II 1974
Increasing Complexity
As an E-type system is evolved its complexity increases unless work is done to maintain or reduce it.
III 1974
Self Regulation
Global E-type system evolution processes are self-regulating. [System attributes such as size, time between releases and the number of reported errors are approximately invariant for each system release.] IV
1978
Conservation of Organisational Stability
Unless feedback mechanisms are appropriately adjusted, average effective global activity rate in an evolving E-type system tends to remain constant over product lifetime.

10. Lehman’s ‘laws’ (v – viii)
1978
Conservation of Familiarity
In general, the incremental growth and long term growth rate of E-type systems tend to decline. VI
1991
Continuing Growth
The functional capability of E-type systems must be continually increased to maintain user satisfaction over the system lifetime.
VII
1996
Declining Quality
Unless rigorously adapted to take into account changes in the operational environment, the quality of E-type systems will appear to be declining.
VIII
Feedback System (Recognised 1971, formulated 1996)
E-type evolution processes are multi-level, multi-loop, multi-agent feedback systems.

11. What do they mean?
Multi-level, multi-loop, multi-agent feedback systems – as if a justification for impact analysis was still needed….
The ‘real-world’ is unbounded, the number of assumptions can also become unbounded. Uncertainty is therefore an intrinsic feature, since an invalid assumption, or an assumption that becomes invalid, can alter the behaviour of the software.
Get ahead of yourself – estimate, and record, probable change in the application domain – what will be the affects on the application domain assumptions that have gone into the software development.
Seek to capture by any and all means, assumptions made during development and change.

12. Applicability of Lehman’s ‘laws’
Although not formally proven yet………
They are safely applicable to large, tailored systems developed by large organisations.
It is not safe to apply them to:
Open source systems (actually, not able to);
Systems that incorporate a significant number of COTS components;
Small organisations;
Medium sized systems.
Evolution processes are multi-level, multi-loop, multi-agent feedback systems – closed loop systems are difficult to analyse – what (internal or external) factors specifically cause what change can be much more easily established in open-loop systems.

13. Key points
Software evolution is the study of the phenomena of system change
After major empirical study, Lehman proposed that there were a number of ‘laws’ which applied to all systems as they evolved
Rather than laws, it is more sensible to say ‘observations’. They are shown to be safely applicable in some, not all, circumstances
Seek to capture by any and all means, the assumptions behind E-type software.

14. Bibliography/ Further Reading
Lehman, M.M., ‘Software’s Future: Managing Evolution’, IEEE Software, Vol. 15, No. 1, Jan-Feb 1998.
Bennet, K.H., Rajlich, V.T., ‘Software Maintenance and Evolution: a Roadmap’, ICSE 2000, pp 73 – 87, ISBN:
Lehman, M.M., Ramil, J.F., ‘An Approach to a Theory of Software Evolution’, Proc. IWPSE, Sept. 2001, Vienna.
Lehman, M.M., Ramil, J.F., ‘Rules and Tools for Software Evolution Planning and Management’, Annals of Software Engineering, Vol. 11, Iss. 1, Nov. 2001, ISSN:
Lehman, M.M., Ramil, J.F., ‘A Brief Introduction to the FEAST Hypothesis and Projects’, Imperial College, London, Dec. 2001, .