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
10^3	Mathematics
10^4	Science
10^5	Engineering
10^6	Social Science
10^7	Politics
10^8(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