ZeePedia buy college essays online


Software Engineering - II

<<< Previous Overview of Software Engineering Education Knowledge Next >>>
 
img
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
17
img
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
1
Material offered as part of an undergraduate program that falls outside the core is considered to
be elective.
SE2004 Volume ­ 8/23/2004
18
img
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
19
img
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
20
img
Table 1: SEEK Knowledge Areas and Knowledge Units*
KA/KU
Title
hrs
KA/KU
Title
hrs
CMP
Computing Essentials
172
VAV
Software V & V
42
CMP.cf
Computer Science foundations
140
VAV.fnd
V&V terminology and foundations
5
CMP.ct
Construction technologies
20
VAV.rev
Reviews
6
CMP.tl
Construction tools
4
VAV.tst
Testing
21
CMP.fm
Formal construction methods
8
VAV.hct
Human computer UI testing and
6
evaluation
VAV.par
Problem analysis and reporting
4
FND
Mathematical & Engineering Fundamentals
89
EVL
Software Evolution
10
FND.mf
Mathematical foundations
56
EVO.pro
Evolution processes
6
FND.ef
Engineering foundations for software
23
EVO.ac
Evolution activities
4
FND.ec
Engineering economics for software
10
PRF
Professional Practice
35
PRO
Software Process
13
PRF.psy
Group dynamics / psychology
5
PRO.con
Process concepts
3
PRF.com
Communications skills (specific to SE)
10
PRO.imp
Process implementation
10
PRF.pr
Professionalism
20
MAA
Software Modeling & Analysis
53
QUA
Software Quality
16
MAA.md
Modeling foundations
19
QUA.cc
Software quality concepts and
2
culture
MAA.tm
Types of models
12
QUA.std
Software quality standards
2
MAA.af
Analysis fundamentals
6
QUA.pro
Software quality processes
4
MAA.rfd
Requirements fundamentals
3
QUA.pca
Process assurance
4
MAA.er
Eliciting requirements
4
QUA.pda
Product assurance
4
MAA.rsd
Requirements specification & documentation
6
MAA.rv
Requirements validation
3
DES
Software Design
45
MGT
Software Management
19
DES.con
Design concepts
3
MGT.con
Management concepts
2
DES.str
Design strategies
6
MGT.pp
Project planning
6
DES.ar
Architectural design
9
MGT.per
Project personnel and organization
2
DES.hci
Human computer interface design
12
MGT.ctl
Project control
4
DES.dd
Detailed design
12
MGT.cm
Software configuration management
5
DES.ste
Design support tools and evaluation
3
* 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,
a
E
typing, recursion)
CMP.cf.2
Algorithms, Data Structures/Representation (static & dynamic)
a
E
CMP.ct.1,CMP.f
m.5,MAA.cc.1
and Complexity (CCCS AL 1 to AL 5)
SE2004 Volume ­ 8/23/2004
21
img
CMP.cf.3
Problem solving techniques
a
E
CMP.cf.1
CMP.cf.4
Abstraction ­ use and support for (encapsulation, hierarchy, etc)
a
E
MAA.md.1
CMP.cf.5
Computer organization (parts of CCCS AR 1 to AR 5)
c
E
CMP.cf.6
Basic concept of a system
c
E
MAA.rfd.7
CMP.cf.7
Basic user human factors (I/O, error messages, robustness)
c
E
DES.hci
CMP.cf.8
Basic developer human factors (comments, structure, readability)
c
E
CMP.cf.1
CMP.cf.9
Programming language basics (key concepts from CCCS PL1-
a
E
CMP.ct.3,CMP.ct
.4
PL6)
CMP.cf.10
Operating system basics (key concepts from CCCS OS1-OS5)
c
E
CMP.ct.10,CMP.
ct.15
CMP.cf.11
Database basics
c
E
DES.con.2
CMP.cf.12
Network communication basics
c
E
CMP.cf.13
Semantics of programming languages
D
CMP.ct
Construction technologies
20
CMP.ct.1
API design and use
a
E
DES.dd.4
CMP.ct.2
Code reuse and libraries
a
E
CMP.cf.1
CMP.ct.3
Object-oriented run-time issues (e.g. polymorphism, dynamic
a
E
CMP.cf.1,9,DES.
str.2
binding, etc.)
CMP.ct.4
Parameterization and generics
a
E
CMP.cf.1
CMP.ct.5
Assertions, design by contract, defensive programming
a
E
MAA.md.2
CMP.ct.6
Error handling, exception handling, and fault tolerance
a
E
DES.con.2,VAV.t
st.2,VAV.tst.9
CMP.ct.7
State-based and table driven construction techniques
c
E
FND.mf.7,MAA.t
m.2,CMP.cf.10
CMP.ct.8
Run-time configuration and internationalization
a
E
DES.hci.6
CMP.ct.9
Grammar-based input processing (parsing)
a
E
FND.mf.8
CMP.ct.10
Concurrency primitives (e.g. semaphores, monitors, etc.)
a
E
CMP.cf.10
CMP.ct.11
Middleware (components and containers)
c
E
DES.dd.3,5
CMP.ct.12
Construction methods for distributed software
a
E
CMP.cf.2
CMP.ct.13
Constructing heterogeneous (hardware and software) systems;
c
E
DES.ar.3
hardware-software codesign
CMP.ct.14
Performance analysis and tuning
k
E
FND.ef.4,DES.co
n.6,CMP.tl.4,VAV
.fnd.4
CMP.ct.15
Platform standards (Posix etc.)
D
CMP.ct.16
Test-first programming
D
VAV.tst.1
CMP.tl
Construction tools
4
DES.ste.1
CMP.tl.1
Development environments
a
E
CMP.tl.2
GUI builders
c
E
DES.hci
CMP.tl.3
Unit testing tools
c
E
VAV.tst.1
CMP.tl.4
Application oriented languages (e.g. scripting, visual, domain-
c
E
specific, markup, macros, etc.)
CMP.tl.5
Profiling, performance analysis and slicing tools
D
CMP.ct.14
CMP.fm
Formal construction methods
8
DES.dd.9,MAA.af
.6,EVO.ac.7
CMP.fm.1
Application of abstract machines (e.g. SDL, Paisley, etc.)
k
E
CMP.fm.2
Application of specification languages and methods (e.g. ASM,
a
E
MAA.md.3,MAA.r
sd.3
B, CSP, VDM, Z)
CMP.fm.3
Automatic generation of code from a specification
k
E
CMP.fm.4
Program derivation
c
E
CMP.fm.5
Analysis of candidate implementations
c
E
MAA.cf.2
CMP.fm.6
Mapping of a specification to different implementations
k
E
CMP.fm.7
Refinement
c
E
SE2004 Volume ­ 8/23/2004
22
img
CMP.fm.8
Proofs of correctness
D
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
89
Mathematical and Engineering Fundamentals
FND.mf
Mathematical foundations*
56
FND.mf.1
Functions, Relations and Sets (CCCS DS1)
a
E
FND.mf.2
Basic Logic (propositional and predicate) (CCCS DS2)
a
E
MAA.md.2,3
FND.mf.3
Proof Techniques (direct, contradiction, inductive) (CCCS DS3)
a
E
CMP.fm.8
FND.mf.4
Basic Counting (CCCS DS4)
a
E
FND.mf.5
Graphs and Trees (CCCS DS5)
a
E
CMP.cf.2
FND.mf.6
Discrete Probability (CCCS DS6)
a
E
FND.ef.2
FND.mf.7
Finite State Machines, regular expressions
c
E
CMP.ct.7,MAA.t
m.2
FND.mf.8
Grammars
c
E
CMP.ct.9
FND.mf.9
Numerical precision, accuracy and errors
c
E
FND.mf.10
Number Theory
D
FND.mf.11
Algebraic Structures
O
FND.ef
Engineering foundations for software
23
FND.ef.1
Empirical methods and experimental techniques (e.g., computer-
c
E
VAV.fnd.4,VAV.h
ct.6
related measuring techniques for CPU and memory usage)
FND.ef.2
Statistical analysis (including simple hypothesis testing,
a
E
FND.mf.6
estimating, regression, correlation etc.)
FND.ef.3
Measurement and metrics
k
E
PRO.con.5,PRO.i
mp.4
FND.ef.4
Systems development (e.g. security, safety, performance, effects
k
E
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
c
E
FND.ec.3,MAA.af
.1
solutions, feasibility, etc.)
FND.ef.6
Theory of measurement (e.g. criteria for valid measurement)
c
E
O
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
k
E
FND.ec.2
Generating system objectives (e.g. participatory design,
c
E
PRF.psy.4,MAA.
er.2
stakeholder win-win, quality function deployment, prototyping,
SE2004 Volume ­ 8/23/2004
23
img
etc.)
FND.ec.3
Evaluating cost-effective solutions (e.g. benefits realization,
c
E
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,
k
E
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
35
Professional Practice
PRF.psy
Group dynamics / psychology
5
PRF.psy.1
Dynamics of working in teams/groups
a
E
PRF.psy.2
Individual cognition (e.g. limits)
k
E
DES.hci.10
PRF.psy.3
Cognitive problem complexity
k
E
MAA.rfd.8
PRF.psy.4
Interacting with stakeholders
c
E
FND.ec.2
PRF.psy.5
Dealing with uncertainty and ambiguity
k
E
PRF.psy.6
Dealing with multicultural environments
k
E
PRF.com
Communications skills (specific to SE)
10
PRF.com.1
Reading, understanding and summarizing reading (e.g. source
a
E
MAA.rsd.1
code, documentation)
PRF.com.2
Writing (assignments, reports, evaluations, justifications, etc.)
a
E
PRF.com.3
Team and group communication (both oral and written, email,
a
E
MGT.per
etc.)
PRF.com.4
Presentation skills
a
E
PRF.pr
Professionalism
20
PRF.pr.1
Accreditation, certification, and licensing
k
E
PRF.pr.2
Codes of ethics and professional conduct
c
E
PRF.pr.3
Social, legal, historical, and professional issues and concerns
c
E
PRF.pr.4
The nature and role of professional societies
k
E
PRF.pr.5
The nature and role of software engineering standards
k
E
MAA.rsd.1,CMP.c
t.14,PRO.imp.3,7,
QUA.std
PRF.pr.6
The economic impact of software
c
E
FND.ec
PRF.pr.7
Employment contracts
k
E
SE2004 Volume ­ 8/23/2004
24
img
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
53
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,
a
E
CMP.cf.4
generalization, projection/views, explicitness, use of formal
approaches, etc.)
MAA.md.2
Pre & post conditions, invariants
c
E
CMP.ct.5
MAA.md.3
Introduction to mathematical models and specification languages
c
E
MAA.rsd.3,CMP.f
m.2
(Z, VDM, etc.)
MAA.md.4
Properties of modeling languages
k
E
MAA.md.5
Syntax vs. semantics (understanding model representations)
c
E
CMP.cf.9
MAA.md.6
Explicitness (make no assumptions, or state all assumptions)
k
E
MAA.tm
Types of models
12 MAA.md
MAA.tm.1
Information modeling (e.g. entity-relationship modeling, class
a
E
MAA.rsd.3,DES.d
d.5
diagrams, etc.)
MAA.tm.2
Behavioral modeling (e.g. structured analysis, state diagrams,
a
E
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.)
c
E
MAA.rfd.7
MAA.tm.4
Domain modeling (e.g. domain engineering approaches, etc.)
k
E
MAA.tm.5
Functional modeling (e.g. component diagrams, etc.)
c
E
MAA.tm.6
Enterprise modeling  (e.g. business processes, organizations,
D
goals, etc.)
MAA.tm.7
Modeling embedded systems (e.g. real-time schedulability
D
analysis, external interface analysis, etc.)
MAA.tm.8
Requirements interaction analysis (e.g. feature interaction, house
D
of quality, viewpoint analysis, etc.)
MAA.tm.9
Analysis Patterns (e.g. problem frames, specification re-use, etc.)
D
MAA.af
Analysis fundamentals
6
MAA.af.1
Analyzing well-formedness (e.g. completeness, consistency,
a
E
robustness, etc.)
MAA.af.2
Analyzing correctness (e.g. static analysis, simulation, model
a
E
checking, etc.)
MAA.af.3
Analyzing quality (non-functional) requirements (e.g. safety,
a
E
FND.ef.4,QUA.pd
a,DES.con.6,VAV
security, usability, performance, root cause analysis, etc.)
SE2004 Volume ­ 8/23/2004
25
img
.fnd.4,VAV.tst.9,V
AV.hct,EVO.ac.4
MAA.af.4
Prioritization, trade-off analysis, risk analysis, and impact
c
E
FND.ec.3,4,QUA.
pda.4
analysis
MAA.af.5
Traceability
c
E
DES.ar.4,EVO.pr
o.2
MAA.af.6
Formal analysis
k
E
CMP.fm
MAA.rfd
Requirements fundamentals
3
MAA.rfd.1
Definition of requirements (e.g. product, project, constraints,
c
E
system boundary, external, internal, etc.)
MAA.rfd.2
Requirements process
c
E
PRO.con.3
MAA.rfd.3
Layers/levels of requirements (e.g. needs, goals, user
c
E
MAA.rsd
requirements, system requirements, software requirements, etc.)
MAA.rfd.4
Requirements characteristics (e.g. testable, non-ambiguous,
c
E
MAA.af.5
consistent, correct, traceable, priority, etc.)
MAA.rfd.5
Managing changing requirements
c
E
MGT.ctl.1
MAA.rfd.6
Requirements management (e.g. consistency management,
k
E
CMP.ct.3
release planning, reuse, etc.)
MAA.rfd.7
Interaction between requirements and architecture
k
E
MAA.tm.3,DES.ar
.4,EVO.pro.2
MAA.rfd.8
Relationship of requirements to systems engineering, human-
D
CMP.cf.6
centered design, etc.
MAA.rfd.9
Wicked problems (e.g. ill-structured problems; problems with
D
PRF.psy.3
many solutions; etc.)
MAA.rfd.10
COTS as a constraint
D
MAA.er
Eliciting requirements
4
MAA.er.1
Elicitation Sources (e.g. stakeholders, domain experts,
c
E
PRF.psy.4
operational and organization environments, etc.)
MAA.er.2
Elicitation Techniques (e.g. interviews, questionnaires/surveys,
c
E
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,
O
etc.)
MAA.rsd
Requirements specification & documentation
6
MAA.rsd.1
Requirements documentation basics (e.g. types, audience,
k
E
PRF.pr.5
structure, quality, attributes, standards, etc.)
MAA.rsd.2
Software requirements specification
a
E
MAA.rsd.3
Specification languages (e.g. structured English, UML, formal
k
E
MAA.md.3,CMP.f
m.2
languages such as Z, VDM, SCR, RSML, etc.)
MAA.rv
Requirements validation
3
MAA.rv.1
Reviews and inspection
a
E
VAV.rev
MAA.rv.2
Prototyping to validate requirements (Summative prototyping)
k
E
MAA.rv.3
Acceptance test design
c
E
VAV.tst.8
MAA.rv.4
Validating product quality attributes
c
E
QUA.cc.5
MAA.rv.5
Formal requirements analysis
D
MAA.af.1
SE2004 Volume ­ 8/23/2004
26
img
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
45
Software Design
DES.con
Design concepts
3
DES.con.1
Definition of design
c
E
DES.con.2
Fundamental design issues (e.g. persistent data, storage
c
E
CMP.ct.6,VAV.tst
.2,CMP.cf.11
management, exceptions, etc.)
DES.con.3
Context of design within multiple software development life cycles
k
E
DES.con.4
Design principles (information hiding, cohesion and coupling)
a
E
DES.con.5
Interactions between design and requirements
c
E
DES.ar.4
DES.con.6
Design for quality attributes (e.g. reliability, usability,
k
E
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
k
E
FND.ec.3,DES.ar
.2,DES.ev
DES.con.8
Architectural styles, patterns, reuse
c
E
DES.ar,DES.dd.2
,CMP.ct.3
DES.str
Design strategies
6
DES.str.1
Function-oriented design
ac
E
DES.str.2
Object-oriented design
ca
E
CMP.cf.9,DES.dd
.5,CMP.ct.4
DES.str.3
Data-structure centered design
D
DES.str.4
Aspect oriented design
O
DES.ar
Architectural design
9
DES.ar.1
Architectural styles (e.g. pipe-and-filter, layered, transaction-
a
E
DES.con.8
centered, peer-to-peer, publish-subscribe, event-based, client-
server, etc.)
DES.ar.2
Architectural trade-offs between various attributes
a
E
FND.ec.3
DES.ar.3
Hardware issues in software architecture
k
E
CMP.ct.13
DES.ar.4
Requirements traceability in architecture
k
E
MAA.af.5,DES.co
n.5,EVO.pro.2
DES.ar.5
Domain-specific architectures and product-lines
k
E
DES.ar.6
Architectural notations (e.g. architectural structure viewpoints &
c
E
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
a
E
DES.hci.2
Use of modes, navigation
a
E
DES.hci.3
Coding techniques and visual design (e.g. color, icons, fonts,
c
E
SE2004 Volume ­ 8/23/2004
27
img
etc.)
DES.hci.4  Response time and feedback
a
E
DES.hci.5  Design modalities (e.g. menu-driven, forms, question-answering,
a
E
etc.)
DES.hci.6  Localization and internationalization
c
E
CMP.ct.8
DES.hci.7  Human computer interface design methods
c
E
DES.hci.8  Multi-media (e.g. I/O techniques, voice, natural language, web-
D
page, sound, etc.)
DES.hci.9  Metaphors and conceptual models
D
DES.hci.10 Psychology of HCI
D
PRF.psy.2
DES.dd
Detailed design
12
DES.dd.1
One selected design method (e.g. SSA/SD, JSD, OOD, etc.)
a
E
DES.dd.2
Design patterns
a
E
DES.con.8
DES.dd.3
Component design
a
E
CMP.ct.11
DES.dd.4
Component and system interface design
a
E
CMP.ct.2
DES.dd.5
Design notations (e.g. class and object diagrams, UML, state
c
E
MAA.tm
diagrams, etc.)
DES.ste
Design support tools and evaluation
3
DES.ste.1
Design support tools (e.g. architectural, static analysis, dynamic
a
E
CMP.ct
evaluation, etc.)
DES.ste.2
Measures of design attributes (e.g. coupling, cohesion,
k
E
information-hiding, separation of concerns, etc.)
DES.ste.3
Design metrics (e.g. architectural factors, interpretation, metric
a
E
sets in common use, etc.)
DES.ste.4
Formal design analysis
O
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
42
Software Verification and Validation
VAV.fnd
V&V terminology and foundations
5
VAV.fnd.1
Objectives and constraints of V&V
k
E
VAV.fnd.2
Planning the V&V effort
k
E
VAV.fnd.3
Documenting V&V strategy, including tests and other artifacts
a
E
VAV.fnd.4
Metrics & Measurement (e.g. reliability, usability, performance,
k
E
FND.ef.4,MAA.af.
2,DES.con.6,CM
etc.)
P.ct.14,PRO.con.
4
VAV.fnd.5
V&V involvement at different points in the lifecycle
k
E
VAV.rev
Reviews
6
MAA.rv.1
VAV.rev.1
Desk checking
a
E
SE2004 Volume ­ 8/23/2004
28
img
VAV.rev.2
Walkthroughs
a
E
VAV.rev.3
Inspections
a
E
VAV.hct.2,3
VAV.tst
Testing
21 MAA.rfd.4,DES.c
on.6,CMP.ct.15
VAV.tst.1
Unit testing
a
E
CMP.ct.15,CMP.c
t.3
VAV.tst.2
Exception handling (writing test cases to trigger exception
a
E
DES.con.2,CMP.
ct.6
handling; designing good handling)
VAV.tst.3
Coverage analysis and Structure Based Testing (e.g. statement,
a
E
branch, basis path, multi--condition, dataflow, etc.)
VAV.tst.4
Black-box functional testing techniques
a
E
VAV.tst.5
Integration Testing
c
E
VAV.tst.6
Developing test cases based on use cases and/or customer
a
E
MAA.tm.2
stories
VAV.tst.7
Operational profile-based testing
k
E
VAV.tst.8
System and acceptance testing
a
E
MAA.rv.4
VAV.tst.9
Testing across quality attributes (e.g. usability, security,
a
E
MAA.af.3,MAA.rv
.6,VAV.hct,QUA.
compatibility, accessibility, etc.)
cc.5
VAV.tst.10
Regression Testing
c
E
VAV.tst.11
Testing tools
a
E
CMP.ct.3
VAV.tst.12
Deployment process
D
VAV.hct
Human computer user interface testing and evaluation
6
DES.hci,VAV.tst.
9
VAV.hct.1
The variety of aspects of usefulness and usability
k
E
MAA.af.3
VAV.hct.2
Heuristic evaluation
a
E
VAV.rev.3
VAV.hct.3
Cognitive walkthroughs
c
E
VAV.rev.3
VAV.hct.4
User testing approaches (observation sessions etc.)
a
E
VAV.hct.5
Web usability; testing techniques for web sites
c
E
VAV.hct.6
Formal experiments to test hypotheses about specific HCI
D
FND.ef.1
controls
VAV.par
Problem analysis and reporting
4
VAV.par.1
Analyzing failure reports
c
E
VAV.par.2
Debugging/fault isolation techniques
a
E
VAV.par.3
Defect analysis
k
E
VAV.par.4
Problem tracking
c
E
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
29
img
Units and Topics
Reference
k,c,a E,D,O Hours Related Topics
EVO
10
Software Evolution
EVO.pro
Evolution processes
6
EVO.pro.1
Basic concepts of evolution and maintenance
k
E
EVO.pro.2
Relationship between evolving entities (e.g. assumptions,
k
E
MAA.af.4,DES.ar.
4
requirements, architecture, design, code, etc.)
EVO.pro.3
Models of software evolution (e.g. theories, laws, etc.)
k
E
EVO.pro.4
Cost models of evolution
D
FND.ec.3
EVO.pro.5
Planning for evolution (e.g. outsourcing, in-house, etc.)
D
MGT.pp
EVO.ac
Evolution activities
4
VAV.par.4,MGT.c
m
EVO.ac.1
Working with legacy systems (e.g. use of wrappers, etc.)
k
E
EVO.ac.2
Program comprehension and reverse engineering
k
E
EVO.ac.3
System and process re-engineering (technical and business)
k
E
EVO.ac.4
Impact analysis
k
E
EVO.ac.5
Migration (technical and business)
k
E
EVO.ac.6
Refactoring
k
E
EVO.ac.7
Program transformation
D
EVO.ac.8
Data reverse engineering
D
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
13
Software Process
PRO.con
Process concepts
3
PRO.con.1 Themes and terminology
k
E
PRO.con.2 Software engineering process infrastructure (e.g. personnel,
k
E
tools, training, etc.)
PRO.con.3 Modeling and specification of software processes
c
E
MAA.rfd.2
PRO.con.4 Measurement and analysis of software processes
c
E
MGT.ctl.3
PRO.con.5 Software engineering process improvement (individual, team)
c
E
FND.ef.3,PRO.im
p.4,5
PRO.con.6 Quality analysis and control (e.g. defect prevention, review
c
E
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
D
PRO.imp
Process implementation
10
PRO.imp.1 Levels of process definition (e.g. organization, project, team,
k
E
individual, etc.)
PRO.imp.2 Life cycle models (agile, heavyweight, waterfall, spiral, V-Model,
c
E
DES.con.3,VAV.f
SE2004 Volume ­ 8/23/2004
30
img
etc.)
nd.5
PRO.imp.3 Life cycle process models and standards (e.g., IEEE, ISO, etc.)
c
E
PRF.pr.5,QUA.pr
o.2
PRO.imp.4 Individual software process (model, definition, measurement,
c
E
PRO.con.5
analysis, improvement)
PRO.imp.5 Team process (model, definition, organization, measurement,
c
E
PRO.con.5
analysis, improvement)
PRO.imp.6 Process tailoring
k
E
PRO.imp.7 Requirements for software life cycle process (e.g., ISO/IEEE
k
E
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
16
Software Quality
QUA.cc
Software quality concepts and culture
2
QUA.cc.1
Definitions of quality
k
E
QUA.cc.2
Society's concern for quality
k
E
QUA.cc.3
The costs and impacts of bad quality
k
E
QUA.cc.4
A cost of quality model
c
E
MGT.pp.4
QUA.cc.5
Quality attributes for software (e.g. dependability, usability, etc.)
k
E
MAA.rva.5,VAV.t
st.9,QUA.pda.5
QUA.cc.6
The dimensions of quality engineering
k
E
QUA.cc.7
Roles of people, processes, methods, tools, and technology
k
E
QUA.std
Software quality standards
2
PRF.pr.5
QUA.std.1
The ISO 9000 Quality Management Systems
k
E
QUA.std.2
ISO/IEEE Standard 12207 Software Life Cycle Processes
k
E
QUA.std.3
Organizational implementation of standards
k
E
QUA.std.4
IEEE software quality-related standards
D
QUA.pro
Software quality processes
4
QUA.pro.1
Software quality models and metrics
c
E
VAV.fnd.4,QUA.p
da.5
QUA.pro.2
Quality-related aspects of software process models
k
E
PRO.imp.3
QUA.pro.3
Introduction/overview of ISO 15504 and the SEI CMMs
k
E
PRF.pr.5
QUA.pro.4
Quality-related process areas of ISO 15504
k
E
PRF.pr.5
QUA.pro.5
Quality-related process areas of the SW-CMM and the CMMIs
k
E
QUA.pro.6
The Baldrige Award criteria as applied to software engineering
O
QUA.pro.7
Quality aspects of other process models
O
QUA.pca
Process assurance
4
SE2004 Volume ­ 8/23/2004
31
img
QUA.pca.1
The nature of process assurance
k
E
QUA.pca.2
Quality planning
a
E
MGT.pp
QUA.pca.3
Organizing and reporting for process assurance
a
E
QUA.pda.4
Techniques of process assurance
c
E
QUA.pda
Product assurance
4
QUA.pda.1
The nature of product assurance
k
E
QUA.pda.2
Distinctions between assurance and V&V
k
E
VAV
QUA.pda.3
Quality product models
k
E
QUA.pda.4
Root cause analysis and defect prevention
c
E
PRO.con.6
QUA.pda.5
Quality product metrics and measurement
c
E
VAV.fnd.4,QUA.c
c.5,QUA.pro.1
QUA.pda.6 Assessment of product quality attributes (e.g. useability,
c
E
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
19
Software Management
MGT.con
Management concepts
2
MGT.con.1
General project management
k
E
MGT.con.2
Classic management models
k
E
MGT.con.3
Project management roles
k
E
MGT.con.4
Enterprise/Organizational management structure
k
E
MGT.con.5
Software management types (e.g. acquisition, project,
k
E
FND.ec.4,MGT.p
p.6,EVO
development, maintenance, risk, etc.)
MGT.pp
Project planning
6
VAV.fnd.2,QUA.p
ca.2
MGT.pp.1
Evaluation and planning
c
E
MGT.pp.2
Work breakdown structure
a
E
MGT.pp.3
Task scheduling
a
E
MGT.pp.4
Effort estimation
a
E
FND.ec.3,QUA.cc
.4
MGT.pp.5
Resource allocation
c
E
MGT.pp.6
Risk management
a
E
FND.ec.4
MGT.per
Project personnel and organization
2
PRF.com.3
MGT.per.1
Organizational structures, positions, responsibilities, and
k
E
PRF.psy.1
authority
MGT.per.2
Formal/informal communication
k
E
PRF.com.1,
PRF.com.2,
PRF.com.3
SE2004 Volume ­ 8/23/2004
32
img
MGT.per.3
Project staffing
k
E
MGT.per.4
Personnel training, career development, and evaluation
k
E
MGT.per.5
Meeting management
a
E
MGT.per.6
Building and motivating teams
a
E
MGT.per.7
Conflict resolution
a
E
MGT.ctl
Project control
4
MGT.ctl.1
Change control
k
E
MAA.rfd.5,MGT.c
m.1,2
MGT.ctl.2
Monitoring and reporting
c
E
MGT.ctl.3
Measurement and analysis of results
c
E
PRO.con.4
MGT.ctl.4
Correction and recovery
k
E
MGT.ctl.5
Reward and discipline
O
MGT.ctl.6
Standards of performance
O
MGT.cm
Software configuration management
5
MGT.cm.1
Revision control
a
E
MGT.ctl.1
MGT.cm.2
Release management
c
E
MGT.ctl.1
MGT.cm.3
Tool support
c
E
MGT.cm.4
Builds
c
E
MGT.cm.5
Software configuration management processes
k
E
MGT.cm.6
Maintenance issues
k
E
EVO.ac
MGT.cm.7
Distribution and backup
D
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
33
img
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
34
img
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
35