8 January 2006 - 1 -

© 731c[charts-mml]

Assumptions in Software Development and Evolution

Meir (Manny) LehmanSchool of Computing

Middlesex University

The Burroughs]

London NW4 4BE, UK

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

Abstract: A brief summary of the results of many years of study of E-type system evolution leads to a focus on the inevitability and crucial role of assumptions and their potential impact. The societal and economic consequences of failure in this respect clearly indicates that their adequate management is increasingly vital.

January 2006

8 January 2006 - 2 -

© 731c[charts-mml]

Facts of Life

Effective planning, management , control of software evolution a major challenge but potential for significant returns

•Long known that 50% to 95% of E-type software life cycle costs incurred on maintenance after introduction into use, that is on evolution

• Recent RAEng/BCS report quoted study predicting UK 2003/4 £B22.6 software expenditure - that of other countries will be similar though modified by size of

economy

• Will increase as problem and environmental complexity, inter-system integration and communication, operational, functional, data detail grow

• Human and indirect costs in addition

• Hence UK expenditure in software evolution that year between £B11.3 and £B21.5 - probably (O) £B15

• Other economies similar, though dependant on technological, economic levels

8 January 2006 - 3 -

© 731c[charts-mml]

Opportunities for Process Improvement

First, brief historical overview of basic observations

• Major potential benefit from development of understanding of, discipline, methods and tools for evolution planning and management

• Potential UK annual saving from improvement of only 10% could yield up to £b2benefit on direct software costs alone

• Human, social, economic saving potential many times that

8 January 2006 - 4 -

© 731c[charts-mml]

• Practical implications - Rules and Tools for Software Evolution Planning, Management and Control, Annals of Softw. Eng. Spec. Iss. on Softw. Maint., v. 11,

2001, pps. 16 - 44

Historical Review

- 1968 - 69 IBM Programming Process study the seed- 1969 - 71 First recognition of the role of feedback- 1969 - 02 Collection, analysis of empirical data on evolution of industry-developed systems- 1974 - 86 Laws of Software Evolution- 1979, 04 SPE program classification schema leading to- 1988 Key role of assumptions- 1989 Principle of Software Uncertainty- 1996 - 01 FEAST/1 and /2 projects- 2004 SPE+

Laws were first step in formulating theory

•Basic observation: evolution, particularly of software, inherent to real world use of computers - not an indicator of weakness or incompetence

•Significant elements of an emerging theory of software evolution with feedback key mechanism, role and impact of assumptions key factor

8 January 2006 - 5 -

© 731c[charts-mml]

Status of Laws

• Formulation of feedback observation as eighth law suggested that first seven arerelated to feedback properties

• Subject to extension and generalisation

Today's focus: presence and effect of assumptions in real world computing

• Originally derived individually by observation; relationships between them notinvestigated

• That is, feedback-systems theory significant component of software evolution theory

8 January 2006 - 6 -

© 731c[charts-mml]

Computing in the Real World

• System acceptability depends on stakeholder satisfaction with results of andbehaviour in execution

• E-type software, systems, applications - address problems, activities and/or operatein real world domains

Implication: E-type systems can never be guaranteed fault free- that is, entirely satisfactory or utterly reliable

• Correctness second level issue

8 January 2006 - 7 -

© 731c[charts-mml]

Fundamental Requirements

• To produce acceptable results, system must reflect every property of application, domains to level of precision, detail as at time of concern

• Must continue to hold as domains, application properties and expectationschange

Evolution inescapable for provision of continuing useful service

• Software must be continually adapted to maintain stakeholder satisfaction

• Such change inevitable since real world undergoes continuing change, in part aconsequence of system installation and use

8 January 2006 - 8 -

© 731c[charts-mml]

Intermediate Summary

In any event, software evolution inescapable phenomenonintrinsic to E-type systems

• Real world dynamic

• Without evolution there will be inevitable decline in validity, functionality, utility,performance

• Application and domain changes maintains system in tune with real world needs,

states, opportunities, ambitions

• More generally evolution exploited to increase them

8 January 2006 - 9 -

© 731c[charts-mml]

Human Development

• Properties of E-type domains and applications are unbounded in number

• Moreover, humans can consider only bounded number of product properties indesign and construction

Essential uncertainty whether any artefact is complete or correct

•Since human knowledge, understanding, mastery of real world properties isbounded they cannot consider, determine, even know relevance of all these

8 January 2006 - 10 -

© 731c[charts-mml]

The Consequence

Principle of Software Uncertainty follows

•Hence every E-type program reflects unbounded number of assumptions- that rejected properties are irrelevant to achieving satisfactory execution

