PREFACE

Software engineering is an emerging discipline and there are unmistakable trends indicating an increasing level of maturity:

All of these efforts are based upon the presumption that there is a Body of Knowledge that should be mastered by practicing software engineers. The Body of Knowledge exists in the literature that has accumulated over the past thirty years. This book provides a Guide to that Body of Knowledge.

The purpose of the Guide to the Software Engineering Body of Knowledge is to provide a consensually validated characterization of the bounds of the software engineering discipline and to provide a topical access to the Body of Knowledge supporting that discipline. The Body of Knowledge is subdivided into ten software engineering Knowledge Areas (KA) plus an additional chapter providing an overview of the KAs of strongly related disciplines. The descriptions of the KAs are designed to discriminate among the various important concepts, permitting readers to find their way quickly to subjects of interest. Upon finding a subject, readers are referred to key papers or book chapters selected because they succinctly present the knowledge.

In browsing the Guide, readers will note that the content is markedly different from computer science. Just as electrical engineering is based upon the science of physics, software engineering should be based, among other things, upon computer science. In these two cases, though, the emphasis is necessarily different. Scientists extend our knowledge of the laws of nature while engineers apply those laws of nature to build useful artifacts, under a number of constraints. Therefore, the emphasis of the Guide is placed on the construction of useful software artifacts.

Readers will also notice that many important aspects of information technology that may constitute important software engineering knowledge are not covered in the Guide, including specific programming languages, relational databases, and networks. This is a consequence of an engineering-based approach. In all fields—not only computing—the designers of engineering curricula have realized that specific technologies are replaced much more rapidly than the engineering work force. An engineer must be equipped with the essential knowledge that supports the selection of the appropriate technology at the appropriate time in the appropriate circumstance. For example, software might be built in Fortran using functional decomposition or in C++ using objectoriented techniques. The techniques for software configuring instances of those systems would be quite different. But, the principles and objectives of configuration management remain the same. The Guide therefore does not focus on the rapidly changing technologies, although their general principles are described in relevant KAs.

These exclusions demonstrate that this Guide is necessarily incomplete. The Guide covers software engineering knowledge that is necessary but not sufficient for a software engineer. Practicing software engineers will need to know many things about computer science, project management, and systems engineering—to name a few—that fall outside the Body of Knowledge characterized by this Guide. However, stating that this information should be known by software engineers is not the same as stating that this knowledge falls within the bounds of the software engineering discipline. Instead, it should be stated that software engineers need to know some things taken from other disciplines—and that is the approach adopted in this Guide. So, this Guide characterizes the Body of Knowledge falling within the scope of software engineering and provides references to relevant information from other disciplines. A chapter of the Guide provides a taxonomical overview of the related disciplines derived from authoritative sources.

The emphasis on engineering practice leads the Guide toward a strong relationship with the normative literature. Most of the computer science, information technology, and software engineering literature provides information useful to software engineers, but a relatively small portion is normative. A normative document prescribes what an engineer should do in a specified situation rather than providing information that might be helpful. The normative literature is validated by consensus formed among practitioners and is concentrated in standards and related documents. From the beginning, the SWEBOK project was conceived as having a strong relationship to the normative literature of software engineering. The two major standards bodies for software engineering (IEEE Computer Society Software Engineering Standards Committee and ISO/IEC JTC1/SC7) are represented in the project. Ultimately, we hope that software engineering practice standards will contain principles directly traceable to the Guide.

The Guide is oriented toward a variety of audiences, all over the world. It aims to serve public and private organizations in need of a consistent view of software engineering for defining education and training requirements, classifying jobs, developing performance evaluation policies, or specifying software development tasks. It also addresses practicing, or managing, software engineers and the officials responsible for making public policy regarding licensing and professional guidelines. In addition, professional societies and educators defining the certification rules, accreditation policies for university curricula, and guidelines for professional practice will benefit from SWEBOK, as well as the students learning the software engineering profession and educators and trainers engaged in defining curricula and course content.

From 1993 to 2000, the IEEE Computer Society and the Association for Computing Machinery (ACM) cooperated in promoting the professionalization of software engineering through their joint Software Engineering Coordinating Committee (SWECC). The Code of Ethics was completed under stewardship of the SWECC primarily through volunteer efforts. The SWEBOK project was initiated by the SWECC in 1998.

The SWEBOK project’s scope, the variety of communities involved, and the need for broad participation suggested a need for full-time rather than volunteer management. For this purpose, the IEEE Computer Society contracted the Software Engineering Management Research Laboratory at the Université du Québec à Montréal (UQAM) to manage the effort. In recent years, UQAM has been joined by the École de technologie supérieure, Montréal, Québec.

