Stevens Award LectureICSM 2003Amsterdam

24 September 2003

Meir (Manny) LehmanSchool of ComputingMiddlesex University

Bounds Green RdLondon N11 2NQ, U.K

mml@mdx.ac.ukhttp://www.cs.mdx.ac.uk/staffpages/mml

Software Evolution Cause or Effect?

24 September 2003 - 2 -

© 711c[charts-mml]

• Shared a strong interest in improving the software engineering process

• Unfortunately, though Wayne and I co-existed at IBM, I believe that we never met

Tribute to Wayne Stevens

• Whatever the difference, I am pleased and honoured to be able to pay this tribute tohis many achievements, his thoughtful contributions to software engineering

• This is reflected, for example, in his co-authorship of the 1991 ICSE13 paper “CASE at the Start of the 90s” from which I conclude that despite very different approaches we shared common concerns and reached related conclusions

• His main focus, however, was on practical issues of process improvementthrough development of improved methods and tools, sounder management and increasing provision of CASE support

• How his differs from mine will, I trust, become clear in the next hour

24 September 2003 - 3 -

© 711c[charts-mml]

• Demonstrate that software evolution is disciplined phenomenon with importantpractical significance and worthy of systematic study

• Current understanding of and conclusions about software evolution reflect35 years of data acquisition, empirical analysis, interpretation, modelling

By Way of Introduction

Focus on real world, that is E-type, software

• One very general conclusion: software process improvement requires more than just localised technological and/or management changes

• Foundations and framework for theoretical development now well established

• The latter may have significant impact locally, in the system and in time, but are of lesser consequence at the global level

24 September 2003 - 4 -

© 711c[charts-mml]

E-type Programs, Systems, Applications

• Behaviour during execution and its consequences determine acceptability

• Operate in and address real world problems or activities

Intrinsic property of E-type systems that they must be continuallyevolved to remain satisfactory

• That is, acceptability of a program is re-assessed with each execution

• Results of execution must reflect user and other stakeholder needs, domain and application properties, as specified - must be maintained valid as they change

• Stakeholder satisfaction the basic need and criterion

24 September 2003 - 5 -

© 711c[charts-mml]

Program - Real World Relationship

Is this sufficient?

Specification

abstraction

Real WorldDomains

• Program may be valid with respect to the specification, both must be validwith respect to the real world domain of interest

validation validationpartial

verification?

• In addition to properties required by specification, reification creates additional properties which must not be incompatible with specification

is_model_of

Program

reification

is_model_of

which, therefore, is a model of the specification

• Abstraction assumes that propertieseliminated are not relevant tosolution being determined

• Program reached by reification

• Also model of specification

• Program defined by a specification which is an abstraction of the real world operational domain

24 September 2003 - 6 -

© 711c[charts-mml]

But …

• Each may have properties not addressed by other or by specification

• As the two sets of properties change, incompatibilities may arise

• Operational domain and program properties are generally acquiredindependently of one another, the former sporadically, the latter duringdevelopment and evolution processes

• If such incompatibility affects results of execution, program, documentation and/orprocedures must be changed to avoid misbehaviour, ensure user satisfaction

In changing real world, system must be continually adapted, i.e. evolved, to remain valid

24 September 2003 - 7 -

© 711c[charts-mml]

What Drives this Evolution?

• The universe, which has an unbounded number of properties, is ultimateoperational domain of E-type systems

Invalidation of assumptions over time a key source of the pressure for continual software and system evolution

• Programs are artefacts produced by humans in finite time and so are necessarilybounded, that is finite, in the number of their implemented properties

• As its sub-domains, the geographical and execution domains of E-type applications and the applications themselves are also unbounded in the

number of their properties

• Gap bridged by unbounded number of assumptions reflected in specifications,program, interfaces, documentation, operational procedures and so on

• Some of these will become invalid as a result of domain and application changes

• It follows that every E-type program is incomplete relative to the application(s) anddomains it is designed addresses

24 September 2003 - 8 -

© 711c[charts-mml]

Assumptions

• They may be explicit or implicit, conscious or unconscious, by commission oromission, recorded or unrecorded

• Embedding of assumptions in specification and program is inherent to abstraction

and reification processes

Assumption management, control, updating key to reliable, efficient and, ultimately, safer software evolution and computer usage

• As a system evolves anticipation, detection and rectification of incompatibilities

will become ever more difficult, time consuming and costly, the challenge and

threat to an ever more software dependent society ever greater

24 September 2003 - 9 -

