See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228556143

Systems Engineering Standards And Models Compared

Article  in  INCOSE International Symposium · July 1998

DOI: 10.1002/j.2334-5837.1998.tb00086.x

CITATIONS READS
57 7,247

3 authors, including:

Sarah Sheard
Carnegie Mellon University
78 PUBLICATIONS   1,028 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Online Career Mentoring Program View project

All content following this page was uploaded by Sarah Sheard on 29 October 2017.

The user has requested enhancement of the downloaded file.

 591

Systems Engineering Standards and Models

Compared
Sarah A. Sheard Dr. Jerome (Jerry) G. Lake
Software Productivity Consortium Systems Management international
2214 Rock Hill Road, Herndon, VA 20170 281 So. Pickett Street #401
(703) 742-7106; fax: (703) 742-7200 Alexandria, VA 22304
sheard@software.org (703) 751-7987; fax: (703) 751-5189
lakejg@mindspring.com

MIL-STD-499B, EIA/IS 632, IEEE 12201. In

Abstract. Currently there are five systems engineering
May of 1992, a “Coordination Copy” of the proposed
standards in various stages of release and three systems
engineering capability models. This makes it difficult MIL-STD 499B SW-CMM
to know what to use as a basis for process improve- 1992 Draft
ISO
ment. This paper discusses the similarities and differ- EIA/IS 632 15504*
1994 IEEE 1220-1994
ences among the standards and models. The standards Trial Use (SPICE)
have been evolving from the U.S. Military to interna- IPD-
tional and commercial, with recent standards taking a CMM*
broader scope. Two capability maturity models have SECAM SE-CMM
IEEE (1.5) 1996 (1.1) 1995
been merged into a third, which is tied to the stan- EIA 632* 1220*
1998? 1998? SSE-
dards. CMM
SECM
INTRODUCTION EIA/IS 731
ISO/IEC 15288* 1998? * Not Yet Released
In the last 5 years, five systems engineering stan- 2000? Derived From
Influenced By
dards and three systems engineering capability models
have been published or begun. It is difficult for a sys- Figure 1. SE Standards and Models History
tems engineering practitioner to stay current with the
various models, understanding what is current, how it MIL-STD-499B [MIL-STD-499B 1992] was distrib-
differs from others, and when and why each version uted to reviewers. This would have updated and sig-
ought to be used. A 1997 INCOSE symposium tutorial nificantly rewritten MIL-STD-499A, Engineering
included a module that addressed the similarities and Management, and the name would have become Sys-
differences [Sheard 1997a]. This paper updates that tems Engineering. However, industry lacked consensus
material. about what ought to be included in a standard on sys-
HISTORY tems engineering, which delayed approval, and there
was a change of administrations in the Pentagon.
The Frameworks Quagmire [Sheard 1997b] ex- In June 1994, a Department of Defense initiative
cerpt shown in Figure 1 clearly indicates that confu- decreed the end of military standards other than per-
sion over systems engineering (SE) standards and formance specifications, thereby guaranteeing that
models is likely. Various standards and models have MIL-STD-499B would never be released as such. At
been released that build on each other and on other the request of a new Director for Systems Engineering
available standards and models, particularly those in within the Office of Secretary for Defense (OSD), an
the software world. Some have been heavily publicized
but not released (MIL-STD-499B and more recently,
EIA 632) and others have been less well known but 1
The released version of IEEE 1220 is also referred to as
released and endorsed by INCOSE (such as [SECAM IEEE 1220-1994. This is a “Trial-Use” standard. This is
1996]). being updated in 1998, with the most recent version re-
ferred to as IEEE P1220 (R) D1.1, 27 January 1998. These
two standards are expected to be very similar. They are
treated as one standard, called IEEE 1220, for the purpose
of this paper.

