01 History of Software Engineering
Transcript of 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*
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*
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*
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
2012 by Vclav Rajlich*
2012 by Vclav Rajlich
-
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*
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*
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*
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
2012 by Vclav Rajlich*
2012 by Vclav Rajlich
-
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*
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*
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*
2012 by Vclav Rajlich
-
Exponential cost of changemajor contributor to software cost 2012 by Vclav Rajlich*
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*
2012 by Vclav Rajlich
-
Waterfall paradigmElaborate up-front activitiesBDUF (Big Design Up Front)
TextbooksStill largely based on the waterfall 2012 by Vclav Rajlich*
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
2012 by Vclav Rajlich*
2012 by Vclav Rajlich
-
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*
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*
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*
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*
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*
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*
2012 by Vclav Rajlich
*********************