Software Engineering Body of Knowledge (SWEBOK)

DOWNLOAD

Alert

About SWEBoK


The Guide to the Software Engineering Body of Knowledge (SWEBOK) describes generally accepted knowledge about software engineering. Its 15 knowledge areas (KAs) summarize key concepts and include a reference list for detailed information.

Pierre-Bourque
SWEBOK co-editor Pierre Bourque is Dean of Studies of the École de technologie supérieure of the Université du Québec and is a Professor in the Department of Software and IT Engineering.

For version 3.0, editors received and replied to comments from approximately 150 reviewers in 33 countries. The Computer Society and its volunteers will continue to use the transparent and open consensus process that is an integral part of SWEBOK to continue improving it. SWEBOK has also gained international recognition as ISO Technical Report 19759.

The SWEBOK Guide

  • characterizes the contents of the software engineering discipline
  • promotes a consistent view of software engineering worldwide
  • clarifies the place of, and sets the boundary of, software engineering with respect to other disciplines
  • provides a foundation for training materials and curriculum development, and
  • provides a basis for certification and licensing of software engineers.

SWEBOK V3.0 is the most recent version of the internationally respected Guide to the Software Engineering Body of Knowledge. Imagined as a living, changing document, and thoroughly updated, the guide has been developed and created by leading authorities, reviewed by professionals, and made available for public review and comment, continuing its 20-year reputation as the most authoritative, fundamental, and trusted definition of the software engineering profession.

The following principles underlie the development approach for this project:

  • transparency: the development process is itself published and fully documented;
  • consensus-building: the development process is designed to build, over time, consensus in industry, professional societies and standards-setting bodies, among practicing software developers and in academia.
  • wide distribution: the Guide will remain free at least in one format to ensure as wide a distribution and dissemination as possible.

Be sure to register to receive notifications to get notified when a new version is available.

An Evolving Body of Knowledge


The committee in charge of the 2004 SWEBOK Guide knew it had to plan for revisions, and in fact outlined a process for doing so. The reasons for doing so, included:

Practices change. New tools, methods, and types of software make good practice in software engineering an ever-changing target. Topics that were once experimental may have now reached the state of generally accepted knowledge. And even though the Guide focuses on the most widely accepted and long-lasting of practices, it’s possible for the environment that software operates in to change significantly because of business and job changes. For example, it has become clear in just the past few years that good software practice must pay increasing attention to security. Economics can also affect what methods become best practices in software engineering.

Richard-Fairley
Richard E. (Dick) Fairley is founder and principal associate of Software and Systems Engineering
Associates (S2EA) and an adjunct faculty member in the doctoral program at Colorado Technical
University.

Other viewpoints emerge. Other Computer Society products—notably the Certified Software Development Professional (CSDP) exam and the Software Engineering 2004 curriculum guide—offer slightly differing views of the body of knowledge. So it makes sense to take the opportunity to examine them and better align the SWEBOK Version 3 with them where it makes sense. For example, it seems reasonable that there should be a core set of references for these products, so part of the work on the SWEBOK Version 3 will establish that core set. The comparison among these efforts has also suggested the need for new knowledge areas and the revision of others.

The body of knowledge grows. Since 2004, many of the books cited in the first SWEBOK Guide have been revised and new articles have been added to the body of knowledge. The SWEBOK Version 3 should account for these changes.

These factors drive the need for a new version of the SWEBOK Guide on a regular basis.

Learn a bit more about the evolution of SWEBOK through our webinar: Guide to the Software Engineering Body of Knowledge v3.0 Intro, Usages, and Ongoing Work.

Objectives


The objectives of the project are to:

  • characterize the contents of the Software Engineering Body of Knowledge;
  • promote a consistent view of software engineering worldwide;
  • clarify the place of, and set the boundary of, software engineering with respect to other disciplines such as computer science, project management, computer engineering and mathematics;
  • provide a foundation for curriculum development and individual certification and licensing material.

Who Benefits


The intended audience includes:

  • public and private organizations wishing to use and promote a consistent view of software engineering internally, notably when defining education and training, job classification and performance evaluation policies;
  • practicing software engineers;
  • makers of public policy engaged in defining software engineering licensing rules and guidelines for professionals;
  • professional societies engaged in defining software engineering university program accreditation guidelines, and certification rules and guidelines for professionals;
  • software engineering students learning the discipline;
  • educators and trainers engaged in defining curricula and course content.

SWEBOK Overview


