16.355 Software Engineering Conceptssunnyday.mit.edu/16.355/classnotes-intro.pdf · Prof. Nancy...
Transcript of 16.355 Software Engineering Conceptssunnyday.mit.edu/16.355/classnotes-intro.pdf · Prof. Nancy...
Prof. Nancy Leveson
16.355
Software Engineering Concepts
http://sunnyday.mit.edu/16.355
Fall 2005
�
cCopyright Nancy Leveson, Sept. 2000
Why is Software Engineering Hard?
Syllabus and Class Description
Is There a Problem?
Outline
�
Is there a problem?
programs are encountering software problemsand the rate is increasing.
7 out of every 10 major weapons development
Head of AF Systems Command: ‘‘Software is the achilles heel of weapons development"
Ariane 5
C−17
IRS Modernization Program
Examples:
FBI CIC
AAS (FAA Advanced Automation System)
Nancy Leveson, Sept. 1999Copyright c
�
Some "Data" (Myths?)
Risks of cancellation or major delays rise rapidly as overall application size increases (Capers Jones):
Failure or cancellation rate of large software systems is over 20% (Capers Jones)
25 % for those over 100,000 LOC
50% for systems exceeding half million LOC
cancelled before completion65% of large systems (over 1,000,000 LOC) are
the most risky business undertakings in the modern world (Capers Jones)
5000 function points (~500,000 LOC) is one of Development of large applications in excess of
������
������
���
Nancy Leveson, Sept. 1999Copyright c
More "Data" (Myths?)
of total U.S. software efforts, amounting to as muchmuch as $14 billion in 1993 dollars (Capers Jones).
Work on cancelled projects comprises about 15%
behind schedule and has consumed 200% of Average cancelled project in U.S. is about a year
expected budget (Capers Jones).
After surveying 8,000 IT projects, Standish Group reported about 30% of all projects were cancelled.
Nancy Leveson, Sept. 1999Copyright c
And Yet More
delays and cost overruns (Capers Jones) Of completed projects, 2/3 experience schedule
Civilian software: at least 100 English words produced for every source code statement.
Military: about 400 words (Capers Jones)
and quality problems in first year of deployment (Jones).
2/3 of completed projects experience low reliability
[bad estimates?]
from 0.5 to 3.0 occurrences per 1000 lines of codeSoftware errors in fielded systems typically range
Bell Labs survey).
Nancy Leveson, Sept. 1999Copyright c
�
cCopyright Nancy Leveson, Sept. 1999
Have you ever been on a project where the
What were some of the problems?
software was never finished or used?
�
Death March Projects
Etc.
No documentation of design decisions
Redesign and rewriting during test
Constant re−estimation
Overwriting source code
Integration problems
Thrashing
Feature (scope) creep
Nancy Leveson, Sept. 1999Copyright c
Types of Problem Projects (Yourdan)
Unlikely to succeed, unhappy workers
Unlikely to succeed, happy workersKamikaze
Likely to succeed, unhappy workers
Ugly
Likely to succeed, happy workers
Mission Impossible
Suicide
Nancy Leveson, Sept. 1999Copyright c
�
Development costs are onlythe tip of the iceberg.
��������� �����������
���� "! #�$&%'(%*),+ -"�.0/*1 %23%*)�4
56 "+7�849 (+ �
Understanding the Problem
1/3 planning
cCopyright Nancy Leveson, Sept. 1999
Development Costs
Coding
Test
Planning
1/4 system test
1/6 coding
1/4 component test
�&:
Understanding the Problem (2)
from requirements not codeMost fielded software errors stem
20% error correction
60% enhancements20% adaptation
Software Maintenance:
Nancy Leveson, Sept. 1999Copyright c
�*�
Software Evolution (Maintenance)
personnel numbers or costs.Introducing computers will not reduce
Leveson’s Law:
Software will become increasinglyunstructured as it is changed.
Software will continually change.
Belady and Lehman’s Laws:
Nancy Leveson, Sept. 1999Copyright c
�;�
cCopyright Nancy Leveson, Sept. 1999
Are Things Improving?
Is software improving at a slower rate than hardware?
"Software expands to fill the available memory"
"Software is getting slower more rapidly thanhardware becomes faster" (Reiser)
(Parkinson)
Expectations are changing
�&�
.
Why or why not?
Is software engineering more difficult than hardware engineering?
�
Why is software engineering hard?
Large discrete state spaces
Organized complexity
Lack of historical usage information
Intangibility
"Curse of flexibility"
Nancy Leveson, Sept. 1999Copyright c
�;
+
Emphasis on steps to be achieved without worryingabout how steps will be realized physically.
The Computer Revolution
design became a completely abstract concept.Design separated from physical representation;
impractical to build become feasible.Machines that were physically impossible or
Design can be changed without retooling or manufacturing.
=
cCopyright Nancy Leveson, Sept. 1999
GeneralPurposeMachine
SpecialPurposeMachine
Software
�&�
So flexible that start working with it before fully understanding what need to do
The Curse of Flexibility
No physical constraints
To enforce discipline on design, constructionand modification
"Scaling up is hard to do"
The untrained can get partial success.
To control complexity
‘‘And they looked upon the software and saw that itwas good. But they just had to add one other feature ...’’
"Software is the resting place of afterthoughts."
Nancy Leveson, Sept. 1999Copyright c
� �
level of interactions reaches the point where they cannot
be thoroughly
2. A system becomes intellectually unmanageable when the
interactions within the system and with its environment.1. A "simple" system has a small number of unknowns in its
What is Complexity?
The underlying factor is intellectual manageability
guarded against
anticipated
understood
planned
Nancy Leveson, Sept. 1999Copyright c
�&
3.into the whole are themselves straightforward.Principles governing the assembling of the components
2.as when playing their part in the whole.Components are the same when examined singly
phenomenon being studied.The division into parts will not distort the 1.
Examine the parts separately.
Divide system into distinct parts for analysis purposes.
Three important assumptions:
Analytic Reduction (Descartes)
Ways to Cope with Complexity
Nancy Leveson, Sept. 1999Copyright c
�&�
in their behavior that they can be studied statistically.
Assumes components sufficiently regular and random
terms of averages.
Use Law of Large Numbers to describe behavior in
Treat as a structureless mass with interchangeable parts.
Statistics
Ways to Cope with Complexity (con’t.)
Nancy Leveson, Sept. 1999Copyright c
��:
the statistics.Too much underlying structure that distorts
The most important properties are emergent.
distorts the results.Separation into non−interacting subsystems
What about software?
"Organized Complexity" (Weinberg)
Too organized for statistics
Too complex for complete analysis:
Nancy Leveson, Sept. 1999Copyright c
�<�
Other Factors
Hard to diagnose problems
Transient hardware faults vs. software errors
Hard to experiment with and manage
Invisible interfaces
Continuous vs. discrete math
Cannot test exhaustively
Lacks repetitive structure found in computer circuitry
Large discrete state spaces
Intangibility
=�=
>�>
Nancy Leveson, Sept. 1999Copyright c
�*�
cCopyright Nancy Leveson, Sept. 1999
No historical usage information
Usually doing new things.
Always specially constructed.
to allow measurement, evaluation, andimprovement of standard designs over time.
And One More
���
suggests that the claimed benefits, in fact, may not exist.
Vessey and Weber
1. Students will be able to evaluate software engineeringtechniques and approaches.
Class Objectives
Hawthorne Effect
Religious approach to SE (vs. scientific):Accept on faith (because sounds right)Gurus (Jackson, Yourdan, etc.)Sects (OO, Ada vs. Modula 2)
Arguments:Proof by vigorous handwaving.Unsupported hypotheses.False analogies.
testing, what little evidence has been obtained sometimes
cCopyright Nancy Leveson, Sept. 1999
"It is important that students bring a certain ragamuffinbarefoot irreverance to their studies. They are herenot to worship what is known, but to question it."
Jacob Bronowski, The Ascent of Man
?�?�?�?�?�?�?�?�?�?�?�?@�@�@�@�@�@�@�@�@�@�@�@
"The developed theories ...have rarely been subjected toempirical testing, and so their value remains unknown. Theyprovide zealots with opportunities to market a rash of seminarsand courses and to flood the literature with papers advocatingthe new technologies. When the theories are subjected to
�
cCopyright Nancy Leveson, Sept. 1999
Class Objectives
project based on an understanding of:
2. Students will be able to exercise professional judgement in selecting an approach for a particular
How the present state of software practice came about
What was tried in the past
What worked and what did not work
Why
�*
Some additional short assignments
Any additional thoughts
Critical evaluation
Main ideas or themes
Reading summaries:
No programming
Assignments
Required BackgroundAB
CD
Nancy Leveson, Sept. 1999Copyright c
���
cCopyright Nancy Leveson, Sept. 1999
Reading: Both classic papers and new ones
I would like to see computer science teaching set deliberatelyin a historical framework.... The absence of this element intheir training causes people to approach every problem fromfirst principles. They are apt to propose solutions that havebeen found wanting in the past. Instead of standing on the
Maurice Wilkes
shoulders of their precursors, they try to go it alone.
� �