01 History of Software Engineering

1 History of software engineeringSoftware is everywherebuying bread, driving car, washing clothessynonyms: programs, applicationsPeople, who develop the softwaresoftware engineers, software developers, programmersthey possess skills and tools that allow them to develop and evolve software 2012 by Vclav Rajlich*

2012 by Vclav Rajlich

Difficulties that programmers faceAccidental difficultiesdifficulties of current/ past/ future technologies quirks of the operating systems, compilers, languages, processesthey come and go Essential difficulties of softwaresubset of essential (defining) propertiesno easy answers to essential difficulties !!!

2012 by Vclav Rajlich*


Essential difficultiesInvisibilitysenses cannot be easily used in comprehensionvisualizations, sonifications, require lots of work

Complexityprograms are among most complex systems ever created our short-term memory accommodates only ~7 things

Changeabilitysoftware is constantly changingyesterdays comprehension may be obsolete 2012 by Vclav Rajlich*


Essential difficulties, cont.ConformityLarge system (hardware, users, domain)The program glues it all together, reflects the large systemThis adds even more complexityDiscontinuityPeople easily understand linear or semi-linear systems: showerSoftware is discontinuous, small change on input can result in huge change of output: password 2012 by Vclav Rajlich*


Software engineeringSet of recommendations how to develop softwaresoftware is a result of software engineering

A discipline with a considerable body of knowledge and considerable importance in both academia and industry



Beginning of softwareSoftware separated from the hardware in 1950semerged as a distinct technologybecame independent product

Original programmers recruited from the ranks of hardware engineers and mathematicians used ad-hoc techniques from their former fields 2012 by Vclav Rajlich*


ParadigmThomas S. KuhnThe Structure of Scientific RevolutionsParadigm Coherent tradition of scientific research includes law, theory, application, instrumentation, terminology, research agenda, textbooks, norms, curricula, culture of the field not only the ideas, but also investmentcurrently overusedobject oriented paradigm, etc. 2012 by Vclav Rajlich*


AnomalyAnomaly is an important fact that directly contradicts the old paradigm

Dilemma: disregard anomaly vs. paradigm shiftto shift paradigm means to abandon large part of the investmentthe anomaly must be compelling 2012 by Vclav Rajlich*


Paradigm shiftDiscontinuity in the development of the discipline (revolution)Kuhn collected extensive historical data on paradigm shiftphlogiston - > oxygen in 1770s Lavoisier



Resistance to paradigm shiftAdvantages of the new paradigm is in disputeattempts are made to extend old paradigm to accommodate anomaliesband-aid approaches try to fix old paradigmKnowledge and investment accumulated up to that point may lose its significance some knowledge may be completely lost (knowledge of color of the chemical compounds)Final victory of the new paradigm guaranteed by a generation changeUnsuccessful attempts at paradigm shift 2012 by Vclav Rajlich*


Paradigm shift of ~ 1970AnomalyPrevious techniques did not scale upBrooks: Mythical Man-Month demands of the new operating system OS/360 taxed the limits of the programmers, project managers, and the resources of the IBM corporation

Paradigm shift established discipline of software engineering dealt with complexity of softwaresoftware design established as an important considerationintroduced the waterfall metaphor 2012 by Vclav Rajlich*


Waterfall metaphor (linear process)Used in construction and manufacturingcollect the requirements create a design follow the design during the entire constructiontransfer finished product to the user solve residual problems through maintenance

Intuitively appealing metaphorgood design avoids the expensive late reworkwaterfall became the dominant paradigm 2012 by Vclav Rajlich*


Exponential cost of changemajor contributor to software cost 2012 by Vclav Rajlich*


Chart2

1

1.5

2.25

3.375

5.0625

7.59375

11.390625

17.0859375

25.62890625

38.443359375

57.6650390625

86.4975585938

129.7463378906

194.6195068359

291.9292602539

437.8938903809

656.8408355713

985.2612533569

Time

Cost

Sheet1

1

1.5

2.25

3.375

5.0625

7.59375

11.390625

17.0859375

25.62890625

38.443359375

57.6650390625

86.4975585938

129.7463378906

194.6195068359

291.9292602539

437.8938903809

656.8408355713

985.2612533569

1477.8918800354

2216.8378200531

3325.2567300796

4987.8850951195

7481.8276426792

11222.7414640188

Sheet1

Time

Cost

Sheet2

Time

Cost

Sheet3

Waterfall model RequirementsDesignImplementationMaintenancetransfer to the user 2012 by Vclav Rajlich*


Waterfall paradigmElaborate up-front activitiesBDUF (Big Design Up Front)

TextbooksStill largely based on the waterfall 2012 by Vclav Rajlich*


Anomaly of Requirements volatility30% or more requirements may change during development (Cusumano and Selby) this is the direct result of the teams learning process and software interoperability

Caper-Jones: Requirements for IT change at a rate 2 3% per month



Standish group anomalyIn 199531% of all software projects were cancelled53% were challenged (completed only with great difficulty, with large cost or time overruns, or substantially reduced functionality)only 16% could be called successful

Obviously, the waterfall metaphor did not solve the problems of software development 2012 by Vclav Rajlich*


Band-Aid: Anticipation of changesIf changes can be anticipated at design time, they can be controlled by a parameterization, encapsulations, etc.waterfall model still can be used Experience confirms: many changes are not anticipated by the original designers inability to change software quickly and reliably means that business opportunities are lostonly a band-aid solution 2012 by Vclav Rajlich*


Band-Aid: PrototypingCreate a prototype to capture requirements

Problem: volatility continues after prototype has been completed

Another band-aid 2012 by Vclav Rajlich*


Paradigm shift of ~ 2000New life span models emphasize software evolution staged model of software lifespanbased on data from long-lived systems Iterative developmentRational Unified ProcessAgile developmentSCRUMExtreme programming 2012 by Vclav Rajlich*


Summary of paradigms

The waterfall paradigm tried to freeze requirements for the duration of software development led to too many project failures

The new paradigm emphasizes software evolution and iterationinteroperability and complexity cause volatilityvolatility is a consequence of essential properties 2012 by Vclav Rajlich*


All three paradigms currently coexistAd hoc paradigm still used by some single programmersprogramming as an art rather than engineeringexample: small games Waterfall works if there is no volatilitysmall or short-lived projectsunusually stable requirements and environmentssome managers still insist on itIterative paradigm is the mainstream 2012 by Vclav Rajlich*


*********************

Documents

01 History of Software Engineering