© 711c[charts-mml]

Summarising

What is maintained in software by its continual evolution is the validity of the assumption set and, thereby, stakeholder satisfaction

• As changes occur in the domains, some assumptions become

invalid

• An E-type system is a bounded, model-like, reflection of an application in itsoperational domains

reificationabstraction

Specification

ProgramReal WorldDomains

is_model_of

is_model_of

Validation Validation +

• Must be maintained valid if program is to remain satisfactory

Must be maintained compatible and valid

with one another

validation

reflect_ assumptions_about

• E-type systems must be continuallyevolved

• It must be validated with respect to real world behaviour

and reflects an unbounded number of assumptions

24 September 2003 - 10 -

© 711c[charts-mml]

Examples of Release-based Evolution

• Explanation, interpretation, validation of the patterns suggests empiricalgeneralisations

• Common features striking

• Late 60s operating system

• Analysis to identify and “explain” behavioural patterns, sources of differences

Releases: stable states of a continuing evolution process

Size in modules over release sequence numbers (RSN)

OS/360-370

S(i) = S(i-1)+0.19

1

2

3

4

5

6

7

1 5 9 13 17 21 25

SizeRelativeto RSN 1

RSN

Very Large Real-Time System

S(i) = S(i-1)+0.24

1

2

3

4

5

6

1 5 9 13 17

SizeRelativeto RSN 1

RSN

and a large current real time system

24 September 2003 - 11 -

© 711c[charts-mml]

Change Definition and Bounding

• Elicit, reconcile, merge, subjective, often biased, individual stakeholder views

• Process blends viewpoints, clarifies and agrees initial views, goals, assumptions,

One of many iterative activities in release development-process

and iteratively adjusts application, assumptions, domain bounds and so onto converge to authoritative view

with review, updating of all as required

EvolvingViews

ApplicationConcept

Application

Domain

• Need/Demand/Opportunity not satisfied by current system, statement of purpose

• All require clarification and consensus with/or authoritative decision

24 September 2003 - 12 -

© 711c[charts-mml]

Global process a feedback-system

The E-type Release Development-processExogenous

change

• All in changing real world domain

• Installation and introduction into usecloses major feedback loop

• Drives global evolution process as iterative sequence of releases

• Culmination: validated program

Program

• Series of stepsApplication

concept

Application domain

Stepn Step 2

Step 1

StepiStepi+1

• Final steps: installationOperational

program

• Then operation• , so changingapplication

• , whichchanges domain

24 September 2003 - 13 -

© 711c[charts-mml]

The Global Process

• Global process a feedbacksystem involving people

- multi-loop- multi-level- multi-agent

• Process not sequential

• More than technicaldevelopment

• Previous diagram a fiction

ApplicationConcept

OperationalProgram

Views(Predictive)

EvolvingUnderstandingand Structure

Theories, ModelsProcedures, Laws of Application and System Domains

RequirementsAnalysis

ComputationalProcedures

and Algorithms

ProgramDefinition

Program

CorporateManagement

Marketeers

UsersUser Support

Project &Process

Managers

ExogenousChange

.

Results in continual disciplined evolution that can be encapsulatedin laws whose details may be paradigm dependant

24 September 2003 - 14 -

© 711c[charts-mml]

Recent Formulation

Laws reflect a disciplined phenomenon that provides a baseand framework for a theory of software evolution

III1974

Self Regulation Global E-type system evolution is feedback regulated

II1974

Increasing Complexity

As an E-type system is evolved its complexity increases unless work is done to maintain or reduce it

IV1978

Conservation of Organisational Stability

The work rate of an organisation evolving an E-type software system tends to be constant over the operational lifetime of that system or segments of that lifetime

VI199

1

ContinuingGrowth

The functional capability of E-type systems must be continually enhanced to maintain user satisfaction over system lifetime

VII1996

DecliningQuality

Unless rigorously adapted and evolved to take into account changes in the operational environment, the quality of an E-type system will appear to be declining

VIII1971,1996

Feedback System (Recognised 1971, formulated 1996)

E-type evolution processes are multi-level, multi-loop,multi-agent feedback systems

V1978

In general, incremental growth (growth rate trend) of E-type systems constrained by need to maintain familiarity

Conservation of Familiarity

I1974

ContinuingChange

An E-type system must be continually adapted else it becomes progressively less satisfactory in use, more difficult to evolve

No. Brief Name Law

24 September 2003 - 15 -

© 711c[charts-mml]

and validate against further observations

Theory Formation