•Design and evolution activity involves abstraction, consciously rejectingor implicitly ignoring unbounded number of application and domain properties

• Unbounded number of real world properties rejected or ignored in systemdevelopment, evolution

8 January 2006 - 11 -

© 731c[charts-mml]

However often a system has executed satisfactorily, satisfaction on its next execution is uncertain

Principle

8 January 2006 - 12 -

© 731c[charts-mml]

Source of Uncertainty

Hypothesis: assumptions that are or become invalid major source of project or computer failure during development and use

• Unbounded set of excluded properties may include such as should have beeninitially included or which such changes eventually make relevant

• Application and domain changes will falsify adopted assumptions set

8 January 2006 - 13 -

© 731c[charts-mml]

Examples of Initial or Eventual Invalid Assumptions that Led to Major Problems

• CERN Accelerator - unconscious, but valid, assumptions during development eventually became invalid

• London Ambulance System - invalid design assumption

• First launch of Ariane V - conscious and valid operational application and domain (hardware)assumptions

• Sinking of the Sheffield (18 lives) - initially valid, predictably invalid, application assumption

Daily examples on Google Alerts for Software Failure provide major source of material for further investigation

8 January 2006 - 14 -

© 731c[charts-mml]

Assumptions and their Implications

• Real world changes during use cause invalidation of assumptions

• Assumptions embedding in system during abstraction, reification, boundingintrinsic to E-type computing system development, evolution, usage

Assumption management vital but much neglected development and maintenance responsibility

• Assumptions may be explicit or implicit, conscious or unconscious, by commission or omission, recorded or unrecorded, (initially) valid or invalid

•Continual search for and review of assumptions to ensure satisfactory, that issafe, reliable, efficient, controlled computer usage

8 January 2006 - 15 -

© 731c[charts-mml]

What is Software Maintenance?

Software maintenance maintains validity of assumption set and stakeholder satisfaction

8 January 2006 - 16 -

© 731c[charts-mml]

Theory of Software Evolution

• Its development non-trivial but development could have major impact

• Have outlined base and framework for development of theory of softwareevolution

Theory a powerful tool to reduce cost and threat implied by need for continual evolution; need with major technical,

economic, social implications

•Theory can provide direction and discipline to conception, development,integration of methods and tools; software evolution process improvement

8 January 2006 - 17 -

© 731c[charts-mml]

Reservations

•Observations, hypotheses, generalisations such as laws and principle all based on data from conventional industrial processes

Urgent need for widespread R & D to determine evolution characteristics as function of these and other variables

• Some studies of Open Source processes appear to suggest other growth patterns but support conclusion that software evolution is predictable phenomenon

• Not aware of studies of evolutionary behaviour of systems developed using otherapproaches such as Object Oriented, Open Source, Agile programming

• But universal and process independent domain concepts, behaviours, in particular feedback, assumptions, suggest that phenomenon is universal - independent in principle, though not necessarily detail, of application, domain, process, degree

of system integration, development organisation and so on

8 January 2006 - 18 -

© 731c[charts-mml]

Areas Ripe for R & D, Industrial Application

• Likelihood analysis of changes and their impact on application and domains

• Areas and extent of reviews required to ensure timely changes in advance of failure

• Search for guidelines to minimise likelihood of assumption invalidation, maximise structural flexibility, increase changeability, reduce cost of system changes

• Structured, indexed, mechanised data-base system for assumption management

• Periodic and event-triggered reviews to update assumption sets at all stages of system definition, development, evolution

Examples

8 January 2006 - 19 -

© 731c[charts-mml]

Key R & D Challenges in Assumption Management, Control

• In general, assumption management and control at every and all stages of development, evolution

Examples in specific process activities

Determine, develop and, where possible, formalise method and tool support for:-

• Periodic and, event-triggered reviews to update assumption set, its validity and evaluation of its exposure to and likelyhood of change

• Identifying, questioning assumptions in problem and requirements definitionarchitecture, design, reviews, implementations, inspections, validation etc.

8 January 2006 - 20 -

© 731c[charts-mml]

Assumptions Management

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

In general: search for, examine, control assumptions in all activities

Good practice requires one to:-•Identify, capture, structure, document, update rationale, assumptions,

decisions underlying them with reviews and revalidation whenever changes occur in application, domains

• Institute periodic and event-triggered assessments to anticipate or identify changes

in assumption set and system changes they may require

• Extend process to make search for and questioning of assumptions in reviews,

inspections, validations etc. at each step a specific and required activity

• Improve questioning of assumptions by, for example, using independentspecification, implementation, validation teams

