Citation Information
Who Benefits From the SWEBOK Framework?
The intended audience for the SWEBOK Guide includes:
- Public and Private Organizations: Those aiming to establish and promote a consistent understanding of software engineering within their operations, particularly when setting education and training standards, job classifications, and performance evaluation policies;
- Practicing Software Engineers: Individuals actively working in the field of software engineering who can use the Guide as a reference for best practices and professional development;
- Policymakers: Those involved in creating public policy related to software engineering, including the development of licensing rules and professional guidelines;
- Professional Societies: Organizations that define accreditation standards for university software engineering programs, as well as certification rules and guidelines for professionals in the field;
- Software Engineering Students: Individuals studying software engineering who can use the Guide to deepen their understanding of the discipline;
- Educators and Trainers: Those responsible for developing curricula and course content in software engineering programs
SWEBOK Overview
Consensus on a Core Body of Knowledge Is Crucial
Despite the millions of software professionals worldwide and the ubiquitous presence of software in our society, software engineering has relatively recently reached the status of a legitimate engineering discipline and a recognized profession.
In engineering, the accreditation of university programs and the licensing and certification of professionals are regarded as essential. These processes are vital for the continuous development of professionals and the overall enhancement of the profession’s standards. Establishing a core body of knowledge is fundamental to the creation and accreditation of university curricula, as well as the licensing and certification of professionals.
Reaching a consensus on this core body of knowledge is a significant milestone in any discipline. The IEEE Computer Society has identified this as crucial for advancing software engineering towards full professional recognition. The SWEBOK Guide, developed under the Professional Activities Board, is part of a long-term project aimed at achieving this consensus. The ongoing SWEBOK project, with its upcoming milestone—SWEBOK Version 5.0—will continue to redefine “accepted knowledge” and introduce new areas of focus.
Focus on Generally Accepted Knowledge
The software engineering body of knowledge is an all-inclusive term that describes the sum of knowledge within the profession of software engineering. Since it is usually not possible to put the full body of knowledge of even an emerging discipline, such as software engineering, into a single document, there is a need for a Guide to the Software Engineering Body of Knowledge. This Guide will seek to identify and describe that subset of the body of knowledge that is generally accepted, even though software engineers must be knowledgeable not only in software engineering, but also, of course, in other related disciplines.
What do we mean by “generally accepted knowledge”?
To better illustrate what “generally accepted knowledge” is relative to other types of knowledge, the figure below proposes a draft three-category schema for classifying knowledge.
Categories of Knowledge
The Project Management Institute in its Guide to the Project Management Body of Knowledge defines “generally accepted” knowledge for project management in the following manner:
“Generally accepted” does not mean that the knowledge and practices described are or should be applied uniformly on all projects; the project management team is always responsible for determining what is appropriate for any given project.
The Guide to the Project Management Body of Knowledge is now an IEEE Standard, IEEE 1490-2003.
The Industrial Advisory Board of the SWEBOK Guide better defines “generally accepted” as knowledge to be included in the study material of a software engineering licensing exam that a graduate would pass after completing four years of work experience. These two definitions should be seen as complementary.
Knowledge Area Editors are also expected to be somewhat forward-looking in their interpretation by taking into consideration not only what is “generally accepted” today, but what they expect will be “generally accepted” in a 3 to 5 year timeframe.
Software Engineering Body of Knowledge and Curriculum are Not the Same
Software engineers must not only be knowledgeable in what is specific to their discipline, but they also, of course, must know a lot more. The goal of this initiative is not, however, to inventory everything that software engineers should know, but to identify what forms the core of software engineering. It is the responsibility of other organizations and initiatives involved in the licensing and certification of professionals and the development of accreditation criteria and curricula to define what a software engineer must know outside software engineering. We believe that a very clear distinction must be made between the software engineering body of knowledge and the contents of software engineering curricula.
View the SWEBOK table of contents to get an overview of topics.
List of KA Editors and Contributing Editors
KA EDITORS
Software Requirements
Steve Tockey, Construx Software, USA.
Software Architecture
Rich Hilliard, USA.
Software Design
Rich Hilliard, USA.
Software Construction
Xin Peng, Software School, Fudan University, China.
Steve Schwarm, Synopsys – Black Duck Software, USA.
Software Testing
Eda Marchetti, ISTI-CNR, Italy.
Said Daoudagh, ISTI-CNR, Italy.
Software Engineering Operations
Francis Bordeleau, École de technologie supérieure (ÉTS), Canada.
Alain April, École de technologie supérieure (ÉTS), Canada.
Software Maintenance
Ali Ouni, École de technologie supérieure (ÉTS), Canada.
Alain April, École de technologie supérieure (ÉTS), Canada.
Peter Leather, Exceptional Performance, UK.
Software Configuration Management
Maria Isabel Sánchez Segura, Universidad Carlos III de Madrid, Spain.
Bob Aiello, CM Best Practices, USA.
Software Engineering Management
Kenneth E. Nidiffer, George Mason University, USA.
Software Engineering Process
Juan Garbajosa, Universidad Politécnica de Madrid, Spain.
Software Engineering Models and Methods
Hironori Washizaki, Waseda University, Japan.
Akinori Ihara, Wakayama University, Japan.
Shinpei Ogata, Shinshu University, Japan.
Software Quality
Alain April, École de technologie supérieure (ÉTS), Canada.
Steve Tockey, Construx Software, USA.
Steve Schwarm, Synopsys – Black Duck Software, USA.
Software Security
Nobukazu Yoshioka, Waseda University, Japan.
Seiji Munetoh, IBM Research, Japan.
Software Engineering Professional Practice
Katsuhisa Shintani, Waseda University, Japan.
Eiji Hayashiguchi, Waseda University, Japan.
Software Engineering Economics
Maria Isabel Sánchez Segura, Universidad Carlos III de Madrid, Spain.
Steve Tockey, Construx Software, USA.
Computing Foundations
Yatheendranath TJ, DhiiHii Labs Private Limited, India.
Mathematical Foundations
Yatheendranath TJ, DhiiHii Labs Private Limited, India.
Steve Tockey, Construx Software, USA.
Engineering Foundations
Yatheendranath TJ, DhiiHii Labs Private Limited, India.
Steve Tockey, Construx Software, USA.
Appendix A: Knowledge Area Description Specifications
Juan Garbajosa, Universidad Politécnica de Madrid, Spain.
Hironori Washizaki, Waseda University, Japan.
Appendix B: IEEE and ISO/IEC Standards Supporting SWEBOK
Annette Reilly, USA.
Appendix C: Consolidated Reference List
Hironori Washizaki, Waseda University, Japan.
CONTRIBUTING EDITORS:
The following persons contributed to editing the SWEBOK Guide V4:
Michelle Phon
Eric Berkowitz
Volunteer
The SWEBOK Guide requires participation from all parts of the world and diverse areas of software engineering. Help us by contributing to the public review in developing version 5.0
Public Review
Tell Us How You Use the SWEBOK Guide
SWEBOK.org will feature more information on how people are using the SWEBOK Guide as time goes on. Tell us how you are using SWEBOK by writing to swebok@computer.org.
Stay Informed
Sign up now by writing to swebok@computer.org to be on the email list for notification as updates and opportunities related to the SWEBOK Guide become available.
FAQs
What is SWEBOK?
SWEBOK is an acronym that stands for the Software Engineering Body Of Knowledge, an all-inclusive term that describes the sum of knowledge within the profession of software engineering.
Why is there a SWEBOK guide?
Since it is usually not possible to put the full body of knowledge of even an emerging discipline, such as software engineering, into a single document, there is a need for a Guide to the Software Engineering Body of Knowledge.
This guide identifies and describes that subset of the body of knowledge that is generally accepted, even though software engineers must be knowledgeable not only in software engineering, but also, of course, in other related disciplines.
How is the SWEBOK guide developed?
Software engineers worldwide can participate in the guide’s development. Anyone can sign up to be a reviewer. Look for postings of other opportunities and reviewer sign up on the SWEBOK Volunteer page.
Who should use the SWEBOK guide?
Anyone who develops software should be familiar with the guide and use it where applicable.
What do you use SWEBOK for?
There are a multitude of purposes for using SWEBOK including:
- Understanding Software Engineering
- Guiding Education and Training
- Professional Development
- Standardizing Practices
- Certification Preparation
The Computer Society began defining this body of knowledge in 1998 as a necessary step toward making software engineering a legitimate engineering discipline and a recognized profession. As software becomes the center of critical systems, it is only natural that standards of practice, knowledge, and training would arise in software engineering.
How do you define “generally accepted” knowledge?
A simple definition is “established traditional practices recommended by many organizations.”
Another definition that the SWEBOK guide uses comes from the Project Management Institute. Its Guide to the Project Management Body of Knowledge defines “generally accepted” knowledge for project management in the following manner:
“‘Generally accepted’ means that the knowledge and practices described are applicable to most projects most of the time and that there is widespread consensus about their value and usefulness. ‘Generally accepted’ does not mean that the knowledge and practices described are or should be applied uniformly on all projects; the project management team is always responsible for determining what is appropriate for any given project.”
The Industrial Advisory Board for the 2004 SWEBOK guide better defines “generally accepted” as knowledge to be included in the study material of a software engineering licensing exam that a graduate would pass after completing four years of work experience. These two definitions should be seen as complementary.
How do you determine what is “generally accepted” knowledge?
The SWEBOK guide uses a rigorous process that includes successive levels of review. When an editor proposes a draft knowledge area, a selected group of invited experts provide wide-ranging comments, in a review similar to that for academic papers. The group discusses these comments, and the editor then incorporates the accepted changes.
Next, a larger group of invited practitioners answers a set list of about 14 questions on the new draft. These questions have to do with relevancy and usefulness, and the editor uses the responses to further refine the draft. The last review is open to the public, but comments must be specific and refer to a particular line or item within the draft.
Which publications and books discuss the SWEBOK guide?
Many publications and books have referred to the SWEBOK Guide. Examples are the following but not limited to them. Many more publications discuss and refer to the SWEBOK Guide available on the IEEE Computer Society Digital Library (CSDL) and the IEEE Xplorer®.
- D. R. Fairley, P. Bourque, and J. Kepple, “The impact of SWEBOK Version 3 on software engineering education and training,” 2014 IEEE 27th Conference on Software Engineering Education and Training (CSEE&T), 2014.
- A. Rashid, G. Danezis, H. Chivers, E. Lupu, A. Martin, M. Lewis, and C. Peersman, “Scoping the Cyber Security Body of Knowledge,” IEEE Security & Privacy, Vol. 16, No. 3, 2018.
- J. Voas, R. Kuhn, C. Paulsen, and K. Schaffer, “Computer Science Education in 2018,” IT Professional, Vol. 20, No. 1, 2018.
- P. Bourque, “The SWEBOK Guide — More Than 20 Years down the Road,” 2020 IEEE 32nd Conference on Software Engineering Education and Training (CSEE&T), 2020.
- Z. Sun, C. Hu, C. Li, and L. Wu, “Domain Ontology Construction and Evaluation for the Entire Process of Software Testing,” IEEE Access, Vol. 8, 2020.
- I. Ozkaya, “An AI Engineer Versus a Software Engineer,” IEEE Software, Vol. 39, No. 6, 2022.
- M. Kuhrmann, et al., “What Makes Agile Software Development Agile?” IEEE Transactions on Software Engineering, Vol. 48, No. 9, 2022.
- Z. Kotti, G. Gousios, and D. Spinellis, “Impact of Software Engineering Research in Practice: A Patent and Author Survey Analysis,” IEEE Transactions on Software Engineering, Vol. 49, No. 4, 2023.
- F. Ebbers, “A Large-Scale Analysis of IoT Firmware Version Distribution in the Wild,” IEEE Transactions on Software Engineering, Vol. 49, No. 2, 2023.
- H. Washizaki, M. Sanchez-Segura, J. Garbajosa, S. Tockey, and K. Nidiffer, “Envisioning software engineer training needs in the digital era through the SWEBOK V4.0 prism,” 2023 IEEE 35th International Conference on Software Engineering Education and Training (CSEE&T), 2023.
Consolidated References List of SWEBOK Guide V4.0
The Consolidated Reference List identifies all recommended reference materials that accompany the breakdown of topics within each knowledge area (KA). This Consolidated Reference List is adopted by the software engineering certification and associated professional development products offered by the IEEE Computer Society. KA Editors used the references allocated to their KA by the Consolidated Reference List as their Recommended References. See Appendix C of the guide for more details.
- A. Silberschatz, P.B. Galvin, and G. Gagne, Operating System Concepts, 8th ed., Wiley, 2008.
- A.M.J. Hass, Configuration Management Principles and Practices, 1st ed., Addison-Wesley, 2003.
- B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, 2003.
- C.Y. Laporte, A. April, Software Quality Assurance, IEEE Computer Society Press, 1st ed., 2018.
- D. Budgen, Software Design, 3rd ed., CRC Press, 2021.
- D. C. Montgomery and G. C. Runger, Applied Statistics and Probability for Engineers, 7th ed. Hoboken, NJ: Wiley, 2018.
- D. Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster, Addison-Wesley Professional, 2022.
- E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1st ed., Addison-Wesley Professional, 1994.
- E.W. Cheney and D.R. Kincaid, Numerical Mathematics and Computing, 6th ed., Brooks/Cole, 2007.
- E.W. Cheney and D.R. Kincaid, Numerical Mathematics and Computing, 7th ed., Addison Wesley, 2020.
- F. Bott et al., Professional Issues in Software Engineering, 3rd ed., Taylor & Francis, 2000.
- G. Booch, J. Rumbaugh and I. Jacobson, The Unified Modeling Language User Guide, 2nd edition, Addison-Wesley, 2005.
- G. Kim, J. Humble, P. Debois, J. Willis and J. Allspaw, The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations, 2nd ed., IT Revolution, 2021.
- G. Voland, Engineering by Design, 2nd ed., Prentice Hall, 2003.
- I. Sommerville, Software Engineering, 10th ed., Addison-Wesley, 2016.
- J. McGarry et al., Practical Software Measurement: Objective Information for Decision Makers, Addison-Wesley Professional, 2001.
- J. Nielsen, Usability Engineering, 1st ed., Morgan Kaufmann, 1993.
- J. Shore and S. Warden, The Art of Agile Development, O’Reilly Media, 2nd Edition, 2021.
- J.G. Brookshear, Computer Science: An Overview, 12th ed., Addison-Wesley, 2017.
- J.H. Allen et al., Software Security Engineering: A Guide for Project Managers, Addison-Wesley, 2008.
- J.M. Wing, A Specifier’s Introduction to Formal Methods, Computer, vol. 23, no. 9, 1990, pp. 8, 10–23.
- K. Rosen, Discrete Mathematics and its Applications, 8th ed., McGraw-Hill, 2018.
- K.E. Wiegers, Software Requirements, 3rd ed., Microsoft Press, 2013.
- L. Null and J. Lobur, The Essentials of Computer Organization and Architecture, 2nd ed., Jones and Bartlett Publishers, 2006.
- L. Null and J. Lobur, The Essentials of Computer Organization and Architecture, 5th ed. Sudbury, MA: Jones and Bartlett Publishers, 2018.
- M. Bishop, Computer Security: Art and Science, 2nd Edition, Addison-Wesley, 2018.
- M. Page-Jones, Fundamentals of Object-Oriented Design in UML, 1st ed., Addison-Wesley, 1999.
- N. Rozanski and E. Woods, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2nd edition, Addison-Wesley, 2011.
- P. Clements et al., Documenting Software Architectures: Views and Beyond, 2nd ed., Pearson Education, 2010.
- P. Grubb and A.A. Takang, Software Maintenance: Concepts and Practice, 2nd ed., World Scientific Publishing, 2003.
- Project Management Institute and Agile Alliance, Agile Practice Guide, Project Management Institute, 2017.
- R.E. Fairley, Managing and Leading Software Projects, Wiley-IEEE Computer Society Press, 2009.
- R.N. Taylor, N. Medvidović, E. Dashofy, Software Architecture: Foundations, Theory, and Practice, Wiley, 2009.
- S. McConnell, Code Complete, 2nd ed., Microsoft Press, 2004.
- S. Naik and P. Tripathy, Software Testing and Quality Assurance: Theory and Practice, Wiley-Spektrum, 2008.
- S. Tockey, Return on Software: Maximizing the Return on Your Software Investment, 1st ed., Addison-Wesley, 2004.
- S.H. Kan, Metrics and Models in Software Quality Engineering, 2nd ed., Addison-Wesley, 2002.
- S.J. Mellor and M.J. Balcer, Executable UML: A Foundation for Model-Driven Architecture, 1st ed., Addison-Wesley, 2002.
Terms and Conditions
The document you are about to download is protected by US and international copyright laws, and is made available to you exclusively for your own individual, non-commercial purposes. This User License Agreement describes the terms and conditions that you agree to with regard to using SWEBOK version 4.0.
What You Can Do
This license gives you the right to print and retain a single hard copy of the PDF file, and to maintain the PDF version on your personal computer and/or mobile device. You may also post SWEBOK 4.0 on a corporate or institutional intranet or similar site for reference use by employees or staff (however, all other limitations and requirements apply to those users as well). You may quote or reproduce reasonable passages from SWEBOK 4.0 in a review, article, scholarly, or educational material, provided that you provide an appropriate citation to the source document. Educational use of this material is permitted without fee provided that:
- Copies are made for non-profit educational use and not for resale, advertising, or other commercial use;
- Any copy or other use is accompanied by a full citation to the original work and its copyright;
- The copied text has not been materially altered
What You Cannot Do
You may not copy or otherwise reproduce or share SWEBOK 4.0. Under no circumstances are you permitted to distribute or sell SWEBOK version 4.0 without permission. You may not post SWEBOK version 4.0 publicly, or provide any manner of public access to your downloaded document, including through links. You may not translate SWEBOK 4.0 into other languages, reuse significant portions of SWEBOK 4.0 for commercial purposes, or alter the text of SWEBOK 4.0 in any way.
The Fine Print
While all reasonable care has been taken in the preparation and review of SWEBOK version 4.0, the IEEE does not warrant that the document is accurate, current, or suitable for your particular purpose. In making this document available to you, IEEE is not rendering legal, accounting, technical, or other professional services. In no event shall the IEEE be liable for any direct, indirect, punitive, incidental, special, consequential, or any other damages or judgments whatsoever arising out of or connected with the use or misuse of this document.
This transaction is governed by the laws of New York.
If you have any questions or concerns regarding these terms, or if you have other questions regarding copyright and potential uses, please contact the IEEE Computer Society at help@computer.org.
