Overview of Software Engineering Education Knowledge

<< Guiding Principles

Guidelines for SE Curriculum Design and Delivery >>

Chapter 4: Overview of Software Engineering Education

Knowledge

This chapter describes the body of knowledge that is appropriate for an undergraduate program

in software engineering. The knowledge is designated as the SEEK (Software Engineering

Education Knowledge).

4.1

Process of Determining the SEEK

The development model chosen for determining SE2004 was based on the model used to

construct the CCCS volume. The initial selection of the SEEK areas was based on the

SWEBOK knowledge areas and multiple discussions with dozens of SEEK area volunteers. The

SEEK area volunteers were divided into groups representing each individual SEEK area, where

each group contained roughly seven volunteers. These groups were assigned the task of

providing the details of the units that compose a particular educational knowledge area and the

further refinement of these units into topics. To facilitate their work, references to existing

related software engineering body of knowledge efforts (e.g. SWEBOK, CSDP Exam, and SEI

curriculum recommendations) and a set of templates for supporting the generation of units and

topics were provided.

After the volunteer groups generated an initial draft of their individual education knowledge area

details, the steering committee held a face-to-face forum that brought together education

knowledge and pedagogy area volunteers to iterate over the individual drafts and generate an

initial draft of the SEEK (see Appendix B for an attendee list). This workshop held with this

particular goal mirrored a similar overwhelmingly successful workshop held by CCCS at this

very point in their development process. Once the content of the education knowledge areas was

stabilized, topics were identified to be core or elective. Topics were also labeled with one of

three Bloom's taxonomy's levels of educational objectives; namely, knowledge, comprehension,

or application. Only these three levels of learning were chosen from Bloom's taxonomy, because

they represent what knowledge may be reasonably learned during an undergraduate education.

After the workshop, a draft of the SEEK was completed. Subsequently, the SEEK draft went

through an intensive internal review (by a group of selected experts in software engineering) and

several widely publicized public reviews. After the completion of each review, the steering

committee iterated over the reviewer comments to further refine and improve the contents of the

SEEK.

4.2

Knowledge Areas, Units, and Topics

Knowledge is a term used to describe the whole spectrum of content for the discipline:

information, terminology, artifacts, data, roles, methods, models, procedures, techniques,

practices, processes, and literature. The SEEK is organized hierarchically into three levels. The

highest level of the hierarchy is the education knowledge area, representing a particular sub-

discipline of software engineering that is generally recognized as a significant part of the body of

software engineering knowledge that an undergraduate should know. Knowledge areas are high-

level structural elements used for organizing, classifying, and describing software engineering

knowledge. Each area is identified by an abbreviation, such as PRF for professional practices.

SE2004 Volume 8/23/2004

Each area is broken down into smaller divisions called units, which represent individual

thematic modules within an area. Adding a two or three letter suffix to the area identifies each

unit; as an example, PRF.com is a unit on communication skills.

Each unit is further subdivided into a set of topics, which are the lowest level of the hierarchy.

4.3

Core Material

In determining the SEEK, it is recognized that software engineering, as a discipline, is relatively

young in its maturation, and that common agreement on the definition of an education body of

knowledge is evolving. The SEEK developed and presented in this document is based on a

variety of previous studies and commentaries on the recommended content for the discipline. It

was specially designed to support the development of undergraduate software engineering

curricula, and therefore, does not include all the knowledge that would exist in a more

generalized body of knowledge representation. Hence, a body of core knowledge has been

defined. The core consists of the essential material that professionals teaching software

engineering agree is necessary for anyone to obtain an undergraduate degree in this field. By

insisting on a broad consensus in the definition of the core, it is hoped the core will be as small

as possible, giving institutions the freedom to tailor the elective components of the curriculum in

ways that meet their individual needs.

The following points should be emphasized to clarify the relationship between the SEEK and the

steering committee's ultimate goal of providing undergraduate software engineering curriculum

recommendations.

· The core is not a complete curriculum. Because the core is defined as minimal, it does not,

by itself, constitute a complete undergraduate curriculum. Every undergraduate program will

include additional units, both within and outside the software engineering body of

knowledge, which this document does not attempt address.

Core units are not necessarily limited to a set of introductory courses taken early in the

undergraduate curriculum. Although many of the units defined as core are indeed

introductory, there are also some core units that clearly must be covered only after students

have developed significant background in the field. For example, topics in such areas as

project management, requirements elicitation, and abstract high-level modeling may require

knowledge and sophistication that lower-division students do not possess. Similarly,

introductory courses may include elective units1 alongside the coverage of core material. The

designation core simply means required and says nothing about the level of the course in

which it appears.

4.4

Unit of Time

The SEEK must define a metric that establishes a standard of measurement, in order to judge the

actual amount of time required to cover a particular unit. Choosing such a metric was quite

Material offered as part of an undergraduate program that falls outside the core is considered to

be elective.

SE2004 Volume 8/23/2004

difficult because no standard measure is recognized throughout the world. For consistency with

the earlier curriculum reports, namely the other computing curricula volumes related to this

effort, it was decided to express time in hours. An hour corresponds to the actual in-class time

required to present the material in a traditional lecture-oriented format (referred to in this

document as contact hours). To dispel any potential confusion, however, it is important to

underscore the following observations about the use of lecture hours as a measure:

· The steering committee does not seek to endorse the lecture format. Even though we have

used a metric that has its roots in a classical, lecture-oriented format, the steering committee

believes that there are other styles--particular given recent improvements in educational

technology--that can be at least as effective. For some of these styles, the notion of hours

may be difficult to apply. Even so, the time specifications should at least serve as a

comparative measure, in the sense that a 5-hour unit will presumably take roughly five times

as much time to cover as a 1-hour unit, independent of the teaching style.

The hours specified do not include time spent outside of class. The time assigned to a unit