Electronic Industries Alliance (EIA)2 working group
composed of representatives from the Aircraft Industry
Association, Department of Defense, National Security
Industries Association, EIA, Institute of Electrical and
Electronics Engineers (IEEE), and INCOSE released
in December 1994 a “commercialized” version of MIL-
STD-499B as EIA Interim Standard (IS) 632, [EIA/IS
632 1994]. This was done with the understanding that
considerably more industry input would go into a re-
placement version, to be called EIA 632. In parallel,
the IEEE also released in February 1995 a commercial
“Trial-Use” standard IEEE 1220-1994 [IEEE 1220-
1994 1995]. IEEE 1220-1994 states that it will be
merged with EIA/IS 632 into a single American Na-
tional Standards Institute (ANSI) standard on systems
engineering to be jointly published by the EIA, IEEE,
and INCOSE.3
EIA 632 and ISO 15288. A ballot version of the new
EIA 632 was made available to reviewers in August
1997. Comments were submitted, and the EIA Techni-
cal Committee is expected to complete the work on the
revision with the expectation of a summer 1998 publi-
cation. One of the intents of the revision is to use EIA
632 as an early U.S. implementation of processes for
engineering a system that are expected to be covered in
the evolving ISO standard 15288. [Martin 1998a] and
[Martin 1998b] describe the new standard and how it
has evolved from the interim standard.
The ISO standard for system life cycle processes,
ISO 152884, is being coordinated by the same interna-
tional committee that created the software life cycle
processes standard, ISO 12207. Working Draft #2 was
released for national body review in January 1998. A
first committee draft is anticipated as early as October
1998 with publication of the International Standard as
early as December 1999.
SECAM. INCOSE sponsored a working group that
began in 1992 to address the assessment of systems
engineering capability. This Capability Assessment
Working Group (CAWG) delivered several incre-
mental products. The most recent Version 1.5 of the
Systems Engineering Capability Assessment Model
[SECAM 1996] was released in July of 1996. Several
large corporations have found this model helpful in
improving their systems engineering work.
2
The EIA and the Institute of Electrical and Electronics
Engineers (IEEE ) are two bodies approved to set stan-
dards by the United States’ official standards-setting body,
the American National Standards Institute (ANSI).
3
See Table 1 for a discussion of the outcome of this.
4
Officially, ISO/IEC 15288.
592
SE-CMM. Meanwhile, in December 1993, a group
spun off from the INCOSE SECAM working group.
This group included eight organizations who agreed to
provide full-time authors for a systems engineering
capability maturity model [SE-CMM 1995] to be re-
leased in one year’s time.
This group, later called EPIC (for Enterprise Proc-
ess Improvement Collaboration), used the Software
Engineering Institute (SEI) of Carnegie Mellon Uni-
versity for project management and administrative
support. Thus, EPIC products were released as SEI
documents. Version 1.0 of the SE-CMM was released
in December 1994, and an associated appraisal method
was released in March 1995. Version 1.1 of both were
released in February and June 1996, respectively.
Unfortunately, this meant there were now two
systems engineering models on the market. On the one
hand, the SE-CMM had the SEI’s Software CMM
[SW-CMM 1993] legacy in its favor. Other organiza-
tions took an opposite approach: some INCOSE mem-
bers believed that anyone with a first name of “Soft-
ware” should not be speaking for systems engineering.
To say there was disagreement in the field is an under-
statement.
SECM (EIA/IS 731). INCOSE’s Corporate Advisory
Board, and the Director for Systems Engineering in
OSD, agreed that the two models had to come together.
EPIC and INCOSE agreed to work toward a merged
model, eventually called the Systems Engineering Ca-
pability Model, and given the number EIA/IS 731,
since the EIA sponsored and facilitated the merger
effort. Monthly meetings took place over a period of
years, and the initial review copy of the SECM was
distributed at the 1997 INCOSE symposium.
There is considerable overlap among the models’
contents, so the technical merging of the two models
turned out to be considerably easier than determining
sponsorship, requirements, and the best architecture.
In 1998, a new initiative was undertaken by a new
organization formed by the Director of Systems Engi-
neering in OSD. The group formed of industry and
government representatives is looking at the common
aspects of all the capability models, including Inte-
grated Product Development, Software, and Systems
Engineering. The outcome of this group’s effort will
have an impact on current models.
SIMILARITIES AND DIFFERENCES
The following sections address first, what are the
similarities and differences between standards and ca-
pability models in general, then, what are the similari-
ties and differences among the five systems engineer-
 593

