Tài liệu the grand unified theory of software engineering pptx

‘The Grand Unified Theory of Software Engineering Schednle disaster, etional mist, and system bigs all arse be- cause the Aff band doesn't know what the right hand is doing Teams drift

+ Software Engineering

AM sighs sexed No pt of tin polction mye ep, sre na ete ane,

‘etait oy Fon or by any meat, ect esha, photocopying tig, otherwise, thou prt wniten pein of the ple or aston

Cover dei ais Esta and Pont Johan,

The present edition of the book is not quite as polished as it should bbe due to thar eternal culpsit, time The book thus contains some Significant faults thatthe authors hope that the reader have forbear ance with until the nest version Firstly, there are no — oat least Far too few — references Secondly, there is no index ‘Thirdly, the tweatment of language and the pedagogical presentation need fax- thee work Inthe next version, these issues will be remedied

This book is the result of innumerable longwinded, oftentimes un- necessatily complicated, frequently iextatingly repetitive, and mostly highly enriching discussions between the authors on the nature of soltware engineering, machines, minds, design, software, engineer- fing, organizations and more It is high time to let the icleas that have evolved through these discussions be subjected to the light of pub- lie scrutiny We have thus felt the urge to publish this book

We wish to thank Professor Torsten Cegrell for creating what

we believe to be one of the few workplaces in Sweden where an en- texprise with such grandiose ambitions as the present may be un dertaken and genuinely supported, Our thanks also go to Erik Jo- hansson, who hay been a steadfast backer of this project through- out its evolution We also wish to thank the rest of the people at the Department of Industrial Information and Control Systems at the Royal Institute of Technology in Stockholm for cheering us on,

PROBLEM SOLVING AND COMPOSITION

THEE VON NEUMANN MACHINE

‘THE SOFTWARE MACHINE,

A.NOTE ON THE TITLE

‘THE IMPORTANCE OF A UNIFH

THEORY

SCIENTIEIC MATURITY AND THEORY

‘THE BENEFITS OF A UNIFIED THEORY

‘THE WORLD ACCORDING TO THE GUTSE LÍ

‘SPECIFICATIONS AND TRANSEORMERS 1

‘MINDS AND MACHINES

LEVELS ON WHICH TO ACCEPT THE GUTSE.»

‘THE QUALITY OF A THEORY

AN OVERVIEW OF THE GUTSE

‘Ti Description LANGUAGE

“THỊ BASIC ENTITIES

“Thi: COMPOSED ENTTTIES

OUTLINE OF THE BOOK

‘THE TRANSFORMER FROM THE OUTSIDE

‘THE TRANSFORMER FROM THE INSIDE

SEMANTICS

SEMANTIC MAPPINGS,

‘SEMANTIC DIAGRAMS

SEMANTIC DOMAINS

