THE CHRONIC SOFTWARE ENGINEERING CRISIS - PowerPoint PPT Presentation

1 / 33
About This Presentation
Title:

THE CHRONIC SOFTWARE ENGINEERING CRISIS

Description:

THE CHRONIC SOFTWARE ENGINEERING 'CRISIS' By Walter Maner. DIJKSTRA 'To put it quite bluntly: as long as there were no machines, programming was no ... – PowerPoint PPT presentation

Number of Views:109
Avg rating:3.0/5.0
Slides: 34
Provided by: walter115
Category:

less

Transcript and Presenter's Notes

Title: THE CHRONIC SOFTWARE ENGINEERING CRISIS


1
THE CHRONIC SOFTWARE ENGINEERING CRISIS
By Walter Maner
2
DIJKSTRA
To put it quite bluntly as long as there were
no machines, programming was no problem at all
when we had a few weak computers, programming
became a mild problem, and now we have gigantic
computers, programming has become an equally
gigantic problem."
-- E. Dijkstra, 1972 Turing Award Lecture
3
THE CONCEPT OF SOFTWARE ENGINEERING
  • Software engineering is
  • the technological and managerial discipline
  • concerned with systematic production and
    maintenance of
  • quality software
  • that meets the user's needs and
  • is delivered on time and
  • within budget.

4
BIRTH OF THE TERM "SOFTWARE ENGINEERING"
  • The term "software engineering" was coined by a
    NATO study group in 1967
  • Four decades later, it still hasn't earned a
    reputation as an engineering discipline

5
Software Engineering is LIKE ENGINEERING
  • Both are dependent on advances in technology.
  • Both are labor intensive.
  • Both are pragmatic disciplines in the sense that
    they apply theory to particular situations.
  • Both produce technological artifacts.
  • Both rely on skilled teams.

6
Software Engineering is LIKE ENGINEERING
  • Both require some form of analysis, design,
    construction, testing and maintenance.
  • Both try to learn from failures.
  • Both try to repeat procedures that work.
  • Both use computer-aided tools (CASE, CAD)
  • Both use engineering approaches to
    problem-solving (e.g., engineering notations).

7
Software Engineering is UNLIKE ENGINEERING
  • Software regularly violates the law of
    proportionality that governs every other
    engineering discipline.
  • Small changes may produce disproportionately
    large or even catastrophic effects.
  • Advances is software technology occur at a pace
    too fast for us to master.
  • Developers cannot rely on established best
    practices that have withstood the test of time.

8
Software Engineering is UNLIKE ENGINEERING
  • During maintenance, software undergoes changes so
    radical that they alter the fundamental
    architecture of the system.
  • It is hard to identify development practices that
    can be repeated with the same (or greater) level
    of success.
  • Progress is hard to measure (but CMM tries).

9
Software Engineering is UNLIKE ENGINEERING
  • Few good standard components are available
    off-the-shelf, forcing developers to custom-build
    many component parts.
  • The technological artifact produced by software
    developers is nearly invisible during
    construction (prototyping helps).
  • There are apparently no physical laws that govern
    the construction of software.

10
Software Engineering is UNLIKE ENGINEERING
  • Lack of universal standards governing how
    software components should interface to other
    components.
  • Time and costs are hard to estimate.
  • There is no SINGLE technical notation that can be
    used throughout the entire process of software
    development.
  • Software engineers are not bonded or licensed
    (but this is changing).

11
PreviewTHE PRODUCTIVITY CRISIS IN SOFTWARE
ENGINEERING
  • Time To Develop A Program
  • What Programmers Do With Their Time
  • What Programmers Produce
  • Mistakes Programmers Make

12
TIME TO DEVELOP LARGE PROGRAM
  • gt 512K lines
  • gt 100 programmers
  • 48-60 months

13
TIME TO DEVELOP MEDIUM PROGRAM
  • 64 K lines
  • 5-10 programmers
  • 12-23 months

14
WHAT PROGRAMMERS DO WITH THEIR TIME
  • 13 writing programs
  • 32 job communication

15
WHAT PROGRAMMERS PRODUCE
  • Systems programmers
  • 1 LOC/day
  • Utility programmers
  • 5-10 LOC/day
  • Applications programmers
  • 25-100 LOC/day
  • Overall average for medium-sized programming
    project
  • lt 10 LOC/day

Boehm, B. (1981). Software Engineering
Economics. Englewood Cliffs, NJ Prentice-Hall,
Inc
16
COST PER LOC
  • 50 to 400according to Boehm and Standish, 1983

17
LOC GROWTHWindows NT
Doubling time 866 days Growth rate 33.9 per year
18
LOC GROWTHWeb Browser
Doubling time 216 days Growth rate 221 per year
19
MISTAKES PROGRAMMERS MAKE PER KLOC
  • Errors found in code during development
  • 50-60 per KLOC
  • Errors found in delivered code
  • lt 4 per KLOC (still a lot!)

Mills, H., Dyer, M, and Linger, H. (Sept 1987).
IEEE Software
20
SOFTWARE COST TRENDS RELATIVE TO GNP
  • 1980 5 of GNP
  • 1985 8 of GNP
  • 1990 13 of GNP
  • 1995 21 of GNP
  • 1998 38 of GNP
  • 2007 ?? of GDP

Cost total cost of ownership
Early data from Gibbs, W. Software's Chronic
Crisis. Scientific American. Sept 1994 later
data from Fortune Magazine
21
1979 GAO STUDY OF SOFTWARE BUILT FOR GOVT
  • gt 60of government contracts had schedule
    overruns
  • gt 50 of government contracts had cost overruns
  • gt 29 of software was never delivered
  • gt 19 of software had to be fixed in-house
    before use
  • 2 of software was usable as delivered

Comptroller General. (1979). Contracting for
computer software development. General
Accounting Office Report. (FGMSD-80-4).
Washington, D.C.
22
1994 STANDISH GROUP SURVEY OF 352 COMPANIES
  • 31 of all software projects are canceled
    before completion
  • 53 of projects will cost 189 of estimates
  • 9 of projects come in on time, on budget
    (large firms)
  • 16 of projects come in on time, on budget
    (small firms)

http//www.standishgroup.com/sample_research/chaos
_1994_1.php
23
Standish Group Research Cost Overrun Data
24
Standish Group Research Time Overrun Data
25
Standish Group Research Dropped Feature Data
26
Standish Group Research Factors Making SD
Difficult
27
Standish Group Research Factors Making SD Fail
28
Standish Group Research Are We Improving?
29
Software Engineering InstituteCMM Data
The Capability Maturity Model for Software is a
model for judging the maturity of the software
processes of an organization. The model defines
five level of maturity and specifies what
processes that must by in place to achieve those
levels.
30
Data from Ed YourdonRise and Resurrection of the
American Programmer (1996)
The difference between the best and worst was
101 in 1990, but was 1001 in 1995
31
Standish Group Research New Data
32
Standish Group Research New Data
33
DEFECT COSTS
  • The US Department of Commerce estimates that
    software defects cost the US economy 60 Billion
    per year

Infoworld, June 2002
Write a Comment
User Comments (0)
About PowerShow.com