ing standards and then, the three systems engineering
capability models.
Standard vs. Capability Model. Standards and Capa-
bility models both describe good systems engineering,
but do so somewhat differently. While standards must
go through a defined industry-approval process, in
order to meet a nation’s guidelines, such as those es-
tablished by ANSI, capability models can be created by
anyone with the resources. Other comparisons are
shown below.
What, not How. Both standards and capability models
say what should be done, but try not to say how to do
it. However, some interpret a “what” as a “how.” Often
it is a matter of perspective. Recent standards and ca-
pability models have both attempted to avoid the prob-
lem by focusing on processes and their related activi-
ties and tasks or requirements (the “whats”), not on
methods and tools (the “hows”).
Purpose. Capability models provide a way to evaluate
an enterprise’s or project’s systems engineering capa-
bility. They provide a multi-point scale, in each of
these cases containing six levels, showing a road map
along which an organization’s process improvement
effort can progress.
U.S. military standards originally supported con-
tracts, to aid the government in delivery of quality
products or to ensure utilization of consistent processes
by contractors. In general, commercial standards are
not imposed on contracts. In the case of commercial
speaking is a customer (an acquisition life cycle), a
contractor (a development life cycle), or even a user (a
maintenance life cycle) [Lake 1997].
Given these variations, it is probably a good thing
that the capability models are meant to be used with
any life cycle. However, it is probably also a good thing
that standards define the life cycles they are assuming.
Otherwise, the “things to do” are without a context.
Number of Elements. Most standards have fewer than
ten process elements, but the systems engineering ca-
pability models have 18 or 19. MIL-STD-499B and
(EIA/IS 632) show four interrelated process steps, in-
cluding Requirements Analysis, Functional Analysis,
and Synthesis, all tied to System Analysis and Control
(Balance). This last step includes processes such as
trade studies, interface and risk management, and
configuration and data management.
IEEE 1220 separates Analysis, which is tied to all
other process steps, from Control, which it considers to
be one of the process steps. EIA 632 (see Figure 2,
from the January 1998 version) discusses not one
“Systems Engineering Process,” but thirteen processes,
in five interrelated groupings: Acquisition and Supply
(two processes), Technical Management (three proc-
esses), System Design (two processes), Product Reali-
zation (two processes), and Technical Support (four
processes). These processes are intended to be imple-
mented by a single developer during any phase of a
system’s life cycle, as applicable.
Technical Management

systems engineering standards (EIA 632 or IEEE Planning

Process
Assessment
Process
Control
Process
1220), use by an enterprise is ordinarily voluntary, as Plans
Status
Plans
Products Outcomes
is imposing a standard on a supplier as a basis for Agreement Directives

Acquisition System Product

competition or performance. Capability models theo- & Supply Design Realization
Acquisition

Requirements
Request

Implementation

Products
retically are also voluntary, though certainly with the Supply

System
Definition Process
Process Process
SW-CMM it is evident that the practices called out by Acquisition
Solution Transition
Definition To Use
a capability model have been imposed. U.S. govern- Process Process Process

ment contracting for software has in some cases im- Outcomes

posed a requirement that contractors demonstrate a Technical Support

System
minimum of Level 2 or Level 3 ranking in the SW- Analysis
Requirements
Validation
Product
Verification
Product
Validation
Process Process Process Process
CMM.
Life Cycle. Standards may prescribe a life cycle (al- Figure 2. The Processes of EIA 632
though most specify theirs as “typical” or “example”
life cycles). In general, models do not. They are in- Like EIA 632, the capability models separate out
tended to apply to any system life cycle. A discussion the pieces of System Analysis and Control as process
on the INCOSE list server about life cycles led to two elements, and place Control in a “project” or “man-
observations: 1) that many people are sure that they agement” category (see Table 1). Capability models
know the one correct life cycle, and 2) that these peo- also add a third set of elements, those which establish
ple differ on what that life cycle is. It varies not only by organizational support for systems engineering, such
industry (those making nuclear submarines naturally as training, process management, and tool support.
have a different time-based life cycle than those mak- These are included in the Application Context clause
ing cellular telephones), but also by whether the person of EIA 632.
 594