• Iterative extension - further generalisations, definitions, theorems, practical implications

• Derive practical implications

Determination of Rules, Guidelinesvalidate

• The latter provide inputs to formal theory formation

Formal TheoryFormation

• Observations and data provide continuing inputs to two level process which leads to observed behavioural patterns, models

Definitions,Empirical

Generalisation

ContinuedObservation

InterpretationExplanationModelling

Observational

Theoretical

Two levels

Initial Data

• Predict behaviours on basis of emerging theory

Prediction

What are entities involved?

• and empirical generalisations

24 September 2003 - 16 -

© 711c[charts-mml]

Entities Involved

• Four basic classes of entities are in involved in theory development

• Observations/axioms adopted as such may prove to be inferences/theorems

Example of empirical approach

• In addition, empirical and formal hypotheses may be proposed and investigated

Cl as s

Ap p r o ach

E m p i r i ca l F o rm al

D ef i n i t i o n s N a tu ra l L an g u a g e F o rma l

O b s e r v a ti o n s

P h e n o m e n ol o g i ca l

Obs er v a t i o n s

A x i om s

D ed u ct i o ns In f e re n ce s

T h e o rem s

C or o l l ar i e s

24 September 2003 - 17 -

© 711c[charts-mml]

Some Preliminary Definitions

• E-type operational domains are, respectively, sub-domains and sub-sets of thereal world with determined or implied bounds

• An E-type specification abstracts an E-type application to identify the properties and behaviours that must be reflected in a system if it is to produce a solution

to the application needs or terms of reference

• A program is satisfactory to the extent to which its execution fulfils the needs ofstated or implicit stakeholders

• An E-type program is a set of computer executable instructions defining a valid solution to an E-type application

• Real world comprises the entire universe, its properties and all happenings in it

• An E-type application addresses a problem or supports an activity in a specified real world operational domain

• A specification is satisfactory if it defines a program that satisfies real world needs

as reflected by the authoritative requirements of stated or implicit stakeholders

24 September 2003 - 18 -

© 711c[charts-mml]

• The real world has an unbounded number of attributes

Some Starting Observations

• It may be partitioned in an unbounded number of ways into domains that, in general, each possess an unbounded number of attributes

• Attributes of an E-type program are abstractions of attribute sets of applications and operational domains to be supported

• Attributes of an E-type application must all be accurately reflected in a program if it is to be satisfactory in all situations covered by accepted specification

• The attribute set of an E-type program - as distinct from such programs in execution -is bounded

• It is dynamic with its attributes continually changing independently, including alsoas a result of the installation and use of computers and changes in software

24 September 2003 - 19 -

© 711c[charts-mml]

• E–type operational domains have, in general, an unbounded number of attributes

Relevant Inferences

• There will always be operational domain attributes not addressed by program

• E–type specifications and programs have a bounded number of attributes butreflect an unbounded number of assumptions

• Assumptions about the operational domain reflected in an E-type programs maybecome invalid

• An E–type program and its operational domain may be or become incompatible

What, if any, is practical relevance of a theory of software evolution?

• E-type program execution entails uncertainty, satisfaction cannot be guaranteed

• Suffice to prove Principle of E-type Software Uncertainty

24 September 2003 - 20 -

© 711c[charts-mml]

Areas Addressed

• Much of what follows appears self-evident, elements in a code of good practice

Example - assumption management

• Some recommendations* developed for:- process management- release management- assumption management- component-based development

* Lehman MM and Ramil JF, Rules and Tools for Software Evolution Planning and Management, Annals of Softw. Eng., spec. iss.

on Softw. Management, v. 11, Nov 2001, pp. 16 - 44

• Can only consider one today, and then only very briefly

• Innovative in that recommendations are unified by common conceptual frameworkand, potentially, by formal theory all derived from real world observation

24 September 2003 - 21 -

© 711c[charts-mml]

Assumptions Management

• Develop and use tool support for the above and for system adaptation

Much more could be said, but not today

Hypothesis: Invalid assumptions constitute primary source of project and system misbehaviour or, in the extreme, failure hence:

• Identify, capture, structure, document, update, rationale, assumptions, decisions and review, revalidate whenever a change occurs/is made in the specification, design, implementation of an application in its domain

• Institute periodic and event-triggered reviews and assessments to anticipate oridentify a need for changes in assumption set

• Make search for and questioning of assumptions in all inspections andvalidations a specific and required activity

• Improve questioning of assumptions, for example, by using independentimplementation and validation teams

24 September 2003 - 22 -