8 January 2006 - 21 -

© 731c[charts-mml]

Further Example: Requirements

• Whatever process is followed, all activities must include disciplined examination of

possible impact on assumptions, existing or implied, potential consequences

General conclusions

•Explicit and implicit assumptions at each stage of entire processMust explicitly address and rule on issues such as:

•Continually determine timings for review of all aspects of system to ensure timely

changes, forestall undesirable behaviour•Linkage of architecture, process, design, code, documentation, procedures, etc

to requirements to simplify change and minimise assumption dependent errors

• Full structured, indexed documentation to facilitate organised, timely searches formissing or invalidated assumption statements

•Likelihood and potential impact of changes in problem and domains

8 January 2006 - 22 -

© 731c[charts-mml]

In Summary

• Relate general and specific behavioural patterns and characteristics to application areas, domains, processes, organisation, cultures etc.

• Must recognise inevitability of evolution and accept need for related social,

economic, operational effort and expenditure

•Develop and apply understanding of evolution to support development of

processes, methods, tools for, for example, its and assumption management

8 January 2006 - 23 -

© 731c[charts-mml]

Relevant Papers

Complete listing provided at http://www.cs.mdx.ac.uk/staffpages/mml/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

EstimationJF 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 Processes

OtherMM 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. 1998JF 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 V, 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

8 January 2006 - 24 -

© 731c[charts-mml]

Bibliography - Lehman et al

A listing with additional papers and other material may be accessed via http://www.cs.mdx.ac.uk/staffpages/mml/. References indicated with an ‘*’ reprinted in Lehman MM & Belady LA, Program Evolution—Processes of Software Change, Acad. Pr., London 1985 and now available on web

Lehman MM, Kahen G and Ramil JFl,, Simulation Process Modelling for Managing Software Evolution,in Juristo N. and Acuna S (eds.), Software Process Modelling, Kluwer Ac. Pr. Lehman MM and Ramil JF, Theory of Software Evolution - Background, Theory, Practice, Seventh World Conf.on Integrated Design and Process Tech., Austin, TX, Dec. 3rd – 6th, 2003,id., Towards a Theory of Software Evolution - Background, Theory, Practice, Info. Proc. Letters, v. 88, 2003, pp. 33 - 44id., Software Evolution - Background, Theory, Practice, IDPT, TX, Dec 2003Lehman MM, A Formal Theory of Software and Artificial Systems Evolution, Pos. Pap., Worksh. on Grand Challenges for Computing Research, EPSRC proposal, 17 Oct. 2002, 2 psid., Software Evolution,, Encyclopaedia of Software Engineering, J Marciniak (ed), 2nd ed. Wiley and Co, 2 vols., 2002, pp.1507–1513, revised and extended version of mml507Lehman MM and Ramil JF, Some Lessons Learnt in and from the FEAST Project, WESS 2002, Montreal, 2 Oct 2002id., Software Uncertainty in General and in KBS Applications in Particular, 9th Int. Conf. on Info. Proc. and Man.of Uncertainty in KBS IPMU 2002, Annecy, France, 1-5 Jul. 2002Lehman MM, Software Uncertainty, Proc. Soft-Ware, 1st Int. Conf. on Comp. in an Imperfect World, Interactive Science and Tech. Conf. Centre, Belfast, Northern Ireland, 8-10 Apr. 2002Lehman MM, Kahen G and Ramil JF,, Behavioural Modelling of Softw. Proc. of Long Lived Evol.Proc. –Issues and Exa. ICSTM, J. Softw. Maint. and Evol., v 14, 2002, pps. 335 – 351Lehman MM,, Software Evolution and Software Evolution Processes, Inv. Contr. sp. iss. on Proce.-based  Softw. Eng, Ann., Softw. Eng. v. 14, 2002, pps. 275 – 309 Nov. 2002, Lehman MM and Ramil JF,, SEPiCS – Evolution Phenomenology in Component-intensive Software, WESS 2001, Florence, 9 Nov. 2001id., Is Evolution Intrinsic to All Real World Software?, EPSRC Network on Evolvability in Biological & Software Systems, Proc. Symp. "Software Evolution and Evolutionary Computation", (SEEC), U. of Herts. Workshop, 7 – 8 Feb. 2001Lehman, JF Ramil and U Sandler,, An Approach to Modelling Long-term Growth Trends in Software Systems,, Proc. ICSM 2001, 6-10 Nov., Florence, Italy, Nov. 2001Lehman MM, Kahen G and Ramil JF,, Thoughts on the Role of Formalisms in Studying Software Evolution, Proc. of Worksho. on Formal Foundations of Softw. Evolution, 13 Mar. 2001, Lisbon, Portugal, 8 pp., in Mens T. and Wermelinger M (eds.) Tech. Report UNL-DI-1-2001, Departamento de Informática, Universidade Nova de Lisboa, 8pps.,Evolution and its Impact on Business Processes, Technology Outreach, EPSRC/DTI workshop, London, 15 Mar. 2001Lehman MM and Ramil JF, iSoftware Evolution, wProc. IWPSE 2000Lehman MM, Kahen G and Ramil JF,, Software Evolution: Phenomenon, Metrics, System Dynamics, with JF Ramil and G Kahen, Managing Systems Evolution: Software SystemsLehman MM and Ramil JF, FEAST/2 Workshop - Introduction and Overviews, ICSTM, 19 Dec. 2000Lehman MM., Models and Modelling in Software Engineering, Encycl. of Softw. Eng., J Marciniak (ed), Wiley and Co, 1994, vol. 1, pp. 698 - 702 (Revised ed. 2002)id., Software Evolution, loc cit, vol. 2, pp. 1202 - 1208id., 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 - 27Lehman 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,. Evolution - The Cause of Iteration, Third Process Workshop, Proc. 3rd Int. Process Wrkshp., Dowson M (ed), IEEE Comp. Soc. Press, Mar. 1987, pp. 29 - 32 Lehman MM & Belady LA, Program Evolution,- Processes of Software Change, Acad. Pr, ,London, 1985, 538 p.Lehman MM, Stenning V & Turski WM, (1984). Another Look at Software Design Methodology, Software Engineering Notes, v. 9, no 2, Apr 1984, pp. 38 - 53

