Software Engineering I

(Analysis, Design, Creation) Spring 1998

I still have a sore throat

but

I am not infectious

(clinically speaking)

so to for me to avoid speaking:

Please ask questions that can be answered

with "yes" or "no"

For example:

Rather than ask:

"What is Software Engineering?"

A better question is:

"Does IEEE define Software Engineering as the

application of a systematic, disciplined, quantifiable

approach to the development, operation, and maintenance

of software?"

(Yes)

First:

Some reminders and things you should know:

Today in history:

40 Years ago today:

In Software Engineering:

Nothing Happened

(There was no SE, 40 years ago)

But a lot of software written then, 40 years ago,

is still in use - some in critical applications:

like Social Security

And that’s part of the problem

Some call this a "Software Crisis"

Reminder:

Friday: Jan. 30

There will be a memorial service held for

Dr. Karan Harbison (Professor of Computer Science) on Friday,

January 30th at 11:00AM

in the Rady Room on the sixth floor of Nedderman Hall.

ACM Movies at 12:00 with Pizza and drinks for $1.00

Room 100 NH

Important Reminder:

from each student or you won't be in a team for a

project, and you won't get that part of your grade.

Today's class:

1. Review from last time
2. Brooks Book Chapter
3. Software Engineering:

terms

concepts

requirements

4. Review

Last:

What is Software Engineering?

What are: programs, products, systems? What's the

difference?

Programming was done "ad hoc". That doesn't work

anymore.

The software development process (even after

50 years) continues to stymie engineers.

Software maintenance is a (the) major part of software

products. But there is more to maintenance than

fixing bugs (really: defects, errors).

Software is engineered (developed)

rather than manufactured.

Software doesn't "wear out" (in the classical sense)

But it does deteriorate!

Most software is custom built, not assembled

(from components)

But - this is changing: software "reuse" is increasingly

critical for organizations

The software development environment is becoming

more abstract - higher level. Rather than programs

calling library routines (like "read"), programs interface

to distributed high level objects (Corba, Java RMI, ODBC)

Software may be:

System (software)

Real-Time

Embedded

or Business, Scientific, etc.

Software problems are not really in Crisis

(but instead in "chronic affliction")

Consider:

Computing is about 50 years old.

Moores Law says capabilities double every year and a half:

Processors are twice as fast, memory and disk

are twice as big, etc.

New technologies arise: CD-Roms, DVD, Higher Speed LANS,

telecommunication - data comm, Internet, video, and audio,

even movies and TV are merging (Movie companies start

software firms, software firms start TV and movie companies)

For the first 10 years of computers, systems typically executed

a few thousand "instructions" per second.

For the middle 10 years the execution was 10's of thousands to

a very few million per second.

Now a low end PC is nearing a 100 million per second, with

embedded systems - microwave ovens or PDA organizers -

in the millions per second.

Moore - and most technologists - believe this progress will

not slow down - and many believe it will accelerate.

BUT

Has software kept up?

Hardware is faster/better/cheeper

Customer expectation has increased:

Software is easier to use: GUI-WIMP

(Windows, Icon, Mouse Pointer)

Customers can do things in application domains

that used to require programmers: Spreadsheets,

Data Bases, Publishing.

But we (software engineers) are expected to create

Easy to Use

Reliable

Efficient

Correct (Bug free)

Software

And managers want:

Software

On time

Easy to fix

Easy to port to other OS, Networks, Data bases

New, enhanced versions quickly

Usable by the customer

And some systems require

A financial software shouldn't loose money.

It must comply with accounting practices.

A pacemaker software must be very reliable

(peoples lives are at risk) and even "self correcting"

Are we up to it?

What do customers think of the process?

(Of developing software)

The programmers don't listen.

They develop what they want not what I asked for.

And then it's buggy anyway.

Why do I have to keep punching in that account

number on every screen, can't this program remember

one stupid number!?

What does the boss (the SE manager) think?

These programmers couldn't keep to a schedule if their

life depended on it. Always late.

Doesn't anyone test anything - why are these obvious bugs

here?

I never get a straight answer out of these developers.

Why does the customer change their mind every 5 minutes?

What do we (practitioners) think?

I can write the program - the difficult part. Let some

English major write the documentation. Anyone can test.

My "deliverable" is the program.

The customer must wait for the product until I'm done.

Quality is me writing code really careful. Then testing.

Some scary facts:

There are BILLIONS of lines of working, currently being

used code.

Much (most) is undocumented and is in:

FORTRAN, COBOL, or (some kind of) assembly

Does it "wear out"?

Add two numbers together, display result.