(CATEGORIZING SEMANTIC RELATIONS

[RELEVANT AND IRRELEVANT SEMANTI

FINISHED AND UNFINISHED SPECIFICATIONS

1

PROBLEM SOLVING AND COMPOSITIO’

PROBLEMS AND SOLUTION: 53 (GENERAL PRODLEMS AND SOLUTIONS 53

‘SOFTWARE ENGINEERING PROBLEMS AND SOLUTIONS 4 SINGULAR AND COMPOSITE TRANSFORMERS

COMPOSITION sno

Basic Forms oF COMPOSITION

CoPosiNa FoR COMPLIANCE

INDIRECT RELATIONS BETWEEN TRANSFORMERS

‘MINIMIZING CONSISTENCY REQUIREMENTS

NATURAL CONSISTENCY REQUIREMENTS

ARTIFICIAL CONSISTENCY REQUIREMENTS,

‘THE SOFTWARE MACHIN

ComPosin Von NEUMANN MACHINE ACTIONS

CoposiTioNal UNITS

COMPOSITIONAL SCHEME

‘ComPosiNG VON NEUMANN MACHINES

'COMPOSING PROCEDURES «eS-5cecsccstecs ANSTRACT MACHINES

COMMUNICATION

‘THE ORGANIZATION

‘COMPOSITIONAL SCHEME OF THE ORGANIZATION

DIVISION OF DESIGN LABOR, CONSISTENCY AND

‘THE EVOLUTION OF THE ORGANIZATION w

‘THE EARLIEST ORGANIZATION

‘MoE MACHINES HI MACHINE INTERMEDIARIES " MACHINE CHECKERS ——H2

‘THE SURGICAL TEAM

‘Ta: SpiaL Moet

ADDITIONAL TOURS DE FORCE

ASSESSING COMPOSITIONAL PARADI

PERSPECTIVE

ASSESSING COMPOSITIONAL PARADIGMS FROM AN

ORGANIZATIONAL DESIGN PERSPECTIVE AND VICE VERSA

ASSESSING COMPOSITIONAL PARADIGMS FROM.A VON

NEUMANN PERSPECTIVE 136 ASSESSING ORGANIZATIONAL DESIGN FROM MIND

PERSPECTIVE

COST OF CHANGE,

OUTLINE oF THE ToUR DE FORCE

inst CHANGE Case

‘SECOND CHANGE CASE

EXPLORATION AND RELEASE PLANNING

‘TE First ITERATION PLAN

‘Tue First Task ~ DETECTING INCO?

‘THE ORIGINAL SOLUTION

‘Ta First CHANGE CASE

THE SECOND CHANGE CASE

‘THE REMAINING TASKS

‘Tue CHANGE Cost CURVE

PRESENTING THE CHANGE Cost CURVES

EXPLAINING THE CHANGE Cost CURVES

IMPLICATIONS OF COST OF CHANGE smn

‘Ti: PROGRAM-SYNTACTIC DOMAWN

ALTERNATIVE SEMANTC DOMAINS

ɧÄGUM0NSsesmrmmrseessdmmmrrrmesmerson IBS

ASSEMBLY VERSUS HIGH-LEVEL LANGUAGES

TNTRODUCHON

OUTLINE OF TOUR DE FORC!

OUTLINE OF THE CHAPTER

'WHAT PROGRAMMIERS D0

LEARNING THE MEANING OF THE LANGUAGE

PROPOSING A TRIAL PROGRAM

EXECUTING A PROGRAM " 2

MACHINES AND LANGUAGES FOR LIST SORTING

THE PROGRAMMING LANGUAGES

“THỊ: FUNCTION-SEMANTIC DOMAIN

‘Ti EXECUTION-SEMANTIC DOMAIN

'THE MIND EMUL.ATING THE MACHINE

A Bruce Reviw O TH ACT-R SYSTEM

‘CustoMiziNG ACT-R INTO A MACHINE EMULATOR,

LEARNING THE MEANING OF THE LANGUAGE

PROPOSING A TRIAL PROGRAM

‘THE PROGRAMMERS” INTERFACE SPECIFICATIONS,

A METHOD FoR ESTIMATING COMMUNICATION

REQUIREMENTS Tạng he

ESTIMATING COMMUNICATION REQUIREMENTS

FALSIFYING CONWAY'S LAW

REINTERPRETING CONWAY'S LAW

A MONOLOGUE-BASED ORGANIZATION

ESTIMATING COMMUNICATION REQUIREMENTS

CoRRORORATING CONWAY'S LAW

FALSIFYING CONWAY'S LAW

REINTERPRETING CONWAY'S LAW

A SILENT ORGANIZATION

ESTIMATING COMMUNICATION REQUIREMENTS

CorronoraTinG Conway’s Law

COMPARING THE THREE ORGANIZATIONS sn

'CONCLUSION

One of the most well-known books on the topic of software engi- ncering, studied in numerous academic courses, is The Mythieal Man-Month by Frederick P Brooks This seminal book presents the author's experience from the development of the IBM tem/360 computer family and its software system, OS/360 The 20)" anniversary edition of the book is augmented with a list of propositions asserted in the original book ‘These include proposi- tions like the following,

a) Adling manpower ta a late software poryject makes it late (Brooks's Lam)

1) One estimating techniques, built around cos-avcuunting, confese

«fort and progres Tbe man-month ica fallaions and dangerous nth, fori implies that men and months are interchangeable,

A small sharp team is best— as fow minds as possible,

4) The rato of function to comes complexity isthe nltimate test

of system design, not just the richness of fimotion This ratio ab a measure of ease tows, valid over bath sinple and diffi nse

3) An architectural definition willbe chaner and the architectral dsiphne tighter if at kast to implementations are but inital