*id., Programs, Life Cycles and Laws of Software Evolution, Proc. IEEE Sp. Iss. on Softw. Eng., v. 68, n. 9, Sept 1980, pp. 1060 - 1076

*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/25id., Human Thought and Action as an Ingredient of System Behaviour, Contribution to the Encyclopaedia of Ignorance, July 1976, (Pergamon Press 1977) pp. 397-354*Lehman MM Programs, Cities, Students - Limits to Growth?., Imp. Col. Inaug. Lect. Sers, v. 9, 1970 - 1974, and [GRI78], pp. 42 - 69, Lehman MM & Belady LA, 1985, pp. 133 - 163, *Belady LA & Lehman MM, An Introduction to Program Growth Dynamics, in Stat.Comp. Perf. Eval, W Freiburger (ed), Acad Press, N,Y. 1972, pp. 503 - 511*Lehman MM, The Programming Process, IBM Res. Rep. RC 2722, IBM Res. C,, Yorktown Heights, NY, Sept. 1969

8 January 2006 - 25 -

© 731c[charts-mml]

Bibliography - OthersA first listing with additional papers and other material is provided at and some may be accessed via http://www.cs.mdx.ac.uk/staffpages/mml/Needs to be updated

Boehm 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 - 1076Osterweil 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

8 January 2006 - 26 -

© 731c[charts-mml]

Laws of Software Evolution

Derived from observation and metricsProvides base for empirical 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

Rate of work of organisation evolving E-type software tends to be constant over phases of the operational lifetime of system

VI 1991

ContinuingGrowth

Functional capability of E-type systems must be continually enhanced to maintain user satisfactionVII

1996DecliningQuality

Quality of E-type systems declines unless rigorously evolved to take into account changes in the operational environmentVIII

1971,1996

Feedback System (Recognised 1971, formulated 1996)

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

V1978

Growth rate trend of E-type systems constrained by need to maintain familiarity

Conservation of Familiarity

I1974

ContinuingChange

Unless continually adapted, an E-type system must decline in use and become ever more difficult to maintain satisfactory

No. Brief Name Law

8 January 2006 - 27 -

© 731c[charts-mml]

Example of E-type Evolution

• Instability and break-up from rsn 20 triggered by excessive positive feedback preceding growth rate decline observed in other systems

• Underlying linear growth with superimposed ripple to rsn 19

• Ripple, indication of feedback stabilisation

• Initial faster than linear growth

• First observation

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

8 January 2006 - 28 -

© 731c[charts-mml]

Further Example

• Consistently similar evolution patterns observed on other systems

• Understanding has gone through three stages, linear, inverse square, S-curvegrowth patterns

• Similar faster than linear initial growth and sustained ripple

Suggests empirical generalisations such as:Laws, Principle of Software Uncertainty, ∫-growth (S-curve)

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

• Large current telephone switch - 44M instructions 4 years ago