does not include the instructor's preparation time or the time students spend outside of class.

As a general guideline, the amount of out-of-class work is approximately three times the in-

hours (3 in class and 9 outside).

The hours listed for a unit represent a minimum level of coverage. The time measurements

assigned for each unit should be interpreted as the minimum amount of time necessary to

enable a student to perform the learning objectives for that unit. It is always appropriate to

spend more time on a unit than the mandated minimum.

4.5

Relationship of the SEEK to the Curriculum

The SEEK does not represent the curriculum, but rather provides the foundation for the design,

implementation, and delivery of the educational units that make up a software engineering

curriculum. Other chapters of the SE2004 Volume provide guidance and support on how to use

the SEEK to develop a curriculum. In particular, the organization and content of the knowledge

areas and knowledge units should not be deemed to imply how the knowledge should be

organized into education units or activities. For example, the SEEK does not advocate a

sequential ordering of the KAs (1st CMP, 2nd FND, 3rd PRF, etc.). Nor does it suggest how

topics and units should be combined into education units. Furthermore, the SEEK is not intended

to purport any special curriculum development methodology (waterfall, incremental, cyclic,

etc.).

4.6

Selection of Knowledge Areas

The SWEBOK Guide provided the starting point for determining knowledge areas. Because both

the SE2004 Steering Committee and the SEEK area volunteers felt strongly about emphasizing

the academic discipline of software engineering, the area chosen to represent the theoretical and

scientific foundations of developing software products eventually grew to one half the size of the

core. This prompted a reevaluation of whether the original goals of emphasizing the discipline

were indeed being met. The resulting set of knowledge areas was rebalanced to support these

goals. The result is believed to stress the fundamental principles, knowledge, and practices that

underlie the software engineering discipline in a form suitable for undergraduate education.

SE2004 Volume 8/23/2004

4.7

SE Education Knowledge Areas

In this section, we describe the ten knowledge areas that make up the SEEK: Computing

Essentials (CMP), Mathematical & Engineering Fundamentals (FND), Professional Practice

(PRF), Software Modeling & Analysis (MAA), Software Design (DES), Software Verification &

Validation (VAV), Software Evolution (EVL), Software Process (PRO), Software Quality

(QUA), and Software Management (MGT). The knowledge areas do not include material about

continuous mathematics or the natural sciences; the needs in these areas will be discussed in

other parts of the SE2004 volume. For each knowledge area, there is a short description and then

a table that delineates the units and topics for that area. For each knowledge unit, recommended

contact hours are designated. For each topic, a Bloom taxonomy level (indicating what capability

a graduate should possess) and the topic's relevance (indicating whether the topics is essential,

desirable, or optional to the core) are designated. Table 1 summarizes the SEEK knowledge

areas, with their sets of knowledge units, and lists the minimum number of hours recommended

for each area and unit.

Bloom's attributes are specified using one of the letters k, c, or a, which represent:

· Knowledge (k) - Remembering previously learned material. Test observation and recall of

information; that is, "bring to mind the appropriate information" (e.g. dates, events, places,

knowledge of major ideas, mastery of subject matter).

Comprehension (c) - Understanding information and the meaning of material presented. For

example, be able to translate knowledge to a new context, interpret facts, compare, contrast,

order, group, infer causes, predict consequences, etc.

Application (a) - Ability to use learned material in new and concrete situations. For example,

using information, methods, concepts, and theories to solve problems requiring the skills or

knowledge presented.

A topic's relevance to the core is represented as follows:

· Essential (E) - The topic is part of the core.

Desirable (D) - The topic is not part of the core, but it should be included in the core of a

particular program if possible; otherwise, it should be considered as part of elective

materials.

Optional (O) - The topic should be considered as elective only.

SE2004 Volume 8/23/2004

Table 1: SEEK Knowledge Areas and Knowledge Units*

KA/KU

Title

hrs

KA/KU

Title

hrs

CMP

Computing Essentials

172

VAV

Software V & V

CMP.cf

Computer Science foundations

140

VAV.fnd

V&V terminology and foundations

CMP.ct

Construction technologies

VAV.rev

Reviews

CMP.tl

Construction tools

VAV.tst

Testing

CMP.fm

Formal construction methods

VAV.hct

Human computer UI testing and

evaluation

VAV.par

Problem analysis and reporting

FND

Mathematical & Engineering Fundamentals

EVL

Software Evolution

FND.mf

Mathematical foundations

EVO.pro

Evolution processes

FND.ef

Engineering foundations for software

EVO.ac

Evolution activities

FND.ec

Engineering economics for software

PRF

Professional Practice

PRO

Software Process

PRF.psy

Group dynamics / psychology

PRO.con

Process concepts

PRF.com

Communications skills (specific to SE)

PRO.imp

Process implementation

PRF.pr

Professionalism

MAA

Software Modeling & Analysis

QUA

Software Quality

MAA.md

Modeling foundations

QUA.cc

Software quality concepts and

culture

MAA.tm

Types of models

QUA.std

Software quality standards

MAA.af

Analysis fundamentals

QUA.pro

Software quality processes

MAA.rfd

Requirements fundamentals

QUA.pca

Process assurance

MAA.er

Eliciting requirements

QUA.pda

Product assurance

MAA.rsd

Requirements specification & documentation

MAA.rv

Requirements validation

DES

Software Design

MGT

Software Management

DES.con

Design concepts

MGT.con

Management concepts

DES.str

Design strategies

MGT.pp

Project planning

DES.ar

Architectural design

MGT.per

Project personnel and organization

DES.hci

Human computer interface design

MGT.ctl

Project control

DES.dd

Detailed design

MGT.cm

Software configuration management

DES.ste

Design support tools and evaluation

* Section 4.18 (Systems and Application Specialties) includes additional material, which is not

