|
C HAPTER
1
I NTRODUCTION
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.
WHAT
IS SOFTWARE ENGINEERING?
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
WHAT
IS A RECOGNIZED PROFESSION?
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,
“The legitimization of professional authority
involves three distinctive claims: first, that the knowledge and
competence of the professional have been validated by a
community of his or her peers; second, that this consensually
validated knowledge rests on rational, scientific grounds; and
third, that the professional’s judgment and advice are oriented
toward a set of substantive values, such as health. These
aspects of legitimacy correspond to the kinds of
attributes—collegial, cognitive, and moral—usually embodied in
the term “profession.”2
WHAT
ARE THE CHARACTERISTICS OF A PROFESSION?
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:
Registration of fitness to practice via voluntary
certification
or mandatory
licensing
Specialized
skill
development
and continuing professional education
Communal support via a
professional
society
A
commitment to norms of conduct often prescribed in a
code of ethics
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.
WHAT
ARE THE OBJECTIVES OF THE SWEBOK PROJECT?
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:
-
To promote a consistent view of software
engineering worldwide
-
To clarify the place—and set the boundary—of
software engineering with respect to other disciplines such as
computer science, project management, computer engineering, and
mathematics
-
To characterize the contents of the software
engineering discipline
-
To provide a topical access to the Software
Engineering Body of Knowledge
-
To provide a foundation for curriculum
development and for individual certification and licensing
material
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)
|
Software requirements
Software design
Software construction
Software testing
Software maintenance
Software configuration management
Software engineering management
Software engineering process
Software engineering tools and methods
Software
quality |
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
|
Computer science
Management
Mathematics
|
-
Project
management
-
Quality
management
-
Software
ergonomics
-
Systems
engineering
|
HIERARCHICAL ORGANIZATION
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.
REFERENCE MATERIAL AND MATRIX
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.
DEPTH
OF TREATMENT
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 KA (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
Discover the
bounds of the software and how it must interact with its
environment
Elaborate
system requirements to software requirements
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 KA (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 KA (SEE FIGURE 2, COLUMN C)
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 (SEEFIGURE 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:
a list of
KAs.
The related disciplines
are:
|
Computer science
Management
Mathematics
|
-
Project
management
-
Quality
management
-
Software
ergonomics
-
Systems
engineering
|
APPENDICES
APPENDIX A.
KA DESCRIPTION SPECIFICATIONS
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.
A PPENDIX
B. EVOLUTION OF THE GUIDE
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.
APPENDIX C. ALLOCATION OF STANDARDS TO KAS
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.
APPENDIX D. BLOOM RATINGS
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
-
“IEEE
Standard Glossary of Software Engineering Terminology,” IEEE std
610.12-1990, 1990.
-
P. Starr,
The Social Transformation of American Medicine, Basic
Books, 1982, p. 15.
-
G. Ford
and N.E. Gibbs, A Mature Profession of Software Engineering,
Software Engineering Institute, Carnegie Mellon University,
Pittsburgh, Pa., tech. report CMU/SEI-96-TR-004, Jan. 1996.
-
A
Guide to the Project Management Body of Knowledge, 2000 ed.,
Project Management Institute,
www.pmi.org.
|