Consensus on a Core Body of Knowledge Is Crucial

In spite of 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.

SWEBOK-goals-plan-estimates
To be of value, planning should involve consideration of the project constraints and commitments to stakeholders. This illustration shows how
goals are initially defined. Estimates are done based on the initial goals. The plan tries to match the goals and the estimates. This is an iterative process, because an initial estimate typically does not meet the initial goals.

In engineering, the accreditation of university curricula and the licensing and certification of practicing professionals are taken very seriously. These activities are seen as critical to the constant upgrading of professionals and, hence, the improvement of the level of professional practice. Recognizing a core body of knowledge is pivotal to the development and accreditation of university curricula and the licensing and certification of professionals.

Achieving consensus by the profession on a core body of knowledge is a key milestone in all disciplines and has been identified by the IEEE Computer Society as crucial for the evolution of software engineering towards professional status. The Guide, written under the auspices of the Professional Activities Board, is part of a multiyear project designed to reach such a consensus. The ongoing SWEBOK project and its next milestone—the SWEBOK Version 4.0—will continue to redefine “accepted knowledge” and add new areas.

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, have to 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.

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 4.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 e-mail list for notification as updates and opportunities related to the SWEBOK Guide become available.

[list of names and quotes]

Citation Information


P. Bourque and R.E. Fairley, eds., Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEE Computer Society, 2014; www.swebok.org.
Why SWEBOK Version 3?

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 signup 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?

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 discuss the SWEBOK guide?

  1. Adams, T.L. “Software Engineering in Canada, the Us and the UK: Inter-Professional Relations and the Emergence of a New Profession,” WANE Working Paper #9, University of Western Ontario, London, Ontario, 2004, www.wane.ca.
  2. Bott, F., Coleman, A., Eaton, J., and Rowland, D. Professional Issues in Software Engineering, Taylor & Francis, 2000.
  3. Dony, R.D., Botman, P., Briggs, W.E., Haggart, R., and Taylor, P.A. “The Software Engineering Body of Knowledge for Professional Engineering in Canada,” IEEE Canadian Review (Reprinted in full from IEEE Canadian Conference on Computer and Electrical Engineering – CCECE 2002) (41) 2002.
  4. IEA/ACS “Minutes of the Meeting Held on 27 January 2004,” Joint Board in Software Engineering, The Institution of Engineers, Australia and The Australian Computer Society, 2004, http://www.acs.org.au/boards/jbswe/documents/Minutes_27January2004.doc.
  5. Narayanan, R., and Neethi, S. “Building Software Engineering Professionals: TCS Experience,” 14th Conference on Software Engineering Education and Training – CSEE&T, 2001, pp. 162-171.
  6. Surendran, K., Hays, H., and Macfarlane, A. “Simulating a Software Engineering Apprenticeship,” IEEE Software (19:5) 2002, pp. 49-56.
  7. Seffah, A. “Learning the Ropes: Human-Centered Design Skills and Patterns for Software Engineers’ Education,” Interactions (10:5) 2003, pp. 36-45.
  8. Seffah, A., and Andreevskaia, A. “Empowering Software Engineers in Human-Centered Design,” 25th International Conference on Software Engineering – ICSE, 2003, pp. 653-658.
  9. Almstrum, V.L., Dean, C.N., Goelman, D., Hilburn, T.B., and Smith, J. “Support for Teaching Formal Methods,” Innovation and Technology in Computer Science Education – ITiCSE, ACM Press, 2001, pp. 71-88.
  10. Asklund, U., and Bendix, L. “A Software Configuration Management Course,” Lecture Notes in Computer Science (2649)) 2003, pp. 245-258.
  11. Benediktsson, O. “Software Engineering Body of Knowledge and Curriculum Development.,” Views on Software Development in the New Millennium, 2000.
  12. Borstler, J., Carrington, D., Hislop, G.W., Lisack, S., Olson, K., and Williams, L. “Teaching PSP: Challenges and Lessons Learned,” IEEE Software (19:5) 2002, pp. 42-48.
  13. Bourque, P., Robert, F., Lavoie, J.-M., Lee, A., Trudel, S., and Lethbridge, T. “Guide to the Software Engineering Body of Knowledge (SWEBOK) and the Software Engineering Education Body of Knowledge (SEEK) – A Preliminary Mapping,” Post-Conference Proceedings of the 10th International Software Technology and Engineering Practice Conference – STEP 2002, IEEE Computer Society, Montreal, 2003, pp. 8-23.
  14. Budgen, D., and Tomayko, J.E. “Norm Gibbs and His Contribution to Software Engineering Education through the SEI Curriculum Modules,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 3-13.
  15. Budgen, D., and Tomayko, J.E. “The SEI Curriculum Modules and Their Influence: Norm Gibbs’ Legacy to Software Engineering Education,” Journal of Systems and Software (75:1-2) 2005, pp. 55-62.
  16. Cowling, A.J. “Modelling: A Neglected Feature in the Software Engineering Curriculum,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 206-215.
  17. Cowling, A.J. “What Should Graduating Software Engineers Be Able to Do?,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 88-98.
  18. Cowling, A.J. “The Role of Modelling in the Software Engineering Curriculum,” Journal of Systems and Software (75:1-2) 2005, pp. 41-53.
  19. Daniels, M., Faulkner, X., and Newman, I. “Open Ended Group Projects, Motivating Students and Preparing Them for the ‘Real World’,” 15th Conference on Software Engineering Education and Training – CSEE&T, 2002, pp. 115-126.
  20. Demuth, B., Fischer, M., and Hussmann, H. “Experience in Early and Late Software Engineering Project Courses,” 15th Conference on Software Engineering Education and Training – CSEE&T, 2002, pp. 241-248.
  21. Duley, R., and Maj, S.P. “Cutting Hacking: Breaking from Tradition,” 15th Conference on Software Engineering Education and Training – CSEE&T, 2002, pp. 224-233.
  22. Duley, R., Hislop, G.W., Hilburn, T.B., and Sobel, A.E.K. “Engineering an Introductory Software Engineering Curriculum,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 99-106.
  23. Edwards, S.H. “Improving Student Performance by Evaluating How Well Students Test Their Own Programs,” Journal of Educational Resources in Computing (JERIC) (3:3), September 2003, pp. 1-24.
  24. Fekete, A., and Kummerfeld, B. “Design of a Major in Software Development,” 33rd SIGCSE Technical Symposium on Computer Science Education, ACM Press, Cincinnati, Kentucky, 2002, pp. 73-77.
  25. Fuller, A., Croll, P., and Di, L. “A New Approach to Teaching Software Risk Management with Case Studies,” 15th Conference on Software Engineering Education and Training – CSEE&T, 2002, pp. 215-222.
  26. GarcÃ?Â??­a, F.J., Gomes, J.A., Alonso, L., Amaral, L.A., and PÃ?Â??©rez, J.L. “Business Computing – A Shared Curriculum Proposal for the Spanish-Portuguese Border under the Auspices of the New European Higher Education Area,” 34th ASEE/IEEE Frontiers in Education Conference, Savannah, GA, U.S.A., 2004, pp. S2B-14.
  27. Germain, E., and Robillard, P.N. “What Cognitive Activities Are Performed in Student Projects?,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 224-231.
  28. Hilburn, T.B. “Teams Need a Process!,” Proceedings of the 5th Annual Conference on Innovation and Technology in Computer Science Education – ITiCSE, ACM Press, Helsinki, Finland, 2000, pp. 53-56.
  29. Hislop, G., Lutz, M., Naveda, F., McCracken, M., Mead, N., and Williams, L. “Integrating Agile Practices into Software Engineering Courses,” Computer Science Education (12:3) 2002, pp. 169-185.
  30. Host, M. “Introducing Empirical Software Engineering Methods in Education,” 15th Conference on Software Engineering Education and Training – CSEE&T, 2002, pp. 170-179.
  31. Huffman Hayes, J. “Energizing Software Engineering Education through Real-World Projects as Experimental Studies,” 15th Conference on Software Engineering Education and Training – CSEE&T, 2002, pp. 192-206.
  32. IEEE/ACM “Software Engineering 2004 – Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering – A Volume of the Computing Curriculum Series,” Joint Task Force on Computing Curricula – IEEE Computer Society and Association for Computing Machinery, 2004,http://sites.computer.org/ccse/.
  33. Kropp, M. “Software Education Curriculum Framework,” 2001, http://www.sweed.ch/workgroup.cfm/CurriculumFramework.doc?cmd=download&filename=CurriculumFramework.d oc.
  34. Ludi, S., and Collofello, J. “An Analysis of the Gap between the Knowledge and Skills Learned in Academic Software Engineering Course Projects and those Required in Real Projects,” 31st ASEE/IEEE Frontiers in Education Conference, 2001. http://fie.engrng.pitt.edu/fie2001/papers/1187.pdf, 2001.
  35. Mathiassen, L., and Purao, S. “Educating Reflective Systems Developers,” Information Systems Journal (12:2) 2002, pp. 81-102.
  36. Meziane, F., and Vadera, S. “A Comparison of Computer Science and Software Engineering Programmes in English Universities,” 17th Conference on Software Engineering Education and Training – CSEE&T, 2004, pp. 65-70.
  37. Perez-Martinez, J.E., and Sierra-Alonso, A. “A Coordinated Plan for Teaching Software Engineering in the Rey Juan Carlos University,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 107-118.
  38. Polo, M., Piattini, M., and Ruiz, F. (Eds.) Advances in Software Maintenance Management: Technologies and Solutions. Idea Group Publishing, 2002.
  39. Ramakrishnan, S., and Cambrell, A. “An in-Forming Web-Based Environment for a Bachelor of Software Engineering Degree – DoIT,” Informing Science + IT Education Conference, 2002.
  40. Ramakrishan, S. “MUSE Studio Lab and an Innovative Software Engineering Capstone Project Experience,” 8th Annual Conference on Innovation and Technology in Computer Science Education, ACM Press, Thessaloniki, Greece, 2003, pp. 21-25.
  41. Saiedian, H., Bagert, D.J., and Mead, N.R. “Software Engineering Programs: Dispelling the Myths and Misconceptions,” IEEE Software (19:5) 2002, pp. 35-41.
  42. Shaw, M. “Software Engineering Education: A Roadmap,” Conference on the Future of Software Engineering, ACM Press, Limerick, Ireland, 2000, pp. 371-380.
  43. Shepard, T. “An Efficient Set of Software Degree Programs for One Domain,” 23rd International Conference on Software Engineering – ICSE, IEEE Computer Society, Toronto, Canada, 2001, pp. 623-632.
  44. Shoemaker, D., Jovanovic, V., and Drommi, A. “A Case for the Study of Software Management within a Broad Information Technology Curriculum,” 4th Conference on Information Technology Curriculum, ACM Press, 2003, pp. 174-179.
  45. Thompson, J.B., and Edwards, H.M. “An Account and Appraisal of the Ongoing Development of the Software Engineering Volume of CC2001 and Its International Applicability,” Ninth Asia-Pacific Software Engineering Conference – APSEC, 2002a, pp. 204-213.
  46. Towell, E. “Teaching Ethics in the Software Engineering Curriculum,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 150-157.
  47. Callahan, D., and Pedigo, B. “Educating Experienced IT Professionals by Addressing Industry’s Needs,” IEEE Software (19:5) 2002, pp. 57-62.
  48. Carrington, D., Strooper, P., Newby, S., and Stevenson, T. “An Industry/University Collaboration to Upgrade Software Engineering Knowledge and Skills in Industry,” Journal of Systems and Software (75:1-2) 2005, pp. 29-39.
  49. Duggins, S.L., and Thomas, B.B. “An Historical Investigation of Graduate Software Engineering Curriculum,” 15th Conference on Software Engineering Education and Training – CSEE&T, 2002, pp. 78-87.
  50. Edwards, H.M., and Thompson, J.B. “Reflections on a UK Masters Level Software Engineering Programme Intended for the Home and International Market,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 166-173.
  51. Ellis, H.J.C., Mead, N.R., Moreno, A.M., and Seidman, S.B. “Industry/University Software Engineering Collaborations for the Successful Reeducation of Non-Software Professionals,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 44-51.
  52. Frailey, D., and Mason, J. “Using SWEBOK for Education Programs in Industry and Academia,” 15th Conference on Software Engineering Education and Training Conference – CSEE&T, 2002, pp. 6-10.
  53. Gore, M. “Thoughts on the Information System Architect Role,” International Symposium on Information Technology: Coding and Computing – ITCC, 2003, pp. 706-710.
  54. Hofmann, B., and Wulf, V. “Building Communities among Software Engineers: The ViSEK Approach to Intra- and Inter-Organizational Learning,” 4th International Workshop on Advances in Learning Software Organizations – LSO, Springer-Verlag, Chicago, U.S.A., 2002, pp. 25-33.
  55. John, M., and Melster, R. “Knowledge Networks – Managing Collaborative Knowledge Spaces,” 6th International Workshop on Advances in Learning Software Organizations – LSO, Springer-Verlag, Banff, Canada, 2004, pp. 165-171.
  56. Rosca, D., Tepfenhart, W., and McDonald, J. “Software Engineering Education: Following a Moving Target,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 129-139.
  57. Strooper, P., Carrington, D., Newby, S., and Stevenson, T. “Teaching Software Engineering Fundamentals to Practicing Engineers,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 36-43.
  58. Thompson, J.B., and Hardy, C.J. “Use and Evaluation of SWEBOK by Postgraduate Students,” 15th Conference on Software Engineering Education and Training – CSEE&T, 2002, pp. 66-77.
  59. Mason, J. “Aligning Workforce Development and Software Process Improvement Strategy for Accelerated Adoption of Software Engineering Capability,” 16th Conference on Software Engineering Education and Training – CSEE&T, 2003, pp. 70-77.
  60. Futrell, R.T., Schafer, D.F., and Shafer, L.I. Quality Software Project Management, Prentice Hall PTR, 2002.
  61. ISO/IEC “International Certification of Software Engineers Study Group Final Report,” ISO/IEC JTC1/SC7 Software and Systems Engineering, 2005, p. 16.
  62. OIQ “Le gÃ?Â??©nie logiciel,” Ordre des ingÃ?Â??©nieurs du QuÃ?Â??©bec, MontrÃ?Â??©al, QuÃ?Â??©bec, 2001.
  63. Kaner, C., Bach, J., and Pettichord, B. Lessons Learned in Software Testing – A Context Driven Approach, John Wiley and Sons, New York, 2002.
  64. Bagert, D. “Licensing and Certification of Software Professionals,” Advances in Computers (60) 2004.
  65. Kitchenham, B., Budgen, D., Brereton, P., and Woodall, P. “An Investigation of Software Engineering Curricula,” Journal of Systems and Software (74:3) 2005, pp. 325-335.
  66. Kruchten, P. “Putting the “Engineering” into Software Engineering,” Australian Software Engineering Conference, 2004, pp. 2-8.
  67. Lethbridge, T.C. “What Knowledge Is Important to a Software Professional?,” Computer (33:5) 2000, pp. 44-50.
  68. McConnell, S. After the Gold Rush: Creating a True Profession of Software Engineering, Microsoft Press, 1999.
  69. McConnell, S. Code Complete, (2nd ed.), Microsoft Press, 2004.
  70. Pour, G., Griss, M.L., and Lutz, M. “The Push to Make Software Engineering Respectable,” IEEE Computer (33:5), May 2000, pp. 35-43.
  71. Thompson, J.B. “Knowledge, Professionalism and Free Movement of Labour (Visions of the Software Engineering Future),” The 24th Annual International Computer Software and Applications Conference – COMPSAC, Taipei, Taiwan, 2000, pp. 28-37.
  72. Thompson, J.B. “A Long and Winding Road (Progress on the Road to a Software Engineering Profession),” 25th Annual International Computer Software and Applications Conference – COMPSAC, Chicago, U.S.A., 2001, pp. 39-45.
  73. Thompson, J.B. “Closing the Circle on Software Engineering Professionalism and Free Movement of Labour,” 26th Annual International on Computer Software and Applications Conference – COMPSAC, 2002, pp. 255-264.
  74. Tomayko, J.E. “Milestones in Software Engineering,” in: Encyclopedia of Software Engineering, Marciniak, J. (ed.), Wiley, 2001.
  75. van Amstel, J.J. “The Time of the Chameleons Is Over?,” Information and Software Technology (41:14) 1999, pp. 1011-1020.
  76. AytaÃ?Â??§, T., Ikiz, S., and Aykol, M. ” A SPICE-Oriented, SWEBOK Based, Software Process Based Assessment on a National Scale: Turkish Sector Software Survey – 2001,” 3rd International SPICE Conference, 2003.
  77. Bagert, D.J., Barbacci, M., Budgen, D., Lethbridge, T.C., Suryn, W., and van Vliet, H. “Thoughts on Software Engineering Knowledge, and How to Organize It,” Post-conference Proceedings of the 10th International Workshop on Software Technology and Engineering Practice – STEP 2002, 2003, pp. 24-35.
  78. Booch, G. “Developing the Future,” Communications of the ACM (44:3) 2001, pp. 118-121.
  79. Bucchiarone, A., Muccini, H., Pelliccione, P., and Pierini, P. “Model-Checking Plus Testing: From Software Architecture Analysis to Code Testing,” Applying Formal Methods: Testing, Performance, and M/E-Commerce – FORTE, Springer-Verlag, Toledo, Spain, 2004.
  80. Bunting, R., Coallier, F., and Lewis, G. “Interdisciplinary Influences in Software Engineering Practices,” Post-conference of the 10th International Workshop on Software Technology and Engineering Practice – STEP 2002, 2003, pp. 62-69.
  81. Calero, C., Piattini, M., and Ruiz, F. “Towards a Database Body of Knowledge: A Study from Spain,” ACM SIGMOD Record (32:2) 2003, pp. 48-53.
  82. Daconta, M.C., Smith, K.T., Avondolio, D., and Richardson, W.C. More Java Pitfalls: 50 New Time-Saving Solutions and Workarounds, Wiley, 2003.
  83. Dieste, O., Genero, M., Juristo, N., Mate, J.L., and Moreno, A.M. “A Conceptual Model Completely Independent of the Implementation Paradigm,” Journal of Systems and Software (68:3) 2003, pp. 183-198.
  84. Draheim, D., and Weber, G. “Co-Knowledge Acquisition of Software Organizations and Academia,” 6th International Workshop on Advances in Learning Software Organizations – LSO, Springer-Verlag, Banff, Canada, 2004.
  85. Ferre, X., Juristo, N., and Moreno, A.M. “Improving Software Engineering Practice with HCI Aspects,” Software Engineering Research and Applications – SERA, Springer-Verlag, San Francisco, USA, 2003, pp. 349-363.
  86. GarzÃ?Â??¡s, J., and Piattini, M. “An Ontology for Microarchitectural Design Knowledge,” IEEE Software (22:2) 2005, pp. 28-33.
  87. Geras, A.M., Smith, M.R., and Miller, J. “A Survey of Software Testing Practices in Alberta,” Canadian Journal of Electrical and Computer Engineering (29:3) 2004, pp. 183-191.
  88. Glass, R.L., Vessey, I., and Ramesh, V. “Research in Software Engineering: An Analysis of the Literature,” Information and Software Technology (44:8) 2002, pp. 491-506.
  89. Goldsmith, R.F. Discovering Real Business Requirements for Software Project Success, Artech House Publishers, 2004, p. 241.
  90. Hannington, A., and Reed, K. “Towards a Taxonomy for Guiding Multimedia Application Development,” Ninth Asia-Pacific Software Engineering Conference – APSEC, 2002, pp. 97-106.
  91. Herrmann, D. Software Safety and Reliability: Techniques, Approaches and Standards of Key Industrial Sectors, Wiley-IEEE Computer Society Press, 2000.
  92. IEEE “Software Engineering Standards Collection Cd-Rom,” 2003.
  93. Iivari, J., Hirschheim, R., and Klein, H.K. “Towards a Distinctive Body of Knowledge for Information Systems Experts: Coding ISD Process Knowledge in Two IS Journals,” Information Systems Journal (14:4) 2004, pp. 313-342.
  94. Kappel, G., Michlmayr, E., PrÃ?Â??¶ll, B., Reich, S., and Retschitzegger, W. “Web Engineering – Old Wine in New Bottles?,” 4th International Conference on Web Engineering – ICWE, Springer-Verlag, Munich, Germany, 2004, pp. 6-12.
  95. Kruchten, P. “Casting the Software Design in the Function-Behavior-Structure Framework,” IEEE Software (22:2) 2005, pp. 52-58.
  96. Lavi, J.Z., Dalcher, D., Mannion, M., and Gallant, R. “Engineering of Computer-Based Systems – A Proposed Curriculum for a Degree Program at Bachelor Level,” IEEE Transactions on Education (47:2) 2004, pp. 247-253.
  97. Maffezini, I., Premania, A., and Ventimeglia, B. “Prolégomènes à une critique du génie logiciel,” Génie logiciel (66) 2003, pp. 2-16.
  98. Maffezini, I., Premania, A., and Ventimeglia, B. “ProlÃ?Â??©gomÃ?Â??¨nes Ã?Â?? une critique du gÃ?Â??©nie logiciel – Partie III: Interfaces,” GÃ?Â??©nie logiciel (70) 2004, pp. 2-16.
  99. Marcos, E., and Marcos, A. “A Philosophical Approach to the Concept of a Data Model: Is a Data Model, in Fact, a Model?,” Information System Frontiers (3:2) 2001, pp. 267-274.
  100. McConnell, S. Code Complete, (2nd ed.), Microsoft Press, 2004.
  101. Mehandjiev, N., Layzell, P., Brereton, P., Lewis, G., Mannion, M., and Coallier, F. “Thirteen Knights and the Seven-Headed Dragon: An Interdisciplinary Software Engineering Framework,” Post-conference Proceedings of the 10th International Workshop on Software Technology and Engineering Practice – STEP 2002, 2002, pp. 46-54.
  102. Muccini, H., Dias, M., and Richardson, D.J. “Systematic Testing of Software Architectures in the C2 Style,” 7th International Conference on the Fundamental Approaches to Software Engineering – FASE, Springer-Verlag, Barcelona, Spain, 2004, pp. 295-309.
  103. Peckham, J., and Lloyd, S.J. (Eds.) Practicing Software Engineering in the 21st Century. Idea Group Publishing, 2003.
  104. Pressman, R. Software Engineering – A Practitioner’s Approach, (6th ed.), McGraw-Hill, 2004, p. 880.
  105. Ras, E., and Weibzahl, S. “Embedding Experiences in Micro-Didactical Arrangements,” 6th International Workshop on Advances in Learning Software Organizations – LSO 2004, Springer-Verlag, Banff, Canada, 2004.
  106. Ruhe, G. “Software Engineering Decision Support – A New Paradigm for Learning Software Organizations,” 4th International Workshop on Advances in Learning Software Organizations – LSO, Springer-Verlag, Chicago, U.S.A., 2002, pp. 104-113.
  107. Rus, I., and Lindvall, M. “Knowledge Management in Software Engineering,” IEEE Software (19:3) 2002, pp. 26-38.
  108. Wernick, P., and Hall, T. “Can Thomas Kuhn’s Paradigms Help Us Understand Software Engineering?,” European Journal of Information Systems (13:3), September 2004, pp. 235-243.
  109. Wiegers, K.E. Software Requirements, (2nd ed.), Microsoft Press, 2003.