‘The Grand Unified Theory of Software Engineering

) Schednle disaster, etional mist, and system bigs all arse be- cause the Aff band doesn't know what the right hand is doing Teams drift apart in assumptions

1 One weeds bth a forma definition of «design, for precision, and

«4 prose definition for comprebensibilty

B) One of the formal and prow definitions mast be standard, and

‘the other devivatie, Ether definition can serve in ether rue

This list of propositions can be viewed as a set of theories of software engineering, If they are truc, they can be of significant value to software developers, because with these theories in the back of theie heads they will clearly be able to make better decisions than without them,

Upon penetrating the propositions deeper, we notice that many are based on similar underlying explanatory models For in stance, the first three propositions are based on the idea that it takes time and effort for people to leam new things, and it takes time and effort for people to communicate with each other Per- haps these three propositions could then actually be derived from some deeper theory about learning and communicating? And per- haps this deeper theory could explain even more than the three propositions? This isin fact the ease; learning and communication appear as explanatory factors in several additional propositions in The Mythical Man-Month (eg proposition f, above) 4 third moti vation for proposition b is that many tasks eannot be performed in parallel, so more people does not ly mean shorter time This is a question of organization of work, which also reappears as

an undeslying explanatory theory Proposition g and h highlight that some specifications languages are precise and some are easy to un- derstand, but few are both The underlying explanatory theory for these relates to languages and their interpretations

If it were possible to present a set of more fundamental ex- planatory theories than Brooks's propositions, then these theories would surely be even more useful? They would be able to explain why Brooks’s propositions are correct (or occasionally, false), but they would also be able to generate many more propositions; gen- erally applicable ones such as Brooks's, but also specific ones for specific situations and problems Although Brooks's propositions are of great use, there ate many problems we might face where they

do not help us, but where an argumentation fom the same underly- ing explanatory base could lead to a proposition that could indeed help us

The argument that we ase putting forth here is an argument for the benefits of a greater, a more fundamental, more compre- hensive theory of software engineering In 1975, when Brooks wrote his book, such a theory was hardly possible, but since then, the collective knowledge of software engineering has virtually cx: ploded Because the authors of this book believe that our discipline now has reached the scientific maturity for such an attempt, this book proposes a unified theory of software development

ANOTE ON THE TITLE

As the reader has surely noted, the title of this book is The Grand Unified ‘Theory of Software Engineering (GUTSE) Such a pteten tious tlle might be perceived as provocative, so it may be wise to explain its origins already in the eatly parts of the text

Physicists believe that there are four forces, of interactions, that affect matter in the universe: the strong force, the electromag: netic force, the weak force, and the gravitational force Each force hhas a theory that explains how it works It has long been a dream to combine these four theories into fewer Hinstein spent much of his later life trying to develop a unified theory (UT) that would com-

‘The Grand Unified Theory of Software Engineering

bine gravitation and electromagnetism ‘The theory resulting from the combination of the strong, weak and electromagnetic forces hi been called the grand unified theory (GUT), At the end of the sain bow lies the dream of combining all four forces The resulting, the- ony is often referred 10 as the Theory of Everything (TOR) The title of the present book is clearly inspired by this strive of the physicists

