Professional Documents
Culture Documents
SWEBOK Software Engineering PDF
SWEBOK Software Engineering PDF
Body of Knowledge
Version 3.0
SWEBOK ®
Version 3.0
Editors
Reference to any specific commercial products, process, or service does not imply endorsement by IEEE. The views and opin-
ions expressed in this work do not necessarily reflect those of IEEE.
IEEE makes this document available on an “as is” basis and makes no warranty, express or implied, as to the accuracy, capabil-
ity, efficiency merchantability, or functioning of this document. In no event will IEEE be liable for any general, consequential,
indirect, incidental, exemplary, or special damages, even if IEEE has been advised of the possibility of such damages.
Digital copies of SWEBOK Guide V3.0 may be downloaded free of charge for personal and academic use via www.swebok.org.
IEEE Computer Society Products and Services. The world-renowned IEEE Computer Society publishes, promotes, and dis-
tributes a wide variety of authoritative computer science and engineering journals, magazines, conference proceedings, and
professional education products. Visit the Computer Society at w
ww.computer.org for more information.
TABLE OF CONTENTS
Forewordxvii
Foreword to the 2004 Edition xix
Editorsxxi
Coeditorsxxi
Contributing Editors xxi
Change Control Board xxi
Knowledge Area Editors xxiii
Knowledge Area Editors of Previous SWEBOK Versions xxv
Review Team xxvii
Acknowledgements xxix
Professional Activities Board, 2013 Membership xxix
Motions Regarding the Approval of SWEBOK Guide V3.0 xxx
Motions Regarding the Approval of SWEBOK Guide 2004 Version xxx
Introduction to the Guide xxxi
v
vi SWEBOK® Guide V3.0
3.2. Writing 11-11
3.3. Team and Group Communication 11-11
3.4. Presentation Skills 11-12
Matrix of Topics vs. Reference Material 11-13
5.2. Simulation 15-11
5.3. Prototyping 15-11
6. Standards 15-12
7. Root Cause Analysis 15-12
7.1. Techniques for Conducting Root Cause Analysis 15-13
Matrix of Topics vs. Reference Material 15-14
Every profession is based on a body of knowl- In 1958, John Tukey, the world-renowned stat-
edge, although that knowledge is not always istician, coined the term software. The term soft-
defined in a concise manner. In cases where no ware engineering was used in the title of a NATO
formality exists, the body of knowledge is “gen- conference held in Germany in 1968. The IEEE
erally recognized” by practitioners and may Computer Society first published its Transactions
be codified in a variety of ways for a variety of on Software Engineering in 1972, and a commit-
different uses. But in many cases, a guide to a tee for developing software engineering stan-
body of knowledge is formally documented, usu- dards was established within the IEEE Computer
ally in a form that permits it to be used for such Society in 1976.
purposes as development and accreditation of In 1990, planning was begun for an interna-
academic and training programs, certification of tional standard to provide an overall view of soft-
specialists, or professional licensing. Generally, ware engineering. The standard was completed in
a professional society or similar body maintains 1995 with designation ISO/IEC 12207 and given
stewardship of the formal definition of a body of the title of Standard for Software Life Cycle Pro-
knowledge. cesses. The IEEE version of 12207 was published
During the past forty-five years, software engi- in 1996 and provided a major foundation for the
neering has evolved from a conference catch- body of knowledge captured in SWEBOK 2004.
phrase into an engineering profession, character- The current version of 12207 is designated as
ized by 1) a professional society, 2) standards that ISO/IEC 12207:2008 and IEEE 12207-2008; it
specify generally accepted professional practices, provides the basis for this SWEBOK V3.
3) a code of ethics, 4) conference proceedings, This Guide to the Software Engineering Body
5) textbooks, 6) curriculum guidelines and cur- of Knowledge is presented to you, the reader, as
ricula, 7) accreditation criteria and accredited a mechanism for acquiring the knowledge you
degree programs, 8) certification and licensing, need in your lifelong career development as a
and 9) this Guide to the Body of Knowledge. software engineering professional.
In this Guide to the Software Engineering Body
of Knowledge, the IEEE Computer Society pres-
ents a revised and updated version of the body of Dick Fairley, Chair
knowledge formerly documented as SWEBOK Software and Systems Engineering Committee
2004; this revised and updated version is denoted IEEE Computer Society
SWEBOK V3. This work is in partial fulfillment
of the Society’s responsibility to promote the
advancement of both theory and practice for the Don Shafer, Vice President
profession of software engineering. Professional Activities Board
It should be noted that this Guide does not IEEE Computer Society
present the entire the body of knowledge for soft-
ware engineering but rather serves as a guide to
the body of knowledge that has been developed
over more than four decades. The software engi-
neering body of knowledge is constantly evolv-
ing. Nevertheless, this Guide constitutes a valu-
able characterization of the software engineering
profession.
xvii
FOREWORD TO THE 2004 EDITION
In this Guide, the IEEE Computer Society estab- standards. These workshops involved practitio-
lishes for the first time a baseline for the body ners sharing their experiences with existing stan-
of knowledge for the field of software engineer- dards. The workshops also held sessions on plan-
ing, and the work partially fulfills the Society’s ning for future standards, including one involving
responsibility to promote the advancement of measures and metrics for software engineer-
both theory and practice in this field. In so doing, ing products and processes. The planning also
the Society has been guided by the experience resulted in IEEE Std. 1002, Taxonomy of Software
of disciplines with longer histories but was not Engineering Standards (1986), which provided a
bound either by their problems or their solutions. new, holistic view of software engineering. The
It should be noted that the Guide does not pur- standard describes the form and content of a soft-
port to define the body of knowledge but rather to ware engineering standards taxonomy. It explains
serve as a compendium and guide to the body of the various types of software engineering stan-
knowledge that has been developing and evolv- dards, their functional and external relationships,
ing over the past four decades. Furthermore, and the role of various functions participating in
this body of knowledge is not static. The Guide the software life cycle.
must, necessarily, develop and evolve as software In 1990, planning for an international stan-
engineering matures. It nevertheless constitutes dard with an overall view was begun. The plan-
a valuable element of the software engineering ning focused on reconciling the software process
infrastructure. views from IEEE Std. 1074 and the revised US
In 1958, John Tukey, the world-renowned stat- DoD standard 2167A. The revision was eventu-
istician, coined the term software. The term soft- ally published as DoD Std. 498. The international
ware engineering was used in the title of a NATO standard was completed in 1995 with designa-
conference held in Germany in 1968. The IEEE tion, ISO/IEC 12207, and given the title of Stan-
Computer Society first published its Transactions dard for Software Life Cycle Processes. Std. ISO/
on Software Engineering in 1972. The committee IEC 12207 provided a major point of departure
established within the IEEE Computer Society for the body of knowledge captured in this book.
for developing software engineering standards It was the IEEE Computer Society Board of
was founded in 1976. Governors’ approval of the motion put forward
The first holistic view of software engineer- in May 1993 by Fletcher Buckley which resulted
ing to emerge from the IEEE Computer Society in the writing of this book. The Association for
resulted from an effort led by Fletcher Buckley Computing Machinery (ACM) Council approved
to develop IEEE standard 730 for software qual- a related motion in August 1993. The two motions
ity assurance, which was completed in 1979. led to a joint committee under the leadership of
The purpose of IEEE Std. 730 was to provide Mario Barbacci and Stuart Zweben who served as
uniform, minimum acceptable requirements for cochairs. The mission statement of the joint com-
preparation and content of software quality assur- mittee was “To establish the appropriate sets(s)
ance plans. This standard was influential in com- of criteria and norms for professional practice of
pleting the developing standards in the following software engineering upon which industrial deci-
topics: configuration management, software test- sions, professional certification, and educational
ing, software requirements, software design, and curricula can be based.” The steering committee
software verification and validation. organized task forces in the following areas:
During the period 1981–1985, the IEEE Com-
puter Society held a series of workshops con- 1. Define Required Body of Knowledge and
cerning the application of software engineering Recommended Practices.
xix
xx SWEBOK® Guide V3.0
2. Define Ethics and Professional Standards. It is hoped that readers will find this book use-
3. Define Educational Curricula for undergradu- ful in guiding them toward the knowledge and
ate, graduate, and continuing education. resources they need in their lifelong career devel-
opment as software engineering professionals.
This book supplies the first component: required The book is dedicated to Fletcher Buckley in
body of knowledge and recommend practices. recognition of his commitment to promoting soft-
The code of ethics and professional practice ware engineering as a professional discipline and
for software engineering was completed in 1998 his excellence as a software engineering practi-
and approved by both the ACM Council and the tioner in radar applications.
IEEE Computer Society Board of Governors. It
has been adopted by numerous corporations and
other organizations and is included in several Leonard L. Tripp, IEEE Fellow 2003
recent textbooks. Chair, Professional Practices Committee, IEEE
The educational curriculum for undergraduates Computer Society (2001–2003)
is being completed by a joint effort of the IEEE
Computer Society and the ACM and is expected Chair, Joint IEEE Computer Society and ACM
to be completed in 2004. Steering Committee for the Establishment of
Every profession is based on a body of knowl- Software Engineering as a Profession (1998–1999)
edge and recommended practices, although they
are not always defined in a precise manner. In Chair, Software Engineering Standards Committee,
many cases, these are formally documented, usu- IEEE Computer Society (1992–1998)
ally in a form that permits them to be used for
such purposes as accreditation of academic pro-
grams, development of education and training
programs, certification of specialists, or profes-
sional licensing. Generally, a professional society
or related body maintains custody of such a for-
mal definition. In cases where no such formality
exists, the body of knowledge and recommended
practices are “generally recognized” by practitio-
ners and may be codified in a variety of ways for
different uses.
EDITORS
Pierre Bourque, Department of Software and IT Engineering, École de technologie supérieure (ÉTS),
Canada, pierre.bourque@etsmtl.ca
Richard E. (Dick) Fairley, Software and Systems Engineering Associates (S2EA), USA,
dickfairley@gmail.com
COEDITORS
Alain Abran, Department of Software and IT Engineering, École de technologie supérieure (ÉTS),
Canada, alain.abran@etsmtl.ca
Juan Garbajosa, Universidad Politecnica de Madrid (Technical University of Madrid, UPM), Spain,
juan.garbajosa@upm.es
Gargi Keeni, Tata Consultancy Services, India, gargi@ieee.org
Beijun Shen, School of Software, Shanghai Jiao Tong University, China, bjshen@sjtu.edu.cn
CONTRIBUTING EDITORS
The following persons served on the SWEBOK Guide V3 Change Control Board:
Pierre Bourque
Richard E. (Dick) Fairley, Chair
Dennis Frailey
Michael Gayle
Thomas Hilburn
Paul Joannou
James W. Moore
Don Shafer
Steve Tockey
xxi
KNOWLEDGE AREA EDITORS
Software Requirements
Gerald Kotonya, School of Computing and Communications, Lancaster University, UK,
gerald@comp.lancs.ac.uk
Peter Sawyer, School of Computing and Communications, Lancaster University, UK,
sawyer@comp.lancs.ac.uk
Software Design
Yanchun Sun, School of Electronics Engineering and Computer Science, Peking University, China,
sunyc@pku.edu.cn
Software Construction
Xin Peng, Software School, Fudan University, China, pengxin@fudan.edu.cn
Software Testing
Antonia Bertolino, ISTI-CNR, Italy, antonia.bertolino@isti.cnr.it
Eda Marchetti, ISTI-CNR, Italy, eda.marchetti@isti.cnr.it
Software Maintenance
Alain April, École de technologie supérieure (ÉTS), Canada, alain.april@etsmtl.ca
Mira Kajko-Mattsson, School of Information and Communication Technology,
KTH Royal Institute of Technology, mekm2@kth.se
Software Quality
J. David Blaine, USA, jdavidblaine@gmail.com
Durba Biswas, Tata Consultancy Services, India, durba.biswas@tcs.com
xxiii
xxiv SWEBOK® Guide V3.0
Computing Foundations
Hengming Zou, Shanghai Jiao Tong University, China, zou@sjtu.edu.cn
Mathematical Foundations
Nabendu Chaki, University of Calcutta, India, nabendu@ieee.org
Engineering Foundations
Amitava Bandyopadhayay, Indian Statistical Institute, India, bamitava@isical.ac.in
Mary Jane Willshire, Software and Systems Engineering Associates (S2EA), USA,
mj.fairley@gmail.com
The following persons served as Associate Editors for either the Trial version published in 2001 or for
the 2004 version.
Software Requirements
Peter Sawyer, Computing Department, Lancaster University, UK
Gerald Kotonya, Computing Department, Lancaster University, UK
Software Design
Guy Tremblay, Département d’informatique, UQAM, Canada
Software Construction
Steve McConnell, Construx Software, USA
Terry Bollinger, the MITRE Corporation, USA
Philippe Gabrini, Département d’informatique, UQAM, Canada
Louis Martin, Département d’informatique, UQAM, Canada
Software Testing
Antonia Bertolino, ISTI-CNR, Italy
Eda Marchetti, ISTI-CNR, Italy
Software Maintenance
Thomas M. Pigoski, Techsoft Inc., USA
Alain April, École de technologie supérieure, Canada
xxv
xxvi SWEBOK® Guide V3.0
Software Quality
Alain April, École de technologie supérieure, Canada
Dolores Wallace, retired from the National Institute of Standards and Technology, USA
Larry Reeker, NIST, USA
References Editor
Marc Bouisset, Département d’informatique, UQAM
REVIEW TEAM
The people listed below participated in the public review process of SWEBOK Guide V3. Member-
ship of the IEEE Computer Society was not a requirement to participate in this review process, and
membership information was not requested from reviewers. Over 1500 individual comments were
collected and duly adjudicated.
xxvii
xxviii SWEBOK® Guide V3.0
Funding for the development of SWEBOK Guide various ways: Pieter Botman, Evan Butterfield,
V3 has been provided by the IEEE Computer Carine Chauny, Pierce Gibbs, Diane Girard, John
Society. The editors and coeditors appreciate the Keppler, Dorian McClenahan, Kenza Meridji, Sam-
important work performed by the KA editors and uel Redwine, Annette Reilly, and Pam Thompson.
the contributing editors as well as by the the mem- Finally, there are surely other people who have
bers of the Change Control Board. The editorial contributed to this Guide, either directly or indi-
team must also acknowledge the indispensable rectly, whose names we have inadvertently omit-
contribution of reviewers. ted. To those people, we offer our tacit appre-
The editorial team also wishes to thank the fol- ciation and apologize for having omitted explicit
lowing people who contributed to the project in recognition.
xxix
xxx SWEBOK® Guide V3.0
The SWEBOK Guide V3.0 was submitted to ballot by verified IEEE Computer Society members in
November 2013 with the following question: “Do you approve this manuscript of the SWEBOK Guide
V3.0 to move forward to formatting and publication?”
The results of this ballot were 259 Yes votes and 5 No votes.
The following motion was unanimously adopted by the Professional Activities Board of the IEEE Com-
puter Society in December 2013:
The Professional Activities Board of the IEEE Computer Society finds that the Guide to the Soft-
ware Engineering Body of Knowledge Version 3.0 has been successfully completed; and endorses
the Guide to the Software Engineering Body of Knowledge Version 3.0 and commends it to the
IEEE Computer Society Board of Governors for their approval.
The following motion was adopted by the IEEE Computer Society Board of Governors in December 2013:
MOVED, that the Board of Governors of the IEEE Computer Society approves Version 3.0 of the
Guide to the Software Engineering Body of Knowledge and authorizes the Chair of the Profes-
sional Activities Board to proceed with printing.
The following motion was unanimously adopted by the Industrial Advisory Board of the SWEBOK Guide
project in February 2004:
The Industrial Advisory Board finds that the Software Engineering Body of Knowledge project ini-
tiated in 1998 has been successfully completed; and endorses the 2004 Version of the Guide to the
SWEBOK and commends it to the IEEE Computer Society Board of Governors for their approval.
The following motion was adopted by the IEEE Computer Society Board of Governors in February 2004:
MOVED, that the Board of Governors of the IEEE Computer Society approves the 2004 Edition of
the Guide to the Software Engineering Body of Knowledge and authorizes the Chair of the Profes-
sional Practices Committee to proceed with printing.
Please also note that the 2004 edition of the Guide to the Software Engineering Body of Knowledge
was submitted by the IEEE Computer Society to ISO/IEC without any change and was recognized as
Technical Report ISO/IEC TR 19759:2005.
INTRODUCTION TO THE GUIDE
KA Knowledge Area
literature. The purpose of the Guide is to describe
Software Engineering Body of
SWEBOK the portion of the Body of Knowledge that is gen-
Knowledge
erally accepted, to organize that portion, and to
provide topical access to it.
Publication of the 2004 version of this Guide to the The Guide to the Software Engineering Body
Software Engineering Body of Knowledge (SWE- of Knowledge (SWEBOK Guide) was established
BOK 2004) was a major milestone in establishing with the following five objectives:
software engineering as a recognized engineering
discipline. The goal in developing this update to 1. To promote a consistent view of software
SWEBOK is to improve the currency, readability, engineering worldwide
consistency, and usability of the Guide. 2. To specify the scope of, and clarify the place
All knowledge areas (KAs) have been updated of software engineering with respect to other
to reflect changes in software engineering since disciplines such as computer science, proj-
publication of SWEBOK 2004. Four new foun- ect management, computer engineering, and
dation KAs and a Software Engineering Profes- mathematics
sional Practices KA have been added. The Soft- 3. To characterize the contents of the software
ware Engineering Tools and Methods KA has engineering discipline
been revised as Software Engineering Models 4. To provide a topical access to the Software
and Methods. Software engineering tools is now Engineering Body of Knowledge
a topic in each of the KAs. Three appendices pro- 5. To provide a foundation for curriculum
vide the specifications for the KA description, an development and for individual certification
annotated set of relevant standards for each KA, and licensing material
and a listing of the references cited in the Guide.
This Guide, written under the auspices of the The first of these objectives, a consistent world-
Professional Activities Board of the IEEE Com- wide view of software engineering, was supported
puter Society, represents a next step in the evolu- by a development process which engaged approxi-
tion of the software engineering profession. mately 150 reviewers from 33 countries. More
information regarding the development process can
WHAT IS SOFTWARE ENGINEERING? be found on the website (www.swebok.org). Pro-
fessional and learned societies and public agencies
ISO/IEC/IEEE Systems and Software Engineering involved in software engineering were contacted,
Vocabulary (SEVOCAB) defines software engi- made aware of this project to update SWEBOK, and
neering as “the application of a systematic, disci- invited to participate in the review process. KA edi-
plined, quantifiable approach to the development, tors were recruited from North America, the Pacific
operation, and maintenance of software; that is, the Rim, and Europe. Presentations on the project were
application of engineering to software).”1 made at various international venues.
The second of the objectives, the desire to
WHAT ARE THE OBJECTIVES OF THE specify the scope of software engineering, moti-
SWEBOK GUIDE? vates the fundamental organization of the Guide.
The material that is recognized as being within
The Guide should not be confused with the Body this discipline is organized into the fifteen KAs
of Knowledge itself, which exists in the published listed in Table I.1. Each of these KAs is treated in
a chapter in this Guide.
1 See www.computer.org/sevocab.
xxxi
xxxii SWEBOK® Guide V3.0
certification, and licensing, the criterion of gen- The breakdown of topics in each KA consti-
erally accepted knowledge has been applied, to tutes the core the KA description, describing
be distinguished from advanced and research the decomposition of the KA into subareas, top-
knowledge (on the grounds of maturity) and from ics, and sub-topics. For each topic or subtopic, a
specialized knowledge (on the grounds of gener- short description is given, along with one or more
ality of application). references.
The equivalent term generally recognized The reference material was chosen because it is
comes from the Project Management Institute: considered to constitute the best presentation of
“Generally recognized means the knowledge the knowledge relative to the topic. A matrix links
and practices described are applicable to most the topics to the reference material.
projects most of the time, and there is consensus The last part of each KA description is the list
about their value and usefulness.”2 of recommended references and (optionally) fur-
However, the terms “generally accepted” or ther readings. Relevant standards for each KA are
“generally recognized” do not imply that the des- presented in Appendix B of the Guide.
ignated knowledge should be uniformly applied
to all software engineering endeavors—each proj- APPENDIX A. KA DESCRIPTION
ect’s needs determine that—but it does imply that SPECIFICATIONS
competent, capable software engineers should
be equipped with this knowledge for potential Appendix A describes the specifications provided
application. More precisely, generally accepted by the editorial team to the associate editors for
knowledge should be included in the study mate- the content, recommended references, format,
rial for the software engineering licensing exami- and style of the KA descriptions.
nation that graduates would take after gaining
four years of work experience. Although this cri- APPENDIX B. ALLOCATION OF STAN-
terion is specific to the US style of education and DARDS TO KAS
does not necessarily apply to other countries, we
deem it useful. Appendix B is an annotated list of the relevant
standards, mostly from the IEEE and the ISO, for
STRUCTURE OF THE KA DESCRIPTIONS each of the KAs of the SWEBOK Guide.
SOFTWARE REQUIREMENTS
1-1
1-2 SWEBOK® Guide V3.0
order to solve some problem in the real world. It requirements can be verified within available
may aim to automate part of a task for someone resource constraints.
to support the business processes of an organiza- Requirements have other attributes in addi-
tion, to correct shortcomings of existing software, tion to behavioral properties. Common examples
or to control a device—to name just a few of the include a priority rating to enable tradeoffs in
many problems for which software solutions are the face of finite resources and a status value to
possible. The ways in which users, business pro- enable project progress to be monitored. Typi-
cesses, and devices function are typically complex. cally, software requirements are uniquely identi-
By extension, therefore, the requirements on par- fied so that they can be subjected to software con-
ticular software are typically a complex combina- figuration management over the entire life cycle
tion from various people at different levels of an of the feature and of the software.
organization, and who are in one way or another
involved or connected with this feature from the 1.2. Product and Process Requirements
environment in which the software will operate.
An essential property of all software require- A product requirement is a need or constraint on
ments is that they be verifiable as an individual the software to be developed (for example, “The
feature as a functional requirement or at the software shall verify that a student meets all pre-
system level as a nonfunctional requirement. It requisites before he or she registers for a course”).
may be difficult or costly to verify certain soft- A process requirement is essentially a con-
ware requirements. For example, verification straint on the development of the software (for
of the throughput requirement on a call center example, “The software shall be developed using
may necessitate the development of simulation a RUP process”).
software. Software requirements, software test- Some software requirements generate implicit
ing, and quality personnel must ensure that the process requirements. The choice of verification
Software Requirements 1-3
technique is one example. Another might be the depend for their interpretation on subjective
use of particularly rigorous analysis techniques judgment (“the software shall be reliable”; “the
(such as formal specification methods) to reduce software shall be user-friendly”). This is par-
faults that can lead to inadequate reliability. Pro- ticularly important for nonfunctional require-
cess requirements may also be imposed directly ments. Two examples of quantified requirements
by the development organization, their customer, are the following: a call center’s software must
or a third party such as a safety regulator. increase the center’s throughput by 20%; and a
system shall have a probability of generating a
1.3. Functional and Nonfunctional Requirements fatal error during any hour of operation of less
than 1 * 10−8. The throughput requirement is at a
Functional requirements describe the functions very high level and will need to be used to derive
that the software is to execute; for example, for- a number of detailed requirements. The reliabil-
matting some text or modulating a signal. They ity requirement will tightly constrain the system
are sometimes known as capabilities or features. architecture.
A functional requirement can also be described
as one for which a finite set of test steps can be 1.6. System Requirements and Software
written to validate its behavior. Requirements
Nonfunctional requirements are the ones that
act to constrain the solution. Nonfunctional In this topic, “system” means
requirements are sometimes known as constraints
or quality requirements. They can be further clas- an interacting combination of elements
sified according to whether they are performance to accomplish a defined objective. These
requirements, maintainability requirements, include hardware, software, firmware,
safety requirements, reliability requirements, people, information, techniques, facilities,
security requirements, interoperability require- services, and other support elements,
ments or one of many other types of software
requirements (see Models and Quality Character- as defined by the International Council on Soft-
istics in the Software Quality KA). ware and Systems Engineering (INCOSE) [3].
System requirements are the requirements for
1.4. Emergent Properties the system as a whole. In a system containing
software components, software requirements are
Some requirements represent emergent proper- derived from system requirements.
ties of software—that is, requirements that can- This KA defines “user requirements” in a
not be addressed by a single component but that restricted way, as the requirements of the sys-
depend on how all the software components tem’s customers or end users. System require-
interoperate. The throughput requirement for a ments, by contrast, encompass user requirements,
call center would, for example, depend on how requirements of other stakeholders (such as regu-
the telephone system, information system, and latory authorities), and requirements without an
the operators all interacted under actual operat- identifiable human source.
ing conditions. Emergent properties are crucially
dependent on the system architecture. 2. Requirements Process
[1*, c4s4] [2*, c1–4, c6, c22, c23]
1.5. Quantifiable Requirements
This section introduces the software requirements
Software requirements should be stated as clearly process, orienting the remaining five topics and
and as unambiguously as possible, and, where showing how the requirements process dovetails
appropriate, quantitatively. It is important to with the overall software engineering process.
avoid vague and unverifiable requirements that
1-4 SWEBOK® Guide V3.0
cost and timeliness of a software product and of to ensure the customer’s most important business
the customer’s satisfaction with it. It will help to needs are satisfied first. This minimizes the risk
orient the requirements process with quality stan- of requirements specialists spending time elicit-
dards and process improvement models for soft- ing requirements that are of low importance, or
ware and systems. Process quality and improve- those that turn out to be no longer relevant when
ment is closely related to both the Software the software is delivered. On the other hand, the
Quality KA and Software Engineering Process description must be scalable and extensible to
KA, comprising accept further requirements not expressed in the
first formal lists and compatible with the previous
• requirements process coverage by process ones as contemplated in recursive methods.
improvement standards and models;
• requirements process measures and 3.1. Requirements Sources
benchmarking;
• improvement planning and implementation; Requirements have many sources in typical soft-
• security/CIA improvement/planning and ware, and it is essential that all potential sources
implementation. be identified and evaluated. This topic is designed
to promote awareness of the various sources of
3. Requirements Elicitation software requirements and of the frameworks for
[1*, c4s5] [2*, c5, c6, c9] managing them. The main points covered are as
follows:
Requirements elicitation is concerned with the
origins of software requirements and how the • Goals. The term “goal” (sometimes called
software engineer can collect them. It is the first “business concern” or “critical success fac-
stage in building an understanding of the problem tor”) refers to the overall, high-level objec-
the software is required to solve. It is fundamen- tives of the software. Goals provide the moti-
tally a human activity and is where the stakehold- vation for the software but are often vaguely
ers are identified and relationships established formulated. Software engineers need to pay
between the development team and the customer. particular attention to assessing the value
It is variously termed “requirements capture,” (relative to priority) and cost of goals. A fea-
“requirements discovery,” and “requirements sibility study is a relatively low-cost way of
acquisition.” doing this.
One of the fundamental principles of a good • Domain knowledge. The software engineer
requirements elicitation process is that of effec- needs to acquire or have available knowl-
tive communication between the various stake- edge about the application domain. Domain
holders. This communication continues through knowledge provides the background against
the entire Software Development Life Cycle which all elicited requirements knowledge
(SDLC) process with different stakeholders at must be set in order to understand it. It’s
different points in time. Before development a good practice to emulate an ontological
begins, requirements specialists may form the approach in the knowledge domain. Rela-
conduit for this communication. They must medi- tions between relevant concepts within the
ate between the domain of the software users (and application domain should be identified.
other stakeholders) and the technical world of the • Stakeholders (see section 2.2, Process
software engineer. A set of internally consistent Actors). Much software has proved unsat-
models at different levels of abstraction facilitate isfactory because it has stressed the require-
communications between software users/stake- ments of one group of stakeholders at the
holders and software engineers. expense of others. Hence, the delivered
A critical element of requirements elicitation is software is difficult to use, or subverts the
informing the project scope. This involves provid- cultural or political structures of the cus-
ing a description of the software being specified tomer organization. The software engineer
and its purpose and prioritizing the deliverables needs to identify, represent, and manage
1-6 SWEBOK® Guide V3.0
the “viewpoints” of many different types of has yet to be obtained from end users. The impor-
stakeholders. tance of planning, verification, and validation in
• Business rules. These are statements that requirements elicitation cannot be overstated. A
define or constrain some aspect of the struc- number of techniques exist for requirements elici-
ture or the behavior of the business itself. “A tation; the principal ones are these:
student cannot register in next semester’s
courses if there remain some unpaid tuition • Interviews. Interviewing stakeholders is a
fees” would be an example of a business rule “traditional” means of eliciting requirements.
that would be a requirement source for a uni- It is important to understand the advantages
versity’s course-registration software. and limitations of interviews and how they
• The operational environment. Requirements should be conducted.
will be derived from the environment in • Scenarios. Scenarios provide a valuable
which the software will be executed. These means for providing context to the elicita-
may be, for example, timing constraints tion of user requirements. They allow the
in real-time software or performance con- software engineer to provide a framework
straints in a business environment. These for questions about user tasks by permitting
must be sought out actively because they can “what if” and “how is this done” questions
greatly affect software feasibility and cost as to be asked. The most common type of sce-
well as restrict design choices. nario is the use case description. There is a
• The organizational environment. Software link here to topic 4.2 (Conceptual Modeling)
is often required to support a business pro- because scenario notations such as use case
cess, the selection of which may be condi- diagrams are common in modeling software.
tioned by the structure, culture, and internal • Prototypes. This technique is a valuable tool
politics of the organization. The software for clarifying ambiguous requirements. They
engineer needs to be sensitive to these since, can act in a similar way to scenarios by pro-
in general, new software should not force viding users with a context within which they
unplanned change on the business process. can better understand what information they
need to provide. There is a wide range of
3.2. Elicitation Techniques prototyping techniques—from paper mock-
ups of screen designs to beta-test versions of
Once the requirements sources have been iden- software products—and a strong overlap of
tified, the software engineer can start eliciting their separate uses for requirements elicita-
requirements information from them. Note that tion and for requirements validation (see
requirements are seldom elicited ready-made. section 6.2, Prototyping). Low fidelity proto-
Rather, the software engineer elicits information types are often preferred to avoid stakeholder
from which he or she formulates requirements. “anchoring” on minor, incidental character-
This topic concentrates on techniques for getting istics of a higher quality prototype that can
human stakeholders to articulate requirements- limit design flexibility in unintended ways.
relevant information. It is a very difficult task and • Facilitated meetings. The purpose of these
the software engineer needs to be sensitized to the meetings is to try to achieve a summative
fact that (for example) users may have difficulty effect, whereby a group of people can bring
describing their tasks, may leave important infor- more insight into their software require-
mation unstated, or may be unwilling or unable to ments than by working individually. They
cooperate. It is particularly important to understand can brainstorm and refine ideas that may be
that elicitation is not a passive activity and that, difficult to bring to the surface using inter-
even if cooperative and articulate stakeholders are views. Another advantage is that conflicting
available, the software engineer has to work hard requirements surface early on in a way that
to elicit the right information. Many business or lets the stakeholders recognize where these
technical requirements are tacit or in feedback that occur. When it works well, this technique
Software Requirements 1-7
Reviews may be constituted on completion of domain, exchange data. If formal analysis nota-
the system definition document, the system spec- tions are used, it is possible to use formal reason-
ification document, the software requirements ing to prove specification properties. This topic is
specification document, the baseline specifica- closely related to the Software Engineering Mod-
tion for a new release, or at any other step in the els and Methods KA.
process.
6.4. Acceptance Tests
6.2. Prototyping
An essential property of a software requirement
Prototyping is commonly a means for validating is that it should be possible to validate that the
the software engineer’s interpretation of the soft- finished product satisfies it. Requirements that
ware requirements, as well as for eliciting new cannot be validated are really just “wishes.” An
requirements. As with elicitation, there is a range important task is therefore planning how to ver-
of prototyping techniques and a number of points ify each requirement. In most cases, designing
in the process where prototype validation may acceptance tests does this for how end-users typi-
be appropriate. The advantage of prototypes is cally conduct business using the system.
that they can make it easier to interpret the soft- Identifying and designing acceptance tests
ware engineer’s assumptions and, where needed, may be difficult for nonfunctional requirements
give useful feedback on why they are wrong. For (see section 1.3, Functional and Nonfunctional
example, the dynamic behavior of a user inter- Requirements). To be validated, they must first
face can be better understood through an ani- be analyzed and decomposed to the point where
mated prototype than through textual description they can be expressed quantitatively.
or graphical models. The volatility of a require- Additional information can be found in Accep-
ment that is defined after prototyping has been tance/Qualification/Conformance Testing in the
done is extremely low because there is agreement Software Testing KA.
between the stakeholder and the software engi-
neer—therefore, for safety-critical and crucial 7. Practical Considerations
features prototyping would really help. There are [1*, c4s1, c4s4, c4s6, c4s7]
also disadvantages, however. These include the [2*, c3, c12, c14, c16, c18–21]
danger of users’ attention being distracted from
the core underlying functionality by cosmetic The first level of topic decomposition pre-
issues or quality problems with the prototype. For sented in this KA may seem to describe a linear
this reason, some advocate prototypes that avoid sequence of activities. This is a simplified view
software, such as flip-chart-based mockups. Pro- of the process.
totypes may be costly to develop. However, if The requirements process spans the whole
they avoid the wastage of resources caused by software life cycle. Change management and the
trying to satisfy erroneous requirements, their maintenance of the requirements in a state that
cost can be more easily justified. Early proto- accurately mirrors the software to be built, or that
types may contain aspects of the final solution. has been built, are key to the success of the soft-
Prototypes may be evolutionary as opposed to ware engineering process.
throwaway. Not every organization has a culture of docu-
menting and managing requirements. It is com-
6.3. Model Validation mon in dynamic start-up companies, driven by a
strong “product vision” and limited resources, to
It is typically necessary to validate the quality of view requirements documentation as unnecessary
the models developed during analysis. For exam- overhead. Most often, however, as these compa-
ple, in object models, it is useful to perform a nies expand, as their customer base grows, and
static analysis to verify that communication paths as their product starts to evolve, they discover
exist between objects that, in the stakeholders’ that they need to recover the requirements that
Software Requirements 1-13
motivated product features in order to assess the proceeds. This often leads to the revision of
impact of proposed changes. Hence, requirements requirements late in the life cycle. Perhaps the
documentation and change management are key most crucial point in understanding software
to the success of any requirements process. requirements is that a significant proportion of
the requirements will change. This is sometimes
7.1. Iterative Nature of the Requirements due to errors in the analysis, but it is frequently an
Process inevitable consequence of change in the “environ-
ment”—for example, the customer’s operating
There is general pressure in the software indus- or business environment, regulatory processes
try for ever shorter development cycles, and this imposed by the authorities, or the market into
is particularly pronounced in highly competitive, which software must sell. Whatever the cause, it is
market-driven sectors. Moreover, most projects important to recognize the inevitability of change
are constrained in some way by their environment, and take steps to mitigate its effects. Change has
and many are upgrades to, or revisions of, exist- to be managed by ensuring that proposed changes
ing software where the architecture is a given. In go through a defined review and approval pro-
practice, therefore, it is almost always impractical cess and by applying careful requirements trac-
to implement the requirements process as a linear, ing, impact analysis, and software configuration
deterministic process in which software require- management (see the Software Configuration
ments are elicited from the stakeholders, base- Management KA). Hence, the requirements pro-
lined, allocated, and handed over to the software cess is not merely a front-end task in software
development team. It is certainly a myth that the development, but spans the whole software life
requirements for large software projects are ever cycle. In a typical project, the software require-
perfectly understood or perfectly specified. ments activities evolve over time from elicitation
Instead, requirements typically iterate towards to change management. A combination of top-
a level of quality and detail that is sufficient to down analysis and design methods and bottom-
permit design and procurement decisions to be up implementation and refactoring methods that
made. In some projects, this may result in the meet in the middle could provide the best of both
requirements being baselined before all their worlds. However, this is difficult to achieve in
properties are fully understood. This risks expen- practice, as it depends heavily upon the maturity
sive rework if problems emerge late in the soft- and expertise of the software engineers.
ware engineering process. However, software
engineers are necessarily constrained by project 7.2. Change Management
management plans and must therefore take steps
to ensure that the “quality” of the requirements is Change management is central to the management
as high as possible given the available resources. of requirements. This topic describes the role of
They should, for example, make explicit any change management, the procedures that need to
assumptions that underpin the requirements as be in place, and the analysis that should be applied
well as any known problems. to proposed changes. It has strong links to the Soft-
For software products that are developed iter- ware Configuration Management KA.
atively, a project team may baseline only those
requirements needed for the current iteration. The 7.3. Requirements Attributes
requirements specialist can continue to develop
requirements for future iterations, while develop- Requirements should consist not only of a speci-
ers proceed with design and construction of the fication of what is required, but also of ancillary
current iteration. This approach provides custom- information, which helps manage and interpret
ers with business value quickly, while minimiz- the requirements. Requirements attributes must
ing the cost of rework. be defined, recorded, and updated as the soft-
In almost all cases, requirements understanding ware under development or maintenance evolves.
continues to evolve as design and development This should include the various classification
1-14 SWEBOK® Guide V3.0
Sommerville 2011
Wiegers 2003
[2*]
[1*]
1. Software Requirements Fundamentals
1.1. Definition of a Software Requirement c4 c1
1.2. Product and Process Requirements c4s1 c1, c6
1.3. Functional and Nonfunctional Requirements c4s1 c12
1.4. Emergent Properties c10s1
1.5. Quantifiable Requirements c1
1.6. System Requirements and Software Requirements c10s4 c1
2. Requirements Process
2.1. Process Models c4s4 c3
2.2. Process Actors c1, c2, c4, c6
2.3. Process Support and Management c3
2.4. Process Quality and Improvement c22, c23
3. Requirements Elicitation
3.1. Requirements Sources c4s5 c5, c6,c9
3.2. Elicitation Techniques c4s5 c6
4. Requirements Analysis
4.1. Requirements Classification c4s1 c12
4.2. Conceptual Modeling c4s5 c11
4.3. Architectural Design and Requirements Allocation c10s4 c17
4.4. Requirements Negotiation c4s5 c7
4.5. Formal Analysis c12s5
5. Requirements Specification
5.1. System Definition Document c4s2 c10
c4s2, c12s2,
5.2. System Requirements Specification c12s3, c12s4, c10
c12s5
5.3. Software Requirements Specification c4s3 c10
6. Requirements Validation
6.1. Requirements Reviews c4s6 c15
6.2. Prototyping c4s6 c13
6.3. Model Validation c4s6 c15
6.4. Acceptance Tests c4s6 c15
1-16 SWEBOK® Guide V3.0
Sommerville 2011
Wiegers 2003
[2*]
[1*]
7. Practical Considerations
7.1. Iterative Nature of the Requirements Process c4s4 c3, c16
7.2. Change Management c4s7 c18, c19
7.3. Requirements Attributes c4s1 c12, c14
7.4. Requirements Tracing c20
7.5. Measuring Requirements c4s6 c18
8. Software Requirements Tools c21
Software Requirements 1-17
FURTHER READINGS
I. Alexander and L. Beus-Dukic, Discovering A. van Lamsweerde, Requirements
Requirements [5]. Engineering: From System Goals to UML
Models to Software Specifications [7].
An easily digestible and practically oriented
book on software requirements, this is perhaps Serves as a good introduction to requirements
the best of current textbooks on how the various engineering but its unique value is as a reference
elements of software requirements fit together. It book for the KAOS goal-oriented requirements
is full of practical advice on (for example) how modelling language. Explains why goal model-
to identify the various system stakeholders and ling is useful and shows how it can integrate with
how to evaluate alternative solutions. Its cover- mainstream modelling techniques using UML.
age is exemplary and serves as a useful reference
for key techniques such as use case modeling and O. Gotel and A. Finkelstein, “An Analysis of the
requirements prioritization. Requirements Traceability Problem” [8].
C. Potts, K. Takahashi, and A. Antón, “Inquiry- This paper is a classic reference work on a key
Based Requirements Analysis” [6]. element of requirements management. Based on
empirical studies, it sets out the reasons for and
This paper is an easily digested account of work the barriers to the effective tracing of require-
that has proven to be very influential in the devel- ments. It is essential reading for an understanding
opment of requirements handling. It describes of why requirements tracing is an essential ele-
how and why the elaboration of requirements ment of an effective software process.
cannot be a linear process by which the analyst
simply transcribes and reformulates requirements N. Maiden and C. Ncube, “Acquiring COTS
elicited from the customer. The role of scenarios Software Selection Requirements” [9].
is described in a way that helps to define their use
in discovering and describing requirements. This paper is significant because it recognises
explicitly that software products often integrate
third-party components. It offers insights into the
problems of selecting off-the-shelf software to
satisfy requirements: there is usually a mismatch.
This challenges some of the assumptions under-
pinning much of traditional requirements han-
dling, which tends to assume custom software.
1-18 SWEBOK® Guide V3.0
REFERENCES
[1*] I. Sommerville, Software Engineering, 9th [6] C. Potts, K. Takahashi, and A.I. Antón,
ed., Addison-Wesley, 2011. “Inquiry-Based Requirements Analysis,”
IEEE Software, vol. 11, no. 2, Mar. 1994,
[2*] K.E. Wiegers, Software Requirements, 2nd pp. 21–32.
ed., Microsoft Press, 2003.
[7] A. van Lamsweerde, Requirements
[3] INCOSE, Systems Engineering Handbook: Engineering: From System Goals to UML
A Guide for System Life Cycle Processes Models to Software Specifications, Wiley,
and Activities, version 3.2.2, International 2009.
Council on Systems Engineering, 2012.
[8] O. Gotel and C.W. Finkelstein, “An Analysis
[4] S. Friedenthal, A. Moore, and R. Steiner, A of the Requirements Traceability Problem,”
Practical Guide to SysML: The Systems Proc. 1st Int’l Conf. Requirements Eng.,
Modeling Language, 2nd ed., Morgan IEEE, 1994.
Kaufmann, 2012.
[9] N.A. Maiden and C. Ncube, “Acquiring
[5] I. Alexander and L. Beus-Deukic, COTS Software Selection Requirements,”
Discovering Requirements: How to Specify IEEE Software, vol. 15, no. 2, Mar.–Apr.
Products and Services, Wiley, 2009. 1998, pp. 46–56.
CHAPTER 2
SOFTWARE DESIGN
2-1
2-2 SWEBOK® Guide V3.0
• Architectural design (also referred to as high- software is divided into a number of smaller
level design and top-level design) describes named components having well-defined
how software is organized into components. interfaces that describe component interac-
• Detailed design describes the desired behav- tions. Usually the goal is to place different
ior of these components. functionalities and responsibilities in differ-
ent components.
The output of these two processes is a set of • Encapsulation and information hiding means
models and artifacts that record the major deci- grouping and packaging the internal details
sions that have been taken, along with an explana- of an abstraction and making those details
tion of the rationale for each nontrivial decision. inaccessible to external entities.
By recording the rationale, long-term maintain- • Separation of interface and implementation.
ability of the software product is enhanced. Separating interface and implementation
involves defining a component by specify-
1.4. Software Design Principles ing a public interface (known to the clients)
[4*] [5*, c6, c7, c21] [6*, c1, c8, c9] that is separate from the details of how the
component is realized (see encapsulation and
A principle is “a comprehensive and fundamen- information hiding above).
tal law, doctrine, or assumption” [7]. Software • Sufficiency, completeness, and primitiveness.
design principles are key notions that provide Achieving sufficiency and completeness
the basis for many different software design means ensuring that a software component
approaches and concepts. Software design princi- captures all the important characteristics of
ples include abstraction; coupling and cohesion; an abstraction and nothing more. Primitive-
decomposition and modularization; encapsula- ness means the design should be based on
tion/information hiding; separation of interface patterns that are easy to implement.
and implementation; sufficiency, completeness, • Separation of concerns. A concern is an
and primitiveness; and separation of concerns. “area of interest with respect to a software
design” [8]. A design concern is an area of
• Abstraction is “a view of an object that design that is relevant to one or more of its
focuses on the information relevant to a stakeholders. Each architecture view frames
particular purpose and ignores the remain- one or more concerns. Separating concerns
der of the information” [1] (see Abstraction by views allows interested stakeholders to
in the Computing Foundations KA). In the focus on a few things at a time and offers a
context of software design, two key abstrac- means of managing complexity [9].
tion mechanisms are parameterization and
specification. Abstraction by parameteriza- 2. Key Issues in Software Design
tion abstracts from the details of data repre-
sentations by representing the data as named A number of key issues must be dealt with when
parameters. Abstraction by specification designing software. Some are quality concerns
leads to three major kinds of abstraction: that all software must address—for example,
procedural abstraction, data abstraction, and performance, security, reliability, usability, etc.
control (iteration) abstraction. Another important issue is how to decompose,
• Coupling and Cohesion. Coupling is defined organize, and package software components.
as “a measure of the interdependence among This is so fundamental that all design approaches
modules in a computer program,” whereas address it in one way or another (see section 1.4,
cohesion is defined as “a measure of the Software Design Principles, and topic 7, Soft-
strength of association of the elements within ware Design Strategies and Methods). In contrast,
a module” [1]. other issues “deal with some aspect of software’s
• Decomposition and modularization. Decom- behavior that is not in the application domain,
posing and modularizing means that large but which addresses some of the supporting
2-4 SWEBOK® Guide V3.0
domains” [10]. Such issues, which often crosscut 2.6. Interaction and Presentation
the system’s functionality, have been referred to [5*, c16]
as aspects, which “tend not to be units of soft-
ware’s functional decomposition, but rather to be This design issue is concerned with how to struc-
properties that affect the performance or seman- ture and organize interactions with users as well
tics of the components in systemic ways” [11]. as the presentation of information (for example,
A number of these key, crosscutting issues are separation of presentation and business logic
discussed in the following sections (presented in using the Model-View-Controller approach).
alphabetical order). Note that this topic does not specify user interface
details, which is the task of user interface design
2.1. Concurrency (see topic 4, User Interface Design).
[5*, c18]
2.7. Security
Design for concurrency is concerned with decom- [5*, c12, c18] [13*, c4]
posing software into processes, tasks, and threads
and dealing with related issues of efficiency, Design for security is concerned with how to pre-
atomicity, synchronization, and scheduling. vent unauthorized disclosure, creation, change,
deletion, or denial of access to information and
2.2. Control and Handling of Events other resources. It is also concerned with how to
[5*, c21] tolerate security-related attacks or violations by
limiting damage, continuing service, speeding
This design issue is concerned with how to repair and recovery, and failing and recovering
organize data and control flow as well as how securely. Access control is a fundamental con-
to handle reactive and temporal events through cept of security, and one should also ensure the
various mechanisms such as implicit invocation proper use of cryptology.
and call-backs.
3. Software Structure and Architecture
2.3. Data Persistence
[12*, c9] In its strict sense, a software architecture is
“the set of structures needed to reason about
This design issue is concerned with how to han- the system, which comprise software elements,
dle long-lived data. relations among them, and properties of both”
[14*]. During the mid-1990s, however, soft-
2.4. Distribution of Components ware architecture started to emerge as a broader
[5*, c18] discipline that involved the study of software
structures and architectures in a more generic
This design issue is concerned with how to dis- way. This gave rise to a number of interesting
tribute the software across the hardware (includ- concepts about software design at different lev-
ing computer hardware and network hardware), els of abstraction. Some of these concepts can
how the components communicate, and how be useful during the architectural design (for
middleware can be used to deal with heteroge- example, architectural styles) as well as during
neous software. the detailed design (for example, design pat-
terns). These design concepts can also be used
2.5. Error and Exception Handling and Fault to design families of programs (also known as
Tolerance product lines). Interestingly, most of these con-
[5*, c18] cepts can be seen as attempts to describe, and
thus reuse, design knowledge.
This design issue is concerned with how to pre-
vent, tolerate, and process errors and deal with
exceptional conditions.
Software Design 2-5
and control of the machine. For software to and presentation for the software, the background
achieve its full potential, the user interface should and experience of the software users, and the
be designed to match the skills, experience, and available devices.
expectations of its anticipated users.
4.3. The Design of User Interaction Modalities
4.1. General User Interface Design Principles [5*, c29-web] [17*, c2]
[5*, c29-web] [17*, c2]1
User interaction involves issuing commands and
• Learnability. The software should be easy to providing associated data to the software. User
learn so that the user can rapidly start work- interaction styles can be classified into the fol-
ing with the software. lowing primary styles:
• User familiarity. The interface should use
terms and concepts drawn from the experi- • Question-answer. The interaction is essen-
ences of the people who will use the software. tially restricted to a single question-answer
• Consistency. The interface should be consis- exchange between the user and the software.
tent so that comparable operations are acti- The user issues a question to the software,
vated in the same way. and the software returns the answer to the
• Minimal surprise. The behavior of software question.
should not surprise users. • Direct manipulation. Users interact with
• Recoverability. The interface should provide objects on the computer screen. Direct
mechanisms allowing users to recover from manipulation often includes a pointing
errors. device (such as a mouse, trackball, or a fin-
• User guidance. The interface should give ger on touch screens) that manipulates an
meaningful feedback when errors occur and object and invokes actions that specify what
provide context-related help to users. is to be done with that object.
• User diversity. The interface should pro- • Menu selection. The user selects a command
vide appropriate interaction mechanisms from a menu list of commands.
for diverse types of users and for users with • Form fill-in. The user fills in the fields of a
different capabilities (blind, poor eyesight, form. Sometimes fields include menus, in
deaf, colorblind, etc.). which case the form has action buttons for
the user to initiate action.
4.2. User Interface Design Issues • Command language. The user issues a com-
[5*, c29-web] [17*, c2] mand and provides related parameters to
direct the software what to do.
User interface design should solve two key issues: • Natural language. The user issues a com-
mand in natural language. That is, the natural
• How should the user interact with the language is a front end to a command lan-
software? guage and is parsed and translated into soft-
• How should information from the software ware commands.
be presented to the user?
4.4. The Design of Information Presentation
User interface design must integrate user [5*, c29-web] [17*, c2]
interaction and information presentation. User
interface design should consider a compromise Information presentation may be textual or graphi-
between the most appropriate styles of interaction cal in nature. A good design keeps the information
presentation separate from the information itself.
The MVC (Model-View-Controller) approach is
1 Chapter 29 is a web-based chapter available an effective way to keep information presentation
at http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/
separating from the information being presented.
WebChapters/.
Software Design 2-7
used to describe the major components and how • Activity diagrams: used to show control flow
they are interconnected (static view): from activity to activity. Can be used to rep-
resent concurrent activities.
• Architecture description languages (ADLs): • Communication diagrams: used to show
textual, often formal, languages used to the interactions that occur among a group
describe software architecture in terms of of objects; emphasis is on the objects, their
components and connectors. links, and the messages they exchange on
• Class and object diagrams: used to repre- those links.
sent a set of classes (and objects) and their • Data flow diagrams (DFDs): used to show
interrelationships. data flow among elements. A data flow dia-
• Component diagrams: used to represent a gram provides “a description based on model-
set of components (“physical and replace- ing the flow of information around a network
able part[s] of a system that [conform] to of operational elements, with each element
and [provide] the realization of a set of inter- making use of or modifying the information
faces” [18]) and their interrelationships. flowing into that element” [4*]. Data flows
• Class responsibility collaborator cards (and therefore data flow diagrams) can be
(CRCs): used to denote the names of compo- used for security analysis, as they offer iden-
nents (class), their responsibilities, and their tification of possible paths for attack and dis-
collaborating components’ names. closure of confidential information.
• Deployment diagrams: used to represent a • Decision tables and diagrams: used to rep-
set of (physical) nodes and their interrela- resent complex combinations of conditions
tionships, and, thus, to model the physical and actions.
aspects of software. • Flowcharts: used to represent the flow of
• Entity-relationship diagrams (ERDs): used control and the associated actions to be
to represent conceptual models of data stored performed.
in information repositories. • Sequence diagrams: used to show the inter-
• Interface description languages (IDLs): actions among a group of objects, with
programming-like languages used to define emphasis on the time ordering of messages
the interfaces (names and types of exported passed between objects.
operations) of software components. • State transition and state chart diagrams:
• Structure charts: used to describe the calling used to show the control flow from state to
structure of programs (which modules call, state and how the behavior of a component
and are called by, which other modules). changes based on its current state in a state
machine.
6.2. Behavioral Descriptions (Dynamic View) • Formal specification languages: textual lan-
[4*, c7, c13] [5*, c6, c7] [6*, c4, c5, c6, c7] guages that use basic notions from math-
[14*, c8] ematics (for example, logic, set, sequence)
to rigorously and abstractly define software
The following notations and languages, some component interfaces and behavior, often in
graphical and some textual, are used to describe terms of pre- and postconditions. (See also
the dynamic behavior of software systems and the Software Engineering Models and Meth-
components. Many of these notations are use- ods KA.)
ful mostly, but not exclusively, during detailed • Pseudo code and program design languages
design. Moreover, behavioral descriptions can (PDLs): structured programming-like lan-
include a rationale for design decision such as guages used to describe, generally at the
how a design will meet security requirements. detailed design stage, the behavior of a pro-
cedure or method.
2-10 SWEBOK® Guide V3.0
7. Software Design Strategies and Methods design of the mid-1980s (noun = object; verb
= method; adjective = attribute), where inheri-
There exist various general strategies to help tance and polymorphism play a key role, to the
guide the design process. In contrast with general field of component-based design, where metain-
strategies, methods are more specific in that they formation can be defined and accessed (through
generally provide a set of notations to be used reflection, for example). Although OO design’s
with the method, a description of the process to roots stem from the concept of data abstraction,
be used when following the method, and a set of responsibility-driven design has been proposed
guidelines for using the method. Such methods as an alternative approach to OO design.
are useful as a common framework for teams of
software engineers. (See also the Software Engi- 7.4. Data Structure-Centered Design
neering Models and Methods KA). [4*, c14, c15]
Brookshear 2008
Page-Jones 1999
Budgen 2003
Nielsen 1993
Allen 2008
[12*]
[13*]
[15*]
[17*]
[14*]
[5*]
[4*]
[6*]
1. Software Design
Fundamentals
1.1. General Design
c1
Concepts
1.2. The Context of
c3
Software Design
1.3. The Software
c2
Design Process
1.4. Software Design c6, c7, c1, c8,
c1
Principles c21 c9
2. Key Issues in
Software Design
2.1. Concurrency c18
2.2. Control and
c21
Handling of Events
2.3. Data Persistence c9
2.4. Distribution of
c18
Components
2.5. Error and
Exception Handling c18
and Fault Tolerance
2.6. Interaction and
c16
Presentation
c12,
2.7. Security c4
c18
3. Software Structure
and Architecture
3.1. Architectural
Structures and c1
Viewpoints
c1, c2,
3.2. Architectural
c3, c4,
Styles
c5
c3, c4,
3.3. Design Patterns
c5
Software Design 2-13
Brookshear 2008
Page-Jones 1999
Budgen 2003
Nielsen 1993
Allen 2008
[12*]
[13*]
[15*]
[17*]
[14*]
[5*]
[4*]
[6*]
3.4. Architecture
c6
Design Decisions
3.5. Families of
c6, c7,
Programs and
c16
Frameworks
4. User Interface
Design
4.1. General User
c29-
Interface Design c2
web
Principle
4.2. User Interface c29-
Design Issues web
4.3. The Design of
c29-
User Interaction
web
Modalities
4.4. The Design
c29-
of Information
web
Presentation
4.5. User Interface c29-
Design Process web
4.6. Localization and
c8, c9
Internationalization
4.7. Metaphors and
c5
Conceptual Models
5. Software Design
Quality Analysis and
Evaluation
5.1. Quality
c4
Attributes
5.2. Quality
Analysis and
c4 c24
Evaluation
Techniques
5.3. Measures c4 c24
2-14 SWEBOK® Guide V3.0
Brookshear 2008
Page-Jones 1999
Budgen 2003
Nielsen 1993
Allen 2008
[12*]
[13*]
[15*]
[17*]
[14*]
[5*]
[4*]
[6*]
6. Software Design
Notations
6.1. Structural
c4, c5,
Descriptions (Static c7 c6, c7 c7 c7
c6, c7
View)
6.2. Behavioral
c7, c13, c4, c5,
Descriptions c6, c7 c8
c18 c6, c7
(Dynamic View)
7. Software Design
Strategies and
Methods
7.1. General c8, c9,
c7
Strategies c10
7.2. Function-
Oriented c13
(Structured) Design
7.3. Object-Oriented
c16
Design
7.4. Data Structure- c14,
Centered Design c15
7.5. Component-
c17
Based Design (CBD)
c19,
7.6. Other Methods
c21
8. Software Design c10,
Tools App. A
Software Design 2-15
For roughly three decades, Roger Pressman’s [2] IEEE Std. 12207-2008 (a.k.a. ISO/IEC
Software Engineering: A Practitioner’s Approach 12207:2008) Standard for Systems and
has been one of the world’s leading textbooks in Software Engineering—Software Life Cycle
software engineering. Notably, this complemen- Processes, IEEE, 2008.
tary textbook to [5*] comprehensively presents
software design—including design concepts, [3] T. DeMarco, “The Paradox of Software
architectural design, component-level design, Architecture and Design,” Stevens Prize
user interface design, pattern-based design, and Lecture, 1999.
web application design.
[4*] D. Budgen, Software Design, 2nd ed.,
“The 4+1 View Model of Architecture” [20]. Addison-Wesley, 2003.
The seminal paper “The 4+1 View Model” orga- [5*] I. Sommerville, Software Engineering, 9th
nizes a description of a software architecture ed., Addison-Wesley, 2011.
using five concurrent views. The four views of
the model are the logical view, the development [6*] M. Page-Jones, Fundamentals of Object-
view, the process view, and the physical view. Oriented Design in UML, 1st ed., Addison-
In addition, selected use cases or scenarios are Wesley, 1999.
utilized to illustrate the architecture. Hence, the
model contains 4+1 views. The views are used to [7] Merriam-Webster’s Collegiate Dictionary,
describe the software as envisioned by different 11th ed., 2003.
stakeholders—such as end-users, developers, and
project managers. [8] IEEE Std. 1069-2009 Standard for
Information Technology—Systems
Len Bass, Paul Clements, and Rick Kazman, Design—Software Design Descriptions,
Software Architecture in Practice [21]. IEEE, 2009.
This book introduces the concepts and best prac- [9] ISO/IEC 42010:2011 Systems and Software
tices of software architecture, meaning how soft- Engineering—Recommended Practice for
ware is structured and how the software’s compo- Architectural Description of Software-
nents interact. Drawing on their own experience, Intensive Systems, ISO/IEC, 2011.
the authors cover the essential technical topics
for designing, specifying, and validating software [10] J. Bosch, Design and Use of Software
architectures. They also emphasize the impor- Architectures: Adopting and Evolving a
tance of the business context in which large soft- Product-Line Approach, ACM Press, 2000.
ware is designed. Their aim is to present software
architecture in a real-world setting, reflecting [11] G. Kiczales et al., “Aspect-Oriented
both the opportunities and constraints that orga- Programming,” Proc. 11th European Conf.
nizations encounter. This is one of the best books Object-Oriented Programming (ECOOP
currently available on software architecture. 97), Springer, 1997.
2-16 SWEBOK® Guide V3.0
[12*] J.G. Brookshear, Computer Science: An [17*] J. Nielsen, Usability Engineering, Morgan
Overview, 10th ed., Addison-Wesley, 2008. Kaufmann, 1993.
[13*] J.H. Allen et al., Software Security [18] G. Booch, J. Rumbaugh, and I. Jacobson,
Engineering: A Guide for Project The Unified Modeling Language User
Managers, Addison-Wesley, 2008. Guide, Addison-Wesley, 1999.
[14*] P. Clements et al., Documenting Software [19] R.S. Pressman, Software Engineering: A
Architectures: Views and Beyond, 2nd ed., Practitioner’s Approach, 7th ed., McGraw-
Pearson Education, 2010. Hill, 2010.
[15*] E. Gamma et al., Design Patterns: [20] P.B. Kruchten, “The 4+1 View Model of
Elements of Reusable Object-Oriented Architecture,” IEEE Software, vol. 12, no.
Software, 1st ed., Addison-Wesley 6, 1995, pp. 42–55.
Professional, 1994.
[21] L. Bass, P. Clements, and R. Kazman,
[16] I. Jacobson, G. Booch, and J. Rumbaugh, Software Architecture in Practice, 3rd ed.,
The Unified Software Development Addison-Wesley Professional, 2013.
Process, Addison-Wesley Professional,
1999.
CHAPTER 3
SOFTWARE CONSTRUCTION
3-1
3-2 SWEBOK® Guide V3.0
these concepts and describe how they apply to independent testing and operational activities.
construction. Specific techniques that support constructing for
verification include following coding standards to
1.1. Minimizing Complexity support code reviews and unit testing, organizing
[1*] code to support automated testing, and restrict-
ing the use of complex or hard-to-understand lan-
Most people are limited in their ability to hold guage structures, among others.
complex structures and information in their
working memories, especially over long peri- 1.4. Reuse
ods of time. This proves to be a major factor [2*]
influencing how people convey intent to com-
puters and leads to one of the strongest drives Reuse refers to using existing assets in solving
in software construction: minimizing complex- different problems. In software construction, typ-
ity. The need to reduce complexity applies to ical assets that are reused include libraries, mod-
essentially every aspect of software construction ules, components, source code, and commercial
and is particularly critical to testing of software off-the-shelf (COTS) assets. Reuse is best prac-
constructions. ticed systematically, according to a well-defined,
In software construction, reduced complexity repeatable process. Systematic reuse can enable
is achieved through emphasizing code creation significant software productivity, quality, and
that is simple and readable rather than clever. It cost improvements.
is accomplished through making use of standards Reuse has two closely related facets: “construc-
(see section 1.5, Standards in Construction), tion for reuse” and “construction with reuse.” The
modular design (see section 3.1, Construction former means to create reusable software assets,
Design), and numerous other specific techniques while the latter means to reuse software assets in
(see section 3.3, Coding). It is also supported by the construction of a new solution. Reuse often
construction-focused quality techniques (see sec- transcends the boundary of projects, which means
tion 3.7, Construction Quality). reused assets can be constructed in other projects
or organizations.
1.2. Anticipating Change
[1*] 1.5. Standards in Construction
[1*]
Most software will change over time, and the
anticipation of change drives many aspects of Applying external or internal development stan-
software construction; changes in the environ- dards during construction helps achieve a proj-
ments in which software operates also affect soft- ect’s objectives for efficiency, quality, and cost.
ware in diverse ways. Specifically, the choices of allowable program-
Anticipating change helps software engineers ming language subsets and usage standards are
build extensible software, which means they can important aids in achieving higher security.
enhance a software product without disrupting Standards that directly affect construction
the underlying structure. issues include
Anticipating change is supported by many spe-
cific techniques (see section 3.3, Coding). • communication methods (for example, stan-
dards for document formats and contents)
1.3. Constructing for Verification • programming languages (for example, lan-
[1*] guage standards for languages like Java and
C++)
Constructing for verification means building • coding standards (for example, standards for
software in such a way that faults can be read- naming conventions, layout, and indentation)
ily found by the software engineers writing the • platforms (for example, interface standards
software as well as by the testers and users during for operating system calls)
3-4 SWEBOK® Guide V3.0
• tools (for example, diagrammatic standards the Software Management and Software Process
for notations like UML (Unified Modeling KAs).
Language)). Consequently, what is considered to be “con-
struction” depends to some degree on the life
Use of external standards. Construction cycle model used. In general, software con-
depends on the use of external standards for con- struction is mostly coding and debugging, but
struction languages, construction tools, technical it also involves construction planning, detailed
interfaces, and interactions between the Software design, unit testing, integration testing, and other
Construction KA and other KAs. Standards come activities.
from numerous sources, including hardware and
software interface specifications (such as the 2.2. Construction Planning
Object Management Group (OMG)) and interna- [1*]
tional organizations (such as the IEEE or ISO).
Use of internal standards. Standards may also The choice of construction method is a key aspect
be created on an organizational basis at the cor- of the construction-planning activity. The choice
porate level or for use on specific projects. These of construction method affects the extent to
standards support coordination of group activi- which construction prerequisites are performed,
ties, minimizing complexity, anticipating change, the order in which they are performed, and the
and constructing for verification. degree to which they should be completed before
construction work begins.
2. Managing Construction The approach to construction affects the proj-
ect team’s ability to reduce complexity, anticipate
2.1. Construction in Life Cycle Models change, and construct for verification. Each of
[1*] these objectives may also be addressed at the pro-
cess, requirements, and design levels—but they
Numerous models have been created to develop will be influenced by the choice of construction
software; some emphasize construction more method.
than others. Construction planning also defines the order
Some models are more linear from the con- in which components are created and integrated,
struction point of view—such as the waterfall and the integration strategy (for example, phased or
staged-delivery life cycle models. These models incremental integration), the software quality
treat construction as an activity that occurs only management processes, the allocation of task
after significant prerequisite work has been com- assignments to specific software engineers, and
pleted—including detailed requirements work, other tasks, according to the chosen method.
extensive design work, and detailed planning.
The more linear approaches tend to emphasize 2.3. Construction Measurement
the activities that precede construction (require- [1*]
ments and design) and to create more distinct sep-
arations between activities. In these models, the Numerous construction activities and artifacts can
main emphasis of construction may be coding. be measured—including code developed, code
Other models are more iterative—such as modified, code reused, code destroyed, code com-
evolutionary prototyping and agile develop- plexity, code inspection statistics, fault-fix and
ment. These approaches tend to treat construc- fault-find rates, effort, and scheduling. These mea-
tion as an activity that occurs concurrently with surements can be useful for purposes of managing
other software development activities (including construction, ensuring quality during construction,
requirements, design, and planning) or that over- and improving the construction process, among
laps them. These approaches tend to mix design, other uses (see the Software Engineering Process
coding, and testing activities, and they often treat KA for more on measurement).
the combination of activities as construction (see
Software Construction 3-5
• Variability implementation with mecha- • unit testing and integration testing (see sec-
nisms such as parameterization, conditional tion 3.4, Construction Testing)
compilation, design patterns, and so forth. • test-first development (see section 2.2 in the
• Variability encapsulation to make the soft- Software Testing KA)
ware assets easy to configure and customize. • use of assertions and defensive programming
• Testing the variability provided by the reus- • debugging
able software assets. • inspections
• Description and publication of reusable soft- • technical reviews, including security-ori-
ware assets. ented reviews (see section 2.3.2 in the Soft-
ware Quality KA)
3.6. Construction with Reuse • static analysis (see section 2.3 of the Soft-
[2*] ware Quality KA)
Construction with reuse means to create new The specific technique or techniques selected
software with the reuse of existing software depend on the nature of the software being con-
assets. The most popular method of reuse is to structed as well as on the skillset of the software
reuse code from the libraries provided by the lan- engineers performing the construction activi-
guage, platform, tools being used, or an organiza- ties. Programmers should know good practices
tional repository. Asides from these, the applica- and common vulnerabilities—for example, from
tions developed today widely make use of many widely recognized lists about common vulner-
open-source libraries. Reused and off-the-shelf abilities. Automated static analysis of code for
software often have the same—or better—quality security weaknesses is available for several com-
requirements as newly developed software (for mon programming languages and can be used in
example, security level). security-critical projects.
The tasks related to software construction with Construction quality activities are differenti-
reuse during coding and testing are as follows: ated from other quality activities by their focus.
Construction quality activities focus on code and
• The selection of the reusable units, data- artifacts that are closely related to code—such
bases, test procedures, or test data. as detailed design—as opposed to other artifacts
• The evaluation of code or test reusability. that are less directly connected to the code, such
• The integration of reusable software assets as requirements, high-level designs, and plans.
into the current software.
• The reporting of reuse information on new 3.8. Integration
code, test procedures, or test data. [1*]
Design by contract is a development approach or containing their effects if recovery is not pos-
in which preconditions and postconditions are sible. The most common fault tolerance strategies
included for each routine. When preconditions include backing up and retrying, using auxiliary
and postconditions are used, each routine or code, using voting algorithms, and replacing an
class is said to form a contract with the rest of erroneous value with a phony value that will have
the program. Furthermore, a contract provides a a benign effect.
precise specification of the semantics of a routine,
and thus helps the understanding of its behavior. 4.6. Executable Models
Design by contract is thought to improve the [5*]
quality of software construction.
Defensive programming means to protect a Executable models abstract away the details of
routine from being broken by invalid inputs. specific programming languages and decisions
Common ways to handle invalid inputs include about the organization of the software. Different
checking the values of all the input parameters from traditional software models, a specification
and deciding how to handle bad inputs. Asser- built in an executable modeling language like
tions are often used in defensive programming to xUML (executable UML) can be deployed in
check input values. various software environments without change.
An executable-model compiler (transformer) can
4.5. Error Handling, Exception Handling, and turn an executable model into an implementation
Fault Tolerance using a set of decisions about the target hardware
[1*] and software environment. Thus, constructing
executable models can be regarded as a way of
The way that errors are handled affects software’s constructing executable software.
ability to meet requirements related to correct- Executable models are one foundation support-
ness, robustness, and other nonfunctional attri- ing the Model-Driven Architecture (MDA) initia-
butes. Assertions are sometimes used to check tive of the Object Management Group (OMG). An
for errors. Other error handling techniques—such executable model is a way to completely specify
as returning a neutral value, substituting the next a Platform Independent Model (PIM); a PIM is
piece of valid data, logging a warning message, a model of a solution to a problem that does not
returning an error code, or shutting down the soft- rely on any implementation technologies. Then
ware—are also used. a Platform Specific Model (PSM), which is a
Exceptions are used to detect and process model that contains the details of the implemen-
errors or exceptional events. The basic structure tation, can be produced by weaving together the
of an exception is that a routine uses throw to PIM and the platform on which it relies.
throw a detected exception and an exception han-
dling block will catch the exception in a try-catch 4.7. State-Based and Table-Driven Construction
block. The try-catch block may process the erro- Techniques
neous condition in the routine or it may return [1*]
control to the calling routine. Exception handling
policies should be carefully designed follow- State-based programming, or automata-based
ing common principles such as including in the programming, is a programming technology
exception message all information that led to the using finite state machines to describe program
exception, avoiding empty catch blocks, knowing behaviours. The transition graphs of a state
the exceptions the library code throws, perhaps machine are used in all stages of software devel-
building a centralized exception reporter, and opment (specification, implementation, debug-
standardizing the program’s use of exceptions. ging, and documentation). The main idea is to
Fault tolerance is a collection of techniques construct computer programs the same way the
that increase software reliability by detecting automation of technological processes is done.
errors and then recovering from them if possible State-based programming is usually combined
3-10 SWEBOK® Guide V3.0
[7*]
[5*]
[3*]
[2*]
[4*]
[6*]
[1*]
1. Software
Construction
Fundamentals
c2, c3,
c7-c9,
1.1. Minimizing
c24, c27,
Complexity
c28, c31,
c32, c34
c3–c5,
1.2. Anticipating
c24, c31,
Change
c32, c34
c8,
1.3. Constructing for c20–
Verification c23, c31,
c34
1.4. Reuse c16
1.5. Standards in
c4
Construction
2. Managing
Construction
2.1. Construction in c2, c3,
Life Cycle Models c27, c29
c3, c4,
2.2. Construction
c21,
Planning
c27–c29
2.3. Construction
c25, c28
Measurement
3. Practical
Considerations
3.1. Construction c3, c5,
Design c24
3.2. Construction
c4
Languages
c5–c19,
3.3. Coding
c25–c26
3-14 SWEBOK® Guide V3.0
[7*]
[5*]
[3*]
[2*]
[4*]
[6*]
[1*]
3.4. Construction
c22, c23
Testing
3.5. Construction for
c16
Reuse
3.6. Construction
c16
with Reuse
3.7. Construction c8,
Quality c20–c25
3.8. Integration c29
4. Construction
Technologies
4.1. API Design and
c7
Use
4.2. Object-Oriented
c6, c7
Runtime Issues
4.3.
Parameterization c1
and Generics
4.4. Assertions,
Design by Contract,
c8, c9
and Defensive
Programming
4.5. Error Handling,
Exception Handling, c3, c8
and Fault Tolerance
4.6. Executable
c1
Models
4.7. State-Based
and Table-Driven
c18
Construction
Techniques
4.8. Runtime
Configuration and c3, c10
Internationalization
4.9. Grammar-Based
c5 c8
Input Processing
Software Construction 3-15
[7*]
[5*]
[3*]
[2*]
[4*]
[6*]
4.10. Concurrency [1*]
c6
Primitives
4.11. Middleware c1 c8
4.12. Construction
Methods for c2
Distributed Software
4.13. Constructing
Heterogeneous c9
Systems
4.14. Performance
c25, c26
Analysis and Tuning
4.15. Platform
c10 c1
Standards
4.16. Test-First
c22
Programming
5. Construction Tools
5.1. Development
c30
Environments
5.2. GUI Builders c30
5.3. Unit Testing
c22 c8
Tools
5.4. Profiling,
Performance
c25, c26
Analysis, and
Slicing Tools
3-16 SWEBOK® Guide V3.0
IEEE Std. 1517-2010 Standard for Information [1*] S. McConnell, Code Complete, 2nd ed.,
Technology—System and Software Life Microsoft Press, 2004.
Cycle Processes—Reuse Processes, IEEE,
2010 [8]. [2*] I. Sommerville, Software Engineering, 9th
ed., Addison-Wesley, 2011.
This standard specifies the processes, activities,
and tasks to be applied during each phase of the [3*] P. Clements et al., Documenting Software
software life cycle to enable a software product Architectures: Views and Beyond, 2nd ed.,
to be constructed from reusable assets. It covers Pearson Education, 2010.
the concept of reuse-based development and the
processes of construction for reuse and construc- [4*] E. Gamma et al., Design Patterns: Elements
tion with reuse. of Reusable Object-Oriented Software, 1st
ed., Addison-Wesley Professional, 1994.
IEEE Std. 12207-2008 (a.k.a. ISO/IEC
12207:2008) Standard for Systems and [5*] S.J. Mellor and M.J. Balcer, Executable
Software Engineering—Software Life Cycle UML: A Foundation for Model-Driven
Processes, IEEE, 2008 [9]. Architecture, 1st ed., Addison-Wesley,
2002.
This standard defines a series of software devel-
opment processes, including software construc- [6*] L. Null and J. Lobur, The Essentials of
tion process, software integration process, and Computer Organization and Architecture,
software reuse process. 2nd ed., Jones and Bartlett Publishers,
2006.
SOFTWARE TESTING
4-1
4-2 SWEBOK® Guide V3.0
and test plans and procedures should be system- and quality attributes of the software and also
atically and continuously developed—and possi- for identifying faults in those cases where error
bly refined—as software development proceeds. prevention has not been effective. It is perhaps
These test planning and test designing activities obvious but worth recognizing that software can
provide useful input for software designers and still contain faults, even after completion of an
help to highlight potential weaknesses, such as extensive testing activity. Software failures expe-
design oversights/contradictions, or omissions/ rienced after delivery are addressed by corrective
ambiguities in the documentation. maintenance. Software maintenance topics are
For many organizations, the approach to soft- covered in the Software Maintenance KA.
ware quality is one of prevention: it is obviously In the Software Quality KA (see Software Qual-
much better to prevent problems than to correct ity Management Techniques), software quality
them. Testing can be seen, then, as a means for management techniques are notably categorized
providing information about the functionality into static techniques (no code execution) and
Software Testing 4-3
The breakdown of topics for the Software Test- 1.1.2. Faults vs. Failures
ing KA is shown in Figure 4.1. A more detailed [1*, c1s5] [2*, c11]
breakdown is provided in the Matrix of Topics
vs. Reference Material at the end of this KA. Many terms are used in the software engineering
The first topic describes Software Testing Fun- literature to describe a malfunction: notably fault,
damentals. It covers the basic definitions in the failure, and error, among others. This terminol-
field of software testing, the basic terminology ogy is precisely defined in [3, c2]. It is essential
and key issues, and software testing’s relation- to clearly distinguish between the cause of a mal-
ship with other activities. function (for which the term fault will be used
The second topic, Test Levels, consists of two here) and an undesired effect observed in the sys-
(orthogonal) subtopics: the first subtopic lists the tem’s delivered service (which will be called a
levels in which the testing of large software is failure). Indeed there may well be faults in the
traditionally subdivided, and the second subtopic software that never manifest themselves as fail-
considers testing for specific conditions or prop- ures (see Theoretical and Practical Limitations
erties and is referred to as Objectives of Testing. of Testing in section 1.2, Key Issues). Thus test-
Not all types of testing apply to every software ing can reveal failures, but it is the faults that can
product, nor has every possible type been listed. and must be removed [3]. The more generic term
The test target and test objective together defect can be used to refer to either a fault or a
determine how the test set is identified, both with failure, when the distinction is not important [3].
regard to its consistency—how much testing is However, it should be recognized that the cause
enough for achieving the stated objective—and of a failure cannot always be unequivocally iden-
to its composition—which test cases should tified. No theoretical criteria exist to definitively
be selected for achieving the stated objective determine, in general, the fault that caused an
(although usually “for achieving the stated objec- observed failure. It might be said that it was the
tive” remains implicit and only the first part of the fault that had to be modified to remove the failure,
two italicized questions above is posed). Criteria but other modifications might have worked just
for addressing the first question are referred to as as well. To avoid ambiguity, one could refer to
test adequacy criteria, while those addressing the failure-causing inputs instead of faults—that is,
second question are the test selection criteria. those sets of inputs that cause a failure to appear.
Several Test Techniques have been developed
in the past few decades, and new ones are still 1.2. Key Issues
being proposed. Generally accepted techniques
are covered in the third topic. 1.2.1. Test Selection Criteria / Test Adequacy
Test-Related Measures are dealt with in the Criteria (Stopping Rules)
fourth topic, while the issues relative to Test Pro- [1*, c1s14, c6s6, c12s7]
cess are covered in the fifth. Finally, Software
Testing Tools are presented in topic six. A test selection criterion is a means of selecting
test cases or determining that a set of test cases
4-4 SWEBOK® Guide V3.0
is sufficient for a specified purpose. Test ade- in this regard is the Dijkstra aphorism that “pro-
quacy criteria can be used to decide when suf- gram testing can be used to show the presence of
ficient testing will be, or has been accomplished bugs, but never to show their absence” [5]. The
[4] (see Termination in section 5.1, Practical obvious reason for this is that complete testing is
Considerations). not feasible in realistic software. Because of this,
testing must be driven based on risk [6, part 1]
1.2.2. Testing Effectiveness / Objectives for and can be seen as a risk management strategy.
Testing
[1*, c11s4, c13s11] 1.2.6. The Problem of Infeasible Paths
[1*, c4s7]
Testing effectiveness is determined by analyzing
a set of program executions. Selection of tests to Infeasible paths are control flow paths that cannot
be executed can be guided by different objectives: be exercised by any input data. They are a signifi-
it is only in light of the objective pursued that the cant problem in path-based testing, particularly
effectiveness of the test set can be evaluated. in automated derivation of test inputs to exercise
control flow paths.
1.2.3. Testing for Defect Discovery
[1*, c1s14] 1.2.7. Testability
[1*, c17s2]
In testing for defect discovery, a successful test
is one that causes the system to fail. This is quite The term “software testability” has two related
different from testing to demonstrate that the but different meanings: on the one hand, it refers
software meets its specifications or other desired to the ease with which a given test coverage
properties, in which case testing is successful if criterion can be satisfied; on the other hand, it
no failures are observed under realistic test cases is defined as the likelihood, possibly measured
and test environments. statistically, that a set of test cases will expose
a failure if the software is faulty. Both meanings
1.2.4. The Oracle Problem are important.
[1*, c1s9, c9s7]
1.3. Relationship of Testing to Other Activities
An oracle is any human or mechanical agent that
decides whether a program behaved correctly Software testing is related to, but different from,
in a given test and accordingly results in a ver- static software quality management techniques,
dict of “pass” or “fail.” There exist many differ- proofs of correctness, debugging, and program
ent kinds of oracles; for example, unambiguous construction. However, it is informative to con-
requirements specifications, behavioral models, sider testing from the point of view of software
and code annotations. Automation of mechanized quality analysts and of certifiers.
oracles can be difficult and expensive.
• Testing vs. Static Software Quality Man-
1.2.5. Theoretical and Practical Limitations of agement Techniques (see Software Quality
Testing Management Techniques in the Software
[1*, c2s7] Quality KA [1*, c12]).
• Testing vs. Correctness Proofs and Formal
Testing theory warns against ascribing an unjusti- Verification (see the Software Engineering
fied level of confidence to a series of successful Models and Methods KA [1*, c17s2]).
tests. Unfortunately, most established results of • Testing vs. Debugging (see Construction
testing theory are negative ones, in that they state Testing in the Software Construction KA
what testing can never achieve as opposed to what and Debugging Tools and Techniques in the
is actually achieved. The most famous quotation Computing Foundations KA [1*, c3s6]).
Software Testing 4-5
• Testing vs. Program Construction (see Con- functional threads. Integration testing is often an
struction Testing in the Software Construc- ongoing activity at each stage of development
tion KA [1*, c3s2]). during which software engineers abstract away
lower-level perspectives and concentrate on the
2. Test Levels perspectives of the level at which they are inte-
grating. For other than small, simple software,
Software testing is usually performed at differ- incremental integration testing strategies are usu-
ent levels throughout the development and main- ally preferred to putting all of the components
tenance processes. Levels can be distinguished together at once—which is often called “big
based on the object of testing, which is called bang” testing.
the target, or on the purpose, which is called the
objective (of the test level). 2.1.3. System Testing
[1*, c8] [2*, c8]
2.1. The Target of the Test
[1*, c1s13] [2*, c8s1] System testing is concerned with testing the
behavior of an entire system. Effective unit and
The target of the test can vary: a single module, a integration testing will have identified many of
group of such modules (related by purpose, use, the software defects. System testing is usually
behavior, or structure), or an entire system. Three considered appropriate for assessing the non-
test stages can be distinguished: unit, integra- functional system requirements—such as secu-
tion, and system. These three test stages do not rity, speed, accuracy, and reliability (see Func-
imply any process model, nor is any one of them tional and Non-Functional Requirements in the
assumed to be more important than the other two. Software Requirements KA and Software Qual-
ity Requirements in the Software Quality KA).
2.1.1. Unit Testing External interfaces to other applications, utilities,
[1*, c3] [2*, c8] hardware devices, or the operating environments
are also usually evaluated at this level.
Unit testing verifies the functioning in isolation
of software elements that are separately testable. 2.2. Objectives of Testing
Depending on the context, these could be the [1*, c1s7]
individual subprograms or a larger component
made of highly cohesive units. Typically, unit Testing is conducted in view of specific objec-
testing occurs with access to the code being tested tives, which are stated more or less explicitly
and with the support of debugging tools. The pro- and with varying degrees of precision. Stating
grammers who wrote the code typically, but not the objectives of testing in precise, quantitative
always, conduct unit testing. terms supports measurement and control of the
test process.
2.1.2. Integration Testing Testing can be aimed at verifying different prop-
[1*, c7] [2*, c8] erties. Test cases can be designed to check that
the functional specifications are correctly imple-
Integration testing is the process of verifying the mented, which is variously referred to in the lit-
interactions among software components. Clas- erature as conformance testing, correctness test-
sical integration testing strategies, such as top- ing, or functional testing. However, several other
down and bottom-up, are often used with hierar- nonfunctional properties may be tested as well—
chically structured software. including performance, reliability, and usabil-
Modern, systematic integration strategies are ity, among many others (see Models and Quality
typically architecture-driven, which involves Characteristics in the Software Quality KA).
incrementally integrating the software com- Other important objectives for testing include
ponents or subsystems based on identified but are not limited to reliability measurement,
4-6 SWEBOK® Guide V3.0
Security testing is focused on the verification that In cases where software is built to serve different
the software is protected from external attacks. In users, configuration testing verifies the software
particular, security testing verifies the confiden- under different specified configurations.
tiality, integrity, and availability of the systems
and its data. Usually, security testing includes 2.2.13. Usability and Human Computer Inter-
verification against misuse and abuse of the soft- action Testing
ware or system (negative testing). [10*, c6]
IEEE/ISO/IEC Standard 24765 defines back-to- One of the aims of testing is to detect as many
back testing as “testing in which two or more failures as possible. Many techniques have been
variants of a program are executed with the same developed to do this [6, part 4]. These techniques
inputs, the outputs are compared, and errors are attempt to “break” a program by being as sys-
analyzed in case of discrepancies.” tematic as possible in identifying inputs that will
produce representative program behaviors; for
2.2.10. Recovery Testing instance, by considering subclasses of the input
[1*, c14s2] domain, scenarios, states, and data flows.
The classification of testing techniques pre-
Recovery testing is aimed at verifying software sented here is based on how tests are generated:
restart capabilities after a system crash or other from the software engineer’s intuition and expe-
“disaster.” rience, the specifications, the code structure, the
real or imagined faults to be discovered, predicted
2.2.11. Interface Testing usage, models, or the nature of the application.
[2*, c8s1.3] [9*, c4s4.5] One category deals with the combined use of two
or more techniques.
Interface defects are common in complex sys- Sometimes these techniques are classified as
tems. Interface testing aims at verifying whether white-box (also called glass-box), if the tests are
the components interface correctly to provide the based on information about how the software has
correct exchange of data and control informa- been designed or coded, or as black-box if the test
tion. Usually the test cases are generated from cases rely only on the input/output behavior of
the interface specification. A specific objective of the software. The following list includes those
interface testing is to simulate the use of APIs by testing techniques that are commonly used, but
end-user applications. This involves the genera- some practitioners rely on some of the techniques
tion of parameters of the API calls, the setting of more than others.
external environment conditions, and the defini-
tion of internal data that affect the API.
4-8 SWEBOK® Guide V3.0
3.1. Based on the Software Engineer’s Intuition instead of considering all possible combinations.
and Experience Pairwise testing belongs to combinatorial testing,
which in general also includes higher-level com-
3.1.1. Ad Hoc binations than pairs: these techniques are referred
to as t-wise, whereby every possible combination
Perhaps the most widely practiced technique is of t input variables is considered.
ad hoc testing: tests are derived relying on the
software engineer’s skill, intuition, and experi- 3.2.3. Boundary-Value Analysis
ence with similar programs. Ad hoc testing can [1*, c9s5]
be useful for identifying tests cases that not easily
generated by more formalized techniques. Test cases are chosen on or near the boundaries of
the input domain of variables, with the underly-
3.1.2. Exploratory Testing ing rationale that many faults tend to concentrate
near the extreme values of inputs. An extension of
Exploratory testing is defined as simultaneous this technique is robustness testing, wherein test
learning, test design, and test execution [6, part cases are also chosen outside the input domain of
1]; that is, the tests are not defined in advance variables to test program robustness in processing
in an established test plan, but are dynamically unexpected or erroneous inputs.
designed, executed, and modified. The effective-
ness of exploratory testing relies on the software 3.2.4. Random Testing
engineer’s knowledge, which can be derived [1*, c9s7]
from various sources: observed product behavior
during testing, familiarity with the application, Tests are generated purely at random (not to be
the platform, the failure process, the type of pos- confused with statistical testing from the opera-
sible faults and failures, the risk associated with a tional profile, as described in Operational Profile
particular product, and so on. in section 3.5). This form of testing falls under the
heading of input domain testing since the input
3.2. Input Domain-Based Techniques domain must be known in order to be able to pick
random points within it. Random testing provides
3.2.1. Equivalence Partitioning a relatively simple approach for test automation;
[1*, c9s4] recently, enhanced forms of random testing have
been proposed in which the random input sam-
Equivalence partitioning involves partitioning the pling is directed by other input selection criteria
input domain into a collection of subsets (or equiv- [11]. Fuzz testing or fuzzing is a special form of
alent classes) based on a specified criterion or rela- random testing aimed at breaking the software; it
tion. This criterion or relation may be different is most often used for security testing.
computational results, a relation based on control
flow or data flow, or a distinction made between 3.3. Code-Based Techniques
valid inputs that are accepted and processed by the
system and invalid inputs, such as out of range val- 3.3.1. Control Flow-Based Criteria
ues, that are not accepted and should generate an [1*, c4]
error message or initiate error processing. A repre-
sentative set of tests (sometimes only one) is usu- Control flow-based coverage criteria are aimed
ally taken from each equivalency class. at covering all the statements, blocks of state-
ments, or specified combinations of statements
3.2.2. Pairwise Testing in a program. The strongest of the control flow-
[1*, c9s3] based criteria is path testing, which aims to
execute all entry-to-exit control flow paths in a
Test cases are derived by combining interesting program’s control flow graph. Since exhaustive
values for every pair of a set of input variables path testing is generally not feasible because of
Software Testing 4-9
to guide derivation of test cases that will assess (roughly, outputs). Test cases are systematically
the achievement of reliability objectives and derived by considering every possible combina-
exercise relative usage and criticality of different tion of conditions and their corresponding resul-
functions similar to what will be encountered in tant actions. A related technique is cause-effect
the operational environment [3]. graphing [1*, c13s6].
Usability principles can provide guidelines for dis- By modeling a program as a finite state machine,
covering problems in the design of the user inter- tests can be selected in order to cover the states
face [10*, c1s4] (see User Interface Design in the and transitions.
Software Design KA). Specialized heuristics, also
called usability inspection methods, are applied 3.6.3. Formal Specifications
for the systematic observation of system usage [1*, c10s11] [2*, c15]
under controlled conditions in order to deter-
mine how well people can use the system and its Stating the specifications in a formal language
interfaces. Usability heuristics include cognitive (see Formal Methods in the Software Engineer-
walkthroughs, claims analysis, field observations, ing Models and Methods KA) permits automatic
thinking aloud, and even indirect approaches such derivation of functional test cases, and, at the
as user questionnaires and interviews. same time, provides an oracle for checking test
results.
3.6. Model-Based Testing Techniques TTCN3 (Testing and Test Control Notation
version 3) is a language developed for writing test
A model in this context is an abstract (formal) cases. The notation was conceived for the specific
representation of the software under test or of needs of testing telecommunication systems, so it
its software requirements (see Modeling in the is particularly suitable for testing complex com-
Software Engineering Models and Methods KA). munication protocols.
Model-based testing is used to validate require-
ments, check their consistency, and generate test 3.6.4. Workflow Models
cases focused on the behavioral aspects of the [2*, c8s3.2, c19s3.1]
software. The key components of model-based
testing are [13]: the notation used to represent the Workflow models specify a sequence of activi-
model of the software or its requirements; work- ties performed by humans and/or software appli-
flow models or similar models; the test strategy cations, usually represented through graphical
or algorithm used for test case generation; the notations. Each sequence of actions constitutes
supporting infrastructure for the test execution; one workflow (also called a scenario). Both typi-
and the evaluation of test results compared to cal and alternate workflows should be tested [6,
expected results. Due to the complexity of the part 4]. A special focus on the roles in a work-
techniques, model-based testing approaches flow specification is targeted in business process
are often used in conjunction with test automa- testing.
tion harnesses. Model-based testing techniques
include the following. 3.7. Techniques Based on the Nature of the
Application
3.6.1. Decision Tables
[1*, c9s6] The above techniques apply to all kinds of soft-
ware. Additional techniques for test derivation
Decision tables represent logical relationships and execution are based on the nature of the soft-
between conditions (roughly, inputs) and actions ware being tested; for example,
Software Testing 4-11
Sometimes testing techniques are confused with The testing literature is rich in classifications and
testing objectives. Testing techniques can be taxonomies of faults. To make testing more effec-
viewed as aids that help to ensure the achieve- tive, it is important to know which types of faults
ment of test objectives [6, part 4]. For instance, may be found in the software under test and the
branch coverage is a popular testing technique. relative frequency with which these faults have
Achieving a specified branch coverage measure occurred in the past. This information can be use-
(e.g., 95% branch coverage) should not be the ful in making quality predictions as well as in
objective of testing per se: it is a way of improv- process improvement (see Defect Characteriza-
ing the chances of finding failures by attempting tion in the Software Quality KA).
to systematically exercise every program branch
4-12 SWEBOK® Guide V3.0
A program under test can be evaluated by counting In fault seeding, some faults are artificially intro-
discovered faults as the ratio between the number duced into a program before testing. When the
of faults found and the size of the program. tests are executed, some of these seeded faults will
be revealed as well as, possibly, some faults that
4.1.4. Life Test, Reliability Evaluation were already there. In theory, depending on which
[1*, c15] [9*, c3] and how many of the artificial faults are discov-
ered, testing effectiveness can be evaluated and the
A statistical estimate of software reliability, remaining number of genuine faults can be esti-
which can be obtained by observing reliabil- mated. In practice, statisticians question the dis-
ity achieved, can be used to evaluate a software tribution and representativeness of seeded faults
product and decide whether or not testing can be relative to genuine faults and the small sample size
stopped (see section 2.2, Reliability Achievement on which any extrapolations are based. Some also
and Evaluation). argue that this technique should be used with great
care since inserting faults into software involves
4.1.5. Reliability Growth Models the obvious risk of leaving them there.
[1*, c15] [9*, c8]
4.2.3. Mutation Score
Reliability growth models provide a prediction of [1*, c3s5]
reliability based on failures. They assume, in gen-
eral, that when the faults that caused the observed In mutation testing (see Mutation Testing in sec-
failures have been fixed (although some models tion 3.4, Fault-Based Techniques), the ratio of
also accept imperfect fixes), the estimated prod- killed mutants to the total number of generated
uct’s reliability exhibits, on average, an increasing mutants can be a measure of the effectiveness of
trend. There are many published reliability growth the executed test set.
models. Notably, these models are divided into
failure-count and time-between-failure models. 4.2.4. Comparison and Relative Effectiveness
of Different Techniques
4.2. Evaluation of the Tests Performed
Several studies have been conducted to com-
4.2.1. Coverage / Thoroughness Measures pare the relative effectiveness of different testing
[9*, c11] techniques. It is important to be precise as to the
property against which the techniques are being
Several test adequacy criteria require that the test assessed; what, for instance, is the exact meaning
cases systematically exercise a set of elements given to the term “effectiveness”? Possible inter-
identified in the program or in the specifications pretations include the number of tests needed to
(see topic 3, Test Techniques). To evaluate the find the first failure, the ratio of the number of
thoroughness of the executed tests, software engi- faults found through testing to all the faults found
neers can monitor the elements covered so that during and after testing, and how much reliabil-
they can dynamically measure the ratio between ity was improved. Analytical and empirical com-
covered elements and the total number. For exam- parisons between different techniques have been
ple, it is possible to measure the percentage of conducted according to each of the notions of
branches covered in the program flow graph or the effectiveness specified above.
percentage of functional requirements exercised
among those listed in the specifications document. 5. Test Process
Code-based adequacy criteria require appropriate
instrumentation of the program under test. Testing concepts, strategies, techniques, and mea-
sures need to be integrated into a defined and
Software Testing 4-13
controlled process. The test process supports test- the test item. Test documentation should be pro-
ing activities and provides guidance to testers and duced and continually updated to the same level
testing teams, from test planning to test output of quality as other types of documentation in
evaluation, in such a way as to provide assurance software engineering. Test documentation should
that the test objectives will be met in a cost-effec- also be under the control of software configura-
tive way. tion management (see the Software Configuration
Management KA). Moreover, test documentation
5.1. Practical Considerations includes work products that can provide material
for user manuals and user training.
5.1.1. Attitudes / Egoless Programming
[1*c16] [9*, c15] 5.1.5. Test-Driven Development
[1*, c1s16]
An important element of successful testing is a
collaborative attitude towards testing and quality Test-driven development (TDD) originated as one
assurance activities. Managers have a key role in of the core XP (extreme programming) practices
fostering a generally favorable reception towards and consists of writing unit tests prior to writing
failure discovery and correction during software the code to be tested (see Agile Methods in the
development and maintenance; for instance, by Software Engineering Models and Method KA).
overcoming the mindset of individual code own- In this way, TDD develops the test cases as a sur-
ership among programmers and by promoting a rogate for a software requirements specification
collaborative environment with team responsibil- document rather than as an independent check
ity for anomalies in the code. that the software has correctly implemented the
requirements. Rather than a testing strategy, TDD
5.1.2. Test Guides is a practice that requires software developers to
[1*, c12s1] [9*, c15s1] define and maintain unit tests; it thus can also
have a positive impact on elaborating user needs
The testing phases can be guided by various and software requirements specifications.
aims—for example, risk-based testing uses the
product risks to prioritize and focus the test strat- 5.1.6. Internal vs. Independent Test Team
egy, and scenario-based testing defines test cases [1*, c16]
based on specified software scenarios.
Formalizing the testing process may also involve
5.1.3. Test Process Management formalizing the organization of the testing team.
[1*, c12] [9*, c15] The testing team can be composed of internal
members (that is, on the project team, involved or
Test activities conducted at different levels (see not in software construction), of external members
topic 2, Test Levels) must be organized—together (in the hope of bringing an unbiased, independent
with people, tools, policies, and measures—into a perspective), or of both internal and external mem-
well-defined process that is an integral part of the bers. Considerations of cost, schedule, maturity
life cycle. levels of the involved organizations, and criticality
of the application can guide the decision.
5.1.4. Test Documentation and Work Products
[1*, c8s12] [9*, c4s5] 5.1.7. Cost/Effort Estimation and Test Process
Measures
Documentation is an integral part of the formaliza- [1*, c18s3] [9*, c5s7]
tion of the test process [6, part 3]. Test documents
may include, among others, the test plan, test Several measures related to the resources spent
design specification, test procedure specification, on testing, as well as to the relative fault-finding
test case specification, test log, and test incident effectiveness of the various test phases, are used
report. The software under test is documented as by managers to control and improve the testing
4-14 SWEBOK® Guide V3.0
To carry out testing or maintenance in an orga- The environment used for testing should be com-
nized and cost-effective way, the means used to patible with the other adopted software engi-
test each part of the software should be reused neering tools. It should facilitate development
systematically. A repository of test materials and control of test cases, as well as logging and
should be under the control of software con- recovery of expected results, scripts, and other
figuration management so that changes to soft- testing materials.
ware requirements or design can be reflected in
changes to the tests conducted. 5.2.4. Execution
The test solutions adopted for testing some [1*, c12s7]
application types under certain circumstances,
with the motivations behind the decisions taken, Execution of tests should embody a basic prin-
form a test pattern that can itself be documented ciple of scientific experimentation: everything
for later reuse in similar projects. done during testing should be performed and
documented clearly enough that another person
Software Testing 4-15
could replicate the results. Hence, testing should the software. Defect tracking information is used
be performed in accordance with documented to determine what aspects of software testing
procedures using a clearly defined version of the and other processes need improvement and how
software under test. effective previous approaches have been.
5.2.6. Problem Reporting / Test Log Guidance to managers and testers on how to select
[1*, c13s9] testing tools that will be most useful to their orga-
nization and processes is a very important topic,
Testing activities can be entered into a testing as tool selection greatly affects testing efficiency
log to identify when a test was conducted, who and effectiveness. Tool selection depends on
performed the test, what software configuration diverse evidence, such as development choices,
was used, and other relevant identification infor- evaluation objectives, execution facilities, and so
mation. Unexpected or incorrect test results can on. In general, there may not be a unique tool that
be recorded in a problem reporting system, the will satisfy particular needs, so a suite of tools
data for which forms the basis for later debug- could be an appropriate choice.
ging and fixing the problems that were observed
as failures during testing. Also, anomalies not 6.2. Categories of Tools
classified as faults could be documented in case
they later turn out to be more serious than first We categorize the available tools according to
thought. Test reports are also inputs to the change their functionality:
management request process (see Software Con-
figuration Control in the Software Configuration • Test harnesses (drivers, stubs) [1*, c3s9]
Management KA). provide a controlled environment in which
tests can be launched and the test outputs can
5.2.7. Defect Tracking be logged. In order to execute parts of a pro-
[9*, c9] gram, drivers and stubs are provided to simu-
late calling and called modules, respectively.
Defects can be tracked and analyzed to determine • Test generators [1*, c12s11] provide assis-
when they were introduced into the software, tance in the generation test cases. The gen-
why they were created (for example, poorly eration can be random, path-based, model-
defined requirements, incorrect variable declara- based, or a mix thereof.
tion, memory leak, programming syntax error), • Capture/replay tools [1*, c12s11] auto-
and when they could have been first observed in matically reexecute, or replay, previously
4-16 SWEBOK® Guide V3.0
executed tests which have recorded inputs • Tracers [1*, c1s7] record the history of a
and outputs (e.g., screens). program’s execution paths.
• Oracle/file comparators/assertion checking • Regression testing tools [1*, c12s16] support
tools [1*, c9s7] assist in deciding whether a the reexecution of a test suite after a section
test outcome is successful or not. of software has been modified. They can also
• Coverage analyzers and instrumenters [1*, help to select a test subset according to the
c4] work together. Coverage analyzers assess change made.
which and how many entities of the program • Reliability evaluation tools [9*, c8] support
flow graph have been exercised amongst all test results analysis and graphical visualiza-
those required by the selected test coverage tion in order to assess reliability-related mea-
criterion. The analysis can be done thanks to sures according to selected models.
program instrumenters that insert recording
probes into the code.
Software Testing 4-17
Sommerville 2011
Nielsen 1993
Kan 2003
[10*]
[9*]
[2*]
[1*]
1. Software Testing Fundamentals
1.1. Testing-Related Terminology
1.1.1. Definitions of Testing and
c1,c2 c8
Related Terminology
1.1.2. Faults vs. Failures c1s5 c11
1.2. Key Issues
1.2.1. Test Selection Criteria /
c1s14, c6s6,
Test Adequacy Criteria
c12s7
(Stopping Rules)
1.2.2. Testing Effectiveness /
c13s11, c11s4
Objectives for Testing
1.2.3. Testing for Defect
c1s14
Identification
c1s9,
1.2.4. The Oracle Problem
c9s7
1.2.5. Theoretical and Practical
c2s7
Limitations of Testing
1.2.6. The Problem of Infeasible
c4s7
Paths
1.2.7. Testability c17s2
1.3. Relationship of Testing to
Other Activities
1.3.1. Testing vs. Static
Software Quality Management c12
Techniques
1.3.2. Testing vs. Correctness
c17s2
Proofs and Formal Verification
1.3.3. Testing vs. Debugging c3s6
1.3.4. Testing vs. Programming c3s2
2. Test Levels
2.1. The Target of the Test c1s13 c8s1
2.1.1. Unit Testing c3 c8
2.1.2. Integration Testing c7 c8
2.1.3. System Testing c8 c8
4-18 SWEBOK® Guide V3.0
Sommerville 2011
Nielsen 1993
Kan 2003
[10*]
[9*]
[2*]
[1*]
2.2. Objectives of Testing c1s7
2.2.1. Acceptance / Qualification c1s7 c8s4
2.2.2. Installation Testing c12s2
c13s7,
2.2.3. Alpha and Beta Testing c8s4
c16s6
2.2.4. Reliability Achievement
c15 c15s2
and Evaluation
c8s11,
2.2.5. Regression Testing
c13s3
2.2.6. Performance Testing c8s6
2.2.7. Security Testing c8s3 c11s4
2.2.8. Stress Testing c8s8
2.2.9. Back-to-Back Testing
2.2.10. Recovery Testing c14s2
2.2.11. Interface Testing c8s1.3 c4s4.5
2.2.12. Configuration Testing c8s5
2.2.13. Usability and Human
c6
Computer Interaction Testing
3. Test Techniques
3.1. Based on the Software
Engineer’s Intuition and
Experience
3.1.1. Ad Hoc
3.1.2. Exploratory Testing
3.2. Input Domain-Based
Techniques
3.2.1. Equivalence Partitioning c9s4
3.2.2. Pairwise Testing c9s3
3.2.3. Boundary-Value Analysis c9s5
3.2.4. Random Testing c9s7
3.3. Code-Based Techniques
3.3.1. Control Flow-Based
c4
Criteria
Software Testing 4-19
Sommerville 2011
Nielsen 1993
Kan 2003
[10*]
[9*]
[2*]
[1*]
3.3.2. Data Flow-Based Criteria c5
3.3.3. Reference Models for
c4
Code-Based Testing
3.4. Fault-Based Techniques c1s14
3.4.1. Error Guessing c9s8
3.4.2. Mutation Testing c3s5
3.5. Usage-Based Techniques
3.5.1. Operational Profile c15s5
3.5.2. User Observation
c5, c7
Heuristics
3.6. Model-Based Testing
Techniques
3.6.1. Decision Table c9s6
3.6.2. Finite-State Machines c10
3.6.3. Testing from Formal
c10s11 c15
Specifications
3.7. Techniques Based on the
Nature of the Application
3.8. Selecting and Combining
Techniques
3.8.1. Functional and Structural c9
3.8.2. Deterministic vs. Random c9s6
4. Test-Related Measures
4.1. Evaluation of the Program
Under Test
4.1.1. Program Measurements
That Aid in Planning and c11
Designing Testing
4.1.2. Fault Types, Classification,
c4
and Statistics
4.1.3. Fault Density c13s4 c4
4.1.4. Life Test, Reliability
c15 c3
Evaluation
4.1.5. Reliability Growth Models c15 c8
4-20 SWEBOK® Guide V3.0
Sommerville 2011
Nielsen 1993
Kan 2003
[10*]
[9*]
[2*]
[1*]
4.2. Evaluation of the Tests
Performed
4.2.1. Coverage / Thoroughness
c11
Measures
4.2.2. Fault Seeding c2s5 c6
4.2.3. Mutation Score c3s5
4.2.4. Comparison and Relative
Effectiveness of Different
Techniques
5. Test Process
5.1. Practical Considerations
5.1.1. Attitudes / Egoless
c16 c15
Programming
5.1.2. Test Guides c12s1 c15s1
5.1.3. Test Process Management c12 c15
5.1.4. Test Documentation and
c8s12 c4s5
Work Products
5.1.5. Test-Driven Development c1s16
5.1.6. Internal vs. Independent
c16
Test Team
5.1.7. Cost/Effort Estimation and
c18s3 c5s7
Other Process Measures
5.1.8. Termination c10s4
5.1.9. Test Reuse and Patterns c2s5
5.2. Test Activities
c12s1
5.2.1. Planning
c12s8
c12s1
5.2.2. Test-Case Generation
c12s3
5.2.3. Test Environment
c12s6
Development
5.2.4. Execution c12s7
5.2.5. Test Results Evaluation c15
Software Testing 4-21
Sommerville 2011
Nielsen 1993
Kan 2003
[10*]
[9*]
[2*]
[1*]
5.2.6. Problem Reporting / Test
c13s9
Log
5.2.7. Defect Tracking c9
6. Software Testing Tools
6.1. Testing Tool Support c12s11 c5
6.1.1. Selecting Tools c12s11
c1s7, c3s9,
c4, c9s7,
6.2. Categories of Tools c8
c12s11,
c12s16
4-22 SWEBOK® Guide V3.0
REFERENCES
[1*] S. Naik and P. Tripathy, Software Testing [8] S. Yoo and M. Harman, “Regression Testing
and Quality Assurance: Theory and Minimization, Selection and Prioritization:
Practice, Wiley-Spektrum, 2008. A Survey,” Software Testing Verification
and Reliability, vol. 22, no. 2, Mar. 2012,
[2*] I. Sommerville, Software Engineering, 9th pp. 67–120.
ed., Addison-Wesley, 2011.
[9*] S.H. Kan, Metrics and Models in Software
[3] M.R. Lyu, ed., Handbook of Software Quality Engineering, 2nd ed., Addison-
Reliability Engineering, McGraw-Hill and Wesley, 2002.
IEEE Computer Society Press, 1996.
[10*] J. Nielsen, Usability Engineering, Morgan
[4] H. Zhu, P.A.V. Hall, and J.H.R. May, Kaufmann, 1993.
“Software Unit Test Coverage and
Adequacy,” ACM Computing Surveys, vol. [11] T.Y. Chen et al., “Adaptive Random Testing:
29, no. 4, Dec. 1997, pp. 366–427. The ART of Test Case Diversity,” Journal
of Systems and Software, vol. 83, no. 1, Jan.
[5] E.W. Dijkstra, “Notes on Structured 2010, pp. 60–66.
Programming,” T.H.-Report 70-WSE-03,
Technological University, Eindhoven, 1970; [12] Y. Jia and M. Harman, “An Analysis
http://www.cs.utexas.edu/users/EWD/ and Survey of the Development of
ewd02xx/EWD249.PDF. Mutation Testing,” IEEE Trans. Software
Engineering, vol. 37, no. 5, Sep.–Oct. 2011,
[6] ISO/IEC/IEEE P29119-1/DIS Draft Standard pp. 649–678.
for Software and Systems Engineering—
Software Testing—Part 1: Concepts and [13] M. Utting and B. Legeard, Practical
Definitions, ISO/IEC/IEEE, 2012. Model-Based Testing: A Tools Approach,
Morgan Kaufmann, 2007.
[7] ISO/IEC/IEEE 24765:2010 Systems and
Software Engineering—Vocabulary, ISO/
IEC/IEEE, 2010.
CHAPTER 5
SOFTWARE MAINTENANCE
5-1
5-2 SWEBOK® Guide V3.0
The objective of software maintenance is to modified, testing is conducted, and a new version
modify existing software while preserving its of the software product is released. Also, train-
integrity. The international standard also states ing and daily support are provided to users. The
the importance of having some maintenance term maintainer is defined as an organization that
activities prior to the final delivery of software performs maintenance activities. In this KA, the
(predelivery activities). Notably, IEEE 14764 term will sometimes refer to individuals who per-
emphasizes the importance of the predelivery form those activities, contrasting them with the
aspects of maintenance—planning, for example. developers.
IEEE 14764 identifies the primary activities of
1.2. Nature of Maintenance software maintenance as process implementation,
[2*, c1s3] problem and modification analysis, modification
implementation, maintenance review/acceptance,
Software maintenance sustains the software prod- migration, and retirement. These activities are
uct throughout its life cycle (from development discussed in section 3.2, Maintenance Activities.
to operations). Modification requests are logged Maintainers can learn from the develop-
and tracked, the impact of proposed changes is ers’ knowledge of the software. Contact with
determined, code and other software artifacts are the developers and early involvement by the
Software Maintenance 5-3
maintainer helps reduce the overall maintenance perception of software maintenance is that it
effort. In some instances, the initial developer merely fixes faults. However, studies and sur-
cannot be reached or has moved on to other tasks, veys over the years have indicated that the major-
which creates an additional challenge for main- ity, over 80 percent, of software maintenance is
tainers. Maintenance must take software artifacts used for noncorrective actions [2*, figure 4.1].
from development (for example, code or docu- Grouping enhancements and corrections together
mentation) and support them immediately, then in management reports contributes to some mis-
progressively evolve/maintain them over a soft- conceptions regarding the high cost of correc-
ware life cycle. tions. Understanding the categories of software
maintenance helps to understand the structure of
1.3. Need for Maintenance software maintenance costs. Also, understanding
[2*, c1s5] the factors that influence the maintainability of
software can help to contain costs. Some environ-
Maintenance is needed to ensure that the software mental factors and their relationship to software
continues to satisfy user requirements. Mainte- maintenance costs include the following:
nance is applicable to software that is developed
using any software life cycle model (for example, • Operating environment refers to hardware
spiral or linear). Software products change due and software.
to corrective and noncorrective software actions. • Organizational environment refers to poli-
Maintenance must be performed in order to cies, competition, process, product, and
personnel.
• correct faults;
• improve the design; 1.5. Evolution of Software
• implement enhancements; [2*, c3s5]
• interface with other software;
• adapt programs so that different hardware, Software maintenance in terms of evolution was
software, system features, and telecommuni- first addressed in the late 1960s. Over a period of
cations facilities can be used; twenty years, research led to the formulation of
• migrate legacy software; and eight “Laws of Evolution.” Key findings include a
• retire software. proposal that maintenance is evolutionary devel-
opment and that maintenance decisions are aided
Five key characteristics comprise the maintain- by understanding what happens to software over
er’s activities: time. Some state that maintenance is continued
development, except that there is an extra input
• maintaining control over the software’s day- (or constraint)–in other words, existing large soft-
to-day functions; ware is never complete and continues to evolve;
• maintaining control over software as it evolves, it grows more complex unless some
modification; action is taken to reduce this complexity.
• perfecting existing functions;
• identifying security threats and fixing secu- 1.6. Categories of Maintenance
rity vulnerabilities; and [1*, c3, c6s2] [2*, c3s3.1]
• preventing software performance from
degrading to unacceptable levels. Three categories (types) of maintenance have
been defined: corrective, adaptive, and perfec-
1.4. Majority of Maintenance Costs tive [2*, c4s3]. IEEE 14764 includes a fourth
[2*, c4s3, c5s5.2] category–preventative.
Maintenance consumes a major share of the finan- • Corrective maintenance: reactive modifi-
cial resources in a software life cycle. A common cation (or repairs) of a software product
5-4 SWEBOK® Guide V3.0
performed after delivery to correct discov- next release while sending out emergency patches
ered problems. Included in this category for the current release, also creates a challenge.
is emergency maintenance, which is an The following section presents some of the tech-
unscheduled modification performed to tem- nical and management issues related to software
porarily keep a software product operational maintenance. They have been grouped under the
pending corrective maintenance. following topic headings:
• Adaptive maintenance: modification of a
software product performed after delivery to • technical issues,
keep a software product usable in a changed • management issues,
or changing environment. For example, • cost estimation, and
the operating system might be upgraded • measurement.
and some changes to the software may be
necessary. 2.1. Technical Issues
• Perfective maintenance: modification of a
software product after delivery to provide 2.1.1. Limited Understanding
enhancements for users, improvement of [2*, c6]
program documentation, and recoding to
improve software performance, maintain- Limited understanding refers to how quickly a
ability, or other software attributes. software engineer can understand where to make
• Preventive maintenance: modification of a a change or correction in software that he or she
software product after delivery to detect and did not develop. Research indicates that about half
correct latent faults in the software product of the total maintenance effort is devoted to under-
before they become operational faults. standing the software to be modified. Thus, the
topic of software comprehension is of great inter-
IEEE 14764 classifies adaptive and perfective est to software engineers. Comprehension is more
maintenance as maintenance enhancements. It difficult in text-oriented representation—in source
also groups together the corrective and preven- code, for example—where it is often difficult to
tive maintenance categories into a correction cat- trace the evolution of software through its releases/
egory, as shown in Table 5.1. versions if changes are not documented and if the
developers are not available to explain it, which is
Table 5.1. Software Maintenance Categories often the case. Thus, software engineers may ini-
tially have a limited understanding of the software;
Correction Enhancement much has to be done to remedy this.
Proactive Preventive Perfective
2.1.2. Testing
Reactive Corrective Adaptive
[1*, c6s2.2.2] [2*, c9]
2. Key Issues in Software Maintenance The cost of repeating full testing on a major
piece of software is significant in terms of time
A number of key issues must be dealt with to and money. In order to ensure that the requested
ensure the effective maintenance of software. problem reports are valid, the maintainer should
Software maintenance provides unique techni- replicate or verify problems by running the
cal and management challenges for software appropriate tests. Regression testing (the selec-
engineers—for example, trying to find a fault in tive retesting of software or a component to ver-
software containing a large number of lines of ify that the modifications have not caused unin-
code that another software engineer developed. tended effects) is an important testing concept in
Similarly, competing with software developers maintenance. Additionally, finding time to test is
for resources is a constant battle. Planning for a often difficult. Coordinating tests when different
future release, which often includes coding the members of the maintenance team are working
Software Maintenance 5-5
3.2.1. Unique Activities
[1*, c3s10, c6s9, c7s2, c7s3] [2*, c6, c7]
and audits. Another important support activity • identification of the software maintenance
consists of training the maintainers and users. organization, and
• estimate of software maintenance costs.
3.2.3. Maintenance Planning Activities
[1*, c7s3] The next step is to develop a corresponding
software maintenance plan. This plan should be
An important activity for software maintenance is prepared during software development and should
planning, and maintainers must address the issues specify how users will request software modifica-
associated with a number of planning perspec- tions or report problems. Software maintenance
tives, including planning is addressed in IEEE 14764. It provides
guidelines for a maintenance plan. Finally, at
• business planning (organizational level), the highest level, the maintenance organization
• maintenance planning (transition level), will have to conduct business planning activities
• release/version planning (software level), and (budgetary, financial, and human resources) just
• individual software change request planning like all the other divisions of the organization.
(request level). Management is discussed in the chapter Related
Disciplines of Software Engineering.
At the individual request level, planning is
carried out during the impact analysis (see sec- 3.2.4. Software Configuration Management
tion 2.1.3, Impact Analysis). The release/version [1*, c5s1.2.3] [2*, c11]
planning activity requires that the maintainer:
IEEE 14764 describes software configuration
• collect the dates of availability of individual management as a critical element of the mainte-
requests, nance process. Software configuration manage-
• agree with users on the content of subsequent ment procedures should provide for the verifica-
releases/versions, tion, validation, and audit of each step required
• identify potential conflicts and develop to identify, authorize, implement, and release the
alternatives, software product.
• assess the risk of a given release and develop It is not sufficient to simply track modifica-
a back-out plan in case problems should tion requests or problem reports. The software
arise, and product and any changes made to it must be con-
• inform all the stakeholders. trolled. This control is established by implement-
ing and enforcing an approved software configu-
Whereas software development projects can ration management (SCM) process. The Software
typically last from some months to a few years, Configuration Management KA provides details
the maintenance phase usually lasts for many of SCM and discusses the process by which soft-
years. Making estimates of resources is a key ele- ware change requests are submitted, evaluated,
ment of maintenance planning. Software main- and approved. SCM for software maintenance is
tenance planning should begin with the decision different from SCM for software development in
to develop a new software product and should the number of small changes that must be con-
consider quality objectives. A concept document trolled on operational software. The SCM pro-
should be developed, followed by a maintenance cess is implemented by developing and following
plan. The maintenance concept for each software a software configuration management plan and
product needs to be documented in the plan [1*, operating procedures. Maintainers participate in
c7s2] and should address the Configuration Control Boards to determine the
content of the next release/version.
• scope of the software maintenance,
• adaptation of the software maintenance
process,
5-10 SWEBOK® Guide V3.0
It is not sufficient to simply hope that increased Reverse engineering is the process of analyzing
quality will result from the maintenance of soft- software to identify the software’s components
ware. Maintainers should have a software qual- and their inter-relationships and to create repre-
ity program. It must be planned and processes sentations of the software in another form or at
must be implemented to support the maintenance higher levels of abstraction. Reverse engineer-
process. The activities and techniques for Soft- ing is passive; it does not change the software
ware Quality Assurance (SQA), V&V, reviews, or result in new software. Reverse engineer-
and audits must be selected in concert with all ing efforts produce call graphs and control flow
the other processes to achieve the desired level graphs from source code. One type of reverse
of quality. It is also recommended that the main- engineering is redocumentation. Another type is
tainer adapt the software development processes, design recovery. Finally, data reverse engineer-
techniques and deliverables (for instance, testing ing, where logical schemas are recovered from
documentation), and test results. More details can physical databases, has grown in importance over
be found in the Software Quality KA. the last few years. Tools are key for reverse engi-
neering and related tasks such as redocumenta-
4. Techniques for Maintenance tion and design recovery.
• postoperation review: an assessment of par- • program slicers, which select only parts of a
allel operation and the impact of changing to program affected by a change;
the new environment; • static analyzers, which allow general view-
• data archival: storing the old software data. ing and summaries of a program content;
• dynamic analyzers, which allow the main-
4.5. Retirement tainer to trace the execution path of a
[1*, c5s6] program;
• data flow analyzers, which allow the main-
Once software has reached the end of its use- tainer to track all possible data flows of a
ful life, it must be retired. An analysis should program;
be performed to assist in making the retirement • cross-referencers, which generate indices of
decision. This analysis should be included in the program components; and
retirement plan, which covers retirement require- • dependency analyzers, which help maintain-
ments, impact, replacement, schedule, and effort. ers analyze and understand the interrelation-
Accessibility of archive copies of data may also ships between components of a program.
be included. Retiring software entails a number
of activities similar to migration. Reverse engineering tools assist the process by
working backwards from an existing product to
5. Software Maintenance Tools create artifacts such as specification and design
[1*, c6s4] [2*, c14] descriptions, which can then be transformed to
generate a new product from an old one. Main-
This topic encompasses tools that are particularly tainers also use software test, software configura-
important in software maintenance where exist- tion management, software documentation, and
ing software is being modified. Examples regard- software measurement tools.
ing program comprehension include
5-12 SWEBOK® Guide V3.0
Sneed 2008
[3*]
[2*]
[1*]
1. Software Maintenance
Fundamentals
1.1. Definitions and Terminology c3 c1s2, c2s2
1.2. Nature of Maintenance c1s3
1.3. Need for Maintenance c1s5
1.4. Majority of Maintenance Costs c4s3, c5s5.2
1.5. Evolution of Software c3s5
1.6. Categories of Maintenance c3, c6s2 c3s3.1, c4s3
2. Key Issues in Software
Maintenance
2.1. Technical Issues
2.1.1. Limited Understanding c6
2.1.2. Testing c6s2.2.2 c9
2.1.3. Impact Analysis c5s2.5 c13s3
2.1.4. Maintainability c6s8, c3s4 c12s5.5
2.2. Management Issues
2.2.1. Alignment with
c4
Organizational objectives
2.2.2. Staffing c4s5, c10s4
2.2.3. Process c5 c5
2.2.4. Organizational Aspects of
c7s.2.3 c10
Maintenance
2.2.5. Outsourcing/Offshoring all
2.3. Maintenance Cost Estimation
2.3.1. Cost Estimation c7s4.1 c7s2.4
Software Maintenance 5-13
Sneed 2008
[3*]
[2*]
[1*]
2.3.2. Parametric Models c12s5.6
2.3.3. Experience c12s5.5
2.4. Software Maintenance
c6s5 c12, c12s3.1
Measurement
2.4.1. Specific Measures c12
3. Maintenance Process
3.1. Maintenance Processes c5 c5
c5, c5s3.2.2,
3.2. Maintenance Activities
c6s8.2, c7s3.3
c3s10, c6s9, c7s2,
3.2.1. Unique Activities c6,c7
c7s3
3.2.2. Supporting Activities c4s1, c5, c6s7 c9
3.2.3. Maintenance Planning
c7s2, c7s.3
Activities
3.2.4. Software Configuration
c5s1.2.3 c11
Management
3.2.5. Software Quality c6s5, c6s7, c6s8 c12s5.3
4. Techniques for Maintenance
4.1. Program Comprehension c6,c14s5
4.2. Reengineering c7
4.3. Reverse Engineering c6s2 c7, c14s5
4.4. Migration c5s5
4.5. Retirement c5s6
5. Software Maintenance Tools c6s4 c14
5-14 SWEBOK® Guide V3.0
A. April and A. Abran, Software Maintenance [1*] IEEE Std. 14764-2006 (a.k.a. ISO/IEC
Management: Evaluation and Continuous 14764:2006) Standard for Software
Improvement [6]. Engineering—Software Life Cycle
Processes—Maintenance, IEEE, 2006.
This book explores the domain of small software
maintenance processes (S3M). It provides road- [2*] P. Grubb and A.A. Takang, Software
maps for improving software maintenance pro- Maintenance: Concepts and Practice, 2nd
cesses in organizations. It describes a software ed., World Scientific Publishing, 2003.
maintenance specific maturity model organized
by levels which allow for benchmarking and con- [3*] H.M. Sneed, “Offering Software
tinuous improvement. Goals for each key prac- Maintenance as an Offshore Service,” Proc.
tice area are provided, and the process model pre- IEEE Int’l Conf. Software Maintenance
sented is fully aligned with the architecture and (ICSM 08), IEEE, 2008, pp. 1–5.
framework of international standards ISO12207,
ISO14764 and ISO15504 and popular maturity [4*] J.W. Moore, The Road Map to Software
models like ITIL, CoBIT, CMMI and CM3. Engineering: A Standards-Based Guide,
Wiley-IEEE Computer Society Press, 2006.
M. Kajko-Mattsson, “Towards a Business
Maintenance Model,” IEEE Int’l Conf. [5] ISO/IEC/IEEE 24765:2010 Systems and
Software Maintenance [7]. Software Engineering—Vocabulary, ISO/
IEC/IEEE, 2010.
This paper presents an overview of the Correc-
tive Maintenance Maturity Model (CM3). In [6] A. April and A. Abran, Software
contrast to other process models, CM3 is a spe- Maintenance Management: Evaluation
cialized model, entirely dedicated to corrective and Continuous Improvement, Wiley-IEEE
maintenance of software. It views maintenance in Computer Society Press, 2008.
terms of the activities to be performed and their
order, in terms of the information used by these [7] M. Kajko-Mattsson, “Towards a Business
activities, goals, rules and motivations for their Maintenance Model,” Proc. Int’l Conf.
execution, and organizational levels and roles Software Maintenance, IEEE, 2001, pp.
involved at various stages of a typical corrective 500–509.
maintenance process.
CHAPTER 6
6-1
6-2 SWEBOK® Guide V3.0
The SCM activities are management and plan- development and change implementation activi-
ning of the SCM process, software configuration ties. A successful SCM implementation requires
identification, software configuration control, careful planning and management. This, in turn,
software configuration status accounting, soft- requires an understanding of the organizational
ware configuration auditing, and software release context for, and the constraints placed on, the
management and delivery. design and implementation of the SCM process.
The Software Configuration Management KA
is related to all the other KAs, since the object 1.1. Organizational Context for SCM
of configuration management is the artifact pro- [2*, c6, ann. D] [3*, introduction] [4*, c29]
duced and used throughout the software engi-
neering process. To plan an SCM process for a project, it is neces-
sary to understand the organizational context and
BREAKDOWN OF TOPICS FOR the relationships among organizational elements.
SOFTWARE CONFIGURATION SCM interacts with several other activities or
MANAGEMENT organizational elements.
The organizational elements responsible for the
The breakdown of topics for the Software Config- software engineering supporting processes may be
uration Management KA is shown in Figure 6.1. structured in various ways. Although the responsi-
bility for performing certain SCM tasks might be
1. Management of the SCM Process assigned to other parts of the organization (such as
the development organization), the overall respon-
SCM controls the evolution and integrity of a sibility for SCM often rests with a distinct organi-
product by identifying its elements; managing and zational element or designated individual.
controlling change; and verifying, recording, and Software is frequently developed as part of a
reporting on configuration information. From the larger system containing hardware and firmware
software engineer’s perspective, SCM facilitates elements. In this case, SCM activities take place
Software Configuration Management 6-3
in parallel with hardware and firmware CM activ- engineering issued by the various standards orga-
ities and must be consistent with system-level nizations (see Appendix B on standards).
CM. Note that firmware contains hardware and
software; therefore, both hardware and software 1.3. Planning for SCM
CM concepts are applicable. [2*, c6, ann. D, ann. E] [3*, c23] [4*, c29]
SCM might interface with an organization’s
quality assurance activity on issues such as The planning of an SCM process for a given
records management and nonconforming items. project should be consistent with the organi-
Regarding the former, some items under SCM zational context, applicable constraints, com-
control might also be project records subject to monly accepted guidance, and the nature of the
provisions of the organization’s quality assurance project (for example, size, safety criticality, and
program. Managing nonconforming items is usu- security). The major activities covered are soft-
ally the responsibility of the quality assurance ware configuration identification, software con-
activity; however, SCM might assist with track- figuration control, software configuration status
ing and reporting on software configuration items accounting, software configuration auditing, and
falling into this category. software release management and delivery. In
Perhaps the closest relationship is with the addition, issues such as organization and respon-
software development and maintenance orga- sibilities, resources and schedules, tool selection
nizations. It is within this context that many of and implementation, vendor and subcontractor
the software configuration control tasks are con- control, and interface control are typically con-
ducted. Frequently, the same tools support devel- sidered. The results of the planning activity are
opment, maintenance, and SCM purposes. recorded in an SCM Plan (SCMP), which is typi-
cally subject to SQA review and audit.
1.2. Constraints and Guidance for the SCM Branching and merging strategies should be
Process carefully planned and communicated, since they
[2*, c6, ann. D, ann. E] [3*, c2, c5] impact many SCM activities. From an SCM stand-
[5*, c19s2.2] point, a branch is defined as a set of evolving source
file versions [1]. Merging consists in combining
Constraints affecting, and guidance for, the SCM different changes to the same file [1]. This typi-
process come from a number of sources. Poli- cally occurs when more than one person changes a
cies and procedures set forth at corporate or other configuration item. There are many branching and
organizational levels might influence or prescribe merging strategies in common use (see the Further
the design and implementation of the SCM pro- Readings section for additional discussion).
cess for a given project. In addition, the contract The software development life cycle model
between the acquirer and the supplier might con- (see Software Life Cycle Models in the Software
tain provisions affecting the SCM process. For Engineering Process KA) also impacts SCM
example, certain configuration audits might be activities, and SCM planning should take this
required, or it might be specified that certain items into account. For instance, continuous integration
be placed under CM. When software products to is a common practice in many software develop-
be developed have the potential to affect public ment approaches. It is typically characterized by
safety, external regulatory bodies may impose frequent build-test-deploy cycles. SCM activities
constraints. Finally, the particular software life must be planned accordingly.
cycle process chosen for a software project and
the level of formalism selected to implement the 1.3.1. SCM Organization and Responsibilities
software affect the design and implementation of [2*, ann. Ds5, ann. Ds6] [3*, c10-11]
the SCM process. [4*, introduction, c29]
Guidance for designing and implementing an
SCM process can also be obtained from “best To prevent confusion about who will perform
practice,” as reflected in the standards on software given SCM activities or tasks, organizational
6-4 SWEBOK® Guide V3.0
roles to be involved in the SCM process need • Future: what is the plan for the tools’ use in
to be clearly identified. Specific responsibilities the future?
for given SCM activities or tasks also need to be • Change: how adaptable are the tools?
assigned to organizational entities, either by title • Branching and merging: are the tools’ capa-
or by organizational element. The overall author- bilities compatible with the planned branch-
ity and reporting channels for SCM should also be ing and merging strategies?
identified, although this might be accomplished • Integration: do the various SCM tools inte-
at the project management or quality assurance grate among themselves? With other tools in
planning stage. use in the organization?
• Migration: can the repository maintained by
1.3.2. SCM Resources and Schedules the version control tool be ported to another
[2*, ann. Ds8] [3*, c23] version control tool while maintaining com-
plete history of the configuration items it
Planning for SCM identifies the staff and tools contains?
involved in carrying out SCM activities and tasks.
It addresses scheduling questions by establishing SCM typically requires a set of tools, as
necessary sequences of SCM tasks and identify- opposed to a single tool. Such tool sets are some-
ing their relationships to the project schedules times referred to as workbenches. In such a con-
and milestones established at the project manage- text, another important consideration in plan-
ment planning stage. Any training requirements ning for tool selection is determining if the SCM
necessary for implementing the plans and train- workbench will be open (in other words, tools
ing new staff members are also specified. from different suppliers will be used in differ-
ent activities of the SCM process) or integrated
1.3.3. Tool Selection and Implementation (where elements of the workbench are designed
[3*, c26s2, c26s6] [4*, c29s5] to work together).
The size of the organization and the type of
As for any area of software engineering, the projects involved may also impact tool selection
selection and implementation of SCM tools (see topic 7, Software Configuration Manage-
should be carefully planned. The following ques- ment Tools).
tions should be considered:
1.3.4. Vendor/Subcontractor Control
• Organization: what motivates tool acquisi- [2*, c13] [3*, c13s9, c14s2]
tion from an organizational perspective?
• Tools: can we use commercial tools or A software project might acquire or make use of
develop them ourselves? purchased software products, such as compilers
• Environment: what are the constraints or other tools. SCM planning considers if and
imposed by the organization and its techni- how these items will be taken under configura-
cal context? tion control (for example, integrated into the proj-
• Legacy: how will projects use (or not) the ect libraries) and how changes or updates will be
new tools? evaluated and managed.
• Financing: who will pay for the tools’ Similar considerations apply to subcontracted
acquisition, maintenance, training, and software. When using subcontracted software,
customization? both the SCM requirements to be imposed on
• Scope: how will the new tools be deployed— the subcontractor’s SCM process as part of the
for instance, through the entire organization subcontract and the means for monitoring com-
or only on specific projects? pliance need to be established. The latter includes
• Ownership: who is responsible for the intro- consideration of what SCM information must be
duction of new tools? available for effective compliance monitoring.
Software Configuration Management 6-5
insights leading to process changes and corre- This involves understanding the software config-
sponding updates to the SCMP. uration within the context of the system configu-
Software libraries and the various SCM tool ration, selecting software configuration items,
capabilities provide sources for extracting infor- developing a strategy for labeling software items
mation about the characteristics of the SCM and describing their relationships, and identifying
process (as well as providing project and man- both the baselines to be used and the procedure
agement information). For example, information for a baseline’s acquisition of the items.
about the time required to accomplish various
types of changes would be useful in an evalua- 2.1.1. Software Configuration
tion of the criteria for determining what levels of [1, c3]
authority are optimal for authorizing certain types
of changes and for estimating future changes. Software configuration is the functional and phys-
Care must be taken to keep the focus of the ical characteristics of hardware or software as set
surveillance on the insights that can be gained forth in technical documentation or achieved in
from the measurements, not on the measurements a product. It can be viewed as part of an overall
themselves. Discussion of software process and system configuration.
product measurement is presented in the Soft-
ware Engineering Process KA. Software mea- 2.1.2. Software Configuration Item
surement programs are described in the Software [4*, c29s1.1]
Engineering Management KA.
A configuration item (CI) is an item or aggre-
1.5.2. In-Process Audits of SCM gation of hardware or software or both that is
[3*, c1s1] designed to be managed as a single entity. A soft-
ware configuration item (SCI) is a software entity
Audits can be carried out during the software that has been established as a configuration item
engineering process to investigate the current sta- [1]. The SCM typically controls a variety of items
tus of specific elements of the configuration or to in addition to the code itself. Software items with
assess the implementation of the SCM process. potential to become SCIs include plans, specifi-
In-process auditing of SCM provides a more for- cations and design documentation, testing mate-
mal mechanism for monitoring selected aspects rials, software tools, source and executable code,
of the process and may be coordinated with the code libraries, data and data dictionaries, and
SQA function (see topic 5, Software Configura- documentation for installation, maintenance,
tion Auditing). operations, and software use.
Selecting SCIs is an important process in
2. Software Configuration Identification which a balance must be achieved between pro-
[2*, c8] [4*, c29s1.1] viding adequate visibility for project control pur-
poses and providing a manageable number of
Software configuration identification identifies controlled items.
items to be controlled, establishes identification
schemes for the items and their versions, and 2.1.3. Software Configuration Item
establishes the tools and techniques to be used in Relationships
acquiring and managing controlled items. These [3*, c7s4]
activities provide the basis for the other SCM
activities. Structural relationships among the selected
SCIs, and their constituent parts, affect other
2.1. Identifying Items to Be Controlled SCM activities or tasks, such as software
[2*, c8s2.2] [4*, c29s1.1] building or analyzing the impact of proposed
changes. Proper tracking of these relationships
One of the first steps in controlling change is is also important for supporting traceability.
identifying the software items to be controlled. The design of the identification scheme for SCIs
Software Configuration Management 6-7
should consider the need to map identified items baselines. The functional baseline corresponds
to the software structure, as well as the need to to the reviewed system requirements. The allo-
support the evolution of the software items and cated baseline corresponds to the reviewed
their relationships. software requirements specification and soft-
ware interface requirements specification. The
2.1.4. Software Version developmental baseline represents the evolving
[1, c3] [4*, c29s3] software configuration at selected times during
the software life cycle. Change authority for
Software items evolve as a software project pro- this baseline typically rests primarily with the
ceeds. A version of a software item is an identi- development organization but may be shared
fied instance of an item. It can be thought of as a with other organizations (for example, SCM or
state of an evolving item. A variant is a version of Test). The product baseline corresponds to the
a program resulting from the application of soft- completed software product delivered for sys-
ware diversity. tem integration. The baselines to be used for a
given project, along with the associated levels of
2.1.5. Baseline authority needed for change approval, are typi-
[1, c3] cally identified in the SCMP.
of the evolving items. The software change request what changes to make, the authority for approv-
(SCR) is described in section 3.1. ing certain changes, support for the implementa-
In acquiring an SCI, its origin and initial integ- tion of those changes, and the concept of formal
rity must be established. Following the acquisi- deviations from project requirements as well as
tion of an SCI, changes to the item must be for- waivers of them. Information derived from these
mally approved as appropriate for the SCI and activities is useful in measuring change traffic
the baseline involved, as defined in the SCMP. and breakage as well as aspects of rework.
Following approval, the item is incorporated into
the software baseline according to the appropriate 3.1. Requesting, Evaluating, and Approving
procedure. Software Changes
[2*, c9s2.4] [4*, c29s2]
2.2. Software Library
[3*, c1s3] [4*, c29s1.2] The first step in managing changes to controlled
items is determining what changes to make. The
A software library is a controlled collection of software change request process (see a typical
software and related documentation designed to flow of a change request process in Figure 6.3)
aid in software development, use, or maintenance provides formal procedures for submitting and
[1]. It is also instrumental in software release man- recording change requests, evaluating the poten-
agement and delivery activities. Several types of tial cost and impact of a proposed change, and
libraries might be used, each corresponding to the accepting, modifying, deferring, or rejecting
software item’s particular level of maturity. For the proposed change. A change request (CR) is
example, a working library could support coding a request to expand or reduce the project scope;
and a project support library could support test- modify policies, processes, plans, or procedures;
ing, while a master library could be used for fin- modify costs or budgets; or revise schedules
ished products. An appropriate level of SCM con- [1]. Requests for changes to software configura-
trol (associated baseline and level of authority for tion items may be originated by anyone at any
change) is associated with each library. Security, point in the software life cycle and may include
in terms of access control and the backup facili- a suggested solution and requested priority. One
ties, is a key aspect of library management. source of a CR is the initiation of corrective
The tool(s) used for each library must support action in response to problem reports. Regardless
the SCM control needs for that library—both in of the source, the type of change (for example,
terms of controlling SCIs and controlling access defect or enhancement) is usually recorded on the
to the library. At the working library level, this is Software CR (SCR).
a code management capability serving develop- This provides an opportunity for tracking
ers, maintainers, and SCM. It is focused on man- defects and collecting change activity measure-
aging the versions of software items while sup- ments by change type. Once an SCR is received,
porting the activities of multiple developers. At a technical evaluation (also known as an impact
higher levels of control, access is more restricted analysis) is performed to determine the extent of
and SCM is the primary user. the modifications that would be necessary should
These libraries are also an important source the change request be accepted. A good under-
of information for measurements of work and standing of the relationships among software
progress. (and, possibly, hardware) items is important for
this task. Finally, an established authority—com-
3. Software Configuration Control mensurate with the affected baseline, the SCI
[2*, c9] [4*, c29s2] involved, and the nature of the change—will
evaluate the technical and managerial aspects
Software configuration control is concerned of the change request and either accept, modify,
with managing changes during the software reject, or defer the proposed change.
life cycle. It covers the process for determining
Software Configuration Management 6-9
3.1.1. Software Configuration Control Board CCB decisions, and reporting change process
[2*, c9s2.2] [3*, c11s1] [4*, c29s2] information. A link between this tool capability
and the problem-reporting system can facilitate
The authority for accepting or rejecting proposed the tracking of solutions for reported problems.
changes rests with an entity typically known as a
Configuration Control Board (CCB). In smaller 3.2. Implementing Software Changes
projects, this authority may actually reside with [4*, c29]
the leader or an assigned individual rather than a
multiperson board. There can be multiple levels Approved SCRs are implemented using the
of change authority depending on a variety of cri- defined software procedures in accordance with
teria—such as the criticality of the item involved, the applicable schedule requirements. Since a
the nature of the change (for example, impact on number of approved SCRs might be implemented
budget and schedule), or the project’s current simultaneously, it is necessary to provide a means
point in the life cycle. The composition of the for tracking which SCRs are incorporated into
CCBs used for a given system varies depending particular software versions and baselines. As
on these criteria (an SCM representative would part of the closure of the change process, com-
always be present). All stakeholders, appropriate pleted changes may undergo configuration audits
to the level of the CCB, are represented. When and software quality verification—this includes
the scope of authority of a CCB is strictly soft- ensuring that only approved changes have been
ware, it is known as a Software Configuration made. The software change request process
Control Board (SCCB). The activities of the CCB described above will typically document the
are typically subject to software quality audit or SCM (and other) approval information for the
review. change.
Changes may be supported by source code ver-
3.1.2. Software Change Request Process sion control tools. These tools allow a team of
[3*, c1s4, c8s4] software engineers, or a single software engineer,
to track and document changes to the source code.
An effective software change request (SCR) pro- These tools provide a single repository for storing
cess requires the use of supporting tools and pro- the source code, can prevent more than one soft-
cedures for originating change requests, enforc- ware engineer from editing the same module at
ing the flow of the change process, capturing the same time, and record all changes made to the
6-10 SWEBOK® Guide V3.0
source code. Software engineers check modules information system, the configuration status infor-
out of the repository, make changes, document mation to be managed for the evolving configura-
the changes, and then save the edited modules tions must be identified, collected, and maintained.
in the repository. If needed, changes can also be Various information and measurements are needed
discarded, restoring a previous baseline. More to support the SCM process and to meet the con-
powerful tools can support parallel development figuration status reporting needs of management,
and geographically distributed environments. software engineering, and other related activities.
These tools may be manifested as separate, The types of information available include the
specialized applications under the control of an approved configuration identification as well as
independent SCM group. They may also appear the identification and current implementation sta-
as an integrated part of the software engineering tus of changes, deviations, and waivers.
environment. Finally, they may be as elementary Some form of automated tool support is neces-
as a rudimentary change control system provided sary to accomplish the SCSA data collection and
with an operating system. reporting tasks; this could be a database capabil-
ity, a stand-alone tool, or a capability of a larger,
3.3. Deviations and Waivers integrated tool environment.
[1, c3]
4.2. Software Configuration Status Reporting
The constraints imposed on a software engineer- [2*, c10s2.4] [3*, c1s5, c9s1, c17]
ing effort or the specifications produced during the
development activities might contain provisions Reported information can be used by various
that cannot be satisfied at the designated point organizational and project elements—including
in the life cycle. A deviation is a written autho- the development team, the maintenance team,
rization, granted prior to the manufacture of an project management, and software quality activi-
item, to depart from a particular performance or ties. Reporting can take the form of ad hoc que-
design requirement for a specific number of units ries to answer specific questions or the periodic
or a specific period of time. A waiver is a writ- production of predesigned reports. Some infor-
ten authorization to accept a configuration item or mation produced by the status accounting activity
other designated item that is found, during produc- during the course of the life cycle might become
tion or after having been submitted for inspection, quality assurance records.
to depart from specified requirements but is nev- In addition to reporting the current status of the
ertheless considered suitable for use as-is or after configuration, the information obtained by the
rework by an approved method. In these cases, a SCSA can serve as a basis of various measure-
formal process is used for gaining approval for ments. Examples include the number of change
deviations from, or waivers of, the provisions. requests per SCI and the average time needed to
implement a change request.
4. Software Configuration Status Accounting
[2*, c10] 5. Software Configuration Auditing
[2*, c11]
Software configuration status accounting (SCSA)
is an element of configuration management con- A software audit is an independent examina-
sisting of the recording and reporting of informa- tion of a work product or set of work products to
tion needed to manage a configuration effectively. assess compliance with specifications, standards,
contractual agreements, or other criteria [1].
4.1. Software Configuration Status Information Audits are conducted according to a well-defined
[2*, c10s2.1] process consisting of various auditor roles and
responsibilities. Consequently, each audit must
The SCSA activity designs and operates a sys- be carefully planned. An audit can require a num-
tem for the capture and reporting of necessary ber of individuals to perform a variety of tasks
information as the life cycle proceeds. As in any over a fairly short period of time. Tools to support
Software Configuration Management 6-11
the planning and conduct of an audit can greatly the development activity; this includes internal
facilitate the process. releases as well as distribution to customers. When
Software configuration auditing determines different versions of a software item are available
the extent to which an item satisfies the required for delivery (such as versions for different plat-
functional and physical characteristics. Informal forms or versions with varying capabilities), it is
audits of this type can be conducted at key points frequently necessary to recreate specific versions
in the life cycle. Two types of formal audits might and package the correct materials for delivery of
be required by the governing contract (for exam- the version. The software library is a key element
ple, in contracts covering critical software): the in accomplishing release and delivery tasks.
Functional Configuration Audit (FCA) and the
Physical Configuration Audit (PCA). Successful 6.1. Software Building
completion of these audits can be a prerequisite [4*, c29s4]
for the establishment of the product baseline.
Software building is the activity of combining the
5.1. Software Functional Configuration Audit correct versions of software configuration items,
[2*, c11s2.1] using the appropriate configuration data, into an
executable program for delivery to a customer or
The purpose of the software FCA is to ensure that other recipient, such as the testing activity. For
the audited software item is consistent with its systems with hardware or firmware, the executable
governing specifications. The output of the soft- program is delivered to the system-building activ-
ware verification and validation activities (see ity. Build instructions ensure that the proper build
Verification and Validation in the Software Qual- steps are taken in the correct sequence. In addition
ity KA) is a key input to this audit. to building software for new releases, it is usually
also necessary for SCM to have the capability to
5.2. Software Physical Configuration Audit reproduce previous releases for recovery, testing,
[2*, c11s2.2] maintenance, or additional release purposes.
Software is built using particular versions of
The purpose of the software physical configura- supporting tools, such as compilers (see Com-
tion audit (PCA) is to ensure that the design and piler Basics in the Computing Foundations KA).
reference documentation is consistent with the It might be necessary to rebuild an exact copy of
as-built software product. a previously built software configuration item. In
this case, supporting tools and associated build
5.3. In-Process Audits of a Software Baseline instructions need to be under SCM control to
[2*, c11s2.3] ensure availability of the correct versions of the
tools.
As mentioned above, audits can be carried out A tool capability is useful for selecting the cor-
during the development process to investigate rect versions of software items for a given target
the current status of specific elements of the con- environment and for automating the process of
figuration. In this case, an audit could be applied building the software from the selected versions
to sampled baseline items to ensure that per- and appropriate configuration data. For projects
formance is consistent with specifications or to with parallel or distributed development envi-
ensure that evolving documentation continues to ronments, this tool capability is necessary. Most
be consistent with the developing baseline item. software engineering environments provide this
capability. These tools vary in complexity from
6. Software Release Management and requiring the software engineer to learn a spe-
Delivery cialized scripting language to graphics-oriented
[2*, c14] [3*, c8s2] approaches that hide much of the complexity of
an “intelligent” build facility.
In this context, release refers to the distribu- The build process and products are often sub-
tion of a software configuration item outside ject to software quality verification. Outputs of
6-12 SWEBOK® Guide V3.0
the build process might be needed for future refer- 7. Software Configuration Management Tools
ence and may become quality assurance records. [3*, c26s1] [4*, c8s2]
Sommerville 2011
IEEE 828-2012
Moore 2006
Hass 2003
[5*]
[3*]
[2*]
[4*]
1. Management of the SCM
Process
1.1. Organizational Context for
c6, ann.D introduction c29
SCM
1.2. Constraints and Guidance c6, ann.D,
c2 c19s2.2 c29 intro
for the SCM Process ann.E
c6, ann.D,
1.3. Planning for SCM c23 c29
ann.E
1.3.1. SCM Organization and
ann.Ds5–6 c10–11 c29 intro
Responsibilities
1.3.2. SCM Resources and
ann.Ds8 c23
Schedules
1.3.3. Tool Selection and
c26s2; s6 c29s5
Implementation
1.3.4. Vendor/Subcontractor
c13 c13s9–c14s2
Control
1.3.5. Interface Control c12 c24s4
1.4. SCM Plan ann.D c23 c29s1
1.5. Surveillance of Software
c11s3
Configuration Management
1.5.1. SCM Measures and c9s2;
Measurement c25s2–s3
1.5.2. In-Process Audits of
c1s1
SCM
2. Software Configuration
c29s1.1
Identification
2.1. Identifying Items to Be
c8s2.2 c29s1.1
Controlled
2.1.1. Software Configuration
2.1.2. Software Configuration
c29s1.1
Item
2.1.3. Software Configuration
c7s4
Item Relationships
2.1.4. Software Version c29s3
6-14 SWEBOK® Guide V3.0
Sommerville 2011
IEEE 828-2012
Moore 2006
Hass 2003
[5*]
[3*]
[2*]
[4*]
2.1.5. Baseline
2.1.6. Acquiring Software
c18
Configuration Items
2.2. Software Library c1s3 c29s1.2
3. Software Configuration
c9 c29s2
Control
3.1. Requesting, Evaluating, and
c9s2.4 c29s2
Approving Software Changes
3.1.1. Software Configuration
c9s2.2 c11s1 c29s2
Control Board
3.1.2. Software Change
c1s4, c8s4
Request Process
3.2. Implementing Software
c29
Changes
3.3. Deviations and Waivers
4. Software Configuration
c10
Status Accounting
4.1. Software Configuration
c10s2.1
Status Information
4.2. Software Configuration c1s5, c9s1,
c10s2.4
Status Reporting c17
5. Software Configuration
c11
Auditing
5.1. Software Functional
c11s2.1
Configuration Audit
5.2. Software Physical
c11s2.2
Configuration Audit
5.3. In-Process Audits of a
c11s2.3
Software Baseline
6. Software Release
c14 c8s2 c29s3
Management and Delivery
6.1. Software Building c29s4
6.2. Software Release
c29s3.2
Management
7. Software Configuration
c26s1
Management Tools
Software Configuration Management 6-15
Stephen P. Berczuk and Brad Appleton, [1] ISO/IEC/IEEE 24765:2010 Systems and
Software Configuration Management Software Engineering—Vocabulary, ISO/
Patterns: Effective Teamwork, Practical IEC/IEEE, 2010.
Integration [6].
[2*] IEEE Std. 828-2012, Standard for
This book expresses useful SCM practices and Configuration Management in Systems and
strategies as patterns. The patterns can be imple- Software Engineering, IEEE, 2012.
mented using various tools, but they are expressed
in a tool-agnostic fashion. [3*] A.M.J. Hass, Configuration Management
Principles and Practices, 1st ed., Addison-
“CMMI for Development,” Version 1.3, pp. Wesley, 2003.
137–147 [7].
[4*] I. Sommerville, Software Engineering, 9th
This model presents a collection of best prac- ed., Addison-Wesley, 2011.
tices to help software development organizations
improve their processes. At maturity level 2, it [5*] J.W. Moore, The Road Map to Software
suggests configuration management activities. Engineering: A Standards-Based Guide,
Wiley-IEEE Computer Society Press, 2006.
7-1
7-2 SWEBOK® Guide V3.0
factor in maintaining and improving productivity management—a basic principle of any true engi-
and competitiveness. Effective reuse requires a neering discipline (see Measurement in the Engi-
strategic vision that reflects the advantages and neering Foundations KA)—can help improve
disadvantages of reuse. the perception and the reality. In essence, man-
In addition to understanding the aspects of agement without measurement (qualitative and
management that are uniquely influenced by soft- quantitative) suggests a lack of discipline, and
ware projects, software engineers should have measurement without management suggests a
some knowledge of the more general aspects of lack of purpose or context. Effective management
management that are discussed in this KA (even requires a combination of both measurement and
in the first few years after graduation). experience.
Attributes of organizational culture and behav- The following working definitions are adopted
ior, plus management of other functional areas here:
of the enterprise, have an influence, albeit indi-
rectly, on an organization’s software engineering • Management is a system of processes and
processes. controls required to achieve the strategic
Extensive information concerning software objectives set by the organization.
project management can be found in the Guide • Measurement refers to the assignment of val-
to the Project Management Body of Knowledge ues and labels to software engineering work
(PMBOK® Guide) and the Software Extension to products, processes, and resources plus the
the PMBOK® Guide (SWX) [1] [2]. Each of these models that are derived from them, whether
guides includes ten project management KAs: these models are developed using statistical
project integration management, project scope or other techniques [3* , c7, c8].
management, project time management, project
cost management, project quality management, The software engineering project management
project human resource management, project sections in this KA make extensive use of the
communications management, project risk man- software engineering measurement section.
agement, project procurement management, and This KA is closely related to others in the
project stakeholder management. Each KA has SWEBOK Guide, and reading the following KA
direct relevance to this Software Engineering descriptions in conjunction with this one will be
Management KA. particularly helpful:
Additional information is also provided in the
other references and further readings for this KA. • The Engineering Foundations KA describes
This Software Engineering Management KA some general concepts of measurement that
consists of the software project management pro- are directly applicable to the Software Engi-
cesses in the first five topics in Figure 7.1 (Initia- neering Measurement section of this KA.
tion and Scope Definition, Software Project Plan- In addition, the concepts and techniques
ning, Software Project Enactment, Review and presented in the Statistical Analysis section
Evaluation, Closure), plus Software Engineering of the Engineering Foundations KA apply
Measurement in the sixth topic and Software directly to many topics in this KA.
Engineering Management Tools in the seventh • The Software Requirements KA describes
topic. While project management and measure- some of the activities that should be per-
ment management are often regarded as being formed during the Initiation and Scope defi-
separate, and indeed each does possess many nition phase of the project.
unique attributes, the close relationship has led to • The Software Configuration Management
combined treatment in this KA. KA deals with identification, control, status
Unfortunately, a common perception of the soft- accounting, and auditing of software con-
ware industry is that software products are deliv- figurations along with software release man-
ered late, over budget, of poor quality, and with agement and delivery and software configu-
incomplete functionality. Measurement-informed ration management tools.
7-4 SWEBOK® Guide V3.0
should be evaluated. Procurement of software well as by issues relating to personnel (for exam-
and use of third parties to develop deliverables ple, productivity of individuals and teams, team
should be planned and suppliers selected (see dynamics, and team structures).
section 3.2, Software Acquisition and Supplier
Contract Management). 2.5. Risk Management
[3*, c9] [5*, c5]
2.3. Effort, Schedule, and Cost Estimation
[3*, c6] Risk and uncertainty are related but distinct con-
cepts. Uncertainty results from lack of informa-
The estimated range of effort required for a proj- tion. Risk is characterized by the probability of an
ect, or parts of a project, can be determined using event that will result in a negative impact plus a
a calibrated estimation model based on historical characterization of the negative impact on a proj-
size and effort data (when available) and other ect. Risk is often the result of uncertainty. The
relevant methods such as expert judgment and converse of risk is opportunity, which is charac-
analogy. Task dependencies can be established terized by the probability that an event having a
and potential opportunities for completing tasks positive outcome might occur.
concurrently and sequentially can be identified Risk management entails identification of risk
and documented using a Gantt chart, for exam- factors and analysis of the probability and poten-
ple. For predictive SDLC projects, the expected tial impact of each risk factor, prioritization of
schedule of tasks with projected start times, dura- risk factors, and development of risk mitigation
tions, and end times is typically produced during strategies to reduce the probability and minimize
planning. For adaptive SDLC projects, an over- the negative impact if a risk factor becomes a
all estimate of effort and schedule is typically problem. Risk assessment methods (for example,
developed from the initial understanding of the expert judgment, historical data, decision trees,
requirements, or, alternatively, constraints on and process simulations) can sometimes be used
overall effort and schedule may be specified and in order to identify and evaluate risk factors.
used to determine an initial estimate of the num- Project abandonment conditions can also be
ber of iterative cycles and estimates of effort and determined at this point in discussion with all
other resources allocated to each cycle. relevant stakeholders. Software-unique aspects
Resource requirements (for example, people of risk, such as software engineers’ tendency to
and tools) can be translated into cost estimates. add unneeded features, or the risks related to soft-
Initial estimation of effort, schedule, and cost is ware’s intangible nature, can influence risk man-
an iterative activity that should be negotiated and agement of a software project. Particular atten-
revised among affected stakeholders until con- tion should be paid to the management of risks
sensus is reached on resources and time available related to software quality requirements such as
for project completion. safety or security (see the Software Quality KA).
Risk management should be done not only at the
2.4. Resource Allocation beginning of a project, but also at periodic inter-
[3*, c5, c10, c11] vals throughout the project life cycle.
and expectations. Procedures concerned with example, software design, software code, and
ongoing Software Quality Assurance (SQA) and software test cases) are generated.
quality improvement throughout the development
process, and for verification and validation of 3.2. Software Acquisition and Supplier Contract
the deliverable software product, should also be Management
specified during quality planning (for example, [3*, c3, c4]
technical reviews and inspections or demonstra-
tions of completed functionality; see the Software Software acquisition and supplier contract man-
Quality KA). agement is concerned with issues involved in
contracting with customers of the software devel-
2.7. Plan Management opment organization who acquire the deliverable
[3*, c4] work products and with suppliers who supply
products or services to the software engineering
For software projects, where change is an expec- organization.
tation, plans should be managed. Managing the This may involve selection of appropriate kinds
project plan should thus be planned. Plans and of contracts, such as fixed price, time and materi-
processes selected for software development als, cost plus fixed fee, or cost plus incentive fee.
should be systematically monitored, reviewed, Agreements with customers and suppliers typi-
reported, and, when appropriate, revised. Plans cally specify the scope of work and the deliver-
associated with supporting processes (for exam- ables and include clauses such as penalties for late
ple, documentation, software configuration man- delivery or nondelivery and intellectual property
agement, and problem resolution) also should be agreements that specify what the supplier or sup-
managed. Reporting, monitoring, and controlling pliers are providing and what the acquirer is pay-
a project should fit within the selected SDLC and ing for, plus what will be delivered to and owned
the realities of the project; plans should account by the acquirer. For software being developed by
for the various artifacts that will be used to man- suppliers (both internal to or external to the soft-
age the project. ware development organization), agreements com-
monly indicate software quality requirements for
3. Software Project Enactment acceptance of the delivered software.
After the agreement has been put in place, exe-
During software project enactment (also known cution of the project in compliance with the terms
as project execution) plans are implemented and of the agreement should be managed (see chapter
the processes embodied in the plans are enacted. 12 of SWX, Software Procurement Management,
Throughout, there should be a focus on adher- for more information on this topic [2]).
ence to the selected SDLC processes, with an
overriding expectation that adherence will lead to 3.3. Implementation of Measurement Process
the successful satisfaction of stakeholder require- [3*, c7]
ments and achievement of the project’s objec-
tives. Fundamental to enactment are the ongoing The measurement process should be enacted dur-
management activities of monitoring, control- ing the software project to ensure that relevant
ling, and reporting. and useful data are collected (see sections 6.2,
Plan the Measurement Process, and 6.3, Perform
3.1. Implementation of Plans the Measurement Process).
[4*, c2]
3.4. Monitor Process
Project activities should be undertaken in accor- [3*, c8]
dance with the project plan and supporting plans.
Resources (for example, personnel, technology, Adherence to the project plan and related
and funding) are utilized and work products (for plans should be assessed continually and at
7-8 SWEBOK® Guide V3.0
predetermined intervals. Also, outputs and com- software configuration control and software con-
pletion criteria for each task should be assessed. figuration management procedures should be
Deliverables should be evaluated in terms of their adhered to (see the Software Configuration Man-
required characteristics (for example, via inspec- agement KA), decisions should be documented
tions or by demonstrating working functionality). and communicated to all relevant parties, plans
Effort expenditure, schedule adherence, and costs should be revisited and revised when necessary,
to date should be analyzed, and resource usage and relevant data recorded (see section 6.3, Per-
examined. The project risk profile (see section form the Measurement Process).
2.5, Risk Management) should be revisited, and
adherence to software quality requirements eval- 3.6. Reporting
uated (see Software Quality Requirements in the [3*, c11]
Software Quality KA).
Measurement data should be analyzed (see Sta- At specified and agreed-upon times, progress to
tistical Analysis in the Engineering Foundations date should be reported—both within the orga-
KA). Variance analysis based on the deviation of nization (for example, to a project steering com-
actual from expected outcomes and values should mittee) and to external stakeholders (for exam-
be determined. This may include cost overruns, ple, clients or users). Reports should focus on
schedule slippage, or other similar measures. the information needs of the target audience as
Outlier identification and analysis of quality and opposed to the detailed status reporting within the
other measurement data should be performed (for project team.
example, defect analysis; see Software Quality
Measurement in the Software Quality KA). Risk 4. Review and Evaluation
exposures should be recalculated (see section 2.5,
Risk Management). These activities can enable At prespecified times and as needed, overall prog-
problem detection and exception identification ress towards achievement of the stated objectives
based on thresholds that have been exceeded. and satisfaction of stakeholder (user and customer)
Outcomes should be reported when thresholds requirements should be evaluated. Similarly,
have been exceeded, or as necessary. assessments of the effectiveness of the software
process, the personnel involved, and the tools and
3.5. Control Process methods employed should also be undertaken reg-
[3*, c7, c8] ularly and as determined by circumstances.
the organization and the project (for exam- prioritized. Then a subset of objectives to be
ple, an organizational objective might be addressed can be selected, documented, com-
“first-to-market with new products”). municated, and reviewed by stakeholders.
• Scope of measurement. The organizational • Select measures. Candidate measures should
unit to which each measurement requirement be selected, with clear links to the informa-
is to be applied should be established. This tion needs. Measures should be selected
may consist of a functional area, a single based on the priorities of the information
project, a single site, or an entire enterprise. needs and other criteria such as cost of col-
The temporal scope of the measurement lection, degree of process disruption during
effort should also be considered because collection, ease of obtaining accurate, con-
time series of some measurements may be sistent data, and ease of analysis and report-
required; for example, to calibrate estima- ing. Because internal quality characteristics
tion models (see section 2.3, Effort, Sched- (see Models and Quality Characteristics in
ule, and Cost Estimation). the Software Quality KA) are often not con-
• Team commitment to measurement. The tained in the contractually binding software
commitment should be formally established, requirements, it is important to consider mea-
communicated, and supported by resources suring the internal quality of the software to
(see next item). provide an early indicator of potential issues
• Resources for measurement. An organiza- that may impact external stakeholders.
tion’s commitment to measurement is an • Define data collection, analysis, and report-
essential factor for success, as evidenced by ing procedures. This encompasses collection
the assignment of resources for implement- procedures and schedules, storage, verifica-
ing the measurement process. Assigning tion, analysis, reporting, and configuration
resources includes allocation of responsibil- management of data.
ity for the various tasks of the measurement • Select criteria for evaluating the information
process (such as analyst and librarian). Ade- products. Criteria for evaluation are influ-
quate funding, training, tools, and support to enced by the technical and business objec-
conduct the process should also be allocated. tives of the organizational unit. Information
products include those associated with the
product being produced, as well as those
6.2. Plan the Measurement Process associated with the processes being used to
[7*, c1, c2] manage and measure the project.
• Provide resources for measurement tasks. The
• Characterize the organizational unit. The measurement plan should be reviewed and
organizational unit provides the context for approved by the appropriate stakeholders to
measurement, so the organizational context include all data collection procedures; storage,
should be made explicit, including the con- analysis, and reporting procedures; evaluation
straints that the organization imposes on criteria; schedules; and responsibilities. Crite-
the measurement process. The characteriza- ria for reviewing these artifacts should have
tion can be stated in terms of organizational been established at the organizational-unit
processes, application domains, technology, level or higher and should be used as the basis
organizational interfaces, and organizational for these reviews. Such criteria should take
structure. into consideration previous experience, avail-
• Identify information needs. Information ability of resources, and potential disruptions
needs are based on the goals, constraints, to projects when changes from current prac-
risks, and problems of the organizational tices are proposed. Approval demonstrates
unit. They may be derived from business, commitment to the measurement process.
organizational, regulatory, and/or product • Identify resources to be made available for
objectives. They should be identified and implementing the planned and approved
Software Engineering Management 7-11
• Integrate measurement procedures with rel- • Evaluate information products and the mea-
evant software processes. The measurement surement process against specified evalu-
procedures, such as data collection, should ation criteria and determine strengths and
be integrated into the software processes weaknesses of the information products or
they are measuring. This may involve chang- process, respectively. Evaluation may be
ing current software processes to accommo- performed by an internal process or an exter-
date data collection or generation activities. nal audit; it should include feedback from
It may also involve analysis of current soft- measurement users. Lessons learned should
ware processes to minimize additional effort be recorded in an appropriate database.
and evaluation of the effect on employees to • Identify potential improvements. Such
ensure that the measurement procedures will improvements may be changes in the format
be accepted. Morale issues and other human of indicators, changes in units measured, or
factors should be considered. In addition, the reclassification of measurement categories.
measurement procedures should be commu- The costs and benefits of potential improve-
nicated to those providing the data. Training ments should be determined and appropriate
and support may also need to be provided. improvement actions should be reported.
Data analysis and reporting procedures are • Communicate proposed improvements to the
typically integrated into organizational and/ measurement process owner and stakehold-
or project processes in a similar manner. ers for review and approval. Also, lack of
• Collect data. Data should be collected, veri- potential improvements should be commu-
fied, and stored. Collection can sometimes nicated if the analysis fails to identify any
be automated by using software engineer- improvements.
ing management tools (see topic 7, Soft-
ware Engineering Management Tools) to 7. Software Engineering Management Tools
analyze data and develop reports. Data may [3*, c5, c6, c7]
be aggregated, transformed, or recoded as
part of the analysis process, using a degree Software engineering management tools are often
of rigor appropriate to the nature of the data used to provide visibility and control of software
and the information needs. The results of engineering management processes. Some tools
this analysis are typically indicators such as are automated while others are manually imple-
graphs, numbers, or other indications that mented. There has been a recent trend towards
will be interpreted, resulting in conclusions the use of integrated suites of software engineer-
and recommendations to be presented to ing tools that are used throughout a project to
stakeholders (see Statistical Analysis in the plan, collect and record, monitor and control, and
7-12 SWEBOK® Guide V3.0
report project and product information. Tools can and subjective estimates of the probabilities of
be divided into the following categories: risk events. Monte Carlo simulation tools can
Project Planning and Tracking Tools. Project be used to produce probability distributions of
planning and tracking tools can be used to esti- effort, schedule, and risk by combining multiple
mate project effort and cost and to prepare project input probability distributions in an algorithmic
schedules. Some projects use automated estima- manner.
tion tools that accept as input the estimated size Communications Tools. Communication tools
and other characteristics of a software product can assist in providing timely and consistent
and produce estimates of the required total effort, information to relevant stakeholders involved in a
schedule, and cost. Planning tools also include project. These tools can include things like email
automated scheduling tools that analyze the tasks notifications and broadcasts to team members
within a work breakdown structure, their esti- and stakeholders. They also include communica-
mated durations, their precedence relationships, tion of minutes from regularly scheduled project
and the resources assigned to each task to pro- meetings, daily stand-up meetings, plus charts
duce a schedule in the form of a Gantt chart. showing progress, backlogs, and maintenance
Tracking tools can be used to track project request resolutions.
milestones, regularly scheduled project status Measurement Tools. Measurement tools sup-
meetings, scheduled iteration cycles, product port activities related to the software measure-
demonstrations, and/or action items. ment program (see topic 6, Software Engineer-
Risk Management Tools. Risk management ing Measurement). There are few completely
tools (see section 2.5, Risk Management) can automated tools in this category. Measurement
be used to track risk identification, estimation, tools used to gather, analyze, and report project
and monitoring. These tools include the use of measurement data may be based on spreadsheets
approaches such as simulation or decision trees developed by project team members or organiza-
to analyze the effect of costs versus payoffs tional employees.
Software Engineering Management 7-13
[7*]
[5*]
[3*]
[4*]
1. Initiation and Scope
Definition
1.1. Determination and
c3
Negotiation of Requirements
1.2. Feasibility Analysis c4
1.3. Process for the Review and
c3
Revision of Requirements
2. Software Project Planning
2.1. Process Planning c2, c3, c4, c5 c1
2.2. Determine Deliverables c4, c5, c6
2.3. Effort, Schedule, and Cost
c6
Estimation
2.4. Resource Allocation c5, c10, c11
2.5. Risk Management c9 c5
2.6. Quality Management c4 c24
2.7. Plan Management c4
3. Software Project Enactment
3.1. Implementation of Plans c2
3.2. Software Acquisition and
c3, c4
Supplier Contract Management
3.3. Implementation of
c7
Measurement Process
3.4. Monitor Process c8
3.5. Control Process c7, c8
3.6. Reporting c11
4. Review and Evaluation
4.1. Determining Satisfaction of
Requirements
4.2. Reviewing and Evaluating
c8, c10
Performance
7-14 SWEBOK® Guide V3.0
[7*]
[5*]
[3*]
[4*]
5. Closure
5.1. Determining Closure
5.2. Closure Activities
6. Software Engineering
Measurement
6.1. Establish and Sustain
c1, c2
Measurement Commitment
6.2. Plan the Measurement
c1, c2
Process
6.3. Perform the Measurement
c1, c2
Process
6.4. Evaluate Measurement c1, c2
7. Software Engineering
c5, c6, c7
Management Tools
Software Engineering Management 7-15
A Guide to the Project Management Body of [1] Project Management Institute, A Guide to the
Knowledge (PMBOK® Guide) [1]. Project Management Body of Knowledge
(PMBOK(R) Guide), 5th ed., Project
The PMBOK® Guide provides guidelines for Management Institute, 2013.
managing individual projects and defines project
management-related concepts. It also describes [2] Project Management Institute and IEEE
the project management life cycle and its related Computer Society, Software Extension to
processes, as well as the project life cycle. It is the PMBOK® Guide Fifth Edition, Project
a globally recognized guide for the project man- Management Institute, 2013.
agement profession.
[3*] R.E. Fairley, Managing and Leading
Software Extension to the Guide to the Software Projects, Wiley-IEEE Computer
Project Management Body of Knowledge Society Press, 2009.
(PMBOK® Guide) [2].
[4*] I. Sommerville, Software Engineering, 9th
SWX provides adaptations and extensions to ed., Addison-Wesley, 2011.
the generic practices of project management
documented in the PMBOK® Guide for manag- [5*] B. Boehm and R. Turner, Balancing Agility
ing software projects. The primary contribution and Discipline: A Guide for the Perplexed,
of this extension to the PMBOK® Guide is a Addison-Wesley, 2003.
description of processes that are applicable for
managing adaptive life cycle software projects. [6] IEEE Std. 15939-2008 Standard Adoption of
ISO/IEC 15939:2007 Systems and Software
IEEE Standard Adoption of ISO/IEC 15939 [6]. Engineering—Measurement Process,
IEEE, 2008.
This international standard identifies a process
that supports defining a suitable set of measures [7*] J. McGarry et al., Practical Software
to address specific information needs. It identi- Measurement: Objective Information
fies the activities and tasks that are necessary to for Decision Makers, Addison-Wesley
successfully identify, define, select, apply, and Professional, 2001.
improve measurement within an overall project
or organizational measurement structure. [8] J. McDonald, Managing the Development of
Software Intensive Systems, John Wiley and
J. McDonald, Managing the Development of Sons, Inc., 2010.
Software Intensive Systems, Wiley, 2010 [8].
8-1
8-2 SWEBOK® Guide V3.0
the software requirements process and its subpro- result from a systematic approach to accomplish-
cesses may be entered and exited multiple times ing software processes and producing work prod-
during software development or modification. ucts—be it at the individual, project, or organiza-
Complete definition of a software process may tional level—and to introduce new or improved
also include the roles and competencies, IT sup- processes.
port, software engineering techniques and tools, Processes are changed with the expectation that
and work environment needed to perform the a new or modified process will improve the effi-
process, as well as the approaches and measures ciency and/or effectiveness of the process and the
(Key Performance Indicators) used to determine quality of the resulting work products. Changing
the efficiency and effectiveness of performing the to a new process, improving an existing process,
process. organizational change, and infrastructure change
In addition, a software process may include (technology insertion or changes in tools) are
interleaved technical, collaborative, and adminis- closely related, as all are usually initiated with the
trative activities. goal of improving the cost, development sched-
Notations for defining software processes ule, or quality of the software products. Process
include textual lists of constituent activities and change has impacts not only for the software
tasks described in natural language; data-flow product; they often lead to organizational change.
diagrams; state charts; BPMN; IDEF0; Petri nets; Changing a process or introducing a new process
and UML activity diagrams. The transforming can have ripple effects throughout an organiza-
tasks within a process may be defined as proce- tion. For example, changes in IT infrastruc-
dures; a procedure may be specified as an ordered ture tools and technology often require process
set of steps or, alternatively, as a checklist of the changes.
work to be accomplished in performing a task. Existing processes may be modified when
It must be emphasized that there is no best soft- other new processes are deployed for the first
ware process or set of software processes. Soft- time (for example, introducing an inspection
ware processes must be selected, adapted, and activity within a software development project
applied as appropriate for each project and each will likely impact the software testing process—
organizational context. No ideal process, or set of see Reviews and Audits in the Software Quality
processes, exists. KA and in the Software Testing KA). These situ-
ations can also be termed “process evolution.”
1.1. Software Process Management If the modifications are extensive, then changes
[3*, s26.1] [4*, p453–454] in the organizational culture and business model
will likely be necessary to accommodate the pro-
Two objectives of software process management cess changes.
are to realize the efficiency and effectiveness that
8-4 SWEBOK® Guide V3.0
Many distinct software processes have been The intangible and malleable nature of software
defined for use in the various parts of the soft- permits a wide variety of software development
ware development and software maintenance life life cycle models, ranging from linear models in
cycles. These processes can be categorized as which the phases of software development are
follows: accomplished sequentially with feedback and
iteration as needed followed by integration, test-
1. Primary processes include software pro- ing, and delivery of a single product; to iterative
cesses for development, operation, and models in which software is developed in incre-
maintenance of software. ments of increasing functionality on iterative
2. Supporting processes are applied intermit- cycles; to agile models that typically involve
tently or continuously throughout a software frequent demonstrations of working software to
product life cycle to support primary pro- a customer or user representative who directs
cesses; they include software processes such development of the software in short iterative
as configuration management, quality assur- cycles that produce small increments of working,
ance, and verification and validation. deliverable software. Incremental, iterative, and
3. Organizational processes provide sup- agile models can deliver early subsets of working
port for software engineering; they include software into the user environment, if desired.
training, process measurement analysis, Linear SDLC models are sometimes referred
infrastructure management, portfolio and to as predictive software development life cycle
reuse management, organizational process models, while iterative and agile SDLCs are
improvement, and management of software referred to as adaptive software development
life cycle models. life cycle models. It should be noted that vari-
4. Cross-project processes, such as reuse, soft- ous maintenance activities during an SPLC can
ware product line, and domain engineering; be conducted using different SDLC models, as
they involve more than a single software appropriate to the maintenance activities.
project in an organization. A distinguishing feature of the various soft-
ware development life cycle models is the way in
Software processes in addition to those listed which software requirements are managed. Lin-
above include the following. ear development models typically develop a com-
Project management processes include pro- plete set of software requirements, to the extent
cesses for planning and estimating, resource possible, during project initiation and planning.
management, measuring and controlling, leading, The software requirements are then rigorously
managing risk, managing stakeholders, and coor- controlled. Changes to the software requirements
dinating the primary, supporting, organizational, are based on change requests that are processed
and cross-project processes of software develop- by a change control board (see Requesting,
ment and maintenance projects. Evaluating and Approving Software Changes in
Software processes are also developed for the Change Control Board in the Software Con-
particular needs, such as process activities that figuration Management KA). An incremental
address software quality characteristics (see model produces successive increments of work-
the Software Quality KA). For example, secu- ing, deliverable software based on partitioning
rity concerns during software development may of the software requirements to be implemented
necessitate one or more software processes to in each of the increments. The software require-
protect the security of the development environ- ments may be rigorously controlled, as in a linear
ment and reduce the risk of malicious acts. Soft- model, or there may be some flexibility in revising
ware processes may also be developed to provide the software requirements as the software product
adequate grounds for establishing confidence in evolves. Agile models may define product scope
the integrity of the software. and high-level features initially; however, agile
8-6 SWEBOK® Guide V3.0
models are designed to facilitate evolution of the construction, and testing) can be adapted to facili-
software requirements during the project. tate operation, support, maintenance, migration,
It must be emphasized that the continuum of and retirement of the software.
SDLCs from linear to agile is not a thin, straight Additional factors to be considered when
line. Elements of different approaches may be defining and tailoring a software life cycle model
incorporated into a specific model; for exam- include required conformance to standards, direc-
ple, an incremental software development life tives, and policies; customer demands; criticality
cycle model may incorporate sequential soft- of the software product; and organizational matu-
ware requirements and design phases but permit rity and competencies. Other factors include the
considerable flexibility in revising the software nature of the work (e.g., modification of exist-
requirements and architecture during software ing software versus new development) and the
construction. application domain (e.g., aerospace versus hotel
management).
2.3. Software Process Adaptation
[1*, s2.7] [2*, p51] 3. Software Process Assessment and
Improvement
Predefined SDLCs, SPLCs, and individual soft- [2*, p188, p194] [3*, c26] [4*, p397, c15]
ware processes often need to be adapted (or
“tailored”) to better serve local needs. Organiza- This topic addresses software process assess-
tional context, innovations in technology, project ment models, software process assessment meth-
size, product criticality, regulatory requirements, ods, software process improvement models, and
industry practices, and corporate culture may continuous and staged process ratings. Software
determine needed adaptations. Adaptation of process assessments are used to evaluate the form
individual software processes and software life and content of a software process, which may
cycle models (development and product) may be specified by a standardized set of criteria. In
consist of adding more details to software pro- some instances, the terms “process appraisal”
cesses, activities, tasks, and procedures to address and “capability evaluation” are used instead of
critical concerns. It may consist of using an alter- process assessment. Capability evaluations are
nate set of activities that achieves the purpose and typically performed by an acquirer (or potential
outcomes of the software process. Adaptation acquirer) or by an external agent on behalf of
may also include omitting software processes an acquirer (or potential acquirer). The results
or activities from a development or product life are used as an indicator of whether the software
cycle model that are clearly inapplicable to the processes used by a supplier (or potential sup-
scope of work to be accomplished. plier) are acceptable to the acquirer. Performance
appraisals are typically performed within an orga-
2.4. Practical Considerations nization to identify software processes in need of
[2*, p188–190] improvement or to determine whether a process
(or processes) satisfies the criteria at a given level
In practice, software processes and activities are of process capability or maturity.
often interleaved, overlapped, and applied concur- Process assessments are performed at the lev-
rently. Software life cycle models that specify dis- els of entire organizations, organizational units
crete software processes, with rigorously specified within organizations, and individual projects.
entry and exit criteria and prescribed boundaries Assessment may involve issues such as assess-
and interfaces, should be recognized as idealiza- ing whether software process entry and exit cri-
tions that must be adapted to reflect the realities of teria are being met, to review risk factors and
software development and maintenance within the risk management, or to identify lessons learned.
organizational context and business environment. Process assessment is carried out using both an
Another practical consideration: software assessment model and an assessment method. The
processes (such as configuration management, model can provide a norm for a benchmarking
Software Engineering Process 8-7
comparison among projects within an organiza- examining the procedural steps followed and
tion and among organizations. results obtained plus data concerning defects
A process audit differs from a process assess- found and time required to find and fix the defects
ment. Assessments are performed to determine as compared to software testing.
levels of capability or maturity and to identify A typical method of software process assess-
software processes to be improved. Audits are ment includes planning, fact-finding (by collect-
typically conducted to ascertain compliance with ing evidence through questionnaires, interviews,
policies and standards. Audits provide manage- and observation of work practices), collection
ment visibility into the actual operations being and validation of process data, and analysis and
performed in the organization so that accurate reporting. Process assessments may rely on the
and meaningful decisions can be made concern- subjective, qualitative judgment of the assessor,
ing issues that are impacting a development proj- or on the objective presence or absence of defined
ect, a maintenance activity, or a software-related artifacts, records, and other evidence.
topic. The activities performed during a software pro-
Success factors for software process assess- cess assessment and the distribution of effort for
ment and improvement within software engineer- assessment activities are different depending on
ing organizations include management sponsor- the purpose of the software process assessment.
ship, planning, training, experienced and capable Software process assessments may be undertaken
leaders, team commitment, expectation manage- to develop capability ratings used to make recom-
ment, the use of change agents, plus pilot projects mendations for process improvements or may be
and experimentation with tools. Additional fac- undertaken to obtain a process maturity rating in
tors include independence of the assessor and the order to qualify for a contract or award.
timeliness of the assessment. The quality of assessment results depends on
the software process assessment method, the
3.1. Software Process Assessment Models integrity and quality of the obtained data, the
[2*, s4.5, s4.6] [3*, s26.5] [4*, p44–48] assessment team’s capability and objectivity, and
the evidence examined during the assessment.
Software process assessment models typically The goal of a software process assessment is to
include assessment criteria for software processes gain insight that will establish the current status
that are regarded as constituting good practices. of a process or processes and provide a basis for
These practices may address software develop- process improvement; performing a software
ment processes only, or they may also include process assessment by following a checklist for
topics such as software maintenance, software conformance without gaining insight adds little
project management, systems engineering, or value.
human resources management.
3.3. Software Process Improvement Models
3.2. Software Process Assessment Methods [2*, p187–188] [3*, s26.5] [4*, s2.7]
[1*, p322–331] [3*, s26.3]
[4*, p44–48, s16.4] [6] Software process improvement models empha-
size iterative cycles of continuous improvement.
A software process assessment method can be A software process improvement cycle typically
qualitative or quantitative. Qualitative assess- involves the subprocesses of measuring, ana-
ments rely on the judgment of experts; quanti- lyzing, and changing. The Plan-Do-Check-Act
tative assessments assign numerical scores to model is a well-known iterative approach to
software processes based on analysis of objective software process improvement. Improvement
evidence that indicates attainment of the goals activities include identifying and prioritizing
and outcomes of a defined software process. For desired improvements (planning); introducing
example, a quantitative assessment of the soft- an improvement, including change management
ware inspection process might be performed by and training (doing); evaluating the improvement
8-8 SWEBOK® Guide V3.0
as compared to previous or exemplary process visibility into intermediate work products and
results and costs (checking); and making further can exert some control over transitions between
modifications (acting). The Plan-Do-Check-Act processes. At level 3, a single software process or
process improvement model can be applied, for the processes in a maturity level 3 group plus the
example, to improve software processes that process or processes in maturity level 2 are well
enhance defect prevention. defined (perhaps in organizational policies and
procedures) and are being repeated across dif-
3.4. Continuous and Staged Software Process ferent projects. Level 3 of process capability or
Ratings maturity provides the basis for process improve-
[1*, p28–34] [3*, s26.5] [4*, p39–45] ment across an organization because the process
is (or processes are) conducted in a similar man-
Software process capability and software process ner. This allows collection of performance data
maturity are typically rated using five or six levels in a uniform manner across multiple projects. At
to characterize the capability or maturity of the maturity level 4, quantitative measures can be
software processes used within an organization. applied and used for process assessment; statis-
A continuous rating system involves assign- tical analysis may be used. At maturity level 5,
ing a rating to each software process of interest; the mechanisms for continuous process improve-
a staged rating system is established by assign- ments are applied.
ing the same maturity rating to all of the software Continuous and staged representations can be
processes within a specified process level. A rep- used to determine the order in which software
resentation of continuous and staged process lev- processes are to be improved. In the continuous
els is provided in Table 8.1. Continuous models representation, the different capability levels for
typically use a level 0 rating; staged models typi- different software processes provide a guideline
cally do not. for determining the order in which software pro-
cesses will be improved. In the staged representa-
Table 8.1. Software Process Rating Levels tion, satisfying the goals of a set of software pro-
Continuous Staged cesses within a maturity level is accomplished for
Representation Representation that maturity level, which provides a foundation
Level for improving all of the software processes at the
of Capability of Maturity
Levels Levels next higher level.
0 Incomplete
4. Software Measurement
1 Performed Initial [3*, s26.2] [4*, s18.1.1]
2 Managed Managed
3 Defined Defined This topic addresses software process and prod-
uct measurement, quality of measurement results,
Quantitatively
4 software information models, and software pro-
Managed
cess measurement techniques (see Measurement
5 Optimizing in the Engineering Foundations KA).
Before a new process is implemented or a cur-
In Table 8.1, level 0 indicates that a software rent process is modified, measurement results for
process is incompletely performed or may not be the current situation should be obtained to pro-
performed. At level 1, a software process is being vide a baseline for comparison between the cur-
performed (capability rating), or the software rent situation and the new situation. For exam-
processes in a maturity level 1 group are being ple, before introducing the software inspection
performed but on an ad hoc, informal basis. At process, effort required to fix defects discovered
level 2, a software process (capability rating) or by testing should be measured. Following an ini-
the processes in maturity level 2 are being per- tial start-up period after the inspection process
formed in a manner that provides management is introduced, the combined effort of inspection
Software Engineering Process 8-9
plus testing can be compared to the previous design documentation, and other related work
amount of effort required for testing alone. Simi- products.
lar considerations apply if a process is changed. Also note that efficiency and effectiveness are
independent concepts. An effective software pro-
4.1. Software Process and Product Measurement cess can be inefficient in achieving a desired soft-
[1*, s6.3, p273] [3*, s26.2, p638] ware process result; for example, the amount of
effort expended to find and fix software defects
Software process and product measurement are could be very high and result in low efficiency, as
concerned with determining the efficiency and compared to expectations.
effectiveness of a software process, activity, or An efficient process can be ineffective in accom-
task. The efficiency of a software process, activity, plishing the desired transformation of input work
or task is the ratio of resources actually consumed products into output work products; for example,
to resources expected or desired to be consumed failure to find and correct a sufficient number of
in accomplishing a software process, activity, or software defects during the testing process.
task (see Efficiency in the Software Engineering Causes of low efficiency and/or low effective-
Economics KA). Effort (or equivalent cost) is the ness in the way a software process, activity, or
primary measure of resources for most software task is executed might include one or more of the
processes, activities, and tasks; it is measured in following problems: deficient input work prod-
units such as person-hours, person-days, staff- ucts, inexperienced personnel, lack of adequate
weeks, or staff-months of effort or in equivalent tools and infrastructure, learning a new process,
monetary units—such as euros or dollars. a complex product, or an unfamiliar product
Effectiveness is the ratio of actual output to domain. The efficiency and effectiveness of soft-
expected output produced by a software process, ware process execution are also affected (either
activity, or task; for example, actual number of positively or negatively) by factors such as turn-
defects detected and corrected during software over in software personnel, schedule changes, a
testing to expected number of defects to be new customer representative, or a new organiza-
detected and corrected—perhaps based on his- tional policy.
torical data for similar projects (see Effectiveness In software engineering, productivity in per-
in the Software Engineering Economics KA). forming a process, activity, or task is the ratio of
Note that measurement of software process effec- output produced divided by resources consumed;
tiveness requires measurement of the relevant for example, the number of software defects dis-
product attributes; for example, measurement of covered and corrected divided by person-hours of
software defects discovered and corrected during effort (see Productivity in the Software Engineer-
software testing. ing Economics KA). Accurate measurement of
One must take care when measuring product productivity must include total effort used to sat-
attributes for the purpose of determining process isfy the exit criteria of a software process, activ-
effectiveness. For example, the number of defects ity, or task; for example, the effort required to
detected and corrected by testing may not achieve correct defects discovered during software test-
the expected number of defects and thus provide ing must be included in software development
a misleadingly low effectiveness measure, either productivity.
because the software being tested is of better- Calculation of productivity must account for
than-usual quality or perhaps because introduc- the context in which the work is accomplished.
tion of a newly introduced upstream inspection For example, the effort to correct discovered
process has reduced the remaining number of defects will be included in the productivity cal-
defects in the software. culation of a software team if team members
Product measures that may be important in correct the defects they find—as in unit testing
determining the effectiveness of software pro- by software developers or in a cross-functional
cesses include product complexity, total defects, agile team. Or the productivity calculation
defect density, and the quality of requirements, may include either the effort of the software
8-10 SWEBOK® Guide V3.0
2. results computed for a new data set are Process measurement techniques also provide
close to actual outcomes for that data set, the information needed to measure the effects of
in which case minor adjustments are made process improvement initiatives. Process mea-
to the parameters of the model to improve surement techniques can be used to collect both
agreement; quantitative and qualitative data.
3. results computed for the new data set and
subsequent data sets are very close and no 4.4.1. Quantitative Process Measurement
adjustments to the model are needed. Techniques
[4*, s5.1, s5.7, s9.8]
Continuous evaluation of the model may indi-
cate a need for adjustments over time as the con- The purpose of quantitative process measurement
text in which the model is applied changes. techniques is to collect, transform, and analyze
The Goals/Questions/Metrics (GQM) method quantitative process and work product data that
was originally intended for establishing measure- can be used to indicate where process improve-
ment activities, but it can also be used to guide ments are needed and to assess the results of
analysis and improvement of software processes. process improvement initiatives. Quantitative
It can be used to guide analysis-driven software process measurement techniques are used to col-
information model building; results obtained lect and analyze data in numerical form to which
from the software information model can be used mathematical and statistical techniques can be
to guide process improvement. applied.
The following example illustrates application Quantitative process data can be collected as
of the GQM method: a byproduct of software processes. For example,
the number of defects discovered during software
• Goal: Reduce the average change request testing and the staff-hours expended can be col-
processing time by 10% within six months. lected by direct measurement, and the productiv-
• Question 1-1: What is the baseline change ity of defect discovery can be derived by calculat-
request processing time? ing defects discovered per staff-hour.
• Metric 1-1-1: Average of change request Basic tools for quality control can be used to
processing times on starting date analyze quantitative process measurement data
• Metric 1-1-2: Standard deviation of change (e.g., check sheets, Pareto diagrams, histograms,
request processing times on starting date scatter diagrams, run charts, control charts, and
• Question 1-2: What is the current change cause-and-effect diagrams) (see Root Cause
request processing time? Analysis in the Engineering Foundations KA). In
• Metric 1-2-1: Average of change request addition, various statistical techniques can be used
processing times currently that range from calculation of medians and means
• Metric 1-2-2: Standard deviation of change to multivariate analysis methods (see Statistical
request processing times currently Analysis in the Engineering Foundations KA).
Data collected using quantitative process mea-
4.4. Software Process Measurement Techniques surement techniques can also be used as inputs
[1*, c8] to simulation models (see Modeling, Prototyp-
ing, and Simulation in the Engineering Founda-
Software process measurement techniques are tions KA); these models can be used to assess the
used to collect process data and work product impact of various approaches to software process
data, transform the data into useful information, improvement.
and analyze the information to identify process Orthogonal Defect Classification (ODC) can
activities that are candidates for improvement. be used to analyze quantitative process measure-
In some cases, new software processes may be ment data. ODC can be used to group detected
needed. defects into categories and link the defects in
8-12 SWEBOK® Guide V3.0
each category to the software process or soft- addition, general purpose business tools, such as
ware processes where a group of defects origi- a spreadsheet, may be useful.
nated (see Defect Characterization in the Soft- Computer-Assisted Software Engineering
ware Quality KA). Software interface defects, (CASE) tools can reinforce the use of integrated
for example, may have originated during an inad- processes, support the execution of process defi-
equate software design process; improving the nitions, and provide guidance to humans in per-
software design process will reduce the number forming well-defined processes. Simple tools
of software interface defects. ODC can provide such as word processors and spreadsheets can
quantitative data for applying root cause analysis. be used to prepare textual descriptions of pro-
Statistical Process Control can be used to track cesses, activities, and tasks; these tools also sup-
process stability, or the lack of process stability, port traceability among the inputs and outputs of
using control charts. multiple software processes (such as stakeholder
needs analysis, software requirements specifica-
4.4.2. Qualitative Process Measurement tion, software architecture, and software detailed
Techniques design) as well as the results of software pro-
[1*, s6.4] cesses such as documentation, software compo-
nents, test cases, and problem reports.
Qualitative process measurement techniques— Most of the knowledge areas in this Guide
including interviews, questionnaires, and expert describe specialized tools that can be used to
judgment—can be used to augment quantitative manage the processes within that KA. In particu-
process measurement techniques. Group consen- lar, see the Software Configuration Management
sus techniques, including the Delphi technique, KA for a discussion of software configuration
can be used to obtain consensus among groups of management tools that can be used to manage the
stakeholders. construction, integration, and release processes
for software products. Other tools, such as those
5. Software Engineering Process Tools for requirements management and testing, are
[1*, s8.7] described in the appropriate KAs.
Software process tools can support projects
Software process tools support many of the nota- that involve geographically dispersed (virtual)
tions used to define, implement, and manage teams. Increasingly, software process tools are
individual software processes and software life available through cloud computing facilities as
cycle models. They include editors for notations well as through dedicated infrastructures.
such as data-flow diagrams, state charts, BPMN, A project control panel or dashboard can dis-
IDEF0 diagrams, Petri nets, and UML activity play selected process and product attributes for
diagrams. In some cases, software process tools software projects and indicate measurements that
allow different types of analyses and simula- are within control limits and those needing cor-
tions (for example, discrete event simulation). In rective action.
Software Engineering Process 8-13
Sommerville 2011
Fairley 2009
Moore 2009
Kan 2003
[3*]
[2*]
[4*]
[1*]
p28–29,
1. Software Process Definition p177 p295 p36,
c5
1.1. Software Process Management s26.1 p453–454
p183, p186
1.2. Software Process Infrastructure p437–438
Software Extension to the Guide to the Project [1*] R.E. Fairley, Managing and Leading
Management Body of Knowledge® (SWX) Software Projects, Wiley-IEEE Computer
[5]. Society Press, 2009.
SWX provides adaptations and extensions to the [2*] J.W. Moore, The Road Map to Software
generic practices of project management docu- Engineering: A Standards-Based Guide,
mented in the PMBOK® Guide for managing Wiley-IEEE Computer Society Press, 2006.
software projects. The primary contribution of
this extension to the PMBOK® Guide is descrip- [3*] I. Sommerville, Software Engineering, 9th
tion of processes that are applicable for managing ed., Addison-Wesley, 2011.
adaptive life cycle software projects.
[4*] S.H. Kan, Metrics and Models in Software
D. Gibson, D. Goldenson, and K. Kost, Quality Engineering, 2nd ed., Addison-
“Performance Results of CMMI-Based Wesley, 2002.
Process Improvement” [6].
[5] Project Management Institute and IEEE
This technical report summarizes publicly avail- Computer Society, Software Extension
able empirical evidence about the performance to the PMBOK® Guide Fifth Edition, ed:
results that can occur as a consequence of CMMI- Project Management Institute, 2013.
based process improvement. The report contains
a series of brief case descriptions that were cre- [6] D. Gibson, D. Goldenson, and K. Kost,
ated with collaboration from representatives “Performance Results of CMMI-Based
from 10 organizations that have achieved notable Process Improvement,” Software
quantitative performance results through their Engineering Institute, 2006; http://
CMMI-based improvement efforts. resources.sei.cmu.edu/library/asset-view.
cfm?assetID=8065.
CMMI® for Development, Version 1.3 [7].
[7] CMMI Product Team, “CMMI for
CMMI® for Development, Version 1.3 provides an Development, Version 1.3,” Software
integrated set of process guidelines for develop- Engineering Institute, 2010; http://
ing and improving products and services. These resources.sei.cmu.edu/library/asset-view.
guidelines include best practices for developing cfm?assetID=9661.
and improving products and services to meet the
needs of customers and end users. [8] ISO/IEC 15504-1:2004, Information
Technology—Process Assessment—Part 1:
ISO/IEC 15504-1:2004 Information tech- Concepts and Vocabulary, ISO/IEC, 2004.
nology—Process assessment—Part 1:
Concepts and vocabulary [8].
9-1
9-2 SWEBOK® Guide V3.0
Figure 9.1. Breakdown of Topics for the Software Engineering Models and Methods KA
engineer, and communicate aspects of the soft- significant decisions to others in the stakeholder
ware to appropriate stakeholders. Stakeholders communities. There are three general principles
are those persons or parties who have a stated guiding such modeling activities:
or implied interest in the software (for example,
user, buyer, supplier, architect, certifying author- • Model the Essentials: good models do not
ity, evaluator, developer, software engineer, and usually represent every aspect or feature of
perhaps others). the software under every possible condition.
While there are many modeling languages, Modeling typically involves developing only
notations, techniques, and tools in the literature those aspects or features of the software that
and in practice, there are unifying general con- need specific answers, abstracting away any
cepts that apply in some form to them all. The nonessential information. This approach
following sections provide background on these keeps the models manageable and useful.
general concepts. • Provide Perspective: modeling provides
views of the software under study using
1.1. Modeling Principles a defined set of rules for expression of the
[1*, c2s2, c5s1, c5s2] [2*, c2s2] [3*, c5s0] model within each view. This perspective-
driven approach provides dimensionality to
Modeling provides the software engineer with the model (for example, a structural view,
an organized and systematic approach for repre- behavioral view, temporal view, organiza-
senting significant aspects of the software under tional view, and other views as relevant).
study, facilitating decision-making about the soft- Organizing information into views focuses
ware or elements of it, and communicating those the software modeling efforts on specific
Software Engineering Models and Methods 9-3
concerns relevant to that view using the Models are constructed to represent real-world
appropriate notation, vocabulary, methods, objects and their behaviors to answer specific
and tools. questions about how the software is expected
• Enable Effective Communications: modeling to operate. Interrogating the models—either
employs the application domain vocabulary through exploration, simulation, or review—may
of the software, a modeling language, and expose areas of uncertainty within the model and
semantic expression (in other words, mean- the software to which the model refers. These
ing within context). When used rigorously uncertainties or unanswered questions regarding
and systematically, this modeling results in the requirements, design, and/or implementation
a reporting approach that facilitates effective can then be handled appropriately.
communication of software information to The primary expression element of a model is
project stakeholders. an entity. An entity may represent concrete arti-
facts (for example, processors, sensors, or robots)
A model is an abstraction or simplification of or abstract artifacts (for example, software mod-
a software component. A consequence of using ules or communication protocols). Model enti-
abstraction is that no single abstraction com- ties are connected to other entities using rela-
pletely describes a software component. Rather, tions (in other words, lines or textual operators
the model of the software is represented as an on target entities). Expression of model entities
aggregation of abstractions, which—when taken may be accomplished using textual or graphical
together—describe only selected aspects, per- modeling languages; both modeling language
spectives, or views—only those that are needed types connect model entities through specific lan-
to make informed decisions and respond to the guage constructs. The meaning of an entity may
reasons for creating the model in the first place. be represented by its shape, textual attributes, or
This simplification leads to a set of assumptions both. Generally, textual information adheres to
about the context within which the model is language-specific syntactic structure. The pre-
placed that should also be captured in the model. cise meanings related to the modeling of context,
Then, when reusing the model, these assumptions structure, or behavior using these entities and
can be validated first to establish the relevancy of relations is dependent on the modeling language
the reused model within its new use and context. used, the design rigor applied to the modeling
effort, the specific view being constructed, and
1.2. Properties and Expression of Models the entity to which the specific notation element
[1*, c5s2, c5s3] [3*, c4s1.1p7, c4s6p3, may be attached. Multiple views of the model
c5s0p3] may be required to capture the needed semantics
of the software.
Properties of models are those distinguishing fea- When using models supported with automa-
tures of a particular model used to characterize tion, models may be checked for completeness
its completeness, consistency, and correctness and consistency. The usefulness of these checks
within the chosen modeling notation and tooling depends greatly on the level of semantic and syn-
used. Properties of models include the following: tactic rigor applied to the modeling effort in addi-
tion to explicit tool support. Correctness is typi-
• Completeness: the degree to which all cally checked through simulation and/or review.
requirements have been implemented and
verified within the model. 1.3. Syntax, Semantics, and Pragmatics
• Consistency: the degree to which the model [2* c2s2.2.2p6] [3*, c5s0]
contains no conflicting requirements, asser-
tions, constraints, functions, or component Models can be surprisingly deceptive. The fact
descriptions. that a model is an abstraction with missing infor-
• Correctness: the degree to which the model mation can lead one into a false sense of com-
satisfies its requirements and design specifi- pletely understanding the software from a single
cations and is free of defects. model. A complete model (“complete” being
9-4 SWEBOK® Guide V3.0
relative to the modeling effort) may be a union can be introduced, leading to errors. With many
of multiple submodels and any special function software engineers working on a model part over
models. Examination and decision-making rela- time coupled with tool updates and perhaps new
tive to a single model within this collection of requirements, there are opportunities for portions
submodels may be problematic. of the model to represent something different
Understanding the precise meanings of mod- from the original author’s intent and initial model
eling constructs can also be difficult. Modeling context.
languages are defined by syntactic and semantic
rules. For textual languages, syntax is defined 1.4. Preconditions, Postconditions, and
using a notation grammar that defines valid lan- Invariants
guage constructs (for example, Backus-Naur [2*, c4s4] [4*, c10s4p2, c10s5p2p4]
Form (BNF)). For graphical languages, syntax is
defined using graphical models called metamod- When modeling functions or methods, the soft-
els. As with BNF, metamodels define the valid ware engineer typically starts with a set of
syntactical constructs of a graphical modeling assumptions about the state of the software prior
language; the metamodel defines how these con- to, during, and after the function or method exe-
structs can be composed to produce valid models. cutes. These assumptions are essential to the cor-
Semantics for modeling languages specify the rect operation of the function or method and are
meaning attached to the entities and relations grouped, for discussion, as a set of preconditions,
captured within the model. For example, a simple postconditions, and invariants.
diagram of two boxes connected by a line is open
to a variety of interpretations. Knowing that the • Preconditions: a set of conditions that must
diagram on which the boxes are placed and con- be satisfied prior to execution of the function
nected is an object diagram or an activity diagram or method. If these preconditions do not hold
can assist in the interpretation of this model. prior to execution of the function or method,
As a practical matter, there is usually a good the function or method may produce errone-
understanding of the semantics of a specific ous results.
software model due to the modeling language • Postconditions: a set of conditions that is
selected, how that modeling language is used to guaranteed to be true after the function or
express entities and relations within that model, method has executed successfully. Typically,
the experience base of the modeler(s), and the the postconditions represent how the state
context within which the modeling has been of the software has changed, how param-
undertaken and so represented. Meaning is com- eters passed to the function or method have
municated through the model even in the presence changed, how data values have changed, or
of incomplete information through abstraction; how the return value has been affected.
pragmatics explains how meaning is embodied • Invariants: a set of conditions within the
in the model and its context and communicated operational environment that persist (in
effectively to other software engineers. other words, do not change) before and after
There are still instances, however, where cau- execution of the function or method. These
tion is needed regarding modeling and semantics. invariants are relevant and necessary to the
For example, any model parts imported from software and the correct operation of the
another model or library must be examined for function or method.
semantic assumptions that conflict in the new
modeling environment; this may not be obvious. 2. Types of Models
The model should be checked for documented
assumptions. While modeling syntax may be A typical model consists of an aggregation of
identical, the model may mean something quite submodels. Each submodel is a partial descrip-
different in the new environment, which is a dif- tion and is created for a specific purpose; it may
ferent context. Also, consider that as software be comprised of one or more diagrams. The
matures and changes are made, semantic discord collection of submodels may employ multiple
Software Engineering Models and Methods 9-5
and warnings generated by these analysis tools and and pseudo-code, handwritten and tool-generated
found by inspection or review indicate probable code, manual and automated test cases and reports,
needed corrective actions to ensure completeness and files and data. These work products may be
of the models. related through various dependency relationships
(for example, uses, implements, and tests). As soft-
3.2. Analyzing for Consistency ware is being developed, managed, maintained, or
[3*, c4s1.1p7, c4s6] [5*, p8–11] extended, there is a need to map and control these
traceability relationships to demonstrate soft-
Consistency is the degree to which models con- ware requirements consistency with the software
tain no conflicting requirements, assertions, con- model (see Requirements Tracing in the Software
straints, functions, or component descriptions. Requirements KA) and the many work products.
Typically, consistency checking is accomplished Use of traceability typically improves the manage-
with the modeling tool using an automated analysis ment of software work products and software pro-
function; models may also be checked for consis- cess quality; it also provides assurances to stake-
tency manually using inspections or other review holders that all requirements have been satisfied.
techniques (see the Software Quality KA). As Traceability enables change analysis once the soft-
with completeness, errors and warnings generated ware is developed and released, since relationships
by these analysis tools and found by inspection or to software work products can easily be traversed
review indicate the need for corrective action. to assess change impact. Modeling tools typically
provide some automated or manual means to spec-
3.3. Analyzing for Correctness ify and manage traceability links between require-
[5*, p8–11] ments, design, code, and/or test entities as may be
represented in the models and other software work
Correctness is the degree to which a model sat- products. (For more information on traceability,
isfies its software requirements and software see the Software Configuration Management KA).
design specifications, is free of defects, and ulti-
mately meets the stakeholders’ needs. Analyzing 3.5. Interaction Analysis
for correctness includes verifying syntactic cor- [2*, c10, c11] [3*, c29s1.1, c29s5] [4*, c5]
rectness of the model (that is, correct use of the
modeling language grammar and constructs) and Interaction analysis focuses on the communica-
verifying semantic correctness of the model (that tions or control flow relations between entities
is, use of the modeling language constructs to used to accomplish a specific task or function
correctly represent the meaning of that which is within the software model. This analysis exam-
being modeled). To analyze a model for syntactic ines the dynamic behavior of the interactions
and semantic correctness, one analyzes it—either between different portions of the software model,
automatically (for example, using the modeling including other software layers (such as the oper-
tool to check for model syntactic correctness) ating system, middleware, and applications). It
or manually (using inspections or other review may also be important for some software applica-
techniques)—searching for possible defects and tions to examine interactions between the com-
then removing or repairing the confirmed defects puter software application and the user interface
before the software is released for use. software. Some software modeling environments
provide simulation facilities to study aspects of
3.4. Traceability the dynamic behavior of modeled software. Step-
[3*, c4s7.1, c4s7.2] ping through the simulation provides an analysis
option for the software engineer to review the
Developing software typically involves the use, interaction design and verify that the different
creation, and modification of many work products parts of the software work together to provide the
such as planning documents, process specifica- intended functions.
tions, software requirements, diagrams, designs
Software Engineering Models and Methods 9-7
a target set of requirements (for example, a • Scrum: This agile approach is more project
requirements prototype); the prototype may management-friendly than the others. The
also serve as a model for a future software scrum master manages the activities within
development effort (for example, as in a user the project increment; each increment is
interface specification). called a sprint and lasts no more than 30
days. A Product Backlog Item (PBI) list is
4.4. Agile Methods developed from which tasks are identified,
[3*, c3] [6*, c7s3p7] [7*, c6, App. A] defined, prioritized, and estimated. A work-
ing version of the software is tested and
Agile methods were born in the 1990s from the released in each increment. Daily scrum
need to reduce the apparent large overhead associ- meetings ensure work is managed to plan.
ated with heavyweight, plan-based methods used • FDD: This is a model-driven, short, itera-
in large-scale software-development projects. tive software development approach using
Agile methods are considered lightweight meth- a five-phase process: (1) develop a product
ods in that they are characterized by short, itera- model to scope the breadth of the domain, (2)
tive development cycles, self-organizing teams, create the list of needs or features, (3) build
simpler designs, code refactoring, test-driven the feature development plan, (4) develop
development, frequent customer involvement, and designs for iteration-specific features, and
an emphasis on creating a demonstrable working (5) code, test, and then integrate the features.
product with each development cycle. FDD is similar to an incremental software
Many agile methods are available in the lit- development approach; it is also similar to
erature; some of the more popular approaches, XP, except that code ownership is assigned
which are discussed here in brief, include Rapid to individuals rather than the team. FDD
Application Development (RAD), eXtreme Pro- emphasizes an overall architectural approach
gramming (XP), Scrum, and Feature-Driven to the software, which promotes building the
Development (FDD). feature correctly the first time rather than
emphasizing continual refactoring.
• RAD: Rapid software development methods
are used primarily in data-intensive, business- There are many more variations of agile meth-
systems application development. The RAD ods in the literature and in practice. Note that
method is enabled with special-purpose data- there will always be a place for heavyweight,
base development tools used by software plan-based software engineering methods as well
engineers to quickly develop, test, and deploy as places where agile methods shine. There are
new or modified business applications. new methods arising from combinations of agile
• XP: This approach uses stories or scenarios and plan-based methods where practitioners are
for requirements, develops tests first, has defining new methods that balance the features
direct customer involvement on the team needed in both heavyweight and lightweight
(typically defining acceptance tests), uses methods based primarily on prevailing organi-
pair programming, and provides for continu- zational business needs. These business needs,
ous code refactoring and integration. Stories as typically represented by some of the project
are decomposed into tasks, prioritized, esti- stakeholders, should and do drive the choice in
mated, developed, and tested. Each incre- using one software engineering method over
ment of software is tested with automated another or in constructing a new method from the
and manual tests; an increment may be best features of a combination of software engi-
released frequently, such as every couple of neering methods.
weeks or so.
9-10 SWEBOK® Guide V3.0
Sommerville 2011
Brookshear 2008
Page-Jones 1999
Budgen 2003
Wing 1990
[7*]
[5*]
[3*]
[2*]
[4*]
[6*]
[1*]
1. Modeling
c2s2,
1.1. Modeling
c5s1, c2s2 c5s0
Principles
c5s2
1.2. Properties c4s1.1p7,
c5s2,
and Expression of c4s6p3,
c5s3
Models c5s0p3
1.3. Syntax,
c2s2.2.2
Semantics, and c5s0
p6
Pragmatics
1.4. Preconditions, c10s4p2,
Postconditions, and c4s4 c10s5
Invariants p2p4
2. Types of Models
2.1. Information
c7s2.2 c8s1
Modeling
c7s2.1,
2.2. Behavioral
c7s2.3, c9s2 c5s4
Modeling
c7s2.4
c7s2.5,
2.3. Structure
c7s3.1, c5s3 c4
Modeling
c7s3.2
3. Analysis of Models
3.1. Analyzing for c4s1.1p7,
pp8–11
Completeness c4s6
3.2. Analyzing for c4s1.1p7,
pp8–11
Consistency c4s6
3.3. Analyzing for
pp8–11
Correctness
c4s7.1,
3.4. Traceability
c4s7.2
3.5. Interaction c29s1.1,
c10, c11 c5
Analysis c29s5
Software Engineering Models and Methods 9-11
Sommerville 2011
Brookshear 2008
Page-Jones 1999
Budgen 2003
Wing 1990
[7*]
[5*]
[3*]
[2*]
[4*]
[6*]
[1*]
4. Software
Engineering Methods
c2s2.2,
4.1. Heuristic c13, c15,
c7s1,
Methods c16
c5s4.1
4.2. Formal Methods c18 c27 pp8–24
4.3. Prototyping
c12s2 c2s3.1 c7s3p5
Methods
c6, app.
4.4. Agile Methods c3 c7s3p7
A
9-12 SWEBOK® Guide V3.0
REFERENCES
[1*] D. Budgen, Software Design, 2nd ed., [5*] J.M. Wing, “A Specifier’s Introduction to
Addison-Wesley, 2003. Formal Methods,” Computer, vol. 23, no. 9,
1990, pp. 8, 10–23.
[2*] S.J. Mellor and M.J. Balcer, Executable
UML: A Foundation for Model-Driven [6*] J.G. Brookshear, Computer Science: An
Architecture, 1st ed., Addison-Wesley, Overview, 10th ed., Addison-Wesley, 2008.
2002.
[7*] B. Boehm and R. Turner, Balancing Agility
[3*] I. Sommerville, Software Engineering, 9th and Discipline: A Guide for the Perplexed,
ed., Addison-Wesley, 2011. Addison-Wesley, 2003.
SOFTWARE QUALITY
10-1
10-2 SWEBOK® Guide V3.0
use.” Stakeholder value is expressed in require- the many aspects of quality be formally defined
ments. For software products, stakeholders could and discussed.
value price (what they pay for the product), lead A software engineer should understand qual-
time (how fast they get the product), and software ity concepts, characteristics, values, and their
quality. application to the software under development or
This KA addresses definitions and provides an maintenance. The important concept is that the
overview of practices, tools, and techniques for software requirements define the required quality
defining software quality and for appraising the attributes of the software. Software requirements
state of software quality during development, influence the measurement methods and accep-
maintenance, and deployment. Cited references tance criteria for assessing the degree to which
provide additional details. the software and related documentation achieve
the desired quality levels.
BREAKDOWN OF TOPICS FOR
SOFTWARE QUALITY 1.1. Software Engineering Culture and Ethics
[3*, c1s4] [6*, c2s3.5]
The breakdown of topics for the Software Quality
KA is presented in Figure 10.1. Software engineers are expected to share a com-
mitment to software quality as part of their culture.
1. Software Quality Fundamentals A healthy software engineering culture includes
many characteristics, including the understanding
Reaching agreement on what constitutes quality that tradeoffs among cost, schedule, and quality
for all stakeholders and clearly communicating are a basic tenant of the engineering of any prod-
that agreement to software engineers require that uct. A strong software engineering ethic assumes
Software Quality 10-3
that engineers accurately report information, con- software product to the customer. External fail-
ditions, and outcomes related to quality. ure costs include activities to respond to software
Ethics also play a significant role in software problems discovered after delivery to the customer.
quality, the culture, and the attitudes of software Software engineers should be able to use CoSQ
engineers. The IEEE Computer Society and the methods to ascertain levels of software quality
ACM have developed a code of ethics and pro- and should also be able to present quality alter-
fessional practice (see Codes of Ethics and Pro- natives and their costs so that tradeoffs between
fessional Conduct in the Software Engineering cost, schedule, and delivery of stakeholder value
Professional Practice KA). can be made.
Defining and then achieving software quality is Terminology for software quality characteristics
not simple. Quality characteristics may or may differs from one taxonomy (or model of software
not be required, or they may be required to a quality) to another, each model perhaps having
greater or lesser degree, and tradeoffs may be a different number of hierarchical levels and a
made among them. To help determine the level different total number of characteristics. Various
of software quality, i.e., achieving stakeholder authors have produced models of software qual-
value, this section presents cost of software qual- ity characteristics or attributes that can be useful
ity (CoSQ): a set of measurements derived from for discussing, planning, and rating the quality
the economic assessment of software quality of software products. ISO/IEC 25010: 2011 [4]
development and maintenance processes. The defines product quality and quality in use as two
CoSQ measurements are examples of process related quality models. Appendix B in the SWE-
measurements that may be used to infer charac- BOK Guide provides a list of applicable standards
teristics of a product. for each KA. Standards for this KA cover various
The premise underlying the CoSQ is that the ways of characterizing software quality.
level of quality in a software product can be
inferred from the cost of activities related to deal- 1.3.1. Software Process Quality
ing with the consequences of poor quality. Poor
quality means that the software product does not Software quality management and software engi-
fully “satisfy stated and implied needs” or “estab- neering process quality have a direct bearing on
lished requirements.” There are four cost of qual- the quality of the software product.
ity categories: prevention, appraisal, internal fail- Models and criteria that evaluate the capabili-
ure, and external failure. ties of software organizations are primarily proj-
Prevention costs include investments in software ect organization and management considerations
process improvement efforts, quality infrastruc- and, as such, are covered in the Software Engi-
ture, quality tools, training, audits, and manage- neering Management and Software Engineering
ment reviews. These costs are usually not specific Process KAs.
to a project; they span the organization. Appraisal It is not possible to completely distinguish pro-
costs arise from project activities that find defects. cess quality from product quality because process
These appraisal activities can be categorized into outcomes include products. Determining whether
costs of reviews (design, peer) and costs of test- a process has the capability to consistently pro-
ing (software unit testing, software integration, duce products of desired quality is not simple.
system level testing, acceptance testing); appraisal The software engineering process, discussed
costs would be extended to subcontracted software in the Software Engineering Process KA, influ-
suppliers. Costs of internal failures are those that ences the quality characteristics of software prod-
are incurred to fix defects found during appraisal ucts, which in turn affect quality as perceived by
activities and discovered prior to delivery of the stakeholders.
10-4 SWEBOK® Guide V3.0
1.3.2. Software Product Quality in quality who have stated that the quality of a
product is directly linked to the quality of the
The software engineer, first of all, must determine process used to create it. Approaches such as the
the real purpose of the software. In this regard, Deming improvement cycle of Plan-Do-Check-
stakeholder requirements are paramount, and they Act (PDCA), evolutionary delivery, kaizen, and
include quality requirements in addition to func- quality function deployment (QFD) offer tech-
tional requirements. Thus, software engineers niques to specify quality objectives and determine
have a responsibility to elicit quality requirements whether they are met. The Software Engineering
that may not be explicit at the outset and to under- Institute’s IDEAL is another method [7*]. Qual-
stand their importance as well as the level of diffi- ity management is now recognized by the SWE-
culty in attaining them. All software development BOK Guide as an important discipline.
processes (e.g., eliciting requirements, designing, Management sponsorship supports process and
constructing, building, checking, improving qual- product evaluations and the resulting findings.
ity) are designed with these quality requirements Then an improvement program is developed
in mind and may carry additional development identifying detailed actions and improvement
costs if attributes such as safety, security, and projects to be addressed in a feasible time frame.
dependability are important. The additional devel- Management support implies that each improve-
opment costs help ensure that quality obtained can ment project has enough resources to achieve the
be traded off against the anticipated benefits. goal defined for it. Management sponsorship is
The term work-product means any artifact that solicited frequently by implementing proactive
is the outcome of a process used to create the communication activities.
final software product. Examples of a work-prod-
uct include a system/subsystem specification, a 1.5. Software Safety
software requirements specification for a soft- [9*, c11s3]
ware component of a system, a software design
description, source code, software test documen- Safety-critical systems are those in which a sys-
tation, or reports. While some treatments of qual- tem failure could harm human life, other living
ity are described in terms of final software and things, physical structures, or the environment.
system performance, sound engineering practice The software in these systems is safety-critical.
requires that intermediate work-products relevant There are increasing numbers of applications
to quality be evaluated throughout the software of safety-critical software in a growing number
engineering process. of industries. Examples of systems with safety-
critical software include mass transit systems,
1.4. Software Quality Improvement chemical manufacturing plants, and medical
[3*, c1s4] [9*, c24] [10*, c11s2.4] devices. The failure of software in these systems
could have catastrophic effects. There are indus-
The quality of software products can be improved try standards, such as DO-178C [11], and emerg-
through preventative processes or an itera- ing processes, tools, and techniques for develop-
tive process of continual improvement, which ing safetycritical software. The intent of these
requires management control, coordination, and standards, tools, and techniques is to reduce the
feedback from many concurrent processes: (1) risk of injecting faults into the software and thus
the software life cycle processes, (2) the process improve software reliability.
of fault/defect detection, removal, and preven- Safety-critical software can be categorized as
tion, and (3) the quality improvement process. direct or indirect. Direct is that software embed-
The theory and concepts behind qual- ded in a safety-critical system, such as the flight
ity improvement—such as building in quality control computer of an aircraft. Indirect includes
through the prevention and early detection of software applications used to develop safety-
defects, continual improvement, and stakeholder critical software. Indirect software is included in
focus—are pertinent to software engineering. software engineering environments and software
These concepts are based on the work of experts test environments.
Software Quality 10-5
Three complementary techniques for reduc- comply with standards established for the project
ing the risk of failure are avoidance, detection (including requirements, constraints, designs,
and removal, and damage limitation. These contracts, and plans). SQC evaluates intermedi-
techniques impact software functional require- ate products as well as the final products.
ments, software performance requirements, and The fourth SQM category dealing with improve-
development processes. Increasing levels of risk ment has various names within the software indus-
imply increasing levels of software quality assur- try, including SPI, software quality improvement,
ance and control techniques such as inspections. and software corrective and preventive action. The
Higher risk levels may necessitate more thorough activities in this category seek to improve process
inspections of requirements, design, and code effectiveness, efficiency, and other characteris-
or the use of more formal analytical techniques. tics with the ultimate goal of improving software
Another technique for managing and control- quality. Although SPI could be included in any of
ling software risk is building assurance cases. An the first three categories, an increasing number
assurance case is a reasoned, auditable artifact of organizations organize SPI into a separate cat-
created to support the contention that its claim egory that may span across many projects (see the
or claims are satisfied. It contains the following Software Engineering Process KA).
and their relationships: one or more claims about Software quality processes consist of tasks
properties; arguments that logically link the evi- and techniques to indicate how software plans
dence and any assumptions to the claims; and a (e.g., software management, development, qual-
body of evidence and assumptions supporting ity management, or configuration management
these arguments [12]. plans) are being implemented and how well the
intermediate and final products are meeting their
2. Software Quality Management Processes specified requirements. Results from these tasks
are assembled in reports for management before
Software quality management is the collection of corrective action is taken. The management of
all processes that ensure that software products, an SQM process is tasked with ensuring that the
services, and life cycle process implementations results of these reports are accurate.
meet organizational software quality objectives Risk management can also play an important
and achieve stakeholder satisfaction [13, 14]. role in delivering quality software. Incorporating
SQM defines processes, process owners, require- disciplined risk analysis and management tech-
ments for the processes, measurements of the niques into the software life cycle processes can
processes and their outputs, and feedback chan- help improve product quality (see the Software
nels throughout the whole software life cycle. Engineering Management KA for related mate-
SQM comprises four subcategories: software rial on risk management).
quality planning, software quality assurance
(SQA), software quality control (SQC), and soft- 2.1. Software Quality Assurance
ware process improvement (SPI). Software qual- [7*, c4–c6, c11, c12, c26–27]
ity planning includes determining which quality
standards are to be used, defining specific quality To quell a widespread misunderstanding, soft-
goals, and estimating the effort and schedule of ware quality assurance is not testing. software
software quality activities. In some cases, soft- quality assurance (SQA) is a set of activities that
ware quality planning also includes defining the define and assess the adequacy of software pro-
software quality processes to be used. SQA activ- cesses to provide evidence that establishes confi-
ities define and assess the adequacy of software dence that the software processes are appropriate
processes to provide evidence that establishes and produce software products of suitable qual-
confidence that the software processes are appro- ity for their intended purposes. A key attribute of
priate for and produce software products of suit- SQA is the objectivity of the SQA function with
able quality for their intended purposes [5]. SQC respect to the project. The SQA function may
activities examine specific project artifacts (docu- also be organizationally independent of the proj-
ments and executables) to determine whether they ect; that is, free from technical, managerial, and
10-6 SWEBOK® Guide V3.0
financial pressures from the project [5]. SQA has life cycle. This assessment demonstrates
two aspects: product assurance and process assur- whether the requirements are correct, com-
ance, which are explained in section 2.3. plete, accurate, consistent, and testable.
The software quality plan (in some industry The V&V processes determine whether
sectors it is termed the software quality assurance the development products of a given activ-
plan) defines the activities and tasks employed ity conform to the requirements of that
to ensure that software developed for a specific activity and whether the product satisfies
product satisfies the project’s established require- its intended use and user needs.
ments and user needs within project cost and
schedule constraints and is commensurate with Verification is an attempt to ensure that the
project risks. The SQAP first ensures that quality product is built correctly, in the sense that the
targets are clearly defined and understood. output products of an activity meet the specifi-
The SQA plan’s quality activities and tasks are cations imposed on them in previous activities.
specified with their costs, resource requirements, Validation is an attempt to ensure that the right
objectives, and schedule in relation to related product is built—that is, the product fulfills its
objectives in the software engineering manage- specific intended purpose. Both the verification
ment, software development, and software main- process and the validation process begin early
tenance plans. The SQA plan should be consis- in the development or maintenance phase. They
tent with the software configuration management provide an examination of key product features
plan (see the Software Configuration Manage- in relation to both the product’s immediate prede-
ment KA). The SQA plan identifies documents, cessor and the specifications to be met.
standards, practices, and conventions governing The purpose of planning V&V is to ensure that
the project and how these items are checked and each resource, role, and responsibility is clearly
monitored to ensure adequacy and compliance. assigned. The resulting V&V plan documents
The SQA plan also identifies measures; statistical describe the various resources and their roles and
techniques; procedures for problem reporting and activities, as well as the techniques and tools to be
corrective action; resources such as tools, tech- used. An understanding of the different purposes of
niques, and methodologies; security for physical each V&V activity helps in the careful planning of
media; training; and SQA reporting and docu- the techniques and resources needed to fulfill their
mentation. Moreover, the SQA plan addresses purposes. The plan also addresses the manage-
the software quality assurance activities of any ment, communication, policies, and procedures of
other type of activity described in the software the V&V activities and their interaction, as well as
plans—such as procurement of supplier software defect reporting and documentation requirements.
for the project, commercial off-the-shelf software
(COTS) installation, and service after delivery of 2.3. Reviews and Audits
the software. It can also contain acceptance crite- [9*, c24s3] [16*]
ria as well as reporting and management activi-
ties that are critical to software quality. Reviews and audit processes are broadly defined
as static—meaning that no software programs or
2.2. Verification & Validation models are executed—examination of software
[9*, c2s2.3, c8, c15s1.1, c21s3.3] engineering artifacts with respect to standards that
have been established by the organization or proj-
As stated in [15], ect for those artifacts. Different types of reviews
and audits are distinguished by their purpose, lev-
The purpose of V&V is to help the devel- els of independence, tools and techniques, roles,
opment organization build quality into the and by the subject of the activity. Product assur-
system during the life cycle. V&V pro- ance and process assurance audits are typically
cesses provide an objective assessment conducted by software quality assurance (SQA)
of products and processes throughout the personnel who are independent of development
Software Quality 10-7
Inputs to management reviews may include The team follows the documented review pro-
audit reports, progress reports, V&V reports, and cedure. The technical review is completed once
plans of many types, including risk management, all the activities listed in the examination have
project management, software configuration been completed.
management, software safety, and risk assess- Technical reviews of source code may include a
ment, among others. (Refer to the Software Engi- wide variety of concerns such as analysis of algo-
neering Management and the Software Configu- rithms, utilization of critical computer resources,
ration Management KAs for related material.) adherence to coding standards, structure and
10-8 SWEBOK® Guide V3.0
organization of code for testability, and safety- small section of the product at a time (samples).
critical considerations. Each team member examines the software prod-
Note that technical reviews of source code or uct and other review inputs prior to the review
design models such as UML are also termed static meeting, perhaps by applying an analytical tech-
analysis (see topic 3, Practical Considerations). nique (see section 3.3.3) to a small section of
the product or to the entire product with a focus
2.3.3. Inspections on only one aspect—e.g., interfaces. During the
inspection, the moderator conducts the session
“The purpose of an inspection is to detect and and verifies that everyone has prepared for the
identify software product anomalies” [16*]. inspection and conducts the session. The inspec-
Some important differentiators of inspections as tion recorder documents anomalies found. A set
compared to other types of technical reviews are of rules, with criteria and questions germane to
these: the issues of interest, is a common tool used in
inspections. The resulting list often classifies the
1. Rules. Inspections are based upon examining anomalies (see section 3.2, Defect Characteriza-
a work-product with respect to a defined set tion) and is reviewed for completeness and accu-
of criteria specified by the organization. Sets racy by the team. The inspection exit decision
of rules can be defined for different types of corresponds to one of the following options:
workproducts (e.g., rules for requirements,
architecture descriptions, source code). 1. Accept with no or, at most, minor reworking
2. Sampling. Rather that attempt to examine 2. Accept with rework verification
every word and figure in a document, the 3. Reinspect.
inspection process allows checkers to evalu-
ate defined subsets (samples) of the docu- 2.3.4. Walkthroughs
ments under review.
3. Peer. Individuals holding management posi- As stated in [16*],
tions over members of the inspection team
do not participate in the inspection. This is The purpose of a systematic walk-through
a key distinction between peer review and is to evaluate a software product. A walk-
management review. through may be conducted for the purpose
4. Led. An impartial moderator who is trained of educating an audience regarding a soft-
in inspection techniques leads inspection ware product.
meetings.
5. Meeting. The inspection process includes Walkthroughs are distinguished from inspec-
meetings (face to face or electronic) con- tions. The main difference is that the author pres-
ducted by a moderator according to a formal ents the work-product to the other participants in
procedure in which inspection team mem- a meeting (face to face or electronic). Unlike an
bers report the anomalies they have found inspection, the meeting participants may not have
and other issues. necessarily seen the material prior to the meet-
ing. The meetings may be conducted less for-
Software inspections always involve the author mally. The author takes the role of explaining and
of an intermediate or final product; other reviews showing the material to participants and solicits
might not. Inspections also include an inspection feedback. Like inspections, walkthroughs may be
leader, a recorder, a reader, and a few (two to five) conducted on any type of work-product including
checkers (inspectors). The members of an inspec- project plan, requirements, design, source code,
tion team may possess different expertise, such as and test reports.
domain expertise, software design method exper-
tise, or programming language expertise. Inspec-
tions are usually conducted on one relatively
Software Quality 10-9
2.3.5. Process Assurance and Product Assur- • the specific software engineering standards
ance Audits applicable
• the methods and software tools to be used for
As stated in [16*], development and maintenance and for qual-
ity evaluation and improvement
The purpose of a software audit is to pro- • the budget, staff, project organization, plans,
vide an independent evaluation of the con- and scheduling of all processes
formance of software products and pro- • the intended users and use of the system
cesses to applicable regulations, standards, • the integrity level of the system.
guidelines, plans, and procedures.
Information on these factors influences how
Process assurance audits determine the adequacy the SQM processes are organized and docu-
of plans, schedules, and requirements to achieve mented, how specific SQM activities are selected,
project objectives [5]. The audit is a formally what resources are needed, and which of those
organized activity with participants having spe- resources impose bounds on the efforts.
cific roles—such as lead auditor, another auditor, a
recorder, or an initiator—and including a represen- 3.1.2. Dependability
tative of the audited organization. Audits identify
instances of nonconformance and produce a report In cases where system failure may have extremely
requiring the team to take corrective action. severe consequences, overall dependability (hard-
While there may be many formal names for ware, software, and human or operational) is the
reviews and audits, such as those identified in the main quality requirement over and above basic
standard [16*], the important point is that they functionality. This is the case for the following
can occur on almost any product at any stage of reasons: system failures affect a large number of
the development or maintenance process. people; users often reject systems that are unre-
liable, unsafe, or insecure; system failure costs
3. Practical Considerations may be enormous; and undependable systems
may cause information loss. System and soft-
3.1. Software Quality Requirements ware dependability include such characteristics
[9*, c11s1] [18*, c12] as availability, reliability, safety, and security.
[17*, c15s3.2.2, c15s3.3.1, c16s9.10] When developing dependable software, tools and
techniques can be applied to reduce the risk of
3.1.1. Influence Factors injecting faults into the intermediate deliverables
or the final software product. Verification, valida-
Various factors influence planning, management, tion, and testing processes, techniques, methods,
and selection of SQM activities and techniques, and tools identify faults that impact dependability
including as early as possible in the life cycle. Addition-
ally, mechanisms may need to be in place in the
• the domain of the system in which the soft- software to guard against external attacks and to
ware resides; the system functions could be tolerate faults.
safety-critical, mission-critical, business-
critical, security-critical 3.1.3. Integrity Levels of Software
• the physical environment in which the soft-
ware system resides Defining integrity levels is a method of risk
• system and software functional (what the management.
system does) and quality (how well the sys-
tem performs its functions) requirements Software integrity levels are a range of
• the commercial (external) or standard (inter- values that represent software complexity,
nal) components to be used in the system criticality, risk, safety level, security level,
10-10 SWEBOK® Guide V3.0
the causes of the defects—for example, root cause also Formal Methods in the Software Engineer-
analysis (RCA). RCA activities include analyzing ing Models and Methods KA.)
and summarizing the findings to find root causes
and using measurement techniques to improve 3.3.2. Dynamic Techniques
the product and the process as well as to track the
defects and their removal. Process improvement Dynamic techniques involve executing the soft-
is primarily discussed in the Software Engineer- ware code. Different kinds of dynamic techniques
ing Process KA, with the SQM process being a are performed throughout the development and
source of information. maintenance of software. Generally, these are
Data on inadequacies and defects found by testing techniques, but techniques such as simu-
software quality control techniques may be lost lation and model analysis may be considered
unless they are recorded. For some techniques dynamic (see the Software Engineering Models
(e.g., technical reviews, audits, inspections), and Methods KA). Code reading is considered a
recorders are present to set down such informa- static technique, but experienced software engi-
tion, along with issues and decisions. When auto- neers may execute the code as they read through
mated tools are used (see topic 4, Software Qual- it. Code reading may utilize dynamic techniques.
ity Tools), the tool output may provide the defect This discrepancy in categorizing indicates that
information. Reports about defects are provided people with different roles and experience in the
to the management of the organization. organization may consider and apply these tech-
niques differently.
3.3. Software Quality Management Techniques Different groups may perform testing during
[7*, c7s3] [8*, c17] [9*, c12s5, c15s1, p417] software development, including groups inde-
[16*] pendent of the development team. The Software
Testing KA is devoted entirely to this subject.
Software quality control techniques can be cat-
egorized in many ways, but a straightforward 3.3.3. Testing
approach uses just two categories: static and
dynamic. Dynamic techniques involve executing Two types of testing may fall under V&V because
the software; static techniques involve analyzing of their responsibility for the quality of the mate-
documents and source code but not executing the rials used in the project:
software.
• Evaluation and tests of tools to be used on
3.3.1. Static Techniques the project
• Conformance tests (or review of confor-
Static techniques examine software documenta- mance tests) of components and COTS prod-
tion (including requirements, interface specifica- ucts to be used in the product.
tions, designs, and models) and software source
code without executing the code. There are many Sometimes an independent (third-party or
tools and techniques for statically examining soft- IV&V) organization may be tasked to perform
ware work-products (see section 2.3.2). In addi- testing or to monitor the test process V&V may
tion, tools that analyze source code control flow be called upon to evaluate the testing itself: ade-
and search for dead code are considered to be quacy of plans, processes, and procedures, and
static analysis tools because they do not involve adequacy and accuracy of results.
executing the software code. The third party is not the developer, nor is it
Other, more formal, types of analytical tech- associated with the development of the product.
niques are known as formal methods. They are Instead, the third party is an independent facil-
notably used to verify software requirements and ity, usually accredited by some body of authority.
designs. They have mostly been used in the veri- Their purpose is to test a product for conformance
fication of crucial parts of critical systems, such to a specific set of requirements (see the Software
as specific security and safety requirements. (See Testing KA).
10-12 SWEBOK® Guide V3.0
can be applied to artifacts including models, in • Tools that support tracking of software prob-
addition to source code. (See the Software Con- lems provide for entry of anomalies discov-
struction, Software Testing, and Software Main- ered during software testing and subsequent
tenance KAs for descriptions of dynamic analysis analysis, disposition, and resolution. Some
tools.) tools include support for workflow and for
Categories of static analysis tools include the tracking the status of problem resolution.
following: • Tools that analyze data captured from soft-
ware engineering environments and soft-
• Tools that facilitate and partially automate ware test environments and produce visual
reviews and inspections of documents and displays of quantified data in the form of
code. These tools can route work to differ- graphs, charts, and tables. These tools some-
ent participants in order to partially automate times include the functionality to perform
and control a review process. They allow statistical analysis on data sets (for the pur-
users to enter defects found during inspec- pose of discerning trends and making fore-
tions and reviews for later removal. casts). Some of these tools provide defect
• Some tools help organizations perform soft- and removal injection rates; defect densities;
ware safety hazard analysis. These tools yields; distribution of defect injection and
provide, e.g., automated support for failure removal for each of the life cycle phases.
mode and effects analysis (FMEA) and fault
tree analysis (FTA).
10-14 SWEBOK® Guide V3.0
Wiegers 2003
Voland 2003
Moore 2006
Galin 2004
Kan 2002
[10*]
[18*]
[16*]
[17*]
[8*]
[9*]
[7*]
[3*]
[6*]
1. Software
Quality
Fundamentals
1.1. Software
Engineering
c1s4 c2s3.5
Culture and
Ethics
1.2. Value and c17,
Cost of Quality c22
1.3. Models
and Quality c24s1 c2s4 c17
Characteristics
1.4. Software
c11
Quality c1s4 c24
s2.4
Improvement
1.5. Software
c11s3
Safety
2. Software
Quality
Management
Processes
2.1. Software c4–c6,
Quality c11,
Assurance c26–27
c2
s2.3,
2.2. Verification c8, c15
and Validation s1.1,
c21
s3.3
2.3. Reviews
c24s3 *
and Audits
Software Quality 10-15
Wiegers 2003
Voland 2003
Moore 2006
Galin 2004
Kan 2002
[10*]
[18*]
[16*]
[17*]
[8*]
[9*]
[7*]
[3*]
[6*]
3. Software
Quality Practical
Considerations
c15
s3.2.2,
3.1. Software
c15
Quality c11s1 c12
s3.3.1,
Requirements
c16
s9.10
c3s3,
3.2. Defect
c8s8,
Characterization
c10s2
c12s5,
3.3. SQM
c7s3 c17 c15s1, *
Techniques
p417
3.4. Software
Quality c4 c17 p90
Measurement
4. Software
Quality Tools
10-16 SWEBOK® Guide V3.0
FURTHER READINGS
N. Leveson, Safeware: System Safety and K.E. Wiegers, Peer Reviews in Software: A
Computers [20]. Practical Guide [23].
This book describes the importance of software This book provides clear, succinct explanations
safety practices and how these practices can be of different peer review methods distinguished by
incorporated into software development projects. level of formality and effectiveness. Pragmatic
guidance for implementing the methods and how
T. Gilb, Principles of Software Engineering to select which methods are appropriate for given
Management [21]. circumstances is provided.
This is one of the first books on iterative and N.R. Tague, The Quality Toolbox, 2nd ed., [24].
incremental development techniques. The Evo
Method defines quantified goals, frequent time- Provides a pragmatic how-to explanation of a
boxed iterations, measurements of progress comprehensive set of methods, tools, and tech-
toward goals, and adaptation of plans based on niques for solving quality improvement prob-
actual results. lems. Includes the seven basic quality control
tools and many others.
T. Gilb and D. Graham, Software Inspection
[22]. IEEE Std. P730-2013 Draft Standard for
Software Quality Assurance Processes [5].
This book introduces measurement and statisti-
cal sampling for reviews and defects. It presents This draft standard expands the SQA processes
techniques that produce quantified results for identified in IEEE/ISO/IEC 12207-2008. P730
reducing defects, improving productivity, track- establishes standards for initiating, planning,
ing projects, and creating documentation. controlling, and executing the software quality
assurance processes of a software development
or maintenance project. Approval of this draft
standard is expected in 2014.
Software Quality 10-17
REFERENCES
[1] P.B. Crosby, Quality Is Free, McGraw-Hill, [13] IEEE Std. 12207-2008 (a.k.a. ISO/IEC
1979. 12207:2008) Standard for Systems and
Software Engineering—Software Life Cycle
[2] W. Humphrey, Managing the Software Processes, IEEE, 2008.
Process, Addison-Wesley, 1989.
[14] ISO 9000:2005 Quality Management
[3*] S.H. Kan, Metrics and Models in Software Systems—Fundamentals and Vocabulary,
Quality Engineering, 2nd ed., Addison- ISO, 2005.
Wesley, 2002.
[15] IEEE Std. 1012-2012 Standard for System
[4] ISO/IEC 25010:2011 Systems and Software and Software Verification and Validation,
Engineering—Systems and Software IEEE, 2012.
Quality Requirements and Evaluation
(SQuaRE)—Systems and Software Quality [16*] IEEE Std. 1028-2008, Software Reviews
Models, ISO/IEC, 2011. and Audits, IEEE, 2008.
[5] IEEE P730™/D8 Draft Standard for [17*] J.W. Moore, The Road Map to Software
Software Quality Assurance Processes, Engineering: A Standards-Based Guide,
IEEE, 2012. Wiley-IEEE Computer Society Press, 2006.
[6*] F. Bott et al., Professional Issues in [18*] K.E. Wiegers, Software Requirements, 2nd
Software Engineering, 3rd ed., Taylor & ed., Microsoft Press, 2003.
Francis, 2000.
[19] ISO/IEC/IEEE 24765:2010 Systems and
[7*] D. Galin, Software Quality Assurance: Software Engineering—Vocabulary, ISO/
From Theory to Implementation, Pearson IEC/IEEE, 2010.
Education Limited, 2004.
[20] N. Leveson, Safeware: System Safety and
[8*] S. Naik and P. Tripathy, Software Testing Computers, Addison-Wesley Professional,
and Quality Assurance: Theory and 1995.
Practice, Wiley-Spektrum, 2008.
[21] T. Gilb, Principles of Software Engineering
[9*] P. Clements et al., Documenting Software Management, Addison-Wesley Professional,
Architectures: Views and Beyond, 2nd ed., 1988.
Pearson Education, 2010.
[22] T. Gilb and D. Graham, Software
[10*] G. Voland, Engineering by Design, 2nd Inspection, Addison-Wesley Professional,
ed., Prentice Hall, 2003. 1993.
[11] RTCA DO-178C, Software Considerations [23] K. Wiegers, Peer Reviews in Software: A
in Airborne Systems and Equipment Practical Guide, Addison-Wesley
Certification, Radio Technical Commission Professional, 2001.
for Aeronautics, 2011.
[24] N.R. Tague, The Quality Toolbox, 2nd ed.,
[12] IEEE Std. 15026.1-2011 Trial-Use Standard ASQ Quality Press, 2010.
Adoption of ISO/IEC TR 15026-1:2010
Systems and Software Engineering—
Systems and Software Assurance—Part 1:
Concepts and Vocabulary, IEEE, 2011.
CHAPTER 11
SOFTWARE ENGINEERING
PROFESSIONAL PRACTICE
11-1
11-2 SWEBOK® Guide V3.0
Figure 11.1. Breakdown of Topics for the Software Engineering Professional Practice KA
elements that lay the foundation for of the profes- 11.1. The subareas presented in this KA are pro-
sional practice of software engineering. fessionalism, group dynamics and psychology,
and communication skills.
BREAKDOWN OF TOPICS FOR
SOFTWARE ENGINEERING 1. Professionalism
PROFESSIONAL PRACTICE
A software engineer displays professionalism
The Software Engineering Professional Practice notably through adherence to codes of ethics
KA’s breakdown of topics is shown in Figure and professional conduct and to standards and
Software Engineering Professional Practice 11-3
practices that are established by the engineer’s of certification is professional certification, where
professional community. a person is certified as being able to complete an
The professional community is often repre- activity in a certain discipline at a stated level
sented by one or more professional societies; of competency. Professional certification also
those societies publish codes of ethics and profes- can also verify the holder’s ability to meet pro-
sional conduct as well as criteria for admittance fessional standards and to apply professional
to the community. Those criteria form the basis judgment in solving or addressing problems.
for accreditation and licensing activities and may Professional certification can also involve the
be used as a measure to determine engineering verification of prescribed knowledge, the master-
competence or negligence. ing of best practice and proven methodologies,
and the amount of professional experience.
1.1. Accreditation, Certification, and Licensing An engineer usually obtains certification by
[1*, c1s4.1, c1s5.1–c1s5.4] passing an examination in conjunction with other
experience-based criteria. These examinations
1.1.1. Accreditation are often administered by nongovernmental orga-
nizations, such as professional societies.
Accreditation is a process to certify the compe- In software engineering, certification testi-
tency, authority, or credibility of an organization. fies to one’s qualification as a software engineer.
Accredited schools or programs are assured to For example, the IEEE CS has enacted two cer-
adhere to particular standards and maintain cer- tification programs (CSDA and CSDP) designed
tain qualities. In many countries, the basic means to confirm a software engineer’s knowledge of
by which engineers acquire knowledge is through standard software engineering practices and to
completion of an accredited course of study. advance one’s career. A lack of certification does
Often, engineering accreditation is performed by not exclude the individual from working as a
a government organization, such as the ministry software engineer. Currently certification in soft-
of education. Such countries with government ware engineering is completely voluntary. In fact,
accreditations include China, France, Germany, most software engineers are not certified under
Israel, Italy, and Russia. any program.
In other countries, however, the accredita-
tion process is independent of government and 1.1.3. Licensing
performed by private membership associations.
For example, in the United States, engineer- “Licensing” is the action of giving a person the
ing accreditation is performed by an organiza- authorization to perform certain kinds of activi-
tion known as ABET. An organization known as ties and take responsibility for resultant engineer-
CSAB serving as a participating body of ABET ing products. The noun “license” refers to both
is the lead society within ABET for the accredita- that authorization and the document recording
tion of degree programs in software engineering. that authorization. Governmental authorities or
While the process of accreditation may be dif- statutory bodies usually issue licenses.
ferent for each country and jurisdiction, the general Obtaining a license to practice requires not only
meaning is the same. For an institution’s course of that an individual meets a certain standard, but
study to be accredited means that “the accredita- also that they do so with a certain ability to prac-
tion body recognizes an educational institution as tice or operate. Sometimes there is an entry-level
maintaining standards that qualify the graduates requirement which sets the minimum skills and
for admission to higher or more specialized insti- capabilities to practice, but as the professional
tutions or for professional practice” [2]. moves through his or her career, the required
skills and capabilities change and evolve.
1.1.2. Certification In general, engineers are licensed as a means of
protecting the public from unqualified individuals.
Certification refers to the confirmation of a per- In some countries, no one can practice as a pro-
son’s particular characteristics. A common type fessional engineer unless licensed; or further, no
11-4 SWEBOK® Guide V3.0
company may offer “engineering services” unless Since standards and codes of ethics and pro-
at least one licensed engineer is employed there. fessional conduct may be introduced, modified,
or replaced at any time, individual software engi-
1.2. Codes of Ethics and Professional Conduct neers bear the responsibility for their own con-
[1*, c1s6–c1s9] [3*, c8] [4*, c1s2] [5*, c33] tinuing study to stay current in their professional
[6*] practice.
Codes of ethics and professional conduct com- 1.3. Nature and Role of Professional Societies
prise the values and behavior that an engineer’s [1*, c1s1–c1s2] [4*, c1s2] [5*, c35s1]
professional practice and decisions should
embody. Professional societies are comprised of a mix
The professional community establishes codes of practitioners and academics. These societies
of ethics and professional conduct. They exist serve to define, advance, and regulate their cor-
in the context of, and are adjusted to agree with, responding professions. Professional societies
societal norms and local laws. Therefore, codes help to establish professional standards as well
of ethics and professional conduct present guid- as codes of ethics and professional conduct. For
ance in the face of conflicting imperatives. this reason, they also engage in related activities,
Once established, codes of ethics and profes- which include
sional conduct are enforced by the profession,
as represented by professional societies or by a • establishing and promulgating a body of gen-
statutory body. erally accepted knowledge;
Violations may be acts of commission, such • accrediting, certifying, and licensing;
as concealing inadequate work, disclosing con- • dispensing disciplinary actions;
fidential information, falsifying information, or • advancing the profession through confer-
misrepresenting one’s abilities. They may also ences, training, and publications.
occur through omission, including failure to dis-
close risks or to provide important information, Participation in professional societies assists
failure to give proper credit or to acknowledge the individual engineer in maintaining and sharp-
references, and failure to represent client inter- ening their professional knowledge and relevancy
ests. Violations of codes of ethics and profes- and in expanding and maintaining their profes-
sional conduct may result in penalties and pos- sional network.
sible expulsion from professional status.
A code of ethics and professional conduct for 1.4. Nature and Role of Software Engineering
software engineering was approved by the ACM Standards
Council and the IEEE CS Board of Governors in [1*, c5s3.2, c10s2.1] [5*, c32s6] [7*, c1s2]
1999 [6*]. According to the short version of this
code: Software engineering standards cover a remark-
able variety of topics. They provide guidelines for
Software engineers shall commit them- the practice of software engineering and processes
selves to making the analysis, specifica- to be used during development, maintenance, and
tion, design, development, testing and support of software. By establishing a consensual
maintenance of software a beneficial and body of knowledge and experience, software engi-
respected profession. In accordance with neering standards establish a basis upon which fur-
their commitment to the health, safety and ther guidelines may be developed. Appendix B of
welfare of the public, software engineers this Guide provides guidance on IEEE and ISO/
shall adhere to the eight principles con- IEC software engineering standards that support
cerning the public, client and employer, the knowledge areas of this Guide.
product, judgment, management, profes- The benefits of software engineering standards
sion, colleagues, and self, respectively. are many and include improving software quality,
Software Engineering Professional Practice 11-5
helping avoid errors, protecting both software consideration. Here, we are most concerned with
producers and users, increasing professional dis- the engineer-to-customer arrangement and its
cipline, and helping technology transition. attendant agreements or contracts, whether they
are of the direct-hire or consultant variety, and
1.5. Economic Impact of Software the issues they typically address.
[3*, c10s8] [4*, c1s1.1] [8*, c1] A common concern in software engineering
contracts is confidentiality. Employers derive
Software has economic effects at the individual, commercial advantage from intellectual property,
business, and societal levels. Software “success” so they strive to protect that property from dis-
may be determined by the suitability of a product closure. Therefore, software engineers are often
for a recognized problem as well as by its effec- required to sign non-disclosure (NDA) or intel-
tiveness when applied to that problem. lectual property (IP) agreements as a precondi-
At the individual level, an engineer’s continu- tion to work. These agreements typically apply
ing employment may depend on their ability to information the software engineer could only
and willingness to interpret and execute tasks gain through association with the customer. The
in meeting customers’ or employers’ needs and terms of these agreements may extend past termi-
expectations. The customer or employer’s finan- nation of the association.
cial situation may in turn be positively or nega- Another concern is IP ownership. Rights to
tively affected by the purchase of software. software engineering assets—products, innova-
At the business level, software properly applied tions, inventions, discoveries, and ideas—may
to a problem can eliminate months of work reside with the employer or customer, either under
and translate to elevated profits or more effec- explicit contract terms or relevant laws, if those
tive organizations. Moreover, organizations that assets are obtained during the term of the soft-
acquire or provide successful software may be a ware engineer’s relationship with that employer
boon to the society in which they operate by pro- or customer. Contracts differ in the ownership of
viding both employment and improved services. assets created using non-employer-owned equip-
However, the development or acquisition costs of ment or information.
software can also equate to those of any major Finally, contracts can also specify among
acquisition. other elements the location at which work is to
At the societal level, direct impacts of software be performed; standards to which that work will
success or failure include or exclude accidents, be held; the system configuration to be used for
interruptions, and loss of service. Indirect impacts development; limitations of the software engi-
include the success or failure of the organization neer’s and employer’s liability; a communication
that acquired or produced the software, increased matrix and/or escalation plan; and administrative
or decreased societal productivity, harmonious details such as rates, frequency of compensation,
or disruptive social order, and even the saving or working hours, and working conditions.
loss of property and life.
1.7. Legal Issues
1.6. Employment Contracts [1*, c6, c11] [3*, c5s3–c5s4] [9*, c1s10]
[1*, c7]
Legal issues surrounding software engineering
Software engineering services may be provided professional practice notably include matters
under a variety of client-engineer relationships. related to standards, trademarks, patents, copy-
The software engineering work may be solic- rights, trade secrets, professional liability, legal
ited as company-to-customer supplier, engineer- requirements, trade compliance, and cybercrime.
to-customer consultancy, direct hire, or even It is therefore beneficial to possess knowledge of
volunteering. In all of these situations, the cus- these issues and their applicability.
tomer and supplier agree that a product or ser- Legal issues are jurisdictionally based; soft-
vice will be provided in return for some sort of ware engineers must consult attorneys who
11-6 SWEBOK® Guide V3.0
specialize in the type and jurisdiction of any iden- are an old form of idea-ownership protection and
tified legal issues. date back to the 15th century.
Application for a patent entails careful records
1.7.1. Standards of the process that led to the invention. Patent
attorneys are helpful in writing patent disclosure
Software engineering standards establish guide- claims in a manner most likely to protect the soft-
lines for generally accepted practices and mini- ware engineer’s rights.
mum requirements for products and services pro- Note that, if inventions are made during the
vided by a software engineer. Appendix B of this course of a software engineering contract, owner-
Guide provides guidance on software engineer- ship may belong to the employer or customer or
ing standards that are applicable to each KA. be jointly held, rather than belong to the software
Standards are valuable sources of requirements engineer.
and assistance during the everyday conduct of There are rules concerning what is and is not
software engineering activities. Adherence to patentable. In many countries, software code is
standards facilitates discipline by enumerating not patentable, although software algorithms may
minimal characteristics of products and practice. be. Existing and filed patent applications can be
That discipline helps to mitigate subconscious searched at WIPO.
assumptions or overconfidence in a design. For
these reasons, organizations performing software 1.7.4. Copyrights
engineering activities often include conformance
to standards as part of their organizational poli- Most governments in the world give exclusive
cies. Further, adherence to standards is a major rights of an original work to its creator, usually
component of defense from legal action or from for a limited time, enacted as a copyright. Copy-
allegations of malpractice. rights protect the way an idea is presented—not
the idea itself. For example, they may protect the
1.7.2. Trademarks particular wording of an account of an historical
event, whereas the event itself is not protected.
A trademark relates to any word, name, symbol, Copyrights are long-term and renewable; they
or device that is used in business transactions. date back to the 17th century.
It is used “to indicate the source or origin of the
goods” [2]. 1.7.5. Trade Secrets
Trademark protection protects names, logos,
images, and packaging. However, if a name, image, In many countries, an intellectual asset such as
or other trademarked asset becomes a generic term, a formula, algorithm, process, design, method,
then trademark protection is nullified. pattern, instrument, or compilation of informa-
The World Intellectual Property Organization tion may be considered a “trade secret,” provided
(WIPO) is the authority that frames the rules and that these assets are not generally known and may
regulations on trademarks. WIPO is the United provide a business some economic advantage.
Nations agency dedicated to the use of intellec- The designation of “trade secret” provides legal
tual property as a means of stimulating innova- protection if the asset is stolen. This protection
tion and creativity. is not subject to a time limit. However, if another
party derives or discovers the same asset legally,
1.7.3. Patents then the asset is no longer protected and the other
party will also possess all rights to use it.
Patents protect an inventor’s right to manufac-
ture and sell an idea. A patent consists of a set 1.7.6. Professional Liability
of exclusive rights granted by a sovereign gov-
ernment to an individual, group of individuals, or It is common for software engineers to be con-
organization for a limited period of time. Patents cerned with matters of professional liability. As
Software Engineering Professional Practice 11-7
judged by different criteria based on the needs of of the software source code or the right to modify
the various stakeholder audiences. the code, the software engineer should provide
Good documentation complies with accepted documentation of the functional specifications,
standards and guidelines. In particular, software the software design, the test suite, and the neces-
engineers should document sary operating environment for the software.
The minimum length of time documents should
• relevant facts, be kept is the duration of the software products’
• significant risks and tradeoffs, and life cycle or the time required by relevant organi-
• warnings of undesirable or dangerous conse- zational or regulatory requirements.
quences from use or misuse of the software.
1.9. Tradeoff Analysis
Software engineers should avoid [3*, c1s2, c10] [9*, c9s5.10]
A software engineer must conduct a tradeoff One point to emphasize is that software engi-
analysis in an ethical manner—notably by being neers must be able to work in multidisciplinary
objective and impartial when selecting criteria for environments and in varied application domains.
comparison of alternative problem solutions and Since today software is everywhere, from a phone
when assigning weights or importance to these to a car, software is impacting people’s lives far
criteria. Any conflict of interest must be disclosed beyond the more traditional concept of software
up front. made for information management in a business
environment.
2. Group Dynamics and Psychology
2.2. Individual Cognition
Engineering work is very often conducted in the [3*, c1s6.5] [5*, c33]
context of teamwork. A software engineer must
be able to interact cooperatively and construc- Engineers desire to solve problems. The ability to
tively with others to first determine and then solve problems effectively and efficiently is what
meet both needs and expectations. Knowledge of every engineer strives for. However, the limits
group dynamics and psychology is an asset when and processes of individual cognition affect prob-
interacting with customers, coworkers, suppliers, lem solving. In software engineering, notably due
and subordinates to solve software engineering to the highly abstract nature of software itself,
problems. individual cognition plays a very prominent role
in problem solving.
2.1. Dynamics of Working in Teams/Groups In general, an individual’s (in particular, a software
[3*, c1s6] [9*, c1s3.5, c10] engineer’s) ability to decompose a problem and cre-
atively develop a solution can be inhibited by
Software engineers must work with others. On
one hand, they work internally in engineering • need for more knowledge,
teams; on the other hand, they work with cus- • subconscious assumptions,
tomers, members of the public, regulators, and • volume of data,
other stakeholders. Performing teams—those • fear of failure or consequence of failure,
that demonstrate consistent quality of work and • culture, either application domain or
progress toward goals—are cohesive and possess organizational,
a cooperative, honest, and focused atmosphere. • lack of ability to express the problem,
Individual and team goals are aligned so that the • perceived working atmosphere, and
members naturally commit to and feel ownership • emotional status of the individual.
of shared outcomes.
Team members facilitate this atmosphere by The impact of these inhibiting factors can be
being intellectually honest, making use of group reduced by cultivating good problem solving
thinking, admitting ignorance, and acknowledg- habits that minimize the impact of misleading
ing mistakes. They share responsibility, rewards, assumptions. The ability to focus is vital, as is
and workload fairly. They take care to communi- intellectual humility: both allow a software engi-
cate clearly, directly to each other and in docu- neer to suspend personal considerations and con-
ments, as well as in source code, so that informa- sult with others freely, which is especially impor-
tion is accessible to everyone. Peer reviews about tant when working in teams.
work products are framed in a constructive and There is a set of basic methods engineers use
nonpersonal way (see Reviews and Audits in the to facilitate problem solving (see Problem Solv-
Software Quality KA). This allows all the mem- ing Techniques in the Computing Foundations
bers to pursue a cycle of continuous improvement KA). Breaking down problems and solving them
and growth without personal risk. In general, one piece at a time reduces cognitive overload.
members of cohesive teams demonstrate respect Taking advantage of professional curiosity and
for each other and their leader. pursuing continuous professional development
11-10 SWEBOK® Guide V3.0
through training and study add skills and knowl- Therefore, it is vital to maintain open and pro-
edge to the software engineer’s portfolio; reading, ductive communication with stakeholders for the
networking, and experimenting with new tools, duration of the software product’s lifetime.
techniques, and methods are all valid means of
professional development. 2.5. Dealing with Uncertainty and Ambiguity
[4*, c24s4, c26s2] [9*, c9s4]
2.3. Dealing with Problem Complexity
[3*, c3s2] [5*, c33] As with engineers of other fields, software engi-
neers must often deal with and resolve uncer-
Many, if not most, software engineering prob- tainty and ambiguities while providing services
lems are too complex and difficult to address as and developing products. The software engineer
a whole or to be tackled by individual software must attack and reduce or eliminate any lack of
engineers. When such circumstances arise, the clarity that is an obstacle to performing work.
usual means to adopt is teamwork and problem Often, uncertainty is simply a reflection of lack
decomposition (see Problem Solving Techniques of knowledge. In this case, investigation through
in the Computing Foundations KA). recourse to formal sources such as textbooks and
Teams work together to deal with complex and professional journals, interviews with stakehold-
large problems by sharing burdens and draw- ers, or consultation with teammates and peers can
ing upon each other’s knowledge and creativity. overcome it.
When software engineers work in teams, differ- When uncertainty or ambiguity cannot be over-
ent views and abilities of the individual engineers come easily, software engineers or organizations
complement each other and help build a solution may choose to regard it as a project risk. In this
that is otherwise difficult to come by. Some spe- case, work estimates or pricing are adjusted to
cific teamwork examples to software engineering mitigate the anticipated cost of addressing it (see
are pair programming (see Agile Methods in the Risk Management in the Software Engineering
Software Engineering Models and Methods KA) Management KA).
and code review (see Reviews and Audits in the
Software Quality KA). 2.6. Dealing with Multicultural Environments
[9*, c10s7]
2.4. Interacting with Stakeholders
[9*, c2s3.1] Multicultural environments can have an impact
on the dynamics of a group. This is especially
Success of a software engineering endeavor true when the group is geographically separated
depends upon positive interactions with stake- or communication is infrequent, since such sepa-
holders. They should provide support, informa- ration elevates the importance of each contact.
tion, and feedback at all stages of the software Intercultural communication is even more dif-
life cycle process. For example, during the early ficult if the difference in time zones make oral
stages, it is critical to identify all stakeholders and communication less frequent.
discover how the product will affect them, so that Multicultural environments are quite prevalent
sufficient definition of the stakeholder require- in software engineering, perhaps more than in
ments can be properly and completely captured. other fields of engineering, due to the strong trend
During development, stakeholders may pro- of international outsourcing and the easy shipment
vide feedback on specifications and/or early of software components instantaneously across
versions of the software, change of priority, as the globe. For example, it is rather common for a
well as clarification of detailed or new software software project to be divided into pieces across
requirements. Last, during software maintenance national and cultural borders, and it is also quite
and until the end of product life, stakeholders pro- common for a software project team to consist of
vide feedback on evolving or new requirements people from diverse cultural backgrounds.
as well problem reports so that the software may For a software project to be a success, team
be extended and improved. members must achieve a level of tolerance,
Software Engineering Professional Practice 11-11
acknowledging that some rules depend on soci- or rewriting software, it is critical to understand
etal norms and that not all societies derive the both its implementation directly derived from the
same solutions and expectations. presented code and its design, which must often
This tolerance and accompanying understand- be inferred.
ing can be facilitated by the support of leadership
and management. More frequent communication, 3.2. Writing
including face-to-face meetings, can help to miti- [3*, c1s5]
gate geographical and cultural divisions, promote
cohesiveness, and raise productivity. Also, being Software engineers are able to produce written
able to communicate with teammates in their products as required by customer requests or gen-
native language could be very beneficial. erally accepted practice. These written products
may include source code, software project plans,
3. Communication Skills software requirement documents, risk analyses,
software design documents, software test plans,
It is vital that a software engineer communicate user manuals, technical reports and evaluations,
well, both orally and in reading and writing. Suc- justifications, diagrams and charts, and so forth.
cessful attainment of software requirements and Writing clearly and concisely is very important
deadlines depends on developing clear under- because often it is the primary method of com-
standing between the software engineer and munication among relevant parties. In all cases,
customers, supervisors, coworkers, and suppli- written software engineering products must be
ers. Optimal problem solving is made possible written so that they are accessible, understand-
through the ability to investigate, comprehend, able and relevant for their intended audience(s).
and summarize information. Customer product
acceptance and safe product usage depend on the 3.3. Team and Group Communication
provision of relevant training and documentation. [3*, c1s6.8] [4*, c22s3] [5*, c27s1]
It follows that the software engineer’s own career [9*, c10s4]
success is affected by the ability to consistently
provide oral and written communication effec- Effective communication among team and group
tively and on time. members is essential to a collaborative software
engineering effort. Stakeholders must be con-
3.1. Reading, Understanding, and Summarizing sulted, decisions must be made, and plans must
[5*, c33s3] be generated. The greater the number of team
and group members, the greater the need to
Software engineers are able to read and under- communicate.
stand technical material. Technical material The number of communication paths, how-
includes reference books, manuals, research ever, grows quadratically with the addition of
papers, and program source code. each team member. Further, team members
Reading is not only a primary way of improv- are unlikely to communicate with anyone per-
ing skills, but also a way of gathering informa- ceived to be removed from them by more than
tion necessary for the completion of engineering two degrees (levels). This problem can be more
goals. A software engineer sifts through accu- serious when software engineering endeavors or
mulated information, filtering out the pieces that organizations are spread across national and con-
will be most helpful. Customers may request that tinental borders.
a software engineer summarize the results of Some communication can be accomplished in
such information gathering for them, simplifying writing. Software documentation is a common
or explaining it so that they may make the final substitute for direct interaction. Email is another
choice between competing solutions. but, although it is useful, it is not always enough;
Reading and comprehending source code is also, if one sends too many messages, it becomes
also a component of information gathering and difficult to identify the important information.
problem solving. When modifying, extending, Increasingly, organizations are using enterprise
11-12 SWEBOK® Guide V3.0
collaboration tools to share information. In addi- phase, software engineers may walk customers
tion, the use of electronic information stores, and teammates through software requirements
accessible to all team members, for organiza- and conduct formal requirements reviews (see
tional policies, standards, common engineering Requirement Reviews in the Software Require-
procedures, and project-specific information, can ments KA). During and after software design,
be most beneficial. software construction, and software maintenance,
Some software engineering teams focus on software engineers lead reviews, product walk-
face-to-face interaction and promote such inter- throughs (see Review and Audits in the Software
action by office space arrangement. Although Quality KA), and training. All of these require the
private offices improve individual productivity, ability to present technical information to groups
colocating team members in physical or virtual and solicit ideas or feedback.
forms and providing communal work areas is The software engineer’s ability to convey
important to collaborative efforts. concepts effectively in a presentation therefore
influences product acceptance, management,
3.4. Presentation Skills and customer support; it also influences the abil-
[3*, c1s5] [4*, c22] [9*, c10s7–c10s8] ity of stakeholders to comprehend and assist in
the product effort. This knowledge needs to be
Software engineers rely on their presentation archived in the form of slides, knowledge write-
skills during software life cycle processes. For up, technical whitepapers, and any other material
example, during the software requirements utilized for knowledge creation.
Software Engineering Professional Practice 11-13
IEEE-CS/ACM 1999
Sommerville 2011
McConnell 2004
Bott et al. 2000
Fairley 2009
Voland 2003
Tockey 2004
Moore 2006
[8*]
[9*]
[7*]
[5*]
[3*]
[4*]
[6*]
[1*]
1. Professionalism
1.1. Accreditation, c1s4.1,
Certification, and c1s5.1–
Licensing c1s5.4
1.2. Codes of Ethics
c1s6–
and Professional c8 c1s2 c33 *
c1s9
Conduct
1.3. Nature and
c1s1–
Role of Professional c1s2 c35s1
c1s2
Societies
1.4. Nature and
Role of Software c5s3.2,
c32s6 c1s2
Engineering c10s2.1
Standards
1.5. Economic
c10s8 c1s1.1 c1
Impact of Software
1.6. Employment
c7
Contracts
c5s3–
1.7. Legal Issues c6, c11 c1s10
c5s4
1.8. Documentation c10s5.8 c1s5 c32
1.9. Tradeoff c1s2,
c9s5.10
Analysis c10
2. Group Dynamics
and Psychology
2.1. Dynamics of
c1s3.5,
Working in Teams/ c1s6
c10
Groups
2.2. Individual
c1s6.5 c33
Cognition
2.3. 2.3 Dealing with
c3s2 c33
Problem Complexity
2.4. Interacting with
c2s3.1
Stakeholders
11-14 SWEBOK® Guide V3.0
IEEE-CS/ACM 1999
Sommerville 2011
McConnell 2004
Bott et al. 2000
Fairley 2009
Voland 2003
Tockey 2004
Moore 2006
[8*]
[9*]
[7*]
[5*]
[3*]
[4*]
[6*]
[1*]
2.5. Dealing with
c24s4,
Uncertainty and c9s4
c26s2
Ambiguity
2.6. Dealing with
Multicultural c10s7
Environments
3. Communication
Skills
3.1. Reading,
Understanding, and c33s3
Summarizing
3.2. Writing c1s5
3.3. Team and Group
c1s6.8 c22s3 c27s1 c10s4
Communication
3.4. Presentation c10s7–
c1s5 c22
Skills c10s8
Software Engineering Professional Practice 11-15
Kinney and Lange, P.A., Intellectual Property [3*] G. Voland, Engineering by Design, 2nd ed.,
Law for Business Lawyers [11]. Prentice Hall, 2003.
This book covers IP laws in the US. It not only [4*] I. Sommerville, Software Engineering, 9th
talks about what the IP law is; it also explains ed., Addison-Wesley, 2011.
why it looks the way it does.
[5*] S. McConnell, Code Complete, 2nd ed.,
Microsoft Press, 2004.
12-1
12-2 SWEBOK® Guide V3.0
BREAKDOWN OF TOPICS FOR to know the results of their investment: did they
SOFTWARE ENGINEERING ECONOMICS get the profit they were expecting? In “for-profit”
organizations, this relates to the tangible ROI
The breakdown of topics for the Software Engi- (see section 4.3, Return on Investment), while in
neering Economics KA is shown in Figure 12.1. “not-for-profit” and governmental organizations
as well as “for-profit” organizations, it translates
1. Software Engineering Economics into sustainably staying in business. The primary
Fundamentals role of accounting is to measure the organiza-
tion’s actual financial performance and to com-
1.1. Finance municate financial information about a business
[1*, c2] entity to stakeholders, such as shareholders,
financial auditors, and investors. Communication
Finance is the branch of economics concerned is generally in the form of financial statements
with issues such as allocation, management, that show in money terms the economic resources
acquisition, and investment of resources. Finance to be controlled. It is important to select the right
is an element of every organization, including information that is both relevant and reliable to
software engineering organizations. the user. Information and its timing are partially
The field of finance deals with the concepts of governed by risk management and governance
time, money, risk, and how they are interrelated. policies. Accounting systems are also a rich
It also deals with how money is spent and bud- source of historical data for estimating.
geted. Corporate finance is concerned with pro-
viding the funds for an organization’s activities. 1.3. Controlling
Generally, this involves balancing risk and profit- [1*, c15]
ability, while attempting to maximize an organi-
zation’s wealth and the value of its stock. This Controlling is an element of finance and account-
holds primarily for “for-profit” organizations, ing. Controlling involves measuring and correct-
but also applies to “not-for-profit” organizations. ing the performance of finance and accounting.
The latter needs finances to ensure sustainability, It ensures that an organization’s objectives and
while not targeting tangible profit. To do this, an plans are accomplished. Controlling cost is a spe-
organization must cialized branch of controlling used to detect vari-
ances of actual costs from planned costs.
• identify organizational goals, time horizons,
risk factors, tax considerations, and financial 1.4. Cash Flow
constraints; [1*, c3]
• identify and implement the appropriate busi-
ness strategy, such as which portfolio and Cash flow is the movement of money into or out
investment decisions to take, how to manage of a business, project, or financial product over a
cash flow, and where to get the funding; given period. The concepts of cash flow instances
• measure financial performance, such as and cash flow streams are used to describe the
cash flow and ROI (see section 4.3, Return business perspective of a proposal. To make a
on Investment), and take corrective actions meaningful business decision about any specific
in case of deviation from objectives and proposal, that proposal will need to be evaluated
strategy. from a business perspective. In a proposal to
develop and launch product X, the payment for
1.2. Accounting new software licenses is an example of an outgo-
[1*, c15] ing cash flow instance. Money would need to be
spent to carry out that proposal. The sales income
Accounting is part of finance. It allows people from product X in the 11th month after market
whose money is being used to run an organization launch is an example of an incoming cash flow
12-4 SWEBOK® Guide V3.0
Inflation describes long-term trends in prices. One of the most fundamental concepts in
Inflation means that the same things cost more finance—and therefore, in business decisions—
than they did before. If the planning horizon of is that money has time-value: its value changes
a business decision is longer than a few years, or over time. A specific amount of money right now
if the inflation rate is over a couple of percentage almost always has a different value than the same
points annually, it can cause noticeable changes amount of money at some other time. This con-
in the value of a proposal. The present time value cept has been around since the earliest recorded
therefore needs to be adjusted for inflation rates human history and is commonly known as time-
and also for exchange rate fluctuations. value. In order to compare proposals or portfo-
lio elements, they should be normalized in cost,
1.8. Depreciation value, and risk to the net present value. Currency
[1*, c14] exchange variations over time need to be taken
into account based on historical data. This is par-
Depreciation involves spreading the cost of a ticularly important in cross-border developments
tangible asset across a number of time periods; of all kinds.
it is used to determine how investments in capi-
talized assets are charged against income over 1.11. Efficiency
several years. Depreciation is an important part [2*, c1]
of determining after-tax cash flow, which is criti-
cal for accurately addressing profit and taxes. If Economic efficiency of a process, activity, or
a software product is to be sold after the devel- task is the ratio of resources actually consumed to
opment costs are incurred, those costs should be resources expected to be consumed or desired to
capitalized and depreciated over subsequent time be consumed in accomplishing the process, activ-
periods. The depreciation expense for each time ity, or task. Efficiency means “doing things right.”
period is the capitalized cost of developing the An efficient behavior, like an effective behavior,
software divided across the number of periods delivers results—but keeps the necessary effort to
in which the software will be sold. A software a minimum. Factors that may affect efficiency in
project proposal may be compared to other soft- software engineering include product complex-
ware and nonsoftware proposals or to alternative ity, quality requirements, time pressure, process
investment options, so it is important to deter- capability, team distribution, interrupts, feature
mine how those other proposals would be depre- churn, tools, and programming language.
ciated and how profits would be estimated.
1.12. Effectiveness
1.9. Taxation [2*, c1]
[1*, c16, c17]
Effectiveness is about having impact. It is the
Governments charge taxes in order to finance relationship between achieved objectives to
expenses that society needs but that no single orga- defined objectives. Effectiveness means “doing
nization would invest in. Companies have to pay the right things.” Effectiveness looks only at
income taxes, which can take a substantial portion whether defined objectives are reached—not at
of a corporation’s gross profit. A decision analysis how they are reached.
that does not account for taxation can lead to the
wrong choice. A proposal with a high pretax profit 1.13. Productivity
won’t look nearly as profitable in posttax terms. [2*, c23]
Not accounting for taxation can also lead to unre-
alistically high expectations about how profitable a Productivity is the ratio of output over input from
proposed product might be. an economic perspective. Output is the value
Software Engineering Economics 12-7
delivered. Input covers all resources (e.g., effort) from managing them individually.”2 Programs
spent to generate the output. Productivity com- are often used to identify and manage different
bines efficiency and effectiveness from a value- deliveries to a single customer or market over a
oriented perspective: maximizing productivity time horizon of several years.
is about generating highest value with lowest
resource consumption. 2.4. Portfolio
specific vendor quote, shipment or invoice date, parameters used to determine whether programs,
combination of multiple orders, service offerings, investments, and acquisitions are achieving the
and many others. The needs of the consumer can desired results. It is used to evaluate whether
be converted into demand only if the consumer performance objectives are actually achieved; to
has the willingness and capacity to buy the prod- control budgets, resources, progress, and deci-
uct. Thus, pricing is very important in marketing. sions; and to improve performance.
Pricing is initially done during the project initia-
tion phase and is a part of “go” decision making. 2.13. Earned Value Management
[3*, c8]
2.11. Cost and Costing
[1*, c15] Earned value management (EVM) is a project
management technique for measuring progress
A cost is the value of money that has been used up based on created value. At a given moment, the
to produce something and, hence, is not available results achieved to date in a project are com-
for use anymore. In economics, a cost is an alter- pared with the projected budget and the planned
native that is given up as a result of a decision. schedule progress for that date. Progress relates
A sunk cost is the expenses before a certain already-consumed resources and achieved
time, typically used to abstract decisions from results at a given point in time with the respec-
expenses in the past, which can cause emotional tive planned values for the same date. It helps
hurdles in looking forward. From a traditional to identify possible performance problems at an
economics point of view, sunk costs should not early stage. A key principle in EVM is tracking
be considered in decision making. Opportunity cost and schedule variances via comparison of
cost is the cost of an alternative that must be for- planned versus actual schedule and budget versus
gone in order to pursue another alternative. actual cost. EVM tracking gives much earlier vis-
Costing is part of finance and product manage- ibility to deviations and thus permits corrections
ment. It is the process to determine the cost based earlier than classic cost and schedule tracking that
on expenses (e.g., production, software engineer- only looks at delivered documents and products.
ing, distribution, rework) and on the target cost
to be competitive and successful in a market. 2.14. Termination Decisions
The target cost can be below the actual estimated [1*, c11, c12] [2*, c9]
cost. The planning and controlling of these costs
(called cost management) is important and should Termination means to end a project or product.
always be included in costing. Termination can be preplanned for the end of a
An important concept in costing is the total cost long product lifetime (e.g., when foreseeing that a
of ownership (TCO). This holds especially for product will reach its lifetime) or can come rather
software, because there are many not-so-obvious spontaneously during product development
costs related to SPLC activities after initial prod- (e.g., when project performance targets are not
uct development. TCO for a software product is achieved). In both cases, the decision should be
defined as the total cost for acquiring, activating, carefully prepared, considering always the alter-
and keeping that product running. These costs natives of continuing versus terminating. Costs of
can be grouped as direct and indirect costs. TCO different alternatives must be estimated—cover-
is an accounting method that is crucial in making ing topics such as replacement, information col-
sound economic decisions. lection, suppliers, alternatives, assets, and utiliz-
ing resources for other opportunities. Sunk costs
2.12. Performance Measurement should not be considered in such decision making
[3*, c7, c8] because they have been spent and will not reap-
pear as a value.
Performance measurement is the process whereby
an organization establishes and measures the
12-10 SWEBOK® Guide V3.0
2.15. Replacement and Retirement Decisions A business goal relates business needs (such as
[1*, c12] [2*, c9] increasing profitability) to investing resources
(such as starting a project or launching a prod-
A replacement decision is made when an organi- uct with a given budget, content, and timing).
zation already has a particular asset and they are Goals apply to operational planning (for instance,
considering replacing it with something else; for to reach a certain milestone at a given date or to
example, deciding between maintaining and sup- extend software testing by some time to achieve a
porting a legacy software product or redeveloping desired quality level—see Key Issues in the Soft-
it from the ground up. Replacement decisions use ware Testing KA) and to the strategic level (such
the same business decision process as described as reaching a certain profitability or market share
above, but there are additional challenges: sunk in a stated time period).
cost and salvage value. Retirement decisions are An estimate is a well-founded evaluation of
also about getting out of an activity altogether, resources and time that will be needed to achieve
such as when a software company considers not stated goals (see Effort, Schedule, and Cost Esti-
selling a software product anymore or a hardware mation in the Software Engineering Management
manufacturer considers not building and selling a KA and Maintenance Cost Estimation in the Soft-
particular model of computer any longer. Retire- ware Maintenance KA). A software estimate is
ment decision can be influenced by lock-in fac- used to determine whether the project goals can
tors such as technology dependency and high exit be achieved within the constraints on schedule,
costs. budget, features, and quality attributes. Estimates
are typically internally generated and are not
3. Risk and Uncertainty necessarily visible externally. Estimates should
not be driven exclusively by the project goals
3.1. Goals, Estimates, and Plans because this could make an estimate overly opti-
[3*, c6] mistic. Estimation is a periodic activity; estimates
should be continually revised during a project.
Goals in software engineering economics are A plan describes the activities and milestones
mostly business goals (or business objectives). that are necessary in order to reach the goals of
Software Engineering Economics 12-11
The minimum acceptable rate of return (MARR) Cost-benefit analysis is one of the most widely
is the lowest internal rate of return the organi- used methods for evaluating individual propos-
zation would consider to be a good investment. als. Any proposal with a benefit-cost ratio of less
Generally speaking, it wouldn’t be smart to invest than 1.0 can usually be rejected without further
in an activity with a return of 10% when there’s analysis because it would cost more than the ben-
another activity that’s known to return 20%. efit. Proposals with a higher ratio need to con-
The MARR is a statement that an organization sider the associated risk of an investment and
is confident it can achieve at least that rate of compare the benefits with the option of investing
return. The MARR represents the organization’s the money at a guaranteed interest rate (see sec-
opportunity cost for investments. By choosing tion 4.2, Minimum Acceptable Rate of Return).
to invest in some activity, the organization is
explicitly deciding to not invest that same money 4.6. Cost-Effectiveness Analysis
somewhere else. If the organization is already [1*, c18]
confident it can get some known rate of return,
other alternatives should be chosen only if their Cost-effectiveness analysis is similar to cost-
rate of return is at least that high. A simple way benefit analysis. There are two versions of cost-
to account for that opportunity cost is to use the effectiveness analysis: the fixed-cost version
MARR as the interest rate in business decisions. maximizes the benefit given some upper bound
An alternative’s present worth evaluated at the on cost; the fixed-effectiveness version minimizes
MARR shows how much more or less (in pres- the cost needed to achieve a fixed goal.
ent-day cash terms) that alternative is worth than
investing at the MARR. 4.7. Break-Even Analysis
[1*, c19]
4.3. Return on Investment
[1*, c10] Break-even analysis identifies the point where
the costs of developing a product and the revenue
Return on investment (ROI) is a measure of the to be generated are equal. Such an analysis can
profitability of a company or business unit. It be used to choose between different proposals at
is defined as the ratio of money gained or lost different estimated costs and revenue. Given esti-
(whether realized or unrealized) on an investment mated costs and revenue of two or more propos-
relative to the amount of money invested. The als, break-even analysis helps in choosing among
purpose of ROI varies and includes, for instance, them.
providing a rationale for future investments and
acquisition decisions. 4.8. Business Case
[1*, c3]
4.4. Return on Capital Employed
The business case is the consolidated information
The return on capital employed (ROCE) is a mea- summarizing and explaining a business proposal
sure of the profitability of a company or business from different perspectives for a decision maker
unit. It is defined as the ratio of a gross profit (cost, benefit, risk, and so on). It is often used
before taxes and interest (EBIT) to the total assets to assess the potential value of a product, which
minus current liabilities. It describes the return on can be used as a basis in the investment decision-
the used capital. making process. As opposed to a mere profit-
loss calculation, the business case is a “case” of
plans and analyses that is owned by the product
12-14 SWEBOK® Guide V3.0
manager and used in support of achieving the find the point where overall performance is best.
business objectives. Software’s classic space-time tradeoff is an
example of optimization; an algorithm that runs
4.9. Multiple Attribute Evaluation faster will often use more memory. Optimization
[1*, c26] balances the value of the faster runtime against
the cost of the additional memory.
The topics discussed so far are used to make deci- Real options analysis can be used to quantify
sions based on a single decision criterion: money. the value of project choices, including the value
The alternative with the best present worth, the of delaying a decision. Such options are difficult
best ROI, and so forth is the one selected. Aside to compute with precision. However, awareness
from technical feasibility, money is almost that choices have a monetary value provides
always the most important decision criterion, but insight in the timing of decisions such as increas-
it’s not always the only one. Quite often there are ing project staff or lengthening time to market to
other criteria, other “attributes,” that need to be improve quality.
considered, and those attributes can’t be cast in
terms of money. Multiple attribute decision tech- 5. Practical Considerations
niques allow other, nonfinancial criteria to be fac-
tored into the decision. 5.1. The “Good Enough” Principle
There are two families of multiple attribute [1*, c21]
decision techniques that differ in how they use
the attributes in the decision. One family is the Often software engineering projects and products
“compensatory,” or single-dimensioned, tech- are not precise about the targets that should be
niques. This family collapses all of the attributes achieved. Software requirements are stated, but
onto a single figure of merit. The family is called the marginal value of adding a bit more function-
compensatory because, for any given alternative, ality cannot be measured. The result could be late
a lower score in one attribute can be compensated delivery or too-high cost. The “good enough”
by—or traded off against—a higher score in other principle relates marginal value to marginal cost
attributes. The compensatory techniques include and provides guidance to determine criteria when
a deliverable is “good enough” to be delivered.
• nondimensional scaling These criteria depend on business objectives and
• additive weighting on prioritization of different alternatives, such as
• analytic hierarchy process. ranking software requirements, measurable qual-
ity attributes, or relating schedule to product con-
In contrast, the other family is the “noncom- tent and cost.
pensatory,” or fully dimensioned, techniques. The RACE principle (reduce accidents and
This family does not allow tradeoffs among the control essence) is a popular rule towards good
attributes. Each attribute is treated as a separate enough software. Accidents imply unnecessary
entity in the decision process. The noncompensa- overheads such as gold-plating and rework due
tory techniques include to late defect removal or too many requirements
changes. Essence is what customers pay for. Soft-
• dominance ware engineering economics provides the mech-
• satisficing anisms to define criteria that determine when a
• lexicography. deliverable is “good enough” to be delivered.
It also highlights that both words are relevant:
4.10. Optimization Analysis “good” and “enough.” Insufficient quality or
[1*, c20] insufficient quantity is not good enough.
Agile methods are examples of “good enough”
The typical use of optimization analysis is to that try to optimize value by reducing the over-
study a cost function over a range of values to head of delayed rework and the gold plating that
Software Engineering Economics 12-15
results from adding features that have low mar- In a typical ecosystem, there are producers and
ginal value for the users (see Agile Methods in consumers, where the consumers add value to
the Software Engineering Models and Methods the consumed resources. Note that a consumer is
KA and Software Life Cycle Models in the Soft- not the end user but an organization that uses the
ware Engineering Process KA). In agile meth- product to enhance it. A software ecosystem is,
ods, detailed planning and lengthy development for instance, a supplier of an application working
phases are replaced by incremental planning and with companies doing the installation and sup-
frequent delivery of small increments of a deliv- port in different regions. Neither one could exist
erable product that is tested and evaluated by user without the other. Ecosystems can be permanent
representatives. or temporary. Software engineering economics
provides the mechanisms to evaluate alternatives
5.2. Friction-Free Economy in establishing or extending an ecosystem—for
instance, assessing whether to work with a spe-
Economic friction is everything that keeps mar- cific distributor or have the distribution done by a
kets from having perfect competition. It involves company doing service in an area.
distance, cost of delivery, restrictive regulations,
and/or imperfect information. In high-friction 5.4. Offshoring and Outsourcing
markets, customers don’t have many suppliers
from which to choose. Having been in a business Offshoring means executing a business activity
for a while or owning a store in a good location beyond sales and marketing outside the home
determines the economic position. It’s hard for country of an enterprise. Enterprises typically
new competitors to start business and compete. either have their offshoring branches in low-
The marketplace moves slowly and predictably. cost countries or they ask specialized companies
Friction-free markets are just the reverse. New abroad to execute the respective activity. Offshor-
competitors emerge and customers are quick to ing should therefore not be confused with out-
respond. The marketplace is anything but predict- sourcing. Offshoring within a company is called
able. Theoretically, software and IT are friction- captive offshoring. Outsourcing is the result-ori-
free. New companies can easily create products ented relationship with a supplier who executes
and often do so at a much lower cost than estab- business activities for an enterprise when, tra-
lished companies, since they need not consider ditionally, those activities were executed inside
any legacies. Marketing and sales can be done the enterprise. Outsourcing is site-independent.
via the Internet and social networks, and basi- The supplier can reside in the neighborhood of
cally free distribution mechanisms can enable a the enterprise or offshore (outsourced offshor-
ramp up to a global business. Software engineer- ing). Software engineering economics provides
ing economics aims to provide foundations to the basic criteria and business tools to evaluate
judge how a software business performs and how different sourcing mechanisms and control their
friction-free a market actually is. For instance, performance. For instance, using an outsourcing
competition among software app developers is supplier for software development and mainte-
inhibited when apps must be sold through an app nance might reduce the cost per hour of software
store and comply with that store’s rules. development, but increase the number of hours
and capital expenses due to an increased need for
5.3. Ecosystems monitoring and communication. (For more infor-
mation on offshoring and outsourcing, see “Out-
An ecosystem is an environment consisting of all sourcing” in Management Issues in the Software
the mutually dependent stakeholders, business Maintenance KA.)
units, and companies working in a particular area.
12-16 SWEBOK® Guide V3.0
Sommerville 2011
Fairley 2009
Tockey 2005
[3*]
[2*]
[1*]
1. Software Engineering Economics
Fundamentals
1.1. Finance c2
1.2. Accounting c15
1.3. Controlling c15
1.4. Cash Flow c3
1.5. Decision-Making Process c2, c4
1.6. Valuation c5, c8
1.7. Inflation c13
1.8. Depreciation c14
1.9. Taxation c16, c17
1.10. Time-Value of Money c5, c11
1.11. Efficiency c1
1.12. Effectiveness c1
1.13. Productivity c23
2. Life Cycle Economics
2.1. Product c22 c6
2.2. Project c22 c1
2.3. Program
2.4. Portfolio
2.5. Product Life Cycle c2 c2
2.6. Project Life Cycle c2 c2
2.7. Proposals c3
2.8. Investment Decisions c4
2.9. Planning Horizon c11
2.10. Price and Pricing c13
2.11. Cost and Costing c15
2.12. Performance Measurement c7, c8
2.13. Earned Value Management c8
2.14. Termination Decisions c11, c12 c9
2.15. Replacement and Retirement Decisions c12 c9
Software Engineering Economics 12-17
Sommerville 2011
Fairley 2009
Tockey 2005
[3*]
[2*]
[1*]
3. Risk and Uncertainty
3.1. Goals, Estimates, and Plans c6
3.2. Estimation Techniques c6
3.3. Addressing Uncertainty c6
3.4. Prioritization c6
3.5. Decisions under Risk c24 c9
3.6. Decisions under Uncertainty c25 c9
4. Economic Analysis Methods
4.1. For-Profit Decision Analysis c10
4.2. Minimum Acceptable Rate of Return c10
4.3. Return on Investment c10
4.4. Return on Capital Employed
4.5. Cost-Benefit Analysis c18
4.6. Cost-Effectiveness Analysis c18
4.7. Break-Even Analysis c19
4.8. Business Case c3
4.9. Multiple Attribute Evaluation c26
4.10. Optimization Analysis c20
5. Practical Considerations
5.1. The “Good Enough” Principle c21
5.2. Friction-Free Economy
5.3. Ecosystems
5.4. Offshoring and Outsourcing
12-18 SWEBOK® Guide V3.0
A Guide to the Project Management Body of [1*] S. Tockey, Return on Software: Maximizing
Knowledge (PMBOK® Guide) [4]. the Return on Your Software Investment,
Addison-Wesley, 2004.
The PMBOK® Guide provides guidelines for
managing individual projects and defines project [2*] J.H. Allen et al., Software Security
management related concepts. It also describes Engineering: A Guide for Project
the project management life cycle and its related Managers, Addison-Wesley, 2008.
processes, as well as the project life cycle. It is
a globally recognized guide for the project man- [3*] R.E. Fairley, Managing and Leading
agement profession. Software Projects, Wiley-IEEE Computer
Society Press, 2009.
Software Extension to the Guide to the Project
Management Body of Knowledge (SWX) [5]. [4] Project Management Institute, A Guide
to the Project Management Body of
SWX provides adaptations and extensions to the Knowledge (PMBOK(R) Guide), 5th ed.,
generic practices of project management docu- Project Management Institute, 2013.
mented in the PMBOK® Guide for managing
software projects. The primary contribution of [5] Project Management Institute and IEEE
this extension to the PMBOK® Guide is descrip- Computer Society, Software Extension
tion of processes that are applicable for managing to the PMBOK® Guide Fifth Edition, ed:
adaptive life cycle software projects. Project Management Institute, 2013.
B.W. Boehm, Software Engineering Economics [6] B.W. Boehm, Software Engineering
[6]. Economics, Prentice-Hall, 1981.
This book is the classic reading on software [7] C. Ebert and R. Dumke, Software
engineering economics. It provides an overview Measurement, Springer, 2007.
of business thinking in software engineering.
Although the examples and figures are dated, it [8] D.J. Reifer, Making the Software Business
still is worth reading. Case: Improvement by the Numbers,
Addison Wesley, 2002.
C. Ebert and R. Dumke, Software Measurement
[7].
COMPUTING FOUNDATIONS
ACRONYMS
13-1
13-2 SWEBOK® Guide V3.0
1.2. Formulating the Real Problem The uniqueness of computer software gives prob-
lem solving a flavor that is distinct from general
Gerard Voland writes, “It is important to recog- engineering problem solving. To solve a problem
nize that a specific problem should be formulated using computers, we must answer the following
if one is to develop a specific solution” [2*]. questions.
This formulation is called the problem statement,
which explicitly specifies what both the problem • How do we figure out what to tell the com-
and the desired outcome are. puter to do?
Although there is no universal way of stat- • How do we convert the problem statement
ing a problem, in general a problem should be into an algorithm?
expressed in such a way as to facilitate the devel- • How do we convert the algorithm into
opment of solutions. Some general techniques machine instructions?
to help one formulate the real problem include
statement-restatement, determining the source The first task in solving a problem using a com-
and the cause, revising the statement, analyzing puter is to determine what to tell the computer to
present and desired state, and using the fresh eye do. There may be many ways to tell the story, but
approach. all should take the perspective of a computer such
13-4 SWEBOK® Guide V3.0
that the computer can eventually solve the prob- “Through abstraction,” according to Voland,
lem. In general, a problem should be expressed “we view the problem and its possible solution
in such a way as to facilitate the development of paths from a higher level of conceptual under-
algorithms and data structures for solving it. standing. As a result, we may become better pre-
The result of the first task is a problem state- pared to recognize possible relationships between
ment. The next step is to convert the problem state- different aspects of the problem and thereby gen-
ment into algorithms that solve the problem. Once erate more creative design solutions” [2*]. This
an algorithm is found, the final step converts the is particularly true in computer science in general
algorithm into machine instructions that form the (such as hardware vs. software) and in software
final solution: software that solves the problem. engineering in particular (data structure vs. data
Abstractly speaking, problem solving using a flow, and so forth).
computer can be considered as a process of prob-
lem transformation—in other words, the step-by- 2.1. Levels of Abstraction
step transformation of a problem statement into
a problem solution. To the discipline of software When abstracting, we concentrate on one “level”
engineering, the ultimate objective of problem of the big picture at a time with confidence that
solving is to transform a problem expressed in we can then connect effectively with levels above
natural language into electrons running around and below. Although we focus on one level,
a circuit. In general, this transformation can be abstraction does not mean knowing nothing about
broken into three phases: the neighboring levels. Abstraction levels do not
necessarily correspond to discrete components
a) Development of algorithms from the prob- in reality or in the problem domain, but to well-
lem statement. defined standard interfaces such as programming
b) Application of algorithms to the problem. APIs. The advantages that standard interfaces
c) Transformation of algorithms to program provide include portability, easier software/hard-
code. ware integration and wider usage.
at different times—in other words, we work on dif- perform a desired function. It is an indispensible
ferent levels of abstraction as the situation calls. part in software construction. In general, pro-
Most of the time, these different levels of abstrac- gramming can be considered as the process of
tion are organized in a hierarchy. There are many designing, writing, testing, debugging, and main-
ways to structure a particular hierarchy and the taining the source code. This source code is writ-
criteria used in determining the specific content of ten in a programming language.
each layer in the hierarchy varies depending on the The process of writing source code often
individuals performing the work. requires expertise in many different subject
Sometimes, a hierarchy of abstraction is sequen- areas—including knowledge of the application
tial, which means that each layer has one and only domain, appropriate data structures, special-
one predecessor (lower) layer and one and only ized algorithms, various language constructs,
one successor (upper) layer—except the upmost good programming techniques, and software
layer (which has no successor) and the bottommost engineering.
layer (which has no predecessor). Sometimes,
however, the hierarchy is organized in a tree-like 3.1. The Programming Process
structure, which means each layer can have more
than one predecessor layer but only one successor Programming involves design, writing, testing,
layer. Occasionally, a hierarchy can have a many- debugging, and maintenance. Design is the con-
to-many structure, in which each layer can have ception or invention of a scheme for turning a
multiple predecessors and successors. At no time, customer requirement for computer software into
shall there be any loop in a hierarchy. operational software. It is the activity that links
A hierarchy often forms naturally in task decom- application requirements to coding and debug-
position. Often, a task analysis can be decomposed ging. Writing is the actual coding of the design
in a hierarchical fashion, starting with the larger in an appropriate programming language. Testing
tasks and goals of the organization and breaking is the activity to verify that the code one writes
each of them down into smaller subtasks that can actually does what it is supposed to do. Debug-
again be further subdivided This continuous divi- ging is the activity to find and fix bugs (faults) in
sion of tasks into smaller ones would produce a the source code (or design). Maintenance is the
hierarchical structure of tasks-subtasks. activity to update, correct, and enhance existing
programs. Each of these activities is a huge topic
2.4. Alternate Abstractions and often warrants the explanation of an entire
KA in the SWEBOK Guide and many books.
Sometimes it is useful to have multiple alternate
abstractions for the same problem so that one can 3.2. Programming Paradigms
keep different perspectives in mind. For exam-
ple, we can have a class diagram, a state chart, Programming is highly creative and thus some-
and a sequence diagram for the same software what personal. Different people often write dif-
at the same level of abstraction. These alternate ferent programs for the same requirements. This
abstractions do not form a hierarchy but rather diversity of programming causes much difficulty
complement each other in helping understanding in the construction and maintenance of large
the problem and its solution. Though beneficial, it complex software. Various programming para-
is as times difficult to keep alternate abstractions digms have been developed over the years to put
in sync. some standardization into this highly creative and
personal activity. When one programs, he or she
3. Programming Fundamentals can use one of several programming paradigms to
[3*, c6–19] write the code. The major types of programming
paradigms are discussed below.
Programming is composed of the methodologies Unstructured Programming: In unstructured
or activities for creating computer programs that programming, a programmer follows his/her
13-6 SWEBOK® Guide V3.0
hunch to write the code in whatever way he/she problems. In functional programming, all com-
likes as long as the function is operational. Often, putations are treated as the evaluation of math-
the practice is to write code to fulfill a specific ematical functions. In contrast to the imperative
utility without regard to anything else. Programs programming that emphasizes changes in state,
written this way exhibit no particular structure— functional programming emphasizes the applica-
thus the name “unstructured programming.” tion of functions, avoids state and mutable data,
Unstructured programming is also sometimes and provides referential transparency.
called ad hoc programming.
Structured/Procedural/ Imperative Program- 4. Programming Language Basics
ming: A hallmark of structured programming is [4*, c6]
the use of well-defined control structures, includ-
ing procedures (and/or functions) with each pro- Using computers to solve problems involves
cedure (or function) performing a specific task. programming—which is writing and organiz-
Interfaces exist between procedures to facilitate ing instructions telling the computer what to do
correct and smooth calling operations of the pro- at each step. Programs must be written in some
grams. Under structured programming, program- programming language with which and through
mers often follow established protocols and rules which we describe necessary computations. In
of thumb when writing code. These protocols other words, we use the facilities provided by a
and rules can be numerous and cover almost the programming language to describe problems,
entire scope of programming—ranging from the develop algorithms, and reason about problem
simplest issue (such as how to name variables, solutions. To write any program, one must under-
functions, procedures, and so forth) to more com- stand at least one programming language.
plex issues (such as how to structure an interface,
how to handle exceptions, and so forth). 4.1. Programming Language Overview
Object-Oriented Programming: While proce-
dural programming organizes programs around A programming language is designed to express
procedures, object-oriented programming (OOP) computations that can be performed by a com-
organize a program around objects, which are puter. In a practical sense, a programming lan-
abstract data structures that combine both data guage is a notation for writing programs and thus
and methods used to access or manipulate the should be able to express most data structures and
data. The primary features of OOP are that objects algorithms. Some, but not all, people restrict the
representing various abstract and concrete entities term “programming language” to those languages
are created and these objects interact with each that can express all possible algorithms.
other to collectively fulfill the desired functions. Not all languages have the same importance
Aspect-Oriented Programming: Aspect-ori- and popularity. The most popular ones are often
ented programming (AOP) is a programming defined by a specification document established
paradigm that is built on top of OOP. AOP aims by a well-known and respected organization. For
to isolate secondary or supporting functions from example, the C programming language is speci-
the main program’s business logic by focusing fied by an ISO standard named ISO/IEC 9899.
on the cross sections (concerns) of the objects. Other languages, such as Perl and Python, do not
The primary motivation for AOP is to resolve enjoy such treatment and often have a dominant
the object tangling and scattering associated with implementation that is used as a reference.
OOP, in which the interactions among objects
become very complex. The essence of AOP is 4.2. Syntax and Semantics of Programming
the greatly emphasized separation of concerns, Languages
which separates noncore functional concerns or
logic into various aspects. Just like natural languages, many programming
Functional Programming: Though less popu- languages have some form of written specifica-
lar, functional programming is as viable as tion of their syntax (form) and semantics (mean-
the other paradigms in solving programming ing). Such specifications include, for example,
Computing Foundations 13-7
Both commercial and free tools exist in various 6.2. Types of Data Structure
languages. These tools can be extremely useful
when checking very large source trees, where it is As mentioned above, different perspectives can
impractical to do code walkthroughs. The UNIX be used to classify data structures. However, the
lint program is an early example. predominant perspective used in classification
centers on physical and logical ordering between
6. Data Structure and Representation data items. This classification divides data struc-
[5*, s2.1–2.6] tures into linear and nonlinear structures. Linear
structures organize data items in a single dimen-
Programs work on data. But data must be sion in which each data entry has one (physical
expressed and organized within computers before or logical) predecessor and one successor with
being processed by programs. This organization the exception of the first and last entry. The first
and expression of data for programs’ use is the entry has no predecessor and the last entry has
subject of data structure and representation. Sim- no successor. Nonlinear structures organize data
ply put, a data structure tries to store and organize items in two or more dimensions, in which case
data in a computer in such a way that the data can one entry can have multiple predecessors and
be used efficiently. There are many types of data successors. Examples of linear structures include
structures and each type of structure is suitable lists, stacks, and queues. Examples of nonlinear
for some kinds of applications. For example, B/ structures include heaps, hash tables, and trees
B+ trees are well suited for implementing mas- (such as binary trees, balance trees, B-trees, and
sive file systems and databases. so forth).
Another type of data structure that is often
6.1. Data Structure Overview encountered in programming is the compound
structure. A compound data structure builds on
Data structures are computer representations of top of other (more primitive) data structures and,
data. Data structures are used in almost every pro- in some way, can be viewed as the same structure
gram. In a sense, no meaningful program can be as the underlying structure. Examples of com-
constructed without the use of some sort of data pound structures include sets, graphs, and parti-
structure. Some design methods and program- tions. For example, a partition can be viewed as
ming languages even organize an entire software a set of sets.
system around data structures. Fundamentally,
data structures are abstractions defined on a col- 6.3. Operations on Data Structures
lection of data and its associated operations.
Often, data structures are designed for improv- All data structures support some operations that
ing program or algorithm efficiency. Examples of produce a specific structure and ordering, or
such data structures include stacks, queues, and retrieve relevant data from the structure, store data
heaps. At other times, data structures are used for into the structure, or delete data from the structure.
conceptual unity (abstract data type), such as the Basic operations supported by all data structures
name and address of a person. Often, a data struc- include create, read, update, and delete (CRUD).
ture can determine whether a program runs in a
few seconds or in a few hours or even a few days. • Create: Insert a new data entry into the
From the perspective of physical and logi- structure.
cal ordering, a data structure is either linear or • Read: Retrieve a data entry from the structure.
nonlinear. Other perspectives give rise to dif- • Update: Modify an existing data entry.
ferent classifications that include homogeneous • Delete: Remove a data entry from the
vs. heterogeneous, static vs. dynamic, persistent structure.
vs. transient, external vs. internal, primitive vs.
aggregate, recursive vs. nonrecursive; passive vs. Some data structures also support additional
active; and stateful vs. stateless structures. operations:
13-10 SWEBOK® Guide V3.0
Programs are not random pieces of code: they are 7.3. Algorithmic Analysis
meticulously written to perform user-expected
actions. The guide one uses to compose programs Analysis of algorithms is the theoretical study
are algorithms, which organize various functions of computer-program performance and resource
into a series of steps and take into consideration usage; to some extent it determines the goodness
the application domain, the solution strategy, and of an algorithm. Such analysis usually abstracts
the data structures being used. An algorithm can away the particular details of a specific computer
be very simple or very complex. and focuses on the asymptotic, machine-indepen-
dent analysis.
7.1. Overview of Algorithms There are three basic types of analysis. In
worst-case analysis, one determines the maxi-
Abstractly speaking, algorithms guide the opera- mum time or resources required by the algorithm
tions of computers and consist of a sequence of on any input of size n. In average-case analysis,
actions composed to solve a problem. Alternative one determines the expected time or resources
definitions include but are not limited to: required by the algorithm over all inputs of size
n; in performing average-case analysis, one often
• An algorithm is any well-defined computa- needs to make assumptions on the statistical dis-
tional procedure that takes some value or set tribution of inputs. The third type of analysis is
of values as input and produces some value the best-case analysis, in which one determines
or set of values as output. the minimum time or resources required by the
• An algorithm is a sequence of computational algorithm on any input of size n. Among the
steps that transform the input into the output. three types of analysis, average-case analysis is
• An algorithm is a tool for solving a well- the most relevant but also the most difficult to
specified computation problem. perform.
Besides the basic analysis methods, there are
Of course, different definitions are favored also the amortized analysis, in which one deter-
by different people. Though there is no univer- mines the maximum time required by an algo-
sally accepted definition, some agreement exists rithm over a sequence of operations; and the
that an algorithm needs to be correct, finite (in competitive analysis, in which one determines
other words, terminate eventually or one must be the relative performance merit of an algorithm
able to write it in a finite number of steps), and against the optimal algorithm (which may not
unambiguous. be known) in the same category (for the same
operations).
Computing Foundations 13-11
Figure 13.3. Basic Components of a Computer System Based on the von Neumann Model
9. Computer Organization the ISA, which specifies such things as the native
[8*, c1–c4] data types, instructions, registers, addressing
modes, the memory architecture, interrupt and
From the perspective of a computer, a wide exception handling, and the I/Os. Overall, the
semantic gap exists between its intended behav- ISA specifies the ability of a computer and what
ior and the workings of the underlying electronic can be done on the computer with programming.
devices that actually do the work within the com-
puter. This gap is bridged through computer orga- 9.2. Digital Systems
nization, which meshes various electrical, elec-
tronic, and mechanical devices into one device At the lowest level, computations are carried out
that forms a computer. The objects that computer by the electrical and electronic devices within a
organization deals with are the devices, connec- computer. The computer uses circuits and mem-
tions, and controls. The abstraction built in com- ory to hold charges that represents the presence
puter organization is the computer. or absence of voltage. The presence of voltage
is equal to a 1 while the absence of voltage is a
9.1. Computer Organization Overview zero. On disk the polarity of the voltage is repre-
sented by 0s and 1s that in turn represents the data
A computer generally consists of a CPU, mem- stored. Everything—including instruction and
ory, input devices, and output devices. Abstractly data—is expressed or encoded using digital zeros
speaking, the organization of a computer can be and ones. In this sense, a computer becomes a
divided into four levels (Figure 13.4). The macro digital system. For example, decimal value 6 can
architecture level is the formal specification of all be encoded as 110, the addition instruction may
the functions a particular machine can carry out be encoded as 0001, and so forth. The component
and is known as the instruction set architecture of the computer such as the control unit, ALU,
(ISA). The micro architecture level is the imple- memory and I/O use the information to compute
mentation of the ISA in a specific CPU—in other the instructions.
words, the way in which the ISA’s specifications
are actually carried out. The logic circuits level 9.3. Digital Logic
is the level where each functional component
of the micro architecture is built up of circuits Obviously, logics are needed to manipulate data
that make decisions based on simple rules. The and to control the operation of computers. This
devices level is the level where, finally, each logic logic, which is behind a computer’s proper func-
circuit is actually built of electronic devices such tion, is called digital logic because it deals with
as complementary metal-oxide semiconductors the operations of digital zeros and ones. Digital
(CMOS), n-channel metal oxide semiconductors logic specifies the rules both for building various
(NMOS), or gallium arsenide (GaAs) transistors, digital devices from the simplest elements (such
and so forth. as transistors) and for governing the operation of
digital devices. For example, digital logic spells
Macro Architecture Level (ISA) out what the value will be if a zero and one is
Micro Architecture Level ANDed, ORed, or exclusively ORed together. It
also specifies how to build decoders, multiplex-
Logic Circuits Level
ers (MUX), memory, and adders that are used to
Devices Level assemble the computer.
Each level provides an abstraction to the level As mentioned before, a computer expresses data
above and is dependent on the level below. To a with electrical signals or digital zeros and ones.
programmer, the most important abstraction is Since there are only two different digits used in
13-14 SWEBOK® Guide V3.0
data expression, such a system is called a binary • Memory cells and chips
expression system. Due to the inherent nature of • Memory boards and modules
a binary system, the maximum numerical value • Memory hierarchy and cache
expressible by an n-bits binary code is 2n − 1. • Memory as a subsystem of the computer.
Specifically, binary number anan−1…a1a0 corre-
sponds to an × 2n + an−1 × 2n−1 + … + a1 × 21 + Memory cells and chips deal with single-digital
a0 × 20. Thus, the numerical value of the binary storage and the assembling of single-digit units
expression of 1011 is 1 × 8 + 0 × 4 + 1 × 2 + 1 into one-dimensional memory arrays as well
× 1 = 11. To express a nonnumerical value, we as the assembling of one-dimensional storage
need to decide the number of zeros and ones to arrays into multi-dimensional storage memory
use and the order in which those zeros and ones chips. Memory boards and modules concern the
are arranged. assembling of memory chips into memory sys-
Of course, there are different ways to do the tems, with the focus being on the organization,
encoding, and this gives rise to different data operation, and management of the individual
expression schemes and subschemes. For example, chips in the system. Memory hierarchy and cache
integers can be expressed in the form of unsigned, are used to support efficient memory operations.
one’s complement, or two’s complement. For Memory as a sub-system deals with the interface
characters, there are ASCII, Unicode, and IBM’s between the memory system and other parts of
EBCDIC standards. For floating point numbers, the computer.
there are IEEE-754 FP 1, 2, and 3 standards.
9.7. Input and Output (I/O)
9.5. The Central Processing Unit (CPU)
A computer is useless without I/O. Common
The central processing unit is the place where input devices include the keyboard and mouse;
instructions (or programs) are actually executed. common output devices include the disk, the
The execution usually takes several steps, includ- screen, the printer, and speakers. Different I/O
ing fetching the program instruction, decoding devices operate at different data rates and reli-
the instruction, fetching operands, performing abilities. How computers connect and manage
arithmetic and logical operations on the oper- various input and output devices to facilitate the
ands, and storing the result. The main compo- interaction between computers and humans (or
nents of a CPU consist of registers where instruc- other computers) is the focus of topics in I/O.
tions and data are often read from and written to, The main issues that must be resolved in input
the arithmetic and logic unit (ALU) that performs and output are the ways I/O can and should be
the actual arithmetic (such as addition, subtrac- performed.
tion, multiplication, and division) and logic (such In general, I/O is performed at both hard-
as AND, OR, shift, and so forth) operations, the ware and software levels. Hardware I/O can be
control unit that is responsible for producing performed in any of three ways. Dedicated I/O
proper signals to control the operations, and vari- dedicates the CPU to the actual input and output
ous (data, address, and control) buses that link the operations during I/O; memory-mapped I/O treats
components together and transport data to and I/O operations as memory operations; and hybrid
from these components. I/O combines dedicated I/O and memory-mapped
I/O into a single holistic I/O operation mode.
9.6. Memory System Organization Coincidentally, software I/O can also be per-
formed in one of three ways. Programmed I/O
Memory is the storage unit of a computer. It con- lets the CPU wait while the I/O device is doing
cerns the assembling of a large-scale memory I/O; interrupt-driven I/O lets the CPU’s handling
system from smaller and single-digit storage of I/O be driven by the I/O device; and direct
units. The main topics covered by memory sys- memory access (DMA) lets I/O be handled by a
tem architecture include the following: secondary CPU embedded in a DMA device (or
Computing Foundations 13-15
channel). (Except during the initial setup, the there are some important differences between the
main CPU is not disturbed during a DMA I/O two methods. First, a compiler makes the conver-
operation.) sion just once, while an interpreter typically con-
Regardless of the types of I/O scheme being verts it every time a program is executed. Second,
used, the main issues involved in I/O include I/O interpreting code is slower than running the com-
addressing (which deals with the issue of how to piled code, because the interpreter must analyze
identify the I/O device for a specific I/O opera- each statement in the program when it is executed
tion), synchronization (which deals with the issue and then perform the desired action, whereas the
of how to make the CPU and I/O device work compiled code just performs the action within
in harmony during I/O), and error detection and a fixed context determined by the compilation.
correction (which deals with the occurrence of Third, access to variables is also slower in an
transmission errors). interpreter because the mapping of identifiers to
storage locations must be done repeatedly at run-
10. Compiler Basics time rather than at compile time.
[4*, s6.4] [8*, s8.4] The primary tasks of a compiler may include
preprocessing, lexical analysis, parsing, semantic
10.1. Compiler/Interpreter Overview analysis, code generation, and code optimiza-
tion. Program faults caused by incorrect compiler
Programmers usually write programs in high behavior can be very difficult to track down. For
level language code, which the CPU cannot exe- this reason, compiler implementers invest a lot of
cute; so this source code has to be converted into time ensuring the correctness of their software.
machine code to be understood by a computer.
Due to the differences between different ISAs, 10.3. The Compilation Process
the translation must be done for each ISA or spe-
cific machine language under consideration. Compilation is a complex task. Most compilers
The translation is usually performed by a piece divide the compilation process into many phases.
of software called a compiler or an interpreter. A typical breakdown is as follows:
This process of translation from a high-level lan-
guage to a machine language is called compila- • Lexical Analysis
tion, or, sometimes, interpretation. • Syntax Analysis or Parsing
• Semantic Analysis
10.2. Interpretation and Compilation • Code Generation
There are two ways to translate a program writ- Lexical analysis partitions the input text (the
ten in a higher-level language into machine code: source code), which is a sequence of characters,
interpretation and compilation. Interpretation into separate comments, which are to be ignored
translates the source code one statement at a time in subsequent actions, and basic symbols, which
into machine language, executes it on the spot, have lexical meanings. These basic symbols
and then goes back for another statement. Both must correspond to some terminal symbols of
the high-level-language source code and the inter- the grammar of the particular programming lan-
preter are required every time the program is run. guage. Here terminal symbols refer to the ele-
Compilation translates the high-level-language mentary symbols (or tokens) in the grammar that
source code into an entire machine-language pro- cannot be changed.
gram (an executable image) by a program called a Syntax analysis is based on the results of the
compiler. After compilation, only the executable lexical analysis and discovers the structure in the
image is needed to run the program. Most appli- program and determines whether or not a text
cation software is sold in this form. conforms to an expected format. Is this a textu-
While both compilation and interpretation con- ally correct C++ program? or Is this entry tex-
vert high level language code into machine code, tually correct? are typical questions that can be
13-16 SWEBOK® Guide V3.0
Security and protection deal with the protection of • Multiprogrammed batching OS: adds mul-
computer resources from illegal use. titask capability into earlier simple batching
OSs. An example of such an OS is IBM’s
11.3. Operating System Abstractions OS/360.
• Time-sharing OS: adds multi-task and inter-
The arsenal of OSs is abstraction. Corresponding active capabilities into the OS. Examples of
to the five physical tasks, OSs use five abstrac- such OSs include UNIX, Linux, and NT.
tions: process/thread, virtual memory, file sys- • Real-time OS: adds timing predictabil-
tems, input/output, and protection domains. The ity into the OS by scheduling individual
overall OS abstraction is the virtual machine. tasks according to each task’s completion
For each task area of OS, there is both a physi- deadlines. Examples of such OS include
cal reality and a conceptual abstraction. The phys- VxWorks (WindRiver) and DART (EMC).
ical reality refers to the hardware resource under • Distributed OS: adds the capability of man-
management; the conceptual abstraction refers aging a network of computers into the OS.
to the interface the OS presents to the users/pro- • Embedded OS: has limited functionality and
grams above. For example, in the thread model is used for embedded systems such as cars
of the OS, the physical reality is the CPU and the and PDAs. Examples of such OSs include
abstraction is multiple CPUs. Thus, a user doesn’t Palm OS, Windows CE, and TOPPER.
have to worry about sharing the CPU with others
when working on the abstraction provided by an Alternatively, an OS can be classified by its
OS. In the virtual memory abstraction of an OS, applicable target machine/environment into the
the physical reality is the physical RAM or ROM following.
(whatever), the abstraction is multiple unlim-
ited memory space. Thus, a user doesn’t have to • Mainframe OS: runs on the mainframe com-
worry about sharing physical memory with others puters and include OS/360, OS/390, AS/400,
or about limited physical memory size. MVS, and VM.
Abstractions may be virtual or transparent; • Server OS: runs on workstations or servers
in this context virtual applies to something that and includes such systems as UNIX, Win-
appears to be there, but isn’t (like usable memory dows, Linux, and VMS.
beyond physical), whereas transparent applies • Multicomputer OS: runs on multiple com-
to something that is there, but appears not to be puters and include such examples as Novell
there (like fetching memory contents from disk or Netware.
physical memory). • Personal computers OS: runs on personal
computers and include such examples as
11.4. Operating Systems Classification DOS, Windows, Mac OS, and Linux.
• Mobile device OS: runs on personal devices
Different operating systems can have different such as cell phones, IPAD and include such
functionality implementation. In the early days examples of iOS, Android, Symbian, etc.
of the computer era, operating systems were rela-
tively simple. As time goes on, the complexity 12. Database Basics and Data Management
and sophistication of operating systems increases [4*, c9]
significantly. From a historical perspective, an
operating system can be classified as one of the A database consists of an organized collection of
following. data for one or more uses. In a sense, a database is
a generalization and expansion of data structures.
• Batching OS: organizes and processes work But the difference is that a database is usually
in batches. Examples of such OSs include external to individual programs and permanent in
IBM’s FMS, IBSYS, and University of existence compared to data structures. Databases
Michigan’s UMES. are used when the data volume is large or logical
13-18 SWEBOK® Guide V3.0
relations between data items are important. The 12.3. Database Query Language
factors considered in database design include per-
formance, concurrency, integrity, and recovery Users/applications interact with a database
from hardware failures. through a database query language, which is a spe-
cialized programming language tailored to data-
12.1. Entity and Schema base use. The database model tends to determine
the query languages that are available to access
The things a database tries to model and store are the database. One commonly used query lan-
called entities. Entities can be real-world objects guage for the relational database is the structured
such as persons, cars, houses, and so forth, or they query language, more commonly abbreviated as
may be abstract concepts such as persons, salary, SQL. A common query language for object data-
names, and so forth. An entity can be primitive bases is the object query language (abbreviated as
such as a name or composite such as an employee OQL). There are three components of SQL: Data
that consists of a name, identification number, Definition Language (DDL), Data Manipulation
salary, address, and so forth. Language (DML), and Data Control Language
The single most important concept in a database (DCL). An example of an DML query may look
is the schema, which is a description of the entire like the following:
database structure from which all other database
activities are built. A schema defines the relation- SELECT Component_No, Quantity
ships between the various entities that compose a FROM COMPONENT
database. For example, a schema for a company WHERE Item_No = 100
payroll system would consist of such things as
employee ID, name, salary rate, address, and so The above query selects all the Component_No
forth. Database software maintains the database and its corresponding quantity from a database
according to the schema. table called COMPONENT, where the Item_No
Another important concept in database is the equals to 100.
database model that describes the type of rela-
tionship among various entities. The commonly 12.4. Tasks of DBMS Packages
used models include relational, network, and
object models. A DBMS system provides the following
capabilities:
12.2. Database Management Systems (DBMS)
• Database development is used to define and
Database Management System (DBMS) compo- organize the content, relationships, and struc-
nents include database applications for the stor- ture of the data needed to build a database.
age of structured and unstructured data and the • Database interrogation is used for accessing
required database management functions needed the data in a database for information retrieval
to view, collect, store, and retrieve data from the and report generation. End users can selec-
databases. A DBMS controls the creation, main- tively retrieve and display information and
tenance, and use of the database and is usually produce printed reports. This is the operation
categorized according to the database model it that most users know about databases.
supports—such as the relational, network, or • Database Maintenance is used to add, delete,
object model. For example, a relational database update, and correct the data in a database.
management system (RDBMS) implements fea- • Application Development is used to develop
tures of the relational model. An object database prototypes of data entry screens, queries,
management system (ODBMS) implements fea- forms, reports, tables, and labels for a proto-
tures of the object model. typed application. It also refers to the use of
4th Generation Language or application gen-
erators to develop or generate program code.
Computing Foundations 13-19
interface cards (NICs), bridges, hubs, switches, link layer protocols include frame-relay, asyn-
and routers. All these components are called nodes chronous transfer mode (ATM), and Point-to-
in the jargon of networking. Each component per- Point Protocol (PPP). Application layer protocols
forms a distinctive function that is essential for include Fibre channel, Small Computer System
the packaging, connection, transmission, amplifi- Interface (SCSI), and Bluetooth. For each layer
cation, controlling, unpacking, and interpretation or even each individual protocol, there may be
of the data. For example, a repeater amplifies the standards established by national or international
signals, a switch performs many-to-many connec- organizations to guide the design and develop-
tions, a hub performs one-to-many connections, ment of the corresponding protocols.
an interface card is attached to the computer and
performs data packing and transmission, a bridge Application Layer
connects one network with another, and a router is Presentation Layer
a computer itself and performs data analysis and
Session Layer
flow control to regulate the data from the network.
The functions performed by various network Transport Layer
components correspond to the functions specified Network Layer
by one or more levels of the seven-layer Open Data link Layer
Systems Interconnect (OSI) networking model,
Physical Layer
which is discussed below.
13.3. Networking Protocols and Standards Figure 13.5. The Seven-Layer OSI Networking Model
Different ways of coordination give rise to differ- 15. Basic User Human Factors
ent computing models. The most common mod- [3*, c8] [9*, c5]
els in this regard are the shared memory (paral-
lel) model and the message-passing (distributed) Software is developed to meet human desires or
model. needs. Thus, all software design and develop-
In a shared memory (parallel) model, all com- ment must take into consideration human-user
puters have access to a shared central memory factors such as how people use software, how
where local caches are used to speed up the people view software, and what humans expect
processing power. These caches use a protocol from software. There are numerous factors in the
to insure the localized data is fresh and up to human-machine interaction, and ISO 9241 docu-
date, typically the MESI protocol. The algorithm ment series define all the detailed standards of
designer chooses the program for execution by such interactions.[10] But the basic human-user
each computer. Access to the central memory can factors considered here include input/output, the
be synchronous or asynchronous, and must be handling of error messages, and the robustness of
coordinated such that coherency is maintained. the software in general.
Different access models have been invented for
such a purpose. 15.1. Input and Output
In a message-passing (distributed) model, all
computers run some programs that collectively Input and output are the interfaces between users
achieve some purpose. The system must work and software. Software is useless without input
correctly regardless of the structure of the net- and output. Humans design software to process
work. This model can be further classified into some input and produce desirable output. All
client-server (C/S), browser-server (B/S), and software engineers must consider input and out-
n-tier models. In the C/S model, the server pro- put as an integral part of the software product
vides services and the client requests services they engineer or develop. Issues considered for
from the server. In the B/S model, the server pro- input include (but are not limited to):
vides services and the client is the browser. In the
n-tier model, each tier (i.e. layer) provides ser- • What input is required?
vices to the tier immediately above it and requests • How is the input passed from users to
services from the tier immediately below it. In computers?
fact, the n-tier model can be seen as a chain of • What is the most convenient way for users to
client-server models. Often, the tiers between the enter input?
bottommost tier and the topmost tier are called • What format does the computer require of
middleware, which is a distinct subject of study the input data?
in its own right.
The designer should request the minimum
14.4. Main Issues in Distributed Computing data from human input, only when the data is not
already stored in the system. The designer should
Coordination among all the components in a dis- format and edit the data at the time of entry to
tributed computing environment is often complex reduce errors arising from incorrect or malicious
and time-consuming. As the number of cores/ data entry.
CPUs/computers increases, the complexity of For output, we need to consider what the users
distributed computing also increases. Among wish to see:
the many issues faced, memory coherency and
consensus among all computers are the most dif- • In what format would users like to see
ficult ones. Many computation paradigms have output?
been invented to solve these problems and are • What is the most pleasing way to display
the main discussion issues in distributed/parallel output?
computing.
Computing Foundations 13-23
16.2. Comments
17. Secure Software Development and
To most people, programming is coding. These Maintenance
people do not realize that programming also [11*, c29]
includes writing comments and that comments are
an integral part of programming. True, comments Due to increasing malicious activities targeted
are not used by the computer and certainly do not at computer systems, security has become a sig-
constitute final instructions for the computer, but nificant issue in the development of software. In
they improve the readability of the programs by addition to the usual correctness and reliability,
explaining the meaning and logic of the statements software developers must also pay attention to
or sections of code. It should be remembered that the security of the software they develop. Secure
programs are not only meant for computers, they software development builds security in software
are also read, written, and modified by humans. by following a set of established and/or recom-
The types of comments include repeat of the mended rules and practices in software develop-
code, explanation of the code, marker of the ment. Secure software maintenance complements
code, summary of the code, description of the secure software development by ensuring the no
code’s intent, and information that cannot possi- security problems are introduced during software
bly be expressed by the code itself. Some com- maintenance.
ments are good, some are not. The good ones A generally accepted view concerning software
are those that explain the intent of the code and security is that it is much better to design security
justify why this code looks the way it does. The into software than to patch it in after software is
bad ones are repeat of the code and stating irrel- developed. To design security into software, one
evant information. The best comments are self- must take into consideration every stage of the soft-
documenting code. If the code is written in such a ware development lifecycle. In particular, secure
clear and precise manner that its meaning is self- software development involves software require-
proclaimed, then no comment is needed. But this ments security, software design security, software
is easier said than done. Most programs are not construction security, and software testing secu-
self-explanatory and are often hard to read and rity. In addition, security must also be taken into
understand if no comments are given. consideration when performing software mainte-
Here are some general guidelines for writing nance as security faults and loopholes can be and
good comments: often are introduced during maintenance.
lays the foundation for security considerations in • Structure the process so that all sections
the software development. Factors to consider requiring extra privileges are modules. The
in this phase include software requirements and modules should be as small as possible and
threats/risks. The former refers to the specific should perform only those tasks that require
functions that are required for the sake of secu- those privileges.
rity; the latter refers to the possible ways that the • Ensure that any assumptions in the program
security of software is threatened. are validated. If this is not possible, docu-
ment them for the installers and maintainers
17.2. Software Design Security so they know the assumptions that attackers
will try to invalidate.
Software Design security deals with the design • Ensure that the program does not share
of software modules that fit together to meet objects in memory with any other program.
the security objectives specified in the security • The error status of every function must be
requirements. This step clarifies the details of checked. Do not try to recover unless neither
security considerations and develops the specific the cause of the error nor its effects affect
steps for implementation. Factors considered any security considerations. The program
may include frameworks and access modes that should restore the state of the software to
set up the overall security monitoring/enforce- the state it had before the process began, and
ment strategies, as well as the individual policy then terminate.
enforcement mechanisms.
17.4. Software Testing Security
17.3. Software Construction Security
Software testing security determines that soft-
Software construction security concerns the ques- ware protects data and maintains security speci-
tion of how to write actual programming code for fication as given. For more information, please
specific situations such that security considerations refer to the Software Testing KA.
are taken care of. The term “Software Construction
Security” could mean different things for different 17.5. Build Security into Software Engineering
people. It can mean the way a specific function is Process
coded, such that the coding itself is secure, or it can
mean the coding of security into software. Software is only as secure as its development
Most people entangle the two together without process goes. To ensure the security of software,
distinction. One reason for such entanglement is security must be built into the software engineer-
that it is not clear how one can make sure that a ing process. One trend that emerges in this regard
specific coding is secure. For example, in C pro- is the Secure Development Lifecycle (SDL) con-
gramming language, the expression of i<<1 (shift cept, which is a classical spiral model that takes
the binary representation of i’s value to the left by a holistic view of security from the perspective
one bit) and 2*i (multiply the value of variable i of software lifecycle and ensures that security is
by constant 2) mean the same thing semantically, inherent in software design and development, not
but do they have the same security ramification? an afterthought later in production. The SDL pro-
The answer could be different for different com- cess is claimed to reduce software maintenance
binations of ISAs and compilers. Due to this lack costs and increase reliability of software concern-
of understanding, software construction secu- ing software security related faults.
rity—in its current state of existence—mostly
refers to the second aspect mentioned above: the 17.6. Software Security Guidelines
coding of security into software.
Coding of security into software can be Although there are no bulletproof ways for secure
achieved by following recommended rules. A few software development, some general guidelines
such rules follow: do exist that can be used to aid such effort. These
13-26 SWEBOK® Guide V3.0
Sommerville 2011
Brookshear 2008
McConnell 2004
Nielsen 1993
Voland 2003
Bishop 2002
[11*]
[8*]
[9*]
[5*]
[3*]
[2*]
[4*]
[6*]
1. Problem Solving s3.2,
Techniques s4.2
1.1. Definition of
s3.2
Problem Solving
1.2. Formulating the
s3.2
Real Problem
1.3. Analyze the
s3.2
Problem
1.4. Design a
Solution Search s4.2
Strategy
1.5. Problem Solving
c5
Using Programs
s5.2–
2. Abstraction
5.4
2.1. Levels of s5.2–
Abstraction 5.3
2.2. Encapsulation s5.3
2.3. Hierarchy s5.2
3. Programming
c6–19
Fundamentals
3.1. The
Programming c6–c19
Process
3.2. Programming
c6–c19
Paradigms
3.3. Defensive
c8
Programming
4. Programming
c6
Language Basics
4.1. Programming
s6.1
Language Overview
4.2. Syntax and
Semantics of
s6.2
Programming
Language
13-28 SWEBOK® Guide V3.0
Sommerville 2011
Brookshear 2008
McConnell 2004
Nielsen 1993
Voland 2003
Bishop 2002
[11*]
[8*]
[9*]
[5*]
[3*]
[2*]
[4*]
[6*]
4.3. Low Level
s6.5–
Programming
6.7
Language
4.4. High Level
s6.5–
Programing
6.7
Language
4.5. Declarative
vs. Imperative s6.5–
Programming 6.7
Language
5. Debugging Tools
c23
and Techniques
5.1. Types of Errors s23.1
5.2. Debugging
s23.2
Techniques:
5.3. Debugging
s23.5
Tools
6. Data Structure and s2.1–
Representation 2.6
6.1. Data Structure s2.1–
Overview 2.6
6.2. Types of Data s2.1–
Structure 2.6
6.3. Operations on s2.1–
Data Structures 2.6
s1.1–
1.3,
s3.3–
3.6,
s4.1–
4.8,
7. Algorithms and s5.1–
Complexity 5.7,
s6.1–
6.3,
s7.1–
7.6,
s11.1,
s12.1
Computing Foundations 13-29
Sommerville 2011
Brookshear 2008
McConnell 2004
Nielsen 1993
Voland 2003
Bishop 2002
[11*]
[8*]
[9*]
[5*]
[3*]
[2*]
[4*]
[6*]
7.1. Overview of
s1.1–1.2
Algorithms
7.2. Attributes of
s1.3
Algorithms
7.3. Algorithmic
s1.3
Analysis
s3.3–
3.6,
s4.1–
4.8,
s5.1–
7.4. Algorithmic 5.7,
Design Strategies s6.1–
6.3,
s7.1–
7.6,
s11.1,
s12.1
s3.3–
3.6,
s4.1–
4.8,
s5.1–
7.5. Algorithmic 5.7,
Analysis Strategies s6.1–
6.3,
s7.1–
7.6,
s11.1,
s12.1
8. Basic Concept of a
c10
System
8.1. Emergent
s10.1
System Properties
8.2. System
s10.2
Engineering
8.3. Overview of a
Computer System
13-30 SWEBOK® Guide V3.0
Sommerville 2011
Brookshear 2008
McConnell 2004
Nielsen 1993
Voland 2003
Bishop 2002
[11*]
[8*]
[9*]
[5*]
[3*]
[2*]
[4*]
[6*]
9. Computer
c1–4
Organization
9.1. Computer
Organization s1.1–1.2
Overview
9.2. Digital Systems c3
9.3. Digital Logic c3
9.4. Computer
c2
Expression of Data
9.5. The Central
s4.1–
Processing Unit
4.2
(CPU)
9.6. Memory System
s4.6
Organization
9.7. Input and Output
s4.5
(I/O)
10. Compiler Basics s6.4 s8.4
10.1. Compiler
s8.4
Overview
10.2. Interpretation
s8.4
and Compilation
10.3. The
s6.4 s8.4
Compilation Process
11. Operating
c3
Systems Basics
11.1. Operating
s3.2
Systems Overview
11.2. Tasks of
s3.3
Operating System
11.3. Operating
s3.2
System Abstractions
11.4. Operating
Systems s3.1
Classification
Computing Foundations 13-31
Sommerville 2011
Brookshear 2008
McConnell 2004
Nielsen 1993
Voland 2003
Bishop 2002
[11*]
[8*]
[9*]
[5*]
[3*]
[2*]
[4*]
[6*]
12. Database
Basics and Data c9
Management
12.1. Entity and
s9.1
Schema
12.2. Database
Management s9.1
Systems (DBMS)
12.3. Database
s9.2
Query Language
12.4. Tasks of
s9.2
DBMS Packages
12.5. Data
s9.5
Management
12.6. Data Mining s9.6
13. Network
Communication c12
Basics
13.1. Types of s12.2–
Network 12.3
13.2. Basic Network
s12.6
Components
13.3. Networking
s12.4–
Protocols and
12.5
Standards
13.4. The Internet
13.5. Internet of
s12.8
Things
13.6. Virtual Private
Network
14. Parallel and
Distributed c9
Computing
14.1. Parallel
and Distributed s9.4.1–
Computing 9.4.3
Overview
13-32 SWEBOK® Guide V3.0
Sommerville 2011
Brookshear 2008
McConnell 2004
Nielsen 1993
Voland 2003
Bishop 2002
[11*]
[8*]
[9*]
[5*]
[3*]
[2*]
[4*]
[6*]
14.2. Differences
between Parallel s9.4.4–
and Distributed 9.4.5
Computing
14.3. Parallel
s9.4.4–
and Distributed
9.4.5
Computing Models
14.4. Main Issues
in Distributed
Computing
15. Basic User
c8 c5
Human Factors
15.1. Input and s5.1,
Output s5.3
s5.2,
15.2. Error Messages
s5.8
15.3. Software s5.5–
Robustness 5.6
16. Basic Developer
c31–32
Human Factors
16.1. Structure c31
16.2. Comments c32
17. Secure Software
Development and c29
Maintenance
17.1. Two Aspects of
s29.1
Secure Coding
17.2. Coding
Security into s29.4
Software
17.3. Requirement
s29.2
Security
17.4. Design
s29.3
Security
17.5. Implementation
s29.5
Security
Computing Foundations 13-33
REFERENCES
[1] Joint Task Force on Computing Curricula, [7] ISO/IEC/IEEE 24765:2010 Systems and
IEEE Computer Society and Association Software Engineering—Vocabulary, ISO/
for Computing Machinery, Software IEC/IEEE, 2010.
Engineering 2004: Curriculum Guidelines
for Undergraduate Degree Programs in [8*] L. Null and J. Lobur, The Essentials of
Software Engineering, 2004; http://sites. Computer Organization and Architecture,
computer.org/ccse/SE2004Volume.pdf. 2nd ed., Jones and Bartlett Publishers,
2006.
[2*] G. Voland, Engineering by Design, 2nd ed.,
Prentice Hall, 2003. [9*] J. Nielsen, Usability Engineering, Morgan
Kaufmann, 1993.
[3*] S. McConnell, Code Complete, 2nd ed.,
Microsoft Press, 2004. [10] ISO 9241-420:2011 Ergonomics of Human-
System Interaction, ISO, 2011.
[4*] J.G. Brookshear, Computer Science: An
Overview, 10th ed., Addison-Wesley, 2008. [11*] M. Bishop, Computer Security: Art and
Science, Addison-Wesley, 2002.
[5*] E. Horowitz et al., Computer Algorithms,
2nd ed., Silicon Press, 2007. [12] R.C. Seacord, The CERT C Secure Coding
Standard, Addison-Wesley Professional,
[6*] I. Sommerville, Software Engineering, 9th 2008.
ed., Addison-Wesley, 2011.
CHAPTER 14
MATHEMATICAL FOUNDATIONS
14-1
14-2 SWEBOK® Guide V3.0
Cardinality. The cardinality of a finite set S is Empty Set. A set with no elements is called an
the number of elements in S. This is represented empty set. An empty set, denoted by ∅, is also
|S|, e.g., if S = {1, 2, 3}, then |S| = 3. referred to as a null or void set.
Universal Set. In general S = {x ∈ U | p(x)}, Power Set. The set of all subsets of a set X is
where U is the universe of discourse in which called the power set of X. It is represented as
the predicate P(x) must be interpreted. The “uni- ℘(X).
verse of discourse” for a given predicate is often For example, if X = {a, b, c}, then ℘(X) = {∅,
referred to as the universal set. Alternately, one {a}, {b}, {c}, {a, b}, {a, c}, {b, c}, {a, b, c}}. If
may define universal set as the set of all elements. |X| = n, then |℘(X)| = 2n.
Set Equality. Two sets are equal if and only if Venn Diagrams. Venn diagrams are graphic rep-
they have the same elements, i.e.: resentations of sets as enclosed areas in the plane.
For example, in Figure 14.2, the rectangle rep-
X = Y ≡ ∀p (p ∈ X ↔ p ∈ Y). resents the universal set and the shaded region
represents a set X.
Subset. X is a subset of set Y, or X is contained
in Y, if all elements of X are included in Y. This is
denoted by X ⊆ Y. In other words, X ⊆ Y if and
only if ∀p (p ∈ X → p ∈ Y).
For example, if X = {1, 2, 3} and Y = {1, 2, 3,
4, 5}, then X ⊆ Y.
If X is not a subset of Y, it is denoted as X Y.
Proper Subset. X is a proper subset of Y (denoted
by X ⊂ Y) if X is a subset of Y but not equal to Y,
i.e., there is some element in Y that is not in X.
In other words, X ⊂ Y if (X ⊆ Y) ∧ (X ≠ Y). Figure 14.2. Venn Diagram for Set X
For example, if X = {1, 2, 3}, Y = {1, 2, 3,
4}, and Z = {1, 2, 3}, then X ⊂ Y, but X is not a
proper subset of Z. Sets X and Z are equal sets. 1.1. Set Operations
If X is not a proper subset of Y, it is denoted
as X ⊄ Y. Intersection. The intersection of two sets X and
Y, denoted by X ∩ Y, is the set of common ele-
Superset. If X is a subset of Y, then Y is called ments in both X and Y.
a superset of X. This is denoted by Y ⊇ X, i.e., Y In other words, X ∩ Y = {p | (p ∈ X) ∧ (p ∈ Y)}.
⊇ X if and only if X ⊆ Y. As, for example, {1, 2, 3} ∩ {3, 4, 6} = {3}
For example, if X = {1, 2, 3} and Y = {1, 2, 3, If X ∩ Y = f, then the two sets X and Y are said
4, 5}, then Y ⊇ X. to be a disjoint pair of sets.
Mathematical Foundations 14-3
A Venn diagram for set intersection is shown in The shaded portion of the Venn diagram in Fig-
Figure 14.3. The common portion of the two sets ure 14.5 represents the complement set of X.
represents the set intersection. Set Difference or Relative Complement. The set
of elements that belong to set X but not to set Y
builds the set difference of Y from X. This is rep-
resented by X − Y.
In other words, X − Y = {p | (p ∈ X) ∧ (p ∉ Y)}.
As, for example, {1, 2, 3} − {3, 4, 6} = {1, 2}.
It may be proved that X − Y = X ∩ Y’.
Set difference X – Y is illustrated by the shaded
region in Figure 14.6 using a Venn diagram.
Figure 14.3. Intersection of Sets X and Y
1.2. Properties of Set
1. Associative Laws:
X ∪ (Y ∪ Z) = (X ∪ Y) ∪ Z
Figure 14.5. Venn Diagram for Complement Set of X X ∩ (Y ∩ Z) = (X ∩ Y) ∩ Z
14-4 SWEBOK® Guide V3.0
A variable x that is introduced into a logical Statements used in a proof include axioms
expression by a quantifier is bound to the closest and postulates that are essentially the underlying
enclosing quantifier. assumptions about mathematical structures, the
A variable is said to be a free variable if it is not hypotheses of the theorem to be proved, and pre-
bound to a quantifier. viously proved theorems.
Similarly, in a block-structured programming A theorem is a statement that can be shown to
language, a variable in a logical expression refers be true.
to the closest quantifier within whose scope it A lemma is a simple theorem used in the proof
appears. of other theorems.
For example, in ∃x (Cat(x) ∧ ∀x (Black(x))), x A corollary is a proposition that can be estab-
in Black(x) is universally quantified. The expres- lished directly from a theorem that has been
sion implies that cats exist and everything is proved.
black. A conjecture is a statement whose truth value
Propositional logic falls short in representing is unknown.
many assertions that are used in computer sci- When a conjecture’s proof is found, the conjec-
ence and mathematics. It also fails to compare ture becomes a theorem. Many times conjectures
equivalence and some other types of relationship are shown to be false and, hence, are not theorems.
between propositions.
For example, the assertion a is greater than 3.1. Methods of Proving Theorems
1 is not a proposition because one cannot infer
whether it is true or false without knowing the Direct Proof. Direct proof is a technique to estab-
value of a. Thus, propositional logic cannot deal lish that the implication p → q is true by showing
with such sentences. However, such assertions that q must be true when p is true.
appear quite often in mathematics and we want For example, to show that if n is odd then n2−1
to infer on those assertions. Also, the pattern is even, suppose n is odd, i.e., n = 2k + 1 for some
involved in the following two logical equiva- integer k:
lences cannot be captured by propositional
logic: “Not all men are smokers” and “Some men ∴ n2 = (2k + 1)2 = 4k2 + 4k + 1.
don’t smoke.” Each of these two propositions
is treated independently in propositional logic. As the first two terms of the Right Hand Side
There is no mechanism in propositional logic to (RHS) are even numbers irrespective of the value
find out whether or not the two are equivalent to of k, the Left Hand Side (LHS) (i.e., n2) is an odd
one another. Hence, in propositional logic, each number. Therefore, n2−1 is even.
equivalent proposition is treated individually Proof by Contradiction. A proposition p is true
rather than dealing with a general formula that by contradiction if proved based on the truth of
covers all equivalences collectively. the implication ¬ p → q where q is a contradiction.
Predicate logic is supposed to be a more pow- For example, to show that the sum of 2x + 1
erful logic that addresses these issues. In a sense, and 2y − 1 is even, assume that the sum of 2x + 1
predicate logic (also known as first-order logic and 2y − 1is odd. In other words, 2(x + y), which
or predicate calculus) is an extension of propo- is a multiple of 2, is odd. This is a contradiction.
sitional logic to formulas involving terms and Hence, the sum of 2x + 1 and 2y − 1 is even.
predicates. An inference rule is a pattern establishing that
if a set of premises are all true, then it can be
3. Proof Techniques deduced that a certain conclusion statement is
[1*, c1] true. The reference rules of addition, simplifica-
tion, and conjunction need to be studied.
A proof is an argument that rigorously establishes Proof by Induction. Proof by induction is done
the truth of a statement. Proofs can themselves be in two phases. First, the proposition is estab-
represented formally as discrete structures. lished to be true for a base case—typically for the
Mathematical Foundations 14-7
positive integer 1. In the second phase, it is estab- n2 ways, and if these tasks cannot be done at the
lished that if the proposition holds for an arbitrary same time, then there are n1+ n2 ways to do either
positive integer k, then it must also hold for the task.
next greater integer, k + 1. In other words, proof
by induction is based on the rule of inference that • If A and B are disjoint sets, then |A ∪ B|=|A|
tells us that the truth of an infinite sequence of + |B|.
propositions P(n), ∀n ∈ [1 … ∞] is established • In general if A1, A2, …. , An are disjoint
if P(1) is true, and secondly, ∀k ∈ [2 ... n] if P(k) sets, then |A1 ∪ A2 ∪ … ∪ An| = |A1| + |A2|
→ P(k + 1). + … + |An|.
It may be noted here that, for a proof by math-
ematical induction, it is not assumed that P(k) is For example, if there are 200 athletes doing
true for all positive integers k. Proving a theo- sprint events and 30 athletes who participate in
rem or proposition only requires us to establish the long jump event, then how many ways are
that if it is assumed P(k) is true for any arbitrary there to pick one athlete who is either a sprinter
positive integer k, then P(k + 1) is also true. The or a long jumper?
correctness of mathematical induction as a valid Using the sum rule, the answer would be 200
proof technique is beyond discussion of the cur- + 30 = 230.
rent text. Let us prove the following proposition The product rule states that if a task t1 can be
using induction. done in n1 ways and a second task t2 can be done
Proposition: The sum of the first n positive odd in n2 ways after the first task has been done, then
integers P(n) is n2. there are n1 * n2 ways to do the procedure.
Basis Step: The proposition is true for n = 1 as
P(1) = 12 = 1. The basis step is complete. • If A and B are disjoint sets, then |A × B| =
Inductive Step: The induction hypothesis (IH) |A| * |B|.
is that the proposition is true for n = k, k being an • In general if A1, A2, …, An are disjoint sets,
arbitrary positive integer k. then |A1 × A2 × … × An| = |A1| * |A2| * ….
* |An|.
∴ 1 + 3 + 5+ … + (2k − 1) = k2
For example, if there are 200 athletes doing
Now, it’s to be shown that P(k) → P(k + 1). sprint events and 30 athletes who participate in
the long jump event, then how many ways are
P(k + 1) = 1 + 3 + 5+ … +(2k − 1) + (2k + 1) there to pick two athletes so that one is a sprinter
= P(k) + (2k + 1) and the other is a long jumper?
= k2 + (2k + 1) [using IH] Using the product rule, the answer would be
= k2 + 2k + 1 200 * 30 = 6000.
= (k + 1)2 The principle of inclusion-exclusion states that
if a task t1 can be done in n1 ways and a second
Thus, it is shown that if the proposition is true task t2 can be done in n2 ways at the same time
for n = k, then it is also true for n = k + 1. with t1, then to find the total number of ways the
The basis step together with the inductive step of two tasks can be done, subtract the number of
the proof show that P(1) is true and the conditional ways to do both tasks from n1 + n2.
statement P(k) → P(k + 1) is true for all positive
integers k. Hence, the proposition is proved. • If A and B are not disjoint, |A ∪ B| = |A| +
|B| − |A ∩ B|.
4. Basics of Counting
[1*c6] In other words, the principle of inclusion-
exclusion aims to ensure that the objects in the
The sum rule states that if a task t1 can be done intersection of two sets are not counted more than
in n1 ways and a second task t2 can be done in once.
14-8 SWEBOK® Guide V3.0
Recursion is the general term for the practice 5. Graphs and Trees
of defining an object in terms of itself. There are [1*, c10, c11]
recursive algorithms, recursively defined func-
tions, relations, sets, etc. 5.1. Graphs
A recursive function is a function that calls
itself. For example, we define f(n) = 3 * f(n − 1) A graph G = (V, E) where V is the set of vertices
for all n ∈ N and n ≠ 0 and f(0) = 5. (nodes) and E is the set of edges. Edges are also
An algorithm is recursive if it solves a problem referred to as arcs or links.
by reducing it to an instance of the same problem
with a smaller input.
A phenomenon is said to be random if individ-
ual outcomes are uncertain but the long-term pat-
tern of many individual outcomes is predictable.
The probability of any outcome for a ran-
dom phenomenon is the proportion of times the
outcome would occur in a very long series of
repetitions.
The probability P(A) of any event A satisfies 0
≤ P(A) ≤ 1. Any probability is a number between
0 and 1. If S is the sample space in a probabil-
ity model, the P(S) = 1. All possible outcomes
together must have probability of 1. Figure 14.8. Example of a Graph
Two events A and B are disjoint if they have
no outcomes in common and so can never occur F is a function that maps the set of edges E to
together. If A and B are two disjoint events, P(A a set of ordered or unordered pairs of elements V.
or B) = P(A) + P(B). This is known as the addi- For example, in Figure 14.8, G = (V, E) where V
tion rule for disjoint events. = {A, B, C}, E = {e1, e2, e3}, and F = {(e1, (A,
If two events have no outcomes in common, C)), (e2, (C, B)), (e3, (B, A))}.
the probability that one or the other occurs is the The graph in Figure 14.8 is a simple graph that
sum of their individual probabilities. consists of a set of vertices or nodes and a set of
Permutation is an arrangement of objects in edges connecting unordered pairs.
which the order matters without repetition. One The edges in simple graphs are undirected.
can choose r objects in a particular order from a Such graphs are also referred to as undirected
total of n objects by using nPr ways, where, npr = graphs.
n! / (n − r)!. Various notations like nPr and P(n, r) For example, in Figure 14.8, (e1, (A, C)) may
are used to represent the number of permutations be replaced by (e1, (C, A)) as the pair between
of a set of n objects taken r at a time. vertices A and C is unordered. This holds good
Combination is a selection of objects in which for the other two edges too.
the order does not matter without repetition. This In a multigraph, more than one edge may con-
is different from a permutation because the order nect the same two vertices. Two or more connect-
does not matter. If the order is only changed (and ing edges between the same pair of vertices may
not the members) then no new combination is reflect multiple associations between the same
formed. One can choose r objects in any order two vertices. Such edges are called parallel or
from a total of n objects by using nCr ways, where, multiple edges.
n
Cr = n! / [r! * (n − r)!]. For example, in Figure 14.9, the edges e3 and
e4 are both between A and B. Figure 14.9 is a
multigraph where edges e3 and e4 are multiple
edges.
Mathematical Foundations 14-9
Figure 14.16. Examples of Binary Trees Interestingly, following the definitions above,
the tree in Figure 14.18(b) is a complete but not
For example, in Figure 14.16, the two binary full binary tree as node B has only one child in D.
trees are different as the positions of occurrences On the contrary, the tree in Figure 14.17 is a full
of the children of A are different in the two trees. —but not complete—binary tree, as the children
of B occur in the tree while the children of C do
not appear in the last level.
A binary tree of height H is balanced if all its
leaf nodes occur at levels H or H − 1.
For example, all three binary trees in Figures
14.17 and 14.18 are balanced binary trees.
There are at most 2H leaves in a binary tree of
height H. In other words, if a binary tree with L
leaves is full and balanced, then its height is H =
⎡log2L⎤.
For example, this statement is true for the
two trees in Figures 14.17 and 14.18(a) as both
Figure 14.17. Example of a Full Binary Tree trees are full and balanced. However, the expres-
sion above does not match for the tree in Figure
According to [1*], a binary tree is called a full 14.18(b) as it is not a full binary tree.
binary tree if every internal node has exactly two A binary search tree (BST) is a special kind of
children. binary tree in which each node contains a distinct
For example, the binary tree in Figure 14.17 key value, and the key value of each node in the
is a full binary tree, as both of the two internal tree is less than every key value in its right subtree
nodes A and B are of degree 2. and greater than every key value in its left subtree.
A full binary tree following the definition A traversal algorithm is a procedure for sys-
above is also referred to as a strictly binary tree. tematically visiting every node of a binary tree.
For example, both binary trees in Figure 14.18 Tree traversals may be defined recursively.
are complete binary trees. The tree in Figure If T is binary tree with root R and the remain-
14.18(a) is a complete as well as a full binary ing nodes form an ordered pair of nonnull left
tree. A complete binary tree has all its levels, subtree TL and nonnull right subtree TR below R,
except possibly the last one, filled up to capacity. then the preorder traversal function PreOrder(T)
In case the last level of a complete binary tree is is defined as:
not full, nodes occur from the leftmost positions
available. PreOrder(T) = R, PreOrder(TL), PreOrder(TR)
… eqn. 1
Mathematical Foundations 14-13
The recursive process of finding the preorder randomness has been defined in section 4 of this
traversal of the subtrees continues till the sub- KA. Here, let us start with the concepts behind
trees are found to be Null. Here, commas have probability distribution and discrete probability.
been used as delimiters for the sake of improved A probability model is a mathematical descrip-
readability. tion of a random phenomenon consisting of two
The postorder and in-order may be similarly parts: a sample space S and a way of assigning
defined using eqn. 2 and eqn. 3 respectively. probabilities to events. The sample space defines
the set of all possible outcomes, whereas an event
PostOrder(T) = PostOrder(TL), PostOrder(TR), is a subset of a sample space representing a pos-
R … eqn 2 sible outcome or a set of outcomes.
InOrder(T) = InOrder(TL), R, InOrder(TR) … A random variable is a function or rule that
eqn 3 assigns a number to each outcome. Basically, it
is just a symbol that represents the outcome of an
experiment.
For example, let X be the number of heads
when the experiment is flipping a coin n times.
Similarly, let S be the speed of a car as registered
on a radar detector.
The values for a random variable could be dis-
crete or continuous depending on the experiment.
A discrete random variable can hold all pos-
sible outcomes without missing any, although it
might take an infinite amount of time.
A continuous random variable is used to mea-
sure an uncountable number of values even if an
infinite amount of time is given.
Figure 14.19. A Binary Search Tree For example, if a random variable X represents
an outcome that is a real number between 1 and
For example, the tree in Figure 14.19 is a binary 100, then X may have an infinite number of val-
search tree (BST). The preorder, postorder, and ues. One can never list all possible outcomes for
in-order traversal outputs for the BST are given X even if an infinite amount of time is allowed.
below in their respective order. Here, X is a continuous random variable. On
the contrary, for the same interval of 1 to 100,
Preorder output: 9, 5, 2, 1, 4, 7, 6, 8, 13, 11, another random variable Y can be used to list all
10, 15 the integer values in the range. Here, Y is a dis-
Postorder output: 1, 4, 2, 6, 8, 7, 5, 10, 11, 15, crete random variable.
13, 9 An upper-case letter, say X, will represent
In-order output: 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, the name of the random variable. Its lower-case
13, 15 counterpart, x, will represent the value of the ran-
dom variable.
Further discussion on trees and their usage has The probability that the random variable X will
been included in section 6, Data Structure and Rep- equal x is:
resentation, of the Computing Foundations KA.
P(X = x) or, more simply, P(x).
6. Discrete Probability
[1*, c7] A probability distribution (density) function is
a table, formula, or graph that describes the val-
Probability is the mathematical description of ues of a random variable and the probability asso-
randomness. Basic definition of probability and ciated with these values.
14-14 SWEBOK® Guide V3.0
Probabilities associated with discrete random These numbers indeed aim to derive the aver-
variables have the following properties: age value from repeated experiments. This is
based on the single most important phenom-
i. 0 ≤ P(x) ≤ 1 for all x enon of probability, i.e., the average value from
ii. ΣP(x) = 1 repeated experiments is likely to be close to the
expected value of one experiment. Moreover,
A discrete probability distribution can be repre- the average value is more likely to be closer to
sented as a discrete random variable. the expected value of any one experiment as the
number of experiments increases.
X 1 2 3 4 5 6
7. Finite State Machines
P(x) 1/6 1/6 1/6 1/6 1/6 1/6 [1*, c13]
Figure 14.20. A Discrete Probability Function for a Rolling A computer system may be abstracted as a map-
Die ping from state to state driven by inputs. In other
words, a system may be considered as a transition
The mean μ of a probability distribution model function T: S × I → S × O, where S is the set of
is the sum of the product terms for individual states and I, O are the input and output functions.
events and its outcome probability. In other If the state set S is finite (not infinite), the sys-
words, for the possible outcomes x1, x2, … , xn tem is called a finite state machine (FSM).
in a sample space S if pk is the probability of out- Alternately, a finite state machine (FSM) is a
come xk, the mean of this probability would be μ mathematical abstraction composed of a finite
= x1p1 + x2p2 + … + xnpn. number of states and transitions between those
For example, the mean of the probability den- states. If the domain S × I is reasonably small,
sity for the distribution in Figure 14.20 would be then one can specify T explicitly using diagrams
similar to a flow graph to illustrate the way logic
1 * (1/6) + 2 * (1/6) + 3 * (1/6) + 4 * (1/6) + 5 flows for different inputs. However, this is prac-
* (1/6) + 6 * (1/6) tical only for machines that have a very small
= 21 * (1/6) = 3.5 information capacity.
An FSM has a finite internal memory, an input
Here, the sample space refers to the set of all feature that reads symbols in a sequence and one
possible outcomes. at a time, and an output feature.
The variance s2 of a discrete probability model The operation of an FSM begins from a start
is: s2 = (x1 – μ)2p1 + (x2 – μ)2p2 + … + (xk – μ)2pk. state, goes through transitions depending on input
The standard deviations is the square root of the to different states, and can end in any valid state.
variance. However, only a few of all the states mark a suc-
For example, for the probability distribution in cessful flow of operation. These are called accept
Figure 14.20, the variation σ2 would be states.
The information capacity of an FSM is
s2 = [(1 – 3.5)2 * (1/6) + (2 – 3.5)2 * (1/6) + C = log |S|. Thus, if we represent a machine having
(3 – 3.5)2 * (1/6) + (4 – 3.5)2 * (1/6) + (5 – an information capacity of C bits as an FSM, then
3.5)2 * (1/6) + (6 – 3.5)2 * (1/6)] its state transition graph will have |S| = 2C nodes.
= (6.25 + 2.25 + 0.25 + 0.5 + 2.25 + 6.25) * A finite state machine is formally defined as M
(1/6) = (S, I, O, f, g, s0).
= 17.5 * (1/6)
= 2.90 S is the state set;
I is the set of input symbols;
∴ standard deviation s = O is the set of output symbols;
f is the state transition function;
Mathematical Foundations 14-15
g is the output function; The state transition and output values for differ-
and s0 is the initial state. ent inputs on different states may be represented
using a state table. The state table for the FSM in
Given an input x ∈ I on state Sk, the FSM Figure 14.21 is shown in Figure 14.22. Each pair
makes a transition to state Sh following state tran- against an input symbol represents the new state
sition function f and produces an output y ∈ O and the output symbol.
using the output function g. For example, Figures 14.22(a) and 14.22(b) are
two alternate representations of the FSM in Fig-
ure 14.21.
8. Grammars
[1*, c13]
1. Every regular grammar is a context-free For example, the regular expression (ab)*
grammar (CFG). matches the set of strings: {e, ab, abab, ababab,
2. Every CFG is a context-sensitive grammar abababab, …}.
(CSG).
Mathematical Foundations 14-17
For example, the regular expression (aa)* or chopping (meaning the exact representative
matches the set of strings on one letter a that have immediately below —or above, if negative—the
even length. number).
For example, the regular expression (aaa)* + Numbers lying beyond the range must be repre-
(aaaaa)* matches the set of strings of length equal sented by the largest (or largest negative) number
to a multiple of 3 or 5. that can be represented. This becomes a symbol
for overflow. Overflow occurs when a computa-
9. Numerical Precision, Accuracy, and Errors tion produces a value larger than the maximum
[2*, c2] value in the range.
When processing speed is a significant bottle-
The main goal of numerical analysis is to neck, the use of the fixed-point representations
develop efficient algorithms for computing pre- is an attractive and faster alternative to the more
cise numerical values of functions, solutions of cumbersome floating-point arithmetic most com-
algebraic and differential equations, optimization monly used in practice.
problems, etc. Let’s define a couple of very important terms:
A matter of fact is that all digital computers can accuracy and precision as associated with numer-
only store finite numbers. In other words, there ical analysis.
is no way that a computer can represent an infi- Accuracy is the closeness with which a mea-
nitely large number—be it an integer, rational sured or computed value agrees with the true value.
number, or any real or all complex numbers (see Precision, on the other hand, is the closeness
section 10, Number Theory). So the mathematics with which two or more measured or computed
of approximation becomes very critical to handle values for the same physical substance agree with
all the numbers in the finite range that a computer each other. In other words, precision is the close-
can handle. ness with which a number represents an exact
Each number in a computer is assigned a loca- value.
tion or word, consisting of a specified number of Let x be a real number and let x* be an approxi-
binary digits or bits. A k bit word can store a total mation. The absolute error in the approximation
of N = 2k different numbers. x* ≈ x is defined as | x* − x |. The relative error
For example, a computer that uses 32 bit arith- is defined as the ratio of the absolute error to the
metic can store a total of N = 232 ≈ 4.3 × 109 dif- size of x, i.e., |x* − x| / | x |, which assumes x ¹ 0;
ferent numbers, while another one that uses 64 otherwise, relative error is not defined.
bits can handle N’ = 264 ≈ 1.84 × 1019 different For example, 1000000 is an approximation to
numbers. The question is how to distribute these 1000001 with an absolute error of 1 and a relative
N numbers over the real line for maximum effi- error of 10−6, while 10 is an approximation of 11
ciency and accuracy in practical computations. with an absolute error of 1 and a relative error of
One evident choice is to distribute them evenly, 0.1. Typically, relative error is more intuitive and
leading to fixed-point arithmetic. In this system, the preferred determiner of the size of the error.
the first bit in a word is used to represent a sign The present convention is that errors are always
and the remaining bits are treated for integer val- ≥ 0, and are = 0 if and only if the approximation
ues. This allows representation of the integers is exact.
from 1 − ½N, i.e., = 1 − 2k−1 to 1. As an approxi- An approximation x* has k significant deci-
mating method, this is not good for noninteger mal digits if its relative error is < 5 × 10−k−1. This
numbers. means that the first k digits of x* following its
Another option is to space the numbers closely first nonzero digit are the same as those of x.
together—say with a uniform gap of 2−n—and so Significant digits are the digits of a number that
distribute the total N numbers uniformly over the are known to be correct. In a measurement, one
interval −2−n−1N < x ≤ 2−n−1N. Real numbers lying uncertain digit is included.
between the gaps are represented by either round- For example, measurement of length with
ing (meaning the closest exact representative) a ruler of 15.5 mm with ±0.5 mm maximum
14-18 SWEBOK® Guide V3.0
allowable error has 2 significant digits, whereas decimals either do not exist, e.g., 15, or, when
a measurement of the same length using a caliper decimals do exist, they may terminate, as in 15.6,
and recorded as 15.47 mm with ±0.01 mm maxi- or they may repeat with a pattern, as in 1.666...,
mum allowable error has 3 significant digits. (which is 5/3).
Irrational Numbers. These are numbers that
10. Number Theory cannot be expressed as an integer divided by an
[1*, c4] integer. These numbers have decimals that never
terminate and never repeat with a pattern, e.g., PI
Number theory is one of the oldest branches or √2.
of pure mathematics and one of the largest. Of Real Numbers. This group is made up of all the
course, it concerns questions about numbers, rational and irrational numbers. The numbers that
usually meaning whole numbers and fractional or are encountered when studying algebra are real
rational numbers. The different types of numbers numbers. The common mathematical symbol for
include integer, real number, natural number, the set of all real numbers is R.
complex number, rational number, etc. Imaginary Numbers. These are all based on the
imaginary number i. This imaginary number is
10.1. Divisibility equal to the square root of −1. Any real number
multiple of i is an imaginary number, e.g., i, 5i,
Let’s start this section with a brief description of 3.2i, −2.6i, etc.
each of the above types of numbers, starting with Complex Numbers. A complex number is a
the natural numbers. combination of a real number and an imaginary
Natural Numbers. This group of numbers starts number in the form a + bi. The real part is a, and
at 1 and continues: 1, 2, 3, 4, 5, and so on. Zero b is called the imaginary part. The common math-
is not in this group. There are no negative or frac- ematical symbol for the set of all complex num-
tional numbers in the group of natural numbers. bers is C.
The common mathematical symbol for the set of For example, 2 + 3i, 3−5i, 7.3 + 0i, and 0 + 5i.
all natural numbers is N. Consider the last two examples:
Whole Numbers. This group has all of the natu- 7.3 + 0i is the same as the real number 7.3.
ral numbers in it plus the number 0. Thus, all real numbers are complex numbers with
Unfortunately, not everyone accepts the above zero for the imaginary part.
definitions of natural and whole numbers. There Similarly, 0 + 5i is just the imaginary number
seems to be no general agreement about whether 5i. Thus, all imaginary numbers are complex
to include 0 in the set of natural numbers. numbers with zero for the real part.
Many mathematicians consider that, in Europe, Elementary number theory involves divisibility
the sequence of natural numbers traditionally among integers. Let a, b ∈ Z with a ≠ 0.The expres-
started with 1 (0 was not even considered to be sion a|b, i.e., a divides b if ∃c ∈ Z: b = ac, i.e., there
a number by the Greeks). In the 19th century, set is an integer c such that c times a equals b.
theoreticians and other mathematicians started For example, 3|−12 is true, but 3|7 is false.
the convention of including 0 in the set of natural If a divides b, then we say that a is a factor of
numbers. b or a is a divisor of b, and b is a multiple of a.
Integers. This group has all the whole numbers b is even if and only if 2|b.
in it and their negatives. The common mathemati- Let a, d ∈ Z with d > 1. Then a mod d denotes
cal symbol for the set of all integers is Z, i.e., Z = that the remainder r from the division algorithm
{…, −3, −2, −1, 0, 1, 2, 3, …}. with dividend a and divisor d, i.e., the remainder
Rational Numbers. These are any numbers that when a is divided by d. We can compute (a mod
can be expressed as a ratio of two integers. The d) by: a − d * ⎣a/d⎦, where ⎣a/d⎦ represents the
common symbol for the set of all rational num- floor of the real number.
bers is Q. Let Z+ = {n ∈ Z | n > 0} and a, b ∈ Z, m ∈ Z+,
Rational numbers may be classified into then a is congruent to b modulo m, written as a ≡
three types, based on how the decimals act. The b (mod m), if and only if m | a−b.
Mathematical Foundations 14-19
[2*]
[1*]
1. Sets, Relations, Functions c2
2. Basic Logic c1
3. Proof Techniques c1
4. Basic Counting c6
5. Graphs and Trees c10, c11
6. Discrete Probability c7
7. Finite State Machines c13
8. Grammars c13
9. Numerical Precision, Accuracy, and Errors c2
10. Number Theory c4
11. Algebraic Structures
14-22 SWEBOK® Guide V3.0
REFERENCES ACKNOWLEDGMENTS
[1*] K. Rosen, Discrete Mathematics and Its The author thankfully acknowledges the contri-
Applications, 7th ed., McGraw-Hill, 2011. bution of Prof. Arun Kumar Chatterjee, Ex-Head,
Department of Mathematics, Manipur Univer-
[2*] E.W. Cheney and D.R. Kincaid, Numerical sity, India, and Prof. Devadatta Sinha, Ex-Head,
Mathematics and Computing, 6th ed., Department of Computer Science and Engineer-
Brooks/Cole, 2007. ing, University of Calcutta, India, in preparing
this chapter on Mathematical Foundations.
CHAPTER 15
ENGINEERING FOUNDATIONS
15-1
15-2 SWEBOK® Guide V3.0
results are being generalized may be different. Distribution of a random variable. The range
For example, when the study population consists and pattern of variation of a random variable is
of only past observations and generalizations are given by its distribution. When the distribution
required for the future, the study population and of a random variable is known, it is possible to
the target population may not be the same. compute the chance of any event. Some distribu-
Sample. A sample is a subset of the population. tions are found to occur commonly and are used
The most crucial issue towards the selection of to model many random variables occurring in
a sample is its representativeness, including size. practice in the context of engineering. A few of
The samples must be drawn in a manner so as the more commonly occurring distributions are
to ensure that the draws are independent, and given below.
the rules of drawing the samples must be pre-
defined so that the probability of selecting a par- • Binomial distribution: used to model random
ticular sampling unit is known beforehand. This variables that count the number of successes
method of selecting samples is called probability in n trials carried out independently of each
sampling. other, where each trial results in success or
Random variable. In statistical terminology, failure. We make an assumption that the
the process of making observations or measure- chance of obtaining a success remains con-
ments on the sampling units being studied is stant [2*, c3s6].
referred to as conducting the experiment. For • Poisson distribution: used to model the count
example, if the experiment is to toss a coin 10 of occurrence of some event over time or
times and then count the number of times the space [2*, c3s9].
coin lands on heads, each 10 tosses of the coin • Normal distribution: used to model continu-
is a sampling unit and the number of heads for a ous random variables or discrete random
given sample is the observation or outcome for variables by taking a very large number of
the experiment. The outcome of an experiment is values [2*, c4s6].
obtained in terms of real numbers and defines the
random variable being studied. Thus, the attribute Concept of parameters. A statistical distribution
of the items being measured at the outcome of is characterized by some parameters. For exam-
the experiment represents the random variable ple, the proportion of success in any given trial
being studied; the observation obtained from a is the only parameter characterizing a binomial
particular sampling unit is a particular realization distribution. Similarly, the Poisson distribution is
of the random variable. In the example of the coin characterized by a rate of occurrence. A normal
toss, the random variable is the number of heads distribution is characterized by two parameters:
observed for each experiment. In statistical stud- namely, its mean and standard deviation.
ies, attempts are made to understand population Once the values of the parameters are known,
characteristics on the basis of samples. the distribution of the random variable is com-
The set of possible values of a random variable pletely known and the chance (probability) of
may be finite or infinite but countable (e.g., the any event can be computed. The probabilities
set of all integers or the set of all odd numbers). for a discrete random variable can be computed
In such a case, the random variable is called a dis- through the probability mass function, called
crete random variable. In other cases, the random the pmf. The pmf is defined at discrete points
variable under consideration may take values on and gives the point mass—i.e., the probability
a continuous scale and is called a continuous ran- that the random variable will take that particular
dom variable. value. Likewise, for a continuous random vari-
Event. A subset of possible values of a random able, we have the probability density function,
variable is called an event. Suppose X denotes called the pdf. The pdf is very much like density
some random variable; then, for example, we and needs to be integrated over a range to obtain
may define different events such as X ³ x or X < the probability that the continuous random vari-
x and so on. able lies between certain values. Thus, if the pdf
15-4 SWEBOK® Guide V3.0
or pmf is known, the chances of the random vari- observations as well as the sample size. The lim-
able taking certain set of values may be computed its are computed on the basis of some assump-
theoretically. tions regarding the sampling distribution of the
Concept of estimation [2*, c6s2, c7s1, c7s3]. point estimate on which the limits are based.
The true values of the parameters of a distribution Properties of estimators. Various statistical
are usually unknown and need to be estimated properties of estimators are used to decide about
from the sample observations. The estimates are the appropriateness of an estimator in a given
functions of the sample values and are called sta- situation. The most important properties are that
tistics. For example, the sample mean is a statistic an estimator is unbiased, efficient, and consistent
and may be used to estimate the population mean. with respect to the population.
Similarly, the rate of occurrence of defects esti- Tests of hypotheses [2*, c9s1].A hypothesis is
mated from the sample (rate of defects per line of a statement about the possible values of a param-
code) is a statistic and serves as the estimate of eter. For example, suppose it is claimed that a
the population rate of rate of defects per line of new method of software development reduces the
code. The statistic used to estimate some popula- occurrence of defects. In this case, the hypoth-
tion parameter is often referred to as the estimator esis is that the rate of occurrence of defects has
of the parameter. reduced. In tests of hypotheses, we decide—on
A very important point to note is that the results the basis of sample observations—whether a pro-
of the estimators themselves are random. If we posed hypothesis should be accepted or rejected.
take a different sample, we are likely to get a dif- For testing hypotheses, the null and alternative
ferent estimate of the population parameter. In the hypotheses are formed. The null hypothesis is the
theory of estimation, we need to understand dif- hypothesis of no change and is denoted as H0. The
ferent properties of estimators—particularly, how alternative hypothesis is written as H1. It is impor-
much the estimates can vary across samples and tant to note that the alternative hypothesis may be
how to choose between different alternative ways one-sided or two-sided. For example, if we have
to obtain the estimates. For example, if we wish the null hypothesis that the population mean is not
to estimate the mean of a population, we might less than some given value, the alternative hypoth-
use as our estimator a sample mean, a sample esis would be that it is less than that value and we
median, a sample mode, or the midrange of the would have a one-sided test. However, if we have
sample. Each of these estimators has different the null hypothesis that the population mean is
statistical properties that may impact the standard equal to some given value, the alternative hypoth-
error of the estimate. esis would be that it is not equal and we would
Types of estimates [2*, c7s3, c8s1].There are have a two-sided test (because the true value could
two types of estimates: namely, point estimates be either less than or greater than the given value).
and interval estimates. When we use the value In order to test some hypothesis, we first com-
of a statistic to estimate a population parameter, pute some statistic. Along with the computation
we get a point estimate. As the name indicates, a of the statistic, a region is defined such that in
point estimate gives a point value of the param- case the computed value of the statistic falls in
eter being estimated. that region, the null hypothesis is rejected. This
Although point estimates are often used, they region is called the critical region (also known as
leave room for many questions. For instance, we the confidence interval). In tests of hypotheses,
are not told anything about the possible size of we need to accept or reject the null hypothesis
error or statistical properties of the point esti- on the basis of the evidence obtained. We note
mate. Thus, we might need to supplement a point that, in general, the alternative hypothesis is the
estimate with the sample size as well as the vari- hypothesis of interest. If the computed value of
ance of the estimate. Alternately, we might use the statistic does not fall inside the critical region,
an interval estimate. An interval estimate is a then we cannot reject the null hypothesis. This
random interval with the lower and upper lim- indicates that there is not enough evidence to
its of the interval being functions of the sample believe that the alternative hypothesis is true.
Engineering Foundations 15-5
As the decision is being taken on the basis given the value of one variable, the other can be
of sample observations, errors are possible; the estimated with no error. A positive correlation
types of such errors are summarized in the fol- coefficient indicates a positive relationship—that
lowing table. is, if one variable increases, so does the other. On
the other hand, when the variables are negatively
Statistical Decision correlated, an increase of one leads to a decrease
Nature of the other.
Accept H0 Reject H0
It is important to remember that correlation
H0 is Type I error does not imply causation. Thus, if two variables
OK
true (probability = a) are correlated, we cannot conclude that one
H0 is Type II error causes the other.
OK
false (probability = b) Regression. The correlation analysis only
measures the degree of relationship between
In test of hypotheses, we aim at maximizing the two variables. The analysis to find the relation-
power of the test (the value of 1−b) while ensur- ship between two variables is called regression
ing that the probability of a type I error (the value analysis. The strength of the relationship between
of a) is maintained within a particular value— two variables is measured using the coefficient of
typically 5 percent. determination. This is a value between 0 and 1.
It is to be noted that construction of a test of The closer the coefficient is to 1, the stronger the
hypothesis includes identifying statistic(s) to relationship between the variables. A value of 1
estimate the parameter(s) and defining a critical indicates a perfect relationship.
region such that if the computed value of the sta-
tistic falls in the critical region, the null hypoth- 3. Measurement
esis is rejected. [4*, c3s1, c3s2] [5*, c4s4] [6*, c7s5]
[7*, p442–447]
2.2. Concepts of Correlation and Regression
[2*, c11s2, c11s8] Knowing what to measure and which measure-
ment method to use is critical in engineering
A major objective of many statistical investiga- endeavors. It is important that everyone involved
tions is to establish relationships that make it pos- in an engineering project understand the mea-
sible to predict one or more variables in terms of surement methods and the measurement results
others. Although it is desirable to predict a quan- that will be used.
tity exactly in terms of another quantity, it is sel- Measurements can be physical, environmen-
dom possible and, in many cases, we have to be tal, economic, operational, or some other sort of
satisfied with estimating the average or expected measurement that is meaningful for the particular
values. project. This section explores the theory of mea-
The relationship between two variables is stud- surement and how it is fundamental to engineer-
ied using the methods of correlation and regres- ing. Measurement starts as a conceptualization
sion. Both these concepts are explained briefly in then moves from abstract concepts to definitions
the following paragraphs. of the measurement method to the actual appli-
Correlation. The strength of linear relation- cation of that method to obtain a measurement
ship between two variables is measured using result. Each of these steps must be understood,
the correlation coefficient. While computing the communicated, and properly employed in order
correlation coefficient between two variables, we to generate usable data. In traditional engineer-
assume that these variables measure two differ- ing, direct measures are often used. In software
ent attributes of the same entity. The correlation engineering, a combination of both direct and
coefficient takes a value between –1 to +1. The derived measures is necessary [6*, p273].
values –1 and +1 indicate a situation when the The theory of measurement states that mea-
association between the variables is perfect—i.e., surement is an attempt to describe an underlying
15-6 SWEBOK® Guide V3.0
real empirical system. Measurement methods this simple measurement will lead to substantial
define activities that allocate a value or a symbol variation. Engineers must appreciate the need to
to an attribute of an entity. define measures from an operational perspective.
Attributes must then be defined in terms of
the operations used to identify and measure 3.1. Levels (Scales) of Measurement
them— that is, the measurement methods. In this [4*, c3s2] [6*, c7s5]
approach, a measurement method is defined to be
a precisely specified operation that yields a num- Once the operational definitions are determined,
ber (called the measurement result) when mea- the actual measurements need to be undertaken.
suring an attribute. It follows that, to be useful, It is to be noted that measurement may be car-
the measurement method has to be well defined. ried out in four different scales: namely, nominal,
Arbitrariness in the method will reflect itself in ordinal, interval, and ratio. Brief descriptions of
ambiguity in the measurement results. each are given below.
In some cases—particularly in the physical Nominal scale: This is the lowest level of mea-
world—the attributes that we wish to measure are surement and represents the most unrestricted
easy to grasp; however, in an artificial world like assignment of numerals. The numerals serve only
software engineering, defining the attributes may as labels, and words or letters would serve as well.
not be that simple. For example, the attributes of The nominal scale of measurement involves only
height, weight, distance, etc. are easily and uni- classification and the observed sampling units
formly understood (though they may not be very are put into any one of the mutually exclusive
easy to measure in all circumstances), whereas and collectively exhaustive categories (classes).
attributes such as software size or complexity Some examples of nominal scales are:
require clear definitions.
Operational definitions. The definition of attri- • Job titles in a company
butes, to start with, is often rather abstract. Such • The software development life cycle (SDLC)
definitions do not facilitate measurements. For model (like waterfall, iterative, agile, etc.)
example, we may define a circle as a line forming followed by different software projects
a closed loop such that the distance between any
point on this line and a fixed interior point called In nominal scale, the names of the different cat-
the center is constant. We may further say that the egories are just labels and no relationship between
fixed distance from the center to any point on the them is assumed. The only operations that can be
closed loop gives the radius of the circle. It may be carried out on nominal scale is that of counting
noted that though the concept has been defined, no the number of occurrences in the different classes
means of measuring the radius has been proposed. and determining if two occurrences have the same
The operational definition specifies the exact steps nominal value. However, statistical analyses may
or method used to carry out a specific measure- be carried out to understand how entities belong-
ment. This can also be called the measurement ing to different classes perform with respect to
method; sometimes a measurement procedure may some other response variable.
be required to be even more precise. Ordinal scale: Refers to the measurement scale
The importance of operational definitions where the different values obtained through the
can hardly be overstated. Take the case of the process of measurement have an implicit order-
apparently simple measurement of height of ing. The intervals between values are not speci-
individuals. Unless we specify various factors fied and there is no objectively defined zero
like the time when the height will be measured element. Typical examples of measurements in
(it is known that the height of individuals vary ordinal scales are:
across various time points of the day), how the
variability due to hair would be taken care of, • Skill levels (low, medium, high)
whether the measurement will be with or without • Capability Maturity Model Integration
shoes, what kind of accuracy is expected (correct (CMMI) maturity levels of software devel-
up to an inch, 1/2 inch, centimeter, etc.)—even opment organizations
Engineering Foundations 15-7
Thus, it is clear that engineering design is a All of the engineering design steps are itera-
vital component in the training and education for tive, and knowledge gained at any step in the
all engineers. The remainder of this section will process may be used to inform earlier tasks and
focus on various aspects of engineering design. trigger an iteration in the process. These steps are
expanded in the subsequent sections.
4.2. Design as a Problem Solving Activity
[5*, c1s4, c2s1, c3s3] a. Define the problem. At this stage, the custom-
er’s requirements are gathered. Specific informa-
It is to be noted that engineering design is primar- tion about product functions and features are also
ily a problem solving activity. Design problems closely examined. This step includes refining the
are open ended and more vaguely defined. There problem statement to identify the real problem to
are usually several alternative ways to solve the be solved and setting the design goals and criteria
same problem. Design is generally considered to for success.
be a wicked problem—a term first coined by Horst The problem definition is a crucial stage in
Rittel in the 1960s when design methods were a engineering design. A point to note is that this
subject of intense interest. Rittel sought an alterna- step is deceptively simple. Thus, enough care
tive to the linear, step-by-step model of the design must be taken to carry out this step judiciously. It
process being explored by many designers and is important to identify needs and link the success
design theorists and argued that most of the prob- criteria with the required product characteristics.
lems addressed by the designers are wicked prob- It is also an engineering task to limit the scope
lems. As explained by Steve McConnell, a wicked of a problem and its solution through negotiation
problem is one that could be clearly defined only among the stakeholders.
by solving it or by solving part of it. This paradox
implies, essentially, that a wicked problem has to b. Gather pertinent information. At this stage,
be solved once in order to define it clearly and then the designer attempts to expand his/her knowl-
solved again to create a solution that works. This edge about the problem. This is a vital, yet often
has been an important insight for software design- neglected, stage. Gathering pertinent information
ers for several decades [10*, c5s1]. can reveal facts leading to a redefinition of the
15-10 SWEBOK® Guide V3.0
problem—in particular, mistakes and false starts refine the design or drive the selection of an alter-
may be identified. This step may also involve the native design solution. One of the most impor-
decomposition of the problem into smaller, more tant activities in design is documentation of the
easily solved subproblems. design solution as well as of the tradeoffs for the
While gathering pertinent information, care choices made in the design of the solution. This
must be taken to identify how a product may be work should be carried out in a manner such that
used as well as misused. It is also important to the solution to the design problem can be com-
understand the perceived value of the product/ municated clearly to others.
service being offered. Included in the pertinent The testing and verification take us back to the
information is a list of constraints that must be success criteria. The engineer needs to devise
satisfied by the solution or that may limit the set tests such that the ability of the design to meet the
of feasible solutions. success criteria is demonstrated. While design-
ing the tests, the engineer must think through
c. Generate multiple solutions. During this stage, different possible failure modes and then design
different solutions to the same problem are devel- tests based on those failure modes. The engineer
oped. It has already been stated that design prob- may choose to carry out designed experiments to
lems have multiple solutions. The goal of this assess the validity of the design.
step is to conceptualize multiple possible solu-
tions and refine them to a sufficient level of detail 5. Modeling, Simulation, and Prototyping
that a comparison can be done among them. [5*, c6] [11*, c13s3] [12*, c2s3.1]
d. Analyze and select a solution. Once alternative Modeling is part of the abstraction process used
solutions have been identified, they need to be ana- to represent some aspects of a system. Simula-
lyzed to identify the solution that best suits the cur- tion uses a model of the system and provides a
rent situation. The analysis includes a functional means of conducting designed experiments with
analysis to assess whether the proposed design that model to better understand the system, its
would meet the functional requirements. Physical behavior, and relationships between subsystems,
solutions that involve human users often include as well as to analyze aspects of the design. Mod-
analysis of the ergonomics or user friendliness of eling and simulation are techniques that can be
the proposed solution. Other aspects of the solu- used to construct theories or hypotheses about the
tion—such as product safety and liability, an eco- behavior of the system; engineers then use those
nomic or market analysis to ensure a return (profit) theories to make predictions about the system.
on the solution, performance predictions and anal- Prototyping is another abstraction process where
ysis to meet quality characteristics, opportunities a partial representation (that captures aspects of
for incorrect data input or hardware malfunctions, interest) of the product or system is built. A pro-
and so on—may be studied. The types and amount totype may be an initial version of the system but
of analysis used on a proposed solution are depen- lacks the full functionality of the final version.
dent on the type of problem and the needs that the
solution must address as well as the constraints 5.1. Modeling
imposed on the design.
A model is always an abstraction of some real
e. Implement the solution. The final phase of the or imagined artifact. Engineers use models in
design process is implementation. Implemen- many ways as part of their problem solving
tation refers to development and testing of the activities. Some models are physical, such as a
proposed solution. Sometimes a preliminary, made-to-scale miniature construction of a bridge
partial solution called a prototype may be devel- or building. Other models may be nonphysical
oped initially to test the proposed design solu- representations, such as a CAD drawing of a cog
tion under certain conditions. Feedback resulting or a mathematical model for a process. Models
from testing a prototype may be used either to help engineers reason and understand aspects of
Engineering Foundations 15-11
a problem. They can also help engineers under- An important problem in the development of a
stand what they do know and what they don’t discrete simulation is that of initialization. Before
know about the problem at hand. a simulation can be run, the initial values of all
There are three types of models: iconic, ana- the state variables must be provided. As the simu-
logic, and symbolic. An iconic model is a visu- lation designer may not know what initial values
ally equivalent but incomplete 2-dimensional are appropriate for the state variables, these val-
or 3-dimensional representation—for example, ues might be chosen somewhat arbitrarily. For
maps, globes, or built-to-scale models of struc- instance, it might be decided that a queue should
tures such as bridges or highways. An iconic be initialized as empty and idle. Such a choice of
model actually resembles the artifact modeled. initial condition can have a significant but unrec-
In contrast, an analogic model is a functionally ognized impact on the outcome of the simulation.
equivalent but incomplete representation. That
is, the model behaves like the physical artifact 5.3. Prototyping
even though it may not physically resemble it.
Examples of analogic models include a miniature Constructing a prototype of a system is another
airplane for wind tunnel testing or a computer abstraction process. In this case, an initial version
simulation of a manufacturing process. of the system is constructed, often while the sys-
Finally, a symbolic model is a higher level of tem is being designed. This helps the designers
abstraction, where the model is represented using determine the feasibility of their design.
symbols such as equations. The model captures There are many uses for a prototype, includ-
the relevant aspects of the process or system in ing the elicitation of requirements, the design and
symbolic form. The symbols can then be used to refinement of a user interface to the system, vali-
increase the engineer’s understanding of the final dation of functional requirements, and so on. The
system. An example is an equation such as F = objectives and purposes for building the proto-
Ma. Such mathematical models can be used to type will determine its construction and the level
describe and predict properties or behavior of the of abstraction used.
final system or product. The role of prototyping is somewhat different
between physical systems and software. With
5.2. Simulation physical systems, the prototype may actually
be the first fully functional version of a system
All simulation models are a specification of real- or it may be a model of the system. In software
ity. A central issue in simulation is to abstract engineering, prototypes are also an abstract
and specify an appropriate simplification of model of part of the software but are usually not
reality. Developing this abstraction is of vital constructed with all of the architectural, perfor-
importance, as misspecification of the abstrac- mance, and other quality characteristics expected
tion would invalidate the results of the simulation in the finished product. In either case, prototype
exercise. Simulation can be used for a variety of construction must have a clear purpose and be
testing purposes. planned, monitored, and controlled—it is a tech-
Simulation is classified based on the type of nique to study a specific problem within a limited
system under study. Thus, simulation can be either context [6*, c2s8].
continuous or discrete. In the context of software In conclusion, modeling, simulation, and pro-
engineering, the emphasis will be primarily on totyping are powerful techniques for studying the
discrete simulation. Discrete simulations may behavior of a system from a given perspective.
model event scheduling or process interaction. All can be used to perform designed experiments
The main components in such a model include to study various aspects of the system. How-
entities, activities and events, resources, the state ever, these are abstractions and, as such, may not
of the system, a simulation clock, and a random model all attributes of interest.
number generator. Output is generated by the
simulation and must be analyzed.
15-12 SWEBOK® Guide V3.0
of RCA is to prevent recurrence of the undesir- A very simple approach that is useful in quality
able event. Thus, the more specific the investiga- control is the use of a checklist. Checklists are
tor can be about why an event occurred, the easier a list of key points in a process with tasks that
it will be to prevent recurrence. A common way must be completed. As each task is completed,
to identify specific underlying cause(s) is to ask a it is checked off the list. If a problem occurs,
series of why questions. then sometimes the checklist can quickly identify
tasks that may have been skipped or only par-
7.1. Techniques for Conducting Root Cause tially completed.
Analysis Finally, relations diagrams are a means for dis-
[4*, c5] [5*, c3] playing complex relationships. They give visual
support to cause-and-effect thinking. The dia-
There are many approaches used for both quality gram relates the specific to the general, revealing
control and root cause analysis. The first step in key causes and key effects.
any root cause analysis effort is to identify the real Root cause analysis aims at preventing the
problem. Techniques such as statement-restate- recurrence of undesirable events. Reduction of
ment, why-why diagrams, the revision method, variation due to common causes requires utili-
present state and desired state diagrams, and the zation of a number of techniques. An important
fresh-eye approach are used to identify and refine point to note is that these techniques should be
the real problem that needs to be addressed. used offline and not necessarily in direct response
Once the real problem has been identified, then to the occurrence of some undesirable event.
work can begin to determine the cause of the Some of the techniques that may be used to
problem. Ishikawa is known for the seven tools reduce variation due to common causes are given
for quality control that he promoted. Some of below.
those tools are helpful in identifying the causes
for a given problem. Those tools are check sheets 1. Cause-and-effect diagrams may be used to
or checklists, Pareto diagrams, histograms, run identify the sub and sub-sub causes.
charts, scatter diagrams, control charts, and 2. Fault tree analysis is a technique that may be
fishbone or cause-and-effect diagrams. More used to understand the sources of failures.
recently, other approaches for quality improve- 3. Designed experiments may be used to under-
ment and root cause analysis have emerged. Some stand the impact of various causes on the
examples of these newer methods are affinity dia- occurrence of undesirable events (see Empir-
grams, relations diagrams, tree diagrams, matrix ical Methods and Experimental Techniques
charts, matrix data analysis charts, process deci- in this KA).
sion program charts, and arrow diagrams. A few 4. Various kinds of correlation analyses may be
of these techniques are briefly described below. used to understand the relationship between
A fishbone or cause-and-effect diagram is a various causes and their impact. These tech-
way to visualize the various factors that affect niques may be used in cases when conduct-
some characteristic. The main line in the diagram ing controlled experiments is difficult but
represents the problem and the connecting lines data may be gathered (see Statistical Analy-
represent the factors that led to or influenced the sis in this KA).
problem. Those factors are broken down into sub-
factors and sub-subfactors until root causes can
be identified.
15-14 SWEBOK® Guide V3.0
Sommerville 2011
McConnell 2004
Fairley 2009
Voland 2003
Tockey 2004
Moore 2006
Kan 2002
[12*]
[13*]
[10*]
[11*]
[7*]
[5*]
[3*]
[2*]
[4*]
[6*]
1. Empirical
Methods and
c1
Experimental
Techniques
1.1. Designed
Experiment
1.2.
Observational
Study
1.3.
Retrospective
Study
2. Statistical c9s1,
c10s3
Analysis c2s1
c3s6,
c3s9,
2.1. Concept of
c4s6,
Unit of Analysis
c6s2,
(Sampling
c7s1,
Units), Sample,
c7s3,
and Population
c8s1,
c9s1
2.2. Concepts of
c11s2,
Correlation and
c11s8
Regression
c3s1,
3. Measurement c4s4 c7s5
c3s2
3.1. Levels
p442
(Scales) of c3s2 c7s5
–447
Measurement
3.2. Direct
and Derived
Measures
Engineering Foundations 15-15
Sommerville 2011
McConnell 2004
Fairley 2009
Voland 2003
Tockey 2004
Moore 2006
Kan 2002
[12*]
[13*]
[10*]
[11*]
[7*]
[5*]
[3*]
[2*]
[4*]
[6*]
3.3. Reliability c3s4,
and Validity c3s5
3.4. Assessing
c3s5
Reliability
c1s2,
4. Engineering
c1s3,
Design
c1s4
4.1. Design in
Engineering
Education
4.2. Design c1s4,
as a Problem c2s1, c5s1
Solving Activity c3s3
4.3. Steps
Involved in
c4
Engineering
Design
5. Modeling,
c2
Prototyping, and c6 c13s3
s3.1
Simulation
5.1. Modeling
5.2. Simulation
5.3. Prototyping
c9
6. Standards c1s2
s3.2
c5, c9s3,
7. Root Cause c13
c3s7, c9s4,
Analysis s3.4.5
c9s8 c9s5
7.1. Techniques
for Conducting
c5 c3
Root Cause
Analysis
15-16 SWEBOK® Guide V3.0
FURTHER READINGS
A. Abran, Software Metrics and Software W.G. Vincenti, What Engineers Know and How
Metrology. [14] They Know It. [15]
This book provides very good information on the This book provides an interesting introduc-
proper use of the terms measure, measurement tion to engineering foundations through a series
method and measurement outcome. It provides of case studies that show many of the founda-
strong support material for the entire section on tional concepts as used in real world engineering
Measurement. applications.
Engineering Foundations 15-17
REFERENCES
[1] ISO/IEC/IEEE 24765:2010 Systems and [9] ABET Engineering Accreditation
Software Engineering—Vocabulary, ISO/ Commission, “Criteria for Accrediting
IEC/IEEE, 2010. Engineering Programs, 2012-2013,”
ABET, 2011; www.abet.org/uploadedFiles/
[2*] D.C. Montgomery and G.C. Runger, Accreditation/Accreditation_Process/
Applied Statistics and Probability for Accreditation_Documents/Current/eac-
Engineers, 4th ed., Wiley, 2007. criteria-2012-2013.pdf.
[3*] L. Null and J. Lobur, The Essentials of [10*] S. McConnell, Code Complete, 2nd ed.,
Computer Organization and Architecture, Microsoft Press, 2004.
2nd ed., Jones and Bartlett Publishers,
2006. [11*] E.W. Cheney and D.R. Kincaid, Numerical
Mathematics and Computing, 6th ed.,
[4*] S.H. Kan, Metrics and Models in Software Brooks/Cole, 2007.
Quality Engineering, 2nd ed., Addison-
Wesley, 2002. [12*] I. Sommerville, Software Engineering, 9th
ed., Addison-Wesley, 2011.
[5*] G. Voland, Engineering by Design, 2nd ed.,
Prentice Hall, 2003. [13*] J.W. Moore, The Road Map to Software
Engineering: A Standards-Based Guide,
[6*] R.E. Fairley, Managing and Leading Wiley-IEEE Computer Society Press, 2006.
Software Projects, Wiley-IEEE Computer
Society Press, 2009. [14] A. Abran, Software Metrics and Software
Metrology, Wiley-IEEE Computer Society
[7*] S. Tockey, Return on Software: Maximizing Press, 2010.
the Return on Your Software Investment,
Addison-Wesley, 2004. [15] W.G. Vincenti, What Engineers Know
and How They Know It, John Hopkins
[8] Canadian Engineering Accreditation Board, University Press, 1990.
Engineers Canada, “Accreditation Criteria
and Procedures,” Canadian Council of
Professional Engineers, 2011; www.
engineerscanada.ca/files/w_Accreditation_
Criteria_Procedures_2011.pdf.
APPENDIX A
A-1
A-2 SWEBOK® Guide V3.0
topics within each KA, and the Consolidated Ref- Areas and therefore must be incorporated
erence List. into the proposed breakdown of topics of
A Change Control Board (CCB) has been in each Knowledge Area. These common
place for the development of this version to han- themes are measurement, quality (in gen-
dle all change requests to this baseline coming eral), and security.
from the KA Editors, arising during the review i) The breakdown of topics should be at most
process, or otherwise. Change requests must be two or three levels deep. Even though no
approved both by the SWEBOK Guide Editors upper or lower limit is imposed on the num-
and by the CCB before being implemented. This ber of topics within each KA, a reasonable
CCB is comprised of members of the initiatives and manageable number of topics is expected
listed above and acting under the authority of the to be included in each KA. Emphasis should
Software and Systems Engineering Committee of also be put on the selection of the topics
the IEEE Computer Society Professional Activi- themselves rather than on their organization
ties Board. in an appropriate hierarchy.
j) Topic names must be significant enough
CRITERIA AND REQUIREMENTS FOR to be meaningful even when cited outside the
THE BREAKDOWN OF TOPICS WITHIN SWEBOK Guide.
A KNOWLEDGE AREA k) The description of a KA will include a chart
(in tree form) describing the knowledge
a) KA Editors are instructed to adopt the base- breakdown.
line breakdown of topics.
b) The breakdown of topics is expected to be CRITERIA AND REQUIREMENTS FOR
“reasonable,” not “perfect.” DESCRIBING TOPICS
c) The breakdown of topics within a KA must
decompose the subset of the Software Engi- Topics need only be sufficiently described so the
neering Body of Knowledge that is “gen- reader can select the appropriate reference mate-
erally recognized.” See below for a more rial according to his/her needs. Topic descrip-
detailed discussion of this point. tions must not be prescriptive.
d) The breakdown of topics within a KA must
not presume specific application domains, CRITERIA AND REQUIREMENTS FOR
business needs, sizes of organizations, organi- REFERENCE MATERIAL
zational structures, management philosophies,
software life cycle models, software technolo- a) KA Editors are instructed to use the refer-
gies, or software development methods. ences (to the level of section number) allo-
e) The breakdown of topics must, as much cated to their KA by the Consolidated Refer-
as possible, be compatible with the vari- ence List as their Recommended References.
ous schools of thought within software b) There are three categories of reference
engineering. material:
f) The breakdown of topics within a KA must
be compatible with the breakdown of soft- »» Recommended References. The set of
ware engineering generally found in indus- Recommended References (to the level
try and in the software engineering literature of section number) is collectively known
and standards. as the Consolidated Reference List.
g) The breakdown of topics is expected to be as »» Further Readings.
inclusive as possible. »» Additional references cited in the KA
h) The SWEBOK Guide adopts the position Description (for example, the source
that even though the following “themes” are of a quotation or reference material in
common across all Knowledge Areas, they support of a rationale behind a particular
are also an integral part of all Knowledge argument).
Appendix A A-3
c) The SWEBOK Guide is intended by defini- cited reference material is sufficient for
tion to be selective in its choice of topics the objectives of the SWEBOK Guide).
and associated reference material. The list of »» Each reference to the recommended
reference material should be clearly viewed reference material should be as precise
as an “informed and reasonable selection” as possible by identifying what specific
rather than as a definitive list. chapter or section is relevant.
d) Reference material can be book chapters, »» A matrix of reference material (to the
refereed journal papers, refereed confer- level of section number) versus topics
ence papers, refereed technical or industrial must be provided.
reports, or any other type of recognized arti- »» A reasonable amount of recommended
fact. References to another KA, subarea, or reference material must be identified
topic are also permitted. for each KA. The following guidelines
e) Reference material must be generally avail- should be used in determining how
able and must not be confidential in nature. much is reasonable:
f) Reference material must be in English.
g) Criteria and requirements for recommended i. If the recommended reference
reference material or Consolidated Refer- material were written in a coher-
ence List: ent manner that followed the pro-
posed breakdown of topics and in
»» Collectively the list of Recommended a uniform style (for example, in a
References should be new book based on the proposed
KA description), an average tar-
i. complete: covering the entire get across all KAs for the number
scope of the SWEBOK Guide of pages would be 750. However,
ii. sufficient: providing enough this target may not be attainable
information to describe “gener- when selecting existing reference
ally accepted” knowledge material due to differences in
iii. consistent: not providing contra- style and overlap and redundancy
dictory knowledge nor conflict- between the selected reference
ing practices materials.
iv. credible: recognized as providing ii. In other words, the target for the
expert treatment number of pages for the entire
v. current: treating the subject in collection of recommended refer-
a manner that is commensurate ences of the SWEBOK Guide is
with currently generally accepted in the range of 10,000 to 15,000
knowledge pages.
vi. succinct: as short as possible iii. Another way of viewing this is
(both in number of reference that the amount of recommended
items and in total page count) reference material would be
without failing other objectives. reasonable if it consisted of the
study material on this KA for a
»» Recommended reference material must software engineering licensing
be identified for each topic. Each recom- exam that a graduate would pass
mended reference item may of course after completing four years of
cover multiple topics. Exceptionally, a work experience.
topic may be self-descriptive and not cite
a reference material item (for example, a h) Additional reference material can be
topic that is a definition or a topic for included by the KA Editor in a “Further
which the description itself without any Readings” list:
A-4 SWEBOK® Guide V3.0
KA descriptions should use the following structure: “Generally accepted” knowledge could also be
viewed as knowledge to be included in the study
• Acronyms material of a software engineering licensing exam
• Introduction (in the USA) that a graduate would take after
• Breakdown of Topics of the KA (including a completing four years of work experience. These
figure describing the breakdown) two definitions should be seen as complementary.
• Matrix of Topics vs. Reference Material KA Editors are also expected to be somewhat
• List of Further Readings forward looking in their interpretation by tak-
• References ing into consideration not only what is “gener-
ally recognized” today and but what they expect
will be “generally recognized” in a 3- to 5-year
timeframe.
Appendix A A-5
Advanced and Research Even though we do not intend that the Guide to
Innovative practices tested the Software Engineering Body of Knowledge be
and used only by some orga- fully 12207-conformant, this standard remains a
nizations and concepts still key input to the SWEBOK Guide, and special care
being developed and tested in will be taken throughout the SWEBOK Guide
research organizations regarding the compatibility of the Guide with the
12207 standard.
Figure A.1. Categories of Knowledge
3. J.W. Moore, The Road Map to Software
Engineering: A Standards-Based Guide,
LENGTH OF KA DESCRIPTION Wiley-IEEE Computer Society Press, 2006.
[4*]
KA Descriptions are to be roughly 10 to 20 pages
using the formatting template for papers pub- This book describes the scope, roles, uses, and
lished in conference proceedings of the IEEE development trends of the most widely used soft-
Computer Society. This includes text, references, ware engineering standards. It concentrates on
appendices, tables, etc. This, of course, does not important software engineering activities—qual-
include the reference materials themselves. ity and project management, system engineer-
ing, dependability, and safety. The analysis and
IMPORTANT RELATED DOCUMENTS regrouping of the standard collections exposes
the reader to key relationships between standards.
1. Graduate Software Engineering 2009 Even though the SWEBOK Guide is not a soft-
(GSwE2009): Curriculum Guidelines for ware engineering standard per se, special care
Graduate Degree Programs in Software will be taken throughout the document regarding
Engineering, 2009; www.gswe2009.org. [2] the compatibility of the Guide with the current
IEEE and ISO/IEC Systems and Software Engi-
This document “provides guidelines and rec- neering Standards Collection.
ommendations” for defining the curricula of a
professional master’s level program in software 4. Software Engineering 2004: Curriculum
engineering. The SWEBOK Guide is identified Guidelines for Undergraduate Degree
as a “primary reference” in developing the body Programs in Software Engineering, IEEE
of knowledge underlying these guidelines. This Computer Society and Association for
document has been officially endorsed by the Computing Machinery, 2004; http://sites.
IEEE Computer Society and sponsored by the computer.org/ccse/SE2004Volume.pdf. [5]
Association for Computing Machinery.
This document describes curriculum guidelines
2. IEEE Std. 12207-2008 (a.k.a. ISO/IEC for an undergraduate degree in software engineer-
12207:2008) Standard for Systems and ing. The SWEBOK Guide is identified as being
Software Engineering—Software Life Cycle “one of the primary sources” in developing the
Processes, IEEE, 2008 [3]. body of knowledge underlying these guidelines.
This standard is considered the key standard 5. ISO/IEC/IEEE 24765:2010 Systems and
regarding the definition of life cycle processes and Software Engineering—Vocabulary, ISO/
has been adopted by the two main standardization IEC/IEEE, 2010; www.computer.org/
bodies in software engineering: ISO/IEC JTC1/ sevocab. [6]
SC7 and the IEEE Computer Society Software
A-6 SWEBOK® Guide V3.0
The hierarchy of references for terminology is the bibliography. We believe this approach allows
Merriam Webster’s Collegiate Dictionary (11th the reader to be better exposed to the source and
ed.) [7], IEEE/ISO/IEC 24765 [6], and new pro- scope of a standard.
posed definitions if required. The text accompanying figures and tables
should be self-explanatory or have enough related
6. “Certification and Training for Software text. This would ensure that the reader knows
Professionals,” IEEE Computer Society, what the figures and tables mean.
2013; www.computer.org/certification. [8] To make sure that some information in the
SWEBOK Guide does not become rapidly obso-
Information on the certification and associated lete and due to its generic nature, please avoid
professional development products developed directly naming tools and products. Instead, try
and offered by the IEEE Computer Society for to name their functions.
professionals in the field of software engineer-
ing can be found on this website. The SWEBOK EDITING
Guide is foundational to these products.
Editors of the SWEBOK Guide as well as profes-
STYLE AND TECHNICAL GUIDELINES sional copy editors will edit KA Descriptions.
Editing includes copy editing (grammar, punc-
• KA Descriptions should conform to the tuation, and capitalization), style editing (confor-
Word template available at www.computer. mance to the Computer Society style guide), and
org/portal/web/cscps/formatting. content editing (flow, meaning, clarity, direct-
• KA Descriptions are expected to follow the ness, and organization). The final editing will
IEEE Computer Society Style Guide (www. be a collaborative process in which the Editors
computer.org/portal/web/publications/ of the SWEBOK Guide and the KA Editors work
styleguide). together to achieve a concise, well-worded, and
• Files are to be submitted in Microsoft Word useful KA Description.
format.
• All citations of reference material are to be RELEASE OF COPYRIGHT
produced using EndNote Web as indicated
in the instructions provided to KA Editors in All intellectual property rights associated with
this regard. the SWEBOK Guide will remain with the IEEE.
KA Editors must sign a copyright release form.
OTHER DETAILED GUIDELINES It is also understood that the SWEBOK Guide
will continue to be available free of charge in the
When referencing the Guide to the Software public domain in at least one format, provided by
Engineering Body of Knowledge, use the title the IEEE Computer Society through web technol-
“SWEBOK Guide.” ogy or by other means.
For the purpose of simplicity, avoid footnotes For more information, see www.computer.org/
and try to include their content in the main text. copyright.htm.
Use explicit references to standards, as opposed
to simply inserting numbers referencing items in
Appendix A A-7
REFERENCES
[1] Project Management Institute, A Guide to the [5] Joint Task Force on Computing Curricula,
Project Management Body of Knowledge IEEE Computer Society and Association
(PMBOK(R) Guide), 5th ed., Project for Computing Machinery, Software
Management Institute, 2013. Engineering 2004: Curriculum Guidelines
for Undergraduate Degree Programs in
[2] Integrated Software and Systems Software Engineering, 2004; http://sites.
Engineering Curriculum (iSSEc) Project, computer.org/ccse/SE2004Volume.pdf.
Graduate Software Engineering 2009
(GSwE2009): Curriculum Guidelines [6] ISO/IEC/IEEE 24765:2010 Systems and
for Graduate Degree Programs in Software Engineering—Vocabulary, ISO/
Software Engineering, Stevens Institute of IEC/IEEE, 2010.
Technology, 2009; www.gswe2009.org.
[7] Merriam-Webster’s Collegiate Dictionary,
[3] IEEE Std. 12207-2008 (a.k.a. ISO/IEC 11th ed., 2003.
12207:2008) Standard for Systems and
Software Engineering—Software Life Cycle [8] IEEE Computer Society, “Certification and
Processes, IEEE, 2008. Training for Software Professionals,” 2013;
www.computer.org/certification.
[4*] J.W. Moore, The Road Map to Software
Engineering: A Standards-Based Guide,
Wiley-IEEE Computer Society Press, 2006.
APPENDIX B
Some might say that the supply of software engi- title of the standard or simply use its number.
neering standards far exceeds the demand. One In obtaining a standard of interest, the reader
seldom listens to a briefing on the subject without should rely on the number, not the title, given
suffering some apparently obligatory joke that in this article. For reasons of consistency, the
there are too many of them. However, the exis- article will use the IEEE’s convention for the
tence of standards takes a very large (possibly capitalization of titles—nouns, pronouns,
infinite) trade space of alternatives and reduces adjectives, verbs, adverbs, and first and last
that space to a smaller set of choices—a huge words have an initial capital letter—despite
advantage for users. Nevertheless, it can still be the fact that IEEE and ISO/IEC use differing
difficult to choose from dozens of alternatives, so conventions.
supplementary guidance, like this appendix, can • Because these standards are being continu-
be helpful. A summary list of the standards men- ally revised to take account of new technolo-
tioned in this appendix appears at the end. gies and usage patterns, this article will be
To reduce tedium in reading, a few simplifica- obsolescent before it is published. Therefore,
tions and abridgements are made in this appendix: it will occasionally discuss standards that
have not yet been published, if they are likely
• ISO/IEC JTC 1/SC 7 maintains nearly two to assume significant importance.
hundred standards on the subject. IEEE • Explicit trademarks are omitted. Suffice it to
maintains about fifty. The two organizations say that IEEE places a trademark on all of its
are in the tenth year of a systematic program standards’ designations.
to coordinate and integrate their collections.
In general, this article will focus on the stan- There are some other conventions of interest:
dards that are recognized by both organiza-
tions, taking this condition as evidence that • In both IEEE and ISO/IEC, standards for
wide agreement has been obtained. Other systems engineering are maintained by the
standards will be mentioned briefly. same committee as those for software engi-
• Standards tend to have long, taxonomical neering. Many of the standards apply to both.
titles. If there were a single standard for So, instead of making fine distinctions, this
building an automobile, the one for your article will deal with both.
Camry probably would be titled something • On the other hand, both S2ESC and SC 7
like, “Vehicle, internal combustion, four- (see below for descriptions of these orga-
wheel, passenger, sedan.” Also, modern stan- nizations) are responsible for standards
dards organizations provide their standards that don’t qualify as “engineering.” In the
from databases. Like any database, these US and many other countries, the services
sometimes contain errors, particularly for the of a licensed engineer are required when a
titles. So this article will often paraphrase the product might affect public safety, health,
B-1
B-2 SWEBOK® Guide V3.0
and welfare as opposed to affecting merely 7) is the one responsible for software and sys-
the pocketbook of the client. This appendix tems engineering. SC 7, and its working groups,
will respect that distinction and ignore stan- meets twice a year, attracting delegations repre-
dards that appear to be merely economic in senting the national standards bodies of partici-
consequence. pating nations. Each nation follows its own pro-
• User documentation is assumed to be devel- cedures for determining national positions and
oped similarly to software. For example, each nation has the responsibility of determining
a standard concerning the design of user whether an ISO/IEC standard should be adopted
documentation is described in the Software as a national standard.
Design KA. SC 7 creates three types of documents:
• Some jointly developed standards are explic-
itly labeled as joint developments, e.g., ISO/ • International Standards: Documents contain-
IEC/IEEE 24765. In other cases, the stan- ing requirements that must be satisfied in
dards have different designations in the two order to claim conformance.
organizations. Examples include • Technical Specifications (formerly called
Technical Reports, type 1 and type 2): Docu-
»» IEEE Std. 12207:2008 (a.k.a. ISO/IEC ments published in a preliminary manner
12207:2008), where “a.k.a.” (“also while work continues.
known as”) is this appendix’s abbrevia- • Technical Reports (formerly called Techni-
tion to note the designation in the other cal Reports, type 3): Documents inherently
organization; unsuited to be standards, usually because
»» IEEE Std. 15939:2008 Standard Adop- they are descriptive rather than prescriptive.
tion of ISO/IEC 15939:2007, an adop-
tion by IEEE of a standard developed in The key thing to remember is that only the
ISO/IEC; first category counts as a consensus standard.
»» IEEE Std. 1220:2005 (a.k.a. ISO/IEC The reader can easily recognize the others by the
26702:2007), a “fast-track” by ISO/IEC suffix TS or TR prepended to the number of the
of a standard developed in IEEE. document.
In each of these cases, the standards are IEEE SOFTWARE AND SYSTEMS
substantively identical in the two orga- ENGINEERING STANDARDS
nizations, differing only in front matter COMMITTEE (S2ESC)
and, occasionally, added informational
material. IEEE is the world’s largest organization of tech-
nical professionals, with about 400,000 members
A summary list of all of the mentioned stan- in more than 160 countries. The publication of
dards is provided at the end of this appendix. standards is performed by the IEEE Standards
Association (IEEE-SA), but the committees that
ISO/IEC JTC 1/SC 7, SOFTWARE AND draft and sponsor the standards are in the various
SYSTEMS ENGINEERING IEEE societies; S2ESC is a part of the IEEE Com-
puter Society. IEEE is a global standards maker
ISO/IEC JTC 1/SC 7 is the major source of because its standards are used in many differ-
international standards on software and systems ent countries. Despite its international member-
engineering. Its name is formed taxonomically. ship (about 50% non-US), though, the IEEE-SA
Joint Technical Committee 1 (JTC 1) is a child routinely submits its standards to the American
of the International Organization for Standardiza- National Standards Institute (ANSI) for endorse-
tion (ISO) and the International Electrotechnical ment as “American National Standards.” Some
Commission (IEC); it has the scope of “informa- S2ESC standards are developed within S2ESC,
tion technology” and subdivides its work among some are developed jointly with SC 7, and some
a number of subcommittees; Subcommittee 7 (SC are adopted after being developed by SC 7.
Appendix B B-3
IEEE-SA publishes three types of “standards”: for any of the IEEE categories. In ISO/IEC, it is a
“technical report”—defined as a document inher-
• Standards, with a preponderance of the verb ently unsuited to be a standard. The 2004 IEEE
“shall” SWEBOK Guide was adopted by ISO/IEC with-
• Recommended Practices, with a preponder- out change. Presumably, ISO/IEC will adopt Ver-
ance of the verb “should” sion 3 of the SWEBOK Guide.
• Guides, with a preponderance of the verb
“may.”
ISO/IEC TR 19759:2005 Software Engineering—
All three of these compare to ISO/IEC stan- Guide to the Software Engineering Body of Knowledge
dards. IEEE-SA does have the concept of a “Trial- (SWEBOK)
Use” standard, which is roughly comparable to Applies to all KAs
an ISO/IEC Technical Specification. However, it
has nothing comparable to an ISO/IEC Techni- ISO/IEC 19759:2005, a Guide to the Software
cal Report; one would look elsewhere in IEEE for Engineering Body of Knowledge (SWEBOK),
documents of this ilk. identifies and describes that subset of the body
of knowledge that is generally accepted, even
THE STANDARDS though software engineers must be knowledge-
able not only in software engineering, but also,
The remainder of this article allocates the selected of course, in other related disciplines. SWEBOK
standards to relevant knowledge areas (KAs) of is an all-inclusive term that describes the sum
the SWEBOK Guide. There is a section for each of knowledge within the profession of software
KA. Within each section, the relevant standards engineering.
are listed—the ones that principally apply to the
KA as well as others that principally apply to
other KAs but which are also related to the cur- The text of the SWEBOK Guide is freely avail-
rent one. Following each standard is a brief sum- able at www.swebok.org/. The ISO/IEC adoption
mary. In most cases, the summary is a quotation of the Guide is freely available at http://standards.
or paraphrase of the abstract or other introductory iso.org/ittf/PubliclyAvailableStandards/index.
material from the text of the standard. html.
Most of the standards easily fit into one KA. ISO/IEC/IEEE 24765 provides a shared vocab-
Some fit into more than one; in such cases, ulary for the systems and software engineering
a cross-reference is provided. Two standards standards of both SC 7 and S2ESC.
apply to all KAs, so they are listed in a category
called “General.” All of the standards related to
computer-aided software engineering (CASE) ISO/IEC/IEEE 24765:2010 Systems and Software
tools and environments are listed in the Software Engineering—Vocabulary
Engineering Models and Methods KA section. Applies to all KAs
active source standards for each definition so that It defines the construct of a good requirement,
the use of the term can be further explored. provides attributes and characteristics of require-
ments, and discusses the iterative and recursive
application of requirements processes through-
The vocabulary is descriptive, rather than pre- out the life cycle. ISO/IEC/IEEE 29148:2011
scriptive; it gathers up all of the definitions from provides additional guidance in the application
all of the relevant standards, as well as a few of requirements engineering and management
other sources, rather than choosing among com- processes for requirements-related activities in
peting definitions. ISO/IEC 12207:2008 and ISO/IEC 15288:2008.
The content of the 24765 standard is freely Information items applicable to the engineering
accessible online at www.computer.org/sevocab. of requirements and their content are defined.
Two standards, 12207 and 15288, provide a The content of ISO/IEC/IEEE 29148:2011 can
complete set of processes for the entire life cycle be added to the existing set of requirements-
of a system or a software product. The two stan- related life cycle processes defined by ISO/IEC
dards are aligned for concurrent use on a single 12207:2008 or ISO/IEC 15288:2008, or it can be
project or in a single organization. They are used independently.
mentioned here because they are often used as a
framework for explaining or localizing the role of
other standards in the life cycle. A multipart ISO/IEC standard provides princi-
ples and methods for “sizing” software based on
its requirements. The functional size is often use-
IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) ful in the denominator of measurements of qual-
Standard for Systems and Software Engineering— ity and productivity in software development. It
Software Life Cycle Processes may also play a role in contracting for service-
See Software Engineering Process KA level agreements.
stakeholders. This standard is intended for use in standard is also applicable to user documentation
design situations in which an explicit software for systems including hardware.
design description is to be prepared. These situ-
ations include traditional software construction
activities (when design leads to code) and reverse SOFTWARE CONSTRUCTION
engineering situations (when a design description
is recovered from an existing implementation). The term “software construction” refers to the
This standard can be applied to commercial, sci- detailed creation of working, meaningful software
entific, or military software that runs on digital through a combination of coding, verification,
computers. Applicability is not restricted by the unit testing, integration testing, and debugging.
size, complexity, or criticality of the software. There are few standards on the details of soft-
This standard can be applied to the description ware coding. It has been found through (mostly
of high-level and detailed designs. This stan- bad) experience that coding conventions are not
dard does not prescribe specific methodologies appropriate for standardization because, in most
for design, configuration management, or qual- cases, the real benefit comes from the consis-
ity assurance. This standard does not require the tency of applying an arbitrary convention rather
use of any particular design languages, but estab- than the convention itself. So, although coding
lishes requirements on the selection of design conventions are a good idea, it is generally left
languages for use in an SDD. This standard can to the organization or the project to develop such
be applied to the preparation of SDDs captured as a standard.
paper documents, automated databases, software Nevertheless, the subject of secure coding has
development tools, or other media. attracted attention in recent years because some
coding idioms are insecure in the face of attack.
A Technical Report prepared by ISO/IEC JTC 1/
By convention, this appendix treats user docu- SC 22 (programming languages) describes vul-
mentation as a part of a software system. There- nerabilities in programming languages and how
fore, the various aspects of user documentation— they can be avoided.
its design, its testing, and so forth—are allocated
to different KAs. The next standard deals with the
design of user documentation. ISO/IEC TR 24772:2013 Information Technology—
Programming Languages—Guidance to Avoiding
Vulnerabilities in Programming Languages through
IEEE Std. 26514-2010 Standard Adoption of ISO/ Language Selection and Use
IEC 26514:2008 Systems and Software Engineer-
ing—Requirements for Designers and Developers of ISO/IEC TR 24772:2013 specifies software pro-
User Documentation gramming language vulnerabilities to be avoided
in the development of systems where assured
This standard provides requirements for the behavior is required for security, safety, mis-
design and development of software user docu- sion-critical, and business-critical software. In
mentation as part of the life cycle processes. It general, this guidance is applicable to the soft-
defines the documentation process from the view- ware developed, reviewed, or maintained for any
point of the documentation developer and also application.
covers the documentation product. It specifies the Vulnerabilities are described in a generic man-
structure, content, and format for user documen- ner that is applicable to a broad range of pro-
tation and also provides informative guidance for gramming languages. Annexes relate the generic
user documentation style. It is independent of the guidance to a selection of specific programming
software tools that may be used to produce docu- languages.
mentation and applies to both printed documenta-
tion and onscreen documentation. Much of this
Appendix B B-7
Coding is not the only way to create a software IEEE Std. 1008-1987 Standard for Software Unit
product. Often code (as well as requirements and Testing
design) is reused from previous projects or engi-
neered for reuse in future projects. IEEE Std. 1517 The primary objective is to specify a standard
is mentioned here because it provides a common approach to software unit testing that can be
framework for extending the system and software used as a basis for sound software engineer-
life cycle processes of IEEE Std. 12207:2008 to ing practice. A second objective is to describe
include the systematic practice of reuse. the software engineering concepts and testing
assumptions on which the standard approach is
based. A third objective is to provide guidance
IEEE Std. 1517-2010 Standard for Information and resource information to assist with the imple-
Technology—System and Software Life Cycle Pro- mentation and usage of the standard unit testing
cesses—Reuse Processes approach.
See Software Engineering Process KA
B-8 SWEBOK® Guide V3.0
IEEE and ISO/IEC JTC 1/SC 7 are cooperating It specifies processes for use in testing and
in a project to develop a single comprehensive reviewing of user documentation. It is not lim-
standard that covers all aspects of testing. One ited to the test and review phase of the life cycle,
can hope for publication of the four-part standard but includes activities throughout the information
by 2014. Portions of the content remain contro- management and documentation management
versial. One taxonomical issue is whether “static processes.
methods”—such as inspection, review, and static
analysis—should fall within the scope of “test-
ing” or should be distinguished as “verification Two standards are mentioned here because
and validation.” Although the resolution of the some sources consider software verification and
issue is probably of little importance to users of validation to be taxonomically included in testing.
the standard, it assumes great importance to the
standards-writers who must manage an integrated
suite of interoperating standards. IEEE Std. 1012-2012 Standard for System and Soft-
ware Verification and Validation
See Software Quality KA
ISO/IEC/IEEE 29119 [four parts] (Draft) Software
and Systems Engineering—Software Testing IEEE Std. 1044-2009 Standard for Classification for
Software Anomalies
The purpose of ISO/IEC 29119 Software Testing See Software Quality KA
is to define an internationally agreed standard for
software testing that can be used by any orga-
nization when performing any form of software SOFTWARE MAINTENANCE
testing.
This standard—the result of harmonizing distinct
IEEE and ISO/IEC standards on the subject—
Testing of user documentation is described in describes a single comprehensive process for the
the next standard, providing requirements for the management and execution of software mainte-
test and review of software user documentation nance. It expands on the provisions of the soft-
as part of the life cycle processes. It defines the ware maintenance process provided in ISO/IEC/
documentation process from the viewpoint of the IEEE 12207.
documentation tester and reviewer. It is relevant
to roles involved in testing and development of
software and user documentation, including proj- IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006)
ect managers, usability experts, and information Standard for Software Engineering—Software Life
developers in addition to testers and reviewers. Cycle Processes—Maintenance
ISO/IEC 14764:2006 provides the framework in ISO/IEC/IEEE Std. 24765 and the information
within which generic and specific software main- item requirements of IEEE Std. 15939.
tenance plans may be executed, evaluated, and
tailored to the maintenance scope and magni-
tude of given software products. It provides the ISO/IEC JTC 1/SC 7 has not yet determined
framework, precise terminology, and processes what action it should take regarding the new
to allow the consistent application of technol- IEEE Std. 828. There are issues concerning the
ogy (tools, techniques, and methods) to software extent of compatibility with ISO/IEC/IEEE
maintenance. 12207 and other standards in the SC 7 suite. It
It does not address the operation of software should be noted, though, that SC 7 does not have
and the operational functions, e.g., backup, a competing standard.
recovery, and system administration, which are
normally performed by those who operate the SOFTWARE ENGINEERING
software. MANAGEMENT
ISO/IEC 14764:2006 is written primarily for
maintainers of software and additionally for those Most readers will interpret the phrase “software
responsible for development and quality assur- engineering management” to mean the manage-
ance. It may also be used by acquirers and users ment of a project that concerns software. There
of systems containing software, who may provide are at least two possible extensions to this gen-
inputs to the maintenance plan. eralization, though. Some software activities are
managed according to a service-level agreement
(SLA). SLAs do not meet the criteria for “proj-
SOFTWARE CONFIGURATION ect” according to some definitions. Also, it has
MANAGEMENT become generally agreed that some management
of software should occur in the organization at a
There is one standard for configuration level above the project, so that all projects can
management. benefit from a common investment. A commonly
cited example is the provision of software pro-
cesses and tooling by the organization.
IEEE Std. 828-2012 Standard for Configuration Software project management can be regarded
Management in Systems and Software Engineering as a specialization of “project management”—
often regarded as a distinct discipline. The Proj-
This standard establishes the minimum require- ect Management Institute’s Guide to the Project
ments for processes for configuration management Management Body of Knowledge (PMBOK®
(CM) in systems and software engineering. The Guide) is often regarded as the authoritative
application of this standard applies to any form, source for this knowledge. From time to time,
class, or type of software or system. This revision IEEE adopts the most recent version of the
of the standard expands the previous version to PMBOK® Guide as an IEEE standard.
explain CM, including identifying and acquiring
configuration items, controlling changes, report-
ing the status of configuration items, as well as IEEE Std. 1490-2011 Guide—Adoption of the Proj-
software builds and release engineering. Its pre- ect Management Institute (PMI®) Standard, A
decessor defined only the contents of a software Guide to the Project Management Body of Knowl-
configuration management plan. This standard edge (PMBOK® Guide)—Fourth Edition
addresses what CM activities are to be done, when
they are to happen in the life cycle, and what plan- The PMBOK® Guide identifies that subset of
ning and resources are required. It also describes the project management body of knowledge gen-
the content areas for a CM plan. The standard sup- erally recognized as good practice. “Generally
ports ISO/IEC/IEEE 12207:2008 and ISO/IEC/ recognized” means the knowledge and practices
IEEE 15288:2008 and adheres to the terminology described are applicable to most projects most of
B-10 SWEBOK® Guide V3.0
the time and there is consensus about their value and Particularly in high-technology applications
usefulness. “Good practice” means there is general and high-consequence projects, the management
agreement that the application of these skills, tools, of risk is an important aspect of the overall proj-
and techniques can enhance the chances of success ect management responsibilities. This standard
over a wide range of projects. Good practice does deals with that subject.
not mean the knowledge described should always
be applied uniformly to all projects; the organiza-
tion and/or project management team is respon- IEEE Std. 16085-2006 (a.k.a. ISO/IEC 16085:2006)
sible for determining what is appropriate for any Standard for Systems and Software Engineering—
given project. The PMBOK® Guide also provides Software Life Cycle Processes—Risk Management
and promotes a common vocabulary within the
project management profession for discussing, ISO/IEC 16085:2006 defines a process for the
writing, and applying project management con- management of risk in the life cycle. It can be
cepts. Such a standard vocabulary is an essential added to the existing set of system and software
element of a professional discipline. The Project life cycle processes defined by ISO/IEC 15288 and
Management Institute (PMI) views this standard ISO/IEC 12207, or it can be used independently.
as a foundational project management reference ISO/IEC 16085:2006 can be applied equally to
for its professional development programs and systems and software.
certifications. The purpose of risk management is to iden-
tify potential managerial and technical problems
before they occur so that actions can be taken that
The 2008 revisions of ISO/IEC/IEEE 12207 reduce or eliminate the probability and/or impact
and 15288 provide project management pro- of these problems should they occur. It is a criti-
cesses for software and systems and relate them cal tool for continuously determining the feasi-
to organization-level processes as well as tech- bility of project plans, for improving the search
nical processes. The jointly developed 16326 for and identification of potential problems that
standard, replacing two older standards, expands can affect life cycle activities and the quality and
those provisions with guidance for application. performance of products, and for improving the
active management of projects.
if the analysis results are valid. The measurement to produce or manage documentation, and applies
process is flexible, tailorable, and adaptable to the to both printed documentation and onscreen docu-
needs of different users. mentation. Much of its guidance is applicable to
ISO/IEC 15939:2007 identifies a process that user documentation for systems including hard-
supports defining a suitable set of measures that ware as well as software.
address specific information needs. It identifies the
activities and tasks that are necessary to success-
fully identify, define, select, apply, and improve Sometimes software or system components are
measurement within an overall project or organi- acquired rather than developed.
zational measurement structure. It also provides
definitions for measurement terms commonly used
within the system and software industries. IEEE Std. 1062-1998 Recommended Practice for
Software Acquisition
Software projects often require the develop- A set of useful quality practices that can be
ment of user documentation. Management of the selected and applied during one or more steps in
project, therefore, includes management of the a software acquisition process is described. This
documentation effort. recommended practice can be applied to software
that runs on any computer system regardless of
the size, complexity, or criticality of the software,
ISO/IEC/IEEE 26511:2012 Systems and Software but is more suited for use on modified-off-the-
Engineering—Requirements for Managers of User shelf software and fully developed software.
Documentation
software user documentation. These requirements improved practices. For example, one might pro-
are central to the user documentation specification pose an improved practice for software require-
and statement of work. It includes requirements ments analysis. A naïve treatment might relate
for primary document outputs of the acquisition the description to an early stage of the life cycle
and supply process: the request for proposal and model. A superior approach is to describe the
the proposal for user documentation products and practice in the context of a process that can be
services. It also discusses the use of a documen- applied at any stage of the life cycle. The require-
tation management plan and a document plan as ments analysis process, for example, is neces-
they arise in the acquisition and supply processes. sary for the development stage, for maintenance,
ISO/IEC/IEEE 26512:2011 is independent of the and often for retirement, so an improved practice
software tools that may be used to produce docu- described in terms of the requirements analysis
mentation and applies to both printed documen- process can be applied to any of those stages.
tation and onscreen documentation. Much of its The two key standards are ISO/IEC/IEEE
guidance is applicable to user documentation for 12207, Software Life Cycle Processes, and ISO/
systems including hardware as well as software. IEC/IEEE 15288, System Life Cycle Processes.
The two standards have distinct histories, but
they were both revised in 2008 to align their pro-
The next two standards are mentioned here cesses, permitting their interoperable use across a
because they supply information used in manage- wide spectrum of projects ranging from a stand-
ment decision-making. alone software component to a system with neg-
ligible software content. Both are being revised
again with the intent of containing an identical
IEEE Std. 1028-2008 Standard for Software Reviews list of processes, but with provisions specialized
and Audits for the respective disciplines.
See Software Quality KA
IEEE Std. 1061-1998 Standard for Software Quality IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008)
Metrics Methodology Standard for Systems and Software Engineering—
See Software Quality KA Software Life Cycle Processes
IEEE Std. 15288-2008 (a.k.a. ISO/IEC 15288:2008) information items (information products, docu-
Standard for Systems and Software Engineering— mentation) to be developed and revised during
System Life Cycle Processes systems and software life cycles and service
management processes. It specifies the purpose
ISO/IEC 15288:2008 establishes a common and content of all identified systems and software
framework for describing the life cycle of sys- data records and life cycle information items, as
tems created by humans. It defines a set of well as records and information items for infor-
processes and associated terminology. These mation technology service management. The
processes can be applied at any level in the information item contents are defined according
hierarchy of a system’s structure. Selected sets to generic document types (description, plan, pol-
of these processes can be applied throughout icy, procedure, report, request, and specification)
the life cycle for managing and performing the and the specific purpose of the document. For
stages of a system’s life cycle. This is accom- simplicity of reference, each information item
plished through the involvement of all interested is described as if it were published as a separate
parties, with the ultimate goal of achieving cus- document. However, information items may be
tomer satisfaction. unpublished but available in a repository for ref-
ISO/IEC 15288:2008 also provides processes erence, divided into separate documents or vol-
that support the definition, control, and improve- umes, or combined with other information items
ment of the life cycle processes used within an into one document. ISO/IEC/IEEE 15289:2011
organization or a project. Organizations and is based on the life cycle processes specified in
projects can use these life cycle processes when ISO/IEC 12207:2008 (IEEE Std. 12207-2008)
acquiring and supplying systems. and ISO/IEC 15288:2008 (IEEE Std. 15288-
ISO/IEC 15288:2008 concerns those systems 2008), and the service management processes
that are man-made and may be configured with specified in ISO/IEC 20000-1:2005 and ISO/IEC
one or more of the following: hardware, software, 20000-2:2005.
data, humans, processes (e.g., processes for pro-
viding service to users), procedures (e.g., opera-
tor instructions), facilities, materials, and natu- The next two guides provide supplementary
rally occurring entities. When a system element is information helpful in applying 12207 and 15288.
software, the software life cycle processes docu-
mented in ISO/IEC 12207:2008 may be used to
implement that system element. IEEE Std. 24748.2-2012 Guide—Adoption of ISO/
ISO/IEC 15288:2008 and ISO/IEC 12207:2008 IEC TR 24748-2:2011 Systems and Software Engi-
are harmonized for concurrent use on a single neering—Life Cycle Management—Part 2: Guide to
project or in a single organization. the Application of ISO/IEC 15288 (System Life Cycle
Processes)
Those two standards specify that processes ISO/IEC TR 24748-2 is a guide for the applica-
may produce items of information but do not pre- tion of ISO/IEC 15288:2008. It addresses sys-
scribe their content or format. The next standard tem, life cycle, process, organizational, project,
provides help with that. and adaptation concepts, principally through
reference to ISO/IEC TR 24748-1 and ISO/IEC
15288:2008. It then gives guidance on applying
ISO/IEC/IEEE 15289:2011 Systems and Software ISO/IEC 15288:2008 from the aspects of strat-
Engineering—Content of Life-Cycle Information egy, planning, application in organizations, and
Products (Documentation) application on projects.
The 12207 and 15288 standards provide pro- A common framework for extending the system
cesses covering the life cycle, but they do not pro- and software life cycle processes of IEEE Std.
vide a standard life cycle model (waterfall, incre- 12207:2008 to include the systematic practice
mental delivery, prototype-driven, etc). Selecting of reuse is provided. The processes, activities,
an appropriate life cycle model for a project is a and tasks to be applied during each life cycle
major concern of ISO/IEC 24748-1. process to enable a system and/or product to be
constructed from reusable assets are specified.
The processes, activities, and tasks to enable
IEEE Std. 24748.1-2011 Guide—Adoption of ISO/ the identification, construction, maintenance,
IEC TR 24748-1:2010 Systems and Software Engi- and management of assets supplied are also
neering—Life Cycle Management—Part 1: Guide specified.
for Life Cycle Management
ISO/IEC TR 24748-1 provides information on IEEE Std. 1220 has been widely applied as a
life cycle concepts and descriptions of the pur- systems engineering process and was adopted by
poses and outcomes of representative life cycle ISO/IEC with the number 26702. Unfortunately,
stages. It also illustrates the use of a life cycle the standard is not completely compatible with
model for systems in the context of ISO/IEC ISO/IEC/IEEE 15288 and is being revised to
15288 and provides a corresponding illustration solve that problem. The result will be published
of the use of a life cycle model for software in the as ISO/IEC/IEEE 24748-4.
context of ISO/IEC 12207. ISO/IEC TR 24748-1
additionally provides detailed discussion and
advice on adapting a life cycle model for use in a IEEE Std. 1220-2005 (a.k.a. ISO/IEC 26702:2007)
specific project and organizational environment. Standard for Application and Management of the
It further provides guidance on life cycle model Systems Engineering Process
use by domains, disciplines and specialties. ISO/
IEC TR 24748-1 gives a detailed comparison ISO/IEC 26702 defines the interdisciplinary tasks
between prior and current versions of ISO/IEC which are required throughout a system’s life
12207 and ISO/IEC 15288 as well as advice on cycle to transform customer needs, requirements,
transitioning from prior to current versions and and constraints into a system solution. In addi-
on using their application guides. The discus- tion, it specifies the requirements for the systems
sion and advice are intended to provide a refer- engineering process and its application through-
ence model for life cycle models, facilitate use of out the product life cycle. ISO/IEC 26702:2007
the updated ISO/IEC 15288 and ISO/IEC 12207, focuses on engineering activities necessary to
and provide a framework for the development of guide product development, while ensuring
Appendix B B-15
that the product is properly designed to make it A VSE could obtain an ISO/IEC 29110 Certi-
affordable to produce, own, operate, maintain, fication. The set of technical reports is available
and eventually dispose of without undue risk to at no cost on the ISO website. Many ISO 29110
health or the environment. documents are available in English, Spanish, Por-
tuguese, Japanese, and French.
All of the standards described so far in this sec- • is applicable across all application domains
tion provide a basis for defining processes. Some and sizes of organization; and
users are interested in assessing and improving • may provide an objective benchmark
their processes after implementation. The 15504 between organizations.
series provides for process assessment; it is cur-
rently being revised and renumbered 330xx. The minimum set of requirements defined in
ISO/IEC 15504-2:2003 ensures that assessment
results are objective, impartial, consistent, repeat-
ISO/IEC 15504 [ten parts] Information Technol- able, and representative of the assessed processes.
ogy—Process Assessment Results of conformant process assessments may
be compared when the scopes of the assessments
ISO/IEC 15504-2:2003 defines the requirements are considered to be similar; for guidance on this
for performing process assessment as a basis matter, refer to ISO/IEC 15504-4.
for use in process improvement and capability
determination.
Process assessment is based on a two-dimen- Several other standards are mentioned here
sional model containing a process dimension and because they are written as elaborations of the
a capability dimension. The process dimension is processes of 12207 or 15288. They are allocated
provided by an external process reference model to other KAs because each one deals with topics
(such as 12207 or 15288), which defines a set of described in those other KAs.
processes characterized by statements of process
purpose and process outcomes. The capability
dimension consists of a measurement framework IEEE Std. 828-2012 Standard for Configuration
comprising six process capability levels and their Management in Systems and Software Engineering
associated process attributes. See Software Configuration Management KA
The assessment output consists of a set of pro-
cess attribute ratings for each process assessed, IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006)
termed the process profile, and may also include Standard for Software Engineering—Software Life
the capability level achieved by that process. Cycle Processes—Maintenance
ISO/IEC 15504-2:2003 identifies the measure- See Software Maintenance KA
ment framework for process capability and the
requirements for ISO/IEC 15026-4:2012 Systems and Software Engi-
neering—Systems and Software Assurance—Part 4:
• performing an assessment; Assurance in the Life Cycle
• process reference models; See Software Quality KA
• process assessment models;
• verifying conformity of process assessment. IEEE Std. 15939-2008 Standard Adoption of ISO/
IEC 15939:2007 Systems and Software Engineer-
The requirements for process assessment ing—Measurement Process
defined in ISO/IEC 15504-2:2003 form a struc- See Software Engineering Management KA
ture that
ISO/IEC 15940:2006 Information Technology—
• facilitates self-assessment; Software Engineering Environment Services
• provides a basis for use in process improve- See Software Engineering Models and
ment and capability determination; Methods KA
• takes into account the context in which the
assessed process is implemented; IEEE Std. 16085-2006 (a.k.a. ISO/IEC 16085:2006)
• produces a process rating; Standard for Systems and Software Engineering—
• addresses the ability of the process to achieve Software Life Cycle Processes—Risk Management
its purpose; See Software Engineering Management KA
Appendix B B-17
ISO/IEC/IEEE 16326:2009 Systems and Soft- example. Neither S2ESC nor SC 7 has a standard
ware Engineering—Life Cycle Processes—Project for agile development, but there is a standard
Management for developing user documentation in an agile
See Software Engineering Management KA project.
understanding, support analysis, provide logic for The next two standards provide two versions of
potential changes, specify requirements, and sup- the UML language.
port system-level design and integration activi-
ties. IDEF0 may be used to model a wide variety
of systems, composed of people, machines, mate- ISO/IEC 19501:2005 Information Technology—
rials, computers, and information of all varieties, Open Distributed Processing—Unified Modeling
and structured by the relationships among them, Language (UML) Version 1.4.2
both automated and nonautomated. For new sys-
tems, IDEF0 may be used first to define require- ISO/IEC 19501 describes the Unified Model-
ments and to specify the functions to be carried ing Language (UML), a graphical language for
out by the future system. As the basis of this visualizing, specifying, constructing, and docu-
architecture, IDEF0 may then be used to design menting the artifacts of a software-intensive sys-
an implementation that meets these requirements tem. The UML offers a standard way to write a
and performs these functions. For existing sys- system’s blueprints, including conceptual things
tems, IDEF0 can be used to analyze the functions such as business processes and system functions
that the system performs and to record the means as well as concrete things such as programming
by which these are done. language statements, database schemas, and reus-
able software components.
IEEE Std. 1320.2-1998 Standard for Conceptual
Modeling Language—Syntax and Semantics for ISO/IEC 19505:2012 [two parts] Information Tech-
IDEF1X97 (IDEFobject) nology—Object Management Group Unified Model-
ing Language (OMG UML)
IDEF1X 97 consists of two conceptual modeling
languages. The key-style language supports data/ ISO/IEC 19505 defines the Unified Modeling
information modeling and is downward compat- Language (UML), revision 2. The objective of
ible with the US government’s 1993 standard, UML is to provide system architects, software
FIPS PUB 184. The identity-style language is engineers, and software developers with tools for
based on the object model with declarative rules analysis, design, and implementation of software-
and constraints. IDEF1X 97 identity style includes based systems as well as for modeling business
constructs for the distinct but related components and similar processes.
of object abstraction: interface, requests, and
realization; utilizes graphics to state the interface;
and defines a declarative, directly executable rule Two more standards build on the base of UML
and constraint language for requests and realiza- to provide additional modeling capabilities:
tions. IDEF1X 97 conceptual modeling supports
implementation by relational databases, extended
relational databases, object databases, and object ISO/IEC 19506:2012 Information Technology—
programming languages. IDEF1X 97 is formally Object Management Group Architecture-Driven
defined in terms of first order logic. A procedure Modernization (ADM)—Knowledge Discovery
is given whereby any valid IDEF1X 97 model Meta-Model (KDM)
can be transformed into an equivalent theory in
first order logic. That procedure is then applied to ISO/IEC 19506:2012 defines a metamodel for rep-
a metamodel of IDEF1X 97 to define the valid set resenting existing software assets, their associa-
of IDEF1X 97 models. tions, and operational environments, referred to as
the knowledge discovery metamodel (KDM). This
is the first in the series of specifications related to
In recent years, the UML notation has become software assurance (SwA) and architecture-driven
popular for modeling software-intensive systems. modernization (ADM) activities. KDM facilitates
Appendix B B-19
projects that involve existing software systems Within systems and software engineering, com-
by insuring interoperability and exchange of data puter-aided software engineering (CASE) tools
between tools provided by different vendors. represent a major part of the supporting tech-
nologies used to develop and maintain informa-
ISO/IEC 19507:2012 Information Technology— tion technology systems. Their selection must be
Object Management Group Object Constraint Lan- carried out with careful consideration of both the
guage (OCL) technical and management requirements.
ISO/IEC 14102:2008 defines both a set of pro-
ISO/IEC 19507:2012 defines the Object Con- cesses and a structured set of CASE tool char-
straint Language (OCL), version 2.3.1. OCL ver- acteristics for use in the technical evaluation and
sion 2.3.1 is the version of OCL that is aligned the ultimate selection of a CASE tool. It follows
with UML 2.3 and MOF 2.0. the software product evaluation model defined in
ISO/IEC 14598-5:1998.
ISO/IEC 14102:2008 adopts the general model
Some organizations invest in software engi- of software product quality characteristics and
neering environments (SEE) to assist in the subcharacteristics defined in ISO/IEC 9126-
construction of software. An SEE, per se, is not 1:2001 and extends these when the software
a replacement for sound processes. However, a product is a CASE tool; it provides product char-
suitable SEE must support the processes that acteristics unique to CASE tools.
have been chosen by the organization.
ISO/IEC 15940:2006 defines software engineering IEEE Std. 14471-2010 Guide—Adoption of ISO/IEC
environment (SEE) services conceptually in a refer- TR 14471:2007 Information Technology—Software
ence model that can be adapted to any SEEs to auto- Engineering—Guidelines for the Adoption of CASE
mate one or more software engineering activities. Tools
It describes services that support the process defini-
tions as in ISO/IEC 12207 so that the set of SEE The purpose of ISO/IEC TR 14471:2007 is to
services is compatible with ISO/IEC 12207. ISO/ provide a recommended practice for CASE adop-
IEC 15940:2006 can be used either as a general ref- tion. It provides guidance in establishing pro-
erence or to define an automated software process. cesses and activities that are to be applied for
the successful adoption of CASE technology.
The use of ISO/IEC TR 14471:2007 will help
The selection of tooling for a software engineering to maximize the return and minimize the risk of
environment is itself a difficult task. Two standards investing in CASE technology. However, ISO/
provide some assistance. ISO/IEC 14102:2008 IEC TR 14471:2007 does not establish compli-
defines both a set of processes and a structured set of ance criteria.
computer-aided software engineering (CASE) tool It is best used in conjunction with ISO/IEC
characteristics for use in the technical evaluation 14102 for CASE tool evaluation and selection. It
and the ultimate selection of a CASE tool. neither dictates nor advocates particular develop-
ment standards, software processes, design meth-
ods, methodologies, techniques, programming
IEEE Std. 14102-2010 Standard Adoption of ISO/ languages, or life cycle paradigms.
IEC 14102:2008 Information Technology—Guide-
line for the Evaluation and Selection of CASE Tools
B-20 SWEBOK® Guide V3.0
Within a software engineering environment, it for the Application of ISO 9001:2000 to Computer
is important for the various tools to interoperate. Software
The following standards provide a scheme for
interconnection. ISO/IEC 90003 provides guidance for organiza-
tions in the application of ISO 9001:2000 to the
acquisition, supply, development, operation, and
IEEE Std. 1175.1-2002 Guide for CASE Tool Inter- maintenance of computer software and related
connections—Classification and Description support services. ISO/IEC 90003:2004 does not
add to or otherwise change the requirements of
IEEE Std. 1175.2-2006 Recommended Practice for ISO 9001:2000.
CASE Tool Interconnection—Characterization of The guidelines provided in ISO/IEC
Interconnections 90003:2004 are not intended to be used as assess-
ment criteria in quality management system
IEEE Std. 1175.3-2004 Standard for CASE Tool registration/certification.
Interconnections—Reference Model for Specifying The application of ISO/IEC 90003:2004 is
Software Behavior appropriate to software that is
IEEE Std. 1175.4-2008 Standard for CASE Tool • part of a commercial contract with another
Interconnections—Reference Model for Specifying organization,
System Behavior • a product available for a market sector,
• used to support the processes of an
The purpose of this family of standards is to spec- organization,
ify a common set of modeling concepts based • embedded in a hardware product, or
on those found in commercial CASE tools for • related to software services.
describing the operational behavior of a software
system. These standards establish a uniform, Some organizations may be involved in all
integrated model of software concepts related to the above activities; others may specialize in
software functionality. They also provide a tex- one area. Whatever the situation, the organiza-
tual syntax for expressing the common properties tion’s quality management system should cover
(attributes and relationships) of those concepts as all aspects (software related and nonsoftware
they have been used to model software behavior. related) of the business.
ISO/IEC 90003:2004 identifies the issues
which should be addressed and is independent
SOFTWARE QUALITY of the technology, life cycle models, develop-
ment processes, sequence of activities, and
One viewpoint of software quality starts with organizational structure used by an organiza-
ISO 9001, Quality Management Requirements, tion. Additional guidance and frequent ref-
dealing with quality policy throughout an orga- erences to the ISO/IEC JTC 1/SC 7 software
nization. The terminology of that standard may engineering standards are provided to assist in
be unfamiliar to software professionals, and the application of ISO 9001:2000: in particu-
quality management auditors may be unfamiliar lar, ISO/IEC 12207, ISO/IEC TR 9126, ISO/
with software jargon. The following standard IEC 14598, ISO/IEC 15939, and ISO/IEC TR
describes the relationship between ISO 9001 and 15504.
ISO/IEC 12207. Unfortunately, the current ver-
sion refers to obsolete editions of both; a replace-
ment is in progress: The ISO 9001 approach posits an organiza-
tion-level quality management process paired
with project-level quality assurance planning
IEEE Std. 90003-2008 Guide—Adoption of ISO/ to achieve the organizational goals. IEEE 730
IEC 90003:2004 Software Engineering—Guidelines describes project-level quality planning. It is
Appendix B B-21
ISO/IEC 25000 through 25099 Software Engineer- ISO/IEC 25010:2011 defines the following:
ing—Software Product Quality Requirements and
Evaluation (SQuaRE) 1. A quality in-use model composed of five
characteristics (some of which are further
subdivided into subcharacteristics) that
A few of the SQuaRE standards are selected relate to the outcome of interaction when a
below for particular attention. The first is the product is used in a particular context of use.
overall guide to the series. This system model is applicable to the com-
plete human-computer system, including
both computer systems in use and software
ISO/IEC 25000:2005 Software Engineering—Soft- products in use.
ware Product Quality Requirements and Evaluation 2. A product quality model composed of eight
(SQuaRE)—Guide to SQuaRE characteristics (which are further subdivided
into subcharacteristics) that relate to static
ISO/IEC 25000:2005 provides guidance for the properties of software and dynamic proper-
use of the new series of international standards ties of the computer system. The model is
named Software product Quality Requirements applicable to both computer systems and
and Evaluation (SQuaRE). The purpose of this software products.
guide is to provide a general overview of SQuaRE
contents, common reference models, and defini- The characteristics defined by both models
tions, as well as the relationship among the docu- are relevant to all software products and com-
ments, allowing users of this guide a good under- puter systems. The characteristics and subchar-
standing of those international standards. This acteristics provide consistent terminology for
document contains an explanation of the transi- specifying, measuring, and evaluating system
tion process between the old ISO/IEC 9126 and and software product quality. They also provide
the 14598 series and SQuaRE, and also presents a set of quality characteristics against which
information on how to use the ISO/IEC 9126 and stated quality requirements can be compared for
14598 series in their previous form. completeness.
B-22 SWEBOK® Guide V3.0
Although the scope of the product quality Evaluation (SQuaRE)—Common Industry Format
model is intended to be software and computer (CIF) for Usability
systems, many of the characteristics are also rel-
evant to wider systems and services. A family of international standards, named the
ISO/IEC 25012 contains a model for data qual- Common Industry Formats (CIF), documents
ity that is complementary to this model. the specification and evaluation of the usability
The scope of the models excludes purely func- of interactive systems. It provides a general over-
tional properties, but it does include functional view of the CIF framework and contents, defini-
suitability. tions, and the relationship of the framework ele-
The scope of application of the quality models ments. The intended users of the framework are
includes supporting specification and evaluation identified, as well as the situations in which the
of software and software-intensive computer sys- framework may be applied. The assumptions and
tems from different perspectives by those who are constraints of the framework are also enumerated.
associated with their acquisition, requirements, The framework content includes the following:
development, use, evaluation, support, mainte-
nance, quality assurance and control, and audit. • consistent terminology and classification of
The models can, for example, be used by devel- specification, evaluation, and reporting;
opers, acquirers, quality assurance and control • a definition of the type and scope of formats
staff, and independent evaluators, particularly and the high-level structure to be used for
those responsible for specifying and evaluating documenting required information and the
software product quality. Activities during prod- results of evaluation.
uct development that can benefit from the use of
the quality models include The CIF family of standards is applicable to
software and hardware products used for pre-
• identifying software and system requirements; defined tasks. The information items are intended
• validating the comprehensiveness of a to be used as part of system-level documentation
requirements definition; resulting from development processes such as
• identifying software and system design those in ISO 9241-210 and ISO/IEC JTC 1/SC 7
objectives; process standards.
• identifying software and system testing The CIF family focuses on documenting those
objectives; elements needed for design and development of
• identifying quality control criteria as part of usable systems, rather than prescribing a specific
quality assurance; process. It is intended to be used in conjunction
• identifying acceptance criteria for a software with existing international standards, includ-
product and/or software-intensive computer ing ISO 9241, ISO 20282, ISO/IEC 9126, and
system; the SQuaRE series (ISO/IEC 25000 to ISO/IEC
• establishing measures of quality characteris- 25099).
tics in support of these activities. The CIF family of standards does not prescribe
any kind of method, life cycle or process.
In many cases, a database of software anoma- use of each part and the combined use of multiple
lies is used to support verification and validation parts. Coverage of assurance for a service being
activities. The following standard suggests how operated and managed on an ongoing basis is not
anomalies should be classified. covered in ISO/IEC 15026.
IEEE Std. 1044-2009 Standard for Classification for The second part of the standard describes the
Software Anomalies structure of an “assurance case,” which is intended
as a structured argument that the critical property
This standard provides a uniform approach to the has been achieved. It is a generalization of various
classification of software anomalies, regardless domain-specific constructs like “safety cases.”
of when they originate or when they are encoun-
tered within the project, product, or system life
cycle. Classification data can be used for a vari- IEEE Std. 15026.2-2011 Standard Adoption of ISO/
ety of purposes, including defect causal analy- IEC 15026-2:2011 Systems and Software Engineer-
sis, project management, and software process ing—Systems and Software Assurance—Part 2:
improvement (e.g., to reduce the likelihood of Assurance Case
defect insertion and/or increase the likelihood of
early defect detection). ISO/IEC 15026-2:2011 is adopted by this stan-
dard. ISO/IEC 15026-2:2011 specifies minimum
requirements for the structure and contents of an
In some systems, one particular property of the assurance case to improve the consistency and
software is so important that it requires special comparability of assurance cases and to facili-
treatment beyond that provided by a conven- tate stakeholder communications, engineering
tional verification and validation program. The decisions, and other uses of assurance cases. An
emerging term for this sort of treatment is “sys- assurance case includes a top-level claim for a
tems and software assurance.” Examples include property of a system or product (or set of claims),
safety, privacy, high security, and ultrareliability. systematic argumentation regarding this claim,
The 15026 standard is under development to deal and the evidence and explicit assumptions that
with such situations. The first part of the four-part underlie this argumentation. Arguing through
standard provides terminology and concepts used multiple levels of subordinate claims, this struc-
in the remaining parts. It was first written before tured argumentation connects the top-level claim
the other parts and is now being revised for com- to the evidence and assumptions. Assurance
plete agreement with the others. cases are generally developed to support claims
in areas such as safety, reliability, maintain-
ability, human factors, operability, and security,
IEEE Std. 15026.1-2011 Trial-Use Standard Adop- although these assurance cases are often called
tion of ISO/IEC TR 15026-1:2010 Systems and Soft- by more specific names, e.g., safety case or reli-
ware Engineering—Systems and Software Assur- ability and maintainability (R&M) case. ISO/IEC
ance—Part 1: Concepts and Vocabulary 15026-2:2011 does not place requirements on
the quality of the contents of an assurance case
This trial-use standard adopts ISO/IEC TR and does not require the use of a particular termi-
15026-1:2010, which defines terms and estab- nology or graphical representation. Likewise, it
lishes an extensive and organized set of concepts places no requirements on the means of physical
and their relationships for software and systems implementation of the data, including no require-
assurance, thereby establishing a basis for shared ments for redundancy or colocation.
understanding of the concepts and principles cen-
tral to ISO/IEC 15026 across its user communi-
ties. It provides information to users of the sub- In many systems, some portions are critical to
sequent parts of ISO/IEC 15026, including the achieving the desired property while others are only
Appendix B B-25
incidental. For example, the flight control system of TR 15026-1 provides additional information and
an airliner is critical to safety, but the microwave references to aid users of ISO/IEC 15026-3:2011.
oven is not. Conventionally, the various portions ISO/IEC 15026-3:2011 does not require the
are assigned “criticality levels” to indicate their sig- use of the assurance cases described by ISO/IEC
nificance to the overall achievement of the property. 15026-2 but describes how integrity levels and
The third part of ISO/IEC 15026 describes how that assurance cases can work together, especially in
is done. This part will be revised for better fit with the definition of specifications for integrity levels
the remainder of the 15026 standard. or by using integrity levels within a portion of an
assurance case.
One important use of integrity levels is by sup- The next standard deals with a property—
pliers and acquirers in agreements; for example, safety—that is often identified as critical. It was
to aid in assuring safety, economic, or security originally developed in cooperation with the US
characteristics of a delivered system or product. nuclear power industry.
ISO/IEC 15026-3:2011 does not prescribe a
specific set of integrity levels or their integrity
level requirements. In addition, it does not pre- IEEE Std. 1228-1994 Standard for Software Safety
scribe the way in which integrity level use is inte- Plans
grated with the overall system or software engi-
neering life cycle processes. The minimum acceptable requirements for the
ISO/IEC 15026-3:2011 can be used alone or content of a software safety plan are established.
with other parts of ISO/IEC 15026. It can be used This standard applies to the software safety plan
with a variety of technical and specialized risk used for the development, procurement, mainte-
analysis and development approaches. ISO/IEC nance, and retirement of safety-critical software.
B-26 SWEBOK® Guide V3.0
MATHEMATICAL FOUNDATIONS
ISO/IEC TR 19759:2005 Software Engineer-
ing—Guide to the Software Engineering Body of No standards are allocated to this KA.
Appendix B B-27
Some readers will want to obtain standards The SWEBOK Guide is published under an IEEE
described in this article. The first thing to copyright. The current version of the SWEBOK
know is that some international standards are Guide is available free to the public at www.
available free for individual use. The current swebok.org/. The ISO/IEC adoption of the
list of ISO/IEC standards available under these SWEBOK Guide, ISO/IEC TR 19759, is one of
terms is located at http://standards.iso.org/ittf/ the freely available standards.
PubliclyAvailableStandards/index.html.
One of the publicly available standards is the
ISO/IEC adoption of the SWEBOK Guide, ISO/
IEC 19759.
B-28 SWEBOK® Guide V3.0
The Consolidated Reference List identifies all [4*] F. Bott et al., Professional Issues in
recommended reference materials (to the level of Software Engineering, 3rd ed., Taylor &
section number) that accompany the breakdown Francis, 2000.
of topics within each knowledge area (KA). This
Consolidated Reference List is adopted by the [5*] J.G. Brookshear, Computer Science: An
software engineering certification and associated Overview, 10th ed., Addison-Wesley, 2008.
professional development products offered by the
IEEE Computer Society. KA Editors used the ref- [6*] D. Budgen, Software Design, 2nd ed.,
erences allocated to their KA by the Consolidated Addison-Wesley, 2003.
Reference List as their Recommended References.
Collectively this Consolidated Reference List is [7*] E.W. Cheney and D.R. Kincaid, Numerical
Mathematics and Computing, 6th ed.,
• Complete: Covering the entire scope of the Brooks/Cole, 2007.
SWEBOK Guide.
• Sufficient: Providing enough information to [8*] P. Clements et al., Documenting Software
describe “generally accepted” knowledge. Architectures: Views and Beyond, 2nd ed.,
• Consistent: Not providing contradictory Pearson Education, 2010.
knowledge nor conflicting practices.
• Credible: Recognized as providing expert [9*] R.E. Fairley, Managing and Leading
treatment. Software Projects, Wiley-IEEE Computer
• Current: Treating the subject in a manner that Society Press, 2009.
is commensurate with currently generally
accepted knowledge. [10*] D. Galin, Software Quality Assurance:
• Succinct: As short as possible (both in num- From Theory to Implementation, Pearson
ber of reference items and in total page Education Limited, 2004.
count) without failing other objectives.
[11*] E. Gamma et al., Design Patterns:
[1*] J.H. Allen et al., Software Security Elements of Reusable Object-Oriented
Engineering: A Guide for Project Software, 1st ed., Addison-Wesley
Managers, Addison-Wesley, 2008. Professional, 1994.
[2*] M. Bishop, Computer Security: Art and [12*] P. Grubb and A.A. Takang, Software
Science, Addison-Wesley, 2002. Maintenance: Concepts and Practice, 2nd
ed., World Scientific Publishing, 2003.
[3*] B. Boehm and R. Turner, Balancing Agility
and Discipline: A Guide for the Perplexed, [13*] A.M.J. Hass, Configuration Management
Addison-Wesley, 2003. Principles and Practices, 1st ed., Addison-
Wesley, 2003.
C-1
C-2 SWEBOK® Guide V3.0
[14*] E. Horowitz et al., Computer Algorithms, [25*] S. Naik and P. Tripathy, Software Testing
2nd ed., Silicon Press, 2007. and Quality Assurance: Theory and
Practice, Wiley-Spektrum, 2008.
[15*] IEEE CS/ACM Joint Task Force on
Software Engineering Ethics and [26*] J. Nielsen, Usability Engineering, 1st ed.,
Professional Practices, “Software Morgan Kaufmann, 1993.
Engineering Code of Ethics and
Professional Practice (Version 5.2),” 1999; [27*] L. Null and J. Lobur, The Essentials of
www.acm.org/serving/se/code.htm. Computer Organization and Architecture,
2nd ed., Jones and Bartlett Publishers,
[16*] IEEE Std. 828-2012, Standard for 2006.
Configuration Management in Systems and
Software Engineering, IEEE, 2012. [28*] M. Page-Jones, Fundamentals of Object-
Oriented Design in UML, 1st ed., Addison-
[17*] IEEE Std. 1028-2008, Software Reviews Wesley, 1999.
and Audits, IEEE, 2008.
[29*] K. Rosen, Discrete Mathematics and Its
[18*] ISO/IEC 14764 IEEE Std. 14764-2006, Applications, 7th ed., McGraw-Hill, 2011.
Software Engineering—Software Life Cycle
Processes—Maintenance, IEEE, 2006. [30*] A. Silberschatz, P.B. Galvin, and G.
Gagne, Operating System Concepts, 8th
[19*] S.H. Kan, Metrics and Models in Software ed., Wiley, 2008.
Quality Engineering, 2nd ed., Addison-
Wesley, 2002. [31*] H.M. Sneed, “Offering Software
Maintenance as an Offshore Service,” Proc.
[20*] S. McConnell, Code Complete, 2nd ed., IEEE Int’l Conf. Software Maintenance
Microsoft Press, 2004. (ICSM 08), IEEE, 2008, pp. 1–5.
[21*] J. McGarry et al., Practical Software [32*] I. Sommerville, Software Engineering, 9th
Measurement: Objective Information ed., Addison-Wesley, 2011.
for Decision Makers, Addison-Wesley
Professional, 2001. [33*] S. Tockey, Return on Software:
Maximizing the Return on Your Software
[22*] S.J. Mellor and M.J. Balcer, Executable Investment, 1st ed., Addison-Wesley, 2004.
UML: A Foundation for Model-Driven
Architecture, 1st ed., Addison-Wesley, [34*] G. Voland, Engineering by Design, 2nd
2002. ed., Prentice Hall, 2003.
[23*] D.C. Montgomery and G.C. Runger, [35*] K.E. Wiegers, Software Requirements, 2nd
Applied Statistics and Probability for ed., Microsoft Press, 2003.
Engineers, 4th ed., Wiley, 2007.
[36*] J.M. Wing, “A Specifier’s Introduction to
[24*] J.W. Moore, The Road Map to Software Formal Methods,” Computer, vol. 23, no. 9,
Engineering: A Standards-Based Guide, 1st 1990, pp. 8, 10–23.
ed., Wiley-IEEE Computer Society Press,
2006.