When computer software succeeds—when it meets the needs of the people who use
it, when it performs flawlessly over a long period of time, when it is easy to modify
and even easier to use—it can and does change things for the better. But when software
fails—when its users are dissatisfied, when it is error prone, when it is difficult to change
and even harder to use—bad things can and do happen. We all want to build software that
makes things better, avoiding the bad things that lurk in the shadow of failed efforts. To
succeed, we need discipline when software is designed and built. We need an engineer-
ing approach.
It has been almost three decades since the first edition of this book was written. During
that time, software engineering has evolved from an obscure idea practiced by a relatively
small number of zealots to a legitimate engineering discipline. Today, it is recognized as a
subject worthy of serious research, conscientious study, and tumultuous debate. Through-
out the industry, software engineer has replaced programmer as the job title of preference.
Software process models, software engineering methods, and software tools have been
adopted successfully across a broad spectrum of industry segments.
Although managers and practitioners alike recognize the need for a more disciplined
approach to software, they continue to debate the manner in which discipline is to be
applied. Many individuals and companies still develop software haphazardly, even as they
build systems to service today’s most advanced technologies. Many professionals and
students are unaware of modern methods. And as a result, the quality of the software that
we produce suffers, and bad things happen. In addition, debate and controversy about the
true nature of the software engineering approach continue. The status of software engi-
neering is a study in contrasts. Attitudes have changed, progress has been made, but
much remains to be done before the discipline reaches full maturity.
OR