Which books discuss the SWEBOK guide?

  1. Bott, F., Coleman, A., Eaton, J., and Rowland, D. Professional Issues in Software Engineering, Taylor &Francis, 2000.
  2. Polo, M., Piattini, M., and Ruiz, F. (Eds.) Advances in Software Maintenance Management: Technologies and Solutions. Idea Group Publishing, 2002.
  3. Futrell, R.T., Schafer, D.F., and Shafer, L.I. Quality Software Project Management, Prentice Hall PTR, 2002.
  4. Kaner, C., Bach, J., and Pettichord, B. Lessons Learned in Software Testing & A Context Driven Approach, John Wiley and Sons, New York, 2002.
  5. McConnell, S. After the Gold Rush: Creating a True Profession of Software Engineering, Microsoft Press, 1999.
  6. McConnell, S. Code Complete, (2nd ed.), Microsoft Press, 2004.
  7. Daconta, M.C., Smith, K.T., Avondolio, D., and Richardson, W.C. More Java Pitfalls: 50 New Time-Saving Solutions and Workarounds, Wiley, 2003.
  8. Goldsmith, R.F. Discovering Real Business Requirements for Software Project Success, Artech House Publishers, 2004, p. 241.
  9. Herrmann, D. Software Safety and Reliability: Techniques, Approaches and Standards of Key Industrial Sectors, Wiley-IEEE Computer Society Press, 2000.
  10. McConnell, S. Code Complete, (2nd ed.), Microsoft Press, 2004.
  11. Peckham, J., and Lloyd, S.J. (Eds.) Practicing Software Engineering in the 21st Century. Idea Group Publishing, 2003.
  12. Pressman, R. Software Engineering & A Practitioner’s Approach, (6th ed.), McGraw-Hill, 2004, p. 880.
  13. Wiegers, K.E. Software Requirements, (2nd ed.), Microsoft Press, 2003.