Table 1. Comparison of Process, Focus, and Key Focus Areas in the Three SE Capability Models
SE-CMM (PAs) SECM(EIA/IS 731) (FAs) SECAM (KFAs)
Engineering, Technical, or Systems Engineering Areas
PA06 Understand Customer Needs and 1.1 Define Stakeholder and System 3.1 System Concept Definition
Expectations Level Requirements
PA02 Derive and Allocate Requirements 1.2 Define Technical Requirements 3.2 Requirements and Functional
Analysis
PA03 Evolve System Architecture 1.3 Define Solution 3.3 System Design
PA01 Analyze Candidate Solutions 1.4 Assess and Select 3.4 Integrated Engineering Analysis
PA05 Integrate System 1.5 Integrate System 3.5 System Integration
PA07 Verify and Validate System 1.6 Verify System 3.6 System Verification
1.7 Validate System 3.7 System Validation
PA04 Integrate Disciplines (see 2.3 below) (see 1.4 below)
Project or Management Areas
PA12 Plan Technical Effort 2.1 Plan and Organize 1.1 Planning
PA11 Monitor and Control Technical 2.2 Monitor and Control 1.2 Tracking and Oversight
Effort
(PA04 above) 2.3 Integrate Disciplines 1.4 Intergroup Coordination
(PA18 below) 2.4 Coordinate with Suppliers 1.3 Subcontract Management
PA10 Manage Risk 2.5 Manage Risk 1.7 Risk Management
(none) 2.6 Manage Data 1.8 Data Management
PA09 Manage Configurations 2.7 Manage Configurations 1.5 Configuration Management
PA08 Ensure Quality 2.8 Ensure Quality 1.6 Quality Management
Organization or Environment Areas
PA13 Define Organization’s SE Proc- 3.1 Define and Improve the Systems 2.1 Process Management and Im-
ess Engineering Process provement
PA14 Improve Organization’s SE Proc-
ess
PA17 Provide Ongoing Knowledge and 3.2 Manage Competency 2.2 Competency Development
Skills
PA15 Manage Product Line Evolution 3.3 Manage Technology 2.3 Technology Management
PA16 Manage Systems Engineering 3.4 Manage Systems Engineering Sup- 2.4 Environment and Tool Support
Support Environment port Environment
PA18 Coordinate With Suppliers (see 2.4 above) (see 1.3 above)

Is EIA/IS 731 a standard or a model? In EIA/IS 731, Table 2. SE Standards Commonalities

the distinction between standards and models blurs.
This is the SECM, a capability model that has been
submitted as a standard. Fortunately, it is a model
heavily tied to the existing standards, notably EIA 632,
but also IEEE 1220. Thus, the release of EIA 632 and
EIA/IS 731 is the first time two consistent standards
have been in operation, one for “What to do in engi-
neering systems” (632) and one for “How to measure
and improve your systems engineering capability”
(731).
Similarities and differences among SE standards.
The similarities among standards are summarized in
Table 2, the differences in Table 3.
What is a systems engineering standard? Some
authors of EIA 632 and ISO 15288 do not consider
these to be “systems engineering standards” at all.
Neither one uses the term “systems engineering.”
Common Authors:
John Kordik (1,2) Blake Andrews (7,8)
Ken Ptack (3a,5) Don Barber (7,8)
Richard Schmidt (3a,3b,5) Curt Wells (6,8)
Jerry Lake (1,2,3a,3b,4,5) Rich Widman (7,8)
Jim Armstrong (3a), (3b), (8)
(1) MIL-STD-499B, (2) EIA/IS 632,
(3a) IEEE 1220-1994, (3b) IEEE 1220, (4) EIA632,
(5) ISO 15288, (6) SE-CMM, (7) SECAM, (8) SECM
History: Figure 1 illustrates the interrelationships of the stan-
dards. Standards and capability models have been influenced
by prior ones.
Evolution: The systems engineering standards have evolved
from a military-contract-centric approach to a commercial,
voluntary-compliance approach. The focus has changed from
a management to a process orientation. And, although the
nature remained a total system approach, the name has
changed from “systems engineering” to the “engineering of
systems” to reflect that nature better.
 595

Table 3. SE Standard Differences