An alternative title to this book is A Theory of Software Engi neering, That title would, however, miss the important point of unity: So a more appropriate title would then be A Unified Theory

of Software Engineering, This would perhaps be an equally good title as the present, in the sense that the book indeed attempts to present one possible unified theory of software engineering, How- lever, one might argue hat even the addition of the word Grand keeps the title on the humble side, because the really pretentious title would be The Theory of Everything of Software Engineering, (TOESE)

‘THE IMPORTANCE OF A UNIFIED THEORY

According to the famous philosopher Thomas Kubn, scientific dis- ciplines go through life cycles First, there is no science at all, then comes pre-science, characterized among other things by debate over theory, This stage may be evolved into what Kuhn calls noe mul science, where there is one generally accepted paradigm Para- chưng may in tum be overthrown by scientific revolutions, leading,

to new paradigms

Theory

A central concept in science is the concept of theory When we speak of theory in this book, we simply mean a set of concepts and relations between them, As an example, a very simple theory may

state that for a software program, increases in modularity causes in- exeases in modifiabiliy The concepts here are the properties of

‘mocifiability and modularity The relation berween them is a causal relation where the value of one property changes as a result of changes in the value of the other

There are many quality characteristics of theories for instance,

a theory may’ be more of less encompassing, it may be more or less precise, it may be mote of less consistent The above example is a very limited theory with litle explanatory capacity It not very precise because it does not explain how to measure modularity oF modifabilly and it does not explain the size of the causal effect A

‘good quality of the theosy i that itis consistent with itself An in- teresting question for software engginecsing scientists is whether iis true; however, the theory itself doesn’t tll us this

Scientific Maturity and Theory

We may express Kuhn's view of science in terms of theory In normal science, there is one single unified theory in which every scientist believes In pre-seienee, there are several competing and conflicting, but unified theories In the no-science-at-all stag, there

is mass of micto-theories, some contficting with each other, some speaking of completely different things, and none unified

In the natural seiences, we are So accustomed to the normal- scientific paradigm, characterized by a single and unified theory, that we hardly think about it For instance, electromagnetic theory

és set by Maxwells four equations; there are no competing theories and all searchers agree on this unified theory of electsomagnet- fam In mechanics, there is an undisputed set of relations between concepts such as force, mass, acceleration, velocity and energy Be fore Binstein, there was anothes, Newtonian, set of relations that was equally undisputed ‘The Newtonian and the relativistic me- chanics as well electromagnetic theory constitute grand schemes linking together a set of concepts in a consistent manner, thus pro-

‘The Grand Unified Theory of Software Engineering

viding explanations to avast set of phenomena Bur not only in the natural seences do we find generally accepted unified theories For Jnstance, in economies, the theory of supply and demand is capable

of explaining a plethora of concepts related to pricing in perfect smuarkets, monopolies and monopsonies

Another interesting science is international relations, where there are many different unified theories ‘They are unified because the attempt to explain “the grand scheme”, but they are not undis puted, so international relations is in Kuhn’s pre-seience stage The

‘most prominent schisin les between the realist and the hberalist theories Both theories are capable of explaining the past and pre- dicting the futuee, but of course with varying outcome However, since it is not cleat which of the theories is best in accordance with realty, the schism has not yet been settled To complicate matters more, there are many competing theories within the two main theo- retical steands

Let us now compare the academic (and thus arguably scien- fife) discipline of software engineering to the ones mentioned above As of yet, the authors ofthis book have not come across any attempt to propose a coherent unified theory of software engineer fing, but rather a cluster of miceo-disciplines based on micro theories In fact, there are thousands of micso-theoees available in software engineering, There are theories explaining why the go to statement is harmful, cheories explaining why redundancy increases availabilty, theories explaining why modulasity increases modifiabil ity, theories explaining why formal specifications are better than natural language specification, theories explaining why natural lấn

‘guage specifications are better than formal specifications, theories explaining why iterative development reduces risk, and so on Many

