Computing and se ii chapter 2 a brief history of se
This presentation is the property of its rightful owner.
Sponsored Links
1 / 50

Computing and SE II Chapter 2: A Brief History of SE PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on
  • Presentation posted in: General

Computing and SE II Chapter 2: A Brief History of SE. Er-Yu Ding Software Institute, NJU. A View of 20 th and 21 st Century Software Engineering. Barry Boehm ICSE 2006 Keynote Address May 25, 2006 [email protected] http://sunset.usc.edu. Modified by Er-Yu Ding. Outline.

Download Presentation

Computing and SE II Chapter 2: A Brief History of SE

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Computing and se ii chapter 2 a brief history of se

Computing and SE II Chapter 2: A Brief History of SE

Er-Yu Ding

Software Institute, NJU


A view of 20 th and 21 st century software engineering

A View of 20th and 21st Century Software Engineering

Barry Boehm

ICSE 2006 Keynote Address

May 25, 2006

[email protected]

http://sunset.usc.edu

Modified by Er-Yu Ding


Outline

Outline

Motivation and Context

A 20th Century View

A 21st Century View

Conclusions

Timeless principles and aging practices


Motivation and context

Motivation and Context

Importance of historical perspective

We are losing our history


Why software projects fail average overrun 89 9 on cost 121 on schedule with 61 of content

Why Software Projects Fail- Average overrun: 89.9% on cost, 121% on schedule, with 61% of content


Importance of historical perspective

Importance of Historical Perspective

Santayana half-truth:

“Those who cannot remember the past are condemned to repeat it”

Don’t remember failures?

Likely to repeat them

Don’t remember successes?

Not likely to repeat them

Our objectives

Understanding SE more deeply

Organizing important techniques/methods/methodologiesof SE systematically


A hegelian view of software engineering evolution

A Hegelian View of Software Engineering Evolution


Outline1

Outline

Motivation and Context

A 20th Century View

A 21st Century View

Conclusions

Timeless principles and aging practices


1950 s thesis engineer software like hardware

1950’s Thesis: Engineer Software Like Hardware

Hardware-oriented:

Software applications: airplanes, bridges, circuits

Economics: Boehm supervisor, 1955

“We’re paying $600/hour for that computer, and $2/hour for you, and I want you to act accordingly.”

Software Processes: SAGE (Semi-Automated Ground Environment)

1 MLOC air defense system, real-time, user-intensive

Successful development of highly unprecedented system

Hardware-oriented waterfall-type process


Computing and se ii chapter 2 a brief history of se

The SAGE Software Development Process - (Benington, 1956)“We were successful because we were all engineers”.


1950 s thesis engineer software like hardware1

1950’s Thesis: Engineer Software Like Hardware

Software Techniques:

Machine-Centric Application

For special usage, research mainframes

1GL, 2GL

Organization software with statements

Coding tips for a optimized program are important


1960 s techniques progress

1960’s, techniques progress

Complier can optimizing statements well

Organizing program with function

Function was derived from λ calculus

software get more complex


1960 s antithesis software is not like hardware four brooks factors plus two

1960’s Antithesis: Software Is Not Like Hardware- Four Brooks factors plus two

Invisibility: like the Emperor’s Magic Cloth

Visibility and controllability of project is always a topic of SE

Complexity: we have see this last lecture

Conformity: executed by computers, not people

Changeability: up to a point, then becomes difficult

Doesn’t wear out: different reliability, maintenance phenomena

Unconstrained: can program antigravity, time travel, interpenetration, …


1960 s antithesis software crafting

1960’s Antithesis: Software Crafting

Flexible materials, frequent changes as above

SW demand exceeded supply of engineers

Cowboy programmers as heroes

Code-and-fix process

Hacker culture (Levy, 1984)

Judge programmers by the elegance of their code


1960 s progress and problems

1960’s Progress and Problems

Better infrastructure: OS, compilers, utilities

Computer Science Departments

Product Families: OS-360, CAD/CAM, math/statistics libraries

Some large successes: Apollo, ESS, BofA check processing

Problems: 1968, 1969 NATO Reports

Failure of most large systems

Unmaintainable spaghetti code

Unreliable, undiagnosable systems


1970 s antithesis formal and waterfall approaches

1970’s Antithesis: Formal and Waterfall Approaches

Structured Methods

Structured programming (Bohm-Jacopini: GO TO unnecessary)

Formal programming calculus: Dijkstra, Hoare, Floyd

Formalized Top-Down SP: Mills, Baker

Waterfall Methods

Code and fix too expensive (100:1 for large systems)

Precede code by design (De Marco SD, Jackson JSD/JSP)

Precede design by requirements (PSL/PSA, SA, SREM)


1970 s antithesis formal methods

1970’s Antithesis: Formal Methods

“formal methods” branch that focused on program correctness, either by mathematical proof, or by construction via a “programming calculus”