MIL-STD-499B EIA/IS 632
Scope of Standard
Defines total system Defines total system
approach for the devel- approach for the devel-
opment of defense sys- opment of systems.
tems. Definition of what "the
Specification on "the performing activity" does.
performing activity". This standard was the
demilitarized version of
MIL-STD-499B, which
was never officially ap-
proved by, but used
extensively by industry
and the Air Force.
Level of Abstraction
Medium level of abstrac- Same as 499B
tion -- Activity level
Example: Example:
•Pre-Concept •Market Requirements
•Concept Exploration •Concept Definition and
and Definition Feasibility
•Demonstration and •Concept Validation
Validation •Design and Verifica-
•Engineering and tion
Manufacturing •Production and
Development Deployment
•Production and •Operations and
Deployment Support
•Operations and
Support
2-page section on SEMP 2-page section on SEMP
in the Detailed Require- in the Detailed Require-
ments section and a ments section and an 8
template in page template in Appen-
Appendix B. dix B.
Appendix on guidance Appendix on guidance
for developing a SE for developing a SE
Master Schedule. Master Schedule.
IEEE 1220 EIA 632 ISO/IEC 15288
Defines the interdiscipli- Defines thirteen proc- Will address both sys-
nary tasks that are re- esses and 34 require- tem engineering and
quired throughout a ments for engineering a management (business)
system's life cycle to system. processes.
transform customer The focus is on imple- The focus is on the
needs, requirements, menting the require- “system” versus the
and constraints into a ments of the standard “components,” where
system solution. within a defined engi- component standards
Specifies the require- neering life cycle, which like ISO/IEC 12207 -
ments for the systems can be applied in any Software Life Cycle
engineering process and enterprise-based life Processes will apply.
its application throughout cycle phase to engineer
the system’s life cycle. or reengineer a system.
More detailed than 499B Higher level of abstrac- Highest level of
- Detailed Task level tion than previous stan- abstraction.
dards, less than 15288.
System Life Cycle
Typical: Enterprise-Based: Life Cycle Processes:
•System Definition •Assessment of •Concept Process
•Subsystem Definition Opportunities •Development Process
•Preliminary Design •Solicitation and •Production Process
•Detailed Design Contract Award •Operations Process
•Fabrication, •System Concept De- •Support Process
Assembly, Integration, velopment •Decommissioning or
and Test •Subsystem Design Disposal Process
•Production and Pre-Deployment
•Customer Support •Deployment/ Installa-
tion and Operations
and Support
SEMP Guidance
Ten-page "informative" One requirement calls Will not be a specific
Annex gives SEMP tem- for the creation of an engineering plan, more
plate. engineering plan. The than likely. But, planning
expected outcomes (or the system life cycle and
expected content) of this application of the generic
plan is provided in Annex processes will likely be
C. required.

engineering view (rather than, say, a “contracts” view).

In the case of EIA 632, this was because the author
group could not come to consensus on what systems
engineering was, in order to create a standard for it.
But they did detect a need for a standard on how to
create systems, and were able to come to consensus on
the content. If an organization chooses to use some-
thing called “systems engineering” in performing the
processes in EIA 632, that is acceptable, but it is not
required.
Similarly, ISO 15288 is not a systems engineering
standard. In this case, the scope is really higher than a
systems engineering organization would encompass,
and higher even than an engineering organization’s
normal scope, although the standard is written from an
A systems engineering standard might be invoked at a
lower level, as would software or hardware standards.
Nevertheless, these two standards were considered
in this paper, precisely because of all the confusion.
Focus. Standards vary in their focus in a way that mir-
rors the change in industry outlook. MIL-STD-499B
was clearly focused on a single military procurement
and a contractual agreement between contractor and
acquirer. EIA/IS 632 focused on systems and products
in general, and IEEE 1220 added focus on the enter-
prise (larger organization) as well. EIA 632 has an
enterprise context for the application of processes on
whatever system it is that one is engineering when one