© 711c[charts-mml]

Summarising

• High-level behaviour patterns share descriptions that provide basis for empirical generalisation that may be process-paradigm sensitive

• Sufficient data and insight to suggest formation of a theory of software evolution

• Phenomena abstracted are closely related to inherent feedback nature of the global

process, to organisational and societal factors, but must not be ignored bysoftware engineers even though they fall outside the scope of software

engineering as now perceived

Software use changes the world which forces evolution of the software

• Studies need to be widened but underlying global phenomena will remain

• Software global evolution process a multi-level feedback system

Software evolution is both cause and effect - closed loop

24 September 2003 - 23 -

© 711c[charts-mml]

Final Word - A Societal Challenge

Despite limited knowledge of his work I believe that vision presented would have had Wayne's full and enthusiastic support.

This is my tribute to him

• Growing societal dependence on software constitutes a threat and indicates needfor wider understanding of the evolution phenomenon to provides framework for directing and driving coordinated software process improvement

• Empirical study of the newer process paradigms and of assumption managementmust also be high on the priority list

• Current approach to software process improvement relies on ad hoc proposalsfor development of new or improved methods, tools, procedures etc.

• The nounal approach to software evolution addresses questions, which seeks to understand the nature, causes, impact, implications, management, control of software evolution, deserves far more attention, must be more widely

pursued

24 September 2003 - 24 -

© 711c[charts-mml]

Acknowledgements

• First and foremost my sincere thanks and appreciation to the Re-engineering Forumindustry association, IWCASE and the members of their Awards Committee fortheir recognition and so very generous (and exaggerated) words in the citation

• Finally, to my new colleagues at Middlesex University who welcomed me with open arms and enthusiasm and, in particular, to Professor Colin Tully, Director of Research of its School of Computer Science

• The wider results sampled in today’s talk are the result of much collaborative effort.My sincere appreciation and thanks go out to all the many colleagues with whom

I interacted over a 35 year period, who were partners in the work and conclusionspresented today and who so often educated and corrected me, set me straight,

• Those who should share in the award are too many to name. They are exemplified by Les Belady who laid the foundations with me in the 70s, Professor W M Turski

who educated and guided me since the 80s and is still doing so, to all members of

the FEAST teams and, in particular, Dr J F Ramil, now of the Open University, who has worked with me since he joined the FEAST projects, and is still doing so

24 September 2003 - 25 -

© 711c[charts-mml]

Relevant Papers

A complete listing of papers is provided at http://www.doc.ic.ac.uk/~mml/feast Rules, Tools and Guidelines

MM Lehman, Rules and Tools for Software Evolution Planning and Management, pos. paper, FEAST 2000 Workshop, Imp. Col., 10 - 12 Jul. 2000, DoC, Res. Rep. Nov 2000, a revised version to appear in Annals of Software Engineering, Spec. Issue on Software Management, vol. 11., 2001

MM Lehman, The Future of Software - Managing Evolution, inv. contr., IEEE Software, Jan-Feb. 1998, pp. 40-44Theory

MM Lehman and JF Ramil, Towards a Theory of Software Evolution - And Its Practical Impact, invited talk, ISPSE 2000, Intl. Symposium on the Principles of Software Evolution, Kanazawa, Japan, Nov 1-2, 2000

Process Modelling G Kahen, MM Lehman, JF Ramil and PD Wernick, Dynamic Modelling in the Investigation of Policies for E-type Software Evolution, ProSim 2000, International Workshop on Software

Process Simulation and Modelling, 12 - 14 Jul. 2000, London, UKBW Chatters, MM Lehman, JF Ramil, P Wernick, Modelling a Software Evolution Process, ProSim'99, Softw. Process Modelling and Simulation Workshop, Silver Falls, Oregon, 28-30 Jun.

1999, also as Modelling a Long Term Software Evolution Process in J. of Softw. Proc.: Improv. and Practice, 2000 v. 5, iss. 2/3, Jul. 2000, pps. 95-102MM Lehman, DE Perry and JF Ramil, On Evidence Supporting the FEAST Hypothesis and the Laws of Software Evolution, Proc. Metrics'98, Bethesda, MD, 20-21 Nov. 1998, pp. 84-88P Wernick and MM Lehman, Software Process White Box Modelling for FEAST/1, ProSim '98 Workshop, Silver Falls, OR, 23 Jun. 1998. As a revised version in Journal of Systems and