Over the decade of the '60s theoretical computer science achieved standing as a discipline recognized by both the mathematical and the computing communities, and it could point to both applications and mathematical elegance


1970 s formal methods

1970’s: Formal Methods

Organized programs with

Function

Algorithm

Three control logic

Type and type check

When compiler deal with functions well, organized programs with

Modularity

This things gets importance with modularity

Information hiding

Data abstraction


1970 s formalized top down sp

1970’s: Formalized Top-Down SP

Function decomposition

divide and rule

Process modeling

DFD

Data modeling

ERD


Increase in software cost to fix vs phase 1976

Increase in Software Cost-to-fix vs. Phase (1976)

1000

1000

Larger Software Projects

500

500

IBM-SSD

GTE

200

200

100

100

80%

Relative cost to fix defect

Relative cost to fix defect

Median (TRW Survey)

50

50

20%

SAFEGUARD

20

20

Smaller Software Projects

10

10

5

5

2

2

1

1

Requirements Design Code Development

Requirements Design Code Development

Acceptance Operation

Acceptance Operation

test

test

test

test

Phase in Which defect was fixed

Phase in Which defect was fixed


The royce waterfall model 1970 explicit feedback do it twice

The Royce Waterfall Model (1970)- Explicit feedback- “Do it twice”


1970 s problems with formal methods

1970’s: Problems with Formal Methods

Successful for small, critical programs

Largest proven programs around 10 KSLOC

Proofs show presence of defects, not absence

Defects in specification, proofs happen

Scalability of programmer community

Techniques require math expertise, $500/SLOC

Average coder in 1975 survey:

2 years of college, SW experience

Familiar with 2 languages, applications

Sloppy, inflexible, in over his head, and undermanaged


Large organization hw sw cost trends 1973

Large-Organization HW/SW Cost Trends (1973)


1970 s problems with waterfall model

1970’s: Problems with Waterfall Model

Overly literal interpretation of sequential milestones

Prototyping is coding before Critical Design Review

Mismatch to user-intensive systems

Heavyweight documentation hard to review, maintain

7 year project with 318% requirements change

Milestones passed but not validated

Mismatch to COTS, reuse, legacy SW

Bottom-up vs. top-down processes


A hegelian view of software engineering evolution1

A Hegelian View of Software Engineering Evolution


1980 s synthesis productivity reuse objects

1980’s Synthesis: Productivity, Reuse, Objects

Worldwide concern with productivity, competitiveness

Japanese example: autos, electronics, Toshiba SW reuse

Major SW productivity enhancers

Working faster: tools and environments

Working smarter: processes and methods

Work avoidance: reuse, simplicity; objects

Technology silver bullets: AI, transformations, DWIM, PBE

Do what I mean; programming by example


Tools environments and process

Tools, Environments, and Process

1970s, some requirements and design tools developed, significant tool progress had been mode in such areas as test tools and SCM tools

Major emphasis in 1980s was on integrating tools into support environments: IPSEs to CASEs

Integrated Project Support Environment, Computer Aided Software Engineering

Requirements, design, planning and control, office support

Formatted vs. formal specifications

1980s: Resource estimations and middleware is underway

Process-driven CASEs

Use process knowledge as tool integration framework

Some overkill in locking people into roles


Process industrial engineering

Process: Industrial Engineering

Frederick W. Taylor : scientific management

First. They develop a science for each element of a man's work

Second. They scientifically select and then train, teach, and develop the workman

Third. They heartily cooperate with the men so as to insure all of the work is being done in accordance with the principle of the science which has been developed.

Fourth. There is an almost equal division of the work and the responsibility between the management and the workmen.


Process

Process

Process execution support: “SW processes are SW too”

What’s good for products is good for processes

Reuse, prototyping, architecture, programming

Process compliance support: Standards and CMMs


Reuse mechanical engineering

Reuse: Mechanical Engineering

In modular software, clearly the "standardized units or dimensions" should be standards such that software modules meeting the standards may be conveniently fitted together (without "trimming") to realize large software systems. The reference to "variety of use" should mean that the range of module types available should be sufficient for the construction of a usefully large class of programs.


Reuse and object orientation

Reuse and Object Orientation

1950’s: Math routines, utilities

1960’s: McIlroy component marketplace, Simula – 67

1970’s: Abstract data types, Parnas program families

1980’s: Smalltalk, Eiffel, C++, OO methods, reuse libraries

1990’s: Domain engineering, product lines, UML, components, patterns, pub-sub architectures, etc.

2000’s: Model driven development, service oriented architectures


No silver bullet brooks

No Silver Bullet: Brooks

Automated solutions are good for “accidental” software problems

Simple inconsistencies, noncompliance, inferences

They do not do well on “essential” software problems

Changeability: adapting themselves to unanticipated changes

Conformity: working out everything the computer needs to “know”

Devoid of intuition, commonsense reasoning

Complexity: integrating multiple already- complex programs

