SFIA 7 AND SWEBOK v3 - The guide to the software engineering body of knowledge
This Software Engineering competency model is based on the SWEBOK v3 and SFIA 7 (published July 2018). Presented here is a route map into software engineering competencies via the Knowledge Areas of the SWEBOK.
Contributors: Volunteers from the IEEE-CS Professional & Educational Activities Board (PEAB) Engineering Disciplines Committee., SFIA 7 Software Engineering Working Group.
Rights: Selected extracts from Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEE Computer Society, 2014; www.swebokwiki.org.
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 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.
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
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 software engineering competencies
- Requirements definition and management
- Real-time/embedded systems development
- Methods and tools
- Testing
- Configuration management
- Safety engineering
Related enterprise IT competencies in SFIA
- Business analysis
- User research
- User experience analysis
- Business process testing
- Solution architecture
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 software engineering 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 software engineering competencies
- Programming/software development
- Real-time/embedded systems development
- Systems integration and build
- Testing
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 software engineering competencies
Related enterprise IT competencies in SFIA
Software maintenance knowledge area
Scope:
Software development efforts result in the delivery of a software product that satisfies user requirements. Accordingly, the software product must change or evolve. Once in operation, defects are uncovered, operating environments change, and new user requirements surface. The maintenance phase of the life cycle begins following a warranty period or postimplementation support delivery, but maintenance activities occur much earlier.
Software maintenance is an integral part of a software life cycle. However, it has not received the same degree of attention that the other phases have. Historically, software development has had a much higher profile than software maintenance in most organizations. This is now changing, as organizations strive to squeeze the most out of their software development investment by keeping software operating as long as possible. The open source paradigm has brought further attention to the issue of maintaining software artifacts developed by others.
In the SWEBOK, software maintenance is defined as the totality of activities required to provide cost-effective support to software. Activities are performed during the predelivery stage as well as during the postdelivery stage. Predelivery activities include planning for postdelivery operations, maintainability, and logistics determination for transition activities. Postdelivery activities include software modification, training, and operating or interfacing to a help desk. [Extract from SWEBOK v3.0].
Full content is here SWEBOK Chapter 5: Software Maintenance.
Core software engineering competencies
Related enterprise IT competencies in SFIA
Software configuration management knowledge area
Scope:
The configuration of a system is the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product ; it can also be thought of as a collection of specific versions of hardware, firmware, or software items combined according to specific build procedures to serve a particular purpose. Configuration management is the discipline of identifying the configuration of a system at distinct points in time for the purpose of systematically controlling changes to the configuration and maintaining the integrity and traceability of the configuration throughout the system life cycle.
Software configuration management (SCM) is a supporting-software life cycle process that benefits project management, development and maintenance activities, quality assurance activities, as well as the customers and users of the end product. The concepts of configuration management apply to all items to be controlled, although there are some differences in implementation between hardware CM and software CM.
The SCM activities are management and planning of the SCM process, software configuration identification, software configuration control, software configuration status accounting, software configuration auditing, and software release management and delivery. [Extract from SWEBOK v3.0].
Full content is here SWEBOK Chapter 6: Software Configuration Management.
Core software engineering competencies
Software engineering management knowledge area
Scope:
Full content is here SWEBOK Chapter 7: Software Engineering Management
Software engineering management can be defined as the application of management activities—planning, coordinating, measuring, monitoring, controlling, and reporting1—to ensure that software products and software engineering services are delivered efficiently, effectively, and to the benefit of stakeholders. Software engineering management activities occur at three levels: organizational and infrastructure management, project management, and management of the measurement program. [Extract from SWEBOK v3.0].
Software engineering management competencies
Related enterprise IT competencies in SFIA
- Programme management
- Resourcing
- Performance management
- Relationship management
- Enterprise IT governance
Software engineering process knowledge area
Scope:
An engineering process consists of a set of interrelated activities that transform one or more inputs into outputs while consuming resources to accomplish the transformation. Many of the processes of traditional engineering disciplines (e.g., electrical, mechanical, civil, chemical) are concerned with transforming energy and physical entities from one form into another, as in a hydroelectric dam that transforms potential energy into electrical energy or a petroleum refinery that uses chemical processes to transform crude oil into gasoline.
In this knowledge area (KA), software engineering processes are concerned with work activities accomplished by software engineers to develop, maintain, and operate software, such as requirements, design, construction, testing, configuration management, and other software engineering processes. Software processes are specified for a number of reasons: to facilitate human understanding, communication, and coordination; to aid management of software projects; to measure and improve the quality of software products in an efficient manner; to support process improvement; and to provide a basis for automated support of process execution. [Extract from SWEBOK v3.0].
Full content is here SWEBOK Chapter 8: Software Engineering Process.
Software engineering management competencies
- Methods and tools
- Measurement
- Systems development management
- Organisational capability development
- Quality management
Software engineering models knowledge area
Scope:
Software engineering models and methods impose structure on software engineering with the goal of making that activity systematic, repeatable, and ultimately more success-oriented. Using models provides an approach to problem solving, a notation, and procedures for model construction and analysis. Methods provide an approach to the systematic specification, design, construction, test, and verification of the end-item software and associated work products. Software engineering models and methods vary widely in scope—from addressing a single software life cycle phase to covering the complete software life cycle. [Extract from SWEBOK v3.0].
Full content is here SWEBOK Chapter 9: Software Engineering Models.
Core software engineering competencies
Related enterprise IT competencies in SFIA
Software quality knowledge area
Scope:
Software quality may refer: to desirable characteristics of software products, to the extent to which a particular software product possess those characteristics, and to processes, tools, and techniques used to achieve those characteristics. Over the years, authors and organizations have defined the term quality differently. To Phil Crosby, it was “conformance to requirements” . Watts Humphrey refers to it as “achieving excellent levels of “fitness for use”. Meanwhile, IBM coined the phrase “market-driven quality,” where the “customer is the final arbiter”.
More recently, software quality is defined as the “capability of software product to satisfy stated and implied needs under specified conditions” and as “the degree to which a software product meets established requirements; however, quality depends upon the degree to which those established requirements accurately represent stakeholder needs, wants, and expectations”. Both definitions embrace the premise of conformance to requirements. Neither refers to types of requirements (e.g., functional, reliability, performance, dependability, or any other characteristic). Significantly, however, these definitions emphasize that quality is dependent upon requirements.
Software quality is achieved by conformance to all requirements regardless of what characteristic is specified or how requirements are grouped or named.
For all engineered products, the primary goal is delivering maximum stakeholder value, while balancing the constraints of development cost and schedule; this is sometimes characterized as “fitness for use.” Stakeholder value is expressed in requirements. For software products, stakeholders could value price (what they pay for the product), lead time (how fast they get the product), and software quality. [Extract from SWEBOK v3.0].
Full content is here SWEBOK Chapter 10: Software Quality.
Core software engineering competencies
Software engineering management competencies
Related enterprise IT competencies in SFIA
Software engineering professional practice knowledge area
The Software Engineering Professional Practice knowledge area (KA) is concerned with the knowledge, skills, and attitudes that software engineers must possess to practice software engineering in a professional, responsible, and ethical manner. Because of the widespread applications of software products in social and personal life, the quality of software products can have profound impact on our personal well-being and societal harmony. Software engineers must handle unique engineering problems, producing software with known characteristics and reliability. This requirement calls for software engineers who possess a proper set of knowledge, skills, training, and experience in professional practice.
A software engineer displays professionalism notably through adherence to codes of ethics and professional conduct and to standards and practices that are established by the engineer’s professional community. The professional community is often represented by one or more professional societies; those societies publish codes of ethics and professional conduct as well as criteria for admittance to the community. Those criteria form the basis for accreditation and licensing activities and may be used as a measure to determine engineering competence or negligence. [Extract from SWEBOK v3.0].
Full content is here SWEBOK Chapter 11: Software Engineering Professional Practice.
Related enterprise IT competencies in SFIA
Software engineering economics knowledge area
Scope:
Software engineering economics is about making decisions related to software engineering in a business context. The success of a software product, service, and solution depends on good business management. Yet, in many companies and organizations, software business relationships to software development and engineering remain vague. This knowledge area (KA) provides an overview on software engineering economics. Economics is the study of value, costs, resources, and their relationship in a given context or situation. In the discipline of software engineering, activities have costs, but the resulting software itself has economic attributes as well. Software engineering economics provides a way to study the attributes of software and software processes in a systematic way that relates them to economic measures. These economic measures can be weighed and analyzed when making decisions that are within the scope of a software organization and those within the integrated scope of an entire producing or acquiring business. Software engineering economics is concerned with aligning software technical decisions with the business goals of the organization. In all types of organizations — be it “for-profit,” “not-for- profit,” or governmental — this translates into sustainably staying in business. In “for-profit” organizations this additionally relates to achieving a tangible return on the invested capital — both assets and capital employed. [Extract from SWEBOK v3.0].
Full content is here SWEBOK Chapter 12: Software Engineering Economics.
Software engineering management competencies
Related enterprise IT competencies in SFIA
- Financial management
- Portfolio management
- Product management
- Programme management
- Benefits management
- Contract management