Software, Vol. 46, Numbers 2/3, 15 Apr. 1999MM Lehman and P Wernick, System Dynamics Models of Software Evolution Processes, Proc. Int. Wrkshp. on the Principles fo Software Evolution IWPSE-98, ICSE-20, 20-21 Apr. 1998,

Kyoto, Japan, pp. 6-10MM Lehman, DE Perry, JF Ramil, WM Turski and P Wernick, Metrics and Laws of Software Evolution - The Nineties View, Proc. Fourth International Symposium on Software Metrics,

Metrics 97, Albuquerque, New Mexico, 5-7 Nov. 97, IEEE Comp. Soc. or. n. PR08093, pp 20-32. Also as in K El Eman and N H Madhavji (eds.), Elements of Software Process Assessment and Improvement, IEEE CS Press, 1999

WM Turski, A Reference Model for the Smooth Growth of Software Systems, IEEE Trans. Softw. Eng., v. 22, n. 8, Aug. 1996, pp. 599 - 600 Estimation

JF Ramil and MM Lehman, Exploring Cost Estimation Models in the Context of Continuing Software Evolution, FESMA-AEMES Software Measurement Conference 2000 "Management Excellence through IT Measurement", Madrid, Spain Oct. 18-20, 2000

Lessons Learnt (e.g., Modelling Methodology)JF Ramil and MM Lehman, Metrics of Software Evolution as Effort Predictors - A Case Study, Proc. ICSM 2000, Int. Conference on Software Maintenance, 11-14 Oct. 2000, San Jose, CA

Component-based and Integration-intensive ProcessesOther

MM Lehman and JF Ramil, Software Evolution Phenomenology and Component Based Software Engineering, IEE Proc. Softw., sp. issue on Component Based Software Engineering, scheduled for Dec. 2000, earlier version as Tech. Rep. 98/8, Imperial College, London, Jun. 1998

JF Ramil (ed.), Preprints of FEAST 2000 International Workshop on Feedback and Evolution in Software and Business Process, Imp. Col., London, 10 - 12 Jul. 2000, 124 pp.JF Ramil, MM Lehman and G Kahen, The FEAST Approach to Quantitative Process Modelling of Software Evolution Processes, Proc. PROFES'2000 2nd International Conference on

Product Focused Software Process Improvement, Oulu, Finland, 20 - 22 Jun. 2000, in Frank Bomarius and Markku Oivo (eds.) LNCS 1840, Springer Verlag, Berlin, 2000, pp. 311 - 325. MM Lehman, Feedback in the Software Evolution Process, Keynote Address, CSR Eleventh Annual Workshop on Software Evolution: Models and Metrics. Dublin, 7-9 Sept. 1994,

Workshop Proc., Information and Software Technology, sp. is. on Software Maintenance, v. 38, n. 11, 1996, Elsevier, 1996, pp. 681 - 686

24 September 2003 - 26 -

© 711c[charts-mml]

BibliographyA listing with additional papers and other material is provided at and some may be accessed via http://www.cs.mdx.ac.uk/staffpages/mmlReferences indicated with an ‘*’ have been reprinted in Lehman MM & Belady LA, Program Evolution—Processes of Software Change, Acad. Pr., London 1985 *Belady LA & Lehman MM, An Introduction to Program Growth Dynamics, in Statistical Computer Performance Evaluation, W Freiburger (ed), Academic Press, New

York, 1972, pp. 503 - 511Boehm BW, Software Engineering, IEEE Trans. on Comp., v. C-5, n. 12, Dec. 1976, pp. 1226 - 1241id., A Spiral Model of Software Development and Enhancement, Computer, v. 21, May 1988, pp. 61 - 72id., Software Engineering Economics, Englewood Cliffs, N.J, Prentice-Hall, 1981Brooks FP, No Silver Bullet - Essence and Accidents of Software Engineering, Information Processing 86, Proc. IFIP Congress 1986, Dublin, Sept. 1-5, Elsevier Science

Pubs. (BV), (North Holland), pp. 1069 - 1076*Lehman MM, The Programming Process, IBM Research Report RC 2722, IBM Research Centre, Yorktown Heights, NY, Sept. 1969, also in Program Evolution—

Processes of Software Change q.v.*id., Programs, Cities, Students - Limits to Growth?., Imperial College. Inaugural Lecture Series, v. 9, 1970 - 1974, also. in [GRI78], pp. 42 - 69, Lehman MM & Belady