Of the micto-theories are at odds with each other, many speak of different phenomena, and many speak similaly of simylar pheaom cna Interpreting Kuhn unfavorably, sofevare engineering would be

fn the no-science-at-all stage,

‘The Benefits of a Unified Theory

There are several merits with the strive for a unified theory Firstly,

«unified theory implies a common vocabulary, allowing software engineers to understand cach other Cusrently, there ate astounding numbers of definitions of many important concepts For instance, the homepage of the Software Engineering Institute presents 150 definitions of the concept of sonar ardietae We might suspect that misunderstandings are commonplace under these concltions

To further complicate the mater, most of the 150 definitions refer

to equally vague concepts, such as system, structure and compo- nent So even if two software engincers where 0 agree on one of the Software Engineering Institute sofmare ancbitecre definitions, they would probably not mean the same thing anyway OF course, software architecture is aot the only unclear concept; there is na generally agreed upon definition of the term sofnure engineering & ther, oF design or modifabiliy or sftrare prowss of almost any other concept

Secondly, without unified theory, software engineers and software engineering researchers will have difficulties seeing the big picture Operating systems people, eg will have problems under standing and will nat see the benefit of, research results in usability cagineering and vice versa, even though the evo disciplines at times

‘may have very much in common and results in one discipline might bbe very fruitful forthe other

Thiedly, and importantly, without a unified theory, there is no common base from which an argument may be made for or against some proposition about the state of the world I is equally aceept- able t0 present an argument based on sociological research on

‘group dynamics as one based on findings within solid state physies

as one based on results in fractal geometry This is problematic, be cause these scientific disciplines are not consistent with each other and may very well lead 10 opposing conclusions, and there is reall

no systematic way of telling which conclusion is correct In a good

‘The Grand Unified Theory of Software Engineering

unified theory, arguments will have the same foundation It may seem strange that truths from one disciplines cannot be invoked at wll in another discipline, but this is the case in all maeuce science:

it is a Kind of separation of concems In the realist theory of inter- national relation, for instance, all arguments are based on the a sumption that the relation between states is one of anarchy If someone were to object to this assumption, perhaps based on re- search in sociology, then the discussion would enter into a new arena with new ules for argumentation; from an intra-theoretieal discussion to an inter-theoretical diseussion It would then become

a discussion on the choice of theory In Kuha’s unified normal- scientific disciplines, such as electromagnetism, there are no inter- theoretical discussions This is of course very satisfying, because it provitles a strong base for reaching the same conclusions and few discussions need to end up in stalemates (at least in principle) In pre-scientific disciplines, the debaters are at least aware of when they move from the intra-theoretical arena to the inter-theoretical fone, thus maintaining a separation of concerns In software engi- neering, however, the lack of unified theories makes the distinction impossible and there are no real rules for separating sound argu ments from unsound ones It is consequently quite acceptable to pick any one of the thousands of micro-theories available to sup- port an argument and simply disregard the thousands remaining,

We can thus explain and predict everything and nothing

But the lack of unified theories does not mean that there is a lack of good knowledge within software engineering In the many micro-theories, the knowledge of a whole discipline is hidden Let

us consider some examples of micro-theories ‘There is a famous article explaining why the goto statement is considered haemful in programming languages [Dijkstra, 1968] By a simple model of the limits of human cognition — representing the mind as a stack mac chine — the author explains that it becomes much more complicated

to imagine how a progeam will behave the more goto statements it

contains The micro-theory here would be the model of human cognitive limitations that explains why gote’s are harmful

‘Then there are arguments for using decomposition as a strat- egy for software design, Some of these are also based on micto- theories of the cognitive limits of the mind, for instance those that say that people generally only can keep some limited number of concepts in mind at the same time These two micro-theories speak much of the same thing, namely how the limits of human cognition affect software development, so it would seem natural to trợ to combine them into a single not-quite-as-micro-theory with a higher explanatory capacity In fact, perhaps we could develop a single, coherent theory that explains even more than these two principles

