Introduction

What course is this?

Motivate the course....

The STARS radar display terminals for the US air traffic control system. Old system had round B&W screens, knobs to adjust the display, and ABC keyboard. New system has color display, pulldown menus, and a QWERTY keyboard. Controllers found it very difficult (and dangerous) to use the new terminals.

Denver airport baggage handling disaster. Ambitious plan, using new technologies and methods. Entire airport project depended on it. Technical problems and project management errors. Deadlines missed again and again. Blown demos -- baggage flying off conveyors. Airport opening delayed.

Goals of the course

help you avoid working on (or creating) a project like the above
broad survey of current theory and practice
introduction to the complete life of a software project
practice with methods learned in class
organizing and delegating in a team
critical thinking

Non-goals

Teaching a particular programming language, like Java or OOP
Focusing just on the programming process; the course will be broader than that
Teaching provable results. This course will probably be less formal and mathematical than your other CS courses.

Prerequisites

Comfortable writing sizable programs in a popular language. (Sizable means 5+ modules, error checking, file I/O, user interface.)
Familiarity with a range of issues in computer science. (You should have taken 4+ CS courses.)

Overview of Software Engineering

What is software engineering?

Producing high-quality software in an efficient and predictable manner.

High-quality is relative to the project at hand. It might mean fast execution, or easy to use, or super-reliable, or all of these.

Efficient means in the minimum number of person-days and calendar days (approximately).

Predictable means that you know beforehand how long the project will take, and the project actually takes that long.

All three of these qualities must be true for a project to be successful.

Give some senarios where only two are true?

Student opinions about SE?

Other opinions about SE

All software can be written in a predictable efficient manner, if only the stupid engineers would listen to us (researchers).
Software engineering is a waste of time. You can not predict when software will be finished. SE methods slow down projects. Good programmers need freedom and won't work with all these rules.

The state of software engineering (my opinion)

Somewhere between the above two statements.

It is not true that all software projects can be made to run smoothly using known techniques. Example: New software in an unknown area.

On the other hand, far too many projects go wrong when there are known methods that would have helped. Examples: The 5th revision of a word processing program. A team that consistently misses its own schedules by 100%.

Why (in my opinion) SE matters

Software (and software development) is everywhere now. Software affects all financial systems, personal privacy, medical care, transportation systems, building controls, military arsenals, etc.

When software development goes wrong, any of these systems also goes wrong.

If we can make a small improvement (say 5%) in the quality and efficiency of software projects, that has a tremendous impact worldwide on almost everything.

Models of Software Engineering

Three-layer pyramid look at software engineering.

Bottom layer -- Quality is an attitude, or goal, that underlies SE. (Without a focus on quality, there is no need for SE.)

Middle layer -- Processes are frameworks for how we will approach a software project. (The course will generally be concerned with processes.)

Top layer -- Tools are automated ways to carry out a process. (We will be less concerned with tools, but will have a few demonstrations of them.)

The three phases of any software project.

Definition -- what is to be done

Development -- writing the software

Deployment / Maintenance -- installing, fixing, and changing the software

Models of SE

These are general descriptions of how software can be created.

None of the models are "correct" or "better" since software can (and is) developed using each model.

Linear-sequential (waterfall) model of SE, page 137, 139 in RD.

Idea -- Do each part of the software process once, then you are done.

Pros -- Simple, straightforward, easy for users to understand.

Cons -- Unrealistic for any sizable project. Users don't know, or can't say, what they want at the start. Impossible to completely design complex systems before starting to write any code.

Code and Fix, page 140

Idea -- Code everything right away, then fix the bugs.

Pros -- Can get started right away, some engineers like it, management often likes it.

Cons -- Takes WAY more time in the long run. The fast start is an illusion, because it takes so long to fix the bugs. Some problems can not be fixed without starting over, because of design errors.

Note -- Amazingly, this method of software development is in wide use many places, by smart people, at top companies.

Design to Tools

Idea -- Choose system features that can be done easily by the software development tools that you are using.

Example -- Web page design using MS FrontPage. You create web sites using one of the supplied templates, with a given style, predefined button types, etc.

Pros -- Can be very fast, given a team that knows how to use the tools. Good for customers with a small budget.

Cons -- Users have to compromise on what they are getting. Customers with a large budget often don't want to do this.

Note -- I do this regularly in my consulting business. I try to steer clients to create applications in ways that are easy for Lotus Notes/Domino. (Even though I make more money by writing custom code.)

Off the Shelf

Idea? -- Don't write any software at all. Buy something that already works.

Pros -- Very fast. Inexpensive, compared to development costs. Cheaper support. High quality immediately (hopefully).

Cons -- Most settle for existing solution. Not an option for "first of its kind" software.

Note -- You should strong consider this approach before writing any software. Don't assume that your original creation will be perfect or on schedule. Ask yourself: "If our custom code ends up with 1/2 of our desired features and takes 2x as long as we planned, do we still want to write this ourselves?"

Spiral and Evolutionary Delivery, page 142, 147

Idea -- Create a small, core system. Finish it and release it. Then create the next version with more features. Then the next, etc.

Pros -- It is realistic, only so many features can realistically be added at a time. It is easier to estimate the time needed for each new version, versus one big estimate for everything.

Cons -- Users don't want to wait 3 versions to get their favorite features. Users find it hard to prioritize features by version. Users don't like to hear the realistic price and time up front.

Note -- There are many variations of this, with the same basic idea. Spiral, staged delivery, evolutionary prototyping, etc.

In my opinion (and McConnell's) these latter models are the right way to do software development.

Put the core, necessary features in the first version. (This often takes judgment and can be difficult.)

Add a reasonable set of new/changed features in the 2nd version (not every feature you really wanted in the first place).

Add another reasonable set of new/modified features in each subsequent version.

I encourage you to use the spiral model (or something like it) for your team project.

A word about Rapid Application Development (RAD) and web-time development...

These are important goals, but are not methods of software development.

If your boss says "Write this program in web time!", you still need some method to get this done.

The spiral / staged model can be used to finish software quickly for near-term e-commerce deadlines.

Process vs. Flexibility

What I mean by this...

Should programmers just program, or should they work within a certain method?

How rigid should methods be? Should they specify the overall engineering process, or code-level details about comments and GOTOs?

This is a dominant theme in SE and real software development teams.

Having a software development process is good. Any organization (or a team within an organization) needs one to create good software. Without some process, things go wrong, source code vanishes, and bugs reappear.

On the other hand, an over-reliance on process stifles development. Engineers are not allowed to create and think. (IBM was famous for having 500 programmers on a project and getting little done.)

Conclusion -- We need software process, but also the flexibility to change the process to suit the needs of each project and to learn as we go.