LA, 1985, pp. 133 - 163, also in Program Evolution—Processes of Software Change q.v.*id., Laws of Program Evolution - Rules and Tools for Programming Management, Proc. Infotech State of the Art Conf., Why Software Projects Fail, - Apr 9 - 11 1978, pp.

11/1 - 11/25*id., Programs, Life Cycles and Laws of Software Evolution, Proc. IEEE Sp. Iss. on Softw. Eng., v. 68, n. 9, Sept 1980, pp. 1060 - 1076Lehman MM, Stenning V & Turski WM, (1984). Another Look at Software Design Methodology, ICST DoC Res. Rep. 83/13, Jun 1983. Also, Software Engineering Notes,

v. 9, no 2, Apr 1984, pp. 38 - 53Lehman MM & Belady LA, Program Evolution,- Processes of Software Change, Academic Press, London, 1985, 538 p.id,. Evolution - The Cause of Iteration, Third Process Workshop, Breconridge, CO, Nov. 1986. In Iteration in the Software Process - Proc. 3rd Int. Process Wrkshp.,

Dowson M (ed), IEEE Comp. Soc. Press, Mar. 1987, pp. 29 - 32 Lehman MM, Process Models, Process Programs, Programming Support, Inv. Resp. To A Keynote Addr. By Lee Osterweil, Proc. 9th Int. Conf. on Softw. Eng., Monterey,

CA, 30 Mar. 2 Apr 1987, IEEE Comp. Soc. pub. n. 767, IEEE Cat. n. 87CH2432-3, pp. 14 - 16id., Uncertainty in Computer Application, Comm. of the ACM, Vol. 33, No. 5, May 1990, pp. 584-586id., Uncertainty in Computer Application and its Control through the Engineering of Software, J. of Softw. Maint., Res. & Pract., v. 1, 1 Sept 1989, pp. 3 - 27id., Models and Modelling in Software Engineering, Ency. of Softw. Eng., J Marciniak (ed), Wiley and Co, 1994, vol. 1, pp. 698 - 702id., Software Evolution, loc cit, vol. 2, pp. 1202 - 1208Osterweil L, Software Processes are Software Too, Iteration in the Software Process, Proc. of the 3rd Int. Proc. Worksh., Breckenridge, CO, 17 - 19 Nov. 1986, IEEE cat.

n. TH0184-2, IEEE Comp. Soc. order n. 709, 1987, pp. 79 - 80Perry DE, Policy and Product-Directed Process Instantiation, Proc. of the 6th Int. Softw. Process Workshop, 28-31 October 1990, Hakodate, JapanRajlich VT and Bennet KH, A Staged Model for the Software Life Cycle, Computer, July 2000, pp. 66 - 71Turski WM, And No Philosophers' Stone Either, Inf. Processing 86, Proc. IFIP Congr., Dublin, Sept. 1 - 5, 1986, Elsevier Sci. Pubs, London, pp. 1077 - 1080Wilkes M V, Wheeler D J & Gill S, The Preparation of Programs for an Electronic Digital Computer, Addison Wesley Press Inc., 1951, 167 pp.Wirth N, Program Development by Stepwise Refinement, CACM, v.14, n.4, Apr 1971, pp.221-227*Woodside CM, A Mathematical Model for the Evolution of Software, J. of Sys. and Softw. vol. 1, no. 4, Oct 1980, pp. 337 - 345 Zurcher FW and Randell B, Iterative Multi-Level Modelling - A Methodology for Computer System Design, IBM Res. Rep. RC 1938, Nov. 1967, IBM Res. Centre,

Yorktown Heights, NY 10594. Also in Information Processing 67, Proc. IFIP Congr. 1968, Edinburgh, Aug. 1968, pp. D138 - 142

24 September 2003 - 27 -

© 711c[charts-mml]

E-type System Evolution as a Phenomenon

• Potential for disciplined study and for theoretical base and framework suggestedby common behavioural abstractions and invariants, across industriallydeveloped software from variety of domains and evolved using variety ofmethods, tools

Development of an empirical theory

• Core observations- real world domains and applications each have an unbounded number of properties- programs are finite in the number of their properties and, therefore, reflect an unbounded number of

assumptions- gradual invalidation of some of these leads to an intrinsic need for continuing evolution- feedback system characteristics largely determine global evolutionary behaviour- consequence of domain and global process properties, rather than of technology - some key features encapsulated in or consequence of Laws and in Uncertainty Principle- source of relationships between laws related to feedback characteristics of process

24 September 2003 - 28 -

© 711c[charts-mml]

Introductory Observations

• Demonstration of software as a disciplined phenomenon and related empiricalgeneralisations provide, at least, initial feasibility