part of the core, which can be used to extend core knowledge and provide for specialization.

4.8

Computing Essentials

Description

Computing essentials includes the computer science foundations that support the design and

construction of software products. This area also includes knowledge about the transformation

of a design into an implementation, the tools used during this process, and formal software

construction methods.

Units and Topics

Reference

k,c,a E,D,O Hours Related Topics

CMP

172

Computing Essentials

CMP.cf

Computer Science foundations

140

CMP.cf.1

Programming Fundamentals (CCCS PF1 to PF5) (control & data,

typing, recursion)

CMP.cf.2

Algorithms, Data Structures/Representation (static & dynamic)

CMP.ct.1,CMP.f

m.5,MAA.cc.1

and Complexity (CCCS AL 1 to AL 5)

SE2004 Volume 8/23/2004

CMP.cf.3

Problem solving techniques

CMP.cf.1

CMP.cf.4

Abstraction use and support for (encapsulation, hierarchy, etc)

MAA.md.1

CMP.cf.5

Computer organization (parts of CCCS AR 1 to AR 5)

CMP.cf.6

Basic concept of a system

MAA.rfd.7

CMP.cf.7

Basic user human factors (I/O, error messages, robustness)

DES.hci

CMP.cf.8

Basic developer human factors (comments, structure, readability)

CMP.cf.1

CMP.cf.9

Programming language basics (key concepts from CCCS PL1-

CMP.ct.3,CMP.ct

PL6)

CMP.cf.10

Operating system basics (key concepts from CCCS OS1-OS5)

CMP.ct.10,CMP.

ct.15

CMP.cf.11

Database basics

DES.con.2

CMP.cf.12

Network communication basics

CMP.cf.13

Semantics of programming languages

CMP.ct

Construction technologies

CMP.ct.1

API design and use

DES.dd.4

CMP.ct.2

Code reuse and libraries

CMP.cf.1

CMP.ct.3

Object-oriented run-time issues (e.g. polymorphism, dynamic

CMP.cf.1,9,DES.

str.2

binding, etc.)

CMP.ct.4

Parameterization and generics

CMP.cf.1

CMP.ct.5

Assertions, design by contract, defensive programming

MAA.md.2

CMP.ct.6

Error handling, exception handling, and fault tolerance

DES.con.2,VAV.t

st.2,VAV.tst.9

CMP.ct.7

State-based and table driven construction techniques

FND.mf.7,MAA.t

m.2,CMP.cf.10

CMP.ct.8

Run-time configuration and internationalization

DES.hci.6

CMP.ct.9

Grammar-based input processing (parsing)

FND.mf.8

CMP.ct.10

Concurrency primitives (e.g. semaphores, monitors, etc.)

CMP.cf.10

CMP.ct.11

Middleware (components and containers)

DES.dd.3,5

CMP.ct.12

Construction methods for distributed software

CMP.cf.2

CMP.ct.13

Constructing heterogeneous (hardware and software) systems;

DES.ar.3

hardware-software codesign

CMP.ct.14

Performance analysis and tuning

FND.ef.4,DES.co

n.6,CMP.tl.4,VAV

.fnd.4

CMP.ct.15

Platform standards (Posix etc.)

CMP.ct.16

Test-first programming

VAV.tst.1

CMP.tl

Construction tools

DES.ste.1

CMP.tl.1

Development environments

CMP.tl.2

GUI builders

DES.hci

CMP.tl.3

Unit testing tools

VAV.tst.1

CMP.tl.4

Application oriented languages (e.g. scripting, visual, domain-

specific, markup, macros, etc.)

CMP.tl.5

Profiling, performance analysis and slicing tools

CMP.ct.14

CMP.fm

Formal construction methods

DES.dd.9,MAA.af

.6,EVO.ac.7

CMP.fm.1

Application of abstract machines (e.g. SDL, Paisley, etc.)

CMP.fm.2

Application of specification languages and methods (e.g. ASM,

MAA.md.3,MAA.r

sd.3

B, CSP, VDM, Z)

CMP.fm.3

Automatic generation of code from a specification

CMP.fm.4

Program derivation

CMP.fm.5

Analysis of candidate implementations

MAA.cf.2

CMP.fm.6

Mapping of a specification to different implementations

CMP.fm.7

Refinement

SE2004 Volume 8/23/2004

CMP.fm.8

Proofs of correctness

FND.mf.3

4.9

Mathematical and Engineering Fundamentals

Description

The mathematical and engineering fundamentals of software engineering provide theoretical and

scientific underpinnings for the construction of software products with desired attributes. These

fundamentals support describing software engineering products in a precise manner. They

provide the mathematical foundations to model and facilitate reasoning about these products and

their interrelations, as well as form the basis for a predictable design process. A central theme is

engineering design: a decision-making process of iterative nature, in which computing,

mathematics, and engineering sciences are applied to deploy available resources efficiently to

meet a stated objective.

Units and Topics

Reference

k,c,a E,D,O Hours Related Topics

FND

Mathematical and Engineering Fundamentals

FND.mf

Mathematical foundations*

FND.mf.1

Functions, Relations and Sets (CCCS DS1)

FND.mf.2

Basic Logic (propositional and predicate) (CCCS DS2)

MAA.md.2,3

FND.mf.3

Proof Techniques (direct, contradiction, inductive) (CCCS DS3)

CMP.fm.8

FND.mf.4

Basic Counting (CCCS DS4)

FND.mf.5

Graphs and Trees (CCCS DS5)

CMP.cf.2

FND.mf.6

Discrete Probability (CCCS DS6)

FND.ef.2

FND.mf.7

Finite State Machines, regular expressions

CMP.ct.7,MAA.t

m.2

FND.mf.8

Grammars

CMP.ct.9

FND.mf.9

Numerical precision, accuracy and errors