The project plan comprised three successive phases: Strawman, Stoneman, and Ironman. An early prototype, Strawman, demonstrated how the project might be organized. The publication of the widely circulated Trial Version of the Guide in 2001 marked the end of the Stoneman phase of the project and initiated a period of trial usage. The current Guide marks the end of the Ironman period by providing a Guide that has achieved consensus through broad review and trial application.

The project team developed two important principles for guiding the project: transparency and consensus. By transparency, we mean that the development process is itself documented, published, and publicized so that important decisions and status are visible to all concerned parties. By consensus, we mean that the only practical method for legitimizing a statement of this kind is through broad participation and agreement by all significant sectors of the relevant community. Literally hundreds of contributors, reviewers, and trial users have played a part in producing the current document.

Like any software project, the SWEBOK project has many stakeholders—some of which are formally represented. An Industrial Advisory Board, composed of representatives from industry (Boeing, Construx Software, the MITRE Corporation, Rational Software, Raytheon Systems, and SAP Labs-Canada), research agencies (National Institute of Standards and Technology, National Research Council of Canada), the Canadian Council of Professional Engineers, and the IEEE Computer Society, has provided financial support for the project. The IAB’s generous support permits us to make the products of the SWEBOK project publicly available without any charge (see http://www.swebok.org). IAB membership is supplemented with the chairs of ISO/IEC JTC1/SC7 and the related Computing Curricula 2001 initiative. The IAB reviews and approves the project plans, oversees consensus building and review processes, promotes the project, and lends credibility to the effort. In general, it ensures the relevance of the effort to real-world needs.

The Trial Version of the Guide was the product of extensive review and comment. In three public review cycles, a total of roughly 500 reviewers from 42 countries provided roughly 9,000 comments, all of which are available at www.swebok.org. To produce the current version, we released the Trial Version for extensive trial usage. Trial application in specialized studies resulted in 17 papers describing good aspects of the Guide, as well as aspects needing improvement. A Web-based survey captured additional experience: 573 individuals from 55 countries registered for the survey; 124 reviewers from 21 countries actually provided comments—1,020 of them. Additional suggestions for improvement resulted from liaison with related organizations and efforts: IEEE-CS/ACM Computing Curricula Software Engineering; the IEEE CS Certified Software Development Professional project; ISO/IEC JTC1/SC7 (software and systems engineering standards); the IEEE Software Engineering Standards Committee; the American Society for Quality, Software Division; and an engineering professional society, the Canadian Council of Professional Engineers.

The overall goal of the current revision was to improve the readability, consistency, and usability of the Guide. This implied a general rewrite of the entire text to make the style consistent throughout the document. In several cases, the topical breakdown of the KA was rearranged to make it more usable, but we were careful to include the same information that was approved by the earlier consensus process. We updated the reference list so that it would be easier to obtain the references.

Trial usage resulted in the recommendation that three KAs should be rewritten. Practitioners remarked that the Construction KA was difficult to apply in a practical context. The Management KA was perceived as being too close to general management and not sufficiently specific to software engineering concerns. The Quality KA was viewed as an uncomfortable mix of process quality and product quality; it was revised to emphasize the latter.

Finally, some KAs were revised to remove material duplicating that of other KAs.

Even though the Guide has gone through an elaborate development and review process, the following limitations of this process must be recognized and stated:

• Software engineering continues to be infused with new technology and new practices. Acceptance of new techniques grows and older techniques are discarded. The topics listed as “generally accepted” in this Guide are carefully selected at this time. Inevitably, though, the selection will need to evolve.

• The amount of literature that has been published on software engineering is considerable and the reference material included in this Guide should not be seen as a definitive selection but rather as a reasonable selection. Obviously, there are other excellent authors and excellent references than those included in the Guide. In the case of the Guide, references were selected because they are written in English, readily available, recent, and easily readable, and—taken as a group—they provide coverage of the topics within the KA.

• Important and highly relevant reference material written in languages other than English have been omitted from the selected reference material.

Additionally, one must consider that

• Software engineering is an emerging discipline. This is especially true if you compare it to certain more established engineering disciplines. This means notably that the boundaries between the KAs of software engineering and between software engineering and its related disciplines remain a matter for continued evolution.

The contents of this Guide must therefore be viewed as an “informed and reasonable” characterization of the oftware engineering Body of  Knowledge and as baseline for future evolution. Additionally, please note that the Guide is not attempting nor does it claim to replace or amend in any way laws, rules, and procedures that have been defined by official public policy makers around the world regarding the practice and definition of engineering and software engineering in particular.

1. The ACM/CS Software Engineering Code of Ethics and Professional Practice can be found at http://www.computer.org/certification/ethics.htm