References


[1*] J.H. Allen et al., Software Security Engineering: A Guide for Project Managers, Addison-Wesley, 2008.
[2*] M. Bishop, Computer Security: Art and Science, Addison-Wesley, 2002.
[3*] B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, 2003.
[4*] F. Bott et al., Professional Issues in Software Engineering, 3rd ed., Taylor & Francis, 2000.
[5*] J.G. Brookshear, Computer Science: An Overview, 10th ed., Addison-Wesley, 2008.
[6*] D. Budgen, Software Design, 2nd ed., Addison-Wesley, 2003.
[7*] E.W. Cheney and D.R. Kincaid, Numerical Mathematics and Computing, 6th ed., Brooks/Cole, 2007.
[8*] P. Clements et al., Documenting Software Architectures: Views and Beyond, 2nd ed., Pearson Education, 2010.
[9*] R.E. Fairley, Managing and Leading Software Projects, Wiley-IEEE Computer Society Press, 2009.
[10*] D. Galin, Software Quality Assurance: From Theory to Implementation, Pearson Education Limited, 2004.
[11*] E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1st ed., Addison-Wesley Professional, 1994.
[12*] P. Grubb and A.A. Takang, Software Maintenance: Concepts and Practice, 2nd ed., World Scientific Publishing, 2003.
[13*] A.M.J. Hass, Configuration Management Principles and Practices, 1st ed., Addison-Wesley, 2003.
[14*] E. Horowitz et al., Computer Algorithms, 2nd ed., Silicon Press, 2007.
[15*] IEEE CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices, “Software Engineering Code of Ethics and Professional Practice (Version 5.2),” 1999; www.acm.org/serving/se/code.htm.
[16*] IEEE Std. 828-2012, Standard for Configuration Management in Systems and Software Engineering, IEEE, 2012.
[17*] IEEE Std. 1028-2008, Software Reviews and Audits, IEEE, 2008.
[18*] ISO/IEC 14764 IEEE Std. 14764-2006, Software Engineering—Software Life Cycle Processes—Maintenance, IEEE, 2006.
[19*] S.H. Kan, Metrics and Models in Software Quality Engineering, 2nd ed., Addison-Wesley, 2002.
[20*] S. McConnell, Code Complete, 2nd ed., Microsoft Press, 2004.
[21*] J. McGarry et al., Practical Software Measurement: Objective Information for Decision Makers, Addison-Wesley Professional, 2001.
[22*] S.J. Mellor and M.J. Balcer, Executable UML: A Foundation for Model-Driven Architecture, 1st ed., Addison-Wesley, 2002.
[23*] D.C. Montgomery and G.C. Runger, Applied Statistics and Probability for Engineers, 4th ed., Wiley, 2007.
[24*] J.W. Moore, The Road Map to Software Engineering: A Standards-Based Guide, 1st ed., Wiley-IEEE Computer Society Press, 2006.
[25*] S. Naik and P. Tripathy, Software Testing and Quality Assurance: Theory and Practice, Wiley-Spektrum, 2008.
[26*] J. Nielsen, Usability Engineering, 1st ed., Morgan Kaufmann, 1993.
[27*] L. Null and J. Lobur, The Essentials of Computer Organization and Architecture, 2nd ed., Jones and Bartlett Publishers, 2006.
[28*] M. Page-Jones, Fundamentals of Object-Oriented Design in UML, 1st ed., Addison-Wesley, 1999.
[29*] K. Rosen, Discrete Mathematics and Its Applications, 7th ed., McGraw-Hill, 2011.
[30*] A. Silberschatz, P.B. Galvin, and G. Gagne, Operating System Concepts, 8th ed., Wiley, 2008.
[31*] H.M. Sneed, “Offering Software Maintenance as an Offshore Service,” Proc. IEEE Int’l Conf. Software Maintenance (ICSM 08), IEEE, 2008, pp. 1–5.
[32*] I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011.
[33*] S. Tockey, Return on Software: Maximizing the Return on Your Software Investment, 1st ed., Addison-Wesley, 2004.
[34*] G. Voland, Engineering by Design, 2nd ed., Prentice Hall, 2003.
[35*] K.E. Wiegers, Software Requirements, 2nd ed., Microsoft Press, 2003.
[36*] J.M. Wing, “A Specifier’s Introduction to Formal Methods,” Computer, vol. 23, no. 9, 1990, pp. 8, 10–23.

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 3.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 3.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 3.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:

  1. copies are made for non-profit educational use and not for resale, advertising, or other commercial use;
  2. any copy or other use is accompanied by a full citation to the original work and its copyright; and
  3. the copied text has not been materially altered.

 

What You Cannot Do

You may not copy or otherwise reproduce or share SWEBOK 3.0. Under no circumstances are you permitted to distribute or sell SWEBOK version 3.0 without permission. You may not post SWEBOK version 3.0 publicly, or provide any manner of public access to your downloaded document, including through links. You may not translate SWEBOK 3.0 into other languages, reuse significant portions of SWEBOK 3.0 for commercial purposes, or alter the text of SWEBOK 3.0 in any way.

The Fine Print

While all reasonable care has been taken in the preparation and review of SWEBOK version 3.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.

Inside the Computer Society