FND.mf.10

Number Theory

FND.mf.11

Algebraic Structures

FND.ef

Engineering foundations for software

FND.ef.1

Empirical methods and experimental techniques (e.g., computer-

VAV.fnd.4,VAV.h

ct.6

related measuring techniques for CPU and memory usage)

FND.ef.2

Statistical analysis (including simple hypothesis testing,

FND.mf.6

estimating, regression, correlation etc.)

FND.ef.3

Measurement and metrics

PRO.con.5,PRO.i

mp.4

FND.ef.4

Systems development (e.g. security, safety, performance, effects

MAA.af.4,DES.co

n.6,VAV.fnd.4,VA

of scaling, feature interaction, etc.)

V.tst.9

FND.ef.5

Engineering design (e.g. formulation of problem, alternative

FND.ec.3,MAA.af

solutions, feasibility, etc.)

FND.ef.6

Theory of measurement (e.g. criteria for valid measurement)

FND.ef.7

Engineering science for other engineering disciplines (strength of

materials, digital system principles, logic design, fundamentals of

thermodynamics, etc.)

FND.ec

Engineering economics for software

10 PRF.pr.6

FND.ec.1

Value considerations throughout the software lifecycle

FND.ec.2

Generating system objectives (e.g. participatory design,

PRF.psy.4,MAA.

er.2

stakeholder win-win, quality function deployment, prototyping,

SE2004 Volume 8/23/2004

etc.)

FND.ec.3

Evaluating cost-effective solutions (e.g. benefits realization,

DES.con.7,MAA.

af.4,MGT.pp.4

tradeoff analysis, cost analysis, return on investment, etc.)

FND.ec.4

Realizing system value (e.g. prioritization, risk resolution,

MAA.af.4,MGT.p

p.6

controlling costs, etc.)

* Topics 1-6 correspond to Computer Science curriculum guidelines for discrete structures 1-6

4.10 Professional Practice

Description

Professional Practice is concerned with the knowledge, skills, and attitudes that software

engineers must possess to practice software engineering in a professional, responsible, and

ethical manner. The study of professional practices includes the areas of technical

communication, group dynamics and psychology, and social and professional responsibilities.

Units and Topics

Reference

k,c,a E,D,O Hours Related Topics

PRF

Professional Practice

PRF.psy

Group dynamics / psychology

PRF.psy.1

Dynamics of working in teams/groups

PRF.psy.2

Individual cognition (e.g. limits)

DES.hci.10

PRF.psy.3

Cognitive problem complexity

MAA.rfd.8

PRF.psy.4

Interacting with stakeholders

FND.ec.2

PRF.psy.5

Dealing with uncertainty and ambiguity

PRF.psy.6

Dealing with multicultural environments

PRF.com

Communications skills (specific to SE)

PRF.com.1

Reading, understanding and summarizing reading (e.g. source

MAA.rsd.1

code, documentation)

PRF.com.2

Writing (assignments, reports, evaluations, justifications, etc.)

PRF.com.3

Team and group communication (both oral and written, email,

MGT.per

etc.)

PRF.com.4

Presentation skills

PRF.pr

Professionalism

PRF.pr.1

Accreditation, certification, and licensing

PRF.pr.2

Codes of ethics and professional conduct

PRF.pr.3

Social, legal, historical, and professional issues and concerns

PRF.pr.4

The nature and role of professional societies

PRF.pr.5

The nature and role of software engineering standards

MAA.rsd.1,CMP.c

t.14,PRO.imp.3,7,

QUA.std

PRF.pr.6

The economic impact of software

FND.ec

PRF.pr.7

Employment contracts

SE2004 Volume 8/23/2004

4.11 Software Modeling and Analysis

Description

Modeling and analysis can be considered core concepts in any engineering discipline, because

they are essential to documenting and evaluating design decisions and alternatives. Modeling

and analysis is first applied to the analysis, specification, and validation of requirements.

Requirements represent the real-world needs of users, customers, and other stakeholders affected

by the system. The construction of requirements includes an analysis of the feasibility of the

desired system, elicitation and analysis of stakeholders' needs, the creation of a precise

description of what the system should and should not do along with any constraints on its

operation and implementation, and the validation of this description or specification by the

stakeholders.

Units and Topics

Reference

k,c,a E,D,O Hours Related Topics

MAA

Software Modeling and Analysis

MAA.md

Modeling foundations

19 PRO.con.3,QUA.

pro.1,QUA.pda.3

MAA.md.1

Modeling principles (e.g. decomposition, abstraction,

CMP.cf.4

generalization, projection/views, explicitness, use of formal

approaches, etc.)

MAA.md.2

Pre & post conditions, invariants

CMP.ct.5

MAA.md.3

Introduction to mathematical models and specification languages

MAA.rsd.3,CMP.f

m.2

(Z, VDM, etc.)

MAA.md.4

Properties of modeling languages

MAA.md.5

Syntax vs. semantics (understanding model representations)

CMP.cf.9

MAA.md.6

Explicitness (make no assumptions, or state all assumptions)

MAA.tm

Types of models

12 MAA.md

MAA.tm.1

Information modeling (e.g. entity-relationship modeling, class

MAA.rsd.3,DES.d

d.5

diagrams, etc.)

MAA.tm.2

Behavioral modeling (e.g. structured analysis, state diagrams,

FND.mf.7,MAA.er

.2,MAA.rsd.3,DE

use case analysis, interaction diagrams, failure modes and

S.dd.5

effects analysis, fault tree analysis etc.)

MAA.tm.3

Structure modeling (e.g. architectural, etc.)

MAA.rfd.7

MAA.tm.4

Domain modeling (e.g. domain engineering approaches, etc.)

MAA.tm.5

Functional modeling (e.g. component diagrams, etc.)

