CSE403 Software Engineering,
Autumn 1999
David Notkin
Lecture #1 Notes
1)
What
is the worst thing that you’ve heard about CSE403?
2)
What
is the best thing that you’ve heard about CSE403?
3)
Today
a)
CSE403
educational objectives (and why)
b)
Quick
overview of software engineering and why we study it
c)
Overview
of the course
i)
If
I am short of time, I will do less on this, since the material is on the web
page for the course
4)
Our
educational objective is for you to learn that
a)
“Effectively engineering large software
systems is not merely a matter of programming”
b)
The vehicle is a large, group project
5)
You
may intellectually already understand the course’s objective, but the project
will ensure that you understand this in your heart and soul
6)
Why
don’t we teach the right way......to
engineer large software systems?
a)
Because
there is no single right way
b)
All
engineering, including software engineering, is concerned with building useful
artifacts under constraints (some people even define engineering to be “design
under constraints”)
c)
If
it weren’t for the constraints, there might be a single right way to engineer
software systems
d)
But
we will definitely convey principles and approaches that represent classes of
best practices
7)
In
groups of 2 or 3 people, take one minute and write down some possible
constraints that might affect how you would engineer software; some of our
examples include
a)
Ship
your computer game by November 15th or miss the Christmas market — and your
company will go out of business
b)
Fix
your Y2K problem in time — or face lawsuits
c)
Fit
your embedded software in 128K bytes — or the price of the PDA will go up 20%
d)
Headcount
on this project is four people
e)
You
have to program in COBOL, because that’s the only language people in this shop
use, and anyway we can’t afford to buy new tools
8)
Success
in 403 is not solely determined by whether your project works
a)
Remember
the primary educational objective
b)
Resources
about how to succeed include
i)
Lectures
& sections & readings
ii)
The
instructors and TA
c)
Collectively,
these will convey key software engineering principles & practices that you
can apply
9)
We
will not give you a single methodology for your project
a)
“Beware
of the methodologist, who has more interest in a style of solution than in the
customers’ problem [Jackson].”
10)
Similarly,
we will not give you a single tool set or environment for your project
11)
These
are legitimate educational approaches that we’ve chosen not to use
a)
There
are many successful (and some unsuccessful) models of software engineering
courses; we like this one!
12)
Some
definitions of SE
a)
The
practical application of scientific knowledge to the design and construction of
computer programs and the associated documentation required to develop,
operate, and maintain them [Boehm].
b)
The
systematic approach to the development, operation, maintenance, and retirement
of software [IEEE].
c)
The
establishment and use of sound engineering principles (methods) in order to
obtain economically software that is reliable and works on real machines
[Bauer].
d)
Multi-person
construction of multi-version software [Parnas].
e)
“Software
from womb to tomb.”
13)
Why
study SE?
a)
It’s
critical to society
b)
It’s
hard
c)
There
is a perceived crisis in our ability to build software
d)
It’s
fun!
14)
Software
is critical to society
a)
Economically
important
b)
Essential
for running most enterprises
c)
Key
part of most complex systems
d)
Essential
for designing many engineering products
e)
In
many if not in most cases, the software is embedded in the system you are using
— you don’t see the software
15)
Software
is big
a)
Code
sizes due to Jon Jacky (mostly); KLOC = 1000 lines of code; MLOC = 1,000,000
lines of code
Bar
code scanners |
10-50KLOC |
4-speed
transmissions |
20KLOC |
ATC
ground system |
130KLOC |
Automatic
teller machine |
600KLOC |
Call
router |
2.1MLOC |
B-2
Stealth Bomber |
3.5MLOC |
Seawolf
submarine combat |
3.6MLOC |
NT
4.0 |
10MLOC |
NT
5.0 |
60+
MLOC |
b)
Delivered
source lines per person
c)
Common
estimates are that a person can deliver about 1000 source lines per year
(including documentation, scaffolding, etc.)
d)
Therefore,
most complex systems require many people to build
i)
This
would be true even with an order of magnitude increase in productivity
e)
Hence
the critical need for coordination
i)
Brooks
reminds us that people ¹ time
16)
“The
Software Crisis”
a)
We’ve
been in the midst of a crisis ever since the 1968 NATO meeting that christened
software engineering
b)
“We
are unable to produce or maintain high-quality software at reasonable price and
on schedule.”
c)
“Software
systems are like cathedrals; first we build them and they we pray.
[Redwine]"
17)
To
some degree this is accurate
a)
We’ll
look at some classic software failures later on in the quarter
b)
But
it’s not fully accurate
c)
Given
the context, we do pretty well
d)
We
surely can, should and must improve
e)
Some
so-called software “failures” are not
i)
They
are often management errors (the choice not to do something that would have
helped)
f)
In
some areas, in particular safety-critical real-time embedded systems, we may
indeed have a looming crisis
18)
Some
“crisis” issues
a)
Relative
cost of hardware/software
b)
Low
productivity
c)
“Wrong”
products
d)
Poor
quality
e)
Constant
maintenance
f)
Technology
transfer is slow
19)
Why
is it hard?
a)
There
is no single reason software engineering is hard—it’s a “wicked problem”
b)
Lack
of well-understood representations of software makes customer and engineer
interactions hard [Brooks]
c)
Relatively
young field
d)
Software
intangibility is deceptive
i)
Norman
Augustine [Wulf]: “Software is like entropy.
It is difficult to grasp, weighs nothing, and obeys the second law of
thermodynamics; i.e., it always increases.”
[Law XXIII]
20)
As
the size of the software system grows, the dominant discipline changes (due to
Stu Feldman)
Code
Size (LOC) |
Dominant
Discipline |
103 |
Mathematics |
104 |
Science |
105 |
Engineering |
106 |
Social
Science |
107 |
Politics |
108
(not addressed by Feldman) |
Legal? |
21)
In
CSE so far you have mostly implemented carefully defined specifications
a)
In
most cases, the central objective was to build an implementation that satisfied
specific speed and space requirements
b)
From
a CSE326 assignment
i)
“For
this assignment, you are required to write a program mzsolve that finds routes through mazes and solves the 2-coloring
problem. Your program will take a maze as input (in a file format described
below) and output a solution path for the maze and a strategy for 2-coloring
the maze. To accomplish this, you will implement a Maze ADT to represent the
maze as a graph. You will implement Maze ADT operations to construct a graph
from a maze file, search the graph for solution paths using DFS and BFS, and
determine a two color painting scheme for the maze.”
ii)
mzsolve.C - this is the main driver
code for the program that we've partially implemented. Mostly, this will just
make calls to the Maze ADT and output their results.
iii)
Maze.h,Maze.C - these contain a skeleton
of the specification and implementation of the Maze ADT as a C++ class. You
will implement the internal representation of the the maze. You are free to use
any implementation you prefer. Be aware that some representations are better
than others, and we will evaluate your choice. The data structure should be
able to handle arbitrary mazes (thus, arbitrary graphs). At the minimum, you
will need to implement these methods:
Maze(istream &inFile); //
construct a maze from input stream
DFSolve(); // solve using DFS
BFSolve(); // solve using BFS
TwoColor(); // determine whether a maze is 2-colorable
iv)
Makefile - make mzsolve will use this to build your program.
v)
You
were given...
(1)
…the
specification (what to do)
(2)
…the
design (roughly, what ADTs to build)
(3)
…hints
about the implementation
(4)
…some
partial code
(5)
…a
pointer to some libraries to use (omitted from the slides)
vi)
Somebody
had to figure all this stuff out for you; now that's software engineering, and
now it's your turn
22)
Software
lifecycle
a)
A
software engineering lifecycle model describes how one might put structure on
the software engineering activities
b)
The
classic lifecycle model is the waterfall model (roughly due to Royce in 1956),
which is structured by a set of activities and is inherently document-driven
c)
Limited
feedback increases risk
d)
“You
start at the top and it’s all downhill from there.” [uncertain origin]
e)
The
cost of fixing errors at later lifecycle phases is much higher than at earlier
stages
i)
Boehm’s
1976 data still hold — the differences are often an order of magnitude
ii)
Must
increase feedback in the lifecycle to reduce these costs (and other risks)
23)
Wednesday
and Friday lectures
a)
Kimura
(Notkin absent, at IBM Research and at ACM SIG Governing Board meetings)
b)
Wednesday:
Models of software engineering (Read the two Boehm papers)
c)
Friday:
Overview of requirements
24)
Overview
of the course
a)
Project
(4-6 students, you choose the members)
i)
We
give you a high-level description, you refine it
ii)
Strict
milestones (some flexibility later on)
iii)
Weekly
reports, due on Fridays; list top 3 risks, plus other material (email is fine)
iv)
Not
primarily graded on whether your program "works"
b)
Just-in-time
lectures
c)
Reviews
d)
Sections
e)
Quizzes:
only part of the grade that is yours alone
f)
Special
topics (often guest lectures), last two weeks of quarter
g)
Readings
are key
h)
Schedule
is on the web page