• Whether a satisfying empirical theory can be developed and a formal theoryderived remains to be demonstrated

• Some initial implications derived from the laws have been discussed* andexemplify what might be derived from such a theory

* Rules and Tools for Software Evolution Planning and Management, Annals of Software Engineering, special issue on Software Management, v. 11, November 2001, pp. 16 - 44

Software System Maintenance and Evolution in an Era of Reuse, COTS and Component-Based Systems , Joint Keynote Lecture, ICSM. and WESS 99, Oxford, 3 Sept. 1999 and Software Evolution in the Age of

Component-Based Software Engineering, IEE Proceedings Software, v. 147, n. 6, Dec. 2000

• Empirical studies have yielded laws providing candidate observations, potentialinferences

24 September 2003 - 29 -

© 711c[charts-mml]

Metrics and Modelling

• Recalibrate, validate models as new data becomes available so as to reflectprocess, application, environmental changes

• For system as a whole and its parts, acquire, plot, model, interpret historicalevolution data and determine patterns, trends, growth and their rates of

change

• Model and exploit dynamics of global process to improve planning and process, identify interactions, evaluate and optimise policies, control strategies

• Develop tools to support data collection, modelling, etc.

All the above relate to global process,apply to both technical and organisational activities

24 September 2003 - 30 -

© 711c[charts-mml]

General Definition of Evolution• Evolution is staged process of discrete, progressive, change over time in the

characteristics, attributes, properties of some material or abstract, natural or

artificial, entity or system or of a sequence of these

Examples

• May occur at many levels - and does in software - Software Evolution and Software Evolution Processes, MM Lehman, JF Ramil, Ann. of Softw. Eng. v. 14, 2002

• Our work has focused on release-based evolution process

24 September 2003 - 31 -

© 711c[charts-mml]

Evolution Management

• Create, maintain comprehensive documentation, emphasising identification and recording of assumptions - critical for usability, system evolvability and longetivity

• When validating, check interaction with, impact on unchanged parts of system- impact of assumptions

• Assess likely functional and non-functional evolutionary trends in advance andreview as part of release planning, taking system, domain volatility into

account

• Develop tools for capture, structured recording and periodic review of assumptionsand of changes to them

Plan, manage, control release to users

• Establish baselines of key measures over time - to support review

• Involve application, domain specialists in assessment

• Capture, monitor, analyse, exploit metrics, patterns, trends, rates of change

24 September 2003 - 32 -

© 711c[charts-mml]

• Observe safe change rate limits

• Follow established software engineering principles - e.g., information hiding - tominimise spread of change between system elements

Release Management

• Assign resources to control and reduce complexity and its growth

• If excessive functional increments are unavoidable, plan for clean-up releases

• Alternate enhancement, extension with clean-up, restructuring releases

• When large functional increments appear unavoidable, distribute across severalreleases as in Gilb’s evolutionary development

• And, using models, to anti-regressive activities

Assumptions play key role in release planning, management

24 September 2003 - 33 -

© 711c[charts-mml]

Software Components

• Many issues, e.g.:- Functional and interface specifications- Embedded assumptions- How components are used- System evolution- Disparate users- Long term impact on cost, quality, integrity, reliability- Component developer ownership rights

Identification, understanding of issues essential if components are to be effective over prolonged period despite assumption set changes

• Compatibility with disparate users, themselves evolving, and with concurrentevolution of system, application, domains, must be maintained

• Long term costs are likely to increase; quality, availability, evolvability decline

• Assumptions embedded in components essentially unknowable, constrained byownership interests, clashes with evolving, disparate, systems

unpredictableperhaps irreconcilable

24 September 2003 - 34 -

© 711c[charts-mml]

Bottom Line

• To be of lasting value components must be semantically and syntactically as clearly and completely defined as any operator in a programming language

• Problems must be identified, solved if assumptions are to be managed, component usage is to have lasting value

• Techniques outlined earlier apply also component-based domains

• New issues to be addressed:- Independence of system and component development organisations- Protection of commercial competitive market place interests- Multiple, possibly competitive, clients with conflicting interests, concerns

• Component-based architecture and design logically equivalent to programmingin very high level programming language

Must identify specific problems that will surely arise and devise means to overcome, or at least control, them

24 September 2003 - 35 -

© 711c[charts-mml]

• Observe safe change rate limits

• Follow established software engineering principles - e.g., information hiding - tominimise spread of change between system elements

Release Management

