INTRODUCTION TO THE GUIDE
In spite of the millions of software professionals worldwide and the ubiquitous presence of software in our society, software engineering has only recently reached the status of a legitimate engineering discipline and a recognized profession.
Achieving consensus by the profession on a core body of knowledge is a key milestone in all disciplines and had been identified by the IEEE Computer Society as crucial for the evolution of software engineering towards professional status. This Guide, written under the auspices of the Professional Practices Committee, is part of a multi-year project designed to reach such a consensus.
The IEEE Computer Society defines software engineering as: "(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1)."1
For software engineering to be fully known as a legitimate engineering discipline and a recognized profession, consensus on a core body of knowledge is imperative. This fact is well illustrated by Starr when he defines what can be considered a legitimate discipline and a recognized profession. In his Pulitzer Prize-winning book on the history of the medical profession in the USA, he states,
Gary Ford and Norman Gibbs studied several recognized professions, including medicine, law, engineering, and accounting.3 They concluded that an engineering profession is characterized by several components:
This Guide contributes to the first three of these components. Articulating a Body of Knowledge is an essential step toward developing a profession because it represents a broad consensus regarding what a software engineering professional should know. Without such a consensus, no licensing examination can be validated, no curriculum can prepare an individual for an examination, and no criteria can be formulated for accrediting a curriculum. The development of consensus is also a prerequisite to the adoption of coherent skills development and continuing professional education programs in organizations.
The Guide should not be confused with the Body of Knowledge itself, which already exists in the published literature. The purpose of the Guide is to describe what portion of the Body of Knowledge is generally accepted, to organize that portion, and to provide a topical access to it. Additional information on the meaning given to "generally accepted" can be found below and in Appendix A.
The Guide to the Software Engineering Body of Knowledge (SWEBOK) was established with the following five objectives:
The first of these objectives, a consistent worldwide view of software engineering, was supported by a development process which engaged approximately 500 reviewers from 42 countries in the Stoneman phase (1998–2001) leading to the Trial version, and over 120 reviewers from 21 countries in the Ironman phase (2003) leading to the 2004 version. More information regarding the development process can be found in the Preface and on the Web site (www.swebok.org). Professional and learned societies and public agencies involved in software engineering were officially contacted, made aware of this project, and invited to participate in the review process. Associate editors were recruited from North America, the Pacific Rim, and Europe. Presentations on the project were made at various international venues and more are scheduled for the upcoming year.
The second of the objectives, the desire to set a boundary for software engineering, motivates the fundamental organization of the Guide. The material that is recognized as being within this discipline is organized into the first ten Knowledge Areas (KAs) listed in Table 1. Each of these KAs is treated as a chapter in this Guide.
Table 1 The SWEBOK Knowledge Areas (KAs)
In establishing a boundary, it is also important to identify what disciplines share that boundary, and often a common intersection, with software engineering. To this end, the Guide also recognizes eight related disciplines, listed in Table 2 (see Chapter 12, "Related Disciplines of Software Engineering"). Software engineers should, of course, have knowledge of material from these fields (and the KA descriptions may make reference to them). It is not, however, an objective of the SWEBOK Guide to characterize the knowledge of the related disciplines, but rather what knowledge is viewed as specific to software engineering.
Table 2 Related disciplines
The organization of the KA descriptions or chapters supports the third of the project's objectives—a characterization of the contents of software engineering. The detailed specifications provided by the project's editorial team to the associate editors regarding the contents of the KA descriptions can be found in Appendix A.
The Guide uses a hierarchical organization to decompose each KA into a set of topics with recognizable labels. A two- or three-level breakdown provides a reasonable way to find topics of interest. The Guide treats the selected topics in a manner compatible with major schools of thought and with breakdowns generally found in industry and in software engineering literature and standards. The breakdowns of topics do not presume particular application domains, business uses, management philosophies, development methods, and so forth. The extent of each topic's description is only that needed to understand the generally accepted nature of the topics and for the reader to successfully find reference material. After all, the Body of Knowledge is found in the reference material themselves, not in the Guide.
To provide a topical access to the knowledge—the fourth of the project's objectives—the Guide identifies reference material for each KA, including book chapters, refereed papers, or other recognized sources of authoritative information. Each KA description also includes a matrix relating the reference material to the listed topics. The total volume of cited literature is intended to be suitable for mastery through the completion of an undergraduate education plus four years of experience.
In this edition of the Guide, all KAs were allocated around 500 pages of reference material, and this was the specification the associate editors were invited to apply. It may be argued that some KAs, such as software design for instance, deserve more pages of reference material than others. Such modulation may be applied in future editions of the Guide.
It should be noted that the Guide does not attempt to be comprehensive in its citations. Much material that is both suitable and excellent is not referenced. Material was selected in part because—taken as a collection—it provides coverage of the topics described.
From the outset, the question arose as to the depth of treatment the Guide should provide. The project team adopted an approach which supports the fifth of the project's objectives— providing a foundation for curriculum development, certification, and licensing. The editorial team applied the criterion of generally accepted knowledge, to be distinguished from advanced and research knowledge (on the grounds of maturity) and from specialized knowledge (on the grounds of generality of application). The definition comes from the Project Management Institute: "The generally accepted knowledge applies to most projects most of the time, and widespread consensus validates its value and effectiveness."4
Figure 1 Categories of knowledge
However, the term "generally accepted" does not imply that the designated knowledge should be uniformly applied to all software engineering endeavors—each project's needs determine that—but it does imply that competent, capable software engineers should be equipped with this knowledge for potential application. More precisely, generally accepted knowledge should be included in the study material for the software engineering licensing examination that graduates would take after gaining four years of work experience. Although this criterion is specific to the US style of education and does not necessarily apply to other countries, we deem it useful. However, the two definitions of generally accepted knowledge should be seen as complementary.
LIMITATIONS RELATED TO THE BOOK FORMAT
The book format for which this edition was conceived has its limitations. The nature of the contents would be better served using a hypertext structure, where a topic would be linked to topics other than the ones immediately preceding and following it in a list.
Some boundaries between KAs, subareas, and so on are also sometimes relatively arbitrary. These boundaries are not to be given too much importance. As much as possible, pointers and links have been given in the text where relevant and useful.
Links between KAs are not of the input-output type. The KAs are meant to be views on the knowledge one should possess in software engineering with respect to the KA in question. The decomposition of the discipline within KAs and the order in which the KAs are presented are not to be assimilated with any particular method or model. The methods are described in the appropriate KA in the Guide, and the Guide itself is not one of them.
THE KNOWLEDGE AREAS
Figure 1 maps out the eleven chapters and the important topics incorporated within them. The first five KAs are presented in traditional waterfall life-cycle sequence. However, this does not imply that the Guide adopts or encourages the waterfall model, or any other model. The subsequent KAs are presented in alphabetical order, and those of the related disciplines are presented in the last chapter. This is identical to the sequence in which they are presented in this Guide.
STRUCTURE OF THE KA DESCRIPTIONS
The KA descriptions are structured as follows.
In the introduction, a brief definition of the KA and an overview of its scope and of its relationship with other KAs are presented.
The breakdown of topics constitutes the core of each KA description, describing the decomposition of the KA into subareas, topics, and sub-topics. For each topic or sub-topic, a short description is given, along with one or more references.
The reference material was chosen because it is considered to constitute the best presentation of the knowledge relative to the topic, taking into account the limitations imposed on the choice of references (see above). A matrix links the topics to the reference material.
The last part of the KA description is the list of recommended references. Appendix A of each KA includes suggestions for further reading for those users who wish to learn more about the KA topics. Appendix B presents the list of standards most relevant to the KA. Note that citations enclosed in square brackets "[ ]" in the text identify recommended references, while those enclosed in parentheses "( )" identify the usual references used to write or justify the text. The former are to be found in the corresponding section of the KA and the latter in Appendix A of the KA.
Brief summaries of the KA descriptions and appendices are given next.
SOFTWARE REQUIREMENTS (SEE FIGURE 2, COLUMN A)
A requirement is defined as a property that must be exhibited in order to solve some real-world problem.
The first knowledge subarea is Software Requirements Fundamentals. It includes definitions of software requirements themselves, but also of the major types of requirements: product vs. process, functional vs. nonfunctional, emergent properties. The subarea also describes the importance of quantifiable requirements and distinguishes between systems and software requirements.
The second knowledge subarea is the Requirements Process, which introduces the process itself, orienting the remaining five subareas and showing how requirements engineering dovetails with the other software engineering processes. It describes process models, process actors, process support and management, and process quality and improvement.
The third subarea is Requirements Elicitation, which is concerned with where software requirements come from and how the software engineer can collect them. It includes requirement sources and elicitation techniques.
The fourth subarea, Requirements Analysis, is concerned with the process of analyzing requirements to
Requirements analysis includes requirements classification, conceptual modeling, architectural design and requirements allocation, and requirements negotiation.
The fifth subarea is Requirements Specification. Requirements specification typically refers to the production of a document, or its electronic equivalent, that can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced: system definition, system requirements specification, and software requirements specification. The subarea describes all three documents and the underlying activities.
The sixth subarea is Requirements Validation, the aim of which is to pick up any problems before resources are committed to addressing the requirements. Requirements validation is concerned with the process of examining the requirements documents to ensure that they are defining the right system (that is, the system that the user expects). It is subdivided into descriptions of the conduct of requirements reviews, prototyping, and model validation and acceptance tests.
The seventh and last subarea is Practical Considerations. It describes topics which need to be understood in practice. The first topic is the iterative nature of the requirements process. The next three topics are fundamentally about change management and the maintenance of requirements in a state which accurately mirrors the software to be built, or that has already been built. It includes change management, requirements attributes, and requirements tracing. The final topic is requirements measurement.
SOFTWARE DESIGN (SEE FIGURE 2, COLUMN B)
According to the IEEE definition [IEEE 610.12-90], design is both "the process of defining the architecture, components, interfaces, and other characteristics of a system or component" and "the result of [that] process." The KA is divided into six subareas.
The first subarea presents Software Design Fundamentals, which form an underlying basis to the understanding of the role and scope of software design. These are general software concepts, the context of software design, the software design process, and the enabling techniques for software design.
The second subarea groups together the Key Issues in Software Design. They include concurrency, control and handling of events, distribution of components, error and exception handling and fault tolerance, interaction and presentation, and data persistence.
The third subarea is Software Structure and Architecture, the topics of which are architectural structures and viewpoints, architectural styles, design patterns, and, finally, families of programs and frameworks.
The fourth subarea describes software Design Quality Analysis and Evaluation. While there is a entire KA devoted to software quality, this subarea presents the topics specifically related to software design. These aspects are quality attributes, quality analysis, and evaluation techniques and measures.
The fifth subarea is Software Design Notations, which are divided into structural and behavioral descriptions.
The last subarea describes Software Design Strategies and Methods. First, general strategies are described, followed by function-oriented design methods, object-oriented design methods, data-structure-centered design, component- based design, and others.
Software construction refers to the detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. The KA includes three subareas.
The first subarea is Software Construction Fundamentals. The first three topics are basic principles of construction: minimizing complexity, anticipating change, and constructing for verification. The last topic discusses standards for construction.
The second subarea describes Managing Construction. The topics are construction models, construction planning, and construction measurement.
The third subarea covers Practical Considerations. The topics are construction design, construction languages, coding, construction testing, reuse, construction quality, and integration.
SOFTWARE TESTING (SEE FIGURE 2, COLUMN D)
Software Testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected behavior. It includes five subareas.
It begins with a description of Software Testing Fundamentals. First, the testing-related terminology is presented, then key issues of testing are described, and finally the relationship of testing to other activities is covered.
The second subarea is Test Levels. These are divided between the targets of the tests and the objectives of the tests.
The third subarea is Test Techniques. The first category includes the tests based on the tester's intuition and experience. A second group comprises specification-based techniques, followed by code-based techniques, fault-based techniques, usage-based techniques, and techniques relative to the nature of the application. A discussion of how to select and combine the appropriate techniques is also presented.
The fourth subarea covers Test-Related Measures. The measures are grouped into those related to the evaluation of the program under test and the evaluation of the tests performed.
The last subarea describes the Test Process and includes practical considerations and the test activities.
SOFTWARE MAINTENANCE (SEE FIGURE 2, COLUMN E)
Once in operation, anomalies are uncovered, operating environments change, and new user requirements surface. The maintenance phase of the life cycle commences upon delivery, but maintenance activities occur much earlier. The Software Maintenance KA is divided into four subareas.
The first one presents Software Maintenance Fundamentals: definitions and terminology, the nature of maintenance, the need for maintenance, the majority of maintenance costs, the evolution of software, and the categories of maintenance.
The second subarea groups together the Key Issues in Software Maintenance. These are the technical issues, the management issues, maintenance cost estimation, and software maintenance measurement.
The third subarea describes the Maintenance Process. The topics here are the maintenance processes and maintenance activities.
Techniques for Maintenance constitute the fourth subarea.
These include program comprehension, re-engineering, and reverse engineering.
SOFTWARE CONFIGURATION MANAGEMENT (SEE FIGURE 3, COLUMN F)
Software Configuration Management (SCM) is the discipline of identifying the configuration of software at distinct points in time for the purpose of systematically controlling changes to the configuration and of maintaining the integrity and traceability of the configuration throughout the system life cycle. This KA includes six subareas.
The first subarea is Management of the SCM Process. It covers the topics of the organizational context for SCM, constraints and guidance for SCM, planning for SCM, the SCM plan itself, and surveillance of SCM.
The second subarea is Software Configuration Identification, which identifies items to be controlled, establishes identification schemes for the items and their versions, and establishes the tools and techniques to be used in acquiring and managing controlled items. The first topics in this subarea are identification of the items to be controlled and the software library.
The third subarea is Software Configuration Control, which is the management of changes during the software life cycle. The topics are: first, requesting, evaluating, and approving software changes; second, implementing software changes; and third, deviations and waivers.
The fourth subarea is Software Configuration Status Accounting. Its topics are software configuration status information and software configuration status reporting.
The fifth subarea is Software Configuration Auditing. It consists of software functional configuration auditing, software physical configuration auditing, and in-process audits of a software baseline.
The last subarea is Software Release Management and Delivery, covering software building and software release management.
SOFTWARE ENGINEERING MANAGEMENT (SEE FIGURE 3, COLUMN G)
The Software Engineering Management KA addresses the management and measurement of software engineering. While measurement is an important aspect of all KAs, it is here that the topic of measurement programs is presented. There are six subareas for software engineering management. The first five cover software project management and the sixth describes software measurement programs.
The first subarea is Initiation and Scope Definition, which comprises determination and negotiation of requirements, feasibility analysis, and process for the review and revision of requirements.
The second subarea is Software Project Planning and includes process planning, determining deliverables, effort, schedule and cost estimation, resource allocation, risk management, quality management, and plan management.
The third subarea is Software Project Enactment. The topics here are implementation of plans, supplier contract management, implementation of measurement process, monitor process, control process, and reporting.
The fourth subarea is Review and Evaluation, which includes the topics of determining satisfaction of requirements and reviewing and evaluating performance.
The fifth subarea describes Closure: determining closure and closure activities.
Finally, the sixth subarea describes Software Engineering Measurement, more specifically, measurement programs. Product and process measures are described in the Software Engineering Process KA. Many of the other KAs also describe measures specific to their KA. The topics of this subarea include establishing and sustaining measurement commitment, planning the measurement process, performing the measurement process, and evaluating measurement.
SOFTWARE ENGINEERING PROCESS (SEE FIGURE 3, COLUMN H)
The Software Engineering Process KA is concerned with the definition, implementation, assessment, measurement, management, change, and improvement of the software engineering process itself. It is divided into four subareas.
The first subarea presents Process Implementation and Change. The topics here are process infrastructure, the software process management cycle, models for process implementation and change, and practical considerations.
The second subarea deals with Process Definition. It includes the topics of software life cycle models, software life cycle processes, notations for process definitions, process adaptation, and automation.
The third subarea is Process Assessment. The topics here include process assessment models and process assessment methods.
The fourth subarea describes Process and Product Measurements. The software engineering process covers general product measurement, as well as process measurement in general. Measurements specific to KAs are described in the relevant KA. The topics are process measurement, software product measurement, quality of measurement results, software information models, and process measurement techniques.
SOFTWARE ENGINEERING TOOLS AND METHODS (SEE FIGURE 3, COLUMN I)
The Software Engineering Tools and Methods KA includes both software engineering tools and software engineering methods.
The Software Engineering Tools subarea uses the same structure as the Guide itself, with one topic for each of the other nine software engineering KAs. An additional topic is provided: miscellaneous tools issues, such as tool integration techniques, which are potentially applicable to all classes of tools.
The Software Engineering Methods subarea is divided into four subsections: heuristic methods dealing with informal approaches, formal methods dealing with mathematically based approaches, and prototyping methods dealing with software development approaches based on various forms of prototyping.
SOFTWARE QUALITY (SEE FIGURE 3, COLUMN J)
The Software Quality KA deals with software quality considerations which transcend the software life cycle processes. Since software quality is a ubiquitous concern in software engineering, it is also considered in many of the other KAs, and the reader will notice pointers to those KAs throughout this KA. The description of this KA covers three subareas.
The first subarea describes the Software Quality Fundamentals such as software engineering culture and ethics, the value and costs of quality, models and quality characteristics, and quality improvement.
The second subarea covers Software Quality Management Processes. The topics here are software quality assurance, verification and validation, and reviews and audits.
The third and final subarea describes Practical Considerations related to software quality. The topics are software quality requirements, defect characterization, software quality management techniques, and software quality measurement.
RELATED DISCIPLINES OF SOFTWARE ENGINEERING (SEE FIGURE 3, COLUMN K)
The last chapter is entitled Related Disciplines of Software Engineering. In order to circumscribe software engineering, it is necessary to identify the disciplines with which software engineering shares a common boundary. This chapter identifies, in alphabetical order, these related disciplines. For each related discipline, and using a consensus-based recognized source as found, are identified:
The related disciplines are:
The appendix describes the specifications provided by the editorial team to the associate editors for the content, recommended references, format, and style of the KA descriptions.
The second appendix describes the project's proposal for the evolution of the Guide. The 2004 Guide is simply the current edition of a guide which will continue evolving to meet the needs of the software engineering community. Planning for evolution is not yet complete, but a tentative outline of the process is provided in this appendix. As of this writing, this process has been endorsed by the project's Industrial Advisory Board and briefed to the Board of Governors of the IEEE Computer Society but is not yet either funded or implemented.
The third appendix is an annotated table of the most relevant standards, mostly from the IEEE and the ISO, allocated to the KAs of the SWEBOK Guide.
As an aid, notably to curriculum developers (and other users), in support of the project's fifth objective, the fourth appendix rates each topic with one of a set of pedagogical categories commonly attributed to Benjamin Bloom. The concept is that educational objectives can be classified into six categories representing increasing depth: knowledge, comprehension, application, analysis, synthesis, and evaluation. Results of this exercise for all KAs can be found in Appendix D. This Appendix must not, however, be viewed as a definitive classification, but much more as a starting point.
Figure 2 First five KAs
Figure 3 Last six KAs