Skip to content. | Skip to navigation

Personal tools

You are here: Home / Tools and resources / Bodies of Knowledge / SWEBOK - The Guide to the Software Engineering Body of Knowledge

SWEBOK - The Guide to the Software Engineering Body of Knowledge

The Guide to the Software Engineering Body of Knowledge (SWEBOK) from the IEEE-CS is the industry standard source for the knowledge needed by software engineering professionals. The IEEE-CS Professional & Educational Activities Board sponsored a collaborative project to develop a competency model for Software Engineers based on SFIA. Presented here is a route map into Software Engineering competencies via the Knowledge Areas of the SWEBOK.

Click on image to see full size.

Each of the Knowledge Areas in the SWEBOK were analysed to determine the related Software Engineering (SWE) competencies. These competencies are grouped into 

  • Core Software Engineering competencies
  • Software Engineering Management competencies
  • Related Enterprise Enterprise IT competencies

Core Software Engineering (SWE) competencies

These are the competencies typically needed by Software Engineering practitioners.

Note that not all of the competencies listed are required by all Software Engineers

  • The set of Competencies required depends on the nature of the employing organisation, team structures, and the specific roles and responsibilities of the Software Engineers they employ.

Software Engineering (SWE) Management competencies

  • These are the competencies typically needed by managers of Software Engineering functions or teams.

The diagram below shows the mapping of SFIA Competencies to SWEBOK Knowledge Areas.

Click on image to see full size.


Enterprise IT Competencies related to Software Engineering

These are the Competencies which are related to Enterprise IT functions and roles which typically support or interact with Software Engineering functions and team.

  • Some Software Engineering functions will find it helpful to refer to and/or use some of these competencies.
  • This is particularly relevant in Enterprise IT organisations which employ Software Engineers
The diagram below extends the mapping of SFIA Competencies to SWEBOK Knowledge Areas to include the related Enterprise IT competencies.
Click on image to see full size.

Software Requirements Knowledge Area

Scope:

Software Requirements 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. [Extract from SWEBOK v3.0].

Full content is here SWEBOK Chapter 1: Software Requirements.

Core SWE competencies

Related Enterprise IT Competencies in SFIA

Software Design Knowledge Area

Scope:

Software design is the software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction. A software design (the result) describes the software architecture—that is, how software is decomposed and organized into components—and the interfaces between those components. It should also describe the components at a level of detail that enables their construction. [Extract from SWEBOK v3.0].

Full content is here SWEBOK Chapter 2: Software Design.

Core SWE competencies

Related Enterprise IT Competencies in SFIA

Software Construction Knowledge Area

Scope:

Software construction refers to the detailed creation of working software through a combination of coding, verification, unit testing, integration testing, and debugging. The Software Construction knowledge area (KA) is linked to all the other KAs, but it is most strongly linked to Software Design and Software Testing because the software construction process involves significant software design and testing. [Extract from SWEBOK v3.0].

Full content is here SWEBOK Chapter 3: Software Construction.

Core SWE competencies

Related Enterprise IT Competencies in SFIA

Software Testing Knowledge Area

Scope:

Software testing consists of the dynamic verification that a program provides expected behaviors on a finite set of test cases, suitably selected from the usually infinite execution domain. The words in bold correspond to key issues in describing the Software Testing knowledge area (KA):

  • Dynamic: This term means that testing always implies executing the program on selected inputs. To be precise, the input value alone is not always sufficient to specify a test, since a complex, non-deterministic system might react to the same input with different behaviors, depending on the system state. … Static techniques are different from and complementary to dynamic testing. Static techniques are covered in the Software Quality KA.
  • Finite: Even in simple programs, so many test cases are theoretically possible that exhaustive testing could require months or years to execute. This is why, in practice, a complete set of tests can generally be considered infinite, and testing is conducted on a subset of all possible tests, which is determined by risk and prioritization criteria. Testing always implies a tradeoff between limited resources and schedules on the one hand and inherently unlimited test requirements on the other.
  • Selected: The many proposed test techniques differ essentially in how the test set is selected, and software engineers must be aware that different selection criteria may yield vastly different degrees of effectiveness. How to identify the most suitable selection criterion under given conditions is a complex problem; in practice, risk analysis techniques and software engineering expertise are applied.
  • Expected: It must be possible, although not always easy, to decide whether the observed outcomes of program testing are acceptable or not; otherwise, the testing effort is useless. The observed behavior may be checked against user needs (commonly referred to as testing for validation), against a specification (testing for verification), or, perhaps, against the anticipated behavior from implicit requirements or expectations.

In recent years, the view of software testing has matured into a constructive one. Testing is no longer seen as an activity that starts only after the coding phase is complete with the limited purpose of detecting failures. Software testing is, or should be, pervasive throughout the entire development and maintenance life cycle. I[Extract from SWEBOK v3.0].

Full content is here SWEBOK Chapter 4: Software Testing.

Core SWE competencies