uses EIA 632. ISO 15288 is likely to take the same
approach as its software predecessor ISO/IEC 12207,
where the focus is on a set of generic processes applied
as appropriate to accomplish the purposes of any one of
the phases of a system’s life cycle.
Definitions. Table 4 shows the different definitions of
system and systems engineering in the standards and
models. The definitions show that the standards are
addressing somewhat different problems.
Phraseology. MIL-STD-499B used “shall” to detail
what the contractor was responsible for doing. When
EIA/IS 632 was created from MIL-STD-499B, it kept
most of the same content. Two overall changes were to
replace the word “shall” with the present tense of the
verb and to replace the term “contractor” with “per-
forming activity.” Thus, instead of saying, “the con-
tractor shall develop items that are survivable,” EIA/IS
632 says, “the performing activity identifies and de-
fines requirements to ensure that items are survivable.”
This approach in EIA/IS 632 reduced the number of
“shalls” to four. However, one of the “shall” statements
called for a Systems Engineering Management Plan
(SEMP) and referenced an annex which provided a
comprehensive outline of the content.
IEEE 1220 also uses the “performing activity”
rather than contractor as the performer of standard
requirements. EIA 632 uses the term “developer” for
the performing activity.
Similarities and Differences among SE Capability
Models. Table 5 shows that the three capability models
are similar in architecture and intent. Indeed, the con-
tent and scope of all three models are similar. Primary
differences, shown in Table 6, are that the SE-CMM
Table 4. Definitions of System and Systems Engineering in SE Standards and Capability Models
Standard Definition of System
or Model
MIL-STD- An integrated composite of people, products,
and processes that provide a capability to
499B
satisfy a stated need or objective.
596
considered all process area content (in that case, called
base practices) to be necessary to reach Level 1,
whereas the other two limited what was needed for
Level 1 and added more practices at higher levels. The
SECAM and SECM also included process effectiveness
and product value considerations, where the SE-CMM
did not. The SECM maturity scale specifies “generic
attributes” which rate these non-process aspects. Fi-
nally, the SECM traces closely to the systems engi-
neering standards.
Table 5. SE Capability Models Commonality
Architecture: All three use the six-level SPICE architecture,
including 18 or 19 process (or focus) areas on one axis, meas-
ured by Levels 0-5 capability on the other axis.
What vs. How: All three models do not prescribe “how”, just
characteristics of good processes.
Role: All three models do not prescribe “who” (Role independ-
ence)
General Categories: All three models have separate catego-
ries for technical, management, and organizational elements.
Life Cycle Considerations: None address logistics and op-
erations very well. All three models address most other of the
12 systems engineering roles [Sheard 1996].
Elements of the Models. Table 1 shows that the Focus
Areas (FAs) of the SECM are almost a 1:1 derivation
from both the source models. SECM FAs 1.1, 1.2, and
1.3 changed emphasis in that the SECM kept all prob-
lem-domain ideas in 1.1 and 1.2, and all solution do-
main ideas in 1.3, whereas both source models mixed
these somewhat. Content of other areas was shifted
slightly, but in general all three models have nearly
identical process content. Data Management is not
present in SE-CMM.
Definition of Systems Engineering
An interdisciplinary approach encompassing the entire technical
effort to evolve and verify an integrated and life-cycle balanced set of
system people, product, and process solutions that satisfy customer
needs. Systems engineering encompasses:
a) the technical efforts related to the development, manufacturing,
verification, deployment, operations, support, disposal of, and user
training for, system products and processes;
b) the definition and management of the system configuration;
c) the translation of the system definition into work breakdown
structures; and
d) development of information for management decision-making.
 597

Table 4. (continued)

Standard Definition of System Definition of Systems Engineering

or Model
EIA/IS 632 Same as MIL-STD -499B Same as MIL-STD-499B

IEEE 1220 The top element of the system architecture, An interdisciplinary collaborative approach to derive, evolve, and
specification tree, or systems breakdown verify a life cycle balanced system solution that satisfies customer
structure that is comprised of one or more expectations and meets public acceptability.
products and associated life cycle processes
and their products and services.
EIA 632 The aggregation of end products and ena- None— the term is not used or referred to in the standard.
bling products that achieves a given purpose.

ISO 15288 An integrated composite that consists of one
or more of the processes, hardware, soft-
ware, facilities and people, that provides a
capability to satisfy a stated need or objective.
(ISO 12207 definition adopted for ISO
15288)
SE-CMM An integrated composite of people, prod-
ucts, and processes that provide a capability
to satisfy a stated need or objective.
(MIL-STD-499B definition)
SECM The aggregation of end products and ena-
(EIA/IS bling products that achieves a given purpose.
731)
None— the term is not used or referred to in the standard.
Systems engineering is the selective application of scientific and
engineering efforts to
• Transform an operational need into a description of the system
configuration which best satisfies the operational need ac-
cording to the measures of effectiveness,
• Integrate related technical parameters and ensure compatibility
of all physical, functional, and technical program interfaces in a
manner which optimizes the total system definition and design,
• Integrate the efforts of all engineering disciplines and special-
ties into the total engineering effort.
An interdisciplinary approach and means to enable the realization of
successful systems.

SECAM A set of interrelated components working An interdisciplinary approach and means to enable the realization of
together to accomplish a common purpose successful systems.
(CAWG). An interacting combination of ele-
ments viewed in relation to function
(INCOSE).

Table 6. Capability Model Differences

