Systems Engineering Standards and Models
Compared
Sarah A. Sheard
Software Productivity Consortium
2214 Rock Hill Road, Herndon, VA 20170
(703) 742-7106; fax: (703) 742-7200
[email protected]
Dr. Jerome (Jerry) G. Lake
Systems Management international
281 So. Pickett Street #401
Alexandria, VA 22304
(703) 751-7987; fax: (703) 751-5189
[email protected]
Abstract. Currently there are five systems engineering
standards in various stages of release and three systems
engineering capability models. This makes it difficult to
know what to use as a basis for process improvement.
This paper discusses the similarities and differences
among the standards and models. The standards have
been evolving from the U.S. Military to international
and commercial, with recent standards taking a broader
scope. Two capability maturity models have been
merged into a third, which is tied to the standards.
MIL-STD 499B
1992 Draft
EIA/IS 632
1994
SECAM
IEEE (1.5) 1996
EIA 632* 1220*
1998? 1998?
INTRODUCTION
In the last 5 years, five systems engineering standards and three systems engineering capability models
have been published or begun. It is difficult for a systems engineering practitioner to stay current with the
various models, understanding what is current, how it
differs from others, and when and why each version
ought to be used. A 1997 INCOSE symposium tutorial
included a module that addressed the similarities and
differences [Sheard 1997a]. This paper updates that
material.
HISTORY
The Frameworks Quagmire [Sheard 1997b] excerpt
shown in Figure 1 clearly indicates that confusion over
systems engineering (SE) standards and models is
likely. Various standards and models have been released that build on each other and on other available
standards and models, particularly those in 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 released and
endorsed by INCOSE (such as [SECAM 1996]).
MIL-STD-499B, EIA/IS 632, IEEE 12201. In
May of 1992, a “Coordination Copy” of the proposed
ISO/IEC 15288*
2000?
The released version of IEEE 1220 is also referred to as
IEEE 1220-1994. This is a “Trial-Use” standard. This is
being updated in 1998, with the most recent version re-
SE-CMM
(1.1) 1995
SECM
EIA/IS 731
1998?
IPDCMM*
SSECMM
* Not Yet Released
Derived From
Influenced By
Figure 1. SE Standards and Models History
MIL-STD-499B [MIL-STD-499B 1992] was distributed to reviewers. This would have updated and significantly rewritten MIL-STD-499A, Engineering Management, and the name would have become Systems
Engineering. However, industry lacked consensus about
what ought to be included in a standard on systems engineering, which delayed approval, and there was a
change of administrations in the Pentagon.
In June 1994, a Department of Defense initiative
decreed the end of military standards other than performance specifications, thereby guaranteeing that MILSTD-499B would never be released as such. At the request of a new Director for Systems Engineering within
the Office of Secretary for Defense (OSD), an Electronic Industries Alliance (EIA)2 working group composed of representatives from the Aircraft Industry As-
2
1
IEEE 1220-1994
Trial Use
SW-CMM
ISO
15504*
(SPICE)
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.
The EIA and the Institute of Electrical and Electronics
Engineers (IEEE ) are two bodies approved to set standards
by the United States’ official standards-setting body, the
American National Standards Institute (ANSI).
sociation, 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 MILSTD-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 replacement version, to be called EIA 632. In parallel, the
IEEE also released in February 1995 a commercial
“Trial-Use” standard IEEE 1220-1994 [IEEE 12201994 1995]. IEEE 1220-1994 states that it will be
merged with EIA/IS 632 into a single American National 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 Technical Committee is expected to complete the work on the
revision with the expectation of a summer 1998 publication. 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 international 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 incremental
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.
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 released
in one year’s time.
3
4
See Table 1 for a discussion of the outcome of this.
Officially, ISO/IEC 15288.
This group, later called EPIC (for Enterprise Process Improvement Collaboration), used the Software
Engineering Institute (SEI) of Carnegie Mellon University 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 [SWCMM 1993] legacy in its favor. Other organizations
took an opposite approach: some INCOSE members
believed that anyone with a first name of “Software”
should not be speaking for systems engineering. To say
there was disagreement in the field is an understatement.
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 Capability 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 Engineering in OSD. The group formed of industry and government representatives is looking at the common aspects of all the capability models, including Integrated
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 capability models in general, then, what are the similarities and differences among the five systems engineering
standards and then, the three systems engineering capability models.
Standard vs. Capability Model. Standards and Capability 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 estab-
Purpose. Capability models provide a way to evaluate
an enterprise’s or project’s systems engineering capability. 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 contracts, 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 systems engineering standards (EIA 632 or IEEE 1220),
use by an enterprise is ordinarily voluntary, as is imposing a standard on a supplier as a basis for competition
or performance. Capability models theoretically are also
voluntary, though certainly with the SW-CMM it is
evident that the practices called out by a capability
model have been imposed. U.S. government contracting
for software has in some cases imposed a requirement
that contractors demonstrate a minimum of Level 2 or
Level 3 ranking in the SW-CMM.
Life Cycle. Standards may prescribe a life cycle (although most specify theirs as “typical” or “example”
life cycles). In general, models do not. They are intended to apply to any system life cycle. A discussion
on the INCOSE list server about life cycles led to two
observations: 1) that many people are sure that they
know the one correct life cycle, and 2) that these people
differ on what that life cycle is. It varies not only by
industry (those making nuclear submarines naturally
have a different time-based life cycle than those making
cellular telephones), but also by whether the person
speaking is a customer (an acquisition life cycle), a contractor (a development life cycle), or even a user (a
maintenance life cycle) [Lake 1997].
Number of Elements. Most standards have fewer than
ten process elements, but the systems engineering capability models have 18 or 19. MIL-STD-499B and
(EIA/IS 632) show four interrelated process steps, including 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 processes), System Design (two processes), Product Realization (two processes), and Technical Support (four
processes). These processes are intended to be implemented by a single developer during any phase of a
system’s life cycle, as applicable.
Technical Management
Planning
Process
Assessment
Process
Plans
Status
Products
Plans
Directives
Agreement
Supply
Process
System
Design
Requirements
Definition
Process
Acquisition
Process
Solution
Definition
Process
Acquisition
& Supply
Control
Process
Outcomes
Product
Realization
Implementation
Process
Transition
To Use
Process
System
Products
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 capability models have both attempted to avoid the problem by
focusing on processes and their related activities and
tasks or requirements (the “whats”), not on methods and
tools (the “hows”).
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.
Acquisition
Request
lished by ANSI, capability models can be created by
anyone with the resources. Other comparisons are
shown below.
Outcomes
Technical Support
System
Analysis
Process
Requirements
Validation
Process
Product
Verification
Process
Product
Validation
Process
Figure 2. The Processes of EIA 632
Like EIA 632, the capability models separate out
the pieces of System Analysis and Control as process
elements, and place Control in a “project” or “management” category (see Table 1). Capability models also
add a third set of elements, those which establish organizational support for systems engineering, such as training, process management, and tool support. These are
included in the Application Context clause of EIA 632.
Table 1. Comparison of Process, Focus, and Key Focus Areas in the Three SE Capability Models
SE-CMM (PAs)
PA06
PA02
PA03
PA01
PA05
PA07
PA04
PA12
PA11
PA10
PA09
PA08
PA13
PA14
PA17
PA15
PA16
PA18
SECM(EIA/IS 731) (FAs)
Engineering, Technical, or Systems Engineering Areas
Understand Customer Needs
1.1 Define Stakeholder and System
3.1
and Expectations
Level Requirements
Derive and Allocate Require1.2 Define Technical Requirements
3.2
ments
Evolve System Architecture
1.3 Define Solution
3.3
Analyze Candidate Solutions
1.4 Assess and Select
3.4
Integrate System
1.5 Integrate System
3.5
Verify and Validate System
1.6 Verify System
3.6
1.7 Validate System
3.7
Integrate Disciplines
(see 2.3 below)
Project or Management Areas
Plan Technical Effort
2.1 Plan and Organize
1.1
Monitor and Control Technical
2.2 Monitor and Control
1.2
Effort
(PA04 above)
2.3 Integrate Disciplines
1.4
(PA18 below)
2.4 Coordinate with Suppliers
1.3
Manage Risk
2.5 Manage Risk
1.7
(none)
2.6 Manage Data
1.8
Manage Configurations
2.7 Manage Configurations
1.5
Ensure Quality
2.8 Ensure Quality
1.6
Organization or Environment Areas
Define Organization’s SE Proc3.1 Define and Improve the Systems
2.1
ess
Engineering Process
Improve Organization’s SE
Process
Provide Ongoing Knowledge
3.2 Manage Competency
2.2
and Skills
Manage Product Line Evolution
3.3 Manage Technology
2.3
Manage Systems Engineering
3.4 Manage Systems Engineering
2.4
Support Environment
Support Environment
Coordinate With Suppliers
(see 2.4 above)
Is EIA/IS 731 a standard or a model? In EIA/IS 731,
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 engineering 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.”
SECAM (KFAs)
System Concept Definition
Requirements and Functional
Analysis
System Design
Integrated Engineering Analysis
System Integration
System Verification
System Validation
(see 1.4 below)
Planning
Tracking and Oversight
Intergroup Coordination
Subcontract Management
Risk Management
Data Management
Configuration Management
Quality Management
Process Management and Improvement
Competency Development
Technology Management
Environment and Tool Support
(see 1.3 above)
Table 2. SE Standards Commonalities
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
standards. 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.
Table 3. SE Standard Differences
MIL-STD-499B
EIA/IS 632
IEEE 1220
Scope of Standard
EIA 632
ISO/IEC 15288
Defines total system
approach for the development of defense
systems.
Specification on "the
performing activity".
Defines total system
approach for the development of systems.
Definition of what "the
performing activity"
does.
This standard was the
demilitarized version of
MIL-STD-499B, which
was never officially
approved by, but used
extensively by industry
and the Air Force.
Defines the interdisciplinary tasks that are
required throughout a
system's life cycle to
transform customer
needs, requirements,
and constraints into a
system solution.
Specifies the requirements for the systems
engineering process
and its application
throughout the system’s
life cycle.
Defines thirteen processes and 34 requirements for engineering a
system.
The focus is on implementing the requirements of the standard
within a defined engineering life cycle, which
can be applied in any
enterprise-based life
cycle phase to engineer
or reengineer a system.
Will address both system engineering and
management (business)
processes.
The focus is on the
“system” versus the
“components,” where
component standards
like ISO/IEC 12207 Software Life Cycle
Processes will apply.
Medium level of abstraction -- Activity level
Same as 499B
More detailed than
499B - Detailed Task
level
Higher level of abstraction than previous standards, less than 15288.
Highest level of
abstraction.
Example:
• Pre-Concept
• Concept Exploration
and Definition
• Demonstration and
Validation
• Engineering and
Manufacturing
Development
• Production and
Deployment
• Operations and
Support
Example:
• Market Requirements
• Concept Definition
and Feasibility
• Concept Validation
• Design and Verification
• Production and
Deployment
• Operations and
Support
Typical:
• System Definition
• Subsystem Definition
• Preliminary Design
• Detailed Design
• Fabrication,
Assembly, Integration, and Test
• Production
• Customer Support
Enterprise-Based:
• Assessment of
Opportunities
• Solicitation and
Contract Award
• System Concept
Development
• Subsystem Design
and Pre-Deployment
• Deployment/ Installation and Operations
and Support
Life Cycle Processes:
• Concept Process
• Development Process
• Production Process
• Operations Process
• Support Process
• Decommissioning or
Disposal Process
2-page section on
SEMP in the Detailed
Requirements section
and a template in
Appendix B.
Appendix on guidance
for developing a SE
Master Schedule.
2-page section on
SEMP in the Detailed
Requirements section
and an 8 page template
in Appendix B.
Appendix on guidance
for developing a SE
Master Schedule.
Ten-page "informative"
Annex gives SEMP
template.
One requirement calls
for the creation of an
engineering plan. The
expected outcomes (or
expected content) of
this plan is provided in
Annex C.
Will not be a specific
engineering plan, more
than likely. But, planning the system life
cycle and application of
the generic processes
will likely be required.
Level of Abstraction
System Life Cycle
SEMP Guidance
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 something
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
engineering view (rather than, say, a “contracts” view).
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 mirrors 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 enterprise
(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 “performing activity.” Thus, instead of saying, “the contractor shall develop items that are survivable,” EIA/IS 632
says, “the performing activity identifies and defines
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 content and scope of all three models are similar. Primary
differences, shown in Table 6, are that the SE-CMM
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. Finally, the SECM traces closely to the systems engineering 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,
measured 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 independence)
General Categories: All three models have separate categories for technical, management, and organizational elements.
Life Cycle Considerations: None address logistics and
operations 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 problem-domain ideas in 1.1 and 1.2, and all solution domain 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.
Table 4. Definitions of System and Systems Engineering in SE Standards and Capability Models
Standard
or Model
Definition of System
Definition of Systems Engineering
MIL-STD499B
An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective.
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.
Table 4. (continued)
Standard
or Model
Definition of System
Definition of Systems Engineering
EIA/IS 632
Same as MIL-STD -499B
Same as MIL-STD-499B
IEEE 1220
The top element of the system architecture,
specification tree, or systems breakdown
structure that is comprised of one or more
products and associated life cycle processes and their products and services.
An interdisciplinary collaborative approach to derive, evolve, and
verify a life cycle balanced system solution that satisfies customer
expectations and meets public acceptability.
The aggregation of end products and enabling products that achieves a given purpose.
None—the term is not used or referred to in the standard.
An integrated composite that consists of
one or more of the processes, hardware,
software, facilities and people, that provides a capability to satisfy a stated need or
objective.
(ISO 12207 definition adopted for ISO
15288)
None—the term is not used or referred to in the standard.
SE-CMM
An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective.
(MIL-STD-499B definition)
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 according 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 specialties into the total engineering effort.
SECM
(EIA/IS
731)
The aggregation of end products and enabling products that achieves a given purpose.
An interdisciplinary approach and means to enable the realization
of successful systems.
SECAM
A set of interrelated components working
together to accomplish a common purpose
(CAWG). An interacting combination of
elements viewed in relation to function
(INCOSE).
An interdisciplinary approach and means to enable the realization
of successful systems.
EIA 632
ISO 15288
Table 6. Capability Model Differences
Attribute
SE-CMM
SECM (EIA/IS 731)
SECAM
Focus
Process only
Process, plus process effectiveness and
product value
Process, plus process effectiveness and product value
Smallest elements
Practices
Practices
Questions
Level of elements
All practices at Level 1
Basic practices at Level 1
Advanced practices at Levels 2-5
Questions at all levels
Integer ratings?
Yes
Not clear in draft of model
No
Generic practices
Generic practices apply to
all Process Areas
Generic practices apply to all Focus Areas. Two Generic Attributes apply to
non-process characteristics.
Generic questions tailored for
each Key Focus Area
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 differences
among the standards and models. The comparison
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 Application and Management of the Systems Engineering
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 Interim 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 Defense,
“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 Frameworks Quagmire,” Tutorial, INCOSE 1997a.
Sheard, Sarah A. “The Frameworks Quagmire, A Brief
Look,” Proceedings of INCOSE, 1997b.
SW-CMM: Paulk, Mark C., Bill Curtis, Mary Beth
Chrissis, and Charles V. Weber. Capability Maturity
Model for Software, Version 1.1, Software Engineering Institute, February 1993.
AUTHOR BIOGRAPHIES
Sarah A. Sheard has eighteen years experience in systems engineering, including hardware systems (satellites) and software systems such as air traffic control.
Currently, as a systems engineer at the Software Productivity 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 Software Acquisition CMM for the FAA.
Ms. Sheard received a B.A. in Chemistry from the
University of Rochester and an M.S. from the California
Institute of Technology.
Dr. Jerome G. Lake is the co-founder and chief scientist 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 represents INCOSE as a technical expert for the ISO 15288
effort.