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

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

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’

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

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

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

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”

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.

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.

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.

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.

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.

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.

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:1-58113-253-0. 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:1022-7091. Lehman, M.M., Ramil, J.F., ‘A Brief Introduction to the FEAST Hypothesis and Projects’, Imperial College, London, Dec. 2001, http://www.doc.ic.ac.uk/~mml/feast .