‘This is the purpose of the present book; to present a coherent the- ory that can explain many things in software engineering It turns cout that the main questions that we will want the GUTSE to an- swer are “what are the characteristics of good software abstrac: tions?” and “what are the characteristics of good software onganiza-

THE WORLD ACCORDING TO THE GUTSE,

Two important properties of the world of software are that every thing is man-made and everything is intangible These two proper ties permeate the two main concepts in this world, specifications and transformers

Specifications and Transformers

Software programs ate specifications, eypically thought of as strings

Of symbols Design specifications, architecture specifications, re: quirements specifications, executable binary code are also all speci- fications These specifications are difficult to grasp for nvo reasons, Firstly, they do not depend on the physical medium on which they

uw

‘The Grand Unified Theory of Software Engineering

are stored A specification may be written down in ink on a piece of paper, or it may be stored electronically in a computer, or it may be written in the sand or even memorized by someone ‘The medium that stores the specification is not important, only that the “đ” comes before the “0” before the “g” The only thing that matters is thus the structure Secondly, specifications have no inherent mean- ing The specification “MOV 2F'57C300, AO” may mean that the contents of a byte of random access memory located at 2F57C (according to some internal memory addressing convention) should

be added to the register AO Or perhaps it means that the movie with the name 2I57C300 should be played with the audio volume

at zeto, Or perhaps it doesn’t mean anything, What a specification

‘means (or doesn’t mean) is in the eye of the beholder

And the beholders, those entities which consume and provide specifications, are the second main concept in this world of soft- ware, Equally frustrating, also these executors of specifications are intangible To start with, a software process, such as a Java Vietual Machine, is not only a consumer of Java Bytecode specifications; it

is also in itself an executing program specification, eg, the file with the name jvm.exe But if we explain the software process in terms

of a specification, then ¢his explanation only brings us back to the intanggbility of the specification, so we have gained nothing in con- creteness, Perhaps, then, we can become conerete by considering the executor of the executor ‘Typically, a Java Virtual Machine is executed by a hardware processor; surely this must be a firm base fon which we can base our discipline, Unfortunately, the relief of Finding something tangible is short-lived Because just like an elec- tric capacitor is constructed as a model of the ideal capacitor, a processor is a (physical) model of an ideal processor Ie is not im- portant chat the processor in a typical computer is implemented in silicon, for it could have been implemented using vacuum tubes, a small and nimble-fingered person, oF yet another software program

So also the processor is in this sense independent of the medium in which it is constructed In the words of Falsgar Dijkstra [Dij76}:

“Originally [viewed it as the Ranetion of the abstract mi chine to provide a tnuthful picace of the physical eal Later, horwever, Heared to consider the abstract machine asthe “true™

‘one, because that isthe only one we can “thinks iti the physical machine's purpose to supply “a working made! (hopeful!) su: ficiently accurate physical simulation of the tc, abstract ma chine

To put it differently, mankind has worked very hard to free it self from the consteaints of physical reality, and in the world of software, it has (basically) succeeded It is a man-made and intangi- ble world,

Minds and Machines

In the physical world of objects, the laws of nature apply ‘This is oftentimes inconvenient for us ~ sometimes even lethal ~ but if we wish to understand this world, we are in luck We are in fuck, be- cause it seems that itis possible to discover many of the laws that

‘govern material things; many of these laws seem to be surprisingly simple, and they seem to apply more or less everywhere Those of

us wishing to understand the artificial world of software can, unfor- tunately, not hope to employ the same strategy Since mankind has more of less succeeded! in freeing itself from the laws of nature, we have good reason to suspect that nature’s parsimony and generality were thrown out with the bathwater Laws that apply in the soft- ware world are artificial laws, i laws invented by fallible human minds So if we wish to understand the world of software, we will need to consider human minds

‘One way of viewing the software engineering endeavor is as the great human effort to speak to our machines In our minds lie cour desires and we know that some of them may be satisfied in the adificial world of software, We may desire to prosluce or collect in

‘The Grand Unified Theory of Software Engineering

formation, to conteol or supervise parts ofthe physical world, to be amused, to understand; many of our desires may be satisfied by software executing on computing machines Happily, our comput ing machines are more than willing to comply with oue desites As soon as we have told them what we would like them to, dhey will perform without the slightest complaint ‘They will indeed perform tasks that are so boring and task that are so complicated with such zeal and dedication that we can only marvel ‘There is seally only fone cateh Machines eannot read our minds, so we must carefull explain oue desites to the machines in a language that they wnder- stand Unfortunately, the languages of machines differ from the Tanguages of the mind In fact, they differ so much that many mil Kons of people today have as their main occupation to explain to the machines what we eeally want Since it is impossible to directly write down a machine code specification of, say, a modern word processor, the task has been divided into a set of activities, from the tation of our desires ~ requirements engineering ~ (0 extensive conteols that the machine really understood what we tied tớ cx- plain ~ testing Some of these activites are performed by minds and some are pesformed by machines Returning to the main line of| aggumentation, it becomes clear that the main underlying compo nents of a theory of software engineering must be based on minds, machines and the languages they use

We do not believe that its controversial to claim that we need

to understand computing machines and specification languages to understand sofiwate engineering We therefore posit these as main components of a theory of software engineering However, the in- corporation of the human mind might be considered more alarming

to some readers However, without a stringent consideration of the people in the peocess, the software engineering world is only half

In a discipline created by and for engineers, i s peshaps a natural cautionary tendency t0 avoid those uncomfortable problems that sight appear when people enter the arena, ‘The authors agrce with

these cautious souls in that many accounts on the “people aspects”

of software development have, in lack of a theoretical base, been forced to mainly anecdotal support for theie propositions, How ever, we may find inspiration in some other scientific disciplines that have managed to take the mind into account without reli quishing all control ‘Take, for instance, the concept of the eco- nomic man, homo econonricns, this is a theoretical consteuct that al- lows a reasonable treatment of human behavior in economic the ory Economie man is an extreme simplification of a human mind;

he is completely rational, he always has perfect information, he al- ways knows exactly what he wants, and he is completely egoistical

No sane person believes thac this man actually exists, but with this extremely abstracted concept, i possible to explain and predict a surprising number of phenomena within the economic sciences It

is also clear that this coarse approximation will only be valid in cer- tain domains, The concept of economic man cannot, for instance, explain of predict the nature of relations within a family; one reason that fumily life rarely is completely characterized by individual egoism However, the usefulness of economic man should not be juudged by what it cannot explain, bue by what it can explaén,

Modified models of the human mind have been proposed to extend the domain of inquiry, including administeative man, having, Limits to his mental powers; contractual man, capable of lying, steal- ing and cheating; and more ‘This book prescnts a similar controlled inclusion of the mind as a component in a theory of software engi neering, the programming man, bono prognunatcn

LEVELS ON WHICH TO ACCEPT THE GUTSE

This book proposes a specific theory of software engineering However, it would be unfortunate if the reader experienced only

‘so options when relating to the book: accept or reject In particu-

l5

‘The Grand Unified Theory of Software Engineering

las, it would be unfortunate if the reader rejected the overarching concepts because he or she disagreed with the more detailed mat- ters Therefore, we would like to suggest some different levels on which the book could be accepted (or rejected)

‘The first and most important proposition herein is that there

is good reason to strive for a unified theory of software engineer- ing This has been argued for above and is implicit in the rest of the book The second most important proposition is that the ewo main pillars of such a theory ate the mind and the machine, Beyond those to main propositions, acceptance or rejection may be on various parts of the theory Perhaps some readers would have pre- fereed a more formalized theory, while others would have liked a Tess restricted version; perhaps some would like a different repre- sentation of the mind; perhaps some would argue tha

have been a stronger focus on the social nature of software devel- opment,

‘The philosopher of science Karl Popper, whose scientific ide- als have had great impact on the contemporary view of research, declared that if a theory ever in any singular case was proven wrong, then the whole theory would have to be completely dis carded, This uncompromising position was objected to by Imre Lakatos, who instead claimed that scientific evolution is ineremental and iterative, According to Lakatos, a theory is proposed much like

a software application As many sofeware engineers (and users) have experienced, the fist release may be less than perfect, but if the main concept is good enough, then the whole application will not

be discarded, but a second and improved release will instead follow This second release might incorporate more functionality, but it will surely attempt to correct the worst flaws of the first one, The a thors of this book adhere to the view of Lakatos It is very unlikel that the first release of the theory presented in this book is lawless,

it is quite sufficient if the main concept tums out to be good enough

‘THE QUALITY OF A THEORY

‘There are good theories and there are bad ones, and whether a the-

ry belongs to the former or latter category depends on a number

of its properties Firstly, the theory should have an unprecedented definitional and explanatory capacity Le if a theory aleeady exists that can explain and define all things covered by the new theory, then the new theory is of questionable value Secondly, the theory should be internally consistent, ic i should not contradict itself Thiedly, the theory should be falsifiable It should be possible to perform investigations (eg experiments) that may prove the theory wrong Fourthly, the theory should be as simple as possible (pars mony), Finally, the scope of the theory should be defined Although all of these properties have been aimed for, in developing the GUTSE, the authors have held some criteria of goodness higher than others The three most driving ones have been explanatory cac pacity, parsimony, and internal consistency

"A wide explanatory capacity was important because without this property, the GUTSE would end up as just another micro- theory Therefore, fundamental concepts needed to be defined, such as software development, design, component, program, model, testing, architecture, process, and many more, General truths of sofeware engineering should also be explainable, including why sofiware development is organized the way it is, why decom- position and abstraction are employed as centeal strategies, why leg- acy software is a problem, how tools support software develop ment, why certain specification languages are good and others are bad, why certain platforms are good and others are bad, why cer- tain software processes are good and others are bad, why many lan-

‘guages are employed in a software development project, why soft ware development projects generally fal, ete:

The GUTSE may be criticized for being naively simplistic in a complex world We believe in parsimony for three reasons Firstly,

a simple theory is easier to apply than a complicated one Few peo-

‘The Grand Unified Theory of Software Engineering

ple attempt to employ the Schrddinger equation for quantum me- chanical behavior o other fundamental laws of physies when ex- plaining biological phenomena such as the workings of the cascho vascular system of frogs Not because the fundamental laws cannot esplain these things but because their explanation is far too compli- cated Secondly ancl related, if a theory cannot be applied, i eannot bee tested, and if it cannot be tested, this becomes a problem with regaeds (0 its falsifiabiity, Thiedly, a complex theogy fs ficult to rmunage Iti difficult to understand it and itis difficult to examine its internal consistency In the search for parsimony, we have cho- sen a perspective that disregards many concerns, such as power ambitions, gender issues, etc, that do have an influence on the software engineering situation This choice of perspective will have

an impact on what we ean speak of with the GUISE in a meaning- ful manner

‘On the other hand, the theory may be criticized for being too detailed and thus too limited We do, for instance, incorporate a theory of the mind called ACT-R, although we may not need all thar comes with this theory We do however believe that we ean prove our point better using conerete instances than solely general arguments With respect to the detail, it i important to remember and understand the different level of acceptance of the GUISE

‘The reader may not agree with the details, but accept the main co cept Such a result would not be viewed as a fulure by the authors Internal consistency has been important since the lack of this, property in the large ser of micto-theories currently avaiable was a major driving foree for the development of the theo: Stiving foe internal consistency, we have aimed for transparency, clarity, and again, parsimony We have thus attempted to base the theory on a Emited set of well-defined concepts, clearly present the relations between these, and relate additional terminology to these funda-

18