Invisibility: communicating their likely behavior to humans

Closest thing to silver bullet: great designers


People the most important factor sw engineering is of the people by the people and for the people

People: The Most Important Factor- SW engineering is of the people, by the people, and for the people

1970’s: Weinberg Psychology of Computer Programming

1980’s: DeMarco-Lister Peopleware

1990’s – 2000’s: Importance emphasized in both Agile and CMM cultures

Individuals and interactions over process and tools

People CMM, Personal Software Process, Team Software Process


Dual 1990 s now software progress

Dual 1990’s – Now: software progress

1950s-1960s: machine-centric software

1960s-1980s: application-centric software

1990s-now: enterprise-centric software

Distributed, large-scale

Design patterns, Software architectures, UML

Requirement engineering

Middleware, Components, CDE, Product Line, COTS, etc.

Collaborative development environment, Commercial off the shelf

Future?

domain-centric software

Components, Product Line, COTS


Dual 1990 s early 2000 s software techniques

Dual 1990’s – Early 2000’s: software techniques

OO methods were strengthened through

OOP ( Java )OO Design (1995)OO Analysis

UML

OO design principles

Design patterns


Dual 1990 s early 2000 s antithesis maturity models and agile methods

Dual 1990’s – Early 2000’s Antithesis:- Maturity Models and Agile Methods

Predictability and Control: Maturity Models——CMMI

Reliance on explicit documented knowledge

Heavyweight but verifiable, scalable

Time to Market and Rapid Change: Agile Methods

Reliance on interpersonal tacit knowledge

Lightweight, adaptable, not very scalable


Other 1990 s early 2000 s developments

Other 1990’s – Early 2000’s Developments

Y2K and reverse engineering

Mature risk-driven software model: RUP

Rational unified process

Nature and importance of software architecture

Usability and Human-Computer Interaction

COTS, open source, and legacy software

Software as the primary competitive discriminator


Open source and legacy

Open source and legacy

Open source

From its roots in the hacker culture of the 1960’s

Collective code ownership

Free software, data, computing access

Free Software

Linux

Raymond’s “The Cathedral and the Bazaar”

Legacy

EAI (enterprise application integration), BPR (business process reengineering)

Components and COTS are their future


Cots the future is here

COTS: The Future Is Here

Escalate COTS priorities for research, staffing, education

Software is not “all about programming” anymore

New processes required

*

  • CBA: COTS-Based Application

  • * Standish Group CHAOS 2000 (54%)


Mid 2000 s synthesis risk driven hybrid products and process

Mid-2000’s Synthesis: Risk-Driven Hybrid Products and Process

Increasing integration of systems engineering and SW engineering

Increasing trend toward “soft systems engineering”

Increasing focus on usability and value

Fit the software and hardware to the people, not vice versa

Model-driven development and service-oriented architectures


Outline2

Outline

Motivation and Context

A 20th Century View

A 21st Century View

Conclusions

Timeless principles and aging practices


The future of systems and software

The Future of Systems and Software

Eight surprise-free trends

Increasing integration of SysE and SwE

User/Value focus

Software Criticality and Dependability

Rapid, Accelerating Change

Distribution, Mobility, Interoperability, Globalization

Complex Systems of Systems

COTS, Open Source, Reuse, Legacy Integration

Computational Plenty

Two wild-card trends

Autonomy Software

Combinations of Biology and Computing


Outline3

Outline

Motivation and Context

A 20th Century View

A 21st Century View

Conclusions

Timeless principles and aging practices


Timeless principles and aging practices

Timeless Principles (+) and Aging Practices (-)

From the 1950’s

+Don’t neglect the sciences

+Look before you leap (avoid premature commitments)

Avoid inflexible sequential processes

From the 1960’s

+Think outside the box

+Respect software’s differences

-Avoid cowboy programming


Timeless principles and aging practices1

Timeless Principles (+) and Aging Practices (-)

From the 1970’s

+Eliminate errors early

+Determine the system’s purpose

Avoid top-down development and reductionism

From the 1980’s

+These are many roads to increased productivity

+What’s good for products is good for processes

-Be skeptical about silver bullets


Timeless principles and aging practices2

Timeless Principles (+) and Aging Practices (-)

From the 1990’s

+Time is money and value to people

+Make software useful to people

Be quick, but don’t hurry

From the 2000’s

+If change is rapid, adaptability trumps repeatability

+Consider and satisfice all of your stakeholders’ value propositions

-Avoid falling in love with your slogans


Timeless principles and aging practices3

Timeless Principles (+) and Aging Practices (-)

For the 2010’s

+Keep your reach within your grasp

+Have an exit strategy

Don’t believe everything you read

“It’s true because I read it on the Internet”


The end

The END

Recommend papers

A View of 20th and 21st Century Software Engineering

Fifty Years of Progress in Software Engineering

Finding a History for Software Engineering

Next Lecture

Software developments activities


  • Login