• Assign resources to control and reduce complexity and its growth

• Plan for clean-up releases if excessive functional increments are unavoidable

• Alternate enhancement, extension and clean-up, restructuring releases

• When large functional increments appear unavoidable distribute across severalreleases as in evolutionary development - Gilb

• Constrain release increment scope, size as suggested by models of past growth using criteria such as ~≤ m, ~(m+s) i.e. ~(m ‹ incr ‹ (m+2s)), ~≥ (m+2s) - as instatistical process control - to determine whether increments are safe, risky,

unsafe

• More generally, assess need and assign resources to anti-regressive activities

Assumptions play key role in release planning and management

24 September 2003 - 36 -

© 711c[charts-mml]

Software Components

• Issues relate to:- Components themselves- Way they are used- System evolution- Components in an evolving system - Long term impact on cost, quality, integrity, reliability

• In a world moving to component-intensive software and processes important toexamine implications of evolution phenomenon to:

- Determine if, why and how components are sensitive to it- Derive implications of laws of software evolution in component context- Investigate means to mitigate and control impact

• Present discussion restricted to issues related to assumptions

Identification and understanding of issues essential if components are to be effective over prolonged period

24 September 2003 - 37 -

© 711c[charts-mml]

Conclusion

Decisions based on balancing cost, value, risk that arise from alternative strategies and approaches

• Views may appear pessimistic but I am not a Luddite

• Problems in the use of components, in particular those relating to assumptionsmust be identified, spelt out, solved to retain control of computer usage

• Eventually, problems that have arisen in conventional programming will re-emerge

• Intervening period must be used to identify specific problems that will surelyarise and to devise means to overcome, or at least, control them

24 September 2003 - 38 -

© 711c[charts-mml]

Bounding Process

• Elicit, reconcile, merge, limit restricted, subjective, often biased, views ofindividual stakeholders

-all levels of management-organisational, individual, direct or indirect users-marketeers, suppliers, procurement personnel-domains and application experts-system, software engineers, developers-etc., etc.

• Process blends viewpoints, determines broad goals, agrees initial assumptions

• Iterative convergence to consensus changes assumptions, application, bounds

Release process

EvolvingViews

ApplicationConcept

Application

Domain

24 September 2003 - 39 -

© 711c[charts-mml]

Phenomenology

• In philosophy, the science of phenomena as perceived, as opposed to thestudy of being, the nature of things as they are - √

• Philosophical investigation, description of conscious experience in all varietieswithout reference to question of whether experience is objectively real - √

Theory• More or less plausible or scientifically acceptable general principle or body of

principles offered to explain phenomena - √

• Body of theorems presenting clear, rounded and systematic view of a subject - √

• Analysis of a set of facts in their ideal relations to one another - ?

• General or abstract principles of a body of facts; pure as distinct from appliedscience - X

• Analysis of a set of facts in their ideal relations to one another - √

24 September 2003 - 40 -

© 711c[charts-mml]

• Way forward to formation of theory of software evolution appears realistic thoughnot without challenges

• Current state: behavioural, patterns invariants for current widespread process paradigm identified; models constructed, interpretations, empirical generalisations proposed

Software Evolution

Outline example

• Ultimately theory may be generalisable to cover wide range of:- Real world domains- Applications - Organisations- Software processes

• Initial challenge, selection of appropriate generalisations, determination andformalisation of definitions

• Early empirical generalisations provide foundation for development of definitions,axioms, candidate theorems, proofs in formal theory

24 September 2003 - 41 -

© 711c[charts-mml]

• Initial generalisations adopted over a long period of observation

Example at Observational Level

Generalisations and associated definitions

• A set of observations and one of inferences

• Believed to be sufficient to support principle of software uncertainty

• Associated definitions intuitive

24 September 2003 - 42 -

© 711c[charts-mml]

• And, therefore, of E-type software

Final Word

• Evolution inevitable in computer application in a dynamic real-world

• Main current effort in software evolution R & D has largely adopted a verbal, tooloriented, approach that develops methods, processes, tools etc.

More effort in study of the evolution phenomenon

• Rapidly increasing societal dependence on software represents a real threat and indicates need for wider understanding of the phenomenon to provideframework to direct and drive coordinated development, process improvement

• Interpretation of evolution as a noun leads to seeking understanding of its nature,causes, impact,implications and control, leads to more systematic progress

• Empirical study of the newer process paradigms and of assumption management high on the priority list

•

but deserves and justifies much more attention

• yieldinglocalised, ad hoc process improvement