xxx SWEBOK Guide V3.0 MOTIONS REGARDING THE APPROVAL OF 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. MOTIONS REGARDING THE APPROVAL OF SWEBOK GUIDE 2004 VERSION 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 ofGovernors 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
xxx SWEBOK® Guide V3.0 MOTIONS REGARDING THE APPROVAL OF 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 Computer Society in December 2013: The Professional Activities Board of the IEEE Computer Society finds that the Guide to the Software 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 Professional Activities Board to proceed with printing. MOTIONS REGARDING THE APPROVAL OF SWEBOK GUIDE 2004 VERSION 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 initiated 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 Professional 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 Software Engineering Body of literature.The purpose of the Guide is to describe SWEBOK Knowledge the portion of the Body of Knowledge that is gen- 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 Softvare 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)." 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. See www.computer.org/sevocab. XXxi
xxxi INTRODUCTION TO THE GUIDE KA Knowledge Area SWEBOK Software Engineering Body of Knowledge Publication of the 2004 version of this Guide to the Software Engineering Body of Knowledge (SWEBOK 2004) was a major milestone in establishing software engineering as a recognized engineering discipline. The goal in developing this update to SWEBOK is to improve the currency, readability, consistency, and usability of the Guide. All knowledge areas (KAs) have been updated to reflect changes in software engineering since publication of SWEBOK 2004. Four new foundation KAs and a Software Engineering Professional Practices KA have been added. The Software Engineering Tools and Methods KA has been revised as Software Engineering Models and Methods. Software engineering tools is now a topic in each of the KAs. Three appendices provide the specifications for the KA description, an annotated set of relevant standards for each KA, and a listing of the references cited in the Guide. This Guide, written under the auspices of the Professional Activities Board of the IEEE Computer Society, represents a next step in the evolution of the software engineering profession. WHAT IS SOFTWARE ENGINEERING? ISO/IEC/IEEE Systems and Software Engineering Vocabulary (SEVOCAB) defines software engineering as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software).”1 WHAT ARE THE OBJECTIVES OF THE SWEBOK GUIDE? The Guide should not be confused with the Body of Knowledge itself, which exists in the published 1 See www.computer.org/sevocab. literature. The purpose of the Guide is to describe the portion of the Body of Knowledge that is generally accepted, to organize that portion, and to provide topical access to it. The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide) was established with the following five objectives: 1.To promote a consistent view of software engineering worldwide 2.To specify the scope of, and clarify the place of software engineering with respect to other disciplines such as computer science, project management, computer engineering, and mathematics 3.To characterize the contents of the software engineering discipline 4.To provide a topical access to the Software Engineering Body of Knowledge 5.To provide a foundation for curriculum development and for individual certification and licensing material The first of these objectives, a consistent worldwide view of software engineering, was supported by a development process which engaged approximately 150 reviewers from 33 countries. More information regarding the development process can be found on the website (www.swebok.org). Professional and learned societies and public agencies involved in software engineering were contacted, made aware of this project to update SWEBOK, and invited to participate in the review process. KA editors were recruited from North America, the Pacific Rim, and Europe. Presentations on the project were made at various international venues. The second of the objectives, the desire to specify the scope of software engineering, motivates the fundamental organization of the Guide. The material that is recognized as being within this discipline is organized into the fifteen KAs listed in Table I.1. Each of these KAs is treated in a chapter in this Guide
xxxii SWEBOK Guide V3.0 Table I.1.The 15 SWEBOK KAs HIERARCHICAL ORGANIZATION Software Requirements Software Design The organization of the KA chapters supports the third of the project's objectives-a characteriza- Software Construction tion of the contents of software engineering.The Software Testing detailed specifications provided by the project's Software Maintenance editorial team to the associate editors regarding Software Configuration Management the contents of the KA descriptions can be found in Appendix A. Software Engineering Management The Guide uses a hierarchical organization to Software Engineering Process decompose each KA into a set of topics with rec- Software Engineering Models and Methods ognizable labels.A two (sometime three)level Software Quality breakdown provides a reasonable way to find topics of interest.The Guide treats the selected Software Engineering Professional Practice topics in a manner compatible with major schools Software Engineering Economics of thought and with breakdowns generally found Computing Foundations in industry and in software engineering literature Mathematical Foundations and standards.The breakdowns of topics do not presume particular application domains,business Engineering Foundations uses,management philosophies,development methods,and so forth.The extent of each topic's In specifying scope,it is also important to iden- description is only that needed to understand the tify the disciplines that intersect with software generally accepted nature of the topics and for engineering.To this end,SWEBOK V3 also rec-the reader to successfully find reference material; ognizes seven related disciplines,listed in Table the Body of Knowledge is found in the reference I.2.Software engineers should,of course,have materials themselves,not in the Guide. knowledge of material from these disciplines (and the KA descriptions in this Guide may make REFERENCE MATERIALAND MATRIX reference to them).It is not,however,an objec- tive of the SWEBOK Guide to characterize the To provide topical access to the knowledge-the knowledge of the related disciplines. fourth of the project's objectives-the Guide identifies authoritative reference material for Table I.2.Related Disciplines each KA.Appendix C provides a Consolidated Computer Engineering Reference List for the Guide.Each KA includes Computer Science relevant references from the Consolidated Refer- ence List and also includes a matrix relating the General Management reference material to the included topics. Mathematics It should be noted that the Guide does not Project Management attempt to be comprehensive in its citations. Much material that is both suitable and excellent Quality Management is not referenced.Material included in the Con- Systems Engineering solidated Reference List provides coverage of the topics described. The relevant elements of computer science and mathematics are presented in the Computing DEPTH OF TREATMENT Foundations and Mathematical Foundations KAs of the Guide (Chapters 13 and 14). To achieve the SWEBOK fifth objective-pro- viding a foundation for curriculum development
xxxii SWEBOK® Guide V3.0 Table I.1. The 15 SWEBOK KAs Software Requirements Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Engineering Models and Methods Software Quality Software Engineering Professional Practice Software Engineering Economics Computing Foundations Mathematical Foundations Engineering Foundations In specifying scope, it is also important to identify the disciplines that intersect with software engineering. To this end, SWEBOK V3 also recognizes seven related disciplines, listed in Table I.2. Software engineers should, of course, have knowledge of material from these disciplines (and the KA descriptions in this Guide may make reference to them). It is not, however, an objective of the SWEBOK Guide to characterize the knowledge of the related disciplines. Table I.2. Related Disciplines Computer Engineering Computer Science General Management Mathematics Project Management Quality Management Systems Engineering The relevant elements of computer science and mathematics are presented in the Computing Foundations and Mathematical Foundations KAs of the Guide (Chapters 13 and 14). HIERARCHICAL ORGANIZATION The organization of the KA chapters supports the third of the project’s objectives—a characterization of the contents of software engineering. The detailed specifications provided by the project’s editorial team to the associate editors regarding the contents of the KA descriptions can be found in Appendix A. The Guide uses a hierarchical organization to decompose each KA into a set of topics with recognizable labels. A two (sometime three) level breakdown provides a reasonable way to find topics of interest. The Guide treats the selected topics in a manner compatible with major schools of thought and with breakdowns generally found in industry and in software engineering literature and standards. The breakdowns of topics do not presume particular application domains, business uses, management philosophies, development methods, and so forth. The extent of each topic’s description is only that needed to understand the generally accepted nature of the topics and for the reader to successfully find reference material; the Body of Knowledge is found in the reference materials themselves, not in the Guide. REFERENCE MATERIAL AND MATRIX To provide topical access to the knowledge—the fourth of the project’s objectives—the Guide identifies authoritative reference material for each KA. Appendix C provides a Consolidated Reference List for the Guide. Each KA includes relevant references from the Consolidated Reference List and also includes a matrix relating the reference material to the included topics. It should be noted that the Guide does not attempt to be comprehensive in its citations. Much material that is both suitable and excellent is not referenced. Material included in the Consolidated Reference List provides coverage of the topics described. DEPTH OF TREATMENT To achieve the SWEBOK fifth objective—providing a foundation for curriculum development
Introduction xxxiii 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.Amatrix 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. The KA descriptions are structured as follows. APPENDIX C.CONSOLIDATED In the introduction,a brief definition of the KA REFERENCE LIST and an overview of its scope and of its relation- ship with other KAs are presented. Appendix C contains the consolidated list of rec- ommended references cited in the KAs (these 2 A Guide to the Project Management Body of references are marked with an asterisk (*in the Knowledge,5th ed.,Project Management Institute, text). 2013:www.pmi.org
Introduction xxxiii certification, and licensing, the criterion of generally accepted knowledge has been applied, to be distinguished from advanced and research knowledge (on the grounds of maturity) and from specialized knowledge (on the grounds of generality of application). The equivalent term generally recognized comes from the Project Management Institute: “Generally recognized means the knowledge and practices described are applicable to most projects most of the time, and there is consensus about their value and usefulness.”2 However, the terms “generally accepted” or “generally recognized” do not imply that the designated knowledge should be uniformly applied to all software engineering endeavors—each project’s needs determine that—but it does imply that competent, capable software engineers should be equipped with this knowledge for potential application. More precisely, generally accepted knowledge should be included in the study material for the software engineering licensing examination that graduates would take after gaining four years of work experience. Although this criterion is specific to the US style of education and does not necessarily apply to other countries, we deem it useful. STRUCTURE OF THE KA DESCRIPTIONS The KA descriptions are structured as follows. In the introduction, a brief definition of the KA and an overview of its scope and of its relationship with other KAs are presented. 2 A Guide to the Project Management Body of Knowledge, 5th ed., Project Management Institute, 2013; www.pmi.org. The breakdown of topics in each KA constitutes the core the KA description, describing the decomposition of the KA into subareas, topics, and sub-topics. For each topic or subtopic, a short description is given, along with one or more references. The reference material was chosen because it is considered to constitute the best presentation of the knowledge relative to the topic. A matrix links the topics to the reference material. The last part of each KA description is the list of recommended references and (optionally) further readings. Relevant standards for each KA are presented in Appendix B of the Guide. APPENDIX A. KA DESCRIPTION SPECIFICATIONS Appendix A describes the specifications provided by the editorial team to the associate editors for the content, recommended references, format, and style of the KA descriptions. APPENDIX B. ALLOCATION OF STANDARDS TO KAS Appendix B is an annotated list of the relevant standards, mostly from the IEEE and the ISO, for each of the KAs of the SWEBOK Guide. APPENDIX C. CONSOLIDATED REFERENCE LIST Appendix C contains the consolidated list of recommended references cited in the KAs (these references are marked with an asterisk (*) in the text)
CHAPTER 1 SOFTWARE REQUIREMENTS ACRONYMS does not imply,however,that a software engineer could not perform the function. CIA Confidentiality,Integrity,and A risk inherent in the proposed breakdown is Availability that a waterfall-like process may be inferred.To DAG Directed Acyclic Graph guard against this,topic 2,Requirements Process, FSM Functional Size Measurement is designed to provide a high-level overview of the requirements process by setting out the resources INCOSE International Council on Systems Engineering and constraints under which the process operates and which act to configure it. UML Unified Modeling Language An alternate decomposition could use a prod- SysML Systems Modeling Language uct-based structure (system requirements,soft- ware requirements,prototypes,use cases,and so on).The process-based breakdown reflects INTRODUCTION the fact that the requirements process,if it is to be successful,must be considered as a process The Software Requirements knowledge area(KA) involving complex,tightly coupled activities is concerned with the elicitation,analysis,speci- (both sequential and concurrent),rather than as a fication,and validation of software requirements discrete,one-off activity performed at the outset as well as the management of requirements dur- of a software development project. ing the whole life cycle of the software product. The Software Requirements KA is related It is widely acknowledged amongst researchers closely to the Software Design,Software Testing, and industry practitioners that software projects Software Maintenance,Software Configuration are critically vulnerable when the requirements- Management,Software Engineering Manage- related activities are poorly performed. ment,Software Engineering Process,Software Software requirements express the needs and Engineering Models and Methods,and Software constraints placed on a software product that Quality KAs. contribute to the solution of some real-world problem. BREAKDOWN OFTOPICS FOR The term"requirements engineering"is widely SOFTWARE REQUIREMENTS used in the field to denote the systematic handling of requirements.For reasons of consistency,the The breakdown of topics for the Software term“engineering”will not be used in this KA Requirements KA is shown in Figure 1.1. other than for software engineering per se. For the same reason,"requirements engineer," 1.Software Requirements Fundamentals a term which appears in some of the literature, [1#,c4,c4s1,cl0s1,c10s4][2*,cl,c6,c12] will not be used either.Instead,the term"software engineer”or,in some specific cases,.“require- 1.1.Definition of a Software Requirement ments specialist"will be used,the latter where the role in question is usually performed by an At its most basic,a software requirement is a individual other than a software engineer.This property that must be exhibited by something in 1-1
1-1 CHAPTER 1 SOFTWARE REQUIREMENTS ACRONYMS CIA Confidentiality, Integrity, and Availability DAG Directed Acyclic Graph FSM Functional Size Measurement INCOSE International Council on Systems Engineering UML Unified Modeling Language SysML Systems Modeling Language INTRODUCTION The Software Requirements knowledge area (KA) is concerned with the elicitation, analysis, specification, and validation of software requirements as well as the management of requirements during the whole life cycle of the software product. It is widely acknowledged amongst researchers and industry practitioners that software projects are critically vulnerable when the requirementsrelated activities are poorly performed. Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem. The term “requirements engineering” is widely used in the field to denote the systematic handling of requirements. For reasons of consistency, the term “engineering” will not be used in this KA other than for software engineering per se. For the same reason, “requirements engineer,” a term which appears in some of the literature, will not be used either. Instead, the term “software engineer” or, in some specific cases, “requirements specialist” will be used, the latter where the role in question is usually performed by an individual other than a software engineer. This does not imply, however, that a software engineer could not perform the function. A risk inherent in the proposed breakdown is that a waterfall-like process may be inferred. To guard against this, topic 2, Requirements Process, is designed to provide a high-level overview of the requirements process by setting out the resources and constraints under which the process operates and which act to configure it. An alternate decomposition could use a product-based structure (system requirements, software requirements, prototypes, use cases, and so on). The process-based breakdown reflects the fact that the requirements process, if it is to be successful, must be considered as a process involving complex, tightly coupled activities (both sequential and concurrent), rather than as a discrete, one-off activity performed at the outset of a software development project. The Software Requirements KA is related closely to the Software Design, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, Software Engineering Models and Methods, and Software Quality KAs. BREAKDOWN OF TOPICS FOR SOFTWARE REQUIREMENTS The breakdown of topics for the Software Requirements KA is shown in Figure 1.1. 1. Software Requirements Fundamentals [1*, c4, c4s1, c10s1, c10s4] [2*, c1, c6, c12] 1.1. Definition of a Software Requirement At its most basic, a software requirement is a property that must be exhibited by something in