MAA.tm.6

Enterprise modeling (e.g. business processes, organizations,

goals, etc.)

MAA.tm.7

Modeling embedded systems (e.g. real-time schedulability

analysis, external interface analysis, etc.)

MAA.tm.8

Requirements interaction analysis (e.g. feature interaction, house

of quality, viewpoint analysis, etc.)

MAA.tm.9

Analysis Patterns (e.g. problem frames, specification re-use, etc.)

MAA.af

Analysis fundamentals

MAA.af.1

Analyzing well-formedness (e.g. completeness, consistency,

robustness, etc.)

MAA.af.2

Analyzing correctness (e.g. static analysis, simulation, model

checking, etc.)

MAA.af.3

Analyzing quality (non-functional) requirements (e.g. safety,

FND.ef.4,QUA.pd

a,DES.con.6,VAV

security, usability, performance, root cause analysis, etc.)

SE2004 Volume 8/23/2004

.fnd.4,VAV.tst.9,V

AV.hct,EVO.ac.4

MAA.af.4

Prioritization, trade-off analysis, risk analysis, and impact

FND.ec.3,4,QUA.

pda.4

analysis

MAA.af.5

Traceability

DES.ar.4,EVO.pr

o.2

MAA.af.6

Formal analysis

CMP.fm

MAA.rfd

Requirements fundamentals

MAA.rfd.1

Definition of requirements (e.g. product, project, constraints,

system boundary, external, internal, etc.)

MAA.rfd.2

Requirements process

PRO.con.3

MAA.rfd.3

Layers/levels of requirements (e.g. needs, goals, user

MAA.rsd

requirements, system requirements, software requirements, etc.)

MAA.rfd.4

Requirements characteristics (e.g. testable, non-ambiguous,

MAA.af.5

consistent, correct, traceable, priority, etc.)

MAA.rfd.5

Managing changing requirements

MGT.ctl.1

MAA.rfd.6

Requirements management (e.g. consistency management,

CMP.ct.3

release planning, reuse, etc.)

MAA.rfd.7

Interaction between requirements and architecture

MAA.tm.3,DES.ar

.4,EVO.pro.2

MAA.rfd.8

Relationship of requirements to systems engineering, human-

CMP.cf.6

centered design, etc.

MAA.rfd.9

Wicked problems (e.g. ill-structured problems; problems with

PRF.psy.3

many solutions; etc.)

MAA.rfd.10

COTS as a constraint

MAA.er

Eliciting requirements

MAA.er.1

Elicitation Sources (e.g. stakeholders, domain experts,

PRF.psy.4

operational and organization environments, etc.)

MAA.er.2

Elicitation Techniques (e.g. interviews, questionnaires/surveys,

FND.ec.2,MAA.er

.1, PRF.psy.5

prototypes, use cases, observation, participatory techniques,

etc.)

MAA.er.3

Advanced techniques (e.g. ethnographic, knowledge elicitation,

etc.)

MAA.rsd

Requirements specification & documentation

MAA.rsd.1

Requirements documentation basics (e.g. types, audience,

PRF.pr.5

structure, quality, attributes, standards, etc.)

MAA.rsd.2

Software requirements specification

MAA.rsd.3

Specification languages (e.g. structured English, UML, formal

MAA.md.3,CMP.f

m.2

languages such as Z, VDM, SCR, RSML, etc.)

MAA.rv

Requirements validation

MAA.rv.1

Reviews and inspection

VAV.rev

MAA.rv.2

Prototyping to validate requirements (Summative prototyping)

MAA.rv.3

Acceptance test design

VAV.tst.8

MAA.rv.4

Validating product quality attributes

QUA.cc.5

MAA.rv.5

Formal requirements analysis

MAA.af.1

SE2004 Volume 8/23/2004

4.12 Software Design

Description

Software design is concerned with issues, techniques, strategies, representations, and patterns

used to determine how to implement a component or a system. The design will conform to

functional requirements within the constraints imposed by other requirements such as resource,

performance, reliability, and security. This area also includes specification of internal interfaces

among software components, architectural design, data design, user interface design, design

tools, and the evaluation of design.

Units and Topics

Reference

k,c,a E,D,O Hours Related Topics

DES

Software Design

DES.con

Design concepts

DES.con.1

Definition of design

DES.con.2

Fundamental design issues (e.g. persistent data, storage

CMP.ct.6,VAV.tst

.2,CMP.cf.11

management, exceptions, etc.)

DES.con.3

Context of design within multiple software development life cycles

DES.con.4

Design principles (information hiding, cohesion and coupling)

DES.con.5

Interactions between design and requirements

DES.ar.4

DES.con.6

Design for quality attributes (e.g. reliability, usability,

FND.ef.4,MAA.tm

.4,DES.ar.2,CMP.

maintainability, performance, testability, security, fault tolerance,

ct.14,VAV.fnd.4

etc.)

DES.con.7

Design trade-offs

FND.ec.3,DES.ar

.2,DES.ev

DES.con.8

Architectural styles, patterns, reuse

DES.ar,DES.dd.2

,CMP.ct.3

DES.str

Design strategies

DES.str.1

Function-oriented design

DES.str.2

Object-oriented design

CMP.cf.9,DES.dd

.5,CMP.ct.4

DES.str.3

Data-structure centered design

DES.str.4

Aspect oriented design

DES.ar

Architectural design

DES.ar.1

Architectural styles (e.g. pipe-and-filter, layered, transaction-

DES.con.8

centered, peer-to-peer, publish-subscribe, event-based, client-

server, etc.)

DES.ar.2

Architectural trade-offs between various attributes

FND.ec.3

DES.ar.3

Hardware issues in software architecture

CMP.ct.13

DES.ar.4

Requirements traceability in architecture

MAA.af.5,DES.co

n.5,EVO.pro.2