Attribute SE-CMM SECM (EIA/IS 731) SECAM
Focus Process only Process, plus process effectiveness and Process, plus process effec-
product value tiveness and product value
Smallest elements Practices Practices Questions
Level of elements All practices at Level 1 Basic practices at Level 1 Questions at all levels
Advanced practices at Levels 2-5
Integer ratings? Yes Not clear in draft of model No
Generic practices Generic practices apply to all Generic practices apply to all Focus Areas. Generic questions tailored for
Process Areas Two Generic Attributes apply to each Key Focus Area
non-process characteristics.
Tie to standards Influenced by Influenced by, and more explicitly tied to Influenced by

CONCLUSION
Although the systems engineering and capability
models arena currently looks complicated, there is
good news. Two models have been merged into a third,
which is likely to replace the others and is similar
enough to both that transition should be relatively easy.
This paper discusses the similarities and differ-
ences among the standards and models. The compari-
son should help individuals and organizations doing
systems engineering to understand which standards
and models are current and which are likely to be most
useful in the future. The working groups of INCOSE
can use the information in this paper for identifying
potential new efforts such as preparing guides and
handbooks to implement the processes of the standards,
or preparing models to fill the gaps identified.
REFERENCES
EIA/IS 632, Interim Standard: Systems Engineering.
1994. Electronic Industries Alliance, December
1994.
IEEE 1220-1994. IEEE Trial-Use Standard for Appli-
cation and Management of the Systems Engineer-
ing Process, IEEE Computer Society, Institute of
Electrical and Electronics Engineers, February 28,
1995.
Lake 97: “Thoughts about Life Cycle Phases: How a
System is Developed Incrementally,” Dr. Jerome G.
Lake, Proceedings of INCOSE, 1997.
Martin, James N. “Evolution of EIA 632 from an In-
terim Standard to a Full Standard,” Proceedings of
INCOSE, 1998.
Martin, James N. “Overview of EIA 632: Processes for
Engineering a System,” Proceedings of INCOSE,
1998.
MIL-STD-499B, Draft Military Standard: Systems
Engineering. HQ/AFSC/ EN, Department of De-
fense, “For Coordination Review” draft, May 6,
1992.
Quagmire: Web site at www.software.org/quagmire.
SECAM: Systems Engineering Capability Assessment
Model (version 1.50), INCOSE, June 1996.
SE-CMM: Bate, Roger, et. al., Systems Engineering
Capability Maturity Model (version 1.1), Software
Engineering Institute, Carnegie Mellon University,
November 1995.
Sheard, Sarah A. “Twelve Systems Engineering
Roles,” Proceedings of INCOSE, 1996.
Sheard, Sarah A. “Navigating the Compliance Frame-
works Quagmire,” Tutorial, INCOSE 1997a.
Sheard, Sarah A. “The Frameworks Quagmire, A Brief
Look,” Proceedings of INCOSE, 1997b.
View publication stats
598
SW-CMM: Paulk, Mark C., Bill Curtis, Mary Beth
Chrissis, and Charles V. Weber. Capability Matur-
ity Model for Software, Version 1.1, Software En-
gineering Institute, February 1993.
AUTHOR BIOGRAPHIES
Sarah A. Sheard has eighteen years experience in
systems engineering, including hardware systems (sat-
ellites) and software systems such as air traffic control.
Currently, as a systems engineer at the Software Pro-
ductivity Consortium, Ms. Sheard helps companies
start systems engineering process improvement efforts
and integrate software and systems engineering work
and process improvement efforts.
Ms. Sheard was on the original author team for the
SE-CMM model and served as an author of EIA 731
for half a year. Ms. Sheard is an author of the FAA-
iCMM, an integrated CMM merging the Software
CMM, the Systems Engineering CMM, and the Soft-
ware Acquisition CMM for the FAA.
Ms. Sheard received a B.A. in Chemistry from the
University of Rochester and an M.S. from the Califor-
nia Institute of Technology.
Dr. Jerome G. Lake is the co-founder and chief sci-
entist of Systems Management international (SMi), a
consulting and training company. Dr. Lake is one of
the founders of INCOSE and has served on the board
of directors for seven years as the first president and
director-at-large. He received the Founders Award in
1996. Dr. Lake is an aerospace engineer by degree. His
former positions include: pilot and R&D manager in
the U.s. Air Force; industry consultant/project manager
for cruise missile testing; dean at two business schools;
director of technology and engineering management at
the University of Maryland, and faculty member at the
Defense Systems Management College. Dr. Lake rep-
resents INCOSE as a technical expert for the ISO
15288 effort.