DES.ar.5

Domain-specific architectures and product-lines

DES.ar.6

Architectural notations (e.g. architectural structure viewpoints &

MAA.tm

representations, component diagrams, etc.)

DES.hci

Human computer interface design

12 CMP.cf.7,VAV.hc

t,CMP.ct.2

DES.hci.1

General HCI design principles

DES.hci.2

Use of modes, navigation

DES.hci.3

Coding techniques and visual design (e.g. color, icons, fonts,

SE2004 Volume 8/23/2004

etc.)

DES.hci.4 Response time and feedback

DES.hci.5 Design modalities (e.g. menu-driven, forms, question-answering,

etc.)

DES.hci.6 Localization and internationalization

CMP.ct.8

DES.hci.7 Human computer interface design methods

DES.hci.8 Multi-media (e.g. I/O techniques, voice, natural language, web-

page, sound, etc.)

DES.hci.9 Metaphors and conceptual models

DES.hci.10 Psychology of HCI

PRF.psy.2

DES.dd

Detailed design

DES.dd.1

One selected design method (e.g. SSA/SD, JSD, OOD, etc.)

DES.dd.2

Design patterns

DES.con.8

DES.dd.3

Component design

CMP.ct.11

DES.dd.4

Component and system interface design

CMP.ct.2

DES.dd.5

Design notations (e.g. class and object diagrams, UML, state

MAA.tm

diagrams, etc.)

DES.ste

Design support tools and evaluation

DES.ste.1

Design support tools (e.g. architectural, static analysis, dynamic

CMP.ct

evaluation, etc.)

DES.ste.2

Measures of design attributes (e.g. coupling, cohesion,

information-hiding, separation of concerns, etc.)

DES.ste.3

Design metrics (e.g. architectural factors, interpretation, metric

sets in common use, etc.)

DES.ste.4

Formal design analysis

MAA.af.2

4.13 Software Verification and Validation

Description

Software verification and validation uses both static and dynamic techniques of system checking

to ensure that the resulting program satisfies its specification and that the program as

implemented meets the expectations of the stakeholders. Static techniques are concerned with

the analysis and checking of system representations throughout all stages of the software life

cycle, while dynamic techniques involve only the implemented system.

Units and Topics

Reference

k,c,a E,D,O Hours Related Topics

VAV

Software Verification and Validation

VAV.fnd

V&V terminology and foundations

VAV.fnd.1

Objectives and constraints of V&V

VAV.fnd.2

Planning the V&V effort

VAV.fnd.3

Documenting V&V strategy, including tests and other artifacts

VAV.fnd.4

Metrics & Measurement (e.g. reliability, usability, performance,

FND.ef.4,MAA.af.

2,DES.con.6,CM

etc.)

P.ct.14,PRO.con.

VAV.fnd.5

V&V involvement at different points in the lifecycle

VAV.rev

Reviews

MAA.rv.1

VAV.rev.1

Desk checking

SE2004 Volume 8/23/2004

VAV.rev.2

Walkthroughs

VAV.rev.3

Inspections

VAV.hct.2,3

VAV.tst

Testing

21 MAA.rfd.4,DES.c

on.6,CMP.ct.15

VAV.tst.1

Unit testing

CMP.ct.15,CMP.c

t.3

VAV.tst.2

Exception handling (writing test cases to trigger exception

DES.con.2,CMP.

ct.6

handling; designing good handling)

VAV.tst.3

Coverage analysis and Structure Based Testing (e.g. statement,

branch, basis path, multi--condition, dataflow, etc.)

VAV.tst.4

Black-box functional testing techniques

VAV.tst.5

Integration Testing

VAV.tst.6

Developing test cases based on use cases and/or customer

MAA.tm.2

stories

VAV.tst.7

Operational profile-based testing

VAV.tst.8

System and acceptance testing

MAA.rv.4

VAV.tst.9

Testing across quality attributes (e.g. usability, security,

MAA.af.3,MAA.rv

.6,VAV.hct,QUA.

compatibility, accessibility, etc.)

cc.5

VAV.tst.10

Regression Testing

VAV.tst.11

Testing tools

CMP.ct.3

VAV.tst.12

Deployment process

VAV.hct

Human computer user interface testing and evaluation

DES.hci,VAV.tst.

VAV.hct.1

The variety of aspects of usefulness and usability

MAA.af.3

VAV.hct.2

Heuristic evaluation

VAV.rev.3

VAV.hct.3

Cognitive walkthroughs

VAV.rev.3

VAV.hct.4

User testing approaches (observation sessions etc.)

VAV.hct.5

Web usability; testing techniques for web sites

VAV.hct.6

Formal experiments to test hypotheses about specific HCI

FND.ef.1

controls

VAV.par

Problem analysis and reporting

VAV.par.1

Analyzing failure reports

VAV.par.2

Debugging/fault isolation techniques

VAV.par.3

Defect analysis

VAV.par.4

Problem tracking

4.14 Software Evolution

Description

Software evolution is the result of the ongoing need to support the stakeholders' mission in the

face of changing assumptions, problems, requirements, architectures, and technologies.

Evolution is intrinsic to all real-world software systems. Support for evolution requires

numerous activities both before and after each of a succession of versions or upgrades (releases)

that constitute the evolving system. Evolution is a broad concept that expands upon the

traditional notion of software maintenance.

SE2004 Volume 8/23/2004

Units and Topics

Reference

k,c,a E,D,O Hours Related Topics

EVO

Software Evolution

EVO.pro

Evolution processes

EVO.pro.1

Basic concepts of evolution and maintenance

EVO.pro.2

Relationship between evolving entities (e.g. assumptions,

MAA.af.4,DES.ar.

requirements, architecture, design, code, etc.)

EVO.pro.3

Models of software evolution (e.g. theories, laws, etc.)

EVO.pro.4

Cost models of evolution

FND.ec.3

EVO.pro.5

Planning for evolution (e.g. outsourcing, in-house, etc.)

MGT.pp

EVO.ac

Evolution activities

VAV.par.4,MGT.c

EVO.ac.1

Working with legacy systems (e.g. use of wrappers, etc.)

EVO.ac.2

Program comprehension and reverse engineering

EVO.ac.3

System and process re-engineering (technical and business)

EVO.ac.4

Impact analysis

EVO.ac.5

Migration (technical and business)

EVO.ac.6

Refactoring

EVO.ac.7

Program transformation

EVO.ac.8

Data reverse engineering

4.15 Software Process

Description

Software process is concerned with knowledge about the description of commonly used

software life-cycle process models and the contents of institutional process standards; definition,

implementation, measurement, management, change and improvement of software processes;

and use of a defined process to perform the technical and managerial activities needed for

software development and maintenance.

Units and Topics

Reference

k,c,a E,D,O Hours Related Topics

PRO

Software Process

PRO.con

Process concepts

PRO.con.1 Themes and terminology

PRO.con.2 Software engineering process infrastructure (e.g. personnel,

tools, training, etc.)

PRO.con.3 Modeling and specification of software processes

MAA.rfd.2

PRO.con.4 Measurement and analysis of software processes

MGT.ctl.3

PRO.con.5 Software engineering process improvement (individual, team)

FND.ef.3,PRO.im

p.4,5

PRO.con.6 Quality analysis and control (e.g. defect prevention, review

MAA.rv.1,VAV.re

v,QUA.pda.4

processes, quality metrics, root cause analysis, etc.)

PRO.con.7 Analysis and modeling of software process models

PRO.imp

Process implementation

PRO.imp.1 Levels of process definition (e.g. organization, project, team,

individual, etc.)

PRO.imp.2 Life cycle models (agile, heavyweight, waterfall, spiral, V-Model,

DES.con.3,VAV.f

SE2004 Volume 8/23/2004

etc.)

nd.5

PRO.imp.3 Life cycle process models and standards (e.g., IEEE, ISO, etc.)

PRF.pr.5,QUA.pr

o.2

PRO.imp.4 Individual software process (model, definition, measurement,

PRO.con.5

analysis, improvement)

PRO.imp.5 Team process (model, definition, organization, measurement,

PRO.con.5

analysis, improvement)

PRO.imp.6 Process tailoring

PRO.imp.7 Requirements for software life cycle process (e.g., ISO/IEEE

PRF.pr.5

Standard 12207)

4.16 Software Quality

Description

Software quality is a pervasive concept that affects, and is affected by all aspects of software

development, support, revision, and maintenance. It encompasses the quality of work products

developed and/or modified (both intermediate and deliverable work products) and the quality of

the work processes used to develop and/or modify the work products. Quality work product

attributes include functionality, usability, reliability, safety, security, maintainability, portability,

efficiency, performance, and availability.

Units and Topics

Reference

k,c,a E,D,O Hours Related Topics

QUA

Software Quality

QUA.cc

Software quality concepts and culture

QUA.cc.1

Definitions of quality

QUA.cc.2

Society's concern for quality

QUA.cc.3

The costs and impacts of bad quality

QUA.cc.4

A cost of quality model

MGT.pp.4

QUA.cc.5

Quality attributes for software (e.g. dependability, usability, etc.)

MAA.rva.5,VAV.t

st.9,QUA.pda.5

QUA.cc.6

The dimensions of quality engineering

QUA.cc.7

Roles of people, processes, methods, tools, and technology

QUA.std

Software quality standards

PRF.pr.5

QUA.std.1

The ISO 9000 Quality Management Systems

QUA.std.2

ISO/IEEE Standard 12207 Software Life Cycle Processes

QUA.std.3

Organizational implementation of standards

QUA.std.4

IEEE software quality-related standards

QUA.pro

Software quality processes

QUA.pro.1

Software quality models and metrics

VAV.fnd.4,QUA.p

da.5

QUA.pro.2

Quality-related aspects of software process models

PRO.imp.3

QUA.pro.3

Introduction/overview of ISO 15504 and the SEI CMMs

PRF.pr.5

QUA.pro.4

Quality-related process areas of ISO 15504

PRF.pr.5

QUA.pro.5

Quality-related process areas of the SW-CMM and the CMMIs

QUA.pro.6

The Baldrige Award criteria as applied to software engineering

QUA.pro.7

Quality aspects of other process models

QUA.pca

Process assurance

SE2004 Volume 8/23/2004

QUA.pca.1

The nature of process assurance

QUA.pca.2

Quality planning

MGT.pp

QUA.pca.3

Organizing and reporting for process assurance

QUA.pda.4

Techniques of process assurance

QUA.pda

Product assurance

QUA.pda.1

The nature of product assurance

QUA.pda.2

Distinctions between assurance and V&V

VAV

QUA.pda.3

Quality product models

QUA.pda.4

Root cause analysis and defect prevention

PRO.con.6

QUA.pda.5

Quality product metrics and measurement

VAV.fnd.4,QUA.c

c.5,QUA.pro.1

QUA.pda.6 Assessment of product quality attributes (e.g. useability,

reliability, availability, etc.)

4.17 Software Management

Description

Software management is concerned with knowledge about the planning, organization, and

monitoring of all software life-cycle phases. Management is critical to ensure that software

development projects are appropriate to an organization, work in different organizational units is

coordinated, software versions and configurations are maintained, resources are available when

necessary, project work is divided appropriately, communication is facilitated, and progress is

accurately charted.

Units and Topics

Reference

k,c,a E,D,O Hours Related Topics

MGT

Software Management

MGT.con

Management concepts

MGT.con.1

General project management

MGT.con.2

Classic management models

MGT.con.3

Project management roles

MGT.con.4

Enterprise/Organizational management structure

MGT.con.5

Software management types (e.g. acquisition, project,

FND.ec.4,MGT.p

p.6,EVO

development, maintenance, risk, etc.)

MGT.pp

Project planning

VAV.fnd.2,QUA.p

ca.2

MGT.pp.1

Evaluation and planning

MGT.pp.2

Work breakdown structure

MGT.pp.3

Task scheduling

MGT.pp.4

Effort estimation

FND.ec.3,QUA.cc

MGT.pp.5

Resource allocation

MGT.pp.6

Risk management

FND.ec.4

MGT.per

Project personnel and organization

PRF.com.3

MGT.per.1

Organizational structures, positions, responsibilities, and

PRF.psy.1

authority

MGT.per.2

Formal/informal communication

PRF.com.1,

PRF.com.2,

PRF.com.3

SE2004 Volume 8/23/2004

MGT.per.3

Project staffing

MGT.per.4

Personnel training, career development, and evaluation

MGT.per.5

Meeting management

MGT.per.6

Building and motivating teams

MGT.per.7

Conflict resolution

MGT.ctl

Project control

MGT.ctl.1

Change control

MAA.rfd.5,MGT.c

m.1,2

MGT.ctl.2

Monitoring and reporting

MGT.ctl.3

Measurement and analysis of results

PRO.con.4

MGT.ctl.4

Correction and recovery

MGT.ctl.5

Reward and discipline

MGT.ctl.6

Standards of performance

MGT.cm

Software configuration management

MGT.cm.1

Revision control

MGT.ctl.1

MGT.cm.2

Release management

MGT.ctl.1

MGT.cm.3

Tool support

MGT.cm.4

Builds

MGT.cm.5

Software configuration management processes

MGT.cm.6

Maintenance issues

EVO.ac

MGT.cm.7

Distribution and backup

4.18 Systems and Application Specialties

As part of an undergraduate software engineering education, students should specialize in one or

more areas. Within their specialty, students should learn material well beyond the core material

specified above. They may either specialize in one or more of the ten knowledge areas listed

above, or they may specialize in one or more of the application areas listed below. For each

application area, students should obtain breadth in the related domain knowledge while they are

obtaining a depth of knowledge about the design of a particular system. Students should also

learn about the characteristics of typical products in these areas and how these characteristics

influence a system's design and construction. Each application specialty listed below is

elaborated with a list of related topics that are needed to support the application.

This list of application areas is not intended to be exhaustive but is designed to give guidance to

those developing specialty curricula.

Specialties and Their Related Topics

Reference

SAS

System and Application Specialties

SAS.net

Network-centric systems

SAS.net.1

Knowledge and skills in web-based technology

SAS.net.2

Depth in networking

SAS.net.3

Depth in security

SAS.inf

Information systems and data processing

SAS.inf.1

Depth in databases

SE2004 Volume 8/23/2004

SAS.inf.2

Depth in business administration

SAS.inf.3

Data warehousing

SAS.fin

Financial and e-commerce systems

SAS.fin.1

Accounting

SAS.fin.2

Finance

SAS.fin.3

Depth in security

SAS.sur

Fault tolerant and survivable systems

SAS.sur.1

Knowledge and skills with heterogeneous, distributed systems

SAS.sur.2

Depth in security

SAS.sur.3

Failure analysis and recovery

SAS.sur.4

Intrusion detection

SAS.sec

Highly secure systems

SAS.sec.1

Business issues related to security

SAS.sec.2

Security weaknesses and risks

SAS.sec.3

Cryptography, cryptanalysis, steganography, etc.

SAS.sec.4

Depth in networks

SAS.sfy

Safety critical systems

SAS.sfy.1

Depth in formal methods, proofs of correctness, etc.

SAS.sfy.2

Knowledge of control systems

SAS.sfy.3

Depth in failure modes, effects analysis, and fault tree analysis

SAS.emb

Embedded and real-time systems

SAS.emb.1

Hardware for embedded systems

SAS.emb.2

Language and tools for development

SAS.emb.3

Depth in timing issues

SAS.emb.3

Hardware verification

SAS.bio

Biomedical systems

SAS.bio.1

Biology and related sciences

SAS.bio.2

Related safety critical systems knowledge

SAS.sci

Scientific systems

SAS.sci.1

Depth in related science

SAS.sci.2

Depth in statistics

SAS.sci.3

Visualization and graphics

SAS.tel

Telecommunications systems

SAS.tel.1

Depth in signals, information theory, etc.

SAS.tel.2

Telephony and telecommunications protocols

SAS.av

Avionics and vehicular systems

SAS.av.1

Mechanical engineering concepts

SAS.av.2

Related safety critical systems knowledge

SAS.av.3

Related embedded and real-time systems knowledge

SAS.ind

Industrial process control systems

SAS.ind.1

Control systems

SAS.ind.2

Industrial engineering and other relevant areas of engineering

SAS.ind.3

Related embedded and real-time systems knowledge

SE2004 Volume 8/23/2004

SAS.mm

Multimedia, game and entertainment systems

SAS.mm.1

Visualization, haptics, and graphics

SAS.mm.2

Depth in human computer interface design

SAS.mm.3

Depth in networks

SAS.mob

Systems for small and mobile platforms

SAS.mob.1

Wireless technology

SAS.mob.2

Depth in human computer interfaces for small and mobile platforms

SAS.mob.3

Related embedded and real-time systems knowledge

SAS.mob.4

Related telecommunications systems knowledge

SAS.ab

Agent-based systems

SAS.ab.1

Machine learning

SAS.ab.2

Fuzzy logic

SAS.ab.3

Knowledge engineering

SE2004 Volume 8/23/2004

Table of Contents: